ISIKUANDMETE TÖÖTLEMISE TINGIMUSED

... (edaspidi volitaja), registrikood ...., asukohaga ......, keda esindab direktor ....... ja ..... (edaspidi volitatud töötleja), registrikood ......, asukohaga ......., keda esindab juhatuse liige ........ on sõlminud käesoleva isikuandmete töötlemise lepingu hankelepingu nr ... lisana nr ... (edaspidi leping):

1. Ese ja eesmärk

1.1. Lepingu esemeks on volitaja ja volitatud töötleja (edaspidi koos nimetatud kui pooled) vaheliste tingimuste sätestamine seoses ... tööde käigus käsitletavate andmete töötlemisega.

1.2. Volitatud töötleja töötleb lepingus kirjeldatud isikuandmeid hankelepingu nr ... täitmiseks, millele on volitatud töötlejal õigus saada ligipääs hankelepingus määratletud tööde teostamiseks vastavalt lepingus sätestatud piirangutele.

1.3. Lepingu täitmiseks on volitatud töötleja isikuandmete töötlemisega seotud tegevused lepingu alusel piiratud hankelepingu täitmiseks vajalike tegevustega. Ligipääs isikuandmetele võimaldatakse .....

2. Isikuandmed

2.1. Volitatud töötlejale võivad hankelepingu täitmise käigus teatavaks saada volitaja poolt hallatavas infosüsteemis või andmekogus töödeldavad isikuandmed: 2.1.1. isikuandmed, nt inimese nimi, sünniaeg, isikukood, isikut tõendava

dokumendi andmed; 2.1.2. kontaktandmed, nt aadress, telefoninumber ja e-posti aadress; 2.1.3. eriliiki isikuandmed, nt andmed isiku, tema esindatava või tema

pereliikme terviseseisundi, majandusliku seisundi või perekonna kohta; 2.1.4. ameti- ja kutsesaladust puudutav teave.

3. Volitatud töötleja kohustused

3.1. Volitatud töötleja on kohustatud: 3.1.1. tagama lepingueelsete läbirääkimiste ja lepingu täitmise käigus volitajalt

ükskõik mis vormis saadud isikuandmete konfidentsiaalsuse ja mitte edastama ega võimaldama sellele teabele juurdepääsu kolmandale isikule ilma volitaja sellekohase selgesõnalise kirjaliku nõusolekuta;

3.1.2. tagama, et lepingu täitmise raames töödeldavaid isikuandmeid ei edastata väljapoole Euroopa Liidu liikmesriikide ja Euroopa Majandusühendusse kuuluvate riikide territooriumi ilma volitaja sellekohase selgesõnalise kirjaliku nõusolekuta;

3.1.3. kasutama ja töötlema isikuandmeid üksnes hankelepingu 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;

3.1.4. võimaldama juurdepääsu isikuandmetele ainult nendele isikutele, kellel on selleks oma tööülesannete täitmiseks vajadus ning tagab, 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;

3.1.5. teavitama volitajat toimunud või põhjendatult kahtlustatavast lepingu punktis 3.1.4. sätestatud konfidentsiaalsuskohustuse rikkumisest viivitamatult;

3.1.6. 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;

3.1.7. rakendama alltoodud organisatsioonilisi, füüsilisi ja infotehnilisi 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:

3.1.7.1. vältima kõrvaliste isikute ligipääsu isikuandmete töötlemiseks kasutatavatele seadmetele;

3.1.7.2. ära hoidma andmete omavolilist lugemist, kopeerimist ja muutmist andmetöötlussüsteemis, samuti andmekandjate omavolilist teisaldamist;

3.1.7.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;

3.1.7.4. tagama, et igal andmetöötlussüsteemi kasutajal oleks juurdepääs ainult temale töötlemiseks lubatud isikuandmetele ja temale lubatud andmetöötluseks;

3.1.7.5. tagama andmete olemasolu isikuandmete edastamise kohta: millal, kellele ja millised isikuandmed edastati, samuti selliste andmete muutusteta säilimise;

3.1.7.6. tagama, et isikuandmete edastamisel andmesidevahenditega ja andmekandjate transportimisel ei toimuks isikuandmete omavolilist lugemist, kopeerimist, muutmist või kustutamist;

3.1.7.7. pidama arvestust isikuandmete töötlemisel kasutatavate tema kontrolli all olevate seadmete ja tarkvara üle, dokumenteerides järgmised andmed:

3.1.7.7.1. seadme nimetus, tüüp ja asukoht ning seadme valmistaja nimi; 3.1.7.7.2. tarkvara nimetus, versioon, valmistaja nimi ja kontaktandmed.

3.1.8. teavitama kirjalikult volitajat turvameetmete rikkumisest, mis põhjustab, on põhjustanud või võib põhjustada töödeldavate isikuandmete juhusliku või

ebaseadusliku hävitamise, kaotsimineku, muutmise või loata avalikustamise või neile juurdepääsu 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:

3.1.8.1. kirjeldada isikuandmetega seotud rikkumise laadi, sealhulgas puudutatud andmesubjektide liike ja arvu ning puudutatud kirjete liike ja arvu;

3.1.8.2. teatada andmekaitsespetsialisti või mõne teise täiendavat teavet andva kontaktisiku nimi ja kontaktandmed;

3.1.8.3. soovitada meetmeid isikuandmetega seotud rikkumise võimalike negatiivsete mõjude leevendamiseks;

3.1.8.4. kirjeldada isikuandmetega seotud rikkumise võimalikke tagajärgi; 3.1.8.5. kirjeldada volitatud töötleja poolt pakutud või võetud meetmeid

isikuandmetega seotud rikkumisega tegelemiseks ja 3.1.8.6. 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.

3.1.9. lõpetama eelnevalt kirjeldatud rikkumised või tegema kõik endast oleneva nende lõpetamiseks ja kohaldama meetmeid isikuandmetega seotud rikkumise lahendamiseks, sealhulgas vajaduse korral rikkumise võimaliku kahjuliku mõju kõrvaldamiseks ja leevendamiseks;

3.1.10. kustutama, niivõrd kui see on võimalik, lepingu lõppemisel kõik tööde teostamise käigus teatavaks saanud isikuandmed ja nimetatute koopiad 30 päeva jooksul, v.a juhul, kui õigusaktidest tuleneb teisiti;

3.1.11. tegema volitajale kättesaadavaks kogu teabe, mida volitaja peab vajalikuks lepingus sätestatud kohustuste täitmise tõendamiseks;

3.1.12. võimaldama volitajal või volitaja poolt määratud audiitoril teha seoses isikuandmete töötlemisega auditeid ja kontrolle ning panustama nendesse.

4. Lõppsätted

4.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.

4.2. Isikuandmete konfidentsiaalsena hoidmise kohustus jääb kehtima ka pärast käesoleva lepingu lõppemist tähtajatult.

4.3. Isikuandmete konfidentsiaalsena hoidmise kohustus ei laiene teabe avaldamisele volitatud töötleja audiitorile ja advokaadile.

4.4. Leping on kehtiv poolte poolt allkirjastamisest kuni hankelepingu järgsete kohustuste täitmiseni, v.a konfidentsiaalsuskohtustus, mis kehtib tähtajatult.

5. Poole allkirjad

Volitaja: Volitatud töötleja: /Allkirjastatud digitaalselt/ /Allkirjastatud digitaalselt/

1

TEHNILINE KIRJELDUS Riigihanke nimetus: Tervisestatistika infosüsteemi arendus- ja hooldustööd Lühendid ja mõisted

Lühend/mõiste Kirjeldus

TAI Tervise Arengu Instituut

TEHIK Tervise ja Heaolu Infosüsteemide Keskus

TIS Tervise infosüsteem

RHS Riigihangete seadus

MEDISTAT Uus tervisestatistika infosüsteem

TTO Tervishoiuteenuse osutaja

1. ÜLDINE KIRJELDUS Teostada tervisestatistika andmete kogumisel ja haldamisel uuele metoodikale ülemineku süsteemianalüüsi-, arendus- ja hooldustöid. 1.1. Hanke eesmärk Hange on suunatud tarkvaraarenduse terviklahenduse pakkujale süsteemianalüüsi-, arendus- ja hooldustööde (edaspidi töö) teostamiseks. Eesmärk on luua Tervisestatistika infosüsteem, mis võimaldab koguda ja vastu võtta andmeid tervishoiuteenuse osutajatelt, teistelt ettevõtetelt ning riiklikest registritest ja süsteemidest. Süsteem peab vähendama tervisestatistiliste andmete esitajate halduskoormust aruandekohustuste täitmisel ja TAI halduskoormust tervisestatistiliste andmete kogumisel ning haldamisel, kasutades selleks tänapäevaseid tehnoloogilisi lahendusi äriprotsesside, andmekorje ja andmehalduse digitaliseerimiseks ning automatiseerimiseks. Arendusega soovitakse andmekorjeks praegu kasutusel olev tervishoiustatistika ja tervishoiualase majandustegevuse statistika kogumise keskkond (A-veeb) ning muul viisil toimuv tervisestatistiliste andmete kogumine asendada tänapäevase infotehnoloogilise lahendusega. Süsteemianalüüsi ja arendustööde aluseks on 2025. aastal teostatud ärianalüüs. 1.2. Taustainfo Tervise Arengu Instituudi üheks ülesandeks on tegeleda Eestis tervisestatistiliste andmete kogumise, kontrollimise, töötlemise, analüüsimise ja levitamisega ning valdkonna metodoloogilise arendustööga. Enamik tervishoiustatistilistest andmetest kogutakse agregeeritud aruandluse alusel A-veebi keskkonna kaudu (https://aveeb.sm.ee/). Osaliselt toimub tervisestatistiliste andmete kogumine meilitsi (nt .csv ja .xlsx formaatides) ning veebikorje teel ka muudest infoallikatest. Pärast andmete kogumist toimub andmete kontrolli ja parandusprotsess ning vigade ja muutuste täpsustamine andmeesitajatega. Sellele järgneb andmete töötlus, andmeanalüüs, muutuste põhjuste väljaselgitamine, andmete vaheliste seoste otsimine, andmete kõrvutamine teiste andmeallikatega ning statistiliste korrektuuride tegemine. Andmeanalüüsi tulemusel saadud statistilised tulemused avaldatakse Tervisestatistika ja terviseuuringute andmebaas-is. TAI eesmärk on tagada tarbijatele kiire, ulatuslik, detailne ja kvaliteetne tervisestatistika, lõpetada dubleeriv andmekogumine ning minna üle administratiivsete andmeallikate teisesele andmekasutusele või andmeesitajatelt masin-masin liidestusega andmete kogumisele. Ärianalüüs hõlmas:

 Loodava veebirakenduse üldfunktsionaalsusi (mh esileht; aruannete vormid ja juhised; autentimine; TTO töölaud; õigused; aruannete staatused; klassifikaatorid; liidesed; TAI töölaud; aruandlusperioodide haldamine; aruandluskohustuse määramine; aruandevormide haldamine; andmete kustutamine; migratsioon; e-kirjade saatmine).

 Tervishoiutöötajate ja -tunnipalga andmete kogumist (mh masin-masin (M2M) liides aruande esitamiseks; funktsionaalsus M2M andmetest aruande tegemiseks; andmete rikastamine; ametikoodide ja verekeskuste kvalifitseerimise "whitelist-tabel"; aruandevormi kontrollreeglid; ADS

2

liidestus; andmete kogumise alternatiivsed allikad; andmete sobivus andmepõhise aruandluse palga- ja tööjõukulu taksonoomiaga).

 Tervishoiuteenuste osutajate andmete kogumist ja haldamist.

 Tervishoiukulude andmete kogumist.

 Tervishoiualase majandustegevuse andmete kogumist (mh masin-masin (M2M) liides aruande esitamiseks; andmete sobivus andmepõhise aruandluse majandustehingute taksonoomiaga).

 Verekeskuse andmete kogumist.

 Ravivoodite andmete kogumist

 Operatsioonivõimekuse andmete kogumist

 Meditsiiniseadmete andmete kogumist.

Tervishoiutöötajate andmete kogumise eesmärk on anda ülevaade tervishoiutöötajate vanuselisest ja soolisest jaotusest ning töökoormusest ja täidetud ametikohtadest ametialade kaupa. Tervishoiutöötajate tunnipalga andmete kogumise eesmärk on anda detailne ülevaade tervishoiutöötajate keskmisest tunni- ja kuupalgast erinevate ametirühmade vanuse, soo ja tervishoiuteenuse osutaja liikide kaupa. Andmeid esitavad kõik tervishoiuteenuse osutajad (TTO-d). Andmete esitamine A-veebi kaudu on andmeesitajale suur halduskoormus, sest samu andmeid esitatakse dubleerivalt ka Maksu- ja Tolliametile ning Statistikaametile. Tervishoiuteenuste osutajate andmete kogumise eesmärk on ülevaate saamine tervishoiuteenuseid pakkuvatest asutustest, selleks, et koguda, töödelda ja avaldada tervisestatistikat, milles on hõlmatud kõikide tegutsevate TTO-de andmed. TTO üldandmeid esitavad kõik TTO-d A-veebi kaudu ning lisaks toimub süsteemiväline veebikorje TAI töötajate poolt. TTO-de andmed pannakse kokku avalikult kättesaadava, erinevatelt koostööpartneritelt saadud ning iga-aastase aruandluse raames TTO-de poolt TAI-le teada antud info põhjal. Andmete esitamine A-veebi kaudu on andmeesitajale ja süsteemiväline veebikorje vajaliku info kokku kogumiseks TAI-le suur halduskoormus. Tervishoiualase majandustegevuse andmete kogumise eesmärk on saada detailne ülevaade tervishoiuteenuse osutajate tuluallikatest, kulutustest ning investeeringutest põhivarasse. Aruanne tugineb majandusaasta aruandel, kuid detailsemalt on välja toodud tervishoiutegevusele omased näitajad. Aruande esitamise kohustus on kõikidel tervishoiuteenuse osutajatel, isegi kui nende põhitegevus ei ole tervishoiuteenuse osutamine. Andmeid esitatakse A-veebi kaudu. Lisaks toimub süsteemiväline veebikorje TAI töötajate poolt. Andmete esitamine A-veebi kaudu on andmeesitajale suur halduskoormus, sest toimub dubleeriv andmeedastus ka Registrite ja Infosüsteemide Keskusele. 1.3. Probleemi kirjeldus Andmeesitajatele on agregeeritud vormipõhine andmete edastus läbi A-veebi väga suur halduskoormus, kuna paljudel puudub masin-masin liidestus ning osaliselt peavad teenuseosutajad samu andmeid esitama ka teistele asutustele. Praegust andmekogumise süsteemi A-veeb on tehniliselt keeruline hallata ja uusi muudatusi ajamahukas ja kulukas sisse viia. A-veeb ei ole tänapäevane ega kasutajasõbralik ning liidestus erinevate registrite ja teiste süsteemidega ei ole piisav. TAI andmekorjes ja -töötluses osalevatele töötajatele on info erinevatest allikatest käsitsi otsimine ning koondamine samuti suureks halduskoormuseks. 2. ESEME KIRJELDUS

2.1. Täitja ülesandeks on läbi viia detailanalüüs ning selle põhjal arendada eraldiseisev Tervisestatistika

infosüsteem (MEDISTAT), mis võimaldab koguda ja vastu võtta andmeid tervishoiuteenuse osutajatelt, teistelt ettevõtetelt ning riiklikest registritest ja süsteemidest.

2.2. Süsteem peab vähendama tervisestatistiliste andmete esitajate halduskoormust aruandekohustuste täitmisel ja TAI halduskoormust tervisestatistiliste andmete kogumisel ning haldamisel, kasutades selleks tänapäevaseid tehnoloogilisi lahendusi äriprotsesside, andmekorje ja andmehalduse digitaliseerimiseks ning automatiseerimiseks.

2.3. Arendustööd teostatakse arvestades tellija poolt esitatud arendusnõudeid „TEHIK nõuded arendustele“ ja täiendavaid materjale asukohaga https://tehik.ee/arendusjuhendid (v.a allkirjastamine);

3

2.4. Arendustööde tegemisel arvestatakse eelduslikult olemasolevate teenuste liidestamisega: 2.4.1. Pääsuke – keskne volituste haldamise infosüsteem 2.4.2. MEDRE – tervishoiukorralduse infosüsteem 2.4.3. TÖR – töötamise register 2.4.4. ADS – aadressandmete süsteem 2.4.5. ÄR - Äriregister 2.4.6. Tervisekassa andmekogu 2.4.7. TARA – Riigi autentimisteenus 2.4.8. GOV SSO teenus – Riigi SSO teenus 2.4.9. TEHIKu teabekeskus 2.4.10. ÜVIS – üleriigiline vereinfosüsteem 2.4.11. MSA2 – meditsiiniseadmete andmekogu 2.4.12. Võib lisanduda veel teenuseid

2.5. Olemasolevate teenuste korduvkasutusel teostab töövõtja arendaja teenustes vajalikud arendused, kohandades teenused sobivaks vastavalt tervisestatistika andmestikule.

3. MEDISTAT INFOSÜSTEEMI ARENDUSTÖÖDE ÜLDISED NÕUDED

3.1. Loodav süsteem peab toetama reaalajamajanduse andmepõhise aruandluse valdkonna visiooni,

mis kirjeldab, et riik ja kodanik saavad säästa aega ning raha paberipõhiste haldustoimingute asendamisega automaatse andmevahetuse vastu, kui need toimuvad järgmistel põhimõtetel:

 turvaliselt;

 standardiseeritult;

 digitaalselt;

 automaatselt;

 masinloetavalt;

 reaalajas või minimaalse viitega (täpsustub süsteemianalüüsi käigus). 3.2. Uute lahenduste väljatöötamisel tuleb arvestada Eesti Vabariigis kehtivate majandusalaste

taksonoomiatega (nt tervishoiutöötajate ja -tunnipalga andmed). Pakutav lahendus peab võimaldama andmevahetust läbi x-tee turvaserveri, majandusandmete puhul XBRL GL formaadis. XBRL GL on info edastamise struktureeritud vorming, mis on XMLi põhine ning sobib andmete kiiremaks, tõhusamaks ja väiksemate kuludega edastamiseks, töötlemiseks ning analüüsimiseks.

4. HANGITAV SKOOP 4.1. Hanke skoobiks on MEDISTAT süsteemi arendus ja hooldustööd, sh vähemalt:

4.1.1. Ärinõuete analüüs ja kaardistamine; 4.1.2. Arendus- ja juurutustööd koos (automaat)testimisega ning seotud komponentide ühise

töökindluse tagamisega; 4.1.3. X-tee liideste arendus infosüsteemide vahel; 4.1.4. Dokumentatsiooni koostamine; 4.1.5. Konsultatsioon; 4.1.6. Muud tööd, mis on vajalikud arendustöö tõrgeteta toimise tagamiseks.

4.2. Hooldustööde alla kuuluvad etteplaneeritud tarkvara ja infosüsteemi hoolduse tegevused, mille eesmärk on infosüsteemi toimivuse tagamine ning veaparandustööd, mis on vajalikud testimise või igapäevase töö käigus avastatud vigade kõrvaldamiseks.

5. TÖÖDE TELLIMISE PÕHIMÕTTED 5.1. Arenduste läbiviimise metoodika kehtestab tellija konkreetse tellimuse tingimusena. Arenduste

läbiviimine toimub kas: 5.1.1. funktsionaalsuse põhiselt, kus sisendiks on konkreetse tulemi (skoobi) tellimus, sh tähtaeg

ja/või piirsumma või; 5.1.2. arendusmeeskonna töötundide põhiselt, kus arendused realiseeritakse agiilse

4

arendusprotsessi põhimõtetel. 5.1.3. Andma arendusega seotud konsultatsioone ja koolitusi.

6. TEHNILISE KIRJELDUSE (TK) LISAD:

6.1. TK Lisa 1 – TEHIKu mittefunktsionaalsed nõuded arendustele; 6.2. TK Lisa 2 - Nõuded infosüsteemi dokumentatsioonile; 6.3. TK Lisa 3 - IT-Profiil; 6.4. TK Lisa 4 – Automaattestide kasutamise nõuded; 6.5. TK Lisa 5 – Front-end arendusreeglid; 6.6. TK Lisa 6 – Lähtekoodi haldus.

Hankelepingu projekt

Tervise ja Heaolu Infosüsteemide Keskus (edaspidi tellija), registrikood 70009770, aadress Pärnu

mnt 132, 11317 Tallinn, keda esindab põhimääruse alusel direktor Margus Arm ja

Askend Estonia OÜ (edaspidi täitja), registrikood 14133207, aadress Harju maakond, Tallinn,

Kesklinna linnaosa, Tartu mnt 80f, 10112, keda esindab põhikirja alusel juhatuse liige Vassili

Ljahhovets,

edaspidi eraldi pool või koos pooled, sõlmisid raamlepingu nr 3-9/5065-1 alusel käesoleva

hankelepingu (edaspidi leping) alljärgnevas:

1. Lepingu ese

1.1. Lepingu esemeks on riigihanke „Tervisestatistika infosüsteemi arendus- ja hooldustööd“,

viitenumber 308846 alusdokumentides olevas tehnilises kirjelduses nimetatud tööd

(edaspidi tööd).

1.2. Lepingu tööde maht tundides/kuudes/maksumusena/maksimaalse mahuna.

1.3. Lepingut rahastatakse projektist nr _____ . Tulemi märgistamisel lähtutakse _____ .

2. Töö üleandmise ja vastuvõtmise tingimused

2.1. Täitja annab töö üle päev.kuu.aasta/kuude arv alates lepingu sõlmimisest.

2.2. Töötunni põhise lepingu korral esitab täitja eelmise kuu töötundide ajaaruande, mis sisaldab

teostatud töötunde ja nende jooksul teostatud töid. Ajaaruanne esitatakse allkirjastatult

hiljemalt järgmise kalendrikuu 5. tööpäeval. Viimane ajaaruanne esitatakse koos aktiga.

2.3. Tellitavad tööd antakse vastuvõtutestimiseks üle vastavalt lepingu tehnilises kirjelduses

kokkulepitud tingimustele.

2.4. Tellija vaatab töö üle vastavalt raamlepingu tingimustele.

2.5. Koos üle antava tööga annab täitja tellijale üle kõik tööde intellektuaalse omandi õigused

vastavalt raamlepingus kirjeldatule.

2.6. Siia sisestatakse kõik erisused võrreldes raamlepingus sätestatuga.

3. Lepingu hind

Kui tegemist on töötunnipõhise lepinguga:

3.1. Lepingu täitmine toimub töötunnipõhisel arvestusel, tellija tasub üksnes lepingu alusel

tellitud ja teostatud töötundide eest.

3.2. Ühe töötunni maksumuseks lepingu täitmisel on ____ (maksumus sõnadega) eurot

käibemaksuta.

3.3. Täitja esitab tellijale e-arve igakuiselt. Arvel tuleb märkida riigihanke nimetus, lepingu osa

viitenumber, lepingu number ja kontaktisiku andmed.

Kui tegemist on fikseeritud kogumaksumusega:

3.1. Tellija tasub lepingu alusel tellitud tööde eest kokku ___ (maksumus sõnadega) eurot

käibemaksuta.

3.2. Tööd antakse üle järgmistes etappides:

3.2.1. ____;

3.2.2. ____.

3.3. Täitja esitab tellijale e-arve pärast töö üleandmise-vastuvõtmise akti allkirjastamist. Arvele

tuleb märkida lepingu osa viitenumber riigihangete registrist: ______ ___ ___ ___.

4. Poolte vahelised teated ja kontaktisikud

4.1. Teadete edastamisel ja kätte toimetamisel lähtutakse raamlepingu regulatsioonist.

4.2. Tellija kontaktisikuks lepingu täitmisel on ________, tel ________, e-post ______ või tema

asendaja.

4.3. Täitja kontaktisikuks lepingu täitmisel on ________, tel ________, e-post ______ või tema

asendaja.

5. Lõppsätted

5.1. Leping jõustub sellele poolte poolt allakirjutamise hetkest ja kehtib kuni poolte poolt oma

lepinguliste kohustuste täitmiseni.

5.2. Lepingu dokumendid koosnevad riigihanke alusdokumentidest, sh lepingu lisadest, lepingu

muudatustest ja pakkumusest.

5.3. Lepingu lahutamatuteks osadeks lepingu sõlmimise hetkel on järgmised dokumendid:

5.3.1. Lisa 1 - Tehniline kirjeldus;

5.3.2. Lisa 2 – Pakkumus (ei allkirjastata koos lepinguga);

5.3.3. ______ .

6. Poolte allkirjad

Tellija: Täitja:

Tööde üleandmise-vastuvõtmise akt

1. Sisu

Lähtudes Tervise ja Heaolu Infosüsteemide Keskuse, keda esindab /lepingus märgitud kontaktisik/

(edaspidi tellija) ja /ettevõtja nimi/, keda esindab /lepingus märgitud kontaktisik/ (edaspidi täitja)

vahel päev.kuu.aasta sõlmitud hankelepingu nr ___ annab täitja üle ja võtab tellija vastu teostatud

tööd.

1.1. Käesoleva aktiga annab täitja tellijale üle tööd, mis täitja on teostanud vastavalt

hankelepingule ja tellija võtab käesolevas aktis nimetatud tööd vastu.

1.2. Tellija kinnitab, et tema või tema esindajad on käesolevas aktis nimetatud tööd üle vaadanud

ning see vastab hankelepingule.

1.3. Käesolev akt on täitjale tasu maksmise aluseks. Poolte vaheline arveldamine toimub

hankelepingu alusel vastavalt käesolevas aktis sisalduvatele andmetele.

1.4. Käesoleva akti pooled kinnitavad, et aktis sisalduvad andmed on nende parima teadmise

kohaselt õiged.

2. Akteeritavad tööd

Nr Tööde loetelu Tunnid Maksumus km-

ta

1

2

KOKKU

Pooled kinnitavad, et hankelepingu alusel käesoleva aktiga vastuvõetavate tööde hinnaks on

brutosummana ...... (summa sõnadega) eurot. Täitjale arvestatud töötasust peetakse kinni EV

seadusandlusega kehtestatud maksud ja maksed ning tellija tasub EV seadusandlusega kehtestatud

makse ja makseid.1

3. Tööde üleandmise tähtaeg

3.1. Tööd on üle antud päev.kuu.aasta /etappide puhul ka etapid/.

3.2. Tööd teostati tähtaegselt.

4. Puudustega tööde nimekiri

4.1. Puuduseid töös ei esine./Esinevad järgmised puudused töös:

4.1.1. ____;

4.1.2. ____;

4.2. Puuduste põhjendus.

4.3. Puuduste kõrvaldamise tähtaeg on päev.kuu.aasta.

1 Antud lõik eemaldatakse, kui täitja on juriidiline isik.

5. Poolte allkirjad

Tellija: Täitja:

Lepinguline kontaktisik lepinguline kontaktisik

/allkirjastatud digitaalselt/ /allkirjastatud digitaalselt/

Lisa 5

Kodukord

1. Eesmärk

1.1. Kodukorra eesmärgiks on täpsustada hankelepingu alusel (edaspidi nimetatud ka

projekt) tööde tellimise kord ja põhimõtted, täitja ja tellija omavaheline suhtlus ning

tagasiside andmise kord.

1.2. Tellija võib teha kodukorda muudatusi, teavitades täitjat kodukorra muutmisest.

2. Mõisted

2.1. Töö – hankelepingus fikseeritud töö(d)/tegevus(ed) ja üleantav(ad) tulem(id), mida saab

testida või mille valmimist saab kinnitada tellija.

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/äritellija – Tervise Arengu Instituut, kes hakkab tööna tellitud

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 ja sihtgrupid.

2.5. Arendustööd – programmeerimine koos selle juurde kuuluvate tugitegevustega, sh

analüüsitööd.

2.6. Jira – tellija probleemide ja arenduste piletite jälgimise keskkond, sh arenduste tundide

jälgimise keskkond.

2.7. Wiki ehk Confluence – kogu projekti dokumentatsiooni, sh analüüsi hoidmise keskkond.

2.8. Sprint – aeg, tavaliselt kaks nädalat, mille jooksul saavutatakse konkreetne tulemus.

2.9. Stand-up - Stand-up on regulaarne, lühike, üldjuhul igapäevane kohtumine

projektimeeskonnaga, et tööde seisust ja edenemisest oleks kõigil ülevaade.

2.10. Backlog Grooming/refinement – vaadatakse üle backlogis olevad taskid (kas on valmis

arendusse võtmiseks), prioritiseeritakse. Peamine ülesanne, et backlog on uuendatud,

ajakohane ja piletid on valmis sprinti võtmiseks.

2.11. Sprint planning – sprindi tööde planeerimine

2.12. Demo - Sprindi tööde tutvustamine arendustiimi poolt. Arendustiim annab ülevaate,

millised tööd said sprindi jooksul valmis ja näitavad need ette - nii BackEnd kui FrontEnd

tööd. Samuti annavad ülevaate, mis tööd ei saanud valmis ja mis kanduvad järgmisse

sprinti üle.

2.13. Retro - Retrospektiiv on kohtumine projekti meeskonnaga, kus vaadatakse tagasi ja

tulevikku, et õppekohti tuvastada ja kaasa võtta, säilitada häid praktikaid ja loobuda

halbadest.

3. Töökorraldus tööde teostamisel

3.1. Täitja peab olema võimeline arendustöid teostama MVP põhimõtetest lähtudes.

3.1.1. Pakkumuskutses on fikseeritud loodava funktsionaalsuse loetelu (skoop) ärinõuetena

ilma konkreetsete lahenduskäikudeta. Täitja ülesandeks on tellija poolt seatud ajalistes ja

Lisa 5

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

arendustööde lõppmaksumuse proportsionaalsust lahendatava probleemi keerukusega.

3.2. Täitja tagab tööde teostamise ajal igakülgse läbipaistvuse vastavalt tellija nõuetele (sh

otsekontakt ja vajadusel igapäevane suhtlus kõikide täitja meeskonna liikmetega):

3.2.1. arendustööde teostamine on jagatud reeglina kahenädalasteks etappideks (sprint). Tellija nõusolekul võib sprindi pikkust muuta;

3.2.2. arendus ja/või analüüsi tööde teostamise perioodi igal hommikul või vähemalt kolm korda nädalas viiakse läbi projektimeeskonna päevakoosolek (stand-up), kus kõik liikmed annavad ülevaate eelnenud tööpäeval tehtud töödest, mis on samal päeval plaanis teha ja toovad välja tööde tegemisel ilmnenud takistused, kui neid peaks esinema. Takistuste lahendamine lepitakse kokku väljaspool stand-upi;

3.2.3. iga etapi järel esitleb täitja saavutatud tulemeid tellijale (nt viib läbi demo);

3.2.4. iga arendusetapi tööde tutvustamise (demo) järgselt korraldab täitja projektimeeskonnale tagasivaatekoosoleku (retro), kus iga tiimiliige annab tagasisidet, mis läks hästi ja mis oleks võinud paremini minna. Üldise arutelu käigus peab projektimeeskond jõudma arusaamisele, kuidas ja kes ilmnenud puudujäägid kõrvaldab;

3.2.5. iga etapi järel esitab täitja ülevaate planeeritud arendustööde mahust ja tegelikult

teostatud tööde mahust (nn „põlemisgraafik“, Burndown chart) koos selgituste ja

tulemuslikkuse suurendamise kavaga;

3.2.6. iga etapi järel viib täitja läbi järgmise sprindi planeerimise (sprint planning) koosoleku;

3.2.7. uue kahenädalase etapi eelneval nädalal peab täitja korraldama projektimeeskonnaga planeerimiskoosoleku (backlog grooming/refinement), kus hinnatakse järgmiste etappide tööde eeldatavat mahtu ja kus vajadusel tükeldatakse arendustööd väikesemateks osadeks. Planeerimiskoosolekuks peab täitja olema eelnevalt analüüsinud ja kirjeldanud piisavalt töid, et garanteerida, et igas sprindis oleks täitja meeskonnal maksimaalne hõivatus;

3.2.8. täitja peab korraldama iganädalasi projektimeeskonnaga analüüsikoosolekuid, kus vastavalt vajadusele arutatakse nii äri- kui detailanalüüsi käigus tekkinud küsimusi, valideeritakse valminud prototüüpe, planeeritakse testimisi ja vajadusel arutatakse muid sisulisi küsimusi;

3.2.9. arendustööd on hiljemalt etapi planeerimise hetkeks jagatud ühtlase detailsusega väiksemateks osadeks. Kui vajadus töö jagamiseks väiksemateks osadeks tekib töö käigus, siis tuleb seda teha koheselt;

3.2.10. nõuete vajadus sõltub töö(de) mahust ning iseloomust ja nende rakendamise üle otsustab tellija.

3.3. Tööde teostamine ei tohi tekitada häireid tellija mistahes teiste liidestatud süsteemide

või teenuste talitluses, v.a juhul kui see on tellija ja täitja vahel eelnevalt kokku lepitud.

3.4. Täitja meeskonnaliikmed peavad, tellija korraldusel, olema valmis töötama tellija

ruumides (TEHIKu kontor, Pärnu mnt 132, 11317 Tallinn).

3.5. Juhul, kui töö teostamine toimub tellija ruumides, peavad tellija ruumides viibivad täitja

esindajad kinni pidama tellija juures kehtivatest sisekorraeeskirjadest, sh turvanõuetest,

mis on tellija poolt teatavaks tehtud.

3.6. Vajadusel võivad tellija ja täitja esindajad kokku leppida tööde teostamise töövälisel ajal.

Sellisel juhul lepivad pooled kokku konkreetsetes reeglites, mis alluvad ületundide

Lisa 5

teostamise regulatsioonile, st töövälisel ajal töö tegemise puhul hüvitatakse see

eelduslikult vaba aja andmisega.

3.7. Lepingu täitmisest tulenev suhtlus toimub eesti keeles, täitja peab tagama võimekuse

tööde teostajatega eesti keeles infot vahetada (vajadusel korraldab nt tõlke täitja). Tellija

ei kata tõlkimisega seotud kulusid.

4. Tööde üleandmine

4.1. Tööde tulemused ja vajadusel tööde teostamise käik dokumenteeritakse ning hallatakse tellija dokumendihalduskeskkonnas (nt. wiki, jira) ja/või koodihalduskeskkonnas (näiteks gitlab).

4.2. Arendustööde tulemite üleandmise eelselt viib täitja läbi süsteemitestimise (System Test). Nõuded süsteemitestimisele (sh automaattestimisele) kehtestab tellija (üldise korrana, vajadusel konkreetse lepingu raames).

4.2.1. Süsteemitestimise tulemusena peab lähtekood olema vigadeta, st kõlbulik toodangukeskkonda paigaldamiseks.

4.2.2. Vajadusel teostab arendaja tööde üleandmiseks täiendavad testid tellija testkeskkonnas (arenduskeskkondade limitatsioonide korral).

4.2.3. Testimiste tulemused (vastuvõtu kriteeriumite kontroll) dokumenteeritakse vastavasse arenduspiletisse, selleks kirjeldatakse ära mida on testitud ja milline oli tulemus.

4.3. Arendustööde tulemite üleandmine (lähtekoodi tarne) toimub pideva integreerimise (Continuous Integration) teel või kokkulepitud sagedusega (nt iga arendustööde etapi järel).

4.4. Tarne on tehtud komplekselt lähtudes ettenähtud tarneprotsessist

4.4.1. Täitja teab, et tellija võib igat üle antud funktsionaalsust paigaldada toodangusse ning täitja peab tagama, et lõplikult valmimata funktsiooni protsessid on võimalik toodangust välja lülitada (feature flags).

4.5. Täitja korraldab tulemite üleandmise järel vajalikud lähtekoodi paigaldused keskkondadesse, kus tellija viib läbi vastuvõtutestimise (Acceptance Test, User Acceptance Test).

4.6. Täitja annab tööd üle omalt poolt allkirjastatud aktiga. Hooldustööde teostamisel tuleb koos aktiga esitada ajaaruanne. Aktis peavad tehtud hooldus- ja arendustööd olema teineteisest eristatud.

4.6.1. Nooremarendaja vms (raamlepingu p 5.7) kaasamisel meeskonda on täitja kohustatud eristama aktis tema töötunnid ning esitlema detailset loetelu teostatud töödest.

5. Tööde teostamise meeskonna rollid ja vastutused

5.1. Tööde teostamiseks moodustatakse projektimeeskond.

5.2. Tellija (so Tervise ja Heaolu Infosüsteemide Keskuse) poolt osalevad tööde tellimisel ja

teostamisel järgmised rollid:

5.2.1. Tellija projektijuht - juhib tellija poolt tööde tellimuse ja ajaplaani kokkuleppimist ning

tööde teostamist. Tellija projektijuhil on õigus kontrollida lepingu täitmise käiku ning

kohustus anda täitjale töödega seotud informatsiooni ja juhiseid vastava nõude

esitamisel. . Tellija projektijuht on peamine kontakt erinevate takistuste ja probleemide

lahendamisel;

Lisa 5

5.2.2. Tooteomanik (Product Owner) – esindab äritellijat igapäevatöös, sh korraldab ja viib läbi

kokkulepitud ärinõuete defineerimise ja prioriseerimise, juhib projekti skoopi (ulatust).

5.2.3. Arhitekt – 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.

5.2.4. 5.2.4. rakenduse- ja/või süsteemiadministraator – teostab paigalduse, annab tehnilist nõu

täitjale.

5.3. 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. Samuti organiseerib arenduskoosolekuid (vt p 3) ja koondab igakuiselt

arendajate töötunnid, mille alusel koostatakse tööde ja töötundide üleandmiseks akt. On

hankijale kontaktisikuks tööde teostamise ning üleandmise käigus.

5.4. Täitja arhitekt vastutab rakenduse arhitektuuri ja komponentide eest, osaleb rakenduse

dokumentatsiooni koostamisel ning teostab pakkuja poolt arendus- ja veaparandustöid.

5.5. Täitja süsteemianalüütik analüüsib Tellija tehnilisi vajadusi ning koostab

arenduspileteid.

5.6. Täitja arendaja teostab pakkuja poolt arendus- ja veaparandustöid.

5.7. Täitja kasutajaliidese disainer teostab disainitöid, vajadusel täiendab ja testib FIGMA’s

loodud tehnilise lahenduse prototüüpi, toetab arendatava lahenduse kasutajatestimise

läbiviimist ning koostab ettepanekud lahenduse kasutajasõbralikuks muutmiseks

koostöös arendusmeeskonnaga;

5.8. Täitja front-end arendaja ülesandeks on front-end arendustegevused;

5.9. Täitja testija vastutab selle eest, et tarkvara kvaliteet oleks tagatud läbi vigade

avastamise, testimise ja nõuetele vastavuse kontrolli ning koostab testimisega seonduvat

dokumentatsiooni.

5.10. Täitja projekti meeskonnaliikmed raporteerivad töödele kuluvaid tunde igapäevaselt

tellija Jira keskkonnas.

5.11. Kumbki pool peab tagama, et tema projektijuhil on vajalik ajaressurss ning kõik vajalikud

õigused ja pädevus vastava poole nimel tegutseda.

5.12. Meeskonna 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 parimatele praktikatele.

5.13. Vajadusel täpsustavad pooled hankelepingu sõlmimisel projektimeeskonna liikmete

rollid ja nende ülesanded.

5.14. Tellija juures töötab projekti juhtrühm, mis jälgib raamlepingu alusel sõlmitud lepingute

täitmist tervikuna. Vajadusel annab täitja esindaja tellija korraldusel juhtrühmale

ülevaate projekti hetkeseisust ja võimalikest probleemidest.

6. Aruandlus

6.1. Töötunnipõhiselt tasustavate tellimuste puhul on täitja meeskond kohustatud esitama

tööaja aruandeid vastavalt tellija poolt nimetatud tingimustele.

6.1.1. Tellija nimetab tööaja aruannete esitamiseks kasutatava töövahendi (nt Jira) lepingus ja

tagab selle kättesaadavuse.

6.1.2. Tööaja aruande esitab täitja iga meeskonnaliige isiklikult (iga meeskonnaliige täidab

aruandevormid ise).

Lisa 5

6.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.

6.1.4. Nõuded ajaaruande detailsusele (täidetud tööülesannete kirjeldusele) kehtestab tellija

projektijuht.

7. Tasustamine

7.1. Töötunnipõhiste tellimuste puhul kuuluvad tellija poolt 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) ega transpordile kuluvat aega.

