tehniskā specifikācija - vmnvd.gov.lv file · web viewvienotĀ uzraudzĪbas informĀcijas...

VIENOTĀ UZRAUDZĪBAS INFORMĀCIJAS SISTĒMA

TEHNISKĀ SPECIFIKĀCIJA

NACIONĀLAIS VESELĪBAS DIENESTS

Dokumenta identifikācijas Nr. document.doc

Versija 2.0

2014. GADA 15.JŪLIJS

RĪGA

Vienotā uzraudzības informācijas sistēma Versija 2.0

Tehniskā specifikācija 2014.gada 15.jūlijs

Šī dokumenta autoru personiskās tiesības pieder tā izstrādātājiem. Dokumenta autoru mantiskās tiesības

pieder Pasūtītājam, kuram ir tiesības izmantot šo dokumentu saskaņā ar līgumu Nr. VM NVD 2013/14 ERAF.

Pieļaujama dokumentā iekļautās informācijas citēšana un izmantošana atvasinātu darbu veidošanai,

iekļaujot atsauci uz šo dokumentu.

Visas tekstā izmantotās tirdzniecības zīmes pieder to īpašniekiem un ir izmantotas tikai kā atsauces.

Darbi tiek finansēti no ERAF projekta „E-veselības integrētās informācijas sistēmas attīstība” (ID Nr.

3DP/3.2.2.1.1/13/IPIA/CFLA/008) līdzekļiem.

Dokumenta autori

Jānis Sprukts, SIA Corporate Consulting

Imants Felsbergs, SIA Corporate Consulting

Rasa Sarnoviča, SIA Corporate Consulting

Kontaktpersona:

Āris Āriņš

SIA “Corporate Consulting”

Pērnavas 43a - 9

Rīga, LV-1009

Tel.: (+371) 67 84 77 62

Fakss: (+371) 67 84 77 61

E-pasts: [email protected]

Izmaiņu lapa

Versija Datums Apraksts Autors

1.0 28.04.2014 Izveidota dokumenta sākotnējā versija. J.Sprukts, I.Felsbergs, R.Sarnoviča

1.1 26.05.2014 Iestrādāti Pasūtītāja komentāri J.Sprukts

1.2 20.06.2014 Iestrādāti Pasūtītāja komentāri J.Sprukts

2.0 15.07.2014 Veikta dokumenta sagatavošana gala versijas iesniegšanai Pasūtītājam

Autoru kolektīvs

2



SATURA RĀDĪTĀJS

1. Ievads 5

1.1. Nolūks 5

1.2. Darbības sfēra 5

1.3. Lietotie termini un skaidrojumi 5

1.4. Saistība ar citiem dokumentiem 5

1.5. Dokumenta izstrādes procesā veiktās intervijas un notikušās darba grupas 5

1.6. Kopsavilkums 5

2. Projekta konteksts6

2.1. VUIS darbības principi un darbības vide 6

2.2. VUIS atbalstāmie procesi 6

2.3. VUIS darbību reglamentējošo dokumentu saraksts 7

2.4. VUIS informācijas sistēma un datu apmaiņas saskarnes 8

2.5. VUIS darbību atbalstošā IT arhitektūra 8

2.6. VUIS lietotāju kategorijas un tiesību grupas 8

3. Funkcionālās prasības 10

3.1. Risku analīzes modulis 10

3.2. Plānošanas un resursu pārvaldības modulis 13

3.3. Ekspertīžu modulis 17

3.4. Laboratoriju izmeklējumu modulis 19

3.5. E-pakalpojumi 20

3.6. Integrācijas papildinājumi 21

3.7. Citi funkcionālie papildinājumi 22

3.7.1. Iesniegumi 22

3.7.2. Notikumi 24

3.7.3. Darba uzdevumi 24

3.7.4. Administratīvie akti 24

3.7.5. Uzraudzības objektu kontrole 26

3



4. Nefunkcionālās prasības 27

4.1. Veiktspējas prasības 27

4.2. Drošības prasības 27

4.3. Saskarņu un to lietojamības prasības 28

4.4. Prasības tehniskajai infrastruktūrai un standarta programmatūrai 29

4.5. Sistēmas darbības nepārtrauktības prasības 29

5. Organizatoriskās prasības 30

5.1. Laika grafiks 30

5.2. Ieviešanas projekta pārvaldības prasības 30

5.3. Izmantotie standarti 30

5.4. Konfigurācijas pārvaldības prasības 30

5.5. Nodevumi 31

5.6. Nodevumu pieņemšanas kārtība 32

5.7. Apmācību procesa prasības 33

5.8. Ieviešana 34

5.9. Apmācības 35

5.10. Izmaiņu pieprasījumu realizācija 35

5.11. Garantijas prasības 36

4



1. IEVADS

1.1. Nolūks

Dokumenta nolūku skatīt dokumenta „Vienotā uzraudzības informācijas sistēma. Vispārīga informācija” 1.sadaļā „Nolūks”.

1.2. Darbības sfēra

Dokumenta darbības sfēru skatīt dokumenta „Vienotā uzraudzības informācijas sistēma. Vispārīga informācija” 2.sadaļā „Darbības sfēra”.

1.3. Lietotie termini un skaidrojumi

Dokumentā lietoto terminu sarakstu un to skaidrojumus skatīt dokumenta „Vienotā uzraudzības informācijas sistēma. Vispārīga informācija” 3.sadaļā „Lietotie termini un to skaidrojums”.

1.4. Saistība ar citiem dokumentiem

Saistīto dokumentu sarakstu skatīt dokumenta „Vienotā uzraudzības informācijas sistēma. Vispārīga informācija” 4.sadaļā „Saistība ar citiem dokumentiem”.

1.5. Dokumenta izstrādes procesā veiktās intervijas un notikušās

darba grupas

Dokumenta izstrādes procesā veiktās intervijas un notikušās darba grupas skatīt dokumenta „Vienotā uzraudzības informācijas sistēma. Vispārīga informācija” 5.sadaļā „Dokumenta izstrādes procesā veiktās intervijas un darba grupas”.

1.6. Kopsavilkums

Šis dokuments sastāv no 5 sadaļām: 1.sadaļā ir izklāstīts dokumenta izstrādāšanas nolūks, darbības sfēra, sniegts dokumenta pārskats,

norādes uz saistītajiem dokumentiem, kā arī dots izmantoto terminu un saīsinājumu skaidrojums; 2.sadaļā ir aprakstītas vispārīgās prasības saistībā ar projekta kontekstu; 3.sadaļā ir aprakstītas VUIS funkcionālās prasības; 4.sadaļā ir aprakstītas VUIS nefunkcionālās prasības; 5.sadaļā ir aprakstītas VUIS organizatoriskās prasības.

5



2. PROJEKTA KONTEKSTSŠajā nodaļā ir aprakstīts Vienotās uzraudzības informācijas sistēmas attīstības projekta konteksts un

prasības.

2.1. VUIS darbības principi un darbības vide

Vienotās uzraudzības informācijas sistēmas esošā situācija ir aprakstīta dokumentā „Vienotās uzraudzības

informācijas sistēmas esošās situācijas izvērtējums”. Situācija pēc Vienotās uzraudzības informācijas

sistēmas 2.kārtas ieviešanas ir aprakstīta dokumentā „Vienotās uzraudzības informācijas sistēmas attīstības

plāna apraksts”. Citi dokumenti, kuri Izpildītājam būtu lasāmi vienlaicīgi ar šo dokumentu ir iekļauti

1.4.nodaļā.

Izpildītājam ir jāattīsta Vienotās uzraudzības informācijas sistēma atbilstoši Vienotās uzraudzības

informācijas sistēmas arhitektūras dokumenta 2.nodaļā minētajiem principiem, aprakstam un prasībām.

2.2. VUIS atbalstāmie procesi

Izpildītājam ir jāattīsta Vienotās uzraudzības informācijas sistēma tā, lai tā nodrošinātu vismaz Tabulā 4

„VUIS atbalstāmie plānotie biznesa procesi” uzskaitītos procesus, ņemot vērā funkcionālās prasības un to

realizācijas prioritātes. Sistēmas analīzes fāzes laikā Pasūtītājs var precizēt procesus, saskaņojot tos ar

Izpildītāju. Procesu detalizētais izvērsums ir sniegts Vienotās uzraudzības informācijas sistēmas attīstības

plāna aprakstā.

Tabula 1. VUIS atbalstāmie plānotie biznesa procesi

Biznesa procesa

identifikators

Biznesa procesa nosaukums

BP_K.01 Tipveida kontroles lapu izveide

BP_K.02 Uzraudzības plānošana

BP_K.03 Objekta kontroles pasākumu izpilde

BP_IR Iesniegumu reģistrēšana

BP_NR Notikuma reģistrēšana

BP_EK Ekspertīzes veikšana

BP_AA Administratīvā akta sagatavošana

BP_AL Administratīvā pārkāpums lēmuma sagatavošana

6



BP_LA Lēmuma apstrīdēšana

2.3. VUIS darbību reglamentējošo dokumentu saraksts

Izpildītājam ir jāattīsta Vienotās uzraudzības informācijas sistēma, ievērojot visus šajā nodaļā nosauktos

normatīvos aktus un dokumentus. Ja Projekta realizācijas laikā ir stājusies spēkā jauna normatīvā akta vai

dokumenta redakcija, Izpildītājam ir jāņem vērā aktuālā redakcija. Uzsākot Projekta realizāciju, analīzes

fāzes laikā Izpildītājam ir jāveic normatīvo aktu dokumentu versiju pārbaude, lai identificētu to aktuālās

versijas.

VUIS darbību reglamentē šādi normatīvie akti:

Eiropas Parlamenta un Padomes Direktīva 95/46/EK (1995. gada 24. oktobris) par personu

aizsardzību attiecībā uz personas datu apstrādi un šādu datu brīvu apriti;

LR likums „Elektronisko dokumentu likums”;

LR likums „Fizisko personu datu aizsardzības likums”;

LR likums „Par Eiropas Padomes Konvenciju par personu aizsardzību attiecībā uz personas datu

automātisko apstrādi”;

LR likums „Valsts informācijas sistēmu likums”;

MK noteikumi Nr.40 „Personas datu aizsardzības obligātās tehniskās un organizatoriskās prasības”

(30.01.2001.);

MK noteikumi Nr.134 „Noteikumi par vienoto veselības nozares elektronisko informācijas sistēmu"

(11.04.2014.);

MK noteikumi Nr.421 „Valsts informācijas sistēmu savietotāju un integrēto valsts informācijas

sistēmu aizsardzības prasības” (19.06.2012.);

MK noteikumi Nr.473 „Elektronisko dokumentu izstrādāšanas, noformēšanas, glabāšanas un aprites

kārtība valsts un pašvaldību iestādēs un kārtība, kādā notiek elektronisko dokumentu aprite starp

valsts un pašvaldību iestādēm vai starp šīm iestādēm un fiziskajām un juridiskajām personām”

(28.06.2005.);

MK noteikumi Nr.764 „Valsts informācijas sistēmu vispārējās tehniskās prasības” (11.10.2005.);

MK noteikumi Nr.765 „Valsts informācijas sistēmu vispārējās drošības prasības” (11.10.2005.).

VUIS jāatbalsta veselības nozares uzraudzības normatīvos aktu piemērošanu. Galvenie normatīvie akti:

Ārstniecības likums un tā likumpamatotie Ministru Kabineta noteikumi;

Farmācijas likums un tā likumpamatotie Ministru Kabineta noteikumi;

Epidemioloģiskās drošības likums un tā likumpamatotie Ministru kabineta noteikumi;

7



MK noteikumi Nr. 235 "Dzeramā ūdens obligātās nekaitīguma un kvalitātes prasības, monitoringa un

kontroles kārtība" (29.04.2003.);

Ķīmisko vielu likums un tā likumpamatotie Ministru kabineta noteikumi;

Latvijas administratīvo pārkāpumu kodekss;

Administratīvā procesa likums;

likumprojekts "Administratīvo pārkāpumu procesa likums" (Saeimā Nr.1160/Lp11).

Pilns normatīvo aktu saraksts ir pieejams Veselības inspekcijas mājaslapā:

http://www.vi.gov.lv/lv/sakums/normativie-akti

2.4. VUIS informācijas sistēma un datu apmaiņas saskarnes

Vienotās uzraudzības informācijas sistēma veidota kā neatkarīga informācijas sistēma. Izstrādes ietvaros,

nepieciešams izveidot automātiskas datu apmaiņas saskarnes ar šādām sistēmām:

Ārstniecības iestāžu reģistrs;

Ārstniecības personu un ārstniecības atbalsta personu reģistrs;

Zāļu valsta aģentūras informācijas sistēmas Licencētie farmaceitiskās darbības uzņēmumi;

Valsts izglītības informācijas sistēma (Izglītības iestāžu reģistrs);

VI dokumentu vadības sistēma DocLogix;

Datu saskarni ar laboratorijām, kas veic dzeramā ūdens testēšanu.

2.5. VUIS darbību atbalstošā IT arhitektūra

Izpildītājam ir jāattīsta Vienotās uzraudzības informācijas sistēma, ņemot vērā Vienotās uzraudzības

informācijas sistēmas arhitektūru. Vienotās uzraudzības informācijas sistēmas arhitektūra detalizētāk

aprakstīta dokumentā „Vienotās uzraudzības informācijas sistēmas arhitektūra”.

2.6. VUIS lietotāju kategorijas un tiesību grupas

VUIS lietotāji ir Veselības inspekcijas darbinieki. Zemākajā līmenī lietotāju tiesības VUIS tiek piešķirtas uz

