2.pielikumsatklāta konkursa nolikumam

“Valsts ieņēmumu dienesta Čeku spēles organizēšanas un īstenošanas pakalpojums”,

iepirkuma identifikācijas Nr. FM VID 2018/100

TEHNISKĀ SPECIFIKĀCIJAatklātam konkursam “Valsts ieņēmumu dienesta Čeku spēles organizēšanas un īstenošanas

pakalpojums”, iepirkuma identifikācijas Nr. FM VID 2018/100 (turpmāk – Konkurss)

1. Ievads1.1. Dokumenta nolūks un izmantošanaŠī dokumenta nolūks ir aprakstīt prasības Valsts ieņēmumu dienesta Čeku spēles organizēšanai un īstenošanai, nodrošinot programmatūru un aparatūru datu apstrādei, datu apmaiņai un datu uzglabāšanai (turpmāk – Pakalpojums).

Čeku spēli organizē saskaņā ar “Čeku spēles likumu”.

Čeku spēles organizēšanas un īstenošanas mērķis ir ieviest nodokļu nomaksu apliecinošu dokumentu, kas, pamatojoties uz “Čeku spēles likumu”, ir kases čeku, kvīšu un biļešu, spēle, kā pasākumu, lai veicinātu godīgu konkurenci un labprātīgu nodokļu saistību izpildi, apkarotu nodokļu krāpniecību, un mudinātu pircējus pieprasīt čekus, kvītis un biļetes par ienākumiem, kā arī veicināt godīgu konkurenci.

Tehniskā specifikācija ir Pasūtītāja sagatavots un apstiprināts dokuments, kurš ir iepirkuma dokumentācijas sastāvdaļa. Dokuments ir adresēts Pakalpojuma sniedzējiem, kuri veiks piedāvājumu sagatavošanu, un Pasūtītāja atbildīgajiem darbiniekiem, kuri piedalīsies Konkursa iepirkuma procedūrā.

1.2. Dokumenta pārskatsDokuments sastāv no trim nodaļām.

Pirmajā nodaļā ir aprakstīts šī dokumenta izstrādāšanas nolūks, aprakstīta darbības sfēra un sniegts dokumenta pārskats.

Otrajā nodaļā ir Čeku spēles vispārējais apraksts jeb izvirzītās prasībās no Valsts ieņēmumu dienesta puses.

Trešajā nodaļā ir uzskaitītas izvirzītās prasības Čeku spēles Pakalpojumam un dots vispārējo prasību apraksts.

1

2. Čeku spēles vispārējais apraksts2.1. Čeku spēles īstenošanai nepieciešamā programmatūras arhitektūraŠajā nodaļā ir attēlota un aprakstīta Čeku spēles īstenošanai nepieciešamās loģiskās arhitektūras dekompozīcija pa komponentēm.

Att.1.Vispārīgā konceptuālā arhitektūra

Att.1. lietotie apzīmējumi:VID DB – Valsts ieņēmumu dienesta datu bāzes;X DB – Pakalpojuma sniedzēja datu bāze;* – Pakalpojuma sniedzēja datu bāzes procesi, kas tiek veikti, lai noteiktu uzvarētājus (turpmāk – Uzvarētāja noteikšanas procedūra). Skat. nodaļu 2.2. WEB – Uz tīmekļa pārlūkprogrammas darbināma lietojumprogrammatūra (turpmāk – saskarne). Piekļuve saskarnei ir jānodrošina, izmantojot VID izsniegtu domēna vārdu www.cekuspele.gov.lv;Lietotājs – Čeku spēles dalībnieks (turpmāk – spēles dalībnieks);FTPS - VID (Safe File Transfer Protocol) serveris.

Att.1. atspoguļotais konceptuālais informācijas apmaiņas apraksts (Informācijas apmaiņas process):1 – ar noteiktu regularitāti tiek izveidoti faili strukturētā formātā, kas tiek novietoti uz VID FTP servera. Pakalpojuma sniedzējs šo failu lejuplādē un novieto savā datu bāzē;2 – Pakalpojuma sniedzējs nodrošina iespēju reģistrēt čekus, kvītis un biļetes saskaņā ar normatīvo aktu un šīs specifikācijas prasībām, savukārt spēles dalībnieks, izmantojot reģistrācijas formu, iesniedz nepieciešamo informāciju, kas satur 1.Tab. redzamo informāciju, kas tiek apstrādāta un uzglabāta Pakalpojuma sniedzēja datu bāzē.

2

Tab.1. Informācija, ko iesniedz spēles dalībnieksČeka gadījumā: Kvīts gadījumā: Biļetes gadījumā:1. unikālo kases aparāta,

hibrīda kases aparāta, kases sistēmas, specializētās ierīces vai iekārtas numuru;

2. čeka numuru; 3. čeka datumu; 4. čeka summu; 5. mobilā tālruņa numuru

(pieejami arī ārzemju kodi).

1. kvīts sēriju; 2. kvīts numuru; 3. darījuma apliecinošās

kvīts nodokļu maksātāja reģistrācijas kods;

4. kvīts izrakstīšanas datumu;

5. kvīts summu; 6. mobilā tālruņa numuru

(pieejami arī ārzemju kodi).

1. biļetes sēriju;2. biļetes numuru;3. biļetes nodokļu maksātāja

reģistrācijas kods;4. biļetes datumu, kas

vienāds ar pasākuma norises datumu;

5. biļetes summu;6. mobilā tālruņa numuru

(pieejami arī ārzemju kodi).

3 – Pakalpojuma sniedzējs sniedz informāciju spēles dalībniekam:a) spēles dalībniekam tiek nodrošināta iespēja izdrukāt reģistrācijas apstiprinājumu vai to nosūtīt uz spēles dalībnieka mobilo ierīci SMS veidā, norādīto elektronisko pasta adresi vai lejupielādēt spēles dalībnieka darbstacijā. Apstiprinājumā jābūt norādītiem reģistrācijas formā ievadītajiem datiem, reģistrācijas datumam un tekstam/informācijai, kā saņemt laimestu, gadījumā, ja spēlē tiks laimēts (teksts jāsaskaņo ar VID);b) gadījumā, ja spēles dalībnieks tiek atlasīts Uzvarētāja noteikšanas procedūras rezultātā, par to spēles dalībniekam tiek paziņots automātiski SMS veidā;

