Lisa 2 – arendusnõuded

1

RAAMLEPING nr 1-18/2026/58

Riigimetsa Majandamise Keskus, registrikood 70004459, aadress Mõisa/3, Sagadi küla,

Haljala vald, 45403 Lääne-Viru maakond (edaspidi RMK või tellija), keda esindab Vabariigi

Valitsuse 09.01.2007 määrusega nr 4 kinnitatud “Riigimetsa Majandamise Keskuse

põhimääruse” § 18 lõike 1 alusel juhatuse liige Agne Aija, ühelt poolt

ja

Nortal AS, registrikood 10391131, aadress Tallinn, Lasnamäe linnaosa, Lõõtsa tn 6, 11415

Harju maakond (edaspidi täitja), keda esindab volikirja alusel Olga Golubeva, keda edaspidi

nimetatakse ka eraldi pool või koos pooled, on sõlminud raamlepingu (edaspidi leping)

alljärgnevas:

1. Üldsätted

1.1. Käesolev leping sõlmitakse riigihanke „Metsatööde operatiivse juhtimise infosüsteem

“Metsajuht"“(edaspidi nimetatud riigihange, viitenumber 305832, DHS 1-47.3646)

tulemusena.

1.2. Lepingu juurde kuuluvateks lahutamatuteks osadeks loetakse riigihanke alusdokumendid

(RHAD), täitja riigihankes esitatud pakkumus ja riigihankes tellija antud selgitused ning

pooltevahelised kirjalikud teated, mida lepingu lisadena eraldi ei allkirjastata.

1.3. Lepingul on sõlmimisel järgmised lisad, mis on lepingu lahutamatuteks osadeks:

1.3.1. Lisa 1 – tehniline kirjeldus;

1.3.2. Lisa 2 – arendusnõuded;

1.3.3. Lisa 3 - isikuandmete töötlemise nõuded volitatud töötlejale.

1.4. Vastuolu korral lepingu ja lisa vahel, kohaldatakse lepingu lisas sätestatut, kui

konkreetsest lepingu sättest ei tulene teisiti.

1.5. Leping ei kohusta tellijat täitjalt teenust tellima. Tellija tellib teenust vastavalt reaalsele

vajadusele ja olemasolevatele võimalustele, kooskõlas tehnilise kirjeldusega.

2. Lepingu ese

2.1. Lepingu esemeks on metsatööde juhtimise infosüsteemi “Metsajuht” arendus- ja

hooldustööd (edaspidi „teenus“ või „töö“), mida täitja kohustub läbi viima vastavalt

RHAD-le, sõlmitud lepingule ja selle lisadele.

2.2. Pooled täpsustavad teenuse osutamise käigus teenuse sisu, ulatust ja ajakava lähtuvalt

kiiruse, kvaliteedi, säästlikkuse ja otstarbekuse põhimõtetest. Pooltel on õigus teha

nimetatud küsimustes omapoolseid ettepanekuid ja pakkumisi, mis tagaks teenuse parima

teostuse.

2.3. Täitja teostab töö kooskõlas tehnilise kirjeldusega ja parimate praktikatega

tarkvaraarenduses.

2.4. Lepingu täitmise keel on eesti keel, muuhulgas on see ka lepingu sõlmimise,

töökoosolekute jm suhtluse ning tööde dokumenteerimise keel.

2.5. Täitja on kohustatud lepingu alusel ja selles sätestatud maksumuse eest teostama ka nn

sidustöid, mis ei ole lepingus sõnaselgelt sätestatud, kuid mille teostamine on headest

tavadest ja täitja ametialasest professionaalsusest lähtudes nõutavad ja/või vajalikud

lepingust tuleneva eesmärgi saavutamiseks. Tööde teostamisel tuleb lähtuda tõhususe,

kvaliteedi, säästlikkuse ja otstarbekuse põhimõtetest ning arvestades vastavas

tegevusvaldkonnas kehtivaid õigusakte, standardeid ja head tava.

2

3. Lepingu täitmine, tööde teostamine

3.1. Töid teostatakse üldjuhul täitja valitud asukohas tellija ja täitja poolt nimetatud

arendusmetoodikaid kasutades. Täitja teostab kogumaksumuse eest ka nn sidustöid, mis

ei ole lepingus sõnaselgelt sätestatud, kuid mille teostamine on headest tavadest ja täitja

ametialasest professionaalsusest lähtudes nõutavad ja/või vajalikud lepingust tuleneva

eesmärgi saavutamiseks

3.2. Täitja alustab lepingu täitmist esimesel võimalusel pärast selle sõlmimist. Tellija annab

täitjale teada lepingu täitmise algustähtaja e-kirja teel. Tellijal on õigus ühepoolselt

nimetatud tähtaega edasi lükata vajaliku perioodi võrra põhjendatud vajaduse esinemisel.

Tellija teavitab täitjat lepingu täitmise hilisemast algustähtajast ja täitmisega viibimise

põhjusest e-kirja teel.

3.3. Täitja kohustub rakendama tööde teostamisel meeskonnaliikmeid, kelle ta on esitanud

lepingu sõlmimise aluseks olevas hankemenetluses.

3.4. Lisaks meeskonnaliikmetele, kelle CV-d on lisatud pakkumusele, võib täitja vajadusel

kaasata lepingu täitmisesse meeskonnaliikmeid, kes ei pea vastama hankemenetluses

vastavatele spetsialistidele tellija poolt kehtestatud nõuetele. Nimetatud spetsialistid

osalevad lepingu täitmisel ainult koos hankemenetluses kehtestatud nõuetele vastavate

spetsialistidega, ilma lisatasu küsimata. Täitja peab tellijat piisav aeg ette kirjalikult

informeerima planeeritavast meeskonnaliikme lisamisest ning spetsialisti lisamine võib

toimuda ainult tellija kirjalikku taasesitamist võimaldavas vormis antud nõusolekul ja

kooskõlas RHAD-ga. Tellijal on õigus täitja poolt pakutavast lisa meeskonnaliikmest

keelduda.

3.5. Täitja tagab lepingu täitmise eesti keeles. Lepingu täitmisesse kaasatud

meeskonnaliikme(te) eesti keele oskus kõnes ja kirjas peab olema vähemalt tasemel, mis

võimaldab meeskonnaliikme(te)l vahetult osaleda nii meeskonnatöös (koosolekud jmt)

kui teostada lepingu esemeks olevaid arendustöid ja saada iseseisvalt, ilma täiendava

tellija poolse juhendamiseta, aru tööülesannete ja tehniliste juhiste sisust ja tellijal

kasutusel olevate töökeskkondade juhistest. Juhul, kui meeskonnaliikme(te) eesti keele

oskus ei ole piisaval tasemel, tagab täitja meeskonnaliikme(te)le omal kulul tõlgi, sh juba

sõlmitud lepingu täitmise olukorras, kui ilmnevad probleemid eespoolviidatud

kompetentsidega. Taolisel kujul lepingu täitmine ei tohi kahjustada lepingu täitmise

kvaliteeti ega kiirust, vastasel juhul on tegu lepingu olulise rikkumisega.

3.6. Töid vahetult teostavate spetsialistide asendamine/lisamine võib toimuda tellija kirjalikku

taasesitamist võimaldavas vormis antud nõusolekul. Täitja on kohustatud teavitama

tellijat meeskonnaliikme asendamisest/lisamisest kirjalikku taasesitamist võimaldavas

vormis vähemalt 14 päeva enne meeskonnaliikme asendamist/lisamist, kusjuures täitja on

kohustatud tagama, et uue meeskonnaliikme kompetents on vähemalt võrdne lepingu

sõlmimise aluseks olevas hankes vastavale meeskonnaliikmele esitatud nõuetega. Tellijal

on õigus keelduda täitja poolt lepingu täitmiseks esitatud meeskonnaliikme

asendamiseks/lisamiseks pakutavast meeskonnaliikmest, kui pakutav spetsialist ei vasta

eelnimetatud nõuetele või kui pakutava isiku kompetentside hindamisel ei oleks täitja

pakkumus olnud hankemenetluses edukas (so kohtleks teisi pakkujaid ebavõrdselt).

3.7. Lisaks punktis 3.6 sätestatule kohustub täitja tellijat vähemalt 14 päevaette teavitama

kirjalikku taasesitamist võimaldavas vormis meeskonnaliikmete planeeritud puhkustest

ja lähetustest juhul, kui puhkuse või lähetuse kestus on 4 või rohkem kalendripäeva.

3.8. Täitja annab kogu lepingu täitmise perioodi vältel jooksvalt tagasisidet tellija küsimustele

ja arupärimistele ning annab tellija nõudmisel jooksvalt ülevaate ja esitleb juba teostatud

või teostamisel olevaid töid.

3.9. Pretensioonid töö tulemi plaanipärase edenemise, teostamise efektiivsuse ja kvaliteedi

kohta annab tellija teada lisaks meeskonnaliikmele ka täitja lepingulisele kontaktisikule.

3

Olulises ulatuses või korduvaid kõrvalekaldeid tellija juhiste järgimata jätmisel loetakse

lepingu rikkumiseks.

3.10. Tellijal on õigus igal ajal lepingu täitmise käigus kolme kalendripäevase etteteatamisega

kokku kutsuda koosolekuid, kus täpsustatakse töökorraldust, tellija ja täitja ootuseid vmt.

3.11. Tellija on kohustatud kõikidele täitja lepingu täitmisega seotud põhjendatud küsimustele

vastama hiljemalt kolme tööpäeva jooksul. Juhul, kui küsimusele vastamine nõuab

tellijalt pikemat analüüsi, on tellija kohustatud andma eeltoodud kolme tööpäeva jooksul

täitjale täpse kuupäeva, millal tagasisidet antakse, sellisel juhul on täitjal õigus nõuda

tarne tähtaja proportsionaalset pikendamist.

3.12. Täitja tagab ja vastutab tööks vajalike töövahendite, litsentside ja autoriõiguste eest

iseseisvalt.

4. Analüüsi-, hooldus- ja arendustööde teostamine

4.1. Tööde teostamiseks esitab tellija täitjale tellimuse. Eraldiseisvaid kirjalikke

hankelepinguid ei sõlmita.

4.2. Töid teostatakse agiilselt tunnipõhise arvestusega, akteeritakse ja arveldatakse 1 (üks)

kord kuus eelmise kuu töötundide ja lepingus sätestatud tunnitasu alusel. Seejuures tellija

kontrollib täitja esitatud akti tundide vastavust tehtud tööle ning kinnitab või esitab

küsimusi/tagasisidet hiljemalt 14 päeva jooksul peale akti esitamist.

4.3. Täitja koostöös tellija kontaktisikuga valmistavad ette (analüüsib ja kirjeldab)

tööülesanded tellija tööülesannete projektirühmas. Täidetavad ülesanded (tulemid)

lepitakse kokku kohtumistel (ehk projektirühma koosolekul). Sellele eelnevalt hinnatakse

ja täiendatakse tulevaste tööde/tulemite sisu ja töömahtu selleks ettenähtud kohtumisel.

Täitja peab lepingu täitmisel juhinduma tellija poolt edastatud juhistest ja ülesannetest.

4.4. Konkreetse töö teostamisel lepitakse projektirühmas kokku rakendatava meeskonna

suurus ja rakendatavad rollid vastavalt pakkumusele, tellija vajadustele ja prioriteetidele

tulenevalt tellitava teenuse konkreetsest sisust.

4.5. Loodavad tulemid antakse üle tellija koodirepositooriumi kaudu vastavalt tellija juhistele.

Arendustööde raames tehtud lähtekoodi paneb täitja tellija koodirepositooriumisse ja

paigaldab tellija arenduskeskkonda vähemalt 1 (üks) kord nädalas. Täitja

meeskonnaliikmetele luuakse tellija poolt ligipääs koodirepositooriumile lähtekoodide,

andmebaasimuudatuste ning muude tulemite või nende muudatuste üleandmiseks.

4.6. Enne lähtekoodi repositooriumisse lisamist peab kood/teostatud töö/tulem olema:

4.5.1 iseendaga kooskõlas (pole vastuolusid, katkiseid mooduleid, iseendaga vastuolus

funktsionaalsust);

4.5.2 üldharu/muu haru tulemiga kooskõlas;

4.5.3 edaspidi mugavalt kasutatav ja mõistetav, ehk sellel on olemas oma enda

sisseehitatud testid, mis peale järgnevaid võimalikke arendusi/tegevusi näitaks,

kas see konkreetne funktsionaalsuse osa on endiselt korras, või läks katki ja tuleb

korrastada.

4.6 Äriliselt võtmetähtis funktsionaalsus peab olema loodavas koodis varustatud

kommentaaridega (klasside ja meetodite kommentaarid).

4.7 Tarnitav lepingu ese peab ühilduma tellija poolt nõutud tehnilise lahendusega (erisused on

lubatud tellija kontaktisiku kirjalikku taasesitamist võimaldavas vormis esitatud

nõusolekuga), sealhulgas:

4.7.1 järgima tellija poolt nõutud tehnilise lahenduse ideoloogiat süsteemsete

protseduuride osas ja infosüsteemi arhitektuurset lahendust ja kasutusloogikat;

4.7.2 taaste- ja varundusprotseduurid peavad olema ühilduvad tellija poolt soovitud

tehnilise lahendusega;

4

4.7.3 lepingu ese ei tohi põhjustada süsteemi töö terviklikkuse või muid toimimise

häireid ega jõudluse langust;

4.7.4 lepingu ese peab olema tellija poolt nõutud infosüsteemiga ühetaoline ning

sobituma olemasolevatesse ekraanivormidesse ja töövoogu;

4.7.5 lepingu ese peab vastama hankes esitatud arendusnõuetele, välja arvatud nendele,

millele loodav infosüsteem ei kohaldu või on täitja poolt kirjalikult välja toodud

ja põhjendatud ning tellija poolt kirjalikult kinnitatud erand;

4.8 Tööde teostamise käigus tuleb täitjal vajadusel uuendada ka lepingu eseme

dokumentatsiooni (kirjeldused, juhised, protsessianalüüs jmt) ja dokumentatsioon tellijale

üle anda. Dokumentatsiooni üleandmisel eelistatakse elektroonilist vormi.

4.9 Tööde üldisteks vastuvõtukriteeriumiteks on:

4.9.1 vastavus lähteülesandes toodud ja projektirühmas kokkulepitud ärilisele- ja

tehnilisele kirjeldusele;

4.9.2 vigade ja kõrvalmõjude puudumine.

4.10 Tellijal on 14 tööpäeva aega kontrollida vastuvõtmiseks esitatud tööde lepingutingimustele

vastavust. Tellija kontaktisik võib nimetatud tähtaega pikendada, kui pikendamine on

põhjendatud.

4.11 Üleandmis-vastuvõtmisakti valmistab ette täitja vastavalt tellija poolt etteantud vormile

ning see allkirjastatakse poolte kontaktisikute poolt digitaalselt. Täitja esitab tellijale

punktis 4.2 nimetatud ja akteeritud tööde teostamise järel üleandmis-vastuvõtmisakti,

milles on sätestatud täitja poolt teostatud tööde tulemi kirjeldus, ning vastava töö

maksumus. Vajadusel täpsustatakse aktis üle antud tulemit. Üleandmise-vastuvõtmise akti

on õigus allkirjastada lepingu kontaktisikutel.

4.12 Peale üleandmise-vastuvõtmise akti allkirjastamist esitab täitja tellijale arve teostatud

tööde eest vastavalt üleandmise-vastuvõtmise aktile ja punktile 4.11.

4.13 Kui Tellijal puuduvad lepingu eseme osas pretensioonid, allkirjastavad pooled Lepingu

eseme üleandmise-vastuvõtmise akti.

4.14 Mistahes Teenuse osa valmimisel võib Tellija anda välja vastuvõtuakti vastava osa kohta

ning aktis fikseeritakse puudused koos puuduste kõrvaldamise tähtajaga. Selline

vastuvõtmine ei mõjuta Täitja kohustust täita kõiki Lepingus ettenähtud kohustusi.

4.15 Tellija poolt Teenuse vastuvõtmine ei vabasta Täitjat vastutusest Teenuse üleandmisel-

vastuvõtmisel avastamata jäänud vigade või Teenuse mittenõuetekohasuse eest.

4.16 Tugi- ja hooldustööde tellimuses edastab Tellija Töövõtjale teenuse osutamise

alguskuupäev, maksumus ning vajadusel muud andmed.

5. Garantiitingimused

5.1 Üle antud tulemi osas kohaldub garantii alljärgnevatel põhimõtetel:

5.1.1 garantiiaeg on 12 (kaksteist) kuud alates hetkest, mil viimase etapi tulem on

tellija poolt lepingu kohaselt vastu võetud;

5.1.2 olukorras, kus töö pole akti alusel vastu võetud, on etapi tulemi osaline või

täielik toodangus kasutuselevõtt aluseks nende osade garantiiperioodi

algusele;

5.1.3 täitja on kohustatud tagama garantiiajal tulemil ilmnenud puuduste tasuta

kõrvaldamise vastavalt vea prioriteetsusele järgnevalt:

5.1.3.1 kriitilised vead 2 tööpäeva jooksul peale sellekohase teate

edastamist tellija poolt täitjale. Kriitiliseks veaks loetakse tarkvara

arendusega seotud viga, mille tõttu: tarkvara tervikuna ei ole

võimalik kasutada; tarkvara põhifunktsionaalsus ei tööta või on

oluliselt häiritud; tarkvara lubab/teostab mitteautoriseeritud

operatsioone; kahjustatud on süsteemis olevad andmed; kasutajale

5

või seotud infosüsteemidele/andmebaasidele väljastatakse

ebaõigeid andmeid/tulemusi. Kriitiliseks veaks loetakse

sealhulgas ebamõistliku sagedusega esinevad sarnased

mittekriitilised vead;

5.1.3.2 mittekriitilised vead 5 tööpäeva jooksul peale sellekohase teate

edastamist tellija poolt täitjale. Mittekriitiliseks veaks loetakse

infosüsteemi toimehäiret, mis ei ole põhjustatud riistvarast või

muust tarkvarast või muust arendustööst ja mida ei saa käsitleda

kriitilise veana.

5.2 Veateade loetakse esitatuks, kui tellija või tellija kontaktisik on veateate esitanud

kirjalikku taasesitamist võimaldavas vormis täitjale või täitja lepingujärgse kontaktisiku

e-posti aadressil.

5.3 Täitja teostab garantiiaja vältel vajalikud tööd kasutades lepingukohast meeskonda,

milles on võimalik muudatusi teha vastavalt lepingu punktile 3.6.

6 Poolte vastutus

6.1 Pooled vastutavad lepinguliste kohustuste rikkumise eest. Kohustuse rikkumisel on

teisel poolel õigus kasutada kõiki seadusest või lepingust tulenevaid

õiguskaitsevahendeid vastavalt võlaõigusseadusele.

6.2 Lisaks mujal lepingudokumentides sätestatule, on tellijal õigus nõuda ja täitjal on

kohustus maksta leppetrahvi tarne üleandmisega või garantiitööde teostamisega

viivitamisel 0,5 % vastava töö maksumusest iga viivitatud tööpäeva eest.

6.3 Poolte hankelepingust tulenev koguvastutus on piiratud hankelepingu

kogumaksumusega.

6.4 Lepingu olulise rikkumise korral on tellijal õigus esitada täitjale leppetrahvi nõue 10

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

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

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

hankelepingust taganeda.

6.5 Oluliseks rikkumiseks loevad pooled lisaks võlaõigusseaduses ja mujal lepingus

sätestatule muuhulgas:

6.5.1 mõjuva põhjuseta lepingu täitmise katkestamine või täitmisele mitte

asumine;

6.5.2 valeinfo esitamine;

6.5.3 lepingu täitmiseks vajalike õiguste (sealhulgas load, litsentsid,

intellektuaalse omandi õigused) puudumine;

6.5.4 intellektuaalse omandi õiguste ja nende kasutamise tingimuste rikkumine;

6.5.5 korduv (vähemalt kahel korral) meeskonnaliikme asendamine isikuga, kes

ei vasta kokku lepitud nõuetele või meeskonnaliikme asendamine ilma

tellija eelneva vähemalt kirjalikku taasesitamist võimaldavas vormis antud

nõusolekuta;

6.5.6 konfidentsiaalsuskohustuse rikkumine;

6.5.7 lepingujärgsete kohustuste korduvat (vähemalt kahel korral) täitmata

jätmist;

6.5.8 tähtaegselt lepingu täitmata jätmist selliselt, et tehnilises kirjelduses

sätestatud eesmärgi täitmine ei ole enam tähtaegselt realistlik ja/või täitja

poolse tegevuse või tegevusetuse tõttu ei ole võimalik enam kasutada

lepingu rahastamiseks ettenähtud vahendeid;

6.5.9 lepingujärgsete kohustuste üleandmine kolmandale isikule.

