Santrauka - vtek.lt · Web viewSudėtingesni panaudos atvejai ar jų grupės turi būti detalizuojami pateikiant veiklos bei Registro procesus, naudojant procesų modeliavimo diagramas

Konkurso sąlygų 1 priedas

PRIVAČIŲ INTERESŲ REGISTRO SUKŪRIMO TECHNINĖ SPECIFIKACIJA

Užsakovas: Vyriausioji tarnybinės etikos komisija

Privačių interesų registro sukūrimo techninė specifikacija 2 | 47

PARENGĖ

Organizacija/Padalinys Funkcijos projekte Vardas, pavardė

UAB „S4ID“ Analitikas Karolis Linkevičius

UŽSAKOVAS

Organizacija/Padalinys Funkcija projekte Vardas, pavardė

Vyriausioji tarnybinės etikos komisija

Projekto vadovė Evelina Matulaitienė

PAKEITIMŲ ISTORIJA

Versija Data Pastabos

V0.1 2017-09-05 Pateikta užsakovui


TURINYS1. Santrauka.................................................................................................................................................. 4

2. Sąvokos ir sutrumpinimai..........................................................................................................................4

3. Susijusių dokumentų sąrašas.................................................................................................................... 6

4. Pirkimo tikSLAS, PROJEKTO VEIKLOS IR REZULTATAI........................................................................6

5. Esamos situacijos aprašymas...................................................................................................................6

5.1. Esama situacija................................................................................................................................ 6

6. SIEKIAMOS SITUACIJOS APRAŠYMAS.................................................................................................9

7. Reikalavimai programinei įrangai.............................................................................................................14

7.1. Funkciniai reikalavimai................................................................................................................... 14

7.2. Nefunkciniai reikalavimai...............................................................................................................31

7.2.1. Reikalavimų įgyvendinimas......................................................................................................31

7.2.2. Reikalavimai saugumui............................................................................................................31

7.2.3. Reikalavimai architektūrai........................................................................................................32

7.2.4. Reikalavimai programinei įrangai ir licencijoms........................................................................32

7.2.5. Reikalavimai naudotojo sąsajai................................................................................................33

7.2.6. Reikalavimai greitaveikai ir našumui........................................................................................35

7.2.7. Reikalavimui duomenų migravimui...........................................................................................35

7.2.8. Reikalavimai duomenų kokybei................................................................................................35

7.2.9. Reikalavimai testavimo ir eksploatavimo aplinkoms.................................................................35

7.2.10. Reikalavimai testavimui..........................................................................................................36

7.2.11. Reikalavimai įdiegimui gamybinėje aplinkoje.........................................................................36

7.2.12. Reikalavimai mokymams.......................................................................................................37

7.2.13. Reikalavimai bandomajai eksploatacijai.................................................................................37

7.2.14. Reikalavimai garantijai ir priežiūrai.........................................................................................38

7.3. Reikalavimai pasiūlymams.............................................................................................................38

7.4. Baigiamosios nuostatos................................................................................................................. 39

8. Sutarties vykdymo etapai ir terminai........................................................................................................39


1. SANTRAUKA1. Šis dokumentas parengtas vadovaujantis nuostatomis, išdėstytomis 2017 m. gegužės 25 d. Informacinės sistemos kūrimo ir diegimo techninės specifikacijos ir įteisinančių dokumentų parengimo paslaugų pirkimo sutartyje MS-4-(6.10)/SR-17-1 (toliau - Sutartis).2. Šio dokumento tikslas – aprašyti Privačių interesų registro (toliau – PIR arba Registras) sukūrimo funkcinius ir nefunkcinius reikalavimus.3. Šiame dokumente vartojami terminai „turi būti“, „turi turėti“, „turi leisti“, „turi turėti galimybę“, „turi būti sukurtas (-a)“ yra lygiaverčiai ir reiškia, kad Registro sukūrimo ir diegimo paslaugų teikėjas (toliau – Paslaugų teikėjas) šio pirkimo apimtyje privalo sukurti ir įdiegti (ar pateikti ir įdiegti) atitinkamą funkcionalumą, suteikti atitinkamas paslaugas ar pateikti reikiamus daiktus. Funkcionalumas, kuris yra nurodytas būsimuoju laiku (bus, leis, apims ir t.t.) nurodo siekiamą įgyvendinti būseną ir reiškia, kad Paslaugų teikėjas šio pirkimo apimtyje privalo sukurti ir įdiegti (ar pateikti ir įdiegti) atitinkamą funkcionalumą, daiktą ar paslaugą.

2. SĄVOKOS IR SUTRUMPINIMAI

Sąvoka ar sutrumpinimas Paaiškinimas

COR Civilinių orlaivių registras

DB Duomenų bazė

EDS Valstybinės mokesčių inspekcijos prie Lietuvos Respublikos finansų ministerijos elektroninio deklaravimo sistema

PIDTIS Privačių interesų deklaracijų tvarkymo informacinė sistema

JADIS Juridinių asmenų dalyvių registras

JAR Juridinių asmenų registras

GYPAS Valstybinės mokesčių inspekcijos gyventojų pajamų mokesčio informacinė sistema

GR Gyventojų registras

IT Informacinės technologijos

KTPR Kelių transporto priemonių registras

LICREG Sveikatos priežiūros ir farmacijos specialistų praktikos licencijų registras

LR Lietuvos Respublika

LRSVIS Lietuvos Respublikos Seimo veiklos informacinė sistema

LVĮ Lietuvos Respublikos lobistinės veiklos įstatymas

NTR Nekilnojamojo turto registras

Paslaugų teikėjas Privačių interesų registro sukūrimo ir diegimo paslaugų teikėjas


Sąvoka ar sutrumpinimas Paaiškinimas

Perkančioji organizacija, Užsakovas Vyriausioji tarnybinės etikos komisija

PID, Deklaracija Privačių interesų deklaracija

PIR, Registras Privačių interesų registras

PĮ Programinė įranga

PPID Preliminari privačių interesų deklaracija

Projektas Privačių interesų registro sukūrimas

SFMIS Europos Sąjungos struktūrinės paramos kompiuterinė informacinė valdymo ir priežiūros sistema

Skaidrumas Programinė įranga „Skaidrumas“

SPĮLIS Sveikatos priežiūros įstaigų licencijavimo informacinė sistema

SODRA IS Valstybinio socialinio draudimo fondo valdybos prie Socialinės apsaugos ir darbo ministerijos informacinė sistema

Techninė specifikacija Privačių interesų registro sukūrimo techninė specifikacija

TSŽŪMPR Traktorių, savaeigių ir žemės ūkio mašinų ir jų priekabų registras

VASPVT Valstybinė akreditavimo sveikatos priežiūros veiklai tarnyba

VATAR Valstybės tarnautojų registras

VBAMS Valstybės biudžeto apskaitos ir mokėjimų sistema

VDPT Valstybės debesijos paslaugų teikėjas

VIISP Valstybės informacinių išteklių sąveikumo platforma

VMI Valstybinė mokesčių inspekcija prie Lietuvos Respublikos finansų ministerijos

VPIDĮ Lietuvos Respublikos viešųjų ir privačių interesų derinimo valstybinėje tarnyboje įstatymas

VRK Vyriausioji rinkimų komisija

VRPR Vidaus reikalų pareigūnų registras

VSAKIS Viešojo sektoriaus apskaitos ir ataskaitų konsolidavimo informacinė sistema

VTEK Vyriausioji tarnybinės etikos komisija

VVLR Vidaus vandenų laivų registras


3. SUSIJUSIŲ DOKUMENTŲ SĄRAŠAS4. Žemiau pateiktas sąrašas dokumentų ir teisės aktų, kurias turi būti vadovaujamasi kuriant PIR:4.1. Lietuvos Respublikos viešųjų ir privačių interesų derinimo valstybinėje tarnyboje įstatymas (toliau -VPIDĮ),4.2. Lietuvos Respublikos Vyriausiosios tarnybinės etikos komisijos įstatymas,4.3. Lietuvos Respublikos valstybės informacinių išteklių valdymo įstatymas,4.4. Lietuvos Respublikos asmens duomenų teisinės apsaugos įstatymas;4.5. Lietuvos Respublikos lobistinės veiklos įstatymas (toliau - LVĮ);4.6. Kiti teisės aktai.

4. PIRKIMO TIKSLAS, PROJEKTO VEIKLOS IR REZULTATAI5. Pirkimo tikslas – sukurti, įdiegti, ištestuoti, išbandyti bei parengti darbinei eksploatacijai PIR.6. Pirkimo veiklos:6.1. Atlikti detalią poreikių ir galimybių analizę;6.2. Sumodeliuoti ir suprojektuoti PIR;6.3. Realizuoti PIR;6.4. Įdiegti PIR taikomąją programinę įrangą;6.5. Įdiegti duomenų bazes bei kitą reikiamą standartinę programinę įrangą;6.6. Sukurti sąsajas su visais Registro sukūrimo techninėje specifikacijoje (toliau - Techninė specifikacija) įvardintais duomenų teikėjais ir gavėjais;6.7. Sėkmingai įvykdyti PIR priėmimo testavimą bei bandomąją eksploataciją.7. Projekto rezultatas – pilna apimtimi sukurtas, įdiegtas ir ištestuotas PIR.

5. ESAMOS SITUACIJOS APRAŠYMAS

5.1.ESAMA SITUACIJA

8. Žemiau aprašyta esama situacija VTEK informacinių technologijų (toliau – IT) infrastruktūros ir vykdomos veiklos atžvilgiu. Šiuo metu vykdomi šie pagrindiniai procesai:8.1. Asmenų, kurie privalo deklaruoti privačius interesus, sąrašo sudarymas ir kontrolė;8.2. Privačių interesų deklaracijos (toliau – PID arba Deklaracija) pildymas ir teikimas;8.3. Deklaracijų viešinimas;8.4. Deklaracijų analizė;8.5. Pranešimų registravimas ir nagrinėjimas;8.6. Tyrimo atlikimas.9. Procesų schemos pateikiamos priede nr. 1.10. Žemiau schemoje yra pavaizduota VTEK sukurti ir palaikomi IT komponentai, kurie naudojami aukščiau išvardintų procesų vykdyme. Schemos komponentai vaizduoja programinės įrangos vienetus, jų teikiamas naudojimo sąsajas ir tas sąsajas naudojančias asmenų grupes (roles).


Paveikslas 1. „Esamos situacijos IT komponentų schema“

11. Žemiau lentelėje trumpai aprašomi schemos elementai bei VTEK IT infrastruktūros veikimo principai.

Lentelė 1. „Esamos situacijos IT komponentų schemos paaiškinimas“

Pavadinimas Aprašymas

Valstybinė mokesčių inspekcija prie Lietuvos Respublikos finansų ministerijos (toliau – VMI)

12. Valstybinės mokesčių inspekcijos prie Lietuvos Respublikos finansų ministerijos elektroninio deklaravimo sistema (toliau - EDS) ir Valstybinės mokesčių inspekcijos gyventojų pajamų mokesčio informacinė sistema (GYPAS)

12.1. EDS realizuoja galimybę Lietuvos Respublikos (toliau – LR) piliečiui pateikti kontrolės institucijoms įvairias deklaracijas (turto, gyventojo pajamų ir kt.), tame tarpe – PID (ID001). Asmuo, sėkmingai save identifikavęs EDS siūlomomis priemonėmis (el. bankininkystė, el. parašas, mob. parašas, Valstybės informacinių išteklių sąveikumo platforma (toliau -VIISP)), gauna galimybę savo EDS paskyroje pasirinkti pildyti ir pateikti PID. Pateiktoje deklaracijoje visi formos laukai (išskyrus vardą, pavardę, asmens kodą ir gyvenamąją vietą) yra tušti, t. y. nėra užpildyti valstybės registruose ir informacinėse sistemose esančiais duomenimis (kurie aktualūs deklaruojančio asmens atžvilgiu). Asmuo, užpildęs deklaraciją, ją pateikia. Tokia deklaracija išsaugoma GYPAS ir integracinių sąsajų pagalba yra perduodama į VTEK eksploatuojamą Privačių interesų deklaracijų tvarkymo informacinę sistemą.

VTEK

13. Privačių interesų deklaracijų tvarkymo informacinė sistema (toliau – PIDTIS) ir PIDTIS duomenų bazė (toliau – DB)

13.1. Tai programinė įranga, kuri sukurta ir eksploatuojama VTEK. Ši programinė įranga suteikia prieigą VTEK darbuotojams bei įstaigų, kurių darbuotojai turi deklaruoti privačius interesus, vadovams. Įstaigų vadovai turi tokias pagrindines funkcijas:13.1.1. Įstaigos struktūros tvarkymas (padalinių, skyrių pridėjimas ir šalinimas);13.1.2. Įstaigos darbuotojų sąrašo peržiūra;13.1.3. Įstaigos darbuotojų papildymas (darbuotojo įvedimas);13.1.4. Darbuotojo PID pateikimo būsenų sąrašas.


Pavadinimas Aprašymas

13.2. VTEK darbuotojai turi tas pačias funkcijas, kaip ir įstaigos vadovas, tik nėra apriboti vienos įstaigos rėmuose. Papildomai VTEK darbuotojai gali filtruoti pateiktas deklaracijas, atlikti jų peržiūrą bei spausdinimą. VTEK administratorius gali keisti sisteminius parametrus.

14. Programinė įranga (toliau – PĮ) „Skaidrumas“ (toliau – Skaidrumas) ir Skaidrumas DB

14.1. VTEK sukurta ir eksploatuojama programinė įranga, kuri skirta VTEK vykdomų tyrimų registravimui. Skaidrumas realizuoja šias pagrindines funkcijas, kuriomis naudojasi VTEK darbuotojai:14.1.1. Nagrinėjamo pranešimo registravimas;14.1.2. Tyrimo būsenos fiksavimas;14.1.3. Tyrimo metaduomenų suvedimas;14.1.4. Paieškos atlikimas tyrimų duomenyse;14.1.5. Paklausimo dėl rekomendacijos duomenų įvedimas;14.1.6. Paieškos vykdymas paklausimų dėl rekomendacijų duomenyse;14.1.7. Savivaldybių etikos komisijos sprendimų registravimas (metaduomenų suvedimas);14.1.8. Paieška savivaldybės etikos komisijų sprendimų duomenyse.

15. VTEK tinklapis ir tinklapio DB 15.1. VTEK tinklapis tai viešai prieinamas www.vtek.lt tinklapis, kuriame pateikiam įvairi su VTEK veikla susijusi informacija bei viešinamos viešos PID, kurios gali būti surandamos pagal juridinio asmens kodą, asmens vardą ir pavardę.

16. Esamos situacijos problematika:16.1. Nėra įteisinto PIR, t. y. dabar pateiktos Deklaracijos yra saugomos ir tvarkomos neįteisintomis (neįregistruotomis) programinėmis priemonėmis.16.2. VTEK eksploatuojama PIDTIS yra sukurta senomis technologijomis, nesilaikant gerųjų praktikų ir tipinių programų sistemų kūrimo architektūrinių sprendimų. Tai reiškia, kad stipriai apribotos PIDTIS funkcionalumo bei našumo plėtimo galimybės. Panaudotos techninės priemonės, kurios labiau skirtos kurti reprezentacinius tinklapius nei veiklos procesų kompiuterizavimo aplikacijas.16.3. Tai, kad PID pildymas ir teikimas realizuotas EDS aplinkoje, sukelia šia problemas:16.3.1. PID forma yra statinė, t. y. trūksta dinamiškumo. Nėra realizuotų sąsajų tarp įvedamų duomenų laukų, forma nekinta atliktus tam tikrus pasirinkimus ar įvedus tam tikrą informaciją, nėra pakankamos įvedamų duomenų validavimo logikos, forma nėra aiški ir patogi. Deklaracijos formos realizacija neišnaudoja šiuolaikinių tinklinių (angl. web) technologijų galimybių, kurios žymiai supaprastina duomenų įvedimo formos supratimą bei pildymą.16.3.2. PID forma nėra užpildoma valstybės registruose ir informacinėse sistemose kaupiamais su deklaruojančio asmens privačiais interesais susijusios informacijos duomenimis. Tokia funkcija pagreitintų Deklaracijos pildymą bei sumažintų žmogiškosios klaidos tikimybę (užmiršti deklaruoti).16.3.3. EDS nerealizuoja logikos ir neturi tam tinkamos terpės, kuri leistų identifikuoti privalančius PID teikti asmenis. Tam reikia integracinių sąsajų su įvairiais registrais, kuriuose saugoma informacija apie asmenų pareigas, turimas licencijas, priklausymą įvairioms taryboms ir pan.16.3.4. EDS forma negali būti lengvai keičiama (tobulinama), nes ji realizuota VMI eksploatuojamoje EDS sistemoje. Norint atlikti pakeitimus (tobulinimus) reikalingas sudėtingas procesas, kuris įtraukia ir VMI darbuotojus.

