Grįžti į sąrašą

Pastatų duomenų banko posistemio Statinių poveikio aplinkai rodiklių modeliavimo ir rizikos veiksnių nustatymo sukūrimo ir Pastatų duomenų banko informacinės sistemos tobulinimo paslaugos

Išanalizuota

Lietuvos Respublikos aplinkos ministerijos Aplinkos projektų valdymo agentūra

Atviras konkursasCPV: 72212517 - IT programinės įrangos kūrimo paslaugos
ID: 71516572026-06-05 05:12Pasiūlymai iki: 2026-07-09 13:00
Atidaryti CVP IS

Aprašymas

Perkami Pastatų duomenų banko (PDB) posistemio, skirto statinių poveikio aplinkai rodiklių modeliavimui ir rizikos veiksnių nustatymui, sukūrimo ir PDB informacinės sistemos tobulinimo paslaugos. Šio pirkimo tikslas yra sukurti ir įdiegti Statinių gyvavimo ciklo informacinę sistemą (SGC IS), kuri centralizuotai rinks duomenis ir modeliuos rodiklius, leidžiančius efektyviai įvertinti statinio poveikio aplinkai ir klimato kaitai per visą jo gyvavimo ciklą.

Kvalifikaciniai reikalavimai

  • 1Tiekėjas, per paskutinius 3 (tris) metus iki pasiūlymo pateikimo termino pabaigos arba per laiką nuo tiekėjo įregistravimo dienos (jeigu tiekėjas įregistruotas vėliau) pagal vieną ar daugiau sutarčių yra suteikęs informacinių sistemų ar registrų kūrimo, diegimo ar modernizavimo paslaugų, kurių bendra vertė ne mažesnė kaip 200 000,00 Eur be PVM vertę.
  • 2Minėtas reikalavimas gali būti patenkinamas pagal vieną ar daugiau sutarčių, kurios tenkina šiame reikalavime išvardintas sąlygas.
  • 3Jei tiekėjas teikia informaciją apie vykdomą sutartį, tuomet įvykdyta paslaugų dalis turi būti sukurtos, įdiegtos ar modernizuotos informacinės sistemos ar registro, visos bent vieno prieaugio diegimo veiklos: detali analizė, IS projektavimas, programavimas, testavimas, diegimas, bandomoji eksploatacija.
  • 4Jei tiekėjas teikia informaciją apie įvykdytą sutartį, sutartis gali būti pradėta vykdyti anksčiau, nei prieš 3 (trejus) metus, tačiau sutarties vykdymo pabaiga turi patekti į 3 (trejų) metų laikotarpį, skaičiuojant nuo paskutinės pasiūlymų pateikimo termino dienos.
  • 5Ekspertas Nr. 1 – Projekto vadovas: turi ne mažesnę kaip 3 (trejų) metų* patirtį vadovaujant informacinių sistemų ar registrų kūrimo, diegimo ar modernizavimo projektams/sutarčių.
  • 6Ekspertas Nr. 1 – Projekto vadovas: turi būti vadovavęs bent 1 (vienam) įgyvendintam informacinės sistemos ar registro kūrimo, diegimo ar modernizavimo projektui/sutarčiai, kurio/-ios vertė yra ne mažesnė kaip 200 000 Eur be PVM.
  • 7Ekspertas Nr. 1 – Projekto vadovas: turi projekto valdymo kvalifikaciją, patvirtintą tarptautiniu projekto valdymo sertifikatu (pvz., PMP, PRINCE2, CompTIA Project+) arba lygiaverčiu išvardintiems tarptautiniu projekto valdymo sertifikatu.
  • 8Ekspertas Nr. 2 – informacinių sistemų analitikas: turi ne mažesnę nei 3 (trejų) metų* patirtį vykdant informacinių sistemų ar registrų analizės veiklas.
  • 9Ekspertas Nr. 2 – informacinių sistemų analitikas: per paskutinius 3 (trejus) metus (iki pasiūlymų pateikimo termino pabaigos) informacinių sistemų analitiko pareigose yra dalyvavęs vykdant bent 1 (vieną) įgyvendintą informacinių technologijų (IT) paslaugų teikimo sutartį/projektą, kurios vykdymo metu atliko veiklos procesų, reikalavimų programinei įrangai analizę ir modeliavimą bei šios veiklos rezultato pagrindu buvo sukurta, įdiegta ar modernizuota informacinė sistema ar registras.
  • 10Ekspertas Nr. 3 – Naudotojo sąsajos analitikas: turi ne mažesnę nei 3 (trejų) metų* darbo patirtį vykdant naudotojo patirties (UX) ir/ar naudotojo sąsajos (UI) analizės ir projektavimo veiklas;
  • 11Ekspertas Nr. 3 – Naudotojo sąsajos analitikas: per paskutinius 3 (trejus) metus (iki pasiūlymų pateikimo termino pabaigos) dalyvavo bent 1 (viename) įgyvendintame informacinės sistemos ar registro kūrimo, diegimo, ar modernizavimo projekte/sutartyje einant naudotojo sąsajos analitiko pareigas ir kurio metu buvo rengiamas naudotojo sąsajos projektas naudojant profesionalius UI/UX projektavimo įrankius (pvz. Figma, Axure ar lygiaverčius);
  • 12Ekspertas Nr. 3 – Naudotojo sąsajos analitikas: turi dokumentais pagrįstą profesinę patirtį UI/UX srityje.
  • 13Ekspertas Nr. 4 – Informacinių sistemų architektas: turi ne mažesnę nei 3 (trejų) metų* programavimo patirtį;
  • 14Ekspertas Nr. 4 – Informacinių sistemų architektas: turi ne mažesnę kaip 3 (trejų) metų* patirtį informacinių sistemų ar registrų architektūros projektavimo ir sprendinių formavimo srityje;
  • 15Ekspertas Nr. 4 – Informacinių sistemų architektas: turi patirties projektuojant ar vystant informacines sistemas ar registrus, sukurtus naudojant React ir Node.js (pvz., NestJS) arba lygiaverčių pagrindu veikiančias technologijas bei ORM arba lygiverčiu principu veikiančius duomenų prieigos sprendimus;
  • 16Ekspertas Nr. 4 – Informacinių sistemų architektas: per paskutinius 3 (trejus) metus (iki pasiūlymų pateikimo termino pabaigos) yra dirbęs architekto pareigose bent 1 (viename) įgyvendintame projekte/sutartyje, kurio vykdymo metu buvo kuriama, diegiama ar modernizuojama informacinė sistema ar registras, tenkinanti visus žemiau išvardintus reikalavimus: sistema yra integruota su bent viena informacine sistema ar registru; sistema buvo projektuojama ir veikia reliacinės duomenų bazės pagrindu; sistema sukurta internetinės naudotojo sąsajos principu ir prie sistemos vienu metu gali prisijungti ir dirbti ne mažiau kaip 100 naudotojų.
  • 17Ekspertas Nr. 5 – Vyriausiasis programuotojas: turi ne mažesnę nei 3 (trejų) metų* programavimo patirtį;
  • 18Ekspertas Nr. 5 – Vyriausiasis programuotojas: per paskutinius 3 (trejus) metus (iki pasiūlymų pateikimo termino pabaigos) yra dirbęs bent 1 (viename) įgyvendintame informacinių sistemų ar registrų kūrimo, diegimo ar modenizavimo projekte/sutartyje, kurioje buvo: kuriami serverinės dalies sprendimai naudojant Node.js arba lygiavertes technologijas (pvz., NestJS ar analogiškus programavimo karkasus); naudojamos React, TypeScript, NestJS ir TypeORM arba lygiavertes technologijos; realizuojamos integracijos (duomenų mainų sąsajos) su kitomis informacinėmis sistemomis ar registrais, įskaitant integracijas per žiniatinklio paslaugas (REST ar analogiškus API principus).
  • 19Ekspertas Nr. 6 – Programuotojas („frontend“): turi ne mažesnę nei 3 (trejų) metų* praktinę patirtį kuriant naudotojo sąsajas naudojant React ir TypeScript arba lygiavertes technologijas;
  • 20Ekspertas Nr. 6 – Programuotojas („frontend“): per paskutinius 3 (trejus) metus (iki pasiūlymų pateikimo termino pabaigos) dalyvavo bent 1 (viename) įgyvendintame informacinės sistemos ar registro kūrimo, diegimo ar modernizavimo projekte/sutartyje, kuriame vykdė naudotojo sąsajos programavimo darbus naudojant React ir TypeScript arba lygiavertes technologijas.
  • 21Ekspertas Nr. 7 – Programuotojas („backend“): turi ne mažiau nei 3 (trejų) metų* programavimo patirtį naudojant NestJS, Typescript, TypeORM arba lygiavertes technologijas;
  • 22Ekspertas Nr. 7 – Programuotojas („backend“): per paskutinius 3 (trejus) metus (iki pasiūlymų pateikimo termino pabaigos) dalyvavo bent 1 (viename) įgyvendintame informacinės sistemos ar registro kūrimo, diegimo ar modernizavimo projekte/sutartyje, kuriame vykdė REST API sąsajos programavimo darbus naudojant NestJS, Typescript ir TypeORM arba lygiavertes technologijas.
  • 23Ekspertas Nr. 8 – IS testavimo specialistas: per paskutinius 3 (trejus) metus (iki pasiūlymų pateikimo termino pabaigos) dalyvavo bent 1 (viename) įgyvendintame informacinės sistemos ar registro kūrimo, diegimo ar modernizavimo projekte/sutartyje, kuriame rengė testavimo planą, testavimo scenarijus, vykdė testavimą ir rengė testavimo ataskaitas;
  • 24Ekspertas Nr. 8 – IS testavimo specialistas: turi galiojantį ISTQB Certified Tester sertifikatą arba lygiavertį arba turi ne mažiau nei 3 (trejų) metų informacinių sistemų arba registrų testavimo patirtį.

Techniniai reikalavimai