konkrētām ekrānformām un spiedpogām. Zemākā līmeņa tiesības tiek grupētas biznesa lomās, kas aptver

noteiktu funkcionalitātes apgabalu. Kopumā sistēmā ir virs 70 biznesa lomām, kuras tiek piešķirtas

lietotājiem pēc nepieciešamības. VUIS lietotāji ir dalāmi šādās grupās:

Lietotāju grupa Lietotāju grupas apraksts

Sistēmas administrators Veic lietotāju tiesību administrēšanu, sistēmas kodifikatoru

uzturēšanu un dažādu citu sistēmas parametru administrēšanu.

8

http://www.vi.gov.lv/lv/sakums/normativie-akti



VI vadība Datu ievadi neveic, bet ir piekļuve visai funkcionalitātei skatīšanās

režīmā un atskaišu izgūšanai.

VI inspektors Plāno kontroles, ievada veikto kontroļu datus un citu saistīto

informāciju, tai skaitā uzraudzības objekta datus un administratīvo

pārkāpumu aktus. Var aizpildīt datus tikai sevis reģistrētajām

kontrolēm vai kontrolēm, kur nozīmēts kā galvenais inspektors.

Citu datu ievades un informācijas pievienošanas tiesības, kas nav

kontroles akti, attiecināmas arī uz higiēnas ārstiem un vides

veselības analītiķiem, un nozaru plānošanas nodaļu darbiniekiem.

Veselības aprūpes kvalitātes

eksperts

Veiks datu ievadi Ekspertīžu modulī, izgūs atskaites.

E-pakalpojumu apstrādes speciālists Apstrādā ienākošos e-pakalpojumus.

E-pakalpojumu administrators Administrē e-pakalpojumu uzstādījumus.

Normatīvo aktu speciālists Veic datu (normatīvo aktu prasības un tipveida kontroles lapu

prasības) ievadi Normatīvo aktu modulī.

9



3. FUNKCIONĀLĀS PRASĪBASŠajā sadaļā ir aprakstītas VUIS funkcionālās prasības. Visas šajā sadaļā minētās prasības ir ietveramas

tehniskā piedāvājuma sagatavošanā un realizējamas Projekta izpildes laikā.

VV-01 Prasību izpildes aprakstsPrasību izpildes aprakstam tehniskajā piedāvājumā jābūt pietiekamam, lai nepārprotami būtu aprakstīts

prasības īstenošanas mehānisms vai rīki (līdzekļi), ar kuriem ir iespējams izpildīt prasību, un Izpildītāja

izpratne par piedāvājumu. Apraksts, kurā būs pārrakstīts tikai prasības teksts vai iekļauts tikai prasības

izpildes apsolījums, apraksts, kurš būs pretrunā tehniskās specifikācijas prasībām, vai apraksts ar citu

prasību izpildes piedāvājumu, netiks uzskatīts par detalizētu, un šādi piedāvājumi netiks vērtēti.

VV-02 Piedāvājuma apraksta formaTehniskajā piedāvājumā jāiekļauj tabula, kur apliecināta Tehniskā piedāvājuma atbilstība visām Tehniskās

specifikācijas prasībām, norādot veidu, kā katra konkrētā prasība tiks nodrošināta. Veidojot tehniskā

piedāvājuma prasību izpildes aprakstu, jāņem vērā Nodevuma dokumentā „Vienotās uzraudzības

informācijas sistēma Attīstības plāns” aprakstos aprakstītie biznesa procesi.

3.1. Risku analīzes modulis

Sistēma jāpapildina ar risku analīzes moduli, kurš atbilst Vienotās uzraudzības informācijas sistēmas

attīstības plāna (VUIS.APL) 3.1.sadaļā „Risku analīzes modulis” un šajā nodaļā aprakstītajām prasībām. Risku

modulim balstoties uz risku kritērijiem, uzraudzības objektiem darbības veidu līmenī jāaprēķina risku

reitings, jānosaka uzraudzības objekta kopējais risku reitings un riska grupa.

RAM-01 Risku aprēķina kritēriji (Obligāta)Uzraudzības objekta darbības veidam risku jāaprēķina pēc šādiem kritērijiem:

R1: Darbības veida potenciālā ietekme uz sabiedrību, kur iespējamās vērtības ir:

Minimāla ietekme; Mazsvarīga ietekme; Būtiska ietekme; Liela ietekme

R2: Objekta darbības ietekme uz potenciālajiem riskiem, kur iespējamās vērtības ir:

Minimāla; Zema; Vidēja; Augsta.

10



R3: Darbības veidu reglamentējošās likumdošanas sarežģītība (piemērams, normatīvo aktu daudzums

vai mainība), kur iespējamās vērtības ir:

Zema; Vidēja; Augsta; Ļoti augsta.

R4: Ietekmēto patērētāju daudzums, kur iespējamās vērtības ir:

Ļoti nedaudzi; Daži; Vidējs skaits; Būtisks skaits.

R5: Objekta uzticamība.

Risku kritērijiem no R1 līdz R3 vērtībām ir jābūt konfigurējamiem darbības veidu līmenī. Piemēram darbības

veidam „Diagnostiskā nodaļa” ietekme uz sabiedrību (R1) varētu būt „minimāla”, uzņēmuma darbības

ietekme uz potenciālajiem riskiem (R2) „vidēja” un darbības veidu reglamentējošās likumdošanas

sarežģītība (R3) „ļoti augsta”.

Risku kritērija R4 vērtība ir jāvar norādīt pie konkrēta objekta struktūrvienības (darbības veida). Piemēram,

Veselības centra 4, K.Barona ielas 117, diagnostikas nodaļa varētu ietekmēt „vidēju skaitu” patērētāju (R4).

Risku kritērija R5 aprēķins aprakstīts prasībā „RAM-04 Objekta uzticamības riska kritērija aprēķins”.

Vērtību piešķiršana riska aprēķina kritērijiem ir precizējama izstrādes laikā.

RAM-02 Riska koeficientu konfigurācija (Obligāta)Katra risku kritērija katrai vērtībai jābūt iespējai konfigurācijā norādīt riska koeficientu, kurš tiks izmantots

riska aprēķinā. Riska koeficienta vērtībai jābūt decimāl daļskaitlim robežās no nulles (neieskaitot) līdz

vienam (ieskaitot). Riska koeficientu konfigurācijas tabulas piemērs attēlots tabulā „Tabula 2 – Risku

koeficientu konfigurācijas piemērs”, kur kolonnu Riska kritērijs un Riska vērtības ir predefinētas atbilstoši

prasībai „RAM-01Risku aprēķina kritēriji”, savukārt Riska koeficients ir konfigurējam vērtība.

Tabula 2 – Risku koeficientu konfigurācijas piemērs

Riska kritērijs Riska vērtība Riska koeficients

Darbības veida potenciālā ietekme uz sabiedrību Minimāla ietekme 1,0

Darbības veida potenciālā ietekme uz sabiedrību Mazsvarīga ietekme 0,9

Darbības veida potenciālā ietekme uz sabiedrību Būtiska ietekme 0,8

Darbības veida potenciālā ietekme uz sabiedrību Liela ietekme 0,7

Objekta darbības ietekme uz potenciālajiem riskiem Minimāla 1,0

11



… … …

RAM-03 Risku aprēķins (Obligāta)Riska reitingu uzraudzības objekta darbības veidam aprēķina pēc formulas:

RR=100*RK1*RK2*RK3*RK4*RK5, kur:

- RR ir riska reitings;

- RKn ir riska koeficients n-tajam riska kritērijam. Piemēram, ja darbības veida

„Diagnostikas nodaļa” riska kritērijam R1 „Darbības veida potenciālā ietekme uz

sabiedrību” vērtība ir „Mazsvarīga ietekme”, tad RK3 vērtība ir 0,9.

Balstoties uz aprēķinātajiem uzraudzības objekta darbības veidu riska reitingiem, jānosaka arī uzraudzības

objekta kopējais risku reitings un uzņēmuma kopējais risku reitings. Algoritms kopējā riska noteikšanai ir

jāprecizē un ar Pasūtītāju jāsaskaņo izstrādes gaitā. Piemēram, uzraudzības objekta kopējo riska reitingu

varētu noteikt kā minimumu no aprēķinātajiem uzraudzības objekta darbības veidu riska reitingiem,

savukārt uzņēmuma riska reitingu varētu noteikt kā vidējo aritmētisko no uzņēmumam atbilstošo

uzraudzības objektu riska reitingiem.

Riska reitinga pārrēķins uzraudzības objekta darbības veidam veicams pēc katras kontroles uzraudzības

objektā un reizi ceturksnī neatkarīgi no tā vai notikušas kontroles. Jābūt iespējai arī manuāli izsaukt riska

pārrēķinu uzraudzības objekta darbības veidam. Katrreiz kad tiek pārrēķināts riska reitings uzraudzības

objekta darbības veidam jāpārrēķina riska reitings arī atbilstošajam uzraudzības objektam un uzņēmumam.

RAM-04 Objekta uzticamības riska kritērija aprēķins (Obligāta)Objekta uzticamības riska kritēriju (R5) veido trīs apakš kritēriji:

R5.1 - Kontroles akta slēdziens, TKL kopējais vērtējums un TKL prasību individuālo vērtējuma svars

R5.2 - Inspektora aptaujas anketa, kura tiek aizpildīta kontroles laikā;

R5.3 - Objektam reģistrēto sūdzību un citu negatīvo notikumu daudzums pēdējā gada laikā attiecībā

pret objekta izmēru.

Līdzīgi kā pamata riska kritērijiem, arī apakš kritērijiem jādefinē iespējamās vērtības un katrai vērtībai jābūt

iespēja definēt riska koeficients. Tai skaitā jābūt vērtībai un iespējai definēt atbilstošo riska koeficientu

gadījumiem, kad informācija nav pieejama (konkrētajā objektā kontrole nav veikta, nav reģistrēta neviena

aptaujas anketa vai objektam nav reģistrēts neviens notikums). Kopējo R5 riska koeficientu veido apakš

kritēriju risku koeficientu reizinājums.

RAM-05 Uzraudzības objekta riska grupas (Obligāta)Balstoties uz aprēķināto uzraudzības objekta riska reitingu, sistēmai uzraudzības objektam jāpiešķir viena

no trim riska grupām („Augsta riska objekts”, „Vidēja riska objekts” vai „Zema riska objekts”).

12



Reitingu intervāliem, kuri atbilst katrai riska grupai, ir jābūt konfigurējamiem uzraudzības objektu klašu

griezumā.

RAM-06 Uzraudzības objekta riska profils (Obligāta)Uzraudzības objekta datu apskates ekfrānformā jāizveido jauna sadaļa „Riska profils”, kurā tiek attēlota

uzraudzības objekta risku analīzes informācija, tai skaitā uzraudzības objekta riska grupa, uzraudzības

objekta kopējais riska reitings un uzraudzības objekta darbības veidu riska reitingi.

Jābūt arī iespējai aplūkot informāciju kā mainījies riska reitings un riska grupa uzraudzības uzņēmumam,

objektam un struktūrvienībai laika gaitā.

Uzņēmuma datu apskates ekrānforma papildināma ar informāciju par uzņēmuma kopējo riska reitingu.

RAM-07 Inspektora aptaujas anketa (Vēlama)Uzraudzības kontroļu modulis jāpapildina ar iespēju kontroles ietvaros inspektoriem aizpildīt aptaujas

anketu, kas ir konfigurējama. Aptaujas anketa sastāv no dažiem jautājumiem, kuru mērķis ir noskaidrot

inspektoru viedokli par konstatēto neatbilstību atkārtošanās iespējamību vai jaunu neatbilstību rašanās

iespējamību. Aptaujas anketas aizpildīšana ir veidojama kā neobligāts solis. Jautājumu un iespējamo atbilžu

saraksts, kā arī rezultējošā riska vērtības noteikšanas mehānisms Izpildītājam sadarbībā ar Pasūtītāja

speciālistiem jādefinē izstrādes laikā.

RAM-08 Kontroles akta slēdziena, TKL vērtējuma un prasību svars (Obligāta)VUIS jāpapildina ar kontroles akta slēdziena svaru,TKL vērtējuma svaru un individuālo prasību svaru –

parametru, kurš nosaka prasības ietekmi uz kopējo TKL risku novērtējumu salīdzinoši ar citām TKL

prasībām. Sākotnēji visām TKL prasībām jāuzstāda vienāds svars, kuras tālāk VUIS lietotājiem jābūt iespējai

koriģēt. Pēc katrām prasību svaru izmaiņām veicams pilns pārrēķins.

3.2. Plānošanas un resursu pārvaldības modulis

VUIS jāpapildina ar darba plānošanas moduli, kurš atbilst šajā nodaļā aprakstītajām prasībām. Plānošanas

modulimjānodrošina iespēja izveidot un saskaņot Plānu.

DPM-01 Uzraudzības pasākumu plānošana (Obligāta)VUIS jāpapildina ar iespēju izveidot un apstiprināt Plānu Inspekcijas un kontroles nodaļu (līdz inspektoram)

līmenī. Plānam ir jāsatur obligātā un mainīgā daļa, atbilstoši NVD.VUIS.APL. 3.3.BP_PL-Uzraudzības

plānošana 4.solim. VUIS jāpapildina ar iespēju iegūt informāciju par Plāna izpildes statusu. Plāns ir saraksts

ar objektiem no Objektu reģistra, kurus konkrētajā gadā plānots kontrolēt. Plānam ir šādi statusi:

plānošanā – statuss tiek piešķirts uzreiz pēc Plāna izveides. Šajā statusā Plāns ir pieejams rediģēšanai;

13



