VOLIKIRI

OÜ ADM Interactive (registrikood 10474271), keda esindab juhatuse liige Riho Pihelpuu

volitab käesolevaga

Hendrek Kraavi ([eemaldatud]) esindama äriühingut alljärgnevas:

1) sõlmima, muutma ja lõpetama klientidega sõlmitavad teenuslepinguid, s.h. vastavate

lepingutega seotud kokkuleppeid nagu konfidentsiaalsuslepingud jm;

2) esitama pakkumisi riigihangete osas ja sõlmima riigihangete lepinguid.

Volitus kehtib allkirjastamise hetkest tähtajatult või kuni töösuhte lõppemiseni.

10.04.2024

Riho Pihelpuu /allkirjastatud digitaalselt/

ADM Interactive OÜ

Juhatuse liige

Hankeleping nr 2/40-25

Hankelepingu eritingimused

Tallinnas

Registrite ja Infosüsteemide Keskus, (registrikoodiga 70000310) asukohaga Lubja 4, 19081 Tallinn,

mida esindab põhimääruse alusel direktor Rivo Reitmann, edaspidi Tellija,

ja

ADM Interactive OÜ (registrikoodiga10474271)asukohaga Kursi tn 3, 10415 Tallinn, mida esindab

volikirja alusel Hendrek Kraavi, edaspidi Täitja,

ja

Riigikohus (registrikoodiga 74001127)asukohaga Lossi 17, Tartu 50093, Eesti, mida esindab kodukorra

alusel Üllar Kaljumäe, edaspidi Maksja,

keda nimetatakse edaspidi pool või koos pooled, sõlmisid käesoleva arenduslepingu (edaspidi nimetatud

Leping) alljärgnevas:

1. Lepingu sõlmimise alus ja ese

1.1. Vastavalt riigihanke „Drupal veebilehtede arendus- ja hooldustööd“ (viitenumber 285000) tulemusel

sõlmitud raamlepingu nr 2/55-24 alusel esitatud pakkumuse täpsustusele teostab täitja Lepingu lisas 3

mainitud tööd ja täidab kõik muud Lepingust tulenevad kohustused (edaspidi ka Töö).

1.2. Pooled kinnitavad, et teevad kõik enesest oleneva, et täita lepingu eesmärgid käesolevas lepingus,

seonduvates õigusaktides sätestatud tingimustes ja mahus.

2. Hind ja maksetingimused

2.1. Lepingu hind on 34860,00 eurot (netosumma), arvestusega, et arendustööde tunnihind on 30,00 eurot

(netosumma).

2.3. Maksja tasub lepingu alusel teostatud tööde eest lepingu üldtingimustes sätestatud korras.

3. Lepingu jõustumine ja Töö teostamise tähtaeg

3.1 Leping jõustub allkirjastamise hetkest ja kehtib kuni lepingujärgsete kohustuste nõuetekohase

täitmiseni.

3.2 Töö teostamise tähtaeg on 6 kuud arvates Lepingu jõustumise ajahetkest.

4. Lepingu dokumendid

4.1 Lepingu dokumendid koosnevad Lepingu tekstist, Lepingu lisadest, mis on lisatud Lepingu

allkirjastamisel ja lisadest, millistes võidakse kokku leppida pärast Lepingu allkirjastamist.

Lepingu allkirjastamisel on Lepingu lisad järgmised:

4.1.1 Arenduslepingu üldtingimused Lisa nr 1;

4.1.2 Personal ja kontaktandmed Lisa nr 2;

4.1.3 Tehniline kirjeldus Lisa nr 3;

4.1.4 Pakkumus Lisa nr 4;

4.1.5 Maksegraafik Lisa nr 5.

4.2 Kui Lepingu dokumendid on oma sisult vastuolulised ja/või nendes antud informatsioon erinevalt

tõlgendatav, siis dokumentide pädevusjärjekord (ülimuslik lepingu dokument on nimetatud eespool

allolevas loetelus) on järgmine:

4.2.1 Eritingimused;

4.2.2 Arenduslepingu üldtingimused;

4.2.3 Tehniline kirjeldus;

4.2.4 Muud riigihanke alusdokumendid;

4.2.5 Pakkumus.

Käesoleva Lepingu allakirjutamisega tõendavad pooled, et on tutvunud ja on nõus Lepinguga ja selle

lisadega ning mõistavad täielikult enesele võetavate kohustuste sisu ning nende tagajärgi.

Tellija: Täitja: Maksja:

/ allkirjastatud

digitaalselt /

/ allkirjastatud

digitaalselt /

/allkirjastatud

digitaalselt/

Rivo Reitmann Hendrek Kraavi Üllar Kaljumäe

Direktor

Registrite ja

Infosüsteemide

Keskus

ADM Interactive OÜ Riigikohtu direktor

Riigikohus

Hankeleping nr 2/40-25

Lisa nr 2

PERSONAL JA KONTAKTANDMED

1. Tellija esindaja ja kontaktisikud

1.1. Tellija esindajaks tööde vastuvõtmise aktide, teadete jms lepinguga seonduvate dokumentide

allkirjastamisel on Registrite ja Infosüsteemide Keskuse tugiinfosüsteemide tiimi tiimijuht Vesta

Laansoo (tel 510 3196, e-post: [email protected]).

1.2. Tellija kontaktisikuks tööde teostamise juhendamisel ning Täitjale vajaliku lähteinformatsiooni ja

tööülesannete täpsustamisel jmt. on Registrite ja Infosüsteemide Keskuse tugiinfosüsteemide tiimi

ärianalüütik Maarja Ottis (tel 5830 3389, e-post: [email protected]).

2. Täitja esindaja ja kontaktisikud

2.1 Täitja esindajaks on volikirja alusel Hendrek Kraavi.

2.2 Täitja kontaktisikuteks on tiimijuht Tõnis Muuga (tel +372 5596 6981, e-post: [email protected]) ja

projektijuht Jana Korberg (tel +37253670101, e-post: [email protected]).

3. Personali nimekiri

3.1. Tellija personal

Nr. Nimi Ametinimetus Kontaktandmed

1. Risto Uustal Riigikohtu õigusteabe nõunik 5401 1344

2. Mart Koppel Riigikohtu IT osakonna juhataja 523 4334

3. Margo Munner RIK Infosüsteemi haldur 5899 8353

3.2. Täitja personal

Nr. Nimi Ametinimetus Kontaktandmed

1. Märt Rang arendaja +372 56159712,

[email protected]

2. Gerda Põdder projektijuht +372 56703809,

[email protected]

3. Katre Rodima testija +372 57863717,

[email protected]

4. Martin Jüriska UI/UX disainer +372 53635138,

[email protected]

4. Kontaktandmed

4.1. Tellija kontaktandmed on: 4.2. Täitja kontaktandmed on:

Registrite ja Infosüsteemide Keskus ADM Interactive OÜ

Reg. nr. 70000310 Registrikood 10474271

Lubja tn 4 Kursi tn 3

19081 TALLINN 10415 TALLINN

Telefon: 663 6300 Telefon: 617 7600

Hankeleping nr 2/40-25

Lisa nr 5

MAKSEGRAAFIK

1. Lepingu hind

1.1 Lepingu hind on 34 860,00eurot. Hinnale lisandub käibemaks.

1.2. Lepingu kogumaksumus tasutakse kahes etapis vastavalt pakkumuse projektiplaanile.

Töö nimetus Üleandmise tähtaeg Hind (KM-ta)

Makse 1 I etapp (protsesside ja

kasutajateekondade kaardistus

ning analüüs, tehnilise

lahenduse ja arhitektuuri

analüüs)

2 kuud arvestades

lepingu allkirjastamisest.

14550,00 eurot

Makse 2 II etapp (front-end ja back-end

arenduses veebilehe

realiseerimine tuginedes

analüüsi etapis saadud

sisendile)

6 kuud arvestades

lepingu allkirjastamisest

20310,00 eurot

KOKKU 34860,00 eurot

Hankeleping nr 2/40-25

Lisa nr 1

HANKELEPINGU ÜLDTINGIMUSED

1. Üldosa

1.1 Üldtingimused on riigihanke „Drupal veebilehtede arendus- ja hooldustööd“ (viitenumber 285000)

alusel sõlmitud raamlepingu lisaks ning raamlepingu alt teostatavate tehingute lahutamatuks osaks.

1.2 Pooled võivad hankelepingu eritingimustes kokku leppida üldtingimustes käsitlemata või üldtingimusi

täpsustavates küsimustes, samuti erisusi üldtingimustest, kuid nende puudumisel kohaldatakse

üldtingimusi. Üldtingimuste ja eritingimustes sisalduvate sätete vastuolu korral, loetakse ülimuslikuks

eritingimustes sätestatu.

2. Definitsioonid

Järgnevad definitsioonid laienevad nii lepingule kui ka selle osaks olevatele dokumentidele.

2.1 Tarkvara

Tarkvara tähendab põhiliselt arvutiprogramme, telekommunikatsioone, andmebaasi-, rakendus- ja muud

tarkvara objektikoodis, lähtekoodis või nende mistahes muid vorme või adaptsioone koos sellega seonduva

dokumentatsiooniga. Spetsiaalselt Tellijale tema funktsioonide täitmiseks loodud tarkvara käsitletakse

lepingu raames spetsiaaltarkvarana.

2.2 Seadmed

Seadmed tähendavad lepingus kirjeldatud tooteid, hõlmates nendega otseselt seotud tarkvara, mis on

vajalik seadmete funktsioneerimiseks.

2.3 Telekommunikatsioonid

Telekommunikatsioonid tähendavad sisemise ja välise telekommunikatsiooni seadmeid, tarkvara ja

teenuseid ning vajalikke vahendeid, teenuseid ja protseduure.

2.4 Asukoht

Asukoht tähendab kohta või kohti, välja arvatud Täitja asukoht, kuhu seadmeid, telekommunikatsioone või

tarkvara tarnitakse või installeeritakse või teenuseid osutatakse (nt Tellija test- arendus-ja

toodangukeskkond).

2.5 Puudus ja viga

Puuduse või veaga on tegemist juhul, kui seade, telekommunikatsioon või tarkvara ei täida lepingus

sätestatud funktsioone, annab valesid tulemusi, kui tema nõuetekohane toimimine katkeb või on (muul

viisil) häiritud, nii et seadme, telekommunikatsiooni või tarkvara otstarbekohane kasutamine on takistatud

või oluliselt häiritud. Vigu liigitatakse järgnevalt:

2.5.1 Kriitiline/Blocker – viga, mille tõttu süsteemi tervikuna või mistahes süsteemi osa ei ole võimalik

kasutada ja/või see piirab sama süsteemi mistahes teise osa kasutamist.

2.5.2 Kõrge – viga, mille tõttu pole võimalik mingit süsteemi osa kasutada, kuid see ei sega mõne

teist sama süsteemi osa kasutamast.

2.5.3 Keskmine – viga, mille tõttu süsteemi või selle süsteemi mõnda osa on võimalik kasutada

piirangutega ja/või kasutajad peavad tegema mitte ettenähtud tegevusi eesmärgi

saavutamiseks (nt. funktsionaalsus lubab vigadega toiminguid lõpetada).

2.5.4 Madal – viga, mille tõttu süsteemis esineb kõrvalekaldeid ettenähtust, kuid üldprotsessi need ei

häiri või häirivad vähesel määral.

2.5.5 Väheoluline - viga, mille tõttu otseseid kõrvalekaldeid ei teki kuid vajavad

muutmist/parandamist.

2.6 Hooldustööd

Hooldus tähendab töid, mis tagavad seadmete, telekommunikatsioonide ja tarkvara (kaasa arvatud nende

juurde kuuluvate andmete ja andmebaaside) toimivuse (korrasoleku, terviklikkuse, jõudluse jms). Hooldus

sisaldab kaugtuge, vigade ennetamist ja parandamist, uute redaktsioonide ja versioonide ning nendega

seotud dokumentatsiooni üleandmist. Samuti hõlmab hooldus lepingus sätestatud tingimustel seadmete,

telekommunikatsioonide ja tarkvara kohandamist Tellija vajadustele, eeldusel, et see ei nõua olulist

ümberprogrammeerimist ega uue toote loomist.

2.7 Arendustööd

Arendustööd tähendavad Drupal veebilehtede funktsionaalsuse parandamise ja täiendamise ning teenuse

arendamisega seonduvaid töid. Arendustööd sisaldavad endas tehnilist konsultatsiooni, süsteemi- ja

detailanalüüsi läbiviimist, programmeerimistöid, testimist, dokumentatsiooni koostamist ja vajadusel

koolitusi.

2.8 Toodangukeskkond

Reaalseks andmevahetuseks mõeldud keskkond, mis ei ole test- või arenduskeskkond.

3. Hind

3.1 Lepingu hind sisaldab kõiki tolli- ja muid makse, kaasa arvatud käibemaks. Lepingu eritingimustes

märgitakse Lepingu hind netosummana (käibemaksuta).

3.2 Lepingu hind väljendatakse eurodes.

3.3 Lepingu hind on Täitja ainuke tasu seoses lepinguga ja Täitja ise ega tema töötajad ei võta

päevarahasid, kaudset tasu ega muud lepingus toodud kohustustega seotud tasu. Samuti ei ole

Täitjal ega tema töötajal õigust täiendavale autori- või muule sarnasele tasule seoses lepingu

täitmisel kasutatud patenteeritud või muul viisil kaitstud eseme või protsessiga.

4. Maksmine

4.1 Täitja esitab Tellijale/Maksjale arve masinloetaval kujul e-arvena. Arve esitamise õigus tekib Täitjal

pärast Töö vastuvõtmist Tellija poolt.

4.2 Arve peab sisaldama vähemalt alljärgnevaid andmeid:

4.2.1 info arve esitaja kohta;

4.2.2 info maksja kohta;

4.2.3 viide Lepingule;

4.2.4 käibemaksukohustuslase number;

4.2.5 vastuvõetud Töö nimetus ja kirjeldus;

4.2.6 käibemaks;

4.2.7 kogusumma;

4.3 Tellija/Maksja tasub Lepingu hinna Täitja poolt esitatud arvel märgitud kuupäevaks. Maksetähtaeg ei

tohi olla lühem kui 30 kalendripäeva, va juhul kui hankija on nimetatut pakkumuse esitamise

ettepanekus ette näinud.

4.4 Ettemakseid Tellija/Maksja ei teosta.

4.5 Lõpparve maksmine eeldab Täitja kõigi Lepingu järgsete kohustuste täitmist ning Tellija poolt

vastuvõtmist.

4.6 Tellijal/Maksjal on õigus Lepingu rikkumise korral arvestatud leppetrahvid ja kahju hüvitised maha

arvata Lepingu alusel Täitjale tasumisele kuuluvatest summadest.

4.7 Tellija/Maksja poolt makstud mistahes summa, mis ületab Täitjale Lepingus ettenähtu, maksab Täitja

Tellijale/Maksjale tagasi 30 kalendripäeva jooksul pärast vastava teate saamist.

4.8 Lepingujärgse hinna tasumisega viivitamisel on Täitjal õigus nõuda viivist iga maksmisega viivitatud

kalendripäeva eest 0,15 (null koma viisteist) % maksmata summast päevas.

5. Informatsioon ja aruanded

5.1 Täitja loetakse asukohaga ja lepingu tingimustega tutvunuks. Eelkõige ei rahuldata Täitja nõuet

lisamakseteks või ajapikenduseks, kui ta oleks saanud vajaliku informatsiooni hankida visiidiga

asukohta, konsulteerides Tellijaga või muul sobilikul viisil.

5.2 Tellija varustab Täitjat tema käsutuses oleva mistahes informatsiooni ja dokumentatsiooniga, mis võib

olla lepingu täitmisel oluline, niipea kui võimalik, kuid mitte hiljem kui 2 tööpäeva jooksul vastava

nõude saamisest.

5.3 Tellija abistab Täitjat niipalju kui võimalik lepingusse puutuva informatsiooni saamisel, mida Täitja

mõistlikkuse piirides lepingu täitmiseks nõuab.

5.4 Täitja annab Tellijale niipea kui võimalik, kuid mitte hiljem kui 2 tööpäeva jooksul vastava nõude

saamisest, lepingu täitmist (sealhulgas seadmeid, telekommunikatsioone, tarkvara, projekti kulgemist

ja teenuseid) puudutavat informatsiooni.

6. Teated ja kirjavahetus

6.1 Pooltevaheline suhtlus toimub selleks otstarbeks määratud poolte kontaktandmetel ja aadressidel.

Pooled on kohustatud kontaktandmete ja aadresside muutusest teineteist teavitama viivitamatult, aga

mitte hiljem kui 2 tööpäeva jooksul.

6.2 Kui teisele poolele edastatav teade eeldab vastust, tuleb vastata viivitamatult, kuid mitte hiljem kui 2

tööpäeva jooksul.

6.3 Pooltevahelised Lepinguga seotud teated peavad olema kirjalikku taasesitamist võimaldavas vormis,

välja arvatud juhtudel, kui teated on informatsioonilise iseloomuga, mille edastamisel teisele poolele

ei ole õiguslikke tagajärgi. Teade loetakse kättesaaduks, kui:

6.3.1 teade on üle antud allkirja vastu;

6.3.2 teade on edastatud tähitud kirjana poole postiaadressil ja teate postitamisest on möödunud 5

(viis) kalendripäeva;

6.3.3 e-posti või telefoni teel on teade edastatud Lepingus märgitud kontaktisikule või esindajale.

7. Asukoht

7.1 Täitja peab andma lepingutäitmise käigus piisavalt informatsiooni korrektselt kirjalikku taasesitamist

võimaldavas vormis koostatud kasutusjuhendi näol, et võimaldada Tellijal asukoht lepingujärgsete

kohustuste täitmiseks kohaselt ette valmistada. Juhend peab olema antud sellise sisendiga, et

objektiivselt keskmise võimekusega programmeerija oleks suuteline asukoha Töö vastuvõtmiseks

vajalike testide teostamiseks ette valmistada. Juhend peab olema esitatud piisava ajavaruga selleks,

et Tellijal oleks võimalik Töö üleandmisel alustada koheselt vastuvõtmiseks vajalike testide

teostamist. Juhul, kui Töö üleandmise hetkeks ei ole juhendit edastatud või kui edastamisest

hoolimata ei ole Tellija asukohta ette valmistada jõudnud, algab Töö vastuvõtmiseks ette nähtud

tähtaeg kulgema pärast asukoha ette valmistamist. Kui Täitja ei ole ette näinud erilisi

keskkonnatingimusi, võib Tellija eeldada, et neid ei nõuta.

7.2 Tellija teeb vastavad ettevalmistused ja loob tingimused omal kulul.

7.3 Kui Tellija ettevalmistused või loodud tingimused ei vasta lepingus sätestatule, esitab Täitja

viivitamatult puuduste loetelu. Kui Tellija ei muuda olukorda selliselt, et Täitjal oleks võimalik

ajagraafikust kinni pidada, on Täitjal õigus saada lepingujärgsete kohustuste täitmiseks vajalikku

ajapikendust.

7.4 Täitjal on õigus taotleda juurdepääsu asukohale Tellija tavalisel tööajal.

7.5 Täitja kulud, mis on seotud lepingus sätestatud juurdepääsupiirangutega ja turvaprotseduuridega,

sisalduvad Lepingu hinnas ning neid ei hüvitata.

7.6 Tellija võib igal ajal lepingu kehtivuse vältel muuta või kehtestada juurdepääsupiiranguid ja

turvaprotseduure. Kui Täitja tõendab, et selline muudatuste tegemine või piirangute või protseduuride

kehtestamine põhjustas lisakulusid, on tal õigus nende hüvitamisele.

8. Lepingu muutmine

8.1 Lepingut võib muuta poolte kirjalikul kokkuleppel. Muudatused jõustuvad pärast nende allkirjastamist

mõlema poole poolt või poolte poolt määratud tähtajal. Kirjaliku vormi mittejärgimisel on muudatused

tühised.

8.2 Riigihangete seaduse § 123 lg 1 p 1 kirjeldatud muudatused lepitakse kokku Tellija ja Täitja esindajate

poolt kirjalikku taasesitamist võimaldavas vormis.

9. Poolte õiguskaitsevahendid

9.1 Lepingu see peatükk fikseerib Lepingu olulised rikkumised, menetluse rikkumisest teatamisel ning

Poolte vastutuse. See peatükk ei välista ega piira Poole õigust kasutada muude Lepingu rikkumiste

korral muid õigusaktidest tulenevaid õiguskaitsevahendeid, samuti kasutada täiendavaid

õiguskaitsevahendeid lisaks selles peatükis kokkulepitule.

9.2 Lepingust või seadusest tuleneva õiguse või õiguskaitsevahendi mittekasutamine või selle

kasutamisega viivitamine ei tähenda nimetatud õigusest või õiguskaitsevahendist või muudest

õigustest või õiguskaitsevahenditest loobumist. Lepinguga seotud mis tahes loobumised on kehtivad

ainult siis, kui need on selgesõnaliselt ja kirjalikult väljendatud.

9.3 Pooled vastutavad Lepinguga võetud kohustuste täitmata jätmise või mittekohase täitmise eest Eesti

Vabariigi õigusaktides ning Lepingus ettenähtud korras.

9.4 Oluliseks lepingurikkumiseks loetakse muu hulgas järgmisi rikkumisi:

9.4.1 Pool ei täida mis tahes Lepingust tulenevat kohustust teise Poole poolt Lepingust tuleneva

vastava kohustuse täitmiseks antud täiendava tähtaja jooksul;

9.4.2 Täitja ei täida garantiiperioodil Lepingust tulenevaid kohustusi;

9.4.3 Täitja ei ole esitanud Tellijale Asukoha keskkonnatingimusi, millest tulenevalt on häiritud Tellija

seadmete, telekommunikatsioonide või tarkvara kohane funktsioneerimine ning mistõttu Tellija

kaotab Täitja Lepingu järgsete kohustuste täitmise vastu huvi;

9.4.4 Täitja rikkus kohustust tahtlikult või raske hooletuse tõttu;

9.4.5 Täitja rikub Personaliga seonduvaid tingimusi;

9.4.6 Poolel või tema poolt kaasatud kolmandal isikul puuduvad Lepingu täitmiseks vajalikud õigused

(sealhulgas load, litsentsid, Intellektuaalse omandi õigused);

9.4.7 Täitja suhtes on algatatud pankrotimenetlus, pankrot on välja kuulutatud, Täitja varad

arestitakse või Täitja finantsseisund halveneb Tellija põhjendatud hinnangul oluliselt ja see

halvenemine muudab vähetõenäoliseks Lepingu nõuetekohase täitmise;

9.4.8 Pool on rikkunud Intellektuaalse omandi õigusi ja nende kasutamise tingimusi;

9.4.9 Pool on rikkunud konfidentsiaalsuskohustust ja/või isikuandmete töötlemisega seonduvaid

kohustusi;

9.4.10 Pool on rikkunud avalikustamise keelu kohustust;

9.4.11 Pool on rikkunud kolmandate isikutega seonduvaid kohustusi;

9.4.12 Tellija/Maksja on viivituses Lepingus kokku lepitud maksetähtajaga rohkem kui kolmkümmend

(30) kalendripäeva;

9.5 Poolel on õigus nõuda Lepingu olulise rikkumise korral leppetrahvi tasumist kuni 30% Lepingu hinnast

iga vastava juhtumi korral. Juhul, kui leppetrahvi nõue on seotud Töö etapi puuduliku teostamisega

ja puudus ei sea ohtu lepingujärgse Töö tervikuna nõuetekohast üleandmist ei tohi leppetrahvi nõue

ületada 30% teostatud või töös oleva etapi maksumusest.

9.6 Poolte rahaline koguvastutus on piiratud Lepingu maksumusega, välja arvatud juhul, kui Pool rikkus

kohustust tahtlikult või raske hooletuse tõttu.

9.7 Pool peab teavitama teist Poolt leppetrahvi nõudest mõistliku aja jooksul arvates ajast, mil ta sai

teada leppetrahvi nõudmise õiguse tekkimisest. Leppetrahvi nõude esitamisel on Pool kohustatud

märkima mõistliku tähtaja leppetrahvi tasumiseks, tähtaeg ei tohi olla lühem kui 30 kalendripäeva.

Pool on kohustatud leppetrahvi tasuma nõudes märgitud tähtaja jooksul. Kui Poole hinnangul on

leppetrahvi nõue alusetu, on Pool kohustatud esitama oma vastuväited enne leppetrahvi tasumise

tähtaega. Leppetrahvi nõudmine ei mõjuta Poole õigust nõuda Poolelt nõuetekohase Töö või selle

osa teostamist ning kahju hüvitamist või kasutada muid seadusest tulenevaid õiguskaitsevahendeid.

9.8 Lisaks leppetrahvi nõudele ja / või leppetrahvi asemel on Tellijal õigus nõuda Täitjalt Lepingu

mittenõuetekohasel täitmisel, et:

9.8.1 Täitja kõrvaldaks puudused, sealhulgas nõuda, et Täitja hangiks parema teenuse osutamiseks

vajalikud lisa- või asendusseadmed, -telekommunikatsioonid, -tarkvara ja teenused;

9.8.2 oluliste puuduste, samuti puuduste kõrvaldamise ebaõnnestumise korral nõuda, et Täitja teeks

uue Töö ja tarniks uued seadmed, telekommunikatsioonid ja tarkvara või keelduda

vastuvõtmisest ning Leping lõpetada;

9.8.3 võtta Täitja pakutud Töö vastu ning alandada vastavalt hinda;

9.9 Lepingust tulenevate leppetrahvide maksmine, samuti tekitatud kahju hüvitamine, ei vabasta

Lepingut rikkunud poolt Lepingujärgsete kohustuste täitmisest.

10. Standardid, liidesed ja ühilduvus

10.1 Täitja lepingujärgsete kohustuste täitmine ei tohi tekitada häireid Tellija mistahes teiste liidestatud

süsteemide talitluses.

10.2 Täitja garanteerib, et kõik seadmed, telekommunikatsioonid, tarkvara ja teenused on vastastikku

ühilduvad, funktsioneerivad ja töötavad standardite ja/või liideste vahendusel rahuldavalt koos

mistahes teiste lepingus sätestatud seadmete, telekommunikatsioonide, tarkvara ja teenustega ning

lepingus sätestatud keskkonnas.

10.3 Täitja ei muuda ilma Tellija eelneva kirjaliku nõusolekuta mistahes standardeid, liideseid,

sideprotokolle jms.

11. Dokumentatsioon

11.1 Lepingu täitmisel kaasneva dokumentatsiooni loomisel toetutakse dokumentatsiooniplaanile.

11.2 Täitja varustab Tellijat piisava ja adekvaatse dokumentatsiooniga, kaasa arvatud informatsioon

seadmete, telekommunikatsioonide ja tarkvara projekteerimise ja funktsioneerimise kohta, mis on

vajalik, et Tellija saaks seadmeid, telekommunikatsioone, tarkvara ja teenuseid efektiivselt kasutada,

hooldada, kohandada ja neile lisaseadmeid lisada.

11.3 Kõik juhendid ja muud dokumendid esitatakse eesti keeles, kui ei ole kokku lepitud teisiti.

11.4 Dokumentatsioon peab vastama tootele, sisaldama muudatusi ja olema terminoloogiliselt üheselt

mõistetav.

11.5 Dokumentide valmistamiseks ja levitamiseks kasutatakse paberkandjat või elektroonilist infokandjat.

12. Üleandmine ja vastuvõtmine

12.1 Hooldustööde üleandmine ja vastuvõtmine:

12.1.1 Hooldustööd valmimise järgselt annab Täitja selle Tellijale üle vastuvõtmiseks.

12.1.2 Täitja peab Tellijat Hooldustöö üle andmise viivitusest või viivitusse sattumise ohust ja

põhjustest koheselt kirjalikku taasesitamist võimaldavas vormis informeerima. Kui Täitja

viivituse põhjustab Tellija, on Täitjal õigus nõuda mõistlikku ajapikendust ja põhjendatud

lisakulude hüvitamist.

12.1.3 Hooldustöö üleandmise kohta koostab Täitja üleandmise akti, milles näidatakse muuhulgas ära

üleandmise kuupäev, teostatud Töö, osutatud teenuste, hoolduse ja tarnitud seadmete,

telekommunikatsioonide ja tarkvara detailiseeritud nimekiri ning vajaduse korral neis esinevad

puudused. Iga Töö etapi üleandmisel koostab ja esitab Täitja antud etapi kohta koostatud

dokumentatsiooni, vastavalt dokumentatsiooniplaanile või Tellija poolt tehnilises kirjelduses

esitatud nõudmistele.

12.1.4 Hooldustöö üleandmine Tellijale ei ole käsitatav selle vastuvõtmisena Tellija poolt.

12.1.5 Täitjal on õigus nõuda ja Tellijal kohustus Töö vatsu võtta kui Hooldustöös on Täitja poolt

kõrvaldatud kõik järgmise prioriteediga vead: kriitiline/blocker, kõrge ja keskmine. Taolisel juhul

lasub Täitjal kohustus vaegtöödena madala ja väheolulise tähtsusega vead parandada

Hooldustöö vastuvõtmise aktis toodud ajaperioodiks.

12.1.6 Pärast Hooldustöö üleandmist on Tellijal õigus Töö üle vaadata 20 tööpäeva jooksul.

12.1.7 Juhul, kui Tellija leiab, et Hooldustöö ei vasta Lepingu tingimustele, on Tellija kohustatud