Duomenų modulis

  • 1Įrankis turi palaikyti projekto (statinio) duomenų: importą iš CSV ir JSON; eksportą į CSV ir JSON;
  • 2Importo metu turi būti atliekama CSV ir JSON struktūros patikra. Neteisingos struktūros rinkmenos neturi būti galima importuoti.
  • 3Diegėjas turės parengti CSV ir JSON struktūrų specifikaciją. JSON atveju papildomai turi būti aprašoma JSON Schema.
  • 4Sistema turi aiškiai informuoti naudotoją apie struktūros klaidas.
  • 5Turi būti galima atlikti bandomąjį CSV ir JSON importą, kurio metu imituojamas duomenų importas ir visi įrašai, kurių nepavyko importuoti turi būti išskirti ir pateikta naudotojo peržiūrai su klaidų sąrašu.
  • 6Su importuojamu įrašu susijusios klaidos turi būti aiškiai susietos su konkrečiu įrašu, kad iš klaidos teksto naudotojui būtų aišku kuris įrašas kokios patikros sąlygų netenkina.
  • 7Importuojamo ir eksportuojamo failų struktūrose turi būti sąsajumo informacija – iš kokio BIM elemento, komponento ID (pvz. IFC GUID) yra suformuotas įrašas.
  • 8Importuojamuose duomenyse turi būti: kodavimo pagal NSIK informacija; importo laikas; ar importuoti kiekiai buvo pakeisti rankiniu būdu.
  • 9Turi būti išsaugomi pirminiai importuoti duomenys ir rankiniu būdu pakeisti.

Projektų modulis

  • 1Turi būti organizacijos duomenų ir naudotojų prieigos prie atskirų projektų tvarkymo funkcija.
  • 2Turi būti galima įvesti pagrindinę projekto (statinio) informaciją (neapsiribojant): Statinio metaduomenys (pavadinimas, tipologija, projekto fazė, lokalizacija, projektavimo dalyviai, projekto užbaigtumo metai); Statinio plotas.
  • 3Turi būti schematiškai parodoma visų organizacijos projektų parametrų apžvalga su svarbiausia informacija (VAP rezultatu, plotu, skaičiavimų užbaigtumu, redagavimo data).
  • 4Turi būti galimybė valdyti atskirus projekto nustatymus.
  • 5Turi būti projekto kopijavimo funkcija („klonavimas“).
  • 6Projekto modulyje turi būti galimybė nurodyti projekto eksploatacijos metu sunaudojamą energijos kiekį ir jos tipą. Skaičiavimo metodika bei emisijų faktoriai B6 etapui turi būti paremti Metodika.
  • 7Projektus turi būti galima sukurti gaunant duomenis iš IS Infostatyba arba rankiniu būdu. Kūrimo būdai turi būti įjungiami per sistemos parametrus.
  • 8Turi būti galima susikurti bandomuosius projektus, kuriuos vėliau būtų galima susieti su realiais projektais. Susiejimo metu neturi būti reikalaujama naudotojui perimportuoti duomenis iš XLS/CSV/JSON ir pan.

Ataskaitų modulis

  • 1Ataskaitos turi būti formuojamos PDF, Excel, CSV formatais.
  • 2Duomenų rūšis, ar naudojami PADR ar APD duomenys, bei kokie jų šaltiniai.
  • 3Standartizuotos ataskaitos turi būti parengiamos pagal Metodiką, tačiau turi būti sudaryta galimybė generuoti ir pritaikytas ataskaitas pagal vartotojo ar organizacijos nustatytas nuostatas, įskaitant pasirinktą projekto metaduomenų informaciją.
  • 4Turi būti realizuota iki 10 ataskaitų.

PDB IS tobulinimas

  • 1PDB IS tobulinimas turės būti atliekamas pagal skyriuje „10.9 Reikalavimai papildomoms paslaugoms / nenumatytiems reikalavimams bei PDB IS tobulinimui“ aprašytą tvarką.
  • 2Visi Techninės specifikacijos reikalavimai turi būti įgyvendinti pilna apimti ir nereikalauti atlikti sukurto funkcionalumo tobulinimo sistemos įdiegimo dienai. Tobulinimo darbai gali būti užsakyti išimtinai tik tais atvejais, kuomet iškyla poreikis, kuris nėra apibrėžtas Techninėje specifikacijoje ir būtinas pirkimo uždaviniams bei tikslams pasiekti.

Integracijų modulis

  • 1IS Infostatyba „iš“. Į SGC IS gaunami duomenys apie statybas leidžiančius dokumentus bei statinius.
  • 2IS Infostatyba „į“. Iš SGC IS (pagal poreikį) teikiama SGC ataskaita ir/ar jos duomenys.
  • 3PENS „iš“. Į SGC IS gaunami duomenys, reikalingi SGC skaičiavimams atlikti.
  • 4PENS „į“. Iš SGC IS teikiami duomenys apie paskaičiuotus SGC įverčius.
  • 5GPAIS „iš“. Į SGC IS gaunami duomenys apie atliekas, reikalingas SGC skaičiavimams atlikti.
  • 6Integracijų API. SGC IS turi užtikrinti galimybę išoriniams integratoriams per API atlikti pagrindines funkcijas, analogiškas kaip ir naudojantiems SGC IS portalą (sukurti projektą, įkelti statinio duomenis, atlikti skaičiavimus ir kt.).
  • 7TPS vartai. SGC IS (ir PDB IS) turi nedubliuoti TPS vartų funkcionalumo kas liečia vieningą prisijungimą (angl. „single sign on“, SSO), naudotojų ir jų profilių valdymą, pranešimų naudotojams siuntimą ir kitą funkcionalumą, aprašytą TPS vartų techninėje dokumentacijoje. Atitinkamai Projekto rezultatams pasiekti reikalingas TPS vartuose esantis funkcionalumas turi būti integruojamas per TPS vartų API integracijų sąsają.

Mokymų reikalavimai

  • 1Diegėjas turės apmokyti pažangius naudotojus, kurie galėtų apmokyti kitus naudotojus: ne mažiau 2 SGC IS administravimą atliekančių darbuotojų (mokymų trukmė ne trumpesnė nei 4 akademinės val.). Mokymų forma – nuotoliu. Privaloma atlikti šių mokymų vaizdo įrašą.
  • 2Organizuoti darbo su SGC IS portalu pristatymą (renginio trukmė ne trumpesnė nei 6 akademinės val.). Mokymų forma – nuotoliu. Privaloma atlikti šių mokymų vaizdo įrašą.
  • 3Vaizdo įrašai turi būti pateikti kartu su laiko žymomis, kurios padėtų greičiau rasti su atitinkama tema susijusią vietą.

Saugumo reikalavimai

  • 1Turi būti sukurtos skirtingos prieigos grupės organizacijų naudotojams: administratorius, duomenų tvarkytojas, skaitytojas, su galimybe valdyti vartotojus per grupes, suteikiant jiems prieigą prie modulių.
  • 2Roles turi būti galima konfigūruoti naujas iš esamų sistemos teisių.
  • 3Naudotojų autentifikavimas turi būti realizuotas naudojant TPS vartų naudotojų autentifikavimo vieningo prisijungimo (angl. „single sign-on“) modulį.
  • 4Duomenų sauga turi būti užtikrinama: Užtikrinant duomenų vientisumą ir neprieštaringumą; Registruojant naudotojų atliekamus veiksmus su duomenimis; Numatant apsaugos nuo atsitiktinio duomenų ištrynimo (pvz., perspėjimai apie numatomą duomenų ištrynimą) priemones.
  • 5Bandomosios eksploatacijos etapo metu (ar kitu sutartu metu) Diegėjas turi sudaryti visas reikiamas sąlygas atsparumo įsilaužimų testavimo ir jei bus būtina – pakartotinio testavimo – atlikimui. Esant poreikiui Diegėjas turės atlikti konfigūravimo ar programavimo darbus, kurie bus būtini siekiant ištestuoti SGC IS saugumą įvairiais jos naudojimo scenarijais.
  • 6Atsižvelgiant į atsparumo įsilaužimams testavimo rezultatus Diegėjas turi atlikti reikiamus SGC IS programavimo ir / ar konfigūravimo (įskaitant architektūrinių komponentų atnaujinimo) darbus, kad būtų pašalinti visi nustatyti svarbūs saugumo pažeidžiamumai.
  • 7Diegėjas turi suderinti failų formatus, kuriuos leidžiama įkelti į SGC IS, ir suderinti juos su Užsakovu (pvz., neturi būti leidžiama įkelti potencialiai nesaugių, galinčių automatiškai pasileisti (angl. self-executive) failų).
  • 8Naudotojui pateikiama informacija turi būti ribojama pagal jam suteiktas roles bei prieigos teises prie konkretaus objekto informacijos.
  • 9Jautri informacija (pvz. asmens kodas) turi būti rodomi tik įvedimo ar redagavimo metu, o peržiūros režime rodoma užmaskuota (ar dalinai užmaskuota).