saskaņots -šādu statusu Plānam var piešķirt lietotājs ar atbilstošām tiesībām nodaļas un Inspekcijas

līmenī.

apstiprināts - šādu statusu Plānam var piešķirt lietotājs ar atbilstošām tiesībām nodaļas un

Inspekcijas līmenī. Šajā statusā gada plāna obligātā daļa vairs nav rediģējama – drīkst veikt izmaiņas,

papildinot plānoto objektu sarakstu

noslēdzies – šāds statuss plānam tiek piešķirts, ja tas ir saskaņots un attiecas uz gadu, kurš jau ir

pagājis.

DPM-02 Kontrolējamo objektu saraksts (Obligāta)Plāna pamatā ir saraksts ar uzraudzības objektiem, kurus paredzēts konkrētajā gadā kontrolēt. Tiklīdz

uzraudzības objekts tiek pievienots gada plānam, tam konkrētā plāna ietvaros tiek piešķirts plānošanas

statuss. Jāparedz vismaz šādi plānošanas statusi:

plānots – objekts ir izvirzīts iekļaušanai kontrolējamo objektu sarakstā. Statusu var piešķirt gan visam

izgūtajam objektu sarakstam, obektu grupām, atsevišķiem objektiem;

saskaņotsiekļauts – objekta iekļaušana kontrolējamo objektu sarakstā ir saskaņota;

apstiprināts – objekta iekļaušana kontrolējamo objektu sarakstā ir apstiprināta;

kontrolēts – objektam plānošanas periodā ir reģistrēta plānveida kontrole;

atcelts – objekts no kontroles pasākumu gada plāna ir izkļauts. Izkļaušana var notikt gan plāna

saskaņošanas, gan izpildes periodā. Ja objekta kontrole ir atcelta, jāparedz obligāta pamatojuma

norāde.

Statusi ir precizējami sistēmas izstrādes laikā.

Kontrolējamo objektu saraksta sastādīšanai, saskaņošanai un apskatei VUIS jāpapildina ar kontrolējamo

objektu saraksta ekfrānformu, kurai jābūt šādām savēršamām/izvēršamām sadaļām:

Kopsavilkums – satur kontroles pasākumu gada plāna vispārīgo informāciju un globālās darbības;

Skats – globāla līmeņa filtrs, kas nosaka kādā griezumā kontrolējamo objektu saraksts aplūkojams;

Filtri – lokāla līmeņa filtrs, kurš nosaka kuri uzraudzības objekti iekļaujami kontrolējamo objektu

sarakstā;

Kolonnas – ļauj noteikt sarakstā attēlojamās kolonnas;

Saraksts – saraksts, kurš satur visus skatam atbilstošos uzraudzības objektus, kam gada plāna

ietvaros ir piešķirts kāds no statusiem vai kas atbilst norādītajiem filtriem;

Kopsummas – atlasīto un plānā iekļauto objektu kopsummas.

Katrā sadaļā nepieciešamā funkcionalitāte detalizētāk aprakstītā tālākajās prasībās un tā ir tālāk

precizējama sistēmas izstrādes gaiā.

14



Sākotnējais Objektu saraksts veidojams atbilstoši NVD.VUIS.APL. 3.3.BP_PL-Uzraudzības plānošana 2.solim.

DPM-03 Kontrolējamo objektu saraksts - kopsavilkums (Obligāta)Kontrolējamo objektu saraksta kopsavilkuma sadaļā attēlojama šāda informācija:

Gads – kontroles pasākumu gada plāna pārskata periods;

Statuss – kontroles pasākumu gada plāna statuss;

Kontrolējamo objektu kopsavilkuma sadaļā jābūt pieejamai šādai funkcionalitātei:

Iespējai pievienot visus ar filtriem atlasītos objektus kontroles pasākumu gada plānam statusā

plānots un statusā iekļauts;

Iespējai eksportēt sarakstu uz MS Excel tipa datni.

DPM-04 Kontrolējamo objektu saraksts - skats (Obligāta)Kontrolējamo objektu saraksta skata sadaļā jābūt iespējai norādīt vienu no iespējamajiem saraksta

aplūkošanas griezumiem:

Kopējais – sarakstā attēlo visus uzraudzības objektus, kam plāna ietvaros piešķirts kāds no statusiem

un visus objektus, kas atbilst norādītajiem filtriem (objektiem, kas atbilst filtriem, bet nav piešķirts

statuss gada plāna ietvaros, statusa lauku rāda kā tukšu kopu).

Struktūrvienības – sarakstā attēlo tikai tos uzraudzības objektus, kas vienlaicīgi:

attiecināmi uz izvēlēto VI struktūrvienību (pēc teritorijas un pēc VI struktūrvienības pārraudzībā esošajiem uzraudzības objekta darbības veidiem);

atbilst norādītajiem filtriem vai tiem plāna ietvaros piešķirts kāds no plānošanas statusiem. Darbības veida - sarakstā attēlo tikai tos uzraudzības objektus, kas vienlaicīgi:

veic norādītā veida darbības; atbilst norādītajiem filtriem vai tiem plāna ietvaros piešķirts kāds no plānošanas statusiem.

Kontrolējamo objektu saraksta skatus VI darbinieki izmantos, lai veiktu plānošanu tikai ar uz sevi

attiecināmajām uzraudzības objektu apakškopām.

DPM-05 Kontrolējamo objektu saraksts - filtri (Obligāta)Filtri nosaka kuri skatam atbilstošie uzraudzības objekti iekļaujami attēlojamajā sarakstā. Kontroles objektu

sarakstam jānodrošina uzraudzības objektu filtrēšana vismaz pēc šādiem parametriem:

uzraudzības objekta kopējā risku reitinga (iespēja norādīt risku reitinga intervālu) – gan pēc riska

grupas, gan pēc atsevišķa riska kritērija;

uzraudzības objekta risku reitinga noteiktā darbības veidā (iespēja norādīt darbības veidu un riska

reitinga vērtības intervālu);

uzraudzības objekta darbības veidiem (iespēja norādīt darbības veidu);

15



pēdējās kontroles rezultātiem uzraudzības objektā (kontroles akta slēdziens)

laika kopš pēdējās plānveida kontroles uzraudzības objektā (iespēja norādīt laiku, periodu);

laika kopš pēdējās plānveida kontroles uzraudzības objekta noteiktā darbības veidā (iespēja norādīt

darbības veidu un laiku, periodu).

Filtri ir precizējami izstrādes gaitā.

Kontrolējamo objektu saraksta filtrus VI darbinieki izmantos, lai atlasītu tos uzraudzības objektus, kuros

plānošanas pārskatā nepieciešams veikt kontroli. Filtriem atbilstošie uzraudzības objekti kļūst par kontroles

pasākumu plāna sastāvdaļu tikai tajā brīdī, kad tiem individuālā kārtā vai visai atlasei kopā tiek piešķirts

plānošanas statuss.

DPM-06 Kontrolējamo objektu saraksts - kolonnas (Obligāta)Kontrolējamo objektu saraksta kolonnu sadaļā iekļaujama funkcionalitāte, kas ļauj sarakstam ekrānformā

pievienot vai noņemt neobligātās kolonnas. Jābūt iespējai pievienot vai noņemt šādas kolonnas:

Iepriekš kontrolēts - laiks kopš pēdējās plānveida kontroles uzraudzības objektā (gados);

Kontroles rezultāts - pēdējās kontroles slēdziensObjekta kalses/apakšklases kods;

Objekta klases/apakšklases nosaukums;

Kontroles nodaļa;

Objekta adrese;

objekta riska grupa;

objekta riska reitings.

Neobligātās kolonnu saraksts ir precizējams izstrādes gaitā.

Neatkarīgi no tā vai neobligātās kolonnas tiek attēlotas sarakstā, tās visas jāiekļ saraksta eksportā uz

MS Excel.

DPM-07 Kontrolējamo objektu saraksts - saraksts (Obligāta)Kontrolējamo objektu sarakstā attēlo tabulu ar skatam atbilstošajiem uzraudzības objektiem, kam gada

plāna ietvaros ir piešķirts kāds no statusiem vai kas atbilst norādītajiem filtriem. Par katru objektu attēlo

vismaz šādas kolonnas:

Objekta nosaukums – objekta nosaukums, kurš darbojas kā hipersaite uz objekta kartiņu;

Statuss – objekta plānošanas statuss;

Pievienoja – vārds uzvārds lietotājam, kurš sākotnēji pievienoja uzraudzības objektu kontrolējamo

objektu sarakstam;

Izmainīts – pēdējo plānošanas statusa izmaiņu datums;

16



Izmainīja – pēdējo plānošanas statusa izmaiņu autora vārds un uzvārds;

Kontrole – plānošanas periodā reģistrētās plānveida kontroles akta numurs, kurš kalpo kā hipersaite

uz atbilstošās kontroles kartiņu. Ja objektam plānošanas periodā nav reģistrēta plānveida kontrole, šī

kolonna ir tukša;

Darbības – ikonas, kas atkarībā no uzraudzības objekta plānošanas statusa ļauj ar uzraudzības

objektu izdarīt kādu no šādām darbībām:

Ieplānot – darbība ļauj uzraudzības objektam bez plānošanas statusa piešķirt plānošanas statusu „plānots”;

Apstiprināt – darbība ļauj apstiprināt uzraudzības objekta iekļaušanu kontrolējamo objektu sarakstā, mainot tam statusu uz „iekļauts”. VUIS saglabā apstiprinātāja struktūrvienību un tai jābūt apskatāmai uzraudzības objekta kartiņā. Vienu uzraudzības objektu var apstiprināt vairāku struktūrvienību lietotāji;

Atcelt – darbība ļauj mainīt uzraudzības objekta plānošanas statusu uz „atcelts. Šādā gadījumā jāpievieno atcelšanas iemesls;

Reģistrēt kontroli – darbība ļauj izvēlētajam uzraudzības objektam reģistrēt jaunu plānveida kontroli ar hipersaiti uz kontroles rezultātu ievadi.

DPM-08 Kontrolējamo objektu saraksts - kopsummas (Obligāta)Kontrolējamo objektu saraksta kopsummu sadaļā jāattēlo vismaz šādas kopsummas:

Kopējais Plānā iekļauto uzraudzības objektu skaits;

Skatam atbilstošo gada plānā iekļauto uzraudzības objektu skaits;

Skatam atbilstošo atlasīto objektu skaits (gan gada plānā iekļautie uzraudzības objekti, gan filtram

atbilstošie uzraudzības objekti).

Kopsummas var tikt precizētas sistēmas izstrādes laikā.

DPM-09 Kontrolējamo objektu pārskats (Obligāta)Kontrolējamo objektu pārskats satur kontrolējamo objektu kopsummas norādītajā griezumā. Kontrolējamo

objektu pārskata ekrānformai jāsastāv no šādām sadaļām:

Pamatinformācija – kontroles pasākumu plāna gads un statuss;

Griezums – griezums, kurā attēlojamas kontrolējamo objektu sarakstā iekļauto uzraudzības objektu

kopsummas. Jābūt vismaz šādiem griezumiem:

Objekta klase; VI struktūrvienība; Darbības veids.

Pārskats – saraksts ar kontrolējamo objektu sarakstā iekļauto uzraudzības objektu kopsummām

noteiktajā griezumā. Pārskats satur vismaz šādas kolonnas:

Klase / Struktūrvienība / Darbības veids – atbilstoši norādītajam griezumam objekta klases nosaukums, VI struktūrvienības nosaukums vai darbības veida nosaukums;

17



Kopā – kopējais objekta klasei, VI struktūrvienībai vai darbības veidam atbilstošo objektu skaits; Plānots – kontrolējamo objektu sarakstā iekļauto uzraudzības objektu skaits, kas atbilst rindā

norādītajai objekta klasei, VI struktūrvienībai vai darbības veidam. Kopsummas – kontrolējamo objektu sarakstā iekļauto uzraudzības objektu kopskaits dalījumā pa

uzraudzības statusiem.

Pārskata sadaļas var tikt precizētas sistēmas izstrādes laikā.

DPM-10 Plāna izpildes atskaites (Obligāta)Plānošanas modulim jānodrošina informācija par gada plāna izpildes statusu atskaišu veidā. Jābūt iespējai

pārliecināties par gada plāna izpildes statusu un procentuālo progresu gan VI struktūrvienību, gan darbības

veidu, gan uzraudzības objektu klašu griezumā. Visos griezumos informācijai jābūt grupētai gan pa

mēnešiem, gan pa ceturkšņiem.

3.3. Ekspertīžu modulis

VUIS jāpapildina ar ekspertīžu moduli, kurš ļauj fiksēt ekspertīzes rezultātā iegūto informāciju, sasaistīt

ekspertīzi ar uzraudzības objektiem un ekspertīzē iesaistītajiem speciālistiem. Ekspertīžu rezultāti fiksējami

atskaites lapās līdzīgi kā kontroles rezultāti kontroles aktos.

EKM-01 Atskaites lapas (Obligāta)VUIS ekspertīžu modulī jānodrošina iespēja reģistrēt atskaites lapas par veiktajām ekspertīzēm. Atskaites

lapas jāvar reģistrēt uz darba uzdevumu pamata, kas tiek izveidoti uz iesniegumu un notikumu pamata.

Reģistrējot atskaites lapas, nepieciešams nodrošināt automātisku uzraudzības objektu un iesaistīto

ekspertu informācijas pārņemšanu no darba uzdevuma un saistītā iesnieguma vai notikuma.

Jābūt iespējai atskaites lapām piesaistīt un atsaistīt saistītos uzraudzības objektus, kā arī piesaistīt un

