LIETUVOS NACIONALINĖS ŠENGENO INFORMACINĖS SISTEMOS IR SUSIJUSIŲ REGISTRŲ, TVARKANČIŲ ŠENGENO INFORMACINĖS SISTEMOS DUOMENIS, (NSIS ir POLIS) PROGRAMINĖS ĮRANGOS ATNAUJINIMO PASLAUGŲ PIRKIMAS (PPR-905)

Išanalizuota

Išteklių agentūra prie Lietuvos Respublikos vidaus reikalų ministerijos

Atviras konkursasCPV: 72200000 - Programinės įrangos programavimo ir konsultacinės paslaugos

ID: 68585152026-03-10 05:12Pasiūlymai iki: 2026-04-13 10:00

Aprašymas

Perkamos Lietuvos nacionalinės Šengeno informacinės sistemos (NSIS) ir susijusių registrų, tvarkančių Šengeno informacinės sistemos duomenis (NSIS ir POLIS), programinės įrangos atnaujinimo paslaugos. Šio pirkimo tikslas – užtikrinti SIS perspėjimų duomenų tvarkymo atitiktį teisės aktams, gerinti duomenų kokybę ir sistemos efektyvumą bei įdiegti Šengeno vertinimų rekomendacijas.

Kvalifikaciniai reikalavimai

1Tiekėjas per paskutinius 3 (trejus) metus iki pasiūlymo pateikimo termino pabaigos turi būti tinkamai suteikęs informacinės sistemos (IS) ir/ar registro kūrimo ir/ar modernizavimo paslaugas, kurių vertė turi būti ne mažesnė kaip 100 000,00 (vienas šimtas tūkstančių) EUR be PVM (į paslaugų vertę neįskaičiuojama techninės įrangos tiekimo vertė).
2Specialistas (Ekspertas) Nr. 1 – Projekto vadovas: turi tarptautiniu mastu pripažįstamą informacinių technologijų projektų valdymo kvalifikaciją, patvirtintą galiojančiu PMP arba Prince2, arba Certified Project Manager IPMA sertifikatu, arba kitu lygiaverčiu dokumentu.
3Specialistas (Ekspertas) Nr. 1 – Projekto vadovas: per paskutinius 5 (penkerius) metus iki pasiūlymo pateikimo termino pabaigos turi būti vadovavęs bent 1 (vienai) informacinių sistemų ir/ar registrų kūrimo ir/ ar modifikavimo, ir/ ar modernizavimo sutarčiai (projektui).
4Specialistas (Ekspertas) Nr. 2 – Informacinės sistemos (IS) analitikas – projektuotojas: turi tarptautiniu mastu pripažįstamą IS analitiko kvalifikaciją, patvirtintą galiojančiu Foundation Certificate in Business Analysis arba OMG-Certified UML Professional (Foundation), arba IREB® Certified Professional for Requirements Engineering (Foundation), arba Microsoft Certified Data Analyst Associate, arba OMG Certified Expert in BPM sertifikatu, arba kitu lygiaverčiu dokumentu.
5Specialistas (Ekspertas) Nr. 2 – Informacinės sistemos (IS) analitikas – projektuotojas: per pastaruosius 5 (penkerius) metus iki pasiūlymo pateikimo termino pabaigos turi būti kaip IS analizės specialistas dalyvavęs vykdant bent 1 (vieną) IT paslaugų teikimo sutartį (projektą), kurios (-io) vykdymo metu buvo teikiamos informacinių sistemų ir/ar registrų kūrimo ir/ar modernizavimo, ir/ar modifikavimo paslaugos.
6Specialistas (Ekspertas) Nr. 3– Informacinės sistemos (IS) programinės įrangos specialistas (programuotojas): turi tarptautiniu mastu pripažįstamą IS programinės įrangos specialisto kvalifikaciją, patvirtintą galiojančiu Oracle Certified Professional Java Programmer arba Oracle Advanced PL/SQL Developer Certified Professional, arba Java Certified Programmer, arba Developing Solutions for Microsoft Azure, arba Microsoft Certified Professional, arba ESRI Sertified Web Application Developer Associate sertifikatu, arba kitu lygiaverčiu dokumentu.
7Specialistas (Ekspertas) Nr. 3– Informacinės sistemos (IS) programinės įrangos specialistas (programuotojas): per paskutinius 5 (penkerius) metus iki pasiūlymo pateikimo termino pabaigos turi būti dalyvavęs kaip IS programinės įrangos specialistas (programuotojas) vykdant bent 1 (vieną) IT paslaugų kūrimo, ir/ar modernizavimo, ir/ar modifikavimo sutartį (projektą).
8Specialistas (Ekspertas) Nr. 4 – Informacinės sistemos (IS) saugos ekspertas: turi tarptautiniu mastu pripažįstamą IS saugos eksperto kvalifikaciją, patvirtintą galiojančiu CISM (Certified Information Security Manager) arba CISA (Certified Information Security Auditor), arba CISSP (Certified Information Systems Security Professional), arba Microsoft 365 Certified: Security Administrator Associate, arba CompTIA Security+ sertifikatu, arba kitu lygiaverčiu dokumentu.
9Specialistas (Ekspertas) Nr. 4 – Informacinės sistemos (IS) saugos ekspertas: per paskutinius 5 (penkerius) metus iki pasiūlymo pateikimo termino pabaigos turi būti dalyvavęs kaip saugos specialistas vykdant bent 1 (vieną) IT paslaugų teikimo sutartį (projektą), kurios (-io) vykdymo metu užtikrino kuriamos ir/ar modernizuojamos, ir/ar modifikuojamos informacinės sistemos ar registro duomenų saugumą.
10Specialistas (Ekspertas) Nr. 5 – Testuotojas: turi tarptautiniu mastu pripažįstamą testuotojo kvalifikaciją, patvirtintą galiojančiu ISTQB Certified Tester Advanced Level (Test Manager) arba ISEB Intermediate Certificate in Software Testing sertifikatu, arba kitu lygiaverčiu dokumentu.
11Specialistas (Ekspertas) Nr. 5 – Testuotojas: per paskutinius 5 (penkerius) metus iki pasiūlymo pateikimo termino pabaigos turi būti dalyvavęs kaip testavimo specialistas vykdant bent 1 (vieną) IT paslaugų kūrimo, ir/ar modernizavimo, ir/ar modifikavimo sutartį (projektą).
12Tiekėjas neturi interesų, galinčių kelti grėsmę nacionaliniam saugumui. Perkančioji organizacija draudžia pirkime dalyvauti tiekėjams, jų subtiekėjams ar ūkio subjektams, kurių pajėgumais yra remiamasi, kurie patys ar juos kontroliuojantys asmenys yra registruoti (jeigu tiekėjas, jo subtiekėjas, ūkio subjektas, kurio pajėgumais remiamasi, ar kontroliuojantis asmuo yra fizinis asmuo – nuolat gyvenantis ar turintis pilietybę) VPĮ 92 straipsnio 14 dalyje numatytame sąraše nurodytose valstybėse ar teritorijose.

