IEPIRKUMA


Iepirkuma nolikuma 1.pielikums

(iepirkums Nr. ESP-2022/3)


IEPIRKUMA

eParakstītājs 3.0, bibliotēku, pārlūkprogrammu paplašinājumu un saistīto servisu uzturēšanas un izstrādes darbi

ID Nr. ESP-2022/3


PIETEIKUMS PAR PIEDALĪŠANOS IEPIRKUMĀ

(forma)


______________________ __________________

/sagatavošanas vieta/ /datums/


Pretendents _________________________________________

(nosaukums)


Vienotais reģistrācijas numurs


Juridiskā adrese


Faktiskā adrese


Tālr. Nr., e-pasts


Kontaktpersonas amats, vārds, uzvārds, e-pasta adrese un tālrunis saziņai šajā iepirkumā


Banka, kods, bankas konta numurs



tā ______________________________________________________________ personā*

ar šī piedāvājuma iesniegšanu:

  1. piesakās piedalīties iepirkumā “eParakstītājs 3.0, bibliotēku, pārlūkprogrammu paplašinājumu un saistīto servisu uzturēšanas un izstrādes darbi”, ID Nr.ESP-2022/3 un, iesniedzot piedāvājumu, piekrīt iepirkuma nolikuma prasībām;

  2. apliecina, ka piedāvājuma iesniegšanas dienā nav pasludināts Pretendenta un Pretendenta norādītā apakšuzņēmēja, kura sniedzamo pakalpojumu vērtība ir vismaz 10 (desmit) procenti no iepirkuma līguma summas, un Pretendenta norādītās personas, uz kuras iespējām pretendents balstās, maksātnespējas process (izņemot gadījumu, kad maksātnespējas procesā tiek piemērota sanācija vai cits līdzīga veida pasākumu kopums, kas vērsts uz parādnieka iespējamā bankrota novēršanu un maksātspējas atjaunošanu), nav apturēta vai pārtraukta tā saimnieciskā darbība, nav uzsākta tiesvedība par tā bankrotu vai iepirkuma līguma izpildes paredzamajam beigu termiņam tas nebūs likvidēts;

  3. apliecina, ka piedāvājuma iesniegšanas dienā Pretendentam un Pretendenta norādītajam apakšuzņēmējam, kura sniedzamo pakalpojumu vērtība ir vismaz 10 (desmit) procenti no iepirkuma līguma summas, un Pretendenta norādītajai personai, uz kuras iespējām pretendents balstās, Latvijā un valstī, kurā tas reģistrēts vai atrodas tā pastāvīgā dzīvesvieta, nav nodokļu parādi, tajā skaitā valsts sociālās apdrošināšanas iemaksu parādi, kas kopsummā katrā valstī pārsniedz 150 euro;

  4. apliecina, ka Pretendents un Pretendenta norādītais apakšuzņēmējs, kura sniedzamo pakalpojumu vērtība ir vismaz 10 (desmit) procenti no iepirkuma līguma summas, un Pretendenta norādītās personas, uz kuras iespējām pretendents balstās, nav ārzonā reģistrēta juridiskā persona vai personu apvienība;

  5. apliecina, ka Pretendentam un Pretendenta norādītajam apakšuzņēmējam, kura sniedzamo pakalpojumu vērtība ir vismaz 10 (desmit) procenti no iepirkuma līguma summas, un Pretendenta norādītajām personām, uz kuras iespējām pretendents balstās, ir atbilstošs, kvalificēts personāls iepirkuma priekšmeta izpildei;

  6. apliecina, ka Pretendentam, Pretendenta norādītajam apakšuzņēmējam, kura sniedzamo pakalpojumu vērtība ir vismaz 10 (desmit) procenti no līguma summas, un Pretendenta norādītajai personai, uz kuras iespējām pretendents balstās, nav noteiktas starptautiskās vai nacionālās sankcijas vai būtiskas finanšu un kapitāla tirgus intereses ietekmējošas Eiropas Savienības vai Ziemeļatlantijas līguma organizācijas dalībvalsts noteiktās sankcijas, kuras kavē līguma izpildi, saskaņā ar Starptautisko un Latvijas Republikas nacionālo sankciju likuma 111.pantā noteikto;

  7. apliecina, ka piedāvājums nesatur nekādas ļaunatūras (datorvīrusi, spiegprogrammatūras vai citas ļaunprātīgas programmatūras) un apņemas Pasūtītājam atlīdzināt visus zaudējumus, ja tādi Pasūtītājam rodas iesniegtajā piedāvājumā esošas ļaunatūras dēļ;

  8. iesniedzot piedāvājumu, apliecina, ka apņemas ievērot iepirkuma nolikuma noteikumus, tajā skaitā Iepirkuma līguma projekta noteikumus, un apņemas ne vēlāk kā 5 (piecu) darba dienu laikā no uzaicinājuma nosūtīšanas noslēgt Iepirkuma līgumu atbilstoši nolikumam pievienotajai redakcijai;

  9. apliecina, ka visas sniegtās ziņas ir patiesas un precīzas;

  10. apliecina, ka ir pārbaudījis Pretendenta norādīto apakšuzņēmēju, kura sniedzamo pakalpojumu vērtība ir vismaz 10 (desmit) procenti no līguma summas, un Pretendenta norādīto personu, uz kuras iespējām pretendents balstās atbilstību šī pieteikuma 3.-6.punktā minētajam. Apliecina, ka nepieciešamības gadījumā (pēc Pasūtītāja pieprasījuma) iesniegs Pasūtītājam dokumentus, kas apliecina veikto pārbaudi;

  11. apliecina, ka gadījumā, ja ar Pretendentu tiks noslēgts Iepirkuma līgums, Pretendenta rīcībā būs brīvi pieejami visi nepieciešamie resursi, kas nepieciešami Iepirkuma līguma izpildei;

  12. apliecina, ka kā patstāvīgs datu pārzinis ievēro Eiropas Parlamenta un Padomes 2016. gada 27. aprīļa regulas (ES) 2016/679 par fizisku personu aizsardzību attiecībā uz personas datu apstrādi un šādu datu brīvu apriti un ar ko atceļ direktīvu 95/46/EK (Vispārīgā datu aizsardzības regula) prasības un ir nodrošinājis tiesisko pamatu Piedāvājumā norādīto personas datu apstrādei un nodošanai Pasūtītājam, kā arī citas Vispārīgās datu aizsardzības regulas prasības attiecībā uz personas datu apstrādi un datu subjektu tiesību aizsardzību.