atsaistīt ekspertīzē iesaistītos VI speciālistus. Veidojot atskaites lapu no darba uzdevuma automātiski

jāpārņem informācija par darba uzdevumam piesaistītajiem uzraudzības objektiem un VI speciālistiem.

Atskaites lapā jābūt iespējai norādīt būtiskāko informāciju par veikto ekspertīzi, tai skaitā:

Ekspertīzes rezultātu – brīvā teksta formā;

Piezīmes – brīvā teksta formā;

Ekspertīzes pagarinājumus – atzīme;

Darbnespējas pamatotību – atzīme par to vai darbnespēja noteikta pamatoti.

Atskaites lapām jāuztur ekspertīzes statusa lauks, lai varētu izsekot ekspertīžu progresam.

18



EKM-02 Atskaites lapas – pārkāpumi (Obligāta)VUIS jānodrošina iespēja atskaites lapā pie katra piesaistītā uzraudzības objekta fiksēt informāciju par

konstatētajiem pārkāpumiem, tai skaitā:

Pārkāpuma aprakstu – tekstu brīvā formā;

Izdarītā pārkāpuma veidu – klasificētu vērtību (piemēram, darbnespējas ekspertīzes pārkāpumi,

veselības aprūpes pārkāpumi);

Veicamos darbus – tekstu brīvā formā;

Izpildes termiņu – datumu;

Normatīvo aktu pārkāpums – atzīme;

Normatīvo aktu punkts – izvēle no saraksta ar normatīvajiem aktiem un punkts brīvā teksta formā.

EKM-03 Ekspertīžu saraksts (Obligāta)VUIS ekspertīžu modulī jāizveido ekspertīžu saraksts. Ekspertīžu sarakstā tiek attēlota informācija no

reģistrētajām atskaites lapām, saistītajiem iesniegumiem, notikumiem un darba uzdevumiem. Ekspertīžu

saraksta ierakstiem jāattēlo vismaz šādi dati:

Galvenais eksperts (sistēmas lietotājs);

Ekspertīzes termiņš (datums);

Saite uz ekspertīzes slēdziena dokumentu (dokumenta identifikators lietvedības sistēmā DocLogix).

EKM-04 Atskaites par veiktajām ekspertīzēm (Obligāta)VUIS jāpapildina ar iespēju veidot atskaites par veiktajām ekspertīzēm. Atskaitēs attēlojami visi ekspertīzi

raksturojošie dati, tai skaitā no saistītajiem iesniegumiem, notikumiem un darba uzdevumiem.

3.4. Laboratoriju izmeklējumu modulis

VUIS jāpapildina ar laboratoriju izmeklējumu moduli, kurš atbilst šajā nodaļā aprakstītajām prasībām.

LIM-01 Monitoringa programmu uzturēšana (Obligāta)Laboratoriju izmeklējumu modulī jāuztur informācija par pa publiskajiem ūdensvadiem patērētājiem

piegādātā dzeramā ūdens izmeklējumu rezultātiem, kas iegūti, veicot dzeramā ūdens kvalitātes

monitoringu. Dati tiek izmantoti gatavojot pārskatus par dzeramā ūdens kvalitāti valstī.

Laboratoriju izmeklējumu modulī jābūt iespējai izveidot, apskatīt, rediģēt, dzēst un anulēt dzeramā ūdens

auditmonitoringa programmas (ko veic Veselības inspekcija) MK Nr.235 izpratnē. Katrai auditmonitoringa

programmai ir nosaukums, apraksts un saraksts ar monitoringa programmas ietvaros pārbaudāmajiem

rādītājiem. Katram rādītājam tiek fiksēts nosaukums, mērvienība, minimālā pieļaujamā vērtība, maksimālā

19



pieļaujamā vērtība. Dzeramā ūdens auditmonitoringa programmas jāpiesaista attiecīgajai dzeramā ūdens

apgādes sistēmai Objektu reģistrā.

Auditmonitoringa programmas, līdz brīdim kamēr tām nav pievienots neviens testēšanas pārskats ir

dzēšamas. Ja monitoringa programmai ir pievienots kāds testēšanas pārskats, tad tā ir tikai anulējama, kas

nozīmē, ka tai vairs nav iespējams pievienot jaunus testēšanas pārskatus. Anulēšanas darbībai ir jābūt

atceļamai.

Jāspēj pievienot kārtējā monitoringa (ko veic ūdensapgādes uzņēmums) programmas MK Nr.235 izpratnē

vismaz pievienoto failu (nezinu, vai tā ir pareizi nosaukt specifikācijā) veidā. Iesniegtās kārtējā monitoringa

programmas jāpiesaista attiecīgajai dzeramā ūdens apgādes sistēmai Objektu reģistrā.

Uzraudzības objektiem jāspēj pievienot ūdensapgādes sistēmu raksturojošās vērtības (vismaz – apjoms,

patērētāji, koordinātes), kas sasaistāmas gan ar monitoringa programmām un izgūstamas pārskatos, gan ar

attiecīgo dzeramā ūdens apgādes sistēmu Objektu reģistrā.

LIM-02 Testēšanas pārskatu uzturēšana (Obligāta)Laboratoriju izmeklējumu modulī VUIS lietotājiem jābūt iespējai pievienot, apskatīt, rediģēt un anulēt

testēšanas pārskatus. Izstrādes 2.kārtas ietvaros pārskatus jāvar pievienot gan manuāli, gan automātiski e-

pakalpojuma „Dzeramā ūdens testēšanas pārskatu iesniegšana” ietvaros. Testēšanas pārskatu uzturēšanas

funkcionalitāte plānojama un veidojama tā, lai nākamajās izstrādes kārtās nerastos šķēršļi to papildināt ar

automātisku pārskatu ielādi no laboratorijām.

Testēšanas pārskati sastāv no pārskata vispārīgajiem datiem, laboratorijas mērījumu (rādītāju) datiem un

tie ir piesaistīti kādai no monitoringa programmām. Jābūt iespējai testēšanas pārskatus piesaistīt

uzraudzības objektiem.

Testēšanas pārskata vispārīgo datu kopu veido monitoringa programmas nosaukums, uzraudzības objekta

nosaukums, paraugu ņemšanas adrese, parauga ņemšanas datums, laboratorijas nosaukums, informācija

par parauga ņemšanas vietu, un citi analīzes laikā precizējami parametri.

Testēšanas pārskata ietvaros jābūt iespējai reģistrēt rezultātu vērtības visiem monitoringa programmā

paredzētajiem rādītājiem. Sistēmai automātiski jānosaka vai rādītāja vērtība ir atbilstoša monitoringa

programmā izvirzītajiem rādītājiem vai nē.

LIM-03 Testēšanas rezultātu analīzes iespējas (Obligāta)VUIS jābūt pieejamam ievadīto testēšanas pārskatu sarakstam, kur saraksta līmenī redzama būtiskākā

pārskata informācija, tai skaitā monitoringa programmas kritērijiem neatbilstošo rādītāju skaits un

skaitliskās vērtības.. Sarakstam jābūt kārtojamam un filtrējamam pēc katras no kolonnām.

Jābūt iespējai eksportēt gan testēšanas pārskatu sarakstu, gan visos testēšanas pārskatos reģistrēto

rādītāju vērtību sarakstu uz MS Excel tipa datnēm.

20



LIM-04 Datu un funkcionalitātes migrācija no DZUMON (Obligāta)Migrēt esošos DZUMON datus un datu ievades funkcionalitāti uz VUIS Laboratoriju izmeklējumu moduli.

3.5. E-pakalpojumi

Šajā nodaļā aprakstītas prasības jauni veidojamajiem VUIS e-pakalpojumiem.

EPK-01 Dzeramā ūdens testēšanas pārskatu iesniegšana (Obligāta)Iespēja ievadīt dzeramā ūdens testēšanas rezultātus elektroniskā veidā un ūdensapgādes sistēmu

raksturojošās vērtības. Reizē ar šo pakalpojumu nepieciešams veidot Laboratorisko mērījumu moduli, kurā

glabājami laboratorisko mērījumu rezultāti. E-pakalpojuma process detalizētāk aprakstīts dokumentā

„Vienotās uzraudzības informācijas sistēmas attīstības plāns”.

EPK-02 Aktuālais stāvoklis uzraudzības objektā (Obligāta)Iespēja uzņēmuma pārstāvim iegūt informāciju par stāvokli uzņēmuma uzraudzības objektos. Informācijai

būtu jāiekļauj kontroļu datumi, konstatētās neatbilstības, neatbilstību novēršanas statusi, uzdotie

uzdevumi un sastādītie administratīvie akti. E-pakalpojuma process detalizētāk aprakstīts dokumentā

„Vienotās uzraudzības informācijas sistēmas attīstības plāns”.

3.6. Integrācijas papildinājumi

Šajā sadaļā aprakstītas prasības VUIS starpsistēmu datu apmaiņas papildinājumiem.

INT-01 ĀIR datu ielāde no VVIS Integrācijas platformas (Obligāta)Šobrīd VUIS dati no ĀIR tiek nodoti MS Excel datņu veidā. Šie dati tiek izmantoti VI uzraugāmo objektu

reģistra papildināšanai un atjaunināšanai. Šī datu apmaiņa ir jāautomatizē, ĀIR datus iegūstot no VVIS IP

klasifikatoru reģistra.

INT-02 ĀPR datu ielāde no VVIS Integrācijas platformas (Vēlama)Nepieciešams papildināt VUIS ar automātisku ārstniecības personu datu ielādi no ĀPR izmantojot VVIS IP

klasifikatoru reģistru. Dati par ārstniecības personām pievienojami pie uzraudzības objektiem kā jauna

informatīvā sadaļa.

INT-03 Izglītības iestāžu datu automatizēta ielāde (Obligāta)Šobrīd VUIS datus no IZM VIIS saņem MS Excel datņu veidā. Šie dati tiek izmantoti VI uzraugāmo objektu

reģistra papildināšanai un atjaunināšanai. Nepieciešams šo datu apmaiņu automatizēt, izglītības iestāžu

datus iegūstot no VVIS IP klasifikatoru reģistra vai IZM VIIS.

21



INT-04 Farmaceitiskās darbības uzņēmumu datu ielāde (Obligāta)Šobrīd VUIS farmaceitiskās darbības uzņēmumu licencēšanas informāciju no ZVA IS saņem MS Excel datņu

veidā. Šie dati tiek izmantoti VI uzraugāmo objektu reģistra papildināšanai un atjaunināšanai. Jānodrošina

ZVA IS klasifikatoru datu saņemšana, izmantojot VVIS IP datu apmaiņas mehānismu līdzšinējās datņu

apmaiņas vietā.

INT-05 Valsts adrešu reģistra datu ielāde (Vēlama)Jāizstrādā regulāra un automatizēta VZD Valsts adrešu reģistra datu ielāde no VVIS IP klasifikatoru reģistra.

INT-06 Integrācija ar DocLogix (Obligāta)Jānodrošina VUIS integrācija ar VI DocLogix sistēmu. No DocLogix uz VUIS jānodod informācija par

reģistrētajiem iesniegumiem, kā arī informācija par atbildes vēstulēm un apstrīdējumiem uz lēmumiem, kas

pieņemti izskatot reģistrētos iesniegumus.

INT-07 Datu saņemšana no dzeramā ūdens testu laboratorijām (Vēlama)Jāizstrādā datu apmaiņas saskarnes automatizētai ūdens testēšanas pārskatu saņemšanai no ūdens

paraugu testēšanas laboratorijām.

3.7. Citi funkcionālie papildinājumi

3.7.1. Iesniegumi

VUIS jāpapildina ar iespēju reģistrēt un apstrādāt iesniegumus. Iesniegumi sākotnēji tiek importēti no VI

DocLogix sistēmas. Tālāk VUIS lietotāji apstiprina šo iesniegumu reģistrēšanu VUIS, pievieno tiem papildus

informāciju un uz to pamata veido darba uzdevumus, kas tālāk rezultējās uzraudzības objektu kontrolēs vai

ekspertīzēs.

CFP-01 Iesniegumu saņemšana (Obligāta)VUIS jānodrošina DocLogix sistēmā reģistrēto iesniegumu imports un apstrāde. Importējami ir tādi

iesniegumi, kuriem DocLogix sistēmā norādīts atbildīgais VI darbinieks un izskatīšanas termiņš. Importējot

iesniegumus no DocLogix jāpārnes vismaz šādi dati:

Iesniedzējs;

Iesniegumā norādītais datums;

Iesnieguma saņemšanas datums;

Īss iesnieguma apraksts;

Izskatīšanas termiņš.

22



CFP-02 Iesniegumu apstrāde (Obligāta)VUIS lietotājiem jānodrošina iespēja apstrādāt importētos iesniegumus. VUIS lietotājiem jānodrošina

sadaļa „mani iesniegumi”, kurā tiktu attēlots konkrētajam VUIS lietotājam deleģēto iesniegumu saraksts no

importētajiem iesniegumiem. Sarakstā par iesniegumu būtu jāattēlo vismaz šāda informācija:

iesnieguma numurs;

iesnieguma statuss (piemēram, uzsākta reģistrācija, izveidots kontroles/darba uzdevums, atsaukts,

u.c.);

izveidoto kontroles/ darba uzdevumu skaits.

Sarakstā attēlojamā informācija un tās ekrānforma ir precizējama sistēmas izstrādes laikā.

Sarakstā jābūt iespējai meklēt iesniegumu pēc DocLogix piešķirtā iesnieguma numura.

VUIS darbiniekam jābūt iespējai no saraksta izvēlēties jebkuru iesniegumu un apstiprināt iesnieguma