http://www.vtek.lt/


16.3.5. Nėra galimybės vienoje vietoje realizuoti su privačių ir viešųjų interesų derinimu susijusių paslaugų (funkcijų), nes EDS orientuota tik į deklaracijų pildymą ir pateikimą. Pavyzdžiui Deklaracijų paieška turi būti vykdoma VTEK tinklapyje, nors deklaracijos suvedamos EDS sistemoje. Taip pat nėra galimybės deklaruojančiam asmeniui patogiai prisijungti ir panaikinti savo Deklaraciją, nes tokia funkcija nerealizuota EDS.16.4. PIDTIS funkcionalumas nesuteikia galimybės atlikti patogios, greitos, metodikomis ir rizikų skaičiavimais paremtos Deklaracijų analizės. Šiuo metu PIDTIS pateikia tik ribotų galimybių deklaracijų filtrą.16.5. PIDTIS nerealizuoja sąsajų su valstybės informacinėmis sistemomis ir registrais, kuriuose yra informacija apie asmenis, kurie turi teikti PID. Šią naštą apsiima įstaigų vadovai, kurie turi rankiniu būdu įvesti asmenis, turinčius teikti PID, bei VTEK, bendraudama su registrų ir informacinių sistemų valdytojais ir tvarkytojais, kurie reikiamą informaciją pateikia rankiniu būdu sudarydami XLSX ar CSV rinkmenas.16.6. Skaidrumas realizuotas atskirai nuo PIDTIS. Aplikacijų išsaugomi duomenys taip pat nėra niekaip siejami, todėl tenka kartoti tos pačios informacijos įvedimą.

6. SIEKIAMOS SITUACIJOS APRAŠYMAS17. Projekto „Privačių interesų registro sukūrimas“ (toliau – Projektas), kurį įgyvendina VTEK, metu siekiama sukurti PIR, kuris realizuotų funkcionalumą skirtą deklaruojantiems asmenims, jų vadovams, savivaldybių etikos komisijos nariams ir VTEK darbuotojams. Asmenys, kurie privalo teikti deklaracijas, galės susipažinti su savo preliminariomis deklaracijomis, jas pakoreguoti ir pateikti į PIR. Institucijų vadovai ir jų įgalioti atstovai galės susipažinti su darbuotojų pateiktomis deklaracijomis, galės įvesti asmenis, kurie privalo teikti deklaracijas. Savivaldybių etikos komisijų nariai galės pateikti sprendimus pagal valstybės politiko elgesio kodeksą, o VTEK – analizuoti pateiktas PID ir vykdyti tyrimus.18. PIR turi būti realizuotas tinklinėmis (angl. web) technologijomis.19. Žemiau pateikiama siekiama PIR architektūros schema. Joje pateikiami PIR programinės įrangos vienetai, naudotojų grupės ir jų naudojami komponentai. Taip pat pateikiami valstybės registrai ir informacinės sistemos, kurios turi būti integruotos su PIR.


Paveikslas 2. „PIR architektūra”


20. Žemiau lentelėje paaiškinami schemos elementai.

Lentelė 2. PIR architektūros elementų paaiškinimas

Elementas Paaiškinimas

21. PIR išorinė aplikacija ir PIR išorinio portalo DB

21.1. PIR aplikacija, kuri realizuoja funkcijas viešosios informacijos naudotojams, institucijų vadovams, savivaldybės etikos komisijos nariams, deklaruojantiems asmenims.

22. PIR vidinė aplikacija ir PIR vidinio portalo DB

22.1. Aplikacija, kuri pasiekiama iš VTEK vidinio tinklo ir gali būti naudojama tik VTEK darbuotojų. Vidinė aplikacija realizuoja specifines funkcijas, skirtas VTEK veiklai vykdyti. PIR vidinės aplikacijos duomenų bazėje bus tvarkomi registro objektai.

23. Ataskaitų ir analizės PĮ 23.1. Programinė įranga, kuri padės vykdyti sukauptos informacijos ir veiklos rezultatų analizę, formuoti įvairias ataskaitas.

24. Integracinis komponentas 24.1. Komponentas, realizuojantis savarankišką integracijų architektūrinį lygmenį. Realizuojamas kaip ESB (angl. Enterprise Service Bus).

25. Duomenų teikimo servisai 25.1. Duomenų teikimo servisai, kurie Web Service ar RESTful technologijos pagrindu reikiama apimtimi teikia duomenis duomenų gavėjams.

26. Juridinių asmenų registras (toliau – JAR)

26.1. JAR teiks informaciją apie:26.1.1. Lietuvos banko darbuotojus, turinčius viešojo administravimo įgaliojimus (atliekančiu finansų rinkos priežiūros, vartotojų ir finansų rinkos dalyvių ginčų nagrinėjimo ne teisme funkcijas ir kitas viešojo administravimo funkcijas);26.1.2. Akcinių bendrovių ir uždarųjų akcinių bendrovių, kurių akcijos, suteikiančios daugiau kaip 1/2 balsų visuotiniame akcininkų susirinkime, nuosavybės teise priklauso valstybei ar savivaldybei, vadovus ir vadovų pavaduotojus;26.1.3. Politinių partijų pirmininkus ir jų pavaduotojus;26.1.4. Kitų juridinių asmenų vadovus ir jų pavaduotojus.

27. Juridinių asmenų dalyvių registras (toliau – JADIS)

27.1. JADIS teiks informaciją apie:27.1.1. Valstybės ar savivaldybių įmonių valdybų narius;27.1.2. Akcinių bendrovių bei uždarųjų akcinių bendrovių, kurių akcijos, suteikiančios daugiau kaip 1/2 balsų visuotiniame akcininkų susirinkime, nuosavybės teise priklauso valstybei ar savivaldybei, stebėtojų tarybų ir valdybų narius;27.2. Kitų juridinių asmenų dalyvius.

28. Gyventojų registras (toliau – GR) 28.1. GR teiks informaciją apie:28.1.1. Deklaruojančio asmens duomenis;28.1.2. Deklaruojančio asmens artimųjų duomenis.

29. Civilinių orlaivių registras (toliau – COR)

29.1. COR teiks informaciją apie deklaruojančio asmens civilinių orlaivių duomenis.

30. Valstybės tarnautojų registras (toliau – VATAR)

30.1. VATAR teiks informaciją apie:30.1.1. Valstybės tarnautojus;30.1.2. Valstybės politikus (jeigu turės tokią informaciją);30.1.3. Valstybės pareigūnus (jeigu turės tokia informaciją);30.1.4. Teisėjus (jeigu turės tokia informaciją);30.1.5. Asmenis, pretenduojančius į pareigas valstybinėje tarnyboje (jeigu bus techninės galimybės).

31. Kelių transporto priemonių 31.1. KTPR teiks informaciją apie deklaruojančio asmens turimų


Elementas Paaiškinimas

registras (toliau – KTPR) transporto priemonių duomenis.32. Nekilnojamojo turto registras (toliau – NTR)

32.1. NTR teiks informaciją apie deklaruojančio asmens turimo nekilnojamojo turto duomenis.

33. Traktorių, savaeigių ir žemės ūkio mašinų ir jų priekabų registras (toliau – TSŽŪMPR)

33.1. TSŽŪMPR teiks informaciją apie deklaruojančio asmens turimų transporto priemonių duomenis.

34. LR finansų ministerijos Viešojo sektoriaus apskaitos ir ataskaitų konsolidavimo informacinė sistema (toliau – VSAKIS), Valstybės biudžeto apskaitos ir mokėjimų sistema (toliau – VBAMS), Europos Sąjungos struktūrinės paramos kompiuterinė informacinė valdymo ir priežiūros sistema (toliau – SFMIS)

34.1. Teiks informaciją apie įstaigas ir asociacijas, kurios gauna lėšų iš Lietuvos valstybės ar savivaldybių biudžetų ir fondų.

35. Valstybinės mokesčių inspekcijos gyventojų pajamų mokesčio informacinė sistema (toliau – GYPAS)

35.1. GYPAS teiks informaciją apie nekilnojamojo turto mokesčio deklaraciją.

36. Valstybinio socialinio draudimo fondo valdybos prie Socialinės apsaugos ir darbo ministerijos informacinė sistema (toliau - SODRA IS)

36.1. SODRA IS teiks informaciją apie juridinių asmenų viešąją informaciją, kuri bus naudojama skaičiuojant PID rizikas.

37. Vidaus vandenų laivų registras (toliau - VVLR)

37.1. VVLR teiks deklaruojančio asmens turimų vidaus vandenų laivų duomenis.

38. Sveikatos priežiūros ir farmacijos specialistų praktikos licencijų registras (toliau – LICREG)

38.1. LICREG teiks informaciją apie gydytojus, odontologus ir farmacijos specialistus.

39. Lietuvos Respublikos Seimo veiklos informacinė sistema (toliau - LRSVIS)

39.1. LRSVIS teiks informaciją apie:39.1.1. Valstybės politikų visuomeninius konsultantus, padėjėjus, patarėjus;39.1.2. Lietuvos Respublikos Seimo komitetų patvirtintus ekspertus.

40. VIISP 40.1. VIISP teiks asmens identifikavimo elektroninėje erdvėje paslaugą. El. parašo, el. bankininkystės ar kitomis priemonėmis vienareikšmiškai identifikuoti asmenys galės naudotis PIR viešosios aplikacijos funkcionalumu.

41. Žemiau schemoje pateiktas preliminarus PIR dislokavimo vaizdas. PIR turės būti diegiama Valstybės debesijos paslaugų teikėjo (toliau – VDPT) (ar lygiavertėje) aplinkoje. Paslaugų teikėjas turės įvykdyti visus PIR įdiegimo darbus pagal VDPT reikalavimus ir apribojimus.42. Paslaugų teikėjas gali siūlyti alternatyvų PIR komponentų dislokavimo būdą, kuris turi būti patvirtintas Perkančiosios organizacijos.


Paveikslas 3. „PIR dislokavimo vaizdas“


7. REIKALAVIMAI PROGRAMINEI ĮRANGAI

7.1.FUNKCINIAI REIKALAVIMAI

43. Žemiau pateikiama PIR funkcinės architektūros schema.

Paveikslas 4. „PIR funkcinė architektūra“

44. Toliau pateikiama kiekvieno funkcinio komponento panaudos atvejų diagrama ir funkciniai reikalavimai panaudos atvejui.


Paveikslas 5. Institucijos vadovo srities panaudos atvejai

45. Reikalavimai PIR išorinės aplikacijos institucijos vadovo srities funkcijoms:45.1. Prie įstaigos vadovo srities turi galėti prieiti tik tinkamai identifikuotas ir autorizuotas įstaigos vadovas. Įstaigos vadovui identifikuoti turi būti naudojamos sąsajos su VIISP ir JAR. VIISP turi identifikuoti asmenį, o pagal gautus asmens duomenis turi būti atliktas patikrinimas JAR, ar asmuo yra juridinio asmens vadovas. Prisijungus prie PIR išorinės aplikacijos asmeniui turi būti pateikiamas pasirinkimas – atstovauti įmonę ar save.45.2. Įstaigos vadovas turi galėti įvesti asmenį (-is), kuriam suteikiamos vadovo teisės – tvarkyti deklaruoti turinčius asmenų duomenis, peržiūrėti jų Deklaracijas ir kt. Tokiam asmeniui jungiantis prie PIR turi būti pateiktas pasirinkimas – vykdyti įgalioto tvarkyti asmenų duomenis funkcijas ar atstovauti save.45.2.1. Įstaigos vadovas turi galėti pašalinti suteiktus įgaliojimus ar įgaliotą asmenį.45.3. Įstaigos vadovas turi galėti atlikti paiešką įstaigos darbuotojų sąraše. Paieškos kriterijai turi prasmingai atitikti sąrašo duomenis. Kiekvieno sąrašo paieškos formos laukai turi būti apibrėžti detalios analizės ar projektavimo etape.45.4. Įstaigos vadovas turi galėti peržiūrėti įstaigos, kurios vadovas yra, darbuotojų sąrašą. Darbuotojų sąraše turi galėti atverti detalią informaciją apie darbuotoją (darbuotojo kortelę) bei darbuotojo duomenų tvarkymo funkcijas.


45.5. Įstaigos vadovas turi galėti peržiūrėti darbuotojo duomenis bei darbuotojo visas PID.45.6. Įstaigos vadovas turi galėti įvesti įstaigos darbuotojo, kuris turi deklaruoti privačius interesus, duomenis. Pagal pateiktus darbuotojo duomenis (vardą, pavardę, asmens kodą ar valstybės tarnautojo kodą) turi būti automatiškai gaunami duomenys iš GR ir panaudojami darbuotojo kortelės sukūrimui. Vadovas gali įvesti tok tokį asmenį, kuris dirba toje pačioje įstaigoje, kaip ir vadovas. Įvedamo asmens darbovietė turi būti patikrinama SODROS IS.45.7. Įstaigos vadovas turi galėti redaguoti darbuotojo duomenis. Kokia apimtimi gali būti redaguojami duomenys turi būti nustatyta ir apibrėžtą detalios analizės ir projektavimo etape. Turi būti galima atnaujinti darbuotojo duomenis juos gaunant iš susijusių registrų (GR ar kt.).45.8. Turi būti galima pašalinti asmenį (darbuotoją), jeigu asmuo įvestas įstaigos vadovo. Jeigu asmuo į registrą įrašytas pagal informaciją gautą iš susijusių informacinių sistemų ir registrų, jo šalinti vadovas negali.45.9. Įstaigos vadovas turi galėti į VTEK pateikti pranešimus apie priimtus ar nepriimtus darbuotojų nusišalinimus. Turi būti galimybė užpildyti darbuotojo nusišalinimo ar darbuotojo atsisakymo nusišalinti pranešimo formą ir ją pateikti į VTEK. Turi būti galimybė pridėti darbuotojo nusišalinimo ar darbuotojo atsisakymo nusišalinti pranešimo skaitmeninę kopiją ir ją pateikti į VTEK.45.9.1. Turi būti galimybė sudaryti pranešimo PDF rinkmeną.45.10. Įstaigos vadovas turi galėti peržiūrėti VTEK pateiktas rekomendacijas (ar kitą informaciją).45.10.1. Turi būti galimybė sudaryti VTEK pateiktos informacijos PDF rinkmeną.45.11. Įstaigos vadovui prieiga prie sudaromų ar gaunamų dokumentų turi būti realizuota viename loginiame funkciniame vienete, kuris skirtas dokumentų sudarymui, peržiūrai ir pateikimui kitoms šalims.

Paveikslas 6. PID sudarymo ir pateikimo modulio panaudos atvejai

46. Reikalavimai PIR išorinės aplikacijos PID sudarymo ir pateikimo moduliui:


46.1. Šis modulis turi būti prieinamas tik per VIISP identifikuotiems asmenims, kurie turi teikti PID.46.2. Deklaruojantis asmuo turi galėti peržiūrėti savo anksčiau pateiktų deklaracijų sąrašą bei atverti iš sąrašo pasirinktą deklaraciją detaliai peržiūrai. Sąraše turi būti pateikiama aktuali deklaraciją apibūdinanti informacija: pavadinimas, pateikimo data, panaikinimo data, deklaracijos būsena ir kt.46.2.1. Turi būti galima sudaryti peržiūrai atvertos deklaracijos PDF rinkmeną.46.3. Turi būti galimybė deklaruojančiam asmeniui inicijuoti (užsakyti) preliminarios deklaracijos sudarymą. Preliminari deklaracija turi būti užpildoma iš išorinių registrų ir informacinių sistemų gautais duomenimis (žr. Lentelė 3. PIR integracinių sąsajų realizavimo tikslai, apimtys ir būdai).46.4. Deklaruojantis asmuo turi galėti peržiūrėti preliminarią deklaraciją ir atlikti norimus pakeitimus.46.5. Turi būti galimybė deklaruojančiam asmeniui sudaryti PID:46.5.1. Turi būti galimybė įvesti sutuoktinio, sugyventinio ir partnerio (toliau - partnerio) asmens duomenis: vardą, pavardę, asmens kodą, pilietybę. Įvestų duomenų korektiškumas turi būti patikrintas GR duomenyse. Patikrinimo rezultate neturi būti atskleidžiami asmens duomenys, kurių neįvedė deklaruojantis asmuo.46.5.2. Deklaracijoje deklaruojančio asmens darbovietės duomenys turi būti užpildyti automatiškai, gavus duomenis iš SODROS IS. 46.5.3. Turi būti galimybė įvesti deklaruojančios asmens partnerio darbovietės duomenis:46.5.3.1. Darbovietės kodą, pavadinimą, pareigas, telefono numerį. Įvestų duomenų korektiškumas turi būti patikrinamas SODROS IS, o patikrinimo rezultate neturi būti atskleidžiami asmens duomenys, kurių neįvedė deklaruojantis asmuo.46.5.3.2. Turi būti galima nurodyti neribotą kiekį darboviečių.46.5.4. Deklaracijoje deklaruojančio asmens įstaigos, kuriose asmuo yra dalyvis ar narys, turi būti užpildomos automatiškai, gavus duomenis iš JAR ir JADIS. 46.5.5. Turi būti galima nurodyti deklaruojančio asmens partnerio įstaigos, kurios dalyvis ar narys yra, duomenis:46.5.5.1. Įstaigos kodą, pavadinimą, valstybę (kurioje įstaiga registruota), ryšio tipą, ryšio pradžios ir pabaigos datas, kitą aktualią informaciją. Įvestų duomenų korektiškumas turi būti patikrinamas JAR ir JADIS, o patikrinimo rezultate neturi būti atskleidžiami asmens duomenys, kurių neįvedė deklaruojantis asmuo.46.5.5.2. Turi būti galima nurodyti neribotą kiekį ryšių su juridiniais asmenimis.46.5.6. Deklaracijoje deklaruojančio asmens sandorių duomenys turi būti užpildomi automatiškai, gavus duomenis iš išorinių registrų ir informacinių sistemų (žr. Lentelė 3. PIR integracinių sąsajų realizavimotikslai, apimtys ir būdai).46.5.7. Turi būti galima nurodyti deklaruojančio asmens ir jo partnerio sandorių duomenis:46.5.7.1. Sandorio rūšį, formą, sandorio pradžios ir pabaigos datas, sandorio metu įgytą ar suteiktą turtą ar paslaugą, apytikslę sandorio vertę, sandorio šalies kodą (fizinio ar juridinio asmens), sandorio šalies pavadinimą, sandorio esmės aprašymą;46.5.7.2. Turi būti galima nurodyti neribotą kiekį sandorių.46.5.8. Turi būti galimybė nurodyti deklaruojančio asmens ir partnerio ryšius su fiziniais asmenimis:46.5.8.1. Susieto asmens pilietybė, vardas, pavardė, kodas ir aplinkybės, dėl kurių gali kilti interesų konfliktas.46.5.9. Deklaracijoje deklaruojančio asmens individualios veiklos turi būti užpildomos automatiškai, gavus duomenis iš išorinių informacinių sistemų ir registrų (žr. Lentelė 3. PIR integracinių sąsajų realizavimotikslai, apimtys ir būdai).46.5.10. Turi būti galimybė nurodyti deklaruojančio asmens partnerio individualią veiklą:46.5.10.1. Individualios veiklos ryšys, veiklos pradžios ir pabaigs datos, papildomi duomenys apie veiklą. Įvestų duomenų korektiškumas turi būti patikrinamas JAR ir JADIS, o patikrinimo rezultate neturi būti atskleidžiami asmens duomenys, kurių neįvedė deklaruojantis asmuo;46.5.10.2. Turi būti galima nurodyti daugiau nei vieną individualią veiklą. 46.5.11. Turi būti galima nurodyti deklaruojančio asmens ir partnerio kitus duomenis, dėl kurių gali kilti interesų konfliktas.46.6. Deklaruojantis asmuo turi galėti išsaugoti PID ruošinį (nebaigtą pildyti PID) neribotam laikui. Turi būti galimybė pratęsti pildyti išsaugotą PID arba ją pašalinti.


46.7. Turi būti galimybė deklaruojančiam asmeniui pateikti sudarytą PID į VTEK. PIR turi atlikti teikiamos PID korektiškumo tikrinimą ir deklaruojančiam asmeniui pateikti tikrinimo rezultatą. Tik korektiškai užpildytos PID gali būti perduotos į PIR vidinį portalą. PID korektiškumo tikrinimo taisyklės ir logika turi būti detaliai apibrėžta detalios analizės ir projektavimo etape.46.8. Turi būti galimybė sudaryti PID ankstesnės PID pagrindu. Automatiškai gaunami duomenys turi būti užpildomi gaunant duomenis iš susijusių registrų ir informacinių sistemų, o ne perkeliami iš ankstesnės PID. Iš ankstesnės PID turi būti perkeliami tik paties deklaruojančio asmens laisvai įvesti duomenys.46.9. Turi būti galimybė deklaruojančiam asmeniui pranešti, kad jo pateikta PID nebeturi būti viešinama, nes asmuo prarado deklaruojančio asmens statusą. Turi būti galimybė nurodyti prašymo priežastis.46.10. PIR, gavusi iš informacinių sistemų ir registrų informaciją, turi nustatyti:46.10.1. Naujus asmenis, kurie įgijo deklaruojančio asmens statusą;46.10.2. Asmenis, kurie prarado deklaruojančio asmens statusą;46.10.3. PID, kurios turi būti deklaruojančio asmens atnaujintos.46.10.4. Apie aukščiau gautą informaciją PIR turi išsiųsti pranešimą deklaruojančiam asmeniui. Pranešime turi būti aiškiai išdėstyta kokia gauta informacija remiantis siunčiamas pranešimas bei kokius veiksmus PIR turi atlikti asmuo. Turi būti galimybė reikiamus veiksmus inicijuoti iš pranešimo turinio, pavyzdžiui: pranešti VTEK, kad neviešintų asmens deklaracijos arba inicijuoti naujos PID sudarymą.46.11. Deklaruojančiam asmeniui turi būti galimybė gauti VTEK ar PIR siunčiamus pranešimus.46.11.1. Apie PIR išorinėje aplikacijoje gautą pranešimą turi būti išsiunčiamas elektroninis laiškas, jeigu

PIR yra deklaruojančio asmens el. pašto dėžutės adresas.

Paveikslas 7. PID paieškos ir peržiūros panaudos atvejai

47. Reikalavimai PIR išorinės aplikacijos PID paieškos ir peržiūros moduliui:47.1. PID paieškos ir peržiūros modulis turi būti prieinamas viešai PID išorinėje aplikacijoje.47.2. Viešosios informacijos naudotojui turi būti galima atlikti paiešką viešose PID. Paieškos kriterijai turi prasmingai atitikti PID duomenų struktūrą. Paieškos formos laukai turi būti apibrėžti detalios analizės ar projektavimo etape.47.3. Turi būti galima atverti viešą PID peržiūrai. Detalios analizės metu turi būti apibrėžta kokie PID duomenų struktūros duomenys yra vieši.47.4. Turi būti galima sudaryti PID PDF rinkmeną.


Paveikslas 8. Pranešimų pateikimo modulio panaudos atvejai

48. Reikalavimai PIR išorinės aplikacijos pranešimo pateikimo moduliui:48.1. Turi būti galimybė viešosios informacijos naudotojui sudaryti ir pateikti pranešimą į VTEK:48.1.1. Turi būti galimybė pranešimą sudaryti užpildant formą PIR išorinėje aplikacijoje. Formą turi sudaryti tokie laukai (neapsiribojant):48.1.1.1. Pranešėjo duomenys ir kontaktai;48.1.1.2. Informacija apie asmenį, dirbantį valstybinėje tarnyboje;48.1.1.3. Straipsnis (-iai), kurį (-iuos) galimai pažeidė skundžiamas asmuo;48.1.1.4. Asmens veiksmai (ar neveikimas) bei kitos svarbios aplinkybės, dėl kurių galėjo būti pažeisti VPIDĮ reikalavimai;48.1.1.5. Kas prašoma VTEK;48.1.1.6. Dokumentai (ar jų kopijos), pagrindžiančios paminėtas aplinkybes;48.1.1.7. Kita.48.1.2. Turi būti galimybė pateikti PIR išorinėje aplikacijoje įkeliant skenuotą skundo versiją ar el. parašu patvirtiną skaitmeninę skundo versiją.


Paveikslas 9. Savivaldybės srities panaudos atvejai

49. Reikalavimai PIR išorinės aplikacijos savivaldybės etikos komisijos nario sričiai:49.1. Turi būti galimybė savivaldybės etikos komisijos nariui identifikuotis ir autorizuotis PIR išorinėje aplikacijoje, savivaldybės etikos komisijos nario srityje. Savivaldybės etikos komisijos narį PIR turi užregistruoti ir suteikti prisijungimo duomenis VTEK atsakingas darbuotojas.49.2. Tinkamai identifikuotas ir autorizuotas savivaldybės etikos komisijos narys turi galėti įkelti skenuotą sprendimo pagal valstybės politiko elgesio kodeksą kopijos versiją ar el. parašu patvirtiną skaitmeninę sprendimo versiją bei suvesti metaduomenis (metaduomenys turi būti apibrėžti detalios analizės etape).49.3. Turi būti galimybė etikos komisijos nariui peržiūrėti anksčiau savivaldybės pateiktų sprendimų sąrašą bei atverti anksčiau pateiktą sprendimą peržiūros režimu.

49.3.1. Turi būti galimybė sudaryti sprendimo PDF rinkmeną.

Paveikslas 10. VTEK sprendimų paieškos ir peržiūros panaudos atvejai


50. Reikalavimai PIR išorinės aplikacijos VTEK sprendimų paieškos ir peržiūros moduliui:50.1. Turi būti galima atlikti paiešką viešuose VTEK sprendimuose. Paieškos kriterijai turi prasmingai atitikti sąrašo duomenis. Kiekvieno sąrašo paieškos formos laukai turi būti apibrėžti detalios analizės ar projektavimo etape. Turi būti galima atlikti paiešką VTEK sprendimo dokumento turinyje.50.2. Turi būti galima į kompiuterį atsisiųsti sprendimo dokumentą.

Paveikslas 11. Konsultavimo / susirašinėjimo modulio panaudos atvejai

51. Konsultavimo ir susirašinėjimo modulio reikalavimai:51.1. Visiems PIR išorinės aplikacijos naudotojams turi būti galimybė greitai ir nesudėtingai inicijuoti „gyvą“ (angl. live chat) susirašinėjimą su VTEK specialistu.51.2. Turi būti galimybė susirašinėti tiek identifikuotiems tiek neidentifikuotiems PIR išorinės aplikacijos naudotojams.51.3. „Gyvo“ susirašinėjimo komponento naudotojo sąsajos sprendimas turi būti artimas „live chat“ tipinei vartotojo sąsajai.51.4. Identifikuotiems ir autorizuotiems PIR išorinės aplikacijos naudotojams bei VTEK darbuotojui turi būti galimybė peržiūrėti vykdytų unikalių susirašinėjimų sąrašą.51.4.1. Turi būti galimybė atlikti paiešką (filtravimą) susirašinėjimų sąraše. Paieškos kriterijai turi prasmingai atitikti sąrašo atributus. Paieškos formos laukai turi būti apibrėžti detalios analizės ar projektavimo etape.51.5. Identifikuotiems ir autorizuotiems PIR išorinės aplikacijos naudotojams bei VTEK darbuotojui turi būti galimybė atverti susirašinėjimą (peržiūrėti susirašinėjimo istoriją).51.6. Turi būti galimybė administravimo priemonėmis įjungti / išjungti „gyvo“ susirašinėjimo komponentą. Turi būti galimybė administravimo priemonėmis nustatyti laiką (laikotarpį) kada komponentas turi veikti / neveikti. Laikotarpio aprašymo sintaksė turi būti lygiavertė CRON sintaksei.51.7. Kiekvienas VTEK darbuotojas, turintis teises naudoti konsultavimo ir susirašinėjimo modulį, turi galėti peržiūrėti visus su VTEK darbuotojais vykdytus susirašinėjimus.


51.8. VTEK darbuotojo konsultavimo ir susirašinėjimo modulio funkcijos realizuojamos PIR vidinėje aplikacijoje, o kitų – PIR išorinėje aplikacijoje.

Paveikslas 12. PID paieškos ir peržiūros modulio panaudos atvejai

52. Reikalavimai PIR vidinės aplikacijos PID paieškos ir peržiūros moduliui52.1. VTEK darbuotojui turi būti galima atlikti visose pateiktose PID. Paieškos kriterijai turi prasmingai atitikti PID duomenų struktūrą. Paieškos formos laukai turi būti apibrėžti detalios analizės ar projektavimo etape.52.1.1. Turi būti galima išsaugoti sąrašo paieškos kriterijus jiems suteikiant pavadinimą. Turi būti galima pasirinktą išsaugotą paieškos kriterijų paketą panaudoti atliekant greitąjį sąrašo filtravimą. Sudarytas paieškos kriterijų paketas turi būti matomas tik tam naudotojui, kuris jį sudarė. Turi būti galima paieškos kriterijų paketą padaryti prieinama ir kitiems pasirinktiems PIR naudotojams.52.2. Turi būti galima eksportuoti PID paieškos rezultatų sąrašą į XLSX ir PDF rinkmenas. Prieš eksportuojant sąrašo reikšmes turi būti galima pažymėti, kurias sąrašo reikšmes eksportuoti į rinkmeną.52.3. Turi būti galima atverti PID peržiūrai.52.3.1. PID aplinkoje turi būti galima inicijuoti pateiktų duomenų sutikrinimą su išoriniuose registruose ir informacinėse sistemose esančiais duomenimis:52.3.1.1. Deklaruojančio asmens ir partnerio asmens duomenų pasikeitimus su GR duomenimis;52.3.1.2. Pareigų, narystės ir kt. pasikeitimus VATAR, LICREG, JADIS, JARIS duomenyse;52.3.1.3. Deklaruojančio asmens ir partnerio darbovietės duomenis su SODROS IS duomenimis;52.3.1.4. Deklaruojančio asmens ir partnerio ryšius su juridiniais asmenimis JAR ir JADIS registruose;52.3.1.5. Deklaruojančio asmens ir partnerio sandorius NTR, COR, KTPR, TSŽŪMPR, VVLR registruose;52.3.1.6. Deklaruojančio asmens ir partnerio individualią veiklą su GYPAS duomenimis.52.3.1.7. Gauti duomenys turi būti logiškai susiejami su PID, tačiau neturi būti atliekamas PID duomenų pakeitimas. Gauti duomenys turi būti matomi tik VTEK darbuotojui, kaip patikrinimo rezultatas.52.3.2. Turi būti galima inicijuoti pranešimo išsiuntimą deklaraciją pateikusiam asmeniui dėl atsiradusio poreikio patikslinti PID (dėl įvairių priežasčių: reikia atnaujinti PID duomenis; reikia pakeisti deklaracijos


viešumo statusą ar pan.). PIR turi suformuoti pranešimo turinį automatiškai bei turi būti galimybė VTEK darbuotojui papildyti pranešimo tekstą.52.3.2.1. Turi būti galima sudaryti ir išsiųsti laisvos formos pranešimą deklaruojančiam asmeniui ar jo įstaigos vadovui. Turi būti galima prie siunčiamo pranešimo pridėti rinkmenas. Turi būti galima peržiūrėti asmeniui išsiųstus pranešimus.52.3.2.2. Turi būti galima peržiūrėti išsiųstų pranešimų sąrašą, kuriame turi būti pateikiama: kada išsiųstas pranešimas, kam išsiųstas pranešimas, pranešimo išsiuntimo priežastis, pranešimas išsiųstas automatiškai ar inicijavus VTEK darbuotojui ir kt.

52.3.3. Turi būti galima sudaryti PID PDF rinkmeną.

Paveikslas 13. Deklaruojančių asmenų duomenų tvarkymo modulio panaudos atvejai

53. Reikalavimai deklaruojančių asmenų duomenų tvarkymo moduliui:53.1. VTEK darbuotojas turi galėti įvesti asmenį (sukurti registro objektą). Pagal pateiktus darbuotojo duomenis (vardą, pavardę, asmens kodą ar valstybės tarnautojo kodą) turi būti automatiškai gaunami duomenys iš GR ir panaudojami asmens kortelės sukūrimui. 53.1.1. VTEK darbuotojas turi galėti inicijuoti pranešimo išsiuntimą asmeniui dėl atsiradusio poreikio pateikti (atnaujinti) PID. PIR turi suformuoti pranešimo turinį automatiškai bei turi būti galimybė VTEK darbuotojui papildyti pranešimo tekstą.53.2. VTEK darbuotojui turi būti galimybė atlikti paiešką asmenų sąraše. Asmenų sąrašas turi būti sujungtas su asmens darbovietės duomenimis, kad būtų galimybė atlikti paiešką ir pagal detalius darbovietės duomenis. Sąraše turi būti aiškiai išskiriami darbovietės asmenys, kurie yra pateikę PID ir kurie nėra. Turi būti galimybė sudaryti įstaigų sąrašą, kuriose dirba asmenys turintys teikti PID, tačiau nėra pateikę. Turi būti galima matyti (gauti) įstaigos vadovo informaciją. Paieškos kriterijai turi prasmingai atitikti sąrašo duomenis. Kiekvieno sąrašo paieškos formos laukai turi būti apibrėžti detalios analizės ar projektavimo etape. Asmenų sąrašas gali būti skaidomas į atskirus, siekiant patogiai ir racionaliai pateikti informaciją analizei.


