Grįžti į sąrašą

GINKLŲ REGISTRO PROGRAMINĖS ĮRANGOS MODERNIZAVIMO IR PRIEŽIŪROS PASLAUGŲ PIRKIMAS (PPR-1125)

Išanalizuota

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

Atviras konkursasCPV: 72200000 - Programinės įrangos programavimo ir konsultacinės paslaugos
ID: 66390582026-02-26 05:20
Atidaryti CVP IS

Aprašymas

Perkamos Ginklų registro programinės įrangos modernizavimo ir priežiūros paslaugos. Šio pirkimo tikslas – modernizuoti esamą programinę įrangą, atnaujinti ir sukurti naujas integracines sąsajas, kad policijos ir kitos teisėsaugos institucijos galėtų efektyviau keistis informacija apie ginklus, užtikrinti duomenų atsekamumą ir kovoti su neteisėta prekyba šaunamaisiais ginklais. Taip pat bus užtikrinta nuolatinė modernizuotos sistemos garantinė priežiūra.

Kvalifikaciniai reikalavimai

  • 1Tiekėjas sutarties vykdymui privalo turėti ne mažiau kaip žemiau nurodyta kvalifikuotų specialistų (ekspertų), kurie atitiktų žemiau nurodytus reikalavimus.
  • 2Ekspertas Nr. 1 – Projekto vadovas: turintis tarptautiniu mastu pripažįstamą projektų valdymo eksperto kvalifikaciją, patvirtintą PMP sertifikatu arba Prince2 sertifikatu arba kitu lygiaverčiu sertifikatu arba lygiaverčiais tarptautiniu mastu pripažįstamais, reikalaujamą kvalifikaciją įrodančiais dokumentais, arba kitais lygiaverčiais įrodymais.
  • 3Ekspertas Nr. 1 – Projekto vadovas: per paskutiniuosius 5 (penkis) metus turi turėti vadovavimo informacinių sistemų ar registrų kūrimo ir įdiegimo arba modernizavimo sutartims darbo patirtį ne mažiau kaip 1 (vienoje) sėkmingai įvykdytoje (baigtoje) sutartyje.
  • 4Ekspertas Nr. 2 – Informacinių sistemų architektas: turintis tarptautiniu mastu pripažįstamą informacinių sistemų architekto kvalifikaciją, patvirtintą TOGAF Certified sertifikatu arba Oracle Certified Master Java EE Enterprise Architect sertifikatu ar lygiaverčiu sertifikatu arba lygiaverčiais tarptautiniu mastu pripažįstamais, reikalaujamą kvalifikaciją įrodančiais dokumentais, arba kitais lygiaverčiais įrodymais.
  • 5Ekspertas Nr. 3 – Informacinių sistemų analitikas-projektuotojas: turintis tarptautiniu mastu pripažįstamą informacinių sistemų analitiko - projektuotojo kvalifikaciją, patvirtintą OMG Certified UML Professional (Foundation) arba OMG-Certified Expert in BPM 2 Fundamental, arba BCS, Foundation Certificate in Business Analysis, arba kitu lygiaverčiu sertifikatu arba lygiaverčiais tarptautiniu mastu pripažįstamais, reikalaujamą kvalifikaciją įrodančiais dokumentais, arba kitais lygiaverčiais įrodymais.
  • 6Ekspertas Nr. 4 – Programuotojas: turintis tarptautiniu mastu pripažįstamą programuotojo kvalifikaciją, patvirtintą 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 kitais lygiaverčiais tarptautiniu mastu pripažįstamais, reikalaujamą kvalifikaciją įrodančiais dokumentais, arba kitais lygiaverčiais įrodymais.
  • 7Ekspertas Nr. 4 – Programuotojas: turintis programuotojo darbo patirtį bent 1 (vienoje) per paskutinius 5 (penkis) metus sėkmingai įvykdytoje (baigtoje) sutartyje, kurios metu buvo atsakingas už programavimą naudojant JAVA ar lygiavertę technologiją.
  • 8Ekspertas Nr. 5 – Informacinių sistemų saugos ekspertas: turintis tarptautiniu mastu pripažįstamą informacinių sistemų (IS) saugos eksperto kvalifikaciją, patvirtintą 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 sertifikatu arba lygiaverčiais tarptautiniu mastu pripažįstamais, reikalaujamą kvalifikaciją įrodančiais dokumentais, arba kitais lygiaverčiais įrodymais.
  • 9Ekspertas Nr. 5 – Informacinių sistemų saugos ekspertas: turintis saugos eksperto darbo patirtį bent 1 (viename) per paskutinius 5 (penkis) metus sėkmingai įvykdytoje (baigtoje) informacinės sistemos ar registro kūrimo ir diegimo ar modernizavimo sutartyje.
  • 10Ekspertas Nr. 6 – Informacinių sistemų testavimo ekspertas: turintis tarptautiniu mastu pripažįstamą testuotojo kvalifikaciją, patvirtintą ISTQB Certified Tester Foundation Level sertifikatu arba ISEB testing foundation level, arba Certified Associate in Software Testing (CAST) sertifikatu arba lygiaverčiu sertifikatu arba lygiaverčiais tarptautiniu mastu pripažįstamais, reikalaujamą kvalifikaciją įrodančiais dokumentais, arba kitais lygiaverčiais įrodymais.
  • 11Ekspertas Nr. 6 – Informacinių sistemų testavimo ekspertas: turintis informacinių sistemų testavimo darbo patirtį bent 1 (vienoje) per paskutinius 5 (penkis) metus sėkmingai įvykdytoje (baigtoje) informacinės sistemos ar registro kūrimo ir diegimo ar modernizavimo sutartyje.
  • 12Tiekėjas (jo pasitelkiamas jungtinės veiklos partneris) ir jo pasitelkiami subtiekėjai negali kelti grėsmės nacionaliniam saugumui, kai ketinamos sudaryti sutarties pagrindu susidarytų aplinkybės, nurodytos Nacionaliniam saugumui užtikrinti svarbių objektų apsaugos įstatymo 13 straipsnio 4 dalies 1 punkte.
  • 13Tiekė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

