Atklāta konkursa
APSTIPRINĀTS
VSIA „Autotransporta direkcija”
iepirkuma komisijas 2016. gada 4.marta sēdē protokols Nr. AD 2016/5-1
Atklāta konkursa
Sabiedriskā transporta kustības maršrutu attēlošanas ģeotelpiskās informācijas sistēmas izstrāde un uzturēšana
(iepirkuma identifikācijas Nr. AD 2016/5)
Nolikums
Rīga, 2016
SATURA RĀDĪTĀJS
3. Pretendentu atlases prasības 6
4. Pretendenta iesniedzamie atlases dokumenti 7
5. Tehniskais piedāvājums un tā demonstrācija 8
8. Pretendentam, kuram būtu piešķiramas līguma slēgšanas tiesības, pārbaude 13
10. Pretendentu tiesības un pienākumi 14
Pielikums Nr.1. – Tehniskā specifikācija 15
Pielikums Nr.2. – Pieteikuma vēstules forma 39
Pielikums Nr.3.– Iepirkuma līguma projekts 40
Pielikums Nr.4. – Finanšu piedāvājuma forma 47
Pielikums Nr.5. – Pretendenta pieredzes apliecinājuma forma 48
VISPĀRĪGA INFORMĀCIJA
1.1. Iepirkuma identifikācijas numurs:
Nr. AD 2016/4
1.2. Pasūtītājs:
Valsts SIA „Autotransporta direkcija” Reģ. Nr. 40003429317
E-pasts: xxx@xxx.xx; tel.: 00000000, fakss: 67821107 Juridiskā adrese: Xxxxx xxxx 00, Xxxx, XX-0000
1.3. Kontaktpersonas:
1.3.1 Sabiedriskā transporta plānošanas daļas vadītāja vietniece informācijas sistēmu jautājumos Xxxx Xxxxx tālrunis 67502866, fakss 67686481, e-pasts: xxxx.xxxxx@xxx.xx
1.3.2 Administratīvās vadības daļas vadītājs - IT nodaļas vadītājs Xxxxx Xxxxxxxxxx, tālrunis 67502873, fakss 67686481, e-pasts: xxxxx.xxxxxxxxxx@xxx.xx.
1.4. Iepirkuma priekšmets:
1.4.1 Sabiedriskā transporta kustības maršrutu attēlošanas ģeotelpiskās informācijas sistēmas izstrāde un uzturēšana saskaņā ar tehnisko specifikāciju (1.pielikums).
1.4.2 Iepirkuma priekšmeta CPV kods ir 72243000-0 (Sistēmu analīzes un programmēšanas pakalpojumi).
1.4.3. Paredzamā līguma cena - līdz 100 000 EUR (neieskaitot PVN).
1.5. Līguma izpildes vieta un termiņš:
1.5.1 Pakalpojums jāpiegādā Pasūtītāja telpās, Xxxxx xxxx 00, Xxxx.
1.5.2 Iepirkuma līguma izpildes termiņš – 8 (astoņi) mēneši, skaitot no līguma noslēgšanas dienas.
1.6. Piedāvājumu iesniegšanas un atvēršanas vieta, datums, laiks un kārtība:
1.6.1 Piedāvājumi jāiesniedz Valsts SIA „Autotransporta direkcija”, Xxxxx xxxx 00, Xxxx, XX- 1050, 225. kabinetā, no plkst.8.30-12.00 un no 13.00-17.00 (piektdienās līdz 16.30.) ne vēlāk kā līdz 2016. gada 11. aprīļa, plkst. 11.00.
1.6.2 Pretendents atbilstoši 1.10.punktā noteiktajām prasībām noformētu piedāvājumu iesniedz personīgi vai nosūta pa pastu Valsts SIA „Autotransporta direkcija”. Pasta sūtījumam jābūt nogādātam šajā punktā norādītajā adresē līdz 1.6.1.punktā minētajam piedāvājuma iesniegšanas termiņam.
1.6.3 Pasūtītāja pārstāvis piedāvājumu neatvērtu atdod vai nosūta tā iesniedzējam, ja:
1.6.3.1 Piedāvājums neatbilst nolikuma 1.10.2. punktā minētajām prasībām.
1.6.3.2 Piedāvājums tiek iesniegts pēc 1.6.1.punktā norādītā piedāvājuma iesniegšanas termiņa beigām.
1.7. Informācija par iepirkumu:
1.8. Piedāvājuma atvēršanas vieta, datums, laiks un kārtība:
1.8.1 Piedāvājumu atvēršanas sanāksme notiks 2016.gada 11.aprīlī , plkst. 11.00, valsts SIA
„Autotransporta direkcija” Xxxxx xxxx 00, 0. stāva sanāksmju zālē.
1.8.2 Piedāvājumu atvēršanas sanāksme ir atklāta.
1.8.3 Piedāvājumu atvēršanas sanāksmē iepirkuma komisija piedāvājumus atver to iesniegšanas secībā, nosaucot Pretendentu, piedāvājuma iesniegšanas laiku, piedāvāto cenu.
1.9. Piedāvājuma derīguma termiņš:
1.9.1 Pretendenta iesniegtais piedāvājums ir derīgs 90 dienas no piedāvājumu atvēršanas dienas.
1.9.2 Gadījumā, ja līdz 1.9.1. punktā minētajam termiņam netiek noslēgts iepirkuma līgums, Pasūtītājs var lūgt piedāvājuma derīguma termiņa pagarināšanu.
1.10. Piedāvājuma noformēšana:
1.10.1 Piedāvājums jāsagatavo latviešu valodā. Ja piedāvājumā ietvertie dokumenti ir svešvalodā, tiem jāpievieno normatīvajos aktos noteiktajā kārtībā apliecināts tulkojums latviešu valodā.
1.10.2 Piedāvājumi iesniedzami aizlīmētā, aizzīmogotā aploksnē (liela dokumentu apjoma gadījumā var tikt lietots cits iepakojums, piemēram, kaste), uz kuras jānorāda:
1.10.2.1 Pretendenta nosaukums, adrese, tālruņa un faksa numurs.
1.10.2.2 Norāde:
Valsts SIA „Autotransporta direkcija” iepirkuma komisijai Xxxxx xxxx 00, Xxxx, XX-0000
Piedāvājums atklātā konkursā „ Sabiedriskā transporta kustības maršrutu attēlošanas ģeotelpiskās informācijas sistēmas izstrāde un uzturēšana”
(iepirkuma identifikācijas Nr. AD 2016/5)
Neatvērt līdz 2016. gada 11.aprīlim plkst. 11.00!
1.10.3 Piedāvājums iesniedzams kā vienots dokumenta sējums, kurš sastāv no trīs daļām: Pretendenta atlases dokumenti, Pretendenta tehniskais piedāvājums un Pretendenta finanšu piedāvājums.
1.10.4 Piedāvājums jāiesniedz 2 (divos) eksemplāros – viens oriģināls un viena apliecināta kopija. Katra eksemplāra pirmās lapas augšējā labajā stūrī ievieto attiecīgu uzrakstu („KOPIJA” vai „ORIĢINĀLS”).
1.10.5 Piedāvājumam jābūt ar satura rādītāju, cauršūtam, sanumurētam un apliecinātam.
1.10.6 Piedāvājumu paraksta Pretendents vai komersanta paraksttiesīgā persona, vai pilnvarotā persona. Gadījumā, ja piedāvājumu paraksta Pretendenta pilnvarotā persona, piedāvājumā ir jāpievieno pilnvaras oriģināls.
1.10.7 Pretendenta tehniskais piedāvājums jāiesniedz arī elektroniskā formā (vienreiz rakstāmā CD vai citā datu nesējā), ierakstīts ar Adobe Acrobat vai MS Office rīkiem nolasāmā formātā. Uz datu nesēja jābūt uzrakstītam Pretendenta nosaukumam un Iepirkuma identifikācijas numuram.
1.10.8 Piedāvājuma dokumentiem jābūt skaidri salasāmiem, lai izvairītos no jebkādiem pārpratumiem. Vārdiem un skaitļiem jābūt bez iestarpinājumiem vai labojumiem. Ja pastāvēs jebkāda veida pretrunas starp oriģinālu un kopiju, noteicošais būs oriģināls. Ja pastāvēs jebkāda veida pretrunas starp skaitlisko vērtību apzīmējumiem ar vārdiem un skaitļiem, noteicošais būs apzīmējums ar vārdiem. Visu dokumentu noformējumam jānodrošina to juridiskais spēks.
1.10.9 Gadījumā, ja Pretendents iesniedzis kāda dokumenta atvasinājumu, tas jāapliecina atbilstoši Ministru kabineta 2010.gada 28.septembra noteikumiem Nr.916 „Dokumentu izstrādāšanas un noformēšanas kārtība”.
1.10.10 Iesniedzot piedāvājumu, Pretendents pilnībā piekrīt visiem Nolikumā ietvertajiem noteikumiem.
1.10.11 Piedāvājumi, kas iesniegti līdz Piedāvājumu iesniegšanas termiņa beigām, netiek atdoti atpakaļ un tiek glabāti atbilstoši Publisko iepirkumu likuma prasībām.
1.11. Papildu informācijas sniegšana:
1.11.1 Ieinteresētajam Pretendentam ir tiesības prasīt papildus informāciju par iepirkumu, tai skaitā, prasīt paskaidrojumus par nolikumu. Šie pieprasījumi ir iesniedzami Xxxxx xxxx 00, Xxxx, XX-0000, nosūtot tos rakstveidā pa pastu un vienlaicīgi pa faksu vai elektroniski uz e-pasta adresi: xxxx.xxxxx@xxx.xx
1.11.2 Ja ieinteresētais Pretendents laikus rakstiski pieprasa papildus informāciju par iepirkuma nolikumā iekļauto informāciju, iepirkuma komisija sagatavo atbildi un kopā ar uzdoto jautājumu (nenorādot iesniedzēju) ne vēlāk kā 6 (sešas) dienas pirms nolikuma 1.6.1.punktā norādītā piedāvājumu iesniegšanas termiņa beigām to publicē tīmekļa vietnē xxx.xxx.xx un nosūta jautājuma iesniedzējam rakstveidā.
2. IEPIRKUMA PRETENDENTI
2.1. Par iepirkuma pretendentu var būt fiziska vai juridiska persona, šādu personu apvienība jebkurā to kombinācijā, kas attiecīgi piedāvā tirgū sniegt pakalpojumus.
2.2. Visiem pretendentiem iepirkumā piemēro vienādus noteikumus.
2.3. Ja piedāvājumu iepirkumam iesniedz personu apvienība, visi apvienības dalībnieki paraksta gan pieteikumu, gan tehnisko un finanšu piedāvājumu.
2.4. Ja piedāvājumu iepirkumam iesniedz personu apvienība, piedāvājumā norāda personu, kura pārstāv personu apvienību iepirkumā, kā arī katras personas atbildības sadalījumu. Šo informāciju paraksta visi personu apvienības dalībnieki.
2.5. Ja piedāvājumu iesniedz personu (piegādātāju) apvienība, kura uz piedāvājuma iesniegšanas brīdi nav juridiski noformējusi savu sadarbību saskaņā ar Komerclikumu, lai tā tiktu atzīta par pretendentu, ir jāiesniedz visu personu (piegādātāju) apvienības dalībnieku parakstīts saistību raksta (protokola, vienošanās, cita dokumenta) kopija, kas apliecina, ka, ja pretendents tiks atzīts par uzvarētāju, tiks izveidota personālsabiedrība saskaņā ar nolikuma prasībām.
2.6. Ja piedāvājumu iesniedz personālsabiedrība, tad, lai tā tiktu atzīta par pretendentu atklātā konkursā, ir jāiesniedz personālsabiedrības līguma kopija vai izraksts no līguma, vai cita dokumenta (protokols, vienošanās) kopija, kas apliecina katra personālsabiedrības biedra kompetenci un atbildības sadalījumu, ja tas nav ietverts personālsabiedrības līgumā vai tā izrakstā.
2.7. Ja piedāvājumu iesniegusi personu (piegādātāju) apvienība tiek atzīta par konkursa uzvarētāju, tai ir jāparaksta personālsabiedrības līgums. Personālsabiedrības līguma kopija, kā arī personālsabiedrības pārstāvja pilnvara jāiesniedz Pasūtītājam. Xxx Xxxxxxxxx līguma parakstīšanas personālsabiedrības pilnvarotajam pārstāvim ir jāiesniedz tās reģistrācijas apliecības kopija.
2.8. Iepirkuma līguma slēgšanas tiesību iegūšanai personu apvienībai ir jāveic personālsabiedrības reģistrācija normatīvajos aktos noteiktajā kārtībā 10 (desmit) kalendāro dienu laikā no dienas, kad atbilstoši Publisko iepirkumu likumam var slēgt Iepirkuma līgumu.
3. PRETENDENTU ATLASES PRASĪBAS
3.1. Pretendentu atlases nosacījumi ir obligāti visiem pretendentiem, kuri vēlas iegūt tiesības izpildīt pasūtījumu un slēgt Iepirkuma līgumu.
3.2. Pretendentam jābūt reģistrētam normatīvajos aktos noteiktajā kārtībā.
3.3. Pasūtītājs neizskata pretendenta piedāvājumu un izslēdz pretendentu no turpmākas dalības jebkurā piedāvājuma izvērtēšanas stadijā, ja konstatē kādu no Publisko iepirkumu likuma 391.pantā noteiktajiem pretendentu izslēgšanas gadījumiem.
3.4. Pretendents pēdējo 3 (trīs) gadu laikā ir realizējis vismaz 3 (trīs) projektus ģeogrāfiskās informācijas sistēmu izstrādes un ieviešanas jomā, izmantojot Pretendenta norādītās tehnoloģijas, no kuriem vismaz 1 (viena) projekta realizācijas finanšu apjoms ir līdzvērtīgs Pretendenta piedāvātajam finanšu piedāvājumam;
3.5. Pretendentam jānodrošina speciālistu grupa, kas sastāv no vismaz 4 ekspertiem ar šādām noteiktajām prasībām:
3.6. Projekta vadītājs:
3.6.1 Augstākā izglītība IT, biznesa vadības, ekonomikas vai finanšu jomā;
3.6.2 Starptautiski atzīta sertifikācija projektu vadības nodrošināšanā (PMP, PRINCE2 practitioner vai līdzvērtīga sertifikācija, vai līdzvērtīga (ekvivalenta) akadēmiskā izglītība projektu vadības jomā (Pretendentam jāiesniedz pierādījumi attiecībā uz iegūtās akadēmiskās izglītības projektu vadības jomā atbilstību starptautiski atzītajai sertifikācijai projektu vadības nodrošināšanā));
3.6.3 Vismaz 3 (trīs) gadu pieredze informācijas sistēmu izstrādes projektu vadībā.
3.6.4 Pieredze projekta vadītāja lomā vismaz 3 (trīs) projektos, no kuriem vismaz:
3.6.4.1 1 (viens) ir realizēts ģeogrāfiskās informācijas sistēmu izstrādes un ieviešanas jomā, izmantojot Pretendenta norādītās tehnoloģijas
3.6.4.2 vismaz 1 (viena) projekta kopējais finanšu apjoms ir līdzvērtīgs Pretendenta piedāvātajam finanšu piedāvājumam.
3.7. Arhitekts/ vadošais programmētājs:
3.7.1 Augstākā izglītība IT jomā;
3.7.2 praktiska programmēšanas pieredze Pretendenta piedāvājumā norādītajās ģeogrāfiskās informācijas sistēmas tehnoloģijās;
3.7.3 Pieredze arhitekta / vadošā programmētāja lomā vismaz 3 (trīs) projektos, no kuriem vismaz:
3.7.3.1 1 (viens) ir realizēts ģeogrāfiskās informācijas sistēmu izstrādes un ieviešanas jomā, izmantojot Pretendenta norādītās tehnoloģijas
3.8. Programmētājs:
3.8.1 Augstākā izglītība IT jomā.
3.8.2 praktiska programmēšanas pieredze Pretendenta piedāvājumā norādītajās ģeogrāfiskās informācijas sistēmas tehnoloģijās;
3.8.3 Pieredze programmētāja lomā vismaz 3 (trīs) projektos, no kuriem vismaz:
3.8.3.1 1 (viens) ir realizēts ģeogrāfiskās informācijas sistēmu izstrādes un ieviešanas jomā, izmantojot Pretendenta norādītās tehnoloģijas
3.9. Testētājs:
3.9.1 praktiska pieredze informācijas sistēmu testēšanā;
3.9.2 Pieredze testētāja lomā vismaz 3 (trīs) projektos, no kuriem vismaz:
3.9.2.1 1 (viens) ir realizēts ģeogrāfiskās informācijas sistēmu izstrādes un ieviešanas jomā, izmantojot Pretendenta norādītās tehnoloģijas
3.10. Visu ekspertu projektu pieredzei ir jābūt iegūtai pēdējo 3 (trīs) gadu laikā.
3.11. Lai nodrošinātu pakāpeniskās ieviešanas (agile) metodoloģijas piemērošanu projektā, visiem ekspertiem projektā ir jābūt latviešu valodas zināšanām sapratnē, runāšanā un rakstīšanā ne zemākas kā C1 līmenī, atbilstoši Eiropas valodas līmeņu novērtējuma metodikai.
3.12. Viens speciālists drīkst piedalīties pakalpojumu sniegšanā ne vairāk kā vienā lomā.
3.13. Gadījumā, ja Pretendents iepirkuma procedūras rezultātā tiek atzīts par uzvarētāju, tam visu līgumā un piedāvājumā iekļauto darbu realizācija ir jānodrošina ar Pretendenta piedāvājumā norādītajiem speciālistiem. Piedāvātos speciālistus var mainīt tikai ar līdzvērtīgiem un tikai ar Pasūtītāja rakstisku atļauju.
4. PRETENDENTA IESNIEDZAMIE ATLASES DOKUMENTI:
4.1. Pieteikums, kas noformēts atbilstoši Nolikuma 2.pielikumam.
4.2. Komercdarbību reģistrējošas iestādes ārvalstīs izdota reģistrācijas apliecības kopija, kas apliecina, ka Pretendents – juridiska persona ir reģistrēta likumā noteiktajā kārtībā. Ja Pretendents – fiziska persona ir reģistrēts kā nodokļu maksātājs, jāiesniedz nodokļu maksātāja apliecības kopija.
4.3. Dokuments, kas apliecina piedāvājuma paraksta tiesīgas personas paraksta tiesības, ja dati par paraksta tiesībām nav pieejami Latvijas Republikas Uzņēmumu reģistrā (līdzvērtīga reģistra ārvalstīs izdota izziņa par paraksta tiesībām, kas ir spēkā uz piedāvājuma iesniegšanas brīdi) vai atbilstoši noformēta pilnvara, ar kuru amatpersona tiek pilnvarota pārstāvēt pretendentu atklātā konkursā, ja piedāvājumu paraksta pilnvarota persona.
4.4. Atbilstoši 5.pielikumā pievienotajai formai - Pretendenta iepriekšējo 3 (trīs) gadu (2013., 2014. un 2015.) periodā realizēto projektu saraksts informācijas sistēmu izstrādes ieviešanas un uzturēšanas jomā, kas apliecina Pretendenta atbilstību Nolikuma 3.4. punktā noteiktajām prasībām, norādot projektu pasūtītāju, pasūtītāja kontaktinformāciju, projekta realizācijas laiku, īsu izstrādātās un ieviestās sistēmas aprakstu (būtiskākā funkcionalitāte, izmantotās tehnoloģijas), projekta līgumcenu (bez PVN), kā arī uzņēmēja statusu projektā (virsuzņēmējs vai apakšuzņēmējs). Ja Pretendents projektā ir bijis apakšuzņēmējs, papildus ir jānorāda virsuzņēmēja nosaukums, kā arī pretendenta sniegtā pakalpojuma realizācijas apjoms EUR (bez PVN).
4.5. Vismaz 3 (trīs) pozitīvas atsauksmes no dažādiem klientiem/pasūtītājiem, kurās ir sniegta informācija par pretendenta veiktajiem projektiem informācijas sistēmu izstrādes un ieviešanas jomā, kas apliecina Pretendenta atbilstību Nolikuma 3.4. punktā noteiktajām prasībām.
4.6. Pretendenta piedāvāto speciālistu dzīvesgājuma apraksti (CV) saskaņā ar nolikuma 3.6.- 3.9.punktos noteiktajām prasībām speciālistiem.
4.7. Pretendenta piedāvāto speciālistu kvalifikāciju apliecinošu dokumentu kopijas (diplomi, sertifikāti) saskaņā ar nolikuma 3.6.-3.9.punktos noteiktajām prasībām speciālistiem.
4.8. Vismaz viena pozitīva atsauksme no klienta/pasūtītāja par katru Nolikuma 3.6.-3.9.punktos noteikto speciālistu, kas saņemta no klienta/pasūtītāja, kuram attiecīgais eksperts ir sniedzis savus pakalpojumus.
4.9. Ja Pretendents kvalifikācijas prasību izpildei balstās uz citas personas iespējām Publisko iepirkumu likuma 41.panta vai 42.panta prasību izpildīšanai, t.i., lai apliecinātu atbilstību
kvalifikācijas prasībām, pretendentam ir jāiesniedz šo uzņēmēju apliecinājumu vai vienošanos par sadarbību konkrētā līguma izpildei.
4.10. Ja Pretendents līguma izpildē piesaista apakšuzņēmēju, paredzot tam izpildei nodot konkrētu līguma daļu, kuras apjoms pārsniedz 20% (divdesmit procenti) pretendentam jāiesniedz apakšuzņēmēja parakstīts dokuments (apliecinājums vai vienošanās), kas pierāda apakšuzņēmēja uzņemtās saistības attiecībā uz iepirkuma īstenošanu un piedalīšanos iepirkuma līguma izpildē, kā arī informāciju par to, kādu iepirkuma (līguma) daļu (kurus darbus) īstenos apakšuzņēmējs. Informāciju norāda tādā apjomā, kādā tas ir objektīvi (ņemot vērā piedāvājuma sagatavošanas brīdī pieejamo informāciju).
4.11. Pretendenta, personu apvienības dalībnieka vai apakšuzņēmēja apliecinātas izdrukas no Valsts ieņēmumu dienesta (VID) elektroniskās deklarēšanas sistēmas (EDS) par tā vidējām stundas tarifa likmēm profesiju grupās. Datiem par vidējām stundu tarifu likmēm VID EDS izdrukās jābūt par periodu, kas noteikts Publisko iepirkumu likuma 48. panta 1.1daļā.
5. TEHNISKAIS PIEDĀVĀJUMS UN TĀ DEMONSTRĀCIJA
5.1. Tehniskais piedāvājums sagatavojams saskaņā ar tehnisko specifikāciju (Nolikuma 1. pielikums), sniedzot aprakstu par veidu, kā izvirzītās prasības tiks realizētas.
5.2. Tehnisko piedāvājumu paraksta Pretendents vai Pretendenta – juridiskās personas paraksttiesīgā persona vai pilnvarotā persona.
5.3. Pretendentam pēc iepirkuma komisijas uzaicinājuma, kas tiks izsūtīts ne vēlāk kā 3 (trīs) darba dienas iepriekš uz pretendenta norādīto juridisko adresi, ir jānodrošina sava tehniskā piedāvājuma demonstrācija, kuras laikā Pretendentam ir jāizklāsta vismaz šāda informācija:
5.3.1 piedāvātā tehniskā risinājuma arhitektūra, izklāstot informāciju par sistēmas tehnisko uzbūvi, pielietojamajiem risinājumiem un tehnoloģijām;
5.3.2 Pretendenta redzējums par tehniski sarežģītākajiem risinājumiem ieviešamās sistēmas ietvaros un Pretendenta piedāvātajiem risinājumiem to ieviešanas realizācijai;
5.3.3 Pretendenta piedāvātā projekta realizācijas pieeja, laika plāns un nepieciešamais atbalsts no pasūtītāja puses;
5.3.4 Pretendenta identificēto risku izklāsts un piedāvātie risinājumi to pārvaldībai.
5.4. Demonstrācijas ilgums nedrīkst pārsniedz 30 (trīsdesmit) minūtes.
5.5. Demonstrācijas laikā Pasūtītājs nodrošina datoru, pieslēgumu elektrotīklam, interneta pieslēgumu un projektoru. Pretendentam jāņem vērā, ka:
5.5.1 Demonstrācijas norise tiks filmēta. Demonstrācijas norises filmēšanu nodrošina Pasūtītājs.
5.5.2 Iepirkumu komisija un pieaicinātie eksperti saistībā ar piedāvāto demonstrāciju ir tiesīgi uzdot jautājumus pēc būtības.
6. FINANŠU PIEDĀVĀJUMS
6.1. Finanšu Piedāvājuma cenā jābūt iekļautām visām izmaksām, kas saistītas ar Pakalpojumu sniegšanu.
6.2. Finanšu piedāvājums jāsagatavo, izmantojot 4.pielikumā pievienoto paraugu (Finanšu piedāvājumu paraksta Pretendents vai Pretendenta – juridiskās personas paraksttiesīgā persona vai pilnvarotā persona).
7. PIEDĀVĀJUMU VĒRTĒŠANA
7.1. Piedāvājumu vērtēšanas kritērijs ir – saimnieciski izdevīgākais piedāvājums.
7.2. Iepirkuma komisija vērtēšanā ņem vērā tikai to Pretendentu piedāvājumus, kuru piedāvājumi ir izturējuši pirmo un otro pārbaudes posmu (Piedāvājuma noformējuma un satura pārbaude, un Tehniskā un finanšu piedāvājuma atbilstības pārbaude).
7.3. Galīgā piedāvājuma novērtēšanā (GN) īpatsvars sastāv no:
7.3.1. Tehniskā piedāvājuma vērtējuma (TP) - 25%, kas atbilst tehniskā piedāvājumā iegūstamajiem 25 punktiem;
7.3.2. Finanšu piedāvājuma vērtējuma (FP) – 75%, kas atbilst finanšu piedāvājumā iegūstamajiem 75 punktiem.
7.4. Piedāvājumu vērtēšanu komisija veic šādos 3 posmos:
7.4.1. Piedāvājuma noformējuma un satura pārbaude;
7.4.2. Tehniskā un finanšu piedāvājuma atbilstības pārbaude;
7.4.3. Piedāvājuma vērtēšana.
7.5. posms – Piedāvājumu noformējuma un satura pārbaude:
7.5.1. Piedāvājumu noformējuma pārbaudi iepirkuma komisija veic slēgtā sēdē, kuras laikā pārbauda, vai piedāvājumi sagatavoti un noformēti atbilstoši Nolikuma prasībām.
7.5.2. Pretendenti, kuru piedāvājumi nav noformēti atbilstoši Nolikuma prasībām, var tikt izslēgti no tālākās vērtēšanas.
7.5.3. Iepirkumu komisija neizskata Pretendenta piedāvājumu un izslēdz pretendentu no turpmākās dalības konkursā, ja uz pretendentu, personu apvienības dalībnieku, ja piedāvājumu iesniedz personu apvienība, attiecas kaut viens no Publisko iepirkumu likuma 39.1panta pirmās daļas 1., 2., 3., 4., 5., 6.punktā minētajiem nosacījumiem. Uz pretendenta piesaistītajiem apakšuzņēmējiem, uz kuru iespējām balstās pretendents, lai apliecinātu, ka tā kvalifikācija atbilst nolikuma prasībām vai tādiem pretendenta piesaistītajiem apakšuzņēmējiem, kuru sniedzamo pakalpojumu vērtība ir 20% no kopējās iepirkuma līguma vērtības vai vairāk, attiecas kaut viens no Publisko iepirkumu likuma 39.1panta pirmajā daļā 2., 3., 4., 5., 6.pinktā minētajiem nosacījumiem.
7.5.4. Iepirkumu komisija neizslēdz pretendentu no dalības iepirkumā, ja:
7.5.4.1. no dienas, kad kļuvis nepastrīdams un nepārsūdzams tiesas spriedums, prokurora priekšraksts par sodu vai citas kompetentās institūcijas pieņemtais lēmums saistībā ar Publisko iepirkumu likuma 39.1panta pirmās daļas 1.punktā un 2.punkta “a” apakšpunktā minētajiem pārkāpumiem, līdz piedāvājumu iesniegšanas dienai ir pagājuši trīs gadi;
0.0.0.0.xx dienas, kad kļuvis neapstrīdams un nepārsūdzams tiesas spriedums vai citas kompetentās institūcijas pieņemtais lēmums saistībā ar Publisko iepirkumu likuma
39.1. panta pirmās daļas 2.punkta “b” apakšpunktā un 3.punktā minētajiem pārkāpumiem, līdz piedāvājuma iesniegšanas dienai ir pagājuši 12 mēneši.
7.5.5.Iepirkumu komisija pārbaudi par Publisko iepirkumu likuma 39.1panta pirmajā daļā minēto pretendentu izslēgšanas gadījumu esamību veic attiecībā uz katru pretendentu, kad uzsāk piedāvājumu vērtēšanu.
7.5.6.Iepirkumu komisija pārbaudi par Xxxxxxxx iepirkumu likuma 39.1panta pirmās daļas 5.punktā minētā pretendentu izslēgšanas gadījumu veic arī attiecībā uz katru pretendentu, kuram būtu piešķiramas līguma slēgšanas tiesības, pirms tam, kad ir pieņemts lēmums par līguma slēgšanas tiesību piešķiršanu.
7.5.7.Iepirkuma komisija veic nolikuma 7.5.3. un 7.5.4.punktā noteikto faktu pārbaudi par Latvijā reģistrētiem vai pastāvīgi dzīvojošiem Pretendentiem informācijas sistēmā, kurā saskaņā ar Publisko iepirkumu likuma 39.¹ panta devīto daļu iegūstama informācija, lai pārbaudītu, vai pretendents nav izslēdzams no dalības iepirkuma procedūrā. Pasūtītājs
minēto informāciju ir tiesīgs iegūt, neprasot pretendenta un citu Nolikuma 7.5.3.punktā minēto personu piekrišanu.
7.5.8.Nolikuma 7.5.9.punktā noteikto faktu pārbaudi veic uz brīdi (datumu), kad paziņojums par līgumu publicēts Iepirkumu uzraudzības biroja mājaslapā.
7.5.9.Iepirkuma komisija, pārbaudot vai uz pretendentu, personas dalībnieku vai uz pretendenta piesaistītajiem apakšuzņēmējiem, uz kuru iespējām balstās pretendents, lai apliecinātu, ka tā kvalifikācija atbilst nolikuma prasībām, vai tādiem pretendenta piesaistītajiem apakšuzņēmējiem, kuru sniedzamo pakalpojumu apjoms ir 20% no kopējās iepirkuma līguma vērtības vai vairāk, neattiecas Publisko iepirkumu likuma 39.1panta pirmās daļas 5.punkta nosacījumi, atkarībā no pārbaudes rezultātiem:
7.5.9.1.neizslēdz pretendentu no turpmākās dalības iepirkuma procedūrā, ja konstatē, ka saskaņā ar Valsts ieņēmumu dienesta administrēto nodokļu (nodevu) parādnieku datubāzē esošajiem aktuālajiem datiem pretendentam, kā arī Nolikuma 7.2.3.punktā minētajām personām nav Valsts ieņēmumu dienesta administrēto nodokļu parādu, tajā skaitā valsts sociālās apdrošināšanas obligāto iemaksu parādu, kas kopsummā pārsniedz 150 euro; 7.5.9.2.informē pretendentu par to, ka saskaņā ar Valsts ieņēmumu dienesta publiskajā nodokļu parādnieku datubāzē pēdējās datu aktualizācijas datumā ievietoto informāciju ir konstatēts, ka tam vai Nolikuma 7.5.3.punktā minētajām personām dienā, kad paziņojums par līgumu publicēts Iepirkumu uzraudzības biroja mājaslapā, vai arī dienā, kad pieņemts lēmums par iespējamu līguma slēgšanas tiesību piešķiršanu, ir nodokļu parādi, tajā skaitā valsts sociālās apdrošināšanas obligāto iemaksu parādi, kas kopsummā pārsniedz 150 euro, un nosaka termiņu — 10 dienas pēc informācijas izsniegšanas vai nosūtīšanas dienas — apliecinājuma iesniegšanai. Pretendents, lai apliecinātu, ka tam, kā arī Nolikuma 7.5.3.punktā minētajām personām nebija nodokļu parādu, tajā skaitā valsts sociālās apdrošināšanas obligāto iemaksu parādu, kas kopsummā pārsniedz 150 euro, iesniedz attiecīgās personas vai tās pārstāvja apliecinātu izdruku no Valsts ieņēmumu dienesta elektroniskās deklarēšanas sistēmas par to, ka attiecīgajai personai nebija nodokļu parādu, tajā skaitā valsts sociālās apdrošināšanas iemaksu parādu, kas kopsummā pārsniedz 150 euro. Ja noteiktajā termiņā minētais apliecinājums nav iesniegts, pasūtītājs pretendentu izslēdz no dalības iepirkumā.
7.5.10.Iepirkumu komisijai ir tiesības veikt pretendenta iesniegto izdruku autentiskuma pārbaudi. 7.5.11.Lai pārbaudītu, vai uz ārvalstī reģistrētu vai pastāvīgi dzīvojošu pretendentu, vai Nolikuma 7.5.3.punktā minēto personu, kas reģistrēta vai pastāvīgi dzīvo ārvalstī, nav
attiecināmi Nolikuma 7.5.3.punktā noteiktie izslēgšanas nosacījumi, pasūtītājs, izņemot personām, kuras ir reģistrētas Latvijā vai pastāvīgi dzīvo Latvijā, pieprasa, lai pretendents iesniedz attiecīgās kompetentās institūcijas izziņu, kas apliecina, ka uz pretendentu, vai Nolikuma 7.2.3.punktā minēto personu neattiecas Nolikuma 7.5.3.punktā minētie gadījumi. Termiņu izziņas iesniegšanai pasūtītājs nosaka ne īsāku par 10 darbdienām pēc pieprasījuma izsniegšanas vai nosūtīšanas dienas. Ja attiecīgais pretendents noteiktajā termiņā neiesniedz minēto izziņu, pasūtītājs to izslēdz no dalības iepirkuma procedūrā. Xxxxx pamatotus argumentus, pretendentam ir tiesības lūgt noteiktā izziņas iesniegšanas termiņa pagarinājumu, taču pasūtītājam nav pienākums piešķirt prasīto termiņa pagarinājumu.
7.6. 2. posms – Tehniskā un finanšu piedāvājuma atbilstības pārbaude:
7.6.1. Tehnisko un finanšu piedāvājumu atbilstības pārbaudi iepirkuma komisija veic slēgtā sēdē, kuras laikā pārbauda, vai tehniskie un finanšu piedāvājumi sagatavoti un atbilst Nolikuma un tā pielikumos noteiktajām prasībām.
7.6.2.Pretendenti, kuru piedāvājumi nav sagatavoti atbilstoši Nolikuma prasībām, var tikt izslēgti no tālākās vērtēšanas.
7.6.3.Pretendenti, kuru piedāvājumos nav norādīts, kā tiks izpildītas visas Tehniskajā specifikācijā (1.pielikums) noteiktās prasības, tiek izslēgti no tālākās vērtēšanas.
7.7. 3. posms – Piedāvājumu vērtēšana
7.7.1. Finanšu piedāvājuma pārbaudes laikā iepirkuma komisija pārbauda vai piedāvājumā nav aritmētisko kļūdu. Konstatējot aritmētiskās kļūdas, iepirkuma komisija šīs kļūdas izlabo. Par visiem aritmētisko kļūdu labojumiem iepirkuma komisija paziņo Pretendentam, kura finanšu piedāvājumā labojumi izdarīti. Vērtējot finanšu piedāvājumus, kuros bijušas aritmētiskas kļūdas, iepirkuma komisija ņem vērā tikai labotās cenas.
7.7.2. Piedāvātā līgumcena tiks vērtēta pēc šādas metodes: viszemākajai piedāvātajai cenai tiks piešķirts maksimālais punktu skaits, bet pārējiem piedāvājumiem punkti tiks aprēķināti proporcionāli attiecībā pret lētāko. Šo daļu novērtēs, piemērojot sekojošu formulu:
FP =75*Fx / Fy, kur:
FP — vērtējamā piedāvājuma iegūtais punktu skaits;
Fx — lētākā piedāvājuma cena;
Fy — vērtējamā piedāvājuma cena.
7.7.3. Piedāvājumu vērtēšanas laikā Iepirkuma komisija pārbauda, vai pretendentu Finanšu piedāvājumi nav nepamatoti lēti saskaņā ar Publisko iepirkumu likuma 48.panta 11daļu. Iepirkuma komisija pārbaudi veic pēc Pretendentu piedāvājumos iekļautajiem, Nolikuma 4.11.punktā noteiktajiem dokumentiem.
7.7.4.Iepirkumu komisijai ir pienākums izvērtēt, vai piedāvājums nav nepamatoti lēts, ja tas konstatē, ka pretendenta vai tā piedāvājumā norādīto apakšuzņēmēju darba ņēmēju vidējā stundas tarifa likme kaut vienā no profesiju grupām pirmajos trijos gada ceturkšņos pēdējo četru gada ceturkšņu periodā līdz piedāvājuma iesniegšanas dienai ir mazāka par 80 procentiem (vai nesasniedz valstī noteikto minimālo stundas tarifa likmi) no darba ņēmēju vidējās stundas tarifa likmes attiecīgajā profesiju grupā valstī minētajā periodā pēc Valsts ieņēmumu dienesta apkopotajiem datiem, kas publicēti Valsts ieņēmumu dienesta mājaslapā internetā. Ja pretendents kā nodokļu maksātājs ir reģistrēts pēdējo četru gada ceturkšņu periodā līdz piedāvājuma iesniegšanas dienai, ņem vērā darba ņēmēju vidējo stundas tarifa likmi periodā no nākamā mēneša pēc reģistrācijas mēneša līdz piedāvājuma iesniegšanas dienai.
7.7.5.Iepirkumu komisija, nolikuma 7.7.4. punktā minēto faktu izvērtēšanai pieprasa no Valsts ieņēmumu dienesta atzinumu par pretendenta un tā piedāvājumā norādīto apakšuzņēmēju darba ņēmēju vidējās stundas tarifa likmes pamatotību atbilstoši pretendenta un tā piedāvājumā norādīto apakšuzņēmēju veiktajai saimnieciskajai darbībai.
7.7.6.Iepirkuma komisija izskata, vai piedāvājumos nav konstatējamas citas pazīmes, kas varētu liecināt, ka pretendentu Finanšu piedāvājumi ir nepamatoti lēti. Ja piedāvājuma vērtēšanas laikā iepirkuma komisija konstatē, ka Pretendents piedāvā Pakalpojumu par ievērojami zemāku cenu, nekā piedāvā pārējie Pretendenti, tā pārbauda, vai Pretendenta piedāvājums nav nepamatoti lēts. Šajā gadījumā iepirkuma komisija pieprasa, lai Pretendents iesniedz papildus detalizētu paskaidrojumu par būtiskajiem piedāvājuma nosacījumiem. Ja Pretendents šādu pamatojumu nevar sniegt vai pamatojums nesniedz pārliecību par īpašajām priekšrocībām, kas tam ir, tā piedāvājums tiek atzīts par nepamatoti lētu, un Pretendents tiek izslēgts no turpmākās dalības Iepirkuma procedūrā.
7.7.7. Vērtējot tehnisko piedāvājumu, tiks piešķirti punkti, izmantojot šādu tabulu:
Nr.p.k. | Vērtēšanas kritērijs | Vērtējuma skala punktos | ||
1. | Pakalpojuma izpildes laiks (A) (maksimālais punktu skaits – 5) | |||
1.1. | Pretendents piedāvā nodrošināt visu darba uzdevumu izpildi 6 (sešu) mēnešu laikā | 5 | ||
1.2. | Pretendents piedāvā nodrošināt visu darba uzdevumu izpildi 7 (septiņu) mēnešu laikā | 2 | ||
2. | Piedāvātās garantijas apjoms (B) (maksimālais punktu skaits - 5) | |||
2.1. | Pretendents piedāvā cilvēkstundas gadā | 100 | uzturēšanas | 5 |
2.2. | Pretendents piedāvā cilvēkstundas gadā | 90 | uzturēšanas | 3 |
2.3. | Pretendents piedāvā cilvēkstundas gadā | 85 | uzturēšanas | 2 |
3. | Slāņu pieejamība (C) (maksimālais punktu skaits - 15) | |||
3.1. | Pretendents piedāvā uz kartes parādīt vai noslēpt mācību iestāžu atrašanās vietas (ar un bez nosaukuma) | 3 | ||
3.2. | Pretendents piedāvā uz kartes parādīt vai noslēpt valsts iestāžu un to struktūrvienību atrašanās vietas (ar un bez nosaukuma) | 3 | ||
3.3. | Pretendents piedāvā uz kartes parādīt vai noslēpt pašvaldību iestāžu un to struktūrvienību atrašanās vietas (ar un bez nosaukuma) | 3 | ||
3.4. | Pretendents piedāvā uz kartes parādīt vai noslēpt veselības aprūpes pakalpojumu sniedzēju atrašanās vietas (ar un bez nosaukuma) | 3 | ||
3.5. | Pretendents piedāvā uz kartes parādīt vai noslēpt lielo1 uzņēmumu atrašanās vietas (ar un bez nosaukuma) | 2 | ||
3.6. | Pretendents piedāvā uz kartes parādīt vai noslēpt kultūras iestāžu atrašanās vietas (ar un bez nosaukuma) | 1 |
7.7.8. Galīgais tehniskā piedāvājuma (TP) vērtējums tiks aprēķināts sekojoši:
TP = A + B +C
1 Uzņēmuma kategorija ir noteikta, ņemot vērā Gada pārskatu un konsolidēto gada pārskatu likuma 5.panta piektās daļas regulējumu.
7.7.9. Galīgā piedāvājuma novērtēšana notiek pēc sekojošas formulas, kurā ietilpstošie radītāji aprēķināti ar precizitāti līdz divām zīmēm aiz komata:
GN = TP + FP
7.7.10. Gadījumā, ja veicot saimnieciski izdevīgākā piedāvājuma noteikšanu divi vai vairāk Pretendenti būs ieguvuši vienādu punktu skaitu, tad par uzvarētāju tiks atzīts tas Pretendents, kurš būs saņēmis augstāku Tehniskā piedāvājuma novērtējumu. Gadījumā, ja vairāki Pretendenti saņems vienādu Tehniskā piedāvājuma novērtējumu, tad par uzvarētāju tiks atzīts Pretendents, kurš ātrāk iesniedza piedāvājumu konkursam.
8. PRETENDENTAM, KURAM BŪTU PIEŠĶIRAMAS LĪGUMA SLĒGŠANAS TIESĪBAS, PĀRBAUDE:
8.1. Pirms lēmuma pieņemšanas iepirkuma komisijas locekļi, Publisko iepirkumu likumā noteiktajā kārtībā, veiks pārbaudi publiski pieejamos reģistros attiecībā uz pretendentu, kuram būtu piešķiramas līguma slēgšanas tiesības.
8.2. Lai pārbaudītu, vai ārvalstī reģistrēts vai pastāvīgi dzīvojošs kandidāts vai pretendents nav izslēdzams no dalības iepirkuma procedūrā, pasūtītājs pieprasīs, lai kandidāts vai pretendents iesniedz attiecīgās ārvalsts kompetentās institūcijas izziņu, kas apliecina, ka uz kandidātu vai pretendentu neattiecas Publisko iepirkumu likuma 391.panta pirmajā daļā noteiktie gadījumi. Termiņu izziņu iesniegšanai pasūtītājs noteiks ne īsāku par 10 darbdienām pēc pieprasījuma izsniegšanas vai nosūtīšanas dienas. Ja attiecīgais kandidāts vai pretendents noteiktajā termiņā neiesniegs minēto izziņu, pasūtītājs to izslēgs no dalības iepirkuma procedūrā.
9. IEPIRKUMA KOMISIJA
9.1. Vispārīgā informācija:
9.1.1 Iepirkuma komisijas funkcijas, tiesības un pienākumi noteikti normatīvajos aktos un šajā Nolikumā.
9.1.2 Iepirkuma komisijas sēdes tiek protokolētas. Protokolu paraksta visi komisijas locekļi, kuri piedalās sēdē.
9.1.3 Iepirkuma komisija ir tiesīga savā darbā piesaistīt ekspertus.
9.1.4 Pamatotu lēmumu slēgt vispārīgo vienošanos vai izbeigt iepirkumu, neizvēloties nevienu piedāvājumu, iepirkuma komisija pieņem balsojot.
9.2. Iepirkuma komisijas tiesības:
9.2.1 Pārbaudīt Pretendentu iesniegtās informācijas patiesumu, vēršoties pie kompetentām trešajām personām, vai pieprasīt Pretendentam papildus informāciju, pieprasot Pretendentam uzrādīt darba līgumu, nodokļu pārskatu u.c. dokumentu kopijas, kā arī apmeklēt Pretendenta telpas (pakalpojumu sniegšanas vietas). Pretendenta iesniegtais piedāvājums ir uzskatāms par pilnvarojumu Pasūtītājam iesniegt trešajām personām šādus informācijas pieprasījumus un saņemt atbildes. Iepirkuma komisija ir tiesīga pieprasīt Pretendentiem iesniegt sniegto pakalpojumu sarakstu un darījumu summu apliecinošu dokumentu (līgumu, preču pavadzīmju – rēķinu vai faktūrrēķinu apliecinātas kopijas).
9.2.2 Gadījumā, ja jebkurā vērtēšanas stadijā atklājas, ka Pretendents nav sniedzis nepieciešamās ziņas vai sniedzis nepatiesas ziņas, Iepirkuma komisija ir tiesīga izslēgt Pretendenta piedāvājumu no tālākas vērtēšanas.
9.2.3 Pieņemt lēmumu par konkursā uzvarējušo Pretendentu noteikšanu, pieņemt lēmumu slēgt līgumu vai izbeigt iepirkumu, neizvēloties nevienu piedāvājumu.
9.2.4 Ja konkursa uzvarētājs atsakās no līguma noslēgšanas vai atsauc savu piedāvājumu, par uzvarētāju iepirkuma komisija var atzīt Pretendentu, kurš iesniedzis nākamo saimnieciski visizdevīgāko piedāvājumu, vai izbeigt iepirkumu, neizvēloties nevienu piedāvājumu.
9.3. Iepirkuma komisijas pienākumi:
9.3.1 Iepirkuma procedūras norises laikā nodrošināt vienlīdzīgu attieksmi pret visiem Pretendentiem, garantējot visiem vienādu piekļuvi informācijai par iepirkumu. Iepirkuma komisija nevienam Pretendentam nerada labvēlīgākus apstākļus.
9.3.2 Xxxxxxxxx, vai piedāvājumos nav aritmētisku kļūdu.
9.3.3 Triju darba dienu laikā pēc tam, kad pieņemts lēmums slēgt līgumu vai izbeigt iepirkumu, neizvēloties nevienu piedāvājumu, ievietot paziņojumu Iepirkumu uzraudzības biroja mājas lapā un nosūtīt paziņojumu visiem Pretendentiem.
10. PRETENDENTU TIESĪBAS UN PIENĀKUMI
10.1. Pretendentu tiesības:
10.1.1 Līdz piedāvājumu iesniegšanas termiņa beigām Pretendents ir tiesīgs atsaukt vai mainīt savu piedāvājumu.
10.1.2 Pretendentam piedāvājuma sagatavošanai ir tiesības pieprasīt Pasūtītājam elektroniskā formā izsniegt Tehniskajā specifikācijā norādītos pieprasāmos dokumentus.
10.2. Pretendentu pienākumi:
10.2.1 Iesniedzot piedāvājumu, Pretendents pilnībā akceptē visus Nolikumā ietvertos nosacījumus.
10.2.2 Konkursa uzvarētājam ir pienākums noslēgt iepirkuma līgumu atbilstoši Nolikumam pievienotajam līguma paraugam (Pielikums Nr.3) 5 (piecu) darba dienu laikā pēc pasūtītāja pieprasījuma saņemšanas. Iepirkuma līguma projektu sagatavo Pasūtītājs. Gadījumā, ja konkursa uzvarētājs minētajā laikā nenoslēdz iepirkuma līgumu, Pasūtītājs atbilstoši Publisko iepirkumu likuma nosacījumiem pieņem lēmumu slēgt līgumu ar nākamo pretendentu, kurš piedāvājis saimnieciski izdevīgāko piedāvājumu.
11. NOLIKUMA PIELIKUMI
Šim nolikumam ir pievienoti 5 (pieci) pielikumi, kas ir tā neatņemamas sastāvdaļas:
1. pielikums | - | Tehniskā specifikācija; |
2. pielikums | - | Pieteikuma vēstules forma; |
3. pielikums | - | Iepirkuma līguma projekts; |
4. pielikums | - | Finanšu piedāvājuma forma. |
5. pielikums | - | Pretendenta pieredzes apliecinājuma forma |
Iepirkuma komisijas priekšsēdētājs X.Xxxxxx
informācijas sistēmas izstrāde un uzturēšana”, Iepirkuma identifikācijas Nr. AD 2016/5
nolikumam
Tehniskā specifikācija
“Sabiedriskā transporta kustības maršrutu attēlošanas ģeotelpiskās informācijas sistēmas izstrāde un uzturēšana"
(identifikācijas Nr. AD 2016/5)
1 IEVADS
1.1 Nolūks
Tehniskās specifikācijas mērķis ir aprakstīt prasības sistēmai “SĢIS”, kas nodrošinās autotransporta reisu shēmu izveidošanu uz ģeotelpisko datu kartes un izveidoto shēmu sasaistīšanu ar informāciju par reisiem, kas glabājas citās informācijas sistēmās. Dokuments paredzēts vienotas izpratnes veidošanai starp sistēmas pasūtītāju SIA “Autotransporta direkcija” (turpmāk – ATD), sistēmas gala lietotājiem un potenciālajiem sistēmas izstrādātājiem.
1.2 Darbības sfēra
Šis dokuments apraksta prasības sabiedriskā transporta ģeogrāfiskās informācijas sistēmai, kuru paredzēts izstrādāt, lai šī projekta ietvaros nodrošinātu rīku reisa shēmu bāzes izveidošanai, kuru nākotnē plānots papildināt un pilnveidot par pilnvērtīgu sabiedriskā transporta kustības monitorēšanas un modelēšanas tehnisko risinājumu.
1.3 Atslēgvārdi un saīsinājumi
API | Lietojumprogrammu programmēšanas saskarne |
ATD | Valsts SIA “Autotransporta direkcija” |
Reisa shēma | Reisa maršruta līnijas vektordati ar tos aprakstošiem metadatiem, kas ļauj realizēt šiem vektordatiem atbilstošu reisa attēlojumu kartē |
SĢIS | STIFSS Ģeogrāfiskās informācijas modulis |
STIFSS | Sabiedriskā transporta informācijas un finanšu statistikas sistēma |
WCS standarts | Web Coverage Service, Open Geospatial Consortium definēts |
WFS | Web Feature Service, Open Geospatial Consortium definēts standarts |
WFS-T definēts standarts | Transactional Web Feature Service, Open Geospatial Consortium |
WMS | Web Map Service, Open Geospatial Consortium definēts standarts |
1.4 Prasību prioritātes
Obligāta Obligāto prasību realizācijas aprakstam jābūt pietiekamam, lai nepārprotami būtu aprakstīts prasības realizācijas mehānisms vai rīki (līdzekļi), ar kuriem ir iespējams realizēt prasību un pretendenta izpratne par piedāvājamo risinājumu. Apraksts, kurš saturēs prasības teksta kopiju vai tikai prasības izpildes apsolījumu, būs pretrunā ar tehniskās
specifikācijas prasībām, kā arī citu prasību realizācijas piedāvājumu, netiks uzskatīts par detalizētu un šādi piedāvājumi tiks izslēgti no vērtēšanas.
Nākotnes Nākotnes prasības nav sistēmā jārealizē. Tās jāņem vērā, jo tās paredzēts realizēt sistēmas ieviešanas nākošajās kārtās. Sistēma ir jāprojektē un jāizstrādā tā, lai, realizējot nākotnes prasības, sistēmas esošajā programmatūrā būtu jāveic pēc iespējas mazāk pārveidojumu. Piedāvājumā ir jābūt aprakstītam, kā nākotnes prasības tiks realizētas un iekļausies sistēmā.
Prasību realizācijas aprakstam jābūt pietiekamam, lai nepārprotami būtu aprakstīts prasības realizācijas mehānisms vai rīki (līdzekļi), ar kuriem ir iespējams realizēt prasību un pretendenta izpratne par piedāvājamo risinājumu
Apraksts, kurš saturēs prasības teksta kopiju vai tikai prasības izpildes apsolījumu, būs pretrunā ar tehniskās specifikācijas prasībām, kā arī citu prasību realizācijas piedāvājumu, netiks uzskatīts par detalizētu un šādi piedāvājumi tiks izslēgti no vērtēšanas.
2 VISPĀRĒJAIS APRAKSTS
2.1 Produkta perspektīva
SĢIS ir rīks, kuru ATD izmanto sabiedriskā transporta maršrutu tīkla plānošanas funkcijas veikšanai un kas papildina STIFSS (ATD informācijas sistēma) pamatfunkcijas ar ģeogrāfiskas informācijas ievadi un vizualizēšanu uz kartes. STIFSS uzdevums ir reģistrēt visu informāciju, kas nepieciešama pasūtītā sabiedriskā transporta pakalpojumu uzskaitei, izmaksu uzskaitei un pakalpojuma kvalitātes nodrošināšanai. Savukārt SĢIS uzdevums ir veidot reisa shēmas, kas uz kartes attēlo ceļu, pa kuru brauc vai plānots braukt sabiedriskajam transportam.
Lai SĢIS varētu iegūt un saglabāt ģeogrāfiska rakstura datus, ATD nepieciešams arī ieviest ĢIS Serveri, kas atbalsta atvērtus standartus.
Nākotnē paredzēts, ka SĢIS arī nodrošinās sabiedriskā transporta reisu noslodzes un savstarpējās sasaistes analīzi un modelēšanu, kā arī sabiedriskā transporta kustības kontroli, sekojot tā atrašanās vietai reālajā laikā.
2.2 Lietotāja raksturiezīmes
SĢIS izmantos personas ar sekojošām lomām:
Administrators – lietotājs ar tiesībām rediģēt lietotāju sarakstu un lietotāju pieejas tiesības, kā arī skatīt un labot datus
Lietotājs – lietotājs ar tiesībām skatīt un labot datus Skatītājs – lietotājs ar tiesībām tikai skatīt datus
Paredzamajiem sistēmas lietotājiem ir ilgstoša pieredze darbā ar informācijas sistēmām, taču ikdienas darbs nav saistīts ar ģeogrāfisku datu manipulēšanu.
2.3 Sistēmas arhitektūra
Reisu shēmas Ceļu karte u.c.
Attēls 1 - SĢIS ārējās saskarnes
STIFSS nodod pamatdatus SĢIS, tai skaitā pieturvietas maršrutus un kustības sarakstus. Papildus STIFSS API ir paredzēta iespēja iegūt no STIFSS klasifikatoru (sk. Tehniskās specifikācijas I. Pielikumā “/I18n”) nosaukumus, ko izmantot lietotāja saskarnēs. Savukārt SĢIS ir jānodrošina iespējas atvērt apskatei interaktīvas kartes ar reisa shēmām.
Datu apmaiņai nepieciešamo STIFSS un SĢIS API apraksti atrodami Tehniskās specifikācijas Pielikumos I un II. Tā kā STIFSS tiek regulāri pilnveidots, tad ir iespējamas izmaiņas API uzskaitītajos datu laukos un to vērtībās.
Ģeotelpisku datu glabāšanai būs jāievieš ĢIS serveris, attiecīgi SĢIS no šī servera iegūs informācju, ko attēlot uz kartes un nosūtīs tam izveidotās reisa shēmas glabāšanai.
3 VISPĀRĪGĀS UN CITAS PRASĪBAS
3.1 Normatīvā bāze
[V1.1] Izstrādātajai sistēmai jāatbilst Latvijas Republikas likumiem un normatīvajiem aktiem.
Sabiedriskā transporta nozari tieši reglamentē 14.06.2007. "Sabiedriskā transporta pakalpojumu likums", (turpmāk tekstā – „STPL”) uz kā pamata izdoti sekojošie normatīvie akti.
1. 28.08.2012. MK noteikumi Nr.599 "Sabiedriskā transporta pakalpojumu sniegšanas un izmantošanas kārtība" regulē sabiedriskā transporta sniegšanas un izmantošanas kārtību”;
2. 31.03.2015. MK noteikumi Nr.153 “Noteikumi par pasažieru kategorijām, kuras ir tiesīgas izmantot braukšanas maksas atvieglojumus maršrutu tīkla
maršrutos”;
3. 11.08.2015. MK noteikumi Nr.461 “Vienotas sabiedriskā transporta pakalpojumu uzskaites sistēmas izveidošanas, uzturēšanas un attīstīšanas kārtība”;
4. 13.06.2010. MK noteikumi Nr.634 „Sabiedriskā transporta pakalpojumu organizēšanas kārtība maršrutu tīklā”;
5. 28.07.2015. MK noteikumi Nr.435 “Kārtība, kādā nosaka un kompensē ar sabiedriskā transporta pakalpojumu sniegšanu saistītos zaudējumus un izdevumus un nosaka sabiedriskā transporta pakalpojuma tarifu”.
(Obligāta)
3.2 Sistēmas darbības koncepcija
[V2.1] Sistēmai jābūt veidotai atbilstoši pasūtītāja noteiktajai arhitektūrai
(Obligāta).
[V2.2] Izstrādātājam risinājumam jābūt veidotam saskaņā ar pasūtītāja IT attīstības stratēģiju:
1. Sistēmas izstrāde ir jārealizē uz Windows platformas x64 versijas;
2. Sistēmas datu bāzes risinājumiem ir jāizmanto Microsoft SQL Server Standard Edition;
3. Sistēmas izstrādei ieteicams izmantot programmēšanas valodu PHP;
4. Sistēmas web servera programmatūrai ieteicams izmantot IIS.
Pasūtītājs nodrošina produkcijas un akcepttesta vidēm nepieciešamos tehniskos resursus. Windows platformā (x64), datu bāzu risinājumam nodrošinot Microsoft SQL Server standarta versiju.
Pasūtītājs dod pieeju SĢIS izstrādes resursiem, izmantojot drošu kanālu (VPN). Gadījumā, ja Izstrādātājs veic Sistēmas izstrādi ar citu programmēšanas valodu, citā platformā, izmanto citus datu bāzu risinājumus vai citas tehnoloģijas, kas nesaskan ar pašreizējo pasūtītāja IT attīstības stratēģiju, izstrādātājam ir jānorāda visas papildus izmaksas atbilstoši prasībai [D4].
(Obligāta)
3.3 Projekta pārvaldība
[V3.1] Izstrādātājam jānodrošina labās prakses principiem atbilstoša IS izstrādes vide.
Tā kā ATD nākotnē plāno nodrošināt SĢIS uzturēšanu un nepieciešamo izmaiņu veikšanu pēc SĢIS uzturēšanas termiņa beigām ar saviem resursiem, Izstrādātājam 1 (viena) mēneša laikā no līguma noslēgšanas dienas ir pilnībā jāsagatavo un jānokonfigurē izstrādes, testēšanas, akcepttestēšanas un produkcijas vides uz Pasūtītāja infrastruktūras.
Izstrādes procesā jāizmanto vismaz šādus rīkus:
• Izstrādes rīki (piem., Eclipse, NetBeans);
• Nepārtrauktas integrēšanas vide (Continuous integration tool) (šī projekta laikā tiks izmantots pasūtītāja izmantotais rīks - Jenkins);
• Izejas koda vadības sistēma (Source code management system) rīks (šī projekta laikā tiks izmantots pasūtītāja izmantotais rīks - Git);
• Vienībtestēšanas rīki (piem., PHPUnit, Cuke4Php);
• Automātiskie uzstādīšanas rīki (deployment automation tool) (piem., Capistrano, Phing);
• Problēmu pieteikumu rīks (šī projekta laikā tiks izmantots pasūtītāja izmantotais rīks - Redmine);
• Projekta dokumentu vietne (piem. SharePoint Service 3 );
• Monitoringa rīks (šī projekta laikā tiks izmantots pasūtītāja izmantotais rīks
– Zabbix).
Piedāvātais izstrādes vides komplekts nodrošina atbalstu vismaz 2 aktīvu izstrādātāju darba vietām. Risinājumā tiek nodrošināta lietotāju autentifikācija. Risinājumā ir jābūt savstarpēji integrētai problēmu pieteikumu, vienībtestēšanas, nepārtrauktās integrēšanas u.c. sadaļu funkcionalitātei. Risinājumam ir jāatbalsta pakāpeniskas jeb iteratīvas piegādes modelis.
Rīku iegādes izmaksas, kā arī uzturēšanas izmaksas jānorāda atbilstoši prasībai [D4]. Pretendentam Tehniskajā piedāvājumā ir detalizēti jāapraksta, kā 1 (viena) mēneša laikā no līguma noslēgšanas dienas tiks sagatavota un nokonfigurēta izstrādes, testēšanas, akcepttestēšanas un produkcijas vide, izklāstot piedāvātos rīkus katrā no vidēm un norādot to atbilstību kopējām prasībām (Tīmekļa saskarne, savstarpējā rīku integrācija un daudzlietotāju režīms) un priekšrocības (bezmaksas rīks, lietotājam ērta izmantošana, pārskatāmība, grupēšana, meklēšana u.c.)
(Obligāta).
[V3.2] Izstrādātājam jānodrošina labās prakses principiem atbilstošs IS izstrādes process.
Izstrādātājam Projekta realizācija ir jānodrošina atbilstoši pakāpeniskās ieviešanas (agile) metodoloģijai, nodrošinot ciešu sadarbību starp Pasūtītāja pārstāvi un Izstrādātāja speciālistiem.
Pretendents var izvēlēties veikt projekta realizāciju atbilstoši kādam citam no labās prakses IT projektu standartiem. Šajā gadījumā Pretendentam piedāvājumā ir detalizēti jāizklāsta, kā tiks nodrošināta Līguma prasību izpilde atbilstoši piedāvātajam projektu realizācijas standartam.
Pretendentam piedāvājumā ir jāapraksta izvēlētā projekta piegādes metodoloģija, izklāstot, kā tiks nodrošināta sadarbība ar Pasūtītāja pārstāvi
Neatkarīgi no piedāvātās metodoloģijas projekta realizācijā, Pretendentam ir jāparedz testēšanas fāzes īstenošana, kuras ietvaros tiek nodrošināta testēšanas scenāriju sagatavošana, attiecīgo testēšanas pasākumu veikšana un testu rezultātu iesniegšana Pasūtītājam. Pakāpeniskās ieviešanas (agile) metodoloģijas piemērošanas gadījumā testēšana ir veicama katras iterācijas ietvaros, un testēšanas rezultātu pārskats ir iesniedzams Pasūtītājam kopā ar citiem iterācijas nodevumiem.
(Obligāta).
3.4 Nefunkcionālās prasības
3.4.1 Veiktspēja
[NF1.1] 95% sistēmas lietotāju veiktajiem pieprasījumiem veicot saglabāšanu, dzēšanu un attēlošanu jāizpildās ātrāk kā 1 sekundē un 98% jāizpildās ātrāk kā 3 sekundes veicot lielu sarakstu atlasi vai dokumentu ģenerēšanu. Liela apjoma datu imports, eksports un laikietilpīgi aprēķini nedrīkst būtiski ietekmēt sistēmas lietotāju saskarnes darbības ātrumu darba laikā, līdz 10 vienlaicīgiem pieslēgumiem, kas noteikts iepriekš minētajā prasībā par pieprasījumu atbildes laikiem (Obligāta).
[NF1.2] Atskaitēm vai funkcijām, kuras lietotājs izmanto reizi nedēļā vai retāk, pieļaujams apstrādes laiks līdz 30 sekundēm, taču šajā gadījumā sistēmai jābrīdina lietotājs, ka izpildes laiks ir ilgāks (Obligāta).
[NF1.3] Izstrādātājam jāizstrādā un jāievieš mehānisms automatizētai ATD personāla informēšanai ( e-pasts) par katru gadījumu, kad sistēma neizpilda kādu veiktspējas prasībām, kā arī grafisks risinājums veiktspējas parametru vērtību grafiskai apskatei izvēlētā laika periodā (Obligāta).
[NF1.4] Interaktīvās kartes darbības ātrums nedrīkst būtiski pasliktināties, ja lietotājs pieprasa attēlot visas pieturvietas un reisa shēmas, kas ir datu bāzē (Obligāta).
3.4.2 Drošība
[NF2.1] SĢIS jānodrošina drošība un informācijas aizsardzības prasību izpilde atbilstoši labās prakses standartiem:
• LVS ISO/IEC 27001 Informācijas tehnoloģija. Drošības metodika. Prakses kodekss informācijas drošības pārvaldībai;
• LVS ISO/IEC 27002 Informācijas tehnoloģija. Drošības paņēmieni. Informācijas drošības pārvaldības sistēmas;
(Obligāta).
[NF2.2] SĢIS izstrādē ir jānodrošina, ka ir novērstas zemāk minēto drošības ievainojamību testēšanas vadlīniju uzskaitītās top 10 drošības ievainojamības:
• OWASP (Open Web Application Security Project) testēšanas vadlīnijas (OWASP Testing Guide);
• OWASP koda pārskatīšanas vadlīnijas (OWASP Code Review Guide);
• Atvērtā koda drošības testēšanas metodikas rokasgrāmata OSSTMM (Open Source Security Testing Methodology Manual);
(Obligāta).
[NF2.3] ATD ir tiesības veikt neatkarīgu piegādātās programmatūras drošības auditu pēc tās piegādes un Izstrādātājam ir jānodrošina visu atklāto ievainojamību novēršana pirms programmatūras pieņemšanas (Obligāta).
[NF2.4] SĢIS jānodrošina datu apmaiņas kanāla šifrēšana, izmantojot HTTPS protokolu. Jau sākot no autentifikācijas brīža, visām darbībām jābūt šifrētām. Pasūtītājs nodrošina reģistrētas trešās puses sertifikāta pieejamību, lai lietotājiem nebūtu jāapstiprina sertifikāta derīgums (Obligāta).
[NF2.5] SĢIS ir jānodrošina datu integritāte gan lietotāju manuāli ievadītiem datiem, gan no datnēm un sistēmām importētiem datiem (Obligāta).
3.4.3 Darbības nepārtrauktība
[NF3.1] Lai nodrošinātu augstu sistēmas pieejamību sistēma tiks virtualizēta, izmantojot VMware risinājumu (Obligāta).
[NF3.2] Izstrādātājam jāievieš produkcijas vidē un jānodod ATD IT speciālistu pārziņā rezerves kopēšanas procedūra, kas nodrošina datu rezerves kopijas veidošanu ne retāk kā 1 (vienu) reizi stundā un sistēmas rezerves kopijas veidošanu ne retāk kā 1 (vienu) reizi dienā (Obligāta).
[NF3.3] Izstrādātājam jāievieš produkcijas vidē datu un sistēmas atjaunošanas procedūra, kas nodrošina datu atjaunošanu 1 (vienas) stundas laikā un jānodrošina tās apraksta nodošana ATD IT speciālistu pārziņā (Obligāta).
3.4.4 Uzturamība
[NF4.1] SĢIS tiek integrēta ar vairākām ārējām sistēmām, kurām ir atšķirīga loģika un datu struktūras, tādēļ ir būtiski veidot brīvo sakabi (ang. loose coupling) moduļiem, kas nodrošina datu importu un eksportu (Obligāta).
[NF4.2] SĢIS uzturēšanu jāspēj veikt tās Izstrādātājam vai jebkuram citam profesionālam programmatūras izstrādes uzņēmumam ar pieredzi izmantotajā izstrādes vidē un produktos. Tādēļ piedāvātajā risinājumā nedrīkst būt iekļautas komponentes, kuras citiem izstrādātājiem nav iespējams vai nav atļauts izmantot. Kā arī visām šī projekta ietvaros izstrādātajām daļām ir jābūt pieejamam izejas kodam (Obligāta).
3.4.5 Kļūdu apstrāde
[NF5.1] Tā kā SĢIS ir būtiski nodrošināt datu integritāti, tad gadījumos, kad rodas kļūdas sarežģītu aprēķinu, datu importa vai eksporta procesa laikā, tad sistēma spēj
automātiski atkārtot procesu. Ja sistēmai kādas kļūdas dēļ atkārtoti neizdodas izpildīt uzdevumu līdz galam, tad par incidentu tiek ziņots administratoram. Informācijai par sistēmas darbības laikā notikušajām kļūdām ir jābūt pieejamai administratora
lietotāja saskarnē (Obligāta).
3.5 Lietotāja saskarnes prasības
[UI1] Lietotāja saskarnei ir jābūt intuitīvai, pēc iespējas jāizmanto plaši izplatīti risinājumi
(Obligāta).
[UI2] Reisa shēmu veidošanai uz interaktīvās kartes ir jābūt intuitīvai, vienkāršai un pēc iespējas automatizētai, lai lietotājam bez pieredzes darbā ar ĢIS reisa shēmas veidošana bez īpašas apmācības būtu saprotama un ātri izdarāma. Pasūtītājs patur tiesības pieprasīt saskarnes pārstrādāšanu vai uzlabošanu gadījumā, ja tas neapmierina lietotājus (Obligāta).
[UI3] Saskarnei jābūt pieejamai izmantojot tīmekļa pārlūkprogrammām Chrome, Firefox un IE10+, EDGE (Obligāta).
[UI4] Lietotāja saskarnei jābūt latviešu valodā. Saskarnēm kuras izmanto tikai sistēmas administrators pieļaujama angļu valoda (Obligāta).
3.6 Sistēmas ieviešanas prasības
[I1] Izstrādātājam ir jānodrošina Sistēmas piegāde atbilstoši sekojošiem izstrādes posmiem:
1. 1 (viena) mēneša laikā no līguma noslēgšanas datuma:
o dokuments, kas detalizēti apraksta Sistēmas arhitektūru;
o detalizēts Sistēmas Iterāciju ieviešanas plāns.
o pilnībā uzstādīta un nokonfigurēta izstrādes, testēšanas un akcepttestēšanas vide, izmantojot Pretendenta piedāvājumā norādītos rīkus.
2. pretendenta piedāvātajā laikā no līguma noslēgšanas dienas SĢIS ir ieviesta produkcijas vidē pilnā apjomā, pilnībā nodrošinot visu šajā specifikācijā noteikto funkcionalitāti. (Obligāta)
[I2] Visām problēmām, kas tiek atklātas Sistēmas ieviešanā ir jābūt dokumentētām Pasūtītāja norādītajā Problēmu pieteikumu rīkā (Obligāta).
[I3] Izstrādātājam ir jāveic ATD darbinieku (līdz 10) apmācība Sistēmas lietošanā (Obligāta).
[I4] Izstrādātājam ir jānodrošina sākotnējā kartogrāfiskā materiāla izveide un ielāde Sistēmā, kā arī jānodrošina sākotnējā maršrutu tīkla izveide, atbilstoši Izpildītāja sniegtajai informācijai, nodrošinot, ka Pasūtītājam līdz ar Sistēmas nodošanu produktīvajā lietošanā ir pieejams pilns maršrutu tīkla attēlojums tā aktuālā versijā Sistēmas ieviešanas brīdī.
3.7 Prasības dokumentācijai
[D1] Izstrādātājam ir jāpiegādā sekojoša dokumentācija:
• Iterāciju ieviešanas plāns;
• Sistēmas arhitektūra;
• Instalācijas rokasgrāmata (x.xx. Sistēmas klienta instalēšanas instrukcijas);
• Administratora rokasgrāmata;
• Uzturēšanas rokasgrāmata;
• Lietotāja rokasgrāmata;
• Specificētās saskarnes ar ārējām sistēmām un lietotājiem;
• Sistēmas arhitektūras apraksts;
• Sistēmas moduļu saskarņu apraksts;
• Dokumentācijai jābūt latviešu valodā un jātiek piegādātai elektroniski un drukātā veidā;
• Sistēmas testu piemēri un veikto testēšanas pasākumu pārskati.
(Obligāta)
[D2] Izstrādātājam jāpiegādā sistēmas klašu un to publisko metožu dokumentācija, kas skaidro to mērķi un darbības principu (Obligāta).
[D3] Dokumentācijas nodošana ATD:
• visi programmatūras nodevumi Izstrādātājam ir jāpiegādā uz CD-R vai cita pastāvīga, neizdzēšama datu nesēja;
• piegādātajai Sistēmai ir jāiekļauj Izstrādātāja veikto izstrāžu pirmkods ar klašu, procedūru (metožu) un parametru komentāriem, kā arī ar datu bāzes struktūras aprakstu;
• dokumentos ir jābūt aprakstītām izmantotajām klasēm, metodēm, procedūrām;
• saskaņotās dokumentu versijas jāpiegādā elektroniski PDF formātā;
• dokumentācijas nodevumi papildus jāpiegādā MS Word atpazīstamā formātā un 2 (divos) drukātos eksemplāros.
• dokumentācijai jāsatur informāciju par to, kā no piegādātā izejas koda izveidot izpildāmu failu.
• Dokumentācija izstrādājama atbilstoši standarta LVS 66:1996 „Programmatūras lietotāja dokumentācija” prasībām.
(Obligāta)
[D4] Sistēmas izstrādes izmaksās jāiekļauj visas trešo pušu produktu (ja tādi tiek izmantoti) licencēšanas un to ieviešanas izmaksas. Ja trešās puses nenodrošina beztermiņa licences, tām jābūt vismaz 2 (divu) gadu licencēm, kas ietver uzturēšanu. Jānorāda:
• licenču iegādes izmaksas;
• ja nepieciešamas atsevišķas licences izstrādātājiem, tad jāparedz to iegāde 2 darba vietām;
• izmaksas pasūtītāja IT speciālistu iepazīstināšanai ar nepieciešamajiem rīkiem un valodām, apjomā līdz 32 stundām);
• datu sagatavošanai un migrācijas izmaksas no esošām sistēmām uz jaunām, ja tas nepieciešams;
• citas izmaksas, kas var būt saistītas ar vairāku tehnoloģisko risinājumu vienlaicīgu lietošanu un attīstību ar Pasūtītāja resursiem.
Jānodrošina:
• visām risinājumam nepieciešamajām licencēm jābūt izmantojamām uz virtuālajām mašīnām;
• visām risinājumam nepieciešamajām licencēm jābūt savietojamām ar x64 arhitektūru;
• trešo pušu programmatūras licenču piegāde jāveic līdz akcepttestēšanas uzsākšanai;
• kopā ar trešo pušu produktiem Izstrādātājam ir jāpiegādā arī to programmatūras dokumentācija.
(Obligāta)
[D5] ATD pieder mantiskās un autortiesības uz sistēmas kodu. Prasība attiecas uz šī iepirkuma ietvaros izstrādātajām sistēmas komponentēm (Obligāta).
3.8 Uzturēšanas prasības
[U1] Izstrādātājam ir jānodrošina SĢIS uzturēšana 2 (divus) gadus, garantējot darba apjomu ne mazāku kā 80 (astoņdesmit) cilvēkstundas gadā. Nepieciešamo darbu prasības pirms to realizācijas apstiprina Pasūtītājs (Obligāta).
[U2] Izstrādātājam nepieciešamības gadījumā ir jānodrošina SĢIS pielāgošana jaunākām STIFSS versijām. Ja pielāgošanai nepieciešamais darba apjoms pārsniedz prasībā [U1] noteikto, tad puses vienojas par atsevišķu samaksu (Obligāta).
3.9 Garantijas prasības
[G1] Izstrādātājam ir jānodrošina vismaz 2 (divu) gadu garantijas periods izstrādātajai Sistēmai, skaitot no Sistēmas nodošanas ekspluatācijā dienas (Obligāta).
[G2] Sistēmas garantijas uzturēšanas laikā Izstrādātājam bez maksas jāveic ATD pieteikumu izpilde, tai skaitā 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 Izstrādātāja apzinātas vai neapzinātas rīcības rezultātā un kas apgrūtina Sistēmas izmantošanu atbilstoši Sistēmas tehniskajai specifikācijai, kāda tā bijusi, nododot Sistēmu ekspluatācijā (prasība attiecas uz visiem Sistēmas garantijas laikā veiktajiem pieteikumiem) (Obligāta).
[G3] Izstrādātājam ir jānodrošina tehniskais atbalsts darba dienās no 8:00 līdz 18:00
(Obligāta).
[G4] Tehniskais atbalsts, palīdzība un konsultācijas sniedzams, izmantojot šādus komunikācijas kanālus – telefoniski, Skype, pa e-pastu un klātienē (Obligāta).
[G5] Piedāvājumā jāiekļauj pieteikumu risināšanas procedūra, kurā būtu ietverti šādi temati:
• pieteikumu klasifikācija, prioritātes (saskaņā ar IEEE J-STD-016-1995 standartu ):
1. prioritāte: Avārija.
2. prioritāte: Kļūda, no kuras nevar izvairīties.
3. prioritāte: Kļūda, no kuras var izvairīties.
4. prioritāte: Neprecizitāte.
5. prioritāte: Priekšlikums par izmaiņām.
6. prioritāte: Nepieciešama konsultācija.
(Obligāta)
• pieteikumu pieteikšanas veidi;
• pieteikumu reģistrēšana, saskaņošana;
• Izstrādātāja reakcijas laiki uz pieteikumiem;
• pieteikumu risināšana;
• kļūdas novēršanas termiņš atbilstoši kļūdas prioritātei.
[G6] Izstrādātajam jānodrošina attālināta kļūdu pieteikšanas iespēja, lietojot tālruni vai Internetu. Šī iespēja tiek nodrošināta Pasūtītāja kontaktpersonām darba dienās 9 stundas diennaktī - no 8:00 līdz 18:00. Pieteikumus, kas iesniegti pēc 18.00 vai izejamā (svētku) dienā, uzskatāms par nākamajā darbadienā 8.00 no rīta saņemtu. Darba stundas tiek aprēķinātas Pasūtītāja darba laikā no 8:00 līdz 18:00 darba dienās. Ārpus minētā darba laika pieteikumi tiek pieņemti elektroniski, darbība tiek uzsākta nākamās darba dienas sākumā (Obligāta).
[G7] Procedūra jāsaskaņo ar ATD slēdzot līgumu, saskaņā ar Prasību pielikumā iekļauto līguma projektu (Obligāta).
4 FUNKCIONĀLĀS PRASĪBAS
4.1 SĢIS
4.1.1 Lietotāju autorizācija
[LG1.1] Administrators var pievienot jaunus lietotājus un labot esošos, bloķēt un atjaunot esošos (Obligāta).
[LG1.2] Administrators var norādīt lietotājiem lomas ar atļaujām tikai lasīt vai lasīt un rakstīt reisa shēmu datus (Nākotnē lomas, iespējams, mainīsies, tādēļ lomu veidošanas mehānismam ir jābūt elastīgam) (Obligāta).
[LG1.3] Lietotājam jāautorizējas, lai uzsāktu jaunu sesiju SĢIS sistēmā (Obligāta).
[LG1.4] Administrators var nomainīt lietotājam paroli (Obligāta).
[LG1.5] Lietotājs var nomainīt savu paroli (Obligāta).
[LG1.6] Sistēma reģistrē lietotāju un laiku, kad veiktas izmaiņas datos (Obligāta).
4.1.2 Reisa pamatinformācijas ielādēšana no STIFSS
[LG2.1] Lietotājs var ielādēt/atjaunināt pieturvietu sarakstu no STIFSS (Obligāta).
[LG2.2] Lietotājs var ielādēt/atjaunināt maršrutu sarakstu no STIFSS (Obligāta).
[LG2.3] Lietotājs var ielādēt/atjaunināt reisu sarakstu no STIFSS (Obligāta).
4.1.3 Reisa shēmas rediģēšana
4.1.3.1 Reisa shēmu pārvaldīšana
[LG3.1.1] Lietotājs var izveidot reisa shēmu, par pamatu ņemot STIFSS reģistrēta reisa kustības sarakstu (pieturvietu secību) (Obligāta).
[LG3.1.2] Lietotājs var izveidot reisa shēmu ar pieturām, STIFSS neapstiprināta reisa projektam (Obligāta).
[LG3.1.3] Lietotājs var izveidot reisa shēmu gan izmantojot, gan neizmantojot STIFSS pieturvietas, neatkarīgi no tā, vai reiss apstiprināts STIFSS (Obligāta).
[LG3.1.4] Lietotājs var kopēt reisa shēmu no citiem reisiem, un pielāgot to reisa kustības sarakstam (Obligāta).
[LG3.1.5] Lietotājs var pievienot reisa shēmai birkas (atslēgvārdi, kurus izmanto, lai aprakstītu vienību), lai būtu vieglā tās meklēt (Obligāta).
[LG3.1.6] Lietotājs var filtrēt, kuras reisa shēmas parādīt uz kartes pēc visiem pieejamajiem atribūtiem, tai skaitā datiem par saistītajiem maršrutiem un reisiem (Obligāta).
4.1.3.2 Darbs ar karti
[LG3.2.1] Lietotājs var apskatīt Latvijas ceļu karti (Obligāta)
[LG3.2.2] Lietotājs var mērogot karti vismaz 10 līmeņos no mēroga 1:2000 līdz 1:2000000(Obligāta).
[LG3.2.3] Lietotājs var pārvietot kartes redzamo apgabalu izmantojot vilkt un nomest metodi
(Obligāta).
[LG3.2.4] Lietotājs var izvēlēties uz kartes parādīt vai noslēpt sekojošos slāņus, kas pieejami uz ĢIS servera (ATD būs datu gala lietotājs):
• Autoceļi un ielas (A, P, V, pašvaldību, „privātie” ceļi un ielas) (ar ceļu numuriem, ielas ar nosaukumiem, māju numuriem ceļiem, kas nav “privātie”);
• Republikas pilsētas (ar nosaukumiem);
• Novadu robežas (ar novadu nosaukumiem, krāsaina, vienkrāsaina);
• Novados esošie pagasti (ar nosauktiem);
• Novadu pilsētas (ar nosaukumiem);
• Plānošanas reģionu robežas (ar plānošanas reģiona nosaukumu);
• Autoostas (ar un bez nosaukumiem);
• Autobusu pieturvietas (ar un bez nosaukumiem);
• Ceļa seguma identifikācija (asfalts vai grants);
• Dzelzceļa līnijas ;
• Ūdeņi (ar nosaukumiem);
• Tilti;
• Dzelzceļa pārbrauktuves;
• Dzelzceļa stacijas (ar un bez nosaukumiem);
• Dzelzceļa pieturas (ar un bez nosaukumiem)
(Obligāta).
[LG3.2.5] Lietotājs var izvēlēties uz kartes parādīt, vai noslēpt sekojošos slāņus, kas pieejami uz ĢIS servera (papildus prasības, kuras pretendents var neiekļaut piedāvājumā):
• Valsts iestāžu un to struktūrvienību atrašanās vietas (ar un bez nosaukumiem);
• Pašvaldības iestāžu un to struktūrvienību atrašanās (ar un bez nosaukumiem);
• Ārstniecības iestāžu atrašanās vietas (ar un bez nosaukumiem);
• Lielo2 uzņēmumu (darba vietas) atrašanās vietas (ar un bez nosaukumiem);
• Mācību iestāžu atrašanās (ar un bez nosaukumiem);
• Ilgstošās sociālās aprūpes un sociālās rehabilitācijas iestādes (ar un bez nosaukumiem);
• Kultūras iestāžu atrašanās (ar un bez nosaukumiem).
2 Uzņēmuma kategorija ir noteikta, ņemot vērā Gada pārskatu un konsolidēto gada pārskatu likuma 5.panta piektās daļas regulējumu.
4.1.3.3 Reisa shēmu ģeotelpisko datu rediģēšana [LG3.3.1] Lietotājs var apskatīt reisa shēmu uz kartes (Obligāta).
[LG3.3.2] Lietotājs veidojot reisa shēmu ar STIFSS nesaistītiem maršrutiem, var brīvi izvēlēties sākuma un beigu punktu (Obligāta).
[LG3.3.3] Lietotājs, veidojot reisa shēmu, var norādīt, ka sākuma un/vai beigu punkts ir noteikta pietura (Obligāta).
[LG3.3.4] Lietotājs, veidojot reisa shēmu uz kartes, var atzīmēt pieturvietas secībā, kādā transports tajās apstāsies (Obligāta).
[LG3.3.5] Lietotājs var iezīmēt braucamā ceļa posma sākuma un beigu punktus, brīvi rediģēt (dzēst vai papildināt), bet SĢIS automātiski uzzīmē piemērotu līniju pa ceļu (Obligāta).
[LG3.3.6] Lietotājs jauna reisa shēmas veidošanai var kopēt esoša reisa shēmu (Obligāta) . [LG3.3.7] Lietotājs SĢIS automātiski uzzīmētai līnijai var izmainīt ceļa posma līniju, ar peli
uz kartes pievienojot papildus punktus ceļa posma līnijai un pārvelkot tos, vai
attiecīgi noņemot liekos, lai veiktu vajadzīgās maršruta izmaiņas. Attiecīgi ceļa posmi no un līdz jaunajiem posmiem tiek automātiski pārzīmēti kā norādīts [LG3.3.5] (Obligāta)
[LG3.3.8] Lietotājs var norādīt kādus ģeogrāfiskās informācijas slāņus parādīt uz kartes (piemēram, pieturvietas un izglītības iestādes) (Obligāta).
[LG3.3.9] Lietotājs, veidojot reisa shēmu, uz kartes var arī pievienot karšu virsrakstus un anotācijas, kas norāda uz noteiktu punktu kartē vai ir novietoti noteiktā vietā kartē. Anotācijas ir piesaistītas attiecīgajam reisam (Obligāta).
[LG3.3.10] Lietotājs uz kartes var apskatīt pieturvietas (Obligāta).
[LG3.3.11] Lietotājs, uzklikšķinot uz pieturvietas marķiera, var apskatīt informāciju par šo pieturvietu (Obligāta).
[LG3.3.12] Lietotājs, uzklikšķinot uz reisa shēmas, var apskatīt tās anotāciju (Obligāta).
[LG3.3.13] Lietotājs var nomērīt attālumu pa norādīto maršrutu starp diviem punktiem kartē
(Obligāta).
[LG3.3.14] Lietotājs var nomērīt braukšanas laiku starp diviem punktiem kartē (Obligāta).
[LG3.3.15] Lietotājs var redzēt kartē izceltus ceļu posmus, kur pārklājās kartē atrādītās reisu shēmas (Obligāta).
4.1.3.4 Piekļuve reisa shēmām no STIFSS
[LG3.4.1] Lietotājs var izmantot URL, kas atver reisa shēmas izveidošanas vai labošanas skatu, lai lietotājs no STIFSS, rediģējot reisu, varētu ērti pāriet uz SĢIS un rediģēt saistīto reisa shēmu (Obligāta).
[LG3.4.2] Lietotājs SĢIS redz, atbilstošu paziņojumu, ja STIFSS ir veiktas kopējās pieturvietu informācijas vai apstiprināta kustības saraksta izmaiņas reisam, kam ir izveidota reisa shēma SĢIS (Obligāta).
4.1.3.5 Pārskatu veidošana
[LG3.5.1] Lietotājs, skatot vairākus reisus uz kartes, var izvēlēties, parādīt visu reisu anotācijas (Obligāta).
[LG3.5.2] Lietotājs var veidot un saglabāt pārskata slāņus atlasot reisa shēmas pēc dažādu kritēriju kombinācijas, piemēram, pēc maršrutiem, pārvadātājiem, plānošanas reģioniem
u.c par reisiem pieejamās informācijas (Obligāta).
[LG3.5.3] Lietotājs var pārskata slāņa reisa shēmām mainīt uz kartes redzamo vizuālo noformējumu (piemēram, līniju krāsa, biezums, marķieru forma un ikonas) (Obligāta).
[LG3.5.4] Lietotājs var novietot uz pārskata kartes anotācijas (Obligāta).
[LG3.5.5] Lietotājs var zīmēt uz pārskata kartes vienkāršas figūras (līnijas, riņķus, taisnstūrus, bultas) (Obligāta).
[LG3.5.6] Lietotājs var saglabāt izveidoto pārskatu, lai varētu to atkārtoti apskatīt vai rediģēt
(Obligāta).
[LG3.5.7] Lietotājs var saglabāt izveidoto pārskatu kā png attēlu un izvēlēties izšķirtspēju
• Kartes izdrukai uz A3 - 4900 x 3500 px
• Ievietošanai internetā vai dokumentos - 1024 x 726 px
(Obligāta)
[LG3.5.8] Lietotājs var saglabāt aktuālo reisu shēmu karti ar visiem saistītajiem datiem. Šādu pārskatu paredzēts veidot divas reizes gadā, lai nākotnē varētu apskatīt vēsturisko reisa shēmu stāvokli. Tas ietver arī saistīto klasifikatoru kā pieturvietu vai reisu saglabāšanu, jo laika gaitā var mainīties pieturvietu atrašanās vieta, pārvadātāji, kas nodrošina reisu un cita informācija (Obligāta)
4.2 ĢIS serveris
4.2.1 Datu apmaiņas protokoli
[LG5.1.1] ĢIS serveris nodrošina rastra tipa ģeotelpisko datu pieprasīšanu izmantojot WMS protokolu (Obligāta).
[LG5.1.2] ĢIS serveris nodrošina vektora tipa ģeotelpisko datu pieprasīšanu izmantojot WFS protokolu (Obligāta).
[LG5.1.3] ĢIS serveris nodrošina no SĢIS rīka izveidoto reisa shēmu saglabāšanu izmantojot WFS-T protokolu (Obligāta).
[LG5.1.4] ĢIS serveris nodrošina koordināšu datu iegūšanu WGS 84 Web Mercator formātā
(Obligāta).
[LG5.1.5] ĢIS serveris nodrošina analītiska tipa ģeotelpisko datu pieprasīšanu izmantojot WCS protokolu (Nākotnes).
4.2.2 Servera datu pārvaldība
[LG5.2.1] Administrators var piesaistīt rastra datu avotus ESRI ArcGrid, GeoTIFF un JPEG2000 formātā (Obligāta).
[LG5.2.2] Administrators var piesaistīt vektoru datu avotus PostGIS un ESRI™ Shapefile formātos (Obligāta).
[LG5.2.3] Administrators var piesaistīt vektora datu avotus no citiem WFS serveriem
(Obligāta).
[LG5.2.4] Administrators var ielādēt/atjaunināt punktveida datu kopas (piemēram, izglītības iestāžu vai citu objektu sarakstu ar to atrašanās vietas koordinātām) no CSV datnes (Obligāta).
4.3 Vispārīgas prasības lietotāja darbam ar sistēmu
[LG6.1] Lietotājs sarakstu (piem. klasifikatoru vai reisu sarakstu) skatos var attiecīgā saraksta datus filtrēt un kārtot pēc vairākiem datu laukiem vienlaicīgi (Obligāta).
[LG6.2] Lietotājs sarakstu skatos, filtrējot pēc klasifikatoru laukiem, var izvēlēties no iespējamām vērtībām (Obligāta).
[LG6.3] Lietotājs var dzēst datus tikai, ja tam nav saistīto ierakstu, lai tiktu saglabāta vēsturisko datu integritāte (Obligāta).
[LG6.4] Lietotājs var arhivēt datus, lai tie vairs neparādītos izvēlnēs, veidojot jaunus ierakstus, vai labojot esošos, bet būtu apskatāmi datubāzes ierakstos kur tie izmantoti pirms arhivēšanas (Obligāta).
[LG6.5] Administrators var atarhivēt pamatdatus, lai tos varētu turpināt izmantot veidojot un labojot jaunus ierakstus (Obligāta).
[LG6.6] Ja lietotājs kļūdas ievadot datus, tad sistēma parāda atbilstošu kļūdas paziņojums, kas skaidro, kurā laukā kāda kļūda atrasta (Obligāta).
[LG6.7] Lietotājs var uzklikšķināt uz saites, lai apskatītu saistītos ierakstus vai atfiltrētus sarakstus (Obligāta).
5 DATU APRAKSTS
5.1 Maršruts
1. Tips – vietējās nozīmes / starppilsētu / skolēnu / cits
2. Plānošanas reģions – netiek norādīts starppilsētu tipa maršrutiem
3. Rajons – tiek norādīts tikai vietējās nozīmes maršrutiem
4. Kods (maršruta numurs) – Maršruta numuram ir noteikta struktūra, kur katram ciparam numurā var būt dažādas nozīmes, kas definētas MK noteikumos. Maršruta numerācijas princips - pirmā cipara nozīme:
1,2 – sākotnēji domāti autobusu komercpārvadājumiem, taču faktiski netiek izmantoti, 3,5,6 – autobusu vietējie maršruti
4 – sistēmas ietvaros tiks veidoti vilcienu maršruti, kurus līdz šim nenumurēja 7 – autobusu starppilsētu maršruti
Pārējie 3 cipari veido kārtas numuru
5. Nosaukums
6. Lote (nav,1-8)
7. Statuss – atvērts / slēgts
8. Pārvadājuma veids – Starppilsētu autobusu maršruti, Starppilsētu vilcienu maršruti, Vietējie maršruti, Pilsētas maršruti.
Par skolēnu maršrutu, projektu un citu STIFSS nekodētu maršrutu izveidei nepieciešamo datu aprakstu puses vienojas izstrādes procesā
Sagaidāmais datu apjoms: līdz 3 000 ierakstu. Skaits nākamajos izstrādes posmos var palielināties.
5.2 Pieturvieta / Dzelzceļa stacija
1. Kods
2. Nosaukums
3. Transporta tips (autobuss, vilciens)
4. Ceļš/iela/dzelzceļa posms
5. GPS koordinātas
Lielākajai daļai pieturu ir divas autobusu apstāšanās vietas, kas paredzētas, lai autobuss varētu ērti apstāties, gan prom ceļā, gan atpakaļceļā.
Sagaidāmais datu apjoms: līdz 15 000 ierakstu.
5.3 Reiss
Vienam maršrutam var būt vairāki reisi.
1. Vispārējie dati
a. Uzņēmums (Pārvadātājs)
b. Līgumi
c. Maršruta Nr
d. Reisa Nr
e. Reisa nosaukums
f. Sēdvietu skaits no
g. Sēdvietu skaits līdz
h. Derīguma termiņš no
i. Derīguma termiņš līdz
j. Statuss (projekts, atvērts, slēgts, anulēts)
k. Reisa izpildes dienas (norādītas viena vai vairākas nedēļas dienas)
l. Piezīmes par izpildi (var izvēlēties vienu vai vairākas no iespējām - Svētku dienās, Pirmssvētku dienas, Pēc svētku dienas, Mācību brīvlaiks, Mācību laiks, Sezonalitāte)
2. Kustības saraksts
a. pieturvietu secīgs saraksts
i. Pieturvietas kods
ii. Nosaukums
iii. Atiešanas laiks
Par skolēnu maršrutu, projektu un citu STIFSS nekodētu maršrutu izveidei nepieciešamo datu aprakstu puses vienojas izstrādes procesā.
Sagaidāmais datu apjoms: līdz 15 000 ierakstu. Skaits nākamajos izstrādes posmos var palielināties.
5.4 Reisa shēma
1. Nosaukums
2. Kods
3. Statuss – projekts / aktuāls
4. Stājies spēkā (datums, ko iegūst no STIFSS reisiem vai skolēnu maršrutiem norāda manuāli)
5. Saistītais STIFSS reiss (ja tāds ir)
6. Birkas
6 NĀKOTNES ATTĪSTĪBA
6.1 Otrais posms
[N1.1] Iespējams veikt esošo un plānoto reisu analīzi pa laikiem, pa pārvadājuma veidiem un pasažieru apjomiem un vizualizēt analīzes rezultātus uz kartes (Nākotnes).
[N1.2] Iespējams modelēt pasažieru plūsmas izmaiņas mainot reisu sarakstu, pārvadājuma veidu un laika grafiku (Nākotnes).
[N1.3] SĢIS kustības saraksta izmaiņas reisiem ar statusu “projekts” automātiski nosūta uz STIFSS, tai skaitā attālumu un paredzamo braukšanas ilgumu starp pieturvietām (Nākotnes).
[N1.4] Lietotājs var izveidot vai labot reisa shēmu STIFSS reģistrētam reisam tikai, ja tā statuss ir “projekts” (Nākotnes).
6.2 Trešais posms
[N2.1] Iespējams apskatīt interaktīvu karti, kur redzami visu pašlaik ceļā esošo autobusu atrašanās vieta. Ziņas par atrašanās vietu atjaunojas ne retāk kā ik pēc 20 sekundēm (Nākotnes).
I. PIELIKUMS – STIFSS API
STIFSS nodrošina sekojošās API funkcijas
GET /marsruti
Atgriež sarakstu ar maršrutiem
Pieprasījums:
URL: xxxxx://xxxxxx.xxx.xx/xxxxxxxx Parametri
Nosaukums | Apraksts | Iespējamās vērtības | Obligāts |
per_page | Norāda cik ierakstus atgriezt | No 1 līdz 100, pēc noklusējuma 100 | Nē |
page | Norāda kuru lapu ar rezultātiem atgriezt | Vesels skaitlis, pēc noklusējuma 1 | Nē |
changed_since | Atlasa tikai ierakstus, kas ir izveidoti, laboti, vai dzēsti periodā no dotā laika, līdz šim brīdim. | Datums un laiks ISO formātā | Nē |
Atbilde:
[
{
"tips": "starppilsētu",
"planosanas_regions": "Rīgas", "rajons": "Rīgas rajons", "kods": "4321",
"lote": [1,5,8],
"statuss": "atverts",
"parvadajuma_veids": "starppilsetu_autobuss", "nosaukums": "Rīga - Sigulda"
"created_at": "2015-10-08T16:20:30.45", "updated_at": "2015-10-10T11:31:30.17",
"deleted_at": null
}
]
GET /reisi
Atgriež sarakstu ar reisiem
Pieprasījums:
URL: xxxxx://xxxxxx.xxx.xx/xxxxx Parametri
Nosaukums | Apraksts | Iespējamās vērtības | Obligāts |
per_page | Norāda cik ierakstus atgriezt | No 1 līdz 100, pēc noklusējuma 100 | Nē |
page | Norāda kuru lapu ar rezultātiem atgriezt | Vesels skaitlis, pēc noklusējuma 1 | Nē |
changed_since | Atlasa tikai ierakstus, kas ir izveidoti, laboti, vai dzēsti periodā no dotā laika, līdz šim brīdim. | Datums un laiks ISO formātā | Nē |
Atbilde:
[
{
"reisa_kods": "4321-01",
"marsruta_kods": "4321", "parvadatajs": "A/S Nordeka", "ligumi": "ATD/ST-2015/X", "nosaukums": "Rīga - Sigulda", "sedvietu_skaits_no": 30,
"sedvietu_skaits_lidz": "45",
"deriguma_termins_no": "2015-08-01",
"deriguma_termins_lidz": "2016-08-01", "statuss": "atverts", "reisa_izpildes_dienas": [1,5,7], "piezimes_par_izpildi": [
{
"piezimes_veids": "svetku_dienas", "kustiba": "nekurse"
},
{
"piezimes_veids": "cits", "datums_no": "2015-12-01",
"datums_lidz": "2016-01-01", "kustiba": "nekurse"
}
],
"kustibas_saraksts": [
{
"seciba": "1", "pieturvietas_kods": "?",
"pieturvietas_nosaukums": "Ērberģes skola", "atiesanas_laiks": "7:55"
}
],
"created_at": "2015-10-08T16:20:30.45", "updated_at": "2015-10-10T11:31:30.17",
"deleted_at": null
}
]
GET /pieturas
Atgriež sarakstu ar pieturvietām un dzelzceļa stacijām
Pieprasījums:
URL: xxxxx://xxxxxx.xxx.xx/xxxxxxxx Parametri
Nosaukums | Apraksts | Iespējamās vērtības | Obligāts |
per_page | Norāda cik ierakstus atgriezt | No 1 līdz 100, pēc noklusējuma 100 | Nē |
page | Norāda kuru lapu ar rezultātiem atgriezt | Vesels skaitlis, pēc noklusējuma 1 | Nē |
changed_since | Atlasa tikai ierakstus, kas ir izveidoti, laboti, vai dzēsti periodā no dotā laika, līdz šim brīdim. | Datums un laiks ISO formātā | Nē |
Atbilde:
[
{
"kods": "6232",
"nosaukums": "Ērberģes skola", "transporta_tips": "autobuss", "cels": "?",
"longitude": "45.24322",
"latitude": "43.51231",
"created_at": "2015-10-08T16:20:30.45", "updated_at": "2015-10-10T11:31:30.17",
"deleted_at": null
}
]
POST /reisu_shemas/<reisa_nr> (Nākotnes)
Ja lietotājs izveido reisa shēmu reisam, kuram vēl nav kustības saraksts, tad SĢIS nosūta informāciju par jaunizveidoto shēmu uz STIFS, lai no shēmas varētu automātiski izveidot kustības saraksta melnrakstu
Pieprasījums:
URL: xxxxx://xxxxxx.xxx.xx/xxxxx_xxxxxx Parametri
Nosaukums | Apraksts | Iespējamās vērtības | Obligāts |
reisa_kods | Reisa kods | Nenoteikta garuma simbolu virkne | Jā |
kustibas_saraksts | JSON masīvs ar visām reisa pieturām | [ { "seciba": 1 "pieturas_kods": "6232", "attalums_no_ieprieksejas_pieturas": 5.3, "laiks_cela_no_ieprieksejas_pieturas": 5, "garuma_gradi": "45.24322", "platuma_gradi": "43.51231", }, {...} ] | Jā |
GET /i18n
Atgriež sarakstu ar klasifikatoru atšifrējumiem
Pieprasījums:
URL: xxxxx://xxxxxx.xxx.xx/x00x Parametri
Nosaukums | Apraksts | Iespējamās vērtības | Obligāts |
per_page | Norāda cik ierakstus atgriezt | No 1 līdz 100, pēc noklusējuma 100 | Nē |
page | Norāda kuru lapu ar rezultātiem atgriezt | Vesels skaitlis, pēc noklusējuma 1 | Nē |
Atbilde:
[
{
"klasifikators": "parvadajuma_veids", "vertibas": [
{
"vertibas_kods": "starppilsetu_autobuss",
"vertibas_nosaukums": "Starppilsētu autobuss"
},
{
"vertibas_kods": "vietejas_nozimes",
"vertibas_nosaukums": "Vietējās nozīmes"
}
]
},
{
"klasifikators": "reisa_statuss", "vertibas": [
{
"vertibas_kods": "atverts",
"vertibas_nosaukums": "Atvērts"
}
]
}
]
II. PIELIKUMS – SĢIS API
GET /reisu_shemas/<reisa_nr>
URL: xxxxx://xxxx.xxx.xx/xxxxx_xxxxxx/<reisa_nr>/
Atverot šo saiti SĢIS attēlo reisa shēmas rediģēšanas skatu attiecīgajam reisam.
Ja reiss ar doto numuru SĢIS sistēmā nav zināms, tad jāparāda atbilstošs kļūdas paziņojums. Reisam ar statusu “projekts”, ja ir piešķirtas atbilstošas pieejas tiesības, lietotājs var labot esošu reisa shēmu vai izveidot reisa shēmu, ja tāda vēl nav.
GET /reisu_shemas/<reisa_nr>/iegult
URL: xxxxx://xxxx.xxx.xx/xxxxx_xxxxxx/<reisa_nr>/iegult
SĢIS attēlo interaktīvu karti ko var iegult citās tīmekļa vietnēs izmantojot <iframe> HTML tagu
Pieteikums
Pielikums Nr.2. – Pieteikuma vēstules forma Atklāta konkursa „ Sabiedriskā transporta kustības maršrutu attēlošanas ģeotelpiskās
informācijas sistēmas izstrāde un uzturēšana”, Iepirkuma identifikācijas Nr. AD 2016/5
nolikumam
“Sabiedriskā transporta kustības maršrutu attēlošanas ģeotelpiskās informācijas sistēmas izstrāde un uzturēšana"
(identifikācijas Nr. AD 2016/5)
Vieta
Datums
Informācija par pretendentu
Pretendenta nosaukums | |
Reģistrācijas numurs | |
Juridiskā adrese | |
Pasta adrese | |
Tālrunis | |
Fakss | |
E-pasta adrese | |
Vispārējā interneta adrese |
Finanšu rekvizīti
Bankas nosaukums | |
Bankas kods | |
Konta numurs |
Kontaktpersona (atbildīgā persona)
Vārds, Uzvārds | |
Tālrunis | |
E-pasta adrese |
Ar šo mēs apliecinām savu dalību iepirkuma procedūrā. Apstiprinām, ka esam iepazinušies ar iepirkuma dokumentāciju un piekrītam visiem tajā minētajiem nosacījumiem, tie ir skaidri un saprotami, iebildumu un pretenziju pret tiem nav. Apliecinām, ka uz mums neattiecas iepirkumā noteiktie izslēgšanas nosacījumi. Apliecinām, ka visa iesniegtā informācija ir patiesa.
Vārds, Uzvārds | |
Ieņemamais amats | |
Paraksts |
informācijas sistēmas izstrāde un uzturēšana”, Iepirkuma identifikācijas Nr. AD 2016/5
nolikumam
Iepirkuma līguma projekts
Rīgā 2016.gada .
Valsts SIA „Autotransporta direkcija”, xxx.Xx. 40003429317, juridiskā adrese Xxxxx xxxx 00, Xxxx, XX - 0000, turpmāk tekstā Pasūtītājs, tās
personā no vienas puses,
,
turpmāk tekstā Izpildītājs, no otras puses,
xxxx kopā vai xxxxx xxxxxxxxx – Puse vai Xxxxx, pamatojoties uz 2016.gada
. izsludinātā iepirkuma „Sabiedriskā transporta kustības maršrutu attēlošanas ģeotelpiskās informācijas sistēmas izstrāde un uzturēšana” (iepirkuma identifikācijas Nr. AD 2016/5) rezultātiem, noslēdz šo līgumu un vienojas par sekojošo:
1. LĪGUMA PRIEKŠMETS
1.1. Pasūtītājs uzdod, bet Izpildītājs apņemas saskaņā ar Līgumam pievienoto Tehnisko specifikāciju (Pielikums Nr.1) un Izpildītāja piedāvājumu iepirkumā „Sabiedriskā transporta kustības maršrutu attēlošanas ģeotelpiskās informācijas sistēmas izstrāde un uzturēšana” (iepirkuma identifikācijas Nr. AD 2016/5 (Pielikums Nr.2) nodrošināt informācijas sistēmas izstrādes un ieviešanas pakalpojumu sniegšanu.
1.2. Izpildītājs apņemas veikt Līguma 1.1. punktā norādītos Pakalpojumus atbilstoši Līguma noteikumiem, un Pasūtītājs apņemas apmaksāt šos Pakalpojumus Līgumā noteiktajā kārtībā un termiņos.
2. LĪGUMA IZPILDES KĀRTĪBA UN IZPILDES TERMIŅŠ
2.1. Kopējais līguma izpildes termiņš (neieskaitot garantijas termiņu) ir mēneši pēc Līguma spēkā stāšanās.
2.2. Izpildītājs 2 (divus) gadu laikā pēc Līguma 2.17. punktā noteiktā informācijas sistēmas izstrādes un ieviešanas pieņemšanas – nodošanas akta parakstīšanas dienas nodrošina informācijas sistēmas uzturēšanu atbilstoši Izpildītāja piedāvātajam cilvēkstundu skaitam gadā - (skaits ar vārdiem) cilvēkstundas gadā.
2.3. Izpildītājs 2 (divu) gadu laikā pēc Līguma 2.17. punktā noteiktā informācijas sistēmas izstrādes un ieviešanas pieņemšanas – nodošanas akta parakstīšanas dienas nodrošina informācijas sistēmas garantiju, atbilstoši Līguma noteikumiem un Garantijas risinājuma procedūrai (Pielikums Nr.5).
2.4. Informācijas sistēmas (turpmāk tekstā – IS) izstrādes un ieviešanas nodevumu sagatavošana tiek veikta atbilstoši Pušu saskaņotajam IS programmatūras izstrādes un ieviešanas iterāciju plānam (Product backlog), kas tiek saskaņots 1 (viena) kalendārā mēneša laikā pēc Līguma spēkā stāšanās un kļūst par Līguma neatņemamu sastāvdaļu kā Pielikums Nr. 4. Dokumentā tiek ietverta šāda informācija:
2.4.1. Darba uzdevuma identifikators;
2.4.2. Darba uzdevuma apraksts;
2.4.3. Darba plānotais uzdevuma apjoms cilvēkstundās;
2.4.4. Darba uzdevuma izpildes kalendārais laiks;
2.4.5. Izpildes prioritāte;
2.4.6. Atkarības no citiem uzdevumiem vai ārējām sistēmām.
2.5. IS izstrādes un ieviešanas uzdevumi tiek piegādāti 1 (vienu) kalendāro mēnesi garos posmos (iterācijās), kurus sasniedzot Izpildītājs piegādā pilnībā izstrādātu, notestētu un dokumentētu sistēmas daļu. Posma ietvaros veicamie darbi tiek ņemti no IS programmatūras izstrādes un ieviešanas iterāciju plāna, bet precizēti vai papildināti Iterācijas plānošanas laikā pirms tās uzsākšanas.
2.6. Puses saskaņo darba uzdevumus (iterācijas backlog) katra IS iterācijas nodevuma izstrādei, (turpmāk tekstā – Darba uzdevums) tieši pirms kārtējā posma uzsākšanas. Darba uzdevums var atšķirties no IS programmatūras izstrādes un ieviešanas iterāciju plāna, ja par to vienojas Izpildītāja un Pasūtītāja pārstāvji. Darba uzdevums tiek noformēts rakstiski tabulas veidā un to paraksta abu Pušu pilnvarotie projekta vadītāji. Pēc katra nodevuma Darba uzdevuma saskaņošanas, Izpildītājs, ņemot vērā noteiktos nodevuma akceptēšanas kritērijus, sagatavo un saskaņo ar Pasūtītāju nodevumu akcepttestēšanas kritērijus un pievieno tos Darba uzdevumam.
2.7. Darba uzdevumā tiek norādīta šāda informācija:
2.7.1. veicamo darbu apraksts, tai skaitā (ja piemērojams), izmaiņu pieprasījumi, izmaiņu pieprasījumu apjoms cilvēkstundās;
2.7.2. nodevuma akceptēšanas kritēriji.
2.8. Ja iterācijas izpildes laikā tiek konstatēta nepieciešamība veikt izmaiņas iepriekšējos nodevumos, Puses rakstiski saskaņo veicamās izmaiņas un pievieno tās iterācijas Darba uzdevumam.
2.9. Pirms iterācijas nodevuma iesniegšanas Pasūtītājam Izpildītājs veic šī nodevuma testēšanu.
2.10. Pēc Pasūtītāja pieprasījuma, Izstrādātājs uzstāda piegādātos darba uzdevumus Pasūtītāja produkcijas vidē.
2.11. Pēc katra Darba uzdevuma izpildes un nodevuma iesniegšanas, Pasūtītājs pārbauda Izpildītāja sagatavotos Darba uzdevuma izpildes nodevumus 10 (desmit) kalendāro dienu laikā pēc Xxxxx uzdevuma nodošanas. Pasūtītājam ir tiesības Darba uzdevuma izpildes nodevumu pārbaudē piesaistīt trešās personas - neatkarīgus ekspertus. Ja 10 (desmit) kalendāro dienu laikā pēc Darba uzdevuma izpildes un Darba uzdevuma izpildes pieņemšanas - nodošanas akta saņemšanas Pasūtītājs nav Izpildītājam iesniedzis parakstītu Darba uzdevuma izpildes pieņemšanas - nodošanas aktu vai nav sniedzis pamatotu rakstisku atteikumu, tiek uzskatīts, ka Pasūtītājs nodevumu ir pieņēmis.
2.12. Ja Pasūtītājs ir sniedzis atteikumu apstiprināt Darba uzdevuma izpildes pieņemšanas - nodošanas aktu, Darba uzdevuma izpilde tiek pievienota citas iterācijas Darba uzdevumam.
2.13. Pēc IS izstrādes un ieviešanas (pēdējā nodevuma izstrādes) Pasūtītājs veic IS pārbaudi ekspluatācijas vidē. IS pārbaude ekspluatācijas vidē tiek veikta 40 (četrdesmit) kalendāro dienu laikā. Pārbaudes laikā Pasūtītājs reģistrē radušās problēmas. IS pārbaudes ekspluatācijas vidē laikā Pasūtītājam ir tiesības piesaistīt trešās personas - neatkarīgus ekspertus, kā arī veikt sistēmas drošības pārbaudes pasākumus, par tiem sagatavojot atsevišķu novērtējumu.
2.14. Ja IS pārbaudes ekspluatācijas vidē laikā tiek reģistrētas 1. un 2. kategorijas problēmas, kā arī drošības ievainojamības, Izpildītājs novērš konstatētās IS kļūdas 20 (divdesmit)
kalendāro dienu laikā (vai citā termiņā pēc Pušu savstarpējas vienošanās) pēc IS pārbaudes ekspluatācijas vidē.
2.15. Pēc IS pārbaudes ekspluatācijas vidē reģistrēto 1. un 2. kategorijas problēmu un drošības ievainojamību novēršanas, Pasūtītājs 10 (desmit) kalendāro dienu laikā veic IS gala akcepttestēšanu. IS gala akcepttestēšanas laikā Pasūtītājam ir tiesības piesaistīt trešās personas - neatkarīgus ekspertus, kā arī veikt sistēmas drošības pārbaudes pasākumus, par tiem sagatavojot atsevišķu novērtējumu.
2.16. Ja pēc IS gala akcepttestēšanas Pasūtītājs konstatē neatbilstību akcepttestēšanas kritērijiem, Izpildītājs novērš konstatētās IS kļūdas un nepilnības 15 (piecpadsmit) kalendāro dienu laikā (vai citā termiņā pēc Pušu savstarpējas vienošanās).
2.17. Pēc IS gala akcepttestēšanas un gala akcepttestēšanas laikā konstatēto kļūdu un nepilnību novēršanas, Izpildītājs sagatavo un iesniedz Pasūtītājam IS izstrādes un ieviešanas pieņemšanas-nodošanas aktu. Ja 5 (piecu) kalendāro dienu laikā pēc IS izstrādes un ieviešanas pieņemšanas-nodošanas akta saņemšanas Pasūtītājs nav Izpildītājam iesniedzis parakstītu IS izstrādes un ieviešanas pieņemšanas-nodošanas aktu vai nav sniedzis pamatotu rakstisku atteikumu, tiek uzskatīts, ka Pasūtītājs ir pieņēmis IS izstrādi un ieviešanu.
2.18. Ja vienas Puses būtisks saistību izpildes nokavējums liedz otrai Pusei veikt savlaicīgu saistību izpildi, tad otras Puses saistību izpildes termiņš tiek pagarināts par pirmās Puses nokavēto laika posmu. Pusei, kura prasa, lai minēto apstākļu dēļ tiktu pagarināts saistību izpildes termiņš, ir pienākums pierādīt otras Puses saistību izpildes nokavējuma faktu.
2.19. Ja Izpildītājam Līguma izpildei ir nepieciešams veikt izmaiņas informācijas sistēmās, kurām garantiju vai uzturēšanu nodrošina trešās puses, Izpildītājs kopīgi ar Pasūtītāju veic izmaiņu saskaņošanu ar attiecīgo informācijas sistēmas garantijas nodrošinātāju vai uzturētāju.
2.20. Izpildītājs izstrādā un ievieš informācijas sistēmas pilnā apmērā, saskaņā ar Tehniskajā specifikācijā (Pielikums Nr.1) un Tehniskajā piedāvājumā (Pielikums Nr.2) norādīto aprakstu Līguma 4.1.punktā noteiktās līgumcenas ietvaros.
3. LĪGUMA IZPILDĒ IESAISTĪTAIS PERSONĀLS
3.1. Par Līguma izpildē iesaistīto personālu uzskatāms Pretendenta piedāvājumā atklātam konkursam „ Sabiedriskā transporta kustības maršrutu attēlošanas ģeotelpiskās informācijas sistēmas izstrāde un uzturēšana” (iepirkuma identifikācijas nr. AD 2016/4) norādītais personāls.
3.2. Ja nepieciešams, Izpildītājs ir tiesīgs papildus piedāvājumā norādītajam personālam, piesaistīt citus speciālistus bez saskaņošanas ar Pasūtītāju.
3.3. Bez rakstiskas Pasūtītāja piekrišanas, Izpildītājs nedrīkst aizstāt piedāvājumā norādīto personālu ar citu.
3.4. Ja Pasūtītājs ir piekritis piedāvājuma norādītā personāla nomaiņai, tad jaunā speciālista kvalifikācijai un pieredzei ir jābūt līdzvērtīgai ar aizstājamā speciālista kvalifikāciju un pieredzi, kā arī, ir jāatbilst atklāta konkursa „Sabiedriskā transporta kustības maršrutu attēlošanas ģeotelpiskās informācijas sistēmas izstrāde un uzturēšana” (iepirkuma identifikācijas Nr. AD 2016/_) kandidātu atlases nolikumā noteiktajām attiecīgā speciālista kvalifikācijas prasībām.
4. LĪGUMCENA UN TĀS APMAKSAS KĀRTĪBA
4.1. Līgumcena bez pievienotās vērtības nodokļa (PVN) ir EUR ( lati). Līgumcena ar PVN ir EUR ( ), tai skaitā PVN atbilstoši
Latvijas Republikā noteiktajai PVN likmei EUR, ( ) (Pielikums Nr.3).
4.2. Ja realizējot kārtējo iterāciju ir radusies nepieciešamība labot iepriekšējās iterācijas laikā izstrādātos nodevumus, Izpildītājs izmaiņas veic bez papildu samaksas. Šādu izmaiņu veikšana nodevumos nav uzskatāma par izmaiņu pieprasījumu.
4.3. Samaksu 40% (četrdesmit procentu) apmērā no attiecīgā nodevuma cenas Pasūtītājs veic 10 (desmit) dienu laikā pēc katra iterācijas nodevuma (izņemot pēdējo informācijas sistēmas izstrādes un ieviešanas nodevumu) akceptēšanas un pieņemšanas – nodošanas akta parakstīšanas un rēķina iesniegšanas dienas.
4.4. Samaksu 60% (sešdesmit procentu) apmērā no iepriekšējās iterācijās akceptēto nodevumu kopējās cenas un samaksu 100% (viens simts procentu) apmērā no pēdējā IS izstrādes un ieviešanas iterācijas nodevuma cenas Pasūtītājs veic 10 (desmit) dienu laikā pēc IS gala akcepttestēšanas, akcepttestēšanas laikā konstatēto kļūdu novēršanas un IS izstrādes un ieviešanas pieņemšanas – nodošanas akta parakstīšanas un rēķina iesniegšanas dienas.
5. PUŠU TIESĪBAS UN PIENĀKUMI
5.1. Pasūtītāja tiesības un pienākumi:
5.1.1. kontrolēt Pakalpojumu izpildi un dot norādījumus Izpildītājam saistībā ar Līguma izpildi.
5.1.2. sniegt Izpildītājam visu tā rīcībā esošo informāciju, kas Izpildītājam nepieciešama Līguma izpildei;
5.1.3. veikt norēķinus ar Izpildītāju par kvalitatīvi un atbilstoši Līguma noteikumiem sniegtajiem Pakalpojumiem.
5.2. Izpildītāja tiesības un pienākumi:
5.2.1. nodot nodevumus, atbilstoši „Tehniskajam piedāvājumam” (Pielikums Nr.2) un atbilstoši Līguma 2.4. punktā definētajiem nosacījumiem.
5.2.2. bez maksas novērst visas kļūdas un trūkumus, kas tiks atklāti, veicot nodevumu pārbaudi, pārbaudi ekspluatācijas vidē un gala akcepttestēšanu, saskaņā ar Līguma noteikumiem;
5.2.3. bez maksas nodrošināt informācijas sistēmas garantiju un Izpildītāja pieļauto kļūdu labošanu informācijas sistēmā un dokumentācijā, un konsultācijas un papildus izmaiņu pieprasījumus stundas gadā 2 (divu) gadu laikā no informācijas sistēmas izstrādes un ieviešanas pieņemšanas – nodošanas akta parakstīšanas dienas, saskaņā ar Līguma noteikumiem.
5.2.4. sniegt Pakalpojumus kvalitatīvi un atbilstoši Līguma noteikumiem;
5.2.5. nesniegt publiskos paziņojumus, kas saistīti ar Līgumu un tā pielikumiem, bez iepriekšējas rakstiskas saskaņošanas ar Pasūtītāju.
6. LĪGUMA PĀRVALDĪBA UN ATBILDĪGĀS PERSONAS
6.1. Līguma izpildei Pasūtītājs pilnvaro projekta vadītāju , tālr.: , e-pasts: .
6.2. Līguma izpildei Izpildītājs pilnvaro projekta vadītāju ,
tālr.: , e-pasts: .
6.3. Pasūtītāja un Izpildītāja projekta vadītāju pienākums ir vadīt un sekot Līguma izpildei un informēt par tā izpildi gan savu, gan arī otru Pusi. Pasūtītāja un Izpildītāja projekta vadītājiem ir tiesības apstiprināt Darba uzdevumus, kā arī parakstīt nodevumu pieņemšanas – nodošanas aktus. Projekta vadītāja nomaiņas gadījumā otra Puse tiek nekavējoties par to informēta.
6.4. Līguma izpildes ietvaros Pasūtītājs un Izpildītājs kopīgi izveido projekta vadības struktūras.
7. NEPĀRVARAMA VARA
7.1. Xxxxxxx Xxxx nav atbildīga par savu saistību daļēju vai pilnīgu neizpildi, ja tas ir rezultāts tādiem notikumiem, kā valdības lēmumi, kas tieši ietekmē Līguma izpildi, plūdi, ugunsgrēks, streiki u.c., kas notikuši pēc Līguma slēgšanas un iestājušies no Pusēm neatkarīgu iemeslu dēļ.
7.2. Puse, kuras saistību izpilde kļūst neiespējama, nekavējoties brīdina otru Pusi personīgi, telefoniski vai rakstiskā veidā par augstāk minēto apstākļu iestāšanos, prognozējamo ilgumu un vienojas par tālāko sadarbības veidu.
7.3. Ja nepārvaramās varas notikums ilgst ilgāk nekā trīs mēnešus, jebkura Puse drīkst izbeigt Līguma izpildi par to paziņojot otrai Pusei rakstiskā veidā.
8. PUŠU ATBILDĪBA
8.1. Puses apņemas 3 (trīs) dienu laikā rakstiski ziņot viena otrai par jebkuru apstākli, kas negatīvi ietekmē vai var ietekmēt Līguma izpildi;
8.2. Pasūtītājs ir atbildīgs par Līguma izpildes ietvaros tam piegādātās informācijas sistēmas pareizu ekspluatāciju un uzturēšanu lietošanas kārtībā. Pasūtītājs veic regulāru informācijas sistēmas un tās datu rezerves kopēšanu apjomā, kas atbilst Izpildītāja iesniegtajai rezerves kopiju veidošanas dokumentācijai.
8.3. Izpildītājs ir atbildīgs par Pasūtītājam nodarītajiem tiešajiem zaudējumiem, ja tie radušies Izpildītāja rupjas neuzmanības vai ļauna nolūka dēļ.
8.5. Ja Izpildītājs pārkāpj Darba uzdevumā noteikto Pakalpojumu sniegšanas termiņu, Pasūtītājs ir tiesīgs pieprasīt līgumsodu 0,1% (viena desmitā daļa procenta) apmērā no kavētā nodevuma cenas par katru kavējuma darba dienu. Kopējais līgumsods nedrīkst pārsniegt 10% (desmit procentu) no 4.1.punktā minētās līgumcenas. Šajā Līguma punktā noteiktais līgumsods nav attiecināms uz Sistēmas izstrādes un ieviešanas pēdējo nodevumu. Sistēmas izstrādes un ieviešanas pēdējā nodevuma kavējums tiek uzskatīts par visas sistēmas izstrādes un ieviešanas kavējumu, kam tiek piemērota Līguma 8.4.punktā noteiktā sankcija.
8.6. Ja Pasūtītājs kavē Līguma 4.punktā norādīto maksājuma termiņu, Izpildītājs ir tiesīgs pieprasīt līgumsodu 0,1% (viena desmitā daļa procenta) apmērā no laikā nesamaksātās summas par katru nokavēto dienu. Kopējais līgumsods nedrīkst pārsniegt 10% (desmit procentu) no 4.1.punktā minētās līgumcenas.
8.7. Ja Izpildītājs garantijas termiņa laikā nenovērš vai neatrisina pieteikto 1.kategorijas
problēmu līdz 2.kategorijas problēmas līmenim 48h (četrdesmit astoņu stundu) laikā (vai citā termiņā, par kuru Puses ir vienojušās) no problēmas pieteikšanas brīža, Pasūtītājs ir tiesīgs pieprasīt līgumsodu 30 EUR (trīsdesmit euro) apmērā par katru nokavēto stundu.
8.8. Ja Izpildītājs garantijas termiņa laikā nenovērš vai neatrisina pieteikto 2.kategorijas problēmu līdz 3.kategorijas problēmas līmenim 72h (septiņdesmit divu stundu) laikā (vai citā termiņā, par kuru Puses ir vienojušās) no problēmas pieteikšanas brīža, Pasūtītājs ir tiesīgs pieprasīt līgumsodu 15 EUR (piecpadsmit euro) apmērā par katru nokavēto stundu.
8.9. Ja Izpildītājs nenovērš garantijas termiņa laikā pieteiktās problēmas līdz garantijas termiņa beigām, izņemot garantijas perioda pēdējā mēneša laikā pieteiktās problēmas, Pasūtītājs ir tiesīgs pieprasīt līgumsodu 70 EUR (septiņdesmit euro) apmērā par katru nokavēto darba dienu.
8.10. Ja Izpildītājs nenovērš garantijas perioda pēdējā mēneša laikā pieteiktās problēmas 1 mēneša laikā pēc problēmas pieteikšanas, Pasūtītājs ir tiesīgs pieprasīt līgumsodu 70 EUR (septiņdesmit euro) apmērā par katru nokavēto dienu.
8.11. Izpildītājs tiek atbrīvots no Līgumā noteiktajām informācijas sistēmas garantijas saistībām uz tiem informācijas sistēmas apgabaliem, kuros Pasūtītājs vai cita trešā persona Pasūtītāja uzdevumā ir veikusi izmaiņas vai labojumus, kas nav iepriekš saskaņoti ar Izpildītāju.
8.12. Līgumsoda apmaksa neatbrīvo Puses no saistību izpildes.
9. AUTORTIESĪBAS
9.2. Pasūtītājs saņem tiesības uz visiem grafiskajiem un/vai tekstuālajiem, un/vai audiovizuālajiem (ar vai bez skaņas pavadījuma) autortiesību objektiem, jebkādā fiksācijas veidā.
9.3. Saskaņā ar Līguma 9.1. punktu Pasūtītājs saņem autora mantiskās tiesības uz neierobežotu laiku un var tās izlietot atbilstoši saviem ieskatiem.
9.4. Pasūtītājs apliecina, ka nekādas autora mantiskās tiesības uz informācijas sistēmu, kuras Līguma ietvaros ir jāpārveido vai jālabo, nepieder Līgumā neiesaistītām trešajām personām, tādēļ izmaiņu veikšana šajās informācijas sistēmas nevar tikt uzskatīta par trešajām personām piederošu autora tiesību aizskārumu.
10. INFORMĀCIJAS AIZSARDZĪBA
10.1. Puses apņemas ievērot no otras Puses saņemtās un Līguma saistību izpildes gaitā iegūtās informācijas konfidencialitāti, neizpaust šādu informāciju trešajām personām, izņemot tiesību aktos noteiktajos gadījumos un kārtībā. Konfidencialitātes noteikumi attiecas kā uz rakstisku informāciju, tā arī uz mutiski sniegtu informāciju, elektronisku informāciju un uz jebkuru citu informāciju, kura nonāk Pušu rīcībā, izpildot šī Līguma saistības.
10.2. Izpildītājs pēc Līguma izpildes atgriež Pasūtītājam visus Līguma izpildē no Pasūtītāja saņemtos dokumentētos materiālus un elektroniskos datu nesējus.
10.3. Pusēm ir tiesības izpaust konfidenciālu informāciju jebkurai trešajai personai tikai pēc otras Puses rakstveida piekrišanas saņemšanas, izņemot normatīvajos aktos noteiktajos gadījumos un kārtībā.
10.4. Par konfidenciālu informāciju netiek uzskatīta informācija, ja tā:
10.4.1. bija saņemšanas laikā publicēta vai citādi padarīta vispārpieejama;
10.4.2. pēc tam, kad Puse to saņēmusi, ir tikusi publicēta vai kļuvusi vispārēji publiski pieejama citādā veidā nekā ar jebkādu to saņēmušās Puses veiktu darbību vai nodošanu;
10.4.3. saņemšanas laikā bija jau zināma Pusei, kura to saņēmusi, bez jebkādiem ierobežojumiem, attiecībā uz to atklāšanu;
10.4.4. bija pilntiesīgi saņemta no trešās personas bez jebkādas to atklājušās Puses pieprasītās konfidencialitātes uzņemšanās;
10.5. Konfidencialitātes saistībai ir beztermiņa raksturs.
10.6. Ja Izpildītājs izpaudis trešajām personām, vai izmantojis Pakalpojuma sniegšanas gaitā saņemto informāciju darbībām, ko neparedz Līgums, Izpildītājs maksā līgumsodu pasūtītājam EUR 15 000 (piecpadsmit) apmērā un kompensē Pasūtītājam radītos tiešos zaudējumus.
11. CITI NOTEIKUMI
11.1. Ja Pasūtītājam Līguma darbības laikā rodas nepieciešamība pēc papildus funkcionalitātes, tad Puses vienojas par izmaiņu pieprasījumu. Izmaiņu pieprasījums tiek apmierināts Izpildītāja piedāvāto uzturēšanas stundu ietvaros. Ja līguma darbības laikā visas Izpildītāja piedāvātas uzturēšanas stundas ir izlietotas, Puses vienojas par izmaiņu pieprasījuma apmierināšanu, slēdzot atsevišķo vienošanos.
11.2. Visus strīdus un domstarpības, kas radušies Līguma darbības laikā, Puses risina savstarpējā pārrunu ceļā.
11.3. Strīdi un domstarpības, kuras nav izdevies atrisināt pārrunu ceļā, tiek izskatīti tiesā Latvijas Republikas normatīvajos aktos paredzētajā kārtībā.
11.4. Pasūtītājam ir tiesības vienpusēji pārtraukt Līgumu, ja:
11.4.1. Izpildītājs ir kavējis nodevuma iesniegšanas termiņu vai nodevuma izpildes trūkumu novēršanas termiņu ilgāk par 60 (sešdesmit) dienām. Šādā gadījumā:
11.4.1.1. visi Pasūtītājam iesniegtie un pieņemtie nodevumi un visi Pasūtītājam iesniegtie, bet nepieņemtie nodevumi, paliek Pasūtītāja īpašumā un uz tiem ir attiecināmi Līguma 9.punkta noteikumi;
11.4.1.2. līgumsodi Izpildītājam tiek aprēķināti līdz paziņojuma par Līguma laušanu nosūtīšanas dienai.
11.4.2. Izpildītājam ir tiesības vienpusēji pārtraukt Līgumu, ja Pasūtītājs neveic samaksu par izpildītu un pieņemtu nodevumu ilgāk kā par 60 (sešdesmit) dienām. Šādā gadījumā:
11.4.2.1. visi Pasūtītājam iesniegtie, pieņemtie un apmaksātie nodevumi, paliek Pasūtītāja īpašumā un uz tiem ir attiecināmi Līguma 9.punkta noteikumi;
11.4.2.2. līgumsodi Pasūtītājam tiek aprēķināti līdz paziņojuma par Līguma laušanu nosūtīšanas dienai.
11.5. Visi Līguma pielikumi ir noformējami rakstiskā formā un tos jāparaksta abām Pusēm. Visi Līguma pielikumi ir Līguma neatņemamas sastāvdaļas.
11.6. Līgums ir sastādīts latviešu valodā uz lapām, ar 4 (četriem) pielikumiem uz
lapām divos eksemplāros ar vienādu juridisko spēku, no kuriem viens atrodas pie Pasūtītāja, otrs pie Izpildītāja .
11.7. Līgumam ir 5 (pieci) pielikumi, kas ir tā neatņemama sastāvdaļa:
1. pielikums – Tehniskā specifikācija
2. pielikums – Tehniskais piedāvājums
3. pielikums – Finanšu piedāvājums
4. pielikums – Ieviešanas iterāciju plāns
5. pielikums - Garantijas risinājuma procedūra
12. PUŠU REKVIZĪTI UN PARAKSTI
informācijas sistēmas izstrāde un uzturēšana”, Iepirkuma identifikācijas Nr. AD 2016/5
nolikumam
Finanšu piedāvājuma forma
Finanšu piedāvājums jāaizpilda, izmantojot šādu formu:
Nr. | Pakalpojuma nosaukums | Izmaksu vienību skaits | Vienas vienības cena EUR, bez PVN | Summa EUR, bez PVN |
1. | Programmatūras izstrāde | |||
2. | Licences (ja paredzētas, jāuzrāda katras licences izmaksas) | |||
Līgumcena EUR, bez PVN: |
Datums:
Pretendenta paraksts
/Vārds, uzvārds
Pielikums Nr.5. – Pretendenta pieredzes apliecinājuma forma
Atklāta konkursa „ Sabiedriskā transporta kustības maršrutu attēlošanas ģeotelpiskās
informācijas sistēmas izstrāde un uzturēšana”, Iepirkuma identifikācijas Nr. AD 2016/5
nolikumam
Pretendenta pieredzes apliecinājuma forma
Nr. | Projekta nosaukums un īss apraksts (būtiskākā funkcionalitāte, izmantotās tehnoloģijas) | Pasūtītājs un tā pārstāvja kontaktinformā cija (vārds, uzvārds, amats, telefons, e- pasts) | Projekta realizācijas laiks (gads, mēnesis, no – līdz) | Projekta apjoms (EUR, bez PVN) | Pretendenta statuss projektā (virsuzņēmējs vai apakšuzņēmējs) un pretendenta izpildīto darbu apjoms (%)3 |
1 | |||||
2 | |||||
3 | |||||
4 | |||||
5 | |||||
6 |
Datums:
Pretendenta paraksts
/Vārds, uzvārds/
3 Ja Pretendents projektā ir bijis apakšuzņēmējs, papildus ir jānorāda virsuzņēmēja nosaukums.