7.1.1.1. Täitja peab lähtuma Vabariigi Valitsuse määrusest nr 362, vastu võetud 15.11.2000

(Kuvariga töötamise töötervishoiu ja tööohutuse nõuded), võimaldades täitja

meeskonnaliikmetele puhkepause nõutaval määral.

7.1.1.2. Täitja peab lähtuma kehtivast töölepingu seadusest. Täitja peab planeerima

meeskonnaliikmete töökoormuse selliselt, et tööülesanded täidetakse

nominaaltöötundide piires. Ületunnitöö rakendamine täitja meeskonnas toimub

kokkuleppel tellijaga.

7.1.2. Tellija ei tasusta (ei aktsepteeri ajaaruannetes) ajakulu, mis on seotud täitja spetsialistide

oskusteabe täiendamisega, mis on vajalik 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. Uute 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 kaasneb tööülesannete täitmiseks uue oskusteabe omandamisega.

7.1.4. Tellija ei tasusta aega, mis kulub täitjal korduvate (esineb vähemalt kaks korda) vigade

lahendamiseks (näiteks samaliigiliste probleemide kordumine lähtekoodis vaatamata

täitja varasemale tagasisidele koodiülevaatuste käigus).

7.1.5. Tellija ei tasusta aega, mis kulub täitjal pakkumuse koostamiseks ja esitamiseks.

7.1.6. Tellija eeldab, et täitja arvestab meeskonnaliikmete vahetumisel selle mõjuga

tööviljakusele (produktiivsusele) ja kajastab seda ajaaruannetes.

7.1.7. Täitja peab arvestama, et meeskonnaliikme vahetamisel või täiendava liikme lisamisel

rakendub vajadusel sisseelamise koefitsient 0,5 üheks kuuks (arveldamisel).

7.2. Akteerimisele kuulub töö, mis on edukalt läbinud tellija poolse vastuvõtutestimise.

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 nimetatud keskkonna

kättesaadavuse.

8.1.1. Dokumentide hoidmise struktuur, selle täiendused ja muudatused lepitakse kokku poolte

projektijuhtide vahel.

8.1.2. Dokumentide lisamise, muutmise ja kustutamise reeglid lepitakse kokku poolte

projektijuhtide vahel, kes tagavad kokkulepitud reeglite järgimise oma meeskonna

poolel.

Lisa 5

8.2. Konfiguratsiooni- ja arendustööde ülesannete suunamiseks ja jälgimiseks, vigade ja

probleemide haldamiseks ning tööaja arvestuseks kasutatakse tellija poolt nimetatud

töövahendit (nt Jira).

8.2.1. Tellija võib lisaks töövahendis registreerimisele viidata leitud vigadele ka e-kirja vm

suhtluskanali vahendusel, kuid vea/tööülesandega tegelema hakkamise eelduseks täitja

poolt on vea registreerimine töövahendis ning lepingus toodud nimetatud tööde eest

vastutava (tellija) isiku poolt antud korraldus tööde alustamiseks.

8.3. Lepingu täitmisega seotud muu (igapäevane) teabevahetus toimub e-kirja, telefoni või

Teams’i teel või koosoleku vormis. Poolte projektijuhid tagavad teabe edastamise ja

saamise.

8.4. Teabevahetuse vormid ja reageerimisajad:

8.4.1. Koosolek – koosoleku kokkukutsumisel lepitakse kokku koosoleku läbiviimise asukoht

(kohapeal või Teams’is), 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.4.1.1. Koosoleku toimumise järel koostatakse memo (vastutab koosoleku korraldaja).

Otsused protokollitakse ja kantakse dokumendihalduskeskkonda (Confluence), kuhu

kantakse vajadusel ka kinnitused. Kui koosolekul osalenud ei esita kahe tööpäeva

jooksul pretensiooni memo sisu osas, loetakse, et isik nõustub memos toodud

seisukohtade ja/või otsustega ja sellega, et eelnimetatud on koosoleku käigus

fikseeritud memos toodud kujul.

8.4.2. E-kiri – kasutatakse igapäevase suhtluskanalina (v.a kui konkreetset infot tuleb vastavalt

kodukorrale edastada täitja projektikeskkondade kaudu).

8.4.2.1. Kui e-kirjale oodatakse vastust, tuleb pealkirja real või kirja alguses see üheselt

määratleda. Kui e-kirjale ei ole võimalik anda selle aja jooksul sisulist vastust, tuleb

hiljemalt järgneva tööpäeva jooksul teha teatavaks sisulise vastuse andmise aeg.

8.4.3. Telefon, Teams – kasutatakse kiireloomuliseks ja operatiivseks suhtluseks. Telefoni

kaudu kokkulepitud olulised otsused tuleb kinnituseks fikseerida e-kirjaga või arutada ja

protokollida koosolekul.

8.4.3.1. Pooled säilitavad projekti e-kirjad, Teams’i vestlused projekti ja garantiiperioodi

kehtivuse ajal.

8.4.3.2. Poolte projektijuhid lepivad kokku e-posti, Teamsi gruppide ja/või töörühmade

loomise.

8.4.4. Stand-up kohtumine – Toimub tellija soovitud sagedusega täitja esindajate osalusel.

Stand-up kohtumisi ei toimu, kui täitjal ei ole tellija poolt esitatud tellimusi töös.

9. Nõuded dokumenteerimisele

9.1. Projekti dokumentatsioon peab olema terviklik ja terminoloogiliselt üheselt mõistetav.

9.2. Dokumentatsiooni kvaliteedi eest vastutavad poolte projektijuhid. Tellija projektijuhil on

õigus nõuda täitja 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.

9.3. Nõuded dokumenteerimisele on esitatud dokumendis „Nõuded infosüsteemi

dokumentatsioonile“. Tehnilise kirjelduse lisasid kohaldatakse vastavalt lepingule.

Lisa 5

10. Arendus-, test-, prelive- ja live keskkonnad

10.1. Arenduskeskkond asub tellija juures, kes tagab selle olemasolu ja toimimise.

10.2. Tellija testkeskkond koosneb vähendatud võimsusega komponentidest. Täitjal on tellija

testkeskkonnale lugemisõigusega ligipääs.

10.3. Tellija Prelive keskkond koosneb Live keskkonnale sarnastest komponentidest, sh

andmebaasid, rakendusserverid ning väliste süsteemide liidesed. Täitjal puudub

arendusteenuse osutamisel alaline ligipääs Tellija Prelive keskkonnale.

10.4. Live keskkonna konfiguratsioon lepitakse kokku tööde käigus. Täitjal puudub

arendusteenuse osutamisel ligipääs Tellija Live keskkonnale.

10.5. Pooled teevad mõistlikud pingutused tagamaks, et tellija testkeskkond sarnaneks Live

keskkonnale järgmises osas:

10.5.1. arvutivõrgu konfiguratsioon;

10.5.2. liidesed kolmandate süsteemidega;

10.5.3. andmemahud;

10.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.

10.6. Keskkondade ning nende ligipääsude haldamise ja tarnete paigalduse reeglid lepitakse

kokku projekti alguses.

11. Vea parandamine arenduse, juurutamise või garantiiperioodi käigus

11.1. Vigade menetlemise käigus registreeritakse kõik poolte leitud vead tellija poolt nimetatud keskkonnas (nt Jira).

11.2. Täitja analüüsib vea kirjeldust ning selgitab välja vea põhjuse.

11.3. Vigadele määrab tellija kriitilisuse astme ja neid asutakse parandama kriitilisuse järjekorras, lähtudes tellija poolt teatavaks tehtud prioriteetidest vigade parandamisel.

11.4. Garantiiperioodil asub täitja viga parandama vastavalt hankelepingus sätestatud tingimustele.

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 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 projektijuhid.

12.4. Kriisi tekkel informeerib tellija projektijuht koheselt projekti juhtrühma, kes rakendab

meetmed kriisi lahendamiseks.

12.5. Kui kriisi ei suudeta projekti juhtrühma poolt likvideerida, kasutatakse täitja ja tellija

vahelises lepingus sätestatud meetmeid.

1

RAAMLEPING NR 3-9/5065-1

Tervisestatistika infosüsteemi arendus- ja hooldustööd

Lepingu osa viitenumber 308846 001 000 000

Tervise ja Heaolu Infosüsteemide Keskus (edaspidi tellija), registrikood 70009770, aadress Pärnu

mnt 132, 11317 Tallinn, keda esindab põhimääruse alusel direktor Margus Arm

ja

Askend Estonia OÜ, registrikood 14133207, aadress Harju maakond, Tallinn, Kesklinna linnaosa,

Tartu mnt 80f, 10112, keda esindab seaduse ja põhikirja alusel juhatuse liige Vassili Ljahhovets,

edaspidi nimetatud ka eraldi pool või koos pooled, sõlmisid raamlepingu (edaspidi nimetatud

raamleping ning koos hankelepinguga ka leping) alljärgnevas:

1. Raamlepingu eesmärk ja ese

1.1. Tellija poolt korraldatud riigihanke „Tervisestatistika infosüsteemi arendus- ja hooldustööd“

(riigihanke viitenumber 308846) alusel sõlmitud raamlepingu eesmärk on kokku leppida,

kuidas toimub raamlepingu kehtivuse ajal raamlepingu esemeks olevate tööde tellimiseks

hankelepingute sõlmimine tellija ning täitja vahel.

1.2. Raamlepingu esemeks on tervisestatistika infosüsteemi arendus- ja hooldustööd (edaspidi

tööd), mida täitja kohustub teostama lähtudes raamlepingu alusel sõlmitud hankelepingutes

kokku lepitud tingimustest. Teostatavad tööd on toodud tehnilises kirjelduses.

1.3. Raamleping ei kohusta tellijat töid tellima. Raamleping kohustab täitjat tellija tellimuste

alusel pakkumusi esitama. Neid pakkumusi käsitletakse täitja poolt riigihankes esitatud

pakkumuse täiendustena RHS § 30 lg 3 tähenduses.

1.4. Raamleping kehtib sõlmimisest alates 48 kuud või raamlepingu lõpetamiseni või

raamlepingu mahu täitumiseni.

1.5. Raamlepingu täitmist rahastatakse riigieelarvest ja/või struktuurfondidest ja/või

välisrahastusest ja/või muust rahastusest.

2. Üldtingimused

2.1. Raamlepingu juurde kuuluvateks lahutamatuteks osadeks loetakse kõik lisad ja riigihanke

alusdokumendid ning täitja riigihankes esitatud pakkumus ja pooltevahelised kirjalikud

teated.

2.2. Lepingu täitmisel lähtutakse lisaks raamlepingule hankelepingu tingimustest ja kodukorra

regulatsioonist selle olemasolul. Tellija võib kodukorra kehtestamisel teha kodukorda

muudatusi, teavitades täitjat kodukorra muutmisest.

2.3. Raamlepingu ja hankelepingu tingimuste erinevuse korral lähtutakse esmajärjekorras

kooskõlalise tõlgendamise põhimõttest, mille kohaselt tuleb tingimusi tõlgendada selliselt,

et need oleksid samaaegselt kohaldatavad. Juhul kui selline tõlgendamine ei ole võimalik

2

ning esineb lahendamatu vastuolu, kohaldatakse hankelepingu tingimust. Kui lepingu lisas

esinev tingimus on vastuolus lepingu tingimusega, loetakse ülimuslikuks lepingu tingimus.

2.4. Raamlepingu täitmise käigus võib kokku leppida täiendavaid tingimusi, kui need on vajalikud

välisvahendite rakendamisest tulenevate nõuete täitmiseks.

2.5. Juhul, kui hankelepingu alusel teostatavaid töid rahastatakse välisvahenditest, on täitjal

kohustus järgida hankelepingus teatavaks tehtud välisvahendite kasutamisest tulenevaid

nõudeid, sh kasutada programmi tingimustes nõutud sümboolikat.

2.6. Pooled teevad raamlepingu ja selle alusel sõlmitud hankelepingutetäitmiseks ja nende

eesmärkide saavutamiseks koostööd. Pooled kohustuvad tegema kõik vajalikud pingutused,

et täita hankeleping õigeaegselt ja vastavalt kokkulepetele.

2.7. Pooled võivad kokkuleppel kaasata tööde kvaliteedi või tööde vastuvõtmise hindamiseks

mõlema poole poolt aktsepteeritud sõltumatu eksperdi või audiitori. Kui tellija hinnang

tööde kvaliteedile või tööde vastuvõtmisele osutub ekspertiisi tulemusel põhjendamatuks,

hüvitab tellija ekspertiisikulud. Kui ekspertiis kinnitab tellija hinnangut kvaliteedile või tööde

vastuvõtmisele, jäävad ekspertiisikulud täitja kanda.

2.8. Kui lepingu täitmisel tekivad täitja ja tellija vahel erimeelsused, lahendatakse need koostöös,

lähtudes lepingu eesmärkidest ning tagades võrdsuse ja õiguspärase kohtlemise

põhimõtteid mõlema poole huvide tasakaalustatud arvestamisega. Kui pooled mõistliku aja

jooksul koostöös kokkuleppele ei jõua, on tellijal õigus lähtuda lepingu täitmisel oma

eesmärkidest, järgides seejuures hea usu ja heauskse koostöö põhimõtteid.

2.9. Poolel on õigus teha teisele poolele ettepanekuid hankelepingute täitmise kvaliteedi

tõstmiseks. Kui pool on esitanud teisele poolele hankelepingu täitmisega seotud küsimuses

päringu, on pool kohustatud sellele sisuliselt reageerima (asjakohast tagasisidet andma)

võimalikult kiiresti, kuid hiljemalt 3 tööpäeva jooksul, v.a juhul kui pöördumine nõuab

täiendavat analüüsi või info süstematiseerimist.

2.10. Pooltel on kohustus osa võtta töökoosolekutest töö käigus tekkinud probleemide

lahendamiseks ja infovahetuseks tellija juures kohapeal või virtuaalselt. Garantiitööde

töökoosolekutel osalemist tellija ei tasusta.

1.1. Lepingu täitmise keel on eesti keel, muuhulgas on see ka riigihankemenetluse, pakkumuste

esitamise ettepanekute, pakkumuste, hankelepingute ja nende sõlmimise, töökoosolekute

jm suhtluse ning tööde dokumenteerimise keel.

1.2. Nõuded dokumentatsioonile ja kasutusjuhenditele tulenevad tellija poolt kodulehel

avaldatud vastavatest nõuetest.1

3. Poolte õigused ja kohustused

3.1. Täitja kohustub:

3.1.1. teostama tööd hankelepingus kokkulepitud tingimustel ja ulatuses, sh tagama tööde

õigeaegse alustamise, teostamise, valmimise ja tellijale üleandmise;

3.1.2. tagama hankelepingu täitmiseks vajalike ressursside olemasolu, tööde teostajate

kõrge professionaalse taseme ning vajaliku tehnoloogia ja metoodikate väga hea

tundmise, omama lepingu täitmiseks sobivaid keskkondi, koos kõige sinna juurde

kuuluvaga, sh kasutatava tarkvara litsentsid, või kasutama tellija olemasolevaid

jagatud keskkondi;

1 https://www.tehik.ee/arendusjuhendid

3

3.1.3. võtma jätkuarenduste puhul litsentsimudeli valikul arvesse tellija olemasoleva

tarkvara litsentsitingimusi või juhinduma tellija vajadustest;

3.1.4. tegema koostööd kolmandate osapooltega pidades silmas tellija vajadusi (nt

äritellijaga, teiste tellija arenduspartneritega jne);

3.1.5. teavitama viivitamatult tellijat lepingu täitmist takistavatest asjaoludest, mis

segavad hankelepingu nõuetekohast täitmist;

3.1.6. juhinduma tellija suunistest ja eeskirjadest lepingu eesmärkide saavutamisel,

pöördudes selleks vajadusel tellija poole;

3.1.7. arvestama, et hankelepingu täitmiseks võib olla vajadus muuta ja täiendada

olemasolevat koodi ning tagama protsesside ja funktsionaalsuse tervikluse pärast

koodi muutmist või täiendamist;

3.1.8. kasutama tellija tööajahalduse ja projektijuhtimiskeskkondi, mis on täitjale

kättesaadavaks tehtud;

3.1.9. töötunni põhiselt tellitavate tööde puhul esitama tellijale tööde teostamise

ajaaruandeid (iga meeskonnaliige isiklikult);

3.1.10. tagama rakenduste hooldusteenuste osutamiseks valmisoleku ja omapoolse abi kuni

veaolukorra kõrvaldamiseni vastavalt tehnilises kirjelduses toodud tingimustele,

vajadusel ka väljakutse korras kohapeal;

3.1.11. osutama tellijale teostatud töö osas tuge, sh pakkuma konsultatsiooni ja koolitusi

kuni garantiiaja lõpuni;

3.1.12. teostama tööd kvaliteetselt ning vastavalt valdkonna headele tavadele ja praktikale.

Tellija eeldab, et täitja on tarkvaraarenduse valdkonna professionaal, kes saab aru

ning võtab teadlikult enda kanda hankelepingu funktsionaalsete ja

mittefunktsionaalsete nõuete täidetavuse ja tulemuse saavutatavuse riski. Sellest

tulenevalt laieneb täitjale ka selliste tööde tegemise kohustus, mida ei ole

hankelepingus kokku lepitud, kuid mis oma olemusest lähtuvalt kuuluvad

hankelepinguga seotud tööde hulka. Nimetatud tööde teostamise vajadusest

teavitab täitja viivitamatult tellijat ning teostamisele heakskiidu saamisel teostab

täitja kirjeldatud tööd hankelepingu täitmise raames;

3.1.13. viivitamata teavitama tellijat täitja vastu suunatud küberintsidendist, mis puudutab

käesoleva raamlepingu ja/või selle alusel sõlmitud hankelepingute täitmist või mis

võib mõjutada tellija andmeid, süsteeme või teenuseid, ning esitama tellija nõudmisel

tellijale küberintsidendi raporti;

3.1.14. teavitama kirjalikku taasesitamist võimaldavas vormis oma mistahes huvist, mis võib

põhjustada lepingu täitmisel huvide konflikti tekkimist.

