1.pielikums (iepirkums Nr. LVRTC-2017/10)

ATKLĀTA KONKURSA NOLIKUMS

INFORMĀCIJAS SISTĒMU UZTURĒŠANAS UN PILNVEIDOŠANAS DARBI

ID Nr. LVRTC-2017/10

TEHNISKĀ SPECIFIKĀCIJA

1. IDENTIFIKĀCIJA

Šis sistēmas tehniskās specifikācijas dokuments attiecas uz “Latvijas Valsts radio un televīzijas centrs” (turpmāk tekstā – LVRTC vai Pasūtītājs) Informācijas sistēmu to integrāciju ar citām informācijas sistēmām uzturēšanu un pilnveidošanu. Dokuments sniedz priekšstatu par informācijas sistēmu kopējo arhitektūru un tās galvenajām komponentēm.

2. SAĪSINĀJUMI UN DEFINĪCIJAS

AD – Aktīvā direktorija

ATL – Activity TimeLine.

INTRA - Atlassian Confluence

VEDUS - Atlassian JIRA

CRM - vTiger CRM

ELU – Elementu uzskaites sistēma

ĢIS – Ģeogrāfiskā informācijas sistēma

KLS – Koplietošanas servisi

BI - Oracle BI Publisher

UR- Uzņēmumu reģistrs

IeR – Iedzīvotāju reģistrs

VZD – Valsts Zemes dienests

CVE - Common Vulnerabilities and Exposures publiski pieejamā zināmo drošības ievainojamību datu bazē https://cve.mitre.org/

Ķekars - loģiska vienība ar saviem atribūtiem, kurš apkopo savstarpēji nesaistītus vai saistītus elementus, elementu grupēšanai. Ķekars ir veids, kā sistēmā tiks grupēti dažādi savstarpēji neatkarīgi elementi, definējot tiem kopējus atribūtu.

3. VISPĀRĪGĀ INFORMĀCIJA PAR IEPIRKUMA PRIEKŠMETU

3.1.Pārskats par informācijas sistēmām.

Sistēmas arhitektūras apraksts

Shematiskajā attēlā ir parādītas testa vides IS arhitektūru veidojošās sistēmas un būtiskākās saskarsmes (integrācijas) starp tām.

IS arhitektūra sastāv no šādām apakšsistēmām un to komponentēm:

1. Elementu uzskaites sistēma ELU kopā ar ĢIS apakšsistēmu;

2. Datu noliktavas/biznesa inteliģences sistēma Oracle BI;

4. Klientu attiecību pārvaldības sistēma. CRM;

5. Grāmatvedības sistēma Horizon v490;

6. Dokumentu vadības sistēma Optima.;

7. Darba uzdevumu un incidentu pārvaldības sistēma. VEDUS;

8. Iekšējā tīkla sistēma jeb Intranet sistēma. INTRA;

9. Darba laika uzskaites sistēma. ATL.;

10. Dažādi koplietošanas servisi. KLS kas ietver vienotu autentifikāciju (OpenAM), vienotu auditācijas žurnālu, apakšmoduļus – IeR, UR, VZD.

11. Aktīvā direktorija (AD) iekšējiem un LDAP ārējiem lietotājiem.

Lietotāju grupas

Sistēmu lietotāji tiek iedalīti divās grupās:

Ārējie lietotāji (klients, partneris);

Iekšējie lietotāji (darbinieki, sistēmas konti).

3.2. Prasību specifikācija

Šajā nodalījumā ir aprakstītas IS uzturēšanas un pilnveidošanas prasības, kas tiek strukturētas šādas nodaļas:

3.2.1. Funkcionālās prasības;

3.2.2. Nefunkcionālās prasības

3.2.3. Citas prasības

3.2.1. Funkcionālās prasības

Vispārēji funkcionālās prasības ir sadalītas IS grupās:

3.2.1.1. Elementu uzskaites sistēma. ELU/ĢIS uzturēšana un pilnveidošana;

3.2.1.2. Datu noliktavas sistēma. Oracle Business Intelligence. BI uzturēšana un pilnveidošana;

3.2.1.3. Klientu attiecību pārvaldības sistēma. Vtiger. CRM uzturēšana un pilnveidošana;

3.2.1.4. Vienotā elektronisko darba uzdevumu sistēma (VEDUS). VEDUS uzturēšana un pilnveidošana;

3.2.1.5. Intraneta sistēma. Confluence. INTRA uzturēšana un pilnveidošana;

3.2.1.6. Darba laika uzskaite un plānošana. Activity TimeLine (ATL) uzturēšana un pilnveidošana;

3.2.1.7. Koplietošanas servisi. KLS uzturēšana un pilnveidošana

3.2.1.1. Elementu uzskaites sistēma. ELU/ĢIS uzturēšana un pilnveidošana

ELU/ĢIS uzturēšana jānodrošina visām esošajām ELU/ĢIS funkcionalitātēm un visām esošajām ELU/ĢIS integrācijām.

ELU/ĢIS pilnveidošana jānodrošina ņemot vērā visu esošo ELU/ĢIS funkcionalitāti un to savstarpējo ietekmi kā arī pilnveidošana jānodrošina ņemot vērā ELU/ĢIS visas esošās integrācijas.

3.2.1.1.1. Vispārējs apraksts

Web bāzēta aplikācija, kurā tiek uzglabāti dati par tīkla elementiem. Sistēmas funkcijas un lietotāja saskarne veidota, izmantojot Java (pašizstrāde) un Tomcat. Elementu uzskaites sistēma izmanto PostgreSQL datubāzi (tīkla elementu uzskaites glabāšanai) un Clusterpoint DB (elementu dinamisko atribūtu glabāšanai). Elementu ģeotelpiskās informācijas atspoguļošanai tiek izmantots FME Server.

3.2.1.1.2. ELU/GIS galvenā funkcionalitāte:

- LVRTC infrastruktūras un pakalpojumos izmantojamo elementu un to raksturojošās informācijas uzturēšana;

- Elementu infrastruktūras projektēšana un plānošana;

- Elementu savstarpējā savienošana un šī savienojumu informācijas uzturēšana;

- Elementu ģeogrāfiskās informācijas uzturēšana un attēlošana.

3.2.1.1.3. ELU/ĢIS ir šādas galvenās integrācijas:

N.p.k. ELU Sistēma/ modulis Virziens (datu apmaiņa)

Integrācija

1. ELU BI ELU BI Process

2. ELU CRM CRM ELU Tiešsaiste

3. ELU VEDUS VEDUS ELU Tiešsaiste

4. ELU Lietojumi ELU Lietojumi Tiešsaiste

5. ELU KLS/ADR ELU KLS/ADR Tiešsaiste

6. ELU HORIZON ELU HORIZON Tiešsaiste

3.2.1.2. Datu noliktavas sistēma. Oracle Business Intelligence. BI uzturēšana un pilnveidošana

BI uzturēšana jānodrošina visām esošajām BI funkcionalitātēm un visām esošajām BI integrācijām.

BI pilnveidošana jānodrošina ņemot vērā visu esošo BI funkcionalitāti un to savstarpējo ietekmi kā arī pilnveidošana jānodrošina ņemot vērā BI visas esošās integrācijas.

3.2.1.2.1. Vispārējs apraksts

Oracle Business Intelligence risinājums, kas nodrošina datu savākšanu no dažādiem datu avotiem, datu transformēšanu un attēlošanu iepriekš definētajos atskaišu griezumos. Oracle Business Intelligence izmanto PostgreSQL datu bāzi.

3.2.1.2.2. BI galvenā funkcionalitāte:

- Atskaišu ģenerēšana

- Pārskati

3.2.1.2.3. BI ir šādas galvenās integrācijas

N.p.k. BI Sistēma/ modulis Virziens (datu apmaiņa) Integrācija

1. BI ELU/ĢIS, VEDUS, CRM, Horizon, Optima, eParaksts