Saugumo valdymas

  • 1Tiekėjas privalo vadovautis pripažintomis saugaus programinės įrangos kūrimo metodikomis (pvz., ISO/IEC 27034-1, OWASP Application Security Verification Standard, OWASP Testing Guide arba lygiavertėmis).
  • 2Tiekėjas privalo užtikrinti, kad visi programinės įrangos kūrime dalyvaujantys darbuotojai susipažinę su saugaus programinės įrangos kūrimo metodikomis.
  • 3Tiekėjas privalo atlikti patikrinimą siekdamas identifikuoti pagrindines sistemos saugumo rizikas bei saugumo pažeidžiamumus (nurodytus CWE/SANS TOP 25 Most Dangerous Software Errors, OWASP 10 Most Critical Web Application Security Risks sąrašuose, naujausiose OWASP Application Security Verification Standard, OWASP Testing Guide versijose arba lygiavertėse) ir rastas rizikas bei pažeidžiamumus pašalinti.
  • 4Tiekėjas privalo pateikti deklaraciją, kurioje būtų nurodyta, jog sukurtame Registre nėra CWE/SANS TOP 25, OWASP TOP 10 sąrašuose ir naujausiose OWASP Application Security Verification Standard, OWASP Testing Guide versijose arba lygiavertėse nurodytų rizikų/pažeidžiamumų.
  • 5Tiekėjas privalo pateikti visų, sistemoje naudojamų trečių šalių komponentų sąrašą.
  • 6Tiekėjas privalo imtis tinkamų veiksmų (angl. reasonable effort) užtikrinant, kad trečių šalių komponentai atitinka Perkančiosios organizacijos saugumo reikalavimus.
  • 7Priėmimo testavimo etapo metu ar bandomosios eksploatacijos etapo metu Tiekėjas turi sudaryti visas reikiamas sąlygas Perkančiosios organizacijos atstovų specialistams atlikti atsparumo įsilaužimams testavimą.
  • 8Tiekėjas turi atlikti reikiamus Registro programavimo ir / ar konfigūravimo darbus, atsižvelgiant į Perkančiosios organizacijos atstovų atliktų atsparumo įsilaužimams testavimų rezultatus, kad prieš pradedant eksploatuoti Registro būtų pašalinti visi nustatyti svarbūs saugumo pažeidžiamumai.

Duomenų migravimas

  • 1Registro duomenys turi būti saugomi modernizuotoje duomenų bazėje.
  • 2Turi būti atliktas duomenų migravimas iš esamos Registro duomenų bazės į modernizuoto Registro duomenų bazę.
  • 3Migravimo metu turi būti išlaikyta Registro duomenų nuoseklumas, tarpusavio duomenų sąsajos bei ryšiai su klasifikatorių reikšmėmis.

Diegimo reikalavimai

  • 1Paslaugų teikėjas po bandomosios eksploatacijos turi perduoti Perkančiajai organizacijai modernizuoto Registro išeities kodą ir licencinės programinės įrangos instaliacinius paketus.
  • 2Paslaugų teikėjas turi įdiegti priemones, užtikrinančias automatinį naujų sistemos versijų diegimą, užtikrinant jos veikimą diegimo metu. Turi būti sukonfigūruotas (ir dokumentuotas) programinės įrangos diegimo į testavimo ir gamybinę aplinką procesas ir priemonės taip, kad atsakingas Perkančiosios organizacijos darbuotojas galėtų ją įdiegti ir valdyti konfigūraciją.
  • 3Bet kokie programinės įrangos atnaujinimų diegimai į testavimo ir gamybinę aplinkas turi būti galimi tik iš GitLab esančių išeities tekstų.
  • 4Registro išeities kodas turi būti pateikiamas Tiekėjas naudotoms kūrimo priemonėms suprantamu formatu perkeliant į GitLab. Kartu turi būti pateikiamas sukompiliuotas išeities kodas (parengtas diegimui).
  • 5Paslaugų teikėjas turi dokumentuoti programinės įrangos diegimo į Perkančiosios organizacijos Registro produkcinę ir testavimo aplinkas procesą ir pateikti tam reikalingas programines priemones. Procesas turi būti dokumentuotas taip, kad atsakingas Perkančiosios organizacijos darbuotojas galėtų pagaminti (build) programinę įrangą ir ją įdiegti, valdyti gaminimo ir diegimo konfigūraciją.
  • 6Registro programinė įranga turi būti įdiegta ir sukonfigūruota turimoje IRD gamybinėje aplinkoje. Po įdiegimo turi nesutrikti gamybinėje aplinkoje įdiegtos taikomosios programinės įrangos veikimas.
  • 7Registro programinė įranga turi išlikti darbinga įvykus daliniams techninės įrangos gedimams (angl. failover).
  • 8SSL arba kitos lygiavertės šifravimo priemonės administravimas turi būti aprašytas Registro naudotojo vadove.
  • 9Funkcionalumas, įkeltas į Registro gamybinę aplinką, neturi sutrikdyti kitų Registro esančių funkcijų darbo. Jeigu sutrikdo, laikoma, kad Paslaugos suteiktos nekokybiškai, ir Tiekėjas atlieka klaidų taisymą bei duomenų atstatymo darbus savo lėšomis.

