Lisa 2- Arendusnõuded - Riigimetsa Majandamise Keskus

lisa 2- arendusnõuded-2026-02.pdf

Lisa 2

RMK ja Askend Estonia OÜ

Vahelise lepingu nr 1-18/2026/92

juurde

Arendusnõuded

Dokumendi punktis 2.1 viidatud “RMK Töö- ja koodihaldus” ja punktis 5 viidatud “Logimise spetsifikatsioon” väljastatakse hanelepingu sõlmimise järel ning punktis 2.3 viidatud “Eelistatud tehnoloogiate nimekiri” väljastatakse konfidentsiaalsusleppe (NDA) või hankelepingu sõlmimise järel.

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

3.1 Tehnilised ................................................................................................................. 5

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

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

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

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

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

7.2 Sessioonid .............................................................................................................. 10

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.

raamleping rh306077 nr 1-18202692 (1).asice

Digiallkirjad

Allkirjade kehtivust ei ole kontrollitud.

VASSILI LJAHHOVETS PNOEE-38501316046 2026-04-28 11:01:09

lepingu lisa 3 - isikuandmete töötlemise nõuded volitatud töötlejale.pdf

Lisa

RMK ja Askend Estonia OÜ

vahelise lepingu nr

1-18/2026/92 juurde

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

[Vali kuupäev]

(hiliseima digitaalallkirja kuupäev)

1. Üldine

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

