Leping

Lisa 2 – Kodukord 1. Sissejuhatus 1.1. Kodukorra eesmärk on täpsustada poolte õiguseid ja kohustusi ja tööde teostamise korraldust. 2. Nõuete haldus 2.1. Antud peatüki eesmärk on kirjeldada kust ja kuidas nõuded tulevad, kuidas nõuded kaardistatakse, kuidas neid hallatakse, kuidas hallatakse muudatusi, sh kuidas kinnitatakse muudatused, kuidas ärilised nõuded seotakse süsteeminõuetega ja kuidas süsteeminõuded seotakse arenduse taskide, testilugude jms-ga. 2.2. Projekti skoopi kuuluvad tööd on kirjeldatud hanke tehnilises kirjelduses ja selle lisades. Nende tööde teostamise jälgimiseks loob täitja projektijuht võimalikult sarnase töömahuga piletid projekti tööhalduskeskkonnas. Pileteid võib samadel tingimustel luua ka tellija. Projektis ei teostata töid, mida pole hanke tehnilises kirjelduses defineeritud (ja mille kohta ei ole seega tööhalduskeskkonnas piletit). 2.3. Tööde läbivaatamisel võib tellija tuua välja erinevaid muudatusvajadusi, mis defineeritakse projekti töörühma poolt tööhalduskeskkonna vastavas piletis nõuetena või uute tööpiletitena. 2.4. Dokumentatsiooni loomisel tuleb lähtuda suunistest mis on kättesaadaval aadressil https://tehik.ee/arendusjuhendid („Nõuded infosüsteemi dokumentatsioonile“). 3. Kommunikatsiooni haldus 3.1. Tellija projektijuht säilitab kogu projekti vältel toimuva kommunikatsiooni, mida on võimalik kirjalikult taas esitada, projekti ja garantiiperioodi kehtivuse vältel. 3.2. Projekti kommunikatsiooni vormid on järgmised, kuid neile võib vastavalt vajadusele kokkuleppeliselt lisanduda ka muid kommunikatsiooni vorme, mida pole alljärgnevas tabelis kirjeldatud: Kommunikatsiooni Sagedus Vastutav Reeglid vorm roll Igapäevane Jooksvalt Tellija PJ  Tööde läbiviimiseks lepib teabevahetus Täitja PJ töörühm kokku vestluskanali (Teams vms), millesse kuuluvad kõik töörühma liikmed. Projektijuhid tagavad, et kõigil osalistel oleks kanalisse ligipääs  Vajadusel lepivad poolte projektijuhid kokku antud kanalis täiendavate alamgruppide loomise konkreetsete teemade arutamiseks   Poolte projektijuhid vastutavad, et ebaturvalistes peetavates vestluskanalites ei edastataks tundlikke andmeid (n delikaatsed isikuandmed, tellija rakenduste turvalisust puudutav info).  Vestluskanalis tõstatatud küsimusele tuleb vastata koheselt või anda vastamise tähtaeg.  Mõlema poole projektijuhid jälgivad jooksvalt vestluskanalit ning viivituste korral korraldavad vastamise enda poolel  Vestluskanalis langetatud otsused tuleb eraldi dokumenteerida projektidokumentatsioonis või tööde halduse keskkonnas. Ad hoc koosolekud Vastavalt Tellija PJ  Keerulisematele küsimuste vajadustele Täitja PJ arutamiseks võivad tellija ja täitja projektijuht kokku kutsuda eraldi koosoleku.  Koosolekule võib kutsuda ka liikmeid väljastpoolt projekti töörühma.  Koosolekust antakse ette teada vähemalt 1 tööpäev.  Koosolekusse tuleb märkida päevakord, eesmärk ning toimumise koht.  Koosolek võib toimuda nii kohapeal kui veebi vahendusel.  Koosoleku tulemina koostab kokku kutsuja memo või delegeerib selle koostamise mõnele koosoleku osalejale.  Kui koosoleku osalejad ei suuda leida vastust, eskaleerib koosoleku kokku kutsuja otsustamise projekti töörühma üldkoosolekule.   Koosolekut võib tühistada poolte kokkuleppel hiljemalt 2- tunnise etteteatamise ajaga Projekti Jooksvalt Tellija PJ  Projekti dokumentatsioon dokumentatsioon Täitja PJ hoitakse tellija Confluence’i keskkonnas vastavas ruumis.  Tellija PJ vastutab, et kõigil töörühma liikmetel oleks sinna ligipääs.  Dokumentatsiooni struktuur lepitakse kokku projekti töörühma koosolekul. Igale dokumendile määratakse tellija ja täitja jälgija.  Projektijuhid vastutavad, et dokumendi jälgijad teostaksid dokumendi kokkulepitud täiendused ja muudatused ning et dokumentatsioon püsiks ajakohane. Projekti Iganädalaselt Tellija PJ  Projekti kõiki tööülesandeid tööülesanded Täitja PJ hallatakse tellija Jira keskkonna vastavas projektis. Selles keskkonnas registreerimata töid ei teostata ega arveldata.  Tellija PJ vastutab, et kõigil töörühma liikmetel oleks tööhalduskeskkonda ligipääs.  Igal teostamisele määratud ülesandel peab olema täitja  Ülesande täitja vastutab ülesande täitmise staatuse ajakohasena hoidmise eest  Ülesanded vaadatakse läbi kord nädalas ning märgitakse juurde vastavad tegevused. Lepingu täitmist Vastavalt Tellija PJ  Lepingu täitmist puudutav puudutav vajadusele Täitja PJ ametlik teabevahetus, mis pole teabevahetus kaetud muude kommunikatsioonivormidega (n tööülesannete ja projektidokumentatsiooni haldus) toimub e-kirja teel.   Ametlikud e-kirjad registreerib tellija projektijuht tellija dokumendihalduse keskkonnas  Kui e-kirjale oodatakse vastust, tuleb see pealkirja real või kirja alguses üheselt määratleda.  Vastust eeldavale e-kirjale tuleb vastata hiljemalt järgneva tööpäeva jooksul. Kui see ei ole võimalik, tuleb järgneva tööpäeva jooksul anda sisulise vastamise tähtaeg.  Lepingu üleandmis-vastuvõtu akt (ÜVA) tuleb tellija poolsele lepingu kontaktile edastada meili teel ja digitaalselt allkirjastatuna. Tellija korraldab ÜVA registreerimise ja allkirjastamise dokumendihaldussüsteemis ning täitjale meili teel tagastamise.  Arved lepingu täitmise eest esitatakse e-arvete keskkonnas. Erakorraline Vastavalt Tellija PJ  Poolte vaheline teabevahetus, teabevahetus vajadusele Täitja PJ mis pole kaetud eelnevalt kirjeldatuga, lepitakse kokku tellija ja täitja PJ poolt vastavalt olukorrale.  Projektijuhid lepivad kokku, millises vormis erakorraline kommunikatsioon edastada ning kuidas seda edasi käsitleda.  Reeglina on erakorralise kommunikatsiooni vormiks ametlik e-kiri, mis registreeritakse tellija dokumendihalduse süsteemis.  Kommunikatsioon kriisiolukorras on kirjeldatud käesoleva dokumendi punktis 5. 4. Projekti muudatuste haldus  4.1. Projekti muudatuseks nimetatakse vajadust, mida pole varasemalt kokku lepitud projekti ressurssides, skoobis (sh nõuetes, tulemites, verstapostides, eeldustes, piirangutes või seostes) või tööplaanis ja mille realiseerimine toob kaasa muudatusi varasemalt kokku lepitud: 4.1.1. üle antavates tulemites ja/või 4.1.2.ajakavas, projekti eelarves, inimressurssides ja/või 4.1.3. projekti läbiviimise tööprotsessides 4.2. Muudatustaotlused registreerib ja nende menetlemise seisu jälgib tellija projektijuht projektidokumentatsiooni keskkonnas. 4.3. Registreeritud muudatustaotlused vaatavad poolte projektijuhid koos läbi, konsulteerides vastavalt vajadusele projekti töörühmaga. Läbivaatuse käigus märgitakse taotlusse muudatuse mõju projekti tulemitele, ajakavale, eelarvele ning inimressursside kasutamisele. 4.4. Enne muudatustaotluse esitamist tuleb tagada, et on olemas vajalikud eeldused muudatuse teostamiseks. 4.5. Juhul, kui muudatus eeldab lisarahastust, hankes nimetamata ressursside kaasamist projekti või läheb muul viisil vastuollu riigihanke dokumentatsiooni sõnastusega, peab tellija projektijuht koostama muudatust põhjendava memo ning kooskõlastama selle tellija dokumendihaldussüsteemis vastavalt kehtivale asjaajamiskorrale. 4.5.1. Muudatus ei tohi tekitada täitjale eelist võrreldes teiste riigihankes kandideerinud pakkujatega. 4.6. Muudatuse realiseerimisega alustatakse alles peale vajalike kooskõlastuste saamist ning vajadusel hankelepingu või projekti kodukorra muudatuse allkirjastamist mõlema poole poolt. 5. Probleemide haldus 5.1. Kriisiolukorraks loetakse olukorda, kus: 5.1.1. poolte esindajad ei suuda kokkuleppele jõuda; 5.1.2. on muutunud võimatuks võtmeisikute osalemine tööde teostamisel; 5.1.3. on ilmnenud 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. 5.2. Kriisiolukorra tekkimisel on pool kohustatud sellest teise poole esindajat viivitamatult teavitama e-maili teel. Poole projektijuht helistab lisaks üle teise poole projektijuhi ning kontrollib meili kättesaamist. 5.3. Kui telefonikõnele pole võimalik vastata, tuleb tagasi helistada esimesel võimalusel, aga mitte hiljem kui järgmise tööpäeva lõpus. 5.4. Kriisi tekkel informeerib tellija projektijuht koheselt TEHIK-u andmeanalüüsi ja/või andmeladude talituse juhte, kes rakendavad täiendavad meetmed kriisi lahendamiseks. 5.5. Kriisist väljumiseks teevad mõlemad pooled kõik endast sõltuva mõlemat poolt rahuldava lahenduse leidmiseks. Kriisi vältimise ja kriisist väljumise tegevuste edenemise eest vastutavad poolte projektijuhid. 5.6. Kriisisituatsioonis võivad projektijuhid kokku leppida vajalike isikute kättesaadavuse ka peale tööpäeva lõppu. 5.7. Kui eelnevate meetmete abil ei suudeta kriisist väljuda, kasutatakse täitja ja tellija vahelises lepingus sätestatud meetmeid. 6. Kvaliteedi tagamine 6.1. Juhtimise kvaliteet tagatakse käesolevas projektis läbi süstemaatilise ja aktiivse projektijuhtimise, kus regulaarselt jälgitakse kokkulepitud tööplaani ja tööprotsesse ning muid hanke- ja projektidokumentatsioonis sõnastatud meetodeid, reegleid ja põhimõtteid. 6.2. Töö teostaja tagab, et projekti üle antavate tulemite kvaliteedi tagamiseks on tulemid (tarned) eelnevalt testitud vastu esitatud (sh funktsionaalseid ja mittefunktsionaalseid) nõudeid ning tuvastatud vead on parandatud enne tellijale üleandmist. 7. Tulemite valideerimine ja kinnitamine 7.1. Selliste tulemite nagu aruanded ja dokumentatsioon valideerimiseks vaatab tellija analüütik tulemid läbi, rakendades neid toodangukeskkonna andmetele ning kinnitab tulemite vastavust enda ärivajadustele tellija tööhalduskeskkonnas. Tööd ei võeta vastu enne, kui tellija analüütik või tema esindaja on tööhalduskeskkonnas kinnitanud loodud tulemi sobivust. 7.2. Laadimise koodi ja infodomeenile vastava andmemudeli vastavust nõuetele kontrollib tellija andmelao spetsialist (arendaja, arhitekt) versioonihaldus keskkonnas (GIT). 7.3. Andmeparandusalgoritmide valideerimiseks tuleb tagada, et need on tellija keskkonnas rakendatud, tellija andmelao arendaja on kinnitanud nende sobivust ning tellija analüütik on kinnitanud, et aruanded, mille andmekoosseisu algoritmid mõjutavad, on vastuvõetavad. 7.4. Dokumentatsiooni vastavust kehtivatele mittefunktsionaalsetele nõuetele kontrollib tellija projektijuht, kaasates vastavalt vajadusele täiendavaid spetsialiste. 8. Riskide haldus 8.1. Riskide haldus hõlmab: 8.1.1. riskide tuvastamist, analüüsi ja riskide prioriseerimist, 8.1.2.riskide juhtimistegevuste planeerimist, 8.1.3. riskide juhtimist, 8.1.4.riskide juhtimistulemuse kontrollimist ning otsustamist, kas risk on kontrolli all või vajab lisategevusi. 8.2. Riskide halduse reeglid ja protsess on järgmine: 8.2.1. täitja projektijuht koos projektimeeskonnaga koostab esialgse riskiplaani vastavalt alljärgnevale tabelile: I Valdkon Riski Riski Risk Riski Skoo Riski Vastutaj D d kirjeldu realiseerumis i realiseerumis r (S) juhtimise a s e tagajärg mõj e tõenäosus tegevuse u (TN) d (M) 8.2.2. Riskiplaan sisaldab järgmist infot: 8.2.2.1. riski _ID; 8.2.2.2. riski valdkond (nt: kliendist tulenevad riskid, finantsidest tulenevad riskid, ajahinnangutest tulenevad riskid, skoobist tulenevad riskid, tehnilisest lahendusest tulenevad riskid jne);  8.2.2.3. riski kirjeldus; 8.2.2.4. riski tagajärg; 8.2.2.5. riski mõju; 8.2.2.6. riski realiseerumise tõenäosus (TN); 8.2.2.7. riskikoefitsient/ skoor; 8.2.2.8. riski juhtimise tegevused ja vastutajad. 8.2.3.Riskiplaan arutatakse läbi kõigi seotud osapooltega. 8.2.4. Riskiplaani muudatusi haldab täitja projektijuht, küsides regulaarselt tagasisidet projekti meeskonnalt ja tellija projektijuhilt. 8.2.5. Riskiplaanis olevad kõrge prioriteediga riskid ja nende juhtimise tegevused, vastutajad ja seis vaadatakse üle projekti juhtrühmas. 8.2.6. Riskiplaani hoitakse ning hallatakse tellija dokumendihalduskeskkonnas (Confluence). 8.3. Riskide hindamine 8.3.1. Riskide hindamine hõlmab riskide tuvastamist, analüüsi ning riskikoefitsiendi/skoori määramist. 8.3.2.Riskide hindamisel osalevad kõik täitja projektimeeskonna liikmed, projektijuhi ülesanne on tulemused kaardistada ning tagada riskiplaani aja- ja asjakohasus. 8.3.3. Riskide hindamise reeglid on: 8.3.3.1. riski esinemise tõenäosus 3 palli süsteemis (madal - 1, keskmine – 2, kõrge - 3); 8.3.3.2. riski mõju 3 palli süsteemis (madal - 1, keskmine – 2, kõrge - 3); 8.3.3.3. skoor on riski esinemise tõenäosuse ja mõju korrutis (S = TN x M); 8.3.3.4. prioriteetsed riskid - koefitsiendiga 4-9 - kuuluvad alati ülevaatamisele projekti juhtrühmas; 8.3.3.5. partneriga seotud riskide hindamisel kaasatakse partneri esindaja/ projektijuht, kes vajadusel kaasab hindamisprotsessi omapoolsed spetsialistid. 8.4. Riskide kontroll 8.4.1.Riskide kontroll hõlmab riskide juhtimise tulemuste kontrollimist ning otsustamist, kas on lisandunud uusi riske, kas on muutunud mõne riski skoor, millised on abinõud riskide edasiseks juhtimiseks. 8.4.2. Konkreetsete tegevuste täitmise eest vastutajad ning tähtajad kannab täitja projektijuht üldisesse tööplaani. Nimetatud tegevuste täitmist kontrollib ja esitab ülevaate täitja projektijuht projekti edenemise seisu raportis. 9. Tööprotsessid 9.1. Antud peatüki eesmärk on kirjeldada olulisemad tööprotsessid selleks, et meeskonnal oleks ühene arusaam, kes, mida, millal ja kuidas teeb. Nt protsess, kuidas toimub mingite nõuete ja analüüsitulemite ülevaatus ja kinnitamine projekti erinevate osapoolte vahel. 9.2. Projekti alguses toimub avakoosolek (vajadusel mitu) ning luuakse kõigile osapooltele vajalikud ligipääsud tööde teostamiseks. 9.3. Täitja teostab arendustööd vastavalt hanke tehnilisele kirjeldusele ja selle lisadele. 9.4. Arendustööd teostatakse täitja poolt tellija poolses keskkonnas, millele tellija organiseerib täitja jaoks vajalikud ligipääsud. 9.5. Tööde tulemid peavad olema täitja poolt testitud ning vastama tehnilises kirjelduses ja selle lisades seatud ootustele vastavalt hankelepingus ja tehnilises kirjelduses ettenähtud ajaraamile ning tähtaegadeks. 9.6. Tööde registreerimiseks teavitab tellija täitjat töö vajadusest, esitades töö ettepaneku tööde / vigade halduskeskkonnas. 9.7. Täitja kirjeldab eelanalüüsi käigus vastavalt tellija poolt esitatud lähteülesandele tööle tehnilise lahenduskäigu ning annab tööle mahuhinnangu tundides. 9.7.1. Kui tööd ei ole võimalik enne teostamist hinnata, siis arendaja teavitab sellest tellijat. 9.7.2. Tellija kinnitusel võtab täitja sõltuvalt töö skoobist mõistliku mahu (4 kuni 8h) tööga tutvumiseks ja annab selle kohta teavituse töö piletisse enne tööga alustamist. 9.7.3. Täitja annab tööga tutvumise järgselt tööle seejärel lõpliku hinnangu alles peale mainitud aja jooksul tööga tutvumist. Kui töö nende tundide jooksul laheneb, siis täiendavat hinnangut ei teki. 9.8. Tellija kinnitab töö teostamise ja suunab selle töödekuhja pakkujale teostamiseks. 9.8.1.Tellijal on õigus pakutud mahuhinnang tagasi lükata või töö teostamine peatada ning arendustööd mitte tellida. 9.9. Täitja teostab tööde osas aruandlust. 9.9.1.Täitja peab tööde osas arvestust rollide kaupa ja esitab tööde kohta aruande tööde üleandmise ja vastuvõtmise aktis sisalduva tabeli kujul. 9.9.2. Täitja esitab tellijale aruande iga kuu kohta, mis sisaldab täitja poolt veaparandus ja/või tellimuste alusel tehtud tööde (sh garantiiliste tööde) nimekirja (sh. tarneid ja vastuvõetud töid) ning mahtu (töötunnid). 9.9.3. Täitja esitab aruanded tellijale vähemalt 1 kord kuus. 9.10. Täitja peab salvestama tööde aruandlust (logima töö teostamiseks kulunud aega) tööde/vigade halduskeskkonnas (Jira) kasutades selleks tellija poolt aktsepteeritud aja logimise lahendust (TEMPO). 9.10.1. Täitja peab tööde teostamiseks kulunud aega salvestama vastava töö pileti külge iga päev kui tööd on tehtud. 9.10.1.1. Ei ole aktsepteeritav, et täitja esitab ajaaruanded töö pileti tasemel suuremas mahus kui 1 päev (8 tundi) viivitusega.  9.10.2. Tööde aruandluse salvestamine tööde/vigade halduskeskkonda on kohustuslik ja on tööde akteerimise aluseks. 9.11. Täitja annab aruande alusel tööd üle aktiga. 9.11.1. Akteerimisele kuuluvad ainult tööd, mis on hinnatud või muul juhul tellija poolt töösse kinnitatud ja peale täitja poolset tööde teostamist tellija poolt tööde / vigade halduskeskkonnas vastu võetud ja/või jõudnud muu resolutsioonini (nt. katkestatud, tühistatud, ...), kus tellija kinnitab teostatud tööde akteerimise. 9.11.2. Tellijal on õigus töösse eelnevalt kinnitamata täitja poolt raporteeritud töötunde mitte akteerida. 9.12. Täitja suunab tööga seotud pileti tellijale kui töö on valmis vastuvõtutestimiseks (test) keskkonnas. 9.12.1. Piletisse tuleb märkida seos nõuetega, vastavalt hanke tehnilisele kirjeldusele ja selle lisadele, mida see pilet mõjutab. 9.12.2. Piletisse tuleb lühidalt kirjeldada teostatud töö tulem ning võimalusel viidata tehtud tööle tellija keskkonnas ja/või koodi asukohale koodihalduskeskkonnas. 9.12.3. Piletisse tuleb märkida viide dokumentatsioonile, mida tööde käigus loodi, muudeti või täiendati. 9.12.4. Kulupõhise arvelduse puhul peab piletis olema tööde teostamiseks kulunud aeg (TEMPO). 9.13. Suunamise eest järgmisele täitjale vastutab vaikimisi isik, kelle nimel pilet on. 9.13.1. Uute piletite määramise eest täitjale vastutatavad tellija ja täitja projektijuhid. 9.14. Tööde tarnimine täitja keskkondadest tellija keskkondadesse toimub peale täitjaga kooskõlastamist ning tarnete puhul lähtutakse tellija muudatuste halduse protsessist. 9.15. Tellija testib tulemeid esialgu võimalusel test keskkonnas ja peale tarnet ka toodangu (live) keskkonnas. 9.15.1. Juhul kui töös esineb vigu, annab tellija omalt poolt tagasisidet täitjale, et täitja saaks teha vajalikud parandused. 9.16. Tellija kinnitab tulemid, kui need vastavad tehnilises kirjelduses ja selle lisades seatud ootustele tulemi suhtes toodangu keskkonnas (live) – Definition of Done (DoD). 10. SCRUM protsessid 10.1. Antud peatükki kohaldatakse juhul, kui projektis on kasutusel SCRUM arendusmetoodika. 10.2. Tellija on tooteomaniku (Product Owner; PO) rollis. 10.3. Täitja on Scrum Master (SM) rollis. 10.4. SCRUM sündmused 10.4.1. Sprint on Scrum-i konteinersündmus. 10.4.2. Sprint sisaldab kõiki vajalikke töid sh: 10.4.2.1. Analüüs 10.4.2.2. Disain 10.4.2.3. Arhitektuur 10.4.2.4. Arendus 10.4.2.5. Testimine 10.4.2.6. Jne. 10.4.3. Sprint kestab 1-4 nädalat (maksimaalselt 1 kuu). 10.4.3.1. Enamasti on kokkuleppeliselt projektis sprindi kestvuseks 1-2 nädalat. 10.4.4. Sprint võimaldab prognoosimist ja riski piirangut – iga sprindi lõpus on mõõdetav tulemus. 10.4.5. Sprindi võtmesisendid: 10.4.5.1. Toote backlog 10.4.5.2. Tiimi võimekus (velocity; capacity) 10.4.5.3. Valmimiskriteeriumid (DoD – Definition of Done)  10.4.5.4. Viimane töötav tarkvara versioon (increment) ja tagasiside retrospektiivist. 10.4.6. Sprindi eesmärk on võtmeväljundina luua töötav ja potentsiaalselt lansseeritav (tootestatav) tarkvara versioon (increment). 10.4.7. Sprindi sündmused: 10.4.7.1. Sprint planning – Sprindi alustamine õige fookusega. 10.4.7.1.1. Eesmärk: 10.4.7.1.1.1. Määrata, millised tööülesanded lähevad toote backlogist sprindi backlogi. 10.4.7.1.1.2. Koostada plaan, kuidas sprindi jooksul seatud eesmärk saavutada. 10.4.7.1.2. Kestvus ja regulaarsus: 10.4.7.1.2.1. Kuni 2 h iga nädala kohta (maksimaalselt 8 h 4-nädalase sprindi kohta). 10.4.7.1.3. Väljund: 10.4.7.1.3.1. Sprint backlog – konkreetne tööplaan kogu sprindi jaoks. 10.4.7.2. Daily Scrum – Igapäevane lühikoosolek sprindi sujuvaks edenemiseks. 10.4.7.2.1. Eesmärk: 10.4.7.2.1.1. Ülevaade viimase 24h progressist sprindi eesmärgi suhtes. 10.4.7.2.1.2. Vajadusel sprindi backlogi uuendamine. 10.4.7.2.2. Kestvus ja regulaarsus: 10.4.7.2.2.1. Kuni 15 minutit iga päev samal ajal. 10.4.7.2.3. Väljund: 10.4.7.2.3.1. Järgmise 24h plaan. 10.4.7.3. Sprint Review – Iteratiivne tagasiside sessioon. 10.4.7.3.1. Eesmärk: 10.4.7.3.1.1. Vaadata üle sprindi jooksul valminud versioon (increment).  10.4.7.3.1.2. Vajadusel uuendata toote backlogi lähtuvalt tagasisidest. 10.4.7.3.2. Kestvus ja regulaarsus: 10.4.7.3.2.1. Iga sprindi lõpus 1 kord kuni 1 h iga nädala kohta (maksimaalselt 4 h 4-nädalase sprindi kohta). 10.4.7.3.3. Väljund: 10.4.7.3.3.1. Uuendatud toote backlog. 10.4.7.4. Sprint Retrospective – tiimi eneseanalüüs ja parendamine. 10.4.7.4.1. Eesmärk: 10.4.7.4.1.1. Selgitada välja parendused, mida saab rakendada järgmise sprindi jooksul. 10.4.7.4.2. Kestvus ja regulaarsus: 10.4.7.4.2.1. Kohe pärast Sprint Review-d 1 kord kuni 1 h ia nädala kohta (maksimaalselt 4 h 4-nädalase sprindi kohta). 10.4.7.4.3. 1-2 planeeritud parendust järgmisesse sprinti. 11. Tööde piirangud 11.1. Tööde teostamisel peab arvestama, et TEHIKu pärandandmelaod laadivad infosüsteemide PostgreSQL ja Oracle baasidest Pentaho abil SAP IQ andmeladudesse. Andmeanalüüsi keskkonnana on kasutusel WebFocus, sh veebipõhine töökeskkond WebFOCUS InfoAssist. 11.2. Kõigi uute loodavate lahenduste puhul tuleb kasutada tehnoloogiaid, mis on kirjeldatud tellija IT profiilis. IT profiili ning teiste kohalduvate dokumentide viited (mittefunktsionaalsed nõuded, nõuded andmeladude arendusele, automaattestimisele) ning nende materjalide kasutamine ja kohaldamine raamlepingu jooksul on täpsemalt kirjeldatud raamlepingus. 11.3. Sõlmitavates hankelepingutes on tellijal ja täitjal õigus kokku leppida täiendavaid tehnilisi vahendeid (näiteks väliste andmefailide laadimiseks, andmete presenteerimiseks). 11.4. Nii toodangueelsed kui toodangukeskkonnad asuvad tellija juures. Plaanitavad uued komponendid nendes keskkondades peab looma täitja, seejuures eeldab tellija, et kui ei ole spetsifitseeritud teisiti, peab pakkuja eeldama, et tema vastutab projektides järgnevate tegevuste eest: 11.4.1. mikroteenuste loomine vastavalt tellija poolt esitatud arhitektuuriplaanile; 11.4.2. täies mahus CI/CD töövoogude koostamine; 11.4.3. rakenduste paigaldus tellija DEV keskkonda läbi loodud CI/CD töövoo ning testkeskkonda koos tellija poolse süsteemiadministraatoriga;  11.4.4. regulaarsete koodiläbivaatuste läbiviimine meeskonna siseselt; 11.4.5. automaatsete testide koostamine vastavalt TEHIKu automaattestide koostamise juhendile; 11.4.6. peakasutaja(te) koolitamine; 11.4.7. dokumentatsiooni koostamine; 11.4.8. mittefunktsionaalse monitooringu loomine rakendustele; 11.4.9. funktsionaalse monitooringu loomine rakendustele vastavalt kokkuleppele tellijaga. 11.5. Tarkvara arenduse käigus tuleb lähtuda suunistest, mis on kättesaadaval aadressil https://tehik.ee/arendusjuhendid. 11.6. Tarkvara arenduse puhul tuleb eelistada konteiner lahendusi. Esimene eelistus Apache Hop või custom konteiner (tuleb kooskõlastada arhitektiga). 11.7. Tarkvara arenduse käigus võib kasutada ainult tellija repositooriumis olevaid teeke. Juhul, kui on vajadus kasutada mõnda avalikku või mingit muud teeki, siis see tuleb see enne kooskõlastada tellija arhitektiga. 11.8. Kõik kõrvalekalded eelnevast tuleb kooskõlastada tellija arhitektiga. 11.9. Tellija eeldus on, et täitja ei pea enese juures looma ei eraldi arenduskeskkonda ega keskkondi tööde, dokumentatsiooni ega koodi haldamiseks ja säilitamiseks. Juhul, kui täitja peab vajalikuks luua mõne komponendi jaoks enese juures arenduskeskkonda, luuakse see täitja kuludega, sh võimalikud täiendavad litsentsitasud. 11.9.1. Arendustööde läbiviimiseks on vajalik ligipääs olemasolevate ning loodavate andmeladude toodangueelsetele keskkondadele. 11.9.2. Andmeladude keskkonnad hõlmavad ladude baase, andmelaadimise funktsioone, andmeparandusfunktsioone ning aruandluskeskkondi. 11.9.3. Lähtekoodi ja skriptide tarnimiseks ning töövoogude koostamiseks on kasutusel GitLab 11.9.4. Sõltuvuste repositoorium on vaikimisi tellija Artifactory. 11.9.5. Kubernetese halduseks on kasutusel Rancher. 11.9.6. Dokumentatsioon ja juhendid tarnitakse tellija Confluence keskkonda https://wiki.sm.ee. 11.9.7. Tööde halduseks on kasutusel JIRA keskkond https://smjira.sm.ee. 11.9.8. Aja logimiseks on kasutusel Tempo. 11.9.9. Aktsepteeritud suhtluskanaliteks on tellija Rocket.Chat, Microsoft Teams, tellija Jira/Confluence ja e-mail. 11.9.10. Enamuse rakenduste ja keskkondade ligipääs on arendajale võimalik ainult VPN tunneli kaudu. IP põhiseid ligipääse vaikimisi ei looda. VPN tunneli kasutamiseks on vajalik Eesti ID kaart või Digi-ID.  ISIKUANDMETE TÖÖTLEMISE TINGIMUSED ... (edaspidi volitaja), registrikood //, asukohaga //, keda esindab direktor // ja ..... (edaspidi volitatud töötleja), registrikood //, asukohaga //, keda esindab juhatuse liige/volikirja alusel //. 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 /...hankelepingu nimetus.../ 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. 1.4. //. 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 järgmises koosseisus: 2.1.1. /... Infosüsteemi nimetus .../ andmed vastavalt // pp.kk.aaaa määruse nr // /... määruse nimetus .../ peatükile nr // /... peatüki nimetus .../. 2.1.2. // 2.1.3. VÕI 2.1.4. // 2.1.5. isikuandmed, nt inimese nimi, sünniaeg, isikukood, isikut tõendava dokumendi andmed; 2.1.6. kontaktandmed, nt aadress, telefoninumber ja e-posti aadress; 2.1.7. eriliigilised isikuandmed, nt andmed isiku või tema pereliikme terviseseisundi, majandusliku seisundi või perekonna kohta; 2.1.8. ameti- ja kutsesaladust puudutav teave. 2.1.9. // 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/  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 Roll / Nimi Maht Tunnihind Maksumus kokku (ID) töö nimetus (h) (€/h) KM-ta (€) KM-ta 1 Roll 1 ___ € Roll 2 2 (...) (...) 3 4 ... ___ € 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. 5. Poolte allkirjad Tellija: Täitja: Lepinguline kontaktisik lepinguline kontaktisik /allkirjastatud digitaalselt/ /allkirjastatud digitaalselt/  Hankeleping nr 3-9/4515-5 Lepingu osa viitenumber 273311 004 003 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 Wizon OÜ (edaspidi täitja), registrikood 12570796, aadress Harju maakond, Tallinn, Kesklinna linnaosa, Rotermanni tn 8, 10111, keda esindab põhikirja alusel juhatuse liige Marko Tammsaar, edaspidi eraldi pool või koos pooled, sõlmisid raamlepingu nr 3-9/4515-1 alusel käesoleva hankelepingu (edaspidi leping) alljärgnevas: Lepingu ese 1.1. Lepingu esemeks on riigihanke „Tervisekassa andmelao ("STEEL") jätkuarendused ja hooldustööd“ alusdokumentides (minikonkursi viitenumber 307718) olevas tehnilises kirjelduses nimetatud hooldustööd (edaspidi tööd). 1.2. Lepingu tööde maht maksimaalne maht on 150 000 eurot käibemaksuta. 2. Töö üleandmise ja vastuvõtmise tingimused 2.1. Täitja annab töö üle igakuiselt 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. Töö teostamise tähtaeg on 36 kuud alates lepingu sõlmimisest. Leping jõustub sõlmimise hetkel ja kehtib kuni 37 kuud või kuni poolte poolt oma kohustuste täitmiseni. 3. Lepingu hind 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 60 (kuuskümmend) 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. 3. Poolte vahelised teated ja kontaktisikud 3.1. Teadete edastamisel ja kätte toimetamisel lähtutakse raamlepingu regulatsioonist. 3.2. Tellija kontaktisikuks lepingu täitmisel on Sten Martmaa, tel 5333 8534, e-post [email protected] või tema asendaja.  3.3. Täitja kontaktisikuks lepingu täitmisel on Andres Kukk, tel 513 4481, e-post [email protected] või tema asendaja. 4. Lõppsätted 4.1. Leping jõustub sellele poolte poolt allakirjutamise hetkest ja lõppeb poolte poolt oma lepinguliste kohustuste täitmisega. 4.2. Lepingu dokumendid koosnevad riigihanke alusdokumentidest, sh lepingu lisadest, lepingu muudatustest ja pakkumusest. 4.3. Lepingu lahutamatuteks osadeks lepingu sõlmimise hetkel on järgmised dokumendid: 4.3.1. Lisa 1 - Tehniline kirjeldus; 4.3.2.Lisa 2 – Kodukord; 4.3.3. Lisa 3 – Isikuandmete töötlemise tingimused; 4.3.4. Lisa 4 – Tööde üleandmise ja vastuvõtmise akt; 4.3.5. Lisa 2 – Pakkumus (ei allkirjastata koos lepinguga). 5. Poolte allkirjad Tellija: Täitja:  Tehniline kirjeldus Tervisekassa andmelao ("STEEL") jätkuarendused ja hooldustööd 1. Mõisted ja lühendid See peatükk loob ülevaate käesolevas hankedokumentatsioonis ja tööde käigus enim kasutusel olevatest mõistetest ja lühenditest ning selgitab nende tähendused. TEHIK Tervise ja Heaolu Infosüsteemide Keskus STEEL Tervisekassa andmeladu Andmeladu / Andmeait Andmeladu on struktureeritud kogum integreeritud, kindlale teemale suunatud, püsiva loomuga ja ajast sõltuvaid andmeid, mille ülesandeks on toetada otsuste tegemist. ODS kiht Andmelaos olev kiht (schema, dbspace või muu andmelao platvormist tulenev objekt), kuhu kantakse alliksüsteemist andmed sellisel kujul nagu need alliksüsteemis on. EDW kiht Andmelaos olev kiht (schema, dbspace või muu andmelao platvormist tulenev objekt), mis luuakse vajadusel integratsiooni, andmemudeldamise ja transformatsiooni jaoks. DWH kiht Andmelaos olev presentatsiooni kiht (schema, dbspace või muu andmelao platvormist tulenev objekt) kuhu luuakse analüütikute töö aluseks olevad tabelid inimkeelsete nimedega ja arusaadavate seostega. Andmed võetakse ODS kihist või EDW kihist (vastavalt alusandmestikele) ja viiakse optimaalsele kujule aruannete kokkupaneku lihtsustamiseks ja päringute kiiruste optimeerimiseks . Analüütikakeskkond / analüütikarakendus Analüütikakeskkond on presentatsiooni kihil töötav visuaalsete aruannete loomise rakendus, mis toetab äriliste otsuste tegemist ning mille sisendiks on andmelaos ja muudes andmeallikates olevad andmed. Andmete esitlus on visuaalne ja/või masinloetav. Tarkvara Tarkvara tähistab baastarkvara või tarkvaraplatvormi (näiteks Pentaho, Apache Hop, Vertica, Tableau jms andmeladudega seotud tarkvara). [1] Teenustase võib raamlepingu perioodil muutuda, sellest teavitatakse täitjat esimesel võimalusel.  Töödekuhi Töödekuhi ehk backlog on tööde / vigade halduskeskkonnas olev nimekiri töökäskudest. Tööde / Vigade halduskeskkond Tööde ja vigade halduskeskkond on tellija keskkonnas asuv rakendus vigade ja arenduste haldamiseks kasutusel olev programm (nt. Jira). Dokumentide halduskeskkond Dokumentide halduskeskkond on tellija keskkonnas asuv rakendus dokumentide ja informatsiooni (nt. spetsifikatsioonid, juhendid, koosolekute memod) haldamiseks kasutusel olev programm (nt. Confluence). Reageerimisaeg Reageerimisaeg on aeg, mis on täitjal tellija päringule vastamiseks. Teenindusaeg / tööaeg Teenindusaeg ehk tööaeg on vastavalt arendustööde tingimustele SLA (arendustööde tingimused / rakenduste teenustasemed) tabelis sätestatud teenindusaegadele. Muu aeg on tööväline aeg. Lahendusaeg Lahendusaeg tähendab perioodi tellimuse saamisest kuni tööde valmimiseni, mille jooksul täitja on kohustatud teostama kõik tööd (sh. arendustöö, jooksva arendustöö, veaparanduse ning täitma garantiist tulevad kohustused) vastavalt lahendusaja tabelile ja SLA (arendustööde tingimused / rakenduste teenustasemed) tabelile. Tarne 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. Tarneteatise vormi kehtestab tellija hankelepingu täitmise käigus. Paigalduslogi Paigalduslogi on informatsioon rakenduste igasuguste muudatuste (nt. tarnete paigaldamise) kohta kirjalikku taas-esitamist võimaldavas vormis. RL Raamleping TK Tehniline kirjeldus [1] Teenustase võib raamlepingu perioodil muutuda, sellest teavitatakse täitjat esimesel võimalusel. 2. Üldine 2.1. Hanke eesmärk on sõlmida hankeleping ja hooldusleping (SLA) pakkujaga, kes hakkab teostama Tervisekassa andmelao ("STEEL") arendus- ja hooldustöid. 2.1.1. Hanke võitva pakkujaga sõlmitakse 2 lepingut: 2.1.1.1. Hankeleping 2.1.1.2. Hooldustööde leping (SLA) 2.1.2. Olemuselt on mõlemad lepingud seotud ühe ja sama esemega. 2.2. Tööde skoop sisaldab: 2.2.1. Juba liidestunud süsteemidest täiendavate andmete ODS‑kihti kandmise arendus: olemasolevatest Tervisekassa SAP‑süsteemidest (RERP, HERP, CRM) uute andmehulkade tuvastamine, analüüs, ODS‑struktuuride loomine või täiendamine, laadimiste arendus ja testimine. 2.2.2. Arendustööd uute andmeallikate liidestamiseks andmelaoga ja andmete ODS‑kihti toomiseks: analüüsi käigus määratletavate uute süsteemide (näiteks Ravimiskeem, Ravimiregister, MEDRE jt) ODS‑mudeli loomine, laadimiste arendus ja valideerimine. 2.2.3. Analüüsitööd ja arendused olemasolevate andmete kandmiseks ODS-kihist EDW kihti: EDW kihti loodavate tabelite struktuuri, andmevajaduste ja transformatsioonide analüüs. Andmeallikate ja ärinõuete põhjal andmemudelite koostamine ning olemasolevate mudelite täiendamine. ODS → EDW andmelaadimiste disain, arendus ja testimine. 2.2.4. EDW‑andmetest tuletatud presentatsioonikihi (DWH) tabelite ja vaadete loomine ja laadimiste arendamine vastavalt analüütiliste kasutusjuhtude vajadustele. DWH‑struktuuride täiendamine ja optimeerimine tööpiletites täpsustatud ulatuses. 2.2.5. Arendus- ja hooldustööd andmete ettevalmistamiseks automaatseks ja regulaarseks väljastamiseks andmelaost (sh üle x-tee). 2.2.6. Dokumentatsiooni koostamine: loodud töövoogude, transformatsioonireeglite, mudelite ja konfiguratsioonide dokumenteerimine vastavalt TEHIK arendusjuhenditele ja olemasoleva dokumentatsiooni täiendamine vastavalt tehtud täiendustele. 2.2.7. Hooldustööd ja SLA‑järgne tugi: olemasolevate ODS‑, EDW‑ ja DWH-kihi töövoogude hooldus, parandused, väiksemad arendus- ja täiendusülesanded ning töövoogude toimimise jälgimine vastavalt SLA‑le. 2.2.8. Kõik käesolevas tehnilises kirjelduses (TK) punktis 5.1 nimetatud tööd. 3. Hanke eseme tutvustus [1] Teenustase võib raamlepingu perioodil muutuda, sellest teavitatakse täitjat esimesel võimalusel.  3.1. Hanke esemeks on Tervisekassa andmelao (“STEEL”) analüüsi-, arendus- ja hooldustööd, mis on vajalikud andmelao kasutuselevõtuks, uute andmeallikate liidestamiseks ning ODS‑, EDW‑ ja DWH-kihtide täiendamiseks. Tööde tulemusel peavad olema tagatud uute ja olemasolevate andmete korrektne laadimine, transformatsioonid ja esitamine Tervisekassa ärivajaduste tarbeks. 3.2. Arhitektuurijoonised leiab käesoleva dokumendi Lisadest (Lisa 1.4 - TERK STEEL andmeplatformi arhitektuurne lahendus ning tehniline teostus_README) 3.3. Põhilised märksõnad kasutusel olevate standardite, tehnoloogiate ja teekide osas on X- tee; HL7; CDA; FHIR; JSON; Vertica; Apache Hop; Power BI; DBT; CI/CD; Kestra; Liquibase; Oracle; Postgre; SAP HANA; MS SQL. 4. Töö tehnilised nõuded 4.1. Rakenduste tehniline kirjeldus ja nõuded on dokumenteeritud käesolevas dokumendis ja selle lisades. 4.2. Tööd teostatakse arvestades tellija poolt esitatud dokumenteerimise nõudeid „TEHIK nõuded infosüsteemi dokumentatsioonile“ ja täiendavaid materjale asukohaga https://www.tehik.ee/arendusjuhendid (vt. ka „Tööde piirangud“). 5. Tööde teostamine 5.1. Töödeks on arendus- ja veaparandus/hooldustööd, mille hulka kuuluvad raamlepingus käsitletud tehnoloogiad ja tööd: 5.1.1. analüüsitööd; 5.1.2. arhitektuuritööd; 5.1.3. arendusressurss (Bodylease); 5.1.4. programmeerimistööd; 5.1.5. testimistööd (end-to-end automaatestimine); 5.1.6. juurutustööd; 5.1.7. koolitused; 5.1.8. konsultatsioon; 5.1.9. dokumentatsiooni koostamine; 5.1.10. jooksvate muudatusvajaduste realiseerimine; 5.1.11. veaparandustööd; 5.1.12. hooldustööd; 5.1.13. Dev-ops CI/CD. 5.2. Täitja teostab tööd kahes (2) etapis: 5.2.1. I etapp: 5.2.1.1. STEEL jätkuarendused [1] Teenustase võib raamlepingu perioodil muutuda, sellest teavitatakse täitjat esimesel võimalusel.  5.2.1.2. I etapi tööde tulemiks on: 5.2.1.2.1. EDW kihi analüüs: 5.2.1.2.1.1. EDW‑ kihti vajalike tabelite ja struktuuride analüüs vastavalt ärilistele vajadustele, 5.2.1.2.1.2. Transformatsioonireeglite ja loogiliste seoste kirjeldamine ODS‑ kihist EDW‑ kihti kandmiseks. 5.2.1.2.1.3. Loogilise, kontseptuaalse ja füüsilise mudeli täiendamine ning uute mudelielementide loomine. 5.2.1.2.1.4. Analüüsi käigus tuvastatud uute andmeallikate sobivuse hindamine ja kasutamise põhimõtete kirjeldamine EDW‑ kihis. 5.2.1.2.2. EDW kihi arendus: 5.2.1.2.2.1. EDW‑ tabelite loomine ja olemasolevate tabelite täiendamine analüüsi tulemustele vastavalt. 5.2.1.2.2.2. Andmete ODS →EDW laadimiste disain, arendus ja testimine. 5.2.1.2.2.3. Transformatsioonireeglite realiseerimine ja optimeerimine. 5.2.1.2.2.4. EDW‑ kihti vajalike tehniliste konfiguratsioonide loomine (töövood, laadimisskriptid, kontrollreeglid). 5.2.1.2.3. DWH kihi arendus 5.2.1.2.3.1. EDW‑andmetest tuletatud presentatsioonikihi (DWH) tabelite ja vaadete loomine ja laadimiste arendamine vastavalt analüütiliste kasutusjuhtude vajadustele. 5.2.1.2.4. Uute andmete toomine ODS-kihti: 5.2.1.2.4.1. Uute andmeallikate (nt Ravimiskeem, Ravimiregister, MEDRE jt) analüüs, ODS‑ mudeli loomine ja laadimiste arendus. 5.2.1.2.4.2. Täiendavate andmehulkade toomine olemasolevatest Tervisekassa SAP‑ süsteemidest (RERP, HERP, CRM) ja nende integreerimine ODS‑ kihti. 5.2.1.2.4.3. ODS‑ tabelite struktuuride loomine või täiendamine vastavalt uute andmete vajadustele. [1] Teenustase võib raamlepingu perioodil muutuda, sellest teavitatakse täitjat esimesel võimalusel.  5.2.1.2.5. Teha andmekvaliteedi kontrollid ja testid: 5.2.1.2.5.1. Andmehulkade vastavuse kontroll (kirjete arvud, struktuurid, väljade kvaliteet). 5.2.1.2.5.2. Transformatsioonireeglite ja ärireeglite järgimise esmane valideerimine ODS‑ ja EDW‑ tasandil. 5.2.1.2.5.3. Monitooringu jaoks oluliste andmelaadimiskontrollide loomine. 5.2.2. II etapp: 5.2.2.1. STEEL arendus- ja hooldustööd (SLA) 5.2.2.1.1. Tavapärasteks tööülesanneteks on seotud keskkondades tekkivate veaolukordade analüüsimine ja parandamine ning arendusvajaduste realiseerimine nt uute laadimiste loomine ja olemasolevate laadimiste muutmine ja konfigureerimine sh ka võimalikud migratsioonid erinevate süsteemide vahel, mille eesmärgiks on äritellija analüütika/aruandluse vajaduste rahuldamine. 5.2.2.2. II etapi tööde tulemiks on: 5.2.2.2.1. Väikearendus- ja hooldustööd, mis tagaksid turvalisuse, tehnilise optimeerituse, töökindluse ja edasise haldus- ning edasiarendussuutlikkuse. 5.3. Tööde teostamisel peab arvestama, et: 5.3.1. Tööd teostatakse vastavalt TEHIKu arenduskeskkondade tehnilistele nõuetele ja arendusjuhenditele. 5.3.2. Kõik loodud töövood, konfiguratsioonid, mudelid ja muud arenduse tulemid peavad olema dokumenteeritud. 5.3.3. Andmelao kihid (ODS, EDW, DWH) peavad säilitama struktuurse ja semantilise järjepidevuse. 5.3.4. Uute andmeallikate liidestamisel tuleb arvestada võimalikku andmekvaliteedi varieeruvust ning tagada ühtsed laadimis- ja transformatsioonipõhimõtted. 5.4. Konkreetsed funktsionaalsed nõuded täpsustatakse arendustööde käigus loodavates piletites. 5.5. Tellija tagab tööde teostamiseks ligipääsu vajalikele keskkondadele ja vajadusel omapoolse abi. Ligipääsu tehnilised tingimused jms täpsustatakse tööde teostamise käigus. 5.6. Hankelepingu täitmise tulemina peab pakkuja andma tellijale üle: 5.6.1. Tööde jooksul tekkivate tellimuste alusel teostatud tööd vastavalt tellimuses, käesolevas tehnilises kirjelduses ja selle lisades toodud skoobile. [1] Teenustase võib raamlepingu perioodil muutuda, sellest teavitatakse täitjat esimesel võimalusel.  5.6.2. Teostatud tööde dokumentatsioon (sh kasutusjuhend). 6. Meeskond 6.1. Käesolevaks tööks peab pakkuja esitama meeskonna, mis koosneb minimaalselt järgnevatest rollidest: 6.1.1. Projektijuht 6.1.2. Analüütik 6.1.3. Arhitekt/vanemarendaja 6.1.4. Süsteemiarhitekt 6.1.5. Arendaja 6.2. Kõik raamlepingus esitatud meeskonnaliikmed tuleb esitada hankega kaasas oleva meeskonna vormil või uue meeskonnaliikme lisamise korral lisaks ka raamlepingu (RL) meeskonna vormil. 6.2.1. Uue meeskonnaliikme lisamiseks tuleb täita RL meeskonna vormis plokis 2 individuaalse kogemuse andmed: "2. Individuaalsed nõuded kogu pakkuja meeskonnale (nõuded tuleb täita iga esitatud meeskonna liikme poolt individuaalselt)" 6.2.2. Uus meeskonnaliige peab omama vähemalt ühte kompetentsi/kogemust ühiste nõuete plokist ja see tuleb tõendada RL meeskonna vormis vastavas plokis andmed täites: "3. Ühised nõuded kogu pakkuja meeskonnale (nõuded tuleb täita esitatud meeskonna peale kokku)". 6.3. Pakkuja peab esitama lepingu sõlmimiseks isikuliselt vähemalt 5 meeskonnaliiget eelnevalt defineeritud rollidesse. 6.3.1. Rolle ei ole lubatud katta (st sama isik, ei tohi olla esitatud mitmes erinevas rollis). 6.3.2. Samasse rolli (näiteks mitme arendaja puhul) ei saa määrata sama isikut. 6.3.3. Hankelepingu kehtivuse perioodil võib vastavalt vajadusele tellijaga eelnevalt kooskõlastades RL punkt 5.2 alusel meeskonda uusi täiendavaid nõuetele vastavaid liikmeid juurde lisada käesolevas tehnilises kirjelduses punktis 6.2 kirjeldatud viisil. 6.4. Pakkuja peab tagama, et pakutud meeskonna koosseis on tööde teostamiseks tellija jaoks kogu hanke perioodil täis töömahus olemas. 6.4.1. Hankijal ei ole kohustust tagada täismahus kõigi meeskonnaliikmete hõivatust, kuid pakkujal peab olema valmidus pakkuda eelpool kirjeldatud mahus meeskonda kogu hanke perioodil tellitavate tööde teostamiseks. 7. Mahud ja ajakava 7.1. Tööde teostamise ajad (etappide korral ka etapid) ja lepingute kehtivusajad on sätestatud hankelepingus. [1] Teenustase võib raamlepingu perioodil muutuda, sellest teavitatakse täitjat esimesel võimalusel.  7.1.1. Täitja teostab tööd vastavalt hankelepingus toodud tähtaegadele. 7.1.2. Kui etappidele pole lepingu kehtivuse kuupäevadega seatud omavahelist järjestikust sõltuvust, siis võivad etapid ka osaliselt või täielikult kattuda ning toimuda paralleelselt. 7.2. Projekti eelduslik töömaht kokku on ~ 10 000 tundi. 7.2.1. Eelduslik töömaht arendus- ja hooldustööde lepingute vahel jaguneb järgmiselt: 7.2.1.1. Hankelepingu maksimaalne maht kuni 500 000 EUR eeldusliku töömahuga ~8000 tundi. 7.2.1.2. Hooldustööde lepingu maksimaalne maht kuni 150 000 EUR eeldusliku töömahuga ~2000 tundi. 7.3. Projekti eelduslikud töömahud rollide lõikes: 7.3.1. Projektijuht: ca 500 h. 7.3.2. Analüütik: ca 3000 h. 7.3.3. Arhitekt/vanemarendaja: ca 2000 h. 7.3.4. Süsteemiarhitekt: ca 500 h. 7.3.5. Arendaja: ca 4000 h. 7.4. Projekti eelduslikud töömahud etappide lõikes: 7.4.1. I etapp (STEEL jätkuarendused): kuni 8000 h. 7.4.2. II etapp (STEEL arendus- ja hooldustööd) (SLA): kuni 2000 h. 7.5. Kõik eelduslikud töömahud on hankija eelduslikud arvutused muuhulgas hanke eeldatava maksumuse määramiseks. 7.5.1. Märgitud töömahud ei ole hankes siduvad. 7.5.2. Hankijal ei ole kohustust nimetatud töömahtude väljaostmiseks. 7.5.3. Eelduslike töömahtude puhul arvestatakse kogumahtu ning reaalne mahtude jaotumine rollide lõikes selgub tööde käigus. 8. Tööde aruandlus, testimine ja vastuvõtmine 8.1. Tehnilises kirjelduses ja selle lisades kirjeldatud tulemite ära toomiseks teostatakse tööd tellija poolt sätestatud prioriteetidest lähtuvalt. 8.2. Tööde teostamiseks kasutatakse SCRUM arendusmetoodikat. SCRUMi tseremooniad ja nende sagedus lepitakse kokku avakoosolekul. 8.3. Nii arendustööde kui ka hooldus- ja veaparandustööde tellimise, teostamise ja vastuvõtmise täpsem protsess koos nõuetega on kirjeldatud raamlepingus (RL punkt 7), raamlepingu tehnilises kirjelduses (RL TK punkt 5) kui ka projekti kodukorras. 9. Teenustasemed (SLA) [1] Teenustase võib raamlepingu perioodil muutuda, sellest teavitatakse täitjat esimesel võimalusel.  9.1. Maksimaalsed reageerimis- ja lahendusajad, mille jooksul peavad infosüsteemi, tarkvara või rakenduse vead saama hoolduse käigus lahendatud on toodud alljärgnevas tabelis[1]: Ärikriitilisus Kategooria Kirjeldus Reageerimisaeg Lahendusaeg Kõrge (kriitiline A Lahenduse 1 tund 8 tundi viga) kasutamine on tõsiselt häiritud, alternatiivset lahendust ei ole võimalik kasutada Keskmine (häiriv B Lahenduse 1 tööpäev 16 tundi viga) kasutamine on häiritud, kuid alternatiivne lahendus võimaldab tööga jätkata. Madal (pisiviga) C Lahenduse 2 tööpäeva 40 tundi kasutamine ei ole häiritud, vea ilmnemine ei takista otseselt lahenduse kasutamist 9.2. A kategooria juhtumi lahendamine toimub alates tellija pöördumisest täitja poole vajadusel ka tööväliselt kuni veasituatsiooni kõrvaldamiseni, juhul kui tellija kontaktisik esitab juhtumi täitjale lahendamiseks tööajal. Pärast A kategooria hooldusjuhtumi lahendamist on täitja kohustatud vigade halduse tarkvara kaudu teavitama tellija kontaktisikut hooldusjuhtumi lahendamisest ning lahendamisele kulunud ajast. 9.3. B ja C kategooria hooldusjuhtumite puhul esitab täitja tellija kontaktisikule kooskõlastamiseks hooldustööde teostamiseks vajaliku ajakava, ajalise ja rahalise mahu viie tööpäeva jooksul alates tellija pöördumisest täitja poole. Kooskõlastamisele kuluvat aega reageerimise ja lahendamise hulka ei loeta. 9.4. Reageerimis- ja lahendusaeg hakkab kulgema tellija poolt teate välja saatmise hetkest. 9.5. Tellija töövälisel ajal edastatud pöördumine loetakse laekunuks sellele järgneva tööpäeva esimese tunni algusest. 9.6. Kui täitja rikub reageerimisaegadest ja/või lahendusaegadest tulenevat kohustust, siis on tellijal õigus nõuda täitjalt leppetrahvi tasumist vastavalt raamlepingule. 10. Garantii [1] Teenustase võib raamlepingu perioodil muutuda, sellest teavitatakse täitjat esimesel võimalusel.  10.1. Kõigile lepingu alusel teostatud töödele rakendub garantii. 10.2. Garantiitingimused on kirjeldatud raamlepingus (RL punkt 10). 11. Tööde piirangud 11.1. Kõigi uute loodavate lahenduste puhul tuleb kasutada tehnoloogiaid, mis on kirjeldatud tellija IT profiilis. 11.2. Tarkvara arenduse käigus tuleb lähtuda suunistest mis on kättesaadaval aadressil https://tehik.ee/arendusjuhendid. 11.2.1. Automaattestide nõuded 11.2.2. Allkirjastamise teenused SiGa ja SiVa 11.2.3. IT-profiil 11.2.4. Mittefunktsionaalsed nõuded 11.3. Õigusruumi võimalikud piirangud võivad täpsustuda tööde käigus ja täitja peab sellega tööde teostamise puhul arvestama. Neid piiranguid enne tööde algust täpselt öelda ei ole võimalik. Õigusruum ei luba valimatult kõike, mis tehniliselt mugav ja need piirangud võivad täpsustuda kogu hanke perioodil. 11.4. Sõlmitavates hankelepingutes on tellijal ja täitjal õigus kokku leppida täiendavaid tehnilisi vahendeid (näiteks väliste andmefailide laadimiseks, andmete presenteerimiseks). 11.5. Nii toodangueelsed kui toodangukeskkonnad asuvad tellija juures. Plaanitavad uued komponendid nendes keskkondades peab looma täitja, seejuures eeldab tellija, et kui ei ole spetsifitseeritud teisiti, peab pakkuja eeldama, et tema vastutab projektides järgnevate tegevuste eest: 11.5.1. täies mahus CI/CD töövoogude koostamine; 11.5.2. rakenduste paigaldus tellija DEV keskkonda läbi loodud CI/CD töövoo ning testkeskkonda koos tellija poolse süsteemiadministraatoriga; 11.5.3. regulaarsete koodiläbivaatuste läbiviimine meeskonna siseselt; 11.5.4. automaatsete testide koostamine vastavalt TEHIKu automaattestide koostamise juhendile; 11.5.5. peakasutaja(te) koolitamine; 11.5.6. dokumentatsiooni koostamine; 11.5.7. funktsionaalse monitooringu loomine rakendustele vastavalt kokkuleppele tellijaga. 11.6. Tarkvara arenduse puhul tuleb eelistada konteiner lahendusi. Esimene eelistus Apache Hop. Kõik muud alternatiivsed variandid tuleb eelnevalt kooskõlastada TEHIK-u arhitektiga. 11.6.1. EDW kihid luuakse DBT-ga. [1] Teenustase võib raamlepingu perioodil muutuda, sellest teavitatakse täitjat esimesel võimalusel.  11.7. Tarkvara arenduse käigus võib kasutada ainult tellija repositooriumis olevaid teeke. Juhul kui on vajadus kasutada mõnda avalikku või mingit muud teeki siis tuleb see enne kooskõlastada tellija arhitektiga. 11.8. Kõik kõrvalekalded eelnevast tuleb kooskõlastada tellija arhitektiga. 11.9. Tellija eeldus on, et täitja ei pea enese juures looma ei eraldi arenduskeskkonda ega keskkondi tööde, dokumentatsiooni ega koodi haldamiseks ja säilitamiseks. Juhul kui täitja peab vajalikuks luua mõne komponendi jaoks enese juures arenduskeskkonda, luuakse see täitja kuludega, sh võimalikud täiendavad litsentsitasud. 11.10. Arendustööde läbiviimiseks on vajalik ligipääs olemasolevate ning loodavate andmeladude toodangueelsetele keskkondadele. 11.11. Andmeladude keskkonnad hõlmavad ladude baase, andmelaadimise funktsioone, andmeparandusfunktsioone ning aruandluskeskkondi. 11.12. Lähtekoodi ja skriptide tarnimiseks ning töövoogude koostamiseks on kasutusel GitLab. 11.13. Sõltuvuste repositoorium on vaikimisi tellija Artifactory. 11.14. Kubernetese halduseks on kasutusel Rancher. 11.15. Dokumentatsioon ja juhendid tarnitakse tellija Confluence keskkonda https://wiki.sm.ee. 11.15.1. Tarkvara käivitamise ja kasutamise juhendid peavad lisaks olema ka GIT-is koodi juures markdown formaadis. 11.16. Tööde halduseks on kasutusel JIRA keskkond https://smjira.sm.ee. 11.17. Aja logimiseks kasutatakse Tempo. 11.18. Aktsepteeritud suhtluskanaliteks on tellija MS Teams, tellija Jira/Confluence ja e-mail. 11.19. Enamuse rakenduste ja keskkondade ligipääs on arendajale võimalik ainult VPN tunneli kaudu. IP põhiseid ligipääse vaikimisi ei looda. VPN tunneli kasutamiseks on vajalik Eesti ID kaart või Digi-ID. 12. Lisad 12.1. Lisa 1.1 - TEHIK mittefunktsionaalsed nõuded arendustele 19082025 12.2. Lisa 1.2 - Andmeladude olemus ja funktsioon juhis 14042023 12.3. Lisa 1.3 - IT-Profiil v3 veebidoc 12.4. Lisa 1.4 - TERK STEEL andmeplatformi arhitektuurne lahendus ning tehniline teostus_README [1] Teenustase võib raamlepingu perioodil muutuda, sellest teavitatakse täitjat esimesel võimalusel.