Techniniai reikalavimai

Diegimas

1Paslaugų teikėjas po bandomosios eksploatacijos turi perduoti Perkančiajai organizacijai modernizuotų sistemų išeities kodą ir licencinės programinės įrangos instaliacinius paketus.
2Turi būti sukonfigūruotas ir dokumentuotas programinės įrangos diegimo į testavimo ir gamybinę aplinką(-as) procesas ir priemonės taip, kad atsakingas Perkančiosios organizacijos darbuotojas programinę įrangą, pagamintą (sukompiliuotą) iš išeities tekstų, galėtų įdiegti į testavimo ir gamybinę aplinką(-as), valdyti diegimo konfigūraciją.
3Bet kokie programinės įrangos atnaujinimų diegimai į testavimo ir gamybinę aplinkas turi būti galimi tik iš Perkančiosios organizacijos kodo valdymo sistemoje (GIT) esančių išeities tekstų.
4Paslaugų teikėjas turi užtikrinti sistemų naudotojų konsultavimą visais su sistemų programinės įrangos diegimu susijusiais klausimais.
5Sistemų išeities kodai turi būti pateikiamas Paslaugų teikėjo naudotoms kūrimo priemonėms suprantamu formatu perkeliant į GIT.
6Paslaugų teikėjas turi dokumentuoti programinės įrangos diegimo į sistemų testavimo ir gamybinę aplankas procesą bei pateikti tam reikalingas programines priemones.
7Procesas turi būti dokumentuotas taip, kad: atsakingas Perkančiosios organizacijos darbuotojas iš pateiktų išeities tekstų galėtų pagaminti (Build) programinę įrangą bei valdyti gaminimo konfigūraciją; atsakingas Perkančiosios organizacijos darbuotojas programinę įrangą galėtų įdiegti į testavimo ir gamybinę aplinką(-as) bei valdyti diegimo konfigūraciją.

Saugumas

1Atnaujinamos ir naujai kuriamos sistemų dalys turi būti projektuojamos ir kuriamos atsižvelgiant į teisės aktų keliamus saugumo reikalavimus.
2Sistemų atnaujinimo metu sukurti komponentai turi būti apsaugoti nuo pažeidžiamumų, skelbiamų projekte „OWASP Top Ten Project“.
3Paslaugų teikėjas, prieš prasidedant bandomajai eksploatacijai, turės pateikti atsparumo įsilaužimams testavimo ataskaitą su išvada, kad pakeitimai užtikrina ir nepablogina esamų saugumo sprendimų.
4Jei atsparumo įsilaužimams testavimo metu bus nustatytas saugumo pažeidžiamumas, jis turi būti pašalintas iki funkcionalumų eksploatavimo pradžios.
5Atliekant sistemų modernizavimą neturi būti išjungiami ar kitaip pažeidžiami esami saugumo sprendimai.
6Tikslūs audito įrašų darymo momentai turi būti suderinti su Perkančiąja organizacija analizės ar projektavimo metu.
7Paslaugų teikėjas turi užtikrinti, kad siūlomos paslaugos atitinka Organizacinių ir techninių kibernetinio saugumo reikalavimų, taikomų kibernetinio saugumo subjektams, apraše nurodytus reikalavimus.
8Teikiant paslaugas turi būti vadovaujamasi saugaus projektavimo ir kodavimo (Secure Coding) praktika ir metodais (The Open Web Application Application Security Project (OWASP) Secure Coding Practices, OWASP application security verification standard ar lygiaverčius).
9Atliekant patikrinimus (testavimus) turi būti remiamasi Open Web Application Security Project (OWASP) Testing Guide v4, Penetration Testing Execution Standard (PTES), Open Source Security Testing Methodology Manual (OSSTMM), Information Systems Security Assessment Framework (ISSAF), NIST SP 800-30 ar lygiavertėmis saugumo patikrinimo metodikomis.
10Žiniatinklio paslaugų sauga turi būti vykdoma vadovaujantis WS-S (Web Services Security) standarto arba lygiaverčiais reikalavimais.
11Priėmimo testavimo etapo metu (ar kitu sutartu metu) Paslaugų teikėjas turi sudaryti visas reikiamas sąlygas Perkančiosios organizacijos darbuotojams (ar trečiajai šaliai) atlikti atsparumo įsilaužimams testavimą.
12Paslaugų teikėjas turės atlikti konfigūravimo ar programavimo darbus, kurie bus būtini siekiant ištestuoti sistemų saugumą įvairiais jų naudojimo scenarijais.
13Paslaugų teikėjas turės atlikti reikiamus sistemų programavimo ir / ar konfigūravimo darbus, atsižvelgiant į Perkančiosios organizacijos darbuotojų (ar trečiosios šalies) atliktų atsparumo įsilaužimams testavimų rezultatus, kad prieš pradedant eksploatuoti atnaujintas sistemas būtų pašalinti nustatyti saugumo grėsmes keliantys trūkumai.

Testavimas

1Turi būti atlikti šie testavimai: 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šą.
2Turi būti atliktas priėmimo testavimas (Acceptance testing). Šis testavimas turi būti atliekamas dalyvaujant Paslaugų teikėjas, Perkančiajai organizacijai ir kitoms suinteresuotoms šalims. Šio testavimo metu turi būti tikrinamas testavimo tikslų įgyvendinimas.
3Priėmimo testavimo veiklos turi būti vykdomos remiantis apibrėžtu priėmimo testavimo planu, metodika ir testavimo scenarijais.
4Priėmimo testavimas turi užtikrinti, kad atnaujintos sistemos yra tinkamos bandomajai eksploatacijai.
5Priėmimo testavimo metu turi būti vykdomas identifikuotų klaidų, problemų ir trūkumų registravimas. Už registravimą atsakingas Paslaugų teikėjas.
6Klaidų žurnalas turi būti specializuota problemų registravimo ir sekimo programinė įranga (Issue Tracking Software), paremta tinklinėmis technologijomis, t. y. pasiekiama naudojant interneto naršyklę.
7Paslaugų teikėjas turi parengti visus testavimui reikalingus testavimo duomenis.
8Paslaugų teikėjas turi užtikrinti, kad priėmimo testavimo metu Sistemose būtų pakankamai testinių duomenų, kurie leistų visiškai ištestuoti atnaujintus funkcionalumus.
9Priėmimo testavimas bus užbaigiamas, kai bus tenkinami testavimo metodikoje įvardinti testavimo priėmimo kriterijai: ištaisytos visos 1-ojo prioriteto klaidos; 2-ojo prioriteto neuždarytų klaidų kiekis neviršija 20 proc. viso (fiksuotų) 2-ojo prioriteto klaidų kiekio; 3-ojo prioriteto neuždarytų klaidų kiekis neviršija 40 proc. viso (fiksuotų) 3-ojo prioriteto klaidų kiekio.