reģistrāciju VUIS. Apstiprinot iesnieguma reģistrāciju tiek atvērta iesnieguma reģistrācijas forma.

Iesnieguma reģistrācijas formai jāsatur visi no DocLogix importētie dati rediģējamā formā, kā arī šādi

papildus datu lauki:

Iesnieguma subjekts – fiziska persona, juridiska persona vai cits (pēc noklusējuma no DocLogix

saņemtais iesnieguma iesniedzējs). Norādītās vērtības ir saglabājamas kontaktu sarakstā un jābūt

iespējai tās atkārtoti ievadīt izmangojot “auto-complete” tipa funkcionalitāti. Fiziskai personai

norādāms vārds, uzvārds un personas kods, juridiskai personai nosaukums un variantam “cits” teksts

brīvā formā;

Iesnieguma būtība – klasificēta vērtība (VUIS uzturams klasifikators);

Iesnieguma veids – klasificēta vērtība (“rakstveida”, “elektronisks”, “latvija.lv”);

Iesnieguma joma – klasificēta vērtība (VUIS uzturams klasifikators);

Iesnieguma objekts – fiziska persona, juridiska persona vai uzraudzības objekts. Fizisko un juridisko

personu pievienošanas funkcionalitāte jābūt tādai pašai kā laukam “Iesnieguma subjekts”;

Lietas statuss – klasificēta vērtība („pabeigta”, “nepabeigta”);

Iesnieguma atbilstība VI darbības profilam – klasificēta vērtība („jā”, “nē”, “daļēji”);

Iesnieguma pamatotību – klasificēta vērtība („pamatots”, “nepamatots”, ”cits”);

Veiktās darbības – klasificēta vērtība;

Iesnieguma profils – viena vai vairākas klasificētas vērtības;

Kontroles akta datums un numurs – aizpildās automātiski pēc kontroles veikšanas iesnieguma

izskatīšanai. Var būt vairāki kontroļu datumi. Nodrošināta hipersaite uz attiecīgo kontroles aktu

Piezīmes – teksts brīvā formā;

23



Papildus tam, iesnieguma reģistrācijas un rediģēšanas ekrānformās jābūt iespējai ar iesniegumu veikt šādas

darbības:

Piesaistīt iesniegumam vai atsaistīt no iesnieguma uz iesniegumu attiecināmos uzraudzības objektus;

Izveidot kontroles/darba uzdevumu - kā rezultātā uz ekrāna tiek attēlota kontroles vai darba

uzdevuma elektroniskā forma un VUIS reģistrētais iesniegums automātiski tiek piesaistīts šim

uzdevumam. Vienam iesniegumam jābūt iespējai pievienot vairākus kontroles / darba uzdevumus;

Pēc kontroles pabeigšanas (kontroles akta apstiprināšanas) kontroles akta datums un numurs tiek

nodoti iesnieguma reģistrācijas formai.

Veikt atzīmi par atbildes vēstules nosūtīšanu un pēc izēles norādīt saiti uz atbilstošo DocLogix

ierakstu;

Veikt atzīmi, ka iesniegums atsaukts.

CFP-03 Iesniegumu monitorings (Obligāta)Nepieciešams nodrošināt, lai brīdī, kad persona DocLogix sistēmā pie iesnieguma izvēlas opciju „uzdevums

izpildīts”, attiecīgais iesniegums vairs netiek rādīts VUIS nereģistrēto iesniegumu sarakstā vai ja tas ir

reģistrēts, tam nomainītos statuss uz atbilstošo.

3.7.2. Notikumi

VUIS jāpapildina ar iespēju reģistrēt notikumu (telefona zvanu, e-pastu, u.tml.) reģistrēšanu un apriti.

CFP-04 Notikumu reģistrēšana un apstrāde (Vēlama)VUIS jāiestrādā iespēja reģistrēt datus par notikumiem (saņemtajiem iesniegumiem, telefona zvaniem,

veiktajiem novērojumiem, u.c.). Katru notikumu jāvar piesaistīt vienam vai vairākiem uzraudzības

objektiem. Par katru notikumu norādāma vismaz šāda informācija:

Notikuma veids – klasificēta vērtība;

Notikuma apraksts – teksts brīvā formā;

Piezīmes – teksts brīvā formā.

VUIS jābūt iespējai uz notikuma pamata izveidot vienu vai vairākus darba un/vai kontroles uzdevumus.

3.7.3. Darba uzdevumi

VUIS jāpapildina ar iespēju reģistrēt un apstrādāt darba uzdevumus.

CFP-05 Darba uzdevumi (Obligāta)VUIS jāpapildina ar iespēju uz iesniegumu vai notikumu pamata reģistrēt darba uzdevumus. Darba

uzdevumam jābūt iespējai norādīt:

24



VUIS lietotājs – darbinieks, kas izskatīs iesniegumu vai notikumu;

Termiņš – datums līdz kuram darba uzdevums paveicams;

Paredzamais darba apjoms – viena vai vairākas klasificētas vērtības (piemēram, “atbildes vēstules

sagatavošana”, “ekspertīze”;

VUIS lietotājiem ar atbilstošām tiesībām jābūt iespējai darba uzdevumus deleģēt citiem VUIS lietotājiem.

Jābūt iespējai uz darba uzdevuma pamata reģistrēt ekspertīzi.

3.7.4. Administratīvie akti

VUIS jāpapildina ar šādiem administratīvo aktu funkcionalitātes uzlabojumiem.

CFP-06 Administratīvā akta reģistrācija un rediģēšana (Obligāta)VUIS jābūt iespējai reģistrēt un rediģēt administratīvo aktu. Jābūt iespējai administratīvos aktus izveidot

gan uz kontroles akta pamata, gan bez piesaiste kontroles aktam.

Administratīvajam aktam jābūt iespējai norādīt vai tā ir atbildes vēstule vai lēmums. Atbildes vēstulei

reģistrējami šādi dati:

Sagatavošanas datums – datums;

Būtība – brīvs teksta lauks;

Sagatavotājs – VI darbinieks (pēc noklusējuma aktīvais VUIS lietotājs).

Ja administratīvais akts ir lēmums, tad norādāmi šādi dati:

Lēmuma numurs;

Lēmuma veids – klasificēta vērtība (VUIS uzturams klasifikators);

Līguma veids – klasificēta vērtība (VUIS uzturams klasifikators);

Informācija par pārbaudi, tai skaitā - pārbaudes veids, apjoms, atbildīgie inspektori par pārbaudes

veikšanu, pārbaudītā dokumentācija, konstatētie pārkāpumi un attiecīgie uzdotie darbi to

novēršanai. Ja lēmums tiek reģistrēts uz kontroles akta pamata, šī informācija ņemama no kontroles

akta.

Informācija par pārkāpumiem:

Pārkāpuma būtība – teksts brīvā formā; piemērotās sankcijas – klasificēta vērtība (VUIS uzturams klasifikators); piemērotais soda apmērs – skaitliska vērtība; veiktais ieturējums – skaitliska vērtība; pacientam atmaksātā summa – skaitliska vērtība;

Lēmuma pieņemšanas datums – datums.

25



CFP-07 Apstrīdēšanas informācijas saņemšana (Obligāta)VUIS nepieciešams papildināt ar funkcionalitāti, kas nodrošina informācijas saņemšanu no DocLogix par

saņemtajiem administratīvo aktu apstrīdējumiem vai atbildes vēstulēm uz iepriekš nosūtītām atbildes

vēstulēm par apstrīdēšanu. Šī informācija fiksējama pie atbilstošā administratīvā akta.

CFP-08 Apstrīdēšanas lēmuma dati (Obligāta)VUIS nepieciešams papildināt ar iespēju VI juridiskās nodaļas pārstāvjiem apstrīdējumu gadījumos pie

administratīvā akta fiksēt informāciju par pieņemto lēmumu, kas iekļauj:

Pieņemtā lēmuma veidu – klasificēta vērtība;

Pieņemtā lēmuma datumu – datums.

Pievienojamās vērtības precizējas sistēmas izstrādes laikā.

CFP-09 Administratīvo pārkāpumu lietu atskaites (Obligāta)Nepieciešams nodrošināt, lai, sagatavojot APK lietu būtu iespēja izgūt ne tikai kontroles aktu, bet arī

ekspertīzes veikšanas procesa laikā izveidoto atskaites lapu, tādā veidā sasaistot izveidoto APK lietu ar

veikto kontroli un/vai ekspertīzi.

3.7.5. Uzraudzības objektu kontrole

Šajā sadaļā aprakstītas prasības VUIS uzraudzības objektu kontroles funkcionalitātes papildinājumiem.

CFP-09 Papildus datu lauki kontroles aktā (Obligāta)Nepieciešams nodrošināt iespēju, aizpildot kontroles aktu, laukā „kontroles veids” piezīmju sadaļā papildus

iespējai ievadīt tekstu brīvā formā paredzēt arī izvēļu sarakstu, kurā iekļautas biežāk izmantotās atbildes.

Nepieciešams nodrošināt iespēju, aizpildot kontroles aktu, veikt atzīmi „ierosināta administratīvā lieta”.

26



4. NEFUNKCIONĀLĀS PRASĪBASŠajā sadaļā ir aprakstītas VUIS nefunkcionālās prasības. Visas šajā sadaļā minētās prasības ir ietveramas

tehniskā piedāvājuma sagatavošanā un realizējamas Projekta izpildes laikā. Tehniskā piedāvājuma

sagatavošanā Izpildītājam jāievēro VV-01 un VV-02 prasībās noteiktais.

4.1. Veiktspējas prasības

NFP-01 Lietotāju skaits (Obligāta)Sistēmas maksimālais lietotāju skaits ir 200 lietotāji un sistēmu vienlaicīgi lieto līdz 20% lietotāju.

NFP-02 Ekrānformu attēlošanas laiks (Obligāta)Lietotāju datu ievadam vai datu pieprasījumam (izziņai) uz ekrāna ir jāizpildās ne ilgāk kā 3 sekundes

(neņemot vērā tīkla pārsūtīšanas aizturi un pieprasījumu izpildes laiku ārējās sistēmās). Minētā ātrdarbība

jānodrošina ņemot vērā reālu datu bāzes aizpildījumu ražošanas režīmā.

NFP-03 Atskaišu attēlošanas laiks (Obligāta)Atskaites sagatavošanai uz ekrāna ir jāizpildās ne ilgāk kā 15 sekundes (neņemot vērā tīkla pārsūtīšanas

aizturi). Minētā ātrdarbība jānodrošina ņemot vērā reālu datu bāzes aizpildījumu ražošanas režīmā.

NFP-04 Web servisu apstrādes laiks (Obligāta)Sinhrono Web servisu pieprasījumu apstrāde nedrīkst pārsniegt 3 sekundes (netiek ņemts vērā laiks, kas

tiek patērēts ārēju Sistēmas Web servisu izsaukumiem).

4.2. Drošības prasības

NFP-05 Sistēmas drošības principi (Obligāta)Sistēmai jānodrošina, lai tiktu ievēroti šādi drošības principi:

Konfidencialitāte – informācija ir pieejama tikai autorizētiem lietotājiem;

Datu integritāte – informācija ir pasargāta no tīšas vai netīšas neautorizētas modificēšanas;

Pieejamība – informācija un ar to saistītā funkcionalitāte ir pieejama noteiktā apjomā, laikā un vietā;

Autentiskums – informācijas izcelsme ir pierādāma, sistēma var uzticēties, ka identitāte ir patiesa;

Atbildība – katru darbību ar informāciju ir jāsasaista ar tās veicēju.

27



NFP-06 Autentifikācija un autorizācija (Obligāta)Izstrādes ietvaros jāizmanto sistēmā izstrādātā autentifikācijas un autorizācijas komponente, kas nodrošina

vienotu lietotāju autorizācijas un autentifikācijas mehānismu VUIS ietvaros.

Komponente nodrošina šādas iespējas: lietotāju autorizācija, lietotāju pievienošana un dzēšanu, lietotāju

tiesību pārvaldi.

4.3. Saskarņu un to lietojamības prasības

NFP-07 Web aplikāciju lietotāju saskarne (Obligāta)Sistēmas lietotāja interfeisam jābūt pieejamam izmantojot WEB pārlūkprogrammu (WEB interfeiss).

Interfeisam jānodrošina vismaz šādu populāru pārlūkprogrammu atbalsts:

MS Internet Explorer (8.x – 10.x un jaunākas)

FireFox (19.X un jaunākas)

Opera 10.X

Google Chrome

Pārlūkprogrammās (klienta pusē) atļauts izmantot šādas WEB tehnoloģijas: HTML, CSS, JavaScript, HTML5

paplašinājumus.

NFP-08 Atbalstāmās lietotāju operētājsistēmas (Obligāta)Informācijas sistēmai ir jāatbalsta lietotāju darbs vismaz Windows saimes (Windows XP, Windows Vista,

Windows 7, Windows 8) un Linux saimes operāciju sistēmās.

NFP-09 Lietotāju saskarnes lietojamība (Obligāta)Izstrādājamās informācijas sistēmas interfeiss ir jāveido latviešu valodā.

Sistēmas lietotāju interfeisu jāveido ņemot vērā rekomendācijas, ko izvirza W3C Web Content Accessibility

Guidelines.

Lietotāja interfeisam ir jābūt orientētam uz lietotāju:

Lietotāja ekrānos ir jāizmanto lietotājam saprotama terminoloģija;

Lietotāja ekrānos jāizmanto vieni un tie paši termini vienas un tās pašas informācijas apzīmēšanai;

Lietotājam jābūt iespēja brīvi pārslēgties starp sistēmas datu objektiem. Lietotāja ekrānformās, kur ir

atsauces uz datu objektiem, kam ir pašiem savas apsakates ekrānformas, jābūt iespējai klikšķinot uz

objekta atvērt atbilstošo apskates ekrānformu;

Pēc iespējas jāsamazina ekrāna formu un atskaišu sarežģītība;

Datu ievada un apstrādes secībai ir jāatbilst tipiska lietotāja darba procesam;

28



Visos gadījumos ir jābūt skaidri norādītai konkrētai darbībai, kuru veic lietotājs, kā arī skaidri

saprotamas norādes, kā pārtraukt vai pabeigt iesākto darbību;

Ja lietotāja darbība ir daļa no lielāka sistēmā realizējam procesa lietotājam, ir jābūt pieejamai

informācijai par procesu (iespējamais variants: palīdzības (HELP) sastāvdaļa) un konkrētās darbības

vietai procesā;

Kļūdu un ārkārtas situāciju aprakstiem ir jābūt skaidriem un lietotājam saprotamiem, tieši norādot,

kāda darbība tiek sagaidīta no lietotāja.

4.4. Prasības tehniskajai infrastruktūrai un standarta

programmatūrai

NFP-10 Infrastruktūras prasības (Obligāta)Sistēmai jādarbojas uz VI nodrošinātās infrastruktūras platformas, kuras detalizēts apraksts ir sniegts

dokumenta Vienotās uzraudzības informācijas sistēmas vienotā arhitektūra 5.nodaļā.

Ja Sistēmas darbības nodrošināšanai ir nepieciešama papildus infrastruktūra, tad Izpildītājam Tehniskajā

piedāvājumā ir jāiekļauj visu infrastruktūras papildu elementu apraksti (tostarp jānorāda, kā tiks

nodrošināta saderība ar VI rīcībā esošo infrastruktūru un kā notiks papildu elementu apkalpošana) un to

izmaksas jānorāda Finanšu piedāvājumā. Prasība attiecināma gan uz tehnisko infrastruktūru, gan standarta

programmatūru.

Ja Izpildītājs piegādā tehnisko infrastruktūru un/vai standarta programmatūru, garantijas laiks piegādātajai

programmatūrai un aparatūrai ir 3 gadi, un šajā laikā jānodrošina šāda garantijas pakalpojuma sniegšana:

1) Garantija saskaņā ar ministru kabineta noteikumu Nr.766 „Noteikumi par darbības programmas