4 – Pakalpojuma sniedzējs ar VID iepriekš saskaņotā strukturētā veidā izveido failu, kas satur visu Pakalpojuma sniedzēja datu bāzē pieejamo informāciju par visiem reģistrētajiem čekiem un kvītīm, un to augšupielādē uz VID FTP servera. VID nosaka datu nodošanas regularitāti, kā arī to vai dati tiek nodoti pilnībā, vai arī izmaiņu režīmā. Pakalpojuma sniedzēja uzdevums ir uzglabāt Čeku spēles laikā iegūtos datus tik ilgi līdz visi dati ir nodoti VID. Čeku spēles laikā iegūtie dati ir ierobežotas pieejamības un izmantojami tikai spēlei nepieciešamo procedūru veikšanai.

3

2.2. Uzvarētāju noteikšanas procedūra

Att.2. Uzvarētāja noteikšanas procedūraUzvarētāja noteikšanas procedūra (skat.Att.2.) sastāv no sekojošiem soļiem, kas tiek izpildīti secīgi pie iepriekšējā soļa izpildes pozitīva rezultāta (gadījumā, ja soļa izpildes rezultāts ir negatīvs, attiecīgais čeks, kvīts vai biļete tiek izslēgts no tālākās apstrādes un dalības Čeku spēlē):1) Summas pārbaude - tiek pārbaudīta iesniegtā čeka vai darījumu apliecinošās kvītis summa, kurai jāsastāda 5 EUR bez PVN (atbilstoši PVN likmei, kas ir spēkā čeka izsniegšanas datumā);2) Derīguma pārbaude - tiek pārbaudīts čeka vai biļetes derīgums pret dalībnieka iesniegtajiem datiem pēc VID noteiktajiem validācijas principiem kas satur 2.Tab. redzamo informāciju;

Tab.2.Derīguma pārbaudes validējamo datu pārbaude Dalībnieka sniegtā informācija VID sniegtie dati

Čeka gadījumā:Šasijas numurs Pārbaude pret Šasijas numursŠasijas numurs Pārbaude pret Attiecīgā kases aparāta šasijas

numuram atbilstošā nodokļu maksātāja NACE kods

Kvīts gadījumā:Kvīts sērijas numurs Pārbaude pret Kvīts sērijas numurs

Biļetes gadījumā:Biļetes sērijas numurs Pārbaude pret Biļetes sērijas numursBiļetes nodokļu maksātāja reģistrācijas kods (tikai juridiskām personām)

Pārbaude pret Biļetes nodokļu maksātāja reģistrācijas kods (tikai juridiskām personām)

Visos gadījumos:Datums Pārbaude pret Spēles norises periods

3) Proporciju sadale - iesniegtie čeki tiek sadalīti proporcijā 70:30 saskaņā ar Pakalpojuma sniedzēja datu bāzē novietotajiem datiem par EKA lietotāja aktuālais paziņotais pamatdarbības veidu, proti, izlozei iesniegtie čeki, kas izsniegtas par Latvijas Republikas teritorijā sniegtajiem pakalpojumiem tiek iedalītas koeficientā 70 %, savukārt iesniegtie čeki, kas izsniegtas par

4

precēm, kas iegādātas publiskajās tirdzniecības vietās Latvijas Republikā tiek iedalīti koeficientā 30%. Gadījumā ja pamatdarbības veids nav zināms, iesniegtais čeks tiek iedalīts koeficientā 70%. Visas iesniegtās darījumu apliecinošās kvītis un biļetes tiek iedalītas koeficientā 70%;4) Ģeneratora darbināšana - tiek darbināts gadījuma skaitļu ģenerators, proti, Pakalpojuma sniedzēja izstrādātā programmatūra, kas ģenerē skaitļus un to secību pēc nejaušības principa, ko izmanto čeku spēles uzvarētāju noteikšanai;5) Informācijas par uzvarētājiem izsūtīšana – dati par uzvarētājiem, kas sevī ietver uzvarētāja tālruņa numura pēdējos četrus ciparus, uzvarējušā čeka numuru un datumu tiek nosūtīta sekojoši:

a) VID tiek nosūtīti automatizēta e-pasta veidā nākamajā dienā pēc attiecīgās izlozes noslēgšanas dienas līdz plkst.06:00, ja VID nav noteicis citādāk:b) tiek publicēti Čeku spēles interneta vietnē www.cekuspele.gov.lv, atbilstoši 2.2.1.punktā noteiktajam;c) secīgi Pakalpojuma sniedzējs nodrošina, ka informācija par laimestu tiek nosūtīta uz spēles dalībnieka mobilo ierīci SMS (Short Message Service) veidā. Attiecīgi teksts, kas tiks nosūtīts kopā ar uzvarējušā čeka, kvīts vai biļetes aizpildes formā ievadītajiem datiem (neskaitot mobilā tālruņa numuru) uzvarētājiem ir iepriekš saskaņots ar VID.

Procedūru jāizstrādā un jānodrošina Pakalpojuma sniedzējam, izmantojot savus resursus.

2.2.1. Uzvarētāju noteikšanas procedūras pamatnostādnesUzvarējušā čeka, kvīts vai biļetes noteikšanu visos laikos nodrošina Pakalpojuma sniedzējs. Pakalpojuma sniedzējs nodrošina godprātīgu un neatkarīgu uzvarētāju noteikšanu izmantojot 2.2.punktā aprakstīto Uzvarētāju noteikšanas procedūru. Čeku spēle sastāv no divām daļām – nedēļas un mēneša čeku spēles izlozes. Nedēļas izlozei reģistrējamo čeku, kvīšu un biļešu datums sakrīt ar konkrētās nedēļas izlozes laiku, bet mēneša izlozei – ar konkrētā mēneša spēles mēnesi:

2.2.1.1. Nedēļas čeku spēle sākas katru nedēļu pirmdien plkst. 00.00 un beidzas tās pašas nedēļas svētdienā plkst. 23.59. Čeku vai kvīti attiecīgās nedēļas čeku spēlei reģistrē līdz nākamās nedēļas pirmdienas plkst. 23.59. Šīs čeku spēles laikā jānosaka “n” skaits uzvarētāju. Nedēļas izložu uzvarētājus nosaka katrā nākamās nedēļas otrdienā;