(ELU/ĢIS, VEDUS, CRM, Horizon, Optima, eParaksts) BI

Process

3.2.1.3. Klientu attiecību pārvaldības sistēma. Vtiger. CRM uzturēšana un pilnveidošana

CRM uzturēšana jānodrošina visām esošajām CRM funkcionalitātēm un visām esošajām CRM integrācijām.

CRM pilnveidošana jānodrošina ņemot vērā visu esošo CRM funkcionalitāti un to savstarpējo ietekmi kā arī pilnveidošana jānodrošina ņemot vērā CRM visas esošās integrācijas.

3.2.1.3.1. Vispārējs apraksts

CRM programmatūra - Standarta CRM programmatūra – Vtiger CRM (PHP izstrāde) ar specifisku konfigurāciju un pielāgojumiem. CRM izmanto MySQL datubāzi.

3.2.1.3.2. Klientu attiecību pārvaldības sistēmas CRM galvenā funkcionalitāte:

1. Lietotāju (fizisku un juridisku - klientu, partneru, piegādātāju, kontaktpersonu, objekta īpašnieku, potenciālu klientu) uzskaites modulis, kurā tiek uzturēta šo lietotāju raksturojošā informācija (t.skaitā kontaktinformācija, norēķinu informācija). Lietotāju uzskaites modulis ir centrālā un vienīgā vieta, kurā tiek uzturēti šo lietotāju dati. Visas citas sistēmas, kurām nepieciešami dati par lietotājiem, tos ņem no CRM.

Lietotāju datiem tiek veikta datu validācija:

- Juridisko personu datu validācijas modulis pret Uzņēmumu reģistru;

- Privātpersonu datu validācijas modulis pret Iedzīvotāju reģistru. 2. Saziņas (zvanu, pasta sūtījumu, tikšanās, e-pastu u.c. veida saziņas), kas veikta ar personu, uzkrāšana, par katru ierakstu uzturot tā raksturojošo informāciju. Saziņas ieraksti tiek attēloti sistēmas kalendārā.

3. Pakalpojuma katalogs, kurā tiek uzturēta visu LVRTC pakalpojumu raksturojošā informācija, t.sk. funkcionalitāte pakalpojuma cenošanai – iekšējās cenas aprēķināšanu un cenas klientam norādīšanu.

4. Klienta interešu uzkrāšana un piedāvājumu sagatavošana.

5. Kampaņu apakšmodulis, kas nodrošina atbalstu īpaši organizētām pārdošanas aktivitātēm pēc noteiktiem kritērijiem definētiem klientiem.

6. Klienta līgumu un vienošanos sagatavošana un gala versijas uzturēšana. Pieņemšanas nodošanas aktu raksturojošās informācijas uzturēšana.

7. Klienta pakalpojuma instanču uzturēšana

3.2.1.3.3. CRM ir šādas galvenās integrācijas:

N.p.k. CRM Sistēma/ modulis Virziens (datu apmaiņa) Integrācija

1. CRM ELU/ĢIS CRM ELU/ĢIS Tiešsaiste

2. CRM VEDUS CRM VEDUS Tiešsaiste

3. CRM Optima CRM Optima Tiešsaiste/Process

4. CRM Horizon CRM Horizon Tiešsaiste

5. CRM Lietojumi CRM Lietojumi Tiešsaiste

6. CRM KLS/ADR CRM KLS/ADR Tiešsaiste

7. C CRM BI CRM BI Process

3.2.1.4. Vienotā elektronisko darba uzdevumu sistēma (VEDUS). VEDUS uzturēšana

un pilnveidošana

VEDUS uzturēšana jānodrošina visām esošajām VEDUS funkcionalitātēm un visām esošajām VEDUS integrācijām.

VEDUS pilnveidošana jānodrošina ņemot vērā visu esošo VEDUS funkcionalitāti un to savstarpējo ietekmi kā arī pilnveidošana jānodrošina ņemot vērā VEDUS visas esošās integrācijas.

3.2.1.4.1. Vispārējs apraksts

Standarta darba uzdevumu pārvaldības programmatūra - Atlassian JIRA (JAVA izstrāde) ar Pasūtītājam specifisku konfigurāciju. VEDUS izmanto PostgreSQL .

3.2.1.4.2. VEDUS galvenā funkcionalitāte:

1. Pieteikumu (darba uzdevumu) pārvaldība, t.skaitā, darba plūsmu un to nosacījumu, ekrānformu definēšana, pieteikumu komentēšanu un pieteikuma apstrādē iesaistīto lietotāju apziņošanu.

2. Klientu apkalpošana: klientu pieteikumu reģistrs.

3. Incidentu un problēmu pārvaldība.

3.2.1.4.3. VEDUS ir šādas galvenās integrācijas:

N.p.k. VEDUS Sistēma/ modulis

Virziens (datu apmaiņa) Integrācija

1. VEDUS ELU/ĢIS VEDUS ELU/ĢIS Tiešsaiste

2. VEDUS CRM VEDUS CRM Tiešsaiste

3. VEDUS Optima VEDUS Optima Tiešsaiste

4. VEDUS Horizon Horizon VEDUS Tiešsaiste

5. VEDUS Lietojumi VEDUS Lietojumi Tiešsaiste

6. VEDUS KLS/ADR VEDUS KLS/ADR Tiešsaiste

7. C VEDUS BI VEDUS BI Process

8. VEDUS ATL VEDUS ATL Tiešsaiste

9. VEDUS INTRA VEDUS INTRA Tiešsaiste

3.2.1.5. Intraneta sistēma. Confluence. INTRA uzturēšana un pilnveidošana

INTRA uzturēšana jānodrošina visām esošajām INTRA funkcionalitātēm un visām esošajām INTRA integrācijām.

INTRA pilnveidošana jānodrošina ņemot vērā visu esošo INTRA funkcionalitāti un to savstarpējo ietekmi kā arī pilnveidošana jānodrošina ņemot vērā visas esošās integrācijas.

3.2.1.5.1. Vispārējs apraksts

Satura pārvaldības programmatūra - Atlassian Confluence (JAVA izstrāde) ar specifisku konfigurāciju iekštīkla apakašsistēmas (Intranet) funkcionalitātes nodrošināšanai. INTRA izmanto PostgreSQL datubāzi.

3.2.1.5.2. INTRA galvenā funkcionalitāte:

- Uzņēmuma vispārējās informācijas (struktūra, nolikumi, noteikumi, jaunumi, aktuālās rokasgrāmatas, procesu apraksti) uzturēšanai;

- Darbinieku aktuālās informācijas (profils, prombūtnes, dzimšanas diena, kontaktinformācija) attēlošanai;

- Projektu un grupu informācijas uzturēšana, kopēja projekta google kalendāra izmantošana, pieteikumu izveidošana VEDUS, aktuālās informācijas attēlošana, filtrēšana, diskusiju (komentāru) norādīšana.

3.2.1.5.3. INTRA ir šādas galvenās integrācijas:

N.p.k. INTRA Sistēma/ modulis

Virziens (datu apmaiņa) Integrācija

1. INTRA VEDUS INTRA VEDUS Tiešsaiste

2. INTRA AD AD INTRA Tiešsaiste

3. INTRA Optima INTRA Optima Tiešsaiste

4. INTRA Horizon Horizon INTRA Tiešsaiste/Process

5. INTRA Lietojumi INTRA Lietojumi Tiešsaiste

6. INTRA KLS VEDUS KLS Tiešsaiste

3.2.1.6. Darba laika uzskaite un plānošana. Activity TimeLine (ATL) uzturēšana un pilnveidošana

ATL uzturēšana jānodrošina visām esošajām ATL funkcionalitātēm un visām esošajām ATL integrācijām.

ATL pilnveidošana jānodrošina ņemot vērā visu esošo ATL funkcionalitāti un to savstarpējo ietekmi kā arī pilnveidošana jānodrošina ņemot vērā ATL visas esošās integrācijas.