"Infrastruktūra un pakalpojumi" papildinājuma 3.2.2.1.1.apakšaktivitātes "Informācijas sistēmu un

elektronisko pakalpojumu attīstība" projektu iesniegumu atlases otro, trešo, ceturto un piekto kārtu”

punktu 57.4 „Preču un pakalpojumu sniegšanas garantiju iekļauj līguma priekšmeta cenā un atsevišķi

neizdala kā izmaksu pozīciju. Minēto garantiju paredz, lai novērstu līguma priekšmeta neatbilstības, kas

radušās ražotāja vai pakalpojuma sniedzēja vainas dēļ, un tās sniegšanas termiņš nepārsniedz piecus gadus

pēc projekta īstenošanas.”

2) Problēmu pieteikuma gadījumā reakcijas laiks ne vēlāk kā 8 (astoņas) stundas darba dienā;

3) Bojājumu novēršanas laiks garantijas ietvarā ir ne vēlāk kā 2 (divas) darba dienu laikā no bojājumu

pieteikšanas brīža.

29



NFP-11 Sistēmas darba vides (Obligāta)Vides, kas nepieciešamas Izpildītājam izstrādei un garantijs nodrošināšanai, nodrošina pats Izpildītājs (t.sk.

izstrādei vai attīstībai izmantojamo rīku licences, testēšanai izmantojamo produktu licences u.tml.),

savukārt Sistēmas ekspluatācijas vidi un akcepttestēšanas vidi nodrošina VI.

4.5. Sistēmas darbības nepārtrauktības prasības

NFP-12 Darbības nepārtrauktība (Obligāta)VUIS ir jānodrošina nepārtraukta pieejamība lietotājiem 24 stundas diennaktī un 7 dienas nedēļā. VUIS

darbspējas laikam jābūt ne mazākam kā 98% gada laikā (plānotās dīkstāves neskaitot), katras dīkstāves

maksimālajam laikam nepārsniedzot vienu dienu. Prasība nav attiecināma uz VUIS darbības

pārtraukumiem, kas radušies tehniskās infrastruktūras bojājumu rezultātā.

NFP-13 Rezerves kopēšana (Obligāta)Sistēmai jānodrošina iespēja veikt VUIS rezerves kopēšanu un konsistentas kopijas iegūšanu bez VUIS darba

apturēšanas. Ja Sistēmas rezerves kopēšanai nepieciešama IS un/vai infrastruktūras komponenšu

darbināšana speciālā režīmā, tad šāda speciāla režīma ieslēgšana/izslēgšana jānodrošina ar komandrindas

saskarnes palīdzību.

Izmantojamām komponentēm (datu bāzei, pielietojumu serverim) ir jānodrošina iespēja veidot

rezervēšanas politiku pamatojoties uz Sistēmas turētāja noteikto atjaunošanas laiku (piemēram,

atjaunošana ne ilgāka kā 2h).

30



5. ORGANIZATORISKĀS PRASĪBASŠajā sadaļā ir aprakstītas VUIS organizatoriskās prasības. Visas šajā sadaļā minētās prasības ir ietveramas

tehniskā piedāvājuma sagatavošanā un realizējamas Projekta izpildes laikā. Tehniskā piedāvājuma

sagatavošanā Izpildītājam jāievēro VV-01 un VV-02 prasībās noteiktais.

5.1. Laika grafiks

ORG-01 Izstrādes un ieviešanas laika grafiks (Obligāta)Izpildītājam ir jāiesniedz aktivitāšu laika plāns, kurā detalizēti ir norādīti visi veicamo darbu etapi, ņemtas

vērā Izpildītāja resursu un citu piedāvājumā izklāstīto aspektu ietekme uz Projekta izpildi. Laika plānā

jānorāda visu iesaistīto speciālistu paredzētais darba apjoms stundās.

Projekta visu darbu izpilde jāveic ne vēlāk kā līdz ERAF projekta beigu termiņam - 2015.gada 28.jūnijam. Ja

ERAF projekts tiek pagarināts, tad saskaņā ar Izstrādes līguma nosacījumiem var tikt precizēts izpildes

termiņš.

5.2. Metodoloģijas

ORG-02 Projekta vadības metodika (Obligāta)Izpildītājam ir jāpiedāvā un Projekta laikā jānodrošina sistēmas izstrādes vadība, kas ir balstīta uz

starptautiski pieņemtas projekta vadības metodoloģijas, piemēram, RUP (Rational Unified Process), Oracle

CDM (Custom Development Method), DSDM (Dynamic Systems Development Method), MSF (Microsoft

Solution Framework).

ORG-03 Izstrādes standarti un metodes (Obligāta)Izpildītājam jāizmanto dokumentēti izstrādes standarti un metodes visām izstrādes aktivitātēm un

nodevumiem. Standarti un metodes jāapraksta vai jānorāda atsauces uz atbilstošiem dokumentiem

„Projekta pārvaldības plānā” (ORG-04).

ORG-04 Projekta pārvaldības plāns (Obligāta)Projekta pārvaldības plāns Izpildītājam jāizstrādā un jāiesniedz saskaņošanai Pasūtītājam 10 darba dienu

laikā no Projekta Izstrādes līguma parakstīšanas dienas. Projekta pārvaldības plānam jābūt izstrādātam

atbilstoši Izpildītāja piedāvātajai projekta vadības metodoloģijai, un tajā jāiekļauj vismaz šādas sadaļas:

Projekta organizācija;

Pārvaldības process;

Kalendārais plāns (nodevumu secība, savstarpējā saistība un piegādes termiņi);

31



Kvalitātes vadība;

Konfigurācijas vadība;

Risku vadība;

Izmaiņu vadība.

Projekta pārvaldības plāns Izpildītājam ir jāaktualizē un jāiesniedz saskaņošanai Pasūtītājam, ja Projektā

notiek izmaiņas.

ORG-05 Kvalitātes vadībaIzpildītājam jāveic nepieciešamie pasākumi, lai nodrošinātu projekta kvalitātes vadību atbilstoši labās

prakses principiem, t.sk.:

ar ieviešanas un izstrādes, pielāgošanas procesu tieši nesaistīta kvalitātes pārvaldnieka iesaistīšana

Projekta organizatoriskajā struktūrā un regulāra ziņojumu iesniegšana Projekta vadības grupai par

Projekta gaitu;

pirms visu dokumentu nodevumu izstrādes uzsākšanas Izpildītājam jāsaskaņo dokumentu nodevumu

sagataves ar Pasūtītāju;

Izpildītāja iekšēja nodevumu kvalitātes novērtēšana jāveic pirms nodevumu iesniegšanas Pasūtītājam

(visiem dokumentiem un tajos aprakstītajai informācijai jābūt viennozīmīgai, nepretrunīgai un

pabeigtai, savukārt programmatūrai jābūt dokumentētai un izstrādātai saskaņā ar saskaņotām

kodēšanas vadlīnijām);

nodevumi savlaicīgi jāiesniedz Pasūtītājam saskaņošanai;

jāveic savlaicīga un regulāra projekta risku identificēšana un eskalācija.

Izpildītājam Projekta pārvaldības plānā jāapraksta piedāvātā pieeja Projekta kvalitātes vadības

nodrošināšanai.

ORG-06 Konfigurācijas vadībaSistēmas izstrādes gaitā visām konfigurācijas vienībām un to versijām ir jābūt identificētām, visām

izmaiņām trasējamām un sasaistāmām ar konkrētiem darba uzdevumiem un atbildīgajiem.

Jaunām nodevumu versijām (gan dokumentiem, gan Sistēmai) jātiek piegādātām atsevišķi, pievienojot

izmaiņu vēsturi.

Izpildītājam Projekta pārvaldības plānā jāapraksta piedāvātā pieeja Projekta konfigurācijas vadības

nodrošināšanai.

32



ORG-07 Izmaiņu vadībaIzpildītājam jāpiedāvā projekta izmaiņu vadības modelis, kas paredz vairāku līmeņu projekta izmaiņu

izskatīšanu un eskalāciju atbilstoši izmaiņu nozīmīgumam un ietekmei uz projekta darbaspēka un finanšu

resursiem, kā arī uz projekta gaitā veicamo darbu apjomu.

Izpildītājam Projekta pārvaldības plānā jāapraksta piedāvātā pieeja Projekta izmaiņu vadības

nodrošināšanai.

ORG-08 Finanšu vadībaIzpildītājam jāpiedāvā metodoloģija, kāda tiks izmantota Līgumā ietverto darbu izmaksu sadalījumam,

izrakstot rēķinu Pasūtītājam, lai nodrošinātu MK noteikumu Nr.766 16.-22.punkta prasību ievērošanu

izmaksu pozīcijām.

5.3. Komunikācijas vadība

ORG-09 Projekta darba valoda (Obligāta)Projekta darba valoda ir latviešu valoda. Izpildītājam dokumentētie nodevumi jāizstrādā latviešu valodā.

Ja Projekta laikā tiek piesaistīti speciālisti, kuri nepārvalda latviešu valodu, Izpildītājam šo speciālistu saziņā

ar Pasūtītāju jānodrošina tulkošana bez papildu maksas.

ORG-10 Interviju un sanāksmju protokolēšana (Obligāta)Izpildītājam ir jāveic visu interviju un sanāksmju protokolēšana, iesniedzot protokolus saskaņošanai

Pasūtītājam 3 darba dienu laikā pēc intervijas vai sanāksmes. Pēc Pasūtītāja komentāru saņemšanas,

protokoli jāprecizē 1 darba dienas laikā un jānosūta atkārtotai saskaņošanai Pasūtītājam.

ORG-11 Progresa ziņojumi (Obligāta)Izpildītājam jāsagatavo un elektroniski jāiesniedz Pasūtītājam šādi progresa ziņojumi :

Iknedēļas progresa ziņojums Projekta vadības grupai par uzsāktajiem un plānotajiem darbiem,

atvērtajiem jautājumiem un uzdevumiem. Izpildītājs ziņojumu iesniedz Pasūtītāja Projekta vadītājam

ne vēlāk kā katras pirmdienas pl.10.00.

Ikmēneša progresa ziņojums Projekta uzraudzības komitejai par Projekta uzdevumu izpildes

progresu, sasniegtajiem robežstabiem, atvērtajiem riskiem/problēmām un nepieciešamajiem

lēmumiem. Ziņojums jāiesniedz Pasūtītāja Projekta vadītājam ne vēlāk kā 2 (divas) darba dienas

pirms plānotās Projekta uzraudzības komitejas sēdes, kurā ziņojums saskaņojams.

ORG-12 Sanāksmes (Obligāta)Izpildītājam jāorganizē šādas sanāksmes (Pasūtītāja norādītajā vietā, Rīgas administratīvajā teritorijā):

33



Projekta uzsākšanas sanāksme – 2 darba dienu laikā pēc Izstrādes līguma par Projekta īstenošanu

parakstīšanas. Projekta uzsākšanas sanāksmē Izpildītājs iepazīstina ar Izstrādes līguma izpildes plānu

(t.sk. tuvākos plānotos darbus un iespējamo risku tabulu);

Projekta uzraudzības komitejas sanāksmes – ne retāk kā 1 reizi mēnesī, ja puses nevienojas citādi;

Projekta vadības grupas sanāksmes – ne retāk kā 1 reizi nedēļā, ja puses nevienojas citādi;

