NOLIKUMS

APSTIPRINĀTS:

Iepirkuma komisijas sēdē

2014.gada.3.novembrī

protokols Nr. VAMOIC 2014/171-03


ATKLĀTA KONKURSA

„Tehniskā risinājuma prototipa izstrāde AnNa (VILDA) projekta ietvaros”

(identifikācijas Nr. VAMOIC 2014/171)

NOLIKUMS


  1. PASŪTĪTĀJS, KONKURSA RĪKOTĀJS UN KONKURSA PRETENDENTI

    1. Atklāta konkursa „Tehniskā risinājuma prototipa izstrāde AnNa (VILDA) projekta ietvaros” (identifikācijas Nr. VAMOIC 2014/171), pasūtītājs: Latvijas Republikas (LR) Nacionālo bruņoto spēku Nodrošinājuma pavēlniecības 1.Reģionālais nodrošinājuma centrs, kas atrodas Xxxx xxxx 0, Xxxxxxx, XX-0000.

    2. Konkursa rīkotājs: Valsts aizsardzības militāro objektu un iepirkumu centrs (turpmāk tekstā – Centrs), kas atrodas Xxxxxxxxxx xxxx 00, Xxxx, XX-0000.

    3. Finansējuma avots – valsts budžets un Eiropas Savienības līdzfinansējums projekta „XXXX-Xxxxxxxxx valstu pārvaldes iestāžu tīkli” Nr.2012-EU-21019-S ietvaros.

    4. Organizatoriska rakstura informāciju par Konkursu sniedz: Centra Juridiskā un iepirkumu nodrošinājuma departamenta Preču un pakalpojumu līgumu un iepirkumu nodaļas pārvaldes vecākā referente Xxxxx Xxxxx, e‑pasts: xxxxx.xxxxx@xxxxxx.xxx.xx, tālrunis: 67300272; fakss: 67300207.

    5. Pretendents – piegādātājs, kas ir iesniedzis piedāvājumu.

    6. Piegādātāju apvienība – fizisko vai juridisko personu apvienība jebkurā to kombinācijā.

    7. Pretendentam līguma izpildei ir tiesības piesaistīt apakšuzņēmējus vai balstīties uz citu personu iespējām, lai apliecinātu, ka tā kvalifikācija atbilst paziņojumā par līgumu vai iepirkuma procedūras dokumentos noteiktajām prasībām, vai ja tas nepieciešams konkrētā līguma izpildei.

  2. IEPIRKUMA PRIEKŠMETS, PLĀNOTIE APJOMI UN iepirkuma izpildes noteikumi

    1. Iepirkuma priekšmets ir tehniskā risinājuma prototipa izstrāde AnNa (VILDA) projekta ietvaros (turpmāk – Prece) saskaņā ar tehniskajām specifikācijām (pielikums Nr.3).

    2. Iepirkuma priekšmeta daļas:

      1. I daļa – Prototipa izstrāde "Automātiska, vienota datu apmaiņas saslēguma izstrādei starp ES dalībvalstīm ostas formalitāšu un kuģošanas drošības datu apmaiņai”;

      2. II daļa – Datu pārraides tīkla modeļa prototipa izveide Rīgas jūras līcī (I-CaDE);

      3. III daļa - Automatizētā risinājuma izstrāde, kuģošanas informācijas un ostu formalitāšu datu atpazīšanai;

      4. IV daļa –Kuģošanas informācijas un ostu formalitāšu datu konvertēšanas un apmaiņas moduļa izstrāde.

    3. Piedāvājumu var iesniegt par katru iepirkuma priekšmeta daļu atsevišķi, bet par pilnu iepirkuma priekšmeta daļas apjomu.

    4. Pretendents katrā iepirkuma priekšmeta daļā var iesniegt tikai vienu piedāvājuma variantu.

    5. Preces izstrādes nosacījumi un termiņi: saskaņā ar tehniskās specifikācijas prasībām.

    6. Līguma darbības termiņš: līdz pušu saistību pilnīgai izpildei, bet ne ilgāk kā tas noteikts Publisko iepirkumu likumā.

    7. Apmaksas noteikumi: saskaņā ar līguma projekta noteikumiem (pielikums Nr.5):

      1. iespējama priekšapmaksa līdz 50% no līguma summas 10 (desmit) darba dienu laikā pēc Līguma spēkā stāšanās dienas un rēķina saņemšanas dienas;

      2. Pēc priekšapmaksas Bankas garantijas dzēšanas, par katru nodevumu veic samaksu 30 (trīsdesmit) kalendāro dienu laikā pēc nodevuma pieņemšanas-nodošanas akta abpusējas parakstīšanas dienas un rēķina saņemšanas dienas.

    8. Līguma slēgšanas tiesības tiks piešķirtas pretendentam, kurš ir iesniedzis nolikuma prasībām atbilstošu saimnieciski visizdevīgāko piedāvājumu.

  3. PRASĪBAS PRETENDENTIEM

    1. Pretendents vai persona, kura ir pretendenta valdes vai padomes loceklis vai prokūrists, vai persona, kura ir pilnvarota pārstāvēt pretendentu darbībās, kas saistītas ar filiāli, ar tādu prokurora priekšrakstu par sodu vai tiesas spriedumu, kas stājies spēkā un kļuvis neapstrīdams un nepārsūdzams pēdējo trīs gadu laikā no piedāvājumu iesniegšanas dienas, nav atzīta par vainīgu jebkurā no šādiem noziedzīgiem nodarījumiem:

      1. kukuļņemšana, kukuļdošana, kukuļa piesavināšanās, starpniecība kukuļošanā, neatļauta labumu pieņemšana vai komerciāla uzpirkšana,

      2. krāpšana, piesavināšanās vai noziedzīgi iegūtu līdzekļu legalizēšana,

      3. izvairīšanās no nodokļu un tiem pielīdzināto maksājumu nomaksas,

      4. terorisms, terorisma finansēšana, aicinājums uz terorismu, terorisma draudi vai personas vervēšana un apmācīšana terora aktu veikšanai.

    2. Pretendents ar tādu kompetentas institūcijas lēmumu vai tiesas spriedumu, kas stājies spēkā un kļuvis neapstrīdams un nepārsūdzams pēdējo trīs gadu laikā no piedāvājumu iesniegšanas dienas, nav atzīts par vainīgu pārkāpumā, kas izpaužas kā viena vai vairāku tādu valstu pilsoņu vai pavalstnieku nodarbināšana, kuri nav Eiropas Savienības dalībvalstu pilsoņi vai pavalstnieki, ja tie Eiropas Savienības dalībvalstu teritorijā uzturas nelikumīgi.

    3. Pretendents ar tādu kompetentas institūcijas lēmumu vai tiesas spriedumu, kas stājies spēkā un kļuvis neapstrīdams un nepārsūdzams pēdējo 12 mēnešu laikā no piedāvājumu iesniegšanas dienas, nav atzīts par vainīgu pārkāpumā, kas izpaužas kā personas nodarbināšana bez rakstveidā noslēgta darba līguma, nodokļu normatīvajos aktos noteiktajā termiņā neiesniedzot par šo personu informatīvo deklarāciju par darba ņēmējiem, kas iesniedzama par personām, kuras uzsāk darbu.**

    4. Pretendents ar tādu kompetentas institūcijas lēmumu vai tiesas spriedumu, kas stājies spēkā un kļuvis neapstrīdams un nepārsūdzams pēdējo 12 mēnešu laikā no piedāvājumu iesniegšanas dienas, nav atzīts par vainīgu konkurences tiesību pārkāpumā, kas izpaužas kā vertikālā vienošanās, kuras mērķis ir ierobežot pircēja iespēju noteikt tālākpārdošanas cenu, vai horizontālā karteļa vienošanās, izņemot gadījumu, kad attiecīgā institūcija, konstatējot konkurences tiesību pārkāpumu, par sadarbību iecietības programmas ietvaros kandidātu vai pretendentu ir atbrīvojusi no naudas soda vai naudas sodu samazinājusi.**

    5. Nav pasludināts pretendenta maksātnespējas process, nav apturēta vai pārtraukta pretendenta saimnieciskā darbība, nav uzsākta tiesvedība par pretendenta bankrotu vai pretendents netiek likvidēts. **

    6. Pretendentam Latvijā vai valstī, kurā tas reģistrēts vai kurā atrodas tā pastāvīgā dzīvesvieta, nav nodokļu parādu, tajā skaitā valsts sociālās apdrošināšanas obligāto iemaksu parādu, kas kopsummā kādā no valstīm pārsniedz 150 euro. **

  4. KVALIFIKĀCIJAS PRASĪBAS PRETENDENTIEM


N.p.k.

I daļa – Prototipa izstrāde "Automātiskai, vienotai datu apmaiņas saslēguma izstrādei starp ES dalībvalstīm ostas formalitāšu un kuģošanas drošības datu apmaiņai”

II daļa – Datu pārraides tīkla modeļa prototipa izveide Rīgas jūras līcī (I-CaDE)

III daļa – Automatizētā risinājuma izstrāde, kuģošanas informācijas un ostu formalitāšu datu atpazīšanai

IV daļa -Kuģošanas informācijas un ostu formalitāšu datu konvertēšanas un apmaiņas moduļa izstrāde

4.1.

Pretendents ir reģistrēts likumā noteiktajos gadījumos un likumā noteiktajā kārtībā.

4.2.

Pretendentam kādā no Eiropas Savienības vai Eiropas Ekonomiskās Zonas valstīm ir šāda pieredze (vienā vai vairākos projektos):

4.2.1.

Pretendentam pēdējo trīs gadu laikā ir jābūt realizējušam projektus, kas sevī ietver:


4.2.1.1. vismaz vienu līdzīga apjoma un satura programmatūras izstrādes projektu. Par līdzīga apjoma un satura projektiem šīs prasības izpratnē tiks uzskatīti tādi projekti, kas ietver universāla datu apmaiņas risinājuma izstrādi, kurš nodrošina informācijas apmaiņu starp nenoteiktu datu apmaiņas risinājumam pieslēgtu klientu skaitu, ziņojumu adresācijai izmantojot ziņojuma metadatus, nodrošina pierādījumus par ziņojumu nodošanu un garantētu ziņojumu piegādi;


4.2.1.2. tehnoloģiska risinājuma prototipa, kurš izmantots (izvērsts) kā strādājošs projekts, izstrādē vai vairākkārt izmantojama un pielāgojama risinājuma (produkta) izstrādē;


4.2.1.3. vismaz vienas jūras satiksmes formalitāšu nodrošinājuma sistēmas izstrādē, kuras izstrādes cena nav mazāka par 150`000 Euro un, kura nodrošina pārvadājumu formalitāšu apstrādi un ir pieejama lietošanai kā no datora, tā no mobilajām iekārtām;


4.2.1.4. vismaz divu vienas pieturas aģentūras principa risinājumu izstrādē, kur, izmantojot vienotu programmatūras saskarni (API) un lietotāja saskarni (GUI) tiek nodrošināta pieeja vairāku (vismaz četru) iekšējo (BackOffice) informācijas sistēmu nodrošinātajiem servisiem;


4.2.1.5. vismaz viena projekta, kurā vienlaicīgi izmantoti xml un EDIFACT standarti, realizācijā;

Pretendentam pēdējo trīs gadu laikā ir jābūt realizējušam projektus, kas sevī ietver:


4.2.1.1. vismaz vienu sakaru sistēmas pētniecības projektu par bezvadu datu pārraidi no vai/un uz starptautiskajā jūras satiksmē iesaistītiem kuģiem, un kur pētniecības projekta summa nav mazāka par 150 000 EUR (divi simti tūkstoši eiro);



4.2.1.2. vismaz viena prototipa izstrādi, kas paredz starptautiskā kuģošanā iesaistīto kuģu atpazīšanas datu pārraidi vai apmaiņu. Prototipa izstrādes pieredze ietver konceptuālā risinājuma izstrādi un sistēmas izstrādi, kā arī tehniskās dokumentācijas izstrādi;

Pretendentam pēdējo trīs gadu laikā ir jābūt realizējušam projektus, kas sevī ietver:


4.2.1.1. tehnoloģiska risinājuma prototipa, kurš izmantots (izvērsts) kā strādājošs projekts, izstrādi vai vairākkārt izmantojama un pielāgojama risinājuma (produkta) izstrādi;


4.2.1.2. vismaz viena datu izgūšanas, transformēšanas un analīzes risinājuma izstrādē;


4.2.1.3. vismaz vienas jūras satiksmes formalitāšu nodrošinājuma sistēmas izstrādē, kuras izstrādes cena nav mazāka par 150`000 Euro un kura nodrošina pārvadājumu formalitāšu apstrādi un ir pieejama lietošanai kā no datora, tā no mobilajām iekārtām;


4.2.1.4. vismaz viena projekā, kurā vienlaicīgi izmantoti xml un EDIFACT standarti, realizācijā;

Pretendentam pēdējo trīs gadu laikā ir jābūt realizējušam projektus, kas sevī ietver:


4.2.1.1. vismaz vienu atvērtu dokumentu apmaiņas risinājumu (tāda risinājumu, kuram, ievērojot tehniskos noteikumus apmaiņas formātu un noslēdzot atbilstošu līgumu, var pieslēgties jebkurš lietotājs), kura izstrādes līgumcena nav mazāka par 150`000 EUR biznesa procesu analīzē, tehnisko specifikāciju izstrādē un realizācijā;


4.2.1.2. universāla datu apmaiņas risinājuma izstrādē, kurš nodrošina informācijas apmaiņu starp nenoteiktu datu apmaiņas risinājumam pieslēgtu klientu skaitu, ziņojumu adresācijai izmantojot ziņojuma metadatus, nodrošina pierādījumus par ziņojumu nodošanu un garantētu ziņojumu piegādi;


4.2.1.3. universāla datu apmaiņas risinājuma izstrādē, kurš nodrošina informācijas apmaiņu starp nenoteiktu datu apmaiņas risinājumam pieslēgtu klientu skaitu, ziņojumu adresācijai izmantojot ziņojuma metadatus, nodrošina pierādījumus par ziņojumu nodošanu un garantētu ziņojumu piegādi;


4.2.1.4. vismaz divu vienas pieturas aģentūras principa risinājumu izstrādē, kur, izmantojot vienotu programmatūras saskarni (API) un lietotāja saskarni (GUI) tiek nodrošināta pieeja vairāku (vismaz četru) iekšējo (BackOffice) informācijas sistēmu nodrošinātajiem servisiem;


4.2.1.5. vismaz viena projekta, kurā vienlaicīgi izmantoti xml un EDIFACT standarti, realizācijā;

4.2.2.

Pretendenta pieredze tiek apliecināta aizpildot un parakstot Konkursa nolikumam pievienoto veidlapu (pielikums Nr.2.1.). Ja pretendents ir piegādātāju apvienība, pieredze tiek apliecināta attiecīgajam piegādātāju apvienības dalībniekam aizpildot un parakstot Konkursa nolikumam pievienoto veidlapu (pielikums Nr.2.1.);

4.2.3.

Pretendentam ir jābūt pietiekošam tehniskajam aprīkojumam (ang.-hardware) tehniskajā specifikācijā noteikto pakalpojumu sniegšanai. Jebkāda programmatūra, kuru Pretendents plāno izmantot pakalpojumu nodrošināšanai ir jāizmanto atbilstoši autortiesību normām, nepieciešamības gadījumā nodrošinot atbilstošas licences.

4.2.4.

Gadījumos, kad pretendents piedāvājumā ietver trešo personu veidotu preču (programmatūras) piegādi (turpmāk tekstā „preču piegāde”), tam jābūt šādu piedāvāto preču ražotāja, ražotāja autorizētas pārstāvniecības ar pārpilnvarojuma tiesībām pilnvarotam pārstāvim izplatīt konkrētās preces un nodrošināt to garantijas apkalpošanas pakalpojumus Latvijas Republikas teritorijā. Ja pretendents ir piegādātāju apvienība, tad vismaz vienam no piegādātāju apvienības dalībniekiem ir jābūt piedāvāto preču ražotāja, ražotāja autorizētas pārstāvniecības ar pārpilnvarojuma tiesībām pilnvarotam pārstāvim izplatīt konkrētās preces un nodrošināt to garantijas apkalpošanas pakalpojumus Latvijas Republikas teritorijā.

4.3. Prasības pretendenta personālam: Pretendentam jāpiedāvā darba grupa, kura sastāv no šādiem speciālistiem (katrs speciālists var piedalīties piedāvājumā ne vairāk kā 2 (divās) lomās), kuru kvalifikācija un pieredze atbilst vismaz šādām prasībām:

4.3.1.

Informācijas tehnoloģiju projektu vadītājs:

Profesionālais maģistra grāds projektu vadībā, kas atbilst Ministru kabineta 2010.gada 18.maija noteikumos Nr.461 "Noteikumi par Profesiju klasifikatoru, profesijai atbilstošiem pamatuzdevumiem un kvalifikācijas pamatprasībām un Profesiju klasifikatora lietošanas un aktualizēšanas kārtību" minētajai kvalifikācijas pakāpei vai augstākā izglītība telekomunikāciju, datorzinību vai vadības zinību jomā un starptautiski atzīts sertifikāts projektu vadībā (jāiesniedz dokumenta /u kopija/s);

Iepriekšējo trīs gadu laikā pieredze vismaz 1 (viena) projekta vadībā informācijas tehnoloģiju jomā ar projekta budžetu vismaz 50 000 Eiro (piecdesmit tūkstoši eiro) (jāaizpilda un jāiesniedz pielikumā pievienotā apliecinājuma forma);

Informācijas tehnoloģiju projektu vadītājs:

Profesionālais maģistra grāds projektu vadībā, kas atbilst Ministru kabineta 2010.gada 18.maija noteikumos Nr.461 "Noteikumi par Profesiju klasifikatoru, profesijai atbilstošiem pamatuzdevumiem un kvalifikācijas pamatprasībām un Profesiju klasifikatora lietošanas un aktualizēšanas kārtību" minētajai kvalifikācijas pakāpei vai augstākā izglītība telekomunikāciju, datorzinību vai vadības zinību jomā un starptautiski atzīts sertifikāts projektu vadībā (jāiesniedz dokumenta /u kopija/s);

Praktiska pieredze vismaz 1 (viena) finanšu ziņā līdzvērtīga projekta vadībā, kas ietver datu apmaiņas sistēmas izstrādi (jāaizpilda un jāiesniedz pielikumā pievienotā apliecinājuma forma).

Informācijas tehnoloģiju projektu vadītājs:

Profesionālais maģistra grāds projektu vadībā, kas atbilst Ministru kabineta 2010.gada 18.maija noteikumos Nr.461 "Noteikumi par Profesiju klasifikatoru, profesijai atbilstošiem pamatuzdevumiem un kvalifikācijas pamatprasībām un Profesiju klasifikatora lietošanas un aktualizēšanas kārtību" minētajai kvalifikācijas pakāpei vai augstākā izglītība telekomunikāciju, datorzinību vai vadības zinību jomā un starptautiski atzīts sertifikāts projektu vadībā (PRINCE II; PMP vai līdzvērtīgs) (jāiesniedz dokumenta /u kopija/s).

Praktiska pieredze vismaz 1 (viena) finanšu ziņā līdzvērtīga projekta vadībā, kas ietver datu noliktavas izstrādi (jāaizpilda un jāiesniedz pielikumā pievienotā apliecinājuma forma).

Informācijas tehnoloģiju projektu vadītājs:

Profesionālais maģistra grāds projektu vadībā, kas atbilst Ministru kabineta 2010.gada 18.maija noteikumos Nr.461 "Noteikumi par Profesiju klasifikatoru, profesijai atbilstošiem pamatuzdevumiem un kvalifikācijas pamatprasībām un Profesiju klasifikatora lietošanas un aktualizēšanas kārtību" minētajai kvalifikācijas pakāpei vai augstākā izglītība telekomunikāciju, datorzinību vai vadības zinību jomā un starptautiski atzīts sertifikāts projektu vadībā (PRINCE II; PMP vai līdzvērtīgs) (jāiesniedz dokumenta /u kopija/s);

Praktiska pieredze vismaz 2 (divu) finanšu ziņā līdzvērtīgu projektu vadībā, no kuriem vismaz viens projekts, kas ietver datu apmaiņas sistēmas izstrādi, bet vismaz viens projekts – pilnu sistēmas izstrādes dzīves ciklu (sākot no biznesa analīzes un konceptuālā risinājuma izstrādes līdz sistēmas ieviešanai lietošanā) (jāaizpilda un jāiesniedz pielikumā pievienotā apliecinājuma forma);

4.3.2.

Biznesa analītiķis/konsultants:

Augstākā izglītība vadības zinātnēs jūrniecības sektorā vai jūras transportā (jāiesniedz dokumenta /u kopija/s).

Pēdējo trīs gadu laikā ir pieredze darbā ar kuģošanas drošības un ostu formalitāšu informāciju (jāaizpilda un jāiesniedz pielikumā pievienotā apliecinājuma forma);

Pēdējo trīs gadu laikā ir pieredze darbībā ar jūras kravu pārvadājumos iesaistītajām institūcijām un komersantiem, kā arī pieredze darbā ar vismaz vienu kuģu satiksmes uzraudzības un informācijas datu apmaiņas sistēmu (jāaizpilda un jāiesniedz pielikumā pievienotā apliecinājuma forma).

Pieredze darbā ar vismaz vienu kuģošanas drošības un ostu formalitāšu vienota loga atbalsta sistēmas dokumentācijas izstrādi, tai skatā sagatavošanā un tehniskās dokumentācijas izstrādi (jāaizpilda un jāiesniedz pielikumā pievienotā apliecinājuma forma).

Biznesa analītiķis/konsultants:

Augstākā izglītība vadības zinātnēs jūrniecības sektorā vai jūras transportā (jāiesniedz dokumenta /u kopija/s).

Pēdējo trīs gadu laikā ir pieredze darbā ar kuģošanas drošības un ostu formalitāšu informāciju (jāaizpilda un jāiesniedz pielikumā pievienotā apliecinājuma forma);

Pēdējo trīs gadu laikā ir pieredze darbībā ar jūras kravu pārvadājumos iesaistītajām institūcijām un komersantiem, kā arī pieredze darbā ar vismaz vienu kuģu satiksmes uzraudzības un informācijas datu apmaiņas sistēmu (jāaizpilda un jāiesniedz pielikumā pievienotā apliecinājuma forma).

  • Pēdējo 3 gadu laikā ir pieredze vismaz vienas izpētes vai novēršanas dokumentu izstrādē, kurās ietvaros veikta kuģošanas un ostu informācijas apmaiņas procesu izpēte vai novērtēšana (jāaizpilda un jāiesniedz pielikumā pievienotā apliecinājuma forma).

Biznesa analītiķis/konsultants:

Augstākā izglītība vadības zinātnēs jūrniecības sektorā vai jūras transportā (jāiesniedz dokumenta /u kopija/s).

Pēdējo trīs gadu laikā ir pieredze darbā ar kuģošanas drošības un ostu formalitāšu informāciju (jāaizpilda un jāiesniedz pielikumā pievienotā apliecinājuma forma);

Pēdējo trīs gadu laikā ir pieredze darbībā ar jūras kravu pārvadājumos iesaistītajām institūcijām un komersantiem, kā arī pieredze darbā ar vismaz vienu kuģu satiksmes uzraudzības un informācijas datu apmaiņas sistēmu (jāaizpilda un jāiesniedz pielikumā pievienotā apliecinājuma forma).

Pieredze darbā ar vismaz vienu kuģošanas drošības un ostu formalitāšu vienota loga atbalsta sistēmas dokumentācijas izstrādi, tai skatā sagatavošanā un tehniskās dokumentācijas izstrādi (jāaizpilda un jāiesniedz pielikumā pievienotā apliecinājuma forma).

Biznesa analītiķis/konsultants:

Augstākā izglītība vadības zinātnēs jūrniecības sektorā vai jūras transportā (jāiesniedz dokumenta /u kopija/s).

Pēdējo trīs gadu laikā ir pieredze darbā ar kuģošanas drošības un ostu formalitāšu informāciju (jāaizpilda un jāiesniedz pielikumā pievienotā apliecinājuma forma);

Pēdējo trīs gadu laikā ir pieredze darbībā ar jūras kravu pārvadājumos iesaistītajām institūcijām un komersantiem, kā arī pieredze darbā ar vismaz vienu kuģu satiksmes uzraudzības un informācijas datu apmaiņas sistēmu (jāaizpilda un jāiesniedz pielikumā pievienotā apliecinājuma forma).

Pieredze darbā ar vismaz vienu kuģošanas drošības un ostu formalitāšu vienota loga atbalsta sistēmas dokumentācijas izstrādi, tai skatā sagatavošanā un tehniskās dokumentācijas izstrādi(jāaizpilda un jāiesniedz pielikumā pievienotā apliecinājuma forma).

4.3.3.

Ostu informācijas sistēmu eksperts:

Augstākā izglītība vadību zinātņu jomā, informācijas tehnoloģiju, loģistikas vai jūrniecības jomā (jāiesniedz dokumenta /u kopija/s);

pieredze vismaz vienas informācijas sistēmas, kura nodrošina tiešu vai pastarpinātu (izmantojot nacionālo SafeSeaNet vai līdzvērtīgu nacionālo sistēmu) informācijas apmaiņu ar Eiropas Jūras drošības aģentūru (EMSA) vai kompetences ziņā līdzvērtīgu pārvaldes iestādi ar līgumcenu, kura nav mazāka par 150`000 Eiro (trīs simti tūkstošiem eiro) ieviešanā kā vadošajam biznesa prasību analītiķim/ sistēmanalītiķim vai projekta vadītajam (jāaizpilda un jāiesniedz pielikumā pievienotā apliecinājuma forma).

Telekomunikāciju vai elektronikas inženieris:

Augstākā izglītība inženierzinātnēs (vismaz maģistra grāds elektronikas vai telekomunikāciju jomā) (jāiesniedz dokumenta /u kopija/s);

  • Iepriekšējo 3 gadu laikā ir pieredze vismaz viena elektronikas vai radiotehnikas risinājuma projektēšanā un izstrādē, tai skaitā tehniskās dokumentācijas izstrādē (jāaizpilda un jāiesniedz pielikumā pievienotā apliecinājuma forma);

  • Iepriekšējo 3 gadu laikā ir vismaz viena praktiska pieredze elektrotehnikas vai radiotehnikas risinājuma pilna dzīvescikla prototipa izstrādē, kas ietver projektēšanu, izstrādi, montāžā un uzturēšanu (jāaizpilda un jāiesniedz pielikumā pievienotā apliecinājuma forma).

  • Iepriekšējo 3 gadu laikā ir elektronisko ierīču vai aprīkojumu montāžas pieredze (jāaizpilda un jāiesniedz pielikumā pievienotā apliecinājuma forma).

Projekta zinātniskais vadītājs:

Doktora grāds datorzinībās, pieredze zinātnisku pētījumu veikšanā/vadībā par dokumentu apstrādes sistēmām (pētījuma rezultātiem jābūt publicētiem) (jāiesniedz dokumenta /u kopija/s);

Projekta zinātniskais vadītājs:

Doktora grāds datorzinībās, pieredze zinātnisku pētījumu veikšanā/vadībā par dokumentu apstrādes sistēmām (pētījuma rezultātiem jābūt publicētiem) (jāiesniedz dokumenta /u kopija/s);

4.3.4.

Sistēmas arhitekts:

Augstākā izglītība datorzinībās (jāiesniedz dokumenta /u kopija/s);

Pieredze vismaz viena vienas pieturas aģentūras lietotāja saskarnes (pakalpojumu portāla) un programmatūras saskarnes (API) projektēšanā informācijas sistēmā, kuras izstrādes cena nav mazāka par 150`000 EUR, pieredze vismaz viena ziņojumapmaiņas risinājuma, kurš atbilst Nolikuma 4.2.1.1..punkta prasībām, projektēšanā (jāaizpilda un jāiesniedz pielikumā pievienotā apliecinājuma forma).

Radio inženieris/ eksperts:

Augstākā izglītība elektronikā vai radiotehnikas jomā (jāiesniedz dokumenta /u kopija/s);

Pēdējo 3 gadu laikā ir pieredze darbā ar kuģu elektronikas un/ vai radiotehnikas aprīkojumu, tai skaitā iekārtu darbības uzturēšanu vai kontroli (jāaizpilda un jāiesniedz pielikumā pievienotā apliecinājuma forma);

  • Pēdējo 3 gadu laikā ir pieredze darbā ar kuģu radiosakaru aprīkojuma dokumentāciju, tai skaitā tās analīzi, atbilstības novērtēšanu (jāaizpilda un jāiesniedz pielikumā pievienotā apliecinājuma forma);

  • Pieredze darbā ar SOLAS konvenciju, kā arī tai piekritīgo sakaru un navigācijas kodeksiem, Starptautiskās telekomunikāciju savienības Radio reglamentu (ITU Radio Regulations) (jāaizpilda un jāiesniedz pielikumā pievienotā apliecinājuma forma);

Sistēmas arhitekts:

Augstākā izglītība datorzinībās (jāiesniedz dokumenta /u kopija/s);

Pieredze vismaz viena atvērta dokumentu apmaiņas risinājuma konceptuālās arhitektūras un sistēmas projektējuma izstrādē (jāaizpilda un jāiesniedz pielikumā pievienotā apliecinājuma forma).

Pieredze vismaz vienas informācijas sistēmas, kura nodrošina sadarbību un informācijas apmaiņu starp vismaz 10 (desmit) dažādām informācijas sistēmām, arhitektūras izstrādē, šādas sistēmas izstrādes līgumcena nedrīkst būt mazāka par 150`000 EUR (jāaizpilda un jāiesniedz pielikumā pievienotā apliecinājuma forma).

Sistēmas arhitekts:

Augstākā izglītība datorzinībās (jāiesniedz dokumenta /u kopija/s);

Pieredze vismaz viena datu noliktavas risinājuma izstrādē, kura izstrādes cena nav mazāka par 150`000 EUR (jāaizpilda un jāiesniedz pielikumā pievienotā apliecinājuma forma).

4.3.5.

Vismaz trīs programmētāji, kuri kopumā nodrošina sekojošas kompetences:

Praktiska pieredze XML un EDIFACT standartu praktiskā pielietošanā (jāaizpilda un jāiesniedz pielikumā pievienotā apliecinājuma forma);

Pretendenta piedāvātās programmēšanas vides ražotāja sertifikācija (jāiesniedz dokumenta /u kopija/s);

Praktiska pieredze ziņojumapmaiņas sistēmas izstrādē (jāaizpilda un jāiesniedz pielikumā pievienotā apliecinājuma forma).

Radio sakaru/ bezvadu tīklu operatori (vismaz divi speciālisti)

Pieredze radio vai citu sakaru risinājumu iekārtu uzstādīšana, tai skaitā apraides sektoru antenu uzstādīšana un regulēšana (jāaizpilda un jāiesniedz pielikumā pievienotā apliecinājuma forma);

  • Pieredze darbā ar radiotehnikas iekārtu monitoringu un uzturēšanu, maršrutētāju un serveru konfigurēšanu (jāaizpilda un jāiesniedz pielikumā pievienotā apliecinājuma forma);

Pieredze darbā augstumā (telekomunikāciju torņos);

Pieredze darbā ar 2300 – 2450MHz, 5485 -5720 MHz joslas frekvencēm (jāaizpilda un jāiesniedz pielikumā pievienotā apliecinājuma forma);

Vismaz trīs programmētāji, kuri kopumā nodrošina sekojošas kompetences:

Praktiska pieredze XML un EDIFACT standartu praktiskā pielietošanā (jāaizpilda un jāiesniedz pielikumā pievienotā apliecinājuma forma);

Pretendenta piedāvātās programmēšanas vides ražotāja sertifikācija (jāiesniedz dokumenta /u kopija/s);

Praktiska pieredze ziņojumapmaiņas sistēmas izstrādē (jāaizpilda un jāiesniedz pielikumā pievienotā apliecinājuma forma).

Vismaz trīs programmētāji, kuri kopumā nodrošina sekojošas kompetences:

Praktiska pieredze XML un EDIFACT standartu praktiskā pielietošanā (jāaizpilda un jāiesniedz pielikumā pievienotā apliecinājuma forma) ;

Pretendenta piedāvātās programmēšanas vides ražotāja sertifikācija (jāiesniedz dokumenta /u kopija/s);

Praktiska pieredze ziņojumapmaiņas sistēmas izstrādē (jāaizpilda un jāiesniedz pielikumā pievienotā apliecinājuma forma).

4.3.6.

Drošības speciālists:

Augstākā izglītība datorzinībās ar specialitāti informācijas drošībā(jāiesniedz dokumenta /u kopija/s);

CISM vai ekvivalents un CEH vai ekvivalents sertifikāts (jāiesniedz dokumenta /u kopija/s);

Teorētiskas zināšanas un praktiska pieredze informācijas drošības sistēmas izstrādē vai novērtēšanā (ISO 27001:2005 auditora sertifikāts), praktiska pieredze vismaz viena informācijas sistēmu drošības pārvaldības organizatorisko un tehnoloģiskā risinājuma izstrādē (jāaizpilda un jāiesniedz pielikumā pievienotā apliecinājuma forma).

Programmētājs

Augstākā izglītība datorzinībās (jāiesniedz dokumenta /u kopija/s);

  • Iepriekšējo 3 gadu laikā ir vismaz viena praktiska pieredze ziņojumapmaiņas sistēmas izstrādē (jāaizpilda un jāiesniedz pielikumā pievienotā apliecinājuma forma);

Drošības speciālists:

Augstākā izglītība datorzinībās ar specialitāti informācijas drošībā.(jāiesniedz dokumenta /u kopija/s)

CISM vai ekvivalents un CEH vai ekvivalents sertifikāts (jāiesniedz dokumenta /u kopija/s);

Teorētiskas zināšanas un praktiska pieredze informācijas drošības sistēmas izstrādē vai novērtēšanā (ISO 27001:2005 auditora sertifikāts), praktiska pieredze vismaz viena informācijas sistēmu drošības pārvaldības organizatorisko un tehnoloģiska risinājuma izstrādē (jāaizpilda un jāiesniedz pielikumā pievienotā apliecinājuma forma).

Drošības speciālists:

Augstākā izglītība datorzinībās ar specialitāti informācijas drošībā (jāiesniedz dokumenta /u kopija/s)

CISM vai ekvivalents un CEH vai ekvivalents sertifikāts (jāiesniedz dokumenta /u kopija/s);

Teorētiskas zināšanas un praktiska pieredze informācijas drošības sistēmas izstrādē vai novērtēšanā (ISO 27001:2005 auditora sertifikāts), praktiska pieredze vismaz viena informācijas sistēmu drošības pārvaldības organizatorisko un tehnoloģiska risinājuma izstrādē. (jāaizpilda un jāiesniedz pielikumā pievienotā apliecinājuma forma).

4.3.7.

Testēšanas vadītājs:

Augstākā izglītība datorzinībās ar specialitāti informācijas sistēmu testēšanā (jāiesniedz dokumenta /u kopija/s);

ISTQB Advanced level Test Manager sertifikāts (vai ekvivalents) (jāiesniedz dokumenta /u kopija/s);

Pieredze vismaz viena informācijas sistēmas izstrādes projekta testēšanas vadībā, kur veikts pilns testēšanas spektrs – funkcionālā testēšana, integrācijas testēšana, drošības testēšana, veiktspējas testēšana unvismaz vienā projektā, kur veiktspējas testēšana veikta pie vismaz 250 vienlaicīgiem lietotājiem un, projekta finanšu apjoms nav bijis mazāks par 150`000 EUR (jāaizpilda un jāiesniedz pielikumā pievienotā apliecinājuma forma).

Juridiskais eksperts:

Augstākā izglītība tiesību zinātnēs ar specializāciju jūrlietās (vismaz maģistra grāds) (jāiesniedz dokumenta /u kopija/s);

Praktiska pieredze jūrlietām saistītu normatīvo aktu projektu izstrādē vai piemērošanā tiesā (jāaizpilda un jāiesniedz pielikumā pievienotā apliecinājuma forma),

Izpētes un zinātniskā līdzstrādnieka un publikāciju pieredze starptautiska mēroga jūrniecības sektora izpētes projektos (jāaizpilda un jāiesniedz pielikumā pievienotā apliecinājuma forma).

Testēšanas vadītājs:

Augstākā izglītība datorzinībās ar specialitāti informācijas sistēmu testēšanā (jāiesniedz dokumenta /u kopija/s);

ISTQB Advanced level Test Manager sertifikāts (vai ekvivalents) (jāiesniedz dokumenta /u kopija/s);

Pieredze vismaz 1 (viena) informācijas sistēmu izstrādes projekta testēšanas vadībā, kur veikts pilns testēšanas spektrs – funkcionālā testēšana, integrācijas testēšana, drošības testēšana, veiktspējas testēšana un veiktspējas testēšana veikta pie vismaz 250 vienlaicīgiem lietotājiem un, projekta finanšu apjoms nav bijis mazāks par 150`000 EUR (jāaizpilda un jāiesniedz pielikumā pievienotā apliecinājuma forma).

Testēšanas vadītājs:

Augstākā izglītība datorzinībās ar specialitāti informācijas sistēmu testēšanā (jāiesniedz dokumenta /u kopija/s);

ISTQB Advanced level Test Manager sertifikāts (vai ekvivalents) (jāiesniedz dokumenta /u kopija/s);

Pieredze vismaz 1 (viena) informācijas sistēmu izstrādes projektu testēšanas vadībā, kur veikts pilns testēšanas spektrs – funkcionālā testēšana, integrācijas testēšana, drošības testēšana, veiktspējas testēšana un veiktspējas testēšana veikta pie vismaz 250 vienlaicīgiem lietotājiem un, projekta finanšu apjoms nav bijis mazāks par 150`000 EUR (jāaizpilda un jāiesniedz pielikumā pievienotā apliecinājuma forma).

4.3.8.

Testētāji (vismaz divi speciālisti):

- Augstākā izglītība datorzinībās ar specialitāti informācijas sistēmu testēšanā vai augstākā izglītība datorzinībās un ISTQB Foundation level sertifikāts (vai ekvivalents); (jāiesniedz dokumenta /u kopija/s)

- pieredze vismaz 1 (viena) informācijas sistēmu izstrādes projekta testēšanā, kur veikts pilns testēšanas spektrs – funkcionālā testēšana, integrācijas testēšana, drošības testēšana, veiktspējas testēšana, kur veiktspējas testēšana veikta pie vismaz 250 vienlaicīgiem lietotājiem un projekta finanšu apjoms nav bijis mazāks par 150`000 EUR (jāaizpilda un jāiesniedz pielikumā pievienotā apliecinājuma forma);


Testētāji (vismaz divi speciālisti):

- Augstākā izglītība datorzinībās ar specialitāti informācijas sistēmu testēšanā vai augstākā izglītība datorzinībās un ISTQB Foundation level sertifikāts (vai ekvivalents) (jāiesniedz dokumenta /u kopija/s);

- pieredze vismaz 1 (viena) informācijas sistēmu izstrādes projekta testēšanā, kur veikts pilns testēšanas spektrs – funkcionālā testēšana, integrācijas testēšana, drošības testēšana, veiktspējas testēšana un veiktspējas testēšana veikta pie vismaz 250 vienlaicīgiem lietotājiem un projekta finanšu apjoms nav bijis mazāks par 150`000 EUR (jāaizpilda un jāiesniedz pielikumā pievienotā apliecinājuma forma).

Testētāji (vismaz divi speciālisti):

Augstākā izglītība datorzinībās ar specialitāti informācijas sistēmu testēšanā vai augstākā izglītība datorzinībās un ISTQB Foundation level sertifikāts (vai ekvivalents) (jāiesniedz dokumenta /u kopija/s);

- pieredze vismaz 1 (viena) informācijas sistēmu izstrādes projekta testēšanā, kur veikts pilns testēšanas spektrs – funkcionālā testēšana, integrācijas testēšana, drošības testēšana, veiktspējas testēšana un veiktspējas testēšana veikta pie vismaz 250 vienlaicīgiem lietotājiem un projekta finanšu apjoms nav bijis mazāks par 150`000 EUR (jāaizpilda un jāiesniedz pielikumā pievienotā apliecinājuma forma).

4.3.9.



Juridiskais eksperts:

Augstākā izglītība tiesību zinātnēs ar specializāciju jūrlietās (vismaz maģistra grāds) (jāiesniedz dokumenta /u kopija/s);

Praktiska pieredze jūrlietām saistītu normatīvo aktu projektu izstrādē vai piemērošanā tiesā (jāaizpilda un jāiesniedz pielikumā pievienotā apliecinājuma forma);

Izpētes un zinātniskā līdzstrādnieka un publikāciju pieredze starptautiska mēroga jūrniecības sektora izpētes projektos (jāaizpilda un jāiesniedz pielikumā pievienotā apliecinājuma forma).

Juridiskais eksperts:

Augstākā izglītība tiesību zinātnēs ar specializāciju jūrlietās (vismaz maģistra grāds) (jāiesniedz dokumenta /u kopija/s);

Praktiska pieredze jūrlietām saistītu normatīvo aktu projektu izstrādē vai piemērošanā tiesā (jāaizpilda un jāiesniedz pielikumā pievienotā apliecinājuma forma);

Izpētes un zinātniskā līdzstrādnieka un publikāciju pieredze starptautiska mēroga jūrniecības sektora izpētes projektos (jāaizpilda un jāiesniedz pielikumā pievienotā apliecinājuma forma).

4.3.10.




Sistēmanalītiķis:

- Augstākā izglītība datorzinībās vai vadzinībās(jāiesniedz dokumenta /u kopija/s);

- pieredze sistēmanalīzes veikšanā un prasību specifikācijas izstrādē vismaz vienā projektā, kurā veikta ostas formalitāšu vai starptautiskā transporta dokumentu apmaiņas elektronizācija (jāaizpilda un jāiesniedz pielikumā pievienotā apliecinājuma forma).



  1. KONKURSA TERMIŅI

    1. Piedāvājumu iesniegšanas termiņš ir līdz 2014.gada 22.decembrimplkst.14:00, Centrā, Xxxxxxxxxx xxxx 00, Xxxx, XX-0000. Pretendentu piedāvājumi, kas iesniegti pēc šī termiņa, netiek atvērti un neatvērti tiek nosūtīti atpakaļ iesniedzējam.

    2. Piedāvājumu atvēršana sākas 2014.gada 22.decembrī pēc piedāvājumu iesniegšanas termiņa beigām plkst.11:00. Piedāvājumu atvēršanas sanāksme notiek atbilstoši Publisko iepirkumu likumam.

    3. Ieinteresēto piegādātāju sanāksme tiks organizēta 2014.gada 5.decembrī plkst. 10.00 Rīgā, Vecmīlgrāvī, Xxxxxx xxxx 0x, Xxxx, XX-0000. Ieinteresētie piegādātāji sagatavo pārrunājamos jautājumus par atklāta konkursa nolikumu un tehnisko specifikāciju un informāciju par pārstāvjiem, kuri piedalīsies ieinteresēto piegādātāju sanāksmē un līdz 2014.gada 3.decembrim plkst. 17:00, elektroniski iesniedz nolikuma 1.4.punktā norādītajai kontaktpersonai.

    4. Ieinteresētajiem piegādātājiem iespējams iepazīties ar „Pilot EU SEC Data and Data transfer security requirements” dokumenta prasībām, iepriekš saskaņojot laikus ar Xxxxxx Xxxxxxx, LR AM NBS Jūras spēku flotiles Krasta apsardzes dienesta Operatīvās nodaļas kuģošanas drošības inspektoru, tālrunis: 67082057, e-pasts: xxxxxx.xxxxxxx@xxxx.xx.

    5. Ja ieinteresētais piegādātājs ir laikus pieprasījis papildus informāciju, iepirkuma komisija to sniedz 5 dienu laikā, bet ne vēlāk kā 6 (sešas) dienas pirms piedāvājumu iesniegšanas termiņa beigām.

  2. PIEDĀVĀJUMA NOFORMĒŠANAS PRASĪBAS

    1. Pretendents sagatavo un iesniedz piedāvājumu saskaņā ar šajā nolikumā izvirzītajām prasībām:

      1. visiem dokumentiem jābūt latviešu un angļu valodā;

      2. piedāvājuma dokumenti un to kopijas ir jāiesniedz vienā iesaiņojumā, nodrošinot, ka tiem nevar piekļūt, nesabojājot iesaiņojumu;

      3. piedāvājuma lapām jābūt numurētām;

      4. visiem piedāvājuma dokumentiem jābūt cauršūtiem ar izturīgu diegu vai auklu. Caurauklojuma vietai jābūt noformētai atbilstīgi 2010.gada 28.septembra Ministru Kabineta noteikumiem Nr. 916 „Dokumentu izstrādāšanas un noformēšanas kārtība”. Piedāvājumam ir jābūt noformētam tā, lai novērstu iespēju nomainīt lapas, nesabojājot nostiprinājumu;

      5. piedāvājuma dokumentiem jābūt skaidri salasāmiem, bez labojumiem un dzēsumiem;

      6. piedāvājuma sākumā jāievieto satura rādītājs. Ja piedāvājums iesniegts vairākos sējumos, satura rādītājs jāsastāda katram sējumam atsevišķi, pirmā sējuma satura rādītājā jānorāda sējumu skaits un lapu skaits katrā sējumā;

      7. ja piedāvājums vai atsevišķas tā daļas satur komercnoslēpumu, piedāvājuma lapām, kuras satur šāda rakstura informāciju, ir jābūt ar atzīmi „Komercnoslēpums”, izņemot Publisko iepirkumu likumā noteiktos gadījumus.

      8. Konkursam jāiesniedz piedāvājuma dokumentu oriģināls un divas kopijas. Uz piedāvājuma oriģināla titullapas ir jābūt norādei „ORIĢINĀLS”, bet uz piedāvājuma kopiju titullapām jābūt norādei „KOPIJA”.

    2. Dokumenti jāiesniedz personīgi vai jānosūta pasta sūtījumā slēgtā, aizzīmogotā iesaiņojumā Centra Kancelejā, Xxxxxxxxxx xxxx 00, Xxxx, XX-0000. Ja pretendents nosūta piedāvājumu pa pastu, tas nodrošina piedāvājumu saņemšanu līdz noteiktajam termiņam.

    3. Uz iesaiņojuma jānorāda:

      1. pretendenta nosaukums, adrese, tālrunis;

      2. norāde: Konkursam „Tehniskā risinājuma prototipa izstrāde AnNa (VILDA) projekta ietvaros” (identifikācijas Nr. VAMOIC 171). Neatvērt līdz 2014. gada 22.decembrim plkst. 14:00.

    4. Dokumenti piedāvājumā jāsakārto šādā secībā:

      1. Konkursa pieteikums (pielikuma Nr.1 formā);

      2. Kvalifikācijas dokumenti;

      3. Tehniskais piedāvājums (pielikuma Nr.4 formā);

      4. Finanšu piedāvājums - iesniedzams brīvā formā.

    5. Piedāvājuma papildinājumus, grozījumus vai atsaukumus var iesniegt līdz piedāvājumu iesniegšanas termiņa beigām rakstiskā formā personīgi vai pasta sūtījumā Centra Kancelejā, Xxxxxxxxxx xxxx  00, Xxxx, ievērojot nolikuma 5.1.punkta noteikumus ar attiecīgu norādi „PAPILDINĀJUMS”, „GROZĪJUMS” vai „ATSAUKUMS”.

    6. Atsaukumam ir bezierunu raksturs un tas izslēdz pretendenta atsauktā piedāvājuma tālāku līdzdalību Konkursā.

    7. Ja konstatētas pretrunas starp Pretendenta iesniegto piedāvājuma oriģinālu un piedāvājuma kopijām, par pamatu tiek ņemts piedāvājuma oriģināls.

  1. KONKURSA PIETEIKUMS UN KVALIFIKĀCIJAS DOKUMENTI

    1. Lai apliecinātu savu piedalīšanos Konkursā, Pretendentam jāiesniedz Pieteikums (pielikuma Nr.1 formā).

      1. Pieteikuma oriģināls (aizpildīts nolikuma pielikums Nr.1) jāparaksta Pretendenta pārstāvim ar pārstāvības tiesībām vai tā pilnvarotai personai. Ja Pretendents ir piegādātāju apvienība un sabiedrības līgumā nav atrunātas pārstāvības tiesības, pieteikuma oriģināls jāparaksta katras personas, kas iekļauta piegādātāju apvienībā, pārstāvim ar pārstāvības tiesībām.

      2. Lai iepirkuma komisija gūtu pārliecību par Pretendenta pārstāvības tiesībām, Pretendentam jāiesniedz spēkā esoša Latvijas Republikas Uzņēmumu reģistra izziņa (oriģināls vai Ministru Kabineta 28.09.2010. noteikumu Nr.916 „Dokumentu izstrādāšanas un noformēšanas kārtība” noteiktajā kārtībā apliecināta kopija; turpmāk – apliecināta kopija), kurā ir uzrādītas Pretendenta personas ar pārstāvības tiesībām un pārstāvības apjoms (norāde, vai persona/-as ir tiesīga pārstāvēt atsevišķi vai kopā ar citu personu/-ām).

Ja pieteikumu paraksta persona, kura atšķiras no Uzņēmuma reģistra izziņā norādītās, jāiesniedz Pretendenta personas ar pārstāvības tiesībām izdota pilnvara (oriģināls vai apliecināta kopija) citai personai parakstīt piedāvājumu un/vai līgumu.

    1. Ja pieteikumu nav parakstījusi persona ar pārstāvības tiesībām, komisija pieņem lēmumu piedāvājumu neizskatīt.

    2. Lai apliecinātu savu atbilstību kvalifikācijas prasībām, pretendentam jāiesniedz:

      1. Apliecinājums par pretendenta pieredzi pielikuma Nr.2.1. formā, kas pierāda pretendenta atbilstību nolikuma 4.2.punktā izvirzītajai kvalifikācijas prasībai. Apliecinājumu aizpilda un paraksta persona ar pārstāvības tiesībām vai tās pilnvarota persona;

      2. Apliecinājums par pretendenta darbinieku, kas tiks iesaistīti projekta izstrādē, pieredzi pielikuma Nr. 2.2. formā, kas pierāda pretendenta atbilstību 4.3.punktā minētajai prasībai. Apliecinājumu aizpilda un paraksta persona ar pārstāvības tiesībām vai tās pilnvarota persona;

      3. Pretendenta darbinieku kvalifikāciju (izglītību) apliecinošu dokumentu kopijas, kas pierāda pretendenta atbilstību nolikuma 4.3.punktā izvirzītajām kvalifikācijas prasībām.

      4. Apliecinājums, ka pretendentam ir pietiekošs tehniskais aprīkojums (ang.-hardware) un programmatūra tehniskajā specifikācijā noteiktās preces izstrādei, un, ka jebkāda programmatūra, kuru pretendents plāno izmantot pakalpojuma nodrošināšanai tiks izmantota atbilstoši autortiesību normām, nepieciešamības gadījumā nodrošinot atbilstošas lietošanas licences.

    3. Ražotāja vai ražotāja autorizētas pārstāvniecības ar pārpilnvarojuma tiesībām apliecinājums (oriģināls vai apliecināta kopija), ka pretendents ir autorizēts izplatīt konkrētās preces un nodrošināt to garantijas apkalpošanas pakalpojumus Latvijas Republikas teritorijā Ja Pretendents ir piegādātāju apvienība, Pretendentam jāiesniedz 7.1.2. punktā norādītais dokuments par katru personu, kas iekļauta apvienībā. Papildus jāiesniedz visu personu, kas iekļautas apvienībā, parakstīts sabiedrības līgums, kuru parakstījis katras personas pārstāvis ar pārstāvības tiesībām vai tā pilnvarota persona (oriģināls vai notariāli apliecināta kopija), kā arī katras personas atbildības apjoms. 7.3. punktā norādītie dokumenti jāiesniedz par to piegādātāju apvienības dalībnieku, kurš izstrādās Preci.

    4. Ja Pretendents piesaista apakšuzņēmējus vai personu, uz kuras iespējām Pretendents balstās, līguma izpildē jāiesniedz apakšuzņēmējiem izpildei nododamo līgumu daļu un to apjoma (%) apraksts, kā arī jāiesniedz spēkā esoši dokumenti, kas noslēgti ar Pretendentu un apliecina katra apakšuzņēmēja vai personas, uz kuras iespējām Pretendents balstās, līguma izpildē gatavību veikt tam izpildei nodotās līguma daļas (apliecināta sadarbības līguma kopija vai piekrišanas raksta oriģināls), kuri jāparaksta apakšuzņēmēja pārstāvim ar pārstāvības tiesībām vai tā pilnvarotai personai. Apakšuzņēmēju vai personu, uz kuras iespējām Pretendents balstās, pārstāvju pārstāvības tiesības tiek apliecinātas, iesniedzot 7.1.2.punktā norādīto dokumentu par katru piesaistīto apakšuzņēmēju vai personu, uz kuras iespējām Pretendents balstās. 7.3. punktā norādītie dokumenti jāiesniedz par to apakšuzņēmēju, kurš izstrādās Preci.

    5. Ārvalstu pretendenti ir tiesīgi iesniegt no 7.1.2. punktā noteiktā dokumenta atšķirīgu dokumentu ar 7.1.2. punktā pieprasīto informāciju, ja to izsniegusi attiecīga ārvalstu institūcija, iestāde vai persona, kas saskaņā ar Pretendenta reģistrācijas valsts normatīvajiem aktiem ir tiesīga to darīt. Ja Pretendenta reģistrācijas valsts normatīvie akti neparedz nolikuma 7.1.2.punktā minētā dokumenta izsniegšanu, Pretendentam jāiesniedz apliecinājums vai paskaidrojums, sniedzot nolikuma 7.1.2.punktā pieprasīto informāciju.

  1. TEHNISKAIS PIEDĀVĀJUMS

    1. Detalizēts piedāvātās Preces tehnoloģiskā risinājuma apraksts, ņemot vērā tehniskās specifikācijas prasības (pielikums Nr.3), iekļaujot:

      1. piedāvāto Preces izstrādes termiņu - detalizēts laika grafiks atbilstoši prototipa izstrādes posmiem saskaņā ar tehnisko specifikāciju;

      2. apliecinājumu par to, ka konsultācijas un apmācība, Preces izstrādes laikā, tiks nodrošināta latviešu valodā (iekļauts nolikuma pielikuma Nr.4 formā);

      3. apliecinājumu, ka pretendenta rīcībā ir visi nepieciešamie resursi un programmatūras Preces izstrādei (iekļauts nolikuma pielikuma Nr.4 formā);

      4. preces izstrādē izmantotās programmatūras ražotāju sarakstu (jānorāda nolikuma pielikuma Nr.4 formā).

  2. FINANŠU PIEDĀVĀJUMS

    1. Piedāvājuma cena jānorāda EUR atbilstoši pielikumam Nr.1 un iesniegtajam finanšu piedāvājumam.

    2. Finanšu piedāvājums iesniedzams brīvā formā. Sastādot finanšu piedāvājumu jāievēro tehniskajā specifikācijā noteiktie nodevumu iesniegšanas termiņi un pretendenta piedāvātais Preces izstrādes laika grafiks.

    3. Cenā jāiekļauj visas izmaksas un visi valsts un pašvaldību noteiktie nodokļi un nodevas bez pievienotās vērtības nodokļa (PVN). PVN jānorāda atsevišķi.

    4. Piedāvājuma cenas ir jāaprēķina un jānorāda ar precizitāti 2 (divas) zīmes aiz komata.

  1. PRETENDENTU kvalifikācijas pārbaude

    1. Komisija veic pretendentu kvalifikācijas pārbaudi.

    2. Pretendents tiek izslēgts no turpmākās dalības Konkursā, un piedāvājums netiek tālāk izvērtēts, ja komisija konstatē, ka:

      1. kvalifikācijas dokumenti nav iesniegti atbilstoši nolikuma 7.3.punkta prasībām un/vai to saturs neatbilst nolikuma 7.3.punkta prasībām un/vai pretendents iesniedzis nepatiesu informāciju savas kvalifikācijas novērtēšanai vai vispār nav iesniedzis pieprasīto informāciju, tajā skaitā, nav sniedzis iepirkuma komisijas pieprasīto precizējošo informāciju iepirkuma komisijas noteiktajā termiņā;

      2. pretendents neatbilst Konkursa nolikuma 4.punkta noteikumu prasībām.

    3. Ja pretendents ir piegādātāju apvienība, pretendents tiek izslēgts no turpmākās dalības Konkursā, ja komisija konstatē, ka uz kādu no personām, kas iekļauta apvienībā, attiecas kāds no 10.2.punktā minētajiem izslēgšanas nosacījumiem.

    4. Ja pretendents piesaista apakšuzņēmējus vai personu, uz kuras iespējām Pretendents balstās līguma izpildē, pretendents tiek izslēgts no turpmākās dalības Konkursā, ja komisija konstatē, ka uz kādu no apakšuzņēmējiem vai personu, uz kuras iespējām Pretendents balstās līguma izpildē, attiecas kāds no 10.2.punktā minētajiem izslēgšanas nosacījumiem.

    5. Ja pretendents ir personālsabiedrība, pretendents tiek izslēgts no turpmākas dalības Konkursā, ja komisija konstatē, ka uz kādu no personālsabiedrības biedriem attiecas kāds no 10.2.punktā minētajiem izslēgšanas nosacījumiem.

  2. pretendentu piedāvājumu atbilstības pārbaude

    1. Iepirkuma komisija veic Pretendentu piedāvājumu atbilstības pārbaudi.

    2. Pretendents tiek izslēgts no dalības Konkursā un tā piedāvājums netiek tālāk izvērtēts, ja komisija konstatē, ka:

      1. nav iesniegti tehniskā piedāvājuma dokumenti, vai tie un to saturs neatbilst nolikuma 8.punkta prasībām;

      2. piedāvājums neatbilst tehniskajai specifikācijai (pielikums Nr. 3);

      3. piedāvājums nav iesniegts par pilnu iepirkuma priekšmeta apjomu un / vai ir iesniegti divi vai vairāki piedāvājuma varianti.

  3. PIEDĀVĀJUMU VĒRTĒŠANA

    1. Pēc pretendentu piedāvājumu atbilstības pārbaudes komisija veic piedāvājumu atbilstības pārbaudi izturējušo pretendentu piedāvājumu vērtēšanu.

    2. Iepirkuma komisija veic aritmētisko kļūdu pārbaudi pretendentu piedāvājumos. Vērtējot finanšu piedāvājumu, iepirkuma komisija rīkojas saskaņā ar Publisko iepirkumu likuma 56.panta trešo daļu.

    3. Iepirkuma komisija pārbauda, vai nav iesniegts nepamatoti lēts piedāvājums un rīkojas saskaņā ar Publisko iepirkumu likuma 48.panta noteikumiem.

    4. Ja iepirkuma komisija konstatē, ka ir iesniegts nepamatoti lēts piedāvājums, tas tiek noraidīts.

    5. Konkursa nolikuma prasībām atbilstošie piedāvājumi tiek vērtēti, izmantojot izdevīguma punktu metodi katrā iepirkuma priekšmeta daļā atsevišķi. Tiek noteikti šādi vērtēšanas kritēriji:

Cena

40 punkti

Tehniskais piedāvājums

  1. punkti

Kopā:

100 punkti


    1. Iepirkuma komisija aprēķina piedāvājuma cenas izdevīguma punktus pēc sekojošas formulas:

A = 40 x (Ax:Ay), kur

A – pretendenta iegūtais punktu skaits;

40 – maksimālais iegūstamais punktu skaits;

Ax – lētākā piedāvājuma cena (EUR bez PVN);

Ay – vērtējamā piedāvājuma cena (EUR bez PVN).


12.7. Maksimālo punktu skaitu par piedāvājuma kvalitāti (60 punktus) saņems piedāvājums, kurā sniegtā informācija pilnībā un pārliecinošo norāda, ka rezultāts tiks sasniegts:

12.7.1. piedāvājumā ievēroti visi uz iepirkuma priekšmetu attiecināmie normatīvie akti un politikas plānošanas dokumenti (tajā skaitā, publiski pieejamie politikas plānošanas un iniciatīvas dokumentu projekti);

12.7.2. piedāvājumā iekļautā projekta realizācijas vīzija skaidri identificē plānoto rezultātu un soļus tā sasniegšanai, norādot katra soļa ietvaros veicamās darbības, sasniedzamo rezultātu un kritērijus tā akceptēšanai;

12.7.3. piedāvātā metodika paredz korektīvas darbības, ja kādā no projekta soļiem tiek identificēti riski projekta mērķa sasniegšanai;

12.7.4. piedāvājumā iekļautās tehnoloģijas tiek uzturētas un vismaz trīs gadus būs pieejami programmatūras atjauninājumi vai ir izziņotas nākamās programmatūras versijas izlaišanas datums.

12.8. Gadījumā, ja piedāvājums atbilst trīs no augstākminētajiem kritērijiem, uzskatāms, ka projekta mērķis visticamāk tiks sasniegts - šāds piedāvājums saņems 30 punktus.

12.9. Gadījumā, ja piedāvājums atbilst diviem no augstākminētajiem kritērijiem, uzskatāms, ka piedāvājumā ir daļēji trūkumi, kuri var apgrūtināt mērķa sasniegšanu - šāds piedāvājums saņems 10 punktus.

12.10. Gadījumā, ja piedāvājums atbilst vienam vai nevienam no augstākminētajiem kritērijiem, uzskatāms, ka piedāvājumā ir būtiski trūkumi, kuri var apgrūtināt mērķa sasniegšanu - šāds piedāvājums saņems 0 punktus. Piedāvājums ar šādu vērtējumu no turpmākās dalības atklātā konkursā tiks izslēgts.

    1. Pretendenta piedāvājumā iegūtā punktu summa tiek iegūta summējot, atsevišķi par katru vērtēšanas kritēriju, iegūtos punktus.

  1. PRETENDENTU IZSLĒGŠANAS NOTEIKUMI

    1. Iepirkuma komisija saskaņā ar Publisko iepirkumu likuma 39.1pantu 5., 6. un 7.daļu veic informācijas pārbaudi attiecībā uz Pretendentu, kuram būtu piešķiramas līguma slēgšanas tiesības. Lai izvērtētu Pretendenta (tajā skaitā, visu piegādātāju apvienības dalībnieku, apakšuzņēmēju vai visu personālsabiedrības biedru, ja konkrētajā gadījumā tādi ir) atbilstību:

      1. nolikuma 3.1., 3.2., 3.3. un 3.4. punkta prasībām, iepirkuma komisija nepieciešamo informāciju iegūst no Iekšlietu ministrijas Informācijas centra (Sodu reģistra);

      2. nolikuma 3.5. punkta prasībām, iepirkuma komisija nepieciešamo informāciju iegūst no Uzņēmumu reģistra;

      3. nolikuma 3.6. punkta prasībām, iepirkuma komisija nepieciešamo informāciju iegūst no Valsts ieņēmumu dienesta un Latvijas pašvaldībām;

    2. Gadījumā, ja Pretendentam (vai piegādātāju apvienības biedriem, vai apakšuzņēmējiem, kura sniedzamo pakalpojumu vērtība ir vismaz 20% no kopējās publiska pakalpojumu līguma vērtības, vai personālsabiedrības biedriem, vai personai, uz kuras iespējām pretendents balstās, lai apliecinātu savu kvalifikāciju), kuram būtu piešķiramas līguma slēgšanas tiesības, ir konstatēti nodokļu parādi, tajā skaitā valsts sociālās apdrošināšanas obligāto iemaksu parādi, kas kopsummā pārsniedz 150 euro, iepirkuma komisija pieprasa 10 (desmit) darba dienu laikā iesniegt attiecīgās personas vai tā pārstāvja apliecinātu izdruku no Valsts ieņēmuma dienesta elektroniskās deklarēšanas sistēmas vai pašvaldības izdotu izziņu par to, ka attiecīgajai personai laikā pēc iepirkuma komisijas nosūtītās informācijas saņemšanas dienas nav nodokļu parādu, tajā skaitā valsts sociālās apdrošināšanas obligāto iemaksu parādi, kas kopsummā pārsniedz 150 euro.

    3. Prasības ārvalstu Pretendentiem:

      1. Ārvalstu Pretendentam, kuram būtu piešķiramas līguma slēgšanas tiesības, iepirkuma komisija pieprasa iesniegt attiecīgās ārvalsts kompetentu institūciju izsniegtas izziņas, kas apliecina Pretendenta atbilstību nolikuma 3.1. līdz 3.6. punkta prasībām. Termiņu šo izziņu iesniegšanai iepirkuma komisija nosaka ne īsāku par 10 darba dienām pēc pieprasījuma izsniegšanas vai nosūtīšanas dienas. Ja attiecīgais Pretendents noteiktajā termiņā neiesniedz minētās izziņas, Pretendents tiek izslēgts no dalības Konkursā.

      2. Ja tādi dokumenti, kas apliecina ārvalstī reģistrēta vai pastāvīgi dzīvojoša Pretendenta atbilstību nolikuma 3.1. līdz 3.6. punktā noteiktajām prasībām Pretendenta reģistrācijas valstī netiek izdoti, tos var aizstāt ar zvērestu vai, ja zvēresta došanu attiecīgās valsts normatīvie akti neparedz, ar paša Pretendenta (vai piegādātāju apvienības biedriem, vai apakšuzņēmējiem, vai personālsabiedrības biedriem, vai personai, uz kuras iespējām pretendents balstās, lai apliecinātu savu kvalifikāciju) apliecinājumu kompetentai izpildvaras vai tiesu varas iestādei, zvērinātam notāram vai kompetentai attiecīgās nozares organizācijai tā reģistrācijas (pastāvīgās dzīvesvietas) valstī.

    4. Pretendents tiek izslēgts no turpmākās dalības Konkursā, ja komisija konstatē, ka:

      1. Pretendents neatbilst Konkursa nolikuma 3.punkta noteikumu prasībām;

      2. Nav iesniedzis 13.2.punktā pieprasīto informāciju iepirkuma komisijas noteiktajā termiņā.

    5. Ja Pretendents ir piegādātāju apvienība, pretendents tiek izslēgts no turpmākās dalības Konkursā, ja komisija konstatē, ka uz kādu no personām, kas iekļauta apvienībā, attiecas kāds no 13.4.punktā minētajiem izslēgšanas nosacījumiem.

    6. Ja Pretendents piesaista apakšuzņēmējus, kura sniedzamo pakalpojumu vērtība ir vismaz 20% no kopējā publiskā pakalpojuma līguma vērtības vai uz kura iespējām pretendents balstās, pretendents tiek izslēgts no turpmākās dalības Konkursā, ja komisija konstatē, ka uz kādu no šiem apakšuzņēmējiem attiecas kāds 13.4.punktā minētajiem izslēgšanas nosacījumiem.

    7. Ja Pretendents ir personālsabiedrība, Pretendents tiek izslēgts no turpmākās dalības Konkursā, ja komisija konstatē, ka uz kādu no personālsabiedrības biedriem attiecas kāds no 13.4.punktā minētajiem izslēgšanas nosacījumiem.

  2. KONKURSA UZVARĒTĀJa NOTEIKŠANA, LĪGUMa NOSLĒGŠANA

    1. Līguma slēgšanas tiesības tiks piešķirtas pretendentam, kurš ir piedāvājis nolikuma prasībām atbilstošu saimnieciski visizdevīgāko piedāvājumu katrā iepirkuma priekšmeta daļā atsevišķi.

    2. Lēmumu par Konkursa rezultātiem iepirkuma komisija pretendentiem paziņo rakstiski 3 (trīs) darba dienu laikā no lēmuma pieņemšanas dienas.

    3. Konkursa uzvarētājam, ja tas ir norādījis vēlmi saņemt priekšapmaksu, pirms līguma noslēgšanas 20 (divdesmit) dienu laikā jāiesniedz Bankas garantija priekšapmaksas maksājumam (turpmāk tekstā – Bankas garantija), kā priekšapmaksas nodrošinājums par tādu summu, kas vienāda ar priekšapmaksas maksājumu, katrā iepirkuma priekšmeta daļā atsevišķi.

    4. Bankas garantiju priekšapmaksas maksājumam var iesniegt, iesniedzot beznosacījuma Bankas garantiju atbilstoši līguma pielikumam Nr.4.

    5. Ja Iepirkuma uzvarētājs neiesniedz Bankas garantiju priekšapmaksas maksājumam 14.3. punktā noteiktajā apjomā, tas tiek uzskatīts par atteikumu no iepirkuma līguma.

    6. Priekšapmaksas Bankas garantija priekšapmaksas maksājumam tiek atsaukta tad, kad tiek izpildīti Preces izstrādes darbi izmaksātās priekšapmaksas apmērā.

    7. Iepirkuma līgums starp pasūtītāju un Konkursa uzvarētāju var tikt noslēgts saskaņā ar Publisko iepirkumu likumu nākamajā darbdienā pēc nogaidīšanas termiņa beigām. Iepirkuma līgumu sagatavo Konkursa rīkotājs, pamatojoties uz iepirkuma komisijas lēmumu par līguma slēgšanas tiesību piešķiršanu, Konkursa nolikumam pievienoto līguma projektu (pielikums Nr.5) un Konkursa uzvarētāja piedāvājumu.

    8. Konkursa uzvarētājam līgums jāparaksta 5 (piecu) darba dienu laikā no Pasūtītāja nosūtītā uzaicinājuma parakstīt līgumu izsūtīšanas dienas. Ja norādītajā termiņā uzvarētājs neparaksta līgumu, tas tiek uzskatīts par atteikumu slēgt iepirkuma līgumu un iepirkuma komisija rīkojas saskaņā ar Publisko iepirkumu likumu.

    9. Pēc Konkursa rīkotāja pieprasījuma piegādātāju apvienība, attiecībā, uz kuru, pieņemts lēmums slēgt līgumu, reģistrē personālsabiedrību saskaņā ar Konkursa nolikuma 1.6.punktu piedāvājumā norādīto atbildības apjomu Latvijas Republikas Uzņēmumu reģistra Komercreģistrā 10 (desmit) darba dienu laikā no paziņojuma par iepirkuma procedūras rezultātiem publicēšanas Iepirkumu uzraudzības biroja mājas lapā. Līgums ar piegādātāju apvienību tiek slēgts pēc Komersanta reģistrācijas apliecības (kopijas) iesniegšanas pasūtītājam. Ja 10 (desmit) darba dienu laikā no paziņojuma par iepirkuma procedūras rezultātiem publicēšanas Iepirkumu uzraudzības biroja mājas lapā personālsabiedrība netiek reģistrēta, tas tiek uzskatīts par pretendenta (piegādātāju apvienības) atteikumu slēgt iepirkuma līgumu.

  3. IEPIRKUMA KOMISIJAS TIESĪBAS UN PIENĀKUMI

    1. Komisija darbojas saskaņā ar Publisko iepirkumu likumu, Konkursa nolikumu un Centra 2014.gada 23.septembra rīkojumu Nr.640.

    2. Komisijas tiesības:

      1. rakstiski pieprasīt precizēt iesniegto informāciju un detalizētus paskaidrojumus;

      2. pārbaudīt visu pretendenta sniegto ziņu patiesumu;

      3. pieaicināt komisijas darbā ekspertus ar padomdevēja tiesībām;

      4. piedāvājumu atvēršanas sanāksmes laikā pretendentu pārstāvju klātbūtnē cauršūt pretendenta iesniegto piedāvājuma dokumentu oriģināla paketi, ja tā iesniegta necauršūta. Šajā gadījumā komisija neatbild par iesniegto dokumentu komplektāciju;

      5. pieprasīt no pretendenta informāciju par piedāvātās Preces cenas veidošanās mehānismu;

      6. noraidīt:

        1. pretendenta piedāvājumu, ja tas nav iesniegts atbilstoši nolikuma prasībām un/vai tā saturs neatbilst nolikuma prasībām un/vai pretendents iesniedzis nepatiesu informāciju sava piedāvājuma novērtēšanai vai vispār nav iesniedzis pieprasīto informāciju, tajā skaitā, nav sniedzis iepirkuma komisijas pieprasīto precizējošo informāciju iepirkuma komisijas noteiktajā termiņā;

        2. pretendenta piedāvājumu, ja pretendents maina vai papildina piedāvājumā norādīto informāciju jebkurā piedāvājuma vērtēšanas posmā.

      7. veikt citas darbības saskaņā ar Publisko iepirkumu likumu, citiem normatīvajiem aktiem un šo nolikumu.

    3. Komisijas pienākumi:

      1. izskatīt pretendentu iesniegtos piedāvājumus, kuri iesniegti noteiktajā piedāvājumu iesniegšanas termiņā;

      2. pieņemt lēmumu par Konkursa rezultātiem;

      3. veikt citas darbības saskaņā ar Publisko iepirkumu likumu, citiem normatīvajiem aktiem un šo nolikumu.

  4. PIEGĀDĀTĀJA / PRETENDENTA TIESĪBAS UN PIENĀKUMI

    1. Piegādātāja / Pretendenta tiesības:

      1. laikus pieprasīt komisijai papildu informāciju par nolikumu, iesniedzot rakstisku pieprasījumu;

      2. iesniedzot piedāvājumu, pieprasīt apliecinājumu par piedāvājuma saņemšanu;

      3. veikt citas darbības saskaņā ar Publisko iepirkumu likumu, citiem normatīvajiem aktiem un šo nolikumu.

    2. Piegādātāja / Pretendenta pienākumi:

      1. lejupielādējot Konkursa nolikumu ieinteresētais piegādātājs apņemas sekot līdzi turpmākajām izmaiņām Konkursa nolikumā, kā arī iepirkuma komisijas sniegtajām atbildēm uz ieinteresēto piegādātāju jautājumiem, kas tiks publicētas Latvijas Republikas Aizsardzības ministrijas mājas lapā xxx.xxx.xxx.xx pie Konkursa nolikuma.

      2. rakstveidā, iepirkuma komisijas norādītajā termiņā, sniegt atbildes un paskaidrojumus par piedāvājumu uz komisijas uzdotajiem jautājumiem un lūgumiem;

      3. pēc iepirkuma komisijas pieprasījuma, iepirkuma komisijas norādītajā termiņā, rakstveidā sniegt informāciju par piedāvātās Preces cenas veidošanās mehānismu;

      4. katrs pretendents līdz ar piedāvājuma iesniegšanu apņemas ievērot visus Konkursa nolikumā minētos noteikumus kā pamatu iepirkuma izpildei;

      5. veikt citas darbības saskaņā ar Publisko iepirkumu likumu, citiem normatīvajiem aktiem un šo nolikumu.

  5. PĀRĒJIE NOTEIKUMI

    1. Iepirkuma komisija un piegādātājs / pretendents ar informāciju apmainās rakstiski. Mutvārdos sniegtā informācija iepirkuma procedūras ietvaros nav saistoša.

    2. Visi izdevumi, kas saistīti ar Konkursa piedāvājuma sagatavošanu un iesniegšanu, jāsedz Konkursa pretendentam.

    3. Centra adreses maiņas gadījumā informācija būs pieejama Aizsardzības ministrijas mājas lapā xxx.xxx.xxx.xx.

    4. Konkursa nolikums sastādīts un apstiprināts latviešu valodā uz 110 (viens simts vienpadsmit) lapām. Nolikums sastāv no nolikuma teksta uz 30 (trīsdesmit) lapām un 5 (pieciem) pielikumiem uz 79 (septiņdesmit deviņas) lapas, kas ir šī nolikuma neatņemama sastāvdaļa:

  1. pielikums – Konkursa pieteikums uz 2 (divām) lapām.

  2. pielikums – Apliecinājums par pieredzi uz 2 (divām) lapām.

  3. pielikums - Tehniskā specifikācija uz 65 (sešdesmit piecām) lapām.

  4. pielikums – Tehniskais piedāvājums uz 1 (vienas) lapas.

  5. pielikums - Līguma projekts uz 9 (deviņām) lapām.

Komisijas priekšsēdētājs: X.Xxxx

Pielikums Nr. 1

Konkursa, identifikācijas Nr.171, nolikumam


PIETEIKUMS


Piezīme: Konkursa pretendentam jāaizpilda tukšās vietas šajā formā.



Iepirkums: Tehniskā risinājuma prototipa izstrāde AnNa (VILDA) projekta ietvaros

Identifikācijas Nr. VAMOIC 2014/171


Kam: Valsts aizsardzības militāro objektu un iepirkumu centrs

Xxxxxxxxxx xxxx 00,

Rīga, LV-1046,

Latvija


Godātā komisija,


  1. Saskaņā ar Konkursa nolikumu, mēs, apakšā parakstījušies, apstiprinām, ka piekrītam Konkursa noteikumiem. Saskaņā ar nolikuma prasībām, piedāvājam izstrādāt šādu Preci par kopēju summu:

Iepirkuma daļa



Iepirkuma priekšmets

Cena EUR bez PVN



PVN

Cena EUR ar PVN

I daļa

Prototipa izstrāde "Automātiskai, vienotai datu apmaiņas saslēguma izstrādei starp ES dalībvalstīm ostas formalitāšu un kuģošanas drošības datu apmaiņai””




II daļa

Datu pārraides tīkla modeļa prototipa izveide Rīgas jūras līcī (I-CaDE);




III daļa

Automatizētā risinājuma izstrāde, kuģošanas informācijas un ostu formalitāšu datu atpazīšanai




IV daļa

Kuģošanas informācijas un ostu formalitāšu datu konvertēšanas un apmaiņas moduļa izstrāde





  1. Ja pretendents ir piegādātāju apvienība:

4.1. personas, kuras veido piegādātāju apvienību (nosaukums, reģ. Nr., juridiskā adrese):

4.2. katras personas atbildības apjoms:

  1. Ja pretendents ir piesaistījis apakšuzņēmējus:

    1. apakšuzņēmēja nosaukums, reģ. Nr., juridiskā adrese: ______

    2. apakšuzņēmējam nododamās līguma daļas apjoms ___________________

_____________________________________________________________________

  1. Mēs piekrītam Konkursa nolikumam pievienotā līguma projekta noteikumiem.

  2. Mēs apstiprinām, ka pievienotie dokumenti veido šo piedāvājumu.

  3. Ir nepieciešama / nav nepieciešama (nevajadzīgo svītrot) priekšapmaksa ____% (ne vairāk kā 50 %) apmērā no pasūtījuma apjoma.

  4. Informācija par pretendentu vai personu, kura pārstāv piegādātāju apvienību Konkursā:


Pretendenta nosaukums: _____________________________________________

Reģistrēts:_________________________________________________________

ar Nr. ____________________________________________________________

Juridiskā adrese:____________________________________________________

Biroja adrese: ______________________________________________________

Kontaktpersona: ____________________________________________________

(vārds, uzvārds, amats)

Telefons: __________________________________________________________

Fakss: ____________________________________________________________

E-pasta adrese: _____________________________________________________

Nodokļu maksātāja reģistrācijas Nr.: ____________________________________

Banka: ____________________________________________________________

Kods: _____________________________________________________________

Konts: ____________________________________________________________

Telefons: __________________________________________________________


Ar šo uzņemos pilnu atbildību par Konkursā iesniegto dokumentu komplektāciju, tajos ietverto informāciju, noformējumu, atbilstību nolikuma prasībām. Sniegtā informācija un dati ir patiesi.



Piedāvājuma dokumentu pakete sastāv no _________ (_____________) lapām.

Paraksts: __________________________________

Vārds, uzvārds: ____________________________

Amats: ___________________________________


Pieteikums sastādīts un parakstīts 2014.gada _______________________

z. v.


Pielikums Nr. 2.1.

Konkursa, identifikācijas

Nr. VAMOIC 2014/171, nolikumam


APLIECINĀJUMS PAR XXXXXXXX

Pretendenta nosaukums: _______________________________________________
Reģistrēts: __________________________________________________________

ar Nr. ______________________________________________________________


2. Mūsu darbības pēdējo trīs kalendāro gadu laikā realizēti šādi projekti:


Līguma slēgšanas gads

Pasūtītājs (juridiskās personas nosaukums, kontaktpersona, tālrunis, e-pasta adrese)

Pakalpojuma līguma nosaukums

Tehnoloģiskā risinājuma īss apraksts

Projekta izpildes laiks
























Pielikums Nr. 2.2.

Konkursa, identifikācijas

Nr. VAMOIC 2014/171, nolikumam


APLIECINĀJUMS PAR XXXXXXXX

(Pretendenta darbinieku, kuri tiks iesaistīti projekta izstrādē, pieredze)


Vārds, Uzvārds

Specializācija/ loma projekta ralizācijā

Projekta nosaukums un norāde uz publikāciju (izpētes un zinātniskajā projektā/ (īss apraksts)

Projeta apjoms, Eiro bez PVN

Pakalpojuma/ projekta pasūtītājs


























Ar šo uzņemos pilnu atbildību par apliecinājumā ietverto informāciju un tās atbilstību nolikuma prasībām.

Paraksts:

Vārds, uzvārds:

Amats:

Apliecinājums sastādīts un parakstīts 2014.gada __________________

Pielikums Nr. 3.1.

Konkursa, identifikācijas

Nr. VAMOIC 2014/171, nolikumam

TEHNISKĀ SPECIFIKĀCIJA


„Prototipa izstrāde „Automātiska, vienota datu apmaiņas saslēguma izstrādei starp ES dalībvalstīm ostas formalitāšu un kuģošanas drošības datu apmaiņai”


Saturs:





Vispārīga informācija par iepirkuma priekšmetu

Mērķis: nacionālo vienoto logu sistēmu savstarpējās datu apmaiņas iespēju izpēte un tehniskā risinājuma prototipa izstrāde, integrējot to ar Latvijas nacionālajām sistēmām SKLOIS (tiek izstrādāta) un tās bāzes sistēmu SSN.

Rezultāts: ar SKLOIS/SSN integrēts tehniskais prototips un saistītā dokumentācija.

Izmantotie termini:

KAD

Jūras spēku flotile Krasta apsardzes dienests

AnNa

Attīstīti valstu pārvaldes iestāžu tīkli

MSW

Jūrniecības vienotais logs

NSW

Nacionālais Jūrniecības vienotais logs

VILDA

Vienots informācijas logs jūrniecības un loģistikas datu administrēšanai

EMSA

Eiropas Jūras drošības aģentūra

ES

Eiropas Savienība

FAL

Konvenciju par starptautiskās jūras satiksmes atvieglošanu

SKLOIS

Starptautiskā kravu loģistikas un ostu informācijas sistēma

SSN

Kuģu satiksmes uzraudzības un informācijas datu apmaiņas sistēma

ES SSN

Eiropas Jūras drošības aģentūras uzturētā SafeSeaNet sistēma

MIG

Ziņojuma ieviešanas vadlīnijas


Dokumenta lietotāji

Tehniskā specifikācija ir paredzēta šādām lietotāju grupām:

  1. Pasūtītājam Jūras spēku flotiles Krasta apsardzes dienests (turpmāk – KAD) – iepirkuma procedūras organizēšanai, pretendentu piedāvājumu novērtēšanai, līguma izpildes kontrolei;

  2. Pretendentiem (izpildītājam) - piedāvājuma sagatavošanai, kā sākotnējais materiāls Projekta plānošanai, analīzes veikšanai un detalizētās programmatūras prasību specifikācijas sagatavošanai.



    1. Esošās situācijas raksturojums

Latvijai, pildot Direktīvas 2010/65/ES prasības, līdz 2015.gada 1.jūnijam ir jārealizē vienas pieturas aģentūras princips. Nacionālo Bruņoto spēku Jūras spēku Flotiles Krasta apsardzes dienesta uzturētā Kuģu satiksmes uzraudzības un informācijas datu apmaiņas sistēma (SSN) kopā ar jaunveidojamo Starptautisko kravu loģistikas un ostu informācijas sistēmu (SKLOIS) ir Latvijas vienas pieturas aģentūras risinājuma pamats. SSN attīstību nosaka Ministru kabineta (turpmāk – MK) 2009.gada 4.augusta noteikumi Nr.857 „Kārtība, kādā nodrošināma sakaru tīklu darbība Kuģu satiksmes uzraudzības un informācijas datu apmaiņas sistēmas ietvaros” un MK 2012.gada 15.maija noteikumi Nr.339 „Noteikumi par ostu formalitātēm”. SKLOIS projekta ietvaros ir paredzēts aktualizēt iepriekš minētos normatīvos aktus. Abi minētie MK noteikumi nacionālā līmenī transponē minēto Direktīvu 2010/65/ES.

Latvijas dalības XXXX MSW projekta virsmērķis ir veicināt aktīvu sadarbību starp ES dalībvalstīm un izstrādāt atbilstošus mehānismus, lai atvieglotu un harmonizētu ziņošanas formalitātes nacionālā un ES dalībvalstu līmenī.

XXXX MSW projekta mērķi ir:

- Sekmēt Direktīvas 2010/65/ES ieviešanu, stiprināt Eiropas ostu un jūras transporta konkurētspēju pasaules mērogā;

- Sekmēt visu iesaistīto pušu dalību vienotā elektroniskā informācijas telpā;

- Izveidot saskaņotu pieeju un efektīvu sadarbību starp privāto un publisko sektoru;

- Dalībvalstīs sekmēt bottom-up pieeju, lai realizētu vienas pieturas aģentūras projektu;

- Izveidot sistēmu, kas sekmētu savietojamību starp datu sniedzējiem, publisko sektoru un loģistikas ķēžu operatoriem.

Aizsardzības Ministrija (turpmāk - AM) ir sagatavojusi izpētes un attīstības projektu „Vienots informācijas logs jūrniecības un loģistikas datu administrēšanai” (turpmāk - VILDA). VILDA paredz pētīt un izveidot vienotu telpu datu apmaiņai jūrniecības un loģistikas informācijai gan nacionālā, gan ES līmenī, saskaņā ar ES Direktīvas 2010/65/ES prasībām.

VILDA projekta ietvarā tiks realizēti četri apakšprojekti, kas nodrošinās vienas pieturas aģentūras principu visos trīs līmeņos datu iesniegšanai, apstrādei un apmaiņai nacionālā un ES līmenī:

- 1.apakšprojekts: Vienas pieturas aģentūras princips ar vienotu grafisko saskarni datu apmaiņai (NaMSW). Apakšprojekta mērķis ir pilnveidot nacionālo SSN sistēmu līdz vienas pieturas aģentūras līmenim nodrošinot Direktīvas 2010/65/ES ieviešanu sadarbībai starpinstitūciju līmenī (Mid Office). Apakšprojektā paredzētās aktivitātes ir vienotas grafiskās saskarnes izveidošana vienotam informācijas logam. Datu apmaiņa ar XXXX MSW projekta dalībvalstīm pēc Pull/Push principa. Pētīt un realizēt drošu datu apmaiņu starp nacionālām institūcijām un ES dalībvalstīm.;

- 2. apakšprojekts: Uzlaboti sakari un datu apmaiņa (I-CaDE). Apakšprojekta mērķis ir pilnveidot komunikāciju un uzlabot datu plūsmas principus, padarot lietotājiem pieejamākus vienas pieturas aģentūras elementus. Apakšprojekta realizācijas laikā tiks pētīta iespēja uzlabot sakaru un datu apmaiņas principus starp vienotu informācijas logu un tā tiešajiem datu un informācijas sniedzējiem – kuģiem. Apakšprojekta eksperimentālajā fāzē sakaru un datu tīkla darbības pierādīšanai tiek plānots izmantot KAD krasta infrastruktūru un iesaistīt kuģus, kas kuģo uz/no Latvijas ostām un NBS kuģus, kas nodrošina krasta apsardzes funkciju veikšanu atbildības rajonā. Projekts paredz uzlabot vienas pieturas aģentūras darbības principus, kā arī kopumā uzlabot kuģošanas drošību un drošumu;

- 3. apakšprojekts: Uzlabota datu kvalitāte kuģošanas režīma uzraudzībai (I-DatQ). Apakšprojekta mērķis ir pētīt un praksē pierādīt iespēju pilnveidot kuģu sniegto datu kvalitātes kontroles mehānismus, nodrošinot Direktīvas 2010/65/ES prasību izpildi. Projekta ietvaros paredzēts modelēt instrumentu datu uzraudzībai, sistemātiskas un automatizētas kontrolpārbaudes veikšanai, atvieglot administratīvās procedūras gan valsts iestādēm, gan uzņēmējiem. Uzlabotā kontroles sistēma ļaus KAD, kā atbildīgai institūcijai par datu kvalitāti un datu apmaiņu ar ES dalībvalstīm, ikdienā nodrošināt visefektīvāko datu kontroles metožu izmantošanu;

- 4. apakšprojekts: Inteliģents datu tulkošanas modulis vienas pieturas aģentūras principa atbalstam (InDTra). Apakšprojekta mērķis ir izstrādāt un praksē pierādīt vienas pieturas aģentūras inteliģentā moduļa darbību, kas nodrošinās datu apstrādi: tulkošana, sinhronizācija un maršrutēšana vienotā informācijas loga lietotājiem, nodrošinot tiešsaisti ar informācijas sniedzējiem, kas izmanto atšķirīgus datu iesniegšanas standartus (piemēram, kuģi, kas nepakļaujas ES normatīvo aktu prasībām par datu aprites standartiem). Apakšprojektā paredzētās aktivitātes ir datu apstrādes moduļa izstrāde, testēšana un saslēgšana ar SSN sistēmu, pilnveidojot vienota informācijas loga darbību un samazinot administratīvo slogu gan valsts iestādēm, gan uzņēmējiem.


    1. Konkrētā iepirkuma mērķis

VILDA apakšprojekta „Automātiska, vienota datu apmaiņas saslēguma izstrādei starp ES dalībvalstīm ostas formalitāšu un kuģošanas drošības datu apmaiņai” (turpmāk - NSW2NSW) mērķis ir nodrošināt efektīvu un pārskatāmu datu (ziņojumu) apmaiņu starp dalībvalstu NSW sistēmām, izveidojot vienotu ziņojumu apmaiņas struktūru. Apakšprojekta izveide tiks veikta balstoties uz jau esošiem rezultātiem, kas sasniegti TEN-T AnNAa projekta ietvarā par centrāla tīkla izveidi starp četrpadsmit dalībvalstu (Beļģijas, Bulgārijas, Grieķijas, Francijas, Itālijas, Kipras, Latvijas, Lielbritānijas Nīderlandes, Portugāles, Rumānijas, Slovēnijas, Spānijas, Zviedrijas) krasta apsardzes dienestiem datu apmaiņai, tādā veidā sekmējot ES Direktīvas 2010/65/ES ieviešanu.

Datu apmaiņas sistēmai ir jābūt savietojamai ar jaunākajām IT tehnoloģijām, kā arī pēc iespējas jābūt veidotai tā, lai spētu pilnvērtīgi funkcionēt (pielāgoties) IT tehnoloģiju attīstības tendencēm.

Apakšprojekta (NSW2NSW) īstenošana paredzēta līdz 2015.gada 1.jūnijam.


Vispārējs darba uzdevums un termiņi

Vispārējs apraksts

Katras AnNa MSW projekta dalībvalsts NSW uzbūves pamatā ir XML ziņojumu sistēma, kas darbojas kā drošs un uzticams „push & pull” mehānisms (sevī ietver autentifikāciju, validēšanu, datu pārveidošanu) ziņojumu un atbilžu nosūtīšanai (push) un saņemšanai (pull) no noteiktās dalībvalsts. Datu apmaiņas risinājums izmanto divpusēju SSL komunikāciju starp centrālo sistēmu un dalībvalsts sistēmu, bet atbilstošo XML ziņojumu struktūras ir daļēji izstrādātas „Message Implementation Guide” (turpmāk tekstā - MIG) projekta ietvaros (projektu attīsta un pārvalda Nīderlandes valsts speciālisti).

Ziņu apmaiņas risinājumā ietilpst apmaiņas programmatūra starp dalībvalstu NSW servisiem. Dalībvalstis un to vietējās aģentūras darbosies kā datu nosūtītājas (sūtot ziņojumus uz nākamo ostu un atbildot uz datu pieprasījumu no citiem NSW datu pieprasītāju uzdevumā) un datu saņēmējas (pieprasot NSW detalizētu informāciju par iepriekšējiem ziņojumiem). NSW komunikācijai tiks izmantota uz XML ziņojumu balstīta saskarne, pamatojoties uz iepriekšēju, savstarpēju vienošanos starp projekta NSW2NSW dalībniekiem (attiecas uz piemērojamām datu struktūrām). XML ziņojumu apmaiņas risinājums tiks balstīts uz standarta protokoliem (XML; HTTPS).

Iepirkuma mērķis ir izstrādāt XML ziņojumu sistēmas apmaiņas servisa prototipu, kas darbojas izmantojot XML dokumentu/ziņojumu apmaiņu uzticamā, drošā un organizētā (saskaņotā) veidā saskaņā ar šajā specifikācijā noteiktajām prasībām.

Projekta realizēšana ietver sekojošas kārtas:

1. Datu struktūru pilnveidošana (AnNa MIG paredzētās informācijas nosūtīšanai, saņemšanai, analizēšanai un izsekošanai (caur ziņojumu apmaiņas servisu) izmantojot standarta XML protokolus);

2. Datu apmaiņas procesu definēšana, nodrošinot iespēju veidot stabilus, ilgtspējīgus, cieši integrētus biznesa procesus, kas apvieno organizācijas, platformas un aplikācijas, un ņemot vērā potenciālās izmaiņas nacionālajos tiesību aktos;

3. Augstu pieejamības un mērogojamības datu apmaiņas pilot-risinājuma izstrāde, balstoties uz KAD rīcībā esošo un SKLOIS projekta ietvaros iegādājamo standarta programmatūru un infrastruktūru;

4. Pilot-risinājuma integrēšana esošajās SKLOIS/SSN sistēmās, tā testēšana un testēšanas rezultātu novērtēšana;

5. demonstrācijas un pieredzes pārneses aktivitātes (uzturēšanas un attīstīšanas dokumentācijas izstrāde).

      1. Atbilstība tiesību aktiem

Prototipa izveides un piegādes ietvaros, Izpildītājam ir jāņem vērā šādi saistošie tiesību akti:

      • FAL Konvencija par starptautiskās jūras satiksmes atvieglošanu;

      • Jūrlietu pārvaldes un jūras drošības likums;

      • Informācijas atklātības likums;

      • Dokumentu juridiskā spēka likums;

      • Elektronisko dokumentu likums;

      • 2013. gada 17. decembra Ministru Kabineta sēdes protokols Nr.67, 86.§Informatīvais ziņojums „Par papildu valsts budžeta saistību uzņemšanos Kuģu Satiksmes uzraudzības un informācijas datu apmaiņas sistēmas pilnveidošanai un Direktīvas 2010/65/ES ieviešanai”

      • Ministru kabineta 2010.gada 28.septembra noteikumi Nr. 916 „Dokumentu izstrādāšanas un noformēšanas kārtība”;

      • Ministru kabineta 2005.gada 28.jūnijā noteikumi Nr. 473 „Elektronisko dokumentu izstrādāšanas, noformēšanas, glabāšanas un aprites kārtība valsts un pašvaldību iestādēs un kārtība, kādā notiek elektronisko dokumentu aprite starp valsts un pašvaldību iestādēm vai starp šīm iestādēm un fiziskajām un juridiskajām personām”;

      • Ministru kabineta 2010. gada 13. aprīlī noteikumi Nr.357 „Kārtība, kādā iestādes sadarbojoties, sniedz informāciju elektroniskā veidā, kā arī nodrošina un apliecina šādas informācijas patiesumu”;

      • 2009. gada 4. augusta Ministru kabineta noteikumi Nr. 857 „Kārtība, kādā nodrošināma sakaru tīklu darbība Kuģu satiksmes uzraudzības un informācijas datu apmaiņas sistēmas ietvaros”

      • 2012. gada 15. maija Ministru kabineta noteikumi Nr.339 „Noteikumi par ostu formalitātēm”

      • Eiropas Parlamenta un Padomes 2002.gada 27.jūnija Direktīvas 2002/59/EK, ar ko izveido Kopienas kuģu satiksmes uzraudzības un informācijas sistēmu un atceļ Padomes Direktīvu 93/75/EEK;

      • Eiropas Parlamenta un Padomes 2009.gada 23.aprīļa Direktīvas 2009/17/EK, ar kuru groza Direktīvu 2002/59/EK, ar ko izveido Kopienas kuģu satiksmes uzraudzības un informācijas sistēmu;

      • Eiropas Parlamenta un Padomes 2010. gada 20. oktobra Direktīvas 2010/65/ES par ziņošanas formalitātēm kuģiem, kuri ienāk dalībvalstu ostās un/vai iziet no tām, un ar ko atceļ Direktīvu 2002/6/EK.

      • Šis „Automātiska, vienota datu apmaiņas saslēguma izstrādei starp ES dalībvalstīm ostas formalitāšu un kuģošanas drošības datu apmaiņai (NSW2NSW)” apakšprojekta darba uzdevums „Terms of Reference”, kas ir vienots ar projekta dalībniekiem ir neatliekama sastāvdaļa un šī Prototima izstrādes procesā Piegādātājam ir jāievēro darba uzdevumu „Terms of Reference” noteiktās prasības.

Darbu izpildes termiņi

Pirmā un otrā kārtas veicamas paralēli, bet visas pārējās – secīgi pēc abu šo kārtu pabeigšanas (uzsākot katru pēc iepriekšējās pabeigšanas). Zemāk norādīti termiņi katras kārtas nodevumu iesniegšanai saskaņošanas uzsākšanai (skaitot no posma uzsākšanas dienas). Katra kārtas nodevumu saskaņošana tiks veikta ne ilgāk kā 5 darba dienu laikā.

Kārtas (posma) nr.

Nodevumu iesniegšanas termiņš / nodevumi

1.

12 nedēļas / XSD shēmas

2.

12 nedēļas / Komunikācijas shēma

3.

12 nedēļas / Programmatūra (prototips)

4.

8 nedēļas / Programmatūra (integrēta SKLOIS/SSN)

5.

2 nedēļas / Uzturēšanas un attīstīšanas vadlīnijas


Detalizēts darba uzdevums

Pārsūtāmo datu apjoms un atbalstāmie procesi

Apakšprojekta NSW2NSW realizācijas ietvaros paredzēts izveidot datu apstrādes un apmaiņas moduļa prototipu starp projekta dalībniekiem (turpmāk tekstā - prototips). Prototips paredzēts, lai atvieglotu un uzlabotu kuģošanas nozares (specifiski - starptautiskajā jūras satiksmē iesaistītajiem kuģiem) informācijas sistēmu savstarpējo datu apmaiņu NSW – NSW un nodrošina, ka netiek radīta administratīvā barjera dokumentu apstrādei. Datu apmaiņai un NSW – NSW izmanto vienotu strukturētu datni. Datnē ievadāmais datu apjoms nodrošinās vienreizēju datu iesniegšanu, kas nepieciešama noteikto ostas formalitāšu ziņošanai, saskaņā ar Konvenciju par starptautiskās jūras satiksmes atvieglošanu (FAL konvencijā), ES un nacionālajiem normatīvajiem aktiem. Tiks nodrošinātas funkcijas, kas saistās ar XML datu formāta atvieglotu nosūtīšanu, saņemšanu un apmaiņu starp apakšprojekta dalībvalstu NSW.

Par pamatu XML formāta datu apmaiņai ar pārējām projekta dalībvalstīm tiek ņemta MIG (Message Implementation Guide) projektā izstrādātā ziņojumu apmaiņas struktūra (vadlīnijas). Apakšprojekta NSW2NSW dalībvalstis XML ziņojumu apmaiņas procesā piedalās kā datu nosūtītāji (sūtot ziņojumus citām NSW un atsaucoties uz datu pieprasījumu no citas dalībvalsts NSW) un datu pieprasītāji (pieprasot citas dalībvalsts NSW sniegt detalizētu informāciju par iepriekšējiem ziņojumiem).

NSW2NSW prototipam jāaptver šādi biznesa procesi:

  1. process: Datu nosūtīšana. NSW2NSW dalībvalsts kā datu nosūtītāja nodrošina sekojošus ziņojumus saturošus informāciju par noteiktu kuģi vai ar to saistītiem negadījumiem attiecīgajai dalībvalsts NSW kura informāciju pieprasījusi:

Ziņojuma veids

Apraksts

PortPlus (Push)

Ziņojums tiek nosūtīts, lai paziņotu NSW:

  • kuģu vizītes plānošana un darbības 72 st. pirms ienākšanas ostā;

  • kuģu vizītes plānošana un darbības 24 st. pirms ienākšanas ostā;

  • kuģa faktisko pienākšanas laiku ostā;

  • kuģa faktisko atiešanas laiku ostā;

  • HAZMAT (ziņošana par bīstamu un piesārņojošu kuģa kravu);

  • drošības informācijas ziņojums 24 st. pirms kuģa ienākšanas ostā;

  • ziņojums par kuģa atkritumiem 00 xx. pirms kuģa ienākšanas ostā.

No minētajiem uz NSW2NSW komunikāciju attiecas uz PortPlus ziņojumi. Datu apjomu nosaka aktuālā ANNA MIG versija (tajā paredzētais datu apjoms).


  1. process: Datu saņemšana. NSW2NSW dalībvalsts kā datu saņēmēja piedalās kā datu pieprasītāja:

Ziņojuma veids

Apraksts

PortPlus (Pull)

Detalizētas informācijas saņemšana par noteiktu kuģi. Pieprasītās dalībvalsts NSW pieprasa faktisko datu turētāju nodrošināt NSW detalizētu informāciju. Pieprasītās dalībvalsts NSW nosūta detalizētu informāciju atpakaļ datu pieprasītāja NSW.

No minētajiem uz NSW2NSW komunikāciju attiecas uz PortPlus ziņojumi. Datu apjomu nosaka aktuālā ANNA MIG versija (tajā paredzētais datu apjoms).



  1. process: Kuģu maršruta maiņa. NSW2NSW ziņojumu apmaiņas sistēma automatizēti nosūta kuģa maršruta maiņas ziņojumu starp NSW2NSW dalībvalstīm. Kuģa maršruta maiņas gadījumā kuģis nosūta „maršruta maiņas ziņojumu” iepriekš plānotai vizītes ostai ar ziņojumu par maršruta maiņu ar norādi, uz kuru ostu maršruts ir nomainīts. Atceltās vizītes osta nosūta atpakaļ kuģa iziešanas ostai „ostas vizītes atcelšanas ziņojumu” kurā ir iekļauta informācija par nomainītās ostas informācija. Datu apjomu nosaka aktuālā ANNA MIG versija (tajā paredzētais datu apjoms).



  1. process: Ziņojumu apmaiņa process. Pēc autorizēta ziņojumu pieprasījuma dalībvalsts NSW nosūta ziņojumu pieprasījumu visām NSW2NSW projekta dalībvalstu NSW, tā kā katra dalībvalsts vienlaicīgi darbojas kā datu pieprasītājs un nosūtītājs. Kā datu nosūtītājs katras dalībvalsts NSW nosūta tai pieejamo informāciju par iepriekšējiem ziņojumiem pieprasītāja dalībvalsts NSW. Datu apjomu nosaka aktuālā ANNA MIG versija (tajā paredzētais datu apjoms).



  1. process: Ziņojumu apstrāde. Lietotāja iesniegto dokumentu vai datu papildināšana, atjaunošana vai atcelšana. Datu apjomu nosaka aktuālā ANNA MIG versija (tajā paredzētais datu apjoms).

Prototipa testēšanas fāzē tiek pārbaudīta datu apmaiņa, NSW – NSW, tā, lai NSW sistēma tiek pārsūtīti noteikti ostu formalitāšu dokumenti, saskaņā ar tabulām Tab.1 un Tab.2:

Dokuments

Atšifrējums

FAL 1. veidlapa

Vispārīgā deklarācija

FAL 2.veidlapa

Kuģa manifests

FAL 3.veidlapa

Kuģa krājumu deklarācija

FAL 4. veidlapa

Apkalpes mantu deklarācija

FAL 5. veidlapa

Apkalpes saraksts

FAL 6. veidlapa

Pasažieru saraksts

HAZMAT

Paziņošana par bīstamu un piesārņojošu kuģa kravu

Paziņošana par kuģa atkritumiem

Paziņojumu par atkritumu nodošanu

Aizsardzības informācijas deklarācija

Aizsardzības informācijas deklarācijas iesniegšana

Veselības deklarācija

Paziņojums par kuģa sanitārās un apkalpes veselību

Paziņošana par personu, kas nokļuvusi un uzturas uz tā nelegāli

Paziņošana par personām, kas nokļuvušas un uzturas uz kuģa nelegāli


Izstrādātajam risinājumam ir savietojams ar SKLOIS/SSN sistēmu, tādā mērā, lai kuģa iesniegtie dati tiktu uzskatīti par līdzvērtīgiem tādiem datiem, ko iesniedz kuģa aģents. Informācijas nosūtīšana tiek nodrošināta divos virzienos: no prototipa uz SKLOIS/SSN tiek nosūtīts datu kopums ar ostu formalitātēm, savukārt SKLOIS/SSN sniedz atbildi prototipam par ostas formalitāšu pieņemšanu, ka arī informāciju par datu noraidīšanu/apstiprināšanu/komentēšanu.

Galvenās prototipa funkcijas

NSW2NSW sistēmas funkcionalitātes ir ziņojumu nosūtīšana, saņemšana, glabāšana, meklēšana un apmaiņa.

Galveno funkcionalitātes raksturojums:

  • Nosūtīt (Push) ziņojumus;

Dalībvalsts NSW sistēma sagatavo XML ziņojumu atbilstoši ziņojuma veidam un nosūta pieprasītāja dalībvalsts NSW. Pieprasītāja dalībvalsts NSW reģistrē un apstiprina ziņojumu. Gadījumā ja XML ziņojums ir derīgs (bez kļūdām) ziņojuma informācija tiek saglabāta pieprasītāja valsts NSW, un pozitīvs ziņojuma statusa kods (apstiprinājums) tiek nosūtīts atpakaļ nosūtītājam. Kļūdaina ziņojuma gadījumā nosūtītājam tiek nosūtīts atpakaļ ziņojums ar negatīvu statusa kodu.

  • pieprasīt (Pull) ziņojumus;

NSW meklēšanas parametri nodrošina iespēju pieprasīt PortPlus ziņojumu detaļas dažādās kuģa atrašanās pozīcijās (sagaidāmā ostas vizīte, kuģa ierašanās laiks, kuģa atiešanas laiks, pašreizējā kuģa situācija).

  • atcelt un novirzīt ziņojumus;

Kuģa maršruta maiņas gadījumā starp valstīm atcelt ostu vizīti un novirzīt ziņojumus par kuģa maršruta izmaiņu ostām.

Kā arī tiks izstrādātas sistēmas funkcionalitātes vadlīnijas lietotāju atbalstam un ieviesta ziņojumu validācija, kuru būs nepieciešams ievērot projekta dalībniekiem atbilstošās informācijas attēlošanai.

Specifiskas tehniskās prasības

      1. Darbības režīms un servisu pieejamība

Sekojoši noteikumi ir jāņem vēra īstenojot NSW2NSW:

  • Ziņojumu apmaiņa starp dalībvalstu NSW tiek īstenota asinhronā veidā, kad vienas dalībvalsts NSW dalībnieks sūtot XML ziņojumu (ziņojumu, pieprasījumu vai atbildi) caur HTTPS uz citas dalībvalsts NSW pēdējais tikai atbild ar HTTP ‘202 Akceptētu’ statusa kodu. Šāda darbība noris abos virzienos;

  • Katras dalībvalsts NSW tiek veidots, ņemot vērā iespējamas sakaru un serveru problēmas. Galvenais noteikums cik vien ilgi XML ziņojums (pieprasījums vai atbilde) nav apstiprināts ar HTTP ‘202 Akceptētu’ statusa kodu ziņas nosūtītāja pārziņā ir ziņojuma atkārtota pārsūtīšana ar maksimālu pārsūtīšanas reižu skaitu. XML ziņojumu apmaiņas sistēmai ir jābūt izveidotai tā, lai tā būtu spējīga risināt šādu nenosūtītu ziņojumu gadījumus;

  • Katras projekta dalībvalsts NSW sistēmai XML ziņojumu nosūtīšanai un saņemšanai ir jānodrošina vienota adrese (URL) izmantojot „push & pull mehānizmu”.

      1. Ziņojumu apmaiņas drošība

Ziņojumu apmaiņas drošības nodrošināšanai jāievēro sekojoši noteikumi:

  • Datu pārsūtīšanai ir jābūt īstenotai ar HTTPS ar 2-way SSL autentifikāciju vai drošības ziņā ekvivalentu risinājumu;

  • Serverim, kas tiek izmantots XML saskarnes izmitināšanai, kā arī dokumentu glabāšanai, kas tiks augšupielādēti (ja tādi tiks paredzēti), ir jābūt apgādātam ar derīgu klienta un servera sertifikātu. kuru izsniedz deleģēta valsts vai Latvija kā projektu koordinējošā valsts;

  • Dalībvalstu NSW (MD5/SHA algoritms) minimālā drošības līmeņa piekļuves obligātā prasība ir šifrētas, stingrās paroles izmantošana;

  • Dalībvalstu NSW sistēmu aizsardzībai ir jāizmanto aizsardzības instrumentu kopums nesankcionētas ielaušanās novēršanai (var tik izmantoti standarta risinājumi);

  • Katrai NSW tiek izmantoti lietotāju validācijas/autentifikācijas digitālie sertifikāti (atbilstoši X.509v3 standartam).

      1. Lomas

Projekta izstrādes Piegādātājam ir jānosaka vadlīnijas lietotāju piekļuves tiesību organizēšanai (konkrētu ziņojumu / darbību veidu pieejamība atkarībā no lomas), paredzot šādas lomas:

  • Krasta apsardzes dienests,

  • Ostas pārvaldes,

  • Latvijas Jūras administrācija,

  • Valsts vides dienests,

  • Valsts robežsardze,

  • Valsts ieņēmumu dienesta muitas iestādes,

  • Pārtikas un veterinārais dienests,

  • Veselības inspekcija,

  • Slimību profilakses un kontroles centrs,

  • Valsts ugunsdzēsības un glābšanas dienests,

  • Valsts policija,

  • Drošības policija,

  • Transporta nelaimes gadījumu un incidentu izmeklēšanas birojs,

  • Xxxxx (kapteinis, īpašnieks, valdītājs, aģents),

  • Kravas īpašnieks, valdītājs vai kravas aģents,

  • Komercsabiedrība, kas ostā pieņem un apsaimnieko kuģu radītos atkritumus,

  • Komercsabiedrība, kas sniedz citus pakalpojumus ostā.

Izstrādājot lietotāju piekļuves tiesību vadlīnijas dalībvalstu NSW sistēmās, Piegādātājam ir jāņem vērā sistēmas lietotāja lomas un piekļuves tiesības, kuras nosaka NSW sistēmas administrators, kam ir tiesības noteikt piekļuves ierobežojumu atbilstoši ES vai nacionālajiem normatīvajiem aktiem. Piekļuve NSW sistēmai tiek kontrolēta ar formālu lietotāja reģistrācijas procesu, kur katram lietotājam tiek piešķirts unikāls lietotāja ID (identifikācija) lietotāju darbību sistēmā uzraudzības nodrošināšanai.

      1. Validācijas

Izstrādātājam jānosaka ziņojumu apmaiņas sistēmas validācijas principi. XML ziņojumu apmaiņas sistēmā jāizveido automātiska datu kvalitātes pārbaude un procedūras ar mērķi:

  • Novērst kļūdainu datu ievadīšanu NSW. Pirms datu nosūtīšanas uz kādas dalībvalsts NSW nosūtītāja dalībvalsts NSW veic pilnu datu pārbaudes kopumu balstītu uz projekta izstrādes pretendenta izstrādātajiem noteikumiem (t.i., - implementē MIG paredzētās validācijas), kas nodrošina datu validāciju pirms ziņojuma reģistrēšanas sistēma un kļūdaina ziņojuma gadījuma nosūta atbildi atpakaļ nosūtītājas dalībvalsts NSW par kļūdainu ziņojumu.

  • Datu pārbaudes procesa laikā nosūtītāja dalībvalsts NSW pārliecinās, ka ziņojums atbilst saņēmēja prasībām un gadījumā, ja kļūda nav atklāta, ziņojums tiek nosūtīts saņēmēja valsts NSW. Gadījumā ja kļūda tiek konstatēta ziņojuma nosūtīšana tiek noraidīta, sniedzot attiecīgu brīdinājumu ziņojuma autoram (izsaucējam) par kļūdas raksturu.

      1. Pieejamība

Prototipa pieejamībai jābūt ne mazākai nekā 99% (24*7 režīmā), par atskaites punktu pieņemot gadu (neskaitot paredzētos ar Pasūtītāju saskaņotos pārtraukumus). Katra ceturkšņa laikā pieļaujamie pārtraukumi nepārsniedz 22 (divdesmit divas) stundas, katra pārtraukuma ilgums nedrīkst pārsniegt 4 (četras) stundas.

Specifiskas organizatoriskās prasības un pieņēmumi

      1. Sadarbība ar dalībvalstīm

Latvija kā apakšprojekta NSW2NSW vadošā valsts ģenerē ar XML ziņojumu apmaiņas sistēmas ieviešanu saistīto pieredzi un tādā veidā nodrošina projektā iesaistītajām dalībvalstīm nepieciešamo tehnisko un informatīvo atbalstu un koordinē sekmīgu projekta ieviešanu dalībvalstu NSW sistēmās.

Testēšanas nolūkam ir nepieciešams izpildītājam izveidot testēšanas vidi. Latvija kā apakšprojekta NSW2NSW koordinējošā un XML ziņojumu apmaiņas sistēmas izstrādājošā valsts plāno nodrošināt testēšanas vidi visu dalībvalstu NSW sistēmu funkcionālo iespēju darbības pārbaudei un XML ziņojumu pareizības un savietojamības pārbaudei starp dažādu dalībvalstu NSW sistēmām. Gadījumā, ja testēšanas laikā nebūs pieejama otra NSW sistēma, pārsūtīšana testējama jā datu iesniegšana un izgūšana, izmantojot standarta rīku (piemēram, SOAP-UI).

      1. Integrācija ar SKLOIS/SSN

Datu saņemšana un nosūtīšana (datu apmaiņas prototipa risinājums) ir integrējams ar SKLOIS/SSN sistēmu. Prototipa instalācija neietekmē esošās nacionālās SSN sistēmas kapacitāti un nemazina tās darbības kvalitāti. Prototipa funkcijas nerada ietekmi vai konfliktus ar esošās nacionālās SSN sistēmas programmatūru vai kādā citā veidā neietekmēt sistēmas darbību vai tās saistības.

Atskaites auditu žurnālā (log failā) saglabājas ziņas par veiktajām darbībām starp SKLIS/SSN un prototipu.

      1. Dokumentācija

Prototipa apraksta dokumentācija tiek sagatavota angļu un latviešu valodās un tajā tiek iekļauts: MIG faila atjaunota versija atbilstoši NSW2NSW vadlīnijām (iekļaujot – lietotāju piekļuves klasificēšanu, lietotāju profila un lomas aprakstu, lietotāju autorizāciju, ziņojumu validācija, NSW darbības principa aprakstu, NSW ziņojumu sistēmas pārvaldīšanas un testēšanas vispārējo aprakstu, kuras tiek ņemtas par pamatu pielāgojot MIG B2MSW struktūru un unificēta formāta paraugs, sistēmas ieviešanas scenāriju apraksts, galveno iespējamo problēmsituāciju apraksts. Prototipa dokumentācijas saraksts un iesniegšanas secība var tikt precizēts projekta gaitā, par to atsevišķi vienojoties Pasūtītājam un Izpildītājam.

      1. Darba valoda

Izpildot darba uzdevumā minētos darbus, visa komunikācija ar Pasūtītāju jānodrošina latviešu valodā (nepieciešamības gadījumā Pretendentam par saviem līdzekļiem ir jānodrošina tulkošana).

      1. Piegāžu noformēšana

Piegādātājam ir jāveic darbi un jāpiegādā šajā specifikācijā nosauktie nodevumi, saskaņā ar šīs specifikācijas prasībām, iepirkuma līguma nosacījumiem, Latvijas Republikas normatīvo aktu un Eiropas Komisijas direktīvu prasībām, Latvijas Republikas un starptautiskajiem programmatūras izstrādes standartiem. Dokumentācijas nodevumi, plāni, protokoli, pārvaldības, sistēmas izejas kodi. Projekta dokumentācija un tehniskie pielikumi ir jāiesniedz Pasūtītājam latviešu un angļu valodā elektroniski rediģējamā (MS Office atpazīstamā vai līdzvērtīga) formātā un jāiesniedz 3 (trīs) kopijas uz CD diskiem un 2 (divos) drukātos eksemplāros parakstīšanai – katrai pusei vienu eksemplāru. Piegādātājam jāpiegādā dokumentācijā ietverto shēmu un attēlu izejas materiāli (elektroniski rediģējamā formātā).

      1. Apmācība

Piegādātājs nodrošina apmācību vismaz 4 (četri) cilvēkiem – informēšanai par būtiskiem aspektiem prototipa lietošanā, to administrēšana un par pasākumiem, kas nepieciešami prototipa pilnvērtīgai funkcionēšanai.

      1. Garantija

Piegādātājam jānodrošina prototipa kļūdu (neatbilstības detalizētai specifikācijai) novēršana vismaz 1 (viens) gadu no nodošanas – pieņemšanas akta parakstīšanas.

      1. Ekspluatācijas atbalsts

Piegādātājam ir jānodrošina pasūtītāja pieteikumu saņemšana pa e-pastu, fiksētās līnijas telefonu un mobilo telefonu 24 stundas diennaktī, saskaņā Pasūtītāja funkcionālo izmaiņu atbalsta pieteikumus klasifikāciju pēc sekojošām prioritātēm:

            • avārijas pieteikumiem reakcijas laiks ir ne vairāk kā 2 stundas, ja radusies neskaidrība par SSN darbību, integrēto prototipa funkcionalitāti, vai ir radies datu bojājums, kā rezultātā SSN sistēmai vai/ un Prototipam nav iespējama darbības turpināšana;

            • konsultācija/ kļūdu labošana pieteikuma reakcijas laiks ir ne vairāk kā 2 darba dienas, radusies neskaidrība par SSN darbību, integrēto prototipa funkcionalitāti, ir radies datu bojājums, ir atklāta funkcionalitātes, savietojamības vai programmēšanas kļūda. SSN sistēmai vai/ un Prototipam ir iespējama darba turpināšana bez būtiskiem ierobežojumiem vai ir pieejams problēmas apiešanas risinājums.

Reakcijas laiks ir laiks no pieteikuma saņemšanas brīža līdz brīdim, kad izpildītājs paziņo, ka pieteikums ir saņemts un ir uzsākta pieteikuma apstrāde.


Projekta īstenošanas metodiskās prasības un dokumentācijas saturs

Datu struktūru un informācijas apmaiņas procesu definēšana

Izstrādājot datu struktūras un definējot informācijas apmaiņas procesus, jāveic izpētes un dokumentācijas sagatavošanas darbi, kuru rezultāta tiek sagatavoti šādi dokumenti:

  1. Analītiskais ziņojums;

  2. Konceptuālais projektējums.

      1. Analītiskais ziņojums

Analītiskajā ziņojumā iekļaujamas šādas nodaļas:

  • Unificēta formāta izstrāde. ES un nacionālos tiesību aktos noteikto formalitāšu daudzveidība un unificēšanas iespējas. Formalitāšu iesniegšanas atšķirīgie momenti dalībvalstīs, kas tiek pieprasīti atbildīgajām pusēm kuģu vizīšu periodā. Ziņojuma sagatavošanai, jāveic vismaz 5 (piecās) Baltijas jūras valstu procedūru apkopojums (normatīvo aktu sarakstu nodrošina pasūtītājs). Unificēta formāta paraugs, saskaņots ar AnNa dalībvalstīm (par komunikāciju atbildīgs pasūtītājs), kas ir veidots kā jauna NSW2NSW struktūra ņemot par pamatu MIG B2MSW struktūru.

  • Lietotāja profila apraksts. Apraksts ietver biznesa procesos iesaistīto Lietotāju sarakstu un lomas. Dokumentā jāiekļauj interviju rezultāti ar pasūtītāja norādītām (komunikāciju un sadarbību/iesaisti nodrošina pasūtītājs) valsts institūcijām un visām ES dalībvalstīm (līdz astoņām), kas iesaistītas projektā. Tiek sagatavots detalizēts Lietotāju sistēmu apraksts, kurš tiek izmantotas NSW2NSW vadlīniju izstrāde priekš dalībvalstu rekomendācijām.

  • Normatīvo aktu analīze. ES un Latvijas nacionālo normatīvo aktu analīze, par veicamajām izmaiņām, lai īstenotu NaMSW projekta ietvarā katras dalībvalsts NSW tiešu saslēgšanu starp dalībvalstīm, kuģu maršruta maiņas un statistikas datu apstrādi un elektronisko datu apmaiņu.

  • Ieviešanas scenāriji. Būtiskāko ieviešanas aspektu identifikācija, datu apmaiņas starp dalībvalstu NSW (NSW2NSW) sagaidāmie ieguvumi.

  • Problēmsituāciju apraksts. ES un nacionāla līmeņa līdzšinējo aktivitāšu, par centieniem veikt datu apmaiņas starp dalībvalstu NSW apraksts. Ar NSW2NSW saistīto problēmu un kritisko faktoru attiecībā uz datu apmaiņu, validāciju pārbaužu un iespējamo problēmu risinājumu apraksts.

  • Testēšanas metodoloģijas apraksts. Testēšanas metodoloģijas apraksts satur prasības akcepttestēšanai, iesaistot visas projekta dalībvalstis. Testēšanas metodoloģija tiek izstrādāt, tā, lai NSW2NSW uz MIG struktūras pamata būtu iespējams veikt tai specializētā testa vidē. Testēšanas metodoloģijas dokumentācija ietver vismaz šādas sadaļas: testēšanas plāns, testpiemēru specifikācija (identifikācija), testēšanas procedūras specifikācijas, testēšanas žurnālu, akcepttesta problēmu protokolu formāts, testēšanas kopsavilkuma ziņojumus.

  • Pieredzes pārneses (demonstrāciju) aktivitāšu saraksts. NSW2NSW Prototipa pieredzes pārneses iespēju novērtējums un demonstrācijas aktivitāšu saraksts pēc vismaz šādas izstrādāta risinājuma ietekmes: kuģošanas informācijas un ostu formalitāšu datu apmaiņa un atvieglošana, integrēšana un apmaiņa NSW2NSW dalībvalstu NSW sistēmās, ekonomiskais izdevīgums un administratīvā sloga samazinājums, efektivitāte salīdzinājumā ar esošiem risinājumiem, NSW2NSW Prototipa trūkumi.

  • MIG faila atjaunota versija. Atbilstoši NSW2NSW vadlīnijām pielāgojot MIG B2NSW struktūru detalizēts apraksts ietverot lietotāju piekļuves klasificēšanu, lietotāju autorizāciju, ziņojumu validāciju, operatīvo dienestu un to procedūru aprakstu, NSW ziņojumu sistēmas darbības principa un pārvaldīšanas aprakstu.

      1. Konceptuālais projektējums

Pēc Ziņojuma saskaņošanas ar Pasūtītāju, kā starpposmu izstrādē Piegādātājs sagatavo konceptuāla projektējuma aprakstu, kurā ir izklāstīti konceptuālie risinājumi un, tiek aprakstītas risinājuma komponentes, to savstarpējā saistība. Konceptuālais projektējums jāprezentē tam paredzētā seminārā un jāsaskaņo ar Pasūtītāju. Pamatojoties uz saskaņoto konceptuālo projektējumu, Piegādātājam jāsagatavo prototips (programmatūra).

Akcepttestēšana

Piegādātājam jānodrošina atbalsts Pasūtītājam akcepttestēšanas laikā:

      • Akcepttestēšana. Piegādātājs sagatavo un saskaņo ar Pasūtītāju akcepttestēšanas procedūru un plānu, kurā tiek aprakstīta akceptēšanas kārtība un kritēriji, kā arī akcepttestēšanas testi (identifikācija). Akcepttestu noslēgumā Piegādātājam ir jāsagatavo akcepttestu protokoli. Protokolos ir jānorāda akcepttestu tvērums un veiktās darbības, kā arī konstatētās kļūdas vai neprecizitātes.

      • Drošības pārbaude. Piegādātājam testēšanas ietvaros jāveic Prototipa un to komponenšu drošības pārbaudes, lai pārliecinātos par Prototipa neautorizētas izmantošanas vai rediģēšanas iespējām. Atbilstoši XxXx projekta dalībnieku kopīgajām projektam par „Pilot EU SEC Data and Data transfer security requirements” projekta dokumentāciju iesniedz pasūtītājs pēc izpildītāja pieprasījuma.

      • Veiktspējas testēšana. Piegādātājam testēšanas ietvaros jāveic Prototipa un to komponenšu veiktspējas pārbaudes, lai pārliecinātos par prototipa arhitektūras realizācijas piemērotību atbilstoši specifikācijā noteiktajām veiktspējas prasībām, kā arī, lai identificētu iespējamos risinājumus prototipa darbības uzlabošanai. Testēšanas procesā jāveic funkcionālie testi atsevišķi visām Prototipa lietotāju lomām, pārbaudot, vai lietotājiem faktiski pieejamā funkcionalitāte ir atbilstoša sistēmas dokumentācijā noteiktajiem lietotāju lomu apgabaliem.

Akcepttestēšanas noslēgumā ir jāveic prototipa efektivitātes analīze, kuras ietvaros Piegādātājs sagatavo Efektivitātes ziņojumu.

      1. Analītiskais ziņojums

Kritēriji. Efektivitātes analīze, kas veikta novērtējot vismaz 8 projekta sasnieguma aspektus, ieskaitot: kuģošanas informācijas un ostu formalitāšu iesniegšanas atvieglošana, administratīvā sloga samazinājums, integrēšana starp NSW2NSW projekta dalībvalstu NSW sistēmām, ekonomiskais izdevīgums, efektivitāte salīdzinājumā ar esošiem risinājumiem, sistēmas funkcionalitāšu darbība, NSW2NSW Prototipa trūkumi. Papildus Piegādātājs pēc sava ieskata izvirza vismaz 2 (divus) efektivitātes kritērijus un tos novērtē iepriekš saskaņojot ar Pasūtītāju.

Rezultātu demonstrēšana

Projekta noslēgumā veicama projekta rezultātu demonstrācija:

  • Gala ziņojums. Piegādātājs sagatavo gala ziņojumu (kopsavilkumu) par projekta realizāciju pēc izstrādātā risinājuma ietekmes: kuģošanas informācijas un ostu formalitāšu iesniegšanas atvieglošana, integrēšana NSW2NSW dalībvalstu NSW sistēmās, ekonomiskais izdevīgums un administratīvā sloga samazinājums, efektivitāte salīdzinājumā ar esošiem risinājumiem, NSW2NSW Prototipa trūkumi. Kopsavilkumu sagatavo uz ne vairāk kā uz 25 lapaspusēm, sinhroni latviešu un angļu valodā, un iesniedz to Pasūtītājam saskaņošanai. Pēc saskaņošanas Piegādātājs nodrošina tā pavairošanu vismaz 50 eksemplāros. Piegādātājs arī iesniedz Pasūtītājam kopsavilkumu Microsoft Office Word (vai līdzvērtīgā) formātā.

  • Atpazīstamība. Izstrādātājs izstrādā un nodrošina, ka saskaņojot ar Pasūtītāju, tā adresē Xxxxxx xxxx 0x, Rīgā, tiek izvietots informatīvs materiāls, kas informē, ka Krasta apsardze dienestā tiek īstenots TEN – T līdzfinansētais projekts AnNa.

  • Uzskates materiāli. Izpildītājs sagatavo vismaz 1 (vienu) vizuālu prezentāciju, kurā ietilps secīgs NSW2NSW projekta realizācijas apraksts, sasniegtie rezultāti, gūtās pieredzes pārneses iespējas. Prezentācija jāsagatavo latviešu un angļu valodā. Izpildītājs sagatavot 1 (vienu) informatīvu brošūru, tās nodevuma formāts ir elektroniska datne, kura izmantojama brošūru pavairošanai tipogrāfijā un vismaz 100 (viens simts) gab. brošūru piegāde katrai valodai – divpusēja, krāsaina, glancēta brošūra, katras brošūras apjoms 1 (viena) A4 formāta lapa.

Papildus izpildītājs sagatavo video materiālu angļu valodā ar uzskatāmu NSW2NSW prototipa darbības demonstrēšanu, un vismaz 4 (četru) aktivitāšu: kuģošanas informācijas un ostu formalitāšu datu apmaiņa un atvieglošana, integrēšana un apmaiņa NSW2NSW dalībvalstu NSW sistēmās, ekonomiskais izdevīgums un administratīvā sloga samazinājums pārskatu.

  • Publicitāte. Demonstrācijas aktivitāšu gaitā Piegādātājs nodrošina Pasūtītāju ar vismaz 3 (trīs) sagatavotiem tekstiem latviešu un angļu valodā, kas satur vismaz 300 (trīs simti) vārdus un, kas paredzēti preses relīzē par aktuālo informācija par projekta īstenošanas gaitu ar atsauksmi uz Projekta koordinatoru mājas lapu xxx.xxxxxxx.xx un TEN – T līdzfinansēto projekts AnNa.

  • Demonstrācija. Izstrādātājs nodrošina konsultatīvu atbalstu Pasūtītājam vismaz 2 (divas) publikāciju sagatavošanai un, nozīmē savu pārstāvi par Piegādātāja resursiem vismaz 1 (vienai) dalībai Eiropas līmeņa pasākumā projekta demonstrācijai.

Pielikums Nr. 3.2.

Konkursa, identifikācijas

Nr. VAMOIC 2014/171, nolikumam

TEHNISKĀ SPECIFIKĀCIJA


„Datu pārraides tīkla modeļa prototipa izveide Rīgas jūras līcī (I-CaDE)”

Saturs

1. Vispārīga informācija par iepirkuma priekšmetu 53

1.1. Esošās situācijas raksturojums 53

1.2. VILDA pilotprojekta „Datu pārraides tīkla modeļa prototipa izveide Rīgas jūras līcī (I-CADE)” apraksts 53

2. Vispārējs darba uzdevums 55

2.1. Tehniskās prototipa komponentes 55

2.2. Prototipa darbībai nepieciešamo iekārtu izvietošana uz KAD bāzes stacijām 55

2.3. Prototipa Lietotāja aprīkojuma izvietošana uz kuģa 55

2.4. Bāzes stacijām izvietoto iekārtu saslēgšana ar centrālo serveri 56

2.5. Frekvenču diapazons un izmantošana 56

2.6. Prototipa tīkla veiktspēja 56

2.7. Prototipa integrācija SKLOIS/SSN 56

2.8. Prototipa darbība 57

2.9. Autentifikācijas risinājuma prasības piekļuvei bezvadu tīklam 57

2.10. Tiesību akti 58

3. Darbu izpildes termiņi 58

4. Darbu veikšanas kārtība un to veikšanas īpašie nosacījumi 59

4.1. Analīzes un pētījumu veikšana posms 59

4.2. Tehniskā prototipa izstrādes posms nodevuma apraksts 61

4.3. Tehniskā prototipa testēšana 62

4.4. Efektivitātes novērtējums 62

4.5. Demonstrācijas izstrādes process 62

5. Organizatoriskās prasības 63

5.1. Piegāde 63

5.2. Darba valoda 63

5.3. Veiktspējas pieejamība 63

5.4. Kvalitātes prasības, garantija. 63

5.5. Informētība. 64



Iepirkuma mērķis: eksperimentālā bezvadu tīkla modeļa prototipa izveide Rīgas Jūras līcī.


Izmantotie termini

AnNa

Attīstīti valstu pārvaldes iestāžu tīkli

IMO

Starptautiskā Jūras organizācija

KAD

Jūras Spēku Flotiles Krasta apsardzes dienests

MSW

Vienots jūrniecības informācijas logs

SSN

Nacionālā SafeSeaNet sistēma

VILDA

Vienots informācijas logs jūrniecības un loģistikas datu administrēšanai

InDTra

Kuģošanas informācijas un ostu formalitāšu datu konvertēšanas un apmaiņas moduļa izstrāde

FAL

FAL Konvencija par starptautiskās jūras satiksmes atvieglošanu

SKLOIS

Starptautiskā kravu loģistikas un ostu informācijas sistēma

dbi

Antenas pastiprināšanas koeficients

IP66

(IP saīsinājuma nozīme — angļu: Ingress Protection) klasificē iekārtu aizsardzību pret apkārtējās vides iedarbību. 66 - Pilnīgi aizsargāts pret putekļu iekļūšanu un spēcīgu ūdens strūklu.

Režģtīkls

mesh network, Tīkla topoloģijas paveids, kurā ir vismaz divi mezgli, starp kuriem ir ne mazāk kā divi ceļi.

Duplekss

Signālu pārraide abos virzienos, izmantojot vienu un to pašu sakaru kanālu.

Pilnduplekss

Divvirzienu datu apmaiņa starp attāliem datoriem, kas datus vienlaicīgi var sūtīt viens otram.

Tīkla latentums

Kavēšanos, kas notiek laika, kad dati tiek apstrādāti vai piegādāta.

Paketes zudums

Koeficients – parametrs, kas procentos nosaka zaudēto pakešu attiecību pret kopējo nosūtīto pakešu skaitu.

Tīkla latentums

Laika intervāls datoru tīklā starp brīdi, kad stacija pieprasa piekļuvi datu pārraides kanālam, un brīdi, kad kanāls tiek nodots šīs stacijas rīcībā datu pārraidīšanai.


Dokumenta lietotāji

Tehniskā specifikācija ir paredzēta šādām lietotāju grupām:

  1. Pasūtītājam (Jūras spēku flotiles Krasta apsardzes dienests turpmāk – KAD) – iepirkuma procedūras organizēšanai, pretendentu piedāvājumu novērtēšanai, līguma izpildes kontrolei;

  2. Pretendentiem (izpildītājam) - piedāvājuma sagatavošanai, kā sākotnējais materiāls Projekta plānošanai, analīzes veikšanai un detalizētās programmatūras prasību specifikācijas sagatavošanai.

  1. Vispārīga informācija par iepirkuma priekšmetu

    1. Esošās situācijas raksturojums

Latvijai, pildot Eiropas Parlamenta un Padomes Direktīva 2010/65/ES (2010. gada 20. oktobris) par ziņošanas formalitātēm kuģiem, kuri ienāk dalībvalstu ostās un/vai iziet no tām, un ar ko atceļ Direktīvu 2002/6/EK (1) (turpmāk – Direktīvas 2010/65/ES) prasības, līdz 2015. gada 1. jūnijam ir jārealizē vienas pieturas aģentūras princips. Nacionālo Bruņoto spēku (turpmāk - NBS) Jūras spēku flotiles Krasta apsardzes dienesta uzturētā Kuģu satiksmes uzraudzības un informācijas datu apmaiņas sistēma (nacionālā vienotā loga sistēmā sistēma, turpmāk – SKLOIS/SSN) ir Latvijas vienas pieturas aģentūras risinājuma pamats. SKLOIS/SSN attīstību nosaka Ministru kabineta (turpmāk – MK) 2009. gada 4. augusta noteikumi Nr.857 „Kārtība, kādā nodrošināma sakaru tīklu darbība Kuģu satiksmes uzraudzības un informācijas datu apmaiņas sistēmas ietvaros” un MK 2012. gada 15. maija noteikumi Nr.339 „Noteikumi par ostu formalitātēm”. Abos minētajos MK noteikumos nacionālā līmenī ir pārņemtas direktīvas 2010/65/ES prasības.

Latvijas dalības ANNA MSW projektā virsmērķis ir veicināt aktīvu sadarbību starp ES dalībvalstīm un izstrādāt atbilstošus mehānismus, lai atvieglotu un harmonizētu ziņošanas formalitātes nacionālā un ES dalībvalstu līmenī.

XXXX MSW projekta mērķi ir:

- Sekmēt Direktīvas 2010/65/ES ieviešanu, stiprināt Eiropas ostu un jūras transporta konkurētspēju pasaules mērogā;

- Sekmēt visu iesaistīto pušu dalību vienotā elektroniskā informācijas telpā;

- Izveidot saskaņotu pieeju un efektīvu sadarbību starp privāto un publisko sektoru;

- Dalībvalstīs sekmēt bottom-up pieeju, lai realizētu vienas pieturas aģentūras projektu;

- Izveidot sistēmu, kas sekmētu savietojamību starp datu sniedzējiem, publisko sektoru un loģistikas ķēžu operatoriem.

Aizsardzības Ministrija ir sagatavojusi nacionālās SKLOIS/SSN sistēmas izpētes un attīstības projektu „Vienots informācijas logs jūrniecības un loģistikas datu administrēšanai (turpmāk - VILDA)”. VILDA paredz pētīt un izveidot vienotu telpu datu apmaiņai jūrniecības un loģistikas informācijai gan nacionālā, gan ES līmenī, saskaņā ar ES Direktīvas 2010/65/ES prasībām.

VILDA apakšprojekta „Datu pārraides tīkla modeļa prototipa izveide Rīgas jūras līcī (I-CaDE)” mērķis ir pilnveidot komunikāciju un uzlabot datu plūsmas principus, padarot lietotājiem pieejamākus vienas pieturas aģentūras elementus. Apakšprojekta realizācijas laikā tiks pētīta iespēja uzlabot sakaru un datu apmaiņas principus starp vienotu informācijas logu un tā tiešajiem datu un informācijas sniedzējiem – kuģiem. Apakšprojekta eksperimentālajā fāzē sakaru un datu tīkla darbības pierādīšanai tiek plānots izmantot KAD krasta infrastruktūru (bāzes stacijas) un iesaistīt kuģus, kas kuģo uz/no Latvijas ostām. Projekts paredz uzlabot vienas pieturas aģentūras darbības principus, kā arī kopumā uzlabot kuģošanas drošību un drošumu.

    1. VILDA pilotprojekta „Datu pārraides tīkla modeļa prototipa izveide Rīgas jūras līcī (I-CADE)” apraksts

Projekta I-CaDE realizācija paredz aktivitātes, kas nodrošinātu satelītu un mobilajiem sakariem alternatīvu bezvadu risinājumu, datu pārradīšanai (apmaiņai), atvieglojot un uzlabojot kuģošanas nozares (specifiski starptautiskajā jūras satiksmē iesaistītajiem kuģiem (turpmāk tekstā – Lietotājs)) savstarpējo datu apmaiņu „kuģis –kuģis”, x.xx., neradot administratīvu barjeru ostas formalitāšu dokumentu apstrādei.

      1. Izstrādājamais prototips

Eksperimentālā bezvadu tīkla modeļa prototipa izveide Rīgas Jūras līcī (turpmāk – prototips), saskaņā ar šajā specifikācijā noteiktajām prasībām un iepirkuma priekšmets sastāv no šādām aktivitātēm:

  • Datu apmaiņas tīkla pārklājumu ieviešana, kas nodrošina Lietotājam un SKLOIS/SSN sistēmai iespēju veikt SKLOIS/SSN sistēmas atbalstītu, elektroniskā formāta datu apmaiņu starp Lietotāju un SKLOIS/SSN sistēmu, turklāt datu apraides pieejamībai Lietotājiem, pārklājuma zonā tiek veidots režģtīkla risinājums.

  • Projektējumā prototipa tehniskās izstrādes un uzstādīšanas detalizēts izklāsts (dokumentēts), prototipa darbības, testēšanas un analīzes izvērtējums.

  • Prototipa testēšana un efektivitātes novērtēšana noteiktajā pārklājuma zonā, iesaistot vismaz 2 (divus) Lietotājus. Testēšana tiek veikta prototipa stabilitātes un iespējamības izvērtēšanai, ņemot vērā vides apstākļu ietekmi un datu plūsmas kvalitāti/kvantitāti. Novērtēšana tiek veikta Rīgas Jūras līcī, novērtējot, vai pastāv perspektīvas iespējas prototipa risinājuma piemērošanai Baltijas jūrā gar Latvijas piekrasti.

  • Pieredzes pārneses aktivitātes.

Prasības aktivitāšu realizācijai ir noteiktas šajā specifikācijā.

Apakšprojekta I-CaDE nodevumam ir jābūt ieviestam eksperimentālam risinājumam, kuģošanas drošības un ostas formalitāšu datus saturošās informācijas apmaiņai, nodrošinot Direktīvas 2010/65/EK prasību izpildi par informācijas vienreizēju iesniegšanu. Realizācijas procesā nepieciešams novērtēt eksperimentālo risinājumu ar mērķi, lai tiktu atvieglotas administratīvās procedūras gan kompetentajām iestādēm, gan SKLOIS/SSN MSW lietotājiem, kam ir pienākums iesniegt ostas formalitātes. Prototipa darbība aptvers 3 (trīs) kuģu reģistrācijas procedūras:

  • 1. procedūra: FAL Konvenciju par starptautiskās jūras satiksmes atvieglošanu (turpmāk - FAL konvencija) minēto dokumentu iesniegšanai SKLOIS/SSN sistēmā vismaz 2 (divas) stundas pirms kuģa paredzētās ienākšanas ostā pie pirmās piestātnes;

  • 2. procedūra: Kuģu iziešanas saskaņošana, ostas formalitāšu kārtošana, kontrole (1.procedūrai pretējs process);

  • 3. procedūra: Lietotāja iesniegto FAL dokumentu papildināšana, atjaunošana vai atcelšana.

Prototipa testēšanas ietveros tiks praksē pierādīts izvirzītais mērķis, nodrošināt vienas pieturas aģentūras principu vismaz šādu Tab. 1 norādīto FAL dokumentu atvieglotai iesniegšanai SKLOIS/SSN sistēmā:

Dokuments

Atšifrējums

FAL 1. veidlapa

Vispārīgā deklarācija

FAL 2.veidlapa

Kuģa kravas manifests

FAL 3.veidlapa

Kuģa krājumu deklarācija

FAL 4. veidlapa

Apkalpes mantu deklarācija

Tab. 1: FAL dokumenti, kas obligāti vismaz divas stundas pirms kuģa paredzētās ienākšanas ostā pie pirmās piestātnes, saskaņā ar FAL konvenciju, starptautiskajā jūras satiksmē iesaistītajiem kuģiem.

2. Vispārējs darba uzdevums

2.1. Tehniskās prototipa komponentes

Prototipa izstrādē jāiekļauj šādas komponentes:

  • Kuģis krasts tīkla un krasts - kuģis – kuģis - krasts režģtīkla arhitektūras dokumentācija;

  • Risinājums, datu apmaiņai, kas nodrošināts ar nepārtrauktu pārklājums ar pārraides ātrums - ne mazāks par 1 MB/s, katram lietotājam, tāda pārklājuma zonā, lai Rīgas Jūras līča rekomendētais kuģu ceļš uz Rīgas ostu, vismaz 10 km platā kuģošanas zonā ar minimālo attālumu no krasta līnijas vismaz 40 km un vismaz 70 km attālumā pa kuģa ceļu pirms pienākšanas bojas B (turpmāk tekstā - definētā pārklājuma zona) tiktu pārklāts.

  • Uz vismaz 2 (divām) KAD bāzes stacijām izvietotas iekārtas;

  • Vismaz 2 (divas) Lietotāja iekārtas (termināls), kas izvietotas uz kuģiem ar spēju lietot prototipa tīklu un radīt režģtīklu ar atpazīstamām cita lietotāja iekārtām;

  • SKLOIS/SSN sistēmā akceptējams Lietotāja datu kopums, kas satur tab. Nr.1 norādīto informāciju;

  • SKLOIS/SSN sistēmas atbildes reakcija, kā datu kopums no SKLOIS/SSN sistēmas, par informācijas saņemšanu un kompetento iestāžu informāciju par datu apstiprināšanu, noraidīšanu un komentēšanu.

2.2. Prototipa darbībai nepieciešamo iekārtu izvietošana uz KAD bāzes stacijām

Datu apraides nodrošināšanai nepieciešamo iekārtu vai tehniskā aprīkojuma izvietošanai, tiek izmantotas KAD bāzes stacijas ar nodrošinātu barošana spriegumu saskaņā ar standartu LVS NE 50160:2010. Uz bāzes stacijām izvietojamā prototipa aprīkojumam minimālie parametri ir šādi:

      1. Vispārīgās prasības

  • Pieslēgumi: 10/100/1000 Ethernet (RJ-45);

  • Papildus USB ligzda vai iebūvēts slots SIM kartei (4G modema izmantošanai, lai nodrošinātu rezerves datu pārraidi).

      1. Antenas parametri:

    • Svars: ne vairāk kā 7 kg;

    • Izmērs: ne vairāk kā 800x400x130mm

    • Mitruma aizsardzība: vismaz IP66

    • Pastiprinājuma koeficients: vismaz 25 dbi;

    • Vēja slodze: vismaz 110 km/h;

    • Darba temperatūra: robežās no – 35..+40 C;

    • Stara platums: vismaz 2,5 grādi;

    • Atbilstības standarti: EN 302 326, DN2, CE, FCC, IC vai līdzvērtīgiem;

    • Rezerves barošana: vismaz 12 stundas.

2.3. Prototipa Lietotāja aprīkojuma izvietošana uz kuģa

Lietotāja aprīkojums un datu apstrādes iekārta tiek izvietota uz vismaz 2 (diviem) kuģiem, kas kuģo definētajā pārklājuma zonā un to minimālie parametri ir šādi:

2.3.1. Savienojums kuģis – krasts iekārtas parametri:

    • Svars: ne vairāk kā 110kg;

    • Vēja slodze: vismaz 110km/h;

    • Izmēri: ne vairāk kā 1500mm x 1500mm;

    • Darba temperatūra: robežās -40..+50 C;

    • Mitruma aizsardzība: vismaz IP66

    • Rezerves barošana: vismaz 6 stundas;

    • Pārklājuma zonas: definētā pārklājuma zona ar minimālo attālumu 40km no bāzes stacijas;

    • Datu pārraides pieslēguma garantētājs ātrums: ne mazāks par 1 MB/s katram lietotājam pieņemot, ka tīklā vienlaikus ir vismaz 20 Lietotāji;

    • Atbilstības standarti: EN 302 326 , DN2, CE, FCC, IC vai līdzvērtīgi.

      1. Režģtīkla savienojums (kuģis – kuģis) iekārtas parametri

    • Pārklājuma zona: vismaz 30km un 360 grādi;

    • Datu pārraides ātrums: ne mazāks par 1 Mb/s katram lietotājam pieņemot, ka tīklā viena laikā ir vismaz 20 Lietotāji;

    • Tīkla latentums vienam pieslēgumam ne vairāk ka 25ms, bet kopēja ne vairāk kā 80ms;

    • Paketes zudums: ne vairāk kā 2%.

      1. Lietotāja datu apstrādes iekārta uz kuģa:

    • Procesora kodolu skaits: vismaz 2 (divi).

    • Operatīvā atmiņa: vismaz 4 (četri) GB, ar iespēju palielināt līdz 8 GB. Operatīvās atmiņas kopne: DDR3;

    • Cietais disks: vismaz 500 GB;

    • Ekrāna izmērs: no 12.5" līdz 14";

    • Fiziskie savienojumi: vismaz 2 (divi) USB porti, 1 (viens) RS232 vai adapteris USB uz RS232, 1 (viens) RJ45.

    • Svars: ne vairāk kā 1,7 kg.

2.4. Bāzes stacijām izvietoto iekārtu saslēgšana ar centrālo serveri

Sadarbspēju uz bāzes stacijām izvietotajām prototipa iekārtām ar centrālo serveri SKLOIS/ SSN (adrese: Rīga, Xxxxxxx xxxx 0x), jānodrošina izmantojot bezvadu saslēgumu ar minimāliem parametriem:

    • Pieslēgšanas ātrums: maksimāli līdz 100Mb/s, bet garantētam pieslēguma ātrumam ne mazāk kā 40Mb/s ar pilnduplekss pieslēgumu;

    • Tīkla latentums ne vairāk kā 5ms;

    • Paketes zudums ne vairāk kā 1%.

2.5. Frekvenču diapazons un izmantošana

Prototipa realizācijas periodam un izveidei, izvēlētāja frekvenču diapazonā pēc iespējas, tiek izmantotas brīvi pieejamās frekvences: 2300 – 2450MHz, 5485 -5720 MHz, izņemot 5660MHz. Ja nepieciešams, uz projekta realizācijai gaitu frekvenču izmantošanas saskaņošanu ar atbildīgajām institūcijām veic Pasūtītājs. Izpildītājs iesniedz Pasūtītājam frekvenču izmantošanas saskaņošanai normatīvos aktos noteikto dokumentāciju.

2.6. Prototipa tīkla veiktspēja

Prototipa darbības sasniedz izvirzītos parametrus, kuģošanu apgrūtinošos apstākļos (migla, stiprs lietus, jūras stāvoklis virs 6 ballēm, augsta spiediena laikā). Sakaru pārtraukumu gadījumā, prototips automātiski mēģina atjaunot sakarus un nepārtrauc šo procesu, kamēr sakari nav atjaunoti un saņemts apstiprinājums par veiksmīgu nosūtāmās informācijas saņemšanu.

2.7. Prototipa integrācija SKLOIS/SSN

Tieši, Lietotāja iesniegti FAL dokumenti testa SKLOIS/SSN sistēmā, izmantojot Prototipa tīkla pārklājumu testa periodā tiek uzskatīti par testa vides datiem un netiek autorizēti, kā ostu formalitātes, atbilstoši normatīvo aktu prasībām. Lietotāja atpazīšana un tā darbības, iesniedzot FAL dokumentāciju, ir atpazīstamas testa SKLOIS/SSN sistēmai. Prototipa instalācija nevar ietekmēt esošās nacionālās testa SKLOIS/SSN sistēmas kapacitāti un mazināt tās darbības kvalitāti. Prototipa funkcijas nerada negatīvu ietekmi vai konfliktus ar esošās nacionālās testa SKLOIS/SSN sistēmas programmatūru vai kādā citā veidā ietekmē tās statusu vai ar to saistītās saistības.

      1. Prototipa Lietotāja vide

Lietotājam tiek nodrošināts pieslēgums tīklam ar tam speciāli paredzētu Lietotāja iekārtu vai vidi, un, Lietotājam ienākot tīkla definētajā pārklājuma zonā uz kuģi esošā iekārta vai termināls, automātiski pieslēdzas tīklam. Lietotāja vide vai iekārta ir ar specializētu programmatūru, kas nodrošina Lietotājam iekārtas pārvaldību un darbību. Pie katras iekārtas ieslēgšanas vai pārstartēšanas, lai uzsākt lietošanu, tā pārliecinās par iekārtas fizisko resursu (procesoru, pieslēgumvietu, dzesēšanas un elektrobarošanas sistēmu) darboties spēju. Papildus tiek nodrošināts VILDA apakšprojekta ”Kuģošanas informācijas un ostu formalitāšu datu konvertēšanas un apmaiņas moduļa izstrāde” prototipa pieejamība Lietotājam, datu iesniegšanai SKLOIS/SSN testa vidē XML formātā. Ka arī uz prototipa testēšanas laiku, Izpildītājam un Lietotājam tiks piešķirtas autorizācijas tiesības SKLOIS/SSN sistēmā, testa videi.

2.8. Prototipa darbība

      1. Fiziskā līmeņa datu pārraides ātrums no gala iekārtas uz bezvadu datu pārraides piekļuves punktu ir ne mazāks par 1 MB/s, ar nosacījumu, ka tīklā šādu ātrumu iespējams nodrošināt ja tīklu vienlaikus lieto vismaz 20 (divdesmit) Lietotāji.

      2. Datu apraide no Krasta stacijas līdz lietotājam ir nodrošināta vismaz definētajā pārklājuma zonā.

      3. Uzstādītās iekārtas un to komponentes uz esošās KAD krasta bāzes stacijas infrastruktūras neietekmē jebkuras esošo sistēmas darbības.

      4. Prototipa darbībai ir aprīkotas vismaz 2 (divas) KAD bāzes stacijas , kā arī nodrošināta tīkla pārklājuma savietojamība bez pārrāvumiem pie pārejas no vienas bāzes stacijas pie otras.

      5. Prototipa darbībai, vismaz 2 (divi) kuģi ir aprīkoti ar Lietotāja vidi vai iekārtu, lai kļūtu par prototipa tīkla lietotāju definētajā pārklājuma zonā ar minimālo datu apmaiņas ātrumu un veidotu režģtīklu.

      6. Lietotāju antenu konstrukcijas ir piemērotas uzstādīšanai uz kuģiem un nekonfliktē ar esošām iekārtām.

      7. Visas iekārtas un komponentes SKLOIS/SSN sistēmas informācijas apstrādei tiek nodrošināta Prototipa izstrādes un uzstādīšanas ietvaros.

      8. Iekārtai jāspēj veikt datu plūsmu maršrutēšanu un komutāciju pie visiem ieslēgtiem servisiem pilndupleksa režīmā.

    1. Autentifikācijas risinājuma prasības piekļuvei bezvadu tīklam

Lietotājs kļūst par atpazīstamu lietotāju tīklam ar autorizācijas saskaņā ar 802.11s standartu, reģistrējot kuģa nosaukumu, kuģa identifikācijas numuru (IMO). Prototipa ietvaros paredzēto FAL formu apmaiņai tiek nodrošināta autentifikācija testa SKLOIS/SSN sistēma no KAD puses uz prototipa realizācijas periodu.

    1. Tiesību akti

Eksperimentālā bezvadu tīkla modeļa izveides un piegādes ietvaros, Izpildītājam ir jāņem vērā šādi saistošie tiesību akti:

      • FAL Konvencija par starptautiskās jūras satiksmes atvieglošanu;

      • Jūrlietu pārvaldes un jūras drošības likums;

      • Informācijas atklātības likums;

      • Dokumentu juridiskā spēka likums;

      • Elektronisko dokumentu likums;

      • 2013. gada 17. decembra Ministru Kabineta sēdes protokols Nr.67, 86.§ Informatīvais ziņojums „Par papildu valsts budžeta saistību uzņemšanos Kuģu Satiksmes uzraudzības un informācijas datu apmaiņas sistēmas pilnveidošanai un Direktīvas 2010/65/ES ieviešanai”;

      • Ministru kabineta 2010.gada 28.septembra noteikumi Nr. 916 „Dokumentu izstrādāšanas un noformēšanas kārtība”;

      • Ministru kabineta 2005.gada 28.jūnijā noteikumi Nr. 473 „Elektronisko dokumentu izstrādāšanas, noformēšanas, glabāšanas un aprites kārtība valsts un pašvaldību iestādēs un kārtība, kādā notiek elektronisko dokumentu aprite starp valsts un pašvaldību iestādēm vai starp šīm iestādēm un fiziskajām un juridiskajām personām”;

      • Ministru kabineta 2010. gada 13. aprīlī noteikumi Nr.357 „Kārtība, kādā iestādes sadarbojoties, sniedz informāciju elektroniskā veidā, kā arī nodrošina un apliecina šādas informācijas patiesumu”;

      • 2009. gada 4. augusta Ministru kabineta noteikumi Nr. 857 „Kārtība, kādā nodrošināma sakaru tīklu darbība Kuģu satiksmes uzraudzības un informācijas datu apmaiņas sistēmas ietvaros”

      • 2012. gada 15. maija Ministru kabineta noteikumi Nr.339 „Noteikumi par ostu formalitātēm”;

      • Eiropas Parlamenta un Padomes 2002.gada 27.jūnija Direktīvas 2002/59/EK, ar ko izveido Kopienas kuģu satiksmes uzraudzības un informācijas sistēmu un atceļ Padomes Direktīvu 93/75/EEK;

      • Eiropas Parlamenta un Padomes 2009. gada 23.aprīļa Direktīvas 2009/17/EK, ar kuru groza Direktīvu 2002/59/EK, ar ko izveido Kopienas kuģu satiksmes uzraudzības un informācijas sistēmu;

      • Eiropas Parlamenta un Padomes 2010. gada 20. oktobra Direktīvas 2010/65/ES par ziņošanas formalitātēm kuģiem, kuri ienāk dalībvalstu ostās un/vai iziet no tām, un ar ko atceļ Direktīvu 2002/6/EK.

  1. Darbu izpildes termiņi

Projekts veicams secīgos posmos (uzsākot katru pēc iepriekšējās pabeigšanas). Zemāk norādīti termiņi katras kārtas nodevumu iesniegšanai saskaņošanas uzsākšanai (skaitot no posma uzsākšanas dienas). Katra kārtas nodevumu saskaņošana tiks veikta ne ilgāk kā 10 darba dienu laikā.

Kārtas (posma) nr.

Nodevumu iesniegšanas termiņš / nodevumi

1.

Analīzes (pētījuma veikšanas) posms

Termiņš: 12 nedēļas

Nodevumi: Ziņojums, Konceptuālais projektējums

2.

Tehniskā prototipa izstrāde

Termiņš: 24 nedēļas

Nodevumi: Tehniskais prototips, Pavaddokumentācija

3.

Tehniskā prototipa testēšana

Termiņš: 8 nedēļas

Nodevumi: Testēšanas ziņojums, Efektivitātes novērtējums

4.

Demonstrēšana, Pieredzes pārneses aktivitātes

Termiņš: 4 nedēļas

Nodevumi: Ziņojums (-i), Pieredzes pārneses dokumentācija

  1. Darbu veikšanas kārtība un to veikšanas īpašie nosacījumi

    1. Analīzes un pētījumu veikšana posms

Analīzes dokumentu sagatavošana notiek latviešu un angļu valodā. Nodevumu saturu var strukturēt sīkāk vai ne savādāk kā prasīts (nezaudējot saturisko apjomu), lai nodrošinātu apraksta dokumenta skaidrību un uztveramību. Analīzes izstrāde ir jāveic tādā detalizācijas pakāpē, lai tas sniegtu gan Pasūtītājam pilnu izpratni par esošo situāciju, iespēju izstrādāt projektu un izveidot prototipu, nodrošināt tā savietojamību ar esošo sistēmu un atbilstību Vienots informācijas logs jūrniecības un loģistikas datu administrēšanai VILDA ietvaram.

      1. Ziņojums

Ziņojumā iekļautas šādas nodaļas:

  • Statistikas ziņojums. Ziņojums kuģu satiksmes intensitātes statistika par projekta realizācijas gaitās periodu 6 (seši) mēneši, no tā uzsākšanas datuma, tiek sagatavots apkopojot kuģu skaitu un kuģošanas ceļu, par tiem kuģiem, kuru mērķa osta bijusi kāda no Latvijas ostām. Statistika tiek izveidota kā kuģu satiksmes intensitātes interaktīvas statistikas datu diagrammas uz Baltijas jūras Latvijas piekrastes jūras navigācijas kartes ar mērogu ne mazāk kā 1: 250 000. Karte paredz demonstrēt un analizēt kuģu satiksmes statistiku pēc vismaz šādiem kritērijiem:

  • Kuģu plūsma katrā mēnesī;

  • Kuģu plūsma gada periodā;

  • Kuģu plūsma diennaktī;

  • Salīdzinošā statistika pa mēnešiem, pa diennaktīm;

  • Kuģu plūsma uz katru no ostām Latvijā (mēnesī, diennaktī, gadā).

  • Lietotāja profila apraksts. Apraksts ietver kuģu reģistrācijas procedūrās iesaistīto Lietotāju un ieinteresēto pušu (kompetentās institūcijas) sarakstu un lomas. Tiek sagatavots detalizēts Lietotāju un ieinteresēto pušu interešu apraksts, kuras tiek izmantotas Prototipa funkcionalitātes nodrošināšanai (loma, tehnoloģijas, pārlūkprogrammas, aizsardzības nosacījumu u.c.).

  • Normatīvo aktu analīze. Starptautiskos, ES un nacionālos tiesību aktos noteikto formalitāšu iesniegšanas specifika, kas tiek pieprasīta atbildīgajām pusēm kuģu vizīšu periodā vismaz 2 stundas pirms pienākšanas pie pirmās piestātnes. Ziņojumā sagatavošanai, statistika jāveic vismaz 5 (piecās) Baltijas jūras valstīs. Tāpat jāsagatavo pārskats par normatīvo aktu bāzi un iespējamajām izmaiņām, kas ļautu autorizēt Lietotāju, kā tiešo informācijas iesniedzēju, bez kuģu aģentu starpniecības.

  • Problēmsituāciju analīze. ES un nacionālā līmeņa līdzšinējo aktivitāšu, par centieniem nodrošināt satelītu sakariem un mobilajiem sakariem alternatīvu un pieejamu datu apraidi, apraksts, rezultāti. Analīzē jāiekļauj vismaz 3 (trīs) I –CaDE līdzvērtīgu tīklu ieviešanas analīze ES dalībvalstīs. Apsekojumos un statistikas analīzē konstatētās problēmas un kritiskie faktori attiecībā uz datu iesniegšanu ar definētā pārklājuma zonā pieejamu datu apmaiņu. Potenciālo Prototipa darbības traucējumu apzināšana un to ietekmes samazinājumu scenārijs;

  • Ieviešanas scenāriji. Ieviešanas scenāriji prototipa pieejamības nodrošināšanai Latvijas ostās un citās ES dalībvalstīs. Scenārijs, iesniegto datu, tālākai integrēšana SKLOIS/SSN sistēmas vidē, tādā mērā, ka tiek nodrošināta definētajā pārklājuma zonā autorizēta Lietotāja datu akceptēšana tieši SKLOIS/SSN. Priekšlikumi normatīvo aktu bāzes pielāgošanai, lai datu iesniegšanas rezultātā iegūtā informācija tiktu uzskatīta par pilnvērtīgu SKLOIS/SSN informāciju, un netiktu pieprasīta tās atkārtota iesniegšana SKLOIS/SSN sistēmā.

  • Testēšanas metodoloģijas apraksts. Testēšanas metodoloģijas apraksts satur prasības akcepttestēšanai iesaistot : vismaz 2 (divus) kuģus kas veic datu apmaiņu kuģis – krasts - kuģis un kuģis – kuģis - krasts, iespējai iesniegt Tab. 1 norādītos dokumentus; SKLOIS/SSN sistēmas testa vidi; uz KAD bāzes stacijām izvietotas iekārtas, un „InDTra” konvertēšanas tehnoloģiju. Testēšanas metodoloģijas dokumentācija ietver: testēšanas plānu, testēšanas procedūras specifikāciju, testēšanas žurnālu, akcepttesta problēmu protokolu formātu un testēšanas kopsavilkuma ziņojumu. Vismaz šādi testēšanas kritēriji ir iekļaujami testēšanas dokumentācijā: datu pārraides ātrums, tīkla pārklājuma zonā, tās stabilitāte attiecībā pret vides apstākļiem, minimālais datu pārraides ātrums pie maksimālā tīkla noslogojuma, Lietotāja termināla darbības stabilitāte.

  • Pieredzes pārneses (demonstrāciju) aktivitāšu saraksts. I-CaDE prototipa pieredzes pārneses iespēju novērtējums un demonstrācijas aktivitāšu saraksts pēc vismaz šādas izstrādāta risinājuma ietekmes: kuģošanas informācijas un ostu formalitāšu iesniegšanas atvieglošana, integrēšana ES dalībvalstu vienota loga sistēmās, ekonomiskais izdevīgums, efektivitāte salīdzinājumā ar esošiem risinājumiem, trūkumi.

  • Efektivitātes novērtēšanas metodika. Metodika nosaka paņēmienu, izstrādātā Prototipa būtisko kritēriju efektivitātes novērtēšanai (mēra pakāpi) attiecībā pret sasniedzamo I-CaDE rezultātu vismaz pēc šādiem kritērijiem: kuģošanas informācijas un ostu formalitāšu iesniegšanas atvieglošana, integrēšana ES dalībvalstu vienota loga sistēmās, ekonomiskais izdevīgums, efektivitāte salīdzinājumā ar esošiem risinājumiem, trūkumi.

      1. Konceptuālais projektējums

Plānotā risinājuma (vīzijas) apraksts. Tā ietvaros Piegādātājs, ņemot vērā precizētu Pasūtītāja vajadzību izpratni, kā arī iepirkuma prasības un savu piedāvājumu, sagatavo Prototipa risinājumu aprakstu, kurā iekļauj funkcionalitātes, izmantojamo, tehnisko un programmatūras risinājumu aprakstu, izveides un ieviešanas grafiku, kā arī citus, ar Prototipa izveidi saistītos aspektus. Pretendentiem piedāvājumu iesniegšanas periodā iespējams iepazīties ar KAD infrastruktūru, pēc pieprasījuma iesniegšanas klātienē vai arī apmeklēt bāzes stacijas izvietošanas vietu, kādu paredzēts izmantot prototipa risinājuma izvietošanai.

Pēc apraksta saskaņošanas ar Pasūtītāju, kā starpposmu izstrādē Piegādātājs sagatavo konceptuālu projektēšanas aprakstu, kurā ir izklāstīti konceptuālie risinājumi un, tiek aprakstītas risinājuma komponentes, to savstarpējā saistība. Konceptuālais projekta apraksts jāprezentē tam paredzētā seminārā un jāsaskaņo ar Pasūtītāju. Pamatojoties uz saskaņoto konceptuālo projektējumu, Piegādātājam jāsagatavo pārējās prasības. Konceptuālais projekts ir iekļaujama dokumentācijas atsevišķa sadaļa.

    1. Tehniskā prototipa izstrādes posms nodevuma apraksts

Izstrādātājam jāveic pilnvērtīga Prototipa funkcionalitātes izstrāde saskaņā ar Pasūtītāja iepirkumā noteiktajām prasībām un I posma rezultātiem.

      1. Prototipa funkcionalitātes izstrāde

Piegādātājam jāveic pilnvērtīga Prototipa funkcionalitātes izstrāde, saskaņā ar iepirkuma prasībām un analīzes posma rezultātiem.

      1. Prototipa savietojamība ar SKLOIS/SSN sistēmu

        1. Pasūtītājs nodrošinās lietotāju piekļuve testa SKLOIS/SSN vidē caur interneta pārlūka saskarni,

        2. Uz prototipa testēšanas periodu, jānodrošina VILDA apakšprojekta InDTra komponentu - Attālināta Vides moduļa un, strukturēta datu kopuma, (iesniegšana ar e-pasta palīdzību), pārraidīšana no Lietotāja uz SKLOIS/SSN. Pasūtītājs ir atbildīgs par Attālinātā Vides moduļa un strukturēta datu kopuma iesniegšanu Izpildītājam, ne vēlāk kā 2 nedēļas pirms testēšanas (3. posma) uzsākšanas. Pēc Izpildītāja pieprasījuma, Pasūtītājs iesniedz Izpildītājam saistošo informāciju par VILDA apakšprojektu InDTra.

      2. Lietotāja nodrošinājums

Piegādātājs izsniedz, piegādā un uzstāda vismaz 2 (diviem) lietotājiem tīkla lietošanas iekārtu komplektus (terminālus). Piegādātājs izvēlās Lietotājus un par tiem informē Pasūtītāju. Pasūtītājs veic Lietotāju autorizāciju SKLOIS/SSN testa vidē.

      1. Izmantojamie standarti un vadlīnijas

Izstrādātājam jāņem vērā vismaz šādos standartos un vadlīnijās noteiktais: AQAP 2210: 2006; AQAP 2110:2009; ISO/IEC 27002, IEEE 1016:1998; LVS 72:1996; 12207:2008; IEEE J-STD-016, ISO/IEC 9001 vai līdzvērtīgos.

      1. Pavadošā dokumentācija

Pavadošajā dokumentācijā jāietver:

- sistēmas konceptuālais projektējums

- uzstādīšanas un administrēšanas rokasgrāmata, kas satur instrukcijas instalēšanai, prototipa pieslēgumu un parametru konfigurēšanai;

4.3. Tehniskā prototipa testēšana

Piegādātājs nodrošina testēšanu atbilstoši I. posmā izstrādātajai metodikai un dokumentācijai.

Piegādātājam jānodrošina Prototipa testēšana, kas aptver pilnvērtīgu testu veikšanu visām komponentēm, gan arī šo komponenšu savstarpējai darbībai un integrācijas pārbaudēm (testiem) ar SKLOIS/SSN sistēmu un Lietotāju informācijas sistēmām. Testēšana (izņemot akcepttestēšana) jāveic, izmantojot Piegādātāja tehnisko infrastruktūru bez papildu samaksas. Apakšprojekta „InDTra” konvertēšanas tehnoloģijas pieejamību nodrošina Pasūtītājs.

4.3.1. Veiktspējas un darbības pārbaude testēšana. Piegādātājam testēšanas ietvaros veic tīkla un to komponenšu drošības pārbaudes, lai pārliecinātos par tīkla neautorizētu izmantošanu vai datu rediģēšanas iespējām. Piegādātājam testēšanas ietvaros jāveic Prototipa un to komponenšu veiktspējas pārbaudes, lai pārliecinātos par prototipa arhitektūras realizācijas piemērotību atbilstoši specifikācijā noteiktajām veiktspējas prasībām, kā arī, lai identificētu iespējamos risinājumus prototipa darbības uzlabošanai. Testēšanas procesā jāveic funkcionālie testi atsevišķi visām Prototipa lietotāju lomām, pārbaudot, vai lietotājiem faktiski pieejamā funkcionalitāte ir atbilstoša sistēmas dokumentācijā noteiktajiem lietotāju lomu apgabaliem.

    1. Efektivitātes novērtējums

Efektivitātes analīzes tiek veikta pēc metodoloģijas, kas saskaņota ar Pasūtītāju. Efektivitātes analīzes novērtēšanas procesā jāveic vismaz 30 (trīsdesmit) Lietotāju intervijas gan ar institūcijas pārstāvjiem gan ar kuģošanas līnijām (iesaistītiem komersantiem)

    1. Demonstrācijas izstrādes process

Piegādātājs sagatavo gala ziņojumu (kopsavilkumu) par projekta realizāciju pēc izstrādātā risinājuma ietekmes: kuģošanas informācijas un ostu formalitāšu iesniegšanas atvieglošana, integrēšana ES dalībvalstu vienota loga sistēmās, ekonomiskais izdevīgums, efektivitāte salīdzinājumā ar esošiem risinājumiem, trūkumi. Kopsavilkumu sagatavo uz ne vairāk kā 25 lapaspusēm sinhroni latviešu un angļu valodā, un iesniedz to Pasūtītājam saskaņošanai. Pēc saskaņošanas Piegādātājs nodrošina tā pavairošanu vismaz 50 eksemplāros. Piegādātājs arī iesniedz Pasūtītājam kopsavilkumu Microsoft Office word formātā ( vai līdzvērtīgā).

      1. Atpazīstamība. Izstrādātājs izstrādā un nodrošina, ka saskaņojot ar Pasūtītāju, tā adresē Xxxxxx xxxx 0x, Rīgā, tiek izvietots informatīvs materiāls, kas informē, ka Krasta apsardze dienesta tiek īstenots konkrētais projekts.

      2. Uzskates materiāli. Izstrādātājs sagatavo vismaz 1 (vienu) vizuālu prezentāciju un informācijas brošūru 2 (divās) valodās: latviešu un angļu valodā. Nodevuma formāts: prezentācija un elektroniska datne, kura izmantojama brošūru pavairošanai tipogrāfijā (Izpildītājam jāveic vismaz 50 (piecdesmit) gab. brošūru piegāde katrai valodai – divpusēja, krāsaina, glancēta brošūra, katras brošūras apjoms 1 (viena) A4 formāta lapa). Izpildītājs nodrošina konsultatīvu atbalstu Pasūtītājam vismaz 2 (divu) publikāciju sagatavošanai un vismaz 1 (vienai) prezentācijai dalībai Eiropas līmeņa pasākumā.

      3. Publicitāte. Demonstrācijas aktivitāšu gaitā Piegādātājs nodrošina Pasūtītāju ar vismaz 3 (trīs) sagatavotiem tekstiem latviešu un angļu valodā, kas satur vismaz 300 (trīs simti) vārdu un, kas paredzēti preses relīzēm ar aktuālo informācija par projekta īstenošanas gaitu ar atsauksmi uz Projekta vadītāju mājas lapu xxx.xxxxxxx.xx;

      4. Demonstrācija. Izstrādātājs nodrošina konsultatīvu atbalstu Pasūtītājam vismaz 2 (divas) publikāciju sagatavošanai un, nozīmē savu pārstāvi par Piegādātāja resursiem vismaz 1 (vienai) dalībai Eiropas līmeņa pasākumā projekta demonstrācijai.

5. Organizatoriskās prasības

5.1. Piegāde

Piegādātājam ir jāveic darbi un jāpiegādā šajā specifikācijā nosauktie nodevumi, saskaņā ar šīs specifikācijas prasībām, iepirkuma līguma nosacījumiem, Latvijas Republikas normatīvo aktu un Eiropas Komisijas direktīvu prasībām, Latvijas Republikas un starptautiskajiem programmatūras izstrādes standartiem. Dokumentācijas nodevumi, plāni, protokoli, pārvaldības u.c. Projekta dokumentācija un tehniskie pielikumi ir jāiesniedz Pasūtītājam latviešu un angļu valodā elektroniski rediģējamā (MS Office atpazīstamā) formātā un jāiesniedz 3(trīs) kopijas uz CD diskiem un 2 (divos) drukātos eksemplāros parakstīšanai – katrai pusei vienu eksemplāru. Piegādātājam jāpiegādā dokumentācijā ietverto shēmu un attēlu izejas materiāli (elektroniski rediģējamā formātā). Jānodod lietošanā Pasūtītāja autorizētiem pārstāvjiem, tam izmantojot savu personālu, materiālus, inventāru un transportu. Piegādes nosacījumi dokumentācijai:

  • jābūt tādai, lai trešajām pusēm būtu iespējams pārliecināties par to, ka projekta realizācija un ieviešana ir notikusi saskaņā ar izvirzītajām prasībām un nozares labo praksi;

  • jābūt tādai, lai sistēmas lietotājiem tiek sniegta visa nepieciešamā informācija, lai viņi patstāvīgi un pilnvērtīgi varētu izmantot sistēmas piedāvāto funkcionalitāti;

  • sistēmas administratoriem ir pieejama nepieciešamā informācija par sistēmas nepārtrauktu darbības nodrošināšanu atbilstoši sistēmas specifikai;

  • Pirms visu dokumentu nodevumu izstrādes uzsākšanas, Piegādātājs saskaņo dokumentu nodevumu sagatavju formātu ar Pasūtītāju. Piegādātājs nodrošina nodevumu savlaicīgu, vismaz 10 (desmit) darba dienas pirms nodevuma termiņa, iesniegšanu Pasūtītājam saskaņošanai.

5.2. Darba valoda

Izpildot darba uzdevumā minētos darbus, visa komunikācija ar Pasūtītāju jānodrošina latviešu valodā (nepieciešamības gadījumā Pretendentam par saviem līdzekļiem ir jānodrošina tulkojums).

5.3. Veiktspējas pieejamība

Pieejamībai jābūt ne mazākai nekā 99% (24*7 režīmā), par atskaites punktu pieņemot gadu (neskaitot paredzētos ar Pasūtītāju saskaņotos pārtraukumus). Katra ceturkšņa laikā pieļaujamie pārtraukumi nepārsniedz 22 (divdesmit divas) stundas, katra pārtraukuma ilgums nedrīkst pārsniegt 4 (četras) stundas.

5.4. Kvalitātes prasības, garantija.

Piegādātājs nodrošina prototipa funkcijas kļūdu novēršanu vismaz 1 (viens) gadu no nodošanas – pieņemšanas akta parakstīšanas.

      1. Pieejamība

Piegādātājam ir jānodrošina pasūtītāja pieteikumu saņemšana pa e-pastu, fiksētās līnijas telefonu un mobilo telefonu 24stundas diennaktī, saskaņā Pasūtītāja funkcionālo izmaiņu atbalsta pieteikumus klasifikāciju pēc sekojošām prioritātēm:

  • avārijas pieteikumiem reakcijas laiks ir ne vairāk kā 2 stundas, ja radusies neskaidrība par SKLOIS/SSN darbību, integrēto prototipa funkcionalitāti, vai ir radies datu bojājums, kā rezultātā SKLOIS/SSN sistēmai vai/ un Prototipam nav iespējama darbības turpināšana;

  • konsultācija/ kļūdu labošana pieteikuma reakcijas laiks ir ne vairāk kā 2 darba dienas, radusies neskaidrība par SKLOIS/SSN darbību, integrēto prototipa funkcionalitāti, ir radies datu bojājums, ir atklāta funkcionalitātes, savietojamības vai programmēšanas kļūda. SKLOIS/SSN sistēmai vai/ un Prototipam ir iespējama darba turpināšana bez būtiskiem ierobežojumiem vai ir pieejams problēmas apiešanas risinājums.

Reakcijas laiks ir laiks no pieteikuma saņemšanas brīža līdz brīdim, kad izpildītājs paziņo, ka pieteikums ir saņemts un ir uzsākta pieteikuma apstrāde.

5.5. Informētība.

Piegādātājs nodrošina apmācību vismaz 4 (četri) cilvēkiem –informēšanai par būtiskiem aspektiem platformas lietošanā, to administrēšana un pasākumi, kas nepieciešami sistēmā to pilnvērtīgai funkcionēšanai.

Pielikums Nr. 3.3.

Konkursa, identifikācijas

Nr. VAMOIC 2014/171, nolikumam

TEHNISKĀ SPECIFIKĀCIJA





Tehniskā specifikācija

Automatizētā risinājuma izstrāde, kuģošanas informācijas un ostu formalitāšu datu atpazīšanai


Saturs:



Vispārīga informācija par iepirkuma priekšmetu


Mērķis: datu kvalitātes uzlabošanas iespēju izpēte un datu kvalitātes uzraudzības risinājuma prototipa izstrāde un integrēšana ar Latvijas nacionālajām sistēmām SKLOIS (un tās bāzes sistēmu SSN).

Rezultāts: izpētes materiāli un ar SKLOIS/SSN integrēts tehniskais prototips.

Izmantotie termini:

ES

Eiropas Savienība

KAD

Krasta apsardzes dienests

EMSA

Eiropas Jūras drošības aģentūra

XXXX

Xxxxxxxxx valstu pārvaldes iestāžu tīkli

MSW

Jūras vienotais logs

NSW

Nacionālais Jūrniecības vienotais logs

VILDA

Vienots informācijas logs jūrniecības un loģistikas datu administrēšanai

ETA

Plānotais pienākšanas laiks

ETD

Plānotais atiešanas laiks

AIS

Automātiska identifikācijas sistēma

MRS

Obligātā kuģošanas ziņošanas sistēma

CVTS

Krasta kuģu satiksmes dienests

SKLOIS

Starptautiskā kravu loģistikas un ostu informācijas sistēma

SSN

Kuģu satiksmes uzraudzības un informācijas datu apmaiņas sistēma

ES SSN

Eiropas Jūras drošības aģentūras uzturētā SafeSeaNet sistēma

FAL

Konvenciju par starptautiskās jūras satiksmes atvieglošanu

MIG

Ziņojuma ieviešanas vadlīnijas


Dokumenta lietotāji:

Tehniskā specifikācija ir paredzēta šādām lietotāju grupām:

  1. Pasūtītājam Jūras spēku flotiles Krasta apsardzes dienests (turpmāk – KAD) – iepirkuma procedūras organizēšanai, pretendentu piedāvājumu novērtēšanai, līguma izpildes kontrolei;

  2. Pretendentiem (izpildītājam) - piedāvājuma sagatavošanai, kā sākotnējais materiāls Projekta plānošanai, analīzes veikšanai un detalizētās programmatūras prasību specifikācijas sagatavošanai.

Esošās situācijas raksturojums

Latvijai, pildot Direktīvas 2010/65/ES prasības, līdz 2015.gada 1.jūnijam ir jārealizē vienas pieturas aģentūras princips. Nacionālo Bruņoto spēku Jūras spēku Flotiles Krasta apsardzes dienesta uzturētā Kuģu satiksmes uzraudzības un informācijas datu apmaiņas sistēma (SSN) kopā ar jaunveidojamo Starptautisko kravu loģistikas un ostu informācijas sistēmu (SKLOIS) ir Latvijas vienas pieturas aģentūras risinājuma pamats. SSN attīstību nosaka Ministru kabineta (turpmāk – MK) 2009.gada 4.augusta noteikumi Nr.857 „Kārtība, kādā nodrošināma sakaru tīklu darbība Kuģu satiksmes uzraudzības un informācijas datu apmaiņas sistēmas ietvaros” un MK 2012.gada 15.maija noteikumi Nr.339 „Noteikumi par ostu formalitātēm”. SKLOIS projekta ietvaros ir paredzēts aktualizēt iepriekš minētos normatīvos aktus. Abi minētie MK noteikumi nacionālā līmenī transponē minēto Direktīvu 2010/65/ES.

Latvijas dalības XXXX MSW projekta virsmērķis ir veicināt aktīvu sadarbību starp ES dalībvalstīm un izstrādāt atbilstošus mehānismus, lai atvieglotu un harmonizētu ziņošanas formalitātes nacionālā un ES dalībvalstu līmenī.

XXXX MSW projekta mērķi ir:

- Sekmēt Direktīvas 2010/65/ES ieviešanu, stiprināt Eiropas ostu un jūras transporta konkurētspēju pasaules mērogā;

- Sekmēt visu iesaistīto pušu dalību vienotā elektroniskā informācijas telpā;

- Izveidot saskaņotu pieeju un efektīvu sadarbību starp privāto un publisko sektoru;

- Dalībvalstīs sekmēt bottom-up pieeju, lai realizētu vienas pieturas aģentūras projektu;

- Izveidot sistēmu, kas sekmētu savietojamību starp datu sniedzējiem, publisko sektoru un loģistikas ķēžu operatoriem.

Aizsardzības Ministrija ir sagatavojusi izpētes un attīstības projektu „Vienots informācijas logs jūrniecības un loģistikas datu administrēšanai” (turpmāk - VILDA). VILDA paredz pētīt un izveidot vienotu telpu datu apmaiņai jūrniecības un loģistikas informācijai gan nacionālā, gan ES līmenī, saskaņā ar ES Direktīvas 2010/65/ES prasībām.

VILDA projekta ietvarā tiks realizēti četri apakšprojekti, kas nodrošinās vienas pieturas aģentūras principu visos trīs līmeņos datu iesniegšanai, apstrādei un apmaiņai nacionālā un ES līmenī:

- 1.apakšprojekts: Vienas pieturas aģentūras princips ar vienotu grafisko saskarni datu apmaiņai (NaMSW). Apakšprojekta mērķis ir pilnveidot nacionālo SSN sistēmu līdz vienas pieturas aģentūras līmenim nodrošinot Direktīvas 2010/65/ES ieviešanu sadarbībai starpinstitūciju līmenī (Mid Office). Apakšprojektā paredzētās aktivitātes ir vienotas grafiskās saskarnes izveidošana vienotam informācijas logam. Datu apmaiņa ar XXXX MSW projekta dalībvalstīm pēc Pull/Push principa. Pētīt un realizēt drošu datu apmaiņu starp nacionālām institūcijām un ES dalībvalstīm.;

- 2. apakšprojekts: Uzlaboti sakari un datu apmaiņa (I-CaDE). Apakšprojekta mērķis ir pilnveidot komunikāciju un uzlabot datu plūsmas principus, padarot lietotājiem pieejamākus vienas pieturas aģentūras elementus. Apakšprojekta realizācijas laikā tiks pētīta iespēja uzlabot sakaru un datu apmaiņas principus starp vienotu informācijas logu un tā tiešajiem datu un informācijas sniedzējiem – kuģiem. Apakšprojekta eksperimentālajā fāzē sakaru un datu tīkla darbības pierādīšanai tiek plānots izmantot KAD krasta infrastruktūru un iesaistīt kuģus, kas kuģo uz/no Latvijas ostām un NBS kuģus, kas nodrošina krasta apsardzes funkciju veikšanu atbildības rajonā. Projekts paredz uzlabot vienas pieturas aģentūras darbības principus, kā arī kopumā uzlabot kuģošanas drošību un drošumu;

- 3. apakšprojekts: Automatizētā risinājuma izstrāde, kuģošanas informācijas un ostu formalitāšu datu atpazīšanai Uzlabota datu kvalitāte kuģošanas režīma uzraudzībai (I-DatQ). Apakšprojekta mērķis ir pētīt un praksē pierādīt iespēju pilnveidot kuģu sniegto datu kvalitātes kontroles mehānismus, nodrošinot Direktīvas 2010/65/ES prasību izpildi. Projekta ietvaros paredzēts modelēt instrumentu datu uzraudzībai, sistemātiskas un automatizētas kontrolpārbaudes veikšanai, atvieglot administratīvās procedūras gan valsts iestādēm, gan uzņēmējiem. Uzlabotā kontroles sistēma ļaus KAD, kā atbildīgai institūcijai par datu kvalitāti un datu apmaiņu ar ES dalībvalstīm, ikdienā nodrošināt visefektīvāko datu kontroles metožu izmantošanu;

- 4. apakšprojekts: Inteliģents datu tulkošanas modulis vienas pieturas aģentūras principa atbalstam (InDTra). Apakšprojekta mērķis ir izstrādāt un praksē pierādīt vienas pieturas aģentūras inteliģentā moduļa darbību, kas nodrošinās datu apstrādi: tulkošana, sinhronizācija un maršrutēšana vienotā informācijas loga lietotājiem, nodrošinot tiešsaisti ar informācijas sniedzējiem, kas izmanto atšķirīgus datu iesniegšanas standartus (piemēram, kuģi, kas nepakļaujas ES normatīvo aktu prasībām par datu aprites standartiem). Apakšprojektā paredzētās aktivitātes ir datu apstrādes moduļa izstrāde, testēšana un saslēgšana ar SSN sistēmu, pilnveidojot vienota informācijas loga darbību un samazinot administratīvo slogu gan valsts iestādēm, gan uzņēmējiem.

Konkrētā iepirkuma mērķis

VILDA pilotprojekta „Uzlabota datu kvalitāte kuģošanas režīma uzraudzībai (I-DatQ)” mērķis ir pētīt un praksē pierādīt iespēju pilnveidot kuģu sniegto datu kvalitātes kontroles mehānismus, nodrošinot Direktīvas 2010/65/ES prasību izpildi. Projekta ietvaros paredzēts modelēt instrumentu datu uzraudzībai, sistemātiskas un automatizētas kontrolpārbaudes veikšanai, tādā veidā atvieglojot administratīvās procedūras gan valsts iestādēm, gan uzņēmējiem. Uzlabotā kontroles sistēma ļaus KAD, kā par datu kvalitāti un datu apmaiņu ar ES dalībvalstīm atbildīgai institūcijai, ikdienā nodrošināt visefektīvāko datu kontroles metožu izmantošanu. Projekta ietvaros paredzēts pētīt un praksē pierādīt iespēju no pirmavota iegūt kuģošanas informāciju un ostu formalitātēs iekļautos datus, pielietojot automatizētu meklēšanas rīku. Informāciju saturošās sistēmās un datu apmaiņas kanālos tiek veikta datu skenēšana, uztverot un korelējot ostā pieteiktā kuģa SKLOIS/SSN iesniedzamo informāciju pirms tā pienākšanas vai atiešanas no piestātnes, tādā veidā nodrošinot Direktīvas 2010/65/ES prasību izpildi par vienreizēju kuģošanas vai ostu formalitāšu informāciju saturošu datu iesniegšanu, nodrošinot datu aktualitāti un autentiskumu. Projekta ietvaros paredzēts modelēt instrumentu datu caurlūkošanai, korelācijai (sistemātiskas un automatizētas kontrolpārbaudes veikšanai) un automātiskai iesniegšanai SKLOIS/SSN sistēmā, atvieglot administratīvās procedūras gan valsts iestādēm, gan uzņēmējiem. Kā I-DatQ nodevumam jābūt definētiem kritērijiem un piedāvātiem risinājumiem, kā izveidot MSW iesniedzamo kuģošanas drošības un ostas formalitāšu datus saturošas informācijas atpazīšanu no dažādām sistēmām, kas uzskatāmas par datu pirmavotiem, tādā veidā nodrošinot Direktīvas 2010/65/EK prasību izpildi par informācijas vienreizēju iesniegšanu. Realizācijas procesā nepieciešams modelēt un testēt platformu (vai citu risinājumu) datu filtrēšanai, korelācijai un integrēšanai MSW, lai tiktu atvieglotas administratīvās procedūras gan kompetentajām iestādēm, gan SKLOIS/SSN MSW lietotājiem, kam ir pienākums iesniegt informāciju ostas formalitāšu kārtošanai.

Izstrādājamais prototips

I-DatQ realizācijas ietvaros paredzēts izveidot datu atpazīšanas programmatūras prototipu, kas paredzēts, lai atvieglotu un uzlabotu kuģošanas nozares (specifiski starptautiskajā jūras satiksmē iesaistītajiem kuģiem (turpmāk - lietotājs)) informācijas sistēmu savstarpējo datu apmaiņu kuģis – krasts – kuģis, papildus nodrošinot, ka netiek radīta administratīvā barjera dokumentu apstrādei t.i. datu apmaiņai kuģis – krasts – kuģis. Kuģošanas un ostu obligātās informācijas apmaiņas neprecizitātes un kļūmes palielinās līdz ar dažādu līmeņu piekļuvēm, datu formatēšanas un pārraidīšanas tehnoloģiju attīstību. Līdz ar to, veicot ostas formalitāšu apmaiņu datu vairākos datu apmaiņas kanālos (terminālu sistēmas, kuģu satiksmes uzraudzības sistēmas, krasta sakaru sistēmās, automātiskās identifikācijas sistēmas) bez korelācijas algoritmu pielietošanas, tieša datu pārnese uz vienotā loga formām var saturēt būtiskas kļūdas. Šī projekta mērķis ir pētīt datu kvalitātes uzraudzības iespējas un prototipa līmenī testēt reālā vidē dažādus scenārijus, lai izveidotu risinājumu, kas pietuvināts reāliem kuģošanas informācijas apmaiņas scenārijiem, atpazīstot individuāla kuģa datu kopumu no informācijas sistēmu saskarnēm un apmaiņas kanāliem, pirms individuālā kuģa obligātās ziņošanas veikšanas vienotā informācijas logā, un iegūtās informācijas integrēšanu noteiktajā ziņošanas procesā, kā arī izveidot un testēt korelācijas algoritmu vai programmatūru, kas veic iegūto datu korelēšanu un indikācijas (iezīmēšanas) funkciju, vēršot uzmanību uz SKLOIS/SSN un piesaistīto sistēmu apritē esošo kļūdaino (atšķirīgo) informāciju.

Pilotprojekta I-DatQ nodevumam ir jābūt definētiem kritērijiem un piedāvātiem risinājumiem, kā izveidot MSW iesniedzamo kuģošanas drošības un ostas formalitāšu datus saturošas informācijas atpazīšanu no dažādām sistēmām, kas uzskatāmas par datu pirmavotiem, tādejādi nodrošinot Direktīvas 2010/65/EK prasību izpildi par informācijas vienreizēju iesniegšanu. Realizācijas procesā nepieciešams modelēt platformu (vai citu risinājumu) datu caurlūkošanai, korelācijai un integrēšanai MSW, lai tiktu atvieglotas administratīvās procedūras gan kompetentajām iestādēm, gan SKLOIS/SSN NSW lietotājiem, kam ir pienākums iesniegt ostas formalitātes. Prototipa darbība aptvers 5 (piecas) kuģu reģistrācijas procedūras:

1. procedūra: Kuģu vizītes pieteikšana un kuģu ienākšana Latvijas ostās, ostas formalitāšu kārtošana, kontrole. Procesa ir četri apakš procesi, kas sadalīti atbilstoši veicamu darbību periodiem:

- kuģu vizītes plānošana un darbības 72 stundas pirms ienākšanas ostā;

- kuģu vizītes plānošana un darbības 24 stundas pirms ienākšanas ostā;

- kuģu vizītes plānošana un darbības 2 stundas pirms ienākšanas ostā;

- kuģu ienākšana ostā.

2. procedūra: Kuģu pārtauvošanas (ostā un ostas akvatorijas ietvaros) saskaņošana, ostas formalitāšu kārtošana, kontrole.

3. procedūra: Kuģu iziešanas saskaņošana, ostas formalitāšu kārtošana, kontrole (1.procesam pretējs process).

4. procedūra: Kuģu pieteikumu ienākšana/iziešana Latvijas ostās, ostas formalitāšu kārtošana ar atcelšanas iespēju;

5. procedūra: Kuģu pieteikumu ienākšana/ iziešana Latvijas ostās, ostas formalitāšu kārtošana ar iespēju to papildināt vai atjaunot dinamisko informāciju (Update);

Projekta ietvaros tiks praksē pierādīts izvirzītais mērķis nodrošināt vienas pieturas aģentūras principu vismaz šādu Tab. 1 un Tab.2 norādīto dokumentu atvieglotai iesniegšanai:

Dokuments

Atšifrējums

FAL 1. veidlapa

Vispārīgā deklarācija

FAL 2.veidlapa

Kuģa manifests

FAL 3.veidlapa

Kuģa krājumu deklarācija

FAL 4. veidlapa

Apkalpes mantu deklarācija

FAL 5. veidlapa

Apkalpes saraksts

FAL 6. veidlapa

Pasažieru saraksts

Tab. 1: FAL veidlapas, kas ir obligātas saskaņā ar FAL Konvenciju par starptautiskās jūras satiksmes atvieglošanu (turpmāk - FAL konvencija), starptautiskajā jūras satiksmē iesaistītajiem kuģiem.

Dokuments

Atšifrējums

HAZMAT

Paziņošana par bīstamu un piesārņojošu kuģa kravu

Paziņošana par kuģa atkritumiem

Paziņojumu par atkritumu nodošanu

Aizsardzības informācijas deklarācija

Aizsardzības informācijas deklarācijas iesniegšana

Veselības deklarācija

Paziņojums par kuģa sanitāro stāvokli un apkalpes veselību

Paziņošana par personu, kas uz kuģa nokļuvusi un uzturas uz tā nelegāli

Paziņošana par personām, kas nokļuvušas un uzturas uz kuģa nelegāli

Tab. 2: Ostu formalitātes, kas noteiktas citos normatīvajos aktos.

Prototipa platformas risinājums ir integrējams SKLOIS/SSN.



Vispārējs darba uzdevums un termiņi

Vispārējs apraksts

      1. Kvalitātes uzraudzības mehānismu identificēšana

Projekta sākotnējā posmā paredzēts veikt datu kvalitatīvās analīzes iespēju izpēti, konkrēti identificējot:

  1. datu kopu, kas pakļaujama kvalitātes uzraudzībai un analīzei;

  2. atbilstošo datu avotus un piekļuves mehānismus šiem avotiem;

  3. datu kvalitātes mērījumu (x.xx., korelēšanas) algoritmus;

  4. notifikāciju mehānismus konstatētajos kvalitātes noviržu gadījumos.

Datu kvalitātes mērījumu algoritmiem jābūt paredzētiem trīs līmeņos:

1. Līmenis: statisko datu salīdzināšana. Korelācijas procesa rezultātā tiek iegūts, kuģa statisko datu kopums, kas atzīts par pareizu, vai nepareizu. Pareizu datu tālāka atzīmēšana netiek veikta (t.i., dati drīkst tikt nodoti datu attēlošanai SKLOIS/SSN sistēmā un var tikt automātiski akceptēti no SKLOIS/SSN sistēmas puses). Nepareizu datu apstrāde paredz kļūdas marķēšanu un tālākās rīcības indikācijas pievienošanu pirms nodošanas SKLOIS/SSN. Atbilstošā apstrāde notiek šādi: identificējot anomāliju (kļūdu), tā tiek marķēta SKLOIS/SSN sistēmai atpazīstamā veidā. Marķējums satur informāciju par kļūdas avotu un indikāciju tālākai reaģēšanai.

2. Līmenis: dinamisko datu salīdzināšana. Korelācijas procesa rezultātā tiek iegūts kuģa dinamisko datu kopums, kas atzīts par pareizu, vai nepareizu. Pareizu datu tālāka atzīmēšana netiek veikta, bet nepareizu datu gadījumā tiek piemērots analogs algoritms kā paredzēts 1.līmenī.

3. Līmenis: korekcijas scenārija identificēšana. Konstatētās kļūdas tiek pakļautas speciali tam paredzētam kļūdainu datu apstrādes procesam, kas paredz kļūdas marķēšanu un tālākās rīcības indikācijas pievienošanu pirms nodošanas SKLOIS/SSN apstrādei. Process notiek šādi: identificējot anomāliju (kļūdu), tā tiek marķēta SKLOIS/SSN sistēmai atpazīstamā veidā. Marķējums satur informāciju par kļūdas avotu un indikāciju tālākai reaģēšanai.

Posmā rezultātā tiek sagatavots analītiskais materiāls un precizētas prasības tehniskā prototipa izstrādei. Šajā posmā pasūtītāja atbilstībā ir komunikācija ar trešajām pusēm un datu avota sistēmu turētājiem, saistītā organizatoriskā atbalsta sniegšana, bet izpildītājam ir jāveic saistītais pētnieciskais darbs, pamatojoties uz pieejamo informāciju.

      1. Tehniskā prototipa komponentes un vispārējā darbības

Tehniskajam prototipam jāietver šādas komponentes:

1. Izgūšanas komponente: kvalitātes kontrolei pakļaujamo SKLOIS/SSN iesniegto kuģa datu izgūšana no iesniegtajiem datiem (orientējošā datu kopā – kuģa identifikācijas un aprakstošie pamatdati, kuģa vizītes pamatdati);

2. Monitoringa komponente: izgūto datu kvalitatīvā analīze, ieskaitot salīdzināšanu ar datiem pasūtītāja norādītajās ārējās sistēmās (orientējoši – vismaz 6 neatkarīgām sistēmām piem. LRIT DC, VMS, Ostas IS, CVTS (MRS), SAT-AIS, EU SSN) – sistēmu skaits un salīdzināmo datu apjoms atkarīgs no reāli pieejamajām saskarnēm un sistēmas uzkrājamajiem datiem;

3. Notifikāciju komponente: konstatēto datu kvalitātes problēmu (datu atšķirību) novadīšana līdz lietotājam manuālai problēmas apstrādei un korekcijai (ja nepieciešams) SKLOIS/SSN.

Prototipam jānodrošina tā uzstādīšanai un lietošanai nepieciešamā tehniskā pavaddokumentācija un jānodrošina garantijas uzturēšana 12 mēnešu laikā pēc prototipa nodošanas. Prototips ir integrējams SKLOIS/SSN.

Papildus informācija par CVTS

Krasta kuģu uzraudzības sistēma (CVTS) nodrošina automātisku informācijas saņemšanu pēc principa kuģis – krasts, kuģim ienākot CVTS darbības zonā (kas ir MRCC rajons) ar speciālu tam izstrādātu SSN paplašinājumu. Automātiskais ziņojums ietver informāciju: kuģa vārds, izsaukuma signāls, IMO numurs, mērķa osta, kravas tips atbilstoši Direktīvā noteiktajam iedalījumam), apkalpes skaits. AIS atpazītie kuģa dati automātiski tiek reģistrēti SSN sistēmā. Automātiski tiek veida datu pārbaude ES SSN sistēmā, tādiem datiem, kā kuģis ar liegumu, bīstamās kravas uz borta, apkalpes un pasažieru skaits, incidenti), lai nodrošinātu informācijas korelācijas atbilstoši 3.līmeņa pārbaudei. Kuģi, kas pakļaujas CVTS datu automātiskai uztveršanai, ir starptautiskā satiksmē iesaistītie kuģi, kas veic obligāto ostas formalitāšu ziņošanu saskaņā ar starptautiskajām, ES un nacionālajām prasībām.

Papildus informācija par integrāciju ar SKLOIS/SSN

Kļūdu marķēšanas paziņojuma dizains pieskaņojams SKLOIS/SSN sistēmā esošajiem brīdinājuma signāliem un lietotāju logiem, saglabājot indikāciju par to, ka tiek atspoguļoti filtrēšanas un monitoringa rezultātā iegūtie dati.

      1. Atbilstība tiesību aktiem

Prototipa izveides un piegādes ietvaros, Izpildītājam ir jāņem vērā šādi saistošie tiesību akti:

      • FAL Konvencija par starptautiskās jūras satiksmes atvieglošanu;

      • Jūrlietu pārvaldes un jūras drošības likums;

      • Informācijas atklātības likums;

      • Dokumentu juridiskā spēka likums;

      • Elektronisko dokumentu likums;

      • 2013. gada 17. decembra Ministru Kabineta sēdes protokols Nr.67, 86.§Informatīvais ziņojums „Par papildu valsts budžeta saistību uzņemšanos Kuģu Satiksmes uzraudzības un informācijas datu apmaiņas sistēmas pilnveidošanai un Direktīvas 2010/65/ES ieviešanai”

      • Ministru kabineta 2010.gada 28.septembra noteikumi Nr. 916 „Dokumentu izstrādāšanas un noformēšanas kārtība”;

      • Ministru kabineta 2005.gada 28.jūnijā noteikumi Nr. 473 „Elektronisko dokumentu izstrādāšanas, noformēšanas, glabāšanas un aprites kārtība valsts un pašvaldību iestādēs un kārtība, kādā notiek elektronisko dokumentu aprite starp valsts un pašvaldību iestādēm vai starp šīm iestādēm un fiziskajām un juridiskajām personām”;

      • Ministru kabineta 2010. gada 13. aprīlī noteikumi Nr.357 „Kārtība, kādā iestādes sadarbojoties, sniedz informāciju elektroniskā veidā, kā arī nodrošina un apliecina šādas informācijas patiesumu”;

      • 2009. gada 4. augusta Ministru kabineta noteikumi Nr. 857 „Kārtība, kādā nodrošināma sakaru tīklu darbība Kuģu satiksmes uzraudzības un informācijas datu apmaiņas sistēmas ietvaros”

      • 2012. gada 15. maija Ministru kabineta noteikumi Nr.339 „Noteikumi par ostu formalitātēm”

      • Eiropas Parlamenta un Padomes 2002.gada 27.jūnija Direktīvas 2002/59/EK, ar ko izveido Kopienas kuģu satiksmes uzraudzības un informācijas sistēmu un atceļ Padomes Direktīvu 93/75/EEK;

      • Eiropas Parlamenta un Padomes 2009.gada 23.aprīļa Direktīvas 2009/17/EK, ar kuru groza Direktīvu 2002/59/EK, ar ko izveido Kopienas kuģu satiksmes uzraudzības un informācijas sistēmu;

      • Eiropas Parlamenta un Padomes 2010. gada 20. oktobra Direktīvas 2010/65/ES par ziņošanas formalitātēm kuģiem, kuri ienāk dalībvalstu ostās un/vai iziet no tām, un ar ko atceļ Direktīvu 2002/6/EK.

      • Šis „Automātiska, vienota datu apmaiņas saslēguma izstrādei starp ES dalībvalstīm ostas formalitāšu un kuģošanas drošības datu apmaiņai (NSW2NSW)” apakšprojekta darba uzdevums „Terms of Reference”, kas ir vienots ar projekta dalībniekiem ir neatliekama sastāvdaļa un šī Prototima izstrādes procesā Piegādātājam ir jāievēro darba uzdevumu „Terms of Reference” noteiktās prasības.


Darbu izpildes termiņi

Projekts veicams secīgos posmos (uzsākot katru pēc iepriekšējās pabeigšanas). Zemāk norādīti termiņi katras kārtas nodevumu iesniegšanai saskaņošanas uzsākšanai (skaitot no posma uzsākšanas dienas). Katra kārtas nodevumu saskaņošana tiks veikta ne ilgāk kā 10 darba dienu laikā.

Kārtas (posma) nr.

Nodevumu iesniegšanas termiņš / nodevumi

1.

Analīzes (pētījuma veikšanas) posms

Termiņš: 12 nedēļas

Nodevumi: Ziņojums (-i), Konceptuālais projektējums (x.xx. algoritmi)

2.

Tehniskā prototipa izstrāde

Termiņš: 24 nedēļas

Nodevumi: Tehniskais prototips, Pavaddokumentācija

3.

Tehniskā prototipa testēšana

Termiņš: 8 nedēļas

Nodevumi: Testēšanas ziņojums, Efektivitātes novērtējums

4.

Demonstrēšana, Pieredzes pārneses aktivitātes

Termiņš: 4 nedēļas

Nodevumi: Ziņojums (-i), Pieredzes pārneses dokumentācija


Detalizēts darba uzdevums

Analīzes (1.posma) nodevumu apraksts

Analīzes dokumentu sagatavošana notiek latviešu un angļu valodā. Nodevumu saturu var strukturēt sīkāk vai savādāk kā prasīts (nezaudējot saturisko apjomu), lai nodrošinātu apraksta dokumenta skaidrību un uztveramību. Analīzes izstrāde ir jāveic tādā detalizācijas pakāpē, lai tas sniegtu gan Pasūtītājam pilnu izpratni par esošo situāciju, iespēju izstrādāt projektu un izveidot prototipu, nodrošināt tā savietojamību ar esošo sistēmu un atbilstību Vienots informācijas logs jūrniecības un loģistikas datu administrēšanai (turpmāk – VILDA) ietvaram.

      1. Ziņojums

Ziņojumā iekļaujamas sekojošas nodaļas:

      • Statistikas ziņojums. Datu pirmavotu sistēmu veidi Latvijā un ES dalībvalstīs. Kļūdu (anomāliju) statistika un analīze, kas satur anomāliju gadījumu daudzumu un analīzi pēc cēloņiem. Izpildītājam jāiesniedz 2012., 2013. un 2014. gadā KAD reģistrēto informācijas aprites anomāliju gadījumu analīzes, pēc tādiem kritērijiem, kas raksturo anomālijas cēloni, kļūdas nozīmīgumu pēc tās nozīmīguma (piemēram, nebūtiska, būtiska vai ļoti būtiska kļūda). Analizējamos datus iesniedz Pasūtītājs, pēc Piegādātāja pieprasījuma. CVTS paplašinājuma izstrādes vajadzībām ziņojumā ir jāiekļauj informācija par MRCC atbildības rajonā veiktajiem jūras meklēšanas un glābšanas darbiem, par vismaz 30 gadiem no projekta realizācijas brīža.

      • Lietotāja profila apraksts. Apraksts ietver kuģu reģistrācijas procedūrās iesaistīto Lietotāju sarakstu un kompetenci. Tiek sagatavots detalizēts Lietotāju sistēmu apraksts, kuras tiek izmantotas Prototipa funkcionalitātes nodrošināšanai (tehnoloģijas un aizsardzības nosacījumu). Jāizstrādā interviju jautājumi un jāveic, galveno iesaistīto pušu intervijas (piem. MRCC koordinatoru, Latvijas Jūras administrāciju, stividoru kompānijām, kravu aģentiem, termināļiem, ostām), lai sagatavotu precīzu prasību definēšanu prototipa izstrādei;

      • Normatīvo aktu analīze. Jāsagatavo pārskats par normatīvo aktu bāzi un iespējamajām izmaiņām, kas ļautu autorizēt meklēšanas un filtrēšanas rezultātā iegūtās informācijas izmantošanu SSN bez aģentu akcepta, nodrošinot, ka tā atkārtoti netiek pieprasīta no kuģiem vai to aģentiem.

      • Ieviešanas scenāriji. Ieviešanas scenāriji saņemto datu tālākai apstrādei un integrēšanai SSN sistēmā. Tādā formātā, lai prototipa darbības rezultātā iegūtie dati būtu integrējami SSN sistēmā kā oficiāla kuģošanas drošības vai ostas formalitāšu informācija, nodrošinot, ka tā atkārtoti netiek pieprasīta no kuģiem vai to aģentiem. Priekšlikumi normatīvo aktu bāzes pielāgošanai, lai datu iesniegšanas rezultātā iegūtā informācija tiktu uzskatīta par pilnvērtīgu SSN informāciju, un netiktu pieprasīta tās atkārtota iesniegšana SSN sistēmā. Piegādātājam jāpiedāvā datu skanēšanas un korelācijas algoritmi prototipi ieviešanai, piesaistot vismaz 5 (piecus) datu sistēmas vai datu apmaiņas kanālus, no kuriem 2 (divi) obligātie ir Izstrādātāja izveidotas testa vides.

      • CVTS SSN paplašinājums testa vides apraksts. Latvijas piekrastes CVTS testa vides modelēšanas apraksts atbilstoši SOLAS 74 konvencijas prasībām un Starptautiskās jūras organizācijas (IMO) Asamblejas Rezolūcijai A.857(20), kā arī iekļaujot dokumenta pielikumā infrastruktūras prasības, komunikāciju un uzturēšanas nosacījumu aprakstus. Nepieciešams veikt analīzi par šīs sistēmas nepieciešamību vai daļēji integrētu MRCC funkciju veikšanai, tai skaitā sagatavot normatīvo aktu izmaiņas priekšlikumus. Aprakstā iekļaut MRS izveide un ieviešanas scenāriju Latvijas piekrastes problemātiskā rajonā. Pasūtītājs precizē MRS rajonu pēc Izpildītāja iesniegta Statistikas ziņojuma. MRS apraksts jāsagatavo atbilstoši SOLAS 74 konvencijas prasībām un IMO Asamblejas rezolūcijas A.858(20) prasībām, kā arī iekļaujot prasības infrastruktūras, komunikāciju un uzturēšanas nosacījumu apraksts. Tai skaitā sagatavot normatīvo aktu izmaiņas priekšlikumus MRS ieviešanai;

      • Problēma situāciju apraksts. ES un nacionālā līmeņa līdzšinējo aktivitāšu, par centieniem skenēt un korelēt datus, kas iegūti no datu sistēmām, apraksts. Apsekojumos un statistikas analīzē konstatētās problēmas un kritiskie faktori attiecībā uz datu iesniegšanu ar unificēta rīka palīdzību. Potenciālo Prototipa darbības traucējumu apzināšana un to ietekmes samazinājumu scenārijs;

      • Testēšanas metodoloģijas apraksts. Testēšanas metodoloģijas apraksts satur prasības akcepttestēšanai iesaistot prototipa darbības testēšanā vismaz šādas grupas: vismaz 100 (simts) kuģus, SSN sistēmu, vismaz 1 (vienu) Ostas termināļa sistēmu un vismaz 6 (sešas) neatkarīgas sistēmas (SSN, LRIT DC, VMS, Costal VTS (MRS), SAT-AIS, EU SSN). Testēšanas metodoloģijas dokumentācija ietver: testēšanas plānu, testēšanas procedūras specifikāciju, testēšanas žurnālu, akcepttesta problēmu protokolu formātu un testēšanas kopsavilkuma ziņojumu.

      • Pieredzes pārneses (demonstrāciju) aktivitāšu saraksts. I-DatQ prototipa pieredzes pārneses iespēju novērtējums un demonstrācijas aktivitāšu saraksts pēc vismaz šādas izstrādāta risinājuma ietekmes: kuģošanas informācijas un ostu formalitāšu iesniegšanas atvieglošana, integrēšana ES dalībvalstu vienota loga sistēmās, ekonomiskais izdevīgums, efektivitāte salīdzinājumā ar esošiem risinājumiem, trūkumi.

      • Efektivitātes novērtēšanas metodika. Metodika nosaka paņēmienu, izstrādātā Prototipa būtisko kritēriju efektivitātes novērtēšanai (mēra pakāpi) attiecībā pret sasniedzamo I-DatQ rezultātu vismaz pēc šādiem kritērijiem: kuģošanas informācijas un ostu formalitāšu iesniegšanas atvieglošana, integrēšana ES dalībvalstu vienota loga sistēmās, ekonomiskais izdevīgums, efektivitāte salīdzinājumā ar esošiem risinājumiem, trūkumi.



      1. Konceptuālais projektējums

Konceptuālajā projektējuma jāiekļauj šādas sadaļas:

  • Plānotā risinājuma (vīzijas) apraksts. Tā ietvaros Piegādātājs, ņemot vērā precizētu Pasūtītāja vajadzību izpratni, kā arī iepirkuma prasības un savu piedāvājumu, sagatavo Prototipa, tai skaitā algoritma aprakstu, kas paralēli datu caurlūkošanai nodrošina to pašu datu korelāciju, tai skaitā kuģošanas informācijas iesniegšanas procesā radušos kļūdu uztveršanai un tālākai vadībai, kas ietver kļūdu atpazīšanas risinājumu, tālāko apstrādi, cēloņu uzrādīšanu, kļūdainas informācijas iezīmēšanu, vadību un likvidēšanu. Funkcionalitātes, izmantojamo, tehnisko un programmatūras risinājumu aprakstu, izveides un ieviešanas grafiku, kā arī citus, ar Prototipa izveidi saistītos aspektus.

  • Pēc risinājuma vīzijas saskaņošanas ar Pasūtītāju, kā starpposmu izstrādē Piegādātājs sagatavo konceptuālu projektēšanas vai projekta aprakstu, kurā ir izklāstīti konceptuālie tehniskie risinājumi (precizējot savu piedāvājumu atbilstoši analīzes rezultātiem) un kurā tiek aprakstītas risinājuma komponentes, to savstarpējā saistība, sistēmas funkcionalitāte un dalījums funkcionālajos moduļos, datu atpazīšanas loģiskā shēma, iekšējās un ārējās saskarnes, sistēmas ieviešanas pieeja u.c. risinājuma elementi. Konceptuālais projekta apraksts jāprezentē un jāsaskaņo ar Pasūtītāju. Pamatojoties uz saskaņoto konceptuālo projektu, Piegādātājam jāsagatavo pārējās prasības. Konceptuālais projekts ir iekļaujams kā atsevišķa sadaļa.





Tehniskā prototipa izstrādes (2.posma) nodevumu apraksts

Izstrādātājam jāveic pilnvērtīga Prototipa funkcionalitātes izstrāde saskaņā ar Pasūtītāja iepirkumā noteiktajām prasībām un Analīzes posma rezultātiem, un jāveic Prototipa savietojamības saskarņu izstrāde informācijas apmaiņai ar SKLOIS/SSN sistēmām saskaņā ar specifikācijā noteiktajām prasībām (vai tieša integrācija SKLOIS/SSN).

Datu kopas, transformācijas un kartēšana

Apstrādājamās datu kopas tiks precizētas 1.posmā. Par katru datu elementu tiks noteikts, kādās informācijas vienības (piemēram, FAL veidlapa) elements izgūstams, kā tas transformējams uz unificēto datu meta-modeli (kartēšana starp avotiem), un kā veicama tā korelēšana katrā no datu kvalitātes pārbaudes līmeņiem. Prototipā jāimplementē atbilstošais unificētais meta-modelis un transformācijas (pie datu skenēšanas / filtrēšanas).

Datu apmaiņas standarti

Tiek pieņemts, ka datu apmaiņa tiks veikta ar XML struktūrām. Konkrētas saskarnes, pieejas mehānismi un darbības ierobežojumi tiks identificēti un aprakstīti 1.posmā, bet tehniskajā prototipā ir jāimplementē atbilstošie datu izgūšanas servisi (tikai no prototipa puses), kā arī datu izsniegšanas servisi SKLOIS/SSN sistēmai.

Izstrādājot datu izsniegšanas servisus, tehnoloģiski tiek jāveido analoģiski kā uz 2.posma uzsākšanas brīdi būs definēts SKLOIS/SSN dokumentācijā (arhitektūrā) priekš iekšējiem SKLOIS/SSN servisiem, tai skaitā, ja tas būs definēts, gadījumā jāizmanto SKLOIS/SSN integrācijas platforma, kurā šie servisi jāpublicē. Līdzīgi, pieeja pie ārējām sistēmām arī veicama caur integrācijas platformā publicētiem servisiem (vismaz tajos gadījumos, ja informācijas plūsma ir virzienā uz prototipu).

Drošība un veiktspēja

Prototipa tehniskais izpildījums un paredzētie darbības mehānismi nedrīkst radīt jaunus riskus ārējo sistēmu, kā arī SKLOIS/SSN, drošībai un veiktspējai.

Izstrādājot prototipu, jāvadās pēc OWASP rekomendācijām drošības jomā, jāņem vērā KAD iekšējās vadlīnijas un standarti drošības jomā. Attiecībā uz veiktspēju jāparedz, ka prototipam jāspēj apstrādāt vismaz 5000 (pieci tūkstoši) transakcijas dienā (ar transakciju tiek saprasts pieprasījums ārējais sistēmai, ārējās sistēmas vai SKLOIS/SSN pieprasījuma apstrāde, iekšējā datu kvalitātes algoritma izpilde un tml. jēgpilnas, autonomas sistēmas darbības).

Savietojamība ar pasūtītāja infrastruktūru

Izstrādātājam Prototipa un tā saskarņu ar citām sistēmām izstrāde jāveic, izmantojot Izstrādātāja un kuģu reģistrācijas procedūru tehnisko infrastruktūru un izstrādei nepieciešamās programmatūras nodrošinājumu. Izstrādes ietvaros izmantotās Izpildītāja tehniskās infrastruktūras un izstrādei nepieciešamās programmatūras nodrošinājuma izmantošanas maksai jābūt iekļautai Pretendenta finanšu piedāvājumā norādītajās izmaksās. Prototipa testēšanas posmā Izpildītājam ir jāintegrē izstrādātais prototips esošajā SSN sistēmā. Pretendents var iepazīties ar pasūtītāja SSN sistēmas infrastruktūru Krasta apsardzes dienesta telpās, kur tiks nodrošināta informācija par tehnisko nodrošinājumu un tās izmantotām licenzēm.

Grafiskais dizains

Izstrādājot notifikācijas, tai skaitā – 1.posmā sagatavojamos precizējumos paredzētās grafiskās indikācijas SKLOIS/SSN, jāņem vērā grafiskā dizaina vadlīnijas un standarti, kas tiks iesniegti no pasūtītāja puses projekta laikā (šādi standarti tiek izstrādāti paralēlā projektā un būs pieejami 1.posma laikā).

Integrācija ar SKLOIS/SSN

Veiksmīgi notestēts prototips ir integrējams ar SKLOIS/SSN sistēmu. Integrācijas mehānismam jāparedz iespēja atslēgt šo moduli kā kopumā, tā arī daļēji – izslēdzot integrāciju ar konkrētām ārējām sistēmām un/vai izslēdzot noteiktu datu kopu kvalitātes analīzes darbības (meta-modeļa datu klašu līmenī).

Pavadošā dokumentācija

Pavadošajā dokumentācijā jāietver:

  • sistēmas konceptuālais projektējums (loģiskās komponentes, galvenās klases un interakcijas, izvēršanas skats;

  • datu servisu apraksti (WSDL vai līdzvērtīga tipa apraksts) un datu struktūru XML failu paraugi (vai XSD shēmas, ja tādas tiks izmantotas);

  • uzstādīšanas un administrēšanas rokasgrāmata, kas satur instrukcijas instalēšanai, prototipa pieslēgumu un parametru konfigurēšanai;

  • izpildītāja veiktās testēšanas protokoli.




Projekta īstenošanas metodiskās un organizatoriskās prasības

Darba valoda

Izpildot darba uzdevumā minētos darbus, visa komunikācija ar Pasūtītāju jānodrošina latviešu valodā (nepieciešamības gadījumā Pretendentam par saviem līdzekļiem ir jānodrošina tulkošana).

Prasību kontrole un atskaitīšanās

Izstrādātājam ir jāveic prototipa specifikācijā un ieviešanas plānā iekļauto prasību kontrole savlaicīgi identificējot atkāpes no tām un brīdinot par to Pasūtītāju. Ne retāk kā reizi mēnesī jāsniedz Pasūtītājam progresa ziņojums. Formātu saskaņo ar Pasūtītāju.

Izmantojamie standarti un vadlīnijas

Izstrādātājam jāņem vērā šādi standarti un vadlīnijas: LVS 72:1996 un LVS 68:1996.

Piegāžu noformēšana

Piegādātājam ir jāveic darbi un jāpiegādā šajā specifikācijā nosauktie nodevumi, saskaņā ar šīs specifikācijas prasībām, iepirkuma līguma nosacījumiem, Latvijas Republikas normatīvo aktu un Eiropas Komisijas direktīvu prasībām, Latvijas Republikas un starptautiskajiem programmatūras izstrādes standartiem. Dokumentācijas nodevumi, plāni, protokoli, pārvaldības, sistēmas izejas kodi. Projekta dokumentācija un tehniskie pielikumi ir jāiesniedz Pasūtītājam latviešu un angļu valodā elektroniski rediģējamā (MS Office atpazīstamā vai līdzvērtīga) formātā un jāiesniedz 3 (trīs) kopijas uz CD diskiem un 2 (divos) drukātos eksemplāros parakstīšanai – katrai pusei vienu eksemplāru. Piegādātājam jāpiegādā dokumentācijā ietverto shēmu un attēlu izejas materiāli (elektroniski rediģējamā formātā).



Apmācība

Piegādātājs nodrošina apmācību vismaz 4 (četri) cilvēkiem – informēšanai par būtiskiem aspektiem prototipa lietošanā, to administrēšana un par pasākumiem, kas nepieciešami prototipa pilnvērtīgai funkcionēšanai.

Akcepttestēšana

Piegādātājam jānodrošina atbalsts Pasūtītājam akcepttestēšanas laikā:

      • Akcepttestēšana. Piegādātājs sagatavo un saskaņo ar Pasūtītāju akcepttestēšanas procedūru un plānu, kurā tiek aprakstīta akceptēšanas kārtība un kritēriji, kā arī akcepttestēšanas testi (identifikācija). Akcepttestu noslēgumā Piegādātājam ir jāsagatavo akcepttestu protokoli. Protokolos ir jānorāda akcepttestu tvērums un veiktās darbības, kā arī konstatētās kļūdas vai neprecizitātes.

      • Drošības pārbaude. Piegādātājam testēšanas ietvaros jāveic Prototipa un to komponenšu drošības pārbaudes, lai pārliecinātos par Prototipa neautorizētas izmantošanas vai rediģēšanas iespējām.

      • Veiktspējas testēšana. Piegādātājam testēšanas ietvaros jāveic Prototipa un to komponenšu veiktspējas pārbaudes, lai pārliecinātos par prototipa arhitektūras realizācijas piemērotību atbilstoši specifikācijā noteiktajām veiktspējas prasībām, kā arī, lai identificētu iespējamos risinājumus prototipa darbības uzlabošanai. Testēšanas procesā jāveic funkcionālie testi atsevišķi visām Prototipa lietotāju lomām, pārbaudot, vai lietotājiem faktiski pieejamā funkcionalitāte ir atbilstoša sistēmas dokumentācijā noteiktajiem lietotāju lomu apgabaliem.



Akcepttestēšanas noslēgumā ir jāveic prototipa efektivitātes analīze, kuras ietvaros Piegādātājs sagatavo Efektivitātes ziņojumu.

      1. Efektivitātes novērtējums

Efektivitātes novērtējumam jāaptver vismaz 4 projekta sasniegumu aspekti, piemēram: kuģošanas informācijas un ostu formalitāšu iesniegšanas atvieglošana, administratīvā sloga samazinājums, efektivitāte salīdzinājumā ar esošiem risinājumiem, sistēmas funkcionalitātes tehniskie rādītāji.

Rezultātu demonstrēšana

Projekta noslēgumā veicama projekta rezultātu demonstrācija un jānodrošina šādi nodevumi:

  • Gala ziņojums. Piegādātājs sagatavo gala ziņojumu (kopsavilkumu) par projekta realizāciju un izstrādātā risinājuma efektivitāti. Kopsavilkumu sagatavo uz ne vairāk kā uz 25 lapaspusēm, latviešu un angļu valodā, un iesniedz to Pasūtītājam saskaņošanai. Pēc saskaņošanas Piegādātājs nodrošina tā pavairošanu vismaz 50 eksemplāros. Piegādātājs arī iesniedz Pasūtītājam kopsavilkumu Microsoft Office Word (vai līdzvērtīgā) formātā.

  • Atpazīstamība. Izstrādātājs izstrādā un nodrošina, ka saskaņojot ar Pasūtītāju, tā adresē Xxxxxx xxxx 0x, Rīgā, tiek izvietots informatīvs materiāls, kas informē, ka KAD tiek īstenots konkrētais projekts.

  • Uzskates materiāli. Izpildītājs sagatavo vismaz 1 (vienu) vizuālu prezentāciju, kurā ietilps secīgs projekta realizācijas apraksts, sasniegtie rezultāti, gūtās pieredzes pārneses iespējas. Prezentācija jāsagatavo latviešu un angļu valodā. Izpildītājs sagatavot 1 (vienu) informatīvu brošūru, tās nodevuma formāts ir elektroniska datne, kura izmantojama brošūru pavairošanai tipogrāfijā un vismaz 50 (piecdesmit) gab. brošūru piegāde katrai valodai – divpusēja, krāsaina, glancēta brošūra, katras brošūras apjoms 1 (viena) A4 formāta lapa.

  • Publicitāte. Demonstrācijas aktivitāšu gaitā Piegādātājs nodrošina Pasūtītāju ar vismaz 3 (trīs) sagatavotiem tekstiem latviešu un angļu valodā, kas satur vismaz 300 (trīs simti) vārdus un, kas paredzēti preses relīzē par aktuālo informācija par projekta īstenošanas gaitu ar atsauksmi uz Projekta koordinatoru mājas lapu xxx.xxxxxxx.xx.

  • Demonstrācija. Izstrādātājs nodrošina konsultatīvu atbalstu Pasūtītājam vismaz 2 (divas) publikāciju sagatavošanai un, nozīmē savu pārstāvi par Piegādātāja resursiem vismaz 1 (vienai) dalībai Eiropas līmeņa pasākumā projekta demonstrācijai.

Garantija

Piegādātājam jānodrošina prototipa kļūdu (neatbilstības detalizētai specifikācijai) novēršana vismaz 1 (viens) gadu no nodošanas – pieņemšanas akta parakstīšanas.

Ekspluatācijas atbalsts

Piegādātājam ir jānodrošina pasūtītāja pieteikumu saņemšana pa e-pastu, fiksētās līnijas telefonu un mobilo telefonu darba dienās, darba laikā, saskaņā Pasūtītāja funkcionālo izmaiņu atbalsta pieteikumus klasifikāciju pēc sekojošām prioritātēm:

            • avārijas pieteikumiem reakcijas laiks ir ne vairāk kā 8 darba stundas, ja radusies neskaidrība par SSN darbību, integrēto prototipa funkcionalitāti, vai ir radies datu bojājums, kā rezultātā SSN sistēmai vai/ un Prototipam nav iespējama darbības turpināšana;

            • konsultācija/ kļūdu labošana pieteikuma reakcijas laiks ir ne vairāk kā 5 darba dienas, radusies neskaidrība par SSN darbību, integrēto prototipa funkcionalitāti, ir radies datu bojājums, ir atklāta funkcionalitātes, savietojamības vai programmēšanas kļūda. SSN sistēmai vai/ un Prototipam ir iespējama darba turpināšana bez būtiskiem ierobežojumiem vai ir pieejams problēmas apiešanas risinājums.

Reakcijas laiks ir laiks no pieteikuma saņemšanas brīža līdz brīdim, kad izpildītājs paziņo, ka pieteikums ir saņemts un ir uzsākta pieteikuma apstrāde.





Pielikums Nr. 3.4.

Konkursa, identifikācijas

Nr. VAMOIC 2014/171, nolikumam


Tehniskā specifikācija

Kuģošanas informācijas un ostu formalitāšu datu konvertēšanas un apmaiņas moduļa izstrāde

  1. Saturs:










  1. Vispārīga informācija par iepirkuma priekšmetu


Mērķis: nacionālo vienoto logu sistēmu savstarpējās datu apmaiņas iespēju izpēte un tehniskā risinājuma prototipa izstrāde, integrējot to ar Latvijas nacionālajām sistēmām SKLOIS (tiek izstrādāta) un tās bāzes sistēmu SSN.

Rezultāts: ar SKLOIS/SSN integrēts tehniskais prototips un saistītā dokumentācija.

Izmantotie termini:


KAD

Jūras spēku flotile Krasta apsardzes dienests

AnNa

Attīstīti valstu pārvaldes iestāžu tīkli

MSW

Jūrniecības vienotais logs

VILDA

Vienots informācijas logs jūrniecības un loģistikas datu administrēšanai

ATV

Attālinātas Vides modulis

EMSA

Eiropas Jūras drošības aģentūra

ES

Eiropas Savienība

FAL

Konvenciju par starptautiskās jūras satiksmes atvieglošanu

SSN

Kuģu satiksmes uzraudzības un informācijas datu apmaiņas sistēma

ES SSN

Eiropas Jūras drošības aģentūras uzturētā SafeSeaNet sistēma

MIG

Ziņojuma ieviešanas vadlīnijas

Dokumenta lietotāji

Tehniskā specifikācija ir paredzēta šādām lietotāju grupām:

  1. Pasūtītājam Jūras spēku flotiles Krasta apsardzes dienests (turpmāk – KAD) – iepirkuma procedūras organizēšanai, pretendentu piedāvājumu novērtēšanai, līguma izpildes kontrolei;

  2. Pretendentiem (izpildītājam) - piedāvājuma sagatavošanai, kā sākotnējais materiāls Projekta plānošanai, analīzes veikšanai un detalizētās programmatūras prasību specifikācijas sagatavošanai.


    1. Esošās situācijas raksturojums

Latvijai, pildot Eiropas Parlamenta un Padomes Direktīva 2010/65/ES (2010. gada 20. oktobris) par ziņošanas formalitātēm kuģiem, kuri ienāk dalībvalstu ostās un/vai iziet no tām, un ar ko atceļ Direktīvu 2002/6/EK (1) (turpmāk – direktīvas 2010/65/ES) prasības, līdz 2015.gada 1.jūnijam ir jārealizē vienas pieturas aģentūras princips. Nacionālo Bruņoto spēku (turpmāk - NBS) Jūras spēku flotiles Krasta apsardzes dienesta uzturētā Kuģu satiksmes uzraudzības un informācijas datu apmaiņas sistēma (nacionālā SSN sistēma, turpmāk – SSN) kopā ar jaunveidojamo Starptautisko kravu loģistikas un ostu informācijas sistēmu (SKLOIS) ir Latvijas vienas pieturas aģentūras risinājuma pamats. SSN attīstību nosaka Ministru kabineta (turpmāk – MK) 2009.gada 4.augusta noteikumi Nr.857 „Kārtība, kādā nodrošināma sakaru tīklu darbība Kuģu satiksmes uzraudzības un informācijas datu apmaiņas sistēmas ietvaros” un MK 2012.gada 15.maija noteikumi Nr.339 „Noteikumi par ostu formalitātēm”. Abi minētie MK noteikumi nacionālā līmenī ir pārņēmuši minētās Direktīvas 2010/65/ES prasības.

Latvijas dalības XXXX MSW projektā virs mērķis ir veicināt aktīvu sadarbību starp ES dalībvalstīm un izstrādāt atbilstošus mehānismus, lai atvieglotu un harmonizētu ziņošanas formalitātes nacionālā un ES dalībvalstu līmenī.

XXXX projekta mērķi ir:

- Sekmēt Direktīvas 2010/65/ES ieviešanu, stiprināt Eiropas ostu un jūras transporta konkurētspēju pasaules mērogā;

- Sekmēt visu iesaistīto pušu dalību vienotā elektroniskā informācijas telpā;

- Izveidot saskaņotu pieeju un efektīvu sadarbību starp privāto un publisko sektoru;

- Dalībvalstīs sekmēt bottom-up pieeju, lai realizētu vienas pieturas aģentūras projektu;

- Izveidot sistēmu, kas sekmētu savietojamību starp datu sniedzējiem, publisko sektoru un loģistikas ķēžu operatoriem.

Aizsardzības Ministrija ir sagatavojusi nacionālās SSN sistēmas izpētes un attīstības projektu „Vienots informācijas logs jūrniecības un loģistikas datu administrēšanai (turpmāk - VILDA)”. VILDA paredz pētīt un izveidot vienotu telpu datu apmaiņai jūrniecības un loģistikas informācijai gan nacionālā, gan ES līmenī, saskaņā ar ES Direktīvas 2010/65/ES prasībām.

VILDA apakšprojekta Kuģošanas datu  apstrādes un apmaiņas moduļa izstrāde (turpmāk - InDTra) mērķis ir izstrādāt un praksē pierādīt vienas pieturas aģentūras inteliģentā moduļa darbību (prototipu), kas nodrošinās datu apstrādi: tulkošana, sinhronizācija un maršrutēšana vienotā informācijas loga lietotājiem, nodrošinot tiešsaisti ar informācijas sniedzējiem, kas izmanto atšķirīgus datu iesniegšanas standartus (piemēram, kuģi, kas nepakļaujas ES normatīvo aktu prasībām par datu aprites standartiem). Apakšprojektā paredzētās aktivitātes ir datu apstrādes moduļa izstrāde, testēšana un saslēgšana ar SSN sistēmu, pilnveidojot vienota informācijas loga darbību un samazinot administratīvo slogu gan valsts iestādēm, gan uzņēmējiem.

Apakšprojekta InDTra īstenošana paredzēta līdz 2015.gada 1.jūnijam.

    1. VILDA apakšprojekta InDTra darba uzdevuma apraksts

      1. Īss esošās situācijas raksturojums un apraksts par plānoto informācijas sistēmu

InDTra realizācijas ietvaros paredzēts izveidot datu apstrādes (konvertēšanas) moduļa prototipu (turpmāk tekstā - prototips). Prototips paredzēts, lai atvieglotu un uzlabotu kuģošanas nozares (specifiski - starptautiskajā jūras satiksmē iesaistītajiem kuģiem) informācijas sistēmu savstarpējo datu apmaiņu kuģis – krasts – kuģis, un nodrošina, ka netiek radīta administratīvā barjera dokumentu apstrādei. Datu apmaiņai kuģis – krasts – kuģis izmanto vienotu strukturētu datni. Datnē ievadāmais datu apjoms nodrošinās vienreizēju datu iesniegšanu, kas nepieciešama noteikto ostas formalitāšu ziņošanai, saskaņā ar Konvenciju par starptautiskās jūras satiksmes atvieglošanu (FAL konvencijā), ES un nacionālajiem normatīvajiem aktiem. Tiks nodrošinātas funkcijas, kas saistās ar elektroniska formāta atvieglotu datu nosūtīšanu, saņemšanu un apmaiņu nacionālā un Eiropas centrālajā SSN sistēmā.

Prototips aptvers 5 (piecus) biznesa procesus:

1. process: Kuģu vizītes pieteikšana un kuģu ienākšana Latvijas ostās, ostas formalitāšu kārtošana, kontrole. 1.process ietver četrus apakš procesus, kas sadalīti atbilstoši veicamu darbību prasībām:

- kuģu vizītes plānošana un darbības 72 stundas pirms ienākšanas ostā;

- kuģu vizītes plānošana un darbības 24 stundas pirms ienākšanas ostā;

- kuģu vizītes plānošana un darbības 2 stundas pirms ienākšanas ostā;

- kuģu ienākšana ostā.

2. process: Kuģu pārtauvošanas (ostā un ostas akvatorijas ietvaros) saskaņošana, ostas formalitāšu kārtošana, kontrole.

3. process: Kuģu iziešanas saskaņošana, ostas formalitāšu kārtošana, kontrole (1.procesam pretējs process).

4. process: Lietotāja iesniegto dokumentu papildināšana, atjaunošana vai atcelšana

Prototipa testēšanas fāzē tiek pārbaudīta datu apmaiņa kuģis – krasts – kuģis, tā, lai SSN sistēma tiek ģenerēti noteikti ostu formalitāšu dokumenti, saskaņā ar tabulām Tab.1 un Tab.2:

Dokuments

Atšifrējums

FAL 1. veidlapa

Vispārīgā deklarācija

FAL 2.veidlapa

Kuģa manifests

FAL 3.veidlapa

Kuģa krājumu deklarācija

FAL 4. veidlapa

Apkalpes mantu deklarācija

FAL 5. veidlapa

Apkalpes saraksts

FAL 6. veidlapa

Pasažieru saraksts

Tab. 1: FAL veidlapas, kas obligāts saskaņā ar FAL Konvenciju par starptautiskās jūras satiksmes atvieglošanu (turpmāk - FAL konvencija), starptautiskajā jūras satiksmē iesaistītajiem kuģiem

HAZMAT

Paziņošana par bīstamu un piesārņojošu kuģa kravu

Paziņošana par kuģa atkritumiem

Paziņojumu par atkritumu nodošanu

Aizsardzības informācijas deklarācija

Aizsardzības informācijas deklarācijas iesniegšana

Veselības deklarācija

Paziņojums par kuģa sanitārās un apkalpes veselību

Paziņošana par personu, kas nokļuvusi un uzturas uz tā nelegāli

Paziņošana par personām, kas nokļuvušas un uzturas uz kuģa nelegāli

Tab. 2: Ostu formalitātes, kas noteiktas citos normatīvos aktos


Izstrādātajam risinājumam ir savietojams ar SSN sistēmu, tādā mērā, lai kuģa iesniegtie dati tiktu uzskatīti par līdzvērtīgiem tādiem datiem, ko iesniedz kuģa aģents. Informācijas nosūtīšana tiek nodrošināta divos virzienos: no prototipa uz SSN tiek nosūtīts datu kopums ar ostu formalitātēm, savukārt SSN sniedz atbildi prototipam par ostas formalitāšu pieņemšanu, ka arī informāciju par datu noraidīšanu/apstiprināšanu/komentēšanu.

Prototipa funkcionalitāte un integrēšana SSN un lietotāja (kuģa) sistēmās, tiek veidota 2 (divos) veidos, kā Attālinātas Vides modulis (turpmāk tekstā - ATV) un, kā strukturētu datu iesniegšana ar e-pasta palīdzību. Šie risinājumi nodrošinās attālinātu datu iesniegšanas iespēju SSN sistēmā.

ATV modulis datus SSN nodos, izmantojot tīmekļa servisu (web service), kā arī nodrošinās iespēju sagatavotos datus saglabāt un nosūtīt vēlāk, kad ir pieejams savienojums ar SSN.


      1. Piedāvājuma iesniegšana

Pretendentam piedāvājumā jāiesniedz detalizēts aprakstu par iespējamo prototipa izveides scenāriju, atbilstoši Pasūtītāja Tehniskās specifikācijas punktā 1.2.3. un sadaļās 2., 3., 4. un 5., noteiktajām prasībām un kārtībai, ar kuru iespējams nodrošināt šajā specifikācijā iekļautās prasības.

      1. Prototipa komponentes un darbības apraksts.

        1. Ostas formalitāšu iesniegšana darbības shēma izmantojot prototipu.

Prototipa biznesa procesus veic šāda kārtība:

  • Pielietojot ATV risinājumu, ATV tiek piešķirts kuģim (turpmāk - lietotājam) pēc līguma noslēgšanu starp KAD un lietotāju par autorizētu SSN sistēmas lietošanu. Plānojot kuģa vizīti ostā, biznesa procesa noteiktā kartībā, kuģa kapteinis uzsāk izmantot ATV. Tiek aizpildīta strukturēta forma, kurā iegūtie dati tiek apkopoti strukturētā datnē, kas tiek iesūtīta SSN sistēmā, izmantojot tīmekļa servisu (web service), kā arī nodrošinās iespēju sagatavotos datus saglabāt un nosūtīt vēlāk, kad ir pieejams savienojums ar SSN. Kontrolējošo dienestu apstiprinājumi no SSN sistēmas automātiski sinhronizējas ar ATV un informē lietotāju par ziņojuma pieņemšanu vai nepieciešamajām izmaiņām.

  • Strukturētu datu iesniegšana/labošana/atcelšana ar e-pasta palīdzību tiek nodrošināta jebkuram lietotājam. SSN sistēmas mājas lapā, publiskajā daļā tiek izvietota strukturēta datne - lietotājiem lejupielādei. Strukturētas datnes aizpildīšanas notiek lietotāja vidē (uz lietotāja datora) un, pēc aizpildīšanas, ar e-pasta pielikuma palīdzību tiek nosūtīts uz SSN sistēmas konfigurēto e-pastu. SSN sistēma spēj automātiski saņemt/atpazīt un ielādēt SSN sistēmā lietotāju iesūtītos datus, sadalot atbilstoši noteiktiem dokumentiem (tab.1 un tab.2). SSN sistēma par datu pieņemšanu un pēc kontrolējošo dienestu datu kopuma validācijas (Muita, Krasta apsardzes dienests, Valsts robežsardzi, Osta un Pārtikas veterināra dienesta) sniedz lietotājam atbildi par apstiprināšanu/noraidīšanu/komentēšanu. Atbildes e-pasti lietotajam no kontrolējošām dienestiem par pārbaudes rezultātiem tiek izsūtītas no SSN sistēmas definēta e-pasta, atbilstoši kontrolējošo dienestu kompetencēm.

        1. Attālinātas Vides (ATV) modulis.

Darbība tiek nodrošināta ar programmatūru, kas spēj darboties bez atsevišķas instalēšanas nepieciešamības un ir neatkarīga no lietotāja darba stacijas operētājsistēmas (spēj darboties uz Microsoft un OS X operētājsistēmām). Modulim ir sava, iekšējā datu glabātuve, datu lokālai uzglabāšanai, un tālākai izmantošanai, x.xx. automātiski piedāvā, izveidot rezerves kopiju uz lietotāja darba stacijas. Programma spēj sazināties ar nacionālo SSN sistēmu datu iesūtīšanai, ziņojuma statusa saņemšanai un attēlošanai, izmantojot lietotāja darba stacijas interneta pieslēgumu. Gadījumā, ja uz lietotāja darba stacijas nav pieejams interneta savienojums un programma nespēj sazināties ar nacionālo SSN sistēmu, tad tiek nodrošināta tās darbība bezsaistes režīmā ar iespēju ievadīt, saglabāt un iesūtīt datus SSN sistēmai vēlāk, kad ir pieejams interneta savienojums. ATV programmatūra ir uzstādīta uz datu nesēja (piemēram, USB zibatmiņa), un nav paredzēta rediģēšanai un pavairošanai. Tā ir aizsargāta pret bojājumiem, vai citas koriģēšanas no lietotāja puses.

Lietotājam, uzsākot darbu ar moduli un aktivizējot programmu, parādās informatīvs paziņojums par datu nesēju un to izmantošanas nosacījumiem (informatīva paziņojuma teksts tiks definēts no izpildītāja puses izstrādes brīdī, saskaņojot ar pasūtītāju).

ATV modulis satur arī aktuālo informācijai par Latvijas normatīvajos aktos noteiktām prasībām ostas formalitāšu kārtošanai.

          1. ATV moduļa atjaunošanās. ATV platformās modulis automātiski veic moduļa atjaunināšanu, izmantojot internetu, ka arī paredz iespēju atjaunināt manuāli vai, modulis atjaunojas, nepieprasot datorsistēmas lokālā administratora atļauju (tiesības). Modulis veic moduļa versijas pārbaudi pie pirmās tiešsaistes ar internetu un ja ir pieejams atjauninājums, piedāvā to lietotājam lejupielādēt. Pēc lejupielādes modulis atjauninās automātiski, informējot par to lietotāju ar lūgumu neizmantot moduli, līdz atjauninājums ir pabeigts. Atjaunošana ir paredzēta gan funkcionālas, gan informatīvas sadaļas atjaunināšanai atbilstoši SSN sistēma izveidotajiem atjauninājumiem ATV modulim.

          2. ATV darbības saglabāšana, nosūtīšana, papildināšana un atcelšana. Moduļa datnes formāts ir ar iespēju ievadīt, mainīt un dzēst informāciju dažādiem apgabaliem, kas iesniedzama (aktualizējama) SSN sistēma. Modulis satur funkciju ar iespēju veikt ziņojumu kopēšanu no vēsturiskiem datiem uz aktuālo ziņojumu. Pārtraucot iecerēto darbību, modulis neveic izmaiņas datubāzē, piemēram, visās reģistrēšanas, rediģēšanas un dzēšanas ekrānformās spiedpogas „Atcelt” pieejamība. Prasība nav attiecināma uz situāciju, kad transakcijas izpilde ir uzsākta, piemēram, aktivizējot spiedpogu „Saglabāt” vai „Nosūtīt”. Darbības saglabāšana, nosūtīšana un atcelšanas iespējai ir skaidri redzamas un viegli pieejamas. SSN sistēmai paziņojamo datu periodiska atjaunošana ar SSN sistēmu notiek pamatojoties pēc 1.2.1. punktā noteiktiem biznesa procesa intervāliem;

          3. ATV moduļa lietotāja datu monitoringa funkcija. Modulis nodrošina vismaz šādas monitoringa funkciju: vēsturisku datu attēlošana ar filtrēšanas iespēju vismaz pēc četrām kritērijiem - datums, osta, valsts, kravas veids, iesniedzējs.

          4. ATV moduļa un tās lietotāja saskarnes dizains. Moduļa dizains un lietotāja saskarne atbilst šādām prasībām:

- lietotāja saskarne darbojas Microsoft un OS X operētājsistēmu vidēs.

- lietotāju saskarnei dizains jāsaskaņo ar pasūtītāju;

- saskarnē ir izmantojamas divās valodās – latviešu un angļu ar iespēju pievienot citu dalībvalstu valodas;

- ievadlauku izmēri atbilst ievadāmo datu apjomam (garumam), t.i., ievadlauks nav pārāk liels vai mazs;

- moduļa standarta ziņojumi ir lietotājiem viegli saprotamā tekstā, precīzi jāskaidro radušās problēmas būtība un piedāvājot tālākās rīcības variantus;

- moduļa dialogi satur tādu informācijas apjomu, kas ir būtisks moduļa darbināšanai un lietotāja funkciju veikšanai;

- navigācija starp ekrānformām – moduli ir izveidota tā, lai lietotājam nevajadzētu atcerēties informāciju, pārejot no viena ekrāna uz citu;

- modulis nodrošina atgriezenisko saiti ar lietotāju, pēc iespējas informējot viņu par ziņojuma statusu;

- nodrošināt moduļa paziņojumu, kas saistīts ar programmas operāciju funkciju izpildi, kas aiztur lietotāja darbu ilgāks laiks par 3 (trīs) sekundēm, t.i., ATV uz ekrāna parāda atbilstošu paziņojumu vai citu vizuālu notifikāciju (piemēram, smilšu pulkstenis), x.xx., meklēšanas funkcionalitātei;

- moduļa lietotāji ir ar iespēju izmantot standarta Windows un pārlūkprogrammu karstos taustiņus („hot keys” atbalsts), piemēram, Ctrl+C, Ctrl+V;

- moduļa ekrāna izšķirtspēja automātiski pielāgojas datorā uzstādītajai izšķirtspējai.

        1. Strukturētu datu iesūtīšana ar e-pasta palīdzību.

Uz lietotāja darba stacijas aizpildīta, SSN sistēmā publicētā elektroniskā formāta datne (piemēram, Excel vai PDF formātā) un pielikuma veidā, elektroniskā formātā tiek pārsūtīta uz SSN noklusēto e-pastu. Ja aizpildīto dokumentu neizdodas atpazīt, sistēma informē sūtītāju par nepareizi sagatavotu dokumentu un automātisku ģenerētu pamatojumu, par kļūdas esamību un pamatojumu.

Lai mazinātu iespēju SSN noklusētu e-pasta vidi piesārņot ar mēstulēm (spamošanu), gadījumos, kad dokuments nav pareizi noformēts, vai neatbilst kritēriju prasībām, sistēma informē attiecīgo operatoru par kļūdu lietotāju darbībā. SSN sistēmā paziņojamo datu atjaunošana vai papildināšana, notiek pamatojoties uz 1.2.1. punktā noteiktiem biznesa procesiem. E-pasta pielikumā nosūtāmai unificētā formāta struktūra ir izveidot tā, lai lietotājam nebūtu iespēja mainīt un rediģēt struktūru, izņemot tikai tos laukus, kur nepieciešams ievadīt pieprasītos datus. Definētie lauku tiek pakļauti validācijai, lai izslēgtu neatbilstošu lauku aizpildīšanu. Tiesības veikt labojumus e-pasta unificētajā struktūrā ir SSN sistēmas administratoram.

        1. Datu kopuma formāts.

Strukturētais datu kopums ATV modulim un e –pasta elektroniskajai datnei, atbilsts MIG prasībām un tās saturs lietotājam pieprasa tab.1 un tab.2 uzskaitīto dokumentu aizpildīšanai nepieciešamo datu kopumu, katru no datu vienībām, kas šajos dokumentos atkārtojas, pieprasot vienu reizi.

        1. Datu apmaiņa.

Datu apmaiņa notiek divos virzienos, no SSN uz/no InDTra prototipa lietotāju moduļiem.

Izsūtāmās paketes tiek sagatavotas sekojoši: tiek saņemti lietotāja iesūtīti dati, ko sistēma atpazīst, un automātiski uzsāk datu augšupielādi sistēmā tālākai apstrādei; SSN sistēma automātiski atpazīst, vai dati ir iesniegti pirmoreiz vai, satur datus, kas jāiesniedz atkārtoti atbilstoši 1.2.1. biznesa procesam, un tad piešķir izstrādes laika atslēgu (jaunie dati “N” vai papildināti dati “U”).

        1. Prototipa integrācija SSN.

Datu saņemšana un nosūtīšana ir pilnībā savietojama ar SSN sistēmu. Prototipa instalācija neietekmē esošās nacionālās SSN sistēmas kapacitāti un nemazina tās darbības kvalitāti. Prototipa funkcijas nerada ietekmi vai konfliktus ar esošās nacionālās SSN sistēmas programmatūru vai kādā citā veidā neietekmēt sistēmas darbību vai tās saistības.

Atskaites auditu žurnālā (log failā) saglabājas ziņas par veiktajām darbībām starp SSN un prototipu. Papildināto, iesūtīto datu apstrādes procesā SSN sistēma veic automātisku validāciju un atpazīst papildinātos datus. Papildinātie dati ir īpaši apzīmēti vai izcelti, tā, lai SSN kompetentajām institūcijām tie būtu vienkāršoti uztverami.

        1. Lietotāja atbalsts.

Prototipa lietošanas uzsākšanas un izmantošanas apraksts ir sniegts Lietotāja palīgā, kas ir sagatavots latviešu un angļu valodā. ATV lietotājam tas pieejams, kā papildinājums programmatūrai. Ar e-pastu nosūtāmās elektroniskās datnes lietotājiem Lietotāja palīgs pieejams SSN mājas lapas publiskajā daļā.

Lietotāja palīgam ATV daļā ir jābūt kontekstjutīgam, lai no katras ekrāna formas Lietotājs varētu iegūt atbilstošo palīga lappusi (atbilstošo tēmu).

Lietotāja palīgam jāsatur apraksts par:

  • katru ekrāna ievada un izvada formu (ATV gadījumā) vai katru elektroniskās datnes lapu (e-pastu nosūtāmās elektroniskās datnes gadījumā) un atsevišķu lauku nozīmi tajās (iekļaujot lauka paplašinātu aprakstu, skaidrojumu, kas lietotājam sniedz papildus nepieciešamo informāciju, lai saprastu laukā ievadāmo informāciju), x.xx. katram laukam ir jābūt aizpildītam ar reāliem datiem pielīdzinātiem datiem, ievērojot kā lauka saturisko nozīmi, tā tipiskā aizpildījuma formātu un aizpildījuma garumu. Reālie dati jānodrošina Izpildītājiem (datiem jābūt maksimāli pietuvinātiem reāliem datiem);

  • izvēļņu apraksts un funkcionālo iespēju detalizēts izklāsts;

  • pamācībām, kādā veidā veikt noteiktas darbības;

  • rīcību problēma gadījumos (troubleshooting);

  • lietotāja saskarnē un pašā lietotāja palīgā lietoto terminu skaidrojumi.

Lietotāja palīgam ir:

  • jābūt organizētām lappusēs, lai sniegtu optimālu nepieciešamo informācijas apjomu par katru aprakstāmo jautājumu;

  • lietotāja palīgā ir jāizmanto hipersaites, lai savstarpēji veidotu norādes no vienas lappuses uz citu;

  • lietotāja palīgā ir jāiekļauj ilustrācijas (attēli, tabulas, shēmas utt.), kur tas ir nepieciešams teksta labākai izskaidrošanai. Lietotāja palīgā nav jāiekļauj pilnas ekrāna formu kopijas, bet pēc vajadzības – tikai to elementu attēli, kas tiek paskaidroti īpaši.

Lietotāja palīgam jābūt ne tikai ekrānformu orientētai (t.i., apraksts par katru ekrānformas funkcionalitāti), bet arī procesu orientētai (atbilstoši kravu pārvadājumu procesā iesaistītajām lomām, biežāk uzdotie jautājumi, tipveida situācijas utt.).

        1. ATV elektroniska rokasgrāmata

ATV elektroniskā lietotājam rokasgrāmata ir pieejama, kā papildinājums programmatūrai.

Izpildītājam jāizstrādā un ar Pasūtītāju jāsaskaņo ATV elektroniska rokasgrāmata (multimediju), x.xx. tās saturs, audio un video datnes. Elektroniskā rokasgrāmata (multimediju) jāsagatavo latviešu un angļu valodā, x.xx., audio un video datnes.

Rokasgrāmata ir jāsadala pa tēmām un apakš tēmām detalizēti, skaidrojot ATV lietošanas kārtību. Darba lapās ir jāievēro vienots princips. Darba lapām ir jābūt ilustrētām un maketētām. Lai atvieglotu tēmas uztveri, rokasgrāmata ir jāpapildina ar vizuālu materiālu un klausīšanās iespēju.

Rokasgrāmatā jāiekļauj ekrāna ieraksts, animācijas un video ieraksti ar skaņas paskaidrojumiem.

Lietotājam ir jānodrošina iespēja ieslēgt/atslēgt pavadošo skaidrojošo skaņas datni. Skaņas ierakstam jābūt skaidram, literārā valodā, bez skaņu trokšņiem, dikcijai jābūt saprotamai, skaņai jāatspoguļo skaņas izpildījuma brīdī uz ekrāna redzamās darbības vai funkcionālās iespējas.

Izpildītājam ar Pasūtītāju jāsaskaņo ATV rokasgrāmatas dizains, navigācija, saturs un skaņas teksts papīra formātā.

Rokasgrāmatā pieejamie navigācijas elementi:

- Atpakaļ, lai dotos pie iepriekšējās darbības aktivitāšu ķēdē;

- Nākošais, lai dotos pie nākamās darbības aktivitāšu ķēdē;

- Izvēlne, lai atgrieztos pie izvēlnes hierarhijā;

- Iziet, lai izietu no rokasgrāmatas;

- Tēmas ietvaros brīva pārvietošanās pa lapām;

- Nokļūšana uz sākumlapu no jebkuras vietas rokasgrāmatā;

- Elektroniskās rokasgrāmatas (multimediju) nodevuma formāts.

        1. Dokumentācija.

Prototipa apraksta dokumentācija tiek sagatavota angļu un latviešu valodās un tajā tiek iekļauts iekļauj: unificēta formāta izstrāde, lietotāja profila apraksts, normatīvo aktu analīze, problēmsituāciju apraksts, ieviešanas scenāriji, pieredzes pārneses aktivitāšu saraksts, efektivitātes novērtēšanas metodika un tehniskā dokumentācija. Prototipa dokumentācijas saraksts un secība var tikt precizēts projekta gaitā, par to atsevišķi vienojoties Pasūtītājam un Izpildītājam.

    1. Atbilstība Tiesību aktiem

Prototipa izveides un piegādes ietvaros, Izpildītājam ir jāņem vērā šādi saistošie tiesību akti:

      1. FAL Konvencija par starptautiskās jūras satiksmes atvieglošanu;

      2. Jūrlietu pārvaldes un jūras drošības likums;

      3. Informācijas atklātības likums;

      4. Dokumentu juridiskā spēka likums;

      5. Elektronisko dokumentu likums;

      6. 2013. gada 17. decembra Ministru Kabineta sēdes protokols Nr.67, 86.§Informatīvais ziņojums „Par papildu valsts budžeta saistību uzņemšanos Kuģu Satiksmes uzraudzības un informācijas datu apmaiņas sistēmas pilnveidošanai un Direktīvas 2010/65/ES ieviešanai”

      7. Ministru kabineta 2010.gada 28.septembra noteikumi Nr. 916 „Dokumentu izstrādāšanas un noformēšanas kārtība”;

      8. Ministru kabineta 2005.gada 28.jūnijā noteikumi Nr. 473 „Elektronisko dokumentu izstrādāšanas, noformēšanas, glabāšanas un aprites kārtība valsts un pašvaldību iestādēs un kārtība, kādā notiek elektronisko dokumentu aprite starp valsts un pašvaldību iestādēm vai starp šīm iestādēm un fiziskajām un juridiskajām personām”;

      9. Ministru kabineta 2010. gada 13. aprīlī noteikumi Nr.357 „Kārtība, kādā iestādes sadarbojoties, sniedz informāciju elektroniskā veidā, kā arī nodrošina un apliecina šādas informācijas patiesumu”;

      10. 2009. gada 4. augusta Ministru kabineta noteikumi Nr. 857 „Kārtība, kādā nodrošināma sakaru tīklu darbība Kuģu satiksmes uzraudzības un informācijas datu apmaiņas sistēmas ietvaros”

      11. 2012. gada 15. maija Ministru kabineta noteikumi Nr.339 „Noteikumi par ostu formalitātēm”

      12. Eiropas Parlamenta un Padomes 2002.gada 27.jūnija Direktīvas 2002/59/EK, ar ko izveido Kopienas kuģu satiksmes uzraudzības un informācijas sistēmu un atceļ Padomes Direktīvu 93/75/EEK;

      13. Eiropas Parlamenta un Padomes 2009.gada 23.aprīļa Direktīvas 2009/17/EK, ar kuru groza Direktīvu 2002/59/EK, ar ko izveido Kopienas kuģu satiksmes uzraudzības un informācijas sistēmu;

      14. Eiropas Parlamenta un Padomes 2010. gada 20. oktobra Direktīvas 2010/65/ES par ziņošanas formalitātēm kuģiem, kuri ienāk dalībvalstu ostās un/vai iziet no tām, un ar ko atceļ Direktīvu 2002/6/EK.

  1. Pakalpojuma izpildes prasības

Šajā sadaļā sniegts InDTra projekta realizācijas laika posmu izklāsts.

    1. InDTra izstrādes un ieviešanas laika plāns. Saskaņā ar VILDA pieteikumu projekta realizācija jāveic līdz 2015. gada 1. jūnijam. Atbilstoši izstrādes un ieviešanas dzīves ciklam projekts plānot jāveic 4 (četros) darbu posmos.

Projekts veicams secīgos posmos (uzsākot katru pēc iepriekšējās pabeigšanas). Zemāk norādīti termiņi katras kārtas nodevumu iesniegšanai saskaņošanas uzsākšanai (skaitot no posma uzsākšanas dienas). Katra kārtas nodevumu saskaņošana tiks veikta ne ilgāk kā 10 darba dienu laikā.


Kārtas (posma) nr.

Nodevumu iesniegšanas termiņš / nodevumi

1.

Analīzes (pētījuma veikšanas) posms

Termiņš: 12 nedēļas

Nodevumi: Ziņojums (-i), Konceptuālais projektējums (x.xx. algoritmi)

2.

Tehniskā prototipa izstrāde

Termiņš: 24 nedēļas

Nodevumi: Tehniskais prototips, Pavaddokumentācija

3.

Tehniskā prototipa testēšana

Termiņš: 8 nedēļas

Nodevumi: Testēšanas ziņojums, Efektivitātes novērtējums

4.

Demonstrēšana, Pieredzes pārneses aktivitātes

Termiņš: 4 nedēļas

Nodevumi: Ziņojums (-i), Pieredzes pārneses dokumentācija


  1. Darbu veikšanas kārtība un to veikšanas īpašie nosacījumi

    1. I. posma ”Prototipa izstrāde” izstrādes process un akceptēšanas procedūra

Piegādātājam InDTra sākotnējā izstrādes kārta I. Prototipa izstrāde (turpmāk tekstā – prototips) jāveic 2 (divos) etapos, atbilstoši punktā 1.2.2. uzskaitītajām Prototipa darbības aprakstam un šajā nodaļā norādītajai metodikai:

  • sagatavojot apraksta dokumentu (1.etaps) (turpmāk tekstā - Apraksta Dokuments);

  • izstrādājot prototipu (2.etaps).

      1. 1.etaps: Apraksta Dokumenta sagatavošana. Dokumenta sagatavošana gaitā jāsagatavo šāda veida izpētes, analīzes, detalizēts apraksts vai informācijas apstrāde un dokumenta struktūrā obligāti jāietver šādas sadaļas:

        1. Ziņojums. Ziņojumā iekļautas sekojošas nodaļas:

  • Unificēta formāta izstrāde. Starptautiskos, ES un nacionālos tiesību aktos noteikto formalitāšu daudzveidība un unificēšanas iespējas. Formalitāšu iesniegšanas atšķirīgie momenti dalībvalstīs, kas tiek pieprasīti atbildīgajām pusēm kuģu vizīšu periodā. Ziņojumā sagatavošanai, jāveic vismaz 5 (piecās) Baltijas jūras valstu procedūru apkopojums. Unificēta formāta paraugs, saskaņots ar AnNA dalībvalstīm.

  • Lietotāja profila apraksts. Apraksts ietver biznesa procesos iesaistīto Lietotāju sarakstu un lomas. Dokumentā jāiekļauj interviju rezultāti kopā vismaz 20 (divdesmit) kuģošanas, stividoru, operatoru un aģentēšanas kompānijām. Tiek sagatavots detalizēts Lietotāju sistēmu apraksts, kuras tiek izmantotas Prototipa funkcionalitātes nodrošināšanai tehnoloģijas un aizsardzības nosacījumu.

  • Normatīvo aktu analīze. Starptautisko, ES un nacionālo normatīvo aktu analīze, par veicamajām izmaiņām, lai ieviestu prasības, kas nosaka, ka kuģim iespējams piešķirt tiesības iesniegt ostu formalitātes bez kuģu aģentu starpniecības.

  • Ieviešanas scenāriji. Vismaz šādu, būtiskāko aspektu ieviešanas scenāriju sagatavošana: ATV izsniegšanas kārtība, lietotāju autorizācija, saņemto ziņojumu tālāka apstrāde SSN sistēmā, rīcība neveiksmīgu formalitāšu iesniegšanas gadījumos, e –pasta paziņošanas formāta kļūdu iespējamība, to novēršana.

  • Problēmsituāciju apraksts. ES un nacionālā līmeņa līdzšinējo aktivitāšu, par centieniem unificēt datu apmaiņas formātus, apraksts. Apsekojumos un statistikas analīzē konstatētās problēmas un kritiskie faktori attiecībā uz datu iesniegšanu ar unificēta rīka palīdzību. Potenciālo Prototipa darbības traucējumu apzināšana un to ietekmes samazinājumu scenārijs;

  • Testēšanas metodoloģijas apraksts. Testēšanas metodoloģijas apraksts satur prasības akcepttestēšanai iesaistot vismaz šādas grupas: vismaz 10 (desmit) kuģus; SSN sistēma. Testēšanas metodoloģija tiek izstrādāt, tā, lai ATV un strukturizēta e-pasta paziņošanu būtu iespējams veikt tam specializētā testa vidē un kurā būti iespējams veikt SSN sistēmai autentiskas darbības. Testēšanas metodoloģijas dokumentācija ietver vismaz šādas sadaļas: testēšanas plāns, testpiemēru specifikācija, testēšanas procedūras specifikāciju, testēšanas žurnālu, akcepttesta problēmu protokolu formāts, testēšanas kopsavilkuma ziņojumus. Testēšanās rezultātā jāgūst arī apliecinājums no Eiropas Jūras Drošības aģentūras par SSN sistēmas paplašinājuma testēšanas atbilstoši EMSA testēšanas metodoloģijai.

  • Pieredzes pārneses (demonstrāciju) aktivitāšu saraksts. InDTra prototipa pieredzes pārneses iespēju novērtējums un demonstrācijas aktivitāšu saraksts pēc vismaz šādas izstrādāta risinājuma ietekmes: kuģošanas informācijas un ostu formalitāšu iesniegšanas atvieglošana, integrēšana ES dalībvalstu vienota loga sistēmās, ekonomiskais izdevīgums un administratīvā sloga samazinājums, efektivitāte salīdzinājumā ar esošiem risinājumiem, InDTra Prototipa trūkumi.

  • Efektivitātes novērtēšanas metodika. Metodika nosaka paņēmienu, izstrādātā Prototipa būtisko kritēriju efektivitātes novērtēšanu (mēra pakāpi) attiecībā pret sasniedzamo InDTra rezultātu vismaz pēc šādiem kritērijiem: kuģošanas informācijas un ostu formalitāšu iesniegšanas atvieglošana, integrēšana ES dalībvalstu vienota loga sistēmās, ekonomiskais izdevīgums un administratīvā sloga samazinājums, efektivitāte salīdzinājumā ar esošiem risinājumiem, InDTra Prototipa trūkumi.

  • Tehniskā dokumentācija. Prototipa projektējuma un uzstādīšanas detalizēts apraksts, kas ietver darbības nodrošināšanas aktivitāšu sarakstu un izveides plānu, prototipa projektējuma un uzstādīšanas detalizētu specifikāciju, nepārtrauktas darbības nodrošināšanas plānu un izveides plānu; testēšanas kopsavilkumu, gala ziņojumu, demonstrācijas aktivitātes; efektivitātes analīzi (prototipa dokumentācijas saraksts var tikt precizēts projekta gaitā).

        1. Plānotā risinājuma apraksts. Tā ietvaros Piegādātājs, ņemot vērā 1.2.2. Prototipa komponenšu un darbības aprakstu un precizētu Pasūtītāja vajadzību izpratni, kā arī iepirkuma prasības un savu piedāvājumu, sagatavo Prototipa risinājumu aprakstu, kurā iekļauj funkcionalitātes, izmantojamo, tehnisko un programmatūras risinājumu aprakstu, izveides un ieviešanas grafiku, kā arī citus, ar Prototipa izveidi saistītos aspektus.

        2. Konceptuāla projektējuma izstrāde. Pēc 3.1.1.2. apakšpunktā norādītās apraksta saskaņošanas ar Pasūtītāju, kā starpposmu izstrādē Piegādātājs sagatavo konceptuāla projektējuma aprakstu, kurā ir izklāstīti konceptuālie risinājumi un, tiek aprakstītas risinājuma komponentes, to savstarpējā saistība. Konceptuālais projektējums jāprezentē tam paredzētā seminārā un jāsaskaņo ar Pasūtītāju. Pamatojoties uz saskaņoto konceptuālo projektējumu, Piegādātājam jāsagatavo pārējās prasības. Konceptuālais projektējums ir iekļaujams kā atsevišķa sadaļa.

        3. Prototipa projektējuma un uzstādīšanas specifikācija. Piegādātājs, ņemot vērā 3.1.1.2. un 3.1.1.3. apakšpunktos izstrādāto un ar Pasūtītāju saskaņoto projektējuma aprakstu, veic tehniskā projektējuma izstrādi, kas ietver arī tā Ieviešanas plānu (turpmāk – specifikācija). Piegādātājs sagatavo un saskaņo ar Pasūtītāju izveides un ieviešanas plānu, kurā, ņemot vērā esošās situācijas analīzi, tiek precizēts piedāvājumā izklāstītais izveides plāns (gan precizējot laika plānojumu, gan iespējamu ieviešanas kārtu funkcionalitāti)

Apraksta Dokumenta sagatavošana notiek latviešu un angļu valodā. Tā struktūrā obligāti jāietver 3.1.1. apakšpunktā norādīto prasību dokumentēšana. Apraksta dokumenta saturu var strukturēt sīkāk vai savādāk atbilstoši, attiecīgajā dokumenta nodaļā vai apakšnodaļā sniedzamajai informācijai, lai nodrošinātu apraksta dokumenta skaidrību un uztveramību. Analīzes izstrāde ir jāveic atbilstošā detalizācijas pakāpē, lai tā sniegtu Pasūtītājam visaptverošu izpratni par esošo situāciju, pārliecību izstrādāt projektu un izveidot prototipu, nodrošināt tā savietojamību ar esošo sistēmu un atbilstību VILDA un AnNa ietvaram.

      1. 2.etaps: Prototipa izstrāde. Pēc punkta 3.1.1.4. specifikācijas saskaņošanas ar Pasūtītāju, Piegādātājs uzsāk, un veic pilnu Prototipa izstrādi šādā kārtība:

        1. Prototipa funkcionalitātes izstrāde. Piegādātājam jāveic pilnvērtīga Prototipa funkcionalitātes izstrāde saskaņā ar Pasūtītāja noteiktajām prasībām un specifikāciju.

        2. Prototipa integrēšana SSN sistēmā. Piegādātājam jāveic Prototipa savietojamības saskarņu izstrāde informācijas apmaiņai ar SSN sistēmām, saskaņā ar specifikācijā un Izstrādātāja noteiktajām un Pasūtītāja saskaņotajām prasībām. Integrēšanas procesā netiek traucēta SSN darbība. Prototipa un to saskarņu izstrādē jāizmanto tīmekļa pakalpiņu tehnoloģijas tādā mērā, lai piegādātā būtu integrējama SSN un Lietotāja sistēmās.

        3. Infrastruktūras izmantošana. Piegādātājam Prototipa un tās saskarņu ar SSN sistēmu izstrāde jāveic, izmantojot Piegādātāja un biznesa procesu lietotāju tehnisko infrastruktūru un izstrādei nepieciešamās programmatūras nodrošinājumu. Izstrādes ietvaros izmantotās tehniskās infrastruktūras un izstrādei nepieciešamās programmatūras nodrošinājuma izmantošanas maksai jābūt iekļautai Pretendenta finanšu piedāvājumā norādītajās izmaksās.

        4. Lietotāja nodrošinājums. Piegādātājs uzrāda Pasūtītājam un piegādā lietotājiem vismaz 10 (desmit) ATV. Piegādātājs izvēlētos Lietotājus saskaņo ar Pasūtītāju. Pasūtītājs veic Lietotāju autorizāciju SSN sistēmā.

        5. Kontrole. Piegādātājam ir jāveic Prototipa specifikācijā un ieviešanas plānā iekļauto prasību kontrole, savlaicīgi identificējot atkāpes no tām un brīdinot par to Pasūtītāju. Ne retāk kā reizi 2 (divās) nedēļās jāsniedz Pasūtītājam progresa ziņojums. Ziņojuma formāts jāsaskaņo ar Pasūtītāju.

        6. Atbilstība normatīvo aktu prasībām. Pretendentam ir jānodrošina Projektu ietvaros izstrādāto informācijas sistēmu atbilstība LR normatīvajos aktos noteiktajām prasībām sistēmas drošībai (Valsts informācijas sistēmu likums; Fizisko personu datu aizsardzības likums un tam piekritīgie normatīvie akti);

        7. Izmantojamie standarti un vadlīnijas. Izstrādātājam jāņem vērā vismaz šādos standartos un vadlīnijās noteiktais: AQAP 2210: 2006; AQAP 2110:2009; ISO/IEC 27002,IEEE 1016:1998; LVS 72:1996;12207:2008; IEEE J-STD-016, ISO/IEC 9001 vai līdzvērtīgus.

    1. II. posma ”Prototipa testēšana” izstrādes process un akceptēšanas procedūra

Kā otrais posms InDTra realizācijas projektā ir Prototipa testēšana - Piegādātājs veic prototipa testēšanas darbus, un nodrošina atbalstu Pasūtītājam akcepttestēšanas laikā šādā kārtība:

      1. Metodika un Testēšanas dokumentācija. Piegādātājs nodrošina testēšanu atbilstoši 3.1.1. apakšpunkta norādītam Testēšanas metodoloģijas aprakstam. Piegādātājam jānodrošina iepriekš minētās dokumentācijas pieejamība Pasūtītājam pēc Pasūtītāja pieprasījuma.

      2. Testēšanas apjoms. Piegādātājam jānodrošina Prototipa testēšana, kas aptver pilnvērtīgu testu veikšanu visām komponentēm, gan arī šo komponenšu savstarpējai darbībai un integrācijas pārbaudēm (testiem) ar SSN sistēmu un Lietotāju informācijas sistēmām. Testēšana (izņemot akcepttestēšana) jāveic, izmantojot Piegādātāja tehnisko infrastruktūru un specializētu testa vidi bez papildu samaksas.

      3. Akcepttestēšana. Piegādātājs sagatavo un saskaņo ar Pasūtītāju akcepttestēšanas procedūru un plānu, kurā tiek aprakstīta akceptēšanas kārtība un kritēriji, kā arī akcepttestēšanas testi.

Piegādātājam jānodrošina savas testa vides izveide. Akcepttestu lietotāju grupas testu noslēgumā Piegādātājam ir jāsagatavo akcepttestu protokoli. Protokolos ir jānorāda akcepttestu tvērums un veiktās darbības, kā arī konstatētās kļūdas vai neprecizitātes.

      1. Drošības pārbaude. Piegādātājam testēšanas ietvaros jāveic Prototipa un to komponenšu drošības pārbaudes, lai pārliecinātos par Prototipa neautorizētas izmantošanas vai rediģēšanas iespējām. Atbilstoši XxXx projekta dalībnieku kopīgajām projektam par „Pilot EU SEC Data and Data transfer security requirements” projekta dokumentāciju iesniedz pasūtītājs pēc izpildītāja pieprasījuma.

      2. Veiktspējas testēšana. Piegādātājam testēšanas ietvaros jāveic Prototipa un to komponenšu veiktspējas pārbaudes, lai pārliecinātos par prototipa arhitektūras realizācijas piemērotību atbilstoši specifikācijā noteiktajām veiktspējas prasībām, kā arī, lai identificētu iespējamos risinājumus prototipa darbības uzlabošanai. Testēšanas procesā jāveic funkcionālie testi atsevišķi visām Prototipa lietotāju lomām, pārbaudot, vai lietotājiem faktiski pieejamā funkcionalitāte ir atbilstoša sistēmas dokumentācijā noteiktajiem lietotāju lomu apgabaliem.

    1. III. posms „InDTra efektivitātes novērtējums”

Kā trešais posms InDTra realizācijas projektā ir Prototipa efektivitātes analīze, kuras ietvaros Piegādātājs sagatavo ziņojumu atbilstoši 3.1. apakšpunktā norādītājai Efektivitātes novērtēšanas metodikai un ar Pasūtītāju saskaņotajai metodikai, šādā kārtībā:

      1. Kritēriji. Efektivitātes analīze, kas veikta novērtējot vismaz 7 (septiņus) projekta sasnieguma aspektus, ieskaitot: kuģošanas informācijas un ostu formalitāšu iesniegšanas atvieglošana, integrēšana ES dalībvalstu vienota loga sistēmās, ekonomiskais izdevīgums, efektivitāte salīdzinājumā ar esošiem risinājumiem, trūkumi.

      1. Intervijas. Efektivitātes analīzes novērtēšanas procesā jāveic vismaz 10 (desmit) Lietotāju intervijas vai anketēšana pēc izvirzītajiem novērtēšanas kritērijiem.

    1. IV. posms „InDTra projekta demonstrācija” izstrādes process un akceptēšanas procedūra

Kā ceturtais posms projekta InDTra realizācijas demonstrācijas nodrošināšana, un Piegādātājam jāveic šādi pasākumi:

      1. Gala ziņojums. Piegādātājs sagatavo gala ziņojumu (kopsavilkumu) par projekta realizāciju pēc izstrādātā risinājuma ietekmes: kuģošanas informācijas un ostu formalitāšu iesniegšanas atvieglošana, integrēšana ES dalībvalstu vienota loga sistēmās, ekonomiskais izdevīgums un administratīvā sloga samazinājums, efektivitāte salīdzinājumā ar esošiem risinājumiem, InDTra Prototipa trūkumi. Kopsavilkumu sagatavo uz ne vairāk kā uz 50 lapaspusēm, sinhroni latviešu un angļu valodā, un iesniedz to Pasūtītājam saskaņošanai. Pēc saskaņošanas Piegādātājs nodrošina tā pavairošanu vismaz 50 eksemplāros. Piegādātājs arī iesniedz Pasūtītājam kopsavilkumu Microsoft Office Word (vai līdzvērtīgā) formātā.

      2. Atpazīstamība. Izstrādātājs izstrādā un nodrošina, ka saskaņojot ar Pasūtītāju, tā adresē Mexxxx xxxx 0x, Rīgā, tiek izvietots informatīvs materiāls, kas informē, ka Krasta apsardze dienestā tiek īstenots TEN – T līdzfinansētais projekts AnNa;

      1. Uzskates materiāli. Izpildītājs sagatavo vismaz 1 (vienu) vizuālu prezentāciju, kurā ietilps secīgs InDTra projekta realizācijas apraksts, sasniegtie rezultāti, gūtās pieredzes pārneses iespējas. Prezentācija jāsagatavo latviešu un angļu valodā. Izpildītājs sagatavot 1 (vienu) informatīvu brošūru, tās nodevuma formāts ir elektroniska datne, kura izmantojama brošūru pavairošanai tipogrāfijā un vismaz 100 (viens simts) gab. brošūru piegāde katrai valodai – divpusēja, krāsaina, glancēta brošūra, katras brošūras apjoms 1 (viena) A4 formāta lapa.

      1. Publicitāte. Demonstrācijas aktivitāšu gaitā Piegādātājs nodrošina Pasūtītāju ar vismaz 3 (trīs) sagatavotiem tekstiem latviešu un angļu valodā, kas satur vismaz 300 (trīs simti) vārdus un, kas paredzēti preses relīzē par aktuālo informācija par projekta īstenošanas gaitu ar atsauksmi uz Projekta koordinatoru mājas lapu xxx.xxxxxxx.xx un TEN – T līdzfinansēto projekts AnNa.

      2. Demonstrācija. Izstrādātājs nodrošina konsultatīvu atbalstu Pasūtītājam vismaz 2 (divas) publikāciju sagatavošanai un, nozīmē savu pārstāvi par Piegādātāja resursiem vismaz 1 (vienai) dalībai Eiropas līmeņa pasākumā projekta demonstrācijai.

  1. Vispārīgas prasības InDTra realizācijai

    1. Realizācija. Piegādātājam jāveic InDTra Prototipa funkcijas izstrāde un instalēšana, testēšana un jānodrošina savietojamība ar nacionālo SSN sistēmu.

    2. Piegāde. Piegādātājam ir jāveic darbi un jāpiegādā šajā specifikācijā nosauktie nodevumi, saskaņā ar šīs specifikācijas prasībām, iepirkuma līguma nosacījumiem, Latvijas Republikas normatīvo aktu un Eiropas Komisijas direktīvu prasībām, Latvijas Republikas un starptautiskajiem programmatūras izstrādes standartiem. Dokumentācijas nodevumi, plāni, protokoli, pārvaldības, sistēmas izejas kodi. Projekta dokumentācija un tehniskie pielikumi ir jāiesniedz Pasūtītājam latviešu un angļu valodā elektroniski rediģējamā (MS Office atpazīstamā vai līdzvērtīga) formātā un jāiesniedz 3 (trīs) kopijas uz CD diskiem un 2 (divos) drukātos eksemplāros parakstīšanai – katrai pusei vienu eksemplāru. Piegādātājam jāpiegādā dokumentācijā ietverto shēmu un attēlu izejas materiāli (elektroniski rediģējamā formātā). Jānodod lietošanā Pasūtītāja autorizētiem pārstāvjiem, tam izmantojot savu personālu, materiālus, inventāru un transportu.

    3. Piegādes nosacījumi dokumentācijai.

Piegādei:

  • jābūt tādai, lai trešajām pusēm būtu iespējams pārliecināties par to, ka projekta realizācija un ieviešana ir notikusi saskaņā ar izvirzītajām prasībām un nozares labo praksi;

  • jābūt tādai, lai sistēmas lietotājiem tiek sniegta visa nepieciešamā informācija, lai viņi patstāvīgi un pilnvērtīgi varētu izmantot sistēmas piedāvāto funkcionalitāti;

  • sistēmas administratoriem ir pieejama nepieciešamā informācija par sistēmas nepārtrauktu darbības nodrošināšanu atbilstoši sistēmas specifikai;

  • Pirms visu dokumentu nodevumu izstrādes uzsākšanas, Piegādātājs saskaņo dokumentu nodevumu sagatavju formātu ar Pasūtītāju. Piegādātājs nodrošina nodevumu savlaicīgu, vismaz 10 (desmit) darba dienas pirms nodevuma termiņa, iesniegšanu Pasūtītājam saskaņošanai.

    1. Darba valoda. Izpildot darba uzdevumā minētos darbus, visa komunikācija ar Pasūtītāju jānodrošina latviešu valodā vai angļu valodā (nepieciešamības gadījumā Pretendentam par saviem līdzekļiem ir jānodrošina tulkojums)..

  1. Specifiskas prasības

Piegādātājam jāveic nepieciešamie pasākumi, lai nodrošinātu projekta kvalitātes vadību atbilstoši labās prakses principiem, x.xx., bet ne tikai:

    1. Kvalitātes prasības, garantija. Piegādātājs nodrošina prototipa funkcijas kļūdu novēršanu vismaz 1 (viens) gadu no nodošanas – pieņemšanas akta parakstīšanas.

    2. Pieejamība. Piegādātājam ir jānodrošina pasūtītāja pieteikumu saņemšana pa e-pastu, fiksētās līnijas telefonu un mobilo telefonu 24 stundas diennaktī, saskaņā Pasūtītāja funkcionālo izmaiņu atbalsta pieteikumus klasifikāciju pēc sekojošām prioritātēm:

  • avārijas pieteikumiem reakcijas laiks ir ne vairāk kā 2 stundas, ja radusies neskaidrība par SSN darbību, integrēto prototipa funkcionalitāti, vai ir radies datu bojājums, kā rezultātā SSN sistēmai vai/ un Prototipam nav iespējama darbības turpināšana;

  • konsultācija/ kļūdu labošana pieteikuma reakcijas laiks ir ne vairāk kā 2 darba dienas, radusies neskaidrība par SSN darbību, integrēto prototipa funkcionalitāti, ir radies datu bojājums, ir atklāta funkcionalitātes, savietojamības vai programmēšanas kļūda. SSN sistēmai vai/ un Prototipam ir iespējama darba turpināšana bez būtiskiem ierobežojumiem vai ir pieejams problēmas apiešanas risinājums.

Reakcijas laiks ir laiks no pieteikuma saņemšanas brīža līdz brīdim, kad izpildītājs paziņo, ka pieteikums ir saņemts un ir uzsākta pieteikuma apstrāde.

    1. Veiktspējas pieejamība. Pieejamībai jābūt ne mazākai nekā 99% (24*7 režīmā), par atskaites punktu pieņemot gadu (neskaitot paredzētos ar Pasūtītāju saskaņotos pārtraukumus). Katra ceturkšņa laikā pieļaujamie pārtraukumi nepārsniedz 22 (divdesmit divas) stundas, katra pārtraukuma ilgums nedrīkst pārsniegt 4 (četras) stundas.

    2. Informētība. Piegādātājs nodrošina apmācību vismaz 4 (četri) cilvēkiem –informēšanai par būtiskiem aspektiem prototipa lietošanā, to administrēšana un pasākumi, kas nepieciešami sistēmā to pilnvērtīgai funkcionēšanai.


Pielikums Nr. 4.

Konkursa, identifikācijas

Nr. VAMOIC 2014/171, nolikumam

TEHNISKAIS PIEDĀVĀJUMS

(iesniedz par katru iepirkuma priekšmeta daļu atsevišķi)


Detalizēts piedāvātās Preces tehnoloģiskā risinājuma apraksts:

(..)



  1. Piedāvātais Preces izstrādes termiņš:________________________________.

  2. Preces izstrādē izmantotās programmatūras ražotāju saraksts:______________________;

  3. Apliecinām, ka ___________(pretendenta nosaukums) rīcībā ir visi nepieciešamie resursi un programmatūras Preces izstrādei;

  4. Apliecinām, ka konsultācijas un apmācība, Preces izstrādes laikā, tiks nodrošināta latviešu valodā.

Apliecinām ka konsultācijas un apmācība, Preces izstrādes laikā, tiks nodrošināta latviešu valodā

Paraksts:

Vārds, uzvārds:

Amats:

Tehniskais piedāvājums sastādīts un parakstīts 2014.gada

z. v.


Pielikums Nr. 5.

Konkursa, identifikācijas

Nr. VAMOIC 2014/171, nolikumam



LĪGUMS Nr. P-___/1.RNC/VAMOIC/2014/171

par tehniskā risinājuma prototipa izstrādi projekta „ANNA-„Attīstīti valstu pārvaldes iestāžu tīkli” Nr.2012-EU-21019-S”, ietvaros

ID Nr. VAMOIC 2014/171


_________ 201__. gada ___. _________


Nacionālo bruņoto spēku Nodrošinājuma pavēlniecības 1. reģionālais nodrošinājuma centrs, tā komandiera, ________________ personā, kurš darbojas uz nolikuma pamata (turpmāk – „PASŪTĪTĀJS”) no vienas puses, un


_______________, kas reģistrēta ar reģistrācijas Nr. ____________ turpmāk tekstā – „IZPILDĪTĀJS”), tās _______________ personā, no otras puses,

abi kopā saukti „Puses” un katrs atsevišķi „Puse”,


pamatojoties uz atklāta konkursa „Tehniskā risinājuma prototipa izstrāde AnNa (VILDA) projekta ietvaros”, identifikācijas Nr. VAMOIC 2014/171, (turpmāk tekstā – Konkurss) rezultātiem 201___.gada ___._______ protokolā Xx.Xx. VAMOIC 2014/171-____, noslēdz šādu līgumu (turpmāk – „Līgums”):


  1. LĪGUMA PRIEKŠMETS

    1. PASŪTĪTĀJS pasūta, un IZPILDĪTĀJS apņemas ar saviem darbiniekiem un materiāltehniskajiem līdzekļiem veikt tehniskā risinājuma prototipa izstrādi AnNa (Attīstīti valstu pārvaldes iestāžu tīkli) (VILDA) (Vienots informācijas logs jūrniecības un loģistikas datu administrēšanai) projekta ietvaros, kā arī personāla apmācību un ekspluatācijas atbalstu, atbilstoši Tehniskajai specifikācijai (Pielikums Nr.1), (turpmāk – Prece) šādās daļās:

      1. Iepirkuma priekšmeta I daļā - Prototipa izstrāde "Automātiska, vienota datu apmaiņas saslēguma izstrādei starp ES dalībvalstīm ostas formalitāšu un kuģošanas drošības datu apmaiņai”, turpmāk Prece Nr.1;

      2. Iepirkuma priekšmeta II daļā - Datu pārraides tīkla modeļa prototipa izveide Rīgas jūras līcī (I-CaDE), turpmāk – Prece Nr.2;

      3. Iepirkuma priekšmeta III daļā - Automatizētā risinājuma izstrāde, kuģošanas informācijas un ostu formalitāšu datu atpazīšanai, turpmāk – Prece Nr.3;

      4. Iepirkuma priekšmeta IV daļā - Kuģošanas informācijas un ostu formalitāšu datu konvertēšanas un apmaiņas moduļa izstrāde, turpmāk – Prece Nr.4.

turpmāk visas iepriekš minētās daļas kopā sauktas kā – Xxxxx

    1. IZPILDĪTĀJA veicamie darbi Preces izstrādes ietvaros ir sadalīti atsevišķās kārtās (posmos), turpmāk – Nodevumi, kuru saturs un darba apjoms, summas un termiņi noteikti Līguma pielikumā Nr.2 „Finanšu piedāvājums” un Līguma pielikumā Nr.1 Tehniskā specifikācija, IZPILDĪTĀJA piedāvājumā Konkursam (turpmāk tekstā - “Piedāvājums”) un iepirkuma komisijas sēdes 201__.gada __.____ protokolā ID Nr. VAMOIC 2014/171-____.

    2. Preces piegādes vieta ir: Jūras spēku flotiles Krasta apsardzes dienesta Jūras meklēšanas un glābšanas koordinācijas centrs (MRCC), Rīga, Xxxxxx xxxx 0x, XX-0000, Xxxxxxx.


  1. PRECES CENA UN LĪGUMA KOPĒJĀ SUMMA

    1. Detalizēts Preces izcenojums norādīts Līguma pielikumā Nr.2 „Finanšu piedāvājums”.

    2. Līguma summa bez pievienotās vērtības nodokļa (turpmāk - PVN) par :

      1. Preci Nr.1 ir ___ EUR (__________euro un ______centi);

      2. Preci Nr.2 ir ____EUR (_________euro un _______centi);

      3. Preci Nr.3 ir ___ EUR (__________euro un ________centi);

      4. PreciNr.4 ir ____EUR (___________euro un _______ centi).

    3. Līguma summā ir iekļautas visas ar Līguma izpildi saistītās izmaksas, tajā skaitā PASŪTĪTĀJA personāla apmācības, konsultācijas, transporta izdevumi, darbaspēka izmaksas u.c. izdevumi, kā arī visi nodokļi un nodevas (izņemot PVN).

    4. PVN tiek piemērots saskaņā ar Latvijas Republikas normatīvajos aktos noteikto kārtību un apmēru.


  1. PUŠU PIENĀKUMI

    1. IZPILDĪTĀJS:

      1. izstrādā un iesniedz Pasūtītājam Tehniskajā specifikācijā norādītos Nodevumus, veic personāla apmācību un nodrošina ekspluatācijas atbalstu saskaņā ar Līguma un tā pielikumu prasībām;

      2. atbilstoši Tehniskajam piedāvājumam nodrošina projekta risku vadību;

      3. 10 (desmit) darba dienu laikā no Līguma noslēgšanas iesniedz PASŪTĪTĀJAM apstiprināšanai darbinieku sarakstu, kuriem nepieciešams iekļūt PASŪTĪTĀJA telpās;

      4. 10 (desmit) darba dienu laikā no PASŪTĪTĀJA saskaņā ar Līguma 3.2.1. punktu iesniegta motivēta atteikuma, saskaņo darbinieku sarakstu, vai nekavējoties konstatējot nepieciešamību veikt izmaiņas iepriekš apstiprinātā sarakstā, sagatavo labotu sarakstu un iesniedz to PASŪTĪTĀJAM atkārtotai apstiprināšanai;

      5. nodrošina, ka gadījumā, kad Preces izstrādei nepieciešams iekļūt PASŪTĪTĀJA telpās, tiek iesaistīti tikai tie IZPILDĪTĀJA darbinieki, kuri norādīti PASŪTĪTĀJA apstiprinātajā darbinieku sarakstā. Gadījumos, kad IZPILDĪTĀJS vēlas veikt izmaiņas iepriekš apstiprinātajā darbinieku sarakstā, tā pienākums ir veikt tā atkārtotu saskaņošanu ar PASŪTĪTĀJU;

      6. Līguma izpildē iesaistīto darbinieku aizvietošanas gadījumā, IZPILDĪTĀJA pienākums ir nodrošināt darba izpildi ar tādiem darbiniekiem, kuru kvalifikācija atbilst Tehniskajā specifikācijā izvirzītajiem kritērijiem;

      7. nodrošina, ka Preces izstrādē iesaistītajiem tehniskajiem darbiniekiem ir darbu izpildei atbilstoša kvalifikācija (izglītība);

      8. bez maksas novērš visas kļūdas un trūkumus, ja tādi tiks atklāti pēc Nodevuma saņemšanas;

      9. pēc PASŪTĪTĀJA pieprasījuma sniedz visu nepieciešamo informāciju par Līguma izpildē iesaistītajiem darbiniekiem;

      10. reizi mēnesī iesniedz PASŪTĪTĀJAM pārskatu par projekta realizāciju un aktualizē risku pārvaldības plānu;

      11. nodrošina Tehniskajā specifikācijā un Tehniskajā piedāvājumā norādīto standartu un metodikas ievērošanu projekta realizācijā;

      12. nodrošina iepirkuma dokumentācijā norādīto speciālistu un apakšuzņēmēju personisku piedalīšanos iepirkuma priekšmeta realizācijā. Gadījumā, ja nepieciešama iepirkuma dokumentācijā norādīto speciālistu vai apakšuzņēmēju aizvietošana, IZPILDĪTĀJS ir tiesīgs veikt šādu aizvietošanu tikai pēc PASŪTĪTĀJA atļaujas saņemšanas, ievērojot Publisko iepirkumu likuma 68.panta prasības;

      13. IZPILDĪTĀJS nodrošina kvalitātes un garantijas prasību izpildi saskaņā ar Līgumu un Līguma pielikumu Nr.1 „Tehniskā specifikācija;

      14. sagatavo un iesniedz PASŪTĪTĀJAM prototipa u.c. dokumentāciju, kas saistīta ar Preces izstrādi saskaņā ar Tehniskajā specifikācijā norādītajām valodas prasībām;

      15. izpildot darba uzdevumā, minētos darbus, nodrošina komunikāciju ar PASŪTĪTĀJU latviešu valodā;

      16. apņemas aizsargāt, neizplatīt un bez iepriekšējas savstarpējas rakstiskas saskaņošanas ar PASŪTĪTĀJU pilnīgi vai daļēji neizpaust trešajām personām Līguma vai citu ar tā izpildi saistīto dokumentu saturu, kā arī tehniska, komerciāla un jebkāda cita rakstura informāciju, kas saņemta no PASŪTĪTĀJA vai iegūta šajā Līgumā paredzēto darbu izpildes laikā;

      17. IZPILDĪTĀJA kontaktpersona Līguma darbības laikā: ______________.

    2. PASŪTĪTĀJS:

      1. 10 (desmit) darba dienu laikā no Līguma 3.1.3. vai 3.1.4.punktā IZPILDĪTĀJA iesniegtā saraksta saņemšanas, izvērtē IZPILDĪTĀJA Līguma izpildē iesaistāmo darbinieku iesniegto sarakstu, pēc nepieciešamības iesniedzot to kompetentai valsts drošības iestādei pārbaudes veikšanai, un sniedz atbildi, akceptējot vai noraidot sarakstā uzskaitīto darbinieku iesaistīšanu Preces izstrādē;

      2. pieņem Līguma prasībām atbilstoši izveidotos un uzstādītos Nodevumus, x.xx. (instalēto) prototipu, ja tas izveidots, uzstādīts (instalēts) un testēts saskaņā ar Līguma un tā pielikumu noteikumiem un atbilst vispārpieņemtām kvalitātes prasībām un spēkā esošajiem normatīvo aktu noteikumiem;

      3. samaksā par pieņemto Līguma prasībām atbilstošo, kvalitatīvo Preci un tās izstrādi, Līgumā noteiktajā kārtībā;

      4. ir tiesīgs jebkurā laikā veikt Līguma izpildes pārbaudi, nepieciešamības gadījumā pieaicinot speciālistus un ekspertus;

      5. ir tiesīgs veikt turpmākās izmaiņas vai papildinājumus IZPILDĪTĀJA piegādātajā programmatūrā (tajā skaitā arī paplašinātajā), bet nav tiesīgs veikt programmatūras tālāku izplatīšanu trešajām personām;

      6. PASŪTĪTĀJA kontaktpersonas, kas atbild:

3.2.4.1. par Līguma izpildes kontroli – __________, tālr.:, e-pasts:;

3.2.4.2. kontaktpersona par ________ sistēmas darbību – Xxxxxx Xxxxxxx, tālr.: x000 00000000, e-pasts: xxxxxx.xxxxxxx@xxxx.xx.


  1. APAKŠUZŅĒMĒJS

    1.  Saskaņā ar IZPILDĪTĀJA iesniegto Piedāvājumu atklātā konkursā, IZPILDĪTĀJS Līguma izpildē piesaista Līgumā norādītos Apakšuzņēmējus un nodod Apakšuzņēmējiem izpildei sekojošas Līguma priekšmeta daļas:

      1. Apakšuzņēmējs Nr.1 nodrošina (veicamo darbu uzskaitījums)    Paredzamais apjoms līdz __% no kopējās Līgumcenas;

      2. Apakšuzņēmējs Nr.2 nodrošina  (veicamo darbu uzskaitījums)    Paredzamais apjoms līdz __% no kopējās Līgumcenas;

    2. Apakšuzņēmējs veic tam uzdoto darba apjomu un pienākumus saskaņā ar IZPILDĪTĀJA piedāvājumu.

    3.  IZPILDĪTĀJS ir tiesīgs nodot Apakšuzņēmējam tikai to informāciju, kas tieši saistīta ar Apakšuzņēmējam nodoto Līguma daļu un apjomu. Apakšuzņēmējam nav tiesību iegūto informāciju par PASŪTĪTĀJU, tā iekārtām un sistēmām izpaust trešajām personām.

    4. IZPILDĪTĀJS ir atbildīgs par to, lai saskaņā ar šo Līgumu darbu izpildē iesaistītais Apakšuzņēmējs nepiesaistītu darbu izpildē trešās personas, tajā skaitā apakšuzņēmējus.

    5. IZPILDĪTĀJS pilnībā uzņemas atbildību par Līguma izpildi kopumā, tajā skaitā nodrošina, ka Apakšuzņēmēji ievēros visus šajā Līgumā minētos noteikumus.

    6. IZPILDĪTĀJS Līguma darbības laikā drīkst mainīt Līguma izpildē piesaistītos Apakšuzņēmējus tikai ar PASŪTĪTĀJA rakstveida piekrišanu. Apakšuzņēmēju maiņas gadījumā IZPILDĪTĀJAM ir pienākums par katru no piesaistītajiem Apakšuzņēmējiem iesniegt visu dokumentāciju, kas attiecībā uz Apakšuzņēmējiem tika pieprasīta Atklāta konkursa nolikumā.

    7. IZPILDĪTĀJAM ir pienākums nekavējoties, tiklīdz tas kļūst zināms, informēt PASŪTĪTĀJU par jebkurām izmaiņām saistībā ar Apakšuzņēmējiem.


  1. PRECES IZSTRĀDES UN PIEGĀDES KĀRTĪBA UN RISKA PĀREJA

    1. IZPILDĪTĀJS uzsāk Preces izstrādi ne vēlāk kā 5 (piecu) darba dienu laikā no Līguma spēkā stāšanās dienas, saskaņā ar IZPILDĪTĀJA iesniegto laika grafiku (Pielikums Nr.__).

    2. Tehniskajā specifikācijā paredzētie un Pušu apstiprinātie Nodevumi tiek iesniegti atbilstoši kalendārajam plānam, saskaņā ar IZPILDĪTĀJA iesniegto laika grafiku (Pielikums Nr.__).

    3. Nodevums, kuru IZPILDĪTĀJS sniedz PASŪTĪTĀJAM, ir uzskatāms par pieņemtu tikai ar brīdi, kad PASŪTĪTĀJS Nodevumu ir pārbaudījis, pieņēmis un ir abpusēji parakstīts Nodevuma nodošanas - pieņemšanas akts, turpmāk – Nodevuma pieņemšanas akts. Gala nodošanas – pieņemšanas akts tiek parakstīts, ja ir parakstīti visi Nodevuma pieņemšanas akti un Prece ir piegādāta pilnā apmērā.

    4. Iesniedzamos dokumentācijas Nodevumus IZPILDĪTĀJS iesniedz PASŪTĪTĀJA kontaktpersonai saskaņošanai elektroniski rediģējamā formātā.

    5. PASŪTĪTĀJS nodevumu izskatīšanu veic 5 (piecu) darba dienu laikā un atkarībā no izskatīšanas rezultātiem, akceptē iesniegto Nodevumu un paraksta Nodevuma pieņemšanas aktu, vai atgriež to trūkumu novēršanai.

    6. Pēc PASŪTĪTĀJA norādīto trūkumu novēršanas Nodevums iesniedzams atkārtotai izskatīšanai. Atkārtotā izskatīšanā tiek pārbaudīta trūkumu novēršana, jaunas pretenzijas var tikt izvirzītas kontekstā ar iepriekšējo iebildumu novēršanu.

    7. Programmatūra tiek nodota testēšanai, iesniedzot PASŪTĪTĀJAM instalācijas pakotni un instalācijas instrukciju.

    8. Pēc programmatūras instalācijas, PASŪTĪTĀJS 10 (desmit) darba dienu laikā veic prototipa testēšanu. Testēšana tiek uzskatīta par veiksmīgu, ja testēšanas laikā netiek konstatētas 1.vai 2.prioritātes kļūdas vai vairāk, kā 10 trešās prioritātes kļūdas.

    9. Konstatējot kļūdas, PASŪTĪTĀJS nodod programmatūru trūkumu novēršanai, pēc kuras tiek veikta atkārtota testēšanas procedūra.

    10. Prece ir uzskatāma par piegādātu, ja iesniegti un akceptēti visi paredzētie Nodevumi un par tiem ir parakstīts nodošanas – pieņemšanas akts, kā arī parakstīts gala pieņemšanas – nodošanas akts.

    11. Ar šī Līguma izpildi saistītajos dokumentos (aktos, rēķinos u.c.) PIEGĀDĀTĀJS iekļauj atsauci uz Eiropas Komisijas līdzfinansējumu šādā redakcijā: „ANNA-Attīstīti valstu pārvaldes iestāžu tīkli” Nr.2012-EU-21019-S.”.




  1. NORĒĶINU KĀRTĪBA

    1. PASŪTĪTĀJS samaksā par kvalitatīvu, atbilstoši Līguma noteikumiem un Tehniskajai specifikācijai izstrādātu Preci, bankas pārskaitījuma veidā Līguma kopējās summas ietvaros.

    2. Samaksa PASŪTĪTĀJS veic šādā kārtībā:

      1. priekšapmaksu ­­___% ( ________procentu) apmērā no Līguma kopējās summas 10 (desmit) kalendāro dienu laikā no rēķina un priekšapmaksas bankas garantijas (beznosacījumu) saņemšanas dienas pie PASŪTĪTĀJA (atzīme par saņemšanu);

      2. Priekšapmaksa tiek dzēsta pakāpeniski, iesniedzot Nodevumus par Preces izstrādi, ko apliecina UZŅĒMĒJA iesniegtie un PASŪTĪTĀJA akceptētie Nodevumu pieņemšanas akti.

      3. pēc priekšapmaksas dzēšanas, tiek veikta samaksa par katru Nodevumu pilnā apmērā saskaņā ar IZPILDĪTĀJA iesniegtiem un PASŪTĪTĀJA apstiprinātiem Nodevumu pieņemšanas aktiem. Kārtējo maksājumu PASŪTĪTĀJS veic 30 (trīsdesmit) kalendāro dienu laikā pēc attiecīgā Pakalpojuma izpildes posma pabeigšanas un abpusēji parakstīta Nodevuma pieņemšanas akta un rēķina saņemšanas dienas (PASŪTĪTĀJA saņemšanas atzīme).

    3. Par samaksas dienu tiek uzskatīta diena, kad PASŪTĪTĀJS veicis pārskaitījumu uz IZPILDĪTĀJA rēķinā norādīto norēķinu kontu.

    4. Katra no Pusēm sedz savus izdevumus par banku pakalpojumiem, kas saistīti ar naudas pārskaitījumiem.

    5. Ar šī Līguma izpildi saistītajos dokumentos (aktos, rēķinos,) IZPILDĪTĀJS iekļauj atsauci uz Eiropas Savienības līdzfinansējumu šādā redakcijā: „ANNA-Attīstīti valstu pārvaldes iestāžu tīkli” Nr.2012-EU-21019-S”.

    6. Ja veikta Līguma prasībām neatbilstošas Preces izstrāde un/vai piegāde, un par to Līgumā noteiktajā kārtībā tiek sastādīts akts, samaksa tiek veikta pēc konstatēto trūkumu un nepilnību novēršanas un Preces izstrādes un/vai piegādes atbilstoši Līguma noteikumiem.

    7. PASŪTĪTĀJAM ir tiesības veikt grozījumus Līgumā paredzētajā norēķinu kārtībā atkarībā no valsts budžeta atvēruma, rakstveidā par to informējot IZPILDĪTĀJU.

    8. IZPILDĪTĀJS, pamatojoties uz PASŪTĪTĀJA iesniegtu rēķinu, 30 (trīsdesmit) kalendāro dienu laikā no rēķina izrakstīšanas dienas atmaksā PASŪTĪTĀJAM avansā saņemtos naudas līdzekļus, kas nav dzēsti ar kvalitatīvi izpildītiem un pieņemtiem Nodevumiem, pārskaitot naudas līdzekļus rēķinā uzrādītajā PASŪTĪTĀJA kontā.

    9. IZPILDITĀJS nodrošina priekšapmaksas bankas garantijas (beznosacījumu) spēkā esamību līdz laikam, kad IZPILDĪTĀJS Līgumā noteiktajā kārtībā ar izpildītajiem Nodevumiem ir dzēsis priekšapmaksas maksājumu par ko abpusēji ir parakstīts Nodevuma pieņemšanas akts.

    10. Ja IZPILDĪTĀJS neiesniedz spēkā esošu priekšapmaksas bankas garantiju (beznosacījumu), uzskatāms, ka IZPILDĪTĀJS ir atteicies no Līguma izpildes.

    11. Priekšapmaksas bankas garantija (beznosacījumu) tiek atgriezta, kad IZPILDĪTĀJS ir veicis Preces izstrādi samaksātās priekšapmaksas summas apmērā.

    12. PASŪTĪTĀJS rakstveidā informē IZPILDĪTĀJU par priekšapmaksas bankas garantijas (beznosacījumu) atgriešanu bankai.


  1. SANKCIJAS

    1. Ja IZPILDĪTĀJS atsakās no Līguma izpildes, PASŪTĪTĀJAM ir tiesības piemērot IZPILDĪTĀJAM līgumsodu 10% (desmit procentu) apmērā no Līguma kopējās summas un ieturēt priekšapmaksas bankas garantiju neizpildīto darbu apmērā. Līgumsoda samaksas termiņš ir 15 (piecpadsmit) kalendārās dienas no līgumsoda rēķina izsūtīšanas dienas (pasta zīmogs). Par atteikšanos no Līguma izpildes šī apakšpunkta izpratnē tiek uzskatīta atteikšanās no Preces izstrādes vai piegādes.

    2. Ja IZPILDĪTĀJS neuzsāk vai neveic Preces izstrādi vai piegādi Līguma 5.1. un/ vai 5.2. punktā noteiktajos termiņos, PASŪTĪTĀJAM ir tiesības piemērot līgumsodu. Šajā gadījumā IZPILDĪTĀJS maksā PASŪTĪTĀJAM līgumsodu 0,2 % (divas desmitdaļas no procenta) apmērā no Līguma kopējās summas par katru nokavēto dienu, 10 (desmit) kalendāro dienu laikā, saskaņā ar PASŪTĪTĀJA izrakstītu rēķinu.

    3. Ja IZPILDĪTĀJS nenodrošina kvalitātes un garantijas prasību izpildi saskaņā ar Līguma pielikumu Nr.1 „Tehniskā specifikācija”, tajā skaitā Preces izstrādes garantijas apkalpošanas laikā nenodrošina Līguma 1.pielikumā „Tehniskā specifikācija” norādīto 1.vai 2.prioritātes kļūdu novēršanu, tad PASŪTĪTĀJAM ir tiesības piemērot līgumsodu. Šajā gadījumā IZPILDĪTĀJS maksā līgumsodu 5.00 EUR (piecus euro un 00 centus) par katru nokavēto stundu, 10 (desmit) kalendāro dienu laikā, saskaņā ar PASŪTĪTĀJA izrakstītu rēķinu.

    4. Līgumsods, kas piemērots pamatojoties uz Līguma 7.2. un 7.3.punktu, kopumā nedrīkst pārsniegt 10% no Līguma kopējās summas.

    5. PASŪTĪTĀJAM ir tiesības ieskaita kārtībā samazināt maksājamo naudas summu par Preci tādā apmērā, kāda ir Līguma 7.1. un 7.2. un 7.3. punktā noteiktajā kārtībā aprēķinātā līgumsoda summa.

    6. Ja PASŪTĪTĀJS nesamaksā IZPILDĪTĀJAM par veikto Preces izstrādi vai piegādi Līgumā noteiktajā termiņā un kārtībā, tad IZPILDĪTĀJAM ir tiesības piemērot līgumsodu. Šajā gadījumā PASŪTĪTĀJS maksā IZPILDĪTĀJAM līgumsodu 0,2 % (divas desmitdaļas no procenta) apmērā no nesamaksātās summas par katru nokavēto dienu, bet ne vairāk kā 10 % (desmit procenti) no Līguma kopējās summas, 10 (desmit) kalendāro dienu laikā, saskaņā ar IZPILDĪTĀJA izrakstītu rēķinu.

    7. Līgumsoda samaksa neatbrīvo puses no saistību izpildes, izņemot Līguma 7.1.punktu.


  1. GARANTIJAS SAISTĪBAS

    1. IZPILDĪTĀJS pilda Preces izstrādes un piegādes garantijas saistības ____ (______) mēnešus no Preces pieņemšanas dienas, kas tiek apliecināta ar abpusēji parakstītu Preces gala pieņemšanas - nodošanas aktu.

    2. PASŪTĪTĀJS ir tiesīgs pieteikt IZPILDĪTĀJAM prasījumu visā garantijas termiņa laikā saskaņā ar IZPILDĪTĀJA nodrošinātās garantijas nosacījumiem. Garantijas saistības ietver programmnodrošinājuma kļūdu un programmatūras bojājumu novēršanu. Minēto pasākumu izpildei IZPILDĪTĀJS kopā ar PASŪTĪTĀJU var organizēt attālinātās apkalpošanas pasākumus. Minētos pasākumus IZPILDĪTĀJS veic uz sava rēķina.

    3. Garantijas termiņa laikā IZPILDĪTĀJS nodrošina nepieciešamo un/vai pieprasīto Sistēmas tehnisko apkopi un darbības kvalitātes nodrošināšanai atbilstoši „Tehniskajai specifikācijai” un Līguma un tā pielikumu noteikumiem.

    4. IZPILDĪTĀJS garantijas termiņa laikā nodrošina PASŪTĪTĀJAM iespēju 24 stundas diennaktī pieteikt konstatētos trūkumus pa tālr. Nr.: _____________, e-pastu: ___________. IZPILDĪTĀJAM, uzsākot pildīt garantijas saistības, ir jāiesniedz PASŪTĪTĀJAM prasījumu pieteikšanas (24 stundas dienā un 7 dienas nedēļā) kontaktinformācija (tālrunis, fakss, e-pasts) un jāinformē par prasījumu pieteikšanas kārtību.


  1. NEPĀRVARAMA VARA

    1. Puses tiek atbrīvotas no Līguma saistību izpildes, ja iestājas nepārvaramas varas apstākļi. Pie nepārvaramas varas apstākļiem tiek pieskaitīti: ugunsgrēks, plūdi, zemestrīce un citi ārkārtēja rakstura gadījumi, ko Puses nevarēja iepriekš paredzēt.

    2. Gadījumā, ja iestājas Līguma 9.1.punktā noteiktie nepārvaramas varas apstākļi, Līgumā noteiktie termiņi tiek pagarināti attiecīgi par tādu laika periodu, par kādu nepārvaramas varas apstākļi aizkavējuši Līguma izpildi.

    3. Puses par Līguma izpildi traucējoša negadījuma sākuma laiku un izbeigšanos 5 (piecu) kalendāro dienu laikā informē otru Pusi. Nesavlaicīga paziņojuma gadījumā vainīgā Puse netiek atbrīvota no saistību izpildes.

    4. Ja nepārvaramas varas apstākļu dēļ Preces piegāde aizkavējas vairāk nekā 30 (trīsdesmit) kalendārās dienas, katra no Pusēm ir tiesīga vienpusēji atkāpties no Līguma par to rakstveidā brīdinot otru Pusi 5 (piecas) darba dienas iepriekš. Šajā gadījumā Xxxxx veic savstarpējo norēķinu par IZPILDĪTĀJA kvalitatīvi izpildīto Preces izstrādi un PASŪTĪTĀJA priekšapmaksā izmaksātajām summām.


  1. AUTORTIESĪBAS

    1. IZPILDĪTĀJS garantē, ka Prece tiks izstrādāta vienīgi PASŪTĪTĀJA vajadzībām un visi Preces izstrādes ietvaros veikto darbu rezultātā radītie un ar tiem saistītie materiāli pēc Līguma izpildes pilnībā tiks nodoti PASŪTĪTĀJAM.

    2. PASŪTĪTĀJAM pāriet visas autora mantiskās izņēmuma tiesības (Autortiesību likuma 15.panta otrā daļa) uz Līguma izpildes rezultātā izstrādātajiem un PASŪTĪTĀJAM nodotajiem prototipa programmatūras kodiem, dokumentāciju un materiāliem, ar brīdi, kad PASŪTĪTĀJS ir veicis pilnu samaksu par Xxxxx.

    3. IZPILDĪTĀJS garantē, ka turpmākos 99 (deviņdesmit deviņus) gadus neizmantos Autortiesību likuma 14.pantā pirmajā daļā noteiktās autora personiskās tiesības uz izlemšanu, vai darbs tiks izziņots un, kad tas tiks izziņots (14.panta pirmās daļas 2.punkts), darba atsaukšanu (14.panta pirmās daļas 3.punkts), darba neaizskaramību (14.panta pirmās daļas 5.punkts) un pretdarbību (14.panta pirmās daļas 6.punkts)


  1. STRĪDU IZSKATĪŠANA UN LĪGUMA IZBEIGŠANA

    1. Strīdus, nesaskaņas un citus jautājumus, kas var rasties Līguma izpildes rezultātā vai sakarā ar Līgumu, Puses risina savstarpēju pārrunu ceļā. Ja Puses nevar panākt vienošanos, tad domstarpības risināmas Latvijas Republikas tiesā, saskaņā ar Latvijas Republikā spēkā esošajiem normatīvajiem aktiem.

    2. Puses var izbeigt Līgumu pirms Līguma termiņa beigām, Pusēm rakstveidā savstarpēji vienojoties.

    3. PASŪTĪTĀJAM ir tiesības vienpusēji atkāpties no Līguma bez IZPILDĪTĀJA piekrišanas:

      1. ja IZPILDĪTĀJA vainas dēļ Prece netiek akceptēta 30 (trīsdesmit) kalendāro dienu laikā pēc Līguma 5.2.punktā norādītā kalendārā plānā noteiktā termiņa;

      2. IZPILDĪTĀJS nepilda garantijas saistības;

      3. Līgumā noteiktajā kārtībā aprēķinātais līgumsods sasniedzis 10% no Līguma kopējās summas.

    4. Līguma 11.3. punktā noteiktajos gadījumos Līgums uzskatāms par izbeigtu 7. (septītajā) dienā pēc PASŪTĪTĀJA paziņojuma par atkāpšanos (ierakstīta vēstule) izsūtīšanas dienas (Pasta zīmogs).

    5. Izbeidzot Līgumu 11.3. punktā noteiktajos gadījumos, IZPILDĪTĀJS atmaksā PASŪTĪTĀJAM tā iepriekš samaksāto priekšapmaksu, maksā Līgumā noteikto līgumsodu un atlīdzina visus radušos zaudējumus.

    6. Līguma darbības laikā Pusēm ir tiesības veikt izmaiņas maksājumu kārtībā attiecībā uz priekšapmaksas maksājumu apmēru, ņemot vērā prototipa darbības testu rezultātus un termiņus.


  1. CITI NOTEIKUMI

    1. Līgums stājas spēkā ar tā abpusēju parakstīšanu un ir spēkā līdz Pušu saistību pilnīgai izpildei, bet ne ilgāk kā to paredz Publisko iepirkumu likums.

    2. Visi Līguma grozījumi vai papildinājumi tiek izdarīti rakstiski, Pusēm tos parakstot, un ir spēkā no to visu eksemplāru parakstīšanas brīža.

    3. Līguma darbības laikā Pusēm ir tiesības veikt izmaiņas Līguma 6.2.3. punktā noteiktajā samaksas kārtībā un apmērā.

    4. Izmaiņas Līguma 6.2.3. punktā IZPILDĪTĀJAM jāpieprasa PASŪTĪTĀJAM rakstveidā, norādot objektīvu pamatojumu.

    5. Izmaiņas Līguma 6.2.3. punktā noteiktajā samaksas kārtībā un apmērā nemaina nekādus citus Līguma nosacījumus, un jebkurā gadījumā IZPILDĪTĀJAM ir pienākums pildīt visas Līguma saistības.

    6. Visi Līgumā minētie pielikumi, kā arī pēc Līguma slēgšanas sastādītie Līguma grozījumi vai papildinājumi, ja tie ir sastādīti, ievērojot Līguma 12.2.punkta noteikumus, ir Līguma neatņemamas sastāvdaļas.

    7. Ja kādi no Līguma noteikumiem zaudē juridisku spēku, tas nerada pārējo noteikumu spēkā neesamību. Spēkā neesoši noteikumi jāaizstāj ar citiem Līguma mērķiem un saturam atbilstošiem noteikumiem.

    8. Ja kāda no Pusēm tiek reorganizēta vai likvidēta, Līgums paliek spēkā un tā noteikumi ir saistoši Pušu saistību un tiesību pārņēmējiem.

    9. Gadījumos, kas nav paredzēti Līgumā, Puses rīkojas saskaņā ar spēkā esošajiem normatīvajiem aktiem.

    10. Puses rakstveidā (ierakstīta vēstule) paziņo viena otrai par juridiskā statusa, juridiskās vai biroja adreses, bankas rekvizītu maiņu, tās reorganizāciju vai likvidāciju, Līgumā norādīto kontaktpersonu maiņu, kā arī citu rekvizītu izmaiņām - 3 (trīs) darba dienu laikā. Pēc paziņojuma saņemšanas (kancelejas atzīme) tas kļūst par Līguma neatņemamu sastāvdaļu.

    11. Paziņojumi par atkāpšanos no Līguma vai cita veida korespondence, kas attiecas uz Līgumu, ir jānosūta ierakstītā vēstulē uz Līgumā norādītajām adresēm.

Līgums sagatavots latviešu valodā kopā uz _____ () lapām, no kurām __ () lapas ir Līguma teksts, () lapas - pielikums Nr.1 ”Tehniskā specifikācija”, 1 (viena) lapa – pielikums Nr.2 „Finanšu piedāvājums”, __ () lapas – pielikums Nr.3 „Kalendārais plāns”___(), lapas – pielikums Nr.4 „Priekšapmaksas bankas garantija”, 2 (divos) eksemplāros ar vienādu juridisku spēku, no kuriem viens glabājas pie PASŪTĪTĀJA un otrs pie IZPILDĪTĀJA.



  1. PUŠU JURIDISKĀS ADRESES, REKVIZĪTI UN PARAKSTI

PASŪTĪTĀJS:

IZPILDĪTĀJS:

NBS NP 1.reģionālais nodrošinājuma centrs

Adrese: Xxxx xxxx 0, Xxxxxxx, XX-0000

Tālr.: x000 00000000

Fakss: x000 00000000

Reģistrācijas Nr.LV90000294774

Valsts kase

Bankas kods: TRELLV22

Konta Nr. XX00XXXX0000000000000


Komandieris

_________________ z.v

/ /


Reģistrācijas Nr.

Juridiskā adrese:

Biroja adrese:

Bankas informācija:


Kods:

Konta Nr.



_________________ z.v

/ /


Pielikums Nr.1

Pie 2014.gada __._____________

Līguma Nr.__________________


TEHNISKĀ SPECIFIKĀCIJA

Pielikums Nr.2

Pie 2014.gada __._____________

Līguma Nr.__________________


TEHNISKAIS/FINANŠU PIEDĀVĀJUMS


Pielikums Nr.3

Pie 2014.gada __._____________

Līguma Nr.__________________


KALENDĀRAIS PLĀNS


Pielikums Nr.4

Pie 2014.gada __._____________

Līguma Nr.__________________


Priekšapmaksas bankas garantija maksājumam (beznosacījumu)


Kam: Valsts aizsardzības militāro objektu un iepirkumu centram

Adrese: Xxxxxxxxxx xxxx 00, Xxxx, XX-0000



Saskaņā ar atklātā konkursā VAMOIC 2014/171 “Tehniskā risinājuma prototipa izstrāde AnNa (VILDA) projekta ietvaros” nolikuma 14.3.punktu, /Izpildītāja nosaukums un adrese/ (turpmāk saukts „IZPILDĪTĀJS”) jāiesniedz Nacionālo bruņoto spēku (NBS) Nodrošinājuma pavēlniecības (NP) 1.reģionālais nodrošinājuma centram (1.RNC)(turpmāk saukts „PASŪTĪTĀJS”) Bankas garantiju, lai garantētu IZPILDĪTĀJA saistību pienācīgu un godprātīgu izpildi saskaņā ar iepriekš minētā Līguma noteikumiem par summu /Garantijas summa/ /summa vārdiem/.


Mēs, /Banka /, pēc PASŪTĪTĀJA norādījumiem, bez nosacījumiem un neatsaucami piekrītam kā pats parādnieks un ne tikai kā galvinieks, veikt maksājumu PASŪTĪTĀJAM pēc tā pirmā pieprasījuma bez jebkādām tiesībām celt no mūsu puses iebildumus, un bez tiesības prasīt vispirms celt prasību pret IZPILDĪTĀJU, par summu, kas nepārsniedz /Garantijas summa/ /summa vārdiem/.


Mēs arī piekrītam, ka nekādas izmaiņas vai papildinājumi, vai jebkādi citi grozījumi Līguma noteikumos vai jebkurā no darbiem, kas veicami saskaņā ar Līguma noteikumiem, vai jebkurā no Līguma dokumentiem, kādi var tikt noslēgti starp PASŪTĪTĀJU un IZPILDĪTĀJU, nekādā veidā neatbrīvos mūs no šajā Garantijā paredzētajām mūsu saistībām. Mēs ar šo atsakāmies no tiesības prasīt paziņot mums par jebkādu šādu izmaiņu, papildinājumu vai grozījumu veikšanu.


Mūsu garantija stājās spēkā, ar tās izsniegšanas dienu un garantija būs spēkā līdz PASŪTĪTĀJS ir saņēmis pilnu garantijas summas atmaksu vai darbu izpildi priekšapmaksas apmērā.




Paraksts un zīmogs______________________________________________


Bankas nosaukums:


______________________________________________________________


Adrese:________________________________________________________


Datums____________________








šis punkts attiecas arī: uz personālsabiedrības biedru, ja pretendents ir personālsabiedrība; uz visiem piegādātāju apvienības biedriem, ja pretendents ir piegādātāju apvienība.

 šis punkts attiecas arī: uz personālsabiedrības biedru, ja pretendents ir personālsabiedrība; uz pretendenta norādīto apakšuzņēmēju, kura sniedzamo pakalpojumu vērtība ir vismaz 20% no kopējās publiska pakalpojumu līguma vērtības; uz pretendenta norādīto personu, uz kuras iespējām pretendents balstās, lai apliecinātu, ka tā kvalifikācija atbilst paziņojumā par līgumu vai iepirkuma procedūras dokumentos noteiktajām prasībām; uz visiem piegādātāju apvienības biedriem, ja pretendents ir piegādātāju apvienība.

1


Document Metadata

Filed: November 3rd, 2014