Leping

Mittefunktsionaalsed nõuded arendustele Versioon: 2.0 Dokument määrab kvaliteedi- ja mittefunktsionaalsed nõuded (MFN) uutele infosüsteemidele ning nende dokumentatsioonile. Dokumenti hoiavad ajakohasena Tervise ja Heaolu Infosüsteemide Keskuse (TEHIK) arhitektid. 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 TEHIKu koostatud dokumentide ja kolmandate osapoolte koostatud dokumentide erisuste puhul tuleb lähtuda TEHIKu 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 võimalik. Erandid tuleb kooskõlastada TEHIKu vastutava arhitektiga. Nõude Nõude sisu Seletused Koostamise Testimise nr eest läbi viib vastutaja või kinnitab 1. Vastavus üldistele standarditele Lahenduse X-tee teenused peavad https://www.ria.ee/et/ametist/juhendid.html Arendaja Testija 1.1 vastama RIA nõuetele Lahendus peab vastama Arendaja Projektijuht 1.2 Sotsiaalministeeriumi IT-profiilile Arhitekt Administraat or Testija Turvatestija Infoturbe spetsialist Standardija Rakendus peab olema kirjutatud https://www.ria.ee/et/kuberturvalisus/infosusteemide-turvameetmete-susteem-iske.html Arendaja Turvatestija 1.3 arvestades selle rakenduse poolt töödeldavatele andmetele määratud ISKE turvaklassi nõudeid Veebirakenduse kasutajaliides peab http://www.w3.org/TR/WCAG20/ Arendaja Testija 1.4 vastama vähemalt WCAG 2.0 tasemele AA Veebipõhine kasutajaliides peab Valideerimiseks kasutatakse vastavaid validaatoreid: http://validator.w3.org/ Kui on tegu Arendaja Testija 1.5 ühilduma täielikult standarditega olemasoleva süsteemi edasiarendusega, siis tuleb järgida olemasolevat HTML ja CSS versiooni. HTML 5 ja CSS 3. Kokkuleppel TEHIK arhitektiga on lubatud erandid. ID-kaardiga allkirjastamisel on Arendaja loodud lahenduse dokumentatsioonis (nt detailanalüüs vms) peab olema välja toodud Arendaja Testija 1.6 eelistatud veebipõhine digidoc- digidoc-teekide versioonid ja kasutuskohad. teenuste kasutamine ja failide asemel failiräside saatmine teenusesse. Veebirakendus peab probleemiteta Kui pole arenduse eraldi kokku lepitud teisiti, siis on OWASP ASVS tasemeks 2 (https://www.owasp. Arendaja Turvatestija 1.7 läbima OWASP ASVS baasil org/index.php/Category: põhineva testi OWASP_Application_Security_Verification_Standard_Project). Kinnise lähtekoodiga kommertstoote kasutamisel ei eeldata ligipääsu kinnisele lähtekoodile.Tellija poolset turvatestimist teostab kolmas sõltumatu pool.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üptoalgoritmite ja räsifunktsioonide Arendaja loodud lahenduse dokumentatsioonis (nt detailanalüüs vms) tuleb välja tuua kasutatavad Arendaja Arhitekt 1.8 kasutamisel tuleb järgida uusimat RIA krüpto- ja räsialgoritmid, nende võtmepikkused, kasutuskohad, sh SSL sertifikaatide kasutuskohad. kodulehel avaldatud krüptograafiliste Värskeima uuringu leiab aadressilt https://www.ria.ee/et/ametist/uuringud-analuusid-ulevaated.html Administraat algoritmide kasutusvaldkondade ja or elutsükli uuringut, st lahendustes ei tohi kasutada uuringus väljatoodud Turvatestija ebaturvalisi algoritme ja võtmepikkuseid Andmete edastus peab olema Arendaja Turvatestija 1.9 kaitstud kasutades turvalisi ja üldteada andmeedastusprotokolle. Kokkuleppel TEHIK arhitektiga on lubatud erandid. Infosüsteem peab kasutama serveri Arendaja Administraat 1.10 kellaaega ja ajatsooni. or Süsteemi edasiarendamisel/loomisel Arendaja Arhitekt 1.11 peab arvestama selle võimaliku laiendamisega nii andmemahtude, kui Testija ka kasutajate arvu osas. Konkreetsed nõuded annab ette TEHIK arhitekt.  Rakendus peab olema tehniliselt Näiteks, kui rakendus on eraldi turvakontekstidega liidesed ametnikule ja kodanikule, peab rakendus Arendaja Arhitekt 1.12 tükeldatud vastavalt loogilisele olema jagatav kaheks eraldi liidesekomponendiks ning nende mõlema poolt kasutatavaks jaotusele. Saadud osised peavad andmebaasiks olema eraldi versioneeritavad ja paigaldatavad Avalike e-teenuste loomisel peab https://www.valitsus.ee/et/eesmargid-tegevused/valitsusasutuste-visuaalse-identiteedi-stiilijuhis Arendaja Testija 1.13 arvestama valitsusasutusele kehtestatud visuaalse identiteedi stiilijuhised Avalike e-teenuste loomisel peab https://www.mkm.ee/sites/default/files/iseteeninduskeskkondade_raamistik_08.07.2015.pdf Arendaja Testija 1.14 arvestama valitsusasutustele kehtestatud iseteeninduskeskkonna https://www.mkm.ee/sites/default/files raamistikuga /iseteeninduskeskkondade_raamistiku_kasutatavuse_nouded_dets.pdf 1.15 Avalike e-teenuste koomisel peab <Siia tuleb link TEHIKu gitlabi> Arendaja Arhitekt arvestama TEHIKu stiiliraamatu nõuetega 2. Nõuded rakenduse arhitektuurile Rakenduse, andmebaasi ja kolmanda Arendaja loodud lahenduse dokumentatsioonis (nt detailanalüüs vms) peab olema välja toodud Arendaja Arhitekt 2.1 osapoole komponentid peavad olema kasutatavate komponentide nimetused ja versioonid. Versiooni eluea lõppu ei loeta võrdseks terve sellised, mille eluea lõpp (EOL) pole komponendi eluea lõpuks, st versiooni tugi võib aeguda, kui uus versioon on välja lastud. teadaolevalt vähem kui 2 aasta pärast. Tulevase ja olemasolevate Süsteemi jõudlus peab vastama kokkulepitud topoloogial eelanalüüsi ja lähteülesande käigus välja Arendaja Arhitekt 2.2 infosüsteemide platvormid toodud jõudlusnäitajatele. (rakendusserver, andmebaas, kolmanda osapoole komponendid) ja topoloogia peab olema enne reaalse arenduse algust infosüsteemide halduse osakonna juhiga kooskõlastatud. Rakendusserver peab võimaldama Arendaja Administraat 2.3 töötamist andmebaasiserverist eraldi or serveril. Rakendusserver peab olema Arendaja Administraat 2.4 vajadusel klasterdatav aktiivklastris or (kasutajasessioon ei tohi olla klastri node põhine). Rakendust peab saama ilma Lahendus ei tohi olla sisse kompileeritud absoluutseid URI-sid Arendaja Administraat 2.5 ümberprogrammeerimata liigutada or erinevate domeenide ja domeeni saitide vahel Rakenduse Rakendus peab neid sealt ka kasutama (mitte kopeerima parameetreid käivitamisel kolmandatesse Arendaja Administraat 2.6 konfiguratsiooniparameetrid tuleb kohtadesse), logimise seaded võivad olla rakenduse konfiguratsioonifailist eraldi ühes or ühte kohta kokku tuua nii, et nende lisakonfiguratsioonifailis (näit Log4net). Samuti on väga soovitatav eraldi konfiguratsioonifailis hoida muutmisel ei peaks rakendust uuesti arendaja ja administraatori vastutusala parameetrid. Infosüsteem peab olema seadistatav Testija kokku kompileerima (nt ühte konfiguratsiooniparameetrite(de) abil. Konfiguratsioonifailiks ei saa lugeda faili, kus hoitakse lisaks tekstipõhisesse konfiguratsioonifaili, konfiguratsioonile ka muud programmikoodi. andmebaasi tabelisse). Rakenduse taaskäivitus, Maksimaalne aeg on 5 minutit. Kui rakendus vajab indekseeritud sisu ja see pole kättesaadav, siis Arendaja Testija 2.7 konfiguratsiooni muutmine vms peab peab rakendus väljastama selle kohta selge teate. toimuma mõistliku aja jooksul. 2.8 Kui rakendusel või mõnel selle Näiteks digidoc4j teegi korral laetakse TSL nimekiri välisvõrgust, mis on aeglane. Arendaja Arhitekt komponendil on tihti kasutatav teenus ning sellel teenusel on aeglaselt Testija laetav konfiguratsioon, siis tuleb: Administraat a) laadida konfiguratsioon or ühekordselt ja korduvkasutada seda; b) konfiguratsiooni automaatselt ja regulaarselt värskendada; regulaarsuse tarbeks peab saama määrata intervalli, millise aja järel või täpsed kellaajad, millal konfiguratsiooni värskendatakse; c) luua võimalus värskendada konfiugratsiooni käsitsi. Rakendus peab kasutama 64-bitist Arendaja Administraat 2.9 arvutiarhitektuuri kui ei ole kokku or lepitud teisiti. Arhitekt Kõik andmed, andmebaasid, SQL Arendaja Administraat 2.10 skriptid ja rakendus peavad kasutama or UTF-8 kodeeringut. Kokkuleppel TEHIK arhitektiga on lubatud erandid. Testija Failisüsteemi salvestamisel ei tohi Failid peab katalogiseerima kokkulepitud tunnuste alusel (nt aasta, kuu, kuupäev). Arendaja Administraat 2.11 ühte kausta tekkida üle 10000 faili. or Ühest andmetabelist teise viitamisel Arendaja Arhitekt 2.12 tuleb kasutada väliseid võtmeid (Foreign key). Kõik välised võtmed (Foreign Key) Andmebaasis peab kasutama indekseid või muid meetmeid, et nõuded rakenduse jõudlusele oleksid Arendaja Arhitekt 2.13 peavad olema indekseeritud. täidetud ka tulevikus. (1, 3, 5 või 10 aasta pärast – vastavalt planeeritud kasutusajale).  Tuleb kasutada päringumuutujaid SQL päringute väljakutsumisel väljastpoolt andmebaasi, peab kasutama päringumuutujaid, et vältida Arendaja Arhitekt 2.14 (Parameter Binding) SQL vahemälu fragmentseerumist (When calling SQL code from outside the database, Parameter Binding should be used to prevent SQL cache fragmentation) Kõigis andmebaasi tabelites peab Kasutada vastava andmebaasisüsteemi nimetamise parimaid praktikaid. Arendaja Arhitekt 2.15 olema defineeritud üks primaarvõti. Andmebaasi objektide nimetused peavad olema sisulised ja andma aimu nende otstarbest. Andmebaasis defineeritakse üldjuhul Need õigused, mis on vajalikud ainult rakenduse baasi loomiseks, on eraldi välja toodud ja tuleb Arendaja Administraat 2.16 kaks või enam kasutajat: peale installi ära võtta. Karbitoodete puhul tuleb erisused läbi arutada TEHIK arhitektiga. or Rakenduse peakasutaja, kellena luuakse objektid ja skeemid. Rakenduse piiratud õigustega kasutaja, kellena pöördub rakendusserver/rakendus. Objektide loomiseks vajalikud õigused ja ressursid on loetletud rakenduse dokumentatsioonis. Failide hoidmise asukoht lepitakse Failide hoidmine klassikalises andmebaasis on kulukas ja seab kõrgendatud nõudmised ja piirangud Arendaja Arhitekt 2.17 igakord kokku. Kuid failid ja failide andmebaasiserveritele. Lahenduse dokumentatsioonis tuleb ära tuua failide hoidmise asukoht. indeks peavad olema replikeeritavad teise serveriruumi. Peab olema minimiseeritud vajadus, Halduri haldustoimingud lepitakse tellijaga kokku detailanalüüsi käigus. Arendaja Testija 2.18 et haldur teeb haldustoiminguid otse baasis. St rakendusel peab olema haldusliides, mille kaudu rakenduse haldur saab teha tavapäraseid haldustoiminguid. Rakendus peab olema võimeline Näiteks logifailides. Arendaja Testija 2.19 kasutama keskkonnamuutujaid (serverinimi, kuu, päev jne). Andmebaas peab toetama nii külm- Ei tohi kasutada teenuseid, mis välistavad andmebaasi peegeldamist (nt "MSSQL filestream"). Arendaja Arhitekt 2.20 kui ka kuumvaru (peegeldamist) teise serviruumi. Sorteerimisreeglistik peab olema Näiteks PostgreSQL puhul et_EE. Arendaja Testija 2.21 Eesti tähestikule vastav. Tõusutundlikkus peab olema välja lülitatud. Accent peab olema sisse lülitatud. Kui infosüsteemid saadavad e- Saatja ja adressaadid, pealkiri ja sisu ei tohi olla rakendusse kodeeritud, vaid on muudetavad Arendaja Administraat 2.22 kirju, peavad nad kasutama välist e- konfiguratsioonifaili kaudu. Genereeritud kirjade puhul peab tagama kirjade jälitatavuse (näiteks or mailiserverit. Kirja saatmisel peab lisada X-päise kodeeritud kirje, milles on kirjeldatud, mis protsess/skriptifail/kasutaja kirja genereeris rakendus veenduma, et e-mailiserver jms abistav info). võttis meili vastu. E-kirjade vormindamine peab järgima interneti standardeid (RFC 5322). Konfiguratsiooniparameetrite nimed Näiteks : X-tee Turvaserver, mitte XTTS või viitenumber, mitte vk_seb jne Arendaja Administraat 2.23 peavad olema sisulised. Kui see ei ole or võimalik, siis peab kõrval olema seletus. Testija Infosüsteemides on eessüsteemid Koostöövõime raamistik 2011. Punkt 3.1. Tagasüsteemide ülesanneteks on andmete haldamine ja Arendaja Arhitekt 2.24 (front end; presentatsiooni kiht) ja võrguteenuste pakkumine. Tagasüsteemid ei tegele lõppkasutaja autentimise ja autoriseerimisega. tagasüsteemid (back end; äriloogika Lõppkasutaja autoriseerimise tagavad eessüsteemid. Välise süsteemi tõrge tohib mõjutada ainult kiht) arhitektuuriliselt selgelt lahutatud sellest otseselt sõltuvate kasutuslugude toimimist. Välise süsteemi taastumisel peab süsteem olema ja eraldi paigaldatavad. suuteline oma tööd jatkama taaskäivitamata. Konfiguratsioonifailid peavad olema Näiteks IIS: *.config , *.resources Apache: *.conf, .htaccess. Arendaja peab välja tooma konfifailide Arendaja Administraat 2.25 vastavalt rakendusserveri tüübile listi, kui neid on mitu. or vaikimisi kaitstud failid Rakenduse failid, mida kasutaja näha Näiteks: IIS: Bin,App_Code, App_Data, App_Browsers, App_GlobalResources, Arendaja Administraat 2.26 ei tohi, peavad olema vaikimisi App_LocalResources, App_Themes, App_WebReferences or kaitstud kaustades ja ei tohi olla veebi juurkaustas. Konfiguratsiooniparameetrite Kõiki parameetreid tuleks konfiguratsioonis kirjeldada vaid korra, mitte nii, et igas lõigus kirjeldatakse Arendaja Administraat 2.27 taaskasutus. Erinevaid sama sisuga samu asju uuesti. or parameetreid ei tohi konfiguratsioonis eksisteerida. Testija Kõik rakenduse liidesed peavad Rakendustes tohib kasutada vaid masinapõhiseid teenuseid, mis lubavad kõrgkäideldavaid (klaster) Arendaja Administraat 2.28 olema võimelised lahendusi. Kõrgkäideldav lahendus on selline, mida saab samaaegselt käitada erinevates masinates. or töötama kõrgkäideldavalt. Klientrakendus ei tohi pöörduda otse Tuleb kasutada rakendusservereid. Arendaja Administraat 2.29 andmebaasi poole. or Keskkonnapõhised muutujad peavad Näiteks WSDL ei tohi sisaldada viiteid arendusserveritele. Arendaja Administraat 2.30 olema konfiguratsioonifailist or seadistatavad. Testija  Eelistada tuleb tsentraalseid Eelistama peaks IP-aadressipõhist blokeeringut. Erandina tellijaga kokkuleppel võib kasutada Arendaja Arhitekt 2.31 autentimislahendusi (nt TARA, AAM). captchat või konto lukustamist. Blokeeringute ajavahemikku ja logimiskatsete arvu peab saama Kui rakendus realiseerib ise konfiguratsioonifailist muuta. Testija autentimist, siis peab olema võimalik piirata ebaõnnestunud logimisi ajaühiku kohta (mobiil-ID, paroolid) ühelt IP-aadressilt. Rakenduse äriloogika tuleb Andmebaas ei tohi sisaldada äriloogikat, mis muudab andmetabelites olevaid/sinna kirjutatavaid Arendaja Arhitekt 2.32 realiseerida andmebaasist eraldi andmeid, va trigerid, mis tekitavad logi. sõltumatus rakenduskihis. Andmebaasis võib kasutada vaid ISO *Ei ole soovitav kasutada mingit platvormispetsiifilist lahendust, mille üleviimine mõnele muule Arendaja Arhitekt 2.33 /IEC 9075 standardiga kaetud andmebaasiplatvormile ei ole võimalik. funktsionaalsusi. Lisaks ei tohi *ISO/IEC 9075 osa 13 spetsifitseerib Javas kirjutatud programmimoodulite kasutamist andmebaasis. kasutada ka sama standardi osas 13 kirjeldatud funktsionaalsusi. Kui rakendus eeldab eraldi kasutajate, Arendaja Arhitekt 2.34 rollide ja õiguste registri pidamist, siis peab rakendus kasutama Tellija Testija tsentraalseid autoriseerimislahendusi. Uniform resource identifier (URI) Harilikult on piiriks 2000 tähemärki, kuid iga IS puhul tuleb seda eraldi järele uurida sõltuvalt IS Arendaja Administraat 2.35 pikkus ei tohi ületada ühegi IS poolt komponentidest. Asjakohased viited: RFC 3986 ja RFC 7239. or toetatava brauseri maksimaalset lubatud väärtust. Testija Veebiteenuseid (REST, SOAP) Näiteks WSDL puhul: Alajaotis definitions/types/schema: Arendaja Arhitekt 2.36 pakkuv rakendus peab olema üles ehitatud nii, et see toetaks teenuste * complexType defineerimisel tuleb sellele lisada any element. versioneerimist URL-i ja/või schema tasemel. Rakendus peab olema võimeline SSL offload Arendaja Administraat 2.37 töötama koormusjaoturitega or varustatud taristul. Sidusinfosüsteemide mitte Sidussüsteemi tõrge tohib mõjutada ainult sellest otseselt sõltuvate kasutuslugude toimimist. Arendaja Administraat 2.38 kättesaadavus ei tohi segada Sidussüsteemi taastumisel peab süsteem olema suuteline oma tööd jatkama taaskäivitamata. or rakenduse töötamist. Sidusinfosüsteemidega Väliste liidestatud süsteemide tõrke korral ei tohi süsteem hanguda, vaid väljastama mõistliku Testija andmevahetamisel tekkinud vead (võimalikult lühikese) aja jooksul ajakohase veateate. Võimalusel tuleb kasutada asünkroonseid logitakse ja kasutajat hoiatatakse. liideseid. 2.39 Automaatselt käivituvaid taustatöid Vajalik juhuks, kui automaatsel käivitumisel on tekkinud viga ja/või taustatöö on pooleli jäänud. Arendaja Testija peab saama käsitsi (taas)käivitada. Pärast vea põhjuse korrigeerimist peab saama taustatöö uuesti käivitada. Kui ajastatult käivitatav taustatöö, ei Arendaja Administraat 2.40 ole mõeldud käima paralleelselt, peab or selles olema realiseeritud kontrollmehhanism, mis tagab, et Testija 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 Näiteks kui rakenduse komponent pöördub andmebaasi või veebiteenuse poole, siis selle Arendaja Administraat 2.41 tohi sama parameetri seadistamine pöördumise parameetrid peavad olema muudetavad vaid ühes kohas. or toimuda rohkem kui ühes kohas. Uue toote arenduse ja olemasolevate Arendaja Arhitekt 2.42 infosüsteemide versiooniuuendustel kasutusele võetavate tehnoloogiate ja standardite valik tuleb kooskõlastada Tellija poolse arhitektiga Rakenduse ühenduste (s.h. Implementeeritud peab olema vähemalt maksimaalsete ühenduste arvu piirang ja päringu aegumise Arendaja Arhitekt 2.43 andmebaasi ja sidusinfosüsteemide aeg (request timeout). Rakenduse ühenduste tõrge tohib mõjutada ainult sellest otseselt sõltuvate ühendused) realiseerimisel tuleb kasutuslugude toimimist. Ühenduste taastumisel peab rakendus olema suuteline oma tööd jatkama kasutada ühenduste puulimist taaskäivitamata. Tekkinud vead logitakse ja kasutajat hoiatatakse. (connection pooling). Rakenduse uuendustega kaasnevad Näiteks Liquibase või Flyway. Arendaja Administraat 2.44 andmebaasi muudatused tuleb or automatiseerida. 3. Turvalisuse tagamisega seotud nõuded Asutuse siseseks kasutamiseks Erandina tellija kooskõlastusel võib sellest loobuda ja kasutada vaid ID-kaardi ja mobiil-ID põhist Arendaja Turvatestija 3.1 mõeldud rakenduse kasutajate autentimist. ID-kaardi puhul peab isiku sertifikaatide kehtivust saama kontrollida vastu OCSP ja CRL- autentimist peab saama teha Active i (vastavalt vajadusele). Directory põhiselt. Kliendi ja serveri vahel peab Arendaja Turvatestija 3.2 autenditud kasutajasessioonide korral olema sessioon krüpteeritud HTTPS- protokolli kasutades. SSL veebiserver peab kasutama Protokolli krüpto tugevust saab kontrollida lehel https://www.ssllabs.com/ssltest/ Administraator Turvatestija 3.3 turvalisi ja SSL/TLS versioone ja šifrikomplekte Rakendus tohib kasutada vaid Arendaja Turvatestija 3.4 sessiooni küpsiseid (cookies). Muude küpsiste kasutamine on keelatud.  Kui andmebaasis olevate andmete St kõik andmemuudatused peavad baasis säilima. Andmete muutmisel andmeid ei kustutata, vaid Arendaja Turvatestija 3.5 ISKE tervikluse turvaosaklass on 3 tehakse uus kirje uute andmetega. Vana muudetakse kehtetuks. Iga uus kirje peab sisaldama (kõrge), siis tuleb kõik andmebaasi järgmist informatsiooni: Arhitekt kirjed/tabelid versioneerida. *viide kirjele, mille ta kehtetuks muutis (kui on) *kasutaja, kes kirje lõi *kirje loomise aeg *sessiooni-ID (kui on olemas). Iga kehtetuks tunnistatud kirje peab omama järgmist informatsiooni: *kasutaja, kes kirje kehtetuks tunnistas *kirje kehtetuks tunnistamise aeg. Rakendusega peab kaasas olema Testandmed peavad säilitama kõik toodangu andmete omadused (pikkuse, tüübi) ja omavahelised Arendaja Arhitekt 3.6 lahendus, mis suudab toota toodangu suhted. Täpsem vajadus ja tegevusplaan tuleb koostada TEHIKu arhitekti ja tooteomanikuga. andmetest testandmed, mis ei sisalda konfidentsiaalset informatsiooni. Andmebaasis olevate rakenduse Ei resource, dba, ANY ega muud sellist. Nõude täitmiseks vajalikud vahendid (skriptid) peavad Arendaja Turvatestija 3.7 kontod peavad omama ainult kuuluma rakenduse juurde ja nende sisu peab olema kontrollitav. Kontodele vajalikud õigused minimaalselt rakenduse tööks peavad olema kirjeldatud rakenduse installijuhendis. Administraator vajalikke õiguseid. Rakendusse ja andmetele tohib olla St rakendustes ega andmebaasides ei tohi olla ligipääsemiseks teisi võimalusi. Arendaja Turvatestija 3.8 ligipääs vaid dokumenteeritud ja tellimuses kirjeldatud teid mööda ning dokumenteeritud autentimisprotseduure kasutades. Kõik paroolid ja salaküsimuste Hetkel kehtivad nõuded saab TEHIKu arhitektilt. Arendaja loodud lahenduse dokumentatsioonis (nt Arendaja Turvatestija 3.9 vastused peab rakendus salvestama detailanalüüs vms) peab olema ära toodud kasutatavad räsi ja krüptoalgoritmid, võtmepikkused ja vaid räsitud+soolatud. Kui räsimise nende kasutuskohad (vt nõue p 1.10) asemel valitakse krüpteerimine, siis tuleb kirjeldada krüptovõtme turvalise hoidmise protseduur. Rakendused, kuhu saavad ligi välised Kui on vajalik ka parooliga logimine, peavad välised kasutajad autentima ennast AD pihta. Vajadus Arendaja Turvatestija 3.10 kasutajad, peavad võimaldama tuleb kooskõlastada TEHIKu arhitektiga. sisselogimist ID-kaardi ja mobiil-ID- ga. Paroolipõhist autentimist ei tohi kasutada. Mobiil-ID autenimise korral tuleb Veebilehel kuvatav kontrollkood peab olema selgelt nähtav, sh ka nutitelefonidel ilma ekraanipilti Arendaja Turvatestija 3.11 lisaks kasutaja telefoninumbrile kerimata. küsida ka kasutaja isikukoodi. Rakendus ei tohi teostada X-tee Kasutajaarvutitest otse x-tee päringute tegemine on arvutivõrgu tasemel kinni. Arendaja Turvatestija 3.12 päringut otse kasutajaarvutist. Veebipõhised välise veebilehega IIS puhul peab kasutama näiteks URL scan, apache puhul modsecurity või vastavat tööriista. Arendaja Turvatestija 3.13 rakendused peavad kasutama Lubamatud päringud on kõik päringud, mis ei ole detailanalüüsi käigus vastavalt kasutusjuhtudele vahendeid kaitsmaks rakendust ette nähtud. Kasutama peab whitelisting põhimõtet, mitte blacklisting. Administraator lubamatute päringute eest. Rakendus peab sisenemisel näitama Kasutaja peab saama soovi korral veenduda, kas keegi pole tema nime all vahepeal sisse loginud. Arendaja Turvatestija 3.14 pärast õnnestunud sisselogimist Ebaõnnestunud logimiste katsete kuvamise nõue kehtib juhul, kui autentimine ja autoriseerimine eelmise õnnestunud sisselogimise lahendatakse rakenduses lokaalselt. aega. Kui on toimunud ebaõnnestunud sisselogimise katseid, siis peab kuvama ka, millal need toimusid, mitu neid oli ja mis IP- aadressilt pöörduti. Kõigil rakendustel peab olema Aeg peab olema muudetav koos teiste konfiguratsiooniparameetritega. Arendaja Turvatestija 3.15 konfigureeritav kasutajasessiooni aegumise aeg. Krüpteerimise ja/või räside arvutamise Järgida tuleb uusimat RIA kodulehel avaldatud krüptograafiliste algoritmide kasutusvaldkondade ja Arendaja Turvatestija 3.16 korral tuleb kasutada tugevaid elutsükli uuringut. Lahenduse dokumentatsioonis tuleb välja tuua kõik krüptoalgoritmid, algoritme. võtmepikkused ja kasutuskohad. Autenditud sessiooni tunnust ei tohi Sessiooni ei tohi olla võimalik üle võtta sessioonitunnuse kopeerimisega ühest arvutist teise. Arendaja Turvatestija 3.17 ainult lihtsa küpsisega lahendada (tunnus peab olema krüpteeritud). LDAP lahenduse (nt AD) kasutamisel Näiteks: konto on lukus, parool aegunud, konto aegunud, paroolipoliitika jne. Arendaja Turvatestija 3.18 peab rakendus kasutama kontoga kaasnevaid piiranguparameetreid. Tagada tuleb rakenduse rollide Peakasutajal ja tavakasutajal on erinevad tööülesanded. Rollide/õiguste kirjeldus peab lähtuma Arendaja Turvatestija 3.19 lahusus. detailanalüüsist ja kasutusjuhtudest. ID-kaardiga autentimisel, peab Proxy tugi Arendaja Turvatestija 3.20 rakendus suutma vastu võtta ID- kaardi sertifikaati ka päises. Kui kasutajaid hallatakse ka Eesmärk vähendada AD ja AAM-i koormust. Arendaja Turvatestija 3.21 rakenduses ja autenditakse AD või AAM-i vahendusel, tuleb sisselogimisel kõigepealt kontrollida kasutaja olemasolu rakenduses ja alles siis pöörduda AD või AAM-i poole. Arendus peab olema orienteeritud Toodangukeskkonna rakendus ei tohi sisaldada osiseid, mis toodangu keskkonnas on ebavajalikud Arendaja Turvatestija 3.22 toodangukeskkonnas toimimiseks. või segavad (näiteks kasutuseta funktsionaalsus ja komponendid, mõeldud testimiseks testkeskkonnas, arendusabiks arenduskeskkonnas jne).  Rakendus ei tohi lubada ühe Juhul kui lähteülesanne spetsiaalselt ei ütle teisiti. Arendaja Turvatestija 3.23 kasutajaga mitut samaaegset sessiooni. Kui rakenduse tervikluse Milline lahendus valitakse tuleb kokku leppida tellijaga. Täpsustuseks vt ISKE nõue HT.34. Vt ka Arendaja Turvatestija 3.24 turvaosaklass on T3, peavad nõuet 3.28. tõestusväärtust omavad andmed olema kas ajatembeldatud, digiallkirjastatud või digitembeldatud. Kui lahendus peaks kasutama Ajatempli kasutamise vajadus lepitakse eraldi kokku Tellija IT juhiga ja infoturbejuhiga. See sõltub Arendaja Turvatestija 3.25 ajatempli teenust, siis tuleks eelistada Tellija keskse ajatempli kasutamise võimalustest. Guardtime lahendust. Kui rakenduse tervikluse Täpsustuseks vt ISKE nõue HT.10. Krüptoahela kasutamise vajadus lepitakse eraldi kokku Tellija Arendaja Turvatestija 3.26 turvaosaklass on T3, peavad infrastrktuuri juhiga ja infoturbejuhiga. See sõltub Tellija keskse krüptoahela kasutamise tõestusväärtust omavad andmed võimalustest. olema krüptoaheldatud, et tagada et tõestusväärtusega andmeid ei saaks märkamatult kustutada. Kui rakenduses on S3 salastuse Täpsustuseks vt ISKE nõue HT.37. Arendaja Turvatestija 3.27 astmega andmeid, peavad need olema nii transpordi ajal ja ka salvestatult alati krüpteeritult. Veebirakendus ei tohi jätta sulgemisel Kui paks klient kasutab ajutisi faile, tuleb tagada nende perioodiline kustutamine tagamaks, et ei Arendaja Turvatestija 3.28 kasutaja tööjaama maha ajutisi faile. koormata liigselt kasutaja arvutit. Nõude eesmärk on tagada, et rakenduse sulgemisel ei jääks Paksu kliendi korral ei tohi rakendus kasutaja arvutisse maha informatsiooni, mida sinna jääda ei tohiks, sh pääsuandmeid, isikuandmeid, kasutaja tööjaama jätta maha andmekogu sisulisi andmeid jms krüpteerimata kujul ajutisi faile, mis sisaldavad või võivad sisaldada konfidentsiaalse või kõrget terviklust nõudvat informatsiooni. Rakendus ja selle komponendid Arendaja arendab arenduskeskkonnas ja annab tarne üle tellijale paigalduspakkidena. Tellija Arendaja Turvatestija 3.29 peavad võimaldama kasutada paigaldab selle testkeskkonda ja testib ning seejärel paigaldab tarne toodangu keskkonda. keskkondade lahusust Reaalseid andmekogu andmeid tohib töödelda üksnes toodangu keskkonnas. Rakendus peab võimaldama hõlpsalt Krüptograafiat kasutav rakenduskood ei tohi nimeliselt välja kutsuda krüptograafilisi algoritme, vaid Arendaja Turvatestija 3.30 välja vahetada aegunud ja peaksid seda tegema vahendavate vaheteekide kaudu üldiste funktsioonide järgi (nt krüpteerimine, ebaturvalise krüptoalgoritmi. dekrüpteerimine, signeerimine, signatuuri verifitseerimine jne). Dokumentatsioon peab kajastama üldist kirjeldust, kuidas vajadusel ebaturvaline krüptoalgoritm välja vahetada. Rakenduse andmebaasi Andmebaasides kasutatavad krüpteerimisfunktsioonidest tingitud lisaväljad peaksid olema Arendaja Turvatestija 3.31 krüpteerimisega seotud andmeväljad muudetava pikkusega, et formaati muutmata saaks kasutada teistsuguste parameetritega peavad olema muudetava pikkusega. krüpteerimisalgoritme. 4. Logimine, debuggimine, testimine Rakendusel peab olema masinloetav Testlehe kättesaadavus erinevatest arvutivõrkudest peab olema konfigureeritav. Testleht peab Arendaja Arhitekt 4.1 testleht (health check) nt JSON või uuendama ennast lehe pärimisel. Testleht peab sisaldama custom built rakenduse versiooni XML formaadis. numbrit, standardsed komponendid (veebiserver, andmebaas, CMS'id jms) ei tohi oma versioone Administraat reeta. Samuti peab testlehel olema infot rakenduse (vajadusel tema erinevate osade) ja tema kõigi or väliste liideste staatuse kohta (töötab, ei 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). 4.2 Rakendus peab pakkuma Näiteks Prometheuse formaadis monitooringu leht, kus näeb infot päringu kestuste kohta, Arendaja Arhitekt monitooringu lehte, kus leidub veakoodide ja nende hulka. Rakenduse mälu kasutamist jne. informatsioon rakenduse Administraat funktsionaalsuse toimimise kohta. or Rakenduse kõik üleantavad Testitulemused tuleb edastada tellijale koos rakenduse üleandmisega. Vaata lisaks nõuet 4.21 ja Arendaja Testija 4.3 versioonid peavad enne tellijale üle 4.22. andmist olema testitud Rakendus peab logima kasutaja Logima peab ka autentimise ebaõnnestumise koos põhjusega (vale parool, aegunud konto jne). Arendaja Testija 4.4 edukat ja ebaedukat autentimist ja Logida tuleks IP-aadress, meetod ja kui võimalik kasutajatunnus (mobiil-ID puhul telefoni number, ID- sessiooni lõpetamist, kasutaja IP ja kaardi puhul isikukood). Kui rakendus kasutab kasutajate autentimiseks AAM-i või TARA, siis autentimismeetodit (ID-kaart, mobiil- leppida projektijuhiga eraldi kokku autentimise detailsus ehk mis kajastatakse AAM-is või TARA-s ja ID vms), eduka autendi puhul tuleks mis rakenduses. logida ka kasutaja isikukood ja mobiil- ID ning Smart-ID puhul telefoninumber Erinevate logifailide kirjeid peab Tegevuste sidumiseks peab olema võimalik logikirjeid siduda ühise välja abil. Selleks ei sobi Arendaja Arhitekt 4.5 olema võimalik seotud komponentide kellaaeg ega IP. Sobib näiteks unikaalne ID, mis ei tohi olla sessiooni ID, sest seda saaks logist logidega loogiliselt kokku viia. välja lugeda ja rünnakuks ära kasutada. Võib olla sessiooni ID räsi koos transaktsiooni ID'ga. Testija Konkreetne lahendus tuleb valideerida TEHIKu arhitektiga. Rakendus peab suutma logida kõiki X- Vajalik eelkõige silumiseks ja toodangu keskkonna probleemide lahendamiseks. Arendaja Administraat 4.6 tee teenuste kaudu liikuvaid andmeid. or Peab olema võimalus logimist sisse- välja lülitada. Testija Logimiseks tuleb kasutada Näiteks java-s log4j/logback ... , transpordiks syslog, logi formaadiks JSON või CSV või tabeldus- Arendaja Administrator 4.7 standardseid komponente kogu eraldus. Failid peavad olema loetavad tekstilisel kujul. Logid peavad olema kujul, et neid saaks logiahela ulatuses. töödelda masinloetavalt ja inimloetavalt. Arhitekt Andmete loomise/vaatamise/muutmise Logikirjes peab sisalduma piisavalt informatsiooni, et vastata küsimustele kes, mida, kus, kust, Arendaja Testija 4.8 /kustutamise tegevused peavad millal, kuidas ja tulemus. olema kajastatud logides. Turvatestija Infoturbespet sialist Logid peavad olema jaotatud Seansilogi - info sisselogimiste, väljalogimiste ja seansi aegumiste kohta. Vigased sisselogimise Arendaja Administraat 4.9 loogiliselt. katsed. Info õiguste suurendamise kohta. Peab olema logitud ka tühja või puuduvate parameetritega or logimise katsed. Tegevuslogi - kogu informatsioon kasutajate tegevuste kohta koos tegevuse tüübi, seansi  parameetrite (korreleerimaks seansi- ja tegevuslogi) ja kasutaja poolt esitatud sisendparameetritega Testija (sh. väliste ressursside kasutamise kohta). Logida tuleb nii õnnestunud kui ka ebaõnnestunud tegevusi. Tehniline logi - rakendusserveri poolt loodud logi Vealogi - erinevate veaolukordade info Silumislogi - arendajate jaoks vajalik debug info Administraatorite ja haldurite poolt Lahendus peab tagama, et administraatorid/haldurid ei saa andmete vaatamise, muutmise logimist Arendaja Infoturbespet 4.10 tehtavaid andmete vaatamised, ise (ka tavakasutajate logimist) deaktiveerida või logisid kustutada/muuta. sialist muutmised sh kustutamised (ka otse baasis) tuleb logida. Testija Kui parameetri väärtus on tühi, tuleb Näiteks NULL Arendaja Testija 4.11 see logis märkida asendusväärtusega. Logis tuleb kõik mitte kuvatavad (non- Näiteks reavahetused -> \n, non-printable sümbolid - 0x00..0x1f, 0x7f..0xff. Arendaja Testija 4.12 printable) sümbolid kodeerida. Logides peab olema maksimaalselt Mitme realiste sündmuste puhul kasutada kodeerimist või JSON formaati. Mitme realiste sündmused Arendaja Testija 4.13 üks sündmus ühel real. võivad olla tehnilises-, vea- või silumislogis kui rakendusserver ei oska seda kodeerida. Ühe ja sama sündmuse väljad peavad Arendaja Testija 4.14 olema erinevatel logikirjetel samas järjekorras Logida tuleb ka päringud, mille vastus Arendaja Administraat 4.15 on puhverdatud. or Testija Logimine peab olema optimeeritud. Informatsiooni dubleerimist logides tuleb vältida, kui ei ole nõutud teisiti. Arendaja Testija 4.16 Rakendusega peab olema kaasas Jõudlustestide täpne kirjeldus tuleb kokku leppida detailanalüüsi käigus. Arendaja peab koos Arendaja Arhitekt 4.17 skript jõudlustestide tegemiseks. rakendusega tarnima skripti ja vajalikud tarkvaralised vahendid kokkulepitud jõudlustestide läbiviimiseks. Jõudlustestide läbiviimine ei tohi nõuda tellijalt omapoolset tarkvara arendamist, Administraat skriptide kirjutamist või litsentside ostmist. or Testija 4.18 Rakendus peab logima kõiki Logi sisaldab minimaalselt vea tekkimise aega, veakoodi, veakirjeldust (stack trace, traceback vms), Arendaja Administraat rakenduses tekkivaid tehnilisi vigu. võimalusel kasutaja andmeid, HTTP-, GET- ja POST-parameetrid ja nende väärtusi. Logimise or detailsusrežiimi (info, warning, errog, debug) peab saama muuta. Testija 4.19 Rakenduse funktsionaalsuse Mida logitakse, kuidas sündmused on logifailidesse jagatud, logiridade näited. Arendaja Arhitekt kirjeldusega tuleb luua ka logimise dokumentatsioon ja loginäidised. Administraat Koos funktsionaalsuse arendamisega or tuleb luua ka loodava funktsionaalsuse logimine ja selle dokumentatsioon. 4.20 Logimisparameetreid peab saama Näiteks log4j konfiguratsiooni failis "monitoring-interval". Arendaja Administraat muuta rakendust taaskäivitamata. or Testija 4.21 Lahendus peab olema minimaalselt Käivitatakse tellija pideva integreerimise (CI) keskkonnas (nt Gitlab) ja kaetust raporteeritakse Arendaja Arhitekt 75% ulatuses kaetud automaatsete lähtekoodi analüsaatoris (nt SonarQube). komponenditestidega (unit test). Testija 4.22 Lahendus peab olema minimaalselt Käivitatakse tellija pideva integreerimise (CI) keskkonnas (nt Gitlab) ja kaetust raporteeritakse Arendaja Arhitekt 50% ulatuses kaetud automaatsete lähtekoodi analüsaatoris (nt SonarQube). vastuvõtutestidega. Testija 5. Nõuded rakenduse lähtekoodile Lähtekoodi kommentaarid peavad NB! Nõuet ei arvestata arendustarkvara poolt automaatselt genereeritavate koodilõikude puhul – Arendaja Arhitekt 5.1 kõigis lahenduse kihtides (rakenduse neid ei ole vaja tõlkida. Samuti ei rakendata nõuet kolmandate osapoolte poolt toodetud lähtekoodile enda kood, andmebaas jne) olema – nt igasugu erinevad lahtise koodiga koodilõigud jms. Kui on tegu olemasoleva süsteemi kirjutatud inglise keeles. edasiarendusega, siis peaks kommentaarides kasutama eelnevalt kasutatud keelt. Lähtekoodi kommentaarid peavad Rakenduse kood peab olema piisavalt hästi kommenteeritud, et erialast haridust omav Arendaja Arhitekt 5.2 olema selged, arusaadavad ja tarkvaraarendaja on võimeline süsteemile jätkuarendusi teostama. sisuliselt kirjeldama vastavat koodi, mille juures nad on ning moodustama vähemalt 20% koodi mahust. Muutujate, tüüpide ja funktsioonide Parim praktika Arendaja Arhitekt 5.3 nimed peavad olema sisulised ja andma aimu nende otstarbest. Koodis kasutatavad konstandid ja Nt Javas identifikaator --> ID Arendaja Arhitekt 5.4 lühendid tuleb kirjutada suurte tähtedega, lähtudes kasutatava programmeerimiskeele parimast praktikast. Koodis kasutatavaid konstante ei tohi Arendaja Arhitekt 5.5 selle kasutamise kohta väärtusena hardcodeda – need tuleb defineerida muutujatena ja kasutada läbi nende. Koodis defineeritud andmetüübid N:Isik; Menetlus; jne. Andmebaaside struktuurikirjeldustes/andmemudelis ei tohi kasutada täpitähti. Arendaja Arhitekt 5.6 peavad olema nimetava käände ainsuses. Kõik andmemassiivid tuleb nimetada nimetava mitmuses (st igasugu collectionid, arrayd, jms).  Andmetabelites sisalduvad Kasutada tuleb konkreetse andmebaasisüsteemi nimetamise parimaid praktikaid. Nt kui on tegu Arendaja Arhitekt 5.7 võõrvõtmed peavad nime järgi tabelitega ’Isikud’ ja ’Autod’, siis seos ’isiku autod’ oleks: Isikud.ID=Autod.Isik_ID seostuma tabeli ja väljaga millele need viitavad. Andmebaasi väljade pikkused tuleb Selle asemel, et eraldada väljale x baiti, tuleb eraldada x tähemärki. (Instead of allocating x bytes of Arendaja Arhitekt 5.8 kirjeldada sümbolites, mitte baitides. storage for the field, x chars of storage must be allocated). Kui kokku pole lepitud teisiti, siis Checkstyle (http://checkstyle.sourceforge.net/) ei tohi käivitamisel järgmise konfiguratsioonifailiga Arendaja Arhitekt 5.9 JAVA rakenduse kood peab olema väljastada ühtegi viga. kirjutatud vastavalt "Oracle Java Code convention" dokumendile. Kui kokku pole lepitud teisiti, siis http://www.python.org/dev/peps/pep-0008/ Arendaja Arhitekt 5.10 Python rakenduse kood peab olema kirjutatud vastavalt "Style Guide for Python Code " dokumendile Kui kokku pole lepitud teisiti, siis .NET http://msdn.microsoft.com/en-us/library/ms229042.aspx Valideerimiseks kasutatakse 'StyleCop' Arendaja Arhitekt 5.11 rakenduse kood peab olema kirjutatud vaikimisi konfiguratsiooni vastavalt "NET Framework Developer's Guide - Design Guidelines for Developing Class Libraries". Koodi valideerimiseks kasutatakse https://sonar.sotsiaalministeerium.ee ( https://www.sonarqube.org/ ) Arendaja Arhitekt 5.12 minimaalselt TEHIK-u Sonarqube teenust. Kasutuses mitteolev kood tuleb Arendaja Arhitekt 5.13 rakenduse lähtekoodist kõrvaldada. Arendamisel kasutatakse DRY ja http://en.wikipedia.org/wiki/Don%27t_repeat_yourself Arendaja Arhitekt 5.14 SOLID printsiipe http://en.wikipedia.org/wiki/SOLID_(object-oriented_design) Üleantavas koodis ei tohi olla paroole, Kehtib ka siis, kui need on välja kommenteeritud. Kõik sellised paroolid tuleb asendada fraasiga Arendaja Arhitekt 5.15 mida on kasutatud arenduse käigus “<password>“. Rakenduste lähtekoodi tasemel ei tohi Eelpoolmainitu haldamine toimub failis või andmebaasis. Arendaja Arhitekt 5.16 olla ühtegi sisse kodeeritud parameetrit, veateadet. 6. Andmekvaliteet ja standardid Aadressiandmete sisestamisel, Liidestatakse maaameti X-tee teenusega. Arendaja Standardija 6.1 kuvamisel ja hoidmisel tuleb lähtuda Vabariigi Valitsuse määrusest https://www.riigiteataja.ee/akt/103102017005?leiaKehtiv Testija "Aadressiandmete süsteem". Rakendus peab võimalikult palju Välja arvatud logimisvormi lahtrid autentimisel Arendaja Testija 6.2 informatsiooni eeltäitma automaatselt (kirje sisestamise kuupäev, kasutaja nimi jne). Tegevusalade andmete sisestamisel, Arendaja Standardija 6.3 kuvamisel ja hoidmisel tuleb lähtuda Vabariigi Valitsuse 10. Testija Jaanuari 2008. a määrusest nr 11 "Klassifikaatorite süsteem" ja kasutada EMTAK infosüsteemis kehtivat klassifikaatorit. Tervishoiuteenuste osutajate andmete Liidestatakse Terviseameti x-tee teenusega Arendaja Testija 6.4 kasutamisel peab kontrollima nende andmeid, sh tegevuslubade kehtivust Terviseameti Tegevuslubade registrist Tervishoiutöötajate andmete Liidestatakse Terviseameti x-tee teenusega Arendaja Testija 6.5 kasutamisel peab kontrollima nende andmeid Terviseameti tervishoiutöötajate registrist Meditsiiniandmete vahetamiseks tuleb www.hl7.org Vajadusel on lubatud ka teiste standardite kasutamine, kuid see tuleb tellijaga eraldi Arendaja Standardija 6.6 kasutada meditsiiniandmete kokku leppida andmevahetuse standardit HL7 Testija Tervise valdkonna klassifikaatorid Võimalusel tuleb kasutada olemasolevaid OID-e ja klassifikaatoreid, mida vajadusel täiendatakse või Arendaja Standardija 6.7 peavad olema kooskõlas Tellija OID- luuakse uued ning publitseeritakse samuti publitseerimiskeskuses http://pub.e-tervis.ee ide ja publitseerimiskeskusega Tellija 7. Kasutajaliides Kasutajaliidese kõik Arendaja Projektijuht 7.1 disainiotsused peavad olema kooskõlastatud tellijaga enne nende realiseerimist Veebipõhine kasutajaliides peab Minimaalselt Internet Explorer, Mozilla Firefox, Chrome ja Safari arenduse testimise hetkel tootja Arendaja Testija 7.2 olema kasutatav enamlevinud poolt toetatud versioonid. Täpsemad nõuded dokumendis "Front-end arendusreeglid" veebibrauseritega, sh nutiseadmetel (Android, IOS) Rakenduse värviskeem ja logo Kui tegemist on struktuurfondide projektiga on lisaks nõutud ka vastav SF sümboolika. Tellija Arendaja Testija 7.3 kasutamine peab vastama Tellija ametlikud CVI esitluspõhjad, logo kasutusjuhend ja kõik logod (ka jpg-na) küsida tellijalt. ametlikule visuaalsele identiteedile (CVI) ja disainijuhistele (UIG). Kasutajaliidese kõik osad ja teated Kui soovitakse juurde eraldi ka muid keeli, siis see on spetsifitseeritud hankedokumentides Arendaja Testija 7.4 peavad olema eestikeelsed.  Avalikuks kasutamiseks tehtav Toetatud peavad olema vähemalt resolutsioonid: 1920x1200, 1920x1080, 1680x1050, 1600x1200, Arendaja Testija 7.5 rakendus peab olema graafiliselt 1440x900, 1360x768, 1280x1024, 1280x960, 1280x800, 1280x768, 1152x864, skaleeruv ja mugavalt kasutatav kõigi 1024x768, 1024x600. Ühegi nimetatud resolutsiooni korral ei tohi tekkida horisontaalset kerimisriba. enamlevinud arvutite monitoride resolutsioonidega. Sisemiseks kasutamiseks tehtav Toetatud peavad olema töökohaprofiilis loetletud resolutsioonid. Ühegi nimetatud resolutsiooni korral Arendaja Testija 7.6 rakendus peab olema graafiliselt ei tohi tekkida horisontaalset kerimisriba. skaleeruv ja mugavalt kasutatav TEHIKu töökohasprofiilis loetletud resolutsioonides. Hüpikaknaid (pop-up) ei tohi kasutada. Silmas on peetud uusi veebilehtiseja aknaid avavaid hüpikaknaid Arendaja Testija 7.7 Kasutajaliideses toiminguni (põhi- ehk Kõik rakenduse kasutajaliidesest tehtavad toimingud tohivad üksteisest olla maksimaalselt 3 Arendaja Testija 7.8 enamkasutatavad tegevused) hiirekliki kaugusel. Toimingut ei pea nende 3 klikiga tehtud saama. Väljalogimise nupp/link peab navigeerimiseks peab kehtima 3 kliki olema ühe kliki kaugusel ja arusaadavas/intuitiivses kohas. printsiip, väljalogimiseks 1 kliki printsiip. Kasutajaliides peab alati küsima Arendaja Testija 7.9 kinnituse andmete kustutamise ja massmuutmiste kohta kui pole kokku lepitud teisiti. Rakenduse kasutamisel tekkinud Veateated peavad olema sellised, mis võimaldavad IT-abil võimalikult lihtsalt tuvastada vea olemuse Arendaja Testija 7.10 veale peab kasutajaliides vastama ja asukoha. kasutajale eestikeelse kasutajasõbraliku veateatega, mis sisaldab soovituslikult ka vea koodi. Veateated peavad olema hallatavad. Kasutajaliides peab olema ilma Uue keele lisamine peab olema teostatav konfiguratsiooni failist või administreerimisliidesest. Arendaja Testija 7.11 rakenduse koodi muutmata tõlgitav teise keelde, v.a kui ei ole kokkulepitud teisiti. Rakenduse tausta, menüüde ja teksti Arendaja Testija 7.12 värvid peavad olema ilma rakenduse koodi muutmata vahetatavad. Rakenduse kasutajaliides peab Ette teavitamise aeg peab olema konfigureeritav. Arendaja Administraat 7.13 teavitama kasutajat ette sessioon or aegumisest. Testija Kui vormile sisestatakse mahukaid Kui vorm koosneb paljudest väiksest andmeväljadest (nt taotlus), siis jagatakse vorm etappideks Arendaja Testija 7.14 andmevälju peab kasutajaliides kokku ning salvestatakse vastava etapi lõpus. lepitud ajavahemike järel salvetama välja sisu, et sessiooni aegumisel või võrgu katkestuse korral juba sisestatud andmed ei kaoks. Sisestusvormidel andmete Arendaja Testija 7.15 sisestamisel peab saama väljade vahel vastavalt äriloogikale liikuda klaviatuuri abil tabulaatoriga. Interaktiivsete vormide puhul (näiteks Arendaja Testija 7.16 faili üleslaadimine), ei tohiks lehe värskendamisega tegevust korrata (faili taas üles laadida, andmeid saata, avaldust esitada). Kui päring võtab aega kauem kui 3 Ikoon peab muutuma liivakellaks ja/või kuvatakse teade: päringut sooritatakse või muu tellijaga Arendaja Testija 7.17 sekundit, peab kasutaja saama kokkulepitud indikaator. visuaalse teate, et süsteem tegeleb päringu läbiviimisega. Esilehel (sisselogimata) ja ka pärast Näiteks võimalikud teavituses: mingi süsteemi osa on vigane, tuli mingi uus funktsionaalsus, Arendaja Testija 7.18 kasutaja sisselogimist peab olema vahetage oma parool, uuendage isikuandmeid jne. lihtne võimalus teavitada kasutajat muudatustest või probleemidest. Teavitus peab olema halduri poolt lihtsalt lisatav ja olema kasutajale märgatav. Nutiseadmetele tuleb luua eraldi See vajadus spetsifitseeritakse arenduse tellimisel. Arendaja Testija 7.19 kohaldatud kasutajaliides. Päringu vastusena kuvatud tabeli Arendaja Testija 7.20 veerge on võimalik andmete/teksti tähestikulises järjekorras sorteerida. Andmeväljade kohustuslikkus peab Arendaja Testija 7.21 olema infosüsteemi väljadel märgitud tärniga (*). Rakenduse andmeväljade mõisted Arendaja Testija 7.22 peavad olema üheselt identifitseeritavad, korrektses eesti keeles (ilma kirjavigadeta) ja vajadusel sisaldama selgitavat teksti. Abiinfo (kasutusjuhendid) peab olema kättesaadav rakenduse toimimise erinevatel etappidel. Kasutajaliides peab vastama ka Front-end arendusreeglid Testija 7.23 dokumendis "Front-end arendusreeglid" kirjeldatud reeglitele 8. Dokumentatsioon Lõppkasutajatele ja avalikkusele Erandiks võivad olla kolmanda osapoole komponentide (mis pole kirjutatud tellija jaoks) Arendaja Projektijuht 8.1 suunatud rakenduse dokumentatsioon dokumentatsioon. Samuti võib erandiks olla välispooltega seotud projektid. Erandid tuleb peab olema kirjutatud eesti keeles. kooskõlastada tellijaga enne dokumentatsiooni koostamist Arhitekt Administraat or Testija Infoturbe spetsialist Lahendus kirjeldatakse RIHA https://www.riigiteataja.ee/akt/12933746?leiaKehtiv#para6 Arendaja Projektijuht 8.2 määruse nõuete kohaselt. Projektijuht RIHA haldur Tellija RIHA haldur Rakenduse dokumentatsioon peab Dokumentatsioon peab olema versioneeritud, muutmiskuupäevadega, autori nimedega, korrektse Arendaja Projektijuht 8.3 vastama ka dokumendis "Nõuded keelekasutusega, selge struktuuriga. Dokumentatsiooni detailsus peab olema piisav, et sõltumatu infosüsteemi dokumentatsioonile" kolmas tehnliste IT baasteadmistega isik suudaks dokumendist vajalikke järeldusi teha (st dokument Arhitekt kirjeldatud nõuetele peab olema arusaadav sellele isikule, kuid näiteks paigaldusjuhise järgi toimetades ei pea ta ebaõnnestunud tarnele teostama veaanalüüsi). Administraat or Testija Nõuded infosüsteemi dokumentatsioonile Infoturbe spetsialist Rakenduse dokumentatsioon peab Esialgne kirjete mahu hinnang peab tulema lähteülesandest, ning täpsustuma eel- ja detailanalüüsi Arendaja Projektijuht 8.4 sisaldama tabelite-andmete-logide käigus. Mahuhinnang peab sisaldama ka logide säilitamise, arhiveerimise tähtaegu. mahu kasvu arvestuslikku hinnangut Arhitekt rakenduse sihipärase kasutamise korral ettenähtud arvu kasutajate Administraat poolt. (MB/GB kuus/aastas). or Infoturbe spetsialist Iga uue versiooniga peab alati välja Release notes peab kajastama kõiki muudatusi eelmise ja uue versiooni vahel. Arendaja Projektijuht 8.5 tooma versiooni muudatuse kirjeldused (release notes). 9. Versioonihaldus Kogu rakenduse testimiseks, Arendajale antakse selleks õigused Tellija versioonihalduse repositooriumi, kus ta peab hoidma oma Arendaja Arhitekt 9.1 koolituseks või implementeerimiseks erinevaid versioone. Versioonihalduse repositooriumi juurdepääsutaotlus esitatakse Tellija üle antav lähtekood ja tarkvarapaketid kasutajatoele läbi projektijuhi. Administraat peavad olema versioneeritud. or Kasutama peab Tellija versioonihalduse ja tehiste (artifaktide) repositooriumi. Arendaja peab veenduma, et teeb Hea tava on, et paralleelse arendamise puhul võetakse igal hommikul versioonihalduse Arendaja Arhitekt 9.2 muudatusi aktuaalsesse koodi. repositooriumist viimane seis koodist. Administraat or Nii arendamisel kui ka Arendajale antakse selleks õigused Tellija tööde ja veahalduse keskkonda. Juurdepääsutaotlus Arendaja Projektijuht 9.3 hoolduslepingute korral kasutatakse esitatakse Tellija kasutajatoele läbi projektijuhi. Tellija tööde ja veahalduse keskkonda. 10. Paigalduspaketi kooste Juhul kui versioonihalduse keskkond Räsialgoritmiks tuleb kasutada SHA256. Linuxi käsurealt kontrollkoodi koostamiseks: $ sha256sum Arendaja Administraat 10.1 ei paku paigalduspaketile filename [filename2] ... > kontrollkood.sum. or kontrollsumma (checksum) automaatset koostamist, siis koostatakse kontrollsumma arendaja poolt ja pannakse eraldi .sum failina tarnele kaasa. Tarnitava lahenduse koosseisus üle Näiteks võib lahenduse paigalduspaketi koosteprotsess ette näha, et käivitada tuleb rida shell-käske Arendaja Projektijuht 10.2 antava lähtekoodiga peavad kaasas või võivad lahenduse koosseisus olla valmis (ant, ..) koosteskriptid või mis iganes muu moodus olema kirjeldused sellest paigalduspaketi tekitamiseks. Administraat paigalduspaketi koosteks. or Eelistatud on kasutada Dockerfile ja Gitlab töövooge. Kooste kirjelduste alusel valmiv Näiteks: kompileeritavate keelte puhul ei tohi sisaldada lähtekoodi, kui see pole vajalik rakenduse Arendaja Arhitekt 10.3 paigalduspakett tohib sisaldada ainult käitamiseks. minimaalse rakenduse käitamiseks Administraat vajamineva failikomplekti. or Kooste kirjelduste alusel valmivat Näiteks ei tohi tekitada olukorda, kus rakenduse jooksutamiseks uues serveris tuleb see tingimata Arendaja Administraat 10.4 paigalduspaketti peab olema võimalik just sealsamas kokku kompileerida. or liigutada erinevate masinate vahel. Rakenduse kõik sõltuvused peavad Arendaja Arhitekt 10.5 olema kompileerimisel saadavad Tellija tehiste repositooriumist (repo. tehik.ee). Andmebaasi paigalduse skriptid ei Administraator tahab veenduda skripti sisus. Arendaja Administraat 10.6 tohi olla kompileeritud. or  Rakenduse lähtekoodi juures peab Tellijal peab olema võimalik suuri pingutusi tegemata ja keskkonna erinevusi vältides teha Arendaja Arhitekt 10.7 leiduma skriptid rakenduse rakendusest paigaldatav pakk. keskkonnast sõltumatult (konteinerlahenduses) kokku kompileerimiseks. Rakenduse lähtekoodi juures peab Vajadusel peab konteinerlahendus käivitama ka rakenduse muud sõltuvused (näiteks andmebaas). Arendaja Arhitekt 10.8 leiduma skriptid rakenduse lokaalselt See on Täitjale uue meeskonnaliikme liitumise lihtsustamiseks ja Tellijale võimalus suuri pingutusi mõnes konteinerlahenduses (Docker) tegemata süsteemi testimiseks. käivitamiseks. Paigalduspakett koostatakse Tellija Erandid lepitakse kokku tellija arhitektiga. Arendaja Arhitekt 10.9 pideva integratsiooni (continuous integration - CI) keskkonnas.  Nõuded infosüsteemi dokumentatsioonile Nõuded infosüsteemi dokumentatsioonile Versioon: 1.0 Dokumendid peavad vastama vähemalt alljärgnevatele tingimustele: Andmemudel Eeldus dokumendile: Teenuste/kasutuslugude dokumentatsioon Otstarve: Kirjeldada andmeobjekte ja nendevahelisi seoseid Sisu: Andmebaasi põhjal luua andmetabelite ja -objektide seosdiagramm. Sihtgrupp: Tellija, peakasutajad, rakenduse administraatorid Ajakava: enne esimese arendusetapi algust enne igat arendusetapi algust igakordsel tellijale testimisse andmisel Kirjeldada andmemudelit kontseptuaalse mudelina jah jah interaktioone/seoseid Kasutaja õiguste ja tegevuste vastavustabel Eeldus Süsteemi üldine kirjeldus dokumendile: Otstarve: Kirjeldada kasutaja rollide õigusi erinevates kasutuslugudes ja tegevustes Sisu: CRUD maatriks Sihtgrupp: Tellija äriprotsesse valdavad kontaktisikud, ärianalüütikud, süsteemianalüütikud, täitjast sõltumatud tarkvara hooldajad, arendajad ja edasiarendajad, testijad, arhitektid, projektijuhid. Ajakava: enne esimese arendusetapi algust enne igat arendusetapi algust igakordsel tellijale testimisse andmisel Nimetada kasutaja rollid jah Teenuste/kasutuslugude dokumentatsioon Eeldus Süsteemi üldine kirjeldus dokumendile: Otstarve: Kirjeldab detailselt üleantavaid teenuseid/kasutuslugusid. Sisu: Teenuste/kasutuslugude detailse kirjelduse sisuks on: Tehnilised parameetrid; Veateated/Hoiatused; Teostatavad kontrollid; Funktsionaalsuse enda põhiprotsess ja mõned sagedamini esinevad alternatiivsed protsessid (vastavalt vajadusele); Üldine kirjeldus, kuidas ja kus kajastub antud teenus/kasutuslugu tervikprotsessis; Nõudeid ja reegleid toetavad (sisu mõistmisele kaasaaitavad) pildid, diagrammid, tabelid, loendid Andmevahetuse teenuste kirjeldus (andmete küsimine/vastuvõtmine, turvalisus, teenuse andmestik, klassifikaatorid, xml/xsd schema ) Protsesside UML vaated Sihtgrupp: Tellija äriprotsesse valdavad kontaktisikud, ärianalüütikud, süsteemianalüütikud, täitjast sõltumatud tarkvara hooldajad, arendajad ja edasiarendajad, testijad, arhitektid, projektijuhid. Ajakava: enne esimese arendusetapi algust enne igat arendusetapi algust igakordsel tellijale testimisse andmisel Nimetada kasutuslood jah Arhitektuuridokument Eeldus Süsteemi üldine kirjeldus dokumendil e: Otstarve: Dokumendi eesmärgiks on kirjeldada loodava süsteemi üldist ehitust. Kirjeldatakse rakenduse loogilist struktuuri, näidates ära selle kihtideks jagunemise korda. Kirjeldatakse ka füüsilist arhitektuuri, antakse ülevaade kasutatavatest tehnoloogiatest ning vahenditest. Sisu: Dokument peab rahuldama vähemalt alljärgnevaid sisunõudeid: 1. topoloogia, süsteemi füüsiline arhitektuur (süsteemi komponendid andmebaasiserver, rakendusserver, meiliserver jms) 2. Nõuded arhitektuurile (operatsioonisüsteem, andmebaasid, liidestused, rakendusserverid, raamistikud, teenused) 3. Nõuded käideldavusele (süsteemi soovituslikud näitajad komponentide kaupa, näiteks andmesidekiirused, kättesaadavus, andmemahud, protsessori kiirus, mälumaht, komponentide arv süsteemi osade kaupa, kettasüsteemi jõudlus jms) 4. liidesed teiste süsteemidega (x-tee, meilisüsteemid) ja sõltuvused teistest süsteemidest. Liideste kirjeldused/otstarve 5. süsteemi tehnilised (sh automaatsed) protsessid ehk töövoog – komponentide omavahelised suhtlusstsenaariumid ja koostoimimine (näiteks, mis komponent ja millal pöördub n teenuse poole) 6. kolmandate osapoolte poolt toodetud kasutatavad tarkvarad/riistvarad, mis on vajalikud süsteemi toimimiseks Sihtgrupp: Arhitekt, administraator, turvaspetsialist Ajakava: enne esimese arendusetapi algust enne igat arendusetapi algust igakordsel tellijale testimisse andmisel Dokumendi esialgne versioon jah Seadmete ja tarkvara kasutajakesksed juhendid Eel Teenuste/kasutuslugude dokumentatsioon dus dok um end ile: Ots Teenuse funktsionaalsuse kasutamiseks ja kasutuslugude läbimiseks vajalikud juhised tarv e: Sis Igale esitluskihile peab olema koostatud eraldi kasutusjuhend, mis kirjeldab vastava komponendi funktsionaalsuse kasutusvoo põhiselt. Kirjeldus tarkvara ja u: seadmete kasutamise üldisest protsessist, protsessi olulisemate sammude kirjeldus. Koostatakse projekti lähteanalüüsi aluseks võttes. Tarkvara kasutusjuhend on aluseks kasutajate koolitamisel. Kasutajajuhend kirjeldab kõiki kasutajate funktsionaalsusi koos tööprotsesside kirjeldusega ning ekraanipiltide vormis näidetega. Haldusliidese kasutusjuhend (peakasutaja ja rakenduse administraatori funktsionaalsus) peab olema eraldi tavakasutaja kasutusjuhendist. Esitluskihi kasutusjuhendi minimaalne ülesehitus: lühitutvustus üldine kirjeldus koos komponentidega autentimine (kui eksisteerib) komponentide detailne kirjeldus koos kõikide funktsionaalsustega Rollide kirjeldus ja õigused Siht Tarkvara kasutajad, peakasutaja, rakenduse administraator gru pp: Aja enne esimese arendusetapi algust enne igat arendusetapi algust igakordsel tellijale testimisse andmisel kav a: jah Paigalduse ja administreerimise juhend Eeldus dokumendil Arhitektuuridokument e: Süsteemi üldine kirjeldus Otstarve: Juhend on aluseks süsteemi administreerimisele Sisu: Juhend peab rahuldama vähemalt alljärgnevaid sisunõudeid: 1. süsteemi parameetrite (seadistuste) kirjeldus ning nende muutmiste mõjud ja protseduurid. Konfiguratsioonifailide kirjeldus koos asukohtadega failisüsteemis; 2. logimise realisatsiooni kirjeldused (kuhu, mida, logide struktuur 3. rutiinsete hooldusprotseduuride kirjeldus (komponentide taaskäivituse vajadus parameetrite muutmisel); 4. paigaldamise protseduurid. 4.1 Nõuded rakenduse komponentidele 4.2 Rakenduse paigaldus (Vajalik tarkvara ja konfigureerimine, rakenduse pakkimine ja paigaldamine) 4.3 Andmete alglaadimine 4.4 Varundusskript 4.5 Monitooringu kirjeldus Juhendis kirjeldatakse iga realiseeritud osa rakendamine (deployment) koos spetsiifiliste seadistustega. Paigaldamise protseduurid peavad olema kirjutatud selliselt (samm sammult), et süsteemiadministraator suudab rakenduse paigaldada ilma kõrvalise abita. Sihtgrupp: Peakasutaja, projektijuht, süsteemiadministraator Ajakava: enne esimese arendusetapi algust enne igat arendusetapi algust igakordsel tellijale testimisse andmisel jah Lähtekood (sh andmebaasi struktuur) Eeldus dokumendile: Arhitektuuridokument Teenuste/kasutuslugude dokumentatsioon Andmemudel Kasutaja õiguste ja tegevuste vastavustabel Prototüüp Otstarve: Lähtekood on vajalik selleks et kompileerida rakendust, ning võimaldada tulevikus rakenduse muutmist. Sisu: Lähtekood peab olema hästi struktureeritud, piisavalt dokumenteeritud ning võimalikult lihtne, et sellest saaksid aru ka teised arendajad. Lähtekood peab vastama MFNile Lähtekood peab olema pakendatud vastavalt versioonimisjuhendile. Rakenduste lähtekood peab olema piisavalt modulaarne, et seda saaks tulevikus lihtsasti täiendada ning muuta. Ajakava: enne esimese arendusetapi algust enne igat arendusetapi algust igakordsel tellijale testimisse andmisel Versioonihaldus tuleb teha Tellijakeskkonnas (nt Gitlab), sh ka jooksvaid commit’e Koormustestide dokumentatsioon Eeldus dokumendile: Teenuste/kasutuslugude dokumentatsioon Prototüüp (ainult kasutajaliidesega rakenduse puhul) Arhitektuuridokument Otstarve: Määrata kindlaks arendusetapil testitavad kasutuslood ja liidesed (sh välja tuua need, mille puhul rakendatakse koormusteste) tuues välja nende järjekorra. Sisu: Järjestatud (võib olla ka paralleelne) nimekiri kasutuslugudest ja liidestest (vajadusel määrates nende ulatust) koos märkega, mis on koormustestiga tagatud ning millel on testandmed Sihtgrupp: Tellijapoolne projektijuht, vastuvõtutestijad Ajakava: enne esimese arendusetapi algust enne igat arendusetapi algust igakordsel tellijale testimisse andmisel Nimetada kasutuslood, mille puhul rakendatakse koormusteste jah Testimise tulemite dokumentatsioon Eeldus Koormustestide dokumentatsioon dokume ndile: Otstarv Anda tellijale ülevaade läbiviidud testimise tulemustest ning esitada soovitused testandmete ja dokumentatsiooni parendamiseks (ettevalmistus, paigaldus, e: kasutuslugude kirjeldus jne). Sisu: Teostatud arenduste testimisel saadud informatsioon (näiteks testlood, testraport, testiplaan, testide kood jms). Dokumenteeritakse iga testimise eesmärgid (testimise maht ja ulatus), tegevused ja tulemused. Sisaldab jõudlus- ja mahutestide infot ning versiooni infot. Teste mitteläbinud testlugudele on lisatud parandused või ülesjäänud vead. MFNi vastavustabel Sihtgru Arhitekt, süsteemiadministraator, turvaspetsialist pp: Ajakava: enne esimese arendusetapi algust enne igat arendusetapi algust igakordsel tellijale testimisse andmisel jah Automaattestimise tulemite dokumentatsioon Eeldus dokumendile: Lähtekood (sh andmebaasi struktuur) Otstarve: Anda tellijale ülevaade läbiviidud automaattestimise tulemustest. Sisu: Ülevaade SonarQube’is (testide nimekiri, testide käivitamise tulemus, koodi kaetavus). Sihtgrupp: Arhitekt, süsteemiadministraator, turvaspetsialist Ajakava: enne esimese arendusetapi algust enne igat arendusetapi algust igakordsel tellijale testimisse andmisel jah Taasteplaani tegemise juhend Otstarve: Kirjeldada erisused, millega tuleb arvestada taasteplaani loomisel Sisu: Taasteplaan peab rahuldama vähemalt alljärgnevaid sisunõudeid: 1. süsteemi halvamist võimaldavad riskid ja nende esinemise võimalikkus; 2. varundamisele kuuluvate komponentide ja asukohtade loetelu (nt rakenduse konfiguratsioonifailid rakendusserverist ja andmebaas jne), nende kirjeldused ja kasutuselevõtu protseduurid; 3. süsteemi komponentide asendusvõimalused, nende alternatiivkomponentide spetsifikatsioonid Sihtgrupp: Arhitekt, süsteemiadministraator, turvaspetsialist, äri, tellijapoolne projektijuht Ajakava: enne esimese arendusetapi algust enne igat arendusetapi algust igakordsel tellijale testimisse andmisel jah Üldised nõuded: Üleantav dokument peab sisaldama sisseviidud muudatusi nii, et on väljatoodud muutunud ja lisandunud osa (võrreldes viimati üleantuga).  COVID-19 kriisiolukorra tööd tervise valdkonna andmeladudes Lisa 1 - Tehniline kirjeldus Teenuse/projekti taust Siiani on tervise infosüsteemi TIS aruandlus realiseeritud kasutades SYBASE IQ andmebaasimootorit, mis on suhteliselt aegunud ja aeglane tehnoloogia. Uute arenduste jaoks on TEHIK-ul loodud keskkond, mis baseerub kaasaaegsel ja kiirel Vertica andmebaasimootoril ning lähitulevikus on tegelikult plaanis kogu aruandlus üle viia uude keskkonda, kuna pikas perspektiivis vana tehnoloogia kaua vastu ei pea. COVID-19 kriisi alguses alustati kriisiga seotud täiendavate aruandluslahenduste loomist uuel platvormil, st Vertical. Paraku laetakse osa vajalikke andmeid ikkagi läbi vana keskkonna (Sybase IQ). See mõjutab otseselt COVID-19 aruandluse toimimist, kuna tekib pudelikael, mis ei lase Vertica aruandlusjõudlust piisava võimsusega kasutada. Samuti nõuab täiendavate aruandlusvajaduste realiseerimine hetkel arendustöid kahes erinevas keskkonnas, mis raiskab kriitilist tööjõuressurssi ja kasvatab arendustöödele kuluvat aega. Et tagada operatiivne kriisiga seotud andmetöötlus ja kriisijuhtide õigeaegne informatsiooniga varustamine tuleb COVID-19 aruandluse puhul alustada aruandluse täielikku üleviimist Vertica platvormile viivitamatult. Soovitud lahendus 1. Tellija soov on sõlmida hankeleping, et pakkuja saaks koostöös Tellijaga operatiivselt tegeleda väikearenduste ja hooldustöödega, mis puudutavad mis on vajalikuks saanud seoses riigis välja kuulutatud eriolukorraga. 30.04.20 seisuga teadaolevad arendused, mis on vaja teostada: 1.1. TIS Sybase IQ andmelaost vajalike lähtetabelite ja seal COVID-19 aruandluse tarvis genereeritud tabelite üleviimine Vertica platvormile. Kasutusel on tabelid: 1.1.1. Ambulatoorsed epikriisid koos diagnoosidega:  dwh.dwh.DWH_EPICRISIS_CASE_AMB  dwh.dwh.DWH_EPICRISIS_DIAGNOSIS_AMB 1.1.2. Testide jaoks  dwh.dwh.DWH_DIR_DOC_RSP_ANA  dwh.dwh.DWH_DIR_DOC_RSP_CASE 1.1.3. Täiendavad tabelid  dwh.dwh.DIM_PATIENT  dwh.dwh.DIM_PATIENT_ADDR  dwh.dwh.DIM_TTO 1.2. Verticas Medsitrep andmestikule juurde tekitada isikustamata PID ja PID_OID. Verticas on kasutusel skeem „medsitrep“ ning tabelid ja vaated ta_koroona_avaandmed.* schema all. 1.3. Tuleb leida lahendus Sybase’i loetletud andmete püsivaks sünkroniseerimiseks Vertica poolele ning nende kokku viimiseks Medsitrep andmetega. 2. Seoses eriolukorra esinemisega võib lisanduda täiendavaid töid, mis ei ole käesolevas dokumendist loetletud. 3. Kõigi lepingu raames teostatavate arenduste ja tööde eesmärk on teha asjaosalistele kättesaadavaks andmed kriisiolukorra operatiivseks juhtimiseks. Hankelepingu alusel ei ole lubatud tellida töid, mis ei ole seotud eriolukorraga. 4. Arendustöid hallatakse Tellija JIRA keskkonnas. 5. Arendused paigaldatakse tellija keskkonda ning olemasolevad komponendid ja süsteem töötab pärast muudatuste või uue funktsionaalsuse lisamist endiselt vastavalt nõuetele. Töö üleandmine ja vastuvõtmine toimub akti mõlemapoolse allkirjastamisega. Täitja annab nõuetekohaselt teostatud töö üle poolte vahel kokkulepitud tähtajal omalt poolt allkirjastatud aktiga. Nõuded täitja meeskonnale Hankelepingu täitmiseks peab Täitjal olema võimalik komplekteerida riigihanke vastavustingimustele vastav meeskond järgmistes rollides: a) projektijuht, kes koordineerib Täitja poolt kirjeldatud tööde teostamist ning dokumenteerimist ja pakub nende ettevalmistamisel konsultatsioone. On Tellijale kontaktisikuks tööde teostamise ning üleandmise käigus; b) analüütik, kes analüüsib, spetsifitseerib ja dokumenteerib vajalikud tööd koostöös Tellija ja rakenduse lõppkasutajatega; c) arendaja, kes teostab Täitja poolt kirjeldatud töid ning vastavalt kokkuleppele pakub Tellijale tööde ettevalmistamisel ja/või teostamise järgselt konsultatsioone ning koolitusi; d) 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. Täitja kinnitab, et tagab tööde teostamiseks järgmistes rollides ja nõuetele vastava meeskonna. Kui hankijal on kahtlus meeskonnaliikme pädevuses, on hankijal õigus nõuda meeskonnaliikme pädevuse tõendamist ja/või nõuda meeskonnaliikme väljavahetamist. Rolli nimetus Arv Kvalifikatsiooninõuded Arendaja 1  omab minimaalselt 24 kuulist Sybase IQ ja Vertica kogemust Testija 1  osalenud testijana vähemalt ühes arendusprojektis, kus on rakendatud HL7 standardit Analüütik 1  omab kõrgharidust;  HL7 standardiga ja UML töötamise kogemus ning on osalenud süsteemianalüütikuna vähemalt kahes HL7 standardit rakendanud arendusprojektis; Projektijuht 1  omab kõrgharidust;  osalenud projektijuhina vähemalt kahes arendusprojektis;  vähemalt 24 kuuline tarkvaraarendusprojektide juhtimise kogemus.  Projektijuhi puhul tuleb esitada eestikeelne CV. CV´s tuleb ära tuua, millistes projektides kogemus on omandatud, iga projekti kohta vähemalt: o projekti tellinud asutus ja tellija kontaktisik, o projekti nimi.  COVID-19 kriisiolukorra väikearendus- ja hooldustööd tervise valdkonna andmeladudes Hankeleping nr 3-9/2227-1 Tervise ja Heaolu Infosüsteemise Keskus (edaspidi tellija), registrikood 70009770, aadress Uus-Tatari 25, 10134 Tallinn, keda esindab põhimääruse alusel direktor Katrin Reinhold ja OÜ Resta, (edaspidi täitja), registrikood 10320415, aadress Ülikooli tn 2a, 51003 Tartu linn, keda esindab volituse alusel Riin Tillmann, edaspidi koos või eraldi nimetatud ka pool või pooled, sõlmisid seoses eriolukorraga tellija poolt korraldatud väljakuulutamiseta läbirääkimiste tulemusena käesoleva hankelepingu (edaspidi leping) alljärgnevas: 1. Lepingu eesmärk ja ese 1.1. Hankelepingu eesmärk on teostada väikearendus- ja hooldustöid tervisevaldkonna andmeladudes seoses eriolukorrast tulenevate kriitiliste andmevajadustega. 1.2. Hankelepingu esemeks on COVID-19 tõttu väljakuulutatud eriolukorraga seoses tehtavad kiired väikearendus- ja hooldustööd, mis on täpsemalt kirjeldatud lisas 1 tehniline kirjeldus (edaspidi tööd). 1.3. Lepingu tööde maht on maksimaalselt 50 000 eurot käibemaksuta ja leping kehtib kuni 31.08.2020. Leping lõppeb mahu täitumisel või tähtaja saabumisel või muul lepingus nimetatud alusel. 1.4. Leping ei kohusta tellijat konkreetseid töid ega konkreetses mahus tellima. Töid teostatakse üksnes vastavalt reaalselt esitatud tellimustele. 1.5. Lepingu lahutamatuks osaks on kõik lisad ja täitja esitatud pakkumus. 2. Üldtingimused 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õik lepingust tulenevad kohustused. 2.2. Tellijal on õigus jooksvalt kontrollida lepingu täitmise käiku. Tellijal on õigus anda täitjale suuniseid lepingu täitmiseks ning täitja on kohustatud neid järgima. Täitja on kohustatud viivitamatult informeerima tellijat lepingu täitmist takistavatest asjaoludest. 2.3. Täitjale laieneb ka nende tööde ja toimingute, sh kõrvalkohustuste, teostamise ning teenuste osutamise kohustus, mis ei ole lepingus sätestatud, kuid mis oma olemuselt kuuluvad lepinguga seotud tööde hulka. Nimetatu ei kuulu teistsuguse kokkuleppe puudumisel eraldi tasustamisele. 2.4. Täitja on kohustatud teostama tööd omal kulul ja vastutusel hoolikalt ning professionaalsel tasemel kooskõlas lepingu, õigusaktide, oma tegevus- või kutsealal kehtivate standardite ja heade kommetega ning andma need tellijale või tema poolt osutatud isikutele üle kokkulepitud ajal ja korras. 2.5. Täitja teavitab tellijat kirjalikku taasesitamist võimaldavas vormis oma mistahes huvist, mis võib põhjustada lepingu täitmisel huvide konflikti tekkimist. 2.6. Tellija tagab täitjale töö tegemiseks vajalikud tingimused. 1  2.7. Poolel on õigus teha teisele poolele ettepanekuid töö kvaliteedi tõstmiseks. Kui pool on esitanud teisele poolele tellimuse täitmisega seotud küsimuses päringu, on pool kohustatud sellele sisuliselt reageerima (asjakohast tagasisidet andma) võimalikult kiiresti, kuid tööpäevadel mitte hiljem kui 4 tunni jooksul. 2.8. Pooltel on kohustus osa võtta töökoosolekutest töö käigus tekkinud probleemide lahendamiseks ja infovahetuseks tellija juures kohapeal või virtuaalselt. Töökoosolekutel osalemist tellija ei tasusta, välja arvatud juhul, kui tellimuses on kokku lepitud teisiti. 2.9. Tööde teostamise keel on eesti keel, muuhulgas on see ka tellimuste esitamise, töökoosolekute jm suhtluse ning tööde dokumenteerimise keel. 2.10. Pooled võivad vajadusel kaasata tööde kvaliteedi ja/või turvalisuse hindamiseks välise eksperdi või audiitori. 2.11. Nõuded dokumentatsioonile ja kasutusjuhenditele tulenevad järgnevatest dokumentidest: 2.11.1. Lisa 2 - Mittefunktsionaalsed nõuded; 2.11.2. Lisa 3 - Nõuded infosüsteemi dokumenteerimisele. 2.11.3. Nendest nõuetest on lubatud kõrvale kalduda ainult kokkuleppel tellijaga. 2.12. Töömahu täitumise osas peab arvestust täitja. Töömahu arvestuse alusel koostab täitja tööde üleandmise-vastuvõtmise akti (edaspidi akt), mille vorm on leitav lepingu lisas 4. 3. Poolte õigused ja kohustused 3.1. Täitja kohustub: 3.1.1. teostama tööd tellimustes kokkulepitud tingimustel ja ulatuses, sh tagama tööde õigeaegse alustamise, teostamise valmimise ja tellijale üleandmise; 3.1.2. tagama tellimuse täitmiseks vajalike ressursside olemasolu, sh tagama tööde teostajate kõrge professionaalse taseme ning vajaliku tehnoloogia ja metoodikate väga hea tundmise ning tehtud tööde dokumenteerimise vastavalt tellija 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; 3.1.3. tegema koostööd tellija palvel kolmandate osapooltega (nt äritellijaga, teiste tellija arenduspartneritega jne); 3.1.4. andma selgitusi ja konsultatsioone teostatud tööde kohta; 3.1.5. informeerima viivitamatult tellijat tööde teostamist takistavatest asjaoludest, mis segavad tellimuses toodud tööde teostamist ja tähtaegadest kinnipidamist või püstitatud eesmärgi saavutamist; 3.1.6. juhinduma tellija suunistest tellimuse eesmärkide saavutamisel, pöördudes juhiste saamiseks või läbirääkimisteks vajadusel tellija poole. Töö käigus tuvastatud vastuolu korral teavitab täitja vastuolu esinemisest tellijale viivitamatult; 3.1.7. täitma kõiki tellija juures kehtivaid ja õigusaktidest tulenevaid andmekaitsealaseid ja andmete turvalisust puudutavaid eeskirju, kui need on täitjale teatavaks tehtud; 2  3.1.8. arvestama, et ärinõuete täitmiseks võib olla vajadus muuta ja täiendada olemasolevat koodi ning tagama protsesside ja funktsionaalsuse tervikluse pärast koodi muutmist või täiendamist; 3.1.9. teostama tööd kuni kokku lepitud tulemi üleandmise ja vastuvõtmiseni oma ressursside arvel, kui pooled ei ole kokku leppinud teisiti; 3.1.10. kasutama tööde teostamisel tellija tööajahalduse ja projektijuhtimiskeskkondi, mis on täitjale kättesaadavaks tehtud; 3.1.11. järgima hankelepingu lisades toodud nõudeid tööde teostamisel; 3.1.12. töötunni põhiselt tellitavate tööde puhul esitama tellijale tööde teostamise ajaaruandeid; 3.1.13. tagama rakenduste hooldusteenuste osutamiseks valmisoleku ja omapoolse abi kuni veaolukorra kõrvaldamiseni vastavalt tehnilises kirjelduses toodud tingimustele, vajadusel ka väljakutse korras kohapeal; 3.1.14. osutama tellijale teostatud töö osas tuge, sh pakkuma konsultatsiooni kuni garantiiaja lõpuni. 3.2. Täitjal on õigus: 3.2.1. saada tööde teostamise eest tellimuses kokkulepitud ulatuses ja korras tasu; 3.2.2. kasutada tööde teostamisel alltöövõtjaid, kooskõlastades alltöövõtjate kasutamise eelnevalt tellijaga. Alltöövõtjate tegevuse ja tegevusetuse eest vastutab tellija ees täitja. 3.3. Tellija kohustub: 3.3.1. tasuma täitjale vastu võetud tööde teostamise eest tellimuses kokkulepitud ulatuses ja korras; 3.3.2. tagama täitjale ligipääsu (sh kaugjuurdepääsu) tööde teostamiseks vajalikule informatsioonile ja keskkondadele, mis võivad olla tellimuse täitmiseks olulised või mida täitja mõistlikkuse piirides tellimuse täitmiseks nõuda võib; 3.3.3. tagama tööde teostamiseise perioodil nende tellija hallatavate infotehnoloogiliste keskkondade korrektse toimimise, mis on olulised täitja poolsete kohustuste täitmiseks; 3.3.4. võtma aktiga vastu täitja poolt üle antud puudusteta tööd mõistliku aja jooksul või vastavalt tellimuses kokku lepitud tähtajale; 3.3.5. teavitama täitjale üle antud töödes esinevatest puudustest ja andma puuduste kõrvaldamiseks mõistliku täiendava tähtaja, kui tähtaeg ei tulene muudest kokkulepetest. 3.4. Tellijal on õigus: 3.4.1. kontrollida jooksvalt tellimuse täitmist ja anda täitjale selleks suuniseid. Täitja kohustub tellija juhiseid järgima; 3.4.2. keelduda osaliselt või täielikult tasu maksmisest, kui täitja ei teostanud nõuetekohaseid töid kokku lepitud tähtajaks ja täitja poolne rikkumine ei ole objektiivselt põhjendatud (nt on tegemist objektiivse põhjendusega, kui tööde teostamine on viibinud tellija või kolmanda osapoole tegevuse tõttu); 3.4.3. kontrollida igal ajal tööde vastavust kokkulepitud tingimustele ja nõuda täitjalt informatsiooni tellimuse täitmise kohta. 4. Tööde teostamise ja üleandmise kord 4.1. Tööde teostamine toimub vastavalt tehnilisele kirjeldusele ja tööde halduskeskkonnas Jira esitatavatele tellimusele. Tellija määrab tellimuses 3  konkreetse töö mahu, sisu, tulemi ja muud olulised tingimused, mis fikseeritakse Jiras. 4.2. Töö üleandmine ja vastuvõtmine toimub üleandmise ja vastuvõtmise akti (edaspidi akt) mõlemapoolse allkirjastamisega. 4.3. Täitja annab nõuetekohaselt teostatud töö üle poolte vahel kokkulepitud tähtajal omalt poolt allkirjastatud aktiga. 4.4. Täitja võib tööd üle anda osade kaupa vastavalt hankelepingu täitmise käigus kokkulepitud tööde teostamise plaanile või tellimustele. Kõik tööde tulemused dokumenteeritakse ja hallatakse tellija versioonihalduskeskkonnas (tarneteatised, juhendid, lähtekood, testraportid jms). 4.5. Tellija vaatab üle ja vajadusel korraldab üleantud töö vastuvõtutestimise mõistliku aja jooksul. Kui tellijal ei esine teostatud töö osas pretensioone, võtab tellija töö akti omapoolse allkirjastamisega vastu. 4.6. Tellijal on õigus nõuetele mittevastavalt teostatud töö vastuvõtmisest keelduda, näidates ära keeldumise konkreetsed põhjused ning andes täitjale täiendava tähtaja töö üleandmiseks, kui see on võimalik. 4.7. Tellija võib tööd vastu võtta osaliselt, märkides aktis, millised tööd on vastu võetud ning andes täitjale täiendava tähtaja puudustega tööde parandamiseks või alandades proportsionaalselt nõuetekohaselt teostatud tööga väljamaksmisele kuuluvat tasu, kui tellijal puudub põhjendatult huvi lepingu edasise täitmise suhtes. 4.8. 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 lähtudes hanke eesmärgist ja lepingu dokumentidest. 5. Täitja meeskond 5.1. Täitja tagab tehnilises kirjelduses fikseeritud nõuetele vastavate meeskonnaliikmete osalemise tööde teostamisel, v.a juhul, kui täitjast mittesõltuval asjaolul ei ole seda võimalik teha ja meeskonnaliige on asendatud tellija kirjalikku taasesitamist võimaldaval nõusolekul uue samaväärse meeskonnaliikmega. 5.2. Täitja meeskonnaliikme ettevõttest lahkumise, haigestumise jms juhtumite korral asendab täitja konkreetse spetsialisti hiljemalt kahe nädala jooksul. 5.3. Täitja võib lisada täiendavaid meeskonnaliikmeid juhul, kui meeskonnaliikmed on tellitud tööde täitmisega hõivatud. Lisanduvad meeskonnaliikmed peavad vastama samuti tehnilises kirjelduses fikseeritud nõuetele. 5.4. Täitja kohustub tellija nõudmisel meeskonnaliikme asendama, kui isik osutub tellija põhjendatud arvamuse kohaselt lepingujärgsete ülesannete täitmiseks ebakompetentseks või ebasobivaks või kui tema lepingujärgsete ülesannete täitmine kahjustab pidevalt tellimuse korrektset ja õigeaegset täitmist. Täitja kannab kõik asendusest tulenevad või sellega kaasnevad kulud. 6. Maksumus ja arvelduste kord 6.1. Tellija tasub üksnes lepingu alusel tellitud, nõuetekohaselt teostatud ja üle antud tööde eest vastavalt tööde teostamiseks kulunud reaalsetele töötundidele, mille osas peetakse arvestust Jiras. Tööd antakse üle osade kaupa vastavalt tellimustes kokkulepitule. 6.2. Ühe töötunni maksumuseks tööde teostamisel on 55.00 (viiskümmend viis) eurot käibemaksuta. 4 6.3. Lepingu alusel esitatavate tellimuste maht on maksimaalselt 50 000 (viiskümmend tuhat) eurot käibemaksuta. 6.4. Täitjal on õigus esitada e-arve pärast töö tellija poolt vastuvõtmist. Arve tasumiseks annab täitja minimaalselt tähtaja 21 kalendripäeva alates nõuetekohase arve laekumisest. Arvel tuleb märkida lepingu kontaktisik ja number. 7. Intellektuaalomand 7.1. Täitja kinnitab lepingu allkirjastamisega, et talle kuuluvad tööde teostamiseks vajalikud autoriõigused, litsentsid ja muud intellektuaalse omandi õigused, mis on vajalikud lepingu järgsete tööde teostamiseks ja õiguste loovutamiseks tellijale ning nende suhtes ei ole õigusi ega nõudeid kolmandatel isikutel. 7.2. Tasu intellektuaalse omandi õiguste loovutamise ja litsentsi andmise eest sisaldub lepingu hinnas. 7.3. Täitja loovutab tellijale tööde teostamise käigus loodud tööde kõik autori varalised õigused ning annab lihtlitsentsi autori isiklikele õigustele koos all-litsentsi andmise õigusega kogu autoriõiguste kehtivuse ajaks ilma geograafiliste piiranguteta tööde üleandmise järgselt tasu maksmise hetkest, loobudes sellega tellimuse alusel üle antud originaalteoste osas õiguste kasutamisest. 7.4. Täitja tagab, et isiklikud õigused on ilma täitja nõusolekuta teostatavad muuhulgas järgnevas ulatuses: 7.4.1. tellijal on õigus tööd kasutada mis tahes eesmärgil ja viisil; 7.4.2. tellijal või tellija tellimusel kolmandatel isikutel on õigus teha üle antud töödes muudatusi ning neid täiendada; 7.4.3. tellijal või tellija tellimusel kolmandatel isikutel on õigus teostatud töid muuta või töödele lisada tellija või kolmandate isikute poolt loodud töid; 7.4.4. tööde üleandmisega tellijale kinnitab täitja, et tööd on üldsusele avaldamiseks valmis. 7.5. Täitja tagab tellijale kõik vajalikud õigused lepingu täitmise käigus loodava töö kontrollimiseks, testimiseks ning süsteemi paigutamiseks ka ajal, mil tööd on vastuvõtutestimiseks üle antud, kuid ei ole veel tellija poolt aktiga vastu võetud. 7.6. Täitja on kohustatud tagama intellektuaalse omandi õiguste (eeskätt autoriõiguste) olemasolu ja kehtivuse, samuti nende ülemineku tellijale viisil, mis võimaldab tellijal tellimuse lõppedes üle võtta täitja funktsioonid. 7.7. Täitja kohustub lahendama kõikvõimalikud lepingujärgsete töödega seotud intellektuaalse omandi õigustest tekkivad vaidlused kolmandate isikute või oma töötajate või koostööpartneritega, v.a. juhul, kui tarkvara või tarkvara osa litsentside soetamise kohustus oli tellijal või kolmandal osapoolel. Juhul, kui eeltoodust tekib tellijale rahaline või muu kohustus või juhul, kui tellija on kohustatud lõpetama tellimuse alusel teostatud ja vastuvõetud tööde kasutamise, on tellijal õigus nõuda täitjalt sellega kaasneva rahalise või muu kohustuse täitmist ja/või samaväärse töö loomist ilma täiendavat tasu nõudmata võimalikult lühikese aja jooksul, hoidudes mistahes viivitustest tarkvara arendamises, kasutuselevõtmises ja kasutamises tellija poolt. 7.8. Kõik tellijale kaasnevad otsesed ja kaudsed kahjud, mis tulenevad sellest, et kolmandal isikul on või väidetavalt on varalisi või mittevaralisi intellektuaalsest 5  omandist tulenevaid õigusi tellimuse alusel üle antavate intellektuaalse omandi objektide suhtes, kannab täitja. 7.9. Selles alapeatükis kirjeldatud õigused ja litsentsid loetakse tellijale lõplikult üle läinuks pärast töö vastuvõtmist. 8. Garantii 8.1. Täitja annab hankelepingu alusel teostatud töödele garantii 12 kuud. Garantii hakkab kehtima aktis märgitud nõuetekohase töö vastuvõtmise kuupäevast. 8.2. Garantiiga on hõlmatud kõik garantii tähtaja jooksul töödes ilmnevad vead ja mittevastavused kokkulepitule, mis ei ole tekkinud tellija või kolmandate osapoolte tegevuse tagajärjel. Garantiiga on hõlmatud ka kõigi tööde muudatused ja modifikatsioonid, mis on tehtud täitja poolt ja mis ei ole oluliselt muutnud varasemalt tehtud tööd. 8.3. Täitja on garantii kehtivuse ajal kohustatud kõrvaldama töödes avaldunud vead ja hankelepingu tingimustele mittevastavused tasuta, sealhulgas on täitja kohustatud uuendama või asendama kõik esinenud veaga seonduvad dokumendid. 8.4. Täitjale peab saama edastada teateid garantiiga hõlmatud vigade ilmnemise kohta vastavalt kehtiva kodukorra regulatsioonile garantiist tulenevate õiguste teostamiseks vähemalt igal tööpäeval ajavahemikul kell 8:00 kuni 17:00. 8.5. Täitja on kohustatud garantii korras teostama eelkõige järgmist: 8.5.1. vea ilmnemisel vea otsimine (lokaliseerimine), veaolukorrale lahenduse leidmine ja vea parandamine; 8.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; 8.5.3. vea parandamisega seoses paigaldamise ja seadistamise toe pakkumine tellijale, samuti sellega seotud konsultatsioonid; 8.5.4. vigase või puuduliku dokumentatsiooni parandamine, sealhulgas dokumentatsiooni täiendamine ja uuendamine, kui selline vajadus tuleneb vigade parandamisest. 8.6. Tellija määrab võimalusel, milline on vea kriitilisuse aste või kas tegemist on muu garantiikohustusega hõlmatud puudusega ning võib määrata vea kõrvaldamiseks tähtaja, lähtudes hankelepingus fikseeritud vigade kriitilisuse astmetest. 8.7. Kui tegemist on kriitilise veaga (blocker ja critical), alustab täitja vea kohta teate saamisel viivitamatult oma esialgse hinnangu koostamist kriitilise vea võimalike põhjuste kohta ning annab juhtnöörid, kuidas tööde tulemit edasi kasutada. Kriitiline viga peab saama kõrvaldatud hiljemalt 24 tunni jooksul alates vea kohta teate saamisest, kui pooled ei ole kokku leppinud teisiti. 8.8. Kui tegemist on häiriva vea (major), pisivea (minor) või muu garantiikohustusega hõlmatud puudusega, teatab täitja hiljemalt 24 tunni jooksul alates selle kohta teate saamisest oma esialgse hinnangu häiriva vea, pisivea või muu puuduse võimalike põhjuste kohta ning vajadusel juhtnöörid, kuidas tööde tulemit edasi kasutada. Häiriv viga peab saama kõrvaldatud hiljemalt 5 tööpäeva jooksul alates vea kohta teate saamisest, kui pooled ei ole kokku leppinud teisiti. 8.9. Juhul, kui täitja tõendab, et kõrvaldatud viga või muu puudus ei olnud garantiiga hõlmatud, hüvitab tellija täitja kantud otsesed kulud seoses nimetatud vea või puuduse kõrvaldamisega. Kulude hüvitamisel võetakse aluseks hankelepingus, mille raames teostatud töödes on viga või puudus ilmnenud, fikseeritud tööde teostamise ühe töötunni hind. 6 8.10. Tellija tagab täitjale kaasaabi garantiikohustuse alla käivate vigade ja puuduste kõrvaldamisel tellija võimekuse ja võimaluste piires. 8.11. Kui täitja ei suuda vigasid kokkulepitud tähtajaks kõrvaldada, võib tellija nimetatud ise kõrvaldada või korraldada nende kõrvaldamise kolmanda isiku kaasabil, teavitades sellest täitjale. Tellijal on õigus täitjalt nõuda kõigi kulutuste hüvitamist, mis tekkisid seoses eelkirjeldatud viisil vea kõrvaldamisega, kui tegemist oli garantiiga hõlmatud vea. 8.12. Garantii kaotab kehtivuse, kui tellija muudab täitjaga kooskõlastamata lähtekoodi, välja arvatud tööde osale, mida ei ole muudetud, kui tellija suudab eristada lähtekoodis tehtud muudatusi. 9. Poolte vastutus 9.1. Pooled vastutavad oma lepinguliste kohustuste rikkumise eest, välja arvatud juhul, kui rikkumine on vabandatav. Rikkumine on vabandatav, kui esineb vääramatu jõud. Nimetatud asjaolu esinemist peab tõendama pool, kes sellele tugineda soovib. 9.2. Pool vastutab teise poole ees muuhulgas lepingu rikkumise eest, mis tuleneb poole poolt tellimuse täitmisele kaasatud isikute tegevusest või tegevusetusest (sh alltöövõtjate tegevuse eest, keda täitja tööde teostamisel kasutab). 9.3. Pool ei vastuta lepinguliste kohustuste rikkumise eest, mis tulenes teise poole kohustuste rikkumisest või kolmandate isikute tegevusest või tegemata jätmistest. Nimetatud asjaolu esinemist peab tõendama pool, kes sellele tugineda soovib. 9.4. Poole lepingulise kohustuse rikkumise korral on teisel poolel õigus kasutada kõiki seadusest tulenevaid õiguskaitsevahendeid. Leppetrahvi, viivise ja tekitatud kahju hüvitamine ei vabasta lepingut rikkunud poolt lepingujärgsete kohustuste täitmisest. Kui rikkumise eest on võimalik kohaldada mitut õiguskaitsevahendit ja/või leppetrahvi, valib õiguskaitsevahendi ja/või leppetrahvi rakendamise tellija. 9.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. 9.6. Poolte rahaline koguvastutus on piiratud lepingu kogumaksumusega, kuid nimetatud piirang ei kehti süülise rikkumise korral, intellektuaalomandiõiguse või andmekaitsealaste kohustuste rikkumise korral. 9.7. Juhul, kui tellija satub täitjale tööde tasu maksmisega viivitusse, on täitjal õigus esitada viivise nõue vastavalt võlaõigusseadusele, kuid mitte rohkem kui 25% tähtaegselt tasumata summast. Täitja esitab viivise nõude tellijale allkirjastatult vähemalt kirjalikku taasesitamist võimaldavas vormis. 9.8. Täitja poolse lepinguliste kohustuste rikkumisena käsitletakse olukorda, kus üle antud töö ei vasta tellimuse ja/ või hankelepingu tingimustele või esineb muid täitja poolseid lepingu rikkumisi. 9.9. Kui täitja rikub lepingulist kohustust (sh garantiist tulenevat kohustust), on tellijal õigus nõuda leppetrahvi tasumist, mille suuruseks on 100 eurot iga rikkumises oldud kalendripäeva eest, kuid mitte rohkem kui 30% lepingu kogumaksumusest. 9.10. Kui täitja ei suuda ka täiendava tähtaja jooksul töid teostada ja tööde kasutuselevõtt ei ole enam realistlik või tellija jaoks vajalik, puudub tellijal kohustus tellitud tööde eest maksta ja täitja on kohustatud tegema juba makstud osa eest tellijale tagasimakse. 9.11. Lepingu olulise rikkumise korral on tellijal õigus esitada täitjale leppetrahvi nõue 10 000 eurot iga rikkumise eest. Täitja poolse olulise rikkumise korral ei pea tellija 7  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. 9.12. Oluliseks lepingu rikkumiseks loevad pooled lisaks võlaõigusseaduses sätestatule muuhulgas: 9.12.1. mõjuva põhjuseta tellimuse sõlmimata või täitmata jätmine; 9.12.2. valeandmete või valeinfo esitamine; 9.12.3. lepingu täitmiseks vajalike õiguste (sealhulgas load, litsentsid, intellektuaalse omandi õigused) puudumine; 9.12.4. intellektuaalse omandi õiguste ja nende kasutamise tingimuste rikkumine; 9.12.5. konfidentsiaalsuskohustuse rikkumine; 9.12.6. lepingujärgsete kohustuste, sh garantiikohustuste korduvat (vähemalt kahel korral) täitmata jätmist; 9.12.7. tähtaegselt tööde teostamata jätmist selliselt, et tehnilises kirjelduses sätestatud eesmärgi täitmine ei ole enam tähtaegselt realistik ja/või täitja poolse tegevuse või tegevusetuse tõttu ei ole võimalik enam kasutada tellimuse rahastamiseks ettenähtud vahendeid; 9.12.8. lepingujärgsete kohustuste üleandmine kolmandale isikule ilma tellija digiallkirjastatud nõusolekuta. 9.13. Töö vastuvõtmine tellija poolt ei vabasta ega vähenda täitja vastutust lepingu rikkumise eest. 9.14. Leppetrahvi nõude kohustub tellija esitama mõistliku aja jooksul, kuid mitte hiljem kui 3 kuu jooksul alates päevast, mil tellija sai teadlikuks leppetrahvi nõude aluseks olevast asjaolust. Leppetrahvi nõude vaidlustamine ei vabasta täitjat selle maksmise kohustusest enne vastava kohtuotsuse jõustumist. 9.15. Täitja on kohustatud leppetrahvi tasuma 2 nädala jooksul alates tellija poolt vastava nõude esitamisest, kui leppetrahvi nõudes ei ole määratud teisiti. 9.16. Tellijal on õigus tasaarvestada leppetrahvi summa täitjale töö teostamise eest tasumisele kuuluvate maksetega. Tasaarvestamise korral ei rakendata leppetrahvi tasumise kohustust. 10. Konfidentsiaalsuskohustus 10.1. Pooled kohustuvad vastastikku hoidma salajas ja mitte avaldama kolmandatele isikutele ükskõik missugust konfidentsiaalseks peetavat informatsiooni, mis on saadud teiselt poolelt lepingu alusel tellitud tööde teostamise käigus või muul viisil või juhuslikult. 10.2. 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. 10.3. Juhul, kui tellimuse täitmise raames osutub vajalikuks isikuandmete töötlemine, lepivad pooled isikuandmete töötlemise tingimused kokku tellimuse esitamisel, juhindudes isikuandmete kaitse üldmääruse1 artiklis 28 kirjeldatust. 10.4. Konfidentsiaalse informatsiooni all mõistavad pooled igasugust informatsiooni (sh ärisaladusi, isikuandmeid, lepingute andmeid, infosüsteeme, turvasüsteemide kirjeldusi, riistvara ja tarkvara kirjeldusi, pakkumuse kirjeldusi, kasutatavaid 1 Euroopa Parlamendi ja Nõukogu määrus nr (EL) 2016/679. 8  tehnoloogiaid, spetsifikatsioone jms), mis on saadud seoses tööde teostamisega ja mille sattumine kolmandate isikute kätte võib pooltele põhjustada turvariske või majanduslikku kahju või kolmandate isikute (eelkõige tellija klientide) eraelu puutumatuse rikkumist. Kahtluse korral eeldatakse informatsiooni konfidentsiaalsust. 10.5. Konfidentsiaalne informatsioon ei hõlma endas informatsiooni, mille avalikustamise kohustus tuleneb õigusaktidest või mille avalikustamiseks pooled on andnud nõusoleku. 10.6. Pooled võivad edastada konfidentsiaalset informatsiooni ainult nendele isikutele, kes on tellitud tööde täitmisega otseselt seotud. Täitja kohustub tagama, et isikud, keda ta oma kohustuste täitmisel kasutab, oleksid konfidentsiaalsuse kohustusest teadlikud ning nõudma nimetatud isikutelt selle kohustuse tingimusteta ja tähtajatut täitmist. Vastutus konfidentsiaalsuskohustuste täitmise eest lasub täitjal. 10.7. Pooled ei kasuta lepingu täitmisel neile teatavaks saanud konfidentsiaalset informatsiooni oma huvides ega muul eesmärgil, kui tellitud tööde teostamiseks. 10.8. Konfidentsiaalsuskohustus jääb kehtima tähtajatult, ka lepingu lõpetamise või lõppemise järgselt. 10.9. Täitja on teadlik, et leping ja kokkulepped on avalikud, v.a osades, mis on avaliku teabe seadusest tulenevatel alustel määratud asutusesiseseks kasutamiseks või märgitud täitja poolt ärisaladuseks. 10.10. Konfidentsiaalsuskohustuse rikkumise korral kohustub täitja hüvitama kõik kahjud, mis sellise rikkumise tagajärjel tellijale või kolmandale isikule tekkisid, sõltumata sellest, kas rikkumine pandi toime tellimuse kehtivuse ajal või lepinguliste kohustuste lõppemise järgselt. 11. Lepingu kehtivus, muutmine ja lõpetamine 11.1. Leping jõustub sellele poolte poolt allakirjutamisest ja kehtib kuni 31.08.2020 või lepingu maksimaalse mahu täitumiseni või lepingu lõppemiseni muul seaduses või lepingus fikseeritud asjaolul. 11.2. Lepingut muudetakse pooltevahelise kirjaliku kokkuleppega lepinguga samas vormis. 11.3. Lepingu mingi sätte muutmine või tühistamine poolte kokkuleppel ei too kaasa ülejäänud lepingu punktide muutumist või tühistamist. 11.4. Tellijal on õigus leping igal ajal sõltumata põhjusest lõpetada teatades sellest kirjalikku taasesitamist võimaldavas vormis ette 30 päeva. Lepingu lõpetamine vabastab pooled käesoleva lepinguga sätestatud kohustuste täitmisest. 11.5. Tellijal on õigus leping ühepoolselt etteteatamistähtaega järgimata üles öelda või sellest taganeda, kui täitja on oluliselt lepingut rikkunud või juhul, kui täitja: 11.5.1. suhtes on algatatud pankrotimenetlus; 11.5.2. pankrot on välja kuulutatud; 11.5.3. täitja varad arestitakse; 11.5.4. täitja finantsseisund halveneb tellija põhjendatud hinnangul oluliselt ja see muudab tellimuse nõuetekohase täitmise vähetõenäoliseks. 11.6. Kui lepingu täitmisel selgub tellija soovidest tulenev vajadus täiendada või muuta töid viisil, mis erineb lepingus algselt kokkulepitust, lepitakse lepingu muutmine poolte vahel kokku lepinguga samas vormis. Lepingu muudatused jõustuvad, mil mõlemad pooled on sellele alla kirjutanud, kui lepingu lisas ei ole määratud teisti. 9  11.7. Lepingu mingi sätte muutmine või tühistamine poolte kokkuleppel ei too kaasa ülejäänud lepingu punktide muutumist või tühistamist. 11.8. Lepingu lõppemisel mistahes alusel ja põhjusel on täitja kohustatud tellijale üle andma kogu tööga seotud informatsiooni ja dokumentatsioon (nii digitaalselt kui paberkandjal, samuti informatsiooni, mida ei ole salvestatud eelnimetatud infokandjatele). Üleantav info ja dokumentatsioon peab olema süstematiseeritud. Täitja on kohustatud andma ammendavad selgitused eelkirjeldatud informatsiooni haldamise ja kasutamise kohta, tehes seda tellija nõudmisel kirjalikult. 12. Teadete edastamine ja kontaktisikud 12.1. Teadete edastamine toimub üldjuhul e-posti teel, lähtudes selle olemasolul kehtiva kodukorra tingimustest. Juhul, kui teate edastamisel on olulised õiguslikud tagajärjed, peab teade olema edastatud kirjalikku taasesitamist võimaldavas vormis allkirjastatult poole allkirjaõigusliku isiku poolt. Informatiivset teadet võib edastada ka telefoni teel. Informatiivseks loetakse teade, millega ei kaasne iseseisvaid õiguslikke tagajärgi. 12.2. Kirjalik teade loetakse poole poolt kättesaaduks, kui see on üle antud allkirja vastu või kui teade on saadetud postiasutuse poolt tähitud kirjaga poole poolt teatatud aadressil ja postitamisest on möödunud 5 (viis) kalendripäeva. E-posti teel, sh digitaalselt allkirjastatud dokumentide, saatmise korral loetakse teade kättesaaduks kohale jõudmise teates märgitud kellaajal või e-kirjas näidatud saatmise kellaajal. 12.3. Tellija kontaktisik(ud) on: Lehor Meius, telefon +372 535 70 111, e-post: [email protected] või tema asendaja. 12.4. Täitja kontaktisik(ud) on: Liina Valdna, telefon +372 585 54 370, e-post: [email protected] või tema asendaja. 12.5. Kontaktisikute pädevuses on anda teisele poolele vajaliku informatsiooni ja juhiseid oma pädevuse piires, kontrollida teostatud töö kvaliteeti, anda töö üle ja võtta töö vastu ning allkirjastada akt. 12.6. Kontaktisiku muutumisest teavitab pool kirjalikult teist poolt viivitamatult. 13. Lõppsätted 13.1. Täitjal puudub volitus tegeleda lepingu raames avalike suhetega ning anda teateid pressile, elektroonilisele meediale, üldsusele või teistele auditooriumidele, välja arvatud tellija eelneval kirjalikku taasesitamist võimaldaval nõusolekul. 13.2. Täitjal ei ole õigust lepingut või sellest tulenevaid kohustusi kolmandatele isikutele üle anda, välja arvatud tellija digiallkirjastatud nõusolekul riigihangete seaduses ette nähtud alustel. Kolmas isik on mistahes füüsiline või juriidiline isik, kes ei ole selle lepingu pooleks. 13.3. Lepinguga seotud vaidlused, mida pooled ei ole suutnud läbirääkimiste teel lahendada, antakse lahendamiseks Harju Maakohtule. Raamlepingule kohaldub Eesti õigus. 13.4. Lepinguga reguleerimata küsimustes või olukorras, kus mõni lepingu säte on vastuolus seadusega, lähtutakse Eesti Vabariigis kehtivast seadusandlusest. 14. Lepingu lisad: 14.1. Lisa 1 – Tehniline kirjeldus; 14.2. Lisa 2 – Mittefunktsionaalsed nõuded; 10  14.3. Lisa 3 – Nõuded infosüsteemi dokumenteerimisele. 14.4. Lisa 4 – Tööde üleandmise ja vastuvõtmise akt; 15. Poolte allkirjad Tellija Täitja /allkirjastatud digitaalselt/ /allkirjastatud digitaalselt/ 11  Lisa 4 - Tööde üleandmise-vastuvõtmise akt nr ... hankelepingule nr 3-9/2227-1 Lähtudes Tervise ja Heaolu Infosüsteemide Keskuse, keda esindab lepingu alusel Lehor Meius (edaspidi tellija) ja OÜ Resta, keda esindab Liina Valdna (edaspidi täitja) vahel päev.kuu.aasta sõlmitud hankelepingust nr 3-9/2227-1, annab täitja üle ja võtab tellija vastu teostatud tööd. 1. Sisu 1.1. Käesoleva aktiga annab täitja tellijale üle tööd, mis täitja on teostanud vastavalt pooltevahelisele kokkuleppele ja tellija võtab käesolevas aktis nimetatud tööd vastu. 1.2. Tellija kinnitab, et tema või tema esindajad on käesolevas aktis nimetatud tööd üle vaadanud ja need vastavad lepingu tingimustele. Kui töös avaldub puudusi, siis täitja lahendab need kas projekti raames parenduste faasis või garantii perioodil omal kulul. 1.3. Käesolev akt on täitjale tasu maksmise aluseks. Poolte vaheline arveldamine toimub sõlmitud hankelepingu alusel vastavalt käesolevas aktis sisalduvatele andmetele. 1.4. Käesoleva akti pooled kinnitavad, et aktis sisalduvad andmed on nende parima teadmise kohaselt õiged. 2. Akteeritavad tööd Nr Tööde loetelu Maksumus Maksumus km-ta km-ga 1 2 3 4 5 KOKKU 3. Tööde üleandmise tähtaeg 3.1. Tööd on üle antud päev.kuu.aasta. 3.2. Tööd teostati tähtaegselt. Tellija: Täitja: /allkirjastatud digitaalselt/ /allkirjastatud digitaalselt/ Lehor Meius Liina Valdna 12