informācijas sistēmas Tehniskā specifikācija · Web view2018-12-06 · Formā jāvar pievienot vismaz šādas datnes: .docx, .pdf, .jpg, .jpeg, ... Infografika – .jpg, .jpeg,

Valsts un pašvaldību iestāžu tīmekļvietņu vienotā platforma 4.2informācijas sistēmas Tehniskā specifikācija

VALSTS UN PAŠVALDĪBU IESTĀŽU TĪMEKĻVIETŅU

VIENOTĀ PLATFORMA

INFORMĀCIJAS SISTĒMAS TEHNISKĀ SPECIFIKĀCIJA

VALSTS KANCELEJA

DOKUMENTA IDENTIFIKĀCIJAS NR. DOCUMENT.DOCX

VERSIJA 4.2

RĪGA


Šī 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 2018. gada 6. jūlija Līgumu “Konsultāciju pakalpojumi informācijas un komunikācijas tehnoloģiju risinājumu ieviešanai Valsts kancelejas īstenoto Eiropas Reģionālās attīstības fonda projektu ietvaros”. 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 “Valsts un pašvaldību iestāžu tīmekļvietņu vienotā platforma” līdzekļiem.

Dokumenta autori:

Āris Āriņš Zanda Rence-MālnieceKristiāna GloveckaJānis SpruktsNauris KļavaImants FelsbergsJuris Šmits

Kontaktpersona:

Kristiāna GloveckaSIA “Corporate Consulting”Pērnavas 43a - 9Rīga, LV-1009Tālr.: (+371) 67 074 725E-pasts: [email protected]ņu lapa

Versija Datums Apraksts Autors

1.0 08.10.2018. Dokumenta sākotnējā versija Dokumenta autori

2.0 17.10.2018. Dokuments ar iestrādātiem vadības grupas (VGR) labojumiem

Dokumenta autori

3.0 02.11.2018. Dokuments ar iestrādātiem iestāžu labojumiem

Dokumenta autori

4.0 06.11.2018. Dokumenta gala versija Dokumenta autori

2


Versija Datums Apraksts Autors

4.1. 16.11.2018. Dokumenta gala versija ar iestrādātiem VGR labojumiem atbilstoši 15.11. VGR sanāksmei

Dokumenta autori

4.2. 30.11.2018. Dokumenta gala versija ar iestrādātiem Projekta uzraudzības padomes (PUP) komentāriem, atbilstoši 26.11.2018. PUP sanāksmei

Dokumenta autori

3


SATURA RĀDĪTĀJSSatura rādītājs.........................................................................................................................4

1. Ievads...............................................................................................................................8

1.1. Nolūks..........................................................................................................................................8

1.2. Darbības sfēra..............................................................................................................................8

1.3. Lietotie saīsinājumi un termini.....................................................................................................9

1.4. Saistība ar citiem dokumentiem.................................................................................................11

1.5. Kopsavilkums..............................................................................................................................11

2. TVP konteksts.................................................................................................................12

2.1. TVP darbības principi un darbības vide.......................................................................................12

2.2. TVP atbalstāmie biznesa procesi................................................................................................12

2.3. TVP darbību reglamentējošie normatīvie akti............................................................................12

2.4. TVP datu arhitektūra..................................................................................................................14

3. Funkcionālās prasības.....................................................................................................15

3.1. Vispārīgās prasības.....................................................................................................................15

3.2. Satura veidošana........................................................................................................................18

3.2.1. Satura redaktors.......................................................................................................................18

3.2.2. Satura rediģēšana.....................................................................................................................20

3.2.3. Satura pārņemšana..................................................................................................................21

3.2.4. Atslēgvārdi...............................................................................................................................22

3.2.5. Attēli.........................................................................................................................................22

3.2.6. Video, audio un tiešraides........................................................................................................25

3.2.7. Melnrakstu sagatavošana.........................................................................................................27

3.3. Satura pārvaldība.......................................................................................................................27

3.3.1. Satura pārvaldība.....................................................................................................................27

3.3.2. Formas.....................................................................................................................................29

3.3.3. Satura bloki..............................................................................................................................31

3.3.4. Satura strukturēšana................................................................................................................32

4


3.3.5. Paziņojumu iestatījumi.............................................................................................................34

3.3.6. Spraudņi...................................................................................................................................35

3.3.7. Palīdzības ikonas......................................................................................................................36

3.3.8. Tīmekļvietnes novērtēšana......................................................................................................37

3.3.9. Virtuālais asistents...................................................................................................................37

3.3.10. Datu atjaunošana un dzēšana..................................................................................................38

3.3.11. Saites........................................................................................................................................39

3.3.12. Sesijas ilgums...........................................................................................................................40

3.3.13. Klasifikatori...............................................................................................................................41

3.4. Satura publicēšana.....................................................................................................................43

3.4.1. Satura attēlošanas veidi un formāti..........................................................................................43

3.4.2. Publicēšana..............................................................................................................................44

3.4.3. Paziņojumu attēlošana.............................................................................................................45

3.4.4. Daudzvalodu saskarne..............................................................................................................46

3.4.5. Biežāk uzdotie jautājumi..........................................................................................................47

3.4.6. Vietnes karte............................................................................................................................48

3.4.7. Sociālie mediji..........................................................................................................................49

3.4.8. Darba laiks................................................................................................................................50

3.4.9. Kontaktinformācija...................................................................................................................51

3.4.10. Kartes attēlošana......................................................................................................................53

3.4.11. Pieteikšanās jaunumiem...........................................................................................................54

3.4.12. Notikumu kalendārs.................................................................................................................56

3.4.13. Pieteikšanās pasākumiem........................................................................................................58

3.4.14. Baneru attēlošana....................................................................................................................59

3.4.15. Prezentācijas un dokumenti.....................................................................................................60

3.4.16. Anketas....................................................................................................................................61

3.4.17. Vakanču attēlošana..................................................................................................................63

3.4.18. Pieteikšanās konsultācijai.........................................................................................................64

3.4.19. Satura saglabāšanas iespēja.....................................................................................................65

3.4.20. Hipersaišu attēlojums...............................................................................................................65

5


3.4.21. Izdrukas....................................................................................................................................66

3.4.22. RSS...........................................................................................................................................66

3.5. Satura administratora darba vide...............................................................................................66

3.6. Platformas administratora darba vide........................................................................................68

3.7. Meklētājs....................................................................................................................................71

3.8. SEO (Search engine optimization) funkciju nodrošinājums........................................................73

3.9. Indeksēšanas serviss...................................................................................................................74

3.10. Informācija par iestādes pakalpojumiem...................................................................................77

3.11. Statistikas pārskati......................................................................................................................78

3.12. Iepirkumu informācijas publicēšana...........................................................................................80

3.13. Lietotāju pārvaldība....................................................................................................................80

3.14. Grafiskā lietotāju saskarne.........................................................................................................83

3.15. Datu arhivēšana.........................................................................................................................84

3.16. Lietojamības prasības.................................................................................................................86

3.17. Datu apmaiņa.............................................................................................................................89

4. Nefunkcionālās prasības.................................................................................................91

4.1. Prasības Tehniskajam piedāvājumam.........................................................................................91

4.2. Arhitektūras prasības.................................................................................................................92

4.3. Pieejamības prasības..................................................................................................................96

4.4. Veiktspējas prasības...................................................................................................................98

4.5. Infrastruktūras prasības..............................................................................................................99

4.6. Trešo pušu programmatūras licences.......................................................................................101

4.7. Drošības prasības.....................................................................................................................102

4.8. Auditācijas prasības..................................................................................................................106

5. Organizatoriskās prasības.............................................................................................111

5.1. Projekta īstenošanas pieeja un laika plāns...............................................................................111

5.2. Metodoloģijas..........................................................................................................................114

5.3. Projekta organizatoriskā struktūra...........................................................................................121

6


5.4. Komunikācijas vadība...............................................................................................................121

5.5. Projekta nodevumi...................................................................................................................124

5.6. Nodevumu (laidienu) iesniegšanas un pieņemšanas kārtība....................................................130

5.7. TVP ieviešana...........................................................................................................................137

5.8. Mācības....................................................................................................................................137

5.9. Garantijas prasības...................................................................................................................139

5.10. Uzturēšanas prasības................................................................................................................143

5.11. Datu migrācija..........................................................................................................................145

6. Prasību trasējamības matrica........................................................................................147

7. Prasību savstarpējo atkarību apraksts...........................................................................151

7


1. IEVADS

1.1.NolūksŠis dokuments ir veidots kā pielikums iepirkuma “Valsts un pašvaldību iestāžu tīmekļvietņu vienotās platformas izstrāde, ieviešana un uzturēšana” nolikumam. Tehniskās specifikācijas mērķis ir aprakstīt TVP prasības. Iepirkuma ietvaros Tehnisko specifikāciju izmantos, lai Pretendenti novērtētu TVP realizācijas darbietilpību un sagatavotu tehnisko piedāvājumu. Savukārt Projekta realizācijas laikā Tehnisko specifikāciju izmantos, lai pārbaudītu TVP atbilstību iepirkuma prasībām.

1.2.Darbības sfēraProjekta mērķis ir izveidot vienotu, centralizētu valsts pārvaldes iestāžu tīmekļvietņu pārvaldības risinājumu, kas sniedz priekšnoteikumus sabiedrībai vienkāršāk un saprotamāk piekļūt publiski radītai informācijai, uzlabot iestāžu tīmekļvietņu piekļūstamību, īstenojot ES Direktīvas 2016/2102 prasības, tādējādi sniedzot iespēju publiski radītās informācijas pieejamībai visām sabiedrības grupām, ieskaitot cilvēkus ar ierobežotām funkcionālajām spējām, kā arī nodrošināt efektīvu resursu izlietojumu valsts un pašvaldības iestāžu tīmekļvietņu pārvaldībā, izmantojot vienotu tīmekļvietņu satura pārvaldības sistēmu un centralizētu tehnisko atbalstu un uzturēšanu, kā arī decentralizētu satura veidošanu un administrēšanu.

Projekta “Valsts un pašvaldību iestāžu tīmekļvietņu vienotās platformas izstrāde, ieviešana un uzturēšana” (turpmāk – Projekts) plānotās darbības ir paredzēts īstenot un finansēt ar Eiropas Savienības ERAF struktūrfondu atbalstu atbilstoši 2015. gada 17. novembra Ministru kabineta noteikumiem Nr. 653 “Darbības programmas “Izaugsme un nodarbinātība” 2.2.1. specifiskā atbalsta mērķa "Nodrošināt publisko datu atkalizmantošanas pieaugumu un efektīvu publiskās pārvaldes un privātā sektora mijiedarbību" 2.2.1.1. pasākuma “Centralizētu publiskās pārvaldes IKT platformu izveide, publiskās pārvaldes procesu optimizēšana un attīstība” īstenošanas noteikumi”.

1.3.Lietotie saīsinājumi un termini 1. tabula. Saīsinājumi, termini un to skaidrojumi

8


Saīsinājums, termins Skaidrojums

Autentifikācija Procedūra, kas nodrošina Platformas administratoru un Satura administratoru identitātes pārbaudi (atpazīšanas procesa daļa)

CIVIS Valsts pārvaldes cilvēkresursu vadības informācijas sistēmaERAF Eiropas reģionālās attīstības fondsES Direktīva 2016/2102

Eiropas Parlamenta un Padomes Direktīva (ES) 2016/2102 (2016. gada 26. oktobris) par publiskā sektora struktūru tīmekļvietņu un mobilo lietotņu piekļūstamību

IeM IC Iekšlietu ministrijas Informācijas centrsIKT Informācijas un komunikācijas tehnoloģijasIS Informācijas sistēmaIzstrādātājs Komersants vai komersantu grupa, kas saskaņā ar

iepirkuma rezultātiem veiks pasūtījuma izpildiKISC Kultūras informācijas sistēmu centrsKonsultanti Personu apvienība “Corporate Consulting” un “Ernst&Young

Baltic”LNA Latvijas Nacionālais arhīvsLVRTC uzturētais eParaksts API EISP modulis

VAS “Latvijas valsts radio un televīzijas centra” uzturētā eParaksta lietojumprogrammatūras saskarnes Elektroniskās Identifikācijas Sniegšanas Platformas modulis

MK Ministru kabinetsMK 611 Ministru kabineta 2018. gada 25. septembra noteikumi Nr.

611 “Kārtība, kādā iestādes ievieto informāciju internetā”N/a Nav attiecināmsPasūtītājs Valsts kancelejaPilotprojekts ERAF projekta Nr. 2.2.1.1/17/I/016 “Valsts un pašvaldību

iestāžu tīmekļvietņu vienotā platforma” izmēģinājuma projekts, kurā tiks novērtēta TVP atbilstība izvirzītajām prasībām jau izstrādes sākumposmā, un tajā tiks iesaistītas 12 iestādes

Platformas administrators

Loma personai, kas veic Platformas konfigurēšanas un uzturēšanas darbus. Ar šo lomu var pārlūkot, pārvietot, dzēst repozitorija objektus (mapes, dokumentus un saites) un risināt piekļuves tiesību problēmas. Lomai ir nodrošinātas tiesības mainīt konfigurācijas parametrus. Var

9


Saīsinājums, termins Skaidrojums

pievienot papildu moduļus tīmekļvietņu bāzes modulim. Uzstāda Platformas programmatūras atjauninājumus.

Pretendents Komersants vai komersantu grupa, kas sagatavo Tehnisko piedāvājumu

Projekts Valsts un pašvaldību iestāžu tīmekļvietņu vienotās platformas izstrāde, ieviešana un uzturēšana

Publiskais pakalpojums

Publiskie pakalpojumi ir valsts pārvaldes vai pašvaldības iestāžu darbības rezultāts, kas izpaužas kā noteiktu labumu nodrošināšana tās klientiem – sabiedrībai, piemēram, dažāda veida pabalstu izmaksa, valsts nodrošinātie izglītības un veselības aprūpes pakalpojumi u. c. Pie publiskiem pakalpojumiem ir pieskaitāma arī konkrētā klienta mijiedarbība ar valsti, kas ir klienta pienākums un kuras mērķis ir visas sabiedrības interešu nodrošināšana, piemēram, būvatļaujas, dažādu atļauju un licenču izsniegšana, nodokļu nomaksa u. c.

PUP Projekta uzraudzības padomePVG Projekta vadības grupaRSS XML tīmekļa sindikācijas datņu formātu saime (no angļu

val. – really simple syndication)Satura administratori Iestāžu darbinieki, kuri tīmekļvietnēs veido un administrē

saturu un struktūru ar Platformas administratora atļaujuSatura patērētāji Iedzīvotāji, kuri apmeklē tīmekļvietnes publisko daļuSEO Meklētājprogrammas optimizācija (no angļu val. – search

engine optimization)SPS Satura pārvaldības sistēmaTVP, Platforma Tīmekļvietņu platformaVARAM Vides aizsardzības un reģionālās attīstības ministrijaVRAA Valsts reģionālās attīstības aģentūraWCAG Web Content Accesibility Guidelines – Tīmekļa satura

piekļūstamības vadlīnijas

10


1.4. Saistība ar citiem dokumentiem2. tabula. Saistītie dokumenti

Nr.p.k.

Dokumenta nosaukums Datums