Garantinė priežiūra

  • 1Sukuriamam ar modernizuojamam Registro funkcionalumui suteikiama garantija, galiojanti visą sutarties laikotarpį, ir 12 (dvylika) mėnesių po paskutinio paslaugų perdavimo-priėmimo akto pasirašymo dienos.
  • 2Garantinio laikotarpio metu Tiekėjas turi užtikrinti visų pastebėtų trūkumų tinkamą pašalinimą. Registras privalo būti darbingas, patikimas ir atstatomas po trikdžių.
  • 3Garantinio laikotarpio metu elektronine forma turi būti vedamas pastebėtų klaidų ir jų būsenų kaupimo žurnalas, suteikta galimybė jį pildyti įgaliotiems PO darbuotojams.
  • 4Visi incidentai dėl modernizuojamos įrangos registruojami Informacinių technologijų ir telekomunikacijų pagalbos tarnybos posistemėje ir perduodami Tiekėjui el. paštu spręsti incidentus.
  • 5Tiekėjas el. paštu gautą pranešimą apie incidentą turės užregistruoti savo incidentų valdymo sistemoje ir jam suteikti identifikacinį numerį bei Perkančiajai organizacijai atsakyti apie užregistravimą, incidento sprendimą el. paštu, nurodydamas tą patį incidento numerį.
  • 6Turi būti parengtos prieinamos ir PO tinkamos informavimo apie Registro klaidas ir netikslumus, jų registravimo ir taisymo veiksmų būseną priemonės (suderinti telefonai, el. pašto adresai, klaidų registravimo IS).
  • 7Garantinio laikotarpio metu PO nurodymu ar Tiekėjui savarankiškai aptikus Registro PĮ trūkumus, turi būti atliekami: klaidų ar netikslumų registravimas, klaidų ar netikslumų taisymas, testavimas, atnaujinimas, diegiant pataisymus, dokumentacijos tikslinimas.
  • 8Kritinės klaidos turi būti pašalintos ne vėliau kaip per 4 darbo valandas nuo pranešimo apie incidentą išsiuntimo Tiekėjui.
  • 9Svarbios klaidos turi būti pašalintos ne vėliau kaip per 8 darbo valandas nuo pranešimo apie incidentą išsiuntimo Tiekėjui.
  • 10Kitos klaidos turi būti pašalintos ne vėliau kaip per 20 darbo valandų nuo pranešimo apie incidentą išsiuntimo Tiekėjui.
  • 11Informacija (ataskaita) apie pašalintas ar pataisytas klaidas ir (ar) trikdžius turi būti atnaujinama ir pateikiama ne rečiau kaip kartą per mėnesį.
  • 12Garantinės priežiūros darbai turi apimti: konsultavimo darbus, neatitikimų šalinimo ir klaidų taisymo paslaugas, sugadintų duomenų atstatymą, registro duomenų bazės tvarkymą, Registro veikimui reikalingos programinės įrangos ir tarpusavio sąsajų tvarkymą, Registro administratorių konsultavimą, pagalbos PO teikimą vykdant duomenų atkūrimą iš atsarginių duomenų kopijų.

Testavimo reikalavimai

  • 1Turi būti atliktas Registro priėmimo testavimas, apimantis visą funkcinių reikalavimų dokumentacijoje specifikuotą sistemos funkcionalumą ir visus taikymo atvejus.
  • 2Testavimo aplinkos architektūros principai turi atitikti darbinę sistemos aplinkos architektūrą.
  • 3Testavimo tikslai: įsitikinti, kad įgyvendinti visi funkciniai ir nefunkciniai reikalavimai, įgyvendinimas atliktas tinkama apimtimi, sukurta programinė įranga yra naši ir ergonomiška, identifikuoti ir užregistruoti klaidas, problemas, trūkumus, bei ištaisyti juos.
  • 4Turi būti atlikti vidinis testavimas, priėmimo testavimas (dalyvaujant Tiekėjui, IRD ir kitoms suinteresuotoms šalims) ir Registro sąrankos (kompiliavimo) ir diegimo testavimas (Perkančiosios organizacijos atstovų).
  • 5Į testinę aplinką bus diegiama tik iš Gitlab esančių išeities tekstų pagaminta Registro programinė įranga.
  • 6Atlikti testavimai turi užtikrinti, kad modernizuotas Registras yra tinkamas bandomajai eksploatacijai.
  • 7Testavimų metu turi būti vykdomas identifikuotų klaidų, problemų ir trūkumų registravimas Perkančiosios organizacijos JIRA įrankyje. Už registravimą atsakingas Tiekėjas.
  • 8Tiekėjas turės parengti visus testavimui reikalingus testavimo duomenis ir užtikrinti pakankamai testavimo duomenų, kurie leistų visiškai ištestuoti Registro funkcionalumus.
  • 9Perkančioji organizacija savo iniciatyva gali atlikti bet kokius kitus Registro testavimus ir bandymus (išeities kodų tikrinimą, konfigūracijos tikrinimą, našumo tikrinimą ir kt.). Tiekėjas turės atsižvelgti į jų rezultatus ir atlikti trūkumų šalinimą.