3.2.1.6.1. Vispārējs apraksts

Darba laika uzskaites sistēma ATL ar specifisku konfigurāciju nostrādātā darba laika uzturēšanai, prombūtņu ievadīšanai un apstiprināšanai. ATL izmanto PostgreSQL datubāzi.

3.2.1.6.2. ATL galvenā funkcionalitāte:

- Darba laika atrakstīšana

- Darba laika imports no VEDUS

- Darba laika apstiprināšana

3.2.1.6.3. ATL ir šādas galvenās integrācijas:

N.p.k. ATL Sistēma/ modulis Virziens (datu apmaiņa) Integrācija

1. ATL VEDUS VEDUS ATL Tiešsaiste

2. ATL Horizon ATL Horizon Tiešsaiste

3. ATL Lietojumi ATL Lietojumi Tiešsaiste

3.2.1.7. Koplietošanas servisi. KLS uzturēšana un pilnveidošana

KLS uzturēšana jānodrošina visām esošajām KLS funkcionalitātēm un visām esošajām KLS integrācijām.

KLS pilnveidošana jānodrošina ņemot vērā visu esošo KLS funkcionalitāti un to savstarpējo ietekmi kā arī pilnveidošana jānodrošina ņemot vērā KLS visas esošās integrācijas..

3.2.1.7.1. Vispārējs apraksts

Koplietošanas servisu galvenais mērķis ir nodrošināt funkcionalitāti, kuru iespējams izmantot centralizēti dažādās sistēmās. KLS izmanto PostgreSQL datubāzi. Izmantotās programmēšanas valodas: PHP, JAVA

3.2.1.7.2. KLS galvenā funkcionalitāte:

- Vienotā autentifikācija;

- Personas datu validācija un monitorēšana pret Iedzīvotāju reģistra (IR) datiem;

- Organizācijas datu validācija pret Uzņēmuma reģistra (UR) datiem;

- Adrešu reģistrs (ADR);

- Apziņošanas serviss;

Vienotais audita pierakstu žurnāls un lietotāju tiesību pārvaldības žurnāls

3.2.1.7.3. KLS ir šādas galvenās integrācijas:

N.p.k. KLS Sistēma/ modulis Virziens (datu apmaiņa) Integrācija

1. KLS /UR CRM CRM KLS/UR Tiešsaiste

2. KLS AD/LDAP AD/LDAP Lietojumi Process

3. Lietojumi CRM, ELU/ĢIS, VEDUS, INTRA

Lietojumi CRM, ELU/ĢIS, VEDUS, INTRA

Tiešsaiste

4. KLS /IR Horizon CRM KLS/IR Tiešsaiste

5. KLS /ADR Lietojumi CRM KLS/UR Tiešsaiste

3.2.2. Nefunkcionālās prasības

3.2.2.1.1. Veicot informācijas sistēmu (ELU/ĢIS, BI, CRM, VEDUS, INTRA, ATL, KLS) izmaiņu pieprasījumu jānodrošina esošo sistēmu funkcionalitātes pilnu atbalstu jaunākajā versijā saglabājot pieejamo funkcionalitāti un nodrošinot atpakaļ savietojamību ar esošo informācijas sistēmu (ELU/ĢIS, BI, CRM, VEDUS, INTRA, ATL, KLS) versiju.

3.2.2.1.2. Atbalstāmās tīmekļa pārlūkprogrammas

Sistēmai ir jāatbalsta šādas tīmekļa pārlūkprogrammas un to versijas:

Google Chrome 56 vai jaunāka versija;

Mozilla Firefox 51 vai jaunāka versija;

Microsoft Internet Explorer 11 vai jaunāka versija;

Apple Safari 10 vai jaunāka versija.

3.2.2.1.3. Atbalstāmās mobilās tīmekļa pārlūkprogrammas

Sistēmai ir jāatbalsta šādas viedtālruņu un planšetdatoru mobilās tīmekļa pārlūkprogrammas un to versijas:

Google Chrome for Android 56 vai jaunāka versija (sākot ar Android 4.4);

Apple Safari 10 vai jaunāka versija (sākot ar iOS 4.1);

Microsoft Internet Explorer 11 vai jaunāka versija.

3.2.2.1.5. Saskarnes valoda

Sistēmas lietotāju saskarnei ir jābūt latviešu valodā. Visiem sistēmas ziņojumiem (t.sk. biznesa kļūdu paziņojumiem) ir jābūt latviešu valodā. Izņēmums ir tehniskie kļūdu paziņojumi, kuri var būt arī angļu valodā.

3.2.2.4. Sistēmas pieejamības un ātrdarbības prasības

3.2.2.4.2. Sistēmas pieejamība

Sistēmai jābūt pieejamai atbilstoši noteiktam SLA (skat. punktu 4.3.). Sistēmas nepārtrauktas pieejamības prasība neattiecas uz šādiem specifiskiem gadījumiem:

sistēmas jaunas versijas uzstādīšana;

trešo pušu programmatūras avārija, apkalpošana vai atjaunināšana;

aparatūras apkalpošana (piemēram, operatīvās atmiņas palielināšana);

sistēmas atjaunošana no datu rezerves dublikāta.

3.2.2.4.3. Saskarnes atsaucīgums

Jānodrošina, ka sistēmas datu ievades un izvades ekrānformas, kas nesatur apjomīgu biznesa loģiku un kurās nav grafisko datu, 95% gadījumu ir jāatver ātrāk par 3 sekundēm pie vienlaicīgiem 50 vai mazāk sistēmas lietotājiem, ja datu pārraides ātrums nav mazāks par 100 Mbps. Savukārt sistēmas datu ievades un izvades ekrānformas, kas satur apjomīgu biznesa loģiku vai kurās ir jāveic grafisko datu attēlošana, 95% gadījumu ir jāatver ātrāk par 10 sekundēm pie vienlaicīgiem 50 vai mazāk sistēmas lietotājiem, ja datu pārraides ātrums nav mazāks par 100 Mbps. Pie zemākiem datu pārraides ātrumiem (bet ne zemākiem kā 10 Mbps), augstākminētie izpildes laiki var tikt divkāršoti.

3.2.2.5. Sistēmas drošības un datu rezerves kopēšanas prasības

3.2.2.5.1. Datu šifrēšana pārraides tīklā

Sistēmā jānodrošina, ka datu apmaiņa starp klientu (pārlūkprogrammu) un serveri (Sistēmu) notiek tikai un vienīgi pa šifrētu datu apmaiņas kanālu (izmantojot TLS protokola 1.2 vai jaunāku versiju).

3.2.2.5.2. Aizsardzība pret ievainojamībām

Jānodrošina aizsardzība pret zināmajām ievainojamībām kuras ir pieejamas CVE datubāzē.

3.2.2.5.3. Aizsardzība pret nesankcionētu rīcību

Sistēmas formām un saskarnēm jābūt izstrādātām tā, lai nebūtu iespējams, apejot autentifikācijas un autorizācijas procedūras, nesankcionēti izpildīt Sistēmas funkcijas un/ vai piekļūt Sistēmā uzglabātajai informācijai pat tad, ja pieprasījums satur precīzu funkcijas un/ vai datu piekļuves resursa datus. Visas darbības sistēmā tiek saglabātas audita notikuma žurnālā.

3.2.2.5.4. Sistēmas vispārējas drošības prasības

Jānodrošina, ka sistēmā nav pieļaujama funkcionalitāte, kas atļauj sistēmas lietotājam saglabāt savu paroli tā, lai tā turpmākajās pieslēgšanas reizēs nav jāievada;

Sistēmas lietotājiem redzamie kļūdu paziņojumi satur tikai minimāli nepieciešamo informāciju, lai sistēmas lietotājs pašrocīgi vai ar sistēmas atbalsta personāla palīdzību atrisinātu kļūdu;