[1] Valsts un pašvaldību iestāžu tīmekļvietņu vienotās platformas izveide. Detalizētais projekta apraksts. (Dokuments pieejams https://drive.google.com/file/d/1Nrk-udKRrg9j-hCWpY2JVzM_Y5kgDYtg/view)

27.10.2017.

[2] Valsts un pašvaldību iestāžu tīmekļvietņu vienotā platforma. Informācijas sistēmas biznesa procesu un biznesa prasību specifikācija un lietotāju vajadzību apraksts.

08.10.2018.

[3] Valsts un pašvaldību iestāžu tīmekļvietņu vienotā platforma. Datu arhitektūras prasības.

08.10.2018.

Izstrādātājam Platformas izstrādes laikā jāņem vērā saistīto projektu ietvaros sagatavotā dokumentācija, tādā apmērā kādā tā atteicas uz šo projektu.

1.5.KopsavilkumsŠajā dokumentā ir aprakstītas TVP prasības, un tas sastāv no 7 (septiņām) 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ī sniegts izmantoto terminu un saīsinājumu skaidrojums;

2. sadaļā ir aprakstīts TVP konteksts; 3. sadaļā ir aprakstītas TVP funkcionālās prasības; 4. sadaļā ir aprakstītas TVP nefunkcionālās prasības; 5. sadaļā ir aprakstītas Projekta organizatoriskās un pārvaldības prasības; 6. sadaļā ir aprakstīta prasību trasējamības matrica; 7. sadaļā ir aprakstītas prasību savstarpējās atkarības.

11


2. TVP KONTEKSTS

2.1.TVP darbības principi un darbības videTehniskajā specifikācijā aprakstītās Platformas prasības skatāmas kontekstā ar dokumentu “Informācijas sistēmas biznesa procesu un biznesa prasību specifikācija un lietotāju vajadzību apraksts”, kurā iekļauts nākotnes biznesa procesu attēlojums, apraksts, kā arī lietotāju vajadzību apraksts un dokuments “Datu arhitektūras prasības“, kurā aprakstīta datu arhitektūra un no tās izrietošās prasības.

2.2. TVP atbalstāmie biznesa procesiTVP atbalstāmie biznesa procesi detalizēti aprakstīti dokumentā “Valsts un pašvaldību iestāžu tīmekļvietņu vienotā platforma. Informācijas sistēmas biznesa procesu un biznesa prasību specifikācija un lietotāju vajadzību apraksts.” [2]. Zemāk tabulā attēloti “Valsts un pašvaldību iestāžu tīmekļvietņu vienotā platforma. Detalizētais projekta apraksts” [1] aprakstītie procesi un Tehniskajā specifikācijā aprakstīto prasību atbilstība tiem.

2. tabula. Procesu atbilstība

Detalizētajā projekta aprakstā uzskaitītie procesi

Nodaļas, kurās tehniskajā specifikācijā aprakstītas prasības

atbilstoši procesiem

1. Publiskās pārvaldes komunikācija ar sabiedrību, izmantojot tīmekļvietnes

3.1., 3.2., 3.3., 3.4.

2. Informācijas par publisko iepirkumu un iepirkuma dokumentu publicēšana valsts un pašvaldību iestāžu tīmekļvietnēs

3.1., 3.2., 3.12., 4.2.

3. Publiskās pārvaldes tīmekļvietnes publicētās informācijas piekļūstamības nodrošināšana

3.1., 3.3., 3.4., 3.14., 3.16., 4.2., 4.3.

4. Publiskās pārvaldes tīmekļvietņu izveide, uzturēšana un modernizācija

3.1., 4.2., 4.5., 5.10., 5.11.

5. Publiskās pārvaldes tīmekļvietņu izmitināšana

3.1., 4.3., 4.5.

6. Publiskās pārvaldes tīmekļvietņu drošības pārvaldība

3.1., 4.7.

12


2.3.TVP darbību reglamentējošie normatīvie akti

Šajā nodaļā uzskaitīti normatīvie akti, standarti un vadlīnijas, kas jāņem vērā TVP izstrādes un uzturēšanas procesā (saraksts aktuāls uz 08.10.2018.):

Eiropas Parlamenta un Padomes Direktīva 2016/2102 par publiskā sektora struktūru tīmekļvietņu un mobilo lietotņu piekļūstamību;

ES Direktīva 2013/37/ES (2013. gada 26. jūnijs), ar ko groza Direktīvu 2003/98/EK par valsts sektora informācijas atkalizmantošanu;

Eiropas Parlamenta un Padomes Regula (ES) 2016/679 (2016. gada 27. aprīlis) par fizisku personu aizsardzību attiecībā uz personas datu apstrādi un šādu datu brīvu apriti un ar ko atceļ Direktīvu 95/46/EK (Vispārīgā datu aizsardzības regula);

Informācijas atklātības likums; Fizisko personu datu apstrādes likums; Publisko iepirkumu likums; Likums “Par Latvijas valsts ģerboni”; Aizsardzības un drošības jomas iepirkumu likums; Publiskās un privātās partnerības likums; Eiropas Savienības struktūrfondu un Kohēzijas fonda vadības likums; Eiropas Savienības struktūrfondu un Kohēzijas fonda 2014.-2020. gada plānošanas

perioda vadības likums; Valsts pārvaldes iekārtas likums; Valsts un pašvaldību institūciju amatpersonu un darbinieku atlīdzības likums; Arhīva likums; Ministru kabineta 2018. gada 25. septembra noteikumi Nr. 611 “Kārtība, kādā

iestādes ievieto informāciju internetā”; Ministru kabineta 2018. gada 6. februāra instrukcija Nr. 1 “Valsts elektronisko

sakaru pakalpojumu centra nodrošināšanas kārtība”; Ministru kabineta 2017. gada 28. februāra noteikumi Nr. 103 “Publisko iepirkumu

paziņojumi un to sagatavošanas kārtība”; Ministru kabineta 2011. gada 6. decembra noteikumi Nr. 927 “Noteikumi par

iepirkumos aizsardzības un drošības jomā izmantojamo paziņojumu saturu un sagatavošanas kārtību”;

Ministru kabineta 2017. gada 3. maija noteikumi Nr. 244 “Koncesijas procedūras paziņojumi un to sagatavošanas kārtība”;

Ministru kabineta 2016. gada 12. aprīļa noteikumi Nr. 225 "Kārtība, kādā tiek publiskota informācija par amatpersonu (darbinieku) atlīdzības noteikšanas kritērijiem un darba samaksas apmēru sadalījumā pa amatu grupām";

Ministru kabineta 2015. gada 17. novembra noteikumi Nr. 653 “Darbības programmas "Izaugsme un nodarbinātība" 2.2.1. specifiskā atbalsta mērķa “Nodrošināt publisko datu atkalizmantošanas pieaugumu un efektīvu publiskās pārvaldes un privātā sektora mijiedarbību” 2.2.1.1. pasākuma “Centralizētu publiskās pārvaldes IKT platformu izveide, publiskās pārvaldes procesu optimizēšana un attīstība” īstenošanas noteikumi”;

Ministru kabineta 2015. gada 28. jūlija noteikumi Nr. 442 “Kārtība, kādā tiek nodrošināta informācijas un komunikācijas tehnoloģiju sistēmu atbilstība minimālajām drošības prasībām”;

Ministru kabineta 2015. gada 17. februāra noteikumi Nr. 87 “Kārtība, kādā Eiropas Savienības struktūrfondu un Kohēzijas fonda ieviešanā 2014.–2020. gada plānošanas periodā nodrošināma komunikācijas un vizuālās identitātes prasību ievērošana”;

13


Ministru kabineta 2014. gada 28. janvāra noteikumi Nr. 51 “Ministru kabinetam padoto institūciju vienotās vizuālās identitātes noteikumi”;

Ministru kabineta 2013. gada 29. oktobra noteikumi Nr. 1191 “Kārtība, kādā publiska persona nomā nekustamo īpašumu no privātpersonas vai kapitālsabiedrības un publicē informāciju par nomātajiem un nomāt paredzētajiem nekustamajiem īpašumiem”;

Ministru kabineta 2013. gada 11. jūnija noteikumi Nr. 311 “Noteikumi par Latvijas valsts ģerboņa un Vidzemes, Latgales, Kurzemes un Zemgales ģerboņu heraldisko krāsu toņiem un grafiskajiem apzīmējumiem”;

Ministru kabineta 2009. gada 15. decembra instrukcija Nr. 19 “Tiesību akta projekta sākotnējās ietekmes izvērtēšanas kārtība”;

Ministru kabineta 2009. gada 25. augusta noteikumi Nr. 970 “Sabiedrības līdzdalības kārtība attīstības plānošanas procesā”;

Ministru kabineta 2005. gada 28. jūnija 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”;

Ministru kabineta 2004. gada 2. marta noteikumi Nr. 117 “Noteikumi par elektronisko dokumentu izvērtēšanas veidu, saglabāšanas kārtību un nodošanu valsts arhīvam glabāšanā”;

Informācijas sabiedrības attīstības pamatnostādnes 2014.–2020. gadam (apstiprinātas ar Ministru kabineta 2013. gada 14. oktobra rīkojumu Nr. 486.);

Latvijas nacionālais standarts LVS EN ISO 9241-210:2016 “Cilvēka un sistēmas mijiedarbības ergonomika” 210. daļa "Cilvēkorientēta interaktīvo sistēmu projektēšana";

Grafiskais standarts “Valsts pārvaldes iestāžu vienota vizuālā identitāte”; Latvijas nacionālais standarts EN 301549:2017 “IKT produktu un pakalpojumu

piekļūstamības prasības Eiropas publiskajos iepirkumos”; Tīmekļa satura piekļūstamības vadlīnijas WCAG 2.1.

Atsevišķām valsts iestādēm un pašvaldībām saistībā ar pamatdarbības funkciju izpildi arī ir izvirzītas obligātas speciālo normatīvo aktu prasības, kas nosaka pienākumu publicēt informāciju iestādes tīmekļvietnē, tomēr normatīvo aktu skaita dēļ tie nav uzskaitīti šajā dokumentā, bet tajos noteiktie pienākumi iestādēm attiecībā uz informācija publicēšanu tīmekļvietnēs ir jāņem vērā TVP izstrādes un uzturēšanas procesā. Līdzīgi – šeit netiek uzskaitītas arī detalizētās prasības, kas izriet no Ministru kabineta izdotajiem tiesību aktiem un citu institūciju lēmumiem (piemēram, plānošanas dokumenti, rīkojumi, Ministru kabineta protokollēmumi), un vēlamās prasības, kas saistītas ar rūpēm par galalietotāju ērtībām.

2.4.TVP datu arhitektūraTVP datu arhitektūra aprakstīta dokumentā “Valsts un pašvaldību iestāžu tīmekļvietņu vienotā platforma. Datu arhitektūras prasības” [3].

14


3. FUNKCIONĀLĀS PRASĪBASŠajā sadaļā aprakstītas Platformai izvirzītās funkcionālās prasības. Platformas funkcionālo prasību apraksta saturu skatīt . tabulā.

3. tabula. Platformas funkcionālo prasību apraksta skaidrojums

Apraksta kolonna Skaidrojums

Prasības identifikators Tehniskās specifikācijas ietvaros unikāls prasības apzīmējums.Prasība Prasības nosaukums.Apraksts Prasības detalizēts apraksts.Obligātums Visas funkcionālās prasības ir sadalītas divās grupās pēc to obligātuma:

Obligātās prasības ir tādas prasības, kuras nepieciešams Platformā realizēt Projekta ietvaros; Nākotnes prasības ir tādas prasības, par kuru realizācijas pasūtīšanu vai nepasūtīšanu Pasūtītājs lems

Projekta realizācijas gaitā. Pretendentam tehniskajā piedāvājumā šo prasību apraksts nav jāsniedz. Finanšu piedāvājumā nav jāiekļauj šo prasību realizācijas novērtējums, bet, projektējot Platformu, jāņem vērā, ka šādas prasības var tikt pasūtītas.

Pretendentam piedāvājumā jāiekļauj visu obligāto prasību realizācijas piedāvājuma apraksts.

3.1.Vispārīgās prasībasVispārīgās funkcionālās prasības definē Projekta sasniedzamos rezultātus. Visas šajā dokumentā iekļautās prasības Izstrādātājam ir jāsaskaņo un jādetalizē ar Pasūtītāju sistēmanalīzes laikā. Vispārīgo funkcionālo prasību realizācijas izmaksas ir iekļaujamas pārējo Tehniskās specifikācijas funkcionālo prasību realizācijas izmaksās un finanšu piedāvājumā kā atsevišķa izmaksu pozīcija nav izdalāma.


Prasības identifikators

Prasība Apraksts Obligātums

VSP01 Atbalstāmie biznesa procesi Izstrādātājam Platforma jāveido tā, lai tā nodrošinātu dokumentā “Valsts un pašvaldību iestāžu tīmekļvietņu vienotā platforma. Informācijas sistēmas biznesa procesu, biznesa prasību specifikācija un lietotāju vajadzību apraksts” uzskaitītos biznesa procesus, ņemot vērā funkcionālās prasības.Biznesa procesu un prasību sistēmanalīzes laikā Izstrādātājs var precizēt procesu izpildi, izmaiņas saskaņojot ar Pasūtītāju.

Obligāta

VSP02 Kļūdu paziņojumi Ja Satura patērētājam tiek attēlots kļūdas paziņojums, tam ir jābūt pietiekoši detalizētam, iekļaujot kļūdas skaidrojumu un turpmākās veicamās darbības vienkāršā, lietotājiem bez IT priekšzināšanām saprotamā valodā. Paziņojuma tekstam jābūt konfigurējam. Kļūdas paziņojums Izstrādātājam jāsaskaņo ar Pasūtītāju izstrādes gaitā.

Obligāta

VSP03 Datņu augšupielādēšana Izstrādātājam jānodrošina, ka jebkurai augšupielādējamai datnei vai attēlam tiek veikta vīrusu neesamības pārbaude. Tehniskajā piedāvājumā Izstrādātājam jāapraksta risinājums, kā tiks nodrošināta droša datņu augšupielāde Platformā esošajās tīmekļvietnēs.

Obligāta

VSP04 Grafiskais dizains Visām uz TVP esošajām tīmekļvietnēm ir jāatbilst grafiskajam standartam “Valsts pārvaldes iestāžu vienotā vizuālā identitāte”.

Obligāta

VSP05 Integrācijas ar citām IS Izstrādātājam jānodrošina visas biznesa procesu nodrošināšanai nepieciešamās datu apmaiņas, kas aprakstītas šīs nodaļas zemāk esošajās prasībās, atbilstoši ar Pasūtītāju un citu IS turētāju saskaņotām

Obligāta




prasībām, pārliecinoties par IS integrācijas pilnvērtīgu, atbilstošu un drošu darbību.Platformas analīzes laikā Izstrādātājam jāprecizē un ar Pasūtītāju un citu IS turētājiem jāsaskaņo datu nodošanas formāts, process, datu apjomi u. c. principi.

VSP06 Tīmekļvietņu struktūra Izstrādātājam jāizstrādā 3 tīmekļvietņu veidnes (ministrijām, ministriju padotības iestādēm un pašvaldībām) atbilstoši “Valsts un pašvaldību iestāžu tīmekļvietņu vienotā platforma. Informācijas sistēmas biznesa procesu, biznesa prasību specifikācija un lietotāju vajadzību apraksts” dokumentā aprakstītajām struktūrām. Jānodrošina, ka katrai veidnei ir izveidots standarta teksta formatējums un satura administrators to neveido manuāli.

Obligāta

VSP07 Prasību saskaņošana Izstrādes laikā tiek nodrošināta kāda no iteratīvajām IS izstrādes metodikām (piemēram, Agile) un visas Tehniskajā specifikācijā uzskaitītās prasības iespējams precizēt, saskaņojot tās ar Pasūtītāju.

Obligāta

VSP08 Satura publicēšana Visam publiskajam saturam jābūt pieejamam mašīnlasāmā formā.Izstrādājot dizainu, jānodrošina, ka sadaļām ir skaidri, nepārprotami, stilistiski un gramatiski pareizi nosaukumi. Jāievēro samērīgi sadaļu nosaukumu garumi. Vēlamos sadaļu nosaukumus skatīt dokumentā “Valsts un pašvaldību iestāžu vienotā tīmekļvietņu platforma. Informācijas sistēmas biznesa procesu un biznesa prasību specifikācija un lietotāju vajadzību apraksts” [2].

Obligāta




VSP09 Strukturētie lauki Visur, kur iespējams, jānodrošina iespēja veidot strukturētus laukus. ObligātaVSP10 Nodalītas satura sadaļas TVP izvietotajās tīmekļvietnēs jābūt iespējai nodalīt ierobežotas pieejas

sadaļas, kurām var piekļūt, piemēram, ar lietotājvārdu un paroli vai tikai zinot sadaļas konkrēto URL adresi.

Nākotnes prasība

3.2.Satura veidošana3.2.1. Satura redaktors


Satura patērētāja funkcionalitāte Prasības identifikators

Administratora funkcionalitāte Obligātums

SP01 Jānodrošina, ka satura patērētājam saites tiek attēlotas izceltas no pārējā satura. Jānodrošina, ka satura patērētājam saites atveras gan tajā pašā logā (iekšējie resursi, piemēram saite uz citu sadaļu), gan arī jaunā logā (piemēram, ārējos resursus). Jānodrošina, ka satura patērētājs tiek informēts, ka lapa tiks atvērta jaunā logā.

AP01 1. Teksta ievades redaktoram jānodrošina vismaz šāda funkcionalitāte:1.1. treknraksts;1.2. slīpraksts;1.3. pasvītrots teksts;1.4. izvēlēties vienu no definētajiem fontiem;1.5. izvēlēties vienu no definētajiem stiliem;1.6. izvēlēties vienu fonta izmēru no

Obligāta





definētajiem;1.7. izvēlēties fonta krāsu no definētajām;1.8. izvēlēties virsraksta formātu no definētajiem (heading);

1.9. formatējuma izvēle, piemēram, saraksts, uzskaitījums (numbered list, bullet list);1.10. sadaļu sakļaušana un izplešana (collapse or expand sections);1.11. automātiskā numerācija;1.12. rindkopu atkāpes;1.13. kopējot tekstu no Word vai citiem resursiem, no formatējuma tiek saglabāts tikai pamatformatējums;1.14. iespēja noņemt formatējumu no kopētā teksta pilnībā; 1.15. kopēt formatējumu;1.16. attēlu un citu datņu pievienošana saturam;1.17. satura pārvaldības saskarnē ir iestrādāts WYSIWYG (What You See Is What





You Get) teksta redaktors – ievietojot saturu, satura administrators var apskatīt, kā tas izskatīsies tīmekļvietnes publiskajā vidē.

2. Jābūt iespējai veidot un rediģēt tabulas, kā arī jau sagatavotas tabulas iekopēt un formatēt.

3. Jābūt iespējai pievienot ārējas informācijas vienības, attēlojot iegulto saturu (embed code) no citiem dažādiem avotiem (piemēram, Vimeo, YouTube u. c.).

4. Jābūt iespējai pievienot hipersaites (saites uz konkrētās tīmekļvietnes sadaļām un saites uz citiem ārējiem resursiem tiek vizuāli izceltas, piemēram treknrakstā vai saiti pasvītrojot, lai lietotājam redzama atšķirība), saites uz konkrētās tīmekļvietnes sadaļām un saites uz citiem ārējiem resursiem.

5. Jābūt iespējai izceltu, formatētu citātu un piemēru/paskaidrojuma logu “Piemēru/paskaidrojuma logi” iekļaušanai tekstā.

6. Teksta laukiem ir jābūt iespējai norādīt maksimālo simbolu skaitu. Simbolu skaitam ir jābūt konfigurējamam parametram.

7. Jābūt iespējai Platformas administratoram definēt izmantojamos stilus un formātus katrai tīmekļvietnes veidnei.


3.2.2. Satura rediģēšana




N/a AP02 Satura administrators var veikt gan melnraksta, gan publicēta satura rediģēšanu.Saturu jāvar rediģēt HTML formātā gan arī atbilstoši WYSIWYG standartam.Satura administratoram, autentificējoties savā darba vidē, ir jābūt iespējai saturu rediģēt no Satura patērētāja saskarnes.Satura rediģēšanai jānodrošina adaptīvais dizains.

Obligāta

N/a AP03 Jāparedz satura izsekojamība (versionēšana), lai būtu iespējams aplūkot rediģēšanas datumu un autoru, kurš veicis izmaiņas (Satura administratoram jāvar redzēt arī tos teksta autorus, kuri vairs nav aktīvi darbinieki), kā arī iespēju atgriezt informācijas vienumu uz izvēlēto vēsturisko versiju.Jānodrošina, ka versijās tiek vizuāli attēlotas veiktās izmaiņas, salīdzinot ar iepriekšējo versiju. Izstrādātājam ar Pasūtītāju izstrādes gaitā jāvienojas par izmaiņu attēlošanas apjomu jeb limitu (piemēram, līdz cik % veiktās izmaiņas no

Obligāta





iepriekšējās versijas tiek attēlotas). Jānodrošina, ka izmaiņu vēsture tiek attēlota saraksta veidā, Izstrādātājam ar Pasūtītāju analīzes laikā vienojoties par sarakstā attēlojamajām kolonnām.

3.2.3. Satura pārņemšana




N/a AP04 Satura administratoriem jāvar pievienot tematiski saistīto saturu, saistītās lapas, pārņemt saturu no saistītajām lapām.

Obligāta

3.2.4. Atslēgvārdi




SP02 Jānodrošina, ka Satura patērētājs var meklēt pēc atslēgvārdiem, kurus satura administrators

AP05 Satura administratoram ir jābūt iespējai atslēgas vārdus pievienot, rediģēt un dzēst. Atslēgvārdiem

Obligāta





pievienojis saturam. jāvar pievienot sinonīmus, kurus var izmantot meklētājā.Atslēgvārdus jāvar pievienot ikvienam satura veidam (piemēram, attēli, raksta teksts, dokumenti u. c.), ko ievieto tīmekļvietnē.

3.2.5. Attēli




SP03 Ja satura ierakstam ir pievienota attēlu galerija, tad noklikšķinot uz kāda pievienotā attēla, tiek atvērts modālais logs, kurā ir iespēja režīmā “uz priekšu/atpakaļ” apskatīt visus pievienotos attēlus. Logā tiek attēlots attēls pilnekrānā, zemāk tiek attēloti vairāki attēli samazinātā izšķirtspējā. Satura patērētājam ir iespēja lejupielādēt augstākās izšķirtspējas attēlus. Satura patērētājam ir iespēja šo logu aizvērt.Satura patērētājam tīmekļvietnē pieejamos attēlus jāvar:

AP06 Satura administratoram tīmekļvietnē ir jāvar pievienot attēls un attēlu galerija un ir jāvar vismaz:

1. pievienot aprakstu;2. norādīt datumu (pēc noklusējuma

augšupielādes datums);3. pievienot atslēgvārdus;4. norādīt publicēšanas/atpublicēšanas

datumus; iespējot/atspējot iespēju dalīties sociālajos tīklos;

5. iespējot/atspējot iespēju novērtēt attēlu/galeriju;

6. iespējot/atspējot iespēju komentēt

Obligāta





Lejupielādēt (ja to atļāvis Satura administrators);

Dalīties sociālajos tīklos (ja to atļāvis Satura administrators);

Novērtēt, izvēloties Like (ja to ļāvis Satura administrators);

Komentēt (ja to ļāvis Satura administrators).

attēlus/galeriju.Jānodrošina, ka satura administrators var augšupielādēt tikai JPG, GIF, PNG formāta datnes. Datņu formātu izmēri un formāts tiek pārbaudīts pirms augšupielādes Platformā. Izstrādātājam ar Pasūtītāju izstrādes gaitā jāvienojas par visām sākotnējām noklusējuma vērtībām.Attēlus un attēlu galerijas jāvar pievienot konkrētam rakstam vai atsevišķā sadaļā – Galerijas. Jāparedz iespēja, ka kopējais fotogalerijas apraksts tiek attēlots pie katra fotogalerijas attēla arī tādā gadījumā, ja sākotnēji apraksts katram attēlam nav pielikts atsevišķi.

Attēlus un attēlu galerijas ir jāvar vismaz:1. publicēt/atpublicēt;2. automātiski publicēt/atpublicēt, norādot

konkrēto datumu un laiku;3. ediģēt, t. sk. mainīt katra attēla

nosaukumu;4. saglabāt nepublicējot;5. kopēt; 6. mainīt attēlu secību;





7. norādīt galerijas titulbildi;8. definēt fokusa reģionu, kas attēla

automātiski ģenerētajos mazākajos izmēros vienmēr būs redzams;

9. dzēst.

Veidojot attēlu galeriju, jānodrošina iespēja augšupielādēt fotogrāfijas vai pievienot iepriekš augšupielādētas fotogrāfijas no iepriekš augšupielādētām galerijām (iespējams vienlaikus augšupielādēt vai pievienot vairākas fotogrāfijas).Attēliem tīmekļvietnē ir jāglabājas samazinātā formātā. Jābūt automātiskai attēlu izmēru pielāgošanai uz iepriekš definētiem attēla izmēriem, pēc iespējas mazāk zaudējot kvalitāti, augšupielādējot attēlu. Attēlu sīkattēli tiek ģenerēti automātiski. Jāparedz, ka pēc oriģinālā attēla nomaiņas, kas satur tādu pašu nosaukumu kā sīkattēls, tas tiek nomainīts automātiski.Attēlu minimālās izšķirtspējas jāsaskaņo ar Pasūtītāju izstrādes laikā. Veicot datņu augšupielādi tīmekļvietnē, TVP veic





pārbaudi, vai konkrētās datnes formātu (skat. sadaļu 3.4.1.) ir atļauts augšupielādēt.Veicot datņu augšupielādi tīmekļvietnē, TVP automātiski veic pārbaudi, vai konkrētā datne nesatur ļaunatūru. Jānodrošina attēlu kārtošana caur satura administratora darba vidi.

3.2.6. Video, audio un tiešraides




SP04 Tīmekļvietnē jānodrošina iespēja atskaņot audioierakstus, videoierakstus un tiešraides.Satura patērētājam ar audioierakstiem, videoierakstiem un tiešraidēm ir jāvar vismaz:

1. dalīties sociālajos tīklos;2. novērtēt, izvēloties Like (ja to ļāvis Satura administrators);3. pārtraukt video;4. atskaņot audio;

AP07 Jānodrošina audioierakstu, videoierakstu un tiešraides pievienošana:

1. gan satura elementu veidā, piemēram, apraksts un tiešraide, kas iekļauti tekstā;

2. gan atsevišķā blokā tikai video vai tiešraidēm, piemēram, atsevišķs bloks tīmekļvietnes kreisajā malā.

Video saturs, tajā skaitā tiešraide, tiek nodrošināts, izmantojot iegulšanu, bet audio saturs – gan izmantojot iegulšanu, gan augšupielādējot tīmekļvietnē. Datņu formāti jāspecificē izstrādes

Obligāta





5. mainīt skaļumu;6. u. c.

laikā.Satura iegulšanai var tikt izmantoti, piemēram, šādi vai līdzvērtīgi servisi, kuri nodrošina iegulšanas koda (angļu val. – embed code) izgūšanu:

1. YouTube.com un Vimeo.com;2. issuu.com;3. SoundCloud.com;4. Storify.com;5. Flickr.com.

Satura administratoram tīmekļvietnē ir jāvar pievienot audioierakstus, iegult videoierakstus un tiešraides, kā arī jāvar vismaz:

6. pievienot nosaukumu;7. attēlot transkripciju;8. pievienot aprakstu;9. norādīt datumu (pēc noklusējuma

augšupielādes datums);10. pievienot atslēgvārdus;11. norādīt publicēšanas atpublicēšanas

datumus;12. iespējot/atspējot iespēju novērtēt

audioierakstus, videoierakstus un tiešraides.

Audioierakstus, videoierakstus un tiešraides ir jāvar





vismaz:1. publicēt;2. rediģēt, t. sk. mainīt katras datnes

nosaukumu;3. saglabāt nepublicējot;4. kopēt; 5. dzēst.

Veicot audio datņu augšupielādi tīmekļvietnē, TVP veic pārbaudi, vai konkrētās datnes formātu ir atļauts augšupielādēt. Platformas administratoram jābūt iespējai noteikt datņu atļautos formātus augšupielādei. Veicot datņu augšupielādi tīmekļvietnē, TVP veic pārbaudi, vai konkrētā datne nesatur ļaunatūru.Augšupielādētajiem audioierakstiem tīmekļvietņu platormai jānodrošina balss atpazīšana un pārvēršana tekstā, izmantojot KISC izstrādātās balss atpazīšanas pakalpes.


3.2.7. Melnrakstu sagatavošana




N/a AP08 Platformā ir jānodrošina iespēja izveidot saturu melnraksta statusā un saglabāt to nepublicējot. Pirms publicēšanas ir pieejams satura priekšskatījums (preview) attēlojumam tīmekļvietnē.

Obligāta

3.3.Satura pārvaldība3.3.1. Satura pārvaldība




N/a AP09 Ar saturu ir jāspēj veikt vismaz šādas darbības:1. publicēšanu;2. rediģēšanu;3. dzēšanu;4. kopēšanu (gan tekstam, gan satura tipam,

piemēram, veidlapas, preses relīzes u. c.);5. arhivēšanu;6. atpublicēšanu;

Obligāta





7. melnrakstu saglabāšanu.N/a AP10 Tekstuālas informācijas saturu (piemēram,

tabulas, teksts), iekopējot satura pārvaldības rīkā, jāvar automātiski pārvērst HTML formātā (attīrīts HTML kods bez liekiem formatējumiem).

Obligāta

N/A AP11 Platformā jāparedz iespēja veidot tīmekļvietņu veidnes (jaunas sagataves) ar citām dizaina tēmām un atsevišķu struktūru, lai tās varētu izmantot atsevišķiem projektiem vai kampaņām (piemēram, www.klimatam.lv, www.ainavudargumi.lv, www.mana.latvija.lv).

Nākotnes prasība

N/A AP12 Platformā jāparedz iespēja veidot iekšējā tīkla (intranet) veidnes (jaunas sagataves), lai tās varētu izmantot iestādēs.

Nākotnes prasība

3.3.2. Formas




SP05 Satura patērētājam ir jābūt iespējai aizpildīt tīmekļvietnē pieejamās formas (piemēram,

AP13 Satura administratoram ir jābūt iespējai izveidot dažāda veida formas informācijas iesniegšanai

Obligāta





uzdot jautājumu iestādei) un nosūtīt informāciju iestādei. Pēc formas aizpildīšanas Satura patērētājam ir jābūt iespējai norādīt savu e-pastu aizpildītās formas saņemšanai savā e-pastā.Satura patērētājam pēc formas iesniegšanas ir jāattēlo paziņojums par informācijas veiksmīgu iesniegšanu.Satura patērētājam jābūt iespējai dalīties ar formu sociālajos tīklos, ja šāda funkcija konkrētajai formai ir pieejama. Satura patērētājam jābūt iespējai novērtēt formu (ar Like), ja šāda funkcija konkrētajai formai ir pieejama.

iestādei.Satura administratoram ir jābūt iespējai formas vismaz:

1. izveidot;2. publicēt;3. rediģēt;4. saglabāt nepublicējot;5. dzēst;6. kopēt.

Ir jābūt iespējai formā pievienot dažādus laukus, norādot obligātos laukus, lauka tipus un ievadāmo simbolu skaitu. Formā jāvar pievienot vismaz šādas datnes: .docx, .pdf, .jpg, .jpeg, .png.Satura administratoram izstrādātajai formai jāvar izvēlēties pievienot vai nepievienot funkcionalitāti pret spambotiem (piemēram, angļu val. reCAPTCHA)Satura administratoram ir jāvar izveidot informatīvu paziņojumu par aizpildītās formas saņemšanu, kas tiek attēlots Satura patērētājam pēc formas aizpildīšanas un iesniegšanas.Satura administratoram jābūt iespējai





iespējot/atspējot funkcionalitāti Satura patērētājam ar formu dalīties sociālajos tīklos.Satura administratoram jābūt iespējai iespējot/atspējot funkcionalitāti Satura patērētājam formu novērtēt.Satura patērētājam jāvar saņemt formu e-pastā, ja pēc formas aizpildīšanas Satura patērētājs ir norādījis savu e-pasta adresi. E-pasta adresei jāveic datu validācija. Satura administratoram ir jābūt iespējai izvēlēties aizpildītās formas saņemšanas vietu – tīmekļvietne vai iestādes, vai iestādes darbinieka e-pasts. Katrai formai var būt savs atbildīgais darbinieks. Izvēloties un norādot Satura patērētāja aizpildīto formu saņemt e-pastā, jāveic e-pasta adreses datu validācija. Pēc formas iesniegšanas tā automātiski jāsaņem norādītajā saņemšanas vietā. Formās iegūtos datus sistēmas administratīvajā daļā jābūt iespējai kārtot, atlasīt un eksportēt .xlsx un .csv formātā.

SP06 Satura patērētājam ir iespēja aizpildīt AP14 TVP jānodrošina iespēja satura pārvaldniekam, Obligāta





tīmekļvietnē pieejamās e-formas. izmantojot "Pakalpojumu sniegšanas un pārvaldības platforma" (PSPP) izstrādāto e-formu risinājumu, izveidot un tīmekļvietnē izvietot e-formas.

3.3.3. Satura bloki


Satura patērētāja funkcionalitāte



SP07 Satura patērētājiem jānodrošina uz vienotiem pamatprincipiem balstīta tīmekļvietņu struktūra, nodrošinot atpazīstamu vidi un navigāciju ar citu TVP izvietoto tīmekļvietņu sadaļām.

AP15 Ir jāparedz trīs atsevišķas struktūru veidnes tīmekļvietnēm (pēc to satura blokiem) – ministrijām, padotības iestādēm un pašvaldībām.Struktūrām jāizmanto rekomendētā tīmekļvietņu struktūra, kas attēlota “Valsts un pašvaldību iestāžu tīmekļvietņu vienotā platforma. Informācijas sistēmas biznesa procesu un biznesa prasību specifikācija un lietotāju vajadzību apraksts” [2] dokumentā, kuru detalizētās analīzes laikā var mainīt, saskaņojot ar Pasūtītāju. Jānodrošina, ka obligāto struktūrā esošo satura bloku un sadaļu nosaukumus var mainīt tikai Platformas administrators. Jānodrošina, ka katrā tīmekļvietnē var tikt ievietota 1–3 specifiskas iestādes izveidotas sadaļas,

Obligāta






kurā satura administrators var iekļaut informāciju, kura nav paredzēta rekomendētajā tīmekļvietņu struktūrā.

N/a AP16 Iestādes ietvaros Satura administratoram ir jābūt iespējai publiskajā vidē attēlotos satura blokus deaktivizēt.Detalizētās analīzes laikā ir jāvienojas ar Pasūtītāju, kuras sadaļas kurā līmenī Satura administratoram ir iespēja neattēlot.

Obligāta

N/a AP17 Satura administratoram jānodrošina iespēja pievienot papildu satura blokus tīmekļvietnes struktūrā (piemēram, iestādes specifisko informāciju) 2. un 3. līmenī.

Obligāta

N/a AP18 Sākumlapā nepieciešams attēlot svarīgākās sadaļas un informācijas blokus Satura patērētājiem pārskatāmā un ērti lietojamā veidā.

Obligāta

N/a AP19 Izstrādātājam ir jāpiedāvā satura attēlošanas veidi dažādai iestāžu specifiskai informācijai, kuru var ievietot satura administrators. Piemēram, Nodarbinātības valsts aģentūras tīmekļvietnē ir sadaļa “NVA filiāles” un Izglītības iestāžu meklētājs, kurā informāciju ievieto katra NVA filiāle individuāli, tīmekļvietnēs esošie reģistri un datubāzes (piemēram, Veselības inspekcijai), LIAA esošais publikāciju katalogs, LIAA nekustamo īpašumu datu bāze, Centrālās statistikas pārvaldes “Statistisko klasifikāciju katalogs” un “Veidlapu katalogs” u.

Obligāta






c., kuras būtu jāattēlo iestāžu tīmekļvietnēs arī turpmāk. Izstrādes laikā, veicot padziļinātu analīzi, ir jāizvērtē iestāžu specifiskā informācija, kuru nepieciešams saglabāt un attēlot arī turpmāk.

3.3.4. Satura strukturēšana





SP08 Tīmekļvietnes galvenē tiek attēlots vismaz:

1. konkrētās iestādes vizuālā identitāte;

2. daudzvalodu izvēle;3. funkcija vājredzīgajiem;4. burtu izmēra maiņa;5. meklētājs.

Informācija, kas attēlojama galvenē, var mainīties un izstrādes laikā jāsaskaņo ar Pasūtītāju.

AP20 Jānodrošina, ka tīmekļvietnes galvenē esošo satura bloku izkārtojumu var rediģēt tikai Platformas administrators. Jānodrošina, ka satura administrators šajos blokos var aizpildīt informāciju, kas attiecas uz konkrēto iestādi.

Obligāta

SP09 Tīmekļvietnes kājenē tiek attēlots vismaz:

AP21 Jānodrošina, ka tīmekļvietnes kājeni var rediģēt tikai Platformas administrators.

Obligāta






1. kontaktu bloks;2. saite “Vietnes karte”;3. pieteikšanās jaunumiem;4. sociālo tīklu ikonas;5. RSS;6. saite uz sadaļu “Biežāk

uzdotie jautājumi”.Informācija, kas attēlojama kājenē, var mainīties un izstrādes laikā jāsaskaņo ar Pasūtītāju.

SP10 Iestādes vizuālā identitāte tiek attēlota galvenē visos tīmekļvietnes skatos. Uz tās noklikšķinot ar peli, Satura patērētājs nokļūst tīmekļvietnes sākumlapā. Jānodrošina, ka katrā tīmekļvietnē vizuālā identitāte tiek attēlota atbilstoši grafiskajam standartam “Valsts pārvaldes iestāžu vienota vizuālā identitāte”.

AP22 N/a Obligāta


3.3.5. Paziņojumu iestatījumi





SP11 Satura patērētājam jānodrošina paziņojumu saņemšana savā e-pastā vismaz par šādām darbībām, kuras veiktas tīmekļvietnē:

1. par sūdzību/ieteikumu iesniegšanu;2. par aptaujas aizpildīšanu (ja norādīts e-pasts);3. par pieteikšanos pasākumam;4. u. c. paziņojumiem, kas jāsaskaņo ar Pasūtītāju izstrādes laikā.

AP23 Jānodrošina, ka Satura administrators var veidot un rediģēt paziņojumus savas iestādes tīmekļvietnes ietvaros.Izstrādātājam ar Pasūtītāju sistēmanalīzes laikā jāsaskaņo visu Platformā izsūtāmo paziņojumu saturs un attēlojums un citi nosacījumi paziņojumu izsūtīšanai.Jānodrošina, ka satura administrators var konfigurēt iespēju pievienot vai nepievienot iespēju satura patērētājam norādīt e-pastu.

Obligāta

N/a AP24 Satura administratoriem savā darba vidē TVP vai e-pastā ir jāsaņem paziņojumi no jebkādas Satura patērētāja darbības, kurai nepieciešama pretreakcija (piemēram, atbildes e-pasts). Jānodrošina, ka satura administrators var norādīt savu e-pastu, uz kuru saņemt paziņojumus.

Obligāta

SP12 Jānodrošina, ka Satura AP25 Jānodrošina, ka Satura administrators var sagatavot Obligāta






patērētājam, kurš izvēlējies atvērt kādu saiti citā lapā, piemēram, izmantot e-pakalpojumu, tiek attēlots paziņojums, ka tiks atvērts portāls Latvija.lv vai nozares portāls, vai apskatīt iepirkumus Elektronisko iepirkumu sistēmā u. c., kurā ir iespēja saņemt detalizētāku informāciju (lai Satura patērētājam būtu iespēja izsekot darbībām).

attēlojamā paziņojuma tekstu, to rediģēt un dzēst.

3.3.6. Spraudņi





N/a AP26 Platformas administratoram ir jābūt iespējai pievienot Platformā spraudņus un moduļus, ar kuriem var papildināt Platformā izvietoto tīmekļvietņu funkcionalitāti.

Obligāta


3.3.7. Palīdzības ikonas





SP13 Jānodrošina iespēja attēlot Satura patērētājiem palīdzības informācijas blokus, kas paskaidro satura ievades laukus. Palīdzības ikonām ir jāsatur paskaidrojuma informācija par konkrētā lauka aizpildīšanas niansēm.

AP27 Satura administratoram tīmekļvietnē ir jābūt iespējai norādīt vietas, kurās būs redzamas palīdzības ikonas Satura patērētājiem. Jānodrošina palīdzības ikonu un paskaidrojumu attēlošana arī Satura administratoru darba vidē pie satura ievades laukiem. Satura administratoriem jānodrošina satura ievades vadlīnijas un lietotāja rokasgrāmata.

Obligāta

N/a AP28 Satura administratoriem palīdzības informācija pie satura ievades laukiem jānodrošina kontekstjutīga, t. i., Satura administratoriem tiek attēlota palīdzības informācija no lietotāja rokasgrāmatas par to datu lauku, pie kura tas ir uzspiedis palīdzības ikonu.

Nākotnes prasība

N/a AP29 Jānodrošina video rokasgrāmata, kurai jāsatur video mācību materiāli, kur katrs video ir ne garāks par 1 (vienu) minūti. Analīzes laikā ar Pasūtītāju jāvienojas par video mācībās iekļautajiem scenārijiem.

Nākotnes prasība


3.3.8. Tīmekļvietnes novērtēšana





SP14 Satura patērētājam ir jābūt iespējai novērtēt/iesniegt komentāru par tīmekļvietni.

AP30 Gan Platformas administratoram, gan Satura administratoram ir jābūt iespējai apskatīt iesniegtos komentārus. Komentāriem un ieteikumiem no Satura patērētājiem ir jāuzkrājas tīmekļvietnē, tos ir jāvar kārtot un filtrēt, kā arī izeksportēt .xlsx un .csv formātā, Platformas administratoram jābūt tiesībām piekļūt šiem novērtējumu un komentāru datiem.

Obligāta

SP15 Jānodrošina, ka tīmekļvietni iespējams novērtēt. Par novērtēšanas veidu Izstrādātājam jāvienojas ar Pasūtītāju.

AP31 Jānodrošina, ka Satura administrators var iespējot vai atspējot iespēju tīmekļvietni novērtēt Satura patērētājiem.Izstrādātājam izstrādes laikā jāvienojas par novērtēšanas veidu un risinājumu ar Pasūtītāju.

Nākotnes prasība

3.3.9. Virtuālais asistents





SP16 Satura patērētājam tīmekļvietnē ir AP32 Satura administratoram ir jābūt iespējai virtuālo asistentu Obligāta






jābūt pieejamam virtuālajam asistentam, ja šāda funkcionalitāte ir pieejama. Satura patērētājam jābūt iespējai uzdot jautājumus un saņemt tipveida atbildes, kuras nodefinējis Satura administrators, kā arī pieteikties vietnes jaunumiem. Jānodrošina, ka Satura patērētājam tiek attēlota informācija par to, kad atbildes sniedz virtuālais asistents un kad uz atbildēm atbild klientu apkalpošanas speciālists, ja tas pārņēmis sarunu.

iespējot/atspējot savas iestādes tīmekļvietnē. Satura administratoram jānodrošina saite no satura pārvaldības risinājuma uz virtuālā asistenta pārvaldības rīku. Virtuālais asistents ir trešās puses produkts un nav jāizstrādā šī Projekta ietvaros, skat. prasību DAP05. Ja TVP un virtuālā asistenta pārvaldības rīkiem ir vienādi autentifikācijas veidi (vienotā pieteikšanās), jānodrošina, ka Satura administrators var bez atkārtotas autentifikācijas pārslēgties virtuālā asistenta pārvaldības rīkā.

3.3.10. Datu atjaunošana un dzēšana





N/a AP33 Jebkādu datu dzēšanas gadījumā tīmekļvietnei vienmēr attēlo Obligāta






pārvaicājuma ziņojumu par dzēšanas darbības izpildi ar Satura administratora apstiprinājumu ieraksta dzēšanai un iespēju atteikties no dzēšanas. Datu dzēšana ir loģiska, nevis fiziska, saglabājot datu integritāti.Jānodrošina, ka Satura administrators vienlaicīgi var dzēst vairākus ierakstus.

N/a AP34 Jānodrošina, ka Satura administratoram ir pieejami visi dzēstie materiāli. Dzēstajiem materiāliem jāglabājas vienkopus datubāzē hronoloģiskā secībā pēc dzēšanas datuma. Ierakstiem jānodrošina vismaz šādas filtrēšanas iespējas:

1. dzēšanas datums;2. izveides datums;3. sagatavotājs;4. alfabētiskā secībā.

Jāparedz, ka Satura administrators var atjaunot dzēstos materiālus un tos atkārtoti rediģēt un publicēt.

Obligāta


3.3.11. Saites





N/a AP35 Jānodrošina informācijas vienumu atkalizmantošana. Piemēram, Satura administratoram jābūt iespējai norādīt sasaisti (abpusēji) starp informācijas vienumiem, tai skaitā dažāda tipa vienumiem – starp statiskām lapām un jaunumu ierakstiem, statiskām lapām un galerijām, jaunumiem un galerijām u. tml., izslēdzot nepieciešamību atkārtoti pievienot vienu informāciju (piemēram, bildes kā jaunu galeriju un tad atkārtoti pie saistītās statiskās lapas vai jaunumu ieraksta) un manuāli veidot saites.

Obligāta

N/a AP36 Jānodrošina funkcionalitāte, kas ar noteiktu regularitāti pārbauda TVP izvietoto saišu aktualitāti. Izstrādes laikā jāpiedāvā izmantot tirgū pieejamo atvērtā koda komponenti nederīgo saišu meklēšanai.

Obligāta

3.3.12. Sesijas ilgums





N/a AP37 Jāparedz, ka Platformas lietošanai būs terminēts sesijas laiks. Obligāta






Izstrādes laikā, ņemot vērā drošības prasības, Izstrādātājam ar Pasūtītāju jāsaskaņo sesijas ilgums. Jānodrošina, ka Satura administrators tiek informēts par tuvojošām sesijas beigām. Paziņojuma attēlošanas laiks pirms sesijas pārtraukšanas jāsaskaņo ar Pasūtītāju izstrādes laikā.Jānodrošina mehānisms, lai saglabātu Platformas administratora un Satura administratora darbu pirms sesijas pārtraukšanas.

3.3.13. Klasifikatori





SP17 Satura patērētājam ir jābūt iespējai izvēlēties vērtības no klasifikatora laukiem, kur klasifikatori ir definēti. Jānodrošina automātiskā vērtības pabeigšana (autocomplete).

AP38 Platformā jābūt klasifikatoru pārvaldības modulim, kurā tiek uzturēti Platformas darbībai nepieciešamie klasifikatori. Platformas administratoram ir jānodrošina iespēja rediģēt, dzēst un pievienot jaunas klasifikatora vērtības. Jānodrošina, ka arī katrs Satura administrators var rediģēt un izveidot savā tīmekļvietnē nepieciešamos klasifikatorus.Klasifikatoros, kuros ir nozīmīgs ierakstu skaits, jānodrošina vērtību meklēšana pēc atslēgvārdiem un filtrēšana pēc

Obligāta






svarīgākajiem laukiem. Par katru klasifikatora izmaiņu jāsaglabā atbilstošs auditācijas pieraksts.Jānodrošina iespēja klasifikatoru vērtības sasaistīt ar citiem funkcionāliem moduļiem, piemēram, kontaktformas, anketas, galerijas, jaunumi.

N/a AP39 Platformā paredzēti klasifikatori ar dažādu sarežģītības līmeni. Platformai ir jāatbalsta hierarhiski klasifikatori ar vismaz 4 (četru) līmeņu skaitu. Ierakstiem jāvar pievienot vismaz šādu informāciju:

1. ieraksta kods;2. nosaukums;3. derīgs no;4. derīgs līdz;5. hierarhijas līmenis;6. hierarhiski augstākais klasifikators.

Jānodrošina iespēja pievienot citus papildu parametrus (kolonnas).

Obligāta

SP18 Satura patērētājam ir jābūt pieejamām tikai spēkā esošām klasifikatoru vērtībām.

AP40 Platformā jānodrošina, ka vēsturiskie ieraksti attēlo tās klasifikatora vērtības, kas bija spēkā uz attiecīgo ierakstu izveidošanas brīdi. Platformas administratoram, veidojot jaunus ierakstus, tiek attēlotas tikai tās klasifikatoru vērtības, kuras ir aktuālas ieraksta izveides brīdī.

Obligāta






N/a AP41 Platformā klasifikatoriem ir jābūt grupētiem pa tematiem, lai uzlabotu klasifikatoru saraksta pārskatāmību.

Obligāta

N/a AP42 Platformas administratoram jāvar piešķirt pārvaldības tiesības Satura administratoram uz atsevišķiem klasifikatoriem vai klasifikatoru grupām konkrētās tīmekļvietnēs.Jānodrošina, ka Platformas administrators var pārvaldīt visus klasifikatorus vai klasifikatoru grupas.

Obligāta

N/a AP43 Visu Platformas klasifikatoru ierakstiem ir jāuztur unikāls identifikators.

Obligāta

N/a AP44 Platformā jārealizē visi klasifikatori, kas nepieciešami Platformas biznesa procesu un funkcionalitātes nodrošināšanai un datu apmaiņai ar citām sistēmām. Platformā izstrādājamo klasifikatoru saraksts Izstrādātājam jādefinē Platformas analīzes un projektēšanas fāzē.

Obligāta


3.4.Satura publicēšana3.4.1. Satura attēlošanas veidi un formāti





SP19 Jānodrošina, ka tīmekļvietnē var attēlot vismaz šāda veida saturu:

1. Attēli;2. Tabulas;3. Infografika;4. Video;5. Audio;6. Kustīgās bildes (.gif);7. Prezentācijas;8. Dokumenti, veidlapas.

Jānodrošina, ka Satura patērētājs visa veida saturu var apskatīt adaptīvajā dizainā ar iespēju atsevišķu saturu tuvināt (piemēram,inforgrafikas, attēli, dokumenti u. c.).

AP45 Satura administratoram jābūt iespējai augšupielādēt un pievienot vismaz šāda formāta datnes katram satura veidam:

1. Attēli – .jpg, .jpeg, .png, .gif formātā;2. Infografika – .jpg, .jpeg, .png, .pdf formātā (iegult

infografikas no infogr.am vai Venngage.com);3. Audio – .mp3, .mp4, .wav;4. Prezentācijas – .ppt, .pptx, .odp;5. Dokumenti – .pdf, .doc, .docx, .xls, .xlsx, .odt, .ods, .edoc

u. c. Video jāvar tikai iegult.Datņu atļauto izmēru jāspecificē ar Pasūtītāju analīzes laikā.Visi datņu formāti jāprecizē un jāsaskaņo ar Pasūtītāju izstrādes laikā.TVP jāvar definēt atļauto augšupielādējamo datņu formātu sarakstu. Platformas administrators var iekļaut vai izkļaut no atļauto datņu formātu saraksta konkrētu formātu.Veicot datņu augšupielādi tīmekļvietnē, TVP veic pārbaudi, vai konkrētās datnes formātu ir atļauts augšupielādēt. Pārbaudi veic gan pēc paplašinājuma, gan pēc MIME type. Veicot datņu augšupielādi tīmekļvietnē, TVP veic pārbaudi, vai

Obligāta






konkrētā datne nesatur ļaunatūru.Jānodrošina, ka Satura administrators var ievietot tīmekļvietnē statistikas informāciju par kopējo lapas apmeklējumu.Satura administratoram būs iespēja prioritizēt rakstu secību, mainot konkrēto ierakstu kārtību.Satura administratora norādītajiem rakstiem nodrošināma runas sintēze, izmantojot KISC uzturēto runas sintēzes pakalpi.

3.4.2. Publicēšana





SP20 Satura patērētājiem pie katra raksta tiek attēlots rakstu publicēšanas vai publicēšanas un atjaunošanas datums un laiks.

AP46 Katram rakstam ir jāsatur publicēšanas vai, ja raksts tiek atjaunots, publicēšanas un atjaunošanas datums un laiks. Datumiem jāveidojas automātiski, un Satura administrators tos nedrīkst rediģēt.Datumiem jābūt formātā dd.mm.gggg hh:mm. Datumu ir jāvar ievadīt arī no kalendāra.

Obligāta

N/a AP47 Satura administratoram, veidojot rakstu, ir jābūt iespējai norādīt raksta atpublicēšanas datumu un laiku. Brīdī, kad iestājas

Obligāta






norādītais datums un laiks, raksts nav redzams Satura patērētājam, bet saturs tiek saglabāts Satura administratora vidē. Jānodrošina, ka vizuāli atšķirīgi tiek attēlots saturs, kurš jau ir publicēts un kurš vēl nav publicēts.

N/a AP48 Satura administratoram jābūt iespējai sagatavotam melnrakstam noteikt automātisku tā publicēšanas un atpublicēšanas datumu un laiku. Brīdī, kad iestājas norādītais datums un laiks, raksts kļūst redzams Satura patērētājam.

Obligāta

3.4.3. Paziņojumu attēlošana





SP21 Tīmekļvietnē jānodrošina informatīvais paziņojuma logs, kurš tiek atvērts pirms tīmekļvietnes sākumlapas atvēršanas, ja Satura administrators tādu izveidojis.

AP49 Satura administratoram jābūt iespējai rediģēt paziņojuma logos attēloto informāciju, kā arī norādīt, pēc cik ilga laika logs automātiski aizveras.

Obligāta

SP22 Ja tīmekļvietne nav pieejama, tad Satura patērētājam tiek

AP50 Platformas administratoram ir jāvar izveidot paziņojumu par tīmekļvietnes nepieejamību.

Obligāta






attēlots informatīvs paziņojums par tīmekļvietnes nepieejamību.Satura patērētājiem tīmekļvietnes sākumlapā vismaz 2 (divas) dienas pirms plānotas tīmekļvietnes nepieejamības tiek attēlots informatīvs paziņojums par plānotu tīmekļvietnes nepieejamību.

Jānodrošina, ka Satura administrators ar īpašām tiesībām var izvēlēties, kad publicēt paziņojumu par tīmekļvietnes nepieejamību.Neplānotas tīmekļvietnes nepieejamības gadījumā informatīvs paziņojums jāievieto atbilstoši tehniskajām iespējām. Gadījumos, kad lietotņu servera līmenī ir tehniskas problēmas ar satura atrādīšanu, serverim nepieciešams parādīt statisku HTML lapu ar korekti attēlotu kļūdas paziņojumu.

N/a AP51 Kļūdu un sistēmas paziņojumi neatklāj Satura patērētājam nekādus liekus tehniskus datus par tīmekļvietni, kas varētu radīt drošības riskus. Detalizēti paziņojumi ir redzami tikai Platformas administratoram.

Obligāta

N/a AP52 Satura administratoriem ir jāsaņem paziņojumi par jebkādu Satura patērētāja darbību, kurai nepieciešama pretreakcija (piemēram, atbildes e-pasts).

Obligāta


3.4.4. Daudzvalodu saskarne





SP23 Satura patērētājam jāvar pārslēgties starp dažādām valodām, ja tas paredzēts tīmekļvietnē. Valodu pārslēgiem ir jābūt pieejamiem tīmekļvietnes galvenē, un tie jāattēlo visos tīmekļvietnes skatos. Veicot pārslēgšanos uz citu valodu, ir jāsaglabā esošais skats, izņemot gadījumus, kad konkrētais skats nav tulkots – tad Satura patērētājam jāattēlo sākumskats. Jānodrošina, ka, tīmekļvietni pārtulkojot, katrai valodai tiek veidota un attēlota atsevišķa saite. Jānodrošina, ka Satura patērētājiem pie teksta, kurš tulkots, izmantojot mašīntulkošanu, tiek attēlots paziņojums par mašīntulkotu tekstu gadījumos, kad satura

AP53 Satura administratoram jānodrošina iespēja norādīt, kuras sadaļas tīmekļvietnē nepieciešams tulkot. Satura administratoram satura tulkošana jānodrošina, izmantojot KISC mašīntulkošanas pakalpi. Jānodrošina, ka Satura administrators, izmantojot mašīntulkošanas pakalpi, var tulkot gan konkrētas lapas, gan teksta sadaļas.Jāparedz, ka Satura administrators sadaļu nosaukumus var tulkot gan manuāli, neizmantojot mašīntulkošanas pakalpi, gan arī tulkot automātiski, izmantojot mašīntulkošanas pakalpi, un nepieciešamības gadījumā rediģēt tulkoto tekstu. Jānodrošina, ka tekstu tulko mašīntulkošanas pakalpe, kad Satura administrators to ievada satura pārvaldības rīkā, nevis tad, kad Satura patērētājs veic pieprasījumu. Jāparedz, ka Satura administratoram ir iespēja mašīntulkošanas pakalpes veikto tulkojumu rediģēt pirms satura publicēšanas.Jānodrošina, ka iespējams tulkot arī, piemēram, Word, Excel datnes.

Obligāta






administrators nav veicis labojumus tulkotajā tekstā.

3.4.5. Biežāk uzdotie jautājumi





SP24 Satura patērētājam ir jābūt pieejamai sadaļai “Biežāk uzdotie jautājumi”, kurā apkopoti biežāk uzdotie jautājumi un uz tiem sniegtās atbildes. Jānodrošina, ka sadaļa tiek attēlota Satura patērētājam pārskatāmā veidā, piemēram, kā izkrītošas izvēlnes (akordeona princips).

AP54 Satura administratoram sadaļā “Biežāk uzdotie jautājumi” ir iespēja vismaz:

1. pievienot jautājumu un atbildi;2. dzēst jautājumu un atbildi;3. rediģēt jautājumu un atbildi;4. kopēt jautājumu un atbildi;5. mainīt jautājumu secību;6. publicēt un atpublicēt jautājumus un atbildes;7. izvēlēties iespēju saņemt atgādinājumus par sadaļas

“Biežāk uzdotie jautājumi” aktualizēšanu.Jānodrošina, ka Satura administrators var konfigurēt atgādinājumu saņemšanas biežumu vai atteikties no tiem vispār.

Obligāta

SP25 Jānodrošina jautājumu filtrēšana pēc kategorijām.

AP55 Satura administratoram ir jābūt iespējai norādīt jautājuma kategoriju. Jautājumiem un tiem saistītajām atbildēm automātiski jāgrupējas pēc norādītās kategorijas.

Obligāta


3.4.6. Vietnes karte





SP26 Tīmekļvietnē Satura patērētājam ir pieejama vietnes karte. Tajā tiek attēlota tīmekļvietnes aktīvo sadaļu struktūra hipersaišu veidā.Satura patērētājam, uzspiežot uz hipersaites, jāattēlo izvēlētā tīmekļvietnes sadaļa.

AP56 Vietnes karte tiek veidota automātiski no izveidotās tīmekļvietnes struktūras, un tajā tiek attēlotas tikai aktīvās jeb Satura patērētājiem publicētās sadaļas. Satura administratoram veicot izmaiņas tīmekļvietnes struktūrā, vietnes karte atjaunojas automātiski. Vietnes karte ir jāveido arī mašīnlasāmā formā (XML, RSS vai HTML) pilnai vietnes satura indeksēšanai.

Obligāta

3.4.7. Sociālie mediji





SP27 Satura patērētājam ir jāattēlo sociālo tīklu ikonas, kuras darbojas kā saites uz iestādes sociālā tīkla vietni. Ja Satura administrators norādījis, tad jāattēlo ministra sociālo tīklu kontu ikonas sadaļā, kurā publicēta informācija par

AP57 Satura administratoram ir jābūt iespējai rediģēt sociālo tīklu ikonas, kuras darbojas kā saites uz iestādes sociālo tīklu vietnēm:

1. pievienot ikonas;2. noņemt ikonas;3. ikonai pievienot attiecīgo iestādes sociālā tīkla konta

adresi.Ja Satura patērētājs nospiež sociālo tīklu ikonu, jaunā logā ir

Obligāta






ministru. jāatveras attiecīgajai iestādes sociālo tīklu vietnei. Jānodrošina, ka Satura patērētājs par to tiek informēts ar paziņojumu.

SP28 Satura patērētājam ir jābūt iespējai dalīties ar tīmekļvietnē esošu saturu savā sociālā tīkla kontā, uzspiežot uz sociālo tīklu ikonām pie satura (piemēram, raksta, attēla u. c.), kur tās ir izvietotas. Satura patērētājam jānodrošina iespēja noņemt attēlu no satura, kuru publicēt.

AP58 Satura administratoram jābūt iespējai pie satura (piemēram, raksta, attēla u. c.) izvietot sociālo tīklu ikonas, uz kurām uzspiežot, Satura patērētājam būs iespēja dalīties ar to savā sociālā tīkla kontā. Ierakstam jāattēlojas ar korektu virsrakstu un rakstam pievienoto attēlu. ,

Obligāta

N/a AP59 Satura administratoram ir jābūt iespējai katram rakstam izveidot sociālajos tīklos publicējamo raksta versiju, kura ir raksta saīsinātā versija un definēts raksta attēls.Jānodrošina, ka katram rakstam ir iespēja izveidot sociālā tīkla versiju. Satura administratoram, izvēloties iespēju ar rakstu dalīties sociālajos tīklos, jāpiedāvā saīsinātā versija rediģēšanas režīmā.

Obligāta

N/a AP60 Satura administratoram, veidojot rakstu, ir jābūt iespējai atzīmēt iespēju automātiski publicēt rakstu sociālajos tīklos un norādīt, kuros sociālajos tīklos tas jāpublicē. Pirms teksta publicēšanas sociālajos tīklos Satura administratoram obligāti ir

Obligāta






jānorāda publicējamā satura pavadošais teksts. Ja tiek izvēlēta šāda iespēja, brīdī, kad raksts tiek publicēts tīmekļvietnē, raksts automātiski publicējas arī norādītajos iestādes sociālajos tīklos, vēlams ar rakstam pievienoto vai manuāli pievienotu attēlu. Jānodrošina, ka Satura administratoram ir iespēja piesaistīt API atslēgas (angļ. val. API key), lai nodrošinātu satura automātisku publicēšanu sociālajos tīklos.

3.4.8. Darba laiks




SP29 Satura patērētājam tīmekļvietnē ir jāattēlo iestādes darba laiks un iestādes filiāļu darba laiki, ja iestādei ir filiāles. Jānodrošina, ka iestāžu filiāļu darba laiki var atšķirties. Jānodrošina, ka Satura patērētājam, izvēloties un atverot konkrētu iestādes filiāli, tiek attēloti tikai konkrētās filiāles kontakti un darba laiks. Tāpat, izvēloties kartē kādu iestādes filiāli, tiek attēlots filiāles darba laiks, adreses un kontakttālrunis.

AP61 Platformas administratoram ir jābūt iespējai administrēt kalendāru, kas tiks saistīts ar iestāžu darba laiku.Platformas administratoram ir jābūt iespējai vismaz:

1. norādīt brīvdienas (sestdiena, svētdiena);

2. norādīt pirmssvētku dienas;3. norādīt svētku dienas.

Obligāta





Nedēļu pirms valsts svētkiem Satura patērētājam pie iestādes darba laika ir jāattēlo iestādes darba laiks pirmssvētku un svētku dienā. Satura patērētājam ir jāattēlo iestādes pašreizējais stāvoklis atkarībā no iestādes darba laika – atvērts vai aizvērts.

Satura administratoram ir jābūt iespējai vismaz:1. norādīt iestādes/filiāļu/klientu

apkalpošanas centru darba laiku darba dienās;

2. norādīt iestādes/filiāļu/klientu apkalpošanas centru darba laiku brīvdienās (sestdienā, svētdienā);

3. norādīt iestādes/filiāļu/klientu apkalpošanas centru darba laiku pirmssvētku dienās.

3.4.9. Kontaktinformācija




SP30 Jānodrošina, ka Satura patērētājam kontaktinformācija tiek attēlota strukturētā veidā pa nodaļām vai struktūrvienībām.Jānodrošina, ka Kontaktu sadaļā tiek izšķirtas vairākas apakšsadaļas:

1. Kontaktinformācija par Iestādi – iestādes kopējais tālrunis, oficiālais e-pasts, darba laiks, karte, adrese, nokļūšanas iespējas

AP62 Jānodrošina, ka Satura administrators no CIVIS var saņemt vismaz šādu informāciju par iestādes darbiniekiem:

1. vārds;2. uzvārds;3. tālrunis;4. e-pasts;5. filiāle, struktūrvienība.

Izstrādes laikā jāprecizē no CIVIS saņemamās

Obligāta





atbilstoši MK 611.2. Kontaktinformācija par darbiniekiem, par katru darbinieku norādot vismaz – vārdu, uzvārdu, tālruni, e-pastu, filiāli, struktūrvienību, amatu, foto (ja pievienojies Satura administrators). Jānodrošina, ka iestāžu darbinieku saraksts tiek attēlots sadalījumā pa nodaļām.3. Ja Satura administrators norādījis, tad jāpublicē arī cita kontaktinformācija, piemēram, kontaktinformācija medijiem u. c.

Jānodrošina, ka Satura patērētājam kontaktu sadaļā tiek attēlots meklētājs ar iespēju meklēt darbinieku kontaktos.

informācijas apjoms, datu kopas un saņemšanas biežums. Ja iestāde neizmanto CIVIS vai CIVIS nav pieejams, informāciju jāvar ievadīt manuāli. Jānodrošina, ka kontaktu sadaļā iespējams ievietot arī darbinieku fotogrāfiju.

n/a AP63 Jānodrošina, ka Satura administrators no CIVIS var saņemt informāciju par iestādes darbinieku prombūtni.

Obligāta

n/a AP64 Jānodrošina, ka gadījumos, kad satura administrators vēlas ievadīt papildu informāciju par darbinieku (piemēram, ja darbinieks ir atvaļinājumā, norāda informāciju, kas šo darbinieku aizvieto un ar ko var sazināties)

Obligāta





manuāli. AP65 Jānodrošina iespēja satura administratoram

saņemt kontaktinformāciju no citām iestāžu iekšējām sistēmām datu regulārai saņemšanai un atjaunošanai.

Nākotnes prasība

SP31 Jānodrošina, ka Satura patērētājam attēlotais tālruņa numurs ir kā aktīva saite, uz kuras uzspiežot, no mobilā telefona ir iespējams uzreiz piezvanīt. Jānodrošina, ka, uzspiežot uz attēlotās e-pasta adreses, tā tiek atvērta jau e-pasta formā (kā “mail:to” saite), kuru uzreiz iespējams nosūtīt konkrētajam adresātam.

AP66 n/a Obligāta

3.4.10. Kartes attēlošana




SP32 Jānodrošina, ka tīmekļvietnē iespējams attēlot karti.Satura patērētājam ir jābūt iespējai tīmekļvietnē

AP67 Jānodrošina, ka kartes attēlošanas nodrošināšanai izmanto geolatvija.lv iegultās

Obligāta





izvietoto karti atvērt citās lietojumprogrammās (piemēram, Waze, Google maps utt.).

kartes funkcionalitāti.Jānodrošina, ka Satura administrators kartē vizuāli var atzīmēt iestādes vai tās filiāļu atrašanās vietas (norādot adresi, koordinātas u. tml.). Jānodrošina, ka kartes marķierim iespējams pievienot informācijas logu ar tekstuālu, grafisku materiālu un hipersaitēm.Jānodrošina, ka kartes lietošana ir obligāta tīmekļvietnē vietā, kur tiks norādītas iestādes un filiāļu atrašanās vietas. Jānodrošina, ka karti var ievietot arī citās tīmekļvietņu sadaļās, piemēram, informējot par pasākumu.

3.4.11. Pieteikšanās jaunumiem





SP33 Iestādes tīmekļvietnē Satura patērētājam jābūt iespējai pieteikties saņemt jaunumus e-

AP68 Satura administratoram tīmekļvietnes slēgtajā daļā ir jābūt iespējai iespējot/atspējot iespēju pieteikties jaunumu saņemšanai e-pastā.

Obligāta






pastā un iespējai iepazīties ar iestādes personu datu apstrādes politiku.Lai pieteiktos jaunumiem, Satura patērētājam ir jāvar ievadīt sava e-pasta adresi un jāvar izvēlēties kategorijas, par kurām vēlas saņemt jaunumus savā e-pastā. Jānodrošina, ka Satura patērētājs var pieteikties jaunumiem gan uz konkrētu sadaļu, gan uz visas tīmekļvietnes jaunumiem.E-pasta adreses ievades laukam ir jānodrošina standarta e-pasta adreses formas validācija. Gadījumā, ja validācija ir neveiksmīga, Satura patērētājam jāattēlo kļūdas paziņojums. Jānodrošina iespēja, ka Satura patērētājs var atteikties no jaunumu saņemšanas.

Satura administratoram tīmekļvietnes slēgtajā daļā jābūt iespējai iegūtos datus (vismaz e-pasts, jaunumu kategorija) kārtot, atlasīt un eksportēt .xlsx formātā.Satura administratoram ir jāvar vismaz:

1. rediģēt pieteikšanās jaunumiem formas tekstu un pievienot vai dzēst jaunumu kategorijas;

2. iestatīt laiku un periodiskumu, kad nākotnē konkrēto jaunumu nosūtīt Satura patērētājam;

3. pievienot e-pasta šablonus (ar vizuālo noformējumu);4. iespējot/atspējot iespēju pieteikties jaunumu

saņemšanai e-pastā.

SP34 E-pasta sūtījumā, kurš tiek izsūtīts AP69 Pēc e-pasta ievades uz norādīto e-pasta adresi automātiski Obligāta






Satura patērētājam, ir jābūt pieejamai saitei, kura nodrošina iespēju atteikties no jaunumu saņemšanas e-pastā.

jānosūta e-pasta adreses apstiprinājuma pieprasījums (e-pasta vēstule ar apstiprinājuma saiti). Ja persona apstiprina savu e-pasta adresi, nospiežot uz apstiprināšanas saites, tad tās e-pasts tiek pievienots sarakstam, kuram tiek sūtīti jaunumi par konkrēto kategoriju.Ja Satura patērētājs neapstiprina e-pasta adresi, tad uz konkrēto e-pasta adresi jaunumu e-pasti netiek sūtīti. Pieteikuma e-pasta adrese, kura nav apstiprināta, Platformā pēc 24 (divdesmit četrām) stundām jādzēš fiziski.Satura patērētājam ir jābūt iespējai vēlreiz pieteikties jaunumu saņemšanai. Jaunumu e-pasti tiek izsūtīti atbilstoši parametros noteiktajam izsūtīšanas periodam (piemēram, katru otrdienu plkst. 12:00) par iepriekšējā laika periodā konkrētās Satura patērētāja norādītās kategorijas izmaiņām, ja tādas ir bijušas. Izsūtīšanas laikam ir jābūt konfigurējamam parametram.Jāparedz, ka, ja Satura patērētājs ir pierakstījies uz jaunumiem par vairākām kategorijām, tad tiek sūtīts viens e-pasts, kurā ietverti jaunumi par vairākām kategorijām. E-pastu nosūtīšanai jābūt kā fona procesam, tie nedrīkst ietekmēt Platformas darbību. Izstrādes laikā jāvienojas par e-pastu izsūtīšanas detalizētu kārtību (vai katrai iestādei ir savs






atsevišķs e-pasts, vai arī Platformā ir vienots e-pasts jaunumu izsūtīšanai).

3.4.12. Notikumu kalendārs





SP35 Jānodrošina iespēja tīmekļvietnē attēlot kalendāru.Jānodrošina iespēja kalendāra ierakstus attēlot gan kalendārā, gan kā atsevišķu sarakstu. Satura patērētājam kalendārā jāvar apskatīt tajā ievietotos notikumus. Jānodrošina, ka Satura patērētājam, uzbraucot ar kursoru uz konkrēta datuma, tiek attēlots iznirstošs logs ar konkrētajā dienā paredzētajiem pasākumiem. Kalendārā datumam, ja tajā paredzēts kāds notikums, vizuāli jāatšķiras no datumiem,

AP70 Jānodrošina, ka Satura administrators var veikt šādas darbības:1. izveidot kalendāra notikumu (piemēram, semināru,

mācības, pasākumu u. c.) un saglabāt, to nepublicējot;2. publicēt kalendārā dažāda veida notikumus gan

kalendāra veidā, gan saraksta veidā;3. izvēlēties, kurus notikumus publicēt sākumlapā;4. rediģēt izveidotos notikumus;5. kopēt notikumus;6. izveidot regulārus notikumus, kuriem iespēja norādīt

regularitāti, kas automātiski tiek attēlota kalendārā;7. dzēst izveidotos notikumus.

Kalendārā jāvar uzstādīt dažādus parametrus (ievadot notikumu, Satura administrators var izvēlēties, kādus parametrus kalendārā norādīt):

1. pasākuma veids;2. pasākuma nosaukums;

Obligāta






kuros notikumi nav plānoti.Kalendārā ievadītos notikumus jāvar atlasīt pēc tēmas (piemēram, sports, kultūra, finanses, jaunajiem uzņēmējiem utt.) un pēc pasākuma norises vietas (piemēram, Rīga, Saldus, Jelgava utt.).Jānodrošina, ka, mainot tēmas un norises vietas, kalendārs dinamiski pārlādējas, attēlojot tikai izvēlētā veida notikumus konkrētajā norises vietā.Nospiežot kalendārā uz konkrēta notikuma, tiek atvērts notikuma satura ieraksts.

3. pasākuma norises vieta (izvēle no klasifikatora – pilsēta, iela, mājas numurs; var papildināt ar komentāru, piemēram, “Ziemeļblāzma”, Valsts ieņēmumu dienesta galvenā ēka utt.);

4. pasākuma norises datums un laiks;5. pasākuma norises ilgums;6. pieteikšanās termiņš;7. pieteikšanās veids;8. notikuma attēlošanas kalendārā laiks (netiek attēlots

Satura patērētājam);9. saite uz, piemēram, tiešraidi, vēsturiskajiem

notikumiem, galeriju;10. cik ilgi pasākumam jāattēlojas tīmekļvietnes sākumlapā

(netiek attēlots Satura patērētājam).Izstrādātājam ar Pasūtītāju izstrādes laikā jāvienojas par maksimālajām vērtībām, kuras Satura administrators var iestatīt informācijas attēlošanai kalendārā.Izstrādātājam ar Pasūtītāju izstrādes laikā jāvienojas par kalendāra vizuālo noformējumu un attēlojumu.

n/a AP71 Jānodrošina, ka Satura administrators var ievietot datus kalendārā no citas sistēmas (piemēram, iestādes biznesa sistēmas), norādot saiti no sistēmas uz TVP. Jānodrošina, ka caur saiti ir iespējams iegūt tikai kalendāra formātam atbilstošus datus.

Nākotnes prasība

SP36 Satura patērētājam, izmantojot AP72 N/a Obligāta






mobilās ierīces ar Android un iOS (iCalendar v2.0) operētājsistēmām, apskatot notikumu un nospiežot uz pogas “Pievienot savam kalendāram”, jābūt iespējai notikumu pievienot savam kalendāram – MS Outlook, Google Calendar, iCal. Citu operētājsistēmu ierīcēm šādas funkcijas nodrošināšana tiks vērtēta kā papildu opcija.

3.4.13. Pieteikšanās pasākumiem





SP37 Jānodrošina iespēja kalendārā izvietotajiem pasākumiem pieteikties elektroniski tiešsaistē, ja Satura administrators ir šādu iespēju aktivizējis. Jānodrošina, ka

AP73 Satura administratoram jābūt iespējai norādīt pieteikšanās veidu konkrētam pasākumam:

1. pieteikšanās tiešsaistē; 2. norādīt kontaktinformāciju, kuru izmantojot satura

patērētajam jāsazinās, lai pieteiktos pasākumam.Ja tiek izvēlēta pieteikšanās tiešsaistē, tad pieteikšanās formā

Obligāta






viens Satura patērētājs var pieteikt vairākas personas uz vienu pasākumu vienlaicīgi.Pēc pieteikšanās pasākumam Satura patērētājam jāsaņem paziņojums savā e-pastā par to, ka Satura patērētājs pasākumam pieteicies. Nospiežot “Iesniegt”:

jāattēlo paziņojums par to, ka pieteikums ir saņemts un informācija par pieteikumu jānosūta uz Satura patērētāja norādīto e-pastu, vai:

kļūdas gadījumā jāattēlo kļūdas paziņojums un informācija par turpmākajām darbībām.

jāparādās vismaz šādai informācijai un datu laukiem: 1. pasākuma nosaukums (automātiski);2. pasākuma datums un laiks (automātiski);3. vārds un uzvārds (aizpildāms datu lauks); 4. e-pasts (aizpildāms datu lauks).

Norādot pieteikšanās kontaktinformāciju:1. ja tiek norādīts e-pasts, tad tai jābūt kā aktīvai saitei e-

pasta nosūtīšanai;2. ja tiek norādīts tālruņa numurs, tad mobilajās ierīcēs ar

zvana funkciju, uzspiežot uz šī numura, Satura patērētājam ir iespēja zvanīt un pieteikties.

n/a AP74 Jānodrošina, ka Satura administrators var pievienot QR kodu, kuru nosūtīt Satura patērētājam, kurš pieteicies uz konkrētu pasākumu. QR kods tiek ģenerēts uz konkrētu pasākumu, nevis uz konkrētu apmeklētāju.

Nākotnes prasība


3.4.14. Baneru attēlošana





SP38 Tīmekļvietnē izvietojamiem baneriem ir jāparedz divi izvietošanas veidi:

1.slīdoša lente – vizuāli vienā vietā pēc kārtas tiek parādīti vairāki šai vietai piesaistītie baneri; 2.statiskie – vienai vietai piesaistīts viens baneris (piemēram kampaņas banneris).

Baneriem ir pievienotas hipersaites, uz kurām nospiežot, Satura patērētājam jaunā pārlūkprogrammas logā tiek atvērta piesaistītā vietne. Satura patērētājam jānodrošina attēlojams paziņojums par to, ka informācija tiks atvērta jaunā logā.

AP75 Satura administratoram ir jābūt iespējai:1. pievienot jaunus banerus;2. rediģēt banera lenti;3. dzēst banerus;4. regulēt lentes ātrumu (baneru maiņas ātrumu); 5. apskatīt baneru statistiku.

Jānodrošina, ka tīmekļvietnē izvietojamais baneris ir ar definētu izmēru un ievietošanas kārtību (visas Platformas ietvaros).Izstrādātājam ar Pasūtītāju jāsaskaņo baneru standarta izmērs un izvietošanas kārtība tīmekļvietnēs.

Obligāta

N/a AP76 Jānodrošina baneru pārvietošanas iespējas tīmekļvietnes Obligāta






ietvaros (piemēram, pārvietot starp sadaļām, savstarpēji mainīt vietām baneru lentā).

N/a AP77 Baneriem jāvar pievienot saites, uz kurām noklikšķinot Satura patērētājam atveras, piemēram, iestādes tīmekļvietnes lapa, kas satur informāciju par īstenoto projektu vai konkrētā laika periodā īstenotās kampaņas tīmekļvietni.

Obligāta

N/a AP78 Pārlūkprogrammā baneru ielāde attēlošanai jāveic tikai pēc tīmekļvietnes pārējā satura ielādes.

Obligāta

3.4.15. Prezentācijas un dokumenti





SP39 Satura patērētājam pieejamos dokumentus, veidlapas un prezentācijas jāvar lejupielādēt uz darbstacijas.

AP79 Satura administratoram jāvar norādīt katrai datnei vismaz nosaukumu, datumu un datumus, no kura līdz kuram datne tiks publicēta tīmekļvietnē. Satura administratoram jābūt iespējai:

1. dzēst datnes;2. rediģēt datnes.

Veicot datņu augšupielādi tīmekļvietnē, TVP veic pārbaudi, vai konkrētās datnes formātu ir atļauts augšupielādēt.Veicot datņu augšupielādi tīmekļvietnē, TVP veic pārbaudi, vai

Obligāta






konkrētās datnes nesatur ļaunatūru.

3.4.16. Anketas





SP40 Jānodrošina anketu attēlošana Satura patērētājam.Jānodrošina anketu aizpildīšanas iespēja. Pēc anketas aizpildīšanas Satura patērētājam jāattēlo paziņojums ar pateicību par dalību.Pēc anketas aizpildīšanas jānodrošina Satura patērētājam izvēlēties anketēšanas rezultātus saņemt e-pastā (ja Satura administrators iespējojis šādu funkcionalitāti). E-pasta ievades

AP80 Tīmekļvietnē ir jābūt iespējai izveidot un publicēt anketas. Izstrādātājam ir jāpiedāvā anketu formātu veidi. Anketas formā ir jābūt iespējai pievienot dažādus laukus, norādot obligātos laukus, lauka tipus un ievadāmo simbolu skaitu.Jāvar:

1. ievadīt anketas nosaukumu;2. ievadīt aprakstu par anketu;3. norādīt anketas darbības termiņu;4. izveidot dažādu tipu jautājumus (gan atvērta tipa, gan

ar atbilžu variantiem, ar iespēju atzīmēt vairākus atbilžu variantus, atbildes skalā, atbildes režģī u. c.);

5. jautājumiem jāvar izveidot apakšjautājumi atkarībā no atbildes varianta;

6. pievienot attēlus.

Obligāta






laukiem tiek veikta e-pasta adreses formas validācija.Vienu anketu Satura patērētājs no vienas interneta ierīces (datora, mobilā tālruņa u. tml.) var aizpildīt tikai vienu reizi. Pārbaude tiek veikta izmantojot sīkdatnes.Jānodrošina iespēja Satura patērētājam:

1.apskatīt anketēšanas rezultātus uzreiz pēc anketas aizpildīšanas, ja Satura administrators ļāvis tos apskatīt;2.apskatīt anketēšanas rezultātus iestādes tīmekļvietnē, ja rezultātus paredzēts publicēt tikai pēc anketēšanas noslēgšanas;3.saņemt e-pastā anketas rezultātus;4.dalīties ar anketu sociālajos

Anketu funkcionalitātei ir jābūt pietuvinātai, piemēram, Google anketu (Google Forms) funkcionalitātei ar iespēju izveidot dažāda veida jautājumus un nosacījumus.Satura administratoram ir jābūt iespējai anketas vismaz:

1. izveidot;2. publicēt;3. rediģēt;4. saglabāt nepublicējot;5. dzēst;6. kopēt;7. norādīt anketas publicēšanas/atpublicēšanas datumu.

Anketēšanas rezultātus Satura administratoram jāvar apskatīt Satura administratora vidē, jāvar tos izgūt .xlsx un .csv formātā un nosūtīt uz iestādes e-pastu. Par anketu uzglabāšanas ilgumu Satura administratoru darba vidē jāvienojas detalizētas analīzes laikā ar Pasūtītāju.Satura administratoram jābūt iespējai izvēlēties rezultātus attēlot uzreiz pēc Satura patērētāja anketas aizpildīšanas vai pēc anketēšanas darbības termiņa beigām.Jānodrošina aptauju analīzes rīki, piemēram, automātiska diagrammu veidošana.Satura administratoram jābūt iespējai izvēlēties anketēšanas rezultātu attēlošanas veidu (stabiņu diagramma, aplis utt.). Šos






tīklos, ja šāda funkcija konkrētai anketai ir pieejama.

rezultātus jāvar attēlot tīmekļvietnē un/vai nosūtīt e-pastā tiem Satura patērētājiem, kuri izvēlējušies rezultātus saņemt e-pastā. Satura administratoram ir jāvar izveidot informatīvu paziņojumu, kas tiek attēlots Satura patērētājam pēc anketas aizpildīšanas.Jānodrošina, ka Satura administrators var norādīt katrai anketai piesaistītu e-pastu, uz kuru tiek saņemtas visas aizpildītās anketas.Satura administratoram jābūt iespējai iespējot/atspējot funkcionalitāti Satura patērētājam ar anketu dalīties sociālajos tīklos. Izstrādātājam jāizvērtē iespēja izmantot EU Survey risinājumu.

n/a AP81 Satura administratoram jābūt iespējai izveidot anketas, kurās nepieciešama Satura patērētāju autentificēšanās, izmantojot vienotās pieteikšanās moduli.

Nākotnes prasība


3.4.17. Vakanču attēlošana





SP41 Tīmekļvietnē ir jāattēlo iestādē pieejamās vakances pārskatāmā sarakstā ar iespēju izvērst un savērst katru vakanci. Jānodrošina, ka Satura patērētājs var pieteikties vakancei, nosūtot savu CV uz norādīto kontaktinformāciju pie vakances.Vakanču detalizēts attēlošanas veids jāspecificē analīzes laikā.

AP82 Iestādes tīmekļvietnē ir jāattēlo informācija par pieejamajām vakancēm. Informāciju par aktuālajām vakancēm jāvar saņemt no CIVIS vai, ja iestāde neizmanto CIVIS vai CIVIS nav pieejams, informāciju jāvar ievadīt manuāli. Izstrādes laikā ar Pasūtītāju un CIVIS Projekta komandu ir jāsaskaņo datu apmaiņas risinājums un no CIVIS saņemamo un tīmekļvietnē publicējamo datu kopa, kā arī manuāli ievadāmo datu lauku veids un saturs.

Obligāta


3.4.18. Pieteikšanās konsultācijai





SP42 Jānodrošina iespēja tiešsaistē pieteikties konsultācijai.

AP83 Jānodrošina Satura administratoram iespēja iespējot vai atspējot Satura patērētājiem pieteikšanoskonsultācijai tiešsaistē.Pieteikšanās formai jātiek izveidotai atbilstoši prasībai “Formas” šī dokumenta 3.3.2. sadaļā.

Obligāta

3.4.19. Satura saglabāšanas iespēja





SP43 Jānodrošina, ka tīmekļvietnes saturu (t. sk. meklēšanas rezultātus) var saglabāt un lejupielādēt dažādos formātos, piemēram, Excel, .csv, .pdf, kā arī, kur iespējams, jāpievieno atvērto datu principam atbilstoši, tai skaitā mašīnlasāmi formāti.

AP84 Jānodrošina, ka Satura administrators var administrēt iespējas saturu lejupielādēt (iespēju Satura patērētājam atļaut konkrēto saturu lejupielādēt).

Obligāta


3.4.20. Hipersaišu attēlojums





SP44 Jānodrošina, ka Satura patērētājiem hipersaites tiek attēlotas vizuāli atšķirīgi no pamatteksta.

AP85 Jānodrošina, ka Satura administratoram ir iespēja atzīmēt tekstā hipersaites, ievadot saturu satura pārvaldības rīkā. Jānodrošina, ka hipersaites tiek vizuāli izceltas atbilstoši katras tīmekļvietnes iestādes vienotajās vadlīnijās definētajiem toņiem.

Obligāta

3.4.21. Izdrukas





SP45 Satura patērētājam jābūt iespējai izdrukāt tīmekļvietnes rakstu vai lapas saturu. Izdrukai jābūt pārskatāmai un loģiski sakārtotai. Izdrukā saturam jābūt izkārtotam tāpat kā tīmekļvietnē.

AP86 Jānodrošina iespēja ģenerēt satura (raksta) vai citas veidnes (piemēram, veidlapas, citi dokumenti) izdrukājamās veidlapas .pdf formātos, nodrošinot satura attēlošanu izdrukai piemērotā formātā.

Obligāta


3.4.22. RSS





SP46 Satura patērētājam jāattēlo RSS plūsmas kā aktīva saite.

AP87 Tīmekļvietnē jānodrošina RSS plūsma jaunumu un kalendāra notikumu izmaiņu izplatīšanai.

Obligāta

3.5.Satura administratora darba videPrasības identifikators




N/a AP88 Satura administratoriem jābūt pieejamai Satura administratora saskarnei latviešu un angļu valodā.Satura administratoriem jānodrošina iespēja pārslēgties starp valodām, nezaudējot datus.

Obligāta

N/a AP89 Satura administratoru vidē ir jābūt iestrādātam WYSIWYG (What You See Is What You Get) teksta redaktoram – ievietojot saturu var apskatīt, kā tas izskatīsies TVP publiskajā vidē.

Obligāta

N/a AP90 Jāparedz iespēja katram satura administratoram teksta ievades vidi daļēji pielāgot.

Obligāta

N/a AP91 Pieeja Satura administratora videi ir iespējama tikai pēc autentifikācijas izmantojot vienoto pieteikšanās moduli Latvija.lv.

Obligāta






N/a AP92 Satura administratoram ar īpašām tiesībām ir jābūt iespējai definēt tiesības uz konkrētu satura moduli vai tīmekļvietnes sadaļu iestādes Satura administratoriem. Jānodrošina, ka satura administrators ar īpašajām tiesībām definētās tiesības var arī noņemt.

Obligāta

N/a AP93 Jānodrošina, ka Satura administratora ar īpašām tiesībām vide atšķiras no Satura administratoru vides. Satura administratora ar īpašām tiesībām ir paplašināta darba vides funkcionalitāte, saturot savas iestādes lietotāju pārvaldības daļu.

Obligāta

N/a AP94 Jānodrošina satura rediģēšanas un ievadīšanas iespējas ārpus darba vietas, ņemot vērā drošības prasības. Jānodrošina sadaļu pārvietošanas iespējas sadaļu koka ietvaros, tām sadaļām, kuras pievienojies Satura administrators.

Obligāta

3.6.Platformas administratora darba videPrasības identifikators




N/a AP95 Platformas administratoram jānodrošina iespēja Platformā veikt Obligāta






vismaz šādas darbības:1. jaunu tīmekļvietņu uzstādīšana, satura pamata struktūras

izveidošana, tīmekļvietnei pieejamā datu glabāšanas apjoma konfigurēšana;

2. iestāžu Satura administratoru ar īpašām tiesībām kontu izveide;

3. Platformas programmatūras atjauninājumu uzstādīšana (centralizēti visām tīmekļvietnēm);

4. tīmekļvietņu uzstādīšana no rezerves kopijām (individuāli);

5. jaunu spraudņu pievienošana sistēmā u. c.

Platformas administratoram jānodrošina iespēja pārslēgties starp valodām (latviešu, angļu), nezaudējot datus.Jaunu tīmekļvietņu izveidošana un uzstādīšana ir jānodrošina kā automatizēts process pēc sekojoša scenārija:

1. Platformas administrators izvēlas veidot jaunu vietni.2. Platformas administrators norāda jaunās vietnes pagaidu

adresi domēnā vraa.gov.lv, piemēram, iestade.vraa.gov.lv.

3. Platformas administrators norāda satura pamata struktūras sagatavi.

4. Platformas administrators norāda iestādes e-pasta adresi, uz kuru tiks nosūtīts satura administratora ar īpašām






tiesībām vārds ar saiti konta izveidei.5. Pēc šīs informācijas apstiprināšanas Platforma automātiski

uzstāda jauno vietni, izveido struktūru un satura administratoru ar īpašām tiesībām, kā arī nosūta saiti konta izveidei uz norādīto e-pasta adresi. Šīs saites derīguma termiņš ir 24 stundas.

Citas Platformas administratora funkcijas:1. Iespēja atkārtoti izsūtīt e-pastu ar saiti konta izveidei.2. Konfigurēt Platformā izvietoto Iestāžu tīmekļvietņu

domēnu vārdus.N/a AP96 Platformā jābūt grafiskai administrēšanas saskarnei, kas

nodrošina, piemēram, šādu funkcionalitāti: 1. iespēja aplūkot Platformas komponenšu versijas; 2. konfigurēt datu apmaiņas saskarņu iestatījumus; 3. konfigurēt lietotāju sesijas noildzi (timeout) un maksimālo

sinhrono darbību izpildes laiku (laiku, pēc kura Platforma pārtrauc darbību, ja nav sasniegts rezultāts) (ievērot prasību 4.7. nodaļā SEC01 “Identifikācijas datu drošība”);

4. rediģēt visus satura patērētāja saskarnē attēlotos tekstus - aprakstus, lauku nosaukumus un kļūdu paziņojumu tekstus;

5. veikt biznesa administrēšanu (veidņu, klasifikatoru u. c. konfigurēšanu).

Šajā sadaļā iekļaujami visi pārējie konfigurējamie parametri, ko

Obligāta






paredz Tehniskās specifikācijas prasības vai kas nepieciešami sekmīgai Platformas atbalstāmo procesu realizācijai.

N/a AP97 Jābūt iespējai Platformu ieslēgt apkopes režīmā. Apkopes režīmā Platformas administratoru un Satura administratoru pieprasījumi nav jāapkalpo, bet ir jāizvada statisks informatīvs paziņojums, kurš Platformas administratorus un Satura administratorus informē par Platformas nepieejamību. Platformai jānodrošina iespēja apziņot Satura patērētājus un Satura administratorus par paredzamajiem apkopes darbiem šādos veidos:

1. parādot Platformas administratora rediģējamu ziņojumu brīdī, kad Satura patērētājs pieslēdzas Platformai;

2. noteiktā laikā parādot Platformas administratora rediģējamu ziņojumu visiem aktīvajiem Satura patērētājiem.

Obligāta

N/a AP98 Pieeja Platformas administratora videi ir iespējama tikai pēc autentifikācijas. Ir jāparedz šāda autentifikācijas iespēja:

1. izmantojot Vienoto pieteikšanās moduli;2.

Obligāta

N/a AP99 Platformas administratoram ir jābūt iespējai definēt tiesības uz konkrētu tīmekļvietni katram Satura administratoram ar paplašinātām tiesībām un Satura administratoram. Jānodrošina, ka Platformas administrators definētās tiesības var arī noņemt un

Obligāta






anulēt (gadījumos, kad tiek saņemta informācija par darba tiesisko attiecību pārtraukšanu).

N/a AP100 Platformas administratoram jānodrošina iespēja pārvaldīt kalendāru, kurš tiek izmantots Platformas ietvaros, nodrošinot iespēju atzīmēt svētku dienas, brīvdienas un pirmssvētku dienas, tādējādi Platformas ietvaros uzturot faktisko darba dienu kalendāru. Izstrādes ietvaros analīzes fāzē jāizvērtē iespēja saņemt datus par svētku dienām, brīvdienām un pirmssvētku dienām no Atvērto datu portāla.

Obligāta

3.7.MeklētājsPrasības identifikators




SP47 Jānodrošina Satura patērētājam meklēšanas funkcionalitāte.Jānodrošina, ka Satura patērētājam sākotnēji tiek attēloti meklēšanas rezultāti

AP101 Platformā gan publiskajā, gan slēgtajā vidē jānodrošina meklēšanas rīks, kurš ir statisks un viegli pamanāms visos skatos un kurš nodrošina pilnteksta meklēšanu gan metatagi, gan pievienotajos dokumentos, rakstu un datņu nosaukumos, izvēlnēs, gan pārējā Platformas saturā u. c.

Obligāta






konkrētajā tīmekļvietnē un pēc tam pārējie meklēšanas rezultāti no citām tīmekļvietnēm, kuras izvietotas uz TVP.Jānodrošina, ka Satura patērētājs var izvēlēties – meklēt šajā lapā vai visā Platformā.Jānodrošina, ka Satura patērētājs meklēšanas rezultātus var atlasīt vismaz pēc šādiem kritērijiem:

1. pēc sadaļas;2. satura tēmas;3. pēc satura veida

(jaunumi, informācija presei, vienkārša lapa u. c.)

4. pēc laika perioda (iespēja norādīt datuma periodu – no, līdz), nenorādot termiņu, meklēšana tiek veikta visā termiņā.

Jānodrošina, ka sākotnēji tiek attēloti meklēšanas rezultāti konkrētajā tīmekļvietnē un secīgi pārējie meklēšanas rezultāti no

Meklētājam jānodrošina iespēja meklēt, izmantojot:1.ātrās meklēšanas iespēju, ietverot 2-3 parametrus;2.detalizēto meklēšanu, piemēram, pēc šādiem meklēšanas kritērijiem:

2.1.vārdiem (t. sk. dažādos locījumos);2.2.frāzēm;2.3.daļējiem vārdiem;2.4.izmantojot aizstājējsimbolus;2.5.u. c. līdz 5 kritērijiem, kuri var tikt detalizēti analīzes un izstrādes fāzē.

Izstrādātājam analīzes un izstrādes fāzē jāprecizē un ar Pasūtītāju jāsaskaņo ātrās un detalizētās meklēšanas kritēriji. Jānodrošina, ka meklēšanas rezultātos ir redzams, kāda veida rezultāts ir atrasts, piemēram, raksts, video, utt., kā arī jānorāda atlasīto ierakstu kopējais skaits.Jānodrošina, ka meklēšanas rezultāti tiek prioritizēti pēc meklēšanas kritērijam svarīgākā rezultāta. Piemēram, ja Satura patērētājs meklēšanas kritērijā ir ierakstījis pakalpojuma nosaukuma daļu, sākotnēji meklēšanas rezultātos tiek attēloti pakalpojumi, kuri satur šādu kritērijā minēto nosaukumu un tikai pēc tam secīgi tiek attēlotas aktualitātes, jaunumi u. c. Piemēram, ja tiek meklēts konkrēts cilvēka vārds, tad sākotnēji






citām tīmekļvietnēm, kuras izvietotas uz TVP. Jānodrošina arī meklēšanas rezultātu prioritizēšana vienas tīmekļvietnes ietvaros.

tiek attēlota informācija no kontaktinformācijas sadaļas, kura satur konkrēto cilvēka vārdu, un tikai tad ziņas vai citi raksti.Ja Satura patērētājs izmanto meklētāju kādā konekrētā sadaļā, meklēšanas rezultāti tiek attēloti sākotnēji no šīs sadaļas un tikai pēc tam no visas tīmekļvietnes un citām tīmekļvietnēm.

N/a AP102 Jāizvērtē jau gatavu meklēšanas servisu izmantošana vai jāpiedāvā prasībām atbilstoša meklētāja izstrāde.Norāde tehniskajam piedāvājumam: Piedāvājumā jāiekļauj piedāvātā risinājuma iegādes izmaksas, izmaksas izstrādes ietvaros un uzturēšanas laikā.

Obligāta

N/a AP103 Jānodrošina, ka Satura administratoram meklēšanas rīkā ir iespēja papildināt un modificēt tā meklēšanas iespējas, pārvaldot kritēriju laukus. Jāparedz iespēja Satura administratoram apkopot meklētāja statistiku, noskaidrojot, kādi ir vismeklētākie atslēgvārdi.

Obligāta

N/a AP104 Jānodrošina, ka meklēšanas funkcija darbojas arī pievienotajās datnēs (piemēram, MS Word, MS Excel, .pdf utt.).

Obligāta

N/a AP105 Meklēšanas laukā, rakstot atslēgvārdu, jānodrošina vaicājuma ieteikuma (Autosuggest) iespēja – no meklēšanas indeksa tiek piedāvāti atbilstošie atslēgvārdi un to kombinācijas.

Obligāta


3.8.SEO (Search engine optimization) funkciju nodrošinājumsPrasības identifikators




N/a AP106 Platformas publiskās vides saturam ir jānodrošina SEO prasības 1 .

Izstrādātājam piedāvājumā jāapraksta, kā tiks nodrošināta SEO funkcionalitāte iestāžu tīmekļvietnēm.

Izstrādātājam Projekta ietvaros jāizstrādā vadlīnijas, kā Satura administratoriem jāveic satura izveide un strukturēšana atbilstoši labākajai SEO praksei.

Obligāta

3.9. Indeksēšanas servissPrasības identifikators




SP48 Satura patērētājam jāvar veikt meklēšanu vietnes ietvaros pēc satura ar sekojošām papildu iespējām:

1. meklēt vairākus vārdus, kas nav secīgi;

AP107 Platformā jānodrošina konfigurējama indeksēšanas funkcionalitāte (piemēram, search apache SOLR vai ekvivalents). Tiek nodrošināts uzglabātās informācijas indeksēšanas vai ekvivalents mehānisms ātrai informācijas (metadatu un

Obligāta

1 https://support.google.com/webmasters/answer/7451184?hl=en

https://support.google.com/webmasters/answer/7451184?hl=en






2. meklēt vārdus, kas cits citu izslēdz;

3. meklēt vārdus locījumos (neskaitot latviešu valodai specifiskās līdzskaņu mijas).

4. Meklēšanas indeksācijā un meklēšanā netiek ņemtas vērā didaktiskās zīmes (tās tiek aizstātas ar attiecīgo latīņu burtu).

dokumentu) atrašanai.Indeksēšanai jānotiek katras tīmekļvietnes ietvaros.Platformas administratoram grafiskajā saskarnē jāvar veikt vismaz šādas konfigurācijas iespējas:Pievienot un pārvaldīt indeksēšanas serverus, ar iespēju norādīt:

1.servera nosaukumu;2.pieslēgumu (ar vai bez autentifikācijas), par katru pieslēgumu norādot:

2.1.HTTP protokols;2.2.servera pieslēguma vieta;2.3.servera pieslēguma ports;2.4.indeksēšanas instances lokācija serverī;2.5.pieprasījuma ar indeksēšanas serveri noilgums; 2.6.indeksēšanas pieprasījuma ar indeksēšanas serveri noilgums;2.7.automātisko indeksēšanas pieprasījumu noilgums indeksēšanas serverī;2.8.autentifikācijas dati:

2.8.1.lietotājvārds;2.8.2.parole;






3.iespējot/atspējot serveri;4.iespējot/atspējot multi vietņu savienojamību.

Veidot un pārvaldīt katra servera indeksus, par katru indeksu norādot:

1.indeksa nosaukumu;2.datu avotus (Visu Platformā iespējamo datu veidus, piemēram, Satura administratorus, datnes, saturu, formu pieteikumus, vārdnīcu ierakstus u. c.; 3.katram datu avotam jāvar norādīt :

3.1.satura šablonus/satura veidus, kuros darbojas indekss, piemēram, aktualitātes, kalendāra ieraksti, galerija, veidlapas u. c.;3.2.valodas, kurās tiek indeksēts saturs;

4.katram datu avotam jāvar pievienot un pārvaldīt indeksējamos laukus ar iespēju:

4.1.norādīt indeksēšanas lauka veidu:4.1.1.Decimāldaļskaitlis;4.1.2.Datums;4.1.3.Fulltext;4.1.4.Vesels skaitlis;4.1.5.Simbolu rinda;






4.1.6.Loģiskais datu tips;4.1.7.String Ngram;4.1.8.Fulltext Tokens;4.1.9.Fulltext Unstemmed;4.1.10.Fulltext Phonetic;4.1.11.Fulltext Omit norms;4.1.12.Fulltext Ngram;4.1.13.Storage-only;

4.2.norādīt lauka indeksēšanas prioritāti;5.indeksēšanas secību;serveri;6.indeksa uzdevuma izpildes apjomu (cik vienības tiek indeksētas viena uzdevuma izpildes laikā);7.pārvaldīt procesus, kas apstrādā datus pirms un pēc indeksēšanas un meklēšanas:

7.1.iespējot/atspējot:7.1.1.Izslēgt neaktīvus Satura administratorus un neaktuālas satura vienības no indeksēšanas7.1.2.Pievienot pielikumu indeksētajai vienībai7.2.pārvaldīt procesu secību:7.2.1.Indeksēšanas priekšapstrāde;






7.2.2.Pieprasījuma priekšapstrāde; 7.2.3.Pieprasījuma pēcapstrāde.

3.10. Informācija par iestādes pakalpojumiemPrasības identifikators




SP49 Satura patērētājam jānodrošina publisko pakalpojumu attēlošana strukturētā un pārskatāmā veidā.Satura patērētājiem par iestādes sniegto pakalpojumu tīmekļvietnē jāattēlo vismaz:

1.pakalpojuma nosaukums;2.pakalpojuma apraksts;3.iespēja uzsākt pakalpojumu tīmekļvietnē, un pēc tam Satura patērētājs tiek aizvests uz pakalpojuma izpildes vietu (piemēram, www.latvija.lv);

AP108 Jānodrošina, ka Satura administrators iestādes tīmekļvietnē var pievienot vismaz šādu informāciju par iestādes pakalpojumiem:

1. pakalpojuma nosaukums;2. pakalpojuma apraksts (jānodrošina integrācija starp

Pakalpojumu katalogu, kas pieejams valsts pārvaldes pakalpojumu portālā Latvija.lv un TVP, lai nodrošinātu, ka TVP tiek saņemta informācija par iestādes sniegtajiem pakalpojumiem);

3. saite uz konkrētā pakalpojuma izpildes vietu (piemēram, www.latvija.lv);

4. lejupielādējamas veidlapas.Sadaļā “Pakalpojumi” Satura administrators var veikt šādas darbības:

1. pievienot publiskos pakalpojumus, to aprakstus;2. rediģēt informāciju par iestādes pakalpojumiem;3. kopēt publiska pakalpojuma aprakstu;

Obligāta

http://www.latvija.lv/

http://www.latvija.lv/






4.jāizceļ pakalpojumi, kuri pieejami kā e-pakalpojumi;5.lejupielādējamas veidlapas.

Rekomendācijas pakalpojumu sadaļas attēlošanai skatīt Biznesa prasību specifikācijas dokumentā.Izstrādes laikā ar Pasūtītāju jāvienojas par labāko publisko pakalpojumu attēlošanas veidu. Jānodrošina, ka tām iestādēm, kuras nesniedz publiskos pakalpojumus, šī sadaļa tīmekļvietnē netiek attēlota.

4. dzēst publiskos pakalpojumus, to aprakstus;5. pievienot saites uz saistītajiem pakalpojumiem;6. mainīt pakalpojumu secību sarakstā u. c.

Izstrādātājam analīzes laikā ar Pasūtītāju jādetalizē publisko pakalpojumu publicēšanas iespējas.

3.11. Statistikas pārskatiPrasības identifikators




N/a AP109 Jāuzkrāj statistikas dati par tīmekļvietņu Satura patērētāju apmeklējumiem. Jāuztur kā atvērtā formāta datu kopa -

Obligāta






statistikas dati par Satura patērētāju apmeklējumiem.Jānodrošina, ka uzkrātie dati par Satura patērētāju apmeklējumu tiek nodoti uz Atvērto datu portālu.

N/a AP110 Statistikas uzkrāšana un attēlošana ir jāveic vismaz par šādiem rādītajiem:

1. Satura patērētāju skaits pa tīmekļvietnēm un to sadaļām skaitliskā un grafiskā formā;

2. Satura patērētāju sadalījums un skaits atkarībā no pieslēguma vietas – valsts, pilsētas, reģiona;

3. sadaļas ar lielāko klikšķu skaitu;4. uzturēšanās ilguma lapu navigācijas statistika;5. iekšējos un ārējos tīmekļvietņu lietotājus;6. izmantotās iekārtas tīmekļvietnes apmeklējumam;7. like un Share statistika sadaļām, lapām, ziņām;8. atslēgvārdu statistika;9. lejupielāžu statistika;10. iespēja norādīt laika periodu, par kuru nepieciešama

statistika;11. meklējums caur Google un citām

meklējumprogrammām, nonākot tīmekļvietnē.Jānodrošina, ka Satura administratoram ir iespēja statistikas datus eksportēt vismaz .xlsx un .csv formātā – Satura administratoram par savu tīmekļvietni, savukārt Platformas administratoram visu iestāžu statistikas datus. Visi statistikas uzkrāšanas datu veidi jāsaskaņo ar Pasūtītāju izstrādes laikā.

Obligāta


3.12. Iepirkumu informācijas publicēšana Prasības identifikators




SP50 Jānodrošina, ka Satura patērētājiem tiek attēlota pamatinformācija par iepirkumiem atsevišķā sadaļā tīmekļvietnes 2. līmenī. Jānodrošina, ka tiek attēlota arī saite pie katra iepirkuma uz konkrēto iepirkumu elektronisko iepirkumu sistēmā.

AP111 Jānodrošina, ka pamatinformācija par iestādes publiskajiem iepirkumiem tiek automātiski saņemta no Atvērto datu portāla uz TVP un attēlota attiecīgajā iestādes tīmekļvietnē. Jānodrošina, ka tiek pievienota saite uz konkrēto iepirkumu elektronisko iepirkumu sistēmā. Jānodrošina, ka gadījumos, ja integrācija starp Atvērto datu portālu un TVP nestrādā un informāciju par iepirkumiem nav iespējams saņemt automātiski, Satura administrators manuāli var ievadīt un publicēt tīmekļvietnē informāciju par iestādes publiskajiem iepirkumiem.Izstrādes laikā Izstrādātājam, Pasūtītājam un VRAA jāvienojas par no Atvērto datu portāla saņemamo datu apjomu un jāsaskaņo datu apmaiņas risinājumu.Izstrādes laikā Izstrādātājam un Pasūtītājam jāsaskaņo informācijas attēlošana publiskajā vidē.

Obligāta


3.13. Lietotāju pārvaldībaPrasības identifikators




N/a AP112 Jānodrošina ērta Platformas administratoru un Satura administratoru autentifikācija izmantojot Vienotās pieteikšanās moduli;Izstrādātājam sistēmanalīzes laikā jāsaskaņo ar Pasūtītāju autentifikācijas veidi un risinājumi.

Obligāta

N/a AP113 Platformas administratoru un Satura administratoru autorizācija veicama, izmantojot TVP uzturētās Satura administratora vides lietotāju lomas un Platformā definētās tiesības lietotāju lomām.Ja sistēmā TVP netiks izstrādāta augstāk minētā funkcionalitāte, Izstrādātājam jānodrošina cits risinājums lietotāju autorizācijai un lomu uzturēšanai, pārvaldībai.

Obligāta

N/a AP114 Platformā un katras iestādes tīmekļvietnē jābūt pieejamai tiesību pārvaldības sadaļai, kas lietotājiem ar atbilstošām tiesībām ļauj definēt lietotāju lomu piekļuves tiesības. Piekļuves tiesības jādefinē, piemēram, pēc šādiem parametriem – informācijas resursa veida, Platformas sadaļas, veicamās darbības veida (lasīšana, rakstīšana, dzēšana, parakstīšanas, saskaņošanas), procesa soļiem un citiem parametriem, kas precizējami analīzes un izstrādes gaitā.

Obligāta

N/a AP115 Sākotnējā Platformas lomu un tiesību komplekta definēšana ir Obligāta






Izstrādātāja uzdevums. TVP jānodrošina vismaz šādas lietotāju lomas un to tiesības:

1. Satura patērētājs – lietotājs, kurš apmeklē jebkuru TVP izvietoto tīmekļvietni;

2. Satura administrators ar īpašām tiesībām – loma nodrošina pieeju datu apstrādes procesam, ar tiesībām ievadīt konkrētās tīmekļvietnes saturu, satura rediģēšanu, publicēšanu, atpublicēšanu un dzēšanu, veikt tīmekļvietnes struktūras izmaiņas, ko atļāvis Platformas administrators, veikt datu izmaiņu apstiprināšanu, korekciju vai dzēšanu. Satura administrators ar īpašām tiesībām ir savas pārstāvētās iestādes administrators, kurš var veidot pieejas tiesības citiem iestādes darbiniekiem un pārstāvjiem, kuri var veikt tīmekļvietnes satura ievadi, rediģēšanu, publicēšanu, atpublicēšanu un dzēšanu.

3. Satura administrators - loma nodrošina pieeju datu apstrādes procesam ar tiesībām ievadīt konkrētās tīmekļvietnes saturu, veikt satura rediģēšanu, publicēšanu, atpublicēšanu un dzēšanu.

4. Platformas administrators – ar šādu lomu Platformas administrators veic Platformas konfigurēšanas un uzturēšanas darbus. Platformas administrators var pārlūkot, pārvietot, dzēst repozitorija objektus (mapes, dokumentus un saites) un risināt piekļuves tiesību problēmas. Platformas administratoram ir nodrošinātas tiesības mainīt konfigurācijas parametrus. Var pievienot papildu moduļus tīmekļvietņu bāzes modulim. Uzstāda Platformas programmatūras atjauninājumus.






N/a AP116 Satura administratoram ar atbilstošām tiesībām jānodrošina iespēja izveidot iestādes darbinieku kontus un piešķirt lietotājiem lomas, nodrošinot piekļuvi Satura administratora videi.

Obligāta

3.14. Grafiskā lietotāju saskarnePrasības identifikators




SP51 Jānodrošina funkcijas vājredzīgajiem – krāsu maiņas funkcija un teksta versija:

1.krāsu maiņas funkcija nodrošina šādu stilu izvēlni un tīmekļvietnes attēlojuma maiņu:

1.2.melns teksts uz balta fona;1.3.balts teksts uz melna fona;

AP117 Izstrādātājam jāizstrādā un ar Pasūtītāju jāsaskaņo Platformas struktūras skices (wireframe). Skices jāsaskaņo ar Pasūtītāju pirms grafiskās lietotāju saskarnes izveides uzsākšanas. Ir jāizstrādā katras vizuāli atšķirīgās Platformas sadaļas gan satura, gan funkcionalitātes izvietojums. Izstrādājot Platformas struktūras izkārtojumu, jāņem vērā galalietotāju lietošanas scenāriji, Platformas biznesa procesi, lietojamības labās prakses principi un nodaļā 2.3 “TVP darbībureglamentējošie normatīvie akti” uzskaitītie normatīvie akti. Izstrādātājam skiču izstrādē jāpiesaista lietojamības speciālists un dizainers.

Obligāta






1.4.melns teksts uz dzeltena fona;1.5.dzeltens teksts uz melna fona;

2.teksta versija nodrošina teksta attēlojumu bez grafiskiem elementiem.

N/a AP118 Izstrādātājam ir jāizstrādā un ar Pasūtītāju jāsaskaņo grafiskais dizains gan Platformas publiskajai videi (iestāžu tīmekļvietnēm), gan slēgtajai videi. Dizaina izstrādes procesā Izstrādātājam regulāri, katra sprinta ietvaros, jāsaskaņo darba progress ar Pasūtītāju.

Obligāta

SP52 Jānodrošina, ka Satura patērētājam tiek attēlots navigācijas ceļš visās lapās, kas nosaka, kāda sadaļa/ekrānforma ir pašreiz atvērta.

AP119 Gan Platformas publiskajā vidē Satura patērētājiem, gan Satura administratora vidē Platformas administratoriem un Satura administratoriem jāattēlo navigācijas ceļš, kas nosaka, kāda sadaļa vai lapa ir pašreiz atvērta.

Obligāta

SP53 Sadaļām ir jābūt kā aktīvām saitēm, uz kurām uzejot Satura patērētājs publiskajā vidē nokļūst attiecīgajā lapas skatā.

AP120 Navigācijas ceļa sadaļām ir jābūt kā aktīvām saitēm, uz kurām uzejot Satura administrators slēgtajā vidē nokļūst attiecīgajā lapas skatā.

Obligāta






SP54 Jānodrošina, ka Satura patērētājam ir iespēja filtrēt vai kārtot sarakstus tīmekļvietnēs un lapās, kurās Satura administrators ir izveidojis filtrēšanas un kārtošanas iespējas.

AP121 Platformā izvietotajās tīmekļvietnēs (tām, kurām nepieciešams) Satura administratoram ir jābūt iespējai iespējot vai atspējot esošo datu vienumu sarakstu ierakstu filtrēšanas iespējas un ierakstu kārtošanas iespējas, piemēram, tām tīmekļvietnēm, kurās ir publicēti saraksti ar filtrēšanas iespējām. Jānodrošina, ka Satura administrators var definēt filtrus.Izstrādātājam sistēmanalīzes laikā jānosaka filtrēšanas parametri un jāsaskaņo ar Pasūtītāju.

Obligāta

3.15. Datu arhivēšanaPrasības identifikators




SP55 Nepieciešams Satura patērētājam attēlot iestādes rakstu arhīvu, ja konkrētā iestāde tādu uztur un ja Satura administrators to publicējis. Jānodrošina iespēja meklēt Satura patērētājam

AP122 Arhivēšanas funkcionalitātei jānodrošina Platformā esošo datu arhivēšana jeb sagatavošana pastāvīgai vai ilgstošai glabāšanai, atbilstoši saistītajiem normatīvajiem aktiem. Arhivēto datu katalogam jānodrošina meklēšana pēc to metadatiem un atdalīšana pēc to statusiem.

Obligāta






iestādes rakstu arhīvā.N/a AP123 Platformā jāuztur arhivēto datu katalogs, kurš par katru

arhivēto datni satur MK noteikumos Nr. 117 “Noteikumi par elektronisko dokumentu izvērtēšanas veidu, saglabāšanas kārtību un nodošanu Valsts arhīvam glabāšanā” paredzētos metadatus. Platformas administratoram ar atbilstošām tiesībām jānodrošina iespēja veidot glabājamo vienību nodošanas LNA arhivēšanas akta projektu, piesaistīt glabājamās vienības, iekļaut vai izkļaut arhivēšanas lietās atsevišķus dokumentus, nodot akta projektu parakstīšanai. Satura administratoram ar īpašām tiesībām jānodrošina iespēja iepazīties ar arhivēšanas akta informāciju un to saskaņot.

Obligāta

N/a AP124 Platformā jānodrošina automātiska auditācijas datu arhivēšana un manuāla dzēšana. Auditācijas datu arhivēšanas termiņu var konfigurēt Platformas administrators, termiņam jābūt konfigurējamam. Jānodrošina, ka arī auditācijas datu arhivēšanas un dzēšanas fakts tiek auditēts. Jānodrošina iespēja Platformas administratoram arhivētos datus atjaunot Platformā.

Obligāta

N/a AP125 Jānodrošina informācijas arhivēšana, izstrādes laikā Izstrādātājam ar Pasūtītāju jāsaskaņo ziņu arhivēšanas posmi

Obligāta






un arhivēšanas nosacījumi.Platformas administratoram ir jābūt iespējai konfigurēt laika posmu no raksta publicēšanas līdz arhivēšanai.

3.16. Lietojamības prasībasPrasības identifikators


USB01 Pārlūkprogrammu atbalsts Tīmekļvietnes funkcijām jābūt vienādi izpildāmām populārākajās pārlūkprogrammās (pēdējām divām stabilajām versijām uz TVP pilnvērtīgas funkcionalitātes nodošanas – pieņemšanas akta brīdi):

1. Chrome;2. Edge;3. Firefox;4. Safari;5. Opera;6. Internet Explorer.

Pārlūkprogrammās (klienta pusē) ir atļauts izmantot šādas tīmekļa tehnoloģijas: HTML, CSS, JavaScript, HTML5 paplašinājumus.

Obligāta

USB02 Atbalstāmās lietotāju operētājsistēmas

Platformai ir jānodrošina lietotāju darbs vismaz uz Windows, Linux un Mac saimes operētājsistēmās.

Obligāta




Platformai ir jānodrošina lietotāju darbs arī vismaz uz iOS un Android tālruņu operētājsistēmām (pēdējām divām stabilajām versijām uz TVP pilnvērtīgas funkcionalitātes nodošanas – pieņemšanas akta brīdi).

USB03 Spraudņu pārnesamība TVP spraudņi jāveido tā, lai tos vajadzības gadījumā varētu lietot citās TVP tīmekļvietnēs, izmantojot atkalizmantošanas principu.

Obligāta

USB03 Cilvēka un sistēmas mijiedarbības ergonomika

Izstrādātājam jānodrošina TVP adaptīvajā dizainā, ievērojot lietotājorientētu pieeju un iteratīvas izstrādes principu saskaņā ar Latvijas nacionālā standarta LVS EN ISO 9241-210:2016 “Cilvēka un sistēmas mijiedarbības ergonomika” 210. daļu “Cilvēkorientēta interaktīvo sistēmu projektēšana”.

Obligāta

USB04 TVP piekļūstamība Izstrādātājam jānodrošina TVP izvietoto tīmekļvietņu piekļūstamība saskaņā ar Latvijas nacionālā standarta EN 301549:2017 “IKT produktu un pakalpojumu piekļūstamības prasības Eiropas publiskajos iepirkumos” 9., 10. un 11. nodaļas prasībām.UZ TS izstrādes brīdi standartam EN 301549:2017 ir izstrādāti grozījumi ETSI/CEN/CENELEC EN 301 549 V2.1.22, Uz TS izstrādes brīdi grozījumi nav saistoši ES direktīvai, tomēr, jāņem vērā, ka tad, kad grozījumi tiks noteikti kā saistoši direktīvai, Izstrādātājam jānodrošina TVP piekļūstamība atbilstoši jaunajam standartam.

Obligāta

USB05 TVP piekļūstamība Izstrādātājam jānodrošina TVP izvietoto tīmekļvietņu lietojamība saskaņā ar Eiropas Parlamenta un Padomes Direktīvu (ES) 2016/2102 (26.10.2016.) par

Obligāta

2 Pieejams: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/02.01.02_60/en_301549v020102p.pdf




publiskā sektora struktūru tīmekļvietņu un mobilo lietotņu piekļūstamību.USB06 Saskarnes valoda TVP un tajā izvietoto tīmekļvietņu publiskās un iekšējās daļas saskarnei (t. sk.

kļūdu paziņojumiem) ir jābūt pieejamai latviešu un angļu valodā.Publiskajā daļā izvietotie paziņojumi jāattēlo Satura patērētāja izvēlētajā valodā (latviešu, angļu, krievu).

Obligāta

USB07 Reaģējošs dizains TVP un tajā izvietotās tīmekļvietnes ir jāveido pēc reaģējoša dizaina principiem, kas nodrošina vieglu un ērtu lietošanu dažādām ekrāna izšķirtspējām.

Obligāta

USB08 UTF-8 atbalsts Tīmekļvietnei ir jānodrošina UTF-8 kodējuma atbalsts gan teksta ievadē, gan izvadē.

Obligāta

USB09 Satura ievade Satura ievadei jābūt lietotājam intuitīvai. ObligātaUSB10 Lietojamība cilvēkiem ar

invaliditātiIzstrādātājam jāņem vērā ISO/IEC 40500:2012 standarts un papildus WCAG 2.1., lai veidotu tīmekļvietņu dizainu, nodrošinot tīmekļvietņu lietošanu labvēlīgāku personām ar dažādām funkcionālajām spējām.

Obligāta

USB11 Datu ievades ekrānformas Tīmekļvietņu datu ievades ekrānformas jāveido tā, lai padarītu datu ievadi pēc iespējas ērtāku, tajā skaitā, bet ne tikai nodrošinot klasifikatoru vērtību izvēli atbilstošajos laukos, datumu izvēli no kalendāra, iespēju izmantot vilkt un nomest (drag and drop) paņēmienu, ievadīto vērtību validāciju reālajā laikā, iespēju pārvietoties starp ievades laukiem, izmantojot tastatūras taustiņu “Tab”, rediģējot saturu no mobilās iekārtas u. c.

Obligāta

USB12 Lietotāju saskarnes lietojamība Platformai ir jāatbilst vismaz šādiem lietojamības kritērijiem: 1) Platformai ir jābūt saprotamai. Visiem lietotāja saskarnes elementiem

Obligāta




(navigācijas elementiem, ikonām, spiedpogām utt.) jābūt viegli uztveramiem un veidotiem atbilstoši industrijas labajai praksei. Platformā jāizmanto termini, kas sakrīt ar galalietotāju ikdienas darbā izmantojamajiem terminiem. Retāk izmantotajiem un sarežģītākajiem terminiem vai jēdzieniem jābūt skaidrojumiem. 2) Platformai ir jābūt viegli apgūstamai. Lietotāja palīdzības informācijai ir jābūt izstrādātai visām lomām pilnīgai, konteksta jutīgai, un tai jāizskaidro, kā paveikt tipiskos ikdienas uzdevumus. 3) Ar Platformu ir jābūt viegli operēt un jābūt veidotai vienotā stilā. Saskarnes elementiem jādarbojas konsistenti visās Platformas sadaļās. Lielākai daļai darbību jābūt atsaucamām (undo) un datu ievades kļūdām jābūt labojamām. Gadījumos, kad nav iespējas labot datus vai atgriezties pie iepriekšējā stāvokļa, jāparedz brīdinājumi pirms neatgriezeniskās darbības. Platformas saskarnei jābūt veidotai tā, lai tipiskās darbības neprasītu liekus klikšķus vai lieku pārslēgšanos starp dažādām ekrānformām. Datu ievades formām jāsatur datu validācijas kontroles.