Piedāvājums parakstīts ar drošu elektronisko parakstu un satur laika zīmogu

_____________________________

Komercsabiedrības vadītājs vai pilnvarotās persona

Pilns vārds, uzvārds: ________________________________________________________

Amats: ___________________________________________________________________


Pieteikums ir jāparaksta uzņēmuma vadītājam vai viņa pilnvarotai personai (šādā gadījumā obligāti jāpievieno pilnvaras oriģināls vai apliecināta kopija).


PIETEIKUMS PARAKSTĪTS AR DROŠU ELEKTRONISKO PARAKSTU UN SATUR LAIKA ZĪMOGU


Iepirkuma nolikuma 2.pielikums

(iepirkums Nr. ESP-2022/3)


IEPIRKUMA

eParakstītājs 3.0, bibliotēku, pārlūkprogrammu paplašinājumu un saistīto servisu uzturēšanas un izstrādes darbi

ID Nr. ESP-2022/3




Apliecinājums par neatkarīgi izstrādātu piedāvājumu

(FORMA)


Ar šo, sniedzot izsmeļošu un patiesu informāciju, ________________________

Pretendenta nosaukums, reģ. Nr.

(turpmāk – Pretendents) attiecībā uz konkrēto iepirkuma procedūru apliecina, ka:


1. Pretendents ir iepazinies un piekrīt šī apliecinājuma saturam.

2. Pretendents apzinās savu pienākumu šajā apliecinājumā norādīt pilnīgu, izsmeļošu un patiesu informāciju.

3. Pretendents ir pilnvarojis katru personu, kuras paraksts atrodas uz iepirkuma piedāvājuma, parakstīt šo apliecinājumu Pretendenta vārdā.

4. Pretendents informē, ka (pēc vajadzības, atzīmējiet vienu no turpmāk minētajiem):

☐

4.1. ir iesniedzis piedāvājumu neatkarīgi no konkurentiem1 un bez konsultācijām, līgumiem vai vienošanām, vai cita veida saziņas ar konkurentiem;

☐

