Raamleping

Lisa 2

Riigihange „Veebipõhise info- ja teenindusportaali arendus- ja hooldustööd“ (290452)

Lisa 2 - Tehniline kirjeldus

1. Hanke üldinfo

1.1. Riigihanke nimetus on „Veebipõhise info- ja teenindusportaali arendus- ja hooldustööd“

(viitenumber 290452).

1.2. Hankijaks on Riigi Info- ja Kommunikatsioonitehnoloogia Keskus (edaspidi Riigi IT Keskus

või RIT).

1.3. Riigihanke eesmärk on sõlmida raamleping veebipõhise info- ja teenindusportaali (edaspidi RIT

portaal või infosüsteem) arendus- ja hooldustööde teostamiseks. Raamlepingu esemeks on

tagada RIT portaali arendamine, toimimine ja regulaarne hooldus.

2. Tehnilise kirjelduse lugemine

2.1. Iga viidet, mille hankija teeb käesolevas dokumendis mõnele riigihangete seaduse paragrahvi

88 lõikes 2 ja paragrahvi 89 lõikes 2 nimetatud alusele kui pakkumuse tehnilisele kirjeldusele

vastavuse kriteeriumile, tuleb lugeda selliselt, et see on täiendatud märkega „või sellega

samaväärne“.

2.2. Iga viidet, mille hankija teeb käesolevas dokumendis ostuallikale, protsessile, kaubamärgile,

patendile, tüübile, päritolule või tootmisviisile, tuleb lugeda selliselt, et see on täiendatud

märkega „või sellega samaväärne“.

3. Hetkeolukorra ja vajaduse kirjeldus

Riigi IT Keskus pakub avalikule sektorile arvutitöökoha-, serveri alustaristu teenuseid ja mitmeid erilahendusi.

RIT pakub täna teenuseid enam kui 80 asutusele ja ligikaudu 9000 avaliku sektori kasutajale.

Praegu puudub Riigi IT Keskuse kliendi (avaliku sektori asutus) ja kasutaja (riigitöötaja) vaatest terviklik ja

kasutajasõbralik lahendus arvutitöökohaga seotud informatsiooni ja teenuste tarbimiseks. Oluline

informatsioon on hajali, keskkondi on palju ning kasutaja jaoks olulised töövood osaliselt puuduvad.

RIT portaali eesmärk on olla põhiline kontaktpunkt, mis võimaldab klientidel ja lõppkasutajatel juurdepääsu

Riigi IT Keskuse teenustele ja seotud teabele. RIT portaal koondab hajali paikneva RITi teenustega seotud

informatsiooni, pakkudes struktureeritud ja selget ülevaadet kasutaja jaoks olulistest andmetest. RIT portaal

saab olema integreeritud mitmete infosüsteemidega, et kuvada ülevaatlikult ja ajakohaselt informatsiooni ning

võimaldada kasutajatel teostada toiminguid läbi ühtse kasutajaliidese. RIT portaal tagab ühetaolise ja sujuva

kasutajakogemuse, parandab infokorraldust ning tõstab teenuste kättesaadavust ja kvaliteeti.

RIT portaali vajaduste kaardistamiseks on varasemalt läbi viidud kasutajakogemuse ja -liidese disain ja

analüüs ning loodud esmased disainivaated ja prototüübid. Need on aluseks antud hanke eseme tellimisel, kuid

ei ole lõplikud ning pakkuja peab olema valmis vastavalt hankija tellimusele tegema täiendavaid vaateid ja

muudatusi olemasolevates disainivaadetes.

3.1. RIT portaali kasutajad

Lk 2/8

RIT portaal saab olema suunatud peamiselt kahele erinevale profiilile: RITi teenuste lõppkasutajad ja RITi

klientasutuse esindajad.

RITi teenuste lõppkasutaja on avaliku sektori töötaja, kes töötab asutuses, mis on RITi arvutitöökohateenusega

liitunud. 2025. aasta alguse seisuga teenindab RIT ligikaudu 9000 lõppkasutajat ning lähiaastatel on ennustatav

kasutajate arvu kasv üle 27 000. Lõppkasutajate esmaseks kontaktpunktiks RITis on täna IT-abi, kas läbi

kirjalike pöördumiste või telefoni teel. Lõppkasutaja huvi on, et ta enda arvutitöökoha muredele, tellimustele

ja päringutele võimalikult kiirelt ja lihtsalt lahenduse leiaks ning ei kulutaks aega erinevate keskkondade ja

teadmusbaaside vahel liikumisele.

Klientasutuse esindaja on avaliku sektori töötaja, kes töötab asutuses, mis on RITi arvutitöökohateenusega

liitunud ning esindab avaliku sektori asutust RITiga suhtlusel. Klientasutuse esindajaid on üldjuhul sama palju

kui arvutitöökohateenusega liitunud asutusi, ehk 2025. aasta alguse seisuga ligikaudu 80. Lähiaastatel on

eeldatav klientasutuse arv üle 125, mis tähendab ka esindajate arvu kasvu. Klientasutuse esindajatega hoiavad

regulaarset suhtlust RITi kliendisuhete juhid. Klientasutuse esindaja huvi on saada ülevaade enda esindatavast

asutuseülesest teabest seoses RITiga (nt varade, pöördumiste, kasutajate, meiligruppide jne ülevaade), lisaks

näha ülevaated kokkulepetest RITiga (nt sõlmitud lepingud, tellitud teenused, eelarve täituvus jne).

4. Hanke eseme kirjeldus

Hanke esemeks on hankija vajadustele vastava RIT portaali arendus- ja hooldustööd. Arendustööna

käsitletakse arendusteenust, mida pakkuja osutab uue funktsionaalsuse loomiseks või tööde käigus loodud

olemasoleva funktsionaalsuse muutmiseks, mis on eelnevalt hankija ja pakkuja vahel kokku lepitud ja

tellimusega kinnitatud. Hooldustöö all mõistetakse teenust, mida pakkuja osutab infosüsteemi omaduste

säilitamiseks, parandamiseks või parendamiseks etteplaneeritavalt. Hooldustöö eesmärgiks on tagada

infosüsteemi, millele hooldustööd osutatakse, toimimine.

Pakkuja kohustus on teha järgnevad tööd:

4.1. Hankija poolt esitatud (või edasise arendamise käigus esitatava) lähteülesande täiendav

analüüsimine ja vastava lahenduse disainimine (tarkvaraarhitektuuri loomine ja oodatava

kasutajakogemuse ja -liidese kontseptsiooni väljapakkumine).

4.2. Disainitud lahenduste arendustööd.

4.3. Infosüsteemi liidestamine hankija teiste infosüsteemidega.

4.4. Ühekordsed täiendavad loodava infosüsteemiga seotud arendustööd hankija tellimisel.

4.5. Hooldustööd, milleks on hankija poolt teenuse saamiseks esitatud ja pakkujale laekunud

pöördumine või pakkuja poolt registreeritud juhtum, mille käigus kõrvaldatakse viga, tõrge või

arendatakse uus infosüsteemi funktsionaalsus.

Lk 3/8

4.6. Ettepanekute tegemine komponentide uuendamiseks vastavalt tootja väljalastud uuenduste

ilmumisele ja infosüsteemi iseärasustele. Pakkuja pädevus on erinevate komponentide

koosmõjust tingitud rikete ja tõrgete vältimine. Vajadusel teostab pakkuja arendustöid, mis on

tingitud tootjate poolt väljastatud uuendustest.

4.7. Infosüsteemi ja selle arendustööde dokumenteerimine ning dokumentatsiooni kaasajastamine.

4.8. Hankija nõustamine ja koolitamine infosüsteemi kasutamisel ja arendamisel.

4.9. Infosüsteemis esinevate tõrgete ja probleemide põhjuste väljaselgitamine ja nende

kõrvaldamine.

4.10. Infosüsteemi tehniline administreerimistugi lepinguperioodil koostöös RITi IT spetsialistidega.

4.11. Muud infosüsteemi loomiseks, kasutuselevõtmiseks, hooldamiseks ja arendamiseks vajalikud

tööd.

5. Nõuded arendustöödele, lähtekoodile ja kasutatavad tehnoloogiad

5.1. Arendustöid teostatakse vastavalt lisas 3 kirjeldatud Kodukorrale.

5.2. Kõik infosüsteemi arendustööde raames loodud tulemid peavad olema testitud etteantud

funktsionaalsuste täitmise kinnitamiseks ja kooskõlastatud RITi poolse kontaktisikuga.

5.3. Tellimuse aluseks on kirjalik pöördumine tööde teostamiseks, kas tellimuskirjana või tööde

halduskeskkonna (Jira) kaudu. Tellimusi esitab RITi poolne kontaktisik.

5.4. Arendused on loodud viisil, mis ei sunni hankijat hankima täiendavat tarkvara või selle

kasutusõigust, on platvormisõltumatud ning vabavaralised.

5.5. Pakutava lahenduse puhul peab olema võimalik kuluefektiivselt kasutada automaatset

skaleerimist nii horisontaalselt (uute ressursside lisamine) kui ka vertikaalselt (olemasolevate

ressursside suurendamine) vastavalt kasutajate hulgale.

5.6. Infosüsteemi erinevaid komponente/mooduleid peab olema võimalik paralleelselt arendada ja

vajadusel välja vahetada.

5.7. Uute moodulite lisamine peab olema võimalik ilma oluliste muudatuste vajaduseta juba

kasutuses olevates moodulites.

5.8. Valmivad komponendid peavad olema taaskasutatavad.

5.9. Arendustöid teostatakse lähtuvalt tarkvaraarenduse standarditest, tunnustatud reeglitest ja

headest tavadest.

5.10. Tööde käigus loodud lähtekood peab olema kirjutatud ja dokumenteeritud selliselt, et vajadusel

oleks hankija või kolmas isik võimeline aru saama infosüsteemi loogilisest ülesehitusest ning

jätkama lähtekoodi arendusega.

5.11. Tööde vastavust standarditele võivad hinnata vastava ala eksperdid.

5.12. Arendustöödel on kasutusel vähemalt järgmised keskkonnad (Tabel 1):

Keskkond Funktsioon Kasutajad Haldaja Märkused

Lk 4/8

Arendus-

keskkond

RIT portaali

arendamiseks

Pakkuja arendajad, pakkuja

testijad, vajadusel hankija

kasutajad.

Hankija Majutatakse hankija

süsteemides.

Testkeskkond Hankijapoolne

testimine,

automaat-testimine,

liideste testimine

Hankija testijad, pakkuja

vastavalt vajadusele ja

kokkulepetele

Hankija Majutatakse hankija

süsteemides. Pakkuja

poolsed tegevused

tuleb registreerida

tööde

halduskeskkonnas.

Toodangu-

keskkond

RIT portaali

eesmärki täitev

igapäevane

töökeskkond

Lõppkasutajad ja

klientasutuse esindajad.

Reeglina arendaja ligipääs

vajalik ei ole.

Hankija Majutatakse hankija

süsteemides.

Tabel 1. Ülevaade arendustöödel nõutud keskkondadest.

5.13. Test- ja toodangukeskkonda infosüsteemi uuenduse paigaldamiseks peab pakkuja seadistama

vajalikud automaatsed paigalduse töövood, mille tingimused peavad olema hankijaga koostöös

kokku lepitud. Töövoo esialgse seadistamise, muudatuste ja lepingu vältel käimas hoidmise eest

vastutab pakkuja.

5.13.1. Pakkuja peab hankijale üle andma dokumentatsiooni loodud töövoogude

kohta, mis on piisav selleks, et hankija saaks lepingu lõppedes halduse üle võtta.

5.14. Kogu teostatav töö ja üleantavad tulemid, versioonihaldus ja konfiguratsioonid, tuleb salvestada

hankija poolt määratud versioonihalduse (Git) projektina.

5.15. Infosüsteemi paigaldus automatiseeritakse pakkuja ja hankija koostöös ja lahenduse arhitektuur

kavandatakse selliselt, et see tagaks infosüsteemi tööaja 24/7.

5.16. Pakutav lahendus peab olema realiseeritud mikroteenustena ning kasutatav hankija Kubernetese

konteinerplatvormil ja allolevast failisüsteemist sõltuvusi ei tohi olla, kõik failid tuleb salvestada

S3-e.

5.17. Serveripoolne osa (back-end) peab olema teostatud kas Go Fiber raamistikus või kasutama Java

Spring Boot koos JOOQ-ga.

5.18. Kasutajaliides (front-end) peab olema arendatud kas React või Angular raamistikus.

5.19. Andmebaasina tuleb kasutada hankija relatsioonilist andmebaasi PostgreSQL.

5.20. Püsiva integratsiooni töövood lahendatakse GitLab-i abil.

5.21. Autentimise mehhanismiks kasutatakse Entra ID tehnoloogiat. SSO ja kasutaja õiguste gruppide

haldamise lahendusena kasutatakse KeyCloak-i.

5.22. Liidestuse ühe lahendusena kasutatakse OpenID Connect tehnoloogiat.

5.23. Mikroteenuste omavahelise suhtluse puhul tuleb kasutada asünkroonset liiklust ning

arhitektuuri tuleb lisada ka sobiv MQ.

5.24. Rakenduste sõltuvuste (maven, npm jne) allikana tuleb kasutada hankija sisest keskset

repositooriumi (Artifactory).

Lk 5/8

5.25. Lähtekoodi kvaliteedist ja tehnoloogilisest võlast ülevaate saamiseks kasutatakse hankija

platvormi SonarQube. Pakkujal on kohustus SonarQube-i poolt leitud lähtekoodi vead ja halvad

lõhnad (code smells) enne tulemi/commiti üleandmist parandada. Kui selgub, et tulemi

üleandmisel olid lähtekoodis vead ja halvad lõhnad parandamata, on hankijal õigus

tulemit/commiti mitte vastu võtta.

5.26. Pakkujal lasub kohustus teha teiste arendajate tulemitele koodiülevaatust (Code Review)

tagamaks lähtekoodi vastavuse koodistiili reeglitele.

5.27. Lähtekood peab olema pakkuja poolt piisavalt kommenteeritud, et hiljem oleks võimalik teha

edasiarendusi või parandusi.

5.28. Arendustööde tulemusel valmiva lähtekoodi hoidmiseks on hankija Git koodirepositoorium

(Gitlab). Pakkuja meeskonnaliikmetele luuakse hankija poolt ligipääs koodirepositooriumile

lähtekoodi, andmebaasimuudatuste ning muude tulemite või nende muudatuste üleandmiseks.

5.29. Tarkvara järjepidevaks integreerimiseks ja tarnimiseks (Continuous Integration, Continuous

Deployment CI/CD) kasutatakse Gitlab-i.

5.30. CI töövoogude loomine on arendaja ülesanne, sealhulgas järgida põhimõtet et konfiguratsioonid

teostatakse läbi keskkonnamuutujate.

5.31. Loodavad hanke tulemid antakse üle hankija koodirepositooriumi kaudu vastavalt hankija

juhistele. Arendustööde tulemite üleandmine (lähtekoodi tarne) toimub pideva integreerimise

(CI) teel või kokkulepitud sagedusega (nt iga arendustööde sprindi/etapi järel).

5.32. Kõik välised sõltuvused tuleb rakenduse ehitamisprotsessi käigus läbi skaneerida hankija

Artifactory Xray töövahendiga ja mitte kasutada kõrge ega ülikõrge kriitilisusega (CVE hinne

7.0 või kõrgem) turvanõrkuseid sisaldavaid teeke/komponente.

5.33. Arendamisel lisatakse commitide (lähtekoodi repositooriumisse lisamine) juurde Jira pileti nr,

mille alusel muudatus sisse viiakse ning lühisõnaline lühikirjeldus, mida muudatused

sisaldavad. Commit sõnumi alguses peab olema alati projekti nimi, mille raames commit

tehakse ja informatsioon, kes antud commiti teeb (isiku nimi).

5.34. Enne commiti peab kood/teostatud töö/tulem olema:

5.34.1. iseendaga kooskõlas (pole vastuolusid, katkiseid mooduleid, iseendaga

vastuolus funktsionaalsust);

5.34.2. üldharu/muu haru tulemiga kooskõlas (üldharus olemasolev pole peale

commiti katki);

5.34.3. SonarQube-i poolt leitud lähtekoodi vead ja halvad lõhnad (code smells)

parandatud (uut tehnoloogilist võlga tekitada ei tohi);

5.34.4. läbinud edukalt hankija kehtiva kvaliteedivärava (SonarQube-is Quality

Gate);

5.34.5. selgelt mõistetav ja hõlpsasti kasutatav. Selle tagamiseks peavad olema

olemas sisseehitatud testid, mis aitavad tuvastada, kas edasiste arenduste, commitide

Lk 6/8

või muude tegevuste järel on vastav funktsionaalsus endiselt töökorras või vajab

parandamist.