3.17. Datu apmaiņaPrasības identifikators


DAP01 Integrācija ar geolatvija.lv TVP jānodrošina geolatvija.lv piedāvāto iegulto karšu izmantošana, tai skaitā adrešu, administratīvi teritoriālo vienību un piezīmju (izlecošajā logā) attēlošana uz kartes.

Obligāta

DAP02 Integrācija ar Publisko pakalpojumu katalogu

TVP jānodrošina datu izgūšana no Publisko pakalpojumu kataloga par iestādes publiskajiem pakalpojumiem, kas attēlojami pakalpojumu sadaļā – skatīt “3.10. Informācija par iestādes pakalpojumiem”.

Obligāta

DAP03 Datu nodošana Latvijas Atvērto datu portālam

Uzkrātie statistikas dati par tīmekļvietņu Satura patērētāju apmeklējumiem ir ar noteiktu regularitāti nododami Latvijas Atvērto datu portālam.

Obligāta

DAP04 Valodas pakalpju izmantošana TVP jānodrošina iespēja izmantot KISC nodrošinātās mašīntulkošanas pakalpes nodaļā “3.4.4. Daudzvalodu saskarne” aprakstītās funkcionalitātes realizācijai.

Obligāta

DAP05 Virtuālais asistents TVP jānodrošina iespēja izvietot tīmekļvietnēs KISC uzturētais virtuālais asistents. TVP izvietojama tīmekļvietņu apmeklētājiem pieejamā asistenta funkcionalitāte, savukārt virtuālā asistenta konfigurācijai un mācībām paredzētā satura pārvaldnieku funkcionalitāte tiks uzturēta atsevišķā lietotāja saskarnē, kas nav TVP platformas tvērumā.