6.5.10 RMK infoturbe nõuetele mittevastavus.

6

6.6 Kui Täitja ei paranda teenuses esinevaid probleeme garantiitingimuste punktis 5.1.3

sätestatud lahendamise aja jooksul, on Tellijal õigus nõuda leppetrahvi järgmiselt:

6.6.1 kriitiline viga - 400 (nelisada) eurot iga ületatud tunni eest;

6.6.2 mittekriitilised vead - 200 (kakssada) eurot iga ületatud tunni eest;

7 Tasu maksmine

7.1 Pooled lähtuvad teenuse eest tasumisel pakkumuses toodud tunnihindadest.

7.2 Lepingu maksimaalne kogumaksumus on kaks miljonit (2 000 000) eurot, millele

lisandub käibemaks (edaspidi lepingu hind). Lepingu hind sisaldab muuhulgas ka kõiki

intellektuaalomandiga seotud tasusid, kui need kohalduvad.

7.3 Tellijal on õigus lepingu rikkumise korral arvestatud leppetrahvid ja kahju hüvitised

maha arvata lepingu alusel täitjale tasumisele kuuluvatest summadest.

7.4 Täitja esitab arve vaid elektrooniliselt. Arve esitamiseks tuleb kasutada elektrooniliste

arvete esitamiseks mõeldud raamatupidamistarkvara või raamatupidamistarkvara E-

arveldaja, mis asub ettevõtjaportaalis https://www.rik.ee/et/e-arveldaja.

7.5 Arved kuuluvad Tellija poolt tasumisele 15 (viieteistkümne) päeva jooksul arve

edastamisest Tellijale. E-arve peab sisaldama Teenuse tegelikku tellimust vormistanud

kontaktisiku nime või lepingust tulenevat tellija kontaktisiku nime ning selgelt ja üheselt

viitama lepingu numbrile ja arve perioodile.

8 Lepingu kehtivus, täiendamine, muutmine ja lõpetamine

8.1 Raamleping jõustub selle allkirjastamisest ja kehtib 48 kuud või kuni rahalise mahu

täitumiseni, olenevalt sellest kumb olukord saabub varem.

8.2 Lepingu muutmine on võimalik üksnes poolte kirjalikul kokkuleppel ja kooskõlas

riigihangete seadusega.

8.3 Pooltel on õigus leping üles öelda seaduses ja lepingus sätestatud alustel.

8.4 Tellijal on õigus leping olenemata põhjusest ilma täiendavat tasu või hüvitist maksmata

korraliselt üles öelda, teatades sellest täitjale kirjalikult üks (1) kuu ette.

8.5 Täitjal on õigus leping erakorraliselt üles öelda, kui:

8.5.1 lepingust tulenevate täitja kohustuste täitmine on muutunud võimatuks tellijast

põhjustatud tingimustel;

8.5.2 tellija on põhjendamatult viivitanud lepingujärgsete maksete tasumisega rohkem

kui 40 (nelikümmend) kalendripäeva.

8.6 Tellijal on õigus leping erakorraliselt etteteatamise tähtaega järgimata üles öelda ja nõuda

täitjalt tekkinud otsese varalise kahju kompenseerimist, kui:

8.6.1 täitja rikkus oluliselt lepingu kohustust, mille järgimine oli täitja kohustus;

8.6.2 puudus on tekkinud täitjast tingitud asjaoludel, puuduste kõrvaldamine teenuse

osutamisel ei ole võimalik ja puudus mõjutab oluliselt teenuse osutamise väärtust

tellija jaoks;

8.6.3 täitja rikub muul moel lepingut sedavõrd oluliselt, et ei saa mõistlikult eeldada

lepingu jätkamist tellija poolt;

8.6.4 kui täitja ei täida lepingus ja selle lisades kokku lepitud nõudeid või on tema tegevus

muul viisil vastuolus lepingu ja selle lisadega ning kui hoolimata tellija nõudmisest

ei ole olukord paranenud;

8.6.5 kui esinevad riigihangete seaduse §-s 124 toodud lepingu ülesütlemise alused;

8.6.6 kui täitja on teadlikult esitanud enne või peale lepingu sõlmimist või lepingu

täitmise käigus tellijale valeinformatsiooni.

8.7 Lepingu lõppemisel jäävad kehtima kõik sellised sätted, mille osas on lepingus sätestatud

nende kehtima jäämine pärast lepingu lõppemist.

7

8.8 Lepingu ülesütlemine, lõpetamine või lõppemine ei vabasta pooli kohustuste täitmisest,

mis neil tekkisid enne lepingu ülesütlemist, lõpetamist või lõppemist. Lepingu

ülesütlemisel, lõppemisel või lõpetamisel teostavad pooled kõik teenuse osutamise

kulude ja arvete tasaarvestused 30 päeva jooksul alates lepingu lõpetamise kuupäevast,

juhindudes sealjuures faktiliselt tehtud kulutustest ja nõuetekohaselt osutatud teenusest.

8.9 Lepingu ülesütlemisel, lõpetamisel või lõppemisel tuleb täitjal edastada tellijale

viivitamatult (ülesütlemise teate saamisest või kokkuleppe allkirjastamisest 3 tööpäeva

jooksul lepingu lõppemise tähtaja saabumisel hiljemalt 10 tööpäeva enne lepingu

lõppemist) kõik seni lepingu raames tehtud ja üle andmata tööd ja seonduv materjal,

informatsioon ja dokumendid (sh poolelioleva projekti või objektiga seonduv materjal).

9 Konfidentsiaalsus ja andmekaitse

9.1 Pool kohustub tähtajatult hoidma saladuses teise poole poolt lepingu täitmise raames

saadud, edastatud või muul moel teatavaks saanud teabe ja dokumendid, mis vastavalt

avaliku teabe seaduse või muu kehtiva õigusakti nõuetele ei ole avaldamiseks kohustuslik

(konfidentsiaalne informatsioon).

9.2 Konfidentsiaalse informatsiooni avaldamine kolmandatele isikutele on lubatud vaid teise

poole eelneval kirjalikku taasesitamist võimaldavas vormis antud nõusolekul. Lepingus

sätestatud konfidentsiaalsuse nõue ei laiene informatsiooni avaldamisele poolte

esindajatele, töötajatele, audiitoritele, advokaatidele, pankadele, kindlustusandjatele,

allhankijatele või teenusepakkujatele ja muudele isikutele, keda ta oma kohustuste

täitmisel kasutab (seotud isikud).

9.3 Pool kohustub tagama, et temaga seotud isikud oleksid lepingus sätestatud

konfidentsiaalsuse kohustusest teadlikud ning rakendama temaga seotud isikutele

samaväärseid nõudeid konfidentsiaalse informatsiooni töötlemisel ja kasutamisel, kui

kehtib poolele endale lepingu ja seaduse alusel.

9.4 Täitja kohustub mitte kasutama konfidentsiaalset teavet isikliku kasu saamise eesmärgil

või kolmandate isikute huvides.

9.5 Pool kohustub tagama lepingu täitmise käigus isikuandmete töötlemise õiguspärasuse

ning vastavuse isikuandmete kaitse üldmääruses (EL 2016/679) ja teistes andmekaitse

õigusaktides sätestatud nõuetele, sh täitma organisatsioonilisi, füüsilisi ja

infotehnoloogilisi turvameetmeid konfidentsiaalsete andmete kaitseks juhusliku või

tahtliku volitamata muutmise, juhusliku hävimise, tahtliku hävitamise, avalikustamise

jms eest.

10 Load ja litsentsid

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

10.2 Tellija võib ilma ette teatamata lepingu lõpetada, kui täitja ei saa lepingu täitmiseks

vajalikku luba või litsentsi.

10.3 Tellija tagab täitjale ligipääsu tellija kontorisse ja infosüsteemidele ulatuses, milles see

on lepingu täitmiseks vajalik.

11 Intellektuaalne omand

11.1 Täitja loovutab tellijale kõik varalised õigused autoriõiguse seaduse tähenduses käesoleva

lepingu alusel üle antud tulemitele, kaasa arvatud õiguse neid reprodutseerida, levitada ja

üldsusele kättesaadavaks teha mistahes vormis ja kandjal, ilma geograafiliste

piiranguteta. Autori varalised õigused loetakse tellijale üle läinuks pärast tulemi

lepingukohast vastuvõtmist tellija poolt.

8

11.2 Juhul kui lepingus või tellimuses ei ole sõnaselgelt sätestatud teisiti, on tellijal muuhulgas

õigus:

11.2.1 lepingu eset kasutada mis tahes eesmärgil ja viisil;

11.2.2 originaalteost muuta;

11.2.3 lepingu eset või selle koopiaid laenutada ja rentida;

11.2.4 anda all-litsentse lepingu eseme või selle koopiate suhtes kehtivate õiguste kohta.

11.3 Täitja annab tellijale vastavalt valdkonnas kehtivatele parimatele praktikatele

dokumenteeritud lähtekoodi, va punktis 11.6 sätestatud juhtudel, kui on tegemist

standardtarkvaraga.

11.4 Juhul kui lepingus või tellimuses ei ole sõnaselgelt sätestatud teisiti, kehtivad nimetatud

õigused kogu autoriõiguste kehtivuse aja ja nende kehtivuse territooriumiks on kogu

maailm.

11.5 Lepingu alusel üle antud õigused ja litsents hõlmab kõiki edasisi tulemi arendusi. Lepingu

alusel annab täitja tellijale õiguse luua oma äranägemisel tuletatud teoseid tulemi

edasiarendamise teel.

11.6 Juhul kui riigihankes on pakutud tehnilises kirjelduses kirjeldatud samaväärset platvormi

ning pakkumus sisaldab vastavaid litsentse, annab täitja tellijale õiguse litsentsiga

määratletud tarkvara kasutada lepingus sätestatud ulatuses ja määras. Sellisel juhul täitja:

11.6.1 tagab lepingu täitmiseks vajalike litsentside ja vajadusel muude intellektuaalse

omandi õiguste olemasolu ja kehtivuse lepingu täitmise ajal;

11.6.2 kinnitab, et kasutusõiguse andmisega tellijale ei rikuta kolmandate isikute

autoriõigusi ega muid intellektuaalse omandi õigusi lepingu kehtivuse ajal;

11.6.3 hüvitab tellijale kõik täitja poolt käesoleva punkti rikkumisest tulenevad tellijale

tekkivad kulud ja kahjud juhul, kui täitja poolt pakutavad litsentsid rikuvad teiste

isikute õigusi;

11.6.4 esitab tellijale kõigi litsentside autoriõiguste ja muude intellektuaalomandi õiguste

kasutamisõigust tõendavad kinnitused hiljemalt ajaks, kui tellijal tekib vajadus

kasutada nimetatud õigusi;

11.6.5 annab tellijale üle dokumendid ja teabe, mis on vajalikud litsentsidest tulenevate

õiguse kasutamiseks lepingu alusel;

11.6.6 kannab kõik otsesed ja kaudsed kahjud, mis tulenevad sellest, et kolmandal isikul

on või väidetavalt on intellektuaalsest omandist tulenevaid õigusi lepinguga seotud

intellektuaalse omandi objektile.

11.7 Täitja tagab tellijale kõik vajalikud õigused lepingu täitmise käigus loodava tulemi

kontrollimiseks, testimiseks ning süsteemi paigutamiseks ka ajaks, mil tarne on üle antud,

kuid pole veel lepingukohaselt tellija poolt vastu võetud.

12 Probleemihalduse rakendus

12.1 Täitja koostöös tellija kontaktisikuga valmistavad ette (analüüsib ja kirjeldab)

tööülesanded tellija tööülesannete haldussüsteemis JIRA. Täidetavad ülesanded (tulemid)

lepitakse kokku projektimeeskonna kohtumistel. Sellele eelnevalt hinnatakse ja

täiendatakse tulevaste tööde/tulemite sisu ja töömahtu selleks ettenähtud kohtumisel.

Täitja peab lepingu täitmisel juhinduma tellija poolt edastatud juhistest ja ülesannetest.

12.2 Kasutatav probleemihalduse rakendus on tellija Atlassian Jira, mida kasutatakse teenuse

osutamisel avastatud probleemide, küsimuste jms ülesannetena registreerimiseks ja

järelevalveülesannete täitmiseks. Tellija registreerib tuvastatud probleemid, küsimused

jms probleemihalduse rakenduses ülesannetena. Pooled võivad kokku leppida, et

kasutavad Atlassian Jira asemel muud lahendust.

12.3 Probleemihalduse rakenduse tarkvarale pääseb juurde turvaliselt ja autoriseerituna

veebiaadressi kaudu.

9

12.4 Tellija võib Täitjat teavitada tuvastatud probleemidest, küsimustest jms e-posti ja telefoni

teel, kuid ülesande käsitlemise eelduseks on nende registreerimine probleemihalduse

rakenduses.

12.5 Vajaduse korral lepivad Pooled kokku täpsemas kasutuskorras probleemihalduse

rakenduse puhul, milles selgitatakse ülesannete lisamise nõudeid (rubriigid, teemad,

ülesannete prioriteetsed kategooriad jne).

13 Dokumentatsioon

13.1 Täitja varustab tellijat piisava, adekvaatse ja ajakohase dokumentatsiooniga tarkvara

funktsioneerimise kohta, mis on vajalik, et tellija saaks tarkvara ja teenuseid efektiivselt

kasutada.

13.2 Kasutusjuhendid ja muud tehnilised dokumendid tuleb esitada eesti keeles.

13.3 Dokumentatsioon peab vastama tarkvarale, sisaldama muudatusi ja olema

terminoloogiliselt üheselt mõistetav.

13.4 Dokumentide valmistamiseks ja levitamiseks kasutatakse Atlassian Confluence

keskkonda, mille juurdepääsu täitjale tagab tellija.

14 Vääramatu jõud

14.1 Kui mistahes vääramatu jõu tingimustele vastav asjaolu toob kaasa lepingu mittetäitmise

lepingus või selle lisades ettenähtud tähtajal ning selle mõju on ajutine, on lepingust

tulenevat kohustust rikkunud poole käitumine vabandatav üksnes ajal, mil vääramatu jõud

kohustuse täitmist takistas. Vääramatu jõud on mistahes asjaolu, mida pool ei saanud

mõjutada ja mõistlikkuse põhimõttest lähtudes ei saanud temalt oodata, et ta lepingu

sõlmimise ajal selle asjaoluga arvestaks või seda väldiks (nt loodusõnnetused, sõda,

mobilisatsioon, võimu- ja valitsusorganite aktid jms).

14.2 Vääramatu jõu esinemise tõttu lükatakse lepingulise kohustuse täitmise tähtaeg edasi

vastavalt asjaolu mõjumise ajale, kuid mitte enamaks kui 90 päeva.

14.3 Pool, kes ei suuda oma kohustusi vääramatu jõu tõttu täita, peab viivitamatult teatama

teisele poolele nimetatud olukorra tekkimisest ja lõppemisest. Mitteteatamine või

mitteõigeaegne teatamine võtab poolelt õiguse viidata rikkumise vabandatavusele, s.o

vääramatu jõu esinemisele ning teavitamise kohustust rikkunud pool vastutab lepingulise

kohustuse rikkumise eest vastavalt lepingus sätestatule.

14.4 Kui vääramatu jõu mõju on alaline ning ei võimalda pooltel täita lepingulisi kohustusi

täielikult või osaliselt, on pooltel õigus leping üles öelda või taganeda, tehes teisele

poolele vastava lepingust ülesütlemis- või taganemisavalduse.

15 Tellija esindamine lepingu täitmisega seotud küsimustes

15.1 Juhul, kui leping on allkirjastatud RMK juhatuse liikme poolt, on lepingu täitmisega

seotud hankelepingute sõlmimise ja/või tellimuste esitamise õigus, sõltumata nende

maksumusest, lepingu täitmise eest vastutava RMK struktuuriüksuse või piirkonna juhil

ning piiratud ulatuses lepingu, hankelepingu või tellimuse alusel teostatavate tööde

korraldamiseks volitatud spetsialistil.

15.2 Lepingu ning selle alusel sõlmitud hankelepingute ja/või esitatud tellimuste täitmiseks

vahetult vajalike lisade (tööajagraafikud, kasutatava tehnika loetelu) jmt dokumentide

allkirjastamise ning pretensioonide esitamise õigus, samuti tööülesannete andmise ja

töö kvaliteedi kontrollimise õigus, on lepingus, hankelepingus või tellimuses sätestatud

kontaktisikul.

15.3 Kui tööde üleandmis-vastuvõtmisaktide kinnitamiseks või allkirjastamiseks volitatud

isik ei ole teisiti välja toodud, on vastav õigus töid vahetult juhendaval RMK töötajal.

10

16 Tellija ja Täitja esindajad

16.1 Tellija esindajad käesoleva raamlepingu täitmisel on punktide 15.1 ja 15.2. osas: Annika

Brauer, tel +372 5348 9984, e-post [email protected].

16.2 Täitja esindaja, kes omab õigust ja kohustust jälgida lepinguga tellija ja täitja poolt

võetud kohuste täitmist, on: Olga Golubeva, tel nr +372 5657 5793, e-post

[email protected].

17 Lõppsätted

17.1 Lepingust tulenevad vaidlused lahendatakse läbirääkimiste teel. Kokkuleppe

mittesaavutamisel pöördutakse lahenduse saamiseks Harju Maakohtusse.

17.2 Täitja ei või anda lepingust tulenevaid kohustusi üle kolmandale isikule ilma tellija

kirjaliku nõusolekuta.

17.3 Lepinguga seotud informatsioonilise iseloomuga teated edastatakse poolte vahel e-posti

teel, sh pretensioonid. Muud pooltele õiguslikke tagajärgi kaasatoovad teated

vormistatakse kirjalikult ning edastatakse e-posti teel. Kontaktisiku e-posti aadressile

edastatud teate ja pretensiooni loevad pooled kätte saaduks koheselt pärast teate või

pretensiooni saatmist.

17.4 Kontaktide muutumisest kohustub pool teist poolt koheselt teavitama.

17.5 Lepingu lisad kuuluvad poolte poolt allakirjutatud lepingu juurde ja kehtivad selle

lahutamatute osadena.

17.6 Leping on allkirjastatud digitaalselt.

Lisa 1 RMK ja Nortal AS

vahelise lepingu nr 1-18/2026/58 juurde

Universaalse metsatööde juhtimise

platvormi “Metsajuht” tehniline kirjeldus

Riigimetsa Majandamise Keskus

Taust

Riigimetsa Majandamise Keskus (RMK) on Eesti suurim metsamajandaja, kelle

ülesanne on riigimetsa kestlik ja tasakaalustatud majandamine. Metsamajandamine

hõlmab metsa eest hoolitsemist kogu selle elukaare vältel – alates metsa

uuendamisest ja hooldamisest kuni küpsete metsade majandamise, looduskaitse ning

metsatööde tulemuste seireni.

RMK korraldab suurema osa metsas tehtavatest töödest teenuse ostmise kaudu,

kasutades selleks hankemenetlusi. Hangitavate teenuste hulka kuuluvad muu hulgas

puidu varumine, puidu väljavedu ja transport, metsateede ning muu metsataristu

rajamine ja hooldus, noore metsa hooldustööd ning erinevad looduskaitselised ja

keskkonnahoiuga seotud tööd. Tegemist on mitmekesiste ja mahukate töödega, mida

teostavad erinevad alltöövõtjad üle Eesti.

Metsatööde teenuse operatiivne juhtimine on valdkonnaülene ja universaalne

protsess, mis eeldab tööde planeerimise, täitmise, järelevalve ja tulemuste arvestuse

sidusat käsitlemist. Eriti oluline roll on seejuures puidu varumisel tekkival toodangu

andmestikul, mida nimetatakse puidulaoks. Puidulao andmed kajastavad muu hulgas

raiutud puidu koguseid, sortimente, kvaliteeti, asukohti ja liikumist ning on keskse

tähtsusega nii majandusliku arvestuse, logistika korraldamise kui ka juhtimisotsuste

tegemise seisukohalt. Täpsed ja ajakohased puidulao andmed on eelduseks

metsamajandamise efektiivsele, läbipaistvale ja operatiivsele juhtimisele.

Käesoleva arendusprojekti eesmärk on luua kaasaegne ja terviklik metsatööde

juhtimise infosüsteem “Metsajuht”, mis toetab erinevate valdkondade ja rollide

vajadusi metsatööde planeerimisel, elluviimisel ja jälgimisel. Infosüsteem peab

võimaldama piisavat, turvalist ja auditeeritavat andmevahetust RMK ja alltöövõtjate

vahel, toetama reaalajas või sellele lähedast andmete liikumist ning tagama süsteemi

töökindluse ja tõrgeteta toimimise. Arendatav lahendus peab looma aluse ühtsele

andmekäsitlusele, vähendama käsitööd ja vigade riski ning toetama RMK strateegilisi