5.35. Tarnitav lepingu ese peab ühilduma hankija poolt nõutud tehnilise lahendusega (erisused on

lubatud hankija kontaktisiku kirjalikku taasesitamist võimaldavas vormis esitatud nõusolekuga),

sealhulgas:

5.35.1. järgima hankija poolt nõutud tehnilise lahenduse ideoloogiat süsteemsete

protseduuride osas ja infosüsteemi arhitektuurset lahendust ja kasutusloogikat;

5.35.2. taaste- ja varundusprotseduurid peavad olema ühilduvad hankija poolt

soovitud tehnilise lahendusega;

5.35.3. ei tohi põhjustada tööde käigus loodud olemasoleva infosüsteemi tervikluse

või muid toimimise häireid ega jõudluse langust.

5.36. Tööde teostamine ei tohi tekitada häireid hankija mistahes teiste liidestatud süsteemide või

teenuste talitluses, v.a juhul, kui see on hankija ja pakkuja poolt eelnevalt kokku lepitud.

5.37. Lepingu alusel teostatud tööde raames loodud tulemid peavad olema testitud etteantud

funktsionaalsuste täitmise kinnitamiseks ja vastama hankes kehtestatud nõuetele. Pakkuja peab

olema valmis looma integratsiooni ja unit teste vastavalt hankija nõuetele.

5.38. Pakkuja kohustub teostama koormusteste, et tagada infosüsteemi toimimine prognoositava

kasutajate arvu kasvu piirides. Koormustestide käigus tuleb hinnata süsteemi jõudlust,

töökindlust ja skaleeritavust, tagades, et see suudab toimida eeldatava kasutusmahu kasvades

ilma märgatava jõudluse languseta. Testimise metoodika ja mõõdikud tuleb kooskõlastada

hankijaga ning testitulemused esitada koos vastava aruandlusega.

5.39. Hankija jätab endale hankelepingu tingimuste piires õiguse ühepoolselt täiendada ja muuta

üldist töökorraldust, sh arendusnõudeid, teavitades pakkujat kirjalikult ette 1 (üks) kuu.

6. Nõuded hooldusteenusele

6.1. Pakkuja pakub hankijale RIT portaali hooldusteenust, et tagada infosüsteemi töö.

6.2. Hooldusteenuse sisu:

6.2.1. Telefoni või elektroonilisel teel või vajadusel hankija juures kohapeal antavad

konsultatsioonid infosüsteemi kasutamise ja toimimisega seotud küsimuste kohta.

6.2.2. Hoolduse käigus avastatud infosüsteemi vigadest teavitamine või arendust

vajavate tööde puhul arendusettepanekute tegemine hankijale tööde halduskeskkonna

kaudu.

6.2.3. Infosüsteemi uute versioonide tarnete koostamine, tarnete dokumenteerimine

vastavalt tarneteatistele ja paigaldamine ning paigalduslogide koostamine.

6.2.4. Logide analüüsimine.

6.2.5. Infosüsteemi versiooniuuenduste, paranduste ja turvapaikade paigaldamine ja

seadistamine ning vajadusel juhendite koostamine ja versiooniuuenduste

dokumenteerimine paigalduslogis.

Lk 7/8

6.2.6. Turvapaikade paigaldamine teostatakse mitte hiljem kui 1 (üks) nädal peale

turvapaikade väljastamist tootja poolt; turvapaikade väljastamise teavet jälgib

pakkuja.

6.2.7. Kõrge turvakriitilisusega vigade korral võib pakkuja ettepanekul katkestuste

arv olla suurem kui 1 (üks) kord kuus.

6.2.8. Konfiguratsioonimuudatuste sisseviimine vastavalt hankija vajadustele.

6.2.9. Hooldustööde teostamiseks tagab pakkuja valmisoleku ja omapoolse abi kuni

veaolukorra kõrvaldamiseni vastavalt rakenduse SLA eesmärkidele, vajadusel ka

väljakutse korras kohapeal.

6.2.10. Hankija tagab hooldustööde teostamiseks ligipääsu vajalikele keskkondadele

ja vajadusel omapoolse abi. Ligipääsu tehnilised tingimused jms täpsustatakse tööde

teostamise käigus.

6.2.11. Pakkuja peab hooldustööde osas arvestust ja esitab hooldustööde kohta

igakuiselt või kvartaalselt hooldusakti olenevalt kokkuleppest, mis sisaldab

minimaalselt teostatud hooldustööde ning pakkuja poolt veaparanduse ja/või

tellimuste alusel tehtud tööde (sh garantiiliste tööde) nimekirja (sh. tarneid ja

vastuvõetud töid) ning teostatud tööde mahtu (töötunnid).

6.2.12. Tellimuskirjaga või Jira pileti alusel tellitud töödele tuleb esitada

mahuhinnang.

7. Esimene tellimus

7.1. Lisas 2.3 on määratletud esimene arendustööde tellimus ning sealsete arendustööde teostamise

maksumuse pakkumus on üks riigihanke hindamiskriteeriume. Pärast raamlepingu jõustumist

sõlmitakse viivitamata hankeleping raamlepingu partneriga Lisa 2.3 alusel määratletud tööde

teostamiseks (hankemenetluses esitatud pakkumus on siduv).

8. Lisad

8.1. Lisa 2.1 - Mittefunktsionaalsed nõuded

8.2. Lisa 2.2 - Nõuded dokumentatsioonile

8.3. Lisa 2.3 - Esimese etapi arendustööd

8.4. Lisa 2.4 - RIT portaali visiooni kavand

Lisa 2.1

Riigihange „Veebipõhise info- ja teenindusportaali arendus- ja hooldustööd“ (290452)

Lisa 2.1 Mittefunktsionaalsed nõuded

Käesoleva riigihanke mittefunktsionaalsete nõuete koostamisel on võetud aluseks Tervise ja Heaolu

Infosüsteemide Keskuse (edaspidi TEHIK) poolt välja töötatud mittefunktsionaalsete nõuete dokument

("TEHIK mittefunktsionaalsed nõuded arendustele", 2024), mis on lisatud hanke alusdokumentide

hulka. Antud riigihanke mittefunktsionaalsed nõuded järgivad TEHIKu dokumendis väljatoodud, kuid

teatud nõuded on kohandatud vastavalt hankeeseme spetsiifilistele vajadustele.

Mittefunktsionaalsete nõuete vastuolu korral Lisas 2.1 „Mittefunktsionaalsed nõuded“ ja „TEHIK

mittefunktsionaalsed nõuded arendustele“ lähtutakse Lisas 2.1 „Mittefunktsionaalsed nõuded“ esitatud

nõuetest.

1. TEHIKu dokumendi kohandatud nõuded

Järgnevas tabelis on välja toodud TEHIKu dokumendis kirjeldatud nõuded, mida on kohandatud antud

riigihanke vajadustele vastavaks.

Nõude

nr

TEHIK-u nõue Kohandatud nõue Kohandatud seletused

1.5 Rakendus peab olema

kirjutatud

arvestades selle lahenduse

äriprotsesside

ja andmete E-ITS ja ISKE

turvaklassi

nõudeid.

Rakendus peab olema

kirjutatud arvestades selle

lahenduse äriprotsesside ja

andmete E-ITS väga suure

kaitsetarbe või ISO/IEC

27001 nõudeid.

TEHIKu dokumendi

selgitus pädeb

3.1 Asutusesiseseks

kasutamiseks mõeldud

rakenduse kasutajate

autoriseerimist peab saama

teha vastu TEHIKu keskset

autoriseerimisteenust.

Rakenduse kasutajate

autoriseerimist peab saama

teha vastu RITi keskset

autoriseerimisteenust.

Kasutajate ja rollide

hoiustamiseks kasutatakse

hankija Keycloak teenust.

Täpsem tehniline lahendus

leida koos RITi poolse

arhitektiga.

3.4 Kui andmebaasis olevate

andmete E-ITS tervikluse

(I ehk integrity)

turvaosaklass on S või VS,

siis tuleb kõik andmebaasi

kirjed/tabelid

versioneerida.

Kui andmebaasis olevate

andmete E-ITS tervikluse (I

ehk integrity) kaitsetarbe tase

on S või VS, siis tuleb kõik

andmebaasi kirjed/tabelid

versioneerida

TEHIKu dokumendi

selgitus pädeb

6.3 Rakendus peab pakkuma

monitooringu lehte, kus

leidub informatsioon

rakenduse funktsionaalsuse

toimimise kohta.

Rakendusel peab olema

masinloetav XML-

staatusleht, mille struktuur

vastab hankija poolt ette

antud XML struktuurile.

Hankija annab ette täpse

kirjelduse.

Lk 2/3

2. Kehtetuks tunnistatud nõuded

Järgnevas tabelis on välja toodud TEHIKu mittefunktsionaalsete nõuete dokumendis sisalduvad

nõuded, mis antud riigihanke kontekstis ei kehti.

Nõude nr Nõude sisu

1.3 Lahendus peab vastama Sotsiaalministeeriumi IT-profiilile

1.8 Allkirjastamisel tuleb kasutada Tellija SiGA/SiVa vahendusteenust.

1.15 Avalike e-teenuste loomisel peab arvestama valitsusasutusele kehtestatud visuaalse

identiteedi stiilijuhiseid.

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

1.19 Tegevusalade andmete sisestamisel, kuvamisel ja hoidmisel tuleb lähtuda Vabariigi

Valitsuse 10. jaanuari 2008. a määrusest nr 11 "Klassifikaatorite

süsteem" ja kasutada EMTAK infosüsteemis kehtivat klassifikaatorit.

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

sisse loginud.

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

kaasnevaid piiranguparameetreid.

3.16 Kui rakenduse tervikluse turvaosaklass on T3, peavad tõestusväärtust omavad andmed

olema kas ajatembeldatud, digiallkirjastatud või digitembeldatud ning

krüptoaheldatud.

3.17 Kui rakenduses on S3 salastatuse astmega andmeid, peavad need olema nii transpordi

ajal ja ka salvestatult alati krüpteeritult.

6.1 Rakendusel peab olema masinloetav tervise testleht (health check) JSON kujul.

6.2 Rakendusel peavad olema elususe ja tööks valmiduse otspunktid.

10.2 Lahendus kirjeldatakse RIHA määruse nõuete kohaselt.

3. Tehnoloogilise võla mõõtmine (SonarQube)

Kogu tarnitav kood peab läbima standardse SONAR analüüsi. RITis kasutatavad kvaliteedimõõdikud

ja nende lubatud väärtused:

 Coverage - mõõdik määrab mitu protsenti kogu lahenduse lähtekoodist on kaetud

automaattestidega. Alampiir on 75%;

 Duplicated Lines (%) - mõõdik määrab mitu protsenti lähtekoodi koodist võib olla

dubleeritud. Ülempiir on 3%;

 Maintainability Rating - mõõdik määrab mitu protsenti kogu rakendusele kulunud

ajast on tekitanud tehnilist võlga (Code Smell) koodi stiili ja standarditele vastavuse

osas. Lubatud maht on alla 5%-i (tase A);

Lk 3/3

 Reliability Rating - mõõdik näitab palju on koodis erinevaid vigu. Uues ja

refaktooritud koodis ei tohi olla ühtegi viga (tase A);

 Security Rating - mõõdik näitab palju on turvanõrkuseid rakenduses, mis on SonarQube

rakenduse poolt tuvastatud. Ei ole lubatud ühtegi turvanõrkust (tase A).

Nõuded infosüsteemi dokumentatsioonile

Nõuded infosüsteemi dokumentatsioonile Versioon: 1.0

Dokumendid peavad vastama vähemalt alljärgnevatele tingimustele:

Andmemudel  

Eeldus dokumendile: Teenuste/kasutuslugude dokumentatsioon

Otstarve: Kirjeldada andmeobjekte ja nendevahelisi seoseid

Sisu: Andmebaasi põhjal luua andmetabelite ja -objektide seosdiagramm.

Sihtgrupp: Tellija, peakasutajad, rakenduse administraatorid

Ajakava: enne esimese arendusetapi algust enne igat arendusetapi algust igakordsel tellijale testimisse andmisel

Kirjeldada andmemudelit kontseptuaalse mudelina

interaktioone/seoseid

jah jah

Kasutaja õiguste ja tegevuste vastavustabel 

Eeldus dokumendile:

Süsteemi üldine kirjeldus

Otstarve: Kirjeldada kasutaja rollide õigusi erinevates kasutuslugudes ja tegevustes

Sisu: CRUD maatriks

Sihtgrupp: Tellija äriprotsesse valdavad kontaktisikud, ärianalüütikud, süsteemianalüütikud, täitjast sõltumatud tarkvara hooldajad, arendajad ja edasiarendajad, testijad, arhitektid, projektijuhid.

Ajakava: enne esimese arendusetapi algust enne igat arendusetapi algust igakordsel tellijale testimisse andmisel

Nimetada kasutaja rollid jah

 Teenuste/kasutuslugude dokumentatsioon

Eeldus dokumendile:

Süsteemi üldine kirjeldus

Otstarve: Kirjeldab detailselt üleantavaid teenuseid/kasutuslugusid.

Sisu: Teenuste/kasutuslugude detailse kirjelduse sisuks on:

Tehnilised parameetrid; Veateated/Hoiatused; Teostatavad kontrollid; Funktsionaalsuse enda põhiprotsess ja mõned sagedamini esinevad alternatiivsed protsessid (vastavalt vajadusele); Üldine kirjeldus, kuidas ja kus kajastub antud teenus/kasutuslugu tervikprotsessis; Nõudeid ja reegleid toetavad (sisu mõistmisele kaasaaitavad) pildid, diagrammid, tabelid, loendid Andmevahetuse teenuste kirjeldus (andmete küsimine/vastuvõtmine, turvalisus, teenuse andmestik, klassifikaatorid, xml/xsd schema ) Protsesside UML vaated

Sihtgrupp: Tellija äriprotsesse valdavad kontaktisikud, ärianalüütikud, süsteemianalüütikud, täitjast sõltumatud tarkvara hooldajad, arendajad ja edasiarendajad, testijad, arhitektid, projektijuhid.

Ajakava: enne esimese arendusetapi algust enne igat arendusetapi algust igakordsel tellijale testimisse andmisel

Nimetada kasutuslood jah

 Arhitektuuridokument 

Eeldus dokumendil e:

Süsteemi üldine kirjeldus

Otstarve: Dokumendi eesmärgiks on kirjeldada loodava süsteemi üldist ehitust. Kirjeldatakse rakenduse loogilist struktuuri, näidates ära selle kihtideks jagunemise korda. Kirjeldatakse ka füüsilist arhitektuuri, antakse ülevaade kasutatavatest tehnoloogiatest ning vahenditest.

Sisu: Dokument peab rahuldama vähemalt alljärgnevaid sisunõudeid: 1. topoloogia, süsteemi füüsiline arhitektuur (süsteemi komponendid andmebaasiserver, rakendusserver, meiliserver jms) 2. Nõuded arhitektuurile (operatsioonisüsteem, andmebaasid, liidestused, rakendusserverid, raamistikud, teenused)

3. Nõuded käideldavusele (süsteemi soovituslikud näitajad komponentide kaupa, näiteks andmesidekiirused, kättesaadavus, andmemahud, protsessori kiirus, mälumaht, komponentide arv süsteemi osade kaupa, kettasüsteemi jõudlus jms)

4. liidesed teiste süsteemidega (x-tee, meilisüsteemid) ja sõltuvused teistest süsteemidest. Liideste kirjeldused/otstarve

5. süsteemi tehnilised (sh automaatsed) protsessid ehk töövoog – komponentide omavahelised suhtlusstsenaariumid ja koostoimimine (näiteks, mis komponent ja millal pöördub n teenuse poole) 6. kolmandate osapoolte poolt toodetud kasutatavad tarkvarad/riistvarad, mis on vajalikud süsteemi toimimiseks

Sihtgrupp: Arhitekt, administraator, turvaspetsialist

Ajakava: enne esimese arendusetapi algust enne igat arendusetapi algust igakordsel tellijale testimisse andmisel

Dokumendi esialgne versioon jah

Seadmete ja tarkvara kasutajakesksed juhendid

Eel dus dok um end ile:

Teenuste/kasutuslugude dokumentatsioon

Ots tarv e:

Teenuse funktsionaalsuse kasutamiseks ja kasutuslugude läbimiseks vajalikud juhised

Sis u:

Igale esitluskihile peab olema koostatud eraldi kasutusjuhend, mis kirjeldab vastava komponendi funktsionaalsuse kasutusvoo põhiselt. Kirjeldus tarkvara ja seadmete kasutamise üldisest protsessist, protsessi olulisemate sammude kirjeldus. Koostatakse projekti lähteanalüüsi aluseks võttes. Tarkvara kasutusjuhend on aluseks kasutajate koolitamisel. Kasutajajuhend kirjeldab kõiki kasutajate funktsionaalsusi koos tööprotsesside kirjeldusega ning ekraanipiltide vormis näidetega. Haldusliidese kasutusjuhend (peakasutaja ja rakenduse administraatori funktsionaalsus) peab olema eraldi tavakasutaja kasutusjuhendist.