Papildus sistēmas atbalsta personālam jānodrošina detalizētas tehniskās informācijas par kļūdu pieejamība (piem., auditācijas pierakstos);

Veicot sistēmas izstrādi nav pieļaujama tās pirmkoda nodošana nepilnvarotām personām;

Veicot sistēmas izstrādi un testēšanu, nav pieļaujams radīt apdraudējumu sistēmā glabāto datu integritātei un konfidencialitātei;

Darbinot sistēmu, jāatslēdz visas iekļautās, bet neizmantotās komponentes (datortīkla pakalpojumus, saskarnes, procesus un servisus);

Jānodrošina datu plūsmas kontrole starp sistēmas komponentēm;

Jānodrošina informācijas integritātes saglabāšana (pilnīgas un nemainītas informācijas saglabāšana). Jānodrošina informācijas konfidencialitāte (piekļuve informācijai nodrošināma tikai tām personām, kurām ir atbilstošas piekļuves tiesības);

Visām sistēmas komponentēm ir funkcionāli jādarbojas pie jebkura drošības atjauninājuma uzstādīšanas servera un klienta pusē;

Pirms sistēmas testēšanas tās izstrādātājs sagatavo izmantoto aizsardzības metožu aprakstu (datu ievades kontrole, datu plūsmu kontrole, izmantotās šifrēšanas metodes u.c.), uzskaita drošības apdraudējumu tuvošanās vai iestāšanās pazīmes un sagatavo ieteikumus sistēmas drošības (pieejamība, integritāte, konfidencialitāte) nodrošināšanai. Pēc Pasūtītāja pieprasījuma Izpildītājs sadarbojas ar Pasūtītāju sistēmas drošības pārbaudes nodrošināšanai un atklāto trūkumu novēršanai.

3.2.2.6. Sistēmas izstrādes vides

3.2.2.6.1. Izstrādes un testēšanas vides

Piegādātājam ir jānodrošina vides sistēmas izstrādes un testēšanas vajadzībām, izmantojot savas organizācijas infrastruktūru un aparatūru.

3.2.2.6.2. Akcepttestēšanas un produkcijas vides

Pasūtītājam ir jānodrošina vides sistēmas akcepttestēšanai un produkcijai, balstoties uz Piegādātāja iesniegtu minimālās un rekomendētās infrastruktūras, aparatūras un programmatūras konfigurācijas aprakstu.

3.2.2.7. Sistēmas testēšanas prasības

3.2.2.7.1. Sistēmas testēšanas dokumentācija

Piegādātājam jānodrošina vismaz šādas testēšanas dokumentācijas pieejamība (saskaņā ar standartu LVS 70:1996 "Informācijas tehnoloģija. Programminženierija. Programmatūras testēšanas dokumentācija"), kura ir apkopota vienotā dokumentā:

testēšanas plāns;

testu projektējuma specifikācija;

testpiemēra specifikācija;

testēšanas procedūras specifikācija;

testējamā vienuma pavadzīme;

testēšanas žurnāls;

testa problēmu ziņojumi;

testēšanas kopsavilkuma pārskats.

3.2.2.7.2. Sistēmas testēšanas apjoms

Piegādātājam jānodrošina visu Sistēmas komponenšu, šo komponenšu savstarpējās sadarbības, kā arī integrācijas ar citām iekšējām un ārējām sistēmām testēšana, izmantojot manuālās un automātiskās metodes. Piedāvājumā jānorāda metodes, kas tiks izmantotas. Katrai komponentei jāveic pilnīgi visu tās funkciju testēšana.

3.2.2.7.3. Sistēmas akcepttestēšana

Piegādātājam jānodrošina atbalsts Sistēmas akcepttestēšanas vides sagatavošanā, Sistēmas uzstādīšanā un konfigurēšanā, kā arī nepieciešamais atbalsts Pasūtītājam, lai Pasūtītājs varētu veiksmīgi veikt akcepttestēšanu. Pasūtītājam ir tiesības noraidīt sistēmas vai tās daļas akceptēšanu, saņemot pirmo kritisko kļūdu akceptēšanas laikā.

3.2.2.7.4. Sistēmas akceptēšanas procedūra un plāns

Piegādātājam jāsagatavo un jāsaskaņo ar Pasūtītāju Sistēmas akcepttestēšanas plāns un procedūra, kurā ir aprakstīta akceptēšanas kārtība, kritēriji un testi.

3.2.2.7.5. Sistēmas veiktspējas testēšana

Piegādātājam jānodrošina Sistēmas, to komponenšu un funkciju veiktspējas testēšana, lai pārliecinātos par to, ka Sistēma atbilst specifikācijā noteiktajām veiktspējas prasībām.

3.2.2.8. Garantijas nodrošināšanas prasības

3.2.2.8.1. Sistēmas garantija

Sistēmas garantija attiecas uz:

izstrādāto un piegādāto izmaiņu pieprasījumiem;

izstrādātām un ieviestām izmaiņām, kuras iepriekš Pretendents ir izvērtējis un rakstiski akceptējis ar Pasūtītāju;

uzturēšanas ietvaros veiktajām izmaiņām citās informācijas sistēmās;

piegādāto dokumentāciju.

3.2.2.8.2. Gadījumā, ja Programmatūrā pēc izmaiņu ieviešanas tiek konstatētas kļūdas Programmatūras funkcionalitātē, veiktspējas zudumi, drošības ievainojamības vai integritātes apdraudējumi, Pretendentam ir pienākums pierādīt, ka šādu kļūdu cēlonis nav izmaiņu izstrāde un ieviešana, pretējā gadījumā uzskatāms, ka šādu defektu cēlonis ir Pretendenta rīcība un šādu kļūdu novēršana ir Pretendenta atbildība.

3.2.2.8.2. Sistēmas garantijas nodrošināšana

Piegādātājam jānodrošina Sistēmas garantija visām izmaiņām tajās informācijas sistēmās, kā arī to savstarpējās integrācijas, kurās Piegādātājs veiks izmaiņas Sistēmas ieviešanas laikā.

3.2.2.8.3. Pretendents tiek atbrīvots no pienākuma nodrošināt garantijas uzturēšanu tām Programmatūras daļām, kuras Pasūtītājs ir pasūtījis papildinājumu izstrādi trešajām pusēm un tām daļām, kuru darbību šie papildinājumi ietekmē.

3.2.2.8.5. Garantijas nodrošināšanas maksa

Piegādātāja nodrošinātajai garantijai ir jābūt bez maksas visu tās darbības laiku.

3.2.3. Citas prasības

3.2.3.1. Sagatavojot tehnisko piedāvājumu, Pretendents tehniskajā piedāvājumā norāda informāciju par piegādātās programmatūras garantijas un pēcgarantijas apkalpošanas noteikumiem un nosacījumiem. Programmatūrai un to pilnveidošanas darbiem jānodrošina Pretendenta piedāvātā garantija, bet ne mazāk kā 2 (divu) gadu garantija pēc to pieņemšanas-nodošanas akta parakstīšanas. Garantijas laikā tiek nodrošināta bezmaksas Programmatūras kļūdu labojumu izstrāde un uzstādīšana. Garantijas laikā Pasūtītājs nodrošina infrastruktūras uzturēšanu pie sevis, kas nepieciešama Pasūtītāja programmatūras kļūdu labojumu testēšanai un izstrādei.

3.2.3.2. Tehniskajā piedāvājumā Pretendentam jānorāda visas licences, kas būs nepieciešamas pakalpojuma uzturēšanai, tostarp arī licences, kas nepieciešamas testa vides uzturēšanai pie Pasūtītāja.

4. UZTURĒŠANAS RISINĀJUMA PROCEDŪRA UN PAKALPOJUMA IS PIEEJAMĪBA (SLA)

4.1. Uzturēšanas periodā sniegtie pakalpojumi:

IS uzturēšanas laikā Pretendenta, ir jānodrošina vismaz šādu pakalpojumu pieejamība Pasūtītājam:

4.1.2. IS un to integrāciju ar citām informācijas sistēmām uzturēšanas nodrošināšana

Klientu apkalpošanas dienesta nodrošināšanu darba dienās no plkst. 08:00 līdz 18:00;

konsultāciju sniegšanu par sistēmas lietošanu un administrēšanu;

sistēmas un to integrāciju ar citām informācijas sistēmām darbību traucējumu un/ vai incidentu diagnosticēšanu un analīzi;

sistēmas to integrāciju ar citām informācijas sistēmām darbību traucējumu un/ vai incidentu novēršana;

sistēmas to integrāciju ar citām informācijas sistēmām darbināšanas incidentu novēršana;

visu Pretendenta piegādāto IS piegādēm, gan visām izmaiņām, kuras tiks veiktas Sistēmas uzturēšanas laikā 1.– 4. pieteikumu kategorijas (skat. Tabula 2.. Pieteikumu kategorijas) incidentu novēršana, tai skaitā Sistēmas uzstādījumu, konfigurācijas parametru un programmatūras modifikāciju veikšana ar mērķi; novērst incidentus un datu bojājumus, kas radušies Pretendenta apzinātas vai neapzinātas rīcības rezultātā (prasība attiecas uz visiem Sistēmas uzturēšanas laikā veiktajiem pieteikumiem).

akcepttestēšanas laikā atklāto kļūdu novēršanu;

labojumu piegāžu un uzstādīšanas instrukciju sagatavošanu un nosūtīšanu;

trešās puses programmatūras atjauninājumu nosūtīšanu Pasūtītājam;

4.1.2. Izmaiņu pieprasījumu realizācija – IS pilnveidošana.

4.1.3. Dokumentācijas un pirmkoda uzturēšana izmantojot LVRTC rīcībā esošo UberSVN risinājumu

4. 2. Sistēmas uzturēšanas nodrošināšana.

4.2.1. Izpildītāja atbildība.

4.2.1.1. Klienta apkalpošanas dienestam adresēto pieteikumu apkalpošana:

zvana pieņemšanu: 08:00 – 18:00 darba dienās;

Incidentu reģistrēšana notiek izmantojot Pasūtītāju pieteikumu apstrādes sistēmu VEDUS:

Tiek nodrošināts Pasūtītāja pastāvīgais pieslēgums incidentu reģistrācijai, izmantojot autorizēto pieteikumu apstrādes sistēmu VEDUS, kura nodrošinās šādas iespējas (skat. 1.att. Incidenta risināšanas darba plūsma):

o pārlūkot pieteikto incidentu risināšanas norisi pēc to statusiem.

VEDUS izmantošanas laiks nav ierobežota.

e-pastu saņemšana;

tikšanās klātienē;

pieteikuma piereģistrēšanu, pāradresēšanu atbildīgajai personai (parasti, līgumā norādītajai Pretendenta kontaktpersonai, ja nav atrunāts citādi);

Gadījumos, kad pieteikuma risināšanas gaitā tiks konstatēts, ka incidenta novēršanai nepieciešama trešās puses programmatūras izstrādātāja (ražotāja) iejaukšanās, Pretendents pieprasījumu eskalē līdz attiecīgajam ražotājam. Tālāk pieteikums tiek risināts atbilstoši sistēmas vai trešās puses programmatūras ražotāja garantijas/uzturēšanas noteikumiem.

4.2.1.3. Pretendents sniedz regulāru informāciju par incidenta novēršanas gaitu atkarībā no incidenta novēršanas prioritātes:

4.2.1.3.1. Prioritāte “Kritisks” – pēc katras 1 stundas;

4.2.1.3.2. Prioritāte “Augsts” - katrām 2 stundām;

4.2.1.3.3. Prioritāte “Vidējs/Zems” - pēc pieprasījuma

4.2.1.3.4. Prioritāte “Konsultācija” - pēc pieprasījuma

4.2.1.4. Pretendentam ir tiesības veikt pieteikuma (prioritātes) pārklasificēšanu, iepriekš to saskaņojot ar Pasūtītāju.

4.2.1.5. Pretendents kontrolē incidenta novēršanas gaitu, lai iekļautos SLA kritērijos.

4.2.2. Pasūtītāja atbildība ietver:

4.2.2.1. Sniegt nepieciešamo informāciju incidenta cēloņu noskaidrošanā;

4.2.2.2. Norādīt pieteikuma kategoriju (prioritāti);

4.2.2.3. Norādīt atbildīgo kontaktpersonu, ar kuru kontaktēties incidenta risināšanas laikā;

4.2.2.4. Akceptēt vai noraidīt incidenta novēršanas risinājumu;

4.2.2.5. Norādīt incidenta reakcijas un novēršanas laikus, kas atrunāti punktā 4.5.

4.3.6. Par noteikto Vidējas vai Zemas prioritātes (3. vai 4. kategorijas) incidentu novēršanas termiņu kavējumu Pretendents maksā Pasūtītājam līgumsodu 50,00 EUR (piecdesmit euro, 00 centi) par katru kavējuma dienu.

4.4. Pieteikumu klasificēšana

Pieteikumi tiek klasificēti, lai pieteikumu VEDUS pieteikumu apstrādes sistēmā varētu ātri un uzskatāmi atlasīt un apskatīties attiecīgā tipa pieteikumus un to apstrādes statusu.

Tabula 1

Pieteikuma tips

Tipa apraksts Nodevums

Pieteikuma tips

Tipa apraksts Nodevums

1. Konsultācija Incidents ir novēršams paša lietotāja spēkiem, izpildot klienta apkalpošanas dienesta ieteiktās darbības.

Izlabota attiecīgās IS rokasgrāmata

2. Incidents Incidents atrodas Pasūtītāja specificēto prasību jomā un ir novēršams ar Izpildītāja spēkiem, veicot konstatētās kļūdas labojumu sistēmas aktuālā piegādē.

Pēc kļūdas labojuma Pretendents veic labotās piegādes testēšanu un pēc pozitīvās testēšanas iesniedz Pasūtītājam laboto piegādi līgumā atrunātajā kārtībā (piem., ar CD vai uzliekot uz datu apmaiņas servera) ar pievienoto pavaddokumentu.

Jauna piegāde

Izlabots pirmkods

Izlabota instalācijas pakotne

Izlabota attiecīgā rokasgrāmata

Testa rezultāti

3. Izmaiņu pieprasījums (IP)

Pieteikums ir klasificējams kā viena vai vairākas jaunas prasības. Izmaiņu pieprasījuma pieteikuma apstrādes process ir attēlots (skat. attēlu nr. 2)

Pasūtītājam jauno piegādi jānodod līgumā atrunātajā kārtībā (piem., ar CD vai uzliekot uz datu apmaiņas servera) ar pievienoto pavaddokumentu.

Jauna piegāde

Izlabots pirmkods

Izlabota instalācijas pakotne

Izlabota attiecīgā rokasgrāmata

Akcepttestēšanas kritēriji

NP akts

Izlabots Arhitektūras dokuments

4.5. Incidentu reakcijas un novēršanas laiki

Sistēmas uzturēšanas periodā tiek nodrošināta pieteikumu klasifikācija saskaņā ar šādām pieteikumu kategorijām (skat. Tabula 2):

Tabula 2.

Pieteikuma kategorija

Kategorijas apraksts Reakcijas laiks

Maksimālais novēršanas

laiks1

1. Kritisks Incidents izraisa pilnīgu sistēmas (p.1.5.1.) to integrāciju ar citām informācijas sistēmām darbības apstāšanos un/vai darbs nevar tikt turpināts

30

min.

4

darba stundas

2. Augsts Kļūda, kuru nevar apiet: Incidents izraisa iekšēju programmatūras kļūdu vai nekorektu darbību, kas rada funkcionalitātes zudumus. Nav zināms (Pasūtītājam) pieņemams incidenta apiešanas risinājums, tomēr ir iespējams darbu turpināt ierobežotā režīmā;

