Uue dokumendihaldussüsteemi juurutamine, arendus ja hooldustööd

lisa 2 - arendusnõuded.docx

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 1
2. Üldnõuded 1
2.1 Töö- ja koodihaldus 1
2.2. Operatsioonid, lokaalne käivitamine, CI/CD ja release 1
2.3 Platvorm 2
2.4 Koodi kvaliteet ja arendusprotsess 2
2.5 Dokumenteerimine 3
2.6 Haldus 4
2.7 Välised sõltuvused 4
2.8 Muud üldised nõuded 4
3. Frontend nõuded (UX/UI) 4
3.1 Tehnilised 4
3.2 Kasutuskogemus 5
4. Backend nõuded (API/teenused) 6
4.1 Konfiguratsioon ja deploy 6
4.2 API disain ja dokumentatsioon 6
4.3 Töökindlus ja monitooring 6
4.4 Koodistruktuur ja arendus 7
4.5 Integratsioon 7
5. Logimine 7
6. Andmebaasi ja andmetöötluse nõuded 8
6.1 Üldpõhimõtted 8
6.2 Identifikaatorid ja audit 8
6.3 Platvorm ja tööriistad 8
6.4 Turvalisus ja juurdepääs 8
7. Turvanõuded 8
7.1 Üldised põhimõtted 8
7.2 Sessioonid 9
7.3 Lähtekood ja arendusvahendid 9
9. Hooldatavus ja toetatavus 10

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.
◦ 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.
◦ Ä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.
◦ 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:
◦ süsteemi funktsionaalne ja tehniline kirjeldus,
◦ kasutatavad liidesed (API-d, integratsioonid),
◦ perioodilised tööd (schedulerid, batch-protsessid),
◦ arenduskeskkonna seadistamine
◦ andmebaasi struktuuri kirjeldus (tabelid, seosed, migratsioonid),
◦ keskkonnad ja paigaldus
◦ 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:
◦ SPA: npm / yarn / pnpm (lock fail versioonihalduses; build deterministlik).
◦ Java SSR (Server-Side Rendering nt Thymeleaf): Gradle (või Maven) hoiab nii backendi kui frontendi build-i .
◦ PHP SSR: Composer.
◦ 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 kontrollerite kihis.
• 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. Stored procedure 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.
◦ RMK arendajatele antakse ligipääs vajaduspõhiselt töölepingu kehtivuse ajal.
◦ RMK töötajatele antakse ligipääs ainult vajaduse korral ja vaikimisi lugemisõigus.
◦ 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 production keskkonda 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:
◦ 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.
◦ Integratsioonitestid: katavad liideseid ja sõltuvusi(andmebaas, failisüsteem, MQ, REST liidesed jne)
◦ 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_.asice

Digiallkirjad

Allkirjade kehtivust ei ole kontrollitud.

TARGO TENNISBERG PNOEE-37811244731 2026-04-01 08:42:51

lisa 1 - tehniline kirjeldus dhs.docx

LISA 1 – TEHNILINE KIRJELDUS

1. Hanke eesmärk ja üldised tingimused
1.1. Käesoleva hanke eesmärgiks on sõlmida raamleping ühe pakkujaga, kes hakkab juurutama uut RMK (Hankija) dokumendihaldussüsteemi (DHS), teostab integratsioonid ja võimalikud lisaarendustööd, samuti viib läbi andmete migratsiooni. Hankega on hõlmatud lisaks koolitused ning tugi- ja hooldusteenus.
1.2. Eesmärgiks on võtta kasutusele uus dokumendihaldussüsteem lähtuvalt HD Lisast 1, 2 ja 3.

2. Tehnoloogilised nõuded
2.1. Tarkvara peab olema integreeritav hankija poolt kasutusel olevate ning tulevikus kasutusele võetavate infosüsteemidega. Hanke väljakuulutamise hetkeks olevad infosüsteemid on kirjeldatud HD Lisas 3 (MFN).
2.2. Arendus- ja testkeskkondades kasutatakse ainult testandmeid. Andmetöötluse vajaduse ilmnedes LIVE (siin ja edaspidi tähenduses: töökeskkond, kus lahendus on hankijale kättesaadavaks tehtud) keskkonnast antakse arendus- ja testkeskkondadesse töödeldavad andmed reeglina hägustatud või muul viisil anonümiseeritud kujul (v.a. juurutusperioodil).

3. Üldised nõuded tarkvarale
Lahenduse funktsionaalsed nõuded on detailselt kirjeldatud HD Lisas 2 (funktsionaalsusnõuded).
3.1. Funktsionaalsuse ulatus ja kvaliteet:
3.1.1. Tarkvara peab katma kõik hanke alusdokumentides nõutud funktsionaalsused või pakkuma vähemalt samaväärset funktsionaalsuse taset. Samaväärsust hinnatakse tellija poolt demona ja vajadusel funktsionaalsustestidega.
3.2. Äriprotsesside automatiseerimine:
3.2.1. Tarkvara peab sisaldama sisseehitatud tööriistu dokumendihaldusega seotud äriprotsesside automatiseerimiseks.
3.2.2. Peab võimaldama töövoogude loomist ja kohandamist, mis toetavad ettevõtte konkreetseid äriprotsesse.
3.3. Skaleeritavus ja paindlikkus:
3.3.1. Süsteem peab olema skaleeritav vastavalt hankija kasvavatele või kahanevatele vajadustele ning toetama kohandusi ja konfiguratsiooni muudatusi vastavalt hankija spetsiifilistele nõuetele.
3.4. Pilvepõhisus ja turvalisus:
3.4.1. Tarkvara peab olema pilvepõhine lahendus, mis tagab kõrge turvalisuse ja andmete kättesaadavuse.
3.4.2. Lahendus peab võimaldama andmete ja komponentide paigaldamist hankija hallatavasse pilvekeskkonda, tagades hankija kontrolli andmete asukoha, ligipääsu ja turvapoliitika üle.
3.4.3 Turvalisus peab olema tagatud kogu dokumendi elutsükli vältel.
3.4.4. Peab vastama Lisa 2 väljatoodud standarditele ja üldmäärustele.
3.4.5. Juurutatav tarkvara lokalisatsioon ja tema komponendid peavad olema paigaldatud Hankija haldusalas olevasse pilveruumi.
3.5. Kasutusmugavus ja kasutajaliides:
3.5.1. Tarkvara peab olema kasutajasõbralik ja intuitiivne, toetades tõhusat igapäevast tööd organisatsiooni erinevatel tasanditel ja rollides. Kasutajaliidese kujundamisel tuleb lähtuda kasutajakesksuse ja tööprotsesside loogilisuse põhimõtetest.

