Leping

Mittefunktsionaalsed nõuded arendustele Versioon: 1.0 Käesolev dokument määrab kvaliteedi- ja mittefunktsionaalsed nõuded uutele infosüsteemidele ning nende dokumentatsioonile. Käesolevat dokumenti tuleb vaadata kui arenduste kvaliteedi- ja mittefunktsionaalsete nõuete põhidokumenti. Põhidokumendi ja viidatud dokumentide erisuste puhul tuleb lähtuda põhidokumendis kirjeldatust. Põhidokumendis viidatud Sotsiaalministeeriumi poolt koostatud dokumentide ja kolmandate osapoolte poolt koostatud dokumentide erisuste puhul tuleb lähtuda Sotsiaalministeeriumi poolt loodud dokumentides kirjeldatust. Kui mõnda nõuet ei ole võimalik või otstarbekas täita, tuleb selle mittetäitmise fakt ja põhjendus välja tuua pakkumuse esitamisel. Nõudeid tuleb järgida ka olemasolevate infosüsteemide versiooniuuendustel nii palju kui versiooniuuenduse käigus võimalik. Nõu Nõu Koostamis de de Nõude sisu Seletused e eest liik nr. vastutaja Vastavus üldistele standarditele Lahendus peab olema kooskõlas 1.1 riigi IT koosvõime raamistiku https://www.mkm.ee/sites/default/files/riigi_it_koosvoime_raamistik.pdf Arendaja nõuetega. Lahenduse X-tee teenused 1.2 https://www.ria.ee/ee/xtee-juhendid.html Arendaja peavad vastama RIA nõuetele. Lahendus peab vastama 1.3 Sotsiaalministeeriumi IT- Arendaja profiilile.  Rakendus peab olema kirjutatud arvestades selle rakenduse poolt Tervise infosüsteemi ISKE turvaklass on K2T3S2. 1.4 töödeldavatele andmetele Arendaja määratud ISKE turvaklassi https://www.ria.ee/ee/iske-kkk.html nõudeid. Lahendus peab vastama veebide 1.5 https://www.mkm.ee/sites/default/files/veebide_raamistik.pdf Arendaja koosvõime raamistikule. Veebirakenduse kasutajaliides 1.6 peab vastama vähemalt WCAG http://www.w3.org/TR/WCAG20/ Arendaja 2.0 tasemele AA. Valideerimiseks kasutatakse vastavaid validaatoreid: http://validator.w3.org/ Kui on tegu olemasoleva süsteemi edasiarendusega, siis tuleb järgida olemasolevat HTML ja CSS versiooni. HTML valideerimisel arvestatakse sellega, et infosüsteemides kasutusel olev Angular javascript raamistik lisab HTML atribuute, mis ei vasta HTML5 standardile. Sellest lähtuvalt eristatakse HTML Veebipõhine kasutajaliides peab valideerimisel Angular – ja HTML spetsiifilisi vigasid. Angular 1.7 ühilduma täielikult standarditega Arendaja spetsiifilised HTML valideerumise vead ei kuulu parandamisele. HTML 5 ja CSS 3 Valideerimise tulemustest parema ülevaate saamiseks saab kasutada w3 validaatori filtreerimis funktsionaalsusi. CSS valideerimisel võetakse aluseks profiil CSS level 3 + SVG, brauseri tootjate spetsiifiliste (vendor prefix) css reegleid käsitletakse kui hoiatusi ja nende kasutamine on aktsepteeritav. Kui tekib vajadus vanemate brauserite toetamiseks kasutada mitte valideeruvat CSS-i siis selles lepitakse eraldi kokku. ID-kaardiga allkirjastamisel on Arendaja loodud lahenduse dokumentatsioonis (nt detailanalüüs vms) 1.8 eelistatud veebipõhine digidoc- Arendaja peab olema välja toodud digidoc-teekide versioonid ja kasutuskohad teenuste kasutamine.  Kui pole arenduse eraldi kokku lepitud teisiti, siis on OWASP ASVS 3.0 tasemeks 2 (https://www.owasp.org/index.php/Category: OWASP_Application_Security_Verification_Standard_Project). Veebirakendus peab Kinnise lähtekoodiga kommertstoote kasutamisel ei eeldata ligipääsu 1.9 probleemideta läbima OWASP kinnisele lähtekoodile.Tellija poolset turvatestimist teostab kolmas Arendaja ASVS baasil põhineva testi 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üptoalgoritmide ja räsifunktsioonide kasutamisel tuleb järgida uusimat RIA Arendaja loodud lahenduse dokumentatsioonis (nt detailanalüüs vms) kodulehel avaldatud tuleb välja tuua kasutatavad krüpto- ja räsialgoritmid, nende krüptograafiliste algoritmide 1.10 võtmepikkused, kasutuskohad, sh SSL sertifikaatide kasutuskohad. Arendaja kasutusvaldkondade ja elutsükli Värskeima uuringu leiab aadressilt https://www.ria.ee/ee/iske- uuringut, st lahendustes ei tohi dokumendid.html kasutada uuringus väljatoodud ebaturvalisi algoritme ja võtmepikkuseid Andmete edastus peab välisvõrgu liikluses olema kaitstud 1.11 Arendaja kasutades turvalisi ja üldteada andmeedastusprotokolle Infosüsteem peab kasutama 1.12 Arendaja serveri kellaaega ja ajatsooni  Süsteemi edasiarendamisel/loomisel peab arvestama selle võimaliku 1.13 Arendaja laiendamisega nii andmemahtude, kui ka kasutajate arvu osas. Rakendus peab olema tehniliselt Näiteks, kui rakendusel on eraldi turvakontekstidega liidesed ametnikule tükeldatud vastavalt loogilisele ja kodanikule, peab rakendus olema jagatav kaheks eraldi 1.14 jaotusele. Saadud osised peavad Arendaja liidesekomponendiks ning nende mõlema poolt kasutatavaks olema eraldi versioneeritavad ja andmebaasiks. paigaldatavad Avalike e-teenuste loomisel peab arvestama valitsusasutusele https://www.valitsus.ee/et/eesmargid-tegevused/valitsusasutuste- 1.15 Arendaja kehtestatud visuaalse identiteedi visuaalse-identiteedi-stiilijuhis stiilijuhisega Avalike e-teenuste loomisel peab https://www.mkm.ee/sites/default/files/iseteeninduskeskkondade_raamis arvestama valitsusasutustele tik_08.07.2015.pdf 1.16 kehtestatud Arendaja iseteeninduskeskkonna https://www.mkm.ee/sites/default/files/iseteeninduskeskkondade_raamis raamistikuga tiku_kasutatavuse_nouded_dets.pdf Nõuded rakenduse arhitektuurile Rakenduse, andmebaasi ja Arendaja loodud lahenduse dokumentatsioonis (nt detailanalüüs vms) kolmanda osapoole komponentid peab olema välja toodud kasutatavate komponentide nimetused ja peavad olema sellised, mille 2.1 versioonid. Versiooni eluea lõppu ei loeta võrdseks terve komponendi Arendaja eluea lõpp (EOL) pole eluea lõpuks, st versiooni tugi võib aeguda, kui uus versioon on välja teadaolevalt vähem kui 2 aasta lastud. pärast.  Tulevase ja olemasolevate infosüsteemide platvormid (rakendusserver, andmebaas, kolmanda osapoole Süsteemi jõudlus peab vastama kokkulepitud topoloogial eelanalüüsi ja 2.2 Arendaja komponendid) ja topoloogia peab lähteülesande käigus välja toodud jõudlusnäitajatele. olema enne reaalse arenduse algust infosüsteemide halduse osakonna juhiga kooskõlastatud. Rakendusserver peab võimaldama töötamist 2.3 - Arendaja andmebaasiserverist eraldi serveril. Rakendusserver peab olema vajadusel klasterdatav 2.4 - Arendaja aktiivklastris (kasutajasessioon ei tohi olla klastri node põhine). Rakendust peab saama ilma ümberprogrammeerimata 2.5 Lahendus ei tohi olla sisse kompileeritud absoluutseid URI-sid Arendaja liigutada erinevate domeenide ja domeeni saitide vahel Rakenduse liidesed peavad Väliste liidestatud süsteemide tõrke korral ei tohi süsteem hanguda, vaid olema tõrkekindlad kolmandate 2.6 väljastama mõistliku (võimalikult lühikese) aja jooksul ajakohase Arendaja osapoolte süsteemide vigade veateate. Võimalusel tuleb kasutada asünkroonseid liideseid. suhtes  Rakendus peab neid sealt ka kasutama (mitte kopeerima parameetreid Rakenduse käivitamisel kolmandatesse kohtadesse), logimise seaded võivad olla konfiguratsiooniparameetrid rakenduse konfiguratsioonifailist eraldi ühes lisakonfiguratsioonifailis tuleb ühte kohta kokku tuua nii, (näit Log4net). Samuti on väga soovitatav eraldi konfiguratsioonifailis et nende muutmisel ei peaks hoida arendaja ja administraatori vastutusala parameetrid. Infosüsteem 2.7 rakendust uuesti kokku Arendaja peab olema seadistatav konfiguratsiooniparameetrite(de) abil. kompileerima (nt ühte Konfiguratsioonifailiks ei saa lugeda faili, kus hoitakse lisaks tekstipõhisesse konfiguratsioonile ka muud programmikoodi. konfiguratsioonifaili, andmebaasi tabelisse). Rakenduse kompileerimine < 10min Rakenduse kompileerimine, saidi Mooduli taaskäivitus < 1min taaskäivitus ja konfiguratsiooni Konfiguratsiooni muutmine < 30s 2.8 Arendaja muutmine peavad toimuma mõistliku aja jooksul. Kui rakendus vajab indekseeritud sisu ja see pole kättesaadav, siis peab rakendus väljastama selle kohta selge teate Rakendus peab kasutama 64- 2.9 bitist arvutiarhitektuuri kui ei ole Suund on 64-bitiste rakenduste op süsteemide kasutamise poole. Arendaja kokku lepitud teisiti. Kõik andmed, andmebaasid, 2.10 SQL skriptid ja rakendus peavad - Arendaja kasutama UTF-8 kodeeringut. Failisüsteemi salvestamisel ei Failid peab katalogiseerima kokkulepitud tunnuste alusel (nt aasta, kuu, 2.11 tohi ühte kausta tekkida üle Arendaja kuupäev). 10000 faili. Rakenduse loomisel tuleb Eelistuse eiramine tuleb kooskõlastada projektijuhiga enne arendamise 2.12 eelistada objektorienteeritud Arendaja alustamist mudelit  Ühest andmetabelist teise 2.13 viitamisel tuleb kasutada väliseid - Arendaja võtmeid (Foreign key). Kõik välised võtmed (Foreign Andmebaasis peab kasutama indekseid või muid meetmeid, et nõuded 2.14 Key) peavad olema rakenduse jõudlusele oleksid täidetud ka tulevikus. (1, 3, 5 või 10 aasta Arendaja indekseeritud. pärast – vastavalt planeeritud kasutusajale). SQL päringute väljakutsumisel väljastpoolt andmebaasi, peab kasutama Tuleb kasutada päringumuutujaid päringumuutujaid, et vältida SQL vahemälu fragmentseerumist (When 2.15 Arendaja (Parameter Binding). calling SQL code from outside the database, Parameter Binding should be used to prevent SQL cache fragmentation) Kõigis andmebaasi tabelites peab olema defineeritud üks primaarvõti. Andmebaasi 2.16 Kasutada vastava andmebaasisüsteemi nimetamise parimaid praktikaid. Arendaja objektide nimetused peavad olema sisulised ja andma aimu nende otstarbest. Andmebaasis defineeritakse üldjuhul kaks või enam kasutajat:  Rakenduse peakasutaja, kellena luuakse objektid ja skeemid. Need õigused, mis on vajalikud ainult rakenduse baasi loomiseks, on  Rakenduse piiratud 2.17 eraldi välja toodud ja tuleb peale installi ära võtta. Ei kehti teiste Arendaja õigustega kasutaja, andmebaasisüsteemide korral, seal võib see tekitada mõttetut keerukust. kellena pöördub rakendusserver/rakendus. Objektide loomiseks vajalikud õigused ja ressursid on loetletud rakenduse dokumentatsioonis.  Failide hoidmise asukoht lepitakse igakord kokku. Kuid Failide hoidmine klassikalises andmebaasis on kulukas ja seab 2.18 failid ja failide indeks peavad kõrgendatud nõudmised ja piirangud andmebaasiserveritele. Lahenduse Arendaja olema replikeeritavad teise dokumentatsioonis tuleb ära tuua failide hoidmise asukoht. serveriruumi. Peab olema minimiseeritud vajadus, et haldur teeb haldustoiminguid otse baasis. St 2.19 rakendusel peab olema Halduri haldustoimingud lepitakse tellijaga kokku detailanalüüsi käigus. Arendaja haldusliides, mille kaudu rakenduse haldur saab teha tavapäraseid haldustoiminguid. Rakendus peab olema võimeline 2.20 kasutama keskkonnamuutujaid Näiteks logifailides. Arendaja (serverinimi, kuu, päev jne). Andmebaas peab toetama nii Ei tohi kasutada teenuseid, mis välistavad andmebaasi peegeldamist (nt 2.21 külm- kui ka kuumvaru Arendaja "failstream"). (peegeldamist) teise serviruumi. Sorteerimisreeglistik peab olema Eesti tähestikule vastav. 2.22 Tõusutundlikkus peab olema Näiteks MS SQL puhul Estonian_CI_AS. Arendaja välja lülitatud. Accent peab olema sisse lülitatud.  Kui infosüsteemid saadavad e- kirju, peavad nad kasutama välist e-mailiserverit. Kirja Saatja ja adressaadid, pealkiri ja sisu ei tohi olla rakendusse kodeeritud, saatmisel peab rakendus vaid on muudetavad konfiguratsioonifaili kaudu. Genereeritud kirjade 2.23 veenduma, et e-mailiserver võttis puhul peab tagama kirjade jälitatavuse (näiteks lisada X-päise kodeeritud Arendaja meili vastu. E-kirjade kirje, milles on kirjeldatud, mis protsess/skriptifail/kasutaja kirja vormindamine peab järgima genereeris jms abistav info). interneti standardeid (RFC 5322). Konfiguratsiooniparameetrite nimed peavad olema sisulised. Näiteks : X-tee Turvaserver, mitte XTTS või viitenumber, mitte vk_seb 2.24 Arendaja Kui see ei ole võimalik, siis peab jne kõrval olema seletus. Infosüsteemides on eessüsteemid (front end; presentatsiooni kiht) Välise süsteemi tõrge tohib mõjutada ainult sellest otseselt sõltuvate 2.25 ja tagasüsteemid (back end; kasutuslugude toimimist. Välise süsteemi taastumisel peab süsteem Arendaja äriloogika kiht) arhitektuuriliselt olema suuteline oma tööd jatkama taaskäivitamata. selgelt lahutatud. Konfiguratsioonifailid peavad Näiteks IIS: *.config , *.resources Apache: *.conf, .htaccess. Arendaja 2.26 olema vastavalt rakendusserveri Arendaja peab välja tooma konfifailide listi, kui neid on mitu. tüübile vaikimisi kaitstud failid Rakenduse failid, mida kasutaja Näiteks: IIS: Bin,App_Code, App_Data, App_Browsers, 2.27 näha ei tohi, peavad olema App_GlobalResources, App_LocalResources, App_Themes, Arendaja vaikimisi kaitstud kaustades. App_WebReferences Konfiguratsiooniparameetrite taaskasutus. Erinevaid sama Kõiki parameetreid tuleks konfiguratsioonis kirjeldada vaid korra, mitte 2.28 Arendaja sisuga parameetreid ei tohi nii, et igas lõigus kirjeldatakse samu asju uuesti. konfiguratsioonis eksisteerida.  Kõik rakenduse liidesed peavad Rakendustes tohib kasutada vaid masinapõhiseid teenuseid, mis lubavad 2.29 olema võimelised kõrgkäideldavaid (klaster) lahendusi. Kõrgkäideldav lahendus on selline, Arendaja töötama kõrgkäidetavalt. mida saab samaaegselt käitada erinevates masinates. Klientrakendus ei tohi pöörduda 2.30 Tuleb kasutada rakendusservereid. Arendaja otse andmebaasi poole. Keskkonnapõhised muutujad peavad olema 2.31 Näiteks WSDL ei tohi sisaldada viiteid arendusserveritele. Arendaja konfiguratsioonifailist seadistatavad. Eelistama peaks IP-aadressipõhist blokeeringut. Erandina tellijaga kokkuleppel võib kasutada captchat või konto lukustamist. Blokeeringute ajavahemikku ja logimiskatsete arvu peab saama konfiguratsioonifailist muuta. Rakenduses peab olema võimalik piirata ebaõnnestunud logimisi Allikas: 2.32 ajaühiku kohta (mobiil-ID, ID- Arendaja https://iske.ria.ee/8_06/ISKE_kataloogid/7_Kataloog_M/M4/M_4.15 kaart, paroolid) ühelt IP- aadressilt. M.Toim: Iseteeninduse vaates delegeerime vastutuse nõude eest TARAle. Ametnikurakenduse juures ei eelda Tellija Täitjalt eelnevate puuduste täitmist. Puuduste likvideerimine lepitakse eraldi projektide/väiketöödena kokku. Rakenduse äriloogika tuleb Andmebaas ei tohi sisaldada äriloogikat, mis muudab andmetabelites 2.33 realiseerida andmebaasist eraldi Arendaja olevaid/sinna kirjutatavaid andmeid, va trigerid, mis tekitavad logi. sõltumatus rakenduskihis. Andmebaasis võib kasutada vaid ISO/IEC 9075 standardiga *Ei ole soovitav kasutada mingit platvormispetsiifilist lahendust, mille kaetud funktsionaalsusi. Lisaks üleviimine mõnele muule andmebaasiplatvormile ei ole võimalik. 2.34 Arendaja ei tohi kasutada ka sama *ISO/IEC 9075 osa 13 spetsifitseerib Javas kirjutatud standardi osas 13 kirjeldatud programmimoodulite kasutamist andmebaasis. funktsionaalsusi.  Uniform resource identifier Harilikult on piiriks 2000 tähemärki, kuid iga IS puhul tuleb seda eraldi (URI) pikkus ei tohi ületada 2.35 järele uurida sõltuvalt IS komponentidest. Asjakohased viited: RFC 3986 Arendaja ühegi IS poolt toetatava brauseri ja RFC 7239. maksimaalset lubatud väärtust. SOAP teenuseid pakkuva rakenduse WSDL peab olema Näiteks: Alajaotis definitions/types/schema: 2.36 Arendaja üles ehitatud nii, et see toetaks * complexType defineerimisel tuleb sellele lisada any element. teenuste versioneerimist. Rakendus peab olema võimeline 2.37 töötama koormusjaoturitega Arendaja varustatud taristul. Sidusinfosüsteemide mitte kättesaadavus ei tohi segada Sidussüsteemi tõrge tohib mõjutada ainult sellest otseselt sõltuvate rakenduse töötamist. 2.38 kasutuslugude toimimist. Sidussüsteemi taastumisel peab süsteem olema Arendaja Sidusinfosüsteemidega suuteline oma tööd jatkama taaskäivitamata. andmevahetamisel tekkinud vead logitakse ja kasutajat hoiatatakse. Kui ajastatult käivitatav taustatöö, ei ole mõeldud käima paralleelselt, peab selles olema realiseeritud kontrollmehhanism, 2.39 Arendaja mis tagab, et sama taustatööd ei ole võimalik käivitada uuesti enne, kui eelmisena käivitatud instants on oma töö lõpetanud. Ühe tarkvarakomponendi raames Näiteks kui rakenduse komponent pöördub andmebaasi või veebiteenuse ei tohi sama parameetri 2.40 poole, siis selle pöördumise parameetrid peavad olema muudetavad vaid Arendaja seadistamine toimuda rohkem ühes kohas. kui ühes kohas.  Uue toote arenduse ja olemasolevate infosüsteemide versiooniuuendustel kasutusele 2.41 võetavate Tehnoloogiate ja Arendaja standardite valik tuleb kooskõlastada Tellija poolse arhitektiga Rakenduse ühenduste (s.h. Implementeeritud peab olema vähemalt maksimaalsete ühenduste arvu andmebaasi ja piirang ja päringu aegumise aeg (request timeout). Rakenduse ühenduste sidusinfosüsteemide ühendused) tõrge tohib mõjutada ainult sellest otseselt sõltuvate kasutuslugude 2.42 Arendaja realiseerimisel tuleb kasutada toimimist. Ühenduste taastumisel peab rakendus olema suuteline oma ühenduste puulimist (connection tööd jatkama taaskäivitamata. Tekkinud vead logitakse ja kasutajat pooling). hoiatatakse. Rakenduse uuendustega kaasnevad andmebaasi 2.43 Näiteks Liquibase või Flyway Arendaja muudatused tuleb automatiseerida. Turvalisuse tagamisega seotud nõuded Sisemised rakendusliidese Erandina tellija kooskõlastusel võib sellest loobuda ja kasutada vaid ID- 3.1 autentimised peab saama teha kaardi ja mobiil-ID põhist autentimist. Isiku sertifikaatide kehtivust peab Arendaja Active directory põhiselt. saama kontrollida vastu OCSP ja CRL-i (vastavalt vajadusele). Kliendi ja serveri vahel peab autenditud kasutajasessioonide 3.2 korral olema sessioon - Arendaja krüpteeritud HTTPS-protokolli kasutades. SSL veebiserver peab kasutama 3.3 turvalisi ja SSL/TLS versioone ja https://www.ssllabs.com/ssltest/ Arendaja šifrikomplekte  Rakendus tohib kasutada vaid 3.4 sessiooni küpsiseid. Muude - Arendaja küpsiste kasutamine on keelatud. St kõik andmemuudatused peavad baasis säilima. Andmete Kui andmebaasis olevate muutmisel andmeid ei kustutata, vaid tehakse uus kirje uute andmetega. andmete ISKE tervikluse Vana muudetakse kehtetuks. Iga uus kirje peab sisaldama järgmist turvaosaklass on 2 või kõrgem, informatsiooni: *viide kirjele, mille ta kehtetuks muutis (kui on) 3.5 Arendaja siis tuleb kõik klass 2 infot *kasutaja, kes kirje lõi *kirje loomise aeg *sessiooni-ID (kui on olemas). sisaldavad andmebaasi Iga kehtetuks tunnistatud kirje peab omama järgmist informatsiooni: kirjed/tabelid versioneerida. *kasutaja, kes kirje kehtetuks tunnistas *kirje kehtetuks tunnistamise aeg. Kui rakenduse poolt töödeldavate andmete konfidentsiaalsuse turvaosaklass on 2 või kõrgem, peab rakendusega kaasas olema Testandmed peavad säilitama kõik toodangu andmete omadused 3.6 Arendaja lahendus, mis suudab toota (pikkuse, tüübi) ja omavahelised suhted. toodangu andmetest testandmed, mis ei sisalda konfidentsiaalset informatsiooni. Andmebaasis olevate rakenduse Ei resource, dba, ANY ega muud sellist. Nõude täitmiseks vajalikud kontod peavad omama ainult vahendid (skriptid) peavad kuuluma rakenduse juurde ja nende sisu peab 3.7 Arendaja minimaalselt rakenduse tööks olema kontrollitav. Kontodele vajalikud õigused peavad olema vajalikke õiguseid. kirjeldatud rakenduse installijuhendis. Rakendusse ja andmetele tohib olla ligipääs vaid dokumenteeritud ja tellimuses St rakendustes ega andmebaasides ei tohi olla ligipääsemiseks teisi 3.8 Arendaja kirjeldatud teid mööda ning võimalusi. dokumenteeritud autentimisprotseduure kasutades.  Räsimine peab kasutama turvalist räsifunktsiooni (nt SHA2, SHA3, RIPEMD-160) ja kindlasti ka soola (salt). Sool peab olema Kõik paroolid ja salaküsimuste andmebaasiüleselt unikaalne, piisavalt suure bitiarvuga ja vastused peab rakendus (pseudo)random. Krüpteerimisel peab kasutama turvalisi algoritme (nt salvestama vaid AES256) ja CBC, CRT vms režiimis. Kindlasti ei tohi kasutada ECB 3.9 räsitud+soolatud. Kui räsimise režiimi. Paroolid ja salaküsimuste vastused tohivad olla krüpteerimata Arendaja asemel valitakse krüpteerimine, kujul vaid ajutiselt serveri muutmälus. Krüpteerimata kujul ei tohi siis tuleb kirjeldadakrüptovõtme paroole salvestada (ka ajutiselt) ühelegi kettale. Arendaja loodud turvalise hoidmise protseduur. lahenduse dokumentatsioonis (nt detailanalüüs vms) peab olema ära toodud kasutatavad räsi ja krüptoalgoritmid, võtmepikkused ja nende kasutuskohad (vt nõue p 1.10) Kui on vajalik ka parooliga logimine, peavad välised kasutajad autentima ennast spetsiaalse väliskasutajate jaoks mõeldud AD pihta. Rakendused, kuhu saavad ligi Kui parooliga autentimist tehakse alati samadelt üksikutelt IP-delt, siis välised kasutajad, peavad tuleb lisaks paroolile kasutada ka IP-põhist ligipääsukontrolli. Rakendus võimaldama sisselogimist ID- 3.10 ei tohi lubada kasutada nõrku paroole, peab võimaldama paroolide Arendaja kaardi ja mobiil-ID-ga. eelmääratud aegumist ja mitme valesisestuse (nt 5 korda) korral kontode Paroolipõhist autentimist ei tohi lukustamist. Sertifitseerimiskeskuse dokument digisertifikaatide kasutada. kasutamise kohta EV dokumentidel: https://sk.ee/upload/files/SK-CPR- ESTEID-ET-v5_0-20150101.pdf Mobiil-ID autenimise korral tuleb lisaks kasutaja Veebilehel kuvatav kontrollkood peab olema selgelt nähtav, sh ka 3.11 Arendaja telefoninumbrile küsida ka nutitelefonidel ilma ekraanipilti kerimata. kasutaja isikukoodi. Rakendus ei tohi teostada X-tee Kasutajaarvutitest otse x-tee päringute tegemine on arvutivõrgu tasemel 3.12 Arendaja päringut otse kasutajaarvutist. kinni.  Veebipõhised välise veebilehega rakendused, mis on keskmise või IIS puhul peab kasutama näiteks URL scan, apache puhul modsecurity kõrgema ISKE turbeastmega, või vastavat tööriista. Lubatud päringud on kõik päringud, mis ei ole 3.13 Arendaja peavad kasutama vahendeid detailanalüüsi käigus vastavalt kasutusjuhtudele ette nähtud. Kasutama kaitsmaks rakendust lubamatute peab whitelisting põhimõtet, mitte blacklisting. päringute eest. Kui rakenduse mõni ISKE turvaosaklass on 2 või kõrgem, peab rakendus sisenemisel näitama pärast õnnestunud sisselogimist eelmise õnnestunud Kasutaja peab saama soovi korral veenduda, kas keegi pole tema nime 3.14 sisselogimise aega. Kui on Arendaja all vahepeal sisse loginud. 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 3.15 konfigureeritav kasutajasessiooni Aeg peab olema muudetav koos teiste konfiguratsiooniparameetritega. Arendaja aegumise aeg. Järgida tuleb uusimat RIA kodulehel avaldatud krüptograafiliste Krüpteerimise ja/või räside algoritmide kasutusvaldkondade ja elutsükli uuringut. Lubatud on: AES- 3.16 arvutamise korral tuleb kasutada 256, Blowfish-256, RSA-2048, SHA-2, RIPEMD-160 või tugevamaid. Arendaja tugevaid algoritme. Lahenduses tuleb välja tuua kõik krüptoalgoritmid, võtmepikkused ja kasutuskohad. Autenditud sessiooni tunnust ei Sessiooni ei tohi olla võimalik üle võtta sessioonitunnuse kopeerimisega 3.17 tohi ainult lihtsa küpsisega Arendaja ühest arvutist teise. lahendada.  AD või AAM-i autentimise kasutamisel peab rakendus Näiteks: konto on lukus, parool aegunud, konto aegunud, paroolipoliitika 3.18 kasutama ka AD või AAM-i Arendaja jne. kontoga kaasnevaid piiranguparameetreid. Tagada tuleb rollide lahusus. Administraatoril, halduril ja tavakasutajal on erinevad tööülesanded. Halduritel ei tohi olla võimalik 3.19 Rollide/õiguste kirjeldus peab lähtuma detailanalüüsist ja Arendaja muuta ega näha rakenduse kasutusjuhtudest. konfiguratsiooni. ID-kaardiga autentimisel, peab 3.20 rakendus suutma vastu võtta ID- Proxy tugi Arendaja kaardi sertifikaati ka päises. Kui kasutajaid hallatakse ka rakenduses ja autenditakse AD või AAM-i vahendusel, tuleb 3.21 sisselogimisel kõigepealt Eesmärk vähendada AD ja AAM-i koormust. Arendaja kontrollida kasutaja olemasolu rakenduses ja alles siis pöörduda AD või AAM-i poole. Rakendus ei tohi lubada ühe 3.23 kasutajaga mitut samaaegset Juhul kui lähteülesanne spetsiaalselt ei ütle teisiti. Arendaja sessiooni. Kui rakenduse tervikluse turvaosaklass on T3, peavad tõestusväärtust omavad andmed Milline lahendus valitakse tuleb kokku leppida tellijaga. Täpsustuseks vt 3.24 Arendaja olema kas ajatembeldatud, ISKE nõue HT.34. digiallkirjastatud või digitembeldatud.  Kui lahendus peaks kasutama Ajatempli kasutamise vajadus lepitakse eraldi kokku Tellija IT juhiga ja 3.25 ajatempli teenust, siis tuleks infoturbejuhiga. See sõltub Tellija keskse ajatempli kasutamise Arendaja eelistada Guardtime lahendust. võimalustest. Kui rakenduse tervikluse turvaosaklass on T3, peavad Täpsustuseks vt ISKE nõue HT.10. Krüptoahela kasutamise vajadus tõestusväärtust omavad andmed 3.26 lepitakse eraldi kokku Tellija infrastrktuuri juhiga ja infoturbejuhiga. See Arendaja olema krüptoaheldatud, et tagada sõltub Tellija keskse krüptoahela kasutamise võimalustest. et tõestusväärtusega andmeid ei saaks märkamatult kustutada. Kui rakenduses on S3 salastuse astmega andmeid, peavad need 3.27 Täpsustuseks vt ISKE nõue HT.37 . Arendaja olema nii transpordi ajal ja ka salvestatult alati krüpteeritult. Arendaja arendab arenduskeskkonnas ja annab tarne üle tellijale Rakendus ja selle komponendid paigalduspakkidena. Tellija paigaldab selle testkeskkonda ja testib ning 3.29 peavad võimaldama kasutada Arendaja seejärel paigaldab tarne toodangu keskkonda. Reaalseid andmekogu keskkondade lahusust andmeid tohib töödelda üksnes toodangu keskkonnas. Krüptograafiat kasutav rakenduskood ei tohi nimeliselt välja kutsuda krüptograafilisi algoritme, vaid peaksid seda tegema vahendavate Rakendus peab võimaldama vaheteekide kaudu üldiste funktsioonide järgi (nt krüpteerimine, 3.30 hõlpsalt välja vahetada aegunud Arendaja dekrüpteerimine, signeerimine, signatuuri verifitseerimine jne). ja ebaturvalise krüptoalgoritmi. Dokumentatsioon peab kajastama üldist kirjeldust, kuidas vajadusel ebaturvaline krüptoalgoritm välja vahetada. Rakenduse andmebaasi Andmebaasides kasutatavad krüpteerimisfunktsioonidest tingitud krüpteerimisega seotud 3.31 lisaväljad peaksid olema muudetava pikkusega, et formaati muutmata Arendaja andmeväljad peavad olema saaks kasutada teistsuguste parameetritega krüpteerimisalgoritme. muudetava pikkusega. Logimine, debuggimine, testimine  Testlehe kättesaadavus erinevatest arvutivõrkudest peab olema konfigureeritav. Testleht peab uuendama ennast lehe pärimisel. Testleht peab sisaldama custom builtrakenduse versiooni numbrit, standardsed komponendid (veebiserver, andmebaas, CMS'id jms) ei tohi oma Rakendusel peab olema versioone reeta. Samuti peab testlehel olema infot rakenduse (vajadusel 4.1 masinloetav testleht (JSON, Arendaja tema erinevate osade) ja tema kõigi väliste liideste staatuse kohta XML). (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). Rakenduse kõik üleantavad 4.2 versioonid peavad enne tellijale Testitulemused tuleb edastada tellijale koos rakenduse üleandmisega Arendaja üle andmist olema testitud Rakendus peab logima kasutaja edukat ja ebaedukat autentimist Logima peab ka autentimise ebaõnnestumise koos põhjusega (vale ja sessiooni lõpetamist, kasutaja parool, aegunud konto jne). Logida tuleks IP-aadress, meetod ja kui IP ja autentimismeetodit (ID- võimalik kasutajatunnus (mobiil-ID puhul telefoni number, ID-kaardi 4.3 Arendaja kaart, mobiil-ID vms), eduka puhul isikukood). Kui rakendus kasutab kasutajate autentimiseks AAM-i autendi puhul tuleks logida ka või TARA, siis leppida projektijuhiga eraldi kokku autentimise detailsus kasutaja isikukood ja mobiil-ID ehk mis kajastatakse AAM-is või TARA-s ja mis rakenduses. puhul telefoninumber Erinevate logifailide kirjeid peab olema võimalik seotud 4.4 Näiteks timestamp või mingi (request)ID abil. Arendaja komponentide logidega loogiliselt kokku viia. Rakendus peab suutma logida kõiki X-tee teenuste kaudu Vajalik eelkõige debuggimiseks ja toodangu keskkonna 4.5 liikuvaid andmeid. Peab olema Arendaja probleemide lahendamiseks. võimalus logimist sisse-välja lülitada.  Kui rakenduse ISKE Andmetöötlust peab olema võimalik kokku viia konkreetse kasutajaga konfidentsiaalsus turvaosaklass ning sessiooniinfoga. Isikuandmete kaitse seadus §25 lg2 on 2 või kõrgem, peab rakendus p3:(Isikuandmete töötleja on kohustatud) ära hoidma isikuandmete 4.6 logima kõiki konfidentsiaalsus omavolilist salvestamist, muutmist ja kustutamist ningtagama, et Arendaja klassiga 2 või kõrgemate tagantjärele oleks võimalik kindlaks teha, millal, kelle poolt ja milliseid andmete loomist, muutmist (sh isikuandmeid salvestati, muudeti või kustutati või millal, kelle poolt ja kustutamist) ja vaatamist. millistele isikuandmetele andmetöötlussüsteemis juurdepääs saadi; Andmetöötlust peab olema võimalik kokku viia konkreetse kasutajaga Kui rakenduse ISKE tervikluse ning sessiooniinfoga. Isikuandmete kaitse seadus §25 lg2 turvaosaklass on 2 või kõrgem p3:(Isikuandmete töötleja on kohustatud) ära hoidma isikuandmete peab rakendus logima 4.7 omavolilist salvestamist, muutmist ja kustutamist ningtagama, et Arendaja kõiki tervikluse klassiga 2 tagantjärele oleks võimalik kindlaks teha, millal, kelle poolt ja milliseid andmete loomist ja muutmist (sh isikuandmeid salvestati, muudeti või kustutati või millal, kelle poolt ja kustutamist). millistele isikuandmetele andmetöötlussüsteemis juurdepääs saadi; Kui rakenduse andmete konfidentsiaalsuse turvaosaklass Lahendus peab tagama, et administraatorid/haldurid ei saa andmete on 3, siis ka kõiki vaatamise logimist ise (ka tavakasutajate logimist) deaktiveerida või 4.8 administraatorite ja haldurite Arendaja logisid kustutada/muuta. Võib tellijaga kokku leppel nõudest loobuda poolt tehtavaid andmete kui andmed on krüpteeritud. vaatamised (ka otse baasis) tuleb logida. Kui rakenduse andmete Lahendus peab tagama, et administraatorid/haldurid ei saa andmete tervikluse turvaosaklass on 3, siis muutmise logimist ise (ka tavakasutajate logimist) kinni keerata või ka kõiki administraatorite ja 4.9 logisid kustutada/muuta. Tellijaga kokkuleppel võib nõudest loobuda, Arendaja haldurite poolt tehtavaid andmete kui andmed on kaitstud digiallkirja, digitempli või välise osapoole muudatused (ka otse baasis) ajatempliga. tuleb logida. Andmete 4.10 loomise/vaatamise/muutmise/kus Logid peavad asetsema tsentraalses logiserveris Arendaja tutamise tegevused peab logima.  Andmebaasi logidest saadetakse reaalajas koopia failisüsteemi logisse ja seal logis peab Failisüsteemi logide eesmärk on koguda logid ühtesesse 4.11 kajastuma ka Arendaja logihaldussüsteemi, neid krüptoaheldada ja aegtembeldada. logimisfunktsionaalsuse aktiveerimise ja deaktiveerimise info (aeg, kasutaja jms) Jõudlustestide täpne kirjeldus tuleb kokku leppida detailanalüüsi käigus. Arendaja peab koos rakendusega tarnima skripti ja vajalikud Rakendusega peab olema kaasas 4.12 tarkvaralised vahendid kokkulepitud jõudlustestide läbiviimiseks. Arendaja skript jõudlustestide tegemiseks. Jõudlustestide läbiviimine ei tohi nõuda tellijalt omapoolset tarkvara arendamist, skriptide kirjutamist või litsentside ostmist. Rakendus peab logima kõiki Logi sisaldab minimaalselt vea tekkimise aega, veakoodi, veakirjeldust 4.13 rakenduses tekkivaid tehnilisi (stack trace, traceback vms), võimalusel kasutaja andmeid, HTTP-, Arendaja vigu. GET- ja POST-parameetrid ja nende väärtusi. Vea ja süsteemilogid peavad olema vähemalt failisüsteemi Kui logitakse mitmesse kohta, siis vajadusel peab saama ühte või teise 4.14 tekstifailis üldtuntud vormingus, kohta logimist välja lülitada. Logi peab olema lihtsalt masintöödeldav ja Arendaja lisaks võib ka andmebaasis tuntud vormingus. Näiteks syslog, syslog-ng, XML, CSV. hoida.  Failisüsteemi logimise korral peavad logid olema ka katalogiseeritud (näiteks kuupäeva või liigi järgi) ja üldtunnustatud faililaiendiga (näiteks .log, .txt, .xml), logi 4.15 peab olema roteeruv, et ei tekiks Ei tohi esinda olukorda, kus ühte kausta tekib rohkem kui 1000 faili. Arendaja liiga suuri faile (nt 5MB). Logifailide seadistamisel peab olema failinime/kaustatee nimedes võimalik kasutada keskkonnamuutujaid (kuupäev, masinanimi jne). Logimis parameetreid peab 4.16 saama muuta rakendust Näiteks log4j konfiguratsiooni failis "monitoring-interval". Arendaja taaskäivitamata. Arhitektuuriline lahendus peab 4.17 olema 75% ulatuses kaetud Arendaja komponenditestidega (unit test). Arhitektuuriline lahendus peab olema 50% ulatuses kaetud automatiseeritud integratsiooni ja 4.18 Arendaja vastuvõtutestidega (integrationtest, api end-to-end test).  Kasutajaliidese testimise osakaal kogu testimise mahust peab olema mõistlik (mitte ületades 30%), rakendades seda kriitilisele funktsionaalsusele 4.19 Arendaja (lepitakse tööde käigus kokku). 50% kasutajaliidese testimisest peab olema automatiseeritud ja korduvkasutatav kokkulepitud raamistikul (nt Selenium) Nõuded rakenduse lähtekoodile NB! Nõuet ei arvestata arendustarkvara poolt automaatselt Lähtekoodi kommentaarid genereeritavate koodilõikude puhul – neid ei ole vaja tõlkida. Samuti ei peavad kõigis lahenduse kihtides rakendata nõuet kolmandate osapoolte poolt toodetud lähtekoodile – nt 5.1 (rakenduse enda kood, Arendaja igasugu erinevad lahtise koodiga koodilõigud jms. Kui on tegu andmebaas, jne) olema kirjutatud olemasoleva süsteemi edasiarendusega, siis peaks kommentaarides inglise keeles. kasutama eelnevalt kasutatud keelt. Muutujate, tüüpide ja funktsioonide nimed peavad 5.3 Parim praktika Arendaja olema sisulised ja andma aimu nende otstarbest. Koodis kasutatavad konstandid ja Parim praktika. Nt Identifikaator --> ID. Front-End reeglid on 5.4 lühendid tuleb kirjutada suurte Arendaja kirjeldatud Front-end arendusreeglid lehel tähtedega. Koodis kasutatavaid konstante ei tohi selle kasutamise kohta 5.5 väärtusena hardcodeda – need - Arendaja tuleb defineerida muutujatena ja kasutada läbi nende.  Koodis defineeritud andmetüübid peavad olema nimetava käände ainsuses. Kõik andmemassiivid N:Isik; Menetlus; jne. Andmebaaside 5.6 Arendaja tuleb nimetada nimetava struktuurikirjeldustes/andmemudelis ei tohi kasutada täpitähti. mitmuses (st igasugu collectionid, arrayd, jms). Andmetabelites sisalduvad Kasutada tuleb konkreetse andmebaasisüsteemi nimetamise parimaid võõrvõtmed peavad nime järgi 5.7 praktikaid. Nt kui on tegu tabelitega ’Isikud’ ja ’Autod’, siis seos ’isiku Arendaja seostuma tabeli ja väljaga millele autod’ oleks: Isikud.ID=Autod.Isik_ID need viitavad. Andmebaasi väljade pikkused Selle asemel, et eraldada väljale x baiti, tuleb eraldada x tähemärki. 5.8 tuleb kirjeldada sümbolites, mitte (Instead of allocating x bytes of storage for the field, x chars of storage Arendaja baitides. must be allocated). Kui kokku pole lepitud teisiti, siis Java rakenduse kood peab olema kirjutatud vastavalt 5.9 "Google Java Style Guide" Arendaja dokumendile: https://google.github.io/styleguid e/javaguide.html TEHIK-us on automaatseks koodivalideerimiseks kasutusel SonarQube (https://www.sonarqube.org/). Ennem üleandmist tuleb veenduda, et koodis puuduvad: Java koodi valideerimiseks kasutatakse tellija SonarQube 5.12 1. Turbedefektid Arendaja paigalduses seadistatud 2. Blokeerivad ja kriitilised vead reeglistiku Mõistlik on koodivalideerimine automatiseerida Gitlabi või Jenkinsi abil. Sõltub milline lahendus on projektis kasutusel.  Kasutuses mitteolev kood tuleb 5.15 rakenduse lähtekoodist - Arendaja kõrvaldada. Arendamisel kasutatakse DRY ja http://en.wikipedia.org/wiki/Don%27t_repeat_yourself 5.16 Arendaja SOLID printsiipe http://en.wikipedia.org/wiki/SOLID_(object-oriented_design) Üleantavas koodis ei tohi olla Kehtib ka siis, kui need on välja kommenteeritud. Kõik sellised paroolid 5.17 paroole, mida on kasutatud Arendaja tuleb asendada fraasiga “<password>“. arenduse käigus Rakenduste lähtekoodi tasemel ei tohi olla ühtegi sisse kodeeritud 5.18 Eelpoolmainitu haldamine toimub failis või andmebaasis. Arendaja parameetrit, väljade nimetust, veateadet. Andmekvaliteet ja standardid Aadressiandmete sisestamisel, kuvamisel ja hoidmisel tuleb Liidestatakse maaameti X-tee teenusega. 6.1 lähtuda Vabariigi Valitsuse Arendaja määrusest "Aadressiandmete https://www.riigiteataja.ee/akt/103102017005?leiaKehtiv süsteem". Rakendus peab võimalikult palju informatsiooni eeltäitma 6.2 Välja arvatud logimisvormi lahtrid autentimisel Arendaja automaatselt (kirje sisestamise kuupäev, kasutaja nimi jne).  Tegevusalade andmete sisestamisel, kuvamisel ja hoidmisel tuleb lähtuda Vabariigi Valitsuse 10. 6.3 - Arendaja Jaanuari 2008. a määrusest nr 11 "Klassifikaatorite süsteem" ja kasutada EMTAK infosüsteemis kehtivat klassifikaatorit. Tervishoiuteenuste osutajate andmete kasutamisel peab kontrollima nende andmeid, sh 6.4 Liidestatakse Terviseameti x-tee teenusega Arendaja tegevuslubade kehtivust Terviseameti Tegeuslubade registrist Tervishoiutöötajate andmete kasutamisel peab kontrollima 6.5 Liidestatakse Terviseameti x-tee teenusega Arendaja nende andmeid Terviseameti tervishoiutöötajate registrist Meditsiiniandmete vahetamiseks www.hl7.org Vajadusel on lubatud ka teiste standardite kasutamine, 6.6 tuleb kasutada meditsiiniandmete Arendaja kuid see tuleb tellijaga eraldi kokku leppida andmevahetuse standardit HL7 Tervise valdkonna Võimalusel tuleb kasutada olemasolevaid OID-e ja klassifikaatoreid, klassifikaatorid peavad olema Arendaja/ 6.7 mida vajadusel täiendatakse või luuakse uued ning publitseeritakse kooskõlas Tellija OID-ide ja Tellija samuti publitseerimiskeskuses http://pub.e-tervis.ee publitseerimiskeskusega Kasutajaliides  Kasutajaliidese kõik disainiotsused peavad olema 7.1 - Arendaja kooskõlastatud tellijaga enne nende realiseerimist Veebipõhine kasutajaliides peab olema kasutatav enamlevinud Minimaalselt Internet Explorer, Mozilla Firefox, Chrome ja Safari 7.2 veebibrauseritega, sh arenduse testimise hetkel tootja poolt toetatud versioonid. Täpsemad Arendaja nutiseadmetel (Android, IOS, nõuded dokumendis "Front-end arendusreeglid" Windows Phone) Rakenduse värviskeem ja logo Kui tegemist on struktuurfondide projektiga on lisaks nõutud ka vastav kasutamine peab vastama Tellija SF sümboolika. Tellija ametlikud CVI esitluspõhjad, logo kasutusjuhend 7.3 ametlikule visuaalsele ja kõik logod (ka jpg-na) küsida tellijalt. Iseteeniduse väljanägemine Arendaja identiteedile (CVI) ja tuleb vastaval RIA stiiliraamatule. Ametnikurakenduse väljanägemine disainijuhistele (UIG). vastavalt ametnikurakenduses kehtestatud stiiliraamatule. Kasutajaliidese kõik osad ja Kui soovitakse juurde eraldi ka muid keeli, siis see on spetsifitseeritud 7.4 teated peavad olema Arendaja hankedokumentides eestikeelsed. Toetatud peavad olema vähemalt resolutsioonid: 1920x1200, Avalikuks kasutamiseks tehtav 1920x1080, 1680x1050, 1600x1200, 1440x900, 1360x768, 1280x1024, rakendus peab olema graafiliselt 1280x960, 1280x800, 1280x768, 1152x864, 1024x768, 1024x600. eskaleeruv ja Ühegi nimetatud resolutsiooni korral ei tohi tekkida lehe ülest 7.5 Arendaja mugavalt kasutatav kõigi horisontaalset kerimisriba. Mahukate andmekogumite väikestel enamlevinud arvutite monitoride ekraanidel kuvamiseks üks lahendus võib olla komponendi sisene resolutsioonidega. kerimine x ja y teljel. Täpsed lahendused lepitakse kokku töö käigus ja vastavalt vajadusele.  Sisemiseks kasutamiseks tehtav rakendus peab olema graafiliselt Ühegi nimetatud resolutsiooni korral ei tohi tekkida lehe ülest eskaleeruv ja horisontaalset kerimisriba. Mahukate andmekogumite väikestel mugavalt kasutatav 7.6 ekraanidel kuvamiseks üks lahendus võib olla komponendi sisene Arendaja järgmiste monitoride kerimine x ja y teljel. Täpsed lahendused lepitakse kokku töö käigus ja resolutsioonidega: 1024x768, vastavalt vajadusele. 1280x1024, 1680x1050, 1920 x 1080, 1920x1200. Hüpikaknaid (pop-up) ei tohi 7.7 Silmas on peetud uusi veebilehtiseja aknaid avavaid hüpikaknaid Arendaja kasutada. Kasutajaliides peab alati küsima kinnituse andmete 7.9 kustutamise ja massmuutmiste - Arendaja kohta kui pole kokku lepitud teisiti. Rakenduse kasutamisel tekkinud veale peab kasutajaliides vastama Veateated peavad olema sellised, mis võimaldavad IT-abil võimalikult kasutajale eestikeelse 7.10 lihtsalt tuvastada vea olemuse ja asukoha. Kui kasutaja kasutab süsteemi Arendaja kasutajasõbraliku veateatega, mis mõnes võõrkeeles siis peavad veateated olema selles keeles sisaldab soovituslikult ka vea koodi. Kasutajaliides peab olema ilma rakenduse koodi muutmata Uue keele lisamine peab olema teostatav konfiguratsiooni failist või 7.11 Arendaja tõlgitav teise keelde, v.a kui ei administreerimisliidesest. ole kokkulepitud teisiti. Rakenduse kasutajaliides peab 7.13 teavitama kasutajat ette sessioon Ette teavitamise aeg peab olema konfigureeritav. Arendaja aegumisest.  Kui vormile sisestatakse mahukaid andmevälju peab kasutajaliides kokku lepitud Kui vorm koosneb paljudest väiksest andmeväljadest (nt taotlus), siis 7.14 ajavahemike järel salvetama Arendaja jagatakse vorm etappideks ning salvestatakse vastava etapi lõpus. välja sisu, et sessiooni aegumisel või võrgu katkestuse korral juba sisestatud andmed ei kaoks. Sisestusvormidel andmete sisestamisel peab saama väljade Tabuleerimise järjekord tuleb HTML struktuurist. Pigem vältida käsitsi 7.15 vahel vastavalt äriloogikale Arendaja tabindex-ite seadmist. liikuda klaviatuuri abil tabulaatoriga. Interaktiivsete vormide puhul (näiteks faili üleslaadimine), ei tohiks lehe värskendamisega 7.16 - Arendaja tegevust korrata (faili taas üles laadida, andmeid saata, avaldust esitada). Kui päring võtab aega kauem kui 3 sekundit, peab kasutaja saama Ikoon peab muutuma liivakellaks ja/või kuvatakse teade: päringut 7.17 Arendaja visuaalse teate, et süsteem sooritatakse või muu tellijaga kokkulepitud indikaator. tegeleb päringu läbiviimisega. Esilehel (sisselogimata) ja ka pärast kasutaja sisselogimist peab olema lihtne võimalus teavitada kasutajat muudatustest või Näiteks võimalikud teavituses: mingi süsteemi osa on vigane, tuli mingi 7.18 Arendaja probleemidest. Teavitus peab uus funktsionaalsus, vahetage oma parool, uuendage isikuandmeid jne. olema halduri poolt lihtsalt lisatav ja olema kasutajale märgatav.  Infosüsteem peab funktsionaalse vea (näiteks kohustuslikkude väljade täitamata jätmisel) korral 7.20 kasutajale kuvama Arendaja kasutajasõbraliku veateate. Veateated peavad olema hallatavad. Päringu vastusena kuvatud tabeli veerge on võimalik 7.21 Arendaja andmete/teksti tähestikulises järjekorras sorteerida. Vastavalt RIA stiiliraamatule tähistatakse kohustuslikud väljad tekstiga. Kui vormil on kohustuslikke väljasid on rohkem kui mittekohustuslikke Vormide täitmisel peab kasutaja siis tähistatakse hoopiski mittekohustuslikud. Kui ametniku rakendus ei saama ülevaate kohustuslikest kasuta RIA stiiliraamatut siis tähistatakse kohustuslikud väljad tärniga. 7.22 Arendaja andmeväljadest enne vormi Oluline on ka meeles pidada, et lähtuvalt WCAG nõuetest täitmist https://www.w3.org/TR/WCAG20-TECHS/H90.html peab iga vormi alguses olema legend, mis selgitab kohustuslikke väljasid tähistavat sümbolit. Nt: *tähistab kohustuslikke väljasid Rakenduse andmeväljade mõisted peavad olema üheselt identifitseeritavad, korrektses eesti keeles (ilma kirjavigadeta) 7.23 ja vajadusel sisaldama selgitavat Korrektne keel ja õigekirjareeglite järgimine on sisuhaldajate ülesanne. Arendaja teksti. Abiinfo (kasutusjuhendid) peab olema kättesaadav rakenduse toimimise erinevatel etappidel.  Kasutajaliides peab vastama ka dokumendis "Front-end 7.24 Front-end arendusreeglid arendusreeglid" kirjeldatud reeglitele Dokumentatsioon Erandiks võivad olla kolmanda osapoole komponentide (mis pole Kogu rakenduse kirjutatud tellija jaoks) dokumentatsioon. Samuti võib erandiks olla 8.1 dokumentatsioon peab olema Arendaja välispooltega seotud projektid. Erandid tuleb kooskõlastada tellijaga kirjutatud eesti keeles. enne dokumentatsiooni koostamist Arendaja / Projektiju Lahendus kirjeldatakse RIHA 8.2 https://www.riigiteataja.ee/akt/12933746?leiaKehtiv#para6 ht / Tellija määruse nõuete kohaselt. RIHA haldur Rakenduse dokumentatsioon peab sisaldama paigaldusjuhiseid, varundatavate komponentide kirjeldust, Dokumentatsioon peab olema versioneeritud, muutmiskuupäevadega, kasutajate kasutusjuhendeid, autori nimedega, korrektse keelekasutusega, selge struktuuriga. peakasutajate ja administraatorite Dokumentatsiooni detailsus peab olema piisav, et sõltumatu kolmas 8.3 kasutusjuhendeid, tehnliste IT baasteadmistega isik suudaks dokumendist vajalikke Arendaja andmemudeleid, arhidektuurilisi järeldusi teha (st dokument peab olema arusaadav sellele isikule, kuid mudeleid, süsteemitehnilisi näiteks paigaldusjuhise järgi toimetades ei pea ta ebaõnnestunud tarnele kirjeldusi, nõudeid riistavarale, teostama veaanalüüsi). krüptoalgoritme ja võtmepikkuseid, SSL sertifikaatide kasutuskohti jms  Rakenduse dokumentatsioon peab sisaldama tabelite-andmete-logide mahu Esialgne kirjete mahu hinnang peab tulema lähteülesandest, ning 8.4 kasvu arvestuslikku hinnangut täpsustuma eel ja detailanalüüsi käigus. Mahuhinnang peab sisaldama ka Arendaja rakenduse sihipärase kasutamise logide säilitamise, arhiveerimise tähtaegu. korral ettenähtud arvu kasutajate poolt. (MB/GB kuus/aastas). Iga uue versiooniga peab alati Release notes peab kajastama kõiki muudatusi eelmise ja uue versiooni 8.5 välja tooma versiooni muudatuse Arendaja vahel. kirjeldused (release notes). Rakenduse dokumentatsioon peab vastama ka dokumendis 8.6 "Nõuded infosüsteemi Nõuded infosüsteemi dokumentatsioonile Arendaja dokumentatsioonile" kirjeldatud nõuetele Versioonihaldus Kõik rakenduse testimiseks, koolituseks või Arendajale antakse selleks õigused Tellija versioonihalduse implementeerimiseks üle antavad repositooriumi, kus ta peab hoidma oma erinevaid versioone. 9.1 tarkvarapaketid peavad olema Arendaja Versioonihalduse repositooriumi juurdepääsutaotlus esitatakse Tellija versioneeritud. Kasutama peab kasutajatoele läbi projektijuhi Tellija versioonihalduse repositooriumi. Nii arendamisel kui ka hoolduslepingute korral Arendajale antakse selleks õigused Tellija veahalduse keskkonda. 9.5 Arendaja kasutatakse Tellija veahalduse Juurdepääsutaotlus esitatakse Tellija kasutajatoele läbi projektijuhi keskkonda. Paigalduspaketi kooste  Näiteks võib lahenduse paigalduspaketi koosteprotsess ette näha, et Tarnitava lahenduse koosseisus käivitada tuleb rida shell-käske või võivad lahenduse koosseisus olla üle antava lähtekoodiga peavad valmis (Gradle, ..) koosteskriptid või mis iganes muu moodus 10.1 Arendaja kaasas olema kirjeldused sellest paigalduspaketi tekitamiseks. paigalduspaketi koosteks. Eelistatud on kasutada GitLab skripte. Kooste kirjelduste alusel valmiv paigalduspakett tohib sisaldada Näiteks: kompileeritavate keelte puhul ei tohi sisaldada lähtekoodi, kui 10.2 ainult minimaalse rakenduse Arendaja see pole vajalik rakenduse käitamiseks. käitamiseks vajamineva failikomplekti. Kooste kirjelduste alusel valmivat paigalduspaketti peab Näiteks ei tohi tekitada olukorda, kus rakenduse jooksutamiseks uues 10.3 Arendaja olema võimalik liigutada serveris tuleb see tingimata just sealsamas kokku kompileerida. erinevate masinate vahel. Administraatoril peab olema võimalus andmebaasi 10.5 Arendaja muudatuste skriptide sisus veenduda.  Nõuded infosüsteemi dokumentatsioonile Nõuded infosüsteemi dokumentatsioonile Versioon: 1.0 Dokumendid peavad vastama vähemalt alljärgnevatele tingimustele: Andmemudel (kuuluvus: [Tervise Infosüsteem] -> Infosüsteemi dokumentatsioon -> alamsüsteem -> 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 üleandmisel Kirjeldada andmemudelit jah jah kontseptuaalse mudelina interaktioone/seoseid Kasutaja õiguste ja tegevuste vastavustabel (kuuluvus: [Tervise Infosüsteem] -> Infosüsteemi dokumentatsioon -> alamsüsteem -> Kasutaja õiguste ja tegevuste vastavustabel) Eeldus dokumendile: Süsteemi üldine kirjeldus 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 üleandmisel Nimetada kasutaja rollid jah jah Teenuste/kasutuslugude dokumentatsioon (kuuluvus: [Tervise Infosüsteem] -> Infosüsteemi dokumentatsioon -> alamsüsteem -> Teenused ja kasutuslood) Eeldus dokumendile: Süsteemi üldine kirjeldus Otstarve: Kirjeldab detailselt üleantavaid teenuseid/kasutuslugusid. Sisu: Teenuste/kasutuslugude detailse kirjelduse sisuks on: • Infosüsteemi kasutusloo/andmevahetuse teenusepõhised nõuded (ärinõuded ja neile vastavad detailsed funktsionaalsuse nõuded); • 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 ) 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 üleandmisel Nimetada kasutuslood jah jah Arhitektuuridokument (kuuluvus: [Tervise Infosüsteem] -> Infosüsteemi dokumentatsioon -> alamsüsteem -> Arhitektuur) Eeldus dokumendile: Süsteemi üldine kirjeldus 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 (Arhitektuuridokumendimall_v1.1): 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 X 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 üleandmisel Dokumendi esialgne versioon jah Seadmete ja tarkvara kasutajakesksed juhendid (kuuluvus: [Tervise Infosüsteem] -> Infosüsteemi dokumentatsioon -> alamsüsteem -> -> Seadmete ja tarkvara kasutajakesksed juhendid) Eeldus dokumendile: Teenuste/kasutuslugude dokumentatsioon Otstarve: Teenuse funktsionaalsuse kasutamiseks ja kasutuslugude läbimiseks vajalikud juhised Sisu: Igale esitluskihile peab olema koostatud eraldi kasutusjuhend, mis kirjeldab vastava komponendi funktsionaalsuse kasutusvoo põhiselt. Kirjeldus tarkvara ja 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 Sihtgrupp: Tarkvara kasutajad, peakasutaja, rakenduse administraator Ajakava: enne esimese arendusetapi algust enne igat arendusetapi algust igakordsel üleandmisel jah Paigalduse ja administreerimise juhend (kuuluvus: [Tervise Infosüsteem] -> Infosüsteemi dokumentatsioon -> alamsüsteem -> Paigalduse ja administreerimise juhend) Eeldus dokumendile: Arhitektuuridokument 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. 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. 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 Sihtgrupp: Peakasutaja, projektijuht, süsteemiadministraator Ajakava: enne esimese arendusetapi algust enne igat arendusetapi algust igakordsel üleandmisel jah Lähtekood (sh andmebaasi struktuur) (Kuuluvus:Lähtekoodi üleandmine lepitakse kokku Tellijapoolse projektijuhiga) 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 üleandmisel Minimaalselt iga nädalal tagant uuendada versioonihalduskeskkonnas. Testide ettevalmistuse dokumentatsioon (kuuluvus: [Tervise Infosüsteem] -> Infosüsteemi dokumentatsioon -> alamsüsteem -> Testiplaanid) 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 üleandmisel Nimetada kasutuslood, mille puhul jah rakendatakse koormusteste Testimise tulemite dokumentatsioon (kuuluvus: [Tervise Infosüsteem] -> Infosüsteemi dokumentatsioon -> alamsüsteem -> Testimise tulemid) Eeldus dokumendile: Testide ettevalmistuse dokumentatsioon Otstarve: Anda tellijale ülevaade läbiviidud testimise tulemustest ning esitada soovitused testandmete ja dokumentatsiooni parendamiseks (ettevalmistus, paigaldus, kasutuslugude kirjeldus jne). Sisu: Teostatud arenduste testimisel saadud informatsioon (näiteks testlood, testraport, testiplaan, testide kood jms). Peab vastama „Nõuded testimisele“ dokumendile. 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 Sihtgrupp: Arhitekt, süsteemiadministraator, turvaspetsialist Ajakava: enne esimese arendusetapi algust enne igat arendusetapi algust igakordsel üleandmisel jah Taasteplaani tegemise juhend (kuuluvus: [Tervise Infosüsteem] -> Infosüsteemi dokumentatsioon -> alamsüsteem -> Taasteplaani 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: Süsteemiadministraator Ajakava: enne esimese arendusetapi algust enne igat arendusetapi algust igakordsel üleandmisel jah Andmekogude semantiline kirjeldus ja andmekoosseis (kuuluvus: [Tervise Infosüsteem] -> Infosüsteemi dokumentatsioon -> alamsüsteem - > [Loomise kuupäev YYYY-MM-DD]_[Tervise_infosüsteem_alamsüsteemi_nimi].owl; [Loomise kuupäev YYYY-MM-DD]_ [Tervise_infosüsteem_alamsüsteemi_nimi].xmi ) Sisu: Andmekogu(de) semantiline kirjeldus masinloetaval kujul (OWL-formaadis) ja andmekoosseis (XMI-formaadis) vastavalt RIHA määrusega kehtestatud nõuetele ning infosüsteemi ontoloogiat kirjeldav dokument. Sihtgrupp: Tellija, tellijapoolne projektijuht Ajakava: enne esimese arendusetapi algust enne igat arendusetapi algust igakordsel üleandmisel Esitada viimasel etapil UML vaated (kuuluvus: [Tervise Infosüsteem] -> Infosüsteemi dokumentatsioon -> alamsüsteem -> [Tervise_infosüsteem_alamsüsteemi_nimi]. eap) Otstarve: Protsessi, kasutuslugude, süsteemi arhitektuuri vaadete kaudu muuta süsteem läbipaistvamaks ja ülevaatlikumaks Sisu: Loogiline vaade (Logical view) - komponendid, liidesed, rakenduskihi ja ärikihi loogika Protsessi vaade (Process view) – jõudlus, skaleeritavus, läbilaskevõime Rakendus vaade (Deployment diagram) – süsteemi topoloogia, kasutuselevõtmine, paigaldamine Sihtgrupp: Peakasutaja, projektijuht, süsteemiadministraator, arhitekt Ajakava: enne esimese arendusetapi algust enne igat arendusetapi algust igakordsel üleandmisel jah jah Üldised nõuded: Üleantav dokument peab sisaldama sisseviidud muudatusi nii, et on väljatoodud muutunud ja lisandunud osa (võrreldes viimati üleantuga)  Sotsiaalteenuste ja -toetuste andmeregistri hooldus- ja väiketööd Hankeleping nr 3-9/1893-1 Tervise ja Heaolu Infosüsteemide Keskus (edaspidi tellija), registrikood 70009700, aadress Uus-Tatari 25, Tallinn, keda esindab põhimääruse ja direktori käskkirja alusel Lauri Treima (infosüsteemihalduse osakonna juhataja direktori ülesannetes) ja Dolm IT OÜ (edaspidi täitja), registrikood 12809505, aadress Lõõtsa 12, Tallinn, keda esindab juhatuse liige Mait Piir edaspidi nimetatud ka eraldi pool või koos pooled, sõlmisid hankelepingu (edaspidi leping) alljärgnevas: 1. LEPINGU EESMÄRK 1.1. Tellija poolt korraldatud riigihanke „Sotsiaalteenuste ja –toetuste andmeregistri hooldus- ja väiketööd“ (riigihanke viitenumber 208287) alusel sõlmitud lepingu eesmärk on kirjeldada lepingu kehtivuse ajal poolte õigused, kohustused ja vastutus, määrata kindlaks tellimuste esitamise tingimused ja lepingu täitmise eest makstav tasu. 1.2. Lepingu alusel teostatavate tööde täpne sisu, maht ja teostamise tähtaeg lepitakse kokku tellimuse esitamisel lähtudes käesolevas lepingus ja selle lisades fikseeritud tingimustest. 2. LEPINGU ESE 2.1. Lepingu esemeks on Sotsiaalteenuste ja -toetuste andmeregistri (edaspidi STAR) hooldus- ja väiketööde teostamine vastavalt lepingu lisas 1 (tehniline kirjeldus) kokkulepitud spetsifikatsioonile (edaspidi tööd). 2.2. Lepingu juurde kuuluvateks lahutamatuteks osadeks loetakse lepingu lisad, riigihanke alusdokumendid ja täitja riigihankes esitatud pakkumus. 3. LEPINGU ÜLDTINGIMUSED 3.1. Tööde teostamisel lähtutakse lisaks lepingule ja selle lisadele tellimustes fikseeritud tingimustest. Tellija võib teha muudatusi kodukorda, mittefunktsionaalsetesse nõuetesse ja infosüsteemi dokumenteerimise nõuetesse, teavitades täitjat muudatustest. 3.2. Kui tellimuse tingimus erineb lepingu tingimusest, loetakse ülimuslikuks tellimuse tingimus. 3.3. Pooled teevad lepingu täitmiseks ja eesmärkide saavutamiseks koostööd. Lepingu täitmisel kohustuvad pooled tegema kõik vajalikud pingutused, et täita õigeaegselt ja korrektselt kõiki lepingust ning õigusaktidest tulenevaid kohustusi. 3.4. Tellija eeldab, et täitja on lepingu esemeks olevate tööde valdkonna professionaal, kes saab aru ning võtab teadlikult enda kanda lepingu funktsionaalsete ja mittefunktsionaalsete nõuete täidetavuse ja tulemuse saavutatavuse riski. Tellija eeldab, et kõik tegevused, mida ei ole lepingus otsesõnu nimetatud, ent mis moodustavad oma olemusest lähtudes hooldus- ja väiketööde teostamise lahutamatu osa, kuuluvad täitja poolt lepingu täitmise raames teostamisele. Nimetatud tegevused ei kuulu teistsuguse kirjaliku kokkuleppe puudumisel eraldi tasustamisele. 3.5. Tööde teostamise keel on eesti keel, muuhulgas on see ka tellimuste esitamise, töökoosolekute jm suhtluse ning teostatud tööde dokumenteerimise keel. 3.6. Kui pool on teinud teisele poolele lepingu täitmisega seotud küsimuses päringu, on teine pool kohustatud sellele sisuliselt reageerima (asjakohast tagasisidet andma) võimalikult kiiresti, kuid hiljemalt 3 tööpäeva jooksul. 3.7. Pooled lähtuvad probleemidele reageerimise ja lahendamise tähtaegade arvestamisel kriitilisuse astmetest, mis on fikseeritud lepingu lisas 1. Kriitilisuse astme määrab tellimuse esitamisel tellija. 3.8. Täitja on kohustatud tagama lepingu täitmiseks vajalike ressursside olemasolu, sh tagama töö teostajate kõrge professionaalse taseme ja vajaliku tehnoloogia/ metoodikate väga hea tundmise ning tehtud tööde dokumenteerimise vastavalt tellija vormidele ja/või suunistele, samuti omama tööde teostamiseks sobivaid keskkondi, koos kõige sinna juurde kuuluvaga, sh kasutatava tarkvara litsentsid või kasutama tellija olemasolevaid jagatud keskkondi. Väiketööde puhul on täitja kohustatud litsentsimudeli valikul arvesse võtma tellija varem soetatud tarkvara litsentsitingimusi või juhinduma tellija vajadustest. 3.9. Tellijal või tema poolt määratud esindajal on õigus jooksvalt kontrollida lepingu täitmist. Tellijal või tema esindajal on õigus anda täitjale suuniseid lepingu täitmiseks ning täitja on kohustatud neid järgima. 3.10. Täitja on kohustatud viivitamatult informeerima tellijat tööde teostamist takistavatest asjaoludest, mis segavad tööde teostamist ja tähtaegadest kinnipidamist. 3.11. Pooltel on kohustus osa võtta töökoosolekutest töö käigus tekkinud probleemide lahendamiseks ja infovahetuseks tellija juures kohapeal või virtuaalselt. Informatsioonivahetust töökoosolekute vormis ei tasustata. 3.12. Tellija kindlustab informatsiooni saamiseks vajalike inimeste ja töödeks vajamineva dokumentatsiooni ning kaugjuurdepääsu kättesaadavuse, mis võib olla lepingu täitmiseks oluline ja mida täitja mõistlikkuse piirides lepingu täitmiseks nõuda võib. Täitja peab takistama juurdepääsu tellija infosüsteemidele töödega mitte seotud isikutele. 3.13. Täitja poolne tööde teostamine ei tohi tekitada häireid tellija mistahes teiste liidestatud süsteemide või teenuste talitluses, v.a juhul kui täitja lähtus töö teostamisel tellija juhistest ja kokkulepetest, kuid sellele vaatamata tekkisid häired. Juhul, kui töö teostamine toimub tellija ruumides, peavad tellija ruumides viibivad täitja poolsed töö teostajad kinni pidama tellija sellistest sisekorraeeskirjadest, sh turvanõuetest, mis on neile teatavaks tehtud. 3.14. Täitja kohustub võimaldama tööde teostamist rakenduste arendamisel ka teiste tellija lepingupartnerite poolt, kui rakenduse arendustöid tellitakse väljaspool käesolevat lepingut (nt lisaarendustööd Euroopa Liidu või muudest välisvahenditest rahastuse korral). 3.15. Tellija võib kontrollida täitja poolt tööde teostamiseks kasutatava alltöövõtja osas kõrvaldamise aluste puudumist vastavalt RHS § 95 lõigetes 1 ja 4 sätestatule. Kui Tellija tuvastab, et alltöövõtjal esineb RHS § 95 lõikes 1 sätestatud alus, nõuab ta pakkujalt sellise alltöövõtja asendamist. Kui alltöövõtjal esineb § 95 lõikes 4 sätestatud alus, võib hankija nõuda pakkujalt sellise alltöövõtja asendamist (RHS § 122 lg 7). 4. LEPINGU HIND JA TÖÖDE ÜLEANDMINE 4.1. Tellija garanteerib igas kalendrikuus kogu lepingu kehtivuse perioodil hooldus- ja väiketööde tellimise mahus 50 töötundi, mille eest tasutakse kokku kuutasuna 2148,50 (kaks tuhat ükssada nelikümmend kaheksa ja viiskümmend senti) eurot ilma käibemaksuta. Tasu on kokku lepitud vastavalt riigihankes esitatud pakkumusele, täitja ei saa tasu lepingu kehtivuse perioodil tõsta. 4.2. Punktis 4.1 nimetatud hooldus- ja väiketööde mahu ületamisel, tasub tellija iga täiendava töötunni eest (alates 51. töötunnist) reaalselt teostatud töötundide põhiselt. Alates 51. töötunnist on tööde teostamise maksimaalne ühe töötunni hind 45,97 (nelikümmend viis ja üheksakümmend seitse senti) eurot ilma käibemaksuta. Täitja ei saa ühe töötunni hinda lepingu kehtivuse perioodil tõsta. 4.3. Lepingu maht on maksimaalselt 300 000 (kolmsada tuhat) eurot käibemaksuta. Tellija ei garanteeri nimetatud mahus tööde tellimist ja täitjal puudub õigus nõudmaks konkreetses mahus tööde tellimist või tasu. 4.4. Vajadusel on poolte kokkuleppel õigus lepingu mahtu kuni 20% ulatuses suurendada. Mahu muutmine toimub poolte kokkuleppel kirjalikku taasesitamist võimaldavas digitaalselt allkirjastatud või sellega samaväärses vormis. 4.5. Tööde eest tasutakse tööde üleandmise–vastuvõtmise akti (edaspidi ka akt) alusel. Täitja annab tööd üle koos omalt poolt allkirjastatud aktiga. 4.5.1. Eelneval kalendrikuul teostatud ja tööde halduskeskkonnas suletud staatusesse (Closed) määratud tööde kohta esitatakse akt üks kord kalendrikuus hiljemalt järgneva kuu 10. kuupäevaks. 4.5.2. Tellija võtab tööd vastu, allkirjastades akti omalt poolt hiljemalt viie tööpäeva jooksul, kui tellijal puuduvad pretensioonid. 4.5.3. Aktis peab kajastuma viide tellimusele tööde halduskeskkonnas, sh töö number, tööde üle andmise aeg, teostatud töö maht tundides, hooldus- või väiketöö lühikirjeldus, töö prioriteet ning akti koostanud isiku nimi ja allkiri. 4.6. Täitjal on õigus esitada arve pärast akti allkirjastamist poolte poolt. Arve esitatakse masinloetaval kujul e-posti aadressile [email protected]. 4.7. Tellijale antav maksetähtaeg peab olema vähemalt 21 kalendripäeva arvates tellija poolt nõuetekohase arve kättesaamisest. 5. POOLTE ESINDAJAD JA TÄITJA MEESKOND 5.1. Teadete edastamine toimub üldjuhul e-posti teel, lähtudes 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. 5.2. Poolte vahelise koostöö korraldamise eest vastutavad poolte esindajad: 5.2.1. Tellija esindaja lepingu täitmisel on Eve Jürgenson, e-post: [email protected], tel: 7943810. 5.2.2. Täitja esindaja lepingu täitmisel on Daniel Leifer, e-post: [email protected], tel: 53000 0025. 5.3. Esindaja vahetumise korral tuleb koheselt kirjalikku taasesitamist võimaldavas vormis informeerida teise poole esindajat. 5.4. Esindajate volitused on piiratud lepingu täitmisega seotud küsimustega. Esindajate pädevuses on anda teisele poolele tööde teostamiseks vajaliku informatsiooni ja juhiseid oma pädevuse piires, esitada tööde halduskeskkonna kaudu tellimusi, kontrollida teostatud tööde kvaliteeti, anda töö üle ja võtta töö vastu ning allkirjastada akt. 5.5. Täitja tagab riigihankes pakkumusega esitatud meeskonnaliikmete (lisa 4) 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.6. Täitja meeskonnaliikme ettevõttest lahkumise, haigestumise jms juhtumite korral asendab täitja konkreetse spetsialisti hiljemalt kahe nädala jooksul. 5.7. 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 lepingu korrektset ja õigeaegset täitmist. Täitja kannab kõik asendusest tulenevad või sellega kaasnevad kulud. 5.8. Tellija võib lepingu sõlmimisel tellida lisaks kokku lepitud meeskonnaliikmete rollidele (lisa 4) uusi rolle, kui see on tingitud tellitavate tööde iseloomust ja tööde efektiivseks teostamiseks on otstarbekas kaasata teistsuguse kompetentsiga meeskonnaliikmeid. 6. TÖÖDE TELLIMINE JA DOKUMENTEERIMINE 6.1. Lepingu raames tellitakse töid tööde halduskeskkonnas tööülesande täitmiseks suunamise teel. 6.2. Tellija võimaldab täitjale tööde teostamiseks ligipääsu selleks vajalikesse keskkondadesse. Ligipääsu tehnilised tingimused jms täpsustatakse lepingu täitmise käigus. 6.3. Arenduskeskkond asub täitja juures. Arenduskeskkonna töökorras hoidmist tellija ei kompenseeri. Arenduskeskkonna tarkvara platvorm ja selle versioonid peavad olema samaväärsed tellija test- ja toodangukeskkonna omadega või vastavalt kokkuleppele uuemad. 6.4. Täitja tagab rakenduste hooldusteenuste osutamiseks valmisoleku ja omapoolse abi kuni veaolukorra kõrvaldamiseni vastavalt lisas 1 toodud tingimustele, vajadusel ka väljakutse korras kohapeal. 6.5. Kõik tööde tulemused dokumenteeritakse ja hallatakse tellija poolt näidatud dokumendihaldussüsteemis. Kõik töödega seonduv dokumentatsioon (tarneteatised, juhendid, spetsifikatsioonid, lähtekood, testiraportid jm) lisatakse tellija poolt näidatud projektiga seotud dokumendihalduskeskkonda. 6.6. Töödele lisatud või tööde käigus loodud dokumentatsioon peab olema eesti keelne ja terviklik, vastama töödele, sisaldama muudatusi ja olema terminoloogiliselt üheselt mõistetav ning detailne vastavalt tellija suunistele, et tellija saaks käesoleva lepingu alusel loodud töid efektiivselt kasutada, hooldada ja kohandada, täiendades juba olemas olevat dokumentatsiooni või koostades vajadusel uue dokumentatsiooni. 6.7. Tööde dokumentatsioon ja kasutusjuhendid peavad tagama tellijale võimaluse tööde tulemit tulevikus parandada ja arendada, samuti koolitada ja juhendada oma töötajaid tööde kasutamisel. Tööde dokumentatsioon peab olema laetud üles tellija määratud keskkonda. 6.8. Täitja kohustub lähtekoodi dokumenteerimisel juhinduma tellija poolt kehtestatud mittefunktsionaalsetest nõuetest arendustele, mis on ajas muutuv dokument. Tellija teavitab dokumendi muudatustest. Tööde käigus loodud lähtekood peab olema kirjutatud ja dokumenteeritud selliselt, et vajadusel oleks tellija või kolmas isik võimeline aru saama tarkvara loogilisest ülesehitusest ning jätkama lähtekoodi arendusega. 6.9. Tööde tulem peab olema dokumenteeritud lähtuvalt konkreetsete tööde iseloomust, juhindudes tehnilisest kirjeldusest ja kehtivast kodukorrast, kui lepingus ei ole kokku lepitud teisiti. 7. TÖÖDE ÜLEANDMINE JA VASTUVÕTMINE 7.1. Täitja kohustub töö teostama lepingu lisas 1 kokkulepitud ja tellimuses näidatud tähtaegadel ja tingimustel. Tööde lahutamatuks osaks, mis tuleb üle anda koos töödega, on tööde juurde kuuluv nõuetekohane dokumentatsioon (sh kasutusjuhendid), kommenteeritud lähtekood ja intellektuaalomandi õigused. 7.2. Töö nõuetekohase teostamise hetke arvestatakse tellija poolt näidatud tööde halduskeskkonnas tööülesande täitjale testimiseks suunamise hetke alusel, kui tellijal puuduvad pretensioonid töö nõuetekohasuse osas. 7.3. Tööde halduskeskkonnas tellijale testimiseks suunatud tööd peavad olema täitja poolt testitud vastavalt kehtivale kodukorrale. 7.4. Tellija ei aktsepteeri töid tööde halduskeskkonnas (ei määra staatusesse Closed) enne, kui tööd on läbinud tellija poolt eduka vastuvõtutestimise kehtivas kodukorras või lepingus fikseeritud tingimustel. 7.5. Tellija teavitab täitjat testimise käigus avastatud vigadest, andes täitjale mõistliku tähtaja vigade parandamiseks enne tööde teistkordset üle andmist. 7.6. Testimise käigus avastatud ja täitjale teatavaks tehtud vead parandab täitja omal kulul, andes parandatud tööd tellijale üle kokkulepitud või lepingust tuleneval tähtajal. 7.7. Kui täitja annab vigade parandamise järgselt üle tööd, milles tellija vastuvõtutestimise käigus tuvastatakse jätkuvalt vigu (teistkordne vigadega tööde üleandmine), võib tellija otsustada, kas anda täitjale uus tähtaeg vigade parandamiseks, kõrvaldada vead ise või kolmanda isiku kaasabil, vähendades täitjale makstavat tasu võrdeliselt vigade parandamiseks tehtud kulutustega. 7.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. 7.9. Tööd annab täitja üle igakuiselt omalt poolt allkirjastatud aktiga. 7.10. Lepingu alusel teostatud tööde vastuvõtmise ajaks loetakse akti allkirjastamise aeg või aktis märgitud hilisem kuupäev. 8. INTELLEKTUAALNE OMAND 8.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. 8.2. Tasu autoriõiguste loovutamise ja litsentsi andmise eest sisaldub lepingu hinnas. 8.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 hetkest, loobudes sellega lepingu alusel üle antud originaalteoste osas õiguste kasutamisest. 8.4. Täitja tagab, et isiklikud õigused on ilma täitja nõusolekuta teostatavad muuhulgas järgnevas ulatuses: 8.4.1. tellijal on õigus tööd kasutada mis tahes eesmärgil ja viisil; 8.4.2. tellijal või tellija tellimusel kolmandatel isikutel on õigus teha üle antud töödes muudatusi ning neid täiendada; 8.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; 8.4.4. tööde üleandmisega tellijale kinnitab täitja, et tööd on üldsusele avaldamiseks valmis. 8.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 üle antud, kuid ei ole veel tellija poolt aktiga vastu võetud. 8.6. Kirjeldatud õigused ja litsentsid loetakse tellijale lõplikult üle läinuks pärast töö vastuvõtmist. 8.7. Täitja on kohustatud tagama intellektuaalse omandi õiguste (eeskätt autoriõiguste) olemasolu ja kehtivuse, samuti nende ülemineku tellijale viisil, mis võimaldab tellijal lepingu lõppedes üle võtta täitja funktsioonid. 8.8. 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 lepingu 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. 8.9. 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 omandist tulenevaid õigusi lepingu alusel üle antavate intellektuaalse omandi objektide suhtes, kannab täitja. 9. GARANTII 9.1. Täitja annab kõikidele lepingu alusel teostatud töödele ühe aastase garantii. Garantii katab kõiki garantii tähtaja jooksul ilmnenud tööde puudusi ja lepingu tingimustele mittevastavusi (edaspidi ka: viga). Garantii katab ka kõiki tööde muudatusi ja modifikatsioone, mis on tehtud täitja poolt ja mis ei ole oluliselt muutnud varasemalt tehtud tööd. 9.2. Garantii tähtaeg hakkab kulgema töö võtmisest ja kehtib üks aasta sõltumata käesoleva lepingu kehtivusest. 9.3. Täitja on garantii kehtivuse ajal kohustatud tasuta kõrvaldama töödes avalduvad vead ja lepingu tingimustele mittevastavused, sealhulgas on täitja kohustatud uuendama või asendama kõik esinenud veaga seonduvad dokumendid. 9.4. Tellija informeerib täitjat töös esinevatest vigadest, vea iseloomust ja ulatusest viivitamatult selle ilmnemisel, niivõrd kui seda saab tellijalt mõistlikult oodata. Tellija tagab täitjale kaasaabi garantiikohustuse alla käivate vigade ja puuduste kõrvaldamisel tellija võimekuse ja võimaluste piires. 9.5. Täitja on kohustatud garantii korras teostama eelkõige järgmist: 9.5.1. vea ilmnemisel vea otsimine (lokaliseerimine), veaolukorrale lahenduse leidmine ja vea parandamine; 9.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; 9.5.3. vea parandamisega seoses paigaldamise ja seadistamise toe pakkumine tellijale, samuti sellega seotud konsultatsioonid; 9.5.4. vigase või puuduliku dokumentatsiooni parandamine, sealhulgas dokumentatsiooni täiendamine ja uuendamine, kui selline vajadus tuleneb vigade parandamisest. 9.6. Täitja kõrvaldab garantiiperioodil ilmnenud vead sõltuvalt vea iseloomust hiljemalt viie tööpäeva jooksul. Kui vea kõrvaldamine nimetatud aja jooksul ei ole võimalik, teatab täitja tellijale põhjuse, miks vea parandamine ei ole viie tööpäeva jooksul võimalik ja millise aja jooksul on võimalik viga parandada. Kui täitja ei kõrvalda viga kokkulepitud tähtaja jooksul, võib tellija korraldada vea kõrvaldamise kolmanda isiku poolt täitja kulul. 9.7. Kui täitja ei kõrvalda viga või puudust kokkulepitud tähtajaks, võib tellija nimetatud vea ise kõrvaldada või korraldada puuduste kõrvaldamise kolmanda isiku kaasabil, teavitades sellest täitjat. Tellijal on õigus täitjalt nõuda kõigi kulutuste hüvitamist, mis tekkisid seoses eelkirjeldatud viisil vea või puuduse kõrvaldamisega, kui tegemist oli garantiiga hõlmatud vea või puudusega. 9.8. 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.  10. KONFIDENTSIAALSUSKOHUSTUS JA ISIKUANDMETE TÖÖTLEMINE 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, kui pooled ei ole kokku leppinud teisiti. 10.3. Pooled lepivad kokku isikuandmete töötlemise tingimused (lisa 2), juhindudes isikuandmete kaitse üldmääruse1 artiklist 28. 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 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 selle alusel sõlmitud 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 pool hüvitama kõik kahjud, mis sellise rikkumise tagajärjel teisele poolele või kolmandale isikule tekkisid, sõltumata sellest, kas rikkumine pandi toime lepingu kehtivuse ajal või lepinguliste kohustuste lõppemise järgselt. 11. VASTUTUS 11.1. Pooled vastutavad oma lepinguliste kohustuste rikkumise eest, välja arvatud, kui rikkumine on vabandatav. Eeldatakse, et rikkumine ei ole vabandatav. Rikkumine on vabandatav, kui esineb vääramatu jõud. Nimetatud asjaolu esinemist peab tõendama pool, kes sellele tugineda soovib. 11.2. Pool vastutab teise poole ees muuhulgas lepingu rikkumise eest, mis tuleneb poole poolt lepingu täitmisele kaasatud isikute tegevusest või tegevusetusest (sh alltöövõtjate tegevuse eest, keda täitja tööde teostamise kasutab). Pool ei vastuta lepinguliste kohustuste rikkumise eest, mis tulenes teise poole kohustuste rikkumisest 1 Euroopa Parlamendi ja Nõukogu määrus nr (EL) 2016/679  või kolmandate isikute tegevusest või tegemata jätmistest. Nimetatud asjaolude esinemist peab tõendama pool, kes sellele tugineda soovib. 11.3. 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. 11.4. 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 proportsionaalselt vastava aja võrra. 11.5. Poolte rahaline koguvastutus on piiratud lepingu kogumaksumusega, kuid nimetatud piirang ei kehti tahtliku rikkumise korral, intellektuaalomandiõiguse või andmekaitsealaste kohustuste rikkumise korral. 11.6. Juhul, kui tellija satub täitjale tööde eest tasu maksmisega viivitusse, on täitjal õigus esitada viivise nõue, mille suuruseks on 0,2% konkreetse töö eest välja maksmisele kuuluvalt tasult iga tasumisega viivitatud kalendripäeva eest, kuid mitte rohkem kui 25% konkreetse töö eest tasumisele kuuluvast kogusummast. Täitja esitab viivise nõude tellijale allkirjastatult vähemalt kirjalikku taasesitamist võimaldavas vormis. 11.7. Täitja poolse lepinguliste kohustuste rikkumisena käsitletakse eeskätt olukorda, kus tööd ei vasta osaliselt või täielikult lepingu tingimustele, ei ole teostatud vastavalt kokku lepitud kvaliteedile, ei ole teostatud ja üle antud tähtaegselt või esineb muu lepingus kokkulepitud kohustuse mittetäitmine. 11.8. Juhul, kui täitja rikub lepingulist kohustust (sh garantiist tulenevat kohustust), on tellijal õigus nõuda leppetrahvi tasumist, mille suurus on 200 eurot iga rikkumises oldud kalendripäeva eest, kuid mitte rohkem kui 25% lepingu kogumaksumusest. 11.9. Lepingu olulise rikkumise korral on tellijal õigus esitada täitjale leppetrahvi nõue 10 000 eurot iga rikkumise eest. Oluliseks lepingurikkumiseks loetakse punktis 12.5 kirjeldatut. Täitja poolse lepingu olulise rikkumise korral ei pea tellija määrama täitjale lepingu täitmiseks võlaõigusseaduse §-s 114 nimetatud täiendavat tähtaega ning tellijal on muu hulgas õigus leping üles öelda või lepingust taganeda. 11.10. 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. 11.11. Täitja on kohustatud leppetrahvi tasuma 2 nädala jooksul alates tellija poolt vastava nõude esitamisest, kui leppetrahvinõudes ei ole määratud teisiti. 11.12. Tellijal on õigus tasaarvestada leppetrahvi summa täitjale töö teostamise eest tasumisele kuuluvate maksetega. Tasaarvestamise korral ei rakendata punktis 11.12 kirjeldatud tasumise kohustust. 11.13. Tööde vastuvõtmine tellija poolt ei vabasta ega vähenda täitja vastutust lepingu rikkumise eest. 12. LEPINGU KEHTIVUS 12.1. Leping jõustub selle allkirjastamisest ja kehtib 48 kuud või kuni lepingu mahu täitumiseni. 12.2. Tellija võib lepingu igal ajal ühepoolselt üles öelda, teatades täitjale 60 päeva ette. Lepingu lõppemisel käesolevas punktis sätestatud alusel vabanevad pooled lõppemisest alates kõikidest lepingust tulenevatest kohustustest (v.a garantii kehtivusest tulenevad kohustused). 12.3. Täitja võib lepingu igal ajal ühepoolselt üles öelda, teatades tellijale vähemalt 90 päeva ette. Lepingu lõppemisel korral käesolevas punktis sätestatud alusel vabanevad  pooled lõppemisest alates kõikidest lepingust tulenevatest kohustustest (v.a garantii kehtivusest tulenevad kohustused). 12.4. Tellijal on õigus leping ühepoolselt etteteatamistähtaega järgimata üles öelda või lepingust taganeda, kui täitja on oluliselt lepingut rikkunud või juhul, kui täitja: 12.4.1. suhtes on algatatud pankrotimenetlus; 12.4.2. pankrot on välja kuulutatud; 12.4.3. täitja varad arestitakse; 12.4.4. täitja finantsseisund halveneb tellija põhjendatud hinnangul oluliselt ja see muudab lepingu nõuetekohase täitmise vähetõenäoliseks. 12.5. Lepingu oluliseks rikkumiseks täitja poolt loetakse muuhulgas: 12.5.1. valeandmete või valeinfo esitamine; 12.5.2. täitjal puuduvad lepingu täitmiseks vajalikud õigused (sealhulgas load, litsentsid, intellektuaalse omandi õigused); 12.5.3. alapunktis 8 kirjeldatud intellektuaalse omandi õiguste ja nende kasutamise tingimuste rikkumine; 12.5.4. korduv (vähemalt kahel korral) meeskonnaliikme asendamine isikuga, kes ei vasta kokku lepitud nõuetele või meeskonnaliikme asendamine ilma tellija eelneva vähemalt kirjalikku taasesitamist võimaldavas vormis antud nõusolekuta; 12.5.5. konfidentsiaalsuskohustuse rikkumine; 12.5.6. korduv (vähemalt kahel korral) lepingu järgsetele tingimustele vastava kohustuse täitmata jätmine, sh lepingu järgsete tööde mittekohane teostamine ja kohustuste täitmata jätmine garantiiperioodil; 12.5.7. lepingujärgsete kohustuste üleandmine kolmandale isikule, saamata selleks eelnevalt tellija poolset kirjalikku taasesitamist võimaldavat nõusolekut. 12.6. Poolte poolt allkirjastatud lepingu muudatused on lepingu lahutamatuks osaks. 12.7. Kumbki pool võib lepingu igal ajal ette teatamata üles öelda või lepingust taganeda, kui teine pool rikub korduvalt (vähemalt kahel korral) lepingut ning ei ole lepingu rikkumist kõrvaldanud 21 päeva jooksul arvates talle lepingu rikkumisest teatamisest kirjalikku taasesitamist võimaldavas vormis. 12.8. Kui pool ütleb lepingu üles punktis 12.7 toodud alusel, ei ole teisel poolel õigust nõuda sellega seoses talle tekkinud kahju (sh hulgas saamata jäänud tulu) hüvitamist või lepingujärgse tasu maksmist ning pooled vabanevad lepingulistest kohustustest alates lepingu lõppemisest (v.a garantiilised kohustused). 12.9. Täitjal ei ole õigust nõuda tellijalt mingit hüvitise maksmist ega saamata jäänud tulu selle tõttu, et tellija lõpetas lepingu enne selle kogumahu täitumist. 13. MUUD TINGIMUSED 13.1. Leping ja selle lisad sisaldavad poolte täielikku kokkulepet. Lepingu tingimuste muutmine või täiendamine on võimalik vaid kirjalikku taasesitamist võimaldavas vormis, mis jõustub, kui mõlema poole allkirjaõiguslikud isikud on selle allkirjastanud. 13.2. Lepingu mingi sätte muutmine või tühistamine poolte kokkuleppe tulemusel või kohtuotsusega ei too kaasa ülejäänud lepingu punktide muutumist või kehtetust. 13.3. Pooltel ei ole õigust oma lepingust tulenevaid õigusi ja/või kohustusi üle anda kolmandatele isikutele, kui selleks puudub teise poole eelnev kirjalik nõusolek. 13.4. Lepinguga reguleerimata küsimustes lähtutakse Eesti Vabariigis kehtivast seadusandlusest. 13.5. Kõik lepingust tulenevad erimeelsused püütakse lahendada läbirääkimiste teel. Juhul, kui läbirääkimised ei anna tulemusi, lahendatakse erimeelsused Harju Maakohtus. Lepingule kohaldatakse Eesti õigust.  13.6. Täitjal puudub volitus tegeleda lepingu raames avalike suhetega ja anda teateid pressile, elektroonsele meediale, üldsusele või teistele auditooriumidele, välja arvatud tellija eelneval kirjalikku taasesitamist võimaldaval nõusolekul. 14. LISAD Lepingu sõlmimisega samaaegselt allkirjastavad pooled järgmised lepingu lisad: 14.1.1. Lisa 1 – Tehniline kirjeldus ja selle lisad; 14.1.2. Lisa 2 – Isikuandmete töötlemise leping; 14.1.3. Lisa 3 – Kodukord; 14.1.4. Lisa 4 – Nõuded pakkuja meeskonnale; 15. POOLTE ALLKIRJAD Tellija: Täitja: /allkirjastatud digitaalselt/ /allkirjastatud digitaalselt/  Sotsiaalteenuste ja -toetuste andmeregistri hooldus- ja väiketööde tehniline kirjeldus Lisa 1 Hankelepingu juurde 1. Lepingu eesmärk Leping sõlmitakse Sotsiaalteenuste ja –toetuste andmeregistri „STAR“ hooldus- ja väiketööde osutamiseks, lepingu alusel teostatavate tööde eesmärgiks on tagada STARi pidev tõrgeteta toimimine, jooksvate probleemide lahendamine ja väiketööde tegemine. 2. Mõisted Mõiste/Lühend Kirjeldus STAR Sotsiaalteenuste ja -toetuste andmeregister Lepingus ja selle lisades kirjeldatud töö(d)/ tegevus(ed) ja üle antav(ad) tulem(id), mida saab Töö testida või mille valmimist saab tellija kinnitada. Hooldustööd on kirjeldatud käesoleva dokumendi punktis 4.1 ja väiketööd on kirjeldatud punktis 4.2. Töö üleandmist ja vastuvõtmist kinnitav dokument, Üleandmise ja vastuvõtmise akt mis allkirjastatakse nii täitja kui tellija poolt ja mis on (akt) täitjale aluseks arve esitamiseks ning tellijale arve tasumiseks. Hooldus- ja väiketööde ülesannete suunamiseks ja jälgimiseks, vigade ja probleemide haldamiseks ning Tööde halduskeskkond tööaja arvestuseks kasutatakse tellija poolt nimetatud töövahend (nt Jira). Lepingu täitmisega seotud dokumentatsiooni Dokumentatsioonihalduskeskkond haldamiseks ja jagamiseks kasutatav tellija poolt nimetatud keskkond (nt Confluence). Täitjale raporteeritud hooldustöö või poolte leitud Probleem vead, mis on fikseeritud tellija poolt nimetatud tööde halduskeskkonnas. Ajavahemik, mis algab probleemi tööde halduskeskkonnas esitamisest täitjale ning lõpeb lahendamise alustamise, lahendamiseks Reageerimisaeg edasisuunamise või tagasilükkamisega. Maksimaalne lubatud aeg probleemi lahendamiseks, mis ei eelda arendustööde teostamist. Lahendamise Lahendamisaeg aeg algab tööhalduskeskkonnas probleemi täitjale suunamise hetkest. Gitlab Rakenduse lähtekoodi hoidla. 3. Üldised nõuded 3.1. Hooldus- ja väiketööd peavad olema täielikult tagatud kogu lepingu perioodil. 3.2. Lepingu alusel kuuluvad kuutasu alusel tasustamisele esimesed 50 töötundi kalendrikuus, kui tellimuste maht ületab kuutasuga hõlmatud töötundide mahu, kuuluvad tasustamisele ainult need töötunnid, mille eest on tehtud reaalseid tegevusi. Töötundide mahud võivad perioodide lõikes erineda. Täitja peab olema valmis teostama tähtaegselt hooldus- ja väiketööd järgnevates STAR keskkondades: 3.2.1. STAR Tootmiskeskkond töökeskkonnana. Turvaklass K2T2S2. 3.2.2. STAR toodangu eelne keskkond töökeskkonnana (prelive). Turvaklass K2T2S2. 3.2.3. STAR Test- ja koolituskeskkond funktsionaalsete testide ja koolituste läbiviimiseks. Turvaklass K1T0S1. 3.2.4. STAR Statistikabaas. Turvaklass K1T2S2. 3.3. Lepingu alusel esitatud tellimused (sh eeldatavad lahendusajad, eeldatav tähtaeg) ja tehtud tööd (sh maht tundides) fikseeritakse tellija poolt kasutatavas tööde halduskeskkonnas. 3.4. Tööde teostamisega seonduv muu info dokumenteeritakse tööde halduskeskkonnas (sh tarneteatised, juhendid, spetsifikatsioonid, lähtekood, testiraportid, tuvastatud vead/probleemid ja nende lahendused). Kriitilise tööga seoses teavitab tellija kontaktisik lisaks tööde halduskeskkonnas kande tegemisele täitja kontaktisikut tööülesande lisandumisest ka telefoni/skype teel. 3.5. Probleemi lahendamise ajal ja pärast probleemi lahendamist kirjeldab täitja tööde halduskeskkonnas kõik tegevused, mida ta probleemi lahendamiseks teostas. Samuti lisab ta tööde halduskeskkonnas tööülesande juurde teostatud tundide arvu, kui töö on täitja poolt teostatud. Teostatud tööna mõistavad pooled seda, kui probleem on märgitud staatusesse Closed. 3.6. Täitja peab esimesel võimalusel tellijat teavitama töö teostamisel tekkivatest viivitustest töö tähtaegsel teostamisel. 3.7. Juhul, kui tellijal on pretensioone või vastuväiteid teostatud tööle, taasavab (probleem muudetakse staatusesse Reopened) tellija teostatud töö ja suunab töö uuesti täitjale täitmiseks. Täitja peab tegema töös parandused poolte poolt kokkulepitud aja jooksul, mis tuleneb tööde halduskeskkonnast määratud prioriteedist. 3.8. Täitjal tuleb puudused kõrvaldada tellija poolt määratud tähtaja jooksul. Täitja esitab tellijale üks kord kuus tööde üleandmise-vastuvõtmise akti, milles tuuakse eraldi välja kalendrikuu jooksul teostatud hooldus- ja väiketööd. Tööde akt sisaldab: töö numbrit, teostatud töö mahtu tundides, hooldus- või väiketöö lühikirjeldust ja prioriteeti. 3.9. Hooldusjuhtumiks ei loeta garantiikorras vigade parandamist. 3.10. Täitja peab olema valmis koostööks STAR majutusteenuse lepingupartneriga, kelleks täna on Telia Eesti AS. 3.11. Töö kvaliteetne realiseerimine võib eeldada funktsionaalseid muudatusi, mis peavad põhinema täna kasutusel oleva infosüsteemi äriloogikal, kuid mis lepitakse detailselt kokku töö teostamise käigus. 3.12. Hooldustööde lahendusaegade ja tööde prioriteedi määramisel lähtub tellija punktis 5.1 toodud tabelist, väiketööde teostamise aeg määratakse kokkuleppel täitjaga tööde halduskeskkonnas tellimuse esitamisel. 4. Hooldus- ja väiketööd (edaspidi ka töö) sisaldab muuhulgas: 4.1. Tellitavad hooldustööd: Töö kirjeldus Tegevused Tulemus Rakenduse ja selle liideste  Logide analüüs  Muudatusettepanek tööprotsessides ilmnenud  Rakenduse  Veapilet vigade, probleemide monitooringu  Tagasiside kliendile, nt tuvastamine, analüüsimine ja jõudluse näitajate rakendus käitub lahenduste leidmine. analüüs vastavalt analüüsile või  Andmebaasi konsultatsioon andmete analüüs funktsionaalsuse korrektseks kasutamiseks Vigaste andmete või  Logide analüüs  Muudatusettepanek andmevahetusega seotud  Andmebaasi  Veapilet tõrgete tuvastamine andmete analüüs  Tagasiside kliendile nt andmebaasis. Tõrgete  Nende tegevustega rakendus käitub analüüsimine, seotud vastavalt analüüsile või muudatusettepanekute arendustööd konsultatsioon tegemine ja lahendamine, funktsionaalsuse vajadusel andmestiku korrektseks korrigeerimine andmebaasis. kasutamiseks  Andmeparandusskript Muud rakenduse ja selle  Majutajalt ja teistelt  Muudatusettepanek liidestega seotud tööd, mis on koostööpartneritelt  Tagasiside tellijale vajalikud rakenduse ja selle tulnud liideste käideldavuse tähelepanekute tagamiseks. analüüs. Tellijat esindavate töötajate  STAR  Muudatusettepanek konsulteerimine rakenduse funktsionaalsuse  Tagasiside tellijale administreerimise ja analüüs  Andmebaasi päring andmebaasi päringute osas.  Andmemudeli analüüs  Nende tegevustega seotud arendustööd 4.2. Tellitavad väiketööd: Töö kirjeldus Tegevused Tulemus Väiketöö on väiksemahuline  Täiendav töö, mis  Muudatusettepanek arendustöö, mis on esitatud võib olla lisaks  Uue töö pilet tellimusena tööde arendustööle ka  Tarne halduskeskkonnas ja mille maht muu rakenduse ja  Täiendatud tarkvara ei ületa 40 töötundi. selle liidestusega seotud töö, mis on vajalik rakenduse ja selle liideste käideldavuse tagamiseks. 4.3. Hooldus- ja väiketööde käigus loodud lähtekood peab olema kaetud 80% ulatuses ühiktestidega ja 50% ulatuses integratsiooni/süsteemi/”end-to-end” automatiseeritud testidega. Testidega kaetakse serveripoolne ja kasutajaliidese kood. Kaetavuse kontrolliks ja raporteerimiseks seatakse tellija koodihoidla keskkonnas (Gitlab) üles continuous-integrationi töövoog, mis seadistatakse koostoimima SonarQube koodi ja testide kaetavuse analüsaatoriga. 4.4. Hooldus- ja väiketööde tulemite üleandmise eelselt viib täitja läbi süsteemitestimise (System Test). 4.4.1. Süsteemitestimise tulemusena peab lähtekood olema vigadeta, st kõlbulik toodangukeskkonda paigaldamiseks. 4.5. Hooldus- ja väiketööde tulemite üleandmine (lähtekoodi tarne) toimub pideva integreerimise (Continuous Integration) teel või kokkulepitud sagedusega (nt iga hooldus- või väiketöö etapi järel). 4.6. Täitja tagab tulemite üleandmise järel vajaliku tarneinfo olemasolu, et tellijal oleks võimalik korraldada paigaldusi keskkondadesse, kus tellija viib läbi vastuvõtutestimise (Acceptance Test, User Acceptance Test). 4.7. Tööde hulka ei kuulu vigade kõrvaldamine tarkvaras, kui tegemist on garantiiliste vigadega. Garantiilised tarkvaravead kõrvaldatakse garantii korras vastavalt lepingus sätestatud tingimustele. 5. Tööde halduskeskkonnas täitmiseks suunatud probleemide reageerimis- ja lahendamisajad 5.1. Hooldustöödes ilmnevates vigades eristatakse järgnevaid kriitilisuse astmeid: Probleemi Probleemi kirjeldus Probleemi Probleemi prioriteet reageerimisaeg lahendamisaeg tööpäeviti kell 08:30- tööpäeviti kell 08:30- 17:00 17:00 Blokeeriv Tarkvaral põhinev teenus Kiireim võimalik aeg, Kiireim võimalik aeg, viga või süsteem ei toimi, ei ole kuid täitja reageerib mitte kuid blokeeriv viga peab (blocker) kasutatav või hiljem kui 2 tunni jooksul saama lahendatud mitte teenus/süsteem on alates vea kohta teate hiljem kui 8 tunni jooksul, seiskunud. Mõjutatud on saamisest, kui pooled ei alates vea kohta teate kõik või enamus tarkvara lepi asjaolude tõttu saamisest, kui pooled ei kasutajatest, esineb tõsine kokku teisiti. lepi asjaolude tõttu finantsmõju. kokku teisiti. Kriitiline Tarkvara või teenuse Täitja reageerib hiljemalt Kriitiline viga peab viga andmed rikutud, esineb 24 tunni jooksul, alates saama lahendatud mitte (critical) kasutajasessioonide vea kohta teate hiljem kui 3 tööpäeva ebanormaalne katkemine, saamisest ja annab oma jooksul, alates vea kohta probleem mõjutab esialgse hinnangu teate saamisest, kui süsteemi käideldavust ja kriitilise vea võimalike pooled ei lepi asjaolude andmete terviklikkust. põhjuste kohta ning tõttu kokku teisiti. juhtnöörid, kuidas veaga tarkvara või teenust edasi kasutada, kui pooled ei lepi kokku teisiti. Häiriv viga Tarkvara saab kasutada Täitja reageerib hiljemalt Häiriv viga peab saama (major) ettenähtud tööks, kuid 3 tööpäeva jooksul, lahendatud mitte hiljem veaolukorra vältimine või alates vea kohta teate kui 10 tööpäeva jooksul, ületamine nõuab töötajatelt saamisest ja annab oma alates vea kohta teate lisaks tööülesannete esialgse hinnangu saamisest, kui pooled ei täitmisele täiendavaid häiriva vea võimalike lepi asjaolude tõttu toiminguid või pingutust. põhjuste kohta ning kokku teisiti. juhtnöörid, kuidas veaga tarkvara või teenust edasi kasutada, kui pooled ei lepi kokku teisiti.  Pisiviga Ilming või kõrvalefekt Täitja reageerib hiljemalt Pisiviga peab saama (minor) tarkvara töös, mis ei takista 10 tööpäeva jooksul, lahendatud mitte hiljem ettenähtud töö tegemist ja alates vea kohta teate kui 20 tööpäeva jooksul, puudutab tarkvara üksikuid saamisest. alates vea kohta teate kasutajaid, kuid ei ole saamisest, kui pooled ei täielikult eiratav. lepi asjaolude tõttu kokku teisiti. 5.2. Tööaeg - Kokkulepitud ajavahemik, millal hooldustööde teostaja peab garanteeritult kättesaadav olema ning mille jooksul pakutakse hooldustööde teostamiseks kasutajatuge (kasutusnõustamine, planeerimata katkestuste lahendamine jms). Tööaeg on täitja poolt probleemile reageerimise ja selle lahendamise aeg, mis on tööpäevadel (v.a riiklikud pühad) kell 08:30 kuni kell 17:00. 5.3. Töövälisel ajal kriitiliste vea lahendamise valmisoleku ajaplaan tuleb tellija ja täitja esindajate poolt eelnevalt kokku leppida iga kord vähemalt 3 tööpäeva ette, arvates sündmusest, mis võib tekitada kriitilise vea. Sellistel juhtudel tellija teavitab täitjat probleemidest telefoni teel. Kui kriitiline viga tekib ootamatult, siis tuleb lähtuda eeltoodud tabelis (punkt 5.1) esitatud reageerimise ja lahendamise aegadest. Hooldustöö väljaspool tööaega peab olema kajastatud tööaja aruandes. 5.4. Töö prioriteedi (kriitilisuse astme) määrab alati tellija. 5.5. Kui hooldustööd ei ole võimalik lahendada punktis 5.1. kirjeldatud aja jooksul, esitab täitja tellijale põhjendused ja lahendusettepanekud ning toob välja, millal oleks võimalik probleem kõige varem kõrvaldada. 6. Lisad Lisa 1.1 - Mittefunktsionaalsed nõuded arendustele Lisa 1.2 - Nõuded infosüsteemi dokumentatsioonile  Hankelepingu lisa 2 ISIKUANDMETE TÖÖTLEMISE LEPING Tervise ja Heaolu Infosüsteemide Keskus (edaspidi Volitaja), registrikood 700097700, asukohaga Uus-Tatari 25, Tallinn, keda esindab põhimääruse ja direktori käskkirja alusel Lauri Treima (infosüsteemihalduse osakonna juhataja direktori ülesannetes) ja Dolm IT OÜ (edaspidi Volitatud Töötleja), registrikood 12809505, aadress Lõõtsa 12, Tallinn, keda esindab juhatuse liige Mait Piir on sõlminud käesoleva isikuandmete töötlemise lepingu hankelepingu nr 3-9/1893-1 lisana nr 2 (edaspidi Leping) 1. Lepingu ese ja eesmärk 1.1. Lepingu esemeks on Volitaja ja Volitatud Töötleja (edaspidi koos nimetatud kui Pooled) vaheliste tingimuste sätestamine seoses isikuandmete töötlemisega Sotsiaalteenuste ja – toetuste andmeregistris (STAR). 1.2. Volitatud Töötleja töötleb isikuandmeid hankelepingu nr 3-9/1893-1 täitmiseks, milleks on Volitatud Töötlejal õigus saada juurdepääs STAR toodangukeskkonnas (live) sisalduvatele isikuandmetele, sealhulgas eriliigilistele isikuandmetele: 1.2.1. isiku üldandmed, sh isikukood, sugu, sünniaeg, perekonna- ja eesnimi, isiku surma või surnuks tunnistamise andmed, elamisloa ja -õiguse ning kodakondsuse andmed, andmed eestkoste või hooldusõiguste kohta ning andmed Eesti Vabariiki saabumise ja sealt lahkumise kohta; 1.2.2. andmed isikule riikliku toetuse, pensioni, hüvitise, elatisabi ning teenuse määramise, maksmise, peatamise või lõpetamise ja kinnipidamise kohta; 1.2.3. isiku maksualased andmed. 1.3. Punktis 1.2. nimetatud hankelepingu täitmiseks on Volitatud Töötleja isikuandmete töötlemisega seotud tegevused piiratud hooldustööde teostamise käigus tootmiskeskkonna vigade leidmise ja parandamisega STAR-is, ligipääs isikuandmetele on vajaduspõhine ja lähtub konkreetsest tööülesandest. 2. Volitatud Töötleja kohustused 2.1. Volitatud Töötleja on kohustatud: 2.1.1. tagama Lepingueelsete läbirääkimiste ja Lepingu täitmise käigus Volitajalt ükskõik mis vormis saadud isikuandmete ja muu teabe (sh andmed, tehingudokumentatsiooni ja know-how) konfidentsiaalsuse ning ei edasta ega võimalda sellele teabele juurdepääsu kolmandale isikule ilma Volitaja sellekohase selgesõnalise kirjaliku nõusolekuta; 2.1.2. tagama, et Lepingu täitmise käigus teatavaks saanud isikuandmeid ei edastata väljapoole Euroopa Liidu liikmesriikide ja Euroopa Majandusühendusse kuuluvate riikide territooriumi ilma Volitaja sellekohase selgesõnalise kirjaliku nõusolekuta; 2.1.3. kasutama ja töötlema Lepingu täitmise käigus teatavaks saanud isikuandmeid üksnes Lepingu täitmiseks ja Volitaja dokumenteeritud juhiste alusel, välja arvatud juhul, kui Volitatud Töötleja on kohustatud teavet töötlema Volitatud Töötleja suhtes kohalduva õiguse alusel. Viimati nimetatud juhul teavitab Volitatud Töötleja Volitajat vastava kohustuse olemasolust enne teabe töötlemist; 2.1.4. võimaldama juurdepääsu Lepingu täitmise käigus teatavaks saanud isikuandmetele ainult nendele isikutele, kellel on selleks oma tööülesannete täitmiseks vajadus ning tagama, et need isikud on teadlikud ning järgivad isikuandmete töötlemis alaseid nõudeid ja õigusakte, nad on saanud asjakohase koolituse eelmainitud nõuete kohta, on võtnud endale konfidentsiaalsuskohustuse või neile kehtib asjakohane seadusest tulenev konfidentsiaalsuskohustus; 2.1.5. täitma kõiki kehtivaid isikuandmete töötlemisalaseid nõudeid, andmete turvalisust puudutavaid ning isikuandmete kaitse alaseid Euroopa Liidu ja Eesti Vabariigi õigusakte ja muid eeskirju; 2.1.6. rakendama alltoodud organisatsioonilisi, füüsilisi ja infotehnoloogilisi turvameetmeid isikuandmete kaitseks juhusliku või tahtliku volitamata muutmise; juhusliku hävimise ja tahtliku hävitamise eest ning õigustatud isikule andmete kättesaadavuse takistamise eest, volitamata töötlemise, sh avalikustamise eest: 2.1.6.1. vältima kõrvaliste isikute ligipääsu isikuandmete töötlemiseks kasutatavatele seadmetele; 2.1.6.2. ära hoidma andmete omavolilist lugemist, kopeerimist ja muutmist andmetöötlussüsteemis, samuti andmekandjate omavolilist teisaldamist; 2.1.6.3. ära hoidma isikuandmete omavolilist salvestamist, muutmist ja kustutamist ning tagama, et tagantjärele oleks võimalik kindlaks teha, millal, kelle poolt ja milliseid isikuandmeid salvestati, muudeti või kustutati või millal, kelle poolt ja millistele isikuandmetele andmetöötlussüsteemis juurdepääs saadi; 2.1.6.4. tagama, et igal andmetöötlussüsteemi kasutajal oleks juurdepääs ainult temale töötlemiseks lubatud isikuandmetele ja temale lubatud andmetöötluseks; 2.1.6.5. tagama andmete olemasolu isikuandmete edastamise kohta: millal, kellele ja millised isikuandmed edastati, samuti selliste andmete muutusteta säilimise; 2.1.6.6. tagama, et isikuandmete edastamisel andmesidevahenditega ja andmekandjate transportimisel ei toimuks isikuandmete omavolilist lugemist, kopeerimist, muutmist või kustutamist; 2.1.6.7. pidama arvestust isikuandmete töötlemisel kasutatavate tema kontrolli all olevate seadmete ja tarkvara üle, dokumenteerides järgmised andmed. 2.1.7. teavitama Volitajat toimunud või põhjendatult kahtlustatavast Lepingu punktis 2.1.4. sätestatud konfidentsiaalsuskohustuse rikkumisest; 2.1.8. teavitama Volitajat Lepingu punktides 2.1.6.1.-2.1.6.7. turvameetmete rikkumisest, mis põhjustab, on põhjustanud või võib põhjustada edastatavate, salvestatud või muul viisil töödeldavate isikuandmete juhusliku või ebaseadusliku hävitamise, kaotsimineku, muutmise või loata avalikustamise või neile juurdepääsu, kirjalikult viivitamata, kuid mitte hiljem kui kakskümmend neli tundi pärast sellest teada saamist. Juhul, kui rikkumisest teadasaamine langeb nädalavahetusele või riiklikule pühale, kohustub Volitatud Töötleja Volitajat kirjalikult teavitama viivitamatult, kuid mitte hiljem kui nelikümmend kaheksa tundi pärast rikkumisest teada saamist. Kirjeldatud teates tuleb vähemalt: 2.1.8.1. kirjeldada isikuandmetega seotud rikkumise laadi, sealhulgas tuues välja puudutatud andmesubjektide kategooriad ja ligikaudne arv ning isikuandmete kirjete liigid ja ligikaudne arv; 2.1.8.2. teatada andmekaitsespetsialisti või mõne teise täiendavat teavet andva kontaktisiku nimi ja kontaktandmed; 2.1.8.3. soovitada meetmeid isikuandmetega seotud rikkumise võimalike negatiivsete mõjude leevendamiseks; 2.1.8.4. kirjeldada isikuandmetega seotud rikkumise võimalikke tagajärgi; 2.1.8.5. kirjeldada Volitatud Töötleja poolt pakutud või võetud meetmeid isikuandmetega seotud rikkumisega tegelemiseks ja esitada muud teavet, mis on mõistlikult nõutav, et Volitaja saaks täita kohaldatavaid andmekaitse õigusakte, sealhulgas riigiasutustega seotud teavitamise ja avaldamise kohustusi, näiteks teavet, mis on nõutav andmesubjekti tuvastamiseks. 2.1.9. lõpetama punktides 2.1.7. või 2.1.8. nimetatud rikkumise ning kohaldama meetmeid isikuandmetega seotud rikkumise lahendamiseks, sealhulgas vajaduse korral rikkumise võimaliku kahjuliku mõju kõrvaldamiseks ja leevendamiseks; 2.1.10. kustutama Lepingu lõppemisel kõik Lepingu täitmise käigus teatavaks saanud isikuandmed ja nimetatute koopiad 30 kalendripäeva jooksul, v.a juhul, kui õigusaktidest tuleneb teisiti; 2.1.11. tegema Volitajale kättesaadavaks kogu teabe, mida Volitaja peab vajalikuks Lepingus sätestatud kohustuste täitmise tõendamiseks; 2.1.12. võimaldama Volitajal või Volitaja poolt volitatud audiitoril teha auditeid ja kontrolle ning panustama nendesse. 3. Lõppsätted 3.1. Volitatud Töötleja ei või oma lepingujärgseid kohustusi anda üle kolmandale isikule ega kaasata oma Lepingujärgsete kohustuste täitmiseks kolmandat isikut. 3.2. Käesoleva Lepingu punktis 2.1.4. nimetatud kohustus jääb kehtima ka pärast käesoleva Lepingu lõppemist. 3.3. Käesoleva Lepingu punktis 2.1.4. sätestatud konfidentsiaalsuse nõue ei laiene teabe avaldamisele Volitatud Töötleja audiitorile ja advokaadile. 3.4. Leping on kehtiv Poolte poolt allkirjastamisest kuni hankelepingu nr 3-9/1893-1 nõuetekohase täitmiseni. 4. Poolte allkirjad Volitaja Volitatud Töötleja /Allkirjastatud digitaalselt/ /Allkirjastatud digitaalselt/  Sotsiaalteenuste ja -toetuste andmeregistri hooldus- ja väiketööde teostamise kodukord Lisa 3 Hankelepingu juurde 1. Eesmärk 1.1. Kodukorra eesmärk on täpsustada lepingu alusel (edaspidi nimetatud ka projekt) tööde tellimise korda ja põhimõtteid, täitja ja tellija omavahelist suhtlust ning tagasiside andmise korda. 1.2. Tellija võib teha kodukorda muudatusi, teavitades täitjat kodukorra muutmisest. 2. Mõisted 2.1. Töö – Lepingus fikseeritud töö(d)/tegevus(ed) ja üle antav(ad) tulem(id), mida saab testida või mille valmimist saab tellija kinnitada. 2.2. Üleandmise ja vastuvõtmise akt (akt) - töö üleandmist ja vastuvõtmist kinnitav dokument, mis allkirjastatakse nii täitja kui tellija poolt ja mis on täitjale aluseks arve esitamiseks ning tellijale arve tasumiseks. 2.3. Teenuse kasutaja – kohaliku omavalitsuse (KOV) töötaja, kes hakkab tööna teostatud teenuseid kasutama, sh testib üle antud töid sisuliselt. 2.4. MVP (Minimum Viable Product) – minimaalne töötav toode/teenus. Tegemist on toote/teenuse (või selle alamosa) esmaversiooniga, mida klient saab kasutada ning mis lahendab esmased vajadused. MVP etapis kasutatakse tehniliselt lihtsaid lahendusi ning jäetakse kõrvale sekundaarse prioriteediga ärinõuded. 3. Töökorraldus tööde teostamisel 3.1. Täitja peab olema võimeline väiketöid teostama MVP (punkt 2.4) põhimõtetest lähtudes, pidades silmas, et: 3.1.1. Tellimuses on esitatud loodava funktsionaalsuse loetelu (skoop) ärinõuetena, ilma konkreetsete lahenduskäikudeta. Täitja ülesanne on tellija poolt seatud ajalistes ja eelarvelistes piirides leida koostöös tellijaga igale ärinõudele antud tingimustes parim võimalik (mõistlik) lahendus. Parima võimaliku lahenduse all peab tellija siinkohal silmas hooldus- ja väiketööde lõppmaksumuse proportsionaalsust lahendatava probleemi keerukusega. 3.2. Täitja tagab tööde teostamise ajal igakülgse läbipaistvuse (sh otsekontakt ja vajadusel igapäevane suhtlus kõikide täitja meeskonna liikmetega): 3.2.1. Hooldus- ja väiketööd peavad tarnimiseks valmima tööde halduskeskkonna alusel vastavalt tehnilises kirjelduses toodud tööde teostamise ajale või tellija poolt probleemi täitmiseks suunamisel määratud ajale. 3.3. Lepingu täitmisest tulenev suhtlus toimub eesti keeles, täitja peab tagama võimekuse tööde teostajatega eesti keeles infot vahetada (vajadusel korraldab tõlke täitja). 3.4. Tellija esindaja teeb kõik selleks, et vahetult enne ja pärast kolmandate osapoolte (arenduspartnerite) tööde tarnet oleks täitja informeeritud tööde sisust ja vajadusel konsulteerib igakülgselt täitjat seoses arendustööde tarnega. 4. Tööde teostamise meeskond ja vastutused 4.1. Tööde teostamiseks moodustatakse meeskond. 4.2. Tellija poolt osalevad tööde tellimisel ja teostamisel järgmisi rolle täitvad isikud: 4.2.1. Teenusehaldur - kooskõlastab paigaldused toodangukeskkonda ja teavitab testimise käigus leitud vigadest. Juhib tellija poolt tööde tellimuste ja ajaplaani kokkuleppimist ning tööde teostamist. 4.2.2. Tellija teenusehalduril on õigus kontrollida lepingu täitmise käiku ja kohustus anda täitjale töödega seotud informatsiooni ja juhiseid vastava nõude esitamisel. 4.2.2. Tooteomanik (Product Owner) – esindab teenuse kasutajat igapäevatöös, sh korraldab ja viib läbi ärinõuete defineerimise ja prioriseerimise, juhib projekti skoopi (ulatust). 4.2.3. Süsteemiarhitekt – juhib tervikliku süsteemiarhitektuuri planeerimist, vastavuse kontrollimist esitatud nõuetele ja projektis defineeritud ärivajadustele. Korraldab tehniliste otsuste vastuvõtmist ja jõustamist seotud osapoolte (sh erinevate arenduspartnerite) vahel. 4.2.4. Kvaliteedijuht – kehtestab kvaliteedi tagamise ja kvaliteedikontrolli põhimõtted ning kontrollib nende täitmist (tööde teostamise käigus ja selle järgselt). Juhib vastuvõtutestimise läbiviimist. 4.3. Sõltuvalt tellitavate tööde iseloomust võib tellija enda poolt tööde tellimisel ja teostamisel osalevate rollide nimekirja muuta (sh isikuid lisada). 4.4. Täitja projektijuht juhib täitja poolt tööde tulemi kokkuleppimist, vastutab tööde teostamise ajaplaani koostamise eest ning tagab kokkulepitud tööde tulemi valmimise ja ajaplaani täitmise. 4.5. Pooled peavad tagama, et tellija teenusehalduril ja täitja projektijuhil on vajalik ajaressurss ning kõik vajalikud õigused ja pädevus vastava poole nimel tegutseda. 4.6. Projektimeeskonna liikmed (teostajad) vastutavad, et nende poolt teostatud tööd on teostatud ja dokumenteeritud vastavalt kokkulepitud töö eesmärgile ning tellija suunistele ja nõuetele ning valdkonnas kehtivatele parimale praktikale. 4.7. Vajadusel täpsustavad pooled lepingu sõlmimisel projektimeeskonna liikmete rollid ja nende ülesanded. 5. Aruandlus 5.1. Töötunnipõhiselt tasustatavate hooldus- ja väiketööde puhul on täitja meeskond kohustatud esitama tööaja aruandeid vastavalt järgmistele tingimustele: 5.1.1. Tellija nimetab tööaja aruannete esitamiseks kasutatava töövahendi (nt Jira) ja tagab täitjale selle kättesaadavuse. 5.1.2. Tööaja aruande esitab täitja iga meeskonnaliige isiklikult (iga meeskonnaliige täidab aruandevormid ise). 5.1.3. Tööaja aruannete esitamise sagedus on üks kord nädalas (reedese tööpäeva lõpuks, riigipühade puhul sellele eelneva tööpäeva lõpuks), kui tellija ja täitja ei lepi kokku teisiti. 5.1.4. Nõuded ajaaruande detailsusele (täidetud tööülesannete kirjeldusele) kehtestab tellija teenusehaldur. 6. Vea parandamine hooldus- või väiketööna, juurutamise või garantiiperioodi käigus 6.1. Vigade menetlemise käigus registreeritakse kõik poolte leitud vead tellija poolt nimetatud keskkonnas (nt Jira). 6.2. Täitja analüüsib vea kirjeldust ja selgitab välja vea põhjuse. 6.3. Vigadele määratakse tellija poolt kriitilisuse aste ning neid asutakse parandama kriitilisuse järjekorras või muus tellija poolt teatavaks tehtud järjekorras. 6.4. Garantiiperioodil asub täitja viga parandama vastavalt lepingus sätestatud tingimustele. 7. Tasustamine 7.1. Tellija poolt kuuluvad tasustamisele üksnes reaalselt töö teostamiseks kulutatud efektiivsed töötunnid, mis loovad tellijale otsest väärtust. 7.1.1. Tellija ei tasusta (ei aktsepteeri ajaaruannetes) seadusest tulenevaid puhkepause (nt lõunapausid, paus silmade puhkamiseks jmt). 7.1.2. Tellija ei tasusta ajakulu, mis kulub täitja spetsialistidel oskusteabe täiendamiseks lepingus sätestatud tööde nõuetekohaseks teostamiseks. Nende hulka kuuluvad näiteks: 7.1.2.1. Uute tehnoloogiate tundmaõppimine (mille järele vajadus võib selguda töö teostamise käigus). 7.1.2.2. Uue metoodikate tundmaõppimine (mille järele vajadus võib selguda töö teostamise käigus). 7.1.3. Tellija ei tasusta punktist 7.1.2 lähtuvalt täitja meeskonnaliikmete täiendavat tööaega, mis kulub uue oskusteabe omandamise perioodil tööülesannete täitmiseks. 7.1.4. Tellija ei tasusta aega, mis kulub täitjal korduvate vigade lahendamiseks (näiteks samaliigiliste probleemide kordumine lähtekoodis vaatamata täitja varasemale tagasisidele koodiülevaatuste käigus). 7.1.5. Tellija eeldab, et täitja arvestab meeskonnaliikmete vahetumisel selle mõjuga tööviljakusele (produktiivsusele) ning kajastab seda vastavalt ajaaruannetes. 7.2. Tehtud tööpuhul kuulub akteerimisele töö, mis on edukalt läbinud tellija poolse vastuvõtutestimise (Acceptance Test, User Acceptance Test). 7.3. Tööaja aruandes kajastatud töötunnid arveldatakse sammuga 15 minutit, kui pooled ei ole kokku leppinud teisiti. 8. Lepingu täitmisega seotud infovahetus 8.1. Lepingu täitmisega seotud dokumentatsiooni haldamiseks ja jagamiseks kasutatakse tellija poolt nimetatud keskkonda (nt Confluence). Tellija tagab täitjale keskkonna kättesaadavuse. 8.1.1. Dokumentide hoidmise struktuur, selle täiendused ja muudatused lepitakse kokku poolte kontaktisikute vahel. 8.1.2. Dokumentide lisamise, muutmise ja kustutamise reeglid lepitakse kokku poolte kontaktisikute vahel, kes tagavad kokkulepitud reeglite järgimise oma meeskonnas. 8.2. Tööülesannete suunamiseks ja jälgimiseks, vigade ja probleemide haldamiseks ning tööaja arvestuseks kasutatakse tellija poolt nimetatud töövahendit (nt Jira). 8.3 Tööülesandega tegelema hakkamise eelduseks täitja poolt on vea registreerimine töövahendis ja lepingus toodud nimetatud tööde eest vastutava (tellija) isiku poolt antud korraldus töödega alustamiseks. 8.4. Lepingu täitmisega seotud muu (igapäevane) teabevahetus toimub e-kirja, telefoni, Skype teel või koosoleku vormis. Poolte kontaktisikud tagavad teabe edastamise ja saamise. 8.5. Teabevahetuse vormid ja reageerimisajad: 8.5.1. Koosolek – koosoleku kokkukutsumisel esitatakse päevakord ja eesmärk. Võimaluse korral lepitakse projekti alguses kokku korralised koosolekud. Korralisi koosolekuid võib poolte kokkuleppel tühistada (hiljemalt samal päeval 2-tunnise etteteatamise ajaga). Muude koosolekute kutsed tuleb esitada vähemalt 2 tööpäeva enne koosoleku toimumist. 8.5.1.1. Koosoleku toimumise järel koostatakse memo (vastutab koosoleku korraldaja), otsused protokollitakse ja saadetakse e-kirjaga koosolekul osalenutele teadmiseks/vajadusel kinnitamiseks. 8.5.2. E-kiri – kasutatakse igapäevase suhtluskanalina (v.a kui infot tuleb vastavalt kodukorrale edastada täitja projektikeskkondade kaudu). 8.5.2.1. Kui e-kirjale oodatakse vastust, tuleb pealkirja real või kirja alguses see üheselt määratleda. Vastust eeldavale e-kirjale tuleb vastata hiljemalt järgneva tööpäeva jooksul. Kui e- kirjale ei ole võimalik anda selle aja jooksul sisulist vastust, tuleb hiljemalt järgneva tööpäeva jooksul saata sisulise vastuse andmise aeg. 8.5.3. Skype ja muud sarnased sõnumivahetuskeskkonnad – kasutatakse kiireloomuliseks ja operatiivseks suhtluseks. Skype’i kõneteenuse või telefoni kaudu kokku lepitud otsused tuleb kinnituseks fikseerida e-kirjaga või arutada ja protokollida koosolekul. 8.5.3.1. Pooled säilitavad projekti e-kirjad, Skype'i ja/või muudes sõnumivahetuskeskkondades toimunud vestlused projekti ja garantiiperioodi kehtivuse ajal. 8.5.3.2. Poolte kontaktisikud lepivad kokku e-posti, Skype'i ja muude sarnaste sõnumivahetuskeskkondade gruppide loomise. 8.5.4 Telefon - kasutatakse operatiivse ja olulise informatsiooni edastamiseks, samuti kriisisituatsioonides. Telefonikõnele mitte vastates tuleb tagasi helistada esimesel võimalusel, aga mitte hiljem kui järgmise tööpäeva lõpus. Olulistel juhtudel (näiteks hooldus- või väiketööde juurutusfaasis) peavad mõlema poole kontaktisikud olema telefoni teel kättesaadavad ka pärast ametlikku tööpäeva lõppu. Valmisolek lepitakse eraldi kokku. 8.5.5. Stand-up kohtumine – Toimub tööde teostamise ajal vastavalt tellija ja täitja kokkuleppele ning täitja esindajate osalusel. Stand-up kohtumisi ei toimu, kui Täitjal ei ole Tellija poolt esitatud tellimusi töös. 9. Arendus-, test-, prelive- ja live keskkonnad 9.1. Arenduskeskkond asub täitja juures, kes tagab selle olemasolu ja toimimise. 9.2. Tellija testkeskkond koosneb vähendatud võimsusega komponentidest. Täitjal võib olla tellija testkeskkonnale lugemisõigusega ligipääs. 9.3. Tellija prelive keskkond koosneb live keskkonnale sarnastest komponentidest, sh andmebaasid, rakendusserverid ning väliste süsteemide liidesed. Täitjal puudub alaline ligipääs tellija prelive keskkonnale. 9.4. Live keskkonna konfiguratsioon lepitakse kokku arenduse käigus. Täitjal puudub ligipääs tellija live keskkonnale. 9.5. Pooled teevad mõistlikud pingutused tagamaks, et tellija testkeskkond sarnaneks live keskkonnale järgmises osas: 9.5.1. arvutivõrgu konfiguratsioon; 9.5.2. liidesed kolmandate süsteemidega; 9.5.3. andmemahud; 9.5.4. kui maksimaalne sarnasus ei ole majanduslikult põhjendatud või tulenevalt andmekaitse piirangutest võimalik, kohustub pool informeerima teist poolt test- ja live keskkondade disainitud erinevustest. Vajadusel lepivad pooled kokku alternatiivse võimaluse keskkondade erinevuse puudujäägi kompenseerimiseks. 9.6. Keskkondade ning nende ligipääsude haldamise ja tarnete paigalduse reeglid lepitakse kokku projekti alguses. 10. Nõuded lähtekoodile 10.1. Rakenduse lähtekoodi hoidmiseks kasutatakse https://gitlab.sotsiaalministeerium.ee. 10.2. Lähtekoodi haldamisel ja versioneerimisel tuleb lähtuda http://nvie.com/posts/a-successful- git-branching-model/ mudelist. 11. Nõuded dokumenteerimisele 11.1. Projekti dokumentatsioon peab olema terviklik ja terminoloogiliselt üheselt mõistetav. 11.2. Dokumentatsiooni kvaliteedi eest vastutavad poolte kontaktisikud. Tellija teenusehalduril on õigus nõuda täita poolt koostatud või parandatud dokumentatsiooni täiendamist või muul viisil muutmist, kui dokumentatsioon ei vasta nõuetele või on muul viisil puudulik. 11.3. Nõuded dokumenteerimisele on esitatud dokumendi "Mittefunktsionaalsed nõuded arendustele" alapunktis 8 ja dokumendis „Nõuded infosüsteemi dokumentatsioonile“. 12. Kriisisituatsioonide haldamine 12.1. Kriisisituatsiooniks loetakse olukorda, kus poolte esindajad ei suuda kokkuleppele jõuda või on muutunud võimatuks võtmeisikute osalemine tööde teostamisel või ilmnenud on muud asjaolud, mis võivad oluliselt mõjutada tööde edukat elluviimist ja/või satuvad olulisse ohtu kokkulepitud tähtajad ja/või funktsionaalsus. 12.2. Kriisi tekkimisel on pool kohustatud sellest teise poole esindajat viivitamatult kirjalikult teavitama. 12.3. Kriisist väljumiseks teevad mõlemad pooled kõik endast sõltuva kriisist väljatulekuks ja mõlemat poolt rahuldava lahenduse leidmiseks. Kriisi vältimise ja kriisist väljumise eest vastutavad poolte kontaktisikud.  Nõuded pakkuja meeskonnale 1. Täitja kinnitab, et suudab komplekteerida lepingu täitmiseks kuni viieliikmelise meeskonna, mis koosneb järgmistest võtmeisikutest: Arv Roll 1 projektijuht 1 analüütik 2 arendajat 1 testija 2. Tööde teostamiseks peab pakkuja meeskonnal olema võimekus teostada rakenduse hooldus- ja väiketöid vastavalt riigihanke alusdokumentides kirjeldatud tingimustele. 3. Täitja peab pakkumuse osana esitama lepingu täitmiseks komplekteeritud meeskonna isikuliselt. 4. Projektijuht ja analüütik võivad olla samas isikus ning arendaja ja testija võivad olla samas isikus, muudel juhtudel ei tohi meeskonnaliikmed erinevates rollides kattuda. 5. Kui pakkuja üks arendajatest ei suuda katta täielikult nõutud töövahendite, raamistike ja keskkondadega töötamise kogemusi (arendajale esitatud nõuded punktides 4.1- 4.4), võib esitatud nõuded katta mitme arendajaga (pakkumuse osana tuleb siiski esitada hankelepingu täitmiseks vähemalt kaks arendajat). Pakkuja kinnitab, et suudab tagada tööde teostamiseks järgmised meeskonnaliikmed, tuues välja andmed nõuetele vastavuse kohta: Projektijuht (nimi, isikukood): Daniel Leifer, 39208142762 Nõude Nõuded Kas Täpsustus selle kohta kus/millal/kuidas on kood vastab nõue täidetud. esitatud Projektidele viitamisel märkida projekti tellinud nõudele asutus, tellija kontaktisik ja projekti nimi, (JAH/ arvestades, et hankijal on õigus kontrollida EI) esitatud andmeid viidatud kontaktisiku vahendusel. Välja täitmine on kohustuslik. 1 Omab vähemalt 2-aastast Jah Ajaperiood: 2015 mai – Praeguseni töökogemust tarkvara Firma: Dolm IT OÜ arenduse projektijuhina. Positsioon: IT tehniline projektijuht 2 On juhtinud vähemalt ühte Jah Projekti nimetus: E-cargoWorld tarkvara arendusprojekti Ekspediteerimise CRM süsteemi arendus viimase kahe aasta jooksul, Tundide maht: +1500h mille projekti maht ületab 1500 tundi. Analüütik (nimi, isikukood): Hendrik Hoekstra, 37605050095 Nõude Nõuded Kas Täpsustus selle kohta kus/millal/kuidas on kood vastab nõue täidetud.  esitatud Projektidele viitamisel märkida projekti tellinud nõudele asutus, tellija kontaktisik ja projekti nimi, (JAH/ arvestades, et hankijal on õigus kontrollida EI) esitatud andmeid viidatud kontaktisiku vahendusel. Välja täitmine on kohustuslik. 1a* Omab kõrgharidust ja Jah Kool: Technical University Tewente (The Netherlands) Eriala: Äriinfotehnoloogia Kraad: Bakalaureusekraad Omab vähemalt 3-aastast Jah Ajaperiood: 2016 aprill – Praeguseni töökogemust tarkvara Firma: Dolm IT OÜ arenduse projektides Positsioon: IT tehniline analüütik analüütikuna või tarkvara projekteerijana. 1b* Omab vähemalt 5-aastast Jah Ajaperiood: 2007 oktoober – 2016 märts töökogemust tarkvara Firma: Juwelier.de GmbH arenduse projektides Positsioon: IT tehniline analüütik analüütikuna või tarkvara projekteerijana. 2 On osalenud vähemalt ühes Projekti nimetus: Juwelier.de laohalduse ERP IT projektis viimase kahe süsteemi arenduse ja hoolduse tööd aasta jooksul, mille Jah Tundide maht: +5000h arendusmaht on rohkem kui 1500 tundi. 3 Omab töökogemust: 3.1 Menetlussüsteemide Jah Projekti nimetus: E-cargoWorld arendamisel ja/või Ekspediteerimise CRM süsteemi arendus analüüsimisel Tundide maht: +1500h Positsioon: IT tehniline analüütik Tõendav seos: süsteemis on erinevad ekspediteerimise menetlusprotsessid, mille raames sai teostatud analüütilisi töid. 3.2 äriprotsesside optimeerimisel Jah Projekti nimetus: Juwelier.de laohalduse ERP süsteemi arenduse ja hoolduse tööd Tundide maht: +5000h Positsioon: IT tehniline analüütik Tõendav seos: süsteemis sai analüüsitud erinevaid olukordasid, kus oli vaja optimeerida äriprotesside käekäiku. 3.3 UML-iga (Unified Modeling Jah Projekti nimetus: E-cargoWorld Language)1 Ekspediteerimise CRM süsteemi arendus Tundide maht: +1500h Positsioon: IT tehniline analüütik Tõendav seos: analüüsi tööde käigus sai realiseeritud erinevaid UML diagramme. 3.4 Prototüüpide koostamisel Jah Projekti nimetus: E-cargoWorld Ekspediteerimise CRM süsteemi arendus Tundide maht: +1500h Positsioon: IT tehniline analüütik 1 Siin ja edaspidi lugeda kogu dokumendis koos märkega "või samaväärne" kui see on objektiivselt võimalik. Samaväärsuse tõendamise kohustus lasub pakkujal, kes sellele tugineda soovib.  Tõendav seos: analüüsi tööde käigus sai realiseeritud erinevaid prototüüpe (HTML prototüübid). Arendaja 1 (nimi, isikukood): Tõnis Bender, 39204281525 Nõude Nõuded Täpsustus selle kohta kus/millal/kuidas on nõue kood täidetud. Projektidele viitamisel märkida projekti tellinud asutus, tellija kontaktisik ja projekti nimi, arvestades, et hankijal on õigus kontrollida esitatud andmeid viidatud kontaktisiku vahendusel. Välja täitmine on kohustuslik. 1a* Omab kõrgharidust reaalainete1 Kool: Tallinna Tehnikaülikool valdkonnas ja Eriala: Informaatika Kraad: Bakalaureusekraad Omab vähemalt 2,5-aastast Ajaperiood: 2017 september – Praeguseni töökogemust IT arendajana. Firma: Dolm IT OÜ Positsioon: IT arendaja Ajaperiood: 2013 juuni – 2017 september Firma: Nortal AS Positsioon: IT arendaja 1b* Omab vähemalt 4-aastast Ajaperiood: 2013 juuni – 2017 september töökogemust IT arendajana. Firma: Nortal AS Positsioon: IT arendaja 2 On osalenud vähemalt ühes IT Projekti nimetus: eHealth haigla infosüsteemi projektis viimase kahe aasta arendustööd raamlepingu alusel jooksul, mille arendusmaht on Tundide maht: +5000h rohkem kui 1500 tundi ning Tõendav seos: Tööde käigus sai realiseeritud rohkem, projektis kasutatud Spring ning kui 1500 tundi kasutades Spring ning REST/SOAP REST/SOAP protokollil protokollil baseeruvaid veebiteenuseid baseeruvaid veebiteenuseid. 3 Omab vähemalt 2-aastast Projekti nimetus: eHealth haigla infosüsteemi töökogemust relatsiooniliste arendustööd raamlepingu alusel andmebaaside ja Java’ga. Tundide maht: +5000h Tõendav seos: Tegemist on Java projektiga, kus oli kasutusel relatsioonilised andmebaasid (nii PostgreSQL kui Oracle.) 4 Omab töökogemust järgmiste Jah töövahendite, raamistike ja keskkondadega: 4.1 GIT Projekti nimetus: Küberhügieeni arenduse ja hoolduse tööd Tundide maht: +2000h Positsioon: IT arendaja Tõendav seos: süsteemis oli koodihalduse keskonnana kasutusel GIT 4.2 Intellij IDEA/Eclipse Projekti nimetus: Küberhügieeni arenduse ja hoolduse tööd Tundide maht: +2000h  Positsioon: IT arendaja Tõendav seos: süsteemi arendustöödeks sai kasutatud Intellij IDEA keskkonda 4.3 Spring raamistik Projekti nimetus: eHealth haigla infosüsteemi arendustööd raamlepingu alusel Tundide maht: +5000h Tõendav seos: süsteemi arendustööd toimusid Java Spring raamistikul 4.4 REST ja SOAP veebiteenused Projekti nimetus: eHealth haigla infosüsteemi arendustööd raamlepingu alusel Tundide maht: +5000h Tõendav seos: süsteemi arendustööde käigus sai kasutatud nii REST kui ka SOAP veebiteenuseid Arendaja 2 (nimi, isikukood): Sten Luhtoja, 39210052038 Nõude Nõuded Täpsustus selle kohta kus/millal/kuidas on nõue kood täidetud. Projektidele viitamisel märkida projekti tellinud asutus, tellija kontaktisik ja projekti nimi, arvestades, et hankijal on õigus kontrollida esitatud andmeid viidatud kontaktisiku vahendusel. Välja täitmine on kohustuslik. 1a* Omab kõrgharidust reaalainete2 Kool: Tallinna Tehnikaülikool (Endine IT Kolledž) valdkonnas ja Eriala: Informaatika Kraad: Bakalaureusekraad Omab vähemalt 2,5-aastast Ajaperiood: 2019 märts – Praeguseni töökogemust IT arendajana. Firma: Dolm IT OÜ Positsioon: IT arendaja Ajaperiood: 2015 mai – 2019 märts Firma: Ignite OÜ Positsioon: IT arendaja 1b* Omab vähemalt 4-aastast Ajaperiood: 2015 mai – 2019 märts töökogemust IT arendajana. Firma: Ignite OÜ Positsioon: IT arendaja 2 On osalenud vähemalt ühes IT Projekti nimetus: Elisa ja Starmani süsteemide projektis viimase kahe aasta ühenduse keskne rakendus jooksul, mille arendusmaht on Tundide maht: +3000h rohkem kui 1500 tundi ning Tõendav seos: Süsteemi arendustööde käigus sai projektis kasutatud Spring ning kasutatud Java keelt, Spring raamistiku ning REST/SOAP protokollil REST/SOAP protokollil baseeruvaid veebiteenuseid. baseeruvaid veebiteenuseid. 3 Omab vähemalt 2-aastast Projekti nimetus: Elisa ja Starmani süsteemide töökogemust relatsiooniliste ühenduse keskne rakendus andmebaaside ja Java’ga. Tundide maht: +3000h Tõendav seos: Süsteemi arendustööde käigus sai kasutatud Java keelt ning relatsioonilist andmebaasi (postgreSQL). 2 Tartu Ülikoolis: Loodus ja täppisteaduste erialad; Tallinna Tehnikaülikoolis: Inseneri-, infotehnoloogia ja loodusteaduskonna erialad; Tallinna Ülikoolis: Digitehnoloogiate instituudi erialad; või samaväärne. 4 Omab töökogemust järgmiste Jah töövahendite, raamistike ja keskkondadega: 4.1 GIT Projekti nimetus: Telia rikete halduse süsteem Tundide maht: +1000h Tõendav seos: süsteemis oli koodihalduse keskonnana kasutusel GIT 4.2 Intellij IDEA/Eclipse Projekti nimetus: Elisa ja Starmani süsteemide ühenduse keskne rakendus Tundide maht: +3000h Tõendav seos: süsteemi arendustöödeks sai kasutatud Intellij IDEA keskkonda 4.3 Spring raamistik Projekti nimetus: Elisa ja Starmani süsteemide ühenduse keskne rakendus Tundide maht: +3000h Tõendav seos: süsteemi arendustööd toimusid Java Spring raamistikul 4.4 REST ja SOAP veebiteenused Projekti nimetus: Elisa ja Starmani süsteemide ühenduse keskne rakendus Tundide maht: +3000h Tõendav seos: süsteemi arendustööde käigus sai kasutatud nii REST kui ka SOAP veebiteenuseid *Täidetud peab olema kas väljal 1a või 1b esitatud nõue. Testija (nimi, isikukood): Stefan-Jaanus Rüstern, 39207140270 Nõude Nõuded Täpsustus selle kohta kus/millal/kuidas on nõue kood täidetud. Projektidele viitamisel märkida projekti tellinud asutus, tellija kontaktisik ja projekti nimi, arvestades, et hankijal on õigus kontrollida esitatud andmeid viidatud kontaktisiku vahendusel. Välja täitmine on kohustuslik. 1 Omab vähemalt 2-aastast Ajaperiood: 2018 jaanuar – Praeguseni töökogemust testijana või Firma: Dolm IT OÜ programmeerijana. Positsioon: Programmeerija / Automaattestija Ajaperiood: 2013 juuni – 2018 jaanuar Firma: Videobet Positsioon: Automaattestija 2 On osalenud vähemalt kahes 1.Projekti nimetus: Elisa kingituste süsteem tarkvara arenduse projektis, kus Tundide maht: +600h on isiklikult kirjutanud Tõendav seos: Süsteemi arendustööde käigus sai automaatteste. kirjutatud automaatteste. 2.Projekti nimetus: Videobeti kasiinomängu arendus Tundide maht: +3000h Tõendav seos: Süsteemi arendustööde käigus sai kirjutatud automaatteste.