teavitama Täitjat Hooldustöös avastatud puudustest, keeldumisest Hooldustööd enne puuduste

kõrvaldamist vastu võtta ja kirjeldama Hooldustöö puudused. Täitja on kohustatud puudused

kõrvaldama 5 tööpäeva jooksul, kui pooled ei ole kokku leppinud mõnda muud tähtaega.

Hooldustöö puuduste kõrvaldamise kulud kannab Täitja.

12.1.8 Enne Hooldustöö üleandmist viib Täitja Hooldustöö nõuetelevastavuse kindlakstegemiseks läbi

testid.

12.1.9 Täitja esitab Tellijale kõik tema poolt läbiviidud testide tulemusena valminud dokumentide

koopiad.

12.1.10 Enne Hooldustöö vastuvõtmist viib Tellija Hooldustöö nõuetelevastavuse kindlakstegemiseks

läbi testid.

12.1.11 Kui Hooldustöö või mistahes Hooldustöö osa ei läbi teste, viiakse otsekohe pärast seda, kui

Täitja on teinud vajalikud korrektuurid testide edukaks läbiviimiseks, läbi kordustestid samadel

tingimustel.

12.1.12 Tellija nõudmisel viib kordustestid läbi Täitja.

12.1.13 Parandatud Hooldustöö üleandmine toimub nagu esmakordsel üleandmiselgi.

12.1.14 Puudustega üle antud Hooldustööd ei loeta tähtaegselt üleantuks ning Tellijal on õigus nõuda

sellise lepingurikkumise korral Täitjalt leppetrahvi Lepingus sätestatud korras ja määrades või

rakendada muid õiguskaitsevahendeid.

12.1.15 Vastuvõtmiseks valmis Hooldustöö peab vastama Lepingus sätestatud tingimustele. Töö etapi

vastuvõtmine Tellija poolt ei tingi ega kohusta Töö kui terviku vastuvõtmist Tellija poolt juhul,

kui Töö ei vasta tingimustele. Hooldustöö vastuvõtmise kohta koostab Tellija vastuvõtuakti,

milles näidatakse muuhulgas ära vastuvõtmise kuupäev, teostatud Hooldustöö, osutatud

teenuste, hoolduse ja tarnitud seadmete, telekommunikatsioonide ja tarkvara detailiseeritud

nimekiri.

12.1.16 Hooldustöö loetakse vastuvõetuks vastuvõtuakti allkirjastamisest või toodangukeskkonnas

kasutusele võtmisest. Juhul, kui Tellija on võtnud puuduseid sisaldava Hooldustöö

toodangukeskkonnas kasutusele, loetakse vastuvõetuks ainult nõuetekohaselt teostatud tööd

ja Täitjal on õigus nimetatute osas esitada arve. Taolises olukorras esitab Tellija Täitjale

Hooldustöös esinevate puuduste nimekirja ning puuduste kõrvaldamise tähtaja, kas enne

Hooldustöö toodangukeskkonnas kasutusele võtmist või vahetult pärast selle toimumist.

12.1.17 Mistahes seadmete, telekommunikatsioonide, tarkvara ja teenuste osa valmimisel võib Tellija

anda välja vastuvõtuakti vastava osa kohta. Selline vastuvõtmine ei mõjuta Täitja kohustust

täita kõiki Lepingus ettenähtud kohustusi.

12.1.18 Täitja vastutab Hooldustöö juhusliku hävimise või kahjustumise eest kuni Hooldustöö

vastuvõtmiseni Tellija poolt.

12.2 Arendustööde üleandmine ja vastuvõtmine:

12.2.1 Arendustöö või arendustöö etapi valmimise järgselt annab Täitja selle Tellijale üle

vastuvõtmiseks.

12.2.2 Täitja peab Tellijat Töö või Töö etapi üle andmise viivitusest või viivitusse sattumise ohust ja

põhjustest koheselt kirjalikku taasesitamist võimaldavas vormis informeerima. Kui Täitja

viivituse põhjustab Tellija, on Täitjal õigus nõuda mõistlikku ajapikendust ja põhjendatud

lisakulude hüvitamist.

12.2.3 Töö või Töö etapi üleandmise kohta koostab Täitja üleandmise akti, milles näidatakse

muuhulgas ära üleandmise kuupäev, teostatud Töö, osutatud teenuste, hoolduse ja tarnitud

seadmete, telekommunikatsioonide ja tarkvara detailiseeritud nimekiri ning vajaduse korral neis

esinevad puudused. Iga Töö etapi üleandmisel koostab ja esitab Täitja antud etapi kohta

koostatud dokumentatsiooni, vastavalt dokumentatsiooniplaanile või Tellija poolt tehnilises

kirjelduses esitatud nõudmistele.

12.2.4 Töö või Töö etapi üleandmine Tellijale ei ole käsitatav selle vastuvõtmisena Tellija poolt.

12.2.5 Täitjal on õigus nõuda ja Tellijal kohustus Töö vatsu võtta kui Töös on Täitja poolt kõrvaldatud

kõik järgmise prioriteediga vead: kriitiline/blocker, kõrge ja keskmine. Taolisel juhul lasub Täitjal

kohustus vaegtöödena madala ja väheolulise tähtsusega vead parandada Töö vastuvõtmise

aktis toodud ajaperioodiks.

12.2.6 Pärast Töö etapi üleandmist on Tellijal õigus Töö üle vaadata 10 tööpäeva jooksul. Pärast Töö

üleandmist on Tellijal õigus Töö üle vaadata 20 tööpäeva jooksul.

12.2.7 Juhul, kui Tellija leiab, et Töö ei vasta Lepingu tingimustele, on Tellija kohustatud teavitama

Täitjat Töös avastatud puudustest, keeldumisest Tööd enne puuduste kõrvaldamist vastu võtta

ja kirjeldama Töö puudused. Täitja on kohustatud puudused kõrvaldama 5 tööpäeva jooksul,

kui pooled ei ole kokku leppinud mõnda muud tähtaega. Töö puuduste kõrvaldamise kulud

kannab Täitja.

12.2.8 Enne töö üleandmist viib Täitja Töö nõuetelevastavuse kindlakstegemiseks läbi testid.

12.2.9 Täitja esitab Tellijale kõik tema poolt läbiviidud testide tulemusena valminud dokumentide

koopiad.

12.2.10 Enne töö vastuvõtmist viib Tellija Töö nõuetelevastavuse kindlakstegemiseks läbi testid.

12.2.11 Kui Töö või mistahes Töö osa ei läbi teste, viiakse otsekohe pärast seda, kui Täitja on teinud

vajalikud korrektuurid testide edukaks läbiviimiseks, läbi kordustestid samadel tingimustel.

12.2.12 Tellija nõudmisel viib kordustestid läbi Täitja.

12.2.13 Parandatud Töö üleandmine toimub nagu esmakordsel üleandmiselgi.

12.2.14 Puudustega üle antud Tööd ei loeta tähtaegselt üleantuks ning Tellijal on õigus nõuda sellise

lepingurikkumise korral Täitjalt leppetrahvi Lepingus sätestatud korras ja määrades või

rakendada muid õiguskaitsevahendeid.

12.2.15 Vastuvõtmiseks valmis Töö peab vastama Lepingus sätestatud tingimustele. Töö etapi

vastuvõtmine Tellija poolt ei tingi ega kohusta Töö kui terviku vastuvõtmist Tellija poolt juhul,

kui Töö ei vasta tingimustele. Töö vastuvõtmise kohta koostab Tellija vastuvõtuakti, milles

näidatakse muuhulgas ära vastuvõtmise kuupäev, teostatud Töö, osutatud teenuste, hoolduse

ja tarnitud seadmete, telekommunikatsioonide ja tarkvara detailiseeritud nimekiri.

12.2.16 Töö või Töö etapp loetakse vastuvõetuks vastuvõtuakti allkirjastamisest või

toodangukeskkonnas kasutusele võtmisest. Juhul, kui Tellija on võtnud puuduseid sisaldava

Töö või Töö etapi toodangukeskkonnas kasutusele, loetakse vastuvõetuks ainult

nõuetekohaselt teostatud tööd ja Täitjal on õigus nimetatute osas esitada arve. Taolises

olukorras esitab Tellija Täitjale Töös või Töö etapis esinevate puuduste nimekirja ning puuduste

kõrvaldamise tähtaja, kas enne Töö või Töö etapi toodangukeskkonnas kasutusele võtmist või

vahetult pärast selle toimumist.

12.2.17 Mistahes seadmete, telekommunikatsioonide, tarkvara ja teenuste osa valmimisel võib Tellija

anda välja vastuvõtuakti vastava osa kohta. Selline vastuvõtmine ei mõjuta Täitja kohustust

täita kõiki Lepingus ettenähtud kohustusi.

12.2.18 Täitja vastutab Töö juhusliku hävimise või kahjustumise eest kuni Töö vastuvõtmiseni Tellija

poolt.

13. Koolitus

13.1 Täitja tagab Tellija personalile adekvaatse väljaõppe, kindlustamaks seadmete,

telekommunikatsioonide, tarkvara ja teenuste rahuldava ja efektiivse toimimise, vastavalt Lepingus

kokkulepitule.

13.2 Koolituse toimumise aeg, koht ja maht kooskõlastatakse eelnevalt Tellija kontaktisikuga.

14. Garantii

14.1 Täitja annab arendustöödele 12 (kaheteist) kuulise ning hooldustöödele 6 (kuue) kuulise

töövõtugarantii. Garantiiperiood algab Tööde kogumina vastuvõtmisest.

14.2 Garantiiperioodil ilmnevad puudused kõrvaldab Täitja omal kulul, v.a punktis 14.6 toodud juhtumitel.

Kui ilmnenud puudused ei ole garantii korras kõrvaldatavad, esitab Täitja Tellijale põhjendused

kirjalikku taasesitamist võimaldavas vormis, kuid mitte hiljem kui järgmisel tööpäeval pärast sellest

asjaolust teada saamist.

14.3 Kui ei ole kokku lepitud teisiti, toimub garantiiliste puuduste üleandmine ja vastuvõtmine Lepingu

punktis 10 toodud regulatsiooni kohaselt.

14.4 Juhul kui garantiiperioodil ilmnenud puudused muudavad osa või kõik seadmed,

telekommunikatsioonid ja/või tarkvara kasutamiskõlbmatuks, varustab Täitja Tellijat nõutud tasemel

toimimise garanteerivate lisa- või asendusosade ja muu vajalikuga omal kulul.

14.5 Tellija informeerib Täitjat puuduse iseloomust ja ulatusest otsekohe selle ilmnemisel. Täitja on

kohustatud eemaldama ilmnenud puudused vastavalt lepingus toodule või Tellija poolt määratud ajal.

14.6 Garantiiga ei ole hõlmatud:

14.6.1 puudused, mille tekkimise eest vastutab Tellija;

14.6.2 diagnostikaks kulunud aeg, juhul kui algselt garantii juhtumine registreeritud juhtumi raames

tuvastatakse, et tegu ei ole garantiilise juhtumiga. Vastav töö kuulub eraldi tasustamisele

Lepingu tunnihinna alusel.

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

juhul kui Tellija suudab eristada lähtekoodis tehtavaid muudatusi.

15. Load ja litsentsid

15.1 Täitja vastutab ainuisikuliselt lepingu täitmiseks vajalike lubade ja litsentside saamise eest. Tellija

teeb Täitjaga mõistliku koostööd, hoidmaks ära selliste lubade või litsentside väljaandmise asjatut

viivitamist või väljaandmisest keeldumist.

15.2 Tellija võib ilma ette teatamata lepingu lõpetada, kui Täitja ei saa lepingu täitmiseks vajalikku luba või

litsentsi.

15.3 Täitja garanteerib, et tal on õigus anda Tellijale lepingu objektiks oleva tarkvara ja teiste autori- või

muude sarnaste õigustega kaitstavate esemete kasutamisõigus.

15.4 Täitja garanteerib, et nimetatud kasutusõiguse üleandmisega ei rikuta kolmandate isikute õigusi.

Juhul kui kolmas isik esitab oma õiguste rikkumise tõttu Tellija vastu hagi ning see rahuldatakse,

tasub Täitja võimalikud kahjuhüvitusnõuded, samuti õigusabikulud ja muud seonduvad kulud.

16. Riski üleminek

16.1 Juhusliku hävimise või kahjustumise risk läheb Tellijale üle töö vastuvõtmisel, samuti hetkel, mil Tellija

satub viivitusse toimingu tegemisega, millega ta töö üleandmisele peab kaasa aitama.

17. Intellektuaalne vara

17.1 Lepingu allkirjastamisega kinnitab Täitja Tellijale, et talle kuuluvad Lepingu täitmiseks vajalikud

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

järgse Töö täielikuks teostamiseks ja loovutamiseks ning, et nende suhtes ei ole kolmandatel isikutel

nõudeid.

17.2 Täitja kinnitab, et ta on võtnud tarvitusele kõik meetmed autori isiklike õiguste realiseerimiseks viisil,

mis ei takista ega raskenda teose kasutamist ja autori varaliste õiguste teostamist Tellija poolt.

17.3 Täitja annab spetsiaaltarkvarale Euroopa Liidu tarkvara vaba kasutuse litsentsi v.1.1 (EUPL). Juhul,

kui Töö üleandmine toimub etapiviisiliselt, siis loetakse litsents antuks iga etapi (teose) vastuvõtmisel

Tellija poolt.

17.4 Tellijal on muuhulgas õigus spetsiaaltarkvara (teose) autoriõiguste kehtivusaja jooksul:

17.4.1 teost kasutada mis tahes eesmärgil ja mis tahes viisil;

17.4.2 teost reprodutseerida;

17.4.3 originaalteost muuta ja luua teosel põhinevaid tuletatud teoseid;

17.4.4 teost või selle koopiaid üldsusele edastada, sealhulgas neid kättesaadavaks teha või

eksponeerida, samuti avalikult esitada;

17.4.5 teost või selle koopiaid levitada;

17.4.6 teost või selle koopiaid laenutada ja rentida;

17.4.7 anda all-litsentse teose või selle koopiate suhtes kehtivate õiguste kohta.

17.5 Täitja annab Tellijale spetsiaaltarkvara lähtekoodi, täitmiskoodi ja dokumentatsiooni kujul, mis

võimaldab Tellijal sellest aru saada.

17.6 Tellija võib levitada lähtekoodi ja täitmiskoodi ning dokumentatsiooni ja selle muudatusi mistahes

kolmandatele isikutele ja asutustele.

17.7 Kõik Täitja poolt Lepingu täitmise käigus koostatud dokumendid ja andmed kuuluvad Tellijale. Täitja

annab kõik nimetatud dokumendid ja andmed Tellijale üle.

17.8 Tellija võib spetsiaaltarkvara autoriõigusi teostada mistahes olemasolevas või hiljem loodud

keskkonnas, toel või formaadis.

17.9 Täitja tagab, et tema töötajad on loobunud Eesti seadusega lubatud ulatuses oma õigusest teostada

isiklikke õigusi, et Tellijale oleks võimalik vajalikke varalisi õigusi litsentsida.

17.10 Lepingujärgse tarkvarasüsteemi loomiseks kolmandatele isikutele kuuluvate komponentide (tarkvara)

kasutamise osas juhinduvad Pooled nende kasutamise litsentsitingimustest. Täitja kinnitab, et

eelistab tarkvara loomisel selliseid kolmandatele isikutele kuuluvaid komponente, mille kasutamisega

ei kaasne täiendavaid litsentsitasusid ega piiranguid tarkvara kasutamisel või alllitsentside andmisel.

Täitja on kohustatud Tellijat teavitama juhul, kui Täitja plaanib tarkvara loomisel kasutada selliseid

kolmandatele isikutele kuuluvaid komponente, mille kasutamine toob Tellijale kaasa täiendavaid

litsentsitasusid või piiranguid tarkvara kasutamisel. Ilma Tellija kirjaliku nõusolekuta ei tohi Täitja

tarkvara loomisel nimetatud komponente kasutada.

17.11 Nimetatud õigused kehtivad kogu autoriõiguste kehtivuse aja ja nende kehtivuse territooriumiks on

kogu maailm.

18. Personal

18.1 Lepingus kirjeldatud teenuseid osutavad Lepingus nimetatud isikud vastavalt Lepingus sätestatud

ülesannetele. Muudatusi tohib teha vaid Tellija kirjalikku taasesitamist võimaldavas vormis antud

nõusolekul.

18.2 Täitja asendab Töid teostava isiku viivitamatult Lepingu objekti täitmise seisukohast võrdväärse

kvalifikatsiooni ja kogemustega ning Tellijale vastuvõetava isikuga, kui:

18.2.1 Töid teostav isik ei ole võimeline teenuste osutamist jätkama haiguse, õnnetusjuhtumi või muu

temast tuleneva põhjuse tõttu;

18.2.2 lepingus nimetatud Töid teostav isik osutub Tellija põhjendatud arvamuse kohaselt

lepingujärgsete ülesannete täitmiseks ebakompetentseks või ebasobivaks või kui tema

lepingujärgsete ülesannete täitmine pidevalt kahjustab lepingu korrektset ja õigeaegset täitmist.

18.2.3 Isikul on kuriteo toimepanemise eest määratud kehtiv karistus.

18.3 Täitja kannab kõik punktis 18.2 nimetatud asendusest tulenevad või sellega kaasnevad kulud.

18.4 Töid teostavatel isikutel ei tohi olla kuriteo toimepanemise eest määratud kehtivat karistust.

18.5 Töid teostavad isikud ei tohi olla Tellija töötajad ega Tellija töötajaga seotud juriidilised isikud. Seotud

juriidiline isik tähendab käesoleva lepingu mõistes juriidilist isikut, mille juhtumis- või kontrollorgani

liige Tellija töötaja on või juriidiline isik, milles vähemalt 1/10 osalusest kuulub Tellija töötajale.

19. Kolmandad isikud

19.1 Pooled võivad loovutada lepingust tulenevaid rahalisi nõudeid kolmandatele isikutele. Pooled on

kohustatud teineteist nõude loovutamisest viivitamatult kirjalikult informeerima.

19.2 Pooled ei või oma lepingujärgseid kohustusi anda üle kolmandale isikule ega kaasata oma

lepingujärgsete kohustuste täitmiseks kolmandat isikut ilma teise poole sellekohase selgesõnalise

kirjaliku nõusolekuta.Tellijal on õigus edastada või suunata Täitja poolt esitatud arve tasumisele

Tellijast erinevale hankijale nendevahelise koostöökokkuleppest tuleneval alusel juhul kui

vastavasisuline teavitus on Tellija poolt pakkumuse esitamise ettepanekus kajastatud.

19.3 Pooled vastutavad kõigi isikute eest, keda nad kasutavad oma lepingujärgsete kohustuste täitmisel.

20. Auditeerimine

20.1 Mõlemal poolel on õigus kaasata auditeerimiseks sõltumatu audiitor.Audiitori kaasamiseks ei ole

vajalik teise poole luba.

20.2 Audiitori isik ja muu auditeerimisega seotud asjaolud sätestatakse eraldi kokkuleppes. Auditeerimise

käigus avastatud probleemid tuleb registreerida ja vajaduse korral sisestada probleemide

lahendamise protsessi.

20.3 Täitja peab täpset arvet lepingu täitmisel töötatud kalendripäevade ja –kuude kompenseerimisele

kuuluvate kulude kohta. Audiitorile võimaldatakse piiramatu ligipääs nimetatud andmetele.

20.4 Audiitorit kaasanud pool tagab, et audiitor käsitleb saadud informatsiooni konfidentsiaalsena.

Vastutus jääb audiitorit kaasanud poolele.

20.5 Pärast andmete auditeerimist ja kontrollimist teeb audiitor järeldusotsuse, mis on lõplik.

20.6 Auditi kulud kannab auditi tellinud pool.

21. Õigustest loobumine

21.1 Kummagi poole mistahes viivitus, hoolimatus või keeldumine teist poolt lepingutingimuste täitmise

nõudmisel või muude nõuete esitamisel ei kujuta endast selle poole mistahes lepingujärgsetest

õigustest loobumist või nende tühistamist.

22. Konfidentsiaalsus ja isikuandmed

22.1 Täitja ei või oma lepingujärgseid kohustusi anda üle kolmandale isikule ega kaasata oma

lepingujärgsete kohustuste täitmiseks kolmandat isikut ilma Tellija sellekohase selgesõnalise kirjaliku

nõusolekuta.

22.2 Täitja on kohustatud:

22.2.1 tagama lepingu täitmise käigus Tellijalt ükskõik mis vormis saadud teabe (andmed,

tehingudokumentatsioonis ja lepingutes sisalduvad Tellija esindajate isikuandmed, know-how)

konfidentsiaalsuse ning ei edasta ega võimalda sellele teabele juurdepääsu kolmandale isikule

ilma Tellija sellekohase selgesõnalise kirjaliku nõusolekuta;

22.2.2 tagama lepingueelsete läbirääkimiste, lepingujärgsete kohustuste ja lepingu täitmise käigus

ükskõik mis vormis teatavaks saanud isikuandmete (v.a. tehingudokumentatsioonis ja

lepingutes sisalduvate Tellija esindajate isikuandmete) konfidentsiaalsuse ning ei edasta ega

võimalda nendele juurdepääsu ühelegi kolmandale isikule ilma Tellija sellekohase

selgesõnalise kirjaliku nõusolekuta;

22.2.3 ei edasta punktis 22.2.2 nimetatud isikuandmeid väljapoole Euroopa Liidu liikmesriikide ja

Euroopa Majandusühendusse kuuluvate riikide territooriumit ilma tellija sellekohase

selgesõnalise kirjaliku nõusolekuta;

22.2.4 kasutama ja töötlema punktis 22.2.2. nimetatud isikuandmeid üksnes Lepingu täitmiseks 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;

22.2.5 võimaldab juurdepääsu punktis 22.2.2. nimetatud isikuandmetele ainult nendele isikutele, kellel

on selleks oma tööülesannete täitmiseks vajadus ning tagab, et need isikud on teadlikud ning

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

koolituse eelmainitud nõuete kohta, on võtnud endale konfidentsiaalsuskohustuse või neile

kehtib asjakohane seadusest tulenev konfidentsiaalsuskohustus. Vastav

konfidentsiaalsuskohustus jääb kehtima pärast käesoleva Lepingu lõppemist;

22.2.6 kohustub täitma kõiki kehtivaid isikuandmete töötlemisalaseid nõudeid, andmete turvalisust

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

eeskirju.

22.2.7 kohustub rakendama järgmisi organisatsioonilisi, füüsilisi ja infotehnilisi turvameetmeid punktis

22.2.2. nimetatud 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 s.h. avalikustamise eest:

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

b) ära hoidma andmete omavolilist lugemist, kopeerimist ja muutmist

andmetöötlussüsteemis, samuti andmekandjate omavolilist teisaldamist;

c) ära hoidma isikuandmete omavolilist salvestamist, muutmist ja kustutamist ning tagama, et

tagantjärele oleks võimalik kindlaks teha, millal, kelle poolt ja milliseid isikuandmeid

salvestati, muudeti või kustutati või millal, kelle poolt ja millistele isikuandmetele

andmetöötlussüsteemis juurdepääs saadi;

d) tagama, et igal andmetöötlussüsteemi kasutajal oleks juurdepääs ainult temale

töötlemiseks lubatud isikuandmetele ja temale lubatud andmetöötluseks;

e) tagama andmete olemasolu isikuandmete edastamise kohta: millal, kellele ja millised

isikuandmed edastati, samuti selliste andmete muutusteta säilimise;

f) tagama, et isikuandmete edastamisel andmesidevahenditega ja andmekandjate

transportimisel ei toimuks isikuandmete omavolilist lugemist, kopeerimist, muutmist või

kustutamist;

g) pidama arvestust isikuandmete töötlemisel kasutatavate tema kontrolli all olevate

seadmete ja tarkvara üle, dokumenteerides järgmised andmed:

i. seadme nimetus, tüüp ja asukoht ning seadme valmistaja nimi;

ii. tarkvara nimetus, versioon, valmistaja nimi ja kontaktandmed.

22.2.8 teavitama tellijat toimunud või põhjendatult kahtlustatavast käesoleva lepingu punktis 22.2.1

ja/või 22.2.2 sätestatud konfidentsiaalsuskohustuse rikkumisest; punktis 22.2.7. ja selle

alapunktides a-g 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, kirjalikult viivitamata aga mitte hiljem kui kakskümmend neli (24) tundi pärast

sellest teada saamist. Teates tuleb vähemalt:

a) kirjeldada (Isikuandmetega seotud) rikkumise laadi, sealhulgas puudutatud

andmesubjektide liike ja arvu ning puudutatud kirjete liike ja arvu;

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

lisateavet;

c) soovitada meetmeid (Isikuandmetega seotud) rikkumise võimalike negatiivsete mõjude

leevendamiseks;

d) kirjeldada (Isikuandmetega seotud) rikkumise tõttu andmesubjektidele tekkivaid tagajärgi

ja potentsiaalseid ohte;

e) kirjeldada täitja/või kolmandast isikust alltöötleja poolt välja pakutud või võetud meetmeid

(Isikuandmetega seotud) rikkumisega tegelemiseks ja

f) 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.

22.2.9 Tellija eelnevalt kirjalikul heakskiidul lõpetama käesoleva lepingu punktis 22.2.8.nimetatud

rikkumise ning kohaldama meetmeid (isikuandmetega seotud) rikkumise lahendamiseks,

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

leevendamiseks;

22.2.10 kohustub lepingu lõppemisel kustutama kõik punktis 22.2.2. nimetatud isikuandmed ja

nimetatute koopiad 30 päeva jooksul, v.a juhul, kui õigusaktidest tuleneb teisiti;

22.2.11 teeb Tellijale kättesaadavaks kogu teabe, mida Tellija peab vajalikuks lepingus sätestatud

kohustuste täitmise tõendamiseks;

22.2.12 võimaldab Tellijal või Tellija poolt volitatud audiitoril teha auditeid ja kontrolle ning panustab

nendesse;

22.2.13 kohustub võimaluse piires asjakohaste tehniliste ja korralduslike meetmete abil punktis 22.2.2.

nimetatud isikuandmete osas Tellijal täita Tellija kohustust vastata taotlustele andmesubjekti

õiguste teostamiseks ning teostada nende õiguste teostamisest tulenevaid toiminguid (andmete

parandamine, sulgemine, kustutamine).

22.3 Käesoleva lepingu punktis 22.2.1. sätestatud konfidentsiaalsuse nõue ei laiene informatsiooni

avaldamisele täitja audiitorile ja advokaadile.

22.4 Käesoleva lepingu punktides 22.2.1. ja 22.2.2. sätestatud konfidentsiaalsuskohustuse nõue on

tähtajatu ning kehtib nii lepingu täitmise ajal kui ka pärast lepingu lõppemist.

22.5 Tulenevalt konfidentsiaalse informatsiooni laadist on tellijal õigus seada täiendavaid nõuded ja/või

juhised isikuandmete töötlemiseks.

22.6 Kõik käesoleva lepingu punktides 22.2.1. – 22.4 kohustused kehtestab täitja kõikidele kolmandatele

isikutele, keda ta kasutab oma lepingujärgsete kohustuste täitmisel. Kolmas isik on füüsiline või

juriidiline isik või riigi- või kohaliku omavalitsuse asutus, kes ei ole ei tellija ega ka täitja.

23. Avalikud suhted

23.1 Pooled ei tegele seoses lepinguga avalike suhetega ega anna teateid pressile, elektroonilisele

meediale, üldsusele või teistele auditooriumidele, välja arvatud teise poole eelneval kirjalikul

nõusolekul. Avaldada võib vaid teateid, mis on teise poolega eelnevalt kooskõlastatud.

23.2 Kõik eelnimetatud kohustused kehtestab pool ka kõigile kolmandatele isikutele, keda ta kasutab oma

lepingujärgsete kohustuste täitmisel.

24. Lepingu täitmise peatamine ja lepingu lõpetamine

24.1 Tellija võib peatada Täitjale lepingujärgselt makstavate summade maksmise kas osaliselt või

täielikult, kui:

24.1.1 Täitja ei täida Lepingut;

24.1.2 vastuvõtmise, testimise või auditeerimise käigus avastatakse puudusi või muid Täitja poolseid

kohustuste rikkumisi;

24.1.3 Tellija Lepingu järgsete kohustuste õigeaegset ja korrektset täitmist segab või ähvardab segada

muu asjaolu, mille eest vastutab Täitja.

24.2 Täitja võib peatada Tellijale teenuse osutamise kas osaliselt või täielikult, kui:

24.2.1 Tellija ei täida Lepingut;

24.2.2 Täitja Lepingu järgsete kohustuste õigeaegset ja korrektset täitmist segab või ähvardab segada

muu asjaolu, mille eest vastutab Tellija.

24.3 Tellija võib igal ajal Lepingu üles öelda, teatades sellest 1 (üks) kuu ette. Sellisel juhul on Täitjal õigus

nõuda tasu täidetud kohustuste eest.

24.4 Tellijal on õigus Leping erakorraliselt etteteatamata lõpetada Täitjapoolse olulise Lepingu rikkumise

korral. Lepingu lõpetamisel punktides 9.4 nimetatud juhtudel Täitja tehtud Tööd ei tasustata. Täitja

poolt tarnitud seadmed, telekommunikatsioonid ja tarkvara tagastatakse, selle võimatuse korral või

muul juhul, kui tagastamine on saadu olemuse tõttu välistatud, makstakse hüvitust

võlaõigusseaduses sätestatud korras.