4. Andmete korrastus ja andmete migratsioon
4.1. Pakutav tarkvaraline lahendus peab võimaldama andmete migratsiooni Hankija olemasolevatest süsteemidest ja Hankija poolt välja töötatud reeglite alusel kus:
4.1.1. Defineeritakse andmete koosseis ja formaat;
4.1.2. Migreeritavate andmete maht;
4.1.3. Migreeritavate andmete eluiga.
4.2. Pakkuja peab pakkuma migratsiooni jaoks vajalikud tehnilised lahendused.
4.3. Pakkuja peab pakkumist tegemisel arvestama, et andmed võivad migreerimisel vajada töötlust ning nende kvaliteet testimist.

5. Litsentsid
5.1. Pakkuja peab tagama toote kasutamiseks vajalikud litsentsid Hankija poolt määratud ulatuses.
5.2. Pakkuja võib tarkvara loomisel kasutada järgnevaid komponente ja litsentse:
5.2.1. Üleantav tarkvara (või tarkvara üleantavad komponendid) – täitja loovutab kõik varalised autoriõigused tarkvarale tervikuna (või selle teatavatele osadele) tellijale.
5.2.2. Jagatav tarkvara (või komponendid) – täitja annab kõik varalised autoriõigused (või osa neist) tellijale ja jätab samad õigused ka endale. Jagatavate õiguste sisu ja maht tuleb pakkumuses selgelt määratleda.
5.2.3. Litsentseeritav tarkvara (või komponendid) – täitja annab tellijale enda loodud tarkvara suhtes litsentsi ning mis tuleb kirjeldada vastavalt punktile 5.4.
5.3. Pakkuja võib rakendada eraldi litsentsitasusid pakkuja olemasolevate funktsionaalsuste, moodulite vm toodete osas. Nimetatud litsentsid peavad olema lahti kirjeldatud litsentsikirjelduses (vt p 5.4) ning võtma arvesse, et:
5.3.1. litsentside kogus on eeldatav lähtuvalt kasutajate arvust, kuid kasutajate arv võib muutuda raamlepingu täitmise ajal ning hankija ei ole kohustatud soetama litsentse käesolevas dokumendis märgitud kogustes;
5.3.2. litsentside maksumuse määramisel arvestatakse, et kõik kasutajad hakkavad LIVE keskkonda kasutama pärast I etapi LIVEi;
5.3.3. arvesse võetakse kasutajate profiilid kasutajate kogused.
Kasutajate profiil
Arv ettevõttes
Peakasutaja
1
Administraator
1
Arhivaar
1
DHS-i kasutajad
600

5.4. Pakkuja esitab vastavustingimustes litsentsikirjelduse, mis sisaldab:
5.4.1. kõikide pakkumusega seotud litsentside nimetust, kogust kasutajagruppide lõikes jm oluline info;
5.4.2. pakkuja olemasolevate funktsionaalsuste, moodulite vm toodete pakutavate litsentside osas lisaks kirjeldust ja maksumust, nn masin-masin litsentsid;
5.4.3. samaväärse platvormi litsentside jm seotud litsentside kirjeldust ja maksumust vastavalt arenduse etappidele.
5.5. Maksumusena märgitakse HD Lisas 5 ühikuhinnad aastapõhise hinnastamisega. Kasutajate arvu määramisel lähtutakse punktis 5.3.3 esitatud tabelist. Seisuga veebruar 2026 on vajalik 600 litsentsi. Raamlepingu kehtivuse jooksul võib see arv suureneda või väheneda. Pakkuja peab arvestama, et raamlepingu vältel võib litsentside koguarv muutuda vastavalt tegelikule vajadusele.
5.6. Punktis 5.3.2 ja 5.3.3 nimetatud maksumused arvestatakse hanke maksumuse hulka vastavalt hindamiskriteeriumites toodule.
5.7. Hankija hindab vastavusena sh litsentside vajaduse realistlikkust (sh kas pakkuja poolt pakutud litsentside sisu ja kogusega on võimalik kasutada tarkvara hanke alusdokumentides märgitud funktsionaalsuses ja kasutajate arvuga).
5.8. Pakkuja võib pakkumusse lisada omapoolsed litsentsilepingu tingimused, mis ei tohi olla vastuolus hanke alusdokumentides sätestatuga ega esitada hankijale kitsendavaid või piiravamaid tingimusi hanke alusdokumentides sätestatust.

