Käskkiri

1/1 VASTAVUSTINGIMUSED Viitenumber: 227116 Hankija: Maanteeamet (70001490) Hange: Maanteeameti teede ja ITS valdkonna infosüsteemide jätkuarendused OSA 1: MAANTEEAMETI ERINEVATE INFOSÜSTEEMIDE ANALÜÜSI, PROGRAMMEERIMIS- JA HOOLDUSTEENUS, SH LIIKLUSREGISTER JA E-TEENINDUS KINNITUSED PAKKUMUSE KOHTA Küsimused ettevõtjale: 1. Pakkuja kinnitab, et: 1) ta nõustub kõikide riigihanke alusdokumentides esitatud tingimuste ülevõtmisega; 2) ta esitab pakkumuse üksnes kõigi nende asjaolude kohta, mille kohta hankija on soovinud võistlevaid pakkumusi; 3) pakkumus vastab kõigile sõlmitud raam- ja hankelepingu tingimustele ning pakkumuses pakutud ühiku hinnad ei ületa raamlepingus fikseeritud ühiku hindasid. (Raadionupp valikutega "Jah/Ei") ÄRISALADUS Pakkuja märgib pakkumuses, milline teave on pakkuja ärisaladus ning põhjendab teabe määramist ärisaladuseks. Pakkuja märgib pakkumuses, milline teave on pakkuja ärisaladus ning põhjendab teabe ärisaladuseks määramist. Pakkuja ei või ärisaladusena märkida: 1) pakkumuse maksumust ega osamaksumusi; 2) teenuste hankelepingute puhul lisaks punktis 1 nimetatule muid pakkumuste hindamise kriteeriumidele vastavaid pakkumust iseloomustavaid numbrilisi näitajaid; 3) asjade ja ehitustööde hankelepingute puhul lisaks käesoleva lõike punktis 1 nimetatule muid pakkumuste hindamise kriteeriumidele vastavaid pakkumust iseloomustavaid näitajaid (RHS § 111 lg 5). Küsimused ettevõtjale: 1. Kirjeldage lühidalt pakkumuses sisalduvat ärisaladust ja lisage selle määramise põhjendus või märkige, et pakkumus ei sisalda ärisaladust. (Suur sisestusala (max pikkus 4000 tähemärki)) Koostatud 07.09.2020 10:21:33 https://riigihanked.riik.ee/rhr-web/#/procurement/2331172/general-info  HANKE LEPING nr I I osa Maanteeamet , registrikoodiga 70 001490, asukohaga Teelise 4 , 10916 Tallinn (edaspidi Tellija ), mida esindab Maanteeameti peadirektor/ mida volituse alusel esindab Maanteeameti ja …………… , registrikoodiga ……………. , asukohaga (edaspidi Täitja ), mida esindab juhatuse liige /mida volituse al usel esindab , Tellija ja Täitja (edaspidi koos Pooled või eraldi Pool ), sõlmisid käesoleva infosüsteemide ja seonduvate tarkvaraliste moodulite analüüsi -, hooldus - ja programmeerimisteenusega seotud ülesannete teostamine (edaspidi Leping ) alljärgnevas: Lepingu ese Lepingu esemeks on Maanteeameti teede ja ITS valdkonna infosüsteemide jätkuarendused (edaspidi Töö), mida Täitja kohustub tegema vastavalt Lepingus ja Lepingu Lisades toodud tingimustele. Tööna käsitletakse kõiki töid ja toiminguid, sh Lepingus nimetamata töid ja toiminguid, mis on vajalikud Lepingus ettenähtud tulemuse saavutamiseks, samuti Töö vastuvõtmiseks vajaliku dokumentatsiooni vormistamisega seotud toiminguid. Lepingu üldtingimused Lepingul on selle sõlmimise hetkel järgmised lisad: Lisa 1 – Tööde üleandmis - ja vastuvõtmisakti vorm; Lisa 2 – Täitja hinnapakkumus; Lisa 3 – Tehniline kirjeldus; Lisa 4- Nõuded infosüsteemide dokumentatsioonile ; Lisa 5– Mittefunktsionaalsed nõuded . Pooled juhinduvad Lepingu täitmisel lisaks Lepingule ja selle lisadele ka Eesti Vabariigis kehtivatest õigusaktidest, eeskirjadest, standarditest ning vajadusel muudest vastava valdkonna tehnilistest dokumentidest. Leping on sõlmitud riigihanke „Tarkvara analüüsi, programmeerimis- ja hooldusteenus“ (viitenumber 160084 ) I I osa kohta sõlmitud raamlepingu „ Tellijale kuuluvate infosüsteemide ja seonduvate tarkvaraliste moodulite analüüsi-, hooldus- ja programmeerimisteenusega seotud ülesannete teostamine “ (edaspidi Raamleping) alusel teostatud minikonkursi „ Maanteeameti teede ja ITS valdkonna infosüsteemide jätkuarendused“ tulemusel. Kui Lepingus ei ole sätestatud teisiti, siis viiteid kindlale punktile, alapunktile või lisale tõlgendatakse viidetena Lepingu vastavale punktile, alapunktile või lisale. Lepingus on kasutatud pealkirju vaid viitamise lihtsustamise huvides ning neid ei arvestata Lepingu sätete defineerimisel, tõlgendamisel või piiramisel. Lepingus, kus kontekst seda nõuab, võivad ainsuses olevad sõnad tähendada mitmust ja vastupidi. Lepingu täitmise keel on eesti keel. Tähtajad ja T öö üleandmine Töö teostamist alustatakse koheselt peale Lepingu allkirjastamist Poolte poolt. Töö teostamise tähtaeg Tehnilises kirjelduses toodule 18 kuu jooksul alates Lepingu jõustumisest v õi kuni on täitnud arendusmaht 4 0 0 000 eurot, millele lisandub käibemaks 20%. Tellijal ei ole kohustust tellida arendusi kogu piirmahu ulatuses. Tasutakse tegelikult kulunud rollipõhise töötunni maksumuse alusel. Täitja esitab Tellijale iga kalendrikuu jooksul valminud Töö hiljemalt järgneva kuu 5. tööpäevaks, koos Lisa 1 kohaselt vormistatud dokumentatsiooniga . Sellist esitamist ei loeta Töö lõplikuks üleandmiseks. Tellija peab esitatud Töö üle vaatama ja teostama testimise 14 päeva jooksul peale Töö esitamist Täitja poolt. Juhul, kui Tellija poolt läbiviidava testperioodi vältel esineb Töös puudusi, annab Tellija selles kirjalikult Täitja le teada testperioodi lõpus . Täitja kohustub puudused likvideerima 14 päeva jooksul alates Tellija kirjaliku teatise saamisest . Täitja kohustub teostama Tellija (või kolmanda osapoole) vastuvõtu testimisel ilmnenud v ead/puudused parandam a oma l kulu l . Juhul, kui üks P ool tähtaegasid ei järgi, on teisel poolel õigus nõuda oma kohustust e täitmise tähtaegade proportsionaalset edasilükkamist; Töö lõplikul üleandmisel peale Tellja poolset testperioodi ning Täitja poolt puuduste kõrvaldamist , esitab Täitja Tellijale Töö üleandmis- ja vastuvõtmisakti koos Töö kohta koostatud dokumentatsiooniga . Juhul, kui Töö vastuvõtmisel on Tellijal jätkuvalt pretensioone Töö kvaliteedi ja/või Lepingule vastavuse osas, ei allkirjasta Tellija kontaktisik üleandmis- ja vastuvõtmisakti ning edastab Täitja le kirjalikult Töös ilmnenud vead ning puudused. Täitja kohustub vead ning puudused likvideerima 7 kalendripäeva jooksul alates Tellija poolt kirjaliku teate saamisest ja esitama parandatud Töö Tellijale. Töö loetakse vastu võetuks üleandmis-vastuvõtmis akti allkirjastamise hetkest, kuid mitte hiljem kui tulemid on toodangukeskkonnas kasutusele võetud. Juhul, kui T öö võetakse T öö tulemis esinevate vigade tõttu toodangus kasutusele osaliselt, siis lepitakse kokku Töö üleandmis- ja vastuvõtmisakti s, millises osas on Töö vastu võetud ning kuuluvad tasumisele ning millised on vaegtööd ja nende kõrvaldamise tähtajad. Poolte õigused ja kohustused Poolte üldised õigused ja kohustused on enamuses sätestatud Raamlepingus. Tellijal on õigus : igal ajal teha järelpärimisi Tööde tegemise hetke olukorra kohta ning kontrollida Tööde tegemise käiku; pöörduda kolmandate isikute poole sõltumatu eksperthinnangu saamiseks Tööde kvaliteedi kohta ; seada Täitja le tähtaegu parenduste läbiviimiseks; kasutada õiguskaitsevahendeid (sh öelda Leping üles), samuti nõuda Lepingus sätestatud juhtudel leppetrahvi, kui Täitja ei pea kinni Lepingus, selle lisades või muudes Lepingu juurde kuuluvates dokumentid es sätestatud tähtaegadest, kva liteedinõuetest, maksumusest, samuti kui Täitja ei täida või täidab mittevastavalt muid endale Lepinguga võetud kohustusi . Tellijal on kohustus: tasuda Täitja le Töö eest vastavalt Lepingule; tasuda viivist vastavalt Lepingu le; anda võimalus kasutada töökoosolekuteks Maanteeameti ruume Maanteeameti tööaja piires. Täitja l on õigus: saada Tellijalt Töö tegemiseks vajalikku informatsiooni ja juhiseid; saada Töö eest Lepingus kokkulepitud tasu. Täitja l on kohustus: teha Töö vastavalt Lepingule; tagada Töö tegemisel vajaliku kvalifikatsiooniga tööjõu kasutamine; vastutada selle eest, et Töö oleks tehtud korrektselt ja kvaliteetselt; anda oma projektijuhi kaudu ( kes on nimetatud Lepingu punktis 9.1 kui Täitja kontaktisik ) Tellija projektijuhile (kes on nimetatud Lepingu punktis 9.2 kui Tellija kontaktisik) regulaarset ülevaadet Töö teostamise käigu st iganädalastel töökoosolekutel . Töökoosolekute toimumise ajast teavitab Tellija projektijuht Täitja projektijuhti vähemalt kaks tööpäeva enne koosoleku toimumist . Kui Täitja peab vajalikuks kaasata töökoosolekutele analüütikut, testijat või arendajat, siis nimetatud isikute koosolekul viibimise tundide kulu Töö arvestus es ei käsitleta , need kulu d kannab Täitja . Kui Tellija peab vajalikuks kaasata iganädalastele töö koosolekutele lisaks Täitja projektijuhile ka analüütikut, testijat või arendajat, siis lähtutakse töötundide maksumuse arvutamisel Lisas 2 selle isiku kohta esitatud töötunni maks umusest. korraldada töökoosolekute protokollimist; edastada igal töökoosolekul Tellija projektijuhile kirjalikult täp n e ülevaa d e Töö tegemiseks kulunud töötundide kohta isikute põhiselt moodulite lõikes. täita kõiki Tellija juures kehtivaid ja õigusaktidest tulenevaid andmekaitsealaseid ja andmete turvalisust puudutavaid eeskirju; informeerida viivitamatult Tellijat Töö tegemise käigus tekkinud probleemidest; tasuda leppetrahvi vastavalt Lepingule. Autoriõigused Autoriõiguste regulatsioon on sätestatud poolte vahel sõlmitud Raamlepingus. Tasumine Tellija kohustub kvaliteetse, tähtaegse ja Lepingu tingimustele vastava Töö eest Täitja le tasuma iga kuu lõikes. Täitja koostab arve P oolte poolt allkirjastatud üleandmise- ja vastuvõtmisakti alusel, vastavuses Töö tegemiseks kulunud tundide tegelikule mahule ja Lepingu lisas Lisas 2 esitatud isikute töötundide maksumustele . Tellija tasub Täitja le Poolte poolt allakirjutatud Tööde üleandmis- ja vastuvõtmisakt i alusel koostatud arve eest 20 kalendripäeva jooksul pärast arve saamist. Arve tuleb esitada 7 kalendripäeva jooksul, pärast Töö vastuvõtmist Tellija poolt , masintöödeldaval kujul, e-arvena, mis vastab Eesti Pangaliidu standardile ja Rahandusministri 11.04.2017 määrusele nr 24 „Masintöödeldava algdokumendi juhendi kehtestamine“ . Arve loetakse laekunuks selle Maanteeameti arvete halduskeskkonda laekumise kuupäevast . Mitteresidentidel tuleb pdf formaadis arve saata meiliaadressile [email protected] või edastada see e- arvena rahvusvahelise Peppol süsteemi kaudu . Arvele tuleb märkida kontaktisiku nimi ja Lepingu number ning tööde teostamise või teenuste osutamise periood. Poolte vastutus Täitja on kohustatud hüvitama Lepingu mittetäitmise või mittekohase täitmisega Tellijale tekitatud kahju ja Tellija poolt seoses Täitja poolse Lepingu rikkumisega tehtud kulutused. Muuhulgas vas t utab Täitja Töö käigus Täitja poolt infosüsteemi tekkinud tõrgete ja vigade eest, mis on põhjuslikus seoses Töö iseloomuga ning tekkinud Täitja tegevuse tagajärjel. Tellija vastutab Lepingu rikkumise eest ja on kohustatud Täitja le hüvitama Lepingu rikkumisega tekitatud kahju ning Täitja poolt Tellija poolse Lepingu rikkumisega seoses tehtud kulutused. Täitja l on õigus nõuda Tellijalt viivist tasumisega viivitamise korral 0,2 % tähtaegselt tasumata arve summast iga tasumise tähtpäeva ületanud päeva eest , kuid mitte rohkem kui 30% vastava arve summast. Tellijal on n õuda Täitja lt leppetrahvi iga Lepingu rikkumise korral kuni 8 00 0 eurot kokku mit te rohkem kui 24 000 eurot, kui Täitja on rikkunud oma lepingulisi kohustusi. Juhul kui Täitja rikub Lepingus sätestatud tähtaegu, on Tellijal õigus nõuda Täitjalt leppe trahvi 16 0 eurot maksumusest iga viivitatud päeva eest. Tähtaegade ületamise korral kohaldu b Lepingu punktis 7.4 sätestatud leppetrahvi piirmäär . Pooled on kokku leppinud, et Täitja kohustub hüvitama Lepingu täitmise käigus Täitja süül tekkinud kahju kolmandatele isikutele. Täitja kohustub oma kulul esindama Tellijat Lepingu alusel Täitja poolt täidetavate ülesannete või toimingutega seotud vaidlustes (sh kohtuvaidlustes) kolmandate isikutega ning kandma kõik sellega kaasnevad menetluskulud. Poolel on õigus esitada teisele Poolele nõue Lepingus või õigusaktides sätestatud aegumistähtaja jooksul. Garantii Täitja garanteerib tehtud Tööle garantii, mille kestvus on 1 aasta alates viimasest Tööde üleandmis- ja vastuvõtmisakti allkirjastamist Poolte poolt. Garantiiperioodi jooksul kohustub Täitja teostama ilmnenud vigade parandamise oma kuludega eeldusel, et Tellija ei ole teinud programmikoodi muudatusi. Garantiitööde le annab Täitja uue garantii 1 aastase kestvusega, garantiitöö teostamisest arvates. Garantii ei hõlma vigasid, mis on tingitud riistvara tõrgetest või tarkvara ebaõigest kasutamisest, välja arvatud juhul kui ebaõige kasutamine oli tingitud Täitja poolt üleantud Töö puuduste tõttu. Täitja on kohustatud reageerima Tellija informatsioonile Töö puuduste kohta hiljemalt 2 tööpäeva jooksul arvates Tellijalt vastava informatsiooni saam isest ja vead parandama 5 tööpäeva jooksul Tellijalt vastava informatsiooni saamisest. Kui Täitja ei suuda puudust mõistliku viivitusega kõrvaldada, võib Tellija korraldada vigade kõrvaldamise kolmanda isiku poolt Täitja kulul ja riisikol. Garantii katkeb koheselt kui Tellija või kolmas osapool teostab tarkvaras täiendusi ja/või muudatusi Täitja nõusolekuta. Garantii ei katke, kui tarnitud lähtekoodis tehakse muudatusi P oolte kokkuleppel ja Tellija suudab eristada lähtekoodis tehtavaid muudatusi . Poolte kont akt isikud Täitja kontaktisik: ………………. , tel: (+372) …………….. , e- post: … ……………….. ; ; Tellija kontaktisik : Maanteeameti infotehnoloogia osakonna projektijuht Raigo Püü , e-post: raigo.pyy @mnt.ee ja Maanteeameti infotehnoloogia osakonna projektijuht Tõnu Vahter , e-post : [email protected] ; Lepingu kehtivus Leping jõustub Tellija poolt allkirjastatud Lepingu esitamisel Täitjale . Tellija võib Lepingust taganeda, kui Täitja rikub oluliselt oma õigusaktidest või Lepingust tulenevaid kohustusi . Tellija võib Lepingu üles öelda võlaõigusseaduses ettenähtud korras. Täitja võib Lepingust taganeda , kui Tellija rikub oluliselt Lepingu tingimusi. Sellisel juhul on Tellija kohustatud Täitja le hüvitama Täitja poolt Lepingu täitmisel tehtud kulutused. Leping loetakse koheselt lõppenuks, kui: Täitja lõpeb; kuulutatakse välja Täitja pankrot. Teated Pooltevahelised Lepinguga seotud teated peavad olema esitatud kirjalikus vormis, välja arvatud juhtudel, kui sellised teated on informatsioonilise iseloomuga, mille edastamisel teisele Poolele ei ole õiguslikke tagajärgi. Informatsioonilist teadet võib edastada telefoni teel. Kirjalikud teated saadetakse Lepingu Pooltele e-posti teel digitaalselt allkirjastatuna või selle võimaluse puudumisel antakse Lepingu Pooltele üle allkirja vastu. Kui ühe Poole teade on teisele Poolele saadetud Lepingus märgitud e-posti aadressil loetakse see kättesaaduks järgmisel tööpäeval. Lepingu üks Pool on kohustatud kätte saadud ning vastust eeldavale teatele vastama kolme tööpäeva jooksul selle kättesaamisele järgnevast päevast lugedes, kui teates ei ole ette nähtud vastamiseks pikemat tähtaega. Muud tingimused Lepingut võib muuta Poolte kirjalikul kokkuleppel ja kooskõlas kehtivate õigusaktidega. Kirjalikult vormistamata Lepingu muudatused on tühised. Pooltel on õigus Lepingust tulenevaid ja sellega seotud nõudeid ja kohustusi kolmandatele isikutele üle anda ainult teise Poole eelneval nõusolekul, mis on Lepinguga samas vormis. Mittekohaselt üle antud nõuete ja kohustuste osas jääb teise Poole ees vastutavaks nõuded ja/või kohustused üle andnud Pool. Kõik Lepingu tõlgendamisest või täitmisest tulenevad vaidlused püütakse lahendada Lepingupoolte vaheliste läbirääkimiste teel. Kokkuleppe mittesaavutamisel lahendatakse vaidlus Harju Maakohtus vastavalt Eesti Vabariigis kehtivatele õigusaktidele. Kõigis küsimustes, mis ei ole reguleeritud Lepinguga , juhinduvad Pooled sõlmitud R aamlepingust ja Eesti Vabariigi vastavatest õigusaktidest. Leping allkirjastat akse Poolte poolt digitaalselt. Poolte allkirjad Tellija: Täitja : (allkirjastatud digitaalselt) (allkirjastatud digitaalselt) L isa 1 TÖÖDE ÜLEANDMIS- JA VASTUVÕTMISAKT Käesolevaga …………. annab üle ja Maanteeamet võtab vastu kooskõlas IT raamhanke „Tarkvara analüüsi, programmeerimis- ja hooldusteenus“ (viitenumber ) I I osa raames sõlmitud raaml epingu „ Tellijale kuuluvate infosüsteemide ja seonduvate tarkvaraliste moodulite analüüsi -, hooldus - ja programmeerimisteenusega seotud ülesannete teostamine “ ja Lepingu lisades toodud tingimustele: Rollipõhine teenus tundides/ Mooduli nimetus Analüütik Arendaja Testija Projektijuht Vastuvõtmise kuupäev: Tellija kontaktisik: Täitja kontaktisik: (Allkirjastatud digitaalselt) (Allkirjastatud digitaalselt) Lepingu lisa 3 Tehniline Kirjeldus „Maanteeameti teede ja ITS valdkonna infosüsteemide jätkuarendused “ Hangitav teenus L eping sõlmitakse Maanteeameti teede valdkonna erinevate infosüsteemide jätkuarendusteks kuni Raalepingu II osa piirmahu täitumiseni Arendustööde eesmärgiks on tagada infosüsteemide kohandamine lähtudes muutunud või täienenud vajadustest ja skoobis toodud arendusvajadustest . Arendustööde käigus kohustub lepingu partner tagama lepingu sõlmimis est 18 kuu jooksul või kuni Raamlepingu mahu täitumiseni . Tellijal (hankijal) ei ole kohustust Tellida Tööd maksimaalses eeldatavas mahus ning Tellija tasub vaid Tellitud Tööle reaalselt kulunud töötundide alusel. Täitja peab olema võimeline pakkuma järgnevaid teenuseid: Analüüsi teostamine: Ärianalüüs i ja detailanalüüsi läbiviimine. Disaini teostamine: Tarkvaralahenduse disain ( nii visuaalne kui ka süsteemne). Täienduse teostamine: Tarkvara lahenduste muutmine, sh koodi ja testide kirjutamine. Arenduse teostamine: Tarkvara lahenduse loomine, sh rakendustarkvara koodi, andmebaasi struktuuri täie ndamine ja testide kirjutamine. Konsulteerimine: Tellija spetsialistide nõustamine tarkvaraarenduse valdkonnas ja vajadusel osalemine kohtumistel Te llijaga ja Tellija partneritega. Tarkvara testimine: Loodud lahenduse testimine (k.a. koormustestid). Dokumentatsiooni koostamine ja täiendamine Arendustele vastava dokumentatsiooni kirjutamine/täiendamine (sh arvestades RIHA nõudeid ). Arendusmeeskond ja rollid Rakendatava meeskonna suurus ja täidetavad rollid lepitakse kokku vastavalt Tellija ( hankija ) vajadustele ja prioriteetidele tulenevalt tellitava teenuse konkreetsest sisust. Täitjal peab olema võimekus rakendada meeskond, mille täidetavad rollid ja kvalifikatsioon vastavad raamhankes loetletud nõuetele. Meeskond peab katma järgmised rollid: projektijuht , analüütik , programmeerija , testija . Täitja arendusmeeskond peab olema valmis kohanduma Tellija poolt määratud a rendusmeetodile, mis pannakse paika Tellija projektimeeskonna poolt Töö hankimisel. Analüüsi- ja arendustööde SKOOP Analüüsi- ja arendustööde skoop: Teeregistri andmete arhiivi ja ajalooliste seisude korrastamine, ETAK liidestuse parendamine ja optimeerimine; Kaitsevööndite kihi loomine Teeregistrisse ; Omandi nähtuse ja katastripiiride kaardikihi parendamine ; THK ja EPMS vahelise andmevahetuse automatiseerimine/parendamine ; TEET juurutusest tingitud arendusvajadused teistes teede (sh intelligentsed transpordisüsteemid ITS) valdkonna infosüsteemides Õigusaktidest ja tööprotsesside muudatustest tingitud arendusvajadused. Täpsed tööülesanded registreeritakse Tellija tööhaldus keskkonnas JIRA ning ajakava lepitakse Osapoolte vahel kokku iga arendustsükli planeerimise käigus Projekti elluviimist toetavad keskkonnad Tööülesannete halduskeskkond Tööülesannete halduskeskkonnaks on Maanteeameti arenduskeskkond Jira ja Täitja on kohustatud Jirat kasutama analüüsimisel ja arendamisel. Tellija arenduskeskkonnas Jira (Tempo Timesheets ) on loodud võimalus personaliseeritud tööajaarvestuseks, milles on Täitja kohustatud töötundide arvestust pidama. Täitja peab teostatud töötundide arvestust isikute põhiselt. Projekti dokumendihalduskeskkond Projekti dokumendihalduskeskkonnaks on Maanteeameti dokumendihalduskeskkond 365 SharePoint ja Confluence . Lähtekoodi r epositoorium Projekti lähtekoodi halduskeskkond repositoorium on Maanteeameti GitLab . Täitja on kohustatud kandma Töö tulemid repositooriumisse vastavalt Tellija juhistele. Rakenduse lähtekoodi ehitamise ja paigaldamise keskkond Jenkins . Täitja on kohustatud rakenduse lähtekoodi kompileerimiseks ja paigaldamiseks kasutama Maanteeameti rakenduse lähtekoodi ehitamise ja paigaldamise keskkonda Jenkins . Täitja on kohustatud kandma Töö tulemid keskkonda vastavalt Tellija juhistele. Arendus-, Test- ja Toodangukeskkonnad. Arendus-, Test- ja Toodangukeskkondade installeerimise teostab ning ligipääs ude haldamisega tegeleb Tellija, kui ei ole kokku lepitud teisiti. Lisad Nõuded infosüsteemide dokumentatsioonile Maanteeameti mittefunktsionaalsed nõuded (MFN) Maanteeameti mittefunktsionaalsed nõuded (MFN) Dokumendi ajalugu KUUPÄEV VERSIOON KIRJELDUS AUTOR 27 .03. 17 0.1 Dokumendi loomine Martin Õunap 28.03.17 0 . 1.1 Turvalisus , Nõuded lähtekoodile ja komponentidele … Martin Õunap 29.03.17 0.1.2 Karbitoode Martin Õunap 09.06.17 0.1.3 Partnerite sisendi kombineerimine Martin Õunap Sisukord TOC \o "1-3" \h \z \u Tellija jaoks loodav tarkvara PAGEREF _Toc484781353 \h 3 1. Üldised nõuded PAGEREF _Toc484781354 \h 3 1.1 Vastavus Õigusaktidele PAGEREF _Toc484781355 \h 3 1.2 Arhitektuur PAGEREF _Toc484781358 \h 3 2. Tehnoloogia profiil PAGEREF _Toc484781359 \h 4 2.1 Infrastruktuur PAGEREF _Toc484781360 \h 4 2.2 Võrguarhitektuur PAGEREF _Toc484781363 \h 5 2.3 Andmebaasiserverid PAGEREF _Toc484781366 \h 5 2.4 Veebiserver PAGEREF _Toc484781367 \h 6 2.5 Java tehnoloogia PAGEREF _Toc484781368 \h 6 2.6 PHP tehnoloogia PAGEREF _Toc484781369 \h 7 2.7 Alternatiivsed tehnoloogiad PAGEREF _Toc484781370 \h 7 3. Turvalisus PAGEREF _Toc484781371 \h 8 4. Nõuded lähtekoodile ja komponentidele PAGEREF _Toc484781372 \h 9 4.1 Materjalide üleandmine PAGEREF _Toc484781373 \h 9 4.2 Nõuded lähtekoodile PAGEREF _Toc484781374 \h 10 4.3 Nõuded andmebaasi ülesehitusele PAGEREF _Toc484781375 \h 10 4.4 Andmeformaadid PAGEREF _Toc484781376 \h 11 5. Versioonihaldus ja repositoorium PAGEREF _Toc484781377 \h 11 6. Koormusnäitajad ja jõudlus PAGEREF _Toc484781378 \h 12 7. Logimine ja audit PAGEREF _Toc484781379 \h 13 8. Monitooring PAGEREF _Toc484781380 \h 14 9. Konfiguratsioon PAGEREF _Toc484781381 \h 14 10. Kasutajaliides PAGEREF _Toc484781382 \h 15 11. Dokumentatsioon PAGEREF _Toc484781383 \h 17 12. Karbitoode PAGEREF _Toc484781384 \h 17 12.1 Karbitoote iseloomustus PAGEREF _Toc484781385 \h 17 12.2 Infrastruktuur PAGEREF _Toc484781386 \h 17 Tellija jaoks loodav tarkvara Tarkvara mis on loodud eraldi tellijale tellija soovide ja protsesside täitmiseks ning teostamiseks . Üldised nõuded Vastavus Õigusaktidele Loodava lahenduse väljatöötamisel peavad olema arvesse võetud „Avaliku teabe seaduses“ (RT I 2000, 92, 597. https://www.riigiteataja.ee/akt/114032011019?leiaKehtiv ) kehtestatud nõuded teabe avalikustamise ja juurdepääsu võimaldamise suhtes. Loodava lahenduse väljatöötamise ning juurutamise l peab arvestama „Riigi infosüsteemi koosvõime raamistikus“ (MKM 2011. https://www.mkm.ee/et/riigi-infosusteemi-koosvoime-raamistik ) kirjeldatud põhimõtetega ja täitma nõuded mis on väljendatud sõnadega: PEAB, NÕUTAV, TULEB. Masinloetaval kujul avaandmete publitseerimine peab olema realiseeritud ratsionaalselt ja kuluefektiivselt ning arvestades „Avaandmete rohelises raamatus“ (RISO 2013. https://opendata.riik.ee/roheline-raamat )sõnastatud põhimõtete ja nõuetega. Riigi infosüsteemi haldamise läbipaistvuse tagamiseks loodava lahenduse väljatöötamisel peab arvestama „Riigi infosüsteemi haldussüsteemi“ (RT I 2008, 12, 84. https://www.riigiteataja.ee/akt/12933746?leiaKehtiv ) nõuetega ja reeglitega andmekogude dokumenteerimise ja RIHA - s registreerimise suhtes. „Infosüsteemide turvameetmete süsteem“ (RT I 2007, 71, 440. https://www.riigiteataja.ee/akt/13125331?leiaKehtiv ) rakendatakse vastavalt kokkuleppele lähtuvaltfunktsionaalsetest nõuetest ja väljatöötatud lahenduse ülesehitusest. Riigi infosüsteemile turvalise juurdepääsu võimaldamine peab toimuma „Infosüsteemide andmevahetuskihi“ määruses ( https://www.riigiteataja.ee/akt/127092016004?leiaKehtiv ) sätestatud põhimõtete alusel. Isikuandmete töötlemine loodavas lahenduses peab toimuma vastavuses „Isikuandmete kaitse seaduses“ (RT I2007, 24, 127. https://www.riigiteataja.ee/akt/12909389?leiaKehtiv ) kehtestatud tingimuste ja kordadega. Arhitektuur Tarkvara lahendused peavad töötama. Tehnoloogilised otsused ja loodavate lahenduste ülesehitus peavad baseeruma eeldefineeritud funktsionaalsetel nõuetel ning toetama püstitatud eesmärkide täitmist. Funktsionaalsete ja mittefunktsionaalsete nõuete realiseerimisel on eelistatud platvormide, tehnoloogiate ja programmeerimiskeelte vähesus ning muude korduvkasutatavate komponentide rohkus , nende ühtlustamine ja koostöö. Lahenduste väljatöötamisel/juurutamisel peab arvestama valitud tehnoloogiliste platvormide ja komponentide rakendamise parimate praktikate ja tavadega tarkvara ülesehituse, lähtekoodi vormingu, dokumenteerimise, testimise ja muude aspektide osas. Lahendused peavad olema projekteeritud laiendatavana ja edasi arendatavana. Eelistatud on sõltumatu funktsionaalsete moodulitega infosüsteemi ülesehitus. Lahenduste ülesehituse mustrina on eelistatud kolmekihiline arhitektuur – peavad olema selgelt eristatavad vähemalt kolme kihi funktsioonid (esitlusloogika, äriloogika, andmehoidla). Loodavate lahenduste eelistatud platvorm on Oracle Java (endine Sun Java) ning antud tehnoloogial põhinevad arendusraamistikud ja osaliselt ka alternatiivsed programmeerimiskeeled. Kindlalt määratud funktsionaalsustega temaatiliste veebilehtede realiseerimiseks sobiv ad platvorm id on PHP või NodeJS . Teiste programmeerimiskeelte, keskkondade ning eriti interpreteeritavate programmeerimiskeelte kasutamine lahenduste realiseerimiseks peab olema põhjendatud ja kooskõlastatud tellijaga. Lahenduste lähtekood peab olema võimalik kompileerida standardsete kompilaatoritega. Lahendused peavad töötama infrastruktuuri tootjate poolt toetatud standardse konfiguratsiooniga serveri keskkonnas ning sobima kokku tellija olemasoleva infrastruktuuriga. Lahenduste ülesehitus peab vajadusel võimaldama ka mitme instantsi samaaegset käivitamist (arendus-, test-, töökeskkond jt) minimaalse vajaliku seadistamisega ilma andmete-, sessioonide ja muude konfliktideta. Tehnoloogia profiil All olevates paragrahvides on toodud Maanteeameti visioon ja eelistatud valik tehnoloogiatest, programmeerimiskeeltest, raamistikutest ja muudest komponentidest, mille arendamise ja haldamise kogemus on praegu organisatsioonil olemas, mis toetavad olemasolevat infrastruktuuri, on heade referentsidega, omavad selget potentsiaali ning on kindlad ja läbiproovitud vahendid. Maanteeameti Infotehnoloogia osakonna eesmärk on ühtlustada ja lihtsustada infotehnoloogiline infrastruktuur , selle arendus ja haldus. Standardiseeritud tehnoloogiline platvorm, vahendid ja oskusteave tagavad kuluefektiivset ressursside rakendamist ning leevendavad innovatsiooniga seotud riske. Infrastruktuur Operatsiooni süsteem Centos 7 või uuem AdctiveDirecory Microsoft ActiveDirecory 2008 SMTP Kasutusel on standardne SMTP teenus LDAP Kasutusel on standardne LDAP teenus Monitooring Kasutusel on Zabbix Versioonihaldus GitLab ( https://about.gitlab.com/community/ ) Maanteeameti tsentraalne versioonihaldus on GitLab . https://git.mnt.ee/ Loodava lahenduse materjalide (lähtekood, skriptid, abistavad failid jne.) varamuna on lubatud kasutada ainult Maanteeameti koodi varamut. Komponentide varamu Artifactory open Source ( https://www.jfrog.com/open-source/ ) https://git.mnt.ee/artifactory/ Artifactory Open Source toimib lüüsina avalike komponentide repositooriumite (nt., Maven Central ) ja loodava lahenduse vahel. Loodava lahenduse kompileerimise/pakendamise skriptid peavad kasutama Maanteeameti komponentide varamut. Alternatiivsete varamute kasutamine ei ole lubatud Integratsiooniserver Jenkins ( https://jenkins.io/ ) http://mnt-arendus-jenkins.mts.local Jenkins on vabavaraline vahend, mida Maanteeametis rakendatakse tarkvara kompileerimisega ja paigaldamisega seotud serveripoolsete protsesside automatiseerimiseks. Loodava väärtuse kompileerimine peab olema teostatud Jenkinsiga . Erandid on võimalikud kokkuleppel tellijaga. Projektihaldus, tööjaotsu ja ajarvestus Jira ( https://www.atlassian.com/software/jira ) https://jira.mkm.ee Maanteeametis on projekti halduseks, tööde jaotamiseks ja ajaarvestuseks kasutusel Jira . Teostatavast tööst , juurde arendusest, muudatusest peab olema jälg Jiras . Dokumendihaldus Microsoft SharePoint ( https://technet.microsoft.com/en-us/library/cc303422.aspx ) https://sp.mkm.ee Loodava lahenduse realiseerimise käigus tekkivad muudatused infrastruktuurses lahenduses ja paigaldamise skeemis peavad olema edastatud infrastruktuuriga tegelevale personaalile arvestatava ajavaruga. Kõik muudatused enne jõustumist/rakendamist peavad olema kooskõlastatud tellijaga. Võrguarhitektuur Andmebaasiserverid Valdkond Tehnoloogia Lisainfo Andmebaasi platvorm PostgreSQL 9. 6 https://www.postgresql.org/ Geoandmebaas PostGIS 2.2 http://postgis.net/ Andmebaasi klaster Vastavalt vajadusele Vastavalt andmemahule, kasutajate ja päringute arvule. Käideldavuse vajadusest Andmebaasi mu udatuste haldus LiquiBase LiquiBase rakendatakse Maanteeameti andmebaaside migratsiooni ja uuendamise tarbeks. Alternatiivsete vahendite kasutamine on lubatud eeldusel, et need integreeruvad ja on võimelised töötama olemasoleva infrastruktuuriga ning nende rakendamine on põhjendatud ja kooskõlastatud tellijaga Veebiserver Veebiserver Teholoogia Lisainfo Veebiserver Apache HTTP Server 2.4 või uuem Apache veebiserveri ülesanne on olla lüüs lõppkasutaja veebibrauseri ja rakendusserveri vahel ning vahendada ainult selleks ettenähtud sisu HTTP(s) protokolli kaudu. Apache veebiserveri toomine loodava lahenduse arhitektuuri teine perspektiiv on ka võimalus rakendada koormuse jaotust mitme rakendusserveri vahel, kui see osutub vajalikuks tulevikus näiteks, koormuse kasvu tõttu. Kasutajaliides HTML[5] Javascript CSS[3] Kasutajaliideste realiseerimiseks on võimalik kasutada spetsialiseeritud UI raamistike ja komponente (nt., Jquery *, Dojo Toolkit , jQWidgets jt), kui nende rakendamine on põhjendatud. Sama veebirakenduse realiseerimiseks kasutatavate erinevate UI raamistikute ja komponentide arv peab olema minimaalne. Kasutatavate Javascript komponentide töötamine erinevates veebibrauserites peab olema loodava lahenduse arendaja poolt tõestatud (sh automatiseeritud) testide abil. Veebikaardid OpenLayers ArcGIS API for JavaScript Leaflet JS http://openlayers.org/ Tegemist on avatud lähtekoodiga veebikaartide kuvamise komponendiga. https://developers.arcgis.com/en/javascript/ Tegemist on interaktiivsete veebikaartide kuvamise komponendiga, mis toetab erinevaid kaasaegseid veebibrausereid, s.h ka mobiilseid kliente, integreerub teiste Javascript raamistikutega (nt JQuery ) ning on võimeline visualiseerima erinevatest andmeallikatest pärinevaid andmeid. http://leafletjs.com/ Leafleti funktsionaalsus on kergesti laiendatav. ( http://leafletjs.com/reference.html ) Java tehnoloogia Valdkond Tehnoloogia Lisainfo Platvorm Java S E 8 http://www.oracle.com/technetwork/java/javase/overview/index.html Rakenduserver Wildfly http://www.wildfly.org/ Loodav väärtus peab olema sõltumatu rakenduserveri tarkvarast ja versioonist. Jättes Maanteeametile võimaluse vahetada välja rakendus serveri tarkvara. Esitluskihi raamistik Angular 4 https://angular.io/ Alternatiivsete raamistike kasutamine on lubatud eeldusel, et need integreeruvad ja on võimelised töötama olemasoleva infrastruktuuriga ning nende rakendamine on põhjendatud ja kooskõlastatud tellijaga. Taustkihi raamistik Spring Boot http://projects.spring.io/spring-boot/ Alternatiivsete raamistike kasutamine on lubatud eeldusel, et need integreeruvad ja on võimelised töötama olemasoleva infrastruktuuriga ning nende rakendamine on põhjendatud ja kooskõlastatud tellijaga. Teenuste avastamine, balansseerimine Spring Cloud http://projects.spring.io/spring-cloud/ Alternatiivsete vahendite kasutamine on lubatud eeldusel, et need integreeruvad ja on võimelised töötama olemasoleva infrastruktuuriga ning nende rakendamine on põhjendatud ja kooskõlastatud tellijaga. Logimine SLF4J Logback Log4j http://www.slf4j.org/ http://logback.qos.ch/ http://logging.apache.org/log4j/2.x/ Java-lähtekoodi nimeruumi juurkataloog peab olema “ ee.gov.mnt.projekti_nimi ”, mille alla tuleb lu u a arendatavatele tarkvara moodulitele vastavaid alamkatalooge PHP tehnoloogia Valdkond Tehnoloogia Lisainfo Platvorm PHP 7 või uuem http://php.net Vanemate PHP versioonide kasutamine on keelatud Raamistikud Drupal https://www.drupal.org/ Teistel PHP tehnoloogilistel platvormidel baseeruvatel arendusraamistike rakendamine peab olema põhjendatud ja kooskõlastatud tellijaga Alternatiivsed tehnoloogiad Loodava lahenduse realiseerimiseks on lubatud kasutada alternatiivseid vahendeid. Valikud ja otsused peavad olema kooskõlastatud tellijaga. Sobivus olemasoleva infrastruktuuriga Tehnoloogiline lahendus peab olem a suuteline koos toimima olemas- oleva tellija infrastruktuuriga. Tehnoloogiline platvorm ei tohi eeldada eriotstarbelist ja spetsiifilist infrastruktuuri komponentide (eriti tasuliste komponentide) olemasolu ega juurutamis t . Platvormi tehnoloogilised omadused Tehnoloogiline platvorm peab olema avatud, vabavaraline ning ilma igasuguste kaasnevate kohustuslike tasudeta. Valitud Java-põhised raamistikud ja korduvkasutatavad komponendid peavad järgima vastavaid JSR (Java Specification Request ) spetsifikatsioone ja nõudeid. Valitud tehnoloogiline platvorm peab olema laiendatav ja arendatav; sellel peab olema tugiorganisatsioon (ametlik arendaja, kasutajate/arendajate kogukond) ja perspektiivne edasiarendamise plaan. Kompetentsi olemasolu ja kättesaadavus tööjõuturul Valitud platvormi ja/või raamistiku arendamise ja toetamise kompetents ja kogemus peab olemas olema vähemalt kolmel konkureerival IT arendusettevõttel Eestis (pakkuja poolt tõestatav fakt). Valitud platvormi ja/või raamistiku arendamist ja toetamist peavad omama vähemalt 15 spetsialisti üle Eesti (pakkuja poolt tõestatav fakt). Valitud platvormi ja/või raamistiku arendamise ja toetamise kohta peavad olema avalikuks kasutamiseks tasuta kättesaadavad elektroonilisel kujul õppevahendid, arendamise/kasutamise juhendid ja muud vajalikud materjalid. Kulud K äesolevast dokumendist puuduvate alternatiivsete tehnoloogiate, vahendite ja metoodikate rakendamisega ning juurutamisega seotud kulud (sh tellija personali väljaõpe, litsentside ja tugiteenuste hankimine ja ostmine, testimine ja muud tegevused) peavad olema kaetud täitja poolt. Turvalisus Loodavate lahenduste kanalid ja teenused (veebilehed, portaalid, andmeteenused jt) peavad olema projekti raames testitud vastu „OWASP Top Ten“ (OWASP 2013. https://www.owasp.org/index.php/Top_10_2013-Top_10 ) turvariskide nimekirja. Turvatestide läbiviimisel peab rakendama OWASP ASVS metoodikat (OWASP Application Security Verification Standard 2014. https://www.owasp.org/index.php/ASVS ). Turvatestimise tellimise korraldab tellija ja organiseerib tulemuse lahenduse loojale. Turvatestide käigus tuvastatud turvalisusega seotud probleemide ja vigade lahendamise eest vastutab loodava lahenduse tarnija nii vastava arendusprojekti/tegevuse kui ka garantiiperioodi ajal. Sanktsioneerimata juurdepääs andmetele, nende tekitamine, muutmine ja kustutamine peavad olema välistatud tarkvaralahenduse kogu elutsükli vältel. Sisestatud ja/või edastatud andmete lõplik kontroll, valideerimine ning vastavate otsuste tegemine edasiste operatsioonide käivitamise suhtes (andmete salvestamine, uuendamine vm) peavad toimuma kontrollitud keskkonnas serveri poolel. Loodavates lahendustes peavad olema lõpp-kasutajate rollide tasemele selgelt defineeritud andmete juurdepääsu erinevad tasemed (vaatamine, tekitamine, muutmine, kustutamine, valideerimine jne). Olukorras, kui sama füüsiline isik peab saama kasutada infosüsteeme erinevas rollis, sisse logimisel süsteemi peab lõppkasutajal olema võimalus valida, mis õigustes (mis rolliga) soovitakse infosüsteemi kasutada . Samuti peab olema võimalik rollivahetus ilma välja logimata. Lõppkasutajate ja infosüsteemide autentimiseks on lubatud rakendada infrastruktuuril põhinevaid mehhanisme – Kerberos , LDAP, ID-kaart , Mobiil-ID. Vastavalt EUROOPA PARLAMENDI JA NÕUKOGU MÄÄRUS (EL) nr 910/2014 e- identimise ja e-tehingute jaoks vajalike usaldusteenuste kohta siseturul http://eur-lex.europa.eu/legal-content/ET/TXT/?uri=OJ%3AJOL_2014_257_R_0002 Kasutades lahenduses lõppkasutaja rollivalikuteks asutuse keskset lahendust, tuleb arvestada, et grupid sisaldavad gruppe nn. „Nested Groups “. Veebiserveris toimiva autentimise protsessi tulemusena saadud lõppkasutaja identifikaator(id) tuleb rakendusserverisse edastamiseks lisada HTTPS päisse. Kõiki lõppkasutajate ja infosüsteemide autentimist/autoriseerimist puudutavaid andmeid peab edastama kasutades turvalisi andmekanaleid ja protokolle (SSL, TLS, Kerberos jt). Lõppkasutajate ja infosüsteemide autentimist/autoriseerimist puudutavaid andmeid (kasutajanimed, paroolid jt) ei tohi hoida veebibrauseri küpsiste failis ega edastada lahtiselt veebibrauseri ja serveri vahel (GET-päringu parameetrina vm). Lõppkasutajate ja infosüsteemide autentimiseks vajalikud paroolid ja/või allkirjad peavad olema enne andmebaasi, faili või teisele meediale salvestamist kaitstud ühesuunalise räsialgoritmiga (SHA256 või turvalisem). Lõppkasutajatele peab olema tagatud võimalus jooksva sessiooni lõpetamiseks ( logout ) selleks ettenähtud kasutajaliides elementide abil. Loodavas lahenduses peab olema võimalik defineerida maksimaalset lõppkasutaja sessiooni kestvust. Nõuded lähtekoodile ja komponentidele Materjalide üleandmine Loodavate lahenduste lähtekoodi olulisemad elemendid peavad olema kaetud automatiseeritud komponenditestidega. Kriitilisemate komponentidega peavad kaasnema käivitatavad koormustestide failid, testandmed ja muud vajalikud materjalid. Testandmeid peab olema võimalik eristada ja peale testide läbiviimist kustutada. Kõik loodavate lahenduste käivitamiseks, jooksutamiseks ja haldamiseks vajalikud komponendid ja vahendid peavad olema antud tellijale üle. Kasutatava kommertstarkvara komponentide (operatsioonisüsteemid, serveritarkvara, teegid, draiverid, lõppkasutaja töövahendid jt) litsentsid peavad olema antud loodava lahenduse tellijale üle mahus, mis võimaldab loodavate lahenduste käivitamist ja legaalset kasutamist vastavalt defineeritud kokkulepitud funktsionaalsetele ja mittefunktsionaalsetele nõuetele. Olulist rolli antud teema juures mängivad jõudluse nõuded, kasutajate arv, andmemaht, integratsioonide arv, sessioonide ja päringute arv ja intensiivsus ja muud sarnased aspektid. Kasutatavate kommertstarkvara komponentide versioonid peavad olema testitud, töökindlad ja stabiilsed ning nendel peab olema kehtiv vähemalt 3-aastane turva- ja veaparanduste tugiteenus (lepinguline, community -põhine vmt ). Tarkvara komponentide (skriptid, stiilid, teegid, draiverid jmt) jooksev alla laadimine kolmandatest allikatest ( repositooriumid , hoidlad, portaalid, veebilehed jmt) on üldjuhul keelatud. Erandjuhud peavad olema alati põhjendatud ja kokkulepitud tellijaga. Võimalusel tuleb kasutada tellija komponentide varamu lahendust. Arendaja poolt kirjutatud koodi omandiõigus läheb lahenduse üleandmisel tellijale. Nõuded lähtekoodile Loodava lahendu se lähtekoodis kasutatavate klas side, meetodite, muutujate ja muude elementide nimede eelistatud keel on inglise keel. Lähtekoodi kommentaaride eelistatud keeled on i nglise keel. Lähtekoodi lõigud või muud loodava lahenduse komponendid, mida ei kasutata, mis ei osale kompileerimises või muul põhjusel ei ole [enam] infosüsteemi osa, peavad olema kustutatud ja/või arhiveeritud. Loodava lahenduse lähtekoodi kompileerimiseks ja kõikide vajalike moodulite pakendamiseks peavad olema loodud spetsialiseeritud vastavat infrastruktuuri toetavad automatiseerimise skriptid. Vaikimisi käivitatava kompileerimise/pakendamise skripti nimi peab olema „build.xml“ või „ build.gradle “ . Skript peab koodi repositooriumis alati paiknema vastava tarkvara mooduli juurkataloogis. Nõuded andmebaasi ülesehitusele Andmebaasi peab kasutama andmete hoidmiseks ja transaktsioonide käivitamiseks. Äriloogika toomine (eriti erilahenduste lähtekood) andmebaasi tasemele peab olema põhjendatud erand ja kokkuleppel tellijaga . Andmebaasi väljade ja tabelite nimede eelistatud keeleks on inglise keel. Loodava lahenduse kõik peamised andmeobjektid peavad paigutatud ühte andmebaasi skeemi. Lahenduste töö ei tohi eeldada süsteemsete õiguste olemasolu andmebaasis rakenduste/protsesside jaoks. Vajalikud objektide ja/või operatsioonide teostamise õigused peavad olema igale andmebaasi skeemile eraldi. Erinevate tarkvara moodulite konfiguratsiooniandmete hoidmiseks on andmebaasi lubatud luua eraldi andmebaasi skeeme/kasutajaid. Andmebaasi ning selles hoitavate andmete ja kõikide käivitatavate skriptide kodeering peab olema UTF- 8. Integreeritavate infosüsteemide jaoks ei tohi kasutada andmebaasi võimalusi (eraldi kasutaja/skeem). Kõikide andmebaasis olevate andmeridade kohta peab olema vajadusel võimalik salvestada ja hoida kirje loomise aega, viimase uuendamise aega ja kasutaja tunnust. Failide sisu hoidmine andmebaasis peab olema välistatud. Eelistatud on lahendused, mille puhul andmebaasis hoitakse viited failidele ning failide sisu hoidmine on realiseeritud väljaspool andmebaasi. Aeg peab üldjuhul olema (kui täpsemalt pole nõutud) sekundi täpsusega – peab kasutama TIMESTAMP WITH TIME ZONE- andmetüüpe. Igal tabelil andmebaasis peab olema oma primaarvõti ( primary key ) – see peab olema numbrijadal ( sequence ) põhinev surrogaatvõti, mille andmevälja nime formaat peab olema „UID_<tabeli nimi>“. Äriliste primaarvõtmete rakendamine väärtuste kombinatsioonide unikaalsuse tagamiseks on keelatud (peab kasutama teisi kättesaadavaid andmebaasimootori alternatiive). Andmeridade füüsilise kustutamise asemel peab üldjuhul (kui teisiti pole nõutud) olema kasutatud nn loogiline kustutamine, mille puhul kirjele omistatakse „loogilise kustutamise“ lipik. Väli peab üldjuhul olema CHAR-tüüpi andmeväli nimega „IS_DELETED“ (Y/N[ULL]). Võõrvõtmete ( foreign key ) loomine andmebaasi skeemide vahel on keelatud. Infosüsteemi jaoks loodud andmebaasi konto tohib opereerida vaid ühe skeemi piires. Klassifikaatorite kasutamise puhul igale üksikule väärtusele peab olema võimalik määratleda eraldi oma kehtivusperiood TIMESTAMP WITH TIME ZONE mis võimaldab sekundi täpsusega kehtivuse määramist. Kehtetuks määratud klassifikaatorite väärtused peavad jääma andmebaasi alles. Andmemudel peab võimaldama vajadusel ka hierarhiliste klassifikaatorite kirjeldamist. Klassifikaatorite väärtustele (koodidele) peab olema võimalik defineerida vastavat tekstilist osa mitmes keeles. Klassifikaatorite koodidele vastavad tõlked teistesse keeltesse peab hoidma andmebaasis. Andmeformaadid Loodavas lahenduses toetatud failide formaadid peavad olema järgnevas nimekirjas: Office Open XML (ECMA-376, ISO/IEC 29500:2008), OpenDocument (ISO/IEC 26300:2006/ Amd 1:2012), Comma-Separated Values väljaeraldajaga semikoolon (;) (kodeeringud: CP 1257, UTF-8/16, Unicode), ESRI shapefile , GeoJSON , JSON, GML, XML, kõigis tekstilistes ( inimloetavates ) formaatides on koma eraldajaks koma (,). Loodav lahendus peab olema võimeline genereerim a dokumente PDF formaadis (ISO 32000-1:2008). Versioonihaldus ja repositoorium Repositooriumisse laetavad materjalid (lähtekood, skriptid, abistavad failid jm) peavad olema korrektsed ja töötavad, sh lähtekood peab olema kompileeritav. Repositooriumisse laetavate muudatustega peab alati kaasnema sisuline kommentaar, mis peab kirjeldama muudatuse sisu ning sisaldama ka viiteid realiseeritud tööle (nt., jira taski number). Igale loodava lahenduse tarkvaramooduli jaoks peab olema loodud eraldi alamkataloog sõltuvalt tarkvara ülesehitusest ning kogu lahenduse jaotusest komponentideks. Komponentide põhiste kataloogide nimed peavad olema intuitiivsed ning tohivad sisaldada inglisekeelseid tähte ("A..Z" ja " a..z ") ja numbreid ("0..9") ning eraldajana on lubatud kasutada sidekriipsu ("-") ja alakriipsu ("_") Lähtekoodi ja muude materjalide viimane pädev versioon peab olema koodi repositooriumi vastavas harus „ master “ ja olema „ tag “- itud versiooni nr. Lähtekood ja muud materjalid peavad olema paigutatud repositooriumis omaette vastavatesse alamkataloogidesse: „ config “ – konfiguratsioonifailide (arendusraamistiku konfiguratsioon, rakendusserveri konfiguratsioon vm) hoidmiseks ettenähtud kataloog; „ database “ – andmebaasi skriptide jaoks tuleb antud kataloogi luua alamkatalooge, mis vastaks andmebaasiserveris olevate skeemidele/kasutajatele; „ src “ – lähtekoodi juurkataloog, mille alamkataloogide struktuur peab järgima vastava tehnoloogilise platvormi parimaid praktikaid ja soovitusi; „etc“ – graafikafailide, skriptide, stiilide ja muude vajalikke failide hoidmise kataloog; „test“ – testidega (sh koormustestidega) seotud materjalide hoidmiseks ettenähtud kataloog. Muud alamkataloogid vastavalt põhjendatud ja ratsionaalsele vajadusele. Igapäevane töö lähtekoodiga peab üldjuhul toimuma muus harus kui „ master “. Täiendavate/abistavate harude loomine koodi repositooriumisse ( branching ), nende kasutamine arendustöödeks ja tarkvara eriversioonide liitmine ( merge ) harude vahel on lubatud ja soovituslik . Täien davate/abistavate harude nimedes on lubatud kasutada inglisekeelseid tähte ("A..Z" ja " a..z ") ja numbreid ("0..9") ning eraldajatena on lubatud kasutada punkti ("."). Soovitatav täiendava/abistava haru nime formaadis on mõistlik kasutada viidet haru otstarbele, näiteks „feature_ moodul _JIRA-1234“ Loodava lahenduse igal moodulil (Java tehnoloogia puhul moodul on war -, ear - või jar -arhiiv) peab olema võimalik tuvastada selle versioon ja versiooni loomise aeg minuti täpsusega. Koormusnäitajad ja jõudlus Loodavates lahendustes peavad olema ette nähtud võimalused serveri poolt lõppkasutajale tagastatavate andmeobjektide arvu piiramiseks ja/või mahukate andmekomplektide lehtede kaupa serveerimiseks ( pagination ). Parameetrid peavad olema konfigureeritavad ning uued piirangud peavad rakenduma ilma loodava lahenduse taas käivitamiseta. Staatiliste (sh cache’itud ) veebilehtede kuvamine peab üldjuh ul mahtuma 1 sekundi sisse. Lihtsamatele päringutele (nt., ühe konkreetse andmeobjekti otsing) peab loodav lahendus vastama maksimaalselt 3 sekundi jooksul. Keerulisemate päringute (nt., nimekirja filtreerimine) puhul on ajaline piirang 5 sekundit. Loodavate lahenduste jõudlusnäitajate ja stabiilse funktsioneerimise tagamiseks on mõistlik jooksutada koormusteste regulaarselt. Koormustestide regulaarsus tuleb leppida kokku tellijaga. Koormustestid peavad olema läbiviidud vähemalt 25% koormuse varuga. Loodava lahenduse jõudlusega seotud tõrked ja probleemid (nt., mälulekked, andmetabelite indekseerimine vm) peavad olema lahendatud ja likvideeritud enne vastava tarkvara versiooni kasutusele võtmist. Parandused ja täiendused peavad olema testitud enne tarkvara versiooni kasutusele võtmist. Logimine ja audit Loodavates lahendustes peab olema võimalik üheselt tuvastada konkreetset isikut või komponenti, kes või mis on tekitanud andmeid ning on neid hiljem muutnud (sh kustutanud). Kui infosüsteem sisaldab võimalust, kus kasutajal võib esineda mitu rolli , siis logikanne peab sisaldama kasutaja identifikaatori t ja rolli tunnust . Loodavad tarkvara lahendused pe avad olema võimelised salvestama tarkvara töötamisel tekkinud vigu ja probleeme logifailidesse. Logimine peab põhinema vastaval logimisraamistikul, sh logimine serveri konsooli. Debug -tüüpi teadete saatmine serveri konsooli väljaspool arenduskeskkonda on keelatud. Ühe päeva logikanded peavad olema salvestatud eraldi logifaili, varasemad logifailid peavad oma nimes sisaldama vastava kuupäeva tähise formaadis YYYY-MM-DD (näiteks 2015-01-03). Logifailides peavad olema alati fikseeritud veateated (tasemed ERROR, FATAL), mis vajavad administraatori sekkumist ja mis on seotud kas tarkvara endaga (koodivead, konfiguratsiooni probleemid, tõrked töös jmt), serverikeskkonnaga (operatiivmälu limiidi ületamine, konfiguratsiooni probleemid jmt) või väliste ressursside rakendamisega (failisüsteem, andmebaas, teenused jt). ERROR taseme logi kanded tuleb koguda eraldi logifaili. Lihtsustades probleemi märmkamist . Veaolukorra tekkimisel maha salvestatud logikanne peab sisaldama võimalikult palju informatsiooni (näiteks, vea tekkimise koht lähtekoodis, olulisemad mõjutavad seadistused ja muutujate väärtused, viimast operatsiooni teostanud lõppkasutaja arvuti IP-aadress, lõppkasutaja kasutajanimi jmt), mis võimaldaks ja lihtsustaks probleemi lokaliseerimist ja lahendamist. Käsurealt käivitatavad pikaajalised protsessid ( ühekordsed SQL päringud, Shell skriptid jmt) peavad salvestama informatsiooni enda töö tulemuste, häirete ja probleemide kohta logifailidesse rakendades selleks kättesaadavaid võimalusi. ( 2>&1 ) Tarkvara veaolukorra puhul tohib lõppkasutajatele kuvada ainult üldist informatiivset veateadet ilma tehnilise informatsioonita. Lisaks peab olema võimalus logikirjele viitavava informatsiooni lisamine vealehele sis se/välja lülitatav ilma komponendi taaskäivitamiseta . Logi kirje kuju mida kuvada ja lisada logisse „#ABCDFG123456789“ ( #[A-Z]{6}[0-9]{9} ) Monitooring Keskse monitooringu kaudu peavad olema kontrollitavad nii infrastruktuursed komponendid, kui ka üksikud tarkvarateenused ja nende sisemiste alamkomponentide staatus, vajalikke ressursside olemasolu ja kättesaadavus ning teised aspektid sõltuvalt valitud tarkvara lahenduse arhitektuurist. Kõikidel veebirakendustel peab olema endpoint , mis väljastab JSON formaadis staatusobjekti . Monitooringu JSON ressurss ( endpoint ) peab olema kättesaadav aadressil http[s]://< host+path >/< module >/ monitooring Kohustuslikud vastuse elemendid on: VERSION : väljastab tarkvaramooduli versiooni nõutud formaadis; STATUS : väljastab üldist mooduli staatust – TRUE/FALSE; TIMESTAMP : väljastab serveri hetkeaega – YYYY-MM-DD-HH24-MI-SS; Täiendavad kontrollelemendid ja vastavad muutujate nimed defineeritakse ja kooskõlastatakse tarkvara disaini tulemusena. Sarnaseid kontrollelemente on võimalik grupeerida – nt., "DATABASES", "SERVICES" jne. Kontrolltulemust sisaldava elemendi nime maksimaalne lubatud pikkus on 12 sümbolit. Kontrolltulemust sisaldava elemendi nimes on lubatud kasutada inglisekeelseid tähte ("A..Z" ja " a..z ") ja numbreid ("0..9") ning eraldajana on lubatud kasutada sidekriipsu ("-") ja alakriipsu ("_"). Juhul kui loodava lahenduse ühe mooduli kontrollehe genereerimiseks nõutud operatsioonide käivitamise kogukestvus ületab 2 sekundit peab olema [osaliselt] rakendatud asünkroonne kontrollide käivitamise mehhanism. JSON lihtsa vastuse näide: {"VERSION ":"1 .17.3.1","DB":"TRUE","CRYPTO _ SIGN":" TRUE" ," VALINE_TEENUS":"TRUE "} JSON laiendatud vastuse näide: {"VERSION":"1.17.3.1","STATUS":"TRUE","DB":"TRUE","SIGN_CERT":"TRUE","VALISED_TEENUSED":{"TEENUS_X":"TRUE","TEENUS_Y":"TRUE"},"X-TEE":{"TEENUS_X":"TRUE","TEENUS_Y":"TRUE"}} Konfiguratsioon Loodava tarkvara erineva te moodulite seadistus parameetrid peavad olema talletatud andmebaasi . Alternatiiv andmebaasis hoitavatele parameetritele on hoida parameetreid konfiguratsioonifailis näiteks andmebaasi ühenduse parameetrid. Kõik ühe tarkvara mooduli parameetrid peavad paiknema samas tabelis või samas konfiguratsioonifailis. Konfiguratsioonifailid peavad rakendusserveril paiknema eraldi paigaldatavast tarkvara moodulist. Java rakendus tes kasutatavad parameetrid peavad olemas asukohas: { user.home }/.TARKVARA /{CONF_FILE} Tarkvara uue versiooni installeerimine ei tohi automaatselt muuta, kustutada või kirjutada ümber eelnevalt konfiguratsioonifailis või –tabelis defineeritud parameetreid. Tarkvara lähtekood ei tohi sisaldada mitte ühtegi sisse kirjutatud dünaamilise iseloomuga konfiguratsiooni parameetri väärtust, mis on mõeldud kasutamiseks arendus-, test-, töö- või muu infosüsteemi instantsis. Juhul, kui tarkvara kompileerimine eeldab üksikute staatilise iseloomuga parameetrite sisse kirjutamist lähtekoodi, peavad lähtekoodi originaalversioonis sellised parameetrid esinema koodnimetusena (näiteks, < release_date >, < version > jne), mida kompileerimise skript peab asendama tegelike väärtustega konfiguratsioonifaili alusel vahetult enne lähtekoodi kompileerimist. Konfiguratsiooni parameetrite muutmine ei tohi nõuda lähtekoodi ümber kompileerimist ega tarkvara paigaldamist/taas käivitamist. Erandid peavad olema alati põhjendatud ja kooskõlastatud tellijaga . Loodavas lahenduses peab olema keelatud juurdepääs süsteemsele konfiguratsioonile tavakasutaja poolt. Loodava lahenduse komponendid peavad vaikimisi töötama serveriga samas ajatsoonis. Kui tellija pole märkinud teisiti. Loodava lahenduse konfiguratsioonis peab olema võimalik kasutada serveri keskkonnamuutujaid. Andmebaasis olevate parameetrite muutmine peab olema mõistlik. Esitluskihiga rakenduste puhul admin paneel, millele on piiratud ligipääs. Esitluskihiga rakenduse puhul teenus, mille kaudu on võimalik parameetreid, nende olekut pärida ning muuta. Teenusele ligipääs peab olema piiratud. Esmane teenuse kasutajanimi peab olema muudetav konfiguratsiooni failist. Esmase kasutaja parooli räsi peab olema muudetav konfiguratsiooni failist. Kasutajaliides Lõppkasutajate jaoks eelistatud lahendus on veebipõhine kasutajaliides, mis peab toetama erinevate operatsioonisüsteemide enimlevinud brausereid – tõestamiseks peavad olema läbiviidud vastavad teistid, nende tulemused peavad olema dokumenteeritud ja esitatud tellijale. Brauserite nimekiri: Microsoft Edge; Internet Explorer 11+; Google Chrome 56+; Mozilla Firefox 52+; Loodava lahenduse lõppkasutaja visuaalsed liidesed peavad olema arusaadava ja loogilise ülesehitusega, peavad olema kasutatud ühised visuaalsed elemendid. Kõik kasutajaliidese visuaalset disaini puudutavad otsused peavad olema kooskõlastatud tellijaga. Välisele kliendile l oodavate veebilehtede juurdepääsetavuse tagamiseks puuetega inimestele on soovituslik aluseks võt t a W3C poolt väljatöötatud juhised „ Web Content Accessibility Guidelines (WCAG) 2.0“ ( http://www.w3.org/TR/WCAG20/ ) . Loodava lahenduse kasutajaliidesed peavad üldjuhul sisaldama aktiivset navigeerimisrada komponenti ( breadcrumb navigation ). Loodava lahenduse kasutajaliides peab pakkuma abitekstide ( tooltip ) süsteemi spetsiifiliste terminite ja keerulisemate mõistete tähenduse selgitamiseks või muu lisainformatsiooni kuvamiseks lõppkasutajatele. Loodava lahenduse ekraanivormidele täiendavate andmete/informatsiooni saamiseks serverist peab üldjuhul lehe kogu sisu uuesti laadimise asemel rakendama lehe osalist laadimist võimaldavat lähenemist. Loodavas lahenduses peab olema rakendatud sisestatud andmete eelvalideerimine otse veebibrauseris enne nende serverisse edastamist. Hoiatused vigase sisestuse kohta peavad olema visuaalselt selgelt eristatavad ülejäänud sisestusvormi elementidest. Loodava lahenduse kasutajaliides peab olema varustatud viisaka välimusega veebilehtedega, mis visualiseeriks veebiserveri ja/või veebiraamistiku poolt tagastatavaid ja töödeldavaid vigu (nt., HTTP veakoodid 404, 403 jt). Loodava lahenduse kasutajaliidese kaudu peab olema võimalik kuvada lõppkasutajatele visuaalselt eristatavaid hoiatusi eelseisvate hooldustööde kohta (tarkvara versiooni uuendused, infrastruktuuri haldustegevused vms). Lõppkasutajal peab olema võimalus hoiatusi peita, sulgeda või muul viisil kaotada ekraanilt. Loodava lahenduse kasutajaliidesed peab sisaldama eraldi informatiivset komponenti (nt., iga lehe alumises servas), mis sisaldaks järgmist informatsiooni: Eeldefineeritud tarkvara nimi; Tarkvara versioon vastavalt kehtivatele nõuetele; Arenduspartnerite kontaktandmete ja/või logode paigutamine või muul viisil loodava lahenduse kasutajaliidese kaudu viitamine on keelatud. Spetsiifiliste pluginate (nt., Flash ) rakendamine peab olema välistatud, erandid peavad olema põhjendatud ja kooskõlastatud tellijaga. Sisestusvormidel [TAB]-klahvi vajutamine peab viima kursori andmete sisestusloogika suhtes järgmisele väljale. Sisestusvormidel [ENTER]-klahvi vajutamine peab käivitama andmete valideerimise ja salvestamise protsessi. Loodava lahenduse lõppkasutajale peab olema tagatud võimalus kasutada [BACKSPACE]-klahvi või vastavate navigatsiooni klahvide kombinatsiooni ([ALT]+[LEFT] ja [ALT]+RIGHT) eelmistele/järgmi stele lehtedele liikumiseks . Sisestusvormidel [BACKSPACE]-klahvi või vastavate navigatsiooni klahvide kombinatsiooni ([ALT]+[LEFT] ja [ALT]+RIGHT) kasutamisel peab küsima lõppkasutajalt kinnitust enne vormilt lahkumist. Loodava lahenduse lõppkasutaja graafiliste liideste vaikimisi keel peab olema eesti keel. Peab olema võimalik ka teiste keelte kasutamine ja vahetamine . Juhul, kui loodava lahenduse koosseisu kuulub arukas klienditarkvara, siis otseühendused andmebaasidega ja muude ressurssidega peavad olema välistatud. Erandjuhud peavad olema alati põhjendatud ja kooskõlastatud tellijaga. Dokumentatsioon Nõuded dokumentatsioonile on toodud välja dokumendis „ Nõuded_dokumentatsioonile.doc “. Nõuded võivad olla tänu projekti iseloomule erinevad ja on võimalik suurendada/vähendada nõudeid kokkuleppel tellijaga. Karbitoode Karbitoote iseloomustus Karbitoode (t oode ) , mis ei ole spetsi aalselt arendatud tellija jaoks, kuid täidab vajalikus osas tellija soove. Karbitoodete iseärasuse tõttu on täpsemad nõuded ja võimalused kokkulepitavad tellijaga. Toode peab arvestama tellija olemasoleva infrastruktuuri ja selle iseärasustega. Toote kasutajate haldus peab toetama asutuse keskset haldus süsteemi . Grupi päringute puhul tuleb arvestada võimalusega, et grupp sisaldab teisi gruppe nn. „ Nested Groups “ . Toote ja lõppkasutaja ühenduse vahel on nn. „Proxy“. Lõppkasutaja ja andmeb aas ei asu samas võrgusegmendis. Toote üleandmisel tuleb esitada selle haldamiseks, kasutamiseks ja paigaldamiseks kõik vajalikud dokumendid tellija poolt soovitud keeles. Eelistatud on eesti keel. Infrastruktuur Operatsiooni süsteem Centos 7 või uuem Microsoft Windows 2012 Andmebaas PostgreSQL 9.3 Microsoft SQL Server 2012 Microsoft SQL Server 2012 Express AdctiveDirecory Microsoft ActiveDirecory 2008 SMTP Kasutusel on standardne SMTP teenus LDAP Kasutusel on standardne LDAP teenus Monitooring Kasutusel on Zabbix Hankija nimi: MAANTEEAMET Raamlepingu alusel korraldatav m inikonkurss : „ Maanteeameti teede ja ITS valdkonna infosüsteemide jätkuarendused “ RIIGIHANKE ALUS DOKUMEN T Hankelepingu ese: Teenus ED 20 20 SISUKORD TOC \o "1-3" \h \z 1. Üldandmed PAGEREF _Toc5885357 \h 2 2. Minikonkursil osalemine PAGEREF _Toc5885358 \h 2 3. Tehniline kirjeldus PAGEREF _Toc5885359 \h 2 4. Hankelepingu tingimused ja täitmise tähtpäev PAGEREF _Toc5885360 \h 2 5. Pakkumuse koostamise keel PAGEREF _Toc5885361 \h 2 6. Pakkumuse maksumuse esitamise struktuur ja valuuta PAGEREF _Toc5885362 \h 2 7. Pakkumuse struktuur ja nõutud dokumentide loetelu PAGEREF _Toc5885363 \h 3 8. Täiendav teave HD kohta PAGEREF _Toc5885364 \h 3 9. Pakkumuse esitamine PAGEREF _Toc5885365 \h 3 11. Pakkumuse vastavuse kontroll PAGEREF _Toc5885366 \h 3 12. Pakkumuse edukaks tunnistamine PAGEREF _Toc5885367 \h 3 13. Kõrvaldamise aluste puudumise kontroll PAGEREF _Toc5885368 \h 4 14. Hankelepingu jõustumine PAGEREF _Toc5885369 \h 4 Muud r iigihanke alusdokumendid I: Hankelepingu projekt I I : Te hniline kirjeldus I II : V astavustingimused I V: Hindamiskriteeriumid ja hinnatavad näitajad V: Kõrvaldamise alused Üldandmed Hankija nimi ja andmed: Maanteeamet; registrikood 70001490; aadress Teelise 4 , 10916 Tallinn, Eesti; telefon: (+372) 611 9300; faks: (+372) 611 9360; e-post: [email protected]; koduleht: http://www.mnt.ee . Hankija kontaktisiku nimi ja kontakt andme d seoses kõnesoleva riigihankega on kättesaadavad e-riigihangete keskkonnas aadressil https://riigihanked.riik.ee/ Hankelepingu rahastamisallikas: riigieelarve. Riigihangete seadus ning selle alamastme õigusaktid on elektrooniliselt kättesaadavad interneti aadressidel: https://www.riigiteataja.ee ja http://www.fin.ee. Hankija korraldab raam hanke „ Tarkvara analüüsi, programmeerimis- ja hooldusteenus“ (viitenumber 160084) II osa alusel sõlmitud raamlepingu „ Infosüsteemide ja seonduvate tarkvaraliste moodulite analüüsi-, hooldus- ja programmeerimisteenusega seotud ülesannete teostamine “ (edaspidi Raamleping) raames minikonkursi „ Maanteeameti teede ja ITS valdkonna infosüsteemide jätkuarendused “ (edaspidi minikonkurss) . Hankija tagab piiramatu ja täieliku elektroonilise juurdepääsu minikonkursi riigihanke alusdokumentidele e-riigihangete keskkonnas aadressil https://riigihanked.riik.ee/ . Minikonkurss viiakse läbi e-riigihangete keskkonnas aadressil https://riigihanked.riik.ee/ . Minikonkursil osalemine Vastavalt R aamlepingule teeb hankija ettepaneku esitada minikonkursil pakkumus vastavalt riigihanke alusdokumentides (edaspidi HD) sisalduvatele tingimustele . Pakkumuse esitamisel kinnitab pakkuja, et ta võtab üle kõik HDs esitatud tingimused ja et ta esitab pakkumuse üksnes kõigi nende asjaolude kohta, mille kohta hankija on soovinud võistlevaid pakkumusi . Pakkuja esitab pakkumuses kinnituse, et pakkumus vastab kõigile sõlmitud Raamlepingu tingimustele ja hankelepingu tingimustele ning et pakkumuses pakutud ühiku hinnad ei ületa Raamlepingus fikseeritud ühiku hindasid. Pakkumuse jõusoleku tähtaeg on 4 kuud pakkumuste esitamise tähtpäevast arvates. Tehniline kirjeldus Minikonkursi t ehniline kirjeldus on esitatud HD-s II Tehnili ne kirjeldus. Hankelepingu tingimused ja täitmise tähtpäev Hankija sõlmib edukaks tunnistatud pakkumuse esitanud pakkujaga hankelepingu, mille projekt on esitatud H D-s I Hankeleping u projekt . Hankelepingu täitmise periood alates hankelepingu sõlmimisest on 18 kuud või kuni on täitunud hankelepingu rahaline piirmaht 4 0 0 000 eurot, millele lisandub käibemaks . Pakkumuse koostamise keel Pakkumus koostatakse eesti keeles. Pakkumuse maksumuse esitamise struktuur ja valuuta Pakkuja esitab pakkumuse maksumuse e-riigihangete keskkonnas HD-s „ Hindamiskriteeriumid ja hinnatavad näitajad “ eurodes, täpsusega kaks kohta peale koma . Pakkumuse struktuur ja nõutud dokumentide loetelu Pakkumuse struktuur ja nõutud dokumentide ja andmete loetelu on toodud HD-s „Vastavustingimused“ ning „Hindamiskriteeriumid ja hinnatavad näitajad“. Nõutud dokumendid ja andmed tuleb esitada elektrooniliselt e-riigihangete keskkonna kaudu aadressil https://riigihanked.riik.ee . Täiendav teave HD kohta HD sisu kohta saab selgitusi kirjalikul pöördumisel hankija poole läbi e-riigihangete keskkonna aadressil https://riigihanked.riik.ee/ , riigihanke viitenumber 227116. Pakkumus e esitamine Pakkumuse esitamise tähtpäev on 10 . 0 9 . 20 20 . a kell 1 0 : 00 . Pakkumus tuleb esitada e-riigihangete keskkonnas aadressil: https://riigihanked.riik.ee . Pabe ril, e-posti teel esitatud pakkumused ei osale hankemenetluses . Pakkumuse tähtaegse esitamise eest vastutab pakkuja. Pakkuja kannab kõik pakkumuse koostamise ning esitamisega seotud kulud. HD punktis REF _Ref171415155 \r \h \* MERGEFORMAT 9 .1 nimetatud tähtajast hiljem saabunud pakkumust arvesse ei võeta. Pakkuja võib esitatud pakkumuse enne pakkumuse esitamise tähtaega iseseisvalt tagasi võtta e-riigihangete keskkonnas . Pakkuja võib esitada HD punktis REF _Ref171415155 \r \h \* MERGEFORMAT 9 .1 nimetatud tähtaja jooksul uue pakkumuse. Pakkuja peab arvestama pakkumuse koostamisel ja esitamisel e-riigihangete keskkonnast tulenevate nõuete ja piirangutega. Hankija ei vastuta võimalike viivituste, tõrgete või katkestuste eest, mida põhjustavad e-keskkonnas hankija kontrollile mitte alluvad asjaolud, nt force majeure , elektrikatkestused, häired pakkuja või hankija telefoni või interneti ühenduses või muude elektrooniliste seadmete ja vahendite, sealhulgas tarkvara töös jne. Hankija ei vastuta e-keskkonna kasutamisest või mittekasutamisest tekkinud kahjude või saamatajäänud tulu eest. E-riigihangete keskkonna kasutamisega seotud tuge pakub e-riigihangete keskkond ja Rahandusministeerium. Pakkumus e avamine Pakkumus avatakse e-riigihangete keskkonnas https://riigihanked.riik.ee HDs toodud ajal. Pakkumus e vastavuse kontroll Hankija kontrollib pakkuja poolt esitatud pakkumuse vastavust HD-s „Vastavustingimused“ ja „Hindamiskriteeriumid ja hinnatavad näitajad“ esitatud tingimustele . Hankija lükkab pakkumuse tagasi , kui see ei vasta HDs esitatud tingimustele. Hankija võib tunnistada pakkumuse vastavaks, kui selles ei esine sisulisi kõrvalekaldeid HDs esitatud tingimustest. Hankija ei tunnista pakkumust vastavaks ja lükkab pakkumuse tagasi, kui pakkumuses esitatud ühiku hind ületa b pakkujaga sõlmitud R aamlepingus fikseeritud vastavat ühiku hinda. Pakkumus t e hindamise kriteeriumid, hindamine ja edukaks tunnistamine Hankija hindab pakkumusi punktis REF _Ref187738106 \r \h \* MERGEFORMAT 6 .1 nimetatud dokumendis esitatud pakkumuse kogumaksumuse alusel käibemaksuta . Edukaks pakkumuseks tunnistatakse pakkumus, milles pakutud kogumaksumus ilma käibemaksuta on madalaim. Kui kaks või enam pakkumust, mille maksumused on madalaimad, on võrdväärsete maksumustega, siis valitakse edukas pakkumus liisuheitmise teel hankija poolt määratud korras, ajal ja kohas ning kus osalevad võrdväärsete maksumustega pakkumused esitanud pakkujate esindajad. Kõrvaldamise aluste puudumise kontroll Hankija ei sõlmi hankelepingut ja kõrvaldab hankemenetlusest pakkuja, kellel esinevad riigihangete seaduse § 95 lõikes 1 toodud kõrvaldamise alused. Hankija kontrollib enne hankelepingu sõlmimist edukal pakkujal kõrvaldamise aluste puudumist riigihangete registri liidese kaudu vastavatest registritest . Hankija võib kõrvaldada hankemenetlusest pakkuja, kellel esinevad riigihangete seaduse § 95 lõikes 4 toodud kõrvaldamise alused. Hankija teeb otsuse enne hankelepingu sõlmimist eduka pakkuja kõrvaldamise või kõrvaldamata jätmise kohta. Kui hankija tuvastab, et pakkujal esineb riigihangete seaduse § 95 lõike 1 punktis 4 või lõike 4 punktis 1 sätestatud alus, siis rakendab hankija riigihangete seaduse § 95 lõiget 6. H ankelepingu jõustumine Hankeleping jõustub Hankija poolt allkirjastatud Lepingu esitamisel edukaks tunnistatud pakkumuse esitanud pakkujale. HINDAMISKRITEERIUMID JA HINNATAVAD NÄITAJAD Viitenumber: 227116 Hankija: Maanteeamet (70001490) Hange: Maanteeameti teede ja ITS valdkonna infosüsteemide jätkuarendused OSA 1 – MAANTEEAMETI ERINEVATE INFOSÜSTEEMIDE ANALÜÜSI, PROGRAMMEERIMIS- JA HOOLDUSTEENUS, SH LIIKLUSREGISTER JA E-TEENINDUS Pakkumuse maksumust hinnatakse - Ilma maksudeta Elektroonilist oksjoni kasutatakse: ei Jrk Nimetus Kirjeldus Tüüp / Osakaal Kogus Ühik Pakkuja nr hindamismeetod täidetav 1 Maanteeameti teede ja ITS valdkonna Maksumus - 100 infosüsteemide jätkuarendused vähim on parim Projektijuhi tunnihind Esitada projektijuhi ühe töötunni hind. 1 tund (h) jah Süsteemianalüütiku tunnihind Esitada süsteemianalüütiku ühe tunni hind. 1 tund (h) jah Programmeerija (arendaja) tunnihind Esitada programmeerija (arendaja) ühe tunni hind. 1 tund (h) jah Testija tunnihind Esitada testija ühe tunni hind. 1 tund (h) jah Kokku: 100 Hindamismetoodika kirjeldus 1. Maanteeameti teede ja ITS valdkonna infosüsteemide jätkuarendused Madalaima väärtusega pakkumus saab maksimaalse arvu punkte. Teised pakkumused saavad punkte proportsionaalselt vähem ja arvutatakse valemiga: "madalaim väärtus" / "pakkumuse väärtus" * "osakaal". Koostatud 07.09.2020 10:26:22 1/1 https://riigihanked.riik.ee/rhr-web/#/procurement/ 2331172/general-info  1/1 KÕRVALDAMISE ALUSED JA KVALIFITSEERIMISTINGIMUSED Viitenumber: 227116 Hankija: Maanteeamet (70001490) Hange: Maanteeameti teede ja ITS valdkonna infosüsteemide jätkuarendused KÕRVALDAMISE ALUSED RIIGIHANGETE SEADUSE § 95 LÕIKES 1 TOODUD KÕRVALDAMISE ALUSTE PUUDUMISE KINNITUS Hankija ei sõlmi hankelepingut ja kõrvaldab hankemenetlusest pakkuja: 1) keda või kelle haldus-, juhtimis- või järelevalveorgani liiget või muud seaduslikku või asjaomase riigihankega seotud lepingulist esindajat on karistatud kuritegelikus ühenduses osalemise, aususe kohustuse rikkumise või korruptiivse teo, kelmuse, terroriakti toimepaneku või muu terroristliku tegevusega seotud kuriteo või sellele kihutamise, kaasaaitamise või selle katse, rahapesualase süüteo või terrorismi rahastamise eest; 2) keda või kelle haldus-, juhtimis- või järelevalveorgani liiget või muud seaduslikku või asjaomase riigihankega seotud lepingulist esindajat on karistatud riigis ilma seadusliku aluseta viibivale välismaalasele töötamise võimaldamise või välismaalase Eestis töötamise tingimuste rikkumise võimaldamise, sealhulgas seaduses sätestatud töötasu määrast väiksema töötasu maksmise eest; 3) keda või kelle haldus-, juhtimis- või järelevalveorgani liiget või muud seaduslikku või asjaomase riigihankega seotud lepingulist esindajat on karistatud laste tööjõu ebaseadusliku kasutamise või inimkaubandusega seotud teo eest; 4) kellel on riikliku maksu, makse või keskkonnatasu maksuvõlg maksukorralduse seaduse tähenduses või maksu või sotsiaalkindlustusmaksete võlg tema asukohariigi õigusaktide kohaselt; 5) kes või kelle haldus-, juhtimis- või järelevalveorgani liige on rahvusvahelise sanktsiooni subjekt rahvusvahelise sanktsiooni seaduse tähenduses (RHS § 95 lg 1). Juhul, kui hankija tuvastab pakkujal punktis 4 nimetatud kõrvaldamise aluse, siis hankija rakendab riigihangete seaduse § 95 lg 6. Hankijal on igal aja hetkel õigus küsida pakkujalt täiendavaid dokumente, kui neid andmeid ei ole hankijal võimalik kontrollida andmekogus olevate avalike andmete põhjal. Kehtib: Kogu hanke kohta Küsimused ettevõtjale: 1) Kas pakkujal või ühispakkumuse korral kaaspakkujal esinevad riigihangete seaduse § 95 lõikes 1 toodud kõrvaldamise alused? (Raadionupp valikutega "Jah/Ei") RIIGIHANGETE SEADUSE § 95 LÕIKES 4 TOODUD KÕRVALDAMISE ALUSTE PUUDUMISE KINNITUS Hankija võib kõrvaldada hankemenetlusest pakkuja, kellel esinevad riigihangete seaduse § 95 lõikes 4 toodud kõrvaldamise alused. Kehtib: Kogu hanke kohta Küsimused ettevõtjale: 1) Kas pakkujal või ühispakkumuse korral kaaspakkujal esinevad riigihangete seaduse § 95 lõikes 4 toodud kõrvaldamise alused? (Raadionupp valikutega "Jah/Ei") Koostatud 07.09.2020 10:18:40 https://riigihanked.riik.ee/rhr-web/#/procurement/2331172/general-info  KÄSKKIRI 07.09.2020 nr 1-23/20/699 Raamlepingu alusel korraldatava minikonkursi Maanteeameti teede ja ITS valdkonna infosüsteemide jätkuarendused riigihanke alusdokumentide kinnitamine, eeldatava maksumuse, komisjoni koosseisu ning selgitusi andva isiku määramine Võttes aluseks riigihangete seaduse § 5 lõike 2 punkti 1 ja § 30 ning kooskõlas majandus- ja taristuministri 16.10.2018. a määrusega nr 55 kinnitatud Maanteeameti põhimääruse § 9 lõikega 1 ja § 10 lõikega 1: 1. Raamhanke „Tarkvara analüüsi, programmeerimis- ja hooldusteenus“ (viitenumber 160084) II osa alusel sõlmitud raamlepingu „Infosüsteemide ja seonduvate tarkvaraliste moodulite analüüsi-, hooldus- ja programmeerimisteenusega seotud ülesannete teostamine“ raames korraldan minikonkursi „Maanteeameti teede ja ITS valdkonna infosüsteemide jätkuarendused”. 2. Tulenevalt nimetatud raamlepingu punktist 4.3 saadetakse minikonkursi pakkumuse esitamise ettepanekud kõikidele raamlepingu partneritele. 3. Määran minikonkursi eeldatavaks maksumuseks 400 000 eurot ilma käibemaksuta. 4. Riigihangete talituse peaspetsialistil Helen-Mai Voogand´il edastada koheselt riigihangete registri kaudu pakkumuse esitamise ettepanekud kõikidele raamlepingu partneritele. 5. Minikonkursi riigihanke alusdokumentide osas anda vajadusel selgitusi riigihangete talituse peaspetsialistil Helen-Mai Voogand´il või riigihangete registris vastutavaks või volitatud isikuks määratud riigihangete talituse töötajal. 6. Moodustan nõuandva õigusega komisjoni (edaspidi nimetatud Komisjon), kes korraldab minikonkursi korraldamisega seotud toimingute läbiviimise vastavalt riigihangete seaduses sätestatule ning esitab peadirektorile motiveeritud ettepanekud pakkumuste vastavaks tunnistamiseks või pakkumuste tagasilükkamiseks, kõigi pakkumuste tagasilükkamiseks, minikonkursi kehtetuks tunnistamiseks, ühe pakkumuse edukaks tunnistamiseks ning pakkuja hankemenetlusest kõrvaldamiseks või kõrvaldamata jätmiseks. Komisjon järgib töökorralduslikes küsimustes Komisjoni esimehe korraldusi. 6.1. Moodustan Komisjoni alljärgnevas koosseisus: Komisjoni esimees: Helen-Mai Voogand– õigusosakonna riigihangete talituse peaspetsialist või riigihangete registris vastutavaks või volitatud isikuks määratud riigihangete talituse töötaja.  2 Komisjoni liikmed: Juhan Kaarpalu - infotehnoloogia osakonna teenusehaldur või tema ametlik asendaja; Raigo Püü - infotehnoloogia osakonna projektijuht või tema ametlik asendaja. 6.2. Volitan Komisjoni esimeest: a) nõudma Maanteeameti nimel pakkujatelt pakkumuses esitatud andmete kohta riigihangete seaduse § 46 lõike 4 kohaseid selgitusi või selgitamist võimaldavad dokumente; b) andma korraldusi Komisjoni töö korraldamiseks; c) esitama pakkujale riigihangete seaduse § 112 kohaseid ettepanekuid pakkumuse jõusoleku tähtaja pikendamiseks ning § 47 ning § 30 lõike 11 kohaseid teateid; d) Maanteeameti nimel esitama riigihanke alusdokumendid käesolevas käskkirjas määratud isikutele. 7. Määran hankelepingu täitmise eest vastutavateks isikuteks infotehnoloogia osakonna projektijuhid Raigo Püü ja Tõnu Vahter´i. (allkirjastatud digitaalselt) Priit Sauk peadirektor