4.2. tam ir bijušas konsultācijas, līgumi, vienošanās vai cita veida saziņa ar vienu vai vairākiem konkurentiem saistībā ar šo iepirkumu, un tādēļ Pretendents šī apliecinājuma Pielikumā atklāj izsmeļošu un patiesu informāciju par to, ieskaitot konkurentu nosaukumus un šādas saziņas mērķi, raksturu un saturu.

5. Pretendentam, izņemot gadījumu, kad pretendents šādu saziņu ir paziņojis saskaņā ar šī apliecinājuma 4.2. apakšpunktu, ne ar vienu konkurentu nav bijusi saziņa attiecībā uz:

5.1. cenām;

5.2. cenas aprēķināšanas metodēm, faktoriem (apstākļiem) vai formulām;

5.3. nodomu vai lēmumu piedalīties vai nepiedalīties iepirkumā (iesniegt vai neiesniegt piedāvājumu); vai

5.4. tādu piedāvājuma iesniegšanu, kas neatbilst iepirkuma prasībām;

5.5. kvalitāti, apjomu, specifikāciju, izpildes, piegādes vai citiem nosacījumiem, kas risināmi neatkarīgi no konkurentiem, tiem produktiem vai pakalpojumiem, uz ko attiecas šis iepirkums.

6. Pretendents nav apzināti, tieši vai netieši atklājis un neatklās sava piedāvājuma noteikumus nevienam konkurentam pirms oficiālā piedāvājumu atvēršanas datuma un laika vai līguma slēgšanas tiesību piešķiršanas, vai arī tas ir īpaši atklāts saskaņā ar šī apliecinājuma 4.2. apakšpunktu.

7. Pretendents apzinās, ka Konkurences likumā ir noteikta atbildība par aizliegtām vienošanām.


(Piezīme: Pretendents atbilstoši situācijai var papildināt apliecinājuma formu ar informāciju, kas pretendentam šķiet būtiska un tā nav ietverta apliecinājuma formā).



Ar šo apstiprinām un garantējam sniegto ziņu patiesumu un precizitāti, kā arī atbilstību nolikuma prasībām.


Parakstītāja (pretendenta paraksttiesīgās personas vai pilnvarotās personas) vārds, uzvārds un amats


Dokuments parakstīts ar drošu elektronisku parakstu un satur laika zīmogu.

Parakstītāja vārds, uzvārds un amats

Datums, vieta





Pielikums

apliecinājumam par neatkarīgi izstrādātu piedāvājumu [pieteikumu]


Informācija par Pretendenta saziņu ar konkurentiem saistībā ar konkrēto iepirkumu

Nr.

Konkurents, ar kuru ir bijusi saziņa

Saziņas veids, mērķis, raksturs un saturs


[Komersanta nosaukums, reģ. Nr.]








Ar šo apstiprinām un garantējam sniegto ziņu patiesumu un precizitāti, kā arī atbilstību nolikuma prasībām.


Parakstītāja (pretendenta paraksttiesīgās personas vai pilnvarotās personas) vārds, uzvārds un amats


Dokuments parakstīts ar drošu elektronisku parakstu un satur laika zīmogu.

Parakstītāja vārds, uzvārds un amats

Datums, vieta

Iepirkuma nolikuma 3.pielikums

(iepirkums Nr. ESP-2022/3)


IEPIRKUMA

eParakstītājs 3.0, bibliotēku, pārlūkprogrammu paplašinājumu un saistīto servisu uzturēšanas un izstrādes darbi

ID Nr. ESP-2022/3


Apakšuzņēmēju saraksts

(forma)


Nr. p.k.

Apakšuzņēmēja nosaukums, reģistrācijas Nr., (personas kods un vārds, uzvārds- fiziskai personai)

Kontaktinformācija

Nododamās līguma daļas procentuālais apjoms

Apakšuzņēmējam paredzēto nododamo Līguma sadaļu (pienākumu) apraksts

Informācija par uzņēmuma statusu2

Vai balstās uz apakšuzņēmēja iespējām (jā/nē)

Ja balstās uz apakšuzņēmēja iespējām, norāda kvalifikācijas prasības punktu, kura izpildei apakšuzņēmējs piesaistīts, lai apliecinātu prasības atbilstību

A

B

C

D

E

F

G

H


























