Lietuvos Nacionalinės Šengeno informacinės sistemos (NSIS) komponentų Tarptautinių ryšių valdybos informacinės sistemos (TRVIS) ir Lietuvos migracijos informacinės sistemos (MIGRIS) integracijos įdiegimo paslaugų pirkimas (PPR-244)

Išanalizuota

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

Rinkos konsultacijaCPV: 72200000 - Programinės įrangos programavimo ir konsultacinės paslaugos

ID: 71279292026-03-26 13:54

Aprašymas

Perkamos integracijos įdiegimo paslaugos, skirtos atnaujinti Nacionalinės Šengeno informacinės sistemos (NSIS) sąsajas, kad būtų automatizuotas perspėjimų papildomų duomenų tvarkymas ir užtikrintos SIRENE biuro funkcijos. Bus atnaujintos sąsajos su Lietuvos kriminalinės policijos biuro Tarptautinių ryšių valdybos informacine sistema (TRVIS) ir Lietuvos migracijos informacine sistema (MIGRIS), siekiant efektyvinti informacijos mainus ir konsultacijas su užsienio institucijomis.

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ą).

Techniniai reikalavimai

Diegimo reikalavimai

1Paslaugų teikėjas po bandomosios eksploatacijos turi perduoti Perkančiajai organizacijai modernizuotų Sąsajos 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 Sąsajos sistemų naudotojų konsultavimą visais su Sąsajos sistemų programinės įrangos diegimu susijusiais klausimais.
5Sąsajos sistemų išeities kodai turi būti pateikiami Paslaugų teikėjo naudotoms kūrimo priemonėms suprantamu formatu perkeliant į GIT.
6Paslaugų teikėjas turi dokumentuoti programinės įrangos diegimo į Sąsajos sistemų testavimo ir gamybinę aplinkas 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 (angl. 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ą.

Saugumo reikalavimai

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“, kuriame periodiškai išanalizuojama ir paskelbiama dešimt kritiškiausių pažeidžiamumų, aptinkamų internetinių technologijų pagrindu sukurtose aplikacijose. Paslaugų 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ų. Jei atsparumo įsilaužimams testavimo metu bus nustatytas saugumo pažeidžiamumas, jis turi būti pašalintas iki funkcionalumų eksploatavimo pradžios.
3Atliekant Sąsajos sistemų modernizavimą neturi būti išjungiami ar kitaip pažeidžiami esami saugumo sprendimai.
4Siekiant išvengti perteklinės auditavimo informacijos kaupimo tikslūs audito įrašų darymo momentai turi būti suderinti su Perkančiąja organizacija analizės ar projektavimo metu.
5Paslaugų teikėjas turi užtikrinti, kad siūlomos paslaugos atitinka Organizacinių ir techninių kibernetinio saugumo reikalavimų, taikomų kibernetinio saugumo subjektams, apraše nurodytus reikalavimus.
6Teikiant paslaugas turi būti vadovaujamasi saugaus projektavimo ir kodavimo (angl. Secure Coding) praktika ir metodais (The Open Web Application Security Project (OWASP) Secure Coding Practices, OWASP application security verification standard ar lygiaverčius), o atliekant 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, siekiant užtikrinti, kad paslaugų rezultatai neturėtų saugumo spragų.
7Žiniatinklio paslaugų naudojimo atveju žiniatinklio paslaugų sauga turi būti vykdoma vadovaujantis WS-S (Web Services Security) standarto arba lygiaverčiais reikalavimais.
8Priė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ą.
9Paslaugų teikėjas turės atlikti reikiamus Sąsajos 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 Sąsajos sistemas būtų pašalinti nustatyti saugumo grėsmes keliantys trūkumai.
10Paslaugų teikė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į.
11Paslaugų teikė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.
12Paslaugų teikė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, nurodyta ši informacija pagal Kibernetinio saugumo įstatymo 18 straipsnio 4 dalies 4 punktą.
13Perkančioji organizacija arba jos įgalioti paslaugų teikėjai turi teisę atlikti Paslaugų teikėjo atitikties Kibernetinio saugumo reikalavimų aprašo, patvirtinto Lietuvos Respublikos Vyriausybės 2018 m. rugpjūčio 13 d. nutarimu Nr. 818 „Dėl Lietuvos Respublikos kibernetinio saugumo įgyvendinimo“, (toliau – Aprašas), reikalavimams auditą (įskaitant neplaninį), o ir Paslaugų teikėjas turi pareigą sudaryti sąlygas tokiam auditui atlikti sutarties vykdymo laikotarpiu ar įvykus dideliam incidentui.
14Paslaugų teikė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ą.
15Paslaugų teikėjas privalo reguliariai, ne rečiau kaip kartą per metus, įvertinti savo atitiktį Kibernetinio saugumo įstatymui, Aprašo ir Paslaugų teikėjo patvirtintiems kibernetinio saugumo politikos dokumentuose nustatytiems reikalavimams.
16Paslaugų teikėjas įsipareigoja užtikrinti jo tinklų ir informacinės sistemų spragų, keliančių riziką perkančiosios organizacijos tinklams ir informacinėms sistemoms, valdymą.
17Paslaugų teikėjas įsipareigoja užtikrinti, kad jo patalpos, įranga, tinklai ir informacinių sistemų priežiūra, informacijos perdavimas tinklais atitinka Aprašo reikalavimus.
18Paslaugų teikėjui fizinė prieiga prie perkančiosios organizacijos tinklų, kitos techninės infrastruktūros ir informacinių sistemų nėra suteikiama. Paslaugų teikėjui suteikiama loginė prieiga per perkančiosios organizacijos saugų VPN sprendimą prie kūrimo ar testavimo aplinkų. Atskiru perkančiosios organizacijos sprendimu (pvz. sprendžiant kritinius incidentus), laikina loginė prieiga gali būti suteikta prie darbinių aplinkų. Loginė prieiga suteikiama prie perkančiosios organizacijos kontroliuojamo nuotolinio darbalaukio serverio, kuriame visi Paslaugų teikėjo veiksmai yra fiksuojami.

Testavimo reikalavimai

1Turi būti atliktas 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šą.
2Priėmimo testavimas (angl. Acceptance testing) turi būti atliekamas dalyvaujant Paslaugų teikėjui, Perkančiajai organizacijai ir kitoms suinteresuotoms šalims.
3Priėmimo testavimo tikslai: įsitikinti, kad yra įgyvendinti visi funkciniai ir nefunkciniai specifikacijos reikalavimai; įsitikinti, kad reikalavimų įgyvendinimas atliktas tinkama apimtimi; nustatyti ar reikalavimų įgyvendinimas tenkina Perkančiąją organizaciją ir kitas suinteresuotas šalis.
4Atliktas priėmimo testavimas turi užtikrinti, kad atnaujintos Sąsajos 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. 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ę.
6Paslaugų teikėjas turi parengti visus testavimui reikalingus testavimo duomenis.
7Paslaugų teikėjas turi užtikrinti, kad priėmimo testavimo metu Sistemose būtų pakankamai testinių duomenų, kurie leistų visiškai ištestuoti atnaujintus funkcionalumus.

Auditavimo reikalavimai

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

Greitaveikos reikalavimai

1Atnaujintų komponentų greitaveika turi būti neprastesnė, nei iki atnaujinimo.
2Integracinių sąsajų realizacija turi užtikrinti, kad projektavimo metu apibrėžti integraciniai scenarijai įvyks per ne ilgesnį nei 1 sekundės laiko tarpą.
3Priėmimo testavimo etapo metu (ar kitu sutartu metu) Paslaugų teikėjas turi sudaryti visas reikiamas sąlygas Perkančiosios organizacijos atstovų specialistams atlikti atnaujintų Sąsajos sistemų našumo ir greitaveikos testavimą.
4Paslaugų teikėjas turi atlikti reikiamus atnaujintų Sąsajos sistemų 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ų.

Architektūros reikalavimai

1Sąsajos sistemų modernizavimo metu neturi būti atliekami esminiai Sąsajos sistemų architektūros pakeitimai.
2Atliekant Sąsajos 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.
3Atliekant sąsajos su MIGRIS atnaujinimą, neturi būti keičiami ar kitaip neigiamai įtakojami MIGRIS aukšto prieinamumo sprendimai.

Dokumentacijos reikalavimai

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ą: TRVIS techninė specifikacija; TRVIS naudotojo sąsajos specifikacija; MIGRIS techninė specifikacija; MIGRIS naudotojo sąsajos specifikacija.
5Paslaugų teikėjo 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).