53.2.1. Turi būti galima išsaugoti sąrašo paieškos kriterijus jiems suteikiant pavadinimą. Turi būti galima pasirinktą išsaugotą paieškos kriterijų paketą panaudoti atliekant greitąjį sąrašo filtravimą. Sudarytas paieškos kriterijų paketas turi būti matomas tik tam naudotojui, kuris jį sudarė. Turi būti galima paieškos kriterijų paketą padaryti prieinama ir kitiems pasirinktiems PIR naudotojams.53.2.2. Turi būti galima eksportuoti asmenų paieškos rezultatų sąrašą į XLSX ir PDF rinkmenas. Prieš eksportuojant sąrašo reikšmes turi būti galima pažymėti, kurias sąrašo reikšmes eksportuoti į rinkmeną.53.3. Asmenų sąraše turi būti galima atverti peržiūrai asmens kortelę. Detalios analizės metu turi būti nustatyta, kokie duomenys turi sudaryti asmens kortelę.53.4. VTEK darbuotojas turi galėti atverti peržiūrai visas asmens pateiktas deklaracijas.53.5. VTEK darbuotojas turi galėti redaguoti asmens duomenis. Detalios analizės metu turi būti nustatyti kokia apimtimi gali būti redaguojami asmens duomenys.53.6. Turi būti galima pašalinti asmens duomenis iš PIR. Asmens duomenis galima pašalinti tik tuo atveju, jeigu asmuo niekada neturėjo prievolės ir teisės teikti PID.

Paveikslas 14. Tyrimų modulio panaudos atvejai

54. Reikalavimai tyrimų moduliui:54.1. Turi būti galima sukurti tyrimą įvedant tyrimo duomenis:54.1.1. Už tyrimą atsakingą VTEK darbuotoją (-us) – parenkant iš sąrašo;54.1.2. Tiriamojo asmens duomenis – turi būti galima susieti su PIR registruotais asmenimis;54.1.3. Apskritis, savivaldybė – parenkant iš klasifikatoriaus;54.1.4. Tiriamojo statusis pagal VPIDĮ ar LVĮ – parenkamas iš klasifikatoriaus;54.1.5. Darbovietė (-ės) – užpildoma pagal PIR objekto duomenis ar informacija, gauta iš SODROS IS. Turi būti galimybė laisva forma;54.1.6. Pareigos - užpildoma pagal PIR objekto duomenis;


54.1.7. Pranešėjo fizinio ar juridinio asmens duomenis – įvedami laisva forma;54.1.8. Požymis ar yra pranešėjo tarnybinis santykis su tiriamuoju;54.1.9. Tyrimo būsena – parenkama iš klasifikatoriaus;54.1.10. Pranešimo gavimo data;54.1.11. Tyrimo pradėjimo data;54.1.12. Tyrimo pabaigimo data;54.1.13. Tyrimo kryptis (-ys) – parenkama iš klasifikatoriaus, kuris sudarytas iš VPIDĮ ir LVĮ straipsnių;54.1.14. Subjektai, į kuriuos kreiptasi atliekant tyrimą – įvedama laisva forma;54.1.15. Raktiniai žodžiai – priskiriant raktažodžius turi būti galima pasirinki jau anksčiau panaudotus raktažodžius arba sukurti naujus;54.1.16. Pranešimo aprašymas – įvedamas laisva forma;54.1.17. Sprendimo aprašymas – įvedamas laisva forma bei pridedamas dokumentas;54.1.18. Sprendimas pagal VPIDĮ – parenkant iš klasifikatoriaus;54.1.19. Teismo sprendimas – parenkant iš klasifikatoriaus;54.1.20. Teismo (-ų) sprendimai – įvedami laisva forma;54.1.21. Kita – kiti duomenų įvedimo laukai ir elementai, kurie bus identifikuoti detalios analizės etape.54.2. Turi būti galima pažymėti, kad sprendimas yra viešas. Toks sprendimas turi būti prieinamas PIR išorinėje aplikacijoje „VTEK sprendimų paieškos ir peržiūros“ modulyje.54.3. Turi būti galima redaguoti tyrimo duomenis. Kiekvienas tyrimo duomenų pakeitimas ar redagavimas turi būti išsaugomas tyrimo veiksmų chronologijoje (audite).54.4. Turi būti galima į tyrimą įkelti su tyrimu susijusius dokumentus. Turi būtu galima įvesti įkeliamo dokumento metaduomenis. Detalios analizės etape turi būti apibrėžti metaduomenys.54.5. Turi būti galima peržiūrėti VTEK tyrimų sąrašą bei atlikti paiešką jame. Paieškos kriterijai turi prasmingai atitikti sąrašo duomenų struktūrą. Paieškos formos laukai turi būti apibrėžti detalios analizės ar projektavimo etape.54.6. Turi būti galima atverti tyrimą peržiūrai. Peržiūros režimu turi būti pateikiami visi tyrimo metaduomenys, dokumentai bei tyrimo veiksmų chronologija.54.7. Turi būti galima sudaryti pažymą apie tinkamumą eiti pareigas pagal politiko elgesio kodekso reikalavimus. Turi būti galima nurodyti kokius asmens pažeidimus ar kitą tyrimo informaciją įtraukti į sudaromą pažymą. Sudarytą pažymą turi būti galima išsaugoti prie asmens duomenų. Turi būti galima pažymą eksportuoti į DOCX ir PDF rinkmenas.

55. Reikalavimai administravimo moduliui:55.1. Turi būti galima administruoti PIR naudotojus:55.1.1. Sukurti VTEK naudoją, nurodant: vardą, pavardę, prisijungimo vardą, slaptažodį, galiojimo terminą, pareigas, priskirti struktūrinį padalinį ir kt.;55.1.2. Sukurti savivaldybės etikos komisijos nario naudotoją: vardą, pavardę, prisijungimo vardą, slaptažodį, galiojimo terminą, pareigas, savivaldybę ir kt.;55.1.3. Sustabdyti naudotoją;55.1.4. Suteikti PIR naudojimo roles ir (ar) teises.55.2. Turi būti galimybė vykdyti teisių ir rolių (teisių grupių) administravimą:55.2.1. PIR naudotojų teisės turi būti statiškos be galimybės jas keisti administravimo priemonėmis.55.2.2. Paslaugų teikėjas turi pateikti visų teisių aprašymus. Trumpi teisių aprašymai turi būti pateikiami ir PIR.55.2.3. Teisės turi būti priskiriamos naudotojų rolėms. Rolės turi būti priskiriamos naudotojams.55.2.4. Turi būti galimybė naudotojams priskirti ne tik roles, bet ir pavienes teises.55.2.5. Turi būti galimybė naudotojui pašalinti suteiktas roles ar teises.55.2.6. Turi būti galimybė sudaryti roles (teisių grupes), rolėms priskirti pavadinimus.55.2.7. Turi būti galimybė peržiūrėti ir tvarkyti teisių sąrašą ir rolių sąrašą.55.2.8. Tiekėjas turi sudaryti pradinius teisių ir rolių rinkinius, kurie atitiktų VTEK veiklos specifiką ir poreikius.56. Turi būti realizuotas funkcionalumas leidžiantis valdyti PIR naudotojų pavadavimą.57. Turi būti galimybė PIR naudotojui priskirti jį pavaduojantį kitą PIR naudotoją.


57.1. Naudotojui, kuriam priskiriama pavaduoti kitą naudotoją, turi būti suteikiamos priskirtojo naudotojo PIR rolės ir teisės, t. y. jis turi įgyti visas pavaduojamojo naudojot PIR funkcijas bei prieigą prie duomenų.57.2. Pavaduojančio naudotojo atliekami veiksmai už pavaduojamąjį naudotoją turi būti audituojami, kaip bet kurie kiti naudojo atliekami veiksmai. Audito įrašuose, kuriuose išsaugomi veiksmą atlikusio naudotojo duomenys, turi būti fiksuojama, kad veiksmą atliko pavaduojantysis naudotojas.57.3. Turi būti galimybė atšaukti pavadavimų priskyrimus. Pavadavimo priskyrimo atšaukimą gali įvykdyti pavaduojamas naudotojas arba administratorius.57.4. Registro naudotojui, kuris turi administratoriaus teises, pavadavimų priskyrimas ar jų atšaukimas turi būti neapribojamas, t.y. tokias teises turintis naudotojas gali atlikti bet kokį (logišką) pavadavimo priskyrimą ar jo atšaukimą.57.5. Turi būti galima tvarkyti PIR naudojamus klasifikatorius:57.5.1. Redaguoti esamų klasifikatorius reikšmes;57.5.2. Įvesti naujas esamų klasifikatorių reikšmes;57.5.3. Šalinti (padaryti nenaudojamais) esamas klasifikatoriaus reikšmes.57.6. Turi būti realizuoti šioje Techninėje specifikacijoje įvardinti klasifikatoriai. Klasifikatorių reikšmes, jeigu jos nėra specifinės VTEK veiklai, į PIR suveda Paslaugų teikėjas, o specifinius klasifikatorius – Užsakovas pateikia Paslaugų teikėjui, kad atliktų jų suvedimą į PIR.57.7. Turi būti galima keisti įvairius PIR sisteminius parametrus (terminus, adresus ir kt.), kurie bus identifikuoti ir apibrėžti projektavimo etape.

58. Reikalavimai statistinės analizės moduliui:58.1. Registre turi būti galimybė formuoti iš anksto apibrėžtas ataskaitas iš visų sistemoje kaupiamų duomenų.58.2. Turi būti galimybės formuoti šių tipų ataskaitas:58.2.1. Tipines (angl. relational model) – tai iš anksto parengtos formos ataskaitos, kuriose yra apibrėžtas dimensijų, atributų ir metrikų atvaizdavimas, t. y. kuriose vietose (stulpeliuose, eilutėse, ląstelėse) jie yra atvaizduojami ir apibrėžti galimi filtrai. Šiose ataskaitose iš principo naudotojui yra galimybė tik vykdyti ataskaitos filtravimą pagal nustatytus filtrus ir vykdyti detalizavimo (angl. drill-down) ar bendrinimo (angl. drill-up) funkcijas hierarchinėse dimensijose. Dažniausiai šios ataskaitos rengiamos lentelių forma. 58.2.2. Dimensines (angl. ad hoc reports) – kuriose naudotojas gali vykdyti ataskaitų modeliavimą (angl. pivoting), t.y. pasirinkti dimensijas, metrikas ir jų atvaizdavimo vietą (stulpeliuose, eilutėse, ląstelėse, filtruose), ataskaitos formą (diagrama, lentelė) ir vykdyti filtravimo, detalizavimo ir bendrinimo veiksmus. 58.2.3. Interaktyvias (angl. report to report) – kuriose turi būti iš anksto suformuotas duomenų, metrikų ir dimensijų rinkinys, jų pateikimo galimos formos bei naudotojui suteikta galimybė pereiti iš vienos ataskaitos formos į kitą, vykdyti filtrus, vykdyti detalizavimo, bendrinimo veiksmus. Interaktyvias ataskaitas turi būti galima persiųsti kaip naršyklėje veikiančią rinkmeną, veikiančią be ryšio su pagrindiniu duomenų šaltiniu (BI duomenų saugykla). 58.3. Tipinėse ataskaitose turi būti realizuotos šios galimybės:58.3.1. Į ataskaitą įtraukti visą esybę su savo atributais arba pasirinkti tik dalį jos atributų, tokiu būdu suteikiant galimybę analizuoti apibendrintą arba išskleistą vertinimo kriterijų informaciją (metrikas). Automatinėmis priemonėmis turi būti užtikrinama, kad ta pati esybė ar atributas nebus įtrauktas į ataskaitą daugiau nei 1 kartą;58.3.2. Formuoti nurodytų esybių ir pasirinktų atributų sąrašus, su galimybe eliminuoti pasikartojančius sąrašų duomenis;58.3.3. Generuoti grafines diagramas iš pasirinktų esybių ar jų atributų;58.3.4. Atlikti matematinius veiksmus su stulpelių reikšmėmis, t. y., skaičiuoti (angl. count), sudėti, atimti, dauginti, dalinti, rodyti procentinį santykį:58.3.4.1. Atliktų veiksmų rezultatai turi būti atvaizduojami naujai pridėtame stulpelyje;58.3.4.2. Naujai pridėto stulpelio pavadinimą turi būti leidžiama redaguoti;58.3.4.3. Duomenis turi būti galima filtruoti ir rūšiuoti pagal naujai pridėtą stulpelį;58.3.4.4. Turi būti galima išsaugoti atliktas modifikacijas kaip asmeninę ataskaitą (žr. 58.11 punktą);58.4. Turi būti galimybė į ataskaitą įkelti duomenis iš išorinės rinkmenos ir juos panaudoti formuojant ataskaitą.


58.5. Turi būti realizuota ne daugiau kaip 10 ataskaitų, kurios turi būti detalizuotos analizės metu su Perkančiąja organizacija.58.6. Dimensinėse ataskaitose turi būti šios galimybės:58.6.1. Išskleisti objektų detalumą iki žemiausio lygio pagal pasirinktos dimensijos hierarchiją, kurios taip pat gali būti sudarytos iš kitų dimensijų;58.6.2. Sukeisti eilučių ir stulpelių reikšmes vietomis;58.6.3. Generuoti grafines diagramas iš pasirinktų esybių ar atributų nustatytu laiko periodu;58.6.4. Turi būti galimybė sužinoti, kokias metrikas ir rodiklius galima apskaičiuoti pagal pasirinktą dimensiją.58.7. Interaktyviose ataskaitose turi būti realizuotos šios galimybės:58.7.1. Generuoti grafines diagramas iš pasirinktų esybių ar atributų nustatytu laiko periodu. Grafinės diagramos taip pat turi būti realizuotos interaktyviuoju principu, leidžiančiu „judėti“ per skirtingus detalumo (hierarchijos) lygius;58.7.2. Pasikeitus grafinės diagramos detalumo lygiui, atitinkami duomenys turi būti atvaizduoti lentelės pavidalo ataskaitoje, t. y., lentelėje ir diagramoje atvaizduojami duomenys turi būti neatsiejamai susieti.58.8. Visų tipų ataskaitose turi būti suteikta galimybė naudoti pilną Perkančiosios organizacinę struktūrą, panaudojant administravimo komponente suformuotą jų sąryšio logiką.58.9. Turi būti leidžiama keisti stulpelių išdėstymo seką visose ataskaitose.58.10. Turi būti galimybė atfiltruoti visų ataskaitų duomenų imtį tiek pagal visus ataskaitos stulpelius, tiek pagal papildomus ataskaitų filtrus, kuriuos Teikėjas turi apibrėžti kiekvienai ataskaitai detalios analizės metu.58.11. Kiekvienas naudotojas turi galėti išsaugoti ataskaitas, suformuotas pagal asmeninius nustatymus:58.11.1. Turi būti galimybė pasirinkti ataskaitos išdėstymo struktūrą (angl. layout) ir stilių, būtent:58.11.1.1. Nurodant duomenų atvaizdavimo būdą: sąrašas, lentelė, dimensinė ataskaita, diagrama, žemėlapis ir pan.;58.11.1.2. Pasirenkant formatavimo parametrus, tokius kaip spalvos, numeracija, paveiksliukai;58.11.1.3. Nurodant atskirų objektų išdėstymą skirtinguose lapuose.58.11.2. Turi būti galimybė pasirinkti konkrečias filtravimo reikšmes;58.11.3. Turi būti galimybė suformuotas ataskaitas išsaugoti paties susikurtuose aplankaluose;58.11.4. Turi būti galimybė nustatyti aplanko matymo teises;58.11.5. Jei keliose ataskaitose yra tas pats filtravimo laukas (pvz., data), išsaugota filtro reikšmė vienoje ataskaitoje neturi daryti įtakos kitos ataskaitos duomenų atvaizdavimui.58.12. Turi būti galimybė rūšiuoti visų ataskaitų duomenis pagal stulpelių reikšmes didėjimo ir mažėjimo tvarka (reikalavimas taikomas skaitinės ir tekstinės / klasifikatorių tipų laukams).58.13. Turi būti galimybė eksportuoti visas ataskaitas į HTML, CSV, XLSX, DOCX, PDF formatais:58.13.1. Turi būti eksportuoti tik atfiltruoti (ar paieškos rezultatuose pateikti) duomenys;58.14. Turi būti galima suformuoti ir bet kuriuo metu keisti šias grafinių diagramų rūšis: 58.14.1. Sritinis,58.14.2. Juostinis (angl. Bar chart),58.14.3. Stulpelinis (angl. Column chart),58.14.4. Linijinis (angl. Line chart),58.14.5. Skritulinis (angl. Pie chart),58.14.6. Taškinis (angl. Point chart),58.14.7. Burbulinis (angl. Bubble chart);58.14.8. Ganto (angl. Gantt chart).