Auditavimas

1Paslaugų teikėjas turi išlaikyti esamą sistemų naudojimo veiksmų auditavimo modelį, papildydamas jį atnaujintų komponentų auditavimo elementais.

Greitaveika

1Atnaujintų komponentų greitaveika turi būti neprastesnė, nei iki atnaujinimo.
2Priėmimo testavimo etapo metu (ar kitu sutartu metu) Paslaugų teikėjas turi sudaryti visas reikiamas sąlygas Perkančiosios organizacijos atstovų specialistams atlikti atnaujintų sistemų našumo ir greitaveikos testavimą.
3Paslaugų teikėjas turės atlikti konfigūravimo ar programavimo darbus, kurie bus būtini siekiant išbandyti atnaujintų sistemų našumą įvairiais naudojimo scenarijais.
4Paslaugų teikėjas turi atlikti reikiamus atnaujintų sistemų programavimo ir / ar konfigūravimo darbus, atsižvelgiant į Perkančiosios organizacijos atstovų atliktų našumo ir greitaveikos testavimų rezultatus, jeigu testų rezultatai netenkins našumo ir greitaveikos reikalavimų.

Dokumentacija

1Visa dokumentacija turi būti parengta / atnaujinta laikantis bendrinės lietuvių kalbos taisyklių.
2Paslaugų teikėjas per 10 (dešimt) darbo dienų nuo sutarties įsigaliojimo dienos turi parengti ir pateikti Perkančiajai organizacijai Paslaugų teikimo reglamentą, apimantį projekto tikslus, prioritetus, paslaugų apimtis ir rezultatus, rizikų valdymą, kokybės valdymą, naudojamus standartus, komunikavimo planą, atsakomybes, projekto problemų nustatymo ir valdymo procedūras, detalų paslaugų teikimo kalendorinį planą (grafiką) ir kitą projekto vykdymui aktualią informaciją.
3Visi Paslaugų teikėjo parengti/ atnaujinti dokumentai turės būti suderinti su Perkančiąja organizacija.
4Paslaugų teikėjas turės parengti / atnaujinti su Perkančiąja organizacija suderintą dokumentaciją įskaitant: NSIS architektūros specifikaciją; NSIS techninę specifikacija; NSIS duomenų teikimo žiniatinklio paslaugos specifikaciją; NSIS administratoriaus vadovą; PPPTR reikalavimų specifikaciją; POLIS dokumentus, kiek tai susiję su pakeitimais įdiegtais paslaugų teikimo eigoje.
5Paslaugų teikėjas pataisyti dokumentai turi būti teikiami su matomais pakeitimais („track changes“ funkcija).
6Projekto dokumentacija turi būti aktualizuojama (atnaujinama) ir galutinės versijos pateiktos su Perkančiąja organizacija suderintais terminais bet ne vėliau kaip iki galutinio priėmimo perdavimo akto pateikimo dienos.
7Dokumentų galutinės versijos turi būti pateiktos elektroniniu (MS Word arba kitu su Perkančiąja organizacija suderintu redagavimui tinkamu formatu).
8Perkančiajai organizacijai nurodžius, dokumentai turės būti pasirašyti elektroniniu parašu.

Galutinis priėmimas

1Galutinis atnaujintų sistemų 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.
2Sistemų atnaujinimo darbai bus priimami pasirašant perdavimo–priėmimo aktą.
3Paslaugų 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).
4Intelektinės nuosavybės teisių perėjimas turi apimti Perkančiosios organizacijos galimybę ateityje pasirinkti kitą paslaugų teikėją šio pirkimo objekto priežiūrai, vystymui ir kitų būtinų paslaugų teikimui, siekiant užtikrinti stabilų pirkimo objekto veikimą.
5Šiuo tikslu Perkančiajai organizacijai yra perduodami programiniai kodai ir jų diegimo instrukcijos tam, kad Perkančioji organizacija galėtų be jokių apribojimų toliau savo nuožiūra modifikuoti ir įskaitant, bet neapsiribojant, toliau plėtoti sukurtą objektą, suteikti teises naudoti objektą kitoms šalims, keisti objekto pradinį kodą.
6Kartu su kompiuterine programa Perkančiajai organizacijai perduodamas ir programos išeitinis kodas ir jo diegimo instrukcijos.
7Kompiuterių 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.
8Autorių turtinės teisės perduodamos ir suteikiamos Lietuvos Respublikos ir ES šalių teritorijoje neribotam laikui.
9Paslaugų 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.
10Paslaugų 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.

Kibernetinis saugumas

1Tiekėjas privalo nedelsiant, bet ne vėliau kaip per 24 valandas nuo sužinojimo apie didelį kibernetinį incidentą momento – pateikti ankstyvąjį perspėjimą, kuriame pagal galimybes nurodoma, ar didelį kibernetinį incidentą, kaip įtariama, sukėlė neteisėti ar piktavališki veiksmai ir ar jis galėtų daryti tarpvalstybinį poveikį.
2Tiekėjas privalo nedelsiant, bet ne vėliau kaip per 72 valandas nuo sužinojimo apie kitą kibernetinį incidentą momento – pateikti ankstyvąjį perspėjimą apie kitą kibernetinį incidentą, kuriame pagal galimybes nurodoma ar kibernetinį incidentą, kaip įtariama, sukėlė neteisėti ar piktavališki veiksmai ir ar jis galėtų daryti poveikį perkančiosios organizacijos tinklams ir informacinėms sistemoms.
3Tiekėjas privalo ne vėliau kaip per vieną mėnesį nuo ankstyvojo perspėjimo apie kibernetinį incidentą pateikimo dienos – pateikti galutinę ataskaitą, kurioje pateikiama informacija pagal Kibernetinio saugumo įstatymo 18 straipsnio 4 dalies 4 punktą.
4Perkančioji organizacija arba jos įgalioti paslaugų teikėjai turi teisę atlikti tiekėjo atitikties Kibernetinio saugumo reikalavimų aprašo reikalavimams auditą (įskaitant neplaninį), o ir tiekėjas turi pareigą sudaryti sąlygas tokiam auditui atlikti sutarties vykdymo laikotarpiu ar įvykus dideliam incidentui.
5Tiekėjas visą sutarties vykdymo laikotarpį privalo ne rečiau kaip kartą per metus, įvykus esminiams kibernetinio saugumo subjekto organizaciniams ar kitiems reikšmingiems pokyčiams, taip pat įvykus dideliam kibernetiniam incidentui atlikti savo valdomų tinklų ir informacinių sistemų rizikos vertinimą.
6Tiekėjas privalo reguliariai, ne rečiau kaip kartą per metus, įvertinti savo atitiktį Kibernetinio saugumo įstatymui, Aprašo ir tiekėjo patvirtintiems kibernetinio saugumo politikos dokumentuose nustatytiems reikalavimams.
7Tiekėjas įsipareigoja perkančiajai organizacijai pareikalavus pateikti visą reikalingą informaciją, dokumentus, reikalingus įsitikinti, kad tiekėjas atlieka rizikos ir atitikties vertinimus.
8Tiekėjas įsipareigoja užtikrinti jo tinklų ir informacinės sistemų spragų, keliančių riziką perkančiosios organizacijos tinklams ir informacinėms sistemoms, valdymą.
9Tiekėjas įsipareigoja užtikrinti, kad jo patalpos, įranga, tinklai ir informacinių sistemų priežiūra, informacijos perdavimas tinklais atitinka Aprašo reikalavimus.
10Tiekėjui fizinė prieiga prie perkančiosios organizacijos tinklų, kitos techninės infrastruktūros ir informacinių sistemų nėra suteikiama.
11Tiekėjui suteikiama loginė prieiga per perkančiosios organizacijos saugų VPN sprendimą prie kūrimo ar testavimo aplinkų.
12Laikina loginė prieiga gali būti suteikta prie darbinių aplinkų atskiru perkančiosios organizacijos sprendimu (pvz. sprendžiant kritinius incidentus).
13Loginė prieiga suteikiama prie perkančiosios organizacijos kontroliuojamo nuotolinio darbalaukio serverio, kuriame visi tiekėjo veiksmai yra fiksuojami.