6. Juurutustööd ja lisaarendustööd
6.1. Juurutustööde aluseks on Pakkuja poolt pakkumusega esitatud Lisa 2 ja 3, milles on esitatud iga nõude eeldatav töötundide maht. Täpsem töötundide maht täpsustub peale analüüsifaasi koostatud projektiplaanis, kus on välja toodud töömahud tundide kaupa. Kui tegelik töömaht osutub kogu projektiplaanis toodud tundidest rohkem kui 5% suuremaks, on Täitja kohustatud sellest Tellijat kirjalikult teavitama ning ootama ära Tellija kirjaliku kinnituse töödega jätkamiseks. Ilma Tellija eelneva kirjaliku kooskõlastuseta ületatud töötunnid ei kuulu Tellija poolt tasumisele.
6.2. Lisaarendustööde maht esitatakse arendusdokumendis töötundide kaupa. Kui lisaarenduse tegelik töömaht osutub arendusdokumendis toodud tundidest rohkem kui 5% suuremaks, on Täitja kohustatud sellest Tellijat kirjalikult teavitama (nt JIRA piletis) ning ootama ära Tellija kirjaliku kinnituse töödega jätkamiseks. Ilma Tellija eelneva kirjaliku kooskõlastuseta ületatud töötunnid ei kuulu Tellija poolt tasumisele.
6.3. Lisaarendustööd tähendavad nii uute süsteemide liidestamist tarkvaraga kui ka uute funktsionaalsuste lisamist.
6.4. Lisaarendustööd seisnevad tarkvara täiendava funktsionaalsuse eesmärgipärase funktsioneerimise tagamiseks teostatavatest töödest, mis ei ole käsitletavad tugiteenusena ja ei tulene seadusandluse muudatustest. Lisaarendustööd võivad olla ka täiendavad juurutamistööd raamlepingu kestvusel pärast esimese etapi LIVE’i. Hankijal on õigus, kuid mitte kohustus tellida täiendavaid lisaarendustöid.
6.5. Lisaarendus peab ühilduma tarkavaga selliselt, et see ei häiri tarkvara muud funktsionaalsust. Üleantud lisaarendus loetakse tarkvara osaks ning sellele laieneb ka tugiteenus olemasolevas mahus.

7. Arendustööde nõuded
7.1. Tarnida RMK jaoks arendatud dokumendihaldussüsteemi laiendused koos lähtekoodiga.
7.2. Tarnida RMK jaoks arendatud dokumendihaldussüsteemi laiendused koos tehnilise ja kasutaja dokumentatsiooniga.
7.3. Kui tarnitav lahendus või selle osa ei ole dokumendihaldussüsteemi komponent, siis sellistel lahendustel peab olema eraldi turva / vastavuse sertifikaat.
7.4. Jälgima RMK tarkvara “Arendusnõudeid” (vt HD Lisa 6).
7.5. Tarnija peab olema valmis kasutama RMK poolt ette antud IT haldusvahendid – JIRA, Confluence, Azure DevOps jne.
7.6. Juhul, kui RMK-le tarnitakse kohandatud dokumendihaldussüsteemi laiendus, mis põhineb sama tarnija teise baasrakenduse peal ja laiendab selle funktsionaalsuse, peab tarnija hoidma ka põhirakenduste koodi up-to-date.
7.7. Tellijal peab olema õigus lähtekoodi kasutada ja edasi arendada ka lepingu lõppemisel.

8. Koolitused
8.1. Riigihanke arendustööde mahtu kuulub tarkvara kasutamise eestikeelse üldjuhendi koostamine ja hankijale kättesaadavaks tegemine hiljemalt arendusetapi lõpuks. Lisaks peab olema tagatud
kogu tarkvara kasutamise ajal ajakohastatud kasutusjuhendite kättesaadavus, sh lisaarenduste kirjeldused.
8.2. Riigihanke arendustööde mahtu kuulub tarkvara kasutamise koolitus kasutajatele rollist lähtuvates gruppides. Koolitus peab toimuma eesti keeles. Koolituse toimumisvorm (veebis või kohapeal) ja täpsed koolitusajad kokkuleppel hankijaga. Koolitus tuleb salvestada ning salvestus edastada hankijale. Koolitusel peavad olema käsitletud tarkvara funktsionaalsused. Täpsemad koolituste sihtgrupid ja arvud on funktsionaalsuste tabelis.

9. Tugiteenus ja hooldusteenus
9.1. Tugiteenus peab sisaldama pakutava lahenduse toimimisega seotud kasutajatuge ja tarkvarauuendusi (sh versiooniuuendused) kogu raamlepingu kehtivusperioodil vastavalt hanke alusdokumentidele.
9.2. Seadusemuudatustest tulenevad versiooniuuendused peavad olema Tellijale kättesaadavad ilma täiendava tasuta.
9.3. Hankija nõuded tugiteenusele on järgmised:
9.3.1. raamlepingu täitmise ajal tagab pakkuja tarkvara kasutusteenuse nõuetekohase toimise, sh intsidentide tekkimise korral reageerima ja probleemi lahendama vastavalt teenustasemetele;
9.3.2. parandama turvanõrkuseid ja uuendama tarkvara vastavalt allolevale tabelile;

Tõsidus
CVSS skoor
Paikamise ajakava
Kriitiline
CVSS 9.0 – 10.0
Esimesel võimalusel, kuid mitte hiljem kui 72h (3 ööpäeva)
Kõrge
CVSS 7.0 – 8.9
Esimesel võimalusel, kuid mitte hiljem kui 7 ööpäeva
Keskmine
CVSS 4.0 – 6.9
Mitte hiljem kui 30 ööpäeva
Madal
CVSS 0.0 – 3.9
Muu plaanipärase tarkvarauuenduse käigus, kui ei ole hinnatud ebavajalikuks.