3.2. Täitjal on õigus:

3.2.1. saada lepingu täitmise eest hankelepingus kokkulepitud ulatuses ja korras tasu;

3.2.2. kasutada lepingu täitmisel alltöövõtjaid, kooskõlastades selle eelnevalt kirjalikult

tellijaga. Alltöövõtjate tegevuse ja tegevusetuse eest vastutab tellija ees täitja;

3.2.3. anda arve esitamise õiguse üle kolmandale isikule lepingu muudatust sõlmimata, kui

ta on tellijale esitanud sellekohase teate.

3.3. Tellija kohustub:

3.3.1. tasuma vastu võetud tööde eest kokkulepitud ulatuses ja korras;

3.3.2. tagama lepingu täitmiseks täitjale ligipääsu vajalikule teabele ja keskkondadele;

4

3.3.3. tagama lepingu täitmiseks oluliste tellija hallatavate keskkondade olemasolu ja

toimimise.

3.4. Tellijal on õigus:

3.4.1. kontrollida igal ajal lepingu täitmist ja anda täitjale selleks kohustuslikke suuniseid;

3.4.2. keelduda osaliselt või täielikult tasu maksmisest, kui täitja ei teostanud

nõuetekohaseid töid kokku lepitud tähtajaks ja täitja poolne rikkumine ei ole

objektiivselt põhjendatud;

3.4.3. kaasata lepingu täitmiseks tellija teisi riigiasutusi informatsiooni andmisel, maksja ja/

või töö kvaliteedi kontrollija rollis. Kolmanda osapoole kaasamine tellija poolt ei ole

käsitletav raamlepingu muutmisena riigihangete seaduse mõttes.

4. Raamlepingu hind ja maksimaalne võimalik kogumaksumus

4.1. Raamlepingu kehtivuse ajal on ühe töötunni maksimaalne hind käibemaksuta vastavalt

pakkumusele 38,00 (kolmkümmend kaheksa eurot ja 00 senti) eurot.

4.2. Raamlepingu maht on maksimaalselt 2 500 000 (kaks miljonit viissada tuhat) eurot

käibemaksuta, mis summeeritakse raamlepingu piirides tehtud tellimuste ehk sõlmitud

hankelepingute alusel. Raamleping kaotab kehtivuse ja selle alusel ei ole lubatud uusi

hankelepinguid sõlmida, kui maksimaalne võimalik maksumus on täitunud.

4.3. Täitjal on õigus esitada e-arve pärast tööde aktiga vastu võtmist, kui hankelepingus ei ole

kokku lepitud teisiti. Arvel tuleb märkida riigihanke nimetus ja viitenumber, lepingu osa

viitenumber, lepingu number ja kontaktisiku andmed.2

4.4. Arve tasumiseks annab täitja minimaalselt tähtaja 21 kalendripäeva alates arve laekumisest.

5. Täitja meeskond

5.1. Lepingu täitmisel osalevad pakkumuses esitatud meeskonnaliikmed, 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, hanke tingimustele vastava

meeskonnaliikmega. Täitja peab meeskonnaliikme asendamist tellijale kirjalikku

taasesitamist võimaldavas vormis põhjendama.

5.2. Täitja võib tellija kirjalikku taasesitamist võimaldaval nõusolekul kaasata täiendavaid

meeskonnaliikmeid. Täiendavad meeskonnaliikmed peavad vastama riigihankes seatud

nõuetele.

5.3. Kui hankemenetluse käigus hinnati meeskonnaliikme kogemusi ja hinnatud meeskonnaliige

asendatakse või meeskonda täiendatakse, peab asendav või lisatav isik hindamisel

samaväärselt punkte koguma. Asendada või täiendada on lubatud tellija kirjalikku

taasesitamist võimaldaval nõusolekul.

5.4. Täitja asendab tellija nõudmisel ja määratud tähtajaks meeskonnaliikme, 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 täitmist. Täitja kannab kõik asendusega kaasnevad kulud.

Täiendavalt kaasatud meeskonnaliikmed peavad vastama rollile seatud hanketingimustele.

2 Välisriigi pakkujad võivad esitada arve pdf-vormingus aadressil [email protected], kui e-arve esitamine ei ole võimalik.

5

5.5. Täitja garanteerib riigihankes isikuliselt mitte välja toodud meeskonnaliikmete

olemasolu/kättesaadavuse/kaasatavuse ja vastavuse riigihankes nõutud

kvalifikatsioonile/varasemale töökogemusele ning esitab tööde teostajad nimeliselt

hankelepingu sõlmimisel.

5.6. Tellija võib hankelepingu sõlmimisel määrata, milliseid rolle on vajalik konkreetse

hankelepingu täitmiseks kaasata. Lisaks võib hankelepingu sõlmimisel tellida lisaks

riigihankes nõutud meeskonnaliikmete rollidele uusi rolle, kui see on tingitud tellitavate

tööde iseloomust ja tööde efektiivseks teostamiseks on otstarbekas kaasata teistsuguse

kompetentsiga meeskonnaliikmeid. Sellisel juhul määratakse uue meeskonnaliikme rolli

kompetentsi nõuded tellimuses.

5.7. Meeskonda võib vajadusel lülitada ka muude rollide täitjaid, kuid nende kompetents ei kuulu

hindamisele ega vastavuse kontrollimisele, nt noorem-arendaja, noorem-analüütik,

dokumenteerija jne. Raamlepingu täitmisel vastavustingimustele mittevastava töötaja

kaasamine on lubatud ainult hankija kirjalikku taasesitamist võimaldavas vormis esitatud

nõusolekul ning tingimusel, et ta ei asenda põhimeeskonna liiget, vaid on kaasatud

abitööjõuna või spetsiifilise eksperdina. Spetsiifilise eksperdi kaasamise vajadus peab olema

tingitud hankija poolt tellitud töö olemusest ning olema põhjendatud. Selliselt muudes

rollides kaasatud isikute poolt teostatud tööde eest tellija eraldi tasu ei maksa.

5.8. Kõigile, s.h täiendavalt kaasatud isikutele rakenduvad kõik konfidentsiaalsusnõuded.

6. Tööde tellimine

6.1. Tööde teostamise aluseks on sõlmitud hankeleping. Hankeleping loetakse sõlmituks nii

tellimuse esitamisel ja tellija poolt pakkumuse aktsepteerimisel kui ka hankelepingu

sõlmimisel konkreetsel vormil. Pakkumusena mõistetakse selles punktis pakkumuse

täpsustamist RHS § 30 lg 3 tähenduses.

6.2. Tellimuste esitamiseks ja hankelepingu sõlmimiseks pöördub tellija otse täitja poole,

esitades hankelepingu sõlmimise tingimused.

6.3. Tööde teostamine toimub tellimuses esitatud tehnilise kirjelduse alusel, milles on määratud

tööde sisu ja üle antavad tulemid (tööde loetelu), võimalusel tööde maht, ajalised ja

eelarvelised piirangud jm olulised tingimused. Tellimuses võib tööde teostamine ja üle

andmine olla nõutud etapiti, samuti võib tellimuses esitada etappide kaupa teostatavatele

töödele erinevaid tingimusi.

6.4. Tööde tellimiseks esitab tellija täitjale kirjalikku taasesitamist võimaldavas vormis tellimuse,

välja arvatud jooksva konsultatsiooni vajaduse korral. Tellimus on täitjale esitatav kirjalikku

taasesitamist võimaldavas vormis pöördumine tööde teostamiseks, kas tellimuskirjana,

mille järel sõlmitakse hankeleping kindlal vormil või tööde halduskeskkonna (nt Jira) kaudu.

6.5. Tellija annab mõistliku aja pakkumuse esitamiseks, arvestades tellitavate tööde keerukust ja

pakkumuse esitamiseks vajalikku aega. Pakkumuse esitamisel tuleb järgida kõiki tellimuses

esitatud nõudeid.

6.6. Täitja hindab võimalusel tellimuse alusel töö mahtu ja esitab tellimuses määratud tähtajaks

hinnapakkumuse töö teostamiseks ja/või vajadusel muud tellimuses nõutud andmed

(pakkumus). Täitjal ei ole õigust pakkumuse esitamisest keelduda/loobuda.

6

6.7. Kui pakkumus ei vasta tellimuse tingimustele või ei ole muul põhjusel vastuvõetav, on tellijal

õigus see tagasi lükata. Tellija ei ole kohustatud pakkumust tagasi lükkama, eelkõige kui

pakkumuse mittevastavus tellimuse tingimustele ei ole sisuline või kui tellija leiab, et

olenemata mittevastavusest on pakkumus talle vastuvõetav (nt kui pakkumuse sisuks on

raamlepingu ja tellimuse esemega ühilduv, kuigi tellimuses mittesisaldunud alternatiivne

lahendus vms). Ühe töötunni maksimaalset hinda ületavat töötunni hinda sisaldava

pakkumuse lükkab tellija tagasi.

6.8. Tellijal on õigus esitatud pakkumus tagasi lükata ja otsustada hankelepingut mitte sõlmida

või vastavalt raamlepingule esitatud tellimus kehtetuks tunnistada ka siis, kui:

6.8.1. tellija vajadus tellimuse täitmiseks kaob või muutub;

6.8.2. ületab eeldatavat maksumust või;

6.8.3. tellija ei saa välisvahenditega seotud hankelepingu sõlmimiseks heakskiitu

täistaotlusele.

6.9. Hankeleping mahuga alates 20 000 eurot käibemaksuta sõlmitakse alati hankelepingu

vormil ja allkirjastatakse poolte poolt. Täitja kohustub hankelepingu allkirjastama hiljemalt

3 tööpäeva jooksul hankelepingu allkirjastamiseks saatmisest.

7. Tööde üleandmine ja vastuvõtmine

7.1. Hankelepingus määratakse vajadusel tööde üleandmise ja vastuvõtmise eritingimused,

nõuded testimisele, lepingu täitmise etapid, kord, tähtajad, sh testimise tähtajad või muud

lepingu täitmiseks vajalikud kokkulepped.

7.2. Täitja annab tööd üle hiljemalt hankelepingus kokkulepitud tähtaegadel ja tingimustel. Koos

töödega antakse üle nõuetekohane dokumentatsioon, kommenteeritud lähtekood,

intellektuaalomandi õigused ja muu hankelepingus kokkulepitu.

7.3. Tööde tulemused ja vajadusel tööde teostamise käik dokumenteeritakse ning hallatakse

tellija dokumendihalduskeskkonnas ja/ või koodihalduskeskkonnas (näiteks wiki, gitlab).

7.4. Tarne on hankelepingu alusel teostatud tööde paketina üleandmine, mis on toodangusse

paigaldamiseks korrektselt konfigureeritud ja koodihalduskeskkonda lisatud. Täitja lisab

tarne kirjelduse ja spetsifikatsiooni dokumendihalduskeskkonda. Täitja esitab tarne kohta

tarneteatise, lisades tarnega seotud testimise juhendi ja vastavalt hankelepingule

automaattestid.

7.5. Üleantavad tööd tuleb täitja poolt enne tellijale üle andmist testida, koostada testiraportid

ja testilood.

7.6. Täitja annab tööd üle omalt poolt allkirjastatud aktiga. Hooldustööde teostamisel tuleb koos

aktiga esitada ajaaruanne. Aktis peavad tehtud hooldus- ja arendustööd olema teineteisest

eristatud.

7.7. Tellija võtab tööd vastu akti allkirjastamisega pärast edukat vastuvõtutestimist.

7.8. Tööd loetakse nõuetekohaselt teostatuks, kui tööd vastavad hankelepingule,

vastuvõtutestid on vigadeta läbitud ja tööd on aktiga tellija poolt vastu võetud.

7.9. Tellija võib tööd vastu võtta, kui töödes esineb üksikuid ja tellija jaoks väheolulisi pisivigasid,

mis fikseeritakse aktis. Tellija poolne pisivigadega tööde vastuvõtmine ei vabasta täitjat

kohustusest vead kõrvaldada ning üle anda vigadeta tööd. Tellija määrab mõistliku tähtaja

pisivigade parandamiseks.

7.10. Tellijal on õigus keelduda tööde vastuvõtmisest kui tööd ei vasta esitatud nõuetele või

töödes esineb muid vigu.

7

7.11. Kui tellija esitab vastuväited töödele, peab täitja tööd parandama tellija poolt määratud

mõistliku tähtaja jooksul. Kui täitja ei ole tellija antud tähtaja jooksul kõrvaldanud avastatud

vigu, võib tellija tööd ise parandada või lasta seda teha kolmandatel isikutel ja nõuda täitjalt

selleks tehtud mõistlike kulutuste hüvitamist tingimusel, et puudused on objektiivselt

tuvastatavad ja nende eest vastutab täitja, tellija vastuväited ja parandamisvajadus on

põhjendatud. Juhul, kui hiljem selgub, et puuduste eest ei vastuta siiski täitja, kannab

vastavad kulud tellija.

7.12. Alates teisest kordustestimisest võib tellija kordustestidega seotud kulutused (tellija

kulutatud tööaeg ja/ või tellija testimispartnerite poolt esitatud arvete alusel) täitjalt välja

nõuda või tasaarvestada, kui kordustestimise vajadus oli tingitud puudustest, mille eest

vastutab täitja.

8. Intellektuaalne omand

8.1. Täitja kinnitab raamlepingu ja selle alusel sõlmitud hankelepingute allkirjastamisega, et talle

kuuluvad lepingu täitmiseks vajalikud autoriõigused, litsentsid ja muud intellektuaalse

omandi õigused, mis on vajalikud raamlepingu ja hankelepingute järgsete tööde

teostamiseks ja õiguste loovutamiseks tellijale ning nende suhtes ei ole õigusi ega nõudeid

kolmandatel isikutel.

8.2. Tasu intellektuaalse omandi varaliste õiguste loovutamise ja litsentsi andmise eest sisaldub

hankelepingu hinnas.

8.3. Täitja loovutab tellijale lepingu täitmise käigus loodud kõik mistahes vormis tööde osad, mis

puutuvad tööde teostamisse, 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 hankelepingu

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 hankelepingu täitmise käigus loodava töö

kontrollimiseks, testimiseks ning süsteemi paigutamiseks ka ajal, mil tööd on

vastuvõtutestimiseks üle antud, kuid ei ole veel tellija poolt aktiga vastu võetud.

8.6. Täitja on kohustatud tagama intellektuaalse omandi õiguste (eeskätt autoriõiguste)

olemasolu ja kehtivuse, samuti nende ülemineku tellijale viisil, mis võimaldab tellijal

hankelepingu lõppedes üle võtta täitja funktsioonid.

8.7. Täitja kohustub lahendama kõikvõimalikud lepingujärgsete töödega seotud intellektuaalse

omandi õigustest tekkivad vaidlused kolmandate isikute või oma töötajate või

koostööpartneritega, v.a. juhul, kui tarkvara või tarkvara osa litsentside soetamise kohustus

oli tellijal või kolmandal osapoolel. Juhul, kui eeltoodust tekib tellijale rahaline või muu

kohustus või juhul, kui tellija on kohustatud lõpetama hankelepingu alusel teostatud ja

8

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.8. Kõik tellijale kaasnevad otsesed ja kaudsed kahjud, mis tulenevad sellest, et kolmandal isikul

on või väidetavalt on varalisi või mittevaralisi intellektuaalsest omandist tulenevaid õigusi

hankelepingu alusel üle antavate intellektuaalse omandi objektide suhtes, kannab täitja.

8.9. Selles alapeatükis kirjeldatud õigused ja litsentsid loetakse tellijale lõplikult üle läinuks pärast

töö vastuvõtmist.

9. Garantii

9.1. Täitja annab hankelepingu alusel teostatud töödele garantii 12 kuud. Garantii hakkab

kehtima alates tööde vastuvõtmisest aktiga.

9.2. Garantiiga on hõlmatud kõik garantii tähtaja jooksul tarkvaras ilmnevad vead ja

mittevastavused, mis ei ole tekkinud tellija või kolmandate osapoolte tegevuse tagajärjel.

Garantiiga on hõlmatud ka kõigi tööde muudatused ja modifikatsioonid, mis on tehtud täitja

poolt ja mis ei ole oluliselt muutnud varasemalt tehtud tööd.

9.3. Täitja kõrvaldab garantii kehtivuse ajal töödes avaldunud vead ja mittevastavused tasuta,

sealhulgas uuendab või asendab kõik seonduvad dokumendid.

9.4. Täitja on kohustatud garantii korras teostama eelkõige järgmist:

9.4.1. vea ilmnemisel vea otsimine, lokaliseerimine, veaolukorrale lahenduse leidmine ja

vea parandamine;

9.4.2. vea põhjuste analüüs ja ettepanekute tegemine ennetavate meetmete kasutusele

võtuks kirjalikku taasesitamist võimaldavas vormis;

9.4.3. vea parandamisega seoses paigaldamise ja seadistamise tugi ning sellega seotud

konsultatsioonid.

9.5. Tellija määrab võimalusel, milline on vea kriitilisuse aste või kas tegemist on muu

garantiikohustusega hõlmatud puudusega ning võib määrata vea kõrvaldamiseks tähtaja,

lähtudes hankelepingus fikseeritud vigade kriitilisuse astmetest.

9.6. Reageerimis- ja lahendusaeg hakkab kulgema tellija poolt teate välja saatmise hetkest.

9.7. Kui tegemist on kriitilise veaga (blocker ja critical), teatab täitja hiljemalt 24 tunni jooksul

alates kriitilise vea kohta teate saamisest oma esialgse hinnangu kriitilise vea võimalike

põhjuste kohta ning juhtnöörid, kuidas tööde tulemit edasi kasutada. Kriitiline viga peab

saama kõrvaldatud hiljemalt 3 tööpäeva jooksul alates vea kohta teate saamisest, kui pooled

ei ole kokku leppinud teisiti.

9.8. Kui tegemist on häiriva vea (major), pisivea (minor) või muu garantiikohustusega hõlmatud

puudusega, teatab täitja hiljemalt 48 tunni jooksul alates selle kohta teate saamisest oma

esialgse hinnangu häiriva vea, pisivea või muu puuduse võimalike põhjuste kohta ning

vajadusel juhtnöörid, kuidas tööde tulemit edasi kasutada. Häiriv viga peab saama

kõrvaldatud hiljemalt 10 tööpäeva jooksul alates vea kohta teate saamisest, kui pooled ei ole

kokku leppinud teisiti.

9.9. Kui täitja tõendab, et kõrvaldatud viga ei olnud garantiiga hõlmatud, hüvitab tellija täitja

kantud otsesed kulud seoses nimetatud vea kõrvaldamisega. Kulude hüvitamisel võetakse

aluseks hankelepingus, mille raames teostatud töödes on viga ilmnenud, fikseeritud tööde

teostamise ühe töötunni hind.

9

9.10. Tellija tagab täitjale kaasabi garantiikohustuse alla käivate vigade kõrvaldamisel

tellija võimekuse ja võimaluste piires.

9.11. Kui täitja ei suuda vigasid kokkulepitud tähtajaks kõrvaldada, võib tellija nimetatud vead ise

kõrvaldada või korraldada nende kõrvaldamise kolmanda isiku kaasabil, teavitades sellest

täitjale. Tellijal on õigus täitjalt nõuda kõigi kulutuste hüvitamist, mis tekkisid seoses

eelkirjeldatud viisil vea kõrvaldamisega, kui tegemist oli garantiiga hõlmatud veaga.

9.12. Garantii kaotab kehtivuse, kui tellija muudab lähtekoodi, välja arvatud tööde osale,

mida ei ole muudetud ning tellija suudab eristada lähtekoodis tehtud muudatusi.

10. Vastutus

10.1. Pool vastutab oma lepingulise kohustuse rikkumise eest, välja arvatud juhul, kui rikkumine

on vabandatav vääramatu jõu või muu objektiivse asjaolu tõttu. Nimetatud asjaolu esinemist

peab tõendama pool, kes sellele tugineda soovib.

10.2. Pool vastutab oma lepingulise kohustuse rikkumise eest, mis tuleneb tema poolt

hankelepingu täitmisse kaasatud isikute tegevusest.

10.3. Pool ei vastuta lepinguliste kohustuste rikkumise eest, mis tulenes teise poole kohustuste

rikkumisest või kolmandate isikute tegevusest või tegemata jätmistest. 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, fikseeritakse tööde üleandmise

tähtaja pikenemine vastava aja võrra. Nimetatud asjaolu esinemist peab tõendama pool, kes

sellele tugineda soovib.

10.4. Kohustuse rikkumisel on teisel poolel õigus kasutada kõiki seadusest või lepingust

tulenevaid õiguskaitsevahendeid vastavalt võlaõigusseadusele.

10.5. Poolte rahaline koguvastutus on piiratud raamlepingu kogumaksumusega, kuid see

piirang ei kehti süülisel rikkumisel, sh süülisel rikkumisel seoses intellektuaalomandiõiguse

või andmekaitsealaste kohustustega.

10.6. Tasu maksmisega viivitamisel on täitjal õigus nõuda viivist võlaõigusseaduses

sätestatud määras konkreetse töö eest maksmisele kuuluvast tasust iga tasumisega

viivitatud kalendripäeva eest. Viivise maksimaalne määr on 25% konkreetse töö eest

tasumisele kuuluvast kogusummast. Viivise nõue tuleb esitada allkirjastatult.

10.7. Täitja poolse lepinguliste kohustuste rikkumisena käsitletakse eeskätt olukorda, kus üle

antud tööd ei vasta osaliselt või täielikult lepingu tingimustele, sh kokkulepitud hooldus- või

veaparandustööde tingimustele või esineb muid täitja poolseid lepingu rikkumisi.

10.8. Kui täitja rikub lepingulist kohustust, on tellijal õigus nõuda leppetrahvi tasumist,

mille suuruseks on kuni 200 eurot iga rikkumises oldud kalendripäeva eest, kuid mitte

rohkem kui 25% hankelepingu kogumaksumusest. Kui lepingu täitmine on kokku lepitud

etappide kaupa, siis mitte rohkem kui 25% etapi kogumaksumusest.

10.9. Juhul kui täitja poolsetest viivitustest tingitult ei ole tööde kasutuselevõtt enam

realistlik või vajalik, on tellijal õigus hankelepingust taganeda vastavalt võlaõigusseaduse §

116 lõikele 1 ning täitja on kohustatud tegema juba makstud osa eest tellijale tagasimakse.

10.10. Lepingu olulise rikkumise korral on tellijal õigus esitada täitjale leppetrahvi nõue kuni

10 000 eurot iga rikkumise eest. Täitja poolse olulise hankelepingu rikkumise korral ei pea

tellija määrama täitjale lepingu täitmiseks võlaõigusseaduse §-s 114 nimetatud täiendavat

10

tähtaega ning tellijal on muu hulgas õigus hankeleping üles öelda või hankelepingust

taganeda.

10.11. Oluline rikkumine on lisaks võlaõigusseaduses sätestatule mh järgnev:

10.11.1. mõjuva põhjuseta hankelepingu sõlmimata jätmine või täitmisele mitte asumine;

10.11.2. valeinfo esitamine, s.h hankelepingu täitmise asjaolude (nt teostatud tööde ajaline

maht, töid tegelikkuses teostavad isikud jm) kohta;;

10.11.3. hankelepingu täitmiseks vajalike õiguste (sealhulgas load, litsentsid, intellektuaalse

omandi õigused) puudumine;

10.11.4. intellektuaalse omandi õiguste ja nende kasutamise tingimuste rikkumine;

10.11.5. 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;

10.11.6. konfidentsiaalsuskohustuse rikkumine;

10.11.7. lepingujärgsete kohustuste korduv (vähemalt kahel korral) täitmata jätmine;

10.11.8. tähtaegselt lepingu täitmata jätmine selliselt, et lepingu eesmärgi täitmine ei ole

enam tähtaegselt realistik ja/või täitja poolse tegevuse või tegevusetuse tõttu ei ole

võimalik enam kasutada hankelepingu rahastamiseks ettenähtud vahendeid;

10.11.9. lepingujärgsete kohustuste üleandmine kolmandale isikule vastavat

lepingumuudatust sõlmimata.

10.12. Töö vastuvõtmine tellija poolt ei vabasta ega vähenda täitja vastutust lepingu

rikkumise eest.

10.13. Kui täitja ei täida lepingut nõuetekohaselt ja selle alusel teeb rakendusasutus toetuse

vähendamise või tagasinõude otsuse, on tellijal õigus täitjalt tagasi nõuda

mitteabikõlbulikud kulud tagasimakse nõude ulatuses.

10.14. Leppetrahvi nõude kohustub tellija esitama mõistliku aja jooksul, kuid mitte hiljem kui

3 kuu jooksul alates päevast, mil tellija sai teadlikuks leppetrahvi nõude aluseks olevast

asjaolust. Leppetrahvi nõude vaidlustamine ei vabasta täitjat selle maksmise kohustusest

enne vastava kohtuotsuse jõustumist.

10.15. Täitja on kohustatud leppetrahvi tasuma 14 kalendripäeva jooksul alates tellija poolt

vastava nõude esitamisest, kui leppetrahvi nõudes ei ole määratud teisiti.

10.16. Tellijal on õigus tasaarvestada leppetrahvi summa täitjale töö teostamise eest

tasumisele kuuluvate maksetega. Tasaarvestamise korral ei rakendata leppetrahvi tasumise

kohustust.

11. Konfidentsiaalsuskohustus

11.1. Pooled kohustuvad vastastikku hoidma salajas ja mitte avaldama kolmandatele isikutele

ükskõik missugust konfidentsiaalseks peetavat informatsiooni, mis on saadud teiselt poolelt

lepingu täitmise käigus või muul viisil või juhuslikult.

11.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.

11

11.3. Juhul, kui lepingu täitmise raames osutub vajalikuks isikuandmete töötlemine, lepivad

pooled isikuandmete töötlemise tingimused kokku isikuandmete töötlemise lepingus,

juhindudes isikuandmete kaitse üldmääruse3 artiklis 28 kirjeldatust.

11.4. Konfidentsiaalne informatsioon on igasugune teave (sh ärisaladus, isikuandmed, lepingute

andmed, infosüsteemid, turvasüsteemide kirjeldused, riistvara ja tarkvara kirjeldused,

pakkumused, kasutatavad tehnoloogiad, spetsifikatsioonid jms), mis on saadud seoses

lepingu täitmisega 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.

11.5. Konfidentsiaalne informatsioon ei ole teave, mille avalikustamise kohustus tuleneb

õigusaktidest või mille avalikustamiseks pooled on andnud nõusoleku.

11.6. Täitjal ei tohi tegeleda lepingu osas avalike suhetega ning anda teateid pressile,

elektroonilisele meediale, üldsusele või teistele auditooriumidele, välja arvatud tellija

eelneval kirjalikku taasesitamist võimaldaval nõusolekul.

11.7. Pooled võivad edastada konfidentsiaalset informatsiooni ainult nendele isikutele, kes on

lepingu täitmisega seotud ja tagavad, et need isikud oleksid konfidentsiaalsuskohustusest

teadlikud. Pooled nõuavad nimetatud isikutelt selle kohustuse tingimusteta ja tähtajatut

täitmist.

11.8. Pooled ei kasuta lepingu täitmisel neile teatavaks saanud konfidentsiaalset informatsiooni

oma huvides ega muul eesmärgil, kui lepingu täitmiseks.

11.9. Täitja on teadlik, et lepingud ja kokkulepped on avalikud, v.a osades, mis on avaliku teabe

seadusest tulenevatel alustel määratud asutusesiseseks kasutamiseks või märgitud täitja

poolt ärisaladuseks.

11.10. Konfidentsiaalsuskohustuse rikkumise korral kohustub täitja hüvitama kõik kahjud,

mis sellise rikkumise tagajärjel tellijale või kolmandale isikule tekkisid, sõltumata sellest, kas

rikkumine pandi toime lepingu kehtivuse ajal või lepinguliste kohustuste lõppemise järgselt.

11.11. Konfidentsiaalsuskohustus kehtib tähtajatult.

13. Lepingute kehtivus

13.1. Lepingud jõustuvad sõlmimisel.

13.2. Hankelepingud tuleb sõlmida raamlepingu kehtivuse ajal, kuid võivad kehtida kauem.

Raamlepingu alusel sõlmitud hankelepingutele kohalduvad raamlepingu tingimused,

olenemata raamlepingu kehtivusest.

13.3. Lepingut muudetakse pooltevahelise kokkuleppega raamlepinguga samas vormis,

arvestades riigihangete seaduses toodut.

13.4. Kui mõni lepingu tingimus peaks osutuma osaliselt või täielikult kehtetuks või täitmisele

mittepööratavaks, ei mõjuta see teiste lepingu tingimuste kehtivust ning lepingu ülejäänud

tingimused jäävad kehtima ja täitmisele pööratavaks. Sel juhul võimalusel asendatakse

kehtetu või täitmisele mittepööratav tingimus õiguslikult kehtiva tingimusega, mis on sisult

võimalikult lähedane poolte kavatsustele ja kehtetu tingimuse majanduslikule mõjule.

13.5. Täitjal ei ole õigust lepingut või sellest tulenevaid kohustusi üle anda kolmandatele isikutele,

välja arvatud riigihangete seaduses ette nähtud alustel. Kolmas isik on mistahes füüsiline või