Obligāta

DAP06 Datu saņemšana no Atvērto datu portāla

TVP jānodrošina iespēja saņemt informāciju par publiskajiem iepirkumiem, kuri no EIS tiek publicēti Atvērto datu portālā.

Obligāta

DAP07 CIVIS TVP jānodrošina vismaz šādu datu saņemšana no CIVIS:1. iestādes vakances, 2. iestādes darbinieku saraksts,

Obligāta




3. kontaktinformācija,4. iestādes darbinieku atalgojums, 5. iestādes struktūra.

DAP08 Citas sasaistes Izstrādātājam jāizvērtē cita veida sasaistes, kas var tikt identificētas detalizēts analīzes laikā ar citām sistēmām, piemēram, Vienoto Tiesību aktu projektu izstrādes un saskaņošanas portālu, kurā izvietoti visi tiesību aktu projekti, savukārt TVP tiks attēlotas saites uz konkrētiem tiesību aktu projektiem un iespēja pieteikties sabiedrības līdzdalībai.

Obligāta


4. NEFUNKCIONĀLĀS PRASĪBASŠajā sadaļā ir aprakstītas TVP 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ā. Nefunkcionālo prasību radītās izmaksas ir jāiekļauj funkcionālo prasību realizācijas izmaksās un finanšu piedāvājumā kā atsevišķa pozīcija nav jāizdala.