eesmärke metsade kestlikul ja efektiivsel majandamisel.

Mõisted ja lühendid

Alljärgnev tabel annab ülevaate tehnilises kirjelduses kasutatud peamistest mõistetest

ja lühenditest.

Mõiste Selgitus

AXA, Axapta Microsoft Dynamics AX Enterprise Portalil põhinev töölaudade lahendus, mis on

RMK-s olnud keskseks platvormiks raietööde ja looduskaitsetööde juhtimisel.

LOKA

Looduskaitsetööde planeerimise ja juhtimise rakendus kus koostatakse

lähteülesandeid, tööde kirjeldusi ja kooskõlastusi. QGIS platformile ehitatud

pluginate komplekt.

DHS Dokumendi halduse tarkvara. Lepingute tsentraalne hoiukoht – süsteem, kus

hallatakse kõiki RMK lepinguid ja nende lisasid.

BC, Business Central Business Central - raamatupidamise ja arveldamise süsteem, mis seob aktid,

arved ja maksed. Pilvepõhine MS SaaS teenus.

Harvester Metsamasin, mis teostab raiet ja mõõdab raiutud materjali kogused.

Forwarder Metsamasin, mis veab raiutud metsamaterjali metsaladudest vahelattu.

Sortiment Metsamaterjali liigid ja mõõtmed (nt palk, paberipuu, küttepuu), mida harvester

raiub ja mõõdab.

ÜA akt, üleandmise akt Tööde üleandmise akt. Dokument, mis defineerib kogu töö olemuse. Hilisemalt

vastuvõtuakti aluseks.

VV akt, vastuvõtu akt Vastuvõtuakt – dokument, millega kinnitatakse tööde nõuetekohane täitmine ja

mille alusel vormistatakse arve.

Vaegtöö Järeltegevus, mis tuleb teha, kui tööde kontrollimisel tuvastatakse puudusi või

kvaliteediprobleeme.

StanForD1999

Metsamasinate vanem andmevahetusstandard, mille järgi genereeritakse juhiste

failid harvesteritele ja forwarderitele tänases RMK infosüsteemis. Binaarne

formaat.

StanForD2010 Metsamasinate uuem ja enimkasutatav andmevahetusstandard. Täpsemad

juhised ja täpsemad toodanguandmed. Tekstiline xml kujul formaat.

Infosüsteemi eesmärk ja ulatus

Eesmärk on luua uus terviklik ja universaalne metsatööde operatiivse juhtimise

infosüsteem “Metsajuht”.

Täna toimub metsatööde juhtimine RMK erinevates struktuuriüksustes mitmete eraldiseisvate infosüsteemide abil, mis on kujunenud vastavalt konkreetsete valdkondade ajaloolistele vajadustele. Sellest tulenevalt on tööde juhtimise protsessid, andmemudelid ja kasutajaliidesed killustunud, kuigi tööde planeerimise, üleandmise, täitmise, vastuvõtmise ja arvestuse loogika on oma olemuselt suuresti universaalne ja valdkonnaülene. Käesoleva projekti käigus on vajalik luua ühtne äriline- ja arhitektuuriline tervikpilt, et luua alus ühtse ja universaalse metsatööde juhtimise platvormi Metsajuht väljaarendamiseks.

Eeldusena lähtume põhimõttest, et metsatööde juhtimise põhivõimekused on ühtlustatavad ning koondatavad ühele ühisele platvormile, mis toetab kõiki metsatööde liike ja osapooli ühtsete ärireeglite, andmemudelite ja protsesside kaudu. Kavandatav lahendus võimaldab koondada kogu metsatööde juhtimise ühte infosüsteemi, vähendada süsteemidevahelist dubleerimist ja käsitööd ning luua selge

ja järjepidev alus edasiseks automatiseerimiseks, aruandluseks ja juhtimisarvestuseks. Ühtne platvorm toetab nii strateegilist planeerimist kui ka operatiivset tööde juhtimist ning võimaldab järkjärgulist üleminekut olemasolevatelt lahendustelt uuele terviklikule metsatööde juhtimise tarkvarale.

Analüüsi- ja arendustööd võib eeldatavalt jagada järgnevateks etappideks:

1. Detailanalüüs moodulite tehnilise lahenduse ja liidestuste kirjeldamiseks;

2. Puidulao mooduli arendus ja migratsioon;

3. Juhtimisarvestuse mooduli arendus ja migratsioon;

4. Operatiivsete tööde juhtimismooduli arendus;

5. Töövõtjate rakenduste arendus;

6. Paralleelsed analüüsid ja arendused, et Metsajuhi platvormi kasutada RMK

siseselt metsakasvatuse ja teiste valdkondade töödejuhtimise platvormina.

1. Detailanalüüs moodulite tehnilise lahenduse ja liidestuste

kirjeldamiseks

Projekti esimese etapi eesmärk on täpsustada sihtarhitektuur ja tehniline lahendus ning luua arenduse alustamiseks vajalik alus: liidestuste spetsifikatsioonid, andmevahetuse kirjeldused ja Azure’i taristu ning tarneprotsessid (CI/CD).

1) Detailanalüüs ja komponentarhitektuuri täpsustamine

Teostaja viib läbi detailanalüüsi, mille tulemusel täpsustatakse infosüsteemi komponentide ja nende omavaheliste seoste arhitektuur ning tehniline teostus. Analüüsi käigus:

• määratletakse põhikomponendid, teenused ja moodulid ning nende vastutused;

• kirjeldatakse peamised andmevood, sündmused ja integratsioonimustrid; • täpsustatakse tehnoloogilised valikud, standardid ja kvaliteedinõuded (nt

logimine, monitooring, veahalduse põhimõtted, turvaprintsiibid).

Väljund: kinnitatud tehnilise lahenduse kirjeldus ja komponentarhitektuuri dokumentatsioon.

2) Ühtse liidestuskomponendi spetsifikatsioon RMK süsteemidega

Etapp hõlmab ühtse liidestuskomponendi (integration layer / API- või integratsiooniteenus) spetsifitseerimist, mis koondab ja standardiseerib infosüsteemi liidestused teiste RMK infosüsteemidega. Spetsifikatsioon peab hõlmama:

• liidestuste ulatust ja vastutusalasid (millised süsteemid, millised teenused/objektid);

• integratsioonimehhanisme (nt REST/GraphQL, sõnumipõhine suhtlus, failipõhine vahetus – vastavalt vajadusele);

• autentimise ja autoriseerimise lahendust ning auditeeritavust; • veakäsitluse, korduskatsete, versioonihalduse ja tagurpidi ühilduvuse

põhimõtteid.

Väljund: liidestuskomponendi tehniline spetsifikatsioon ja liidestuste kataloog (endpointid, andmeobjektid, veakoodid, SLA/latentsus ootused).

3) Andmevahetuse spetsifikatsioon töövõtjate rakendustega

Teostaja spetsifitseerib töövõtjate (alltöövõtjate) rakendustega andmevahetuse terviklahenduse nii andmemudelite kui ka tehnilise teostuse tasemel. See hõlmab:

• vahetatavate andmete loetelu (nt töökorraldused, tööde staatused, puidulao/produkti andmestik, veod, asukohad);

• andmemudelite ja andmeformaadi kirjeldust (objektid, väljad, seosed, koodistike kasutus, valideerimisreeglid);

• andmevahetuse protsessikirjeldust (sünkroonne/asünkroonne, sagedus, reaalajas vs perioodiline);

• turvanõudeid (identiteedihaldus, krüpto, allkirjastamine kui vajalik, logimine ja auditijälg);

• testimise ja sertifitseerimise põhimõtteid töövõtjate liidestustele (testkeskkond, näidispäringud, automaattestid).

Väljund: esialgne ja täiendatav töövõtjate liidestuse spetsifikatsioon (API kirjeldus/OpenAPI või ekvivalent), andmemudelite kirjeldus ja andmevahetuse protsessiskeemid.

4) Azure DevOps / Azure pilvetaristu ja CI/CD ettevalmistus

Etapis luuakse Azure keskkonda arenduse ja kasutuselevõtu alusinfrastruktuur:

• vajalikud koodirepositooriumid (nt backend, frontend, integratsioonikomponent, infrastruktuur-as-kood);

• automatiseeritud tarneprotsessid (pipeline’id) ehitamiseks, testimiseks ja juurutamiseks;

• eraldatud ressursid test- ja live-keskkondade jaoks ning nende halduspõhimõtted (võrgud, identiteedid, õigused, saladused/keys);

• baaskomponendid logimiseks ja monitooringuks (nt Application Insights/Log Analytics või ekvivalent, vastavalt RMK standarditele).

Väljund: toimiv CI/CD raamistik ning eraldatud test- ja live-keskkondade algkonfiguratsioon.

5) Konteinerpõhine paigaldus- ja halduslahendus AKS-is

Teostaja kavandab ja kirjeldab, kuidas infosüsteem paigaldatakse ja hallatakse ühtse tervikuna konteinerplatvormil (Azure AKS), sh automaatne skaleerumine. Tulemus peab hõlmama:

• konteineriseerimise ja teenuste pakkimise põhimõtteid (Docker, image’ite versioonimine, registry);

• juurutusmudelit AKS-is (nt Helm/Kustomize, GitOps, namespace’ide struktuur); • skaleerumise ja töökindluse põhimõtteid (HPA, ressursilimiidid,

readiness/liveness kontrollid); • konfiguratsiooni ja saladuste haldust (Key Vault, config management); • operatiivhaldust: monitooring, logimine, häirete käsitlus,

varundus/taastepõhimõtted (kui asjakohane).

Väljund: AKS paigalduse ja halduse kontseptsioon + juurutus- ja opereerimisjuhendi esmane versioon.

2. Puidulao funktsionaalsuse migratsioon ja paralleelkasutus

Projekti teise etapi eesmärk on viia RMK puidulao keskne funktsionaalsus üle uuele platvormile, tagades olemasolevate äriprotsesside katkematu toimimise ning võimaldades infosüsteemide järkjärgulist üleminekut uuele lahendusele.

1) Olemasoleva puidulao lahenduse analüüs

Teostaja analüüsib olemasolevat puidulao funktsionaalsust, mis on realiseeritud MS SQL andmebaasil ning tugineb Microsoft Dynamics AX (Axapta) laomoodulile. Analüüsi käigus:

• kaardistatakse puidulao ärifunktsioonid ja andmeobjektid, millele toetuvad puidu varumine, puidu tarne ja nendega seotud aruandlus;

• tuvastatakse kriitilised sõltuvused teiste süsteemide ja protsessidega; • hinnatakse andmete kvaliteeti, mahtu, ajakohasust ning ajaloolise andmestiku

käsitlemise vajadust.

Väljund: olemasoleva puidulao funktsionaalse ja tehnilise kirjelduse kokkuvõte ning migratsioonimahu hinnang.

2) Uue puidulao platvorm ja funktsionaalsuse realiseerimine

Teostaja kavandab ja realiseerib uue puidulao lahenduse, mis vastab järgmistele koondnõuetele:

• uus puiduladu peab põhinema RMK taristusse sobival platvormil; lubatud on nii kohandatud arendus kui ka valmistoode, seejuures eelistatud on vabavaralised (open source), pilve- ja konteineripõhised lahendused, mis sobituvad Azure’i keskkonda ning toetavad edasist laiendamist;

• lahendus peab katma vähemalt olemasoleva Axapta-põhise puidulao kriitilised ärifunktsioonid, millele toetuvad puidu varumine, puidu tarne ja nendega seotud protsessid;

• puidulao põhi- ja tehinguandmete haldus peab hõlmama puidu koguste, sortimentide, asukohtade ja staatuste arvestust ning tuginema selgele ja dokumenteeritud andmemudelile;

• arhitektuur peab olema modulaarne ja laiendatav ning toetama standardiseeritud liidestusi teiste infosüsteemidega vastavalt I etapis määratletud integratsioonipõhimõtetele;

• lahendus peab olema hooldatav ja skaleeritav ning looma aluse aruandluse ja analüütiliste kasutusjuhtude edasiseks arendamiseks ilma oluliste arhitektuuriliste muudatusteta.

Väljund: valitud ja rakendatud uue puidulao platvorm ning toimiv puidulao moodul.

3) Andmete sünkroniseerimine ja esmased liidestused – nõuded

Teostaja kavandab ja realiseerib vana ja uue puidulao paralleelkasutust toetava integratsioonilahenduse, mis vastab järgmistele koondnõuetele:

• vana (Axapta-põhise) ja uue puidulao vahele tuleb luua eraldiseisev andmete sünkroniseerimise sõlmpunkt, mis võimaldab süsteemide järkjärgulist üleminekut ja selgelt määratletud vastutust andmete vahetamisel;

• sünkroniseerimine peab tagama andmete kooskõla mõlemas süsteemis üleminekuperioodil ning toetama kokkulepitud ulatuses ühe- või kahesuunalist andmevahetust, sh „tõeallika“ (system of record) põhimõtteid;

• uue puidulao komponendiga peab teise etapi raames olema liidestatud vähemalt logistika rakendus.

Väljund: toimiv andmete sünkroniseerimise lahendus ning logistika rakenduse liidestus uue puidulaoga.

3. Juhtimisarvestuse mooduli arendus ja migratsioon

Projekti kolmanda etapi eesmärk on luua metsatööde juhtimise infosüsteemi backoffice-tasandi põhifunktsionaalsused ning töötada välja juhtimisarvestuse mooduli algne versioon, mis loob ühtse ja laiendatava aluse RMK metsamajandamise äriloogikale ning järgnevate etappide funktsionaalsustele. Juhtimisarvestuse mooduli peamisteks kasutajateks on erinevate valdkondade juhid, kelle ülesandeks on teha pikemaajalisi plaane ning kelle vastutuses on lepingute ja hinnaraamistike haldus.

1) Backoffice-funktsionaalsuste detailanalüüs ja kavandamine

Teostaja kaardistab olemasolevad backoffice-funktsionaalsused, mida täna kasutatakse erinevates süsteemides ja protsessides. Analüüsi põhjal kavandab teostaja ühtse ja universaalse backoffice-lahenduse, mis koondab klassifikaatorite, lepingute ja hinnaraamistike halduse ühisesse loogilisse mudelisse. Lahendus peab sisaldama ja olema:

• klassifikaatorite (nt tööliigid, objektitüübid, ühikud, staatused) haldus; • lepingute ja lepinguliste tingimuste haldus; • töövõtjate andmete haldus ja masinate haldus; • varumisülesande haldus; • hinnaraamistike ja hinnastusloogika kasutus; • olema sõltumatu konkreetsetest tööliikidest ja protsessidest; • toetama erinevate ärivaldkondade ja juhtimistasandite vajadusi; • võimaldama konfiguratsioonipõhist laiendamist ja kohandamist ilma lähtekoodi

muutmata;

Analüüsi käigus tuvastatakse kattuvused, süsteemispetsiifilised erisused ning universaalseks lahenduseks sobivad üldised põhimõtted, lähtudes eelkõige juhtimisarvestuse ja planeerimise vajadustest. Lisaks on oluline tuvastada funktsionaalsuste optimeerimise ja protsesside efektiivistamise kohti, mis tagaksid uue lahenduse kõrge kasutajamugavuse. Analüüsi põhjal kavandab teostaja ühtse ja universaalse backoffice-lahenduse, mis koondab klassifikaatorite, lepingute ja hinnaraamistike halduse ühisesse loogilisse mudelisse

Väljund: Nimetatud funktsionaalsused peaksid tekkima juba uude lahendusse osaliselt töötavas vormis. Elav ja täienev analüüsidokument Confluence keskkonnas.

2) Juhtimisarvestuse mooduli realiseerimine

Etapi tulemusena realiseeritakse juhtimisarvestuse mooduli algne versioon, mis

sisaldab kogu funktsionaalsuse ning loob aluse edasiseks arendamiseks.

Juhtimisarvestuse moodul peab toetama eelkõige valdkondade juhtide tööd ning

võimaldama:

• metsatööde üldist ja abstraktset defineerimist, sõltumatult konkreetsetest rakendustest või protsessidest;

• metsatööde seostamist erinevate objektitüüpide, lepingute ja hinnastusmudelitega;

• hinnaraamistike ja lepingutingimuste kasutamist juhtimis- ja planeerimisotsuste tegemisel;

• äriloogika laiendamist ja uute kombinatsioonide loomist konfiguratsiooni kaudu, ilma lähtekoodi muutmata.

Väljund: toimiv juhtimisarvestuse moodul, koos esialgsete testandmetega.

4. Operatiivsete tööde juhtimismooduli arendus

Projekti neljanda etapi eesmärk on luua operatiivne tööde juhtimise moodul, mis toetab metsatööde igapäevast planeerimist, tööülesannete edastamist, täitmise jälgimist ning tööde üleandmist ja vastuvõtmist RMK ja töövõtjate vahel, sh tööde ruumiline planeerimine ja jälgimine kaardil.

1) Olemasolevate lahenduste kasutamine

Mooduli arenduse eelduseks on olemasoleva lahendusega tutvumine, mis tugineb RMK olemasolevale tööde juhtimise süsteemile, selle käigus on võimalik kasutada olemasolevaid andmemudeleid, kasutajaliidese ekraanipilte ning lähtekoodi, et:

• mõista kehtivaid tööprotsesse ja andmestruktuure; • tuvastada korduvkasutatavad lahendusosad; • võimaldada kiiret esmast teostust ning suunata lahendust järk-järgult

universaalse ja laiendatava arhitektuuri poole.

Väljund: eelanalüüsi kokkuvõte ja TO-BE kontseptsioon operatiivse tööde juhtimise moodulile.

2) Tööülesannete edastamine ja täitmise juhtimine

Operatiivne tööde juhtimise moodul peab võimaldama tööülesannete loomist, edastamist ja vastuvõtmist erinevatele osapooltele, sh:

• töövõtjale organisatsiooni tasemel; • konkreetsele tööd tegevale töötajale; • töövõtja masinale (nt harvester, forwarder).

Moodul peab toetama tööülesannete elutsüklit alates töö üleandmisest kuni töö lõpetamise ja vastuvõtmiseni.

Väljund: Moodul välja arendatud.

3) Tööde üleandmine, vastuvõtmine ja vaegtööde menetlemine

Operatiivne tööde juhtimise moodul peab toetama tööde terviklikku elutsüklit alates töö üleandmisest kuni töö vastuvõtmise ja võimalike vaegtööde menetlemiseni. Moodul peab võimaldama:

• tööülesande üleandmist töövõtjale, tööd tegevale töötajale või töövõtja masinale, mille käigus luuakse tööliigipõhine digitaalne dokument („üleandmise akt“), mis fikseerib töö üleandmise tingimused ja lähteandmed;

• töö teostamise staatuse jälgimist ning töö vastuvõtmist RMK poolt, mille käigus luuakse digitaalne „tööde vastuvõtu akt“, mis kajastab vastuvõetud tööde ulatust, koguseid ja kvaliteeti;

• vaegtööde ja puuduste fikseerimist töö vastuvõtmisel, sh märkuste, tähtaegade ja vastutajate määramist;

• vaegtööde menetlemist, sealhulgas paranduste jälgimist, korduvat vastuvõtmist ja vaegtööde sulgemist;

• tööde vastuvõtu akti kasutamist arveldamise alusdokumendina ning vastuvõetud tööde andmete edastamist RMK majandustarkvarasse, tagades auditeeritava ja jälgitava arvestus- ja arveldusprotsessi.

Väljund: Moodul välja arendatud.

4) Metsavarumise ja muude tööliikide tugi

Moodul peab võimaldama lihtsalt ja mugavalt üle anda ja vastu võtta metsavarumisega seotud töid, sh:

• raied harvesteriga; • puidu kokkuvedu forwarderiga.

Lisaks peab moodul toetama ka muude, juhtimisarvestuse moodulis defineeritud tööde üleandmist ja juhtimist, sõltumata töö liigist või kasutatavast tehnikast.

Väljund: Moodul välja arendatud.

5) Kaardikomponent ja ruumiline tööde juhtimine

Operatiivne tööde juhtimise moodul peab sisaldama ühe või mitme kaardikomponendi loomist, mis toetab tööde ruumilist planeerimist ja jälgimist. Metsatööde objektiks võib olla metsaeraldis, metsatee lõik või metsakraavi lõik, mistõttu on tööülesanded valdavalt seotud konkreetsete geograafiliste objektidega. Kaardikomponent peab võimaldama:

• tööde planeerimist kaardil, sh tööobjektide valimist, märgistamist ja seostamist tööülesannetega;

• tööde täitmise ja staatuse jälgimist kaardil; • erinevate tööliikide, olekute ja ajaperioodide visualiseerimist kaardikihtidena; • kasutajale arusaadavat ja jõudlust silmas pidavat kaardivaadet nii kontoris kui

ka välitingimustes kasutamiseks.