Skaičiavimų modulis

  • 1Įrankis turi leisti modeliuoti projektavimo scenarijus ir variantus (pvz., medžiagų alternatyvos, konstrukciniai sprendimai, viso scenarijaus modeliavimas).
  • 2Naudotojas bet kuriame lygmenyje (grupė > komponentas > medžiaga) turi matyti: naudojamus duomenis ir jų šaltinius; emisijų rodiklius (VAP) nurodomus bendrai ir per etapus; deklaruotą vienetą (kg, m², m³ ir pan.).
  • 3Naudotojas turi turėti galimybę rankiniu būdu pasirinkti įvesti naują APD arba duomenų rinkinius skaičiavimams atlikti.
  • 4Automatinio APD importo metu turi būti patikrinama ar jau nėra tokia APD importuota ir informuoti naudotoją.
  • 5Skaičiavimo modulis turi integruoti statybinių komponentų ir medžiagų biblioteką.
  • 6Informacijos paieška duomenų įvedimui turi būti lanksti, galimybė ieškoti pilno teksto pagrindu (angl. „full text search“) ir pagal fiksuotus parametrus.
  • 7Modulis turi būti organizuotas hierarchiniu principu: Komponentų grupė > Komponentas > Medžiaga > Medžiagos gyvavimo ciklo etapai.
  • 8Turi būti integruota medžiagų ir APD, Bendrinių duomenų medžiagų duomenų paieška ir priskyrimas. Skaičiavimo modulio lentelės/duomenų sluoksnis turi turėti: medžiagų paiešką; integruotą APD ir (arba) bendrinės duomenų bazės naršymą; pasirinktai (-iems) konstrukcijai (-oms) ar komponentui (-ams) galimybę surasti ir priskirti atitinkamą PADR arba APD įrašą. Visa reikalinga skaičiavimams atlikti CO₂e informacija turi būti automatiškai įkelta į skaičiavimo lentelę su duomenų šaltinio žyma (PADR ar APD).
  • 9Konstrukcijoms ir medžiagoms turi būti suteikta galimybė pasirinkti matavimo vienetą pagal jų tipą (m, m², m³, kg).
  • 10Sistemoje turi būti taikomas automatinis konversijų palaikymas, jei APD, PADR deklaruota kita forma (pvz., kg>m³ pagal tankį).
  • 11Turi būti sąsajos su nacionaliniais rodikliais (faktoriais). Turi būti galima šiuos rodiklius (faktorius) įvesti sistemoje kartotiniam naudojimui.
  • 12Turi būti galimybė peržiūrėti visus CO2 skaičiavimuose naudojamus konversijų rodiklius.
  • 13Turi būti įtraukta funkcija pažymėti, jei medžiaga arba konstrukcija yra pakartotinai panaudota.
  • 14Skaičiavimo modulyje turi būti galima naudoti statybinių komponentų ir medžiagų biblioteką. Biblioteka turi būti filtruojama pagal duomenų šaltinį (PADR arba APD), medžiagų ar konstrukcijų kategorijas, taip pat pagal vartotojo pasirinktus dažniausiai naudojamus elementus.
  • 15Turi būti įdiegtas lengvas ir intuityvus medžiagų sujungimas bei jų susiejimas su projekto konstrukcijomis ir medžiagomis, pavyzdžiui, naudojant „drag and drop“ funkciją. Susiejimui turi būti automatiškai pasiūlomos artimiausios medžiagos (sufleris).
  • 16Turi būti įdiegta galimybė skaičiavimo modulyje palyginti skirtingas medžiagų ir konstrukcijų VAP.
  • 17Turi būti įdiegta automatinio medžiagų susiejimo su projekto konstrukcijomis funkcija, paremta naudotojo nustatyta logika, pavyzdžiui, labiausiai naudotomis medžiagomis ankstesniuose projektuose (tai paspartintų pradinius LCA skaičiavimus ankstyvoje projektavimo fazėje).
  • 18Turi būti taikomi struktūruoti medžiagų gyvavimo trukmės duomenys su automatine parinkimo funkcija B4 etapui apskaičiuoti. Duomenys turi būti susieti su kiekviena projekte naudojama medžiaga.
  • 19Skaičiavimo modulyje turi būti integruoti du atskiri skaičiavimo būdai A4 medžiagų transportui į statybvietę: skaičiavimas pagal Metodiką arba standartinių verčių taikymas ankstyvojoje projekto stadijoje. Taip pat turi būti integruotas A5 etapo skaičiavimas, apimantis statybvietėje naudojamos energijos apskaičiavimą.
  • 20Skaičiavimo modulyje turi būti pateiktas daugiausiai VAP įtakojančių medžiagų sąrašas su alternatyvų pasiūlymais.
  • 21Skaičiavimų modulyje gali būti integruoti dirbtinio intelekto, AI patarimai, siūlantys mažesnes emisijas turinčias medžiagas toje pačioje kategorijoje.
  • 22Siekiant įtraukti tarp kelių statinių bendrai išdalinamo objekto (pvz. bendros požeminės infrastruktūros) paskirstymą į skaičiavimą, turi būti galima nurodyti medžiagų (produktų) procentinę dalį, tenkančią konkrečiam skaičiuojamam objektui (statiniui).

Diegimas ir testavimas

  • 1Turi būti realizuotas komponentų automatizuotas testavimas ir diegimas (angl. „Continuous Integration and Delivery (CI/CD)“). Turi būti realizuotas automatinis testų vykdymas ir testavimo duomenų generavimas.
  • 2Automatiniai testai turi apimti sistemos kritinį funkcionalumą naudotojo ir išorinių integracijų sąsajų lygmeniu.
  • 3Automatizuotas diegimas turi apimti ir duomenų bazės struktūrų keitimą bei duomenų tvarkymą (angl. „migrations“).
  • 4Turi būti įdiegtos šios SGC IS aplinkos: testavimo – naudojama visą SGC IS eksploatavimo laikotarpį. Testavimo aplinkos architektūriniai sprendimai turi būti paremti gamybinės aplinkos sprendimais. Testavimo aplinkos diegiamų komponentų kiekis gali būti mažinamas (ir / ar grupuojamas) siekiant racionalaus resursų panaudojimo, tokiems sprendimams turi būti gautas Užsakovo pritarimas. Testavimo aplinkai nėra keliami aukšto prieinamumo reikalavimai. Testavimo aplinkai nėra keliami rezervinio duomenų kopijavimo reikalavimai; mokymų aplinka – naudojama visą SGC IS eksploatavimo laikotarpį. Mokymų aplinka turi būti diegiama apimtimi, kuri bus reikalinga mokymams atlikti. Mokymų aplinkai nėra keliami aukšto prieinamumo reikalavimai. Mokymų aplinkai nėra keliami rezervinio duomenų kopijavimo reikalavimai; gamybinė – naudojama visą SGC IS eksploatavimo laikotarpį;
  • 5SGC IS komponentai turi būti diegiami „Docker“ konteineriuose ir tiesiogiai virtualiose mašinose. Kiekvieno komponento diegimo principas turi būti suderintas su Užsakovu.
  • 6Konteineriai turi būti diegiami virtualių mašinų (VM) platformoje.
  • 7Diegėjas tiesiogiai diegimų ir konfigūracijos veiksmų Užsakovo aplinkose neatlieka. Visi reikalingi sudiegti komponentai, konfigūracijos nustatymai bus atliekami Užsakovo atstovų pagal Diegėjo pateiktas instrukcijas. Instrukcijos privalo būti aiškios, pateikiamos CLI komandų principu.
  • 8Pirminis aplinkų parengimas gali būti pusiau automatizuotas. SGC IS programinės įrangos diegimas ir atnaujinimai privalo būti pilnai automatizuoti. Kiekvieno automatizuoto diegimo metu privalo būti sugeneruojami diegimo žurnalai, iš kurių turi būti aišku kas diegiama, klaidų atveju – matomos klaidos, jų priežastys. Iš žurnalo įrašų turi būti galima nesudėtingai identifikuoti problemą ir ją pašalinti.
  • 9Turi būti atliktas SGC IS testavimas. Testavimo pagrindinis tikslas – užtikrinti, kad sukurtas funkcionalumas tenkina visus šios specifikacijos funkcinius ir nefunkcinius reikalavimus bei identifikuoti ir pataisyti kiek įmanoma daugiau klaidų.
  • 10Turi būti atlikti šie testavimai: Vidinis atskirų sistemos komponentų testavimas, kurį Diegėjas turi atlikti savarankiškai, nedalyvaujant Užsakovo atstovams, tačiau turi pateikti tokio testavimo įrodymus – vidinių testavimų metu nustatytų klaidų sąrašą (su būsenomis), testavimo scenarijus ir ataskaitą; Priėmimo testavimas, kurį Diegėjas turi atlikti dalyvaujant Užsakovo atstovams, vadovaujantis Diegėjo parengtu testavimo planu ir testavimo scenarijais. Testavimą turi vykdyti (testavimo scenarijaus veiksmus atlikinėti) Diegėjas. Diegėjas gali atlikti priėmimo testavimą ir pagal savo nuožiūra pasirengtus testavimo scenarijus; Naudojamumo testavimas, kurį Diegėjas turi atlikti su būsimų naudotojų atstovais. Šis testavimas turi būti atliktas individualiai su kiekvienu testavime dalyvaujančiu naudotoju ir testavimo sesija privalo būti įrašyta (jeigu testavime dalyvaujantis asmuo tam neprieštarauja). Turi būti atliktas sukurto sprendinio testavimas su ne mažiau nei 20 būsimų naudotojų, po 10 asmenų kiekviename testavime. Antrasis testavimas turi būti atliekamas tik įvertinus pirmojo testavimo rezultatus ir tik atlikus suderintus su Užsakovu pataisymus sistemoje.
  • 11Priėmimo testavimas turi būti vykdomas Užsakovo pateiktoje įrangoje.
  • 12Diegėjas turės užtikrinti, kad priėmimo ir naudojamumo testavimams sistemoje būtų suvesta arba migruota pakankamai duomenų, kurie leistų pilnai ištestuoti SGC IS funkcionalumą.
  • 13Testavimo aplinkos architektūros principai, kiek įmanoma, turi atitikti darbinę sistemos aplinkos architektūrą.
  • 14Testavimo metu elektronine forma turi būti vedamas pastebėtų klaidų ir jų būsenų kaupimo žurnalas (toliau – klaidų žurnalas). Klaidų žurnalą turi pildyti Diegėjo atstovai, galimybę jį peržiūrėti ar pildyti suteikiant Užsakovo atstovams.
  • 15Klaidų žurnalas turi būti specializuota problemų registravimo ir sekimo programinė įranga (angl. Issue tracking software), veikianti interneto naršyklės aplinkoje.
  • 16Diegėjas turės užtikrinti, kad priėmimo testavimo metu bus realizuotos visos šioje specifikacijoje apibrėžtos integracijos su vidinėmis ir išorinėmis sistemomis. Priėmimo testavimo metu SGC IS turės būti integruota su vidinių ir išorinių sistemų testavimo aplinkomis (jeigu tokios egzistuoja). Jeigu priėmimo testavimo metu nebus galimybės atlikti integracijų testavimo dėl integruotinos sistemos (ar registro) neveikimo (neegzistavimo), Diegėjas turės simuliuoti integruotinas sistemas arba atskiru sutarimu su Užsakovu suderinti alternatyvų integracijų funkcionalumo testavimo būdą.
  • 17Priėmimo testavimo veikla laikoma sėkminga, kai tenkinami priėmimo testavimo plane apibrėžti priėmimo kriterijai.