Esitluskihi kasutusjuhendi minimaalne ülesehitus:

lühitutvustus üldine kirjeldus koos komponentidega autentimine (kui eksisteerib) komponentide detailne kirjeldus koos kõikide funktsionaalsustega Rollide kirjeldus ja õigused

Siht gru pp:

Tarkvara kasutajad,  peakasutaja, rakenduse administraator

Aja kav a:

enne esimese arendusetapi algust enne igat arendusetapi algust igakordsel tellijale testimisse andmisel

jah

 Paigalduse ja administreerimise juhend 

Eeldus dokumendil e:

Arhitektuuridokument Süsteemi üldine kirjeldus

Otstarve: Juhend on aluseks süsteemi administreerimisele

Sisu: Juhend peab rahuldama vähemalt alljärgnevaid sisunõudeid: 1. süsteemi parameetrite (seadistuste) kirjeldus ning nende muutmiste mõjud ja protseduurid. Konfiguratsioonifailide kirjeldus koos asukohtadega failisüsteemis; 2. logimise realisatsiooni kirjeldused (kuhu, mida, logide struktuur 3. rutiinsete hooldusprotseduuride kirjeldus (komponentide taaskäivituse vajadus parameetrite muutmisel); 4. paigaldamise protseduurid.

4.1 Nõuded rakenduse komponentidele

4.2 Rakenduse paigaldus (Vajalik tarkvara ja konfigureerimine, rakenduse pakkimine ja paigaldamine)

4.3 Andmete alglaadimine

4.4 Varundusskript

4.5 Monitooringu kirjeldus

Juhendis kirjeldatakse iga realiseeritud osa rakendamine koos spetsiifiliste seadistustega. Paigaldamise protseduurid peavad olema kirjutatud (deployment) selliselt (samm sammult), et süsteemiadministraator suudab rakenduse paigaldada ilma kõrvalise abita.

Sihtgrupp: Peakasutaja, projektijuht, süsteemiadministraator

Ajakava: enne esimese arendusetapi algust enne igat arendusetapi algust igakordsel tellijale testimisse andmisel

jah

 Lähtekood (sh andmebaasi struktuur)

Eeldus dokumendile: Arhitektuuridokument Teenuste/kasutuslugude dokumentatsioon Andmemudel Kasutaja õiguste ja tegevuste vastavustabel Prototüüp

Otstarve: Lähtekood on vajalik selleks et kompileerida rakendust, ning võimaldada tulevikus rakenduse muutmist.

Sisu: Lähtekood peab olema hästi struktureeritud, piisavalt dokumenteeritud ning võimalikult lihtne, et sellest saaksid aru ka teised arendajad. Lähtekood peab vastama MFNile Lähtekood peab olema pakendatud vastavalt versioonimisjuhendile. Rakenduste lähtekood peab olema piisavalt modulaarne, et seda saaks tulevikus lihtsasti täiendada ning muuta.

Ajakava: enne esimese arendusetapi algust enne igat arendusetapi algust igakordsel tellijale testimisse andmisel

Versioonihaldus tuleb teha Tellijakeskkonnas (nt Gitlab), sh ka jooksvaid commit’e

 Koormustestide dokumentatsioon 

Eeldus dokumendile: Teenuste/kasutuslugude dokumentatsioon

Prototüüp (ainult kasutajaliidesega rakenduse puhul) Arhitektuuridokument

Otstarve: Määrata kindlaks arendusetapil testitavad kasutuslood ja liidesed (sh välja tuua need, mille puhul rakendatakse koormusteste) tuues välja nende järjekorra.

Sisu: Järjestatud (võib olla ka paralleelne) nimekiri kasutuslugudest ja liidestest (vajadusel määrates nende ulatust) koos märkega, mis on koormustestiga tagatud ning millel on testandmed

Sihtgrupp: Tellijapoolne projektijuht, vastuvõtutestijad

Ajakava: enne esimese arendusetapi algust enne igat arendusetapi algust igakordsel tellijale testimisse andmisel

Nimetada kasutuslood, mille puhul rakendatakse koormusteste  jah

 Testimise tulemite dokumentatsioon

Eeldus dokume ndile:

Koormustestide dokumentatsioon

Otstarv e:

Anda tellijale ülevaade läbiviidud testimise tulemustest ning esitada soovitused testandmete ja dokumentatsiooni parendamiseks (ettevalmistus, paigaldus, kasutuslugude kirjeldus jne).

Sisu: Teostatud arenduste testimisel saadud informatsioon (näiteks testlood, testraport, testiplaan, testide kood jms). Dokumenteeritakse iga testimise eesmärgid (testimise maht ja ulatus), tegevused ja tulemused. Sisaldab jõudlus- ja mahutestide infot ning versiooni infot. Teste mitteläbinud testlugudele on lisatud parandused või ülesjäänud vead. MFNi vastavustabel

Sihtgru pp:

Arhitekt, süsteemiadministraator, turvaspetsialist

Ajakava: enne esimese arendusetapi algust enne igat arendusetapi algust igakordsel tellijale testimisse andmisel

jah

Automaattestimise tulemite dokumentatsioon

Eeldus dokumendile: Lähtekood (sh andmebaasi struktuur)

Otstarve: Anda tellijale ülevaade läbiviidud automaattestimise tulemustest.

Sisu: Ülevaade SonarQube’is (testide nimekiri, testide käivitamise tulemus, koodi kaetavus).

Sihtgrupp: Arhitekt, süsteemiadministraator, turvaspetsialist

Ajakava: enne esimese arendusetapi algust enne igat arendusetapi algust igakordsel tellijale testimisse andmisel

jah

Taasteplaani tegemise juhend 

Otstarve: Kirjeldada erisused, millega tuleb arvestada taasteplaani loomisel

Sisu: Taasteplaan peab rahuldama vähemalt alljärgnevaid sisunõudeid: 1. süsteemi halvamist võimaldavad riskid ja nende esinemise võimalikkus; 2. varundamisele kuuluvate komponentide ja asukohtade loetelu (nt rakenduse konfiguratsioonifailid rakendusserverist ja andmebaas jne), nende kirjeldused ja kasutuselevõtu protseduurid; 3. süsteemi komponentide asendusvõimalused, nende alternatiivkomponentide spetsifikatsioonid

Sihtgrupp: Arhitekt, süsteemiadministraator, turvaspetsialist, äri, tellijapoolne projektijuht

Ajakava: enne esimese arendusetapi algust enne igat arendusetapi algust igakordsel tellijale testimisse andmisel

jah

Üldised nõuded:

Üleantav dokument peab sisaldama sisseviidud muudatusi nii, et on väljatoodud muutunud ja lisandunud osa (võrreldes viimati üleantuga). 

Lisa 2.3

Riigihange „Veebipõhise info- ja teenindusportaali arendus- ja hooldustööd“ (290452)

Lisa 2.3 - Esimese etapi arendustööd

Hankija poolne ootus on, et esimese etapi arendustööd on lõpetatud ja tellija poolt vastu võetud hiljemalt kolm

(3) kuud peale RIT portaali projekti käivitamist (kick-off koosolekust). Pärast raamlepingu jõustumist

sõlmitakse viivitamata hankeleping raamlepingu partneriga esimese etapi arendustööde teostamiseks. Projekti

kick-off koosolek peab aset leidma ühe (1) kuu jooksul alates hankelepingu sõlmimisest poolte kokkuleppel,

võttes arvesse suvist puhkuste perioodi.

Esimese etapi arendustööde loetelu:

1. RIT portaalile mikroteenustel põhineva platvormi disain ja loomine.

1.1. Infosüsteemi disainimisel ja loomisel lähtutakse mikroteenuste põhimõtetest:

1.1.1. iga teenus keskendub ühele äriprobleemile;

1.1.2. teenused on minimaalse omavahelise sõltuvusega;

1.1.3. komponendid on võimalikult sõltumatud ja iseseisvalt hallatavad;

1.1.4. komponente on võimalik eraldi sisse ja välja lülitada;

1.1.5. komponentidel on lokaalsed seadistusfailid, millega on võimalik

komponendipõhist seadistust uuendada;

1.1.6. teenused on sõltumatult uuendatavad ja süsteemis rakendatavad;

1.1.7. teenused on kõrge käideldavusega ning lihtsasti testitavad.

1.2. Loodav lahendus peab olema konteineriseeritud ja allolevast failisüsteemist sõltuvusi ei tohi

olla, kõik failid tuleb salvestada S3-e.

1.3. Infosüsteem peab olema skaleeritav nii horisontaalselt (uute ressursside lisamine) kui ka

vertikaalselt (olemasolevate ressursside suurendamine).

1.4. Infosüsteem peab tagama kõrge töökindluse ja olema võimeline automaatselt taastuma

tõrgete korral.

1.5. Infosüsteemil peab olema kasutajaliides, mis , mis võimaldab vähemalt järgnevaid

toiminguid:

1.5.1. õiguste põhine alammoodulite ligipääs.

1.6. Infosüsteemil peab olema halduriliides, mis võimaldab vähemalt järgnevaid administratiivsed

toiminguid:

1.6.1. kasutajate ülevaade;

1.6.2. kasutajate õiguste haldus, mis peab olema eraldiseisev mikroteenus, mille

kaudu saab hankija Keycloakis hallata kasutaja õiguste gruppe, liidestus tuleb teha

kasutades Keycloaki API-t;

1.6.3. kasutajate rollide õiguste haldus RIT portaali siseselt;

1.6.4. logi jälgimine;

1.6.5. süsteemiüleste teavituste loomist ja haldamist.

1.6.5.1. Teavitused peavad olema kasutajatele nähtavad RIT portaalis.

Lk 2/3

1.6.5.2. Teavituste kuvamine peab olema kohandatav vastavalt kasutaja rollile

ja asutusele, et tagada asjakohasus ja relevantsus.

1.7. Kasutajate õiguste haldus peab olema paindlik ja võimaldama vajadusel integreerimist teiste

süsteemidega, et tagada sujuv ja täpne kasutajate haldus.

1.8. Infosüsteem peab toetama kasutajate õiguste dünaamilist muutmist vastavalt vajadusele.

1.9. Infosüsteem peab toetama erinevaid kasutajarolle ja privileege, sealhulgas tavakasutaja,

administraator ja klientasutuse esindaja.

1.10. Moodulite ligipääsu peab olema võimalik määrata õiguste kaudu vastavalt vajadusele.

2. RIT portaali integratsioon Confluence Cloud tarkvaraga, kus talletatakse RITi teenuste kasutajatele

mõeldud juhised ja abimaterjalid. Liidestuse tulemusena kuvatakse kasutajale RIT portaalis

teadmistebaas. Arendustööde aluseks on ideekavanditena valminud disainivaated ja prototüübid, mille

eesmärk on anda visuaalne suunis ning toetada pakkujat üldise kontseptsiooni ja kasutajakogemuse

mõistmisel. Disainivaated, mis käsitlevad teadmistebaasi integratsiooni asuvad Figmas ‘UI’ lehel,

‘Lõppkasutaja’ blokis ning vaadete pealkirjas on mainitud ‘Juhendid’. Disainivaated ei ole arendustele

siduv lähteülesanne. Pakkuja peab olema valmis tegema täiendavaid vaateid ja muudatusi

olemasolevates disainivaadetes vastavalt hankija tellimusele. Teadmistebaasi integratsiooni tulem:

2.1. Kasutajatele kuvatakse teadmistebaas, mis võtab oma andmete aluseks RITi poolt

defineeritud Confluence Cloud lehed.

2.2. Teadmistebaasist tuleb läbi API liidestuse võtta kogu andmestik ning seda kuvada loodava

RIT portaali kujundusele vastavalt. Kujunduses võib töö käigus tekkida lisavajadusi, mille

tulemusena tuleb disainivaateid kohendada.

2.3. Teadmistebaasi sisu peab olema RIT portaalis struktureeritud vastavalt Confluence Cloud

tarkvaras ettemääratud struktuurile, mis võib ajas muutuda.

2.4. Juhenditele ja abimaterjalidele tuleb määrata metaandmeteks asutuse info, mille järgi

kuvatakse juhendid sisse logitud kasutajatele vastavalt nende asutustele. See info asub

Confluence'i labelite all.

2.5. Kasutajal peab olema võimalus otsida teadmistebaasist juhendeid ja abimaterjale.

2.6. Otsingumootor peab võimaldama laiapõhist täistekstiotsingut. Otsing peab arvestama sisu

konteksti ja relevantsust ning tooma esile täpsed tulemused vastavalt otsingupäringule. Sisu

indekseerimine peab olema teostatud infosüsteemis.

2.7. Teadmistebaasi juhendid ja abimaterjalid peavad avanema RIT portaali samas veebilehitseja

aknas.

2.8. Kasutajal on võimalik tegevusnupu „Teavita veast dokumendis“ abil alustada pöördumist, et

teavitada juhendi täiendamise vajadusest.

2.9. Infosüsteem peab võimaldama hankijal paindlikult integreerida täiendavaid teadmistebaase

ja liidestusi teiste süsteemidega, et tagada kasutajatele vajalik ja terviklik juurdepääs teabele.

Lahendus ei tohi piirata võimalust uusi teadmistebaase lisada ega liidestusi tellida.

Lk 3/3

2.10. Hankijal peab olema võimalik piirata ligipääsu erinevatele juhenditele ja

abimaterjalidele samas teadmistebaasis.

2.11. Kasutajatele kuvatavas teadmistebaasis peab regulaarselt aset leidma automaatne

sünkroniseerimine, et tagada teadmistebaasi ajakohasus ja täpsus.

2.12. RITi IT spetsialistil peab olema võimalik vajaduse korral üksikut sünkroniseeritud

teadmistebaasi uuesti sünkroniseerida või seda süsteemist kustutada ja seejärel

sünkroniseerimist käivitada.

2.13. Teadmistebaasi kasutuse kohta peab olema võimalik koguda statistikat ning seda peab

olema võimalik RITi IT spetsialistil näha.

Infosüsteemi kasutajaliideste loomisel on hankija eelistus taaskasutada TEHIKu disainisüsteemi (edaspidi

TEDI) disaini- ja arenduskomponente (täpsem info https://tedi.tehik.ee/1ee8444b7/p/33df89-sissejuhatus).

Selle eesmärgiks on nii disaini- ja arendusprotsessi lihtsustamine ja kiirendamine kui ka visuaalse ühtsuse

suurendamine riiklikes digikeskkondades. Hankija ja pakkuja kokkleppel otsustatakse TEDI rakendamise

ulatus RIT portaali kasutajaliideste arendamisel.

Arendustööde teostamisel tuleb järgida tehnilises kirjelduses (Lisa 2) ja selle lisades seatud nõuded. Pakkuja

poolt proovitöö ülesandes 1 (Lisa 6) esitatud arhitektuuri visioon ja ettepanekud kasutuselevõtuks tuleb võtta

aluseks RIT portaali loomisel.

Lisa 2.4

Riigihange „Veebipõhise info- ja teenindusportaali arendus- ja hooldustööd“ (290452)

Lisa 2.4 - RIT portaali visiooni kavand

Dokumendi eesmärk on pakkuda terviklikku ülevaadet RIT portaali pikaajalisest suunast ja soovitud

funktsionaalsustest. Dokument kirjeldab prioriteetseid arendusvaldkondi ning tutvustab kasutuslugusid,

mis toetavad sihtrühmade vajadusi ja ootusi. See on aluseks RIT portaali arenduste planeerimisele.

RIT portaali eesmärgiks on olla põhiliseks kontaktpunktiks, mis võimaldab klientidel ja lõppkasutajatel

juurdepääsu Riigi IT Keskuse teenustele ja seotud teabele. Eesmärgi saavutamiseks on vaja luua

mikroteenustel põhinev, skaleeritav platvorm, mis kasutaja vaatest on ühtseks kontaktpunktiks ning

taustal koondab ja vahetab informatsiooni erinevate infosüsteemidega. Portaal on suunatud peamiselt

kahele erinevale profiilile, RITi arvutikohateenuse lõppkasutaja (riigitöötaja) ja klientasutus (avaliku

sektori asutus), mistõttu peab portaalil olema ka erinevad vaated ja funktsionaalsused vastavalt

profiilile.

RIT portaali vajaduste kaardistamisel selgunud olulisemad funktsionaalsused on kuvatud Joonis 1

pildil.

Joonis 1. RIT portaali soovitud funktsionaalsuste ülevaade lõppkasutaja ja klientasutuse vaatest.

Näited potentsiaalsetest liidestustest RIT portaali platvormiga:

 Keycloak

 Confluence Cloud

 Bürokratt

 OpenText™ Service Management (SMAX)

Lk 2/4

 VaRe – RITi varade halduse infosüsteem

 Kasutaja- ja juurdepääsuhalduse (IAM) süsteem

 Sympa – meililistide halduse tarkvara

 Power BI – andmete visualiseerimise tarkvara

Joonisel 1. olev funktsionaalsuste nimekiri on esialgne visioon ning nende reaalne tellimine sõltub

tegelikust vajadustest, tööde tellimise ajal olevatest prioriteetidest, eelarve võimalustest jne.

Funktsionaalsuste detailsemalt lahti mõtestamiseks ning arendustööde aluseks on kirjeldatud

kasutuslood nii lõppkasutaja kui klientasutuse esindaja vaatest. Järgnev kasutuslugude nimekiri on

näitlik, andmaks ülevaate võimalikest arendusvajadustest. Täpsed arendustellimused lepitakse kokku

töö käigus vastavalt hankija vajadustele.

1.1. Kasutuslood lõppkasutaja vaatest:

1.1.1. Kasutaja soovib portaali ligi pääseda võimalikult lihtsalt läbi enda arvutitöökoha

kasutades ühekordse sisselogimise autentimise süsteemi (SSO). Peale sisselogimist valib

kasutaja rolli ja konto, millega soovitakse toiminguid teostada. Peale portaali sisenemist

kuvatakse kasutajale lehe sisu.

1.1.1.1. Konto valik kuvatakse kasutajale juhul kui tal on mitu kontot.

1.1.1.2. Rolli valik kuvatakse kasutajale juhul kui talle on määratud mitu rolli (nt.

tavakasutaja ja klientasutuse esindaja)

1.1.2. Kasutaja saab vaadata enda kontaktandmeid (amet, telefon, email, kontori asukoht,

ruum).

1.1.3. Kasutaja saab vaadata enda meiligruppide infot (kuulun meiligruppi andmed,

hallatavate meiligruppide andmed).

1.1.4. Kasutaja saab vaadata enda seadmete infot (arvuti ID, kasutajanimi, võrguliidesed,

viimane sisselogimise kuupäev). Lisaks kuvatakse kasutajale tema kasutusel olevat vara (vara

tüüp, vara liik, mudel, seeria nr, kasutuse lõpp) ning litsentse.

1.1.5. Kasutaja saab vaadata enda konto andmestikku (konto kasutusala, konto loomise

kuupäev, konto kehtivusaeg, asutus, struktuuri üksus, otsene juht).

1.1.6. Kasutaja soovib vaadata temale suunatud teavitusi. Avalehel kasutaja nimega samal

real kuvatakse teavitusi tähistav ikoon ning tekst teavitused. Avades akordioni kuvatakse

kasutajale teavituste plokk, kus kuvatakse kõik asjakohased teavitused. Uued teavitused on

tähistatud ning samuti on kuvatud uute sõnumite arv.

1.1.7. Kasutaja soovib otsida juhendit, mille sisu ta vaadata soovib. Kasutaja sisestab

otsinguväljale märksõna. Süsteem kuvab automaatseid vasteid (autocomplete), lisaks on kuvatud

tegevusnupp „Otsingu tulemused“. Otsitav märksõna on automaatsete vastete kuvamisel

Lk 3/4

markeeritud värviga. Valiku tegemise järel teostab andmebaas filtreerimise valitud

otsingukriteeriumite alusel ning kuvab kasutajale otsingutulemused.

1.1.8. Kasutaja soovib leida temale sobivat juhendit, selleks on tal võimalik valida

meelepärane teema ning näha antud teema alamteemasid. Alamteemade sisu ehk juhendite

loetelu kuvatakse kujul pealkiri ja lühikirjeldus. Vajutades konkreetsele juhendile, avaneb

parempoolses ekraaniosas juhend. Kasutajal on võimalik tegevusnupu „Teavita veast

dokumendis“ abil alustada pöördumist, et teavitada juhendi täiendamise vajadusest.

1.1.9. Kasutaja saab vaadata meiligruppide nimekirju, mis on jaotatud kahte tabelisse –

hallatavad grupid ja grupid, milles ollakse liige. Iga meiligrupi kohta kuvatakse meiligrupi nimi,

omanik, loomise kuupäev ja roll, avades akordioni kuvatakse veel täiendavalt meiligrupi

meiliaadress, lühikirjeldus, viimati saadetud meili kuupäev, viimati vaadatud meili kuupäev ning

kokku saadetud meilide arvu. Olles meiligrupi haldaja on võimalik antud akordionivaatest

suunduda meiligruppi haldama. Meiligruppide nimekirjavaatelt on võimalik alustada uue

meiligrupi loomist.

1.2. Kasutuslood klientasutuse esindaja vaatest:

1.2.1. Kasutaja soovib vahetada rolli, et näha enda esindatava asutuse andmeid. Rolli

vahetamise alustamine on võimalik avalehel enda nime real olevalt ikoonilt või ekraani paremalt

ülevalt nurgast enda nimele vajutades. Vajutades enda nimele, siis kuvatakse rollid, mille vahel

on võimalik valida. Vajutades soovitud rollil vahetatakse kasutajal profiil.

1.2.2. Kasutaja saab vaadata enda asutuse kohta käivat varade infot. Esmalt kuvatakse

kasutajale varade koondinfo – arvutite koguarv, kuvarite koguarv, printerite koguarv,

videokonverentsi seadmete koguarv. Seejärel on kasutajal võimalik tutvuda detailsete varade

tabelitega ehk vaadata kõiki varasid, ühisvarasid ja litsentse. Tabelist õige info leidmiseks on

kasutajal võimalik kasutada filtreid, vaikimisi on kuvatud 3 olulisemat filtrit kuid tegevusnupp

„Ava kõik filtrid“ esitab kõik filtrid. Peale nupule „Rakenda filtrid“ vajutamist teostab süsteem

päringu ning kuvab kasutajale soovitud andmed. Tabelit on kasutajal võimalik alla laadida

tegevusnupu „Laadi tabel alla“ abi.

1.2.3. Kasutaja saab vaadata enda asutuse kasutajate kohta käivat infot. Õige kasutaja

leidmiseks on võimalik kasutada otsingut. Kasutajate info kuvatakse tabelis, kus iga kasutaja

kohta kuvatakse tema nimi, vara tüüp, asutus, asukoht, ametikoht. Avades kasutaja rea

(akordioni) on võimalik näha täiendavat infot- kasutaja õigusgrupid, meiligrupid ning tema

kasutuses olevate varade infot tabelis. Tabelit on kasutajal võimalik alla laadida tegevusnupu

„Laadi tabel alla“ abi.

1.2.4. Kasutaja soovib vaadata aktiivseid teenuseid ning samas on võimalik vaadata ka

tellitavaid teenuseid. Teenuste kohta kuvatakse teenuse nimi, vastutaja, staatus, eeldatav

rakendusaeg. Akordioni avades näeb täiendavalt teenuse kirjeldust ning aktiveerimise kuupäeva,

samuti antud teenuse kohta käivaid juhendeid ning nende lühikirjeldust.

Lisa 3

Riigihange „Veebipõhise info- ja teenindusportaali arendus- ja hooldustööd“ (290452)

Lisa 3 - Kodukord

1. Eesmärk

1.1. Kodukorra eesmärgiks on selgelt välja tuua Lepingu alusel teostatavad tegevused, tegevuste

teostamiste vastutajad, tegevuste tagajärjel valmivad tulemid, samuti tulemite valmimise

eelduseks oleva Täitja ja Tellija omavahelise suhtluse ning tagasiside edastamise kord.

1.2. Antud dokumendis kasutatakse mõisteid vastavalt raamlepingus sätestatud tähendustele.

2. Suhtlemist ja Tööde elluviimist toetavad keskkonnad ja vahendid

2.1. Teated

2.1.1. Kõik ettepanekud, muudatused, nõuded, avaldused, nõusolekud jm Lepingust tulenevad

õiguslikku tähendust omavad ametlikud teated tuleb esitada teisele Poolele vähemalt

kirjalikku taasesitamist võimaldavas vormis (e-post, tööde halduskeskkond), kui Lepingus

ei ole ette nähtud teisiti.

2.1.2. Teade loetakse kätte toimetatuks pärast seda, kui see on edastatud Lepingus toodud

kontaktaadressile või aadressile, millest Pool on teist Poolt viimati teavitanud.

2.1.3. Teade loetakse teisele Poolele kätte toimetatuks vastuse või kättesaamist kinnitava teate

saamisel saajalt, kuid mitte hiljem kui järgmisel tööpäeval pärast teate saatmist.

2.2. Suhtluskanalid

2.2.1. MS Teams – Arendusmeeskonna igapäevane suhtlusvahend, mida kasutatakse

kiireloomuliseks ja operatiivseks suhtluseks. Teamsi või telefoni kaudu kokku lepitud

otsused tuleb kinnituseks fikseerida kirjalikku taasesitamist võimaldavas vormis (nt e-

kirjas, koosoleku protokollis, tööde halduskeskkonnas).

2.2.2. E-kiri – Arendusmeeskonna ametlik suhtluskanal, v.a kui infot tuleb vastavalt kodukorrale

edastada tööde halduskeskkonna või dokumendihalduskeskkonna kaudu). Kui e-kirjale

oodatakse vastust, tuleb see kirjas üheselt määratleda. Vastust eeldavale e-kirjale tuleb

vastata hiljemalt järgneva tööpäeva jooksul. Kui e-kirjale ei ole võimalik anda selle aja

jooksul sisulist vastust, tuleb hiljemalt järgneva tööpäeva jooksul saata sisulise vastuse

andmise aeg.

2.2.3. Koosolek – Koosoleku kokkukutsumisel esitatakse koosoleku päevakord ja eesmärk.

Korralised koosolekud võib poolte kokkuleppel tühistada (hiljemalt samal päeval 2-tunnise

etteteatamise ajaga). Muude koosolekute kutsed tuleb esitada vähemalt 2 (kaks) tööpäeva

enne koosoleku toimumist. Koosoleku korraldaja koostab koosoleku või muu kohtumise

toimumise järel protokolli, kus protokollitakse vastu võetud otsused. Protokoll saadetakse

e-kirjaga koosolekul osalenutele teadmiseks/vajadusel kinnitamiseks.

Lk 2/4

2.2.4. Telefon – Kasutatakse operatiivse ja olulise informatsiooni edastamiseks, samuti

kriisisituatsioonides. Telefonikõnele mitte vastates tuleb tagasi helistada esimesel

võimalusel, aga mitte hiljem kui järgmise tööpäeva lõpus. Olulistel juhtudel (näiteks

arendustööde juurutusfaasis) peavad mõlema poole esindajad olema telefoni teel

kättesaadavad ka pärast ametlikku tööpäeva lõppu. Valmisolek lepitakse eraldi kokku.

2.2.5. Pooled säilitavad Lepingu täitmisega seotud e-kirjad, Teamsi ja/või muudes

sõnumivahetuskeskkondades toimunud vestlused Lepingu kehtivuse perioodil.

2.3. Tööde haldus ja dokumenteerimine

2.3.1. Kogu arendusprotsessi projektijuhtimine, tööde korraldamine, dokumenteerimine,

tööülesannete määramine, vastuvõtmine ja teostamine ning suhtlus toimub Tellija määratud

töö- ja koodihalduse keskkondades. Tellija tagab Täitjale vajaliku ligipääsu nendesse

keskkondadesse Lepingu kestvuse perioodil.

2.3.2. Tööde halduskeskkonnaks on Tellija Atlassian JIRA Software, mida kasutatakse

arendustööde ning vigade ja probleemide registreerimiseks tööülesannetena, nende

hindamiseks ning tööülesannete täitmise jälgimiseks ja töötundide registreerimiseks.

2.3.3. Tööde halduskeskkonnas antud ülesandeid käsitletakse hankelepingutena. Alates 20 000

eurot (ilma käibemaksuta) maksvate Tööde tellimisel vormistatakse kirjalik hankeleping

(raamlepingu lisa 5).

2.3.4. Tööde halduskeskkonnas fikseeritakse Töö kohta nimi, kirjeldus, maht tundides, teostamise

logi, teostajad, prioriteetsus, lõpptähtaeg ning tööd kirjeldavad failid ja spetsifikatsioonid.

2.3.5. Enne Täitja poolt Töö mahule hinnangu andmist valmib detailne ülesande püstitus (analüüs

või detailne kirjeldus). Ülesande püstituse vastavust soovidele kinnitab Tellija poolne

kontaktisik.

2.3.6. Tellija annab mõistliku aja pakkumuse esitamiseks, arvestades tellitavate Tööde keerukust

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

tellimuses esitatud nõudeid.

2.3.7. Täitja hindab võimalusel tellimuse alusel Tööde mahtu ja esitab tellimuses määratud

tähtajaks pakkumuse töö teostamiseks ja/või vajadusel muud tellimuses nõutud andmed.

2.3.8. Tööde halduskeskkonnas fikseeritud Töö maht peab sisaldama kogu selle Töö täitmiseks

vajalikku kulu.

2.3.9. Kui pakkumus ei vasta tellimuse tingimustele või ei ole muul põhjusel vastuvõetav, lükkab

Tellija pakkumuse tagasi.

2.3.10. Tellijal on õigus esitatud pakkumus tagasi lükata kui:

2.3.10.1. pakkumus ei vasta tingimustele;

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

2.3.10.3. ületab eeldatavat maksumust.

Lk 3/4

2.3.11. Pooled võivad pidada tellimuse või pakkumuse muutmiseks või kohandamiseks

läbirääkimisi, et muuta pakkumus tellimusele vastavaks või tellimuse tingimused

pakkumusele sobivaks.

2.3.12. Iga Töö peab enne konkreetse Töö algust saama Tellijapoolse kontaktisiku heakskiidu.

2.3.13. Muutunud prioriteetide korral korrigeeritakse Tellija ja Täitja koostöös ajagraafikut. Täitja

kaasab tööde teostamisse täiendavaid ressursse, kui tähtaegade korrigeerimine on võimatu.

2.3.14. Töö mahtu muutvate täiendavate nõuete ilmnemisel täpsustatakse tööde halduskeskkonnas

Töö, sellega seonduvad dokumendid ning antakse Täitja poolt Tööle uus mahuhinnang.

Enne Töö täitmise jätkamist peab Tellija poolne kontaktisik muudatused heaks kiitma.

2.3.15. Tööde halduskeskkonda, mida Täitja hoiab jooksvalt aktuaalsena, võivad Töid sisestada nii

Täitja kui ka Tellija.

2.3.16. Dokumendihalduskeskkonnaks on Tellija Atlassian Confluence ning selle keskkonna

kasutamine on Täitjale kohustuslik dokumentatsiooni koostamiseks, täiendamiseks,

muutmiseks. Dokumenteerimine toimub vastavalt Tellija juhistele ja hanke Lisale 2.2

„Nõuded dokumentatsioonile“. Dokumentatsioon koostatakse eesti keeles, kui ei ole kokku

lepitud teisiti. Täitja tagab koostatud teksti nii keelelise kui ka vormilise korrektsuse ning

hea keelekasutuse.

3. Tööde teostamine

3.1. Tööde teostamise metoodika lepitakse kokku projekti esimesel kohtumisel poolte kokkuleppel.

3.2. Tellija eelistab kasutada arendusmetoodikat, kus arendustööd ja nende ülevaatamine toimuvad

kahenädalaste tsüklitena. Selline lähenemine võimaldab arendustööd jagada osadeks ning

fokusseerida kindlale lahenduse osale.

3.3. Vähemalt üks töökoosolek toimub igal nädalal, kus täitja tutvustab teostatud töid ja lepitakse

kokku järgmise perioodi töödes.

3.4. Lõplikud töö tegemise põhimõtted fikseeritakse poolte kokkuleppel kirjalikult taasesitamist

võimaldavas vormis dokumendihalduskeskkonnas, e-kirjas või eraldi dokumendiga.

3.5. Tööde teostamise töökeeleks on eesti keel. Täitja ning Tellija esindajad suhtlevad omavahel

eesti keeles. Vajadusel tagab Täitja omal kulul alalise tõlke olemasolu suuliseks ja kirjalikuks

suhtlemiseks vastava meeskonnaliikme ja Tellija vahel. Tõlk peab olema kompetentne tehnilise

teksti tõlkimisel.

3.6. Täiendavad nõuded Tööde teostamisele (sh kasutatavad tehnoloogiad) on kirjeldatud Lisa 2

Tehnilises kirjelduses.

Lisa 4

Riigihange „Veebipõhise info- ja teenindusportaali arendus- ja hooldustööd“ (290452)

Lisa 4 - Nõuded pakkuja meeskonnale

1. Pakkuja peab esitama isikuliselt meeskonna liikmed (minimaalselt 5 liiget), kes täidavad järgmisi rolle:

Isiku ees- ja perekonnanimi Isiku sünniaeg/isikukood Isiku roll lepingu täitmisel

Projektijuht

Tarkvaraarhitekt

Analüütik

Arendaja

Arendaja

Testija

UX-UI disainer

2. Pakkuja meeskonnal peavad kogumis olema kaetud CV vormil (punktis 8.5.) märgitud kogemuse nõuded. Iga meeskonnaliige üksikult peab omama

vähemalt ühte nõutud kogemust.

3. Üks isik võib täita maksimaalselt 2 (kahte) erinevat rolli, näiteks analüütik-testija, kuid sellisel juhul peab antud isik vastama punktis 2 esitatud nõuetele

üksiku rolli täitmiseks ning peab olema tagatud meeskonna nõutav minimaalne suurus (5 liiget).

4. Pakkuja peab arvestama, et hankijal võib olla vajadus meeskonda suurendada, et riigihankes püstitatud eesmärgid täita.

5. Pakkumuses esitatud meeskonnaliikme saab lepingu käigus hankija eelneval nõusolekul vahetada uue meeskonnaliikme vastu kui pakkuja meeskond

tervikuna katab CV vormil märgitud nõutud kogemused. Meeskonnaliikme asendamise taotluse esitamise ajaks peab isik nõutud tingimustele vastama.

6. Hankija küsib meeskonnaliikme sünniaega või isikukoodi, et tuvastada hiljem isikusamasus ning välistamaks nimekaimude segi ajamist.

7. Meeskonnaliikmete rollid ja vastutus

Lk 2/7

7.1. Projektijuht, kes koostab ja jälgib projektiplaani (sh ajakava, riskid), juhib projektimeeskonna igapäevatööd, korraldab tööde üleandmise ja

arveldamise, planeerib tööde üleandmise hankijale ning veendub enne üleandmist nende vastavuses hankija soovidele. Samuti koordineerib teostatud

töödele nõuetekohase dokumentatsiooni teostamise, korraldab infovahetuse ja osaleb projektimeeskonna koosolekutel. Projektijuht on hankijale

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

7.2. Arhitekt, kelle üheks ülesandeks on koostada plaan, milliseid tarkvaralisi lahendusi, platvorme või muid tehnoloogilisi abivahendeid arendusmeeskond

RIT portaali arendamisel kasutab. Arhitekt vastutab lahenduste tervikuna toimimise ning valitud arendusvahendite ning platvormide otstarbeka

kasutamise eest. Arhitekti ülesanne on tagada loodud arhitektuuri jätkusuutlikkus (kokkuleppel hankijaga) pidevalt suunates arendusmeeskonna aega

arhitektuuri parendamisse ning tehnilise võla vähendamisse. Arhitekt vastutab, et arendustegevuse keerukus muutuks ajas võimalikult aeglaselt ja jääks

hoomatavaks.

7.3. Analüütik, kelle peamised ülesanded on RIT portaali ärivajaduste, äriprotsesside analüüs, tehniline analüüs, arendusteks vajalike protsesside

kirjeldamine, äriarenduseks vajaliku dokumentatsiooni loomine ja haldamine. Lisaks on analüütiku ülesandeks koostada planeeritava infosüsteemi

dokumentatsioon, sh detailne dokumentatsioon kõikide funktsionaalsuste ootuspärasest ja korrektsest toimimisest, kasutuslood, ning funktsionaalsed

ning mittefunktsionaalsed nõuded. Analüütikud koostavad ka arenduspiletid nii taustasüsteemide kui ka esitluskihi arendajatele.

7.4. Arendajad, kes teostavad pakkuja poolt arendus- ja hooldustöid ning vastavalt kokkuleppele pakub hankijale tööde ettevalmistamisel ja/või teostamise

järgselt konsultatsioone ning koolitusi. Meeskonnas peab olema nii front-end kui back-end oskusega arendaja, et teostada süsteemide esitluskihi ja

taustasüsteemide arendused. Arendaja vastutab arenduste teostamise kvaliteedi eest, sh tegeleb ilmnevate vigade parandamisega ning vajadusel koostab

tehnilist dokumentatsiooni.

7.5. Testija, kes teostab tehtud töödele testimisi, koostab testimistega seonduva dokumentatsiooni ning vastavalt kokkuleppele pakub hankijale tööde

ettevalmistamisel ja/või teostamise järgselt konsultatsioone ning koolitusi. Testija ülesandeks on tagada arendatud tarkvaralahenduste nõuetekohane

toimimine läbi arenduse piisava testimise enne lahenduste kasutajale kättesaadavaks tegemist.

7.6. UX-UI disainer, kelle peamised ülesanded on kavandada ning illustreerida uute funktsionaalsuste või protsesside toimimist kasutajasõbralikul viisil.

Samuti olemasolevate funktsionaalsuste ja protsesside kasutajasõbralikkuse tõstmine ja parendusettepanekute tegemine. Lisaks luua koostatud

lähteülesandele vastavalt kasutajaliidese disain, vajadusel ka uusi komponente, mis on kooskõlas vastava projekti stiilinõuetega. Samuti hoida ning

Lk 3/7

parendada stiilinõuetes sisalduvaid komponente. UX disaini ja UI disaini valideerimine ja testimine kasutajatega, muudatuste sisseviimine vastavalt

testi tulemustele.

8. Meeskonnaliikmete ühine CV vorm

8.1. CV-s peab nähtuma kõikide hankija seatud nõuete täitmine. Hankija kontrollib nõude täitmist esitatud andmete alusel. CV peab olema esitatud eesti

keeles. Meeskond tunnistatakse vastavaks, kui kõik CV vormil esitatud nõutud kogemused on meeskonnaliikmete poolt kaetud.

8.2. Töökogemus eeldab, et tegemist on tööandja heaks töötamisega töösuhtes või tellija heaks töötamisega projektis. Kui tingimuses ei ole nõutud

töökogemust projektis, võib viidata ka töösuhtele. Täiendkoolituse või koolitöö raames saadud kogemus ei ole arvesse võetav. Samuti ei arvestata

töökogemusena vabakutselisena tegutsemist, v.a kui selle perioodi osas on viidatud konkreetsetele projektidele, millel on tellijaks kolmas isik.

8.3. Töökogemuse andmed tuleb esitada vähemalt kalendrikuude kestuse alusel, näitamaks ära nõutud kogemusele vastav periood (nt osalemine projektis

X kestusega 12.2020 – 01.2023).

8.4. „Projekt“ peab olema teostatud kolmanda isiku ehk pakkujast eraldiseisva välise tellija jaoks ning hankija ei käsitle selle dokumendi tähenduses

„projektina“ tööandja enda tarbeks või majasisese tellimuse alusel teostatud töid. Selliseid töid aktsepteerib hankija töökogemusena, kui tingimuses ei

ole nõutud projektile viitamist.

8.4.1. Projektide andmete esitamisel tuleb iga projekti kohta esitada vähemalt: projekti nimi ja sisu kirjeldus, projekti algus- ja lõppaeg kalendrikuu

täpsusega, projekti tellinud asutus ja tellija kontaktisik ning riigihanke korral märkida riigihanke number.

8.4.2. Samaaegselt väldanud projektide alusel omandatud töökogemust ei summeerita.

8.4.3. Viidatud projektid peavad olema hanke algamise ajaks nõutud kogemuse mahus täidetud ja tellija poolt vastu võetud.

8.4.4. Hankijal on õigus pöörduda projekti tellija poole esitatud andmete kontrollimiseks.

8.4.5. Projektiks ei loeta (varasemat) töösuhet.

8.4.6. Hankija ei aktsepteeri tingimuste täitmiseks „konfidentsiaalseid“ projekte, mille osas pakkujal ei ole võimalik esitada projekti andmeid tingimuses

nõutu kohta ja mille osas ei ole võimalik kolmandal isikul tellijana anda kinnitust projekti nõuetekohase täitmise kohta.

8.4.7. Töökogemusele viidatav projekt peab olema teostatud viimase 7 (seitsme) aasta jooksul, arvestades käesoleva riigihanke hanketeate avaldamise

kuupäeva.

Lk 4/7

8.4.8. Iga loetelus toodud projekt eraldi ei pea sisaldama andmeid kopeerituna, piisab viitest varasemalt samas dokumendis esitatud projekti

informatsioonile.

8.5. Meeskonna ühine CV tuleb esitada järgmisel vormil, täites kõik nõutud väljad:

Jrk Nõuded Kes vastab esitatud nõudele

(isiku nimi)

Täpsustus selle kohta kus/kuidas

on nõue täidetud.

Kas projekti nimi ja sisu

kirjeldus (sh kasutatud

tehnoloogiad ja tööülesanded

projektis, välja tuua ka

infosüsteem, millega töötamisel

kogemus omandati) või viide

töösuhtele (tööandja nimi,

töökogemuse kestuse periood ja

tööülesannete lühikirjeldus)

Projekti algus- ja

lõppaeg kalendrikuu

täpsusega. Riigihanke

korral lisada riigihanke

viitenumber.

Projekt peab olema

teostatud viimase 7

(seitsme) aasta jooksul,

arvestades käesoleva

riigihanke hanketeate

avaldamise kuupäeva.

Projektidele viitamisel

märkida projekti

tellinud asutus, tellija

kontaktisik,

kontaktandmed (e-

mail)

1. Veebipõhise sh

autoriseerimist nõudva

rakenduse arendamise

kogemus projektis

Sisestada selle

meeskonnaliikme nimi, kes

vastab nimetatud nõudele

Projekti nimi ja sisu kirjeldus

Sisestada projekti

periood. Riigihanke

korral lisada viitenumber.

Sisesta projekti tellinud

asutus ning tellija

kontaktisik koos

kontaktandmetega.

2. PostgreSQL andmebaasiga

töötamise kogemus

projektis

Sisestada selle

meeskonnaliikme nimi, kes

vastab nimetatud nõudele

Projekti nimi ja sisu kirjeldus

Sisestada projekti

periood. Riigihanke

korral lisada viitenumber.

Sisesta projekti tellinud

asutus ning tellija

kontaktisik koos

kontaktandmetega.

3. Kogemus projektis pideva

integratsiooni (CI-

continuous integration)

põhimõtete rakendamisega

Sisestada selle

meeskonnaliikme nimi, kes

vastab nimetatud nõudele

Projekti nimi ja sisu kirjeldus

Sisestada projekti

periood. Riigihanke

korral lisada viitenumber.

Sisesta projekti tellinud

asutus ning tellija

kontaktisik koos

kontaktandmetega.

Lk 5/7

4. Vähemalt 36-kuune

projektijuhtimise

töökogemus tarkvara

arenduses

Sisestada selle

meeskonnaliikme nimi, kes

vastab nimetatud nõudele

Lisada tööandja nimi,

töökogemuse kestuse periood,

tööülesannete lühikirjeldus

- Tööandja kontaktisik

koos kontaktandmetega.

5. Vähemalt 36-kuuline

töökogemus tarkvara

analüüsi läbiviimisel

Sisestada selle

meeskonnaliikme nimi, kes

vastab nimetatud nõudele

Lisada tööandja nimi,

töökogemuse kestuse periood,

tööülesannete lühikirjeldus

- Tööandja kontaktisik

koos kontaktandmetega.

6. Kogemus projektis UML-

iga (Unified Modeling

Language)

Sisestada selle

meeskonnaliikme nimi, kes

vastab nimetatud nõudele

Projekti nimi ja sisu kirjeldus

Sisestada projekti

periood. Riigihanke

korral lisada viitenumber.

Sisesta projekti tellinud

asutus ning tellija

kontaktisik koos

kontaktandmetega.

7. Prototüübi koostamise

kogemus (Figma vm

sarnane vahend) projektis

Sisestada selle

meeskonnaliikme nimi, kes

vastab nimetatud nõudele

Projekti nimi ja sisu kirjeldus

Sisestada projekti

periood. Riigihanke

korral lisada viitenumber.

Sisesta projekti tellinud

asutus ning tellija

kontaktisik koos

kontaktandmetega.

8. Vähemalt 24-kuuline

töökogemus süsteemi- või

tarkvara arhitekti rollis

Sisestada selle

meeskonnaliikme nimi, kes

vastab nimetatud nõudele

Lisada tööandja nimi,

töökogemuse kestuse periood,

tööülesannete lühikirjeldus

- Tööandja kontaktisik

koos kontaktandmetega.

9.

GIT versioonihalduse

kogemus projektis

Sisestada selle

meeskonnaliikme nimi, kes

vastab nimetatud nõudele

Projekti nimi ja sisu kirjeldus

Sisestada projekti

periood. Riigihanke

korral lisada viitenumber.

Sisesta projekti tellinud

asutus ning tellija

kontaktisik koos

kontaktandmetega.

10. Kogemus projektis DevOps

arendustsükli

ülesehitamisel (Plan, Code,

Build, Test, Release,

Deploy, Operate, Monitor)

Sisestada selle

meeskonnaliikme nimi, kes

vastab nimetatud nõudele

Projekti nimi ja sisu kirjeldus

Sisestada projekti

periood. Riigihanke

korral lisada viitenumber.

Sisesta projekti tellinud

asutus ning tellija

kontaktisik koos

kontaktandmetega.

11. Kogemus projektis

mikroteenustel põhineva

arhitektuurilahenduse

Sisestada selle

meeskonnaliikme nimi, kes

vastab nimetatud nõudele

Projekti nimi ja sisu kirjeldus

Sisestada projekti

periood. Riigihanke

korral lisada viitenumber.

Sisesta projekti tellinud

asutus ning tellija

Lk 6/7

projekteerimisel ja

realiseerimisel

kontaktisik koos

kontaktandmetega.

12.

K8S kogemus projektis

Sisestada selle

meeskonnaliikme nimi, kes

vastab nimetatud nõudele

Projekti nimi ja sisu kirjeldus

Sisestada projekti

periood. Riigihanke

korral lisada viitenumber.

Sisesta projekti tellinud

asutus ning tellija

kontaktisik koos

kontaktandmetega.

13. Kogemus proovitöös

pakutava serveripoolse

raamistiku arendamisel

projektis (kas Go või Java

Spring Boot)

Sisestada selle

meeskonnaliikme nimi, kes

vastab nimetatud nõudele

Projekti nimi ja sisu kirjeldus

Sisestada projekti

periood. Riigihanke

korral lisada viitenumber.

Sisesta projekti tellinud

asutus ning tellija

kontaktisik koos

kontaktandmetega.

14. Kogemus proovitöös

pakutava kasutajaliidese

raamistiku arendamisel

projektis (kas React või

Angular raamistik)

Sisestada selle

meeskonnaliikme nimi, kes

vastab nimetatud nõudele

Projekti nimi ja sisu kirjeldus

Sisestada projekti

periood. Riigihanke

korral lisada viitenumber.

Sisesta projekti tellinud

asutus ning tellija

kontaktisik koos

kontaktandmetega.

15. REST API

(https://restfulapi.net/)

kogemus projektis

Sisestada selle

meeskonnaliikme nimi, kes

vastab nimetatud nõudele

Projekti nimi ja sisu kirjeldus

Sisestada projekti

periood. Riigihanke

korral lisada viitenumber.

Sisesta projekti tellinud

asutus ning tellija

kontaktisik koos

kontaktandmetega.

16. Kogemus vähemalt kahes

tarkvara arenduse projektis

testide automatiseerimise

teostamisel

Sisestada selle

meeskonnaliikme nimi, kes

vastab nimetatud nõudele

Projekti nimi ja sisu kirjeldus

Sisestada projekti

periood. Riigihanke

korral lisada viitenumber.

Sisesta projekti tellinud

asutus ning tellija

kontaktisik koos

kontaktandmetega.

17. Kogemus projektis

koormustestide ja API

testide kirjutamisel

Sisestada selle

meeskonnaliikme nimi, kes

vastab nimetatud nõudele

Projekti nimi ja sisu kirjeldus

Sisestada projekti

periood. Riigihanke

korral lisada viitenumber.

Sisesta projekti tellinud

asutus ning tellija

kontaktisik koos

kontaktandmetega.

Lk 7/7

18. Kogemus

digiligipääsetavuse

nõuetega projektis (nt EN

301 549 või WCAG

standard)

Sisestada selle

meeskonnaliikme nimi, kes

vastab nimetatud nõudele

Projekti nimi ja sisu kirjeldus

Sisestada projekti

periood. Riigihanke

korral lisada viitenumber.

Sisesta projekti tellinud

asutus ning tellija

kontaktisik koos

kontaktandmetega.

19. Kasutajaliidese ja

kasutajateekonna loomise

kogemus projektis

Sisestada selle

meeskonnaliikme nimi, kes

vastab nimetatud nõudele

Projekti nimi ja sisu kirjeldus

Sisestada projekti

periood. Riigihanke

korral lisada viitenumber.

Sisesta projekti tellinud

asutus ning tellija

kontaktisik koos

kontaktandmetega.

Lisa 5

Riigihange „Veebipõhise info- ja teenindusportaali arendus- ja hooldustööd“ (290452)

Lisa 5. RAAMLEPINGU ALUSEL SÕLMITAV HANKELEPING

Riigi Info- ja Kommunikatsioonitehnoloogia Keskus, (edaspidi „tellija“) registrikood 77001613,

aadress Lõõtsa 8a, Tallinn 11415, mida ________2024 sõlmitud raamlepingu nr ____ (edaspidi

„raamleping“) alusel esindab _________________,

ja ________________ (edaspidi „täitja”), registrikood _____________, aadress_______________,

mida esindab ___________

sõlmisid lähtuvalt raamlepingu tingimustest käesoleva hankelepingu (edaspidi „leping”) ja leppisid

kokku alljärgnevas:

1. Täitja kohustub teostama raamlepingus sätestatud tingimustel järgmised tööd (edaspidi töö):

1.1. _________________________;

1.2. _________________________.

2. Täitja kohustub teostama lepingus kokku lepitud töö ning andma selle koos tööst tulenevate

varaliste õigustega tellijale üle hiljemalt ___________________.

3. Täitja kohustub viivitamatult teatama tellijale kõigist töö teostamisega seotud olulistest asjaoludest,

eelkõige aga nendest, mis võivad mõjutada või mõjutavad töö tähtaegselt valmimist või töö

vastavust lepingu tingimustele ja/või mille vastu on või võib olla tellijal äratuntav oluline huvi.

4. Tellija maksab punktis 1 nimetatud töö teostamise eest täitjale tasu ________ eurot, millele

lisandub käibemaks.

5. Lepingu finantseerimise allikas: /märkida vajadusel/.

6. Punktis 1 nimetatud töö täpsem kirjeldus on toodud lepingule lisatud lähteülesandes.

Tellija Täitja

(allkirjastatud digitaalselt) (allkirjastatud digitaalselt)

RAAMLEPING nr 5-6/25-212-1

Riigi Info- ja Kommunikatsioonitehnoloogia Keskus, (edaspidi Tellija) registrikood 77001613, aadress

Lõõtsa 8a, Tallinn 11415, mida esindab direktor Ergo Tars,

ja

HEISI IT OÜ (edaspidi Täitja), registrikood 12765966, asukohaga Pärnu mnt 105, Tallinn 11312, mida

esindab juhatuse liige Talvi Pihl

sõlmisid käesoleva raamlepingu (edaspidi „Leping”) ja leppisid kokku alljärgnevas:

1. Lepingus kasutatavad mõisted

1.1. Suure algustähega mõisteid tuleb Lepingus tõlgendada nii, nagu need allpool on määratletud. Kui

ei ole teisiti sätestatud, siis viitab mõiste ainsuse vorm ka selle mitmusele. Kahtluse korral tuleb

väljendeid, millel võib olla rohkem kui üks tähendus, mõista viisil, mis sobib kõige rohkem

Lepingu olemuse ja eesmärkidega.

1.2. Akt - dokument, mille allkirjastamisega Täitja annab tehtud Tööd üle ja Tellija võtab need vastu;

1.3. Intellektuaalse omandi õigused – intellektuaalse omandi õiguste käsitlemisel lähtutakse

autoriõiguse seadusest;

1.4. Kodukord – Lepingu alusel teostavate tegevuste, nende tegevuste teostamise eest vastutajate,

tegevuste tulemusel valmivate tulemite, samuti tulemite valmimise eelduseks oleva Täitja ja

Tellija omavahelise suhtluse ning tagasiside edastamise kord. Kodukord on Lepingu lisaks;

1.5. Leping – Leping koos lisadega. Lepingu eesmärgiks on fikseerida Tööde edukaks tegemiseks

vajalike kokkulepete raamistik;

1.6. Kolmas isik – iga isik, kes ei ole lepingu pool;

1.7. Pool – sõltuvalt Lepingu kontekstist kas Tellija või Täitja või mõlemad koos;

1.8. Tarkvara – kõik Lepingu täitmiseks rakendatavate tarkvarade komponendid kogumis, ka RIT

portaal, infosüsteem või veebipõhine info- ja teenindusportaal. Tarkvara võib koosneda

järgmistest komponentidest:

a) Arendatav tarkvara – tarkvara, mis on loodud spetsiaalselt Tellija jaoks Tellija

konkreetseid huve ja soove silmas pidades Lepingu alusel;

b) Kommertstarkvara – tarkvara, mida kasutatakse Arendatava tarkvara funktsionaalsuse