1

stundas

8

darba stundas

1 Pretendents saskaņā ar Iepirkuma nolikumu piedāvā savu incidentu novēršanas laiku, kas nevar būt ilgāks par šajā tabulā norādīto maksimālo novēršanas laiku.

Pieteikuma kategorija

Kategorijas apraksts Reakcijas laiks

Maksimālais novēršanas

laiks1

3. Vidējs Incidents izraisa minimālus iespēju zudumus. Ietekme uz sistēmu ir mazsvarīga/sagādā zināmas neērtības;

1

darba diena

5

darba dienas

4. Zems Incidents neizraisa iespēju zudumus un ir uzskatāma par programmatūras kļūdu, neprecizitāti vai nekorektu darbību, kuras ietekmi uz darba turpināšanu var neņemt vērā. Šeit ietilpst arī kļūdas/ neprecizitātes produkta dokumentācijā;

2

darba dienas

10

darba dienas

5.Konsultācija Incidents neizraisa iespēju zudumus. Programmatūrā nav kļūdas, bet ir radusies kāda neskaidrība par sistēmas darbību vai funkcionalitāti, izmantošanu, tehnisko apkalpošanu u.c.;

4

stundas

2

darba dienas

6.Izmaiņu pieprasījums

Pieteikums tiek risināts saskaņā ar atsevišķu izmaiņu pieprasījumu apstrādes procedūru;

3

darba dienas

Piedāvājuma (izmaksas,

termiņi) sagatavošanas laiks 5 darba

dienas

Ar reakcijas laiku tiek saprasts laiks no pieteikuma saņemšanas (reģistrēšanas VEDUS) līdz brīdim, kad no Izpildītāju puses tiek nozīmēti konkrēti atbildīgie pieteikuma apstrādei un uzsākta incidents risināšana.

Ar novēršanas laiku tiek saprasts laiks no incidenta risināšanas uzsākšanas laika līdz brīdim, kad incidents ir atrisināts un novērsti tā cēloņi vai arī incidenta pieteikumu kategorija tiek samazināta (jauns incidenta novēršanas laiks), ja ir atrasts pagaidu risinājums, vai ir apstiprināti tālākie incidenta risināšanas soļi un termiņi, ko Pasūtītājs ir apstiprinājis vienotajā elektroniskajā darba uzdevumu sistēmā.

4.6. Uzturēšanas pakalpojuma ietvaros Pretendentam nepieciešams nodrošināt, ka gadījumā, ja tiek izdots IS darbības nodrošināšanā izmantotās standartprogrammatūras (trešās puses programmatūra) jauninājums, Pretendents pēc Pasūtītāja pieprasījuma sniedz atzinumu par jauninājuma ietekmi uz IS darbību un gadījumā, ja, lai nodrošinātu jauninājuma uzstādīšanu nepieciešamas izmaiņas IS programmatūrā, sniedz izvērtējumu par šādu izmaiņu darbietilpību. Šādi Pasūtītāja pieteikumi tiek apstrādāti, kā 3.prioritātes pieteikumi, un izvērtējumu Pretendents sniedz Pasūtītājam 5 darba dienu laikā. Ja standartprogrammatūras (trešās puses programmatūra) jauninājums ir kritisks IS drošībai, Izvērtējumu Pretendents sniedz īsākā laikā, par ko puses vienojas atsevišķi.

4.7. Uzturēšanas pakalpojuma ietvaros Pretendentam nepieciešams nodrošināt, ka gadījumā, ja Pasūtītājam ir nepieciešams veikt izmaiņas IS izmantojot savus cilvēkresursus, Pretendents pēc Pasūtītāja pieprasījuma sniedz atzinumu par izmaiņu ietekmi uz IS darbību un nepieciešamības gadījumā sniedz konsultāciju (piem., uzstādīšana, iestatījumi, datu migrācija), lai nodrošinātu nepieciešamo izmaiņu ieviešanu IS programmatūrā. Šādi Pasūtītāja pieteikumi tiek apstrādāti, kā 3.prioritātes pieteikumi, un izvērtējumu Pretendents sniedz Pasūtītājam 5 darba dienu laikā. Ja standartprogrammatūras (trešās puses programmatūra) jauninājums ir kritisks IS drošībai, Izvērtējumu Pretendents sniedz īsākā laikā, par ko puses vienojas atsevišķi.

4.8. Kļūdas drošības jautājumos tiek klasificētas ar augstu kategoriju (1. vai 2.).

4.9. Pretendentam bez papildus samaksas ir jāveic arī Pasūtītāja datu labošana/atjaunošana, ja datu bojājumi radušies kļūdu vai nepilnību dēļ piegādātajā programmatūrā.

4.10. Piedāvātās pieteikumu risināšanas darba plūsmas ir attēlotas attēlā 1. un 2..:

1.att. Incidenta risināšanas darba plūsma:

5. IZMAIŅU PIEPRASĪJUMS (IS PILNVEIDOŠANA).

5.1. Pieteikums ir klasificējams kā viena vai vairākas jaunas prasības.

5.2. Pieteikums tiek risināts saskaņā ar atsevišķu izmaiņu pieprasījumu apstrādes procedūru Pasūtītāja pieteikumu apstrādes sistēmā VEDUS;

Izmaiņu pieprasījuma spēkā esošais pieteikuma apstrādes process ir attēlots (skat. attēlu nr. 2.).

5.3. Izpildītāja atbildība ietver sekojošo:

5.3.1. IS arhitektūras prasību ievērošana. Ja izmaiņu pieprasījumam ir ietekme uz IS kopējo arhitektūru, tad Pretendents veic izmaiņu ietekmes novērtējumu un saskaņo to ar Pasūtītāju.

5.3.2. Sistēmā veikto izmaiņu ieviešanas process jānodrošina atbilstoši ISO 27001 labās prakses standartam, kas ir būtisks faktors, lai nodrošinātu kvalitatīvu sistēmas uzturēšanu;

5.3.3. Veikt izmaiņas atbilstoši Pasūtītāja noteiktam izmaiņu pieprasījuma spēkā esošai darba plūsmai (skat. 2.att. Izmaiņu pieprasījuma darba plūsma);

5.3.4. Veic novērtējumu nepieciešamajām izmaiņām 10 (desmit) darba dienu laikā pēc tās saņemšanas un saskaņo to ar Pasūtītāju. Ja izmaiņu pieteikuma novērtēšana objektīvu apstākļu dēļ nav iespējama 10 darba dienu laikā, Izpildītājs par to informē Pasūtītāja pilnvarotos pārstāvjus un vienojas par citiem novērtējuma iesniegšanas termiņiem ;

5.3.5. Visas pieteiktās izmaiņas Pretendentu pusē apstiprina Pretendentu izmaiņu vadītājs;

5.3.6. Norāda paredzamo izmaiņu realizācijas izstrādi cilvēkstundās;

5.3.7. Norāda izmaiņu realizācijas izmaksas, pamatojoties uz izstrādes novērtējumu un cilvēkstundas likmi;

5.3.7. Norāda paredzamo izmaiņu realizācijas termiņu, iekļaujot arī termiņu, kāds nepieciešams, lai veiktu testus Pasūtītāja akcepttesta un produkcijas vidē. Jāparedz nepieciešamais laiks visu izstrādāto programmatūras dokumentāciju atjaunošanai.

5.3.8. Norāda izmaiņu realizācijas ietekmi uz IS to integrāciju ar citām informācijas sistēmām esošo funkcionalitāti, ja šāda ietekme ir iespējama;

5.3.9. Jebkuru izmaiņu pieprasījuma realizācijas novērtējumu jāsaskaņo ar Pasūtītāju. Pēc tam, kad Pasūtītājs ir apstiprinājis Pretendenta iesniegto izmaiņu pieprasījuma novērtējumu vai arī novērtējumu, kurā ir veiktas savstarpēji apstiprinātas izmaiņas, Pretendents veic izmaiņu izstrādi, testēšanu un lietotāju dokumentācijas papildināšanu, pamatojoties uz Pasūtītāja prasībām un saskaņoto vienošanos par darbu izpildi un izpildes termiņiem.