2.2.1.2. Mēneša čeku spēle sākas katra mēneša pirmajā datumā plkst. 00.00 un beidzas mēneša pēdējā datumā plkst. 23.59. Čeku vai kvīti attiecīgās mēneša spēlei reģistrē līdz nākamā mēneša pirmā datuma plkst. 23.59. Šīs čeku spēles laikā jānosaka “n” skaits uzvarētāju. Mēneša izložu uzvarētājus nosaka katra nākamā mēneša otrajā otrdienā;

2.2.1.3. Informāciju par nedēļas izlozē laimējušiem čekiem paziņo katru nedēļu otrdienā pēc attiecīgās nedēļas izlozes, bet mēneša spēlē – katra nākamā mēneša otrās nedēļas otrdienā.

Pakalpojuma sniedzējam jānodrošina, ka vienu čeku, kvīti vai biļeti var reģistrēt spēlei tikai vienu reizi, ar nosacījumu, ka visi čeki, kvītis un biļetes, kas reģistrēti attiecīgajā mēnesī piedalās mēneša spēlē neatkarīgi no tā, vai čeks, kvīts vai biļete jau ir uzvarējis attiecīgā mēneša nedēļā.

2.3. Prasības Pakalpojuma sniedzēja mājaslapas programmatūrai2.3.1. Pakalpojuma sniedzējam jānodrošina piekļuvi saskarnei ar VID sniegto domēna vārdu - www.cekuspele.gov.lv - ar funkcionalitāti, kas pielāgota spēles dalībniekiem. 2.3.2.Spēles dalībnieku lietotāju saskarnei ir jābūt pieejamai valsts valodā. Saskarnes dizainu izstrādā atbilstoši VID iesniegtajai grafiskajai identitātei.2.3.3.Pakalpojuma sniedzēja programmatūrai pēc veiksmīgas akcepttestēšanas un pirms Pakalpojuma sniegšanas uzsākšanas ir jābūt veiktam neatkarīgam drošības un veiktspējas auditam, kas pārbauda Pakalpojuma atbilstību tehniskajā specifikācijā norādītajām drošības un

5

veiktspējas prasībām. Auditu pasūta un apmaksā Pakalpojuma sniedzējs. Audita ziņojums ir jāiesniedz VID pēc veiksmīgas akcepttestēšanas, bet ne vēlāk kā līdz 2019.gada 31.maijam.2.3.4.Pakalpojuma sniedzējam ir jānodrošina, lai saskarne un tai paredzētās funkcionalitātes darbotos interneta pārlūkos Google Chrome, Internet Explorer, Mozila Firefox, Microsoft Edge, Safari (t.sk. to mobilajās versijās), kuru versijām tiek nodrošināts ražotāja atbalsts. Mājaslapai jāspēj pielāgoties visa izmēra ierīču ekrāniem (angļu valodā Responsive Design).2.3.5. Pakalpojuma veiktspējas prasības2.3.5.1. Sistēmas uzturēšanas pakalpojuma ietvaros Pakalpojuma sniedzējam nepieciešams nodrošināt augstu sistēmas pieejamību lietotājiem un tādu arhitektūras kvalitāti, lai sistēmas darbība ir stabila. Sistēmas darbības pārtraukumi kopumā (gan plānotie, gan neplānotie) nedrīkst pārsniegt 12 (divpadsmit) stundas mēneša laikā. 2.3.5.2. Pakalpojuma sniedzējam jānodrošina stabila saskarnes darbība pie vidēji 2000 vienlaicīgiem lietotājiem. Lietotāju darbību veikšana nedrīkst ilgt vairāk par 3 sekundēm. Saskarnei jānodrošina augsta pieejamība (24x7) lietotājiem un tās darbībai ir jābūt stabilai.

2.4. Spēles dalībnieka saskarnes funkcionālās prasības2.4.1. Spēles dalībnieka saskarnei jābūt pieejamām četrām cilmēm, kuras var tikt mainītas vietām/dzēstas pēc VID lūguma. Pārslēdzoties starp cilmēm reģistrācijas formā ievadītā informācija jāsaglabā.

2.4.2. Pirmajā cilmē, blakus reģistrācijas formās, jābūt pieejamai automatizētai informatīvās palīdzības funkcijai lietotājam, kas aizpilda kvīts vai kases aparāta, hibrīda kases aparāta, kases sistēmas, specializētās ierīces vai iekārtas čeku, kā arī biļešu reģistrācijas formas. Informatīvajai palīdzībai jābūt pieejamai laukā pie reģistrācijas veidlapas, ko aizpilda lietotājs. Tāpat blakus reģistrācijas formai jābūt redzamiem paraugiem, kuros uzskatāmi norādīts, kāda informācija jāievada. Pirmajā cilmē ir arī paredzēta iespēja iepazīties ar Čeku spēles nosacījumiem atbilstoši Čeku spēles likumā minētajam (uznirstošs logs vai saite uz trešo cilmi).

2.4.3. Otrajā cilmē kopā ar jaunākajiem datiem par uzvarētājiem, kas sevī ietver uzvarētāja tālruņa numura pēdējos četrus ciparus, uzvarējušā čeka numuru un datumu, tiek atspoguļoti arī vēsturiskie izložu dati, kuri var būt pieejami arhīva veidā. VID ir iespēja noteikt cik ilgs periods tiek uzglabāts spēles dalībniekiem pieejamā veidā, kā arī to cik ilgi tiek atspoguļota informācija saraksta veidā, pirms tā tiek pārcelta uz arhīvu.

2.4.4. Trešajā cilmē jābūt pieejamiem Čeku spēles nosacījumiem.

2.4.5. Ceturtajā cilmē jābūt pieejamai palīdzībai ar biežāk uzdotajiem jautājumiem. Cilme Pakalpojuma sniegšanas laikā var tikt papildināta ar VID vai Pakalpojuma sniedzēja sagatavotām atbildēm uz jautājumiem, kā arī papildus, informāciju pēc nepieciešamības.