Pielikumā: tabulā noradītā apakšuzņēmēja parakstīts spēkā esošs dokuments, kas apliecina šīs personas gatavību veikt tam izpildei nodotās Iepirkuma līguma daļas (apliecināta sadarbības līguma kopija vai oriģināls vai piekrišanas raksta (apliecinājuma) oriģināls vai apliecināta kopija), ja ar pretendentu tiks noslēgts līgums.


Ar šo apstiprinām un garantējam sniegto ziņu patiesumu un precizitāti, kā arī atbilstību nolikuma prasībām.


Dokuments parakstīts ar drošu elektronisku parakstu un satur laika zīmogu.

Parakstītāja vārds, uzvārds un amats

Datums, vieta

Iepirkuma nolikuma 4.pielikums

(iepirkums Nr. ESP-2022/3)


IEPIRKUMA

eParakstītājs 3.0, bibliotēku, pārlūkprogrammu paplašinājumu un saistīto servisu uzturēšanas un izstrādes darbi

ID Nr. ESP-2022/3


Speciālistu saraksts

(forma)


Nr. p.k.

Loma līguma izpildē *

Speciālista vārds, uzvārds

Persona, kuru pārstāv**

1.




2.




3.





* Pretendents norāda līguma izpildē iesaistītos speciālistus, nodrošinot nolikuma 3.6.4.1.punktā noteikto speciālistu piesaisti.


** norāda, vai piesaistītais speciālists ir:

A - pretendenta (piegādātāja vai piegādātāju apvienības) resurss/darbinieks

B - apakšuzņēmēja vai personas, uz kuru iespējām balstās - darbinieks

C - fiziskā persona, uz kuru iespējām pretendents balstās (šajā gadījumā speciālists jāpiesaista apakšuzņēmēja statusā, vai arī piedāvājums jāiesniedz kā personu apvienībai kopā ar personu, uz kuru iespējām pretendents balstās).



Ar šo apliecinām, ka šajā pielikumā minētie speciālisti pretendenta uzvaras gadījumā tiks iesaistīti Vispārīgās vienošanās izpildē.


Puses ievēro Eiropas Parlamenta un Padomes 2016.gada 27.aprīļa regulu (ES) 2016/679 par fizisku personu aizsardzību attiecībā uz personas datu apstrādi un šādu datu brīvu apriti, tajā skaitā nolikuma 1.13.7.punktā noteikto.



Ar šo apstiprinām un garantējam sniegto ziņu patiesumu un precizitāti, kā arī atbilstību nolikuma prasībām.


Dokuments parakstīts ar drošu elektronisku parakstu un satur laika zīmogu.

Parakstītāja vārds, uzvārds un amats

Datums, vieta










Iepirkuma nolikuma 5.pielikums

(iepirkums Nr. ESP-2022/3)


IEPIRKUMA

eParakstītājs 3.0, bibliotēku, pārlūkprogrammu paplašinājumu un saistīto servisu uzturēšanas un izstrādes darbi

ID Nr. ESP-2022/3


(paraugs)


Iepirkuma līguma izpildē iesaistītā speciālista apliecinājums par gatavību piedalīties iepirkuma nolikumā noteiktā iepirkuma priekšmeta realizācijā




Ar šo es, ______________ (norāda vārdu, uzvārdu) apņemos piedalīties iepirkumā “eParakstītājs 3.0, bibliotēku, pārlūkprogrammu paplašinājumu un saistīto servisu uzturēšanas un izstrādes darbi”, iepirkuma identifikācijas numurs ESP-2022/3, (turpmāk – Iepirkums) Xxxxxxxxx līguma izpildē tādā statusā, kāds man ir paredzēts ______________ (norāda pretendenta nosaukumu) piedāvājumā, gadījumā, ja ar šo pretendentu tiks noslēgts Iepirkuma līgums.

Šī apņemšanās nav atsaucama, izņemot, ja iestājas ārkārtas apstākļi, kurus nav iespējams paredzēt Iepirkuma laikā, par kuriem apņemos informēt.