Sistemos funkcionalumas

  • 1SGC IS turi realizuoti šias funkcijas: SGC IS duomenų tvarkymas, peržiūra suinteresuotoms šalims; informacinių pranešimų gavimas ir komunikacija tarp SGC IS naudotojų; organizacijos paskyros valdymas ir organizacijos duomenų administravimas; ataskaitų formavimas; SGC IS duomenų archyvavimas ir peržiūra; SGC IS administravimas; Duomenų gavimas (per sukurtas integracijų sąsajas); Duomenų teikimas (per sukurtas integracijų sąsajas); Duomenų įkėlimas SGC IS skaičiavimams atlikti; SGC IS skaičiavimų atlikimas; SGC IS skaičiavimų analizė bei ataskaitų formavimas.
  • 2Šios Paslaugų teikimo sutarties apimtyje numatoma atlikti PDB IS tobulinimą.
  • 3Sukurtais SGC IS funkcionalumais naudosis šios suinteresuotos šalys: Sistemos tvarkytojo specialistai; Statytojas ir jo paskirti asmenys; Statinio savininkas ir jo paskirti asmenys.
  • 4Įrankis turi atlikti poveikio globaliniam atšilimui (CO2 emisijų) skaičiavimus pagal taikomą Metodiką.
  • 5Turi būti palaikomi visi statinio gyvavimo ciklo etapai: A1-A3, A4, A5, B1-B7, C1-C4, D.
  • 6Įrankyje turi būti naudojama PADR taip pat įrankis turi palaikyti APD pagal galiojantį EN 15804+A2 standartą (arba lygiavertį galiojantį) bei ESAD duomenų įvestį, reikalingą SGC poveikio aplinkai skaičiavimams (Reglamento (ES) 2024/3110 II priedas).
  • 7Naudotojas turi turėti galimybę pasirinkti analizės gylį ir tik jam reikalingus etapus, bet tuo pačiu ir Metodikos standartinius nustatymus.
  • 8Turi būti galimybė keisti ribines vertes. Turi būti saugoma visa ribinių verčių chronologija.
  • 9Klaidų, įkeliant duomenis, nustatymas (nepriskiertos / neatpažintos medžiagos, kiekiai). Nustatytos klaidos turi būti aiškiai pažymėtos taip, kad iš jų būtų galima identifikuoti klaidų pobūdį, jų atsiradimo priežastis bei gauti instrukciją dėl jų ištaisymo. Kur tai taikytina, sistema turi grąžinti ne po vieną klaidą, bet iš karto visą duomenų rinkinio patikrinimo klaidų sąrašą.
  • 10Sistema turi perspėti naudotoją, kad skaičiavimuose panaudota negaliojanti (-ios) APD.
  • 11Turi būti galimybė automatizuotu būdu įkelti APD ir ESAD iš PDF bylų. Sistema turi taikyti DI ar kitus principus pasiūlyti galimas importuoti reikšmes, reikalingas SGC poveikio aplinkai skaičiavimams, iš nestruktūruoto (pvz. PDF) dokumento. Automatizuotai išskirtos importuotinos reikšmės turi būti patogiai pateikiamos sugretinant su pirminiais importuotinais duomenimis patogiam sutikrinimui.
  • 12Turi būti galimybė sukurti, redaguoti ar panaikinti fizinių ir juridinių asmenų profilius.
  • 13Turi būti galimybė profiliams priskirti skirtingo tipo naudotojų grupes (roles).
  • 14Fizinis asmuo, atstovaudamas juridinį asmenį turi galėti matyti ir tvarkyti to juridinio asmens SGC skaičiavimų projektų duomenis.
  • 15Naudojant profilius turi būti galima tvarkyti atitinkamų statinių projektų metaduomenis.
  • 16Turi būti galima suarchyvuoti nebeaktualius statinių projektus.
  • 17SGC skaičiavimų projektai turi turėti gyvavimo ciklą (pvz. „Darbinis“, „Parengtas tvirtinimui“, „Patvirtintas“, „Pateiktas“, „Panaikintas“).
  • 18Nustatytų būsenų skaičiavimų projektų neturi būti galima koreguoti, tik kurti naujas versijas, kurios turi analogišką gyvavimo ciklą. Patvirtinus naujesnę versiją, senoji turi būti pažymėta kaip „negaliojanti“.
  • 19Turi būti galima peržiūrėti visas SGC skaičiavimų projektų versijas.
  • 20Turi būti galima panaikinti projektus.
  • 21Turi būti galimybė tvarkyti statybinių komponentų ir medžiagų biblioteką(-as).
  • 22Statybinių komponentų ir medžiagų biblioteka turi būti skirtingų lygių: bendrojo naudojimo ir naudojama tik organizacijos viduje.
  • 23SGC IS turi būti numatyti du pagrindiniai SGC scenarijai: Kuomet skaičiavimai atliekami SGC IS posistemyje; Kuomet skaičiavimai atliekami su išoriniais įrankiais.
  • 24Antruoju scenarijumi turi būti užtikrinamas duomenų, reikalingų duomenų analizei bei teikimui išorinėms sistemoms, pateikimo į SGC IS funkcionalumas. Taipogi šis funkcionalumas turi būti užtikrinamas tiek naudojantis SGC IS portalu, tiek per SGC IS integracijų API.

Prieinamumo reikalavimai

  • 1Diegėjo suprojektuotas sprendimas turi užtikrinti, kad SGC IS prieinamumas būtų ne mažesnis kaip 96 proc. laiko darbo metu nuo 8:00 iki 17:00 darbo dienomis, kiek to neriboja PDB IS infrastruktūra (kai tokį ar geresnį paslaugų teikimo lygį užtikrina duomenų centro infrastruktūra).

Duomenų analizės modulis

  • 1SGC analizės scenarijai turi būti palyginami tarpusavyje skirtingais pjūviais (grafiniu ir lenteliniu būdais).
  • 2Turi būti galima analizuoti rezultatų pasiskirstymą pagal: komponentų grupes; medžiagų tipus; gyvavimo ciklo skaičiavimo modulius. Šios analizės rezultatas turi būti vaizduojamos kaip Top 10 sąrašas, bei detali duomenų išklotinė.
  • 3Analizės duomenys turi būti interaktyvūs, suteikiant galimybę gilintis į duomenų struktūrą. Pasirinkus konkrečią konstrukciją, turi būti rodoma jos medžiagų sudėtis ir atskiros jų VAP emisijos, o pasirinkus medžiagą, matomi visi jos deklaruoti etapai ir kiekvieno etapo emisijos.
  • 4Analizės modulyje turi būti galima pasirinkti ir schematiškai matyti rezultatus, lyginant juos su etaloninėmis reikšmėmis, įmonės vidiniais arba Lietuvos nacionaliniais standartiniais lygiais.
  • 5Analizės modulyje turi būti matomas gautų rezultatų procentinis nuokrypis nuo ribinių verčių.
  • 6Analizės modulyje gautas rezultatas turi būti priskirtas klasei (analogiškai kaip skirstomas pastatų energinis naudingumas).
  • 7Klasių intervalai turi būti valdomi atskirame klasifikatoriuje. Klasifikatorius turi užtikrinti istorinių reikšmių saugojimą, kad būtų galima atsekti kuriuo laikotarpiu kokios reikšmės galiojo.
  • 8Scenarijų analizė turi būti lanksti – vieno gaminio keitimas neturėtų virsti atskiru scenarijumi.
  • 9Scenarijai turi būti versijuojami. Versija nelaikytina atskiru scenarijumi. Konkreti versija turi turėti pilną scenarijaus informaciją.
  • 10Turi būti galima peržiūrėti versijų istoriją.
  • 11Turi būti galima pasirinktą versiją pažymėti kaip „Aktuali“.
  • 12Turi būti galima palyginti tarpusavyje dvi to paties arba skirtingų scenarijų versijas.
  • 13Visus grafikus su jų duomenų išklotinėmis turi būti galima eksportuoti į PDF bei Excel formatus.
  • 14Turi būti galima nustatyti rizikos veiksnius viso statinio gyvavimo ciklo metu nuo pastato planavimo iki likvidavimo.
  • 15Vertinti pastatų rizikingumą turi būti išskiriami rizikos veiksniai, medžiagos, jų kiekiai.
  • 16Turi būti galima remiantis surinktais faktiniais energijos suvartojimo duomenimis apskaičiuoti ir įvertinti ar statinys neviršija ir potencialiai neviršys viso SGC metu projektavimo metu nustatytų CO2 rodiklių, išskiriant potencialius rizikos rodiklius.
  • 17Iš apskaičiuotų rodiklių turi būti galima modeliuoti rizikos vertinimo rodiklius ataskaitos CO2 perspektyvoje (pvz.: išskiriamos tam tikros medžiagų grupės, veiksniai, jų ribinės vertės dėl kurių pastatas viso gyvavimo ciklo metu gali išskirti daugiau CO2 nei planuota).
  • 18Turi būti vertinami rizikos veiksniai dėl: ribinių reikšmių; statybos metu galimų pokyčių; didžiausio poveikio medžiagų.