Veebikaardi komponent ning kaardikihtide loomine peavad põhinema vabavaralistel (open source) lahendustel ning olema integreeritavad RMK olemasolevate ja tulevaste ruumiandmete allikatega.

Väljund: toimiv operatiivse tööde juhtimise moodul koos rollipõhise tööülesannete halduse, tööde üleandmise ja vastuvõtmise, vaegtööde menetlemise, majandustarkvara integratsiooni ning kaardipõhise tööde planeerimise ja jälgimisega.

5. Töövõtjate rakenduste arendus (mobiilirakendus ja

metsamasina rakendus)

Projekti viienda etapi eesmärk on luua töövõtjatele mõeldud rakendused, mis võimaldavad tööülesannete vastuvõtmist, tööde teostuse raporteerimist ning andmevahetust RMK metsatööde juhtimise infosüsteemiga. Etapi tulemusena valmivad kaks rakenduse tüüpi: universaalne mobiilirakendus ning metsamasina (harvester/forwarder) Windowsi rakendus.

1) Universaalne mobiilirakendus tööülesannete täitmiseks

Luua töövõtjatele universaalne mobiilirakendus (mobiiliplatvormile), mis toetab tööde operatiivset teostamist ja raporteerimist. Rakendus peab võimaldama:

• tööülesannete vastuvõtmist ja kuvamist ning töö oleku muutmist (nt vastu võetud, töös, lõpetatud, esitatud vastuvõtuks);

• tööobjekti ja tööpiirkonna vaatamist kaardil, sh tööga seotud geograafiliste objektide kuvamist (metsaeraldis, metsatee lõik, metsakraavi lõik);

• töö tulemi ja täitmise info raporteerimist (nt kogused, ajad, märkused, lisainfo vastavalt tööliigile), sh vajadusel lisad (nt fotod, kommentaarid) vastavalt RMK poolt määratud vormidele;

• andmevahetust RMK süsteemiga turvalise, auditeeritava ja tõrketaluvana (lähtuvalt I etapis spetsifitseeritud töövõtjate liidestusest).

Väljund: toimiv mobiilirakendus tööülesannete vastuvõtuks, kaardil kuvamiseks ja tulemuste raporteerimiseks.

2) Metsamasinate rakendus

Luua metsamasina rakendus, mis töötab Windowsi operatsioonisüsteemiga seadmes harvesteris ja forwarderis ning toetab standardset andmevahetust StanForD2010 formaadis. Rakendus peab:

• võtma RMK süsteemist sisendina vastu tööülesande StanForD2010 formaadis; • edastama RMK süsteemi tagasi sama standardi kohase toodangu-/tulemifaili

(produkti andmed), kasutades kokkulepitud andmevahetuskanalit; • toetama töö protsessi järjepidevust metsamasina töökeskkonnas (st

tööülesande valik, töö käivitamine/lõpetamine, toodangu faili genereerimine ja edastus);

• tagama andmete tervikluse, korrektse failiversioonide/saadetiste käsitlemise ning veakäsitluse (nt katkise ühenduse korral hilisem uuestisaatmine).

Väljund: toimiv Windowsi metsamasina rakendus harvesteri ja forwarderi töökeskkonda, StanForD2010 sisend- ja väljundfailide toega ning integratsiooniga RMK infosüsteemi.

6. Paralleelsed analüüsid ja arendused

Projekti kuuenda etapi eesmärk on laiendada valdkondlikku skoopi. Riigimetsas on metsakasvatuse- ja ka metsataristu valdkonnal tööde juhtimiseks eraldi tarkvarad. Tänaseks on need tarkvarad vananenud ja vajaksid samuti uuendamist. Metsajuhi loodav tarkvaraplatvorm võimaldaks kasutada nende valdkondadega vahetult seotud ja protsessiliselt sarnaseid komponente ka teiste valdkondade tarkvaralahendusena.

1) Metsakasvatuse ja metsataristu tarkvarade funktsionaalsuste kaardistamine

Eesmärk on analüüsida Riigimetsa metsakasvatuse- ja metsataristu valdkonnas

kasutusel olevate tarkvarade olemasolevaid funktsionaalsusi, töövooge ja

kasutusloogikat, sh koguda sisend kasutajatelt ja sidusrühmadelt. Töö tulemusena

koostatakse struktureeritud ülevaade olemasolevatest funktsioonidest, ärireeglitest ja

kitsaskohtadest.

Väljund: Funktsionaalsuste loend ja tegevusplaan funktsionaalsuste implementeerimiseks uuel universaalsel Metsajuhi platformil.

2) Arhitektuursed eeltingimused laiema skoobi arenduseks

Määratleda tehnilised eeltingimused, mis võimaldavad jooksvalt lisada uude Metsajuhi tarkvarasse metsakasvatuse tööde juhtimise ning metsataristu valdkonna protsesside juhtimise võimekuse. Töö tulemusena koostatakse soovitused moodulipõhiseks ülesehituseks ning võimalikud arendusstsenaariumid edasiseks elluviimiseks.

Väljund: Andmemudelid, modulaarne jaotus ja tehnilise arhitektuuri plaan.

3) Andmete migratsiooni ja tarkvara vahetuse muudatuse juhtimise plaan

Koostada tarkvara vahetusega seotud muudatuste juhtimise tegevusplaan, mis käsitleb kasutajagruppide mõjutamist, kommunikatsiooni, koolituste vajadust, üleminekuperioodi korraldust ning riskide maandamist.

Lisaks tuleb koostada andmete migratsiooniplaan uuele platvormile, mis hõlmab olemasolevate tarkvarade andmete kaardistamist, andmete kvaliteedi hindamist, migratsioonimeetodite kirjeldust ning migratsiooni etappide ja vastutuste määratlemist.

Väljund: Muudatuste juhtimise ja andmete migratsiooni koondplaan.

Loodava lahenduse arhitektuur

Integratsioonid ja andmevahetus

Loodav lahendus töötab integratsioonis teiste RMK süsteemidega (VPT, LOKA, DHS,

BC).

Loodava lahenduse esialgne kontekstidiagramm, mis esitab seosed teiste

süsteemidega:

Seotud tähtsamad infosüsteemid

• VPT (Visuaalse planeerimise töölaud) – pikaajaline raiete planeerimine

arvestuslangi ja pikaaegsete alltöövõtu lepingute alusel.

• LOKA (Looduskaitse tööde planeerimise töölaud)

• DHS (Dokumendi Haldussüsteem) - hoiustatakse RMK dokumente ja

lepinguid. RMK plaanib 2026a jooksul tänase DHSi välja vahetada ning

vana süsteemiga integratsioone teostama ei pea.

• LTL (Logistika Töölaud) – annab väljastatud veoselehtede info Turustuse

Töölauale ning saab vastu lepingud ja nende täitmise info.

• BC (MS Business Central) - RMK finantsinfosüsteem

Kõik integratsioonid tuleb enne nende realiseerimist töö käigus analüüsida ning

vajaduse korral täpsustada ja täiendada. Sisemiste ja väliste süsteemidega seotud

integratsioonid tuleb realiseerida ühise integratsioonimooduli kaudu, tagades

integratsioonide keskse hallatavuse, muudatuste üheselt mõistetava käsitlemise ning

tulevikukindluse sisendite ja väljundite muutumisel ja täiendavate moodulite lisamisel.

Hankedokumentatsiooniga on kaasa pandud eelnevale ärianalüüsile tuginedes

funktsionaalsuste lühikirjeldused, et pakkuja saaks projekti skoobist tunnetuse.

Tehniline arhitektuur

Loodav infosüsteem:

• Peab kasutama SOA (teenusepõhine arhitektuur) tehnoloogilist arhitektuuri;

• Olema täiel määral pilvekõlbulik (RMK kasutab Azure pilveteenuseid);

• Olema horisontaalselt skaleeritav;

• Süsteemi osad peavad töötama olekuta (stateless) põhimõttel;

• Esitluskiht ja back-end asuvad eraldi ning suhtlevad omavahel REST/JSON

protokolliga;

• Autentimine peab olema realiseeritud RMK töötajale läbi Azure Entra ja

töövõtjatele läbi riikliku autentimisteenuse ehk TARA;

• Keskne liidestus sisemiste teenustega;

• Infosüsteem rakendab säilitustähtajapõhist automaatset andmete

kustutamist (data lifecycle management).

• Logide talletamise lahendus, indeks-server tehingutega seotud

otsingulahenduse loomiseks ning ärianalüütika tööriist (nt MS Power BI)

andmetöölaudade loomiseks;

• Infosüsteem peab vastama kaasaegsetele turvastandarditele (OWASP

nõuetele);

• Kõik andmeedastused toimuvad krüpteeritud kanalite kaudu;

• Kasutajaliides peab võimaldama mitmekeelsust;

• Süsteemi kriitilised komponendid peavad olema testitud koormustestide ja

turvatestidega;

• Versioonihaldus - koodi versioonihaldus ning infosüsteemi

versioonimuudatuste korral paigalduspakettide ettevalmistamine;

• WCAG 2.2 AA ligipääsetavuse nõuete täitmine.

PS. Kõik arendusnõuded on toodud lisadokumendis “Arendusnõuded”. Kui pakkuja

näeb, et mõni arendusnõue ei ole asjassepuutuv või ei kohaldu antud süsteemile, siis

ta toob selle tervikkirjelduses välja ning pakub omaltpoolt põhjendatud alternatiivi(d).

Kasutusmugavus ja kasutajaliides

• Intuitiivne kasutajaliides. Pakutava tarkvara kasutajaliides peab olema loogilise

ülesehitusega ja intuitiivselt kasutatav, võimaldades uuel kasutajal teostada

vähemalt järgmised põhitegevused ilma eelneva koolituseta: töö objekti

loomine, töö staatuse muutmine ja andmete vaatamine. Vastavust hinnatakse

tarkvara demonstratsiooni käigus.

• Kohanduv (responsive) kasutajaliides. Tarkvara kasutajaliides peab olema

kohanduv ning võimaldama tarkvara kasutamist vähemalt lauaarvutis ja

nutiseadmes (nutitelefon või tahvelarvuti) ilma funktsionaalsuse kadumiseta.

• Efektiivsed töövood. Tarkvara peab võimaldama peamiste töövoogude (sh

tööde planeerimine, tööde seire ja tööde lõpetamine) läbiviimist loogilise ja

minimaalse sammude arvuga.

• Kiire ja lihtne andmesisestus. Andmete sisestamisel peab tarkvara pakkuma

vähemalt järgmisi funktsioone: vaikimisi väärtused, automaatne täitmine ning

sisestatud andmete loogiline valideerimine.

• Kontekstipõhine abi. Tarkvara peab sisaldama kasutajale kättesaadavat abi,

sealhulgas kontekstipõhiseid abitekste, tööriistavihjeid või kasutusjuhendeid.

Abi peab olema kasutajaliideses kergesti leitav ning seotud vastava

funktsionaalsusega.

Pilvepõhisus ja turvalisus

• Tarkvara peab olema pilvepõhine lahendus, mis tagab kõrge turvalisuse ja

andmete kättesaadavuse;

• Juurutatav tarkvara lokalisatsioon ja tema komponendid peavad olema

paigaldatud Hankija haldusalas olevasse pilveruumi. RMK kasutab Microsoft

Azure pilvekeskkonda.

• Arenduskeskkond on Hankija poolt. Jira/Confluence arendusülesannete

haldamiseks. Azure Devops koodi haldamise ja pideva integratsiooni/juurutuse

(CD/CI) jaoks.

Dokumentatsioon

• Arenduste teostamisel peab Täitja koostama dokumendi(d), millede

eesmärgiks on anda selge ja konkreetne ülevaade süsteemi sisust ja

realiseeritud arendustest.

• Dokumentatsioon luuakse Tellija keskkonda (Confluence) jooksvalt projekti

käigus.

• Dokumenteerimise nõuded on täpsemalt kirjas Arendusnõuded dokumendis.

Testimine

Testimise üldpõhimõtteks on lõppkasutajate minimaalne kaasamine testimisse.

Arendaja vastutab selle eest, et arendusnõuetes sätestatud testimise tasemed ja

põhimõtted oleksid rakendatud ning et testimine oleks võimalikult suures ulatuses

automatiseeritud.

Ideaalis osaleb lõppkasutaja testimises üksnes kasutaja aktsepteerimistestimise

(UAT) raames.

Tugiteenus arendustegevuse jooksul ja peale arenduste tootekeskkonda

paigaldamist

• Raamlepingu täitmise ajal tagab pakkuja tarkvara nõuetekohase toimise, sh intsidentide tekkimise korral reageerima ja probleemi lahendama vastavalt teenustasemetele;

• Pakkuma ülalhoiu teenust peale süsteemi etappide järkjärgulist tootekeskkonda paigaldamist;

• Parandama turvanõrkuseid ja uuendama tarkvara vastavalt lepingus sätestatule;

• Hoidma tehnilist ja lõppkasutaja dokumentatsiooni ajakohasena;

• Nõustama hankijat süsteemis muudatuste tegemisel ja kasutamisel.

Autentimine ja identiteet

Loodavas süsteemis peavad olema toetatud erinevad autentimisviisid vastavalt kasutajatüübile. Süsteem peab eristama kasutajaid ning rakendama neile vastavaid autentimis- ja autoriseerimismehhanisme.

• Ettevõtte (RMK) oma töötajad peavad süsteemi sisenema ettevõtte kasutajakonto abil. Autentimine peab toimuma läbi Azure Entra ID (endine Azure Active Directory) põhise lahenduse.

• Ettevõtte partnerid ja alltöövõtjad peavad süsteemi sisenema läbi riikliku autentimissüsteemi TARA. Süsteem peab toetama TARA kaudu autentimist. Kasutaja identiteedi seost ettevõtte ja rolliga hallatakse juhtimisarvestuse moodulis.

• Masinatega seotud tarkvarade ja süsteemide jaoks peab olema kasutusel eraldi unikaalsete autentimisvõtmete süsteem. Autentimisvõtmed peavad olema seotud juhtimisarvestuse moodulis oleva masinate registriga. Neid võtmeid kasutatakse masin-liideste (machine-to-machine) suhtluseks.

Ootused ajahinnangule

Pakkuja peab andma ajahinnangu, mis toetaks paindlikku arendust, moodulite

paralleelset elluviimist ning pidevat väärtuse loomist. Ajahinnang peab suutma välja

tuua, milline on olulisim MVP (Minimum viable product) stiilis tulem, et infosüsteemi

saaks hakata esimesel võimalusel kasutusele võtma.

Kirjeldus peab vastama alljärgnevatele ootustele:

1. Paindlik ja väärtust loov ajakäsitlus

Pakkuja kirjeldab, kuidas arendus on korraldatud viisil, mis võimaldab tellijal saada

lahendusest sisulist väärtust järk-järgult kogu arenduse vältel. Ajahinnangu käsitlus

peab võimaldama prioriteetide muutmist ja kohandamist arenduse käigus vastavalt

ärilistele vajadustele, vältides jäika ja lineaarset elluviimist.

2. Moodulipõhine ja paralleelne arendus

Kirjeldatud on, kuidas lahendus on jaotatud suuremateks funktsionaalseteks

mooduliteks ning kuidas on tagatud võimalus nende moodulite paralleelseks

detailanalüüsiks ja arendamiseks.

3. Koostöös ja kohanduv ajaplaneerimine

Pakkuja kirjeldab, kuidas ajahinnang kujuneb ja täpsustub koostöös tellijaga

arenduse käigus, sh kuidas tehakse otsuseid prioriteetide, etappide ja

kasutuselevõttude osas.

4. Valmidus üleminekuks uuele süsteemile 2027. aastal

Esitatud ajakava kirjeldus peab arvestama eesmärgiga minna esimesel võimalusel

2027. aasta jooksul üle uuele süsteemile nii looduskaitse kui ka metsavarumise

valdkondades. Sealhulgas puidulao moodul peab olema juurutatud 2026 aasta

lõpuks.

Joonis: RMK nägemus, kuidas mooduleid paralleelselt arendada.

Lisa 2 RMK ja Nortal AS

vahelise lepingu nr 1-18/2026/58 juurde

Arendusnõuded Avalikustamine: RMK sisene teave

Teavet ei ole lubatud jagada kolmandate osapooltega, v.a juhul, kui selleks on õiguslik alus ja/või see on vajalik tööprotsesside toimimiseks.

Avalikustamise lisainfo: “Arendusnõuded (MFN)” lisatakse tarkvara arendamise, hankimise ja juurutamise hangete korral hankedokumentide juurde, v.a dokumendi punktis 2.1 viidatud “RMK Töö- ja koodihaldus” ja punktis 5 viidatud “Logimise spetsifikatsioon”, mis väljastatakse hanelepingu sõlmimise järel ning punktis 2.3 viidatud “Eelistatud tehnoloogiate nimekiri”, mis väljastatakse konfidentsiaalsusleppe (NDA) või hankelepingu sõlmimise järel. Riigihangete portaali hankedokumentide juurde koos “Arendusnõuded (MFN)” dokumendiga neid vaikimisi ei lisata.

Sisukord Arendusnõuded ..................................................................................................................... 1

1. Ülevaade ja skoop .......................................................................................................... 2

2. Üldnõuded ..................................................................................................................... 2

2.1 Töö- ja koodihaldus ................................................................................................... 2

2.2. Operatsioonid, lokaalne käivitamine, CI/CD ja release ............................................... 2

2.3 Platvorm ................................................................................................................... 3

2.4 Koodi kvaliteet ja arendusprotsess ............................................................................. 3

2.5 Dokumenteerimine.................................................................................................... 4

2.6 Haldus ...................................................................................................................... 5

2.7 Välised sõltuvused .................................................................................................... 5

2.8 Muud üldised nõuded ................................................................................................ 5

3. Frontend nõuded (UX/UI) ................................................................................................ 6

3.1 Tehnilised ................................................................................................................. 6

3.2 Kasutuskogemus ....................................................................................................... 6

4. Backend nõuded (API/teenused) ..................................................................................... 7

4.1 Konfiguratsioon ja deploy .......................................................................................... 7

4.2 API disain ja dokumentatsioon ................................................................................... 7

4.3 Töökindlus ja monitooring .......................................................................................... 8

4.4 Koodistruktuur ja arendus .......................................................................................... 8

4.5 Integratsioon ............................................................................................................. 9

5. Logimine ........................................................................................................................ 9

6. Andmebaasi ja andmetöötluse nõuded ........................................................................... 9

6.1 Üldpõhimõtted .......................................................................................................... 9

6.2 Identifikaatorid ja audit .............................................................................................. 9

6.3 Platvorm ja tööriistad .............................................................................................. 10

6.4 Turvalisus ja juurdepääs .......................................................................................... 10

7. Turvanõuded ................................................................................................................ 10

7.1 Üldised põhimõtted ................................................................................................. 10

7.2 Sessioonid .............................................................................................................. 11

7.3 Lähtekood ja arendusvahendid ................................................................................ 11

9. Hooldatavus ja toetatavus ............................................................................................ 11

1. Ülevaade ja skoop Käesolev dokument kirjeldab kuidas RMK-s arendatakse, hangitakse ja juurutatakse tarkvara. See hõlmab nii tarkvara arendust kui ka karbitoodete ja SaaS (Software as a Service) teenuste kasutusele võttu. Nõuded ei kirjelda ärifunktsionaalsust.

Dokumendis viidatakse ka teistele välistele dokumentidele, mis moodustavad käesoleva dokumendiga ühtse terviku.

2. Üldnõuded

2.1 Töö- ja koodihaldus • Kõik tööd peavad olema kirjeldatud piletina RMK JIRA-s. Täpsemad JIRA ja

versioonihalduse kasutamise nõuded on kirjeldatud dokumendis „RMK Töö- ja koodihaldus“(välisele arenduspartnerile väljastatakse dokument peale hankelepingu sõlmimist).

• Git repod: RMK kood asub Azure DevOps repodes.

2.2. Operatsioonid, lokaalne käivitamine, CI/CD ja release • Lokaalne käivitus: Rakendused peavad olema lokaalselt käivitatavad ilma väliste

sõltuvusteta. Vajalikud sõltuvused peaksid olema lokaalselt käivitatavad Docker Compose-i konteineriga. Välised sõltuvused(API-d) võivad olla mockitud. Rakenduse käivitamiseks ja testimiseks vajalikud andmed peavad olema rakenduses seadistatud.

Peale käivitamist peab olema rakendus kasutatav. Rakenduse Vajalikud käsud ja sammud rakenduse lokaalseks käivitamiseks peavad olema välja toodud koodi repos README.md failis.

• Koodi formaadi kontroll: koodi formaadi kontroll peab olema build protsessi osa. Kood peab vastama RMK-s kokku lepitud formaadile.

• Staatiline analüüs: staatiline analüüs(nt Sonar) peab olema build protsessi osa selliselt, et kui kvaliteedi lävendit ei ületata, siis build ei õnnestu. Uus kood ei tohi tekitada juurde Sonari vigu. Lokaalselt seda sammu ei ole(võimalusel kasutada Sonarit IDE pluginana, või minna eraldi Sonari liidesesse ja kontrollida vigasid).

