ATKLĀTA KONKURSA
PIEŅEMTS
VAS “Elektroniskie sakari” Pastāvīgās iepirkumu komisijas sēdē 2018. gada 20. februārī
(protokols Nr. VASES 2018/04-1)
APSTIPRINĀTS
VAS “ Elektroniskie sakari” Valdes sēdē
2018. gada 27. februārī (protokols Nr. 4/2018)
ATKLĀTA KONKURSA
„Numerācijas datu bāzes izstrāde un uzturēšana” nolikums
Rīga 2018
SATURS
II Pretendenta atlases dokumenti 6
V Piedāvājuma vērtēšana un lēmuma pieņemšana 11
VII Pastāvīgās iepirkumu komisijas tiesības un pienākumi 15
VIII Pretendentu tiesības un pienākumi 16
IX Iepirkuma līguma izpildē iesaistītā personāla un apakšuzņēmēju nomaiņa 17
Pielikums Nr. 1 : Pieteikums par piedalīšanos atklātā konkursā Pielikums Nr. 2 : Tehniskā specifikācija
Pielikums Nr. 3 : Tehniskais piedāvājums (veidlapa) Pielikums Nr. 4 : Finanšu piedāvājums (veidlapa) Pielikums Nr. 5 : Informācija par Pretendentu (veidlapa) Pielikums Nr. 6 : Līgums (projekts)
1. Iepirkuma identifikācijas numurs – VASES 2018/04.
2. Pasūtītāja nosaukums, adrese, rekvizīti – Valsts akciju sabiedrība “Elektroniskie sakari” (turpmāk – VAS ES); vienotais Reģ. Nr. 40003021907, Xxxxxxxx xxxx 0, Xxxx, Xxxxxxx, XX-0000, tālrunis - 67333034, fakss - 67821275.
3. Iepirkuma nomenklatūra (CPV kods) – 72230000-6, 72263000-6, 72267000-4.
4. Iepirkuma priekšmets: Numerācijas datu bāzes (turpmāk – NDB) izstrāde un uzturēšana saskaņā ar Tehnisko specifikāciju (Pielikums Nr.2), kura satur minimālās prasības attiecībā uz iepirkuma priekšmetu.
5. Līguma izpildes laiks: līdz 2021.gada 30.decembrim sadalīti pa kārtām:
5.1. NDB pirmās kārtas izstrāde un ieviešana – līdz 2018.gada 30.decembrim;
5.2. NDB otrās kārtas izstrāde un ieviešana – līdz 2019.gada 30.decembrim;
5.3. NDB uzturēšana – no pirmās kārtas izstrādes un ieviešanas līdz līguma izpildei.
* Pasūtītājs atklāta konkursa ietvaros garantē NDB pirmās kārtas izstrādi un ieviešanu, ja nebūs pieejami nepieciešamie līdzekļi NDB otrās kārtas izstrādei un ieviešanai, Pasūtītājam ir tiesības atlikt uz nenoteiktu laiku vai atteikties no NDB otrās kārtas izstrādes un ieviešanas.
6. Līguma izpildes vieta – Latvijas Republika.
7. Atklātā konkursa „Numerācijas datu bāzes izstrāde un uzturēšana”, Xx.Xx. VASES 2018/04, nolikuma (turpmāk – Nolikums) saņemšanas kārtība:
7.1. Pretendenti Nolikumu var saņemt elektroniski VAS ES mājas lapā xxx.xxxxx.xx sadaļā
„Iepirkumi” un e-konkursu apakšsistēmā vietnē: xxxxx://xxx.xxx.xxx.xx/XXXXX/Xxxxxxxx/0, sākot ar dienu, kad paziņojums par līgumu ir publicēts Iepirkumu uzraudzības biroja mājas lapā līdz piedāvājumu iesniegšanas termiņa beigām;
7.2. Ar Nolikumu drukātā veidā var iepazīties VAS ES telpās Xxxx, Xxxxxxxx xxxx 0, 000. kab. pie Pastāvīgās iepirkumu komisijas (turpmāk – Iepirkumu komisija) locekles Vinetas Dambrovskas, sākot ar atklāta konkursa izsludināšanas brīdi, iepriekš piesakoties pa tālruni 28305574 vai pa e-pastu: xxxxxx.xxxxxxxxxx@xxxxx.xx darba dienās no plkst. 9.00 līdz 12.00, sākot ar dienu, kad paziņojums par līgumu ir publicēts Iepirkumu uzraudzības biroja mājas lapā līdz piedāvājumu iesniegšanas termiņa beigām;
7.3. Nolikuma apstiprinātu kopiju drukātā veidā var saņemt VAS ES telpās Xxxx, Xxxxxxxx xxxx 0,
336. kab. pie Iepirkumu komisijas locekles Vinetas Dambrovskas darba dienās (no plkst. 9.00 līdz plkst.12.00), iepriekš piesakoties pa tālruni 28305574 vai pa e-pastu: xxxxxx.xxxxxxxxxx@xxxxx.xx 3 (trīs) darba dienu laikā pēc tam, kad saņemts pieprasījums, ievērojot nosacījumu, ka pieprasījums iesniegts laikus pirms piedāvājuma iesniegšanas termiņa.
8. Ieinteresēto Pretendentu sanāksme:
8.1. Pasūtītājs rīkos ieinteresēto Pretendentu sanāksmi (turpmāk – Sanāksme), ja ne vēlāk kā 10 dienas pirms piedāvājumu atvēršanas dienas tiks saņemti vismaz divi Pretendentu priekšlikumi rīkot Sanāksmi;
8.2. Pasūtītājs Sanāksmi rīkos ne vēlāk kā 5 (piecas) kalendārās dienas pirms piedāvājumu atvēršanas un informāciju par Sanāksmi ievietos pircēja profilā vismaz 3 (trīs) kalendārās dienas iepriekš;
8.3. Pasūtītājs sniegs papildu informāciju un atbildēs uz Sanāksmes laikā uzdotajiem jautājumiem;
8.4. Sanāksmes gaita tiks protokolēta un Pasūtītājs 3 (trīs) darba dienu laikā nosūtīs tās protokola izrakstu visiem Sanāksmes dalībniekiem un vienlaicīgi publicēs šo informāciju arī savā mājas lapā xxx.xxxxx.xx sadaļā „Iepirkumi” un Elektronisko iepirkumu sistēmas e- konkursu apakšsistēmā.
9. Piedāvājumu iesniegšana un noformējuma prasības:
9.1. Piedāvājumi iesniedzami elektroniski Elektronisko iepirkumu sistēmas e-konkursu apakšsistēmā, līdz 2018. gada 10. aprīlim plkst. 11:00 ievērojot šādas Pretendenta izvēles iespējas:
9.1.1.izmantojot e-konkursu apakšsistēmas piedāvātos rīkus, aizpildot minētās sistēmas e- konkursu apakšsistēmā šīs iepirkuma procedūras sadaļā ievietotās formas;
9.1.2.elektroniski aizpildāmos dokumentus elektroniski sagatavojot ārpus Elektronisko iepirkumu sistēmas e-konkursu apakšsistēmas un pievienojot prasībām atbilstošā Elektronisko iepirkumu sistēmas saskarnes laukā (šādā gadījumā Pretendents ir atbildīgs par aizpildāmo formu atbilstību dokumentācijas prasībām un formu paraugiem);
9.1.3.elektroniski sagatavoto piedāvājumu šifrējot ārpus e-konkursu apakšsistēmas ar trešās personas piedāvātiem datu aizsardzības rīkiem un aizsargājot ar elektronisku atslēgu un paroli (šādā gadījumā Pretendents ir atbildīgs par aizpildāmo formu atbilstību dokumentācijas prasībām un formu paraugiem, kā arī dokumenta atvēršanas un nolasīšanas iespējām).
9.2. Ārpus Elektronisko iepirkumu sistēmas e-konkursu apakšsistēmas iesniegtie piedāvājumi tiks atzīti par neatbilstošiem Nolikuma prasībām, netiks izskatīti un tiks atdoti iesniedzējam neatvērti.
9.3. Sagatavojot piedāvājumu, Pretendents ievēro, ka:
9.3.1. Pieteikuma veidlapa un finanšu piedāvājums saskaņā ar Elektronisko iepirkumu sistēmas e-konkursu apakšsistēmā iepirkuma procedūras profilam pievienotajām dokumentu veidnēm jāaizpilda tikai elektroniski, katrs atsevišķā elektroniskā dokumentā ar Microsoft Office 2010 (vai vēlākas programmatūras versijas) rīkiem lasāmā formātā un jāpievieno tam paredzētajā iepirkuma procedūras profila sadaļā. Tehniskais piedāvājums jāsagatavo kā atsevišķs elektronisks dokuments ar Microsoft Office 2010 (vai vēlākas programmatūras versijas) vai Adobe Acrobat Reader rīkiem nolasāmā formātā, nodrošinot teksta meklēšanas un kopēšanas iespējas;
9.3.2. Iesniedzot piedāvājumu, Pretendents to paraksta ar drošu elektronisko parakstu un laika zīmogu vai ar Elektronisko iepirkumu sistēmas piedāvāto elektronisko parakstu. Pretendents pēc saviem ieskatiem dalības pieteikumu, tehnisko piedāvājumu un finanšu piedāvājumu var ar drošu elektronisko parakstu un laika zīmogu parakstīt atsevišķi. Piedāvājumu (tā daļas, ja tās paraksta atsevišķi) paraksta persona, kuras paraksta tiesībām ir jābūt nostiprinātām atbilstoši normatīvajos aktos noteiktajam regulējumam. Ja dokumentāciju paraksta Pretendenta pilnvarota persona, pievienojot attiecīgu paraksta tiesīgās personas izdotu pilnvaru vai normatīvajos aktos noteiktā kārtībā apliecinātu pilnvarojuma kopiju.
9.4. Ja Pretendents piedāvājuma datu aizsardzībai izmantojis piedāvājuma papildu šifrēšanu (saskaņā ar Nolikuma 9.1.3. punktu), Pretendentam ne vēlāk kā 15 (piecpadsmit) minūtes pēc piedāvājumu iesniegšanas termiņa beigām Iepirkumu komisijai jāiesniedz elektroniskā atslēga ar paroli šifrētā dokumenta atvēršanai;
9.5. Piedāvājumā iekļautajiem dokumentiem jābūt skaidri salasāmiem, latviešu valodā. Vārdiem un skaitļiem jābūt bez iestarpinājumiem vai labojumiem. Ja Pretendenta profesionālo darbību vai kvalifikāciju apliecinošie dokumenti ir svešvalodā, tiem jāpievieno paraksttiesīgās personas apstiprināts tulkojums latviešu valodā. Par dokumentu tulkojuma atbilstību oriģinālam un pareizību atbilstoši normatīvo aktu prasībām atbild Pretendents;
9.6. Piedāvājuma dokumentiem ir jābūt noformētiem atbilstoši Ministru kabineta 2010.gada 28.septembra noteikumiem Nr.916 „Dokumentu izstrādāšanas un noformēšanas kārtība”;
9.7. Piedāvājums jāsagatavo tā, lai nekādā veidā netiktu apdraudēta Elektronisko iepirkumu sistēmas e-konkursu apakšsistēmas darbība un nebūtu ierobežota piekļuve piedāvājumā ietvertajai informācijai, kā arī piedāvājums nedrīkst saturēt datorvīrusus un citas kaitīgas programmatūras vai to ģeneratorus. Ja piedāvājums saturēs kādu no šajā punktā minētajiem riskiem, tas netiks izskatīts.
9.8. Iesniedzot piedāvājumu, Pretendents pilnībā akceptē visus Nolikumā ietvertos nosacījumus un Tehniskās specifikācijas prasības;
9.9. Iesniedzot ārvalstīs izdotus publiskos dokumentus (valsts pārvaldes, tiesu, likumdevēja,
u.c. iestāžu izdotus dokumentus), nepieciešama dokumentu īstuma apliecināšana (legalizācija). Lai ārvalstīs izsniegtu dokumentu varētu izmantot Latvijas Republikā:
9.9.1. ja dokuments ir izsniegts valstī, kura ir 1961. gada Hāgas konvencijas „Par ārvalstu publisko dokumentu legalizācijas prasības atcelšanu” dalībvalsts, tā īstumam jābūt minētās konvencijas 3. panta kārtībā apstiprinātam ar „Apostille” dotās ārvalsts kompetentajā institūcijā. Šādi sagatavotu dokumentu vairs nav nepieciešams apstiprināt Latvijas Republikas diplomātiskajā pārstāvniecībā/konsulārajā iestādē;
9.9.2. ja dokuments ir izsniegts valstī, kura nav 1961. gada Hāgas konvencijas „Par ārvalstu publisko dokumentu legalizācijas prasības atcelšanu” dalībvalsts, tas jālegalizē Latvijas Republikas diplomātiskajā pārstāvniecībā/konsulārajā iestādē attiecīgajā ārvalstī, vai vispirms jālegalizē attiecīgās valsts diplomātiskajā pārstāvniecībā/konsulārajā iestādē Latvijā vai tuvākajā ārvalstī un pēc tam Latvijas Republikas Ārlietu ministrijas Konsulārajā departamentā;
9.9.3. dokumentu legalizācija nav nepieciešama, ja publisks dokuments ir izsniegts Eiropas Savienības, Eiropas Ekonomikas zonas valstī vai Šveices Konfederācijā. Ja Pasūtītājam radīsies šaubas par dokumenta autentiskumu, Pasūtītājs rakstveidā sazināsies ar ārvalsts iestādi, kas ir izsniegusi publisko dokumentu vai ir atbildīga par publiskā dokumenta autentiskumu, ja Saeimas apstiprinātajos starptautiskajos līgumos vai Eiropas Savienības tiesību aktos nav noteikts citādi.
10. Izmaiņas piedāvājumā un tā atsaukšanas kārtība
10.1. Pretendents līdz piedāvājumu iesniegšanas termiņa beigām var atsaukt savu piedāvājumu, iesniedzot iepirkuma komisijai paziņojumu. Paziņojumu iesniedz elektroniski Elektronisko iepirkumu sistēmas e-konkursu apakšsistēmā;
10.2. Pretendents līdz piedāvājumu iesniegšanas termiņa beigām var grozīt savu piedāvājumu, augšupielādējot Elektronisko iepirkumu sistēmas e-konkursu apakšsistēmā grozīto piedāvājumu vai tā daļu un parakstot grozījumus ar drošu elektronisko parakstu un laika zīmogu vai ar Elektronisko iepirkumu sistēmas piedāvāto elektronisko parakstu.
11. Piedāvājumu atvēršana:
11.1. Piedāvājumu atvēršana notiek Elektronisko iepirkumu sistēmas e-konkursu apakšsistēmā, Nolikuma 9.1. punktā norādītajā datumā, tūlīt pēc piedāvājuma iesniegšanas termiņa beigām. Piedāvājumu atvēršanas sanāksmes finanšu piedāvājumu kopsavilkums ir pieejams Elektronisko iepirkumu sistēmas e-konkursu apakšsistēmā;
11.2. Piedāvājumu izvērtēšanu Iepirkumu komisija veiks slēgtās sēdēs;
11.3. Pasūtītājs pārceļ vai atceļ piedāvājumu atvēršanas sanāksmi un par to publicē informāciju VAS ES mājas lapā xxx.xxxxx.xx un Elektronisko iepirkumu sistēmas e-konkursu apakšsistēmā, ja Iepirkumu uzraudzības birojā ir iesniegts iesniegums attiecībā uz prasībām, kas iekļautas Nolikumā vai paziņojumā par līgumu, ievērojot Nolikuma 11.4. un
11.5. punktā noteikto;
11.4. Gadījumā, ja Iepirkumu uzraudzības biroja iesniegumu izskatīšanas komisija lemj atstāt spēkā Nolikumā noteiktās prasībās vai arī ja administratīvā lieta tiek izbeigta, Pasūtītājs savā mājas lapā xxx.xxxxx.xx un Elektronisko iepirkumu sistēmas e-konkursu apakšsistēmā publicē informāciju par piedāvājumu atvēršanas sanāksmes vietu un laiku, kā arī informē par to Pretendentus vismaz 3 (trīs) darba dienas iepriekš;
11.5. Gadījumā, ja Iepirkumu uzraudzības biroja iesniegumu izskatīšanas komisija lemj atcelt Nolikumā noteiktās prasības vai arī lemj par pasākumiem konstatēto pārkāpumu novēršanai, Pasūtītājs neatver saņemtos piedāvājumus un izsniedz vai nosūta tos atpakaļ Pretendentiem. Informāciju par piedāvājumu atvēršanas sanāksmes atcelšanu Pasūtītājs publicē savā mājas lapā xxx.xxxxx.xx un Elektronisko iepirkumu sistēmas e-konkursu apakšsistēmā.
12. Piedāvājuma nodrošinājums netiek paredzēts.
13. Saistību izpildes nodrošinājums netiek paredzēts.
14. Cita vispārīgā informācija:
14.1. Piedalīšanās atklātā konkursā ir Pretendenta brīvas gribas izpausme. Iesniedzot savu piedāvājumu dalībai atklātā konkursā, Pretendents visā pilnībā pieņem un ir gatavs pildīt visas Nolikumā ietvertās prasības, normas un noteikumus;
14.2. Pretendentam pilnībā jāsedz piedāvājuma sagatavošanas un iesniegšanas izmaksas. VAS ES neuzņemas nekādas saistības par šīm izmaksām neatkarīgi no atklāta konkursa rezultāta;
14.3. Pretendents iesniedz piedāvājumu par visu iepirkuma priekšmetu kopumā;
14.4. Pretendents nevar iesniegt piedāvājumu variantus;
14.5. Pasūtītājs Elektronisko iepirkumu sistēmas e-konkursu apakšsistēmā reģistrē visus iespējamos Pretendentus, kuri saņem Nolikumu. Iepirkumu komisija nosūtīs Pretendentam papildu informāciju un iespējamās izmaiņas un/vai papildinājumus un skaidrojumus par izmaiņām Nolikumā un vienlaicīgi publicēs šo informāciju arī savā mājas lapā xxx.xxxxx.xx sadaļā „Iepirkumi” un Elektronisko iepirkumu sistēmas e-konkursu apakšsistēmā.
15. Kontaktpersonas - kontaktpersona, kura ir pilnvarota sniegt organizatorisku informāciju par atklātu konkursu – Xxxxxx Xxxxxxxxxx, tālrunis - 28305574, fakss - 67821275, e-pasta adrese: xxxxxx.xxxxxxxxxx@xxxxx.xx.
II Pretendenta atlases dokumenti
16. Nosacījumi Pretendenta dalībai atklātā konkursā:
16.1. Pretendentam (Piegādātāju apvienības vai personālsabiedrības gadījumā – visiem Piegādātāju apvienības dalībniekiem) ir jābūt reģistrētiem kā saimnieciskās darbības veicējiem, atbilstoši savas rezidences valsts normatīvajiem aktiem;
16.2. Pretendents neatbilst Publisko iepirkumu likuma 42. panta pirmās daļas Pretendentu izslēgšanas nosacījumiem. Minētā prasība attiecas arī uz Publisko iepirkumu likuma
42. panta pirmās daļas 9., 10. un 11. punktā minēto/-ajām personu/-ām;
16.3. Attiecībā uz Pretendenta saimnieciskajām un finansiālām spējām, Pretendents var balstīties uz citu personu iespējām pierādot Iepirkumu komisijai, ka tam faktiski būs pieejami šo personu resursi, kuri pašam nav un kas ir nepieciešami iepirkuma līguma izpildei uz visu iepirkuma līguma izpildes laiku, ciktāl tie būs nepieciešami un ka šīs personas būs solidāri atbildīgas par iepirkuma līguma izpildi;
16.4. Attiecībā uz Pretendenta tehniskajām, profesionālajām spējām Pretendents var balstīties uz citu personu iespējām, ja tas ir nepieciešams iepirkuma līguma izpildei, neatkarīgi no savstarpējo attiecību tiesiskā rakstura. Šādā gadījumā Pretendents pierāda Iepirkumu komisijai, ka tam faktiski būs pieejami šo personu resursi, kuri pašam nav un kas ir nepieciešami iepirkuma līguma izpildei uz visu iepirkuma līguma izpildes laiku, ciktāl tie būs nepieciešami, iesniedzot šo personu apliecinājumu vai vienošanos par nepieciešamo resursu nodošanu Pretendenta rīcībā. Pretendents, lai apliecinātu profesionālo pieredzi vai pasūtītāja prasībām atbilstoša personāla pieejamību, var balstīties uz citu personu iespējām tikai tad, ja šīs personas sniegs pakalpojumus, kuru izpildei attiecīgās spējas ir nepieciešamas;
16.5. Ja par atklātā konkursa uzvarētāju tiks atzīta piegādātāju apvienība, tai 10 (desmit) darba dienu laikā pēc attiecīgā Pasūtītāja paziņojuma saņemšanas jāreģistrē personālsabiedrība likumā paredzētajā kārtībā;
16.6. Lai Pretendents iesniegtu piedāvājumu Elektronisko iepirkumu sistēmas e-konkursu apakšsistēmā rīkotā iepirkuma procedūrā, tas reģistrējas Elektronisko iepirkumu sistēmā (reģistrācijas informāciju sk. šeit: xxxxx://xxx.xxx.xxx.xx/XXX/Xxxxxxxxxxxx/XxxxxxxxxxxXxxx.xxxx?XxxxxxxxxxxXxx0&xxxxxxXxx e=CORE) vai piedāvājumu e-konkursu apakšsistēmā iesniedz, izmantojot citu informācijas sistēmu, kas paredzēta elektroniskai piedāvājumu iesniegšanai un kas ir spējīga sadarboties ar e-konkursu apakšsistēmu atbilstoši to normatīvo aktu regulējumam, kas
nosaka elektroniskai pieteikumu un piedāvājumu iesniegšanai izmantojamo informācijas sistēmu tehniskās prasības.
17. Prasības attiecībā uz Pretendenta saimniecisko un finansiālo stāvokli un kvalifikāciju apliecinošie dokumenti:
Nr.p.k. | Noteiktās kvalifikācijas prasības | Kvalifikāciju apliecinoši iesniedzamie dokumenti |
17.1. | Pretendents ir reģistrēts atbilstoši Latvijas Republikas vai ārvalstu normatīvo aktu prasībām. | Pasūtītājs pārbauda Pretendenta atbilstību Nolikuma 17.1. punkta prasībām, iegūstot informāciju Uzņēmumu reģistra datu bāzē. Ārvalstīs reģistrēts Pretendents iesniedz kompetentas attiecīgās valsts institūcijas izsniegtu dokumentu, kas apliecina, ka Pretendents ir reģistrēts atbilstoši attiecīgās valsts normatīvo aktu prasībām. |
17.2. | Pretendenta vidējais finanšu apgrozījums lietojumprogrammatūras izstrādes un ieviešanas jomā iepriekšējos trīs finanšu gados, par kuriem Pretendentam bija jāsniedz gada pārskats (2014., 2015. un 2016.gads), ir vismaz 100 000,00 EUR (viens simts tūkstoši euro un 00 centi) gadā, neieskaitot PVN. Pretendentiem, kuru darbības ilgums ir īsāks par trīs gadiem, finanšu apgrozījums lietojumprogrammatūras izstrādes un ieviešanas jomā vidēji gadā par nostrādāto periodu ir vismaz 100 000,00 EUR (viens simts tūkstoši euro un 00 centi), neieskaitot PVN. Pretendentiem, kuri attiecīgajā tirgū darbojas mazāk kā 1 (vienu) gadu, attiecīgo vidējo apgrozījumu lietojumprogrammatūras izstrādes un ieviešanas jomā nosaka, ievērojot proporcionalitātes principu - aprēķina mēneša vidējo apgrozījumu lietojumprogrammatūras izstrādes un ieviešanas jomā pēc nostrādāto mēnešu skaita, reizina to ar 12 (divpadsmit). | Pretendenta apliecinājums par Pretendenta vidējo finanšu apgrozījumu lietojumprogrammatūras izstrādes un ieviešanas jomā pēdējos trīs gados, par kuriem Pretendentam bija jāiesniedz gada pārskatu (2014., 2015. un 2016.gads). |
17.3. | Pretendenta īstermiņa likviditātes koeficients pēc pēdējā iesniegtā gada (2016.gada vai cita perioda, par kuru Pretendentam bija jāiesniedz gada pārskats) pārskata (vai zvērināta revidenta apstiprinātas operatīvās bilances) datiem ir vismaz 1 (bilances rindas “Apgrozāmie līdzekļi kopā” dalījums ar bilances rindu “Īstermiņa kreditori kopā”). | Pretendenta pēdējās (2016.gada vai cita perioda, par kuru Pretendentam bija jāiesniedz gada pārskats) iesniegtās bilances kopija vai izdruka no Elektroniskās deklarēšanās sistēmas. |
18. Prasības attiecībā uz Pretendenta tehniskajām un profesionālajām spējām un kvalifikāciju apliecinošie dokumenti:
Nr.p.k. | Noteiktās kvalifikācijas prasības | Kvalifikāciju apliecinoši iesniedzamie dokumenti |
8.1. | Pretendentam iepriekšējo 3 (trīs) gadu laikā (no 2015.gada līdz piedāvājuma iesniegšanas dienai) ir pieredze vismaz divu informācijas sistēmu izstrādē, kuru līgumcena nav mazāka par 100`000 (viens simts tūkstoši euro), kur: | Pretendenta realizēto projektu saraksts, ar ko Pretendents apliecina viņa atbilstību Nolikuma 18.1. punkta prasībām saskaņā ar Elektronisko iepirkumu sistēmas e-konkursu apakšsistēmā publicēto formu (Pielikums Nr. 5); Klientu atsauksmes vai citi dokumenti (piemēram, līgumu un darbu nodošanas – pieņemšanas aktu kopijas, finanšu dokumenti), kas apliecina Nolikuma 18.1. punktā norādīto pakalpojumu sniegšanu. |
18.1.1. | Vismaz viena sistēma uztur informāciju par vismaz 2`000`000 (diviem miljoniem) datu objektu; | |
18.1.2. | Vismaz vienai tīmeklī veidotai sistēmai nodalītos apgabalos ir piekļuve vismaz trīs dažādām lietotāju grupām ar tiesībām ievadīt, lasīt un labot informāciju; | |
18.1.3. | Vismaz viena no izstrādātajām sistēmām nodrošina datu apmaiņu vairākos veidos (t.i., vienus un tos pašus datus iespējams ievadīt, izmantojot lietotāja saskarni vai nodot, izmantojot tīmekļa pakalpes); | |
18.1.4. | Vismaz viena no izstrādātajām sistēmām atbilst paaugstinātas drošības sistēmas2 statusam; | |
18.1.5. | Vismaz viena no sistēmām izstrādāta, izmantojot Pretendenta piedāvāto izstrādes ietvaru un datu bāzu tehnoloģiju; | |
18.1.6. | Vismaz vienā sistēmā pieejams elektroniskais pakalpojums, kurš nodrošina vismaz 100 (vienu simtu) pakalpojuma pieprasījumu apstrādi 1 (vienas) minūtes laikā. | |
8.2. | Prasības Pretendenta piedāvātajam | Pakalpojumā iesaistīto speciālistu saraksts |
vadošajam personālam. Pretendents | (Pielikums Nr. 5), kam pievienoti speciālistu | |
nodrošina iepirkuma rezultātā | parakstīti dzīves gājuma apraksti (turpmāk – CV) | |
noslēdzamā līguma izpildei uz visu | atbilstoši ar Elektronisko iepirkumu sistēmas | |
līguma darbības laiku šādus | e-konkursu apakšsistēmā publicēto formu | |
speciālistus Pakalpojuma | Pielikumu Nr. 5 un dokumentu (diplomu, sekmju | |
sniegšanai3: | izrakstu, sertifikātu) kopijas, kas apliecina | |
Pretendenta atbilstību Nolikuma 18.2. punkta prasībām. | ||
18.2.1. | Projekta vadītājs, kuram ir maģistra grāds projektu vadībā vai | |
informācijas tehnoloģijās un pieredze | ||
vismaz divu projektu vadībā, kur |
2 MK 28.07.2015 Noteikumu Nr.442 vai līdzvērtīga ārvalstu normatīvā akta izpratnē. Komersantu informācijas sistēmas uzskatāmas par ekvivalentām, ja to drošības politika atbilst MK noteikumu Nr.442 prasībām.
3 Pieredzes pierādīšanai Pretendenta piedāvātie speciālisti var atsaukties uz projektiem, kuri pabeigti iepriekšējo piecu gadu laikā (no 2015.gada līdz piedāvājuma iesniegšanas dienai). Pieredzes pierādīšanai speciālisti var atsaukties uz projektiem, kuros speciālisti piedalījušies ne mazāk ka 50% no projekta laika.
katra projekta līgumcena nav | ||
mazāka par 100`000 EUR (viens | ||
simts tūkstoši euro); | ||
18.2.2. | Projekta komanda, kura sastāv no | |
vismaz pieciem speciālistiem, kuriem | ||
kopumā ir šādas kompetences: | ||
18.2.2.1. | Vismaz diviem speciālistiem ir | |
piedāvātās datu bāzu vadības | ||
sistēmas ražotāja izsniegts | ||
sertifikāts par apmācību datu bāzu | ||
izstrādē vismaz vidējā līmenī | ||
(piemēram, Microsoft Certified | ||
Professional). Ja ražotāja sertifikācija | ||
piedāvātajai datu bāzei nav | ||
pieejama, jābūt pieredzei vismaz 3 | ||
(trīs) līdzvērtīgu (t.i., atbilstošu | ||
vismaz 2 (diviem) 18.1. punkta | ||
apakšpunktiem) sistēmu izstrādē, | ||
izmantojot piedāvāto datu bāzu | ||
vadības sistēmu; | ||
18.2.2.2. | Vismaz diviem speciālistiem ir jābūt | |
piedāvātās programmēšanas | ||
valodas ražotāja izsniegtam | ||
sertifikātam par apmācību darbam ar | ||
programmēšanas valodu vidējā | ||
līmenī (piemēram, Microsoft Certified | ||
Professional). Ja ražotāja sertifikācija | ||
piedāvātajai programmēšanas | ||
valodai nav pieejama, jābūt pieredzei | ||
vismaz 3 (trīs) līdzvērtīgu (t.i., | ||
atbilstošu vismaz 2 (diviem) | ||
18.1. punkta apakšpunktiem) | ||
sistēmu izstrādē, izmantojot | ||
piedāvāto programmēšanas valodu; | ||
18.2.2.3. | Vismaz vienam speciālistam ir | |
augstākā izglītība ar specializāciju | ||
informācijas sistēmu testēšanā (kur | ||
sistēmu testēšanas disciplīnas | ||
apgūtas vismaz 30 kredītpunktu | ||
apmērā) vai ISTQB vai līdzvērtīgs | ||
sertifikāts; | ||
18.2.2.4. | Vismaz vienam speciālistam ir | |
augstākā izglītība ar specializāciju | ||
informācijas sistēmu drošībā (kur | ||
sistēmu drošības disciplīnas apgūtas | ||
vismaz 30 kredītpunktu apmērā) vai | ||
ISO 27001 auditora vai CISSP vai | ||
CISM sertifikāts; | ||
18.2.2.5. | Visiem speciālistiem ir jābūt | |
pieredzei vismaz divu līdzvērtīgu | ||
sistēmu (t.i., atbilstošu vismaz 2 | ||
(diviem) 18.1. punkta | ||
apakšpunktiem) izstrādē. |
Atklāta konkursa „Numerācijas datu bāzes izstrāde un uzturēšana” nolikums
18.2.3. | Projekta vadītājam un 18.2.2.1. un 18.2.2.5. punktiem atbilstošajiem speciālistiem jāpārvalda latviešu valoda vismaz C14 līmenī, pretējā gadījumā Pretendentam piedāvājumā jāpiedāvā tulks5, kurš atbilst vienai no šādām prasībām: | |
18.2.3.1. | Augstākā izglītība datorzinībās un latviešu valodas zināšanas vismaz C1 līmenī; | |
18.2.3.2. | Augstākā izglītība, latviešu valodas zināšanas vismaz C1 līmenī un pieredze informācijas tehnoloģiju jomas dokumentācijas tulkošanā vismaz divos projektos. | |
18.2.4. | Viens speciālists projektā var piedalīties tikai vienā lomā, izņemot testētāju un drošības speciālistu. |
19. Pretendenta iesniedzamie dokumenti:
19.1. Pretendenta pieteikums par piedalīšanos atklātā konkursā (Pielikums Nr. 1). Elektronisko iepirkumu sistēmas e-konkursu apakšsistēmā publicēto pieteikumu par piedalīšanos atklātā konkursā paraksta Pretendentu pārstāvēt tiesīgā persona (atbilstoši ierakstiem komercreģistrā) vai tā pilnvarotā persona (pievienojot attiecīgu pilnvaru vai apliecinātu pilnvaras kopiju). Ja piedāvājumu iesniedz Piegādātāju apvienība vai personālsabiedrība, tad pieteikumu paraksta visu dalībnieku pārstāvēt tiesīgās personas vai to pilnvarotā/-s persona/-s.
19.2. Pretendenta apliecinājums (iekļauts Pretendenta pieteikumā par piedalīšanos atklātā konkursā Pielikumā Nr. 1), ka uz to neattiecas Publisko iepirkumu likuma 42. panta pirmajā daļā noteiktie Pretendenta izslēgšanas noteikumi;
19.3. Nolikuma 17. un 18. punktā noteiktie kvalifikāciju apliecinošie dokumenti;
19.4. Tehniskais piedāvājums, sagatavots saskaņā ar Nolikuma 24.-25. punktā noteikto
19.5. Finanšu piedāvājums, sagatavots saskaņā ar Nolikuma 26.-29. punktā noteikto.
20. Iesniedzamie dokumenti apakšuzņēmēju piesaistīšanas gadījumā:
20.1. Pretendents piedāvājumā norāda visus paredzamos apakšuzņēmējus un apakšuzņēmēju apakšuzņēmējus un norāda apakšuzņēmējiem izpildei nododamās līguma daļas un to apjomu procentos (%);
20.2. Gadījumā, ja Pretendents balstās uz apakšuzņēmēju iespējām Nolikuma 17.-18. punktā minēto prasību izpildei, Pretendents iesniedz piedāvājumā norādītā/-o apakšuzņēmēja/-u apliecinājumu/-s par gatavību piedalīties atklātā konkursā un veikt noteikto apjomu vai vienošanos par sadarbību konkrēta līguma izpildei un Nolikuma 19.2. punktā minēto dokumentu, kā arī dokumentus, kuri apliecina apakšuzņēmēja/-u atbilstību tām prasībām, kuru izpildei Pretendents balstās uz apakšuzņēmēja/-u iespējām.
21. Iesniedzamie dokumenti gadījumā, ja piedāvājumu iesniedz piegādātāju apvienība:
21.1. Pretendents iesniedz vienošanos par piegādātāju apvienības izveidošanu, kurā norāda personu, kura atklātā konkursā pārstāv attiecīgo grupu, kā arī katras personas atbildības sadalījumu;
4 Saskaņā ar 2009.gada 7.jūlija Ministru kabineta noteikumiem Nr.733 “Noteikumi par valsts valodas zināšanu apjomu un valsts valodas prasmes pārbaudes kārtību profesionālo un amata pienākumu veikšanai, pastāvīgās uzturēšanās atļaujas saņemšanai un Eiropas Kopienas pastāvīgā iedzīvotāja statusa iegūšanai un valsts nodevu par valsts valodas prasmes pārbaudi”
5 Ja nepieciešama tulka iesaiste, tulka dzīvesgājuma apraksts un kvalifikāciju apliecinošo dokumentu kopijas jāiesniedz kopā ar citiem atlases dokumentiem.
21.2. Pretendents iesniedz Nolikuma 19.2. punktā minēto informāciju par katru piegādātāju apvienības biedru vai dalībnieku.
22. Ja Pretendents neatbilst Nolikuma 17.-18. punkta prasībām un/vai nav iesniedzis visus Nolikuma 19. – 21. punktā minētos dokumentus, tad no tālākas līdzdalības atklātā konkursā Pretendents tiek izslēgts.
23. Atklātā konkursa Tehniskā specifikācija pievienota Nolikuma Pielikumā Nr. 2.
24. Tehnisko piedāvājumu Pretendents sagatavo atbilstoši Tehniskajā specifikācijā (Pielikums Nr. 2.) noteiktajām prasībām un saskaņā ar Elektronisko iepirkumu sistēmas e-konkursu apakšsistēmā publicēto Tehniskā piedāvājuma veidlapu (Pielikums Nr. 3).
25. Tehniskajā piedāvājumā Pretendentam jāiekļauj šādi dokumenti:
25.1. Funkcionālo prasību apraksts, par katru prasību norādot:
25.1.1. Realizējamās funkcionalitātes aprakstu;
25.1.2. Informāciju par integrāciju ar ārējiem datu avotiem, norādot saņemamo un nododamo informāciju, integrācijas metodi);
25.1.3. Lietotāja saskarnes elementu skices (ja nepieciešams);
25.1.4. Funkcionālās prasības realizācijas darbietilpības atšifrējums, atbilstoši Finanšu piedāvājuma tabulai “Darbietilpības novērtēšanas metodika”.
25.2. Nefunkcionālo un organizatorisko prasību realizācijas apraksts;
25.3. Sistēmas uzturēšanas piedāvājums;
25.4. Piedāvātās informācijas sistēmas loģiskā arhitektūra un loģisko elementu izvietojums uz serveriem;
25.5. Sistēmas izstrādes un ieviešanas laika grafiks, norādot funkcionalitātes izstrādes sadalījumu pa izstrādes sprintiem, aprakstot savstarpējās atkarības un nosacījumus;
25.6. Sistēmas nodevumu akcepttestēšanas metodika;
25.7. Izmantoto tehnoloģiju uzskaitījumu, tehnoloģiju aprakstu, tajā skaitā licencēšanas noteikumus, informāciju par uzturēšanas un atbalsta pakalpojumu pieejamību.
V Finanšu piedāvājums
26. Finanšu piedāvājumam jābūt izteiktam EUR, norādot summu bez pievienotās vērtības nodokļa (turpmāk – PVN), PVN un kopējo summu ar PVN.
27. Finanšu piedāvājums jāiesniedz saskaņā ar Elektronisko iepirkumu sistēmas e-konkursu apakšsistēmā publicēto Finanšu piedāvājuma veidlapu (Pielikums Nr. 4).
28. Finanšu piedāvājuma cenās jāietver visas ar iepirkuma priekšmetu saistītās izmaksas, visi nodokļi un nodevas, ja tādas paredzētas, kā arī visas izmaksas, kas saistītas ar iespējamajiem riskiem (piem., tirgus cenu svārstības plānotajā Līguma izpildes laikā).
29. Finanšu piedāvājumā norādītās cenas būs spēkā visu iepirkuma līguma izpildes laiku. VI Piedāvājuma vērtēšana un lēmuma pieņemšana
30. Tiks salīdzināti un vērtēti tikai tie piedāvājumi, kuri iesniegti Nolikumā paredzētajā kārtībā un termiņā.
31. Piedāvājumu vērtēšana notiks šādā kārtībā – Iepirkumu komisija:
31.1. vērtēs iesniegto atlases dokumentu atbilstību Nolikuma 19. – 21. punktā minētajām prasībām. Neatbilstošie piedāvājumi no tālākās vērtēšanas tiks izslēgti;
31.2. ja Iepirkumu komisija konstatēs, ka piedāvājumā ietvertā Pretendenta iesniegtā informācija vai dokuments ir neskaidrs vai nepilnīgs, tā pieprasīs, lai Pretendents, vai kompetenta institūcija izskaidro vai papildina minēto informāciju vai dokumentu vai iesniedz trūkstošo dokumentu, nodrošinot vienlīdzīgu attieksmi pret visiem Pretendentiem;
31.3. ja Iepirkumu komisijai radīsies šaubas par iesniegtās dokumenta kopijas autentiskumu, tā pieprasīs, lai Pretendents uzrāda dokumenta oriģinālu;
31.4. vērtēs Pretendentu atbilstību Nolikuma 17. un 18. punktā noteiktajām kvalifikācijas prasībām. Neatbilstošie piedāvājumi no tālākās vērtēšanas tiks izslēgti;
31.5. vērtēs Finanšu piedāvājumu un pārbaudīs, vai tajā nav aritmētiskās kļūdas – ja Iepirkumu komisija Finanšu piedāvājumā atklāj aritmētiskās kļūdas, tā šīs kļūdas labo, par kļūdu labojumu un laboto piedāvājuma summu paziņojot Pretendentam, kura pieļautās kļūdas labotas. Vērtējot finanšu piedāvājumu, aritmētisko kļūdu labojums tiek ņemts vērā.
31.6. ja vērtēšanas procesā Iepirkumu komisijai kāda Pretendenta piedāvājums šķitīs nepamatoti lēts, Iepirkumu komisija rīkosies saskaņā ar Publisko iepirkumu likuma
53. pantā noteikto.
31.7. ja vērtēšanas procesā Iepirkumu komisija konstatēs Pretendenta vai piedāvājuma neatbilstību Nolikuma prasībām jebkurā no vērtēšanas posmiem, Pretendents vai piedāvājums no līdzdalības atklātā konkursā tiks izslēgts.
32. Iepirkumu komisija par uzvarētāju izvēlēsies Pretendentu, kurš iesniedzis Nolikuma prasībām un Tehniskajai specifikācijai atbilstošu saimnieciski visizdevīgāko piedāvājumu, vadoties pēc šādiem kritērijiem:
Nr.x.x. | Xxxxxxxxx | Xxxxxxxxxxx punktu skaits |
1. | Xxxx (EUR bez PVN) par Finanšu piedāvājuma pozīcijā Nr.1 norādītās Sistēmas izstrādes, licenču piegādes un uzturēšanas izmaksas: (Iegūtie punkti = zemākā piedāvātā cena dalīta ar piedāvāto cenu reizināta ar 50 punktiem). Maksimāli iespējamais punktu skaits – 50 | 50 |
2. | Piedāvātā darbu realizācijas efektivitāte Zemākās piedāvātās darbietilpības tabulas kontrolsummas reizinājuma ar Sistēmas uzturēšanas pakalpojumu un izmaiņu pieprasījumu realizācijas stundas likmes dalījums ar Pretendenta piedāvāto darbietilpības tabulas kontrolsummas reizinājumu ar stundas likmi, kura reizināta 10 punktiem. Maksimāli iespējamais punktu skaits – 10 | 10 |
3. | Piedāvājuma risku novērtējums. Piedāvājuma riski tiks noteikti, vērtējot katras funkcionālās prasības realizācijas piedāvājumu. Kā piedāvājuma riski tiks novērtēti šādi apstākļi: • Piedāvātais funkcionalitātes apraksts satur pretrunas ar citiem piedāvājuma punktiem vai neprecizitātes; • Piedāvātās lietotāja saskarnes skices nesatur visu nepieciešamo funkcionalitāti; • Piedāvātās saskarnes apraksts neietver visu nepieciešamo informāciju. Pretendentam, kuram identificēto risku skaits būs viszemākais, tiks piešķirts maksimālais punktu skaits. Pārējiem Pretendentiem punkti tiks piešķirti, dalot viszemāko identificēto risku skaitu ar vērtējamā piedāvājuma risku skaitu un reizinot 30 punktiem. Maksimāli iespējamais punktu skaits – 30 | 30 |
4. | Sistēmas lietotāja saskarnes pieejamībai, izmantojot WEB pārlūkprogrammu: Ja Pretendents piedāvā lietotāja saskarni, kura nodrošinās iespēju izmantot MS Xxxx, Mozilla Firefox un Google Chrome pārlūkprogrammas darbam, sākot ar operētājsistēmu Windows 7, saņemtais piedāvājuma vērtējuma punktu skaits būs 0. Ja Pretendents piedāvās lietotāja saskarni, kura nodrošinās iespēju izmantot MS Edge, Mozilla Firefox, Google Chrome un MS Internet Explorer pārlūkprogrammas darbam, sākot ar operētājsistēmu Windows 7, saņemtais piedāvājuma vērtējuma punktu skaits būs 5. Ja Pretendents piedāvās lietotāja saskarni, kura nodrošinās iespēju izmantot MS Edge, Mozilla Firefox, Google Chrome, MS Internet Explorer un Safari pārlūkprogrammas darbam, sākot ar operētājsistēmu Windows 7, saņemtais piedāvājuma vērtējuma punktu skaits būs 10. Maksimāli iespējamais punktu skaits – 10 | 10 |
KOPĀ: | 100,00 | |
33. Iepirkumu komisija par saimnieciski visizdevīgāko atzīs piedāvājumu, kurš ieguvis visaugstāko vērtējumu saskaņā ar 32. punktā noteiktajiem piedāvājumu vērtēšanas kritērijiem. Ja saimnieciski izdevīgākā piedāvājuma vērtēšanas rezultātā vienādu augstāko punktu skaitu iegūst divi vai vairāki Pretendenti, par atklāta konkursa uzvarētāju noteiks Pretendentu, kurš saņēmis augstāku novērtējumu kritērijā “Piedāvājuma risku novērtējums”.
34. Pirms lēmuma par līguma tiesību piešķiršanu, Iepirkumu komisija veiks pārbaudi vai attiecībā uz Pretendentiem (tai skaitā uz Publisko iepirkumu likuma 42. panta pirmās daļas 9., 10. un
11. punktā minēto/-ajām personu/-ām), kuriem būtu piešķiramas līguma slēgšanas tiesības, neattiecas Publisko iepirkumu likuma 42. panta pirmajā daļā minētie Pretendentu izslēgšanas nosacījumi:
34.1. izmantojot Ministru kabineta noteikto informācijas sistēmu, Ministru kabineta noteiktajā kārtībā, no Iekšlietu ministrijas Informācijas centra (Sodu reģistra) iegūs informāciju vai uz Pretendentu/-iem (tai skaitā Publisko iepirkumu likuma 42. panta pirmās daļas 9., 10. un
11. punktā minēto/-ajām personu/-ām) attiecināmi Publisko iepirkumu likuma 42. panta pirmās daļas 1., 6. un 7. punktā minētie pārkāpumi un noziedzīgie nodarījumi, par kuriem attiecīgā persona ir sodīta vai tai ir piemērots piespiedu ietekmēšanas līdzeklis Latvijā. Pasūtītājs minēto informāciju no Iekšlietu ministrijas Informācijas centra (Sodu reģistra) ir tiesīgs saņemt, neprasot Pretendenta/-u un citu Publisko iepirkumu likuma 42. panta pirmajā daļā minēto personu piekrišanu;
34.2. izmantojot Ministru kabineta noteikto informācijas sistēmu, Ministru kabineta noteiktajā kārtībā, no Uzņēmumu reģistra iegūs informāciju par Publisko iepirkumu likuma 42. panta pirmās daļas 1. punktā minēto personu (personu, kura ir kandidāta vai Pretendenta valdes vai padomes loceklis, pārstāvēt tiesīgā persona, prokūrists, vai personu, kura ir pilnvarota pārstāvēt kandidātu vai Pretendentu darbībās, kas saistītas ar filiāli);
34.3. izmantojot Ministru kabineta noteikto informācijas sistēmu, Ministru kabineta noteiktajā kārtībā, no Uzņēmumu reģistra iegūs informāciju vai uz Pretendentu/-iem (tai skaitā Publisko iepirkumu likuma 42. panta pirmās daļas 9., 10. un 11. punktā minēto/-ajām personu/-ām) attiecināmi Publisko iepirkumu likuma 42. panta pirmās daļas 3. punktā minētie fakti;
34.4. izmantojot Ministru kabineta noteikto informācijas sistēmu, Ministru kabineta noteiktajā kārtībā, no Valsts ieņēmumu dienesta un Latvijas pašvaldībām iegūs informāciju vai uz Pretendentu/-iem (tai skaitā Publisko iepirkumu likuma 42. panta pirmās daļas 9., 10. un
11. punktā minēto/-ajām personu/-ām) attiecināms Publisko iepirkumu likuma 42.panta pirmās daļas 2. punktā minētais fakts (Pretendentam piedāvājumu iesniegšanas termiņa pēdējā dienā vai dienā, kad pieņemts lēmums par iespējamu līguma slēgšanas tiesību piešķiršanu, ir nodokļu parādi Latvijā, tajā skaitā valsts sociālās apdrošināšanas obligāto iemaksu parādi, kas kopsummā pārsniedz EUR 150,00 (viens simts piecdesmit euro, 00 centi)). Pasūtītājs minēto informāciju no Valsts ieņēmumu dienesta publiskās nodokļu parādnieku datubāzes un Nekustamā īpašuma nodokļa administrēšanas sistēmas ir tiesīgs saņemt, neprasot Pretendenta/-u un citu Publisko iepirkumu likuma 42. panta pirmajā daļā minēto personu piekrišanu;
35. Gadījumā, ja tiks konstatēti nodokļu parādi, tajā skaitā valsts sociālās apdrošināšanas obligāto iemaksu parādi, kas kopsummā pārsniedz EUR 150,00 (viens simts piecdesmit euro, 00 centi), Latvijā reģistrētai/-ām personai/ām, Iepirkumu komisija rīkosies saskaņā ar Publisko iepirkumu likuma 42. panta piektajā daļā noteikto;
36. Lai pārbaudītu, vai uz Latvijā reģistrēta Pretendenta valdes vai padomes locekli, pārstāvēt tiesīgo personu vai prokūristu, vai personu, kura ir pilnvarota pārstāvēt Pretendentu darbībās, kas saistītas ar filiāli, un kura ir reģistrēta vai pastāvīgi dzīvo ārvalstī, vai uz ārvalstī reģistrētu vai pastāvīgi dzīvojošu Pretendentu, vai Publisko iepirkumu likuma 42. panta pirmās daļas 9.,
10. un 11. punktā minēto personu, kas reģistrēta vai pastāvīgi dzīvo ārvalstī, nav attiecināmi Publisko iepirkumu likuma 42. panta pirmajā daļā noteiktie izslēgšanas nosacījumi, Iepirkumu komisija pieprasīs, lai Pretendents iesniedz attiecīgās kompetentās institūcijas izziņu, kas apliecina, ka uz Latvijā reģistrēta Pretendenta valdes vai padomes locekli, pārstāvēt tiesīgo personu vai prokūristu, vai personu, kura ir pilnvarota pārstāvēt kandidātu vai Pretendentu darbībās, kas saistītas ar filiāli, un kura ir reģistrēta vai pastāvīgi dzīvo ārvalstī, vai
Pretendentu, vai Publisko iepirkumu likuma 42. panta pirmās daļas 9., 10. un 11. punktā minēto personu neattiecas Publisko iepirkumu likuma 42. panta pirmajā daļā minētie gadījumi. Ja par valdes vai padomes locekli, pārstāvēt tiesīgo personu vai prokūristu, vai personu, kura ir pilnvarota pārstāvēt Pretendentu darbībās, kas saistītas ar filiāli, atbilstoši Pretendenta vai Publisko iepirkumu likuma 42. panta pirmās daļas 9., 10. un 11. punktā minētās personas reģistrācijas valsts normatīvajiem aktiem nevar būt persona, uz kuru ir attiecināmi Publisko iepirkumu likuma 42. panta pirmajā daļā noteiktie izslēgšanas nosacījumi, Pretendents ir tiesīgs izziņas vietā iesniegt attiecīgu skaidrojumu. Termiņu skaidrojuma vai izziņas iesniegšanai Iepirkumu komisija nosaka ne īsāku par 10 (desmit) darba dienām pēc pieprasījuma izsniegšanas vai nosūtīšanas dienas. Ja attiecīgais Pretendents noteiktajā termiņā neiesniedz minēto skaidrojumu vai izziņu, Iepirkumu komisija to izslēdz no dalības atklātā konkursā. Ja Iepirkumu komisija no skaidrojuma negūst pārliecību, ka uz attiecīgajām personām nav attiecināmi Publisko iepirkumu likuma 42. panta pirmajā daļā noteiktie izslēgšanas nosacījumi, tā ir tiesīga pieprasīt iesniegt par attiecīgajām personām kompetento institūciju izziņas.
37. Ja tādi dokumenti, ar kuriem ārvalstī reģistrēts vai pastāvīgi dzīvojošs Pretendents var apliecināt, ka uz to neattiecas Publisko iepirkumu likuma 42. panta pirmajā daļā noteiktie gadījumi, netiek izdoti vai ar šiem dokumentiem nepietiek, lai apliecinātu, ka uz šo Pretendentu neattiecas Publisko iepirkumu likuma 42. panta pirmajā daļā noteiktie gadījumi, minētos dokumentus var aizstāt ar zvērestu vai, ja zvēresta došanu attiecīgās valsts normatīvie akti neparedz, ar paša Pretendenta vai citas Publisko iepirkumu likuma 42. panta pirmajā daļā minētās personas apliecinājumu kompetentai izpildvaras vai tiesu varas iestādei, zvērinātam notāram vai kompetentai attiecīgās nozares organizācijai to reģistrācijas (pastāvīgās dzīvesvietas) valstī.
38. Iepirkumu komisija pieprasīs, lai Pretendents nomaina apakšuzņēmēju, kura sniedzamās piegādes vērtība ir vismaz 10 % (desmit procenti) no kopējās publiska pakalpojuma vai publiska piegādes līguma vērtības, ja tas atbilst Publisko iepirkumu likuma 42. panta pirmās daļas 2., 3., 4., 5., 6. vai 7. punktā minētajam izslēgšanas gadījumam, un personu, uz kuras iespējām Pretendents balstās, lai apliecinātu, ka tā kvalifikācija atbilst Nolikumā noteiktajām prasībām, ja tā atbilst Publisko iepirkumu likuma 42. panta pirmās daļas 1., 2., 3., 4., 5., 6. vai
7. punktā minētajam izslēgšanas gadījumam. Ja Pretendents 10 (desmit) darba dienu laikā pēc pieprasījuma izsniegšanas vai nosūtīšanas dienas neiesniedz dokumentus par jaunu Nolikumā noteiktajām prasībām atbilstošu apakšuzņēmēju vai personu, uz kuras iespējām Pretendents balstās, lai apliecinātu, ka tā kvalifikācija atbilst Nolikumā noteiktajām prasībām, Iepirkumu komisija izslēgs Pretendentu no dalības atklātā konkursā.
39. Ja Pretendentam (tai skaitā Publisko iepirkumu likuma 42. panta pirmās daļas 9., 10. un
11. punktā minēto/-ajām personu/-ām), tiek konstatēts kāds no Publisko iepirkumu likuma
42. panta pirmajā daļā noteiktajiem izslēgšanas nosacījumiem, Iepirkumu komisija izslēdz Pretendentu no dalības atklātā konkursā un izvēlas nākamo Pretendentu, kurš saņēmis nākamo augstāko novērtējumu, uz kuru neattiecas Publisko iepirkumu likuma 42. panta pirmajā daļā noteiktie izslēgšanas nosacījumi.
40. Ja Pasūtītājs jau pēc lēmuma par atklāta konkursa rezultātiem pieņemšanas konstatē, ka uz Pretendentu vai Publisko iepirkumu likuma 42. panta pirmās daļas 9., 10. un 11. punktā minēto/-ajām personu/-ām attiecas kāds no Publisko iepirkumu likuma 42. panta pirmajā daļā minētajiem izslēgšanas nosacījumiem, tad Pasūtītājs nav tiesīgs slēgt iepirkuma līgumu ar konkrēto Pretendentu un pieņem jaunu lēmumu par atklāta konkursa rezultātiem, izvēloties nākamo Pretendentu, kurš saņēmis nākamo augstāko novērtējumu, vai pārtrauc atklātu konkursu Nolikuma 42. punktā noteiktajā kārtībā.
41. Iepirkumu komisija atlasa Pretendentus un vērtē to iesniegtos piedāvājumus saskaņā ar Publisko iepirkumu likumā un Nolikumā noteiktajām prasībām. Iepirkumu komisijas lēmums ir saistošs Pasūtītājam, ja tiek slēgts iepirkuma līgums.
42. Ja tikai viens Pretendents atbilst visām Nolikumā vai paziņojumā par līgumu noteiktajām Pretendentu atlases prasībām, Iepirkumu komisija sagatavo un ietver atklāta konkursa ziņojumā pamatojumu tam, ka izvirzītās Pretendentu atlases prasības ir objektīvas un
samērīgas. Ja Iepirkumu komisija nevar pamatot, ka izvirzītās Pretendentu atlases prasības ir objektīvas un samērīgas, tā pieņem lēmumu pārtraukt atklātu konkursu.
43. Pasūtītājs var jebkurā brīdī pārtraukt atklātu konkursu, ja tam ir objektīvs pamatojums. Iepirkumu komisija nosūta Nolikuma 44. punktā minēto informāciju visiem Pretendentiem un iesniedz publicēšanai paziņojumu par atklāta konkursa rezultātiem, kurā norāda apstākļus, kas bija par pamatu atklāta konkursa pārtraukšanai.
44. Ja atklāts konkurss ir izbeigts vai pārtraukts, Iepirkumu komisija 3 (trīs) darba dienu laikā publicē lēmumu Elektronisko iepirkumu sistēmas e-konkursu apakšsistēmā un vienlaikus informē visus Pretendentus par visiem atklāta konkursa izbeigšanas vai pārtraukšanas iemesliem, un informē par termiņu, kādā Pretendents, ievērojot Publisko iepirkumu likuma
68. panta otrās daļas 1. vai 2. punktā noteikto termiņu, var iesniegt Iepirkumu uzraudzības birojam iesniegumu par iepirkuma procedūras – atklāta konkursa pārkāpumiem.
45. Pasūtītājs informāciju par pieņemto lēmumu attiecībā uz līguma slēgšanu publicē Elektronisko iepirkumu sistēmas e-konkursu apakšsistēmā un nosūta visiem Pretendentiem pa elektronisko pastu, pievienojot elektroniskajam pastam skenētu dokumentu, 3 (trīs) darba dienu laikā pēc lēmumu pieņemšanas;
46. Pasūtītājs sagatavo atklāta konkursa ziņojumu un publicē to pircēja profilā 5 (piecu) darba dienu laikā pēc tam, kad pieņemts lēmums par atklāta konkursa rezultātiem.
VII Līguma slēgšana
47. Pasūtītājs slēgs iepirkuma līgumu ar Iepirkuma uzvarētāju, pamatojoties uz Pretendenta piedāvājumu, saskaņā ar Nolikuma noteikumiem un iepirkuma līguma projektu – (Pielikums Nr. 6).
48. Iepirkuma līgumu slēdz ne agrāk kā nākamajā darba dienā pēc Publisko iepirkumu likuma
60. panta septītajā un astotajā daļā noteiktā nogaidīšanas termiņa beigām – t.i., ne agrāk kā pēc 10 (desmit) kalendārajām dienām pēc dienas, kad informācija par pieņemto lēmumu publicēta Elektronisko iepirkumu sistēmas e-konkursu apakšsistēmā un nosūtīta visiem Pretendentiem pa elektronisko pastu, pievienojot elektroniskajam pastam skenētu dokumentu, un pēc papildu vienas darba dienas termiņa izbeigšanās (ja nogaidīšanas termiņa pēdējā diena ir darba diena, pirms kuras bijusi brīvdiena vai svētku diena, nogaidīšanas termiņš pagarinās par vienu darba dienu).
49. Iepirkuma līgumu Pretendents paraksta un iesniedz Pasūtītajam ne vēlāk kā 3 (trīs) darba dienu laikā no tā brīža, kad Pretendents ir saņēmis Pasūtītāja parakstītu līguma eksemplāru.
50. Ja izraudzītais Pretendents atsakās slēgt iepirkuma līgumu ar Pasūtītāju, Iepirkumu komisija pieņems lēmumu iepirkuma līguma slēgšanas tiesības piešķirt nākamajam Pretendentam, kurš saņēmis nākamo augstāko novērtējumu, vai pārtraukt atklātu konkursu, neizvēloties nevienu piedāvājumu. Ja tiks pieņemts lēmums iepirkuma līguma slēgšanas tiesības piešķirt nākamajam Pretendentam, kura piedāvājums saņēmis nākamo augstāko novērtējumu, bet tas atsakās slēgt iepirkuma līgumu, Iepirkumu komisija pieņems lēmumu pārtraukt atklātu konkursu, neizvēloties nevienu piedāvājumu.
51. Pirms lēmuma pieņemšanas par iepirkuma līguma noslēgšanu ar nākamo Pretendentu, kura piedāvājums saņēmis nākamo augstāko novērtējumu, Iepirkumu komisija izvērtēs, vai tas nav uzskatāms par vienu tirgus dalībnieku kopā ar sākotnēji izraudzīto Pretendentu, kurš atteicās slēgt iepirkuma līgumu ar Pasūtītāju. Ja nepieciešams, Iepirkumu komisija pieprasīs no nākamā Pretendenta apliecinājumu un, ja nepieciešams, pierādījumus, ka tas nav uzskatāms par vienu tirgus dalībnieku kopā ar sākotnēji izraudzīto Pretendentu. Ja nākamais Pretendents būs uzskatāms par vienu tirgus dalībnieku kopā ar sākotnēji izraudzīto Pretendentu, Iepirkumu komisija pieņems lēmumu pārtraukt atklātu konkursu, neizvēloties nevienu piedāvājumu.
52. Līguma slēgšanas procesā ir pieļaujami tikai Publisko iepirkumu likuma 61. pantā noteiktie iepirkuma līguma grozījumi.
VIII Pastāvīgās iepirkumu komisijas tiesības un pienākumi
53. Iepirkumu komisija darbojas, pamatojoties uz Publisko iepirkumu likumu un Nolikumu.
54. Iepirkumu komisijas locekļi ir atbildīgi par Publisko iepirkumu likuma un citu normatīvo aktu pārkāpumiem un valsts interešu neievērošanu.
55. Iepirkumu komisijas tiesības un pienākumi:
55.1. Nodrošināt atklāta konkursa norisi un dokumentēšanu;
55.2. Rīkoties saskaņā ar Nolikumā minēto kārtību un spēkā esošajiem normatīvajiem aktiem;
55.3. Piecu darba dienu laikā sniegt rakstiskas atbildes Pretendentiem uz viņu pieprasījumiem par Nolikumu, bet ne vēlāk kā 6 (sešas) darba dienas pirms piedāvājumu iesniegšanas termiņa beigām, ja tas saņemts ne vēlāk kā 8 (astoņas) darba dienas pirms piedāvājumu iesniegšanas termiņa beigām un tas iesniegts latviešu valodā;
55.5. Rīkot ieinteresēto Pretendentu sanāksmi ne vēlāk kā 5 (piecas) kalendārās dienas pirms piedāvājumu atvēršanas, ja ne vēlāk kā 10 (desmit) kalendārās dienas pirms piedāvājumu atvēršanas dienas ir saņemti vismaz divu ieinteresēto Pretendentu priekšlikumi par ieinteresēto Pretendentu sanāksmes rīkošanu. Informāciju par ieinteresēto Pretendentu sanāksmi Pasūtītājs publicē Elektronisko iepirkumu sistēmas e-konkursu apakšsistēmā un VAS ES mājas lapā xxx.xxxxx.xx vismaz 3 (trīs) kalendārās dienas iepriekš;
55.6. Lemt par Pretendenta izslēgšanu no turpmākas dalības atklātā konkursā, ja iestājas kāds no Publisko iepirkumu likuma 42. pantā noteiktajiem Pretendentu izslēgšanas nosacījumiem;
55.7. Pieprasīt, lai Pretendents izskaidro vai papildina savā piedāvājumā ietverto informāciju, kā arī sniedz precizētu informāciju par piedāvājumu, ja tas nepieciešams piedāvājuma noformējuma pārbaudei un Pretendentu atlasei. Pasūtītājs ir tiesīgs pārbaudīt nepieciešamo informāciju kompetentā institūcijā, publiski pieejamās datu bāzēs vai citos publiski pieejamos informācijas avotos. Ja Pretendents neiesniedz Pasūtītāja pieprasīto informāciju, Pasūtītājam nav pienākums atkārtoti pieprasīt, lai Pretendents izskaidro vai papildina piedāvājumā iekļauto informāciju;
55.8. Pieprasīt, lai Pretendents izskaidro Tehniskajā un/vai Finanšu piedāvājumā iekļauto informāciju, kā arī pieprasīt demonstrēt piedāvājamo risinājuma versiju ja šāda risinājuma versija Pretendentam ir pieejama un tās demonstrēšana nerada nesamērīgus izdevumus;
55.9. Pieaicināt Iepirkumu komisijas darbā speciālistus vai ekspertus ar padomdevēja tiesībām;
55.10. Gadījumā, ja jebkurā vērtēšanas stadijā atklājas, ka Pretendents sniedzis nepatiesu informāciju savas kvalifikācijas novērtēšanai vai vispār nav iesniedzis Nolikumā pieprasīto informāciju, Iepirkumu komisija ir tiesīga izslēgt Pretendenta piedāvājumu no tālākas vērtēšanas;
55.11. Piedāvājumu vērtēšanas gaitā pieprasīt, lai Pretendents iesniedz apliecinājumu tam, ka piedāvājumu izstrādājis neatkarīgi;
55.12. Izdarīt grozījumus Nolikumā saskaņā ar normatīvos aktos noteikto grozījumu izdarīšanas kārtību;
55.13. Labot aritmētiskās kļūdas Pretendentu finanšu piedāvājumos, informējot par to Pretendentu;
55.14. Pieņemt lēmumu par atklāta konkursa rezultātiem;
55.15. Izvēlēties nākamo Pretendentu, kura piedāvājums saņēmis nākamo augstāko novērtējumu vai pārtraukt atklātu konkursu, neizvēloties nevienu piedāvājumu, ja atklāta konkursa uzvarētājs atsakās slēgt iepirkuma līgumu ar Pasūtītāju, ievērojot Nolikuma 50. -
51. punktā noteikto.
IX Pretendentu tiesības un pienākumi
56. Pretendenta tiesības un pienākumi:
56.1. Sekot līdzi Iepirkuma komisijas sniegtajai papildu informācijai, kas tiek publicēta Pasūtītāja pircēja profilā, kur ir publicēts iepirkuma Nolikums un Elektronisko iepirkumu sistēmas e- konkursu apakšsistēmā;
56.2. Atsaukt vai mainīt savu piedāvājumu līdz piedāvājumu iesniegšanas termiņa beigām;
56.3. Pieprasīt rakstiskus skaidrojumus no Pasūtītāja par Nolikumu, nodrošinot, ka Iepirkumu komisija tos saņem ne vēlāk kā 8 (astoņas) darba dienas pirms piedāvājumu iesniegšanas termiņa beigām;
56.4. Iesniegt iesniegumu Iepirkumu uzraudzības birojā par Nolikumu un par Pasūtītāja darbību attiecībā uz Iepirkuma likumību Publisko iepirkumu likumā noteiktajā kārtībā un termiņos;
56.5. Ne vēlāk kā 10 (desmit) kalendārās dienas pirms piedāvājumu atvēršanas dienas iesniegt priekšlikumu Pasūtītājam par ieinteresēto Pretendentu sanāksmes rīkošanu;
56.6. Sagatavot piedāvājumu atbilstoši Nolikuma prasībām;
56.7. Sniegt patiesu informāciju par savu kvalifikāciju un piedāvājumu;
56.8. Sniegt atbildes uz Iepirkumu komisijas pieprasījumiem par papildu informāciju, kas nepieciešama Pretendentu atlasei, piedāvājumu atbilstības pārbaudei, salīdzināšanai un vērtēšanai;
56.9. Segt visas izmaksas, kas saistītas ar piedāvājumu sagatavošanu un iesniegšanu.
57. Iesniedzot savu piedāvājumu, Pretendents apliecina, ka Pretendents akceptē Nolikumā ietvertos noteikumus un nosacījumus.
X Iepirkuma līguma izpildē iesaistītā personāla un apakšuzņēmēju nomaiņa
58. Pretendents nav tiesīgs bez saskaņošanas ar Pasūtītāju veikt iepirkuma līguma izpildē iesaistītā personāla vai apakšuzņēmēju nomaiņu, kā arī papildu apakšuzņēmēju iesaistīšanu līguma izpildē.
59. Pasūtītājs nepiekritīs piedāvājumā norādītā apakšuzņēmēja nomaiņai, ja pastāvēs kāds no šādiem nosacījumiem:
59.1. tiks nomainīts apakšuzņēmējs, uz kura iespējām Pretendents balstījies, lai apliecinātu savas kvalifikācijas atbilstību Nolikumā noteiktajām prasībām, un piedāvātajam apakšuzņēmējam nav vismaz tādas pašas kvalifikācijas, uz kādu Pretendents atsaucies, apliecinot savu atbilstību Nolikumā noteiktajām prasībām, vai uz to attiecas Publisko iepirkumu likuma 42. panta pirmajā daļā minētie Pretendentu izslēgšanas gadījumi;
59.2. uz piedāvāto apakšuzņēmēju, kura veicamās piegādes vērtība ir vismaz 10 % (desmit procenti) no kopējās iepirkuma līguma vērtības, attiecas Publisko iepirkumu likuma
42. panta pirmajā daļā minētie Pretendentu izslēgšanas gadījumi;
59.3. apakšuzņēmēja maiņas rezultātā tiktu izdarīti tādi grozījumi Pretendenta piedāvājumā, kuri, ja sākotnēji būtu tajā iekļauti, ietekmētu piedāvājuma izvēli atbilstoši Nolikumā noteiktajiem piedāvājuma izvērtēšanas kritērijiem.
60. Pasūtītājs nepiekritīs jauna apakšuzņēmēja piesaistei gadījumā, kad šādas izmaiņas, ja tās tiktu veiktas sākotnējā piedāvājumā, būtu ietekmējušas piedāvājuma izvēli atbilstoši Nolikumā noteiktajiem piedāvājuma izvērtēšanas kritērijiem.
61. Xxxxxxxxx jaunā apakšuzņēmēja atbilstību, Pasūtītājs piemēro Publisko iepirkumu likuma
42. panta noteikumus. Publisko iepirkumu likuma 42. panta trešajā daļā minētos termiņus skaita no dienas, kad lūgums par apakšuzņēmēja nomaiņu iesniegts Pasūtītājam.
62. Pasūtītājs pieņem lēmumu atļaut vai atteikt iepirkuma līguma izpildē iesaistītā personāla vai apakšuzņēmēja/-u nomaiņu vai jauna/-u apakšuzņēmēja/-u iesaistīšanu līguma izpildē ne vēlāk kā 5 (piecu) darba dienu laikā pēc tam, kad saņēmis visu informāciju un dokumentus, kuri nepieciešami lēmuma pieņemšanai.
Pielikums Nr. 1 iepirkumam Nr. VASES 2018/04
PIETEIKUMS PAR PIEDALĪŠANOS ATKLĀTĀ KONKURSĀ
(jāsagatavo uz Pretendenta veidlapas)
2018. gada .
Pretendents
Pretendenta nosaukums
nodokļu maksātāja reģ. nr.
tās vadītāja personā,
vadītāja vai pilnvarotās personas vārds, uzvārds
bankas rekvizīti
ar šī pieteikuma iesniegšanu:
- apliecina dalību valsts akciju sabiedrības „Elektroniskie sakari” rīkotajā atklātā konkursā
„Numerācijas datu bāzes izstrāde un uzturēšana”, identifikācijas Nr. VASES 2018/04, iesniedzot piedāvājumu atklātam konkursam;
- apņemas nodrošināt Numerācijas datu bāzes izstrādi un uzturēšanu saskaņā ar Tehniskajā specifikācijā (Pielikums Nr. 2) noteiktajām prasībām;
- apņemas ievērot Nolikumā izvirzītās prasības, kā arī Latvijas Republikā spēkā esošo iepirkuma procesu reglamentējošo normatīvo aktu normas;
- apliecina, ka uz (Pretendenta nosaukums) neattiecas Publisko iepirkumu likuma 42. panta pirmās daļas nosacījumi;
- apliecina, ka (Pretendenta nosaukums) nav veicis profesionālās darbības pārkāpumus pēdējo 3 (trīs) gadu laikā no piedāvājuma iesniegšanas dienas;
- atzīst sava pieteikuma un piedāvājuma spēkā esamību līdz Iepirkumu komisijas lēmuma pieņemšanai, bet gadījumā, ja tiek atzīts par atklāta konkursa uzvarētāju – visā līguma darbības laikā;
- apņemas (ja Pasūtītājs izvēlas šo piedāvājumu) slēgt līgumu un izpildīt visus šī līguma pamatnosacījumus;
- apliecina, ka piedāvājumā iekļautie noteikumi nepasliktina atklāta konkursa nolikumā ietvertās prasības un nenosaka papildu ierobežojumus, un visas piedāvājumā sniegtās ziņas ir patiesas.
Paraksts:
Pretendenta vadītājs vai pilnvarotais pārstāvis
Vārds, uzvārds: Amats: Pretendenta adrese:
Pretendenta tālruņa, faksa numuri:
Kontaktpersona:
Vārds, uzvārds, tālrunis, e-pasts
Z.v.
!Pieteikums ir jāaizpilda drukātā veidā.
*Pieteikums ir jāparaksta Pretendenta likumiskajam pārstāvim vai viņa pilnvarotai personai. Ja Pieteikumu paraksta Pretendenta pilnvarots pārstāvis, Pieteikumam ir jāpievieno atbilstoši noformēts pilnvaras oriģināls vai apliecināta kopija. Ja Pretendents ir piegādātāju apvienība, tad Pieteikumus ir jāparaksta visiem piegādātāju apvienības dalībniekiem.
TEHNISKĀ SPECIFIKĀCIJA
Pielikums Nr. 2 iepirkumam Nr. VASES 2018/04
Atklāts konkurss „Numerācijas datu bāzes izstrāde un uzturēšana”, Xx.Xx. VASES 2018/04 Tehniskā specifikācija
Sistēmas izstrādes pirmajā kārtā realizējamās funkcionālās prasības 22
Publiskajam lietotājam pieejamā funkcionalitāte 33
Sistēmas izstrādes otrajā kārtā realizējamās funkcionālās prasības 33
Trešo pušu programmatūras licences 37
Dokumenta pielietojums
Šis dokuments (Tehniskā specifikācija) ir veidots kā pielikums VAS “Elektroniskie sakari” rīkotā atklātā konkursa „Numerācijas datu bāzes izstrāde un uzturēšana”, identifikācijas Nr. VASES 2018/04, nolikumam. Tehniskās specifikācijas mērķis ir aprakstīt Numerācijas datu bāzes, Numerācijas datu bāzes ieviešanas pieeju un citus ar Numerācijas datu bāzes ieviešanu saistītos nosacījumus.
Atklāta konkursa norises laikā Tehnisko specifikāciju Pretendenti izmantos, lai novērtētu Numerācijas datu bāzes realizācijas darbietilpību un sagatavotu tehnisko piedāvājumu. Savukārt projekta realizācijas laikā Tehnisko specifikāciju izmantos, lai pārbaudītu Numerācijas datu bāzes atbilstību atklāta konkursa nolikuma prasībām.
Sistēmas konteksts
Numerācijas datu bāze paredzēta, lai varētu pārvaldīt numerācijas resursus. Numerācijas lietošanas tiesības piešķir Sabiedrisko pakalpojumu regulators, savukārt informāciju par numerācijas resursu izmantošanu sniedz elektronisko sakaru komersanti. Numerācijas datu bāze nepieciešama, lai VAS “Elektroniskie sakari” varētu pildīt normatīvajos aktos noteiktās funkcijas numerācijas pārvaldībā.
Sistēma paredzēta kā tīmeklī bāzēta sistēma, kuras lietotāji ir VAS ES, Sabiedrisko pakalpojumu regulators, elektronisko sakaru komersanti. Sistēmai jānodrošina publiskojamo datu pieejamība VAS “Elektroniskie sakari” tīmekļa vietnē.
Sistēmai jānodrošina atbilstība šādiem normatīvajiem aktiem:
• Elektronisko sakaru likums;
• Valsts informācijas sistēmu likums;
• Fizisko personu datu aizsardzības likums;
• Ministru kabineta noteikumi Nr.367 “Nacionālais numerācijas plāns”;
• Ministru kabineta noteikumi Nr.45 ” Numerācijas pārvaldīšanas kārtība, izveidojot un uzturot numerācijas datubāzi”;
• Ministru kabineta noteikumi Nr.892 “Noteikumi par numerācijas lietošanas tiesību ikgadējo valsts nodevu”;
• Ministru kabineta noteikumi Nr.374 “Valsts informācijas sistēmu savietotāja noteikumi”;
• Ministru kabineta noteikumi Nr.764 “Valsts informācijas sistēmu vispārējās tehniskās prasības”;
• Ministru kabineta 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”.
• Sabiedrisko pakalpojumu regulēšanas komisijas padomes lēmums Nr.1/18 “Noteikumi par numerācijas lietošanas tiesībām”;
• Sabiedrisko pakalpojumu regulēšanas komisijas padomes lēmums Nr.1/19 “Numura saglabāšanas pakalpojuma nodrošināšanas noteikumi”.
Termini un saīsinājumi
Termins/saīsinājums | Skaidrojums |
SPRK | Sabiedrisko pakalpojumu regulēšanas komisija |
ESK | Elektronisko sakaru komersants |
Izmaiņu pieprasījums | Darbu pasūtījums, kurā realizējamie uzdevumi un sasniedzamie mērķi definēti iepirkuma līguma izpildes procesā un izpaužas kā sistēmas izmaiņas vai papildinājumi. |
Izpildītājs | Pretendents, ar kuru tiks noslēgts iepirkuma līgums |
Pasūtītājs | Valsts akciju sabiedrība "Elektroniskie sakari" |
Problēma | Sistēmas darbības pārtraukums vai neatbilstība funkcionālajām prasībām vai nefunkcionālajām prasībām, sistēmas drošības incidenti, neprecizitātes vai kļūdas sistēmas dokumentācijā. |
Programmatūras versija | Instalējams kārtējais programmatūras variants, kas sastāv no programmatūras pirmkoda, izpildkoda, konfigurācijas skriptiem, versijas piezīmēm, aktualizētas dokumentācijas un testēšanas pārskatiem. |
Sistēmas izstrādes pirmajā kārtā realizējamās funkcionālās prasības
Lietotāju pārvaldība
Indekss | Prasības nosaukums | Prasība |
USR1 | Lietotāju veidi | Sistēmā jānodrošina sekojoši lietotāju veidi: 1. Pasūtītāja administrators, vienlaikus var būt lietotājs (turpmāk – Administrators); 2. Pasūtītāja lietotājs; 3. SPRK lietotājs; 4. ESK lietotājs; 5. Publiskais lietotājs. |
USR2 | Administrators | Administratoram jānodrošina vismaz šādas tiesības: 1. Izveidot ESK kontu; 2. Piešķirt / bloķēt/ atbloķēt/ anulēt SPRK lietotāja tiesības; 3. Piešķirt / bloķēt/ atbloķēt/ anulēt ESK lietotāja tiesības; 4. Piešķirt / bloķēt/ atbloķēt/ anulēt Pasūtītāja lietotāja tiesības; 5. Mainīt sistēmas konfigurējamos parametrus; 6. Apturēt/ palaist Sistēmas procesus; 7. Iniciēt datu arhivēšanu; 8. Atjaunot datus no arhīva; 9. Piekļūt jebkurai sistēmas funkcionalitātei. |
USR3 | Lietotāja tiesību piešķiršana | Sistēmas lietotāju tiesības piešķir Administrators. Lietotāja tiesību piešķiršana veicama, norādot: 1. Juridisko personu, kuras vārdā rīkojas lietotājs; 2. Lietotājvārds; 3. Lietotāja vārds, uzvārds; 4. Lietotāja loma. 5. Identifikācijas veids (lietotājvārds/parole; autentifikācija, izmantojot Active Directory; izmantojot xxx.xxxxxxx.xx vienoto autentifikācijas LDAP (var būt vairāki autentifikācijas varianti); 6. Komunikāciju kanāli (e-pasts/tālrunis); 7. Statuss (ja nav piešķirti numuri, ESK statuss ir neaktīvs); 8. Piekļuves tiesību izveidošanas datums; 9. Piekļuves tiesiskais pamatojums (var būt arī saite uz sistēmā saglabātu elektronisku dokumentu vai saite uz Pasūtītāja lietvedībā saglabātu dokumentu); 10. Atzīmes par lietotāja statusa izmaiņām (bloķēts, bloķēšanas iemesls, atjaunots); 11. Lietotāja tiesību anulēšanas datums un pamatojums; 12. Piezīmes. |
USR4 | Lietotāja piekļuves automātiska bloķēšana | Sistēma automātiski bloķē lietotāja piekļuves tiesības gadījumos, ja: 1. Trīs reizes pēc kārtas ievadīta nepareiza (lietotājvārdam neatbilstoša parole); 2. Konstatēta netipiska datu plūsma, izmantojot lietotāja kontu vai citas pazīmes, kuras satur nesankcionētas piekļuves pazīmes (bloķēšanas nosacījumi identificējami analīzes laikā). Par lietotāja piekļuves bloķēšanu vai lietotājam, kura piekļuves tiesības bloķētas, tiek attēlots brīdinājuma paziņojums. |
USR5 | Lietotāja piekļuves | Administratoram jābūt iespējai bloķēt lietotāja piekļuves |
Indekss | Prasības nosaukums | Prasība |
tiesību manuāla bloķēšana | tiesības: 1. Uz pagaidu prombūtnes laiku; 2. Citos gadījumos, kad Administrators to uzskata par nepieciešamu. | |
USR6 | Manuāla administratora/lietotāja tiesību atbloķēšana | Administrators var manuāli atjaunot lietotāju piekļuves tiesības sistēmai. Par piekļuves atjaunošanas faktu jāveic atzīme lietotāju tiesību pārvaldības modulī. |
USR7 | Lietotāja atbloķēšana kļūdaini ievadītas paroles gadījumā. | Sistēmā jāparedz funkcionalitāte nozaudētas lietotāja paroles atjaunošanai. Pēc lietotāja pieprasījuma uz sistēmā saglabātu lietotāja adresi nosūtāma paroles atjaunošanas informācija, kura ir derīga vienai pieslēgšanās reizei. Pēc pirmās pieslēgšanās lietotāja parole jāatjauno. Parole automātiski var tikt atjaunota ne biežāk, kā vienu reizi gadā (konfigurējams parametrs). Paroles atjaunošanas informācija ir derīga ne vairāk, ka 72 (septiņdesmit divas) stundas. |
USR8 | Lietotāja tiesību anulēšana | Lietotāja tiesību anulēšanu veic Administrators pēc Pasūtītāja, SPRK vai ESK rīkojuma/paziņojuma par darba attiecību izbeigšanu. Lietotāja tiesību anulēšanas gadījumā Sistēma Administratoram attēlo brīdinājuma paziņojumu, ja SPRK vai ESK pēc lietotāja tiesību anulēšanas nav neviena aktuāla lietotāja. Lietotāja tiesību anulēšana ietver lietotāja piekļuves tiesību loģisku dzēšanu, saglabājot auditācijas pierakstus. |
USR9 | Lietotāja meklēšana | Administratoram jābūt iespējai meklēt reģistrētu lietotāju pēc šādiem parametriem: 1. Juridisko personu, kuras vārdā rīkojas lietotājs; 2. Lietotāja vārds, uzvārds; 3. Lietotāja loma; 4. Lietotāja statuss. |
USR10 | Atskaite par lietotāja darbībām | Par katru lietotāju Sistēmai jāattēlo atskaite par Lietotāja Sistēmā veiktajām darbībām. |
USR11 | Lietotāja identifikācija un autentifikācija | Sistēmai jānodrošina šādas lietotāja identifikācijas un autentifikācijas metodes: 1. Lietotājvārds un parole; 2. Autentificēšanās, izmantojot xxx.xxxxxxx.xx vienoto autentifikācijas risinājumu; 3. Autentifikācija ar Pasūtītāja Active Directory (tikai Pasūtītāja lietotājiem). |
USR12 | Prasības parolēm | Paroles uzstādījumiem ir jābūt konfigurējamiem, nodrošinot vismaz šādus konfigurācijas parametrus: 1. Paroles garums; 2. Augšējā reģistra simbolu skaits; 3. Parastā reģistra simbolu skaits; 4. Ciparu skaits; 5. Speciālo simbolu skaits; 6. Paroles derīguma termiņš. |
USR13 | Paroļu aizsardzība | 1. Sistēmā jābūt bloķētai iespējai izmantot pārlūkā saglabātu paroli. 2. Parole publiskajā tīklā, pieslēdzoties sistēmai, jāpārraida šifrētā veidā. |
ESK reģistrs
Indekss | Prasības nosaukums | Prasība |
ESK-1 | ESK reģistrā uzturamā informācija | Sistēmā par katru ESK jāuztur sekojoša informācija: 1. ESK nosaukums; 2. Saimnieciskās darbības veids (SIA; AS ); 3. Uzņēmuma reģistra numurs Komercreģistrā; 4. Adrese / faktiskā adrese (strukturēts lauks, atbilstoši adrešu reģistra formātam); 5. SPRK piešķirtais ESK reģistrācijas numurs; 6. SPRK Reģistrācijas datums; 7. Vispārējās atļaujas statuss (aktīva/anulēta); 8. Kontaktpersona, kontaktinformācija – x.xx. e-pasts ar iespēju automātiski nosūtīt brīdinājumu); 9. Piezīmes; 10. Sistēmas lietotāju saraksts (piekārtojas dinamiski, datus veidojot no reģistrētajiem lietotājiem); 11. Vispārīgās atļaujas veids; ESK reģistrā uzturamo informāciju var ievadīt/mainīt/dzēst SPRK lietotājs vai Administrators |
Numuru reģistrs
Indekss | Prasības nosaukums | Prasība |
NUM1 | Numura veidi | Numerācijas datu bāzes pamatelements ir numurs. Sistēmā jāuztur šādi numuru veidi: 1. Publiskā telefonu tīkla numuri; 2. Īsie kodi; 3. Identifikācijas kodi; |
NUM2 | Publiskā telefonu tīkla numuri | Publiskā telefonu tīkla numuriem jāuztur šāds iedalījums un numerācijas diapazons: 1. Publiskā fiksētā tīkla numuri – numerācijas diapazons tiek piešķirts blokos pa 100 (ja ESK numerācijas lietošanas tiesības pieprasa pirmo reizi) vai blokos pa 1000 numuriem; 2. Publiskā mobilā tīkla numuri – blokos pa 100000 vai 10000 numuriem (izņēmuma gadījumā – pa 1000 numuriem); 3. Pakalpojumu numuri (diapazons no 5; 10; 25; 100; 1000): a. Bezmaksas izsaukuma pakalpojuma numuri (80xxxxxx); b. Dalītās samaksas pakalpojuma numuri (81xxxxxx); c. Papildu samaksas pakalpojuma numuri (90xxxxxx); d. Citu veidu pakalpojumu numuri (78xxxxxx). Numerācijas veidi un to iedalījums var tikt papildināts, atbilstoši numerācijas plāna izmaiņām. |
NUM3 | Īsie kodi | Īsajiem kodiem jāuztur šāds iedalījums: 1. Piekļuves kodi (trīs ciparu formātā 100; 104-109; 190-199; četru ciparu formātā – 1010-1019; 1020-1029; 1030- 1039); 2. Īsie numuri (speciālajiem dienestiem); 3. Īsie numuri, kuri sākas ar 118 (118x vai 118xx) - telefonu uzziņu dienestiem; 4. Īsie numuri, kuri sākas ar 16 (16xx) – operatoru pakalpojumiem tīkla ietvaros; 5. Īsie numuri, kuri sākas ar 82 – 89 (82xx;....) – operatoru pakalpojumiem, tajā skaitā Īsie numuri, kuri sākas ar 88 vai |
Indekss | Prasības nosaukums | Prasība |
89 (88xx; 89xx) – Erotiska, pornogrāfijas vai azartspēļu satura pakalpojumiem; 6. Īsie numuri pakalpojumiem ar sociālo vērtību (116xxx) Īsie numuri tiek piešķirti pa vienam numuram. | ||
NUM4 | Numuru veidu uzturēšana | Numuru veidus, atkarībā no nacionālā numerācijas plāna, uztur Pasūtītājs. Numuru veidiem jābūt konfigurējamiem, uzturot vismaz šādus konfigurācijas parametrus: 1. Numurā ietilpstošo zīmju skaits; 2. Numura sākuma zīmes, ja tas raksturo numura veidu; 3. Numura veida nosaukums; 4. Par numura lietošanas tiesībām veicamais maksājums (par vienu numuru, euro); 5. Tarifikācijas solis (vienreizējs maksājums, diena, mēnesis, ceturksnis, gads). Uzstādot par tarifikācijas soli mēnesi vai gadu katrs iesāktais mēnesis vai gads tiek skaitīts par pilnu periodu . |
NUM5 | Publiskā telefonu tīkla numuru statusi | Atkarībā no izmantošanas, publiskā telefonu tīkla numuram jānodrošina šādi statusi: 1. Izveidots (iekļauts nacionālajā numerācijas plānā); 2. Pieteikts (t.i. rezervēts); 3. Piešķirts; 4. Pagarināts; 5. Anulēts; 6. Tālāk nodots; 7. Piešķirts lietošanā: o Bez termiņa (fiksētā tīkla numuriem un mobilo operatoru pēcapmaksa numuriem); o Sagatavots (mobilā tīkla priekšapmaksas numuriem); o Lietošanā līdz (mobilā tīkla priekšapmaksas numuriem); 8. Nodots ar numura saglabāšanu; 9. Saņemts no cita operatora ar numura saglabāšanu. 10. Atslēgts. |
NUM6 | Publiskā telefonu tīkla numura pieteikšana | Numura pieteikšanu reģistrē SPRK darbinieks. Numurs, kuram piešķirts statuss “Pieteikts” nav pieejams pieteikšanai vai piešķiršanai citiem operatoriem. Statuss automātiski tiek anulēts, ja numurs 60 kalendāro dienu laikā netiek piešķirts operatoram. |
NUM7 | Publiskā telefonu tīkla numura/ numuru bloka piešķiršana | Numura/Numuru bloka piešķiršanu veic SPRK, ar savu lēmumu piešķirot ESK tiesības lietot numuru vai numerācijas bloku. Par lēmumu, ar kuru tiek piešķirts numerācijas bloks vai numurs, Sistēmā jāievada šāda informācija: 1. ESK, kuram piešķirts numurs/numuru bloks (izvēlne no klasifikatora, nodrošinot atlasei vismaz pēc reģistrācijas numura un nosaukuma); 2. Numura veids (izvēle no klasifikatora, lietotājam tiek attēloti pieejamie numuru veidi); 3. Numurs vai numuru bloks. Lietotāja saskarnē sistēma attēlo pieejamos numerācijas blokus un konkrētajam ESK piešķirtos numerācijas blokus. Jāparedz iespējas: a. ievadīt numerācijas diapazona pirmos 4 skaitļus, |
Indekss | Prasības nosaukums | Prasība |
sistēma automātiski attēlo pieejamos numurus, tiek ievadīts piešķiramo numuru skaits; b. ievadīt numerācijas bloka pirmo un pēdējo numuru; c. Izvēlēties numerācijas bloku, kurš seko ESK izmantotajam numerācijas blokam. 4. Datums, ar kuru numurs/numuru bloks piešķirts lietošanā; 5. Piešķirts līdz / bez termiņa (neobligāts lauks). Ievadot piešķiramo numuru vai numerācijas bloku, sistēmai jāveic numuru pieejamības pārbaude (t.i., vai kāds no izvēlētajiem numuriem jau nav piešķirts). Gadījumā, ja kāds no izvēlētajiem numuriem jau ir piešķirts lietošanā, jāattēlo kļūdas paziņojums un jāatgriežas ievadformā, saglabājot ievadītās atbilstošās vērtības. Numerācijas piešķiršanas formā jāparedz iespēja piešķirt vairākus numuru veidus vai vairākus viena veida numerācijas diapazonus. No numerācijas piešķiršanas ekrānformas jābūt saitei uz iespēju izveidot jaunu ESK. Funkcionalitāte pieejama lomai SPRK darbinieks. | ||
NUM8 | Publiskā telefonu tīkla numura/numuru bloka lietošanas tiesību pagarināšana | Numura/Numuru bloka lietošanas tiesību pagarināšanu veic SPRK, ar savu lēmumu pagarinot ESK piešķirtās tiesības lietot numuru vai numerācijas bloku. Par lēmumu, ar kuru tiek pagarinātas numerācijas bloka vai numura lietošanas tiesības, Sistēmā jāievada šāda informācija: 1. ESK, kuram piešķirts numurs/numuru bloks (izvēlne no klasifikatora). Pēc ESK ievades Sistēma attēlo attiecīgajam ESK piešķirtos numurus, kuriem ir noteikts lietošanas termiņš; 2. Numurs vai numuru bloks (iespējams izvēlēties no attiecīgajam ESK piešķirtajiem numuriem, kuriem ir noteikts lietošanas termiņš vai manuāli ievadīt numuru vai numerācijas diapazona pirmo un pēdējo numuru. Ievadformā jāparedz abas formas aizpildīšanas uzsākšanas iespējas, pēc numura vai numerācijas diapazona ievades attēlojot ESK, kuram šis numurs/numerācijas diapazons piešķirts); 3. Piešķirts līdz (obligāti aizpildāms lauks), jānodrošina datu ievades validācija – piešķirtais termiņš nevar būt īsāks, kā esošais termiņš. Jāparedz alternatīva pagarināt numura lietošanas tiesības par noteiktu laika periodu (jādefinē termiņa soļi) vai mainīt numura lietošanas tiesību termiņu uz beztermiņa. Funkcionalitāte pieejama lomai SPRK darbinieks. |
NUM9 | Publiskā telefonu tīkla numura/numuru lietošanas tiesību anulēšana | Numuru/numuru bloka lietošanas tiesību anulēšanu veic SPRK. Par numura/ numerācijas diapazona anulēšanu Sistēmā tie veikts ieraksts: 1. ESK, kuram piešķirts numurs/numuru bloks (izvēlne no klasifikatora). Pēc ESK ievades Sistēma attēlo attiecīgajam ESK piešķirtos numurus; 2. Anulējamais numurs vai numuru bloks (iespējams izvēlēties no attiecīgajam ESK piešķirtajiem numuriem, kuriem ir noteikts lietošanas termiņš vai manuāli ievadīt numuru vai numerācijas diapazona pirmo un pēdējo numuru. |
Atklāta konkursa „Numerācijas datu bāzes izstrāde un uzturēšana” nolikums
Indekss | Prasības nosaukums | Prasība |
Ievadformā jāparedz abas formas aizpildīšanas uzsākšanas iespējas, pēc numura vai numerācijas diapazona ievades attēlojot ESK, kuram šis numurs/numerācijas diapazons piešķirts), jāparedz iespēja anulēt visus piešķirtos numurus; 3. Datums, ar kuru anulētas numerācijas lietošanas tiesības 4. Anulēšanas iemesls (klasifikators no SPRK 1/18 33. Punktā norādītajiem iemesliem); 5. Opcionāla iespēja piešķirt anulēto numerācijas diapazonu citam ESK (pāreja uz numerācijas piešķiršanas formu, piešķiramo numerācijas resursu vietā attēlojot anulētos numurus. Funkcionalitāte pieejama lomai SPRK darbinieks. | ||
NUM10 | Numura tālāknodošana | Numuru/numuru bloka lietošanas tiesību tālāknodošanu veic SPRK. Par numura/ numerācijas bloka tālāknodošanu Sistēmā tie veikts ieraksts: 1. Donors (izvēle no ESK saraksta); 2. Nododamie numuri /numuru bloks (ja izvēlēts ESK, tiek attēloti ESK piešķirtie numerācijas resursi ar iespēju filtrēt numerācijas resursus pēc numerācijas veida). Kā ierosme var būt arī numura / numerācijas diapazona ievade, šādā gadījumā sistēma automātiski attēlo ESK, kura lietošanā ir numuri/numerācijas diapazons; 3. Saņēmējs (izvēle no ESK saraksta); 4. Tālāknodošanas apstiprināšana; 5. Atzīme, ka ESK, kuram nodoti numerācijas resursi, iesniedzis rakstveida apliecinājumu par numerācijas tiesību saņemšanu; 6. (Opcionāli) – atverot ierakstu par numerācijas lietošanas tiesību tālāknodošanu, iespējams numerācijas resursu tālāknodošanu anulēt. Funkcionalitāte pieejama lomai SPRK darbinieks. |
NUM11 | Piešķirts lietošanā | Numura piešķiršanu lietošanā veic ESK. Par numura piešķiršanu lietošanā Sistēmā tiek veikts ieraksts: 1. Numurs; 2. Datums, ar kuru numurs piešķirts lietošanā: o Mobilajiem priekšapmaksas numuriem datums, ar kuru piešķirts lietošanā tiek uzstādīts atbilstoši statusam Sagatavots (mobilā tīkla priekšapmaksas numuriem); o Papildus statuss “Lietošanā līdz” (mobilā tīkla priekšapmaksas numuriem). Funkcionalitāte pieejama lomai “Elektronisko sakaru komersants”. Ierakstu par numura piešķiršanu lietošanā ESK veic vienā no sekojošiem veidiem: a. Nododot Sistēmai informāciju par numura piešķiršanu lietošanā ar tīmekļa pakalpi no savas informācijas sistēmas brīdī, kad ar galalietotāju ir noslēgts līgums par elektronisko sakaru pakalpojumiem.; b. Ievadot Sistēmas lietotāja saskarnē informāciju par numura piešķiršanu lietošanā dienā, kad ar galalietotāju ir noslēgts līgums par elektronisko sakaru pakalpojumiem. Funkcionalitāte pieejama ESK lietotājam. |
Atklāta konkursa „Numerācijas datu bāzes izstrāde un uzturēšana” nolikums
Indekss | Prasības nosaukums | Prasība |
NUM12 | Tīmekļa pakalpe “Piešķirts lietošanā” | Tīmekļa pakalpe tiek ierosināta ESK informācijas sistēmā. Pēc apstiprinājuma saņemšanas no Sistēmas, tiek nodoti prasībā NUM 11 norādītie dati. Transakcija tiek apstiprināta pēc veiksmīgas datu saņemšanas apstiprinājuma saņemšanas. Gadījumā, ja netiek saņemts kāds no apstiprinājumiem, tīmekļa pakalpes izsaukums tiek atkārtots ik pēc 15 minūtēm, līdz veiksmīgas datu saņemšanas apstiprinājuma saņemšanai. Veiksmīga datu saņemšana tiek apstiprināta, izpildoties sekojošiem nosacījumiem: 1. Numurs, kurš piešķirts galalietotājam ietilpst ESK piešķirtajam numerācijas diapazonam; 2. Numurs, kurš piešķirts galalietotājam, nav piešķirts citam galalietotājam; 3. Dati veiksmīgi saglabāti Sistēmā. Neizpildoties kādam no veiksmīgas datu saņemšanas nosacījumiem tiek atgriezts viens no šādiem kļūdas paziņojumiem: 1. Numurs neatbilst ESK piešķirtajam numerācijas diapazonam; 2. Numurs jau ir fiksēts kā piešķirts; 3. Datu saglabāšana nav bijusi veiksmīga. Kļūdas paziņojuma gadījumā (izņemot (3)), elektronisko sakaru operatora sistēmā jāveic datu korekcija un atkārtoti jāizsauc tīmekļa pakalpe. |
NUM13 | Galalietotājam piešķirtā numura ievadīšana lietotāja saskarnē | ESK lietotājam pēc pieslēgšanās sistēmai ir pieejama saskarne lietošanā piešķirto numuru ievadei: 1. Numurs/numerācijas diapazons (ievadforma); 2. Piešķiršanas datums (pēc noklusējuma ievades datums); 3. Iespēja ievadīt jaunu numuru vai apstiprināt ievadīto informāciju. Pēc ievades tiek veikta validācija: 1. Numurs, kurš piešķirts galalietotājam ietilpst ESK piešķirtajam numerācijas diapazonam; 2. Numurs, kurš piešķirts galalietotājam, nav piešķirts citam galalietotājam; 3. Piešķiršanas datums nav lielāks par Sistēmas datumu. Sistēma saglabā ievadītos datus. Neveiksmīgas saglabāšanas gadījumā lietotājam tiek attēlots kļūdas paziņojums. |
NUM14 | Nodots ar numura saglabāšanu | Par numuru, kurš saņemts ar numura saglabāšanu, ESK, kurš saņēmis numuru, sniedz informāciju, norādot: 1. Numurs; 2. ESK, no kura numurs tiek pārņemts; 3. Datums, ar kuru stājas spēkā līgums par elektronisko sakaru pakalpojuma sniegšanu. ESK, kurš nodevis numuru ar numura saglabāšanas pakalpojumu, sniedz informāciju par : 1. Numuru; 2. ESK, kuram numurs nodots; 3. Datums, kad numurs nodots. Numura pārejas faktu Sistēma reģistrē brīdī, kad saņemts paziņojums par nodošanu un pārņemšanu. Gadījumā, ja konfigurējamā periodā informācija par nodoto un pārņemto numuru nesakrīt, Sistēma attēlo administratoram brīdinājuma |
Atklāta konkursa „Numerācijas datu bāzes izstrāde un uzturēšana” nolikums
Indekss | Prasības nosaukums | Prasība |
paziņojumu par informācijas nesakritību. | ||
NUM15 | Atslēgts | ESK, kurš pārtraucis pakalpojuma sniegšanu galalietotājam, ievada sistēmā datus par: 1. Numuru; 2. Atslēgšanas datumu; 3. Piezīmes (neobligāts lauks). Mobilajiem priekšapmaksas numuriem statuss “atslēgts” tiek uzstādīts automātiski, ar brīdi, kad no derīguma termiņa notecējuma pagājuši trīs mēneši. Informāciju par atslēgšanu ESK ievada vienā no šiem veidiem: a) Nododot Sistēmai informāciju par numura atslēgšanu ar tīmekļa pakalpi no savas informācijas sistēmas brīdī, kad pakalpojums galalietotājam ir pārtraukts; b) ievadot Sistēmas lietotāja saskarnē informāciju par numura atslēgšanu. Funkcionalitāte pieejama ESK lietotājam. |
NUM16 | Tīmekļa pakalpe “atslēgts” | Tīmekļa pakalpe tiek ierosināta ESK informācijas sistēmā. Pēc apstiprinājuma saņemšanas no Sistēmas, tiek nodoti prasībā NUM15 norādītie dati. Transakcija tiek apstiprināta pēc veiksmīgas datu saņemšanas apstiprinājuma saņemšanas. Gadījumā, ja netiek saņemts kāds no apstiprinājumiem, tīmekļa pakalpes izsaukums tiek atkārtots ik pēc 15 minūtēm, līdz veiksmīgas datu saņemšanas apstiprinājuma saņemšanai. Veiksmīga datu saņemšana tiek apstiprināta, izpildoties sekojošiem nosacījumiem: 1. Atslēgtais numurs bijis piešķirts ESK vai nodots ar numura saglabāšanas pakalpojumu 2. Atslēgtajam numuram pirms tam bijis statuss “piešķirts lietošanā” 3. Dati veiksmīgi saglabāti Sistēmā. Neizpildoties kādam no veiksmīgas datu saņemšanas nosacījumiem tiek atgriezts viens no šādiem kļūdas paziņojumiem: 1. Numurs neatbilst ESK piešķirtajam numerācijas diapazonam; 2. Numurs nav fiksēts kā piešķirts lietošanā; 3. Datu saglabāšana nav bijusi veiksmīga. Kļūdas paziņojuma gadījumā (izņemot (3)), elektronisko sakaru operatora sistēmā jāveic datu korekcija un atkārtoti jāizsauc tīmekļa pakalpe. Atslēgtais numurs tiek atzīmēts kā neizmantots Ja numurs bijis nodots ar numura saglabāšanas pakalpojumu, numurs tiek atzīmēts kā neizmantots tam ESK, kuram tas sākotnēji piešķirts vai tālāknodots. |
NUM17 | Atslēgtā numura ievadīšana lietotāja saskarnē | ESK lietotājam pēc pieslēgšanās sistēmai ir pieejama saskarne atslēgto numuru ievadei: 1. Numurs (ievadforma); 2. Piešķiršanas datums (pēc noklusējuma ievades datums); 3. Iespēja ievadīt jaunu numuru vai apstiprināt ievadīto informāciju; Pēc ievades tiek veikta validācija: 1. Atslēgtais numurs bijis piešķirts ESK vai nodots ar numura saglabāšanas pakalpojumu; |
Indekss | Prasības nosaukums | Prasība |
2. Atslēgtajam numuram pirms tam bijis statuss “piešķirts lietošanā”; 3. Atslēgšanas datums nav lielāks par Sistēmas datumu. Sistēma saglabā ievadītos datus. Neveiksmīgas saglabāšanas gadījumā lietotājam tiek attēlots kļūdas paziņojums. | ||
NUM18 | Speciāli atslēgšanas gadījumi | SPRK darbiniekam ir tiesības reģistrēt sistēmā ESK vispārējās atļaujas anulēšanas faktu. Vispārējās atļaujas anulēšanas gadījumā tiek atslēgti visi konkrētajam ESK piešķirtie numerācijas resursi. |
Atskaites
Indekss | Prasības nosaukums | Prasība |
REP1 | Darbības ar atskaitēm | Atskaišu funkcionalitātei var piekļūt: 1. SPRK lietotāji – Pasūtītāja definētām atskaitēm par visiem ESK; 2. VASES lietotāji – visām atskaitēm; 3. ESK lietotāji – atskaitēm par ESK piešķirtajiem, lietošanā piešķirtajiem un atslēgtajiem ar numura saglabāšanu numuriem. Atskaitēm jānodrošina vismaz šāda funkcionalitāte: - skatīt uz ekrāna; - izdrukāt; - saglabāt kā *pdf datni; - saglabāt kā *xls/xlsx datni. |
REP2 | Atskaite par publiskā tīkla numuriem | Atskaites sagatavošanu var pieprasīt prasībā REP1 norādītie lietotāji. Pieprasot atskaiti, jāievada datums, uz kuru atskaite sagatavojama. Atskaite tiek attēlota pa numuru veidiem, par katru numuru veidu attēlojot šādu informāciju: 1. ESK piešķirtie numuri; 2. Galalietotājiem piešķirtie numuri; 3. Galalietotājiem lietošanā esošie priekšapmaksas karšu numuri (tikai par publiskā mobilā tīkla numuriem); 4. Lietošanā esošie numuri testēšanai (no 01.01.2019); 5. Lietošanā esošie numuri maršrutēšanai (no 01.01.2019) Lietošanā esošie viesabonēšanas numuri (tikai par publiskā mobilā tīkla numuriem); 6. Atslēgtie numuri, kuru galalietotāji ir izvēlējušies izmantot numura saglabāšanas pakalpojumu; 7. Lietošanā esošie numuri maršrutēšanai, nodrošinot numura saglabāšanas pakalpojumu (tikai publiskā fiksētā tīkla operatoriem; sākot ar 01.01.2019.); 8. Lietošanā esošie numuri testēšanai (sākot ar 01.01.2019.); 9. Atslēgto abonentu/ galalietotāju numuru skaits mēneša pēdējā dienā, kuri ne ilgāk, kā par 3 mēnešiem nav piešķirti citiem lietotājiem; 10. Atslēgto abonentu/ galalietotāju numuru skaits mēneša pēdējā dienā, kuri ilgāk, kā par 3 mēnešiem nav piešķirti citiem lietotājiem; |
Indekss | Prasības nosaukums | Prasība |
11. Neizmantoto abonentu numuru skaits mēneša pēdējā dienā – abonentu numuri, kas sagatavoti izmantošanai abonentu identifikācijas moduļos, bet nav pieslēgti lietošanai (tikai par publiskā mobilā tīkla numuriem). | ||
REP3 | Atskaite par publisko telefonu tīklu operatoru pakalpojumu kodiem | Atskaites sagatavošanu var pieprasīt prasībā REP1 norādītie lietotāji. Pieprasot atskaiti, jāievada datums, uz kuru atskaite sagatavojama. 1. ESK lietošanā esošo publisko telefonu tīklu operatoru pakalpojumu kodu “11X”, “12X”, “13X”, “14X”, “15X” un “17X” (triju ciparu formātā) skaits mēneša pēdējā dienā/lietotāja definētā datumā; 2. ESK lietošanā esošo publisko telefonu tīklu operatoru pakalpojumu kodu “18XX”, “83XX–89XX” (četru ciparu formātā), “82XXX” (piecu ciparu formātā) skaits mēneša pēdējā dienā; 3. ESK lietošanā esošo operatora izvēles kodu “101X”, “102X”, “103X” (četru ciparu formātā) un “10X”, “19X” (triju ciparu formātā) skaits mēneša pēdējā dienā. |
REP4 | Datu iesniegšana | ESK pieejami sekojoši datu iesniegšanas veidi: 1. Sistēmā reģistrēto datu apstiprināšana (pieejama gadījumā, ka ESK nodod Sistēmai datus ar tīmekļa apkalpēm vai regulāri ievada datus lietotāja saskarnē) (prasība realizējama otrajā kārtā, skat. prasību REP8); 2. Datu ievade lietotāja saskarnē. |
REP5 | Atskaites ievade lietotāja saskarnē. | Pēc ESK lietotāja pieprasījuma Sistēma attēlo atskaites formu, atbilstoši ESK nodotajiem numuru veidiem un numerācijas diapazoniem, kā arī sistēmā reģistrētajiem numura saglabāšanas pakalpojumiem. Atskaitē tiek attēlota Sistēmā uzkrātā informācija par iepriekšējo pārskata periodu un ievadlauki aktuālās informācijas ievadei. Ievadlauki aktuālās informācijas ievadei ir obligāti. Veicot atskaites apstiprināšanu, sistēma par katru numerācijas veidu veic datu kvalitātes pārbaudi (atskaitē sniegtajai informācijai jāatbilst ESK nodotajiem numerācijas diapazoniem). ESK lietotājam ir iespējams apstiprināt atskaiti “bez izmaiņām”, šādā gadījumā atskaitē tiek attēloti dati par iepriekšējo pārskata periodu. |
REP6 | Atskaite par ESK | SPRK un VASES lietotājiem ir pieejama pilna atskaites funkcionalitāte. Atskaites pieprasījumā uzstādāmi viens vai vairāki sekojoši iestatījumi: 1. ESK; 2. Numura veids; 3. ESK piešķirtie numuri; 4. Lietošanā piešķirtie numuri; 5. Tālāk nodotie / saņemtie numuri; 6. Pārnestie numuri (izmantojot numura saglabāšanas pakalpojumu) – nodoti citam operatoram; 7. Pārnestie numuri (izmantojot numura saglabāšanas pakalpojumu) – saņemti no cita operatora; 8. Atslēgtie numuri (ne vairāk, kā trīs mēnešus); 9. Atslēgtie numuri (vairāk, kā trīs mēnešus); |
Indekss | Prasības nosaukums | Prasība |
10. Neizmantotie numuri; 11. Laika periods / datums (ar iespēju saņemt atskaiti par vienu dienu); 12. Izvērsta atskaite/savērsta atskaite (attēlo tikai skaitliskos lielumus). Atskaites konfigurē Pasūtītājs. | ||
REP7 | Izvērstā atskaite | Izvērstā atskaitē par ESK nodotajiem numuriem atbilstoši numerācijas veidam vai konkrētam lietotāja ievadītam numuram (numuru diapazonam) tiek attēlots: 1. Numurs; 2. Numura aktuālais statuss; 3. Numura statusa maiņas datums. |
Administratora skats
Indekss | Prasības nosaukums | Prasība |
ADM-1 | Pārskats par apstiprinātajām atskaitēm | Administratora skatā jābūt pieejamai informācijai par atskaišu apstiprināšanu: 1. ESK, kuri apstiprinājuši sistēmas atskaites (par katru ESK attēlojas atskaites apstiprināšanas datums); 2. ESK, kuri nav apstiprinājuši sistēmas atskaites; 3. ESK, kuri nav iesnieguši atskaites (par konfigurējamu periodu). |
ADM-2 | ESK darbību pārskati | Administratora skatā jābūt pieejamai informācijai par: 1. ESK, kuri mēneša laikā nav veikuši datu atjaunošanu (nav izdarīts neviens ieraksts); 2. ESK, kuri izvēlējušies labot sistēmas atskaites, bet nav to izdarījuši (konfigurējamā laikā). |
ADM-3 | Saziņa ar ESK | Administratoram jābūt iespējai nosūtīt vienam vai vairākiem ESK vai SPRK paziņojumus ar brīvi konfigurējamu tekstu. Pie katra ziņojuma jābūt iespējai redzēt ESK, kuri iepazinušies ar ziņojumu (pazīme uzstādās automātiski brīdī, kad ESK lietotājs atvēris ziņojumu). |
ADM-4 | Saņemto ziņojumu apstrāde | Administratora darba virsmā jāattēlojas saņemtajiem ziņojumiem no ESK un SPRK ar iespēju lasīt/atbildēt/pārsūtīt/dzēst. |
ESK lietotāja skats
Indekss | Prasības nosaukums | Prasība |
USR-1 | Lietotāja darbvirsma | Lietotāja darbvirsmai jānodrošina pieeja visām lietotāja lomai atbilstošajām darbībām, kā arī ziņojumu/atgādinājumu sadaļai. |
USR-2 | Ziņojumu / atgādinājumu sadaļa | Sistēmai konfigurējamā laikā jānosūta lietotājiem paziņojumi par veicamajām darbībām un to termiņu, kā arī par nokavētajām darbībām (piemēram, Sistēmas atskaites apstiprināšanu). Sistēmā jāattēlo Sistēmas administratora un SPRK /ESK ziņojumi ar iespēju lasīt/atbildēt/pārsūtīt/dzēst. Sistēmā jānodrošina iespēja nosūtīt ziņojumus: 1. SPRK – vienam vai vairākiem ESK, nodrošinot iespēju monitorēt ziņojuma statusu (skat. ADM-3) un Administratoram; |
Indekss | Prasības nosaukums | Prasība |
2. ESK – SPRK vai administratoram. |
Publiskajam lietotājam pieejamā funkcionalitāte
Indekss | Prasības nosaukums | Prasība |
PUB-1 | Publiskojamie dati | Sistēmai publicēšanai Pasūtītāja tīmekļa vietnē jānodod šāda informācija: 1. Pieteiktie numuri; 2. Piešķirtie numuri; 3. Brīvie diapazoni. |
PUB-2 | Operatora noteikšanas pakalpojums | Sistēmai jānodrošina iespēja lietotāja saskarnē ievadot numuru, saņemt informāciju par operatoru, kurš apkalpo šo numuru, ja numurs nav piešķirts lietošanā – par numura statusu (izveidots/piešķirts operatoram). |
Sistēmas izstrādes otrajā kārtā realizējamās funkcionālās prasības
Indekss | Prasības nosaukums | Prasība |
NUM19 | Atteikšanās no numerācijas resursu izmantošanas | Sistēmā jāparedz iespēja ESK atteikties no neizmantota/ daļēji izmantota numerācijas bloka. Neizmantotā numerācijas bloka daļa šādā gadījumā kļūst pieejama piešķiršanai citiem ESK – uz otro kārtu. |
NUM20 | Numura saglabāšanas pakalpojuma procesa nodrošināšana | ESK, kurš saņēmis galalietotāja pieteikumu par numura saglabāšanas pakalpojumu (saņēmēja tīkla operators), ievada Sistēmā datus: 1. Numurs; 2. ESK, no kura numurs tiek pārņemts; 3. Datums, ar kuru stājas spēkā līgums par elektronisko sakaru pakalpojuma sniegšanu. Sistēma izveido paziņojumu donora tīkla operatoram par saņemto pieteikumu numura saglabāšanas pakalpojumam. Donora tīkla operators var apstiprināt paziņojumu vai atteikt numura saglabāšanas pakalpojumu. Paziņojuma apstiprināšanas gadījumā numurs sistēmā tiek reģistrēts saņēmēja tīkla operatoram, tiek reģistrēts numura nodošanas fakts, numurs tiek piesaistīts saņēmēja tīkla operatoram, nodošanas laiks ir datums, ar kuru stājas spēkā līgums ar saņēmēja tīkla operatoru. Ja numura saglabāšanas pakalpojums tiek atteikts, saņēmēja tīkla operatoram tiek attēlots brīdinājuma paziņojums par numura saglabāšanas pakalpojuma atteikumu. Šādā gadījumā sistēmā numura statuss nemainās, tiek saglabāti audita pieraksti par notikumu. Gadījumā, ja iemesli, kādēļ numura nodošanas pakalpojums tika atteikts, ir novērsti, saņēmēja tīkla operators atkārtoti ievada paziņojumu par numura pārņemšanu (vai atkārtoti iesniedz sistēmā saglabāto paziņojumu, kuram uzstādīts statuss “atteikts”). Gadījumā, ja donora tīkla operators vienas darba dienas laikā nav atbildējis uz pieteikumu, Sistēma ģenerē brīdinājuma paziņojumu Pasūtītāja administratoram. Numuram ir statuss atslēgts ar numura saglabāšanu – tas ir brīdis, ar kuru ESK – saņēmējs var pievienot numuru, pēc atslēgšanas pārvietotais numurs atgriežas pie numerācijas |
lietošanas tiesību saņēmēja. Donoram atskaitē parādās atgrieztais numurs, Sistēmā jānodrošina serviss, kas aizsūta paziņojumu ESK par pieejamu numuru. | ||
NUM21 | Numerācijas bloku optimizācija | Sistēmā jānodrošina iespēja optimizēt numerācijas blokus, kuros ir daži izmantoti numuri, savukārt no pārējo numuru izmantošanas ESK ir atteicies. Optimizācija ietver numerācijas bloka sadalīšanu sīkākos blokos, izolējot tos numerācijas apgabalus, kuri ir piešķirti lietošanā. Gadījumā, ja atsevišķie numuri, kuri bijušie piešķirti lietošanā, tiek atslēgti, Sistēmai jāatjauno pieejams numerācijas bloks. |
REP8 | Sistēmā reģistrēto datu apstiprināšana | Funkcionalitāte pieejama ESK, kuri datus uz Sistēmu nodot, izmantojot tīmekļa pakalpes vai veicot regulāru datu ievadi. ESK lietotājs izsauc mēneša atskaiti, kura tiek veidota no Sistēmā esošajiem datiem. Atskaiti iespējams eksportēt *csv formātā (vai citā formātā, ja par tādu vienojas analīzes gaitā). ESK lietotājs var apstiprināt Sistēmā ievadīto datu pareizību vai izvēlēties precizēt datus, izmantojot lietotāja saskarni. |
REP9 | Datu nodošana VID | Sistēmā jānodrošina funkcionalitāte ESK deklarācijas iesniegšanai VID. Par datu apmaiņas formātu izstrādes laikā jāvienojas ar VID maksājumu administrēšanas sistēmas izstrādātāju. |
REP10 | Kopsavilkuma datu nodošana VID | Sistēmā jānodrošina funkcionalitāte kopsavilkuma datu (t.i., apkopotu datu par visiem ESK) nodošanai VID. Par datu apmaiņas formātu izstrādes laikā jāvienojas ar VID maksājumu administrēšanas sistēmas izstrādātāju. |
REP11 | Biznesa analītikas risinājums | Sistēmā jāiekļauj biznesa analītikas (Business Intelligence) apakšsistēma, kura ļauj lietotājam definēt un iegūt atskaites nepieciešamajos griezumos, atskaites definēšanai izmantojot lietotāja saskarni. |
REP12 | Atskaite par numerācijas izmantošanu | Sistēmai jānodrošina šādu statistikas datu attēlošana par visiem numuriem vai par individuāli izvēlētu ESK, individuāli izvēlēta ESK gadījumā jāattēlo gan ESK, gan vidējais rādītājs: 1. Piešķirto un lietošanai nodoto numuru attiecība; 2. Vidējais laiks no numura piešķiršanas līdz nodošanai abonentam lietošanai; 3. Piešķirtie/tālāknodotie numuri; 4. Piešķirtie/atslēgtie numuri ar numura saglabāšanas pakalpojumu. |
REP13 | Atskaišu datu vizualizācija | Sistēmai jānodrošina atskaišu datu vizualizācija vismaz šādām atskaitēm: • Piešķirtie numerācijas resursi – vienā blokā jāattēlo attiecīgajā numuru veidā piešķirtie numerācijas resursi, vizuāli (ar krāsām) izdalot lielākos ESK (izdalāmo ESK skaits definējams analīzes fāzē), kā arī pārējos ESK (citi ESK), kuriem piešķirti numerācijas resursi. Ja ESK ir iekļauts sadaļā “Citi ESK”, novietojot kursoru uz konkrēto numerācijas bloku, jāattēlo informācija par ESK, kuram piešķirti numerācijas resursi; • Piešķirtie/lietošanā nodotie numerācijas resursi. Vizualizācijai jābūt pieejamai kā par visiem numerācijas resursiem, tā par atsevišķiem ESK piešķirtajiem un lietošanā nodotajiem numerācijas resursiem. |
REP14 | Atskaišu papildināšana ar jaunām sadaļām | Sākot ar 01.01.2020 atskaite par numerācijas izmantošanu jāpapildina ar sekojošām pozīcijām: 1. par bezmaksas izsaukuma pakalpojuma numuriem, kas piešķirti lietotājam attiecīgo pakalpojumu sniegšanai: a. galalietotājiem lietošanā piešķirtie numuri attiecīgo pakalpojumu sniegšanai; b. atslēgtie numuri, kuru galalietotāji ir izvēlējušies izmantot numura saglabāšanas pakalpojumu. 2. par dalītās samaksas pakalpojuma numuriem, kas piešķirti lietotājam attiecīgo pakalpojumu sniegšanai: a. galalietotājiem lietošanā piešķirtie numuri attiecīgo pakalpojumu sniegšanai; b. atslēgtie numuri, kuru galalietotāji ir izvēlējušies izmantot numura saglabāšanas pakalpojumu. 3. par papildus samaksas pakalpojuma numuriem, kas piešķirti lietotājam attiecīgo pakalpojumu sniegšanai: a. galalietotājiem lietošanā piešķirtie numuri attiecīgo pakalpojumu sniegšanai; b. atslēgtie numuri, kuru galalietotāji ir izvēlējušies izmantot numura saglabāšanas pakalpojumu. 4. par citu veidu pakalpojumu numuriem, kas piešķirti lietotājam attiecīgo pakalpojumu sniegšanai: a. galalietotājiem lietošanā piešķirtie numuri attiecīgo pakalpojumu sniegšanai; b. atslēgtie numuri, kuru galalietotāji ir izvēlējušies izmantot numura saglabāšanas pakalpojumu. |
USR-3 | Mobilo iekārtu atbalsts | Sistēmai jānodrošina responsīvs dizains, lai Sistēmu būtu iespējams pilnvērtīgi lietot mobilajās iekārtās (planšetēs/mobilajos telefonos), nodrošinot satura attēlošanu atbilstoši iekārtas ekrāna izmēram. |
USR-4 | Statistikas datu vizualizācijas pieejamība publiskajiem lietotājiem | Jānodrošina, lai statistikas datu vizualizācija (skat. prasību REP13) tiktu attēlota Pasūtītāja tīmekļa vietnē xxx.xxxxx.xx. |
Sistēmas arhitektūra
Indekss | Prasības nosaukums | Prasība |
NFP-1 | Virtualizācijas tehnoloģiju atbalsts | Sistēmai jāatbalsta šāda Pasūtītāja izmantotā virtualizācijas platforma: Microsoft Hyper-V Server 2016. |
NFP-2 | Jauninājumu uzstādīšana | Sistēmai jāparedz iespēja uzstādīt sistēmas jauninājumus, nepārtraucot sistēmas darbību. |
Pieejamības prasības
Indekss | Prasības nosaukums | Prasība |
NFP-3 | Augsta pieejamība | Sistēmai ir jābūt noturīgai pret atsevišķu moduļu kļūmēm. Sistēmai jāsaglabā darbaspēja un jānodrošina transakciju integritāte datubāzes servera, pielietojumu servera jeb pielietojuma programmatūras kļūdas gadījumā. |
NFP-4 | Darbības nepārtrauktība | Sistēmai ir jānodrošina nepārtraukta pieejamība lietotājiem valstī noteiktajās darba dienas, no 8:00 līdz 18:00 (Sistēmas darba laiks). Sistēmas darba laikā jānodrošina pieejamība |
Indekss | Prasības nosaukums | Prasība |
98% (darbspējas laiks). Darbspējas laiks rēķināms gada periodā un tajā ieskaitāmas arī plānotās dīkstāves. Vienas atsevišķas dīkstāves laiks nevar pārsniegt 4 (četras stundas). | ||
NFP-5 | Rezerves kopēšana | Sistēmai jānodrošina iespēja veikt Sistēmas rezerves kopēšanu un konsistentas kopijas iegūšanu bez Sistēmas darba apturēšanas. Ja Sistēmas 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. Sistēmai ir jābūt atjaunojamai no rezerves kopijas ne ilgāk kā četru stundu laikā un dati nedrīkst pazust vairāk kā par vienu pēdējo Sistēmas darbības stundu. Sistēmas 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 Sistēmas Rezerves kopēšanas un darbības atjaunošanas plāns. |
Veiktspējas prasības
Indekss | Prasības nosaukums | Prasība |
NFP-6 | Sistēmas lietotāju skaits | Sistēmai jāspēj apkalpot 100 lietotāji, no kuriem vienlaicīgi Sistēmu lietos līdz 30%. |
NFP-7 | Ekrānformu attēlošanas laiks | Lietotāju datu ievada vai datu pieprasījuma (izziņas) rezultātam, kurš satur līdz 3 dažādiem datu objektiem, uz ekrāna jātiek attēlotam ne ilgāk kā 2 sekunžu laikā no pieprasījuma izdarīšanas brīža (neņemot vērā tīkla pārsūtīšanas aizturi un pieprasījumu izpildes laiku ārējās sistēmās). Papildus datu objektu (vairāk par 3 dažādiem objektiem) attēlošanas gadījumā ekrānformas maksimāli pieļaujamais attēlošanas laiks drīkst tikt palielināts par 0,5 sekundēm, katram papildus attēlojamajam datu objektam. Ekrānformām, kuras nodrošina datu atlasi izmantojot brīva teksta meklēšanu, kas nepieļauj indeksācijas izmantošanu datubāzē, maksimāli pieļaujamais rezultāta attēlošanas laiks ir līdz 15 sekundēm. Prasītais ekrānformu attēlošanas laiks jānodrošina vismaz 90% gadījumu no visiem pieprasījumiem mērījumu veikšanas laika periodā pie prasībā NFP-6 norādītā vienlaicīgo lietotāju skaita un izmantojot reālu datu bāzu aizpildījumu, kas atbilst produkcijas režīmam. |
NFP-8 | Sinhrono web servisu izpildes laiks | Sistēmas sinhrono Web servisu pieprasījumu apstrādes laiks nedrīkst pārsniegt 2 sekundes. |
Infrastruktūras prasības
Indekss | Prasības nosaukums | Prasība |
NFP-9 | Sistēmas vides | Sistēmai ir paredzētas šādas vides: 1. Produkcijas vide. Produkcijas vidi nodrošina Pasūtītājs un tā paredzēta Sistēmas darbināšanai ražošanas režīmā; 2. Testa vide. Testa vidi nodrošina Pasūtītājs un tā paredzēta |
Indekss | Prasības nosaukums | Prasība |
Sistēmas testēšanai no Pasūtītāja puses; 3. Izstrādes vide. Izstrādes vidi nodrošina Izpildītājs un tā ir paredzēta Sistēmas izstrādei un testēšanai. | ||
NFP-10 | Izstrādes vides nodrošināšana | Izpildītājam ir jānodrošina sava vide (aparatūra, programmatūra, biroja telpas) līguma ietvaros izpildāmo darbu un uzdevumu veikšanai. Izpildītājam izstrāde jāveic, izmantojot tikai licencētu programmatūru. Pasūtītājs nenodrošina Izpildītāju ar licencēm. |
NFP-11 | Pieejamie tehniskie resursi | Pasūtītājs Sistēmas darbībai ir paredzējis izmantot 2 virtuālo serverus produkcijas un testa vižu darbināšanai ar šādiem resursiem katrā: 2 vCPU, 16GB RAM, 500GB HDD, Gigabit Ethernet NIC. . Gadījumā, ja šie tehniskie resursi nav pietiekami, lai nodrošinātu veiktspējas un pieejamības prasības, Pretendentam piedāvājumā jānorāda nepieciešamie papildus tehniskie resursi un to cena. |
Trešo pušu programmatūras licences
Indekss | Prasības nosaukums | Prasība |
NFP-12 | Sistēmas licenču piegāde | Izpildītājam Finanšu piedāvājumā jāietver visas piedāvātās Sistēmas 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 Sistēmas izmantošana šajā tehniskajā specifikācijā paredzētajam 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 (5 gadus pēc Sistēmas pirmās versijas nodošanas ekspluatācijā). Atsevišķi ir jānorāda licenču izmaksas un noteikumi Sistēmas Produkcijas (ekspluatācijas) vides un Testa vides izveidošanai un uzturēšanai. |
NFP-13 | Prasības trešo pušu programmatūrai | Trešo pušu standarta programmatūras komponentēm jābūt ar ražotāja apliecinātu uzturēšanas termiņu vismaz 5 (pieci) gadi, skaitot no paredzētās Sistēmas nodošanas ekspluatācijā dienas. Ja programmatūras licenču uzturēšana ir saistīta ar regulāra uzturēšanas/atbalsta maksājuma veikšanu, šādi maksājumi jāiekļauj finanšu piedāvājumā. Visai piedāvātajai atvērtā pirmkoda programmatūrai ir jābūt aktuālai (t.i, pēdējai versijai) un stabilai (t.i. pielietotai un attīstītai vismaz 3 (trīs) gadu laikā no piedāvājuma iesniegšanas dienas, pie tam pēdējā atvērtā pirmkoda programmatūras versija nedrīkst būt vecāka par 6 (sešiem) mēnešiem. |
.
Prasības drošībai
Indekss | Prasības nosaukums | Prasība |
NFP-14 | Autentifikācija, autorizācija un auditācija | Sistēmai jābūt veidotai tā, lai nevarētu apiet autentifikācijas un autorizācijas procedūras un nesankcionēti lietot Sistēmas funkcionalitāti vai piekļūt Sistēmas datiem. Sistēmai jāapkalpo tikai identificētus, autentificētus un autorizētus lietotājus. Sistēmas identifikācijas, autentifikācijas, autorizācijas un |
Indekss | Prasības nosaukums | Prasība |
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. Jānodrošina aizsardzība pret lietotāju esamības pārbaudi (Sistēma nedrīkst atklāt vai lietotājs eksistē vai nē pirms sekmīgas autentifikācijas); 4. Jebkurš nesekmīgs autorizācijas vai autentifikācijas mēģinājums jāreģistrē sistēmas žurnālā saskaņā ar Tehniskās specifikācijas prasību NFP-23; 5. Sistēmā 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); 6. Sistēmas ietvaros ir jābūt izveidotam tehniskajam risinājumam, kas veic neaktīvo sesiju automātisku pārtraukšanu pēc „n” minūtēm (kur „n” ir konfigurējams parametrs, pieņemot, ka noklusētā vērtība ir 15 minūtes); 7. Sistēmai ir jāietver paziņojumu sniegšanas mehānisms, kas informē lietotāju par tā darba sesijas neaktivitāti un sesijas pārtraukšanu “n” minūtes pirms sesijas noilguma iestāšanās (kur „n” ir konfigurējams parametrs, pieņemot, ka noklusētā vērtība ir 2 minūtes); 8. Sistēmā ir jābūt ietvertai kontrolei, kas liedz atkārtoti izmantot jau aktīvu izveidotu sesijas identifikatoru jaunas sesijas izveides nodrošināšanai; 9. Administratoru pieeja sistēmai jāspēj ierobežot ar vienu vai vairākiem Internet Protokola adrešu apgabaliem. Ar Internet Protokola adrešu apgabalu šeit tiek saprasts IPV4 vai IPV6 adrešu intervāls. | ||
NFP-15 | Programmatūras drošība | Veicot Sistēmas izstrādi vai pielāgošanu jāievēro šādas prasības: 1. Sistēmas izstrādē jāievēro OWASP ieteiktie sistēmu izstrādes principi: xxxx://xxx.xxxxx.xxx/xxxxx.xxx/Xxxxxxxx:Xxxxxxxxx. 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 datu bāzes aizsardzības uzlaušanu; 2. WEB pielietojumi izstrādājami saskaņā ar OWASP drošas programmēšanas vadlīnijām: xxxxx://xxx.xxxxx.xxx/xxxxx.xxx/XXXXX_Xxxxxx_Xxxxxx _Practices_-_Quick_Reference_Guide; 3. WEB pielietojumiem sesiju pārvaldība jāorganizē pēc OWASP ieteiktajiem principiem: xxxx://xxx.xxxxx.xxx/xxxxx.xxx/Xxxxxxx_Xxxxxxxxxx; 4. WEB pielietojumiem jāņem vērā OWASP ieteikumi AJAX tehnoloģiju izmantošanai (xxxx://xxx.xxxxx.xxx/xxxxx.xxx/Xxxx_xxx_Xxxxx_%00Xxx h%22_Interface_Technologies). Jāpielieto ražotāju un nozares ekspertu ieteiktās labās prakses drošu informācijas sistēmu izstrādē; |
Indekss | Prasības nosaukums | Prasība |
5. Sistēmas 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 ražošanas sistēmās; 6. Sistēmas izstrādē nedrīkst izmantot komponentes, kurām ražotājs nepiegādā vai tuvāko 5 gadu laikā no izstrādes uzsākšanas brīža plāno pārtraukt izstrādi un/vai piegādāt drošības labojumus. Pēc Sistēmas izstrādes noslēgšanas Sistēmas izstrādātājam ir jāveic neatkarīgs Sistēmas drošības audits, kura ietvaros tā piesaistītai trešajai pusei ir jāveic Sistēmas drošības atbilstības pārbaude attiecībā uz iepriekš minēto prasību ievērošanu, par to sagatavojot un Pasūtītājam iesniedzot ziņojumu kā vienu no Sistēmas piegādes dokumentācijas nodevumiem. Gadījumā, ja pārbaudes laikā tiek atklātas kādas drošības nepilnības, tās Sistēmas izstrādātājam ir jānovērš pirms Sistēmas ieviešanas produktīvajā lietošanā. | ||
NFP-16 | Informācijas drošība | Sistēmai jāizveido pietiekami kontroles mehānismi, lai nodrošinātu, ka Sistēmas dati gan to pārraides, gan glabāšanas laikā netiek atklāti personām vai programmām, kurām nav attiecīgas autorizācijas. Piekļuve Sistēmas datiem nodrošināma ievērojot šādus principus: 1. „Zina tikai tas, kuram jāzina” (need-to-know); 2. „Ir jānodrošina minimālās tiesības pienākumu pildīšanai”, gan lietotājiem, gan tehnoloģiskajiem lietotājiem (least privilege); 3. Jānodrošina lietotāju darbību reģistrācija un šo datu saglabāšana (accountability). Sistēmai jānodrošina, ka programmatūra, nesniedz lietotājam informāciju, kas varētu apdraudēt Sistēmas drošību, tai skaitā, nepieļaujot iespēju lietotājam veikt analīzi par kļūdas un veikto Sistēmas pārbaužu raksturu, kas varētu atvieglot tālākos uzbrukumus Sistēmai. Kļūdas situācijās lietotājam jāparāda tikai minimālā nepieciešamā informācija, bet detalizēts kļūdas tehniskais apraksts jāsaglabā Sistēmas notikumu audita žurnālā saskaņā ar prasību NFP-23. Sistēmas saskarnēm jābūt izveidotām tā, lai nevarētu apiet autentifikācijas un autorizācijas procedūras un nesankcionēti lietot Sistēmas informāciju vai datnes. |
NFP-17 | Lietotāja identifikācijas datu drošība | Sistēmai jānodrošina lietotāju identifikācijas datu aizsardzība. Aizliegts uzglabāt lietotāja identitātes un citus to raksturojošus sensitīvus datus (paroles, pieejas kodus, šifrēšanas atslēgas u.c.) atklātā tekstā datu bāzē vai interneta pārlūkprogrammā, piemēram, kešatmiņā. |
NFP-18 | Datu apstrādes un pārraides drošība | Izpildītājam jānodrošina, ka Sistēmas datu apmaiņas, kā arī citi iespējamie automatizētie datu apstrādes procesi tiek pildīti tikai ar tehnoloģisko lietotāju kontiem, kuriem funkcijas veikšanai ir noteiktas mazākās nepieciešamās tiesības. Tehnoloģiskie lietotāji un to tiesības jādokumentē programmatūras projektējuma aprakstā. 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: 1. Sistēmām, apmainoties ar datiem (informācijas pieprasījumi |
Indekss | Prasības nosaukums | Prasība |
un atbildes starp web servisiem xml formātā), ir jāizmanto par drošām vispāratzītas datu šifrēšanas tehnoloģijas; 2. Ja nav iespējams informācijas pieprasījumu un atbilžu šifrēšana, ir jānodrošina šifrēts datu pārraides kanāls, izmantojot VPN tehnoloģijas. Arī datu apmaiņai starp tīmekļa serveri un klienta pārlūku jābūt šifrētai. | ||
NFP-19 | Sistēmas atbilstība drošību reglamentējošiem normatīvajiem aktiem | Sistēmai jāizpilda šādas drošības standartu un normatīvo aktu prasības: 1. Jānodrošina LVS ISO/IEC 15408 standartā “Informācijas tehnoloģija – Drošības tehnikas – IT drošības novērtējuma kritēriji” 2.daļā “Drošības funkcionālās komponentes” (Information technology — Security techniques — Evaluation criteria for IT security — Part 2: Security functional components. ISO/IEC 15408-2. Third edition 2008-08-15) iekļauto rekomendāciju un vadlīniju ievērošanu, Līguma ietvaros formulējot un realizējot konkrētām sistēmām izvirzāmās drošības prasības; 2. 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; 3. 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; 4. 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. Citos uz informācijas sistēmu drošību attiecināmos normatīvajos aktos iekļautās prasības, kas tiek pieņemtas un stājas spēkā Sistēmas izstrādes laikā. |
NFP-20 | Pasākumi pret darbības noliegšanu (non- repudiation) | Sistēmas kontroles mehānismi veidojami tā, lai nodrošinātu, ka persona, kas veikusi kādas darbības, nevar noliegt šādu darbību veikšanas faktu. Sistēmai jāļauj pamanīt gadījumus, kad informācija tikusi modificēta to pārraides vai glabāšanas laikā. |
Auditācijas prasības
Indekss | Prasības nosaukums | Prasība |
NFP-21 | Lietotāju darbību auditācija | Sistēmai ir jāauditē vismaz šādas lietotāju veiktās darbības: 1. Lietotāja pieslēgšanos (veiksmīgu, neveiksmīgu) sistēmai un atslēgšanos no sistēmas; 2. Lietotāju izsauktos pārskatus un aktivizētos asinhronos uzdevumus (batch job); 3. Datu pievienošanu, labošanu un dzēšanu; 4. Datu apskati. Datu apskate auditējama tikai daļai no Sistēmas datiem. Kuriem datiem apskate auditējama ir jānosaka un ar Pasūtītāju jāsaskaņo prasību analīzes un sistēmas projektēšanas aktivitātes ietvaros. Par katru no lietotāja veiktajām darbībām jāuzglabā vismaz |
Indekss | Prasības nosaukums | Prasība |
šāda informācija: 1. Darbības datums un laiks; 2. Lietotāja identitāte; 3. Darbības veids (pieslēgšanas sistēmai, atslēgšanās no sistēmas, ieraksta pievienošana, ieraksta labošana, utt.); 4. Darbības veidam specifisko informāciju: a. Pieslēgšanās un atslēgšanās no Sistēmas darbībām darbstacijas identifikators (nosaukums un IP adrese); b. Lietotāja sesijas identifikators vai cits identifikators pēc kura iespējams unikāli identificēt konkrētu lietotāja sesiju; c. Datu apskates/pievienošanas/rediģēšanas/dzēšanas darbībām saistītā datu objekta identifikators. Ja izveidotos lietotāju darbību auditācijas pierakstus nevar vienkārši analizēt, izmantojot tradicionālos līdzekļus, jānodrošina speciāli analīzes rīki. | ||
NFP-22 | Lietotāja tiesību izmaiņu auditācija | Sistēmā jāuzglabā un jāvar apskatīt informācija par visām lietotāju tiesību izmaiņām. Par katru izmaiņu jābūt apskatāmai vismaz šādai informācijai: 1. lietotāja vārds; 2. Administratora, kurš veicis izmaiņas, identitāte; 3. izmaiņu datums un laiks; 4. izmaiņu veids (pievienošana, rediģēšanas, dzēšana); 5. izmainītās un jaunās vērtības. |
NFP-23 | Sistēmas notikumu auditācija | Sistēmai jānodrošina programmatūras kļūdu un izņēmumu situāciju (exceptions) auditācija. Programmatūras kļūdas un izņēmuma situācijas auditējamas vismaz šādos līmeņos: 1. Lietotāju saskarnes līmenī; 2. Biznesa procesu līmenī; 3. Tīmekļa servera līmenī; 4. Datu bāzu līmenī. Par katru no programmatūras kļūdām un izņēmumu situācijām saglabājama visa pieejamā ar kļūdu saistītā informācija. Sistēmai jānodrošina iespēja nosūtīt ziņojumu par kļūdām un izņēmuma situācijām sistēmas administratoram. |
NFP-24 | Datu izmaiņu vēsture | Sistēmā ir jāuztur pilna datu izmaiņu vēsture, ja Pasūtītājs nav norādījis citādi.. Respektīvi, 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 Sistēmas fona uzdevums); 2. Katru izmaiņu datums un laiks; 3. Ieraksta satura kopija pievienošanas/labošanas/dzēšanas brīdī. |
NFP-25 | Auditācijas pierakstu dzēš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 36 mēneši), pēc tam tos automātiski arhivējot un dzēšot. 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. |
Uzturamības prasības
Indekss | Prasības nosaukums | Prasība |
NFP-26 | Programmatūras pārnesamība | Ja Sistēma tiek veidota papildinot standartprodukta funkcionalitāti, papildinājumiem jābūt tā veidotiem, lai būtu iespējams bez Sistēmas izmaiņām Sistēmu pārnest uz jaunāku standartprodukta versiju. |
NFP-27 | Koda vadības sistēma | Sistēmas izstrādes gaitā Izpildītājam jāizmanto datorizēta koda bibliotēka, kurai jānodrošina Pasūtītājam pieeja lasīšanas režīmā. |
Lietojamības prasības
Indekss | Prasības nosaukums | Prasība |
NFP-28 | WEB lietotāja saskarne | Sistēmas lietotāja saskarnei jābūt pieejamai, izmantojot WEB pārlūkprogrammu. Saskarnei jānodrošina iespēja izmantot vismaz šādas populāras pārlūkprogrammas darbam, sākot ar oprētējsistēmu Windows 7: 1. MS Edge; 2. Mozilla Firefox; 3. Google Chrome. Piedāvājumi, kuri piedāvās piekļuvi lietotāja saskarnei no MS Internet Explorer un/vai Safari pārlūkprogrammām, saņems papildus punktus. |
NFP-29 | WEB lietotāja saskarnes atjauninājumi | Ne vēlāk, kā 30 (trīsdesmit) dienu laikā, skaitot no jaunas prasībā NFP-28 norādītās pārlūkprogrammas jaunas versijas izlaišanas Izpildītājam jāpiegādā Sistēmas atjauninājumi, lai nodrošinātu sadarbspēju ar jaunāko pārlūkprogrammas versiju. |
NFP-30 | Atbalstāmās lietotāju operētājsistēmas | Informācijas sistēmai ir jānodrošina lietotāju darbs vismaz Windows saimes (Windows 7, Windows 8, Windows 10) un Linux saimes operāciju sistēmās. |
NFP-31 | Lietotāju saskarnes valoda | Sistēmas lietotāju saskarnei jābūt pieejamai latviešu valodā. Saskarnē izmantotajai valodai (vārdiem, frāzēm) jābūt intuitīvi saprotamai lietotājiem. Sistēmas administratoru saskarni var veidot latviešu vai angļu valodā, ja tas neapgrūtina Sistēmas lietošanu. |
NFP-32 | Lietotāju saskarnes uztveramība | Sistēmai ir jāatbilst šādiem lietojamības kritērijiem: 1. Sistēmai ir jābūt saprotamai. Visiem lietotāja interfeisa elementiem (navigācijas elementiem, ikonām, spiedpogām, utt.) jābūt viegli uztveramiem un veidotiem atbilstoši industrijas labajai praksei. Sistēmā jāizmanto termini, kas sakrīt ar Pasūtītāja ikdienas darbā izmantojamajiem terminiem. Retāk izmantotajiem un sarežģītākajiem terminiem vai jēdzieniem jābūt skaidrojumiem; 2. Sistēmai ir jābūt viegli apgūstamai. Lietotāja palīdzības informācijai ir jābūt pilnīgai, konteksta jūtīgai un tai jāizskaidro kā paveikt tipiskos ikdienas uzdevumus; 3. Ar sistēmu ir jābūt viegli operēt. Sistēmai jābūt veidotai vienotā stilā. Saskarnes elementiem jādarbojas konsistenti visās Sistēmas 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 |
Indekss | Prasības nosaukums | Prasība |
pirms neatgriezeniskās darbības. Sistēmas interfeisam jābūt veidotam 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. | ||
NFP-33 | Krāsu pielietojums lietotāja saskarnē | Lietotāja saskarnei jābūt veidotai, atbilstoši Pasūtītāja vizuālās identitātes vadlīnijās noteiktajai krāsu gammai: |
Ieviešanas pieeja
Indekss | Prasības nosaukums | Prasība |
ORG-1 | Projekta ievadfāze | Projekta ievadfāzē (pirmā mēneša laikā, skaitot no iepirkuma līguma noslēgšanas) Izpildītājam jāveic sekojoši darbi: 1. Jāsaskaņo ar Pasūtītāju projekta pārvaldības plāns; 2. Jāsaskaņo ar Pasūtītāju Sistēmas arhitektūra; 3. Jāsaskaņo ar Pasūtītāju sākotnējais projekta uzkrājums un tā dalījums izstrādes sprintos. |
ORG-2 | Sākotnējais projekta uzkrājums | Sākotnējais projekta uzkrājums sastāv no šajā Tehniskajā specifikācijā ietvertajām funkcionālajām prasībām. Atbilstoši piedāvātajai izstrādes pieejai Izpildī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ā. Sākotnējais projekta uzkrājums jādala izstrādes sprintos (sprinta uzkrājuma vienumos), ar nosacījumu, ka viens sprints nevar pārsniegt sešas nedēļas. |
ORG-3 | Sprinta uzkrājuma vienums | Katru sprinta uzkrājuma vienumu raksturo Prasības apraksts, kas ir jārealizē. Vēlamā forma prasību izteikšanai ir t.s. «lietotāju stāsti», aprakstot: 1. lomu, kurai jānodrošina attiecīgā funkcionālā iespēja; 2. funkcionalitāti, kura jānodrošina; 3. biznesa vērtība, kas paskaidro, kāpēc lomai nepieciešama šī funkcionalitāte. Prasības aprakstam var tikt pievienoti papildus dokumenti, diagrammas, ekrānformu skices u.tml. artefakti; 4. Akceptēšanas kritēriji, kas kalpo akcepttestēšanas scenāriju izstrādei un definē sprinta pieņemšanas nosacījumus. |
ORG-4 | Sprinta plānošanas sanāksme | Katrs izstrādes sprints tiek uzsākts ar sprinta plānošanas sanāksmi, kurā piedalās Pasūtītāja projekta vadītājs un produkta īpašnieks (īpašnieki) un Izpildī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 |
Indekss | Prasības nosaukums | Prasība |
uzkrājuma vienumi (sprinta uzkrājums); 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). | ||
ORG-5 | Sprinta sanāksmes | Sprinta sanāksmes jāparedz regulāri, ne retāk, kā reizi nedēļā. Sprinta sanāksmē piedalās Pasūtītāja produkta īpašnieks un Izpildītāja projekta komanda. Sprinta sanāksmē: 1. Izpildītājs demonstrē izstrādes progresu un priekšlikumus biznesa prasību realizācijai, atbilstoši fiksētajiem lietotāju stā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, tajā skaitā lietojamības uzlabojumiem; 4. Sprinta sanāksmes laikā tiek precizēti un saskaņoti lietotāju stāsti, kā arī katras realizējamās prasības akceptēšanas kritēriji. Sprinta sanāksmes protokolē Izpildītājs. Sprinta sanāksmes protokolus precizētu lietotāju stāstu un saskaņotu lietotāja saskarnes dizaina paraugu veidā saskaņo Produkta īpašnieks. |
ORG-6 | Sprinta pārskata sanāksme | Sprinta noslēgumā Izpildītājs organizē sprinta pārskata sanāksmi, kurā iepazīstina ar sprinta laikā izstrādāto funkcionalitāti. Sprinta noslēguma sanāksmē Izpildītājam ir jādemonstrē sistēmas darbība izstrādes vidē. |
ORG-7 | Sprinta rezultātu piegāde | Izpildītājs piegādā ietvaros izstrādātās programmatūras piegādātās instalācijas pakotnes Pasūtītāja norādītam Infrastruktūras pārvaldniekam uzstādīšanai Pasūtītāja testa vidē atbilstoši pakotnē iekļautajai versijas izveides un uzstādīšanas instrukcijai. Izpildītājs nodrošina instalācijas atbalstu pēc Infrastruktūras pārvaldnieka pieprasījuma. Ja instalācija ir neveiksmīga un konstatētās problēmas nav novērstas 5 (piecu) darba dienu laikā, tālāka nodevuma akceptēšana tiek pārtraukta. |
ORG-8 | 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 Izpildītāja izstrādes vidē); 2. Dokumentētam. |
Prasības nodevumiem
Indekss | Prasības nosaukums | Prasība |
ORG-9 | Projekta pārvaldības plāns | Projekta pārvaldības plānam jābūt izstrādātam atbilstoši spējās programmizstrādes metodikai. 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ā noteikto prasību apmierināšanai. 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 |
Indekss | Prasības nosaukums | Prasība |
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. | ||
ORG-10 | Sistēmas arhitektūra | Sistēmas arhitektūras apraksts sagatavojams saskaņā ar standartu ISO/IEC/IEEE 42010:2011. Sistēmas 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); 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ā). 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). |
Prasības testēšanai
Indekss | Prasības nosaukums | Prasība |
ORG-11 | Izpildītāja testi | Lai nodrošinātu nodevumu atbilstību noteiktajām prasībām, Izpildītājam ir jāveic nodevumu iekšējā testēšana atbilstoši kādai no zināmajām testēšanas metodoloģijām, kā arī jāsagatavo testēšanas dokumentācija. Izpildītājam jāveic vismaz šāda testēšana: 1. Funkcionālā testēšana (katrai sprinta piegādei); 2. Lietojamības testēšana (katrai sprinta piegādei); 3. Integrācijas testēšana (katrai Sistēmas versijas piegādei); 4. Veiktspējas un ātrdarbības testēšana (katrai Sistēmas versijas piegādei); 5. Pieejamības testēšana (katrai Sistēmas versijas piegādei); 6. Drošības testēšana (katrai Sistēmas versijas piegādei). Testēšanu Izpildītājam jāveic ar saviem resursiem, neiesaistot Pasūtītāju, pirms nodevuma iesniegšanas, lai pārliecinātos, ka nodevums ir gatavs akcepttestēšanai. Izpildītāja veiktās testēšanas dokumentācija ir jāiesniedz kopā ar programmatūras nodevumiem. |
ORG-12 | Funkcionālā testēšana | Funkcionālajai testēšanai jānosedz: 1. Datu apstrāde. Katrai datu apstrādes operācijai ir jābūt noklātai ar vismaz vienu testa scenāriju; 2. Lietotāja saskarne. Katrai lietotāja saskarnes vienībai ir jābūt noklātai ar vismaz vienu testa scenāriju. Testa scenārijiem jāparedz pozitīvie un negatīvie testu scenāriju rezultāti. |
Indekss | Prasības nosaukums | Prasība |
ORG-13 | Lietojamības testēšana | Sistēmas lietojamība testējama piesaistot Sistēmas gala lietotājus un novērojot to darbu ar sistēmu, lai identificētu lietojamības kļūdas un jomas kurās nepieciešami uzlabojumi. Lietojamības testēšana var tikt apvienota ar sprinta demonstrāciju. |
ORG-14 | Integrācijas testēšana | Veicot integrācijas testēšanu, Izpildītājam ir jāpārbauda Sistēmas darbība kopumā, tai skaitā jāveic visas iepriekš piegādātās Sistēmas funkcionalitātes testēšana, ieskaitot to Sistēmas daļu atkārtoto testēšanu, kas netika modificētas, ar mērķi pārliecināties, ka veiktās modifikācijas nav negatīvi ietekmējušas līdz šim izstrādātās Sistēmas daļas. Sistēmu integrācijas testēšanas ietvaros Izpildītājam jāpārbauda arī starpsistēmu datu apmaiņas saskarnes ar citām informācijas sistēmām, ar nosacījumu, ka šīs informācijas sistēmas ir pieejamas testu veikšanai. |
ORG-15 | Veiktspējas un ātrdarbības testēšana | Izpildītājam jāveic Sistēmas un to komponenšu veiktspējas testi, lai pārliecinātos par Sistēmas atbilstību tehniskajā specifikācijā noteiktajām veiktspējas prasībām, kā arī lai identificētu iespējamās problēmas un atrastu risinājumus Sistēmas ātrdarbības uzlabošanai. Veiktspējas testēšana jāveic Pasūtītāja testa vai apmācību vidē. Veiktspējas un ātrdarbības testi jāveic daudzlietotāju režīmā simulējot Sistēmas darbību šādos apstākļos: 1. Nominālas noslodzes apstākļos (šī testa ietvaros ir jāparāda, ka Sistēma var izpildīt noteiktās ātrdarbības prasības nominālas noslodzes apstākļos – ar nominālu noslodzi saprotot slodzi, kas ir līdzvērtīga slodzei produkcijas režīmā, tai skaitā produkcijas režīmā paredzamajiem pieprasījumu pīķiem, bet mērogota ņemot vērā infrastruktūras jaudas atšķirības starp testa un produkcijas vidi); 2. Maksimālas noslodzes apstākļos (pakāpeniski paaugstinot noslodzi, nosakot slieksni, kad veiktspējas prasības vairs netiek izpildītas vai arī līdz Sistēmas darbības atteicei). |
ORG-16 | Pieejamības testēšana | Izpildītājam jānodrošina Sistēmas pieejamības testēšana. Sistēmas pieejamības testēšana Izpildītājam jāveic infrastruktūrā, kas ir tehnoloģiski un topoloģiski līdzīga Sistēmas produkcijas videi. Pieejamības testēšanas ietvaros jāpārbauda Sistēmas darbība pie šādiem scenārijiem: 1. Stabilitātes testēšana - šī testa ietvaros ir jāpārbauda Sistēmas darbības stabilitāte to ilgstoši darbinot pie dažādām noslodzēm, piemēram, nominālas noslodzes; 2. Noturības pret fizisko serveru kļūdām – šī testa ietvaros jāpārbauda Sistēmas spēja saglabāt darbību simulējot atsevišķa fiziskā servera darbības pārtraukumu; 3. Noturība pret tīkla pārrāvumiem – šī testa ietvaros jāpārbauda Sistēmas spēja saglabāt darbību simulējot atsevišķa tīkla posma darbības pārtraukums; 4. Noturība pret programmatūras kļūdām – šī testa ietvaros jāpārbauda Sistēmas spēja saglabāt darbību simulējot programmatūras kļūdu atsevišķā pielietojumu vai datu bāzes serverī; 5. Datu rezerves kopēšana – šī testa ietvaros jāpārliecinās, |
Indekss | Prasības nosaukums | Prasība |
ka iespējams izveidot Sistēmas rezerves kopiju un restaurēt Sistēmas darbību no izveidotās rezerves kopijas atbilstoši rezerves kopēšanas prasībām. | ||
ORG-17 | Drošības testēšana | Izpildītājam ir jāveic Sistēmas drošības testēšana ar mērķi pārbaudīt Sistēmas noturību pret nesankcionētu pieeju un cita veida uzbrukumiem, kā arī novērtēt Sistēmas atbilstību izvirzītajām drošības prasībām. Drošības testēšanu var veikt Pasūtītāja testa vidē. |
ORG-18 | Testa datu nodrošināšana | Izpildītājam jāsagatavo, jāsaskaņo ar Pasūtītāju, un visu veidu Sistēmas testēšanā jāizmanto speciāla testa datu kopa, kas ir līdzvērtīga reāajiem datiem (biznesa datiem), bet nesatur identificējamu personu reālus datus. Izpildītājam tehniskajā piedāvājumā ir jāapraksta testa datu kopas ievadīšanas, papildināšanas, izņemšanas un atjaunošanas kārtība. |
Pieņemšanas procedūras
Indekss | Prasības nosaukums | Prasība |
ORG-19 | Sprinta piegādes nodevumi | Sprinta piegādes nodevumi ir: 1. Programmatūras versijas apraksts; 2. Sistēmas pirmkods (komentēts) un izpildkods; 3. Versijas izveides un uzstādīšanas instrukcija, izmantojot izstrādes vides automātiskos būvējuma procesus; 4. Programmatūras prasību specifikācija lietotāju stāstu formā; 5. Sistēmas programmatūras projektējuma apraksts (dokuments apraksta tehnisko risinājumu, tajā skaitā integrācijas specifikāciju ar back-end un citām ārējām sistēmām, biznesa loģikas risinājumu un to sadarbību, datu modeli - iekšējās datu bāzes struktūru, iekļaujot detalizētu informāciju par visiem tās objektiem un to atribūtiem un vispārīgo aprakstu); 6. Lietotāju instrukcijas (kontekstjutīgu lietotāja palīgu) un administratoru rokasgrāmatu, papildinot tās saturu ar sprinta laikā veikto Sistēmas papildinājumu, izmaiņu un labojumu aprakstu. Uzsākot dokumentācijas izstrādi tās struktūra jāsaskaņo ar Pasūtītāju. Administratoru rokasgrāmatai jāiekļauj sistēmas rezerves kopēšanas un atjaunošanas instrukcijas. Dokumentācijai jābūt noformētai latviešu valodā; 7. Datu migrācijas skripti, ja versijas instalācija prasa izmaiņas datu bāzē; 8. Izpildītāja funkcionālo un lietojamības testu atskaite. |
ORG-22 | Sprinta pārbaude | 1. Laiks piegādāto sprinta nodevumu instalēšanai akcepttestēšanas vidē un sprinta akcepttestu izpildei tiek noteikts kā viena puse no sprinta garuma; 2. Pasūtītājs paziņo Izpildītājam par atklātajiem programmatūras defektiem, ja tādi ir, izmantojot Problēmpieteikumu vadības vidi; 3. Izpildītājam ir pienākums novērst akcepttestēšanas laikā konstatētos defektus laikā, kas nepārsniedz pusi no programmatūras izstrādes sprinta garuma un piegādāt |
Indekss | Prasības nosaukums | Prasība |
labojumus. Labojumiem ir (a) jābūt inkrementāli instalējamiem uz tekošajā sprintā piegādātās programmatūras un (b) 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ākošā sprinta nodevumos (b variants) un Pasūtītājs var nepieprasīt atsevišķu labojumu piegādi tekošajam sprintam (a variants), tomēr šāda vienošanās nav pienākums no Pasūtītāja puses; 4. Saņemot labotos programmatūras izstrādes nodevumus, Pasūtītājs veiks novērsto defektu pārbaudi , atkārtojot p.1.- 3. aprakstīto procedūru. | ||
ORG-23 | Versijas piegādes nodevumi | Versijas piegāde satur konsolidētus un integrētus sprintu nodevumus, papildus pievienojot pārskatu par Izpildītāja veikto testēšanu atbilstoši visām prasībā ORG-11 norādītajām testu klasēm. |
ORG-24 | Versijas akcepttestēšana | 1. Pasūtītājs veic Sistēmas akcepttestēšanu, veicot ORG-11 prasībā norādītos testus. Termiņš Sistēmas akcepttestēšanai ir 20 (divdesmit) kalendārās dienas; 2. Pasūtītājs paziņo Izpildītājam par atklātajiem programmatūras defektiem, ja tādi ir, izmantojot Problēmpieteikumu vadības vidi; 3. Izpildītājam ir tiesības novērst Sistēmas akcepttestēšanā atklātos trūkumus un piegādāt labojumus akcepttestēšanas laikā. Šādā gadījumā akcepttestēšana tiek pagarināta par 10 (desmit) darba dienām, skaitot no pēdējā atklātā trūkuma labojuma piegādes brīža; 4. Ja akcepttestēšanas laikā tiek atklātas 1. vai 2.prioritātes kļūdas, kuras nav iespējams operatīvi (t.i., vienas darba dienas laikā) novērst, akcepttestēšana tiek pārtraukta. |
ORG-25 | Atkārtota akcepttestēšana | Pēc akcepttestēšanā atklāto kļūdu novēršanas un atkārtotas Izpildītāja testēšanas veikšanas Izpildītājs atkāroti piegādā Sistēmu akcepttestēšanai. Atkārtota akcepttestēšana tiek veikta, atbilstoši Prasības ORG-24 noteikumiem. |
ORG-26 | Sistēmas akcepttestēšanas kritēriji | Sistēma tiks atzīta par atbilstošu ekspluatācijas uzsākšanai, ja izpildās visi šie noteikumi: 1. Akcepttestēšanas laikā nav atklāta neviena 1.-3. Prioritātes kļūda vai visas atklātās kļūdas ir novērstas un, atkārtoti testējot, tās nav izdevies atkārtot; 2. Sistēmā iemigrētie vēsturiskie dati ir korekti (ir iespējams iegūt identiskas atskaites par identiskiem laikaposmiem); 3. Piegādāti visi prasībās ORG-19 norādītie nodevumi un to saturs atbilst Tehniskās specifikācijas prasībām; 4. Visām 4.prioritātes kļūdām ir identificēts to cēlonis un saskaņots novēršanas termiņš. Pasūtītājs pēc saviem ieskatiem ir tiesīgs pieņemt Sistēmu arī ar nenovērstām 3.prioritātes kļūdām, ja ir identificēts to cēlonis un saskaņots novēršanas termiņš. |
Datu migrācija
Indekss | Prasības nosaukums | Prasība |
Indekss | Prasības nosaukums | Prasība |
ORG-27 | Datu migrācija | Izpildītājam jānodrošina datu migrācija no vēsturiskās numerācijas datu bāzes. Uz Sistēmu migrējami visi vēsturiskie dati, kas ir saistīti ar Tehniskajā specifikācijā paredzēto funkcionalitāti vai nepieciešami Tehniskajā specifikācijā aprakstīto prasību izpildei. Datu migrācija veicama paralēli Sistēmas funkcionalitātes izstrādei vai kā pēdējais Sistēmas izstrādes sprints. |
ORG-28 | Datu migrācijas aktivitātes | Datu migrācijas ietvaros Izpildī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 Sistēmas funkcionalitātei vai, kas kā savādāk nav piemēroti migrācijai. Informācija par kļūdainajiem datiem jānodod Pasūtītājam, lai tas 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. Jāsagatavo datu migrācijas skripti un datu migrācijas instrukcijas; 4. Jāsagatavo datu migrācijas kvalitātes pārbaudes (skriptu veidā vai kā savādāk), kas ļauj pārliecināties par datu migrācijas kvalitatīvajiem un kvantitatīvajiem rezultātiem; 5. Jāsniedz Pasūtītājam konsultatīvs atbalsts datu migrācijas un datu migrācijas testēšanas laikā. Izpildītājam ir jāveic vēsturisko datu migrācija, bet Izpildītājs nav atbildīgs par pārņemamo vēsturisko datu līdzšinējo kvalitāti un Izpildītājam nav jāveic šo kvalitātes nepilnību labošana. |
ORG-29 | Prasības datu migrācijas procesam | Izpildītājam jānodrošina datu migrācijas procesa žurnalēšana. Migrācijas žurnālā jāizceļ datu konfliktsituācijas un migrācijas kļūdas. Datu migrācijas izpildes rezultātā tādu konstatēto konfliktsituāciju un kļūdu novēršanai, kur nepieciešama Pasūtītāja iesaiste, jāparedz vismaz 1 (viens) mēnesis sistēmas izstrādes/ieviešanas laikā. Datu migrācijas process sākotnēji testējams Pasūtītāja testa vidē. Ja datu migrācijas testi ir veiksmīgi, tad datu migrācija atkārtojama produkcijas vidē. Datu migrācija produkcijas vidē plānojama kontekstā ar Sistēmas ieviešanu produkcijā. Plānojot datu migrāciju Izpildītājam ir jāparedz arī atkāpšanās scenārijs, kurš izpildāms gadījumā, ja datu migrācija nav veiksmīga. |
Prasības ieviešanai
Indekss | Prasības nosaukums | Prasība |
ORG-30 | Sistēmas uzstādīšana produkcijas vidē | Pēc akcepttestēšanas pabeigšanas Pasūtītājs veiks Sistēmas programmatūras uzstādīšanu un konfigurēšanu produkcijas vidē. Izpildītājam ir jāpiegādā pēdējās atkļūdotās programmatūras un dokumentācijas versijas (skat. atbilstošo nodevumu aprakstu iepriekš), kā arī jānodrošina nepieciešamais Pasūtītāja darbinieku atbalsts Sistēmas uzstādīšanas un konfigurēšanas produkcijas vidē laikā. Pēc Sistēmas uzstādīšanas un konfigurēšanas produkcijas vidē veicama atkārota datu migrācija (datu migrācija var tikt |
Indekss | Prasības nosaukums | Prasība |
ierobežota tikai ar to datu migrāciju, kuri uzkrāti starplaikā starp datu migrāciju akcepttestēšanai un Sistēmas ekspluatācijas uzsākšanu). | ||
ORG-31 | Sistēmas izmēģinājuma ekspluatācija | Pēc Sistēmas uzstādīšanas produkcijas vidē tiks veikta atkārtota Sistēmas 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 testu vidē. Termiņš izmēģinājuma ekspluatācijai ir 10 (desmit) darba dienas. |
ORG-32 | Sistēmas ieviešanas pabeigšana | Sistēmas ieviešana uzskatāma par pabeigtu, ja pēc Sistēmas uzstādīšanas produkcijas vidē 30 (trīsdesmit) darba dienu laikā izpildīti visi prasībā ORG-26 noteiktie akcepttestēšanas kritēriji. Kļūdu gadījumā sistēmas izmēģinājuma ekspluatācija tiek pagarināta par 10 (desmit) darba dienām, skaitot no pēdējās kļūdas labojuma piegādes. |
Apmācība
Indekss | Prasības nosaukums | Prasība |
ORG-33 | Administratoru apmācības | Izpildītājam jānodrošina Sistēmas administratoru apmācība tādā līmenī, lai administratori (ārpakalpojumu sniedzējs) spētu patstāvīgi veikt Sistēmas administrēšanas, uzraudzības, uzturēšanas, rezerves kopēšanas, darbības atjaunošanas un jauninājumu uzstādīšanas pasākumus. Sistēmas administratoru apmācībām ir jāietver gan teorētiskā daļa, gan praktiskā daļa ar praktiskiem treniņa uzdevumiem. Administratoru apmācība ietver vismaz 8 stundu teorētiskās nodarbības un 4 stundas zināšanu pārbaudei. |
ORG-34 | Lietotāju apmācību materiāli | Izpildītājam jāizstrādā apmācību materiāli vismaz šādām lietotāju grupām: • Pasūtītāja lietotāji; • SPRK lietotāji; • ESK lietotāji. Lietotāju apmācību materiālam jābūt interaktīvam un jāaptver visa konkrētajai lietotāju lomai pieejamā funkcionalitāte. |
Garantijas prasības
Indekss | Prasības nosaukums | Prasība |
ORG-35 | Garantijas prasības | Izpildītājam jānodrošina piegādātās Sistēmas 12 (divpadsmit) mēnešu garantija. Garantijas ietvaros Izpildītājam: 1. jāveic piegādātās Sistēmas darbības traucējumu un/vai kļūdu un nepilnību diagnosticēšana, analīze un novēršana; 2. jāveic Sistēmas ietvaros identificēto drošības nepilnību novēršana, ja tādas tiek identificētas Sistēmas lietošanas laikā, piemēram, Pasūtītājam īstenojot neatkarīgus Sistēmas drošības audita un ielaušanās testēšanas pasākumus; 3. jānovērš datu bojājumi, kas radušies piegādātās programmatūras (x.xx. trešās puses programmatūras) kļūdu vai Izpildītāja apzinātas vai neapzinātas rīcības |
Indekss | Prasības nosaukums | Prasība |
rezultātā, un kas apgrūtina Sistēmas izmantošanu atbilstoši Sistēmas tehniskajai specifikācijai, kāda tā bijusi, nododot Sistēmu ekspluatācijā; 4. dokumentācijas labošana (t.i. labošana, papildināšana utt.), atbilstoši visiem garantijas nodrošināšanas ietvaros veiktajiem labojumiem Sistēmā. Garantijas perioda laikā par izmaiņu pieteikumu nevar uzskatīt loģiskās kļūdas Sistēmas projektējumā vai projektējumam un prasībām neatbilstošas realizācijas programmatūras kodā. | ||
ORG-36 | Garantijas saistību izpildes procedūra | Garantijas ietvaros pieteiktās sistēmas kļūdas novēršanas saskaņā ar sadaļas “Prasības uzturēšanai” noteikumiem, ieskaitot termiņus un nosacījumus. |
Indekss | Prasības nosaukums | Prasība |
MNT-1 | Uzturēšanas pakalpojumu saturs | Uzturēšanas pakalpojumi ietver: 1. Palīdzības dienesta nodrošināšanu; 2. Sistēmas darbības monitoringu un potenciālo izmaiņu ierosināšanu; 3. Saņemto problēmu pieteikumu un izmaiņu pieprasījumu izvērtējumu; 4. Sistēmas kļūdu, uz kurām neattiecas Izpildītāja garantijas saistības, novēršanu; 5. Problēmu eskalēšanu standartprogrammatūras ražotājam; 6. Programmatūras bibliotēkas un dokumentācijas bibliotēkas uzturēšanu; 7. Konsultāciju sniegšanu; 8. Izmaiņu pieprasījumu realizāciju. |
MNT-2 | Pieteikumu reģistrēšanas sistēma | Izpildītājam līguma darbības laikā, sākot ar pirmā izstrādes sprinta piegādi, kā arī turpmāk garantijas un pēcgarantijas uzturēšanas ietvaros ir jānodrošina pieteikumu reģistrēšanas sistēma, kas ir pieejama Pasūtītāja autorizētām personām (līdz 5 lietotājiem) un kurā: 1. Ir definētas problēmpieteikumu kategorijas atbilstoši šīs tehniskās specifikācijas prasībām; 2. Pasūtītāja darbinieki, izmantojot web lietotāja saskarni var pieteikt problēmpieteikumus, nepieciešamības gadījumā tos papildināt, precizēt un komentēt; 3. Pasūtītāja darbinieki var sekot problēmpieteikumu risināšanas statusam; 4. Minimālā informācija, kas ir reģistrējama par katru problēmpieteikumu ir: a. Problēmpieteikuma īss apraksts (subject); b. Problēmpieteikuma detalizēts apraksts; c. Problēmpieteikuma kategorija (skat.prasību MNT-3); d. Problēmpieteikuma statuss; e. Pievienotās datnes (ja nepieciešams); f. Komentāri (ieskaitot datumu, laiku un lietotāju); g. Atsauce uz prasību (prasībām); h. Atsauce uz testēšanas scenāriju (scenārijiem); i. Problēmpieteikuma izmaiņu vēsture (izmaiņu datums, laiks, lietotājs, mainītie dati). |
Indekss | Prasības nosaukums | Prasība |
5. Problēmpieteikumu vadības vidē ievadītās informācijas īpašnieks ir Pasūtītājs. Izpildītājam pēc Xxxxxxxxxx pieprasījuma ir jānodrošina problēmpieteikumu vidē saglabātās informācijas vienreizēja nodošana Pasūtītājam formā, kas ir derīga importam citā sistēmā šādos gadījumos: a. Ja tiek izbeigts līgums ar Izpildītāju; b. Ja Pasūtītājs ievieš savu problēmpieteikumu vadības vidi. | ||
MNT-3 | Problēmu kategorijas | 1. Kategorija: Avārija. Problēma izraisa pilnīgu Sistēmas darbības apstāšanos (vai kādas no tās apakšsistēmas) pilnīgu apstāšanos un/vai nevar izpildīt kādu no biznesa procesiem (Datu ievadi, atlasi pārbaudēm uz vietas, x.xx., protokolu veidošana un rezultātu ievade, vēstuļu sagatavošana un izvadīšana uz FTP servera, aprēķinu veikšana, maksājumu veikšana, elektroniskā pieteikšanās sistēma). Avārijas (x.xx. augsta riska drošības trūkumi) tiek risināti 7x24 stundu režīmā neatkarīgi no šajā procedūrā aprakstītā darbalaika. 2. Kategorija: 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. Kategorija: 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. Kategorija: 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ā, kļūda / neprecizitāte produkta dokumentācijā. 5. Kategorija: Izmaiņu pieprasījums. Pieteikums tiek risināts saskaņā ar izmaiņu pieprasījumu apstrādes procedūru (aprakstīta 6.pielikumā). 6. Kategorija: Konsultācija. Problēma neizraisa iespēju zudumus. Programmatūrā nav kļūda, bet ir radusies kāda neskaidrība par Sistēmas darbību vai funkcionalitāti, izmantošanu, tehnisko apkalpošanu u.c. |
MNT-4 | Palīdzības dienesta nodrošināšana | Izpildītājam jānodrošina atbalsta dienesta pakalpojumi latviešu valodā, darba dienās no 8:00 līdz 18:00. Atbalsta dienestam jābūt pieejamam tiešsaistē, nodrošinot pieejamu Izpildītāja pieteikumu reģistrēšanas sistēmu (ārkārtas gadījumā izmantojot telefonu vai elektronisko pastu). Atbalsta dienestam jānodrošina: 1. Problēmpieteikuma apstrāde atbilstoši tā kategorijai; 2. Pasūtītāja pieprasītu konsultāciju plānošana, pieteiktās konsultācijas iekšēja eskalācija un rezultāta piegāde Pasūtītājam; 3. Pasūtītāja informēšana par pieteikto problēmu statusu; 4. Pasūtītāja pieteikto problēmu, kuru risināšana ir ārpus |
Indekss | Prasības nosaukums | Prasība |
Izpildītāja kompetences (piemēram, sadarbspēja ar trešo personu informācijas sistēmām) risināšanas atbalsts; 5. Saņemto problēmpieteikumu un izmaiņu pieprasījumu izvērtējums; 6. Saņemot problēmpieteikumu Izpildītājam jānodrošina problēmas analīze, sazinoties ar problēmas pieteicēju. Ja problēma pieteikta kā kļūda, Izpildītājam jānodrošina reakcijas laika atbilde (RLA), kurā jāietver šāda informācija: a. problēmas cēlonis; b. problēmas novēršanas veids (piemēram, nepieciešams veikt izmaiņas programmatūrā un/vai datubāzē); c. problēmas novēršanas laiks un/vai plāns (piemēram, labojums tiks piegādāts kā operatīvā piegāde, tiks ieplānots nākamajos Nodevumos); d. Pasūtītāja veicamās darbības, lai problēmu lokalizētu (piemēram, rekomendācijas, kas novērš iespējamu tālāku datubāzes bojājumu rašanos, atjauno vispārējo funkcionalitāti). Ja problēma pieteikta kā konsultācija, Izpildītājam Reakcijas laika atbildes termiņā jānodrošina šāda informācija: 1. Konsultācijas sniegšanas termiņa piedāvājums; 2. Piedāvātais konsultācijas veids (klātienes konsultācija, telefoniska vai rakstveida konsultācija); 3. Ja iespējams konsultāciju sniegt reakcijas laikā (telefoniski vai rakstveidā), Izpildītājs fiksē konsultācijas sniegšanas faktu un slēdz pieteikumu. Izpildītājs, saskaņojot to ar Pasūtītāja pārstāvi, kurš pieteicis problēmpieteikumu, var pārkvalificēt problēmpieteikumu kā konsultāciju, ja problēmpieteikuma cēlonis ir lietotāja kļūda vai dokumentācijas nepilnība vai mainīt tā prioritāti, ja kļūdu ir iespējams apiet, vadoties no Izpildītāja sniegtajām instrukcijām. Pirmās vai otrās kategorijas pieteikumiem prioritāti var mainīt tikai, saskaņojot to ar Pasūtītāja kontaktpersonu. | ||
MNT-5 | Kļūdu eskalēšana standartprogrammatūras ražotājam | Gadījumā, ja kļūdas cēlonis izriet no standartprogrammatūras (operētājsistēmas, datu bāzes) uzbūves, Izpildītājam ir pienākums eskalēt kļūdas pieteikumu standartprogrammatūras ražotājam, saskaņā ar atbalsta līmeni, kāds izriet no Pasūtītāja un standartprogrammatūras ražotāja līguma, vienlaikus nodrošinot operatīvo risinājumu (apvadceļu), lai būtu iespējams darbināt sistēmu. Izpildītāja pienākums ir monitorēt risinājuma piegādi, testēšanu un sniegt rekomendāciju par piegādātā standartprogrammatūras ielāpa uzstādīšanu. |
MNT-6 | Programmatūras bibliotēkas un dokumentācijas bibliotēkas uzturēšana. | 1. Izpildītājam ir pienākums uzturēt aktualizētu programmatūras pirmkoda bibliotēku un programmatūras dokumentācijas bibliotēku. 2. Operatīvo piegāžu ietvaros piegādātā programmatūra jāievieto programmatūras bibliotēkā. 3. Programmatūras dokumentācijas bibliotēka jāuztur specializētā dokumentācijas bibliotēkā. Aktualizēti |
Indekss | Prasības nosaukums | Prasība |
programmatūras dokumentācijas vienumi jāievieto bibliotēkā pēc dokumentētās programmatūras piegādes un sekmīgas notestēšanas Pasūtītāja pusē. Veicot dokumentācijas vienumu ievietošanu bibliotēkā, jāaktualizē visa projekta bibliotēkas dokumentācija, lai tā nodrošinātu atbilstību faktiskajai situācijai. 4. Programmatūras dokumentācijas vienumiem ir jābūt izimportējamiem ar biroja programmatūru nolasāmās datnēs, nodrošinot dokumentācijas savstarpējo integritāti un saites starp saistītiem dokumentācijas vienumiem. | ||
MNT-7 | Konsultāciju sniegšana | Pasūtot konsultācijas, Pasūtītājs norāda šādu informāciju: 1. Konsultācijas veids (klātienes/neklātienes konsultācija); 2. Izpildītājam uzdotais jautājums; 3. Nepieciešamais konsultācijas termiņš. Par konsultācijām, kuras tiek sniegtas ārpus reakcijas laika, Pasūtītājs pieteikumu uzskaites sistēmā atzīmē konsultācijas saņemšanas faktu, kas apliecina konsultācijas saņemšanu. |
MNT-8 | Kļūdu novēršana | Uzturēšanas pakalpojuma ietvaros jānodrošina kļūdu, uz kurām neattiecas garantijas termiņš, novēršana. |
MNT-9 | Reakcijas laiks | Reakcijas laiks ir laiks, kurā Izpildītājs veic problēmas analīzi un sniedz reakcijas laika atbildi, kurā norādīta šāda informācija: 1. problēmas cēlonis; 2. problēmas novēršanas veids (piemēram, nepieciešams veikt izmaiņas programmatūrā un/vai datubāzē); 3. problēmas novēršanas laiks un/vai plāns (piemēram, labojums tiks piegādāts kā operatīvā piegāde, tiks ieplānots nākamajos Nodevumos); 4. Pasūtītāja veicamās darbības, lai problēmu lokalizētu (piemēram, rekomendācijas, kas novērš iespējamu tālāku datubāzes bojājumu rašanos, atjauno vispārējo funkcionalitāti). |
MNT-10 | Defekta novēršanas laiks | Izpildītāja piegādāts risinājums, kurā nav iespējams atkārtot pieteikto problēmu vai piegādāts risinājums, kurš ļauj problēmas svarīguma pakāpi pazemināt no avārijas/kļūdas, kuru nevar apiet uz kļūdu, kuru var apiet. |
MNT-11 | Defekta izlabošana | Izpildītāja piegādāts risinājums, kurā nav iespējams atkārtot pieteikto problēmu. |
MNT-12 Līguma ietvaros pieteiktajām kļūdām jānodrošina šādi novēršanas termiņi:
Pieteikuma kategorija | Reakcijas laiks | Defekta novēršanas laiks no pieteikuma brīža | Eskalācija trešās puses programmatūras izstrādātājam (ja nepieciešams) no pieteikuma brīža | Defekta izlabošana (no pieteikuma brīža) |
1. Avārija | 1 stunda | 4 stundas | 24 stundas | 48 stundas |
2. Kritiska problēma (problēma, kuru nevar apiet) | 2 stundas | 8 stundas | 24 stundas | 72 stundas |
3. Problēma (problēma, kuru | 12 stundas | 5 darba dienas | 10 darba dienas | 1 mēnesis |
var apiet) | ||||
4. Mazsvarīga problēma | 12 stundas | - | 10 darba dienas | 1 mēnesis |
5. Konsultācija | 2 stundas | - | - | - |
Indekss | Prasības nosaukums | Prasība |
MNT-13 | Citi uzturēšanas pakalpojumi, kuri jāsniedz pēc Pasūtītāja pieprasījuma: | 1. Sistēmas konfigurēšanas atbalsts. 2. Atbalsts versiju uzstādīšanai Pasūtītāja vidēs. 3. Standartprogrammatūras papildinājumu vai drošības ielāpu testēšana vai konfigurācijas drošības prakses ieteikumu (hardening standards) ietekmes novērtēšana pirms ieviešanas sistēmā. 4. Sistēmas jauninājumu uzstādīšana. 5. Izvērtējumu un ekspertu atzinumu sagatavošana. 6. Rezerves kopiju izveidošana. |
MNT-14 | Ikmēneša atskaite par uzturēšanas pakalpojumiem | Par katra mēneša laikā sniegtajiem uzturēšanas pakalpojumiem Izpildītājs iesniedz Pasūtītājam atskaiti, kurā norāda: 1. Sistēmas pieejamības parametrus; 2. Uzturēšanas pieteikumu skaitu pēc pieteikumu veidiem un kategorijām; 3. Atrisināto pieteikumu skaitu; 4. Laiku, kurš patērēts kļūdu novēršanai; 5. Laiku, kurš patērēts konsultācijām; 6. Laiku, kurš patērēts citiem pakalpojumiem pēc Pasūtītāja pieprasījuma. |
Pielikums Nr. 3 iepirkumam Nr. VASES 2018/04
TEHNISKAIS PIEDĀVĀJUMS (VEIDLAPA)
Atklāts konkurss „Numerācijas datu bāzes izstrāde un uzturēšana”, Xx.Xx. VASES 2018/04
Funkcionālo prasību apraksts, par katru prasību norādot:
• Realizējamās funkcionalitātes aprakstu;
• Informāciju par integrāciju ar ārējiem datu avotiem, norādot saņemamo un nododamo informāciju, integrācijas metodi);
• Lietotāja saskarnes elementu skices (ja nepieciešams);
• Funkcionālās prasības realizācijas darbietilpības atšifrējums, atbilstoši Finanšu piedāvājuma tabulai “Darbietilpības novērtēšanas metodika”.
Sistēmas izstrādes pirmajā kārtā realizējamās funkcionālās prasības
Lietotāju pārvaldība
Indekss | Prasības nosaukums | Prasība | Prasības realizācijas piedāvājums |
USR1 | Lietotāju veidi | Sistēmā jānodrošina sekojoši lietotāju veidi: 1. Pasūtītāja administrators, vienlaikus var būt lietotājs (turpmāk – Administrators); 2. Pasūtītāja lietotājs; 3. SPRK lietotājs; 4. ESK lietotājs; 5. Publiskais lietotājs. | |
USR2 | Administrators | Administratoram jānodrošina vismaz šādas tiesības: 1. Izveidot ESK kontu; 2. Piešķirt / bloķēt/ atbloķēt/ anulēt SPRK lietotāja tiesības; 3. Piešķirt / bloķēt/ atbloķēt/ anulēt ESK lietotāja tiesības; 4. Piešķirt / bloķēt/ atbloķēt/ anulēt Pasūtītāja lietotāja tiesības; 5. Mainīt sistēmas konfigurējamos parametrus; 6. Apturēt/ palaist Sistēmas procesus; 7. Iniciēt datu arhivēšanu; 8. Atjaunot datus no arhīva; 9. Piekļūt jebkurai sistēmas funkcionalitātei. | |
USR3 | Lietotāja tiesību piešķiršana | Sistēmas lietotāju tiesības piešķir Administrators. Lietotāja tiesību piešķiršana veicama, norādot: 1. Juridisko personu, kuras vārdā rīkojas lietotājs; |
Indekss | Prasības nosaukums | Prasība | Prasības realizācijas piedāvājums |
2. Lietotājvārds; 3. Lietotāja vārds, uzvārds; 4. Lietotāja loma; 5. Identifikācijas veids (lietotājvārds/parole; autentifikācija, izmantojot Active Directory; izmantojot xxx.xxxxxxx.xx vienoto autentifikācijas LDAP (var būt vairāki autentifikācijas varianti); 6. Komunikāciju kanāli (e- pasts/tālrunis); 7. Statuss (ja nav piešķirti numuri, ESK statuss ir neaktīvs); 8. Piekļuves tiesību izveidošanas datums; 9. Piekļuves tiesiskais pamatojums (var būt arī saite uz sistēmā saglabātu elektronisku dokumentu vai saite uz Pasūtītāja lietvedībā saglabātu dokumentu); 10. Atzīmes par lietotāja statusa izmaiņām (bloķēts, bloķēšanas iemesls, atjaunots); 11. Lietotāja tiesību anulēšanas datums un pamatojums; 12. Piezīmes. | |||
USR4 | Lietotāja piekļuves automātiska bloķēšana | Sistēma automātiski bloķē lietotāja piekļuves tiesības gadījumos, ja: 1. Trīs reizes pēc kārtas ievadīta nepareiza (lietotājvārdam neatbilstoša parole); 2. Konstatēta netipiska datu plūsma, izmantojot lietotāja kontu vai citas pazīmes, kuras satur nesankcionētas piekļuves pazīmes (bloķēšanas nosacījumi identificējami analīzes laikā). Par lietotāja piekļuves bloķēšanu vai lietotājam, kura piekļuves tiesības bloķētas, tiek attēlots brīdinājuma paziņojums. | |
USR5 | Lietotāja piekļuves tiesību manuāla bloķēšana | Administratoram jābūt iespējai bloķēt lietotāja piekļuves tiesības: 1. Uz pagaidu prombūtnes laiku; 2. Citos gadījumos, kad Administrators to uzskata par nepieciešamu. | |
USR6 | Manuāla administratora /lietotāja tiesību atbloķēšana | Administrators var manuāli atjaunot lietotāju piekļuves tiesības sistēmai. Par piekļuves atjaunošanas faktu jāveic atzīme lietotāju tiesību pārvaldības modulī. | |
USR7 | Lietotāja | Sistēmā jāparedz funkcionalitāte |
Indekss | Prasības nosaukums | Prasība | Prasības realizācijas piedāvājums |
atbloķēšana kļūdaini ievadītas paroles gadījumā. | nozaudētas lietotāja paroles atjaunošanai. Pēc lietotāja pieprasījuma uz sistēmā saglabātu lietotāja adresi nosūtāma paroles atjaunošanas informācija, kura ir derīga vienai pieslēgšanās reizei. Pēc pirmās pieslēgšanās lietotāja parole jāatjauno. Parole automātiski var tikt atjaunota ne biežāk, kā vienu reizi gadā (konfigurējams parametrs). Paroles atjaunošanas informācija ir derīga ne vairāk, ka 72 stundas. | ||
USR8 | Lietotāja tiesību anulēšana | Lietotāja tiesību anulēšanu veic Administrators pēc Pasūtītāja, SPRK vai ESK rīkojuma/paziņojuma par darba attiecību izbeigšanu. Lietotāja tiesību anulēšanas gadījumā Sistēma Administratoram attēlo brīdinājuma paziņojumu, ja SPRK vai ESK pēc lietotāja tiesību anulēšanas nav neviena aktuāla lietotāja. Lietotāja tiesību anulēšana ietver lietotāja piekļuves tiesību loģisku dzēšanu, saglabājot auditācijas pierakstus. | |
USR9 | Lietotāja meklēšana | Administratoram jābūt iespējai meklēt reģistrētu lietotāju pēc šādiem parametriem: 1. Juridisko personu, kuras vārdā rīkojas lietotājs; 2. Lietotāja vārds, uzvārds; 3. Lietotāja loma; 4. Lietotāja statuss. | |
USR10 | Atskaite par lietotāja darbībām | Par katru lietotāju Sistēmai jāattēlo atskaite par Lietotāja Sistēmā veiktajām darbībām. | |
USR11 | Lietotāja identifikācija un autentifikācija | Sistēmai jānodrošina šādas lietotāja identifikācijas un autentifikācijas metodes: 1. Lietotājvārds un parole; 2. Autentificēšanās, izmantojot xxx.xxxxxxx.xx vienoto autentifikācijas risinājumu; 3. Autentifikācija ar Pasūtītāja Active Directory (tikai Pasūtītāja lietotājiem). | |
USR12 | Prasības parolēm | Paroles uzstādījumiem ir jābūt konfigurējamiem, nodrošinot vismaz šādus konfigurācijas parametrus: 1. Paroles garums; 2. Augšējā reģistra simbolu skaits; 3. Parastā reģistra simbolu skaits; |
Indekss | Prasības nosaukums | Prasība | Prasības realizācijas piedāvājums |
4. Ciparu skaits; 5. Speciālo simbolu skaits; 6. Paroles derīguma termiņš. | |||
USR13 | Paroļu aizsardzība | 1. Sistēmā jābūt bloķētai iespējai izmantot pārlūkā saglabātu paroli. 2. Parole publiskajā tīklā, pieslēdzoties sistēmai, jāpārraida šifrētā veidā. |
ESK reģistrs
Indekss | Prasības nosaukums | Prasība | Prasības realizācijas piedāvājums |
ESK-1 | ESK reģistrā uzturamā informācija | Sistēmā par katru ESK jāuztur sekojoša informācija: 1. ESK nosaukums; 2. Saimnieciskās darbības veids (SIA; AS ); 3. Uzņēmuma reģistra numurs Komercreģistrā; 4. Adrese / faktiskā adrese (strukturēts lauks, atbilstoši adrešu reģistra formātam); 5. SPRK piešķirtais ESK reģistrācijas numurs; 6. SPRK Reģistrācijas datums; 7. Vispārējās atļaujas statuss (aktīva/anulēta); 8. Kontaktpersona, kontaktinformācija – x.xx. e-pasts ar iespēju automātiski nosūtīt brīdinājumu); 9. Piezīmes; 10. Sistēmas lietotāju saraksts (piekārtojas dinamiski, datus veidojot no reģistrētajiem lietotājiem); 11. Vispārīgās atļaujas veids. ESK reģistrā uzturamo informāciju var ievadīt/mainīt/dzēst SPRK lietotājs vai Administrators. |
Numuru reģistrs
Indekss | Prasības nosaukums | Prasība | Prasības realizācijas piedāvājums |
NUM1 | Numura veidi | Numerācijas datu bāzes pamatelements ir numurs. Sistēmā jāuztur šādi numuru veidi: 1. Publiskā telefonu tīkla numuri; 2. Īsie kodi; 3. Identifikācijas kodi; | |
NUM2 | Publiskā telefonu tīkla | Publiskā telefonu tīkla numuriem jāuztur šāds iedalījums un numerācijas |
Indekss | Prasības nosaukums | Prasība | Prasības realizācijas piedāvājums |
numuri | diapazons: 1. Publiskā fiksētā tīkla numuri – numerācijas diapazons tiek piešķirts blokos pa 100 (ja ESK numerācijas lietošanas tiesības pieprasa pirmo reizi) vai blokos pa 1000 numuriem; 2. Publiskā mobilā tīkla numuri – blokos pa 100000 vai 10000 numuriem (izņēmuma gadījumā – pa 1000 numuriem); 3. Pakalpojumu numuri (diapazons no 5; 10; 25; 100; 1000): a. Bezmaksas izsaukuma pakalpojuma numuri (80xxxxxx); b. Dalītās samaksas pakalpojuma numuri (81xxxxxx); c. Papildu samaksas pakalpojuma numuri (90xxxxxx); d. Citu veidu pakalpojumu numuri (78xxxxxx). Numerācijas veidi un to iedalījums var tikt papildināts, atbilstoši numerācijas plāna izmaiņām. | ||
NUM3 | Īsie kodi | Īsajiem kodiem jāuztur šāds iedalījums: 1. Piekļuves kodi (trīs ciparu formātā 100; 104-109; 190-199; četru ciparu formātā – 1010-1019; 1020- 1029; 1030-1039); 2. Īsie numuri (speciālajiem dienestiem); 3. Īsie numuri, kuri sākas ar 118 (118x vai 118xx) - telefonu uzziņu dienestiem; 4. Īsie numuri, kuri sākas ar 16 (16xx) – operatoru pakalpojumiem tīkla ietvaros; 5. Īsie numuri, kuri sākas ar 82 – 89 (82xx;....) – operatoru pakalpojumiem, tajā skaitā Īsie numuri, kuri sākas ar 88 vai 89 (88xx; 89xx) – Erotiska, pornogrāfijas vai azartspēļu satura pakalpojumiem; 6. Īsie numuri pakalpojumiem ar sociālo vērtību (116xxx) Īsie numuri tiek piešķirti pa vienam numuram. | |
NUM4 | Numuru veidu uzturēšana | Numuru veidus, atkarībā no nacionālā numerācijas plāna, uztur Pasūtītājs. Numuru veidiem jābūt konfigurējamiem, uzturot vismaz šādus konfigurācijas parametrus: |
Indekss | Prasības nosaukums | Prasība | Prasības realizācijas piedāvājums |
1. Numurā ietilpstošo zīmju skaits; 2. Numura sākuma zīmes, ja tas raksturo numura veidu; 3. Numura veida nosaukums; 4. Par numura lietošanas tiesībām veicamais maksājums (par vienu numuru, euro); 5. Tarifikācijas solis (vienreizējs maksājums, diena, mēnesis, ceturksnis, gads). Uzstādot par tarifikācijas soli mēnesi vai gadu katrs iesāktais mēnesis vai gads tiek skaitīts par pilnu periodu . | |||
NUM5 | Publiskā telefonu tīkla numuru statusi | Atkarībā no izmantošanas, publiskā telefonu tīkla numuram jānodrošina šādi statusi: 1. Izveidots (iekļauts nacionālajā numerācijas plānā); 2. Pieteikts (t.i. rezervēts); 3. Piešķirts; 4. Pagarināts; 5. Anulēts; 6. Tālāk nodots; 7. Piešķirts lietošanā: o Bez termiņa (fiksētā tīkla numuriem un mobilo operatoru pēcapmaksa numuriem); o Sagatavots (mobilā tīkla priekšapmaksas numuriem); o Lietošanā līdz (mobilā tīkla priekšapmaksas numuriem); 8. Nodots ar numura saglabāšanu; 9. Saņemts no cita operatora ar numura saglabāšanu. 10. Atslēgts. | |
NUM6 | Publiskā telefonu tīkla numura pieteikšana | Numura pieteikšanu reģistrē SPRK darbinieks. Numurs, kuram piešķirts statuss “Pieteikts” nav pieejams pieteikšanai vai piešķiršanai citiem operatoriem. Statuss automātiski tiek anulēts, ja numurs 60 kalendāro dienu laikā netiek piešķirts operatoram. | |
NUM7 | Publiskā telefonu tīkla numura/ numuru bloka piešķiršana | Numura/Numuru bloka piešķiršanu veic SPRK, ar savu lēmumu piešķirot ESK tiesības lietot numuru vai numerācijas bloku. Par lēmumu, ar kuru tiek piešķirts numerācijas bloks vai numurs, Sistēmā jāievada šāda informācija: 1. ESK, kuram piešķirts |
Atklāta konkursa „Numerācijas datu bāzes izstrāde un uzturēšana” nolikums
Indekss | Prasības nosaukums | Prasība | Prasības realizācijas piedāvājums |
numurs/numuru bloks (izvēlne no klasifikatora, nodrošinot atlasei vismaz pēc reģistrācijas numura un nosaukuma); 2. Numura veids (izvēle no klasifikatora, lietotājam tiek attēloti pieejamie numuru veidi); 3. Numurs vai numuru bloks. Lietotāja saskarnē sistēma attēlo pieejamos numerācijas blokus un konkrētajam ESK piešķirtos numerācijas blokus. Jāparedz iespējas: a. ievadīt numerācijas diapazona pirmos 4 skaitļus, sistēma automātiski attēlo pieejamos numurus, tiek ievadīts piešķiramo numuru skaits; b. ievadīt numerācijas bloka pirmo un pēdējo numuru; c. Izvēlēties numerācijas bloku, kurš seko ESK izmantotajam numerācijas blokam. 4. Datums, ar kuru numurs/numuru bloks piešķirts lietošanā; 5. Piešķirts līdz / bez termiņa (neobligāts lauks). Ievadot piešķiramo numuru vai numerācijas bloku, sistēmai jāveic numuru pieejamības pārbaude (t.i., vai kāds no izvēlētajiem numuriem jau nav piešķirts). Gadījumā, ja kāds no izvēlētajiem numuriem jau ir piešķirts lietošanā, jāattēlo kļūdas paziņojums un jāatgriežas ievadformā, saglabājot ievadītās atbilstošās vērtības. Numerācijas piešķiršanas formā jāparedz iespēja piešķirt vairākus numuru veidus vai vairākus viena veida numerācijas diapazonus. No numerācijas piešķiršanas ekrānformas jābūt saitei uz iespēju izveidot jaunu ESK. Funkcionalitāte pieejama lomai SPRK darbinieks. | |||
NUM8 | Publiskā telefonu tīkla numura/numur u bloka lietošanas tiesību pagarināšana | Numura/Numuru bloka lietošanas tiesību pagarināšanu veic SPRK, ar savu lēmumu pagarinot ESK piešķirtās tiesības lietot numuru vai numerācijas bloku. Par lēmumu, ar kuru tiek pagarinātas numerācijas bloka vai numura lietošanas tiesības, Sistēmā jāievada šāda informācija:: |
Atklāta konkursa „Numerācijas datu bāzes izstrāde un uzturēšana” nolikums
Indekss | Prasības nosaukums | Prasība | Prasības realizācijas piedāvājums |
1. ESK, kuram piešķirts numurs/numuru bloks (izvēlne no klasifikatora). Pēc ESK ievades Sistēma attēlo attiecīgajam ESK piešķirtos numurus, kuriem ir noteikts lietošanas termiņš; 2. Numurs vai numuru bloks (iespējams izvēlēties no attiecīgajam ESK piešķirtajiem numuriem, kuriem ir noteikts lietošanas termiņš vai manuāli ievadīt numuru vai numerācijas diapazona pirmo un pēdējo numuru. Ievadformā jāparedz abas formas aizpildīšanas uzsākšanas iespējas, pēc numura vai numerācijas diapazona ievades attēlojot ESK, kuram šis numurs/numerācijas diapazons piešķirts); 3. Piešķirts līdz (obligāti aizpildāms lauks), jānodrošina datu ievades validācija – piešķirtais termiņš nevar būt īsāks, kā esošais termiņš. Jāparedz alternatīva pagarināt numura lietošanas tiesības par noteiktu laika periodu (jādefinē termiņa soļi) vai mainīt numura lietošanas tiesību termiņu uz beztermiņa. Funkcionalitāte pieejama lomai SPRK darbinieks. | |||
NUM9 | Publiskā telefonu tīkla numura/numur u lietošanas tiesību anulēšana | Numuru/numuru bloka lietošanas tiesību anulēšanu veic SPRK. Par numura/ numerācijas diapazona anulēšanu Sistēmā tie veikts ieraksts: 1. ESK, kuram piešķirts numurs/numuru bloks (izvēlne no klasifikatora). Pēc ESK ievades Sistēma attēlo attiecīgajam ESK piešķirtos numurus; 2. Anulējamais numurs vai numuru bloks (iespējams izvēlēties no attiecīgajam ESK piešķirtajiem numuriem, kuriem ir noteikts lietošanas termiņš vai manuāli ievadīt numuru vai numerācijas diapazona pirmo un pēdējo numuru. Ievadformā jāparedz abas formas aizpildīšanas uzsākšanas iespējas, pēc numura vai numerācijas diapazona ievades attēlojot ESK, kuram šis numurs/numerācijas |
Atklāta konkursa „Numerācijas datu bāzes izstrāde un uzturēšana” nolikums
Indekss | Prasības nosaukums | Prasība | Prasības realizācijas piedāvājums |
diapazons piešķirts), jāparedz iespēja anulēt visus piešķirtos numurus; 3. Datums, ar kuru anulētas numerācijas lietošanas tiesības 4. Anulēšanas iemesls (klasifikators no SPRK 1/18 33. Punktā norādītajiem iemesliem); 5. Opcionāla iespēja piešķirt anulēto numerācijas diapazonu citam ESK (pāreja uz numerācijas piešķiršanas formu, piešķiramo numerācijas resursu vietā attēlojot anulētos numurus. Funkcionalitāte pieejama lomai SPRK darbinieks. | |||
NUM10 | Numura tālāknodošana | Numuru/numuru bloka lietošanas tiesību tālāknodošanu veic SPRK. Par numura/ numerācijas bloka tālāknodošanu Sistēmā tie veikts ieraksts: 1. Donors (izvēle no ESK saraksta); 2. Nododamie numuri /numuru bloks (ja izvēlēts ESK, tiek attēloti ESK piešķirtie numerācijas resursi ar iespēju filtrēt numerācijas resursus pēc numerācijas veida). Kā ierosme var būt arī numura / numerācijas diapazona ievade, šādā gadījumā sistēma automātiski attēlo ESK, kura lietošanā ir numuri/numerācijas diapazons; 3. Saņēmējs (izvēle no ESK saraksta); 4. Tālāknodošanas apstiprināšana; 5. Atzīme, ka ESK, kuram nodoti numerācijas resursi, iesniedzis rakstveida apliecinājumu par numerācijas tiesību saņemšanu; 6. (Opcionāli) – atverot ierakstu par numerācijas lietošanas tiesību tālāknodošanu, iespējams numerācijas resursu tālāknodošanu anulēt. Funkcionalitāte pieejama lomai SPRK darbinieks. | |
NUM11 | Piešķirts lietošanā | Numura piešķiršanu lietošanā veic ESK. Par numura piešķiršanu lietošanā Sistēmā tiek veikts ieraksts: 1. Numurs; 2. Datums, ar kuru numurs piešķirts lietošanā: o Mobilajiem priekšapmaksas |
Atklāta konkursa „Numerācijas datu bāzes izstrāde un uzturēšana” nolikums
Indekss | Prasības nosaukums | Prasība | Prasības realizācijas piedāvājums |
numuriem datums, ar kuru piešķirts lietošanā tiek uzstādīts atbilstoši statusam Sagatavots (mobilā tīkla priekšapmaksas numuriem); o Papildus statuss “Lietošanā līdz” (mobilā tīkla priekšapmaksas numuriem). Funkcionalitāte pieejama lomai “Elektronisko sakaru komersants”. Ierakstu par numura piešķiršanu lietošanā ESK veic vienā no sekojošiem veidiem: a. Nododot Sistēmai informāciju par numura piešķiršanu lietošanā ar tīmekļa pakalpi no savas informācijas sistēmas brīdī, kad ar galalietotāju ir noslēgts līgums par elektronisko sakaru pakalpojumiem.; b. Ievadot Sistēmas lietotāja saskarnē informāciju par numura piešķiršanu lietošanā dienā, kad ar galalietotāju ir noslēgts līgums par elektronisko sakaru pakalpojumiem. Funkcionalitāte pieejama ESK lietotājam. | |||
NUM12 | Tīmekļa pakalpe “Piešķirts lietošanā” | Tīmekļa pakalpe tiek ierosināta ESK informācijas sistēmā. Pēc apstiprinājuma saņemšanas no Sistēmas, tiek nodoti prasībā NUM 11 norādītie dati. Transakcija tiek apstiprināta pēc veiksmīgas datu saņemšanas apstiprinājuma saņemšanas. Gadījumā, ja netiek saņemts kāds no apstiprinājumiem, tīmekļa pakalpes izsaukums tiek atkārtots ik pēc 15 minūtēm, līdz veiksmīgas datu saņemšanas apstiprinājuma saņemšanai. Veiksmīga datu saņemšana tiek apstiprināta, izpildoties sekojošiem nosacījumiem: 1. Numurs, kurš piešķirts galalietotājam ietilpst ESK piešķirtajam numerācijas diapazonam; 2. Numurs, kurš piešķirts galalietotājam, nav piešķirts citam galalietotājam; |
Atklāta konkursa „Numerācijas datu bāzes izstrāde un uzturēšana” nolikums
Indekss | Prasības nosaukums | Prasība | Prasības realizācijas piedāvājums |
3. Dati veiksmīgi saglabāti Sistēmā. Neizpildoties kādam no veiksmīgas datu saņemšanas nosacījumiem tiek atgriezts viens no šādiem kļūdas paziņojumiem: 1. Numurs neatbilst ESK piešķirtajam numerācijas diapazonam; 2. Numurs jau ir fiksēts kā piešķirts; 3. Datu saglabāšana nav bijusi veiksmīga. Kļūdas paziņojuma gadījumā (izņemot (3)), elektronisko sakaru operatora sistēmā jāveic datu korekcija un atkārtoti jāizsauc tīmekļa pakalpe. | |||
NUM13 | Galalietotājam piešķirtā numura ievadīšana lietotāja saskarnē | ESK lietotājam pēc pieslēgšanās sistēmai ir pieejama saskarne lietošanā piešķirto numuru ievadei: 1. Numurs/numerācijas diapazons (ievadforma); 2. Piešķiršanas datums (pēc noklusējuma ievades datums); 3. Iespēja ievadīt jaunu numuru vai apstiprināt ievadīto informāciju. Pēc ievades tiek veikta validācija: 1. Numurs, kurš piešķirts galalietotājam ietilpst ESK piešķirtajam numerācijas diapazonam; 2. Numurs, kurš piešķirts galalietotājam, nav piešķirts citam galalietotājam; 3. Piešķiršanas datums nav lielāks par Sistēmas datumu. Sistēma saglabā ievadītos datus. Neveiksmīgas saglabāšanas gadījumā lietotājam tiek attēlots kļūdas paziņojums. | |
NUM14 | Nodots ar numura saglabāšanu | Par numuru, kurš saņemts ar numura saglabāšanu, ESK, kurš saņēmis numuru, sniedz informāciju, norādot: 1. Numurs; 2. ESK, no kura numurs tiek pārņemts; 3. Datums, ar kuru stājas spēkā līgums par elektronisko sakaru pakalpojuma sniegšanu. ESK, kurš nodevis numuru ar numura saglabāšanas pakalpojumu, sniedz informāciju par : 1. Numuru; 2. ESK, kuram numurs nodots; 3. Datums, kad numurs nodots. Numura pārejas faktu Sistēma reģistrē |
Atklāta konkursa „Numerācijas datu bāzes izstrāde un uzturēšana” nolikums
Indekss | Prasības nosaukums | Prasība | Prasības realizācijas piedāvājums |
brīdī, kad saņemts paziņojums par nodošanu un pārņemšanu. Gadījumā, ja konfigurējamā periodā informācija par nodoto un pārņemto numuru nesakrīt, Sistēma attēlo administratoram brīdinājuma paziņojumu par informācijas nesakritību. | |||
NUM15 | Atslēgts | ESK, kurš pārtraucis pakalpojuma sniegšanu galalietotājam, ievada sistēmā datus par: 1. Numuru; 2. Atslēgšanas datumu; 3. Piezīmes (neobligāts lauks). Mobilajiem priekšapmaksas numuriem statuss “atslēgts” tiek uzstādīts automātiski, ar brīdi, kad no derīguma termiņa notecējuma pagājuši trīs mēneši. Informāciju par atslēgšanu elektronisko sakaru ESK ievada vienā no šiem veidiem: a) Nododot Sistēmai informāciju par numura atslēgšanu ar tīmekļa pakalpi no savas informācijas sistēmas brīdī, kad pakalpojums galalietotājam ir pārtraukts; b) ievadot Sistēmas lietotāja saskarnē informāciju par numura atslēgšanu. Funkcionalitāte pieejama ESK lietotājam. | |
NUM16 | Tīmekļa pakalpe “atslēgts” | Tīmekļa pakalpe tiek ierosināta ESK informācijas sistēmā. Pēc apstiprinājuma saņemšanas no Sistēmas, tiek nodoti prasībā NUM15 norādītie dati. Transakcija tiek apstiprināta pēc veiksmīgas datu saņemšanas apstiprinājuma saņemšanas. Gadījumā, ja netiek saņemts kāds no apstiprinājumiem, tīmekļa pakalpes izsaukums tiek atkārtots ik pēc 15 minūtēm, līdz veiksmīgas datu saņemšanas apstiprinājuma saņemšanai. Veiksmīga datu saņemšana tiek apstiprināta, izpildoties sekojošiem nosacījumiem: 1. Atslēgtais numurs bijis piešķirts ESK vai nodots ar numura saglabāšanas pakalpojumu |
Atklāta konkursa „Numerācijas datu bāzes izstrāde un uzturēšana” nolikums
Indekss | Prasības nosaukums | Prasība | Prasības realizācijas piedāvājums |
2. Atslēgtajam numuram pirms tam bijis statuss “piešķirts lietošanā” 3. Dati veiksmīgi saglabāti Sistēmā. Neizpildoties kādam no veiksmīgas datu saņemšanas nosacījumiem tiek atgriezts viens no šādiem kļūdas paziņojumiem: 1. Numurs neatbilst elektronisko sakaru ESK piešķirtajam numerācijas diapazonam; 2. Numurs nav fiksēts kā piešķirts lietošanā; 3. Datu saglabāšana nav bijusi veiksmīga. Kļūdas paziņojuma gadījumā (izņemot (3)), elektronisko sakaru operatora sistēmā jāveic datu korekcija un atkārtoti jāizsauc tīmekļa pakalpe. Atslēgtais numurs tiek atzīmēts kā neizmantots Ja numurs bijis nodots ar numura saglabāšanas pakalpojumu, numurs tiek atzīmēts kā neizmantots tam ESK, kuram tas sākotnēji piešķirts vai tālāknodots. | |||
NUM17 | Atslēgtā numura ievadīšana lietotāja saskarnē | ESK lietotājam pēc pieslēgšanās sistēmai ir pieejama saskarne atslēgto numuru ievadei: 1. Numurs (ievadforma); 2. Piešķiršanas datums (pēc noklusējuma ievades datums); 3. Iespēja ievadīt jaunu numuru vai apstiprināt ievadīto informāciju; Pēc ievades tiek veikta validācija: 1. Atslēgtais numurs bijis piešķirts ESK vai nodots ar numura saglabāšanas pakalpojumu; 2. Atslēgtajam numuram pirms tam bijis statuss “piešķirts lietošanā”; 3. Atslēgšanas datums nav lielāks par Sistēmas datumu. Sistēma saglabā ievadītos datus. Neveiksmīgas saglabāšanas gadījumā lietotājam tiek attēlots kļūdas paziņojums. | |
NUM18 | Speciāli atslēgšanas gadījumi | SPRK darbiniekam ir tiesības reģistrēt sistēmā ESK vispārējās atļaujas anulēšanas faktu. Vispārējās atļaujas anulēšanas gadījumā tiek atslēgti visi konkrētajam ESK piešķirtie numerācijas resursi. |
Atskaites
Indekss | Prasības nosaukums | Prasība | Prasības realizācijas piedāvājums |
REP1 | Darbības ar atskaitēm | Atskaišu funkcionalitātei var piekļūt: 1. SPRK lietotāji – Pasūtītāja definētām atskaitēm par visiem ESK; 2. VASES lietotāji – visām atskaitēm 3. ESK lietotāji – atskaitēm par ESK piešķirtajiem, lietošanā piešķirtajiem un atslēgtajiem ar numura saglabāšanu numuriem. Atskaitēm jānodrošina vismaz šāda funkcionalitāte: - skatīt uz ekrāna; - izdrukāt; - saglabāt kā *pdf datni; - saglabāt kā *xls/xlsx datni. | |
REP2 | Atskaite par publiskā tīkla numuriem | Atskaites sagatavošanu var pieprasīt prasībā REP 1 norādītie lietotāji. Pieprasot atskaiti, jāievada datums, uz kuru atskaite sagatavojama. Atskaite tiek attēlota pa numuru veidiem, par katru numuru veidu attēlojot šādu informāciju: 1. ESK piešķirtie numuri; 2. Galalietotājiem piešķirtie numuri; 3. Galalietotājiem lietošanā esošie priekšapmaksas karšu numuri (tikai par publiskā mobilā tīkla numuriem); 4. Lietošanā esošie numuri testēšanai (no 01.01.2019); 5. Lietošanā esošie numuri maršrutēšanai (no 01.01.2019) Lietošanā esošie viesabonēšanas numuri (tikai par publiskā mobilā tīkla numuriem); 6. Atslēgtie numuri, kuru galalietotāji ir izvēlējušies izmantot numura saglabāšanas pakalpojumu; 7. Lietošanā esošie numuri maršrutēšanai, nodrošinot numura saglabāšanas pakalpojumu (tikai publiskā fiksētā tīkla operatoriem; sākot ar 01.01.2019.); 8. Lietošanā esošie numuri testēšanai (sākot ar 01.01.2019.); 9. Atslēgto abonentu/ galalietotāju numuru skaits mēneša pēdējā dienā, kuri ne ilgāk, kā par 3 mēnešiem nav piešķirti citiem lietotājiem; 10. Atslēgto abonentu/ galalietotāju numuru skaits mēneša pēdējā |
Indekss | Prasības nosaukums | Prasība | Prasības realizācijas piedāvājums |
dienā, kuri ilgāk, kā par 3 mēnešiem nav piešķirti citiem lietotājiem; 11. Neizmantoto abonentu numuru skaits mēneša pēdējā dienā – abonentu numuri, kas sagatavoti izmantošanai abonentu identifikācijas moduļos, bet nav pieslēgti lietošanai (tikai par publiskā mobilā tīkla numuriem). | |||
REP3 | Atskaite par publisko telefonu tīklu operatoru pakalpojumu kodiem | Atskaites sagatavošanu var pieprasīt prasībā REP1 norādītie lietotāji. Pieprasot atskaiti, jāievada datums, uz kuru atskaite sagatavojama. 1. ESK lietošanā esošo publisko telefonu tīklu operatoru pakalpojumu kodu “11X”, “12X”, “13X”, “14X”, “15X” un “17X” (triju ciparu formātā) skaits mēneša pēdējā dienā/lietotāja definētā datumā; 2. ESK lietošanā esošo publisko telefonu tīklu operatoru pakalpojumu kodu “18XX”, “83XX– 89XX” (četru ciparu formātā), “82XXX” (piecu ciparu formātā) skaits mēneša pēdējā dienā; 3. ESK lietošanā esošo operatora izvēles kodu “101X”, “102X”, “103X” (četru ciparu formātā) un “10X”, “19X” (triju ciparu formātā) skaits mēneša pēdējā dienā. | |
REP4 | Datu iesniegšana | ESK pieejami sekojoši datu iesniegšanas veidi: 1. Sistēmā reģistrēto datu apstiprināšana (pieejama gadījumā, ka ESK nodod Sistēmai datus ar tīmekļa apkalpēm vai regulāri ievada datus lietotāja saskarnē) (prasība realizējama otrajā kārtā, skat. prasību REP8); 2. Datu ievade lietotāja saskarnē. | |
REP5 | Atskaites ievade lietotāja saskarnē. | Pēc ESK lietotāja pieprasījuma Sistēma attēlo atskaites formu, atbilstoši ESK nodotajiem numuru veidiem un numerācijas diapazoniem, kā arī sistēmā reģistrētajiem numura saglabāšanas pakalpojumiem. Atskaitē tiek attēlota Sistēmā uzkrātā informācija par iepriekšējo pārskata periodu un ievadlauki aktuālās informācijas ievadei. Ievadlauki aktuālās |
Indekss | Prasības nosaukums | Prasība | Prasības realizācijas piedāvājums |
informācijas ievadei ir obligāti. Veicot atskaites apstiprināšanu, sistēma par katru numerācijas veidu veic datu kvalitātes pārbaudi (atskaitē sniegtajai informācijai jāatbilst ESK nodotajiem numerācijas diapazoniem). ESK lietotājam ir iespējams apstiprināt atskaiti “bez izmaiņām”, šādā gadījumā atskaitē tiek attēloti dati par iepriekšējo pārskata periodu. | |||
REP6 | Atskaite par ESK | SPRK un VASES lietotājiem ir pieejama pilna atskaites funkcionalitāte. Atskaites pieprasījumā uzstādāmi viens vai vairāki sekojoši iestatījumi: 1. ESK; 2. Numura veids; 3. ESK piešķirtie numuri; 4. Lietošanā piešķirtie numuri; 5. Tālāknodotie / saņemtie numuri; 6. Pārnestie numuri (izmantojot numura saglabāšanas pakalpojumu) – nodoti citam operatoram; 7. Pārnestie numuri (izmantojot numura saglabāšanas pakalpojumu) – saņemti no cita operatora; 8. Atslēgtie numuri (ne vairāk, kā trīs mēnešus); 9. Atslēgtie numuri (vairāk, kā trīs mēnešus); 10. Neizmantotie numuri; 11. Laika periods / datums (ar iespēju saņemt atskaiti par vienu dienu); 12. Izvērsta atskaite/savērsta atskaite (attēlo tikai skaitliskos lielumus) Atskaites konfigurē Pasūtītājs. | |
REP7 | Izvērstā atskaite | Izvērstā atskaitē par ESK nodotajiem numuriem atbilstoši numerācijas veidam vai konkrētam lietotāja ievadītam numuram (numuru diapazonam) tiek attēlots: 1. Numurs; 2. Numura aktuālais statuss; 3. Numura statusa maiņas datums. |
Administratora skats
Indekss | Prasības nosaukums | Prasība | Prasības realizācijas piedāvājums |
ADM-1 | Pārskats par apstiprinātajā m atskaitēm | Administratora skatā jābūt pieejamai informācijai par atskaišu apstiprināšanu: |
Indekss | Prasības nosaukums | Prasība | Prasības realizācijas piedāvājums |
1. ESK, kuri apstiprinājuši sistēmas atskaites (par katru ESK attēlojas atskaites apstiprināšanas datums); 2. ESK, kuri nav apstiprinājuši sistēmas atskaites; 3. ESK, kuri nav iesnieguši atskaites (par konfigurējamu periodu). | |||
ADM-2 | ESK darbību pārskati | Administratora skatā jābūt pieejamai informācijai par: 1. ESK, kuri mēneša laikā nav veikuši datu atjaunošanu (nav izdarīts neviens ieraksts); 2. ESK, kuri izvēlējušies labot sistēmas atskaites, bet nav to izdarījuši (konfigurējamā laikā). | |
ADM-3 | Saziņa ar ESK | Administratoram jābūt iespējai nosūtīt vienam vai vairākiem ESK vai SPRK paziņojumus ar brīvi konfigurējamu tekstu. Pie katra ziņojuma jābūt iespējai redzēt ESK, kuri iepazinušies ar ziņojumu (pazīme uzstādās automātiski brīdī, kad ESK lietotājs atvēris ziņojumu). | |
ADM-4 | Saņemto ziņojumu apstrāde | Administratora darba virsmā jāattēlojas saņemtajiem ziņojumiem no ESK un SPRK ar iespēju lasīt/atbildēt/pārsūtīt/dzēst. |
ESK lietotāja skats
Indekss | Prasības nosaukums | Prasība | Prasības realizācijas piedāvājums |
USR-1 | Lietotāja darbvirsma | Lietotāja darbvirsmai jānodrošina pieeja visām lietotāja lomai atbilstošajām darbībām, kā arī ziņojumu/atgādinājumu sadaļai. | |
USR-2 | Ziņojumu / atgādinājumu sadaļa | Sistēmai konfigurējamā laikā jānosūta lietotājiem paziņojumi par veicamajām darbībām un to termiņu, kā arī par nokavētajām darbībām (piemēram, Sistēmas atskaites apstiprināšanu). Sistēmā jāattēlo Sistēmas administratora un SPRK /ESK ziņojumi ar iespēju lasīt/atbildēt/pārsūtīt/dzēst. Sistēmā jānodrošina iespēja nosūtīt ziņojumus: 1. SPRK – vienam vai vairākiem ESK, nodrošinot iespēju monitorēt ziņojuma statusu (skat. ADM-3) un Administratoram; 2. ESK – SPRK vai administratoram. |
Publiskajam lietotājam pieejamā funkcionalitāte
Indekss | Prasības nosaukums | Prasība | Prasības realizācijas piedāvājums |
PUB-1 | Publiskojamie dati | Sistēmai publicēšanai Pasūtītāja tīmekļa vietnē jānodod šāda informācija: 1. Pieteiktie numuri; 2. Piešķirtie numuri; 3. Brīvie diapazoni. | |
PUB-2 | Operatora noteikšanas pakalpojums | Sistēmai jānodrošina iespēja lietotāja saskarnē ievadot numuru, saņemt informāciju par operatoru, kurš apkalpo šo numuru, ja numurs nav piešķirts lietošanā – par numura statusu (izveidots/piešķirts operatoram). |
Sistēmas izstrādes otrajā kārtā realizējamās funkcionālās prasības
Indekss | Prasības nosaukums | Prasība | Prasības realizācijas piedāvājums |
NUM19 | Atteikšanās no numerācijas resursu izmantošanas | Sistēmā jāparedz iespēja ESK atteikties no neizmantota/ daļēji izmantota numerācijas bloka. Neizmantotā numerācijas bloka daļa šādā gadījumā kļūst pieejama piešķiršanai citiem ESK – uz otro kārtu. | |
NUM20 | Numura saglabāšanas pakalpojuma procesa nodrošināšana | ESK, kurš saņēmis galalietotāja pieteikumu par numura saglabāšanas pakalpojumu (saņēmēja tīkla operators), ievada Sistēmā datus: 1. Numurs; 2. ESK, no kura numurs tiek pārņemts; 3. Datums, ar kuru stājas spēkā līgums par elektronisko sakaru pakalpojuma sniegšanu. Sistēma izveido paziņojumu donora tīkla operatoram par saņemto pieteikumu numura saglabāšanas pakalpojumam. Donora tīkla operators var apstiprināt paziņojumu vai atteikt numura saglabāšanas pakalpojumu. Paziņojuma apstiprināšanas gadījumā numurs sistēmā tiek reģistrēts saņēmēja tīkla operatoram, tiek reģistrēts numura nodošanas fakts, numurs tiek piesaistīts saņēmēja tīkla operatoram, nodošanas laiks ir datums, ar kuru stājas spēkā līgums ar saņēmēja tīkla operatoru. Ja numura saglabāšanas pakalpojums tiek atteikts, saņēmēja tīkla operatoram tiek attēlots brīdinājuma paziņojums par numura saglabāšanas pakalpojuma atteikumu. Šādā gadījumā sistēmā |
Indekss | Prasības nosaukums | Prasība | Prasības realizācijas piedāvājums |
numura statuss nemainās, tiek saglabāti audita pieraksti par notikumu. Gadījumā, ja iemesli, kādēļ numura nodošanas pakalpojums tika atteikts, ir novērsti, saņēmēja tīkla operators atkārtoti ievada paziņojumu par numura pārņemšanu (vai atkārtoti iesniedz sistēmā saglabāto paziņojumu, kuram uzstādīts statuss “atteikts”). Gadījumā, ja donora tīkla operators vienas darba dienas laikā nav atbildējis uz pieteikumu, Sistēma ģenerē brīdinājuma paziņojumu Pasūtītāja administratoram. Numuram ir statuss atslēgts ar numura saglabāšanu – tas ir brīdis, ar kuru ESK – saņēmējs var pievienot numuru, pēc atslēgšanas pārvietotais numurs atgriežas pie numerācijas lietošanas tiesību saņēmēja. Donoram atskaitē parādās atgrieztais numurs, Sistēmā jānodrošina serviss, kas aizsūta paziņojumu ESK par pieejamu numuru. | |||
NUM21 | Numerācijas bloku optimizācija | Sistēmā jānodrošina iespēja optimizēt numerācijas blokus, kuros ir daži izmantoti numuri, savukārt no pārējo numuru izmantošanas ESK ir atteicies. Optimizācija ietver numerācijas bloka sadalīšanu sīkākos blokos, izolējot tos numerācijas apgabalus, kuri ir piešķirti lietošanā. Gadījumā, ja atsevišķie numuri, kuri bijušie piešķirti lietošanā, tiek atslēgti, Sistēmai jāatjauno pieejams numerācijas bloks. | |
REP8 | Sistēmā reģistrēto datu apstiprināšana | Funkcionalitāte pieejama ESK, kuri datus uz Sistēmu nodot, izmantojot tīmekļa pakalpes vai veicot regulāru datu ievadi. ESK lietotājs izsauc mēneša atskaiti, kura tiek veidota no Sistēmā esošajiem datiem. Atskaiti iespējams eksportēt *csv formātā (vai citā formātā, ja par tādu vienojas analīzes gaitā). ESK lietotājs var apstiprināt Sistēmā ievadīto datu pareizību vai izvēlēties precizēt datus, izmantojot lietotāja saskarni . | |
REP9 | Datu nodošana VID | Sistēmā jānodrošina funkcionalitāte ESK deklarācijas iesniegšanai VID. Par datu apmaiņas formātu izstrādes laikā jāvienojas ar VID maksājumu administrēšanas sistēmas izstrādātāju. | |
REP10 | Kopsavilkuma | Sistēmā jānodrošina funkcionalitāte |
Indekss | Prasības nosaukums | Prasība | Prasības realizācijas piedāvājums |
datu nodošana VID | kopsavilkuma datu (t.i., apkopotu datu par visiem ESK) nodošanai VID. Par datu apmaiņas formātu izstrādes laikā jāvienojas ar VID maksājumu administrēšanas sistēmas izstrādātāju. | ||
REP11 | Biznesa analītikas risinājums | Sistēmā jāiekļauj biznesa analītikas (Business Intelligence) apakšsistēma, kura ļauj lietotājam definēt un iegūt atskaites nepieciešamajos griezumos, atskaites definēšanai izmantojot lietotāja saskarni. | |
REP12 | Atskaite par numerācijas izmantošanu | Sistēmai jānodrošina šādu statistikas datu attēlošana par visiem numuriem vai par individuāli izvēlētu ESK, individuāli izvēlēta ESK gadījumā jāattēlo gan ESK, gan vidējais rādītājs: 1. Piešķirto un lietošanai nodoto numuru attiecība; 2. Vidējais laiks no numura piešķiršanas līdz nodošanai abonentam lietošanai; 3. Piešķirtie/tālāk nodotie numuri; 4. Piešķirtie/atslēgtie numuri ar numura saglabāšanas pakalpojumu. | |
REP13 | Atskaišu datu vizualizācija | Sistēmai jānodrošina atskaišu datu vizualizācija vismaz šādām atskaitēm: • Piešķirtie numerācijas resursi – vienā blokā jāattēlo attiecīgajā numuru veidā piešķirtie numerācijas resursi, vizuāli (ar krāsām) izdalot lielākos ESK (izdalāmo ESK skaits definējams analīzes fāzē), kā arī pārējos ESK (citi ESK), kuriem piešķirti numerācijas resursi. Ja ESK ir iekļauts sadaļā “Citi ESK”, novietojot kursoru uz konkrēto numerācijas bloku, jāattēlo informācija par ESK, kuram piešķirti numerācijas resursi; • Piešķirtie/lietošanā nodotie numerācijas resursi. Vizualizācijai jābūt pieejamai kā par visiem numerācijas resursiem, tā par atsevišķiem ESK piešķirtajiem un lietošanā nodotajiem numerācijas resursiem. | |
REP14 | Atskaišu papildināšana ar jaunām sadaļām | Sākot ar 01.01.2020 atskaite par numerācijas izmantošanu jāpapildina ar sekojošām pozīcijām: 1. par bezmaksas izsaukuma pakalpojuma numuriem, kas piešķirti lietotājam attiecīgo pakalpojumu |
Atklāta konkursa „Numerācijas datu bāzes izstrāde un uzturēšana” nolikums
Indekss | Prasības nosaukums | Prasība | Prasības realizācijas piedāvājums |
sniegšanai: a. galalietotājiem lietošanā piešķirtie numuri attiecīgo pakalpojumu sniegšanai; b. atslēgtie numuri, kuru galalietotāji ir izvēlējušies izmantot numura saglabāšanas pakalpojumu. 2. par dalītās samaksas pakalpojuma numuriem, kas piešķirti lietotājam attiecīgo pakalpojumu sniegšanai: a. galalietotājiem lietošanā piešķirtie numuri attiecīgo pakalpojumu sniegšanai; b. atslēgtie numuri, kuru galalietotāji ir izvēlējušies izmantot numura saglabāšanas pakalpojumu. 3. par papildus samaksas pakalpojuma numuriem, kas piešķirti lietotājam attiecīgo pakalpojumu sniegšanai: a. galalietotājiem lietošanā piešķirtie numuri attiecīgo pakalpojumu sniegšanai; b. atslēgtie numuri, kuru galalietotāji ir izvēlējušies izmantot numura saglabāšanas pakalpojumu. 4. par citu veidu pakalpojumu numuriem, kas piešķirti lietotājam attiecīgo pakalpojumu sniegšanai: a. galalietotājiem lietošanā piešķirtie numuri attiecīgo pakalpojumu sniegšanai; b. atslēgtie numuri, kuru galalietotāji ir izvēlējušies izmantot numura saglabāšanas pakalpojumu. | |||
USR-3 | Mobilo iekārtu atbalsts | Sistēmai jānodrošina responsīvs dizains, lai Sistēmu būtu iespējams pilnvērtīgi lietot mobilajās iekārtās (planšetēs/mobilajos telefonos), nodrošinot satura attēlošanu atbilstoši iekārtas ekrāna izmēram. | |
USR-4 | Statistikas datu vizualizācijas pieejamība publiskajiem lietotājiem | Jānodrošina, lai statistikas datu vizualizācija (skat. prasību REP13) tiktu attēlota Pasūtītāja tīmekļa vietnē xxx.xxxxx.xx. |
Nefunkcionālo un organizatorisko prasību realizācijas apraksts Nefunkcionālās prasības
Sistēmas arhitektūra
Indekss | Prasības nosaukums | Prasība | Prasības realizācijas piedāvājums |
NFP-1 | Virtualizācijas tehnoloģiju atbalsts | Sistēmai jāatbalsta šāda Pasūtītāja izmantotā virtualizācijas platforma: Microsoft Hyper-V Server 2016. | |
NFP-2 | Jauninājumu uzstādīšana | Sistēmai jāparedz iespēja uzstādīt sistēmas jauninājumus, nepārtraucot sistēmas darbību. |
Pieejamības prasības
Indekss | Prasības nosaukums | Prasība | Prasības realizācijas piedāvājums |
NFP-3 | Augsta pieejamība | Sistēmai ir jābūt noturīgai pret atsevišķu moduļu kļūmēm. Sistēmai jāsaglabā darbaspēja un jānodrošina transakciju integritāte datubāzes servera, pielietojumu servera jeb pielietojuma programmatūras kļūdas gadījumā. | |
NFP-4 | Darbības nepārtrauktība | Sistēmai ir jānodrošina nepārtraukta pieejamība lietotājiem valstī noteiktajās darba dienas, no 8:00 līdz 18:00 (Sistēmas darba laiks). Sistēmas darba laikā jānodrošina pieejamība 98% (darbspējas laiks). Darbspējas laiks rēķināms gada periodā un tajā ieskaitāmas arī plānotās dīkstāves. Vienas atsevišķas dīkstāves laiks nevar pārsniegt 4 (četras stundas). | |
NFP-5 | Rezerves kopēšana | Sistēmai jānodrošina iespēja veikt Sistēmas rezerves kopēšanu un konsistentas kopijas iegūšanu bez Sistēmas darba apturēšanas. Ja Sistēmas 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. Sistēmai ir jābūt atjaunojamai no rezerves kopijas ne ilgāk kā četru stundu laikā un dati nedrīkst pazust vairāk kā par vienu pēdējo Sistēmas darbības stundu. Sistēmas atjaunošanai no rezerves kopijas nepieciešamajā laikā nav ieskaitāma infrastruktūras |
Indekss | Prasības nosaukums | Prasība | Prasības realizācijas piedāvājums |
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 Sistēmas Rezerves kopēšanas un darbības atjaunošanas plāns. |
Veiktspējas prasības
Indekss | Prasības nosaukums | Prasība | Prasības realizācijas piedāvājums |
NFP-6 | Sistēmas lietotāju skaits | Sistēmai jāspēj apkalpot 100 lietotāji, no kuriem vienlaicīgi Sistēmu lietos līdz 30% | |
NFP-7 | Ekrānformu attēlošanas laiks | Lietotāju datu ievada vai datu pieprasījuma (izziņas) rezultātam, kurš satur līdz 3 dažādiem datu objektiem, uz ekrāna jātiek attēlotam ne ilgāk kā 2 sekunžu laikā no pieprasījuma izdarīšanas brīža (neņemot vērā tīkla pārsūtīšanas aizturi un pieprasījumu izpildes laiku ārējās sistēmās). Papildus datu objektu (vairāk par 3 dažādiem objektiem) attēlošanas gadījumā ekrānformas maksimāli pieļaujamais attēlošanas laiks drīkst tikt palielināts par 0,5 sekundēm, katram papildus attēlojamajam datu objektam. Ekrānformām, kuras nodrošina datu atlasi izmantojot brīva teksta meklēšanu, kas nepieļauj indeksācijas izmantošanu datubāzē, maksimāli pieļaujamais rezultāta attēlošanas laiks ir līdz 15 sekundēm. Prasītais ekrānformu attēlošanas laiks jānodrošina vismaz 90% gadījumu no visiem pieprasījumiem mērījumu veikšanas laika periodā pie prasībā NFP -6 norādītā vienlaicīgo lietotāju skaita un izmantojot reālu datu bāzu aizpildījumu, kas atbilst produkcijas režīmam. | |
NFP-8 | Sinhrono web servisu izpildes laiks | Sistēmas sinhrono Web servisu pieprasījumu apstrādes laiks nedrīkst pārsniegt 2 sekundes. |
Infrastruktūras prasības
Indekss | Prasības nosaukums | Prasība | Prasības realizācijas piedāvājums |
NFP-9 | Sistēmas vides | Sistēmai ir paredzētas šādas vides: 1. Produkcijas vide. Produkcijas vidi nodrošina Pasūtītājs un tā paredzēta Sistēmas darbināšanai ražošanas režīmā; 2. Testa vide. Testa vidi nodrošina Pasūtītājs un tā paredzēta Sistēmas testēšanai no Pasūtītāja puses; 3. Izstrādes vide. Izstrādes vidi nodrošina Izpildītājs un tā ir paredzēta Sistēmas izstrādei un testēšanai. | |
NFP-10 | Izstrādes vides nodrošināšana | Izpildītājam ir jānodrošina sava vide (aparatūra, programmatūra, biroja telpas) līguma ietvaros izpildāmo darbu un uzdevumu veikšanai. Izpildītājam izstrāde jāveic, izmantojot tikai licencētu programmatūru. Pasūtītājs nenodrošina Izpildītāju ar licencēm. | |
NFP-11 | Pieejamie tehniskie resursi | Pasūtītājs Sistēmas darbībai ir paredzējis izmantot 2 virtuālo serverus produkcijas un testa vižu darbināšanai ar šādiem resursiem katrā: 2 vCPU, 16GB RAM, 500GB HDD, Gigabit Ethernet NIC. . Gadījumā, ja šie tehniskie resursi nav pietiekami, lai nodrošinātu veiktspējas un pieejamības prasības, Pretendentam piedāvājumā jānorāda nepieciešamie papildus tehniskie resursi un to cena. |
Trešo pušu programmatūras licences
Indekss | Prasības nosaukums | Prasība | Prasības realizācijas piedāvājums |
NFP-12 | Sistēmas licenču piegāde | Izpildītājam Finanšu piedāvājumā jāietver visas piedāvātās Sistēmas 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 Sistēmas izmantošana šajā tehniskajā specifikācijā paredzētajam 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 (5 gadus pēc Sistēmas pirmās versijas nodošanas ekspluatācijā). Atsevišķi ir jānorāda |
Indekss | Prasības nosaukums | Prasība | Prasības realizācijas piedāvājums |
licenču izmaksas un noteikumi Sistēmas Produkcijas (ekspluatācijas) vides un Testa vides izveidošanai un uzturēšanai. | |||
NFP-13 | Prasības trešo pušu programmatūrai | Trešo pušu standarta programmatūras komponentēm jābūt ar ražotāja apliecinātu uzturēšanas termiņu vismaz 5 (pieci) gadi, skaitot no paredzētās Sistēmas nodošanas ekspluatācijā dienas. Ja programmatūras licenču uzturēšana ir saistīta ar regulāra uzturēšanas/atbalsta maksājuma veikšanu, šādi maksājumi jāiekļauj finanšu piedāvājumā. Visai piedāvātajai atvērtā pirmkoda programmatūrai ir jābūt aktuālai (t.i, pēdējai versijai) un stabilai (t.i. pielietotai un attīstītai vismaz 3 (trīs) gadu laikā no piedāvājuma iesniegšanas dienas, pie tam pēdējā atvērtā pirmkoda programmatūras versija nedrīkst būt vecāka par 6 (sešiem) mēnešiem. |
Prasības drošībai
Indekss | Prasības nosaukums | Prasība | Prasības realizācijas piedāvājums |
NFP-14 | Autentifikācija, autorizācija un auditācija | Sistēmai jābūt veidotai tā, lai nevarētu apiet autentifikācijas un autorizācijas procedūras un nesankcionēti lietot Sistēmas funkcionalitāti vai piekļūt Sistēmas datiem. Sistēmai jāapkalpo tikai identificētus, autentificētus un autorizētus lietotājus. Sistēmas 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. Jānodrošina aizsardzība pret lietotāju esamības pārbaudi (Sistēma nedrīkst atklāt vai lietotājs eksistē vai nē pirms sekmīgas autentifikācijas); |
Indekss | Prasības nosaukums | Prasība | Prasības realizācijas piedāvājums |
4. Jebkurš nesekmīgs autorizācijas vai autentifikācijas mēģinājums jāreģistrē sistēmas žurnālā saskaņā ar Tehniskās specifikācijas prasību NFP-23; 5. Sistēmā 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); 6. Sistēmas ietvaros ir jābūt izveidotam tehniskajam risinājumam, kas veic neaktīvo sesiju automātisku pārtraukšanu pēc „n” minūtēm (kur „n” ir konfigurējams parametrs, pieņemot, ka noklusētā vērtība ir 15 minūtes); 7. Sistēmai ir jāietver paziņojumu sniegšanas mehānisms, kas informē lietotāju par tā darba sesijas neaktivitāti un sesijas pārtraukšanu “n” minūtes pirms sesijas noilguma iestāšanās (kur „n” ir konfigurējams parametrs, pieņemot, ka noklusētā vērtība ir 2 minūtes); 8. Sistēmā ir jābūt ietvertai kontrolei, kas liedz atkārtoti izmantot jau aktīvu izveidotu sesijas identifikatoru jaunas sesijas izveides nodrošināšanai; Administratoru pieeja sistēmai jāspēj ierobežot ar vienu vai vairākiem Internet Protokola adrešu apgabaliem. Ar Internet Protokola adrešu apgabalu šeit tiek saprasts IPV4 vai IPV6 adrešu intervāls. | |||
NFP-15 | Programmatūras drošība | Veicot Sistēmas izstrādi vai pielāgošanu jāievēro šādas prasības: 1. Sistēmas izstrādē jāievēro OWASP ieteiktie sistēmu izstrādes principi: xxxx://xxx.xxxxx.xxx/xxxxx.xxx/ 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 datu bāzes aizsardzības uzlaušanu; |
Indekss | Prasības nosaukums | Prasība | Prasības realizācijas piedāvājums |
2. WEB pielietojumi izstrādājami saskaņā ar OWASP drošas programmēšanas vadlīnijām: xxxxx://xxx.xxxxx.xxx/xxxxx.xxx/ OWASP_Secure_Coding_Practices_ 3. WEB pielietojumiem sesiju pārvaldība jāorganizē pēc OWASP ieteiktajiem principiem: xxxx://xxx.xxxxx.xxx/xxxxx.xxx/ Session_Management; 4. WEB pielietojumiem jāņem vērā OWASP ieteikumi AJAX tehnoloģiju izmantošanai (xxxx://xxx.xxxxx.xxx/xxxxx.xxx/ Ajax_and_Other_%22Rich%22_Inte rface_Technologies). Jāpielieto ražotāju un nozares ekspertu ieteiktās labās prakses drošu informācijas sistēmu izstrādē; 5. Sistēmas 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 ražošanas sistēmās; 6. Sistēmas izstrādē nedrīkst izmantot komponentes, kurām ražotājs nepiegādā vai tuvāko 5 gadu laikā no izstrādes uzsākšanas brīža plāno pārtraukt izstrādi un/vai piegādāt drošības labojumus. Pēc Sistēmas izstrādes noslēgšanas Sistēmas izstrādātājam ir jāveic neatkarīgs Sistēmas drošības audits, kura ietvaros tā piesaistītai trešajai pusei ir jāveic Sistēmas drošības atbilstības pārbaude attiecībā uz iepriekš minēto prasību ievērošanu, par to sagatavojot un Pasūtītājam iesniedzot ziņojumu kā vienu no Sistēmas piegādes dokumentācijas nodevumiem. Gadījumā, ja pārbaudes laikā tiek atklātas kādas drošības nepilnības, tās Sistēmas izstrādātājam ir jānovērš pirms Sistēmas ieviešanas produktīvajā lietošanā. | |||
NFP-16 | Informācijas drošība | Sistēmai jāizveido pietiekami kontroles mehānismi, lai nodrošinātu, |
Atklāta konkursa „Numerācijas datu bāzes izstrāde un uzturēšana” nolikums
Indekss | Prasības nosaukums | Prasība | Prasības realizācijas piedāvājums |
ka Sistēmas dati gan to pārraides, gan glabāšanas laikā netiek atklāti personām vai programmām, kurām nav attiecīgas autorizācijas. Piekļuve Sistēmas datiem nodrošināma ievērojot šādus principus: 1. „Zina tikai tas, kuram jāzina” (need-to-know); 2. „Ir jānodrošina minimālās tiesības pienākumu pildīšanai”, gan lietotājiem, gan tehnoloģiskajiem lietotājiem (least privilege); 3. Jānodrošina lietotāju darbību reģistrācija un šo datu saglabāšana (accountability). Sistēmai jānodrošina, ka programmatūra, nesniedz lietotājam informāciju, kas varētu apdraudēt Sistēmas drošību, tai skaitā, nepieļaujot iespēju lietotājam veikt analīzi par kļūdas un veikto Sistēmas pārbaužu raksturu, kas varētu atvieglot tālākos uzbrukumus Sistēmai. Kļūdas situācijās lietotājam jāparāda tikai minimālā nepieciešamā informācija, bet detalizēts kļūdas tehniskais apraksts jāsaglabā Sistēmas notikumu audita žurnālā saskaņā ar prasību NFP-23. Sistēmas saskarnēm jābūt izveidotām tā, lai nevarētu apiet autentifikācijas un autorizācijas procedūras un nesankcionēti lietot Sistēmas informāciju vai datnes. | |||
NFP-17 | Lietotāja identifikācijas datu drošība | Sistēmai jānodrošina lietotāju identifikācijas datu aizsardzība. Aizliegts uzglabāt lietotāja identitātes un citus to raksturojošus sensitīvus datus (paroles, pieejas kodus, šifrēšanas atslēgas u.c.) atklātā tekstā datu bāzē vai interneta pārlūkprogrammā, piemēram, kešatmiņā. | |
NFP-18 | Datu apstrādes un pārraides drošība | Izpildītājam jānodrošina, ka Sistēmas datu apmaiņas, kā arī citi iespējamie automatizētie datu apstrādes procesi tiek pildīti tikai ar tehnoloģisko lietotāju kontiem, kuriem funkcijas veikšanai ir noteiktas mazākās nepieciešamās tiesības. Tehnoloģiskie lietotāji un to tiesības jādokumentē programmatūras projektējuma |
Atklāta konkursa „Numerācijas datu bāzes izstrāde un uzturēšana” nolikums
Indekss | Prasības nosaukums | Prasība | Prasības realizācijas piedāvājums |
aprakstā. 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: 1. Sistēmām, apmainoties ar datiem (informācijas pieprasījumi un atbildes starp web servisiem xml formātā), ir jāizmanto par drošām vispāratzītas datu šifrēšanas tehnoloģijas; 2. Ja nav iespējams informācijas pieprasījumu un atbilžu šifrēšana, ir jānodrošina šifrēts datu pārraides kanāls, izmantojot VPN tehnoloģijas. Arī datu apmaiņai starp tīmekļa serveri un klienta pārlūku jābūt šifrētai. | |||
NFP-19 | Sistēmas atbilstība drošību reglamentējošiem normatīvajiem aktiem | Sistēmai jāizpilda šādas drošības standartu un normatīvo aktu prasības: 1. Jānodrošina LVS ISO/IEC 15408 standartā “Informācijas tehnoloģija – Drošības tehnikas – IT drošības novērtējuma kritēriji” 2.daļā “Drošības funkcionālās komponentes” (Information technology — Security techniques — Evaluation criteria for IT security — Part 2: Security functional components. ISO/IEC 15408-2. Third edition 2008-08-15) iekļauto rekomendāciju un vadlīniju ievērošanu, Līguma ietvaros formulējot un realizējot konkrētām sistēmām izvirzāmās drošības prasības; 2. 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; 3. 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; 4. 2015.gada 28.jūlija Ministru kabineta noteikumos Nr.442 „Kārtība, kādā tiek nodrošināta informācijas un komunikācijas |
Indekss | Prasības nosaukums | Prasība | Prasības realizācijas piedāvājums |
tehnoloģiju sistēmu atbilstība minimālajām drošības prasībām” minētās prasības. Citos uz informācijas sistēmu drošību attiecināmos normatīvajos aktos iekļautās prasības, kas tiek pieņemtas un stājas spēkā Sistēmas izstrādes laikā. | |||
NFP-20 | Pasākumi pret darbības noliegšanu (non- repudiation) | Sistēmas kontroles mehānismi veidojami tā, lai nodrošinātu, ka persona, kas veikusi kādas darbības, nevar noliegt šādu darbību veikšanas faktu. Sistēmai jāļauj pamanīt gadījumus, kad informācija tikusi modificēta to pārraides vai glabāšanas laikā. |
Auditācijas prasības
Indekss | Prasības nosaukums | Prasība | Prasības realizācijas piedāvājums |
NFP-21 | Lietotāju darbību auditācija | Sistēmai ir jāauditē vismaz šādas lietotāju veiktās darbības: 1. Lietotāja pieslēgšanos (veiksmīgu, neveiksmīgu) sistēmai un atslēgšanos no sistēmas; 2. Lietotāju izsauktos pārskatus un aktivizētos asinhronos uzdevumus (batch job); 3. Datu pievienošanu, labošanu un dzēšanu; 4. Datu apskati. Datu apskate auditējama tikai daļai no Sistēmas datiem. Kuriem datiem apskate auditējama ir jānosaka un ar Pasūtītāju jāsaskaņo prasību analīzes un sistēmas projektēšanas aktivitātes ietvaros. Par katru no lietotāja veiktajām darbībām jāuzglabā vismaz šāda informācija: 1. Darbības datums un laiks; 2. Lietotāja identitāte; 3. Darbības veids (pieslēgšanas sistēmai, atslēgšanās no sistēmas, ieraksta pievienošana, ieraksta labošana, utt.); 4. Darbības veidam specifisko informāciju: a. Pieslēgšanās un atslēgšanās |
Indekss | Prasības nosaukums | Prasība | Prasības realizācijas piedāvājums |
no Sistēmas darbībām darbstacijas identifikators (nosaukums un IP adrese); b. Lietotāja sesijas identifikators vai cits identifikators pēc kura iespējams unikāli identificēt konkrētu lietotāja sesiju; c. Datu apskates/pievienošanas/redi ģēšanas/dzēšanas darbībām saistītā datu objekta identifikators. Ja izveidotos lietotāju darbību auditācijas pierakstus nevar vienkārši analizēt, izmantojot tradicionālos līdzekļus, jānodrošina speciāli analīzes rīki. | |||
NFP-22 | Lietotāja tiesību izmaiņu auditācija | Sistēmā jāuzglabā un jāvar apskatīt informācija par visām lietotāju tiesību izmaiņām. Par katru izmaiņu jābūt apskatāmai vismaz šādai informācijai: 1. lietotāja vārds; 2. Administratora, kurš veicis izmaiņas, identitāte; 3. izmaiņu datums un laiks; 4. izmaiņu veids (pievienošana, rediģēšanas, dzēšana); 5. izmainītās un jaunās vērtības. | |
NFP-23 | Sistēmas notikumu auditācija | Sistēmai jānodrošina programmatūras kļūdu un izņēmumu situāciju (exceptions) auditācija. Programmatūras kļūdas un izņēmuma situācijas auditējamas vismaz šādos līmeņos: 1. Lietotāju saskarnes līmenī; 2. Biznesa procesu līmenī; 3. Tīmekļa servera līmenī; 4. Datu bāzu līmenī. Par katru no programmatūras kļūdām un izņēmumu situācijām saglabājama visa pieejamā ar kļūdu saistītā informācija. Sistēmai jānodrošina iespēja nosūtīt ziņojumu par kļūdām un izņēmuma situācijām sistēmas administratoram. | |
NFP-24 | Datu izmaiņu vēsture | Sistēmā ir jāuztur pilna datu izmaiņu vēsture, ja Pasūtītājs nav norādījis citādi.. Respektīvi, 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, |
Indekss | Prasības nosaukums | Prasība | Prasības realizācijas piedāvājums |
ārējā sistēma vai Sistēmas fona uzdevums); 2. Katru izmaiņu datums un laiks; 3. Ieraksta satura kopija pievienošanas/labošanas/dzēšana s brīdī. | |||
NFP-25 | Auditācijas pierakstu dzēš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 36 mēneši), pēc tam tos automātiski arhivējot un dzēšot. 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. |
Uzturamības prasības
Indekss | Prasības nosaukums | Prasība | Prasības realizācijas piedāvājums |
NFP-26 | Programmatūras pārnesamība | Ja Sistēma tiek veidota papildinot standartprodukta funkcionalitāti, papildinājumiem jābūt tā veidotiem, lai būtu iespējams bez Sistēmas izmaiņām Sistēmu pārnest uz jaunāku standartprodukta versiju. | |
NFP-27 | Koda vadības sistēma | Sistēmas izstrādes gaitā Izpildītājam jāizmanto datorizēta koda bibliotēka, kurai jānodrošina Pasūtītājam pieeja lasīšanas režīmā. |
Lietojamības prasības
Indekss | Prasības nosaukums | Prasība | Prasības realizācijas piedāvājums |
NFP-28 | WEB lietotāja saskarne | Sistēmas lietotāja saskarnei jābūt pieejamai, izmantojot WEB pārlūkprogrammu. Saskarnei jānodrošina iespēja izmantot vismaz šādas populāras pārlūkprogrammas darbam, sākot ar oprētējsistēmu Windows 7: 1. MS Edge; 2. Mozilla Firefox; 3. Google Chrome. Piedāvājumi, kuri piedāvās piekļuvi |
Indekss | Prasības nosaukums | Prasība | Prasības realizācijas piedāvājums |
lietotāja saskarnei no MS Internet Explorer un/vai Safari pārlūkprogrammām, saņems papildus punktus. | |||
NFP-29 | WEB lietotāja saskarnes atjauninājumi | Ne vēlāk, kā 30 (trīsdesmit) dienu laikā, skaitot no jaunas prasībā NFP- 28 norādītās pārlūkprogrammas jaunas versijas izlaišanas Izpildītājam jāpiegādā Sistēmas atjauninājumi, lai nodrošinātu sadarbspēju ar jaunāko pārlūkprogrammas versiju. | |
NFP-30 | Atbalstāmās lietotāju operētājsistēmas | Informācijas sistēmai ir jānodrošina lietotāju darbs vismaz Windows saimes (Windows 7, Windows 8, Windows 10) un Linux saimes operāciju sistēmās. | |
NFP-31 | Lietotāju saskarnes valoda | Sistēmas lietotāju saskarnei jābūt pieejamai latviešu valodā. Saskarnē izmantotajai valodai (vārdiem, frāzēm) jābūt intuitīvi saprotamai lietotājiem. Sistēmas administratoru saskarni var veidot latviešu vai angļu valodā, ja tas neapgrūtina Sistēmas lietošanu. | |
NFP-32 | Lietotāju saskarnes uztveramība | Sistēmai ir jāatbilst šādiem lietojamības kritērijiem: 1. Sistēmai ir jābūt saprotamai. Visiem lietotāja interfeisa elementiem (navigācijas elementiem, ikonām, spiedpogām, utt.) jābūt viegli uztveramiem un veidotiem atbilstoši industrijas labajai praksei. Sistēmā jāizmanto termini, kas sakrīt ar Pasūtītāja ikdienas darbā izmantojamajiem terminiem. Retāk izmantotajiem un sarežģītākajiem terminiem vai jēdzieniem jābūt skaidrojumiem. 2. Sistēmai ir jābūt viegli apgūstamai. Lietotāja palīdzības informācijai ir jābūt pilnīgai, konteksta jūtīgai un tai jāizskaidro kā paveikt tipiskos ikdienas uzdevumus. 3. Ar sistēmu ir jābūt viegli operēt. Sistēmai jābūt veidotai vienotā stilā. Saskarnes elementiem jādarbojas konsistenti visās Sistēmas 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 |
Indekss | Prasības nosaukums | Prasība | Prasības realizācijas piedāvājums |
brīdinājumi pirms neatgriezeniskās darbības. Sistēmas interfeisam jābūt veidotam 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. | |||
NFP-33 | Krāsu pielietojums lietotāja saskarnē | Lietotāja saskarnei jābūt veidotai, atbilstoši Pasūtītāja vizuālās identitātes vadlīnijās noteiktajai krāsu gammai: | |
Organizatoriskās prasības
Ieviešanas pieeja
Indekss | Prasības nosaukums | Prasība | Prasības realizācijas piedāvājums |
ORG-1 | Projekta ievadfāze | Projekta ievadfāzē (pirmā mēneša laikā, skaitot no iepirkuma līguma noslēgšanas) Izpildītājam jāveic sekojoši darbi: 1. Jāsaskaņo ar Pasūtītāju projekta pārvaldības plāns; 2. Jāsaskaņo ar Pasūtītāju Sistēmas arhitektūra; 3. Jāsaskaņo ar Pasūtītāju sākotnējais projekta uzkrājums un tā dalījums izstrādes sprintos. | |
ORG-2 | Sākotnējais projekta uzkrājums | Sākotnējais projekta uzkrājums sastāv no šajā Tehniskajā specifikācijā ietvertajām funkcionālajām prasībām. Atbilstoši piedāvātajai izstrādes pieejai Izpildī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ā. Sākotnējais projekta uzkrājums jādala izstrādes sprintos (sprinta uzkrājuma vienumos), ar nosacījumu, ka viens sprints nevar pārsniegt sešas nedēļas. | |
ORG-3 | Sprinta | Katru sprinta uzkrājuma vienumu |
Indekss | Prasības nosaukums | Prasība | Prasības realizācijas piedāvājums |
uzkrājuma vienums | raksturo Prasības apraksts, kas ir jārealizē. Vēlamā forma prasību izteikšanai ir t.s. «lietotāju stāsti», aprakstot: 1. lomu, kurai jānodrošina attiecīgā funkcionālā iespēja; 2. funkcionalitāti, kura jānodrošina; 3. biznesa vērtība, kas paskaidro, kāpēc lomai nepieciešama šī funkcionalitāte. Prasības aprakstam var tikt pievienoti papildus dokumenti, diagrammas, ekrānformu skices u.tml. artefakti; 4. Akceptēšanas kritēriji, kas kalpo akcepttestēšanas scenāriju izstrādei un definē sprinta pieņemšanas nosacījumus. | ||
ORG-4 | Sprinta plānošanas sanāksme | Katrs izstrādes sprints tiek uzsākts ar sprinta plānošanas sanāksmi, kurā piedalās Pasūtītāja projekta vadītājs un produkta īpašnieks (īpašnieki) un Izpildī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 (sprinta uzkrājums); 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). | |
ORG-5 | Sprinta sanāksmes | Sprinta sanāksmes jāparedz regulāri, ne retāk, kā reizi nedēļā. Sprinta sanāksmē piedalās Pasūtītāja produkta īpašnieks un Izpildītāja projekta komanda. Sprinta sanāksmē: 1. Izpildītājs demonstrē izstrādes progresu un priekšlikumus biznesa prasību realizācijai, atbilstoši fiksētajiem lietotāju stā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, tajā skaitā lietojamības uzlabojumiem; |
Indekss | Prasības nosaukums | Prasība | Prasības realizācijas piedāvājums |
4. Sprinta sanāksmes laikā tiek precizēti un saskaņoti lietotāju stāsti, kā arī katras realizējamās prasības akceptēšanas kritēriji. Sprinta sanāksmes protokolē Izpildītājs. Sprinta sanāksmes protokolus precizētu lietotāju stāstu un saskaņotu lietotāja saskarnes dizaina paraugu veidā saskaņo Produkta īpašnieks. | |||
ORG-6 | Sprinta pārskata sanāksme | Sprinta noslēgumā Izpildītājs organizē sprinta pārskata sanāksmi, kurā iepazīstina ar sprinta laikā izstrādāto funkcionalitāti. Sprinta noslēguma sanāksmē Izpildītājam ir jādemonstrē sistēmas darbība izstrādes vidē. | |
ORG-7 | Sprinta rezultātu piegāde | Izpildītājs piegādā ietvaros izstrādātās programmatūras piegādātās instalācijas pakotnes Pasūtītāja norādītam Infrastruktūras pārvaldniekam uzstādīšanai Pasūtītāja testa vidē atbilstoši pakotnē iekļautajai versijas izveides un uzstādīšanas instrukcijai. Izpildītājs nodrošina instalācijas atbalstu pēc Infrastruktūras pārvaldnieka pieprasījuma. Ja instalācija ir neveiksmīga un konstatētās problēmas nav novērstas 5 (piecu) darba dienu laikā, tālāka nodevuma akceptēšana tiek pārtraukta. | |
ORG-8 | 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 Izpildītāja izstrādes vidē); 2. Dokumentētam. |
Prasības nodevumiem
Indekss | Prasības nosaukums | Prasība | Prasības realizācijas piedāvājums |
ORG-9 | Projekta pārvaldības plāns | Projekta pārvaldības plānam jābūt izstrādātam atbilstoši spējās programmizstrādes metodikai. 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ā noteikto prasību apmierināšanai. Projekta pārvaldības plānā jāiekļauj |
Indekss | Prasības nosaukums | Prasība | Prasības realizācijas piedāvājums |
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. | |||
ORG-10 | Sistēmas arhitektūra | Sistēmas arhitektūras apraksts sagatavojams saskaņā ar standartu ISO/IEC/IEEE 42010:2011. Sistēmas 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); 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ā) 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). |
Prasības testēšanai
Indekss | Prasības nosaukums | Prasība | Prasības realizācijas piedāvājums |
ORG-11 | Izpildītāja testi | Lai nodrošinātu nodevumu atbilstību noteiktajām prasībām, Izpildītājam ir jāveic nodevumu iekšējā testēšana atbilstoši kādai no zināmajām testēšanas metodoloģijām, kā arī |
Indekss | Prasības nosaukums | Prasība | Prasības realizācijas piedāvājums |
jāsagatavo testēšanas dokumentācija. Izpildītājam jāveic vismaz šāda testēšana: 1. Funkcionālā testēšana (katrai sprinta piegādei); 2. Lietojamības testēšana (katrai sprinta piegādei); 3. Integrācijas testēšana (katrai Sistēmas versijas piegādei); 4. Veiktspējas un ātrdarbības testēšana (katrai Sistēmas versijas piegādei); 5. Pieejamības testēšana (katrai Sistēmas versijas piegādei); 6. Drošības testēšana (katrai Sistēmas versijas piegādei). Testēšanu Izpildītājam jāveic ar saviem resursiem, neiesaistot Pasūtītāju, pirms nodevuma iesniegšanas, lai pārliecinātos, ka nodevums ir gatavs akcepttestēšanai. Izpildītāja veiktās testēšanas dokumentācija ir jāiesniedz kopā ar programmatūras nodevumiem. | |||
ORG-12 | Funkcionālā testēšana | Funkcionālajai testēšanai jānosedz: 1. Datu apstrāde. Katrai datu apstrādes operācijai ir jābūt noklātai ar vismaz vienu testa scenāriju; 2. Lietotāja saskarne. Katrai lietotāja saskarnes vienībai ir jābūt noklātai ar vismaz vienu testa scenāriju. Testa scenārijiem jāparedz pozitīvie un negatīvie testu scenāriju rezultāti. | |
ORG-13 | Lietojamības testēšana | Sistēmas lietojamība testējama piesaistot Sistēmas gala lietotājus un novērojot to darbu ar sistēmu, lai identificētu lietojamības kļūdas un jomas kurās nepieciešami uzlabojumi. Lietojamības testēšana var tikt apvienota ar sprinta demonstrāciju. | |
ORG-14 | Integrācijas testēšana | Veicot integrācijas testēšanu, Izpildītājam ir jāpārbauda Sistēmas darbība kopumā, tai skaitā jāveic visas iepriekš piegādātās Sistēmas funkcionalitātes testēšana, ieskaitot to Sistēmas daļu atkārtoto testēšanu, kas netika modificētas, ar mērķi pārliecināties, ka veiktās modifikācijas nav negatīvi ietekmējušas līdz šim izstrādātās Sistēmas daļas. Sistēmu integrācijas testēšanas ietvaros |
Indekss | Prasības nosaukums | Prasība | Prasības realizācijas piedāvājums |
Izpildītājam jāpārbauda arī starpsistēmu datu apmaiņas saskarnes ar citām informācijas sistēmām, ar nosacījumu, ka šīs informācijas sistēmas ir pieejamas testu veikšanai. | |||
ORG-15 | Veiktspējas un ātrdarbības testēšana | Izpildītājam jāveic Sistēmas un to komponenšu veiktspējas testi, lai pārliecinātos par Sistēmas atbilstību tehniskajā specifikācijā noteiktajām veiktspējas prasībām, kā arī lai identificētu iespējamās problēmas un atrastu risinājumus Sistēmas ātrdarbības uzlabošanai. Veiktspējas testēšana jāveic Pasūtītāja testa vai apmācību vidē. Veiktspējas un ātrdarbības testi jāveic daudzlietotāju režīmā simulējot Sistēmas darbību šādos apstākļos: 1. Nominālas noslodzes apstākļos (šī testa ietvaros ir jāparāda, ka Sistēma var izpildīt noteiktās ātrdarbības prasības nominālas noslodzes apstākļos – ar nominālu noslodzi saprotot slodzi, kas ir līdzvērtīga slodzei produkcijas režīmā, tai skaitā produkcijas režīmā paredzamajiem pieprasījumu pīķiem, bet mērogota ņemot vērā infrastruktūras jaudas atšķirības starp testa un produkcijas vidi); 2. Maksimālas noslodzes apstākļos (pakāpeniski paaugstinot noslodzi, nosakot slieksni, kad veiktspējas prasības vairs netiek izpildītas vai arī līdz Sistēmas darbības atteicei). | |
ORG-16 | Pieejamības testēšana | Izpildītājam jānodrošina Sistēmas pieejamības testēšana. Sistēmas pieejamības testēšana Izpildītājam jāveic infrastruktūrā, kas ir tehnoloģiski un topoloģiski līdzīga Sistēmas produkcijas videi. Pieejamības testēšanas ietvaros jāpārbauda Sistēmas darbība pie šādiem scenārijiem: 1. Stabilitātes testēšana - šī testa ietvaros ir jāpārbauda Sistēmas darbības stabilitāte to ilgstoši darbinot pie dažādām noslodzēm, piemēram, nominālas noslodzes; 2. Noturības pret fizisko serveru |
Indekss | Prasības nosaukums | Prasība | Prasības realizācijas piedāvājums |
kļūdām – šī testa ietvaros jāpārbauda Sistēmas spēja saglabāt darbību simulējot atsevišķa fiziskā servera darbības pārtraukumu; 3. Noturība pret tīkla pārrāvumiem – šī testa ietvaros jāpārbauda Sistēmas spēja saglabāt darbību simulējot atsevišķa tīkla posma darbības pārtraukums; 4. Noturība pret programmatūras kļūdām – šī testa ietvaros jāpārbauda Sistēmas spēja saglabāt darbību simulējot programmatūras kļūdu atsevišķā pielietojumu vai datu bāzes serverī; 5. Datu rezerves kopēšana – šī testa ietvaros jāpārliecinās, ka iespējams izveidot Sistēmas rezerves kopiju un restaurēt Sistēmas darbību no izveidotās rezerves kopijas atbilstoši rezerves kopēšanas prasībām. | |||
ORG-17 | Drošības testēšana | Izpildītājam ir jāveic Sistēmas drošības testēšana ar mērķi pārbaudīt Sistēmas noturību pret nesankcionētu pieeju un cita veida uzbrukumiem, kā arī novērtēt Sistēmas atbilstību izvirzītajām drošības prasībām. Drošības testēšanu var veikt Pasūtītāja testa vidē. | |
ORG-18 | Testa datu nodrošināšana | Izpildītājam jāsagatavo, jāsaskaņo ar Pasūtītāju, un visu veidu Sistēmas testēšanā jāizmanto speciāla testa datu kopa, kas ir līdzvērtīga reālajiem datiem (biznesa datiem), bet nesatur identificējamu personu reālus datus. Izpildītājam tehniskajā piedāvājumā ir jāapraksta testa datu kopas ievadīšanas, papildināšanas, izņemšanas un atjaunošanas kārtība. |
Pieņemšanas procedūras
Indekss | Prasības nosaukums | Prasība | Prasības realizācijas piedāvājums |
ORG-19 | Sprinta piegādes nodevumi | Sprinta piegādes nodevumi ir: 1. Programmatūras versijas apraksts; 2. Sistēmas pirmkods (komentēts) un izpildkods; 3. Versijas izveides un uzstādīšanas |
Indekss | Prasības nosaukums | Prasība | Prasības realizācijas piedāvājums |
instrukcija, izmantojot izstrādes vides automātiskos būvējuma procesus; 4. Programmatūras prasību specifikācija lietotāju stāstu formā; 5. Sistēmas programmatūras projektējuma apraksts (dokuments apraksta tehnisko risinājumu, tajā skaitā integrācijas specifikāciju ar back-end un citām ārējām sistēmām, biznesa loģikas risinājumu un to sadarbību, datu modeli - iekšējās datu bāzes struktūru, iekļaujot detalizētu informāciju par visiem tās objektiem un to atribūtiem un vispārīgo aprakstu); 6. Lietotāju instrukcijas (kontekstjutīgu lietotāja palīgu) un administratoru rokasgrāmatu, papildinot tās saturu ar sprinta laikā veikto Sistēmas papildinājumu, izmaiņu un labojumu aprakstu. Uzsākot dokumentācijas izstrādi tās struktūra jāsaskaņo ar Pasūtītāju. Administratoru rokasgrāmatai jāiekļauj sistēmas rezerves kopēšanas un atjaunošanas instrukcijas. Dokumentācijai jābūt noformētai latviešu valodā; 7. Datu migrācijas skripti, ja versijas instalācija prasa izmaiņas datu bāzē; 8. Izpildītāja funkcionālo un lietojamības testu atskaite. | |||
ORG-22 | Sprinta pārbaude | 1. Laiks piegādāto sprinta nodevumu instalēšanai akcepttestēšanas vidē un sprinta akcepttestu izpildei tiek noteikts kā viena puse no sprinta garuma; 2. Pasūtītājs paziņo Izpildītājam par atklātajiem programmatūras defektiem, ja tādi ir, izmantojot Problēmpieteikumu vadības vidi; 3. Izpildītājam ir pienākums novērst akcepttestēšanas laikā konstatētos defektus laikā, kas nepārsniedz pusi no programmatūras izstrādes sprinta garuma un piegādāt labojumus. Labojumiem ir (a) jābūt |
Indekss | Prasības nosaukums | Prasība | Prasības realizācijas piedāvājums |
inkrementāli instalējamiem uz tekošajā sprintā piegādātās programmatūras un (b) 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ākošā sprinta nodevumos (b variants) un Pasūtītājs var nepieprasīt atsevišķu labojumu piegādi tekošajam sprintam (a variants), tomēr šāda vienošanās nav pienākums no Pasūtītāja puses; 4. Saņemot labotos programmatūras izstrādes nodevumus, Pasūtītājs veiks novērsto defektu pārbaudi , atkārtojot p.1.-3. aprakstīto procedūru. | |||
ORG-23 | Versijas piegādes nodevumi | Versijas piegāde satur konsolidētus un integrētus sprintu nodevumus, papildus pievienojot pārskatu par Izpildītāja veikto testēšanu atbilstoši visām prasībā ORG-11 norādītajām testu klasēm. | |
ORG-24 | Versijas akcepttestēšana | 1. Pasūtītājs veic Sistēmas akcepttestēšanu, veicot ORG-11 prasībā norādītos testus. Termiņš Sistēmas akcepttestēšanai ir 20 (divdesmit) kalendārās dienas; 2. Pasūtītājs paziņo Izpildītājam par atklātajiem programmatūras defektiem, ja tādi ir, izmantojot Problēmpieteikumu vadības vidi; 3. Izpildītājam ir tiesības novērst Sistēmas akcepttestēšanā atklātos trūkumus un piegādāt labojumus akcepttestēšanas laikā. Šādā gadījumā akcepttestēšana tiek pagarināta par 10 (desmit) darba dienām, skaitot no pēdējā atklātā trūkuma labojuma piegādes brīža; 4. Ja akcepttestēšanas laikā tiek atklātas 1. vai 2.prioritātes kļūdas, kuras nav iespējams operatīvi (t.i., vienas darba dienas laikā) novērst, akcepttestēšana tiek pārtraukta. | |
ORG-25 | Atkārtota akcepttestēšana | Pēc akcepttestēšanā atklāto kļūdu novēršanas un atkārtotas Izpildītāja testēšanas veikšanas Izpildītājs atkāroti piegādā Sistēmu |
Indekss | Prasības nosaukums | Prasība | Prasības realizācijas piedāvājums |
akcepttestēšanai. Atkārtota akcepttestēšana tiek veikta, atbilstoši Prasības ORG-24 noteikumiem. | |||
ORG-26 | Sistēmas akcepttestēšanas kritēriji | Sistēma tiks atzīta par atbilstošu ekspluatācijas uzsākšanai, ja izpildās visi šie noteikumi: 1. Akcepttestēšanas laikā nav atklāta neviena 1.-3. Prioritātes kļūda vai visas atklātās kļūdas ir novērstas un, atkārtoti testējot, tās nav izdevies atkārtot; 2. Sistēmā iemigrētie vēsturiskie dati ir korekti (ir iespējams iegūt identiskas atskaites par identiskiem laikaposmiem); 3. Piegādāti visi prasībās ORG-19 norādītie nodevumi un to saturs atbilst Tehniskās specifikācijas prasībām; 4. Visām 4.prioritātes kļūdām ir identificēts to cēlonis un saskaņots novēršanas termiņš. Pasūtītājs pēc saviem ieskatiem ir tiesīgs pieņemt Sistēmu arī ar nenovērstām 3.prioritātes kļūdām, ja ir identificēts to cēlonis un saskaņots novēršanas termiņš. |
Datu migrācija
Indekss | Prasības nosaukums | Prasība | Prasības realizācijas piedāvājums |
ORG-27 | Datu migrācija | Izpildītājam jānodrošina datu migrācija no vēsturiskās numerācijas datu bāzes. Uz Sistēmu migrējami visi vēsturiskie dati, kas ir saistīti ar Tehniskajā specifikācijā paredzēto funkcionalitāti vai nepieciešami Tehniskajā specifikācijā aprakstīto prasību izpildei. Datu migrācija veicama paralēli Sistēmas funkcionalitātes izstrādei vai kā pēdējais Sistēmas izstrādes sprints. | |
ORG-28 | Datu migrācijas aktivitātes | Datu migrācijas ietvaros Izpildī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 Sistēmas funkcionalitātei vai, kas kā savādāk nav piemēroti migrācijai. Informācija par kļūdainajiem |
Indekss | Prasības nosaukums | Prasība | Prasības realizācijas piedāvājums |
datiem jānodod Pasūtītājam, lai tas 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. Jāsagatavo datu migrācijas skripti un datu migrācijas instrukcijas; 4. Jāsagatavo datu migrācijas kvalitātes pārbaudes (skriptu veidā vai kā savādāk), kas ļauj pārliecināties par datu migrācijas kvalitatīvajiem un kvantitatīvajiem rezultātiem; 5. Jāsniedz Pasūtītājam konsultatīvs atbalsts datu migrācijas un datu migrācijas testēšanas laikā. Izpildītājam ir jāveic vēsturisko datu migrācija, bet Izpildītājs nav atbildīgs par pārņemamo vēsturisko datu līdzšinējo kvalitāti un Izpildītājam nav jāveic šo kvalitātes nepilnību labošana. | |||
ORG-29 | Prasības datu migrācijas procesam | Izpildītājam jānodrošina datu migrācijas procesa žurnalēšana. Migrācijas žurnālā jāizceļ datu konfliktsituācijas un migrācijas kļūdas. Datu migrācijas izpildes rezultātā tādu konstatēto konfliktsituāciju un kļūdu novēršanai, kur nepieciešama Pasūtītāja iesaiste, jāparedz vismaz 1 (viens) mēnesis sistēmas izstrādes/ieviešanas laikā. Datu migrācijas process sākotnēji testējams Pasūtītāja testa vidē. Ja datu migrācijas testi ir veiksmīgi, tad datu migrācija atkārtojama produkcijas vidē. Datu migrācija produkcijas vidē plānojama kontekstā ar Sistēmas ieviešanu produkcijā. Plānojot datu migrāciju Izpildītājam ir jāparedz arī atkāpšanās scenārijs, kurš izpildāms gadījumā, ja datu migrācija nav veiksmīga. |
Prasības ieviešanai
Indekss | Prasības nosaukums | Prasība | Prasības realizācijas piedāvājums |
ORG-30 | Sistēmas uzstādīšana produkcijas vidē | Pēc akcepttestēšanas pabeigšanas Pasūtītājs veiks Sistēmas programmatūras uzstādīšanu un |