PADR administravimo modulis

  • 1Galimybė administruoti PADR (kurti, redaguoti, versijuoti).
  • 2Importo/eksporto funkcija į/iš CSV/Excel formatą.
  • 3Turi būti integruota įspėjimo funkcija apie artėjantį PADR ar APD duomenų galiojimo pabaigos terminą.
  • 4Turi būti galima duomenų rinkinio įrašą susieti su viena ar keliomis APD.

Naudotojo sąsaja ir ergonomika

  • 1Naudotojo sąsaja turi atitikti šiuolaikinius ergonomikos reikalavimus, tenkinti Elektroninių paslaugų tinkamumo naudotojams metodinėje medžiagoje pateikiamus reikalavimus bei būti projektuojama vadovaujantis gerosiomis praktikomis, pvz., ISO 9241-210 Ergonomics of human-system interaction — Part 210: Human-centred design for interactive systems ar lygiavertėmis. Naudotojų grafinė sąsaja turi būti nepriklausoma nuo platformos ir turi veikti Microsoft Windows, Linux, MAC OS, Android ir kitose plačiausiai naudojamose aplinkose.
  • 2Sistemos naudotojo sąsaja turi veikti šiose interneto naršyklėse (gamintojų palaikomose ir naujausiose jų versijose likus 6 mėn. ir garantinio aptarnavimo periodo pradžios): Google Chrome; Microsoft Edge; Mozilla Firefox; Safari.
  • 3Portalo naudotojo sąsaja turi būti pritaikyta darbui mobiliuose įrenginiuose ir konstruojama vadovaujantis adaptyvios naudotojo sąsajos (angl. „responsive web design“) principais.
  • 4Analizės bei projektavimo metu Diegėjas turi rengti ir derinti su Užsakovu naudotojo sąsajos funkcinius prototipus naudojant Figma, Axure ar analogiškus įrankius. Rengiami prototipai turi būti interaktyvūs, kad būtų galima įvertinti naudotojo sąsajos veiksmų seką (angl. „flow“). Funkcinių prototipų išeities failai ar debesijoje saugomi projektai turi būti perduoti Užsakovui savininko teisėmis.
  • 5Naudotojo sąsajos prototipo detalumas turi būti pakankamas įvertinti specifikuojamą funkcionalumą ir galimą naudotojo elgseną.
  • 6Naudotojo sąsajos funkcionalumas turi būti integruotas į TPS vartus (viršutinis meniu, apatinis meniu).
  • 7Naudotojo sąsaja turi palaikyti daugiakalbystę. Sistemos kūrimo metu turi būti užtikrinamas dviejų – lietuvių ir anglų – kalbų naudotojo sąsajos palaikymas.
  • 8Naujos kalbos pridėjimas neturi reikalauti programavimo įgūdžių. Turi užtekti aprašyti vertimo tekstus prie nustatytų sisteminių raktų (konstantų).
  • 9Data, laikas turi būti atvaizduojami pagal ISO 8601 standartą.
  • 10Naudotojo sąsaja turi būti pritaikyta reikalavimams, kurie keliami neįgaliesiems pritaikytų valstybės ir savivaldybių institucijų ir įstaigų interneto svetainių kūrimo, testavimo ir įvertinimo metodinėse rekomendacijose. Diegėjas turi užtikrinti „AA“ lygmens pasiekiamumą pagal „Web Content Accessibility Guidelines 2.1“ skaitmeninio turinio prieinamumo gaires su galimybe plėsti funkcionalumą, ateityje siekiant užtikrinti „AAA“ lygmenį.
  • 11Naudotojo sąsaja turi atliepti aplikacijų lygmens patikrinimo taisykles, t.y. naudotojo sąsaja interaktyviai turi padėti naudotojui užpildyti teisingas reikšmes, kad būtų išvengiama klaidos pranešimų. Pavyzdžiui, jeigu užpildoma anuliavimo data, tai turi būti užpildyta ir anuliavimo priežastis ir pan.
  • 12Naudotojo sąsajos valdymas turi remtis pelės ir klaviatūros įrenginiais.
  • 13Turi būti realizuotas naudojimo patogumą užtikrinantis funkcionalumas: TAB klavišo seka einant per duomenų įvedimo laukus; Užuominų ir paaiškinimų pateikimas pelės žymeklį užvedus ant grafinio objekto (angl. „tooltips“); Duomenų įvedimo formose duomenų laukai turi būti užpildomi automatiškai, jeigu Sistemoje yra saugomi atitinkami duomenys arba tokius duomenis galima interaktyviai apskaičiuoti (pvz. einamoji data, laikas ir pan.); Sistemos veiksmai, kurie gali būti vykdomi fone, turi būti taip realizuojami, kad naudotojas galėtų naudoti kitas Sistemos funkcijas. Pasibaigus foniniam darbui sistema turi informuoti naudotoją pateikiant atitinkamą pranešimą ekrane ir/arba suformuojant pranešimą į TPS vartų pranešimų modulį. Tinkamas pranešimo pateikimo būdas nustatomas įvertinant konkrečias situacijas atskirai.
  • 14Visi duomenų sąrašai turi būti: Puslapiuojami, su galimybe nurodyti kiek sąrašo puslapyje rodyti įrašų (arba taikomas alternatyvus vienu metu įkeliamų ir matomų duomenų kiekio ribojimas); Filtruojami pagal sąrašui aktualius kriterijus (vieną ar daugiau kriterijų vienu metu); Rikiuojami pagal sąrašo rikiuotinus elementus; Eksportuojami į XLSX formatą. Sąrašų eksportas turi būti vykdomas kaip foninis darbas ir apie kurio rezultato pabaigą bei atsisiuntimo nuorodą turi būti pateikiama TPS vartų pranešimų modulyje.
  • 15Naudotojui pateikiami pranešimai turi būti suformuluoti taip, kad naudotojui būtų aiški pranešimo pateikimo priežastis. Informacija apie pranešimo pateikimą sąlygojančią priežastį privalo būti pateikiama nurodant konkrečius Sistemos duomenų objektus (pavyzdžiui, laukų pavadinimus);
  • 16Jeigu naudotojui atlikus veiksmus rezultatai turės didelės įtakos, prieš atliekant veiksmą sistema turi pateikti pranešimą ir paprašyti naudotojo patvirtinti, kad tikrai norima vykdyti;
  • 17Naudotojui pateikiamame klaidos pranešime privalo būti nurodoma, kokius veiksmus naudotojas privalo atlikti tam, kad galėtų pašalinti pranešimo pateikimo priežastis ir tęsti darbą su sistema. Įvykus klaidai naudotojas apie tai turi būti aiškiai informuojamas (pvz., nukreipiamas į klaidą sąlygojančią ekraninės formos vietą, paryškinami netinkamai užpildyti formos laukai ir pan.);
  • 18Naudotojui turi būti pateikiami sėkmės pranešimai, nurodantys, kad naudotojo atlikti veiksmai yra sėkmingi (pavyzdžiui, informuojama, kad įrašas išsaugotas / ištrintas / pakoreguotas, duomenys sėkmingai įkelti ir pan.);
  • 19Klaidų pranešimai, sėkmės pranešimai ir informaciniai pranešimai turi būti išskirti skirtingomis spalvomis ar skirtingais simboliais, kad vizualiai būtų galima atskirti pranešimo pobūdį.
  • 20Naudotojo sąsajoje esantys duomenų įvedimo laukai turi turėti duomenų patikrinimo taisykles ir tikrinti įvedamų duomenų logikos korektiškumą. Preliminariai turės būti: Tikrinami privalomi įvesti duomenys; Tikrinimas duomenų formatas (datos, skaičiaus, teksto ar kitas nustatytas taisykles); Tikrinami įkeliamų rinkmenų plėtiniai ir dydžiai; Atliekamas loginis tikrinimas tarp formos elementų – vieno formos elemento parinkimas (įvedimas) turi įtakoti kito elemento įjungimą/ išjungimą ir atlikti kitus veiksmus, kurie turės būti suderinti su Užsakovu.

Išorinės integracijos sąsajos

  • 1Duomenų mainai turi būti vykdomi naudojant HTTP RESTfull protokolą. Esant objektyvioms priežastims (pvz., neegzistuoja išorinės Sistemos žiniatinklio sąsaja), galimos išimtys. Išimčių atveju Diegėjas turi suderinti duomenų mainams naudojamas technologijas ir protokolą. Diegėjas turi atsižvelgti į patvirtintą Informacinės visuomenės plėtros komiteto prie Susisiekimo ministerijos direktoriaus 2013 m. kovo 25 d. įsakymą Nr. T-36 „Dėl duomenų teikimo formatų ir standartų rekomendacijų patvirtinimo“.
  • 2Duomenų mainų sąsajos su išorinėmis sistemomis turi būti sukurtos taip, jog duomenys IS būtų teikiami ir/arba gaunami per VIISP duomenų mainų posistemį („API gateway“ komponentą). Jeigu techniškai to padaryti nėra įmanoma, turi būti gautas VSSA leidimas kurti tiesiogines sąsajas, nenaudojant VIISP duomenų mainų posistemio („API gateway“ komponento).

Šablonų administravimo modulis

  • 1Turi būti integruotas šablonų kūrimas įvairioms pastatų tipologijoms.
  • 2Turi būti galimas šablonų atnaujinimas ir versijavimas.
  • 3Turi būti galima administruoti bendruosius šablonus ir atskirai organizacijos lygmens. Bendruosius šablonus turi galėti tvarkyti tik sistemos administratorius, o organizacijos – organizaciją atstovaujantis naudotojas.
  • 4Kiekvieną kartą atnaujinus bendruosius šablonus, sistemos naudotojai turi būti informuojami informaciniu pranešimu.
  • 5Turi būti galimybė išsaugoti projektą kaip šabloną ir naujai sukurtą šabloną redaguoti prieš paskelbiant jo versiją.