59. Reikalavimai integracijoms su valstybės informacinėmis sistemomis ir registrais:


59.1. Paslaugų teikėjas turi suprojektuoti ir realizuoti integracines sąsajas su žemiau išvardintomis valstybės informacinėmis sistemomis ir registrais.59.2. Paslaugų teikėjas atsakingas už integracinių sąsajų specifikacijų sudarymą ir suderinimą su duomenų teikėjais. Už duomenų teikimo sutarčių sudarymą ir suderinimą atsakinga Perkančioji organizacija.59.3. Paslaugų teikėjas gali siūlyti alternatyvius žemiau pateiktų integracinių sąsajų realizavimo būdus (technologijas, apimtis ir kt.), jeigu jie niekaip neigiamai neįtakotų projekto tikslo, uždavinių ir galutinių rezultatų bei neprieštarautų pirkimus reglamentuojančių teisės aktų reikalavimams. Pasiūlytas alternatyvus integracijos realizavimo būdas turi užtikrinti lygiavertę ar geresnę sąsajos greitaveiką, aukštą prieinamumą, plečiamumą, interoperabilumą, palaikymą ir saugumą. Kiekvienas siūlomas alternatyvus integracijos realizavimo būdas turi būti suderinamas su Perkančiąja organizacija.59.4. Žemiau nurodytos sąsajų realizavimo technologijos (pvz., WS) gali būti keičiamos į kitas duomenų apsikeitimo technologijas jeigu projekto įgyvendinimo metu paaiškėja, kad nėra galimybės realizuoti WS sąsajų arba kitoks duomenų perdavimo būdas būtų efektyvesnis ir tinkamesnis siekiamam rezultatui užtikrinti.59.5. Sąsajų projektavimo ir kūrimo etape paaiškėjus galimybei iš informacinių sistemų ir registrų gauti daugiau reikiamų duomenų nei, kad nurodyta žemiau lentelėje, Paslaugų teikėjas turės realizuoti sąsajas tokiems duomenims gauti ir juos panaudoti PPID sudarymui arba asmenų, kurie turi teikti PID, identifikavimui.


Lentelė 3. PIR integracinių sąsajų realizavimo tikslai, apimtys ir būdai

Eil. nr. Institucija

Registras ar informacinė sistema

Gauti/ teikti Duomenys Technologija

59.6.

VĮ Registrų centras

JAR Gauti

59.6.1. Asmenys, kurie turi teikti PID:59.6.1.1. Duomenys apie Lietuvos banko darbuotojus, turinčius viešojo administravimo įgaliojimus (atliekantys finansų rinkos priežiūros, vartotojų ir finansų rinkos dalyvių ginčų nagrinėjimo ne teisme funkcijas ir kitas viešojo administravimo funkcijas).59.6.1.2. Duomenys apie akcinių bendrovių ir uždarųjų akcinių bendrovių, kurių akcijos, suteikiančios daugiau kaip 1/2 balsų visuotiniame akcininkų susirinkime, nuosavybės teise priklauso valstybei ar savivaldybei, vadovus ir vadovų pavaduotojus.59.6.1.3. Duomenys apie politinių partijų pirmininkus ir jų pavaduotojus. WS

59.7. JADIS Gauti

59.7.1. Asmenys, kurie turi teikti PID:59.7.1.1. Duomenys apie valstybės ar savivaldybių įmonių valdybų narius.59.7.1.2. Duomenys apie akcinių bendrovių bei uždarųjų akcinių bendrovių, kurių akcijos, suteikiančios daugiau kaip 1/2 balsų visuotiniame akcininkų susirinkime, nuosavybės teise priklauso valstybei ar savivaldybei, stebėtojų tarybų ir valdybų narius. WS

59.8. GR Gauti59.8.1. Asmens duomenys: vardas, pavardė, asmens kodas, deklaruota gyvenamoji vieta, pilietybė, sutuoktinio asmens duomenys. WS

59.9. NTR Gauti

59.9.1. Nekilnojamo turto duomenys preliminariai PID užpildyti:59.9.1.1. Unikalus nekilnojamo turto numeris;59.9.1.2. Sandorio šalys;59.9.1.3. Registravimo data;59.9.1.4. Vertė;59.9.1.5. Sandorio forma. WS

59.10. Valstybės tarnybos departamentas VATAR Gauti

59.10.1. Duomenys preliminarios PID užpildymui ir deklaruojančios asmens statuso nustatymui:59.10.1.1. Asmens pareigybės;59.10.1.2. Pareigybių klasifikatoriaus;59.10.1.3. Asmenys, pretenduojantys į pareigas valstybės tarnyboje (jei bus techninės galimybės);59.10.1.4. Valstybės politikai (jeigu bus techninės galimybės);59.10.1.5. Valstybės pareigūnai (jeigu bus techninės galimybės). WS

59.11. Civilinės aviacijos administracija COR Gauti 59.11.1. Orlaivių duomenys preliminarios PID užpildymui. WS

59.12. Valstybės įmonė REGITRA KTPR Gauti 59.12.1. Transporto priemonės duomenys preliminarios PID užpildymui. WS


Eil. nr. Institucija

Registras ar informacinė sistema

Gauti/ teikti Duomenys Technologija

59.13. LR Žemės ūkio ministerija TSŽŪMPR Gauti 59.13.1. Transporto priemonių duomenys preliminarios PID užpildymui. WS

59.14. LR Finansų ministerija

VBAMS Gauti59.14.1. Asignavimų valdytojų sąrašas, kuris turi būti naudojamas siekiant identifikuoti įstaigas, kurių darbuotojai turi teikti PID. WS

59.15. SFMIS Gauti59.15.1. Struktūrinių fondų lėšų gavėjų sąrašas, kuris turi būti naudojamas siekiant identifikuoti įstaigas, kurių darbuotojai turi teikti PID.. WS

59.16. VSAKIS Gauti

59.16.1. Valstybės biudžeto pinigus gaunančių įstaigų sąrašas (pagal viešojo sektoriaus atskaitomybės įstatymą), kuris turi būti naudojamas siekiant identifikuoti įstaigas, kurių darbuotojai turi teikti PID.. WS

59.17. VMI GYPAS Gauti

59.17.1. Preliminarios PID užpildymui:59.17.1.1. Duomenys apie asmeniui suteiktas ir gautas paskolas;59.17.1.2. Duomenys apie asmens individualią veiklą (pagal verslo liudijimą arba pažymą). WS

59.18. Lietuvos saugios laivybos administracija VVLR Gauti 59.18.1. Laivų duomenys preliminarios PID užpildymui. WS

59.19. SODRA SODRA IS Gauti59.19.1. Darbovietės duomenys PPID užpildymui ir deklaruojančios asmens statuso nustatymui WS

59.20. LR Vyriausioji rinkimų komisija

VRKIS Teikti 59.20.1. Kandidatų į politikus PID duomenys. WS59.21. VRKIS Gauti 59.21.1. Duomenys apie išrinktus valstybės politikus. WS

59.22. LR Seimas LRSVIS Gauti

59.22.1. Preliminarios PID užpildymui:59.22.1.1. Duomenys apie Valstybės politikų visuomeninius konsultantus, padėjėjus, patarėjus;59.22.1.2. Duomenys apie LR Seimo komitetų patvirtintus ekspertus. WS

59.23.

Valstybinė akreditavimo sveikatos priežiūros veiklai tarnyba prie Sveikatos apsaugos ministerijos SPĮLIS Gauti

59.23.1. Gydytojo, odontologo, farmacijos specialisto duomenys, siekiant identifikuoti asmenis, kurie turi teikti PID WS

59.24. LR Susisiekimo ministerija VIISP Gauti 59.24.1. VIISP priemonėmis identifikuoto asmens duomenys WS

59.25. Lietuvos bankas LITAS Gauti59.25.1. Preliminarios PID užpildymui:59.25.1.1. Duomenys apie asmeniui suteiktas ir gautas paskolas. WS


60. Reikalavimai duomenų teikimo sąsajoms ir jų administravimo funkcionalumui60.1. Turi būti realizuotos duomenų teikimo sąsajos, kurios pagal užklausą galėtų teikti registro objektus (asmenis, kurie turi teikti PID; PID), asmenims vykdytų tyrimų informaciją, pritaikytų nuobaudų informaciją ar surašytų administracinių teisės pažeidimų protokolų informaciją, kitą, projektavimo etapo metu suderintą PIR informaciją.60.2. Turi būti galima aukščiau punkte paminėtą informaciją gauti prenumeravimo (angl. subscribe) būdu, kai duomenų gavėjas per nustatytą laiko tarpą gauna Registro naujus ir atnaujintus duomenis be poreikio siųsti užklausą.60.3. Duomenų teikimo sąsajos turi būti projektuojamos ir kuriamos remiantis WS-S ar lygiavertėmis sąsajų saugumo specifikacijomis.60.4. Paslaugų teikėjas turi parengti duomenų teikimo sąsajų specifikaciją, kuria remiantis duomenų gavėjai galėtų kurti sąsajas duomenims iš PIR gauti.60.5. Turi būti sukurtas duomenų teikimo sąsajų administravimo funkcionalumas, kuris:60.5.1. Leistų tvarkyti duomenų gavėjų informaciją (informacinių sistemų ir registrų adresus, prisijungimo duomenis, sertifikatus ir kt.);60.5.2. Leistų pridėti ar išjungti sąsają su duomenų gavėjo sistema;60.5.3. Leistų nustatyti kokiomis sąsajų funkcijomis gali naudotis duomenų gavėjo sistema bei kokius Registro objekto ir kitus Registro duomenis gali gauti, pavyzdžiui nurodant konkrečius PID laukus bei PID būseną – vieša.

7.2.NEFUNKCINIAI REIKALAVIMAI7.2.1.Reikalavimų įgyvendinimas

61. Paslaugų teikėjas privalo realizuoti visus šios Techninės specifikacijos funkcinius ir nefunkcinius reikalavimus.62. Paslaugų teikėjas ar Perkančioji organizacija gali siūlyti alternatyvų atskiro Techninės specifikacijos reikalavimo įgyvendinimo būdą arba reikalavimo įgyvendinimo iškeitimą į lygiavertį funkcionalumą, kuris niekaip neigiamai neįtakotų projekto tikslo, uždavinių ir galutinių rezultatų bei neprieštarautų pirkimus reglamentuojančių teisės aktų reikalavimams. Kiekvienas siūlomas alternatyvus ar reikalavimą keičiantis funkcionalumas turi būti suderinamas su Perkančiąja organizacija bei tvirtinimas Reikalavimo pakeitimo, tikslinimo protokolu.63. Paslaugų teikėjas gali siūlyti alternatyvius architektūros realizavimo būdus, kurie užtikrintų lygiavertę ar geresnę Registro greitaveiką, aukštą prieinamumą, plečiamumą, interoperabilumą, palaikymą, saugumą ir patogumą. Kiekvienas siūlymas turi būti įvertintas ir patvirtintas Perkančiosios organizacijos.

7.2.2.Reikalavimai saugumui