• Testimise üldnõuded: vt peatükk 9.

• Release strateegiad: kasutusel võivad olla erinevad väljalaskmise mustrid (nt blue- green, canary). Tähtis on, et uue versiooni kasutuselevõtt oleks kontrollitud ja võimaldaks vajadusel kiiret tagasipööramist.

• Production ressursivajadus: arendusmeeskonna ülesanne on testida rakenduse jõudlust ja selle põhjal teha ettepanek rakenduse ressursivajaduse kohta production keskkonnas, mis on sisendiks haldusosakonnale.

2.3 Platvorm • Versioon: Ükskõik mis programmeerimiskeelte, raamistike või teekidega infosüsteeme

realiseeritakse, kehtib sama põhimõte: alati kasutatakse kas viimast LTS(Long Term Support) versiooni, või selle puudumisel viimast stabiilset versiooni. Kui arendustöö käigus tuleb uus LTS versioon välja, siis see uuendatakse kohe ära, kui ei esine seda takistavaid asjaolusid.

• Eelistatud tehnoloogiate nimekiri: Nimekiri programmeerimiskeeltest, raamistikest, teekidest ja nende versioonidest, mida võib ilma täiendava kooskõlastamiseta kasutada on kirjeldatud dokumendis „Eelistatud tehnoloogiate nimekiri“(välisele arenduspartnerile väljastatakse dokument riigihanke käigus NDA alusel või peale hankelepingu sõlmimist). Juhul kui on soov kasutada midagi muud, siis tuleb see valik kooskõlastada RMK tarkvaraarhitektiga.

• Keskkond: backend, frontend ja andmebaasid töötavad Azure pilvekeskkonnas.

• CI/CD: kasutatakse Azure CI/CD. Build protsessi osana käivitatakse koodi formaadi kontroll, staatiline analüüs, testid.

• Sõltuvused: kasutatakse ainult toetatud ja turvauuendusi saavaid teeke.

• Skaleeruvus: rakenduste arendamisel peab arvestama võimalusega, et need jooksevad mitme õla peal.

• Docker: rakendus peab olema tarnitav Dockeri konteineritena.

2.4 Koodi kvaliteet ja arendusprotsess • Põhiharu kvaliteet: main haru peab alati olema testitud ja valmis production

keskkonda paigaldamiseks.

• Sisendi valideerimine: kõik kasutajalt või teistest süsteemidest tulevad sisendid valideeritakse. Kui rakendusel on nii kliendi- kui serveripool, toimub valideerimine mõlemas komponendis. Samuti rakendatakse valideerimist teistes integratsioonipunktides(andmebaas, välised liidesed).

• Väljundandmete kontroll: Rakenduse poolt kasutajale või teisele süsteemile väljastatavad andmed peavad olema õigesti vormindatud, äriliselt korrektsed ja turvalised.

o Formaadi kontroll: kõik väljastatavad väärtused vastavad kokkulepitud skeemile või standardile. Näiteks kuupäevad esitatakse ISO 8601 formaadis (2025-09-02T12:00:00Z), rahasummad kahe komakohaga, ning API vastus vastab OpenAPI kirjeldatud struktuurile.

o Äriline korrektsus: väljastatav info järgib ärireegleid ja loogikat. Näiteks ei väljastata negatiivset saldo väärtust, kui süsteemi reeglid seda ei luba; ID viitab alati reaalselt olemasolevale kirjetele; staatuse väljad sisaldavad ainult eeldefineeritud väärtusi.

o Turvalisus: väljund ei tohi sisaldada tundlikke või sisemisi andmeid, mida kasutaja või partner ei pea nägema (nt paroole, võtmeid, sisemisi tehnilisi tunnuseid). Tekstid peavad olema korrektselt escape’itud, et vältida XSS või sarnaseid ründeid. Logidesse ei tohi sattuda täielikud isikuandmed ega salajased identifikaatorid.

• Staatiline koodianalüüs: kasutatakse staatilist koodianalüüsi(Sonar); kõrge prioriteediga turvavead tuleb lahendada enne live keskkonda paigaldamist. Kõik Sonari vead vaadatakse enne arenduse üleandmist üle, vead mida ei peeta otstarbekaks parandada kooskõlastatakse RMK tarkvaraarhitektiga.

• Kompilaatori hoiatused: build-i hoiatused ja staatilise analüüsi tulemused vaadatakse üle ja arvestatakse.

• Kiirlahenduste vältimine: ei kasutata testimata lahendusi, mis eiravad häid praktikaid või RMK nõudeid.

• Testimise põhimõtted: vt peatükk 9.

2.5 Dokumenteerimine • Dokumentatsiooni põhielemendid:

o süsteemi funktsionaalne ja tehniline kirjeldus,

o kasutatavad liidesed (API-d, integratsioonid),

o perioodilised tööd (schedulerid, batch-protsessid),

o arenduskeskkonna seadistamine

o andmebaasi struktuuri kirjeldus (tabelid, seosed, migratsioonid),

o keskkonnad ja paigaldus

o peamised hooldustegevused (nt logide ülevaatus, varunduse kontroll, sõltuvuste uuendamise tsükkel)

• Dokumentatsiooni asukoht: RMK Confluence keskkond

• Diagrammid: süsteemi arhitektuuri ja komponente visualiseeritakse eelistatult PlantUML või Mermaid formaadis.

• Arhitektuur: iga süsteemi kohta peab olema arhitektuuriülevaade, sealhulgas API spetsifikatsioonid (nt OpenAPI).

2.6 Haldus • Tehniline võlg: arenduse käigus tuleb dokumenteerida teadaolevad piirangud ja

tehniline võlg (nt TODO-d, ajutised lahendused) ning soovitused nende likvideerimiseks.

• Sõltuvuste ja platvormi uuendused: arenduse käigus tuleb kirjeldada süsteemi kaasaegsena hoidmise strateegiat (nt milliseid raamistikke ja teeke tuleb regulaarselt uuendada, millal tuleb planeerida üleminek LTS-versioonidele).

• Monitooringu vajadused: tarnija peab kirjeldama arendatava süsteemi monitooringu aspektid (nt vealogid, jõudlusmõõdikud, integratsioonide toimivus, job scheduler-i töö).

• Teavitused: tarnija peab defineerima soovitatud häirete künnised (nt kui API annab vea, kui mingi protsess ei lõpeta näiteks 15 minutiga).

• Elutsükli planeerimine: tarnija peab andma hinnangu, millised tehnoloogiad või komponendid võivad lähiaastatel vajada moderniseerimist või väljavahetamist.

• Andmete säilitustähtajad: kui süsteemis talletatakse andmeid, millel on määratud säilitustähtaja (vastavalt teabe liigitusskeemile Jira Assetis), tuleb see dokumenteerida. Dokumentatsioonis peab olema kirjeldatud, millised andmed kustutatakse automaatselt, millal ja kuidas.

2.7 Välised sõltuvused • Teekide kasutamine: kasutada ainult laialdaselt toetatud ja turvauuendusi saavaid

teeke.

• Sõltuvuste miinimum: sõltuvusi hoitakse minimaalsena, et vähendada turvariske ja halduskoormust.

• Litsentsid: sõltuvuste litsentsitingimusi, turvalisust ja ajalugu hinnatakse; eelistatakse vabavaralisi komponente.

• Jätkusuutlikkus: hinnatakse teekide jätkuarenduse ja toe kättesaadavust. Vajadusel analüüsitakse mõju RMK protsessidele, kui komponendi arendus lõpeb.

• Ühilduvus: analüüsitakse kasutatavate komponentide ühilduvust teiste süsteemidega.

2.8 Muud üldised nõuded • Kodeering ja locale: kogu süsteemis (lähtekoodis, andmebaasis, jne) kasutatakse UTF-

8 kodeeringut; vaikekeel on et-EE (laiendatav i18n); ajatsoon on UTC (UI-s kohalik aeg).

3. Frontend nõuded (UX/UI)

3.1 Tehnilised • Tehnoloogia: kui rakenduse nõuded võimaldavad siis eelistame serveris renderdatud

HTML-i (Thymeleaf, HTMX).

• Raamistikud: kui kasutatakse mingit raamistikku, siis eelistame laialdaselt toetatud raamistikku (nt React, Angular või Vue).

• Raamistiku versioon: projektis kasutatavad raamistikud peavad olema toetatud ja saama turvauuendusi.

• Build: sõltuvused hallatakse paketihalduriga, arvestades kasutatavat tehnilist lahendust:

o SPA: npm / yarn / pnpm (lock fail versioonihalduses; build deterministlik).

o Java SSR (Server-Side Rendering nt Thymeleaf): Gradle (või Maven) hoiab nii backendi kui frontendi build-i .

o PHP SSR: Composer.

o Python SSR: pip. Build peab olema deterministlik ja versioonitav (lock failid, build-config git-s).

• Keskkonnaspetsiifilised seaded: hoitakse välises konfiguratsioonis (nt .env).

• API kasutus: kõik API-päringud käivad läbi konfiguratsiooni alusel määratud lõpp- punktide; otselinke koodis ei kasutata.

• Turvalisus: tundlikke andmeid ei salvestata brauseri püsivasse vahemällu (LocalStorage, SessionStorage) ilma krüpteerimiseta.

• Jõudlus: rakendus peab laadima mõistliku aja jooksul – esmase laadimise vaikimisi nõue on 2s. Täpsem kontekst (nt mõõdik, tüüpiline seade ja võrguolud) lepitakse projekti alguses kokku ja fikseeritakse rakenduse/projekti dokumentatsioonis. Pildid, skriptid ja stiilid peavad olema optimeeritud (lazy load, cache, minify).

• Telemeetria: kriitilised kliendipoolsed vead (JavaScript errorid, katkised API päringud) peavad jõudma tsentraalsesse monitooringusse.

3.2 Kasutuskogemus • Reageeriv(responsive) disain: rakendus peab olema kasutatav erineva

ekraanisuurusega seadmetel (desktop, mobiil, tahvel).

• Navigatsioon: menüüd ja liikumisloogika on rakenduse eri vaadetes ühtsed. Sama funktsionaalsus on alati leitav samast kohast.

• Nuppude paigutus ja järjestus: sama tüüpi tegevused (nt “Salvesta”, “Tühista”) paiknevad alati samas järjekorras ja paigutusega.

• Veateated: esitatakse ühtses formaadis (struktuur, sõnastus, värvilahendus). Teated on arusaadavad ja ei sisalda tehnilist müra. Veateated ei sulgu automaatselt, et kasutajal oleks võimalik neid adekvaatselt edastada toe saamiseks.

• Kinnitused ja dialoogid: riskantsete tegevuste (nt kustutamine, lõplik kinnitamine) puhul küsitakse alati kinnitust. Dialoogid järgivad sama stiili ja loogikat.

• Abitekstid ja juhendid: tooltipid, sisestusväljade placeholderid ja abitekstid on stiililt ja positsioonilt ühtsed. Kõik väljad ja tegevused on varustatud abitekstiga, mis aitab kasutajal mõista, mis juhtub enne kui ta midagi teeb.

• Laadimise tagasiside: pikemate tegevuste puhul (nt päring serverisse, faili üleslaadimine) peab kasutaja nägema visuaalset indikaatorit (spinner, progress bar).

• Etteaimatavus: süsteemi käitumine peab olema selge ja ootuspärane – väldime olukorda kus kasutaja peab mõtlema „mis siis juhtub, kui ma siia vajutan“. Tegevuste tagajärjed on nähtavad või selgitatud enne sooritamist.

• Ikonograafia ja sümbolid: sama tegevuse tähistamiseks kasutatakse alati sama ikooni ja tähendust.

• Stiil ja kujundus: värvipalett, kirjatüübid ja komponentide kujundus vastavad ühtsele disainisüsteemile või stiilijuhendile.

• Klahvikombinatsioonid ja kiirtoimingud (kui rakendatud): töötavad järjepidevalt kõigis vaadetes.

• Terminoloogia: tekstid ja nimetused (nt “kasutaja”, “konto”, “fail”) on järjepidevalt samad kogu rakenduses.

• Andmete sisestuse valideerimine: sisestusväljade puhul kasutatakse valideerimist enne serverisse saatmist, et ilmseid vigu kasutajale kiiremini esile tuua.

4. Backend nõuded (API/teenused)

4.1 Konfiguratsioon ja deploy • Seadistused: keskkonnaspetsiifilised väärtused hoitakse rakendusest väljas (Azure

Key Vault, keskkonnamuutujad), aga konfiguratsioon ise on koodi juures vastavates failides.

• Konfiguratsioon: konfiguratsioon on versioneeritav ja muudatused jälgitavad.

• Ehitamine: Java projektide ehitamisel eelistatakse Gradle-t.

4.2 API disain ja dokumentatsioon • Versioonimine: REST/HTTP liidesed on versioonitud (nt /v1). • Dokumentatsioon: kõik REST/HTTP liidesed peavad olema dokumenteeritud nii, et

partneritel ja RMK-l on võimalik neid kasutada ja testida. Dokumentatsiooni võib teha erineval viisil (nt kirjalik juhend, Postman collection, README näidised). Soovitatavalt kasutatakse masinloetavat standardit OpenAPI ja sellest genereeritud Swagger liidest.

• Asukoht: kui kasutatakse OpenAPI/AsyncAPI dokumentatsiooni, peab vastav fail asuma samas Git repo-s koos lähtekoodiga, et see oleks alati koodiga kooskõlas.

• Koormuse juhtimine: kasutatakse mehhanisme ülekoormuse vältimiseks (nt rate limiting, throttling).

• Veakäsitlus: veateated on standardiseeritud, inimloetavad ja ei sisalda tundlikku sisemist infot.