Projekto tikslas ir apimtis

1Sąsajų atnaujinimo tikslas – užtikrinti sistemų integraciją keičiantis informacija dėl Šengeno informacinėje sistemoje (SIS) paskelbtų perspėjimų bei vykdant konsultacijas su užsienio valstybių institucijomis klausimais, numatytais ES Reglamentuose.
2Sąsajos su MIGRIS atnaujinimas įdiegiant galimybę keistis SIRENE formomis apie SIS perspėjimų duomenis su TRVIS.
3Sąsajos su TRVIS atnaujinimas įdiegiant galimybę keistis SIRENE formomis apie SIS perspėjimų duomenis su MIGRIS.
4Įdiegtos kitos Sąsajų funkcijos, leidžiančios tvarkyti SIRENE formas, dalyvaujančios apsikeitime tarp NSIS, SIS, MIGRIS, TRVIS.
5Įdiegtas Sąsajos funkcionalumas MIGRIS siųsti ir gauti SIRENE formas, keičiantis informacija dėl SIS perspėjimų, kurių tvarkymas yra Migracijos departamento kompetencijoje.
6Įdiegtas Sąsajos funkcionalumas TRVIS persiųsti iš užsienio SIRENE gautas formas bei kitus pranešimus į MIGRIS bei iš MIGRIS gautas formas užsienio adresatams automatizuojant procesą.