24.5 Täitja võib Lepingu üles öelda Tellijapoolse olulise Lepingu rikkumise korral pärast vastava hoiatuse

saatmist, kui rikkumist ei ole kõrvaldatud 10 (kümne) tööpäeva jooksul peale hoiatuse esitamist.

Sellise Lepingu lõpetamise korral maksab Tellija Täitjale tasu täidetud kohustuste eest.

24.6 Lepingu lõppemisel on Täitja kohustatud Tellijale tagastama kõik Lepingu täitmiseks üleantu.

25. Vääramatu jõud

25.1 Lepingust tulenevate kohustuste mittetäitmist või mittenõuetekohast täitmist ei loeta Lepingu

rikkumiseks, kui selle põhjuseks oli vääramatu jõud. Vääramatu jõuna käsitlevad pooled

võlaõigusseaduse §-s 103 lg 2 nimetatud asjaolusid.

25.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, esitades teavitusega ühes tõendid

kõigi järgnevate asjaolude esinemise kohta:

25.2.1 takistava asjaolu esinemine, mis takistab kohustuse kohast täitmist;

25.2.2 takistava asjaolu asetsemine väljaspool võlgniku mõjusfääri;

25.2.3 asjaolu ettenägematus;

25.2.4 asjaolu vältimatus ja ületamatus.

25.3 Vääramatu jõu asjaolude ilmnemisel pikeneb Lepingu lõpptähtaeg nimetatud asjaolude esinemise

perioodi võrra. Pool peab vääramatu jõu asjaolude äralangemisel Lepingut täitma asuma. Kui

vääramatu jõu asjaolude tõttu on Poole Lepingust tulenevate kohustuste täitmine takistatud enam kui

60ne kalendripäeva võrra võib teine Pool öelda lepingu üles.

26. Kehtiv seadusandlus

26.1 Lepingule ning kõikidele lepingu osaks olevatele dokumentidele kohaldatakse Eesti Vabariigi

õigusakte.

27. Vaidluste lahendamine

27.1 Käesoleva Lepingu allkirjastamisega kinnitavad pooled, et on tutvunud ja on nõus Lepinguga ja selle

lisadega ning mõistavad täielikult enesele võetavate kohustuste sisu ning nende tagajärgi.

27.2 Lepinguga seotud või sellest tulenevate arusaamatuste või vaidluste puhul püüavad pooled leida

lahenduse heal tahtel põhinevate läbirääkimiste teel.

27.3 Kokkuleppe mittesaavutamisel lahendatakse vaidlus Harju Maakohtus.

1 / 20

Koostatud 25.09.2025 16:43:33 https://riigihanked.riik.ee/rhr-web/#/procurement/9215726/general-info

HANKEPASS

Hankepass ehk Euroopa ühtne hankedokument (ESPD) on ettevõtja enda kinnitus, mis on esialgne tõend ametiasutuste või kolmandate isikute poolt väljastatavate tõendite asemel.

Pakkumus:583657

Ettevõtja: ADM Interactive OÜ

Roll: peapakkuja

I OSA: HANKE JA HANKIJAGA SEOTUD TEAVE

Teave avaldamise kohta Teate number ELTs:

-

ELT URL:

Riigi ametlik teataja:

299179

Kui Euroopa Liidu Teatajas hankekuulutust avaldatud ei ole või kui selle avaldamist ei nõuta, peab avaliku sektori hankija või võrgustiku sektori hankija ise teabe esitama, et hankemenetlust saaks üheselt identifitseerida (nt viide siseriikliku avaldamise kohta).

Hankija andmed Ametlik nimi:

Registrite ja Infosüsteemide Keskus (70000310)

Riik:

Eesti

Hankija aadress:

Lubja tn 4

Hankija veebiaadress:

http://www.rik.ee/

E-posti aadress:

[email protected]

2 / 20

Koostatud 25.09.2025 16:43:33 https://riigihanked.riik.ee/rhr-web/#/procurement/9215726/general-info

Teave hankemenetluse kohta Hanke menetlusliik:

Minikonkurss raamlepingu alusel

Pealkiri:

Riigikohtu veebilehe arendus

Lühikirjeldus:

Minikonkursi eesmärgiks on sõlmida arendustööde hankeleping uue kasutajasõbraliku Riigikohtu veebilehe loomiseks.

Avaliku sektori hankija või võrgustiku sektori hankija poolt toimikule antud viitenumber (kui on asjakohane):

299179

Hanke liik:

Teenused

Hanke CPV-d: 72200000-7 Tarkvara programmeerimis- ja nõustamisteenused

3 / 20

Koostatud 25.09.2025 16:43:33 https://riigihanked.riik.ee/rhr-web/#/procurement/9215726/general-info

II OSA: ETTEVÕTJAGA SEOTUD TEAVE

A: Teave ettevõtja kohta

Nimi: ADM Interactive OÜ

Registrikood: 10474271

Riik: EST

Aadress: Kursi tn 3 Tallinn 10415

Üldine veebileht: http://www.adm.ee/

Kontaktisikud: MARTIN ORN

Kontaktide e-posti aadressid: [email protected]

Kontaktide telefoninumbrid: +372 5078089

Ettevõtte suurus: Keskmise suurusega ettevõte

Töötajate arv: 57

Käive: 7816846

Valuuta: EUR

Finantsalase võimekuse kirjeldus: Ettevõttel on olemas kõik finantsvahendid hankelepingu täitmiseks

Tehnilise võimekuse kirjeldus: Kajastatud hankedokumentides ja hankepassis

Teostatud tööde kirjeldus: Kajastatud hankedokumentides ja hankepassis

Ettevõtja tegevusvaldkond: programmeerimine

4 / 20

Koostatud 25.09.2025 16:43:33 https://riigihanked.riik.ee/rhr-web/#/procurement/9215726/general-info

ETTEVÕTJA ON KAITSTUD TÖÖKOHT

Ainult reserveeritud hangete puhul: kas ettevõtja puhul on tegemist kaitstud töökohaga, sotsiaalse ettevõttega või ta täidab lepingut kaitstud tööhõive programmide raames?

Küsimused ettevõtjale: 1. Mis on Teie vastus?

Vastus: Ei 4. Kas see teave on elektrooniliselt kättesaadav?

Vastus: Ei

ETTEVÕTJA ON KANTUD TUNNUSTATUD ETTEVÕTJATE AMETLIKKU NIMEKIRJA

Kui see on asjakohane, siis kas ettevõtja on kantud tunnustatud ettevõtjate ametlikku nimekirja või kas tal on olemas samaväärne tõend (nt riikliku (eel)kvalifitseerimissüsteemi alusel)?

Küsimused ettevõtjale: 1. Mis on Teie vastus?

Vastus: Ei 5. Kas see teave on elektrooniliselt kättesaadav?

Vastus: Ei

HANKEMENETLUSES KOOS OSALEVAD ETTEVÕTJAD

Kas ettevõtja osaleb hankemenetluses koos teistega?

Küsimused ettevõtjale:

Ettevõtja nimi:ADM Interactive OÜ

Ettevõtja ID:10474271

Ettevõtja roll:peapakkuja

4. Kas see teave on elektrooniliselt kättesaadav? Vastus: Jah

5. URL Vastus: https://riigihanked.riik.ee

TEAVE TEISTE ÜKSUSTE SUUTLIKKUSELE TOETUMISE KOHTA

Kas ettevõtja toetub teiste üksuste suutlikkusele, et täita esitatud valikukriteeriumid ning eeskirjad (kui neid on)?

Küsimused ettevõtjale: 1. Mis on Teie vastus?

Vastus: Ei 5. Kas see teave on elektrooniliselt kättesaadav?

Vastus: Jah 6. URL

Vastus: https://riigihanked.riik.ee

5 / 20

Koostatud 25.09.2025 16:43:33 https://riigihanked.riik.ee/rhr-web/#/procurement/9215726/general-info

TEAVE NENDE ALLHANKIJATE KOHTA, KELLE NÄITAJATELE ETTEVÕTJA EI TUGINE

Kas ettevõtja kavatseb sõlmida lepingu mis tahes osa kohta allhanke kolmanda isikuga?

Küsimused ettevõtjale: 1. Mis on Teie vastus?

Vastus: Ei 5. Kas see teave on elektrooniliselt kättesaadav?

Vastus: Jah 6. URL

Vastus: https://riigihanked.riik.ee

HANKE OSAD

Hanke osad, mille kohta ettevõtja soovib pakkumuse esitada

Küsimused ettevõtjale: 1. Hanke osa number

Vastus: 2. Kas see teave on elektrooniliselt kättesaadav?

Vastus: Jah 3. URL

Vastus: https://riigihanked.riik.ee

ETTEVÕTJA KINNITUSED MAKSUDE TASUMISE KOHTA

Kas ettevõtja saab esitada tõendi sotsiaalkindlustusmaksete ja maksude tasumise kohta või esitada teabe, mis võimaldaks avaliku sektori hankijal või võrgustiku sektori hankijal saada sellise teabe otse ükskõik millise liikmesriigi tasuta andmebaasist?

Küsimused ettevõtjale: 1. Mis on Teie vastus?

Vastus: Jah 2. Kas see teave on elektrooniliselt kättesaadav?

Vastus: Jah 3. URL

Vastus: https://riigihanked.riik.ee

6 / 20

Koostatud 25.09.2025 16:43:33 https://riigihanked.riik.ee/rhr-web/#/procurement/9215726/general-info

B: Teave ettevõtja esindajate kohta

Eesnimi:

Perekonnanimi:

Sünniaeg:

Sünnikoht:

Aadress:

Linn/vald:

Postiindeks:

Riik:

E-post:

Telefon:

Vajaduse korral esitage üksikasjalik teave esindamise kohta (selle vormid, ulatus, eesmärk, ...):

III OSA: KÕRVALDAMISE ALUSED

A: Kõrvalejätmise alused seoses kriminaalasjas tehtud süüdimõistva otsusega

OSALEMINE KURITEGELIKUS ORGANISATSIOONIS

Kas ettevõtja ise või tema haldus-, juht- või järelevalveorgani liige või isik, kellel on volitused seda ettevõtjat esindada, tema nimel otsuseid teha või teda kontrollida, on lõpliku süüdimõistva kohtuotsusega süüdi mõistetud kuritegelikus organisatsioonis osalemise eest kõige rohkem viimase viie aasta jooksul või kehtib süüdimõistvas kohtuotsuses sätestatud kõrvalejäämise kohustus endiselt?

Viide seadusele: RHS § 95 lg 1 p 1 "keda või kelle haldus-, juhtimis- või järelevalveorgani liiget, prokuristi või muud isikut, kellel on volitus seda ettevõtjat esindada, tema nimel otsuseid teha või teda kontrollida, on karistatud kuritegelikus ühenduses osalemise eest". Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") Vastus: Ei

8. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") Vastus: Jah

9. URL (Url) Vastus: https://riigihanked.riik.ee

11. Väljaandja (Sisestusväli (max pikkus 250 tähemärki)) Vastus: Päring karistusregistrisse riigihangete registri kaudu.

7 / 20

Koostatud 25.09.2025 16:43:33 https://riigihanked.riik.ee/rhr-web/#/procurement/9215726/general-info

KORRUPTSIOON

Kas ettevõtja ise või tema haldus-, juht- või järelevalveorgani liige või isik, kellel on volitused seda ettevõtjat esindada, tema nimel otsuseid teha või teda kontrollida, on lõpliku süüdimõistva kohtuotsusega süüdi mõistetud korruptsiooni eest kõige rohkem viimase viie aasta jooksul või kehtib süüdimõistvas kohtuotsuses sätestatud kõrvalejäämise kohustus endiselt? See kõrvalejätmise alus hõlmab ka korruptsiooni avaliku sektori hankija (võrgustiku sektori hankija) või ettevõtja riigi õiguses sätestatud määratluses.

Viide seadusele: RHS § 95 lg 1 p 1 ja lg 2 "keda või kelle haldus-, juhtimis- või järelevalveorgani liiget, prokuristi või muud isikut, kellel on volitus seda ettevõtjat esindada, tema nimel otsuseid teha või teda kontrollida, on karistatud aususe kohustuse rikkumise või korruptiivse teo eest". Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") Vastus: Ei

8. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") Vastus: Jah

9. URL (Url) Vastus: https://riigihanked.riik.ee

11. Väljaandja (Sisestusväli (max pikkus 250 tähemärki)) Vastus: Päring karistusregistrisse riigihangete registri kaudu.

PETTUS

Kas ettevõtja ise või tema haldus-, juht- või järelevalveorgani liige või isik, kellel on volitused seda ettevõtjat esindada, tema nimel otsuseid teha või teda kontrollida, on lõpliku süüdimõistva kohtuotsusega süüdi mõistetud kelmuse eest kõige rohkem viimase viie aasta jooksul või kehtib süüdimõistvas kohtuotsuses sätestatud kõrvalejäämise kohustus endiselt?

Viide seadusele: RHS § 95 lg 1 p 1 ja lg 2 "keda või kelle haldus-, juhtimis- või järelevalveorgani liiget, prokuristi või muud isikut, kellel on volitus seda ettevõtjat esindada, tema nimel otsuseid teha või teda kontrollida, on karistatud kelmuse eest". Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.

8 / 20

Koostatud 25.09.2025 16:43:33 https://riigihanked.riik.ee/rhr-web/#/procurement/9215726/general-info

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") Vastus: Ei

8. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") Vastus: Jah

9. URL (Url) Vastus: https://riigihanked.riik.ee

11. Väljaandja (Sisestusväli (max pikkus 250 tähemärki)) Vastus: Päring karistusregistrisse riigihangete registri kaudu.

TERRORIAKTI TOIMEPANEK VÕI TERRORISTLIKU TEGEVUSEGA SEOTUD

ÕIGUSRIKKUMISED

Kas ettevõtja ise või tema haldus-, juht- või järelevalveorgani liige või isik, kellel on volitused seda ettevõtjat esindada, tema nimel otsuseid teha või teda kontrollida, on lõpliku süüdimõistva kohtuotsusega süüdi mõistetud terroriakti toimepaneku või terroristliku tegevusega seotud õigusrikkumiste eest kõige rohkem viimase viie aasta jooksul või kehtib süüdimõistvas kohtuotsuses sätestatud kõrvalejäämise kohustus endiselt?

Viide seadusele: RHS § 95 lg 1 p 1 ja lg 2 "keda või kelle haldus-, juhtimis- või järelevalveorgani liiget, prokuristi või muud isikut, kellel on volitus seda ettevõtjat esindada, tema nimel otsuseid teha või teda kontrollida, on karistatud terroriakti toimepaneku või muu terroristliku tegevusega seotud kuriteo või sellele kihutamise, kaasaaitamise või selle katse eest". Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") Vastus: Ei

8. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") Vastus: Jah

9. URL (Url) Vastus: https://riigihanked.riik.ee

11. Väljaandja (Sisestusväli (max pikkus 250 tähemärki)) Vastus: Päring karistusregistrisse riigihangete registri kaudu.

RAHAPESU VÕI TERRORISMI RAHASTAMINE

Kas ettevõtja ise või tema haldus-, juht- või järelevalveorgani liige või isik, kellel on volitused seda ettevõtjat esindada, tema nimel otsuseid teha või teda kontrollida, on lõpliku süüdimõistva kohtuotsusega süüdi mõistetud rahapesu või terrorismi rahastamise eest kõige rohkem viimase viie aasta jooksul või kehtib süüdimõistvas kohtuotsuses sätestatud kõrvalejäämise kohustus endiselt?

Viide seadusele:

9 / 20

Koostatud 25.09.2025 16:43:33 https://riigihanked.riik.ee/rhr-web/#/procurement/9215726/general-info

RHS § 95 lg 1 p 1 ja lg 2 "keda või kelle haldus-, juhtimis- või järelevalveorgani liiget, prokuristi või muud isikut, kellel on volitus seda ettevõtjat esindada, tema nimel otsuseid teha või teda kontrollida, on karistatud rahapesualase süüteo või terrorismi rahastamise eest". Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") Vastus: Ei

8. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") Vastus: Jah

9. URL (Url) Vastus: https://riigihanked.riik.ee

11. Väljaandja (Sisestusväli (max pikkus 250 tähemärki)) Vastus: Päring karistusregistrisse riigihangete registri kaudu.

LASTE TÖÖJÕU KASUTAMINE JA MUUD INIMKAUBANDUSE VORMID

Kas ettevõtja ise või tema haldus-, juht- või järelevalveorgani liige või isik, kellel on volitused seda ettevõtjat esindada, tema nimel otsuseid teha või teda kontrollida, on lõpliku süüdimõistva kohtuotsusega süüdi mõistetud laste tööjõu kasutamise või muude inimkaubanduse vormide eest kõige rohkem viimase viie aasta jooksul või kehtib süüdimõistvas kohtuotsuses sätestatud kõrvalejäämise kohustus endiselt?

Viide seadusele: RHS § 95 lg 1 p 3 ja lg 2 "keda või kelle haldus-, juhtimis- või järelevalveorgani liiget, prokuristi või muud isikut, kellel on volitus seda ettevõtjat esindada, tema nimel otsuseid teha või teda kontrollida, on karistatud laste tööjõu ebaseadusliku kasutamise või inimkaubandusega seotud teo eest". Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") Vastus: Ei

8. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") Vastus: Jah

9. URL (Url) Vastus: https://riigihanked.riik.ee

11. Väljaandja (Sisestusväli (max pikkus 250 tähemärki)) Vastus: Päring karistusregistrisse riigihangete registri kaudu.

10 / 20

Koostatud 25.09.2025 16:43:33 https://riigihanked.riik.ee/rhr-web/#/procurement/9215726/general-info

B: Kõrvalejätmise alused seoses maksude või sotsiaalkindlustusmaksete tasumisega

MAKSUDE TASUMINE

Kas ettevõtja on rikkunud oma maksude tasumise kohustusi nii asukohariigis kui ka avaliku sektori hankija või võrgustiku sektori hankija liikmesriigis, kui see erineb asukohariigist?

Viide seadusele: RHS § 95 lg 1 p 4 „kellel on riikliku maksu, makse või keskkonnatasu maksuvõlg maksukorralduse seaduse tähenduses või maksuvõlg /…/ tema asukohariigi õigusaktide kohaselt“

Tingimuse kirjeldus: Piirmäär: 0

Valuuta: EUR

Lisainfo: Maksukorralduse seaduse kohaselt ei väljasta maksuhaldur maksuvõlgade tõendit juhul, kui maksukohustuslasel olev kõikide sama maksuhalduri hallatavate maksude võlg, arvestamata haldusaktiga kindlaksmääramata intressi, on väiksem kui 100 eurot või kui maksuvõla tasumine on ajatatud. Välismaise ettevõtja puhul väljastatakse maksuvõlgade tõend tema asukohariigi õigusaktide kohaselt.

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") Vastus: Ei

12. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") Vastus: Jah

13. URL (Url) Vastus: https://riigihanked.riik.ee

15. Väljaandja (Sisestusväli (max pikkus 250 tähemärki)) Vastus: Päring EMTA maksuvõlglaste andmebaasi riigihangete registri kaudu.

SOTSIAALKINDLUSTUSMAKSETE TASUMINE

Kas ettevõtja on rikkunud oma sotsiaalkindlustusmaksete tasumise kohustusi nii asukohariigis kui ka avaliku sektori hankija või võrgustiku sektori hankija liikmesriigis, kui see erineb asukohariigist?

Viide seadusele: RHS § 95 lg 1 p 4 „kellel on riikliku /…/ makse /…/ maksuvõlg maksukorralduse seaduse tähenduses või sotsiaalkindlustusemaksete võlg tema asukohariigi õigusaktide kohaselt

11 / 20

Koostatud 25.09.2025 16:43:33 https://riigihanked.riik.ee/rhr-web/#/procurement/9215726/general-info

Tingimuse kirjeldus: Piirmäär: 0

Valuuta: EUR

Lisainfo: Maksukorralduse seaduse kohaselt ei väljasta maksuhaldur maksuvõlgade tõendit juhul,kui maksukohustuslasel olev kõikide sama maksuhalduri hallatavate maksude võlg, arvestamata haldusaktiga kindlaksmääramata intressi, on väiksem kui 100 eurot või kui maksuvõla tasumine on ajatatud. Välismaise ettevõtja puhul väljastatakse maksuvõlgade tõend tema asukohariigi õigusaktide kohaselt.

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") Vastus: Ei

12. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") Vastus: Jah

13. URL (Url) Vastus: https://riigihanked.riik.ee

15. Väljaandja (Sisestusväli (max pikkus 250 tähemärki)) Vastus: Päring EMTA maksuvõlglaste andmebaasi riigihangete registri kaudu.

C: Kõrvalejätmise alused seoses maksejõuetusega, huvide konfliktiga või ametialaste käitumisreeglite rikkumisega

KESKKONNAÕIGUSE VALDKONNAS KOHALDATAVATE KOHUSTUSTE TÄITMATA

JÄTMINE

Kas ettevõtja on enda teada rikkunud keskkonnaõiguse valdkonnas kohaldatavaid kohustusi?

Viide seadusele: RHS § 95 lg 4 p 2 „kes on rikkunud õigusaktidest või kollektiivlepingust tulenevaid keskkonnaõiguse valdkonnas kohaldatavaid kohustusi“. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") Vastus: Ei

5. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") Vastus: Ei

SOTSIAALÕIGUSE VALDKONNAS KOHALDATAVATE KOHUSTUSTE TÄITMATA

JÄTMINE

Kas ettevõtja on enda teada rikkunud sotsiaalõiguse valdkonnas kohaldatavaid kohustusi?

Viide seadusele:

12 / 20

Koostatud 25.09.2025 16:43:33 https://riigihanked.riik.ee/rhr-web/#/procurement/9215726/general-info

RHS § 95 lg 4 p 2 „kes on rikkunud õigusaktidest või kollektiivlepingust tulenevaid sotsiaalõiguse valdkonnas kohaldatavaid kohustusi“. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") Vastus: Ei

5. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") Vastus: Ei

TÖÖÕIGUSE VALDKONNAS KOHALDATAVATE KOHUSTUSTE TÄITMATA

JÄTMINE

Kas ettevõtja on enda teada rikkunud tööõiguse valdkonnas kohaldatavaid kohustusi?

Viide seadusele: RHS § 95 lg 4 p 2 „kes on rikkunud õigusaktidest või kollektiivlepingust tulenevaid tööõiguse valdkonnas kohaldatavaid kohustusi“. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") Vastus: Ei

5. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") Vastus: Ei

PANKROT

Kas ettevõtja on pankrotis?

Viide seadusele: RHS § 95 lg 4 p 3 „kes on pankrotis, välja arvatud asjade ostmisel RHS § 49 lõikes 4 sätestatud juhul ja tingimustel“. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.

13 / 20

Koostatud 25.09.2025 16:43:33 https://riigihanked.riik.ee/rhr-web/#/procurement/9215726/general-info

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") Vastus: Ei

4. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") Vastus: Jah

5. URL (Url) Vastus: https://riigihanked.riik.ee

7. Väljaandja (Sisestusväli (max pikkus 250 tähemärki)) Vastus: Päring Äriregistrisse riigihangete registri kaudu.

MAKSEJÕUETUS

Kas ettevõtja suhtes on algatatud maksejõuetus- või likvideerimismenetlus?

Viide seadusele: RHS § 95 lg 4 p 3 „kes on likvideerimisel või kelle suhtes on algatatud pankrotimenetlus, välja arvatud asjade ostmisel RHS § 49 lõikes 4 sätestatud juhul ja tingimustel“. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") Vastus: Ei

4. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") Vastus: Jah

5. URL (Url) Vastus: https://www.ametlikudteadaanded.ee/

7. Väljaandja (Sisestusväli (max pikkus 250 tähemärki)) Vastus: Päringut saab käsitsi teha veebilehel Ametlikud Teadaanded.

KOKKULEPE VÕLAUSALDAJATEGA

Kas ettevõtja on sõlminud kokkuleppe võlausaldajatega?

Viide seadusele: RHS § 95 lg 4 p 3 „kes on muus sellesarnases olukorras tema asukohamaa õigusaktide kohaselt, välja arvatud asjade ostmisel RHS § 49 lõikes 4 sätestatud juhul ja tingimustel“. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.

14 / 20

Koostatud 25.09.2025 16:43:33 https://riigihanked.riik.ee/rhr-web/#/procurement/9215726/general-info

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") Vastus: Ei

4. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") Vastus: Ei

SISERIIKLIKU ÕIGUSE KOHANE SAMALAADNE OLUKORD, NÄITEKS PANKROT

Kas ettevõtja on siseriiklike õigusnormide alusel toimuva samalaadse menetluse tõttu samalaadses olukorras?

Viide seadusele: RHS § 95 lg 4 p 3 „kes on muus sellesarnases olukorras tema asukohamaa õigusaktide kohaselt“, välja arvatud asjade ostmisel RHS § 49 lõikes 4 sätestatud juhul ja tingimustel. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") Vastus: Ei

4. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") Vastus: Jah

5. URL (Url) Vastus: https://riigihanked.riik.ee

7. Väljaandja (Sisestusväli (max pikkus 250 tähemärki)) Vastus: Päring Äriregistrisse riigihangete registri kaudu.

VARA HALDAB LIKVIDEERIJA

Kas ettevõtja vara haldab likvideerija või kohus?

Viide seadusele: RHS § 95 lg 4 p 3 „kes on pankrotis, likvideerimisel või kelle suhtes on algatatud pankrotimenetlus või kes on muus sellesarnases olukorras tema asukohamaa õigusaktide kohaselt, välja arvatud asjade ostmisel RHS § 49 lõikes 4 sätestatud juhul ja tingimustel“. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.

15 / 20

Koostatud 25.09.2025 16:43:33 https://riigihanked.riik.ee/rhr-web/#/procurement/9215726/general-info

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") Vastus: Ei

4. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") Vastus: Jah

5. URL (Url) Vastus: https://riigihanked.riik.ee

7. Väljaandja (Sisestusväli (max pikkus 250 tähemärki)) Vastus: Päring Äriregistrisse riigihangete registri kaudu.

ÄRITEGEVUS ON PEATATUD

Kas ettevõtja äritegevus on peatatud?

Viide seadusele: RHS § 95 lg 4 p 3 „kelle äritegevus on peatatud, välja arvatud asjade ostmisel RHS § 49 lõikes 4 sätestatud juhul ja tingimustel“. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") Vastus: Ei

4. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") Vastus: Jah

5. URL (Url) Vastus: https://ariregister.rik.ee/

7. Väljaandja (Sisestusväli (max pikkus 250 tähemärki)) Vastus: https://ariregister.rik.ee/

SÜÜDI AMETIALASTE KÄITUMISREEGLITE OLULISES RIKKUMISES

Kas ettevõtja on süüdi ametialaste käitumisreeglite olulises rikkumises? Vt siseriiklikud õigusaktid, asjaomane teade või hankedokumendid, kui see on asjakohane.

Viide seadusele: RHS § 95 lg 4 p 4 „kes on raskelt eksinud ametialaste käitumisreeglite vastu ja see muudab tema aususe küsitavaks“. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.

16 / 20

Koostatud 25.09.2025 16:43:33 https://riigihanked.riik.ee/rhr-web/#/procurement/9215726/general-info

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") Vastus: Ei

5. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") Vastus: Ei

KONKURENTSI MOONUTAMISE EESMÄRGIL TEISTE ETTEVÕTJATEGA

SÕLMITUD KOKKULEPPED

Kas ettevõtja on teiste ettevõtjatega sõlminud kokkuleppeid, mille eesmärk on moonutada konkurentsi?

Viide seadusele: RHS § 95 lg 4 p 5 „konkurentsi kahjustava kokkuleppe, ettevõtjate ühenduse otsuse või kooskõlastatud tegevuse tõttu“. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") Vastus: Ei

5. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") Vastus: Ei

HANKEMENETLUSES OSALEMISEGA KAASNEV HUVIDE KONFLIKT

Kas ettevõtja on teadlik hankemenetluses osalemisega kaasnevast mis tahes huvide konfliktist siseriikliku õiguse, asjakohase teatise või hankedokumentide kohaselt?

Viide seadusele: RHS § 95 lg 4 p 6 „kui huvide konflikti ei ole muude vahenditega võimalik vältida“. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") Vastus: Ei

3. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") Vastus: Ei

17 / 20

Koostatud 25.09.2025 16:43:33 https://riigihanked.riik.ee/rhr-web/#/procurement/9215726/general-info

OTSENE VÕI KAUDNE OSALEMINE KÄESOLEVA HANKEMENETLUSE

ETTEVALMISTAMISEL

Kas ettevõtja või temaga seotud ettevõtja on nõustanud avaliku sektori hankijat või võrgustiku sektori hankijat hankemenetluse ettevalmistamisel või olnud muul viisil seotud hankemenetluse ettevalmistamisega?

Viide seadusele: RHS § 95 lg 4 p 7 „kelle pakkumuse või taotluse koostamisel on osalenud isik, kes on osalenud sama riigihanke ettevalmistamisel või on muul viisil hankijaga seotud, ja sellele isikule seetõttu teadaolev info annab talle eelise teiste riigihankes osalejate eest ning sellest tingitud konkurentsi moonutamist ei ole muude vahendistega võimalik vältida“. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") Vastus: Ei

3. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") Vastus: Ei

ENNETÄHTAEGNE LÕPETAMINE, KAHJUTASU VÕI VÕRRELDAVAD

SANKTSIOONID