4.1.Prasības Tehniskajam piedāvājumamPrasības identifikators


NFP01 Piedāvājuma apraksta forma Tehniskajā 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 aprakstu, kā katra konkrētā prasība tiks īstenota.Norāde Tehniskajam piedāvājumam: Pretendentam šīs prasības realizācijas apraksts Tehniskajā piedāvājumā nav jāiekļauj.

Obligāta

NFP02 Prasību izpildes apraksts Prasī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 Izstrādātāja izpratne par prasības realizāciju. Prasību īstenošanas mehānisms vai rīki (līdzekļi), ar kuriem ir iespējams izpildīt prasību, ir jānorāda prasībās, kur tie faktiski ir pielietojami un tam ir saturiskā jēga. Norāde Tehniskajam piedāvājumam: Pretendentam šīs prasības realizācijas apraksts Tehniskajā piedāvājumā nav jāiekļauj.

Obligāta


4.2.Arhitektūras prasībasPrasības identifikators


Risinājuma uzbūve

ARH01 Atvērto standartu un atvērtā koda tehnoloģiju izmantošana

TVP izveidojama primāri izmantojot atvērtos standartus un atvērtā koda tehnoloģijas (piemēram, Drupal vai ekvivalents), nodrošinot tās atkalizmantošanas iespējas. Tehniskajā piedāvājumā Pretendentam jāiekļauj informācija par visām izmantotajām tehnoloģijām, tai skaitā jāsniedz tehnoloģiju izmantošanas nosacījumu apraksts tehnoloģijām, kas nav atvērtā koda tehnoloģijas. Izvēlētās tehnoloģijas nedrīkst radīt nekādus ierobežojumus TVP izmantošanai Projektā paredzētajiem mērķiem. Gadījumā, ja izvēlētās tehnoloģijas rada papildu licencēšanas vai cita veida izmaksas, Pretendentam tās jāiekļauj finanšu piedāvājumā (izmaksas izstrādes un ieviešanas laikā jāiekļauj kopējās izstrādes izmaksās, izmaksas, kas Pasūtītājam rodas pēc projekta beigām (projekta beigas 2021. gada 4. janvāris) jānorāda finanšu piedāvājumā atsevišķā pozīcijā par 1 gadu).

Obligāta

ARH02 Standarta SPS programmatūra TVP izstrādājama/ieviešama par pamatu izmantojot SPS standarta programmatūru, kas tirgū ir pieejama vismaz 3 (trīs) gadus un kuras izstrādātāju publicētā informācija neparedz pārtraukt izvēlētas SPS standarta programmatūras atbalstu tuvāko 5 (piecu) gadu laikā.

Obligāta

Funkcionalitāte

ARH03 Satura veidošana, pārvaldība un publicēšana

TVP jānodrošina satura veidošanas, pārvaldības un publicēšanas iespējas. Jābūt iespējai saturu saglabāt, to nepublicējot, lai veiktu satura saskaņošanu pirms

Obligāta




publicēšanas, kā arī saturu publicēt noteiktā datumā un laikā. Detalizētākas prasības sk. nodaļās 3.2. “Satura veidošana”, 3.3. “Satura pārvaldība” un 3.4. “Satura publicēšana”.

ARH04 Atbalsts moduļiem TVP jābūt papildināmai ar trešo pušu izstrādātiem moduļiem, kas paplašina izmantotās SPS standarta programmatūras funkcionalitāti.Jābūt nodrošinātai moduļu izstrādes dokumentācijai ar piemēriem vienotās platformas moduļu izstrādei. Dokumentācijai jāsatur vismaz šāda informācija - kā moduli izveidot (kādas funkcijas modulis var izsaukt pret platformu, kādas atbildes var saņemt), kā moduli var notestēt, kā moduli ievietot platformā, kā modulī realizēt datu apmaiņu ar iestādes pamatdarbības sistēmām.Iestāžu satura pārvaldniekiem jābūt iespējām arī pa jaunu izstrādātos moduļus izmanto TVP tīmekļvietnēs.

Obligāta

ARH05 Satura meklēšana un indeksēšana

TVP jānodrošina satura indeksēšana un meklēšana pēc atslēgvārdiem. Meklēšanai jāatbalsta iespēja meklēt pilnas frāzes, norādīt vārdus, kas nedrīkst parādīties, vai vārdus, kam jāparādās obligāti, ja tiek meklēts pēc vairākiem atslēgvārdiem.Meklētājam jāatbalsta locījumi un jāspēj meklēt, neņemot vērā diakritiskās zīmes.Meklēšana jānodrošina gan konkrētajā tīmekļvietnē, gan arī pārējās tīmekļvietnēs, kas izvietotas TVP (skatīt prasības nodaļā “3.7. Meklētājs”).

Obligāta

ARH06 Autentifikācija TVP jānodrošina Satura administratoru un Platformas administratoru autentifikācija, izmantojot VRAA Vienotās pieteikšanās moduli.

Obligāta




ARH07 Lietotāju pārvaldība un autorizācija

TVP jānodrošina atbalsts lietotāju pārvaldībai, tai skaitā lietotāju lomu definēšanai, kur katrai lomai ir citas piekļuves tiesības. TVP konfigurāciju un satura pārvaldību var veikt tikai autorizēti lietotāji. Satura pārvaldniekiem jābūt piesaistītiem konkrētām TVP izvietotām tīmekļvietnēm. Detalizētas prasības sk. nodaļās 3.5. “Satura administratora darba vide”, 3.6. “Platformas administratoradarba vide” un 3.13. “Lietotāju pārvaldība”.

Obligāta

ARH08 Nemainīgas saites uz Informācijas resursiem

Datu resursiem IS ir jāuztur statiskas saites, lai tās var izmantot kā atsauces citās IS.

Obligāta

ARH9 Publisko pakalpojumu kataloga datu attēlošana

TVP jāizstrādā modulis, kas integrēts ar VRAA uzturēto publisko pakalpojumu katalogu un lietotājiem attēlo informāciju par iestādes pakalpojumiem. Detalizētas prasības sk. nodaļā 3.10. “Informācija par iestādes pakalpojumiem”.

Obligāta

ARH10 Mašīntulkošanas pakalpes izmantošana

TVP jānodrošina iespēja nosūtīt sagatavoto vietņu satura vienības (teksta) nosūtīšanu KISC mašīntulkošanas pakalpei un atrādīt satura administratoram tulkojumu precizēšanai pirms tā publicēšanas. Detalizētas prasības sk. nodaļā 3.4.4. “Daudzvalodu saskarne”.

Obligāta

ARH11 Balss atpazīšanas pakalpes izmantošana

TVP jānodrošina audio satura vienību nodošana balss atpazīšanai un pārvēršanai tekstā atbilstošajai valodas pakalpei KISC balss atpazīšanas pakalpei.

Obligāta

ARH12 Balss sintēzes pakalpes izmantošana

TVP jānodrošina KISC uzturētā runas sisntēzes pakalpes izmantošana šādā veidā:1. Teksts tiek nosūtīts runas sintēzes pakalpei;2. No runas sintēzes pakalpes tiek asinhroni saņemta *.mp3 formāta audio

datne;3. Audio datne tiek atskaņota tīmekļa vietnes apmeklētājam.

Obligāta




ARH13 Balss sintēzes pakalpes izmantošana (pilnveidotais process)

Papildus iepriekšējā prasībā minētajam TVP jānodrošina iespēja grafiski atspoguļot, kurš vārds tiek atskaņots, kā arī iespēju tīmekļa vietnes apmeklētājam pārslēgt atskaņojamo vārdu vai rindkopu.

Nākotnes prasība

ARH14 Virtuālā asistenta izmantošana TVP jāizstrādā modulis, kas ļauj iestāžu tīmekļvietnēs izmantot KISC izstrādāto virtuālo asistentu.

Obligāta

ARH15 Ģeoportāla kartes izmantošana TVP jāizstrādā modulis Ģeoportāla iegulto karšu attēlošanai iestādes tīmekļvietnēs. Detalizētās prasības sk. nodaļā 3.4.10. “Kartes attēlošana”.

Obligāta

ARH16 Integrācija ar CIVIS TVP jāizstrādā moduļi CIVIS datu attēlošanai iestādes tīmekļvietnēs, tai skaitā iestādes vakanču, iestādes darbinieku saraksta, kontaktinformācijas, iestādes darbinieku atalgojuma, kā arī iestādes struktūras attēlošanai.Jāņem vērā ierobežojums, ka 2019. gadā ir plānots migrēt Pilotprojekta iestāžu tīmekļvietnes uz Platformu, taču CIVIS pilnā apjomā plānots nodot ekspluatācijā 2020. gada beigās, līdz ar to datu apmaiņas saskarnes izstrāde būs jānodrošina atbilstoši CIVIS laika grafikam. Turklāt CIVIS netiks izmantots pašvaldībās. Līdz ar to jānodrošina arī manuāla datu ievades iespēja Satura administratoriem iestāžu tīmekļvietnēs un programmatūras saskarne (API datu saņemšanai no pašvaldību informācijas sistēmām).

Obligāta

ARH17 Sociālie tīkli TVP jānodrošina modulis/iespēja dalīties ar iestādes tīmekļvietnēs publicēto saturu sociālajos tīklos. TVP jānodrošina iespēja iestādes tīmekļvietnē publicēt iestādes sociālo tīklu konta paziņojumus. Detalizētās prasības sk. nodaļā 3.4.7. “Sociālie mediji”.

Obligāta




ARH18 Audiovizuālais saturs TVP jānodrošina trešo pušu pakalpēs (piemēram, YouTube un Vimeo) izvietotā audiovizuālā satura iekļaušana iestādes tīmekļvietnēs.

Obligāta

ARH19 Integrācija ar Latvijas Atvērto datu portālu

TVP jānodod Latvijas Atvērto datu portālam iestāžu tīmekļvietņu apmeklējuma statistika.TVP jāizstrādā modulis publicēto iestādes iepirkumu attēlošanai tīmekļvietnē no Atvērto datu portāla. Detalizētās prasības sk. nodaļā 3.12. “Iepirkumuinformācijas publicēšana”.TVP jānodrošina Latvijas Atvērto datu portālā publicēto iestāžu reģistru datu attēlošanu.

Obligāta

ARH20 Piemērotība meklētājprogrammām

TVP izvietotajām tīmekļvietnēm jābūt tehniski un saturiski pielāgotām (SEO) indeksēšanai populārās tīmekļa meklēšanas sistēmās. Detalizētās prasības sk. nodaļās 3.7. “Meklētājs”, 3.8. “SEO (Search engine optimization) funkcijunodrošinājums” un 3.9. “Indeksēšanas serviss”.

Obligāta

ARH21 Mērogojamība Sistēmas arhitektūrai jāparedz iespēja palielināt veiktspēju, pievienojot papildu aparatūru (jaudu). Pievienojot papildu serverus (vai procesoru kodolus/atmiņas apjomu), Sistēmai jānodrošina veiktspējas pieaugums par vismaz 70 % no papildu pievienotās jaudas.

Obligāta

ARH22 Iegultie e-pakalpojumi TVP jānodrošina latvija.lv izpildāmo e-pakalpojumu izvietošana TVP tīmekļvietnēs, izmantojot latvija.lv piedāvātos iegulšanas mehānismus.

Obligāta

ARH23 E-formu izmantošana TVP jānodrošina projektā "Pakalpojumu sniegšanas un pārvaldības platforma" (PSPP) izstrādātā e-formu risinājuma izmantošana.

Obligāta


4.3.Pieejamības prasībasPrasības identifikators


ACC01 TVP darbības nepārtrauktība Atbilstoši Ministru kabineta 2015. gada 28. jūlija noteikumiem Nr. 442 “Kārtība, kādā tiek nodrošināta informācijas un komunikācijas tehnoloģiju sistēmu atbilstība minimālajām drošības prasībām“ TVP atbilst paaugstinātas drošības sistēmai.TVP ir jānodrošina nepārtraukta pieejamība gan Satura patērētājiem, gan Satura administratoriem un Platformas administratoriem 24 (divdesmit četras) stundas diennaktī un 7 (septiņas) dienas nedēļā. TVP darbspējas laikam jābūt ne mazākam kā 99,50 %. Kopīgais maksimālais dīkstāvju ilgums mēnesī 3 stundas un 35 minūtes. Kopīgais maksimāli pieļaujamais dīkstāvju ilgums gadā 1 diena 19 stundas un 49,8 minūtes. Šajā periodā ietilpst Izstrādātāju, uzturētāju plānotas aktivitātes.Prasība nav attiecināma uz sistēmas darbības pārtraukumiem, kas radušies tehniskās infrastruktūras bojājumu rezultātā.

Obligāta

ACC02 Augsta pieejamība Platformai ir jābūt noturīgai pret atsevišķu moduļu kļūmēm. Tīmekļvietnei jāsaglabā darbaspēja un jānodrošina satura un pakalpojumu nodrošināšana vismaz šādos scenārijos:

1. atsevišķas infrastruktūras iekārtas (serveru, datu glabāšanas ierīču, tīkla ierīču) atteices gadījumā;

2. sakaru kanāla kļūdas vai darbības pārtraukuma gadījumā;3. operāciju sistēmas vai tehniskās kļūdas kādā (vienā) no serveriem

gadījumā;4. datubāzes servera, pielietojumu servera jeb pielietojuma programmatūras

kļūdas gadījumā.

Obligāta




Prasība ir attiecināma arī uz sistēmas pakalpojumu nepieejamību, kas ir radusies piekļuves atteices (DoS, DDoS) uzbrukumu gadījumos (piekļuve var tikt ierobežota ārpus Latvijas teritorijas reģistrētiem piekļuves mēģinājumiem).Papildus jānodrošina, lai jebkuras personas, mehānisma vai procedūras kļūme nerada iespēju piekļūt neizpaužamai informācijai (ierobežotas pieejamības datiem).

ACC03 Rezerves kopēšana Tīmekļvietnei jānodrošina iespēja veikt Tīmekļvietnes rezerves kopēšanu un konsistentas kopijas iegūšanu bez tīmekļvietnes darba apturēšanas. Ja tīmekļvietnes rezerves kopēšanai nepieciešama IS un/vai infrastruktūras komponenšu darbināšana īpašā režīmā, tad šāda režīma ieslēgšana/izslēgšana jānodrošina ar komandrindas saskarnes palīdzību.Tīmekļvietnei ir jābūt atjaunojamai no rezerves kopijas ne ilgāk kā 4 (četru) stundu laikā, un dati nedrīkst pazust vairāk kā par 1 (vienu) pēdējo tīmekļvietnes darbības stundu. Tīmekļvietnes atjaunošanai no rezerves kopijas nepieciešamajā laikā nav ieskaitāma infrastruktūras uzstādīšana un konfigurēšana.Izpildītājam izstrādes līguma ietvaros jāsagatavo, jāsaskaņo un jāiesniedz Pasūtītājam tīmekļvietnes Rezerves kopēšanas un darbības atjaunošanas plāns.Pretendentam plānojot TVP programmatūras arhitektūru un rezerves kopēšanu jāparedz:

1. automātiska datu rezerves kopēšana uz citu tehnisko infrastruktūru (data backup);

2. rezerves kopiju veidošana, nepārtraucot tehniskās infrastruktūras darbību, paredzot iespēju noteiktā laika posmā atjaunot datus (online backup);

3. iespēja pārslēgties no primārās tehniskās infrastruktūras uz rezerves tehnisko infrastruktūru (fault recovery);

Obligāta




4. datu atjaunošana ārkārtas situāciju apstākļos (disaster recovery); 5. datubāzes servera klasterēšanas iespējas;6. tīmekļa un lietojumprogrammu servera klasterēšanas iespējas.

ACC04 Sistēmas darbības atjaunošanas plāns

Izstrādātājam jāsagatavo TVP darbības atjaunošanas plāns gan atsevišķu moduļu kļūmes gadījumā, gan TVP atteices gadījumā.

Obligāta

ACC05 Sistēmas darbības monitorings Izstrādātājam jānodrošina iespēja veikt attālinātu sistēmas uzraudzību ar automatizētiem monitoringa rīkiem, kas ļauj konstatēt sistēmas kļūdas vai darbības pārtraukumus.

Obligāta

4.4.Veiktspējas prasībasPrasības identifikators


PERF01 Lietotāju skaits TVP ir jāspēj vienlaicīgi uzturēt 20 000 lietotāju, kas ikkatru minūti pieprasa jaunu tīmekļvietnes lapu. Tīmekļvietnes atbildes laiks, šajā laikā ģenerējot lapu (neskaitot laiku, ko paņem datu sūtīšana pa tīklu), ir vidēji zem 500 ms uz pieprasījumu un 95 % atbilžu ir zem 1000 ms.

Obligāta

PERF02 Ekrānformu atbildes laiks TVP tīmekļvietnei ar paredzēto vienlaicīgo lietotāju skaitu 95 % gadījumā ir jānodrošina šādas veiktspējas prasības:

1. ievadformā ievadīto datu saglabāšanu datubāzē un attēlošanā ne vairāk kā 1 (vienas) sekundes laikā;

Obligāta




2. informācijas attēlošanu tādos sarakstos, kas ir iebūvēti un neprasa meklēšanas parametru ievadi – ne vairāk kā 1 (vienas) sekundes laikā;

3. informācijas attēlošanu dokumentu, kontaktu u. c. meklēšanas sarakstos ar specifisku meklēšanas parametru/atslēgu ievadīšanu – ne vairāk kā 3 (trīs) sekunžu laikā;

4. pārskatu sagatavošanu ar līdz 3 (trīs) atlases kritērijiem – ne vairāk kā 5 (piecu) sekunžu laikā;

5. kļūdu skaits pie maksimālās slodzes nedrīkst pārsniegt 2 %.Visos gadījumos, ja attēlošanas laiks pārsniedz 3 (trīs) sekundes, lietotājs ir jāinformē ar attiecīgu paziņojumu vai grafisku attēlojumu.

4.5.Infrastruktūras prasībasPrasības identifikators


INFR01 TVP izmitināšana TVP tiks izmitināta IeM IC uzturētajā Loģiski vienotajā datu centrā, kurš nodrošina:1. uz x86 procesoru arhitektūru bāzēta konverģēta datu centru infrastruktūru,

kas ietvers visus (t. sk. virtualizētos) TVP darbināšanai nepieciešamos infrastruktūras elementus, piemēram – atbilstošas telpas, klimata kontroli, UPS, tīklošanu, serverus, disku masīvus, virtualizācijas platformu u. tml.;

2. tiks izmantota VmWare virtualizācijas platforma, kas varēs tikt konfigurētas atbilstoši augstas pieejamības nodrošināšanai, varēs nodrošināt TVP virtuālo serveru izvietošanu 2 (divos) ģeogrāfiski attālinātos datu centros

Informatīva




(Rīgas robežās);3. rezerves kopēšanai būs iespēja izmantot virtuālo serveru

momentuzņēmumus (image-based backup) Loģiski vienotā datu centra ietvaros, kā arī tiks nodrošināti atbilstoši tīkla savienojumi, lai varētu izmantot Valsts elektronisko sakaru pakalpojumu centra (atbilstoši 27.02.2018 Ministru kabineta instrukcijai Nr. 1) nodrošinātos rezerves kopēšanas pakalpojumus.

INFR02 Pretendentam piedāvājumā jānorāda kopējā virtuālo serveru/serveru klastera un tīkla iekārtu slēguma shēma, norādot katra virtuālā servera prasības (RAM apjoms, CPU kodolu skaits, diska vietas apjoms, diska veiktspējas prasības).

Obligāta

INFR03 Pretendentam piedāvājumā jāiesniedz tīmekļvietnes tehniskās infrastruktūras resursu, tehniskās infrastruktūras komponenšu funkciju un paredzamā vidējā nepieciešamā jaudas/apjoma specifikācija, lai nodrošinātu šajās tehniskajās prasībās minētās funkcionālās, veiktspējas un pieejamības prasības.