2.4.6. Reģistrācijas formā pieejamie lauki tiek noteikti atbilstoši Tab.1. noteiktajai informācijai, t.i., spēles dalībniekam ir iespēja izvēlēties vai tiek ievadīta informācija par čeku, kvīti vai biļeti. Attiecīgi visiem datu ievadīšanas laukiem visos gadījumos ir jābūt obligātiem.

2.4.7. Visiem formā ievadītajiem datiem ir jānodrošina validācija, kā arī jānodrošina programmatūras aizsardzība pret pakalpojuma atteices uzbrukumiem, piemēram, cilvēktests jeb CAPTCHA, kas tiek izdots pie konkrēta skaita formas aizpildīšanas reizēm minūtē un ir maināms pēc VID pieprasījuma. Pie validācijas saskarnes ietvaros ir jānodrošina, ka vienu čeku, kvīti vai biļeti var iesniegt tikai vienu reizi, nosakot pārbaudi, kas iepriekš saskaņota ar VID, pēc attiecīgā darījumu apliecinošā dokumenta veida. Nedēļas izlozei reģistrējamo čeku, kvīšu un

6

biļešu datumam jāsakrīt ar konkrētās nedēļas izlozes laiku, bet mēneša izlozei – ar konkrētā mēneša spēles mēnesi. Papildus jānodrošina lauku formāta validācija.

2.4.8. Pakalpojuma sniedzējam jānodrošina kļūdas paziņojuma attēlošana, ja spēles dalībnieks ir ievadījis nekorektu informāciju, atkārtoti mēģina ievadīt čeka datus vai nav ievadījis obligāto informāciju.

2.4.9. Pirms čeka, kvīts vai biļetes reģistrācijas Pakalpojuma sniedzējam ir jānodrošina uznirstošs logs, kurā tiek atspoguļoti Čeku spēles likuma nosacījumi un spēles dalībniekam ir jāapliecina:

1) ka tas ir iepazinies un piekrīt Čeku spēles likuma nosacījumiem;2) ka nav VID darbinieks vai amatpersona.

2.4.10. Pakalpojuma sniedzējam jānodrošina spēles dalībnieka informēšana par veiksmīgu čeku reģistrāciju spēlei (uznirstošs logs mājaslapā ar informatīvu paziņojumu par veiksmīgi reģistrētu čeku spēlei). Spēles dalībniekam jābūt nodrošinātai iespējai izdrukāt reģistrācijas apstiprinājumu vai to nosūtīt uz spēles dalībnieka mobilo ierīci, norādīto elektronisko pasta adresi vai lejupielādēt spēles dalībnieka darbstacijā. Apstiprinājumā jābūt norādītiem reģistrācijas formā ievadītajiem datiem, reģistrācijas datumam un tekstam, informācijai, kā saņemt laimestu, gadījumā, ja spēlē tiks laimēts (teksts jāsaskaņo ar VID).

2.4.11. Pakalpojumu sniedzējs reģistrētajiem čekiem un kvītīm automātiski piešķir unikālu identifikācijas numuru, ko secīgi izmanto uzvarējušā čeka, kvīts vai biļetes identificēšanai atbilstoši Uzvarētāja noteikšanas procedūrai.

3. Prasības Pakalpojumam3.1. Prasības Pakalpojuma pārvaldībai

(001) Izstrādes, testa vides nodrošināšana (Obligāta)

Pakalpojuma sniedzējam ir jānodrošina sava izstrādes un testēšanas vide (aparatūra, programmatūra, biroja telpas) līguma ietvaros izpildāmo darbu un uzdevumu veikšanai. Pakalpojuma sniedzējam izstrāde un testēšana jāveic, izmantojot tikai licencētu programmatūru. Pasūtītājs nenodrošina Pakalpojuma sniedzēju ar licencēm. Pakalpojuma sniedzējam jānodrošina attālinātu piekļuvi VID amatpersonām/darbiniekiem savai testēšanas videi.

(002) Pakalpojumā izmantojamā valoda (Obligāta)Nodevums - Pakalpojuma sniedzējam visā Pakalpojuma sniegšanas laikā jebkurš Pakalpojuma sniedzēja darba rezultāts, kuru akceptē VID. Nodevumi jānoformē latviešu valodā un komunikācija ar Pasūtītāju jānodrošina tikai latviešu valodā. Ja tiks piesaistīti speciālisti, kuri nepārvalda latviešu valodu, Pakalpojuma sniedzējam šo speciālistu saziņā ar Pasūtītāju jānodrošina tulkošana bez papildu maksas. Rakstiskajā komunikācijā nav pieļaujama tikai automātisko tulkošanas rīku (piemēram: Google Translate) izmantošana.

(003) Pakalpojuma problēmu vadība (Obligāta)Pakalpojuma sniedzējam ir jāidentificē Pakalpojuma problēmas un savlaicīgi jāziņo par tām Pasūtītājam, kopēji ar Pasūtītāju nosakot nepieciešamās korektīvās darbības un kontrolējot to izpildes efektivitāti.

7

(004) Pakalpojuma risku vadība (Obligāta)Pakalpojuma sniedzējam visā Pakalpojuma sniegšanas laikā ir jāveic Pakalpojuma risku identificēšana, analīze, novērtēšana, uzraudzība un kontrole, risku mazināšanas un/vai novēršanas darbu plānošana un īstenošana.Pakalpojuma sniedzējam tehniskajā piedāvājumā ir jāapraksta pakalpojuma sākotnējo risku novērtējums, kā arī pieņēmumi, atkarības un ārējās ietekmes, kas tika ņemtas vērā, sagatavojot piedāvājumu.

(005) Darbietilpības novērtēšanai izmantotās Izstrādātāja metodes (Obligāta)Izstrādātājam jāizmanto vismaz viena formālā metode, balstoties uz COCOMO – Constructive Cost Model, vai ekvivalents, un vismaz viena neformālā metode.

(006) Speciālistu savstarpējās sadarbības un komunikācijas shēma (Obligāta)Pakalpojuma sniedzējam jānodrošina efektīva Pakalpojuma sniedzēja speciālistu komunikācija ar Pasūtītāja speciālistiem. Pakalpojuma sniedzējam jāiesniedz shēma, kurā attēlota Pakalpojuma sniedzēja speciālistu komunikācija ar Pasūtītāja speciālistiem. Pakalpojuma sniedzējam jāapraksta piedāvāto speciālistu komandas stiprās un vājās puses.