9.3.3. hoidma tarkvara kohalikule seadusandlusele vastavana;
9.3.4. hoidma tehnilist ja lõppkasutaja dokumentatsiooni ajakohasena;
9.3.5. nõustama hankijat süsteemis muudatuste tegemisel ja kasutamisel.
9.4. Tugi- ja hooldusteenust tellitakse vastavalt vajadusele ning arveldatakse tunnitasupõhiselt.
9.5. Tugiteenus peab olema tagatud tööpäevadel kella 08.00 kuni 17.00. Tööpäevadeks loetakse kõiki nädalapäevi, välja arvatud laupäev, pühapäev ja riigipühad.
9.6. Kriitiliste funktsionaalsuste planeeritud hooldusakendest tuleb ette teatada vähemalt kaks (2) tööpäeva. Süsteemi kättesaadavus kriitiliste funktsionaalsuste osas peab olema vähemalt 99,8% aastas, mis tähendab, et planeerimata katkestuste kogukestvus ei tohi ületada 17,52 tundi aastas. Kriitilise vea korral (Tase 1) ei tohi teenuse taastamisaeg (MTTR) ületada 4 tundi. . Kättesaadavuse arvestus toimub aastapõhiselt teenuse tagatud tööajal (p 9.5) ning planeeritud hooldusaknad (p 9.12) ei kuulu kättesaadavuse arvestusse.
9.7 Mitte-kriitiliste funktsionaalsuste planeeritud katkestustest tuleb ette teatada vähemalt viis (5) tööpäeva. Mitte-kriitiliste funktsionaalsuste puhul ei tohi planeerimata katkestused põhjustada süsteemi kättesaadavuse langemist alla 99,8% aastas. Keskmise tasemega ja madala tasemega vigade (Tase 3 ja Tase 4) lahendamise ajad lepitakse kokku vastavalt Lisa 3 “Teenusetasemed” sätestatule. Kättesaadavuse arvestus toimub aastapõhiselt teenuse tagatud tööajal (p 9.5) ning planeeritud hooldusaknad (p 9.12) ei kuulu kättesaadavuse arvestusse.
9.8 Süsteem peab tagama andmete varundamise ja taastamise selliselt, et andmekadu ei ületaks maksimaalselt 8 tundi (RPO ≤ 8h). Andmete varundamine peab toimuma automaatselt vähemalt iga 8 tunni järel ning hõlmama kogu rakendust ja sellega seotud anmdeid. Andmete taastamine peab olema võimalik maksimaalselt 8 tunni jooksul alates taastamise vajaduse ilmnemisest (RTO ≤ 8h).
9.9. Tase 1 viga tuleb lahendada maksimaalselt 4 tunni jooksul. Tase 1 vigade korral ei kohaldata punktis 9.5 toodud tööaega; pakkuja peab tagama 24/7 tugiteenuse ja alustama vea kõrvaldamist koheselt sõltumata nädalapäevast või kellaajast.
9.10. Reageerimisaeg on aeg, mille jooksul pakkuja annab hankijale esialgset tagasisidet probleemide uurimise kohta.
9.11. Lahendusaeg on probleemi lahendamise maksimaalne aeg või Tellijale vastuvõetava alternatiivse lahenduse rakendamine ja lõpliku lahenduse tähtaja kokkuleppimine Tellijaga ilma lisakuludeta hankijale.
9.12. Funktsioonide kasutamist häirivate plaaniliste hooldustööde kestus ei tohi ületada 4 tundi (kumulatiivselt) kuus. Teavitamine vähemalt kaks (2) tööpäeva ette.
9.13. Pakkuja esitab eelmise kvartali lõpus järgmisse kvartalisse tooteomaniku, kui tootja, poolt planeeritud tarkvarauuenduste info e-kirja teel lepingus kokku lepitud kontaktisikutele.
9.14. Pakkuja peab teostama tugiteenuse käigus ka korrapäraseid hooldustöid, mis tagavad pakutava tarkvara kasutusteenuse terviku (kaasa arvatud selle juurde kuuluvate andmete ja andmebaaside) toimivuse (korrasoleku, terviklikkuse, jõudluse, turvalisuse jms).
9.15. Pakkuja peab tagama tarkvara käideldavuse ja lahendama pöördumisi vastavalt raamlepingus sätestatud tähtaegadele.
9.16. Teenustaseme puhul loetakse oluliseks lepingu rikkumiseks mh, kui on rohkem kui 1 (üks) "Tase 1" või "Tase 2" viga kvartalis või 2 (kaks) "Tase 3" viga kvartalis eraldi või koos, mis ei ole käesolevas peatükis sätestatud lahendamise aegade jooksul parandatud.
9.17. Järgmisi asjaolusid ei loeta rikkumisteks:
9.17.1. kokkulepitud plaanilised hoolduspausid;
9.17.2. rike, mis on põhjustatud võrguühendusest väljaspool taristu teenuse (IaaS) teenusepakkuja võrku;
9.17.3. seisak, mille on põhjustanud vääramatu jõud.
9.18. Teenustasemete reageerimisaja rikkumiste korral kasutab Hankija tööaja kompenseerimise mudelit ehk tasuta tööaja pakkumist järgnevalt:
9.18.1. Tase 1 rikkumise korral on Hankijal õigus saada kuni 8 tundi tasuta hooldustööd, mida võib kasutada järgmise 30 kalendripäeva jooksul.
9.18.2. Tase 2 rikkumise korral kuni 4 tundi tasuta hooldustööd, mida võib kasutada järgmise 30 kalendripäeva jooksul.
9.18.3. Tase 3 ja tase 4 rikkumise korral kuni 2 tundi tasuta hooldustööd, mida võib kasutada järgmise 30 kalendripäeva jooksul.
9.19. Hankijal on õigus punkti 9.18. kompenseerimise mudel asendada leppetrahviga raamlepingu punktis 6.6 sätestatud määradega.

10. Raamhanke struktuur ja eeldatav ajakava
10.1. Raamleping kehtib 48 kalendrikuud või maksimaalse maksumuse täitumiseni (kohaldub esimene täituv tingimus).
10.2. Tarkvara arenduse struktuur:
10.2.1. Arendusetapid võivad käivituda samaaegselt;
10.2.2. Funktsionaalsusnõuetes (HD Lisa 2) ja mittefunktsionaalsetes nõuetes (HD Lisa 3) on osad arendusnõuded defineeritud kui „kohustuslikud“ ning osad „soovituslikud“.
10.3. Lisaarenduse protsess kohaldub vaid nendele võimekustele, mida kohustuslikes funktsionaalsetes nõuetes ei ole loetletud.
10.4. Ajakava:
10.4.1. LIVE kuupäev on eelduslikult 04.01.2027.
10.5. Pärast iga alametapi LIVE-i pakub pakkuja kaks kalendrinädalat nö hüperhooldust ehk suurendatud järelevalvet LIVE-s tuvastatud esmaste vaegtööde lahenduseks, mille käigus keskendutakse tarkvara stabiilsuse tagamisele, varajaste vigade ja probleemide kiirele lahendamisele ning kasutajate tagasiside integreerimisele süsteemi täiustamiseks.
10.6. Pärast alametapi hüperhoolduse perioodi lõppu hakkab kehtima antud alametapi osas ühe kalendriaastane garantii periood.
10.7. Juhul kui pakkumus sisaldas pakkuja poolt pakutavaid tarkvara litsentse, peab pakkuja võimaldama litsentsiga kaetud tarkvarale ligipääsu alates LIVEst. Vastav leping sõlmitakse enne LIVE ja hakkab kehtima LIVE kuupäevast.