Kas ettevõtja on kogenud, et varasem riigihankeleping või võrgustiku sektori hankijaga sõlmitud varasem hankeleping või varasem kontsessioonileping on lõpetatud enneaegselt, või on määratud kahjutasu või sellega võrreldavad sanktsioonid seoses kõnealuse varasema lepinguga?

Viide seadusele: RHS § 95 lg 4 p 8 „kes on oluliselt või pidevalt rikkunud eelnevalt sõlmitud hankelepingu olulist tingimust või hankelepingute olulisi tingimusi nii, et rikkumise tulemusena on lepingust taganetud või leping üles öeldud, hinda alandatud, hüvitatud kahju või makstud leppetrahvi". Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud. Alates 1.09.2017 alustatud hangete tulemusena sõlmitud riigihankelepingute kohta leiab infot riigihangete registrist.

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") Vastus: Ei

5. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") Vastus: Ei

18 / 20

Koostatud 25.09.2025 16:43:33 https://riigihanked.riik.ee/rhr-web/#/procurement/9215726/general-info

SÜÜDI VALEANDMETE ESITAMISES, ON JÄTNUD TEAVET ESITAMATA, EI SUUDA

NÕUTUD DOKUMENTE ESITADA, HANKINUD KÄESOLEVA MENETLUSE KOHTA

KONFIDENTSIAALSET TEAVET

Kas ettevõtja on olnud ühes järgmistest olukordadest: a) ta on kõrvalejätmise aluste puudumise või valikukriteeriumide täitmise kontrollimiseks nõutava teabe esitamisel esitanud valeandmeid; b) ta on jätnud sellist teavet esitamata; c) ta ei ole esitanud viivitamata avaliku sektori hankija või võrgustiku sektori hankija nõutud täiendavad dokumendid, ja d) ta on tegutsenud eesmärgiga mõjutada lubamatul viisil avaliku sektori hankija või võrgustiku sektori hankija otsustusprotsessi, et saada konfidentsiaalseid andmeid, mis võivad anda talle põhjendamatu eelise hankemenetluses, või hooletusest esitanud eksitavat teavet, mis võib oluliselt mõjutada kõrvalejätmise, valiku või lepingu hindamise kohta tehtavaid otsuseid?

Viide seadusele: RHS § 95 lg 4 p 9 „kes on esitanud valeandmeid käesolevas paragrahvis sätestatud või RHS §- des 98-101 sätestatu alusel hankija kehtestatud kvalifitseerimise tingimustele vastavuse kohta“; RHS § 95 lg 4 p 9 „kes on jätnud andmed käesolevas paragrahvis sätestatud või käesoleva seaduse §-des 98-101 sätestatu alusel hankija kehtestatud kvalifitseerimise tingimustele vastavuse kohta esitamata“; RHS § 95 lg 4 p 9 „kes on jätnud käesoleva seaduse § 104 lõigete 7 ja 8 alusel hankija nõutud täiendavad dokumendid esitamata“; RHS § 95 lg 4 p 10 „kes on tegutsenud eesmärgiga mõjutada hankijat või esitanud hooletusest eksitavat teavet, mis on võinud mõjutada hankija otsuseid riigihankes, või on tegutsenud eesmärgiga saada konfidentsiaalset teavet, mis on võinud anda talle põhjendamatu eelise teiste riigihankes osalejate ees“. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") Vastus: Ei

2. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") Vastus: Ei

D: Ainult siseriiklikest õigusaktidest tulenevad kõrvalejätmise alused

AINULT SISERIIKLIKEST ÕIGUSAKTIDEST TULENEVAD KÕRVALEJÄTMISE

ALUSED: SEADUSLIKU ALUSETA VIIBIVALE VÄLISMAALASELE TÖÖTAMISE

VÕIMALDAMISE EEST

Kas ettevõtja on rikkunud RHS § 95 lg 1 p-st 2 tuleneva kõrvalejätmise alusega seotud kohustusi?

Viide seadusele: RHS § 95 lg 1 p 2 „keda või kelle haldus-, juhtimis- või järelevalveorgani liiget, prokuristi või muud isikut, kellel on volitus seda ettevõtjat esindada, tema nimel otsuseid teha või teda kontrollida, on karistatud riigis ilma seadusliku aluseta viibivale välismaalasele töötamise võimaldamise või välismaalase Eestis töötamise tingimuste rikkumise võimaldamise, sealhulgas seaduses sätestatud töötasu määrast väiksema töötasu maksmise eest“. Kohustuslik kõrvaldamise

19 / 20

Koostatud 25.09.2025 16:43:33 https://riigihanked.riik.ee/rhr-web/#/procurement/9215726/general-info

alus. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") Vastus: Ei

AINULT SISERIIKLIKEST ÕIGUSAKTIDEST TULENEVAD KÕRVALEJÄTMISE

ALUSED: RAHVUSVAHELISE SANKTSIOONI SUBJEKT

Kas ettevõtja on rikkunud RHS § 95 lg 1 p-st 5 tuleneva kõrvalejätmise alusega seotud kohustusi?

Viide seadusele: RHS § 95 lg 1 p 5. Kellega hankelepingu sõlmimine rikuks rahvusvahelist või Vabariigi Valitsuse sanktsiooni rahvusvahelise sanktsiooni seaduse tähenduses. Hankija kontrollib käesoleva seaduse § 95 lõike 1 punktis 5 sätestatud kõrvaldamise alust pakkuja või taotleja kinnituse alusel. Hankija võib põhjendatud kahtluse korral nõuda pakkujalt või taotlejalt täiendavate andmete või tõendite esitamist, mis võimaldavad kõrvaldamise alust kontrollida. (RHS § 96 lg 2.1).

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") Vastus: Ei

AINULT SISERIIKLIKEST ÕIGUSAKTIDEST TULENEVAD KÕRVALEJÄTMISE

ALUSED: KARISTATUD MAKSUALASTE SÜÜTEGUDE EEST

Kas ettevõtja on rikkunud RHS § 95 lg 4 p-st 11 tuleneva kõrvalejätmise alusega seotud kohustusi?

Viide seadusele: RHS § 95 lg 4 p 11 „keda või kelle haldus-, juhtimis- või järelevalveorgani liiget või muud seaduslikku esindajat on karistatud maksualaste süütegude eest“. Vabatahtlik kõrvaldamise alus. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") Vastus: Ei

20 / 20

Koostatud 25.09.2025 16:43:33 https://riigihanked.riik.ee/rhr-web/#/procurement/9215726/general-info

AINULT SISERIIKLIKEST ÕIGUSAKTIDEST TULENEVAD KÕRVALEJÄTMISE

ALUSED: OSALEJA PIIRAMINE ETTEVÕTJA ELU- VÕI ASUKOHA PÕHISELT

Kas ettevõtja rikub hankija kehtestatud piirangut pakkumust või taotlust esitada?

Viide seadusele: RHS § 95 lg 4 p 12 „kellel puudub käesoleva seaduse alusel õigus pakkumust või taotlust esitada, välja arvatud § 111 lõikes 6 sätestatud juhul". RHS § 7 lg 3 sätestab, et hankija võib piirata pakkujate ja taotlejate ringi, lubades riigihankes osaleda ainult RHS § 3 punktis 2 nimetatud riikidest pärit ettevõtjatel või andes nendest riikidest pärit ettevõtjate esitatud pakkumustele eeliseid teistest riikidest pärit ettevõtjate esitatud pakkumuste ees. Hankija sätestab piirangu ettevõtja elu- või asukohale hanke alusdokumentides.

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") Vastus: Ei

Kokkuvõtlikud kinnitused

Ettevõtja kinnitab, et esitatud teave on täpne ja õige ning et ta on teadlik valeandmete esitamise tagajärgedest. Ettevõtja kinnitab, et tal on võimalik vajaduse korral viivitamata tema kinnitustele vastavad dokumendid hankijale esitada. Ettevõtja kinnitab, et ta on nõus oma kinnitustele vastavate andmete väljastamisega hankijale, kui need andmed on avalike andmete põhjal hankijale oluliste kulutusteta elektroonilisest andmekogust kättesaadavad.

Kinnituse andja nimi: Riho Pihelpuu

Koostatud 25.09.2025 16:55:29 1 / 2 https://riigihanked.riik.ee/rhr-web/#/procurement/ 9215726/general-info

PAKKUMUS HINDAMISKRITEERIUMID JA HINNATAVAD NÄITAJAD

Viitenumber: 299179 Hankija: Registrite ja Infosüsteemide Keskus (70000310) Hange: Riigikohtu veebilehe arendus Pakkumus: 583657 Ettevõtja: ADM Interactive OÜ (10474271), roll: peapakkuja

Pakkumuse maksumust hinnatakse - Ilma maksudeta

1. Pakkumuse kogumaksumus Pakkumuse maksumus peab olema lõplik ja sisaldama kõiki kulusid vastavalt riigihanke alusdokumentidele ning seal nimetamata kulusid, mis on vajalikud lepingu nõuetekohaseks täitmiseks. 0 või negatiivse väärtusega maksumusi ei ole lubatud kasutada ja sellised pakkumused on hankijal õigus tunnistada mittevastavaks ning tagasi lükata. Maksumus esitatakse täpsusega kaks kohta pärast koma. Hankija ei hüvita lepingu täitmisel pakkujale mingeid täiendavaid kulusid ega tee täiendavaid makseid.

Tüüp ja hindamismeetod: Maksumus, vähim on parim

Osakaal: 60%

Hindamismetoodika kirjeldus: Madalaima väärtusega pakkumus saab maksimaalse arvu punkte. Teised pakkumused saavad punkte arvutades valemiga: "osakaal" - ("pakkumuse väärtus" - madalaim väärtus") / "suurim väärtus" * "osakaal". Juhul, kui mitu pakkumust koguvad võrdse arvu väärtuspunkte, siis korraldab hankija eduka pakkumuse väljaselgitamiseks liisuheitmise, võimaldades võrdselt väärtuspunkte saanud pakkumuse esitanud pakkujatel liisuheitmise juures viibida.

Kogus Ühik Ühiku hind Maksumus KM% Maksumus KM-ga Märkused

34860,000 34860,000 24 43226,400

2. Projektiplaan

Tüüp ja hindamismeetod: Kvaliteet, hankija hinnatav

Osakaal: 40%

Hindamismetoodika kirjeldus: Projektiplaani puhul hinnatakse projektiplaani detailsust, ülevaatlikust, realistlikkust ning tööde loogilist järjestust vastavalt järgmisele skaalale:

Koostatud 25.09.2025 16:55:29 2 / 2 https://riigihanked.riik.ee/rhr-web/#/procurement/ 9215726/general-info

40 punkti - Pakkuja on täielikult aru saanud hankeobjekti olemusest ja ülesandepüstitusest. Projektiplaan vastab täies ulatuses hanke alusdokumentides esitatud parameetritele ja tingimustele. Hanke eesmärgi saavutamiseks vajalikud tegevused on loogilises järjestuses, omavahelises seoses ja kooskõlas hanke tehnilise kirjeldusega. Tööd on jaotatud projekti läbiviimiseks sobiva kestusega etappideks, etapi tööde mahuhinnangud on realistlikud arvestades etapi tulemite mahtu. Riskide halduse ettepanekud on esitatud selgelt, detailselt, läbimõeldult, struktureeritult ja põhjendatult. Projektiplaani osas on tegemist põhjaliku ja realistliku projektiplaani etappide ettepanekuga, mis võimaldab realiseerida hankeobjekti tehnilises kirjelduses püstitatud eesmärgid tähtaegselt. Esitatust nähtub selgelt, kuidas hanke alusdokumentides kirjeldatud nõuded, ootused tulemusele ning eesmärkidele plaanitakse realiseerida. Küsitavusi ei teki. 30 punkti - Pakkuja on aru saanud hankeobjekti ülesandepüstitusest ning esitatud projektiplaan ning riskide hindamine ja nende halduse ettepanekud on esitatud struktureeritult ja põhjendatult. Esitatud projektiplaanist on arusaadav, kuidas hanke alusdokumentides kirjeldatud nõuded, ootused tulemusele ning eesmärkidele planeeritakse realiseerida. Samas tekib projektiplaani ja/või riskide hindamise osas 1-3 küsitavust või märkust, mida hankija peaks pakkujalt üle täpsustama. 15 punkti - Pakkuja esitatud projektiplaan ning riskide hindamine ja nende halduse ettepanekud on esitatud keskpäraselt. Esitatu osas tekib 4-6 küsitavust või märkust, mida hankija peaks pakkujalt üle täpsustama. 5 punkti - Pakkuja esitatud projektiplaan ning riskide hindamine ja nende halduse ettepanekud on esitatud kasinalt. Hankijal tekib palju küsimusi ning ei ole täpselt aru saadav, kuidas kavatsetakse soovitud tulemini jõuda.

Pakkumuse maksumus kokku Maksumus kokku KM-ta: 34860,000

Maksumus kokku KM-ga: 43226,400

1 / 2

Koostatud 25.09.2025 16:55:29 https://riigihanked.riik.ee/rhr-web/#/procurement/9215726/general-info

PAKKUMUS VASTAVUSTINGIMUSED Viitenumber: 299179 Hankija: Registrite ja Infosüsteemide Keskus (70000310) Hange: Riigikohtu veebilehe arendus Pakkumus: 583657 Ettevõtja: ADM Interactive OÜ (10474271), roll: peapakkuja

PAKKUMUSE ESITAMINE Pakkumuse esitamisega kinnitab pakkuja kõigi riigihanke alusdokumentides esitatud tingimuste ülevõtmist.

Tingimusliku pakkumuse esitamine ei ole lubatud.

Ettevõtjalt oodatavad vastused: 1. Kas ettevõtja saab kinnitada, et pakkumus vastab hanke alusdokumentides sätestatud tingimustele? (Raadionupp valikutega "Jah/Ei")

Vastus: Jah

2. Andmed lepinguks, mida kasutatakse juhul kui pakkumus tunnistatakse edukaks. Pakkuja esitab andmetena: 1. lepingu allkirjastaja nimi 2. alus lepingu allkirjastamiseks (juhatuse liige, volikiri vms) 3. pakkuja kontaktisik(ud) lepingu täitmisel (nimi, ametinimetus, telefoni number, e- posti aadress). (Suur sisestusala (max pikkus 4000 tähemärki))

Vastus: 1. Hendrek Kraavi 2. Volikiri 3. Tõnis Muuga, tiimijuht, +372 5596 6981, [email protected] Jana Korberg, projektijuht, +37253670101, [email protected]

3. Pakkumuse esitamisega kinnitab pakkuja, et: • võtab üle kõik hanketeates ja hankedokumentides esitatud tingimused ja esitab pakkumuse üksnes kõigi nende asjaolude kohta, mille kohta hankija soovib võistlevaid pakkumusi; • tal on olemas hankelepingu täitmiseks vajalikud intellektuaalse omandi õigused; • tal on olnud piisavalt aega lepingus sisalduvate tüüptingimustega tutvumiseks, selgitustaotluste esitamiseks ning tüüptingimustega mittenõustumisel vaidlustuse esitamiseks; • kõik tüüptingimused lepingus on pakkujale arusaadavad ja mõistetavad. (Raadionupp valikutega "Jah/Ei")

Vastus: Jah

ÄRISALADUS Pakkuja märgib pakkumuses, milline teave on pakkuja ärisaladus ning põhjendab teabe määramist ärisaladuseks.

Teabe ärisaladuseks määramisel lähtutakse ebaausa konkurentsi takistamise ja ärisaladuse kaitse seaduse § 5 lõikes 2 sätestatust. Pakkuja ei või ärisaladusena märkida: 1) pakkumuse maksumust ega osamaksumusi; 2) teenuste hankelepingute puhul lisaks punktis 1 nimetatule muid pakkumuste hindamise kriteeriumidele vastavaid pakkumust iseloomustavaid numbrilisi näitajaid; 3) asjade ja ehitustööde hankelepingute puhul lisaks punktis 1 nimetatule muid pakkumuste hindamise kriteeriumidele vastavaid pakkumust iseloomustavaid näitajaid (RHS § 46 (1)).

Ettevõtjalt oodatavad vastused: 1. Kirjeldage lühidalt pakkumuses sisalduvat ärisaladust ja lisage selle määramise põhjendus või märkige, et pakkumus ei sisalda ärisaladust. (Suur sisestusala (max pikkus 4000 tähemärki))

Vastus: Pakkumus ei sisalda ärisaladust.

SAMAVÄÄRSUS Pakkuja kinnitab, et pakkumus vastab hanke alusdokumentides nõutule ja vajadusel on samaväärsus selgitatud ja tõendid samaväärsuse kohta lisatud.

2 / 2

Koostatud 25.09.2025 16:55:29 https://riigihanked.riik.ee/rhr-web/#/procurement/9215726/general-info

Iga viidet, mille hankija teeb riigihanke alusdokumentides mõnele RHS-i § 88 lõikes 2 nimetatud alusele (standardile, tehnilisele tunnustusele, tehnilisele kontrollisüsteemile vms), tuleb lugeda selliselt, et see on täiendatud märkega „või sellega samaväärne“. Iga viidet, mille hankija teeb riigihanke alusdokumentides ostuallikale, protsessile, kaubamärgile, patendile, tüübile, päritolule, tootmisviisile, märgisele või vastavushindamisasutuse väljastatud katsearuandele või tõendile, tuleb lugeda selliselt, et see on täiendatud märkega „või sellega samaväärne“ (RHS § 88 lg-d 5-6, § 89 lg 2, 114 lg-d 5-7). Hankija aktsepteerib objektiivsetel põhjustel muid asjakohaseid tõendeid, kui pakkuja tõendab hankijale vastuvõetaval viisil, et pakutav asi, teenus või ehitustöö vastab konkreetse märgise või hankija esitatud nõuetele, välja arvatud juhul, kui hankija nõutud märgis, samaväärne märgis või konkreetse või samaväärse vastavushindamisasutuse väljastatud katsearuanne või muu tõend on seaduse alusel eelduseks asja, teenuse või ehitustöö pakkumiseks turul (RHS § 114 lg 7).

Ettevõtjalt oodatavad vastused: 1. Pakkuja kinnitab, et pakkumus vastab hanke alusdokumentides nõutule ja vajadusel on samaväärsus selgitatud ja tõendid samaväärsuse kohta lisatud. (Raadionupp valikutega "Jah/Ei")

Vastus: Jah

PROJEKTIPLAAN

Hangitavate tööde teostamise tegevuskava kirjeldatakse ära pakkumuse osana esitatavas projektiplaanis. Tegevuste ajalise järjestuse ja korduvuse valib pakkuja. Projektiplaan peab sisaldama ajakava kõikide tehnilises kirjelduses kirjeldatud tööde läbiviimiseks ja vastama projektiplaanile esitatud nõuetele (Lisa 7– Nõuded projektiplaanile). Lisaks projektiplaanile tuleb kirjeldada, kuidas projektijuhtimise riske maandada kavatsetakse (pakkumuse eraldi dokument). Riskide maandamise võimalused ja halduse ettepanekud (lähtuvalt käesolevast projektist) on esitatud selgelt, detailselt, läbimõeldult, struktureeritult ja põhjendatult.

Ettevõtjalt oodatavad vastused: 1. Projektiplaani esitamine (Vabas vormis dokument)

Vastus: 4_1_Riigikohtu veebilehe arenduse pakkumus.pdf, 4_1_Riigikohtu veebilehe arenduse projektiplaan.xlsx, 4_1_Riigikohtu veebilehe arenduse riskide halduse tegevuskava.pdf

Riigikohtu veebilehe

arenduse pakkumus

Viitenumber: 299179

Hankija: Registrite ja Infosüsteemide Keskus

Pakkuja:

ADM Interactive OÜ

10474271

Kultuurikatel, Kursi 3, 10415 Tallinn

www.adm.ee

Esindaja: Martin Orn

Kuupäev: 26.09.2025

2

Sisukord

Sisukord .......................................................................................................................................................2

Sissejuhatus .................................................................................................................................................3

1. Pakkumus ......................................................................................................................................4

2. Arendusprotsessi kirjeldus ............................................................................................................4

2.1 SCRUM arendusmetoodika ............................................................................................................4

2.2 Projektijuhtimine ...........................................................................................................................7

2.3 Detailanalüüs .................................................................................................................................8

2.4 Arendustööd ..................................................................................................................................8

3. Projekti ajakava .......................................................................................................................... 10

4. Riskide halduse tegevuskava ..................................................................................................... 11

3

Sissejuhatus

Käesolev pakkumus kirjeldab ADM Interactive OÜ (edaspidi Pakkuja) nägemust Riigikohtu (edaspidi

Klient või Hankija) veebilehe arendusest, mille tulemina valmib uus Riigikohtu veebileht.

Pakkumuse aluseks on riigihanke alusdokumendid viitenumbriga 299179.

Pakkumuse juurde kuuluvad kõik järgnevas tabelis olevad lisad:

Nimetus Faili nimi

Lisa 1 Projektiplaan Riigikohtu veebilehe arenduse projektiplaan.xlsx

Lisa 2 Riskide halduse tegevuskava Riigikohtu veebilehe arenduse riskide halduse

tegevuskava.pdf

4

1. Pakkumus

Projekti kestus: 6 kuud

Tarnemudel: kahes etapis

I etapp

Sisu: protsesside ja kasutajateekondade kaardistus ning analüüs, tehnilise lahenduse ja arhitektuuri

analüüs.

Tulemus: analüüsi tulemus on kooskõlastatud ja arenduse lähteülesanded valmis. Tehniline

platvorm loodud ja arenduseks valmis.

Maksumus: 14 550 €

II etapp

Sisu: front-end ja back-end arenduses veebilehe realiseerimine tuginedes analüüsi etapis saadud

sisendile.

Tulemus: kasutusvalmis ja dokumenteeritud veebileht kliendi keskkondades (dev, test, live), kõik

skoobis olnud arendustööd on lõppenud, kasutajad koolitatud.

Maksumus: 20 310 €

Kokkuvõte

Kogu projekti maksumus: 34 860 €

Tarnetähtaeg: 6 kuud lepingu sõlmimisest, planeeritud algusaeg 20. oktoober 2025.

Maksetingimused: etapiviisiline arveldamine vastavalt projektiplaanile.

2. Arendusprotsessi kirjeldus

Alljärgnevalt on kirjeldatud kasutatav arendusmetoodika sh arendusmeeskonna rollid, projektijuhtimise,

detailanalüüsi, disainiprotsessi, arendustööde ja testimise läbiviimise metoodikad.

2.1 SCRUM arendusmetoodika

Pakkuja rakendab standardset Scrum-põhist arendusmudelit, mis on tuntud paindliku ja iteratiivse

arendusmetoodikana ning mis on sobivaim Riigikohtu veebilehe arendamisel. Siin on mõned põhjused,

miks eelistada Scrumi arendusmetoodikat:

• Paindlikkus: Scrum võimaldab projektijuhtimises suuremat paindlikkust, s.h võimaldab ka

hilisemate muudatuse soovidega paindlikult kohaneda.

• Kasutaja kaasamine: Scrum keskendub tugevalt kasutajate vajadustele ja tagasisidele.

Riigikohtu veebileht teenindab erinevaid kasutajaid. Scrumi raames saab regulaarselt koguda

kasutajate tagasisidet ja kohandada veebilehte vastavalt nende vajadustele.

5

• Iteratiivne arendus: Scrum põhineb lühikestel arendustsüklitel, mida nimetatakse sprintideks.

Kasutame iteratsioone pikkusega 2 nädalat, mis tagab, et iga iteratsiooni lõpus tarnitakse

Hankijale valmis lahendus või funktsionaalsedkomponendid, mida on võimalik Hankijal testida

ja vastu võtta. Iga sprint toob kaasa funktsionaalsuse täiendamise. Riigikohtu veebilehe puhul

võib see tähendada järkjärgulist lisandumist uutele osadele või funktsioonidele, võimaldades

varajast tagasisidet ja võimalust kiiresti reageerida.

• Prioriteetide seadmine: Riigikohtu veebilehel on palju erinevaid funktsioone ja omadusi. Scrum

nõuab, et iga sprinti planeerides seataks prioriteedid ning tehtaks kõige olulisemad asjad

esimesena. See aitab tagada, et kõige olulisemad funktsioonid saavad kiiresti valmis.

• Meeskonnatöö rõhutamine: Scrum põhineb tugeval meeskonnatööl. Riigikohtu veebilehe

arendamine nõuab erinevate oskustega inimeste koostööd, näiteks disainerid, arendajad,

sisuloome eksperdid jne. Scrumi raames saavad nad regulaarselt suhelda ja lahendada

ülesandeid koos.

• Edenemise läbipaistvus: Scrumi korral pannakse suurt rõhku projekti läbipaistvusele.

Riigikohus on oluline organisatsioon, kus erinevad võtmeisikud soovivad kindlasti veebilehe

arengut jälgida. Scrum võimaldab luua nähtavaid edenemisnäitajaid ja aruandlusmehhanisme.

• Riske maandav lähenemine: Scrumis on sagedane tagasiside ja hindamine, mis aitab varakult

avastada võimalikke probleeme või takistusi. See võimaldab kiiresti reageerida ja vajadusel

korrigeerida arenduse suunda.

• Kvaliteedi tagamine: Scrumi raames on kvaliteedikontroll pidev protsess. Iga sprindi lõpus

viiakse läbi hindamine ja tagasiside kvaliteedi kohta ning vajadusel saab protsessi parandada.

„Kose“ meetodiga võrreldes on SCRUM metoodika põhilisteks erinevusteks:

• Kõrgema ärilise väärtusega funktsioonide arendamine esmajärjekorras;

• Hankijalt tagasiside saamine varakult, mis aitab vältida võimalikku teisiti arusaamist.

SCRUM on raamistik, mitte täpselt defineeritud protsess või metodoloogia ja sellel on lihtne struktuur,

mis sisaldab järgmiseid rolle:

• Tooteomanik (Product Owner) - vastutab investeeringutasuvuse ees, omab toote visiooni ja

ülevaadet kõikides nõuetest ning prioritiseerib arendusülesannete nimekirja. Tooteomanikuks

on üldjuhul Hankija projektijuht.

• Meeskond - tavaliselt 3 kuni 6 spetsialisti, kes teevad kõiki tarkvaraarenduseks vajalikke

tegevusi, s.h testimine. Parimate tulemuste saavutamiseks võiks meeskond asuda samas

füüsilises ruumis, kuid on võimalik luua virtuaalseid ruume MS Teamsis. Antud juhul koosneb

meeskond Pakkuja ja Hankija poolsetest spetsialistidest.

• ScrumMaster (SM) – hoiab toimivana SCRUM protsessi ning kõrvaldab takistused. Ta ei tee

ärilisi ega tehnilisi otsuseid ega meeskonnale määratud töid. Käesoleva hanke projektis on

ScrumMasteri roll Pakkuja projektijuhil.

Scrum protsess sisaldab järgmiseid koosolekuid:

• Sprindi planeerimine - tooteomanik ja meeskond räägivad iga iteratsiooni alguses läbi sprindi

sisu ja otsustavad, millised arendustööd sprinti võetakse. Tooteomanik vastutab prioriteetide

ning meeskond sprindi töömahu eest.

• Igapäevane stand-up - meeskonnaliikmed kohtuvad iga päev 15 minuti pikkusel koosolekul

ning raporteerivad üksteisele:

6

o Millega tegeleti eelmisel päeval;

o Millega tegeletakse käesoleval päeval;

o Millised on takistused.

• Sprindi demo – meeskond demonstreerib sprindi jooksul arendatud ja töötavat

funktsionaalsust tooteomanikule ja projekti teistele osalistele. Tooteomanik otsustab, millised

arendusülesanded võib lugeda tehtuks vastavalt eelnevatele kokkulepetele. Kui tulemus ei

vasta ootustele, lisab Pakkuja projektijuht vastavalt arutelule kommentaarid/otsused kohe

vastava ülesande alla Atlassian Jira keskkonnas, et kogu tööülesande kohta käiv info oleks

olemas ning kättesaadav ühes kohas ning arendajal oleks võimalik peale koosolekut

muudatused sisse viia. • Sprindi retrospektiiv - arutatakse, mis läks hästi, kuidas saab meeskond paremini toimida,

kuidas laiendatud meeskond (koos Hankijaga) saaks paremini toimida. Võetakse tegevusplaani

1-2 praktilist parandusmeedet järgmiseks iteratsiooniperioodiks fookusesse. Retro on

konstruktiivse tagasiside andmiseks, püüame analüüsida ning seeläbi parendada tulevikuks

koostööd ja protsesse. Pakkuja projektijuht dokumenteerib kõik retro raames loetletud

mõtted ja otsused Atlassian Confluence keskkonda.

Arendusülesandeid hallatakse tähtsuse järjekorras tootekirjelduse nimekirjas (backlog), mis on kogu

projektimeeskonnale kättesaadav. Arendusülesanne kirjeldab arendustööd MIDA vormis

kasutajakeskselt, sisaldab vastuvõtukriteeriume, töömahtu ja äriväärtust.

Iga sprinti planeeritud arendusülesanne peab sprindi lõpuks olema märgistatud kui „tehtud“. Siinjuures

on oluline arendusmeeskonna ja Tooteomanikuga täpselt kokku leppida „tehtud“ definitsioon, et kõigil

osapooltel oleks sellest ühine arusaam. Kui osa tööülesannetest saab tehtud, siis uuendab Pakkuja

poolne projektijuht järelejäänud tööde mahtu, et teada saada progressi indikatsioon. Operatiivsuse