• Sisend, väljund: API sisend ja väljund peab jälgima REST põhimõtteid (https://restfulapi.net/).

• Protokoll, formaat: kasutatakse HTTP protokolli ja API väljund on JSON, välja arvatud binaarfailide puhul.

4.3 Töökindlus ja monitooring • Health-checkid: rakendus peab pakkuma health-check ja readiness liideseid(Spring

Boot Actuator).

• Observability: rakendused edastavad minimaalselt request count, response time, error rate mõõdikuid Azure Monitori(Micrometer)

• API töökindlus: API peab olema kasutatav (vastab päringutele) ja enamus päringuid peab lõppema mõistliku aja jooksul ning ilma veata. Täpsemad jõudluse või töökindluse eesmärgid määratakse projektipõhiselt.

• Testimine: Integratsiooniteste ja end-to-end teste võib kirjutada. Nende puudumisel tuleb enne release-i teha regressioonitestimist käsitsi.

4.4 Koodistruktuur ja arendus • Struktuur: Java projektides kasutatakse kihipõhist package struktuuri, kus

komponendid on jaotatud package-tesse tehnilise rolli järgi (nt controllers, services, repositories).

• Perioodilised tööd: kõik schedulerid, batchid ja stored procedures dokumenteeritakse README-s. Perioodiliste tööde käivitamine eraldi klassis äriloogikast.

• Automaatne andmete kustutamine: kui süsteemis on andmeid, millel on määratud säilitustähtaja (vastavalt teabe liigitusskeemile), tuleb rakendada automaatne kustutamise funktsionaalsus. Automaatne kustutamine toimub perioodilise tööna (scheduler, batch), mis kontrollib andmete vanust ja kustutab andmeid, mis on ületanud säilitustähtaja. Kustutamise protsess peab olema logitud.

• Teenusklassid: äriloogika peab olema realiseeritud Service kihis, mille sisendiks ja väljundiks on domeeniobjektid. Teenuseklassi testideks on unit testid.

• Kontrollerid: Kontrollerite testid tuleb kirjutada kasutades MockMvc raamistikku, kus teenuste kihi vastused on mockitud.

• Presentatsioonikiht: presentatsioonikiht ei tohi kasutada sisendiks ja väljundiks domeeniobjekte, vaid eraldi Request ja Response ressursse.

• Autoriseerimine: päringute autoriseerimine peab toimuma kontrolleritekihis. • Testimine: koodi unit testide haru-kattuvus(branch coverage) peab olema 80%. Unit

testid tuleb jooksutada CI/CD süsteemis iga buildiga uuesti. Build peab katki minema, kui testid pole edukad. Repository (ja messaging) kihi testid tuleb kirjutada integratsioonitestidena vastu mockitud (nt rest apid) või konteineris jooksva päris välise süsteemi vastu (näiteks rakenduse Postgres baas TestContainers abil). Iga test hoolitseb ise oma testandmete loomise ja esialgse seisu taastamise eest. Erinevates testides samade andmete kasutamine ei ole lubatud.

• Koodistandard: vaikimisi kasutatakse Google Java koodistandardit, mille kontrollimine on osa buildist.

4.5 Integratsioon • Andmebaasid, välised liidesed: andmebaasi ja teiste väliste andmete küsimine peab

olema lahendatud eraldi repository kihis, mis väljastab äriloogika kihile ainult domeeniobjekte.

• Sõnumid, eventid: eventide saatmine ja vastuvõtmine peab olema realiseeritud äriloogikast eraldi consumerites ja producerites.

5. Logimine Logimisnõuded on kirjeldatud dokumendis „Logimise spetsifikatsioon“.

• NB! Välisele arenduspartnerile väljastatakse “Logimise spetsifikatsioon” dokument peale hankelepingu sõlmimist.

6. Andmebaasi ja andmetöötluse nõuded

6.1 Üldpõhimõtted • Andmete terviklikkus: kõik andmebaasi struktuurid (tabelid, seosed, indeksid) peavad

tagama andmete terviklikkuse ja vältima duplikaate või orvuks jäänud kirjeid.

• Normaliseeritus: andmemudel peab olema vähemalt 3. normaalkujus või põhjendatult denormaliseeritud (näiteks jõudluse kaalutlustel).

• Järjepidevus: andmete formaat ja tähistus (nt kuupäevad, valuutad, staatuse väljad) peab olema ühtne kogu süsteemis.

• Äriloogika: relatsioonilisse baasi tuleb suhtuda kui andmete hoidlasse, äriloogika peab olema implementeeritud rakenduskihis. Storedprocedure kasutamine ei ole lubatud.

6.2 Identifikaatorid ja audit • Primaarvõtmed: numbrilised ID-d on eelistatud, mitte UUID, välja arvatud kui on

tehniline vajadus globaalseks unikaalsuseks.

• Auditväljad: igas tabelis, kus toimub andmete muutmine, peavad olema väljad created_by, created_at, modified_by, modified_at. Ajatemplid (created_at, modified_at) on vajalikud ka andmete automaatseks kustutamiseks vanuse järgi.

• Kustutuse logimine: kõik andmete kustutamise operatsioonid (nii automaatsed kui käsitsi) peavad olema logitud koos kustutatud andmete tüübi, kustutamise ajaga, põhjuseks ja tegijaga (süsteem või kasutaja).

• Auditlogi või event sourcing: kasutatakse sõltuvalt süsteemi iseloomust ja ärivajadusest.

6.3 Platvorm ja tööriistad • Andmebaasi tarkvara: RMK eelistatud andmebaas on PostgreSQL. Arenduse ja

testimise eesmärgil võib kasutada ka mäluandmebaase (nt H2, SQLite3).

• Migratsioonid: kõik struktuurimuudatused hallatakse migratsioonitööriistadega ja versioonihalduses (soovitatavalt Flyway). Käsitsi tehtud muudatused ei ole lubatud, välja arvatud erandkorras ja RMK-ga eelnevalt kooskõlastatult. Kõik sellised muudatused tuleb dokumenteerida ja kanda tagasi migratsiooniskriptidesse, et tagada keskkondade ühtsus.

6.4 Turvalisus ja juurdepääs • Paroolid ja autentimisandmed: salvestatakse ainult soolatud räsi kujul (nt Argon2,

bcrypt, scrypt). Lihttekstina talletamine on keelatud.

• Õiguste haldus: andmebaasis kasutatakse eraldi kontosid rakenduse ja haldustööde jaoks (väikseima privileegi põhimõte).

7. Turvanõuded

7.1 Üldised põhimõtted • Autentimine ja identiteet: rakendused ja kasutajad tuvastavad end RMK

autentimisnõuete alusel (Entra ID, TARA väliskasutajatele).

• Autoriseerimine: juurdepääs rakendustes toimub rollipõhiselt. Rollide nimetusvorming: APP-{env}-{teenus}-{roll}.

• Andmete liigitus: rakenduse planeerimisel määratakse andmete tüüp ja liigitus, dokumenteeritakse nende käsitlemise alused. Säilitustähtajad määratakse vastavalt teabe liigitusskeemile Jira Assetis ja andmesäilituse teemapoliitikale.

• Turvaline arendus: rakenduse arendamisel järgitakse RMK dokumente Arenduse elutsükkel ja Turvaline arhitektuur.

• Andmekaitse: mitteavalikud andmed kaitstakse vastavalt teabe liigitusskeemile ja andmekaitse nõuetele. Töötlemisel järgitakse kehtivaid andmekaitse õigusakte, sh GDPR.

• Andmevahetus: kogu andmevahetus on krüpteeritud (TLS 1.2+); kasutatakse RMK krüptograafia juhendis määratud protokolle ja vorminguid.

• Auditväljad ja -logi: rakendustes logitakse, millal ja kes kirje lõi ning viimati muutis (audit trail).

• Saladuste haldus: kõik võtmed ja paroolid hoitakse Azure Key Vault-s, mitte lähtekoodis või konfiguratsioonifailides.

• Keskkondade eraldatus: live keskkond peab olema rangelt eraldatud arendus- ja testkeskkondadest. Toodanguandmeid ei tohi kasutada arendus- ega testkeskkondades.

• Vajaduspõhine ligipääs: kõik ligipääsud lähtuvad vajaduspõhimõttest (default deny).

• Vähima privileegi põhimõte: kõik protsessid töötavad vähimate vajalike õigustega.

• Autentimise integreerimine: kasutajate õiguseid arvestatakse läbivalt igal tasemel (UI, äriloogika, andmebaas, integratsioonid).

7.2 Sessioonid • Timeout: serveripoolne sessiooni idle timeout ≤ 30 minutit, absoluutne timeout ≤ 12

tundi.

• Sessiooni turvalisus: sessiooni ID logitakse vajadusel maskitult või räsitult.

• Sessiooni lõpetamine: sessioon suletakse automaatselt, kui kasutaja logib välja või jõuab timeout.

7.3 Lähtekood ja arendusvahendid • Ligipääs: lähtekood asub RMK Azure DevOps keskkonnas, kus ligipääsu hallatakse

projekti põhiselt.

o RMK arendajatele antakse ligipääs vajaduspõhiselt töölepingu kehtivuse ajal.

o RMK töötajatele antakse ligipääs ainult vajaduse korral ja vaikimisi lugemisõigus.

o Välistele arendajatele antakse projektipõhine ligipääs, mis eemaldatakse projekti lõppedes.

• Lähtekoodi turvalisus: tuleb vältida lubamatute funktsioonide lisamist ja tagada, et lähtekood, arendusvahendid ja teegid on kaitstud tahtmatute või pahatahtlike muudatuste eest.

• Koodi kvaliteet: turvavigade automaatne analüüs (nt Sonar).

8. Hooldatavus ja toetatavus • Koodistandardid: rakenduse kood peab olema ühtses stiilis, loetav ja järgitav, et ka uus

arendaja saaks töö kiiresti üle võtta.

• Juhendite praktilisus: dokumentatsioon peab olema piisavalt selge, et uuel arendajal või administraatoril oleks võimalik süsteem kiiresti üle võtta.

• Testid: rakenduse põhitöövood peavad olema kaetud automaatsete testidega. See võimaldab veenduda, et süsteemi põhifunktsioonid töötavad ka pärast muudatusi. Täpsemalt vt peatükk 9.

• Runbook-d (käitamis- ja taastamisjuhendid): kriitiliste töövoogude ja häireolukordade jaoks peab olema lühike samm-sammuline juhend, mis kirjeldab, kuidas probleem lahendada või süsteem taastada.

• Tugi ja eskaleerimine: peab olema selge, kes ja kuidas reageerib süsteemi tõrgetele ning millised on reageerimisajad erineva tõsidusega olukordades.

9. Testimine • CI/CD ja build: unit- ja integratsioonitestid peavad jooksma igal ehitusel. Build peab

ebaõnnestuma, kui testid ei ole edukad.

• Peaharu: main haru peab alati olema testitud ja valmis productionkeskkonda paigaldamiseks.

• Testide kattuvus: unit testide haru-kattuvus (branch coverage) peab vaikimisi olema 80%. Projekti- või hankepõhisel kokkuleppel võib tase olla madalam ning erand tuleb fikseerida kirjalikult.

• Testide liigid ja kasutus:

o Unit testid: puhta loogika testimiseks, kus on konkeete sisend ja väljund. Unit testid ei sobi testideks, mille osaks on I/O, võrguga seotud funktsionaalsus või aeg.

o Integratsioonitestid: katavad liideseid ja sõltuvusi(andmebaas, failisüsteem, MQ, REST liidesed jne)

o End-to-end testid: katavad kasutaja töövooge (nt Playwright); vaikimisi katame E2E testidega ainult põhitöövood.

• Testandmed: iga test loob ise testandmed ja vajadusel taastab esialgse seisu; erinevates testides samu testandmeid kasutada ei tohi.

• Integreerimis- ja E2E testid: kui neid ei ole, tuleb enne release'i teha regressioonitestimine käsitsi.

• Testkeskkonnad ja -andmed: testimise käigus ei tohi kasutada toodanguandmeid arendus- ega testkeskkondades (vt 7.1).

• Turva- ja jõudlustestid: tehakse projekti ja vajaduspõhiselt.

Lisa 3

RMK ja Nortal AS

vahelise lepingu nr

1-18/2026/58 juurde

ISIKUANDMETE TÖÖTLEMISE NÕUDED VOLITATUD TÖÖTLEJALE

1. Üldine

1.1. Riigimetsa Majandamise Keskus (RMK) (edaspidi vastutav töötleja) edastab Nortal

AS (edaspidi volitatud töötleja) punktis 2.1 nimetatud andmed ja volitab volitatud

töötlejat neid andmeid töötlema ainult juhul, kui andmete töötlemine on lepingust

tulenevalt vajalik.

1.2. Käesoleva lisa eesmärk on kokku leppida volitatud töötleja õigustes ja kohustuses

lepingu täitmise käigus saadud isikuandmete töötlemisel, millest pooled juhinduvad

lepingu täitmisel.

1.3. Vastuolude korral lepingu ja käesoleva lisa sätete vahel tuleb juhinduda käesoleva lisa

sätetest.

2. Isikuandmete töötlemise eesmärk ja kirjeldus

2.1. Vastutav töötleja kirjeldab ära isikuandmete töötlustoimingud tabelis 1, milles

sätestatakse:

2.1.1. andmete töötlemise eesmärgi/eesmärgid, milleks isikuandmeid vastutava

töötleja nimel töödeldakse;

2.1.2. andmesubjektide kategooriad, kelle isikuandmeid töödeldakse;

2.1.3. töödeldavate andmete liigid;

2.1.4. töötlemise alused;

2.1.5. andmete säilitustähtajad.

Töötlemise

eesmärk

Andmesubjektide

kategooriad Andmete liigid

Töötlemise

alused Säilitustähtajad

Metsatööde

juhtimise tarkvara

platvormi

Metsajuht kaudu

RMK töötajate

isikuandmed;

Isikut tuvastavad

andmed;

Kontaktandmed;

GDPR art

6(1)(e) ja GDPR

art 6(1)(b) -

avalikes huvides

Volitatud

töötleja säilitab

andmeid ainult

lepingu

kogu tööde ahela

juhtimine alates

metsatööde

planeerimisest

kuni raiete

teostamiseni, nii

RMK kui väliste

partnerite poolt

Väliste partnerite

isikuandmed

Kasutajakontode

andmed;

Volituste andmed;

Lepingute

andmed;

Asukoha andmed.

oleva ülesande

täitmine ja

lepingu täitmine

GDPR art 28 -

volitatud

töötleja töötleb

andmeid

vastutava

töötleja

dokumenteeritud

juhiste alusel.

täitmiseks

vajaliku aja

jooksul ning

seejärel andmed

kustutatakse,

välja arvatud

juhul, kui

säilitamine on

vajalik

õigusnõuete

täitmiseks või

vaidluste

lahendamiseks.

Infosüsteemi

turvalisuse ja

töökindluse

tagamine.

RMK töötajate

isikuandmed;

Väliste partnerite

isikuandmed

Tehnilised ja

turbeandmed, sh

autentimisandmed,

logid, intsidentide

andmed,

varundamise ja

taastamisega

seotud andmed.

GDPR art

6(1)(c) ja GDPR

art 6(1)(f) -

juriidilise

kohustuse

täitmine ja

vastutava

töötleja

õigustatud huvi

GDPR art 28 -

volitatud

töötleja töötleb

andmeid

vastutava

töötleja

dokumenteeritud

juhiste alusel.

Volitatud

töötleja säilitab

andmeid ainult

lepingu

täitmiseks

vajaliku aja

jooksul ning

seejärel andmed

kustutatakse,

välja arvatud

juhul, kui

säilitamine on

vajalik

õigusnõuete

täitmiseks või

vaidluste

lahendamiseks.

Tabel 1. Isikuandmete töötlustoimingute tabel

3. Isikuandmete töötlemise kestus ja säilitamise nõuded

3.1. Volitatud töötleja töötleb isikuandmeid üksnes minimaalses vajalikus mahus ja lepingus

kindlaksmääratud aja jooksul, välja arvatud juhul, kui volitatud töötleja on kohustatud

teavet töötlema volitatud töötleja suhtes kohalduva seaduse alusel.

3.2. Käesoleva lisa raames tuleb andmeid säilitada vastavalt tabelis 1 sätestatud ajale. Selle

aja möödudes tuleb andmed volitatud töötleja süsteemidest kustutada.

3.3. Peale teenuslepingu lõppemist tuleb vastutava töötleja teave volitatud töötleja

hallatavatest süsteemidest turvaliselt kustutada, küsides enne selleks vastutavalt

töötlejalt kirjaliku kinnituse. Kinnituse küsimisel tuleb kirjeldada plaanitav turvalise

kustutuse meetod.

4. Nõuded volitatud töötlejale

4.1. Volitatud töötleja on kohustatud kasutama ja töötlema tabelis 1 olevaid andmeid üksnes

lepingu täitmiseks ja vastutava töötleja dokumenteeritud juhiste alusel, välja arvatud

juhul, kui volitatud töötleja on kohustatud teavet töötlema volitatud töötleja suhtes

kohalduva õiguse alusel. Viimati nimetatud juhul teavitab volitatud töötleja vastutavat

töötlejat vastava kohustuse olemasolust enne teabe töötlemist, kui selline teavitamine ei

ole olulise avaliku huvi tõttu volitatud töötleja suhtes kohalduva õigusega keelatud.

4.2. Volitatud töötleja peab täitma kõiki kehtivaid andmete töötlemisalaseid nõudeid,

andmete turvalisust puudutavaid ning andmete kaitse alaseid Euroopa Liidu ja Eesti

Vabariigi õigusakte ja muid eeskirju.

4.3. Volitatud töötleja on kohustatud aitama vastutavat töötlejat järgmiste nõuete täitmise

tagamisel, võttes arvesse andmetöötluse laadi ja volitatud töötlejale kättesaadavat

teavet:

4.3.1. kohustus hinnata kavandatavate töötlemistoimingute mõju isikuandmete kaitsele

(edaspidi „andmekaitsealane mõjuhinnang“), kui teatava töötlemisviisiga

kaasneb tõenäoliselt suur oht füüsiliste isikute õigustele ja vabadustele;

4.3.2. kohustus tagada isikuandmete õigsus ja ajakohasus, teavitades vastutavat

töötlejat viivitamata, kui volitatud töötleja saab teada, et tema töödeldavad

isikuandmed on ebaõiged või aegunud;

4.3.3. kohustus teavitada vastutavat töötlejat kohe, kui vastutava töötleja nõuded ja

juhised lähevad volitatud töötleja arvates vastuollu isikuandmete kaitse

üldmäärusega või kohaldatavate liidu või liikmesriigi andmekaitsealaste

sätetega.

5. Alamtöötleja kaasamine

5.1. Volitatud töötleja ei telli käesolevate nõuete kohaselt vastutava töötleja nimel tehtavate

töötlemistoimingute tegemist alamtöötlejalt ilma vastutava töötleja eelneva kirjaliku

eriloata. Volitatud töötleja esitab eriloa taotluse vähemalt 14 kalendripäeva enne

kõnealuse alamtöötleja kaasamist koos teabega, mis on vajalik, et vastutav töötleja saaks

loa kohta otsuse teha. Luba registreeritakse lepingu külge lisana.

5.2. Kui volitatud töötleja kaasab konkreetsete töötlemistoimingute tegemiseks (vastutava

töötleja nimel) alamtöötleja, teeb ta seda lepinguga, millega kehtestatakse alamtöötlejale

sisuliselt samad andmekaitsealased nõuded, mis on volitatud töötlejal käesolevate

nõuete kohaselt.

5.3. Volitatud töötleja tagab, et alamtöötleja täidab volitatud töötleja suhtes käesolevaid

nõudeid.

5.4. Volitatud töötleja jääb vastutava töötleja ees täielikult vastutavaks alamtöötleja nõuete

täitmise eest vastavalt volitatud töötlejaga sõlmitud lepingule. Volitatud töötleja

teavitab vastutavat töötlejat, kui alamtöötleja ei täida oma lepingulisi nõudeid.

6. Tehnilised ja korralduslikud meetmed, sealhulgas tehnilised ja korralduslikud

meetmed andmete turvalisuse tagamiseks

6.1. Volitatud töötleja kohustub tarvitusele võtma asjakohased tehnilised ja korralduslikud

meetmed lepingu alusel toimuva andmete töötlemise loata või ebaseadusliku töötlemise,

juhusliku kaotamise või hävitamise või kahjustumise vältimiseks.

6.2. Volitatud töötleja tagab organisatsioonisisese metoodilise ja süstemaatilise infoturbe

haldamise, eelistatult laialdaselt tunnustatud turvasmetoodika põhjal (nt ISO/IEC

27001, SOC2, CIS Security Controls, Eesti riiklik infoturbe standard E-ITS vms), sh

rakendades:

6.2.1. infoturbe riskihalduse;

6.2.2. varahalduse, sh arvestades RMK varadega;

6.2.3. infoturbe rollide ja vastutuse kindlaksmääramine;

6.2.4. pääsuõiguste halduse;

6.2.5. turvaintsidentide halduse;

6.2.6. jätkuvuse halduse, sh oma tarneahela ulatuses;

6.2.7. tööjaamade ja teiste IT-seadmete ja tarkvarade tugevdamise ja

konfiguratsioonihalduse;

6.2.8. kahjurvara tõrje;

6.2.9. krüptograafiliste meetmete halduse;

6.2.10. auditilogi ja turvaseire olemasolu;

6.2.11. nõrkuse ja paigahalduse;

6.2.12. füüsiliste turvameetmete halduse;

6.2.13. turvameetmete perioodilise läbivaatuse (vähemalt kord aastas).

6.3. Kõik need infoturbe protsessid peavad tagama RMK varade konfidentsiaalsuse,

tervikluse, käideldavuse ja organisatsiooni kohanemisvõime muutuvas küberohtude

keskkonnas.

7. Andmete turvalisus edastamisel ja talletamisel

7.1. Volitatud töötleja on kohustatud hoidma lepingu täitmise käigus teatavaks saanud

andmeid rangelt konfidentsiaalsena ning mitte kasutama ega avaldama andmeid, mis

tahes muul kui käesolevas lepingus sätestatud eesmärgil.

7.2. Konfidentsiaalse teabe edastamisel arvutivõrgu kaudu peab teave olema krüpteeritud

turvalise krüptomeetme abil vastavalt kokkulepitud andmeedastuse viisile, kas:

7.2.1. rakenduste vahelisel suhtlusel üle API kasutades turvalist šifrikomplektiga TLS

(HTTPS) veebiseanssi;

7.2.2. inimkasutajale andmete jagamisel üle veebiliidese kasutades turvalist

šifrikomplektiga TLS (HTTPS) veebiseanssi;

7.2.3. kaugpääsuga andmete jagamisel kasutades VPN ühendust turvalise

konfiguratsiooniga;

7.2.4. e-kirjaga andmete edastamisel kasutades krüpteeritud manuseid (.cdoc).

7.3. Konfidentsiaalse teabe talletamisel (andmed jõudeolekus) peab rakendama turvalisi

krüptomeetmeid. Näiteks kogu ketta krüpteerimine, mälupulga krüpteerimine,

krüpteeritud andmebaas või andmebaasi kirjed.

7.4. Turvaline krüptomeede on lahendus, mis rakendab turvalist krüptoalgoritmi,

võtmepikkust, krüptovõtme käsitlust, tarkvara jms. Valikul peab lähtuma uusimast RIA

avaldatud krüptograafiliste algoritmide elutsükli uuringust (https://www.ria.ee/amet-

uudised-ja-kontakt/uudised-pressikontakt/uuringud-ja-

analuusid?view_instance=2&current_page=1&sort_property=1&sort_direction=desc#

kruptouuringud).

7.5. Volitatud töötlejal pole lubatud edastada andmeid väljapoole Euroopa Liidu

liikmesriikide ja Euroopa Majandusühendusse kuuluvate riikide territooriumit ilma

vastutava töötleja sellekohase selgesõnalise kirjaliku nõusolekuta.

8. Pääsuhalduse meetmed

8.1. Volitatud töötleja on kohustatud oma töötajatele andma töödeldavatele isikuandmetele

juurdepääsu üksnes ulatuses, mis on vajalik lepingu täitmiseks, haldamiseks ja selle

täitmise üle tehtavaks järelevalveks. Volitatud töötleja tagab, et isikuandmeid töötlema

hakkavad volitatud isikud on kohustatud järgima isikuandmete töötlemise nõudeid või

nende suhtes kehtivaid asjakohaseid seadusjärgseid konfidentsiaalsuskohustusi.

8.2. Juurdepääs RMK varadele, sh teabele on lubatud:

8.2.1. VPN ja RDP/SSH kaugpääsu lahenduste kaudu;

8.2.2. läbi kokkulepitud IP aadressi;

8.2.3. Läbi külaliskontode.

8.3. Vastutava töötleja konfidentsiaalse teabega dokumentatsioon peab olema vastavalt

märgistatud, kui vastav märgistus on juba seotud alusdokumentatsioonil või kui need

juhised on vastutava töötleja poolt antud. Dokumentatsioonil saab kasutada märgistust:

asutusesiseks kasutamiseks ning vastav viide õigusaktile või “RMK siseseks

kasutamiseks”.

8.4. Vastutava töötleja süsteemides talletatud ja üksnes seal töötlemiseks mõeldud teavet ei

tohi kopeerida volitatud töötleja süsteemidesse, kui ei ole kirjalikult kokku lepitud

teisiti.

8.5. Vastutava töötleja konfidentsiaalsele teabele juurdepääsu jagamisel tuleb arvestada

konkreetsete töötajate teadmisvajadusega ning rakendada minimaalõiguste printsiipi.

8.6. Juurdepääsu võimaldavat teavet (nt paroolid, PIN-koodid, salajased või privaatvõtmed,

tookenid jne) tohib talletada ainult krüpteeritud kujul (nt tarkvaraline paroolihoidla,

vault) või füüsiliselt kaitstud hoidlas (nt seifis).

8.7. Juurdepääsul peab kõikidele kasutajatele jõustama mitmetasemelised autentimisviisid

ja keelama üksnes ühetasemelised autentimisviisid.

8.8. Vastutava töötleja süsteemides loodud kasutajakontosid võib kasutada ainult volitatud

töötleja töötaja, kellele nimeline konto on loodud ja kellele on pääsuõigused üle antud.

Konto jagamine on keelatud.

8.9. Volitatud töötleja peab vastutavat töötlejat viivitamata teavitama kasutajakonto

sulgemisese vajadusest, kui mõni volitatud töötleja töötajatest on töölt lahkunud, ei ole

enam seotud lepingu täitmisega või pääsuandmed on sattunud ohtu (nt lekkinud).

9. Töötluskoha füüsilise turbe meetmed

9.1. Vastutava töötleja konfidentsiaalset teavet tohib töödelda ainult nendes ruumides, kus

on tagatud piisav kaitse füüsiliste turvaohtude eest, näiteks seadme vargus või

volitamata juurdepääs, ekraani või klaviatuuri jälgimine jms.

10. Andmete kvaliteedi tagamise meetmed

10.1. Volitatud töötleja peab vastutava töötleja konfidentsiaalset teavet töötlema viisil, et

andmete õigsus, täielikkus ja ajakohasus oleks tagatud. Võimalusel peab rakendama

sisendandmete valideerimist, töödeldud andmete testimist ja kindlustama volitatud

töötleja poolt kasutatava tarkvara korrektne toimimine.

11. Sündmuste logimine ja seire

11.1. Volitatud töötleja tagab konfidentsiaalse teabe töötlemisega seotud revisjonlogi (audit

logi) olemasolu ja pideva turvaseire.

11.2. Logisid peab säilitama 2 aastat.

12. Jätkuvuse ja muudatuse meetmed

12.1. Volitatud töötleja teavitab vastutavat töötlejat kirjalikult kõigist muudatustest, mis

võivad mõjutada volitatud töötleja võimet või väljavaateid pidada kinni käesolevast

lisast ja vastutava töötleja kirjalikest juhistest. Pooled lepivad kõigis käesolevat lisa

puudutavates täiendustes ja muudatustes kokku kirjalikult.

12.2. Volitatud töötleja tagab oma teenuste kättesaadavuse, arvestades võimalike

probleemidega enda tarneahelas.

12.3. Vastutava töötleja poolsel pärimisel annab volitatud töötleja teavet oma toodetes

kasutatavatest süsteemi-komponentidest ja turvafunktsioonidest.

12.4. Teenuseid mõjutavatest muudatustest ja võimalikest plaanilistest katkestustest antakse

vastutavale töötlejale teada enne muudatust või katkestust.

13. Turvameetmete teavitus ja kontroll

13.1. Vastutav- ja volitatud töötleja peavad suutma tõendada käesolevate nõuete täitmist.

13.2. Volitatud töötleja peab võimaldama vastutaval töötlejal või tema poolt volitatud

audiitoril teha auditeid ja kontrolle ning panustama nendesse.

13.3. Vastutav- ja volitatud töötleja teevad auditi käigus saadud teabe ja auditite tulemused

taotluse korral kättesaadavaks pädevale järelevalveasutusele.

13.4. Volitatud töötleja tagab oma töötajate teavitamise käesolevatest turvameetmetest.

13.5. Volitatud töötleja tagab iseseisvalt enda ja alltöövõtjate organisatsioonis pideva

turvameetmete rakendatuse kontrolli.

13.6. Volitatud töötleja organisatsioonisisest infoturbehaldust peab auditeerima sõltumatu

osapool vähemalt üks kord aastas. Selle korraldab volitatud töötleja.

13.7. Tunnustatud turvasertifikaadi (nt ISO/IEC 27001, SOC2) või auditiaruande (E-ITS

auditi aruanne) korral ei pea eraldiseisvat sõltumatud auditit lisaks läbi viima, kui

sertifikaat või auditi aruanne:

13.7.1. on kehtiv;

13.7.2. käsitlusala katab ära RMK varadega seotud teenused või tooted;

13.7.3. tehakse vastutavale töötlejale kättesaadavaks.

13.8. Võimalikud erandid ja kõrvalekalded nimetatud meetmetest tuleb kirjalikult

kooskõlastada vastutava töötlejaga enne erandi rakendamist.

13.9. RMK võib igal ajahetkel kontrollida ja auditeerida nimetatud turvameetmete

rakendatust ja volitatud töötleja peab seda toetama.

14. Andmetega seotud rikkumisest teavitamine

14.1. Volitatud töötleja teavitab vastutavat töötlejat andmetega seotud rikkumistest või kui on

alust kahtlustada, et selline rikkumine on aset leidnud, ilma põhjendamatu viivituseta

alates hetkest, kui volitatud töötleja või tema poolt kasutatav alamtöötleja saab teada

andmetega seotud rikkumisest või on alust kahelda, et selline rikkumine on aset leidnud,

kuid mitte hiljem kui kakskümmend (20) tundi pärast sellest teada saamist.

14.2. Volitatud töötleja teeb vastutava töötlejaga igakülgset koostööd turvaintsidentide

käsitlemisel, sh analüüsimisel, isoleerimisel ja normaalse olukorra taastamisel.

14.3. Volitatud töötleja peab oma sisemised lahendused ja protsessid korraldama selliselt, et

intsidendi korral vastutava töötlejaga seotud äriprotsessid ja -teenused toimiksid

võimalikult vähese häiringuga.

14.4. Vastutava töötleja nõudmisel peab volitatud töötleja ilma põhjendamatu viivituseta

edastama vastutavale töötlejale kogu andmetega seotud rikkumist puudutava asjakohase

informatsiooni.

14.5. Teates tuleb kirjeldada vähemalt järgmist:

14.5.1. toimunud andmetega seotud rikkumise laad, andmesubjekti kategooriad ja

ligikaudne arv ning isikuandmete liigid ja ligikaudne arv;

14.5.2. eeldatav kuupäev ja kellaaeg;

14.5.3. isikuandmetega seotud rikkumise tõenäolised tagajärjed;

14.5.4. volitatud töötleja asjakohase kontaktisiku nimi ja kontaktandmed, kellelt saab

täiendavat informatsiooni;

14.5.5. meetmeid, mida volitatud töötleja rikkumise lahendamiseks on tarvitusele

võtnud või võtab, et vältida andmetega seotud rikkumisi tulevikus, ja vajaduse

korral ka meetmeid, mille abil leevendada rikkumise võimalikke negatiivseid

mõjusid;

14.5.6. esitama muud teavet, mis on mõistlikult nõutav, et vastutav töötleja saaks täita

kohaldatavaid andmekaitsealaseid nõudeid, sealhulgas riigiasutustega seotud

teavitamise ja avaldamise kohustusi, näiteks teavet, mis on nõutav

andmesubjekti tuvastamiseks;

14.5.7. Juhul kui kogu teavet ei ole võimalik esitada korraga, peab esialgne teade

sisaldama sel ajal kättesaadavat teavet ning täiendav teave esitatakse viivituseta

pärast selle saamist.

14.6. Teavet andmetega seotud rikkumistest ja turvaintsidentide kohta loetakse

konfidentsiaalseks ja see tuleb edastada krüpteeritult.

14.7. Teavitus tuleb edastada:

14.7.1. E-posti aadress: [email protected];

14.7.2. telefon: +372 676 7000.

14.8. Vastutav töötleja teavitab vajadusel kolmandaid osapooli, avalikkust ja

järelevalveasutusi, sh Andmekaitse Inspektsiooni, Riigi Infosüsteemi Ametit ja Politsei-

ja Piirivalveametit. Volitatud töötleja ei teosta avalikku suhtlust osas, mis võimaldab

tuvastada vastutavat töötlejat ja tema kliente.

15. Lõppsätted

15.1. Kui volitatud töötleja ei täida käesolevatest nõuetest tulenevaid kohustusi, võib vastutav

töötleja anda volitatud töötlejale korralduse peatada isikuandmete töötlemine seniks,

kuni volitatud töötleja järgib käesolevaid nõudeid või leping lõpetatakse. Volitatud

töötleja teavitab vastutavat töötlejat viivitamata, kui ta ei suuda käesolevaid nõudeid mis

tahes põhjusel täita.

15.2. Vastutaval töötlejal on õigus lõpetada leping , kui:

15.2.1. vastutav töötleja on volitatud töötleja poolse isikuandmete töötlemise punkti

15.1 kohaselt peatanud ja kui käesolevaid nõudeid ei hakata järgima mõistliku

aja jooksul või hiljemalt ühe kuu jooksul pärast peatamist;

15.2.2. volitatud töötleja rikub oluliselt või jätkuvalt käesolevaid nõudeid või

isikuandmete kaitse üldmäärusest tulenevaid nõudeid.

15.3. Volitatud töötlejal on õigus lõpetada leping isikuandmete töötlemise osas pärast seda,

kui ta on vastutavat töötlejat punkti 4.3.3 kohaselt teavitatud, et tema juhised lähevad

vastuollu kohaldatavate õigusnõuetega, kuid vastutav töötleja nõuab nende juhiste

järgimist.

15.4. Pärast lepingu lõpetamist kustutab volitatud töötleja vastutava töötleja valikul kõik

vastutava töötleja nimel töödeldud isikuandmed ja kinnitab vastutavale töötlejale, et ta

on seda teinud, või tagastab kõik isikuandmed vastutavale töötlejale ja kustutab

olemasolevad koopiad, välja arvatud juhul, kui seaduses kohaselt nõutakse

isikuandmete säilitamist. Volitatud töötleja jätkab nendele nõuetele vastavuse tagamist

seni, kuni andmed kustutatakse või tagastatakse.

POWER OF ATTORNEY On the 10th of July 2025 Nortal AS, registration code 10391131 (hereinafter Nortal), gives the following power of attorney:

1. Content of authorisation

With this power of attorney, Nortal authorises Olga Golubeva, date of birth 24.03.1987, personal code 48703240302, place of residence Tallinn, Republic of Estonia (“Attorney”), to:

1) Represent Nortal in public procurements, including, but not limited to, sign public procurement related statements, applications, deeds, acts, tender offers, and negotiate and sign procurement contracts under all conditions at the sole discretion of the Attorney;