Obligāta

INFR04 Vietņu otrā līmeņa tīmekļa domēna vārds

Iestāde savā īpašumā esošām tīmekļvietnēm izmanto vienotu domēna vārdu un elektroniskā pasta adrešu veidošanas kārtību, lietojot otrā līmeņa tīmekļvietņu domēna vārdu “gov.lv”. Pieļaujama esošo domēna vārdu lietošana, nodrošinot pārvirzīšanu uz vienotajā kārtībā noteiktajiem domēniem.

Obligāta

INFR05 Sinhrono tīmekļa pakalpju (Web services) izpildes ātrums

Ja Platformas darbības nodrošināšanai tiek izstrādātas un izmantotas sinhronas tīmekļa pakalpes, tad to pieprasījumu apstrādes laiks nedrīkst pārsniegt 2 (divas) sekundes.

Obligāta


4.6.Trešo pušu programmatūras licencesPrasības identifikators


LIC01 Sistēmas licenču piegāde Izpildītājam Finanšu piedāvājumā jāietver visas piedāvātās TVP licencēšanas izmaksas, tai skaitā papildus nepieciešamo trešo pušu piegādāto standarta programmatūras komponenšu izmaksas. Licencēm ir jāpieļauj piegādātās TVP izmantošana neierobežotam lietotāju skaitam bez datu apjoma ierobežojumiem. Standarta programmatūras licenču darbība jānodrošina atbilstoši MK noteikumu Nr. 653 20.5.2. punktam. Atsevišķi ir jānorāda licenču izmaksas un noteikumi TVP produkcijas (ekspluatācijas) vides un testa vides izveidošanai un uzturēšanai.Pasūtītājam ir tiesības nepasūtīt licenču piegādi tām licencēm, kuras jau ir Pasūtītāja rīcībā.Norāde Tehniskajam piedāvājumam: Pretendentam finanšu piedāvājumā jāiekļauj katra veida licence atsevišķi, norādot katras licences iegādes cenu un 1 (viena) gada uzturēšanas cenu.

Obligāta

LIC02 Papildu programmatūras komponentes

Izstrādātājam piedāvājumā ir jānorāda visas trešo personu licencējamās komponentes, ieskaitot programmu bibliotēkas, attēlus, kā arī citus trešo personu materiālus un to licencēšanas noteikumus. Komponentes, kurām ir komerciālas licences, ir jānorāda piedāvātajai konfigurācijai atbilstošo licenču izmaksas un to licencēšanas noteikumi (licencēšanas ierobežojumi un atbilstība Tehniskajā specifikācijā norādītajām prasībām). Piedāvāto licenču darbība jānodrošina atbilstoši MK noteikumu Nr. 653 20.5.2. punktam.Norāde Tehniskajam piedāvājumam: Pretendentam finanšu piedāvājumā jāiekļauj katra veida licence atsevišķi, norādot katras licences iegādes cenu un 1 (viena)

Obligāta




gada uzturēšanas cenu.

4.7.Drošības prasībasPrasības identifikators


SEC01 Identifikācijas datu drošība TVP jānodrošina lietotāju identifikācijas datu aizsardzība atbilstoši Vispārīgajai datu aizsardzības regulai. Aizliegts uzglabāt lietotāja identitātes un citus to raksturojošus sensitīvus datus (paroles, pieejas kodus, šifrēšanas atslēgas, kredītkartes numurus, veselības informāciju u. c.) atklātā tekstā datubāzē vai interneta pārlūkprogrammā, piemēram, kešatmiņā.

Obligāta

SEC02 Indeksācijas bloķēšana TVP ir jābūt iespējai noteikt, kuras tīmekļvietnes lapas drīkst indeksēt un kuras nedrīkst indeksēt meklētājprogrammās (Google, Bing u. c.).

Obligāta

SEC03 Šifrēšana TVP ir jāspēj nodrošināt šifrētu datu plūsmu starp lietotāju un serveri, izmantojot SSL/TLS protokolu (versija TLS 1.2) ar vismaz 128 bitu kodēšanu.TVP jānodrošina saziņa, izmantojot HTTPS protokolu, pārbaudot ārējā servisa sertifikāta derīgumu.

Obligāta

SEC04 Autentifikācija, autorizācija un auditācija

TVP jābūt veidotai tā, lai nevarētu apiet autentifikācijas un autorizācijas procedūras un nesankcionēti lietot TVP funkcionalitāti vai piekļūt datiem, kuriem nepieciešama autentifikācija vai kuri ir ierobežotas pieejamības.

Obligāta




TVP identifikācijas, autentifikācijas, autorizācijas un auditācijas procedūrām jāizpilda šādas prasības:

1. jāizmanto autorizācijas princips, saskaņā ar kuru viss, kas nav tiešā veidā atļauts, ir aizliegts;

2. visām darbībām jāpārbauda autorizācija darbības izpildei. Pārbaudei jānotiek katra pieprasījuma līmenī;

3. jebkurš autorizācijas vai autentifikācijas mēģinājums jāreģistrē auditācijas notikumu žurnālā.

Visām lietotāju un administratoru veiktajām darbībām jātiek identificētām (jābūt zināmam, kura persona izpilda katru darbību). Šī prasība neattiecas uz funkcionalitāti, kas nodrošināta kā publiski pieejama.

SEC05 Atbilstība drošības standartiem Veicot TVP izstrādi vai pielāgošanu ir jāievēro šādas prasības: 1. jāievēro OWASP ieteiktie sistēmu izstrādes principi:

http://www.owasp.org/index.php/Category:Principle. Datu aizsardzība dažādos pielietojuma slāņos jāveido, izmantojot dažādus (dažādu produktu, dažādu piegādātāju) aizsardzības mehānismus – piemēram, sekmīga pielietojumu servera aizsardzības uzlaušana nedrīkst atvieglot datubāzes aizsardzības uzlaušanu;

2. tīmekļa lietotnes izstrādājamas saskaņā ar OWASP drošas programmēšanas vadlīnijām: https://www.owasp.org/index.php/OWASP_Secure_Coding_Practices_-_Quick_Reference_Guide;

3. WEB pielietojumiem jāņem vērā OWASP ieteikumi attiecībā uz izmantojamām tehnoloģijām https://www.owasp.org/index.php/OWASP_Cheat_Sheet_Series;

4. Jāievēro programmatūras izstrādātāju ieteiktās labās prakses drošu informācijas sistēmu izstrādē un drošā konfigurācijā;

Obligāta

https://www.owasp.org/index.php/OWASP_Cheat_Sheet_Series

https://www.owasp.org/index.php/OWASP_Secure_Coding_Practices_-_Quick_Reference_Guide

https://www.owasp.org/index.php/OWASP_Secure_Coding_Practices_-_Quick_Reference_Guide

http://www.owasp.org/index.php/Category:Principle




5. izstrādē un ekspluatācijā nedrīkst izmantot komponentes, kuras ražotājs pozicionē kā “Beta”, “Pre-release”, “Release candidate”, “Obsolete” vai arī kādā citā veidā nerekomendē izmantošanai produkcijā;

6. izstrādē nedrīkst izmantot komponentes, kurām ražotājs nepiegādā vai tuvāko 5 (piecu) gadu laikā no izstrādes uzsākšanas brīža plāno pārtraukt uzturēšanu.

7. jāievēro 2012. gada 19. jūnija Ministru kabineta noteikumos Nr. 421 “Valsts informācijas sistēmu savietotāju un integrēto valsts informācijas sistēmu aizsardzības prasības” minētās prasības;

8. jāievēro 2015. gada 28. jūlija Ministru kabineta noteikumos Nr. 442 “Kārtība, kādā tiek nodrošināta informācijas un komunikācijas tehnoloģiju sistēmu atbilstība minimālajām drošības prasībām” minētās prasības;

9. jāievēro 2005. gada 11. oktobra Ministru kabineta noteikumos Nr. 764 “Valsts informācijas sistēmu vispārējās tehniskās prasības” minētās prasības;

10. jāievēro Vispārīgās datu aizsardzības regulas noteiktās prasības.Jāievēro citos uz IS drošību attiecināmos normatīvajos aktos iekļautās prasības, kas tiek pieņemtas un stājas spēkā Platformas izstrādes laikā.

SEC06 Aizsardzība pret pakalpojumatteices uzbrukumiem

TVP jānodrošina funkcionalitāte, kas palīdz aizsargāties pret ļaunprātīgu TVP noslogošanu.

Obligāta

SEC07 Kļūdu un sistēmas paziņojumi TVP kļūdu un sistēmas paziņojumi neatklāj lietotājiem datus par tīmekļvietni. Šādi dati ir pieejami tikai TVP administratoram vai satura administratoriem ar īpašām tiesībām (iestādes administratoriem).

Obligāta

SEC08 Datu apstrādes un pārraides drošība

Izstrādātājam jānodrošina, ka TVP datu apmaiņas, kā arī citi iespējamie automatizētie datu apstrādes procesi tiek pildīti tikai ar tehnoloģisko lietotāju

Obligāta




kontiem, kuriem funkcijas veikšanai ir noteiktas mazākās nepieciešamās tiesības. Tehnoloģiskie lietotāji un to tiesības jādokumentē programmatūras projektējuma aprakstā. Tehnoloģiskie konti realizējami tā, ka neļauj tos izmantot manuāliem pieslēgumiem vai darbībām. Datu apmaiņa ar citām sistēmām ir jānodrošina, izmantojot datu pieprasījumu vai datu pārraides kanālu šifrēšanu. Sistēmas komponenšu savstarpējā datu apmaiņa ir organizējama aizsargātā autentificētā veidā (sistēma – sistēma aizsardzība).

SEC09 Risinājuma arhitektūras drošība Risinājuma arhitektūrai jābūt veidotai tā, lai samazinātu visu potenciālo drošības atribūtu – konfidencinalitātes, integritātes un pieejamības, apdraudējuma riskus.Jāievēro sekojošie principi:

1. būvēts, lai būtu drošs (no angļu val. – secure by design), kas paredz, ka programmatūra tiek izstrādāta pēc drošas izstrādes principiem, ņemot vērā aktuālos apdraudējumus un labās prakses rekomendācijas preventīvām darbībām. Piemēram, izstrādē tiek ņemtas vērā OWASP izstrādes vadlīnijas;

2. drošs pēc noklusējuma (no angļu val. – secure by default), kas paredz, ka programmatūra darbojas droši pat tad, kad neviens to nav konfigurējis. Piemēram, tiek ievērots “viss, kas nav atļauts, ir aizliegts” princips piekļuves vadībā u. c.;

3. drošs darbināšanā (no angļu val. – secure in deployment), kas paredz, ka programmatūru ir iespējams droši uzturēt un administrēt.

Obligāta

SEC10 Sīkdatnes Tīmekļvietnē Satura patērētājam jābūt informācijai, ka tiek uzkrātas sīkdatnes (no angļu val. – cookies) un tīmekļvietnes statistikas servisi (piem, Google Analytics u. c.). Jānodrošina sīkdatņu deklarācija vismaz sekojošajos veidos:

1. nepieciešams – nepieciešamās sīkdatnes palīdz padarīt tīmekļvietni par izmantojamu, nodrošinot pamata funkcijas, piemēram, lappuses navigāciju

Obligāta




un piekļuvi drošām vietām tīmekļvietnē. Tīmekļvietne bez šīm sīkdatnēm nevar pareizi funkcionēt;

2. Preferences – preference sīkdatnes ļauj tīmekļvietnei atcerēties informāciju, kas maina veidu, kā vietne darbojas vai izskatās, piemēram, ieteicamo valodu vai reģionu, kurā atrodaties;

3. Statistika – statistikas sīkdatnes palīdz tīmekļvietņu īpašniekiem izprast, kā apmeklētāji mijiedarbojas ar tīmekļvietnēm, vācot un anonīmi pārskatot informāciju;

4. Mārketings – mārketinga sīkdatnes tiek izmantotas, lai sekotu līdzi apmeklētājiem tīmekļvietnēs. Nolūks ir parādīt atbilstošas reklāmas, kas interesē atsevišķu lietotāju, tādējādi tās ir daudz izdevīgākas izdevējiem un trešo personu reklāmdevējiem;

5. Neklasificēts – neklasificētās sīkdatnes ir sīkdatnes, kuras atrodas klasificēšanas procesā kopā ar atsevišķām pakalpojumu sniedzēju sīkdatnēm.

Gadījumā, ja kādas no deklarācijā minētajām sīkdatnēm nav izmantotas, tad jābūt informācijai, ka šāda veida sīkdatnes netiek uzkrātas.Lietotājam jānodrošina iespēja jebkurā laikā mainīt vai atsaukt savu piekrišanu. Tīmekļvietnē jābūt informācijai par konfidencialitātes politiku un sīkdatņu lietošanu (nepieciešamības gadījumā nodrošinot iespēju atsaukt piekrišanu sīkdatņu izmantošanai) – kā un kādam mērķim tiek apstrādāti personas dati.


4.8.Auditācijas prasībasPrasības identifikators


AUD01 Fizisko personu datu apstrādes uzraudzība

Tīmekļvietnei ir jāreģistrē un jāapstrādā visi fizisko personu datu apstrādes notikumi, ņemot vērā Vispārīgās datu aizsardzības regulas un Fizisko personu datu apstrādes likuma prasības.

Obligāta

AUD02 Auditācijas pierakstu tipi Tīmekļvietne nodrošina dažādu auditācijas ierakstu veikšanu atkarībā no izmantošanas mērķa:

1. testēšanas auditācijas pieraksti;2. drošības auditācijas pieraksti.

Obligāta

AUD03 Testēšanas auditācijas pieraksti Testēšanas auditācijas pieraksti tiek veidoti IS izstrādes vai pielāgošanas posmā. Tos iestrādā un izmanto IS izstrādes, testēšanas vai uzturēšanas darbinieki ar mērķi atrast IS kļūdas vai neatbilstības sistēmu specifikācijām, kā arī veikt papildu darbības IS uzlabošanai. Testēšanas auditācijas pieraksti IS ekspluatācijas laikā parasti tiek atslēgti sistēmas darbības efektivitātes uzlabošanai un tiek aktivizēti tikai konkrētu incidentu izmeklēšanas vajadzībām.

Obligāta

AUD04 Testēšanas auditācijas pierakstu veikšana

Tīmekļvietnei jāveic auditācijas pieraksti un vienumu versijas kontrole, iekļaujot šādu informāciju par auditācijas notikumu:

1. notikuma datums un laiks;2. notikuma veids;3. lietotāju identificējoša informācija;4. cita attiecīgajam notikumam specifiska informācija, kura tiks identificēta

prasību sistēmanalīzes laikā.

Obligāta

AUD05 Drošības auditācijas pieraksti Atkarībā no notikuma, kurš izsauc ieraksta veikšanu drošības auditācijas pierakstu Obligāta




auditācijas žurnālā, izdala sekojošus to veidus:1.risinājuma procesu auditācijas pieraksti, kuros reģistrējas:

1.1.IS ieslēgšanas, izslēgšanas, pārstartēšanas laiki un iemesli;1.2.IS laika, citu uzstādījumu un konfigurāciju izmaiņas;1.3.darbības ar sistēmas auditācijas pierakstiem, kā arī izmaiņas drošības politikas realizācijā;1.4.aizsardzības sistēmu (Intrusion detection system – IDS un Intrusion prevention system – IPS), pretvīrusu sistēmas apturēšana, darbības atjaunošana, konfigurācijas izmaiņas un šo sistēmu reģistrēti notikumi;

2.sistēmas līmeņa lietotāju auditācijas pieraksti, kuros reģistrējas:2.1.priviliģētu vai sistēmas operatora/administratora līmeņa lietotāju manuālās darbības;2.2.sistēmas aplikāciju vai servisa programmu pielietošana;2.3.tiešā piekļuve aplikāciju datnēm, neizmantojot biznesa aplikāciju piekļuves mehānismus;

3.autorizācijas procesu auditācijas pieraksti, kuros reģistrējas:3.1.IS lietotāju kontu aktivizācija vai bloķēšana;3.2.izmaiņas lietotāju tiesībās un lomās, jaunu tiesību piešķiršana vai esošo tiesību koriģēšana vai apturēšana;3.3.IS lietotāju pieslēgumu un darbības pārtraukšanas darbības, identifikācijas rezultāts, izmantotie identifikācijas līdzekļi;




3.4.veiksmīgie un neveiksmīgie autorizācijas mēģinājumi;4.darbību auditācijas pieraksti, kuros reģistrē konkrētas lietotāju darbības ar sistēmas datiem.

AUD06 Minimālais drošības auditācijas pierakstu apjoms

TVP auditācijas pierakstos jāreģistrē vismaz šādi darbības notikumi:1. laiks, kas sinhronizēts IS ietvaros ar Iestādē noteiktu laika serveri;2. datums;3. notikuma iniciators (lietotāja sistēmas identitāte);4. notikuma iniciatora atrašanās vieta (IP adrese), izmantotie datu pārraides

protokoli;5. notikuma tips vai veiktā darbība;6. notikuma statuss (darbība veikta veiksmīgi/neveiksmīgi);7. notikumā izmantotie dati, pēc iespējas norādot to aprakstu un nenorādot

saturu;8. notikumā veiktā darbība, pēc iespējas to norādot lietotāja vai IS valdītāja

pielietotajā terminoloģijā (lietotajos jēdzienos);9. notikumā iegūtie dati, pēc iespējas norādot to aprakstu un nenorādot

saturu.Notikumu saraksts var tikt precizēts TVP sistēmanalīzes un izstrādes laikā.

Obligāta

AUD07 Incidentu pieraksti TVP nodrošina sistēmas pierakstu satura plānveida uzraudzību un analīzi, lai konstatētu incidentus. Par incidentiem uzskata vismaz šādus notikumus:

1. atkārtota neveiksmīga pieslēgšanās IS;2. mēģinājumi piekļūt datiem, kuriem lietotājs nav pilnvarots piekļūt;3. IS lietošana neparastā laikā (piemēram, ārpus darba laika);4. atkārtoti mēģinājumi lietot lietotāja pieejas rekvizītus, kuri jau ir anulēti;5. privileģēta lietotāja lomu piešķiršana un lietošana (piemēram,

Obligāta




datubāzes/sistēmas administratora lomas piešķiršana);6. nesankcionētas programmatūras konfigurācijas maiņas un neatļautas

programmatūras uzstādīšana.AUD08 Piekļuve drošības auditācijas

pierakstiemPiekļuve auditācijas pierakstiem reģistrējama auditācijas žurnālos.Drošības auditācijas pieraksti aizsargājami pret to satura nesankcionētām izmaiņām vai neautorizētām piekļuvēm, uzmanību pievēršot:

1. aizsardzībai pret veikto ierakstu satura izmaiņām, labošanu vai dzēšanu;2. pietiekama apjoma glabāšanas vietas nodrošināšanu, tādējādi

aizsargājoties pret neiespējamību veikt jaunus ierakstus vai dzēst jau esošos.

Ir jābūt iespējai ierobežot piekļuvi auditācijas pierakstiem tām pašām personām, kurām ir administratīvās piekļuves tiesības produkcijas lietojumprogrammām/datubāzēm, par kurām veidojas auditācijas pieraksti.

Obligāta

AUD09 Autentificēto lietotāju auditācija TVP nodrošina sistēmas auditācijas pierakstu katram autentificētajam lietotājam vai interneta protokola (IP) adresei.

Obligāta

AUD10 Datu izmaiņu vēsture TVP ir jāuztur pilna datu izmaiņu vēsture, ja Pasūtītājs nav norādījis citādi. Proti, katram ierakstam ir jāuztur informācija par tā pievienošanu, rediģēšanu un dzēšanu, tai skaitā:

1. katru izmaiņu autors (lietotājs, ārējā sistēma vai TVP fona uzdevums);2. katru izmaiņu datums un laiks;3. ieraksta satura kopija pievienošanas/labošanas/dzēšanas brīdī.

Obligāta

AUD11 Auditācijas pierakstu dzēšana un arhivēšana

Auditācijas pieraksti par datos veiktajām izmaiņām jāuzglabā vismaz “n” mēnešus (kur “n” ir konfigurējams parametrs, pieņemot, ka noklusētā vērtība ir 18

Obligāta




(astoņpadsmit) mēneši), pēc tam tos automātiski arhivējot un dzēšot. Platformas administratoram jānodrošina iespēja mainīt šo parametru, izslēgt un ieslēgt automātisko datu izmaiņu vēstures arhivēšanu un dzēšanu, kā arī manuāli ierosināt datu izmaiņu vēstures arhivēšanu un dzēšanu. Izstrādātājam jānodrošina, ka uzglabājamo periodu auditācijas datnes nav iespējams dzēst vai rediģēt.

AUD12 Drošības auditācijas pierakstu aizsardzība

Drošības auditācijas pierakstu aizsardzība organizējama vai nu tos šifrējot, vai arī veicot reālā laika dublēšanu, kritiskos pierakstus izvietojot pierakstus iniciējošajam personālam nepieejamā (ārpus kontroles un pārvaldības) vietā.

Obligāta

AUD13 Auditācijas pierakstu laiks Sistēmas pieraksti tiek veidoti, nodrošinot, ka tajos norādītais laiks sakrīt ar faktiskā notikuma koordinēto pasaules laiku (UTC) ar vienas sekundes precizitāti.

Obligāta

AUD14 Auditācijas pierakstu filtrēšana TVP lietotāju saskarnē lietotājam ar atbilstošām tiesībām jānodrošina auditācijas pierakstu apskate un datu filtrācija. Auditācijas pierakstus jāvar filtrēt vismaz pēc notikuma laika un datuma, pēc lietotāja, pēc IP adreses – pierakstu filtri var tikt precizēti sistēmanalīzes laikā.

Obligāta

AUD15 Auditācijas pierakstu eksports Auditācijas pierakstiem ir jānodrošina pierakstu eksports .xlsx un .csv formātā. Obligāta


5. ORGANIZATORISKĀS PRASĪBASŠajā sadaļā ir aprakstītas Projekta organizatoriskās un pārvaldības prasības. Visas šajā sadaļā minētās prasības ir ietveramas Tehniskā piedāvājuma sagatavošanā un izpildāmas Projekta laikā. Organizatorisko prasību radītās izmaksas ir jāiekļauj funkcionālo prasību realizācijas izmaksās, un finanšu piedāvājumā kā atsevišķa pozīcija nav jāizdala.

5.1.Projekta īstenošanas pieeja un laika plānsPrasības identifikators


ORG01 Projekta laika plāns Sagatavojot Projekta realizācijas laika plānu, Izstrādātājam jāņem vērā šādi termiņi: 1. Platformas izstrāde – 2020. gada 30. aprīlis; 2. Pilotprojekta realizācija – 12 Pilotprojekta iestāžu tīmekļvietņu izveide, datu migrācija no esošajām tīmekļvietnēm, administratoru mācības – 2020. gada 30. aprīlis;3. TVP ekspluatācijas uzsākšana – veikta Pilotprojekta iestāžu tīmekļvietņu izvietošana Platformas produkcijas vidē – 2020. gada 30. aprīlis;4. Vienotu vadlīniju tīmekļvietņu izveidei, funkcionalitātes izmantošanai, satura pārvaldībai un uzturēšanai izstrāde – 2020.gada 30. jūnijs;5. Administratoru mācības (Platformas administratoru, Satura administratoru ar īpašām tiesībām un Satura administratoru) – 2020. gada 30. decembris;6. Pārējo 48 Projektā iesaistīto iestāžu tīmekļvietņu izveide un datu migrācija no esošajām tīmekļvietnēm – 2020. gada 30. decembris.

Platformas uzturēšana jānodrošina 24 (divdesmit četru) kalendāro mēnešu periodā,

Obligāta




skaitot no gala nodošanas-pieņemšanas akta abpusējas parakstīšanas dienas.Garantijas pakalpojumi jānodrošina 24 (divdesmit četru) kalendāro mēnešu periodā, skaitot no gala nodošanas-pieņemšanas akta abpusējas parakstīšanas dienas.Norāde Tehniskajam piedāvājumam: Pretendentam Tehniskajā piedāvājumā ir jāiekļauj Projekta realizācijas laika plāna piedāvājums, kurā norādīti laidieni, sprinti un to ietvaros veicamās aktivitātes. Laika plānā jāparedz Projekta pārvaldības, prasību analīzes un Platformas realizācijas, Izstrādātāja un Pasūtītāja testēšanas, dokumentu izskatīšanas un saskaņošanas, datu migrācijas, mācību, kā arī Platformas ieviešanas produkcijā aktivitātes. Projekta laika plāns Izstrādātājam jāuztur aktuāls visā Projekta realizācijas laikā un jānodrošina tā aktuālās versijas pieejamība Pasūtītājam.

ORG02 Izmaiņu pieprasījumi Izmaiņas Tehniskajā specifikācijā paredzētajā funkcionalitātē vai papildinājumi jau izstrādātai Platformas funkcionalitātei tiks pasūtīti saskaņā ar Līguma projektā iekļauto izmaiņu pieprasījumu pasūtīšanas un izpildes kārtību. Izstrādātājam ir jāveic izmaiņu pieprasījuma izpēte un novērtēšana, izmaiņu izstrāde (t. sk. attiecīgās dokumentācijas aktualizēšana, t. i., labošana, papildināšana utt.), testēšana un piegāde, pamatojoties uz Pasūtītāja definētajām prasībām un saskaņā ar Tehniskās specifikācijas nefunkcionālajām un organizatoriskajām prasībām. Izmaiņu pieprasījuma novērtēšana ir jāveic bez maksas.Par izmaiņu pieprasījumu netiks uzskatītas programmatūras prasību specifikācijas un projektējuma kļūdas vai nepilnības, kuras saskaņā ar industrijas labo praksi Izstrādātājam bija savlaicīgi jāidentificē.

Informatīva




Norāde tehniskajam piedāvājumam: Pretendentam šīs prasības realizācijas apraksts tehniskajā piedāvājumā nav jāiekļauj.

ORG03 Projekta aktivitātes Līguma darbības laikā piedāvātās līgumcenas ietvaros Izstrādātājam jāveic vismaz šādi darbi saskaņā ar šīs Tehniskās specifikācijas prasībām:

1. pirms uzsākt Platformas izstrādes un ieviešanas darbus Izstrādātājam ir jāizstrādā un ar Pasūtītāju jāsaskaņo:

a. Projekta pārvaldības plāns;b. Platformas arhitektūras apraksts; c. Projekta sākotnējais uzkrājums (Backlog) un tā provizoriskais dalījums

sprintos;2. Projekta darbības laikā jāveic Projekta pārvaldība atbilstoši piedāvātajai

metodoloģijai un saskaņotajam Projekta pārvaldības plānam; 3. jāpiegādā visas Platformas darbināšanai nepieciešamās licences, tai skaitā

nepieciešamās trešo pušu programmatūras licences. Trešo pušu programmatūra var ietvert, piemēram, datubāzes, lietojumprogrammu servera, analīzes rīka u. c. licences;

4. jāveic programmatūras prasību analīze un dokumentēšana lietotājstāstu veidā; 5. jāveic Platformas projektēšana un izstrāde, tai skaitā starpsistēmu saskarņu

izstrāde; 6. jāveic Platformas testēšana (funkcionālā, integrācijas, lietojamības, drošības un

veiktspējas testēšana); 7. jāveic testa un pirmsprodukcijas vides administrēšana, t. sk. piekļuves tiesību

izveide un pārvaldība Pasūtītāja pārstāvjiem un Pasūtītāja norādītiem citu iestažu pārstāvjiem;

8. jāveic Projekta iestāžu tīmekļvietņu izveide Platformā;9. jāveic datu migrācija no esošajām Projekta iestāžu tīmekļvietnēm uz Platformā

izvietotajām tīmekļvietnēm;

Obligāta




10. jāveic Platformas administratoru, Satura administratoru ar īpašām tiesībām un Satura administratoru mācības;

11. jāizstrādā labās prakses vadlīnijas tīmekļvietnes satura ievadīšanai, noformēšanai un publicēšanai;

12. jāievieš Platforma (t. sk. izvietošana datu centrā) un jānodrošina Tehniskajā specifikācijā paredzētās funkcionalitātes, t. sk. datu apmaiņas saskarņu darbība.

ORG04 Projekta pārvaldības plāna izstrāde un saskaņošana

Izstrādātājam jāveic Projekta pārvaldības plāna izstrāde un saskaņošana ar Pasūtītāju. Projekta pārvaldības plāns izstrādājams un nododams Pasūtītājam saskaņošanai 2 (divu) nedēļu laikā pēc Līguma abpusējas parakstīšanas dienas. Projekta laikā Izstrādātājam Projekta pārvaldības plāns ir jāuztur aktuāls.

Obligāta

5.2.MetodoloģijasPrasības identifikators


ORG05 Projekta vadības metodoloģija

Izstrādātājam ir jāpiedāvā un Projekta laikā jānodrošina risinājuma izstrādes vadība un Projekta pārvaldība, kas ir balstīta uz starptautiski pieņemtas projekta vadības metodoloģijas ietvaru.

Obligāta

ORG06 Izstrādes standarti un metodes

Izstrādātājam ir jāizmanto dokumentēti izstrādes standarti un metodes visām izstrādes aktivitātēm un nodevumiem. Standarti un metodes ir jāapraksta vai jānorāda atsauces uz atbilstošiem dokumentiem Projekta pārvaldības plānā.

Obligāta




ORG07 Izstrādes metodoloģija Izstrādātājam kā izstrādes metodoloģija jāizmanto kāda no iteratīvajām IS izstrādes metodikām.Izstrādātājam, uzsākot Līguma izpildi, ir jāizveido un ar Pasūtītāju jāsaskaņo Projekta vienumu uzkrājums (project backlog), kas sastāv no šajā Tehniskajā specifikācijā ietvertajām funkcionālajām prasībām un nefunkcionālajām prasībām. Atbilstoši piedāvātajai izstrādes pieejai Izstrādātājs var pārstrukturēt atsevišķu funkcionālo prasību izpildi, iekļaujot to vairākos Projekta uzkrājuma vienumos vai apvienojot vairāku funkcionālo prasību izpildi vienā Projekta uzkrājuma vienumā. Izstrādātājam jānovērtē katrs Projekta uzkrājuma vienums ar noteiktu lietotājstāstu punktu (story points) skaitu un jāiekļauj sākotnējā Projekta uzkrājuma pārskatā. Vērtējot lietotājstāstus, punktu novērtējumam jābūt proporcionālam - lietotājstāstam, kas novērtēts ar 4 punktiem, vajadzētu aizņemt 4 reizes vairāk laika nekā tādam, kas novērtēts ar 1 punktu;Sākotnējais Projekta uzkrājums provizoriski jāsadala izstrādes laidienos un sprintos (t. sk. sprinta uzkrājuma vienumos) ar nosacījumu, ka vienam sprintam jābūt ne ilgākām kā 4 (četras) nedēļas.Norāde Tehniskajam piedāvājumam: Pretendentam Tehniskajā piedāvājumā ir jāiekļauj izmantojamās izstrādes metodoloģijas apraksts, t. sk. plānotais sprintu garums un skaits laidiena ietvaros un provizoriskais Projekta uzkrājuma sadalījums laidienos.

Obligāta

ORG08 Projekta progresa sanāksmes

Pēc nepieciešamības tiek organizētas operatīvās Projekta progresa sanāksmes, kurās Izstrādātājs sniedz aktualizētu pārskatu par Projekta uzkrājumu, sprinta plāna ievērošanu (t. sk. iespējamajām novirzēm), identificētajiem riskiem un problēmjautājumiem, paveiktajām un plānotajām aktivitātēm.

Obligāta




Par sanāksmju biežumu un periodiskumu Izstrādātājs vienojas ar Pasūtītāju Projekta uzsākšanas sanāksmē.

ORG09 Sprinta ietvaros veicamās aktivitātes

Katra sprinta ietvaros ir jāparedz šādas aktivitātes (atšķirīgs var būt sākotnējais un beigu sprints):

1. sprinta uzkrājuma vienumu identificēšana;2. sprinta plānošana; 3. sprinta analīze;4. sprinta ietvaros izstrādātās funkcionalitātes pārskata demonstrācija; 5. sprinta ietvaros izstrādātās funkcionalitātes (kas notestēta un atkļūdota

Izstrādātāja pusē) piegāde un uzstādīšana testa vidē;6. sprinta ietvaros izstrādātās funkcionalitātes testēšana Pasūtītāja pusē;7. identificēto kļūdu labojumu veikšana;8. atkārtota izstrādātās sprinta funkcionalitātes piegāde, uzstādīšana un testēšana