11. Testimine
11.1. Enne töö üleandmist viib Täitja töö nõuetelevastavuse kindlakstegemiseks läbi testid. Testimise nõuded on täpsemalt kirjeldatud dokumendis “Arendusnõuded” Lisa 6?
11.2. Kui töö või mistahes selle osa ei läbi teste, viiakse viivitamatult 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.

12. Dokumentatsioon
12.1. Arenduste teostamisel peab Täitja koostama dokumendi(d)/dokumentatsiooni, millede eesmärgiks on anda selge ja konkreetne ülevaade süsteemi sisust ja realiseeritud arendustest. Dokumentatsioon hoitakse tellija Confluence’is.
12.2. Eraldiseisvaid dokumente üle ei anta vaid Tellija keskkonda kirjutatakse analüüsi jooksvalt projekti käigus.
12.3. Kirjeldused peavad olema kinnitatud Tellija poolt enne arendustöö algust.
12.4. Üle antavad dokumendid peavad sisaldama:
12.4.1. 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;
12.4.2. Vormide (ekraanivormide) kirjeldused;
12.4.3. Kasutuslugude / vormide kasutamise protsesside / tegevuste kirjeldused.
12.5. Infosüsteemi teenuste kirjeldused.
12.6. 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.
12.7. Kirjeldatakse ka füüsilist arhitektuuri, antakse ülevaade kasutatavatest tehnoloogiatest ning vahenditest.
12.8. Täitja sisemiste koosolekute eest, mille töötunde esitatakse Tellijale tasumiseks, peab Täitja koostama ja esitama ülevaatliku memo, mis peab sisaldama vähemalt järgmist infot:
12.8.1. Koosolekul osalenud isikute nimekiri;
12.8.2. Koosoleku eesmärk ja arutatavad teemad;
12.8.3. Koosolekust projektile tekkiv väärus või mõju;
12.8.4. Põhiotsused ja järgmised sammud (kui rakendub);
12.8.5. Koosoleku kuupäev ja kestus.
Memo eesmärk on tagada tööde läbipaistvus ning võimalus hinnata koosoleku asjakohasust projekti täitmise seisukohast. Ilma nõuetekohase memota ei ole Täitjal õigust esitada Tellijale arvet nende töötundide eest.

13. Garantiitingimused
13.1. Täitja garanteerib tööde vastavuse lepingule ja seadusega sätestatud töövõtu tingimustele, tarkvara kirjeldusele ning tellija põhitegevuse tavapärastele ja mõistlikele nõuetele kokkulepitud aja jooksul pärast tööde vastuvõtmist tellija poolt.
13.2. Täitja tagab garantii perioodiks 12 (kaksteist) kuud, mis algab tööde kogumina vastuvõtmisest.
13.3. Garantii korras vea parandamine hõlmab kõigi tarkvara osade, sealhulgas abistava dokumentatsiooni parandamist või muutmist.
13.4. Garantiitöödele tunnitasu ei rakendu.
13.5. Garantii kehtib I ja II etapi raames tehtud töödele.

14. Nõuded projektiplaanile
14.1. Pakkumuse osana esitatakse tarkvara arenduse projektiplaan, mis sisaldab ajakava (tegevuste ajalist kestvust) kõikide funktsionaalsuste loomiseks (Lisa 2 ja 3) ja vajalike tööde läbiviimiseks:
14.1.1 I etapi kohustuslikud nõuded (LIVE 1);
14.1.2 II etapi kohustuslikud nõuded (LIVE 2);
14.1.3 soovituslikud nõuded (realiseeritakse jooksvalt juurutusperioodil ja/või raamlepingu kehtivusajal vastavalt kokkulepitud prioriteetidele)
14.2. Projektiplaanis peab olema selgelt eristatavad tööde etapid ning vajadusel jätku ja/või muud tegevused. Tegevused peavad olema välja toodud nädala täpsusega. Projektiplaan peab olema koostatud arvestusega, et kõik hanke alusdokumentides nimetatud arendusega seotud tegevused, sealhulgas migratsioon, oleks teostatud ja kogu lahendus kasutatav eelduslikult 01.05.2027, millest esimese etapiga LIVE’i minek 04.01.2027.
14.3. Pakkumuses esitatav projektiplaan peab vastama järgmistele tingimustele:
14.3.1. projektiplaanis kirjeldatud tööde läbiviimise tulemusena peab olema saavutatud projekti eesmärk ja soovitud funktsionaalsus;
14.3.2. iga projektiplaani töö kohta peab olema kirjeldatud töö nimetus, töö tegija(te) sh vastutaja roll/nimi, ajaline kestus töötundides või tööpäevades ja tähtaeg vastavalt tööde mahule;
14.3.3. projektiplaanis peavad kajastuma töö tegemiseks vajalikud eeldused/lähteandmed ning töö mõõdetav(ad) tulem(id).
14.3.4. kõik projektiplaanis kirjeldatud tööd peavad olema omavahel loogiliselt seotud;
14.3.5. projektiplaan peab sisaldama varuaega (puhvrit) arvestades riiklike pühade, puhkepäevade, projektimeeskonna puhkustega/vahetustega ja muu taolisega;
14.3.6. Projekti ajakohastamine toimub vaid poolte kirjalikul kokkuleppel.
14.4. Pakkuja peab kirjeldama, kuidas ta kavatseb maandada tarkvara arenduse projekti realiseerimise riske (HD Lisa 4).
14.5. Projektiplaan ja riskide maandamise plaan esitatakse Exceli kujul. Pakkuja võib lisaks pakkumusse lisada projektiplaani Microsoft Project formaadis.