Garantinė priežiūra

1Paslaugų teikėjas garantinio aptarnavimo metu pagal suderintą sistemų garantinės priežiūros reglamentą turi teikti garantinės priežiūros paslaugas.
2Garantinio aptarnavimo objektas yra pagal šio Pirkimo sąlygas atnaujintas sistemų funkcionalumas, pateikta ir įdiegta kita programinė bei sisteminė programinė įranga.
3Paslaugų teikėjas garantinio aptarnavimo metu įsipareigoja užtikrinti visus Techninėje specifikacijoje sistemoms keliamus reikalavimus.
4Garantinio aptarnavimo trukmė – 24 mėnesiai, nuo paslaugų perdavimo-priėmimo akto pasirašymo dienos.
5Visi Paslaugų teikėjo veiksmai atliekant garantinę priežiūrą turi būti atliekami pagal su Perkančiąja organizacija suderintą tvarką.
6Sistemų garantinis aptarnavimas apima: Sistemų neatitikimų funkciniams reikalavimams ir veikimo klaidų bei kritinių klaidų šalinimą bei kitas Lietuvos Respublikos įstatymais ir norminiais aktais numatytas garantijas.
7Sistemų garantinis aptarnavimas apima: Sistemų darbingumo atstatymą, pavyzdžiui, įvykus duomenų bazės ar atskirų jos komponentų darbų sutrikimams, kai tai įvyksta dėl Paslaugų teikėjo pateiktų pakeitimų atnaujinimų ar kitų Paslaugų teikėjo veiksmų ar neveikimo.
8Sistemų garantinis aptarnavimas apima: prarastų, sugadintų duomenų atstatymą, kai gedimo priežastis yra Paslaugų teikėjo pateiktos programinės įrangos netinkamas veikimas.
9Sistemų garantinis aptarnavimas apima: Nustačius, kad atsirado sistemų atnaujinimo metu sukurtų komponentų pažeidžiamumas pagal „OWASP Top Ten Project“ kritinių pažeidžiamumų sąrašą, Paslaugų teikėjas turi pašalinti nustatytus saugumo trūkumus.
10Sistemų veikimo klaidos ir (ar) trikdžiai klasifikuojami: Kritinė klaida ir (ar) trikdis (1-as prioritetas) – sistema nustojo funkcionuoti ir naudotojai negali tęsti darbo. Reakcijos laikas – ne ilgiau kaip 1 valanda. Nustačius sutrikimo priežastis, sutrikimo šalinimo laikas ne ilgiau kaip 5 valandos.
11Sistemų veikimo klaidos ir (ar) trikdžiai klasifikuojami: Vidutinė klaida ir (ar) trikdis (2-as prioritetas) – kritiniai sistemos funkcionavimo sutrikimai, dėl kurių neįmanomas sklandus sistemos darbas, naudotojai turi galimybę dirbti, tačiau ne visu pajėgumu. Reakcijos laikas - ne ilgiau kaip 2 valandos. Nustačius sutrikimo priežastis, sutrikimo šalinimo laikas ne ilgiau kaip 6 valandos.
12Sistemų veikimo klaidos ir (ar) trikdžiai klasifikuojami: Žemo prioriteto klaida ir (ar) trikdis (3-as prioritetas) – veiklos procesai ir sistemos funkcionavimas paveiktas nežymiai, sutrikimas nekelia grėsmės duomenims ir sistemos funkcionavimui, problemos sprendimas yra būtinas, bet ne kritinis. Reakcijos laikas – ne ilgiau kaip 8 darbo valandos. Nustačius sutrikimo priežastis, sutrikimo šalinimo laikas derinamas su Perkančiąja organizacija.
13Sprendimą, kokio tipo klaida yra nustatyta, priima Perkančiosios organizacijos paskirti atsakingi asmenys, suderinę su Paslaugų teikėjo paskirtais atsakingais asmenimis.
14Paslaugų teikėjas turi suteikti prieigą paskirtiems sistemos naudotojams prie klaidų registravimo sistemos.
15Klaidų registravimas sistemoje vykdomas pagal su Perkančiąja organizacija suderintą procedūrą būtų perduodamos į Paslaugų teikėjo klaidų registravimo sistemą ar el. paštu ir grąžinamos aktualios klaidos sprendimo ar duomenų tvarkymo būsenos duomenys.
16Paslaugų teikėjo klaidų registravimo sistemoje sistemų naudotojai turi galėtų filtruoti registruotus darbus pagal laikotarpį, užregistruotų darbų būseną ir kt.
17Informacija apie pašalintas (pataisytas) klaidas ir (ar) trikdžius ataskaitos forma turi būti atnaujinama ir pateikiama kartą per ketvirtį.
18Paslaugų teikėjas privalo teikti parengtą ataskaitą suderinto el. pašto adresu arba sudaryti galimybę tokią ataskaitą formuoti Paslaugų teikėjo klaidų registravimo sistemoje.

Integracinės sąsajos

1Paslaugų teikėjas turi atnaujinti integracines sąsajas išlaikydamas esamus technologinius sprendimus ir priemones.
2Pagal poreikį turės būti sukurti nauji duomenų apsikeitimo metodai arba praplėsti esami.
3Realizuojant integracines sąsajas turi būti naudojamos saugumo priemonės užtikrinančios duomenų mainų vientisumą ir konfidencialumą.
4Paslaugų teikėjas turi užtikrinti, kad nebus sutrikdytas jau veikiančių integracinių sąsajų veikimas.

Bandomoji eksploatacija