juriidiline isik, kes ei ole selle lepingu pooleks.

3 Euroopa Parlamendi ja Nõukogu määrus nr (EL) 2016/679.

12

13.6. Tellijal on õigus raamlepingu alusel sõlmitud hankeleping igal ajal üles öelda ilma põhjust ära

näitamata, teatades sellest täitjale ette vähemalt 30 päeva. Tellija võib sarnaselt üles öelda

ka raamlepingu, teatades sellest täitjale ette vähemalt 60 päeva. Lepingu lõppemisel ei ole

täitjal sellisel juhul õigust saada muud tasu, kui tasu nende tööde eest, mis on lepingu alusel

nõuetekohaselt teostatud, tellijale üle antud ja tellija poolt vastu võetud. Raamlepingu

ülesütlemine ei muuda automaatselt kehtetuks selle alusel varem sõlmitud hankelepinguid.

13.7. Tellijal on õigus leping ühepoolselt etteteatamistähtaega järgimata üles öelda riigihangete

ja/ või võlaõigusseaduses sätestatud alustel või kui täitja on oluliselt või korduvalt lepingut

rikkunud või juhul, kui täitja

13.7.1. suhtes on algatatud pankrotimenetlus;

13.7.2. pankrot on välja kuulutatud;

13.7.3. varad arestitakse;

13.7.4. finantsseisund halveneb tellija põhjendatud hinnangul oluliselt ja see muudab

hankelepingu nõuetekohase täitmise vähetõenäoliseks.

13.8. Lepingu lõppemisel mistahes alusel ja põhjusel on täitja kohustatud tellijale üle andma kogu

tööga seotud informatsiooni ja dokumentatsioon (nii digitaalselt kui paberkandjal, samuti

informatsiooni, mida ei ole salvestatud eelnimetatud infokandjatele). Üleantav info ja

dokumentatsioon peab olema süstematiseeritud. Täitja on kohustatud andma ammendavad

selgitused eelkirjeldatud informatsiooni haldamise ja kasutamise kohta, tehes seda tellija

nõudmisel kirjalikult.

14. Teadete edastamine ja kontaktisikud

14.1. Teadete edastamine toimub üldjuhul e-posti teel, lähtudes kodukorra tingimustest selle

olemasolul. E-posti teel, sh digitaalselt allkirjastatud dokumentide, saatmise korral loetakse

teade kättesaaduks kohale jõudmise teates märgitud kellaajal või e-kirjas näidatud saatmise

kellaajal.

14.2. Juhul, kui teate edastamisel on olulised õiguslikud tagajärjed, peab teade olema

edastatud digiallkirjastatult poole allkirjaõigusliku isiku poolt. Informatiivset teadet võib

edastada ka telefoni teel. Informatiivseks loetakse teade, millega ei kaasne õiguslikke

tagajärgi.

14.3. Kirjalik teade loetakse poole poolt kättesaaduks, kui see on üle antud allkirja vastu või kui

teade on saadetud postiasutuse poolt tähitud kirjaga poole poolt teatatud aadressil ja

postitamisest on möödunud 5 kalendripäeva.

14.4. Tellija kontaktisik(ud) on: Gerli Raadik, e-post: [email protected] või tema

asendaja;

14.5. Täitja kontaktisik(ud) on: Tatjana Solovjova, telefon 55549245, e-post:

[email protected] või tema asendaja;

14.6. Kontaktisikute pädevuses on anda teisele poolele vajaliku informatsiooni ja juhiseid

oma pädevuse piires, anda nõusolek meeskonnaliikme vahetamiseks, kontrollida teostatud

lepingu kvaliteeti, anda lepingu ese üle ja võtta vastu ning allkirjastada akt.

14.7. Kontaktisiku muutumisest teavitab pool kirjalikult teist poolt viivitamatult.

13

15. Lõppsätted

15.1. Raamlepinguga seotud vaidlused, mida pooled ei ole suutnud läbirääkimiste teel lahendada,

antakse lahendamiseks Harju Maakohtule.

15.2. Raamlepingule kohaldub Eesti õigus. Kuivõrd tegemist on segatüüpi lepinguga, siis

lisaks üldistele lepingulistele õiguskaitsevahenditele tuleb arvestada ka seadusest tulenevaid

õiguskaitsevahendeid, mida kasutatakse vastavalt rikkumise olemusele kas VÕS peatükk 35

või 36 alusel.

15.3. Raamlepinguga reguleerimata küsimustes või olukorras, kus mõni lepingu säte on vastuolus

seadusega, lähtutakse Eesti Vabariigis kehtivast seadusandlusest.

16. Lisad

16.1. Lisa 1 – Tehniline kirjeldus;

16.2. Lisa 2 – Hankelepingu projekt;

16.3. Lisa 3 – Tööde üleandmise ja vastuvõtmise akt;

16.4. Lisa 4 – Kodukord;

16.5. Lisa 5 – Isikuandmete töötlemise tingimused;

16.6. Lisa 6 - Pakkumus (ei allkirjastata koos lepinguga).

17. Poolte allkirjad

Tellija: Täitja:

(allkirjastatud digitaalselt) (allkirjastatud digitaalselt)

Versioon: 2.3

Dokument määrab kvaliteedi- ja mittefunktsionaalsed nõuded (MFN) uutele infosüsteemidele ning nende dokumentatsioonile. Dokumenti hoiavad ajakohasena Tervise ja Heaolu Infosüsteemide Keskuse (TEHIK) arhitektid.

Dokumenti tuleb vaadata kui arenduste kvaliteedi- ja mittefunktsionaalsete nõuete põhidokumenti. Põhidokumendi ja viidatud dokumentide erisuste puhul tuleb lähtuda põhidokumendis kirjeldatust. Põhidokumendis viidatud TEHIKu koostatud dokumentide ja kolmandate osapoolte koostatud dokumentide erisuste puhul tuleb lähtuda TEHIKu dokumentides kirjeldatust.

Kui mõnda nõuet ei ole võimalik või otstarbekas täita, tuleb selle mittetäitmise fakt ja põhjendus välja tuua pakkumuse esitamisel.

Nõudeid tuleb järgida ka olemasolevate infosüsteemide versiooniuuendustel nii palju kui versiooniuuenduse käigus võimalik.

Erandid tuleb kooskõlastada TEHIK'u vastutava arhitektiga kirjalikult taasesitataval kujul projektidokumentatsiooni juures.

Nõude nr

Nõude sisu Seletused Digiriigi CFR

Iseteenindus Veebid Karbitoode Koostamise eest vastutaja

Testimise läbi viib või kinnitab

1. Vastavus üldistele standarditele

1.1 Lahendus loomisel peab arvestama digiriigi ristfunktsionaalsed nõudeid.

Kohustus- ja ootustasemel olevad nõuded tuleb rakendada.

https://koodivaramu.eesti.ee/e-gov/cfr

Erisused tuleb kokku leppida Tellija lahenduse arhitektiga.

V V Arendaja Projektijuht

Arhitekt

Administraator

Testija

Turvatestija

Infoturbe spetsialist

Standardija

1.2 Lahenduse X-tee teenused peavad vastama nõuetele.

https://X-tee.ee/docs/live/xroad/ V V V Arendaja Testija

1.3 Lahendus peab vastama Sotsiaalministeeriumi IT-profiilile.

Tulevase ja olemasolevate infosüsteemide platvormid (rakendusserver, andmebaas, kolmanda osapoole komponendid) ja topoloogia peavad olema loodud kooskõlas hankes viidatud IT-Profiil versioonile.

V V V Arendaja Projektijuht

Arhitekt

Administraator

Testija

Turvatestija

Infoturbe spetsialist

Standardija

1.4 Lahenduse kasutajaliides peab vastama dokumendis "Front-end arendusreeglid" kirjeldatud reeglitele.

https://tehik.ee/arendusjuhendid V V Arendaja Arhitekt

Testija

1.5 Rakendus peab olema kirjutatud arvestades selle lahenduse äriprotsesside ja andmete E-ITS ja ISKE turvaklassi nõudeid.

https://eits.ria.ee/ V V V Arendaja Turvatestija

Arhitekt

1.6 Veebirakenduse kasutajaliides peab vastama vähemalt WCAG 2.2 tasemele AA.

https://www.w3.org/TR/WCAG22/

CFR selgitus: WCAG 2.2 alates 05.10.2023

#39 V V V Arendaja Testija

1.7 Veebipõhine kasutajaliides peab ühilduma täielikult standarditega HTML 5 ja CSS 3.

Valideerimiseks kasutatakse vastavaid validaatoreid:

https://validator.w3.org/

Kui on tegu olemasoleva süsteemi edasiarendusega, siis tuleb järgida olemas olevat HTML ja CSS versiooni.

#38 V V Arendaja Testija

1.8 Allkirjastamisel tuleb kasutada Tellija SiGA/SiVa vahendusteenust.

https://www.tehik.ee/arendusjuhendid V V Arendaja Testija

Arhitekt

1.9 Rakendus peab probleemideta läbima OWASP ASVS baasil põhineva testi.