Duomenų migravimas ir archyvavimas

  • 1Turi būti atliktas pirminis SGC IS veikimui būtinų duomenų užkrovimas (naudotojų teisės, klasifikatoriai ir kt.).
  • 2Turi būti įvykdytas pirminis duomenų užkrovimas iš išorinių sistemų bei registrų pagal realizuotas integracijų sąsajos apimtis.
  • 3Turi būti suimportuotos APD ir ESAD deklaracijos (preliminariai apie 200-250). Importas turi būti atliktas naudojant sukurtą funkcionalumą, skirtą automatizuotu būdu įkelti APD ir ESAD iš PDF bylų.
  • 4APD ir ESAD importas turi būti realizuotas kaip atskiras funkcionalumas, kurį būtų galima panaudoti vėliau papildomų (naujų) APD ir ESAD importui.
  • 5Istorinių SGC skaičiavimų duomenų užkrovimas nėra numatomas.
  • 6Sistemoje turi būti realizuota galimybė atlikti sistemoje tvarkomų duomenų loginį archyvavimą. Realizuojant loginio duomenų archyvavimo priemones, duomenų objektui (įrašui, susijusiems įrašams, failui ar kitam objektui) turi būti priskiriamas archyvo požymis pagal suderintas taisykles (pvz. projekto būsena „Užbaigtas“). Sistemos funkcinių modulių veiklos logikoje turi būti numatytos taisyklės kaip elgtis su logiškai suarchyvuotais duomenimis (pvz., vykdant įrašų paiešką, pagal nutylėjimą paiešką atlikti tik tuose SGC IS duomenyse, kurie nėra pažymėti kaip perkelti į loginį archyvą, tačiau naudotojo sąsajoje palikti galimybę įjungti paiešką ir tarp logiškai archyvuotų duomenų).
  • 7Turi būti sukurtos priemonės archyvinių duomenų peržiūrai.
  • 8Turi būti galimybė konfigūruoti archyvuojamų duomenų periodiškumą.
  • 9Atskirų duomenų rinkinių archyvavimas turi būti vykdomas ir periodiškumas konfigūruojamas atskirai.

Projektų valdymas ir dokumentacija

  • 1Perkamų paslaugų rezultatai: sukurtas, įdiegtas ir ištestuotas SGC IS; sukurtos sąsajos su išorinėmis informacinėmis sistemomis ir registrais; parengta SGC IS techninė bei naudotojų dokumentacija; apmokyti SGC IS naudotojai; suteikta SGC IS garantinė priežiūra.
  • 2Paslaugų teikimo reglamentas. Paslaugų teikimo reglamente nurodomi Projekto tikslai, prioritetai, iteracijų apimtys ir rezultatai, suinteresuotos šalys, darbų atlikimo grafikas, naudojami standartai ir kokybiniai reikalavimai, rizikos ir jų suvaldymo būdai, komunikavimo principai, atsakomybės, Projekto problemų nustatymo ir valdymo procedūros, papildomų paslaugų, pakeitimų dėl nenumatytų reikalavimų užsakymo ir įgyvendinimo procedūra, sistemos priežiūros ir techninio aptarnavimo paslaugų teikimo procedūros, pokyčių valdymo procedūra ir visa kita Projekto vykdymui ir pokyčių valdymui aktuali informacija.
  • 3Detalios analizės dokumentai ir interaktyvūs naudotojo sąsajos prototipai. Detalios analizės dokumentuose išanalizuojami ir detalizuojami funkciniai ir nefunkciniai Techninės specifikacijos reikalavimai bei kiti Užsakovo išsakyti poreikiai, parengiami naudojimo atvejai (angl. use cases), kurie pateikiami naudojimo atvejų diagramomis pagal UML (angl. Unified Modeling Language), duomenų modelis (esybių ryšių diagramos su esybių bei jų atributų aprašymais). Sudėtingesni naudojimo atvejai ar jų grupės turi būti detalizuojami pateikiant veiklos bei IS veikimo procesus, naudojant procesų modeliavimo diagramas (angl. UML activity diagram, BPMN (Business Process Model and Notation) ar lygiavertes diagramas). Panaudos atvejai privalo būti išsamiai aprašyti detalizuojant pagrindinį, alternatyvius scenarijus, sąlygas „prieš“, išimtis, vykdymo rezultatus.
  • 4Projektavimo dokumentai. Turi būti pateiktas SGC IS architektūros aprašymas fizinių komponentų ir programinių komponentų požiūriu, naudojamos technologijos (jų pavadinimai, versijos), informacinis vaizdas (duomenų bazės struktūros (su paaiškinimais), duomenų bazių sąsajų schemos ir kt.), funkcinis vaizdas (SGC IS funkciniai vienetai, jų funkcijos, tarpusavio sąsajos ir kt.), integracinis vaizdas (sąsajos tarp vidinių ir išorinių sistemų, kuriamos sistemos atžvilgiu), operacinis vaizdas (sisteminiai procesai, periodiniai sisteminiai darbai ir pan.), dislokavimo vaizdas (programinių komponentų pasiskirstymas techninėje įrangoje) ir kt. Projektavimo dokumentai pildomi visų iteracijų metu.
  • 5Integracines sąsajas aprašantys dokumentai. Juose turi būti detalizuojama kiekvienos integracinės ir duomenų mainų sąsajos paskirtis, realizavimo sprendimas, siunčiamus / gaunamos užklausos, teikiami / gaunami duomenys, prisijungimo ir kiti parametrai, integracinės sąsajos naudojimo pavyzdžiai ir scenarijai (angl. sequence diagram) ir kita aktuali informacija, aprašanti integracinės sąsajos veikimą, jos naudojimą. Parengiamas integracijų sąsajos aprašymas Swagger priemonėmis kur turi būti aprašytas kiekvienas metodas, kiekvieno metodo iškvietimo parametrai, pavyzdinės užklausos, galimi rezultatų statusai, pavyzdiniai rezultatai. Swagger taipogi turi būti tokio detalumo ir tikslumo, kad iš Swagger aprašymo JSON ar YAML failų būtų galima sugeneruoti integracinės sąsajos panaudojimo metodus (angl. „API client“) populiariomis programavimo kalbomis (pvz. C#, Java, PHP ir kt.)
  • 6Vidinio testavimo ataskaita, kurioje aprašyti atlikto vidinio testavimo rezultatai (apimtis, vykdymo metodika, naudoti testavimo scenarijai, testavimo scenarijų vykdymo rezultatai, testavimo aplinka, išvados).
  • 7Naudojamumo testavimo ataskaita ir naudojamumo testavimo vaizdo įrašai.
  • 8Atliktos SGC IS demonstracijos.
  • 9Sukurta programinė įranga įdiegta Užsakovo testavimo aplinkoje.
  • 10Parengti priėmimo testavimo scenarijai ir metodika.
  • 11Parengtos SGC IS diegimo instrukcijos.
  • 12Sėkmingai atliktas priėmimo testavimas - tenkinami sėkmingo priėmimo testavimo kriterijai.
  • 13Priėmimo testavimo ataskaita, kurioje apibendrinami testavimo rezultatai bei pateikiama testavimo išvada.
  • 14Patikslintas PDB IS techninis aprašymas (specifikacija).
  • 15Parengta gamybinė aplinka Užsakovo nurodytoje infrastruktūroje.
  • 16Sukurta programinė įranga įdiegta Užsakovo gamybinėje aplinkoje ir atlikti konfigūravimo darbai;
  • 17Pateiktos atnaujintos SGC IS diegimo instrukcijos.
  • 18Atliktas duomenų migravimas.
  • 19Parengtas mokymų planas. Dokumente turi būti aprašytas mokymų kursų organizavimas, pateikti detalūs mokymų planai/grafikai, mokymų grupės, mokymų vietos, nurodytos mokymų priemonės.
  • 20Parengta mokymų medžiaga.
  • 21Parengti naudotojų vadovai (naudotojų instrukcijos, administravimo instrukcijos), diegimo instrukcijos.
  • 22Parengtos metodinės rekomendacijos sistemų integratoriams.
  • 23Įvykdyti mokymai.
  • 24Sėkmingai baigta bandomoji eksploatacija - tenkinami bandomosios eksploatacijos bandomosios plane apibrėžti kriterijai.
  • 25Pašalintos bandomosios eksploatacijos metu nustatytos klaidos.
  • 26Suteiktos konsultacijos.
  • 27Parengtas garantinės priežiūros procedūros reglamentas. Dokumente turi būti aprašytas garantinės priežiūros teikimo būdas, detalizuotos garantinės priežiūros teikimo sąlygos, Diegėjo atsakomybė, Užsakovo atsakomybė, kontaktinė informacija, papildomos tvarkos (eskalavimo, klaidų registravimo, konsultavimo) ir kt.).
  • 28Atlikti reikiami pakeitimai atsižvelgiant į atsparumo įsilaužimams ir greitaveikos testavimo rezultatus.
  • 29Parengta bandomosios eksploatacijos vertinimo ataskaita.
  • 30Parengtos ataskaitos. Ataskaitose išdėstoma (neapsiribojant): pasiekti rezultatai, vykdomos veiklos ir jų progresas Paslaugų teikimo sutarties vykdymo plano – grafiko atžvilgiu; rizikos, kritiniai faktoriai ir numatomi veiksmai, prognozės ir kitos Projekto įgyvendinimui svarbios aplinkybės.