2) Represent Nortal before all persons in relation to provision and procurement of IT services, including, but not limited to, negotiate and sign all IT services related contracts and contracts related to the procurement or sales of goods under all conditions at the sole discretion of the Attorney;

In connection with the powers described in this power of attorney, the Attorney is authorized to receive and formalize all documents, submit requests and applications, conclude contracts and respective amendments, participate in tenders, pay and receive money, sign documents on behalf of Nortal and do everything else related to the powers specified in this power of attorney.

2. Term of the power of attorney. Specifications concerning representation.

The power of attorney shall remain effective until 10th of July 2027.

The power of attorney has been issued without the right to delegate the powers.

The power of attorney is valid worldwide, i.e. does not have any geographical restrictions.

The power of attorney shall be governed by and construed in accordance with the laws of Estonia. /signed digitally/ Andre Krull Member of the management board

VOLIKIRI 10.07.2025 Nortal AS,registrikood 10391131 (edaspidi Nortal), annab alljärgneva volituse:

1. Volituse sisu Käesoleva volitusega Nortalannab Olga Golubeva’le, sünniaeg 24.03.1987, isikukood 48703240302, elukohaga Tallinn, Eesti Vabariik („Volitatud Esindaja“) õiguse enda nimel:

1) Esindada Nortalit riigihangetel, sealhulgas, kuid mitte ainult Nortali nimel allkirjastada riigihangetega seotud avaldusi, taotlusi, hanke akte ja hankepakkumisi ning läbi rääkida ja sõlmida hankelepinguid kõikidel tingimustel Volitatud Esindaja omal äranägemisel;

2) Esindada Nortalit kõikide isikute ees seoses IT-teenuste osutamise ja ostmisega, sealhulgas, kuid mitte ainult läbi rääkima ja allkirjastama kõiki IT teenustega seotud lepinguid ning kaupade ostu ja müügiga seotud lepinguid kõikidel tingimustel Volitatud Esindaja omal äranägemisel.

Eelpool toodud volitustega seotuses on esindaja volitatud saama ja vormistama kõiki dokumente, esitama taotlusi ja avaldusi, sõlmima lepinguid ja nende muudatusi, osalema pakkumistel, tasuma ja vastu võtma rahasummasid, dokumente Nortali nimel alla kirjutama ning tegema kõik muu, mis on seotud käesolevas volikirjas nimetatud volitustega.

2. Volituse tähtaeg. Esindusõiguse erisused.

Volikiri kehtib kuni 10.07.2027. Volikiri on antud edasivolitamise õiguseta. Volikiri kehtib kogu maailmas, st sellel puuduvad geograafilised piirangud. Volikirjale kohaldub Eesti õigus.

/allkirjastatud digitaalselt/ Andre Krull Juhatuse liige

Lisa 2 RMK ja Nortal AS

vahelise lepingu nr 1-18/2026/58 juurde

Arendusnõuded Avalikustamine: RMK sisene teave

Teavet ei ole lubatud jagada kolmandate osapooltega, v.a juhul, kui selleks on õiguslik alus ja/või see on vajalik tööprotsesside toimimiseks.

Avalikustamise lisainfo: “Arendusnõuded (MFN)” lisatakse tarkvara arendamise, hankimise ja juurutamise hangete korral hankedokumentide juurde, v.a dokumendi punktis 2.1 viidatud “RMK Töö- ja koodihaldus” ja punktis 5 viidatud “Logimise spetsifikatsioon”, mis väljastatakse hanelepingu sõlmimise järel ning punktis 2.3 viidatud “Eelistatud tehnoloogiate nimekiri”, mis väljastatakse konfidentsiaalsusleppe (NDA) või hankelepingu sõlmimise järel. Riigihangete portaali hankedokumentide juurde koos “Arendusnõuded (MFN)” dokumendiga neid vaikimisi ei lisata.

Sisukord Arendusnõuded ..................................................................................................................... 1

1. Ülevaade ja skoop .......................................................................................................... 2

2. Üldnõuded ..................................................................................................................... 2

2.1 Töö- ja koodihaldus ................................................................................................... 2

2.2. Operatsioonid, lokaalne käivitamine, CI/CD ja release ............................................... 2

2.3 Platvorm ................................................................................................................... 3

2.4 Koodi kvaliteet ja arendusprotsess ............................................................................. 3

2.5 Dokumenteerimine.................................................................................................... 4

2.6 Haldus ...................................................................................................................... 5

2.7 Välised sõltuvused .................................................................................................... 5

2.8 Muud üldised nõuded ................................................................................................ 5

3. Frontend nõuded (UX/UI) ................................................................................................ 6

3.1 Tehnilised ................................................................................................................. 6

3.2 Kasutuskogemus ....................................................................................................... 6

4. Backend nõuded (API/teenused) ..................................................................................... 7

4.1 Konfiguratsioon ja deploy .......................................................................................... 7

4.2 API disain ja dokumentatsioon ................................................................................... 7

4.3 Töökindlus ja monitooring .......................................................................................... 8

4.4 Koodistruktuur ja arendus .......................................................................................... 8

4.5 Integratsioon ............................................................................................................. 9

5. Logimine ........................................................................................................................ 9

6. Andmebaasi ja andmetöötluse nõuded ........................................................................... 9

6.1 Üldpõhimõtted .......................................................................................................... 9

6.2 Identifikaatorid ja audit .............................................................................................. 9

6.3 Platvorm ja tööriistad .............................................................................................. 10

6.4 Turvalisus ja juurdepääs .......................................................................................... 10

7. Turvanõuded ................................................................................................................ 10

7.1 Üldised põhimõtted ................................................................................................. 10

7.2 Sessioonid .............................................................................................................. 11

7.3 Lähtekood ja arendusvahendid ................................................................................ 11

9. Hooldatavus ja toetatavus ............................................................................................ 11

1. Ülevaade ja skoop Käesolev dokument kirjeldab kuidas RMK-s arendatakse, hangitakse ja juurutatakse tarkvara. See hõlmab nii tarkvara arendust kui ka karbitoodete ja SaaS (Software as a Service) teenuste kasutusele võttu. Nõuded ei kirjelda ärifunktsionaalsust.

Dokumendis viidatakse ka teistele välistele dokumentidele, mis moodustavad käesoleva dokumendiga ühtse terviku.

2. Üldnõuded

2.1 Töö- ja koodihaldus • Kõik tööd peavad olema kirjeldatud piletina RMK JIRA-s. Täpsemad JIRA ja

versioonihalduse kasutamise nõuded on kirjeldatud dokumendis „RMK Töö- ja koodihaldus“(välisele arenduspartnerile väljastatakse dokument peale hankelepingu sõlmimist).

• Git repod: RMK kood asub Azure DevOps repodes.

2.2. Operatsioonid, lokaalne käivitamine, CI/CD ja release • Lokaalne käivitus: Rakendused peavad olema lokaalselt käivitatavad ilma väliste

sõltuvusteta. Vajalikud sõltuvused peaksid olema lokaalselt käivitatavad Docker Compose-i konteineriga. Välised sõltuvused(API-d) võivad olla mockitud. Rakenduse käivitamiseks ja testimiseks vajalikud andmed peavad olema rakenduses seadistatud.

Peale käivitamist peab olema rakendus kasutatav. Rakenduse Vajalikud käsud ja sammud rakenduse lokaalseks käivitamiseks peavad olema välja toodud koodi repos README.md failis.

• Koodi formaadi kontroll: koodi formaadi kontroll peab olema build protsessi osa. Kood peab vastama RMK-s kokku lepitud formaadile.

• Staatiline analüüs: staatiline analüüs(nt Sonar) peab olema build protsessi osa selliselt, et kui kvaliteedi lävendit ei ületata, siis build ei õnnestu. Uus kood ei tohi tekitada juurde Sonari vigu. Lokaalselt seda sammu ei ole(võimalusel kasutada Sonarit IDE pluginana, või minna eraldi Sonari liidesesse ja kontrollida vigasid).

• Testimise üldnõuded: vt peatükk 9.

• Release strateegiad: kasutusel võivad olla erinevad väljalaskmise mustrid (nt blue- green, canary). Tähtis on, et uue versiooni kasutuselevõtt oleks kontrollitud ja võimaldaks vajadusel kiiret tagasipööramist.

• Production ressursivajadus: arendusmeeskonna ülesanne on testida rakenduse jõudlust ja selle põhjal teha ettepanek rakenduse ressursivajaduse kohta production keskkonnas, mis on sisendiks haldusosakonnale.

2.3 Platvorm • Versioon: Ükskõik mis programmeerimiskeelte, raamistike või teekidega infosüsteeme

realiseeritakse, kehtib sama põhimõte: alati kasutatakse kas viimast LTS(Long Term Support) versiooni, või selle puudumisel viimast stabiilset versiooni. Kui arendustöö käigus tuleb uus LTS versioon välja, siis see uuendatakse kohe ära, kui ei esine seda takistavaid asjaolusid.

• Eelistatud tehnoloogiate nimekiri: Nimekiri programmeerimiskeeltest, raamistikest, teekidest ja nende versioonidest, mida võib ilma täiendava kooskõlastamiseta kasutada on kirjeldatud dokumendis „Eelistatud tehnoloogiate nimekiri“(välisele arenduspartnerile väljastatakse dokument riigihanke käigus NDA alusel või peale hankelepingu sõlmimist). Juhul kui on soov kasutada midagi muud, siis tuleb see valik kooskõlastada RMK tarkvaraarhitektiga.

• Keskkond: backend, frontend ja andmebaasid töötavad Azure pilvekeskkonnas.

• CI/CD: kasutatakse Azure CI/CD. Build protsessi osana käivitatakse koodi formaadi kontroll, staatiline analüüs, testid.

• Sõltuvused: kasutatakse ainult toetatud ja turvauuendusi saavaid teeke.

• Skaleeruvus: rakenduste arendamisel peab arvestama võimalusega, et need jooksevad mitme õla peal.

• Docker: rakendus peab olema tarnitav Dockeri konteineritena.

2.4 Koodi kvaliteet ja arendusprotsess • Põhiharu kvaliteet: main haru peab alati olema testitud ja valmis production

keskkonda paigaldamiseks.

• Sisendi valideerimine: kõik kasutajalt või teistest süsteemidest tulevad sisendid valideeritakse. Kui rakendusel on nii kliendi- kui serveripool, toimub valideerimine mõlemas komponendis. Samuti rakendatakse valideerimist teistes integratsioonipunktides(andmebaas, välised liidesed).

• Väljundandmete kontroll: Rakenduse poolt kasutajale või teisele süsteemile väljastatavad andmed peavad olema õigesti vormindatud, äriliselt korrektsed ja turvalised.

o Formaadi kontroll: kõik väljastatavad väärtused vastavad kokkulepitud skeemile või standardile. Näiteks kuupäevad esitatakse ISO 8601 formaadis (2025-09-02T12:00:00Z), rahasummad kahe komakohaga, ning API vastus vastab OpenAPI kirjeldatud struktuurile.

o Äriline korrektsus: väljastatav info järgib ärireegleid ja loogikat. Näiteks ei väljastata negatiivset saldo väärtust, kui süsteemi reeglid seda ei luba; ID viitab alati reaalselt olemasolevale kirjetele; staatuse väljad sisaldavad ainult eeldefineeritud väärtusi.

o Turvalisus: väljund ei tohi sisaldada tundlikke või sisemisi andmeid, mida kasutaja või partner ei pea nägema (nt paroole, võtmeid, sisemisi tehnilisi tunnuseid). Tekstid peavad olema korrektselt escape’itud, et vältida XSS või sarnaseid ründeid. Logidesse ei tohi sattuda täielikud isikuandmed ega salajased identifikaatorid.

• Staatiline koodianalüüs: kasutatakse staatilist koodianalüüsi(Sonar); kõrge prioriteediga turvavead tuleb lahendada enne live keskkonda paigaldamist. Kõik Sonari vead vaadatakse enne arenduse üleandmist üle, vead mida ei peeta otstarbekaks parandada kooskõlastatakse RMK tarkvaraarhitektiga.

• Kompilaatori hoiatused: build-i hoiatused ja staatilise analüüsi tulemused vaadatakse üle ja arvestatakse.

• Kiirlahenduste vältimine: ei kasutata testimata lahendusi, mis eiravad häid praktikaid või RMK nõudeid.

• Testimise põhimõtted: vt peatükk 9.

2.5 Dokumenteerimine • Dokumentatsiooni põhielemendid:

o süsteemi funktsionaalne ja tehniline kirjeldus,

o kasutatavad liidesed (API-d, integratsioonid),

o perioodilised tööd (schedulerid, batch-protsessid),

o arenduskeskkonna seadistamine