tagamiseks veendub/uuendab Pakkuja poolne projektijuht igapäevaselt järelejäänud tööde mahtu.

Arendustööde haldamiseks on kasutusel Atlassian Jira tarkvara. Sprindi tööde nimekiri kuvatakse Jira

SRCUM tahvlil. See sisaldab sprinti planeeritud arendustöid, on nähtav kogu meeskonnale ja

vaadatakse üle igapäevasel staatuskoosolekul (stand-up).

Alljärgnevalt on kirjeldatud arendusmeeskonna rollid:

Tooteomanik on Hankija esindaja, kes vastutab agiilse arendusprotsessi puhul tööülesannete

kirjeldamise ja prioritiseerimise eest. Toote omanik on arendusmeeskonna peamine kontakt. On

projekti peavastutajaks Hankija poolel.

Projektijuht/Scrum Master on Pakkuja esindaja ja kliendisuhte eest vastutav isik, kes ühtlasi

koordineerib igapäeva arendustöid. On projekti peavastutajaks Pakkuja poolel. Scrum tiimis täidab

Scrum Masteri rollist tulenevaid ülesandeid, mille sisuks on eelkõige meeskonna tulemuslikkuse

parandamine ja läbipaistvuse tagamine.

Kasutajakogemuse ekspert, UX/UI disainer on vastutav eesmärgipärase ja kasutajasõbraliku veebiliidese

disaini eest, mis peab järgima parimaid kasutajakogemuse praktikaid ja vastama Hankija ärinõuetele.

Analüütik teostab süsteemi – ja kasutajanõuete detailanalüüsi alates esmakohtumisest kuni arendustöö

etappideni välja. Põhifookuseks on tõlkida Hankija äri- ja turunduseesmärgid sobivasse tehnilisse

lahendusse.

7

Arendaja ülesandeks on programmeerida veebilahendus vastavalt püstitatud eesmärgile ning

funktsionaalsetele- ja mittefunktsionaalsetele nõuetele. Arendajad on üldiselt spetsialiseerunud

esitluskihi (front-end) või äriloogika (back-end) arendajateks, et saavutada parem kuluefektiivsus ja

kõrgem kvaliteet.

Igasse arendusmeeskonda on kaasatud ka back-end vanemarendaja, kes täidab tehnilise juhi rolli ja

on kaasvastutajaks ärinõudeid täitva optimaalse lahenduse väljatöötamise eest. Suuremate

arendusmeeskondade puhul jagab tehniline vanemarendaja tööülesandeid esitluskihi või äriloogika

arendajate vahel ning teostab vajadusel järelkontrolli.

Kvaliteediekspert, testija vastutab selle eest, et loodav veebilahendus vastaks kvaliteedistandarditele

ja täidaks kokkulepitud funktsionaalseid- ja mittefunktsionaalseid nõudeid.

2.2 Projektijuhtimine

Kvaliteetne projektijuhtimine tagab õigete otsuste tegemise ning eelarve, aja ja funktsionaalsuse

piirangutes püsimise. Agiilse metoodika kasutamine tagab efektiivse teadmiste jagamise Hankija ja

Pakkuja vahel ning vähendab ühe inimese teadmistest tulenevaid riske. Töö teostamisel püstitame

Hankijaga ühised eesmärgid ning anname endast parima kliendi tegevusvaldkonna ja vajaduste

mõistmiseks.

Projektis kasutame kasutuslugudel põhinevat iteratiivset arendust, mis tagab projektijuhtimises

paindlikkuse ja kindluse, et kõik kliendi vajadused saavad täidetud. Iga iteratsiooni järel toimub loodud

lahenduse testimine koos kliendi esindajatega, et tagada vastavus nõuetele ja vajadustele. Samuti

vaadatakse üle projektiplaan, riskid ning järgmised kasutuslood. Võimalik on lisada uusi kasutuslugusid

või eemaldada olemasolevad ja samuti muuta nende prioriteetide iteratsioonides. Projektiplaan on

detailne ning sealt saab alati vastuse küsimustele, mida, millal ja kes teeb ning milline on projekti

hetke staatus.

Projektijuht juhib arendusmeeskonda ja vastutab seatud eesmärkide täitmise eest. Samuti ka tulemite

kvaliteetse ja õigeaegse tarne eest. Projektijuht vormistab kõik kokkulepped ning tagab

dokumentatsiooni kättesaadavuse Confluence´is. Samuti koostab ta arendusetappide üleandmise

dokumentatsiooni ning valmistab ette staatuskoosolekud Hankijaga.

Staatuskoosolekute idee on jälgida projekti üldist staatust ja võtta vajadusel vastu projekti edenemist

mõjutavaid otsuseid. Staatuskoosolekul osalevad nii Hankija kui Pakkuja esindajad. Eesmärk on:

• Projekti kulgemise jälgimine;

• Esialgsete kokkulepete muudatuste kooskõlastamine ja kinnitamine;

• Otsustamine tarkvara ekspluatatsioonivalmiduse üle projektimeeskonna sisendi põhjal;

• Projekti riskide analüüsimine ja hindamine, projekti riskiplaani kinnitamine;

• Kriisikommunikatsiooni juhtimine.

Projekt integreeritakse nii koodi kui dokumentatsiooni tasandil Atlassiani tooteplatvormile. Kasutame

projektijuhtimiseks tarkvara, mis hõlmab kogu tarkvaraarenduse protsessi, alates eelanalüüsist ja

lõpetades tarnega kliendile.

Projektijuhtimisel kasutatavad tarkvarad:

8

• Atlassian Confluence – projektiplaanide koostamine, projektijuhtimine ning detailanalüüsi

loomine;

• Atlassian JIRA – arendustööde haldus.

Projekt viiakse läbi kahes etapis:

• I etapi raames luuakse Riigikohtu veebilehe terviklik analüüs. Projekti I etapi läbiviimine koos

selle vaheetappidega on kajastatud pakkumuse lisas Riigikohtu veebilehe arenduse

projektiplaan ja kirjeldatud lahti peatükis Projekti ajakava

• II etapp sisaldab arendust, dokumentatsiooni loomist ning juurutamist.

2.3 Detailanalüüs

Detailanalüüs luuakse koostöös Tooteomanikuga ning aluseks võetakse hankes toodud prototüüp.

Detailanalüüsi tulemiks on kaardistatud ja kirjeldatud süsteeminõuded ja kasutajanõuded. Kaetud on

ka vajalike liideste detailanalüüs. Alameetapi kestvus on fikseeritud pakkumuse projektiplaanis.

Detailanalüüs hõlmab:

• Funktsionaalsete nõuete, ärireeglite kirjeldamine;

• Mittefunktsionaalsete nõuete kirjeldamine - kõik nõuded, mis ei ole funktsioonid või reeglid

kirjeldatakse mittefunktsionaalsete nõuete all;

• Kasutuslugude kirjeldamine - kasutuslugude kirjeldamise käigus koostatakse kõikide

kasutusjuhtude detailsed kirjeldused kasutaja ja süsteemi vahelise interaktsiooni vormis.

Analüüsi etapis on Hankija ülesanne panna kokku analüüsi töörühm, kes osaleb analüüsi koosolekutel

ning määrata igale ärivaldkonnale tooteomanik, kellel peab olema piisavalt teadmisi juhtimaks toote

valmimist. Analüüsi koosolekute ühe tulemina koostab Pakkuja analüütik ka kasutuslood, millele on

määratud aktsepteerimise kriteeriumid, mis võimaldavad defineerida mõlema poole jaoks vajalikud

kvaliteedinõuded ja vähendada erinevatest arusaamadest tulenevaid riske. Hankija tooteomanik

vastutab Pakkuja analüütiku poolt koostatud kasutuslugude kinnitamise eest.

Analüüsi protsessis kasutame üldjuhul Atlassian Confluence ja JIRA töövahendeid.

2.4 Arendustööd

Pakkuja realiseerib arendused vastavalt valminud detailanalüüsile Drupal 11 platvormile. Drupal on

avatud lähtekoodiga sisuhaldussüsteem (CMS), mis on laialdaselt kasutusel veebisaitide ja rakenduste

loomisel.

Riigikohtu veebilehe arendamisel on Drupal sobiv valik järgnevatel põhjustel:

• Skaleeritavus: Riigikohtu veebileht on ulatuslik, mitme erinevate saitidega ja sisaldab mitmeid

otsinguid. Drupal on tuntud oma võime poolest hakkama saada suurte ja keerukate

veebisaitidega ning hõlpsasti kohandatavate funktsioonide lisamisega.

9

• Mitmekülgsus: Riigikohtu veebileht vajab erinevaid tüüpe sisu, näiteks uudised, sündmused,

kasutajale suunatud teave jne. Drupal võimaldab luua mitmesuguseid sisutüüpe ja nende vahelisi

seoseid, mis aitab hoida veebilehe lihtsalt navigeeritavana.

• Kohandatavus: Riigikohtul on erinevaid disainilisi ja funktsionaalseid vajadusi. Drupal pakub laia

valikut teemasid ja mooduleid, mis võimaldavad veebilehte kohandada vastavalt ameti

kujundusega ning lisada vajalikke funktsioone.

• Turvalisus: Riigikohtu veebileht sisaldab tundlikku teavet. Drupal on tuntud oma turvalisuse

poolest, pakkudes turvauuendusi ja -parandusi, et kaitsta veebilehte potentsiaalsete turvariskide

eest.

• Mitmekeelsus: Kui Riigikohtul on rahvusvaheline kasutajaskond, võib vajadus mitmekeelse

veebilehe järele olla oluline. Drupal toetab mitmekeelset sisu ja pakub funktsionaalsust sisu

tõlkimiseks erinevatesse keeltesse.

• Tagasiside ja koostöö: Drupal võimaldab hõlpsalt luua veebisaidi erinevate osakondade ja

kategooriate vahel ning jagada vastutust sisu loomise ja haldamise eest. See aitab kaasa

tõhusamale koostööle ja tagasisidele.

• Pikaaegne tugi: Drupal on olnud turul juba pikka aega ja sellel on suur kogukond ning tugev

toetus. See tähendab, et vajalikud ressursid ja dokumentatsioon on laialdaselt kättesaadavad.

• Avatud lähtekood: Drupal on avatud lähtekoodiga tarkvara, mis tähendab, et selle kasutamine

on tasuta ning teil on suur kontroll kogu veebilehe üle.

Arendustöö toimub 2 nädalaste iteratsioonidena ning iteratsiooni lõpus tarnitakse Hankijale valmis

lahendus või funktsionaalsedkomponendid, mida on võimalik nii Pakkujal kui Hankijal enda poolt testida

ja formaalselt vastu võtta. Arendusel lähtume Hankija poolt seatud prioriteetidest, mida täpsustame

pärast iga iteratsiooni.

Arenduse teostamisel lähtume järgnevatest põhimõtetest:

• Arendus on tehtud avatud lähtekoodiga, ega too Hankijale kaasa kohustust hankida hiljem

täiendavaid tarkvaralitsentse;

• Kood on dokumenteeritud nii, et võimaldatud on selle edasiarendus tulevikus kolmandate

osapoolte poolt;

• Parandame vead enne järgmise töö alustamist, millega tagame olemasoleva funktsionaalsuse

töökindluse;

• Suuname vead võimalusel teisele arendajale, millega väldime ülekoormuse teket ühel arendajal

ja saavutame võimalikult kiiresti stabiilse versiooni;

• Kommenteerime koodi ja lihtsustame sellega olemasolevas koodis hiljem muudatuste tegemist

teiste arendajate poolt;

• Koodi ülevaatusega tagame koodi kvaliteedi;

Töö väljundiks on keskkonna algkood, mida on võimalik paigaldada sobivasse veebiserverisse. Arendatud

veebileht vastab WCAG 2.1 tasemele AA.

Iga iteratsiooni järel testib esmalt Pakkuja ning pärast seda Hankija ning vajadusel planeeritakse

ülejärgmisesse iteratsiooni veaparanduste realiseerimine. Arendusülesannete haldamiseks kasutatakse

Atlassian Jira tarkvara.

10

Analüütik täiendab ja kaasajastab arenduse teostamise etapis jooksvalt nõuete spetsifikatsiooni. Ta

kirjeldab uued lisandunud nõuded ja olemasolevate nõuete muudatused, säilitades neist ka eelnevad

versioonid. Kõik muudatuse kooskõlastatakse Hankijaga ja kommunikeeritakse projektimeeskonnale.

Iga iteratsiooni alguses lepitakse kokku iteratsiooniperioodi võetavad tööd ja perioodi lõpus näidatakse

Hankijale tulemit, millele järgneb Hankija poolne testimine. Iga iteratsioon sisaldab ajapuhvreid.

3. Projekti ajakava

Teostatava töö eesmärgiks on Riigikohtu veebilehe arenduse realiseerimine, et see oleks toodangusse

minekuks valmis. Projektiplaan on koostatud etapiviisiliselt, jagatud kahte etappi, mis omakorda on

jaotatud kahenädalasteks sprintideks. Kokku on 11 kahenädalast sprinti ja 1 ühenädalane sprint.

Projekt kestab kokku 6 kuud. Eeldus on, et projektiga saab alustada 20. oktoobril ja sellest tulenevalt

on projektiplaanis välja toodud pühade periood (jõulud, aastavahetus).

Pakkuja esitab esmase projektiplaani lähtudes varasemast kogemusest samaväärsete projektide

teostamisel ning hankedokumentatsioonist. Tegemist on esialgse nägemusega projektiplaanist, mida

täpsustatakse kohe projekti alguses. Projektiplaani koostamisel oleme lähtunud eeldusest, et

teostame töid 2 nädalaste sprintide ehk iteratsioonidena. Iga sprindi lõpus toimub kliendi demo.

Projektiplaani etappidesse oleme omalt poolt sisse planeerinud puhvrid, et oleks võimalik tagada

projektiplaanist kinni pidamine väiksemate riskide realiseerumisel. Projektijuhtimine toimub

igapäevaselt kogu projekti jooksul ning selle maht on arvestatud kõigi teostatavate tööde sisse.

Detailne projektiplaan on toodud pakkumuse lisana Riigikohtu veebilehe arenduse projektiplaan.xslx.

Kujutatud on kõigi tegevuste jaotus nädalate kaupa jaotatuna 2 nädalastesse sprintidesse ning välja

on toodud hankedokumentides nõutud detailid.

Projektiplaan kinnitatakse kohe projekti esimeses etapis koostöös Hankijaga ning selle täitmist juhib

Pakkuja poolne projektijuht, kes tegeleb igapäevaselt meeskonna juhtimisega, projekti eesmärkide

saavutamise tagamisega ning vastutab ühtlasi tulemite kvaliteetse ja õigeaegse tarne eest. Projektijuht

vormistab kirjalikult kõik kokkulepped ning teeb kogu dokumentatsiooni projektimeeskonnale

digitaalselt kättesaadavaks. Projekti kokkulepete ja plaanide haldamine toimub Atlassian

Confluence´is.

Projekti eesmärkide saavutamise tagamiseks toimuvad regulaarsed töökoosolekud, kus osalevad

mõlema osapoole projektijuhid või seda rolli täitvad isikud ja teised vajalikud isikud. Töökoosolekud

toimuvad vastavalt omavahelisele kokkuleppele ning nende korraldajaks on üldjuhul Pakkuja poolne

projektijuht. Vajadusel võib koosoleku kokku kutsuda ka Hankija projektijuht. Eesmärgiks on riskide

maandamine võimalikult varakult ning tööde kulgemise tagamine vastavalt projektiplaanile.

Projekti kõige esimesel nädalal toimub projekti kick-off ning valmistatakse ette ja lepitakse kokku projekti

kodukord. Täpsustakse üle:

• arenduspõhimõtted;

• suhtluskanalid;

• regulaarsed koosolekud;

• rollide ja vastutuse jaotus;

11

• koosolekute põhimõtted ja protokollimise eest vastutavad isikud;

• arendusülesannete haldamise keskkonna ettevalmistamine ja selle töövood;

• dokumentatsiooni haldamise ja säilitamise keskkond ja tööde dokumenteerimise kord;

• ligipääsude vajalikkus projekti keskkondadesse;

• tööaja märkimine;

• riskide haldamine;

• jms

Eesmärk on tagada, et projektimeeskond saab eesmärkidest ja tegevustest ühtemoodi aru. Projekti

avakoosolekul osaleb kogu projekti meeskond.

Hankija poolelt on kavandamise etapis vajalik:

• Määrata projektile järgnevaid rolle täitvad isikud: tooteomanik, projektijuht, IT tehniline kontakt,

peaarhitekt, vastuvõtu testija(d);

• Osaleda projekti koostöökokkulepete tegemise arutelus.

4. Riskide halduse tegevuskava

Riskide hindamine ja nende maandamise planeerimine on projektijuhtimise oluliseks osaks ning

mõjutab projekti tulemite tarnet kokkulepitud ajakavas ja mahus. Projekti riskide hindamisel

hinnatakse riski esinemise tõenäosust ehk seda, millise sagedusega võib konkreetne risk avalduda.

Samuti hinnatakse kahju, mida riski avaldumine võib projektile põhjustada. Riskid jagatakse eraldi

alamkategooriatesse ning nummerdatakse Hankija projektijuhi või tootejuhiga kokkulepitud reeglite

alusel ehk iga risk saab unikaalse identifikaatori.

Projekti riskianalüüs kirjeldab riske ning annab neile mõjuhinnangu. Samuti kaardistab riskide

tagajärjed, kirjeldab võimalused nende maandamiseks või kõrvaldamiseks ja määrab vastutajad.

Riskide juhtimisega tegeldakse kogu projekti vältel. Riskid esmalt määratletakse, analüüsitakse ja

hinnatakse. Riskide määratlemisse ja ennetavate tegevuste väljatöötamisse peaksid olema kaasatud

Hankija ja Pakkuja projektimeeskonnad. Määratletud riskide analüüsimisse ja hindamisse peaks

Pakkuja hinnangul olema kaasatud ka projekti juhtrühm.

Põhjalikum riskianalüüs, hindamine ja riskiplaani kinnitamine viiakse läbi enne projekti elluviimist,

näiteks avakoosoleku osana.

Projekti riskid on pidevas muutmises ning seetõttu on oluline, et riskide hindamist viiakse läbi

regulaarselt. Riskide maandamise tegevuste planeerimisel keskendutakse riskidele, mis on hinnatud

keskmise või kõrgema tõenäosusega ning mille mõju on keskmine või suur. Allpool esitatud maatriksi

järgi kuuluvad need riskid „kollasesse“ või „punasesse“ tsooni. Riskide juhtimise ning

maandustegevuste käigus määratakse igale tegevusele tähtaeg ning vastutaja.

12

Tabel 1: Riskimaatriks

Kui riski realiseerumine mõjutab projektiplaani järgset tähtaega, siis leitakse lahendus alati koos

Hankijaga.

Riskide halduse tegevuskava on toodud välja pakkumuse lisas Riigikohtu veebilehe arenduse riskide

halduse tegevuskava.pdf

Tabelis on toodud välja kõik olulised Hankijast, Pakkujast ja projekti olemusest (või kolmandast

osapoolest) tulenevad ohud, mis võivad takistada projekti edukat kulgu. Iga riski kohta on toodud välja

tema mõjuhinnang, esinemistõenäosus, tagajärjed riski realiseerumisel, maandamismeetmete

kirjeldus, tegevuskava riski realiseerumise korral ning maandamismeetme toestamise ja tegevuskava

käivitamise eest vastutavad rollid.

Riigikohtu veebilehe arenduse riskide halduse tegevuskava

Legend (Tabel 1):

Risk Seotud rollid / tegevused

Mõju Tõenäosus Maandamine

Nõuete muutumine projekti käigus

Analüütik, PJ, kliendi esindajad

Suurendab ajakulu ja eelarvet

Keskmine Varajane nõuete kinnitamine, muudatuste juhtimise protsess

Ligipääsude viibimine kliendi keskkondadesse

PJ, Arhitekt/DevOps, BE/FE arendajad

Arenduse algus hilineb

Keskmine Ligipääsud taotleda enne kick- off’i, määrata vastutaja

Atlassiani tööriistade hiline seadistamine

PJ, Analüütik Dokumentatsioon hajub, töökorraldus kannatab

Väike Jira/Confluence seadistada enne detailanalüüsi algust

Äriprotsesside (lahendite sisestus/otsing) alahindamine

Analüütik, BE, FE Hilisemad lisaarendused, testide lisandumine

Keskmine Detailne töövoo analüüs (sisestaja → avalik veeb) sprintides 0–2

WCAG nõuete täitmata jätmine

Disainer, FE arendaja, Testija

Võib põhjustada projekti tagasilükkamise

Keskmine WCAG kontrollid igas sprindis, eraldi ligipääsetavuse testid

Integratsioonide keerukus

Arhitekt, BE arendaja

Projekti ajakava venib, turvariskid

Keskmine Varajane tehniline analüüs, proof-of- concept testid

Helm chartide ja kooditarne probleemid kliendi Kubernetes keskkonnas

Arhitekt/DevOps, BE

Deployment ebaõnnestub, live viibib

Keskmine Varajane kokkulepe keskkondade halduse osas, dev/test

paigalduse testimine enne live’i

Ressursi kättesaadavus (analüütik, disainer, testija)

PJ, kõik rollid Sprintide viibimine

Keskmine Ressursiplaan ja backup-ressursid, prioriteetide selge juhtimine

Testimise alahindamine (BE/FE)

Testija, BE, FE, PJ Defektid live’is, mainekahju

Keskmine Testide planeerimine ja automaatsete testide kasutamine

Koolituste läbiviimata jätmine

PJ Kasutajad ei saa süsteemi kasutada

Väike Koolitused planeerida vähemalt 1 sprint enne live’i

Dokumentatsiooni puudulikkus (paigaldusjuhend, analüüs, kasutusjuhend)

PJ, Analüütik, Arhitekt

Üleandmine venib, hooldus keeruline

Keskmine Dokumentatsiooni kirjutamine paralleelselt töödega, QA ülevaatus

Nõuded arendustele versioon 7.0 §Requirements

Võti Noude liikKokkuvõte Kirjeldus Olek Täitmise

eest

vastutaja

NA-1 Andme kvalitee t ja standar did

Loodavate lahenduste X-tee teenused peavad vastama RIA x-tee juhendis toodud nõuetele.

KEHTIV Arhitekt /juhtiv arendaja

NA-2 Andme kvalitee t ja standar did

Lahendusega koos tarnitav standardtarkvara peab vastama RIK nõuetele.

Kui hankes ei spetsifitseerita tarkvaralist lahendust tuleb kasutada vastaval konkreetsele vajadusel allpool toodud tarkvarade viimaseid stabiilseid versioone.

Serverite operatsioonisüsteemina: 1) Linux RedHat Enterprise/Rocky 2) Windows

Andmebaasidena: 1) Microsoft SQL 2) Postgre SQL 3) MariaDB

Veebiserverina: 1) Nginx 2) Microsoft IIS 3) Apache

Rakendusserverina: 1) Tomcat

Programmeerimiskeelena : 1) C# 2) Java 3) Python

Kui koos tarnega tarnitakse kommertstarkvara peab selle litsents sisaldama vähemalt 5 aasta turvaparandusi

KEHTIV Arhitekt /juhtiv arendaja

NA-3 Andme kvalitee t ja standar did

Rakendus peab olema loodud vastavalt Eesti Infoturbestandardi nõuetele.

Aluseks tuleb võtta hanke väljakuulutamise hetkel kehtiva versiooni meetmeid. KEHTIV Arhitekt /juhtiv arendaja

NA-4 Andme kvalitee t ja standar did

Avalik sektor arendab riigi tarkvara eelkõige avatult ja avaldab tarkvara vaba litsentsiga vastavalt litsentsi nõuetele.

Antud nõudes võib erandeid teha ainult juhul, kui on teisiti ette nähtud seadusega või muul tellijaga kokku lepitud põhjendatud juhul.

RIKis kasutatavad levinuimad vaba tarkvara litsentsid on EUPL, GNU GPL, MIT. Litsentsi valik sõltub vajadustest ja kohustustest ning tuleb kokku leppida tellijaga.

Litsentside litsentsitingimustes sisalduvad nõuded, mida tuleb litsentsi kasutamisel täita, on järgmised: EUPLi puhul on nõutav mh: 1) autoriõiguse märge päises (Copyright © <aasta> <autori nimi>), mille järel on märge „Litsentsitud EUPL alusel “).

GNU GPL puhul on nõutav mh: 1) autoriõiguse märge päises (Copyright © <aasta> <autori nimi>); 2) litsentsitingimustes ette nähtud teavitus töö osas garantii välistamise kohta.

MIT puhul on nõutav mh: 1) autoriõiguse märge päises (Copyright © <aasta> <autori nimi>) koos litsentsis ette nähtud teavitusega; 2) litsentsitingimustes ette nähtud teavitus töö osas garantii välistuse kohta.

Täpsemalt tuleb nõuetega tutvuda lähtudes valitud litsentsitüübi litsentsitingimustest. Valitud litsentsi litsentsitingimused esitatakse ühel või mõlemal alljärgnevatest viisidest: 1) LICENCE-fail peab olema repositooriumis avalikustatud koos tarkvara koodiga; 2) litsentsitingimuste tekst iga faili päises; 3) lisades päisesse link asukohale, kus on võimalik litsentsitingimustega tutvuda.

KEHTIV Tiimijuht

NA-5 Arhitekt uur

Komponendid peavad olema sellised, mille eluea lõpp (EOL) pole teadaolevalt vähem kui 2 aasta pärast.

Erindid tuleb eraldi kokku leppida Strateegia tiimiga. KEHTIV Arhitekt /juhtiv arendaja

NA-6 Arhitekt uur

Infosüsteemide komponendid ja topoloogia peab olema enne reaalse arenduse algust RIK-iga kooskõlastatud.

Kooskõlastamist koordineerib Strateegia tiim (peaarhitekt). KEHTIV Arhitekt /juhtiv arendaja

NA-7 Arhitekt uur

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

KEHTIV Arhitekt /juhtiv arendaja

NA-8 Arhitekt uur

Rakendust peab saama ilma ümber programmeerimata liigutada erinevate domeenide ja domeeni saitide vahel

Lahendus ei tohi olla sisse kompileeritud absoluutseid URL-e. KEHTIV Arhitekt /juhtiv arendaja

NA-9 Arhitekt uur

Väliseid liidestusi peab olema nii vähe, kui võimalik. Liideseid peab saama konfiguratsioonist välja lülitada. Väliste liidestuste veaolukorrad peavad olema käsitletud. Süsteem peab toimima mitte-ärikriitiliste liidestusteta.

KEHTIV Arhitekt /juhtiv arendaja

NA-10 Arhitekt uur

Andmevahetus riigi infosüsteemi kuuluvate andmekogudega ja riigi infosüsteemi kuuluvate andmekogude vahel toimub läbi riigi infosüsteemi andmevahetuskihi (x-tee).

Avaliku teabe seaduse § 43 (9) lõige 5. Kui X-tee päringut teostab inimene, siis peab olema päringu päises autentinud kasutaja andmed.

KEHTIV Arhitekt /juhtiv arendaja

NA-11 Arhitekt uur

Rakenduste keskkonnad peavad kasutama vastavate X-tee turvaserverite otspunkte.

Arendus vastu arenduse otspuntki jne. KEHTIV Arhitekt /juhtiv arendaja

NA-12 Arhitekt uur

Rakendus peab olema konfigureeritav ühest kohast ilma kompileerimisvajaduseta.

Konfiguratsiooni võib vajadusel automaatselt kopeerida, ilma muutmata, kesksest kohast mujale (näiteks helm chartis values failist kopeerimine mitmesse configmapi). Logimise seaded võivad olla rakenduse konfiguratsioonifailist eraldi ühes lisakonfiguratsioonifailis (näiteks Log4net).

KEHTIV Arhitekt /juhtiv arendaja

NA-13 Arhitekt uur

Kompileeritud rakenduse paigaldamine peab toimuma mõistliku aja jooksul.

Mõistlik aeg on kuni 1 minut. KEHTIV Arhitekt /juhtiv arendaja

NA-14 Arhitekt uur

Rakendus peab olema 64-bitine. KEHTIV Arhitekt /juhtiv arendaja

NA-15 Arhitekt uur

Andmebaas ja rakendus peavad kasutama UTF-8 kodeeringut.

Nõue kehtib Oracle ja Postgre andmebaaside puhul. Erindid lepitakse eraldi Strateegia tiimiga kokku. Näiteks UTF-16.

KEHTIV Arhitekt /juhtiv arendaja

NA-16 Arhitekt uur

Failid peab katalogiseerima aasta > kuu > kuupäev. Täpsem lahendus leppida Strateegia tiimiga kokku. KEHTIV Arhitekt /juhtiv arendaja

NA-17 Arhitekt uur

Üldine programmeerimise paradigma on objekt- orienteeritud.

Erindid tuleb eraldi Strateegia tiimiga kokku leppida. KEHTIV Arhitekt /juhtiv arendaja

NA-18 Arhitekt uur

Kõik baasitabelite välisvõtmed peavad olema indekseeritud.

Indekseid ja muid meetmeid kasutatakse andmebaasi jõudluse tõstmiseks. Väliseid võtmeid tuleb kasutada ka ühest andmebaasist teisele viitamisel.

KEHTIV Arhitekt /juhtiv arendaja

NA-19 Arhitekt uur

Tuleb kasutada päringumuutujaid (inglise keeles "Parameter Binding")

SQL päringute väljakutsumisel väljastpoolt andmebaasi peab kasutama päringumuutujaid, et vältida SQL vahemälu fragmenteerumist.