Greitaveikos ir našumo reikalavimai

  • 1Sistema turi būti projektuojama taip, kad vienu metu galėtų naudotis ne mažiau 100 naudotojų;
  • 2Reikalavimai greitaveikai ir našumui taikomi esant 5000 vnt. HTTP užklausų per minutę apkrovai.
  • 3Vidutinė naudotojų veiksmų trukmė (trukmė nuo serverio HTTP užklausos gavimo iki HTTP atsakymo išsiuntimo) neturi viršyti 3 sekundžių;
  • 4Ataskaitų formavimas neturi viršyti 10 sekundžių;
  • 5Skaičiavimų trukmė neturi viršyti 5 sekundžių;
  • 6Sistema turi būti suprojektuota ir realizuota taip, kad sudėtingesni skaičiavimai nebūtų vykdomi nuolatos (pvz. ne po kiekvieno naudotojo veiksmo, o išreikštai paties naudotojo inicijavus atitinkamą veiksmą ir pan.).
  • 7Turi būti realizuotas funkcijų ir atliekamų naudotojų veiksmų, kurios viršija nustatytus našumo reikalavimus auditavimas. Audito įraše turi būti pakankamai duomenų, kad būtų galima nustatyti, kuri sistemos funkcija netenkina našumo reikalavimų.
  • 8Sistemoje turi būti indikuojami ilgiau trunkantys procesai (funkcijos), kad naudotojui būtų aišku, jog SGC IS veikia ir nėra būtinybės iškviesti tų pačių funkcijų keletą kartų.
  • 9Naudotojui inicijavus veiksmą, sistema turi blokuoti kitus veiksmus ar pakartotinį to paties veiksmo iškvietimą iki aplikacijos sluoksnis negrąžins atsakymo.
  • 10Ilgiau trunkantys veiksmai, kur tai dera su veiklos procesu, turi būti vykdomi foniniu režimu leidžiant naudotojui toliau naudotis sistema. Pasibaigus foniniam veiksmui naudotojas turi būti informuojamas. Informaciniame pranešime, turi būti pateikiama aktyvi nuoroda, kurią paspaudus būtų atveriamas su atlikto veiksmo rezultatais susijęs langas. Naudotojui turi būti sudaroma galimybė peržiūrėti visų jo inicijuotų foninių veiksmų sąrašą bei vykdymo rezultatus, įskaitant ir įvykusius su klaidomis. Veiksmų istorija turi būti su filtravimo galimybe ir saugoma sistemos parametru nustatytą dienų kiekį.

Sistemos architektūros reikalavimai

  • 1Architektūra turi palaikyti SGC IS pajėgumų plėtros galimybes prijungiant papildomą techninę įrangą arba virtualią infrastruktūrą.
  • 2Architektūra turi būti projektuojama daugiapakopės architektūros pagrindu, sudarant jos plėtros atskirų sluoksnių lygmenyse galimybes.
  • 3Turi būti užtikrinamos sistemos plėtros galimybės neatliekant papildomų sistemos perprojektavimo ar realizavimo darbų papildyti sistemą naujais skaičiavimo ar saugyklų resursais. Pajėgumų didinimas turi būti atliekamas nestabdant sistemos darbo arba jei reikalingas sistemos stabdymas, tai turi būti atliekama ne darbo metu nuo 19:00 iki 07:00.
  • 4Sistemos programinis kodas privalo būti suskirstytas į aiškiai apibrėžtus programinius modulius.
  • 5Kiekvienas modulis privalo turėti vieną aiškią verslo arba techninę atsakomybę.
  • 6Tarp modulių draudžiamos ciklinės priklausomybės.
  • 7Moduliai privalo komunikuoti tik per viešai apibrėžtas sąsajas (angl. „interfaces“ / APIs).
  • 8Modulis privalo būti vienintelis jam priklausančių duomenų struktūrų savininkas.
  • 9Modulio vidinė realizacija neturi būti matoma kitiems moduliams.
  • 10Modulio realizacija turi būti keičiama nekeičiant kitų modulių.
  • 11Kiekvieną modulį turi būti galima ištestuoti izoliuotai.
  • 12Bendri (angl. „shared“) moduliai neturi turėti verslo logikos.
  • 13Modulio konfigūracija privalo būti lokali moduliui.
  • 14Modulio priklausomybės turi būti deklaruotos ir minimalios.
  • 15SGC IS architektūra turi būti daugiapakopė (angl. Multi-tier, N-tier), ją turi sudaryti mažiausiai 4 hierarchiniai lygmenys: vaizdavimo (angl. Presentation Layer), veiklos logikos (angl. Application Layer), duomenų bazės (angl. Database/Persistence Layer), integracijų (angl. Integration Layer).
  • 16Vaizdavimo lygmuo turi sąveikauti su veiklos logikos lygmeniu sisteminių pranešimų pagalba.
  • 17Veiklos logikos lygmuo programinėmis priemonėmis turi pilnai ar iš dalies automatizuoti veiklos procesų žingsnius ar jų dalį bei kontroliuoti programinių funkcijų vykdymo eigą. Veiklos logikos lygmenyje sisteminiai pranešimai turi būti priimami, apdorojami ir perduodami vaizdavimo lygmeniui. Taip pat šis lygmuo turi aptarnauti: (a) duomenų lygmenį, teikiant atitinkamas duomenų užklausas, apdorojant gautus duomenis, perduodant juos saugojimui ar keičiant juos; (b) vaizdavimo lygmenį, perduodant į jį iš duomenų lygmens gautus ir/ ar veiklos logikos lygmenyje apdorotus duomenis bei priimant ir perduodant kitas sistemines instrukcijas; (c) integracijų lygmenį. Sąsaja turi būti dokumentuota naudojant Swagger biblioteką.
  • 18Integracijų lygmuo turi užtikrint duomenų apsikeitimą su išorinėmis sistemomis. Duomenų mainai užtikrinami RESTful technologijos pagrindu arba, išimtiniais atvejais ir tik suderinus su Užsakovu tiesiogine prieiga prie DB. Sąsaja turi atitikti UDTS reikalavimus ir turi būti dokumentuota naudojant Swagger biblioteką.
  • 19Duomenų bazės lygmuo turi būti realizuotas operacinių sistemų failų sistemos, duomenų bazių, duomenų talpyklų ar saugyklų pavidalu. Duomenų bazės lygmenyje skirtingi duomenų rinkiniai turi būti integruojami į vieną unifikuotą duomenų mainų platformą veiklos logikos lygmenyje esančių komponentų pagalba. Kompiuterinės rinkmenos turi būti saugomos Amazon S3 objektinėje failų saugykloje (šios saugyklos paslaugą teikia VSSA).
  • 20Turi būti taikomos gerosios praktikos modeliuojant duomenų struktūras – vieningas duomenų lentelių ir atributų vardinimas, visos DB lentelės privalo turėti komentarus tiek lentelių, tiek atributų lygiu. Komentarai privalo būti aiškūs ir suprantami.
  • 21Duomenų modelis turi atitikti ne žemesnę nei 3-iąją normalinę formą (3NF), o vietose, kur tai neužtikrinama – pateikiami paaiškinamieji komentarai, pagrindžiantys sprendimo reikalingumą.
  • 22Tvarkomi duomenys turi būti įvedami vieną kartą ir automatiškai susiejami ar pakartotinai panaudojami ten, kur tai gali būti taikoma.
  • 23Tik išimtiniais ir aiškiai dokumentuotais atvejais, DB gali būti saugomi JSON ar kiti objektiniai duomenys.
  • 24SGC IS rezervinis kopijavimas, atstatymas, archyvavimas ir stebėjimas turi būti atliekamas esamomis PDB IS priemonėmis (Zabbix) jas praplečiant SGC IS komponentų stebėsenai reikalinga apimtimi.
  • 25Diegėjas turi užtikrinti, kad SGC IS duomenis būtų galima atstatyti iš rezervinių duomenų kopijų.
  • 26Diegėjas turi sudaryti reikiamas sąlygas ir atlikti reikiamus darbus, kad VSSA specialistai galėtų SGC komponentus prijungti prie stebėjimo programinės įrangos. Sistemos administratoriaus teises turintiems vartotojams turi būti užtikrinta galimybė web priemonėmis stebėti sistemos bei atskirų jos komponentų veikimo rodiklius (aktyvūs vartotojai, atminties panaudojimas, procesorių apkrova ir kiti svarbūs rodikliai) bei gauti pranešimus sutrikus komponentų veikimui ar rodikliams pasiekus kritines reikšmes.
  • 27Visų architektūros lygmenų (sluoksnių) neapdorotos ir nenumatyto veikimo klaidos (angl. „exceptions“, „crashes) turi būti automatiškai registruojamos į Sentry.
  • 28Sistemos veikimo metrikos turi būti automatiškai registruojamos į Prometheus.
  • 29Visi programinio kodo išeities tekstai privalo būti saugomi Užsakovo Git saugykloje.
  • 30Sistemos kūrimo (programavimo) metu programinis kodas turi būti saugomas SSVA Git išeities kodo saugykloje.
  • 31Diegimas į testavimo ir gamybines aplinkas privalo būti vykdomas tik iš Užsakovo Git saugykloje talpinamų išeities tekstų.
  • 32Turi būti naudojamas Git versijavimo funkcionalumas ir būtina taikyti gerąsias programinio kodo versijavimo praktikas, pvz. atšakos (angl. „branching“), kodo įkėlimo užklausos (angl. „Push Requests“).
  • 33Prieš pradedant tvarkyti programinį kodą Git saugykloje Diegėjas turi parengti ir suderinti su Užsakovu Git programinio kodo valdymo procesą.
  • 34Išeities tekstai turi būti su komentarais ir atitikti gerąsias programinio kodo formatavimo, kintamųjų bei funkcijų įvardinimo praktikas.
  • 35Išeities programinis kodas turi būti automatiškai formatuojamas naudojant Prettier (ar analogišką biblioteką, prieš tai suderinus su Užsakovu) bei patikrinama sintaksė naudojant ESLint (ar analogišką biblioteką, prieš tai suderinus su Užsakovu).
  • 36Užsakovo Git saugykloje turi būti patalpintas programinio kodo aprašymas su instrukcijomis kaip paruošti programuotojo darbo vietą, kaip paleisti programą lokaliai darbo vietoje, kaip atliekamas diegimas į testavimo ir gamybines aplinkas.

