Vidzemes plānošanas reģions
Vidzemes plānošanas reģions
Tehniskā specifikācija
Programmatūras izstrāde transportam pēc pieprasījuma projektā
„Mobilitātes un pakalpojumu pieejamības palielināšana demogrāfisko pārmaiņu skartajos reģionos”
Cēsis, 2019
Pasūtītājs –„Vidzemes plānošanas reģions” (turpmāk tekstā saīsināti - VPR), Bērzaines 5, Cēsis, LV- 4101.
Līguma izpildes termiņš – 4 mēneši no līguma parakstīšanas datuma.
Saturs
1.2. Saīsinājumi un definīcijas 5
1.3. Prasību apraksta skaidrojums 7
1.4. Dokumenta satura pārskats 8
2.Programmatūras sistēmas xxxxxxxx 0
2.1. Vispārējs biznesa procesa apraksts, sadarbība ar citām informācijas sistēmām 9
2.2. Projekta realizācijas rezultāts 11
3.2.1. Sistēmas administrēšanas funkcijas 16
3.3. Izstrādes un piegādes metodika 16
3.4.1. Risinājuma izveidei nepieciešamās infrastruktūras definēšana 16
3.4.2. Piegādājamā programmatūra 17
3.4.3. Piegādājamā dokumentācija 18
3.4.4. Atbalsta pakalpojumi līdz ieviešanai (konfigurēšana) 18
3.4.5. Risinājuma izveidei un darbināšanai nepieciešamo licenču piegāde 19
1. Ievads
1.1. Dokumenta nolūks
Tehniskā specifikācija nosaka prasības transportam pēc pieprasījuma informāciju sistēmai (turpmāk tekstā - TPPIS).
Mērķis ir izstrādāt novatorisku un ilgtspējīgu TPPIS mobilitātes centriem (MC), kas tiks izveidoti partneru reģionos kā programmatūra cilvēku un pakalpojumu sniedzēju mobilitātes koordinēšanai un apvienošanai.
TPP tiek veidots projekta “Mobilitātes un pakalpojumu pieejamības palielināšana demogrāfisko pārmaiņu skartajos reģionos (MAMBA)” ietvaros. Projekts tiek realizēts INTERREG Baltijas jūras reģiona transnacionālās sadarbības programmas 2014.–2020. gadam ietvaros. Projekta numurs: #R067. Vairāk informācijas par projektu var uzzināt šeit: xxxxx://xxx.xxxxxxxxxxxx.xx/ un VPR mājas lapā xxx.xxxxxxx.xx.
TPPIS tiks pārvaldīti braukt gribētāju reisi, mobilitātes centros pārvaldīs braukt gribētāju pieteikumus, bet transporta vadītāji saņems rīkojumus no mobilitātes centriem. Cilvēki varēs iepazīties ar iespējām, kā pārvietoties un citu informāciju publiskajā vietnē.
Dokuments ir paredzēts darbam šādiem mērķiem:
• pretendentiem, lai sagatavotu tehnisko piedāvājumu TPPIS iepirkumam;
• Pasūtītājam, iepirkuma komisijai un Pasūtītāja pieaicinātiem trešās puses pārstāvjiem, lai
izvērtētu iesniegto piedāvājumu atbilstību noteiktajām iepirkuma prasībām.
Pēc iepirkuma dokuments ir saistošs tā uzvarētājam (Piegādātājam), lai nodrošinātu piedāvāto pakalpojumu piegādes atbilstību prasībām; Pasūtītājam un Pasūtītāja pieaicinātiem trešās puses pārstāvjiem, lai pārbaudītu sniegto pakalpojumu atbilstību dokumentā noteiktajām kvalitātes prasībām (izvirzītās prasības, apjoms, kvalitāte). Tehniskā specifikācija aptver TPPIS izstrādes, ieviešanas un garantijas pakalpojumus. Darbības sfērā tiek iekļauta arī lietotāju apmācība.
1.2. Saīsinājumi un definīcijas
Lai nodrošinātu viennozīmīgu izpratni par dokumentā lietotajiem terminiem, nosaukumiem un
saīsinājumiem, zemāk pievienotā tabulā ir doti to skaidrojumi un definīcijas.
Termins, saīsinājums | Skaidrojums |
DBVS | Datu bāzu vadības sistēma |
Ģeotelpiskie dati | Jebkura informācija, kas satur tiešas vai netiešas atsauces uz konkrētu atrašanās vietu vai ģeogrāfisku apgabalu. Par ģeotelpiskiem datiem ir jāuzskata arī tie tabulārie burtciparu dati, kuros tiek glabāta informācija par objektu, parādību vai notikumu atrašanās vietu (piemēram: x, y, z koordinātas; adreses; attālumi pa lineārām struktūrām (upēm, autoceļiem, dzelzceļiem) no kāda pieņemta atskaites punkta) vai norāde uz kādu ģeotelpisko pamatdatu objektu. |
ĢIS | Ģeotelpiskās informācijas sistēma |
HTML | No angļu Hyper Text Markup Language |
HTTP | Hiperteksta pārraides protokols, izmantots vispasaules tīmeklī kā pamata komunikāciju protokols |
HTTPS | Komunikāciju protokols šifrētai komunikācijai datortīklos, balstās uz HTTP, izmantojot SSL |
IS | Informācijas sistēma |
Izpildītājs | TPPIS izstrādātājs |
MAMBA | Projekts “Mobilitātes un pakalpojumu pieejamības palielināšana demogrāfisko pārmaiņu skartajos reģionos” |
MC | Mobilitātes centri |
Pasūtītājs | Vidzemes plānošanas reģions |
PHP | Hypertext Preprocessor |
SQL | Strukturētā pieprasījumu valoda (No angļu Structured Query Language) |
SSL | (No angļu Secure Sockets Layer) – asimetrisks kriptogrāfisks datu apmaiņas protokols vispasaules tīmeklī drošai komunikācijai datortīklā |
TLS | (No angļu Transport Layer Security) ) – asimetrisks kriptogrāfisks datu apmaiņas protokols vispasaules tīmeklī drošai komunikācijai datortīklā |
TPP | Transports pēc pieprasījuma |
TPPIS | Informācija sistēma transportam pēc pieprasījuma |
VARIS | Valsts adrešu reģistra informāciju sistēma |
VDAR | Vispārīgā datu aizsardzības regula |
Termins, saīsinājums | Skaidrojums |
VPR | Vidzemes plānošanas reģions |
WYSIWYG | What You See Is What You Get |
WWW | Globālais tīmeklis (No angļu World Wide Web) |
1.3. Prasību apraksta skaidrojums
Katrai tehniskās specifikācijas prasībai ir šāda struktūra:
• identifikators – trīsciparu skaitlis, kas apzīmē konkrētās prasības kārtas numuru. Identifikatora numerācija ir sakārtota augošā secībā sākot ar 001 un ļauj 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 ātru orientēšanos tajā (ātra konkrētās prasības atrašana, tehniskās specifikācijas sasaiste ar nolikumu u.tml.);
• prasības nosaukums – konkrētas prasības virsraksts;
• prasības apraksts – konkrētās izpildāmās prasības apraksts. Pietiekami detalizēts prasības apraksts, kas ļauj Pasūtītājam novērtēt Pretendenta tehniskā piedāvājuma un Piegādātāja piegādātā risinājuma atbilstību iepirkuma mērķiem un uzdevumiem, savukārt, Piegādātājam (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ā.
Realizējot projektu, Piegādātājam ir jāņem vērā šādi prasību interpretācijas ierobežojumi:
• Pretendentam, sagatavojot piedāvājumu, kā arī Piegādātājam, veicot projekta realizāciju, risinājuma piegādi, pielāgošanu un/vai izstrādi, ieviešanu un garantijas pakalpojumu sniegšanu un, izpildot citus šajā Tehniskajā specifikācijā noteiktos darbus (piemēram, lietotāju apmācības), ir jānodrošina atbilstība Tehniskās specifikācijas prasībām. Visas Tehniskajā specifikācijā izteiktās prasības ir saistošas, neatkarīgi no tā, kurā dokumenta daļā tās ir izteiktas.
• Ja prasības formulējumā ir vārds „vismaz”, tad tālākais prasības izklāsts nosaka minimālo prasības izpildes līmeni. Pretendentam ir tiesības paplašināt prasības izpildes līmeni.
1.4. Dokumenta satura pārskats
Dokuments sastāv no 3 (trīs) nodalījumiem:
• 1.nodalījumā (Ievads) aprakstīta dokumenta kopējā struktūra, dokumenta nolūks, izmantotie apzīmējumi un jēdzieni un prasību apraksta skaidrojums;
• 2.nodalījumā (Programmatūras sistēmas pārskats) ir definēts TPPIS konceptuālais redzējums un sasniedzamais rezultāts projekta realizācijas laikā un nākotnes perspektīvā;
• 3.nodalījumā (Risinājuma prasības) ir specificētas TPPIS prasības funkcionalitātei, nodevumiem un izstrādes un piegādes metodikai;
Dokumentu ieteicams lasīt nodalījumu numerācijas secībā.
2. Programmatūras sistēmas pārskats
2.1. Vispārējs biznesa procesa apraksts, sadarbība ar citām informācijas sistēmām
VPR teritorijā ir zemākais iedzīvotāju blīvums no visiem plānošanas reģioniem, iedzīvotāju skaits gadu no gada sarūk, bet iedzīvotājiem pārvietošanās iespējas ir jābūt nodrošinātas. Lai nodrošinātu Sabiedriskā transporta pakalpojumu likuma darbību, VPR ir iesaistījies projektā MAMBA. Projekta mērķis ir uzlabot mobilitātes pakalpojumu pieejamību attālajos lauku apvidos un demogrāfisko pārmaiņu skartajos reģionos, un pilnveidot transporta pakalpojumu sniedzēju kapacitāti. Kā viens no projekta rezultātiem ir MC pilotprojekta izveide divās pašvaldībās:
• Transporta un pakalpojumu sniedzēju vadības pilnveidošana;
• Zvanu centru un elektroniskās pakalpojumu informācijas sistēmas izveide iedzīvotajiem;
• Izveidota platformu valsts/pašvaldību un privātajam sektoram transporta pakalpojumu apvienošanā;
• Sekmēta sadarbība starp sabiedriskā transporta sniedzējam un pakalpojuma nodrošinātājiem. TPPIS tiek veidots ar mērķi, lai pilnībā veidotu un nodrošinātu transporta pēc pieprasījuma darbību. Pilotprojekti tiks realizēti Alūksnes un Mazsalacas novados.
Plānotās Transports pēc pieprasījuma pilota teritorijas Alūksnes novadā:
1. Xxxxxxx - Xxxxxxx- Xxxxx – Maģumi- -Strautiņi – Korneti uz/no Alūksni
2. Jaunlaicene Karva – Jaunlaicene; Karva – Rezaka – Alsviķi ; Alsviķi – Māriņkalns uz/ no
Alūksni
3. Apes ceļš - Celencki - Buliņš – Nēķene + Ilzenes pagrieziens uz/ no Alūksni
4. Blektes kalns un Ezīšava uz/ no Alūksni
Šīs teritorijas būs pirmās pilotējamās teritorijas projektā. Pilota laikā monitorējot pilotus, rast iespēju, ka teritorijas var paplašināt, mainīt, atcelt (novada ietvaros).
Mazsalacas novadā TPP paredzēts veidot visā Mazsalacas teritorijā, nodrošinot pagastu iedzīvotāju nokļūšanu uz / no Mazsalacas pilsētas. Kā arī, pamatojoties uz veikto iedzīvotāju aptauju – sestdienās nodrošināt nokļūšanu uz / no Rūjienu.
TPPIS tiek plānots piecās daļās:
• Publiskā daļa autentificētiem lietotājiem, kas vēlas izmantot TPP servisu, piesakot sevi reisam
konkrētā datumā, laikā. Lietotājs varēs pārvaldīt savus datus, kā arī pieteiktos reisus;
• Autorizēta daļa transporta līdzekļa vadītājam. Transporta līdzekļa vadītājs tiešsaistē saņem visus norādījumus par TTP lietotājiem, uzņemšanas vietu, kā arī var interaktīvi atzīmēt detaļas par reisa izpildi un labot reisu;
• Autorizēta daļa MC dispečeriem, kas pieņem apstrādā e-pastus, telefona zvanus, īsziņas un pienākošos paziņojums TPPIS, ko iniciē TPP klienti. Pēc ienākošiem pieprasījumiem dispečeri plāno maršrutu/reisu, piesaista konkrētu transporta līdzekļa vadītāju, informē transporta līdzekļa vadītāju par izmaiņām, ja tādas rodas;
• Autorizēta daļa administratoram, kur tiek rediģēti sistēmas parametri.
• Publiskā daļa, kur jebkurš lietotājs var iepazīties ar to, kas ir transports pēc pieprasījuma, atrunas par vispārīgo datu aizsardzības regulu, kā sazināties ar dispečeriem, lietošanas noteikumiem un citu informāciju.
Tiek plānota sadarbība arī ar citām informāciju sistēmām, lai uzlabotu programmas lietošanas ērtumu un mazinātu iespējas kļūdīties. Publiskajam lietotājam, reģistrējot savu atrašanos vietu, jāvar vai nu to atzīmēt kartē (manuāli vai ar GPS palīdzību), kā arī izmantot Valsts zemes dienesta Valsts adrešu reģistra informācijas sistēmas datus, lai precīzi atzīmētu savu atrašanās vietu.
2.2. Projekta realizācijas rezultāts
No šādas ‘biznesa’ loģikas izriet vairākas vispārējas prasības TPPIS, kas aprakstītas šajā nodaļā, bet precīzi definētas nodaļā „Risinājuma prasības”.
1. TPPIS ir jānodrošina iespēja lietotājam autorizēties ar lietotāja vārdu un paroli, lai varētu veikt
pieprasījumu reisam, kā arī to pārvaldīt, ja nepieciešams.
2. Dispečeram jāvar saņemt zvanus un autorizēto lietotāju pieprasījumus TPPIS pēc reisiem, lai veidotu apstiprinātu reisu, sazinātos un nodotu informāciju SMS vai e-pasta ziņā par apstiprināto reisu un tā detaļām, sagatavotu reisu un nodotu veicamo reisu pārvadātājam.
3. Pārvadātājam jāvar saņemt apstiprinātu reisu planšetdatorā, vienkāršā veidā interaktīvi reaģēt uz notikumiem planšetdatorā, lai maksimālu maz novērstu uzmanību no ceļa.
4. Administratoram jāvar autorizētā vidē veikt sistēmas parametru maiņu, pārvaldīt lietotājus
un to grupas.
5. Sistēmai ir jānodrošina ilgtermiņā zemas izmaksas, vienlaicīgi nodrošinot iespēju pievienot un pārvaldīt (bez licenču iegādes un uzturēšanas maksas) pietiekoši lielu skaitu autorizētu lietotāju (ar kārtu – 1000).
Risinājums veidojams tāds, lai varētu nodrošināt sistēmas attīstību un dažādu jaunu funkcionalitāšu veidošanu. Sistēma jāizstrādā tā, lai autorizētiem lietotājiem maksimāli maz būtu veicamas darbības, visi logi un ievadformas vienkāršas un viegli uztveramas kā stacionārajos datoros, tā arī mobilās iekārtās. Pogām jābūt lielām, lai skārienjutīgā ekrānā viegli nospiežamas.
Risinājumam jādarbojas maksimāli ar atvērtā koda risinājumiem. Vēlams, bet ne obligāti izmantot PHP (Hypertext Preprocessor), kas ir atvērtā koda servera puses skriptu valoda, kas pamatā domāta dinamisku tīmekļa vietņu veidošanai. Datu bāzei vēlams izmantot atvērtā koda DBVS, piemēram, MySQL vai MariaDB.
2.3. Nākotnes redzējums
Ja pilotprojekts gūs atzinību un atvieglos pieejamību mazāk apdzīvotās vietās, pastāv iespēja, ka TPPIS tiks izmantots ne tikai pilotprojekta teritorijās, bet arī visā Vidzemes teritorijā vai pat Latvijā.
3. Risinājuma prasības
3.1. Vispārīgās prasības
(001). Sistēmas izstrādes un ieviešanas laika grafiks (Obligāta)
TPPIS ir jāpiegādā un jāakceptē līdz četru mēnešu laikā kopš līguma parakstīšanas brīža.
TPPIS instalēšana produkcijas vidē jāveic atbilstoši Piegādātāja izstrādātam un Pasūtītāja apstiprinātam Ieviešanas plānam.
Sistēmas izstrādi ir plānots veikt divos posmos:
1. Sistēmas demonstrācijas prototipa un prezentācijas sagatavošana (termiņš divu mēnešu laikā kopš līguma parakstīšanas):
Šajā posmā ir nepieciešams sagatavot izstrādājamās sistēmas nepilnas versijas prototipu ar svarīgākajiem komponentiem demonstrēšanai Pasūtītājam, lai būtu iespējams pārliecināties par izvēlētā risinājuma pareizību un efektivitāti. Ja nepieciešams, Pasūtītājs var piedāvāt veikt korekcijas turpmākās realizācijas izpildei.
2. Sistēmas gala izstrāde (termiņš 2019. gada divu mēnešu laikā kopš sistēmas demonstrācijas prototipa nodošanas):
Jāpiegādā Pasūtītājam pilnībā pabeigts un akceptēts risinājums.
(002). Projekta valoda (Obligāta)
Visu šajā tehniskajā specifikācijā noteikto pakalpojumu sniegšana ir jānodrošina latviešu valodā. Nepieciešamības gadījumā Piegādātājam uz sava rēķina ir jāveic tulkošana uz/no citām Piegādātāja izvēlētajām darba valodām. Piegādātājam ir jānodrošina latviešu valoda, x.xx., bet ne tikai:
• projekta sanāksmēs;
• intervijās ar Pasūtītāju un TPPIS lietotājiem;
• administratoru apmācībās;
• visā projekta dokumentācijā un nodevumos;
• sniedzot TPPIS garantijas pakalpojumus.
(003). Interviju norises vieta (Obligāta)
Projekta laikā intervijas ir plānotas klātienē Pasūtītāja telpās (Cēsīs, Xxxxxxxxx xxxx 0) un/vai attālināti, izmantojot tīmekļa kolektīvās komunikācijas rīkus.
Interviju norise tiks organizēta darba dienās darba laikā no 9:00 līdz 17:00.
(004). Nodevumu saskaņošanas kārtība (Obligāta)
Izstrādājot projekta laika grafiku, Piegādātājam jāņem vērā šādi nodevumu saskaņošanas termiņi:
• termiņš Sistēmas vai tās daļas akcepttestēšanas veikšanai Pasūtītājam ir 10 (desmit)
darba dienas;
• atkārtota Sistēmas vai tās daļas akcepttestēšana ir jāveic pilnā apjomā, testējot visu Sistēmu (ja vien nav panākta atsevišķa rakstveida vienošanās starp visām iesaistītajām pusēm);
• termiņš pirmreizējai un atkārtotai dokumentācijas nodevuma melnraksta izskatīšanai Pasūtītājam ir 5 (piecas) darba dienas.
Piezīmes:
• atkārtota dokumentācijas nodevuma izskatīšanās procesā Pasūtītājs nevar celt jaunus iebildumus pret dokumenta daļām, kuras iepriekšējā pārskatīšanas reizē nav komentētas. Gadījumā, ja kādā projekta posmā izstrādāta funkcionalitāte, kura ietekmē iepriekš izstrādāto dokumentāciju, Piegādātājam jāveic arī iepriekš izstrādātās
dokumentācijas pārskatīšana, labojumu un papildinājumu veikšana un saskaņošana ar Pasūtītāju;
• Sistēmas vai tās daļas akcepttestēšana tiek uzsākta atbilstoši projekta plānam. Ja Sistēmas vai tās daļas instalācija testēšanas vidē aizkavējusies, apkcepttestēšana tiek uzsākta ne ātrāk, kā pēc 3 (trīs) darba dienām, ja puses nevienojas savādāk;
• Nodevumu saskaņošanas procesā Pasūtītājs ir tiesīgs iesaistīt jebkuru trešās puses pārstāvi.
(005). Veiktspējas prasības (Obligāta)
Piegādātājam jānodrošina šāda TPPIS programmatūras veiktspēja:
• vienlaicīgo lietotāju pieslēgumu skaits – 50;
• TPPIS atbildes laiki (mērot pieprasījumu izpildes laiku uz tīmekļa servera, vienlaicīgi strādājot 100 lietotājiem):
• ievadformas attēlošanai – nedrīkst pārsniegt 3 sekundes, pie noteikuma, ka netiek darbināti fona procesi).
Šī prasība ir formulēta lietotāju darbību apstrādes ātruma mērīšanai. Sistēmā nedrīkst būt ierobežojumi lielākam vienlaicīgo lietotāju sesiju skaitam, tikai tādā gadījumā ir pieļaujama ātrdarbības degradācija.
Visi augstāk norādītie rādītāji raksturo TPPIS darbības parametrus un neattiecas uz tehnisko resursu (serveru, komutatoru, tīkla pieslēguma) darbības parametriem.
(006). Drošība (Obligāta)
Visai komunikācijai starp gala lietotāju un serveri jābūt pārsūtītai, izmantojot HTTPS ar drošu TLS versiju. Neviena TPPIS sistēmas sadaļa nedrīkst būt publiska, ja vien tas nav iepriekš īpaši saskaņots vai nav nodevumu objekts. Šiem mērķiem var izmantot Let’s Encrypt, kas ir bezmaksas, automatizēts un atvērts risinājums, kā arī piemērots TPPIS.
Visam DB saturam jābūt tā šifrētam, lai ļaunprātīgas datu noplūdes gadījumā dati būtu nenolasāmi.
TPPIS ir jābūt aizsargātām pret zināmām ievainojamībām un ļaunprātīgu izmantošanu.
(007). Sasaiste ar citām informāciju sistēmām (Obligāta)
TPPIS darbosies ar dažādām ārējām sistēmām:
• VARIS. VARIS ir valsts adrešu reģistra informācijas sistēma. TPPIS ir jāvar tiešsaistē nolasīt precīzu adresi un koordinātes no VARIS, lai nodrošinātu precīzu punktu attēlošanu kartē. Šī funkcionalitāte būs nepieciešama pasažieriem, lai reģistrētu savu atrašanās vietu, kā arī dispečeriem, reģistrējot zvanītāja atrašanās vietu. Pasūtītājs nodrošinās visu atļauju un tehnisko programmatūras saskarnes specifikāciju saņemšanu no Valsts zemes dienesta, savukārt Izpildītājam jānodrošina tehniskais risinājums datu saņemšanai un apstrādei.
• Fona attēli kartēm. TPPIS jāvar attēlot kartes šāda fona karte: OpenstreetMaps. Var tikt izmantotas arī citas bezmaksas alternatīvas. Visās interaktīvās kartēs jāvar pārslēgties starp fona kartēm, kad tas nepieciešams.
3.2. Funkcionālās prasības
(008). Autorizēta daļa transporta līdzekļa vadītājam (Obligāta)
Autorizēto daļu transporta līdzekļa vadītājiem paredzēts lietot tikai planšetdatorā, kas aprīkota ar 4G, GPS moduļiem un skārienjutīgiem ekrāniem, lai nodrošinātu nepieciešamo funkcionalitāti. Programmai jāturpina funkcionēt gadījumā, ja pazūd interneta savienojums.
Piesakoties sistēmā, pārvadātājs redz sarakstu ar viņam piešķirtiem reisiem. Atverot ierakstu, var iepazīties ar kopskatu kartē, mainīt mērogu un pārvietoties pa karti, iepazīties ar pieturas punktiem, kuros jāuzņem pasažieris, viņa vārds, uzvārds un telefona numurs.
Pārvadātājs var palaist un uzsākt to reisu, kas laika ziņā notiks visdrīzāk. Ja potenciālais pasažieris piezvana transporta līdzekļa vadītājam ar vēlmi veikt izmaiņas savā plānotajā braucienā, pārvadātājam jāvar veikt pieprasītās izmaiņas
Kad reiss ir uzsākts, lielākā daļā ekrāna tiek attēlota karte. Kartē ar trīsstūrīti tiek attēlota pārvadātāja atrašanās vieta, bet trīsstūra virsotne norāda uz kustēšanās virzienu. Uzsākot braukšanu, pārvadātājam jānospiež poga uzsākt reisu, beidzot reisu, jānospiež beigt reisu.
Ekrāna sāna malā tiek attēlots saraksts, kas sakārtots secībā, kādā pasažieri ir jāuzņem. Pietuvojoties konkrētam pasažierim, jāparādās vai jāpaliek lielākām pogām, ka pasažieris uzņemts vai nav objektā.
Pēc pēdējā uzņemtā pasažiera TPPIS jāizrēķina laiks līdz nākošam klientam un, kad palikušas aptuveni 15 minūtes līdz ierašanās pie nākošā pasažiera, automātiski jānosūta SMS, ka pārvadātājs ieradīsies 15 minūšu laikā. Ja laiks līdz nākošajam pasažierim ir mazāks, TPPIS jānosūta SMS ar paziņojumu, pēc cik minūtēm aptuveni ieradīsies pārvadātājs. Jābūt konfigurējamam parametram, norādot laiku, pēc kura ieradīsies pārvadātājs, kā arī jāvar mainīt īsziņas saturs.
(009). Autorizētā daļa lietotājiem, kas izmanto TPP (Obligāta)
Lietotājs var reģistrēties sistēmā, norādot vārdu, uzvārdu, telefona numuru, e-pastu un drošu paroli. Pirmo reizi ielogojoties TPPIS, lietotājam jānorāda sava parastā uzturēšanās vieta, lai atvieglotu turpmākos pieprasījumus pēc transporta. Šo informāciju lietotājs var norādīt divos veidos: ierakstot mājas adresi (līdzīga funkcionalitāte kā VARIS xxxxx://xxx.xxxxxxxx.xx/, kur norāda pašvaldību, pagastu un mājas nosaukumu. TTPIS jāatgriež konkrēta adrese. Adresei ir piesaistītas koordinātes, lai to punktveidā attēlotu kartē), atzīmējot kartē ar punktu, kur tieši pasažieris jāuzņem.
Lietotājs var saraksta veidā apskatīt savus veiktos braucienus, kā arī uz tā bāzes izveidot jaunu
braucienu, norādot datumu un laiku.
Lietotājs nevar norādīt braucienu datumu, kas ir ātrāks par aiznākošo dienu. Tas ir, ja lietotājs reģistrē pieprasījumu pēc transporta 1. datumā, tad viņš brauciena datumu var norādīt tikai 3. datumu, ne ātrāk. Jābūt konfigurējamam lielumam stundās.
Galapunktu lietotājs atzīmē kartē, kā arī vēlamo ierašanās laiku. Vienojoties par detaļām ar dispečeru, dispečers, ja nepieciešams, koriģē galapunktu un par to informē lietotāju. Lietotājs par to tiek informēts telefona sarunā, e-pasta un īsziņas veidā, kā arī pēc tam kartē redz brauciena sākumpunktu, beigu punktu, reisu kartē, prognozēto izbraukšanas laiku un izkāpšanas laiku. Šai informācijai dinamiski jāatjaunojas bez lietotāja iejaukšanās.
Lietotājs TTPIS var jebkurā laikā atcelt savu braucienu. Lietotājam jāvar veikt izmaiņas savā pieteiktajā braucienā līdz pusnaktij, kad vēl viena diena ir palikusi līdz braucienam. Piemēram, ja brauciens ir paredzēts 3. datumā, tad lietotājs var veikt izmaiņas savā pieteiktā braucienā līdz 1. datuma plkst. 24:00. Jābūt konfigurējam lielumam.
(010). Autorizēta daļa MC dispečeriem (Obligāta)
Pieprasījumi pēc transporta var pienākt, zvanot, rakstot e-pastu vai sūtot īsziņu.
Ielogojoties TPPIS, MC dispečers redz karti, kurā attēloti pieprasījumi pēc transporta, kas veikti TPPIS.
TPPIS jāvar saņemt īsziņas, kas nosūtītas kā pieprasījums pēc transporta. Dispečeram jāvar atbildēt ar īsziņu, ka brauciens ir reģistrēts, kā arī atbildēt īsziņai ar zvanu.
Par katru no pasažieriem, kas reģistrēti sistēmā, dispečers redz visu vēsturi, kādiem reisiem viņš ir pieteicies, kad viņš ir atteicies no braucieniem, kā arī ja nav ieradies noteiktā laikā uz braucienu. Dispečers patur tiesības atteikt transportu pēc pieprasījuma, ja pasažieris trīs reizes nav ieradies uz braucieniem norunātā laikā un vietā.
Saņemot zvanu no braukt gribētāja, dispečeram jāvar viegli identificēt sistēmā lietotāju (pēc vārda, uzvārda, telefona numura vai e-pasta), to reģistrēt, ja nepieciešams. Sarunas gaitā dispečeram jāvar nekavējoties uzsākt brauciena reģistrēšanu, atzīmējot sākuma un beigu punktu braucienam, kā arī vēlamos laikus.
Kad braucieni ir reģistrēti, dispečers kārto reģistrētos braucienus šādā secība:
• Datums, kad TPP tiek pieprasīts;
• Vietas, kur jāpaņem pasažieris;
• Laiks.
Xxxxxxxxxx uz šo informāciju, dispečeram jāvar izveidot reisu, saskaņojot ar pasažieriem laiku, vietu. Kad pasažieris ir reģistrēts reisam, ieraksts un punkts kartē, kas attiecas uz konkrēto pieprasījumu, pazūd no kartes. Īsziņas un e-pasta veidā pasažieris tiek informēts par laiku un vietu, kad notiks reiss. Iepriekšējās dienā pasažieris saņem atgādinājumu SMS un e-pasta veidā par nākošā dienā notiekošo reisu, saturot informāciju par to, no kurienes uz kurieni un aptuveni cikos pēc pasažiera ieradīsies. Šo informāciju TPPIS jāvar nosūtīt automātiski. Administratoram jāvar konfigurēt e-pasta un īsziņas saturs, kā arī šo funkciju atslēgšanu vai ieslēgšanu. Ja dispečers tomēr veic izmaiņas maršrutā, par to vai nu manuāli, vai arī automātiski tiek brīdināts pasažieris.
Kad reiss ir izveidots, tam piekļūt var tikai tie dispečeri, kuru grupā tie atrodas. Pašlaik tiek plānotas divas dispečeru grupas – Alūksnes un Mazsalacas. Alūksnes grupa neredz tos reisus, ko izveidojusi Mazsalacas grupa un otrādāk. Taču Alūksnes grupā esošie dispečeri var pārvaldīt savā starpā izveidotus reisus.
Kad reiss ir pabeigts, to piesaista konkrētam pārvadātājam. Ja rodas nepieciešamība, dispečers veic labojumus reisā, un tiem dinamiski jāparādās transporta līdzekļa vadītājam, kā arī jāpienāk paziņojumam, ka konkrētā reisā ir veiktas šādās izmaiņas. Dispečers var pāriestatīt konkrēto reisu citam transporta līdzekļa vadītājam.
Dispečeram jāvar sekot līdzi reisa izpildei, redzot, kurā vietā atrodas pārvadātājs un kuri pasažieri ir uzņemti un vēl jāuzņem.
Dispečeram jāvar veidot atskaites par veiktajiem reisiem, nobrauktiem kilometriem un apkalpotajiem pasažieriem, norādot konkrētu laika periodu (jāvar kalendārā norādīt sākuma datumu un beigu datumu).
(011). Publiskā daļa (Obligāta)
Jāizstrādā publiskā daļa, kur jebkurš potenciāls transportam pēc pieprasījuma lietotājs var iepazīties ar to, kā TPP strādā, kā veicams pieprasījums, kā lietot TPPIS, VDAR, kontaktus, kā sazināties ar dispečeriem. Šim nolūkam var tikt izmantota Wordpress satura vadības sistēma, kur var veidot sadaļas un tās aizpildīt ar saturu. Administratīvā daļā jāvar aizpildīt ar WYSIWYG, jāvar pievienot attēlus, mainīt to izmēru, pievienot Youtube video, veidot sadaļas. Administratīvajā daļā jāvar nokonfigurēt un lietot Google Analytics.
Vienā no sadaļām būs interaktīva karte, kurā dispečeri pievienos jaunu maršrutu, lai lietotājiem, kuri
izmantos TTPIS, būtu orientējoši skaidrs, kur un no kurienes var izmantot TPP.
Sistēmanalīzes laikā tiks precizētas sadaļas un saturs. Netiek plānota lielākā funkcionalitāte, kā šajā punktā minēts un rakstu modulis, statiskas lapas. No publiskās daļas visiem lietotājiem jāvar autorizēties, lai piekļūtu TPPIS. Zem ielogošanās formas jābūt TPPIS lietošanas noteikumiem. Pasūtītājs ir atbildīgs par saturu, Izpildītājs par nepieciešamo funkcionalitāti.
3.2.1. Sistēmas administrēšanas funkcijas
(012). Pieejamības līmeņi (Obligāta)
Administrators var veidot dispečera grupas, kur var pievienot vairākus dispečerus. Dispečeriem nav pieejama informācija par citu grupu dispečeru izstrādātiem reisiem. Dispečeriem ir pieejama visi vienas grupas izveidotie reisi ar labošanas iespējām.
Pārvadātājs var redzēt tikai sev piešķirto reisu.
3.3. Izstrādes un piegādes metodika
(013). Pakāpeniska izstrāde un piegāde (Obligāta)
Piegādātājam ir jāveic programmatūras izstrāde un piegāde akcepttestēšanai pakāpeniski, izstrādājot funkcionalitāti, balstoties uz prioritātēm, kuras iepriekš saskaņotas ar Pasūtītāju. Risinājums Piegādātājam jāpiegādā vismaz 2 (divās) piegādēs (daļās).
Atbilstoši TPPIS piegādes (daļas) akcepttestēšanas laikā Pasūtītāja identificētiem nepieciešamiem papildinājumiem/ nepilnībām/ priekšlikumiem/ ierosinājumiem, Piegādātājam ir jāveic izmaiņu veikšana programmatūras kodā (Pasūtītājs neizvirzīs prasību analīzes laikā definētām prasībām pretrunīgas prasības, prasību papildinājumi un izmaiņas nepārsniegs 3% no projekta apjoma).
(014). Sistēmas testēšana pirms akcepttestēšanas (Obligāta)
Piegādātājam, izmantojot savu izstrādes un testēšanas vidi, ir jānodrošina TPPIS iekšēja testēšana, atbilstoši savām iekšējām procedūrām, neiesaistot Pasūtītāja darbiniekus, lai pārliecinātos par TPPIS gatavību administratoru apmācībām un TPPIS akcepttestēšanai.
(015). Akcepttestēšana (Obligāta)
TPPIS funkcionālos testus veiks Pasūtītāja darbinieki vai Pasūtītāja pieaicināti trešās puses pārstāvji, saskaņā ar projekta plānu. Piegādātājam ir jānodrošina akcepttestu norisei nepieciešamās konsultācijas.
Balstoties uz Pasūtītāja iesniegtajiem problēmziņojumiem, Piegādātājam jāveic identificēto defektu novēršana. Piegādātājam ir jānovērš akcepttestēšanas laikā konstatētie defekti un jānodrošina laiks atkārtotai akcepttestēšanai.
TPPIS ir uzskatāma par atbilstošu sākotnējai ražošanas (ekspluatācijas) uzsākšanai, ja akcepttestēšanas laikā nav konstatētas 1., 2., un 3. prioritātes problēmas (Skatīt 033. punktu). Pasūtītājs un Piegādātājs var vienoties par TPPIS ieviešanu ekspluatācijā ar atklātām, bet nenovērstām 3.prioritātes problēmām, kurām saskaņots novēršanas laiks.
TPPIS akcepttestēšanas laikā vai garantijas uzturēšanas ietvaros jānovērš visas akcepttestēšanas laikā reģistrētās 4.prioritātes problēmas.
3.4. Nodevumi
3.4.1. Risinājuma izveidei nepieciešamās infrastruktūras definēšana
(016). Minimāli nepieciešamās infrastruktūras definēšana TPPIS virtualizēšanai (Obligāta) Piegādātājam jāizstrādā virtuālās vides tehniskā specifikācija un apraksts, norādot uz nepieciešamiem parametriem (nepieciešamo virtuālo serveru skaits, procesora veiktspējas rādītāji, operatīvās atmiņas
apjoms, izolēto tīklu skaits, publisko IP adrešu skaits, interneta pieslēguma datu caurlaides apjoms un
citi nepieciešamie parametri un funkcionalitāte TPPIS uzturēšanai), ņemot vērā vismaz šādus aspektus:
• plānoto TPPIS funkcionalitāti un arhitektūru;
• plānoto informācijas vienību un lietotāju skaitu;
• definētās prasības TPPIS pieejamībai, veiktspējai, ātrdarbībai un drošībai.
Piegādātājam ir jānorāda vismaz šāda informācija: virtuālo serveru shēmas un aprakstu (virtuālo tīklu slēgumi, savienojumi ar ārējiem datu pārraides veidiem un TPPIS infrastruktūru).”
3.4.2. Piegādājamā programmatūra
(017). Sistēmas izstrāde un/vai pielāgošana (Obligāta)
Piegādātājam ir jāveic TPPIS izstrāde (programmēšana) un/vai esošas programmatūras pielāgošana un konfigurēšana, lai TPPIS nodrošinātu šajā dokumentā definētās un detalizētās sistēmanalīzes laikā precizētās prasības.
Piegādātājam ir jāpiegādā TPPIS kopā ar Pasūtītāja vajadzībām specifiski izstrādātajām konfigurācijām
un pielāgojumiem.
Piegādātājam ir jāpiegādā TPPIS izstrādātās programmatūras pirmkodu (source code), izpildkodu un instalācijas pakotni, kas ietver arī visas veiktās izmaiņas un papildinājumus. Pirmkodi nav jāpiegādā standarta programmatūrai (piemēram, operētājsistēmām, datu bāzu vadības sistēmām).
(018). Prasības koda noformējumam (Obligāta)
Piegādātajam kodam ir jāatbilst šādām prasībām:
• Jāpiegādā viss pirmkods, kas tiek izmantots sistēmas darbināšanai;
• Pirmkodam jāsatur komentāri, kas ir izmantojami un pietiekami tehniskās dokumentācijas ģenerēšanai;
• Pirmkodam komentāros automātiski jāiekļauj laidiena identifikators, izmantojot
pirmkoda kontroles rīkus (SVN, GIT);
• Kodam jānodrošina iespēja visam kodam vai atsevišķiem moduļiem ieslēgt un atslēgt atkļūdošanas režīmus, kas nodrošina iespēju veikt kļūdu trasēšanu. Jānodrošina
vismaz trīs režīmi (E-tiek ziņotas tikai kļūdas, W -tik ziņoti gan brīdinājumi, gan kļūdas,
A-tiek ziņota visa izpildes loģika). Jānodrošina iespēja konfigurēt ziņojumu piegādes kanālus (konsole, datne, sistēmas žurnāls) katram no ziņojumu veidiem (kļūda,
brīdinājums, informatīva ziņa);
• Kļūdas ziņojumi jāizvada - veicot izņēmumsituāciju apstrādi / ja programmas
vienumam tik nodoti nekorekti parametri / citos gadījumos, kad to programmas loģika;
• Brīdinājumi jāizvada - ja tiek identificētas situācijas, kad var tikt sasniegti ierobežojumi (piemēram, apstrādāto datu apjoms) / citos gadījumos, kad to prasa programmas
loģika;
• Informatīvas ziņas jāizvada - katrai programmas vienībai uzsākot izpildi / citos gadījumos, kad to prasa programmas loģika.
(019). Prasības programmatūras nodevumiem (Obligāta)
Katram programmatūras nodevumam (versijai/jauninājumam/ielāpam) jāsatur apraksts, kas identificē jaunizveidoto funkcionalitāti, realizētās izmaiņas un novērstās problēmas.
Programmatūras nodevumu piegādēm jāsatur gan izveidotā/labotā koda izejas teksti, gan instalācija (ar uzstādīšanas instrukciju), gan sistēmas konfigurācijas dati.
Programmatūras instalēšanas paketes jāpiegādā uzstādīšanai gan produkcijas vidē, gan testu vidē (ja ir tehniski iespējams, tad ir atļauts piegādāt instalēšanas paketi, kas izmantojama abās vidēs), ar norādi par instalēšanas paketes uzstādīšanas vidi, kopā ar TPPIS instalācijas ceļvedi, kas satur detalizētu operētājsistēmas, tīmekļa pakalpju servera un datu bāzes vadības sistēmas uzstādījumu aprakstu.
Katrai radītajai, kā arī papildinājumu vai izmaiņu rezultātā veidotajai 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. Papildus
“inkrementālām” instalēšanas paketēm, jāpiegādā arī “pilnā” visas programmatūras instalācijas pakete, lai Pasūtītājam būtu iespēja veikt programmatūras uzstādīšanu “jaunā” vidē.
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.
Piegādātājam, izmantojot savu izstrādes un testēšanas vidi, ir jānodrošina TPPIS iekšējā funkcionālā testēšana, atbilstoši savām iekšējām procedūrām, neiesaistot Pasūtītāja darbiniekus, lai pārliecinātos par TPPIS gatavību pirms administratoru apmācībām un TPPIS akcepttestēšanas.
Piegādātājam ir jāveic arī TPPIS veiktspējas un slodzes testi un drošības testēšana (mērķis ir pārbaudīt TPPIS veiktspēju un noslodzes noturību, noturību pret nesankcionētu pieeju, noturību pret uzbrukumiem, TPPIS drošībai kritiskās informācijas žurnalēšana).
Piegādātājam ir jānovērš testēšanas laikā atklātie defekti un jāiesniedz Pasūtītājam testēšanas protokoli par visiem veiktiem testiem un pārskats par rezultātiem.
3.4.3. Piegādājamā dokumentācija
(020). Administratora rokasgrāmata (Obligāta)
Piegādātājam jāizveido administratora rokasgrāmata (detalizēts veicamo darbību apraksts ar praktiskiem piemēriem), kas satur vismaz šādas daļas: lietotāju izveide, tiesību pārvaldība, parametru konfigurācija.
(021). Lietotāju rokasgrāmatas (Obligāta)
Piegādātājam jāizveido rokasgrāmatas (detalizēts veicamo darbību apraksts ar praktiskiem
piemēriem):
• Rokasgrāmata publiskam lietotājam (kas veic pieprasījumu reisam)
• Rokasgrāmata dispečeram;
• Rokasgrāmata pārvadātajam.
(022). Administratoru apmācības un apmācību materiāli (Obligāta)
Piegādātājam ir jāsagatavo un ar Pasūtītāju jāsaskaņo administratoru apmācību materiāli, kuriem jābalstās uz saskaņotās administratora rokasgrāmatas saturu.
Piegādātājam jāveic 1 (viena) administratora apmācības. Apmācāmo personu skaits ne vairāk kā 2 (divi). Apmācībām nepieciešamās telpas nodrošina Pasūtītājs, apmācību saturu un pasniedzēju nodrošina Piegādātājs. Kopējais apmācību ilgums – ne mazāk kā 4 mācību stundas. Apmācību tēmām jāaptver visi sistēmas administratoram veicamie uzdevumi, kas saistīti ar TPPIS uzstādīšanu, konfigurēšanu un citiem uzdevumiem, kas nepieciešami TPPIS darbības nodrošināšanai.
Apmācība jāveic pirms TPPIS akcepttestēšanas atbilstoši Piegādātāja izstrādātām un Pasūtītāja akceptētām apmācību tēmām un laika grafikam.
(023). Tehniskā dokumentācija (Obligāta)
Piegādātājam jāizveido tehniskās dokumentācijas komplekts, kas satur vismaz šādas sadaļas:
• Programmatūras prasību specifikācija;
• TPPIS arhitektūras apraksts;
• Datu bāzes struktūras un metadatu apraksts;
3.4.4. Atbalsta pakalpojumi līdz ieviešanai (konfigurēšana)
(024). Sistēmas instalēšana un konfigurēšana (Obligāta)
Piegādātajam ir jāveic TPPIS instalācija, akcepttestēšanas un ražošanas (ekspluatācijas) vidē, x.xx., serveru instalēšana un konfigurēšana (ražošanas (ekspluatācijas) vidi nodrošina Pasūtītājs, pārējās
vides jānodrošina Piegādātājam). Pakalpojumi sniedzami atbilstoši TPPIS izstrādes un ieviešanas plānam.
Ja nepieciešams, Piegādātajam ir jāsagatavo un jāveic datu ievade TPPIS administratoru apmācībām un akcepttestēšanai nepieciešamajā apjomā.
(025). TPPIS sistēmas ieviešanas plāns (Obligāta)
Piegādātajam ir jāizstrādā un ar Pasūtītāju jāsaskaņo TPPIS sistēmas ieviešanas plāns, kurā jāietver ieviešanas procesa detalizēts apraksts.
Ieviešanas plānā jāietver vismaz šādas aktivitātes:
• TPPIS instalācija ražošanas (ekspluatācijas) un apmācību vidē, x.xx., serveru instalēšana un konfigurēšana;
• TPPIS saslēgšanu un saistītajām informācijas sistēmām (šīs tehniskās specifikācijas apjomā);
• sākotnējo rādītāju un datu kopu ielāde (šīs tehniskās specifikācijas apjomā);
• sākotnējo klasifikatoru vērtību ievadi (datus nodrošina Pasūtītājs, Piegādātajam jānodrošina klasifikatora vērtību ievade (manuāla vai automatizēta));
• TPPIS sākotnējo konfigurācijas parametru ievade (konfigurācijas parametrus Piegādātajam ir jānosaka detalizētās prasību analīzes laikā, balstoties uz intervijās sniegto informāciju);
• informācijas publicēšana publiskajā daļā (veic Pasūtītājs, Piegādātājs nodrošina konsultatīvo atbalstu);
• administratoru apmācības.
Ieviešanas plānā precīzi jānorāda katra veicamā uzdevuma izpildes termiņi, atkarības un atbildība.
Piegādātajam ieviešanas plāns ir jāizstrādā un ar Pasūtītāju jāsaskaņo vismaz 1 (vienu) mēnesi pirms
TPPIS ieviešanas produkcijas vidē.
3.4.5. Risinājuma izveidei un darbināšanai nepieciešamo licenču piegāde
(026). Licenču piegāde (Obligāta)
Piegādātājam ir jāpiegādā TPPIS licence(s), kā arī tās darbināšanai nepieciešamās trešās puses programmatūras licence(s).
Piegādātajām TPPIS licencēm jānodrošina iespēja lietot TPPIS jebkurai Pasūtītāja akceptētai institūcijai vai organizācijai. Licences nedrīkst ierobežot lietotāju skaitu, aktīvās sesijas, pieslēgumu skaitu vai kādus citus ierobežojumus TPPIS darbībā.
Piegādātajām ir jāpiegādā jebkura trešās puses programmatūra, kas ir nepieciešama TPPIS izmantošanai plānotajiem apjomiem. Trešās puses programmatūra var ietvert, piemēram, operētājsistēmas, datu bāzes, lietojumprogrammu servera, OCR u.c. licences.
Trešo pušu programmatūras licenču piegāde jāveic līdz akcepttestēšanas uzsākšanai. Tehniskajā piedāvājumā ir jāiekļauj vismaz šāda informācija:
• izmantoto tehnoloģiju un trešo personu programmatūras apraksts. Trešo pušu programmatūras aprakstā ir jāiekļauj (A) komerciālās programmatūras licences, kuras Pretendents piegādās saskaņā ar piedāvājumu; (B) bezmaksas programmatūra, kas tiks izmantota TPPIS izveidei un darbināšanai saskaņā ar piedāvājumu.
• trešo personu programmatūras aprakstam ir jāiekļauj - produkta nosaukums; licences veids; apraksts un galvenās iespējas; piedāvātā versija; savietojamība ar citām piedāvājumā minētajām tehnoloģijām; tehniskā atbalsta piedāvājums; licencēšanas nosacījumi; ierobežojumi; produkta uzstādīšana un administrēšana; norāde uz tiešsaistes resursu, kurā pieejama informācija par piedāvāto produktu (ja šādi resursi nav publiski pieejami, jānodrošina iespēja piekļūt šādiem resursiem vai nu nododot
pieejas kodus, vai pievienojot tehniskajam piedāvājumam atbilstošus informatīvos materiālus uz datu nesēja).
(027). Garantijas uzturēšanas periods (Obligāta)
Piegādātājam ir jānodrošina 2 (divu) gadu garantijas periods, skaitot no TPPIS, nodošanas ekspluatācijā
dienas.
(028). Garantijas uzturēšanas pakalpojumu sniedzēji (Obligāta)
Piegādātājam visā garantijas laikā jānodrošina iepirkuma atlases dokumentācijas prasībām atbilstošas projekta realizācijas komandas iesaiste garantijas pakalpojumu sniegšanā.
Piegādātājam garantijas laikā jānodrošina vismaz vienas kontaktpersonas pieejamība, izmantojot Piegādātāja norādītos sakaru līdzekļus.
(029). Pieprasījumu reģistrācijas un izsekošanas sistēma (Obligāta)
Piegādātājam garantijas uzturēšanas laikā jānodrošina Pasūtītājam pieejama garantijas pieprasījumu reģistrācijas un izsekošanas sistēma, kurā par katru pieteikumu jābūt reģistrētai vismaz šādai informācijai:
• pieteikuma autors;
• pieteiktā prioritāte;
• ietekmētā funkcionalitāte;
• kļūdas/problēmas raksturojums;
• pieteikšanas datums un laiks;
• statuss (piemēram, reģistrēts, uzsākta apstrāde, piegādāts apvedceļš, slēgts);
• statusa maiņas datums un laiks;
• sarakstes vēsture sakarā ar pieteikumu;
• pieteikuma slēgšanas datums un laiks.
(030). Koda bibliotēka (Obligāta)
Piegādātājam jānodrošina kļūdu labojumu un laidienu izejas tekstu un konfigurācijas failu saglabāšana koda bibliotēkā. Pasūtītājs jānodrošina piekļuve pie koda bibliotēkas.
(031). Garantijas apjoms (Obligāta)
TPPIS garantijas laikā Piegādātājam bez maksas jāveic piegādātās programmatūras uzstādījumu, konfigurācijas parametru un programmatūras modifikāciju veikšana ar mērķi novērst kļūdas un datu bojājumus, kas radušies Piegādātāja apzinātas vai neapzinātas rīcības rezultātā, kāda tā bijusi, nododot TPPIS ekspluatācijā (prasība attiecas uz visiem garantijas laikā veiktajiem pieteikumiem) vai TPPIS programmatūra nenodrošina dokumentācijā norādīto funkciju realizāciju vai nenodrošina to realizāciju dokumentācijā norādītajā laikā (veiktspējas un ātrdarbības problēmas).
Piegādātājam jānovērš darbības traucējumi, ja tādi rodas, un defekti, ja tādi tiek atklāti, bez papildus maksas – pieteikumi, kuru prioritāte atbilst 1., 2. un 3. prioritātei (un tikai tie 4. prioritātes pieteikumi, kuri reģistrēti TPPIS akcepttestēšanas laikā) (Skatīt 033. punktu).
(032). Tehniskais atbalsts (Obligāta)
Garantijas uzturēšanas laikā Piegādātājam jāsniedz tehniskais atbalsts, kurš aptver šādas darbības:
• piegādātās programmatūras kļūdu labojumu piegāde, instalēšana un/vai uzstādīšana;
• Pasūtītāja datu labojumu veikšana, ja datu bojājumi radušies piegādātās
programmatūras kļūdu vai nepilnību dēļ;
• piegādātās programmatūras darbības traucējumu un/vai problēmu analīze.
Klātienes tehniskais atbalsts sniedzams, ja problēmas nav iespējams novērst ar attālinātas saziņas līdzekļiem.
(033). Problēmu prioritātes (Obligāta)
TPPIS darbināšanas problēmas garantijas laikā ir jāapstrādā ievērojot zemāk uzskaitītās prioritātes:
• 1. prioritāte: Avārija – problēma izraisa pilnīgu darbības apstāšanos, un/vai darbs
nevar tikt turpināts vai kļūdas dēļ ir nav pieejams kritisks informācijas resurss.
• 2. prioritāte: Kļūda, kuru nevar apiet – problēma izraisa iekšēju programmatūras kļūdu vai nekorektu darbību, kas rada lielus funkcionalitātes zudumus. Nav zināms
(Pasūtītājam) pieņemams problēmas apiešanas risinājums, tomēr ir iespējams darbu turpināt ierobežotā režīmā (nav pieejama ietekmētā funkcionalitāte) vai kļūdas dēļ nav pieejams svarīgs informācijas resurss;
• 3. prioritāte: Xxxxx, kuru var apiet - Problēma izraisa minimālus iespēju zudumus. Ietekme uz Sistēmu ir mazsvarīga / sagādā zināmas neērtības, piemēram, manuālu darbu Sistēmas funkcionēšanas atjaunošanai / darba turpināšanai vai nav pieejams informācijas resurss;
• 4. prioritāte: Neprecizitāte - Problēma neizraisa iespēju zudumus. Šādu pieteikumu
raksturo iekšēja programmatūras kļūda vai nekorekta darbība, kuras ietekmi uz darba turpināšanu var neņemt vērā, kļūda / neprecizitāte produkta dokumentācijā.
• 5. prioritāte: Izmaiņu pieprasījums - Pieprasījums veikt izmaiņas vai papildināt Sistēmas funkcionalitāti, dokumentāciju vai veikt citus papildus darbus, kas ir ārpus līguma apjoma vai atšķiras no iepriekš saskaņotajām prasībām (reģistrētie izmaiņu pieprasījumi tiek fiksēti vienotā pieteikumu reģistrā, bet šī projekta ietvaros izmaiņu pieprasījumu apstrāde netiek veikta).
• 6. prioritāte: Konsultācija - Problēma neizraisa iespēju zudumus. Programmatūrā nav kļūda, bet ir radusies kāda neskaidrība par Sistēmas darbību vai funkcionalitāti,
izmantošanu, tehnisko apkalpošanu (šī projekta ietvaros konsultāciju pakalpojumi netiek sniegti).
Kļūdas drošības, veiktspējas un ātrdarbības jautājumos var tikt klasificētas jebkurā no prioritātēm atkarībā no to būtiskuma.
(034). Pieteikumu iesniegšana (Obligāta)
Piesakot pieteikumu, Pasūtītāja kontaktpersona formulē pieteikumu un pieteikuma risināšanas prioritāti.
(035). Attālināta problēmu pieteikumu statusa noteikšana (Obligāta)
Piegādātājam jānodrošina iespēja Pasūtītāja nozīmētām kontaktpersonām attālināti sekot pieteikumu statusam, pieslēdzoties pieteikumu reģistrācijas sistēmai.
(036). Pieteikumu saskaņošana (Obligāta)
Katrs pieteikums tiek saskaņots. Pasūtītāja un Piegādātāja pārstāvji vienojas par pieteikuma vienotu izpratni (galīgo formulējumu, būtību, risināšanas prioritāti un citu pieteikumā norādīto informāciju). Par pieteikuma saskaņošanas organizāciju ir atbildīgs Piegādātājs.
(037). Pieteikumu slēgšana (Obligāta)
Pieteikumu risināšana tiek pārtraukta tikai saņemot Pasūtītāja apstiprinājumu pieteikumu uzskaites sistēmā, ka piedāvātais risinājums ir pieņemams vai ka pieteikumu var slēgt citu iemeslu dēļ.
(038). Reakcijas laiks uz pieteikumu (Obligāta)
Piegādātājs reaģē uz pieteikumiem zemāk norādītajos termiņos (reakcijas laiks ir laiks no pieteikuma saņemšanas brīža līdz brīdim, kad Piegādātājs paziņo, ka pieteikums ir saņemts un ir uzsākta pieteikuma apstrāde):
• 1. un 2. prioritātes pieteikumiem reakcija seko 1 (vienas) darba dienas laikā pēc pieteikuma saņemšanas;
• 3. un 4. prioritātes pieteikumiem reakcija seko 3 (trīs) darba dienu laikā pēc pieteikuma reģistrācijas pieteikumu reģistrā.
Pieteikumi tiek apstrādāti darba dienās no 9:00 līdz 18:00; ārpus minētā darba laika pieteikumi tiek pieņemti elektroniski, fiksējot pieteikuma saņemšanas laiku, bet darbība tiek uzsākta nākamās darba dienas sākumā.
Gadījumā, ja uzturēšanas pieteikumā norādītās problēmas iemesls neietilpst Piegādātāja atbildības sfērā (piemēram, tīkla vai aparatūras problēmas), Piegādātājam ir pienākums nekavējoši ziņot par to Pasūtītāja norādītajai kontaktpersonai.
(039). Pieteikumu risināšana (Obligāta)
Piegādātājs risina pieteikumu visiem pieejamajiem saprātīgiem līdzekļiem, savukārt Pasūtītājs visiem pieejamajiem saprātīgiem līdzekļiem sniedz pieteikuma risināšanai nepieciešamo papildus informāciju.
Piegādātājs informē Pasūtītāju par pieteikuma risināšanas gaitu pēc vienošanās (x.xx., veicot nepieciešamās atzīmes pieteikumu reģistrā), bet:
• 1. un 2. prioritātes pieteikumiem ne retāk kā reizi 1 (vienā) darba dienās;
• 3. un 4. prioritātes pieteikumiem ne retāk kā 1 (vienu) reizi 5 (piecās) darba dienās. Piegādātājam jānovērš pieteiktās kļūdas šādos termiņos:
• 1. un 2. prioritātes pieteikumiem ne vēlāk kā 2 (divu) darba dienu laikā pēc pieteikuma reģistrācijas;
• 3. un 4. prioritātes pieteikumiem ne vēlāk kā 2 (divu) nedēļu laikā pēc pieteikuma reģistrācijas pieteikumu reģistrā.
1.-2. prioritātes kļūdu gadījumos Piegādātāja pienākums pirmajā kārta ir novērst kļūdu, nodrošinot TPPIS darbību. Pieļaujama programmatūras atjaunošana, izmantojot iepriekšējo laidienu, apvedceļa vai cita pagaidu risinājuma piegāde, x.xx., kļūdu apiešanas scenārijs (workaround), kas nodrošinātu ikdienas darba turpināšanu ar TPPIS. Šādā gadījumā ir pieļaujama Sistēmas darbināšana ar 3. prioritātes kļūdām.