o andmebaasi struktuuri kirjeldus (tabelid, seosed, migratsioonid),

o keskkonnad ja paigaldus

o peamised hooldustegevused (nt logide ülevaatus, varunduse kontroll, sõltuvuste uuendamise tsükkel)

• Dokumentatsiooni asukoht: RMK Confluence keskkond

• Diagrammid: süsteemi arhitektuuri ja komponente visualiseeritakse eelistatult PlantUML või Mermaid formaadis.

• Arhitektuur: iga süsteemi kohta peab olema arhitektuuriülevaade, sealhulgas API spetsifikatsioonid (nt OpenAPI).

2.6 Haldus • Tehniline võlg: arenduse käigus tuleb dokumenteerida teadaolevad piirangud ja

tehniline võlg (nt TODO-d, ajutised lahendused) ning soovitused nende likvideerimiseks.

• Sõltuvuste ja platvormi uuendused: arenduse käigus tuleb kirjeldada süsteemi kaasaegsena hoidmise strateegiat (nt milliseid raamistikke ja teeke tuleb regulaarselt uuendada, millal tuleb planeerida üleminek LTS-versioonidele).

• Monitooringu vajadused: tarnija peab kirjeldama arendatava süsteemi monitooringu aspektid (nt vealogid, jõudlusmõõdikud, integratsioonide toimivus, job scheduler-i töö).

• Teavitused: tarnija peab defineerima soovitatud häirete künnised (nt kui API annab vea, kui mingi protsess ei lõpeta näiteks 15 minutiga).

• Elutsükli planeerimine: tarnija peab andma hinnangu, millised tehnoloogiad või komponendid võivad lähiaastatel vajada moderniseerimist või väljavahetamist.

• Andmete säilitustähtajad: kui süsteemis talletatakse andmeid, millel on määratud säilitustähtaja (vastavalt teabe liigitusskeemile Jira Assetis), tuleb see dokumenteerida. Dokumentatsioonis peab olema kirjeldatud, millised andmed kustutatakse automaatselt, millal ja kuidas.

2.7 Välised sõltuvused • Teekide kasutamine: kasutada ainult laialdaselt toetatud ja turvauuendusi saavaid

teeke.

• Sõltuvuste miinimum: sõltuvusi hoitakse minimaalsena, et vähendada turvariske ja halduskoormust.

• Litsentsid: sõltuvuste litsentsitingimusi, turvalisust ja ajalugu hinnatakse; eelistatakse vabavaralisi komponente.

• Jätkusuutlikkus: hinnatakse teekide jätkuarenduse ja toe kättesaadavust. Vajadusel analüüsitakse mõju RMK protsessidele, kui komponendi arendus lõpeb.

• Ühilduvus: analüüsitakse kasutatavate komponentide ühilduvust teiste süsteemidega.

2.8 Muud üldised nõuded • Kodeering ja locale: kogu süsteemis (lähtekoodis, andmebaasis, jne) kasutatakse UTF-

8 kodeeringut; vaikekeel on et-EE (laiendatav i18n); ajatsoon on UTC (UI-s kohalik aeg).

3. Frontend nõuded (UX/UI)

3.1 Tehnilised • Tehnoloogia: kui rakenduse nõuded võimaldavad siis eelistame serveris renderdatud

HTML-i (Thymeleaf, HTMX).

• Raamistikud: kui kasutatakse mingit raamistikku, siis eelistame laialdaselt toetatud raamistikku (nt React, Angular või Vue).

• Raamistiku versioon: projektis kasutatavad raamistikud peavad olema toetatud ja saama turvauuendusi.

• Build: sõltuvused hallatakse paketihalduriga, arvestades kasutatavat tehnilist lahendust:

o SPA: npm / yarn / pnpm (lock fail versioonihalduses; build deterministlik).

o Java SSR (Server-Side Rendering nt Thymeleaf): Gradle (või Maven) hoiab nii backendi kui frontendi build-i .

o PHP SSR: Composer.

o Python SSR: pip. Build peab olema deterministlik ja versioonitav (lock failid, build-config git-s).

• Keskkonnaspetsiifilised seaded: hoitakse välises konfiguratsioonis (nt .env).

• API kasutus: kõik API-päringud käivad läbi konfiguratsiooni alusel määratud lõpp- punktide; otselinke koodis ei kasutata.

• Turvalisus: tundlikke andmeid ei salvestata brauseri püsivasse vahemällu (LocalStorage, SessionStorage) ilma krüpteerimiseta.

• Jõudlus: rakendus peab laadima mõistliku aja jooksul – esmase laadimise vaikimisi nõue on 2s. Täpsem kontekst (nt mõõdik, tüüpiline seade ja võrguolud) lepitakse projekti alguses kokku ja fikseeritakse rakenduse/projekti dokumentatsioonis. Pildid, skriptid ja stiilid peavad olema optimeeritud (lazy load, cache, minify).

• Telemeetria: kriitilised kliendipoolsed vead (JavaScript errorid, katkised API päringud) peavad jõudma tsentraalsesse monitooringusse.

3.2 Kasutuskogemus • Reageeriv(responsive) disain: rakendus peab olema kasutatav erineva

ekraanisuurusega seadmetel (desktop, mobiil, tahvel).

• Navigatsioon: menüüd ja liikumisloogika on rakenduse eri vaadetes ühtsed. Sama funktsionaalsus on alati leitav samast kohast.

• Nuppude paigutus ja järjestus: sama tüüpi tegevused (nt “Salvesta”, “Tühista”) paiknevad alati samas järjekorras ja paigutusega.

• Veateated: esitatakse ühtses formaadis (struktuur, sõnastus, värvilahendus). Teated on arusaadavad ja ei sisalda tehnilist müra. Veateated ei sulgu automaatselt, et kasutajal oleks võimalik neid adekvaatselt edastada toe saamiseks.

• Kinnitused ja dialoogid: riskantsete tegevuste (nt kustutamine, lõplik kinnitamine) puhul küsitakse alati kinnitust. Dialoogid järgivad sama stiili ja loogikat.

• Abitekstid ja juhendid: tooltipid, sisestusväljade placeholderid ja abitekstid on stiililt ja positsioonilt ühtsed. Kõik väljad ja tegevused on varustatud abitekstiga, mis aitab kasutajal mõista, mis juhtub enne kui ta midagi teeb.

• Laadimise tagasiside: pikemate tegevuste puhul (nt päring serverisse, faili üleslaadimine) peab kasutaja nägema visuaalset indikaatorit (spinner, progress bar).

• Etteaimatavus: süsteemi käitumine peab olema selge ja ootuspärane – väldime olukorda kus kasutaja peab mõtlema „mis siis juhtub, kui ma siia vajutan“. Tegevuste tagajärjed on nähtavad või selgitatud enne sooritamist.

• Ikonograafia ja sümbolid: sama tegevuse tähistamiseks kasutatakse alati sama ikooni ja tähendust.

• Stiil ja kujundus: värvipalett, kirjatüübid ja komponentide kujundus vastavad ühtsele disainisüsteemile või stiilijuhendile.

• Klahvikombinatsioonid ja kiirtoimingud (kui rakendatud): töötavad järjepidevalt kõigis vaadetes.

• Terminoloogia: tekstid ja nimetused (nt “kasutaja”, “konto”, “fail”) on järjepidevalt samad kogu rakenduses.

• Andmete sisestuse valideerimine: sisestusväljade puhul kasutatakse valideerimist enne serverisse saatmist, et ilmseid vigu kasutajale kiiremini esile tuua.

4. Backend nõuded (API/teenused)

4.1 Konfiguratsioon ja deploy • Seadistused: keskkonnaspetsiifilised väärtused hoitakse rakendusest väljas (Azure

Key Vault, keskkonnamuutujad), aga konfiguratsioon ise on koodi juures vastavates failides.

• Konfiguratsioon: konfiguratsioon on versioneeritav ja muudatused jälgitavad.

• Ehitamine: Java projektide ehitamisel eelistatakse Gradle-t.

4.2 API disain ja dokumentatsioon • Versioonimine: REST/HTTP liidesed on versioonitud (nt /v1). • Dokumentatsioon: kõik REST/HTTP liidesed peavad olema dokumenteeritud nii, et

partneritel ja RMK-l on võimalik neid kasutada ja testida. Dokumentatsiooni võib teha erineval viisil (nt kirjalik juhend, Postman collection, README näidised). Soovitatavalt kasutatakse masinloetavat standardit OpenAPI ja sellest genereeritud Swagger liidest.

• Asukoht: kui kasutatakse OpenAPI/AsyncAPI dokumentatsiooni, peab vastav fail asuma samas Git repo-s koos lähtekoodiga, et see oleks alati koodiga kooskõlas.

• Koormuse juhtimine: kasutatakse mehhanisme ülekoormuse vältimiseks (nt rate limiting, throttling).

• Veakäsitlus: veateated on standardiseeritud, inimloetavad ja ei sisalda tundlikku sisemist infot.

• Sisend, väljund: API sisend ja väljund peab jälgima REST põhimõtteid (https://restfulapi.net/).

• Protokoll, formaat: kasutatakse HTTP protokolli ja API väljund on JSON, välja arvatud binaarfailide puhul.

4.3 Töökindlus ja monitooring • Health-checkid: rakendus peab pakkuma health-check ja readiness liideseid(Spring

Boot Actuator).

• Observability: rakendused edastavad minimaalselt request count, response time, error rate mõõdikuid Azure Monitori(Micrometer)

• API töökindlus: API peab olema kasutatav (vastab päringutele) ja enamus päringuid peab lõppema mõistliku aja jooksul ning ilma veata. Täpsemad jõudluse või töökindluse eesmärgid määratakse projektipõhiselt.

• Testimine: Integratsiooniteste ja end-to-end teste võib kirjutada. Nende puudumisel tuleb enne release-i teha regressioonitestimist käsitsi.

4.4 Koodistruktuur ja arendus • Struktuur: Java projektides kasutatakse kihipõhist package struktuuri, kus

komponendid on jaotatud package-tesse tehnilise rolli järgi (nt controllers, services, repositories).

• Perioodilised tööd: kõik schedulerid, batchid ja stored procedures dokumenteeritakse README-s. Perioodiliste tööde käivitamine eraldi klassis äriloogikast.

• Automaatne andmete kustutamine: kui süsteemis on andmeid, millel on määratud säilitustähtaja (vastavalt teabe liigitusskeemile), tuleb rakendada automaatne kustutamise funktsionaalsus. Automaatne kustutamine toimub perioodilise tööna (scheduler, batch), mis kontrollib andmete vanust ja kustutab andmeid, mis on ületanud säilitustähtaja. Kustutamise protsess peab olema logitud.

• Teenusklassid: äriloogika peab olema realiseeritud Service kihis, mille sisendiks ja väljundiks on domeeniobjektid. Teenuseklassi testideks on unit testid.

• Kontrollerid: Kontrollerite testid tuleb kirjutada kasutades MockMvc raamistikku, kus teenuste kihi vastused on mockitud.

• Presentatsioonikiht: presentatsioonikiht ei tohi kasutada sisendiks ja väljundiks domeeniobjekte, vaid eraldi Request ja Response ressursse.

• Autoriseerimine: päringute autoriseerimine peab toimuma kontrolleritekihis. • Testimine: koodi unit testide haru-kattuvus(branch coverage) peab olema 80%. Unit

testid tuleb jooksutada CI/CD süsteemis iga buildiga uuesti. Build peab katki minema, kui testid pole edukad. Repository (ja messaging) kihi testid tuleb kirjutada integratsioonitestidena vastu mockitud (nt rest apid) või konteineris jooksva päris välise süsteemi vastu (näiteks rakenduse Postgres baas TestContainers abil). Iga test hoolitseb ise oma testandmete loomise ja esialgse seisu taastamise eest. Erinevates testides samade andmete kasutamine ei ole lubatud.

• Koodistandard: vaikimisi kasutatakse Google Java koodistandardit, mille kontrollimine on osa buildist.

4.5 Integratsioon • Andmebaasid, välised liidesed: andmebaasi ja teiste väliste andmete küsimine peab

olema lahendatud eraldi repository kihis, mis väljastab äriloogika kihile ainult domeeniobjekte.

• Sõnumid, eventid: eventide saatmine ja vastuvõtmine peab olema realiseeritud äriloogikast eraldi consumerites ja producerites.

5. Logimine Logimisnõuded on kirjeldatud dokumendis „Logimise spetsifikatsioon“.

• NB! Välisele arenduspartnerile väljastatakse “Logimise spetsifikatsioon” dokument peale hankelepingu sõlmimist.

6. Andmebaasi ja andmetöötluse nõuded

6.1 Üldpõhimõtted • Andmete terviklikkus: kõik andmebaasi struktuurid (tabelid, seosed, indeksid) peavad

tagama andmete terviklikkuse ja vältima duplikaate või orvuks jäänud kirjeid.

• Normaliseeritus: andmemudel peab olema vähemalt 3. normaalkujus või põhjendatult denormaliseeritud (näiteks jõudluse kaalutlustel).

• Järjepidevus: andmete formaat ja tähistus (nt kuupäevad, valuutad, staatuse väljad) peab olema ühtne kogu süsteemis.

• Äriloogika: relatsioonilisse baasi tuleb suhtuda kui andmete hoidlasse, äriloogika peab olema implementeeritud rakenduskihis. Storedprocedure kasutamine ei ole lubatud.

6.2 Identifikaatorid ja audit • Primaarvõtmed: numbrilised ID-d on eelistatud, mitte UUID, välja arvatud kui on

tehniline vajadus globaalseks unikaalsuseks.

• Auditväljad: igas tabelis, kus toimub andmete muutmine, peavad olema väljad created_by, created_at, modified_by, modified_at. Ajatemplid (created_at, modified_at) on vajalikud ka andmete automaatseks kustutamiseks vanuse järgi.

• Kustutuse logimine: kõik andmete kustutamise operatsioonid (nii automaatsed kui käsitsi) peavad olema logitud koos kustutatud andmete tüübi, kustutamise ajaga, põhjuseks ja tegijaga (süsteem või kasutaja).

• Auditlogi või event sourcing: kasutatakse sõltuvalt süsteemi iseloomust ja ärivajadusest.

6.3 Platvorm ja tööriistad • Andmebaasi tarkvara: RMK eelistatud andmebaas on PostgreSQL. Arenduse ja

testimise eesmärgil võib kasutada ka mäluandmebaase (nt H2, SQLite3).

• Migratsioonid: kõik struktuurimuudatused hallatakse migratsioonitööriistadega ja versioonihalduses (soovitatavalt Flyway). Käsitsi tehtud muudatused ei ole lubatud, välja arvatud erandkorras ja RMK-ga eelnevalt kooskõlastatult. Kõik sellised muudatused tuleb dokumenteerida ja kanda tagasi migratsiooniskriptidesse, et tagada keskkondade ühtsus.

6.4 Turvalisus ja juurdepääs • Paroolid ja autentimisandmed: salvestatakse ainult soolatud räsi kujul (nt Argon2,

bcrypt, scrypt). Lihttekstina talletamine on keelatud.

• Õiguste haldus: andmebaasis kasutatakse eraldi kontosid rakenduse ja haldustööde jaoks (väikseima privileegi põhimõte).

7. Turvanõuded

7.1 Üldised põhimõtted • Autentimine ja identiteet: rakendused ja kasutajad tuvastavad end RMK

autentimisnõuete alusel (Entra ID, TARA väliskasutajatele).

• Autoriseerimine: juurdepääs rakendustes toimub rollipõhiselt. Rollide nimetusvorming: APP-{env}-{teenus}-{roll}.

• Andmete liigitus: rakenduse planeerimisel määratakse andmete tüüp ja liigitus, dokumenteeritakse nende käsitlemise alused. Säilitustähtajad määratakse vastavalt teabe liigitusskeemile Jira Assetis ja andmesäilituse teemapoliitikale.

• Turvaline arendus: rakenduse arendamisel järgitakse RMK dokumente Arenduse elutsükkel ja Turvaline arhitektuur.

• Andmekaitse: mitteavalikud andmed kaitstakse vastavalt teabe liigitusskeemile ja andmekaitse nõuetele. Töötlemisel järgitakse kehtivaid andmekaitse õigusakte, sh GDPR.

• Andmevahetus: kogu andmevahetus on krüpteeritud (TLS 1.2+); kasutatakse RMK krüptograafia juhendis määratud protokolle ja vorminguid.

• Auditväljad ja -logi: rakendustes logitakse, millal ja kes kirje lõi ning viimati muutis (audit trail).

• Saladuste haldus: kõik võtmed ja paroolid hoitakse Azure Key Vault-s, mitte lähtekoodis või konfiguratsioonifailides.

• Keskkondade eraldatus: live keskkond peab olema rangelt eraldatud arendus- ja testkeskkondadest. Toodanguandmeid ei tohi kasutada arendus- ega testkeskkondades.

• Vajaduspõhine ligipääs: kõik ligipääsud lähtuvad vajaduspõhimõttest (default deny).

• Vähima privileegi põhimõte: kõik protsessid töötavad vähimate vajalike õigustega.

• Autentimise integreerimine: kasutajate õiguseid arvestatakse läbivalt igal tasemel (UI, äriloogika, andmebaas, integratsioonid).

7.2 Sessioonid • Timeout: serveripoolne sessiooni idle timeout ≤ 30 minutit, absoluutne timeout ≤ 12

tundi.

• Sessiooni turvalisus: sessiooni ID logitakse vajadusel maskitult või räsitult.

• Sessiooni lõpetamine: sessioon suletakse automaatselt, kui kasutaja logib välja või jõuab timeout.

7.3 Lähtekood ja arendusvahendid • Ligipääs: lähtekood asub RMK Azure DevOps keskkonnas, kus ligipääsu hallatakse

projekti põhiselt.

o RMK arendajatele antakse ligipääs vajaduspõhiselt töölepingu kehtivuse ajal.

o RMK töötajatele antakse ligipääs ainult vajaduse korral ja vaikimisi lugemisõigus.

o Välistele arendajatele antakse projektipõhine ligipääs, mis eemaldatakse projekti lõppedes.

• Lähtekoodi turvalisus: tuleb vältida lubamatute funktsioonide lisamist ja tagada, et lähtekood, arendusvahendid ja teegid on kaitstud tahtmatute või pahatahtlike muudatuste eest.

• Koodi kvaliteet: turvavigade automaatne analüüs (nt Sonar).

8. Hooldatavus ja toetatavus • Koodistandardid: rakenduse kood peab olema ühtses stiilis, loetav ja järgitav, et ka uus

arendaja saaks töö kiiresti üle võtta.

• Juhendite praktilisus: dokumentatsioon peab olema piisavalt selge, et uuel arendajal või administraatoril oleks võimalik süsteem kiiresti üle võtta.

• Testid: rakenduse põhitöövood peavad olema kaetud automaatsete testidega. See võimaldab veenduda, et süsteemi põhifunktsioonid töötavad ka pärast muudatusi. Täpsemalt vt peatükk 9.

• Runbook-d (käitamis- ja taastamisjuhendid): kriitiliste töövoogude ja häireolukordade jaoks peab olema lühike samm-sammuline juhend, mis kirjeldab, kuidas probleem lahendada või süsteem taastada.

• Tugi ja eskaleerimine: peab olema selge, kes ja kuidas reageerib süsteemi tõrgetele ning millised on reageerimisajad erineva tõsidusega olukordades.

9. Testimine • CI/CD ja build: unit- ja integratsioonitestid peavad jooksma igal ehitusel. Build peab

ebaõnnestuma, kui testid ei ole edukad.

• Peaharu: main haru peab alati olema testitud ja valmis productionkeskkonda paigaldamiseks.

• Testide kattuvus: unit testide haru-kattuvus (branch coverage) peab vaikimisi olema 80%. Projekti- või hankepõhisel kokkuleppel võib tase olla madalam ning erand tuleb fikseerida kirjalikult.

• Testide liigid ja kasutus:

o Unit testid: puhta loogika testimiseks, kus on konkeete sisend ja väljund. Unit testid ei sobi testideks, mille osaks on I/O, võrguga seotud funktsionaalsus või aeg.

o Integratsioonitestid: katavad liideseid ja sõltuvusi(andmebaas, failisüsteem, MQ, REST liidesed jne)

o End-to-end testid: katavad kasutaja töövooge (nt Playwright); vaikimisi katame E2E testidega ainult põhitöövood.

• Testandmed: iga test loob ise testandmed ja vajadusel taastab esialgse seisu; erinevates testides samu testandmeid kasutada ei tohi.

• Integreerimis- ja E2E testid: kui neid ei ole, tuleb enne release'i teha regressioonitestimine käsitsi.

• Testkeskkonnad ja -andmed: testimise käigus ei tohi kasutada toodanguandmeid arendus- ega testkeskkondades (vt 7.1).

• Turva- ja jõudlustestid: tehakse projekti ja vajaduspõhiselt.