Iepirkums
Iepirkuma nolikuma pielikums Nr.2 (iepirkums Nr.ESP-2020/14)
Iepirkums
“eParakstītājs 3.0, bibliotēku, pārlūkprogrammu paplašinājumu un saistīto servisu uzturēšanas un izstrādes darbi”
Tehniskā specifikācija
Satura rādītājs
3. Dokumentā izmantoto prasību struktūra 2
4. Priekšmeta komponenšu konceptuāla augsta līmeņa arhitektūra 2
5. Tehniskās specifikācijas piemērojums 3
7. Priekšmeta uzturēšanas prasības 5
8. Pieteikumu tipi un to apstrādes prasības 7
9. Pasūtījumu pārvaldības prasības 10
10. Uzturēšanas pakalpojumu (tai skaitā izstrādes prasības) sniegšanas pārvaldības prasības 12
11. Dokumentācijas prasības 18
13. Izstrādes un piegādes prasības 22
1. Dokumenta tvērums
1.1. Šis dokuments definē LVRTC noteiktās prasības attiecībā uz tās pārvaldībā esošo eParakstītājs 3.0 programmatūras un ar to cieši saistīto risinājumu (turpmāk – Priekšmets) uzturēšanas un izstrādes darbiem.
1.2. Visas dokumentā definētās prasības attiecībā uz Priekšmeta uzturēšanas pakalpojuma sniegšanu ir obligātas un ir izpildāmas pilnā apjomā veicot jaunas izstrādes. Prasības, kuras nav pasūtītas esošajās Priekšmeta komponentēs vai pielāgojumos atbilstoši iepriekš noslēgtajiem izstrādes Darba uzdevumiem vai Izmaiņu pieprasījumiem, var tikt pasūtītas no Pasūtītāja puses kā izmaiņu pieprasījumi.
1.3. Priekšmeta uzturēšanas pakalpojuma tvēruma augsta līmeņa arhitektūra ir aprakstīta Tehniskās specifikācijas 4.punktā un attēlota 1.attēlā.
2. Termini un saīsinājumi
Termins / saīsinājums | Apraksts |
eIDAS regula | Eiropas Parlamenta un Padomes 2014. gada 23. xxxxxx Xxxxxx (ES) Nr. 910/2014 par elektronisko identifikāciju un uzticamības pakalpojumiem elektronisko darījumu veikšanai iekšējā tirgū un ar ko atceļ Direktīvu 1999/93/EK |
Risinājums | eParakstītājs 3.0 programmatūra un ar to cieši saistītās komponentes (Tehniskās specifikācijas 4.punkts) |
Pakalpojuma sniedzējs | Xxxxxxxxxx, kurš atbilstoši veiktā iepirkuma rezultātiem tiks izvēlēts kā iepirkuma priekšmeta uzturēšanas pakalpojuma piegādātājs. |
Pasūtītājs jeb LVRTC | Valsts akciju sabiedrība “Latvijas Valsts radio un televīzijas centrs” |
PMLP | Pilsonības un migrāciju lietu pārvalde |
VEDUS | Pasūtītāja pārvaldībā esoša darba uzdevumu un incidentu pieteikumu informācijas sistēma. |
3. Dokumentā izmantoto prasību struktūra
3.1. Katra tehniskajā specifikācijā definētā prasība ir aprakstīta, izmantojot šādu struktūru:
3.1.1. Prasības ID – konkrētās prasības identifikators;
3.1.2. Prasības apraksts – konkrētās prasības virsraksts un detalizēts prasības apraksts.
4. Priekšmeta komponenšu konceptuāla augsta līmeņa arhitektūra
Instalācijas pakotne
4.1. Priekšmeta mērķis ir nodrošināt kvalificēta elektroniskā paraksta radīšanu un tā pārbaudes atbilstoši Eiropas savienības un Latvijas normatīvo aktu prasībām. Augsta līmeņa Priekšmeta komponenšu arhitektūra ir redzama 1.attēlā.
Rokasgrāmatas
JAVA eDOC
bibliotēkas
eParaksts Proxy
eParakstītājs 3.0 |
eID starpprogramatūra |
Viedkaršu draiveri |
Pārlūkprogrammu spraudnis/paplašinājumi |
1.attēls – Priekšmeta komponenšu arhitektūra
4.2. Priekšmetu veido 1.attēlā attēlotās Priekšmeta daļas.
4.3. 1.attēls parāda galvenās sastāvdaļas, taču to komplektācija būs dažāda, t.i., jānodrošina dažādas versijas dažādām OS, kā arī, instalācijas pakotnes, kas ietver tikai atsevišķas daļas. Piemēram, instalācijas pakotne tikai eParakstītājs 3.0 vai tikai pārlūka spraudnis ar draiveriem.
4.4. eParakstītājs 3.0 un Java eDOC bibliotēku realizācija balstīta uz Java programmatūru, kas attiecīgi tiek papildināta ar nepieciešamiem instalācijas vedņiem un skriptiem attiecīgajai operētājsistēmai.
4.5. Neatkarīgi no lietotāja darbstacijas iestatījumiem, eParakstītājs 3.0 instalācijas pakā ir iekļauta Java programmatūra, kas tiek izmantota tikai eParakstītājs 3.0 darbam, tādējādi nodrošinot stabilu eParakstītājs 3.0 darbu.
4.6. Instalācijas/programmatūras pakas komponentes Viedkaršu draiveri un eID starpprogrammatūru uztur attiecīgie viedkaršu ražotāji un IeM PMLP. Izpildītāja pienākums ir tos komplektēt instalācijas/programmatūras pakās.
4.7. Pasūtītāja rīcībā esošie sertifikācijas pakalpojumu servisi, kuri pieejami Priekšmeta darbības nodrošināšanai:
4.7.1. eParaksts Proxy (Priekšmeta sastāvdaļa) – specializēts starpniekserviss, kas nodrošina Priekšmetam iespēju piekļūt tam nepieciešamajiem servisiem (piemēram, 4.7.2, 4.7.3 un 4.7.4.punktos minētajiem) caur vienu piekļuves punktu un sniedz iespēju efektīvāk pārvaldīt izejošos savienojumus.
4.7.2. TSA (Time Stamp Authority) – laika zīmogošanas serviss, kas nepieciešams parakstītu dokumentu laika zīmogošanai.
4.7.3. CRL (Certificate Revocation List) – atsaukto sertifikātu saraksts, kas nodrošina iespēju veikt sertifikāta statusa pārbaudes pret CRL failiem.
4.7.4. OCSP (Online Certificate Status Protocol) – sertifikātu statusa tiešsaistes pārbaudes protokols, kas nodrošina iespēju pārbaudīt sertifikāta statusu uz pieprasījuma brīdi.
4.8. Punkta 4.7.2., 4.7.3. un 4.7.4. apakšpunktos minētie servisi tiek nodrošināti ārpus šī iepirkuma un to darbību un pieejamību nodrošina Pasūtītājs.
4.9. Nepieciešamo dokumentāciju 4.7.2., 4.7.3. un 4.7.4. apakšpunktos minēto ārējo servisu izmantošanai pēc Izpildītāja pieprasījuma nodrošina Pasūtītājs.
5. Tehniskās specifikācijas piemērojums
5.1. Šajā tehniskajā specifikācijā noteiktās tehniskās izstrādes prasības esošajiem risinājumiem ir piemērojamas tik tālu, cik tās ir ieviestas un nodrošinātas līdz Līguma slēgšanas brīdim.
5.2. Tehniskajā specifikācijā noteiktās prasības ir attiecināmas uz pilnīgi visām jauno komponenšu izstrādēm.
5.3. Gadījumā, ja Pasūtītājs kādu no tehniskajā specifikācijā minētajām tehniskās izstrādes prasībām vēlas attiecinātu uz esošajām komponentēm, tad tās izpilde tiek pasūtīta caur izmaiņu pieprasījumu.
5.4. Drošības, piegāžu testēšanas, sagatavošanas, nodošanas un pieņemšanas prasības ir attiecināmas uz esošām komponentēm.
6. Vispārējās prasības
Prasības ID | Prasības apraksts |
VSP-01 | Risinājuma uzturēšanas apjoms Pakalpojuma sniedzējam, veicot Priekšmeta uzturēšanu, jānodrošina šādu pakalpojumu sniegšana: • Priekšmeta kļūdu un darbības problēmu novēršana; • Konsultatīvā atbalsta sniegšana Pasūtītāja darbiniekiem; • Priekšmeta izmaiņu veikšana saskaņā ar Pasūtītāja definētajiem pieprasījumiem; • Priekšmeta pilnveidošana saistībā ar ārējo normatīvo aktu izmaiņām, Biznesa procesu darbības procesu uzlabošanu, jaunu datu apmaiņas |
Prasības ID | Prasības apraksts |
risinājumu ieviešana un citi pilnveidošanas darbi tiktāl, cik tas neskar būtiskas Priekšmeta funkcionalitātes izmaiņas; • Priekšmeta drošības un veiktspējas nepieciešamo prasību nodrošināšana; • Priekšmetam nevajadzīgo vai novecojušo moduļu vai procesu izņemšana no sistēmas; • Pirmkoda, kompilētā koda un dokumentācijas repozitoriju uzturēšana; • Priekšmeta izstrādes vides nodrošināšana Priekšmeta komponentēm, kurām Pasūtītājs nenodrošina izstrādes vidi. • Apmācību organizēšana, ja nepieciešams; • Dalība Pasūtītāja organizētajos atbilstības, drošības un veiktspējas auditos pēc Pasūtītāja pieprasījuma; • Sadarbība ar Pasūtītāju. | |
VSP-02 | Pakalpojuma apmaksas nodrošināšana Apmaksa par Pakalpojuma sniegšanu tiek iedalīta šādās daļās: • Priekšmeta regulārās uzturēšanas nodrošināšana, par kuru tiek piemērota fiksēta ikmēneša maksa. Fiksētajā ikmēneša maksā tiek iekļautas visas Tehniskās specifikācijas prasības (5*8 režīms), nodrošinot Risinājuma pieejamību (kļūdu labojumi (ja tādi ir), pielāgojumi jaunām operētājsistēmām, pārlūkprogrammām u.c. komponentēm, kuru versijas var ietekmēt Risinājuma darbību), kā arī jāsniedz konsultācijas. • Izmaiņu pieprasījumi - kas tiek realizēti Pusēm atsevišķi vienojoties atbilstoši tehniskās specifikācijas IP sadaļas prasībām un apmaksāta pēc Pretendenta iesniegtās stundas likmes (piemēram, jaunu viedkaršu atbalsts, jauna funkcionalitāte, vai izmaiņas esošajā funkcionalitātē). |
VSP-03 | Pakalpojuma sniegšanas laiks Pakalpojuma izpilde ir veicama šādos laika periodos: • Priekšmeta uzturēšanas nodrošināšana – periods tiek noteikts līgumā; • Garantijas saistību nodrošināšana - 2 (divus) gadus pēc konkrētās piegādes: o pieņemšanas - nodošanas akta parakstīšanas (gadījumos ja piegāde tiek veikta uz atsevišķas, savstarpēji noslēgtas vienošanās pamata), vai; o pēc konkrētās piegādes ieviešanas produkcijā, par to izdarot piezīmi Pasūtītāja incidentu un darba uzdevumu pārvaldības sistēmā, kurā minētā piegāde ir reģistrēta. |
VSP-04 | Pakalpojuma sniegšanā iesaistāmais personāls Lai izpildītu tehniskajā specifikācijā noteiktās prasības, Pakalpojuma sniedzējam visā Vispārīgās vienošanās izpildes laikā ir jānodrošina pietiekama kvalificēta personāla pieejamība, kuru kvalifikācija atbilst iepirkuma prasībām. Sanāksmēs ar Pasūtītāju ir jāpiedalās Pakalpojuma sniedzēja iepirkuma piedāvājumā norādītajam Projekta vadītājam un/vai Sistēmanalītiķim. Pasūtītājs, veicot komunikāciju ar Pakalpojuma sniedzēju, saziņu veic pa tiešo ar konkrēto speciālistu, kurš norādīts Iepirkuma piedāvājumā. |
Prasības ID | Prasības apraksts |
Ja Pakalpojuma sniedzēja pusē mainās personāls, Pakalpojuma sniedzējam, iepriekš saskaņojot to ar Pasūtītāju, jānodrošina līdzvērtīgas kvalifikācijas speciālists. Šajā gadījumā, Pakalpojuma sniedzējam savlaicīgi par šo faktu jāinformē Pasūtītājs un jāiesūta jaunā speciālista CV un pieredzes apraksts. | |
VSP-05 | Pakalpojuma sniegšanas vieta Pakalpojuma sniedzējam jānodrošina, ka Pakalpojuma sniegšana tiek realizēta veidā, kas nodrošina tehniskās specifikācijas ietvaros noteikto prasību izpildi, paredzot, ka izpilde var tikt veikta gan attālinātā veidā, izmantojot Pakalpojuma sniedzējam piešķirtās pieejas tiesības Priekšmeta izstrādes videi (ja tāda tiek nodrošināta), kā arī veicot klātienes darbības, ja konkrētais Pakalpojums jāsniedz citās vidēs. |
VSP-06 | Autortiesības Visas autora mantiskās tiesības uz Pakalpojuma sniegšanā radītajiem nodevumiem, x.xx., izmaiņām un papildinājumiem Priekšmeta pirmkodā, kompilētajā kodā, dokumentācijā, testu datu kopās un citās Priekšmeta tehniskajās komponentēs un dokumentācijā, pieder Pasūtītājam un Pakalpojuma sniedzējam bez atsevišķas rakstveida piekrišanas saņemšanas no Pasūtītāja nav tiesību tās izmantot citiem (tostarp saviem) nolūkiem. Autortiesību noteikumi ietverti arī Vienošanās. |
VSP-07 | Priekšmeta izstrādes vide Pakalpojuma sniedzējam visā Vienošanās izpildes periodā uz saviem tehniskajiem resursiem ir jānodrošina izstrādes vide. |
VSP-08 | Priekšmeta komponenšu pirmkodu, kompilēto kodu un dokumentācijas repozitoriju uzturēšana Pakalpojuma sniedzējam ir jānodrošina Priekšmeta komponenšu pirmkoda, kompilēto kodu un dokumentācijas repozitoriju uzturēšana. Pirmkods, kompilētais kods un dokumentācija jānodod Pasūtītājam atbilstoši DEV-06 punkta prasībām. |
7. Priekšmeta uzturēšanas prasības
Prasības ID | Prasības apraksts |
SUP-01 | Pieteikumu veikšanas kanāli Pakalpojuma sniedzējam visā Vienošanās darbības laikā jānodrošina vismaz šādu saziņas kanālu pieejamība: • Pakalpojuma sniedzēja norādīts mobilā telefona numurs; • Pakalpojuma sniedzēja norādīta e-pasta adrese; Pasūtītājs Izpildītājam visā Vienošanās darbības laikā nodrošina piekļuvi Pasūtītāja pārvaldībā esošajai darba uzdevumu un incidentu pieteikumu informācijas sistēmai (tekstā arī – VEDUS) visu veidu pieteikumu reģistrēšanai. Pasūtītājs nodrošina ne vairāk kā 3 (trīs) piekļuves kontus VEDUS sistēmai. |
Prasības ID | Prasības apraksts |
SUP-02 | Pieteikumu veikšanas kanālu pieejamība Visā Vienošanās izpildes laikā ir jānodrošina šāda SUP-01. punktā minēto saziņas kanālu pieejamība: • Pakalpojuma sniedzēja norādītais mobilā telefona numurs Pasūtītāja darba laikā, kas fiksēts SUP-05 punktā. • Pakalpojuma sniedzēja norādītā e-pasta adrese - 24*7 Pasūtītāja pārvaldībā esošā VEDUS sistēma - atbilstoši Pasūtītāja nodrošinātajam SLA, bet nepārkāpjot 2h neplānotu pārtraukumu Pasūtītāja darba laikā. |
SUP-03 | Pieteikumu reģistrēšana un to apskates iespējamība Pieteikumi tiek reģistrēti Pasūtītāja pārvaldībā esošajā VEDUS sistēmā. Pieteikumus reģistrēt (atvērt jaunus pieteikumus) VEDUS sistēmā ir tiesības Pasūtītājam un Pakalpojuma sniedzējam. Pakalpojuma sniedzēja pienākums ir reģistrēt VEDUS visus tos pieteikumus, kurus Pasūtītājs ir pieteicis izmantojot e-pasta vai telefona saziņas kanālus un nav pats reģistrējis VEDUS sistēmā, aizpildot visu nepieciešamo informāciju. Pakalpojumu sniedzēja pienākums ir ievērot VEDUS noteikto pieteikumu darbplūsmu. |
SUP-04 | Priekšmeta iekšējo kļūdu identifikācija un apstrāde Pakalpojuma sniedzējam ir jānodrošina Priekšmeta iekšējo kļūdu identifikācija (Preventīva Priekšmeta darbības analīze) atbilstoši auditācijas pierakstos uzkrātajai informācijai un jāveic novēršana, piemērojot identiskus nosacījumus, kā apstrādājot pieteikumus, kas tiek saņemti no Pasūtītāja puses. |
SUP-05 | Saziņa ar Pasūtītāju, darba laiks Priekšmeta uzturēšanas ietvaros veicamās darbības ir īstenojamas saskaņā ar Pasūtītāja noteikto darba laiku, kas ietver šādus nosacījumus: • Pasūtītājs savu darbību veic 5 (piecas) dienas nedēļā no pirmdienas līdz piektdienai, ievērojot valstī noteiktās brīvdienas un svētku dienas, kā arī nosacījumus par darba dienu pārcelšanu; • Pasūtītāja darba dienas darba laiks ir noteikts no plkst. 8:00 līdz 17:00. |
SUP-06 | Pieteikumu novēršanas/izpildes apjoms Pakalpojuma sniedzējam Priekšmeta uzturēšanas ietvaros, par kuru tiek veikta ikmēneša maksa, ir jānodrošina: • "Kritiska kļūda (Critical)", "Augsta kļūda (High)" un "Vidēja vai zema kļūda (Intermediate vai Low)" prioritātes pieteikumu novēršana; • "Izmaiņu pieprasījums" kategorijas pieteikumu apstrāde; • "Konsultācija" kategorijas pieteikumu apstrāde. |
SUP-07 | Pieteikumu apstrādes noslēgšana Visus pieteikumus Pasūtītāja pārvaldītajā VEDUS sistēmā slēdz Pasūtītāja darbinieks. Pakalpojuma sniedzēja pienākums katrā pieteikumā ir fiksēt |
Prasības ID | Prasības apraksts |
konkrētajam pieteikumam izmantoto stundu skaitu dalījumā pa sekojošām pozīcijām: izpēte, labojumu veikšana, testēšana, piegādes sagatavošana. |
8. Pieteikumu tipi un to apstrādes prasības
Prasības ID | Prasības apraksts |
PIE-01 | Pieteikumu prioritātes un kategorijas Pakalpojumu sniegšanas ietvaros tiek noteiktas šādas pieteikumu kategorijas: • Izmaiņu pieprasījums; • Konsultācija; • Kļūda. Pakalpojumu sniegšanas ietvaros tiek noteiktas šādas kļūdu pieteikumu prioritātes: • Kritiska kļūda (Critical); • Augsta kļūda (High); • Vidēja vai zema kļūda (Intermediate vai Low). |
PIE-02 | Reakcijas laiks uz saņemtajiem pieteikumiem Reakcijas laiks "Kritiska kļūda", "Augsta kļūda" un "Vidēja vai zema kļūda" prioritātes pieteikumiem ir laiks no pieteikuma pieteikšanas brīža, izmantojot jebkuru no SUP-01 prasībā minētajiem kanāliem, līdz brīdim, kad Pakalpojumu sniedzējs ir sniedzis informāciju par to, ka uzsāk novēršanu vai atbildi par veicamajām darbībām un minētais fakts ir reģistrēts VEDUS kļūdu pieteikumu reģistrā. Reakcijas laiks "Izmaiņu pieprasījums" kategorijas pieteikumiem ir laiks, kad Pakalpojumu sniedzējs ir pieņēmis pieteikumu izpildei un sācis projektēšanu un novērtēšanu, vai uzdevis papildus nepieciešamos jautājumus projektējuma un novērtējuma veikšanai. Reakcijas laiks "Konsultācija" kategorijas pieteikumiem ir laiks, kad Pakalpojumu sniedzējs ir pieņēmis pieteikumu izpildei un sācis atbildes gatavošanu vai sniedzis atbildi uzreiz (piemēram, pieteikums izmantojot telefona zvanu kā pieteikuma kanālu). Svarīgi: Visi pieteikumi tiek pieteikti SUP-05 punktā noteiktajā Pasūtītāja darba laikā. Par pieteikumiem, kuri tiek pieteikti ārpus pasūtītāja darba laika, Puses vienojas atsevišķi. |
PIE-03 | Pieteikuma novēršanas laiks Pieteikumu "Kritiska kļūda", "Augsta kļūda" un "Vidēja vai zema kļūda" novēršanas laiks ir laiks no pieteikuma pieteikšanas brīža, izmantojot jebkuru no SUP-01 prasībā minētajiem kanāliem līdz brīdim, kad pieteikums ir atrisināts Pasūtītāja pusē un novērsti tās cēloņi vai atrasts pagaidu risinājums, vai ir apstiprināti tālākie problēmas risināšanas soļi un termiņi. |
Prasības ID | Prasības apraksts |
Pieteikumu "Izmaiņu pieprasījums" vai "Konsultācija" novēršanas laiks ir laiks līdz "Konsultācijas" sniegšanas beigām vai atbilstoši "Izmaiņu pieprasījuma" piegādei atbilstoši iepriekš nolīgtajā termiņā. | |
PIE-04 | Pieteikuma "Kritiska kļūda" nosacījumi Pieteikums ar prioritāti "Kritiska kļūda" ir incidents vai incidentu kopa, kas iniciē vienu vai vairākas no zemāk minētajām problēmām: • izraisa pilnīgu Priekšmeta vai atsevišķas funkcionalitātes nepieejamību un/vai Priekšmeta atteikumu; • izraisa vienu vai vairāku produktu pilnīgu nepieejamību konkrētā risinājuma komponentē; • kavē uzņēmuma operatīvo vai saimnieciskajai darbībai svarīgu uzdevumu veikšanu sakarā ar Priekšmeta disfunkciju; • rada drošības ievainojamības, kas apdraud Priekšmeta un datu konfidencialitāti, pieejamību un integritāti, un/vai Pasūtītāja akreditācijas statusu. • Citi traucējumi, kas rada Priekšmeta nepieejamību vai atteici virs noteiktā SLA laika Kā rezultātā – Klientiem nav pieejami Uzticamības un elektroniskās identifikācijas pakalpojums vai pakalpojumi, tiek traucēti uzņēmuma saimnieciskās darbības procesi, iestājās vai ar augtu ticamības pakāpi var iestāties finanšu zaudējumi un/vai drošības, reputācijas riski. Apdraudēta LVRTC, uzņemot saistību pret trešajām personām, noteikto pienākumu izpilde pilnā apmērā. Darba režīms Reakcija uz pieteikumu Pieteikuma novēršana 5*8 30min 4h |
PIE-05 | Pieteikuma "Augsta kļūda" nosacījumi Notikums, incidents vai incidentu kopa, kas iniciē vienu vai abas zemāk minētās darbības: • izraisa Priekšmeta vai atsevišķas funkcionalitātes kļūdu un/vai nekorektu, x.xx. neparedzētu darbību, kas rada daļēju Priekšmeta funkcionalitātes nepieejamību; • apdraud Priekšmeta un datu konfidencialitāti, pieejamību un integritāti. Kā rezultātā – Uzticamības un elektroniskās identifikācijas pakalpojumu pieejamība Klientiem un/vai parakstītājiem un/vai portāla lietotājiem ir apgrūtināta, iespējams turpināt uzņēmuma saimniecisko darbību un SP sniegšanu ierobežotā režīmā, var iestāties finanšu, drošības un/vai reputācijas riski. Darba režīms Reakcija uz pieteikumu Pieteikuma novēršana 5*8 30min 8h |
Prasības ID | Prasības apraksts |
PIE-06 | Pieteikuma "Vidēja vai zema kļūda" nosacījumi Notikums, incidents vai incidentu kopa, kas iniciē vienu vai abas zemāk minētās darbības: • izraisa Priekšmeta funkcionalitātes kļūdas vai nekorektu darbību, kas rada daļēju Priekšmeta funkcionalitātes nepieejamību. • atteikums vai incidents, kuram nav novērsts cēlonis, bet ir piegādāts apiešanas risinājums. Kā rezultātā ir apgrūtinoši turpināt uzņēmuma saimniecisko darbību un SP sniegšanu bez papildus resursiem vai darbībām. Darba režīms Reakcija uz pieteikumu Pieteikuma novēršana 8*5 2h 14 dienas |
PIE-07 | Pieteikuma "Izmaiņu pieprasījums" nosacījumi Pieteikums, kad Pasūtītājs identificējis nepieciešamību veikt izmaiņas vai papildinājumus esošajā Risinājumā, balstoties uz biznesa prasībām un/vai izmaiņām ārējos normatīvos aktos. Darba režīms Reakcija uz pieteikumu Pieteikuma novēršana 8*5 16h Atbilstoši savstarpējai vienošanai |
PIE-08 | Pieteikuma "Konsultācija" nosacījumi Pieteikums, kad Pasūtītājam ir nepieciešams saņemt Pakalpojumu sniedzēja ekspertu atbalstu sev vai Pasūtītāja klientiem, sadarbības partneriem neskaidro jautājumu risināšanai vai papildus informācijas iegūšanai par Priekšmeta funkcionālajām iespējām, x.xx., piesaistot Pakalpojumu sniedzēja ekspertus apmācību pasākumu veikšanai Pasūtītāja darbiniekiem par Xxxxxxxxxx funkcionalitāti un darbības nosacījumiem. Darba Reakcija uz pieteikumu Pieteikuma novēršana režīms 8*5 e-pasts vai pieteikumu sistēma - Atbilstoši savstarpējai 8h vienošanai telefoniski - uzreiz, vai pēc vienošanās |
PIE-09 | Pieteikumu kategoriju piešķiršana Pieteikumu kategoriju nosaka Pasūtītājs. Pakalpojumu sniedzējam, saņemot jaunu pieteikumu, ir tiesības mainīt pieteikuma kategoriju gadījumā, ja tiek konstatēts, ka pieteikums nav pieteikts atbilstoši PIE-04, PIE-05 vai PIE-06 prasībām, vai arī, kopš pieteikšanas ir mainījušies apstākļi. Pasūtītājam ir tiesības paaugstināt (eskalēt) pieteikuma prioritāti, ja pieteikuma risināšanas laikā pasliktinās situācija un tā atbilst augstākas prioritātes pieteikumam. Pasūtītājam par pieteikuma prioritātes paaugstināšanu ir jāinformē Pakalpojuma sniedzējs telefoniski. Pieteikuma prioritātes maiņai jābūt argumentētai. Pakalpojuma sniedzējs risina pieteikumu atbilstoši tā brīža noteiktajai vai mainītajai prioritātei. |
9. Izmaiņu pieprasījumu pārvaldības prasības
Prasības ID | Prasības apraksts |
IP-01 | Izmaiņu pieprasījumu apstrāde Pakalpojuma sniegšanas ietvaros Pakalpojuma sniedzējam ir jānodrošina "Izmaiņu pieprasījums" kategorijas pieteikumu apstrāde, kas tiek realizēta Pusēm atsevišķi vienojoties atbilstoši tehniskās specifikācijas IP sadaļas prasībām un apmaksāta pēc Pretendenta iesniegtās stundas likmes. |
IP-02 | Izmaiņu pieprasījumu apjoma novērtēšana Saņemot Pasūtījuma pieteikumu, Pakalpojuma sniedzējam, atbilstoši pieteikuma kategorijā noteiktajam reakcijas laikam, jāinformē Pasūtītājs par projektēšanas un novērtēšanas darba uzsākšanu (izmaiņu pieprasījums), vai arī jālūdz sniegt papildus nepieciešamā informācija. Visa komunikācija par konkrētā pieteikuma realizāciju ir jāatspoguļo VEDUS sistēmā pie konkrētā pieteikuma. Gadījumā, ja daļa komunikācijas ir notikusi telefoniski vai izmantojot e-pastu, visa informācijā ir jāfiksē VEDUS sistēmā. Izmaiņu pieprasījumu pieteikumu gadījumā Pakalpojuma sniedzējs pēc visas nepieciešamās informācijas saņemšanas, balstoties uz pieteikumā fiksēto informāciju, ne vēlāk kā 5 (piecu) darba dienu laikā sagatavo pieteikuma realizācijas novērtējumu. Nepieciešamības gadījumā, sagatavojot Izmaiņu pieprasījuma novērtējumu, Pakalpojuma sniedzējam ir tiesības pieprasīt Pasūtītājam papildus informāciju, kā arī organizēt tikšanās ar Pasūtītāju, lai iespējami precīzāk novērtētu veicamā darba apjomu. Iesniegtie Izmaiņu pieprasījumu novērtējumi ir jāiesniedz parakstīti no Pakalpojuma sniedzēja puses. |
IP-03 | Izmaiņu pieprasījuma novērtējuma saturs Katra "Izmaiņu pieprasījums" kategorijas pieteikuma novērtējums satur: • Izmaiņas augsta līmeņa projektējuma aprakstu; • Izmaiņas ieviešanas/izstrādes novērtējums cilvēkstundās; • Izmaiņas realizācijas laika periodu no pasūtīšanas brīža līdz Izmaiņas piegādei; • Izmaiņas ietekmi uz esošo vidi, ja tāda ir (piemēram nepieciešamas papildus skaitļošanas jaudas, serveri, jauni tīkla slēgumi u.t.t.). • Ietekme uz saistītajām sistēmām |
IP-04 | Izmaiņu pieprasījuma realizācijas apstiprināšana un realizācijas uzsākšana Pēc IP-03 noteikto prasību Izmaiņu pieprasījuma novērtējuma iesniegšanas, Pasūtītājs var lūgt Pakalpojuma sniedzējam sniegt papildus informāciju par novērtējumu, vai arī organizēt tikšanās ar Pakalpojuma sniedzēju, lai pieņemtu lēmumu par izmaiņu pieteikuma realizācijas apstiprināšanu vai noraidīšanu. Izmaiņu pieteikuma apstiprināšanas ietvaros Pakalpojuma sniedzējam ir tiesības precizēt un papildināt savu piedāvājumu. Izmaiņu pieteikums ir uzskatāms par apstiprinātu no Pasūtītāja puses: |
Prasības ID | Prasības apraksts |
1. Ja Izmaiņu pieprasījuma novērtējums nepārsniedz 2000 EUR, novērtējumu ir parakstījis Vienošanās norādītais biznesa virziena vadītājs vai tehniskā kontaktpersona, vīzē budžeta atbildīgais darbinieks; 2. Ja Izmaiņu pieprasījuma novērtējums pārsniedz 2000 EUR - novērtējumu ir parakstījis Vienošanās norādītais biznesa virziena vadītājs un tehniskā kontaktpersona (vai to aizvietotāji), vīzē budžeta atbildīgais darbinieks un Biznesa kontroles daļas darbinieks. 3. Ja izmaiņu pieprasījuma novērtējums pārsniedz 6000 EUR, tad starp Pasūtītāju un Pakalpojuma sniedzēju tiek noslēgts rakstveida darba uzdevums (Līgums) pie Vienošanās par tā realizāciju, kurā norādīts precīzs izmaiņu pieteikuma realizācijas apjoms (cilvēkstundās) un izpildes termiņš. | |
IP-05 | Izmaiņu pieprasījuma specificēšana un projektēšana Veicot "Izmaiņu pieprasījums" kategorijas pieteikuma realizāciju, pirms izstrādes pasākumu veikšanas Risinājumā, Pakalpojuma sniedzējs veic Pasūtītāja biznesa un tehnisko prasību detalizētu analīzi, kuras rezultātā tiek sagatavoti vismaz šādi nodevumi: • Priekšmeta arhitektūras apraksts, kas definē Priekšmeta uzbūvi pēc izmaiņu pieprasījuma ieviešanas (prasība attiecināma uz aizmugursistēmas komponentēm); • Programmatūras prasību specifikācija, kas apraksta precīzas biznesa prasības attiecīgā izmaiņu pieprasījuma ieviešanai; • Programmatūras projektējuma apraksts, kas definē attiecīgā izmaiņu pieteikuma tehnisko uzbūvi (prasība attiecināma uz aizmugursistēmas komponentēm). Attiecīgā sagatavotā dokumentācija ir jāizvieto dokumentācijas repozitorijā, kura uzturēšanu Pakalpojuma sniedzējs veic saskaņā ar VSP-08 “Priekšmeta komponenšu pirmkodu, kompilēto kodu un dokumentācijas repozitoriju uzturēšana” noteikto. Pakalpojumu sniedzējs sagatavoto dokumentāciju pievieno konkrētajam VEDUS pieteikumam, kā ietvaros izmaiņu pieprasījums tiek specificēts. Izmaiņu pieteikuma izstrādes pasākumi var tikt uzsākti tikai pēc iepriekš minētās dokumentācijas saskaņošanas no Pasūtītāja vispārīgā vienošanās noteiktās atbildīgās personas puses. Minētā dokumentācija var tikt apstiprināta jau pie Izmaiņu pieprasījuma apstiprināšanas, tādā gadījumā Izmaiņu pieprasījuma izstrāde var tikt sākta uzreiz pēc konkrētā izmaiņu pieprasījuma apstiprināšanas. |
IP-06 | Izmaiņu pieprasījuma realizācija Izmaiņu pieprasījuma realizācijas ietvaros Pakalpojuma sniedzējs nodrošina nepieciešamās programmatūras izstrādes pasākumus. Izmaiņu pieprasījuma realizāciju Pakalpojuma sniedzējs iesniedz Pasūtītājam versijas veidā, atbilstoši DEV-06 noteiktajām prasībām. |
10. Uzturēšanas pakalpojumu (tai skaitā izstrādes prasības) sniegšanas pārvaldības prasības
Prasības ID | Prasības apraksts |
MGM-01 | Priekšmeta pieejamības prasības Pasūtītājam ir jānodrošina Risinājuma patstāvīgi darbināmo komponenšu (piem. eParaksts Proxy) pieejamība (SLA) produkcijas vidē vismaz 99,9% mēnesī. SLA tiek attiecināts tikai uz neplānotiem pārtraukumiem, kas attiecas uz Pakalpojuma sniedzēja uzturētajām komponentēm. Pakalpojuma sniedzējam, veicot uzturēšanas pakalpojumu sniegšanu Vienošanās darbības laikā, jāņem vērā pieejamība (SLA), ko jānodrošina Pasūtītājam, un ar savām darbībām jāveicina Risinājuma pieejamības (SLA) rādītāju paaugstināšana. Priekšmeta pieejamības prasības ir attiecināmas uz Priekšmeta darbību tikai uz tām Priekšmeta komponentēm, kas ir Pakalpojuma sniedzēja sniegtā uzturēšanas pakalpojuma ievaros. |
MGM-02 | Esošā Priekšmeta attiecināšana uz uzturēšanas pakalpojuma sniegšanas prasībām Pakalpojuma sniedzējam trīs mēnešu laikā pēc Vienošanās noslēgšanas rakstiski jāinformē Pasūtītājs par Priekšmeta atbilstību "Uzturēšanas pakalpojumu sniegšanas pārvaldības prasībām", uzskaitot konkrētās Priekšmeta komponentes, kuras neatbilst šīm prasībām, kā arī norādot konkrētu neatbilstības prasību. Konkrētas Priekšmeta komponenšu neatbilstības šīm prasībām tiks saskaņotas un turpmāk netiks attiecinātas uz konkrēto Priekšmeta komponenti, bet to vietā tiks attiecinātas esošajā Risinājumā fiksētās prasības līdz brīdim kamēr tās tiks pilnveidotas, izmantojot "Izmaiņu pieprasījumu" kategorijas pieteikumu. Jaunām izstrādēm ir attiecināmas visas šajā (MGM) prasību blokā definētās prasības. |
MGM-03 | Bibliotēku funkcionālās prasības Java eDOC bibliotēkām uzturēšana jānodrošina visām esošajām funkcionalitātēm, galvenās no tām (visu funkciju aprakstu skatīt publiski pieejamajā bibliotēku dokumentācijā): 1. eDOC 1.0x formāta dokumentu validēšana; 2. eDOC 2.0 formāta dokumentu validēšana un parakstīšana; 3. PDF dokumentu parakstīšana un paraksta validācija; 4. Igaunijas eID, Lietuvas eID un Latvijas eID un LVRTC izsniegto viedkaršu atbalsts; 5. Parakstīšana un parakstīto dokumentu validācija, izmantojot EU Uzticamo pakalpojumu sniedzēju sarakstu1; 6. Parakstīšana izmantojot lokālo Uzticamības pakalpojumu sniedzēju sarakstu (Trusted List), visu iesaistīto sertifikātu un to atsauces datu pielietošanu2; 7. Dalītās parakstīšanas nodrošināšana un dokumentu serializācija; |
1 xxxxx://xxx-xxx.xxxxxx.xx/xxxxx-xxxxxxx/XX/XXX/?xxxxXXXXX%0X00000X0000
2 xxxxx://xxx.xxx.xxx.xx/xx/xxxxxxx-xxxxxxxx/xxxxxxxxxxxx/xxxxxxxxx-xxxxxxxx-xxxxxxxxxxx-xxxxxxxx/xxxxxxxx- sertifikacijas
8. Laika zīmogu pieprasīšanu lietotāju vai organizācijas vārdā; 9. Sertifikātu statusa datu pārvaldība (OCSP, CRL); 10. Bouncy Castle versiju neatkarība; 11. OCSP NONCE vērtību ģenerēšanas loģika; 12. rokasgrāmatas. | |
MGM-04 | eParakstītājs 3.0 funkcionālās prasības Darbvirsmas programmatūrai jānodrošina pilnvērtīga esošās funkcionalitātes uzturēšana, galvenās no tām: 1. eDOC 1.0x formāta dokumentu validēšana; 2. eDOC 2.0 formāta dokumentu validēšana un parakstīšana (ar vai bez paraksta īpašībām); 3. PDF dokumentu parakstīšana un paraksta validācija: 1. Ar un bez vizualizācijas; 2. Ar un bez paraksta īpašībām; 3. Ar un bez paraksta vizualizācijas vietas norādīšanas; 4. Ar vizualizētu attēlu. 4. Igaunijas eID, Lietuvas eID un Latvijas eID un LVRTC izsniegto viedkaršu atbalsts; 5. Parakstīšana un parakstīto dokumentu pārbaude izmantojot EU Uzticamo pakalpojumu sniedzēju sarakstu; 6. Parakstīšana izmantojot lokālo TrustList, visu iesaistīto sertifikātu un to atsauces datu pielietošanu; 7. Sertifikātu statusa datu pārvaldība (OCSP, CRL); 8. Dokumentu parakstīšanu no Operētājsistēmas failu konteksta izvēlnes (Context menu); 9. Parakstīto dokumentu sūtīšanu uz e-pasta klienta lietojumu; 10. Sertifikātu pārvaldības rīku (ieskaitot integrāciju ar eID PinTool rīku sertifikātu jaunizdošanai); 11. PIN pārvaldības rīku PIN kodu maiņai; 12. Izmantoto produktu versiju diagnosticēšana; 13. Atbalsta servisa un tā funkcionalitāšu uzturēšana; 14. “Ziņot par kļūdu” funkcionalitāte; 15. Parakstāmo dokumentu priekšskatījumu; 16. Nepieciešamie uzstādījumi: 1. Valodas; 2. Atjauninājumi; 3. Priekšskatījuma uzstādījumi; 4. Paraksta īpašību saglabāšana; 5. Proxy servisu konfigurācija; 6. Noklusētā uzstādīšana ar konfigurācijas parametriem. |
MGM-05 | Pārlūkprogrammu spraudņu funkcionālās prasības. Pārlūku spraudņiem jānodrošina pilnvērtīga esošo funkcionalitāšu uzturēšana: 1. Dokumentu kontrolsummu parakstīšana; 2. Igaunijas eID, Lietuvas eID un Latvijas eID un LVRTC izsniegto viedkaršu uzturēšana; 3. Lietotāju autentifikācijas nodrošināšana; 4. Laika zīmogošanas pieprasīšana; 5. Saistīto komponenšu nodrošināšana (JS bibliotēkas, darbstacijas komponente, pārlūka komponente); 6. Rokasgrāmatas. Priekšmeta lietojamības prasības interneta pārlūkprogrammām Visām publiski pieejamām (klientiem un sadarbības partneriem) sistēmas saskarnēm, kuras ir pieejamas izmantojot interneta pārlūkprogrammu, jānodrošina atbilstība un korekta darbība, lietojot vismaz šādas pārlūkprogrammas: • MS Internet Explorer v.11 un jaunākas versijas • Mozilla FireFox v71 un jaunākas versijas • Opera v.64 un jaunākas versijas • Google Chrome v.77 un jaunākas versijas • MS Xxxx v40 un jaunākas versijas • Safari v10 un jaunākas versijas Ne vēlāk kā 10 dienu laikā pēc jaunas pārlūkprogrammas versijas iznākšanas Pakalpojuma sniedzējam jāpiegādā jauna Priekšmeta versija, lai nodrošinātu atbilstību jaunākajai pārlūkprogrammas versijai (ja attiecīgās pārlūkprogrammas jaunās versijas darbība atstāj ietekmi uz Priekšmeta lietojamību). |
MGM-06 | Drošības nosacījumu uzturēšana Priekšmeta ietvaros Pakalpojuma sniedzējam, veicot uzturēšanas pakalpojumu sniegšanu Vienošanās darbības laikā Priekšmeta funkcionālajām daļām, kuras nav uzskatāmas par publiskām (prasība attiecināma uz aizmugursistēmas komponentēm), ir jānodrošina šādu drošības nosacījumu ievērošana: • Priekšmetam jābūt veidotam tā, lai nevarētu apiet autentifikācijas un autorizācijas procedūras un nesankcionēti lietot Priekšmeta funkcionalitāti un piekļūt datiem. Priekšmetam jāapkalpo tikai identificētus, autentificētus un autorizētus lietotājus. • Priekšmetam jānodrošina, ka programmatūra nesniedz lietotājam informāciju, kas varētu apdraudēt Priekšmeta drošību, tai skaitā, nepieļaujot iespēju lietotājam veikt analīzi par kļūdas un veikto Priekšmeta pārbaužu raksturu, kas varētu atvieglot tālākos uzbrukumus Priekšmetam. Kļūdas situācijas lietotājam jāparāda tikai minimālā nepieciešamā informācija, bet detalizēts kļūdas tehniskais apraksts jāsaglabā Priekšmeta notikumu audita žurnālā. • Priekšmeta saskarnēm jābūt izveidotām tā, lai nevarētu apiet autentifikācijas un autorizācijas procedūras un nesankcionēti lietot Priekšmeta informāciju vai datnes. • Pakalpojuma sniedzējam jānodrošina, ka Priekšmeta datu apmaiņas, kā arī citi iespējamie automatizētie datu apstrādes procesi tiek pildīti tikai ar tehnoloģisko lietotāju kontiem, kuriem funkcijas veikšanai ir noteiktas mazākās nepieciešamības tiesības mērķa sasniegšanai. Tehnoloģiskie |
lietotāji un to tiesības jādokumentē programmatūras projektējuma aprakstā atbilstoši prasībā DOC-05 noteiktajam. | |
MGM-07 | Priekšmeta identifikācijas, autentifikācijas, autorizācijas un auditācijas procedūras Priekšmeta identifikācijas, autentifikācijas, autorizācijas un auditācijas procedūrām jāizpilda šādas prasības: • Jāizmanto autorizācijas princips, saskaņā ar kuru viss, kas nav tiešā veidā atļauts, ir aizliegts; • Visām darbībām jāpārbauda autorizācija pirms darbības izpildes. Pārbaudei jānotiek katra pieprasījuma līmenī; • Jānodrošina aizsardzība pret lietotāju esamības pārbaudi (Risinājums nedrīkst atklāt vai lietotājs eksistē vai nē pirms sekmīgas autentifikācijas); • Jebkurš sekmīgs un nesekmīgs autorizācijas vai autentifikācijas mēģinājums jāreģistrē Priekšmeta notikumu audita žurnālā; • Risinājumā visām lietotāju un administratoru veiktajām darbībām jātiek identificētām (jābūt zināmām, kura persona izpilda katru darbību); • Administratoru pieeja Priekšmetam jāspēj ierobežot ar vienu vai vairākiem interneta protokola adrešu apgabaliem. Ar interneta protokola adrešu apgabalu šeit tiek saprasts IPV4 vai IPV6 adrešu intervāls. Risinājumā jāuztur pietiekami kontroles mehānismi, lai nodrošinātu, ka Priekšmeta dati gan to pārraides, gan glabāšanas laikā netiek atklāti personām vai programmām, kurām var attiecīgas autorizācijas. Piekļuve Priekšmeta datiem nodrošināma ievērojot šādus principus: • "Zina tikai tas, kuram jāzina" (need-to-know); • "Ir jānodrošina minimālās tiesības pienākumu pildīšanai" gan lietotājiem, gan tehnoloģiskajiem lietotājiem (least privilege); • Jānodrošina lietotāju darbību reģistrācija un šo datu saglabāšana (accountability). |
MGM-08 | Auditējamās aktivitātes un darbības Jānodrošina iespēja auditēt un uzglabāt audita pierakstus par jebkurām darbībām, notikumiem un aktivitātēm, tajā skaitā, bet ne tikai: • autentifikācijas mēģinājumiem (gan veiksmīgiem, gan neveiksmīgiem, ieskaitot IP adresi, datumu/laiku, pārlūkprogrammas aģentu); • datu piekļuves notikumiem (formu atvēršana, datu atlase, datu skatīšanās, mapju piekļuve); • datu izmaiņu notikumiem (datu labošana, dzēšana, pievienošana), datu labošanas aprakstā jāiekļauj vecā un jaunā informācija; • Vispārīgā datu aizsardzības regulā noteikto notikumu fiksēšanai (piemēram, fizisko personu datu apskati); • servisu sniegtajām atbildēm (OCSP, laika zīmogi, pakalpojumu piegādes moduļa atbildes); • citiem notikumiem (procesu, servisu izsaukšanu, atvienošanos no sistēmas). Auditācijas pierakstos ir viennozīmīgi un pilnīgi atsekojamas darbības - kas, kad un ko ir veicis. |
MGM-09 | Audita pierakstu uzglabāšana Vienošanās darbības laikā Pakalpojuma sniedzējam ir jānodrošina mehānisms Priekšmeta komponenšu audita pierakstu uzglabāšanai centralizētā datu bāzē, kurai datus var pievienot un nolasīt, bet nevar labot un/vai dzēst. Auditācijas pierakstiem jāvar norādīt papildus uzglabāšanas vieta, piemēram, ārējā sistēma (SIEM). • Aizmugursistēmu servera līmenī jāreģistrē vismaz šāda informācija: o Notikuma datums un laiks (Date and time); o IP adresi, no kuras pieslēdzies lietotājs (IP address); o sesijas soļa kārtas numuru (User session step number); o darbības nosaukums (Action name); o darbības parametrus (Action value). Par katra no lietotāja veiktajām darbībām jāuzglabā vismaz šāda informācija: • Darbības datums un laiks; • Lietotāja identitāte (lietotāja unikāls identifikators); • Darbības unikāls identifikators; • Darbības veids (pieslēgšanās, atslēgšanās, ierakstu pievienošana, ierakstu labošana utt.); • Darbības veidam specifiskā informācija. Audita pierakstu datiem ir jābūt indeksētiem vismaz pēc lietotāja identifikatora, IP adreses, notikuma veida un datuma un laika, lai nodrošinātu pēc iespējas ātrāku audita notikumu atlasīšanas iespēju. |
MGM-10 | Audita pierakstu arhivēšana Jānodrošina funkcionalitāte, kas ļauj administratoram uzstādīt parametrus automātiskai ierakstu arhivēšanai, saglabājot audita pierakstu integritāti un drošību pret izmaiņām. Papildus jābūt iespējai jebkurus audita pierakstus arhivēt vai eksportēt arī manuāli, x.xx. pa daļām. |
MGM-11 | Drošības nosacījumu ievērošana veicot Priekšmeta izmaiņas Veicot Priekšmeta izmaiņu pieteikumu apstrādi, par kuriem saņemti un apstiprināti pieteikumi atbilstoši 9.punkta “Pasūtījumu pārvaldības prasības” prasībām, Pakalpojuma sniedzējam ir jānodrošina šādu drošības nosacījumu ievērošana: • Priekšmeta izstrādē jāievēro OWASP ieteiktie sistēmu izstrādes principi: xxxxx://xxxx.xxxxx.xxx/xxxxx.xxx/Xxxxxxxx:Xxxxxxxxx • Interneta vides (WEB) lietojumiem sesiju pārvaldība jāorganizē pēc OWASP ieteiktajiem principiem: xxxxx://xxxxxxxxxxxxxxxx.xxxxx.xxx/xxxxxxxxxxx/Xxxxxxx_Xxxxxxxxxx_Xxx at_Sheet.html • Interneta vides (WEB) lietojumiem jāņem vērā OWASP ieteikumi AJAX tehnoloģiju izmantošanai: xxxxx://xxxx.xxxxx.xxx/xxxxx.xxx/Xxxx_xxx_Xxxxx_%00Xxxx%00_Xxxxxxxxx_ Technologies • Priekšmeta izstrādē un ekspluatācijā nedrīkst izmantot komponentes, kuras ražotājs pozicionē kā "Beta", "Pre-release", "Release candidate", "Obsolete" vai arī kādā citā veidā nerekomendē izmantošanai produkcijas sistēmās. • Priekšmeta izstrādē bez Pasūtītāja saskaņojuma nedrīkst izmantot komponentes, kurām ražotājs nepiegādā, vai tuvāko 2 (divu) gadu laikā no izstrādes uzsākšanas brīža plāno pārtraukt izstrādi un/vai piegādāt drošības labojumus. Šis izņēmums neattiecās uz komponentēm ko piegādā Pasūtītājs (piemēram viedkaršu starpprgrammatūru). |
• Risinājumā nedrīkst būt iebūvētas piekļuves, apejot autentifikācijas mehānismus, vai nedokumentēta funkcionalitāte. | |
MGM-12 | Datu pārraides kanālu aizsardzība Pakalpojuma sniedzējam jānodrošina, ka datu apmaiņa starp Priekšmeta komponentēm un citām sistēmām, kā arī starp tīmekļa serveriem un klienta pārlūku tiek veikta, izmantojot šifrētu datu pārraidi. Datu pārraides šifrēšana tiek veikta izmantojot drošus protokolus un šifrēšanas algoritmus. |
MGM-13 | Pakalpojuma sniegšanas atbilstība Latvijas Republikas normatīvajiem aktiem Pakalpojuma sniedzējam veicot Priekšmeta uzturēšanu ir jānodrošina atbilstība šādiem Latvijas Republikas normatīvajiem aktiem: • Elektronisko dokumentu likumam • Fizisko personu elektroniskās identifikācijas likumam • 2017. gada 19. septembra Ministru kabineta noteikumiem Nr. 560 "Noteikumi par kvalificēta un kvalificēta paaugstinātas drošības elektroniskās identifikācijas pakalpojuma sniedzēja un tā sniegtā pakalpojuma tehniskajām un organizatoriskajām prasībām" • 2005.gada 11.oktobra Ministru kabineta noteikumiem Nr.764 "Valsts informācijas sistēmu vispārējās tehniskās prasības"; • 2012.gada 19.jūnija Ministru kabineta noteikumiem Nr.421 "Valsts informācijas sistēmu savietotāju un integrēto valsts informācijas sistēmu aizsardzības prasības"; • 2015. gada 28. jūlija Ministru kabineta 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" • Ministru kabineta 2020.gada 14.xxxxxx noteikumi Nr. 445 “Kārtība, kādā iestādes ievieto informāciju internetā”. |
MGM-14 | Pakalpojuma sniegšanas atbilstība starptautiskiem normatīvajiem aktiem Pakalpojuma sniedzējam veicot Priekšmeta uzturēšanu ir jāseko līdzi un jānodrošina atbilstība šādiem starptautiskajiem normatīvajiem aktiem un standartiem un ar tiem saistītajiem normatīvajiem aktiem un standartiem. • Eiropas Parlamenta un Padomes 2014. gada 23. jūlija Regula (ES) Nr. 910/2014 par elektronisko identifikāciju un uzticamības pakalpojumiem elektronisko darījumu veikšanai iekšējā tirgū un ar ko atceļ Direktīvu 1999/93/EK (eIDAS regula) • Komisijas Īstenošanas lēmums (ES) 2015/1506 (2015. gada 8. septembris), kurā saskaņā ar Eiropas Parlamenta un Padomes Regulas (ES) Nr. 910/2014 par elektronisko identifikāciju un uzticamības pakalpojumiem elektronisko darījumu veikšanai iekšējā tirgū 27. panta 5. punktu un 37. pantu 5. punktu izklāstītas specifikācijas, kas attiecas uz uzlabotu elektronisko parakstu formātiem un uzlabotiem zīmogiem, kas jāatzīst publiskā sektora struktūrām • ETSI TS 119 312 “Cryptographic Suites”; • ETSI EN 319 132 part 1-2 “ESI - XAdES digital signatures”; • ETSI EN 319 162 part 1-2 “ESI - Associated Signature Containers (ASiC)”; • ETSI EN 319 102-1 “ESI - Procedures for Creation and Validation of AdES Digital Signatures” • ETSI TS 119 102-2 “ESI - Procedures for Creation and Validation of AdES Digital Signatures. Part 2: Signature Validation Report” |
• ETSI EN 319 142 part 1, 2, 3 “ESI - PAdES digital signatures. Part 1: Creation and Validation”. | |
MGM-15 | Priekšmeta drošības nepilnību novēršana Vienošanās darbības laikā Pakalpojuma sniedzējam ir jānodrošina visu identificēto drošības nepilnību novēršanu, kuras ir identificējis Pasūtītājs saviem resursiem, piemēram, atbilstoši saņemtajai informācijai no neatkarīga drošības auditora puses. Novēršot kādā Priekšmeta komponentē vai sadaļā konstatētu nepilnību, kas rada drošības riskus, jāveic arī pārējās Priekšmeta funkcionalitātes caurskatīšana un analīze ar mērķi atrast un novērst konkrētā veida nepilnību visās Priekšmeta vietās, kur tā var izpausties, kā arī jāizvērtē izmaiņu ietekme uz priekšmeta funkcionalitāti. Novēršot ievainojamību Pakalpojuma sniedzējs informē Pasūtītāju par metodēm, kādas tiek pielietotas drošības risku novēršanai vai mazināšanai. |
MGM-16 | Informācijas sniegšana par atvērtajām problēmām un aktīvajam garantijas saistībām Xxxxxxxxxxx sniedzējam ne vēlāk kā 5 darba dienas pēc Pasūtītāja pieprasījuma ir jāiesniedz Pasūtītājam šāda informācija: • pārskatu par visiem neatrisinātajiem pieteikumiem un to novēršanas paredzamajiem termiņiem; • pārskatu par Priekšmeta uzlabojumiem un papildinājumiem attiecībā uz kuriem arvien ir aktīvas garantijas saistības. Ne retāk kā reizi 6 mēnešos Izpildītājs sniedz atskaiti – pārskatu ar paveiktajiem Priekšmeta uzlabošanas priekšlikumiem, kā arī iesniedz Izpildītāja ieskatā nepieciešamos uzlabojumus vispārējas Priekšmeta veiktspējas uzlabošanai. |
MGM-17 | Priekšmeta uzraudzības mehānismu pilnveidošana Pakalpojuma sniedzējam, veicot Priekšmeta uzturēšanu, ir jāsniedz priekšlikumus Pasūtītājam par Priekšmeta vai Priekšmeta komponenšu uzraudzības mehānismu pilnveidošanu, norādot konkrētas pazīmes un to robežšķautnes, kuras vajadzētu uzraudzīt. |
11. Dokumentācijas prasības
Prasības ID | Prasības apraksts |
DOC-01 | Uzturamā dokumentācija Pakalpojuma sniedzējam visā Vienošanās darbības laikā jāuztur sekojoša dokumentācija, kuras aktuālā versija tiek pievienota katrai piegādei, uz kuru ir attiecināma konkrētā dokumentācija: • Priekšmeta arhitektūras apraksts (kur tas attiecināms); • Programmatūras prasību specifikācija; • Programmatūras projektējuma apraksts; • Priekšmeta avārijas seku novēršanas plāns (kur tas attiecināms); • Saskarņu (API) apraksti; • Priekšmeta komponenšu lietotāja rokasgrāmata; • Priekšmeta komponenšu uzturēšanas/administrēšanas rokasgrāmata; |
Prasības ID | Prasības apraksts |
• Izstrādātās programmatūras koda atkarību un kompilēšanas rokasgrāmata. | |
DOC-02 | Piegādē papildus iekļaujamā dokumentācija Pakalpojuma sniedzējam, veicot jaunas Priekšmeta komponentes sagatavošanu, konkrētai piegādājamai piegādei ir jāizstrādā vismaz šāda dokumentācija: • Piegādes uzstādīšanas rokasgrāmata; • Piegādes versijas apraksts, kas satur vismaz: o versijas identifikatoru; o versijā iekļautās izmaiņas; o aptuveno piegādes uzstādīšanas laiku, atbilstoši Pasūtītāja infrastruktūrai; o iepriekšējās versijas atjaunošanas (roll-back) plānu, ierobežojumus (kur tas attiecināms); • Piegādes izmaiņu raksturojums no drošības viedokļa – Deklarācija (Skatīt tehniskās specifikācijas pielikumu Nr. 1 – - Piegādes izmaiņu raksturojums no drošības viedokļa) |
DOC-03 | Priekšmeta arhitektūras apraksts Priekšmeta arhitektūras aprakstā ir jābūt iekļautai: • Priekšmeta loģiskajai arhitektūrai (kur tas attiecināms); • Priekšmeta komponenšu savstarpējai datu apmaiņai. |
DOC-04 | Programmatūras prasību specifikācija Programmatūras prasību specifikācijā ir jābūt iekļautam Priekšmeta komponenšu biznesa prasību aprakstam. Dokuments tiek papildināts ar katru veikto Izmaiņu pieprasījumu un strukturēts pa Priekšmeta komponentēm. Pie katras biznesa prasības tiek fiksēts Priekšmeta komponentes versijas numurs, ar kuru minētā prasība ir ieviesta. |
DOC-05 | Priekšmeta komponentes projektējuma apraksts Aizmugurservisu komponentes projektējuma aprakstam ir jāsatur vismaz šāda informācija: • Priekšmeta komponenšu procesu diagrammas atbilstoši BPMN notācijai – aprakstot sistēmas iekšējo darbību, tiek fiksēti arī datubāžu izsaukumi, sagaidāmā darbība un fiksēts pilns izpildāmais vaicājums; • UML diagrammas – aprakstot datu apmaiņu ar citām sistēmām, kur pie katras datu apmaiņas ir skaidri identificēta izmantotā datu apmaiņas metode. Gadījumos, ja tiek izmantots otras sistēmas API, tiek uzrādīts metodes nosaukums un atsauce uz konkrētās metodes API aprakstu, ja tiek izmantotas nedokumentētas datu apmaiņas metodes, tad tās tiek precīzi aprakstītas (dokumentētas); • datu bāzu un konfigurācijas parametru apraksts (kur tas attiecināms); • sistēmas uzraudzības metožu vai parametru apraksts; • Priekšmeta komponenšu tehnoloģiskie lietotāji un to tiesības. |
Prasības ID | Prasības apraksts |
Priekšmeta komponentes projektējuma aprakstā esošajai informācijai jāsakrīt ar Priekšmeta arhitektūras aprakstā fiksēto. | |
DOC-06 | Priekšmeta avārijas seku novēršanas plāns Priekšmeta avārijas seku novēršanas plānā (disaster recovery) ir jābūt aprakstītām darbībām, kā atjaunot katru Priekšmeta komponenti tās avārijas gadījumā. Prasība attiecās uz Priekšmeta sastāvdaļām, kur tas ir attiecināms (piem. eParaksts Proxy). |
DOC-07 | Saskarņu (API) apraksti Saskarņu (API) aprakstiem ir jāsatur vismaz šāda informācija: • Saskarnes servisa darbības loģikas aprakstu (piemēram, obligāta izsaukumu secība); • Pieslēgšanās nosacījumi konkrētam saskarnes servisam; • Konkrēta saskarnes servisa izmantošanas ierobežojumus, ja tādi ir; • Visu saskarnes servisa nodrošināto metožu apraksti, kur katras metodes apraksts satur vismaz: o Metodes nosaukumu; o Metodes mērķi; o Metodes aprakstu; o Pieprasījuma (request) paraugu; o Autorizācijas nosacījums; o Galvenes (header) saturu; o Pieprasījum pamata (body) saturu, norādot parametrus, to tipus un ierobežojumus; o Pilns Pieprasījuma metodes izsaukuma piemērs ar datiem; o Atbildes (response) saturu, norādot parametrus, to tipus un ierobežojumus; o Pilns atbildes piemērs ar datiem; o Potenciālās kļūdas un to skaidrojumi. Pēc saskarņu dokumentācijas Pasūtītājam, izmantojot API saskarņu apstrādei paredzētos rīkus, piemēram, Postman vai SoapUI, jāspēj pieslēgties un izsaukt visas aprakstītās metodes. |
DOC-08 | Priekšmeta komponenšu lietotāja rokasgrāmata Priekšmeta komponentēm, ar kurām darbu veic Priekšmeta gala lietotāji (piemēram eParakstītājs 3.0) ir jānodrošina lietotāja rokasgrāmata. |
DOC-09 | Priekšmeta komponenšu uzturēšanas/administrēšanas rokasgrāmata Priekšmeta komponenšu uzturēšanas/administrēšanas rokasgrāmata, kas satur vismaz sekojošu instrukciju un paskaidrojošo aprakstu apjomu: 1. Priekšmeta parametru konfigurācija, vērtību apraksts, rekomendācijas, savstarpējās atkarības un ietekme; 2. Starpsistēmu un lietotāju piekļuves rekvizītu pārvaldību (x.xx. starpsistēmas sertifikātu); 3. Automatizēto Priekšmeta procesu (x.xx. fona procesu) un to uzraudzības apraksti; 4. Priekšmeta žurnālierakstu pārvaldības un uzraudzības vadlīnijas (pareizai žurnālierakstu un tajos esošo datu konfigurācijai un operatīvas Priekšmeta darbības uzraudzīšanas veicināšanai); |
Prasības ID | Prasības apraksts |
5. Priekšmeta darbībai nepieciešamo ārējo resursu un to pielietojuma apraksts (piemēram, laika serviss); 6. Priekšmeta darbībai nepieciešamo skaitļošanas jaudu un tīkla apjoma apraksts; 7. Priekšmetam specifisku platformas un tīkla Priekšmeta konfigurācijas apraksts; 8. Priekšmeta instanču skaita palielināšanas vai samazināšanas atkarību aparaksts; 9. Priekšmeta un tā komponenšu testēšanas scenāriju apraksts, kas satur visus iespējamos testa scenārijus, kas ir veikti gan veicot jaunas funkcionalitātes testēšanu, gan konkrētu kļūdu atkārtošanām. | |
DOC-10 | Izstrādātās programmatūras koda atkarību un kompilēšanas rokasgrāmata Izstrādātās programmatūras koda atkarību un kompilēšanas rokasgrāmatai jāsatur informācija vismaz par: 1. Priekšmeta izstrādē pielietotajām tehnoloģijām (tehnoloģijas un to versijas); 2. Priekšmeta kompilēšanas vides prasībām un instrukcijām tās sagatavošanai; 3. Koda personalizācijas (atbilstošām vidēm un esošajām biznesa prasībām – piemēram, dažādu tekstu izmaiņu veikšana); 4. Koda kompilēšanas (būvēšanas) soļiem; 5. Koda parakstīšanas soļiem; 6. Publicēšanas vai uzstādīšanas soļiem. |
12. Testēšanas prasības
Prasības ID | Prasības apraksts |
TST-01 | Testēšanas pasākumu veikšana pirms piegādes veikšanas Katras versijas programmatūrai, pirms tās piegādes, Pakalpojuma sniedzējam savā vidē jānodrošina testēšana atbilstoši šādām testu klasēm: • Automātiskie regresa testi; • Funkcionālie testi; • OWASP TOP 10 pārbaude; • Integrācijas testi (kur attiecināms). |
TST-02 | Automātiskie regresa testi Automātiskajiem regresa testiem: • Pakalpojuma sniedzējam jānodrošina automātiskie regresa testi Priekšmeta komponenšu funkcionalitātei, kuru ietekmē veiktās izmaiņas, apjomā, kurš ir saskaņots ar Pasūtītāju (izņemot funkcionalitāti, kuru nodrošina izmantotā trešās puses programmatūras ražotāja programmatūra). Automātisko regresa testu saraksts un scenāriji ir saskaņojami ar Pasūtītāju pirms to realizācijas; • Regresa testi Pakalpojuma sniedzējam ir jāizpilda Priekšmeta izstrādes vidē. Automātiskie testi veidojami tā, lai tie būtu palaižami atkārtoti neierobežotu reižu skaitu no Pasūtītāja testa vides un lai tie neveicinātu testa vides datu bāzes pārpildīšanos (piemēram, paredzot testa laikā izveidoto datu dzēšanu). Regresa testu skripti jāpievieno pie katras piegādes; |
Prasības ID | Prasības apraksts |
• Regresa testu kopsavilkums jāiesniedz Pasūtītājam un tajā ir jāatspoguļo pozitīvie un negatīvie testu scenāriju rezultāti. Piezīme: Automātiskie regresa testi jāizstrādā jaunai funkcionalitātei un jaunām Priekšmeta komponentēm. Esošajās Priekšmeta komponentēs automātisko regresa testu ieviešana var tikt organizēta kā izmaiņu pieprasījums. | |
TST-03 | Funkcionālie testi Funkcionālajiem testiem jānosedz visa versijā iekļautā funkcionalitāte, atbilstoši lietotājstāstiem, lietojuma scenārijiem vai programmatūras prasību specifikācijai, ja tāda konkrētajam vienumam ir izstrādāta. Testu kopsavilkums jāiesniedz Pasūtītājam un tajā ir jāatspoguļo pozitīvie un negatīvie testu scenāriju rezultāti. |
TST-05 | OWASP TOP 10 pārbaude Pakalpojuma sniedzējam jāpārliecinās, ka piegādes nesatur OWASP TOP 10 ievainojamības. |
TST-06 | Integrācijas testi Integrācijas testi jāveic gadījumā, ja attiecīgās versijas ietvaros piegādātā Priekšmeta komponentes funkcionalitāte iespaido datu apmaiņas saskarnes ar ārējām informācijas sistēmām. |
TST-07 | Testēšanas pārskati Testēšanas pārskati, kas ir sagatavoti attiecībā uz automātiskajiem regresa testiem, funkcionālajiem testiem un integrācijas testiem (ja tādi ir veicami) ir pievienojami konkrētās Priekšmeta versijas dokumentācijas pakotnei un piegādājami Pasūtītājam. |
TST-08 | Testpiemēru scenāriju apraksts datubāze/repozitārijs Pakalpojuma sniedzējam ir jāuzkrāj visu Priekšmeta komponenšu testēšanas piemēri, scenāriji un to apraksti. Veicot konkrēta Priekšmeta komponentes jaunas versijas piegādi, Pakalpojuma sniedzējs iesniedz arī atjaunotu konkrētās komponentes testēšanas scenāriju aprakstu. |
13. Izstrādes un piegādes prasības
Prasības ID | Prasības apraksts |
DEV-01 | Priekšmeta lietojamības prasības personām ar invaliditāti Vienošanās darbības laikā Pakalpojuma sniedzējam jānodrošina, ka Risinājums atbilst standarta ETSI EN 301 549 "IKT produktu un pakalpojumu pieejamības prasības" noteiktajām prasībām, tik tālu, cik tas nepieciešams, lai nodrošinātu atbilstību eIDAS regulai un MK not.611. |
DEV-02 | Lietotāja saskarņu interneta tehnoloģijas Priekšmeta lietotāju saskarnes pusē atļauts izmantot šādas interneta tehnoloģijas: HTML, CSS, JavaScript, HTML5 paplašinājumus. Citu paplašinājumu izmantošana var tikt veikta tikai pēc rakstiska saskaņojuma ar Pasūtītāju. |
Prasības ID | Prasības apraksts |
Prasība attiecināma uz jaunām izstrādēm. | |
DEV-03 | No jauna izstrādātās Priekšmeta pielāgojumu un to funkcionalitātes lietojamības kritēriji No jauna izstrādātai (neattiecās uz trešās puses programmatūras ražotāja piegādātajiem risinājumiem) Priekšmeta pielāgojumiem un to funkcionalitātei ir jāatbilst šādiem lietojamības kritērijiem: • Priekšmeta pielāgojumam un tā funkcionalitātei ir jābūt saprotamai. Visiem lietotāja saskarnes elementiem (navigācijas elementiem, ikonām, spiedpogām, utt.) jābūt viegli uztveramiem un veidotiem atbilstoši industrijas labajai praksei. Sistēmā jāizmanto termini, kas sakrīt ar Pasūtītāja līdzšinējā ikdienas darbā izmantotajiem terminiem. • Priekšmeta pielāgojumam ir jābūt viegli apgūstamam. Lietotāja palīdzības informācijai ir jābūt pilnīgai, konteksta jūtīgai un tai jāizskaidro, kā paveikt tipiskos ikdienas uzdevumus. • Ar Priekšmeta pielāgojumu ir jābūt viegli operēt. Priekšmeta pielāgojumam jābūt veidotam vienotā stilā. Saskarnes elementiem jādarbojas viendabīgi visās Priekšmeta sadaļās. Lielākai daļai darbību jābūt atsaucamām (undo) un datu ievades kļūdām jābūt labojamām. Gadījumos, kad nav iespējas labot datus vai atgriezties pie iepriekšējā stāvokļa, jāparedz brīdinājumi pirms neatgriezeniskās darbības. • Priekšmeta pielāgojuma saskarnēm jābūt veidotām tā, lai tipiskās darbības neprasītu liekus klikšķus vai lieku pārslēgšanos starp dažādām ekrānformām. Datu ievades formām jāsatur datu validācijas kontroles. |
DEV-04 | Izstrādes prasības Veicot Priekšmeta komponenšu vai pielāgojumu izstrādi ir jānodrošina vismaz šādu prasību izpilde: • jāveic korektu, būtību izskaidrojošu koda komentēšanu; • jāizmanto mainīgos, kuru nosaukumi tiek veidoti pēc nozīmes; • jāveic strukturētu programmēšanu; • jāveic kļūdu un izņēmumu pārvaldību; • izejas kodu jānodod LVRTC pārvaldīta sadalītajai versiju kontroles sistēmai (GIT); • jādokumentē visas kompilēšanas atkarības un nosacījumus; • jādefinē izstrādē izmantotās konvencijas. Gadījumos, kad tiek veikta jaunu Priekšmeta komponenšu vai pielāgojumu izstrāde, Pakalpojuma sniedzējs ar Pasūtītāju rakstiski vienojās par izmantoto Programmēšanas valodu. Jauniem aizmugurservisiem jāizmanto ".NET Core" un "Java". |
DEV-05 | Drošības nosacījumu ievērošana, veicot jaunas Priekšmeta vai tā pielāgojuma versijas piegādi Veicot jaunu Priekšmeta vai tā pielāgojuma versijas piegādi Pakalpojuma sniedzējam ir jāveic: • pirmkodu apskate, veicot tā atbilstības izvērtēšanu, pārliecinoties, ka piegādājamā versija nesatur kādu no OWASP interneta mājas lapā uzskaitītajām visvairāk izplatītajām drošības ievainojamībām (xxxxx://xxxxx.xxx/xxx-xxxxxxx-xxx-xxx/); |
Prasības ID | Prasības apraksts |
• neizmantoto kodu fragmentu un ļaundabīga koda iespraudumu izņemšana; • ievainojamu izstrādes ietvaru (Framework) nomaiņu; • pārbaude par testēšanas nolūkiem ieviestu papildus saskarņu neesamību piegādes versijā. | |
DEV-06 | Priekšmeta komponenšu vai pielāgojumu versiju sagatavošana un piegādes veikšana Veicot Risinājumu komponenšu un vai pielāgojumu izmaiņu pieteikumu, kļūdu labojumu vai preventīvas izmaiņas Priekšmeta komponentēs un/vai pielāgojumos, Pakalpojuma sniedzējs nodrošina, ka veiktās izmaiņas Priekšmeta komponentē vai pielāgojumā tiek piegādātas kā Priekšmeta komponentes un/vai pielāgojuma versija, kas ietver: • programmatūras pirmkodu (neattiecas uz trešās puses programmatūras ražotāja programmatūru); • piegādātās programmatūras kompilēšanas instrukcija; • kompilēto kodu; • konfigurācijas skriptus; • iepriekšējās versijas atjaunošanas (roll-back) plānu un skriptus (ja tādi nepieciešami); • versijas piezīmju aprakstu; • atjaunotu Priekšmeta aprakstošo dokumentāciju, kuras apjoms ir noteikts šī dokumenta 11.punkta “Dokumentācijas prasības” noteiktajām prasībās; • elektroniski parakstīts testēšanas protokols ar faktiskajiem testu rezultātiem (atbilstoši šī dokumenta 12.punktā “Testēšanas prasības” noteiktajām prasībām); • piegādē iekļautās komponentes papildinātais testēšanas scenāriju apraksts (atbilstoši TST-08 prasībām), ja tas tiek uzturēts ārpus Priekšmeta komponentes uzturēšanas/administrēšanas rokasgrāmatas; • regresa testu skriptus (atbilstoši TST-02 prasībām); • trešās puses programmatūras ražotāja programmatūras gadījumā - ražotāja nodrošinātā programmatūra. Piegādātās programmatūras pirmkodu Pakalpojuma sniedzējs nodod LVRTC sadalītajai versiju kontroles sistēmai (GIT). |
DEV-07 | Jauno komponenšu žurnalēšanas Priekšmeta prasības 1. Pakalpojuma sniedzējam, veicot jaunu Priekšmeta komponenšu vai pielāgojumu izstrādi ir jāievēro šādi žurnalēšanas/žurnālfailu veidošanas principi: Žurnālierakstu automatizēta dublēšana/nosūtīšana uz Pasūtītāja uzturēto žurnālierakstu apstrādes rīku; 2. Žurnālierakstu formātu un saturu jāspēj konfigurēt, piemēram, izmantojot konfigurācijas parametru, kurā, pielietojot mainīgās vērtības, tiek konfigurēts žurnālierakstu formāts; 3. Žurnālierakstiem jānodrošina to integritāti aizsargājoši mehānismi; 4. Konfigurējami (laika nogrieznis, žurnālierakstu nosūtīšanas vieta, vienas reizes apjoma limits, arhivēšanas procesa ierobežošana aktīvajās stundās) žurnālierakstu automātiskas arhivēšanas mehānismi, nezaudējot to integritātes pārbaudes iespējas; Prasība attiecināma uz komponentēm kur to iespējams attiecināt. |
Prasības ID | Prasības apraksts |
DEV-08 | Priekšmeta komponenšu vai pielāgojumu piegāžu pieņemšana Pasūtītājs veic: • piegādes saturisko pārbaudi, vai piegāde satur visu DEV-06 "Priekšmeta komponenšu vai pielāgojumu versiju sagatavošana un piegādes veikšana" punktā noteikto. • piegādē iekļautās dokumentācijas aktualizācijas pārbaudi; • nepieciešamības gadījumā: o veic piegādātās programmatūras kompilēšanu savā vidē un turpmākos testus veic uz pašu kompilētās versijas; o sistēmas saskarņu izmaiņu gadījumā, pilnveido Postman un/vai SoapUI kolekciju papildināšanu atbilstoši piegādātajai dokumentācijai un veic saskarņu testēšanu izmantojot minēto programmatūru; o veic piegādātā iepriekšējās versijas atjaunošanas (roll-back) plāna testus; Priekšmeta komponentes vai pielāgojums tiek uzstādīts testa vidē, pēc sekmīgiem testiem PREP vidē un testēts tur. Pēc sekmīgiem PREP vides testiem tiek pieņemts lēmums par piegādes uzstādīšanu produkcijas vidē. Atsevišķos gadījumos Pasūtītājs var izlaist testa vides uzstādīšanas un testēšanas posmu. |
14. Sadarbības prasības
Prasības ID | Prasības apraksts |
SAD-01 | Vienošanās izpildes darba valoda Pakalpojuma sniedzējam ir jānodrošina, ka visa saziņa starp tā piesaistītajiem ekspertiem un Pasūtītāju tiek veikta latviešu valodā gan mutvārdu, gan rakstveida saziņā. Gadījumos, kad Pakalpojuma sniedzējs piesaista trešās puses programmatūras ražotāja pārstāvi, kurš nepārvalda latviešu valodu, saziņa jānodrošina angļu valodā. |
SAD-02 | Atskaišu iesniegšana par Vienošanās izpildi Pakalpojuma sniedzējam katru mēnesi ir jāsagatavo un Pasūtītājam jāiesniedz atskaite, kas kalpo arī kā attiecīgā mēneša Vienošanās izpildes pieņemšanas un nodošanas akts, kuras ietvaros ir jāsniedz vismaz šāda informācija: • Ikmēneša uzturēšanā izpildītie pieteikumi, tiek uzskaitīti VEDUS uzdevumi. • Ikmēneša uzturēšanā sniegtās konsultācijas, tiek uzskaitīti VEDUS uzdevumi. Ārpus VEDUS sistēmas veiktās darbības (konsultācijas, proaktīvi darbi), aprakstot paveikto. • VEDUS uzdevumi, par kuriem puses ir atsevišķi vienojušās IP sadaļas noteiktajā kārtībā, un par kuriem nav noslēgts atsevišķs darba uzdevums (līgums) un kas ir piegādāti un pieņemti no pasūtītāja puses iepriekšējā mēnesī; |
Prasības ID | Prasības apraksts |
• Pakalpojuma izpildē iesaistīto darbinieku saraksta izmaiņas (Jāfiksē izmaiņas, norādot kuras personas vairāk nepiedalās un kādas tiek piesaistītas. Ja izmaiņu nav, tad tā arī tiek fiksēts “Izmaiņas personālā nav”) Atskaites sagatavošana tiek veikta par laika periodu - kalendārais mēnesis. Gadījumā, ja Vienošanās noslēgšanas ietvaros pirmais Pakalpojuma sniegšanas laika periods nesakrīt ar konkrētu kalendāro mēnesi (piemēram, Vienošanās tiek noslēgts kalendārā mēneša vidū), tad pirmā atskaite tiek sniegta par nepilnu laika periodu, un atskaitē sniedzamā informācija par patērēto laika apjomu attiecībā uz izmaiņu pieteikumu apstrādi un konsultāciju sniegšanu tiek rēķināta proporcionāli faktiskajam Pakalpojuma sniegšanas periodam. Atskaiti no Pasūtītāja puses saskaņo Biznesa virziena vadītājs un Tehniskā kontaktpersona (vai to aizvietotāji). | |
SAD-03 | Informācijas sniegšana par Priekšmeta darbību Pakalpojuma sniedzējam, atbilstoši Pasūtītāja pieprasījumiem, ir jānodrošina tā rīcībā esošās informācijas sniegšana par Priekšmeta tehnisko uzbūvi, funkcionalitāti un citiem saistītajiem jautājumiem, kuri ir būtiski Pasūtītājam vai trešajām personām, piemēram, pakalpojumu sniedzējiem, kuri veic Pasūtītāja darbības vai Priekšmeta audita darbības, apkopo informāciju statistiskiem mērķiem vai realizē citus uzdevumus. Attiecīgie informācijas pieprasījumi no Pasūtītāja atbildīgās personas puses ir adresējami Pakalpojuma sniedzēja Vienošanā norādītajai atbildīgajai personai nosūtot to e-pasta saziņas veidā. |
Tehniskās specifikācijas pielikums Nr.1 (iepirkums Nr.ESP-2020/14)
Piegādes izmaiņu raksturojums no drošības viedokļa Deklarācija
1. Vispārīgi
Šo deklarāciju “Piegādes izmaiņu raksturojumu no drošības viedokļa” Pakalpojuma sniedzējs aizpilda pie katras piegādes.
Aizpildot, pakalpojuma sniedzējam ir jāatzīmē visas tās daļas, kuras raksturo ieviestās izmaiņas, lai Pasūtītājs var novērtēt potenciālos riskus un plānot saistītās darbības, ja tādas nepieciešamas.
2. Informācijas konfidencialitātes/slepenības apdraudējumu risks
Izmaiņa | Risks | Skaidrojums |
☐ | Nepastāv | 1. veikti esošās programmatūras labojumi/papildinājumi, kas neskar nedz lietotāju saskarni, nedz DB struktūru, nedz lietotāju autentifikāciju/ autorizāciju/ auditāciju. Piemēram, realizētas izmaiņas aprēķina algoritmā. |
☐ | Zems | 1. izstrādāti jauni vai veikti labojumi esošos formu logos (FL) un/ vai sarakstu logos (SL) un PPS vai projektējumā ir saskaņotas prasības piekļuves tiesībām DB tabulām un papildinājumiem/ izmaiņām auditācijas pierakstos 2. izstrādātas jaunas Web lapas (formas) vai veikti labojumi esošajās, PPS vai projektējumā ir saskaņotas prasības piekļuves tiesībām DB tabulām un papildinājumiem/ izmaiņām auditācijas pierakstos |
☐ | Vidējs | 3. izstrādāti jauni FL un/ vai SL, bet prasības piekļuves tiesībām DB tabulām un papildinājumiem/ izmaiņām auditācijas pierakstos nav saskaņotas atbilstošā PPS vai PPA 4. veiktas izmaiņas lietotāju autentifikācijas un/ vai autorizācijas un/ vai veikto darbību auditācijas mehānismā |
☐ | Augsts | 5. kardināli mainīta lietotāju saskarnes realizācija, veicot, piemēram, pāreju no ASP uz XXX.XXX 6. izstrādāts jauns lietotāju autentifikācijas un/ vai autorizācijas un/ vai veikto darbību auditācijas mehānisms 7. realizēta jauna funkcionalitāte, kas nodrošina dažāda veida failu (XML, HTML, EDOC, PDF u.c.) augšupielādi (importu) vai lejupielādi (eksportu) |
3. Informācijas (datu) integritātes apdraudējumu risks
Izmaiņa | Risks | Skaidrojums |
☐ | Nepastāv | • veikti „kosmētiski” labojumi lietotāju saskarnē vai citā funkcionalitātē, nemainot datu saglabāšanas vai atjaunināšanas komandas (procedūras). |
☐ | Zems | • piegādāts „punktveida” datu labojums. • piegādāti jaunās funkcionalitātes FL un SL, kas nekādi neietekmē nedz citu šīs IS funkcionalitāti, nedz citas IS. • ir izmaiņas esošos formas logos (FL) vai sarakstu logos (SL) ar izmaiņām datu saglabāšanas vai atjaunināšanas procedūrās. |
☐ | Vidējs | • piegādāta datu labošanas paka un tiek prognozēti vairāki simti labojumu un konkrēto informāciju tieši vai pastarpināti izmanto citas IS. • piegādāti jaunās funkcionalitātes FL un SL, kas var ietekmēt citu šīs IS funkcionalitāti vai citas IS. • veiktas būtiskas izmaiņas datu atlasē un transformācijā pirms nodošanas uz citu sistēmu, piemēram, datu noliktavu. |
☐ | Augsts | • veikti labojumi datu ievades lauku pārbaudes mehānismos un algoritmos. • tiek atslēgts vai netiek izmantots DB servera transakciju mehānisms. • veiktas būtiskas izmaiņas datu modelī un datos, kurus izmanto arī citas IS. |
4. Sistēmas/ informācijas nepieejamības risks
Izmaiņa | Risks | Skaidrojums |
☐ | Nepastāv | • izmaiņas ir nebūtiskas un to instalēšana produkcijas vidē neprasa nedz sistēmas darbināšanas pārtraukšanu, nedz lietotāju darba ierobežošanu kādā citā veidā. |
☐ | Niecīgs | • esošās funkcionalitātes izmaiņu instalēšana produkcijas vidē neprasa nedz sistēmas darbināšanas pārtraukšanu, nedz lietotāju darba ierobežošanu kādā citā veidā. • izmaiņas esošos formas logos (FL) vai sarakstu logos (SL) ar nopietnām izmaiņām datu saglabāšanas vai atjaunināšanas procedūrās. |
☐ | Zems | • piegādāta būtiski jauna funkcionalitāte, kas var ietekmēt citu šīs IS funkcionalitāti vai citas IS, taču tās instalēšanai nav nepieciešams šīs IS darbināšanas pārtraukums. • piegādāta datu labošanas paka un tiek prognozēti vairāki simti labojumu un konkrēto informāciju tieši vai pastarpināti izmanto citas IS. |
☐ | Vidējs | • izmaiņu ieviešanai produkcijas vidē ir nepieciešams darbināšanas pārtraukums (kaut vai kāda operētājsistēmas servisa pārstartēšana). • veiktas būtiskas izmaiņas sistēmas datu modelī un datos, kurus izmanto arī citas IS. • veiktas būtiskas izmaiņas saskarnēs ar citām IS. |
☐ | Augsts | • izmaiņu ieviešanai ir nepieciešams vairāku informācijas sistēmu darbināšanas pārtraukums |