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:

[1] Teenustase võib raamlepingu perioodil muutuda, sellest teavitatakse täitjat esimesel võimalusel.

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

viga)

A Lahenduse

kasutamine on

tõsiselt häiritud,

alternatiivset

lahendust ei ole

võimalik

kasutada

1 tund 8 tundi

Keskmine (häiriv

viga)

B Lahenduse

kasutamine on

häiritud, kuid

alternatiivne

lahendus

võimaldab tööga

jätkata.

1 tööpäev 16 tundi

Madal (pisiviga) C Lahenduse

kasutamine ei ole

häiritud, vea

ilmnemine ei

takista otseselt

lahenduse

kasutamist

2 tööpäeva 40 tundi

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

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

vorm

Sagedus Vastutav

roll

Reeglid

Igapäevane

teabevahetus

Jooksvalt Tellija PJ

Täitja PJ

 Tööde läbiviimiseks lepib

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

vajadustele

Tellija PJ

Täitja PJ

 Keerulisematele küsimuste

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

dokumentatsioon

Jooksvalt Tellija PJ

Täitja PJ

 Projekti dokumentatsioon

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

tööülesanded

Iganädalaselt Tellija PJ

Täitja PJ

 Projekti kõiki tööülesandeid

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

puudutav

teabevahetus

Vastavalt

vajadusele

Tellija PJ

Täitja PJ

 Lepingu täitmist puudutav

ametlik teabevahetus, mis pole

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

teabevahetus

Vastavalt

vajadusele

Tellija PJ

Täitja PJ

 Poolte vaheline teabevahetus,

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

D

Valdkon

d

Riski

kirjeldu

s

Riski

realiseerumis

e tagajärg

Risk

i

mõj

u

(M)

Riski

realiseerumis

e tõenäosus

(TN)

Skoo

r (S)

Riski

juhtimise

tegevuse

d

Vastutaj

a

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

(ID) töö nimetus

Roll / Nimi Maht

(h)

Tunnihind

(€/h) KM-ta

Maksumus

kokku

(€) 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/