Duomenų bazės reikalavimai

1Sąsajos sistemų duomenys turi būti indeksuojami, užtikrinant užklausų apdorojimo spartą.
2Duomenų bazės turi būti normalizuotos, duomenų struktūra turi būti aiškiai apibrėžta, turi būti nustatyti duomenų vientisumo apribojimai (angl. Integrity Constraints).

Paslaugų teikimo reikalavimai

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 (angl. 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.

Priėmimo testavimo kriterijai

1Įvykdyti visi testavimo scenarijai.
2Modernizuota sistema atitinka funkcinius ir nefunkcinius reikalavimus.
3Sutartas likusių klaidų, su priimtina rizika, išsprendimo terminas tenkinant šiuos kriterijus: 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.

Naudotojo sąsajos reikalavimai

1Paslaugų teikėjas turi išlaikyti esamą Sąsajos sistemų naudotojo sąsajų dizaino standartą atnaujintuose komponentuose.

Sąveikos su TRVIS reikalavimai

1Turi būti sukurta funkcija persiųsti gautas užsienio SIRENE formas į MIGRIS naudojant žiniatinklio paslaugų (angl. web service) ar lygiavertę sąsają. Žiniatinklio paslauga turės būti sukurta MIGRIS pusėje.
2Turi būti galimybė konfigūruoti formos požymius, pagal kuriuos vykdomas automatinis (be naudotojo veiksmų) persiuntimas į MIGRIS (pvz. formos tipas, SIS perspėjimo priežastis ir pan.).
3Turi būti galimybė naudotojui atlikti persiuntimą rankiniu būdu.
4Formos persiuntimo faktas ir rezultatas turi būti atvaizduojamas formos peržiūros lange ir fiksuojamas audito žurnale.
5Įvykus persiuntimo klaidai turi būti informuojamas TRVIS naudotojas.
6Turi būti sukurta funkcija gauti SIRENE formas iš MIGRIS naudojant žiniatinklio paslaugų ar lygiavertę sąsają.
7Turi būti atliekamas gautų iš MIGRIS formų patikrinimas duomenų schemos (xsd) atitikimui. Apie gautas netinkamas formas turi būti informuojami nustatyti TRVIS ir MIGRIS naudotojai.
8Turi būti galimybė konfigūruoti formos požymius, pagal kuriuos vykdomas automatinis gautos formos persiuntimas užsienio SIRENE adresatams.
9Iš MIGRIS gautos formos turi būti automatiškai registruojamos TRVIS bylose.
10Turi būti sukurta funkcija automatiškai persiųsti TRVIS gautus elektroninio pašto pranešimus į MIGRIS naudojant žiniatinklio paslaugų ar lygiavertę sąsają. Turi būti galimybė konfigūruoti el. pašto pranešimo požymius (pvz. siuntėjas, gavėjas, tema ir pan.) pagal kuriuos vykdomas automatinis persiuntimas.

Galutinio priėmimo reikalavimai

1Galutinis atnaujintų Sąsajos 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.
2Sąsajos sistemų 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ą.
5Perkanč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, kaip ši sąvoka apibrėžta Lietuvos Respublikos autorių teisių ir gretutinių teisių įstatyme, 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.

Sąveikos su MIGRIS reikalavimai

1Turi būti realizuotos žiniatinklio paslaugų (web service) ar lygiavertės sąsajos, kuriomis MIGRIS vykdytų SIRENE formomis (G, H, R, M, N, O, U) konsultacijų gavimą ir atsakymų išsiuntimą. SIRENE formų specifikacija turi atitikti Data Exchange Between SIRENEs (DEBS) versijos 2.0.5 ir duomenų schemos versijos 5.0.5 (ar naujausių naudojamų versijų sutarties vykdymo metu) reikalavimus.
2Pagal gautoje SIRENE formoje esančius asmens duomenis turi būti identifikuojamas fizinis asmuo, o forma susieta su MIGRIS fizinio asmens byla. Apie nesėkmingai identifikuotą asmenį turi būti informuojamas MIGRIS naudotojas. Turi būti galimybė MIGRIS naudotojui priskirti (ar pakeisti anksčiau priskirtą) konsultaciją MIGRIS fizinio asmens bylai.
3Apie nustatytų konsultacijų (formų) gavimą turi būti informuojamas MIGRIS naudotojas.
4Asmens identifikavimui pagal Šengeno informacinės sistemos identifikatorių (Schengen ID) turi būti modifikuota SIS sistemos integracinė sąsaja.
5MIGRIS byloje, gautoms SIRENE formoms, naudotojas turi galėti paruošti atsakymą ir jį išsiųsti SIRENE kanalu.
6Turi būti realizuotas susijusių veiksmų atvejis – automatiniu būdu ištrinamas SIS perspėjimas dėl grąžinimo kartu su draudimu atvykti ir paskelbiamas SIS perspėjimas dėl draudimo atvykti arba ištrinamas SIS perspėjimas dėl grąžinimo.
7Turi būti galima peržiūrėti gautus konsultacijų kreipinius ir konsultacijų atsakymus ir jų būsenas. Sąrašas turi būti filtruojamas pagal analizės metu suderintus parametrus. Prieiga prie sąrašo valdoma pagal ADMIN3 nustatytas MIGRIS naudotojas roles.
8Apie nesėkmingai išsiųstus konsultacijų atsakymus turi būti informuojamas MIGRIS naudotojas.
9Konsultacijų užklausų ir atsakymų SIRENE formų duomenys turi būti automatiškai ištrinti po 1 metų nuo perspėjimo galiojimo pabaigos, išskyrus atvejus, kai formos bus priskirtos MIGRIS byloms.

Bendrieji funkciniai reikalavimai

1Atnaujinant 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.
2Teisių ir rolių mechanizmas turi būti papildytas naujomis teisėmis ir rolėmis, reikalingomis vykdyti šioje Techninėje specifikacijoje apibrėžtas funkcijas ir veiksmus.
3Pagal turimas naudotojo prieigos teises turi būti galimybė inicijuoti konkretaus duomenų įrašo peržiūrą, koregavimą, trynimą.
4Visoms šioje Techninėje specifikacijoje aprašytoms 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.
5Siekiant įdiegti automatinius (pusiau automatinius) sprendimus, visos 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.
6Visos formos ir šablonai, kiek įmanoma, turi būti automatizuotai užpildomi duomenimis, kurie yra saugomi naudotojo paskyroje, Sąsajos sistemų duomenų struktūrose ar kitose per integracines sąsajas pasiekiamose informacinėse sistemose ir registruose. Naudotojui turi reikėti įvesti tik unikalią, iš anksto nežinomą informaciją.
7Turi būti realizuotas pagalbinės informacijos (angl. Hints) funkcionalumas panaudojant esamą Sąsajos sistemų funkcionalumą, kuris leidžia naudotojams pateikti paaiškinamuosius pranešimus tose vietose, kuriose gali kilti neaiškumų siekiant suprasti reikalingus atlikti veiksmus.
8Turi būti vykdomas išorinių ir vidinių Sąsajos sistemų naudotojų informavimas sisteminiais pranešimais, el. paštu apie naudotojui aktualius įvykius. Informavimui turi būti naudojamas dabartinis pranešimų funkcionalumas, išplečiant jį galimybėmis vykdyti informavimą šioje Techninėje specifikacijoje aprašytų funkcionalumą atvejais.

Programinė įranga ir licencijos

1Atnaujintų Sąsajos sistemų ir visų jų komponentų naudojimui turi būti nereikalingos mokamos ar kitaip naudojimą apribojančios programinės įrangos licencijos.
2Jei tam tikriems šioje techninėje specifikacijoje numatytiems funkcionalumas bus reikalingos mokamos licencijos, joms taikomi kiti šioje techninėje specifikacijoje nustatyti reikalavimai. Turi būti pateikiamos naujausios programinės įrangos versijos (taikoma tiek mokamoms, tiek nemokamoms licencijoms).
3Paslaugų teikėjas, įvertinęs specifikacijos reikalavimus, privalo pateikti reikiamą programinę įrangą ir licencijas (ar bet kokius kitus leidimus (sertifikatus, prenumeratas ir pan.) reikalingas atnaujinamų Sąsajos sistemų dalių sprendimo realizacijai.
4Paslaugų teikėjo pateikiama standartinė licencinė programinė įranga (angl. Commercial Off-The-Shelf Software), kuri reikalinga atnaujintų Sąsajos sistemų dalių veikimui, turi būti pateikiama kartu su visomis reikiamomis licencijomis neriboto galiojimo laikotarpiui, jei gamintojas siūlo tokias licencijas, kitu atveju, jei gamintojas tokių licencijų nesiūlo, - laikotarpiui nuo Sąsajos sistemos komponento, kurio veikimui reikalingos licencijos, 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ų Sąsajos 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ų Sąsajos sistemų veikimą ir naudojimą nuo sukurto komponento, kurio veikimui reikalingos licencijos, 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ų Sąsajos sistemų dalių veikimui reikalingos licencijos.
12Pateikiamų 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.

Bendrieji nefunkciniai reikalavimai

1Įgyvendinant reikalavimus negali būti neigiamai įtakojamas dabartinis Sąsajos sistemų funkcionalumas.
2Paslaugų teikėjas turi atsižvelgti į paslaugų tiekimo metu lygiagrečiai vykdomų kitų pirkimų, skirtų atnaujinti Sąsajos sistemas reikalavimus ir užtikrinti pateiktų atnaujinimų suderinamumą.

Integracinių sąsajų reikalavimai

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

Reikalavimai sąrašams ir paieškai

1Sąrašuose turi būti realizuotas puslapiavimas.
2Sąrašuose turi būti realizuotas daugelio įrašų pažymėjimo funkcionalumas tam tikrų veiksmų atlikimui (pvz., eksportavimui, šalinimui pasirinktų įrašų).
3Turi būti galima sąrašą spausdinti bei eksportuoti į PDF, WORD ar lygiavertes rinkmenas. Turi būti galimybė valdyti eksportuojamų sąrašo objektų apimtį.
4Turi 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.
5Są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.
6Tekstiniuose paieškos laukuose turi būti realizuota paieška pagal žodžio ar skaičių junginio fragmentą ir pilną žodį.
7Paieška turi būti atliekama pagal lietuviškas raides ir vietoje lietuviškų raidžių naudojant lotyniškus raidžių atitikmenis (pavyzdžiui „š“ ir „s“ raides traktuojant kaip vieną).
8Paieška turi būti vykdoma neatsižvelgiant į didžiąsias ir mažąsias raides.
9Paieška turi būti vykdoma tik tuose komponentuose ir duomenų aibėje, prie kurių Sąsajos sistemų naudotojas turi prieigos teises.
10Paieškos rezultatuose turi būti pateikiama ir giminingų reikšmių rezultatai (pavyzdžiui, jeigu paieškos frazė yra „vizito“, tai į rezultatus turi būti įtraukta ir vizitas, vizitui, vizitams ir t.t.).
11Paieškos rezultatai turi būti pateikiami sąrašo forma, jei nesuderinama kitaip.
12Ten kur aktualu, atlikus paiešką, turi būti rodomas paieškos rezultatų skaičius.
13Paieškos / filtravimo funkcijos turi būti įdiegtos visuose naujai kuriamuose komponentuose.

Bandomosios eksploatacijos kriterijai

1Atnaujinta visa susijusi dokumentacija.
2Išbandytos ir patikrintos visos funkcijos.
3Modernizuota sistema atitinka funkcinius ir nefunkcinius reikalavimus.
4Sutartas likusių klaidų, su priimtina rizika, išsprendimo terminas tenkinant šiuos kriterijus: 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.

Garantinės priežiūros reikalavimai

1Paslaugų teikėjas garantinio aptarnavimo metu pagal suderintą Sąsajos 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 Sąsajos sistemų funkcionalumas, pateikta ir įdiegta kita programinė bei sisteminė programinė įranga.
3Paslaugų teikėjas garantinio aptarnavimo metu įsipareigoja užtikrinti visus šioje Techninėje specifikacijoje Sąsajos sistemoms keliamus reikalavimus.
4Garantinio aptarnavimo trukmė – 24 mėnesiai, nuo paslaugų perdavimo-priėmimo akto pasirašymo dienos.
5Sistemų garantinis aptarnavimas apima: Sąsajos sistemų neatitikimų funkciniams reikalavimams ir veikimo klaidų bei kritinių klaidų šalinimą bei kitas Lietuvos Respublikos įstatymais ir norminiais aktais numatytas garantijas.
6Sąsajos 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.
7Prarastų, sugadintų duomenų atstatymą, kai gedimo priežastis yra Paslaugų teikėjo pateiktos programinės įrangos netinkamas veikimas.
8Nustačius, kad atsirado Sąsajos 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.
9Sąsajos sistemų 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.
10Sąsajos sistemų 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.
11Sąsajos sistemų 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.
12Sprendimą, kokio tipo (kritinė, vidutinė, žemo prioriteto) klaida yra nustatyta, priima Perkančiosios organizacijos paskirti atsakingi asmenys, suderinę su Paslaugų teikėjo paskirtais atsakingais asmenimis.
13Paslaugų teikėjas turi suteikti prieigą paskirtiems Sąsajos sistemos naudotojams prie klaidų registravimo sistemos.
14Informacija apie pašalintas (pataisytas) klaidas ir (ar) trikdžius ataskaitos forma turi būti atnaujinama ir pateikiama kartą per ketvirtį.

Šablonų ir klasifikatorių valdymas

1Visoms kuriami šablonai, šabloniniai dokumentai, klasifikatoriai turi turėti jų naudojimo ir matymo sistemoje taisyklių nustatymo ir redagavimo galimybes.
2Turi būti galima nurodyti šias objekto naudojimo sistemoje taisykles: datos rėžius; susiejimą su kito objekto naudojimo ir matymo taisyklėmis; rankinį objekto matymo ir naudojimo įjungimą ir išjungimą; nustatytas koregavimo galimybes.
3Atliekant šablonų, šabloninių dokumentų, klasifikatorių koregavimą turi būti galima pasirinkti, ar turi būti sukuriama nauja šablono, šabloninio dokumento, klasifikatoriaus versija, ar turi būti koreguojama esama objekto reikšmė.
4Iš naudotojo perspektyvos senesnės objektų versijos turi būti naudojamos atvaizduojant duomenis, kurie buvo sudaryti naudojant tuo metu aktualią šablonų, šabloninių dokumentų, klasifikatorių versiją. Naudotojui inicijuojant naujų objektų sukūrimą turi būti naudojamos aktualios šablonų, šabloninių dokumentų, klasifikatorių versijos.
5Turi būti galimybė inicijuoti ir senesnių versijų objektų sukūrimą, kai administravimo priemonėmis yra nustatytos taisyklės leidžiančios atlikti tokį veiksmą.

Analizės ir projektavimo reikalavimai

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 (angl. 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 (angl. 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.

Bandomosios eksploatacijos reikalavimai

1Turi būti atlikta atnaujintų Sąsajos sistemų bandomoji eksploatacija.
2Bandomosios eksploatacijos tikslai: užtikrinti atnaujintų Sąsajos sistemų komponentų atitiktį ir tinkamą veikimą; išbandyti gamybinę Sąsajos 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 Sąsajos sistemų infrastruktūrą darbui: atlikti Sąsajos sistemų komponentų konfigūravimą, kad visi bandomosios eksploatacijos dalyviai turėtų galimybę prisijungti prie Sąsajos sistemos iš savo darbo vietų. Paslaugų teikėjas turi pateikti rekomendacijas dėl naudotojų darbo vietų paruošimo; sumigruoti (įkelti ir suvesti) visus Sąsajos 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.

Duomenų įvedimo ir tikrinimo reikalavimai

1Turi būti vykdomas į duomenų įvedimo formas įvedamų duomenų tikrinimas (angl. validation).
2Turi būti tikrinami privalomi įvesti duomenys.
3Turi būti tikrinamas duomenų formatas (datos, skaičiaus, teksto ar kitas nustatytas taisykles).
4Turi būti tikrinami pridedamų rinkmenų plėtiniai ir rinkmenos dydis.
5Turi būti atliekamas loginis tikrinimas tarp formos elementų – vieno formos elemento parinkimas (įvedimas) turi galėti įjungti / išjungti kitus formos elementus ir pan.
6Suderintose vietose turi būti naudojama turinio teksto rengyklė (redaktorius), kuri turi veikti WYSIWYG principu (angl. What You See Is What You Get, liet. „tai, ką matote, atitinka tai, ką gausite“) 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ą.
7Sąsajos sistemų 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.
8Į Sąsajos sistemą galimų įkelti rinkmenų formatai turi būti tikrinami naudojant esamus leidžiamų įkelti rinkmenų formatų tikrinimo funkcionalumus.
9Turi būti realizuotos bendrosios veiklos logikos taisyklės tarp skirtingų esamų ir naujai kuriamų funkcinių modulių ir komponentų.

Dokumentai4

2_Techninė specifikacija.docx
3_Pirkimo užduotis.docx
1007_7127929.pdf
1_Kvietimas_rinkos_konsultacija.docx

tendis.lt · Sukurta recodin.lt