(007) Kvalitātes vadība (Obligāta)Pakalpojuma sniedzējam pakalpojuma laikā ir jānodrošina kvalitātes pārvaldības procesi, kas nodrošinātu prasībām atbilstoša programmprodukta uzturēšanu un pilnveidošanu.

(008) Kvalitātes kontrole un verifikācija (Obligāta)Visā līguma darbības laikā Pakalpojuma sniedzējam ir jāveic dokumentācijas un programmkoda kvalitātes kontrole, jānodrošina preventīvās un korektīvās darbības, kā arī jāuztur pieraksti par dokumentācijas un programmkoda verifikāciju pirms tā nodošanas Pasūtītājam. Pēc Pasūtītāja pieprasījuma Pakalpojuma sniedzējam ir jānodrošina iespēja Pasūtītājam iepazīties ar dokumentācijas un programmkoda verifikācijas pierakstiem.

3.2. Vispārējās prasības Pakalpojumam

(009) Pakalpojuma vispārīgā atbilstība (Obligāta)Pakalpojuma sniedzējam ir jāveic darbi Pakalpojuma nodrošināšanai, tajā skaitā, jāuztur programmatūra un jāpiegādā dokumentācijas saskaņā ar šīs specifikācijas prasībām, iepirkuma nosacījumiem, Latvijas Republikas normatīvo aktu un Eiropas Komisijas regulu prasībām, Latvijas Republikas un starptautiskajiem programmatūras izstrādes standartiem.

(010) Pakalpojuma atbilstība standartiem (Obligāti)Pakalpojuma sniedzējam ir jānodrošina nodevumu atbilstība šādiem standartiem:

Pakalpojuma sastāvdaļa

Atbilstība Paskaidrojums

Projekta plānošanas dokumenti

Projekta pārvaldības plāns

LVS 67:1996 Projekta pārvaldības plāns apraksta projekta tehniskās un pārvaldības funkcijas, pasākumus un uzdevumus, kas nepieciešami, lai apmierinātu Projekta līgumā noteiktās prasības.

Kvalitātes nodrošināšanas plāns

LVS 65:1996 Kvalitātes nodrošināšanas plāns apraksta visu plānoto un sistemātisko darbību shēmu, ko paredzēts veikt Projekta attīstības gaitā, lai radītu pārliecību, ka dokumentācija un/vai programmatūras produkts atbilst 8

Pakalpojuma sastāvdaļa

Atbilstība Paskaidrojums

iepriekš noteiktajām prasībām.

Programmatūras (kvalifikācijas) testēšanas plāns

LVS 70:1996; IEEE/EIA J-STD-016 (E.2.2.)

Programmatūras testēšanas plānā jādod Projekta laikā veicamo testēšanas pasākumu plāns, kā arī jāapraksta šo pasākumu darbības sfēra, izvēlētā pieeja, resursi u.c. Jāidentificē testējamie vienumi, raksturiezīmes, kuras jātestē, testēšanas uzdevumi, kas jāizpilda, un risks, kurš ir saistīts ar plānu.

Programmatūras verifikācijas un validācijas plāns

LVS 71:1996 Programmatūras verifikācijas un validācijas plāns apraksta visus plānotos verifikācijas un validācijas pasākumus, kurus paredzēts veikt Projekta attīstības gaitā.

Programmatūras pārcelšanas plāns

IEEE/EIA J-STD-016 (E.2.4)

Programmatūras pārcelšanas (transition) plāns apraksta programmatūras lietošanas vietā nepieciešamo aparatūru un programmatūru, kā arī apraksta procedūru, kā programmatūra tiek nodota lietošanai.

Projekta specifikācijas

Sistēmas lietotāju prasības

LVS 72:1996;IEEE/EIA J-STD-016 (F.2.2)

Sistēmas lietotāju prasības ir pakalpojumi, kas sistēmai jāsniedz tās lietotājam, un otrādi, tās parāda to, ko sistēmas lietotājs var darīt ar sistēmu savu mērķu un uzdevumu realizācijai. Sistēmas lietotāju prasības akcentē sadarbību „sistēma-lietotājs” un definē sistēmas un lietotāja veicamās darbības. Sistēmas lietotāju prasība savā veidā atbilst vienkāršam biznesa procesam, jeb biznesa procesa kādai aktivitātei, kuras izpildē, kā atbalsta līdzeklis ir izmantota sistēma (sistēmas attiecīgā funkcija).

Programmatūras prasību specifikācija

LVS 68:1996;

IEEE/EIA J-STD-016 (F.2.2., F.2.4.)

Programmatūras prasību specifikācijā tiek aprakstītas detalizētas prasības katram programmatūras vienumam un tas ir galvenais dokuments, atbilstībā pret kuru tiek veikta programmatūras testēšana.

Sistēmas darbības koncepcijas apraksts

LVS 75:1996;

IEEE/EIA J-STD-016 (F.2.1)

Sistēmas darbības koncepcijas apraksta pamatuzdevums ir dot problēmas formulējumu, apkopot sākotnējās situācijas analīzes rezultātus un aprakstīt sistēmas darbību saistībā ar tās funkcionēšanas vidi. Balstoties uz esošās situācijas analīzi, koncepcijas aprakstā jāpamato jaunās izstrādes vai esošās programmatūras modificēšanas nepieciešamība.

Saskarņu prasību specifikācija

LVS 72:1996; EIA/IEEE J-STD-016 (F.2.3.)

Saskarņu prasību specifikācijā jāapraksta prasības, kas tiek izvirzītas sistēmai, apakšsistēmām, aparatūrai, programmatūrai, lietotāja izdarītajām darbībām vai citām sistēmas komponentēm, lai īstenotu prasīto sadarbību starp šīm komponentēm

Projektējumu dokumentācija

Sistēmas/apakšsistēmas projektējuma apraksts

LVS 72:1996; IEEE/EIA J-STD-016

Sistēmas/apakšsistēmas projektējuma apraksts atspoguļo sistēmas projektējumu un arhitektūru.

9

Pakalpojuma sastāvdaļa