Funkciniai reikalavimai

  • 1Turi būti modernizuotos Registro funkcijos: duomenų paieška, peržiūra, koregavimas, šalinimas, dokumentų formavimas bei ataskaitos.
  • 2Modernizavimo metu turi būti išlaikytas esamas Registro funkcionalumas.
  • 3Registro duomenų paieškos rezultatai turi būti rodomi lentelėje su galimybe pereiti į pasirinkto įrašo detalią formą.
  • 4Duomenų paieškų rezultatus turi būti galima eksportuoti CSV formatu.
  • 5Turi būti modernizuota fizinių asmenų/verslo subjektų paieška su galimybe ieškoti pagal anketinius duomenis.
  • 6Turi būti modernizuota ginklų paieška leidžianti ieškoti Registre registruotų ginklų pagal ginklo duomenis, asmens (savininko) duomenis, atšaudymo duomenis.
  • 7Ginklų paieška turi būti vykdoma ir IGR bei SIS, vaizduojant paieškos rezultatus atskirose lentelėse su galimybe peržiūrėti detalius duomenis.
  • 8Turi būti realizuota/modernizuota universali Registro duomenų paieška, kurios parametrus galima laisvai sukonfigūruoti ir pagal juos ieškoti Registro duomenų.
  • 9Universalios paieškos laukai turi būti laisvai pasirenkami iš esamų Registro duomenų laukų.
  • 10Universalioje paieškoje turi būti galimybė ieškoti ginklų, asmenų ir dokumentų.
  • 11Universalioje paieškoje turi būti realizuotos paieškos sąlygos: lygu, nelygu, daugiau, mažiau, daugiau arba lygu ir mažiau arba lygu.
  • 12Universalios paieškos kriterijaus reikšmės įvedimo forma turi atitikti pasirinktą Registro duomenų lauko tipą: skaičius, eilutė, tekstas, data, lauko klasifikatorius.
  • 13Paieškos užklausoje turi būti galima nurodyti daug kriterijų.
  • 14Turi būti galimybė paieškos užklausos parametrus išsaugoti kaip šabloną suteikiant šablonui pavadinimą, užsikrauti iš šablono, koreguoti ir pašalinti šabloną.
  • 15Turi būti galimybė įvesti naują fizinį asmenį (duomenis atsisiunčiant iš GR) ir juridinį asmenį (duomenis atsisiunčiant iš JAR).
  • 16Turi būti galimybė pakoreguoti fizinio/juridinio asmens duomenis.
  • 17Turi būti realizuota funkcija patikrinti fizinio asmens duomenis kitose sistemose ir atvaizduoti rastus įrašus iš: SIS ir IAR.
  • 18Turi būti galimybė įvesti naujo ginklo duomenis, koreguoti esamo ginklo duomenis.
  • 19Registras turi periodiškai gauti ginklų arešto duomenis iš TAAR ir Sutarčių ir teisių suvaržymų registro apie ginklų sutartinius (priverstinius) įkeitimus bei atnaujinti juos ginklo kortelėje.
  • 20Turi būti galimybė ištrinti ginklo duomenis, jei jie neturi ryšių su kitais įrašais ar IS.
  • 21Turi būti galimybė priskirti, perkelti ginklo nuosavybę fiziniam/juridiniam asmeniui.
  • 22Registre turi būti registruojami išsamūs ginklo identifikavimo (Registro identifikavimo kodas, gamintojas, modelis, kategorija, rūšis, tipas, numeris, kalibras, datos, statusas ir kt.) ir asmens identifikavimo (asmens kodas, vardas, pavardė, adresas, telefono numeris, el. paštas, paso/kortelės duomenys, medicininės pažymos duomenys ir kt.) duomenys.
  • 23Turi būti galimybė formuoti ir spausdinti ginklo pažymėjimą, ginklo de aktyvacijos sertifikatą, pažymą apie fiziniam/juridiniam asmeniui nuosavybės teise priklausančius ginklus.
  • 24Turi būti sukurtos/modernizuotos ataskaitos: Fizinių asmenų turimų ginklų ataskaita, Fizinių asmenų ginklų naudotojų ataskaita, Verslo subjektų turimų ginklų/ginklų dalių ataskaita, Užregistruotų asmenų ataskaita, Areštuotų ginklų ataskaita, Ataskaita apie importuotus/eksportuotus ginklus.
  • 25Suformuotas ataskaitas turi būti galima išsaugoti šiais formatais: pdf, docx, ods, odt, xlsx arba lygiaverčiais.

Duomenų gavimo paslaugos

  • 1Sukurti žiniatinklio paslaugas, sudarančias galimybę pagal asmens duomenis gauti informaciją (duomenis) apie asmeniui šiuo metu priklausančius ar anksčiau priklausiusius ginklus nuosavybės teise.
  • 2Sukurti žiniatinklio paslaugas, sudarančias galimybę pagal ginklo duomenis gauti informaciją (duomenis) apie esamus ir buvusius ginklo savininkus.
  • 3Sukurti funkcionalumą, sudarantį galimybę per žiniatinklio paslaugą iš Ieškomų ginklų registro (ĮGR) gauti duomenis ir informaciją apie ginklo įvykius (įvykio data, aplinkybės, ikiteisminio tyrimo numeris, paiešką paskelbusio pareigūno duomenys, paskelbtų Šengeno perspėjimų duomenys, ginklo radimo, konfiskavimo duomenys ir t.t.).