Projekta darba grupu sanāksmes – pēc nepieciešamības;

Projekta noslēguma sanāksme – 2 darba dienu laikā pēc gala nodošanas – pieņemšanas akta

parakstīšanas. Projekta noslēguma sanāksmē Izpildītājs informē par Izstrādes līguma ietvaros

paveiktajiem darbiem, atkāpēm no plānotā un turpmākajām attīstības iespējām.

5.4. Nodevumi

ORG-13 Nodevumu formāts (Obligāta)Visiem ar Projektu saistītajiem dokumentiem ir jābūt noformētiem atbilstoši ERAF projektu vizuālajām

vadlīnijām un pieejamiem elektroniskā formā, viennozīmīgi identificētiem un uzglabātiem datorizētā

projekta bibliotēkā, kurā vairāki lietotāji vienlaicīgi var veikt dokumentu izskatīšanu, komentēšanu un

izmaiņu saglabāšanu. Par Projekta bibliotēkas izveidi un uzturēšanu atbild Izpildītājs.

Visiem dokumentiem jābūt sagatavotiem MS Office 2007 vai jaunākas versijas MS Word, MS Excel, MS

PowerPoint, MS Visio, MS Project formātos.

Izpildītājs var iesniegt gala nodevumu dokumentus parakstītus papīra formā vai arī elektroniski, parakstītus

ar drošu elektronisko parakstu.

Pēc Pasūtītāja pieprasījuma Izpildītājam ir jāsagatavo komentāru caurskates tabulas, pamatojoties uz

datorizētajā projekta bibliotēkā pieejamiem dokumentiem un tajos iesniegtiem komentāriem un

labojumiem.

ORG-14 Nodevumu saraksts (Obligāta)Projekta ietvaros Izpildītājam jāsagatavo un jāiesniedz Pasūtītājam vismaz šādi Projekta nodevumi:

Projekta pārvaldības plāns (atbilstoši programmatūras projekta pārvaldības plāna standartam IEEE

1058-1998);

Saskaņotas kodēšanas vadlīnijas atbilstoši izmantojamām tehnoloģijām;

Programmatūras prasību specifikācija, tostarp Sistēmas interfeisu specifikācija (Saskaņā ar standartu

programmatūras prasību specifikācijai IEEE 29148-2011). Programmatūras prasību dokumentam

jāsatur sistēmas lietojuma scenāriji, kas parāda kādā veidā sistēma atbalstīs nodaļā „2.2 VUIS

34



atbalstāmie procesi” uzskaitītos procesus, kā arī prasību trasējamības tabula, kas saistību starp

programmatūras prasību dokumenta prasībām un tehniskās specifikācijas prasībām;

Sistēmas tehniskās arhitektūras apraksts (Saskaņā ar arhitektūras apraksta standartu IEEE 1471-

2000);

Programmatūras projektējuma apraksts (tostarp Datu modelis – ER diagramma un datu bāzes

projektējums, integritātes nosacījumu uzskaitījums un to paredzamā realizācija, Funkcionalitāte,

funkcionalitātes realizācija, atskaišu pieprasījumi utt.) (Saskaņā ar programmatūras projektējuma

apraksta standartu IEEE 1016-2009);

Testēšanas plāns un testu specifikācija (Saskaņā ar programmatūras testu dokumentācijas standartu

IEEE 829-2008);

Testēšanas (kopsavilkuma) pārskats (iekļaujot informāciju par Izpildītāja veiktajiem drošības,

veiktspējas un lietojamības testiem);

Programmatūras versijas apraksts;

Izstrādāto programmatūras risinājumu un gatavās programmatūras pielāgojumu pirmkodi un

konfigurācijas datnes (skripti);

Versijas izveides instrukcijas;

Automātisko testu skripti un testa datu kopas;

Akcepttestēšanas plāns;

Akcepttestēšanas scenāriji;

Administratoru un lietotāju rokasgrāmata (Saskaņā ar standartu programmatūras lietotāju

dokumentācijai IEEE 1063-2001). lietotāju dokumentācijai jāsatur arī lietojuma scenāriji, kas parāda

kā izpildāmi nodaļā „2.2 VUIS atbalstāmie procesi” uzskaitītie procesi;

Apmācību materiāli;

Saskarņu dokumentācija;

Prasību trasējamības tabula;

Kvalitātes plāns (saskaņā ar standartu programmatūras kvalitātei IEEE 730-2002);

Rezerves kopēšanas un darbības atjaunošanas plāns.

ORG-15 Prasību trasējamībaIzstrādes gaitā ir jāizstrādā un jānodod vismaz šādas trasējamības tabulas:

Iepirkuma nolikuma Tehniskās specifikācijas prasības salīdzinājumā ar Prasību specifikācijas

dokumentos noteiktajām prasībām;

Prasību specifikācijas dokumenta prasības salīdzinājumā ar Programmatūras projektējuma aprakstu;

35



Prasību specifikācijas dokumenta prasības salīdzinājumā ar testu scenārijiem.

5.5. Nodevumu pieņemšanas kārtība

ORG-16 Dokumentu iesniegšanas kārtība (Obligāta)Projekta ietvaros nododamie dokumenti tiek sagatavoti un nodoti šādā secībā:

Satura saskaņošana – uzsākot darbu pie dokumenta, Izpildītājs piegādā un saskaņo ar Pasūtītāju katra

nodevuma sagatavi, kurā ir norādīta šāda informācija:

Dokumenta mērķis;

Dokumenta auditorija;

Dokumenta satura rādītājs (virsraksti);

Dokumenta atbilstība standartiem un prasībām.

Dokumenta piegāde – Izpildītājs piegādā aizpildītu dokumentu atbilstoši iepriekš sagatavotajam saturam.

Pasūtītājs var pieprasīt Izpildītājam sniegt prezentāciju par iesniegto dokumentu. Pasūtītājs 12 (divpadsmit)

darba dienu laikā izskata dokumentu un iesniedz Izpildītājam iebildumus, komenārus un papildinājumus

Komentāru caurskates tabulas formā (sagatavi nodrošina Pasūtītājs) vai datorizētā projekta bibliotēkā.

Nākošā dokumenta versija iesniedzama Pasūtītājam ne vēlāk kā 10 darba dienu laikā pēc Komentāru

caurskates tabulas vai informācijas par iebildumu, komentāru un papildinājumu pieejamības datorizētā

projekta bibliotēkā saņemšanas, ja dokuments tiek komentēts pirmo reizi un ne vēlāk kā 5 darba dienu

laikā, ja dokuments tiek komentēts atkārtoti. Dokumenta galīgās versijas piegāde – Izpildītājs piegādā un

Pasūtītājs akceptē dokumentu, kurā novērstas visas Komentāru caurskates tabulas formā vai datorizētā

projekta bibliotēkā uzskaitītās nepilnības. Pasūtītājam ir tiesības dokumentu nepieņemt, ja nav novērstas

visas uzskaitītās nepilnības

Ja nav noteikts citādi, visi dokumenti Izpildītājam ir jāpiegādā elektroniskā formā, latviešu valodā,

sintaktiski un gramatiski pareizi lietojot Pasūtītājam saprotamu un pieņemamu terminoloģiju. Gramatiskas

kļūdas, ja to skaits nepārsniedz vidēji 1 kļūdu uz 1 dokumenta (A4) lapu, nevar būt par iemeslu dokumenta

nepieņemšanai. Šādas kļūdas (arī dokumenta kļūdas, kuras tiek atklātas pēc dokumenta akceptēšanas) tiek

labotas izmantojot problēmu pieteikuma procedūru.

ORG-17 Sistēmas iesniegšanas kārtība (Obligāta)Projekta ietvaros piegādājamās Sistēmas komponentes tiek piegādātas akceptēšanai šādā secībā:

Izpildītājs piegādā Sistēmu kopā ar aizpildītu Sistēmas piegādes veidlapu (sagatavi nodrošina

Pasūtītājs) un dokumentāciju, kas apliecina Izpildītāja testēšanas pabeigšanu (testēšanas

dokumentāciju), un Sistēmas piegādes komplektu, kas sastāv no šādiem nodevumiem:

Programmatūras versijas apraksts;

36



Izstrādāto programmatūras risinājumu un gatavās programmatūras pielāgojumu pirmkodi un konfigurācijas datnes (skripti);

Versijas izveides instrukcija; Automātisko testu skripti un testa datu kopas.

Pasūtītājs veic instalācijas testus, Izpildītājs nodrošina instalācijas atbalstu pēc Pasūtītāja

pieprasījuma. Ja testi ir neveiksmīgi, tālāka akceptēšana tiek pārtraukta;

Pasūtītājs izpilda automātisko testu skriptus. Ja automātisko testu izpilde ir neveiksmīga,

akceptēšana tiek pārtraukta;

Sistēmas akcepttestēšana tiek sākta, kad saskaņotie automātiskie testi ir veiksmīgi izpildīti. Pasūtītājs

vai tā pārstāvji 20 darba dienu laikā veic akcepttestu saskaņā ar Izpildītāja piegādātajiem un iepriekš

saskaņotajiem akcepttesta piemēriem. Ja piegādātais Sistēmas apjoms ir liels, Pusēm vienojoties,

akcepttestēšanas termiņu var pagarināt. Akcepttestēšanas rezultātā Izpildītājs sagatavo

Akcepttestēšanas kopsavilkumu (Pasūtītājs nodrošina sagatavi), pamatojoties uz Pasūtītāja sniegto

informāciju par akcepttestēšanas gaitu.

Sistēma tiek akceptēta, ja akcepttestam netiek konstatētas 1. un 2. līmeņa kļūdas, bet 3. līmeņa kļūdu

skaits nepārsniedz 10. 3. un 4.līmeņa kļūdas tiek fiksētas akceptēšanas protokolā ar noteiktu novēršanas

laiku, kas nedrīkst pārsniegt 20 darba dienas no akceptēšanas brīža.

ORG-18 Akcepttestēšanas protokoli (Obligāta)Akcepttestēšanas protokoliem jāsatur pieraksti par testēšanas laikā veiktajiem testiem saskaņā ar

akcepttesta piemēriem, to rezultātiem un sistēmas atbilstību vai konstatētajiem defektiem (kļūdu vai

pieteikumu numuri).

ORG-19 Akcepttestēšanas laikā atklāto kļūdu novēršana (Obligāta)Konstatējot 1.prioritātes kļūdas (Avārija), Sistēmas akcepttestēšana tiek apturēta. Izpildītājam jānovērš šīs

kļūdas un jāiesniedz Sistēma atkārtotai akcepttestēšanai.

Akcepttestēšanas laikā atklātās kļūdas Izpildītājam ir jānovērš 20 darba dienu laikā un jāiesniedz Sistēma

Pasūtītājam atkārtotai akcepttestēšanai. Ja atkārtotas akcepttestēšanas laikā Sistēma netiek akceptēta,

Pasūtītājam ir tiesības Sistēmu nepieņemt (ja atklātās kļūdas netiek novērstas līdz ERAF Projekta beigām,

Pasūtītājam ir tiesības noraidīt nodevumu un neveikt samaksu).

5.6. Projekta organizatoriskā struktūra

ORG-20 Projekta organizatoriskā struktūra (Obligāta)Izpildītājam jāpiedāvā detalizēts projekta organizatoriskais modelis, paredzot vismaz šādas struktūras:

Projekta uzraudzības komiteja;

37



Projekta vadības grupa;

Projekta darba grupas.

ORG-21 Projekta uzraudzības komiteja (Obligāta)Projekta uzraudzības komiteja nodrošinās Projekta norises uzraudzību un būtisku, stratēģiski svarīgu

jautājumu risināšanu un lēmumu pieņemšanu. Projekta uzraudzības komitejas sastāvā ietilps Pasūtītāja un

Izpildītāja pārstāvji. Projekta uzraudzības komitejas pamatdarbība notiks sanāksmēs, saskaņojot to norisi

vismaz 3 (trīs) darba dienas iepriekš.

ORG-22 Projekta vadības grupa (Obligāta)Projekta vadības grupa risinās dažādus ikdienas un operatīvos uzdevumus saistībā ar Projekta īstenošanu.

Sastāvā ietilps Pasūtītāja un Izpildītāja Projekta vadītāji un vadošie speciālisti. Projekta vadības grupas

pamatdarbība notiks regulārās sanāksmē, iepriekš saskaņotā laikā.

ORG-23 Projekta darba grupas (Obligāta)Projekta īstenošanas laikā Projekta darba grupu sanāksmes tiks organizētas pēc nepieciešamības. Projekta

darba grupu sastāvā ietilps darbu izpildē iesaistītie Pasūtītāja un Izpildītāja speciālisti. Pasūtītāja speciālisti

būs atbildīgi par savlaicīgu informācijas sniegšanu Izpildītājam un uzdevumu rezultātu izskatīšanu un

saskaņošanu, savukārt, Izpildītāja speciālistu pienākums ir vismaz 2 darba dienas pirms sanāksmes

sagatavot informācijas pieprasījumus un protokolēt sanāksmē izrunātos jautājumus.

5.7. Ieviešana

ORG-24 Funkcionālā testēšanaIzpildītājam jānodrošina testēšana, kas aptver pilnvērtīgu testu veikšanu gan visām Sistēmas

komponentēm, gan arī šo komponenšu savstarpējai darbībai un Sistēmas integrācijas pārbaudēm (testiem)

ar citām informācijas sistēmām (ja tāda tiek nodrošināta), ar nosacījumu, ka ārējās informācijas sistēmas ir

pieejamas testu veikšanai.