Askend Estonia OÜ (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 Andme-

subjektide

kategooriad

Andmete liigid Töötlemise

alused

Säilitustähtajad

RMK

mobiilirakenduse abil

andmevahetuse

võimaldamine RMK

sisemiste

infosüsteemide ja

väliste osapoolte

vahel.

RMK töötajad

Välised

partnerid

RMK kliendid

ja rakendust

kasutavad

külastajad

Isikut tuvastavad

andmed (sh

pildid);

Kontaktandmed;

Kasutajakontode

andmed;

Volituste andmed;

Lepingute

andmed;

Asukoha andmed;

GDPR art

6(1)(e) ja GDPR

art 6(1)(b) -

avalikes huvides

oleva ülesande

täitmine ja

lepingu täitmine

GDPR art

6(1)(a) -

andmesubjekti

nõusolek (tema

poolt üles laetud

piltide puhul)

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.

Rakenduse turvalisuse

ja töökindluse

tagamine.

RMK töötajad

Välised

partnerid

RMK kliendid

ja rakendust

kasutavad

külastajad

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.

lisa 1- tehniline kirjeldus_190226 (4).pdf

Lisa 1

RMK ja Askend Estonia OÜ

Vahelise lepingu nr 1-

18/2026/92

juurde

Mobiilirakenduste arendushange

Riigimetsa Majandamise Keskus

Taust

Riigimetsa Majandamise Keskus (RMK) kasutab matkaradade kuvamiseks, metsatööde juhtimiseks, töövõtjate tegevuste juhtimiseks ja mitmete teiste tööde andmete sisestamiseks paljusid mobiilirakendusi, millest valdav enamik on tänaseks tehnoloogiliselt vananenud.

Antud hanke eesmärk on leida RMK-le mobiilsete rakenduste arenduspartner. Partneril peab olema kompetents ja kogemused mobiilsete rakenduste arendamisel. Oluline on jätkusuutlikele lahendustele orienteeritud mõtteviis, operatiivsus ja kaasaegsetele tehnoloogiatele tuginemine.

Hanke eesmärk ja ulatus

RMK soovib hankida mobiilirakenduste arendusteenuse, mis aitab ellu viia:

- RMK mobiilirakenduste väljavahetamise kaasaegsete ja turvaliste mobiilirakenduste vastu;

- Aitab valideerida meie enda uuendatud mobiilirakenduste kvaliteeti ja teha ettepanekuid parendusteks;

- Mobiilirakenduste komponentide hooldust ja versiooniuuendusi kokkulepitud ulatuses ja skoobis kogu raamlepingu perioodi vältel.

Hetkeolukord Järgnevalt kirjeldame RMK olemasolevad mobiilirakendused ja tänased tehnoloogiad, mis kõik vajavad uuendamist.

Olemasolevad rakendused

Avalikud rakendused

• RMK Loodusega koos App – Rakendus Google Plays (Cordova) • RMK Loodusega koos App - Rakendus App Store (Cordova)

RMK Loodusega koos – Rakendused Google Plays

RMK Loodusega koos App - App Store

Sisemised mobiilsed rakendused

• ChipsDriver - Hakkpuidu veoki rakendus (Android native)

• Chipper - Hakkurile mõeldud rakendus (Android native) • TimberDriver - Ümarpuidu veoki rakendus (Android native) • Taksaator - Metsakorraldaja rakendus (Android native) • Traktorist(Forwarder) - Kkokkuveo traktoristi rakendus (Android native) • Saemees(Sawyer) - Raie ettevalmistuse võsatööde rakendus (Android native) • MKT KVH (Kvaliteedi hindamine) - Metsakasvatajate analüütikute rakendus

välitöödel (Android native) • MMR - Metsamees - MKT ja TVT lisamoodul: Metsakasvatuse saemehe rakendus

(Android native) • DMK (Dokumendid metsa kaasa) - Rakendus, mis võimaldab salvestada

mobiilseadmes offline'i kõik dokumendid, mis üleval lehel juhendid.rmk.ee (Android native)

• AMK (Andmed metsa kaasa) - Andmed Metsa Kaasa - Offline võimekusega mobiilne rakendus. Kvartalid, eraldised, teed ja kraavid. Andmed laetavad metskondade kaupa. (Android native)

Tehnoloogiline hetkeolukord Praeguse seisuga on ametlikes rakenduste poodides (Google Play, Apple App Store) üksnes avalik RMK rakendus Loodusega Koos. Loodusega Koos kasutab Cordova platvormi, mis võimaldab ühest veebitehnoloogiate põhisest koodibaasist genereerida native rakendused nii Google Play kui ka App Store-i rakenduste poe jaoks.

Teisi tööde juhtimiseks ja haldamiseks mõeldud rakendusi levitatakse läbi RMK enda loodud keskkonna(uuendused, vealogid, kasutatavus). Need on Android native rakendused (Java).

Rakendustel on tüüpiliselt ka java backend, suhtlus toimub läbi REST API.

Native Android rakendused on tehniliselt vananenud, sellega seoses on tekkinud mitmeid probleeme:

• Google Play Protect mehhanism märgistab rakendusi kui kahtlasi (installitud mitte-ametlikust allikast, vana Android SDK versioon)

• Rakenduste suhtlus serveriga ei vasta kaasaegsetele turvanõuetele • Võimalikud turvavead vananenud komponentides • Kasutajad piiratud üksnes Android platvormiga

Soovitud tehniline arhitektuur Käesolev peatükk kirjeldab RMK poolt eelistatud arhitektuurset lähenemist ja tehnoloogilisi valikuid. Täpsemad kohustuslikud tehnilised nõuded on toodud peatükis “Tehnilised nõuded”.

PS.RMK on avatud arenduspartneri soovitustele ja arhitektuurialastele nõuannetele mobiilirakenduste tehnoloogilise arhitektuuri ülesehitamisel.

Üldine lähenemine Avalikud ja laiale kasutajaskonnale suunatud rakendused (nt Loodusega Koos) levitatakse ametlike rakenduste poodide kaudu ning peavad olema native paketid. Eelistatult genereeritakse need ühest ühisest koodibaasist mitmele platvormile.

Sisemised, tööks mõeldud rakendused realiseeritakse esmajärjekorras Progressive Web App (PWA) tehnoloogial ning hostitakse RMK poolt. Juhtudel, kus PWA ei ole tehniliselt või funktsionaalselt sobiv, kasutatakse Androidi native-lahendust, ning levitatakse läbi Google Play Store-i.

Selline lähenemine võimaldab valida rakenduse levitus- ja kasutusviisi vastavalt sihtrühmale ja kasutusstsenaariumile, tagades kiire muudatuste tarnimise, vähendatud arendus- ja hoolduskulud ning tehnoloogilise sõltumatuse.

Alljärgnevalt on kirjeldatud RMK kontekstis eelistatud arhitektuursed realiseerimisviisid.

Native rakendused

• Native-rakendused realiseeritakse native pakettidena ning levitatakse alati ametlike rakenduste poodide kaudu (Google Play, Apple App Store).

• Native-lahendus võib olla arendatud platvormipõhiselt või genereeritud ühisest koodibaasist (nt React Native, Kotlin Multiplatform, Flutter).

• Avalikud ja laiale kasutajaskonnale suunatud rakendused peavad toetama nii Androidi kui ka iOS-i platvormi.

• Sisemised tööks mõeldud rakendused võivad olla piiratud Androidi platvormiga, kuid levitatakse siiski ametliku rakenduste poe (Google Play) kaudu.

• Native-rakendused võimaldavad täielikku ligipääsu seadme võimekustele (nt biomeetriline autentimine, turvaline võtmehoidla, offline-tugi).

• Kasutaja autentimine (nt TARA kaudu) ja turvamehhanismid on lahendatud vastavalt rakenduse kasutusotstarbele.

Puhas PWA-lahendus

• Rakendused realiseeritakse Progressive Web App (PWA) tehnoloogial ning töötavad brauseripõhiselt ilma native paketita.

• PWA-rakendused hostitakse RMK enda infrastruktuuris, ilma rakenduste poodide vahenduseta.

• Paigaldamine kasutaja seadmesse toimub PWA mehhanismide kaudu. • Autentimine, offline-tugi, seadmevõimekused ja uuendused on lahendatud PWA

tehnoloogiate abil.

PWA tehnilised omadused Järgnevalt on kirjeldatud PWA tehnoloogiaga kaasnevaid tüüpilisi võimalusi ja omadusi, mis on RMK rakenduste kontekstis asjakohased.

• Offline'i tugi - kõige olulisem eelis, kuna RMK rakendustega töötatakse ebaühtlase leviga piirkondades. PWA võimaldab rakendustel jätkata tööd ka aktiivse netiühenduseta, salvestades andmed kohalikult ja sünkroniseerides need hiljem, kui ühendus taastub. See tagab töö pidevuse ka kehvema leviga metsapiirkondades;

• Geolokatsioon - võimaldab täpse asukoha määramist, mis on oluline metsatööde dokumenteerimiseks ja juhtimiseks;

• Teavitused - võimaldab kasutajatele oluliste sündmuste ja uuenduste kohta teavituste saatmist, isegi kui rakendus ei ole aktiivselt avatud;

• Uuenduste kiire levitamine - muudatused ja uuendused saab tarnida otse kasutajatele ilma rakenduste poe review protsessi läbimata, tagades kiire reageerimise vajadustele;

• Turvaarhitektuur - kasutab parimaid veebirakenduste turvapraktikaid, sh HTTPS, turvaline autentimine ja andmete krüpteerimine.

PWA eelised • Vähendatud arendus- ja hoolduskulud - üks koodibaas töötab nii Androidi kui ka

iOS platvormidel, samal ajal pakkudes native rakendustega võrreldavat kasutajakogemust;

• Laiendatav seadmete tugi - võimaldab laiendada toetatavate seadmete hulka, kuna seni on metsatööde rakendustes toetatud üksnes Androidi. PWA lahendus võimaldab nüüd toetada ka iOS seadmeid ja tulevikus võimaldab hõlpsalt lisada toetust ka teistele platvormidele;

• Kiire muudatuste tarnimine - võimaldab kiirelt muudatusi klientidele tarnida, ilma et rakenduste poe review protsessist tuleneva viivituseta;

• Vähendatud sõltuvus - vähendab sõltuvust rakenduste poe omanikfirma poliitikast ja nõudmistest.

Autentimine Autentimise vaates on 3 erinevat stsenaariumit: RMK enda töötajad, välised kasutajad kes kasutavad isikupõhist autentimist ja seadmepõhine autentimine.

RMK töötajad autendivad kasutades Azure Entra ID-d.

RMK väliste kasutajate isikupõhiseks autentimiseks kasutame TARA/Smart-ID teenuseid.

Seadmepõhise autentimise korral kasutatakse seadme identiteedil põhinevat autentimisskeemi (nt tokeni või sertifikaadi alusel).

Tehnilised nõuded

Offline-first ja ebastabiilne võrk • Rakendus peab töötama ka piiratud ühenduse korral (katkendlik või puuduv

ühendus), sh vaated ja põhifunktsioonid peavad degradeeruma kontrollitult. • Lokaliseeritud andmehoid (nt IndexedDB / SQLite) koos selge

sünkroniseerimisloogikaga (järjekorrad, retry, backoff). • Konfliktihaldus: määratletud reeglid (last-write-wins / merge / kasutaja valik)

ning kasutajale arusaadav tagasiside. • Failide ja suurte payload’ide käsitlemine: chunking, katkestuse jätkamine

(resume), progress ja ajutine salvestus.

Andmete sünkroniseerimine ja töökindlus • Kõik serverioperatsioonid peavad olema idempotentsed või idempotentsusega

kooskõlas (võrgu korduspäringud ei tekita duplikaate). • Taustsünkroniseerimine (PWA: Background Sync võimalusel; muidu app-level

scheduler) ning selge järjekorrastamise mudel. • Versioonitud API ja andmemudel: tagurpidi ühilduvus vähemalt N versiooni

ulatuses. • Kliendi ja serveri vaheline suhtlus peab toimuma standardiseeritud API kaudu,

eelistatult REST/JSON protokolli abil, võimaldades lihtsat versioonimist, vahemällu salvestamist ja tõrketaluvust.

Turvalisus ja identiteet (mobiilikontekst) • Autentimine/autoriseerimine standardprotokollidega (OIDC/OAuth2), tokenite

turvaline hoidmine (PWA: mitte localStorage, eelistada HttpOnly cookie-t või turvalisi storage mustreid).

• Sessiooni aegumine ja taastamine: kasutaja ei kaota tööd, aga turvariskid on kontrolli all.

• Tundlikud andmed, kui neid hoitakse lokaalselt, peavad olema krüpteeritud. Rakendus peab toetama rakendusesisest lukustust ja turvalist uuesti autentimist. Biomeetria või ekraanilukustus kasutatakse juhul, kui platvorm seda standardliideste kaudu võimaldab.

• Minimaalsete õiguste põhimõte (least privilege) nii kliendis kui API-s. • Andmeside turvalisus: kogu rakenduse andmeside kliendi ja serveri vahel peab

olema krüpteeritud, kasutades kaasaegseid turvaprotokolle (nt HTTPS/TLS), ning krüpteerimata ühendused ei ole lubatud.

• Rakenduse turvalisus: rakenduse arendamisel ja konfigureerimisel tuleb arvestada OWASP-i asjakohaseid turvasoovitusi (sh OWASP Top 10), et vältida levinud turvanõrkusi.

Uuendused ja versioonihaldus (PWA eripära) • PWA puhul peab olema selge uuenduste loogika (“update strategy”): kasutajale

arusaadav teavitus uue versiooni olemasolust. • Cache’i versioonimine ja migratsiooniplaan (service worker, asset cache, API

cache). • Mobiilirakenduse puhul tagurpidi ühilduvus serveri poolel (vanemad kliendid ei

tohi kohe katkeda).

Seadmevõimekused ja platvormierinevused • Selge abstraktsioonikiht seadme-API’dele (kaamera, GPS, failid, teavitused), et

hoida äri- ja UI-loogika platvormisõltumatuna. • Piirangute käsitlemine: rakendus peab arvestama kasutaja rolle ja õigusi,

käsitlema juurdepääsupiiranguid ja tõrkeolukordi ning andma kasutajale arusaadavat tagasisidet ja juhiseid.

• Energiakasutus ja ressursid: piirata tausttööd, koondada sünkroniseerimisi, vältida liigset GPS kasutust.

Ligipääsetavus (WCAG) ja kasutatavus välitingimustes • Siht: Vähemalt WCAG 2.1 AA või parem. • Klaviatuur/fookus (PWA), ekraanilugejad (TalkBack/VoiceOver), kontrast, suured

klikitavad sihtmärgid. • Välitöö kontekst: suured nupud, kindaga kasutus (target size), selged veateated,

“undo” kriitilistes tegevustes. • Rakendus peab kohanema erineva suuruse ja orientatsiooniga ekraanidega

(responsive design), tagades põhifunktsioonide kasutatavuse nii mobiilseadmetes, tahvlites kui ka suurematel ekraanidel.

Korduvkasutatav arhitektuur ja komponendid (mitme rakenduse portfell)

• Ühtne disainisüsteem/komponendikogu (UI kit) ja ühised UX mustrid. • Ühiste teenuste ja klienditeekide kiht: auth, API client, error handling, logging,

feature flags. • Modulaarne arhitektuur: funktsionaalsed moodulid eraldi pakettidena, et

suurendada koodi korduvkasutust ja vähendada vigu. • Ühtsed kvaliteedireeglid: lint/format, testinõuded, sõltuvuste poliitika.

Testitavus ja kvaliteediväravad • Automatiseeritud testid: unit, integration (API/sync), e2e kriitiliste voogude

jaoks. • Ligipääsetavuse automaattestid (PWA) + manuaalsed kontrollid. • CI/CD: reproducible builds, PWA deploy immutable. PWA väljalasked peavad

olema muutumatud (immutable), kus iga versioon kasutab eraldi versioonitud ja hashitud ressursse ning olemasolevaid väljalaskeid ei muudeta tagantjärele, võimaldades kontrollitud ja etteaimatavat rakenduse uuendamist.

Monitooring, logimine ja auditeeritavus (rakenduse tasemel) • Kliendipoolne telemeetria ja vealogimine (crash/JS errors), korrelatsiooni-ID

päringutel. • Offline sündmuste järjekord (event queue) ja saatmine ühenduse taastumisel. • Privaatsus: isikuandmete minimeerimine logides. Rakenduse logimise ja

monitooringu konfiguratsioon peab tagama isikuandmete (PII) automaatse eemaldamise või maskeerimise enne logide talletamist ja edastamist.

Jõudlus • Rakenduse arhitektuur peab toetama kiiret külmkäivitust ja lühikest aega kuni

rakendus on kasutajale tegelikult kasutatav (time-to-interactive). Selle saavutamiseks tuleb rakenduse kood ja ressursid laadida järk-järgult, tuues alguses ainult käivituseks ja esmaseks kasutuseks vajaliku. Ülejäänud funktsionaalsus ja vaated laaditakse nõudepõhiselt (lazy-load), vähendades algset allalaaditavat mahtu. PWA puhul tuleb rakendada koodi ja ressursside jaotamist (code splitting), et vältida ühe suure monoliitse paketi laadimist.

• Andmemahtude piiramine: paging, delta sync, kompressioon. • Piltide/failide optimeerimine ning arvestus et kasutajate seadmed ei pruugi väga

võimsad olla.

Mitmekeelsus ja lokaliseerimine • Rakendus peab toetama mitmekeelset kasutajaliidest (nt eesti ja inglise),

võimaldama keele vahetamist ning kasutama lokaliseerimislahendust, mis eraldab keelelise sisu rakenduse loogikast.

Otsitav kompetents ja kvalifikatsioonid

Üldpädevus Arendajal peab olema praktiline kogemus mobiilirakenduste arendamisel nii native lahenduste (Android, iOS) kui ka Progressive Web App (PWA) tüüpi rakenduste kontekstis. Ta peab suutma iseseisvalt kavandada, arendada, testida ja hooldada rakendusi kogu elutsükli vältel ning mõistma mobiilirakenduste arhitektuurilisi, ligipääsetavus-, jõudlus- ja turvanõudeid.

Androidi native rakenduste arendus Arendajal peab olema:

• tugev praktiline kogemus Android rakenduste arendamisel (Android SDK); • oskus kasutada programmeerimiskeeli Java ja/või Kotlin; • kogemus Android Studio, Gradle’i ning Androidi build’i ja deploy protsessidega; • teadmised Androidi arhitektuurimustritest (nt MVVM, Clean Architecture); • kogemus UI arendamisel (XML, Jetpack Compose) ning erinevate

ekraanisuuruste ja seadmete toetamisel; • arusaam Android rakenduste jõudlusest, mäluhaldusest ja elutsüklist; • kogemus rakenduste avaldamisel ja haldamisel Google Play poes.

IOS native rakenduste arendus

• tugev praktiline kogemus iOS rakenduste arendamisel (iOS SDK); • oskus kasutada programmeerimiskeelt Swift (soovitav) ja/või Objective-C; • kogemus XCode’i, Swift Package Manageri (või CocoaPods’i) ning iOS build’i ja

deploy protsessidega; • kogemus UI arendamisel (SwiftUI ja/või UIKit) ning erinevate seadmete ja

orientatsioonide toetamisel; • arusaam iOS rakenduste elutsüklist, mäluhaldusest ja jõudlusest; • kogemus rakenduste avaldamisel ja haldamisel App Store’s (sertifikaadid,

provisioning profile’d, TestFlight).

PWA ja veebipõhised mobiilirakendused Arendajal peab olema:

• praktiline kogemus PWA-de arendamisel; • head teadmised veebitehnoloogiatest: HTML5, CSS3, JavaScript / TypeScript; • kogemus kaasaegsete veebiraamistikega (nt React, Vue, Angular või sarnased); • arusaam PWA põhikomponentidest: service worker’d, offline-toetus, caching,

web manifest; • kogemus responsive disaini ja mobiilse kasutajakogemuse loomisel; • teadlikkus PWA piirangutest ja erinevustest võrreldes native rakendustega.

Integratsioon, taustasüsteemid ja API-d Arendajal peab olema:

• kogemus REST- ja/või GraphQL API-de kasutamisel; • arusaam autentimis- ja autoriseerimismehhanismidest (nt OAuth2, JWT); • teadmised andmevahetusest, veahaldusest ja võrguühenduse ebastabiilsuse

käsitlemisest.

Ligipääsetavus ja kasutatavus (WCAG) Arendajal peab olema teadmised ja praktiline kogemus digiligipääsetavuse põhimõtete rakendamisel. Ta peab arendustöös arvestama WCAG 2.1 või uuema versiooni nõuetega ning suutma neid rakendada nii Androidi ja iOS native platvormil kui ka PWA tüüpi lahendustes.

Sealhulgas eeldatakse:

• arusaama ligipääsetavuse põhialustest (tajutavus, kasutatavus, arusaadavus, töökindlus);

• oskust rakendada korrektseid semantilisi elemente, kontrastsuse, fookuse ja navigeeritavuse nõudeid;

• teadlikkust ekraanilugerite, klaviatuuriga kasutamise ja abitehnoloogiate eripäradest;

• võimet hinnata ja parandada olemasolevate kasutajaliideste ligipääsetavust; • valmisolekut dokumenteerida ja põhjendada tehtud ligipääsetavusalaseid

otsuseid.

Kvaliteet, testimine ja turvalisus Arendajal peab olema:

• kogemus automaat- ja manuaaltestimisega (nt unit-, integratsiooni- ja UI-testid); • arusaam mobiilirakenduste turvariskidest ja parimatest praktikatest; • oskus järgida versioonihalduse ja koodikvaliteedi põhimõtteid (Git, code review).

Tööstiil ja koostöö Arendajalt eeldatakse:

• võimet töötada iseseisvalt ja meeskonnas; • oskust dokumenteerida tehnilisi lahendusi arusaadavalt; • kogemust agiilsete arendusmeetoditega (nt Scrum, Kanban); • valmisolekut õppida uusi tehnoloogiaid ja kohaneda projekti vajadustega;

Töökorraldus ja nõuded

Dokumentatsioon Arenduste teostamisel peab Täitja koostama dokumendi(d), millede eesmärgiks on anda selge ja konkreetne ülevaade süsteemi sisust ja realiseeritud arendustest. Eraldiseisvaid dokumente üle ei anta vaid Tellija keskkonda (Confluence) kirjutatakse analüüsi jooksvalt projekti käigus. Kirjeldused peavad olema kinnitatud Tellija poolt enne arendustöö algust.

Üle antavad dokumendid peavad sisaldama:

• Infosüsteemi terviku kirjeldus – olemasoleva süsteemi täiendamisel lisatud/muudetud osade kirjeldus. Tegemist on süsteemi ärisisul põhinevate baaskomponentidega, millele toetuvad kasutaja tegevused, ekraanivormid, kasutuslood/protsessid, teenused jms;

• Vormide (ekraanivormide) kirjeldused; • Kasutuslugude / vormide kasutamise protsesside / tegevuste kirjeldused; • Infosüsteemi teenuste kirjeldused; • Juurutuse faasis ja lõpus peab Täitja esitama arhitektuuri kirjeldus dokumendi,

mille eesmärgiks on kirjeldada loodava ja/või juurutatava süsteemi tehnilist ülesehitust. Kirjeldatakse rakenduse loogilist struktuuri, näidates ära selle kihtideks jagunemise;

• Kirjeldatakse ka füüsilist arhitektuuri, antakse ülevaade kasutatavatest tehnoloogiatest ning vahenditest.

Dokumenteerimise kohta täpsemalt on kirjas Arendusnõuete all.

Testimine • Enne töö üleandmist viib Täitja töö nõuetelevastavuse kindlakstegemiseks läbi

testid. • Kui töö või mistahes selle osa ei läbi teste, viiakse pärast seda, kui Täitja on

teinud vajalikud korrektuurid testide edukaks läbiviimiseks, läbi kordustestid samadel tingimustel. Tellija nõudmisel viib kordustestid läbi Täitja.

Tugiteenus • 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.

Lisad: Lisa 1- Mobiilirakenduste arendushange – meeskonna rollid ja ülesanded