tagamiseks ning mis kuulub kas Täitjale või kolmandale isikule ning mille kasutusõigus

antakse Täitja või kolmanda isiku poolt Tellijale litsentsi alusel;

c) Tellija tarkvara – mistahes tarkvara, mis on Tellija poolt omandatud, loodud või temale

litsentseeritud, v.a Arendatav tarkvara ja Kommertstarkvara;

d) Täitja tarkvara – tarkvara, mis on Täitja poolt omandatud, loodud või temale

litsentseeritud enne Lepingu sõlmimist;

e) Vabavaraline tarkvara – tarkvara, mida kasutatakse Arendatava tarkvara

funktsionaalsuse tagamiseks, kuid mida ei ole arendanud Täitja, vaid mis kuulub

kolmandale isikule ning mille kasutusõigus antakse kolmanda isiku poolt Tellijale tarkvara

vaba kasutuse litsentsi alusel.

1.9. Tellija – Riigihanke korraldaja ja läbiviija isik, keda Lepingu dokumentides võidakse nimetada

ka hankijaks;

1.10. Teostajad - Lepingu täitmiseks kasutatavad isikud, eelkõige Tellija või Täitja spetsialistid,

sealhulgas töötajad, alltöövõtjad, Tellija järelevalve vmt;

1.11. Täitja – Riigihankes eduka pakkumuse teinud isik, kellega Tellija sõlmib Lepingu;