5.3.10. Izmaiņu pieprasījuma izstrādes un testēšanas process beidzas, kad Pasūtītājs apstiprina, ka izmaiņu pieprasījums realizēts atbilstoši prasībām, un abpusēji parakstīts darbu nodošanas/pieņemšanas akts.

5.3.11. Pretendents izstrādātām un ieviestām izmaiņām Izpildītājs nodrošina garantijas uzturēšanu 24 mēnešus no izmaiņu realizācijas nodošanas/pieņemšanas akta parakstīšanas dienas un garantijas laikā konstatētās kļūdas tiek novērstas bez papildus maksas.

5.3.12. Garantijas perioda laikā par izmaiņu pieprasījumu nevar uzskatīt loģiskās kļūdas projektējumā vai projektējumam un prasībām (PPA, PPS) neatbilstošas realizācijas programmatūras kodā, kā arī izmaiņu pieprasījumu realizācijas laikā spēkā esošu standartu un vadlīniju neievērošanu.

5.3.13. Pasūtītājam nodot nepieciešamo dokumentāciju, pirmkodu saistībā ar izmaiņu ieviešanu;

5.3.14. Norāda izmaiņu ieviešanas procesa atbildīgo kontaktpersonu;

5.3.15. No Izpildītāja puses pieteikumus var apstrādāt Izpildītāja norādītās kontaktpersonas;

5.3.16. Preventīvās uzturēšanas nodrošināšana – Sistēmas uzlabojumi, kas tiek veikti iespējamo incidentu novēršanai, pirms šis incidents ir skaris Sistēmas darbības kvalitāti;

5.3.17. Pasūtītājam jauno laidienu jānodod līgumā atrunātajā kārtībā (piem., ar CD vai uzliekot uz datu apmaiņas servera) ar pievienoto pavaddokumentu.

5.4. Pasūtītāja atbildība ietver:

5.4.1. Sniegt nepieciešamo informāciju, izmaiņu prasību precizēšanai;

5.4.2. Norādīt atbildīgo kontaktpersonu, ar kuru kontaktēties izmaiņu ieviešanas procesa laikā;

5.4.3. Nodrošināt, ka no Pasūtītāja puses izmaiņu pieprasījumus var pieteikt pasūtītāja norādītās kontaktpersonas, kurām atbilstoši pasūtītāja pieprasījumam vai līgumā atrunātajam tiks izveidoti lietotāju profili.

2.att. Izmaiņu pieprasījuma darba plūsma:

6. PRASĪBAS PIEGĀŽU NOFORMĒŠANAI UN PIEGĀDEI

6.1. Izmaiņas IS programmatūrā (pieteikto kļūdu labojumi, izmaiņu pieteikumi) Pretendents noformē kā programmatūras Piegādes un iesniedz Pasūtītājam uzstādīšanai atbilstoši Pasūtītāja kārtībai, kādā piegādājamas Piegādes uzstādīšanai uz LVRTC pārziņā esošiem tehniskiem resursiem. Piegādes Pretendents piegādā izmantojot Pasūtītāja VEDUS pieteikuma sistēmu. Programmatūras Piegāde sastāv no:

6.1.1. Piegādes instalācijas pakotnes (nepieciešamās datnes, lai veiktu izmaiņu uzstādīšanu );

6.1.2. Piegādes piezīmēm:

6.1.3. Piegādes identifikatora numura, kam jāsastāv no:

6.1.3.1. Piegādātāja saīsināts nosaukums;

6.1.3.2. Sistēmas nosaukuma saīsinājums;

6.1.3.3. Sistēmas moduļa un komponentes saīsinājums;

6.1.3.4. Piegādes datuma;

6.1.3.5. Piegādes numura;

6.1.4. Piegādē iekļauto izmaiņu un/vai uzlabojumu apraksta, kas ietver programmatūras funkcionālo izmaiņu aprakstu;

6.1.5. Iepriekšējo piegāžu izmaiņu vēsture;

6.1.6. Piegādes instalācijas instrukcijas;

6.1.7. Zināmiem ierobežojumiem (known issues);

6.1.8. Programmatūras pirmkoda.

6.1.9. Atjaunotu programmatūras prasību specifikācijas (PPS dokumentācija),

6.1.10. Starpsistēmu saskarņu specifikācijas

6.1.11. Trešās puses programmatūras dokumentācijas (pēc Pasūtītāja pieprasījuma)

6.1.12. Atjaunotas Lietotāju rokasgrāmatas

6.1.13. Testa scenārijiem un testa rezultātiem.

6.2. Piegādēm ir jābūt kvalitatīvi notestētiem Pretendenta pusē, nodrošinot augstu nodevumu kvalitāti un drošību. Pretendents veiks drošības testēšanu atbilstoši IT drošības pārvaldības nozares standartiem. Rezultātā Pretendents iesniegs apliecinājumus testu rezultātiem un izmantotām testu metodikām, kas apliecinās, ka Sistēma atbilst drošības un veiktspējas prasībām

6.3. Piegādi Pasūtītājs uzstāda Pasūtītāja testa (akcepttesta) vidē un pēc akceptēšanas arī produkcijas vidē. Programmatūras piegādi Pasūtītājs akceptē parakstot pieņemšanas – nodošanas aktu, ja tiek veikta sekmīga piegādē iekļauto izmaiņu akcepttestēšana produkcijas vidē. Ja akcepttestēšanas gaitā tiek konstatētas 1. vai 2. prioritātes kļūdas, iesniegtā Piegāde netiek akceptēta un tiek atgriezts Izstrādātājam konstatēto kļūdu novēršanai.

6.4. Piegādātājs nodrošina atbalstu piegāžu uzstādīšanai klātienē pie Pasūtītāja un Pasūtītāja noteiktajos laikos.

6.5. Piegādātās programmatūras izmaiņas nedrīkst negatīvi ietekmēt IS veiktspējas rādītājus. Ar IS veiktspējas rādītājiem tiek saprasts:

6.5.1. laiks, kas nepieciešams atsevišķu darbību kopuma veikšanai izpildot IS;

6.5.2. laiks, kas nepieciešams IS lietotāju saskarnes formu atvēršanai;

6.5.3. reakcijas laiks uz lietotāju veiktajām darbībām IS lietotāju saskarnes formā.

6.6. Pie jebkādu IS piegādes nodošanas, Pretendents nodod Pasūtītājam programmatūras pirmkodu un izpildkodu, kā arī IS dokumentācijas atjaunotu versiju atbilstoši punkta 6. prasībām.

6.7. Piegādē iekļautajiem programmatūras pirmkodiem ir jābūt skaidri un precīzi dokumentētiem. Tai skaitā programmatūras kodam jāsatur komentāri, kas ir saprotami atbilstošas kvalifikācijas speciālistiem (sistēmu analītiķis, programmētājs) bez pirmkoda autora palīdzības un

atbilst programmatūras izstrādes standartiem. Programmatūras pirmkodā komentāru veidā ir jābūt norādītai vismaz šādai informācijai:

6.7.2. veiktie labojumi, to autori un labošanas datumi;

6.7.3. konkrētā faila autors, izveidošanas datums;

6.8. Izpildītājam ir jāveic ārkārtas piegādes gadījumos, ja programmatūras problēmu novēršanai nav iespējams gaidīt līdz nākamās piegādes termiņam, piemēram, novēršot 1. un 2. prioritātes problēmu pieteikumus.

7. PROGRAMMATŪRAS LIETOJAMĪBAS TESTĒŠANA UN LIETOTĀJA SASKARŅU (EKRĀNU FORMAS) PROTOTIPI