1Turi būti atlikta atnaujintų sistemų bandomoji eksploatacija.
2Bandomosios eksploatacijos tikslai: užtikrinti atnaujintų sistemų komponentų atitiktį ir tinkamą veikimą; išbandyti gamybinę sistemų komponentų konfigūraciją; identifikuoti ir pašalinti bandomosios eksploatacijos metu pastebėtus defektus; stabilizuoti gamybinės aplinkos konfigūraciją, atsižvelgiant į bandomosios eksploatacijos metu sukauptą patirtį.
3Bandomosios eksploatacijos veiklas Paslaugų teikėjas turės vykdyti pagal su Perkančiąja organizacija suderintą Bandomosios eksploatacijos planą.
4Paslaugų teikėjas, iki bandomosios eksploatacijos pradžios, privalo paruošti sistemų infrastruktūrą darbui: atlikti sistemų komponentų konfigūravimą, kad visi bandomosios eksploatacijos dalyviai turėtų galimybę prisijungti prie sistemos iš savo darbo vietų.
5Paslaugų teikėjas turi pateikti rekomendacijas dėl naudotojų darbo vietų paruošimo.
6Paslaugų teikėjas privalo sumigruoti (įkelti ir suvesti) visus sistemoms veikti būtinus duomenis (pvz. skaitmeninius objektus, jų metaduomenis ir pan.) bei pašalinti perteklinius (bandomajai eksploatacijai nereikalingus) duomenis, taip pat privalo užtikrinti, kad visi duomenys būtų integralūs.
7Bandomoji eksploatacija yra baigiama, kai tenkinami bandomosios eksploatacijos plane ir metodikoje nustatyti bandomosios eksploatacijos priėmimo kriterijai: atnaujinta visa susijusi dokumentacija, išbandytos ir patikrintos visos funkcijos, modernizuota sistema atitinka funkcinius ir nefunkcinius reikalavimus, sutartas likusių klaidų, su priimtina rizika, išsprendimo terminas tenkinant šiuos kriterijus: ištaisytos visos 1-ojo ir 2-ojo prioriteto klaidos; 3-ojo prioriteto neuždarytų klaidų kiekis neviršija 5.

Analizė ir projektavimas

1Paslaugų teikėjas analizės ir projektavimo vykdymo metu turi atlikti detalią veiklos procesų ir poreikių analizę bei projektavimą ir ne vėliau kaip per 30 darbo dienų parengti su Perkančiąja organizacija suderintus detalios reikalavimų analizės ir projektavimo dokumentus.
2Detalios reikalavimų analizės dokumente turi būti pateikti pagal Techninės specifikacijos funkcinius ir nefunkcinius reikalavimus bei pagal Perkančiosios organizacijos išsakytus poreikius parengti panaudos atvejai (Use Case) (panaudos atvejų diagramos ir detalūs panaudos atvejų aprašymai, nurodant žingsnius (pagrindinę eigą, alternatyvią eigą, išimtinę eigą) ir kitus apribojimus), naudojant UML (Unified Modeling Language) ar lygiavertę notaciją.
3Turi būti atliktas visų 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 kiekvienas Techninės specifikacijos reikalavimas.
4Detalios analizės ir projektavimo etapų metu Paslaugų teikėjas turi detalizuoti Techninės specifikacijos funkcinius ir nefunkcinius reikalavimus, atsižvelgdamas į Sistemų naudotojų poreikius.

Paslaugų teikimo valdymas

1Per 10 (dešimt) darbo dienų nuo Paslaugų teikimo sutarties įsigaliojimo dienos Paslaugų teikėjas turi pateikti Paslaugų teikimo reglamentą, kuriame turi būti detalizuoti Paslaugų teikimo etapai, jų rezultatai (pateiktys), dalyvių vaidmenys, tarpusavio komunikacijos būdai, pateikti pagrindiniai riboženkliai (milestones) ir detalus Perkančiosios organizacijos nurodytus terminus atitinkantis darbų vykdymo grafikas.
2Paslaugų teikėjas turi užtikrinti, kad Paslaugų teikimo reglamentas būtų suderintas su Perkančiąja organizacija per 20 (dvidešimt) darbo dienų nuo Paslaugų teikimo sutarties įsigaliojimo dienos.

Architektūra ir duomenų bazės

1Sistemų modernizavimo metu neturi būti atliekami esminiai sistemų architektūros pakeitimai.
2Atliekant sistemų duomenų bazių struktūros pakeitimus turi būti užtikrinamas korektiškas duomenų bazę naudojančių aplikacijų ir sąsajų (tinklinių sąsajų, DB procedūrų ir pan.) veikimas.
3Sistemų duomenys turi būti indeksuojami, užtikrinant užklausų apdorojimo spartą.
4Duomenų bazės turi būti normalizuotos, duomenų struktūra turi būti aiškiai apibrėžta, turi būti nustatyti duomenų vientisumo apribojimai (Integrity Constraints).

Bendrieji funkciniai reikalavimai