Atbilstība Paskaidrojums

(G.2.1.)

Programmatūras projektējuma apraksts (PPA), ieskaitot saskarņu projektējuma aprakstu un datu bāzu projektējuma aprakstu

LVS 72:1996;

IEEE/EIA J-STD-016 (G.2.2., G.2.3., G.2.4.)

PPA jāietver gan sistēmas programmatūras, gan saskarņu, gan datu bāzu projektējuma aprakstu. PPA pārbauda atbilstībā pret prasību specifikāciju.

PPA jāapraksta gan loģiskais, gan fiziskais sistēmas programmatūras projektējums. Loģiskajā projektējumā ir jābūt aprakstītiem visiem programmatūras vienumiem, to nozīmei, funkcionalitātei un savstarpējai mijiedarbībai. Fiziskajā projektējumā detalizē, kā plānotā programmatūras funkcionalitāte un citas prasību specifikācijā ietvertās prasības tiks realizētas.

Saskarņu projektējuma aprakstā jāapraksta sistēmu, apakšsistēmu, aparatūras, programmatūras, lietotāja iedarbību un citu sistēmas komponentu savstarpējā sadarbība.

Datu bāzu projektējuma aprakstam jāsatur informācija par datu bāzu struktūru, datu bāzes elementu funkcionālo saturu, saistīto programmatūru, informācija par prasībām, kas noteiktas datu bāzei un tās elementiem, kā, piemēram, drošība, integritāte u.c., kā arī jebkura cita veida informācija, kas nepieciešama datu pārbaudei, modificēšanai u.tml.

Lietotāja dokumentācija

Programmatūras lietotāja rokasgrāmata

LVS 66:1996;

IEEE/EIA J-STD-016 (J.2.1.)

Programmatūras lietotāja rokasgrāmatai ir jānodrošina nepieciešamais informācijas līmenis, kas nepieciešams sistēmas programmatūras lietotājiem, lai varētu izmantot sistēmas programmatūru. Programmatūras lietotāja rokasgrāmatai ir jābūt izstrādātai veidā, kas ir piemērots izmantošanai gan drukātā, gan tiešsaistes formā.

Programmatūras uzturēšanas plāns

ISO/IEC 12207

Programmatūras uzturēšanas procedūra

ISO/IEC 12207

Testēšanas dokumentācija

Programmatūras testēšanas apraksts

LVS 70:1996; LVS 73:1996;

IEEE/EIA J-STD-016 (H.2.1.)

Programmatūras testēšanas aprakstā jāapraksta testu sagatavošana, testpiemēri un testēšanas procedūras, kas nosaka, kā veikt SISTĒM programmatūras elementa, sistēmas vai apakšsistēmas testēšanu

Testēšanas (kopsavilkuma) pārskats

LVS 70:1996;

IEEE/EIA J-STD-016 (H.2.2.)

Testēšanas (kopsavilkuma) pārskatā jāapraksta visu plānoto un izpildīto testēšanas darbību rezultātu kopsavilkums, kā arī jādod novērtējums, balstoties uz minētiem rezultātiem.

Testēšanas procedūras specifikācija

LVS 70:1996; IEEE 829

Testēšanas procedūras specifikācijas uzdevums ir aprakstīt testpiemēru izpildīšanas soļus, kas nodrošina testēšanas uzdevuma izpildi (t.i., testēšanas darbību

10

Pakalpojuma sastāvdaļa

Atbilstība Paskaidrojums

izpildes secību).

Testēšanas žurnāls LVS 70:1996; IEEE 829

Testēšanas žurnālam jāsatur būtisko testa izpildīšanas detaļu hronoloģiskus pierakstus.

Testpiemēru specifikācija

LVS 70:1996; IEEE 829

Testpiemēru specifikācijā jāapraksta katrs testpiemērs, kas definēts testu projektējuma specifikācijā.

Testu projektējuma specifikācija

LVS 70:1996; IEEE 829

Testu projektējuma specifikācijā jāapraksta programmatūras pazīmju vai to kombināciju testēšanas pieejas detaļas un jāidentificē atbilstošie testi.

Programmatūras apskates un auditēšana

LVS 74:1996 Projekta iekšējo pārbaužu dokumentēšanas forma. Jāapraksta iekšējo pārbaužu (apskates un auditēšanas) jāapraksta projekta attīstīšanas laikā paredzētās īstenošanas procesi, kā arī specifiskās procedūras, kas nepieciešamas apskates un auditēšanas izpildei.

3.3. Prasības pieteikumu apstrādei

(011) Pasūtītāja un Izpildītāja sadarbības kārtība (Obligāta)

Pakalpojuma aktivitātes var ierosināt gan Pasūtītājs, gan Pakalpojuma sniedzējs.

Par visām problēmām tiek informētas abas puses, t.i., neatkarīgi no tā, kura puse konstatē problēmu, tā informē otru pusi attiecīgi līgumā noteikto/-ās kontaktpersonas uz līgumā iekļauto elektronisko pasta adresi.

3.4. Pakalpojuma nodrošināšana

(012) Pakalpojuma sniegšanas periods (Obligāta)Pakalpojuma sniedzējam ir jānodrošina uzturēšanas un pilnveidošanas periods, skaitot no līguma abpusējas parakstīšanas dienas, kas sastāv no divām daļām:

1) koncepcija un laika grafiks jāsagatavo un jāiesniedz mēneša laikā no līguma noslēgšanas dienas;

2) termiņš, līdz kuram VID tiek nodota programmatūra testēšanai, kā arī tās dokumentācija izskatīšanai, atstājot periodu pilnvērtīgai akcepttestu veikšanai (ne vēlāk kā līdz 2019.gada 29.martam) ;

3) termiņš, ar kuru jānodrošina čeku spēles organizēšana un īstenošana, sākot ar Pasūtītāja pilnvarotās personas pieprasījumā norādītā termiņu, bet ne ātrāk kā no 2019.gada 1.jūlija un līdz 2021.gada 5.janvārim nomas aktīvajā periodā. No 2021.gada 6.janvāra līdz 2021.gada 28.februārim nomas daļēji aktīvajā periodā.

Pakalpojuma sniegšanas publisko daļu sastāda divi periodi:

1) Aktīvais periods – periods, kurā notiek dalībnieku reģistrācija, tiek darbināta uzvarētāju noteikšanas procedūra, kā arī veikti citi atbilstošie pasākumi Pakalpojuma nodrošināšanai (no 2019.gada 1.jūlija līdz 2021.gada 5.janvārim);

2) Daļēji aktīvais periods – periods, kurā pakalpojuma sniedzējs uzglabā datus un nodrošina mājaslapas pieejamību skatīšanās režīmā (no 2021.gada 6.janvāra līdz 2021.gada 28.februārim).

11

(013) Palīdzības un konsultāciju pieejamība uzturēšanas nodrošināšanas laikā(Obligāta)

Uzturēšanas ietvaros Pakalpojuma sniedzējam jānodrošina palīdzība un konsultācijas saskarnes funkcionalitātes izmantošanā Pasūtītāja darba dienās no pirmdienas līdz ceturtdienai no plkst. 8:15 līdz plkst.17:00, piektdien no plkst.8:15 līdz plkst.15:45.Uzturēšanas un pilnveidošanas ietvaros tehniskais atbalsts, palīdzība un konsultācijas sniedzamas, izmantojot sekojošus komunikācijas kanālus – telefoniski, pa e-pastu un klātienē. Izstrādātājam ir jānodrošina visi norādītie komunikācijas kanāli.

(014) Drošības prasības (Obligāta)Pakalpojums jāveido tā, lai samazinātu visu potenciālo drošības atribūtu – konfidencialitātes, integritātes un pieejamības, apdraudējuma riskus. Tajā skaitā:

- Nodrošināt, ka strādāt ar Pakalpojuma sniedzēja programmatūru, kas attiecas uz VID un Pakalpojuma sniedzēja darbiniekiem un amatpersonām, drīkst tikai autentificēti un autorizēti lietotāji, atbilstoši piešķirtajām tiesībām. Lietotāji nedrīkst piekļūt Pakalpojuma ietvaros glabājamai informācijai, apejot drošības kontroles programmas, piemēram, operētājsistēmas, failu sistēmas vai datu bāzes līmenī.Ievērojot:

a) „Zina tikai tas, kuram jāzina” (need-to-know);b) „Ir jānodrošina minimālās tiesības pienākumu pildīšanai”, gan lietotājiem, gan tehnoloģiskajiem lietotājiem (least privilege);- Pakalpojumam jādarbojas tikai uz ražotāja uzturētām operētājsistēmām, datu bāzes vadības

sistēmām u.c. izstrādes ietvariem (development framework), nodrošinot atjauninājumus atbilstoši ražotāja rekomendācijām.

- Pakalpojuma datu integritāte, nodrošinot, ka Pakalpojumā nav iespējams veikt neautorizētas izmaiņas, visa piekļuve datiem un datu izmaiņas tiek ierobežotas ar atbilstošām piekļuves tiesībām un tiek auditētas; Jānodrošina lietotāju darbību reģistrācija un šo datu saglabāšana.

- Datu apmaiņa starp sistēmu un citām sistēmām, un lietotājiem, ja tiek izmantoti publiski tīkli, tiek šifrēta ar vismaz 256 bitu šifrēšanu.

- Nepieļaut Pakalpojama apdraudējumu no populārākajām ievainojamībām (https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project)

- Nodrošināt programmatūras darbību ar konfigurāciju, kas pieļauj tikai HTTP GET, HTTP POST, HTTP HEAD metožu izmantošanu.- Noteikt sistēmas darbināšanai nepieciešamo opertātājsistēmas un/vai datubāzes un to

komponenšu minimumu, lai var veikt sistēmas cietināšanas pasākumus, atslēdzot nevajadzīgo funkcionalitāti, tādā veidā mazinot drošības riskus.

- Nodrošināt, ka programmatūra lietotājam nesniedz informāciju, kas varētu apdraudēt sistēmas drošību, tai skaitā, nepieļaujot iespēju lietotājam veikt analīzi par kļūdas un veikto sistēmas pārbaužu raksturu. Kļūdas situācijās lietotājam parādīt nepieciešamo informāciju, detalizētu tehnisko informāciju nosūtot sistēmas administratoram un veicot informācijas ierakstīšanu sistēmas žurnālā, lai pārāk detalizēti kļūdu paziņojumi neļauj lietotājam iegūt nevēlamu informāciju par izmantotajām tehnoloģijām, sistēmas arhitektūru un veiktajām drošības pārbaudēm, kas varētu atvieglot tālākos uzbrukumus sistēmai.

- Nodrošināt, ka sistēmas datu apmaiņas procesi tiek pildīti tikai ar tehnoloģisko lietotāju kontiem, kuriem informācija ir pieejama tikai tādā apjomā, kas nepieciešama attiecīgās datu apmaiņas nodrošināšanai, lai nepamatoti augstu privilēģiju izmantošana, kur tas nav nepieciešams, neradītu nevajadzīgus datu integritātes, konfidencialitātes un pieejamības riskus.

12

- Pakalpojuma sniedzējam ar darbiniekiem ir noslēgti konfidencialitātes līgumi, kas paredz noteikumus un atbildību darbā ar klientu datiem, kā arī esošie darba līgumi un procedūras paredz noteikumus darbībām ar parolēm un citiem parametriem, kas nosaka piekļuvi.

- Sistēmas drošības funkcionālās prasības jāizpilda saskaņā ar standartā ISO 15408-2 “Informācijas tehnoloģija – Drošības tehnikas – IT drošības novērtējuma kritēriji” 2.daļā “Drošības funkcionālās komponentes” (Information technology – Security techniques – Evaluation criteria for IT security – Part 2: Security functional components. ISO/IEC 15408-2. Third edition 2008-08-15) noteikto aprakstu.

(015) Kļūdas paziņojumi (Obligāta)Sistēmai ir jāattēlo klasificēts kļūdas paziņojums (kļūda, brīdinājums, informācija) ar detalizētu aprakstu un iespējamām turpmākām darbībām. Kļūdu paziņojumi ir jāveido tā, lai būtu iespējams lietotājam draudzīgā veidā sniegt informāciju par problēmu un turpmākajām darbībām, kas jāveic. Kļūdas paziņojumā nav jābūt sistēmas iekšējai informācijai par kļūdaini izpildīto darbību. Auditācijas ierakstos ir jābūt pilnam kļūdas paziņojumam.