ORG-25 AkcepttestēšanaIzpildītājam jāsagatavo un jāsaskaņo ar Pasūtītāju Sistēmas akcepttestēšanas scenāriji un plāns, kurā tiek

aprakstīta Sistēmas akcepttestēšanas kārtība, grafiks un kritēriji, kā arī akcepttestēšanas testu objekti un

scenāriji.

Akcepttestēšanas laikā Izpildītājam jānodrošina Pasūtītājam nepieciešamais atbalsts akcepttestēšanas

scenāriju izpildei.

38



ORG-26 Sistēmas uzstādīšana produkcijas vidē (Obligāta)Par Sistēmas uzstādīšanu produkcijas vidē atbild VI. Izpildītājs nodrošina atbalstu Sistēmas uzstādīšanā pēc

Pasūtītāja pieprasījuma. Izpildītāja pienākums ir piegādāt pilnvērtīgi strādājošu Sistēmu vai Sistēmas

papildinājumus (ja tiek piegādāti Sistēmas papildinājumi) – Sistēmas izejas kodu un versijas izveides

instrukciju, kopā ar aktualizētu Sistēmas dokumentāciju, versijas aprakstu un uzstādīšanas instrukciju.

ORG-27 Administratora rokasgrāmata (Obligāta)Administratora rokasgrāmatā ir jābūt aprakstītai Sistēmas uzstādīšanas kārtībai un uzskaitītām visām

komponentēm, kuras jākopē sekmīgai sistēmas darba atjaunošanai, kā arī ieteicamā kopēšanas secība un

jebkādi ierobežojumi (piemēram ziņojumi, kuri saņemti/nosūtīti ārējās saskarnēs), kuri var radīt datu

integritātes problēmas, atjaunojot sistēmu no kopijas.

Administratora rokasgrāmatai jāsatur arī visu maināmo sistēmas parametru / uzstādījumu uzskaitījums un

apraksts.

Administratora rokasgrāmatai jābūt sadalītai divās daļās. Pirmajā daļā jāapraksta ar sistēmas tehniskā

administrēšana, kas saistīta ar sistēmas uzstādīšanu un tehnisko uzturēšanu. Otrajā daļā jāapraksta

sistēmas lietotāja saskarnē pieejamās administratora darbības, tai skaitā klasifikatoru uzturēšana un

lietotāju uzraudzība.

ORG-28 Veiktspējas testēšanaIzpildītājam jāveic Sistēmas un to komponenšu veiktspējas testi, lai pārliecinātos par Sistēmas atbilstību

tehniskajā specifikācijā noteiktajām veiktspējas prasībām, kā arī lai identificētu iespējamās problēmas un

atrastu risinājumus Sistēmas ātrdarbības uzlabošanai. Veiktspējas testēšana jāveic Akcepttesta un

apmācību vidē.

ORG-29 Drošības testēšanaIzpildītājam jāveic Sistēmas un to komponenšu drošības testi, lai pārliecinātos par drošības principu

ievērošanu un identificētu/novērstu Sistēmas neautorizētas izmantošanas iespējas. Drošības testēšanu var

veikt Akcepttesta un apmācību vidē.

5.8. Apmācības

ORG-30 Administratoru apmācības (Obligāta)Izpildītājam jānodrošina Sistēmas administratoru apmācība tādā līmenī, lai administratori spētu patstāvīgi

veikt sistēmas administrēšanas, uzraudzības, atjaunošanas pasākumus, spētu veidot jaunas vai mainīt

esošās darba plūsmas, sistēmas adapterus un sniegt atbalstu izstrādātājiem jautājumos par VUIS 2.kārtas

funkcionalitātes izmantošanu.

39



ORG-31 Apmācāmo skaits (Obligāta)Izpildītājam ir jānodrošina Pasūtītāja darbinieku (administratoru) apmācības. Apmācību kursu Izpildītājs var

sadalīt vairākās apmācību programmās. Apmācību programma, tās veikšanas laiks un apmācāmo

darbinieku skaits katrā apmācības programmā saskaņojams ar Pasūtītāju pirms apmācību programmas

uzsākšanas. Apmācāmo darbinieku (administratoru) skaits nepārsniegs 3 speciālistus katrā apmācības

programmā.

ORG-32 Apmācību vieta (Obligāta)Izpildītājam jānodrošina Sistēmas administratoru apmācības Izpildītāja telpās, kas atrodas Rīgas

administratīvajā teritorijā vai citā ar Pasūtītāju iepriekš saskaņotā vietā. Izpildītājs nodrošina visu

nepieciešamo tehnisko aprīkojumu un mācību materiālus (elektroniski un drukātā veidā), kas nepieciešami

veiksmīgai administratoru apmācību norisei.

5.9. Konsultācijas

ORG-33 Konsultācijas Pasūtītājam vai Pasūtītāja pilnvarotām personām (Obligāta)Izpildītājam jāsniedz konsultācijas par Sistēmas funkcionalitāti un/vai dokumentāciju (līdz 100 stundām

katrus 6 mēnešus) 24 (divdesmit četru) mēnešu laikā no gala pieņemšanas – nodošanas akta parakstīšanas

dienas. Izpildītājam jānodrošina atbalsts, kas paredz Pasūtītāja iekšēji apstrādātu un precīzi noformulētu

problēmu pieteikumu reģistrēšanu, klasificēšanu un apstrādi.

5.10. Sistēmas neparedzēto uzlabojumu realizācija

ORG-34 Sistēmas neparedzēto uzlabojumu realizācija (Obligāta)Izpildītājam jānodrošina Pasūtītājam garantētu iespēju par maksu saņemt Sistēmas uzlabošanas

pakalpojumus Sistēmas izstrādes laikā un ne mazāk kā 2 gadus pēc projekta gala pieņemšanas-nodošanas

akta parakstīšanas.

Izpildītājam jānodrošina neparedzēto Sistēmas uzlabojumu izpilde, pamatojoties uz Pasūtītāja uzlabojumu

pieprasījumiem un saskaņā ar finanšu piedāvājumā norādīto 1 (vienas) cilvēkdienas likmi.

Izpildītājam jāinformē Pasūtītājs par uzlabojumu darba apjomu, izpildes termiņu un izmaksu novērtējumu 5

darba dienu laikā no uzlabojumu pieprasījuma saņemšanas. Ja pieprasītais uzlabojums ir apjomīgs un tā

izpildes novērtēšanai nepieciešama detalizēta prasību izpēte un analīze, Izpildītājs sniedz vērtējumu tikai

par uzlabojumu analīzes posmu.

Sistēmas izmaiņu realizācijai, ja tādi izriet no Pasūtītāja pieprasījumiem, Izpildītājam ir jānodrošina to

realizācija 100 cilvēkdienu apjomā.

40



Izpildītājam jānorāda tehniskajā piedāvājumā paredzēto sistēmas uzlabošanas pakalpojumu sniegšanas

pieeja, savukārt, finanšu piedāvājumā jānorāda to izmaksas - speciālistu darba laika izmaksas, par kādām

Piegādātājs apņemas veikt minētos pakalpojumus.

5.11. Garantijas prasības

ORG-35 Garantijas pakalpojumu apjoms (Obligāta)Sistēmas garantija iekļauj vismaz šādu bezmaksas pakalpojumu sniegšanu Pasūtītājam saistībā ar piegādāto

Sistēmu vai tās komponentēm:

Pasūtītāju pieteikto programmatūras kļūdu (1. līdz 4.līmeņa prioritātes problēmu ziņojumi)

bezmaksas novēršana;

Programmatūras licencēm un aparatūrai nodrošina garantija saskaņā ar MK noteikumu Nr.766 57.4

punkta nosacījumiem „Preču un pakalpojumu sniegšanas garantiju iekļauj līguma priekšmeta cenā un

atsevišķi neizdala kā izmaksu pozīciju. Minēto garantiju paredz, lai novērstu līguma priekšmeta

neatbilstības, kas radušās ražotāja vai pakalpojuma sniedzēja vainas dēļ, un tās sniegšanas termiņš

nepārsniedz piecus gadus pēc projekta īstenošanas”;

Pasūtītāja, tā nozīmēto pārstāvju un Sistēmas administratoru telefonisks atbalsts darba laikā 8:00-

17:00 (Help-desk);

Bezmaksas garantijas pakalpojumu sniegšanas ietvaros netiek paredzēta jaunas funkcionalitātes piegāde.

ORG-36 Garantijas periods (Obligāta)Izpildītājam jānodrošina izstrādāto un piegādāto Sistēmas komponenšu bezmaksas garantijas līdz

pilnvērtīgas IS un visu tās komponenšu izstrādei, piegādei un ieviešanai pie VI, kā arī 24 (divdesmit četrus)

mēnešus pēc Projekta gala pieņemšanas-nodošanas akta parakstīšanas. Gala nodošanas-pieņemšanas akts

tiek parakstīts pēc visu Sistēmas komponenšu izstrādes, piegādes un akceptēšanas.

ORG-37 Problēmu ziņojumu reģistrs (Obligāta)Izpildītājam garantijas apkalpošanai un tehniskā atbalsta mērķiem ir jānodrošina elektronisks problēmu

pieteikumu reģistrs ar šādu funkcionalitāti:

Problēmu pieteikumi izmantojot e-pastu, tīmekļa saskarni vai telefonu (problēmu reģistrē Izpildītāja

darbinieks);

Pasūtītāja darbiniekiem pieejams pieteikto problēmu pārskats, kurā iespējams redzēt katras

problēmas stāvokli, pieteikšanas un risināšanas gaitu, ieskaitot visu informācijas apmaiņu ar

Izpildītāju (informācijas apmaiņa var notikt kā e-pastu sarakste, izmantojot tīmekli, jeb telefonu);

Atrisināto problēmu arhīvs ar meklēšanas iespējām;

41



E-pasta brīdinājumu izsūtīšana, ja mainās pieteiktās problēmas statuss;

Problēmas pieteikuma reakcijas laika un risināšanas laika uzskaite.

ORG-38 Problēmu ziņojumu klasifikācija (Obligāta)Problēmu ziņojumu klasifikācija:

1.prioritāte - avārija: problēma izraisa pilnīgu sistēmas darbības apstāšanos un/vai darbu nav iespējams

turpināt. Problēmas drošības prasību izpildē tiek klasificētas ar 1.prioritāti;

2. prioritāte - kļūda, kuru nevar apiet: problēma izraisa iekšēju programmatūras kļūdu vai nekorektu

darbību, kas rada lielus iespēju zudumus. Nav zināms (klientam) pieņemams problēmas apiešanas

risinājums, tomēr ir iespējams darbu turpināt ierobežotā režīmā. Problēmas veiktspējas prasību izpildē tiek

klasificētas ar 2.prioritāti;

3. prioritāte - kļūda, kuru var apiet: problēma izraisa minimālus iespēju zudumus. Ietekme uz sistēmu ir

mazsvarīga / sagādā zināmas neērtības, piemēram, manuālu darbu sistēmas funkcionēšanas atjaunošanai /

darba turpināšanai;

4. prioritāte - neprecizitāte: problēma neizraisa iespēju zudumus. Šādu pieteikumu raksturo iekšēja

programmatūras kļūda vai nekorekta darbība, kuras ietekmi uz darba turpināšanu var neņemt vērā,

piemēram, kļūda / neprecizitāte produkta dokumentācijā;

5. prioritāte - izmaiņu pieprasījums\Sistēmas uzlabojumi\papildinājums: pieprasījums veikt izmaiņas,

uzlabojumus vai papildināt Sistēmas funkcionalitāti, dokumentāciju vai veikt citus papildu darbus, kas

atšķiras no tehniskā specifikācijās minētām prasībām;

6. prioritāte - konsultācija: problēma neizraisa iespēju zudumus. Programmatūrā nav kļūda, bet ir radusies

kāda neskaidrība par sistēmas darbību vai funkcionalitāti, izmantošanu, tehnisko apkalpošanu.

ORG-39 Problēmu ziņojumu reakcijas termiņi (Obligāta)Izpildītājam jānodrošina reakcijas laiks darba laikā (darba dienās no 8:00 līdz 17:00) ne ilgāks par 4 stundām

uz pieteiktajiem problēmu ziņojumiem - problēmu ziņojuma pieņemšana, reģistrēšana, problēmu

novēršanas laika un problēmu būtiskuma abpusēja saskaņošana ar Pasūtītāju, izpēte, klasifikācija un

atbildes sniegšana pieteicējam par problēmas novēršanas termiņiem. Izpildītājam jānodrošina tālrunis

ārpus darba laika 1. un 2. prioritātes kļūdu pieteikšanai.

ORG-40 Problēmu ziņojumu novēršanas termiņi (Obligāta)Izpildītājam jānodrošina problēmu novēršanas maksimālais laiks darba laikā (darba dienās no 8:00 līdz

17:00) no problēmas pieteikšanas un reģistrēšanas/ klasifikācijas brīža atkarībā no problēmu prioritātes

(puses var vienoties par citiem termiņiem):

42



1.prioritāte – 8 stundas;

2.prioritāte – 8 stundas;

3.prioritāte – 5 dienas;

4.prioritāte – 5 dienas.

1.prioritātes un 2.prioritātes problēmām ir pieļaujams (pusēm saskaņojot) pagaidu risinājums - Sistēmas

darbības atjaunošana vai tās iepriekšējās strādājošās versijas atjaunošana. Šajā gadījumā problēmas

novēršanas termiņi attiecas uz pagaidu risinājumu, bet problēmas labojumu var piegādāt atbilstoši

3.prioritātes problēmas novēršanas termiņiem.

43

tehniskā specifikācija - vmnvd.gov.lv file · web viewvienotĀ uzraudzĪbas informĀcijas...

Documents