1.12. Töö – Täitja poolt täidetavad tarkvara arenduse, seadistamise, konsultatsiooni, koolitamise või

muud Poolte vahel kokku lepitud ülesanded ja dokumenteerimine. Tööd jagunevad:

Lk 2/13

a) Garantiitööd – garantiiliste kohustuse täitmiseks tehtavad tööd;

b) Arendustööd – arendusteenus, mida Täitja osutab uue infosüsteemi funktsionaalsuse

loomiseks või tööde käigus loodud olemasoleva funktsionaalsuse muutmiseks, mis on

eelnevalt Tellija ja Täitja vahel kokku lepitud ja tellimusega kinnitatud;

c) Hooldustööd – hooldusteenus, mida Täitja osutab infosüsteemi omaduste säilitamiseks,

parandamiseks või parendamiseks etteplaneeritavalt. Hooldustöö eesmärgiks on tagada

infosüsteemi, millele hooldustööd osutatakse, toimimine.

1.13. Tööpäev – kalendripäevad esmaspäevast reedeni (kell 8:00-17:00), v.a riiklikud pühad;

1.14. Viga - tarkvaralahenduses esinev mittevastavus tellimusele. Vigade kriitilisuse astmed:

a) Kriitiline astme Viga (P1) – Tarkvaral põhinev teenus/süsteem ei toimi. Andmed on