(016) Informācijas iekšējās integritātes nodrošināšana (Obligāta)Sistēmai ir jānodrošina informācijas integritāte no biznesa loģikas viedokļa. Lai nodrošinātu informācijas integritāti, jāveic datu validācija gan lietotāja, gan ārējās saskarnes, gan datu bāzes līmenī.

3.5. Testēšanas prasības(017) Izstrādātāja veiktie nodevumu testi (Obligāta)Lai nodrošinātu Nodevuma atbilstību noteiktajām prasībām, Pakalpojuma sniedzējam ir jānodrošina nodevumu iekšējā testēšana atbilstoši kādai no zināmām testēšanas metodoloģijām un testēšanas dokumentācijas sagatavošana.Izstrādātājam jānodrošina vismaz:a) Funkcionalitātes testēšana;b) Integritātes testēšana;c) Drošības testēšana.Testēšanu veic Pakalpojuma sniedzējs ar saviem resursiem, neiesaistot Pasūtītāju, pirms nodošanas Pasūtītājam akcepttestēšanai, lai pārliecinātos par sistēmas kvalitāti.Sistēma akcepttestēšanai ir jānodod kopā ar Izstrādātāja veiktās testēšanas dokumentāciju.

(018) Funkcionālā testēšana (Obligāta)1) Testpiemēros jāiekļauj visu programmatūras prasību specifikācijā/aprakstā iekļauto funkciju (prasību) pārbaude. Testpiemēros jāiekļauj gan „pozitīvie” (ievadīti korekti dati - mērķis ir pārbaudīt, vai sistēmas programmatūras funkcionalitāte strādā korekti), gan „negatīvie” (ievadīti kļūdaini dati - mērķis ir pārbaudīt, sistēmas programmatūras darbaspēju un korektu apstrādi kļūdu un problēmsituāciju gadījumā) piemēri; 2) Testpiemēros jānorāda gan ievaddati, gan sagaidāmie rezultāti;3) Testēšanas scenārijos ir jāiekļauj visu darba plūsmas zaru pārbaude.

(019) Sistēmas akcepttestēšana (Obligāta)Sistēmas akcepttestēšanas kārtība aprakstīta pakalpojuma līguma 3.pielikuma 10.punktā un 11.punktā. Pasūtītājs veiks akcepttestēšanu saskaņā ar testēšanas dokumentāciju.

13

Pakalpojuma sniedzējam ir jānodrošina akcepttestēšanas vides sagatavošana un akcepttestu norisei nepieciešamās konsultācijas.Balstoties uz Pasūtītāja iesniegtajiem testēšanas protokoliem un problēmziņojumiem, Pakalpojuma sniedzējam jānovērš akcepttestēšanas laikā identificētās problēmas.

(020) Sistēmas funkcionalitātes demonstrācija (Obligāta)Sistēmas funkcionalitātes demonstrācijas mērķis ir pārliecināties, ka sistēma atbilst Pasūtītāja prasību analīzes laikā definētiem biznesa procesiem, pilda biznesa procesu nodrošināšanai nepieciešamo funkcionalitāti. Sistēmas demonstrācijas laikā Pasūtītājs neveic akcepttestēšanu. Sistēmas demonstrācija notiek Pakalpojuma sniedzēja testa vidē. Sistēmas funkcionalitātes demonstrācija veicama pēc Pasūtītāja pieprasījuma.Atbilstoši sistēmas funkcionalitātes demonstrācijas laikā Pasūtītāju identificētiem nepieciešamiem papildinājumiem/ nepilnībām/ priekšlikumiem/ ierosinājumiem, Pakalpojuma sniedzējam ir jāveic izstrādātās un apstiprinātās programmatūras dokumentācijas papildināšana un/vai atjaunošana (Sistēmas funkcionalitātes demonstrācijas laikā Pasūtītājs neizvirzīs prasību analīzes laikā definētām prasībām pretrunīgas prasības). Pakalpojuma sniedzējam jāveic atjaunotās dokumentācijas atkārtota saskaņošana ar Pasūtītāju. Pēc dokumentācijas apstiprināšanas Pakalpojuma sniedzējam ir jāveic nepieciešamās izmaiņas sistēmā.

(021) Veiktspējas, ātrdarbības un slodzes testēšana (Obligāta)Daudzlietotāju režīma veiktspējas, ātrdarbības un slodzes testēšanai ir jāsimulē sistēmas darbību:a) Nominālas noslodzes apstākļos (šī testa ietvaros ir jāparāda, ka sistēma var izpildīt noteiktās ātrdarbības prasības nominālas noslodzes apstākļos);b) Maksimālas noslodzes apstākļos (pakāpeniski paaugstinot noslodzi, nosakot slieksni, kad veiktspējas prasības vairs netiek izpildītas vai arī līdz sistēmas darbības atteicei).Papildus Pakalpojuma sniedzējam jānodrošina:a) Stabilitātes testēšana (šī testa ietvaros ir jāpārbauda sistēmas darbības stabilitāte to ilgstoši darbinot pie dažādām noslodzēm, piemēram, nominālas noslodzes).b) Kapacitātes testēšana (šī testa ietvaros ir jāpārbauda sistēmas spēju robežas pie dotās tehniskās konfigurācijas).c) Mērogojamības testēšana (šī testa ietvaros ir noskaidrot sistēmas mērogojamības iespējas). Noslodzes nosacījumi ir jādetalizē programmatūras prasību specifikācijā.

(022) Drošības testēšana (Obligāta)Drošības testēšanas mērķis ir pārbaudīt sistēmas noturību pret nesankcionētu pieeju un uzbrukumiem.Vienlaikus gan slodzes testa laikā, gan veicot drošības un funkcionālos testus, kas simulē dažādas kļūdas uz darbības atteikumu vērstas darbības, jāvērtē sistēmas darbības stabilitāte un drošība.Pakalpojuma sniedzējam ir jānovērš testēšanas laikā atklātie defekti un jāiesniedz Pasūtītājam testēšanas dokumentācija.

14