64. Registras turi būti projektuojamas ir kuriamas atsižvelgiant į teisės aktų saugumo reikalavimus keliamus vidutinės svarbos informacijai. 65. Registre turi būti užtikrinamas saugumas programos lygmeniu, duomenų bazės lygmeniu, tinklo lygmeniu, aparatiniu lygmeniu.66. Įdiegta programinė įranga (kuriamos aplikacijos ar standartinė programinė įranga) negali turėti Open Web Application Security Project (OWASP) Top 10 periodiškai skelbiamame aktualiame dokumente ir ankstesnėse šio dokumento versijose nurodytų pažeidžiamumų.67. Sukurtas Registras turi būti apsaugotas nuo:67.1. neautentifikuotos prieigos;67.2. nesankcionuoto naudotojo sesijos perėmimo;67.3. nesankcionuoto duomenų perėmimo ar jų įterpimo;67.4. žalingo kodo įterpimo (angl. Injection, XSS (Cross-sitescripting));67.5. kitų saugumo pažeidimų, kurie įvardijami OWASP TOP 10 (https://www.owasp.org) periodiškai skelbiamame aktualiame dokumente ir ankstesnėse šio dokumento versijose nurodytų pažeidžiamumų.68. Aplikacijose turi būti numatyta apsauga nuo kenkėjiško kodo įkėlimo į aplikaciją (pavyzdžiui, apribota galimybė įkelti bylas su plėtiniais .com, .exe, .bat ir pan.).69. PIR Aplikacijų ryšys su darbuotojų darbo vietomis (interneto naršyklėmis ir/ar aplikacijomis) turi būti šifruojamas naudojant SSL (angl. Secure Socket Layer) arba kitas lygiavertes šifravimo priemones.


69.1. Paslaugų teikėjas turi pateikti ir įdiegti SSL sertifikatus, kuriuos interneto naršyklės laiko patikimais (angl. trusted).69.2. Priklausomai nuo Registro architektūros, Paslaugų teikėjas turi pateikti reikiamą kiekį sertifikatų, kuriuos naudojant bus atliekamas perduodamos / gaunamos informacijos šifravimas. 69.3. Šifravimui naudojamas sertifikatas turi būti patvirtintas kvalifikuotu sertifikatu (pavyzdžiui: Veri Sign ar analogišku), kurį populiariosios interneto naršyklės gali verifikuoti automatiškai, t. y. darbo vietos naudotojui neturi reikėti savarankiškai sertifikato įtraukti į naršyklės ar operacinės sistemos patikimų sertifikatų saugyklą.69.4. Paslaugų teikėjo pateiktas sertifikatas turi galioti ne mažiau nei tris metus. Pateikiamo sertifikato garantinis aptarnavimas (angl. support) turi būti užtikrinamas ne mažiau trims metams.69.5. Naudotojų prisijungimas prie PIR vidinių aplikacijų turi būti apsaugotas bent naudotojo vardu ir slaptažodžiu, o prisijungimas prie PIR išorinės aplikacijos turi būti realizuojamas per VIISP tapatybės nustatymo internete paslaugą.70. Turi būti vykdomas aplikacijose naudotojų atliekamų veiksmų auditavimas. Atliekant auditavimo įrašo išsaugojimą duomenų bazėje, turi būti kaupiama:70.1. Kas atliko veiksmą (naudotojas);70.2. Kada atliko veiksmą (data);70.3. Kokius duomenis atnaujino;70.4. Kokius duomenis įterpė;70.5. Kokius duomenis pašalino;70.6. Kokias paieškos frazes naudojo;70.7. Kita informacija, nustatyta analizės ir projektavimo etapų metu.71. Turi būti audituojami integracinėmis sąsajomis siunčiamų / gaunamų duomenų momentai, išsaugant informaciją:71.1. Iš kokios sistemos gaunami duomenys;71.2. Į kokią sistemą siunčiami duomenys;71.3. Duomenų gavimo/siuntimo data ir laikas;71.4. Siųsti/gauti duomenys (jeigu tam yra poreikis);71.5. Kita informacija, nustatyta analizės ir projektavimo etapų metu.72. Siekiant išvengti perteklinės auditavimo informacijos kaupimo tikslūs audito įrašų darymo momentai turi būti suderinti su Perkančiąja organizacija analizės ir projektavimo etapų metu.

7.2.3.Reikalavimai architektūrai

73. Architektūrinis sprendimas turi užtikrinti Registro aukštą prieinamumą (angl. High availability), kuris gali būti realizuojamas operacinių sistemų funkcionalumu, techninės įrangos galimybėmis ar kitos programinės įrangos pagalba. Aukštas prieinamumas turi būti realizuojamas paslaugų lygyje, integracijų lygyje ir duomenų lygyje.74. Aukšto prieinamumo sprendimai turi veikti automatiškai (incidentų atveju). Žmogaus įsitraukimas gali būti reikalingas tik Registro veikimą atstatant į būseną, kuri buvo prieš incidentą.75. Aukšto prieinamumo sprendimas turi būti aprašytas projektavimo dokumente ir patvirtintas Perkančiosios organizacijos.76. Paslaugų teikėjas turi pasiūlyti ir suderinti su Perkančiąja organizacija rezervinių kopijų darymo procesus, priemones ir taisykles. Atsarginių kopijų darymas turi būti vykdomas su šiuo metu Perkančiosios organizacijos eksploatuojama atsarginių kopijų darymo ir atstatymo įranga.77. Registras turi leisti atstatyti duomenis iš rezervinių duomenų kopijų. Paslaugų teikėjas turi pasiūlyti ir suderinti su Perkančiąja organizacija rezervinių kopijų atstatymo procesus, priemones ir taisykles.78. Registras turi atitikti plečiamumo principą, t.y., sistemos pajėgumus turi būti galima didinti papildant papildomą techninę įrangą ir / arba didinant esamos įrangos pajėgumus bei nekeičiant programinės įrangos išeities tekstų, programinė įranga neturi būti ribojantis veiksnys didinant našumą.79. Turi būti realizuoti sistemos ir jos komponentų veikimo stebėjimo ir išankstinio perspėjimo (angl. monitoringo) sprendimai. Sistemos administratoriaus teises turintiems naudotojams turi būti užtikrinta galimybė web priemonėmis stebėti sistemos bei atskirų jos komponentų veikimo rodiklius (aktyvūs


naudotojai, atminties panaudojimas, procesorių apkrova ir kiti svarbūs rodikliai) bei gauti parnešimus sutrikus komponentų veikimui ar rodikliams pasiekus kritines reikšmes.80. Įdiegti priemones, užtikrinančias centralizuotą žurnalinių įrašų (angl. logs) surinkimą iš visų sistemos kuriamų komponentų.

7.2.4.Reikalavimai programinei įrangai ir licencijoms

81. Paslaugų teikėjas, įvertinęs Perkančiosios organizacijos turimą standartinę programinę įrangą ir licencijas bei leidimus ją naudoti, privalo pateikti papildomą standartinę programinę įrangą ir licencijas reikalingas siūlomo Registro kūrimo sprendimo realizacijai, jeigu šioje techninėje specifikacijoje tokia programinė įranga ar licencijos nėra reikalaujamos, tačiau yra būtinos Registro kūrimo veikloms įgyvendinti (pavyzdžiui, aplikacijų serveriai, ataskaitų programinė įranga, programavimo karkasai (angl. framework) ar pan.).82. Paslaugų teikėjo pateikiama standartinė licencinė programinė įranga (angl. Commercial Off-The-Shelf Software), kuri reikalinga Registro veikimui, turi būti pateikiama kartu su visomis reikiamomis licencijomis, kad Perkančiajai organizacijai ne mažiau kaip 3 metus nereikėtų įsigyti papildomų licencijų (ar kitaip investuoti) programinės įrangos veikimui.83. Registro kūrimo sprendimo licencinė programinė įranga turi turėti ne mažiau 3 metų palaikymą: atnaujinimų parsisiuntimą ir diegimą, naujų komponentų pateikimą.84. Statistinės analizės modulio standartinė programinė įranga, jeigu yra licencijuojama, turi užtikrinti galimybę konstruoti ataskaitų logiką nemažiau dviem naudotojams ir ne mažiau kaip dviejose darbo vietose. Ataskaitų sudarymą pagal sukonstruotą ataskaitos logiką turi galėti atlikti ne mažiau kaip 30 naudotojų.85. Registro kūrimo sprendimo ne licencinės programinės įrangos naudojimas neturi būti apmokestinamas (naudotojų kiekiui, galimų registruoti naudotojų kiekiui, galimų transakcijų kiekiui ir pan.). 86. Jeigu siūloma standartinė licencinė programinė įranga yra licencijuojama priklausomai nuo Registrą naudojančių naudotojų (žmonių ar sistemų) kiekio, tarnybinių stočių parametrų ar pan., tai Paslaugų teikėjas turi pateikti licencijas, kurios užtikrintų racionalų ir efektyvų Registro veikimą ir naudojimą.87. Visi reikalingos programinės įrangos kaštai turi būti įskaičiuoti į pasiūlymą.88. Visos reikalingos licencijos turi būti įgyjamos Perkančiosios organizacijos vardu. Perkančiajai organizacijai turi būti perduotos visos Registro veikimui reikalingos licencijos. Pateikiamų licencijų (ir sertifikatų) galiojimo pradžia turi būti ne ankstesnė nei bandomosios eksploatacijos etapo pradžia ir ne vėlesnė nei garantinės priežiūros etapo pradžia.89. Paslaugų teikėjas gali pasiūlyti lygiavertę Registrui reikalingą programinę įrangą. Teikdamas lygiavertę programinę įrangą turi detalizuoti siūlomos programinės įrangos lygiavertiškumą architektūriniu, funkciniu, licencijavimo, plečiamumo, prieinamumo, valdymo, diegimo, atstatomumo, našumo, pernešamumo, gedimų tolerantiškumo, interoperabilumo, eksploatavimo, saugumo, palaikomumo, panaudojamumo (patogumo naudotis) požiūriu.90. Siūlomos programinės įrangos lygiavertiškumo deklaravimas ir detalizavimas turi būti pateikiamas Paslaugų teikėjo pasiūlyme. Pasiūlymo vertinimo metu bus priimamas sprendimas dėl siūlomos programinės įrangos lygiavertiškumo. Paslaugų teikėjų pasiūlymai, kuriuose siūloma nelygiavertė programinė įranga, bus atmetami.

7.2.5.Reikalavimai naudotojo sąsajai

91. Registro komponentų naudotojo sąsaja turi būti prieinama naudojant interneto naršyklę (išimtys gali būti taikomos standartinei licencinei programinei įrangai (ataskaitų ir statistikos programinei įrangai, duomenų bazių administravimo programinei įrangai ir pan.)).92. PIR išorinė aplikacija turi būti konstruojama „responsive web design“ principais. Detalios analizės metu turi būti nustatyta, kurios PIR funkcijos turi būti pasiekiamos naudojant mobilius įrenginius (žemesnės raiškos ekranus), o kurios – naudojant kompiuterį (aukštesnės raiškos ekranus).93. Per interneto naršyklę pasiekiami Registro komponentai turi vienodai funkcionuoti bei būti atvaizduojami su Perkančiąja organizacija suderintose interneto naršyklėse. Preliminariai Registrasturi veikti šiose interneto naršyklėse:


93.1. Microsoft Internet Explorer;93.2. Microsoft Edge;93.3. Mozilla Firefox;93.4. Google Chrome.94. Regstro komponentų naudotojo sąsaja turi būti realizuota lietuvių kalba. Kalba turi būti naudojama laikantis bendrinių lietuvių kalbos taisyklių. Registro administratoriams skirtos programinės priemonės (pvz., Administravimo aplikacija) ir pranešimai turi būti lietuvių ar anglų kalba.95. Naudotojų sąsajos klaidų pranešimai turi būti suformuluoti taip, kad naudotojui būtų aišku, kas atsitiko ir kokius veiksmus jam toliau reikia atlikti, kad galėtų tęsti darbą.96. Paslaugų teikėjas privalo užtikrinti Registro korektišką veikimą tiksliai apdorojant ir išsaugant lietuvių kalba įvedamus duomenis.97. Registro komponentų naudotojo sąsaja turi būti intuityvi, suprantama ir nesudėtinga naudoti naudotojams, turintiems reikalaujamą kompiuterinio raštingumo lygį (ECDL ar aukštesnį), bei atitikti šiuolaikinius ergonomikos reikalavimus. 98. Siekiant užtikrinti šiuolaikinius naudotojų sąsajos ergonomikos reikalavimus, rekomenduojama vadovautis LST EN ISO 9241-110:2006 „Žmogaus ir sistemos sąveikos ergonomika. 110 dalis. Dialogo principai (ISO 9241-110:2006)“ standartu arba lygiaverčiu. 99. Registro komponentų, pasiekiamų per interneto naršyklę, naudotojo sąsaja turi atitikti W3C XHTML arba lygiavertę specifikaciją ir turi būti naudojama ne žemesnė kaip 1.0 W3C XHTML arba lygiavertė versija. Realizavimui turi būti naudojama ne žemesnė kaip 2 lygio CSS2 arba lygiavertė technologija (Cascading Style Sheets Language 2, www.w3.org/Style/CSS/).100. Naudotojų sąsajos valdymas turi remtis pelės ir klaviatūros įrenginiais.101. Turi būti realizuotas naudojimo patogumą užtikrinantis funkcionalumas:101.1. TAB klavišo seka einant per duomenų įvedimo laukus;101.2. Užuominų ir paaiškinimų pateikimas pelės žymeklį užvedus ant grafinio objekto.102. Duomenų įvedimo formose duomenų laukai turi būti užpildomi automatiškai, jeigu Registre yra saugomi atitinkami duomenys.103. Paslaugų teikėjas turi suderinti naudotojo sąsajos grafinį dizainą su Perkančiąja organizacija analizės ir projektavimo etapo metu.104. Paslaugų teikėjas turi suderinti naudotojo sąsajos grafinį dizainą su Perkančiąja organizacija analizės ir projektavimo etapo metu. Naudotojo sąsajos vaizdai turi būti pateikiami eskizais ar prototipais. Priėmimo testavimo ir bandomosios eksploatacijos metu Paslaugų teikėjas turės atlikti visus naudotojo sąsajos pakeitimus, jeigu to bus reikalaujama.105. Duomenų sąrašai turi būti:105.1. Puslapiuojami, su galimybe nurodyti kiek sąrašo puslapyje rodyti eilučių;105.2. Filtruojami pagal sąrašui aktualius kriterijus. Paslaugų teikėjas, detalios analizės metus, turės identifikuoti kiekvieno sąrašo filtravimo kriterijus ir juos realizuoti;105.3. Rikiuojami pagal sąrašo rikiuotinus elementus;105.4. Eksportuojami į rinkmenas (.pdf, .docx, .xlxs ar lygiavertes). Detalios analizės metu turi būti nustatyta, kuriems sąrašams yra reikalinga pastaroji funkcija.105.5. Atveriami spausdinimo režimu. Detalios analizės metu turi būti nustatyta, kuriems sąrašams yra reikalinga pastaroji būsena.106. Registre kuriamiems įrašams turi būti realizuojamos veiklos taisykles tenkinančios tų įrašų redagavimo, trynimo, anuliavimo funkcijos.107. Registre turi būti indikuojami ilgiau trunkantys procesai (funkcijos), kad naudotojui būtų aišku, jog Registras veikia ir nėra būtinybės iškviesti tų pačių funkcijų keletą kartų.108. Reikalavimai naudotojų informavimui:108.1. Naudotojui pateikiami pranešimai turi būti suformuluoti taip, kad naudotojui būtų aiški pranešimo pateikimo priežastis. Informacija apie pranešimo pateikimą sąlygojančią priežastį privalo būti pateikiama nurodant konkrečius Registro duomenų objektus (pavyzdžiui, laukų pavadinimus).108.2. Naudotojui pateikiamame klaidos pranešime privalo būti nurodoma, kokius veiksmus naudotojas privalo atlikti tam, kad galėtų pašalinti pranešimo pateikimo priežastis ir tęsti darbą su Registru.


108.3. Naudotojui turi būti pateikiami sėkmės pranešimai, nurodantys, kad naudotojo atlikti veiksmai yra sėkmingi (pavyzdžiui, informuojama, kad įrašas išsaugotas / ištrintas / pakoreguotas, duomenys sėkmingai įkelti ir pan.).108.4. Klaidų pranešimai, sėkmės pranešimai ir informaciniai pranešimai turi būti išskirti skirtingomis spalvomis ar skirtingais simboliais, kad vizualiai būtų galima atskirti.108.5. Jeigu naudotojui atlikus veiksmus rezultatai turės didelės įtakos, prieš atliekant veiksmą Registras turi pateikti pranešimą ir paprašyti naudotojo patvirtinti, kad tikrai norima vykdyti.109. Naudotojui turi būti pateikiamos pagalbos priemonės padedančios greičiau išmokti naudotis Registru (pavyzdžiui, pagalbos mygtukai, naudotojo vadovas).

7.2.6.Reikalavimai greitaveikai ir našumui

110. PIR išorinės aplikacijos realizacija turi užtikrinti, kad kai su Registru vienu metu dirba 3000 naudotojų ir kiekvienas naudotojas kas 5 sekundes atlieka atsitiktinį veiksmą, atsakas (naudotojo naršyklės priimti HTTP paketai) neturi viršyti 3 sekundžių. Galimi išimtiniai atvejai, kurie turi būti suderinti su Perkančiąja organizacija (pvz., ataskaitų generavimas, duomenų importavimas ar eksportavimas ir kt.).111. PIR vidinės aplikacijos realizacija turi užtikrinti, kad kai su Registru vienu metu dirba 3000 naudotojų ir kiekvienas naudotojas kas 5 sekundes atlieka atsitiktinį veiksmą, atsakas (naudotojo naršyklės priimti HTTP paketai) neturi viršyti 2 sekundžių. Galimi išimtiniai atvejai, kurie turi būti suderinti su Perkančiąja organizacija (pvz., ataskaitų generavimas, duomenų importavimas ar eksportavimas ir kt.).112. Tinklinių sąsajų (WS ar RESTful) realizacija turi užtikrinti, kad projektavimo metu apibrėžti integraciniai scenarijai įvyks per racionalų laiko tarpą ir niekaip neigiamai neįtakos PIR išorinės ir vidinės aplikacijos naudojimo patogumo ir našumo.113. Priėmimo testavimo etapo metu (ar kitų sutartu metu) Paslaugų teikėjas turi sudaryti visas reikiamas sąlygas Perkančiosios organizacijos atstovų specialistams, kurie atliks našumo ir greitaveikos testavimą. Esant poreikiui Paslaugų teikėjas turės atlikti konfigūravimo ar programavimo darbus, kurie bus būtini siekiant išbandyti PIR našumą įvairiais jos naudojimo scenarijais. Paslaugų teikėjas neturės pateikti jokios programinės ar techninės įrangos, skirtos našumo ir greitaveikos testavimo vykdymui. 114. Paslaugų teikėjas turės atlikti reikiamus Registro programavimo ir / ar konfigūravimo darbus, atsižvelgiant į Perkančiosios organizacijos atstovų atliktų našumo ir greitaveikos testavimų rezultatus, jeigu testų rezultatai netenkins aukščiau punktuose įvardintų našumo ir greitaveikos reikalavimų.

7.2.7.Reikalavimui duomenų migravimui

115. Iš PIDTIS į PIR turi būti sumigruotos dabartinės PID.116. Į PIR turi būti sumigruoti Skaidrumas duomenys (VTEK vykdyti ir vykdomi tyrimai).117. Į Registrą iš išorinių sistemų ir registrų turi būti importuoti pradiniai duomenys (angl. initial data), kurie reikalingi Registro veikimui. Tiksli pradinių duomenų apimtis turi būti nustatyta detalios analizės metu.118. Duomenų migravimas turi būti dokumentuotas. Paslaugų teikėjas, prieš atlikdamas duomenų migravimą, turi pateikti duomenų migravimo procedūros aprašą.

7.2.8.Reikalavimai duomenų kokybei

119. Turi būti užtikrinamas perduodamų / gaunamų duomenų vientisumas ir integralumas.120. Registro naudotojo sąsaja privalo palaikyti personalizuotas (pagal naudotoją bei naudotojo teises) darbo sritis. Naudotojo darbui nereikalingas funkcionalumas neturi būti matomas arba neturi būti aktyvus.121. Duomenys, prie kurių naudotojas neturi prieigos teisių, naudotojui privalo būti nepateikiami naudotojo sąsajoje.122. Naudotojo sąsajos elementai, kurie remiantis Registre įgyvendinta logika negali būti panaudojami, privalo būti išjungiami (angl. disabled).123. Registras turi neleisti naudotojui atlikti veiksmų, kurie gali sukelti Registro trikdžius.124. Registro vidinės bei išorinės nuorodos ir kitos sąsajos turi užtikrinti, kad būtų pasiekiamas norimas turinys ar iššaukiama pageidaujamų funkcijų grupė, pasirinkus atitinkamą nuorodą. Kiekviena nuoroda turi vesti naudotoją prie norimo turinio arba iššaukti norimų funkcijų seką.


125. Turi būti teisingai ir tiksliai vaizduojamas turinys (duomenys neiškraipomi, atvaizduojami).126. Paieškos mechanizmas turi grąžinti tikslius paieškos rezultatus, turėti pabaigą.127. Turi būti numatyta Registro duomenų bazės automatinio atsarginio kopijavimo galimybė.

7.2.9.Reikalavimai testavimo ir eksploatavimo aplinkoms

128. Testavimo aplinka turės būti sukurta įsigyjamos įrangos pagrindu. 129. Architektūriniai testinių aplikacijų diegimo sprendimai turi būti suderinti su Perkančiąja organizacija.130. Testinės aplinkos diegimas neturi užtikrinti testinės aplinkos aukšto prieinamumo.131. Eksploatavimo aplinka turi būti konstruojama atsižvelgiant į šios Techninės specifikacijos reikalavimus Registro architektūrai, aukštam prieinamumui, saugumui ir kt.

7.2.10. Reikalavimai testavimui

132. Turi būti atliktas Registro priėmimo testavimas. Turi būti testuojamas naujai sukurtas funkcionalumas bei funkcionalumas, kuris buvo modernizuotas (pakeistas) dėl naujai sukurto funkcionalumo.133. Testavimo tikslai:133.1. įsitikinti, kad yra įgyvendinti visi funkciniai ir nefunkciniai techninės specifikacijos reikalavimai;133.2. įsitikinti, kad reikalavimų įgyvendinimas atliktas tinkama apimtimi;133.3. nustatyti ar reikalavimų įgyvendinimas tenkina Perkančiąją organizaciją ir kitas suinteresuotas šalis;133.4. identifikuoti ir užregistruoti funkcionalumo klaidas (angl. bugs).134. Turi būti atlikti šie testavimai:134.1. Vidinis testavimas. Vidinius atskirų komponentų testavimus Paslaugų teikėjas turi atlikti nedalyvaujant Perkančiosios organizacijos atstovams, tačiau turi pateikti tokio testavimo įrodymus – vidinio testavimo ataskaitą ir nustatytų neatitikimų sąrašą.134.2. Priėmimo testavimas (angl. acceptance testing). Šis testavimas turi būti atliekamas dalyvaujant Paslaugų teikėjui, Perkančiajai organizacijai ir kitoms suinteresuotoms šalims. Šio testavimo metu turi būti tikrinamas testavimo tikslų įgyvendinimas (įgyvendinimo lygio nustatymas). Priėmimo testavimo veiklos turi būti vykdomos remiantis apibrėžta priėmimo testavimo metodika bei priėmimo testavimo planu.135. Atliktas testavimas turi užtikrinti, kad Registras yra tinkamas eksploatavimui.136. Priėmimo testavimo metu turi būti vykdomas identifikuotų klaidų (problemų) registravimas. 136.1. Testavimo metu elektronine forma turi būti vedamas pastebėtų klaidų (problemų) ir jų būsenų kaupimo žurnalas. Paslaugų teikėjas turi pateikti tokį įrankį, kuris nuolatos būtų prieinamas internetu Perkančiosios organizacijos atstovams.136.2. Klaidų žurnalas turi būti specializuota problemų registravimo ir sekimo programinė įranga (angl. issue tracking software), paremta tinklinėmis technologijomis, t. y. pasiekiama naudojant interneto naršyklę.137. Paslaugų teikėjas turės parengti visus testavimui reikalingus testavimo duomenis.137.1. Paslaugų teikėjas turės užtikrinti, kad priėmimo testavimo metu Registre bus suvesta (importuota) pakankamai testinių duomenų, kurie leistų pilnai ištestuoti Registro funkcionalumą.138. Priėmimo testavimas turi būti vykdomas Perkančiosios organizacijos įsigytos techninės įrangos pagrindu. Jeigu priėmimo testavimo metu nebus tokios galimybės, testavimas turės būti vykdomas naudojant Paslaugų teikėjo pateiktą techninę įrangą (jos pagrindu veikiančią testinę aplinką). Tokiu atveju turės būti atliktas atskiras testavimas Perkančiosios organizacijos pateiktoje techninėje įrangoje siekiant įsitikinti, kad Registras korektiškai veikia kitos techninės įrangos pagrindu.139. Paslaugų teikėjas turi įdiegti Registro testavimo aplinką, kai Perkančioji organizacija sudarys tam technines ir organizacines sąlygas. Testinėje aplinkoje turi būti naudojami depersonalizuoti duomenys. Turi būti įgyvendintos integracinės sąsajos su integruotinų išorinių sistemų testinėmis aplinkomis (jeigu tokios yra).140. Testavimo aplinkos architektūros principai turi atitikti numatomos darbinės Registro aplinkos architektūrą.141. Galutinį priėmimo ir integracinius testavimus Paslaugų teikėjas turi vykdyti stebint Perkančiosios organizacijos atstovams. Paslaugų teikėjas turi užtikrinti reikiamas sąlygas sėkmingam Registro testavimui atlikti.


142. Priėmimo testavimas bus užbaigiamas, kai bus tenkinami testavimo plane įvardinti testavimo priėmimo kriterijai.

7.2.11. Reikalavimai įdiegimui gamybinėje aplinkoje

143. Paslaugų teikėjas turės įdiegti Registrą į Perkančiosios organizacijos pateiktą techninę įrangą bei atlikti techninės ir programinės įrangos konfigūravimo darbus, kad būtų užtikrintas tinkamas Registro darbinės aplinkos veikimas.144. Paslaugų teikėjas po bandomosios eksploatacijos turi perduoti Perkančiajai organizacijai sukurto Registro išeities kodą ir licencinės programinės įrangos instaliacinius paketus. 145. Paslaugų teikėjas turi įdiegti priemones, užtikrinančias automatinį naujų sistemos versijų diegimą, užtikrinant jos veikimą diegimo metu.146. Turi būti realizuoti sprendimai, kad programinio kodo, aplikacijų, duomenų bazių atnaujinimas reikiamose aplinkose būtų atliekamas be papildomų naudotojo veiksmų147. Registro išeities kodas turi būti pateikiamas Paslaugų teikėjo naudotoms kūrimo priemonėms suprantamu formatu įrašytas į DVD ar kitą skaitmeninę laikmeną. Kartu turi būti pateikiamas sukompiliuotas išeities kodas (parengtas diegimui).148. Paslaugų teikėjas turi dokumentuoti programinės įrangos diegimo į Perkančiosios organizacijos Registro darbinę ir testinę aplinkas procesą bei pateikti tam reikalingas programines priemones. Procesas turi būti dokumentuotas taip, kad:148.1. Atsakingas Perkančiosios organizacijos darbuotojas iš pateiktų išeities tekstų galėtų pagaminti (angl. build) programinę įrangą bei valdyti gaminimo konfigūraciją.148.2. Atsakingas Perkančiosios organizacijos darbuotojas programinę įrangą galėtų įdiegti į testinę ir darbinę aplinką bei valdyti diegimo konfigūraciją.

7.2.12. Reikalavimai mokymams

149. Paslaugų teikėjas turi atlikti Registro naudotojų mokymus. Turi būti apmokyti:149.1. Ne mažiau kaip 10 Perkančiosios organizacijos nurodyti asmenys darbui su PIR vidinės aplikacijos funkcionalumu;149.2. Ne mažiau kaip 2 Perkančiosios organizacijos administratorius darbui su PIR administravimo komponentais ir PIR standartinės programinės įrangos administravimu.150. Apmokymai vedami lietuvių kalba Perkančiosios organizacijos patalpose ir Perkančiosios organizacijos darbo valandomis.151. Mokymų metu naudotojau turi būti apmokyti dirbti su visu PIR funkcionalumu. Atlikti apmokymai turi sudaryti galimybę naudotojui su PIR dirbti savarankiškai.152. Paslaugų teikėjas turi parengti mokymų planą ir mokymų medžiagą.

7.2.13. Reikalavimai bandomajai eksploatacijai

153. Turi būti atlikta Registro bandomoji eksploatacija.154. Bandomosios eksploatacijos tikslai: 154.1. užtikrinti Registro kokybę;154.2. išbandyti gamybinę Registro komponentų konfigūraciją;154.3. identifikuoti ir pašalinti bandomosios eksploatacijos metu pastebėtus defektus;154.4. stabilizuoti darbinės aplinkos konfigūraciją, atsižvelgiant į bandomosios eksploatacijos metu sukauptą patirtį.155. Bandomosios eksploatacijos veiklas Paslaugų teikėjas turės vykdyti pagal Perkančiosios organizacijos pateiktą bandomosios eksploatacijos planą.156. Paslaugų teikėjas, iki bandomosios eksploatacijos pradžios, privalo paruošti Registro infrastruktūrą darbui:156.1. Atlikti Registro komponentų konfigūravimą, kad visi bandomosios eksploatacijos dalyviai turėtų galimybę prisijungti prie Registro iš savo darbo vietų. Naudotojų darbo vietų parengimą užtikrins


Perkančioji organizacija. Paslaugų teikėjas turi pateikti rekomendacijas dėl naudotojų darbo vietų paruošimo.156.2. Sumigruoti (suvesti) visus būtinus Registro duomenis bei pašalinti perteklinius (bandomajai eksploatacijai nereikalingus) duomenis. Privalo užtikrinti, kad visi duomenys Registre būtų integralūs.157. Paslaugų teikėjas privalo užtikrinti Registro veikimą visos bandomosios eksploatacijos metu, jeigu nebus sutarta kitaip.158. Bandomosios eksploatacijos aplinka turi būti realizuota darbinėje aplinkoje, jeigu nebus sutarta kitaip.159. Bandomoji eksploatacija yra baigiama, kai tenkinami bandomosios eksploatacijos priėmimo kriterijai, kurie pateikiami bandomosios eksploatacijos plane.

7.2.14. Reikalavimai garantijai ir priežiūrai

160. Paslaugų teikėjas privalės užtikrinti įdiegtos programinės įrangos (aplikacijų, duomenų bazių ir kt.) garantinę priežiūrą.161. Garantinės priežiūros terminas 36 mėnesių nuo galutinio paslaugų priėmimo–perdavimo akto pasirašymo datos.162. Garantinės priežiūros paslaugos apima sukurtos ir modernizuotos programinės įrangos sutrikimų šalinimą bei Perkančiosios organizacijos atsakingų asmenų konsultavimą.163. Paslaugų teikėjas turi vykdyti Perkančiosios organizacijos atsakingų asmenų konsultavimą Registro veikimo, naudojimo bei tobulinimo klausimais. Konsultacijos turi būti teikiamos telefonu, el. paštu, naudojant priežiūros tarnybos (angl. Help Desk) programinę įrangą ar atvykus į Perkančiąją organizaciją.164. Paslaugų teikėjas turi teikti skubią pagalbą įsilaužimo atveju ir užtikrinti Registro informacijos atstatymą per Perkančiosios organizacijos nurodytą laikotarpį po pranešimo užregistravimo.165. Programinės įrangos veikimo sutrikimu laikoma situacija, kai Registro naudotojai dėl Paslaugų teikėjo sukurtos programinės įrangos funkcionalumo trūkumų negali atlikti numatytų Registro funkcijų ar funkcijos veikia nekorektiškai. 166. Programinės įrangos sutrikimų atstatymo trukmė:166.1. Reakcijos į sutrikimą laikas – ne ilgiau kaip 1 (viena) darbo valanda nuo pranešimo apie sutrikimą gavimo sutartu būdu;166.2. Programinės įrangos veikimo sutrikimai turi būti pašalinti per tokį laiką, kad darbas informacinės Registro naudotojams nesutriktų ilgiau negu 16 valandų. Jei sutrikimo per nurodytą laiką pašalinti negalima, kartu su Perkančiąja organizacija suderinamas susitarimas dėl sutrikimo pašalinimo laiko;166.3. Neesminių sutrikimų šalinimas – ne ilgiau kaip 5 darbo dienos nuo pranešimo gavimo sutartu būdu. Jei sutrikimo per nurodytą laiką pašalinti negalima, kartu su Perkančiąja organizacija suderinamas susitarimas dėl sutrikimo pašalinimo laiko. Neesminis sutrikimas – kosmetinės ar panašios Registro klaidos, kurios neįtakoja korektiško funkcijų veikimo;166.4. Svarbių sutrikimų šalinimas – ne ilgiau kaip 3 darbo dienos nuo pranešimo gavimo sutartu būdu. Jei sutrikimo per nurodytą laiką pašalinti negalima, kartu su Perkančiąja organizacija suderinamas susitarimas dėl sutrikimo pašalinimo laiko. Svarbus sutrikimas – neapibrėžtas funkcijos veikimas, kuris leidžia įvykdyti numatytą Registro funkciją, tačiau naudotojui reikia atlikti papildomus, nenumatytus ar alternatyvius veiksmus;166.5. Kritinių sutrikimų šalinimas – ne ilgiau kaip 1 darbo diena nuo pranešimo gavimo sutartu būdu. Jei sutrikimo per nurodytą laiką pašalinti negalima, kartu su Perkančiąja organizacija suderinamas susitarimas dėl sutrikimo pašalinimo laiko; Kritinis sutrikimas – funkcijos neveikimas, be galimybės reikiamą funkciją įvykdyti alternatyviai.167. Paslaugų teikėjas turi parengti prieinamas ir Perkančiajai organizacijai tinkamas informavimo apie Registro sutrikimus, jų registravimo ir taisymo veiksmų būseną priemones: Perkančiosios organizacijos ir Paslaugų teikėjo suderintus telefonus, e. pašto adresus, garantinio aptarnavimo ir priežiūros tarnybos programinio įrankio adresą (nuorodą). Išvardintais būdais Perkančiosios organizacijos atsakingiems asmenims turi būti galimybė pranešti apie Registro sutrikimus, reikiamas konsultacijas, reikiamus tobulinimus (naujo funkcionalumo kūrimą) ir pan.168. Garantinės priežiūros paslaugos, konsultacijos telefonu ir elektroniniu paštu turi būti teikiamos Perkančiosios organizacijos darbo dienomis darbo valandomis.


7.3.REIKALAVIMAI PASIŪLYMAMS

169. Paslaugų teikėjas turi aprašyti kiekvieno Registro komponento realizavimo būdą, pateikdamas sprendimo architektūros aprašymą, planuojamus naudoti projektinius sprendimus ir įvardindamas kitus, su komponentų realizavimu susijusius ypatumus. Architektūra ir projektiniai sprendimai turi būti iliustruoti schemomis (diagramomis, paveikslėliais, brėžiniais), naudojant standartizuotą modeliavimo notaciją (pvz.: UML, BPMN, SysML ar kt.). Turi būti aprašyti ir schemomis pademonstruoti komponentų tarpusavio ryšiai, sąveikos būdai ir jų integravimas su vidinėmis ir išorinėmis sistemomis.170. Paslaugų teikėjas turi nurodyti kiekvieno diegiamo modulio realizavimo būdą – bus naudojama standartinė programinė įranga (angl. Commercial off-the-shelf) ar bus kuriama (programuojama) nauja programinė įranga.171. Paslaugų teikėjas privalo įvardinti visą planuojamą naudoti (siūlomą) standartinę programinę įrangą (angl. Commercial off-the-shelf), turi pateikti jos gamintojų pavadinimus, programinės įrangos pavadinimus, įvardinti tikslias versijas, turi pateikti nuorodas į programinės įrangos išsamų aprašymą (specifikaciją) gamintojo interneto svetainėje arba pateikti aprašymą (specifikacijas). 172. Paslaugų teikėjas privalo nurodyti naujai kuriamai (programuojamai) programinei įrangai planuojamas naudoti technologijas (aplikacijų serverius, karkasus (angl. framework), programavimo kalbas, programinio kodo bibliotekas ir kt.).

7.4.BAIGIAMOSIOS NUOSTATOS

173. Galutinis Registro priėmimas bus vykdomas pasibaigus bandomajai eksploatacijai, t. y. priėmimas galės būti vykdomas tik tada, kai bus pasiekti bandomosios eksploatacijos priėmimo kriterijai.174. Registras bus priimamas pasirašant priėmimo-perdavimo aktą.175. Siekiant užtikrinti sklandų Projekto tęstinumą:175.1. Paslaugų teikėjas, nepažeidžiant autoriaus teisių turėtojo ar trečiųjų šalių intelektinės nuosavybės teisių, sutartimi perduoda Perkančiajai organizacijai autorių turtines teises į pagal užsakymą sukurtą programinę įrangą ir parengtus projektinius dokumentus, įskaitant, bet neapsiribojant, teisę neribotą laiką ir be papildomo atlygio naudoti sukurtą programinę įrangą; teisę daryti sukurtos programinės įrangos kopijas; teisę modifikuoti ir toliau plėtoti sukurtą programinę įrangą; teisę perkelti programinę įrangą į kitą technologinę platformą; teisę naudoti ir keisti jai sukurtos programinės įrangos pradinį kodą (mašininės kalbos pradinius tekstus).175.2. Jeigu pagal užsakymą sukurtoje programinėje įrangoje panaudota kita autoriaus teisių turėtojo ar trečiųjų šalių programinė įranga, kuri integruota į pagal užsakymą sukurtą programinę įrangą ar kitaip susieta su atliktu užsakymu ir autoriaus turtinių teisių į sukurtą programinę įrangą ar parengtus projektinius dokumentus, perdavimas Perkančiajai organizacijai, užsakiusiai sukurti programinę įrangą ar parengti projektinius dokumentus, neturi apriboti šias teises perdavusio Paslaugų teikėjo teisės be atskiro Perkančiosios organizacijos sutikimo toliau vystyti, tobulinti, platinti ir atlikti kitus reikiamus veiksmus su sukurta programine įranga ar parengtais projektiniais dokumentais.175.3. Kartu su kompiuterine programa, kaip ši sąvoka apibrėžta Lietuvos Respublikos autorių teisių ir gretutinių teisių įstatyme, užsakovui perduodamas ir programos išeitinis kodas. Kompiuterių programos autoriaus asmeninės neturtinės teisės negali būti naudojamos tokiu būdu, kuris suvaržytų autorių turtinių teisių į šią kompiuterinę programą turėtojo teises, tarp jų ir teisę savo nuožiūra adaptuoti, keisti ir neatlygintinai platinti šiuos kūrinius. Šiame punkte numatytos autorių turtinės teisės, vadovaujantis Lietuvos Respublikos Autorių teisių ir gretutinių teisių įstatymo ir Valstybės informacinių išteklių valdymo įstatymo 12 str. nuostatomis, perduodamos ir suteikiamos Lietuvos Respublikos ir Europos Sąjungos šalių teritorijoje neribotam laikui.175.4. Paslaugų teikėjas turi perduoti Perkančiajai organizacijai projekto metu sukurtą programinę įrangą ir jos išeitinį kodą paslaugų priėmimo – perdavimo akto pasirašymo datai. 176. Paslaugų teikėjas neturi teisės atskleisti jokios su paslaugų teikimu susijusios informacijos trečiosioms šalims be Perkančiosios organizacijos raštiško leidimo arba jei to reikalauja įstatymai.


8. SUTARTIES VYKDYMO ETAPAI IR TERMINAI177. Visos paslaugos pagal šią Techninę specifikaciją turi būti suteiktos (išskyrus garantinį aptarnavimą) iki 2019 m. gruodžio 30 d. 178. Žemiau esančioje lentelėje pateikti Paslaugų etapai, etapų rezultatai ir reikalavimai dokumentacijai.


Lentelė 4. Paslaugų etapai, etapų rezultataiPaslaugų teikimo

etapasReikalavimai etapo rezultatams Rezultatas Terminas

1. Inicijavimas Paslaugų teikėjas:

Parengia Paslaugų teikimo reglamentą ir kitus planavimo dokumentus ir suderina su Perkančiąja organizacija.

Perkančioji organizacija (pagal kompetenciją):

Suteikia reikalingą informaciją.

Paslaugų teikimo reglamentas.

Paslaugų teikimo reglamente nurodoma projekto dalyviai, komunikavimo principai, atsakomybės, projekto problemų nustatymo ir valdymo procedūros, tarpinių ir galutinių rezultatų priėmimo kriterijai;

Etapo rezultatai turi būti pateikti, ne vėliau kaip per 10 darbo dienų nuo Paslaugų teikimo sutarties pasirašymo datos.

2. Detali analizė Paslaugų teikėjas:

Atlieka esamos ir siekiamos padėties įvertinimą, parengia dokumentaciją ir ją suderina su Perkančiąja organizacija.


Suteikia reikalingą informaciją;Pateikia pastabas ir rekomendacijas etapo Paslaugų teikėjo rezultatams.

Detalios analizės dokumentų pradinės versijos.

Detalios analizės dokumente išanalizuojami ir detalizuojami funkciniai ir nefunkciniai Techninės specifikacijos reikalavimai bei kiti Perkančiosios organizacijos išsakyti poreikiai, parengiami panaudojimo atvejai (angl. use case), kurie pateikiami panaudos atvejų diagramomis pagal UML (angl. Unified Modeling Language) notaciją ir detalizuojami aprašant kiekvieno panaudos atvejo vykdymo žingsnius (pagrindinę eiga, alternatyvią eigą, išimtinę eigą) ir kitus apribojimus. Sudėtingesni panaudos atvejai ar jų grupės turi būti detalizuojami pateikiant veiklos bei Registro procesus, naudojant procesų modeliavimo diagramas (UML activity diagram, BPMN (Business Process Model and Notation) ar lygiavertes diagramas). Pateikiami pastarųjų diagramų struktūrizuoti aprašai. Aprašomi Registro naudotojai ir jų teisės. Turi būti atliktas visų šios Techninės specifikacijos funkcinių ir nefunkcinių reikalavimų susiejimas su detalios analizės dokumento turiniu (skyriais, panaudos atvejais, diagramomis ir pan.). Siejimas turi būti atliekamas tokia forma, kad būtų aišku kokiu būdu yra projektuojamas ir realizuojamas

Etapo rezultatai turi būti pateikti ne vėliau kaip per 4 mėnesius nuo Paslaugų teikimo sutarties pasirašymo datos.


Paslaugų teikimo etapas

Reikalavimai etapo rezultatams Rezultatas Terminas

kiekvienas šios Techninės specifikacijos reikalavimas.3. Projektavimas Paslaugų teikėjas:

Parengia Registro projektavimo dokumentaciją.


Suteikia reikalingą informaciją;Pateikia pastabas ir rekomendacijas etapo Paslaugų teikėjo rezultatams.

Projektavimo dokumentai.Projektavimo dokumente pateikiama: Registro architektūros aprašymas fizinių komponentų ir programinių komponentų požiūriu, naudojamos technologijos (jų pavadinimai, versijos), informacinis vaizdas (duomenų bazės struktūros, duomenų bazių sąsajų schemos ir kt.), funkcinis vaizdas (Registro funkciniai vienetai, jų funkcijos, tarpusavio sąsajos, naudotojo sąsajos prototipai ir kt.), integracinis vaizdas (sąsajos tarp vidinių ir išorinių sistemų, kuriamos sistemos atžvilgiu), operacinis vaizdas (sisteminiai procesai, algoritmai, periodiniai sisteminiai darbai ir pan.), dislokavimo vaizdas (programinių komponentų pasiskirstymas techninėje įrangoje) ir kt.

Etapo rezultatai turi būti pateikti ne vėliau kaip per 5 mėnesius nuo Paslaugų teikimo sutarties pasirašymo datos.

4. Kūrimas (konstravimas)

Paslaugų teikėjas:

Parengia kūrimo ir testavimo aplinką Perkančiosios organizacijos infrastruktūroje;Vykdo reikalingus programavimo ir programinio konfigūravimo darbus, įgyvendina funkcinius ir nefunkcinius reikalavimus;Atlieka komponentų (angl. unit) testavimą, Registro testavimą, sąsajų su kitomis sistemomis ir registrais (integravimo) testavimą ir parengia vidinio testavimo ataskaitą.


Suteikia reikalingą informaciją;

Parengta kūrimo ir testavimo aplinką Perkančiosios organizacijos infrastruktūroje;Vidinio testavimo ataskaita, kurioje aprašyti atlikto vidinio testavimo rezultatai (apimtis, vykdymo metodika, testavimo tipai, procedūra, įėjimo/išėjimo kriterijai, testavimo aplinka), pateikiant informaciją apie Registro sritis, į kurias reikia atkreipti papildomą dėmesį testavimo metu.Atliktos Registro demonstracijos;Parengtos integracinių sąsajų specifikacijos;Parengta programinė įranga diegimui.

Vidinio testavimo ataskaita turi būti pateikta bent 10 darbo dienos iki diegimo etapo pradžios.Registro demonstracijos turi būti vykdomos nuolatos, pagal atskirai suderintą grafiką.




Peržiūri ir įvertina vidinio testavimo rezultatus;Kontroliuoja Paslaugų teikimo sutarties vystymo, testavimo aplinkas;Teikia pastabas sąsajų su kitomis analizės ir specifikavimo dokumentacijai;Pateikia pastabas ir rekomendacijas etapo Paslaugų teikėjo rezultatams.

5. Diegimas testinėje aplinkoje


Parengia ir pateikia programinę įrangą tinkamą įdiegimui Perkančiosios organizacijos testavimo aplinkoje.Vykdo pradinių duomenų įkėlimą į Registro duomenų bazę.Konsultuoja Perkančiąją organizaciją programinės įrangos įdiegimo į gamybinę aplinką klausimais.


Suteikia reikalingą informaciją;Kontroliuoja testavimo aplinką;Diegia tinkamai parengtą programinę įrangą Perkančiosios organizacijos gamybinėje aplinkoje.

Parengta testavimo aplinka Perkančiosios organizacijos infrastruktūroje;Sukurta programinė įranga ir įdiegta Perkančiosios organizacijos testavimo aplinkoje.

Etapo rezultatai turi būti pasiekti ne vėliau kaip per 2 savaites nuo kūrimo (konstravimo) etapo pabaigos.

Šis diegimo etapas turi būti baigtas iki priėmimo testavimo etapo pradžios.

6. Priėmimo testavimas


Parengia naudotojų ir Registro administratorių instrukcijas;Parengia Registro administravimo dokumentus (įskaitant Registro diegimo procedūrą).

Atliktas priėmimo testavimas;Ištaisytos testavimo metu užfiksuotos klaidos;Parengtos naudotojų ir Registro administratorių instrukcijos.Parengti Registro administravimo dokumentai (įskaitant Registro diegimo procedūrą).

Priėmimo testavimo vykdymui turi būti suplanuota ne mažiau kaip vienas mėnuo.Priėmimo testavimas gali trukti trumpiau, jeigu yra pasiekiami sėkmingo priėmimo testavimo kriterijai.




Vykdo galutinį priėmimo testavimą;Atlieka testavimo metu išaiškėjusius reikalingus pataisymus.


Dalyvauja testavime;Priima programinę įrangą bandomajai eksploatacijai.

Bandomajai eksploatacijai parengtu Registru. Priėmimo testavimas turi būti atliktas iki bandomosios eksploatacijos pradžios.

7. Diegimas darbinėje (eksploatavimo) aplinkoje

Paslaugų teikėjas atlieka šiuos darbus:

Parengia ir pateikia programinę įrangą tinkamą įdiegimui Perkančiosios organizacijos darbinėje aplinkoje.Įdiegia programinę įrangą į Perkančiosios organizacijos darbinę aplinką.Parengia bandomosios eksploatacijos planą.

Perkančioji organizacija:

Pateikia pastabas ir rekomendacijas bandomosios eksploatacijos planui.

Parengta darbinė (eksploatavimo) aplinka Perkančiosios organizacijos infrastruktūroje.Sukurta programinė įranga ir įdiegta Perkančiosios organizacijos darbinėje (eksploatavimo) aplinkoje.

Šis diegimas gali vykti tik po sėkmingai įvykusio priėmimo testavimo.Šis diegimo etapas turi būti baigtas per vieną savaitę nuo priėmimo testavimo etapo pabaigos ir baigtas iki bandomosios eksploatacijos pradžios.

8. Mokymai Paslaugų teikėjas atlieka šiuos darbus:

Parengia mokymų planą.Parengia mokymų medžiagą ir kitas reikalingas priemones.Parengia mokymų aplinką.Vykdo apmokymus.

Parengtas mokymų planas. Dokumente turi būti aprašytas mokymų kursų organizavimas, pateikti detalūs mokymų planai/grafikai, mokymų grupės, mokymų vietos, nurodyti resursai būtini mokymams (lektoriai, mokymų medžiaga, organizavimo priemonės, patalpos), pateiktas mokymų rengimų užduočių planas, mokymų kursų įvertinimo kriterijai.Parengta mokymų medžiaga. Dokumente turi būti pateikti mokymų pratimai skirtingi atskiroms

Mokymai turi būti įvykdyti iki bandomosios eksploatacijos pradžios.




naudotojų grupėms.Įvykdyti mokymai.

9. Duomenų migravimo etapas

Paslaugų teikėjas atlieka šiuos darbus:

Parengia duomenų migravimo aprašą;Atlieka duomenų migravimą.

Perkančioji organizacija:

Suteikia duomenis ar prieigą prie duomenų, kurios reikia migruoti.

Pateiktas ir suderintas duomenų migravimo aprašas.Atliktas duomenų migravimas.

Duomenų migravimas gali vykti tik po sėkmingo įdiegimo darbinėje aplinkoje etapo.Duomenų migravimas turi trukti ne ilgiau 1 mėnesio.

10. Bandomoji eksploatacija


Teikia konsultacijas bandomosios eksploatacijos klausimais;Reaguoja į eksploatacijos metu nustatytus defektus;Užtikrina ekspertų konsultavimą Perkančiosios organizacijos darbuotojams ir IT specialistams;Parengia bandomosios eksploatacijos rezultatų ataskaitą;Užtikrina į Registro DB importuotų ir suvestų duomenų integralumą ir vientisumą.


Dirba su parengtu Registru;Registruoja bandomosios eksploatacijos metu nustatytas klaidas;Vykdo bandomosios eksploatacijos metu nustatytų problemų šalinimo kontrolę.

Bandomosios eksploatacijos ataskaita;Pašalintos bandomosios eksploatacijos metu nustatytos klaidos. Teikėjas bandomosios eksploatacijos metu pagal suderintą klaidų šalinimo grafiką turi šalinti visus suderintos Registro funkcionalumo trūkumus, užregistruotus bandomosios eksploatacijos problemų registre;Parengtas garantinės priežiūros procedūros dokumentas (įskaitant Registro pakeitimų valdymo procedūrą). Dokumente turi būti aprašytas garantinės priežiūros teikimo būdas, detalizuotos garantinės priežiūros teikimo sąlygos, Paslaugų teikėjo atsakomybė, Perkančiosios organizacijos atsakomybė, kontaktinė informacija, papildomos tvarkos (eskalavimo, klaidų registravimo, konsultavimo)).