Kui pole arenduses eraldi kokku lepitud teisiti, siis on OWASP ASVS tasemeks 2 (https://owasp.org/www- project-application-security-verification-standard/).

Kinnise lähtekoodiga kommertstoote kasutamisel ei eeldata ligipääsu kinnisele lähtekoodile.

Tellijapoolset turvatestimist teostab kolmas sõltumatu osapool. Selline esmane kolmanda osapoole turvatestimine tellitakse Tellija finantseeringul. Ilmnenud vigade korral ja peale nende parandamist peab järeltestimise rahaliselt kompenseerima arendaja, kui Tellija vastava nõudmise esitab.

#9

#10

V V V Arendaja Turvatestija

1.10 Krüptoalgoritmite ja räsifunktsioonide kasutamisel tuleb kasutada turvalisi algoritme ja võtmepikkuseid.

Krüptoalgoritmite ja räsifunktsioonide kasutamisel tuleb järgida uusimat RIA kodulehel avaldatud krüptograafiliste algoritmide kasutusvaldkondade ja elutsükli uuringut.

Värskeima uuringu leiab aadressilt https://www.ria.ee/amet-uudised-ja-kontakt/uudised- pressikontakt/uuringud-ja-analuusid#kruptouuringud

Arendaja loodud lahenduse dokumentatsioonis (nt detailanalüüs vms) tuleb välja tuua kasutatavad krüpto- ja räsialgoritmid, nende võtmepikkused, kasutuskohad, sh sertifikaatide kasutuskohad.

#46 V V V Arendaja Arhitekt

Administraator

Turvatestija

1.11 Andmete edastus peab olema kaitstud kasutades krüpteeritud ning vajadusel autenditud ja autoriseeritud kanalit.

Autentimist ei ole vaja ainult avalike andmete edastamisel (nt avaandmed).

V V V Arendaja Turvatestija

Arhitekt

Autentimise mehhanism tuleb kokku leppida Tellijapoolse arhitektiga.

1.12 Infosüsteem peab kasutama serveri kellaaega.

Kõik mahakirjutatavad ja talletatavad kellaajad tuleb salvestada UTC ajatsoonis koos ajatsooni infoga.

Kasutajatele mõeldud kuvades tuleb kasutada sirviku ajatsooni. Aja esitamisel tekstikujul lähtuda standardist ISO 8601.

#51 V V V Arendaja Arhitekt

Administraator

1.13 Süsteemi edasiarendamisel/loomisel peab arvestama selle võimaliku laiendamisega nii andmemahtude kui ka kasutajate arvu osas.

Süsteemi jõudlus peab vastama kokkulepitud topoloogial eelanalüüsi ja lähteülesande käigus välja toodud jõudlusnäitajatele.

V V V Arendaja Arhitekt

Testija

1.14 Rakendus peab olema tehniliselt tükeldatud vastavalt loogilisele jaotusele. Saadud osised peavad olema eraldi versioneeritavad ja paigaldatavad.

Lahenduse arhitektuuris kasutada domeenist juhitud disaini ja mikroteenuste põhimõtteid.

Näiteks kui rakendus on eraldi turvakontekstidega liidesed ametnikule ja kodanikule, peab rakendus olema jagatav kaheks eraldi liidesekomponendiks ning nende mõlema poolt kasutatavaks andmebaasiks.

https://learn.microsoft.com/en-us/archive/msdn- magazine/2009/february/best-practice-an- introduction-to-domain-driven-design

https://microservices.io/

#21 V V Arendaja Arhitekt

1.15 Avalike e-teenuste loomisel peab arvestama valitsusasutusele kehtestatud visuaalse identiteedi stiilijuhiseid.

https://riigikantselei.ee/valitsuslogo #36 V V V Arendaja Testija

1.16 Avalike e-teenuste loomisel peab arvestama Veera disainisüsteemiga.

https://veera.eesti.ee/

Näiteks kasutada ja laiendada E-Gov CVI projekti komponente:

https://e-gov.github.io/cvi/

#36 V V Arendaja Arhitekt

1.17 Lahenduse loomisel peab arvestama riiklikku koostoimeraamistikuga.

https://digiriik.eesti.ee/koostoimeraamistik/ V V V Arendaja Arhitekt

Administraator

1.18 Aadressiandmete sisestamisel, kuvamisel ja hoidmisel tuleb lähtuda Vabariigi Valitsuse määrusest "Aadressiandmete süsteem".

Liidestatakse Maa-ameti ADS teenusega.

Esitluskihis on lubatud liidestada In-ADS teenusega otsingu tarvis. Taustsüsteemides toimub liidestamine X-tee teenusega.

https://www.riigiteataja.ee/akt/115072023005? leiaKehtiv

#53 V V Arendaja Arhitekt

Standardija

Testija

1.19 Tegevusalade andmete sisestamisel, kuvamisel ja hoidmisel tuleb lähtuda Vabariigi Valitsuse 10. jaanuari 2008. a määrusest nr 11 "Klassifikaatorite süsteem" ja kasutada EMTAK infosüsteemis kehtivat klassifikaatorit.

https://www.riigiteataja.ee/akt/12910889?leiaKehtiv

https://emtak.rik.ee/EMTAK/

#54 V V Arendaja Standardija

Testija

2. Nõuded rakenduse arhitektuurile

2.1 Rakenduse, andmebaasi ja kolmanda osapoole komponendid peavad olema sellised, mille turbe uuenduste eluea lõpp (Security Support) pole teadaolevalt vähem kui 2 aasta pärast.

Arendaja loodud lahenduse dokumentatsioonis (nt analüüs vms) peab olema välja toodud kasutatavate komponentide nimetused ja versioonid. Lubatud on kasutada ka tarkvara materjalide loendit (SBOM). Versiooni eluea lõppu ei loeta võrdseks terve komponendi eluea lõpuga, st versiooni tugi võib aeguda, kui uus versioon on välja lastud.

Jätkuarenduse puhul tuleb kaardistada eelneva arendusperioodi komponentide kaardistus. EOL komponentide kasutamisest tuleb teavitada Tellijapoolset arhitekti.

CFR selgitus: Kahjuks täna paljud komponendid vaatavad tulevikku 1.5 - 2 aastat. Võimalusel valida komponendid, mis omavad pikka elueatuge, nn LTS versioon.

#7 V V V Arendaja Arhitekt

2.2 Rakendusserver peab võimaldama töötamist andmebaasiserverist eraldi serveril.

V V V Arendaja Administraator

2.3 Rakendusserver peab olema kõrgkäideldav ja horisontaalselt skaleeruv.

Kasutaja sessioonid ei tohi olla rakenduserveri klastri õla põhised.

V V V Arendaja Administraator

2.4 Rakendust peab saama ilma ümberprogrammeerimata liigutada erinevate domeenide ja domeeni saitide vahel.

Lahenduses ei tohi olla sisse kompileeritud absoluutseid URI-sid.

V V V Arendaja Administraator

2.5 Rakenduse komponentide konfiguratsiooni peab olema võimalik ette anda käivitamisel. Konfiguratsiooni muudatus peab olema teostatav ilma rakendust kompileerimata.

Rakendus peab neid sealt ka kasutama (mitte kopeerima parameetreid käivitamisel kolmandatesse kohtadesse), logimise seaded võivad olla rakenduse konfiguratsioonifailist eraldi ühes lisakonfiguratsioonifailis (nt Log4j). Samuti on tungivalt soovituslik eraldi konfiguratsioonifailis hoida arendaja ja administraatori vastutusala parameetreid.

Infosüsteem peab olema seadistatav konfiguratsiooniparameetrite(de) abil. Konfiguratsioonifailiks ei saa lugeda faili, kus hoitakse lisaks konfiguratsioonile ka muud programmikoodi.

V V V Arendaja Administraator

Testija

Näiteks konteinerlahenduste puhul peab kasutama keskkonnamuutuja põhiseid konfiguratsiooni parameetreid.

2.6 Rakenduse taaskäivitus, konfiguratsiooni muutmine vms peab toimuma mõistliku aja jooksul.

Tavaline käivitusaeg ei tohi ületada 30 sekundit.

Kui rakendus vajab indekseeritud sisu ja see pole kättesaadav, siis peab rakendus väljastama selle kohta selge teate.

V V V Arendaja Testija

2.7 Lahenduse väliste osapoolte komponentide konfiguratsioonid peavad olema puhverdatud.

Kui rakendusel või mõnel selle komponendil on tihti kasutatav teenus ning sellel teenusel on laetav konfiguratsioon, siis tuleb:

laadida konfiguratsioon ühekordselt ja seda korduvkasutada; konfiguratsiooni automaatselt ja regulaarselt värskendada; regulaarsuse tarbeks peab saama määrata intervalli, millise aja järel või täpsed kellaajad, millal konfiguratsiooni värskendatakse; luua võimalus värskendada konfiguratsiooni käsitsi.

Näiteks:

digidoc4j teegi korral laetakse TSL nimekiri välisvõrgust puhvrisse, et vähendada koormust kolmandale osapoolele. OpenID konfiguratsioon

V V Arendaja Arhitekt

Testija

Administraator

2.8 Kõik andmed, andmebaasid, SQL skriptid, lähtekood ja rakendus peavad kasutama UTF-8 või UTF-16 kodeeringut.

#50 V V V Arendaja Administraator

Testija

2.9 Rakendusserveri failisüsteemi ei tohi salvestada midagi püsivaks kasutamiseks.

Näiteks objektide talletuseks kasutada objektide talletamise lahendust (nt MinIO).

V V Arendaja Administraator

2.10 Ühest relatsioonilise andmebaasi andmetabelist teise viitamisel tuleb kasutada väliseid võtmeid (Foreign key).

Erinevate skeemide vahelised ühendused on keelatud. Peab kasutama REST/SOAP/AMQP liidestust.

V V Arendaja Arhitekt

2.11 Kõik välised võtmed (Foreign Key) peavad olema indekseeritud.

Andmebaasis peab kasutama indekseid ja/või muid meetmeid, et nõuded rakenduse jõudlusele oleksid täidetud ka tulevikus. (ühe, kolme, viie või 10 aasta pärast – vastavalt planeeritud kasutusajale).

V V Arendaja Arhitekt

2.12 Tuleb kasutada päringumuutujaid (Parameter Binding).

SQL päringute väljakutsumisel väljastpoolt andmebaasi peab kasutama päringumuutujaid, et vältida SQL vahemälu fragmentseerumist (When calling SQL code from outside the database, Parameter Binding should be used to prevent SQL cache fragmentation).

V V Arendaja Arhitekt

2.13 Kõigis andmebaasi tabelites peab olema defineeritud üks primaarvõti

Kasutada tuleb vastava andmebaasisüsteemi nimetamise parimaid praktikaid.

V V Arendaja Arhitekt

2.14 Andmebaasi objektide nimetused peavad olema sisulised ja andma aimu nende otstarbest.

Kasutada tuleb vastava andmebaasisüsteemi nimetamise parimaid praktikaid.

V V Arendaja Arhitekt

2.15 Andmebaasis defineeritakse üldjuhul kaks või enam kasutajat:

Rakenduse peakasutaja, kellena luuakse objektid ja skeemid. Rakenduse piiratud õigustega kasutaja, kellena pöördub rakendusserver/rakendus.

Objektide loomiseks vajalikud õigused ja ressursid on loetletud rakenduse dokumentatsioonis.

Need õigused, mis on vajalikud ainult rakenduse baasi loomiseks, on eraldi välja toodud ja tuleb peale installeerimist ära võtta. Karbitoodete puhul tuleb erisused läbi arutada Tellija arhitektiga.

Lahenduse puhul, milles kasutatakse andmebaasi versiooneerimist, tuleb kasutada mitut andmebaasi ühendust. Ennem rakenduse käivitumist teostatakse andmebaasi skeemi muudatused eraldi kasutajaga. Rakendus kasutab enda põhitööks kasutajat, kellel puudub õigus andmebaasi skeemis muudatusi teostada.

V V Arendaja Administraator

2.16 Failide hoidmise asukoht lepitakse iga kord kokku, kuid failid ja failide indeks peavad olema replikeeritavad teise asukohta.

Failide hoidmine klassikalises andmebaasis on kulukas ja seab kõrgendatud nõudmised ja piirangud andmebaasiserveritele. Lahenduse dokumentatsioonis tuleb ära tuua failide hoidmise asukoht.

Näiteks objektide talletuseks kasutada objektide talletamise lahendust.

V V Arendaja Arhitekt

2.17 Peab olema miinimumini viidud vajadus, et haldur teeb haldustoiminguid otse baasis. St rakendusel peab olema haldusliides, mille kaudu rakenduse haldur saab teha tavapäraseid haldustoiminguid.

Halduri haldustoimingud lepitakse Tellijaga kokku detailanalüüsi käigus.

V V V Arendaja Testija

2.18 Andmebaas peab toetama nii külm- kui ka kuumvaru (peegeldamist) teise asukohta.

Ei tohi kasutada teenuseid, mis välistavad andmebaasi peegeldamist (nt "MSSQL filestream").

V V Arendaja Arhitekt

2.19 Sorteerimisreeglistik peab olema Eesti tähestikule vastav. Tõusutundlikkus peab olema välja lülitatud. Diakriitiline (Accent) peab olema sisse lülitatud.

Näiteks PostgreSQL puhul et_EE. V V V Arendaja Testija

2.20 Kui infosüsteemid saadavad e-kirju, peavad nad kasutama välist e-maili serverit. Kirja saatmisel peab rakendus veenduma, et e-posti server võttis kirja vastu. E-kirjade vormindamine peab järgima interneti standardeid (RFC 5322).

Saatja ja adressaadid, pealkiri ja sisu ei tohi olla rakendusse kodeeritud, vaid on muudetavad konfiguratsioonifaili kaudu.

Genereeritud kirjade puhul peab tagama kirjade jälitatavuse (näiteks lisada X-päise kodeeritud kirje, milles on kirjeldatud, mis protsess/skriptifail/kasutaja kirja genereeris jms abistav info).

V V V Arendaja Administraator

2.21 Konfiguratsiooniparameetrite nimed peavad olema sisulised. Kui see ei ole

Näiteks : X_TEE_TURVASERVER, mitte XTTS või viitenumber, mitte vk_seb jne

V V Arendaja Administraator

võimalik, siis peab kõrval olema seletus. Testija

2.22 Infosüsteemides on eessüsteemid (front end; presentatsiooni kiht) ja tagasüsteemid (back end; äriloogika kiht) arhitektuuriliselt selgelt lahutatud ja eraldi paigaldatavad.

Rakenduse äriloogika tuleb realiseerida andmebaasist eraldi sõltumatus rakenduskihis.

Koostöövõime raamistik 2011. Punkt 3.1. Tagasüsteemide ülesanneteks on andmete haldamine ja võrguteenuste pakkumine. Tagasüsteemid ei tegele lõppkasutaja autentimise ja autoriseerimisega. Lõppkasutaja autoriseerimise tagavad eessüsteemid. Välise süsteemi tõrge tohib mõjutada ainult sellest otseselt sõltuvate kasutuslugude toimimist. Välise süsteemi taastumisel peab süsteem olema suuteline oma tööd jätkama taaskäivitamata.

Andmebaas ei tohi sisaldada äriloogikat, mis muudab andmetabelites olevaid/sinna kirjutatavaid andmeid, va trigerid, mis tekitavad logi.

#23

#29

#64

V V Arendaja Arhitekt

2.23 Konfiguratsioonifailid peavad olema vastavalt rakendusserveri tüübile vaikimisi kaitstud failid/objektid.

Näiteks IIS: *.config , *.resources Apache: *.conf, .htaccess.

Arendaja peab välja tooma konfifailide listi, kui neid on mitu.

V V V Arendaja Administraator

2.24 Rakenduse failid, mida kasutaja näha ei tohi, peavad olema vaikimisi kaitstud kaustades ja ei tohi olla veebi juurkaustas.

Näiteks: IIS: Bin,App_Code, App_Data, App_Browsers, App_GlobalResources, App_LocalResources, App_Themes, App_WebReferences, .git

V V V Arendaja Administraator

2.25 Konfiguratsiooniparameetrite taaskasutus. Erinevaid sama sisuga parameetreid ei tohi konfiguratsioonis eksisteerida.

Kõiki parameetreid tuleks konfiguratsioonis kirjeldada vaid korra, dubleerimine on keelatud.

V V Arendaja Administraator

Testija

2.26 Esitluskihist ei tohi pöörduda otse andmebaasi poole.

Tuleb rakendada vähemalt 3 tasandilist arhitektuuri (three-tier architecture).

Lõppkasutaja lokaalsesse seadmesse paigaldatud tarkvara loeme esitluskihiks. Ka sellisel juhul ei tohi teha lõppkasutaja seadmest otse ühendust andmebaasi.

V V V Arendaja Administraator

2.27 Keskkonnapõhised muutujad peavad olema konfiguratsiooniparameetritega seadistatavad.

Näiteks WSDL ei tohi sisaldada viiteid arendusserveritele.

V V V Arendaja Administraator

Testija

2.28 Eelistada tuleb tsentraalseid autentimislahendusi (nt Tellija SSO lahendus).

Kui rakendus realiseerib ise autentimist, siis peab olema võimalik piirata ebaõnnestunud logimisi ajaühiku kohta (mobiil-ID, paroolid) ühelt IP- aadressilt.

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 realiseeritav autentimise lahendus peab olema põhjendatud ja omama kirjalikku taasesitatavat kokkulepet projekti dokumentatsiooni juures

#30 V V V Arendaja Arhitekt

Testija

2.29 Relatsioonilises andmebaasis võib kasutada vaid ISO/IEC 9075 standardiga kaetud funktsionaalsusi. Lisaks ei tohi kasutada ka sama standardi osas 13 kirjeldatud funktsionaalsusi.

Ei ole soovitav kasutada mingit platvormispetsiifilist lahendust, mille üleviimine mõnele muule andmebaasiplatvormile ei ole võimalik. ISO/IEC 9075 osa 13 spetsifitseerib Javas kirjutatud programmimoodulite kasutamist andmebaasis.

V V Arendaja Arhitekt

2.30 Uniform resource identifier (URI) pikkus ei tohi ületada ühegi lahenduse poolt toetatava sirviku maksimaalset lubatud väärtust.

Harilikult on piiriks 2048 tähemärki, kuid iga lahenduse puhul tuleb seda eraldi järele uurida sõltuvalt lahenduse komponentidest. Asjakohased viited: RFC 3986 ja RFC 7239.

V V V Arendaja Administraator

Testija

2.31 Veebiteenuseid (REST, SOAP) pakkuv rakendus peab olema üles ehitatud nii, et see toetaks teenuste versiooneerimist URL-i ja/või skeemi tasemel.

Näiteks WSDL puhul: Alajaotis definitions/types/schema:

complexType defineerimisel tuleb sellele lisada any element.

V V V Arendaja Arhitekt

2.32 Rakendus peab olema võimeline töötama koormusjaoturitega varustatud taristul.

Koormusjaoturi peal kasutatakse järjestikplaanurit (Round Robin) päringute suunamisel. Samuti võidakse teostada koormusjaoturil TLS ühenduse lahtivõtmist ja uuesti kokkupanemist (SSL offload).

V V V Arendaja Administraator

2.33 Sidusinfosüsteemide mittekättesaadavus ei tohi segada rakenduse töötamist. Sidusinfosüsteemidega andmevahetamisel tekkinud vead logitakse ja kasutajat hoiatatakse.

Sidussüsteemi tõrge tohib mõjutada ainult sellest otseselt sõltuvate kasutuslugude toimimist. Sidussüsteemi taastumisel peab süsteem olema suuteline oma tööd jätkama rakendust taaskäivitamata.

Väliste liidestatud süsteemide tõrke korral ei tohi süsteem hanguda, vaid peab väljastama mõistliku (võimalikult lühikese) aja jooksul asjakohase veateate. Võimalusel tuleb kasutada asünkroonseid liideseid.

V V V Arendaja Administraator

Testija

2.34 Automaatselt käivituvaid taustatöid peab saama käsitsi (taas)käivitada.

Vajalik juhul, kui automaatsel käivitumisel on tekkinud viga ja/või taustatöö on pooleli jäänud.

Pärast vea põhjuse korrigeerimist peab saama taustatöö uuesti käivitada.

Lahendusse on vaja luua taustatööde haldamiseks ja juhtimiseks võimekus, et võimaldada vastavates rollides olevatel inimestel lahendust hallata (nt peakasutaja või rakenduse administraator).

V V V Arendaja Testija

2.35 Kui ajastatult käivitatav taustatöö ei ole mõeldud käima paralleelselt, peab selles olema realiseeritud kontrollmehhanism, mis tagab, et sama taustatööd ei ole

Kui lahendus töötab mitmel õlal, ei tohi tööd, mis ei ole mõeldud paralleelselt käima, käivituda korraga mitmel õlal. Peab rakendama lukustus põhimõtet.

V V Arendaja Administraator

Testija

võimalik käivitada uuesti enne, kui eelmisena käivitatud instants on oma töö lõpetanud.

2.36 Uue toote arenduse ja olemasolevate infosüsteemide versiooniuuendustel kasutusele võetavate tehnoloogiate ja standardite valik tuleb kooskõlastada Tellijapoolse arhitektiga.

V V V Arendaja Arhitekt

2.37 Rakenduse ühenduste (s.h. andmebaasi ja sidusinfosüsteemide ühendused) realiseerimisel tuleb kasutada ühenduste puulimist (connection pooling).

Implementeeritud peab olema vähemalt maksimaalsete ühenduste arvu piirang, päringu aegumise aeg (request timeout) ja ühenduse elususe periood (keepalive). Rakenduse ühenduste tõrge tohib mõjutada ainult sellest otseselt sõltuvate kasutuslugude toimimist. Ühenduste taastumisel peab rakendus olema suuteline oma tööd jätkama taaskäivitamata. Tekkinud vead logitakse ja kasutajat hoiatatakse.

V V V Arendaja Arhitekt

2.38 Rakenduse uuendustega kaasnevad andmebaasi muudatused tuleb automatiseerida ja versioneerida.

Näiteks Liquibase või Flyway. V V Arendaja Administraator

2.39 Mitterelatsioonilises mudelis andmete hoiustamine tuleb eraldi kokkuleppida.

Näiteks kui soovitakse kasutada NoSQL lahendusi püsivaks andmete talletuseks, tuleb see kokku leppida Tellijapoolse arhitektiga.

V V V Arendaja Arhitekt

2.40 Mikroteenuste arhitektuuris vältida ebavajalikku andmete dubleerimist.

Iga teenus vastutab enda valdkonna andmete eest. Kui on vajadus lisaandmete jaoks, on tal võimalik pöörduda teise teenuse poole.

V Arendaja Arhitekt

2.41 Infosüsteemide vaheline andmevahetus toimub üle X-tee.

https://www.ria.ee/riigi-infosusteem/andmevahetuse- platvormid/andmevahetuskiht-X-tee

https://www.riigiteataja.ee/akt/106082019017? leiaKehtiv

Erandiks on lubatud päringud sama andmekogu raames. Sellisel juhul tuleb turvalisus tagada lahenduse loojate poolt. Kasutada kas mTLS või tõendipõhist autentimist.

#22 V V V Arendaja Arhitekt

3. Turvalisuse tagamisega seotud nõuded

3.1 Asutusesiseseks kasutamiseks mõeldud rakenduse kasutajate autoriseerimist peab saama teha vastu TEHIKu keskset autoriseerimisteenust.

TEHIKu haldusala kasutajad ja nende rollid on kirjeldatud Active Directory's. Võimalik on kasutada rollide pärimiseks TEHIK SSO teenust.

Täpsem tehniline lahendus leida koos TEHIKu poolse arhitektiga.

V V V Arendaja Turvatestija

3.2 Kliendi ja serveri vahel peab autenditud kasutajasessioonide korral olema sessioon krüpteeritud HTTPS-protokolli kasutades.

V V V Arendaja Turvatestija

3.3 Rakendus tohib kasutada vaid sessiooni küpsiseid (cookies). Muude küpsiste kasutamine tuleb kokku leppida Tellijapoolse arhitektiga.

V V Arendaja Turvatestija

3.4 Kui andmebaasis olevate andmete E-ITS tervikluse (I ehk integrity) turvaosaklass on S või VS, siis tuleb kõik andmebaasi kirjed/tabelid versioneerida.

St kõik andmemuudatused peavad baasis säilima. Andmete muutmisel andmeid ei kustutata, vaid tehakse uus kirje uute andmetega. Vana muudetakse kehtetuks. Iga uus kirje peab sisaldama järgmist informatsiooni:

viide kirjele, mille ta kehtetuks muutis (kui on) kasutaja, kes kirje lõi kirje loomise aeg sessiooni-ID (kui on olemas) X-tee ID (kui on olemas)

Iga kehtetuks tunnistatud kirje peab omama järgmist informatsiooni;

kasutaja, kes kirje kehtetuks tunnistas; kirje kehtetuks tunnistamise aeg.

Täpne realisatsioon tuleb kokku leppida Tellija arhitektiga.

#55

#49

V V Arendaja Turvatestija

Arhitekt

3.5 Rakendusega peab kaasas olema lahendus, mis suudab toota toodangu andmetest testandmed, mis ei võimalda siduda konfidentsiaalset informatsiooni päris andmesubjektiga.

Testandmed peavad säilitama kõik toodangu andmete omadused (pikkuse, tüübi) ja omavahelised suhted.

Täpsem vajadus ja tegevusplaan tuleb koostada Tellija arhitekti ja tooteomanikuga.

V Arendaja Arhitekt

3.6 Rakendus ja selle komponendid peavad võimaldama kasutada keskkondade lahusust.

Arendaja arendab arenduskeskkonnas ja annab tarne üle Tellijale paigalduspakkidena. Tellija paigaldab selle testkeskkonda ja testib ning seejärel paigaldab tarne toodangu keskkonda. Reaalseid andmekogu andmeid tohib töödelda üksnes toodangu keskkonnas.

Üldjoones on kõik keskkonnad majutatud Tellija majutuses.

V V V Arendaja Turvatestija

3.7 Rakendusse ja andmetele tohib olla ligipääs vaid dokumenteeritud ja tellimuses kirjeldatud teid mööda ning dokumenteeritud autentimisprotseduure kasutades.

St rakendustes ega andmebaasides ei tohi olla ligipääsemiseks teisi võimalusi.

V V V Arendaja Turvatestija

3.8 Rakendus ei tohi teostada X-tee päringut otse kasutajaarvutist.

Kasutajaarvutitest otse X-tee päringute tegemine on arvutivõrgu tasemel kinni.

V V V Arendaja Turvatestija

3.9 Veebipõhised välise veebilehega rakendused peavad kasutama vahendeid,

IIS puhul peab kasutama näiteks URL scan, apache puhul modsecurity või vastavat tööriista. Lubamatud

V V V Administraator Turvatestija

kaitsmaks rakendust lubamatute päringute eest.

päringud on kõik päringud, mis ei ole detailanalüüsi käigus vastavalt kasutusjuhtudele ette nähtud. Blacklistingu asemel tuleb kasutada whitelisting põhimõtet.

3.10 Kasutaja peab saama soovi korral veenduda, kas keegi pole tema nime all vahepeal sisse loginud.

Rakendus peab sisenemisel näitama pärast õnnestunud sisselogimist eelmise õnnestunud sisselogimise aega. Kui on toimunud ebaõnnestunud sisselogimise katseid, siis peab ka kuvama, millal need toimusid, mitu neid oli ja mis IP-aadressilt pöörduti.

Ebaõnnestunud logimiste katsete kuvamise nõue kehtib juhul, kui autentimine ja autoriseerimine lahendatakse rakenduses lokaalselt.

V V V Arendaja Turvatestija

3.11 Kõigil rakendustel peab olema konfigureeritav kasutajasessiooni aegumise aeg.

Aeg peab olema muudetav koos teiste konfiguratsiooniparameetritega.

Nõue kehtib juhul, kui kasutatakse lahenduse sisest sessiooni haldust.

V V V Arendaja Turvatestija

3.12 Lahenduses kasutatavate küpsiste sisu peab olema krüpteeritud

Eesmärk on kaitsta kasutaja andmeid, mis on talletatud sirviku küpsiste hulka.

V V Arendaja Turvatestija

3.13 LDAP lahenduse (nt Active Directory) kasutamisel peab rakendus kasutama kontoga kaasnevaid piiranguparameetreid.

Näiteks: konto on lukus, parool aegunud, konto aegunud, paroolipoliitika jne.

#30 V V V Arendaja Turvatestija

3.14 Tagada tuleb rakenduse rollide lahusus. Peakasutajal ja tavakasutajal on erinevad tööülesanded. Rollide/õiguste kirjeldus peab lähtuma detailanalüüsist ja kasutusjuhtudest.

V V V Arendaja Turvatestija

3.15 Arendus peab olema orienteeritud toodangukeskkonnas toimimiseks.

Toodangukeskkonnas mittevajalikud funktsionaalsused peavad olema eraldi juhitavad ja tavakäivitusel väljalülitatud. Näiteks eraldiseisva profiiliga Java arenduste puhul. (kasutuseta funktsionaalsus ja komponendid, mis on mõeldud testimiseks testkeskkonnas ja arendusabiks arenduskeskkonnas)

V V V Arendaja Turvatestija

3.16 Kui rakenduse tervikluse turvaosaklass on T3, peavad tõestusväärtust omavad andmed olema kas ajatembeldatud, digiallkirjastatud või digitembeldatud ning krüptoaheldatud.

See tagab, et tõestusväärtusega andmeid ei saaks märkamatult kustutada.

Konkreetne lahendus tuleb kokku leppida Tellija arhitektiga.

V V V Arendaja Turvatestija

3.17 Kui rakenduses on S3 salastatuse astmega andmeid, peavad need olema nii transpordi ajal ja ka salvestatult alati krüpteeritult.

Konkreetne lahendus tuleb kokku leppida Tellija arhitektiga.

V V V Arendaja Turvatestija

3.18 Rakendus peab võimaldama hõlpsalt välja vahetada aegunud ja ebaturvalise krüptoalgoritmi.

Krüptograafiat kasutav rakenduskood ei tohi nimeliselt välja kutsuda krüptograafilisi algoritme, vaid peaksid seda tegema vahendavate vaheteekide kaudu üldiste funktsioonide järgi (nt krüpteerimine, dekrüpteerimine, signeerimine, signatuuri verifitseerimine jne). Dokumentatsioon peab kajastama üldist kirjeldust, kuidas vajadusel ebaturvaline krüptoalgoritm välja vahetada.

Lisaks peavad eksisteerima vahendid juba olemasolevate krüpteeritud andmete ümberkrüpteerimiseks.

V V V Arendaja Turvatestija

3.19 Rakenduse andmebaasi krüpteerimisega seotud andmeväljad peavad olema muudetava pikkusega.

Andmebaasides kasutatavad krüpteerimisfunktsioonidest tingitud lisaväljad peaksid olema muudetava pikkusega, et formaati muutmata saaks kasutada teistsuguste parameetritega krüpteerimisalgoritme.

V V V Arendaja Turvatestija

3.20 Lahendus peab olema kaitstud HTMLi süstimiste eest.

OWASP soovitab kasutada DOMPurify lahendust HTMLi saneerimiseks

#44 V V V Arendaja Arhitekt Turvatestija

4. Logimine

4.1 Logimiseks tuleb kasutada standardseid komponente kogu logiahela ulatuses.

Näiteks Java raamistikku log4j, SLF4J, logback; transpordiks syslog, Elastic Beats; logi formaadiks JSON. Logi peab olema loetaval tekstilisel kujul, et logikirjeid saaks töödelda masinmõistetavalt ja inimloetavalt.

V V V Arendaja Arhitekt

Administrator

4.2 Peab kasutama logikomponenti ja peab olema võimalik juhtida logikomponendi seadistusi.

Seletus: Näiteks peab saama muuta logimise taset ja logimise formaati.

V V V Arendaja Arhitekt

Administraator

Testija

4.3 Logisündmused peavad olema loogiliselt eristatavad.

Auditlogi (Seansilogi, tegevuslogi) - info sisselogimiste, väljalogimiste ja seansi aegumiste kohta. Vigased sisselogimise katsed. Info õiguste suurendamise kohta. Peab olema logitud ka tühja või puuduvate parameetritega logimise katsed. Kogu informatsioon kasutajate tegevuste kohta koos tegevuse tüübi, seansi parameetrite (korreleerimaks seansi- ja tegevuslogi) ja kasutaja poolt esitatud sisendparameetritega (sh. väliste ressursside kasutamise kohta). Logida tuleb nii õnnestunud kui ka ebaõnnestunud tegevusi. Tehniline logi - rakendusserveri poolt loodud logi Vealogi - erinevate veaolukordade info Silumislogi - arendajate jaoks vajalik debug info

#41 V V V Arendaja Arhitekt

Administraator

4.4 Logimine peab olema optimeeritud. Informatsiooni dubleerimist logides tuleb vältida, kui ei ole nõutud teisiti.

V V V Arendaja Arhitekt

Testija

4.5 Logides peab olema maksimaalselt üks sündmus ühel real.

V V Arendaja Administraator

Testija

4.6 Logikirje peab olema JSON formaadis. V V Arendaja Arhitekt Testija

4.7 Logiväljade nimed peavad olema normaliseeritud ja tuleb rakendada Elastic Common Schema spetsifikatsiooni.

Samatüübilised logiväljade nimed peavad olema ühtsed üle logi.

https://www.elastic.co/guide/en/ecs/current/ecs- reference.html

V V Arendaja Arhitekt Infoturbespetsialist

4.8 Rakendus peab logima kasutaja edukat ja ebaedukat autentimist ja sessiooni lõpetamist, kasutaja IP-d ja autentimismeetodit.

Logima peab ka autentimise ebaõnnestumise koos põhjusega (vale juurdepääsumandaat, aegunud konto jne). Logida tuleks IP-aadress, meetod ja kui võimalik kasutajatunnus (mobiil-ID puhul telefoni number; ID- kaardi või Smart-ID puhul isikukood).

Kui rakendus kasutab kasutajate autentimiseks välist autentimise/autoriseerimise vahendit, siis leppida eraldi kokku autentimise detailsus ehk mida kajastatakse autentimise/autoriseerimise vahendis ja mida rakenduses.

V V V Arendaja Arhitekt

Testija

4.9 Üle terve logi peab olema kasutaja sessiooni käigus tehtud tegevusi või sama sündmust võimalik siduda loogiliselt kokku.

Tegevuste sidumiseks peab olema võimalik logikirjeid siduda ühise välja abil. Selleks ei sobi kellaaeg, IP ega isikukood. Sobib näiteks unikaalne ID, mis ei tohi olla sessiooni ID, sest seda saaks logist välja lugeda ja rünnakuks ära kasutada. Võib olla sessiooni ID räsi koos transaktsiooni ID'ga.

Konkreetne lahendus tuleb kokku leppida Tellija arhitektiga.

#17 V V V Arendaja Arhitekt

Testija

4.10 Andmete loomise/vaatamise/muutmise/kustutamise tegevused peavad olema kajastatud logides. Logida tuleb ka päringud, mille vastus on puhverdatud.

Logikirjes peab sisalduma piisavalt informatsiooni, et vastata küsimustele kes?, mida?, kus?, kust?, millal?, kuidas? ja tulemus.

Konkreetne detailsus ja tehniline lahendus tuleb kokkuleppida Tellija arhitektiga. Näiteks on mõistlik luua audit teenus, mis annab vastavale rollile võimaluse näha ja auditeerida tegevusi.

V V V Arendaja Testija

Turvatestija

Infoturbespetsialist

4.11 Administraatorite ja haldurite poolt tehtavaid andmete vaatamised, muutmised sh kustutamised (ka otse baasis) tuleb logida. Muutmise puhul tuleb logida nii uus kui ka vana väärtus.

Lahendus peab tagama, et administraatorid/haldurid ei saa andmete vaatamise, muutmise logimist ise (ka tavakasutajate logimist) deaktiveerida või logisid kustutada/muuta.

Konkreetne detailsus ja tehniline lahendus tuleb kokku leppida Tellija arhitektiga. Näiteks on mõistlik luua audit teenus, mis annab vastavale rollile võimaluse näha ja auditeerida tegevusi.

V V V Arendaja

Administraator

Infoturbespetsialist

Testija

4.12 Süsteemsed logid ei tohi sisaldada otseseid isikuandmeid.

Tulenevalt GDPRist ja logi sündmuse subjekti õigustest, ei tohi logide igapäevane analüüsimine ja jälgimine riivata sündmuse subjekti õigusi.

Näiteks kasutada kasutaja nime ja tunnuse asemel tema süsteemset ID'd. Lahendus peab sisaldama võimalust ID ümberpööramist reaalseteks andmeteks. Antud tegevus peab olema auditeeritav.

Konkreetne detailsus ja tehniline lahendus tuleb kokkuleppida Tellija arhitektiga.

V V V Arendaja Arhitekt

Testija

Turvatestija

Infoturbespetsialist

4.13 Kui parameetri väärtus on tühi, tuleb see logis märkida asendusväärtusega.

Näiteks NULL V V Arendaja Testija

4.14 Logis tuleb kõik mittekuvatavad (non- printable) sümbolid kodeerida.

Näiteks reavahetused -> \n, non-printable sümbolid - 0x00..0x1f, 0x7f..0xff.

V V Arendaja Testija

4.15 Rakendus peab logima kõiki rakenduses tekkivaid tehnilisi vigu.

Logi sisaldab minimaalselt vea tekkimise aega, veakoodi, veakirjeldust (stack trace, traceback vms), võimalusel kasutaja andmeid, HTTP-, GET- ja POST- parameetreid ja nende väärtusi. Logimise detailsusrežiimi (info, warning, errog, debug) peab saama muuta.

V V V Arendaja Administraator

Testija

4.16 Rakendus ei tohi X-tee päringuid salvestada rakenduse logis. Logis peab olema X-tee tunnus (ID), et saaks siduda X-tee logiga.

V V V Arendaja Administraator

Testija

4.17 Rakenduse funktsionaalsuse kirjeldusega tuleb luua logimise dokumentatsioon ja loginäidised. Koos funktsionaalsuse arendamisega tuleb luua ka loodava funktsionaalsuse logimine ja selle dokumentatsioon. Dokumentatsioon peab sisaldama logis kasutatud klassifikaatorite kirjeldusi.

Mida logitakse, kuidas sündmused on logis jagatud, logiridade näited.

V V V Arendaja Arhitekt

Administraator

Infoturbespetsialist

5. Testimine

5.1 Rakenduse kõik üleantavad versioonid peavad enne Tellijale üle andmist olema testitud.

Testitulemused tuleb edastada Tellijale koos rakenduse üleandmisega. Vaata lisaks nõuet 5.2 ja 5.3.

Testid peavad olema käivitatavad Tellija pideva integreerimise (CI) keskkonnas (nt Gitlab) ning olema dokumenteeritud, kuidas teostada testide seadistamist ja manuaalset käivitamist.

#12 V V V Arendaja Testija

5.2 Lahendus peab olema minimaalselt 75% ulatuses kaetud automaatsete komponenditestidega (unit test).

Käivitatakse Tellija pideva integreerimise (CI) keskkonnas (nt Gitlab) ja kaetust raporteeritakse lähtekoodi analüsaatoris (nt SonarQube).

#12

#35

V Arendaja Arhitekt

Testija

5.3 Lahendus peab olema minimaalselt 50% ulatuses kaetud automaatsete

Käivitatakse Tellija pideva integreerimise (CI) keskkonnas (nt Gitlab).

#12

#33

V Arendaja Arhitekt

Testija

vastuvõtutestidega.

5.4 Rakendusega peab olema kaasas skript jõudlustestide tegemiseks.

Jõudlustestide täpne kirjeldus tuleb kokku leppida detailanalüüsi käigus. Arendaja peab koos rakendusega tarnima skripti ja vajalikud tarkvaralised vahendid kokkulepitud jõudlustestide läbiviimiseks. Jõudlustestide läbiviimine ei tohi nõuda Tellijalt omapoolset tarkvara arendamist, skriptide kirjutamist või litsentside ostmist.

Jõudlustestid peavad olema käivitatavad Tellija pideva integreerimise (CI) keskkonnas (nt Gitlab) ning olema dokumenteeritud, kuidas teostada testide seadistamist ja manuaalset käivitamist.

Konkreetne detailsus ja tehniline lahendus tuleb kokku leppida Tellijapoolse testija esindajaga.

#12

#34

V V Arendaja Arhitekt

Administraator

Testija

5.5 Testimine toodangu andmetega on keelatud.

Testimiseks tuleb luua vastavad andmekooslused, et tagada tervik voo testimise võimekus.

V V Arendaja Arhitekt

Administraator

Testija

5.6 Enne lahenduse esmast tootesse lansseerimist peab olema teostatud turbetestid ja seal välja toodud probleemid lahendatud.

Turbe testide teostamist ja tellimist koordineerib Tellijapoolne testija esindaja. Samuti tuleb kokku leppida põhimõtted, millistel juhtudel turbe testi tuleb uuesti teostada.

Parendused ja lahendused tuleb kokku leppida Tellija arhitektiga.

#9

#10

V V Arendaja Arhitekt

Administraator

Testija

6. Monitooring

6.1 Rakendusel peab olema masinloetav tervise testleht (health check) JSON kujul.

Testlehe kättesaadavus erinevatest arvutivõrkudest peab olema konfigureeritav. Testleht peab uuendama ennast lehe pärimisel. Testleht peab sisaldama custom built rakenduse versiooni numbrit, standardsed komponendid (veebiserver, andmebaas, CMS'id jms) ei tohi oma versioone reeta. Samuti peab testlehel olema infot rakenduse (vajadusel tema erinevate osade) ja tema kõigi väliste liideste staatuse kohta (töötab, ei tööta). Rakenduse, andmebaasi ja liideste töökorda kontrollitakse testpäringute teel, mis tuleb Tellija arhitektiga kokku leppida. Testleht peab oma konfiguratsiooni võtma rakenduse üldisest konfiguratsioonist (baasistring, välised ühendused).

Näiteks java Spring raamistiku puhul kasutada actuatori võimekust.

#16 V V Arendaja Arhitekt

Administraator

6.2 Rakendusel peavad olema elususe ja tööks valmiduse otspunktid.

Näiteks java Spring raamistiku puhul kasutada actuatori võimekust. Konteinerite orkestraatori kiht teostab nende järgi otsuseid. Antud lehekülgede sisuline poole peab kajastuma ka tervise testlehel.

#16 V Arendaja Arhitekt

Administraator

6.3 Rakendus peab pakkuma monitooringu lehte, kus leidub informatsioon rakenduse funktsionaalsuse toimimise kohta.

Tuleb rakendada OpenMetrics spetsifikatsiooni.

Monitooringu leht peab välja kuvama ka testlehel kuvatud komponentide olukorda.

Näiteks kui testleht kuvab infot, et andmebaasi ühendusega on probleeme, peab see kajastuma ka monitooringu lehel. Monitooringu lehte kasutame lahenduse jälgimiseks.

https://openmetrics.io/

#16 V V Arendaja Arhitekt

Administraator

7. Nõuded rakenduse lähtekoodile

7.1 Lähtekoodi kommentaarid peavad kõigis lahenduse kihtides (rakenduse enda kood, andmebaas jne) olema kirjutatud inglise keeles.

NB! Nõuet ei arvestata arendustarkvara poolt automaatselt genereeritavate koodilõikude puhul – neid ei ole vaja tõlkida. Samuti ei rakendata nõuet kolmandate osapoolte poolt toodetud lähtekoodile – nt igasugu erinevad lahtise koodiga koodilõigud jms.

Kui tegu on olemasoleva süsteemi edasiarendusega, siis peaks kommentaarides kasutama eelnevalt kasutatud keelt.

#2 V V Arendaja Arhitekt

7.2 Lähtekoodi genereeritud dokumentatsioonid peavad olema selged, arusaadavad ja sisuliselt kirjeldama vastavat koodi, mille juures nad on. Lähtekoodist genereeritava dokumentatsiooniga tuleb katta kõik avalikud (public) meetodid ja funktsioonid.

Rakenduse kood peab olema piisavalt hästi dokumenteeritud, et erialast haridust omav tarkvaraarendaja on võimeline süsteemile jätkuarendusi teostama.

Rakendama peab dokumenteerimisel programmeerimiskeele parimaid praktikaid.

Näiteks tarkvara, mis on kirjutatud Java keeles, peab kasutama javadoc põhimõtteid ja võimekust.

#2 V V Arendaja Arhitekt

7.3 Muutujate, tüüpide ja funktsioonide nimed peavad olema sisulised ja andma aimu nende otstarbest.

Tuleb rakendada Clean Code põhimõtteid. Kui muutuja nimetus vajab kommentaari, siis pigem muuta muutuja nimetust kommenteerimise asemel.

Näiteks muutujate nimed peavad olema selged ja arusaadavad.

Hea näide muutujast: elapsedTimeInDays

Halb näide muutujast: etid

#2 V V Arendaja Arhitekt

7.4 Koodis kasutatavad konstandid ja lühendid tuleb kirjutada suurte tähtedega, lähtudes kasutatava programmeerimiskeele parimast praktikast.

Nt Javas identifikaator --> ID V V Arendaja Arhitekt

7.5 Koodis kasutatavaid konstante ei tohi selle kasutamise kohta väärtusena

V V Arendaja Arhitekt

hardcode'da – need tuleb defineerida muutujatena ja kasutada läbi nende.

7.6 Koodis defineeritud andmetüübid peavad olema nimetava käände ainsuses. Kõik andmemassiivid tuleb nimetada nimetava mitmuses (st igasugu collectionid, arrayd, jms).

N:Isik; Menetlus; jne. Andmebaaside struktuurikirjeldustes/andmemudelis ei tohi kasutada täpitähti.

V V Arendaja Arhitekt

7.7 Andmetabelites sisalduvad võõrvõtmed peavad nime järgi seostuma tabeli ja väljaga millele need viitavad.

Kasutada tuleb konkreetse andmebaasisüsteemi nimetamise parimaid praktikaid. Nt kui tegu on tabelitega ’Isikud’ ja ’Autod’, siis seos ’isiku autod’ oleks: Isikud.ID=Autod.Isik_ID

V V Arendaja Arhitekt

7.8 Andmebaasi väljade pikkused tuleb kirjeldada sümbolites, mitte baitides.

Selle asemel, et eraldada väljale x baiti, tuleb eraldada x tähemärki. (Instead of allocating x bytes of storage for the field, x chars of storage must be allocated).

V V Arendaja Arhitekt

7.9 Kui kokku pole teisiti lepitud, siis rakenduse kood peab olema kirjutatud vastavalt Google stiili juhendile.

https://google.github.io/styleguide/

Kui tarkvara keelel puuduvad Google stiili juhised, siis tuleb need kokku leppida Tellija arhitektiga enne kodeerimist.

V Arendaja Arhitekt

7.10 Koodi valideerimiseks kasutatakse minimaalselt Tellija lähtekoodi analüsaatorit.

Üleantavas koodis ei tohi olla kriitilisi ja kõrgemaid probleeme.

IT profiil: Lähtekoodi analüüs

#10

#40

V V Arendaja Arhitekt

7.11 Kasutuses mitteolev kood tuleb rakenduse lähtekoodist kõrvaldada.

Erandina on lubatud koodi osad, mis on valmis tehtud, aga ei ole veel kasutusse rakendatud ja on peidetud nn. funktsionaalsuste lippude (feature flag) taha.

V V Arendaja Arhitekt

7.12 Arendamisel kasutatakse DRY ja SOLID printsiipe.

http://en.wikipedia.org/wiki/Don%27t_repeat_yourself http://en.wikipedia.org/wiki/SOLID_(object- oriented_design)

V V Arendaja Arhitekt

7.13 Üleantavas koodis ei tohi olla paroole, mida on kasutatud arenduse käigus.

Kehtib ka siis, kui need on välja kommenteeritud. Kõik sellised paroolid tuleb asendada fraasiga “<password>“.

#28

#63

V V Arendaja Arhitekt

7.14 Üleantavas koodis ei tohi olla komponente, mille CVSS punktid on 7 ja kõrgemad ning CVE on rakendatav.

Kui CVE ei ole lahenduses rakendatav ehk tegu on lahenduse mõistes vale-positiivsega, siis võib komponendi uuendus lükkuda edasistesse etappidesse. Eeldusel, et tegu ei ole viimase üleantava tarne versiooniga. Partneri viimane üleantav versioon peab olema turbevigade vaba.

Mõistlik on kõik CVE'd omavad komponendid uuendada või välja vahetada. Ajas võib mitme madalama punkti koosmõjul avalduda kriitiline turbeprobleem.

#10 V V Arendaja Arhitekt

7.15 Üleantava lahendusega peab olema kaasas viis SBOM genereerimiseks.

SBOM ehk tarkvara materjalide loend. Mõistlik on SBOM genereerimine viia üheks järjepideva integratsiooni voo sammuks.

SBOM publitseerimine ja analüüsimine tuleb kokku leppida Tellijapoolse arhitektiga.

https://www.sbom.com/

V V Arendaja Arhitekt

7.16 Tehniliste komponentide API'del eksisteerib automaatselt genereeritud dokumentatsioon.

Näiteks REST API'de puhul kasutada OpenAPI spetsifikatsiooni.

https://www.openapis.org/

#20 V Arendaja Arhitekt

8. Andmekvaliteet

8.1 Andmekorjel kasutatakse klassifikaatoreid ja loendeid, kus need on olemas.

Vabatekstivälju tuleb vältida. #61 V V V Arendaja Arhitekt

Testija

8.2 Tekstiväljad on mõistliku suurusega. Varchar N tähemärki, kus N on ratsionaalne kaalutlus, kui suur lahter võib olla; vältida text/long-varchar kasutust, kui see pole hädavajalik.

V V Arendaja Arhitekt

8.3 Rakendus peab automaatselt eeltäitma kõik võimalikud andmeväljad, kui need andmed on varem riigile esitatud või kui nende väärtused on võimalik automaatselt arvutada.

Välja arvatud logimisvormi lahtrid autentimisel.

Näiteks: kirje sisestamise kuupäev, kasutaja nimi, sünnikuupäev jne

V V Arendaja Testija

8.4 Lahenduses peab olema tagatud idempotentsus.

Kasutaja sama tegevuse kordamisel ei tohi tekkida lahendusse andmeid topelt.

Näiteks "salvesta" nupu korduval vajutusel ei tohi tekkida dubleeritud andmeridu.

V V Arendaja Arhitekt

Testija

8.5 Analüüsi tulemusena ja enne esimese arendusetapi algust peab infosüsteemi kohta olema koostatud kontseptuaalne andmemudel olemi-suhte diagrammi (Entity Relationship Diagram, ERD) või klassidiagrammina olemite ja nende semantika kirjeldusega: teenuse nimi ja selle ärilne kirjeldus, tabeli nimi ja selles talletatavate andmete semantika ehk äriline kirjeldus.

Peab olema dokumenteeritud projekti põhi dokumentatsiooni juures. Dokument tuleb hoida ajakohane.

#58 V Arendaja Arhitekt

8.6 Enne igat arendusetapi algust peab infosüsteemi kohta olema koostatud loogiline andmemudel ehk olemi-suhte diagramm (ERD) koos kirjeldusega: skeemi ja olemite ehk tabelite nimi ja semantika, atribuutide ehk tabeli veergude kirjeldus, sh primaar- ja välisvõtmete kirjeldus: veeru nimi, andmetüüp, kohustuslik või

Peab olema dokumenteeritud projekti põhi dokumentatsiooni juures. Dokument tuleb hoida ajakohane.

#58 V Arendaja Arhitekt

mittekohustuslik (NULL/ NOT NULL), semantika ehk andmete tähendus.

8.7 Füüsiline andmemudel peab iga iteratsiooni lõpus või tarne tähtajaks selle iteratsiooni või tarne ulatuses sisaldama lisaks ajakohasele kontseptuaalsele ja loogilisele andmemudelile ka andmekirjeldusi andmebaasis.

Igal skeemil, tabelil ja veerul on kommentaar andmekirjeldusega, mis vastab loogilise andmemudeli kirjeldusele.

#58 V Arendaja Arhitekt

9. Kasutajaliides

9.1 Kasutajaliidese kõik disainiotsused peavad olema kooskõlastatud Tellijaga enne nende realiseerimist.

V V V Arendaja Projektijuht

9.2 Veebipõhine kasutajaliides peab olema kasutatav enamlevinud veebibrauseritega, sh nutiseadmetel (Android, IOS).

Minimaalselt Microsoft Edge, Mozilla Firefox, Chrome ja Safari arenduse testimise hetkel tootja poolt toetatud versioonid.

Täpsemad nõuded dokumendis "Front-end arendusreeglid".

V V V Arendaja Testija

9.3 Rakenduse värviskeemi ja logo kasutamine peab vastama Tellija ametlikule visuaalsele identiteedile (CVI) ja disainijuhistele (UIG).

Kui tegemist on struktuurfondide projektiga, on lisaks nõutud ka vastav SF sümboolika. Tellija ametlikud CVI esitluspõhjad, logo kasutusjuhend ja kõik logod (ka jpg-na) küsida Tellijalt.

V V Arendaja Testija

9.4 Kasutajaliidese kõik osad ja teated peavad olema eestikeelsed.

Kui soovitakse juurde eraldi ka muid keeli, siis see on spetsifitseeritud hankedokumentides.

V V V Arendaja Testija

9.5 Sisemiseks kasutamiseks tehtav rakendus peab olema graafiliselt skaleeruv ja mugavalt kasutatav Tellija töökohaprofiilis loetletud resolutsioonides.

Toetatud peavad olema töökohaprofiilis loetletud resolutsioonid.

Ühegi nimetatud resolutsiooni korral ei tohi tekkida horisontaalset kerimisriba.

V V Arendaja Testija

9.6 Kasutajaliideses toiminguni (põhi- ehk enamkasutatavad tegevused) navigeerimiseks peab kehtima 3 kliki printsiip, väljalogimiseks 1 kliki printsiip.

Kõik rakenduse kasutajaliidesest tehtavad toimingud tohivad üksteisest olla maksimaalselt 3 hiirekliki kaugusel. Toimingut ei pea nende 3 klikiga tehtud saama. Väljalogimise nupp/link peab olema ühe kliki kaugusel ja arusaadavas/intuitiivses kohas.

V V Arendaja Testija

9.7 Kasutajaliides peab alati küsima kinnituse andmete kustutamise ja massmuutmiste kohta kui just teisiti kokku pole lepitud.

V V V Arendaja Testija

9.8 Rakenduse kasutamisel tekkinud veale peab kasutajaliides vastama kasutajale eestikeelse kasutajasõbraliku veateatega, mis sisaldab ka vea koodi. Veateated peavad olema hallatavad.

Veateated peavad olema sellised, mis võimaldavad IT- abil võimalikult lihtsalt tuvastada vea olemuse ja asukoha.

V V V Arendaja Testija

9.9 Kasutajaliides peab olema ilma rakenduse koodi muutmata tõlgitav teise keelde, v.a kui ei ole teisiti kokku lepitud.

Uue keele lisamine peab olema teostatav konfiguratsiooni failist või administreerimisliidesest.

Konkreetne lahendus tuleb kokku leppida Tellija arhitektiga.

V V Arendaja Testija

9.10 Rakenduse kasutajaliides peab teavitama kasutajat ette sessiooni aegumisest.

Etteteavitamise aeg peab olema konfigureeritav. V V V Arendaja Administraator

Testija

9.11 Kui vormile sisestatakse mahukaid andmevälju, peab kasutajaliides kokku lepitud ajavahemike järel salvetama välja sisu, et sessiooni aegumisel või võrgu katkestuse korral juba sisestatud andmed ei kaoks.

Näiteks kui vorm koosneb paljudest väiksest andmeväljadest (nt taotlus), siis jagatakse vorm etappideks ning salvestatakse vastava etapi lõpus.

V V Arendaja Testija

9.12 Interaktiivsete vormide puhul (näiteks faili üleslaadimine) ei tohiks lehe värskendamisega tegevust korrata (faili taas üles laadida, andmeid saata, avaldust esitada).

V V Arendaja Testija

9.13 Esilehel (sisselogimata) ja pärast kasutaja sisselogimist peab olema lihtne võimalus teavitada kasutajat muudatustest või probleemidest. Teavitus peab olema halduri poolt lihtsasti lisatav ja kasutajale märgatav.

Näiteks võimalikud teavitused: mingi süsteemi osa on vigane, tuli mingi uus funktsionaalsus, hetkel on hooldus, uuendage isikuandmeid jne.

Mõistlik on hooldusteate võimekiust juhtida taustteenuse abil. Näiteks läbi esitluskihi jaoks loodud seadete REST liidese.

V V Arendaja Testija

10. Dokumentatsioon

10.1 Lõppkasutajatele ja avalikkusele suunatud rakenduse dokumentatsioon peab olema kirjutatud eesti keeles.

Erandiks võivad olla kolmanda osapoole komponentide (mis pole kirjutatud Tellija jaoks) dokumentatsioon. Samuti võib erandiks olla väliste osapooltega seotud projektid. Erandid tuleb kooskõlastada Tellijaga enne dokumentatsiooni koostamist.

V V Arendaja Projektijuht

Arhitekt

Administraator

Testija

Infoturbe spetsialist

10.2 Lahendus kirjeldatakse RIHA määruse nõuete kohaselt.

https://www.riigiteataja.ee/akt/12933746? leiaKehtiv#para6

#57 V Arendaja

Projektijuht

Tellija RIHA haldur

Projektijuht

10.3 Rakenduse dokumentatsioon peab vastama dokumendis "Nõuded infosüsteemi dokumentatsioonile" kirjeldatud nõuetele.

Dokumentatsioon peab olema versioneeritud, muutmiskuupäevadega, autori nimedega, korrektse keelekasutusega, selge struktuuriga. Dokumentatsiooni detailsus peab olema piisav, et sõltumatu kolmas tehnliste IT baasteadmistega isik

V V Arendaja Projektijuht

Arhitekt

Administraator

suudaks dokumendist vajalikke järeldusi teha (st dokument peab olema arusaadav sellele isikule, kuid näiteks paigaldusjuhise järgi toimetades ei pea ta ebaõnnestunud tarnele teostama veaanalüüsi).

Täpsemad nõuded dokumendis "Nõuded infosüsteemi dokumentatsioonile".

Testija

Infoturbe spetsialist

10.4 Rakenduse dokumentatsioon peab sisaldama tabelite-andmete-logide mahu kasvu arvestuslikku hinnangut rakenduse sihipärase kasutamise korral ettenähtud arvu kasutajate poolt. (MB/GB kuus/aastas).

Esialgne kirjete mahu hinnang peab tulema lähteülesandest, ning täpsustuma eel- ja detailanalüüsi käigus. Mahuhinnang peab sisaldama ka logide säilitamise, arhiveerimise tähtaegu.

V V Arendaja Projektijuht

Arhitekt

Administraator

Infoturbe spetsialist

10.5 Iga uue versiooniga peab alati välja tooma versiooni muudatuse kirjeldused (release notes).

Release notes peab kajastama kõiki muudatusi eelmise ja uue versiooni vahel.

V V V Arendaja Projektijuht

10.6 Arendaja loodud lahenduse dokumentatsioonis (nt detailanalüüs vms) tuleb välja tuua kasutatavad krüpto- ja räsialgoritmid, nende võtmepikkused, kasutuskohad, sh TLS sertifikaatide kasutuskohad.

V V Aremdaja Arhitekt

Administraator

11. Versioonihaldus

11.1 Kogu rakenduse testimiseks, koolituseks või implementeerimiseks üle antav lähtekood ja tarkvarapaketid peavad olema versioneeritud. Kasutama peab Tellija versioonihalduse ja tehiste (artifaktide) repositooriumi.

Arendajale antakse selleks õigused Tellija versioonihalduse repositooriumi, kus ta peab hoidma oma erinevaid versioone. Versioonihalduse repositooriumi juurdepääsutaotlus esitatakse Tellija kasutajatoele läbi projektijuhi.

#1 V V Arendaja Arhitekt

Administraator

11.2 Arendaja peab veenduma, et teeb muudatusi aktuaalsesse koodi.

Hea tava on, et paralleelse arendamise puhul võetakse igal hommikul versioonihalduse repositooriumist viimane seis koodist.

V V Arendaja Arhitekt

Administraator

11.3 Nii arendamisel kui ka hoolduslepingute korral kasutatakse Tellija tööde ja veahalduse keskkonda.

Arendajale antakse selleks õigused Tellija tööde ja veahalduse keskkonda.

Veahalduse keskkonda juurdepääsutaotlus esitatakse Tellija kasutajatoele läbi projektijuhi.

V V Arendaja Projektijuht

11.4 Versioonihaldusesse muudatuste üleslaadimisel kasutada üleslaadimissõnumis Conventional Commits stiili.

https://www.conventionalcommits.org/ V Arendaja Arhitekt

12. Paigalduspaketi kooste

12.1 Rakendus on versioneeritud kasutades semantilise versioneerimise põhimõtet.

A.B.C kujul, kus C on veaparandus, B on funktsionaalne uuendus, mis töötab ka vanematel integratsioonidel ja A on integratsioone potentsiaalselt lõhkuv uuendus.

Versiooni suurt numbrit A kasutatakse ka API versiooni defineerimiseks.

Lisasoovitus: Kui major versioon saab uuenduse, siis peavad vanema versiooniga teenused hakkama tagastama päises teavitust, et versioon on deprecated (nt. X-API-Deprecated).

https://semver.org/

#15 V Arendaja Arhitekt

Administraator

12.2 Juhul kui versioonihalduse keskkond ei paku paigalduspaketile kontrollsumma (checksum) automaatset koostamist, siis koostatakse kontrollsumma arendaja poolt ja pannakse eraldi .sum failina tarnele kaasa.

Räsialgoritmiks tuleb kasutada SHA256. Linuxi käsurealt kontrollkoodi koostamiseks: $ sha256sum filename [filename2] ... > kontrollkood.sum.

V V Arendaja Administraator

12.3 Tarnitava lahenduse koosseisus üleantava lähtekoodiga peavad kaasas olema kirjeldused sellest paigalduspaketi koosteks.

Näiteks võib lahenduse paigalduspaketi koosteprotsess ette näha, et käivitada tuleb rida shell-käske või võivad lahenduse koosseisus olla valmis (ant, ..) koosteskriptid või mistahes muu moodus paigalduspaketi tekitamiseks.

Eelistatud on kasutada Dockerfile ja Gitlab töövooge.

V V Arendaja Projektijuht

Administraator

12.4 Kooste kirjelduste alusel valmiv paigalduspakett tohib sisaldada ainult minimaalse rakenduse käitamiseks vajamineva failikomplekti.

Näiteks: kompileeritavate keelte puhul ei tohi sisaldada lähtekoodi, kui see pole vajalik rakenduse käitamiseks.

V V Arendaja Arhitekt

Administraator

12.5 Kooste kirjelduste alusel valmivat paigalduspaketti peab olema võimalik liigutada erinevate masinate vahel.

Näiteks ei tohi tekitada olukorda, kus rakenduse jooksutamiseks uues serveris tuleb see tingimata just sealsamas kokku kompileerida.

V V Arendaja Administraator

12.6 Rakenduse kõik sõltuvused peavad olema kompileerimisel saadavad Tellija tehiste repositooriumist.

#4 V V Arendaja Arhitekt

12.7 Andmebaasi paigalduse skriptid ei tohi olla kompileeritud.

Administraator tahab veenduda skripti sisus. V V Arendaja Administraator

12.8 Rakenduse lähtekoodi juures peab leiduma skriptid rakenduse keskkonnast sõltumatult (konteinerlahenduses) kokku kompileerimiseks.

Tellijal peab olema võimalik suuri pingutusi tegemata ja keskkonna erinevusi vältides teha rakendusest paigaldatav pakk.

V V Arendaja Arhitekt

12.9 Rakenduse lähtekoodi juures peab leiduma skriptid rakenduse lokaalselt

Vajadusel peab konteinerlahendus käivitama ka rakenduse muud sõltuvused (näiteks andmebaas).

V V Arendaja Arhitekt

mõnes konteinerlahenduses (Docker) käivitamiseks.

See on Täitjale uue meeskonnaliikme liitumise lihtsustamiseks ja Tellijale võimalus suuri pingutusi tegemata süsteemi testimiseks.

12.10 Paigalduspakett koostatakse Tellija pideva integratsiooni (continuous integration - CI) ja paigaldus (continuous deploy - CD) arendus keskkonnas.

#13 V V Arendaja Arhitekt

12.11 Kubernetesel (K8s) orkestreeritavate lahenduste paigalduste jaoks tuleb luua Helm chart.

https://helm.sh/

Helmi jaoks kasutatava malli annab Tellijapoolne arhitekt.

V V Arendaja

Arhitekt

Arhitekt

Administraator

12.12 Kubernetesel (K8s) orkestreeritavate lahenduste paigalduste jaoks tuleb luua vajalikud automaatsed laienemise reeglid.

https://kubernetes.io/docs/tasks/run- application/horizontal-pod-autoscale/

V V Arendaja

Arhitekt

Arhitekt

Administraator

Nõuded infosüsteemi dokumentatsioonile

Nõuded infosüsteemi dokumentatsioonile Versioon: 1.0

Dokumendid peavad vastama vähemalt alljärgnevatele tingimustele:

Andmemudel  

Eeldus dokumendile: Teenuste/kasutuslugude dokumentatsioon

Otstarve: Kirjeldada andmeobjekte ja nendevahelisi seoseid

Sisu: Andmebaasi põhjal luua andmetabelite ja -objektide seosdiagramm.

Sihtgrupp: Tellija, peakasutajad, rakenduse administraatorid

Ajakava: enne esimese arendusetapi algust enne igat arendusetapi algust igakordsel tellijale testimisse andmisel

Kirjeldada andmemudelit kontseptuaalse mudelina

interaktioone/seoseid

jah jah

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 tellijale testimisse andmisel

Nimetada kasutaja rollid jah

 Teenuste/kasutuslugude dokumentatsioon

Eeldus dokumendile:

Süsteemi üldine kirjeldus

Otstarve: Kirjeldab detailselt üleantavaid teenuseid/kasutuslugusid.

Sisu: Teenuste/kasutuslugude detailse kirjelduse sisuks on:

Tehnilised parameetrid; Veateated/Hoiatused; Teostatavad kontrollid; Funktsionaalsuse enda põhiprotsess ja mõned sagedamini esinevad alternatiivsed protsessid (vastavalt vajadusele); Üldine kirjeldus, kuidas ja kus kajastub antud teenus/kasutuslugu tervikprotsessis; Nõudeid ja reegleid toetavad (sisu mõistmisele kaasaaitavad) pildid, diagrammid, tabelid, loendid Andmevahetuse teenuste kirjeldus (andmete küsimine/vastuvõtmine, turvalisus, teenuse andmestik, klassifikaatorid, xml/xsd schema ) Protsesside UML vaated

Sihtgrupp: Tellija äriprotsesse valdavad kontaktisikud, ärianalüütikud, süsteemianalüütikud, täitjast sõltumatud tarkvara hooldajad, arendajad ja edasiarendajad, testijad, arhitektid, projektijuhid.

Ajakava: enne esimese arendusetapi algust enne igat arendusetapi algust igakordsel tellijale testimisse andmisel

Nimetada kasutuslood jah

 Arhitektuuridokument 

Eeldus dokumendil e:

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: 1. topoloogia, süsteemi füüsiline arhitektuur (süsteemi komponendid andmebaasiserver, rakendusserver, meiliserver jms) 2. Nõuded arhitektuurile (operatsioonisüsteem, andmebaasid, liidestused, rakendusserverid, raamistikud, teenused)

3. Nõuded käideldavusele (süsteemi soovituslikud näitajad komponentide kaupa, näiteks andmesidekiirused, kättesaadavus, andmemahud, protsessori kiirus, mälumaht, komponentide arv süsteemi osade kaupa, kettasüsteemi jõudlus jms)

4. liidesed teiste süsteemidega (x-tee, meilisüsteemid) ja sõltuvused teistest süsteemidest. Liideste kirjeldused/otstarve

5. süsteemi tehnilised (sh automaatsed) protsessid ehk töövoog – komponentide omavahelised suhtlusstsenaariumid ja koostoimimine (näiteks, mis komponent ja millal pöördub n teenuse poole) 6. kolmandate osapoolte poolt toodetud kasutatavad tarkvarad/riistvarad, mis on vajalikud süsteemi toimimiseks

Sihtgrupp: Arhitekt, administraator, turvaspetsialist

Ajakava: enne esimese arendusetapi algust enne igat arendusetapi algust igakordsel tellijale testimisse andmisel

Dokumendi esialgne versioon jah

Seadmete ja tarkvara kasutajakesksed juhendid

Eel dus dok um end ile:

Teenuste/kasutuslugude dokumentatsioon

Ots tarv e:

Teenuse funktsionaalsuse kasutamiseks ja kasutuslugude läbimiseks vajalikud juhised

Sis u:

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

Siht gru pp:

Tarkvara kasutajad,  peakasutaja, rakenduse administraator

Aja kav a:

enne esimese arendusetapi algust enne igat arendusetapi algust igakordsel tellijale testimisse andmisel

jah

 Paigalduse ja administreerimise juhend 

Eeldus dokumendil e:

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.

4.1 Nõuded rakenduse komponentidele

4.2 Rakenduse paigaldus (Vajalik tarkvara ja konfigureerimine, rakenduse pakkimine ja paigaldamine)

4.3 Andmete alglaadimine

4.4 Varundusskript

4.5 Monitooringu kirjeldus

Juhendis kirjeldatakse iga realiseeritud osa rakendamine koos spetsiifiliste seadistustega. Paigaldamise protseduurid peavad olema kirjutatud (deployment) selliselt (samm sammult), et süsteemiadministraator suudab rakenduse paigaldada ilma kõrvalise abita.

Sihtgrupp: Peakasutaja, projektijuht, süsteemiadministraator

Ajakava: enne esimese arendusetapi algust enne igat arendusetapi algust igakordsel tellijale testimisse andmisel

jah

 Lähtekood (sh andmebaasi struktuur)

Eeldus dokumendile: Arhitektuuridokument Teenuste/kasutuslugude dokumentatsioon Andmemudel Kasutaja õiguste ja tegevuste vastavustabel Prototüüp

Otstarve: Lähtekood on vajalik selleks et kompileerida rakendust, ning võimaldada tulevikus rakenduse muutmist.

Sisu: Lähtekood peab olema hästi struktureeritud, piisavalt dokumenteeritud ning võimalikult lihtne, et sellest saaksid aru ka teised arendajad. Lähtekood peab vastama MFNile Lähtekood peab olema pakendatud vastavalt versioonimisjuhendile. Rakenduste lähtekood peab olema piisavalt modulaarne, et seda saaks tulevikus lihtsasti täiendada ning muuta.

Ajakava: enne esimese arendusetapi algust enne igat arendusetapi algust igakordsel tellijale testimisse andmisel

Versioonihaldus tuleb teha Tellijakeskkonnas (nt Gitlab), sh ka jooksvaid commit’e

 Koormustestide dokumentatsioon 

Eeldus dokumendile: Teenuste/kasutuslugude dokumentatsioon

Prototüüp (ainult kasutajaliidesega rakenduse puhul) Arhitektuuridokument

Otstarve: Määrata kindlaks arendusetapil testitavad kasutuslood ja liidesed (sh välja tuua need, mille puhul rakendatakse koormusteste) tuues välja nende järjekorra.

Sisu: Järjestatud (võib olla ka paralleelne) nimekiri kasutuslugudest ja liidestest (vajadusel määrates nende ulatust) koos märkega, mis on koormustestiga tagatud ning millel on testandmed

Sihtgrupp: Tellijapoolne projektijuht, vastuvõtutestijad

Ajakava: enne esimese arendusetapi algust enne igat arendusetapi algust igakordsel tellijale testimisse andmisel

Nimetada kasutuslood, mille puhul rakendatakse koormusteste  jah

 Testimise tulemite dokumentatsioon

Eeldus dokume ndile:

Koormustestide dokumentatsioon

Otstarv e:

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). Dokumenteeritakse iga testimise eesmärgid (testimise maht ja ulatus), tegevused ja tulemused. Sisaldab jõudlus- ja mahutestide infot ning versiooni infot. Teste mitteläbinud testlugudele on lisatud parandused või ülesjäänud vead. MFNi vastavustabel

Sihtgru pp:

Arhitekt, süsteemiadministraator, turvaspetsialist

Ajakava: enne esimese arendusetapi algust enne igat arendusetapi algust igakordsel tellijale testimisse andmisel

jah

Automaattestimise tulemite dokumentatsioon

Eeldus dokumendile: Lähtekood (sh andmebaasi struktuur)

Otstarve: Anda tellijale ülevaade läbiviidud automaattestimise tulemustest.

Sisu: Ülevaade SonarQube’is (testide nimekiri, testide käivitamise tulemus, koodi kaetavus).

Sihtgrupp: Arhitekt, süsteemiadministraator, turvaspetsialist

Ajakava: enne esimese arendusetapi algust enne igat arendusetapi algust igakordsel tellijale testimisse andmisel

jah

Taasteplaani tegemise juhend 

Otstarve: Kirjeldada erisused, millega tuleb arvestada taasteplaani loomisel

Sisu: Taasteplaan peab rahuldama vähemalt alljärgnevaid sisunõudeid: 1. süsteemi halvamist võimaldavad riskid ja nende esinemise võimalikkus; 2. varundamisele kuuluvate komponentide ja asukohtade loetelu (nt rakenduse konfiguratsioonifailid rakendusserverist ja andmebaas jne), nende kirjeldused ja kasutuselevõtu protseduurid; 3. süsteemi komponentide asendusvõimalused, nende alternatiivkomponentide spetsifikatsioonid

Sihtgrupp: Arhitekt, süsteemiadministraator, turvaspetsialist, äri, tellijapoolne projektijuht

Ajakava: enne esimese arendusetapi algust enne igat arendusetapi algust igakordsel tellijale testimisse andmisel

jah

Üldised nõuded:

Üleantav dokument peab sisaldama sisseviidud muudatusi nii, et on väljatoodud muutunud ja lisandunud osa (võrreldes viimati üleantuga). 

IT-Profiil (versioon: 3)

Sotsiaalministeeriumi valitsemisala riist- ja tarkvara ning e-teenuste üldine haldamise ja arendamise infotehnoloogiline profiil

Üldsätted

1. Infotehnoloogilise profiili (edaspidi IT profiili) eesmärgid on: 1. kirjeldada Tervise ja Heaolu Infosüsteemide Keskuse (edaspidi TEHIK) hallatava riist- ja tarkvara tüüpkonfiguratsioone ja nende

miinimumparameetreid; 2. haldus-, hooldus- ja koolituskulude vähendamine olemasolevale infosüsteemile; 3. tekkida võivate probleemide ja kulude minimeerimine läbi erinevate infosüsteemi osade integreerimise; 4. jätkuva arengu garanteerimine kõigile kasutatavatele infotehnoloogilistele (edaspidi IT) lahendustele Sotsiaalministeeriumi haldusalas; 5. kasutatava tarkvara ja riistvara ühtsuse saavutamine, mille abil on tsentraliseeritud hangete kaudu võimalik märkimisväärselt kokku hoida; 6. süsteemidele mõjuvate turvariskide minimeerimine; 7. tekitada süsteemide kasutajatele efektiivne, turvaline ja mugav töökeskkond;

2. Karbitoodete valikul ja implementeerimisel rakendada IT profiili võimalikult suurel mahul. IT profiilist kõrvalekalded on lubatud, kui need on möödapääsmatud ja TEHIK arhitektuurinõukogus kooskõlastatud;

3. IT profiili korrigeeritakse vastavalt vajadusele kuid mitte harvemini kui üks kord aastas. Muudetud IT profiil kinnitatakse TEHIK arhitektuurinõukogu poolt;

Tehnilised nõuded e-teenustele, lähtudes TEHIK'u hallatavatest infosüsteemidest ja infrastruktuurist

1. IT toodete ja komponentide valiku põhimõtted on: 1. sama funktsionaalsusega, kuid erinevate tootjate komponentide arv peab olema viidud miinimumini. Standard riistvara soetamisel

eelistada soovitavalt ühe tootja seadmeid, mis tagab kogu IT infrastruktuuri parema toimivuse ja seadmete ühilduvuse; 2. kõik valitud tooted peavad vastama kehtivatele standarditele, eelistada tuleb avatud standardeid; 3. testistaadiumis (beta, release candidate jne) tarkvara võib kasutada ainult testimise eesmärgil; 4. komponendid ja tooted peavad vastama asutuse poolt määratud turvareeglitele; 5. komponentide ja toodete, mis ei ole antud dokumendis kajastatud, kasutusele võtmine vajab eelnevat arhitektuurinõukogu heakskiitu;

Kehtib nii olemasolevate süsteemide uuendamise kui ka uute süsteemide loomise kohta (Applies to building brand new systems and also to refactoring existing systems)

Komponent

(Component)

Eelistatud

(Preferred)

Aktsepteeritav

(Acceptable)

Mitte valida

(Do not select) Kommentaarid

Kliendi kiht (Client Layer)

Lauaarvuti ja sülearvuti OS / keskkond (Desktop & laptop client OS / environment)

• Windows • Linux • macOS

Lauaarvuti ja sülearvuti kliendi kasutajaliides (Desktop & laptop client user interface)

• Chromium based • Firefox

• Safari (väline klient/external client)

• Edge Legacy • Internet Explorer

Mobiilse kliendi OS / keskkond (Mobile client OS / environment)

• Android perekond (Android family)

• iOS • Windows Phone

Mobiilse kliendi kasutajaliides (Mobile client user interface)

• Chromium based • Firefox • Safari

• Multi platform frameworks

o Flutter o Kotlin

Multiplatform • Native app

• Multi platform frameworks

o .Net based o Nativescript o Ionic

Esitluskiht (Presentation Layer)

Sisuhaldussüsteem (Content management system)

• Drupal • Strapi[1] • WikiJS[1]

• Joomla! • WordPress

[1] Tuleb TEHIKu arhitektiga kooskõlastada (Must be coordinated with TEHIK architect)

Esitluskihi raamistik (Presentation framework (View))

• JavaScript o Angular o React

• JavaScript o Next.JS[1] o Single-SPA o Web-pack

• Java o JSP o JSF

• iFrame • Microsoft .Net • Python

[1] Tuleb TEHIKu arhitektiga kooskõlastada (Must be coordinated with TEHIK architect)

Veebiserver (Web server) • Nginx

• Apache HTTP server

• Microsoft IIS

IT-Profiil (versioon: 3)

Funktsionaalne testimine (Functional testing)

• Selenium • Selenide

• Cypress[1] • Playwright[1]

[1] Tuleb TEHIKu arhitektiga kooskõlastada (Must be coordinated with TEHIK architect)

Rakenduskiht (Application Layer)

Rakenduse raamistik (Application framework)

• Java o Spring[1] o Spring boot

• Java o Quarkus[2]

• Java o Micronaut

• C# o .Net o .Net

Framework o ASP.NET o Entity

Framework Core

[1] Kogu Springi perekond (All Spring family)

[2] Tuleb TEHIKu arhitektiga kooskõlastada (Must be coordinated with TEHIK architect)

Protsessimootor (Workflow Engine)

• Zeebe

Andmeloogika (Persistence framework)

• Java o JPA o JDBCTemplate

• Java o Hibernate[1] o jOOQ

[1] Tuleb TEHIKu arhitektiga kooskõlastada (Must be coordinated with TEHIK architect)

Otsingumootori indeks (Search Engine Index)

• Elasticsearch

Integratsioon (External integration (integration to other systems))

• AMQP[1] • REST

• GraphQL[2] • gRPC[2] • SOAP

• Oracle Advanced Queuing

[1] RabbitMQ

[2] Tuleb TEHIKu arhitektiga kooskõlastada (Must be coordinated with TEHIK architect)

Andmete laadimine (Data Loading - ETL)

• Apache Hop • OData consumer [1]

• Meltano[2] • Pentaho[2]

[1] TEHIKu toode (TEHIK's product)

[2] Tuleb TEHIKu arhitektiga kooskõlastada (Must be coordinated with TEHIK architect)

Aplikatsiooniserver (Application server)

• Java o Tomcat o Embedded

▪ Jetty ▪ Tomcat ▪ WildFly

o GraalVM

• Java o WildFly [1]

• Webmethods Integration Server

• .NET o MS IIS

• Java o Apache

JServ o Sun Java

System Application Server

o SAP o IBM

WebSphere o Oracle iAS o Oracle

iPlanet Web Server

o WebLogic

[1] VM põhine (VM based)

Funktsionaalne testimine (Functional testing)

• Insomnia • SoapUI

• Postman

Koormustestimine (Load testing)

• Jmeter • Gatling

• Testkube

Andmekiht (Persistence Layer / Database layer)

Andmebaasi migratsioon (Database migration)

• Liquibase • Flyway

Relatsiooniline andmebaas (Relational DBMS)

• PostgreSQL • MariaDB[1] • MS SQL Server • Oracle DB • Sybase

[1] Tuleb TEHIKu arhitektiga kooskõlastada (Must be coordinated with TEHIK architect)

IT-Profiil (versioon: 3)

Mitte ainult SQL (NoSQL) • KeyDB

• MongoDB[1] • Valkey[2]

• Redis

[1] Tuleb TEHIKu arhitektiga kooskõlastada (Must be coordinated with TEHIK architect)

[2] https://valkey.io/

Andmeladu (Data Warehouse)

• Vertica • Sybase IQ

Andmete replikatsioon (Data Replication)

• Spilo

Failide hoiustamine (Object Storage)

• MinIO • S3 protokollil

põhinevad objektihoidlad

• Failid andmebaasis (BLOB)

Infrastruktuuri kiht (Infrastructure Layer)

Directory services • MS Active Directory

Autentimine ja Ühekordne

sisselogimine (Authentication

and Single Sign On)

• GovSSO • TEHIK SSO[1]

[1] TEHIK SSO on asutuseväliste kasutajate vaates liikumas toe lõppemise suunas. (TEHIK SSO is moving towards end of life)

Kasutajaõiguste haldus (Authorization)

• Pääsuke [1] • TEHIK SSO AD realm[2]

• TEHIK SSO + rollide api teenuse pool[3]

• MS AD (siseteenused)

[1] https://www.ria.ee/riigi- infosusteem/kesksed- platvormid-avalike-e-teenuste- pakkumiseks/paasuke

[2] On mõeldud siseste kasutajate rollide jaoks (Is ment for inside user rolls)

[3] TEHIK SSO on asutuseväliste kasutajate vaates liikumas toe lõppemise suunas. (TEHIK SSO for external users is moving towards end of life)

Identiteedi haldus (Identity management)

• MIM[1]

[1] Tootel on saabumas eluea lõpp (Product is moving towards end of life): https://learn.microsoft.com/en- us/lifecycle/products/microsoft- identity-manager-2016

Logihaldus (Log management)

• Elastic Agent/Elastic Beats/Logstash

• rsyslog

• GreyLog • Windows Event

Collector

Süsteemi haldamine ja järelevalve (System management and monitoring)

• Prometheus • Grafana • Elastic APM

• Zabbix • Nagios

Koormusjaotur (Traffic management)

• Nginx • HAProxy

Puhverdamine (Caching) • Nginx

• Squid • Varnish

Tööde ajastamine (Job scheduling)

• Application specific decision ie Quartz or cron, windows scheduler

• k8s CronJob

Serveri operatsioonisüsteem (Server OS)

• Linux (Tootja poolt viimane pikaajalise toega või stabiilne versioon)

o Oracle Linux o RedHat o Ubuntu

• Windows o MS (64 bit)

• Linux o Debian o CentOS

• IBM AIX • Other UNIXs

IT-Profiil (versioon: 3)

Konteinerid (Containers) • OCI compliant[1] [1] https://opencontainers.org

Konteinerite orkestreerimine (Contaier orchestration)

• Kubernetes • Docker Swarm

Virtualiseerimine (Virtualization)

• VmWare

• Hyper-V • QEMU/KVM • OracleVM • Xen

Serveri riistvara (Server hardware)

• x86_64 • RISC

Varundamine (Backup)

• VmWare o Veritas

Netbackup • Kubernetes

o S3

• Symantec Backup

Exec

Kettakasti riistvara (Storage hardware)

• SAN o FC >= 32 Gb/s

• SAN o FC >= 16 Gb/s

• iSCSI

Riistvaraline krüptomoodul (HSM - Hardware security module)

• Thales • Utimaco

Tulemüür (Firewall)

• DPI (Deep packet inspection) Layer 7 Pahavara tõrje (Anti- malware)

Muud aspektid (Other Aspects)

Programmeerimiskeeled (Programming languages)

• Java • TypeScript

• Go[1] • JavaScript • Kotlin[1] • Python[1] • PHP[1] • Rust[1][2]

• NET • C/C++/C# • Webmethods flow • iWay Functional

Language

[1] Tuleb TEHIKu arhitektiga kooskõlastada (Must be coordinated with TEHIK architect)

[2] Krüptograafiliste tegevuste teostamiseks (To perform cryptographic activities)

Java virtuaalmasina implementatsioon (Java vitual machine implemetation)

• OpenJDK • Oracle JDK

Versioonihaldus (Version control system)

• GitLab o Koodivaramu[1] o TEHIK

haldusalas olev

• GitHub[1] • SVN • Atlassian Bitbucket

[1] Tuleb TEHIKu arhitektiga kooskõlastada (Must be coordinated with TEHIK architect)

Artefaktide repositoorium (Artifacts repository)

• JFrog artifactory • Gitlab registry

• DockerHub[1] • GitHub Packages[1] • npmjs.com[1]

[1] Tuleb TEHIKu arhitektiga kooskõlastada (Must be coordinated with TEHIK architect)

Pidev integratsioon (Continuous integration)

• Gitlab CI • Github Actions[1] • Jenkins • Bamboo

[1] Tuleb TEHIKu arhitektiga kooskõlastada (Must be coordinated with TEHIK architect)

Paigalduse automaatika (Continious Deployment / Delivery)

• Ansible • GitLab CD (dev/test) • Helm (live) • Terraform

• GitHub Actions[1] • Argo CD[1]

• Jenkins • Bamboo

[1] Tuleb TEHIKu arhitektiga kooskõlastada (Must be coordinated with TEHIK architect)

Lähtekoodi analüüs (Code analysis)

• SonarQube

Tarkvara materjalide loend (SBOM - software bill of materials)

• CycloneDX SBOM

Tarkvara materjalide loendi analüsaator

• Dependency-Track[1] [1] https://dependencytrack.org

IT-Profiil (versioon: 3)

(software bill of materials analysis platform)

Analüütika (Analytics) • Tableau • Apache Superset[1]

• Webfocus • Qlik Sense • Oracle BI Publisher • SAP® Business

Objects

[1] Tuleb TEHIKu arhitektiga kooskõlastada (Must be coordinated with TEHIK architect)

Serverid

1. Riistvara standard 1. X86-64 platvorm 2. Dubleeritud komponendid (toiteplokid, ventilaatorid jms.) 3. Kuumvahetatavad kettad 4. Kaughaldusliidese olemasolu koos vajalike funktsioonide litsentseeritusega (irdmeedia tugi jms.), kaughaldusliides peab toimima

modernsete veebilehitsejatega ilma java/flash toeta) 5. Ostetaval riistvaral peab võimalusel olema vähemalt kaks teineteisest sõltumatut (st. ei tohi olla sama firma/grupi koosseisus) volitatud

hooldus/garantiiteenuse pakkujat 6. Riistvara ostetakse reeglina kolme aastase NBD toega koos nõudega, et kriitiliste varuosade vaheladu peab olema Eestis kohapeal.

Automaattestide kasutamise nõuded

Üldised nõuded Tehnilised nõuded

Üldised nõuded Nõude nr

Nõude sisu Seletused Koostamise eest vastutaja

Testimise läbi viib või kinnitab

1. Automatiseeritavad testiliikide testid

1.1 Automatiseeritakse kokkulepitud või minimaalse skoobi testiliikide testid

Iga lahendus vaadatakse eraldi üle ja lepitakse kokku, milliseid testiliike peab lahenduse testimisel automatiseerima ja läbima.

komponenttestid (unit testid), integratsioonitestid, liideste testid, süsteemitestid ( ), Minimaalne skoop - end-to-end testid robustsuse testid ja koormustestid. Komponenttestid (unit testid) ja integrtatsioonitestid käivitatakse enne reliisi kokku ehitamist.

skriptis on sammudes kirjas, et läbitakse komponenttestid (unit testid) ja integratsioonitestid, kui on edukalt Buildi läbitud, siis koostatakse  .build

Liideste testid, süsteemitestid ( ), robustsuse testid ja koormustestid läbitakse peale reliisi paigaldust end-to-end testid keskkonda.

Peale tegemist läbitakse liideste testid, süsteemitestid ( ), robustsuse testid ja koormustestid.buildi end-to-end testid

Arendaja Arendaja testija TEHIK testija

1.2 Minimaalne skoop

1.2.1 Komponenttestid (unittestid) Testimise eesmärk on kontrollida süsteemi komponendid töötavad erinevates olukordades ootuspäraselt.

Komponenttestid (unit testid) testitakse süsteemi üksikuid komponente. Eesmärk on kinnitada, et süsteemi koodi kõik komponendid toimivad ootuspäraselt. Komponenttestimine (unit testimine) toimub süsteemi väljatöötamise (süsteemi koodi kirjutamise etapis) arendajate poolt. Komponenttestid (unit testid) eraldavad süsteemi koodi osa ja testid, mis kontrollivad süsteemi koodi ootuspärasust. Komponent võib olla individuaalne funktsioon, meetod, protseduur, moodul või objekt.

Komponenttestid (unit testid) käivitatakse enne koodi kokku ehitamist. Komponenttestid (unit testid) on üks osa üleantavast koodist. Peab vastama MFN nõudele 4.21 ( ).https://wiki.sm.ee/pages/viewpage.action?pageId=3834694

Siin tuleb arvestada teekide mittetestimisega, muidu on koodi hindamise hinnangud valed. Iga lahenduse juures otsustab arhitekt, kas aksepteeritav on madalam komponenttestide (unit testide) katvuse protsent kui on MFN nõue 4.21 kirjas. Kui ei ole otsust, et on aksepteeritav ka madalam komponenttestide (unit testide) katvuse protsent, siis aksepteeritav on MFN nõue 4.21 kirjas olev katvuse protsent.

Koodi katvuse automaattestide komponenttestidega (unit testidega) kontrollimiseks kasutame tööriista  (SonarQube sonar. ).tehik.ee

's kontrollime bugide ja haavatavuse taset ning alla taset ei ole aksepteeritav.SonarQube A 

Arendaja Arendaja testija

TEHIK testija

1.2.2 Integratsioonitestid

Testimise eesmärk on kontrollida, kas integreeritud komponentide omavaheline kootöö toimib.

Integratsioonitestides on komponendid integreeritud ja testitakse komponentide omavahelist koostöö toimimist. Tüüpiline tarkvara projekt sisaldab mitmeid komponente, mida kirjutavad erinevad arendajad. Integratsioonitesti eesmärk on tuvastada vead nende komponentide integratsioonis. Keskendutakse komponentide omavahelise andmeside kontrollimisele.

Integratsioonitestid käivitatakse enne koodi kokku ehitamist. Integratsioonitestid on üks osa üleantavast koodist. Testitakse komponentide integreerumist süsteemis.

Vajalikke integreeritud komponentide omavahelist toimimise testimiseks kasutatakse, kas 'e või käivitatakse mock konteineris etteantud andmestik. Saab kasutada nt. https://www.testcontainers.org/ võimalusi.

Käivitatakse koos komponenttestide (unit testide) töövoos. Integratsioonitestid peavad olema projektis, kus hoitakse süsteemi koodi, et saaks neid teste kasutada.

Arendaja Arendaja testija

TEHIK testija

1.2.3 Liideste testid

Testimise eesmärk on kontrollida, et kas kaks erinevat süsteemi töötavad ja edastavad andmeid omavahel ootuspäraselt.

Liideste testid kontrollivad, kas kahe erineva süsteemi vaheline suhtlus toimib. Ühendus, mis integreerib kahte komponenti nimetatakse liideseks nagu nt. API'd, veebiteenused jne. Nende ühenduse teenuste või liidestega testimist nimetatakse liideste testimiseks. Liides on tarkvara, mis koosneb käskude komplektidest, teadetest ja muudest atribuutidest, mis võimaldavad teenuse ja kasutaja vahelist suhtlust. Väliste süsteemidega liidestumise testimisel tuleb kontrollida kõigi liideste toimimist.

Liideste testid käivitatakse peale reliisi paigaldust keskkonda. Lisaks positiivsele töövoole seatakse rõhku ka negatiivsele töövoole. Testitakse kahe erineva süsteemiga nende omavahelist suhtlust ja edastatavaid andmeid.

Vajalike liideseid testimiseks ei 'ta ega käivitata konteineris etteantud andmestikuga.mock Vajalike liideste testimiseks kasutatakse  'd.x-tee

Võimalik kasutada töövahendeid nagu nt. postman/newman ( ) lahendust.https://www.postman.com/ Liideste testid peavad olema projektis, kus hoitakse süsteemi koodi, et saaks neid teste kasutada.

Arendaja Arendaja testija

TEHIK testija

1.2.4 Süsteemitestid (end-to-

)end testid Testimise eesmärk on kontrollida, kas integreeritud süsteem vastab määratud nõuetele ehk testimine peab katma funktsionaalseid ja mitte-funktsionaalseid nõudeid.

Süsteemitestid ( ) kontrollitakse integreeritud süsteem vastab määratud funktsionaalsetele- ja mitte-end-to-end testid funktsionaalsetele nõuetele ning seetõttu läbitakse testi tüübi testid funktsionaalne testimine ja mitte-funktsionaalne testimine.

Funktsionaalse testimisega veendutakse, et arendatud funktsionaalsus ja/või muudetud funktsionaalsus on realiseeritud ja töötab ootuspäraselt. Mitte-funktsionaalse testimisega veendutakse, et arendatud funktsionaalsus ja/või muudetud funktsionaalsus vastab mitte-funktsionaalsetele nõuetele.

Vastavalt vajadusele läbitakse kasutajaliidese süsteemitestid ( ).end-to-end testid

Mõnel lahendusel ei ole kasutajaliidest, siis läbitakse ainult backend tasemel süsteemitestid ( ).end-to-end testid Mõnel lahendusel on kasutajaliides, siis läbitakse nii front-end kui backend tasemel süsteemitestid ( ).end-to-end testid

Süsteemitestid ( ) käivitatakse peale reliisi paigaldust keskkonda.end-to-end testid Peab vastama MFN nõudele 4.22 ( ).https://wiki.sm.ee/pages/viewpage.action?pageId=3834694

Katvuse protsenti kontrollime hetkel manuaalselt ehk kontrollime automaatsete süsteemitestide ( ) end-to-end testide koodi ja hindame, kas automaattestidega on katvuse protsent vastavus funktsionaalsusega, mis on kirjas MFN nõudes 4.22. Plaan tulevikus kasutusele võtta katvuse protsendi kontrollimiseks tööriista   funktsiooni  .Xray Requirement Coverage

Hallatakse eraldi projektis, kus ei hoita süsteemi koodi ning mis sisaldab ainult süsteemiteste ( ).end-to-end teste

Arendaja Arendaja testija

TEHIK testija

1.2.5 Robustsuse testid

Testimise eesmärk on kontrollida süsteemi käitumist ning töö taastumist veaolukordades.

Robustsuse testid keskenduvad olukordadele, kus süsteemi enda mõni komponent või komponendid ei toimi osaliselt (nt. tagastavad valesid tulemusi) või ei toimi üldse (nt. liidese kaudu info edastamine on blokeeritud).

Robustsuse testid käivitatakse peale reliisi paigaldust keskkonda. Hallatakse eraldi projektis, kus ei hoita süsteemi koodi ning mis sisaldab ainult robustsuse teste.

Arendaja Arendaja testija

TEHIK testija

1.2.6 Koormustestid

Koormustestimise eesmärk on kontrollida süsteemi käitumist reaalsetes koormustingimustes ja mitu kasutajat korraga saavad teha paralleelselt tegevusi.

Koormustestide läbimisel määratakse süsteemi maksimaalne koormus, et kontrollida süsteemi käitumist reaalsetes koormustingimustes ja mitu kasutajat saavad teha paralleelseid tegevusi, Koormustestid on mitte-funktsionaalsete nõuete testimise tüüp.

Koormustestid läbitakse, et leida süsteemi koormuse piirkohtade leidmiseks. Koormustestid käivitatakse sprindi lõpus, et veenduda süsteemi koormustaluvus ei ole kehvemaks muutunud. Peab vastama MFN nõudele 4.17 ( ).https://wiki.sm.ee/pages/viewpage.action?pageId=3834694 Hallatakse eraldi projektis, kus ei hoita süsteemi koodi ning mis sisaldab ainult koormusteste.

Arendaja Arendaja testija

TEHIK testija

2 Automatiseeritud testiliikide testid kasutatakse vähemalt arenduskeskkonnas ja testkeskkonnas või kui on kokkulepitud, siis ka teistes keskkondades

Arenduskeskkonnas kasutatakse automatiseeritud teste testiliikide testide testimiseks. Arendaja ja TEHIK peavad koostöös panema arenduskeskkonnas olevad testiliikide automaattestid tööle ka vähemalt testkeskkonnas või kui on kokkulepitud, siis ka teistes olemasolevates keskkondades.

Arendaja

TEHIK

Arendaja testija

TEHIK tehniline testija

TEHIK testija

3 Automatiseeritud testiliikide testide haldamine

Automatiseeritud testiliikide haldamisega ja ajakohasena hoidmisega tegeleb arendaja. Arendaja Arendaja testija

TEHIK tehniline testija

TEHIK testija

4. Automaatestide haldamiseks kasutatakse  'i Domain Driven Design (DDD)

4.1 Koodihalduseks kasutatakse tööriista GitLab

Kõik rakenduste lähtekoodid, automaattestid jm. seotud failid peavad asuma GitLab's ( ).https://gitlab.sotsiaalministeerium.ee/ Arendaja

TEHIK

Arendaja

Arendaja testija

TEHIK arhitekt

TEHIK administraator

TEHIK tehniline testija

TEHIK testija

4.2 Projektide haldamiseks kasutatakse Domain

'i Driven Design (DDD) Domain Driven Design (DDD) - konseptsioon, mille kohaselt koodi struktuur ja keel (klassi nimed, klassi meetodid, klassi muutujad) peaksid ühtima äri domeeniga. Domain Driven Design (DDD) põhineb printsiipidel - põhirõhk on peamisel domeenil ja domeeni loogikal, keerukate disainide koostamine domeeni mudelile ning tehniliste ja domeeni ekspertidega koostöös täpsustatakse/lahendatakse iteratiivselt konseptuaalsete mudelite domeeni probleeme. Rohkem infot leiab .siit

Projektide haldamiseks kasutatatakse  kuna hallatakse projekti domeeni üleselt kui ka Domain Driven Design (DDD) valdkonna põhiselt ehk iga domeeni eraldi.

Projekti domeeni ülesel tehtud muudatused mõjutavad projekti domeeni üleselt. Iga domeen eraldi on kindla valdkonna domeen nagu nt. süsteemitestid ( ).end-to-end testid

Seal tehtavad muudatused mõjutab ainult antud valdkonna domeeni mitte projekti ülest domeeni.

Projekti haldamise struktuur, mida kasutame GitLab's: Projekti jaoks koostatakse .grupp Projekti alla lisatakse peamine projekti , mis sisaldab:gruppi test repositoorium

Lähtekoodi. Komponentteste (unitteste). Integratsiooniteste. Liideste teste.

Projekti alla lisatakse projekti süsteemitestide ( ) , mis sisaldab:gruppi end-to-end testid test repositoorium Süsteemiteste ( ).end-to-end teste

Projekti alla lisatakse projekti robustsuse testid , mis sisaldab:gruppi test repositoorium Robustsuse teste.

Projekti alla lisatakse projekti koormustestid , mis sisaldab:gruppi test repositoorium Koormusteste.

Projekti alla saab lisada ka , kuid sel juhul on   loogika kasutamine sama, mis grupide alam gruppe test repositooriumi peamise all.gruppi Peamine projekti  on domeeni ülene ehk kui seal tehakse muudatus, siis see mõjutab projekti domeeni test repositoorium üleselt. Ülejäänud projekti  on ühe domeeni põhised ehk kui tehakse muudatus nt. süsteemitestide (test repositoorium end-to-end

) , siis mõjutab ainult süsteemitestide ( ) domeeni.testide test repositooriumis end-to-end testide

GitLabis terminite vastavused  terminitega:Domain Driven Design (DDD) 

GitLab: grupp - DDD: projekt; GitLab: test repositoorium - DDD: domeen.

Arendaja

TEHIK

Arendaja

Arendaja testija

TEHIK arhitekt

TEHIK administraator

TEHIK tehniline testija

TEHIK testija

5.  ja automaattestide käivitamise protsesside kasutamineContinous Integratsioni (CI)

5.1 Kasutatakse automaatset  Continous Integratsioni

protsessi(CI)  Continous Integratsion (CI) - tarkvaraarenduses järgitav tava, kus arendajad pidevalt oma koodi ühisesse hoidlasse üles panevad. Iga muudatust kontrollib automaatne protsess, mis tagab arendusprotsessi stabiilsuse ning kui esineb vigu, leitakse need kiiresti. Selleks et arendajate tehtud muudatused koodis ei jääks isoleerituks, peavad arendajad oma muudatused ühishoidlas asuva koodiga liitma. Nende muudatuste edukust testitakse kohe, luues uus tarkvaraversioon (build ), mida testivad automaattestid. Pidev integratsioon säästab aega, kuna identifitseerib varakult koodimuudatustest tulenevad konfliktid ja regressioonid, kuid selle edukaks läbiviimiseks on vaja palju automaatteste. Rohkem infot leiab  .siit

Automaatne Continous Integratsion (CI) protsess: Läbitakse koostamisel automaattestid - komponenttestid (unittestid) ja integratsioonitestid.buildi 

Komponenttestid (unittestid) ja integratsioonitestid on läbitud edukalt ning koostatakse  .build Komponenttestid (unittestid) ja integratsioonitestid on läbitud mitte-edukalt ning katkestatakse  koostamibuildi ne. 

Tehakse  .deploy Läbitakse automaattestid - liideste testid, süsteemitestid testid) robustsuse testid ja koormustestid.(end-to-end ,

Liideste testid, süsteemitestid ( ), robustsuse testid ja koormustestid on läbitud edukalt ning end-to-end testid lõpetatakse protsess. Liideste testid, süsteemitestid ( ), robustsuse testid ja koormustestid on läbitud mitte-end-to-end testid edukalt ning tehakse keskkonnas  .rollback

ei tehta arenduskeskkonnas, aga testkeskonnas ja teistes kokkulepitud keskkondades Rollback  tehakse  .rollback

Continious Integratsion (CI) protsessi ehk reliisi üleandmise joonis Lisa 1. Automaattestide kasutamise nõuete .joonised#Lisa1.1ContinousIntegration(CI)protsessehkreliis%C3%BCleandmiseksvalmis

Lepitakse iga lahenduse juures eraldi kokku, milline peaks olema  ehk peaks kõik Continous Integratsion (CI)  automatiseeritud testiliigid läbima iga reliisi paigalduse korral või mõned automaattestid - robustsuste testid ja koormustestid - võiksid olla ka eraldi manuaalselt käivitatavad.

Projektis on mitu domeeni, kuid luuakse üks  GitLab Pipeline.Continous Integratsion (CI)  GitLab Pipeline struktuur:

Tests Läbitakse komponenttestid (unittestid) ja integratsioonitestid.

Build Koostatakse .build

Deploy Tehakse .deploy

Interface tests Läbitakse liideste testid.

System tests ( )end-to-end tests Läbitakse süsteemitestid ( ).end-to-end testid

Robustness tests Läbitakse robustsuse testid.

Load tests Läbitakse koormustestid.

Arendaja

TEHIK

Arendaja

Arendaja testija

TEHIK arhitekt

TEHIK administraator

TEHIK tehniline testija

TEHIK testija

5.2 Tarnete paigaldus peab olema automatiseeritud Eeldus nõudele .Üldised nõuded nõue 4.1

Tarne paigalduse automatiseerimiseks on kaks varianti: 

Täiesti automaatne, et kui tarnitakse reliis, siis automaatselt käivitatakse reliisi paigaldus. Manuaalselt käivitatav ehk on tekitatud nupp reliisi paigalduse käivitamiseks, et kui kasutaja vajutab nuppu, siis paigaldatakse reliis automaatselt.

Automaatne reliisi paigaldus peab olema minimaalselt testkeskkonda tehtud, kui on kokkulepitud, siis ka teistesse olemasolevatesse keskkondadesse.

Arendaja

TEHIK

Arendaja

TEHIK arhitekt

TEHIK administraator

5.3 Kasutatakse manuaalset automaattestide käivitamise protsessi 

Manuaalne automaattestide käivitamise protsess: Süsteemitestide ( ) domeeni luuakse eraldi GitLab Pipeline, kus saab manuaalselt käivitada end-to-end testid süsteemitestid ( ).end-to-end testid Robustsuste testid domeeni luuakse eraldi GitLab Pipeline, kus saab manuaalselt käivitada robustsuse testid. Koormustestid domeeni luuakse eraldi GitLab Pipeline, kus saab manuaalselt käivitada koormustestid.

Arendaja

TEHIK

Arendaja

TEHIK arhitekt

TEHIK administraator

6 Testide automatiseerimiseks võib kasutada erinevaid tööriistu või raamistikke ning olemasolevaid kasutatavaid tööriistu või raamistikke

Iga uue testimise automatiseerimise tööriista või raamistiku kasutusega tuleb eelnevalt TEHIKuga kokkuleppida, milline on antud tööriista või raamistiku arhitektuuri muster. Olemasolevate tööriistadega või raamistike testide automatiseerimisel tuleb kasutada arhitektuuri mustrit, mis on kirjas nõuetes  .Tehnilised nõuded  nõue 4

Arendaja

TEHIK

Arendaja testija

TEHIK tehniline testija

TEHIK testija

TEHIK arhitekt

TEHIK administraator

7 Automaattestide skriptide kood peab vastama MFN nõuetele 5

MFN nõuded  .https://wiki.sm.ee/pages/viewpage.action?pageId=3834694 Arendaja Arendaja testija

TEHIK testija

8 Automaattestide logimine ja debuggimine peab vastama MFN nõuetele 4 v.a nõuded 4.17, 4.21 ja 4.22

MFN nõuded  .https://wiki.sm.ee/pages/viewpage.action?pageId=3834694 Arendaja Arendaja testija

TEHIK testija

9. Dokumendid

9.1 Automaattestide paigaldamisjuhend Koostatud peab olema automaattestide paigaldusjuhend, kuidas automaattestid integreerida testkeskkonda ja teistesse

kokkulepitud keskkondadesse.

Arendaja Arendaja testija

TEHIK tehniline testija

TEHIK testija

TEHIK arhitekt

TEHIK administraator

9.2 Automaattestide kasutusjuhend Koostatud peab olema automaattestide kasutusjuhend, kuidas automaattestid käivitada ning kus vajalikud logid asuvad jm.

vajalikud failid.

Arendaja Arendaja testija

TEHIK tehniline testija

TEHIK testija

TEHIK arhitekt

TEHIK administraator

Tehnilised nõuded Nõude nr

Nõude sisu Seletused Koostamise eest vastutaja

Testimise läbi viib või kinnitab

1 Automatiseeritud testimiseks tuleks kasutada tööriista / raamistiku, mis võimaldab kergesti automaattestimist hallata.

Põhinõuded:

lisada uued testid; kustutada testid; välja/sisse lülitada testid; parandada testid; hallata teste.

Arendaja Arendaja

Arendaja testija

TEHIK arhitekt

TEHIK administraator

TEHIK tehniline testija

TEHIK testija

2 Kõik testide automatiseerimise tööriistad / raamistikud peavad oskama töötada GitLab PipeLine's ja Docker Container's.

Kogu testimine peaks olema kavandatud töötama GitLab Pipelines automaatselt ja ilma manuaaltegevuseta.

Arendaja Arendaja

Arendaja testija

TEHIK arhitekt

TEHIK administraator

TEHIK tehniline testija

TEHIK testija

3 Automaattestide kasutamise tehniline loogika Testide automatiseerimise kasutamise tehniline loogika joonis Lisa 1. Automaattestide kasutamise nõuete joonised#Lisa1.

.2Testideautomatiseerimiselekasutamisetehnilineloogika

Arendaja

TEHIK

Arendaja

Arendaja testija

TEHIK arhitekt

TEHIK administraator

TEHIK tehniline testija

TEHIK testija

4. Docker image

4.1 Kõik docker image tuleks eelnevalt ette valmistada. Vaata punkt 4.2, kõik 4.3 alampunktid ja 4.4.

Arendaja

TEHIK

Arendaja

TEHIK arhitekt

TEHIK administraator

TEHIK tehniline testija

4.2 Docker image peaks sisaldama kõiki vajalikke sõltuvusi konteineri kiireimaks käivitamiseks. Valmistatud docker image peab olema koos installitud sõltuvustega.

Java-testimiseks peab vajalikud library/raamistikud ette valmistama l kataloogis.ocal /.m2 

Docker image tuleks luua võimalikult kerge ja kõik tuleks prügi enne loomist eemaldada

Arendaja

TEHIK

Arendaja

TEHIK arhitekt

TEHIK administraator

TEHIK tehniline testija

4.3 Dockeri image testimise struktuurid

4.3.1 Dockeri image testimise struktuurid Java baasil testimine. Npm baasil testimine. SoapUI baasil testimine. Muude tööriistade baasil testimine.

Arendaja

TEHIK

Arendaja

TEHIK arhitekt

TEHIK administraator

TEHIK tehniline testija

4.3.2 Docker image Java baasil testimise struktuur Alpine või Ubuntu baasil image. Java v8 või kõrgem. Maven või Gradle:

Gatling ( )./.m2 JUnit ( )./.m2

Selenium ( )./.m2 Selenid ( )./.m2

Teised java raamistikud.

Arendaja

TEHIK

Arendaja

TEHIK arhitekt

TEHIK administraator

TEHIK tehniline testija

4.3.3 Docker image Npm baasil testimise struktuur Alpine või Ubuntu baasil image. Node.js/Npm:

Cypress; Newman; Teised npm raamistikud.

Arendaja

TEHIK

Arendaja

TEHIK arhitekt

TEHIK administraator

TEHIK tehniline testija

4.3.4 Docker image SoapUI baasil testimise struktuur Alpine või Ubuntu baasil image. Java v8 või kõrgem. OpenSource SoapUI.

Arendaja

TEHIK

Arendaja

TEHIK arhitekt

TEHIK administraator

TEHIK tehniline testija

4.4 Kasutada igal võimalusel Docker'is uusimat tarkvara või testide automatiseerimise raamistiku versiooni. Kui testimine ei vaja vanu ja testide automatiseerimise Library

raamistikke, peab kasutama viimast versiooni.

Arendaja

TEHIK

Arendaja

TEHIK arhitekt

TEHIK administraator

TEHIK tehniline testija

1.

2.

3.

5. Automaattestide GitLab repository

5.1 GitLab automaattestide repository struktuur Kõik PipeLine töötamiseks vajalikud failid peavad olema repository r

  kataloogisoot readme litsents gitlab-ci.yml .........

Testprojekt või testfailid peavad olema repository   kataloogistest Test kataloogi nimi peab pealkirjas sisaldama: 

"testi-tüüp"- -tests- -"projekt või mooduli-nimi"

Arendaja

TEHIK

Arendaja

Arendaja testija

TEHIK arhitekt

TEHIK administraator

TEHIK tehniline testija

TEHIK testija

5.2 GitLab automaatesti repository üldine struktuur / - GitLab Repository root kataloog.

- automaattestide  katal/'testi tüüp'-tests-'projekt või mooduli nimi/ root  oog.

- mõne automaattesti kataloog koos  ja .../some-lib/ Library  Depe 'ga.ncy

- mõne automaattesti kataloog. .../some-dir/

- mõni teine automaattesti kataloog. .../some-dir/some-dir/

- automaattesti kataloog..../some-dir/some-dir/some-dir/

- mõne automaattesti failid..../some-file.file

- teised projekti automaattesti failid..../other

- GitLab Pipeline konfiguratsiooni fail./gitlab-ci.yml

/README.md

/.gitignore

/LICENSE

/Muud GitLab Pipline failid

Arendaja

TEHIK

Arendaja

Arendaja testija

TEHIK arhitekt

TEHIK administraator

TEHIK tehniline testija

TEHIK testija

5.2 Front-end automaattestide GitLab repository

5.2.1 Front-end Gitlab repository struktuur Selenium/Selenid repository struktuur -  punkt 5.2.2.

Arendaja

TEHIK

Arendaja

Arendaja testija

TEHIK arhitekt

TEHIK administraator

TEHIK tehniline testija

TEHIK testija

5.2.2 Selenium/Selenide Gitlab repository struktuur Peab vastama punktile 5.1 ja 5.2. Repository struktuur:

Juurkataloog testide jaoks on: /test-kataloogi-nimi/src/test/java/*

Lisa library juurkataloog on: /test-kataloogi-nimi/lib/*

Gradle ja Maven juurkataloog on : /test-kataloogi-nimi/*

Muud failid ja kataloogid luuakse vabas vormis, kuid neid tuleb eelnevalt arutada.

Selenium/Selenid struktuur:

/...

/ui-tests-'projekt või mooduli-nimi'/

.../src/test/java/*

.../lib/*

.../other-dir/

.../other-project.file

.../Gradle-or-Maven.files

/...

Arendaja

TEHIK

Arendaja

Arendaja testija

TEHIK arhitekt

TEHIK administraator

TEHIK tehniline testija

TEHIK testija

1.

2.

3.

4.

5.3 Back-end automaattestide GitLab repositpory

5.3.1 Back-end Gitlab repository struktuur Postman Gitlab repository struktuur -  punkt 5.3.2. SoapUI Gitlab repository struktuur - punkt 5.3.3.

Arendaja

TEHIK

Arendaja

Arendaja testija

TEHIK arhitekt

TEHIK administraator

TEHIK tehniline testija

TEHIK testija

5.3.2 Postman Gitlab repository struktuur Peab vastama punktile 5.1 ja 5.2. Repository struktuur:

Juurkataloog testide jaoks on: /test-kataloogi-nimi/postman-test-file.json

Lisa library juurkataloog on: /test-kataloogi-nimi/lib/*

 Lisa scriptide juurkataloog on: /test-kataloogi-nimi/scripts/*

Test data juurkataloog on: /test-kataloogi-nimi/custom/*

Muud failid ja kataloogid luuakse vabas vormis, kuid neid tuleb eelnevalt arutada.

Postman struktuur:

/...

/'api'-tests-'projekt või mooduli-nimi'/

/'rest'-tests-'projekt või mooduli-nimi'/

/'soap'-tests-'projekt või mooduli-nimi'/

.../postman-test-file.json - automaattesti projekti andmed.

.../lib/* - automaattesti  .Library

.../lib/some-test-lib.file

.../scripts/* - kohandatud automaattestide skriptid.

.../scripts/start.sh

.../scripts/run-after-postman-end.js

.../custom/* - automaattesti andmed.

.../custom/postman-data-csv.file

.../other-dir/

.../other-project.file

/...

Arendaja

TEHIK

Arendaja

Arendaja testija

TEHIK arhitekt

TEHIK administraator

TEHIK tehniline testija

TEHIK testija

1.

2.

3.

4.

5.3.3 SoapUI Gitlab repository struktuur Peab vastama punktile 5.1 ja 5.2. Repository struktuur:

Juurkataloog testide jaoks on: /test-kataloogi-nimi/soapui-test-file.xml

 Lisa library juurkataloog on: /test-kataloogi-nimi/lib/*

Lisa scriptide juurkataloog on: /test-kataloogi-nimi/scripts/*

Test data juurkataloog on: /test-kataloogi-nimi/custom/*

Muud failid ja kataloogid luuakse vabas vormis, kuid neid tuleb eelnevalt arutada

SoapUI struktuur:

/..

/'api'-tests-'projekt või mooduli-nimi'/

/'rest'-tests-'projekt või mooduli-nimi'/

/'soap'-tests-'projekt või mooduli-nimi'/

.../soapui-test-file.xml - automaattesti projekti andmed.

.../lib/* - automaattesti  .Library

.../lib/some-test.lib.file

.../scripts/* - kohandatud automaattesti skriptid.

.../scripts/start.sh

.../scripts/run-after-postman-end,js

.../custom/* - automaattesti andmed.

.../custom/soapui-data-csv.file

.../other-dir/

.../other-project.file

/...

Arendaja

TEHIK

Arendaja

Arendaja testija

TEHIK arhitekt

TEHIK administraator

TEHIK tehniline testija

TEHIK testija

6. Käivitamine

6.1 Kogu loogika ja käivitusjärjestus tuleb failis gitlab-ci.yml määratleda. Testid võivad töötada nii põhiprojektist eraldi kui ka põhiprojekti ajal.

Gitlab  tuleb konfigureerida nii, et see continous integratsionit  saaks iseseisvalt töötada (eraldi projektis). Gitlab  tuleb konfigureerida nii, et see continous integratsionit  saaks töötada põhiprojekti osana (module or extension for main project).

Arendaja

TEHIK

Arendaja

Arendaja testija

TEHIK arhitekt

TEHIK administraator

TEHIK tehniline testija

TEHIK testija

6.2 Peaks olema võimalus testid läbi viia või osaliselt ükshaa .val

Testi käivitamine võib olla:

(all tests/test suites);kõik testid valitud test (test case);üks valitud testi (test cases);mitu

valitud (test suite);testikomplekt valitud (test suites);testikomplektid valitud /  ja / valitud testi.testikomplekt testikomplektid üks mitu

Arendaja

TEHIK

Arendaja

Arendaja testija

TEHIK arhitekt

TEHIK administraator

TEHIK tehniline testija

TEHIK testija

6.3 GitLab PipeLine testi käsitsi valimiseks kasutatakse eelnevalt määratletud muutujaid, nii testide automatiseerimise raamistikus kui ka repositoriumis.

Kõik muutujad tuleb edaspidiseks kasutamiseks eelnevalt kokku leppida.

Arendaja

TEHIK

Arendaja

Arendaja testija

TEHIK arhitekt

TEHIK administraator

TEHIK tehniline testija

TEHIK testija

7. Muud

7.1 Kasutada  või eraldi mocki docker image virtuaal masinat  jaoks. Kui vaja kasutada mock, siis ta peab olema  seon docker container

es koos kõigi vajalike sõltuvustega. Kui docker ei saa kasutada, siis mock saab panna käima virtuaal masinal.

Arendaja

TEHIK

Arendaja

Arendaja testija

TEHIK arhitekt

TEHIK administraator

TEHIK tehniline testija

TEHIK testija

7.2 Testide automatiseerimisel kasutades raamistiku, mis kasutab WebDriverit peab eemalt saama käivitada automaattestid.

Testid tuleb esialgu ette valmistada kaugkäivitumiseks. Testimiseks kasutatakse Selenoid Hub

Selenoid Hub kasutamine:

Local hub:

Isiklik hub Kohalik testimine

Public Test hub:

Test Debuging GitLab PipeLine Test/Proto branch

Public Live hub:

Testid GitLab PipeLine Master branch

 Eraldi Hub projekti jaoks:

GitLab PipeLine Master branch Testi isolatsioon Piiratud juurdepääs andmetele Testandmed

Remote käivitamine kasutavad:

Selenium; Selenide; Muud.

Arendaja

TEHIK

Arendaja

Arendaja testija

TEHIK arhitekt

TEHIK administraator

TEHIK tehniline testija

TEHIK testija

Front-end arendusreeglid

FE arendusreeglid

Versioon: 1.0

Lühendid FE – Front-end BE – Back-end FF – Mozilla Firefox IE – Internet Explorer UI – User interface (kasutajaliides) SEO – Search engine optimization

Eesmärk ja sihtgrupp

FE arendusreeglid on mõeldud kõigile FE ja BE arendajatele. Reeglite järgimine on kohustuslik.

Veebilehitsejate tugi

A klass: IE10+, Chrome (viimane versioon), FF (viimane versioon), Microsoft Edge (viimane versioon)

Lõpptulem ei tohi kujundusest erineda, välja arvatud veebilehitsejate implementatsioonist tulenevad erandid (näide: selectboxi native kujundus on veebilehitsejates omavahel erinev ja see on lubatud)

B klass: Safari

Visuaalselt korrektne, aga võib erineda algsest kujundusest. Optimeerimise ja kodeerimise lihtsustamise eesmärkidel ei pea näiteks toetama ümarad nurkasid, gradiente jne.

Stiililehed Üks peamine stiilileht nimega main.css, kus sees loogilises järjestuses kommentaaridega eristatult kõik rakenduse stiilid. Printimise jaoks on print media abil eraldi kuvatav stiilifail, mille eesmärk on kuvada sisuosa ilma illustreerivate elementideta. Ära peidetud on navigatsiooni elemendid, mis prinditud versioonis ei ole olulised.

Kataloogide stuktuur gfx – CSSid koos CSSis defineeritud piltidega.

images – HTMLis lingitud pildid. Alamkataloogid vajadustel komponendi põhistele elementidele, kui on ühes komponendis kasutusel rohkem kui 15 pilti. fonts – rakenduses kasutatavad fondi failid.

scripts – rakenduses kasutatavad JS failid.

CSSi haldamine CSSi stiilidel on üks haldaja ja vastutaja, kes on kursis kõigi muudatustega. Tema kohustus on üle vaadata teiste poolt kirjutatud CSS ja vastavalt vajadusele muuta või saata tagasi arendajale parandamiseks. CSSi haldamise eesmärk on, et ainult CSSi haldaja ja/või FE meeskond kirjutab CSSi. Arendajad peavad pöörduma CSSi haldaja ja/või FE meeskonna poole, kui on muudatusi vaja. CSSi haldaja koordineerib teiste arendajate tööd. BE arendajad tohivad stiile kirjutada ainult põhilise stiilifaili lõppu pärast vastavat kommentaari. Enda arendused peavad olema kommenteeritud nii, et CSSi haldaja saaks võimalikult kiirelt koodi üle vaadata ning sobivasse asukohta paigutada ja vajadusel koodi muuta. Eelnev kirjeldab olemas oleva koodi muutmist või väikseid uusi arendusi olemas olevas raamistikus. Uute arenduste korral tuleb tellida FE antud ala spetsialist, kellele on edastatud antud dokument. Kui uue koodi kirjutada ei ole CSSi haldaja on haldajal kohustus ülevaadata uus kood.

Illustreerivad pildid

Illustreerivad pildid peavad olema lisatud CSSi abiga. Pildid on optimeeritud. Salvestamisel valitud sobiv laiend vastavalt suurusele ja kvaliteedile. Võimalusel kasutatud Fireworksi, PNG optimizerit või antud hetkel sobivat vahendit vähendamaks piltide mahtu. Photoshopis tuleks pildid salvestada save for web abil. JPG puhul võib salvestada 75-80% ilma, et oleks visuaalset kadu. Kui pildi suuruseks on u 150KB, siis kontrollida üle optimeerimise võimalused. CSSis ja HTMLis lingitud pildid asuvad eraldi kataloogis. CSSis lingitavad illustreerivad pildid asuvad CSSiga samas kataloogis. Eelistada illustreerivate piltide kuvamist läbi CSSi. HTMLis lingitud piltide nimetamisel arvestada SEOd ja ühtset stiili. CSSi pildid nimetada sarnase loogikaga. Ikoonide alguses on icon_, taustapiltidel bg_ logodel logo_, nimekirjadel ul_ ja komponentide spetiifiliste piltidel puhul selle classi nimetus. Pildi nimed on läbivalt inglise keeles ja semantiliste nimetusega. Ei tohi kirjeldada pildil olevat värvi.

Semantika Front-end kood peab vastama semantika reeglitele, välja arvatud juhul, kui kokkulepitud kasutatav raamistik ei võimalda seda saavutada. Kodeerimisel tuleb arvestada responsive (kohandub iseenesest ümber erinevatele ekraanisuurustele) versioonile üleminekuga.

Olulisemad punktid

Classi nimed on üldised või komponendi spetsiifilised Classi nimedes ei tohi olla kasutatud visuaalseid kirjeldusi.

Näiteks värvid, suurused jne.

Kasutada semantiliselt korrektseid HTMLi elemente. Näiteks nimekirjade puhul peab olema kasutatud UL või OL tagi vastavalt sisule. BR ei tohi kasutada. Layouti loomisel ei tohi kasutada tabeleid.

Inline elemendi sisse ei tohi panna block elemente. Paragraafide sisse ei tohi kirjutada DIVe.

Vältida tühjade HTMLi elementide kasutamist.

Re-usable front-end

1. Enne kodeerimist tutvuda olemasolevate komponentidega. 2. Võimalusel kasutada olemasolevaid elemente. 3. Kujunduses olevate väikeste erinevuste puhul pakkuda välja ühtlustamise võimalusi ja lahendusi. 4. Kasutada üldiseid classi nimetusi ja arvestada kodeerimisel, et antud stiile oleks võimalik kasutada läbivalt. Erandite puhul kasutada eraldi classi

nimetust. 5. Kodeerimisel arvestada, et uue elemendi muutmine ja haldamine oleks võimalikult lihtne. Näiteks arvestada keelsusega. Võimalusel vältida keelte

jaoks erandite tegemist.

HTMLi reeglid

HTML peab valideeruma kasutades https://validator.w3.org HTML valideerimisvahendit. Inline CSSi ei tohi kirjutada ja kasutada. Cellpadding'uid ja cellspacing'uid ei tohi kasutada HTMLis.

Võimalusel kirjutada optimeeritud koodi ja vältida üleliigseid elemente ja defineeringuid. Kasutada läbivalt ühtset stiili.

Jutumärkideks on topelt jutumärgid näide class="style01"

Arenduse failid on ühe tabi abil trepitud. Arvestada SEO soovitusi

Vajadusel illustreeritavatel piltidel korrektsed alt väärtused. Meta tagid vastavalt kaasaegsetele nõudmistele.

Piltide või ikoonide puhul, mis on kasutusel linkidena, kasutada title tagi. Title sisu peab kasutajale andma informatsiooni, et kuhu see link kasutaja suunab.

Näide logo title väärtus on "Avalehele" HTMLis vältida ja eemaldada üleliigsed kommentaarid.

CSSi reeglid

Kehtib FE arendaja poolt loodud stiililehtede kohta. Ei kehti juhul, kui kokkulepitud kasutatav raamistik ei võimalda seda saavutada.

CSS peab valideeruma kasutades https://jigsaw.w3.org/css-validator/ CSS valideerimisvahendit. CSSi treppimine

Selektori ja loogeliste sulgude vahele üks tühik. Üks tab enne atribuuti (laiuselt võrdne nelja tühikuga). Selektorid ja atribuudid on eraldi ridadel. Näide

ul*{ ****margi

n:*0; }

Selectori blokkide vahel tühjad read eraldamaks erinevaid elemente aga üldiselt ilma tühja reata.

h1 {

font-size:

34px; }

h2 {

font-size:

24px; }

a {

color:

#08c; }

a:focus,

a:hover {

color:

#ff6; }

Esimese taseme ja teise taseme kommentaari ees ja järgi üks tühi rida. CSSis blokkide järjekord:

normalize/reset, global common vastavalt struktuurile header, content ... Plugina CSSid, kui on tegemist pluginaga, mida kasutatakse samade stiilidega erinevates asukohtades, siis antud CSS lisada eraldi faili. media queries

CSS Atribuutide järjekord:

display: ;

position: ;

top: ;

float: ;

clear: ;

width: ;

height: ;

overflow: ;

margin: ;

padding: ;

outline: ;

border: ;

background: ;

list-style: ;

table-layout: ;

border-collapse: ;

vertical-align: ;

text-align: ;

text-indent: ;

text-transform: ;

line-height: ;

word-spacing: ;

color: ;

font: ;

cursor: ;

visibility: ;

opacity: ;

z-index: ;

content: ;

quotes: ;

CSS3

Ühikud Eelistatult läbivalt kasutada pixleid. 0 väärtuse korral ühik pole vajalik. 0em == 0px == 0

Class' ja ID nimetused läbivalt väikeste tähtedega, semantilised ja eralduseks kasutatud sidekriipsu. Näide: data-table-outer

Classide nimetamisel kasutada läbivalt inglise keelt.

ID kasutada ainult juhul, kui ollakse täiesti kindel, et seda elementi tulevikus ei kasutata lehel korduvalt. Näiteks lehe layout päis, jalus, menüü. CSSis on kaks taset kommentaare.

1. esimene tase /** =Kommentaar */

2. teine tase /** =Kommentaar */

Kommentaarid läbivalt inglise keeles. Vajadusel rakenduse spetiifilisi mõisteid kasutada eesti keeles. Välja kommenteeritud koodi ei tohi jätta alles. Margin ja paddingute korrektne kasutamine. Paddingut kasutada antud elemendi sisse nn õhu jätmiseks ja marginit väljapoole. Tekstide joondamisel vältida line-heighti abil joondamist ja eelistada paddingut. Floatide clearimiseks on class clear, mis läheb floatitud elementide ümber olevale tagile.

.clear:before,

.clear:after

{

content: " ";

display: table;

}

.clear:after

{ clear:

both;

}

CSS kirjutada ainult selleks mõeldud faili. Inline CSSi ja HTMLi failis eraldi <style> kasutada ei tohiks. Võimalusel vältida ka visuaalsete stiilide defineerimist JS failides. Pildi URLi lisamisel jutumärke ei ole vaja kasutada. Vältida veebilehitsejaspetiifilisi häkke. Kodeerimisel arvestada mõistlikkuse piirides "Web Content Accessibility Guidelines (WCAG) 2.0" soovitusi.

http://www.w3.org/WAI/WCAG20/quickref/ http://kristjankure.com/

Optimeerimine FE tehnikate abil

https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Writing_efficient_CSS tbody#select-01 => #select-01 #navigation li a => #nav a

tr.tr-name td.td-name => .td-name HTMLis olevatele piltide määrata kõrgus ja laius, kui on võimalik. Eesmärk vähendada re-flow'ed. Gradientide, ümarate nurkade jne puhul kasutada CSS3 ning vanematel veebilehitsejatel peab kujundus välja nägema visuaalselt korrektne aga ei pea olema visuaalselt identne. Kontrollida veebilehitseja võimalusi siit http://caniuse.com/. Kui on võimalik illustreerivad pildid nt nooled, bulletid asendada CSS3 lahendusega, siis seda võimalust kasutada. Kui vajadus tühja elementi kasutada, siis selle asemel kasutada CSSis before'i võimalust. Selle juures tuleks arvestada veebilehitsejate tuge ja kasutajamugavust mõistlikuse piirides. Informatsioon peab olema arusaadav ja kättesaadav ka B klassi veebilehitseja toele. Reflow ja repaint'iga arvestamine. CSSi reseti asemel kasutada normalize. Värvid kirjutada koodi abil (soovitavalt hex aga vajadusel rgba) ja läbivalt väikeste tähtedega. Võimalusel lühendada kolme tähelisteks.

#ffffff => #fff #ff88aa => #f8a, #ff0000 => #f00

Võimalusel CSSi väärtused tõsta kokku ühele reale. Border-top, border-left, border-bottom, border-right => border

CSSis ei tohi kasutada * lahendust määramaks kõigile elementide CSSi väärtuseid. Important kasutamist CSSi failis vältida. Normalize/reseti puhul ei tohiks olla defineeritud elemente, mida praktikas ei kasutata. Uue projekti alguses tuleks reset/normalize optimeerida ja vajadusel jooksvalt juurde lisada elemente. Võimalusel ja vajadusel kasutada sprite tehnikat.

Pluginatega kaasa tulevat CSSi peab ülevaatama, optimeerima ja järjekorda uuendama.

Kujundus

Linkidele, nuppudele alati korrektsed :hover, :focus ja :active staatused määrata. hoveri ja fookuse puhul on eesmärk tuua visuaalselt element rohkem esile ja paremini loetavaks. aktiivse staatuse puhul tuleks jätta mulje, et nupule või lingile on vajutatud. Visuaalselt poolelt näiteks gradient on vastupidine või lingi värv on tagasihoidlikum.

Arvestada olemasoleva kujundusega ja jälgida sellele sarnast stiili. Ühtlustada ja jälgida lõpptulemuse joonduseid.

Lisa 7 – Lähtekoodi haldus

1 Üldine kirjeldus Lähtekoodi hallatakse GIT tarkvaraga. Tsentraalne tarkvara lähtekoodi hoidla (Gitlab) asub TEHIKus, kuhu on koondatud kõik repositooriumid.

a. Iga tarkvara arendaja võib teha enda lähtekoodi hoidlasse koopiaid TEHIKu hoidlast, kuid iga tööülesande (JIRA story/task) valmides peavad muudatused jõudma TEHIKu lähtekoodi hoidlasse.

b. Tarkvara continuous integration keskkond on TEHIKu Gitlab keskkond ja selle töövood. c. Tarkvara paigalduspakettide kokku ehitamine arendus, testi, prelive ja Live keskkondade jaoks

toimub TEHIKu lähtekoodi hoidlast. d. Käesoleva reeglistiku järgimine on kohustuslik kõigile infosüsteemide arendajatele ja

arendustööde tellijale. e. Tellija peab enne uue mestitava arenduse testima ja arendajale veahaldussüsteemis kinnitama,

et arendatav kood töötab korrektselt.

2 Lähtekoodi versiooni harude haldus

2.1 Peamised harud

TEHIKu lähtekoodi hoidlas on kohustuslike harudena olemas:

 Master

 Release

 Develop

Lähtekoodi harus origin/master hoitakse Live keskkonnas oleva tarkvara lähtekoodi seisu.

Lähtekoodi harus origin/release hoitakse järgmise toodangu uuenduse oleva tarkvara lähtekoodi seisu.

Release haru on vajalik nende süsteemi osade puhul, kus TEHIK ja/või TAI teostab eraldi

vastuvõtutestimist ja sellel perioodil arendatakse juba järgmise tarne töid ning võib tekkida vajadusi

hotfixide järgi.

Lähtekoodi harus origin/develop hoitakse test keskkonnas oleva tarkvara lähtekoodi seisu.

Develop harust võtab alati järgmine arendaja viimase lähtekoodi edaspidiste andmete

sünkroniseerimiseks.

Kui lähtekood on saavutanud stabiilse seisu, teeb tellija arendajale ettepaneku paigaldada lähtekood

Live keskkonda. Lähtekood paigaldatakse Live keskkonda pärast seda, kui arendustöö on arendaja poolt

tellijale aktiga üle antud.

Kõik Develop harus olevad muudatused tuleb mestida Master harusse ja sildistada vastava tarkvara

versiooni numbriga.

2.2 Toetavad harud

Iga uue arenduse algul loob arendaja ühe alljärgnevatest lähtekoodi harudest:

 Feature

 Release

 Hotfix

2.2.1 Feature haru Väljavõte tehakse: Develop

Mestimine tehakse: Develop

Haru nime kuju: [projekti lühinimetus]-*, või Jira taski number

Feature haru kasutatakse tarkvara uue funktsionaalsuse arendusteks.

2.2.2 Release haru Väljavõte tehakse: Develop

Mestimine tehakse: Develop ja Master

Haru nime kuju: release

Peale arenduse edukat testimist teeb tellija ettepaneku tarnida arendustöö release harusse. Release

haru kasutatakse tarkvara live mineku ettevalmistamiseks. Selles võib teostada nn viimase minuti

tarkvara korrigeerimise tegevusi. Lisaks on veel lubatud pisikesi veaparandusi ning meta-andmete

täiendusi. Pärast tööde lõppu Release harus, peab Develop harus olema kogu vajalik lähtekood

järgmisteks suuremateks arendusteks. Release harust võtab arendaja vajaliku lähtekoodi peaharusse

tarnimiseks (master). Lähtekoodi on kohustatud arendaja peaharusse panema hiljemalt järgmise

tööpäeva lõpuks.

2.2.3 Hotfix haru Väljavõte tehakse: Master

Mestimine tehakse: Develop ja Master

Haru nime kuju: hotfix-*

Hotfix harus kasutatakse Live keskkonnas oleva tarkvara vigade parandamiseks.

Kasutatud materjalid: http://nvie.com/posts/a-successful-git-branching-model/