rikutud. Tarkvara tekitab serveri ebanormaalset toimimist (mh luues ülemääraselt ajutisi

faile, tekitades serveritele ebanormaalset koormust, mis tingib serveri töös tõrkeid või

funktsioonide seiskumise). Tarkvara interpreteerib teistest süsteemidest ületulevaid

andmeid või protsesse mittesoovitud viisil. Esineb tööde või kasutajasessioonide

ebanormaalne katkemine. Probleem mõjutab süsteemi käideldavust ja andmete

integreeritust. Mõjutatud on enamus Tarkvara kasutajatest. Ajutine lahendus probleemi

vältimiseks praktiliselt puudub;

b) Keskmine astme Viga (P2) – Tarkvaraga seotud igapäevaste või perioodiliste toimingute

teostamine on osaliselt võimatu või nende tegevuste käigus on oht andmevigade tekkeks.

Mõjutatud on osad Tarkvara kasutajatest. Tähtsad Tarkvara funktsioonid pole käideldavad,

süsteem on ebastabiilne või on kiirus madalamal normaalsest koormuse nõudest. Ajutised

lahendused pole efektiivsed. Taastamine on keeruline;

c) Madal astme Viga (P3) – Tarkvaraga seotud vähemtähtsad funktsionaalsused ei toimi.

Süsteem võimaldab tarkvara põhifunktsionaalsust kasutada.

2. Lepingu üldsätted

2.1. Leping sõlmitakse Tarkvara loomise ja pideva toimimise ning jätkusuutliku arendamise

tagamiseks.

2.2. Lepingu eesmärgiks on sätestada Poolte õigused, kohustused ja vastutus Töö teostamisel

käesoleva Lepingu ja selle alusel sõlmitud hankelepingute raames.

2.3. Lepingu täitmist võidakse rahastada Euroopa Liidu vahenditest. Juhul kui täitja kasutab EL

ühtekuuluvus- ja siseturvalisuspoliitika fondide vahenditest rahastatava hankelepingu puhul

alltöövõtjaid ning alltöövõtulepingu maksumus ületab 50 000 eurot käibemaksuta, siis peab täitja

esitama andmed alltöövõtu kohta. Taaste- ja vastupidavuskava vahendite kasutamisel tuleb

edukal pakkujal esitada pärast hankelepingu sõlmimist riigihangete registri lepingu töölehel

„Alltöövõtjad“ kõigi hankelepingu täitmises osalenud alltöövõtjate kohta sõltumata riigihanke

eeldatavast maksumusest ja alltöövõtulepingu maksumusest. Täitja sisestab jooksvalt

alltöövõtjatega seotud info – alltöövõtja nimi ja registrikood, alltöövõtulepingu nimetus, kuupäev,

number ja summa – riigihangete registrisse, kus hankelepinguga seotud andmete juures on olemas

vastav vaheleht alltöövõtu jaoks.

2.4. Hanke dokumendid on Lepingu lahutamatuks osaks ning neid kasutatakse Lepingu

tõlgendamiseks. Vastuolu korral lähtutakse dokumentidest nende prioriteetsuse järjekorras:

2.4.1. käesolev raamleping;

2.4.2. hankeleping;

2.4.3. tehniline kirjeldus koos lisadega;

2.4.4. muud hanke alusdokumendid;

2.4.5. Täitja riigihankes esitatud ja edukaks tunnistatud pakkumus.

Lk 3/13

2.5. Hiljem tehtud muudatuste osas kehtib põhimõte, et ajaliselt hilisem muudatus prevaleerib ajaliselt

varasema muudatuse üle. Kui vastuolu esineb sama pädevusjärjekorra dokumentide vahel, siis

lähtutakse tõlgendamisel Lepingu eesmärgist ja mõistlikkuse põhimõttest.

2.6. Lepingu osaks on garantii teostatud Tööle ning teostatud Töö toimimisele olemasolevas süsteemis.

Garantiiperiood on 12 kuud pärast Töö vastuvõtmist.

2.7. Lepingu tõlgendamisel lähtutakse Poolte ühisest tegelikust tahtest, isegi kui see erineb sõnade

tavapärasest tähendusest. Kui Poolte ühist tegelikku tahet ei õnnestu kindlaks teha, tuleb Lepingut

tõlgendada nii, nagu teise Poolega samasugune mõistlik isik pidi Lepingut samade asjaolude

esinemise korral mõistma.

2.8. Pooled kohustuvad teist Poolt koheselt informeerima tehnilistest või organisatoorsetest

piirangutest, mis võivad seada ohtu Lepingu eesmärkide saavutamise.

2.9. Lepingu allkirjastamisel on lepingu lisad järgmised:

2.9.1. Lisa 2 Tehniline kirjeldus;

2.9.2. Lisa 2.1 Mittefunktsionaalsed nõuded;

2.9.3. Lisa 2.2 Nõuded dokumentatsioonile;

2.9.4. Lisa 2.3 Esimese etapi arendustööd;

2.9.5. Lisa 2.4 RIT portaali visiooni kavand;

2.9.6. Lisa 3 Kodukord;

2.9.7. Lisa 4 Nõuded meeskonnale;

2.9.8. Lisa 5 Raamlepingu alusel sõlmitav hankeleping.

3. Lepingu ese

3.1. Lepingu esemeks on veebipõhise info- ja teenindusportaali arendamine, toimimine ja regulaarne

hooldus.

3.2. Lepinguga kohustub Täitja teostama töid käesolevas Lepingus, selle lisadokumentides ja Lepingu

alusel sõlmitud hankelepingutes kokkulepitud tingimustel ja korras.

3.3. Tellija ostab Täitjalt Töid 48 kuu jooksul lähtuvalt Tellija eelarvelistest vahenditest ja vajadustest

tunnihinnaga 40,00 eurot, millele lisandub käibemaks.

3.4. Raamlepingu kogumaksumus on 500 000,00 (viissada tuhat) eurot, millele lisandub käibemaks.

3.5. Hankelepingute kehtivus ei ole piiratud raamlepingu kehtivuse lõpptähtpäevaga.

3.6. Tellija poolt sõlmitavate hankelepingute arv ei ole piiratud ja maht on piiratud raamlepingu

kogumaksumusega.

3.7. Täitja tehtavad Tööd on määratletud Riigihanke alusdokumentides, sõlmitavates hankelepingutes

ja muudes Lepingu lisades. Tööde täpsem sisu lepitakse kokku etapiviisiliselt ning

dokumenteeritakse tellimuses (detailne ülesande püstitus, analüüs, kirjeldus).

3.8. Tellija eeldab, et Täitja on Lepingu esemeks olevate Tööde tarkvaraarenduse valdkonna

professionaal, kes saab aru ning võtab teadlikult enda kanda Lepingust tuleneva koostoime,

ristfunktsionaalsete nõuete täidetavuse ja tulemuse saavutatavuse riski. Seepärast laieneb Täitjale

ka nende tööde tegemise kohustus, mida ei ole otsesõnu kokku lepitud, kuid mis oma olemusest

lähtuvalt kuuluvad seotud Tööde hulka ja pidid olema ettenähtavad Täitjale kui professionaalile

riigihankes pakkumuse esitamise etapis ning on vajalikud lõpptulemuse saavutamiseks. Viimati

nimetatud tööde tegemine ei kuulu teistsuguse kirjaliku kokkuleppe puudumisel eraldi

tasustamisele ning Täitja teostab need tööd Lepingu täitmise raames. Täiendava kokkuleppeta ei

kuulu täitmisele uued funktsionaalsed või ristfunktsionaalsed nõuded, mida ei olnud nimetatud

Riigihanke alusdokumentides.

3.9. Täitja tagab Tarkvara ühilduvuse Tellija toodangukeskkonnaga, sh Tellija tarkvaraga.

4. Poolte õigused ja kohustused

Lk 4/13

4.1. Tellijal on õigus:

4.1.1. tellida Töid lähtuvalt vajadusest ja eelarvelistest vahenditest;

4.1.2. kontrollida Töö protsessi ning Täitja poolt lepingu tingimustest kinnipidamist;

4.1.3. kontrollida tehnoloogia valikuid, nõuda täiendavaid selgitusi ja põhjendusi valikute kohta,

kaasata infosüsteemi auditeerimisse kolmandaid isikuid;

4.1.4. nõuda töötaja väljavahetamist, kui Tellija leiab, et töötaja ei ole piisavalt kompetentne,

esitades selleks oma põhjendatud seisukoha. Vajadusel täidab töötaja selleks testülesande.

4.2. Tellija on kohustatud:

4.2.1. tasuma töö tegemise eest tähtaegselt;

4.2.2. teavitama Täitjat kõikidest Töö tegemise käigus avastatud puudustest;

4.2.3. teavitama Täitjat kõigist planeeritavatest ja/või teadaolevatest muudatustest, mis võivad

oluliselt mõjutada Tööd;

4.2.4. tagama Täitjale tööks vajaliku informatsiooni kättesaadavuse.

4.3. Täitja on kohustatud:

4.3.1. tegema Tellija poolt soovitud Tööd vastavalt lepingu tingimustele ja Töö valdkonda

reguleerivatele seadustele;

4.3.2. kõrvaldama operatiivselt Töö tegemisel ilmnenud takistused ja probleemid, mis alluvad

Täitja kontrollile;

4.3.3. teatama Tellijale koheselt asjaoludest, mis võivad ohustada Töö tähtajaks valmimist või

kvaliteeti;

4.3.4. kasutama Lepingu täitmisel riigihanke pakkumuses nimetatud Teostajaid või Tellija

eelneval kirjalikul nõusolekul asendama nad Teostajatega, kes vastavad hankes nimetatud

tingimustele;

4.3.5. informeerima Tellijat muutustest töötajate koosseisus, tagades uue töötaja samaväärse

kompetentsuse ning kandes kõik tööga tutvumise ja sisseelamise kulud.

5. Garantii, vead ja sanktsioonid

5.1. Täitja annab Töödele garantii 12 kuud. Garantiiperiood hakkab kulgema Tellija poolt Tööde

