Neveiksnių ir ribotai veiksnių asmenų, Testamentų ir Vedybų sutarčių registrų vystymo ir priežiūros paslaugos
Išanalizuota
VĮ Registrų centras (PV)
Rinkos konsultacijaCPV: 72200000 - Programinės įrangos programavimo ir konsultacinės paslaugos
ID: 73991342026-04-15 10:15
Atidaryti CVP ISAprašymas
Perkamos Neveiksnių ir ribotai veiksnių asmenų, Testamentų ir Vedybų sutarčių registrų (NIRVAR, TRIS, VSR) vystymo ir priežiūros paslaugos. Šios paslaugos apima esamų informacinių sistemų modernizavimą, naujų funkcionalumų kūrimą, klaidų šalinimą ir techninę pagalbą, siekiant užtikrinti sklandų ir saugų registrų veikimą.
Kvalifikaciniai reikalavimai
- 1Tiekėjas turi turėti (arba gali pasitelkti) kvalifikuotus už pirkimo sutarties vykdymą atsakingus specialistus.
- 2Specialistas – Projekto vadovas: Per pastaruosius 5 metus turi ne trumpesnę nei 1 metų vadovavimo informacinių sistemų kūrimo projektams patirtį.
- 3Specialistas – IS analitikas: Per pastaruosius 5 metus turi ne mažiau kaip 3 metų veiklos procesų analizės patirtį.
- 4Specialistas – IS architektas: Per pastaruosius 3 metus vykdė informacinių sistemų architekto funkcijas, kuriant informacinę sistemą, kuri atitinka šiuos reikalavimus: 1) buvo naudota reliacinė duomenų bazių valdymo (RDBVS) sistema (arba lygiavertė); 2) sistema yra integruota su ne mažiau nei dvejomis informacinėmis sistemomis; 3) sistema kurta internetinės naudotojo sąsajos principu.
- 5Specialistas – IS testuotojas: Per pastaruosius 5 metus turi ne mažiau kaip 3 metų informacinių sistemų testavimo patirtį.
- 6Specialistas – Duomenų bazių (DB) programuotojas (Mid): per paskutinius 5 metus turi ne mažiau kaip 2 metų duomenų bazių programuotojo, dirbant su perkančiosios organizacijos naudojama reliacine duomenų bazių valdymo sistemą (Oracle) (arba lygiaverte) patirtį, kuriant informacines sistemas.
- 7Specialistas – FrontEnd programuotojas (Mid): per paskutinius 5 metus turi ne mažiau kaip 3 metų FrontEnd programuotojo, dirbant su PHP technologijomis (arba lygiavertėmis), patirtį, kuriant informacines sistemas.
- 8Specialistas – FrontEnd programuotojas (Mid): per paskutinius 5 metus turi ne mažiau kaip 3 metų FrontEnd programuotojo, dirbant su .NET (angl. framework) (C#) technologijomis (arba lygiavertėmis), patirtį, kuriant informacines sistemas.
Techniniai reikalavimai
Saugumo reikalavimai
- 1Tiekėjas, kurdamas PĮ ir teikdamas PĮ priežiūros paslaugas, turi vadovautis visuotinai pripažintais saugaus kodavimo standartais ir gerąja praktika (pvz., The Open Web Application Security Project (OWASP) Secure Coding Practices).
- 2Kuriama PĮ neturi turėti nesankcionuotos prieigos prie duomenų ir kitų saugumo pažeidimų, įvardijamų naujausiame OWASP Testing Guide (neapsiribojant „OWASP Top 10“ pažeidžiamumais) ir The OWASP API Security sąraše.
- 3Saugumo patikrinimai (grėsmių modeliavimai, išeities kodo patikros) turi būti vykdomi kiekviename PĮ kūrimo (vystymo, priežiūros) etape, remiantis OWASP Web Security Testing Guide, Penetration Testing Execution Standard (PTES) ir kitomis metodikomis.
- 4Prieiga prie Sistemos tinklinių paslaugų bei naudotojo sąsajų bus galima tik HTTPS protokolu.
- 5Išorinės sistemos, teikiančios duomenis, identifikuojamos remiantis WS-Security bei WS-SecurityPolicy standartų apibrėžtais reikalavimais.
- 6Vartotojai prie sistemos galės jungtis per RC identifikavimo modulį iPasas arba VIISP (elektroniniai valdžios vartai).
- 7Sistemoje draudžiama bet kokia neautorizuota ar nedokumentuota nuotolinė ar lokali prieiga/paskyros ar bet koks slaptas funkcionalumas, galintis pažeisti sistemos saugumą.
- 8Teikėjas privalo pateikti detalias sistemos ir platformos (OS, DBMS, Middleware) saugumo konfigūravimo instrukcijas.
- 9Visi nebūtini Sistemos funkcionalumui komponentai turi būti deaktyvuoti prieš pradedant sistemos eksploataciją.
- 10Duomenų srautai tarp skirtingų lygių turi būti dokumentuoti, nurodant reikalingus komunikacijai prievadus ir protokolus, bei ribojami ugniasienių.
- 11Sistemos išorinis portalas turi būti atskirame nuo Sistemos vidinių posistemių tinklo segmente.
- 12Teikėjas privalo užtikrinti, kad paslaugų kūrimo etape nebūtų naudojami realus asmens duomenys.
- 13Registrai turi būti prieinami naudotojams: II kategorija – ne daugiau kaip 12 val. vienkartinio neveikimo, ne mažiau kaip 96 proc. laiko visą parą.
Testavimo reikalavimai
- 1Turi būti atliktas Sistemos vystymo ir priežiūros paslaugų priėmimo testavimas.
- 2Turi būti užtikrintas išeities kodo padengimas automatiniais testais (ne mažiau kaip 70 proc.).
- 3Teikėjas turi atlikti šiuos vidinius testavimus: Unit, Integration, System, Regression, Functional, Non-Functional, Usability, Compatibility, Configuration.
- 4Apkrovos ir našumo testavimą Teikėjas turi atlikti DEV aplinkoje.
- 5Integracinis testavimas (Integrity Testing) turi būti atliktas TEST aplinkoje su Pirkėjo darbuotojais.
- 6Saugos testavimas turi užtikrinti atitikimą kibernetinio saugumo reikalavimams ir remtis OWASP Testing Guide, Penetration Testing Execution Standard (PTES) ir kitomis metodikomis.
- 7Priėmimo testavimas (Acceptance Testing) turi būti atliekamas TEST aplinkoje dalyvaujant Teikėjui, Pirkėjui ir kitoms suinteresuotoms šalims.
- 8Teikėjas turi parengti pačios Sistemos ir ją sudarančių komponentų automatizuoto testavimo ir diegimo (CI/CD) procesus Pirkėjo naudojamoje priemonėje GitLab.
Paslaugų apimtis ir terminai
- 1Numatoma įsigyti 4000 valandų vystymo paslaugų, užsakomų pagal konkretų Pirkėjo poreikį Sistemos vystymui.
- 2Perkančioji organizacija įsipareigoja nupirkti ne mažiau kaip 1200 valandų vystymo paslaugų.
- 3Priežiūros paslaugos teikiamos 24 mėnesius.
- 4Planuojama pirkti 100 darbo valandų per mėnesį apimties Sistemos priežiūros paslaugų.
- 5Garantinės priežiūros terminas yra 12 mėnesių nuo kiekvieno Vystymo ir (ar) Priežiūros paslaugų perdavimo – priėmimo akto pasirašymo dienos.
- 6Paslaugų trūkumų pašalinimo terminas yra 10 darbo dienų nuo informavimo apie pastebėtus trūkumus.
- 7Priežiūros paslaugos turi būti teikiamos darbo dienomis nuo 8:00 val. iki 17:00 val., o jeigu Sistemos veikimo sutrikimas įtakoja Pirkėjo gebėjimą teikti paslaugas – ir kitu laiku.
- 8Vystymo paslaugų teikimo terminas pradedamas skaičiuoti nuo Paslaugų užsakymo pateikimo dienos.
Standartų taikymo reikalavimai
- 1Sistemos vystymui turi būti taikomi ODBC ar JDBC pagrindu veikiančios arba lygiavertės taikomosios programinės įrangos programavimo sąsajos (API) prisijungimui prie duomenų bazių.
- 2Duomenų mainams turi būti naudojami SOAP saityno paslaugų protokolas (SOAP v1.1) ir WSDL kalba.
- 3Naudotojo sąsajų ir el. paslaugų kūrimui turi būti vadovaujamasi tarptautiniais tinkamumo standartais LST EN ISO 9241-110:2006 ir LST EN ISO 9241-210:2011.
- 4Sistemoms komunikavimui turi būti naudojami SMTP, WS-I, SSL (ar lygiaverčiai) kriptografiniai protokolai, WS-Security, WS-* standartų grupės protokolai, HTTP, JSON, URI, XML, CSS, LDAP, AMQP.
- 5Sistemų ir programinės įrangos kokybės reikalavimams ir vertinimui taikomas ISO/IEC 25010:2011 standartas.
Našumo ir greitaveikos reikalavimai
- 1Paprastų žiniatinklio paslaugų (įvykdymo laikas neviršija 100 milisekundžių) atsako laikas neturi viršyti 2 sekundžių, vienu metu dirbant 100 lygiagrečių naudotojų, atliekančių po vieną užklausą per sekundę.
- 2Ataskaitų generavimas turi trukti ne daugiau kaip 10 sekundžių vieno paprastos ataskaitos puslapio generavimui ir ne daugiau kaip 15 sekundžių vieno suvestinės ataskaitos puslapio generavimui.
- 3Vidutinė atsako trukmė (nuo serverio HTTP užklausos gavimo iki HTTP atsakymo išsiuntimo) neturi viršyti 5 sekundžių, kai su Sistema vienu metu dirba 1000 naudotojų ir jų veiksmų (įterpimo, keitimo, šalinimo) atlikimo, esant 500 HTTP(S) užklausų kiekiui per minutę.
- 4Žiniatinklio paslaugos atveju vienos transakcijos (užklausos ir atsakymo, neįskaitant trečiųjų šalių įtakos) trukmė turi būti ne ilgesnė nei 5 sekundės.
Sistemos architektūros reikalavimai
- 1Sistema turi būti vystoma ir diegiama vadovaujantis mikroservisų architektūros principais.
- 2Sistema turi būti dekomponuojama į logiškus, racionalius, savarankiškai veikiančius programinius vienetus (mikroservisus), kurie su kitais Sistemos mikroservisais komunikuotų RESTful ar lygiaverčių technologijų principais.
- 3Mikroservisai turi realizuoti nuosavas duomenų struktūras (tiesiogiai naudojamas tik paties mikroserviso), išskyrus analizės PĮ.
- 4Turi būti naudojama PĮ, užtikrinanti automatinį mikroservisų paleidimą veikti (auto scaling), kai pasiekiamos nustatytos ribinės mikroserviso apkrovos.
- 5Turi būti naudojamas mikroservisų paieškos servisas (Service registry, service discovery).
- 6Komunikavimui tarp mikroservisų turi būti naudojama žinučių eilių valdymo (Message queuing) ar lygiavertė programinė įranga.
- 7Mikroservisų įdiegimas, veikimas ir išjungimas turi būti nepriklausomas nuo kitų mikroservisų veikimo ar neveikimo.
- 8Naujų Sistemos versijų diegimas neturi sustabdyti Sistemos teikiamų paslaugų (funkcijų) naudotojams arba toks paslaugų sustabdymas turi būti ypač trumpas (kelios sekundės).
- 9Turi būti realizuotas Sistemos komponentų automatizuotas testavimas ir diegimas (Continuous Integration and Delivery (CI/CD)).
- 10Turi būti realizuotas automatinis testų vykdymas ir testavimo duomenų generavimas.
- 11Turi būti pateiktos priemonės ir realizuoti sprendimai, užtikrinantys kuriamų, testuojamų ir diegiamų Sistemos versijų suderinamumą (Contract testing).
- 12Turi būti vengiama realizuoti monolitines aplikacijas – programinę įrangą, kuri skirtingus dalykinius uždavinius ir savarankiškus panaudos atvejus realizuoja vienoje (ar vos keliuose) aplikacijoje.
- 13Vykdant Sistemos vystymo darbus, pasirinktas architektūrinis sprendimas turi užtikrinti sistemos aukštą prieinamumą (High availability) paslaugų, integracijų ir duomenų lygiu.
Vystymo ir priežiūros paslaugų vykdymas
- 1Tiekėjas turės pateikti ir suderinti su Pirkėju Vystymo užsakymo realizacijos siūlymą, kuriame turi būti numatomas techninis sprendimas, darbų vykdymo planas, darbo valandų kiekis ir kaina.
- 2Darbų apimčiai ir planuojamoms vystymo valandoms nustatyti gali būti taikoma taškinė (SFT) metodika.
- 3Sistemos programinė įranga turės būti praplečiama ir keičiama remiantis daugiasluoksnės architektūros principu bei laikantis SOA (Service-Oriented Architecture) principų.
- 4Teikėjas turi užtikrinti ne mažiau kaip 3 vystymo paslaugų užsakymų (dar nesančių bandomosios eksploatacijos etape), vykdymą vienu metu.
- 5Teikėjas turės vykdyti 1 mėnesio bandomąją eksploataciją, jei vystymo užsakyme nesutarta kitaip.
- 6Teikėjas privalės mokymus atlikti Vinco Kudirkos g. 18-3, Vilniuje arba Pirkėjo nurodytoje vietoje ir (ar) būdais (pvz., nuotoliniu).
- 7Pirkimo paslaugos turi būti įgyvendinamos iteraciniu informacinės sistemos kūrimo būdu, taikant gerąsias „Agile“ programinės įrangos kūrimo metodų Scrum ir Kanban praktikas.
- 8Sistemos vystymo poreikiai turi būti registruojami Pirkėjo Jira sistemoje, pasirenkant Issue type Epic.
- 9Visi Teikėjo specialistai, atsakingi už sutarties vykdymą, turės pasirašyti konfidencialumo pasižadėjimą ir susipažinti su pateiktais Pirkėjo saugos dokumentais.
- 10Teikėjo siūlomas specialistas (-ai) turi gebėti bendrauti žodžiu ir raštu lietuvių kalba (ne blogesniu nei C1 lygiu pagal Bendruosius Europos kalbų matmenis).
Dokumentacijos ir atskaitomybės reikalavimai
- 1Teikėjas turės parengti ir/arba atnaujinti dokumentaciją (naudotojų instrukcijas, elektroninės pagalbos priemones, sistemų techninę dokumentaciją ir kt.).
- 2Visa dokumentacija turi būti parengta lietuvių kalba, išskyrus techninius dokumentus, kuriuose dalis informacijos gali būti pateikiama anglų kalba.
- 3Visi Teikėjo parengti dokumentai turės būti suderinti su Pirkėju. Derinimas vyks ne daugiau kaip 2 iteracijomis.
- 4Pirkėjas įsipareigoja pateikti pastabas derinimui pateiktiems dokumentams: iki 100 puslapių – pirma versija per 6 d.d., pataisyta versija per 4 d.d.; virš 100 puslapių – pirma versija per 8 d.d., pataisyta versija per 6 d.d.
- 5Teikėjo pataisyti dokumentai turi būti teikiami su matomais pakeitimais („track changes“ funkcija).
- 6Dokumentų galutinės versijos turi būti pateiktos dviem formatais: redagavimui tinkamu elektroniniu (.doc, .docx, .pdf ar kt.) ir Teikėjo atsakingo asmens parašu pasirašytu formatu.
- 7Per 20 darbo dienų nuo Sutarties įsigaliojimo Teikėjas turi surengti įvadinį susitikimą su Registrų centru bei pateikti derinimui ir pristatyti Paslaugų teikimo reglamentą.
Technologiniai ir programinės įrangos reikalavimai
- 1Teikėjas, suderinęs su Perkančiąja organizacija, turi naudoti naujai kuriamai PĮ jos kūrimo dieną esamas naujausias programinių paketų (pvz. Microsoft Office 2019 WordML technologijos naudojimui), bibliotekų (pvz. jQuery v3.7.1, jQuery.min, Bootstrap ir kt.), programavimo kalbų, jų kompiliatorių bei interpretatorių versijas (pvz., JDK21, .NET 4.8, .NET Core, PHP 8.0).
- 2Paslaugų kūrimo aplinka turi būti kuriama iš sudarytų skriptų (Infrastructura as Code (IaC)) naudojant konteinerizavimo technologijas kaip Docker.
- 3Teikėjas privalo pats pasirūpinti savo kūrimo aplinka, t.y., savo infrastruktūroje arba lokalioje darbo vietoje įsidiegti reikiamus serverius (siūloma naudoti Oracle Database XE, siekiant išvengti programinės įrangos licencijavimo).
- 4TRIS (Testamentų registras) pagrindiniai komponentai naudoja Microsoft .NET Framework v4.8, jQuery 3.5.1, jQueryUI 1.10.3, Angular JS 1.3.8, ASP.NET MVC 5 (v5.2.2), Oracle PL/SQL technologijas ir Oracle 12c duomenų bazę.
- 5VSR (Vedybų sutarčių registras) pagrindiniai komponentai naudoja PHP 5.3.10, jQuery 3.4.1, jQueryUI 1.12.1, Microsoft Visual C++, Microsoft .NET Framework v4.0, Microsoft .NET Framework v4.8 technologijas ir Oracle 12c duomenų bazę.
- 6NIRVAR (Neveiksnių ir ribotai veiksnių asmenų registras) pagrindiniai komponentai naudoja Microsoft .NET Framework v4.8, jQuery 3.5.1 technologijas ir Oracle 12c duomenų bazę.
- 7Aplikacijų serverio PĮ Windows Server 2012 R2 Programinė įranga apima .NET Framework v4.8, .NET Core 2.2.6, Oracle Client 11g R2, Oracle Client 12c, Oracle Data Access Components (ODAC) 12c Release 3, Microsoft Office Word 2007, IIS 8.5, Microsoft ReportViewer 2010 Redistributable, 7-zip.
- 8Sistemos, registro ar produkto vystymo paslaugų teikimo metu sukurto išeities kodo kokybės ir saugumo tikrinimui bus naudojamas SonarQube.
Dokumentai6
tendis.lt · Sukurta recodin.lt