Pasūtītāja pusē;9. datu apkopošana par sprintā realizēto.

Obligāta

ORG10 Sprinta uzkrājuma vienums (user story)

Katru sprinta uzkrājuma vienumu raksturo prasības apraksts, kas ir jārealizē konkrētā sprinta ietvaros.Vēlamā forma prasību izteikšanai ir t. s. “lietotājstāsti” (user story), aprakstot:

1. lomu, kurai jānodrošina attiecīgā funkcionālā iespēja;2. funkcionalitāti, kura jānodrošina;3. akceptēšanas kritērijus, kas definē lietotājstāsta pārbaudes un pieņemšanas

nosacījumus.Prasības aprakstam var tikt pievienoti papildu dokumenti, diagrammas, ekrānformu skices u. tml. artefakti.

Obligāta




ORG11 Sprintu plāns Izstrādātājam, uzsākot Līguma izpildi, jāsagatavo un ar Pasūtītāju jāsaskaņo sākotnējais provizoriskais sprintu plāns.Izstrādātājam pirms katra sprinta uzsākšanas jāsagatavo un ar Pasūtītāju jāsaskaņo konkrētā sprinta plāns un tā ietvaros realizējamie lietotājstāsti un sprinta ietvaros veicamo aktivitāšu laika grafiks.

Obligāta

ORG12 Sprinta plānošanas sanāksme

Pirms katra sprinta uzsākšanas tiek organizēta sprinta plānošanas sanāksme, kurā piedalās Pasūtītāja Projekta vadītājs un produkta īpašnieks (Product owner), Konsultanti un Izstrādātāja Projekta komanda. Sprinta plānošanas sanāksmē:

1. tiek aktualizētas prasību prioritātes;2. tiek identificēti nākamajā sprintā iekļaujami sprinta uzkrājuma vienumi;3. tiek sastādīts un saskaņots sprinta realizācijas operatīvais plāns (interviju grafiks,

sprinta sanāksmju grafiks u. c. organizatoriskie jautājumi).

Obligāta

ORG13 Sprinta analīzes intervijas/sanāksmes

Pirms katra sprinta uzsākšanas, Izstrādātājam jāsagatavo lietotājstāstu apraksti, kurus paredzēts detalizēt sprinta ietvaros, un sprinta sākumā jāiesniedz Pasūtītājam, lai Pasūtītājs un citi pārstāvji var iepazīties ar sprinta ietvaru un sagatavoties analīzes sanāksmēm. Sprinta analīzes sanāksmes jāparedz regulāri saskaņā ar sprintu plānu.Sprinta analīzes sanāksmē piedalās Pasūtītāja Projekta vadītājs, produkta īpašnieks, Konsultanti, Izstrādātāja Projekta komanda un citi Pasūtītāja piesaistīti pārstāvji pēc nepieciešamības. Sprinta analīzes sanāksmē tiek precizētas, papildinātas un saskaņotas lietotājstāstos ietvertās prasības, kā arī katra realizējamā lietotājstāsta akceptēšanas kritēriji.

Obligāta




ORG14 Sprinta ietvaros izstrādātās funkcionalitātes pārskata (demonstrācijas) sanāksme

Izstrādātājam jāorganizē sprinta pārskata sanāksmes (sprint review) saskaņā ar sprintu plānu. Sprinta pārskata sanāksmē Izstrādātājs iepazīstina ar sprinta laikā izstrādāto funkcionalitāti, demonstrējot Platformas darbību izstrādes vai Pasūtītāja testa vidē.Pārskata (demonstrācijas) sanāksmē piedalās vismaz Pasūtītāja Projekta vadītājs, produkta īpašnieks, Projekta vadības grupas pārstāvji, Konsultanti un Izstrādātāja Projekta komanda.Pārskata (demonstrācijas) sanāksmē:

1. izstrādātājs demonstrē izstrādes progresu un izstrādāto funkcionalitāti biznesa prasību realizācijai atbilstoši fiksētajiem lietotājstāstiem, normatīvajiem aktiem un vispārpieejamai informācijai;

2. demonstrē Pasūtītājam ekrānformu, izdruku un citu lietotāja saskarnes elementu dizainu;

3. Pasūtītājs apstiprina izstrādāto apjomu vai norāda uz nepieciešamajām korekcijām, izmaiņām, tai skaitā lietojamības uzlabojumiem. Pasūtītāja norādītās korekcijas un izmaiņas 10 % apmērā no sprinta apjoma funkcionalitātes netiks uzskatītas par izmaiņu pieprasījumu.

Demonstrācija nav uzskatāma par akcepttestēšanu.

Obligāta

ORG15 Prasības sprinta nodevumiem

Katra sprinta rezultātā piegādātajam programmatūras apjomam ir jābūt:1. pabeigtam (t. i. izstrādātam, notestētam un atkļūdotam Izstrādātāja izstrādes

vidē);2. dokumentētam (sk. Prasību Sprinta piegādes nodevumi);3. Novērtētam ar lietotājstāstu punktiem (story points). Izstrādātājam pēc sprinta

testēšanas pabeigšanas jāapkopo dati un jāiesniedz Pasūtītājam pārskats par sprinta ietvaros realizēto, kas ietver:

a) sprinta ietvaros sākotnēji iekļauto lietotājstāstu novērtējuma (story points) apjomu;

Obligāta




b)sprinta ietvaros realizēto lietotājstāstu novērtējuma (story points) apjomu;

c)sprinta ietvaros nerealizēto lietotājstāstu novērtējuma (story points) apjomu;

d)sprinta ietvaros identificēto kļūdu novērtējuma (story points) apjomu;e)sprinta ietvaros novērsto kļūdu novērtējuma (story points) apjomu.

ORG16 Sprinta piegādes nodevumi

Katra sprinta beigās ir jāpiegādā šādi nodevumi: 1. izstrādātā programmatūra; 2. programmatūras prasību specifikācija lietotājstāstu veidā;3. izpildītāja veikto testu pārskats;4. lietotāju rokasgrāmata par sprinta ietvaros piegādāto funkcionalitāti.

Jebkāda cita dokumentācija, kas tiek radīta un būtiski ietekmē Platformas ieviešanu vai tās turpmāku ekspluatāciju.

Obligāta

ORG17 Sprinta ietvaros izstrādātās funkcionalitātes piegāde un uzstādīšana Pasūtītāja testa vidē

Platformas adminstrators, konsultējoties ar Izstrādātāju, veic funkcionalitātes uzstādīšanu Pasūtītāja testa vidē. Ja instalācija ir neveiksmīga, netiek piegādāta sprinta ietvaros izstrādātā funkcionalitāte un konstatētās problēmas nav novērstas 3 (trīs) darba dienu laikā, tad sprinta ietvaros esošie lietotājstāsti tiek uzskatīti par nerealizētiem un ieskaitāmi tehniskā parāda apjomā.Izstrādātājam jāsaskaņo ar Pasūtītāju nepiegādātā sprinta piegādes un aktivitāšu, kas saistītas ar sprinta pārbaudi, termiņi.

Obligāta

ORG18 Sprinta ietvaros izstrādātās funkcionalitātes testēšana Pasūtītāja pusē

Pasūtītājs veic sprinta nodevumu akcepttestu. Izstrādātājam, sagatavojot sprinta aktivitāšu laika plānu, ar Pasūtītāju jāsaskaņo Pasūtītāja pusē sprinta akcepttestēšanai nepieciešamais laiks.

Obligāta




Testēšanas ietvaros identificētās kļūdas tiek reģistrētas Izstrādātāja pieteikumu apstrādes sistēmā. Balstoties uz Pasūtītāja un Konsultantu iesniegtajiem pieteikumiem, Izstrādātājam sprinta ietvaros jāveic identificēto defektu novēršana un atkārtota piegāde Pasūtītājam un uzstādīšana Pasūtītāja testa vidē. Labojumiem ir jābūt inkrementāli instalējamiem uz tekošajā sprintā piegādātās programmatūras un jābūt integrētiem nākošajos programmatūras izstrādes sprinta nodevumos. Vienojoties ar Pasūtītāju, labojumi var tikt piegādāti tikai integrējot tos nākamā sprinta nodevumos un Pasūtītājs var nepieprasīt atsevišķu labojumu piegādi tekošajam sprintam, tomēr šāda vienošanās nav pienākums no Pasūtītāja puses. Saņemot labotos programmatūras izstrādes nodevumus, Pasūtītājs veiks novērsto defektu pārbaudi, atkārtojot iepriekš aprakstīto procedūru.

ORG19 Kvalitātes vadība Izstrādā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.:

1. regulāra statusa Informācijas sniegšana Pasūtītājam par Projekta gaitu; 2. pirms visu dokumentu nodevumu izstrādes uzsākšanas Izstrādātājam jāsaskaņo

dokumentu nodevumu sagataves ar Pasūtītāju; 3. pirms nodevumu iesniegšanas Pasūtītājam Izstrādātājam jāveic iekšēja nodevumu

kvalitātes novērtēšana (visiem dokumentiem un tajos aprakstītajai informācijai jābūt viennozīmīgai, nepretrunīgai un pabeigtai, savukārt programmatūras kodam jābūt komentētam un verificētam);

4. nodevumi savlaicīgi jāiesniedz Pasūtītājam saskaņošanai;5. jāveic savlaicīga un regulāra Projekta risku identificēšana un eskalācija.

Norāde Tehniskajam piedāvājumam: Pretendentam Tehniskajā piedāvājumā ir jāapraksta

Obligāta




dokumentācijas un programmatūras kvalitātes nodrošināšanas principi.ORG20 Risku vadība Izstrādātājam visā Projekta realizācijas laikā ir jāveic 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 saskaņā ar izvēlēto Projekta vadības metodoloģiju. Norāde Tehniskajam piedāvājumam: Pretendentam Tehniskajā piedāvājumā ir jāpievieno risku pārvaldības metodoloģija (kas ietver vismaz risku identificēšanas, risku novērtēšanas, risku mazināšanas un novēršanas plānošanas un īstenošanas pieeju), Projekta 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.

Obligāta

ORG21 Versiju un konfigurācijas pārvaldība

Platformas 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 programmatūrai) jātiek piegādātām atsevišķi, pievienojot izmaiņu vēsturi. Izstrādātājam Projekta pārvaldības plānā jāapraksta piedāvātā pieeja Projekta konfigurācijas vadības nodrošināšanai. Norāde Tehniskajam piedāvājumam: Pretendentam Tehniskajā piedāvājumā ir jāapraksta versionēšanas un konfigurācijas pārvaldības principi un izmantotie rīki.

Obligāta

ORG22 Incidentu vadība Izstrādātājam ir jānodrošina incidentu (Platformas testēšanas vai darbības laikā atklātās kļūdas, nepilnības, neatbilstības utt.) ziņojumu pārvaldība.Norāde Tehniskajam piedāvājumam: Pretendentam Tehniskajā piedāvājumā ir jāapraksta incidentu pārvaldības metodoloģija un incidentu pārvaldībā izmantotie rīki.

Obligāta




ORG23 Izmaiņu vadība Izstrādātājam jāpiedāvā Projekta izmaiņu vadības modelis, paredzot 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.Norāde Tehniskajam piedāvājumam: Izstrādātājam tehniskajā piedāvājumā jāiesniedz izstrādes aktivitāšu darbietilpības novērtēšanas metodika. Papildus Izstrādātājam jānorāda, kā tiek aprēķināts apjoms saistošajām aktivitātēm (analīze, Projekta vadība, testēšana). Izstrādātājam Projekta pārvaldības plānā jāapraksta piedāvātā pieeja Projekta izmaiņu vadības nodrošināšanai.

Obligāta

5.3.Projekta organizatoriskā struktūraPrasības identifikators


ORG24 Projekta organizatoriskā struktūra

Projekta pārvaldība tiks organizēta pēc šādas Projekta organizatoriskās struktūras: 1. Projekta uzraudzības padome (PUP); 2. Projekta vadības grupa (PVG); 3. Projekta vadītājs; 4. Projekta komanda/Projekta darba grupa.

Detalizēts Projekta organizatoriskās struktūras apraksts, pienākumi, sastāvs aprakstīts Detalizētajā projekta aprakstā [1].

Obligāta




Izstrādātājam jānodrošina savu pārstāvju dalība visās Projekta vadības struktūrās: 1. dalībai PUP – Izstrādātāja vadības līmeņa pārstāvis un Izstrādātāja Projekta

vadītājs;2. dalībai PVG – Izstrādātāja Projekta vadītājs un pēc nepieciešamības kāds no

Izstrādātāja komandas dalībniekiem;3. dalībai Projekta komandā – Izstrādātāja Projekta vadītājs un Izstrādātāja

komandā esošie speciālisti.

5.4.Komunikācijas vadībaPrasības identifikators


ORG25 Projekta darba valoda Projekta darba valoda ir latviešu valoda, visas klātienes tikšanās un komunikācija tiek organizēta latviešu valodā. Izstrādātājam dokumentācijas nodevumi ir jāizstrādā latviešu valodā.Ja Projekta laikā tiek piesaistīti speciālisti, kuri nepārvalda latviešu valodu, Izstrādātājam šo speciālistu saziņā ar Pasūtītāju ir jānodrošina tulkošana bez papildu maksas. Atsevišķi Projekta dokumentētie nodevumi, iepriekš saskaņojot ar Pasūtītāju, var tikt iesniegti angļu valodā.

Obligāta

ORG26 Interviju un sanāksmju protokolēšana

Izstrādātājam ir jāveic visu interviju un sanāksmju protokolēšana, 3 (trīs) darba dienu laikā pēc notikušās sanāksmes ievietojot tos Projekta bibliotēkā Pasūtītājam

Obligāta




saskaņošanai. Pēc Pasūtītāja komentāru saņemšanas, protokoli jāprecizē 2 (divu) darba dienu laikā un jāiesniedz atkārtotai saskaņošanai Pasūtītājam.

ORG27 Progresa ziņojumi Izstrādātājam ir jāsagatavo un elektroniski jāiesniedz Pasūtītājam ikmēneša Projekta progresa ziņojums, kas satur vismaz šādu informāciju:

1. Projekta nosaukums;2. izstrādes Projekta sākuma datums;3. pārskata periods;4. kopējais Projekta statusa novērtējums par Projekta apjomu (scope), Projekta

resursiem, Projekta laika plānu – vai izpilde notiek saskaņā ar plānu, vai ir identificētas novirzes no plāna (ja ir identificētas, tad papildu skaidrojums par novirzi un tās ietekmi uz Projekta izpildi);

5. pārskatā periodā veiktie uzdevumi (uzdevums, procentuāls izpildes apjoms uz Projekta progresa ziņojuma iesniegšanas datumu, uzdevuma izpildes datums);

6. pārskatā periodā nepaveiktie uzdevumi (uzdevums, procentuāls izpildes apjoms uz Projekta progresa ziņojuma iesniegšanas datumu, uzdevuma izpildes datums);

7. nākamajā pārskata periodā plānotie uzdevumi (uzdevums, procentuāls izpildes apjoms uz Projekta progresa ziņojuma iesniegšanas datumu, uzdevuma izpildes datums);

8. Projekta riski (Projekta progresa ziņojumā jāietver informācija par atvērtajiem riskiem/problēmām, novēršanas pasākumiem );

9. nepieciešamie lēmumi. Progresa ziņojumi tiek izskatīti PVG.

Obligāta

ORG28 Sanāksmes Izstrādātājam jāorganizē vismaz šādas sanāksmes (Pasūtītāja norādītajā vietā, Rīgas administratīvajā teritorijā):

1. Projekta uzsākšanas sanāksme – 5 (piecu) darba dienu laikā pēc Izstrādes līguma par Projekta īstenošanu abpusējas parakstīšanas. Projekta uzsākšanas sanāksmē

Obligāta




Izstrādātājs iepazīstina Pasūtītāju ar Izstrādes līguma izpildes komandu, izpildes plānu (t. sk. tuvākos plānotos darbus un iespējamajiem riskiem);

2. Projekta darba grupu sanāksmes;3. Sprinta analīzes un demonstrācijas sanāksmes;4. u. c. sanāksmes pēc nepieciešamības.

Izstrādātājam vismaz 1 (vienu) dienu pirms sanāksmes jānosūta informācija par sanāksmes laikā pārrunājamajiem jautājumiem.Izstrādātājam jānodrošina, ka piedāvātie speciālisti piedalās visās sanāksmēs, kuras atbilst to kompetences jomai.

5.5.Projekta nodevumiPrasības identifikators


ORG29 Projekta bibliotēka Izstrādātājam jānodrošina Projekta bibliotēka ar piekļuvēm Pasūtītāja, Projektā iesaistīto iestāžu un Konsultantu pārstāvjiem, kurā tiks izvietota visa ar Projektu saistītā dokumentācija (dokumentācijas nodevumi, sanāksmju protokoli, Projekta progresa ziņojumi u. c.) un nodrošināta dokumentu pieejamība.Izstrādātājam jānodrošina, ka Projekta bibliotēkā vairāki lietotāji vienlaicīgi var veikt viena un tā paša dokumenta izskatīšanu, komentēšanu un izmaiņu saglabāšanu. Projekta bibliotēkā tiek uzkrātas Pasūtītājam iesniegtās dokumentu sākotnējās versijas,

Obligāta




komentētās dokumentu versijas un dokumentu gala versijas, kas saskaņotas ar Pasūtītāju.

Izstrādātājs, ievietojot Projekta bibliotēkā dokumentu komentēšanai, piemēram, sanāksmes protokolu, nosūta e-pastu uz Līgumā norādīto Pasūtītāja kontaktpersonas e-pasta adresi, kas satur informāciju par Projekta bibliotēkā ievietoto dokumentu, saiti uz to un komentāru sniegšanas termiņu. Pasūtītāja kontaktpersona nosūta komentēšanas uzaicinājumu pārējiem sanāksmes dalībniekiem, kuri izmantojot e-pastā esošo saiti, atver dokumentu caurskatei, veic redakcionālas izmaiņas un sniedz komentārus. Izstrādātājs veic visu sniegto komentāru apstrādi un sagatavo jaunu dokumenta versiju. Pasūtītājam jābūt pieejami gan komentētajai versijai, gan gala tīrraksta versijai.Ja Projekta bibliotēka nav pieejama, Pasūtītājs, Projektā iesaistīto iestāžu un Konsultantu pārstāvji var sniegt komentārus par konkrēto dokumentu ārpus Projekta bibliotēkas vides, piemēram, nosūtot e-pastā. Izstrādātājam jānodrošina ārpus Projekta bibliotēkas sniegtās informācijas ievietošana Projekta bibliotēkā.Pēc Pasūtītāja pieprasījuma Izstrādā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.

Par Projekta bibliotēkas izveidi un uzturēšanu atbild Izstrādātājs.Projekta beigās (līdz 2021.gada 4.janvārim) Izstrādātājam jāiesniedz Pasūtītājam visa Projekta bibliotēkā esošā dokumentācija uz fiziska datu nesēja.




ORG30 Nodevumu formāts Visiem ar Projektu saistītajiem dokumentiem ir jābūt sagatavotiem 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ā. Visiem dokumentiem ir jābūt nolasāmiem ar MS Office 2010 vai jaunākas versijas MS Word, MS Excel, MS PowerPoint rīkiem. Nodevumos izmantotās shēmas piegādā rediģējamā formātā, kas sagatavotas atbilstoši Pasūtītāja izvirzītajām prasībām.Izstrādātājs var iesniegt gala nodevumu dokumentus papīra formā ar parakstītu pavadvēstuli vai arī elektroniski, parakstītus ar drošu elektronisko parakstu.

Obligāta

ORG31 Nodevumu saraksts Projekta ietvaros Izstrādātājam ir jāsagatavo un jāiesniedz Pasūtītājam vismaz šādi Projekta nodevumi:

1. Projekta pārvaldības plāns;2. kvalitātes nodrošināšanas plāns (var tikt iekļauts Projekta pārvaldības plānā);3. Platformas struktūras (wireframe) un dizaina skices;4. arhitektūras apraksts (t. sk. datu, loģiskā un fiziskā arhitektūra un to komponenšu

apraksts);5. programmatūras prasību specifikācija (lietotājstāsti);6. saskarņu prasību specifikācija;7. programmatūras projektējuma apraksts, t. sk. datubāzes projektējums;8. rezerves kopēšanas, darbības nepārtrauktības un atjaunošanas plāns; 9. datu migrācijas plāns;

Obligāta




10. testēšanas plāns un pārskats;11. administratora rokasgrāmata (Platformas administratoriem);12. lietotāju rokasgrāmata (Satura administratoriem ar īpašām tiesībām un Satura

administratoriem);13. mācību plāns un mācību materiāli;14. labās prakses vadlīnijas tīmekļvietnes satura ievadīšanai, noformēšanai un

publicēšanai;15. programmatūras versijas apraksti jeb laidienu piezīmes;16. izstrādāto programmatūras risinājumu un gatavās programmatūras pielāgojumu

pirmkodi, gatavās programmatūras un izstrādāto programmatūras pielāgojumu izpildkodi, konfigurācijas datnes (skripti);

17. jebkāda cita dokumentācija, kas tiek radīta un būtiski ietekmē Platformas ieviešanu vai tās turpmāku ekspluatāciju.

Projekta nodevumu saraksts var tikt precizēts Projekta gaitā, un iespējams apvienot nodevumus, to saskaņojot ar Pasūtītāju. Nodevumu iesniegšanas termiņi ir jāsaskaņo ar Pasūtītāju.

ORG32 Atbilstība standartiem Projekta nodevumi sagatavojami atbilstoši Latvijas valsts un starptautisko programmatūras izstrādes standartu un vadlīniju prasībām.

Obligāta

ORG33 Projekta pārvaldības plāns Projekta pārvaldības plānam jābūt izstrādātam atbilstoši Izstrādātāja piedāvātajai izstrādes metodoloģijai. Projekta pārvaldības plānā jānosaka tehniskās un pārvaldošās Projekta funkcijas, aktivitātes un uzdevumi, kas nepieciešami Tehniskajā specifikācijā

Obligāta




noteikto prasību izpildei. Projekta pārvaldības plāns jāiesniedz un jāsaskaņo ar Pasūtītāju pirms izstrādes darbu uzsākšanas.Projekta pārvaldības plānā jāiekļauj vismaz šādas sadaļas:

1. Projekta organizācija; 2. pārvaldības procesi (veicamās aktivitātes, to norises kārtība un atbildīgie);3. Projekta kalendārais plāns; 4. konfigurācijas vadība; 5. risku vadība; 6. izmaiņu vadība.

Kvalitātes nodrošināšanas plāns var tikt iekļauts Projekta pārvaldības plānā vai iesniegts kā atsevišķs nodevums.

ORG34 Arhitektūras apraksts Arhitektūras apraksts sagatavojams saskaņā ar standarta ISO/IEC/IEEE 42010:2011 prasībām un vadlīnijām. Platformas arhitektūras aprakstā ir jāiekļauj vismaz šādi skatu punkti:

1. biznesa arhitektūra (sasniedzamo biznesa mērķu, atbalstāmo funkciju un procesu uzskaitījums);

2. programmatūras arhitektūra (programmatūras komponenšu uzskaitījums, apraksts un to sadarbības shēma);

3. datu arhitektūra (būtiskāko datu objektu uzskaitījums, apraksts un to savstarpējās sasaistes shēma);

Obligāta




4. infrastruktūras arhitektūra (fiziskā arhitektūra, virtuālā arhitektūra, programmatūras komponenšu izvietojums uz infrastruktūras elementiem);

5. drošības arhitektūra (drošības zonas, drošības kontroles, drošības prasību ievērošana izstrādes procesā);

6. uzturēšanas apsvērumi (auditācijas pierakstu veidošana un apskate, jauninājumu un piegāžu uzstādīšanas pieeja, rezerves kopēšanas un atjaunošanas pieeja).

ORG35 Programmatūras prasību specifikācija

Izstrādātājam ir jāizstrādā, jāsaskaņo ar Pasūtītāju un jāpiegādā programmatūras prasību specifikācija. Prasību specificēšana jāveic pakāpeniski lietotājstāstu veidā.Programmatūras prasību specifikācijas neatņemama sastāvdaļa ir arī struktūrskices un ekrānformu prototipi. Ekrānformu prototipi sagatavojami visām Platformas ekrānformām.Sistēmas programmatūras prasību specifikācija ir jāizstrādā atbilstoši standarta "ISO/IEC/IEEE 29148:2011 Systems and software engineering" prasībām (vai ekvivalenta standarta) un atbilstoši Projekta izstrādes metodikai.

Obligāta

ORG36 Programmatūras projektējuma apraksts

Programmatūras projektējuma aprakstā ir jāiekļauj vismaz:1. funkcionālā projektējuma apraksts; 2. datu loģikas projektējuma apraksts (izmantojot entītiju relāciju (no angļu val. -

entity relationship) diagrammas); 3. saskarņu projektējuma apraksts.

Programmatūras projektējuma apraksts ir jāizstrādā atbilstoši standarta "ISO/IEC/IEEE 1016:2009 Software design descriptions" prasībām (vai ekvivalenta standarta) un

Obligāta




atbilstoši projekta izstrādes metodikai.ORG37 Administratora

rokasgrāmataPlatformas administratora rokasgrāmatā jāiekļauj vismaz šāda informācija:

1. prasības Platformas darbības videi un standartprogrammatūras uzstādīšanas instrukcijas;

2. Platformas uzstādīšanas instrukcijas; 3. rezerves kopēšanas un darbības atjaunošanas instrukcijas; 4. izmaiņu un papildinājumu uzstādīšanas procedūra (administratora rokasgrāmatā

jāapraksta vispārīgie principi un kārtība, bet katrai versijai specifiskās uzstādīšanas instrukcijas iekļaujamas programmatūras versiju aprakstā);

5. uzturēšanas instrukcijas, tai skaitā informācija par auditācijas ierakstiem un žurnāldatnēm, informācija par konfigurācijas uzstādījumiem, informācija par kļūdas paziņojumiem un to apstrādes kārtību u. c.

Obligāta

ORG38 Programmatūras versijas apraksts

Programmatūras versijas aprakstā ir jāiekļauj vismaz šāda informācija:1. programmatūras versijas identifikators; 2. versijas sastāvs un nodevumu identifikatori; 3. versijā iekļautās izmaiņas (piegādāto funkcionālās prasību, realizēto izmaiņu

pieprasījumu un laboto kļūdu uzskaitījums);4. versijas uzstādīšanas instrukcijas.

Obligāta

ORG39 Prasību trasējamība Izstrādes gaitā ir jāizstrādā, jāiekļauj dokumentācijas nodevumos un jānodod vismaz šādas trasējamības tabulas:

1. iepirkuma nolikuma Tehniskās specifikācijas prasību un programmatūras prasību

Obligāta




specifikācijas dokumentā noteikto prasību trasējamība;2. programmatūras prasību specifikācijas dokumenta prasību un programmatūras

projektējuma apraksta trasējamība;3. programmatūras prasību specifikācijas dokumenta prasību un testēšanas

scenāriju trasējamība. ORG40 Nodevumu aktualizācija Katrā nākamajā piegādē Izstrādātājam jāpiegādā augstāk Tehniskajā specifikācijā

paredzētās nodevumu aktualizētās versijas, nodrošinot konfigurāciju un versiju pārvaldību saskaņā ar šīs specifikācijas prasībām, kā arī citi nodevumi, kuri saskaņā ar industrijas labo praksi ir vajadzīgi Platformas darbināšanai, t. sk. tālākai pilnveidošanai un uzturēšanai.

Obligāta

5.6.Nodevumu (laidienu) iesniegšanas un pieņemšanas kārtībaPrasības identifikators


ORG41 Nodevumu iesniegšanas kārtība

Izstrādātājam ir jāveic programmatūras piegāde pakāpeniski laidienu veidā, izstrādājot un piegādājot funkcionalitāti, balstoties uz Projekta laika plānu (sk. Prasību ORG01). Katra laidiena piegādes ietvaros Izstrādātājam jāiesniedz vismaz šāds piegādes nodevumu komplekts:

1. programmatūras versijas apraksts; 2. izstrādāto programmatūras risinājumu un gatavās programmatūras pielāgojumu

pirmkodi, gatavās programmatūras un izstrādāto programmatūras pielāgojumu

Obligāta




izpildkodi, konfigurācijas datnes (skripti); 3. Platformas dokumentācijas pirmreizējās vai aktualizētās versijas, tai skaitā

administratora rokasgrāmata, programmatūras prasību specifikācija (lietotājstāstu veidā), programmatūras projektējuma apraksts, lietotāja rokasgrāmata, testēšanas plāns, Izstrādātāja testēšanas (kopsavilkuma) pārskats;

4. u. c. dokumentācija pēc nepieciešamības.Pēdējā laidiena ietvaros jāiesniedz nodevumu konsolidētās versijas. Izstrādātājam, veicot piegādes, jāņem vērā Platformas administratora (Valsts reģionālās attīstības aģentūra) esošā kārtība par piegāžu noformēšanu.

ORG42 Nodevumu piegādes veids Dokumentācijas nodevumi Izstrādātājam ir jāpiegādā, ievietojot tos Projekta bibliotēkā un par to iesniegšanu nosūtot e-pastu uz Līgumā norādīto Pasūtītāja kontaktpersonas e-pasta adresi. Programmatūras nodevumi piegādājami izmantojot koda repozitoriju un automatizētus piegādes rīkus.Papildus augstāk minētajiem nodevumu piegādes veidiem nodevumu pēdējā laidiena konsolidētās versijas Izstrādātājam jāpiegādā uz nepārrakstāma fiziskā datu nesēja kopā ar parakstītu pavadvēstuli.

Obligāta

ORG43 Programmatūras nodevumu piegādes nosacījumi

Programmatūras nodevums jāpiegādā uzstādīšanai gan Pasūtītāja testa vidē, gan Pasūtītāja produkcijas vidē ar norādi par programmatūras nodevuma instalēšanas paketes uzstādīšanas vidi, ja tehniski nav iespējams piegādāt programmatūras nodevuma instalēšanas paketi, kas izmantojama abās vidēs.Piegāžu uzstādīšanai jābūt automatizētai.

Obligāta




Programmatūras instalēšanas paketei jābūt “inkrementālai”, t. i., tās uzstādīšana ir veicama uz iepriekš piegādātas versijas. Programmatūras nodevumi nedrīkst ietekmēt datubāzē jau esošos datus, ja vien tas nav iepriekš īpaši saskaņots vai nav nodevumu objekts. Gadījumos, ja tiek mainīta datu struktūra, jāpiegādā arī atbilstošie datu konvertācijas skripti. Visiem programmatūras nodevumiem ir jānodrošina versiju identifikācija un kontrole.

ORG44 Prasības programmatūras piegādei

Izstrādātājam jāpiegādā Pasūtītājam izstrādātā programmatūra, t. sk. programmatūras pirmkods. Programmatūras nodevumos iekļautajiem programmatūras pirmkodiem ir jābūt skaidri un precīzi dokumentētiem, tai skaitā programmatūras kodam jāsatur komentāri latviešu vai angļu valodā, kas ir viegli saprotami atbilstošas kvalifikācijas speciālistiem bez pirmkoda autora palīdzības. Piegādātā programmatūras pirmkoda kvalitātei ir jābūt pietiekošai, lai Pasūtītāja paša vai tā nolīgts trešās puses kvalificēts personāls varētu nodrošināt programmatūras turpmāko uzturēšanu, modificēšanu, paplašināšanu, kā arī iespējamo migrēšanu.Ja Izstrādātājs izmanto standarta programmatūru, tad Izstrādātājam ir jāpiegādā programmatūras pirmkods, pielāgojumu pirmkodi un konfigurācijas datnes (skripti). Standarta programmatūras lietošanas gadījumā Izstrādātājam jāpiegādā dokumentācija, kurā detalizēti aprakstīti ievades un izvades parametri. Standarta programmatūras lietošanas gadījumā Izstrādātājam un Pasūtītājām ir jābūt neierobežotām tiesībām lietot šo programmatūru.Programmatūras izpildkods ir Izstrādātājam jāpiegādā Pasūtītājam instalācijas pakotnēs,

Obligāta




kas ļauj to uzstādīt testēšanas un produkcijas vidēs atbilstoši uzstādīšanas instrukcijai, administratora rokasgrāmatai un citai dokumentācijai. Kopā ar programmatūras izpildkodu ir jāpiegādā arī konfigurācijas skripti vai datnes, kas nepieciešamas programmatūras uzstādīšanai un darbināšanai.Norāde Tehniskajam piedāvājumam: Izstrādātājam ir jāapraksta programmatūras dokumentēšanas principi un apjoms.Programmatūras piegādēm un uzstādīšanai jābūt automatizētai.Izpildītājam jānodrošina testa vides uzstādīšana, t.sk. videi nepieciešamās programmatūras licences. Infrastruktūru testa videi nodrošina Iekšlietu ministrijas informācijas centrs (skat. prasību INFR01).