15. Nõuded meeskonnale
15.1. Juhul, kui Täitja ei ole toote omanik, kui tootja, peab Täitja kaasama läbiviidavatesse analüüsi töötubadesse ka toote omaniku, kui tootja esindaja, et tagada:
15.1.1. nõuetele vastavus ja toote funktsionaalne terviklikkus;
15.1.2. funktsionaalsuste ja tehniliste piirangute korrektne tõlgendamine;
15.1.3. süsteemi arhitektuuri ja konfiguratsioonipõhimõtete kinnitamine;
15.1.4. analüüsi tulemuste vastavus tarkvara tegelikele võimalustele;
15.1.5. hilisemate arenduste ja seadistuste valideerimine tootja pädevuse alusel.
15.2. Pakkuja peab raamlepingu täitmiseks komplekteerima piisava suurusega meeskonna, et oleks tagatud vajalik ning asjakohane inimressurss kogu arenduse ja juurutusperioodiks, kuid ka tugi- ja hooldusteenuse osutamiseks ja lisaarenduste tellimiseks.
15.3. Kõik meeskonnaliikmed peavad olema kättesaadavad projekti jooksul.
15.4. Kõik meeskonna rollid peavad olema lepingu kestel kaetud ja kättesaadavad vastavalt lepingus kokkulepitud ulatusele. Kui mõne rolli täitja vahetub, peab Täitja teavitama Tellijat rollis oleva liikme asendamisest kirjalikult vähemalt 5 tööpäeva ette. Rolli ajutine või püsiv katmata jätmine on lubatud üksnes juhul, kui Tellija on selleks andnud eelneva kirjaliku nõusoleku.
15.5. Pakkuja asendab töid teostava isiku viivitamatult Lepingu eseme täitmise seisukohast võrdväärse kvalifikatsiooni ja kogemustega ning hankijale vastuvõetava isikuga, kui nimetatud töid teostav isik osutub Tellija põhjendatud arvamuse kohaselt lepingujärgsete ülesannete täitmiseks ebakompetentseks või ebasobivaks või kui tema lepingujärgsete ülesannete täitmine pidevalt kahjustab raamlepingu korrektset ja õigeaegset täitmist.
15.6. Tellija ei ole kohustatud tasuma Täitja töötajate väljaõppe, sisseelamise ega koolitamisega seotud töötundide eest. Juhul kui Täitja vahetab projekti rollis oleva isiku, peab uus töötaja omandama vajalikud teadmised ja projektiga seonduva info Täitja enda kulul. Tellija ei tasu töötundide eest, mis on seotud:
15.6.1. uue töötaja koolitamise või väljaõppega;
15.6.2. projekti teemadega tutvumisega (sh dokumentatsiooni läbilugemine);
15.6.3. Täitja sisese duubeldamise või varjutamisega koosolekutel (nt olukord, kus uus või noorem konsultant osaleb koosolekul ilma Tellijale lisaväärtust loomata).
Sellised tunnid ei kuulu arveldamisele ja neid ei või Tellijale esitada sõltumata sellest, kas Täitja märgib need sisemiselt projekti tööajaks või mitte.
15.7. Arendusmeeskonna liikmetel peab olema varasem kogemus pakutava lahenduse juurutamisel.
15.8 Meeskonna tööd koordineerib projektijuht, kelle suhtluskeel on eesti keel, sh peavad eesti keelt valdama B2 tasemel spetsialistid, kes on Tellijaga otsesuhtluses.
15.9. Pakkuja kannab kõik nimetatud asendusest tulenevad või sellega kaasnevad kulud.
15.10. Pakkuja meeskonna poolt täidetavad rollid on esitatud alljärgnevalt, kusjuures üks spetsialist ei tohi katta mitte rohkem kui kahte rolli.
15.11. Projektijuht, kes korraldab suhtlust arendusmeeskonna ja hankija kontaktide vahel ning vastutab lepingu igapäevase täitmise eest, sealhulgas:
15.11.1. koostöös tellijaga koostab ja jälgib arenduste teekaarti (sh ajakava, riskid);
15.11.2. korraldab ja juhib arenduste planeerimise ja retroperspektiivi koosolekuid;
15.11.3. korraldab ja juhib projektimeeskonna teisi korralisi koosolekuid;
15.11.4. juhib ja korraldab arendusmeeskonna igapäevatööd;
15.11.5. küsib tellija poolset tagasisidet ja lahendab sealt ülesse kerkinud probleeme;
15.11.6. korraldab tarkvara hooldamise ja toe pakkumise protsesse;
15.11.7. korraldab intsidentide ja probleemide lahendamise vastavalt lepingutingimustele;
15.11.8. korraldab tööde üleandmise ja arveldamise, planeerib tööde üleandmise tellijale ning veendub enne üleandmist nende vastavuses tellija soovidele;
15.11.9. koostab ja esitab tellijale projekti aruandluse ning korraldab infovahetuse tellijaga.
15.11.10. Projektijuhil peab olema vähemalt 3-aastane kogemus tarkvaraprojektide juhtimisel avalikus sektoris või samas mahuklassis erasektoris.
15.12. Vanemarendaja/Arhitekt, kes kooskõlastab kõik suuremad arendustööd ja seisab selle eest, et tarkvara arendatakse vastavalt baastoote loogikale ja arendussuunistele, sealhulgas:
15.12.1. töötab välja koostöös tellijaga tarkvara arhitektuuri (komponendid, andmestruktuurid, algoritmid) ning suhtlusprotokollid teiste süsteemide ja kasutajatega;
15.12.2. vaatab üle suuremad muudatused teenustes ning uut tüüpi teenusesoovid ning liidesed;
15.12.3. vaatab üle muudatused andmemudelis;
15.12.4. otsustab ja kooskõlastab tellijaga kasutusele võetavad tehnoloogiad;
15.12.5. teeb ettepanekuid paremateks lahendusteks tarkvaras;
15.12.6. kirjutab tarkvara koodi ja andmelaadimise tingimused;
15.12.7. teostab koodi ülevaatust.
15.13.6. vanemarendajal/arhitektil peab olema vähemalt 5-aastane kogemus infosüsteemide arhitektuuri kavandamisel ja arendamisel.
15.13. Arendaja, kes teostab vastavalt lähteülesandele ja dokumendihaldussüsteemi (DHS) arendussuunistele kliendispetsiifilised eriarendused, sealhulgas:
15.13.1. hoolitseb selle eest, et tarkvara andmebaas, komponendid ja liidestused erinevate infosüsteemide vahel kõik omavahel hästi töötaksid;
15.13.3. kirjutab tarkvara koodi;
15.13.4. kirjutab automaattestid;
15.13.5. teostab koodi ülevaatust.
15.13.6. Arendajal peab olema vähemalt 2-aastane kogemus infosüsteemide arendamisel.
15.14. Testija/dokumenteerija, kes dokumenteerib nõuetekohaselt teostatud arendused ja testib nende toimimist, sealhulgas:
15.14.1. loob testjuhtumid valminud lahenduste testimiseks;
15.14.2. genereerib vajadusel testandmed loodud lahenduste testimiseks;
15.14.3. testib tarkvara;
15.14.4. loob ja täiendab testlugusid;
15.14.5. loob kasutusjuhendeid;
15.14.6. teostab kasutajate konsulteerimist ja koolitamist;
15.14.7. võib kirjutada kasutajaliidese automaat-teste.
15.14.8. Testijal peab olema vähemalt 2-aastane kogemus infosüsteemide testimise metoodikate ja kvaliteediprotsesside rakendamisel.
15.15. Hankija meeskonda kuuluvad arendusprojekti projektijuht, peakasutajad, IT tooteomanikud, arhitektid, tehnilised konsultandid.
15.16. Juhul, kui Täitja ei ole tooteomanik, kui tootja, siis on Hankijal õigus kaasata tooteomaniku, kui tootja, esindaja olulisemaid projekti etappe ja mahte sõltumatu osapoolne valideerima.