7.1. Ja Izmaiņu pieprasījumu realizācija ietekmē IS programmatūras aplikācijas daļu, Pretendentam ir jāpiegādā IS programmatūras lietotāja saskarņu prototipi, kas ir lietotāja ekrāna formu piemēri, kas ilustrē sistēmas darbību no lietotāja viedokļa. Programmatūras lietotāja saskarņu prototipos ir jādemonstrē ekrāna formu vispārējais projektējums, dizains, ievadāmās/izvadāmās informācijas apjoms, lietotāja kontroles un citi elementi, kas papildinot programmatūras prasību specifikāciju, nodrošina labāku vienotas izpratnes panākšanu starp Izstrādātāju un Pasūtītāju.

7.2. Lietotāju saskarņu lietojamības testēšana:

7.2.1. Izmaiņu pieprasījumu izstrādes ietvaros, kurā tiek izstrādātas vai pilnveidotas IS lietotāju saskarnes, lietotāju saskarnes izveide vai pilnveidoš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) vai ekvivalents;

7.2.1.1. Pirms IS lietotāja saskarnes pilnveidošanas ir jāveic esošās lietotāja saskarnes lietojamības tests vismaz vienā iterācijā izmantojot vismaz šādas testa pieejas:

7.2.1.1.1. Heiristiskais (intuitīvais) novērtējums;

7.2.1.1.2. Izpildot klātienes lietojamības testu ar ne vairāk kā pieciem reāliem sistēmas lietotājiem.

7.2.1.2. Pirms klātienes lietojamības testa uzsākšanas Izstrādātājs sagatavo testēšanas plānu, kurā iekļauj informāciju par mērķiem un uzdevumiem, kurus testa dalībniekiem būs jāsasniedz vai jāizpilda testu laikā, kā arī lietojamības testu gaitas aprakstu. Testēšanas plāns jāsaskaņo ar Pasūtītāju.

7.2.1.3. Pasūtītājs organizēs testa dalībniekus un tiem jābūt neatkarīgām personām, kas nav piedalījušies šīs konkrētās lietotāju saskarņu izstrādes procesā.

7.2.1.4. Pasūtītājs testos piedalīsies, kā neatkarīgs novērotājs, kura komentāri ir jāņem vērā lietojamības ziņojuma sagatavošanā.

7.2.1.5. Izstrādātājam ir jāorganizē un jāveic lietojamības testus. Par klātienes lietojamības testu iterācijas skaitu pasūtītāji vienojas atsevišķi prototipu testēšanas plānā.

7.2.1.6. Testu gala rezultātā ir jāsagatavo lietojamības ziņojums – rekomendācija, kurā jāietver:

7.2.1.6.1. Testu laikā fiksētie komentāri, to tips un svarīgums;

7.2.1.6.2. Priekšlikumi identificēto problēmu novēršanai;

7.2.1.6.3. Pozitīvās atziņas.

7.2.1.6.4. Heiristiskā novērtējuma kopsavilkums.

7.2.1.7. Katras iterācijas lietojamības ziņojums ir jāsaskaņo ar Pasūtītāju.

7.2.1.8. Ņemot vērā saskaņotā lietojamības ziņojumā konstatēto, Izstrādātājam jāizstrādā un kopā ar PPS jāpiegādā pilnveidojamās lietotāju saskarnes prototips.

7.3. Lietotāju saskarņu (jaunu vai esošu) lietojamības testēšanas nepieciešamību Pasūtītājas definēs katrā Izmaiņu pieprasījumā atsevišķi.

8. PRASĪBAS DOKUMENTĀCIJAS UZTURĒŠANAI

Dokumentācija tiks veidota kā esošās sistēmas dokumentācijas papildinājumi, kā rezultātā programmatūras prasību specifikācijā, administratora rokasgrāmatā un lietotāja rokasgrāmatā būs visa informācija par risinājuma funkcionalitāti.

8.1. Dokumentācijas standarts

Izpildītājam ir jāizstrādā, jāsaskaņo ar Pasūtītāju un jāpiegādā dokumentācijas atbilstoši sekojošiem standartiem:

8.1.1. “IEEE/EIA 12207 (izmantojot vismaz standarta IEEE/EIA 12207.1 daļas sekojošas sadaļas: 6.3, 6.22, 6.25, 6.26);”

8.1.2. LVS 66:1996 "Programmatūras lietotāja dokumentācija" prasībām (vienojoties ar Pasūtītāju piegādātājs var apvienot vairākas rokasgrāmatas vienā)

8.2. Arhitektūras dokumentu izstrāde un saskaņošana

Izpildītājam ieviešot izmaiņu pieprasījumu ir jāsaskaņo ar Pasūtītāju un jāpiegādā sekojoša dokumentācija:

8.2.1. sistēmas arhitektūras dokuments, kurš tiks veidots kā esošās dokumentācijas papildinājums

8.2.2. Rokasgrāmatu izstrāde un saskaņošana. Izpildītājam ir jāpiegādā sekojoša dokumentācija:

8.2.2.1. instalācijas rokasgrāmata (t.sk. Sistēmas klienta instalēšanas instrukcijas);

8.2.2.2. administratora rokasgrāmata;

8.2.2.3. uzturēšanas rokasgrāmata;

8.2.2.4. lietotāja rokasgrāmata;

8.2.2.5. specificētās saskarnes ar ārējām sistēmām.

8.3. Dokumentācijai jābūt latviešu valodā un jātiek piegādātai elektroniskā veidā.

8.4. Trešās puses programmatūras dokumentācija

Izpildītājam ir jāpiegādā trešās puses programmatūras lietotāja dokumentācija uz pastāvīga datu nesēja (piemēram, CD vai DVD matricā) vai arī, sasakņojot ar Pasūtītāju, jānodrošina iespēja to lejupielādēt Izpildītāja tīmekļa mājas lapā. Trešās puses programmatūras dokumentācija var tikt piegādāta formā, kādā to izlaiž tās oriģinālais ražotājs.

9. PRASĪBAS DARBU ORGANIZĀCIJAI

9.1. Pretendentam darbu realizācijas laikā ir jānodrošina kvalitātes pārvaldības procesi, kas nodrošinātu prasībām atbilstoša programmprodukta izstrādi un piegādi.

9.2. Konfigurāciju vadība

9.2.1. Pretendentam programmatūras projekta realizācijas un sistēmas garantijas apkalpošanas laikā ir jānodrošina atbilstoša konfigurāciju pārvaldība, lai nodrošinātu pirmkoda un dokumentācijas konfigurāciju integritāti.

9.2.2. Pretendentam ir jāuztur automatizēta vide, kas nodrošina konfigurāciju pārvaldības uzdevumus.

9.3. Lai nodrošinātu komunikāciju un lēmumu pieņemšanu, Pretendentam un Pasūtītājs darba realizācijas laikā, ja nepieciešams, nodrošinās kopējas darbu vadības sanāksmes, kurās piedalīsies kompetenti un pilnvaroti pušu pārstāvji.

9.4. Darbu organizēšanas sanāksmēm ir jānotiek latviešu valodā.

9.5. Darbu organizēšanas sanāksmes notiks Pasūtītāja telpās.

9.6. Darbu organizēšanas sanāksmju protokolēšana

9.6.1. Vispārīgās vienošanās izpildītājam ir jānodrošina sanāksmju protokolēšana un jāiesniedz protokoli Pasūtītājam saskaņošanai un apstiprināšanai.

9.6.2. Sanāksmju protokolos ir jāiekļauj vismaz pieņemto lēmumu saraksts, pilnvarotās personas, izpildes termiņi un pārskats par iepriekšējās sanāksmēs nolemto jautājumu izpildi.

9.7. Darbu organizēšanas sanāksmes tiks noturētas pēc vajadzības bet ne retāk kā reizi 1 (vienā) mēnesī, par to paziņojot vismaz trīs darba dienas iepriekš (pievienojot ierosināto sanāksmes darba kārtību).