Ar šo es, ______________ (norāda vārdu, uzvārdu) esmu informēts, ka pretendents __________ (norāda pretendenta nosaukumu) norāda manus personas datus (vārds, uzvārds, paraksts, kontaktinformācija, darba pieredze un cita informācija, kas nepieciešama piedāvājuma atbilstības pārbaudei) pretendenta piedāvājumā Iepirkumam un iesniedz tos valsts akciju sabiedrībai “Latvijas Valsts radio un televīzijas centrs”. Esmu informēts, ka valsts akciju sabiedrība “Latvijas Valsts radio un televīzijas centrs” kā personas datu pārzinis, lai nodrošinātu pretendenta iesniegto piedāvājumu vērtēšanu atbilstoši ārējo normatīvo aktu prasībām, veiks manu piedāvājumā norādīto personas datu apstrādi, tajā skaitā normatīvajos aktos noteiktajos gadījumus iegūs datus no Ministru kabineta noteiktajām informācijas sistēmām vai kompetentām institūcijām.

Esmu informēts, ka papildu informācija par personas datu apstrādi, datu aizsardzību un datu subjekta tiesībām ir pieejama Pasūtītāja tīmekļa vietnē xxxxx://xxx.xxxxx.xx/xxx-xxxxx/xxxxxxxx/xxxxxxxxxx-xxxxxx/xxxxxxxxx_xxxxxxxx/)



Parakstītāja vārds, uzvārds un amats

Dokuments parakstīts ar drošu elektronisku parakstu un satur laika zīmogu.

Parakstītāja vārds, uzvārds un amats



Iepirkuma nolikuma 6.pielikums

(iepirkums Nr. ESP-2022/3)


IEPIRKUMA

eParakstītājs 3.0, bibliotēku, pārlūkprogrammu paplašinājumu un saistīto servisu uzturēšanas un izstrādes darbi

ID Nr. ESP-2022/3


Pretendenta finanšu apgrozījums

(forma)


_______ [Pretendenta nosaukums, reģistrācijas numurs] pēdējo 3 (trīs) gadu (2019., 2020., 2021.gads) vidējais gada neto apgrozījums ir vismaz EUR 50 000 (piecdesmit tūkstoši euro) gadā [Ja pretendents ir personu apvienība vai personālsabiedrība, tad šī nolikuma prasība par apgrozījumu ir jāizpilda vismaz vienam personu apvienības vai personālsabiedrības dalībniekam]:


Gads

Neto apgrozījums (EUR)

2019.


2020.


2021.


Vidēji gadā3:




Ar šo apstiprinām un garantējam sniegto ziņu patiesumu un precizitāti, kā arī atbilstību nolikuma prasībām.


Pretendenta personas ar pārstāvības tiesībām vai pilnvarotās personas paraksts

Parakstītāja vārds, uzvārds un amats

Datums, vieta




Iepirkuma nolikuma 7.pielikums

(iepirkums Nr. ESP-2022/3)


IEPIRKUMA

eParakstītājs 3.0, bibliotēku, pārlūkprogrammu paplašinājumu un saistīto servisu uzturēšanas un izstrādes darbi

ID Nr. ESP-2022/3


Pretendenta pieredzes apraksts

(forma)



N.p.k.