lisa 2 - arendusnõuded.docx

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 1
2. Üldnõuded 1
2.1 Töö- ja koodihaldus 1
2.2. Operatsioonid, lokaalne käivitamine, CI/CD ja release 1
2.3 Platvorm 2
2.4 Koodi kvaliteet ja arendusprotsess 2
2.5 Dokumenteerimine 3
2.6 Haldus 4
2.7 Välised sõltuvused 4
2.8 Muud üldised nõuded 4
3. Frontend nõuded (UX/UI) 4
3.1 Tehnilised 4
3.2 Kasutuskogemus 5
4. Backend nõuded (API/teenused) 6
4.1 Konfiguratsioon ja deploy 6
4.2 API disain ja dokumentatsioon 6
4.3 Töökindlus ja monitooring 6
4.4 Koodistruktuur ja arendus 7
4.5 Integratsioon 7
5. Logimine 7
6. Andmebaasi ja andmetöötluse nõuded 8
6.1 Üldpõhimõtted 8
6.2 Identifikaatorid ja audit 8
6.3 Platvorm ja tööriistad 8
6.4 Turvalisus ja juurdepääs 8
7. Turvanõuded 8
7.1 Üldised põhimõtted 8
7.2 Sessioonid 9
7.3 Lähtekood ja arendusvahendid 9
9. Hooldatavus ja toetatavus 10

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.
◦ 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.
◦ Ä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.
◦ 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:
◦ süsteemi funktsionaalne ja tehniline kirjeldus,
◦ kasutatavad liidesed (API-d, integratsioonid),
◦ perioodilised tööd (schedulerid, batch-protsessid),
◦ arenduskeskkonna seadistamine
◦ andmebaasi struktuuri kirjeldus (tabelid, seosed, migratsioonid),
◦ keskkonnad ja paigaldus
◦ 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:
◦ SPA: npm / yarn / pnpm (lock fail versioonihalduses; build deterministlik).
◦ Java SSR (Server-Side Rendering nt Thymeleaf): Gradle (või Maven) hoiab nii backendi kui frontendi build-i .
◦ PHP SSR: Composer.
◦ 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 kontrollerite kihis.
• 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. Stored procedure 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.
◦ RMK arendajatele antakse ligipääs vajaduspõhiselt töölepingu kehtivuse ajal.
◦ RMK töötajatele antakse ligipääs ainult vajaduse korral ja vaikimisi lugemisõigus.
◦ 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 production keskkonda 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:
◦ 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.
◦ Integratsioonitestid: katavad liideseid ja sõltuvusi(andmebaas, failisüsteem, MQ, REST liidesed jne)
◦ 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 isikuandmete töötlemise nõuded volitatud töötlejale.docx

Lisa 3
RMK ja Hyperintelligent Aliens OÜ
vahelise lepingu nr 1-18/2026/54 juurde

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