KEHTIV Arhitekt /juhtiv arendaja

NA-20 Arhitekt uur

Andmebaasitabelites peab olema tehniline primaarvõti.

Nimetus peab olema „ID“ KEHTIV Arhitekt /juhtiv arendaja

NA-21 Arhitekt uur

Failid ja failide indeks peavad olema replikeeritavad teise serveriruumi.

Failide hoidmise asukoht ja loogika on vastavalt kokkuleppele. KEHTIV Arhitekt /juhtiv arendaja

NA-22 Arhitekt uur

Haldustoimingute tegemiseks peab olema vastav haldusliides.

Eemärk on vähendada otse baasis tehtavaid toiminguid. KEHTIV Arhitekt /juhtiv arendaja

NA-23 Arhitekt uur

Andmebaas peab toetama külm- ja kuumvarundamist teise serveriruumi.

Ei tohi kasutada teenuseid, mis välistavad andmebaasi peegeldamist (nt "failstream"). KEHTIV Arhitekt /juhtiv arendaja

NA-24 Arhitekt uur

Sorteerimisreeglistik peab vastama eesti keele tähestikule.

Peab kasutama case-insensitive, accent-sensitive sorteerimist. KEHTIV Arhitekt /juhtiv arendaja

NA-25 Arhitekt uur

Kasutama peab RIK-i elektronposti serverit. Kirjade saatmine ja mall peavad olema konfigureeritavad. Juhul kui elektronposti server ei võta kirju vastu, siis tuleb need uuesti saata elektronposti teenuse taastumisel.

KEHTIV Arhitekt /juhtiv arendaja

NA-26 Arhitekt uur

Konfiguratsiooniparameetrite nimed peavad olema sisulised.

Näiteks : X-tee Turvaserver, mitte XTTS või viitenumber, mitte vk_seb jne. KEHTIV Arhitekt /juhtiv arendaja

NA-27 Arhitekt uur

Ees -ja tagasüsteemid peavad olema arhitektuuriliselt selgelt lahutatud.

Ees -ja tagasüsteemid peavad olema eraldi paigaldatavad ja konfigureeritavad. KEHTIV Arhitekt /juhtiv arendaja

NA-28 Arhitekt uur

Konfiguratsioonifailid peavad olema vaikimisi kaitstud failid.

Näiteks IIS: *.config , *.resources Apache: *.conf, .htaccess. Kui neid on mitu, siis arendaja peab need eraldi välja tooma konfiguratsioonifailide listis. 

KEHTIV Arhitekt /juhtiv arendaja

NA-29 Arhitekt uur

Lõpp-kasutaja näeb vaid faile, mida ta peab nägema.

KEHTIV Arhitekt /juhtiv arendaja

NA-30 Arhitekt uur

Konfiguratsioonis ei tohi olla sisult dubleerivaid parameetreid.

Kõiki parameetreid tuleks konfiguratsioonis kirjeldada vaid üks kord.

Näiteks nii ei tohi olla: = "Server=myServerAddress;Database=myDataBase;User Id=myUsername;connectionString

Password=myPassword;" = "Server=myServerAddress;Database=myDataBase;User Id=myUsername;Password=myPassword;"_cString

KEHTIV Arhitekt /juhtiv arendaja

NA-31 Arhitekt uur

Rakendused peavad olema kõrgkäideldavad. Meie arendatud rakendused ja kasutatavad karbitooted peavad olema kõrgkäideldavad. ei ole Sticky sessionid soovitatud, vajadus eraldi läbi rääkida.

KEHTIV Arhitekt /juhtiv arendaja

NA-32 Arhitekt uur

Süsteemiintegratsioonid peavad klientrakendusele olema peidetud.

Näiteks klientrakendus ei tohi pöörduda otse andmebaasi ja x-tee poole. KEHTIV Arhitekt /juhtiv arendaja

NA-33 Arhitekt uur

Keskkonnapõhiseid muutujad peavad olema konfiguratsioonist seadistatavad.

Näiteks WSDL ei tohi sisaldada viiteid arendusserveritele. KEHTIV Arhitekt /juhtiv arendaja

NA-34 Arhitekt uur

Windows teenuste nimed peavad olema konfigureeritavad.

KEHTIV Arhitekt /juhtiv arendaja

NA-35 Arhitekt uur

Andmebaasi ei tohi realiseerida rakenduse äriloogikat.

Andmebaas võib sissetulevate andmetega teha ainult tehnilisi tegevusi. Välja arvatud taustatööd. Näiteks õiguste arvutamine või unikaalsete võtmete genereerimine.

KEHTIV Arhitekt /juhtiv arendaja

NA-36 Arhitekt uur

Andmebaasi peab olema võimalik viia MS-SQL standarditele.

Ei tohi kasutada platvormispetsiifilist lahendusi. Erindid eraldi kokku leppida Strateegia tiimiga. KEHTIV Arhitekt /juhtiv arendaja

NA-37 Arhitekt uur

Rakendus peab kasutama autentimiseks RIK poolt heaks kiidetud OpenID põhist autentimislahendust.

Autentimisviisid peavad olema konfigureeritavad. Samuti peab rakenduse konfiguratsioonist olema määratav, kas ID-kaardiga autentimise korral kasutatakse OCSP või tühistusnimekirjade põhist autentimist.

KEHTIV Arhitekt /juhtiv arendaja

NA-38 Arhitekt uur

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

Max uri < 2000. KEHTIV Arhitekt /juhtiv arendaja

NA-39 Arhitekt uur

Rakenduse teenusekirjeldus peab olema üles ehitatud nii, et see toetaks teenuse versioneerimist.

Teenuste kirjelduses võimalike complexType versioonide väärtus "any" KEHTIV Arhitekt /juhtiv arendaja

NA-40 Arhitekt uur

Rakenduse operatiivbaas peab olema arhiveeritav. Enamasti tehakse seda osadena, näiteks juriidiliselt aegunud menetlused, mida kasutajad enam ei näe. KEHTIV Arhitekt /juhtiv arendaja

NA-41 Arhitekt uur

Rakendusega tarnitavad litsentsid peavad olema vähemalt 5-aastase kehtivusajaga.

EU projektide korral tuleb kehtivusaja suhtes lähtuda EU või RIA nõuetest. KEHTIV Tiimijuht

NA-42 Arhitekt uur

Rakendus peab olema jaotatud loogilisteks tehnilisteks osadeks.

Loogiline jaotus lähtub äri vajadustest, haldusest ja arendusest. Tehnilised osad peavad olema eraldi paigaldatavad.

KEHTIV Arhitekt /juhtiv arendaja

NA-43 Arhitekt uur

Failide konverteerimised tuleb teha kasutades RIKi poolt heaks kiidetud teenuseid.

KEHTIV Arhitekt /juhtiv arendaja

NA-44 Arhitekt uur

Kasutaja ei tohi pääseda ligi süsteemi tehnilisele informatsioonile.

Näiteks stack trace, tehnilised logid, täispikavad failinimed, kasutatavad tehnoloogiad ja raamistikud ning nende versioonid.

KEHTIV Arhitekt /juhtiv arendaja

NA-45 Arhitekt uur

Rakendus peab olema stateless. Peab töötama koormusjaoturiga, ei kasuta , SSL offload.sticky sessioneid KEHTIV Arhitekt /juhtiv arendaja

NA-46 Arhitekt uur

Rakenduse failide ligipääsuvajadus peab olema read-execute.

Konteinerite puhul vastutab arendaja, muul juhul administraator. KEHTIV Arendaja /juhtiv arendaja /administraat or

NA-47 Arhitekt uur

Windows serverid peavad töötama windows core serveritel.

KEHTIV Arhitekt /juhtiv arendaja

NA-48 Arhitekt uur

Andmebaasis tuleb veerutüübiks määrata selleks sisuliselt sobivaim andmetüüp.

Lähtuda andmebaasimootori dokumentatsioonist. Keelatud on kasutada (max) tüüpe, kui see pole põhjendatud ja vajalik.

KEHTIV Arhitekt /juhtiv arendaja

NA-49 Arhitekt uur

Rakenduste masinliidestel peab olema publitseeritud tehniline spetsifikatsioon.

Ei kehti karbitoodetele. Näiteks SOAP WSDL ja REST OpenApi Swagger ei tohi olla publitseeritud.

Tehnilises spetsifikatsioonis peavad olema: otspunkti kirjeldus, otspunkti kirjelduse väljalülitamine.

KEHTIV Arhitekt /juhtiv arendaja

NA-50 Arhitekt uur

Active Directory(AD) autentimise kasutamisel peab rakendus kasutama kehtivaid standardeid.

SAML2.0 (Security Assertion Markup Language) ja ADFS (Active Directory Federation Services). KEHTIV Arhitekt /juhtiv arendaja

NA-51 Arhitekt uur

ID-kaardiga autentimise korral kliendipoolne veebirakendus suhtleb veebirakendusega ainult kontrollküsimuse tarbeks.

Edasine koodi täitmine ja võimalike veaolukordade töötlus peab toimuma rangelt ainult kliendi poolel.

Kliendi autentimissertifikaadi kehtivus- ja autentsusekontroll teostatakse maksimaalses võimalikus mahus veebiserveri või proxy poolt.

Autentimissertifikaadil on veebiserveri või proxy poolt kohustuslikult nõutav: Apache: SSLVerifyClient require; NGINX: ssl_verify_client on; Pulse TM: ssl.requireCert(); HAProxy: verify required; Tomcat: clientAuth="true"; jne…                    

Juhul kui toimub pöördub URL poole, kus on nõutud kliendi autentimissertifikaat ning server vastab veaga, peab klientrakendus kuvama korrektse veateate eesti keeles.

KEHTIV Arhitekt /juhtiv arendaja

NA-52 Arhitekt uur

Robotilõksude kasutamine ja valik tuleb kooskõlastada RIK-ga.

Soovitus on robotlõkse vältida ja lahendada potentsiaalne probleem kasutades koormusjaotureid ja IP-põhiseid reegleid.

KEHTIV Arhitekt /juhtiv arendaja

NA-53 Arhitekt uur

Rakendusetevaheline suhtlus peab olema masintöödeldav.

Üldiselt kasutame REST, SOAP(x-tee) või message queued. Muud juhud eraldi läbi rääkida Strateegia tiimiga. KEHTIV Arhitekt /juhtiv arendaja

NA-54 Arhitekt uur

Rakendusserverite otspunktid peavad olema piiratud ja dokumenteeritud.

Rakendus vastab ainult lubatud HTTP-meetoditele, ülejäänud annavad veakoodiga "405" viga. KEHTIV Arhitekt /juhtiv arendaja

NA-55 Arhitekt uur

Rakendusserver peab valideerima ja võimalusel verifitseerima e-posti aadresse.

Peab vastama RFC5322 ja/või RFC6854 standardile.

Võimalusel peab süsteem tõendama kasutaja e-posti aadresse(verifitiseerima)

KEHTIV Arhitekt /juhtiv arendaja

NA-56 Arhitekt uur

Rakendusel peab olema minimaalne CSP header, et funktsionaalsust tagada.

Erandid tuleb hoolikalt läbi mõelda. Väikeväärtus "self"

Täiendav info:

https://csp-evaluator.withgoogle.com/ https://www.hardenize.com/dashboards https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-WebSocket-Accept

KEHTIV Arhitekt /juhtiv arendaja

NA-57 Infoturv e

Kliendi ja serveri vaheline suhtlus peab kasutama TLS-protokolli.

Uusim või kehtiva toega versioon. KEHTIV Arhitekt /juhtiv arendaja

NA-58 Infoturv e

Andmete salvestamisel kliendi arvutisse kasutada baruseri vault-i.

Erandiks on mitmekeelse süsteemi puhul keelevalik. KEHTIV Arhitekt /juhtiv arendaja

NA-59 Infoturv e

Sessiooni lõpetamisel või aegumisel ei tohi kasutajal olla võimalik sessiooni värskendada või uuesti kasutada.

KEHTIV Arhitekt /juhtiv arendaja

NA-60 Infoturv e

Andmebaasis olevate terviklikkuse turvaosaklass 2 või 3 andmete andmebaasi kirjed peab versioneerima.

Versioneerimisel peavad säilima vanad kirjed muutumatul kujul. Uue kirje tehnilistel väljadel peab olema: Kasutaja, kes kirje lõi ja loomise aeg. Kehtetuks tunnistatud kirje peab sisaldama: Kirje muutja, muutmise /kustutamise aeg.

KEHTIV Arhitekt /juhtiv arendaja

NA-61 Infoturv e

Live andmed ei kasutata testimiseks. Testimiseks kasutatakse sünteetilisi, genereeritud andmeid. Erindid tuleb Strateegia tiimiga eraldi kokku leppida.

KEHTIV Arhitekt /juhtiv arendaja

NA-62 Infoturv e

Rakenduse andmebaasikontod peavad omama minimaalseid õigusi.

Rakendus ei kasuta kontot. Kontodele vajalikud õigused peavad olema kirjeldatud rakenduse schema installatsioonijuhendis.

KEHTIV Arhitekt /juhtiv arendaja

NA-63 Infoturv e

Rakenduse lõppkasutajatele peavad olema õigused defineeritud läbi rollide(RBAC).

Kasutada KeyCloaki. AD OU ei tohi anda rolli. KEHTIV Arhitekt /juhtiv arendaja

NA-64 Infoturv e

Rakendusse ja andmebaasi ligipääsemiseks peab kasutama ainult kokkulepitud dokumenteeritud autentimisprotseduure.

KEHTIV Arhitekt /juhtiv arendaja

NA-65 Infoturv e

Salasõnad salvestatakse turvaliselt. Krüpteering peab olema CBC, CRT vms režiimis. Kasutada ei tohi ECB režiimi. Räsi+sool+pipar osas lähtuda OWASP-i juhisest https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html

KEHTIV Arhitekt /juhtiv arendaja

NA-68 Infoturv e

Kõik avalikud veebirakendused peavad kasutama veebitulemüüre.

IIS puhul peab kasutama näiteks URL scan, apache puhul modsecurity või vastavat tööriista. Võimalikud piirangud tuleb kokku leppida tellijaga detailanalüüsi käigus lähtuvalt tellija vajadustest ja nõudmistest. Kasutama peab whitelisting põhimõtet, mitte blacklistingut. Täiendavalt on kasutusel veebitulemüür (CloudFlare)

KEHTIV Arhitekt /juhtiv arendaja

NA-69 Infoturv e

Rakendus peab õnnestunud sisselogimise järgselt näitama eelmise õnnestunud sisselogimise aega.

EU-direktiiv https://www.etsi.org/deliver/etsi_en/301500_301599/301549/03.02.01_60/en_301549v030201p.pdf KEHTIV Arhitekt /juhtiv arendaja

NA-70 Infoturv e

Kasutajaliidesega rakendusel peab olema esilehel rakenduse versioon.

Mõeldud on majas sees arendatud rakendusi. Rakendusserverite ja andmebaaside puhul kehtib vastupidine nõue: .NA-44

KEHTIV Arhitekt /juhtiv arendaja

NA-71 Infoturv e

Sessioonide lõpetamine tuleb teostada serveri poolel ja kõigil rakendustel peab olema konfigureeritav kasutajasessiooni aegumise aeg.

Aeg peab olema muudetav koos teiste konfiguratsiooniparameetritega. Kui kliendilt pole etteantud aja jooksul ühtegi päringut tulnud, tuleb sessioon serveri enda algatusel lõpetada.

Täiendavalt saab lugeda https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet. html

KEHTIV Arhitekt /juhtiv arendaja

NA-72 Infoturv e

Kõik sisendandmed tuleb kodeerida, filtreerida ja valideerida.

Siia hulka kuuluvad vormid, masin-masin liidesed ja veebiteenused. Tuleb teha enne igasugust äriloogika täitmist.

KEHTIV Arhitekt /juhtiv arendaja

NA-73 Infoturv e

Veebipõhiste rakenduste poolt saadetavad vormidel peab paiknema peidetud unikaalne räsi, mida kontrollitakse vormi vastuvõtmisel.

Eesmärk on vältida CSRF rünnakuid. KEHTIV Arhitekt /juhtiv arendaja

NA-74 Infoturv e

Krüpteerimisel ja räsimisel tuleb lähtuda RIA uuringust.

Lähtuda viimasest dokumendist siin nimekirjas https://www.id.ee/artikkel/kruptograafiliste-algoritmide-elutsukli- uuringud-2/

KEHTIV Arhitekt /juhtiv arendaja

NA-75 Infoturv e

Sessiooni tunnused ei tohi olla URL-st kopeeritavad.

https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html KEHTIV Arhitekt /juhtiv arendaja

NA-76 Infoturv e

Konfiguratsioonifaile võivad muuta vaid administraatorid.

Kui rakendusel on admin liides arendatud siis seal muudatuste tegemine on OK. Muud erindid rääkida läbi strateegiatiimiga.

KEHTIV Arhitekt /juhtiv arendaja

NA-77 Infoturv e

Kliendi sertifikaadiga rakenduse poolsel autentimisel (näiteks ID-kaart) peab rakendus vastu võtma sertifikaati HTTP päises.

Kliendi sertifikaadiga autentimisel peaks süsteem vastu võtma kliendi sertifikaati kokkulepitud päises, päise nimi peaks olema rakenduse seadistustega muudetav. Vajadus tuleneb kliendi sertifikaatide usaldusnimekirjade GLB taseme haldusest. Sertifikaat võetakse vastu kliendi veebilehitseja poolt ning edastatakse GLB’le, GLB määrab selle kokkulepitud päisesse sobivuse korral, GLB edastab juba kontrollitud sertifikaadi süsteemi kokkulepitud päises.

Sama asi kehtib mistahes kliendi sertifikaadiga autentimisel ning suvalisest kohast ei tohikski süsteem sertifikaate vastu võtta.

KEHTIV Arhitekt /juhtiv arendaja

NA-78 Infoturv e

Kõik digitembeldamist vajavad rakendused peavad kasutama RIK-i digitembeldamise teenust.

KEHTIV Arhitekt /juhtiv arendaja

NA-79 Infoturv e

Rakenduse turvalisuse tagamiseks tuleb järgida OWASP-i parimaid praktikaid.

Veebirakendus peab probleemideta läbima OWASP ASVS põhineva testi. Esmane väline turvatestimine tellitakse tellija finantseeringul. Kui selle tulemusel leitakse arendaja poolsest tegevusest või tegevusetusest põhjustatud vigu, võib tellija nõuda OWASP järeltestide kompenseerimist arendajalt. Täiendavalt saab uurida https://github. com/OWASP/ASVS

KEHTIV Arhitekt /juhtiv arendaja

NA-80 Arhitekt uur

Rakendus peab olema optimeeritud toodangukeskkonnas toimimiseks.

Toodangukeskkonna rakendus ei tohi sisaldada osiseid, mis on ebavajalikud. NT. Debug logi, testimiseks vajalikud erisused äriloogikast. Rakendust peab olema võimalik uuesti pakendamata tarnida vabalt valitud keskkonda(arendus,test).

KEHTIV Arhitekt /juhtiv arendaja

NA-81 Infoturv e

Ajatemplite kasutamisel eelistatakse RIK-i heaks kiidetud lahendust.

Heaks kiidetud lahenduste kohta info annab OPS-tiim. KEHTIV Arhitekt /juhtiv arendaja

NA-82 Infoturv e

Rakendused peavad toetama SSO kasutamist. Sessioon peab olema stateless KEHTIV Arhitekt /juhtiv arendaja

NA-83 Infoturv e

Süsteemile määratud turvaosaklass peab olema täidetud vastavalt määruse "Võrgu- ja infosüsteemide küberturvalisuse nõuded" paragrahv 10-le.

https://www.riigiteataja.ee/akt/113122022030

Enne arenduste algust tuleb turvaosaklassist tulenevad vajadused kooskõlastada Infoturbe ja IS halduse tiimiga

KEHTIV Arhitekt /juhtiv arendaja

NA-86 Infoturv e

Paks klient peab krüpteerima ajutised failid, mis sisaldavad delikaatseid/konfidentsiaalseid andmeid ja need sulgemisel kustutama.

Kui paks klient kasutab ajutisi faile, tuleb tagada nende perioodiline kustutamine tagamaks, et ei koormata liigselt kasutaja arvutit. Eesmärk on tagada, et rakenduse sulgemisel ei jääks kasutaja arvutisse maha informatsiooni, mida sinna jääda ei tohiks.

KEHTIV Arhitekt /juhtiv arendaja

NA-87 Infoturv e

Rakendus peab serverist kustutama kõik ajutised failid koheselt, kui neid enam ei kasutata.

Ajutiste failide kaust peab olema konfigureeritav. KEHTIV Arhitekt /juhtiv arendaja

NA-88 Infoturv e

Rakendus tohib aksperteerida ainult enda väljastatud sessioonivõtmeid.

KEHTIV Arhitekt /juhtiv arendaja

NA-89 Infoturv e

Rakendusse üleslaetavad failid peab filtreerima, valideerima ja need peavad läbima viirusetõrje.

Tuleb teha tüübi ja faili laiendi vastavause kontroll. Failide üleslaadimise ülempiir peab olema analüüsis kirjeldatud.

Filtreerimine - whitelisting, sh suurus

Valideerimine - äriloogiline vastavus

Viirusetõrje - Rik.Icap.VirusScanner: https://hoidla.rik.ee/#browse/browse:nuget-hosted:Rik.Icap.VirusScanner% 2F1.0.0%2FRik.Icap.VirusScanner-1.0.0.nupkg Kontrollib, kas failis on viirus. Kasutamise näited: KrisDoc2 ( ), KRIS4 ( ), KrAvalik ( ), KAEP ( )KRIS-4642 KRIS-4645 KRIS-4643 KRIS-4644 Alternatiivselt võib dll-i kompileerida lähtekoodist: https://svn.just.ee/!/#riksvn/view/head/VirusScanner/trunk

KEHTIV Arhitekt /juhtiv arendaja

NA-90 Infoturv e

Rakendusse üleslaetava faili peab salvestama unikaalse genereeritud nimega.

Faili originaalnimi tuleb salvestada andmebaasi. KEHTIV Arhitekt /juhtiv arendaja

NA-91 Infoturv e

Rakendus ei tohi lubada ennast kasutada iframe sees.

Kasutada CSP headerit.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-Fetch-Mode

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options

KEHTIV Arhitekt /juhtiv arendaja

NA-92 Infoturv e

Sessiooni küpsisel peavad olema turvalisuse lipud ja prefix __Host.

Sessiooni küpsise korrala tuleb lisada lipud Secure, HttpOnly ja SameSite. Küpsise nime prefiks peab olema "__Host-". Täiendav info: 1)https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie

2) https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/06- Session_Management_Testing/02-Testing_for_Cookies_Attributes

3) https://owasp.org/www-community/HttpOnly

4) https://owasp.org/www-community/controls/SecureCookieAttribute

5) https://owasp.org/www-community/SameSite#:~:text=SameSite%20prevents%20the%20browser%20from, .none%20%2C%20lax%20%2C%20or%20strict%20

KEHTIV Arhitekt /juhtiv arendaja

NA-93 Lähtek ood

Rakenduse kõik üleantavad versioonid peavad enne tellijale üle andmist olema testitud.

Testplaan ja skoop tuleb arenduse käigus tellijaga kokku leppida. KEHTIV Arhitekt /juhtiv arendaja

NA-94 Logimin e ja monito oring

Kriitilised sündmused - sessiooni algamine ja lõppemine ning rolli muutumine tuleb eraldi logida turvalogide tabelis.

Väliste rakenduse puhul tuleb logida kasutaja IP. Sessiooni võtmete väärtused, privaatvõtmed, kasutaja salasõnad ja muu info, mis võimaldab kasutaja isiku kindlakstegemist või on andmekaitset ohustav ei või logisse jääda.

KEHTIV Arhitekt /juhtiv arendaja

NA-95 Logimin e ja monito oring

Rakendus peab logima kõiki väliste süsteemidega vahetatavaid (ka X-tee teenuste kaudu liikuvaid) pöördumisi andmevahetuslogisse.

Parim vahend on Graylog, teine valik baas, kolmas valik on faili logimine. Peab olema võimalus antud logimist välise süsteemi kaupa sisse-välja lülitada. Logi peab olema struktureeritud selliselt, et päring ja vastus on eraldi failides. Logifaili asukoht peab olema administraatori poolt ilma rakendust uuesti kompileerimata seadistatav.

KEHTIV Arhitekt /juhtiv arendaja

NA-98 Logimin e ja monito oring

Rakendus peab logima kõiki rakenduses tekkivaid tehnilisi vigu.

Logi peab sisaldama minimaalselt aega(timestamp), veakoodi, vea sisu (komponent, stack trace, traceback vms), kogu HTTP päringut ja võimalusel kasutaja ID-d. Logimine peab olema konfigureeritav rakenduse taaskäivituseta.

KEHTIV Arhitekt /juhtiv arendaja

NA-99 Logimin e ja monito oring

Failisüsteemi logimise korral peavad logid olema katalogiseeritud, tunnustatud faililaiendiga, roteeruvad.

Peab olema võimalus logimist välise süsteemi kaupa sisse-välja lülitada. Failisüsteemi kausta ei teki rohkem kui 10000 faili. Peab tagama, et iga rakendusserver saaks vajadusel kirjutada logid oma logifaili. Logimine peab olema konfigureeritav rakenduse taaskäivituseta.

KEHTIV Arhitekt /juhtiv arendaja

NA-100 Logimin e ja monito oring

Rakenduse logid peavad olema ühesuguse formaadiga, masinloetavad ja täielikud.

Logiväljad, mida lõppkasutaja saab manipuleerida (IP, useragent, URL) peavad salvestuma logisse kodeeritud ja puhastatud kujul. Igas logikirjes peab olema päringu unikaalne identifikaator. Kui parameetri väärtus on tühi, tuleb see logis märkida asendusväärtusega “-”. Logi kuupäeva ja ajaformaat peab vastama ISO 8601 standardile ja olema Eesti ajavööndis.

KEHTIV Arhitekt /juhtiv arendaja

NA-101 Logimin e ja monito oring

Logi tabelid peavad olema arhiveeritavad operatiivbaasist välja.

Tabeli suurenedes peab olema võimalik hoida vanu kirjeid, näiteks kuude või aastate kaupa, iseseisvates tabelites või teises baasis. Mehhanism peab töötama ka krüptoaheldatud logi korral.

KEHTIV Arhitekt /juhtiv arendaja

NA-102 Logimin e ja monito oring

Kui rakendus kasutab või pakub väliseid teenuseid peab nende kohta arvestust pidama.

Peab kasutama statisikamoodulit või OpenTelemetry-t. KEHTIV Arhitekt /juhtiv arendaja

NA-103 Lähtek ood

Süsteem peab enne toodangusse minemist läbima jõudlustestid.

Täpne kirjeldus tuleb kokku leppida detailanalüüsi käigus. Lähtuda sellest -> https://dok.rik.ee/display/SUS /Koormustestimise+tellimise+eeldused+-+Beeta

KEHTIV Arhitekt /juhtiv arendaja

NA-104 Logimin e ja monito oring

Rakendusel peab olema masinloetav staatusleht. KEHTIV Arhitekt /juhtiv arendaja

NA-106 Lähtek ood

Kõik kommentaarid peavad olema põhjendatud. Lähtekoodi kommentaarid peavad olema: 1. Kood peab olema kirjutatud selliselt, et see on loetav ka ilma kommentaarideta. Kommentaarid on mõeldud keeruliste ja/või kohendamist ja/või edasist tööd (viimaste juurde tuleks märkida TODO) vajavate kohtade jaoks. 2. Aktuaalsed - kommentaar ja kood peavad olema üksteisega vastavuses. 3. Selged ja üheselt mõistetavad. 4. Korrektselt kirjutatud - grammatika ja lauseehitus peavad olema korrektsed. 5. Andmebaasi falid ning muud koodid samadel alustel 6. Peavad olema kirjutatud eesti keeles

KEHTIV Arhitekt /juhtiv arendaja

NA-107 Lähtek ood

Nimetused koodis peavad olema sisulised ja andma selget informatsiooni nende otstarbest.

Projekti skoobis peab olema kokku lepitud nimetamis-reeglistik. KEHTIV Arhitekt /juhtiv arendaja

NA-108 Lähtek ood

Koodis kasutatavad konstandid tuleb defineerida muutujatena.

Siia alla ei kuulu klassifikaatorid. Need peavad olema baasis. KEHTIV Arhitekt /juhtiv arendaja

NA-109 Lähtek ood

Koodis defineeritud andmetüübid peavad olema nimetava käände ainsuses. Kõik andmemassiivid tuleb nimetada nimetava mitmuses.

Näiteks "Isik", "Menetlus" jne. Andmebaasides ei tohi kasutada täpitähti.

Lisainformatsioon:

1) C# - https://learn.microsoft.com/en-us/dotnet/standard/design-guidelines/general-naming-conventions

2) JAVA - https://www.oracle.com/java/technologies/javase/codeconventions-namingconventions.html

3) Python - https://peps.python.org/pep-0008/

KEHTIV Arhitekt /juhtiv arendaja

NA-110 Lähtek ood

Andmetabelites sisalduvad võõrvõtmed peavad nime järgi seostuma tabeli ja väljaga millele need viitavad.

Näiteks kui on tegu tabelitega ’Isik’ ja ’Auto’, siis seos ’isik_auto’ oleks: Isik.ID=Auto.Isik_ID KEHTIV Arhitekt /juhtiv arendaja