1Paslaugų teikėjas turės sukurti Techninėje specifikacijoje nurodytas funkcijas.
2Paslaugų teikėjas turi atlikti visus programinės įrangos pakeitimus, kurie bus nustatyti detalios analizės ar projektavimo etape atsižvelgiant į Techninės specifikacijos reikalavimus.
3Visi atlikti pakeitimai, turi būti atlikti išlaikant bendrą programinės įrangos logiką.
4Atnaujinant ir kuriant funkcijas turi būti vadovaujamasi esamais bendro funkcionalumo veikimo principais (perpanaudojant esamus sprendimus), o kur reikia – išplečiant ar papildant funkcionalumą (pvz., puslapiavimo, paieškos, pranešimų ir užduočių funkcionalumai, dinaminių duomenų formų funkcionalumas ir kt.).
5Atnaujinant ir kuriant funkcijas turi būti realizuotas bylos, prašymų, nagrinėjimų, dokumentų, procesų, užduočių ir kitų komponentų būsenų automatinis priskyrimas ir būsenų atvaizdavimas pagal nustatytas veiklos taisykles, kurios esant poreikiui, turi būti papildytos / praplėstos.
6Teisių ir rolių mechanizmas turi būti papildytas naujomis teisėmis ir rolėmis, reikalingomis vykdyti apibrėžtas funkcijas ir veiksmus.
7Sąrašuose turi būti realizuotas sąrašų puslapiavimas.
8Sąrašuose turi būti realizuotas daugelio įrašų pažymėjimo funkcionalumas tam tikrų veiksmų atlikimui (pvz., eksportavimui, šalinimui pasirinktų įrašų).
9Turi būti galima sąrašą spausdinti bei eksportuoti į PDF, WORD ar lygiavertes rinkmenas. Turi būti galimybė valdyti eksportuojamų sąrašo objektų apimtį.
10Turi būti galima objektų sąrašą filtruoti ir rūšiuoti pagal tam sąrašui priklausančius atributus, filtrų pasirinkimas turi būti suderintas su Perkančiąja organizacija. Esami sąrašai turi būti peržiūrėti ir pagal suderintą poreikį išplėsti naujais atributais / filtrais. Išimtys gali būti taikomos suderinus sprendimą su Perkančiąja organizacija.
11Sąrašuose turi būti atvaizduojamas įrašų sąraše skaičius. Atlikus sąrašo filtravimą turi būti vaizduojamas rastų įrašų skaičius.
12Pagal turimas naudotojo prieigos teises turi būti galimybė inicijuoti konkretaus duomenų įrašo peržiūrą, koregavimą, trynimą.
13Tekstiniuose paieškos laukuose turi būti realizuota paieška pagal žodžio ar skaičių junginio fragmentą ir pilną žodį.
14Paieška turi būti atliekama pagal lietuviškas raides ir vietoje lietuviškų raidžių naudojant lotyniškus raidžių atitikmenis (pvz., „š“ ir „s“ raides traktuojant kaip vieną).
15Paieška turi būti vykdoma neatsižvelgiant į didžiąsias ir mažąsias raides.
16Paieška turi būti vykdoma tik tuose komponentuose ir duomenų aibėje, prie kurių sistemų naudotojas turi prieigos teises.
17Paieškos rezultatuose turi būti pateikiama ir giminingų reikšmių rezultatai (pvz., jeigu paieškos frazė yra „vizito“, tai į rezultatus turi būti įtraukta ir vizitas, vizitui, vizitams ir t.t.).
18Paieškos rezultatai turi būti pateikiami sąrašo forma, jei nesuderinama kitaip.
19Ten kur aktualu, atlikus paiešką, turi būti rodomas paieškos rezultatų skaičius.
20Paieškos / filtravimo funkcijos turi būti įdiegtos visuose naujai kuriamuose komponentuose.
21Turi būti vykdomas į duomenų įvedimo formas įvedamų duomenų tikrinimas (validation).
22Turi būti tikrinami privalomi įvesti duomenys.
23Turi būti tikrinamas duomenų formatas (datos, skaičiaus, teksto ar kitas nustatytas taisykles).
24Turi būti tikrinami pridedamų rinkmenų plėtiniai ir rinkmenos dydis.
25Turi būti atliekamas loginis tikrinimas tarp formos elementų – vieno formos elemento parinkimas (įvedimas) turi galėti įjungti / išjungti kitus formos elementus ir pan.
26Suderintose vietose turi būti naudojama turinio teksto rengyklė (redaktorius), kuri turi veikti WYSIWYG principu arba jam lygiaverčiu principu, t. y. turi turėti lentelių kūrimo, formatavimo bei redagavimo galimybę, pagrindines teksto redagavimo ir formatavimo funkcijas (lygiavimas, pastraipos, numeravimas, spalva ir t. t.), vaizdo įkėlimo funkcijas į tekstą.
27Sistemų naudotojams turi būti rodomi klaidų ar sėkmės pranešimai. Klaidų pranešimai turi būti aiškūs, kad vartotojas suprastų, ką turi patikslinti arba kodėl jis negali atlikti tam tikro veiksmo.
28Į sistemą galimų įkelti rinkmenų formatai turi būti tikrinami naudojant esamus leidžiamų įkelti rinkmenų formatų tikrinimo funkcionalumus.
29Turi būti realizuotos bendrosios veiklos logikos taisyklės tarp skirtingų esamų ir naujai kuriamų funkcinių modulių ir komponentų.
30Visi kuriami šablonai, šabloniniai dokumentai, klasifikatoriai turi turėti jų naudojimo ir matymo sistemoje taisyklių nustatymo ir redagavimo galimybes (datos rėžius, susiejimą su kito objekto naudojimo ir matymo taisyklėmis, rankinį objekto matymo ir naudojimo įjungimą ir išjungimą, nustatytas koregavimo galimybes).
31Atliekant šablonų, šabloninių dokumentų, klasifikatorių koregavimą turi būti galima pasirinkti, ar turi būti sukuriama nauja objekto versija, ar turi būti koreguojama esama objekto reikšmė.
32Iš naudotojo perspektyvos senesnės objektų versijos turi būti naudojamos atvaizduojant duomenis, kurie buvo sudaryti naudojant tuo metu aktualią šablonų, šabloninių dokumentų, klasifikatorių versiją.
33Naudotojui inicijuojant naujų objektų sukūrimą turi būti naudojamos aktualios šablonų, šabloninių dokumentų, klasifikatorių versijos.
34Turi būti galimybė inicijuoti ir senesnių versijų objektų sukūrimą, kai administravimo priemonėmis yra nustatytos taisyklės leidžiančios atlikti tokį veiksmą.
35Visoms funkcijoms, kurių metu yra sukuriami duomenys ar dokumentai, turi būti realizuojamos tų duomenų ar dokumentų redagavimo bei šalinimo ar anuliavimo funkcijos, kurios turi būti suderinamos su veiklos logika.
36Visos naujai kuriamos / atnaujinamos formos turi būti konstruojamos taip, kad duomenų įvedimas būtų kiek įmanoma labiau struktūrizuotas, o dokumentai generuojami struktūrizuotų duomenų pagrindu. Turi būti kuriami ir naudojami klasifikatoriai.
37Visos formos ir šablonai, kiek įmanoma, turi būti automatizuotai užpildomi duomenimis, kurie yra saugomi naudotojo paskyroje, sistemų duomenų struktūrose ar kitose per integracines sąsajas pasiekiamose informacinėse sistemose ir registruose.
38Naudotojui turi reikėti įvesti tik unikalią, iš anksto nežinomą informaciją.
39Turi būti realizuotas pagalbinės informacijos (Hints) funkcionalumas, kuris leidžia naudotojams pateikti paaiškinamuosius pranešimus tose vietose, kuriose gali kilti neaiškumai siekiant suprasti reikalingus atlikti veiksmus (pvz., pateikiamas paaiškinimas, kokius duomenis reikia įvesti į tam tikrą dokumento / prašymo lauką).
40Turi būti vykdomas išorinių ir vidinių sistemų naudotojų informavimas sisteminiais pranešimais, el. paštu apie naudotojui aktualius įvykius.

Programinė įranga ir licencijos