Pasūtītājs (nosaukums/vārds uzvārds, reģistrācijas Nr./ personas kods, kontaktinformācija (e-pasts, tālr.)

Līguma darbības termiņš (no – līdz)


Projekta nosaukums un projekta apraksts – realizētais risinājums un tā funkcionalitāte, apliecinot nolikuma 6.3.6.punkta prasību izpildi.

1.




2.




n.






Ar šo apstiprinām un garantējam sniegto ziņu patiesumu un precizitāti, kā arī atbilstību nolikuma prasībām.


Dokuments parakstīts ar drošu elektronisku parakstu un satur laika zīmogu.

Parakstītāja vārds, uzvārds un amats

Datums, vieta

Iepirkuma nolikuma 8.pielikums

(iepirkums Nr. ESP-2022/3)


IEPIRKUMA

eParakstītājs 3.0, bibliotēku, pārlūkprogrammu paplašinājumu un saistīto servisu uzturēšanas un izstrādes darbi

ID Nr. ESP-2022/3


Tehniskā specifikācija

  1. Dokumenta tvērums

    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.

    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.

    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ā.



  1. 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.



  1. 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.

  1. Priekšmeta komponenšu konceptuāla augsta līmeņa arhitektūra



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ā.

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 veikt šo starpprogrammatūru saderības pārbaudi un 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 numerācija apakšpunktos minēto ārējo servisu izmantošanai pēc Izpildītāja pieprasījuma nodrošina Pasūtītājs.

  1. 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.

  1. 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 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:

  1. 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 (24/7 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;

  2. 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 būtiskas 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:

    • 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;

    • 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.

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ā.

Ja Pakalpojuma sniedzēja pusē mainās personāls, Pakalpojuma sniedzējam, iepriekš saskaņojot to ar Pasūtītāju, jānodrošina cits speciālists. Šajā gadījumā, Pakalpojuma sniedzējam savlaicīgi par šo faktu jāinformē Pasūtītājs.

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ā.

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.



  1. 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.

 

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 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.



  1. 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.

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

24/7

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

24/7

30min

8h



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 Priekšmeta funkcionalitāti un darbības nosacījumiem.

Darba režīms

Reakcija uz pieteikumu

Pieteikuma novēršana

8*5

e-pasts vai pieteikumu sistēma – 8 darba stundu laikā.

telefoniski - uzreiz, vai pēc vienošanās

Atbilstoši savstarpējai vienošanai



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.





  1. 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:

  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.



  1. 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 xxxxxxxx0;

  6. Parakstīšana, izmantojot lokālo Uzticamības pakalpojumu sniedzēju sarakstu (Trusted List), visu iesaistīto sertifikātu un to atsauces datu pielietošanu5;

  7. Dalītās parakstīšanas nodrošināšana un dokumentu serializācija;

  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 atbalsta 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:

  • Mozilla FireFox v93 un jaunākas versijas

  • Opera v.79 un jaunākas versijas

  • Google Chrome v.95 un jaunākas versijas

  • MS Xxxx v95 un jaunākas versijas

  • MacOS Safari v15 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:

    • Notikuma datums un laiks (Date and time);

    • IP adresi, no kuras pieslēdzies lietotājs (IP address);

    • sesijas soļa kārtas numuru (User session step number);

    • darbības nosaukums (Action name);

    • 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_Xxxxx_Xxxxx.xxxx

  • 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_Xxxxxxxxxxxx

  • 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 starpprogrammatū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.jūlija 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.



  1. 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;

  • 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:

    • versijas identifikatoru;

    • versijā iekļautās izmaiņas;

    • aptuveno piegādes uzstādīšanas laiku, atbilstoši Pasūtītāja infrastruktūrai;

    • iepriekšējās versijas atjaunošanas (roll-back) plānu, ierobežojumus (kur tas attiecināms);

  • Apstiprinājums, ka ir izpildītas prasības p. DEV-05.

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.

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:

    • Metodes nosaukumu;

    • Metodes mērķi;

    • Metodes aprakstu;

    • Pieprasījuma (request) paraugu;

    • Autorizācijas nosacījums;

    • Galvenes (header) saturu;

    • Pieprasījuma pamata (body) saturu, norādot parametrus, to tipus un ierobežojumus;

    • Pilns Pieprasījuma metodes izsaukuma piemērs ar datiem;

    • Atbildes (response) saturu, norādot parametrus, to tipus un ierobežojumus;

    • Pilns atbildes piemērs ar datiem;

    • 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);

  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.



  1. 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 TOP10 risku 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;

  • 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 (pēc abpusējas vienošanās). 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 riskus xxxxx://xxxxx.xxx/xxx-xxxxxxx-xxxxxxx-xxx-xxxxxxxx-xxx-00/.

 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.



Testēšanas pārskatā pievieno apliecinājumu, ka ir pārskatīts kods un gūta pārliecība, ka tas atbilst Tehniskās specifikācijas prasībām.

 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.



  1. 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 dokumentēta saskaņojuma ar Pasūtītāju.

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;

  • jāveic ievainojamu izstrādes ietvaru (Framework) un neuzturētu bibliotēku nomaiņu.

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 jaunu 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ītajiem drošības riskiem ( xxxxx://xxxxx.xxx/xxx-xxxxxxx-xxxxxxx-xxx-xxxxxxxx-xxx-00/);

  • neizmantoto kodu fragmentu izņemšana;

  • 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 un iespējami);

  • 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;

  • Ž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;

  • Žurnālierakstiem jānodrošina to integritāti aizsargājoši mehānismi;

  • 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.

 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ā:

    • veic piegādātās programmatūras kompilēšanu savā vidē un turpmākos testus veic uz pašu kompilētās versijas;

    • 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;

    • 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. 



  1. 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;

  • 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ā.





Iepirkuma nolikuma 9.pielikums

(iepirkums Nr. ESP-2022/3)


IEPIRKUMA

eParakstītājs 3.0, bibliotēku, pārlūkprogrammu paplašinājumu un saistīto servisu uzturēšanas un izstrādes darbi

ID Nr. ESP-2022/3


Tehniskais piedāvājums

(forma)



Pretendents ___________________________ apņemas piegādāt Tehniskās

Pretendenta nosaukums

specifikācijā definētos nodevumus, izpildot šādas tehniskās prasības:


NPK

Tehniskās specifikācijas sadaļa

Nodrošina/Nenodrošina*


6. nodaļa – Vispārējās prasības (“VSP” koda prasības)



7.nodaļa – Priekšmeta uzturēšanas prasības (“SUP” koda prasības)



8.nodaļa – Pieteikumu tipi un to apstrādes prasības (“PIE” koda prasības)



9.nodaļa – Izmaiņu pieprasījumu pārvaldības prasības (“IP” koda prasības)



10.nodaļa – Uzturēšanas pakalpojumu (tai skaitā izstrādes prasības) sniegšanas pārvaldības prasības (“MGM” koda prasības)



11.nodaļa – Dokumentācijas prasības (“DOC” koda prasības)



12.nodaļa – Testēšanas prasības (“TST” koda prasības)



13.nodaļa – Izstrādes un piegādes prasības (“DEV” koda prasības)



14.nodaļa – Sadarbības prasības (“SAD” koda prasības)



Ar šo apstiprinām un garantējam sniegto ziņu patiesumu un precizitāti, kā arī atbilstību nolikuma prasībām.


Parakstītāja vārds, uzvārds un amats

Šis dokuments parakstīts ar drošu elektronisko parakstu un satur laika zīmogu.



Iepirkuma nolikuma 10.pielikums

(iepirkums Nr. ESP-2022/3)


IEPIRKUMA

eParakstītājs 3.0, bibliotēku, pārlūkprogrammu paplašinājumu un saistīto servisu uzturēšanas un izstrādes darbi

ID Nr. ESP-2022/3




Finanšu piedāvājums

(forma)


Pretendents ___________________________ apņemas sniegt Pakalpojumus par šādām cenām (cenas norādāmas euro bez pievienotās vērtības nodokļa):


N. p. k.

Pakalpojums

Cena* EUR bez PVN

1.

Fiksētā 1 (viena) mēneša maksa par uzturēšanas darbiem


2.

1 (vienas) cilvēkstundas likme par Izstrādes darbiem



*Cenā ietilpst visas ar iepirkuma priekšmetu saistītās izmaksas, tai skaitā darbaspēka izmaksas, atlaides un piemaksas, kā arī visus nodokļus (izņemot pievienotās vērtības nodokli) un nodevas, ja tādas paredzētas, kā arī visus riskus, kas iespējami ar tirgus cenu svārstībām paredzētajā Iepirkuma līguma izpildes laikā.

Ja pirmais un/vai pēdējais ir nepilns mēnesis, maksa attiecīgajā mēnesī tiek aprēķina proporcionāli Finanšu piedāvājumā noteiktajai cenai, pieņemot, ka mēnesī ir 30 (trīsdesmit) dienas.



Ar šo apstiprinām un garantējam sniegto ziņu patiesumu un precizitāti, kā arī atbilstību nolikuma prasībām.


Parakstītāja vārds, uzvārds un amats

Šis dokuments parakstīts ar drošu elektronisko parakstu un satur laika zīmogu.

1 Šī apliecinājuma kontekstā ar terminu „konkurents” apzīmē jebkuru fizisku vai juridisku personu, kura nav Pretendents un kura:

1) iesniedz piedāvājumu šim iepirkumam;

2) ņemot vērā tās kvalifikāciju, spējas vai pieredzi, kā arī piedāvātās preces vai pakalpojumus, varētu iesniegt piedāvājumu šim iepirkumam.

2 Norāda, vai atbilst mazā vai vidējā uzņēmuma statusam, ņemot vērā Iepirkumu uzraudzības biroja mājas lapā norādītās definīcijas: xxxxx://xxx.xxx.xxx.xx/xxxxx/xxx/xxxxx/xxxxxxx/Xxxxxxxxxxx%00(xx%0000.00)/xxxxxxxxxxx_xxxxxxx_xxxxxxx_xxx.xxx

3 Vismaz 50000 euro.


Document Metadata

Filed: April 6th, 2022