Leping

ANDMED MEESKONNAS OSALEVA ISIKU KOHTA Perekonnanimi: Kaar Eesnimi: Vahur Roll hankelepingu täitmisel: Programmeerija Alljärgnevalt esitada üksnes need andmed, mis peaksid kinnitama riigihanke hanketeates ja hankedokumentides vastava ametikohaga isikule kogemuse ja kutsealase kvalifikatsiooni osas esitatud nõuete täitmist (täiendavalt võib lisada ainult andmeid, mis kinnitavad veelgi kõrgemate nõudmiste täitmist). Haridus Haridusasutus Eriala Omandatud kraad Haridust tõendava dokumendi number ja väljastamise aeg Tallinna tehnikaülikool Informaatika Magister 2016 , MB006476 Tallinna tehnikaülikool Informaatika Bakalaureus 2014 , LB007725 Töökogemus Tööandja nimi Töö-/ametikoha nimetus Töötatud aeg Tööülesannete kirjeldus Dolm IT OÜ Java Vanemarendaja/Arhitekt 01.2018 - .. Keerulisemate infosüsteemide arendamine Javas, arhitektuuri disainimine ja kokkupanek Tieto Estonia AS Full-stack Java arendaja/Arhitekt 02.2014 -01.2018 Infosüsteemide front ja backend arendus (Java+Angular), andmebaaside arendus ( Oracle , Postgre SQL ), arhitektuuri disainimine ja kokkupanek Telema AS Java arendaja 11.2012 -02.2014 Majasiseste toodete arendamine programmeerimiskeeles Java Keeleoskus Kinnitame, et eelnimetatud isik valdab eesti keelt nii suuliselt kui ka kirjalikult ulatuses, mis on vajalik hankelepingu täitmiseks või kasutame omal kulul tõlgiteenust. Teostatud tööd (loetleda vastavalt konkreetse meeskonnaliikme osas esitatud hindamiskriteeriumitele tema osalus nõuetekohaselt teostatud projektides): 1. Projekti nimetus: Rikete haldussüsteem Projekti tellija (asutus/organisatsioon): Kühne &amp; Nagel AS Tellija esindaja kontaktandmed: Priit Pihlak, [email protected] Projekti toimumise periood (kuu/aasta täpsusega ): 01.2018 – 07.2018 Roll projektis: Java Arhitekt/Vanemarendaja Teostatud töö sisu lühikirjeldus: Rahvusvahelise kontserni rikete hald ussüsteemi arhitektuuri loomine. Projekti tehnoloogiline profiil: Java 8, Apache Tomcat &amp; PostgreSQL , AngularJS &amp; HTML5 , SOAP Projekti maksumus + 100 000 EUR 2 . Projekti nimetus: Rahvusarhiiv Projekti tellija (asutus/organisatsioon): Eesti Haridusministeerium Projekti toimumise periood (kuu/aasta täpsusega ): 01.201 6 – 12.201 6 Roll projektis: Java Vanemarendaja/Arhitekt Teostatud töö sisu lühikirjeldus: Rahvusarhiivi projekt kasutas Preservica 5 arhiivimistooteid. Arendaja ülesandeks oli aidata versiooni uuendada ja täiendada lahenduse arhitektuuri, mis toetaks uut funktsionaalsust . Arhiivikeskuste haldamiseks oli riikliku arhiivi infosüsteemil eraldi veebirakendus , mis päris andmeid läbi SOAP x-tee protokolli . Arhiivikaardid salvestatakse eXist andmebaasi xml -andmebaasi. Java, Preservica 5,Tomcat, PostgreSQL , SOAP, X-tee Projekti maksumus + 80 000 EUR 3 . Projekti nimetus: EHIS (Eesti Hariduse Infosüsteem) Projekti tellija (asutus/organisatsioon): Eesti Haridusministeerium Tellija esindaja kontaktandmed: [email protected] Projekti toimumise periood (kuu/aasta täpsusega ): 01.201 5 – 12.201 5 Roll projektis: Java Arendaja/Arhitekt Teostatud töö sisu lühikirjeldus: Arendaja roll projektis oli uue funktsionaalsuse rakendamine ja olemasoleva seadistamine vastavalt spetsifikatsioonidele; Oracle'i andme mudeli jätkuarendused ja andmete migratsioon . Arendaja täitis osade moodulite puhul arhitekti rolli: üks suurimatest all - projektidest oli uu e keskse autentimisteenuse mooduli arendus , mis sisaldas Eesti ID-kaarti ja mobiil-ID autentimist. Projektis kasutati RSS standardeid. Java, Oracle , ID autentimine Projekti maksumus +100 000 EUR Pakkuja volitatud esindaja nimi: Mait Piir ( ühispakkujate puhul märkida ühispakkujaid esindama volitatud ühispakkuja esindaja nimi ) ANDMED MEESKONNAS OSALEVA ISIKU KOHTA Perekonnanimi: Üksti Eesnimi: Tauri-Sten Roll hankelepingu täitmisel: Testija Alljärgnevalt esitada üksnes need andmed, mis peaksid kinnitama riigihanke hanketeates ja hankedokumentides vastava ametikohaga isikule kogemuse ja kutsealase kvalifikatsiooni osas esitatud nõuete täitmist (täiendavalt võib lisada ainult andmeid, mis kinnitavad veelgi kõrgemate nõudmiste täitmist). Haridus Haridusasutus Eriala Omandatud kraad Haridust tõendava dokumendi number ja väljastamise aeg Tallinna Tehnikaülikool Äriinfotehnoloogia Bakalaureus LB 009221 , 09.06.2016 Töökogemus Tööandja nimi Töö-/ametikoha nimetus Töötatud aeg Tööülesannete kirjeldus Bang &amp; Olufsen Tarkvaratestija 05.2014-06.2015 AV-seadmete manuaalne testimine, testraportite koostamine, leitud vigade raporteerimine AS LHV Pank Analüütik - Testija 10.2015-04.2018 Ärinõuete kogumine, eelanalüüsi teostamine, prototüüpide loomine, andmebaasi modeleerimine, süsteemi spetsifikatsiooni koostamine, arendusülesannete loomine, arendusmeeskonna töö koordineerimine, vajadusel testimine, ärianalüütika lahenduste loomine Dolm IT Analüütik - Testija 05.2018- Prototüüpide loomine, eelanalüüsi teostamine, testimine Keeleoskus Kinnitame, et eelnimetatud isik valdab eesti keelt nii suuliselt kui ka kirjalikult ulatuses, mis on vajalik hankelepingu täitmiseks või kasutame omal kulul tõlgiteenust. Teostatud tööd (loetleda vastavalt konkreetse meeskonnaliikme osas esitatud hindamiskriteeriumitele tema osalus nõuetekohaselt teostatud projektides): 1. Projekti nimetus: LHV Laenuhaldussüsteem Projekti tellija (asutus/organisatsioon): AS LHV Pank Tellija esindaja kontaktandmed: Britt Jaaska, [email protected] Projekti toimumise periood (kuu/aasta täpsusega ): 10.2015-04.2018 Roll projektis: Analüütik - Testija Teostatud töö sisu lühikirjeldus: LHV laenude haldamiseks mõeldud süsteemi kohta nõuete kogumine, eelanalüüsimine ja testimine. Ärianalüütika (BI) vajaduste analüüsimine ja teostamine. Projekti maksumus + 500 000 EUR 2. Projekti nimetus: LHV Võlahaldussüsteem Projekti tellija (asutus/organisatsioon): AS LHV Pank Tellija esindaja kontaktandmed: Britt Jaaska, [email protected] Projekti toimumise periood (kuu/aasta täpsusega ): 05.2016-04.2018 Roll projektis: Analüütik - Testija Teostatud töö sisu lühikirjeldus: LHV võlglaste haldamiseks mõeldud süsteemi kohta nõuete kogumine, eelanalüüsimine ja testimine. Ärianalüütika (BI) vajaduste analüüsimine ja teostamine. Projekti maksumus + 500 000 EUR 3 . Projekti nimetus: LHV Tagatiste süsteem Projekti tellija (asutus/organisatsioon): AS LHV Pank Tellija esindaja kontaktandmed: Britt Jaaska, [email protected] Projekti toimumise periood (kuu/aasta täpsusega ): 05.2016-04.2018 Roll projektis: Analüütik - Testija Teostatud töö sisu lühikirjeldus: LHV laenude tagatisteks olevate varade haldamiseks mõeldud süsteemi kohta nõuete kogumine, eelanalüüsimine ja testimine. Ärianalüütika (BI) vajaduste analüüsimine ja teostamine. Projekti maksumus + 100 000 EUR 4 . Projekti nimetus: eCargoWorld CRM Süsteem Projekti tellija (asutus/organisatsioon): еКаргоУорлд Tellija esindaja kontaktandmed: [email protected] Projekti toimumise periood (kuu/aasta täpsusega ): 05.2018- Roll projektis: Analüütik - Testija Teostatud töö sisu lühikirjeldus: Logistikafirma CRM süsteemi eelanalüüsimine, protüüpimine ja testimine. Projekti maksumus + 80 000 EUR Pakkuja volitatud esindaja nimi: Mait Piir ( ühispakkujate puhul märkida ühispakkujaid esindama volitatud ühispakkuja esindaja nimi ) Pakkuja viimase kolme aasta riigihanke esemele sarnase esemega lepingute nimekiri Hankija nimi: Tervise ja Heaolu Infosüsteemide Keskus Riigihanke nimetus: Autentimis- ja autoriseerimismooduli arendustööd Riigihanke viitenumber: 201050 Dolm IT OÜ kinnitab, et meil on olemas lepingu täitmiseks vajalik tehniline võimekus. Pakkuja poolt viimasel kolmel aastal (kuni käesoleva hankemenetluse pakkumuste esitamise tähtajani ) teostatud vähemalt 2 lepingut autentimist- ja autoriseerimist sisaldavad tarkvara arendused, mille ISKE kohane turbeaste on keskmine (M) või samaväärne , millest iga le pingu maksumus peab olema olnud vähemalt 50 000 eurot km-ta . Leping 1 Teostatud lepingu nimetus Kütuseseire andmebaasi loomine Tellija Keskkonnaministeeriumi Infotehnoloogiakeskus Tellija kontaktisik (ees- ja perenimi, tel nr, e-post) Kadri Tammäe, [email protected] Sisu kokkuvõte* Kütuseseire infosüsteem hõlm ab keskset lahendust kütuse tarnijate imporditud kütuse haldamiseks. Süsteemi arenduse käigus sai loodud Keskkonnaministeeriumi valitsusala turvasüst eemide autentimise moodul CAS Dev AUP, mis vastab vähemalt ISKE keskmisele tasemele (M). Teostamise aeg (algus kuu/aasta – lõpp kuu/aasta ) 01.10.2017 – 30.05.2018 Maksumus (eurodes, käibemaksuta) 50 000+ Leping 2 Teostatud lepingu nimetus Kühne &amp; Nagel kontserni rikete ja teavituste haldussüsteem Tellija KÜHNE + NAGEL IT SERVICE CENTRE AS Tellija kontaktisik (ees- ja perenimi, tel nr, e-post) Priit Pihlak , priit . pihlak @ kuehne-nagel . com Sisu kokkuvõte* Rikete teavitus- ja halduskeskkond hõlmab endas kogu Kühne &amp; Nageli kontserni automaatset teavituse infosüsteemi. Arenduse käigus sai loodud LDAP liidestus keskse kasutajate andmebaasi vastu , mis vastab vähema lt ISKE keskmisele tasemele (M). Lisaks sai loodud eraldi autentimise liides kasutajate tellimus t e halduseks. Teostamise aeg (algus kuu/aasta – lõpp kuu/aasta ) 13 .0 1 .2018 – 30.08.2018 Maksumus (eurodes, käibemaksuta) 50 000+ * Sisu kokkuvõte peab andma piisavat informatsiooni selle kohta, kas pakkuja kvalifikatsioon vastab nõutule . Allkirjastatud digitaalselt. Daniel Leifer Dolm IT OÜ Kinnitus ed Käesolevaga kinnitab pakkuja riigihangete seaduse (RHS) § 95 lg 1 p 1- 5 sätestatud hankemenetluse k õrvaldamise aluste puudumist: Kinnitame, et Pakkujat või Pakkuja haldus-, juhtimis- või järelevalveorgani liiget või muud seaduslikku või asjaomase riigihankega seotud lepingulist esindajat ei ole 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; Kinnitame, et Pakkujat või Pakkuja haldus-, juhtimis- või järelevalveorgani liiget või muud seaduslikku või asjaomase riigihankega seotud lepingulist esindajat ei ole karistatud riigis ilma seadusliku aluseta viibivale välismaalasele töötamise võimaldamise eest; Kinnitame, et Pakkujat või Pakkuja haldus-, juhtimis- või järelevalveorgani liiget või muud seaduslikku või asjaomase riigihankega seotud lepingulist esindajat ei ole karistatud laste tööjõu ebaseadusliku kasutamise või inimkaubandusega seotud teo eest; Kin nitame, et Pakkujal ei ole riikliku maksu, makse või keskkonnatasu maksuvõlg a maksukorralduse seaduse tähenduses või maksu- või sotsiaalkindlustusmaksete võlg a Pakkuja asukohariigi õigusaktide kohaselt; Kinnitame, et Pakkuja või Pakkuja haldus-, juhtimis- või järelevalveorgani liige ei ole rahvusvahelise sanktsiooni subjekt rahvusvahelise sanktsiooni seaduse tähenduses. /allkirjastatud digitaalselt / Mait Piir Juhatuse liige ANDMED MEESKONNAS OSALEVA ISIKU KOHTA Perekonnanimi: Piir Eesnimi: Mait Roll hankelepingu täitmisel: Projektijuht Alljärgnevalt esitada üksnes need andmed, mis peaksid kinnitama riigihanke hanketeates ja hankedokumentides vastava ametikohaga isikule kogemuse ja kutsealase kvalifikatsiooni osas esitatud nõuete täitmist (täiendavalt võib lisada ainult andmeid, mis kinnitavad veelgi kõrgemate nõudmiste täitmist). Haridus Haridusasutus Eriala Omandatud kraad Haridust tõendava dokumendi number ja väljastamise aeg Tallinna Tehnikaülikool Äriinfotehnoloogia Bakalaureusekraad LB010474 09.06.2017 Töökogemus Tööandja nimi Töö-/ametikoha nimetus Töötatud aeg Tööülesannete kirjeldus Dolm IT OÜ - Daniel Leifer Projektijuht 11/2015 - Praeguseni Avaliku ja erasektori projektide nii süsteemi, kui ka ärianalüüsi teostamine, arhitektuuri disainimine ja kokkupanek ning projektide hindamine Keskkonnaministeeriumi infotehnoloogiakeskus - Kadri Tammäe Projektijuht - Analüütik 02/2015 – 11/2015 Keskkonnaministeeriumi allasutustele IT projektidele nii süsteem, kui ärianalüüsi teostamine, projektide juhtimine. Thorgate management OÜ - Raido Pikkar Projektijuht - Analüütik 05/2013 – 02/2015 Avaliku ja erasektori projektide juhtimine ja anaüüsi teostamine. Keeleoskus Kinnitame, et eelnimetatud isik valdab eesti keelt nii suuliselt kui ka kirjalikult ulatuses, mis on vajalik hankelepingu täitmiseks või kasutame omal kulul tõlgiteenust. Teostatud tööd (loetleda vastavalt konkreetse meeskonnaliikme osas esitatud hindamiskriteeriumitele tema osalus nõuetekohaselt teostatud projektides): 1. Projekti nimetus: Kütuseseire Infosüsteem Projekti tellija (asutus/organisatsioon): Keskkonnaministeeriumi Infotehnoloogiakeskus (KEMIT) Tellija esindaja kontaktandmed: Kadri Tammäe, [email protected] Projekti toimumise periood (kuu/aasta täpsusega ): 05.10.2017 - Praeguseni Roll projektis: Projektijuht - Analüütik Teostatud töö sisu lühikirjeldus: Projektiplaani kokkupanek, AS analüüsi teostamine, arendajatele ülesannete ette andmine, projekti manageerimine Täitja poolelt. P rojekti maksumus +80 000 EUR 2. Projekti nimetus: JAHIS ja METSIS infosüsteemide arendus Projekti tellija (asutus/organisatsioon): Jahimeeste Selts MTÜ Tellija esindaja kontaktandmed: Tõnis Korts, [email protected] Projekti toimumise periood (kuu/aasta täpsusega ): 05.10.2016 – 01.04.2017 Roll projektis: Projektijuht Teostatud töö sisu lühikirjeldus: Projektiplaani ja skoobi kokkupanek, arhitektuuri loomine, arendajatele ülesannete ette andmine ja nende kontrollimine Projekti maksumus +4 0 000 EUR 3 . Projekti nimetus: Homely koristusplatvormi arendus Projekti tellija (asutus/organisatsioon): Serp Innovations OÜ Tellija esi ndaja kontaktandmed: Tauri Urbanik, [email protected] Projekti toimumise periood (kuu/aasta täpsusega ): 20.11.2015 - 05.10.2016 Roll projektis: Projektijuht Teostatud töö sisu lühikirjeldus: Projektiplaani ja skoobi kokkupanek, arhitektuuriloomine ja arendustsükli tekitamine Projekti maksumus +7 0 000 EUR 4 . Projekti nimetus: Ilmateenistuse M. veebi arendustööd ning põhiveebi jätkutööde analüüs Projekti tellija (asutus/organisatsioon): Keskkonnaministeeriumi Infotehnoloogiakeskus (KEMIT) Tellija esindaja kontaktandmed: Kadri Tammäe, [email protected] Projekti toimumise periood (kuu/aasta täpsusega ): 01.02.2015 - 01.11.2015 Roll projektis: Projektijuht - Analüütik Teostatud töö sisu lühikirjeldus: Ilmateenistuse erinevate moodulite analüüs, võimalikud muudatused M.veebi raames, uue lahenduse kokkupanek Projekti maksumus + 500 000 EUR Pakkuja volitatud esindaja nimi: Mait Piir ( ühispakkujate puhul märkida ühispakkujaid esindama volitatud ühispakkuja esindaja nimi ) Vastavuskinnitused Pakkuja andmed Pakkuja nimi / Ühispakkujate volitatud esindaja nimi Dolm IT Oܡ ˇ 12809505 Aadress Harjumaa, Tallinn, Pärnu mnt 122-20, 11313 Kontaktisik ja tema andmed Mait Piir, juhatuse liige Telefon +372 535 000 07 Elektronposti aadress Harjumaa, Tallinn, Parda 12, 10151 Kodulehekülg www.dolmit.com 1. Pakume ennast teostama käesolevat riigihanget ja kinnitame, et oleme tutvunud hanke tingimustega ja meil on olemas rahalised vahendid hankelepingu täitmiseks. 2. Kinnitame, et võtame üle kõik hanketeates, hankedokumentides ja selle lisades esitatud tingimused ja esitame pakkumuse üksnes kõigi nend e asjaolude kohta, mille kohta H ankija soovib võistlevaid pakkumusi. 3. Kinnitame, et meil on intellektuaalse omandiga seotud hankelepingu täitmiseks vajalikud intellektuaalse omandi õigused. 4. Kinnitame, et kõik käesolevale pakkumusele lisatud dokumendid moodustavad meie pakkumuse . Juhul kui hanketingimustes on nõutud meeskonda, siis kinnitame, et pakkumuses esitatud meeskonnaliikmed osalevad hankelepingu täitmisel. 5. Kinnitame, et pakkumus on jõus hanketeates määratud minimaalse tähtaja jooksul . 6. Aktsepteerime Hankija õigust lükata tagasi kõik pakkumused hankedokumentides kirjeldatud juhtudel , sh kui pakkumuste maksumused ületavad Hankija planeeritavat eelarvet . 7. Anname nõusoleku meie poolt esitatud andmete või dokumentide õigsuse kontrollimiseks järelpärimiste tegemiseks kolmandatele isikutele ja nõustume, et Hankija võib kolmandatelt isikutelt saadud dokumendid ja andmed võtta käesoleval riigihankel otsuste tegemisel aluseks. 8. Kinnitame, et oleme nõus hankemenetluses edastatavate dokumentide elektroonilise kättetoimetamisega. Mait Piir Juhatuse liige Pakkumuse maksumuse vorm Pakkumus 190931, pakkuja: Dolm IT OÜ (12809505) Nr Nimetus Kirjeldus Kogus Ühi Ühiku hind Maksumus KM-ta KM Maksumus KM- Märkused Ei k % ga summeeru kogu- maksumu- sele 1 Tunnihind 1 37,70 37,70 20 45,24 Maksumus kokku KM-ta: 37,70 Maksumus kokku KM-ga: 45,24 Kriteerium Numbri hindamine Väärtus  Tervise infosüsteemi autentimis- ja autoriseerimismooduli arendustööde Hankeleping nr 3-9/1488-1 Tervise ja Heaolu Infosüsteemide Keskus, registrikood 70009770, aadress Uus-Tatari 25, Tallinn, keda esindab põhimääruse alusel direktor Katrin Reinhold (edaspidi: Tellija) ja Dolm IT OÜ, registrikood 12809505 aadress Pärnu mnt 122-20, Tallinn, keda esindab juhatuse liige Daniel Leifer (edaspidi: Täitja) edaspidi koos või eraldi nimetatud ka Pooled või Pool, sõlmisid käesoleva lepingu (edaspidi: Leping) alljärgnevas: 1 Lepingu ese 1.1 Lepingu esemeks on Tervise infosüsteemi ühtse kasutajate ja kasutajagruppide halduskeskkonna ehk autentimis- ja autoriseerimismooduli (edaspidi veebirakendus) arendus- ja veaparandustööde tellimine. 1.2 Tööd tellitakse ja teostatakse vastavalt Tellija arendusportsessile ning Lepingu Lisas 1 toodud kirjeldusele. 2 Lepingu täitmise tingimused 2.1 Pooled teevad Lepingu täitmiseks ja Lepingu eesmärkide saavutamiseks koostööd. Lepingu täitmisel kohustuvad Pooled tegema kõik vajalikud pingutused, et täita õigeaegselt ja korrektselt kõiki Lepingust ning õigusaktidest tulenevaid kohustusi. 2.2 Pooled vastutavad oma vastutusalas olevate kohustuste täitmise eest ja täidavad oma kohustusi põhjendamatu viivituseta. Kui üks Pool on teinud teisele Poolele Lepingu täitmisega seotud küsimuses päringu, on teine Pool kohustatud sellele sisuliselt reageerima (asjakohast tagasisidet andma) võimalikult kiiresti, kuid hiljemalt 3 (kolme) tööpäeva jooksul. 2.3 Täitja on kohustatud tagama Lepingu täitmiseks vajalike ressursside olemasolu, sh tagama Töö teostajate kõrge professionaalse taseme ja vajaliku tehnoloogia/metoodikate väga hea tundmise ning tehtud Tööde dokumenteerimise vastavalt Tellija vormidele ja/või suunistele, samuti omama Tööde teostamiseks sobivaid keskkondi, koos kõige sinna juurde kuuluvaga, sh kasutatava tarkvara litsentsid või kasutama Tellija olemasolevaid jagatud keskkondi. Jätkuarenduste puhul on Täitja kohustatud litsentsimudeli valikul arvesse võtma Tellija varem soetatud tarkvara litsentsitingimusi või juhinduma Tellija vajadustest. 2.4 Tellija tagab Lepingu täitmiseks juurdepääsu Tellija käsutuses olevale informatsioonile ja dokumentidele (sh kaugjuurdepääsu), mis võivad olla Lepingu täitmiseks olulised või mida Täitja mõistlikkuse piirides Lepingu täitmiseks nõuda võib. 2.5 Pooltel on kohustus osa võtta töökoosolekutest Töö käigus tekkinud probleemide lahendamiseks ja infovahetuseks Tellija juures kohapeal või virtuaalselt. Töökoosolekud ei ole hanke ese ja neid ei tasustata. 2.6 Tööde teostamise keel on eesti keel, muuhulgas on see ka tellimuste esitamise, töökoosolekute jm suhtluse ning dokumenteerimise keel. 2.7 Tellijal või tema poolt määratud isikul (lepingulisel kontaktisikul) on õigus jooksvalt kontrollida Lepingu täitmist. Tellijal või tema poolt määratud isikul on õigus anda Täitjale suuniseid Lepingu täitmiseks ning Täitja on kohustatud neid järgima. Täitja on kohustatud viivitamatult informeerima Tellijat Tööde teostamist takistavatest asjaoludest,  mis segavad Lepingus toodud Tööde teostamist ja tähtaegadest kinnipidamist. Täitjal on õigus esitada Tellija kontaktisikule ettepanekuid Tööde ja tähtaegade muutmiseks. 2.8 Täitja kohustub teostama Töid kvaliteetselt ning vastavalt tarkvara arenduse ja programmeerimise valdkonna headele tavadele ja praktikale. Poolel on õigus teha teisele Poolele ettepanekuid teenuse kvaliteedi tõstmiseks. 2.9 Täitja kohustub võimaldama lisaarendustööde teostamist rakenduse arendamisel ka teiste Tellija lepingupartnerite poolt, kui rakendusega seotud arendustöid tellitakse väljaspool käesolevat lepingut (nt lisaarendustööd Euroopa Liidu või muudest välisvahenditest rahastuse korral). 2.10 Täitja peab võtma kasutusele isikuandmete ja Tellija infosüsteemide kaitseks organisatsioonilisi, füüsilisi ja infotehnilisi turvameetmeid, lähtudes muuhulgas kehtivatest õigusaktidest. Täitja ei tohi töödelda arenduskeskkondades reaalseid ja isikustatud andmeid. 2.11 Täitja peab takistama juurdepääsu Tellija infosüsteemidele töödega mitte seotud isikutele. 2.12 Tellija võib vajadusel kaasata Tarkvara turvalisuse hindamiseks välise eksperdi või audiitori. Puuduste avastamisel Täitja töös on Täitja kohustatud kõrvaldama esitatud puudused tasuta ühe kuu jooksul. Puuduste kõrvaldamata jätmisel on Tellijal õigus leping ennetähtaegselt lõpetada. 3 Lepingu eseme maksumus ja tasumise kord 3.1 Ühe (1) töötunni hind on 37,70 eurot ilma käibemaksuta. Täitja ei saa ühe töötunni hinda Lepingu kehtivuse perioodil tõsta. 3.2 Lepingujärgsete Tööde maksimaalne maht lepingu perioodil on 59 999 eurot ilma käibemaksuta. Tellija ei garanteeri nimetatud mahus Tööde tellimist ja Täitjal puudub õigus nõuda vastavas osas Tööde tellimist ja/või tasu. 3.3 Täitjal on õigus esitada arve pärast Töö(de) üleandmise-vastuvõtu akti allkirjastamist Täitja ja Tellija poolt. Arve esitatakse elektrooniliselt masinloetaval kujul e-posti aadressile [email protected]. 3.4 Tellijale antav maksetähtaeg peab olema vähemalt 21 (kakskümmend üks) kalendripäeva Tellija poolt arve kättesaamisest arvates. 4 Konfidentsiaalsuskohustus 4.1 Täitja kohustub hoidma saladuses teavet, mis on talle teatavaks saanud seoses Lepingu täitmisega või juhuslikult (edaspidi: konfidentsiaalne teave). Täitja kohustub mitte edastama konfidentsiaalset teavet kolmandatele isikutele ning võtma kasutusele kõik meetmed välistamaks konfidentsiaalse teabe sattumist kolmandate isikute valdusesse ja kasutusse. Täitja on kohustatud mitte kasutama konfidentsiaalset teavet Lepingu täitmisega mitteseotud eesmärkidel enda või kolmandate isikute huvides. 4.2 Käesoleva Lepingu tähenduses loetakse konfidentsiaalseks teabeks ärisaladusi, mistahes isiku isikuandmeid, mistahes andmeid Tellija infosüsteemide kohta (sh tehnilisi andmeid ja spetsifikatsioone, tehnilist dokumentatsiooni jms), andmeturbega seotud informatsiooni ja asjaolusid, Töö teostamisega ja Töö tulemustega seotud informatsiooni, andmeid Tellija lepingupartnerite kohta ja muud Tellija tegevusega  seonduvat mitteavalikku teavet. Kahtluse korral eeldatakse, et tegu on konfidentsiaalse teabega. 4.3 Täitja täidab kõiki kehtivaid andmekaitsealaseid ja infoturvet puudutavaid õigusakte. 4.4 Täitja ja Tellija edastavad konfidentsiaalset informatsiooni ainult nendele isikutele, kes on Lepingu täitmisega otseselt seotud ja kindlustavad, et need isikud on teadlikud ja täidavad konfidentsiaalsuskohustust. Täitja paneb käesolevas punktis sätestatu kohustuseks kõikidele kolmandatele isikutele, keda ta kasutab oma lepingujärgsete kohustuste täitmisel. 4.5 Juhul, kui Täitja töötaja või alltöövõtja rikub konfidentsiaaluskohustust, vastutab selle eest Tellija ees Täitja vastavalt Lepingus sätestatud tingimustele. 4.6 Täitja kohustub pärast Tööde teostamist hävitama tema valduses oleva konfidentsiaalse teabe niivõrd kui see on võimalik. 4.7 Konfidentsiaalsuskohustus kehtib tähtajatult ja alaliselt ka pärast Lepingu lõppemist või lõpetamist. 4.8 Konfidentsiaalsuskohustuse (Lepingu punktides 4.1 – 4.6 sätestatud kohustused) rikkumise korral on Tellijal õigus nõuda Täitjalt leppetrahvi tasumist summas 10 000 (kümme tuhat) eurot iga rikkumise eest. 4.9 Lisaks punktis 4.8 nimetatud leppetrahvi nõudeõigusele on Tellijal õigus nõuda Täitjalt konfidentsiaalsuskohustuse rikkumise tõttu tekkinud kahju täielikku hüvitamist. 5 Vastutus 5.1 Pooled vastutavad oma lepinguliste kohustuste rikkumise eest. Lepingust tuleneva kohustuse rikkumise korral Poole poolt on Lepingu teisel Poolel õigus kasutada kõiki seadusest tulenevaid õiguskaitsevahendeid. 5.2 Täitja poolse Lepingu rikkumisena käsitletakse eeskätt olukorda, kus Tööd ei vasta Lepingu tingimustele või esineb muid Täitja poolseid Lepingu rikkumisi (näiteks Tööd ei ole teostatud kokkulepitud tähtajaks, üleantud Tööd ei ole kvaliteetsed või ei vasta muudele kokkulepitud tingimustele vms). 5.3 Tööde vastuvõtmine Tellija poolt (Tellija poolt Akti allkirjastamine) ei mõjuta (ei vabasta ega vähenda) Täitja vastutust Lepingu rikkumise eest vastavalt Lepingus sätestatule. 5.4 Kui Täitja ei ole teostanud Töid korduvalt (vähemalt kahel korral) tähtaegselt (sh ei anna tähtaegselt üle kokkulepitud tingimustele vastavaid kvaliteetseid Töid) või Tööd ei vasta kokku lepitud tingimustele ja/või kvaliteedile, on Tellijal õigus nõuda Töö üleandmisega viivitamise või mittenõuetekohase Töö teostamise eest leppetrahvi 50 (viiskümmend) eurot iga Tööde üleandmisega viivitatud päeva eest, kuid mitte rohkem kui 30% (kolmkümmend protsenti) kokkulepitud Töö maksumusest. 5.5 Kui Tellija viivitab omapoolsete kohustuste täitmisega ja nende kohustuste mittetähtaegne täitmine ei võimalda Täitjal omapoolseid kohustusi tähtaegselt täita, pikendatakse Tööde üleandmise tähtaega vastava aja võrra. 5.6 Veaparandustööde lahendusaegadest mittekinnipidamisel rakendatakse Lepingu Lisas 1 sätetatud leppetrahve. 5.7 Juhul, kui Täitja ei kõrvalda garantiiajal avastatud vigu kokkulepitud aja jooksul ilma asjatute viivitusteta, on Tellijal õigus rakendada leppetrahvi kuni 2% (kaks protsenti) päevas selle Töö maksumusest, milles garantiiline viga esineb iga Tööde üleandmisega viivitatud päeva eest. 5.8 Tellija poolt arve tasumisega viivitamise korral on Täitjal õigus nõuda Tellijalt viivise tasumist 0,2% (null koma kaks protsenti) tähtaegselt tasumata summalt iga tasumisega viivitatud päeva eest, kuid mitte rohkem kui 30% (kolmkümmend protsenti) tähtaegselt  tasumata summalt. Viivise nõudmiseks peab Täitja esitama Tellijale vastavasisulise nõude vähemalt kirjalikku taasesitamist võimaldavas vormis. 5.9 Tellija peab esitama Lepingu rikkumisest tuleneva leppetrahvi nõude Täitjale mõistliku aja jooksul, kuid mitte hiljem kui 3 (kolme) kuu jooksul arvates päevast, mil Tellijal tekkis leppetrahvi nõude esitamise õigus. Tööde vastuvõtmine Tellija poolt ei vabasta Täitjat leppetrahvi tasumise kohustusest ega võta ära Tellija õigust leppetrahvi nõude esitamiseks. 5.10 Täitjal on võimalik esitada vastuväiteid ja tugineda rikkumise vabandatavusele, esitades Poolele sellekohase avalduse 10 (kümne) kalendripäeva jooksul alates nõude kättesaamisest. Eeldatakse, et rikkumine ei ole vabandatav. Rikkumise vabandatavusele tugineval Poolel lasub kohustus nimetatud asjaolu tõendada. 5.11 Tellijal on õigus Tööde eest tasumisel vähendada Täitjale makstava tasu suurust leppetrahvi summa võrra. 5.12 Täitja poolse olulise Lepingu rikkumise korral ei pea Tellija määrama Täitjale Lepingu täitmiseks võlaõigusseaduse §-s 114 nimetatud täiendavat tähtaega ning Tellijal on muu hulgas õigus Leping üles öelda või Lepingust taganeda. 5.13 Täitja poolseks oluliseks Lepingu rikkumiseks loevad Pooled olukorda, kus Täitjale üle antud Töö tulemused ei ole vastanud korduvalt (vähemalt kahel korral) Lepingu tingimustele (näiteks ei ole saavutatud kokku lepitud Töö või Töö etapi tulemusi, üle antud Tööd ei vasta kokkulepitud tingimustele vms). 5.14 Lepingu Poole koguvastutus on piiratud Lepingu kogumaksumusega, välja arvatud raske hooletuse või tahtliku Lepingu rikkumise korral või kolmanda isiku intellektuaalomandiõiguse või kehtiva andmekaitse regulatsiooni rikkumisel. 6 Intellektuaalomand 6.1 Täitja annab Tellijale üle kõik Töö autori varalised õigused nii Eesti kui teiste riikide territooriumite suhtes ilma piiranguteta. Autori isiklike õiguste kasutamiseks annab Täitja Tellijale lihtlitsentsi kestvusega autoriõiguste kehtivuse tähtaja lõpuni. 6.2 Täitja loovutab Tellijale täielikult ja tagasivõetamatult autori varalised õigused originaalteostele ning annab lihtlitsentsi autori isiklikele õigustele Tööde üleandmise hetkest, loobudes sellega Lepingu alusel üle antud originaalteoste osas õiguste kasutamisest. 6.3 Tasu autoriõiguste loovutamise ning litsentsi andmise eest sisaldub Lepingu hinnas. 6.4 Täitja annab Tellijale piiramatud õigused Töö kasutamiseks, arendamiseks ja mistahes muudatuste tegemiseks Töös ning Tööde omandiõiguse. 6.5 Tellijal on õigus punktides 6.1 - 6.4 nimetatud õigusi ilma piiranguteta kolmandatele isikutele üle anda või litsentseerida. 6.6 Tööde üleandmisega annab Täitja Tellijale õiguse Tööde testimiseks ja muul viisil kasutamiseks, mis on vajalik Tööde vastuvõtmiseks. Tellija omandab punktides 6.1 - 6.4  nimetatud intellektuaalomandi õigused Lepingu täitmise käigus Tööde eest tasumisest alates. 6.7 Täitja on kohustatud tagama intellektuaalse omandi õiguste (eeskätt autoriõiguste) olemasolu ja kehtivuse, samuti nende ülemineku Tellijale viisil, mis võimaldab Tellijal Lepingu lõppedes üle võtta Täitja funktsioonid. 6.8 Kõik otsesed ja kaudsed kahjud, mis tulenevad sellest, et kolmandal isikul on või väidetavalt on varalisi või mittevaralisi intellektuaalsest omandist tulenevaid õigusi Lepingu alusel üle antavate intellektuaalse omandi objektide suhtes, kannab Täitja. 7 Garantii 7.1 Täitja annab kõikidele käesoleva Lepingu alusel teostatud Töödele kahe (2) aastase garantii. Garantii katab kõiki garantii tähtaja jooksul ilmnenud Tööde puudusi ja Lepingu tingimustele mittevastavusi (edaspidi ka: viga). Garantii katab ka kõiki Tööde muudatusi ja modifikatsioone, mis on tehtud Täitja poolt ja mis ei ole oluliselt muutnud varasemalt tehtud Tööd (edaspidi ka: garantiilist tööd). 7.2 Garantii tähtaeg hakkab kehtima alates Töö vastuvõtmisest Tellija poolt (st Akti allkirjastamisest Tellija poolt). 7.3 Täitja on garantii kehtivuse ajal (garantii tähtaja jooksul) kohustatud tasuta kõrvaldama Töödes avaldunud vead ja Lepingu tingimustele mittevastavused, sealhulgas on Täitja kohustatud uuendama või asendama kõik esinenud veaga seonduvad dokumendid. 7.4 Tellija informeerib Täitjat Töös esinevatest vigadest, vea iseloomust ja ulatusest viivitamatult selle ilmnemisel, niivõrd kui seda saab Tellijalt mõistlikult oodata. 7.5 Täitja on kohustatud garantii korras teostama eelkõige järgmist: 7.5.1 Vea ilmnemisel vea otsimine (lokaliseerimine), veaolukorrale lahenduse leidmine ja vea parandamine; 7.5.2 Vea põhjuste analüüs ning selle tulemuste kirjalikku taasesitamist võimaldavas vormis (näiteks e-posti teel) esitamine Tellijale, samuti ettepanekute tegemine ennetavate meetmete kasutuselevõtmise kohta; 7.5.3 Vea parandamisega seoses paigaldamise ja seadistamise toe pakkumine Tellijale, samuti sellega seotud konsultatsioonid; 7.5.4 Vigase või puuduliku dokumentatsiooni parandamine, sealhulgas dokumentatsiooni täiendamine ja uuendamine, kui selline vajadus tuleneb vigade parandamisest. 7.6 Garantiiliste vigade kõrvaldamisel juhindutakse lisaks käesolevas alapunktis toodud sätetele ka Lisas 1 veaparandustööde kohta sätestatud tingimustest 7.7 Täitja kõrvaldab garantiiperioodil ilmnenud vead sõltuvalt vea iseloomust hiljemalt 5 (viie) tööpäeva jooksul. Kui vea kõrvaldamine nimetatud aja jooksul ei ole võimalik, teatab Täitja Tellijale põhjuse, miks vea parandamine ei ole 5 (viie) tööpäeva jooksul võimalik ja millise aja jooksul on võimalik viga parandada. Kui Täitja ei kõrvalda viga kokkulepitud tähtaja jooksul, võib Tellija korraldada vea kõrvaldamise kolmanda isiku poolt Täitja kulul ja riisikol. 7.8 Juhul kui Töö hõlmab edasisi arendustöid ja kolmas osapool või Tellija teeb tarnitud lähtekoodis Täitjaga kooskõlastamata muudatusi, siis garantii katkeb. Garantii ei katke, kui Tellija suudab eristada lähtekoodis tehtavaid muudatusi. 8 Lepingu kehtivus, muutmine ja ülesütlemine 8.1 Leping jõustub sellele allakirjutamise hetkest ning kehtib 36 kuud või punktis 3.2 märgitud Lepingu mahu täitumiseni. Kui Lepingu maht ei täitu enne 36 kuu möödumist,  siis Pooled võivad kokku leppida lepingu tähtaja pikendamises kuni 12 kuud, kuid mitte rohkem kui Lepingu mahu täitumiseni. 8.2 Poolte poolt alla kirjutatud Lepingu muudatused on Lepingu lahutamatuks osaks. 8.3 Kumbki Pool võib Lepingu igal ajal ilma ette teatamata üles öelda, kui teine Pool rikub korduvalt (vähemalt kahel korral) Lepingut ning ei ole Lepingu rikkumist kõrvaldanud 21 (kahekümne ühe) päeva jooksul arvates talle Lepingu rikkumisest teatamisest kirjalikku taasesitamist võimaldavas vormis. 8.4 Kui Pool ütleb Lepingu üles punktis 8.2 toodud alusel, ei ole teisel Poolel õigust nõuda sellega seoses talle tekkinud kahju (sh hulgas saamata jäänud tulu) hüvitamist või Lepingujärgse tasu maksmist. 8.5 Tellijal on õigus Leping ühepoolselt üles öelda (lõpetada) igal ajal, teatades sellest kirjalikult Täitjale vähemalt 60 (kuuskümmend) päeva ette. Lepingu ülesütlemise korral käesolevas punktis sätestatud alusel vabanevad Pooled ülesütlemise (Lepingu lõppemise) hetkest alates kõikidest Lepingust tulenevatest kohustustest, mis neil oleksid lasunud siis, kui Leping oleks edasi kestnud (v.a garantii kehtivusest tulenevad kohustused). 8.6 Täitjal ei ole õigust nõuda Tellijalt mingit hüvitise maksmist ega saamata jäänud tulu selle tõttu, et Tellija ütles Lepingu üles enne selle kogumahu täitumist. 8.7 Täitjal on õigus Leping ühepoolselt üles öelda igal ajal, teatades sellest kirjalikult Tellijale vähemalt 90 (üheksakümmend) päeva ette. Lepingu ülesütlemise korral käesolevas punktis sätestatud alusel vabanevad Pooled ülesütlemise (Lepingu lõppemise) hetkest alates kõikidest Lepingust tulenevatest kohustustest (v.a garantii kehtivusest tulenevad kohustused). 9 Muud tingimused 9.1 Leping sisaldab Poolte täieliku kokkuleppe. Lepingu Lisad ning Poolte vahel kokku lepitud Lepingu muudatused on Lepingu lahutamatuks osaks. Lepingu tingimuste muutmine või täiendamine on võimalik vaid kirjalikus vormis, mis jõustub, kui vastavale dokumendile on alla kirjutatud mõlema Poole volitatud esindajad. 9.2 Lepingu mingi sätte muutmine või tühistamine Poolte kokkuleppe tulemusel ei too kaasa ülejäänud Lepingu punktide muutumist või kehtetust. 9.3 Pooltel ei ole õigust oma Lepingust tulenevaid õigusi ja/või kohustusi üle anda kolmandatele isikutele, kui selleks puudub teise Poole eelnev kirjalik nõusolek. Kui Täitja on kohustused üle andnud ilma Tellija nõusolekuta, võib Tellija öelda Lepingu üles ja/või  nõuda kahju hüvitamist. Täitja vastutab kolmandate isikute tegevuse eest, keda ta kasutab oma lepingujärgsete kohustuste täitmisel. 9.4 Lepinguga reguleerimata küsimustes lähtutakse Eesti Vabariigis kehtivatest õigusaktidest. 9.5 Kõik Lepingust tulenevad erimeelsused püütakse lahendada läbirääkimiste teel. Juhul kui läbirääkimised ei anna tulemusi, lahendatakse erimeelsused Harju Maakohtus. Lepingule kohaldatakse Eesti õigust. 9.6 Täitjal puudub volitus tegeleda Lepingu raames avalike suhetega ja anda teateid pressile, elektroonilisele meediale, üldsusele või teistele auditooriumidele, välja arvatud Tellija eelneval kirjalikul nõusolekul. 10 Poolte esindajad ja tööde teostajad 10.1 Pooltevahelise koostöö korraldamise eest vastutavad Poolte kontaktisikud: - Tellija esindaja Lepingu täitmisel on Kaidar Viikman, e-post [email protected], tel 5192 3484; - Täitja esindaja Lepingu täitmisel on Mait Piir, e-post [email protected] tel 5350 0007. 10.2 Esindaja vahetumise korral tuleb koheselt kirjalikku taasesitamist võimaldavas vormis informeerida teise Poole esindajat. 10.3 Esindajate volitused on piiratud Lepingu täitmisega seotud küsimustega. Lepingu muutmine, ülesütlemine jms ei kuulu esindajate pädevusse. 11 Lepingu lisad Lepingu sõlmimisega samaaegselt allkirjastavad Pooled järgmised Lepingu Lisad: 11.1 Lisa 1 – Tehniline kirjeldus; 11.2 Lisa 2 - Mittefunktsionaalsed nõuded arendustele; 11.3 Lisa 3 - Dolm IT OÜ pakkumus nr 190931. 12 Poolte allkirjad Tellija: Täitja: /allkirjastatud digitaalselt/ /allkirjastatud digitaalselt/ Katrin Reinhold Daniel Leifer Direktor Juhatuse liige  Lisa 2 Mittefunktsionaalsed nõuded arendustele Versioon: 1.0 Käesolev dokument määrab kvaliteedi- ja mittefunktsionaalsed nõuded TEHIK infosüsteemide arendustele ning nende dokumentatsioonile. Käesolevat dokumenti tuleb vaadata kui arenduste kvaliteedi- ja mittefunktsionaalsete nõuete põhidokumenti. Põhidokumendi ja viidatud dokumentide erisuste puhul tuleb lähtuda põhidokumendis kirjeldatust. Põhidokumendis viidatud TEHIK-u poolt koostatud dokumentide ja kolmandate osapoolte poolt koostatud dokumentide erisuste puhul tuleb lähtuda TEHIK-u poolt loodud dokumentides kirjeldatust. Kui mõnda nõuet ei ole võimalik või otstarbekas täita, tuleb selle mittetäitmise fakt ja põhjendus välja tuua pakkumuse esitamisel. Nõudeid tuleb järgida ka olemasolevate infosüsteemide versiooniuuendustel nii palju kui versiooniuuenduse käigus on võimalik. Nõu Koostamis de Nõude sisu Seletused e eest nr. vastutaja Vastavus üldistele standarditele Lahendus peab olema kooskõlas riigi IT koosvõime https://www.mkm.ee/sites/default/files/riigi_it_koosvoime_raamistik.pdf Arendaja 1.1 raamistiku nõuetega. Lahenduse X-tee teenused https://www.ria.ee/ee/xtee-juhendid.html Arendaja 1.2 peavad vastama RIA nõuetele. Lahendus peab vastama Arendaja 1.3 TEHIK-u IT profiilile.  Rakendus peab olema kirjutatud arvestades selle AAMi ISKE turvaklass on K2T3S2. rakenduse poolt Arendaja 1.4 töödeldavatele andmetele https://www.ria.ee/ee/iske-kkk.html määratud ISKE turvaklassi nõudeid. Lahendus peab vastama veebide koosvõime https://www.mkm.ee/sites/default/files/veebide_raamistik.pdf Arendaja 1.5 raamistikule. http://www.w3.org/TR/WCAG20/ Veebirakenduse kasutajaliides peab vastama vähemalt Eesti Pimedate Liidu poolt soovitatud näidised: Arendaja 1.6 WCAG 2.0 tasemele AA. http://kaasav.miljonivaade.eu/ http://www.bbc.com/ Veebipõhine kasutajaliides Valideerimiseks kasutatakse vastavaid validaatoreid: http://validator.w3.org/ peab ühilduma täielikult Kui on tegu olemasoleva süsteemi edasiarendusega, siis tuleb järgida Arendaja 1.7 standarditega vähemalt olemasolevat HTML ja CSS versiooni. eelistatult HTML 5 ja CSS 3 ID-kaardiga allkirjastamisel on Arendaja loodud lahenduse dokumentatsioonis (nt detailanalüüs vms) peab eelistatud veebipõhine Arendaja 1.8 olema välja toodud DigiDoc-teekide versioonid ja kasutuskohad DigiDoc-teenuste kasutamine.  Kui pole arenduse eraldi kokku lepitud teisiti, siis on OWASP ASVS 3.0 tasemeks 2 (https://www.owasp.org/index.php/Category: OWASP_Application_Security_Verification_Standard_Project). Veebirakendus peab Kinnise lähtekoodiga kommertstoote kasutamisel ei eeldata ligipääsu kinnisele probleemideta läbima OWASP Arendaja 1.9 lähtekoodile. Tellija poolset turvatestimist teostab kolmas sõltumatu pool. ASVS baasil põhineva testi Selline esmane kolmanda poole turvatestimine tellitakse tellija finantseeringul. Ilmnenud vigade korral ja peale nende parandamist peab järeltestimise rahaliselt kompenseerima arendaja, kui tellija vastava nõudmise esitab. Krüptoalgoritmide ja räsifunktsioonide kasutamisel tuleb järgida uusimat RIA kodulehel avaldatud Arendaja loodud lahenduse dokumentatsioonis (nt detailanalüüs vms) tuleb krüptograafiliste algoritmide välja tuua kasutatavad krüpto- ja räsialgoritmid, nende võtmepikkused, kasutusvaldkondade ja Arendaja 1.10 kasutuskohad, sh SSL sertifikaatide kasutuskohad. Värskeima uuringu leiab elutsükli uuringut, st aadressilt https://www.ria.ee/ee/kruptouuringud.html lahendustes ei tohi kasutada uuringus väljatoodud ebaturvalisi algoritme ja võtmepikkuseid Andmete edastus peab välisvõrgu liikluses olema kaitstud kasutades turvalisi ja Arendaja 1.11 üldteada andmeedastusprotokolle Infosüsteem peab kasutama Arendaja 1.12 serveri kellaaega ja ajatsooni  Süsteemi edasiarendamisel/loomisel peab arvestama selle Arendaja 1.13 võimaliku laiendamisega nii andmemahtude, kui ka kasutajate arvu osas. Rakendus peab olema tehniliselt tükeldatud Näiteks, kui rakendusel on eraldi turvakontekstidega liidesed ametnikule ja vastavalt loogilisele jaotusele. kodanikule, peab rakendus olema jagatav kaheks eraldi liidesekomponendiks Arendaja 1.14 Saadud osised peavad olema ning nende mõlema poolt kasutatavaks andmebaasiks. eraldi versioneeritavad ja paigaldatavad https://www.mkm.ee/sites/default/files/iseteeninduskeskkondade_raamistik_ 08.07.2015.pdf Avalike e-teenuste loomisel peab arvestama https://www.mkm.ee/sites/default/files/iseteeninduskeskkondade_raamistik_- 1.15 valitsusasutustele kehtestatud Arendaja _kokkuvote.pdf iseteeninduskeskkonna raamistikuga https://www.mkm.ee/sites/default/files/iseteeninduskeskkondade_raamistiku _kasutatavuse_nouded_dets.pdf Nõuded rakenduse arhitektuurile Rakenduse, andmebaasi ja kolmanda osapoole Arendaja loodud lahenduse dokumentatsioonis (nt detailanalüüs vms) peab komponendid peavad olema olema välja toodud kasutatavate komponentide nimetused ja versioonid. Arendaja 2.1 sellised, mille eluea lõpp (EOL) Versiooni eluea lõppu ei loeta võrdseks terve komponendi eluea lõpuks, st pole teadaolevalt vähem kui versiooni tugi võib aeguda, kui uus versioon on välja lastud. kahe aasta pärast.  Tulevase ja olemasolevate infosüsteemide platvormid (rakendusserver, andmebaas, kolmanda osapoole Süsteemi jõudlus peab vastama kokkulepitud topoloogial eelanalüüsi ja 2.2 komponendid) ja topoloogia Arendaja lähteülesande käigus välja toodud jõudlusnäitajatele. peab olema enne reaalse arenduse algust TEHIK-u poolt projekti kaasatud tarkvara arhitektiga kooskõlastatud. Rakendusserver peab võimaldama töötamist - Arendaja 2.3 andmebaasiserverist eraldi serveril. Rakendusserver peab olema vajadusel klasterdatav aktiivklastris (kasutajasessioon - Arendaja 2.4 ei tohi olla klastri node põhine). Rakendust peab saama ilma ümberprogrammeerimata Lahendusse ei tohi olla sisse kompileeritud absoluutseid URI-sid Arendaja 2.5 liigutada erinevate domeenide ja domeeni saitide vahel Rakenduse liidesed peavad Väliste liidestatud süsteemide tõrke korral ei tohi süsteem hanguda, vaid olema tõrkekindlad väljastama mõistliku (võimalikult lühikese) aja jooksul ajakohase veateate. Arendaja 2.6 kolmandate osapoolte Võimalusel tuleb kasutada asünkroonseid liideseid. süsteemide vigade suhtes  Rakenduse Rakendus peab neid sealt ka kasutama (mitte kopeerima parameetreid konfiguratsiooniparameetrid käivitamisel kolmandatesse kohtadesse), logimise seaded võivad olla rakenduse tuleb ühte kohta kokku tuua konfiguratsioonifailist eraldi ühes lisakonfiguratsioonifailis (näit Log4net). nii, et nende muutmisel ei Samuti on väga soovitatav eraldi konfiguratsioonifailis hoida arendaja ja 2.7 peaks rakendust uuesti kokku administraatori vastutusala parameetrid. Infosüsteem peab olema seadistatav Arendaja kompileerima (nt ühte konfiguratsiooniparameetrite(de) abil. Konfiguratsioonifailiks ei saa lugeda faili, tekstipõhisesse kus hoitakse lisaks konfiguratsioonile ka muud programmikoodi. konfiguratsioonifaili, andmebaasi tabelisse). Rakenduse kompileerimine, saidi taaskäivitus, Maksimaalselt 30 sek. Kui rakendus vajab indekseeritud sisu ja see pole konfiguratsiooni muutmine Arendaja 2.8 kättesaadav, siis peab rakendus väljastama selle kohta selge teate vms peaks toimuma mõistliku aja jooksul. Rakendus peab kasutama 64- bitist arvutiarhitektuuri kui ei Suund on 64-bitiste rakenduste op süsteemide kasutamise poole. Arendaja 2.9 ole kokku lepitud teisiti. Kõik andmed, andmebaasid, SQL skriptid ja rakendus peavad kasutama UTF-8 - Arendaja 2.10 kodeeringut. Alternatiivina on kokkuleppel tellijaga lubatud ka UTF-16. Failisüsteemi salvestamisel ei Failid peab katalogiseerima kokkulepitud tunnuste alusel (nt aasta, kuu, tohi ühte kausta tekkida üle Arendaja 2.11 kuupäev). 10000 faili.  Rakenduse loomisel tuleb Eelistuse eiramine tuleb kooskõlastada projektijuhiga enne arendamise eelistada objektorienteeritud Arendaja 2.12 alustamist mudelit Ühest andmetabelist teise viitamisel tuleb kasutada - Arendaja 2.13 väliseid võtmeid (Foreign key). Kõik välised võtmed (Foreign Andmebaasis peab kasutama indekseid või muid meetmeid, et nõuded Key) peavad olema rakenduse jõudlusele oleksid täidetud ka tulevikus. (1, 3, 5 või 10 aasta pärast – Arendaja 2.14 indekseeritud. vastavalt planeeritud kasutusajale). SQL päringute väljakutsumisel väljastpoolt andmebaasi, peab kasutama Tuleb kasutada päringumuutujaid, et vältida SQL vahemälu fragmentseerumist (When calling päringumuutujaid (Parameter Arendaja 2.15 SQL code from outside the database, Parameter Binding should be used to Binding). prevent SQL cache fragmentation) Kõigis andmebaasi tabelites peab olema defineeritud üks primaarvõti. Andmebaasi Kasutada vastava andmebaasisüsteemi nimetamise parimaid praktikaid. Arendaja 2.16 objektide nimetused peavad olema sisulised ja andma aimu nende otstarbest.  Andmebaasis defineeritakse üldjuhul kaks või enam kasutajat:  Rakenduse peakasutaja, kellena luuakse objektid ja Need õigused, mis on vajalikud ainult rakenduse baasi loomiseks, on eraldi skeemid. välja toodud ja tuleb peale installi ära võtta. Ei kehti teiste  Rakenduse piiratud andmebaasisüsteemide korral, seal võib see tekitada mõttetut keerukust. Arendaja 2.17 õigustega kasutaja, Kui lahenduse arhitektuur ei võimalda antud punkti täitmist, tuleb see kokku kellena pöördub leppida TEHIK-u poolt projekti kaasatud tarkvara arhitektiga. rakendusserver/rakend us. Objektide loomiseks vajalikud õigused ja ressursid on loetletud rakenduse dokumentatsioonis. Failide hoidmise asukoht lepitakse igakord kokku. Kuid Failide hoidmine klassikalises andmebaasis on kulukas ja seab kõrgendatud failid ja failide indeks peavad nõudmised ja piirangud andmebaasiserveritele. Lahenduse dokumentatsioonis Arendaja 2.18 olema replikeeritavad teise tuleb ära tuua failide hoidmise asukoht. serveriruumi.  Peab olema minimiseeritud vajadus, et haldur teeb haldustoiminguid otse baasis. St rakendusel peab olema Halduri haldustoimingud lepitakse tellijaga kokku detailanalüüsi käigus. Arendaja 2.19 haldusliides, mille kaudu rakenduse haldur saab teha tavapäraseid haldustoiminguid. Rakendus peab olema võimeline kasutama Näiteks logifailides. Arendaja 2.20 keskkonnamuutujaid (serverinimi, kuu, päev jne). Andmebaas peab toetama nii külm- kui ka kuumvaru Ei tohi kasutada teenuseid, mis välistavad andmebaasi peegeldamist (nt Arendaja 2.21 (peegeldamist) failstream). teise serviruumi. Sorteerimisreeglistik peab olema Eesti tähestikule vastav. Tõusutundlikkus peab olema Näiteks MS SQL puhul Estonian_CI_AS. Arendaja 2.22 välja lülitatud. Accent peab olema sisse lülitatud.  Kui infosüsteemid saadavad e- kirju, peavad nad kasutama välist e-mailiserverit. Kirja Saatja ja adressaadid, pealkiri ja sisu ei tohi olla rakendusse kodeeritud, vaid on saatmisel peab rakendus muudetavad konfiguratsioonifaili kaudu. Genereeritud kirjade puhul peab veenduma, et e-mailiserver Arendaja 2.23 tagama kirjade jälitatavuse (näiteks lisada X-päise kodeeritud kirje, milles on võttis meili vastu. E-kirjade kirjeldatud, mis protsess/skriptifail/kasutaja kirja genereeris jms abistav info). vormindamine peab järgima interneti standardeid (RFC 5322). Konfiguratsiooniparameetrite nimed peavad olema sisulised. Näiteks : X-tee Turvaserver, mitte XTTS või viitenumber, mitte vk_seb jne Arendaja 2.24 Kui see ei ole võimalik, siis peab kõrval olema seletus. Infosüsteemides on Koostöövõime raamistik 2011. Punkt 3.1. Tagasüsteemide ülesanneteks on eessüsteemid (front end; andmete haldamine ja võrguteenuste pakkumine. Tagasüsteemid ei tegele presentatsiooni kiht) ja lõppkasutaja autentimise ja autoriseerimisega. Lõppkasutaja autoriseerimise tagasüsteemid (back end; Arendaja 2.25 tagavad eessüsteemid. Välise süsteemi tõrge tohib mõjutada ainult sellest äriloogika kiht) otseselt sõltuvate kasutuslugude toimimist. Välise süsteemi taastumisel peab arhitektuuriliselt selgelt süsteem olema suuteline oma tööd jätkama taaskäivitamata. lahutatud. Konfiguratsioonifailid peavad olema vastavalt Näiteks IIS: *.config , *.resources Apache: *.conf, .htaccess. Arendaja peab Arendaja 2.26 rakendusserveri tüübile välja tooma konfifailide listi, kui neid on mitu. vaikimisi kaitstud failid Rakenduse failid, mida kasutaja näha ei tohi, peavad Näiteks: IIS: Bin,App_Code, App_Data, App_Browsers, App_GlobalResources, Arendaja 2.27 olema vaikimisi kaitstud App_LocalResources, App_Themes, App_WebReferences kaustades.  Konfiguratsiooniparameetrite taaskasutus. Erinevaid sama Kõiki parameetreid tuleks konfiguratsioonis kirjeldada vaid korra, tuleb vältida Arendaja 2.28 sisuga parameetreid ei tohi korduseid ja kasutada muutujaid vajalikes kohtades. konfiguratsioonis eksisteerida. Kõik rakenduse liidesed Rakendustes tohib kasutada vaid masinapõhiseid teenuseid, mis lubavad peavad olema võimelised kõrgkäideldavaid (klaster) lahendusi. Kõrgkäideldav lahendus on selline, mida Arendaja 2.29 töötama kõrgkäideldavalt. saab samaaegselt käitada erinevates masinates. Klientrakendus ei tohi pöörduda otse andmebaasi Tuleb kasutada rakendusservereid. Arendaja 2.30 poole. Keskkonnapõhised muutujad peavad olema Näiteks WSDL ei tohi sisaldada viiteid arendusserveritele. Arendaja 2.31 konfiguratsioonifailist seadistatavad. Rakenduses peab olema võimalik piirata Eelistama peaks IP-aadressipõhist blokeeringut. Erandina tellijaga kokkuleppel ebaõnnestunud logimisi võib kasutada captchat või konto lukustamist. Blokeeringute ajavahemikku ja Arendaja 2.32 ajaühiku kohta (mobiil-ID, ID- logimiskatsete arvu peab saama konfiguratsioonifailist muuta. kaart, , Smart-ID) ühelt IP- aadressilt. Rakendus ei tohi kasutada meetodeid, mis välistavad .NET rakenduste puhul on suund shared hostingu kasutamise suunas. Arendaja 2.33 shared hostingu kasutamise. Rakenduse äriloogika tuleb realiseerida andmebaasist Andmebaas ei tohi sisaldada äriloogikat, mis muudab andmetabelites Arendaja 2.34 eraldi sõltumatus olevaid/sinna kirjutatavaid andmeid, va trigerid, mis tekitavad logi. rakenduskihis.  Andmebaasis võib kasutada vaid ISO/IEC 9075 standardiga *Ei ole soovitav kasutada mingit platvormispetsiifilist lahendust, mille kaetud funktsionaalsusi. Lisaks üleviimine mõnele muule andmebaasiplatvormile ei ole võimalik. Arendaja 2.35 ei tohi kasutada ka sama *ISO/IEC 9075 osa 13 spetsifitseerib Javas kirjutatud programmimoodulite standardi osas 13 kirjeldatud kasutamist andmebaasis. funktsionaalsusi. Kui rakendus eeldab eraldi kasutajate, rollide ja õiguste TARA info: https://www.ria.ee/ee/tara-autentimisteenus.html registri pidamist, siis peab AAM on keskne autentimis- ja autoriseerimis lahendus. Arendaja 2.36 rakendus kasutama Riigi Kui lahenduse loomisel on näha, et AAM-i kasutamine pole mõttekas, tuleb see autentimisteenust TARA ja kokku leppida TEHIK-u poolt projekti kaasatud tarkvara arhitektiga autoriseerimismoodulit AAM. Uniform resource identifier (URI) pikkus ei tohi ületada Harilikult on piiriks 2000 tähemärki, kuid iga IS puhul tuleb seda eraldi järele ühegi IS poolt toetatava Arendaja 2.37 uurida sõltuvalt IS komponentidest. Asjakohased viited: RFC 3986 ja RFC 7239. brauseri maksimaalset lubatud väärtust. SOAP teenuseid pakkuva rakenduse WSDL peab olema Näiteks: Alajaotis definitions/types/schema: üles ehitatud nii, et see Arendaja 2.38 * complexType defineerimisel tuleb sellele lisada any element. toetaks teenuste versioneerimist. Rakendus peab olema võimeline töötama Vajadusel võimaldama SSL offload-i. Arendaja 2.49 koormusjaoturitega varustatud taristul.  Sidusinfosüsteemide mitte kättesaadavus ei tohi segada rakenduse töötamist. Sidussüsteemi tõrge tohib mõjutada ainult sellest otseselt sõltuvate Sidusinfosüsteemidega kasutuslugude toimimist. Sidussüsteemi taastumisel peab süsteem olema Arendaja 2.40 andmevahetamisel tekkinud suuteline oma tööd jätkama taaskäivitamata. vead logitakse ja kasutajat hoiatatakse. Kui ajastatult käivitatav taustatöö, ei ole mõeldud käima paralleelselt, peab selles olema realiseeritud kontrollmehhanism, mis Arendaja 2.41 tagab, et sama taustatööd ei ole võimalik käivitada uuesti enne, kui eelmisena käivitatud instants on oma töö lõpetanud. Ühe tarkvarakomponendi raames ei tohi sama Näiteks kui rakenduse komponent pöördub andmebaasi või veebiteenuse parameetri seadistamine poole, siis selle pöördumise parameetrid peavad olema muudetavad vaid ühes Arendaja 2.42 toimuda rohkem kui ühes kohas. kohas.  Uue toote arenduse ja olemasolevate infosüsteemide versiooniuuendustel kasutusele võetavate Arendaja 2.43 Tehnoloogiate ja standardite valik tuleb kooskõlastada TEHIK-u poolt projekti kaasatud tarkvara arhitektiga Rakenduse ühenduste (s.h. andmebaasi ja Implementeeritud peab olema vähemalt maksimaalsete ühenduste arvu sidusinfosüsteemide piirang ja päringu aegumise aeg (request timeout). Rakenduse ühenduste tõrge ühendused) realiseerimisel tohib mõjutada ainult sellest otseselt sõltuvate kasutuslugude toimimist. Arendaja 2.44 tuleb kasutada ühenduste Ühenduste taastumisel peab rakendus olema suuteline oma tööd jätkama puulimist (connection taaskäivitamata. Tekkinud vead logitakse ja kasutajat hoiatatakse. pooling). Rakenduse uuendustega kaasnevad andmebaasi 2.45 Näiteks Liquibase või Flyway. Arendaja muudatused tuleb automatiseerida. Turvalisuse tagamisega seotud nõuded Sisemised rakendusliidese autentimised peavad olema lahendatud TARA-ga ja rolli valikul peab arvestama Näiteks: konto on lukus, parool aegunud, konto aegunud, paroolipoliitika jne. Arendaja 3.1 kasutaja kontoga seotud piirnagutega Active directory- s.  Kliendi ja serveri vahel peab autenditud kasutajasessioonide korral - Arendaja 3.2 olema sessioon krüpteeritud HTTPS-protokolli kasutades. SSL veebiserver peab kasutama turvalisi ja SSL/TLS https://www.ssllabs.com/ssltest/ Arendaja 3.3 versioone ja šifrikomplekte Rakendus tohib kasutada vaid sessiooni küpsiseid. Muude - Arendaja 3.4 küpsiste kasutamine on keelatud. St kõik andmemuudatused peavad baasis säilima. Andmete Kui andmebaasis olevate muutmisel andmeid ei kustutata, vaid tehakse uus kirje uute andmetega. Vana andmete ISKE tervikluse muudetakse kehtetuks. Iga uus kirje peab sisaldama järgmist informatsiooni: turvaosaklass on 2 või kõrgem, *viide kirjele, mille ta kehtetuks muutis (kui on) *kasutaja, kes kirje lõi *kirje Arendaja 3.5 siis tuleb kõik klass 2 infot loomise aeg *sessiooni-ID (kui on olemas). Iga kehtetuks tunnistatud kirje peab sisaldavad andmebaasi omama järgmist informatsiooni: *kasutaja, kes kirje kehtetuks tunnistas *kirje kirjed/tabelid versioneerida. kehtetuks tunnistamise aeg. Kui rakenduse poolt töödeldavate andmete konfidentsiaalsuse turvaosaklass on 2 või kõrgem, peab rakendusega kaasas Testandmed peavad säilitama kõik toodangu andmete omadused (pikkuse, Arendaja 3.6 olema lahendus, mis suudab tüübi) ja omavahelised suhted. toota toodangu andmetest testandmed, mis ei sisalda konfidentsiaalset informatsiooni.  Andmebaasis olevate Ei resource, dba, ANY ega muud sellist. Nõude täitmiseks vajalikud vahendid rakenduse kontod peavad (skriptid) peavad kuuluma rakenduse juurde ja nende sisu peab olema omama ainult minimaalselt Arendaja 3.7 kontrollitav. Kontodele vajalikud õigused peavad olema kirjeldatud rakenduse rakenduse tööks vajalikke installijuhendis. õiguseid. Rakendusse ja andmetele tohib olla ligipääs vaid dokumenteeritud ja tellimuses kirjeldatud teid mööda ning St rakendustes ega andmebaasides ei tohi olla ligipääsemiseks teisi võimalusi. Arendaja 3.8 dokumenteeritud autentimisprotseduure kasutades. Rakendus ei tohi teostada X- Kasutajaarvutitest otse X-tee päringute tegemine on arvutivõrgu tasemel kinni. tee päringut otse Rakendusserverist tehtavate päringute teostamiseks on mõistlik kasutada Arendaja 3.9 kasutajaarvutist. vahekomponenti rakendusserveri ja X-tee vahel. Veebipõhised välise veebilehega rakendused, mis IIS puhul peab kasutama näiteks URL scan, apache puhul modsecurity või on keskmise või kõrgema ISKE vastavat tööriista. Lubatud päringud on kõik päringud, mis ei ole detailanalüüsi turbeastmega, peavad Arendaja 3.10 käigus vastavalt kasutusjuhtudele ette nähtud. Kasutama peab whitelisting kasutama vahendeid põhimõtet, mitte blacklisting. kaitsmaks rakendust lubamatute päringute eest.  Kui rakenduse mõni ISKE turvaosaklass on 2 või kõrgem, peab rakendus sisenemisel näitama pärast õnnestunud siss logimist eelmise Kasutaja peab saama soovi korral veenduda, kas keegi pole tema nime all õnnestunud sisse logimise vahepeal sisse loginud. Riikliku autentimismooduli TARA kasutamise puhul Arendaja 3.11 aega. Kui on toimunud tuleb talletada info ka ebaõnnestunud autentimise puhul. ebaõnnestunud sisse logimise katseid, siis peab kuvama ka, millal need toimusid, mitu neid oli ja mis IP-aadressilt pöörduti. Kõigil rakendustel peab olema konfigureeritav Aeg peab olema muudetav koos teiste konfiguratsiooniparameetritega. Arendaja 3.12 kasutajasessiooni aegumise aeg. Järgida tuleb uusimat RIA kodulehel avaldatud krüptograafiliste algoritmide Krüpteerimise ja/või räside kasutusvaldkondade ja elutsükli uuringut. Lubatud on: AES-256, Blowfish-256, arvutamise korral tuleb Arendaja 3.13 RSA-2048, SHA-2, RIPEMD-160 või tugevamaid. Lahenduses tuleb välja tuua kasutada tugevaid algoritme. kõik krüptoalgoritmid, võtmepikkused ja kasutuskohad. Autenditud sessiooni tunnust Sessiooni ei tohi olla võimalik üle võtta sessioonitunnuse kopeerimisega ühest ei tohi ainult lihtsa küpsisega Arendaja 3.14 arvutist teise. lahendada. Tagada tuleb rollide lahusus. Halduritel ei tohi olla võimalik Administraatoril, halduril ja tavakasutajal on erinevad tööülesanded. Arendaja 3.15 muuta ega näha rakenduse Rollide/õiguste kirjeldus peab lähtuma detailanalüüsist ja kasutusjuhtudest. konfiguratsiooni.  Kui kasutajaid hallatakse ka rakenduses, tuleb sisse logimisel kõigepealt Eesmärk vähendada AD ja AAM-i koormust. Arendaja 3.16 kontrollida kasutaja olemasolu rakenduses ja alles siis pöörduda AD või AAM-i poole. Arendus peab olema Toodangukeskkonna rakendus ei tohi sisaldada osiseid, mis toodangu orienteeritud keskkonnas on ebavajalikud või segavad (näiteks kasutuseta funktsionaalsus ja Arendaja 3.17 toodangukeskkonnas komponendid, mõeldud testimiseks testkeskkonnas, arendusabiks toimimiseks. arenduskeskkonnas jne). Rakendus ei tohi lubada ühe kasutajaga mitut samaaegset Juhul kui lähteülesanne spetsiaalselt ei ütle teisiti. Arendaja 3.18 sessiooni. Kui rakenduse tervikluse turvaosaklass on T3, peavad tõestusväärtust omavad Milline lahendus valitakse tuleb kokku leppida tellijaga. Täpsustuseks vt ISKE andmed olema kas Arendaja 3.19 nõue HT.34. Vt ka nõuet 3.28. ajatembeldatud, digiallkirjastatud või digitembeldatud. Kui lahendus peaks kasutama ajatempli teenust, siis tuleks Ajatempli kasutamise vajadus lepitakse eraldi kokku Tellija IT juhiga ja Arendaja 3.20 eelistada Guardtime infoturbejuhiga. See sõltub Tellija keskse ajatempli kasutamise võimalustest. lahendust.  Kui rakenduse tervikluse turvaosaklass on T3, peavad tõestusväärtust omavad Täpsustuseks vt ISKE nõue HT.10. Krüptoahela kasutamise vajadus lepitakse andmed olema eraldi kokku Tellija infrastrktuuri juhiga ja infoturbejuhiga. See sõltub Tellija Arendaja 3.21 krüptoaheldatud, et tagada et keskse krüptoahela kasutamise võimalustest. tõestusväärtusega andmeid ei saaks märkamatult kustutada. Kui rakenduses on S3 salastuse astmega andmeid, peavad need olema nii Täpsustuseks vt ISKE nõue HT.37 . Arendaja 3.22 transpordi ajal ja ka salvestatult alati krüpteeritult. Veebirakendus ei tohi jätta sulgemisel kasutaja tööjaama maha ajutisi faile. Paksu kliendi korral ei tohi Kui paks klient kasutab ajutisi faile, tuleb tagada nende rakendus kasutaja tööjaama perioodiline kustutamine tagamaks, et ei koormata liigselt kasutaja arvutit. jätta maha krüpteerimata Nõude eesmärk on tagada, et rakenduse sulgemisel ei jääks kasutaja arvutisse Arendaja 3.23 kujul ajutisi faile, mis maha informatsiooni, mida sinna jääda ei tohiks, sh pääsuandmeid, sisaldavad või võivad sisaldada isikuandmeid, andmekogu sisulisi andmeid jms konfidentsiaalse või kõrget terviklust nõudvat informatsiooni. Arendaja arendab arenduskeskkonnas ja annab tarne üle tellijale Rakendus ja selle paigalduspakkidena. Tellija paigaldab selle testkeskkonda ja testib ning seejärel komponendid peavad paigaldab tarne toodangu keskkonda. Reaalseid andmekogu andmeid tohib Arendaja 3.24 võimaldama kasutada töödelda üksnes toodangu keskkonnas. keskkondade lahusust Kokkuleppel tellijaga võib antud protsess erineda kirjeldatust mille vajadus tuleneb näiteks konteinerlahenduse kasutamisele võtul.  Krüptograafiat kasutav rakenduskood ei tohi nimeliselt välja kutsuda Rakendus peab võimaldama krüptograafilisi algoritme, vaid peaksid seda tegema vahendavate vaheteekide hõlpsalt välja vahetada kaudu üldiste funktsioonide järgi (nt krüpteerimine, dekrüpteerimine, Arendaja 3.25 aegunud ja ebaturvalise signeerimine, signatuuri verifitseerimine jne). Dokumentatsioon peab krüptoalgoritmi. kajastama üldist kirjeldust, kuidas vajadusel ebaturvaline krüptoalgoritm välja vahetada. Rakenduse andmebaasi Andmebaasides kasutatavad krüpteerimisfunktsioonidest tingitud lisaväljad krüpteerimisega seotud peaksid olema muudetava pikkusega, et formaati muutmata saaks kasutada Arendaja 3.26 andmeväljad peavad olema teistsuguste parameetritega krüpteerimisalgoritme. muudetava pikkusega. Logimine, debuggimine, testimine Testlehe kättesaadavus erinevatest arvutivõrkudest peab olema konfigureeritav. Testleht peab uuendama ennast lehe pärimisel. Testleht peab sisaldama custom built rakenduse versiooni numbrit, standardsed komponendid (veebiserver, andmebaas, CMS'id jms) ei tohi oma versioone Rakendusel peab olema reeta. Samuti peab testlehel olema infot rakenduse (vajadusel tema erinevate masinloetav testleht (JSON, Arendaja 4.1 osade) ja tema kõigi väliste liideste staatuse kohta (töötab, ei XML). tööta). Rakenduse, andmebaasi ja liideste töökorda kontrollitakse testpäringute teel, mis tuleb tellijaga kokku leppida eelanalüüsi käigus. Testleht peab oma konfiguratsiooni võtma rakenduse üldisest konfiguratsioonist (baasistring, välised ühendused). Rakenduse kõik üleantavad versioonid peavad enne Testitulemused tuleb edastada tellijale koos rakenduse üleandmisega. Vaata Arendaja 4.2 tellijale üle andmist olema lisaks nõuet 4.17 ja 4.18. testitud  Rakendus peab logima kasutaja edukat ja ebaedukat autentimist ja sessiooni Logima peab ka autentimise ebaõnnestumise koos põhjusega (vale parool, lõpetamist, kasutaja IP ja aegunud konto jne). Logida tuleks IP-aadress, meetod ja kui võimalik autentimismeetodit (ID-kaart, kasutajatunnus (mobiil-ID puhul telefoni number, ID-kaardi puhul isikukood). Arendaja 4.3 mobiil-ID vms), eduka autendi Kui rakendus kasutab kasutajate autentimiseks AAM-i või TARA, siis leppida puhul tuleks logida ka kasutaja projektijuhiga eraldi kokku autentimise detailsus ehk mis kajastatakse AAM-is isikukood ja mobiil-ID ning või TARA-s ja mis rakenduses. Smart-ID puhul telefoninumber Erinevate logifailide kirjeid peab olema võimalik seotud Näiteks ajatempli või mingi ID abil. Arendaja 4.4 komponentide logidega loogiliselt kokku viia. Rakendus peab suutma logida kõiki X-tee teenuste kaudu liikuvaid andmeid. Peab olema Vajalik eelkõige silumiseks ja toodangu keskkonna probleemide lahendamiseks. Arendaja 4.5 võimalus logimist sisse-välja lülitada. Kui rakenduse ISKE Andmetöötlust peab olema võimalik kokku viia konkreetse kasutajaga ning konfidentsiaalsus sessiooniinfoga. Isikuandmete kaitse seadus §25 lg2 p3: (Isikuandmete töötleja turvaosaklass on 2 või kõrgem, on kohustatud) ära hoidma isikuandmete omavolilist salvestamist, muutmist ja peab rakendus logima kõiki kustutamist ning tagama, et tagantjärele oleks võimalik kindlaks teha, millal, Arendaja 4.6 konfidentsiaalsus klassiga 2 kelle poolt ja milliseid isikuandmeid salvestati, muudeti või kustutati või millal, või kõrgemate andmete kelle poolt ja millistele isikuandmetele andmetöötlussüsteemis juurdepääs loomist, muutmist (sh saadi; kustutamist) ja vaatamist.  Andmetöötlust peab olema võimalik kokku viia konkreetse kasutajaga ning Kui rakenduse ISKE tervikluse sessiooniinfoga. Isikuandmete kaitse seadus §25 lg2 p3:(Isikuandmete töötleja turvaosaklass on 2 või kõrgem on kohustatud) ära hoidma isikuandmete omavolilist salvestamist, muutmist ja peab rakendus logima kustutamist ning tagama, et tagantjärele oleks võimalik kindlaks teha, millal, Arendaja 4.7 kõiki tervikluse klassiga 2 kelle poolt ja milliseid isikuandmeid salvestati, muudeti või kustutati või millal, andmete loomist ja muutmist kelle poolt ja millistele isikuandmetele andmetöötlussüsteemis juurdepääs (sh kustutamist). saadi; Kui rakenduse andmete konfidentsiaalsuse Lahendus peab tagama, et administraatorid/haldurid ei saa andmete vaatamise turvaosaklass on 3, siis ka kõiki logimist ise (ka tavakasutajate logimist) deaktiveerida või logisid administraatorite ja haldurite Arendaja 4.8 kustutada/muuta. Võib tellijaga kokku leppel nõudest loobuda kui andmed on poolt tehtavaid andmete krüpteeritud. vaatamised (ka otse baasis) tuleb logida. Kui rakenduse andmete tervikluse turvaosaklass on 3, Lahendus peab tagama, et administraatorid/haldurid ei saa andmete muutmise siis ka kõiki administraatorite logimist ise (ka tavakasutajate logimist) kinni keerata või logisid Arendaja 4.9 ja haldurite poolt tehtavaid kustutada/muuta. Tellijaga kokkuleppel võib nõudest loobuda, kui andmed on andmete muudatused (ka otse kaitstud digiallkirja, digitempli või välise osapoole ajatempliga. baasis) tuleb logida. Andmete loomise/vaatamise/muutmise Logid peavad asetsema andmetest eraldi andmebaasi failides-andmeruumides, /kustutamise logid peavad et neid oleks võimalik vajadusel lihtsalt andmetest eraldi arhiveerida või anda asuma andmebaasis ja neile nendele ligipääsuks eraldi õiguseid. Kui rakendusel on eraldi liides Arendaja 4.10 on loodud vastav logide administraatorile või peakasutajale, siis seal peab olema eraldi logidega vaatamise liides rakenduse tutvumise võimalus vastavate pääsuõiguste olemasolul. peakasutajale.  Andmebaasi logidest saadetakse reaalajas koopia failisüsteemi logisse ja seal logis peab kajastuma ka Failisüsteemi logide eesmärk on koguda logid ühtesesse logihaldussüsteemi, Arendaja 4.11 logimisfunktsionaalsuse neid krüptoaheldada ja aegtembeldada. aktiveerimise ja deaktiveerimise info (aeg, kasutaja jms) Jõudlustestide täpne kirjeldus tuleb kokku leppida detailanalüüsi käigus. Rakendusega peab olema Arendaja peab koos rakendusega tarnima skripti ja vajalikud tarkvaralised kaasas skript jõudlustestide vahendid kokkulepitud jõudlustestide läbiviimiseks. Jõudlustestide läbiviimine Arendaja 4.12 tegemiseks. ei tohi nõuda tellijalt omapoolset tarkvara arendamist, skriptide kirjutamist või litsentside ostmist. Logi sisaldab minimaalselt vea tekkimise aega, veakoodi, veakirjeldust (stack Rakendus peab logima kõiki trace, traceback vms), võimalusel kasutaja andmeid, HTTP-, GET- ja POST- rakenduses tekkivaid tehnilisi Arendaja 4.13 parameetrid ja nende väärtusi. Logimise detailsusrežiimi (info, warning, errog, vigu. debug) peab saama muuta. Vea ja süsteemilogid peavad olema vähemalt failisüsteemi Kui logitakse mitmesse kohta, siis vajadusel peab saama ühte või teise kohta tekstifailis üldtuntud logimist välja lülitada. Logi peab olema lihtsalt masintöödeldav ja tuntud Arendaja 4.14 vormingus, lisaks võib ka vormingus. Näiteks syslog, syslog-ng, XML, CSV. andmebaasis hoida.  Failisüsteemi logimise korral peavad logid olema ka katalogiseeritud (näiteks kuupäeva või liigi järgi) ja üldtunnustatud faililaiendiga (näiteks .log, .txt, .xml), logi peab olema roteeruv, et ei Ei tohi esinda olukorda, kus ühte kausta tekib rohkem kui 1000 faili. Arendaja 4.15 tekiks liiga suuri faile (nt 5MB). Logifailide seadistamisel peab olema failinime/kaustatee nimedes võimalik kasutada keskkonnamuutujaid (kuupäev, masinanimi jne). Logimisparameetreid peab 4.16 saama muuta rakendust Näiteks log4j konfiguratsiooni failis "monitoring-interval". Arendaja taaskäivitamata. Arhitektuuriline lahendus peab olema 75% ulatuses 4.17 Arendaja kaetud komponenditestidega (unit test). Arhitektuuriline lahendus 4.18 peab olema 50% ulatuses Arendaja kaetud vastuvõtutestidega. Nõuded rakenduse lähtekoodile  Lähtekoodi kommentaarid NB! Nõuet ei arvestata arendustarkvara poolt automaatselt genereeritavate peavad kõigis lahenduse koodilõikude puhul – neid ei ole vaja tõlkida. Samuti ei rakendata nõuet kihtides (rakenduse enda kolmandate osapoolte poolt toodetud lähtekoodile – nt igasugu erinevad kood, andmebaas, jne) olema Arendaja 5.1 lahtise koodiga koodilõigud jms. Kui on tegu olemasoleva süsteemi kirjutatud eelistatult inglise edasiarendusega, siis peaks kommentaarides kasutama eelnevalt kasutatud keeles, vähem eelistatud keelt. alternatiivina eesti keeles. Lähtekoodi kommentaarid peavad olema selged, arusaadavad ja sisuliselt Rakenduse kood peab olema piisavalt hästi kommenteeritud, et erialast kirjeldama vastavat koodi, haridust omav tarkvaraarendaja on võimeline süsteemile jätkuarendusi Arendaja 5.2 mille juures nad on ning teostama. moodustama vähemalt 20% koodi mahust. Muutujate, tüüpide ja funktsioonide nimed peavad Parim praktika Arendaja 5.3 olema sisulised ja andma aimu nende otstarbest. Koodis kasutatavad konstandid ja lühendid tuleb Parim praktika. Nt Identifikaator --> ID Arendaja 5.4 kirjutada suurte tähtedega. Koodis kasutatavaid konstante ei tohi selle kasutamise kohta väärtusena hardcodeda – - Arendaja 5.5 need tuleb defineerida muutujatena ja kasutada läbi nende.  Koodis defineeritud andmetüübid peavad olema nimetava käände ainsuses. N:Isik; Menetlus; jne. Andmebaaside struktuurikirjeldustes/andmemudelis ei Kõik andmemassiivid tuleb Arendaja 5.6 tohi kasutada täpitähti. nimetada nimetava mitmuses (st igasugu collectionid, arrayd, jms). Andmetabelites sisalduvad Kasutada tuleb konkreetse andmebaasisüsteemi nimetamise parimaid võõrvõtmed peavad nime järgi praktikaid. Nt kui on tegu tabelitega ’Isikud’ ja ’Autod’, siis seos ’isiku autod’ Arendaja 5.7 seostuma tabeli ja väljaga oleks: Isikud.ID=Autod.Isik_ID millele need viitavad. Andmebaasi väljade pikkused Selle asemel, et eraldada väljale x baiti, tuleb eraldada x tähemärki. (Instead of tuleb kirjeldada sümbolites, Arendaja 5.8 allocating x bytes of storage for the field, x chars of storage must be allocated). mitte baitides. Kui kokku pole lepitud teisiti, siis JAVA rakenduse kood peab Checkstyle (http://checkstyle.sourceforge.net/) ei tohi käivitamisel järgmise olema kirjutatud Arendaja 5.9 konfiguratsioonifailiga väljastada ühtegi viga. vastavalt "Oracle Java Code convention" dokumendile. Kui kokku pole lepitud teisiti, siis Python rakenduse kood peab olema kirjutatud http://www.python.org/dev/peps/pep-0008/ Arendaja 5.10 vastavalt "Style Guide for Python Code " dokumendile  Kui kokku pole lepitud teisiti, siis .NET rakenduse kood peab olema kirjutatud vastavalt http://msdn.microsoft.com/en-us/library/ms229042.aspx Valideerimiseks Arendaja 5.11 "NET Framework Developer's kasutatakse 'StyleCop' vaikimisi konfiguratsiooni Guide - Design Guidelines for Developing Class Libraries". 1. PMD (http://pmd.sourceforge.net/) reeglistikud „Basic Rules“, „Import Statement Rules“, „Security Code Guidelines“ ja „Unused Code Rules“ ei tohi JAVA koodi valideerimiseks väljastada ühtegi viga. Arendaja 5.12 kasutatakse: 2. DocCheck(http://java.sun.com/j2se/javadoc/doccheck/) 3. Findbugs (http://findbugs.sourceforge.net/) TEHIK-u poolt kirjeldatud reeglistikus “Java koodi kvaliteedi nõuded.zip” ei tohi väljastada vigu. .NET koodi valideerimiseks FxCop (http://msdn.microsoft.com/en-us/library/bb429476.aspx) Arendaja 5.13 kasutatakse: Pythoni koodi valideerimiseks Pychecker(http://pychecker.sourceforge.net/) Arendaja 5.14 kasutatakse: TEHIK-us on automaatseks koodivalideerimiseks kasutusel SonarQube (https://www.sonarqube.org/). Ennem üleandmist tuleb veenduda, et koodis puuduvad: Automaatne 5.15 1. Turbedefektid koodivalideerimine 2. Blokeerivad ja kriitilised vead Mõistlik on koodivalideerimine automatiseerida Gitlabi või Jenkinsi abil. Sõltub milline lahendus on projektis kasutusel. Kasutuses mitteolev kood tuleb rakenduse lähtekoodist - Arendaja 5.16 kõrvaldada.  Arendamisel kasutatakse DRY http://en.wikipedia.org/wiki/Don%27t_repeat_yourself Arendaja 5.17 ja SOLID printsiipe http://en.wikipedia.org/wiki/SOLID_(object-oriented_design) Üleantavas koodis ei tohi olla Kehtib ka siis, kui need on välja kommenteeritud. Kõik sellised paroolid tuleb paroole, mida on kasutatud Arendaja 5.18 asendada fraasiga “<password>“. arenduse käigus Rakenduste lähtekoodi tasemel ei tohi olla ühtegi Eelpoolmainitu haldamine toimub failis või andmebaasis. Arendaja 5.19 sisse kodeeritud parameetrit, väljade nimetust, veateadet. Andmekvaliteet ja standardid Aadressiandmete sisestamisel, kuvamisel ja hoidmisel tuleb Liidestatakse Maa-ameti X-tee teenusega. lähtuda Vabariigi Valitsuse Arendaja 6.1 määrusest "Aadressiandmete https://www.riigiteataja.ee/akt/103102017005?leiaKehtiv süsteem". Rakendus peab võimalikult palju informatsiooni eeltäitma automaatselt (kirje Välja arvatud logimisvormi lahtrid autentimisel Arendaja 6.2 sisestamise kuupäev, kasutaja nimi jne).  Tegevusalade andmete sisestamisel, kuvamisel ja hoidmisel tuleb lähtuda Vabariigi Valitsuse 10. Jaanuari 2008. a määrusest nr - Arendaja 6.3 11 "Klassifikaatorite süsteem" ja kasutada EMTAK infosüsteemis kehtivat klassifikaatorit. Tervishoiuteenuste osutajate andmete kasutamisel peab kontrollima nende andmeid, Liidestatakse Terviseameti X-tee teenusega Arendaja 6.4 sh tegevuslubade kehtivust Terviseameti Tegevuslubade registrist Tervishoiutöötajate andmete kasutamisel peab kontrollima Liidestatakse Terviseameti X-tee teenusega Arendaja 6.5 nende andmeid Terviseameti tervishoiutöötajate registrist Meditsiiniandmete vahetamiseks tuleb kasutada www.hl7.org Vajadusel on lubatud ka teiste standardite kasutamine, kuid see meditsiiniandmete Arendaja 6.6 tuleb tellijaga eraldi kokku leppida andmevahetuse standardit HL7 Tervise valdkonna Võimalusel tuleb kasutada olemasolevaid OID-e ja klassifikaatoreid, mida klassifikaatorid peavad olema Arendaja/T vajadusel täiendatakse või luuakse uued ning publitseeritakse samuti 6.7 kooskõlas Tellija OID-ide ja ellija publitseerimiskeskuses http://pub.e-tervis.ee publitseerimiskeskusega Kasutajaliides Kasutajaliidese kõik disainiotsused peavad olema - Arendaja 7.1 kooskõlastatud tellijaga enne nende realiseerimist Veebipõhine kasutajaliides peab olema kasutatav Minimaalselt Internet Explorer, Mozilla Firefox, Chrome ja Safari arenduse enamlevinud testimise hetkel tootja poolt toetatud versioonid. Täpsemad nõuded on välja Arendaja 7.2 veebibrauseritega, sh toodud Tehnilise kirjelduse Lisas 1.3 Front-end arendusreeglid. nutiseadmetel (Android, IOS, Windows Phone) Rakenduse värviskeem ja logo kasutamine peab vastama Kui tegemist on struktuurfondide projektiga on lisaks nõutud ka vastav SF Tellija ametlikule visuaalsele sümboolika. Tellija ametlikud CVI esitluspõhjad, logo kasutusjuhend ja kõik Arendaja 7.3 identiteedile (CVI) ja logod (ka jpg-na) küsida tellijalt. disainijuhistele (UIG). Kasutajaliidese kõik osad ja Kui soovitakse juurde eraldi ka muid keeli, siis see on spetsifitseeritud teated peavad olema eesti-, Arendaja 7.4 hankedokumentides vene- ja inglisekeelsed. Lahenduse esitluskiht peab Toetatud peavad olema vähemalt resolutsioonid: 2560x1440, 1920x1200, olema graafiliselt eskaleeruv 1920x1080, 1680x1050, 1600x1200, 1440x900, 1366x768, 1360x768, ja mugavalt kasutatav kõigi 1280x1024, 1280x960, 1280x800, 1280x768, 1152x864, 1024x768, 1024x600, Arendaja 7.5 enamlevinud seadmete 768x1024, 720x1280, 375x667, 360x640, 320x480. Ühegi nimetatud resolutsioonidega. resolutsiooni korral ei tohi tekkida horisontaalset kerimisriba. Hüpikaknaid (pop-up) ei tohi Silmas on peetud uusi veebilehitseja aknaid avavaid hüpikaknaid Arendaja 7.6 kasutada.  Kasutajaliideses toiminguni Kõik rakenduse kasutajaliidesest tehtavad toimingud tohivad üksteisest olla (põhi- ehk enamkasutatavad maksimaalselt 3 hiirekliki kaugusel. Toimingut ei pea nende 3 klikiga tehtud tegevused) navigeerimiseks Arendaja 7.7 saama. Väljalogimise nupp/link peab olema ühe kliki kaugusel ja peab kehtima 3 kliki printsiip, arusaadavas/intuitiivses kohas. väljalogimiseks 1 kliki printsiip. Kasutajaliides peab alati küsima kinnituse andmete kustutamise ja - Arendaja 7.8 massmuutmiste kohta kui pole kokku lepitud teisiti. Rakenduse kasutamisel tekkinud veale peab kasutajaliides vastama kasutajale kasutajasõbraliku Veateated peavad olema sellised, mis võimaldavad IT-abil võimalikult lihtsalt veateatega, mis sisaldab Arendaja 7.9 tuvastada vea olemuse ja asukoha. soovituslikult ka vea koodi. Teade peab olema kasutaja poolt lahendust kasutatavas keeles. Kasutajaliides peab olema ilma rakenduse koodi muutmata Uue keele lisamine peab olema teostatav konfiguratsiooni failist või Arendaja 7.10 tõlgitav teise keelde, v.a kui ei administreerimisliidesest. ole kokkulepitud teisiti. Rakenduse tausta, menüüde ja teksti värvid peavad olema - Arendaja 7.11 ilma rakenduse koodi muutmata vahetatavad.  Rakenduse kasutajaliides peab teavitama kasutajat ette Ette teavitamise aeg peab olema konfigureeritav. Arendaja 7.12 sessioon aegumisest. Kui vormile sisestatakse mahukaid andmevälju peab kasutajaliides kokku lepitud ajavahemike järel salvestama Kui vorm koosneb paljudest väiksest andmeväljadest (nt taotlus), siis jagatakse Arendaja 7.13 välja sisu, et sessiooni vorm etappideks ning salvestatakse vastava etapi lõpus. aegumisel või võrgu katkestuse korral juba sisestatud andmed ei kaoks. Sisestusvormidel andmete sisestamisel peab saama väljade vahel vastavalt - Arendaja 7.14 äriloogikale liikuda klaviatuuri abil tabulaatoriga. Interaktiivsete vormide puhul (näiteks faili üleslaadimine), ei tohiks lehe värskendamisega - Arendaja 7.15 tegevust korrata (faili taas üles laadida, andmeid saata, avaldust esitada). Kui päring võtab aega kauem kui 3 sekundit, peab kasutaja Ikoon peab muutuma liivakellaks ja/või kuvatakse teade: päringut sooritatakse saama visuaalse teate, et Arendaja 7.16 või muu tellijaga kokkulepitud indikaator. süsteem tegeleb päringu läbiviimisega.  Esilehel (sisse logimata) ja ka pärast kasutaja sisse logimist peab olema lihtne võimalus teavitada kasutajat (sisse loginud kasutaja puhul ka vastavalt tema rollile või Näiteks võimalikud teavituses: mingi süsteemi osa on vigane, tuli mingi uus Arendaja 7.17 temaga seotud ettevõtte funktsionaalsus, vahetage oma parool, uuendage isikuandmeid jne. tegevusalale) muudatustest või probleemidest. Teavitus peab olema halduri poolt lihtsalt lisatav ja olema kasutajale märgatav. Infosüsteem peab funktsionaalse vea (näiteks kohustuslikkude väljade täitamata jätmisel) korral Arendaja 7.18 kasutajale kuvama kasutajasõbraliku veateate. Veateated peavad olema hallatavad. Päringu vastusena kuvatud tabeli veerge on võimalik Arendaja 7.19 andmete/teksti tähestikulises järjekorras sorteerida. Andmeväljade kohustuslikkus peab olema infosüsteemi Võib olla mõni muu viis, mis on tellija poolt soovitud. Arendaja 7.20 väljadel märgitud tärniga (*).  Rakenduse andmeväljade mõisted peavad olema üheselt identifitseeritavad, korrektses keeles (ilma kirjavigadeta) ja vajadusel sisaldama selgitavat Arendaja 7.21 teksti. Abiinfo (kasutusjuhendid) peab olema kättesaadav rakenduse toimimise erinevatel etappidel. Kasutajaliides peab vastama ka dokumendis "Front-end Täpsemad nõuded on välja toodud Tehnilise kirjelduse Lisas 1.3 Front-end 7.22 arendusreeglid" kirjeldatud arendusreeglid. reeglitele Dokumentatsioon Erandiks võivad olla kolmanda osapoole komponentide (mis pole kirjutatud Kogu rakenduse tellija jaoks) dokumentatsioon. Samuti võib erandiks olla välispooltega seotud dokumentatsioon peab olema Arendaja 8.1 projektid. Erandid tuleb kooskõlastada tellijaga enne dokumentatsiooni kirjutatud eesti keeles. koostamist Arendaja / Projektijuh Lahendus kirjeldatakse RIHA https://www.riigiteataja.ee/akt/12933746?leiaKehtiv#para6 t / Tellija 8.2 määruse nõuete kohaselt. RIHA haldur  Rakenduse dokumentatsioon peab sisaldama paigaldusjuhiseid, varundatavate komponentide kirjeldust, kasutajate kasutusjuhendeid, Dokumentatsioon peab olema versioneeritud, muutmiskuupäevadega, autori peakasutajate ja nimedega, korrektse keelekasutusega, selge struktuuriga. Dokumentatsiooni administraatorite detailsus peab olema piisav, et sõltumatu kolmas tehniliste IT baasteadmistega Arendaja 8.3 kasutusjuhendeid, isik suudaks dokumendist vajalikke järeldusi teha (st dokument peab olema andmemudeleid, arusaadav sellele isikule, kuid näiteks paigaldusjuhise järgi toimetades ei pea ta arhitektuurilisi mudeleid, ebaõnnestunud tarnele teostama veaanalüüsi). süsteemitehnilisi kirjeldusi, nõudeid riistavarale, krüptoalgoritme ja võtmepikkuseid, SSL sertifikaatide kasutuskohti jms Rakenduse dokumentatsioon peab sisaldama tabelite-andmete- logide mahu kasvu Esialgne kirjete mahu hinnang peab tulema lähteülesandest, ning täpsustuma arvestuslikku hinnangut eel ja detailanalüüsi käigus. Mahuhinnang peab sisaldama ka logide säilitamise, Arendaja 8.4 rakenduse sihipärase arhiveerimise tähtaegu. kasutamise korral ettenähtud arvu kasutajate poolt. (MB/GB kuus/aastas). Iga uue versiooniga peab alati välja tooma versiooni Release notes peab kajastama kõiki muudatusi eelmise ja uue versiooni vahel. Arendaja 8.5 muudatuse kirjeldused (release notes).  Rakenduse dokumentatsioon peab vastama ka dokumendis Täpsemad nõuded on välja toodud Tehnilise kirjelduse Lisas 1.2.1 Nõuded "Nõuded infosüsteemi Arendaja 8.6 infosüsteemi dokumentatsioonile. dokumentatsioonile" kirjeldatud nõuetele Versioonihaldus Kõik rakenduse testimiseks, koolituseks või implementeerimiseks üle Arendajale antakse selleks õigused Tellija versioonihalduse repositooriumi, kus antavad tarkvarapaketid ta peab hoidma oma erinevaid versioone. Versioonihalduse repositooriumi Arendaja 9.1 peavad olema versioneeritud. juurdepääsutaotlus esitatakse Tellija kasutajatoele läbi projektijuhi Kasutama peab Tellija versioonihalduse repositooriumi. Arendaja peab veenduma, et teeb muudatusi aktuaalsesse koodi. Ehk paralleelse arendamise puhul võetakse - Arendaja 9.2 igal hommikul versioonihalduse repositooriumist viimane seis koodist. Paigalduspaketile koostatakse kontrollkood (checksum), mis Räsialgoritmiks tuleb kasutada SHA256. Linuxi käsurealt kontrollkoodi Arendaja 9.3 pannakse eraldi .sum failina koostamiseks: $ sha256sum filename [filename2] ... > kontrollkood.sum tarnele kaasa.  Kõik rakenduste tellijale lepingujärgsete üleantavate Ka tagant järgi peab olema 100% kindel, et üle anti õige arendaja signeeritud, versioonide lähtekoodid mitte kolmanda osapoole poolt kompromiteeritud versioon. Mahuka Arendaja 9.4 peavad olema varustatud lähtekoodi asemel võib signeerida paigalduspaki kontrollkoodi. arendaja esindaja digiallkirjaga. Nii arendamisel kui ka hoolduslepingute korral Arendajale antakse selleks õigused Tellija veahalduse keskkonda. Arendaja 9.5 kasutatakse Tellija veahalduse Juurdepääsutaotlus esitatakse Tellija kasutajatoele läbi projektijuhi keskkonda. Paigalduspaketi kooste Näiteks võib lahenduse paigalduspaketi koosteprotsess ette näha, et käivitada Tarnitava lahenduse tuleb rida shell-käske või võivad lahenduse koosseisus olla valmis (ant, ..) koosseisus üle antava koosteskriptid või mis iganes muu moodus paigalduspaketi tekitamiseks. lähtekoodiga peavad kaasas Arendaja 10.1 olema kirjeldused sellest Eelistatud on kasutada GitLabi pipeline või Jenkins skripte/Jenkinsfile, sõltuvat paigalduspaketi koosteks. kasutatavast lahendusest. Kooste kirjelduste alusel valmiv paigalduspakett tohib Näiteks: kompileeritavate keelte puhul ei tohi sisaldada lähtekoodi, kui see pole sisaldada ainult minimaalse Arendaja 10.2 vajalik rakenduse käitamiseks. rakenduse käitamiseks vajamineva failikomplekti. Kooste kirjelduste alusel valmivat paigalduspaketti Näiteks ei tohi tekitada olukorda, kus rakenduse jooksutamiseks uues serveris Arendaja 10.3 peab olema võimalik liigutada tuleb see tingimata just sealsamas kokku kompileerida. erinevate masinate vahel.  Lähtekoodi kompileerimine peab olema teostatav ka Kasutada tuleb tellija poolset Artifactorit. Arendaja 10.4 võrguühenduse puudumise korral. Andmebaasi paigalduse skriptid ei tohi olla Administraator tahab veenduda skripti sisus. Arendaja 10.5 kompileeritud.  Lisa 1 Tehniline kirjeldus 1. Hanke eesmärk Hanke eesmärk on leida Tervise infosüsteemi ühtse kasutajate ja kasutajagruppide halduskeskkonna ehk autentimis- ja autoriseerimismooduli (edaspidi veebirakendus) (https://ssoadmin.digilugu.ee/admin/aam/Aam.faces ) arendus- ja veaparandustööde teostaja, et oleks tagatud veebirakenduse kiire ja kvaliteetne toimimine. 2. Hankelepingu eseme kirjeldus ja maht Tervise Infosüsteem (edaspidi TIS) on TEHIKu infosüsteem, kus säilitatakse riiklikul tasandil keskselt turvalisel viisil tervishoiuteenuse osutaja poolt koostatud ja edastatud elektroonilisi meditsiinidokumente. Tervishoiuteenuse osutajatel on võimalik üle X-tee TISi elektroonilisi meditsiinidokumente edastada ja isikupõhiselt pärida, kui päringut teostaval tervishoiuteenuse osutajal on vastava isikuga ravisuhe. Augustist 2013 on kasutusel TIS kasutajate ja kasutajagruppide halduskeskkond ehk autentimis- ja autoriseerimismoodul. Halduskeskkond on loodud kasutajate õiguste halduse ühtlustamiseks ning kasutajate efektiivse ja turvalise administreerimise toetamiseks. Halduskeskkond võimaldab autentida nii X-tee põhiste süsteemide kasutajaid, kui ka standardsete (autentimise) protokollide abil loodud lahenduste kasutajaid, samuti vähendada kasutajate ja kasutajagruppide haldamisega seotud hoolduskulusid. Autentimis- ja autoriseerimismoodulit kasutakse kõigis TISiga seotud süsteemides. Autentimis- ja autoriseerimismooduli arendamisel kasutatakse Java 8, Centos 7, TomCat 8.5, PostgreSQL 10 või nende uuendatud versioone. Hanke esemeks on autentimis- ja autoriseerimismooduli arendustega seotud tööd, sh veaparandustest tulenevad arendustööd ja nendega seotud konsultatsioonid ja koolitused. Hanke raames osutatavaid teenuseid ostetakse kolme aasta jooksul (36 kuud) hankelepingu sõlmimisest arvates, maksimaalselt 59 999 euro ulatuses. Töid tellitakse vastavalt vajadusele, mistõttu tellija ei garanteeri tööde tellimist maksimaalses mahus. Tööde eest tasumine toimub tunnitasu alusel. Tellija tellib hankelepingu alusel: - arendustöid Tellimuse alusel; - veaparandusi ja veaparandustest tulenevaid arendustöid; - sh arendus-ja veaparandustöödega seotud konsultatsiooni ja koolitusteenuseid. Arendus- ja veaparandustööde teostamine peab toimuma vastavalt punktis 4 kirjeldatud tööde spetsifikatsioonile. 3. Nõuded täitja meeskonnale 3.1 Hankelepingu täitmiseks peab Täitjal olema võimalik komplekteerida riigihanke vastavustingimustele vastav vähemalt 3-liikmeline meeskond järgmistes rollides: a) projektijuht, kes koordineerib Täitja poolt arendus- ja veaparandustööde teostamist ja dokumenteerimist ning pakub nende ettevalmistamisel konsultatsioone ning koolitusi. On Tellijale kontaktisikuks tööde teostamise ning üleandmise käigus; b) programmeerija, kes teostab Täitja poolt arendus- ja veaparandustöid ning vastavalt kokkuleppele pakub Tellijale tööde ettevalmistamisel ja/või teostamise järgselt konsultatsioone ning koolitusi;  c) testija, kes teostab tehtud töödele testimisi, koostab testimistega seonduva dokumentatsiooni ning vastavalt kokkuleppele pakub Tellijale tööde ettevalmistamisel ja/või teostamise järgselt konsultatsioone ning koolitusi. 3.2 Meeskonna liikmed peavad vastavalt riigihankes esitatud tingimustele vastama järgmistele nõuetele: a) Projektijuhil peab olema: - Vähemalt 1 aasta IT-valdkonna projekti juhtimise kogemust. b) Programmeerijal peab olema: - PostgreSQL või samaväärse andmebaasi rakendamise kogemus arendusprojektides; - vähemalt 3 aastat Java platvormil põhinevate rakenduste arendamise kogemust sh: i. Veebipõhiste, sh autoriseerimist nõudvate rakenduste arendamine; ii. X-tee teenuste loomine kasutades SOAP protokolli; iii. Tomcat või samaväärsel rakendusserveril arendamine. c) Testijal peab olema: - vähemalt 2 aastat töökogemust testijana tarkvara arendusprojektides. 3.3 Täitja tagab kogu Lepingu perioodil Tööde teostajate isikkoosseisu vastavalt pakkumuses esitatud meeskonnale ja nende rollidele. Meeskonnaliikmete vahetumine lepingu täitmise perioodil on lubatud Täitjast mittesõltuval asjaolul üksnes võrdväärse kogemuse ja kvalifikatsiooniga isikuga. Meeskonnaliikme vahetus lepitakse Tellijaga kokku eelnevalt kirjalikku taasesitamist võimaldavas vormis. 4. Tööde spetsifikatsioon Mõisted 4.1 Veebirakendus on TIS juurde kuuluv autentimis- ja autoriseerimismoodul s.h. Tellija juures asuv tootmis-, pre-live ja testkeskkond ning Täitja juures asuv arenduskeskkond. 4.2 Tarkvara tähistab baastarkvara või tarkvaraplatvormi. Minimaalselt peab olema arenduskeskkonnas tagatud järgnev (lähtudes testkeskkonna parameetritest): Andmebaasi op-süsteem: Linux CentOS; Andmebaas: PostgreSQL 10 (tuleb kasutada TEHIK-u andmebaasiserverit teenusena) Rakendusserveri op-süsteem: Linux CentOS; Veebiserver: Apache Tomcat (selle ees eraldiseisev koormusjaotur NGINX); Programne liides : WSO2 ESB; Apache Tomcat ja WSO2 ESB vajavad JAVA-t. 4.3 Teenindusaeg ehk tööaeg on igal tööpäeval alates 08:00 kuni 17:00, v.a riiklikud pühad. Teenindusaeg on lühendatud vastavalt seadusele pühade-eelsetel päevadel. Teenindusajal tagab Täitja valmisoleku Tellija konsulteerimiseks veebirakendusega seotud küsimustes. 4.4 Lahendusaeg tähendab perioodi tööajal, mille jooksul Täitja on kohustatud parandama vea, teostama arendustöö ning täitma muud garantiist tulenevad kohustused (maksimaalsed veaparandustööde lahendusajad on toodud punktis 6.5). 4.5 Tööde halduskeskkond on Tellija keskkonnas asuv rakenduse vigade ja arenduste haldamiseks kasutusel olev rakendus (näiteks Jira), mis lepitakse kokku Poolte vahel hankelepingu täitmisel käigus. 4.6 Tellimus on Tellija poolt Täitjale esitatav kirjalik pöördumine töö(de) teostamiseks. Tellimused esitatakse tellimusvormil, mille kehtestab Tellija hankelepingu täitmise  käigus. 4.7 Veaparandus on rakenduse kasutamise ja funktsioneerimise tagamisega seotud töö, mis on tööde halduskeskkonnas fikseeritud ja mille teostamise on Tellija eelnevalt Täitjale täitmiseks suunanud. 4.8 Arendustöö on rakenduse kasutamise ja funktsioneerimise tagamisega või rakenduse uue funktsionaalsuse lisamisega seotud töö ning sellega seotud töö, mis on eelnevalt Tellija ja Täitja poolt kokku lepitud ja kirjaliku Tellimusega kinnitatud. 4.9 Tarne on Tellimuse alusel teostatud töö üleandmine tarneteatise esitamisega Tellijale. Tarneteatise vormi kehtestab Tellija hankelepingu täitmise käigus. Tarneteatised salvestatakse koodihalduskeskkonnas. 4.10 Dokumendihalduskeskkond on Tellija keskkonnas asuv dokumentide haldamiseks kasutusel olev rakendus (näiteks Confluence), mis lepitakse kokku Poolte vahel hankelepingu täitmisel käigus. 4.11 Dokumentatsioon on lahenduse oluline osa. Dokumentatsiooni hulka kuulub kasutusjuhend, administreerimisjuhend, konfiguratsioonijuhendid, integratsioonijuhend, varundamise- ja taasteplaan, paigaldusjuhend, andmemudel, komponendi mudel ja RIHAle vajalikul kujul teostatud või muudetud dokumentatsioon. 4.12 Koodihalduskeskkond on Tellija keskkonnas asuv rakendus (näiteks GitLab) paigaldusjuhendite, lähtekoodide, konfiguratsioonide, skriptide jmt. haldamiseks, mis lepitakse kokku Poolte vahel lepingu täitmise käigus 5. Veebirakenduse arendustööde teostamine 5.1 Täitja pakub Tellijale arendustöid ja arendustega seonduvaid töid, mis tulenevad veebirakenduse vea ilmnemisel, täiendava funktsionaalsuse vajaduse ilmnemisel vms põhjusel, mis on vajalikud veebirakenduse kasutamiseks ja funktsioneerimiseks. 5.2 Tellija tagab ligipääsu vajalikele keskkondadele ja vajadusel omapoolse abi. Ligipääsu tehnilised tingimused jms täpsustatakse Tööde teostamise käigus. 5.3 Tellija teavitab Täitjat arendustöö vajadusest, esitades arendustöö teostamiseks Tellimuse. Tellimuses on kirjas oodatava töö kirjeldus vajadusel koos töö kriitilisuse astmega. Enne töö teostamist lepitakse kokku töö maht, vajadusel etapid, töö teostamise aeg ja vajadusel muud tingimused. Veaparandustööde tellimused esitatakse üldjuhul tööde halduskeskkonna kaudu. 5.4 Täitja hindab töö teostamise mahtu ning esitab töömahu hinnangu Tellijale. Kui töö maht ületab 20 töötundi, tuleb Tellimus enne töödega alustamist mõlemapoolselt allkirjastada. 5.5 Arendustööga võib Täitja alustada pärast Tellimuse kahepoolset allkirjastamist. 5.6 Arendustööd teostatakse arvestades Tellija poolt esitatud arendusnõudeid. 5.7 Kõigi Tööde tulemused dokumenteeritakse ja hallatakse Tellija dokumendihaldussüsteemis või/ja koodihaldussüsteemis. Dokumendihaldussüsteemis ja koodihaldussüsteemis fikseeritakse muuhulgas ka Töö üleandmise aeg (hetk), milleks on Töö nõuetekohaseks teostamiseks vajaliku viimase dokumendi salvestamise aeg (üldjuhul tarneteatis). Kui Töö on jagatud etappideks, annab Täitja etappide tulemused Tellijale üle vastavalt Tellimuses kokkulepitud etappide tähtaegadele. 5.8 Töödele lisatud või Tööde käigus loodud dokumentatsioon peab olema eesti keelne ja terviklik, vastama Töödele, sisaldama muudatusi ja olema terminoloogiliselt üheselt mõistetav ning detailne vastavalt Tellija suunistele, et Tellija saaks käesoleva teostatud Töid kasutada, hooldada ja kohandada, täiendades juba olemas olevat dokumentatsiooni või koostades vajadusel uue dokumentatsiooni. 5.9 Tööd tuleb Täitja poolt enne Tellijale üle andmist testida, koostada testiraportid ja testilood ning tegevused dokumenteerida. Tarne antakse üle paigaldatava paketina, mis on konfigureeritud korrektselt toodangusse paigaldamiseks ning lisatud koodihalduskeskkonda. Täitja lisab tarne kohta Tarneteatise.  5.10 Väiksemate Tööde teostamiseks kuluv aeg dokumenteeritakse Täitja poolt iga kalendrikuu kohta ning see on edaspidi aluseks Tööde üleandmise-vastuvõtmise aktide koostamisel. Aktid esitatakse vähemalt kord kvartalis, kus nähtub teostatud tööde nimekiri koos teostatud tööde mahuga (töötunnid). Aktis peavad erinevad tööd (arendustööd, veaparandustööd) olema teineteisest eristatud. 5.11 Täitja poolt läbi viidud arendused peavad edukalt läbima OWASP ASVS v2 taseme 2 turvatestid. Turvatestid tellib Tellija lähtudes oma ajakavast. Turvatestimisel leitud vead, mis on tekkinud Tööde teostamise tulemusena, parandab Täitja oma kuludega. 5.12 Tööd loetakse nõuetekohaselt teostatuks kui Tööd vastavad Tellimusele, vastuvõtutestid on positiivselt (vigadeta) läbitud ja Tööd on üleandmise–vastuvõtmise aktiga Tellija poolt vastu võetud. Vastuvõetud Tööd märgitakse tööde halduskeskkonnas teostatuks Tellija poolt. 5.13 Tellijal on õigus keelduda Tööde vastuvõtmisest kui Tööd ei vasta esitatud nõuetele ja/või kvaliteedile või neis esineb muid puudusi või vigu (vastuvõtutestide tulemus on negatiivne). 5.14 Juhul kui Tellija esitab oma vastuväited Tööle, eeskätt Töö mittevastavuse kohta Tellimuse tingimustele, peab Täitja tegema Töös vastavad parandused, muudatused või täiendused Tellija poolt määratud mõistliku tähtaja jooksul. Kui Täitja ei ole mõistliku aja jooksul rahuldanud Tellimuse täitmise nõuet, võib Tellija Töö ise parandada või lasta seda teha kolmandatel isikutel ja nõuda Täitjalt selleks tehtud mõistlike kulutuste hüvitamist. 5.15 Alates teisest kordustestimisest võib Tellija kordustestidega seotud kulutused (Tellija kulutatud tööaeg ja/või Tellija testimispartnerite poolt esitatud arvete alusel) Täitjalt välja nõuda. 5.16 Kui Tööde teostamisel, sh vigade kõrvaldamisel tekivad Täitja ja Tellija vahel erimeelsused, lähtutakse tõlgendamisel eelkõige Tööde eesmärkidest Tellija seisukohalt. 5.17 Täitja annab Töödele garantii. Garantii hakkab kehtima töö vastuvõtmise kuupäevast, mille Täitja lisab tööde halduskeskkonnas. Garantiitingimused on sätestatud lepingus. 6. Vigadest teavitamine ja veaparanduste teostamine 6.1 Täitja teavitab tema poolt avastatud veebirakenduse ja Tarkvara vigadest Tellijat esimesel võimalusel, tehes kande tööde halduskeskkonda, st registreerib vea, sh märkides vea põhjuse ja eeldatava töömahu (märkides lisaks kui tegemist on garantiilise tööga) ja suunab selle Tellija lepingulisele kontaktisikule. 6.2 Täitja garanteerib Tellijale teenindusajal veakahtluste korral veaallika tuvastamiseks vajaliku konsultatsiooni. 6.3 Tellija lepinguline kontaktisik suunab veateated Täitja projektijuhile täitmiseks tööde halduskeskkonna vahendusel või Tellimusega. Täitjal ei ole õigust alustada vigade parandamist enne kui Tellija lepinguline kontaktisik on Täitjale tööde halduskeskkonnas vastava veateate täitmiseks suunanud või täitmine on kokku lepitud Tellimusega. 6.4 Tellija määrab vea kriitilisuse. Täitja on kohustatud veaparanduse teostama vähima võimaliku aja jooksul. 6.5 Maksimaalsed lahendusajad ja vigade eristamise kriitilisuse astmed on toodud alljärgnevas lahendusaja tabelis: Olulisus Äri- Kirjeldus Lahendusaeg kriitilisus  1 Kõrge Veebirakenduse kasutamine on tõsiselt häiritud või 8 tundi süsteem on täiesti kasutuskõlbmatu, alternatiivset lahendust ei ole võimalik kasutada 2 Keskmine Veebirakenduse kasutamine on häiritud, kuid 16 tundi alternatiivne lahendus võimaldab tööga jätkata. 3 Madal Veebirakenduses esinevad väiksemad 40 tundi probleemid/rikked, mis ei takista infosüsteemi põhifunktsioonide kasutamist. 6.6 Kui veaparandus ei ole objektiivsetest asjaoludest tulenevalt võimalik maksimaalse lahendusaja jooksul, kohustub Täitja sellest Tellijat informeerima kirjalikku taasesitamist võimaldavas vormis, näidates ära põhjused, miks veaparandus ei ole nimetatud aja jooksul võimalik ning esitades töö teostamise tähtaja, mille jooksul Täitja on reaalselt võimeline vea parandama. 6.7 Veaparandustööd annab Täitja üle Tarneteatisega. Veaparanduse märgib tööde halduskeskkonnas teostatuks Tellija. 6.8 Veaparandustööde vastuvõtmine ja testimine toimub samadel alustel nagu on sätestatud arendustööde vastavates punktides. 6.9 Kui Täitja rikub teenustaseme kokkulepet (SLA), on Tellijal õigus nõuda Täitjalt leppetrahvi tasumist - 100 eurot tunnis kuni rikkumise kõrvaldamiseni. 6.10 Leppetrahvide suuruse arvutamiseks peetakse ajaarvestust ühe tunni kaupa, iga algav tund arvestatakse ühe tunnina. 6.11 Kui Täitja rikub Lahendusaegadest tulenevat kohustust on Tellijal õigus nõuda Täitjalt leppetrahvi tasumist järgmiselt:  Kriitiline ja kõrge ärikriitilisus – 65 eurot tunnis iga kohustuse täitmisega viivitatud tunni eest;  Keskmine ärikriitilisus - 50 eurot tunnis iga kohustuse täitmisega viivitatud tunni eest;  Madal ärikriitilisus - 35 eurot tunnis iga kohustuse täitmisega viivitatud tunni eest. 7. Veebirakenduse teenustasemed (SLA) 7.1 Teenuse mahunäitajad Jrk. nr Tingimus Kokku lepitud tingimus 1 Maksimaalne lubatud üheaegne Kuni 1000 üheaegset kasutajat. kasutajate/pöördumiste arv 2 Maksimaalne prognoositav andmemaht Kuni 4 TB. Andmete mahu kasv aastas 3 TB. 3 Maksimaalne lubatud säilitusmaht Piiramata 4 Maksimaalne lubatud võrguliikluse maht 30 GB/kuus 5 Andmete varukoopiaklass (RPO) Teoreetiline RPO on 24h 6 Varukoopiate tegemise sagedus ja meetod 1 kord nädalas täielik varukoopia kogu süsteemist; 6 korda nädalas inkrementvarundus (incremental backup, eelneva varukoopia suhtes).  Varundus toimub öösel alates kell 2:00 7.2 Üldmääratlus Jrk. nr Tingimus Kokku lepitud tingimus 1 Tööaeg 24x7 2 Turvaklass K2T3S2 3 Kriitilisuse klass (RTO) Infosüsteem peab olema uuesti kasutatav 12 tunni jooksul. 7.3 Käideldavus Jrk. nr Tingimus Kokku lepitud tingimus 1 Arhiveerimine Varukoopiad arhiveeritakse iga 12 kuu tagant. 2 Hooldusaeg (teostab Tellija) 22:00-06:00 3 Plaanilistest katkestustest etteteatamiseaeg 4 ööpäeva (vähemalt) 4 Ühe planeeritud katkestuse maksimaalne 3 tundi kestvus (teostatakse töövälisel ajal) 5 Maksimaalne planeeritud katkestuste arv 1 kuus 6 Maksimaalne planeeritud katkestuste 96 tundi kogukestvus aastas 7 Maksimaalne ühekordse planeerimata 8 tundi katkestuse kestvus kuus 8 Planeerimata katkestuste arv kuus * 4 9 Lubatud planeerimata katkestuste 96 tundi kogukestvus aastas 10 Mõõtmisprotseduur Monitooringu aruande põhjal *Planeerimata katkestuseks ei loeta olukorda, kus häiritud on vähese arvu kasutajate töö, kuid asutuses (sama hoone piires) on teenus kättesaadav