Bandomoji eksploatacija turi trukti ne trumpiau nei 1 mėnesį.Garantinės priežiūros procedūros dokumentas turi būti pateiktas likus 1 mėnesiui iki projekto įgyvendinimo pabaigos.




11. Garantinė priežiūra

Paslaugų teikėjas suteikia ne trumpesnį nei 36 mėnesių garantinį aptarnavimą.

Teikiami garantinei įsipareigojimai. 36 mėnesiai nuo galutinio sutarties perdavimo-priėmimo akto pasirašymo dienos.


179. Turi būti parengtos tarpinės paslaugų vykdymo ataskaitos. Tarpinė paslaugų vykdymo ataskaita apima projekto eigos ir rezultatų vertinimą, faktinių rezultatų palyginimą su planu, tolesnių darbų vykdymo planą. Tarpinės paslaugų vykdymo ataskaitos teikiamos Perkančiajai organizacijai kas du mėnesius.180. Turi būti parengta galutinė paslaugų įvykdymo ataskaita. Galutinė paslaugų įvykdymo ataskaita apima projekto eigos ir rezultatų vertinimą, faktinį rezultatų palyginimą su planu ir neatitikimų įvertinimą. Galutinė paslaugų įvykdymo ataskaita teikiama per 5 darbo dienas nuo visų paslaugų pagal šią Techninę specifikaciją suteikimo.181. Patvirtinti dokumentai turi (gali) būti keičiami vėlesnių etapų metu, jeigu yra vykdomi kuriamo Registro pakeitimai, atsižvelgiant į priėmimo testavimo bei bandomosios eksploatacijos rezultatus, kitas projekto veiklas ir aplinkybes, kurios susijusios su pateiktos dokumentacijos turiniu. Projekto dokumentacija projekto pabaigoje turi būti aktualizuojama (atnaujinama).182. Paslaugų teikėjas privalo vadovautis Paslaugų teikimo sutarties vykdymo metu aktualiomis teisės aktų redakcijomis. Paslaugų teikėjui privalomi ir visi Paslaugų teikimo sutarties vykdymo metu naujai priimti / pakeisti teisės aktai, jeigu jie susiję su Paslaugų teikimo sutarties įgyvendinimu. Jei naujai priimti / pakeisti teisės aktai prieštarauja šioje Techninėje specifikacijoje aprašytiems reikalavimams, Paslaugų teikėjas turi įgyvendinti reikalavimus vadovaujantis Paslaugų teikimo sutarties vykdymo metu priimtų / pakeistų teisės aktų aktualiomis redakcijomis.183. Visa dokumentacija turi būti parengta laikantis bendrinės lietuvių kalbos taisyklių.184. Dokumentų galutinės versijos turi būti pateiktos dviem formatais: elektroniniu (MS Word arba kitu su Perkančiąja organizacija suderintu redagavimui tinkamu formatu įrašant dokumentą (-us) į CD ar DVD) ir popieriniu (1 egz.). Jų preliminarios (projektinės) versijos turi būti pateikiamos elektroniniu formatu elektroninio ryšio priemonėmis.185. Dokumentų pateikimo terminai pateikti šiam skyriuje pateiktoje lentelėje. Jei dokumentų pateikimo terminas nėra detalizuotas, šių dokumentų pateikimo terminas turi būti sutartas Paslaugų teikimo reglamente. Visi dokumentai privalo būti pateikti iki galutinio paslaugų priėmimo – perdavimo akto pasirašymo datos.

________________________________________

Documents

Santrauka - vtek.lt · Web viewSudėtingesni panaudos atvejai ar jų grupės turi būti detalizuojami pateikiant veiklos bei Registro procesus, naudojant procesų modeliavimo diagramas