vastuvõtmise päevast. Kui Tööd võetakse vastu etapiviisiliselt, algab garantiiperiood viimase

etapi vastuvõtmisest.

5.2. Täitja parandab ilmnenud vead ja puudused garantiiaja jooksul omal kulul, sealhulgas uuendab

või asendab kõik seonduvad dokumendid, ja kannab uue versiooni paigaldusega seotud kulud.

5.3. Nõuded Toodangukeskkonnas avastatud Vigade reageerimisele ning lahendamisele on

alljärgnevad:

5.3.1. Kriitiliste Vigade (P1) puhul tuleb Veale reageerida ja lahendada hiljemalt 3 Tööpäeva

jooksul. Kui Vea kõrvaldamine 3 Tööpäeva jooksul ei õnnestu, kohustub Täitja esitama

raporti Vea kõrvaldamisega seotud tegevuste kohta kuni Vea kõrvaldamiseni alates 4

(neljandast) Tööpäevast igal Tööpäeval;

5.3.2. Keskmise astme Vigade (P2) puhul tuleb Veale reageerida ja lahendada hiljemalt 10

Tööpäeva jooksul;

5.3.3. Madala astme Vigade (P3) puhul tuleb Veale reageerida ja lahendada Tellijaga

kokkulepitud tähtajaks, kuid mitte hiljem kui 15 Tööpäeva Vea teavitusest.

5.4. Tellijal on õigus nõuda punktis 5.3.1, 5.3.2 ja 5.3.3 sätestatud tähtaja ületamisel igakordsel vea

esinemisel ühekordset leppetrahvi 3 000 eurot.

5.5. Leppetrahvi tasumine ei välista Tellija õigust nõuda kohustuste täitmist.

5.6. Kokkulepitud Tööde rakendamise tähtaja ületamisel on Tellijal õigus rakendada leppetrahvi

0.15% päevas Töö maksumusest.

Lk 5/13

5.7. Leppetrahvide rakendamise otsusest informeeritakse Täitjat otsuse tegemisele järgneval

Tööpäeval e-posti teel Lepingus märgitud kontaktisiku poolt.

5.8. Garantiiga ei ole hõlmatud:

5.8.1. ekspluatatsioonihäirete kõrvaldamine, mis on põhjustatud Tellija või tema poolt kasutatava

kolmanda isiku poolt juhuslikust või tahtlikust Tarkvara kahjustamisest või ebaõigest

kasutamisest;

5.8.2. vead, mis on tingitud Tarkvara kasutamisest vastuolus Täitja koostatud ja Tellija poolt

vastu võetud dokumentatsiooniga;

5.8.3. probleemid, mis tulenevad liidestatud süsteemide sisenditest, vaatamata sellele, et Täitja

on nõuetekohaselt rakendanud sisendikontrolli;

5.8.4. seotud süsteemide liideste kooskõlastamata muudatusest tulenevad funktsionaalsed häired

ja andmekvaliteedi probleemid;

5.8.5. diagnostikaks kulunud aeg, juhul kui algselt garantii juhtumina registreeritud juhtumi

uurimise raames tuvastatakse, et tegu ei ole garantiilise juhtumiga.

5.9. Garantii kaotab kehtivuse, kui Täitjaga kooskõlastamata on muudetud või muudetakse lähtekoodi.

Garantii ei kaota kehtivust, kui Tellija suudab eristada lähtekoodis tehtavad muudatusi.

5.10. Kui Viga ei kuulu garantii korras kõrvaldamisele, esitab Täitja Tellijale põhjendused kirjalikus

vormis viivitamatult, kuid mitte hiljem, kui järgmisel Tööpäeval pärast sellest asjaolust teada

saamist.

5.11. Garantii alla mittekuuluvate vigade korral rakendatakse punktis 5.3 sätestatud tähtaegu, kuid

nende lahendamisega seotud kulud kannab Tellija.

5.12. Kui Poolte vahel tekib vaidlus Vea üle, on kummalgi Poolel õigus tellida sõltumatu ekspertiis,

teavitades sellest eelnevalt teist Poolt. Pooled on kohustatud tagama eksperdi nõudmisel ligipääsu

vajalikele andmetele või informatsioonile. Ekspertiisikulud kannab Pool, kes ekspertiisiakti

kohaselt Vea garantiilisuse hindamisel eksis.

5.13. Tellija viib läbi turvatestimisi. Sama turvanõrkuse kordumisel mitmes erinevas turvatestis

toimub selle parandamine Täitja poolt ilma lisakuludeta Tellijale.

6. Omandiõigused

6.1. Kui Töö sisaldab Täitja poolt Tellijale üle antavaid asju, siis läheb asja omandiõigus Täitjalt

Tellijale üle vastavat asja sisaldava Töö vastuvõtmise või vastavalt Lepingule vastuvõetuks

lugemise hetkest.

7. Autoriõigused

7.1. Lepingu alusel välja töötatud ja Tellijale üle antud Töö, selle üksikute osade ja kõigi muude Töö

tulemite autori varalised õigused kuuluvad tervikuna Tellijale.

7.2. Töövõtja annab tellijale ainulitsentsi isiklike õiguste teostamiseks. Tellijal on õigus teostada Töös

ja selle üksikutes osades muudatusi, kohandusi, töötlusi, kombineerida Töö teiste tarkvaradega

ning saadud tarkvara kasutada ja levitada või teostada töö ja selle osade suhtes muid autori

isiklikke ja varalisi õigusi.

7.3. Töö üleandmise- vastuvõtmise akti allkirjastamise järgselt lähevad töö ja selle andmekandjate

omandiõigus ja kõik autori varalised õigused üle Tellijale.

7.4. Täitja kinnitab, et on sõlminud Tööd teostavate töötajatega lepingud, mille alusel enne Täitja

lepingule alla kirjutamist on Töötajad loovutanud Täitjale kõik lepingu täitmisega seoses

valmivatele tulemustele (k.a lõpule viimata Tööle) või nende osadele tekkivad autoriõigusega

kaasnevad varalised õigused ning andnud ainulitsentsi isiklikele õigustele.

Lk 6/13

7.5. Täitja kinnitab, et Lepinguga Tellijale üle antavad autoriõigusega kaasnevad varalised õigused

ning ainulitsents isiklikele õigustele on Täitja poolt üle antavad ning et Täitja ei ole selliseid õigusi

enne Tellijale üleandmist võõrandanud ega koormanud kolmandate isikute õigustega.

7.6. Täitja kinnitab, et annab Tellijale üle autoriõigusega kaasnevad varalised õigused ning

ainulitsentsi isiklikele õigustele Töö tulemustele (sh kogu dokumentatsiooni) ning need kuuluvad

Tellijale eeldusel, et Tellija on töö eest tasunud lepingus ettenähtud hinna.

7.7. Lepingu allkirjastamisega kinnitavad Pooled, et neile kuuluvad Lepingu täitmiseks vajalikud

varalised autoriõigused, litsentsid ja muud intellektuaalse omandi õigused, mis on tarvilikud

Lepingujärgse Töö täielikuks teostamiseks ja loovutamiseks käesolevas peatükis toodud ulatuses

ning, et nende suhtes ei ole kolmandatel isikutel nõudeid. Pooled kinnitavad, et on võtnud

tarvitusele kõik meetmed autori isiklike õiguste realiseerimiseks viisil, mis ei takista ega raskenda

teose kasutamist ja autori varaliste õiguste teostamist.

7.8. Pool kohustub lahendama kõikvõimalikud litsentseeritud või vahendatud Tarkvaraga seotud

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

koostööpartneritega. Juhul kui Täitjapoolsetest litsentseerimisvigadest tulenevalt tekib Tellijale

rahaline või muu kohustus või kui Tellija on kohustatud lõpetama Tarkvara kasutamise, on

Tellijal õigus nõuda Täitjalt selle rahalise või muu kohustuse täitmist ja või kaotatud Tarkvaraga

samaväärse tulemi loomist tasuta ja võimalikult lühikese aja jooksul, hoidudes mistahes

viivitustest tulemi arendamises ja kasutuselevõtmises Tellija poolt.

7.9. Lepingu täitmisel Kommertstarkvara kasutamise osas juhinduvad Pooled nende kasutamise

litsentsitingimustest. Täitja kinnitab, et eelistab tarkvara loomisel sellist Kommertstarkvara, mille

kasutamine ei too Tellijale kaasa täiendavaid litsentsitasusid või piiranguid tarkvara kasutamisel.

7.10. Täitja võib kasutada tarkvara loomisel pakkumuses mittenimetatud Kommertstarkvara vaid

Tellija eelneval kirjalikul nõusolekul. Kirjaliku nõusoleku taotlemisel on Täitja kohustatud

esitama Tellijale litsentsi hinna, litsentsitingimused ja andmed lähtekoodi kättesaamise võimaluse

kohta.

7.11. Tasu Intellektuaalse omandi õiguste Tellijale ülemineku ja litsentside eest sisaldub Lepingu

maksumuses ning Täitjal ei ole õigust nõuda täiendavat tasu nende õiguste üleandmise ega

litsentsimise eest (sh Lepingu sõlmimise ajal tundmatute kasutusviiside lubamise eest tulevikus).

8. Töö tellimine ja üleandmine-vastuvõtmine

8.1. Töö esimene tellimus esitatakse raamlepingu lisa 2 kohaselt.

8.2. Töö tellimus esitatakse või kinnitatakse Tellija esindaja poolt ja kinnitatakse Täitja esindaja poolt

ning fikseeritakse tööde halduskeskkonnas (vt lisa 3). Tellimuse esitamist ja kinnitamist osapoolte

esindajate poolt loetakse hankelepingu sõlmimiseks käesoleva lepingu kontekstis.

8.3. Alates 20 000 eurot (ilma käibemaksuta) maksvate Tööde tellimisel vormistatakse kirjalik

hankeleping.

8.4. Tellija kontaktisik on Liisbeth Pakats, tel 5341 9535, e-post [email protected];

8.5. Täitja kontaktisik on Talvi Pihl, tel 5669 7313, e-post [email protected].

8.6. Tellija kontaktisikul on õigus tellida Tööd ja allkirjastada Tellija nimel vastavaid Akte.

8.7. Täitja kontaktisikul on õigus anda Tööd Tellijale üle ja allkirjastada Täitja nimel vastavaid Akte

ning kohustus nõutada Tellija juhiseid ja informatsiooni Lepingu täitmise käigus tekkinud

küsimuste ja probleemide lahendamiseks.

8.8. Täitja esitab eelmise kuu töötundide ajaaruande, mis sisaldab teostatud töötunde ja nende jooksul

teostatud Töid. Ajaaruanne esitatakse hiljemalt järgmise kalendrikuu 5. tööpäeval või

hankelepingus kokkulepitud arenduse etapi lõppemise järgse kalendrikuu 5. tööpäeval. Viimane

ajaaruanne esitatakse koos Aktiga. Aktis peavad tehtud hooldus- ja arendustööd olema teineteisest

eristatud.

Lk 7/13

8.9. Tellijal on kümme tööpäeva aega kontrollida vastuvõtmiseks esitatud tööde lepingutingimustele

vastavust ning Akti allkirjastamiseks. Tellija võib nimetatud tähtaega pikendada, kui pikendamine

on põhjendatud.

8.10. Tellija võtab Tööd vastu Akti allkirjastamisega pärast tööde nõuetekohasuse kontrollimist ja

edukat vastuvõtutestimist.

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

mis fikseeritakse Aktis.

8.12. Tellija poolne pisivigadega Tööde vastuvõtmine ei vabasta täitjat kohustusest vead kõrvaldada

ning üle anda vigadeta Tööd.

8.13. Tellija määrab mõistliku tähtaja pisivigade parandamiseks.

8.14. Tellijal on õigus keelduda Tööde vastuvõtmisest kui Tööd ei vasta esitatud nõuetele või Töödes

esineb muid vigu.

8.15. Kui Tellija esitab vastuväited töödele, peab Täitja tööd parandama Tellija poolt määratud

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

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

selleks tehtud mõistlike kulutuste hüvitamist.

8.16. Alates teisest kordustestimisest võib Tellija kordustestidega seotud kulutused (Tellija kulutatud

tööaeg ja/ või Tellija testimispartnerite poolt esitatud arvete alusel) Täitjalt välja nõuda või

tasaarvestada.

8.17. Garantiitööd fikseeritakse tööde halduskeskkonnas ja teostatakse lähtuvalt lepingu punktist 5.

8.18. Täitjal on õigus tõendada Tööde vastuvõtmisest keeldumise põhjuste ebaõigsust, nõudes selleks

mõlemaid Pooli rahuldava sõltumatu ekspertiisi tegemist. Kui Tööde vastuvõtmisest keeldumine

osutub ekspertiisi tulemusel põhjendamatuks, loetakse Tööd vastuvõetuks ning Tellija tasub

Täitjale ekspertiisikulud, vastasel korral kannab ekspertiisikulud Täitja.

8.19. Tellijale tuleb üle anda ka Tööde juurde kuuluv või nendega seotud dokumentatsioon, tehes kõik

dokumendid Tellija dokumendihalduskeskkonna kaudu Tellijale kättesaadavaks, järgides lisa 2.2

„Nõuded dokumentatsioonile“ toodud dokumentatsiooni koostamise ja esitamise nõudeid.

9. Arveldused

9.1. Lepingus fikseeritud tasu on Täitja ainus tasu seoses Lepinguga ning tasu võib muuta üksnes

Poolte kirjaliku kokkuleppega õigusaktides lubatud juhtudel ja korras.

9.2. Töö eest tasumine toimub Tellija poolt allkirjastatud valminud ja üle antud Tarkvara üleandmise-

vastuvõtmise aktide alusel pärast Täitja poolt masinloetava e-arve väljastamist.

9.3. Täitja poolt esitatud arve maksetähtaeg ei või olla lühem kui 30 päeva arve saamise kuupäevast

arvates.

9.4. Arve loetakse tasutuks peale arvel näidatud summa ülekandmist Tellija poolt.

9.5. Kui Tellija ei tasu Täitja esitatud arveid õigeaegselt, on Täitjal õigus nõuda viivist 0,15% vastaval

arvel märgitud tasumata summalt iga viivitatud kalendripäeva eest kuni arve täieliku tasumiseni,

kuid mitte rohkem kui 50% vastava arve summast. Viivise maksmiseks kohustatud Tellija on

kohustatud tasuma viivise 30 kalendripäeva jooksul arvates Täitjalt sellekohase nõude saamisest.

9.6. Lepingu alusel Poole tasutud mistahes maksega loetakse esmajärjekorras vastavas osas tasutuks

Lepingu täitmisega (sh täitmisele pööramisega) seotud kulud (sh õigusabikulud), seejärel viivis

ja leppetrahvid alates varaseimast võlgnevusest ning seejärel tasumata põhisumma alates

varaseimast võlgnevusest. Seda nõuete rahuldamise järjekorda saab muuta ainult Poolte kirjaliku

kokkuleppega.

10. Konfidentsiaalsus ja isikuandmete töötlemine

Lk 8/13

10.1. Pooled tagavad käesoleva lepingu täitmise ja lepingust tulenevate kohustuste täitmise käigus

teineteiselt ükskõik mis vormis saadud teabe (sh andmed, isikuandmed, spetsiifilise teadmise)

konfidentsiaalsuse ja ei anna seda edasi ega võimalda sellele teabele juurdepääsu kolmandatele

isikutele ilma teise poole sellekohase selgesõnalise kirjaliku nõusolekuta.

10.2. Andmete töötlemisel kolmanda isiku (edaspidi Alltöötleja) kasutamiseks peab volitatud töötleja

esitama Tellijale kirjalikku taasesitamist võimaldavas vormis taotluse, milles toob ära selle

kolmanda isiku nime, aadressi, kontaktisiku ja üksikasjaliku kirjelduse funktsioonidest, mille

jaoks volitatud töötleja kavatseb Alltöötlejat rakendada. Tellija nõustumise korral peab Täitja

Alltöötlejaga lepingu sõlmimisel kaasama sõlmitavasse alltöötlemise lepingusse käesolevas

lepingus sisalduvatega samaväärsed tingimused.

10.3. Täitja vastutab kõigi Alltöötleja poolsete seaduste, eeskirjade või lepingu rikkumiste eest nii, nagu

oleks selle rikkumise põhjustanud Täitja ise.

10.4. Täitja kohustub mitte edastama lepingu täitmise käigus ükskõik mis vormis saadud teavet (sh

andmed, isikuandmed, spetsiifilise teadmise) ilma Tellija sellekohase selgesõnalise kirjaliku

nõusolekuta.

10.5. Lepingu täitmise käigus Täitjale teatavaks saadud isikuandmed ei kuulu Tellija nõusolekuta

protokollides ning loodavates dokumentides avaldamisele.

10.6. Täitja kohustub kasutama ja töötlema Tööde teostamise täitmise käigus Tellijalt ükskõik mis