1Atnaujintų sistemų ir visų jų komponentų naudojimui turi būti nereikalingos mokamos ar kitaip naudojimą apribojančios programinės įrangos licencijos.
2Turi būti pateikiamos naujausios programinės įrangos versijos (taikoma tiek mokamoms, tiek nemokamoms licencijoms).
3Paslaugų teikėjas privalo pateikti reikiamą programinę įrangą ir licencijas (ar bet kokius kitus leidimus (sertifikatus, prenumeratas ir pan.) reikalingas atnaujinamų sistemų dalių sprendimo realizacijai, net jei Techninėje specifikacijoje tokia programinė įranga ar licencijos nėra reikalaujamos, tačiau yra būtinos veikloms įgyvendinti.
4Paslaugų teikėjo pateikiama standartinė licencinė programinė įranga (Commercial Off-The-Shelf Software), kuri reikalinga atnaujintų sistemų dalių veikimui, turi būti pateikiama kartu su visomis reikiamomis licencijomis (jeigu yra licencijuojama, kad Perkančiajai organizacijai nereikėtų įsigyti papildomų licencijų ar kitaip patirti išlaidų programinės įrangos veikimui) neriboto galiojimo laikotarpiui, jei gamintojas siūlo tokias licencijas, kitu atveju, jei gamintojas tokių licencijų nesiūlo, - laikotarpiui nuo sistemos komponento priėmimo–perdavimo akto pasirašymo dienos iki 36 mėnesių po diegimo paslaugų perdavimo-priėmimo akto pasirašymo dienos.
5Paslaugų teikėjas turi pateikti tokią programinę įrangą ir licencijas testavimo ir gamybinei aplinkoms.
6Pasibaigus licencijų galiojimui programinė įranga negali nustoti veikti ir negali būti apribotas jos funkcionalumas.
7Atnaujintų sistemų dalių licencinė programinė įranga (jei tokia pateikiama) turi turėti ne mažiau kaip 3 metų palaikymą: atnaujinimų parsisiuntimą ir diegimą, naujų komponentų pateikimą.
8Jeigu siūloma programinė įranga yra licencijuojama priklausomai nuo sistemą 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ų sistemų veikimą ir naudojimą nuo sukurto komponento priėmimo–perdavimo akto pasirašymo dienos iki 36 mėnesiai po galutinio diegimo paslaugų perdavimo-priėmimo akto pasirašymo dienos.
9Atnaujinamų sistemų dalių sprendimo ne licencinės programinės įrangos naudojimas neturi būti apmokestinamas (vartotojų kiekiui, galimų registruoti vartotojų kiekiui, galimų transakcijų kiekiui ir pan.).
10Visos reikalingos licencijos turi būti įgyjamos ir užregistruotos Perkančiosios organizacijos vardu, jeigu gamintojas reikalauja jų registracijos.
11Perkančiajai organizacija turi būti perduotos visų atnaujintų sistemų dalių veikimui reikalingos licencijos. Pateikiamų licencijų galiojimo pradžia turi būti ne ankstesnė nei bandomosios eksploatacijos etapo pabaiga ir ne vėlesnė nei garantinės priežiūros etapo pabaiga.
12Jeigu licencijos yra būtinos kūrimo etape ir bandomosios eksploatacijos etape, Paslaugų teikėjas turi pateikti atitinkamas licencijas jų galiojimo termino neįtraukiant į aukščiau reikalaujamą licencijų galiojimo terminą, atitinkamai prisiimant visus su tuo susijusius kaštus.

NSIS programinės įrangos atnaujinimas

1NSIS programinėje įrangoje turi būti įdiegti SIS Detalios techninės specifikacijos (DTS), Sąsajos kontroles dokumento (ICD) versijoje 5.5.2 bei AFIS ICD/DTS versijoje 1.1.0 (arba naujausioje prieinamoje sutarties vykdymo metu) įvesti pakeitimai, įskaitant numatytą „informacinių perspėjimų“ kategoriją - tvarkant (sukūrimas, keitimas, nutraukimas) naują perspėjimo kategoriją pagal Reglamento ES 2018/1862 37a straipsnį “Informaciniai perspėjimai dėl trečiųjų šalių piliečių, įvestų į SIS Sąjungos interesais” (SIS informaciniai perspėjimai).
2Numatoma pakeitimų apimtis: Klasifikatorių atnaujinimas; Perspėjimų tvarkymo XSD schemos atnaujinimas; Veiklos taisyklių atnaujinimas; Failų dydžių apribojimo pakeitimas; AFIS sistemos parametrų pakeitimas.
3Atnaujinta NSIS programinė turi būti pilnai suderinama su Centrinės sistemos versija 26R1/26R2.
4NSIS pranešimų apdorojimo modulyje (CSSM) turi būti įdiegtas funkcionalumas išvengti duomenų praradimo esant duomenų bazės prieigos sutrikimui. Įrašant duomenis turi būti užtikrinamas klaidų išvengimas.
5Sutrikimo atveju, neįrašyti pranešimai turi būti išsaugomi ir apdorojami vėliau.
6NSIS perspėjimų peržiūros modulyje (NSIS naršyklė) turi būti padaryti SIS perspėjimų duomenų atvaizdavimo patobulinimai, įskaitant duomenų pateikimą naudojant šabloną, kurį galima kurti ir keisti išorinėmis priemonėmis (XSLT, CSS ar lygiavertė technologija).
7Šablone turi būti galima aprašyti web tinklapio duomenų laukų išdėstymą, apipavidalinimą, grafinių elementų formatavimą, nuorodas, logines taisykles, klasifikatorių reikšmių panaudojimą ir kitas būtinas funkcijas.
8Šablonai turi būti saugomi NSIS duomenų bazėje.
9Turi būti galima panaudoti daugiau kaip vieną šabloną vienu metu.
10Turi būti pateiktas šablonų sukūrimo ir pritaikymo aprašas.
11Turi būti sukurtas ir įdiegtas pradinis šablonas atvaizduojantis visus šiuo metu pateikiamus duomenis.
12Turi būti išsaugotas ir prieinamas šiuo metu naudojamas NSIS perspėjimų peržiūros langas.
13NSIS perspėjimų peržiūros modulyje (NSIS naršyklė) tvarkant specialius SIS perspėjimų duomenis – žymas (flag) ir sąsajas (links) ši funkcija turi būti pakeista taip, kad nebūtų galima įvesti naujų SIS perspėjimo duomenų pakeitimų kol nebuvo gautas patvirtinimas apie ankstesnės operacijos rezultatą.
14NSIS perspėjimų peržiūros modulyje (NSIS naršyklė) pildant sutapimo formą turi būti galima pridėti papildomus failus (priedus) įkeliant juos iš naudotojo įrenginio. Šie priedai turi būti siunčiami SIRENE kartu su kitais sutapimo formos duomenimis.
15Turi būti pakeista NSIS perspėjimų peržiūros modulio (NSIS naršyklė) naudotojų autorizavimo funkcija.
16Turi būti sukurtos ir naudojamos aplikacijos rolės tvarkomos VRIP naudotojų administravimo posistemėje ADMIN III.
17Prisijungusių naudotojų duomenys (įstaiga, pareigos ir kiti) turi būti imami tik iš VRIP naudotojų administravimo sistemos ADMIN III.
18Turi būti atnaujintas NSIS užklausų modulis (NSIS Queries).
19Turi būti užtikrinta užklausų atsakymų pateikimo greitaveika – atsakymo pateikimas neturi trukti ilgiau kaip 10 sekundžių ieškant 100 milijonų įrašų SIS perspėjimų duomenų bazėje.
20Turi būti sukurtos naujos paieškos funkcijos – „Ieškoti laivo“, „Ieškoti orlaivio“, „Ieškoti žemės ūkio technikos“, „Ieškoti kelių transporto priemonės“ kurių užklausos parametras būtų vienas numeris atliekant paiešką visuose SIS duomenų bazėje esančiuose numerių laukuose pagal sąrašą suderintą analizės etapo metu.
21Užklausų programinis kodas turi būti įdiegtas kaip duomenų bazės procedūrų paketas (Oracle Stored Procedure).
22Užklausose turi būti galima įvesti audito sistemoje naudojamą informaciją.
23Turi būti pateiktos užklausų ir atsakymų schemos WSDL/WADL formatu.
24NSIS pirštų atspaudų apdorojimo modulyje turi būti atlikti pakeitimai įdiegiant atnaujintas centrinės sistemos „NIST validator“ ir „NIST converter“ bibliotekas.

POLIS programinės įrangos atnaujinimas

1POLIS programinėje įrangoje turi būti įdiegtas funkcionalumas apdorojantis NSIS pranešimus apie nacionalinių SIS perspėjimų būklės pasikeitimus (pvz. panaikinimą) ir atitinkamai atnaujinantis registrų objektų duomenis.
2POLIS programinėje įrangoje turi būti sukurtas PPPTR funkcionalumas, tvarkant (sukūrimas, keitimas, nutraukimas) naują perspėjimo kategoriją pagal Reglamento ES 2018/1862 37a straipsnį “Informaciniai perspėjimai dėl trečiųjų šalių piliečių, įvestų į SIS Sąjungos interesais” (SIS informaciniai perspėjimai).
3Šiai kategorijai nacionaliniu lygiu pridėti išplečiančių objektų duomenys (object extensions) turi būti siunčiami į SIS.
4Nacionalinio objekto duomenys turi atitikti SIS duomenų formatus ir tvarkymo taisykles.
5Turi būti atnaujintas PPPTR ataskaitų modulis, atsižvelgiant į naujai įdiegta perspėjimų kategoriją.
6POLIS programinėje įrangoje turi būti įdiegtas funkcionalumas išsiunčiantis pranešimą SIRENE kai yra įvedamas SIS perspėjimas, kuriam taikomas automatinis SIRENE patvirtinimas.
7Perspėjimų kategorijų sąrašas turi būti konfigūruojamas.
8POLIS programinėje įrangoje turi būti užtikrintas skelbiamų SIS perspėjimų klasifikatorių galiojančių kodų naudojimas.
9POLIS programinėje įrangoje turi būti užtikrintas korektiškas nuotraukų tvarkymas ir atvaizdavimas.
10Su registro objektu susietos nuotraukos turi būti rodomos nenaudojant web naršyklės spartinančios atminties (cache) funkcionalumo – nuotraukos turi būti atnaujinamos kiekvieną kartą atidarant peržiūros langą.
11Neturi būti rodomos klaidos koreguojant nuotraukų aprašymo laukus.
12Turi būti užtikrintas visų į POLIS įkeliamų nuotraukų (tiek rankiniu būdu, tiek per integracines sąsajas) būtinų aprašymo laukų (tokių kaip nuotraukos padarymo data) užpildymas bet sumažinto dydžio (thumbnail) nuotraukos sukūrimas.
13Gyventojų registro nuotraukų integracinė sąsaja turi būti pakeista taip, kad POLIS duomenų bazėje būtų išsaugoma nuotraukų padarymo data.
14POLIS programinėje įrangoje turi būti pakeistos integracinės sąsajos, per kurias į atitinkamus registrus yra įkeliami Gyventojų registro, Užsieniečių registro, Juridinių asmenų registro, Vidaus reikalų pareigūnų registro, Kelių transporto priemonių registro, Transporto priemonių savininkų apskaitos informacinės sistemos, Policijos licencijuojamos veiklos informacinės sistemos duomenys.
15Visi POLIS registruose naudojami išoriniai duomenys turi būti teikiami per VRIP naudojamą integracinę programinę įrangą „Oracle Service Bus“ joje sukuriant naujas arba panaudojant esamas paslaugas (servisus).
16POLIS programinėje įrangoje turi būti užtikrintas įkeliamų priedų failų dydžių apribojimų tvarkymas. Sistemos konfigūracijos nustatymuose turi būti galima nustatyti maksimalius pridedamų failų dydžius (priklausomai nuo lauko tipo).
17Bandant įkelti failą, kurio dydis viršija maksimalų nustatytą, naudotojui turi būti rodomas suprantamas perspėjimas.
18POLIS programinėje įrangoje, tvarkant IAŽR asmens paieškos duomenis, naudotojas, neturintis rolės įvesti 1-o lygio paieškos, neturi galėti tvarkyti (keisti) 1-o lygio paieškos.
19POLIS programinėje įrangoje, tvarkant IAŽR nenustatytos tapatybės duomenis, turi būti užtikrintas privalomų Habitoskopinių duomenų registro laukų užpildymas.
20POLIS programinėje įrangoje, tvarkant IAŽR asmens paieškos duomenis, naujai skelbiant pašalintą SIS perspėjimą, koreguojant paieškos kategoriją turi veikti susietos tarptautinės paieškos kategorijų filtras.
21POLIS programinėje įrangoje, tvarkant PPPTR patikrinimų duomenis, turi būti galima keisti SIS paskelbimo priežastį ir veiksmus esant būsenai „Laukia SIRENE patvirtinimo“.
22POLIS programinėje įrangoje, tvarkant INDR duomenis, mobilių telefonų kategorijoje turi būti galima įvesti SIS perspėjimą, atitinkantį SIS perspėjimo tipą ir kategoriją „Informacinių technologijų įrenginys“ – „Išmanusis įrenginys“.
23POLIS programinėje įrangoje, tvarkant INDR ir ITPR duomenis objektų kategorijose, kuriose galima skelbti SIS perspėjimą, turi būti įdiegta funkcija nustatyti iš anksto numatytą leidimą skelbti registro objekto kategoriją SIS.
24Numatyti leidimai turi būti konfigūruojami POLIS klasifikatorių sistemoje.
25Turi būti pakeista POLIS programinės įrangos naudotojų duomenų funkcija - prisijungusių naudotojų duomenys (įstaiga, pareigos ir kiti) turi būti imami tik iš VRIP naudotojų administravimo sistemos ADMIN III.

Dokumentai15

6858515_Contract notice - general directive, standard regime_0.pdf
espd-request.xml
espd-request.pdf
README.txt
6 IA PD FK.docx
7 IA PD Tiekėjo deklaracija.docx
8 IA PD ATITIKTIES DEKLARACIJA.docx
9 IA PD Deklaracija dėl ES 2022_576.docx
10 IA PD SP.docx
1 IA PD BS .docx
2 IA PD SS.docx
3 IA PD TS.docx
1007_6858515.pdf
4 IA PD PF.docx
2_c4t_6858515_1.xml

tendis.lt · Sukurta recodin.lt