(hiliseima digitaalallkirja kuupäev)
1. Üldine
1.1. Riigimetsa Majandamise Keskus (RMK) (edaspidi vastutav töötleja) edastab Hyperintelligent Aliens OÜ (14154480) (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 isikuandmete koosseisu;
2.1.4. töötlemise alused;
2.1.5. andmete säilitustähtajad.

Töötlemise eesmärk
Andmete kategooriad
Andmete koosseis
Töötlemise alused
Säilitustähtajad
Asutuse dokumentide haldamine, säilitamine ja AvTS-st tulenevalt avalikustamisele kuuluva teabe avaldamine
RMK töötajaskond;
koostööpartnerite isikuandmed (teiste asutuste esindajad);
lepingu osapoolte isikuandmed;
klientide isikuandmed;
RMK endiste töötajate isikuandmed;
RMK-ga kirjavahetust pidavate isikute andmed;
RMK töötajatega seotud isikute andmed.
Dokumendi menetlemisega seotud töödeldavate isikuandmete täpne koosseis sõltub menetluse liigist ja dokumendi sisust. Töödeldavad andmed on üldjuhul järgmised:
isikut tuvastavad andmed;
kontaktandmed;
dokumendi menetlemise ja säilitamise andmed (mh esindusõigust või volitust tõendavad andmed, kooskõlastused, otsused);
Organisatsiooni ja rolli andmed (sh kasutajakonto ja juurdepääsuõiguste andmed);
dokumentide sisus sisalduvad muud isikuandmed.
GDPR art6(1)(e) ja GDPR art 6(1)(b)(c) - avalikes huvides oleva ülesande täitmine ja lepingu täitmine või juriidilise kohustuse täitmine
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
Infosüsteemi turvalisuse ja töökindluse tagamine

Tehnilised ja turbeandmed, sh autentimisandmed, logid, intsidentide andmed, varundamise ja taastamisega seotud andmed.

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.

raamleping .pdf

1

RAAMLEPING nr 1-18/2026/54

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

Haljala vald, 45403 Lääne-Virumaa (edaspidi RMK või tellija), keda esindab RMK juhatuse

22.10.2024 otsusega nr 1-32/86 kinnitatud RMK infotehnoloogia arenduste osakonna

põhimääruse alusel RMK infotehnoloogia arenduste osakonna juhataja Annika Brauer, ühelt

poolt

ja

Hyperintelligent Aliens OÜ, registrikoodiga 14154480, asukohaga Tartu maakond, Tartu

linn, Tartu linn, Lai tn 33-1, 51005 (edaspidi täitja), keda esindab põhikirja alusel juhatuse liige

Targo Tennisberg, teiselt poolt,

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 „Dokumendihaldussüsteemi juurutamine,

arendamine ja hooldustööd (edaspidi nimetatud riigihange, viitenumber 305876, DHS 1-

44/3647)“ 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 RMK-le (Hankija) dokumendihaldussüsteemi rakenduse 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. Tugiteenused peavad olema tagatud tööpäevadel kella 08:00 kuni 17:00 ning lähtudes

hanke tehnilises kirjelduses toodud teenustasemetest. Tööpäevadeks loetakse kõiki

nädalapäevi, välja arvatud laupäev, pühapäev ja riigipühad. Tugiteenus peab sisaldama

pakutava lahenduse toimimisega seotud kasutajatuge (tugiisik kõigi lokalisatsioonide

jaoks) ja tarkvarauuendusi (sh versiooniuuendused) kogu raamlepingu kehtivuse aja.

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

lepingu sõlmimise aluseks olevas hankemenetluses.

3.5. 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.6. 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.7. 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

3.8. 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.9. 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.10. Pretensioonid töö tulemi plaanipärase edenemise, teostamise efektiivsuse ja kvaliteedi

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

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

lepingu rikkumiseks.

3.11. 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.12. 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.13. 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. Tugi- ja hooldusteenuseid 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. Arendus- ja analüüsi töid teostatakse etapipõhise arvestusega, mille aluseks on

üleandmise akt. Seejuures tellija kontrollib täitja esitatud akti vastavust tehtud tööle ning

kinnitab või esitab küsimusi/tagasisidet hiljemalt 14 päeva jooksul peale akti esitamist.

4.4. 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.5. 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.6. 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.7. 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

4

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

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.

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

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

6.5.9. lepingujärgsete kohustuste üleandmine kolmandale isikule.

6.5.10. RMK infoturbe nõuetele mittevastavus.

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.

6.7. Teenustasemete reageerimisaja rikkumiste korral kasutab Hankija tööaja

kompenseerimise mudelit ehk tasuta tööaja pakkumist järgnevalt:

6.7.1. Tase 1 rikkumise korral on Hankijal õigus saada kuni 8 tundi tasuta hooldustööd,

mida võib kasutada järgmise 30 kalendripäeva jooksul.

6.7.2. Tase 2 rikkumise korral kuni 4 tundi tasuta hooldustööd, mida võib kasutada

järgmise 30 kalendripäeva jooksul.

6.7.3. Tase 3 ja tase 4 rikkumise korral kuni 2 tundi tasuta hooldustööd, mida võib

kasutada järgmise 30 kalendripäeva jooksul.

6.8. Hankijal on õigus punkti 6.7 kompenseerimise mudel asendada leppetrahviga punktis 6.6

sätestatud määradega.

7. Tasu maksmine

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

7.2. Lepingu maksimaalne kogumaksumus on 500 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;

7

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.

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

8

10.1. Tellija võib tarkvara litsentsid soetada sõltumatult käesolevast hankest, valides litsentside

müüja või tootja vastavalt oma vajadustele ja äranägemisele.

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.

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.

9

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.

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.

10

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

16. Poolte esindajad ja kontaktandmed

16.1 Töövõtja esindaja on , tel , e-post Targo Tennisberg, email: [email protected]., tel

53037167

16.2 Tellija esindajad käesoleva raamlepingu täitmisel on:

16.2.1 punkt 15.1 osas: Annika Brauer, email: [email protected], tel. 53489984

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.

Dokumendiregister	Riigimetsa Majandamise Keskus
Viit	1-18/54
Registreeritud	01.04.2026
Sünkroonitud	17.05.2026
Liik	Leping
Funktsioon	1-18
Sari	Põhitegevusega seotud lepingud
Toimik
Juurdepääsupiirang	Avalik
Adressaat	Hyperintelligent Aliens OÜ
Saabumis/saatmisviis	Hyperintelligent Aliens OÜ
Vastutaja	Infotehnoloogia arenduste osakond
Originaal	Ava uues aknas

Uue dokumendihaldussüsteemi juurutamine, arendus ja hooldustööd

Failid

Digiallkirjad