NA-111 Lähtek ood

Andmebaasi väljade pikkused peavad lähtuma analüüsis kirjeldatud nõuetest.

Tuleb meeles pidada, et 1 byte ei pruugi võrduda 1 tähemärgiga, näiteks täpitähed. KEHTIV Arhitekt /juhtiv arendaja

NA-115 Lähtek ood

Koodi valideerimiseks kasutame SonarQube reegleid.

Koos SonarQube-ga peab tegema ka Trivy skaneerimise. KEHTIV Arhitekt /juhtiv arendaja

NA-118 Lähtek ood

Lähtekoodis ei tohi olla mitte kasutatavaid osasid. KEHTIV Arhitekt /juhtiv arendaja

NA-120 Lähtek ood

Koodibaasis olevad ärilised terminid peavad olema eesti keeles.

Ärianalüüs ja kood peavad teineteist peegeldama. Ka andmebaasis olevad nimetused peavad olema eesti keeles. KEHTIV Arhitekt /juhtiv arendaja

NA-121 Andme kvalitee t ja standar did

Aadressiandmete käitlemisel lähtuda määrusest "Aadressiandmete süsteem."

Kasutada ADS-i. Link määrusele https://www.riigiteataja.ee/akt/128122024043 KEHTIV Arhitekt /juhtiv arendaja

NA-123 Infoturv e

Iga transaktsiooni juures tuleb kontrollida kasutaja õiguseid ja rollikuuluvust.

OWASP nõuetest -> "Validate the Permissions on Every Request" https://cheatsheetseries.owasp.org /cheatsheets/Authorization_Cheat_Sheet.html#validate-the-permissions-on-every-request

KEHTIV Arhitekt /juhtiv arendaja

NA-124 Andme kvalitee t ja standar did

Tegevusalade käitlemisel lähtuda määrusest "Klassifikaatorite süsteem."

Kasutada RIK EMTAK teenust. https://www.riigiteataja.ee/akt/12910889 KEHTIV Arhitekt /juhtiv arendaja

NA-126 Infoturv e

Süsteemist väljaminevad veateated ei tohi sisaldada süsteemiinfot.

Näiteks: "Tekkis tehniline viga. Päringu ID: XXXXX". Reaalne veateade peab logis säilima! KEHTIV Arhitekt /juhtiv arendaja

NA-127 Dokum entatsio on

Kogu rakenduse dokumentatsioon peab olema kirjutatud eesti keeles.

Erandiks kolmandate osapoolte komponendid. KEHTIV Arhitekt /juhtiv arendaja

NA-128 Dokum entatsio on

Dokumentatsioon peab vastama RIK dokumentatsiooniplaani nõuetele.

https://dok.rik.ee/pages/viewpage.action?pageId=190751639 KEHTIV Arhitekt /juhtiv arendaja

Lisad:  Lisa 1.1.1 – Staatuslehe näidis

NA-129 Dokum entatsio on

Iga uue versiooniga käib kaasas muudatuste kirjeldus.

Changelog või .release notes KEHTIV Arhitekt /juhtiv arendaja

NA-130 Version eerimin e

Kõik rakenduse testimiseks, koolituseks või implementeerimiseks üle antavad tarkvarapaketid peavad asuma RIK koodihoidlas.

Arendajale antakse selleks õigused RIK-i koodihoidlas. KEHTIV Arhitekt /juhtiv arendaja

NA-133 Version eerimin e

Peab kasutama RIK piletihalduskeskkonda. Kasutusel on JIRA. Kaasa arvatud välised osapooled. KEHTIV Arhitekt /juhtiv arendaja

NA-137 Version eerimin e

Kolmanda osapoole teegid peavad asuma RIK-i hoidlas.

hoidla.rik.ee KEHTIV Arhitekt /juhtiv arendaja

NA-138 Version eerimin e

Andmebaasi skriptide sisu peab olema kontrollitav. Administraator peab saama veenduda skriptide sisus. KEHTIV Arhitekt /juhtiv arendaja

118 teemat

Nõuded testimisele v1.2 versioon 1.2

Sisukord

Sissejuhatus 1. Üldine AO-N-TE-Y 2. Dokumentatsioon  AO-N-TE-D 3. Testplaan ja -lood  AO-N-TE-T 4. Logimine, raporteerimine  AO-N-TE-R 5. Nõuded testidele  AO-N-TE-N 6. Lähtekood ja spetsiaalsed tööriistad  AO-N-TE-I 7. Alusandmed  AO-N-TE-A 8. Koormus- ja stressitestid  AO-N-TE-S

Sissejuhatus

Enne projekti tegelikku algust lepitakse kokku kõik erisused - millised punktid vastavas projektis ei rakendu (pole võimalik/vajalik) ja kas rakenduvad mingid täiendavad punktid või all-loetletud punktidele täpsustused.

1. Üldine AO-N-TE-Y

Nõue Sisu

AO-N- TE-Y-1

Kõikide üle antavate tarkvara versioonidega peavad kaasas olema vastavad testid, nendega seotud dokumentatsioon ning kirjelduse või raporti leitud ja parandatud vigadest.

AO-N- TE-Y-2

Tarkvara vastuvõtmiseks vajalikud hankevõitja poolsed testimised ja skoop (osa testplaanist) lepitakse kokku projekti alguses ning seda muudetakse poolte kokkuleppel.

AO-N- TE-Y-3

Vastavalt kokkuleppele tuleb koostada ning üle anda punktis  nimetatud testplaan ja testlood ning eraldi testprojekti ja -programmi puhul ka vajaminev dokumentatsioon ja AO-N-TE-Y-2 kirjeldus.

AO-N- TE-Y-4

Testitava tarkvara lõplik versioon peab läbima vastavad nõuded koormusele/jõudlusele (ISKE,SLA jm.). Selle tõestamiseks tuleb tarnida ka vastavad testid.

AO-N- TE-Y-5

Üle antud testides või vastuvõtutestimisel esinenud probleemid tuleb parandada sarnaselt põhiarendusega.

AO-N- TE-Y-6

Testid peavad olema loogiliselt grupeeritud ning numereeritud, nii et skriptide või tööriistade abil saab kindlat osa käivitada. Näiteks teenuse- või tüübi kaupa (süsteemitestid, koormustestid vm.).

AO-N- TE-Y-7

Üle antud testide käivitamiseks ei pea RIK soetama lisatarkvara. Näiteks automaattestid, koormustestid jm. võiks olla kirjutatud C#+NUnit'is, Selenium'is, JMeter'is, Robot Framework'is või Gattling'us. Kokkuleppel Java+JUnit, Cypress või muu.

2. Dokumentatsioon  AO-N-TE-D

Nõue Sisu

AO-N-TE-D- 1

Dokumentatsiooni eesmärgiks on edasi anda kogu vajalik informatsioon testide kohta (testplaanid, testlood, testide käivitamiseks, jooksutamiseks ja valideerimiseks vajalik informatsioon jne).

AO-N-TE-D- 2

Dokumentatsioon peab olema versioneeritud ning iga punkti (Näiteks Testlugu) juures peab olema tekkimise aeg, viimase muudatuse aeg, autor, muutja.

3. Testplaan ja -lood  AO-N-TE-T

Nõue Sisu

AO-N- TE-T-1

Testplaanile ja –lugudele rakendub peatükk .AO-N-TE-D-2

AO-N- TE-T-2

Testplaan kirjeldab ning selgitab kogu tarkvaraga seotud testimist, kui ei ole kokku lepitud teisiti.

AO-N- TE-T-3

Testlood tulenevad kasutuslugudest ja/või süsteemianalüüsi nõuetest, nende kattumisel piisab testimise kirjeldusest, et vältida dokumentatsiooni dubleerimist.

AO-N- TE-T-4

Testloos peab minimaalselt olema: testi kirjeldus, viide nõudele või kasutusloole, etapid, oodatud tulemus, tegelik tulemus.

AO-N- TE-T-5

Testprojekti ja –programmi puhul võib kood koos kommentaaridega täita testloo rolli (Näiteks Testi nimetus viitab kindlale testloole või süsteeminõudele, C# kirjutatud süsteemitesti nimetamisloogika ja kommentaarid teevad kergelt selgeks tegevuste ahela).

4. Logimine, raporteerimine  AO-N-TE-R

Nõue Sisu

AO-N- TE-R-1

Raportitele rakendub peatükk  AO-N-TE-D-2 . Eraldi raporteid pole tingimata vaja kui kasutatakse ühist JIRA + Confluence keskkonda.

AO-N- TE-R-2

Testraportis kajastatud vigade juures peab olema märgitud tarne versioon, milles viga leiti ning milles see on kõrvaldatud.

AO-N- TE-R-3

Automaatsete testide puhul peab automaatselt genereeruma testraport või statistika tegemiseks vajalik logi (Näiteks NUnit genereerib ise raporti, JMeteris Summary Report+ Aggregate Report või eraldi .csv fail jne.).

AO-N- TE-R-4

Koormus- ja stressitestide puhul peab raport kajastama, millise koormuse juures hakkasid testid negatiivseid tulemusi saama ning millised vead esinesid.

AO-N- TE-R-5

Koormus- ja stressitestide juures on vaja minimaalselt välja tuua: saadetud päringute arv, min. päringu käitlemise aeg(ms), max. päringu käitlemise aeg(ms), päringute käitlemise standardhälve (ms), keskmine päringu käitlemise aeg(ms), vigade %, läbilaskevõime(tegevust/sek.), 90/95/99 protsentiilid.

5. Nõuded testidele  AO-N-TE-N

Nõue Sisu

AO-N-TE- N-1

Testprojekti ja –programmi testide juures rakendub peatükk  AO-N-TE-D-2 , lisaks peab testi juurde märkima testi tegija ning tarkvara versiooni, millele test koostati. 

AO-N-TE- N-2

Süsteemitestidega peavad olema kaetud kõik süsteemi osad, kui ei ole kokku lepitud teisiti (Näiteks kõik arendatud teenused, kasutajaliidesega rakenduse testlood jne.).

AO-N-TE- N-3

Iga test peab olema süsteemi- või ärianalüütiliselt terviklik põhjendatav kooslus (Näiteks ühes testis ei testita kahte erinevat teenust või süsteemi viga).

AO-N-TE- N-4

Iga teenuse kohta peab olema Smoke test, mis kontrollib lihtsaima sisendiga teenuse töökorda.

AO-N-TE- N-5

Kuna RIKis arendatakse pideva integratsiooni mudelit järgides, siis peab olema võimalik teste valikuliselt grupeerida ning neid automaatselt käivitada (Näiteks Grupp „Nightly" öiste integratsioonitestide jaoks).

AO-N-TE- N-6

Testsessioonid ning omavahel mitte seotud testid ei tohi üksteist mõjutada.

6. Lähtekood ja spetsiaalsed tööriistad  AO-N-TE-I

Nõue Sisu

AO-N-TE-I- 1

Spetsiaalselt arendatud testprojektile ja -programmile rakenduvad „Nõuded arendustele –Nõuded rakenduse koodile" .

AO-N-TE-I- 2

Spetsiaalselt arendatud testprojektid peavad kasutama üldtuntud raamistikke Näiteks NUnit, JUnit.

AO-N-TE-I- 3

Kui testprojekt kasutab Objektide kihte, omab teenuste kihti või koodi osa, mida saab WSDL, andmebaasi või muu pealt genereerida, siis selleks peab kasutama tööriistu (Näiteks DTOd ei kirjutata käsitsi).

AO-N-TE-I- 4

Punktis mainitud tööriistad ja nende parandused tuleb tarnida koos testidega.AO-N-TE-I-3

7. Alusandmed  AO-N-TE-A

Nõue Sisu

AO-N-TE- A-1

Alusandmete genereerimiseks vajalik peab olema vastavate testidega kaasas.

AO-N-TE- A-2

Kui testimiseks on vajalikud andmed teistest süsteemidest, siis nende saamine lepitakse eelnevalt kokku.

AO-N-TE- A-3

Alusandmed peavad töötama erinevates keskkondades, kaasa arvatud andmed, mida päritakse teistest süsteemidest.

AO-N-TE- A-4

Peab vältima teiste süsteemide andmete rikkumist, selle vältimiseks vt. punkt .AO-N-TE-A-2

AO-N-TE- A-5

Eelistama peaks alusandmete genereerimist või eraldi üldkasutatavat kihti, millest andmed võetakse, mitte koodi sisse kirjutatud andmeid (Näiteks Isikukoodid võetakse üldisest jadast või eraldi testandmete alamprojektist).

AO-N-TE- A-6

Võimalusel kasutada sünteetilisi, mitte reaalseid andmeid (Näiteks reaalsuses mitte eksisteerivad Isikud), eriti kui arendatavas tarkvaras on automaatseid teavitusi või muud samalaadset (Näiteks automaatne e-mailide saatmine).

8. Koormus- ja stressitestid  AO-N-TE-S

Nõue Sisu

AO-N-TE-S-1 Testide üleandmisel peab kaasa andma nendega kaasneva dokumentatsiooni, kasutatud konfiguratsiooni ning vajadusel riistvara ja arhitektuuri kirjelduse.

AO-N-TE-S-2 Kasutatud konfiguratsioon ning riistvara ja arhitektuur võiks tugevalt sarnaneda vastuvõtja test- või toodangukeskkonna riistvaraga.

AO-N-TE-S-3 Testid peavad olema üldisest konfiguratsioonist skaleeritavad: kasutajate arv, kasutajate etapilisus (ramp-up), testide ajastamine jm. on üldised muutujad või üldises konfiguratsioonis.

AO-N-TE-S-4 Igal testil peab olema konkreetne kontekst (Näiteks SLA nõue, teenuse või baasiprotseduuri jõudluse hindamine vm.).

Dokumentatsiooniplaan v2 versioon 2.0

Täitja poolt Tellijale üle antavad dokumendid

Arenduste kirjeldus Arhitektuuri kirjeldus Seadmete ja tarkvara kasutusjuhendid Testplaan ja testimise tulemusena valminud dokumendid Varundus/taasteplaan Versiooni kirjeldus Nõuded arendustele vastavustabel Front-end nõuete vastavustabel Kasutajaliideste ja WCAG nõuete vastavustabel Andmekogude semantiline kirjeldus ja koosseis

Dokumendid peavad vastama vähemalt alljärgnevatele tingimustele

Tehnilise dokumentatsiooni võiks võimaluse korral hoida git’is koodi juures .md failides.  Ärilised dokumendid peavad olema RIK Confluence keskkonnas

  Dokumendi nimi hankelepingus Dokumendi sisu vastavalt arenduslepingule Sihtgrupp

1 Arenduste kirjeldus Dokumendi/dokumentide eesmärgiks on anda selge ja konkreetne ülevaade süsteemi sisust ja realiseeritud arendustest.

Eraldiseisvaid dokumente üle ei anta vaid RIK Confluence keskkonda kirjutatakse analüüsi jooksvalt projekti käigus. 

Kirjeldused peavad olema kinnitatud Tellija poolt enne arendustöö algust.

Üle antavad dokumendid peavad sisaldama:

Infosüsteemi terviku kirjeldus – olemasoleva süsteemi täiendamisel lisatud/muudetud osade kirjeldus. Tegemist on süsteemi ärisisul põhinevate baaskomponentidega, millele toetuvad kasutaja tegevused, ekraanivormid, kasutuslood/protsessid, teenused, jms; Vormide (ekraanivormide) kirjeldused; Kasutuslugude / vormide kasutamise protsesside / tegevuste kirjeldused; Infosüsteemi teenuste kirjeldused.

Tellija äriprotsesse valdavad kontaktisikud:

ärianalüü tikud süsteemi analüütik ud

Täitjast sõltumatud

tarkvara hooldajad arendaja d ja edasiare ndajad testijad arhitektid projektiju hid

2 Arhitektuuri kirjeldus Dokumendi eesmärgiks on kirjeldada loodava süsteemi tehnilist ülesehitust. Kirjeldatakse rakenduse loogilist struktuuri, näidates ära selle kihtideks jagunemise. Kirjeldatakse ka füüsilist arhitektuuri, antakse ülevaade kasutatavatest tehnoloogiatest ning vahenditest.

Dokument peab rahuldama vähemalt alljärgnevaid sisunõudeid:

topoloogia, süsteemi füüsiline arhitektuur (süsteemi komponendid andmebaasiserver, rakendusserver, meiliserver jms): süsteemi soovituslikud näitajad komponentide kaupa, näiteks andmesidekiirused, andmemahud, protsessori kiirus, mälumaht, komponentide arv süsteemi osade kaupa, kettasüsteemi jõudlus jms; liidesed teiste süsteemidega (x-tee, meilisüsteemid) ja sõltuvused teistest süsteemidest; süsteemi tehnilised (sh automaatsed) protsessid ehk töövoog – komponentide omavahelised suhtlusstsenaariumid ja koostoimimine (näiteks, mis komponent ja millal pöördub RR teenuse poole); kolmandate osapoolte poolt toodetud kasutatavad tarkvarad/riistvarad, mis on vajalikud süsteemi toimimiseks; süsteemi krüpto-, allkirjastamise, digitemebeldamise lahendused ja algoritmid.

Esmane kirjeldus esitatakse enne arendustööde algust.

Täiendatud kirjeldus antakse üle koos vaheetapi üleandmise aktiga.

Lõplik (täielik) kirjeldus esitatakse lõppaktiga

arhitekt administraator turvaspetsialist

3 Seadmete ja tarkvara kasutusjuhendid

Süsteem tuleb ehitada selliselt, et see ei vajaks täiendavaid selgitusi (oleks intuitiivne).

Siiski võib teatud hetkedel kasutaja vajada täiendavat infot, mis aitaks kasutajatel mõista, kuidas oma ülesandeid täita, sellisel juhul peab info sisu olema hõlpsasti leitav ja keskenduma kasutaja ülesandele. Seega tuleks alati eelistada kasutajale kontekstipõhist abiinfo andmist, mis on realiseeritud UI vaates, milles kasutaja parasjagu oma ülesandeid täidab.

Abiinfo peab olema lühike ja sisaldama konkreetsete sammude kirjeldusi, mis tuleb läbi viia.

Kasutusjuhendi materjali eraldiseisvalt üle ei anta, vaid need kuuluvad üle antava rakenduse juurde.

tarkvara kasutajad haldurid

4 Administreerimisjuhend,  paigal dusjuhend

Juhend on aluseks süsteemi administreerimisele, paigaldamisele ja seadistamisele.

Juhend peab rahuldama vähemalt alljärgnevaid sisunõudeid:

süsteemi parameetrite (seadistuste) kirjeldus ning nende muutmiste mõjud ja protseduurid (näiteks .net rakenduste puhul konfiguratsiooniparameetrite kirjeldused/selgitused ja näidisväärtused); logimise realisatsiooni kirjeldused (kuhu ja mida, kas kasutatakse roteerimist või katalogiseerimist jms); rutiinsete hooldusprotseduuride kirjeldus; paigalduspaketi koostamise protseduurid; paigaldusprotseduurid; süsteemi halvamist võimaldavad riskid ja nende esinemise võimalikkus.

Paigaldusjuhendis kirjeldatakse iga realiseeritud osa rakendamine (deployment) koos spetsiifiliste seadistustega. Paigaldusprotseduurid peavad olema kirjutatud selliselt, et RIK-i administraator suudab rakenduse paigaldada ja seadistada ilma kõrvalise abita. 

Etapi juhendid antakse üle koos vaheetapi üleandmise aktiga.

Lõplikud (täielikud) juhendid esitatakse lõppaktiga. 

haldurid projektijuht adminitraator arhitekt

1.

2. 3.

5 Testplaan ja testimise tulemusena valminud dokumendid

Annab detailse ülevaate teostatud arenduste testimisest ning testimise tulemustest.

Kesksel kohal on testplaan, mis kirjeldab testimise strateegia, skoobi, vahendid, tegevused, tulemid jne. Vastavalt kokkuleppele koostatakse testlood, mis võivad olla laiendatud kasutuslood. Vastavalt kokkuleppele teostatud funktsionaalsuse-, jõudluse-, koormuse-, integratsiooni-, kasutatavuse-, turvalisuse- jm. testimise dokumendid (plaan, lood, juhendid, puudused, puuduste kõrvaldamise info, tulemid). Testimisel ilmnenud vead ning paranduste info (versiooniinfo, vajadusel sisu). Testimise otstarbel loodud kood, skriptid, kasutusjuhendid.

Testimise dokumentatsioon ei pea olema üks dokument, dokumendid võib grupeerida loogilisteks osadeks:

Testplaan Nõuetele vastavus Testlood

Etapi juhendid antakse üle koos vaheetapi üleandmise aktiga.

Lõplikud (täielikud) juhendid esitatakse lõppaktiga. 

projektijuht vastuvõtu testijad

6 Varundus/taasteplaan Tagada süsteemi hävingujärgne kiire ja tõrgeteta taastamine.

Taasteplaan on aluseks süsteemi taastamisele peale suuremat hävingut.

Taasteplaan peab rahuldama vähemalt alljärgnevaid sisulisi nõudeid:

Süsteemi backup’id, varundamisele kuuluvate komponentide ja asukohtade loetelu (nt rakenduse konfiguratsioonifailid, rakenduse failid failiserveril paiknevad failid ja andmebaas jne), nende kirjeldused ja kasutuselevõtu protseduurid (Näiteks: tuua kataloogi (vajadusel faili) tasemel välja list failidest, mida peab varundama; varunduse järjekord (kui see on oluline); Taastamise sammud kasutades installatsiooni juhendit ja varundatud andmeid; Süsteemi komponentide asendusvõimalused, nende alternatiivkomponentide spetsifikatsioonid. Miinimumis peab vastama küsimusele: milline riistvara/tarkvara on sobiv arendaja arvates (tehtud nt jõudlustestid) seda süsteemi käitama.

Esmane dokument esitatakse enne arendustööde algust.

Täiendatud dokument antakse üle koos vaheetapi üleandmise aktiga.

Lõplik (täielik) dokument esitatakse lõppaktiga.

administraator

7  Versiooni kirjeldus  Vajalik ülevaate saamiseks infosüsteemi versioonide sisust.

Detailne info iga versiooniuuenduse kohta: 

avaldamise kuupäev versiooni number versiooni tüüp (peamine, vaheversioon, parandus, erakorraline) versiooni sisu - milliseid teostatud arendusi sisaldab (töökasu numbrid, näiteks Jira taskide numbrid ja/või lingid taskile) leitud, kuid parandamata vead

Versioni kirjeldus võib põhineda tarnitud Jira piletitel.

Esitatakse koos iga üleantava versiooniga ja iga versiooni kohta.

projektijuht

8 Nõuded arendustele vastavustabel

Kontrolltabel nii Täitjale kui ka Tellijale veendumaks, et arvestatud on hankes nõutud arenduse nõuetega.

Kõik raamlepingus, lähteülesandes või tehnilises kirjelduses kirjeldatud mittefunktsionaalsed nõuded ning täitmismärge. 

Täitmismärke tegemise aluseks peab olema testimine. Vajadusel lisatakse selgitused.

Esmane dokument esitatakse enne arendustööde algust.

Täiendatud dokument antakse üle koos vaheetapi üleandmise aktiga.

Lõplik (täielik) dokument esitatakse lõppaktiga.

arhitekt administraator turvajuht

9 Front-end nõuete vastavustabel

Kontrolltabel nii Täitjale kui ka Tellijale veendumaks, et arvestatud on hankes nõutud front-end nõuetega.

Kõik raamlepingus, lähteülesandes või tehnilises kirjelduses kirjeldatud front-end nõuded ning täitmismärge. 

Täitmismärke tegemise aluseks peab olema testimine. Vajadusel lisatakse selgitused.

Esmane dokument esitatakse enne arendustööde algust.

Täiendatud dokument antakse üle koos vaheetapi üleandmise aktiga.

Lõplik (täielik) dokument esitatakse lõppaktiga.

arhitekt

10 Kasutajaliideste ja WCAG nõuete vastavustabel

Kontrolltabel nii Täitjale kui ka Tellijale veendumaks, et arvestatud on hankes nõutud kasutajaliideste ja WCAG nõuetega.

Kõik raamlepingus, lähteülesandes või tehnilises kirjelduses kirjeldatud kasutajaliideste ja WCAG nõuded ning täitmismärge. 

Täitmismärke tegemise aluseks peab olema testimine. Vajadusel lisatakse selgitused.

Esmane dokument esitatakse enne arendustööde algust.

Täiendatud dokument antakse üle koos vaheetapi üleandmise aktiga.

Lõplik (täielik) dokument esitatakse lõppaktiga.

haldurid

11 Andmekogude semantiline kirjeldus ja koosseis

Vajalik ülevaate saamiseks, mis andmed andmekogus on ja mida need tähendavad.

Andmekogus töödeldavate andmete koosseisu kirjeldus sisaldab:

vanemandmeobjekti nimetus (tabeli nimetus); andmeobjekti nimetus (veeru nimetus); märge, kas tegemist on isikuandmetega; märge, kas tegemist on eriliigiliste isikuandmetega; märge, kas tegemist on andmekogu põhiandmetega; märge, kas tegemist on arhiiviväärtuslike andmetega; viide andmekogule, kust mittepõhiandmed pärinevad; andmeobjekti semantiline kirjeldus (selgitus, mis andmeobjektiga on tegemist).

(Kõik märked formaadis jah/ei.)

Dokument (fail) esitatakse lõppaktiga.

tellija tellija poolne projektijuht

Nõuded süsteemianalüüsile versioon 1.0

Sisukord:

Sissejuhatus I. Vormistus

SA-v 1. Loomise ja muutmise info: SA-v 2. Oleku info: SA-v 3. Identifitseerimise info:

II. Sisu SA-s 1. Loetavus ja mõistetavus. SA-s 2. Infosüsteemi terviku kirjeldus SA-s 3. Vormide kirjeldused SA-s 4. Kasutuslugude/vormide kasutamise protsesside/tegevuste kirjeldused SA-s 5. Infosüsteemi teenuste kirjeldused SA-s 6. Pildid, skeemid, diagrammid:

III. Töövahendid

Sissejuhatus

Enne projekti tegelikku algust lepitakse kokku kõik erisused - millised punktid vastavas projektis ei rakendu (pole võimalik/vajalik) ja kas rakenduvad mingid täiendavad punktid või all-loetletud punktidele täpsustused.

Antud nõueteloetelu kehtib nii RIKi majasisestele projektidele kui välistele projektidele (majavälised arendajad).

I. Vormistus

Alljärgnevalt on kirjeldatud vormistuse nõuded kõiksugustele nõuetele, nõuete komplektidele, reeglitele, vormidele. Muudatuste haldamine ja seotud viitamine peavad olema kooskõlastatud ja kokkulepitud enne süsteemianalüüsi algust.

SA-v 1. Loomise ja muutmise info:

Loomise eesmärk/taustSA-v 1.1

Tekkimise aegSA-v 1.2

AutorSA-v 1.3

Viimase muutmise põhjusSA-v 1.4

Viimase muutmise aegSA-v 1.5

MuutjaSA-v 1.6

Kui on tegemist nõuete komplektiga (või plokiga), siis peavad olema selgelt eristatavad pealkiri ja sisuSA-v 1.7

SA-v 2. Oleku info:

Kinnitaja ja kooskõlastajadSA-v 2.1

Nõude/nõuete komplekti seis - kasutusel olevad olekunäitajad peavad olema kokkulepitud vastavalt antud projekti vajadustele. SA-v 2.2 Näiteks võivad nõude/nõuete komplekti olekud olla:

tegemisel kooskõlastamisel kinnitatud implementeeritud kehtetu

SA-v 3. Identifitseerimise info:

Igal nõudel/reeglil ja nõete komplektil peab olema unikaalne identifikaatorSA-v 3.1

II. Sisu

Alljärgnevalt on kirjeldatud nõuded süsteemianalüüsi sisule.

SA-s 1. Loetavus ja mõistetavus.

Süsteemianalüüs peab olema:

Loetav ja selgeSA-s 1.1

Kindlas kõneviisisSA-s 1.2

Sisaldama üheselt defineeritud äri- ja süsteemi mõisteidSA-s 1.3

Sisaldama ainult täpseid andmeolemite/andmeväljade nimetusiSA-s 1.4

SA-s 2. Infosüsteemi terviku kirjeldus

Infosüsteemi terviku kirjelduses peavad olema:

Kõikide kasutatavate mõistete definitsioonidSA-s 2.1

Kõikide äriobjektide ja neile vastavate andmeolemite ning seoste kirjeldused ning üldised tööpõhimõttedSA-s 2.2

Andmeolemite kõik andmeväljad ja nende sisu vastastikune mõju üksteiseleSA-s 2.3

Infosüsteemi erinevate kihtide kirjeldused: andmevahetus/kasutajaliides, domeen ja andmebaas.SA-s 2.4

Andmete käitlemine antud süsteemis:SA-s 2.5

versioneerimineSA-s 2.5.1

sünkroniseerimineSA-s 2.5.2

arhiveerimineSA-s 2.5.3

kustutamineSA-s 2.5.4

Kasutusel väljade ja kasutatavate andmeolemite täpsed nimetusedSA-s 2.6

Õiguste kirjeldused: kasutajad, rollid, grupidSA-s 2.7

Süsteemi üldised valideerimisedSA-s 2.8

SA-s 3. Vormide kirjeldused

Kõik kasutajaliidesevormid ja vormide elemendid peavad olema nõuetega/reeglitega kaetudSA-s 3.1

Peab olema loodud prototüüp, mis kajastab kõike realiseeritavat.SA-s 3.2

Märkus: Sõltuvalt projekti kokkulepetest võib seda osa teha ka UX inimene UX ja ärianalüüsi tööde raames.

Iga vormi/vormi osa eesmärk peab olema selge - lühike ja täpne kirjeldus, milleks seda vormi on vaja.SA-s 3.3

Iga vormi jaoks peavad olema välja toodud kõik vormiga seotud sisulised veateated.SA-s 3.4

Märkus: Sõltuvalt projekti kokkulepetest võib seda osa teha ka UX inimene UX ja ärianalüüsi tööde raames.

Iga vormi toimimise juures peavad olema välja toodud erandid, kui need on olemas, võrreldes selle konkreetse süsteemi üldiselt SA-s 3.5 kehtivate reeglitega

Igal vormil peavad olema välja toodud kõik sellega seotud valideerimised ning nendega seotud süsteemi poolt tagastatavad SA-s 3.6 veateated ja hoiatused

Vormi andmeväljade sisestamise ja muutmise kirjeldused; kes (süsteem, kasutaja, sidussüsteem, genereeritakse jooksvalt, ...), SA-s 3.7 mis tingimustel, kuidas?

Millised andmeväljad onSA-s 3.8

kohustuslikudSA-s 3.8.1

valikulisedSA-s 3.8.2

ainult kuvatavadSA-s 3.8.3

tingimuslikult kuvatavad vs alati kuvatavadSA-s 3.8.4

vaikeväärtustega täidetavad + millised need vaikeväärtused onSA-s 3.8.5

Lubatud väärtused väljadele (tekst, numbrid, e-mail, komakohad, jne)SA-s 3.9

Kuidas antud vormile saab - kui see ei tule välja punktis SA-s 4 nõutud kirjeldustestSA-s 3.10

SA-s 4. Kasutuslugude/vormide kasutamise protsesside/tegevuste kirjeldused

Kuidas on erinevad vormid omavahel seotudSA-s 4.1

Kasutajate tegevuste ja tegevuste kogumite kirjeldusedSA-s 4.2

Süsteemi terviklikud kasutamise protsessid/kasutusloodSA-s 4.3

Kriitiliste funktsionaalsuste jaoks testimise stsenaariumidSA-s 4.4

SA-s 5. Infosüsteemi teenuste kirjeldused

Kui tegemist on teenusepõhise (XML-teenuseid pakkuva) infosüsteemiga või liidetustumisega mingi teise infosüsteemiga (teenuste tarbimisega), siis peavad olema kirjeldatud:

Tarbitavad teiste süsteemide teenused (kui on)SA-s 5.1

Kõik edastatavad sisendidSA-s 5.1.1

Kõik tarbitavad väljundid - millised ja kus, kuhu edasi saadetakse/märgitakse/salvestatakseSA-s 5.1.2

Kõik infosüsteemi enda poolt pakutavad teenused (kui on)SA-s 5.2

Iga teenuse kohta detailne sisendite kirjeldusSA-s 5.2.1

Iga teenuse kohta detailne väljundite kirjeldusSA-s 5.2.2

Iga teenusega kaasnevad valideerimised ja sisulised veateatedSA-s 5.2.3

Iga teenuse enda loogika ja funktisonaalsuse kirjeldusSA-s 5.2.4

SA-s 6. Pildid, skeemid, diagrammid:

Peavad:

toetama kirjeldatavat - olema tervikliku kirjelduse osa, mitte tühjalt genereeritud pildialbumSA-s 6.1

omama selget eesmärki - milleks see pilt/skeem/diagramm on, mida ta annab?SA-s 6.2

olema intuitiivselt loetavadSA-s 6.3

Lisaks:

Teenuste puhul on hea lisada ka XML .SA-s 6.4 schema

III. Töövahendid

SA-t 1. Süsteemianalüüsi kajastavad töövahendid peavad olema eelnevalt kokkulepitud

SA-t 2. Spetsifikatsioon peab olema üle antud taaskasutataval kujul.

Näiteks:

skeemi/diagrammi/pildi algfail (mitte suvaline link sellele) *.eap fail Confluence eksportfail ...

Arenduse tavad ja töökorraldus

Tellija jätab endale õiguse muuta raamlepingu alusel sõlmitavate hankelepingute tehnilises kirjelduses

kirjeldatud nõudeid. Pakkuja peab lähtuma hankelepingute täitmisel järgnevatest nõuetest, v.a juhul kui tellija on

hankelepingu tehnilises kirjelduses märkinud teisti.

Arendustööde teostamisel kohustub pakkuja lähtuma mittefunktsionaalsetest nõuetest.

1. Nõuded arenduste üleandmisele

Loodavad hanke tulemid antakse üle RIK-i koodirepositooriumi kaudu. Partneri meeskonnaliikmetele luuakse

RIK-i poolt ligipääs koodirepositooriumile lähtekoodide, andmebaasimuudatuste ning muude tulemite või nende

muudatuste üleandmiseks.

2. Commit

Arendamisel lisada commitide (lähtekoodi repositooriumisse lisamine) juurde kindlasti töökäsu 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 ning kindlasti lisada info selle kohta, et kes antud commiti

teeb (isiku nimi).

Vigade parandamisel tuleb alati committimisel lisada ticketi number märkusena.

Muudatusi tuleb commitida vähemalt kord päevas.

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

1) Iseendaga kooskõlas (pole vastuolusid, katkiseid mooduleid, iseendaga vastuolus funktsionaalsust);

2) Üldharu/muu haru tulemiga kooskõlas (üldharus olemasolev pole peale commiti katki);

3) Edaspidi mugavalt kasutatav ja mõistetav, ehk sellel on olemas oma enda sisseehitatud testid, mis peale

