Darba uzdevums - Tehniskā specifikācija
1. pielikums Tehniskā specifikācija
Pie 2020. gada . Līguma EIS Pasūtījumam Nr. BVKB/2020/
Darba uzdevums - Tehniskā specifikācija
Vienotās elektroniskās darba laika uzskaites datubāzes pilnveidošanai un uzturēšanai
Šī dokumenta nolūks ir definēt prasības Elektronisko iepirkumu sistēmā veiktajam pasūtījumam par Vienotās elektroniskās darba laika uzskaites datubāzes pilnveidošanas un uzturēšanas pakalpojumiem.
Tehniskā specifikācija ir Pasūtītāja – Būvniecības valsts kontroles biroja izstrādāts dokuments, kas paredzēts Elektronisko iepirkumu sistēmu piegādātājiem darba apjoma novērtēšanai, informācijas sistēmas pilnveides un uzturēšanas līguma noslēgšanai.
1.1 Termini un saīsinājumi
Tabula Nr.1 Termini un saīsinājumi
Termins, saīsinājums | Skaidrojums |
BVKB, Pasūtītājs | Būvniecības valsts kontroles birojs |
BIS | Būvniecības informācijas sistēma |
EDLUS | Elektroniska darba laika uzskaites sistēma |
EIS | Elektronisko iepirkumu sistēma |
IKT | Informācijas un komunikāciju tehnoloģijas |
IS | Informācijas sistēma |
Izpildītājs | Piegādātājs, kas saskaņā ar Elektronisko iepirkumu sistēmā noslēgto līgumu sniegs tehniskajā specifikācijā minētos darbus. |
Kopdarbības sistēma, elektroniskā darba vide | Līguma izpildes laikā izmantotā Jama vide pieteikumu pieteikšanai un apstrādei, dokumentācijas nodevumu saskaņošanai, bibliotēkas uzturēšanai u.tml. |
Līgums | EIS noslēgtais līgums un darba uzdevums starp Pasūtītāju un Izpildītāju |
MK | Ministru kabinets |
PMLP | Pilsonības un migrācijas lietu pārvalde |
VEDLUDB, Sistēma | Vienotā elektroniskā darba laika uzskaites datubāze |
1.2 Vispārējie ierobežojumi, pieņēmumi un atkarības
• Ņemot vērā, ka BIS ir valsts informācijas sistēma un Izpildītājam, sniedzot pakalpojumus, ir jāievēro uz valsts informācijas sistēmas darbību attiecināmie normatīvie akti un ierobežojumi;
• Pilnveidojumu darbu ietvaros Izpildītājam atbilstoši saskaņotajam pilnveidojuma uzdevumam jāveic arī pilnveidojuma analīzes darbi;
• Sistēma ir izstrādāta izmantojot šādus tehnoloģijas un rīkus – PostgreSQL, .Net, ElasticSearch, WebServices;
• Pilnveidojot Sistēmas risinājuma arhitektūru jāņem vērā BIS loģiskā arhitektūra un tās izstrādes vadlīnijas;
• Pakalpojumu sniedzējs nodrošina sniegto pakalpojumu kvalitātes kontroli, piesaistot iekšējo kvalitātes kontroles vadītāju.
2 Darbu ietvars
2.1 FP-01 Sistēmas pilnveidojumu darbu ietvars:
Darba uzdevuma izpildes ietvaros pilnveidošanas darbi tiks pasūtīti un saskaņoti atbilstoši prasībā Līguma 2. pielikumā “Sadarbības kārtība” definētajam.
Darba apjoms starp pilnveidošanas un uzturēšanas pakalpojumiem tiks saskaņots un precizēts starp Pušu kontaktpersonām līguma izpildes laikā.
2.2 FP-02 Lietotājstāstu definēšana
Izpildītājam pirms Sistēmas pilnveidojumu darbu uzsākšanas jāapzina Sistēmas biznesa procesi un biznesa prasības un jādefinē darbu ietvaros izstrādājamie lietotājstāsti, ievērojot šādus nosacījumus:
• Sistēmā paredzēto lietotājstātu izstrāde tiek veikta elektroniskā kopdarbības vidē, nodrošinot elektronisku komentēšanas un saskaņošanas procesu Pasūtītāja pārstāvjiem elektroniskā kopdarbības vidē;
• lietotājstātu izstrāde tiek veikta, nodrošinot intervijas ar biznesa procesa lietotājiem, konsultējoties ar Pasūtītāju, saglabājot interviju piezīmes elektroniskā kopdarbības vidē;
• Izpildītājam jāparedz dalība intervijās vismaz ar Pasūtītāja biznesa lietotājiem un biznesa procesa ietvaros iesaistītajiem citu iestāžu biznesa lietotājiem;
• lietotājstāstu izstrādes laikā Izpildītājam ir jānodrošina vadības sanāksmju protokolēšana un to saskaņošana elektroniskajā kopdarbības vidē.
2.3 FP-03 Hashchecksum pilnveidošana
Jauna Tīmekļa pakalpe Hash summu iesūtīšanai. Pakalpē nosūtāmo datu apjoms:
• Būvlaukuma sertifikāts (token);
• Hash checksum kontrolsumma;
• Dienas datums (par kuras auditācijas pierakstiem Hash summa iesniegta);
• Links, uz kuru padot ziņu par Xxxx summas pārbaudes pabeigšanu.
Pakalpes iesūtīšanas rezultātā DB tiek saglabāts:
• visa pakalpes apjomā iesūtītā informācija (tai skaitā izveidota piesaiste konkrētam būvlaukumam);
• precīzs laiks un datums, kad notikusi datu iesūtīšana VEDLUDB, izmantojot šo pakalpi;
• versija << tiks izstrādāta versionēšanas funkcionalitāte, lai uzturētu informāciju par aktuālo un visām vēsturiskajām Hashcheksum iesūtītajām vērtībām;
• statuss (true / false vērtību formā) << tiks izstrādāta funkcionalitāte, kas nosaka iesūtūto hashchecksum statusu, piemēram, vai dati pieņemti, vai dati pārbaudīti, vai hashchecksum atbilst FIPS PUB 108-4 standartam.
Hashchecksum datu kvalitātes pārbaude:
• Tiks izstrādāta funkcionalitāte, kas veic hashchecksum pārbaudi pret FIPS PUB 108-4 standartu;
• Pārbaudes funkcionalitāte tiks izstrādāta asinhrona, jo ņemot vērā, ka praktiski var tikt saņemts liels datu apjoma īsā laika posmā, pārbaudi nodrošinot sinhroni var tikt stipri ietekmēta sistēmas veiktspēja;
• Pārbaudes rezultāta notifikācija - tiks realizēta funkcionalitāte, kas nosūtīs paziņojumu uz EDLUS pēc pārbaudes pabeigšanas;
• Papildus tiks izstrādāta funkcionalitāte termiņa konrolei, kas paredz 3 dienu termiņu kopš konkrētās dienas beigām, par kuru bija jāiesniedz hashchecksumma.
Kavējumu paziņošanas funkcionalitāte:
• Tiks realizēta iespēja VEDLUDB saskarnē norādīt e-pastu;
• Tiks realizēta funkcionalitāte, kas uz e-pastu GBV nosūtīs paziņojumu par kavētiem hashchecksum iesūtīšanas termiņiem;
• Tiks realizēta funkcionalitāte, kas uz EDLUS nosūtīs paziņojumu par kavētiem hashchecksum iesūtīšanas termiņiem.
Veiktspējas testi un nepieciešamie programmatūras izstrādes darbi, lai nodrošinātu pietiekošu veiktspēju datu saņemšanai no visiem būvlaukumiem katru dienu īsā laika posmā (parasti no 00:00 līdz 00:30).
3.1 Uzturēšanas prasības
3 Sistēmas uzturēšana
3.1.1 Uzturēšanas organizatoriskās prasības
3.1.1.1 UP-01 Uzturēšanas periods
Izpildītājam ir jānodrošina 12 (divpadsmit) mēnešu uzturēšanas periods no Līguma noslēgšanas dienas vai sasniedzot paredzēto uzturēšanas apjomu c/h.
3.1.1.2 UP-02 Pieprasījumu reģistrācijas un izsekošanas sistēma
Prasības izpilde jānodrošina atbilstoši prasībā Līguma 2. pielikumā “Sadarbības kārtība” definētajam.
3.1.1.3 UP-03 Pārskats par uzturēšanas pakalpojumiem
Uzturēšanas un atbalsta pakalpojumi tiek novērtēti (izmaksas un izpildes termiņš), pamatojoties uz Pasūtītāja pieteikumu Pieprasījumu reģistrācijas un izsekošanas sistēmā. Katra konkrēta uzturēšanas un atbalsta pakalpojuma sniegšana var tikt uzsākta tikai pēc Pasūtītāja saskaņojuma sniegšanas attiecīgā pakalpojuma novērtējumam pieteikumu reģistrā.
Izpildītājam ir jāveic uzturēšanas ietvaros sniegto pakalpojumu uzskaite un ne retāk kā vienu reizi mēnesī jāsniedz Pasūtītajam atskaite par sniegtajiem pakalpojumiem. Atskaitē jāiekļauj vismaz šāda informācija:
• uzturēšanas ietvaros atskaites mēnesī slēgto (atrisināto) pieteikumu saraksts: pieprasījumu reģistrācijas un izsekošanas sistēmā reģistrētie pieteikumi, to īss apraksts, pakalpojuma tips (izmaiņu pieprasījums, konsultācija u.c.), patērēto stundu apjoms un kopējās izmaksas
• risināšanā esošo pieteikumu sarakstu: pieprasījumu reģistrācijas un izsekošanas sistēmā reģistrētie pieteikumi, to īss apraksts, pakalpojuma tips (izmaiņu pieprasījums, konsultācija u.c.), patērēto stundu apjoms;
• mēnesī piegādāto nodevumu saraksts.
Izpildītājs līdz katra mēneša desmitajam datumam iesniedz Pasūtītājam atskaiti par paveiktajiem Sistēmas uzturēšanas darbiem par iepriekšējo kalendāro mēnesi.
3.1.2 UP-04 Uzturēšanas ietvaros piegādājamie nodevumi
Izpildītājs uzturēšanas pakalpojuma ietvaros piegādā šādus funkcionalitātes analīzes nodevumus, ja tas izriet no konkrētā darba uzdeuvma pieteikuma:
• Sistēmas konceptuālais datu modelis (dokuments).
• Interviju protokoli (dokuments), ja tiek organizētas intervijas;
• Datu apmaiņas saskarņu specifikācija (dokuments, ja tiek mainītas vai papildinātas saskarnes);
• Sistēmas un programmatūras prasību specifikācija (dokuments).
Izpildītājam uzturēšanas pakalpojuma ietvaros piegādā šādus funkcionalitātes izstrādes nodevumus, ja tas izriet no konkrētā darba uzdeuvma pieteikuma:
• Administratora rokasgrāmata (dokuments);
• Sistēmas lietotāja dokumentācija (dokuments);
• Programmatūras koda daļa;
• Testēšanas nodevums:
a. Testa plāns (dokuments);
b. Testa piemēri/scenāriji (dokuments);
c. Testēšanas rezultāti (dokuments).
3.1.3 UP-05 Uzturēšanas ietvaros piegādājamo nodevumu saskaņošanas kārtība
Vienlaikus ar izstrādes darbu pabeigšanu (kopējais darbu izpildes laiks), kas noteikts Izpildītāja pieprasījuma realizācijas piedāvājumā, ir jāiesniedz Sistēmas papildu funkcionalitātes izstrādes nodevumi atbilstoši Tehniskās specifikācijas prasībā "UP-04 Uzturēšanas ietvaros piegādājamie nodevumi" definētajam.
Tehniskās specifikācijas prasībā "UP-04 Uzturēšanas ietvaros piegādājamie nodevumi" minētos visus papildu funkcionalitātes analīzes vai izstrādes nodevumus var neiesniegt, ja netiek veiktas izmaiņas kādā no analīzes vai izstrādes nodevumiem, vai var iesniegt kopā ar citu pieprasījuma realizācijas piedāvājumu, ja pieprasījumā (darba uzdevumā) ietvertie papildu funkcionalitātes izstrādes darbi ir neliela apjoma un par to ir vienojušās abu pušu līgumā norādītās kontaktpersonas elektroniskā pasta vēstulē.
Visi Tehniskās specifikācijas prasībā "UP-04 Uzturēšanas ietvaros piegādājamie nodevumi" minētie nodevumi tiek saskaņoti ar Pasūtītāju un iesniegti Jama vidē.
Izpildītājam ir pienākums arī pēc savas iniciatīvas jebkurā brīdī iesniegt Pasūtītājam Tehniskās specifikācijas prasībā "UP-04 Uzturēšanas ietvaros piegādājamie nodevumi" minētos nodevumus vai nodevumu daļu, kas ir aktualizēti Izpildītājam patstāvīgi veicot detalizētu Sistēmas un programmatūras koda analīzi pakalpojuma izpildes laikā, bet ne retāk kā reizi pusgadā.
Pēc Sistēmas papildu funkcionalitātes izstrādes nodevumu un programmatūras koda daļas iesniegšanas Pasūtītājs 10 (desmit) darbdienu laikā izskata Izpildītāja iesniegtos Sistēmas papildu funkcionalitātes izstrādes nodevumus, kā arī veic programmatūras testēšanu. Ja Pasūtītājs konstatē nepilnības, tad Pasūtītājs nepilnības piesaka elektroniskajā kopdarbības vidē. Pēc nepilnību pieteikuma elektroniskajā vidē, Puses, izmantojot līgumā norādītās kontaktpersonu elektroniskā pasta adreses, rakstveidā vienojas par termiņu nepilnību novēršanai. Pēc nepilnību novēršanas Izpildītājs atkārtoti iesniedz nodevumus un Pasūtītājs 5 (piecu) darbdienu laikā atkārtoti veic nodevumu izskatīšanu un testēšanu attiecībā uz daļām, kur tika konstatētas nepilnības.
3.1.4 UP-06 Uzturēšanas ietvaros piegādātās funkcionalitātes pieņemšanas kārtība
Pieprasījuma realizācija ir uzskatāma par atbilstoši izstrādātu, ja Pasūtītāja testēšanas laikā nav konstatētas 1., 2. un 3.kategorijas problēmas, atbilstoši šīs Tehniskās specifikācijas prasībai "UP-09 Kļūdu un problēmu pieteikumu kategorijas". Gadījumā, ja testēšanas rezultātā tiek atklāta 4.kategorijas problēma, tad Izpildītājs un Pasūtītājs var vienoties par pieprasījuma realizācijas pieņemšanu un akceptēšanu ar nodošanas pieņemšanas aktu, vienlaicīgi vienojoties par termiņu 4.kategorijas problēmu novēršanai. Ar nodošanas pieņemšanas aktu tiek pieņemti BIS VEDLUBD papildu funkcionalitātes darbu analīzes un izstrādes nodevumi, tajā skaitā programmatūras koda daļa.
Ja Izpildītājs noteiktajā termiņā nenovērš nodošanas - pieņemšanas aktā ietvertās 4.kategorijas kļūdas atbilstoši iepriekš minētajai kārtībai, Pasūtītājs ir tiesīgs piemērot noteikto līgumsodu.
3.2 Uzturēšanas pakalpojumu saturs
3.2.1 UP-07 Sistēmas papildinājumu izstrāde
Sistēmas papildinājumi tiek izstrādāti saskaņā ar Pasūtītāja pieprasījumiem.
Prasības izpilde jānodrošina atbilstoši prasībā Līguma 2. pielikumā “Sadarbības kārtība” definētajam.
Papildinājumus Pasūtītājs pieņem, ja veicot to akcepttestēšanu netiek atklātas 1.-3. kategorijas kļūdas. Savstarpēji vienojoties, var pieņemt izstrādāto programmatūru, ja tajā konstatētas 3. un 4.kategorijas kļūdas, par kuru novēršanas termiņu puses ir vienojušās.
3.2.2 UP-08 Atbalsta pieejamība administratoram un lietotājiem
Risinājuma uzturēšanas laikā Izpildītājam jāsniedz tehniskais atbalsts, kurš ietver Pasūtītāja kontaktpersonas konsultēšanu un atbalstu risinājuma darbināšanā.
Konsultāciju pieprasījumus Izpildītājam var iesniegt Pasūtītāja norīkoti speciālisti.
Uz konsultāciju pieprasījumiem, ja tie reģistrēti Pieprasījumu reģistrācijas un izsekošanas sistēmā, atbildes tiek sniegtas elektroniski, 1 (vienas) darba dienas laikā.
Ja uzturēšanas pieprasījumā norādīts, ka nepieciešama klātienes konsultācija, Izpildītājs 1 (vienas) darba dienas laikā vienojas ar Pasūtītāja darbinieku par tikšanās laiku. Klātienes konsultācijas notiek Pasūtītāja telpās.
Telefoniskas konsultācijas tiek sniegtas pēc pieprasījuma.
Izpildītājam jānodrošina tehniskais atbalsts darba dienās no plkst. 8:00 līdz 19:00.
Izpildītājam jānodrošina tehniskā atbalsta pieejamība vismaz 1 (vienai) Pasūtītāja kontaktpersonai. Prasības izpilde jānodrošina atbilstoši prasībā Līguma 2. pielikumā “Sadarbības kārtība” definētajam.
3.2.3 UP-09 Kļūdu un problēmu pieteikumu kategorijas
Sistēmas uzturēšanas laikā Izpildītājam ir jāapstrādā ievērojot zemāk uzskaitītās kļūdu un problēmu pieteikumu kategorijas:
Kļūdu kategorija | Kļūdas apraksts |
1.kategorija: avārija | Problēma izraisa pilnīgu sistēmas darbības apstāšanos, un/vai darbs nevar tikt turpināts. |
2.kategorija: kļūda, kuru nevar apiet | Problēma izraisa iekšēju programmatūras kļūdu vai nekorektu darbību, kas rada lielus funkcionalitātes zudumus. Nav zināms (Pasūtītājam) pieņemams problēmas apiešanas risinājums, tomēr ir iespējams darbu turpināt ierobežotā režīmā. |
3.kategorija: kļūda, kuru var apiet | Problēma izraisa minimālus iespēju zudumus. Ietekme uz sistēmu ir mazsvarīga/sagādā zināmas neērtības, piemēram, manuālu darbu sistēmas funkcionēšanas atjaunošanai / darba turpināšanai. |
4.kategorija: neprecizitāte | Problēma neizraisa iespēju zudumus. Šādu pieteikumu raksturo iekšēja programmatūras kļūda vai nekorekta darbība, kuras ietekmi uz darba turpināšanu var neņemt vērā, kļūda / neprecizitāte produkta dokumentācijā. |
5. kategorija: Izmaiņu pieprasījums | Pieprasījums veikt izmaiņas vai papildināt funkcionalitāti, dokumentāciju vai veikt citus papildus darbus, kas ir ārpus līguma apjoma vai atšķiras no iepriekš saskaņotajām prasībām. |
6. kategorija: Konsultācija | Problēma neizraisa iespēju zudumus. Programmatūrā nav kļūda, bet ir radusies kāda neskaidrība par risinājuma darbību vai funkcionalitāti, izmantošanu, tehnisko apkalpošanu. |
3.2.4 UP-10 Pieteikumu slēgšana
Pieteikumu risināšana tiek pārtraukta tikai saņemot Pasūtītāja apstiprinājumu Pieprasījumu reģistrācijas un izsekošanas sistēmā, ka piedāvātais risinājums ir pieņemams vai, ka pieteikumu var slēgt citu iemeslu dēļ. Pieteikumu reģistrā pieteikumu var slēgt tikai Pasūtītājs vai tā pārstāvis.
Darbība | Kļūdu kategorija | Xxxxxxx |
Xxxxxxxxxxx ar Pasūtītāju – darbu saskaņošana | Visām kļūdām | 3 darba stundu laikā darba dienās, ja kļūda ir pieteikta laikā no plkst. 8:00 -15:00, ja kļūda ir pieteikta pēc plkst. 15:00, tad līdz nākošās darba dienas plkst. 11:00, izņemot 4. kategorijas kļūdu – vienas dienas laikā. Gadījumā, ja Izpildītājs augstāk minētajā termiņā no problēmas pieteikuma brīža nav sazinājies ar Pasūtītāju, tad Pasūtītājs piemēro noklusēšanas principu un uzskata, ka problēmas pieteikums (kļūda) ir saskaņots. |
Novērst kļūdu un nodrošināt darbspējīgu sistēmu | 1.kategorija: avārija | 8 stundu laikā darba laikā*, sākot no brīža, kad tika veikta saskaņošana. |
2.kategorija: kļūda, kuru nevar apiet | 2 darba dienu laikā*, sākot no dienas, kad veikta saskaņošana. | |
3.kategorija: kļūda, kuru var apiet | 5 darba dienu laikā*, sākot no dienas, kad veikta saskaņošana. | |
4.kategorija: neprecizitāte | 10 darba dienu laikā*, sākot no dienas, kad veikta saskaņošana. | |
*Norādītajos laikos netiek ieskaitīts periods kamēr kļūda atrodas testēšanā pie Pasūtītāja, kā arī laiks par piegādes (programmatūras) uzstādīšanu (instalāciju) produkcijas vidē par kuru vienojušās līgumā norādītās Pušu kontaktpersonas. | ||
Izmaiņu pieprasījums | Pieprasījums veikt izmaiņas vai papildināt funkcionalitāti, dokumentāciju vai veikt citus papildus darbus, kas ir ārpus līguma apjoma vai atšķiras no iepriekš saskaņotajām prasībām. | |
Konsultācijas | Problēma neizraisa iespēju zudumus. Programmatūrā, iespējams, nav kļūda, bet ir radusies kāda neskaidrība par sistēmas darbību vai funkcionalitāti, izmantošanu, tehnisko apkalpošanu, par kuru Izpildītājs konsultē Pasūtītāju, izmantojot tālruni, e-pastu vai citu elektroniskās saziņas veidu. | |
Prasības izpilde jānodrošina atbilstoši prasībā Līguma 2. pielikumā “Sadarbības kārtība” definētajam.
4 Garantijas nosacījumi
4.1 Garantijas pakalpojumu saturs
4.1.1 GP-01 Garantijas apjoms
Garantija attiecas uz:
• Uzturēšanas pakalpojumu ietvaros izstrādātajiem Sistēmas pilnveidojumiem (Izpildītāja izstrādāto programmatūru);
• Izpildītāja piegādāto standarta programmatūru; Garantijas termiņš – 12 mēneši.
Sistēmas garantijas laikā Izpildītājam bez maksas jāveic piegādātās programmatūras uzstādījumu, konfigurācijas parametru un programmatūras modifikāciju veikšana ar mērķi novērst kļūdas un datu bojājumus, kas radušies Izpildītāja apzinātas vai neapzinātas rīcības rezultātā, kāda tā bijusi, nododot Sistēmu ekspluatācijā (prasība attiecas uz visiem Sistēmas garantijas laikā veiktajiem pieteikumiem) vai Sistēmas programmatūra nenodrošina dokumentācijā norādīto funkciju realizāciju vai nenodrošina to realizāciju dokumentācijā norādītajā laikā (veiktspējas un ātrdarbības problēmas).
Garantijas ietvaros tiek nodrošināta izstrādātās programmatūras (koda daļas) funkcionēšana, kas tiek izstrādāta pakalpojuma izpildes ietvaros. Garantijas nodrošināšana sākas no pieņemšanas-nodošanas akta parakstīšanas dienas vai 90 dienu laikā no Sistēmas piegādes dienas Pasūtītājam, ja Pasūtītājs šajā laikā nav veicis Sistēmas pieņemšanas procedūru vai nosūtījis iebildumus par Sistēmas nepieņemšanas pamatu. Garantijas ietvaros Izpildītājam jānodrošina:
• visu kategoriju problēmu (klasificētas kā 1.-4. kategorijas kļūdas vai bezmaksas konsultācijas) apstrāde – reaģēšana uz pieteiktiem problēmu pieteikumiem, to saskaņošana un konsultāciju sniegšana;
• konstatēto pieteikto kļūdu, kas radušās Izpildītāja vainas dēļ, novēršana un piegāde.
Garantija neattiecas uz uzturēšanas pakalpojuma ietvaros novērstām Sistēmas kļūdām vai darbības nepilnībām.
4.2 Garantijas pieteikumu risināšanas procedūra
4.2.1 GP-02 Pieteikumu iesniegšana un saskaņošana
Prasības izpilde jānodrošina atbilstoši prasībā Līguma 2. pielikumā “Sadarbības kārtība” definētajam.
4.3 Kļūdu labojumu un izstrādes posmu instalāciju piegādes prasības
4.3.1 GP-03 Labojumu instalēšanas pakotnes
Garantijas ietvaros piegādātajām labojumu instalēšanas pakotnēm ir jābūt "inkrementālām" t.i. tās uzstādīšana ir veicama uz iepriekš piegādātas programmatūras versijas, ja vien tas nav iepriekš īpaši saskaņots ar Pasūtītāju. Labojumi nedrīkst ietekmēt datu bāzē jau esošos datus, ja vien tas nav iepriekš īpaši saskaņots vai nav labojuma priekšmets.
Instalācijām ir jābūt uzstādāmām bez Sistēmas darbības pārtraukšanas, kas ilgst ilgāk par 10 minūtēm. Ja Sistēmas darbības pārtraukšana tomēr nepieciešama, tad pārtraukuma ilgums un plānotais laiks iepriekš jāsaskaņo ar Pasūtītāju.
4.3.2 GP-05 Kļūdu labojumu piegādes kārtība
Izpildītājam kļūdu labojumi pirms to piegādes jātestē savā testēšanas vai izstrādes vidē un kopā ar risinājuma piegādi jāpiegādā testēšanas dokumentācija, kura apliecina, ka kļūdu nav iespējams atkārtot.
Kļūdu piegāde veicama:
• nekavējoties pēc 1. vai 2. kategorijas kļūdas novēršanas;
• reizi mēnesī, ja šajā laikā ir novērstas 3. vai 4. kategorijas kļūdas.
Atbilstoši veiktajiem labojumiem programmatūrā, Izpildītājam vienlaicīgi ar kļūdu piegādi, jāpiegādā papildināta/labota dokumentācija (PPS, PPA, administratoru rokasgrāmatas, lietotāju rokasgrāmatas, instalācijas instrukcijas u.c. dokumentācija, ko skar programmatūras labojumi).
Kļūdu testēšana tiks uzskatīta par veiksmīgu, ja testēšanas rezultātā netiks pieteikts neviens 1.-4. kategorijas pieteikums.
Neveiksmīga testēšanas rezultāta gadījumā Izpildītājam jāveic atklāto kļūdu bezmaksas novēršana un jāpiegādā programmatūra atkārtotai testēšanai.
Pirms katras kļūdu labojuma vai papildinājuma realizācijas rezultātā izveidotās programmatūras instalācijas produkcijas vidē BVKB jāveic pilna produkcijas vides datu rezerves kopēšana.
Pēc sekmīga akcepttesta, saskaņā ar Pasūtītāja norādījumiem, Izpildītājs instalē programmatūru produkcijas vidē.
4.3.3 GP-06 Pēdējās bezkļūdainās versijas atjaunošana
Izpildītājam jānodrošina iespēja nepieciešamības gadījumā atjaunot Sistēmas programmatūru, izmantojot pēdējo bezkļūdaino versiju.
5 Nefunkcionālās prasības
Turpmākajās nodaļās iekļautas nefunkcionālās prasības ir prasības, kas attiecināmas uz BIS. Ievērojot, ka Sistēma ir BIS funkcionāls modulis, Izpildītājam ir jāņem vērā uz BIS attiecināmās nefunkcionālās prasības un jānodrošina Sistēmas atbilstība tām tiktāl, ciktāl tās izriet no Sistēmas biznesa vajadzībām.
5.1 NFP-01 Lietotāja saskarnes lietojamība
Sistēmai jānodrošina lietotāja saskarne, kas būtu :
• latviešu valodā;
• orientēta uz lietotāju, lai būtu saprotama un ātri izpildāma katra nepieciešamā darbība, izmantojot darbību secīgas vadības ("wizard") principu;
• ar skaidriem sistēmas kļūdu aprakstiem;
• ar pieejamu palīdzības funkciju, kura sniedz paskaidrojumu par konkrētajā ekrānā veicamo darbību no lietotāja viedokļa, paskaidrojot gan ievadāmās informācijas formātu, gan kontekstu.
5.2 Prasības pieejamībai
5.2.1 NFP-02 Sistēmas mērogojamība
Projektējot un realizējot Sistēmu jānodrošina tās augstu pieejamību un veiktspēju, Izpildītājam ir jāņem vērā nepieciešamība atbalstīt Sistēmas darbināšanai izmantotās infrastruktūras mērogojamību, paredzot, ka var tikt veikta gan vertikāla (Scale-Up - palielinot esošo komponenšu jaudu/kapacitāti), gan horizontāla (Scale-Out - pievienojot jaunas papildus komponentes, piemēram - papildus serveri pieprasījumu apstrādei) infrastruktūras mērogojamība.
5.2.2 NFP-03 Pieejamības nodrošināšana
Sistēmas pieejamībai jābūt ne mazākai kā 96,75% (24*7 režīmā), par atskaites punktu pieņemot mēnesi (neskaitot paredzētos ar Pasūtītāju saskaņotos pārtraukumus, ārkārtas situācijas – force majeure). Katra ceturkšņa laikā pieļaujamie pārtraukumi nedrīkst pārsniegt 11 (vienpadsmit) stundas, katra atsevišķa pārtraukuma ilgums nedrīkst pārsniegt 4 (četras) stundas.
5.3 Veiktspējas prasības
5.3.1 NFP-04 Darbības ātrums
Sistēmas darbības ātrums jānodrošina vismaz šādā apjomā:
• pieslēgšanās pie Sistēmas, pieteikuma nosūtīšana līdz 2 sekundēm;
• formas atvēršana, saglabāšana līdz 2 sekundēm;
• predefinētas atskaites izgūšana – vienkāršas atskaites gadījumā (ne vairāk, kā trīs analizējami parametri) – līdz 8 sekundēm. Izpildītājam jāparedz rīcība sarežģītas atskaites gadījumā, nodrošinot šādu atskaišu izgūšanu kā fona procesu, lai atskaišu izgūšana nedegradētu Sistēmas kopējo veiktspēju;
• faila, kura izmērs ir līdz 10 MB, augšupielāde un lejupielāde Sistēmā līdz 3 sekundēm. Ja faila izmērs ir lielāks par 10 MB, tad iespējams apstrādes laika pieaugums, kas tiks definēts detalizētajos darba uzdevumos.
5.3.2 NFP-05 Vienlaicīgo pieprasījumu skaits
Sistēmai jānodrošina darbības ātrums, kas definēts prasībā "NFP-04 Darbības ātrums" pie vismaz 60 (sešdesmit) vienlaicīgo pieprasījumu skaita sekundē.
5.3.3 NFP-06 Kopējais lietotāju skaits
Sistēmas ietvaros jānodrošina iespēju uzkrāt informāciju par vismaz 1 000 000 lietotājiem. Jānodrošina, ka Sistēmas lietotāju skaits neietekmē Sistēmas ātrdarbību un izvirzītās veiktspējas prasības.
5.4 Sistēmas saskarnes
5.4.1 NFP-07 Prasības dizainam un lietotāja saskarnei
Sistēmas dizainam un lietotāja saskarnei ir jāatbilst šādām prasībām:
• lietotāju saskarnei ir jābūt ērtai un ergonomiskai (piemēram, horizontālo ritjoslu neesamība (datoram ar izšķirtspēju virs 1280x800), pēc iespējas mazāk vertikālo un horizontālo ritjoslu izmantošana, pārskatāms ievadlauku izkārtojums utt.);
• saskarnē izmantotajai valodai (vārdiem, frāzēm) jābūt saprotamai lietotājiem;
• ievadlauku izmēriem jāatbilst ievadāmo datu apjomam (garumam), t.i., ievadlauks nav pārāk liels vai mazs;
• Sistēmas ietvaros, apzīmējot vienu un to pašu lietu dažādos ekrānos, jābūt izmantotiem vieniem un tiem pašiem terminiem un zīmēm;
• Sistēmas standarta ziņojumiem jābūt lietotājiem viegli saprotamā valodā, precīzi jāskaidro radušos problēmu būtība un jāpiedāvā tālākās rīcības variants;
• Sistēmas dialogiem jāsatur tikai tāds informācijas apjoms, kas ir būtisks Sistēmas darbināšanai un lietotāja funkciju veikšanai;
• navigācija starp ekrānformām - Sistēmai jābūt izveidotai tā, lai lietotājam nevajadzētu atcerēties informāciju, pārejot no viena ekrāna uz citu;
• Sistēmā pie datu laukiem jābūt komentāru norādēm - vizuāliem indikatoriem, ka par datu lauka aizpildīšanu ir pieejama paskaidrojoša informācija;
• Sistēmai jānodrošina atgriezeniskā saite ar lietotāju, pēc iespējas informējot viņu par Sistēmā notiekošajām darbībām;
• Sistēmas lietotājam, pildot e-pakalpojumu vai veicot citas secīgas darbības ārējā portālā, ir iespēja atgriezties iepriekšējā solī, kur tiek attēlota iepriekš ievadītā informācija.
5.4.2 NFP-08 Operāciju izpildes laiks
Ja programmas operāciju, kas aiztur lietotāja darbu, veikšanai nepieciešams ilgāks laiks par 3 (trīs) sekundēm, Sistēma uz ekrāna parāda atbilstošu paziņojumu vai citu vizuālu notifikāciju (piemēram, smilšu pulkstenis), x.xx., meklēšanas funkcionalitātei.
5.4.3 NFP-09 Darbības atcelšana
Pēc iespējas katrai Sistēmas funkcijai jābūt iespējai atcelt tās izpildi, pārtraucot iecerēto darbību, neveicot izmaiņas datubāzē (piemēram, visās reģistrēšanas, rediģēšanas un dzēšanas ekrānformās
spiedpogas „Atcelt” pieejamība) (prasība nav attiecināma uz situāciju, kad transakcijas izpilde ir uzsākta, piemēram, aktivizējot spiedpogu „Saglabāt”).
Darbības atcelšanas iespējai jābūt skaidri redzamai un viegli pieejamai lietotājam.
5.4.4 NFP-10 Karsto taustiņu „hot keys” atbalsts
Lietotājam jābūt iespējai izmantot standarta operētājsistēmas (piemēram, Windows) un pārlūkprogrammu karstos taustiņus, piemēram, Ctrl+C, Ctrl+V, lai kopētu datus.
5.4.5 NFP-11 Interneta pārlūkprogrammu atbalsts
Sistēmai jānodrošina atbalsts šādu pārlūku pēdējām divām jaunākajām versijām:
• Microsoft Internet Explorer;
• Microsoft Edge;
• Mozilla Firefox;
• Apple Safari;
• Google Chrome.
5.5 Sistēmas darbības
5.5.1 Uzturamība
5.5.1.1 NFP-12 Prasības uzturamībai
Sistēmas kļūdu novēršanu un papildinājumu izstrādi jāspēj veikt tās Izpildītājam vai jebkuram citam profesionālam programmatūras izstrādes uzņēmumam ar pieredzi izmantotajā izstrādes vidē un produktos.
5.5.1.2 NFP-13 Prasības tehnoloģiju atbalstam
Sistēmas izveidē jāizmanto mūsdienīgas tehnoloģijas un izstrādes rīki, nodrošinot, ka izmantotās tehnoloģijas tiks uzturētas vēl vismaz 5 (piecus) gadus no to ražotāju puses (prasība neattiecas uz atvērtā pirmkoda programmatūru, šādā gadījumā jāizmanto programmatūras aktuālā versija, kura nedrīkst būt vecāka par 3 (trīs) gadiem) un Sistēmas funkcionalitāte šajā periodā varēs tikt papildināta pēc Pasūtītāja vēlmes (atbilstoši iepirkuma nolikuma nosacījumiem).
5.5.1.3 NFP-14 Integrācija ar pirmkoda pārvaldības sistēmām
Izmantotajai izstrādes videi jāatbalsta integrācija ar kādu programmatūras izejas koda uzglabāšanas un versionēšanas sistēmu.
5.5.1.4 NFP-15 Atbalsta pieejamība Sistēmas administratoram un lietotājiem
Sistēmas uzturēšanas laikā Izpildītājam jāsniedz bezmaksas tehniskais atbalsts, kurš ietver Pasūtītāja kontaktpersonas konsultēšanu un atbalstu Sistēmas darbināšanā, bet ne vairāk, kā 20 (divdesmit) cilvēkstundas 1 (viena) kalendārā gada laikā garantijas un uzturēšanas ietvaros.
Konsultāciju pieprasījumus Izpildītājam, ja tie reģistrēti uzturēšanas pieteikumu sistēmā, atbildes tiek sniegtas elektroniski, 1 (vienas) dienas laikā.
Ja uzturēšanas pieprasījumā norādīts, ka nepieciešama klātienes konsultācija, Izpildītājs 1 (vienas) darba dienas laikā vienojas ar Pasūtītāja darbinieku par tikšanās laiku. Klātienes konsultācijas notiek Pasūtītāja telpās.
Telefoniskas konsultācijas tiek sniegtas pēc pieprasījuma. Telefoniskas konsultācijas uzturēšanas pieteikumu sistēmā reģistrē Izpildītājs.
Izpildītājam jānodrošina tehniskais atbalsts darba dienās no 8:00 līdz 19:00.
Izpildītājam jānodrošina tehniskā atbalsta pieejamība vismaz 1 (vienai) Pasūtītāja nozīmētai kontaktpersonām.
Prasības izpilde jānodrošina atbilstoši prasībā Līguma 2. pielikumā “Sadarbības kārtība” definētajam
5.5.2 Uzticamība
5.5.2.1 NFP-16 Iekšējās integritātes nodrošināšana
Sistēmai jānodrošina informācijas integritāte no biznesa loģikas viedokļa.
5.5.2.2 NFP-17 Ierakstu deaktivizēšana
Sistēmā ir jānodrošina iespēja informācijas objektu un dokumentu deaktivizēšanai, uzstādot attiecīgu objekta un/vai dokumenta statusu Sistēmā. Sistēmā netiks piemērota fiziskā datu objektu un dokumenta dzēšana. Prasība ir detalizējama sistēmanalīzes ietvaros.
5.6 Sistēmas drošība
5.6.1 NFP-18 Sistēmas drošības tiesiskais regulējums
Sistēmas drošība jānodrošina atbilstoši Latvijas Republikas un starptautiskajiem informācijas sistēmu drošības standartiem un vismaz šādiem normatīvajiem aktiem:
• 2017.gada 21.februāra iekšējie noteikumi Nr.1-7/3 Ekonomikas ministrijas Informācijas sistēmu drošības politika;
• 2017.gada 17.marta iekšējie noteikumi Nr.1-7/9 Ekonomikas ministrijas Informācijas sistēmu drošības riska pārvaldības plāns;
• 2017.gada 20.marta iekšējie noteikumi Nr.1-7/10 Ekonomikas ministrijas Informācijas sistēmu drošības iekšējie noteikumi;
• 2016.gada 8.jūnija iekšējie noteikumi Nr.1-7/13 Ekonomikas ministrijas Informācijas sistēmu atjaunošanas plāns;
• 2015.gada 20.jūlija iekšējie noteikumi Nr.1-7/24 Ekonomikas ministrijas Informācijas sistēmu lietošanas noteikumi;
• 2017.gada 15.marta Ekonomikas Ministrijas rīkojums Nr.57 par informācijas sistēmu klasifikāciju un atbildīgo personu noteikšanu;
• 2015.gada 28.jūlija MK noteikumu Nr.442 "Kārtība, kādā tiek nodrošināta informācijas un komunikācijas tehnoloģiju sistēmu atbilstība minimālajām drošības prasībām";
• 2016.gada 27.aprīļa Eiropas parlamenta un Padomes regula Nr.2016/679 "Par fizisku personu aizsardzību attiecībā uz personas datu apstrādi un šādu datu brīvu apriti."
5.6.2 NFP-19 Izstrādes drošības noteikumi
Sistēmas funkcionalitāte izstrādājama un kļūdas novēršamas, ņemot vērā vismaz šādos standartos un vadlīnijās noteikto:
• OWASP izstrādātais A Guide to Building Secure Web Applications and Web Services vai ekvivalents;
• OWASP izstrādātais Testing Guide vai ekvivalents;
• ISO/IEC 27001 "Information security management systems — Requirements" un ISO/IEC 27002 "Code of practice for information security management" vai ekvivalents;
• W3C labā prakse drošu tīmekļa aplikāciju izstrādē vai ekvivalents;
Latvijas Republikas normatīvie akti, kas attiecas uz valsts informācijas sistēmām un citām informācijas un komunikācijas tehnoloģiju sistēmām, kur valsts iestāde ir sistēmas turētājs un/vai pārzinis.
5.6.3 NFP-20 Sistēmas drošības kontroles neapejamība
Lietotājiem nav iespējams piekļūt Sistēmā glabājamai informācijai, apejot drošības kontroles programmas, piemēram, operētājsistēmas, failu sistēmas vai datu bāzes līmenī.
5.6.4 NFP-21 Prasības drošai administratora pieejai
Sistēmas autorizēto lietotāju piekļuve Sistēmai jānodrošina izmantojot tikai drošu pieslēgumu, kurš izslēdz trešo personu piekļuvi Sistēmai vai pārsūtāmajiem datiem.
5.6.5 NFP-22 Informācijas kodēšana tīklā
Sistēmai jānodrošina informācijas kodēšana, pārraidot to publiskā datu pārraides tīklā (atskaitot informāciju, kas ir publiski pieejama). Informācijas kodēšanai ir jāizmanto TLS 1.2 risinājums vai ekvivalents. Izpildītājam prasību analīzes laikā jānosaka un ar Pasūtītāju jāsaskaņo algoritms, kurš tiks izmantots datu pārraides šifrēšanā.
5.6.6 NFP-23 Sistēmas darbību auditācija
Sistēmai jāveic lietotājiem pieejamo Sistēmas nodrošināto procesu auditācija (operācijas, kuras Sistēmā ir veikuši lietotāji vai automātiskie procesi).
Auditācijas pieraksti jāveido gan par parastajiem lietotājiem, gan par priviliģētajiem lietotājiem (administratoriem). Administratoriem jānodrošina iespēja apskatīt lietotāju veikto darbību žurnālu (lietotājs, kurš veicis darbību un persona, kuras dati ir mainīti vai apskatīti), kā arī iespēju atlasīt reģistrētās darbības pēc darbību raksturojošiem parametriem (dators, IP adrese, lietotājs, datums, laiks, darbības tips, sākotnējais ieraksts, jaunais ieraksts u.c.).
Sistēmas pieraksti tiek veidoti, nodrošinot, ka tajos norādītais laiks sakrīt ar faktiskā notikuma koordinēto pasaules laiku (UTC) ar vienas sekundes precizitāti
Auditācijas pieraksti uzturami lietotājam saprotamā valodā (pierakstā). Sistēmai jāveic auditācijas pieraksti vismaz par:
• lietotāju veiktajām transakcijām;
• lietotāju veiktajām darbībām autorizētajās saskarnēs;
• datu apmaiņām;
• Sistēmas kļūdu paziņojumiem;
Jānodrošina auditācijas pierakstu veidošana un uzglabāšana Sistēmā vismaz sešus mēnešus pēc ieraksta izdarīšanas.
Jānodrošina auditācijas pierakstu veidošana un uzglabāšana vismaz 18 mēnešus pēc ieraksta izdarīšanas, uzglabājot Sistēmas pierakstus vai to kopijas atsevišķi no Sistēmas.
Auditācijas pierakstu uzkrāšanas un analīzes apjoms ir jāprecizē sistēmanalīzes fāzē.
Katrā auditācijas pierakstā Sistēmai jāiekļauj vismaz zemāk uzskaitītā informācija par auditējamo notikumu:
• notikuma datums un laiks;
• notikuma veids un ar notikumu saistītā lietotāja identitāte;
• notikuma iznākums – sekmīga vai nesekmīga darbība (nesekmīgo darbību auditācijas apjoms tiks noteikts prasību analīzes laikā);
• cita attiecīgajam notikumam specifiska informācija, kura tiks identificēta prasību analīzes laikā.
Sistēmā jānodrošina sistēmas iekšējais audits, pierakstu uzturēšana par:
• veiksmīgajiem, neveiksmīgajiem, nesankcionētajiem piekļuves mēģinājumiem Sistēmai;
• visu lietotāju jebkurām darbībām ar personas datiem vai personas datu kopumiem veikta darbība vai darbību kopums, ko veic ar vai bez automatizētiem līdzekļiem, piemēram, vākšanu, reģistrēšanu, ievadīšanu, glabāšanu, sakārtošanu, pārveidošanu, izmantošanu, nodošanu, pārraidīšanu un izpaušanu, bloķēšanu vai dzēšanu Sistēmā un Sistēmas notikumiem (atbilstoši Fizisko personu datu aizsardzības likumam, Ministru kabineta 2015.gada 28.jūlija noteikumiem Nr.442 “Kārtība, kādā tiek nodrošināta informācijas un komunikācijas tehnoloģiju sistēmu atbilstība minimālajām drošības prasībām”).
5.6.7 NFP-24 Piekļuves tiesību pārbaude
Sistēma nodrošinās, ka pirms katras piekļuves individuālam objektam (funkcijai), kuram (kurai) noteikta piekļuves kontrole, tiks izpildīta piekļuves tiesību pārbaude. Piekļuve tiks atļauta, ja piekļuves tiesību pārbaude bijusi veiksmīga un attiecīgajā momentā lietotājam ir tiesības piekļūt objektam (funkcijai).
Katram piekļuves kontroles veidam, Izpildītājam prasību analīzes laikā jānosaka un ar Pasūtītāju jāsaskaņo algoritms, pēc kura piekļuves tiesību kontroles laikā tiek noteikts ir vai nav tiesības piekļuvei.
5.6.8 NFP-25 Piekļuves izsekojamība
Jebkura piekļuve Sistēmai ir izsekojama līdz konkrētam Sistēmas lietotāja kontam vai interneta protokola (IP) adresei.
5.6.9 NFP-26 Identificētam lietotājam pieļaujamās darbības
Sistēmai jānodrošina, ka lietotājs tiks sekmīgi identificēts un autentificēts pirms tiek atļauta jebkāda cita darbība ar Sistēmu.
Nesekmīgas autentifikācijas gadījumā lietotājam jāsaņem paziņojums, ka autentifikācija nesekmīga, bez paskaidrojuma par nesekmīgas autentifikācijas iemesliem.
Nesekmīgas autentifikācijas mēģinājumu rezultāti un iemesli jāsaglabā auditācijas pierakstos.
5.6.10 NFP-27 Paroļu uzglabāšana
Sistēma nodrošinās, ka paroles Sistēmā tiks uzglabātas tikai šifrētā veidā. Šifrēšanai jāizmanto kāda no drošām vienvirziena šifrēšanas metodēm, piemēram, jaucējfunkcija (hash function).
Veicot paroles maiņu, Sistēmai jāpieprasa iepriekšējās paroles atkārtota ievadi.
Ne jaunā, ne iepriekšējā ievadītā parole netiks attēlota uz ekrāna vai jeb kādā citā veidā.
5.6.11 NFP-28 Atkārtota lietotāja autentificēšana
Veicot paroles maiņu, Sistēmai jāpieprasa lietotāja atkārtota autentificēšana (vecās paroles norādīšana, atskaitot gadījumu, kad paroles maiņu veic administrators lietotāja vietā).
5.6.12 NFP-29 Pēdējās sekmīgās sesijas paziņojums
Pēc sekmīgas sesijas izveides, Sistēma uzrādīs lietotājam datumu, laiku un vietu (IP adresi), no kurienes lietotājs bija veiksmīgi izveidojis sesiju iepriekšējo reizi.
5.6.13 NFP-30 Pēdējās nesekmīgās sesijas paziņojums
Pēc sekmīgas sesijas izveides, Sistēma uzrādīs lietotājam skaitu, cik reižu lietotājs ir nesekmīgi mēģinājis izveidot sesiju kopš iepriekšējās veiksmīgi izveidotās sesijas, kā arī datumu, laiku un vietu (IP adresi), no kurienes lietotājs bija pēdējo reizi nesekmīgi mēģinājis izveidot sesiju.
5.6.14 NFP-31 Aktīvas sesijas pārtraukšana
Sistēmai ir jānodrošina Sistēmas administratoram tiesības pārtraukt jebkura lietotāja aktīvo sesiju. Sistēmā ir jānodrošina automātiskā aktīvās lietotāju sesijas pārtraukšana pēc noteiktā laika perioda (konfigurējamais parametrs), kura ietvaros netika veiktas nekādas darbības.
Pārtraucot aktīvu lietotāja sesiju, attiecīgā lietotāja darbs ar Sistēmu tiek pārtraukts un lietotāja iesāktās, bet nesaglabātās izmaiņas datos tiek atceltas (tiek pārtraukta transakciju izpilde). Lai atsāktu darbu ar Sistēmu, lietotājam jāveic lietotāja identificēšana.
5.6.15 NFP-32 Lietotāja konta slēgšana
Sistēmas administratoram jānodrošina iespēja slēgt lietotāja kontu (slēgtam lietotāja kontam nav atļauts izveidot sesiju). Slēdzot lietotāja kontu, Sistēma pārbaudīs, vai atbilstošajam lietotājam Sistēmā nav aktīva lietotāja sesija, ja eksistēs aktīva sesija, tā tiks automātiski pārtraukta līdzīgi kā prasībā "NFP-31 Aktīvas sesijas pārtraukšana".
5.6.16 NFP-33 Nesekmīgas pieslēgšanās mēģinājumu uzskaite
Sistēmai jāspēj identificēt, kad sasniegts skaits nesekmīgu autentificēšanās mēģinājumu - 3 (trīs) secīgas reizes kopš pēdējās sekmīgās autentificēšanās. Kad sasniegts vai pārsniegts noteikts skaits nesekmīgu autentificēšanās mēģinājumu, Sistēma lietotāju bloķē.
Noteiktais skaits Sistēmā jāuztur kā maināms lielums, kuru var mainīt lietotājs ar atbilstošām tiesībām (Sistēmas administrators).
5.6.17 NFP-34 Paroļu derīguma termiņš
Sistēmai jānodrošina, ka lietotājam parole jāmaina ik pēc 90 (deviņdesmit) dienām. Noteiktais laiks jāuztur kā maināms Sistēmas parametrs, kuru var mainīt lietotājs ar atbilstošām tiesībām (Sistēmas administrators).
Sistēmas lietotāja parole, kas nosūtīta publiskā datu pārraides tīklā nešifrētā veidā, ir lietojama vienu reizi un derīga ne ilgāk kā 72 stundas pēc tās nosūtīšanas.
5.6.18 NFP-35 Brīvprātīga paroles nomaiņa
Sistēmā jānodrošina lietotājam iespēja pašam pēc savas iniciatīvas nomainīt savu paroli, norādot iepriekšējo paroli. Lietotājs paroli nevar mainīt biežāk nekā 2 (divas) reizes 24 (divdesmit četrās) stundās. Papildus, Sistēmā ir jānodrošina paroles nomaiņas pieprasījuma nosūtīšanu Sistēmas administratoram.
5.6.19 NFP-36 Paroļu kvalitātes prasības
Sistēmai jānodrošina, ka, veicot paroles maiņu, tiek pārbaudīta paroles kvalitāte. Ja parole neatbilst noteiktiem kritērijiem, tā netiek akceptēta. Parolei jāatbilst vismaz sekojošiem kritērijiem:
• jābūt vismaz 9 (deviņu) simbolu garai;
• jāsatur lielais latīņu alfabēta burts;
• jāsatur mazais latīņu alfabēta burts;
• satur ciparu;
• satur citu simbolu;
• tā nedrīkst būt vienāda ar 5 iepriekšējām atbilstošā lietotāja parolēm.
Sistēmas administratoram ir jāvar mainīt kā Sistēmas parametrus atbilstoši noteiktajai drošības politikai.
5.6.20 NFP-37 Paroles saglabāšanas ierobežojums
Sistēma nepieļauj iespēju Sistēmas lietotājam saglabāt savu paroli tā, lai tā turpmākajās pieslēgšanas reizēs nav jāievada.
5.6.21 NFP-38 Paroles atjaunināšana
Jānodrošina paroles atjaunošana, kad lietotājs ir aizmirsis/pazaudējis paroli, lai veiktu autentificēšanos kontā. Lietotājam Sistēmā ir jānodrošina iespēja veikt pieprasījumu par paroles atjaunošanu, gadījuma, ja parole ir aizmirsta. Detalizēts paroles atjaunināšanas risinājums jādefinē sistēmanalīzes laikā.
Sistēmas lietotāja parole, kas nosūtīta publiskā datu pārraides tīklā nešifrētā veidā, ir lietojama vienu reizi un derīga ne ilgāk kā 72 stundas pēc tās nosūtīšanas.
5.6.22 NFP-39 Sistēmas datņu pārbaude pret vīrusiem
Visām datnēm, kuras netiek izveidotas Sistēmas darbināšanas laikā, ir jābūt pārbaudītām un brīvām no vīrusiem, lai nodrošinātu drošu un nepārtrauktu Sistēmas darbību. Antivīrusu pārbaude veicama visām datnēm, kuras tiek augšupielādētas sistēmā.
Antivīrusu pārbaude kā fona process jāveic visām datnēm, kuras ir uzkrātas Sistēmā, nodrošinot pārbaudi pret jaunākajām vīrusu definīcijām ne retāk, kā reizi diennaktī. Iespējamās rīcības inficētu datņu atklāšanas gadījumā jāprecizē analīzes fāzē.
5.6.23 NFP-40 HTTPS protokola iedarbināšana
Izpildītājam jānodrošina tīmekļa servera konfigurācija tā, lai servisi, kas paredzēti ierobežotam lietotāju lokam (reģistrētiem un autentificētiem lietotājiem), tiktu darbināti tikai caur šifrētu datu pārraides kanālu (izmantojot HTTPS protokolu).
Izpildītājam jāveic Sistēmas pirmkoda novērtēšana un sagatavošana (ja tāda nepieciešama) darbam caur HTTPS protokola šifrētu datu pārraides kanālu.
5.7 Informācijas pārvaldība
5.7.1 NFP-41 Informācijas aizsardzība
Sistēmai jānodrošina apstrādājamās informācijas aizsardzība, lai neautorizētas personas vai Sistēmas nevarētu izgūt vai modificēt informāciju, kas nav publiski pieejama.
Īstenojot Sistēmas drošību, ir jānodrošina šādi principi:
• „Zina tikai tas, kuram jāzina” (need-to-know);
• „Ir jānodrošina minimālās tiesības pienākumu pildīšanai” (least privilege);
• jābūt nodrošinātai lietotāju darbību uzskaitei (accountability).
5.7.2 NFP-42 Datu atjaunošana
Sistēmai jānodrošina datu atjaunošanas iespējas no rezerves kopijām ar datu bāzes līdzekļiem.
5.8 Verifikācija
5.8.1 NFP-44 Sistēmas testēšana
Izpildītājam, izmantojot savu testēšanas vidi, pirms programmatūras piegādes Pasūtītājam, ir jānodrošina to testēšana atbilstoši savām iekšējām procedūrām, neiesaistot Pasūtītāja darbiniekus, lai pārliecinātos par programmatūras gatavību iesniegšanai Pasūtītājam.
Izpildītājam ir jānovērš testēšanas laikā atklātie defekti un jāiesniedz Pasūtītājam testēšanas protokoli, tajā skaitā automātisko testu skripti, ja tādi ir izstrādāti.
Pirms katras Sistēmas nodevuma testēšanas Izpildītājam papildus jāveic Sistēmas integrācijas, veiktspējas un drošības testēšana.
Izpildītāja testēšanas videi ir jābūt nodalītai no izstrādes vides un jānodrošina arhitektūra, kura atbilst produkcijas videi.
5.8.2 NFP-45 Sistēmas drošības testēšana
Izpildītājam ir jāveic piegādājamās funkcionalitātes testēšana ar mērķi pārbaudīt Sistēmas noturību pret nesankcionētu pieeju, noturību pret uzbrukumiem.
Izpildītājam ir jānovērš testēšanas laikā atklātie defekti un jāiesniedz Pasūtītājam testēšanas protokoli. Drošības kļūdas tiek atzīmētas kā kļūdas ar 1.kategoriju.
5.8.3 NFP-47 Veiktspējas, ātrdarbības un slodzes testēšana
Daudzlietotāju režīma veiktspējas, ātrdarbības un slodzes testēšanai ir jāsimulē Sistēmas darbību:
• nominālas noslodzes apstākļos (šī testa ietvaros ir jāparāda, ka Sistēma var izpildīt noteiktās ātrdarbības prasības nominālas noslodzes apstākļos);
• maksimālas noslodzes apstākļos (pakāpeniski paaugstinot noslodzi, nosakot slieksni, kad veiktspējas prasības vairs netiek izpildītas vai arī līdz Sistēmas darbības atteicei);
• stabilitātes testos (šī testa ietvaros ir jāpārbauda Sistēmas darbības stabilitāte to ilgstoši darbinot nominālas noslodzes režīmā).
Noslodzes nosacījumi ir jādetalizē programmatūras prasību specifikācijā.
Pirms slodzes testēšanas Izpildītājam ar Pasūtītāju jāsaskaņo precīzi testa scenāriji un slodzes testa izpildes nosacījumi, kā arī kritēriji, pēc kuriem tiek akceptēta Sistēmas darba spēja plānotajos ekspluatācijas apstākļos.
2. pielikums Sadarbības kārtība
Pie 2020. gada . Līguma EIS Pasūtījumam Nr. BVKB/2020/
SADARBĪBAS KĀRTĪBA
1. Definīcijas
1.1. Sistēma – Būvniecības informācijas sistēmas lietotāju atbalsta sistēma.
1.2. Jama – Pasūtītāja informācijas sistēmu izmaiņu pārvaldības sistēma (Jama), kurā Pasūtītājs uztur Pieprasījumus, to statusa informāciju un citu ar Pieprasījumiem saistīto informāciju.
1.3. Izpildītāja projekta pārvaldības vide (IPPV) – Izpildītāja projekta pārvaldības vide, kurā Izpildītājs izstrādā, iesniedz Pasūtītājam (sinhronizējot no IPPV uz Jama) un uztur Pieprasījumus un ar tiem saistīto informāciju.
1.4. Pieprasījums – reģistrēts ziņojums, kurš tiek klasificēts kā izmaiņu pieprasījums, ja nepieciešamas izmaiņas vai papildinājumi sistēmā, konsultācijas (x.xx. gadījumi, kad veikts detalizēts darbietilpības izvērtējums, bet konkrētais darbs netiek pasūtīts), garantijai nepakļauto kļūdu novēršana vai citi pakalpojumi Darba uzdevumā noteikto Darbu izpildei.
1.5. Nodevums – Izpildītāja jebkurš darba rezultāts, kas iesniedzams Pasūtītājam;
1.6. Iesniegt Jama - Izpildītāja sagatavoto nodevumu sinhronizācija no IPPV uz Jama, izmantojot Pasūtītāja rīcībā esošo sinhronizācijas moduli Tasktop, atbilstoši Darba uzdevuma nosacījumiem.
2. Pamatnostādnes
2.1. Sistēmas darbībā konstatētās problēmas, nepieciešamās izmaiņas vai citus pakalpojumus ir jāpiesaka, izmantojot Jama.
2.2. Sadarbības uzsākšana:
2.2.1 Izpildītājs 5 (piecu) darba dienu laikā pēc Darba uzdevuma noslēgšanas piešķir Pasūtītājam IPPV lietotāju (ar tiesībām, kas ļauj veikt pilnvērtīgu nepieciešamo datu apmaiņu (sinhronizāciju)) datu apmaiņai ar Jama un izveido IPPV pieteikumiem statusa lauku ar vismaz šādiem statusiem:
Nr. | Statusa nosaukums | Statusa apraksts |
1. | Neaprstrādāts | Pieprasījums ir reģistrēts – Izpildītājs veic sākotnējo apstrādi |
2. | Jauns | Izpildītājs ir veicis sākotnējo apstrādi vai izvērtējumu – Pasūtītājam jāpieņem lēmums par tālāko virzību |
3. | Izvērtēšana | Izpildītājs veic darbu novērtējumu un rezlutātā piegādā tehnisko informāciju par darbu un tā apjomu |
4. | Saskaņošana | Izpildītājs ir veicis darbu sākotnējo novērtējumu vai detalizētu izstrādes darbu analīzi – Pāsūtītājam jāpieņem lēmums par tālāko virzību |
5. | Analīze | Izpildītājs veic sistēmas papildinājuma analīzi, kuras rezultātā piegādā realizācijas aprakstu un izstrādes darbu novērtējumu |
6. | Izstrāde | Izpildītājs veic Pieprasījuma izpildi |
7. | Piegādāts | Izpildītājs veicis darba rezultātu piegādi – Pasūtītājam jāveic pārbaude |
8. | Testēšana | Pārbaudes procesā – par statusa uzstādīšanu atbildīgs Pasūtītājs |
9. | Veiksmīgi notestēts | Pārbaudes procesā Pasūtītājs konstatējis, ka piegādātais risinājums atbilst Pieprasījumam |
10. | Atvērts | Pasūtītājs noraida piegādāto risinājumu |
11. | Slēgts | Pasūtītājs ir akceptējis piegādāto risinājumu un Pieprasījums tiek slēgts |
12. | Atcelts | Pasūtītājs pieņēmis lēmumu atcelt Pieprasījuma risināšanu |
13. | Atlikts | Pasūtītājs pieņēmis lēmumu pagaidām Pieprasījumu nerisināt |
2.2.2 Pasūtītājs ar Izpildītāju 5 (piecu) darba dienu laikā pēc lietotāja piešķiršanas datu apmaiņai ar IPPV, veic sinhronizācijas izveidi un veic sinhronizācijas pārbaudi. Izpildītājam jānodrošina
atbalsts IPPV konfigurēšanai pēc Pasūtītāja pieprasījuma tā, lai tiktu nodrošināta veiksmīga sinhronizācija starp IPPV un Jama.
3. Pieprasījumu pieteikšanas kārtība
3.1. Pasūtītāja darbinieki reģistrē Pieprasījumu Jama, kas satur informāciju par radušos problēmu, nepieciešamajām sistēmas izmaiņām un citiem sistēmas atbalsta pakalpojumiem.
3.2. Izpildītājs precizējošu informāciju par Pieprasījumu var saņemt pie reģistrētā Pieprasījuma komentārā pieprasot precizējošo informāciju.
3.3. Gadījumā, ja datu apmaiņa ar Jama nedarbojas, Izpildītājs sarakstei ar Pasūtītāju vai pieteicēju var izmantot e-pastu. Kad datu apmaiņa ir atjaunota, sarakste, kas notikusi ārpus Jama, tiek pievienota Jama.
3.4. Pēc tam, kad Pieprasījuma statuss norādīts uz “Jauns”, informācija par Pieprasījumu no Jama automātiski tiek sinhronizēta uz IPPV.
3.5. Jama tiek norādīti šādi Pieprasījuma parametri: ID Nr., Reģistrācijas datums, Svarīgums, Pieteicējs, Nosaukums, Detalizēts apraksts, Pielikumi un komentāri, ja nepieciešams.
3.6. Darba uzdevumā norādītajai kontaktpersonai Pasūtītājs var pieteikt Pieprasījumus e-pastā, mutiski tikšanās laikā vai telefonsarunā, vai citādi informējot Izpildītāju – šādā gadījumā pieteikuma reģistrāciju Jama var veikt arī Izpildītājs, atbilstoši 3.5. punkta apjomam.
4. Pieprasījuma sākotnējā apstrāde, izvērtēšana un analīze
4.1. Sākotnējās apstrādes rezultātā Izpildītājs sniedz informāciju par Pieprasījuma klasifikāciju – kļūda, bezmaksas konsultācija, maksas konsultācija, sistēmas pilnveidojums.
4.2. Ja Pieteikums 4.1. punktā noteikto darbību rezultātā klasificēts, kā kļūda, kas novēršama garantijas ietvaros, vai bezmaksas konsultācija, Izpildītājs nekavējoties uzsāk Pieprasījuma risināšanu.
4.3. Ja Pieteikums 4.1. punktā noteikto darbību rezultātā klasificēts, kā maksas konsultācija vai sistēmas pilnveidojums (vai kļūda, uz kuru garantija nav attiecināma), Pasūtītājs pieņem lēmumu par tālāko Pieprasījumu virzību, attiecīgi uzstādot statusu “Izvērtēšanā”, vai atceļ Pieprasījuma tālāku apstrādi uzstādot statusu “Atcelts” vai “Atlikts”.
4.4. Pieprasījuma izvērtēšanas rezultātā Izpildītājs sniedz šādu informāciju:
4.4.1 Indikatīvu darbietilpības novērtējumu izstrādei vai, ja nepieciešami detalizētas analīzes darbi pilnveidojumu izstrādes specificēšanai un apjoma novērtēšanai, tad tiek novērtēts un sniegts prognozējamais analīzes darbu darbietilpības novērtējums.
4.4.2 Prognozējamais Pieprasījuma realizācijai nepieciešamais laiks;
4.4.3 ietekme, kādu tā var atstāt uz jau ieplānotiem Pieprasījumiem;
4.4.4 Gadījumā, ja Pieprasījums klasificējams, kā maksas konsultācija, sistēmas pilnveidojums vai kļūda, uz kuru garantija nav attiecināma, pieprasījuma izvērtēšanai patērētais laiks, kas nepārsniedz 4 stundas.
4.5. Sākotnējās apstrādes, izvērtēšanas rezultātu vai analīzes rezultātu Izpildītājs piegādā Jama sistēmā, ja Jama nav pieejama - sūta e-pastā uz pieteicēja e-pastu.
4.6. Pēc 4.5. minētās informācijas saņemšanas Pasūtītājs pieņem lēmumu par Pieprasījuma tālāku virzību norādot lēmumu Jama pieprasījumā – komentāra formā vai uzstādot attiecīgu statusu. Neskaidrību gadījumā vienošanās tiek veikta Jama komentāros, ja Jama nav pieejama, komunicē e-pastā. Kad datu apmaiņa ir atjaunota, sarakste, kas notikusi ārpus Jama, tiek pievienota Jama.