Post on 20-Jan-2020
1
2.pielikums
Valsts ieņēmumu dienesta rīkotā atklāta
konkursa “IDM (Identity management
system) sistēmas piegāde, ieviešana un
uzturēšana”, iepirkuma identifikācijas
Nr. FM VID 2015/276 nolikumam
TEHNISKĀ SPECIFIKĀCIJA
atklātam konkursam “IdM (Identity management system) sistēmas iegāde, ieviešana
un uzturēšana”, iepirkuma identifikācijas Nr. FM VID 2015/276, (turpmāk –
Konkurss)
2
SATURS
1. Saīsinājumi un definīcijas ...................................................................................... 3
2. Vispārīgā informācija par iepirkuma priekšmetu .................................................. 5
2.1. Īss iepirkuma priekšmeta apraksts................................................................... 5
2.2. Īss esošās situācijas apraksts ........................................................................... 5
2.2.1. VID esošā infrastruktūra un standartprogrammatūra ............................... 5
2.2.2. Autoritatīvs identitāšu avots - Centralizētā resursu vadības sistēma
HORIZON.............................................................................................................. 6
2.2.3. Informācijas sistēmu izmaiņu pārvaldības sistēma – Remedy .............. 7
2.2.4. VID IS apraksts ........................................................................................ 8
3. Tehniskās prasības ............................................................................................... 10
4. Procesu shēmas .................................................................................................... 30
3
1. Saīsinājumi un definīcijas
1.1.tabula
Nr.p.k. Termins vai
saīsinājums Apraksts
1. Autoritatīvs
identitāšu avots
Datu avots, kas tiek definēts kā lietotāja elektroniskās
identitātes izcelsmes avots.
2. Darba plūsma Process, kas sastāv no viena vai vairākiem soļiem, kas
tiek izpildīti pēc iepriekš definēta algoritma
3. DBVS Datubāzes vadības sistēma
4.
RISINĀJUMS
Identitāšu pārvaldības sistēma, kas nodrošina lietotāju
kontu uzturēšanu dažādos IT resursos, balstoties uz
lietotāja identitātes dzīves cikla notikumiem.
5. IT resursa
aizbildnis
Ierēdnis vai darbinieks, kurš veic resursa lietotāju
piekļuves tiesību piešķiršanu, anulēšanu un uzskaiti
atbilstoši resursa īpašnieka lēmumiem
6.
IT resursa
īpašnieks
Ar Valsts ieņēmumu dienesta rīkojumu noteikts
ierēdnis vai darbinieks, kurš nosaka resursa drošības
prasības un apstiprina vai noraida lietotāju piekļuves
tiesību pieprasījumus
7. IT resursa
īpašnieka
pilnvarotā
persona
Pilnvarotā persona, kurai resursa īpašnieks var deleģēt
atsevišķus savus pienākumus
8. IT resursa
pieprasīšana
Pieprasījums izveidot lietotāja kontu vienā vai vairākos
IT resursos, kā rezultātā tiek uzsākta darba plūsmas
izpilde
9. IT resursa
piešķiršana
Lietotāja konta izveidošana pieprasītajā IT resursā kā
rezultātā lietotājam tiek piešķirtas piekļuves tiesības
(izveidots konts) minētajam resursam
10. IT resurss
Lietojums vai tehnoloģiju platforma, kurā tiek izveidoti
un uzturēti lietotāju konti
11. AD VID resursu direktorija, kas nodrošina lietotāju
autentificēšanos un autorizēšanos
12. IS Informācijas sistēma
13. Lomu komplekts Vienas vai vairāku informācijas sistēmu lietotāja
tiesību (darba vietu) kopa, kas nepieciešama attiecīgā
amata pamatpienākumu izpildei
14. Nodevums Katra pasūtījuma (darbu paketes) detalizēti noteikts
izpildāmo piegāžu un darbu saturs, sagaidāmie un
iesniedzamie rezultāti
15. Izpildītājs Pretendents, ar kuru tiks noslēgts līgums par
RISINĀJUMA ieviešanu
16. Pasūtītājs Valsts ieņēmumu dienests
17. VP Vienošanās protokols
Katrai tehniskajā specifikācijā definētai prasībai ir sekojoša struktūra:
Indekss – trīsciparu skaitlis, kas tehniskā specifikācijā apzīmē konkrētās prasības
kārtas numuru. Indeksu numerācija ir sakārtota augošā secībā sākot ar 001 un ļauj
4
viennozīmīgi identificēt katru konkrēto tehniskajā specifikācijā definēto prasību ar
mērķi atvieglot tehniskās specifikācijas lasīšanu un orientēšanos tajā (ātra
konkrētās prasības atrašana, tehniskās specifikācijas sasaite ar nolikumu u.tml.).
Prasības nosaukums – ir konkrētas prasības virsraksts, kas sniedz vispārīgu
informāciju par prasības saturu.
Prasības apraksts – ir konkrētās izpildāmās prasības apraksts, kas ir pietiekami
detalizēts, lai ļautu Pretendentam noteikt prasības realizācijas komplicētību,
tādējādi prognozēt nepieciešamo darbietilpību prasības un tehniskās specifikācijas
realizācijai kopumā, kā arī Pasūtītājam novērtēt Pretendenta tehniskā piedāvājuma
un piegādātā RISINĀJUMA atbilstību Konkursa nolikuma mērķiem un
uzdevumiem.
Apraksts, kurš saturēs prasības teksta kopiju vai tikai prasības izpildes apsolījumu,
būs pretrunā ar tehniskās specifikācijas prasībām, kā arī citu prasību realizācijas
piedāvājumu, netiks uzskatīts par atbilstošu, un šādi piedāvājumi tiks izslēgti no
vērtēšanas.
5
2. Vispārīgā informācija par iepirkuma priekšmetu
2.1. Īss iepirkuma priekšmeta apraksts
Identitātes pārvaldības sistēma (Identity Management system) ir aptverošs risinājums,
kurš apvieno cilvēkus, procesus, tehnoloģijas, sistēmu un drošības politikas, ļaujot
organizācijai pārvaldīt, autentificēt, pilnvarot un pārbaudīt savus informācijas
tehnoloģiju sistēmu lietotājus. Identitātes vadības risinājums ļauj rast atbildes tādiem
jautājumiem kā:
Kas tu esi par lietotāju?
Vai tiešām tu esi tas, par kuru uzdodies?
Kādām sistēmām un resursiem uzņēmumā tu vari piekļūt?
Kā tu piekļūsti šiem resursiem un sistēmām?
Kas piešķir šīs piekļuves tiesības?
Kā šīs tiesības var tikt mainītas?
Kā nepieciešamības gadījumā šo pieeju var pārtraukt?
Iepirkuma priekšmets – ir kvalitatīva un savlaicīga Identitātes pārvaldības risinājuma
(turpmāk – RISINĀJUMS) piegāde, ieviešana, pilnveidošana, uzturēšana un
garantijas nodrošināšana.
2.2. Īss esošās situācijas apraksts
2.2.1. VID esošā infrastruktūra un standartprogrammatūra
VID tiek izmantota šāda standartprogrammatūra:
2.1.tabula
Serveru
operētājsistēmas
1. AIX 5.3 vai jaunāka;
2. MS Windows Server 2008 R2, 2012 vai jaunāka;
3. Oracle Linux 6.0 vai jaunāka;
4. CentOS 6.0 vai jaunāka;
5. Solaris 11.2 vai jaunāka.
Virtualizācijas platforma Citrix XenServer 6.5 SP1 vai jaunāks.
Resursu direktorija
Microsoft Active directory
Tiek darbināta uz Windows 2012 R2 Standart
operētājsistēmas.
Viens fizisks serveris (primārais saits – lomas turētājs) un
divi virtuālie serveri. Virtualizācijā izmantots Citrix
XenServeri 6.5 SP1.
E-pasta sistēma Microsoft Exchange 2013 Enterprise
Tiek darbināta uz Windows 2012R2 Standart
operētājsistēmas.
Koplietošanas vietne
Sharepoint 2013
Tiek darbināta uz Windows 2012 R2 Standart
operētājsistēmas.
6
Izmanto MS SQL 2008R2 datubāzi.
Tiek darbināta uz Windows 2008 R2 Enterprise
operētājsistēmas.
2.2.2. Autoritatīvs identitāšu avots - Centralizētā resursu vadības
sistēma HORIZON
HORIZON ir integrēta programmatūras risinājuma saime. Tās pamata funkcionalitāte
nodrošina vienotu organizācijas vadības, finanšu un grāmatvedības informācijas
pārvaldību, t.sk. personāla pārvaldību.
Datu apmaiņa ar HORIZON notiek, izmantojot saskarnes procedūras, kas apvienotas
Oracle pakotnē PERS_INF. Ir pieejamas sekojošas PERS_INF procedūras:
PERSONAS: Procedūra paredzēta personāla informācijas iegūšanai no
HORIZON;
STATA_VIETAS: Procedūra paredzēta štata vietu informācijas iegūšanai no
HORIZON;
STR_VIENIBAS: Procedūra paredzēta struktūrvienību informācijas iegūšanai no
HORIZON;
attēls 2.1 HORIZON un klienta sistēmas datu apmaiņas struktūra
HORIZON Oracle datu bāzē atrodas speciāla shēma ar nosaukumu
APVINT_VIDAPL, kurā glabājas dažādas VID saskarņu Oracle pakotnes, t.sk. šajā
dokumentā aprakstītās saskarnes pakotne ar nosaukumu PERS_INF. Šī pakotne
nodrošinās HORIZON Oracle datu bāzē esošo VID personāla datu nodošanu klienta
sistēmām.
7
HORIZON dati glabājas atsevišķā Oracle shēmā. Saskarnes pakotnei ir pieeja šiem
datiem, tādējādi tā var nodrošināt datu nodošanu klienta sistēmām. Lai klienta sistēma
saņemtu datus, tai jāizsauc atbilstoša pakotnes procedūra.
Lai lietotu saskarni, nepieciešams ievērot sekojošus nosacījumus:
Saskarne ļauj darboties ar vienu konkrētu HORIZON organizāciju.
Jālieto Oracle datu bāzes servera versija 10.2.0.1.0 vai jaunāka.
Katrai klienta sistēmai tiek paredzēts vismaz viens speciāls Oracle lietotājs, ar kuru tā
varēs pieslēgties pie Horizon Oracle datu bāzes un izsaukt saskarnes procedūras.
Tiesības izsaukt šīs procedūras ir definētas Oracle lomā ROLE_APVINT_PERSINF.
Datu pārvietošanas process no Horizon var tikt organizēts, izmantojot faila eksportu,
jo Horizon sistēma nodrošina datu atgriešanu Oracle kursorā, kas nav pieejams citām
DB. Informācija par lietotājiem tiek glabāta skatu veidā. Ar HORIZON
dokumentāciju var iepazīties, ierodoties klātienē VID, jo šī dokumentācija ir
klasificēta kā „ierobežotas pieejamības” informācija.
2.2.3. Informācijas sistēmu izmaiņu pārvaldības sistēma – Remedy
VID informācijas sistēmu problēmu un izmaiņu pieteikumu apstrādes sistēma ir
bāzēta uz Remedy ARS 7.5 programmatūru, kas darbojas AIX 5.3 operētājsistēmas
vidē, izmantojot Informix 10 (turpmāk - Remedy). WWW saskarnei tiek izmantots
īpašs modulis MidTier 7.5. E-pasta sistēma darbojas uz Remedy Email Engine 7.5
bāzes. Pieteikumu reģistrācija notiek ar BMC Remedy User programmu vai
izmantojot WWW saskarni. Tālākais apstrādes process tiek realizēts ar BMC Remedy
User programmu palīdzību un e-pastu sūtīšanu.
Lietotājs
Remedy datu bāze
WWW serveris
E-pasta serveris
Remedy serveris Informix serveris
e-pasta klients
BMC Remedy User
BMC Remedy Developer Studio
WWW parlūkprogramma
attēls 2.2 VID informācijas sistēmu izmaiņu pārvaldības sistēmas shēma
Remedy ir realizēts lietotāju tiesību pārvaldības modulis, kas nodrošina elektronisko
tiesību pārvaldību (pieprasīšanu, saskaņošanu un uzskaiti). Katram IT resursam ir
nozīmēts resursa īpašnieks, kas nosaka resursa lietotāju pieejas tiesību principus
(kādas lietotāju grupas un ar kādām tiesībām) un apstiprina lietotāju piekļuves tiesību
pieprasījumus. Lietotāja tiešais vadītājs saskaņo lietotāja tiesību pieprasījumus
8
atbilstoši darba pienākumiem un uzdevumiem. Resursa aizbildnis veic resursa
lietotāju piekļuves tiesību piešķiršanu, anulēšanu un uzskaiti. Remedy nodrošina gan
tiesību pieprasīšanu pašapkalpošanās režīmā, gan automatizēto lietotāju tiesību
pieprasījumu (piešķiršana/anulēšana) ģenerēšanu, saskaņā ar struktūrvienību
izstrādātajiem un ar resursa īpašnieku apstiprinātiem lietotāju tiesību lomu
komplektiem un HORIZON datiem.
!!! Pēc VID IT resursu pārvaldības ieviešanas RISINĀJUMĀ (saskaņā ar (012)
prasību) lietotāju tiesību pārvaldība Remedy sistēmā nav paredzēta.
2.2.4. VID IS apraksts
VID darba funkciju nodrošināšanai tiek izmantoti 48 informācijas sistēmas (turpmāk
- IS), t.sk. 16 valsts IS. IS ir izstrādātas dažādos laika posmos un tajās izmantotas
tam laikam atbilstošākās tehnoloģijas, līdz ar to šobrīd sistēmās tiek izmantots ļoti
plašs tehnoloģiju klāsts. Būtiskāko VID IS apraksti pievienoti 4.pielikumā.
2.2.tabula
Lietotāju un lomu skaits1 VID IS
Nr.p.
k. VID IS
2
Lomu/
piekļuves
grupu
skaits
VID
lietotāji
Ārējie
lietotāji
Izmaiņu pieprasījumu
skaits 2015.gadā
Piešķiršana Anulēšana
1. ASIS 12 453
92 96
2. DIP 3 284
63 64
3. DNS 968 2395 724 2525 3280
4. DVS 33 4200
294 15
5. ĀLR (EDS) 15 556
491 401
6. EMCS NLP 23 521
100 164
7. EMDAS 44 1082 76 2491 1840
8. ESDSS 5 367
118 137
9. ESKORT 8 219
34 65
10. FPRAS 8 449
86 213
11. HORIZON 41 455
57 99
12. IAS 13 193
255 166
13. ITVS 5 364
366 3
14. KONDA 8 630
81 151
15. LAVIDAS 44 8
5 9
16. NIS 250 2990
6128 4900
17. NMAS 3 1986
331 352
18. Remedy 10 4247 46 177 361
19. VADIS 49 69 9 76 74
20. TLKAIS 16 519 183 108 110
21. KS 3 1631 4324 167
Kopā: 1561 23618 1038 18202 12667
1- VID un ārējo lietotāju skaits uz 08.01.2016.
2- VID IS nosaukumu atšifrējumi 4.pielikumā.
9
2.3. tabula
AD, Exchange kontu un grupu skaits
Sistēma Kontu skaits Grupu skaits Kontaktu skaits
MS Active Directory 4884 2627 862
MS Exchange 4686 623 783
2.4.tabula
Lietotāju, IT administratoru un tehnoloģisko kontu skaits
Pozīcija Skaits1
VID lietotāju (darbinieku) skaits 4328
Ārējo lietotāju skaits 1038
Tehnoloģisko kontu skaits 140
1- Lietotāju skaits uz 08.01.2016., skaits var dinamiski mainīties 5% ietvaros.
10
3. Tehniskās prasības
(001) Lietotāju un lomu administrēšana
1. RISINĀJUMĀ jābūt iespējai lietotājiem piekļūt, pārvaldīt un administrēt sava
profila datus.
2. RISINĀJUMĀ jābūt iespējai deleģēt grupu, organizāciju un resursu
administrēšanu noteiktiem lietotājiem vai lietotāju grupām.
3. Jānodrošina vienota lietotāju saskarne gan darba plūsmas apstiprinājumu
administrēšanai, gan pašapkalpošanās un deleģētās administrēšanas atbalstam.
4. RISINĀJUMA administratoriem jānodrošina iespēja definēt un pārvaldīt
privilēģiju grupas un lietotāju lomas.
5. RISINĀJUMAM jānodrošina iespēja lietotājam pašam atjaunot aizmirstās
paroles, izmantojot uzvedinošos jautājumus kā lietotāja autentifikācijas
(pārbaudes) mehānismu piekļuvei savam profilam.
(002) IT resursu pieprasījumi un darba plūsmas
1. Lietotājam jānodrošina iespēja pieprasīt IT resursus, izmantojot
pašapkalpošanās web saskarni.
2. Pieprasījuma rezultātā RISINĀJUMAM automātiski jāuzsāk pieprasītā IT
resursa darba plūsmas izpilde.
3. Jānodrošina iespēja veidot pieprasījumus, kas uzsāk izvēlēto IT resursu
piešķiršanu vairākiem lietotājiem vienlaicīgi.
4. Iespēja lietotājiem apskatīties savu pieprasījumu izpildes gaitu.
5. RISINĀJUMAM automātiski ir jānodrošina to pieprasījumu eskalācija, kuru
apstrāde nav pabeigta iepriekš definētā laikā.
6. RISINĀJUMAM jāatbalsta automātiska darba plūsmas izpildes uzsākšana pie
dažādiem notikumiem, piemēram, jauna lietotāja izveidošana autoritatīvā
identitāšu avotā.
7. RISINĀJUMAM jānodrošina iespēja definēt un izpildīt seriālas un paralēlas
darba plūsmas.
8. Darba plūsmas izpildes gaitā RISINĀJUMAM jānodrošina iespēja maršrutēt
pieprasījumus izskatīšanai un apstiprināšanai norādītiem lietotājiem, noteiktu
lietotāju grupu dalībniekiem vai arī lietotājiem ar noteiktām lomām.
9. Jānodrošina iespēja dinamiski mainīt darba plūsmas izpildes ceļu, balstoties uz
procesa starpsoļa rezultātiem.
10. Darba plūsmas ietvaros RISINĀJUMAM jānodrošina iespēja apstiprināt
pieprasījumu vairākiem lietotājiem vienlaicīgi gan secīgi, gan paralēli.
11. Uzsāktās darba plūsmas ietvaros lietotājiem, kas izskata un apstiprina
pieprasījumus, ir jābūt iespējai pieprasīt papildus informāciju no pieprasījuma
autora.
12. RISINĀJUMAM jānodrošina e-pasta ģenerēšana un nosūtīšana darba plūsmā
iesaistītajiem lietotājam, saskaņā ar darba plūsmas notikumiem.
13. RISINĀJUMAM jānodrošina grafiska lietotāju saskarne darba plūsmu
veidošanai un uzturēšanai, nepieprasot programmēšanu vai specifisku skriptu
izmantošanu.
11
(003) RISINĀJUMA likumi un politikas
1. RISINĀJUMAM jānodrošina iespēja definēt likumus (kritērijus) grupu vai
lomu piešķiršanai lietotājiem, darba plūsmas uzsākšanai un IT resursu
piešķiršanai.
2. RISINĀJUMAM ir jānodrošina grafiska saskarne likumu definēšanai,
izmantojot nosacījuma (Būla) izteiksmes.
3. RISINĀJUMAM jānodrošina iespēja definēt centralizētu paroļu veidošanas
politiku un to automātisku pārbaudi (ievērošanu).
4. RISINĀJUMAM jānodrošina iespēja definēt likumus, kas uzsāk apstrādi,
balstoties uz sistēmas notikumiem, piemēram, lietotāja profila atribūta
izmaiņas.
5. RISINĀJUMAM jānodrošina iespēja definēt likumus, kas uzsāk apstrādi,
balstoties uz noteiktu laiku vai laika intervālu.
(004) Lietotāja kontu pārvaldība
1. Lietotāju kontu pārvaldības (izveidošanas, uzturēšanas, dzēšanas) procesam
jātiek īstenotam kā darba plūsmai, kas definēta katram IT resursa tipam.
2. RISINĀJUMAM jānodrošina iespēja definēt likumus (nosacījumus) darba
plūsmas uzsākšanai un kontu izveidošanai vienā vai vairākos resursos.
3. RISINĀJUMAM jānodrošina jau sagatavotas darba plūsmas vismaz
sekojošiem IT resursu tipiem: Oracle DBVS, Microsoft Active Directory,
Microsoft Exchange, Microsoft SQL Server. Minētās darba plūsmas jāvar
mainīt un pielāgot.
4. RISINĀJUMAM jānodrošina grafiska lietotāju saskarne darba plūsmu
veidošanai un uzturēšanai, nepieprasot programmēšanu vai specifisku skriptu
izmantošanu.
(005) IT resursu integrācija
1. RISINĀJUMAM jānodrošina adapteri integrācijai ar vismaz sekojošām e-
pasta platformām: Microsoft Exchange 2013 vai jaunāks.
2. RISINĀJUMAM jānodrošina adapteri integrācijai ar vismaz sekojošām DBVS
platformām: Oracle 11g vai jaunāks, Microsoft SQL Server 2012 vai jaunāks
gan lietotāju, gan tabulu līmenī.
3. RISINĀJUMAM jānodrošina adapteri integrācijai ar vismaz sekojošiem
direktoriju serveriem: Microsoft Active Directory (2012).
4. RISINĀJUMAM jānodrošina adapteri integrācijai ar vismaz sekojošām OS
platformām: Oracle Linux 6.0 vai jaunāka, AIX 6.1 vai jaunāka, MS
Windows Server 2012 vai jaunāka, CentOS 6.0 vai jaunāka, Oracle Solaris
11.0 vai jaunāka.
5. RISINĀJUMAM jāatbalsta jaunu integrācijas adapteru izveidošana,
izmantojot grafisku saskarni.
6. RISINĀJUMAM jānodrošina autoratīva identitāšu avota automātisku
sinhronizēšanu ar RISINĀJUMA lietotāju repozitoriju, izmantojot
konfigurējamus likumus.
7. RISINĀJUMAM jānodrošina iespēja uzkrāt auditpierakstus par visiem
sinhronizācijas notikumiem.
8. RISINĀJUMAM ir jāspēj nodrošināt paroļu sinhronizācija starp visām un
jebkuru no pārvaldībā ietvertajām sistēmām.
12
(006) Sistēmas pārvaldība
Jābūt pieejamam rīkam, kas nodrošina konfigurācijas migrāciju starp izstrādes, testa
un produkcijas vidēm.
(007) Auditpierakstu uzkrāšana
1. RISINĀJUMAM jānodrošina automātiska auditpierakstu uzkrāšana par visiem
notikumiem ar lietotāju profiliem un saistītiem IT resursiem, neveicot
izmaiņas vai pielāgojumus.
2. Auditpierakstu glabāšanas ilgumam jābūt konfigurējamam.
3. Auditpierakstiem jābūt nosūtāmiem uz SIEM. VID rīcībā ir IBM Security
Qradar SIEM. VID jābūt iespējai noteikt, kuras žurnalēšanas datnes (log
failus) un kādā apjomā nosūtīt uz SIEM.
(008) Atskaišu pieejamība un audits
1. RISINĀJUMAM jānodrošina vienota grafiskā konsole atskaišu pārvaldībai.
2. RISINĀJUMAM jānodrošina atskaites, kas ļauj analizēt lietotāja pieejas
tiesības IT resursiem un saistīto darba plūsmu notikumus par jebkuru laika
intervālu.
3. RISINĀJUMAM jānodrošina iespēja ģenerēt atskaites, kas ļauj analizēt
sekojošas kopsakarības – kādi IT resursi (konti) ir piešķirti katram no
lietotājiem par noteiktu laika intervālu, uzrādot arī resursa piešķiršanas
pamatojumu.
4. RISINĀJUMAM jānodrošina iespēja izveidot specifiskas atskaites, izmantojot
atskaišu veidošanas rīku.
5. RISINĀJUMAM jānodrošina iebūvēta vide, kas ļauj veikt lietotāja pieejas
tiesību auditu (resertifikāciju), saskaņā ar šādām prasībām:
5.1. lietotāja pieejas tiesību atskaites sagatavošana gan pēc pieprasījuma, gan
norādītā laikā;
5.2. paziņojuma nosūtīšana norādītajam auditoram par atskaites pieejamību;
5.3. iespēja auditoram veikt pieejas tiesību pārbaudi, veicot atzīmi par katru no
lietotājiem – apstiprināts, noraidīts vai deleģēts pārbaudei citam auditoram;
5.4. jābūt iespējai uzsākt sistēmas darba plūsmas izpildi, saskaņā ar auditora
veiktajām atzīmēm;
5.5. nepieciešams nodrošināt izņēmumu resertifikācijas atbalstu, kur gadījumos,
kad lietotājam tiek piešķirta standarta loma un izņēmuma piekļuve,
resertifikācijai tiek pakļautas tikai piešķirtās izņēmuma piekļuves, standarta
lomu resertifikāciju veicot piekļuves līmenī;
5.6. iespēja saglabāt veiktā audita datus arhīvā un piekļūt tiem pēc vajadzības.
6. RISINĀJUMAM jānodrošina atskaišu un lietotāja pieejas tiesību audita
izpilde neatkarīgi no iesaistīto IT resursu pieejamības.
(009) RISINĀJUMA integrācija ar HORIZON
Jānodrošina autoritatīvo identitāšu datu izgūšana no Resursu vadības sistēmas
HORIZON (sistēmas apraksts 2.2.2.punktā) un integrēšana RISINĀJUMĀ. Jābūt
iespējai konfigurēt datu sinhronizēšanas intervālu (no Horizon datiem uz
RISINĀJUMU).
(010) RISINĀJUMA integrācija ar AD un Exchange
Jānodrošina RISINĀJUMA integrācija ar AD un Exchange:
13
1. VID lietotāju kontu pārvaldība (automātiskā konta izveidošana
jaunpieņemtajam VID darbiniekam, sākotnējas paroles ģenerēšana, konta
informācijas aktualizēšana, konta bloķēšana), balstoties uz HORIZON datiem
un saskaņā ar iepriekš definētiem pieejas noteikumiem.
2. VID struktūrvienību grupu pārvaldība (izveidošana, aktualizēšana,
likvidēšana), balstoties uz HORIZON datiem un saskaņā ar iepriekš
definētiem pieejas noteikumiem.
3. Kontu un grupu pārvaldība, saskaņā ar iepriekš definētiem pieejas
noteikumiem.
4. VID lietotāju e-pasta pārvaldība (automātiska e-pasta izveidošana un piesaiste
katrai identitātei, informācijas aktualizēšana, e-pasta bloķēšana), balstoties uz
HORIZON datiem un saskaņā ar iepriekš definētiem pieejas noteikumiem.
5. Struktūrvienību grupu E-pasta pārvaldība (izveidošana, aktualizēšana,
likvidēšana), balstoties uz HORIZON datiem un saskaņā ar iepriekš
definētiem pieejas noteikumiem.
6. E-pasta grupu pārvaldība, saskaņā ar iepriekš definētiem pieejas noteikumiem.
7. Koplietošanas pastkastu pārvaldība, saskaņā ar iepriekš definētiem pieejas
noteikumiem.
Procesu piemēri ir attēloti 4.punktā.
(011) RISINĀJUMA integrācija ar MS SharePoint
Jānodrošina piekļuves tiesību administrēšanu, balstoties uz lietotāja identitātes dzīves
cikla notikumiem, piemēram, darba attiecību uzsākšana, pārcelšana citā
struktūrvienībā, darba attiecību pārtraukšana, un iepriekš definētām pieejas
noteikumiem.
(012) VID IT resursu piekļuves tiesību (kontu) pārvaldība un darba plūsmu
konfigurēšana
1. Jāveic pašapkalpošanās portāla konfigurēšanu, nodrošinot, ka lietotājs var
pieprasīt sev nepieciešamās tiesības. Jāveic darba plūsmas konfigurēšanu, lai
tiesību pieprasījums tiek secīgi saskaņots ar vadītājiem, resursa īpašnieku vai
pilnvaroto personu un tiek nodots izpildei resursa aizbildnim.
2. Jānodrošina automātisko lietotāju tiesību pieprasījumu izpildi
(piešķiršanu/anulēšanu) VID IS, kurām lietotāju autorizācija notiek,
izmantojot Resursu direktoriju, balstoties uz resursa īpašnieku saskaņotiem
lietotāju tiesību lomu komplektiem.
3. Jānodrošina ārējo (citu organizāciju lietotāju, kuriem ir piekļuves tiesības VID
IS) lietotāju pārvaldību, nodrošināt darba plūsmas konfigurēšanu, lai tiesību
pieprasījums tiek saskaņots ar resursa īpašnieku un tiek nodots izpildei resursa
aizbildnim.
4. Jānodrošina automātisko lietotāju tiesību pieprasījumu (piešķiršanu/anulēšanu)
ģenerēšanu VID IS, balstoties uz struktūrvienību izstrādātajiem un ar resursa
īpašnieku saskaņotiem lietotāju tiesību lomu komplektiem.
5. Jānodrošina resursu īpašnieku un aizbildņu saraksta uzturēšana atbilstoši
3.1.tabulā norādītajai struktūrai. Resursa īpašnieka pilnvarotās personas vai
aizbildņu ilgstošas prombūtnes gadījumā (piemēram, atvaļinājums), resursu
14
īpašnieku sarakstā jānodrošina automātiska un/vai manuāla aizstāšana ar
pienākumu izpildītājiem.
3.1.tabula
Resursu īpašnieku un aizbildņu saraksta uzturēšana
IT resurss IT resursa
apgabals
Resursa
īpašnieks
Resursa īpašnieka
pilnvarotā persona Aizbildņi
NIS NUS Persona1
Persona3 Persona5
…
Persona n+1
Jānodrošina, ka pilnvarotajam personām var norādīt aizvietotājus.
Jābūt iespējai katram resursam noteikt vairākus aizbildņus – DB administratoru,
lietotāju tiesību administratoru, lietojuma administratoru, servera administratoru u.c
(pēc nepieciešamības).
Jābūt iespējai noteikt primāro resursa aizbildni un aizvietotāju.
Jākonfigurē darba plūsmas, kas nodrošina IT resursu īpašnieku, pilnvaroto
personu par tiesību apstiprināšanu un aizbildņu sarakstu veidošanu, uzturēšanu un
aktualizēšanu.
6. Jānodrošina lomu komplektu uzturēšana atbilstoši 3.2.tabulā norādītajai
struktūrai.
3.2.tabula
Lomu komplektu uzturēšanas struktūra
Iestāde
s kods
*
Iestādes
nosauku
ms *
Struktūr
vienības
kods*
Struktūrvienī
bas pilnais
nosaukums*
Amats
* IS
Loma/
piekļuves
grupa
Sākuma
datums
Beigu
datu
ms
CA/29. NP
CA/29.5
8.
NP
Informācijas
sistēmu
atbalsta daļa vadītājs NMAS
Veidot un/
vai atbildēt
CA/29. NP
CA/29.5
8.
NP
Informācijas
sistēmu
atbalsta daļa vadītājs NMAS
NMAS
pārvaldnie
ks
* no HORIZON datiem
RISINĀJUMAM jānodrošina lomu komplektu uzturēšana visā tā dzīves cikla laikā,
tajā skaitā:
- izmaiņu versiju uzturēšanu un darba plūsmas atbalsts izmaiņu apstiprināšanai;
- metadatu uzturēšanu;
- lomu izmaiņu simulācijas iespēja (“what if”).
(013) Tehnoloģisko lietotāju pārvaldība
1. Lietotājam jānodrošina iespēja pieprasīt izveidot, dzēst vai labot tehnoloģisko
lietotāju (konts, kas tiek izmantots IS darbības nodrošināšanai (system-to-
system)) , izmantojot pašapkalpošanās web saskarni.
15
2. Pieprasījuma rezultātā RISINĀJUMAM automātiski jāuzsāk pieprasītā
tehnoloģiskā lietotāja darba plūsmas izpilde.
3. Uzsāktās darba plūsmas ietvaros lietotājiem, kas izskata un apstiprina
pieprasījumus (tiešais vadītājs, resursa īpašnieks, resursa aizbildnis), ir jābūt
iespējai pieprasīt papildus informāciju no pieprasījuma autora.
4. RISINĀJUMAM jānodrošina e-pasta ģenerēšana un nosūtīšana darba plūsmā
iesaistītajiem lietotājam, balstoties uz darba plūsmas notikumiem.
5. Iespēja lietotājiem apskatīties savu pieprasījumu izpildes gaitu.
6. Noteiktā laika periodā (ne retāk kā reizi gadā) RISINĀJUMAM jāizsūta e-
pasts tehnoloģisko lietotāju aizbildņiem ar pilnu sarakstu par atbildībā esošiem
tehnoloģiskajiem lietotājiem un to grupām ar lūgumu izskatīt atbilstību
aktuālajai situācijai.
7. Jānodrošina iespēja tehnoloģisko lietotāju aizbildņiem apskatīt pilnu savā
atbildībā esošo tehnoloģisko lietotāju un to grupu sarakstu WEB vietnē un
veikt tajā pieprasījumus dzēst vai labot atbilstoši aktuālajai situācijai.
8. RISINĀJUMAM jānodrošina automātiska auditpierakstu uzkrāšana par visiem
notikumiem ar tehnoloģisko lietotāju profiliem neveicot tajos izmaiņas.
(014) Tehnoloģiskā platforma
Piedāvātajam risinājumam jāizmanto tehnoloģijas un izstrādes rīki, nodrošinot, ka
izmantotās tehnoloģijas tiks uzturētas (kļūdu un drošības ievainojamību novēršana
esošajās versijās, kā arī jaunu versiju izstrādāšana) vismaz 5 gadus no to izstrādātāju
puses.
(015) Arhitektūras prasības
Pretendentam netiek uzstādīti ierobežojumi RISINĀJUMA arhitektūras izvēlē, taču
tai jāspēj sadarboties ar RISINĀJUMĀ integrējamajām VID rīcībā esošajām IS,
atbilstoši šīs tehniskās specifikācijas prasībai (005).
(016) Infrastruktūras prasības
Pretendentam netiek uzstādīti ierobežojumi tehniskās platformas izvēlē, taču tai jāspēj
sadarboties ar VID rīcībā esošo infrastruktūru.
Tehniskajā risinājumā var izmantot:
1. Esošo VID infrastruktūru, t.sk. datu pārraides tīklu un serverus.
2. VID RISINĀJUMA darbināšanai nodrošina:
2.1. divus asmenserverus Dell PowerEdge m620 (uzstādīti asmeņserveru šasijā),
katram serverim ir divi 8 kodolu procesori, 192GB RAM, kā arī divi 1Gbps
LAN tīkla pieslēgumi un divi 8Gpbs Fibre channel SAN tīkla pieslēgumi.
Katrs serveris ir aprīkots ar vienu cieto disku 250GB 7,2rpm SATA.
2.2. gadījumā, ja kā serveru virtualizācijas platforma tiks izmantota pasūtītāja
rīcībā esošā Citrix XenServer 6.5. platforma, virtuālie serveri var tikt izvietoti
uz Cisco UCSB-B200-M3 serveriem, izdalot šādus resursus: RAM - 128GB,
40 CPU. Ja 3.apakšpunktā minētie datu glabāšanas apjomi tiks izmantoti
virtuālajiem serveriem, loģiskie diski, kas lielāki par 150GB, virtuālajam
serverim jāpieslēdz, izmantojot iSCSI protokolu.
3. Datu glabāšanai VID nodrošina 500GB disku apjomu RAID5 disku masīva grupā
ar 10000 rpm diskiem vai 1TB disku apjomu RAID6 disku masīva grupā ar 7200
rpm diskiem FC SAN disku masīva iekārtā.
16
4. Datubāzes nodrošināšanai VID ir iespējams izdalīt sekojošus Oracle SuperCluster
resursus: RAM – 32 GB, HDD – 250GB un CPU – dalītus 14 kodolus T5-8 SUN
SPARC.
5. Gadījumā, ja tiks izmantoti VID norādītie resursi, Pretendenta RISINĀJUMAM
jābūt darbināmam virtuālajā vidē:
5.1. izmantojot pasūtītāja rīcībā esošo Citrix XenServer 6.5 (vai jaunāks)
virtualizācijas platformu;
5.2. izmantojot VMware vSphere Enterprise Plus virtualizācijas platformu,
piedāvājumā jāiekļauj visas nepieciešamās licences 3 fizisko serveru (6
procesoru) virtualizācijas platformas ražotāja atbalsta nodrošināšanai visā
līguma darbības periodā;
5.3. Pretendentam jāiesniedz apliecinājums, ka piedāvātais Risinājums
uzstādāms un darbināms izvēlētajā virtualizācijas platformā.
6. Gadījumā, ja (016) prasības 2. – 4. apakšpunktos norādītie resursi nav piemēroti
vai nav pietiekami Pretendenta piedāvātajam risinājumam, Pretendentam
jānodrošina un piedāvājumā jāiekļauj risinājumam nepieciešamo
aparatūru/iekārtas (turpmāk – iekārtas). Piedāvātās iekārtas detalizēti jāapraksta
tehniskajā piedāvājumā un kā atsevišķas pozīcijas jāiekļauj Finanšu piedāvājuma
1.3. apakšpunktā. Pretendentam piedāvājumam jāpievieno ražotāja apliecinājums
vai cits līdzvērtīgs dokuments par to, ka piedāvāto iekārtu ražotājs nodrošina šo
iekārtu garantijas un uzturēšanas nodrošināšanas pakalpojumu 3 (trīs) kalendāro
gadu laikā, skaitot no attiecīgā nodošanas-pieņemšanas akta abpusējas
parakstīšanas dienas.
(017) Standartprogrammatūras prasības
Gadījumā, ja piedāvātā RISINĀJUMA darbināšanai (t.sk. testa vidē)
nepieciešamas trešo pušu programmatūras licences, kuras nav VID rīcībā,
Pretendentam šo licenču cena jāiekļauj Finanšu piedāvājuma 1.2. apakšpunktā, kā arī
5. punktā norādot šo licenču uzturēšanas izmaksas par 3 (trīs) gadiem (jauninājumi,
labojumi u.c.).
Pretendentam piedāvājumam jāpievieno ražotāja apliecinājums vai cits
līdzvērtīgs dokuments par to, ka piedāvātās trešo pušu standartprogrammatūras
ražotājs nodrošina šīs standartprogrammatūras uzturēšanas pakalpojumu 3 (trīs)
kalendāro gadu laikā, skaitot no attiecīgā nodošanas-pieņemšanas akta abpusējas
parakstīšanas dienas. Pasūtītāja rīcībā esošā standartprogrammatūra uzskaitīta
3.3.tabulā.
3.3.tabula
Pasūtītāja rīcībā esošā standartprogrammatūra
datu bāzu vadības sistēmas 1. Oracle 12c vai jaunāka, vai
2. Microsoft SQL 2012 vai jaunāka.
serveru operētājsistēmas 1. Solaris 11.2 vai jaunāka;
2. MS Windows 2012 R2 Server vai jaunāka;
3. Oracle Linux 6.7 vai jaunāka;
4. CentOS 7.1 vai jaunāka.
virtualizācijas platforma Citrix XenServer 6.5 vai jaunāka.
17
(018) Risinājuma izmitināšanas minimālie tehniskie resursi
Risinājuma akcepttestēšanas un produkcijas vides izmitināšanu un apkalpošanu
nodrošinās Pasūtītājs. Testa vide tiks veidota tehnoloģiski identiski produkcijas videi
un testa vidi izmantos 20 VID darbinieki. Izpildītājam ir jānodrošina nepieciešamais
Pasūtītāja darbinieku atbalsts testa vides izveidošanai pasūtītāja pusē. Risinājuma
izstrādes vides izmitināšanu un apkalpošanu nodrošinās Izpildītājs.
(019) 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ītajam izstrāde jāveic,
izmantojot tikai licencētu programmatūru. Pasūtītājs nenodrošina Izpildītāju ar
licencēm. Izpildītājs nedrīkst izmantot programmēšanas rīkus vai līdzekļus, kas
prasītu papildu licenču iegādi Pasūtītājam pēc programmatūras izvēršanas.
Pretendentam piedāvājumā ir jāapraksta, kā tiks nodrošināta projekta projektēšanas un
izstrādes vide, tajā skaitā projekta bibliotēka projekta dokumentācijas uzglabāšanai,
vide projekta nodevumu izstrādei, vide Izpildītāja testu veikšanai.
(020) Risinājuma piegāde un uzstādīšana
Pēc programmatūras nodevuma saņemšanas Pasūtītājs veiks Risinājuma
programmatūras uzstādīšanu un konfigurēšanu akcepttesta vidē. Izpildītājam ir
jānodrošina nepieciešamais Pasūtītāja darbinieku atbalsts Risinājuma programmatūras
uzstādīšanas un konfigurēšanas akcepttesta vidē laikā.
Pēc akcepttestēšanas pabeigšanas Pasūtītājs veiks Risinājuma 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, kā arī jānodrošina
nepieciešamais Pasūtītāja darbinieku atbalsts Risinājuma uzstādīšanas un
konfigurēšanas produkcijas vidē laikā.
Pēc programmatūras uzstādīšanas produkcijas vidē tiks veikta atkārtota
programmatūras 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ē.
Testus veiks Pasūtītājs vai Pasūtītāja deleģēta trešā puse.
Programmatūras ieviešana produkcijas vidē tiek uzskatīta par pabeigtu, ja
programmatūras pārbaudes laikā produkcijas vidē netiek konstatētas 1., 2. vai 3.
klases problēmas (problēmu prioritātes klases aprakstītas līguma projekta
0.3.0.pielikumā).
(021) Prasības iesniedzamajiem Nodevumiem un dokumentācijai
1. Visi Nodevumi Izpildītājam ir jāpiegādā saskaņā ar līguma projekta 5. un
6.punktu un līguma projekta 0.1.0.pielikumā aprakstīto sadarbības kārtību.
Programmatūras nodevums jāpiegādā uzstādīšanai gan Pasūtītāja testa vidē, gan
Pasūtītāja produkcijas vidē, ar norādi par programmatūras nodevuma instalēšanas
paketes uzstādīšanas vidi, ja tehniski nav iespējams piegādāt programmatūras
nodevuma instalēšanas paketi, kas izmantojama abās vidēs. Programmatūras
instalēšanas paketei jābūt “inkrementālai” t.i. tās uzstādīšana ir veicama uz
iepriekš piegādātas versijas. Programmatūras nodevumi nedrīkst ietekmēt datu
bāzē jau esošos datus, ja vien tas nav iepriekš īpaši saskaņots vai nav nodevumu
objekts. Gadījumos, ja tiek mainīta datu bāzes struktūra, jāpiegādā arī atbilstošie
18
datu migrācijas skripti. Visiem nodevumiem ir jānodrošina versiju identifikācija
un kontrole.
2. Izpildītājam RISINĀJUMA ieviešanas projekta laikā jāizstrādā un jāiesniedz VID
vismaz šādi dokumenti:
2.1. Projekta pārvaldības plāns (tajā skaitā projekta laika grafiks un projekta
kvalitātes nodrošināšanas plāns);
2.2. RISINĀJUMA arhitektūras apraksts (tajā skaitā RISINĀJUMA loģiskā un
fiziskā arhitektūra un to komponenšu apraksts);
2.3. RISINĀJUMA projektējums;
2.4. RISINĀJUMA testēšanas dokumentācija (tajā skaitā testēšanas plāns,
testpiemēru specifikācija, testēšanas kopsavilkuma pārskats un testu
protokoli);
2.5. RISINĀJUMA lietotāja dokumentācija (tajā skaitā administratora
rokasgrāmata un RISINĀJUMA lietošanas instrukcija);
2.6. RISINĀJUMA instalēšanas/uzstādīšanas instrukcija;
2.7. RISINĀJUMA darbības uzraudzības instrukcija un darbības atjaunošanas
plāns;
2.8. jebkāda cita dokumentācija, kas tiek radīta un būtiski ietekmē RISINĀJUMA
ieviešanu vai tās turpmāku ekspluatāciju.
3. Visi projekta dokumenti jāsagatavo latviešu valodā;
4. Izpildītājam, nepieprasot papildus samaksu, jānodrošina projekta dokumentu
aktualizēšana un atkārtota iesniegšana Pasūtītājam, ja projekta laikā ir veiktas
izmaiņas;
5. Projektu dokumentu saraksts var tikt precizēts projekta gaitā un ir iespējams
apvienot vai izstrādāt papildus projekta dokumentus, saskaņojot ar VID.
(022) Atbilstība standartiem
Izpildītājam ir jāveic darbi un jāpiegādā šajā specifikācijā nosauktie Nodevumi
saskaņā ar šīs specifikācijas prasībām, iepirkuma nosacījumiem, Latvijas Republikas
normatīvo aktu un Eiropas Komisijas direktīvu prasībām, Latvijas Republikas un
starptautiskajiem programmatūras izstrādes standartiem.
Piedāvātā RISINĀJUMA ieviešanas, pielāgošanas un konfigurēšanas gaitā jāizmanto
3.4.tabulā norādītie standarti.;
3.4.tabula
Izmantojamie standarti
Nr.p.
k. Nodevums Atbilstība Paskaidrojums
1.
RISINĀJUMA
programmatūras
konceptuālā arhitektūra
ISO/IEC/IEEE
42010
RISINĀJUMA programmatūras
konceptuālā arhitektūra ir augsta līmeņa
dokuments, kas specificē RISINĀJUMA
galvenās komponentes, iekšējās un
ārējās saskarnes, satur vadošu
informāciju RISINĀJUMA
projektēšanai un pilnveidošanai,
apraksta izmantojamās tehnoloģijas,
izstrādes rīkus un vidi.
2.
Darbu izpildes plāns -
Darbu izpildes plāns jāveido atbilstoši
spirāles izstrādes metodoloģijai. Darbi ir
jāsadala izpildes kārtās, abpusēji
saskaņojot darbu izpildes prioritātes.
3. Projekta plānošanas dokumenti
19
3.1.
Projekta
pārvaldības plāns LVS 67:1996
Projekta pārvaldības plānā jānosaka
projekta tehniskās un pārvaldības
funkcijas, pasākumi un uzdevumi, kas
nepieciešami, lai izpildītu Līgumā
noteiktās prasības.
3.2.
Programmatūras
(kvalifikācijas)
testēšanas plāns
LVS 70:1996;
IEEE/EIA J-STD-
016 (E.2.2.)
Programmatūras testēšanas plānā ir
jānorāda projekta izstrādes laikā
veicamo testēšanas pasākumu plāns, kā
arī jāapraksta šo pasākumu darbības
sfēra, izvēlētā pieeja, resursi u.c.
Jāidentificē testējamie vienumi,
raksturiezīmes, kuras jātestē, testēšanas
uzdevumi, kas jāizpilda, un risks, kurš ir
saistīts ar plānu.
3.3.
Programmatūras
instalēšanas plāns
IEEE/EIA J-STD-
016 (E.2.3.)
Programmatūras instalēšanas plānā
jāparedz aparatūras un programmatūras
sagatavošana, lietotāju apmācīšana, kā
arī visi citi pasākumi, kuri nepieciešami,
lai lietotāji varētu sākt darbināt
RISINĀJUMU.
4. Projekta specifikācijas
4.1.
Programmatūras
prasību
specifikācija
LVS 68:1996;
IEEE/EIA J-STD-
016 (F.2.2., F.2.4.)
Programmatūras prasību specifikācijā
tiek aprakstītas detalizētas prasības
katram RISINĀJUMA programmatūras
vienumam un tas ir galvenais
dokuments, atbilstībā pret kuru
turpmākā projekta izstrādes gaitā tiek
veikta RISINĀJUMA testēšana un
pieņemšana.
4.2.
Saskarņu prasību
specifikācija
LVS 72:1996;
EIA/IEEE J-STD-
016 (F.2.3.)
Saskarņu prasību specifikācijā
jāapraksta prasības, kas tiek izvirzītas
sistēmai, apakšsistēmām, aparatūrai,
programmatūrai, lietotāja izdarītajām
darbībām vai citām sistēmas
komponentēm, lai īstenotu prasīto
sadarbību starp šīm komponentēm.
4.3.
Programmatūras versijas
apraksts
IEEE/EIA J-STD-
016 (1.2.2.)
Programmatūras versijas apraksta
galvenais uzdevums ir sniegt lietotājam
precīzu informāciju par konkrēto
RISINĀJUMA versiju, kura ir izstrādāta
kārtējo izmaiņu rezultātā, atbilstoši
konkrētai RISINĀJUMA lietošanas
vietai u.tml. Versijas aprakstā ir precīzi
jāuzskaita visi elementi, kuri ietilpst šīs
versijas sastāvā (dokumenti,
programmas utt), norādot katra elementa
identifikatoru, laidienu u.c. informāciju;
jāapraksta šīs versijas būtiskās atšķirības
no iepriekšējās versijas; datu īpatnības,
kā arī jādod visa cita tikai šai versijai
unikālā informācija.
5. Projektējumu dokumentācija
5.1. PPA, ieskaitot saskarņu
projektējuma aprakstu
LVS 72:1996;
IEEE/EIA J-STD-
PPA jāietver gan RISINĀJUMA
programmatūras, gan saskarņu, gan datu
20
un datu bāzu
projektējuma aprakstu
016 (G.2.2., G.2.3.,
G.2.4.)
bāzu projektējuma aprakstu. PPA
pārbauda atbilstībā pret prasību
specifikāciju. PPA jāapraksta gan
loģiskais, gan fiziskais RISINĀJUMA
programmatūras projektējums.
Loģiskajā projektējumā ir jābūt
aprakstītiem visiem programmatūras
vienumiem, to nozīmei, funkcionalitātei
un savstarpējai mijiedarbībai. Fiziskajā
projektējumā detalizē, kā plānotā
programmatūras funkcionalitāte un citas
prasību specifikācijā ietvertās prasības
tiks realizētas. Saskarņu projektējuma
aprakstā jāapraksta sistēmu,
apakšsistēmu, aparatūras,
programmatūras, lietotāja iedarbību un
citu sistēmas komponentu savstarpējā
sadarbība.
Datu bāzu projektējuma aprakstam
jāsatur informācija par datu bāzu
struktūru, datu bāzes elementu
funkcionālo saturu, saistīto
programmatūru, informācija par
prasībām, kas noteiktas datu bāzei un tās
elementiem, kā, piemēram, drošība,
integritāte u.c, kā arī jebkura cita veida
informācija, kas nepieciešama datu
pārbaudei, modificēšanai u.tml.
6. Ieviešanas dokumentācija
6.1.
Programmatūras
pirmkodi1
IEEE/EIA J-STD-
016 (G.2.1.)
Programmatūras pirmkodi ir programmu
teksti, kas izpildīti izvēlētās realizācijas
apkārtnes noteiktā veidā (piemēram,
konkrētā programmēšanas valodā).
6.2.
Programmatūras
izpildkodi (ja
iespējams
instalācijas pakotnes)
IEEE/EIA J-STD-
016 (1.2.1.)
Programmatūras izpildkods ir jāpiegādā
instalācijas pakotnēs, kas ļauj to uzstādīt
testēšanas vai produkcijas vidē atbilstoši
administratora rokasgrāmatai un citai
dokumentācijai.
Kopā ar programmatūras izpildkodu ir
jāpiegādā arī konfigurācijas skripti vai
datnes, kas nepieciešamas
programmatūras darbināšanai.
7. Lietotāja dokumentācija
7.1.
Programmatūras
lietotāja
rokasgrāmata
LVS 66:1996;
IEEE/EIA J-STD-
016 (J.2.1.)
Programmatūras lietotāja rokasgrāmatai
ir jānodrošina nepieciešamais
informācijas līmenis, kas nepieciešams
RISINĀJUMA programmatūras
lietotājiem, lai varētu izmantot
RISINĀJUMA programmatūru.
Programmatūras lietotāja rokasgrāmatai
ir jābūt izstrādātai veidā, kas ir
piemērots izmantošanai gan drukātā, gan
tiešsaistes formā.
Programmatūras IEEE/EIA J-STD- Programmatūras uzturēšanas
21
uzturēšanas
rokasgrāmatas
016 (5.13.8.) rokasgrāmatas nolūks ir nodrošināt to
RISINĀJUMA programmatūras
uzturēšanai nepieciešamo informāciju,
kura nav atrodama PPA vai kādā citā
projekta gaitā izstrādātā dokumentā.
7.2.
Programmatūras
instalēšanas
instrukcija
IEEE/EIA J-STD-
016 (1.2.2.)
Aprakstā jāietver konkrētās produkta
versijas instalēšanas instrukcijas,
nepieciešamā apkārtne (environment),
personāla apmācīšana, kā arī jebkura
cita informācija, kas nepieciešama, lai
programmatūru sagatavotu darbināšanai.
7.3.
Programmatūras
administratora
rokasgrāmata
LVS 66:1996;
IEEE/EIA J-STD-
016 (J.2.4.)
Programmatūras administratora
rokasgrāmatai ir jāietver vismaz tādi
aspekti kā programmatūras instalācija,
konfigurēšana, lietotāju administrēšana,
programmatūras rezerves kopiju
veikšana, atjaunošana, nepārtrauktības
nodrošināšana, regulārie ikdienas
uzdevumi (piemēram audita ierakstu
kontrole un arhivēšana), problēmu
identificēšana, programmatūras
veiktspējas un kapacitātes monitorēšana
u.c. Piezīme: papildus Izpildītāja
izstrādātajai programmatūras
administratora rokasgrāmatai ir
jāpiegādā arī oriģinālās trešās puses
programmatūras dokumentācija, kas ir
iekļauta programmatūrā (kura tiek
piegādāta RISINĀJUMA izveidošanas
ietvaros).
7.4.
Programmatūras
integrācijas
instrukcijas
Atbilstoši ārējo
programmatūras
saskarņu
projektējumiem
Instrukcija ir jāveido katrai
RISINĀJUMA komponentei, kas var
tikt integrēta citās VID IS, piemēram,
autentifikācijas modulis, integrācijas
servisi, u.c.
Programmatūras integrācijas instrukcijai
ir jāsatur pietiekoša informācija, lai citu
IS izstrādātāji varētu izstrādāt saskarnes
sadarbībai ar RISINĀJUMA
programmatūru. Programmatūras
integrācijas instrukcijai ir jāsatur
atbilstoši piemēri un to apraksti
paredzēto darbību veikšanai.
8. Testēšanas dokumentācija
8.1.
Testu projektējuma un
testpiemēru
specifikācija
LVS 70:1996;
IEEE 829
Testu projektējuma specifikācijā
jāapraksta programmatūras pazīmju vai
to kombināciju testēšanas pieejas detaļas
un jāidentificē atbilstošie testi un
jāapraksta katrs testpiemērs. 1 – neattiecas uz standartprogrammatūru.
Ja Pretendents izmanto citus standartus, tad Pretendentam ir jānorāda, kādus
standartus paredzēts pielietot sistēmas ieviešanas un pilnveidošanas gaitā. Pēc
Pasūtītāja pieprasījuma, Pretendents nodrošina iespēju ar tiem iepazīties. Jānorāda arī
22
pēc kādas projektu vadības metodoloģijas tiks veidota komunikācija ar Pasūtītāju.
Jānorāda kādas kvalitātes nodrošināšanas procedūras tiks izmantotas.
(023) Lietojamības prasības
RISINĀJUMA pašapkalpošanās portāla lietojumprogrammatūrai, lietotāju saskarnes
lietojamībai jāatbilst šādām prasībām:
1. Izstrādes ietvaros, lietotāju saskarnes izveide un ieviešana ir jāveic, ievērojot
standartu LVS EN ISO 9241-210:2011 (Cilvēka un sistēmas mijiedarbības
ergonomika. 210.daļa: Uz lietotāju orientētie projektēšanas procesi
interaktīvajām sistēmām);
2. Piedāvātās sistēmas lietotāja interfeisam ir jābūt orientētam uz lietotāju:
a. Ekrānformās ir jāizmanto lietotājam viegli saprotama terminoloģija,
piemērojot nozares „labās prakses” pieredzi;
b. Apzīmējot vienu un to pašu elementu vai datu lauku dažādās
ekrānformās, jābūt izmantotiem vieniem un tiem pašiem terminiem un
grafiskajām zīmēm;
c. Datu ievades un apstrādes secībai ir jāatbilst tipiska lietotāja darba
procesam;
d. Visos gadījumos ir jābūt skaidri norādītai konkrētai darbībai, kuru veic
lietotājs, kā arī skaidri saprotamas norādes, kā pārtraukt vai pabeigt
iesākto darbību;
e. Kļūdu un ārkārtas situāciju aprakstiem ir jābūt skaidriem un lietotājam
saprotamiem, tieši norādot, kāda darbība tiek sagaidīta no lietotāja.
3. Lietotāja saskarnē iekļautie grafiskie elementi nedīkt būtiski ietekmēt
saskarnes ielādes procesu.
(024) Veiktspējas prasības
Veicot RISINĀJUMA piegādi, pilnveidošanu un uzturēšanu, Izpildītājam ir
nepieciešams nodrošināt šādas veiktspējas prasības un ātrdarbība:
1. RISINĀJUMAM jānodrošina līdz 400 vienlaicīgu lietotāju darbība (ja
lietotājs veic 1 pieprasījumu katras 3 sekundes);
2. jānodrošina šādu RISINĀJUMA ātrdarbības prasību izpilde:
2.1 visām ekrāna formām, kas nesatur apjomīgu biznesa loģiku, ir pilnībā
jāparādās ne vairāk kā 2 sekunžu laikā;
2.2 meklēšanai, kurā datu bāzē atrod līdz 100 meklējamām vienībām, 95%
gadījumu jānotiek ātrāk par 4 sekundēm;
2.3 meklēšanai, kurā datu bāzē atrod vairāk kā 100 meklējamo vienību, 95%
gadījumu jānotiek ātrāk par 10 sekundēm;
2.4 viena ieraksta pievienošanai, aktualizācijai, dzēšanai vai lietojuma
funkcijas izpildei (no brīža, kad lietotājs izsauc komandu, līdz brīdim,
kad pieejama informācija par sekmīgu rezultātu) 95% gadījumu jānotiek
ātrāk par 2 sekundēm.
Gadījumā, ja pretendents risinājuma darbināšanai nav paredzējis izmantot VID rīcībā
jau esošo infrastruktūru, Pretendentam jāpiedāvā serveri(s), kuru tehniskie resursi ir
atbilstoši, lai RISINĀJUMS nodrošinātu augstākminētos veiktspējas rādītājus un
vienlaicīgi RISINĀJUMA tehnisko resursu noslodze nepārsniegtu 80%.
Jānodrošina iespēja RISINĀJUMA administratoriem uzraudzīt sistēmas veiktspēju,
uzkrājot informāciju par būtiskākajiem RISINĀJUMA darbības parametriem.
23
(025) Pieejamības prasības
RISINĀJUMAM jānodrošina nepārtraukta pieejamība 24 stundas diennaktī un 7
dienas nedēļā, pasūtītāja piedāvātās sistēmas līmenī. Piedāvātās sistēmas darbspējas
laikam jābūt vismaz 98 % 1 (viena) gada laikā (plānotās dīkstāves un darbības
pārtraukumus neskaitot).
(026) Drošības un uzraudzības prasības
1. Piedāvātajam RISINĀJUMAM jābūt izstrādātam bez OWASP mājas lapā
reģistrētām biežāk pieļautajām drošības ievainojamībām, kā arī ņemot vērā
standartā ISO 15408-2:2008 noteiktās drošības vadlīnijas, par ko Pasūtītājs tiesīgs
pārliecināties, pasūtot drošības auditus.
2. Jānodrošina ka, savienojumi gan administrēšanas vajadzībām, gan starp IS, kuras
izmantos RISINĀJUMA sistēmu, ir šifrēti.
3. Piedāvātajam RISINĀJUMAM jānodrošina vairāku līmeņu piekļuves tiesības;
4. Jānodrošina RISINĀJUMA darbības integrāciju ar VID uzraudzības sistēmu
Zabbix (v.2.4.7 vai jaunāku), jāizstrādā risinājuma iekārtu un programmatūras
uzraudzības parametrus (items), bojājumu ziņojumus (triggers) vienotā šablonā
(template) un jāizveido risinājuma grafiskā attēlojuma karte (map) un svarīgāko
sistēmu darbības parametru attēlojošu logu (screen).
5. Jānodrošina iespēja veikt RISINĀJUMA datu rezerves kopiju veidošanu un
atjaunošanu no rezerves kopijas. Datu bāzei un aplikācijas serveriem rezerves
kopijas izveidošana jānodrošina bez sistēmas darbības pārtraukšanas. Jāizstrādā
un jānotestē RISINĀJUMA darbības atjaunošanas plāns.
6. RISINĀJUMAM ir jāattēlo klasificēts kļūdas paziņojums (kļūda, brīdinājums,
informācija) ar aprakstu un iespējamām turpmākām darbībām. Jānodrošina, ka
RISINĀJUMA programmatūra lietotājam nesniedz informāciju, kas varētu
apdraudēt RISINĀJUMA un/vai VID IS drošību, tai skaitā, nepieļaujot iespēju
lietotājam veikt analīzi par kļūdas un veikto Risinājuma pārbaužu raksturu un
iegūt nevēlamu informāciju par izmantotajām tehnoloģijām, RISINĀJUMA un
VID IS arhitektūru. Auditācijas ierakstos ir jābūt pilnam kļūdas paziņojumam.
(027) Uzturamības prasības
1. Piedāvātajam RISINĀJUMAM jābūt modulāram, maksimāli paredzot savstarpēji
nesaistītus moduļus, kas nodrošinātu, ka sistēma ir viegli uzturama, pielāgojama
un bojājumpiecietīga.
2. Piedāvātajam RISINĀJUMAM jābūt iespējai definēt un mainīt sistēmas
funkcionalitāti ar IS lietotāja definētu parametru palīdzību, iespēja mainīt sistēmā
izmantotās formulas vai parametru vērtības (pretēji gadījumam, kad izmaiņas
jāievieš sistēmas pirmkodā).
3. Jānodrošina detalizēta un aktuāla piedāvātās sistēmas dokumentācija, kas
nepieciešama sistēmas lietošanai un administrēšanai (atbilstoši prasībai (021)).
(028) Pielāgojamības un turpmākas attīstības prasības
Piedāvātais RISINĀJUMS ir izstrādājams tā, lai būtu iespējama tās turpmāka attīstība,
pilnveidojot programmatūras funkcionalitāti, un integrējot tajā papildus informācijas
sistēmas.
(029) Garantijas periods un apjoms
Garantijas saturs ir aprakstīts līguma projekta 8.punktā.
24
Garantijai ir jāietver vismaz šo:
1. Garantijas prasības Nodevumiem:
1.1. Izpildītājam Nodevumiem ir jānodrošina 2 (divu) kalendāro gadu garantijas
periods, skaitot no attiecīgā nodošanas-pieņemšanas akta abpusējas parakstīšanas
dienas, saskaņā ar līguma projekta 8.1.punktu;
1.2. Garantijas ietvaros Izpildītājam jānodrošina bezmaksas kļūdu
(programmatūrā, datu bāzē utt.) novēršana, t.sk. jānovērš datu bojājumi, kas
radušies Izpildītāja apzinātas vai neapzinātas rīcības rezultātā, un kas apgrūtina
RISINĀJUMA izmantošanu atbilstoši RISINĀJUMA tehniskajai specifikācijai,
kāda tā bijusi, nododot RISINĀJUMU ekspluatācijā;
1.3. Dokumentācijas aktualizēšana (t.i. labošana, papildināšana utt.), atbilstoši
visiem garantijas nodrošināšanas ietvaros veiktajiem labojumiem RISINĀJUMĀ;
2. Garantijas prasības piegādātajām iekārtām:
Pēc iekārtu piegādes, bet līdz iekārtu pieņemšanai ekspluatācijā, Pretendents iesniedz
ražotāja pilnvarota pārstāvja apliecinājumu, ka iekārtu garantijas ir piereģistrētas uz
Pasūtītāja vārdu.
Garantijas pakalpojuma nodrošināšanas laikā ir jānodrošina bez papildus maksas:
2.1. Piegādāto iekārtu garantijas laiks ir 3 ( trīs) kalendārie gadi no attiecīgā
nodošanas-pieņemšanas akta abpusējas parakstīšanas dienas. Piegādātās iekārtas
bojājumu novēršanas kārtība ir aprakstīta līguma projekta 0.1.0.pielikuma
11.punktā;
2.2. iekārtas bojājumu (defektu vai traucējumu to darbībā) noteikšana, novēršana vai
nepieciešamības gadījumā iekārtas aizstāšana ar līdzvērtīgu vai augstākas
veiktspējas iekārtas;
2.3. konsultāciju sniegšana;
2.4. palīdzības sniegšana iekārtas konfigurācijas korekcijas veikšanai, iekārtas
programmatūras (firmware) uzlabošanai, iekārtas slēgumu maiņā vai
uzlabošanā, ja ir tāda nepieciešamība;
2.5. iekārtas bojājumu novēršana Pasūtītāja telpās, ja bojājumu nav iespējams
novērst, izmantojot attālinātās piekļuves iespējas;
2.6. problēmu eskalācija līdz pat iekārtas ražotāja atbalsta dienestiem;
2.7. piegādātajām iekārtām jābūt apgādātām ar uzlīmēm, uz kurām norādīts iekārtas
seriālais numurs, piegādātājs, piegādātāja garantijas servisa centra
kontaktinformācija (tālrunis, e-pasts), garantijas servisa nodrošināšanas termiņa
beigu datums, līguma numurs un līguma noslēgšanas datums;
2.8. ja bojājums nav kritisks, bet tā novēršanai ir nepieciešams apturēt iekārtu vai tās
atsevišķu komponenšu darbu, šie darbi, ja nepieciešams, saskaņojot ar
Pasūtītāju, tiek veikti ārpus Pasūtītāja darba laika;
2.9. bojājumu novēršanas laikā Izpildītājam pilnībā jāatjauno iekārtas darbspēja.
(030) Palīdzības un konsultāciju pieejamība garantijas pakalpojuma
nodrošināšanas laikā
1. Garantijas ietvaros Izpildītājam jānodrošina palīdzība un konsultācijas
RISINĀJUMA izmantošanā VID darba dienās no pirmdienas līdz ceturtdienai no
plkst. 8:15 līdz plkst.17:00, piektdien no plkst.8:15 līdz plkst.15:45. Garantijas
ietvaros tehniskais atbalsts, palīdzība un konsultācijas sniedzamas, izmantojot
sekojošus komunikācijas kanālus – telefoniski, pa e-pastu un klātienē.
25
Izpildītājam ir jānodrošina visi norādītie komunikācijas kanāli, tomēr Izpildītājs,
vienojoties ar Pasūtītāju, var noteikt primāri izmantojamo komunikācijas kanālu.
2. VID kontaktpersonas atbalsts RISINĀJUMA darbināšanā (telefoniski, izmantojot
e-pastu vai, pēc Pasūtītāja pieprasījuma – klātienē, bet ne vairāk, kā 15
(piecpadsmit) cilvēkdienas mēnesī pirmos 4 (četrus) kalendāros mēnešus pēc
RISINĀJUMA uzstādīšanas produkcijas vidē, nākamos 4 (četrus) kalendāros
mēnešus – 10 (desmit) cilvēkdienas mēnesī, sākot ar 9 (devīto) kalendāro mēnesi
pēc RISINĀJUMA uzstādīšanas produkcijas vidē – 5 (piecas) cilvēkdienas
mēnesī).
(031) Prasības RISINĀJUMA uzturēšanai un pilnveidošanai
Pretendentam jānodrošina Piedāvātā RISINĀJUMA uzturēšana, pilnveidošana un
piegādāto Nodevumu garantijas nodrošināšanu saskaņā ar līguma projekta
0.2.0.pielikumu “RISINĀJUMA uzturēšanas un pilnveidošanas kvalitātes un
pārvaldības tehniskās prasības”.
3.5.tabula
Uzturēšanas un pilnveidošanas prasības
Nr.p.k. Prasības apraksts
1.
Pretendentam jānodrošina RISINĀJUMA uzturēšanas un pilnveidošanas
kvalitāte un pārvaldība Pretendenta pusē atbilstoši šādām prasībām:
1. plānu pārvaldība – pēc Pasūtītāja pilnvaroto personu pieprasījuma
Pretendentam 5 (piecu) darba dienu laikā jāiesniedz IS uzturēšanai un
pilnveidošanai nepieciešamie plāni (laika, izmaksu, izstrādes utt.).
Pretendentam jāpiedalās nodevumu un versiju plānošanā, sagatavojot un
pēc VID pieprasījuma nosūtot versiju plānus;
2. konfigurāciju pārvaldība – Pretendentam jānodrošina dažādu versiju
programmatūras vienumu konfigurāciju pārvaldība (konfigurāciju
informācijas uzkrāšana, savietojamība, atjaunošana utt.), t.sk.
RISINĀJUMA pielāgošana pārcelšanai uz izmantojamo tehnoloģiju
jaunākām versijām.
Visā projekta norises laikā bez aktuālo darba versiju uzturēšanas
vienmēr jāsaglabā arī visas Pasūtītājam iesniegto nodevumu versijas
un/vai laidieni (tas attiecas kā uz programmatūru, tā arī dokumentāliem
nodevumiem). Pretendentam jādefinē, kuri objekti tiks pakļauti
konfigurācijas pārvaldībai, piemēram, visi Pasūtītājam nododamie
dokumenti – prasību specifikācijas, projektējuma apraksti, nododamā
programmatūras produkta būtiskās komponentes (dinamiskie ielādes
moduļi, datubāze, utt.), jānodrošina objektu versiju viennozīmīgu
atpazīšanu, kā arī jāorganizē šo objektu sakārtotu glabāšanu;
3. versiju kontrole – Pretendentam jānodrošina versiju kontrole
dokumentācijas un programmatūras veidiem (versijai, servisa pakai,
tiešsaistes (Online) piegādei, datu labošanai, dokumentācijai), jāapraksta
versionēšanas principi un izmantotie rīki;
4. izmaiņu pārvaldība – Pretendentam jānodrošina izmaiņu pieprasījumu
pārvaldība RISINĀJUMA uzturēšanas un pilnveidošanas nodevumiem
(dokumentācijai, programmatūrai). Visām izmaiņām RISINĀJUMĀ ir
jābūt dokumentētām, katrā nodevumā iekļaujot aprakstu, kas identificē
jaunizveidoto funkcionalitāti, realizētās izmaiņas un novērstās kļūdas.
26
Veicot izmaiņas RISINĀJUMĀ, Pretendentam jāidentificē ietekme uz
citām saistītajām informācijas sistēmām un jāinformē Pasūtītājs, kā arī
jānodrošina datu integritāte un datu apmaiņas procesu savietojamība;
5. nodevumu testēšana – Pretendentam jānodrošina RISINĀJUMA
iekšējā testēšana atbilstoši kādai no zināmām testēšanas metodoloģijām
un testēšanas dokumentācijas sagatavošana. Pretendentam pēc Pasūtītāja
pieprasījuma ir jāapraksta un jāiesniedz Pasūtītājam testēšanas procesu
aprakstu, testēšanas veidus (manuālā, automātiskā) un testēšanas rīku
aprakstu, lai veiktu nodevumu kvalitatīvu testēšanu; kādā formātā tiks
piegādāti testēšanas scenāriji, kā tiks saskaņoti un iesniegti testpiemēri;
kad, kādā formātā un ar kādu saturu tiks iesniegti testu žurnāli.
2.
Pretendentam komunikācija ar pasūtītāju jānodrošina latviešu valodā. Ja
tiks piesaistīti speciālisti, kuri nepārvalda latviešu valodu, pretendentam
šo speciālistu saziņā ar pasūtītāju jānodrošina tulkošana bez papildu
maksas.
3.
Pretendentam visi nodevumi (dokumentācija, lietotāja saskarnes)
jānoformē, latviešu valodā un to izstrāde jānodrošina atbilstoši
standartiem (sk. prasību (022), t.sk. komunikācija ar pasūtītāju
jānodrošina latviešu valodā. Darbu izpildes rezultātā izveidotā
(modificētā) IS dokumentācija ir jāpiegādā, to integrējot attiecīgā
dokumenta veida pēdējā (aktuālajā) versijā, saglabājot izmaiņu
trasējamību.
4.
Pretendentam RISINĀJUMA pilnveidošanas, uzturēšanas un garantijas
laikā ir jāuztur projekta bibliotēka, kurā jāizvieto RISINĀJUMA darba
dokumenti – prasību specifikācijas, projektējuma apraksti, testēšanas
dokumentācija u.c.
5.
Pretendentam jāņem vērā, ka RISINĀJUMA pilnveidošanas un
uzturēšanas izpildes laikā Pasūtītājs ir tiesīgs prasīt Pretendentam
jebkādu informāciju saistībā ar RISINĀJUMA pilnveidošanas un
uzturēšanas kvalitātes nodrošināšanu bez papildu maksas.
6.
Līguma darba rezultātu nodošanas pieņemšanas kārtība un
akcepttestēšanas kārtība, jānodrošina atbilstoši līguma projekta 0.3.0
pielikumā aprakstītajai kārtībai.
7.
Drošības prasības RISINĀJUMA uzturēšanai un pilnveidošanai
jānodrošina saskaņā ar līguma projekta 0.7.0. pielikumā aprakstīto
kārtību. Pretendentam jānodrošina VID IS atbilstība ISO/IEC 15408-2
“Informācijas tehnoloģija – Drošības tehnikas – IT drošības
novērtējuma kritēriji” noteiktajām funkcionālajām drošības prasībām.
8.
RISINĀJUMA uzturēšanas vai pilnveidošanas rezultātā RISINĀJUMA
veiktspējas rādītāji nedrīkst samazināties zemāk par prasībā (024)
izvirzītajiem veiktspējas kritērijiem.
9.
Darbietilpības novērtēšanai izmantotās pretendenta metodes:
Pretendentam detalizēti jāapraksta sākotnējās darbietilpības
novērtēšanas (aprēķināšanas) metode un risinājums speciālistu veikto
darbu apjoma (patērētā laika) uzskaitei, kuru pretendents apņemas
izmantot līguma izpildes laikā. Pretendentam jāizmanto vismaz viena
formālā metode, balstoties uz COCOMO – Constructive Cost Model, un
vismaz viena neformālā metode.
27
10.
Speciālistu savstarpējās sadarbības un komunikācijas efektivitāte:
Pretendentam jāiesniedz shēma, kurā attēlota Pretendenta speciālistu
komunikāciju ar Pasūtītāja un trešās puses speciālistiem.
(032) Prasības RISINĀJUMA standartprogrammatūras uzturēšanai
Uzturēšanas saturs ir aprakstīts līguma projekta 8.punktā.
Uzturēšanai ir jāietver vismaz šo:
1. Izpildītājam standartprogrammatūrai ir jānodrošina 3 (trīs) kalendāro gadu
uzturēšanas periods, skaitot no attiecīgā nodošanas-pieņemšanas akta abpusējas
parakstīšanas dienas;
2. Piegādātās programmatūras darbības traucējumu un/vai kļūdu un nepilnību
diagnosticēšana, analīze un novēršana;
3. VID datu labojumu veikšana, ja datu bojājumi radušies piegādātās
programmatūras (t.sk. trešās puses programmatūras) kļūdu vai nepilnību dēļ;
4. Uzturēšanas ietvaros Izpildītājam ir jānovērš piegādātās programmatūras
darbības traucējumi, ja tādi rodas, un kļūdas un nepilnības, ja tādi tiek atklāti,
bez papildus maksas saskaņā ar līguma projekta 0.1.0.pielikumā aprakstīto
sadarbības kārtību;
5. Pasūtītāja informēšana par standartprogrammatūras jaunākajām versijām un
labojumiem esošajās versijās 2 (divu) nedēļu laikā no brīža, kad tos ir oficiāli
izsludinājis standartprogrammatūras ražotājs, nosūtot informāciju uz
elektroniskā pasta adresi IP_IdM@vid.gov.lv;
6. Pretendents nodrošina standartprogrammatūras jaunāko versiju un labojumu
piegādi bez papildus samaksas. Standartprogrammatūras jauno versiju un
labojumu piegāde Pasūtītājam tiek veikta uz datu nesējiem vai elektroniski 1
(viena) mēneša laikā no dienas, kad tos ir oficiāli izsludinājis tās ražotājs;
7. Pasūtītājam tiek nodrošināta iespēja pieslēgties (autorizēties)
standartprogrammatūras ražotāja Web mājas lapai, kurā var saņemt informāciju:
6.1. par standartprogrammatūras jaunākajām versijām un labojumiem un
lejupielādēt tos;
6.2. par konsultatīva rakstura piemēriem, kļūdu aprakstiem, sīkprogrammatūru,
iepriekš reģistrēto problēmziņojumu aprakstiem, to risinājumiem u.c.
tehnisko informāciju;
8. Pretendents nodrošina Pasūtītājam palīdzību stamdartprogrammatūras
instalēšanā, labojumu uzstādīšanā un pāriešanā uz jaunākām versijām.
(033) Prasības lietotāju apmācībai
RISINĀJUMA ieviešanas ietvaros ir jāveic:
1. vismaz 6 (sešu) RISINĀJUMA administratoru apmācības. Apmācībās jāietver
gan teorētiskās, gan praktiskās nodarbības, nodrošinot zināšanu apguvi par
RISINĀJUMA funkcionalitāti (tādā līmenī, lai apmācītais varētu apmācīt
citus RISINĀJUMA lietotājus), RISINĀJUMA administrēšanu un uzturēšanu
(t.sk. nepieciešamo rezerves kopiju veidošanu un RISINĀJUMA darbības
atjaunošanu), lietotāju administrēšanu, RISINĀJUMA konfigurēšanu.
Paredzamais apmācību ilgums 6 (sešas) stundas.
2. vismaz 100 (simts) VID darbinieku apmācības. Apmācībās jāietver praktiskās
nodarbības RISINĀJUMA pašapkalpošanās portāla lietošanā. Paredzamais
apmācību ilgums 2 (divas) stundas.
28
3. Sagatavot mācību plānus un mācību (izdales) materiālus atbilstoši 3.6. tabulā
norādītajam.
3.6.tabula
Apmācību veikšanai sagatavojamie dokumenti
Nr.p.
k.
Dokumenta veids Apraksts
1.
Mācību plāni Apmācību plānā ir detalizēti jāapraksta mācību
mērķis, saturs, laika grafiks, jānosaka prasības
apmācāmo grupai. Apmācībām ir jāietver teorētiskā
daļa, kā arī praktiskā. Pirms apmācību veikšanas ir
jābūt izstrādātai pietiekoši stabilai RISINĀJUMA
versijai, lai nodrošinātu apmācību praktisko daļu,
kā arī jābūt pabeigtai attiecīgajai dokumentācijai.
2.
Mācību (izdales)
materiāli
Izpildītājam ir jāizstrādā vai jāpapildina, jāsaskaņo
ar VID un jāpiegādā mācību materiāli. MS
PowerPoint, MS Word vai cita formāta
dokumentācija atbilstoši piedāvājumam. Mācību
materiāliem ir jātiek iesniegtiem pārskatīšanai un
akceptēšanai no VID puses vismaz 10 (desmit)
darba dienas pirms mācību norises.
(034) Projekta pārvaldības plāns
Izpildītājam 3 (trīs) kalendāro nedēļu laikā pēc līguma abpusējas parakstīšanas dienas
ir jāizstrādā un jāiesniedz Pasūtītājam izskatīšanai un saskaņošanai projekta
pārvaldības plāns.
Projekta pārvaldības plānā jānosaka tehniskās un pārvaldošās projekta funkcijas,
aktivitātes un uzdevumi, kas nepieciešami Pasūtītāja tehniskajā specifikācijā noteikto
projekta prasību apmierināšanai. Projekta pārvaldības plānā jāapraksta (bet
neaprobežojoties) projekta pārvaldības aktivitātes un uzdevumi, to norises kārtība,
atbildīgie, risku pārvaldības pasākumi, projekta kvalitātes nodrošināšanas pasākumi.
(035) Darbu izpildes plāns
Izpildītājam 4 (četru) kalendāro nedēļu laikā pēc līguma abpusējas parakstīšanas
dienas ir jāizstrādā un jāiesniedz Pasūtītājam izskatīšanai un saskaņošanai
RISINĀJUMA piegādes un ieviešanas darbu izpildes plāns, kurā detalizēti jāapraksta
līguma ietvaros izpildāmie darbi un uzdevumi, to izpildes laika plāns (izpildei
nepieciešamais laiks, kalendārais plāns), iesaistīto darbinieku darbietilpība (slodze).
(036) Darbu izpildes termiņi
Visas definētas prasības, kas uzskaitītas Pasūtītājā tehniskajā specifikācijā, kā arī
papildus prasības kas tiks definētas līguma darbības laikā ir jārealizē saskaņā ar
abpusēji saskaņoto RISINĀJUMA piegādes un ieviešanas darbu izpildes plānu un
attiecīgajā vienošanas protokolā norādītājā termiņā.
29
3.7.tabula
Darbu izpildes termiņi
Nr.p.
k.
Aktivitātes nosaukums Termiņi
1. Projekta pārvaldības plāns. 3 (trīs) kalendāro nedēļu laikā pēc līguma
abpusējas parakstīšanas dienas
2. Darbu izpildes plāns 4 (četru) kalendāro nedēļu laikā pēc
līguma abpusējas parakstīšanas dienas
3. Risinājuma piegāde, uzstādīšana un
integrācija ar HORIZON
Ne ilgāk ka 2 (divu) mēnešu laikā no
attiecīgā VP noslēgšanas
4. Integrācija ar MS AD, Exchange un
Sharepoint
Ne ilgāk ka 3 (trīs) mēnešu laikā no
attiecīga VP noslēgšanas
5. VID IT resursu pārvaldības ieviešana
un darba plūsmu konfigurēšana
Ne ilgāk ka 4 (četru) mēnešu laikā no
attiecīgā VP noslēgšanas
6. Pēc VID pieprasījuma Pretendentam
jāveic VID specializēto IS izpēti vai ir
iespējams integrēt ar RISINĀJUMU
un automatizēt tiesību piešķiršanu un
integrācijas izmaksu (nepieciešamo
personstundu skaits) izvērtēšanu
Pusēm savstarpēji vienojoties
30
4. Procesu shēmas
attēls 4.1 Jauns darbinieks
31
attēls 4.2 Lietotāja konta izmaiņas
32
attēls 4.3 Struktūrvienības izmaiņas
33
attēls 4.4 Lietotāja konta bloķēšana