Garantinė priežiūra ir aptarnavimas

  • 1Diegėjas privalės užtikrinti SGC IS ir įdiegtos licencinės programinės įrangos garantinę priežiūrą.
  • 2Garantijos terminas –12 mėnesių po perdavimo akto pasirašymo datos.
  • 3Garantinės priežiūros paslaugos apima sukurtos programinės įrangos neatitikimų specifikacijai, klaidų, saugumo spragų ir kitų veikimo sutrikimų šalinimą bei Užsakovo atsakingų asmenų konsultavimą.
  • 4Diegėjas turi vykdyti Užsakovo atsakingų asmenų konsultavimą SGC IS veikimo, naudojimo bei tobulinimo klausimais. Konsultacijos turi būti teikiamos telefonu, el. paštu, vaizdo konferenciniais susitikimais, naudojant priežiūros tarnybos (angl. Help Desk) programinę įrangą.
  • 5Garantinės priežiūros metu Diegėjas turi sudaryti galimybę pastebėtas klaidas, saugumo spragas, sutrikimus ir aptiktus programinės įrangos neatitikimus specifikacijai elektronine forma vesti į klaidų žurnalą. Žurnalą turi pildyti Diegėjo atstovai, galimybę jį peržiūrėti ir pildyti suteikiant įgaliotiems Užsakovo atstovams. Klaidų žurnalas turi būti specializuota problemų registravimo ir sekimo programinė įranga (angl. Issue tracking software), veikianti interneto naršyklės aplinkoje.
  • 6Programinės įrangos veikimo sutrikimu laikoma situacija kai IS naudotojai dėl Diegėjo sukurtos ir/ar modernizuotos (pakeistos) programinės įrangos funkcionalumo trūkumų negali atlikti numatytų sistemos funkcijų arba yra identifikuota saugos spragos SGC IS ar jos architektūriniuose komponentuose.
  • 7Reakcijos į sutrikimą laikas – kritinių klaidų ir sutrikimų atveju ne ilgiau kaip 1 (viena) darbo valanda, kitais atvejais ne ilgiau kaip 8 (aštuonios) darbo valandos nuo pranešimo apie sutrikimą gavimo sutartu būdu;
  • 8Kritinių klaidų ir neatitikimų šalinimas – ne ilgiau kaip 4 (keturios) darbo valandos nuo pranešimo gavimo sutartu būdu. Jei klaidos ar neatitikimo per nurodytą laiką pašalinti negalima, kartu su Užsakovu suderinamas susitarimas dėl klaidos ar neatitikimo pašalinimo laiko ir laikinų darbingumo atstatymo priemonių, jeigu tokios įmanomos pagal sutrikimo pobūdį;
  • 9Neesminių klaidų ir neatitikimų šalinimas – ne ilgiau kaip 24 (dvidešimt keturios) darbo valandos nuo pranešimo gavimo sutartu būdu. Jei klaidos ar neatitikimo per nurodytą laiką pašalinti negalima, kartu su Užsakovu suderinamas susitarimas dėl klaidos ar neatitikimo pašalinimo laiko;
  • 10Turi būti užtikrintas informacinės sistemos veiklos atkūrimas – ne ilgiau kaip per 16 darbo valandų.
  • 11Diegėjas turi parengti prieinamas ir Užsakovui tinkamas informavimo apie SGC IS sutrikimus, jų registravimo ir taisymo veiksmų būseną priemones: Užsakovo ir Diegėjo suderintus telefonus, el. pašto adresus, garantinio aptarnavimo ir priežiūros tarnybos programinio įrankio adresą (nuorodą). Išvardintais būdais Užsakovo atsakingiems asmenims turi būti galimybė pranešti apie SGC IS sutrikimus, reikiamas konsultacijas, reikiamus tobulinimus (naujo funkcionalumo kūrimą) ir pan.
  • 12Garantinės priežiūros paslaugos, konsultacijos telefonu ir elektroniniu paštu turi būti teikiamos Užsakovo darbo dienomis darbo valandomis.
  • 13Jeigu Diegėjas teikdamas garantinės priežiūros paslaugas nustato, kad Programinės įrangos veikimas sutrikęs ne dėl Diegėjo prižiūrimos programinės įrangos, informuodamas Užsakovą turi nurodyti spėjamą sutrikimo priežastį.

Sistemos kūrimo aplinka ir technologijos

  • 1SGC IS turi būti diegiamas PDB IS infrastruktūroje (PDB IS šiuo metu yra talpinama valstybiniame duomenų centre).
  • 2Kuriant SGC posistemį turi būti naudojamos šios PDB IS sukūrimui naudotos pagrindinės technologijos: Linux OS, Docker containers, Bun, Bootstrap, React, NestJS, Typescript, TypeORM, MariaDB, Prometheus, Sentry.
  • 3Naudotojo sąsaja turi būti kuriama prisilaikant TPS vartuose nustatytų reikalavimų (naudotojo sąsajos komponentai, stilius, dizainas ir kt.).
  • 4Turi būti naudojami atviri dokumentų ir duomenų formatai, t. y. oficialiai įregistruoti rinkmenų tarptautiniai standartai (pvz. HTML, PDF/A, PDF, ADOC, TIFF, JPEG, PNG, ODF formatai, JSON, CSV XML formatai ir kt.).
  • 5Visi programinės įrangos funkciniai komponentai privalo palaikyti Unicode (UTF – 8) standartą.
  • 6Architektūriniai komponentai turi būti plačiai naudojami praktikoje ir būti stabilūs.
  • 7Neturi būti naudojamos programinių komponentų versijos, kurios yra testavimo stadijoje arba yra oficialiai programinės įrangos gamintojo paskelbta, kad programinė įranga nuo tam tikros datos nebebus palaikoma, tobulinama ir / ar vystoma (angl. end-of-life product).
  • 8Komponentų versijos turi būti atnaujintos iki naujausių stabilių versijų, kurios galioja priėmimo testavimo pradžios momentui.
  • 9Turi būti užtikrinta, kad atliekami naudotojų veiksmai ir kiti sisteminiai veiksmai neblokuotų kitų naudotojų ir sistemos veiksmų, išskyrus atvejus, kai dėl duomenų integralumo, naudotojams ar sistemai blokuojama prieiga prie tuo metu kitų naudotojų ar sistemos tvarkomų duomenų.
  • 10Jeigu yra sąlygų, kurioms esant vyksta naudotojo blokavimas, šios sąlygos turi būti aprašytos ir suderintos. Apie blokavimo priežastis naudotojai turi būti informuoti informatyviais pranešimais, pateikiamais blokavimo metu.
  • 11Visi sistemos pateikiami pranešimai, klaidų tekstai turi būti aiškūs, kad iš jų naudotojui būtų aišku dėl tolimesnių galimų veiksmų, jog klaidos ar pranešimo būtų išvengta.
  • 12SGC IS kūrimui ir veikimui negali būti naudojama komercinė (licencijuojama už mokestį ar su naudojimo apribojimais) trečiųjų šalių programinė įranga (netaikoma naudojamiems programavimo įrankiams (angl. Integrated Development Environment, IDE)).
  • 13Jeigu SGC IS kūrimo ar veikimo metu naudojama trečiųjų šalių programinė įranga, bibliotekos, komponentai ar kiti programiniai moduliai, jie privalo būti atviro kodo (angl. open source), su viešai prieinamu išeities kodu.
  • 14Atviro kodo programinė įranga neturi turėti jokių licencinių ar techninių apribojimų, susijusių su: naudotojų skaičiumi; serverių, procesorių ar branduolių skaičiumi; naudojamos operatyviosios atminties kiekiu; duomenų kiečiu; naudojimo trukme; funkcionalumo apimtimi; diegimo aplinkų skaičiumi; suteikti teisę naudoti, modifikuoti ir platinti programinę įrangą be papildomų mokesčių.
  • 15Naudojamos atviro kodo programinės įrangos licencijos turi būti suderinamos su Užsakovo teisėmis naudoti, modifikuoti ir toliau plėtoti SGC IS be papildomų finansinių ar teisinių įsipareigojimų trečiosioms šalims.
  • 16SGC IS vystymui ir modifikavimui neturi būti reikalaujama naudoti komercinių bibliotekų ar kitų komponentų programuotojo kompiuterizuotoje darbo vietoje.
  • 17Naujos programinės įrangos funkcionalumo ir funkcionalumo pakeitimų realizavimas neturi pareikalauti papildomos techninės ir licencijuojamos standartinės ir nestandartinės programinės įrangos įsigijimo Užsakovui.

Dokumentai20

  • 1.1. SPS 1 priedas. Techninė specifikacija (revizuota).docx
  • 1.10. SPS 10 priedas. Bendrosios sutarties sąlygos.docx
  • 1.2. SPS 2 priedas. Terminai.docx
  • 1.3. SPS 3 priedas. Tiekėjų pašalinimo pagrindai.docx
  • espd-request.pdf
  • espd-request.xml
  • README.txt
  • 1.6._SPS_6_priedas._Pasiūlymų_vertinimo_kriterijai.docx
  • 1.7. SPS 7 priedas. Pasiūlymo forma.docx
  • 1.8. SPS 8 priedas. Tiekėjo patirtis ir specialistų sąrašas.docx
  • 1.9. SPS 9 priedas. Specialiosios sutarties sąlygos.docx
  • 2. BPS SGC IT paslaugos.docx
  • 7151657_Contract notice - general directive, standard regime_0.pdf
  • 1778_7151657.pdf
  • 1. SPS SGC IT paslaugos.docx
  • 1.11. SPS 11 priedas. Deklaracija dėl Reglamento JA.docx
  • 1.12. SPS 12 priedas. Deklaracija dėl Reglamento FA.docx
  • 1.13. SPS 13 priedas. Nac. saugumo atitikties deklaracija.docx
  • 1.5._SPS_5_priedas._Tiekėjų_kvalifikacijos_reikalavimai.docx
  • 2_c4t_7151657_1.xml
tendis.lt · Sukurta recodin.lt