vormis saadud teavet (andmed, isikuandmed, spetsiifilise teadmise) üksnes Tööde teostamiseks

ja Tellija dokumenteeritud juhiste alusel, välja arvatud juhul, kui Täitja on kohustatud teavet

töötlema Täitja suhtes kohalduva õiguse alusel. Viimati nimetatud juhul teavitab Täitja Tellijat

vastava kohustuse olemasolust enne teabe töötlemist, kui selline teavitamine ei ole olulise avaliku

huvi tõttu Täitja suhtes kohalduva õigusega keelatud.

10.7. Pooled võimaldavad juurdepääsu konfidentsiaalsele teabele (sh isikuandmetele) ainult nendele

isikutele, kellel on selleks oma tööülesannete täitmiseks vajadus ning tagavad, et need isikud on

teadlikud ja järgivad isikuandmete töötlemisalaseid nõudeid ja õigusakte, nad on saanud

asjakohase koolituse eelnimetatud nõuete kohta, on võtnud endale konfidentsiaalsuskohustuse või

neile kehtib asjakohane seadusest tulenev konfidentsiaalsuskohustus. Konfidentsiaalsus-

kohustuse nõue on tähtajatu ning kehtib nii raamlepingu kehtivuse ja Tööde teostamise ajal, kui

ka pärast Tööde teostamise ja raamlepingu lõppemist.

10.8. Pooled täidavad kõiki kehtivaid isikuandmete töötlemisalaseid nõudeid, andmete turvalisust

puudutavaid ning isikuandmete kaitse alaseid Euroopa Liidu ja Eesti Vabariigi õigusakte ja

eeskirju.

10.9. Täitja ei tohi edastada andmeid kolmandasse riiki (väljapoole EL-i/EMÜ-d) ega rahvusvahelisele

organisatsioonile, kui seda ei nõua EL-i või selle liikmesriigi õigus, mis Täitjale kohaldub.

10.10. Täitja kohustub rakendama organisatsioonilisi, füüsilisi ja infotehnilisi turvameetmeid punktis

10.1 nimetatud teabe, sh 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. Kasutatavad turvameetmed

peavad vastama vähemalt Eesti infoturbestandardi (E-ITS) tasemele "VS" ehk väga suur.

10.11. Täitja kohustub viivitamatult (hiljemalt 24 tunni jooksul teadasaamisest) kirjalikku taasesitamist

võimaldavas vormis teavitama Tellijat toimunud või põhjendatult kahtlustatavast käesolevas

kokkuleppes sätestatud konfidentsiaalsuskohustuse rikkumisest; punktis 10.10 sätestatud

turvameetmete rikkumisest, mis põhjustab, on põhjustanud või võib põhjustada edastatavate,

salvestatud või muul viisil töödeldavate isikuandmete juhusliku või ebaseadusliku hävitamise,

kaotsimineku, muutmise või loata avalikustamise või neile juurdepääsu, kirjalikku taasesitamist

võimaldavas vormis ilma põhjendamatu viivituseta. Teates tuleb vähemalt:

Lk 9/13

10.11.1. kirjeldada (isikuandmetega seotud) rikkumise laadi, sealhulgas puudutatud

andmesubjektide liike ja arvu ning puudutatud kirjete liike ja arvu;

10.11.2. teatada andmekaitse töötaja ja tema kontaktandmed või muu kontaktpunkt, kust saab

lisateavet;

10.11.3. soovitada meetmeid (isikuandmetega seotud) rikkumise võimalike negatiivsete mõjude

leevendamiseks;

10.11.4. kirjeldada (isikuandmetega seotud) rikkumise tõttu andmesubjektidele tekkivaid

tagajärgi ja potentsiaalseid ohte;

10.11.5. kirjeldada Täitja või kolmandast isikust alltöötleja poolt välja pakutud või võetud

meetmeid (isikuandmetega seotud) rikkumisega tegelemiseks ja esitada muud teavet,

mis on mõistlikult nõutav, et Tellija saaks täita kohaldatavaid andmekaitse õigusakte,

sealhulgas riigiasutustega seotud teavitamise ja avaldamise kohustusi, näiteks teavet,

mis on nõutav andmesubjekti tuvastamiseks.

10.12. Täitja kohustub Tellija nõudmisel lõpetama käesoleva lepingu punktis 10.11 nimetatud

rikkumise ning kohaldama isikuandmetega seotud meetmeid rikkumise lahendamiseks,

sealhulgas vajaduse korral rikkumise võimaliku kahjuliku mõju kõrvaldamiseks ja

leevendamiseks.

10.13. Täitja kohustub Töö teostamise lõppemisel kustutama kõik talle Töö teostamise käigus

teatavaks saanud isikuandmed ja nimetatute koopiad 90 kalendripäeva jooksul, v.a juhul, kui

õigusaktidest tuleneb teisiti.

10.14. Täitja kohustub Tellijale tegema kättesaadavaks kogu teabe, mis on mõistlikult vajalik ja

õigusaktidest tulenevalt kohustuslik käesolevas punktis sätestatud kohustuste täitmise

tõendamiseks.

10.15. Täitja kohustub abistama võimaluse piires asjakohaste tehniliste ja korralduslike meetmete abil

Tellijat täita Täitja kohustust vastata taotlustele andmesubjekti õiguste teostamiseks ning

teostada nende õiguste teostamisest tulenevaid toiminguid (andmete parandamine, sulgemine,

kustutamine).

10.16. Käesoleva kokkuleppe punktis 10.1 sätestatud konfidentsiaalsuse nõue ei laiene informatsiooni

avaldamisele Täitja audiitorile ja advokaadile. Enne teabe avaldamist on pool kohustatud teist

poolt avaldamise kavatsusest teavitama.

10.17. Tulenevalt konfidentsiaalse informatsiooni laadist on Tellijal õigus seada täiendavaid nõuded

ja/või juhised isikuandmete töötlemiseks.

10.18. Kõik eelnimetatud kohustused kehtestab Täitja kõikidele kolmandatele isikutele, keda ta

kasutab oma lepingujärgsete kohustuste täitmisel. Kolmas isik on iga füüsiline või juriidiline

isik või riigi- või kohaliku omavalitsuse asutus, kes ei ole Tellija ega Täitja.

11. Vastutus

11.1. Pool vastutab Lepingulise avalduse, kinnituse ja/või kohustuse rikkumise eest vastavalt Lepingule

ja õigusaktides sätestatule. Pool vastutab teise Poole ees ka Lepingu rikkumise eest, mis tuleneb

Poole poolt Lepingu täitmisele kaasatud Teostajate tegevusest või tegevusetusest.

11.2. Pool ei vastuta Lepingu rikkumiste eest, mis tulenevad teise Poole Lepingu rikkumistest või

kolmandate isikute tegevusest või tegemata jätmistest (näiteks ei valmi kolmanda isiku loodav

liides tähtaegselt).

11.3. Poolte rahaline koguvastutus on piiratud Lepingu kogumaksumusega, kuid see piirang ei kehti

tahtliku rikkumise korral.

11.4. Tellijal on õigus arvestada Tellija esitatud leppetrahvinõuete ja kahjuhüvitiste summad maha

Täitjale tasumisele kuuluvast lepingutasust Täitjat sellest eelnevalt teavitades.

11.5. Oluliseks lepingurikkumiseks loetakse muu hulgas järgmisi rikkumisi:

Lk 10/13

11.5.1. kui Pool ei täida mistahes Lepingust tulenevat kohustust teise Poole poolt Lepingust

tuleneva vastava kohustuse täitmiseks antud täiendava mõistliku tähtaja jooksul;

11.5.2. Täitja ei täida garantiiperioodil Lepingust tulenevaid kohustusi;

11.5.3. kui Poolel või tema poolt kaasatud Teostajal puuduvad Lepingu täitmiseks vajalikud

õigused (sealhulgas load, litsentsid, Intellektuaalse omandi õigused) ja Tellija on

eeltoodud puudustele korrektselt viidanud;

11.5.4. Pool on rikkunud Intellektuaalse omandi õigusi ja nende kasutamise tingimusi;

11.5.5. Pool on rikkunud konfidentsiaalsuskohustust;

11.5.6. Tellija on viivituses Lepingus kokku lepitud maksetähtajaga rohkem kui kolmkümmend

(30) kalendripäeva;

11.5.7. Täitja vahetab riigihanke pakkumuses nimetatud Teostajaid isikute vastu, kes ei vasta

hankes kehtestatud tingimustele;

11.5.8. kui Täitja annab oma ettevõtte või selle osa koos Lepinguga üle Tellija eelneva kirjaliku

nõusolekuta.

11.6. Täitja on vastutav dokumentaalselt tõestatud kahju eest, mis tekib Tellijale täitja poolt osutatud

töö kasutamisest.

11.7. Kui üks Pooltest paneb toime olulise lepingurikkumise, on teisel Poolel õigus kasutada rikkuva

Poole suhtes õiguskaitsevahendina omapoolsete kohustuste täitmisest keeldumise õigust kuni

rikkuva Poole võlgnetavate kohustuste täitmiseni. Kahjustunud Pool on kohustatud teavitama

Lepingu teist Poolt omapoolsete kohustuste täitmise peatamisest kirjalikus vormis. Kui Pool

peatab oma Lepingust tulenevate kohustuste täitmise selle punkti alusel või muul põhjusel kui

vääramatu jõu esinemise tõttu, pikeneb Lepingu täitmise tähtaeg kalendripäevade võrra, mille

vältel oli Poole kohustuste täitmine nõuetekohaselt peatunud ning rikkunud Pool on kohustatud

hüvitama teisele Poolele Töö peatamise ja taasalustamisega seoses tekkinud mõistlikud ja

põhjendatud kulud.

12. Vääramatu jõud

12.1. Poole kohustuste mittetäitmist või mittenõuetekohast täitmist ei loeta rikkumiseks, kui selle

põhjuseks oli vääramatu jõud. Vääramatu jõuna käsitavad Pooled võlaõigusseaduses nimetatud

asjaolusid.

12.2. Pool, kelle tegevus Lepingujärgsete kohustuste täitmisel on takistatud vääramatu jõu asjaolude

tõttu, on kohustatud sellest koheselt kirjalikult teatama teisele Poolele.

12.3. Vääramatu jõu asjaolude ilmnemisel pikeneb Lepingu täitmise lõpptähtaeg nimetatud asjaolude

esinemise perioodi võrra. Pool peab vääramatu jõu asjaolude ära langemisel asuma viivitamatult

Lepingut täitma.

12.4. Vääramatu jõu asjaolu ei vabasta pooli kohustusest võtta tarvitusele kõik võimalikud abinõud

lepingu mittetäitmisega või mittekohase täitmisega tekitatava kahju vältimiseks või

vähendamiseks.

13. Lepingu kehtivus ja muutmine ja lõpetamine

13.1. Leping jõustub selle allakirjutamise hetkest ja on sõlmitud 48 kuuks. Lepingu alusel esitatavad

tellimused ehk sõlmitud hankelepingud, ning ka eraldi dokumendina sõlmitud hankelepingud

kehtivad kuni kõigi hankelepingutest tulenevate kohustuste täitmiseni mõlema poole poolt.

13.2. Leping lõpeb lepinguliste kohustuste täitmisega, Lepingu lõpetamise kokkuleppe sõlmimisega,

Lepingus ettenähtud alusel või seadusest tuleneval alusel.

13.3. Kõik dokumendid, kokkulepped ning tulevikus poolte vahel käesoleva lepinguga seonduvalt

sõlmitud täiendavad kokkulepped (kus viidatakse lepingule) sõlmitakse kirjalikult ja on lepingu

lisad, mis moodustavad lepingu lahutamatu osa.

Lk 11/13

13.4. Lepingut võib muuta poolte kirjalikul kokkuleppel, mis vormistatakse lepingu lisana. Lepingu

muudatused ja täiendused jõustuvad nende allakirjutamise momendist poolte poolt.

13.5. Poolel on õigus Leping üles öelda ette teatamistähtaega järgimata ainult järgmistel asjaoludel,

kui:

13.5.1. teine Pool on toime pannud olulise lepingurikkumise ega ole rikkumist heastanud 30

kalendripäeva jooksul kannatanud Poolelt vastava põhjendatud nõudesaamisest arvates;

13.5.2. teine Pool on näidanud üles kavatsust Lepingut oluliselt rikkuda ega ole Lepingu täitmist

taganud 14 kalendripäeva jooksul kannatanud Poolelt vastava nõude saamisest arvates;

13.5.3. vääramatu jõu asjaolude tõttu on Poole Lepingust tulenevate kohustuste täitmine

takistatud enam kui 2 kuu jooksul.

13.6. Tellijal on õigus Leping üles öelda:

13.6.1. 90-päevase ette teatamistähtajaga igal ajal sõltumata põhjusest;

13.6.2. ette teatamistähtaega järgimata, kui Täitja:

13.6.2.1. suhtes on algatatud pankrotimenetlus;

13.6.2.2. pankrot on välja kuulutatud;

13.6.2.3. Täitja varad arestitakse; või

13.6.2.4. Täitja finantsseisund halveneb Tellija põhjendatud hinnangul oluliselt ja see

halvenemine muudab vähetõenäoliseks Lepingu nõuetekohase täitmise.

13.6.2.5. Täitja viivitab oma lepinguliste kohustuste täitmisega rohkem kui 30 päeva.

13.7. Sõltumata Lepingu lõpetamise alusest kohustub Tellija Lepingu lõppemisel tasuma Täitjale

Lepingu lõppemise hetkeks faktiliselt teostatud ja tellimusele vastava Töö eest. Pooled teostavad

kõik nõuete tasaarvestused 3 kuu jooksul Lepingu lõppemise kuupäevast arvates.

13.8. Peale lepingu lõppemist on Täitja kohustatud Tellijale üle andma kogu tema valduses oleva

Tarkvara dokumentatsiooni, koodi, andmebaasi ja Täitja tööhalduskeskkonnas olevate Tööde

kirjelduste detailse väljavõtte. Peale seda on Täitja kohustatud hävitama kogu tema valduses oleva

Tarkvara puudutava informatsiooni.

14. Nõuete ja kohustuste üleminek

14.1. Lepingu või selles kokku lepitud õiguste ja kohustuste kolmandale isikule üleandmine saab

toimuda ettevõtte üleandmise tulemusena, kuid see eeldab Tellija eelnevat kirjalikku nõusolekut.

Tellija annab selles punktis nimetatud kirjaliku nõusoleku juhul, kui Lepingu või ettevõtte

omandajal on piisav ettevalmistus ja kogemus, mis tagab Lepingu eesmärgi saavutamise ja

Lepingu tingimuste vähemalt samaväärse täitmise.

15. Vaidluste lahendamine

15.1. Lepingu täitmisel ja tõlgendamisel lähtuvad Pooled kõikidel juhtudel Lepingust, selle lisadest ja

Eesti Vabariigi õigusaktidest.

15.2. Lepingus reguleerimata küsimustes kohaldatakse Tööle töövõtulepingu sätteid.

15.3. Lepingu täitmisel tekkinud vaidlusküsimused lahendatakse läbirääkimiste teel. Kokkuleppe

mittesaavutamisel lahendatakse vaidlus vastavalt õigusaktidega kehtestatud korrale.

16. Poolte vahelised teated ja kontaktisikud

16.1. Lepinguga seotud informatsioonilise iseloomuga teated edastatakse poolte vahel elektronposti

teel või lepingu lisades sätestatud tööde halduskeskkonna abil. Poolte vahelised lepingu

muutmisega seotud teated peavad olema allkirjastatud, välja arvatud teisele poolele õiguslikke

tagajärgi mittepõhjustavad teated.

16.2. Pooled kohustuvad teavitama teineteist liigse viivituseta kontaktisikute (p 8) ja/või

kontaktandmete muutumisest.

Lk 12/13

17. Lõppsätted

17.1. Pooled kinnitavad, et:

17.1.1. Lepingu sõlmimisega ei ole nad rikkunud ühtegi enda suhtes kehtiva seaduse, põhikirja

või muu normatiivakti sätet ega ühtki endale varem sõlmitud lepingute ja kokkulepetega

võetud kohustust;

17.1.2. neil on õigus- ja teovõime Lepingu sõlmimiseks ning Lepingust tulenevate kohustuste

täitmiseks ja õiguste realiseerimiseks;

17.1.3. nende poolt Lepingule ja selle lisadele allakirjutanud isikutele on antud piisavad

volitused Lepingu sõlmimiseks kooskõlas seaduste, põhikirjade või muude

õigusaktidega.

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

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

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

mittepööratav tingimus õiguslikult kehtiva tingimusega, mis on sisult võimalikult lähedane Poolte

kavatsustele ja kehtetu tingimuse majanduslikule mõjule.

Poolte esindajate allkirjad:

Tellija Täitja

(allkirjastatud digitaalselt) (allkirjastatud digitaalselt)

Ergo Tars Talvi Pihl

direktor juhatuse liige