ORG45 Akceptēšanas kārtība 1. Izstrādātājs piegādā dokumentāciju, kas apliecina Izstrādātāja testēšanas pabeigšanu (testēšanas dokumentāciju), un Platformas laidiena piegādes komplektu.

2. Izstrādātājs veic piegādātās programmatūras uzstādīšanu Pasūtītāja testa vidē. Ja uzstādīšana ir neveiksmīga, tālāka akceptēšana tiek pārtraukta.

3. Platformas programmatūras laidiena akcepttestēšana tiek sākta pēc programmatūras sekmīgas uzstādīšanas Pasūtītāja testa vidē. Pasūtītājs un tā pārstāvji 20 (divdesmit) darba dienu laikā veic akcepttestu, saskaņā ar lietotājstāstos definētajiem akceptēšans kritērijiem. Ja piegādātais programmatūras apjoms ir liels, Pusēm vienojoties, akcepttestēšanas termiņš var tikt pagarināts. Testēšanas ietvaros identificētās kļūdas tiek reģistrētas

Obligāta




Izstrādātāja Pieteikumu apstrādes sistēmā. Balstoties uz reģistrētajiem pietiekumiem, Izstrādātājam jāveic identificēto defektu novēršana un jāpiegādā funkcionalitāte atkārtotai akcepttestēšanai.

4. Izstrādātājam akcepttestēšanas rezultātā jāsagatavo un jāiesniedz Pasūtītāja norādītajām personām testēšanas pārskats (rezultātu kopsavilkums).

5. Testu izpildē atklātās problēmas tiks grupētas pēc sekojošām kategorijām:

Kategorija

Skaidrojums

1 Avārija – problēma izraisa pilnīgu sistēmas darbības apstāšanos un/vai darbs nevar tikt turpināts.

2 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 Pasūtītājam pieņemams problēmas apiešanas risinājums, tomēr ir iespējams darbu turpināt ierobežotā režīmā.

3 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 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, gramatikas kļūda, neprecizitāte produkta dokumentācijā u. c.

5 Izmaiņu pieprasījums – pieprasījums veikt izmaiņas vai papildināt sistēmas funkcionalitāti, dokumentāciju vai veikt citus papildu darbus, kas ir ārpus līguma sfēras vai atšķiras no iepriekš saskaņotajām prasībām.

6 Konsultācija - 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.

6. Piegāde tiek akceptēta, ja akcepttestam netiek konstatētas 1. un 2. kategorijas kļūdas, bet 3. kategorijas kļūdu skaits nepārsniedz 10 (desmit).

7. 3. un 4. kategorijas kļūdas tiek fiksētas nodošanas – pieņemšanas aktā, nosakot konkrētu to novēršanas laiku, kas nedrīkst pārsniegt 20 (divdesmit) darba dienas no nodošanas-pieņemšanas akta parakstīšanas brīža.

ORG46 Akcepttestēšanas laikā atklāto kļūdu novēršana

Konstatējot 1. un 2. kategorijas kļūdas, Platformas programmatūras akcepttestēšana tiek apturēta. Izstrādātājam jānovērš šīs kļūdas 3 (trīs) darba dienu laikā un jāiesniedz Platformas funkcionalitāte atkārtotai akcepttestēšanai.Akcepttestēšanas laikā pieteiktās kļūdas Izstrādātājam ir jānovērš līdz 20 (divdesmit) darba dienu laikā un jāiesniedz Pasūtītājam programmatūra atkārtotai akcepttestēšanai. Pasūtītājs un tā pārstāvji atkārtotu akcepttestu veic 10 (desmit) darba dienu laikā.Gadījumā, ja ar trešo akcepttestēšanas iterāciju programmatūra netiek akceptēta,

Obligāta




Pasūtītājam ir tiesības Platformas programmatūru nepieņemt.ORG47 Dokumentācijas nodevumu

akceptēšanaIesniegtos dokumentācijas nodevumus Pasūtītājs un Konsultanti izskata 20 (divdesmit) darba dienu laikā, ja vien ar Izstrādātāju nav panākta vienošanās par citu izskatīšanas termiņu. Iebildumus, komentārus un jautājumus nodevumu izskatītāji pievieno nodevuma saturā Projekta bibliotēkā.Izstrādātāja pienākums ir apstrādāt no Pasūtītāja puses reģistrētos komentārus 10 (desmit) darba dienu laikā pēc nodevuma termiņa izskatīšanas beigām, ja vien ar Pasūtītāju nav panākta vienošanās par citu apstrādes termiņu. Izstrādātājs pēc nepieciešamības var organizēt komentāru izskatīšanas sanāksmi/-es. Pasūtītājam ir tiesības dokumentācijas nodevumu nepieņemt, līdz nav apstrādāti visi komentāri un novērsti visi iebildumi vai sniegti argumentēti pamatojumi, kāpēc Pasūtītāja komentāri netiek iestrādāti.

Obligāta

ORG48 Pieteikumu apstrādes sistēma

Izstrādātājam ir jānodrošina elektroniska vide problēmu reģistrēšanai un risināšanas procesa izsekošanai, kas pieejama no pārlūkprogrammas. Pasūtītāja un Konsultantu pārstāvjiem jābūt piekļuvei šai videi problēmu reģistrēšanai un atgriezeniskās saites nodrošināšanai. Pasūtītāja norādītam pārstāvim jābūt iespējai slēgt pieteikumus.Izstrādātājam pieteikumu apstrādes sistēmā pašam jāveic visu reģistrēto kļūdu apstrāde, t. sk. dublikātu identificēšana. Ja ir identificēts dublikāts (pieteikums par kļūdu funkcionalitātē, kuru pieteicis jau kāds cits lietotājs), tad jābūt iespējai šādus pieteikumus sasaistīt un vienu no tiem slēgt.Pieteikumu apstrādes sistēmā tiek pieteiktas akcepttestēšanas, uzturēšanas un garantijas ietvaros identificētās kļūdas.

Obligāta




Pasūtītāja un Konsultanta pārstāvjiem pieteikumu apstrādes sistēmā ir jāvar ievadīt vismaz:

1. pieteikuma nosaukums;2. pieteikuma autors;3. pieteikuma apraksts (t. sk. jāvar pievienot attēlus, lai ilustrētu problēmu);4. pieteikuma veids (kļūda, izmaiņu pieprasījums u. c.);5. pieteikuma kategorija (atbilstoši prasībā ORG60 definētajam);6. komentārs pie konkrētā pieteikuma.

Reģistrējot pieteikumu, tajā jāuzrādās pieteikšanas datumam un laikam.Pieteikuma autoram jābūt iespējai saņemt e-pastu (vai arī atteikties no e-pastu saņemšanas) par pieteikuma risinājuma statusa maiņu.Izstrādātājam tehniskajā piedāvājumā ir jāapraksta pieteikumu pārvaldība, norādot pieteikuma veidu apstrādes darbplūsmas (statusus un statusus maiņu).Izstrādātājam finanšu piedāvājumā jāietver visas izmaksas, kas saistītas ar pieteikumu apstrādes sistēmas lietošanu Projekta ietvaros.

5.7.TVP ieviešanaPrasības identifikators


ORG49 Platformas uzstādīšana Pēc veiksmīgas akcepttestēšanas pabeigšanas Platformas administratoram, pēc Obligāta




produkcijas vidē nepieciešamības piesaistot Izstrādātāju, jāveic Platformas programmatūras uzstādīšana un konfigurēšana produkcijas vidē. Izstrādātājam ir jāpiegādā pēdējās atkļūdotās programmatūras un dokumentācijas versijas.Programmatūras piegādēm un uzstādīšanai jābūt automatizētai.

ORG50 Platformas pārbaude produkcijas vidē

Pēc Platformas uzstādīšanas produkcijas vidē tiks veikta atkārtota Platformas funkcionalitātes pārbaude (izmēģinājuma ekspluatācija), kas apliecina, ka visas prasības joprojām ir izpildītas, ņemot vērā iespējamās produkcijas un testu vides atšķirības un jo īpaši tās prasības, kuras pilnībā nav iespējams pārbaudīt testa vidē. Testus veiks Pasūtītājs un Pasūtītāja deleģēta trešā puse.

Obligāta

ORG51 Platformas ieviešanas pabeigšana produkcijas vidē

Platformas ieviešana produkcijas vidē tiek uzskatīta par pabeigtu, ja Platformas pārbaudes ietvaros produkcijas vidē netiek konstatētas 1., 2. vai 3. kategorijas problēmas (problēmu kategorijas aprakstītas prasībā ORG60).

Obligāta

5.8.MācībasPrasības identifikators


ORG52 Platformas administratoru mācības

Izstrādātājam ir jānodrošina Platformas administratoru mācības ne agrāk kā 1 (vienu) mēnesi pirms Platformas plānotās nodošanas akcepttestēšanai.

Obligāta




Mācību ietvaros jāizglīto līdz 5 (pieci) Platformas administratori tādā līmenī, lai viņi spētu patstāvīgi veikt Platformas administrēšanas, uzraudzības un atjaunošanas pasākumus un veikt citas ar Platformas administrēšanu saistītas funkcijas. Platformas administratoru mācībām ir jāietver gan teorētiskā daļa, gan praktiskā daļa ar praktiskiem treniņa uzdevumiem.Norāde finanšu piedāvājumam: Mācības finanšu piedāvājumā ir izdalāmas kā atsevišķa izmaksu pozīcija.

ORG53 Satura administratoru un Satura administratoru ar īpašām tiesībām mācības

Izstrādātājam ir jānodrošina tīmekļvietņu Satura administratoru un Satura administratoru ar īpašām tiesībām mācības. Mācības jāorganizē Iestāžu grupām, atbilstoši Iestāžu Satura vienību migrācijas grafikam, nodrošinot, lai Iestāžu satura administratoru mācības būtu pabeigtas ne agrāk kā vienu mēnesi pirms Iestādes Satura vienību migrācijas.Izstrādātājam jānodrošina Satura administratoru un Satura administratoru ar īpašām tiesībām mācības Pasūtītāja noteiktiem lietotājiem tādā līmenī, lai tie spētu patstāvīgi veikt tīmekļvietnes administrēšanu iestādes līmenī (lietotāju pārvaldības iestādes līmenī, satura pārvaldība u. c.). Mācībām ir jāietver gan teorētiskā daļa, gan praktiskā daļa ar praktiskiem treniņa uzdevumiem.Mācību ietvaros Izstrādātājam jāizglīto kopā līdz 150 (viens simts piecdesmit) Satura administratoru un Satura adminitratoru ar īpašām tiesībām, paredzot, ka grupā ir ne vairāk kā 20 (divdesmit) cilvēki. Visi Satura administratori nav jāmāca par visām tēmām, bet tikai tām, kuras tiem nepieciešamas tiešo darba pienākumu veikšanai (atbilstošo biznesa procesu izpildei).

Obligāta




Norāde finanšu piedāvājumam: Mācības finanšu piedāvājumā ir izdalāmas kā atsevišķa izmaksu pozīcija.

ORG54 Mācību vieta Izstrādātājam ir jānodrošina mācības Rīgas administratīvajā teritorijā savās telpās (iepriekš saskaņojot) vai Pasūtītāja norādītajās telpās (iepriekš saskaņojot). Izstrādātājs nodrošina visu nepieciešamo tehnisko aprīkojumu (t. sk. programmatūras nodrošinājumu, pieejas testa videi u. c.) un mācību materiālus, kas nepieciešami veiksmīgai mācību norisei.Norāde finanšu piedāvājumam: Mācības finanšu piedāvājumā ir izdalāmas kā atsevišķa izmaksu pozīcija, t.sk. šajā pozīcijā ietverot izmaksas mācību vietas nodrošināšanai.

Obligāta

ORG55 Mācību norise Mācību programma, tās veikšanas laiks un izglītojamo dalībnieku skaits katrā mācības programmā saskaņojams ar Pasūtītāju pirms mācību programmas uzsākšanas.

Obligāta

ORG56 Mācību nodevumi Izstrādātājam ir jānodrošina mācību veikšana un jāsagatavo vismaz šādi nodevumi: 1. Mācību plāns. Mācību plānā ir detalizēti jāapraksta mācību mērķis, saturs, laika

grafiks, jānosaka prasības izglītojamo grupām. Pirms mācību veikšanas ir jābūt izstrādātai pietiekoši stabilai Platformas versijai, lai nodrošinātu mācību praktisko daļu;

2. Mācību materiāli. Izstrādātājam ir jāizstrādā un pirms mācību veikšanas jāsaskaņo ar Pasūtītāju mācību materiāli, t.sk. prakstiskie uzdevumi, kurus mācību dalībnieks izpildīs Platformā.

3. Mācību materiāli veidojami kā MS PowerPoint, MS Word vai cita formāta dokumentācija atbilstoši tehniskajam piedāvājumam. Mācību materiāliem ir jātiek iesniegtiem pārskatīšanai un akceptēšanai no Pasūtītāja puses vismaz 10 (desmit) darba dienas pirms mācību norises.

Obligāta


5.9.Garantijas prasībasPrasības identifikators


ORG57 Garantijas pakalpojumu periods un apjoms

Izstrādātājam ir jānodrošina garantijas pakalpojumi, sākot no TVP ekspluatācijas uzsākšanas 2020. gada 29. martā un 24 (divdesmit četru) kalendāro mēnešu periodā, skaitot no Projekta pabeigšanas dienas (2021. gada 4. janvāris), kad veikta 48 iestāžu tīmkļevietņu migrācija uz TVP.Izstrādātājam garantijas pakalpojumu sniegšanas izmaksas ir jāiekļauj Līguma priekšmeta cenā, neizdalot to kā atsevišķu pozīciju Finanšu piedāvājumā. Garantijas pakalpojumu ietvaros Izstrādātājam ir jāveic šādas aktivitātes:

1. piegādātās Platformas funkcionalitātes darbības traucējumu un/vai kļūdu un nepilnību diagnosticēšana, analīze un novēršana;

2. jānovērš datu bojājumi, kas radušies piegādātās programmatūras (t. sk. trešās puses programmatūras) kļūdu vai Izstrādātāja apzinātas vai neapzinātas rīcības rezultātā un kas apgrūtina Platformas izmantošanu atbilstoši Platformas tehniskajai specifikācijai, kāda tā bijusi, nododot Platformu ekspluatācijā;

3. dokumentācijas labošana (t. i., labošana, papildināšana utt.) atbilstoši visiem garantijas nodrošināšanas ietvaros veiktajiem labojumiem Platformā;

4. Pasūtītāja atbalsts ar garantiju saistītos jautājumos.Garantijas perioda laikā par izmaiņu pieteikumu nevar uzskatīt loģiskās kļūdas projektējumā vai projektējumam un prasībām neatbilstošas realizācijas programmatūras kodā.Nepilnību diagnosticēšana un pārējie garantijas pakalpojumi sniedzami uz reģistrēto pieteikumu pamata, reaģējot uz Pasūtītāja pieteiktajām kļūdām,

Obligāta

ORG58 Pasūtītāja atbalsts Izstrādātājam garantijas ietvaros jānodrošina lietotāju atbalsts Platformas Obligāta




garantijas pakalpojuma nodrošināšanas laikā

administratoriem, Satura administratoriem ar īpašām tiesībām un Satura administratoriem.Izstrādātājam jānodrošina Platformas administratoru tehniskais atbalsts no plkst. 8:00 līdz 18:00. Ārpus darba laika Platformas administratoru tehniskais atbalsts tiek pieteikts savlaicīgi un nepārsniedz 40 (četrdesmit) stundas gadā. Satura administratoru ar īpašām tiesībām un Satura administratoru lietotāju atbalsts darba dienās no plkst. 8:00 līdz 18:00 šādā apjomā:

1. sniegt Platformas admiminstratoriem tehniskas konsultācijas par Platformas darbību;

2. sniegt Satura administratoriem ar īpašām tiesībām un Satura administratoriem konsultācijas par sistēmas lietošanu;

3. reģistrēt pietiekumu apstrādes sistēmā lietotāju ziņotās problēmas vai priekšlikumus Platformas uzlabošanai.

Garantijas ietvaros lietotāju un tehniskais atbalsts sniedzams, izmantojot šādus komunikācijas kanālus – telefoniski un e-pastā. Izstrādātājam ir jānodrošina visi norādītie komunikācijas kanāli, tomēr Izstrādātājs, vienojoties ar Pasūtītāju, var noteikt primāri izmantojamo komunikācijas kanālu. Pasūtītāja atbalsts, kas nav saistīts ar Platformas kļūdu pieteikšanu un apstrādi, tiek klasificēts kā izmaiņu pieprasījums.Izstrādātājam pieteikumu apstrādes sistēmā jānodrošina katra notikuma fiksēšana, atsekošana un statusa noteikšana, kā arī iespēja Pasūtītājam operatīvi iepazīties ar datiem par notikumiem.

ORG59 Problēmu ziņojumu Kļūdas un pieteikumi tiek klasificēti šādi: Obligāta




kategorijas Kategorija

Skaidrojums

1 Avārija – problēma izraisa pilnīgu sistēmas darbības apstāšanos un/vai darbs nevar tikt turpināts.

2 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 Pasūtītājam pieņemams problēmas apiešanas risinājums, tomēr ir iespējams darbu turpināt ierobežotā režīmā.

3 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 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, gramatikas kļūda, neprecizitāte produkta dokumentācijā u. c.

5 Izmaiņu pieprasījums – pieprasījums veikt izmaiņas vai papildināt sistēmas funkcionalitāti, dokumentāciju vai veikt citus papildu darbus, kas ir ārpus līguma sfēras vai atšķiras no iepriekš saskaņotajām prasībām.

6 Konsultācija – 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.ORG60 Reakcijas laiks uz garantijas

ietvaros reģistrētajiem pieteikumiem

Izstrādātājam jānodrošina Platformas darbības traucējumu, kļūdu un nepilnību pieteikumu izpēte, klasifikācija un atbildes sniegšana – reakcijas laikā (stundās) no problēmas pieteikšanas brīža par problēmziņojumā norādītās problēmas cēloni un novēršanas laiku saskaņā ar šādiem reakcijas laikiem:

Prioritāte Reakcijas laiks

1. kategorija

Ne lielāks par 2 (divām) stundām

2. kategorija

Ne lielāks par 4 (četrām) stundām

3. kategorija

Ne lielāks par 8 (astoņām) Pasūtītāja darba laika stundām*

4. kategorija

Ne lielāks par 16 (sešpadsmit) Pasūtītāja darba laika stundām*

*Reakcijas laika atbildes ilguma noteikšanai tiek ņemts vērā Pasūtītāja darba laiks (izņemot oficiālās svētku dienas): no pirmdienas līdz ceturtdienai no plkst. 8:00 līdz plkst. 17:00, piektdien no plkst. 8:00 līdz plkst. 15:45.

Obligāta

ORG61 Problēmu ziņojumu novēršanas termiņi

Izstrādātājam jānodrošina šādi problēmu novēršanas laiki no problēmas reģistrēšanas Izstrādātāja pieteikumu apstrādes sistēmā:

Obligāta




Prioritāte Novēršanas termiņš

1. kategorija

Ne vēlāk par 4 (četrām) stundām

2. kategorija

Ne vēlāk par 16 (sešpadsmit) stundām

3. kategorija

Ne vēlāk par 40 (četrdesmit) Pasūtītāja darba laika stundām*

4. kategorija

Ne vēlāk par 20 (divdesmit) kalendāro dienu laikā

*Novēršanas termiņš tiek ņemts vērā Pasūtītāja darba laiks (izņemot oficiālās svētku dienas): no pirmdienas līdz ceturtdienai no plkst. 8:00 līdz plkst. 17:00, piektdien no plkst. 8:00 līdz plkst. 15:45.


5.10. Uzturēšanas prasībasPrasības identifikators


ORG62 Uzturēšanas pakalpojumu periods un apjoms

Izstrādātājam ir jānodrošina uzturēšanas pakalpojumi Līguma darbības, t. sk. garantijas periodā. Uzturēšanas pakalpojuma nodrošināšanas periodā ir jānodrošina:

1. piegādātās programmatūras uzturēšana (bez papildu maksas); 2. izmaiņu pieprasījumu darbietilpības novērtēšana (bez papildu maksas), izmaiņu

pieprasījumu realizēšana un dokumentācijas izstrāde vai aktualizēšana atbilstoši veiktajām izmaiņām Platformā;

3. konsultāciju sniegšana vai informācijas sagatavošana par šādiem tematiem: a) optimālāko izmaiņu risinājumu (t. sk. tehniskajiem resursiem) saistībā ar

normatīvo aktu izmaiņām; b) ieviešamo izmaiņu ietekmi uz saistītajiem moduļiem/sistēmām;c)iespējamiem risinājumiem, kas ļauj pievienot jaunu funkcionalitāti jau esošajai (konsultējot par tehniski efektīvākajiem un finansiāli izdevīgākajiem tehniskā risinājuma variantiem);d) lietotajām tehnoloģijām, to iespējām un pāreju uz jaunākām versijām vai citām tehnoloģijām;e) sistēmas lietošanas un lietotāju mācību jautājumiem, tai skaitā pēc pieprasījuma nodrošinot mācības;f) sistēmas elementu (lietotāja aplikācijas, datubāzu vadības sistēmas, aparatūras) konfigurēšanu;g) sistēmas ekspluatācijas neskaidrībām un problēmu gadījumiem, tajā skaitā

Obligāta




datu apmaiņu starp Platformu un ārējām sistēmām;h)citiem ar Platformu saistītiem jautājumiem;

4. dalība sanāksmēs.ORG63 Standartprogrammatūr

as uzturēšanas nosacījumi

Platformas uzturēšanas pakalpojuma ietvaros gadījumos, kad tiek izdoti Platformas darbības nodrošināšanā izmantotās standartprogrammatūras (trešās puses programmatūras) jauninājumi vai kritiskie ielāpi, Izstrādātājs bez maksas:

1. seko līdzi Platformas darbības nodrošināšanā izmantotās standartprogrammatūras (trešās puses programmatūras) jauninājumiem un kritiskiem drošības ielāpiem un 24 (divdesmit četru) stundu laikā informē Pasūtītāju par testēšanas rezultātiem un jauninājumu/ielāpu uzstādīšanas nepieciešamību, vienojas par uzstādīšanu.

2.

Obligāta

ORG66 Uzturēšanas pakalpojumu pieteikšana un apstrāde

Saņemot Platformas funkcionalitātes izmaiņu pieprasījumu Problēmu ziņojumu reģistrā, pirms tā realizācijas uzsākšanas Izstrādātājs ar Pasūtītāju saskaņo nepieciešamo izmaiņu vai papildināšanas pieprasījuma prasības, precīzas realizācijas izmaksas, sagaidāmo rezultātu, izpildes termiņus, pieņemšanas–nodošanas kārtību un citus nepieciešamos nosacījumus. Izstrādātājam izmaiņu pieprasījumu pieteikumu apstrāde jāveic 5 (piecu) darba dienu laikā, kuru ietvaros Pasūtītājam jāsniedz sākotnējais realizācijas novērtējums, kas satur veicamo darbu vispārīgu aprakstu un atbilstošo kopējo darbietilpības novērtējumu stundās,vai jāvienojas ar Pasūtītāju par citu termiņu novērtējuma iesniegšanai.Ja Pasūtītājs apstiprinājis Izstrādātāja iesniegto sākotnējo realizācijas novērtējumu, Izstrādātājs 10 (desmit) darba dienu laikā no Pasūtītāja apstiprinājuma iesniedz Pasūtītājam detalizētu izmaiņu pieprasījuma realizācijas piedāvājumu, kurā:

Obligāta




1. Definētas izmaiņu pieprasījuma funkcionālās prasības un to akceptēšanas kritēriji;2. Noteikta izmaiņu pieprasījuma realizācijai nepieciešamā darbietilpība (var atšķirties

no sākotnējās darbietilpības ne vairāk kā par 10%);3. Norādīts darbu izpildes termiņš, ieskaitot laiku, kāds nepieciešams akceptēšanas

procedūrai;4. Norādīts nepieciešamo interviju plāns, nepieciešamā informācija un citi Pasūtītāja

resursi, kuri jāiesaista darbu izpildē;5. Norādīti izpildē iesaistītie Izpildītāja darbinieki.

5.11. Datu migrācijaPrasības identifikators


ORG67 Datu migrācija no iestāžu tīmekļvietnēm

Izstrādātājam jānodrošina datu migrācija no Projekta ietvaros esošo iestāžu tīmekļvietnēm (12 pilotprojekta iestāžu tīmekļvietnes un 48 Projektā iesaistīto iestāžu tīmekļvietnes) uz Platformā izveidotajām un izvietotajām tīmekļvietnēm (produkcijas vidē).Izstrādātājam, sadarbojoties ar katru iestādi atsevišķi, ņemot vērā Platformas funkcionalitāti, jāvienojas par migrējamo datu apjomu.Izstrādātājs saskaņā ar Pasūtītāja apstiprinātiem darba uzdevumiem veic Iestāžu tīmekļvietņu satura migrāciju uz Platformu. Viena darba uzdevuma ietvaros tiek veikta 12

Obligāta




(divpadsmit) Iestāžu tīmekļvietņu satura migrācija.Norāde tehniskajam piedāvājumam: Pretendentam tehniskajā piedāvājumā jāiekļauj piedāvātās datu migrācijas metodikas apraksts.

ORG68 Datu migrācijas aktivitātes

Datu migrācijas ietvaros Izstrādātājam ir jāveic vismaz šādas aktivitātes:1. jāveic esošo datu analīze ar mērķi konstatēt datus, kas dublējas, kas neatbilst

plānotajai Platformas funkcionalitātei vai kas kā citādāk nav piemēroti migrācijai. Informācija par kļūdainajiem datiem jānodod iestādei, kuras tīmekļvietnē tas identificēts, lai tā varētu veikt nepieciešamās datu labošanas aktivitātes;

2. jāizstrādā un ar Pasūtītāju jāsaskaņo datu migrācijas plāns;3. ja Izpildītājs piedāvā datu migrāciju veikt ar skriptiem, tad jāsagatavo datu

migrācijas skripti un datu migrācijas instrukcijas; 4. jāveic datu migrācija;5. jāsagatavo datu migrācijas kvalitātes pārbaudes, kas ļauj pārliecināties par datu

migrācijas kvalitatīvajiem un kvantitatīvajiem rezultātiem;6. jāveic migrēto datu kvalitātes pārbaude;7. jāsniedz Pasūtītājam konsultatīvs atbalsts datu migrācijas un datu migrācijas

testēšanas laikā; 8. Izstrādātājam ir jāveic vēsturisko datu migrācija, bet Izstrādātājs nav atbildīgs par

pārņemamo vēsturisko datu līdzšinējo kvalitāti un Izstrādātājam nav jāveic šo kvalitātes nepilnību labošana.

Obligāta


6. PRASĪBU TRASĒJAMĪBAS MATRICATehniskajā specifikācijā iekļauto prasību izstrāde tika veikta, pamatojoties uz šādiem informācijas avotiem:

Prasību kopums, sadaļa Prasību avots

3.1. Vispārīgās prasības 1. Sanāksmes ar Satura administratoriem;2. Sanāksmes ar Satura patērētājiem;3. Normatīvie akti;

3.2. Satura veidošana 1. Sanāksmes ar Satura administratoriem;2. Sanāksmes ar Satura patērētājiem;3. Lietojamības testi;4. VGR sanāksmes;

3.3.Satura pārvaldība 1. Sanāksmes ar Satura administratoriem;2. Sanāksmes ar Satura patērētājiem;3. Normatīvie akti;4. Lietojamības testi;5. VGR sanāksmes;

3.4. Satura publicēšana 1. Sanāksmes ar Satura administratoriem;2. Sanāksmes ar Satura patērētājiem;3. Normatīvie akti;4. Lietojamības testi;5. VGR sanāksmes;

3.5.Satura administratora darba vide

1. Sanāksmes ar Satura administratoriem;

3.6.Platformas administratora darba vide

1. Sanāksmes ar Satura administratoriem;2. Sanāksme par arhitektūru;3. VGR sanāksmes;

3.7.Meklētājs 1. Sanāksmes ar Satura administratoriem;



2. Sanāksmes ar Satura patērētājiem;3. Lietojamības testi;4. VGR sanāksmes;

3.8.SEO (Search engine optimization) funkciju nodrošinājums

1. Sanāksmes ar Satura administratoriem;2. Sanāksmes ar Satura patērētājiem;3. Lietojamības testi;4. Sanāksme par arhitektūru;5. VGR sanāksmes;

3.9.Indeksēšanas pakalpe 1. Sanāksme par arhitektūru;2. VGR sanāksmes;

3.10.Informācija par iestādes pakalpojumiem

1. Sanāksmes ar Satura administratoriem;2. Sanāksmes ar Satura patērētājiem;3. Lietojamības testi;4. VGR sanāksmes;

3.11.Statistikas pārskati 1. Sanāksmes ar Satura administratoriem;2. VGR sanāksmes;

3.12.Iepirkumu informācijas publicēšana

1. Sanāksmes ar Satura administratoriem;2. Sanāksme ar VRAA un IUB;3. Normatīvie akti

3.13.Lietotāju pārvaldība 1. Sanāksmes ar Satura administratoriem;2. Sanāksme par arhitektūru;3. VGR sanāksmes;

3.14.Grafiskā lietotāju saskarne

1. Sanāksmes ar Satura administratoriem;2. Sanāksme par arhitektūru

3.15.Datu arhivēšana 1. Sanāksmes ar Satura administratoriem;2. Sanāksme par arhitektūru;3. VGR sanāksmes;



3.16.Lietojamības prasības 1. Sanāksmes ar Satura administratoriem;2. Sanāksmes ar Satura patērētājiem;3. Lietojamības testi;4. Starptautiski standarti;

3.17.Datu apmaiņa 1. Sanāksmes ar Satura administratoriem;2. Sanāksme par arhitektūru;3. Sanāksme ar VRAA un IUB;4. Sanāksme ar KISC;5. Sanāksme ar CIVIS projekta komandu;6. VGR sanāksmes;

4.1.-4.8 Nefunkcionālās prasības

1. Sanāksmes ar Satura administratoriem;2. Sanāksmes par arhitektūru;3. Sanāksme ar VRAA un IUB;4. Sanāksmes ar VRAA un VARAM;5. Sanāksme ar KISC;6. Sanākmse ar IeM IC;7. VGR sanāksmes;

5.1.-5.11. Organizatoriskās prasības

1. Sanāksmes ar Satura administratoriem;2. Sanāksmes par arhitektūru;3. VGR sanāksmes;


7. PRASĪBU SAVSTARPĒJO ATKARĪBU APRAKSTSIzstrādātājam ir jārealizē visas sadaļā “3. Funkcionālās prasības” iekļautās prasības, kuras noteiktas kā “Obligāta”, ievērojot Nefunkcionālās un Organizatoriskās prasības, kas aprakstītas 4. un 5. sadaļā un to savstarpējo mijiedarbību.

Izstrādātājam, projektējot Platformu un izstrādājot to, jāņem vērā dokumentā esošās prasības, kuru prioritāte noteikta kā “Nākotnes prasība”. Par šo prasību realizāciju Pasūtītājs lems Projekta realizācijas gaitā un izstrādātajai Platformas funkcionalitātei jābūt tādai, lai Nākotnes prasības būtu iespējams realizēt.

Izstrādātājam tehniskajā piedāvājumā jāiekļauj prasību savstarpējo atkarību apraksts, norādot secīgu prasību realizāciju un to savstarpējo atkarību izstrādes ietvaros, lai nodrošinātu pilnu Platformas funkcionalitāti, pieņemot, ka:

1. sākotnēji jārealizē Platformas pamatfunkcionalitāte un secīgi datu apmaiņas saskarnes;

2. nefunkcionālās prasības attiecināmas uz visu funkcionālo prasību izpildi;

3. lietojamības prasības attiecināmas uz visām prasībām, kas saistītas ar lietotāju saskarņu izveidi.

Documents

informācijas sistēmas Tehniskā specifikācija · Web view2018-12-06 · Formā jāvar pievienot vismaz šādas datnes: .docx, .pdf, .jpg, .jpeg, ... Infografika – .jpg, .jpeg,