järgnevaid võimalikke arendusi/commite/tegevusi näitaks, kas see konkreetne funktsionaalsuse osa on

endiselt korras, või läks katki ja tuleb korrastada.

Commititav kood/teostatud töö/tulem peab olema piisavalt testitud ja pakkuja poolt testidega kaetud, kasutades

selleks:

a) Unittest’e,

b) Systemtest’e

c) Manuaalseid teste

3. Tagimine

Versiooni üleandmiseks tuleb sellest koostada tag. Tagi number peab ühtima versiooni numbriga, mida üle

antakse, kuid tagi nimi peab alati algama projekti lühendiga. Tagi alla tuleb siduda kõikide arhitektuuriliste

komponentide (rakendus, andmebaasiscriptid, x-tee adapter jne) ning muudetud või loodud dokumentatsiooni

commitid.

Versiooni numbrid peavad olema vähemalt kolmekohalised (X.Y.Z, milles X- põhiversioon, Y - üleantav versioon,

Z paranduse number). Vajadusel võib kokku leppida teistsuguses numeratsioonis.

http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-branchtag.html#tsvn-dug-branch-1

Iga tagiga (uue versiooniga) peab kaasnema versiooni kirjeldus (mis taskid, mis ticketid, mis baasiscriptid, mis

juhendeid täiendati jne), mis tuleb paigutada dokumentatsiooni alla.

4. Dokumentatsioon

Dokumentatsiooni tuleb hoida trunk/doc/ kaustas. Alampuud lepitakse eraldi kokku.

5. Baasiscriptid

Andmebaas ning selle muudatused tuleb alati üle anda loovate, muutvate, täiendavate jne skriptidena ning neid

tuleb alati hoida trunk/baas/ kaustas.

Andmebaasiscriptide failinimed peavad olema kujul:

YYYYMMDDHHMM_prefiks+Järjekorranr.sql ehk 201105131430_KR0003.sql kus prefiks on süsteemi

lühend.

6. Pakkuja poolne testimine

Partner peab lisaks kasutuslugude funktsionaalsele testimisele teostatava arenduse/töö/tulemi commitimisel ja

üleandmisel ise tõestatavalt veendunud olema, et nende arendus/töö/tulem teeb seda, mis on nõutud ning

samaaegselt ei riku/lõhu juba olemasolevat muud arendust/tööd/tulemit.

Iga kirjutatud koodiüksuse kohta peaks olemas olema ka vastav test, mis kindlustab, et loodu toimib ja seda ka

eriolukordades. Samuti on testid abiks juba olemasolevate komponentide muutmisel, indikeerides koheselt

võimaliku probleemolukorra.

Arendatav funktsionaalsus peab olema kaetud:

1. Unittestidega

2. Süsteemitestidega

3. Manuaalsete testidega

Igal commitimisel ning üleandmisega peab edukalt:

1. käivitama kõik Unittestid ning selle dokumenteerima.

2. käivitama kõik süsteemitestid ning selle dokumenteerima

3. käivitama kõik manuaalsed testid ning selle dokumenteerima

4. dokumenteerima, mis test data't kasutati, mis keskkondi kasutati, jne.

6.1 Unit-testid e. Moodultestid

Moodultestid testivad ÜHTE klassi isoleeritult teistest klassidest ja ressurssidest (andmebaas).

Ideaalis peaks igal iseseival klassil olema oma moodultest, mis kataks selle funktsionaalust täielikult.

Kuna klassid kasutavad teineteist, moodustuvad niiöelda kobarad, siis moodultesti ideoloogiaga see hästi kokku

ei sobi. Selleks, et saaks testida tõesti vaid konkreetse ühe klassi funktsionaalsust, on kasutusel mock-

objektid(väline komponent Rhino Mocks).

6.2 Süsteemitestid

Süsteemitestid testivad süsteemi kasutaja vaatenurgast, eesmärgiks on kontrollida süsteemi vastavust kasutaja

nõudmistele.

Süsteemitestid jagunevad omakorda kaheks:

1. Funktsionaalsuse testid - üldjuhul koostatakse konkreetse teenuse klassi süsteemitestid sellises mahus, et

kaetud oleksid selle kõik erinevad meetodid ning lisaks äriloogiliselt olulisemad stsenaariumid.

2. Mittefunktsionaalsete aspektide testid - näiteks jõudluse testimiseks.

6.3 Üldised nõuded testide kirjutamisel

Nagu eelnevalt sai kirjeldatud, on testid liigendatud oma olemuse järgi. Testi sisu ja iseloom varieerub olenevalt

selle kategooriale (nt. [Test, Category("Bug")] – testis kirjeldatakse kindel veaolukord ning kontrollitakse selle

põhjal vea olemasolu. testi andmed on antud veaolukorra järgi koostatud ja spetsiifilised). Küll aga on kujunenud

kindlad head tavad, mida tuleb kõigi testide kirjutamisel järgida – koodieetikat, testide liigendamist, testide

automatiseeritust (st. teste peab saama käivitada skriptidega projektiväliselt nt. kategooria alusel iga-öiselt) ning

testide autonoomsust (testid peavad võimalikult hästi taluma ET muudatusi).

6.4 Koodieetika ja struktuur testide kirjutamisel

Testkood peaks olema liigendatud ja selgelt loetav:

1. Defineerida testis projekti erinevate osade kasutus (nt. using System;);

2. Iga testklass tuleb deklareerida [TestFixture]-raamistikus ning olenevalt testi iseloomust nimetada kujul

Bug1234Test (kindlat viga #1234 kirjeldav Bug-test), Ticket1234Test (uuendust #1234 kontrolliv test)

või TestiKirjutajaEesnimi_TeenuseNimiTest (teenuse spetsiifiline süvatest);

3. Testis olevad privaatsed klassimuutujad on tava kohaselt kujul _muutujaNimi, näiteks

private Menetlus _menetlus;

4. Kaitstud ja avalikud muutujad on kujul muutujaNimi või MuutujaNimi;

5. Vajalik uute klassiobjektide initsialiseerimine (nt. liidesed) toimub meetodis SetUp(). Näiteks:

[SetUp]

public void SetUp()

{

_liides = new Liides();

}

6. Iga uus testcase tuleb kirjutada raamistiku sisse kujul

[Test, Category("Kategooria")]

ning testi enda nimetus tuleneb testi tüübist:

a) Bug-testide ja uuendusi kontrollivate testide korral nimetus, mis kirjeldab võimalikult hästi ja

konkreetselt kontrollitavat objekti/olukorda .

b) Teenusepõhiste süvatestide puhul esiteks test, mis kontrollib, et teenust saaks nii minimaalsete

kui ka maksimaalsete andmetega kinnitada, nimetusega A_SetUp()

7. Testandmed võiksid olla võimalikult reaalse elu lähedased ja loogilised, st. ei tohiks tekitada uut objekti

klassist Helikopter kujul _a, vaid kujul _helikopter.

8. Iga äridokumendis olev nõue või tingimus tuleb testida eraldi testcase’i all, olenemata sellest kas

kontrolliks on üks või rohkem ridu koodi. Kui teha äriloogiline kontroll vaid ühe testi all, siis ei kajasta

see teenuse tervist – st. kui esimene kontroll annab veateate, siis ülejäänuteni test ei jõua. Selle

vältimiseks on testid ärinõuete kaupa eraldi kirjutatud.

6.5 Autonoomsus

Testid peavad taluma pisemaid koodi muudatusi (neid, millega ei kaasne DTO või andmemudeli muutused).

6.6 Automatiseeritus

Kõiki teste peab saama käivitada näiteks projektiväliselt skripti abil. Selleks peavad testid olema õigesti

kategoriseeritud.

Nõuded projektiplaanile

Pakkumuse osana esitatakse projektiplaan, mis sisaldab ajakava kõikide funktsionaalsuste loomise ja selle pakkumuse alustamiseks vajalike tööde läbiviimiseks. Pakkumuses esitatavalt projektiplaanilt eeldatakse vastavust järgmistele tingimustele:

PP 1.1 Projektiplaanis kirjeldatud tööde läbiviimise tulemusena peab olema saavutatud projekti eesmärk ja soovitud funktsionaalsus.

PP 1.2 Iga projektiplaani töö kohta peab olema kirjeldatud töö nimetus, töö tegija(te) sh vastutaja roll/nimi, ajaline kestus inimtundides ja tähtaeg.

PP 1.3 Projektiplaanis peab kajastuma töö tegemiseks vajalikud eeldused/lähteandmed ning töö mõõdetav(ad) tulem(id). Projektiplaan peab sisaldama mh. tähtaegu, mis on rakendatavad hankijale/välisele osapoolele projekti edukaks realiseerimiseks vajalike sisendite tagamise kohta.

PP 1.4 Kõik projektiplaanis kirjeldatud tööd peavad olema omavahel loogiliselt seotud ja jaotatud iteratsioonidena.

PP 1.5 Projektiplaan peab sisaldama varuaega (puhvrit) ja selles peab arvestama riiklike pühade, puhkepäevade ja projektimeeskonna puhkustega.

PP 1.6 Projektiplaan peab olema ajakohastatud kogu projekti teostamise vältel.

PP 1.7 Lisaks projektiplaanile tuleb kirjeldada, kuidas projektijuhtimise riske maandada kavatsetakse (pakkumuse eraldi dokument).

Hankelepingu nr 2/40-25

Lisa 3

Registrite ja Infosüsteemide Keskus

„Riigikohtu veebilehe arendus“

(299179)

Tehniline kirjeldus

Tallinn 2025

2

1 Üldinfo

1.1. Minikonkursi eesmärgiks on sõlmida arendustööde hankeleping uue

kasutajasõbraliku Riigikohtu veebilehe loomiseks.

1.2. Hankelepingu eeldatav maksumus on 70 000 eurot (km-ta).

1.3. Hankelepingu järgsete tööde (tehnilise kirjelduse punktid 3 ja 4 ning selle

alapunktid) üleandmise lõpptähtaeg on 6 kuud arvates hankelepingu sõlmimisest.

Juhul, kui pakkuja leiab, et hankija poolt etteantud tähtaeg on ebarealistlik, siis on

pakkuja kohustatud seda pakkumust tehes või sellele eelnevalt hankijale teada

andma. Hankelepingu täitmisel on vastavate sooviavalduste esitamine välistatud, v.a

hankija poolt lisatööde tellimise olukorras või muul riigihangete seaduse §-s 123

toodud lepingu muudatust võimaldavas olukorras.

1.4. Hankelepingujärgseid töid võib teostada kahes (2) etapis. Pakkumusele tuleb

lisada detailne etappide ja nende maksumuste kirjeldus. Töid arveldatakse ka

vastavalt kahes osas. Etappideks jaotamisel tuleb arvestada, et viimase etapi

maksumus ei tohi olla vähem kui 50% lepingu kogumaksumusest.

1.5. Hankeleping jõustub allkirjastamise hetkest ja kehtib kuni lepingujärgsete

kohustuste nõuetekohase täitmiseni. Pakkujal peab olema valmisolek alustada

hankelepingujärgsete tööde teostamisega esimesel võimalusel, kuid mitte hiljem kui 1

kuu jooksul hankelepingu sõlmimisest ja nimetatud tingimusega tuleb pakkujatel

pakkumust, sh projektiplaani esitades arvestada.

1.6. Maksjaks ning valmiva veebilehe omanikuks on Riigikohus.

1.7. Iga viidet, mille hankija teeb käesolevas dokumendis mõnele riigihangete

seaduse paragrahvi 88 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“.

1.8. 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“.

2 Praegune olukord ja eesmärk

2.1. Riigikohtu kodulehe senine versioon1 on olnud kasutusel aastast 2017. Uue

kodulehe loomise vajadus on tingitud vananenud platvormist Drupal 7, mille

kasutamine pole toe lõppemise tõttu enam turvaline ega jätkusuutlik.

2.2. Praegune veebileht ei vasta täielikult WCAG nõuetele.

2.3. Riigikohtu uue veebilehe loomise vajadus tuleneb tehnilisest aspektist, et platvormi

üleviimisel Drupal 7-lt kaasaegsele oleks töömaht sarnane uue tegemisega.

2.4. Minikonkursi eesmärk on uue Riigikohtu veebilehe loomine vastavalt tehnilisele

kirjeldusele lisatud prototüübile (Lisa 1). Vähendatud on olulisel määral senise

veebi funktsionaalsust, jättes uuelt lehelt välja lahendite ja menetluste

otsingusüsteemi (sama info on leitav riigiteataja.ee veebilehelt). Lihtsustamise

1 Kättesaadav: https://www.riigikohus.ee/

3

peamine põhjus on loodava veebilehe maksumuse ja valmimis-tähtaja

vähendamine.

2.5. Uus koduleht peab muutma Riigikohtu teabe ja lahendite info tarbimise

kasutajasõbralikumaks ning tõstma üleüldist kasutajakogemust. Erinevalt vanast

veebilehist peab uus veebileht vastama ka WCAG nõuetele.

2.6. Riigikohtu veebilehe kontaktide alamleht muutub käsitsi sisestatavaks, sest SAP-

ga ühendatult on kontaktide muutmine, struktuuride järjekorra määramine,

telefoninumbrite peitmine jms. oluliselt ajamahukam kui otse veebilehe haldusest

tehes. Lisaprobleemina on käsundus- vm. lepingu alusel töötajad, kes SAP-i kaudu

kontaktidesse ei teki.

3. Tulemid ja nõuete kirjeldus

3.1. Hankelepingu tulemusena peab valmima uus Riigikohtu veebileht.

3.2. Riigikohtu veebilehe funktsionaalsusi hõlmavate tulemite nõuded on eraldi

kirjeldatud punktis 4 „Funktsionaalsed nõuded“ ning nähtuvad kirjeldamata osas

käesolevale tehnilisele kirjeldusele lisatud veebirakenduse kasutajaliidese

prototüübist (vt lisa 1).

3.3. Lisaks eeltoodule loetakse tulemiks ka projekti arendusfaasi jooksul tekkinud

dokumentatsiooni. Hankijale antakse üle järgnevad dokumendid:

1. Arenduste kirjeldus, sh äri- ja süsteemianalüüsi dokumentatsioon

2. Veebirakenduse arhitektuuri kirjeldus

3. Veebirakenduse kasutus- ja haldusjuhendid

4. Administreerimisjuhend/paigaldusjuhend

5. Testimise tulemusena valminud dokumendid

6. Varundus/taasteplaan

7. Versiooni kirjeldus

8. Nõuded arendustele vastavustabel

9. Kasutajaliideste ja WCAG nõuete vastavustabel

Detailsed nõuded üleantavatele dokumentidele on leitavad Lisas 4 – Dokumentatsiooniplaan.

Arenduste kirjelduse dokumendi sisule esitatud täiendavad nõuded leiab Lisast 5 – Nõuded

süsteemianalüüsile. Testimise tulemusena valminud dokumentide sisule esitatud täiendavad

nõuded leiab Lisast 3 – Nõuded testimisele.

3.4. Nõuded arendusele

Arendustööde alustamise eelduseks on vastava osa analüüs (nii äri- kui süsteemianalüüs).

See tähendab, et iga arendustöö planeerimisel tuleb arvestada sellele eelnevate vajalike

analüüsi ja tagasiside kogumise tegevustega. Vältida tuleb olukorda, kus funktsionaalsuse

arendamist alustatakse enne, kui vastava osa analüüs on valmis ja Hankijaga läbiräägitud.

Arendustööks vajaliku analüüsi läbirääkimine Hankijaga ei võta Hankijalt õigust arendustööde

osas puuduste kõrvaldamist nõuda või arendustööde teostamisel juba läbiarutatud analüüsis

muudatusi teha. Samuti ei tähenda eelkirjeldatud protsess, et Hankija ütleks Pakkujale ette iga

programmeerimistoimingu. Hankija eesmärgiks on ärivisiooni elluviimine, mis eeldab pakkujalt

vastava tehnilise kompetentsi olemasolu.

4

Loodav veebileht tuleb luua Drupal 10 või uuemal sisuhaldusplatvormil. Rakendada peab

olema võimalik lisamooduleid nagu Solr ja Matomo.

Veebileht ja selle haldusliides peavad olema kasutatavad koos Cloudflare teenusega.

Dockeri võimekus - veebilehe peab saama käivitada Dockeri vahendite abil (Dockerfile ja

docker-compose).

Pilve võimekus - Veebilehele peab olema loodud Kubernetese lahendus Helm vahenditega

ja kaasa pandud Helm Chart koos soovituslike väärtustega.

Arendustöödes arvestatakse arendustööde tegemise ajal kehtivate WCAG nõuetega.

Veebirakendus peab vastama avaliku teabe seaduse §-s 32 ja ministri määruses nr 20

„Veebilehe ja mobiilirakenduse ligipääsetavuse nõuded ning ligipääsetavust kirjeldava teabe

avaldamise kord„ kehtestatud ligipääsetavusnõuetele (sealhulgas vastavus standardile EN

301 549). EN 301 549 V3.2.1 (2021-03) on avaldatud pdf-versioonis standardiorganisatsiooni

ETSI veebilehel:

https://www.etsi.org/deliver/etsi_en/301500_301599/301549/03.02.01_60/en_301549v03020

1p.pdf.

Üldised mittefunktsionaalsed nõuded ja ülejäänud nõuded arendusele on toodud Lisas 2 –

Nõuded arendustele. Arendustööde raames ei kohaldu järgmised Lisa 2 nõuded: NA-2, NA-

17, NA-36, NA-55, NA-58, NA-60, NA-63, NA-68, NA-69, NA-70, NA-77, NA-81, NA-82, NA-

83, NA-86, NA-103, NA-105, NA-112, NA-115, NA-116, NA-120.

Arendamisel tuleb lähtuda Hankija sätestatud arenduse tavadest ja töökorraldusest, täpsemad

nõuded on toodud Lisas 6 – Arenduse tavad ja töökorraldus.

4. Funktsionaalsed nõuded

Alljärgnev kirjeldab täpsemalt Riigikohtu veebirakenduse funktsionaalsuste tulemitele

esitatavaid nõudeid. Analüüsi käigus võivad selguda täiendavad nõuded, mis on vaja tulemite

saavutamiseks kasutusele võtta. Prototüübilt nähtuvate, kuid kirjeldamata nõuete osas tuleb

lähtuda prototüübist.

4.1. Avalehel lahendid

Riigikohtu avalehel kuvatakse viimati tehtud lahendeid, et Riigikohtu praktika oleks kõigile

koheselt kättesaadav.

Nõuded

ID Kirjeldus

Üldised reeglid

AV-01 Lahendite andmed esitatakse tabelina, mis sisestatakse Drupalisse käsitsi.

Lahendid

AV-02 Kuvatakse ajaliselt viimased 6 lahendit.

AV-03 Uuemad lahendid kuvatakse üleval.

AV-04 Võimalus vanemaid lahendeid vaadata paginatsiooniga, hinnanguliselt tekib

ligi 250 rida aastas; nelja aastaga tuhat rida.

Lahendite tabelis kuvatavad andmed

5

AV-05 Kuupäev – lahendi koostamise kuupäev. Ei saa sorteerida.

AV-06 Kohtuasja nr. - tavatekst, ei ole lingina. Ei saa sorteerida.

AV-07 Kohtuasja kokkuvõte.

AV-08 Kokkuvõttest kuvatakse vaikimisi 2 esimest rida. „Loe rohkem“ käsklusele

vajutamisel saab kasutaja kokkuvõtet tervikuna lugeda.

AV-09 „Loe vähem“ käsklusele vajutades saab kokkuvõtet vähendada.

5. Hankelepingu põhised nõuded ja töökorraldus

5.1. Hankelepingujärgsed tööd viiakse läbi Riigikohtu poolsel juhendamisel koostöös

RIKi tugiinfosüsteemide tiimiga. Lepingu täitmisel minikonkursi eesmärkidele

vastavate tulemuste saavutamiseks näeb hankija ette tihedat koostööd täitja

meeskonnaga, kellega jõutakse koostööna ühistele arusaamadele

kooskõlastatavate tegevuste osas ning üleantavate tulemite detailides.

5.2. Hankelepingujärgsed arendustööd peavad vastama RIKis kehtestatud nõuetele,

mille hulgas tuleb arvesse võtta nõudeid:

5.2.1. Nõuded arendustele, v 7.0 (Lisa 2);

5.2.2. Nõuded testimisele (Lisa 3);

5.2.3. Nõuded süsteemianalüüsile (Lisa 5);

5.2.4. Arendamise tavasid ja töökorraldus (Lisa 6).

5.3. Hankelepingu täitmisel tuleb järgida dokumentatsiooniplaani nõudeid. Lepingu

lõppemisel annab täitja hankijale üle arendusega seotud dokumentatsiooni

vastavalt dokumentatsiooniplaanis esitatule (Lisa 4 – Dokumentatsiooniplaan)

arvestades, et ei kohaldu järgmised dokumentatsiooniplaani nõuded: 5. Testplaan

ja testimise tulemusena valminud dokumendid; 6. Varundus/taasteplaan ning 11.

Andmekogude semantiline kirjeldus ja koosseis.

5.4. Kogu dokumentatsioon tuleb vormistada RIK Confluence keskkonnas, kui ei lepita

kokku teisiti, sh äri- ja süsteeminõuded tuleb vormistada kasutuslugude põhiselt

koos. Koostatud dokumentatsioon peab vastama vähemalt järgmistele

vormistusnõuetele:

5.4.1. Dokumentide teemad ja peatükid on loogiliselt struktureeritud ja esitatud koos

sisukorraga (või seda asendava funktsionaalsusega).

5.4.2. Dokumendid ei sisalda kirjavigu ja on koostatud võimalikult üheselt arusaadava

ja selge lauseehitusega.

5.4.3. Dokumentide sisu osas vastutuse selgemaks eristamiseks on dokumendis

märgitud kõik selle koostajad eraldi nende osade juures, mida iga koostaja

koostas.

5.4.4. Kõik kasutatud allikmaterjalid peavad olema viidetes ära märgitud ning

viitamine teistele dokumentidele on selge ja ühtses stiilis.

5.4.5. Dokumendid on koostatud eesti keeles.

6

5.5. Hangitavate tööde teostamise tegevuskava kirjeldatakse ära pakkumuse osana

esitatavas projektiplaanis. Tegevuste ajalise järjestuse ja korduvuse valib pakkuja.

Projektiplaan peab sisaldama ajakava kõikide tehnilises kirjelduses kirjeldatud

tööde läbiviimiseks ja vastama projektiplaanile esitatud nõuetele (Lisa 7– Nõuded

projektiplaanile).

5.6. Lisaks projektiplaanile tuleb kirjeldada, kuidas projektijuhtimise riske maandada

kavatsetakse (pakkumuse eraldi dokument). Riskide maandamise võimalused ja

halduse ettepanekud (lähtuvalt käesolevast projektist) on esitatud selgelt,

detailselt, läbimõeldult, struktureeritult ja põhjendatult.

5.7. Autoriõiguste realiseerimise viisiks on EUPL.

5.8. Arendus- ja testkeskkondades kasutatakse ainult testandmeid või avalikustatud

andmeid. Andmetöötluse vajaduse ilmnedes Live keskkonnast antakse

töödeldavad andmed hägustatud või muul viisil anonümiseeritud kujul.

5.9. Arendust testitakse nii täitja kui ka hankija poolt RIKi hallatavas keskkonnas.

Lisad

1. Veebirakenduse prototüüp: https://www.figma.com/proto/KlXHCMZZijg4OqKAclB6nI/Riigikohus-UX%2FUI?page- id=4373%3A6644&node-id=4959- 20932&viewport=6081%2C1963%2C0.43&scaling=scale-down&starting-point-node- id=4959%3A20932&mode=design&t=injNXJ2j9iDODBzP-1

2. Nõuded arendustele, v 7.0

3. Nõuded testimisele

4. Dokumentatsiooniplaan

5. Nõuded süsteemianalüüsile

6. Arenduse tavad ja töökorraldus

7. Nõuded projektiplaanile