Kibernetinio saugumo valdymas

  • 1Tiekėjas privalo nedelsiant (iki 24 val.) pranešti apie didelį kibernetinį incidentą, nurodant ar incidentas sukeltas neteisėtų/piktavališkų veiksmų ir galimą tarpvalstybinį poveikį.
  • 2Tiekėjas privalo nedelsiant (iki 72 val.) pranešti apie kitą kibernetinį incidentą, nurodant ar incidentas sukeltas neteisėtų/piktavališkų veiksmų ir galimą poveikį perkančiosios organizacijos tinklams ir informacinėms sistemoms.
  • 3Tiekėjas privalo per vieną mėnesį pateikti galutinę ataskaitą apie kibernetinį incidentą, nurodytą Kibernetinio saugumo įstatymo 18 straipsnio 4 dalies 4 punkte.
  • 4Perkančioji organizacija arba jos įgalioti tiekėjai turi teisę atlikti Tiekėjo atitikties Kibernetinio saugumo reikalavimų aprašo reikalavimams auditą (įskaitant neplaninį), o Tiekėjas turi pareigą sudaryti sąlygas tokiam auditui atlikti.
  • 5Tiekėjas visą sutarties vykdymo laikotarpį privalo ne rečiau kaip kartą per metus, įvykus esminiams pokyčiams ar 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 užtikrinti jo tinklų ir informacinės sistemų spragų, keliančių riziką perkančiosios organizacijos tinklams ir informacinėms sistemoms, valdymą.
  • 8Tiekėjas įsipareigoja užtikrinti, kad jo patalpos, įranga, tinklai ir informacinių sistemų priežiūra, informacijos perdavimas tinklais atitinka Aprašo reikalavimus.
  • 9Tiekėjui fizinė prieiga prie perkančiosios organizacijos tinklų, kitos techninės infrastruktūros ir informacinių sistemų nėra suteikiama. Tiekėjui suteikiama loginė prieiga per perkančiosios organizacijos saugų VPN sprendimą prie kūrimo ar testavimo aplinkų. Atskiru sprendimu (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 Tiekėjo veiksmai yra fiksuojami.

Technologijos ir architektūra

  • 1Registro PĮ turi būti modernizuota taikant trijų sluoksnių architektūrą: duomenų sluoksnis; veiklos logikos sluoksnis; naudotojo sąsajos sluoksnis.
  • 2Registro naudotojo sąsaja turi būti realizuota HTML ir Javascript arba lygiaverčiu pagrindu bei veikti šiuo metu PO ir Registro naudotojų naudojamose interneto naršyklėse: Google Chrome, Microsoft Edge, Mozilla Firefox be papildomų įskiepių.
  • 3Naudotojo ryšys su Registru turi būti šifruojamas SSL(HTTPS) protokolu.
  • 4Registro naudotojo sąsaja turi būti susieta su IRD naudojama vieningo prisijungimo sistema Oracle SSO. Naudotojui SSO turi leisti pereiti iš Registro naudotojo sąsajos į kitas aplikacijas ir atvirkščiai be papildomo prisijungimo.
  • 5Registras turi vykdyti naudotojų autentifikaciją naudodamas ADMIN III. Autentifikacijos metu patikrinama, ar toks naudotojas egzistuoja ir ar jo slaptažodis įvestas teisingai.
  • 6Jei naudotojo slaptažodis teisingai įvestas bet baigęs galioti, Registras turi apie tai pranešti naudotojui ir pasiūlyti pasikeisti slaptažodį.
  • 7Registras turi vykdyti naudotojų autorizaciją naudodamas ADMIN III. Pagal naudotojo turimą teisių krepšelį turi būti leidžiamos tik tos funkcijos ir naudotojo sąsajos elementai, kuriems naudotojas turi teises.
  • 8Tiekėjas turės užkrauti analizės metu nustatytas Registro teises ir roles į ADMIN III (testavimo ir darbines aplinkas).
  • 9Turi būti atnaujinti (sukurti nauji) reikalingi klasifikatoriai (reikšmės, savybės, ryšiai), susieti su išorinių sistemų klasifikatoriais ir įkelti į VRM klasifikatorių posistemės testavimo bei darbines aplinkas. Visas klaidas Tiekėjas turi ištaisyti savo lėšomis. Registro veikimo parametrai turi būti valdomi administravimo srityje.
  • 10Visi automatinių procesų (padaryti Registro naudotojų) veiksmai turi būti audituojami AUDIT III: prisijungimas/atsijungimas, duomenų paieška, įrašo peržiūra, koregavimas, įrašų šalinimas, ataskaitos peržiūra, dokumento formavimas ir kiti funkciniai veiksmai. Duomenys į AUDIT III turi būti siunčiami asinchroniškai, netrikdant Registro veikimo.
  • 11Atliekant Registro modernizavimą turi būti išlaikomi esami Registro architektūriniai sprendimai, nurodyti 1.5 skyriuje. Funkcionalumai turi būti realizuojami „pirmiausia API“ (angl. API-first) principu, siekiant įgalinti duomenų mainus ateities integraciniams poreikiams.

Naudotojo sąsaja ir ergonomika

  • 1Tiekėjas modernizuodamas Registrą turi užtikrinti naudotojo sąsajos ir ergonomikos sprendimus vadovaujamasis LST EN ISO 9241-110:2020 „Žmogaus ir sistemos sąveikos ergonomika. 110 dalis. Dialogo principai (ISO 9241-110:2020)“ standartu arba lygiaverčiu.

Nacionalinio saugumo reikalavimai

  • 1Tiekėjo siūlomos paslaugos turi nekelti grėsmės nacionaliniam saugumui, kai sandorio pagrindu susidarytų aplinkybės, nurodytos Nacionaliniam saugumui užtikrinti svarbių objektų apsaugos įstatymo 13 straipsnio 4 dalies 1 punkte.
  • 2Tiekėjas privalo įrodyti, kad siūlomos paslaugos nekelia grėsmės nacionaliniam saugumui, nėra toliau nurodytų aplinkybių: paslaugų teikimas nebus vykdomas iš VPĮ 92 straipsnio 14 dalyje numatytame sąraše nurodytų valstybių ar teritorijų.

Dokumentacija ir išeities tekstai

  • 1Visa dokumentacija turi būti parengta laikantis bendrinės lietuvių kalbos taisyklių.
  • 2Tiekėjas turės parengti arba atnaujinti Analizės ir projektavimo dokumentaciją, Techninę specifikaciją, Registro duomenų architektūros modelį, Architektūros dokumentaciją, Naudotojo vadovą, Garantijos procedūros dokumentą bei kitą dokumentaciją.
  • 3Visi Registro išeities tekstai turi būti pateikiami PO tų įrankių, kuriais jie sukurti, formatu ir nešifruoti. Tiekėjas privalės išeities tekstus perkelti į PO pateiktą programų išeities tekstų versijų kontrolės sistemos aplinką (GitLab).
  • 4Tiekėjas turi užtikrinti, kad darbų rezultatuose nebus panaudota ir (ar) įterpta ar įtraukta jokių intelektinės nuosavybės objektų, tame tarpe ir kompiuterių programų ar kompiuterių programų kodo, kurios licencijuojamos pagal GPL licencijas (i) draudžia naudoti arba apriboja tokio kodo naudojimą komerciniais tikslais, ar (ii) leidžia naudoti kompiuterių programų kodą su sąlyga, kad naudotojo sukurta kompiuterių programa bus licencijuojama pagal analogišką licenciją, ar (iii) leidžia naudoti kompiuterių programų kodą su sąlyga, kad naudotojo sukurtos kompiuterių programos kodas bus prieinamas tretiesiems asmenims.

Bendrieji nefunkciniai reikalavimai

  • 1Tiekėjas privalo realizuoti visus Techninės specifikacijos reikalavimus.
  • 2Naujai realizuoti (modifikuoti) Registro programinės įrangos funkcionalumai, sauga, greitaveika turi būti ne prastesni nei dabartiniai.
  • 3Registro naudotojas (jei naudotojui suteiktos atitinkamos teisės) turi galėti vykdyti funkciją be papildomų sistemos modifikavimo (arba kūrimo) darbų ir be kitų papildomų veiksmų ir sąnaudų, kai modernizuotas Registras bus įdiegtas.
  • 4Tiekėjas turi pateikti reikiamą programinę įrangą ir licencijas (pvz., aplikacijų serverius, ataskaitų programinę įrangą, programavimo karkasus), reikalingas siūlomo sprendimo realizacijai, net jei jos nėra išreikštinai reikalaujamos specifikacijoje.
  • 5Tiekėjo pateikiama standartinė licencinė programinė įranga turi būti su neriboto galiojimo (angl. Perpetual) licencijomis. Visi programinės įrangos kaštai turi būti įskaičiuoti į pasiūlymo kainą. Turi būti pateikiamos naujausios programinės įrangos versijos.
  • 6Realizuojant naują Registro programinės įrangos funkcionalumą ir funkcionalumo pakeitimus negali būti sutrikdytas sukurtas Registro funkcionalumas, kuriam nevykdomi pakeitimai, ar Perkančiosios organizacijos informacinių sistemų ar registrų veikimo stabilumas.
  • 7Naujo Registro programinės įrangos funkcionalumo ir funkcionalumo pakeitimų realizavimas neturi pareikalauti papildomos techninės ir licencijuojamos programinės įrangos arba papildomo finansavimo. Naujas Registro funkcionalumas turi veikti IRD turimos programinės ir techninės įrangos produkcinėje ir testinėje aplinkoje.
  • 8Registro programinės įrangos naujų funkcionalumų sukūrimas bei esamų funkcionalumų modifikavimas turi užtikrinti duomenų nuoseklumą (angl. consistency), nedalomumą (angl. atomicity), patvarumą (angl. durability) bei atskirtį (angl. isolation).
  • 9Naujai sukurti Registro funkcionalumai privalo neįtakoti įprastinio Registro naudotojų darbo, Registro duomenų bazėje saugomų duomenų teisingumo, neperkrauti Registro aplikacijų, komponentų, duomenų bazių, aplikacijų serverių, apdoroti duomenis realiu laiku, leisti nustatyti duomenų apie pavogtus ir prarastus ginklus atsekamumą ir suteikti galimybę parengti statistinius duomenis dėl nelegaliai įsigytų ginklų darnaus vystymosi rodikliams apskaičiuoti.

Integracinių sąsajų realizavimas

  • 1Paslaugų teikėjas turi modernizuoti ir realizuoti 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ą.
  • 3Tiekėjas turi užtikrinti, kad nebus sutrikdytas jau veikiančių integracinių sąsajų veikimas.
  • 4Tiekėjas turės realizuoti visą reikiamą funkcionalumą, kad aprašytos sąsajos veiktų.
  • 5Turi būti sukurta žiniatinklio paslauga, sudaranti galimybę iš Registro pagal asmens duomenis teikti struktūrizuotus duomenis apie asmeniui priklausančius ir priklausiusius ginklus nuosavybės teise ir pagal ginklo duomenis teikti struktūrizuotus duomenis apie esamus ir buvusius ginklo savininkus.
  • 6Sąsajos su kitomis sistemomis turi būti realizuotos naudojant Perkančiosios organizacijos turimą integracinę terpę Oracle ESB.
  • 7Integracija su Gyventojų registru: gauti fizinio asmens anketinius duomenis, deklaruotą gyvenamąją vietą, žymą, kad asmuo miręs (Žiniatinklio paslauga, pagal poreikį).
  • 8Integracija su Juridinių asmenų registru: gauti juridinio asmens registracijos kodą, pavadinimą, registracijos adresą (Žiniatinklio paslauga, pagal poreikį).
  • 9Integracija su Adresų registru: gauti adreso dalis (savivaldybė, gyvenamoji vieta, gatvė, namas, korpusas, butas) (Žiniatinklio paslauga, pagal poreikį).
  • 10Integracija su PLVIS: gauti/teikti duomenis apie ginklus, fizinius/juridinius asmenis, ginklo nuosavybės duomenis, leidimų naudoti ginklą duomenis; teikti duomenis apie juridinius faktus dėl daikto teisinio statuso pasikeitimo (Duomenų bazė, periodiškai).
  • 11Integracija su IGR: gauti ginklo perspėjimus (įvykio data, aplinkybės, ikiteisminio tyrimo numeris, paiešką paskelbusio pareigūno duomenys, paieškos priežastis, veiksmai radus, informacija apie perspėjimo panaikinimą suradus ginklą) (Žiniatinklio paslauga, pagal poreikį).
  • 12Integracija su SIS: gauti ginklo perspėjimus (ieškomas ginklas) ir asmens perspėjimus (ieškomas asmuo) (Žiniatinklio paslauga, pagal poreikį).
  • 13Integracija su IAR: gauti asmens paieškos perspėjimus (požymį, ar asmuo ieškomas, anketinius duomenis, paieškos priežastį, veiksmus radus) (Žiniatinklio paslauga, pagal poreikį).
  • 14Integracija su kitomis IS (VMI, STT): teikti struktūrizuotus duomenis apie asmeniui priklausančius ginklus nuosavybės teise (Duomenų bazė, Žiniatinklio paslauga, pagal poreikį).
  • 15Integracija su VRIP Klasifikatorių tvarkymo posisteme: gauti su duomenimis susijusių klasifikatorių reikšmes ir jų savybes (Duomenų bazė, periodiškai).
  • 16Integracija su ADMINIII: gauti naudotojo duomenis, prisijungimo duomenis, naudotojo teises (Žiniatinklio paslauga, pagal poreikį).
  • 17Integracija su VRM SSO: gauti naudotojo sesijos duomenis (Pagal poreikį).
  • 18Integracija su AUDIT III: teikti naudotojų Registre atliktus veiksmus (Pagal poreikį).
  • 19Integracija su IRD tinklapiu: teikti ginklų duomenis viešai paieškai ir peržiūrai (Duomenų bazė, periodiškai).
  • 20Integracija su IRD el. paslaugų portalu: teikti Registro išrašą apie asmeniui priklausančius, priklausiusius ginklus nuosavybės teise (Žiniatinklio paslauga, pagal poreikį).
  • 21Integracija su Sutarčių ir teisių suvaržymų registru: teikti apie registruotą ginklą, ginklo savininko duomenis; gauti apie ginklų sutartinius (priverstinius) įkeitimus, žymas apie atliktus notaro vykdomuosius įrašus (Žiniatinklio paslauga, pagal poreikį).
  • 22Integracija su TAAR: teikti apie registruotą ginklą, ginklo savininko duomenis; gauti ginklo arešto duomenis (Žiniatinklio paslauga, pagal poreikį).

Bendrieji funkcionalumo reikalavimai

  • 1Atliekant Registro modernizavimą, kiek įmanoma, turi būti naudojami dabartiniai funkcionalumai (paieškos kriterijų įvedimo, klasifikatorių reikšmių pasirinkimo, paieškos inicijavimo, paieškos rezultatų filtravimo, spausdinimo ir eksportavimo, paieškos kriterijų išvalymo, teisių ir rolių valdymo).
  • 2Naujai kuriamos / modernizuojamos Registro formos kiek įmanoma turi būti automatizuotai užpildomos duomenimis, kurie yra saugomi Registre ar kitose per integracines sąsajas pasiekiamose informacinėse sistemose, duomenų bazėse ir registruose. Naudotojui turi reikėti įvesti tik unikalią, Registre iš anksto nežinomą informaciją.
  • 3Visų naujai kuriamų / modernizuojamų Registro formų laukai ir kiti atributai turės būti detalizuoti ir suderinti su Perkančiąja organizacija detalios analizės ir projektavimo etapų.
  • 4Visoms aprašytoms funkcijoms, kurių metu yra sukuriami duomenys, turi būti realizuojamos tų duomenų redagavimo, šalinimo ir anuliavimo funkcijos, kurios turi būti suderinamos su veiklos logika.
  • 5Visose naujai kuriamose / modernizuojamose Registro duomenų įvedimo formose turi būti realizuoti duomenų įvedimas ranka ir automatizuotas formos užpildymas duomenimis iš duomenų bazės ar per integracines sąsajas (neleidžiant koreguoti gautų duomenų, išskyrus suderintas išimtis).
  • 6Naujai kuriamos / modernizuojamos Registro duomenų įvedimo formos turi būti konstruojamos taip, kad duomenų įvedimas būtų kiek įmanoma labiau struktūrizuotas. Duomenų suvedimui, kur aktualu, turi būti atnaujinti arba sukurti klasifikatoriai.
  • 7Kiekviename naujai kuriamame / modernizuojamame Registro sąraše turi būti galima atlikti spausdinimo ir eksportavimo į PDF, DOCX, XLSX ar pan. funkcijas.
  • 8Kiekviename naujai kuriamame / modernizuojamame Registro sąraše turi būti galima filtruoti ir rikiuoti pagal tam sąrašui priklausančius atributus.
  • 9Naujai sukurtose / modernizuotose Registro duomenų įvedimo formose turi būti naudojamas pagalbinės informacijos (angl. hints) atvaizdavimo funkcionalumas, pateikiant paaiškinamuosius pranešimus naudotojams.
  • 10Naujai kuriamuose / modernizuojamuose Registro sąrašuose turi būti atvaizduojamas įrašų sąraše skaičius ir realizuotas daugumos įrašų pažymėjimo funkcionalumas tam tikrų veiksmų atlikimui (pvz., eksportavimui pasirinktų įrašų).
  • 11Turi būti vykdomas į duomenų įvedimo formas įvedamų duomenų tikrinimas (angl. validation) pagal nustatytas tikrinimo taisykles, įskaitant privalomų duomenų, duomenų formato ir pridedamų rinkmenų plėtinių bei dydžio tikrinimą.
  • 12Turi būti atliekamas loginis tikrinimas tarp formos elementų – vieno formos elemento parinkimas (įvedimas) turi galėti įjungti/išjungti kitus formos elementus.
  • 13Registro informacijos paieškos funkcionalumai turės būti modernizuoti sudarant galimybes atlikti paiešką ir peržiūrėti rezultatus apimant Registro modernizavimo metu sukurtus naujus duomenų parametrus.
  • 14Turi būti modernizuotos Registro administravimo funkcijos susijusios su funkcionalumų realizavimu per Vidaus reikalų integracinės platformos Aplikacijų ir naudotojų administravimo posistemė ADMIN III.
  • 15Turi būti laikomasi bendrų veiklos logikos taisyklių tarp skirtingų Registro komponentų. Tiekėjas turi realizuoti visas su Perkančiąja organizacija detalios analizės ar projektavimo etapų metu identifikuotas veiklos logikos taisykles.

Greitaveikos ir našumo reikalavimai

  • 1Modernizuotų Registro komponentų greitaveika turi būti neprastesnė, nei šiuo metu naudojamo Registro. Tiekėjas turės nustatyti esamą ir atlikti pakartotinį greitaveikos testavimą po modernizavimo.
  • 2Integracinių sąsajų realizacija turi užtikrinti, kad projektavimo metu apibrėžti integraciniai scenarijai įvyks sinchroniniu režimu ir niekaip neigiamai neįtakos Registro aplikacijų naudojimo patogumo ir našumo.
  • 3Priėmimo testavimo etapo metu Tiekėjas turi sudaryti visas reikiamas sąlygas Perkančiosios organizacijos atstovų specialistams atlikti našumo ir greitaveikos testavimą.
  • 4Tiekėjas turi 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 nurodytų reikalavimų.

Programinės įrangos modernizavimas

  • 1Modernizuoti (atnaujinti) Ginklų registro programinę įrangą saugiomis technologijomis.
  • 2Sukurti ne mažiau kaip 2 Registro naudotojo sąsajos prototipo variantus su skirtingais funkcionalumo grupavimo būdais (sukuriant ir Registre esančias funkcijas ir integracines sąsajas), iš kurių PO pasirinks vieną.
  • 3Tiekėjas programinės įrangos modernizavimo metu gali pasirinkti naudoti esamą duomenų bazę arba pasiūlyti sukurti naują atlikdamas esamos duomenų bazės visų duomenų migravimą (apie 250 000 įrašų).
  • 4Pasirinkęs kurti naują duomenų bazę, tiekėjas turi naudoti Perkančiosios organizacijos vieną iš turimą duomenų bazių valdymo sistemų nesukeliant papildomų išlaidų PO susijusių su licenzijų įsigijimu, palaikymu ir infrastruktūros pritaikymu.
  • 5Modernizuota Registro programinė įranga turi sąveikauti (turėti integracinę sąsają) su PLVIS, Sutarčių ir teisių suvaržymų registru, Turto arešto aktų registru, Gyventojų registru, Juridinių asmenų registru, Adresų registru, Ieškomų ginklų registru, Šengeno informacine sistema (siekiant geresnio duomenų apie pavogtus ir prarastus ginklus atsekamumo).
  • 6Atnaujinta Registro integracinė sąsaja su PLVIS turi užtikrinti duomenų gavimą ir teikimą iš/į PLVIS, taip pat apimti Registre esančių duomenų atnaujinimą (pvz., duomenys apie ginklo sunaikinimą, praradimą, grąžinimą, perleidimą, paveldėjimą keliems savininkams ir kitus juridinius faktus dėl daikto teisinio statuso pasikeitimo teismo sprendimu, kitus istorinius duomenis) prioritetą teikiant informacijos gavimui per informacinių sistemų sąsają.
  • 7Modernizuojant Registro programinę įrangą turi būti išlaikytas visas šiuo metu esamas Registro funkcionalumas.

Kūrimo ir demonstracijų reikalavimai

  • 1Registro išeities kodų laikymui turi būti naudojama PO kodo saugykloje Gitlab.
  • 2Tiekėjas kūrimo etape turi atlikti Registro demonstracijas gyvai demonstruojant sistemos veikimą (ne prototipo).
  • 3Iki priėmimo testavimo etapo pradžios Perkančiajai organizacijai turi būti pademonstruotas visas Registro funkcionalumas, išskyrus tą funkcionalumą, kuris bus suderintas kaip nedemonstruotinas.
  • 4Demonstracijų tikslas – supažindinti Perkančiąją organizaciją su modernizuojamu Registru bei gauti atsiliepimus dėl kuriamo/modernizuojamo funkcionalumo.
  • 5Demonstracijų metu išsakomi atsiliepimai (pastabos) turi būti registruojami susitikimo protokoluose ar kita sutarta forma (pavyzdžiui, specializuotoje klaidų registravimo ir sekimo sistemoje).
  • 6Funkcionalumo demonstraciją turi vykdyti Tiekėjas, o Perkančiosios organizacijos atstovai turi teikti atsiliepimus.

Bandomosios eksploatacijos reikalavimai

  • 1Turi būti atlikta Registro bandomoji eksploatacija.
  • 2Bandomosios eksploatacijos tikslai: užtikrinti Registro kokybę, išbandyti gamybinę Registro komponentų konfigūraciją, identifikuoti ir pašalinti defektus, stabilizuoti darbinės aplinkos konfigūraciją.
  • 3Bandomosios eksploatacijos veiklas Tiekėjas turės vykdyti pagal Perkančiosios organizacijos atstovų pateiktą bandomosios eksploatacijos planą ir metodiką.
  • 4Bandomoji eksploatacija yra baigiama, kai tenkinami bandomosios eksploatacijos priėmimo kriterijai, pateikti metodikoje.
  • 5Bandomoji eksploatacija turi trukti ne trumpiau nei 2 savaites.

Dokumentai14

  • 2_IA_PD_SS 20260203135314185 1 (003).docx
  • 3 IA PD TS 20260203135316154 1.docx
  • 4+IA+PD+PF.docx
  • 6+IA+PD+FK.docx
  • 8 IA PD ATITIKTIES DEKLARACIJA.docx
  • 9 IA PD Deklaracija dėl ES 2022_576.docx
  • espd-request.xml
  • espd-request.pdf
  • README.txt
  • 6639058_Contract notice - general directive, standard regime_0.pdf
  • 1007_6639058.pdf
  • 1 IA PD BS 20260203135312217 1.docx
  • 7 IA PD Tiekėjo deklaracija_tarptautiniam pirkimui.docx
  • 2_c4t_6639058_1.xml
tendis.lt · Sukurta recodin.lt