| Dokumendiregister | Registrite ja Infosüsteemide Keskus |
| Viit | 6-2/25/125 |
| Registreeritud | 15.10.2026 |
| Sünkroonitud | 16.10.2026 |
| Liik | Leping |
| Funktsioon | 4 Finantseerimine ja raamatupidamise arvestus |
| Sari | 4-3 Lepingud juriidiliste isikutega, aktid |
| Toimik | 4-3-1/2026 |
| Juurdepääsupiirang | Avalik |
| Adressaat | |
| Saabumis/saatmisviis | |
| Vastutaja | Katriin Kaptein (Registrite ja Infosüsteemide Keskus, JustDigi teenuste valdkond, Koosloome tiim) |
| Originaal | Ava uues aknas |
| Taotle dokumendi eemaldamist või parandamist |
1 / 31
Koostatud 16.05.2025 14:30:37 https://riigihanked.riik.ee/rhr-web/#/procurement/8546704/general-info
HANKEPASS
Hankepass ehk Euroopa ühtne hankedokument (ESPD) on ettevõtja enda kinnitus, mis on esialgne tõend ametiasutuste või kolmandate isikute poolt väljastatavate tõendite asemel.
Pakkumus:551515
Ettevõtja: AKTSIASELTS HELMES
Roll: peapakkuja
I OSA: HANKE JA HANKIJAGA SEOTUD TEAVE
Teave avaldamise kohta Teate number ELTs:
-
ELT URL:
Riigi ametlik teataja:
291973
Kui Euroopa Liidu Teatajas hankekuulutust avaldatud ei ole või kui selle avaldamist ei nõuta, peab avaliku sektori hankija või võrgustiku sektori hankija ise teabe esitama, et hankemenetlust saaks üheselt identifitseerida (nt viide siseriikliku avaldamise kohta).
Hankija andmed Ametlik nimi:
Keskkonnaministeeriumi Infotehnoloogiakeskus (70009445)
Riik:
Eesti
Hankija aadress:
Teaduspargi tn 8
Hankija veebiaadress:
http://www.kemit.ee
E-posti aadress:
2 / 31
Koostatud 16.05.2025 14:30:37 https://riigihanked.riik.ee/rhr-web/#/procurement/8546704/general-info
Teave hankemenetluse kohta Hanke menetlusliik:
Avatud hankemenetlus
Pealkiri:
TTJA e-teenuste keskkonna TARVIK arendus
Lühikirjeldus:
Leida arenduspartner Tarbijakaitse ja Tehnilise Järelevalve Ameti e-teenuste keskkonna TARVIK tarkvara loomiseks ja hooldusteenuse osutamiseks.
Avaliku sektori hankija või võrgustiku sektori hankija poolt toimikule antud viitenumber (kui on asjakohane):
291973
Hanke liik:
Teenused
Hanke CPV-d: 72200000-7 Tarkvara programmeerimis- ja nõustamisteenused
3 / 31
Koostatud 16.05.2025 14:30:37 https://riigihanked.riik.ee/rhr-web/#/procurement/8546704/general-info
II OSA: ETTEVÕTJAGA SEOTUD TEAVE
A: Teave ettevõtja kohta
Nimi: AKTSIASELTS HELMES
Registrikood: 10364097
Riik: EST
Aadress: Lõõtsa tn 6 Tallinn 11415
Üldine veebileht: http://www.helmes.ee
Kontaktisikud: KERT VALAMAA; ANDRES KALJO; LINDA SASSIAN
Kontaktide e-posti aadressid:[email protected]; [email protected]; [email protected]
Kontaktide telefoninumbrid: +372 5144865; +372 5101712; +372 56609729
Ettevõtte suurus: Keskmise suurusega ettevõte
Töötajate arv: 1090
Käive: 100880780
Valuuta: EUR
Finantsalase võimekuse kirjeldus: Pakkujal on piisavalt käibekapitali antud lepingu täitmiseks.
Tehnilise võimekuse kirjeldus:Pakkuja kinnitab, et omame kõiki töövahendeid, seadmeid ja tehnilist varustust, mis on vajalikud raamlepingu täitmiseks ja meil on olemas vastav kirjalik kokkulepe raamlepingu täitmiseks vajaliku tehnika omandamiseks või kasutusse võtmiseks.
Teostatud tööde kirjeldus: Teostatud tööde kirjeldus on toodud valikukriteeriumite all
Ettevõtja tegevusvaldkond: Infosüsteemide arendus
4 / 31
Koostatud 16.05.2025 14:30:37 https://riigihanked.riik.ee/rhr-web/#/procurement/8546704/general-info
ETTEVÕTJA ON KAITSTUD TÖÖKOHT
Ainult reserveeritud hangete puhul: kas ettevõtja puhul on tegemist kaitstud töökohaga, sotsiaalse ettevõttega või ta täidab lepingut kaitstud tööhõive programmide raames?
Küsimused ettevõtjale: 1. Mis on Teie vastus?
Vastus: Ei 4. Kas see teave on elektrooniliselt kättesaadav?
Vastus: Ei
ETTEVÕTJA ON KANTUD TUNNUSTATUD ETTEVÕTJATE AMETLIKKU NIMEKIRJA
Kui see on asjakohane, siis kas ettevõtja on kantud tunnustatud ettevõtjate ametlikku nimekirja või kas tal on olemas samaväärne tõend (nt riikliku (eel)kvalifitseerimissüsteemi alusel)?
Küsimused ettevõtjale: 1. Mis on Teie vastus?
Vastus: Ei 5. Kas see teave on elektrooniliselt kättesaadav?
Vastus: Ei
HANKEMENETLUSES KOOS OSALEVAD ETTEVÕTJAD
Kas ettevõtja osaleb hankemenetluses koos teistega?
Küsimused ettevõtjale:
Ettevõtja nimi:AKTSIASELTS HELMES
Ettevõtja ID:10364097
Ettevõtja roll:peapakkuja
4. Kas see teave on elektrooniliselt kättesaadav? Vastus: Jah
5. URL Vastus: https://riigihanked.riik.ee
TEAVE TEISTE ÜKSUSTE SUUTLIKKUSELE TOETUMISE KOHTA
Kas ettevõtja toetub teiste üksuste suutlikkusele, et täita esitatud valikukriteeriumid ning eeskirjad (kui neid on)?
Küsimused ettevõtjale: 1. Mis on Teie vastus?
Vastus: Ei 5. Kas see teave on elektrooniliselt kättesaadav?
Vastus: Jah 6. URL
Vastus: https://riigihanked.riik.ee
5 / 31
Koostatud 16.05.2025 14:30:37 https://riigihanked.riik.ee/rhr-web/#/procurement/8546704/general-info
TEAVE NENDE ALLHANKIJATE KOHTA, KELLE NÄITAJATELE ETTEVÕTJA EI TUGINE
Kas ettevõtja kavatseb sõlmida lepingu mis tahes osa kohta allhanke kolmanda isikuga?
Küsimused ettevõtjale: 1. Mis on Teie vastus?
Vastus: Ei 5. Kas see teave on elektrooniliselt kättesaadav?
Vastus: Jah 6. URL
Vastus: https://riigihanked.riik.ee
HANKE OSAD
Hanke osad, mille kohta ettevõtja soovib pakkumuse esitada
Küsimused ettevõtjale: 1. Hanke osa number
Vastus: 2. Kas see teave on elektrooniliselt kättesaadav?
Vastus: Jah 3. URL
Vastus: https://riigihanked.riik.ee
ETTEVÕTJA KINNITUSED MAKSUDE TASUMISE KOHTA
Kas ettevõtja saab esitada tõendi sotsiaalkindlustusmaksete ja maksude tasumise kohta või esitada teabe, mis võimaldaks avaliku sektori hankijal või võrgustiku sektori hankijal saada sellise teabe otse ükskõik millise liikmesriigi tasuta andmebaasist?
Küsimused ettevõtjale: 1. Mis on Teie vastus?
Vastus: Jah 2. Kas see teave on elektrooniliselt kättesaadav?
Vastus: Jah 3. URL
Vastus: https://riigihanked.riik.ee
6 / 31
Koostatud 16.05.2025 14:30:37 https://riigihanked.riik.ee/rhr-web/#/procurement/8546704/general-info
B: Teave ettevõtja esindajate kohta
Eesnimi: Kert
Perekonnanimi: Valamaa
Sünniaeg:
Sünnikoht: Tallinn
Aadress: Lõõtsa 6b
Linn/vald: Tallinn
Postiindeks: 11415
Riik: Eesti
E-post: [email protected]
Telefon: +372 5144865
Vajaduse korral esitage üksikasjalik teave esindamise kohta (selle vormid, ulatus, eesmärk, ...):
Eesnimi: Andres
Perekonnanimi: Kaljo
Sünniaeg:
Sünnikoht:
Aadress:
Linn/vald: Tallinn
Postiindeks: 11415
Riik: Eesti
E-post: [email protected]
Telefon: +372 5101712
Vajaduse korral esitage üksikasjalik teave esindamise kohta (selle vormid, ulatus, eesmärk, ...):
III OSA: KÕRVALDAMISE ALUSED
A: Kõrvalejätmise alused seoses kriminaalasjas tehtud süüdimõistva otsusega
OSALEMINE KURITEGELIKUS ORGANISATSIOONIS
Kas ettevõtja ise või tema haldus-, juht- või järelevalveorgani liige või isik, kellel on volitused seda ettevõtjat esindada, tema nimel otsuseid teha või teda kontrollida, on lõpliku süüdimõistva kohtuotsusega süüdi mõistetud kuritegelikus organisatsioonis osalemise eest kõige rohkem viimase viie aasta jooksul või kehtib süüdimõistvas kohtuotsuses sätestatud kõrvalejäämise kohustus endiselt?
Viide seadusele: RHS § 95 lg 1 p 1 "keda või kelle haldus-, juhtimis- või järelevalveorgani liiget, prokuristi või muud isikut, kellel on volitus seda ettevõtjat esindada, tema nimel otsuseid teha või teda kontrollida, on karistatud kuritegelikus ühenduses osalemise eest". Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.
7 / 31
Koostatud 16.05.2025 14:30:37 https://riigihanked.riik.ee/rhr-web/#/procurement/8546704/general-info
Ettevõtjalt oodatavad vastused:
1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") Vastus: Ei
8. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") Vastus: Jah
9. URL (Url) Vastus: https://riigihanked.riik.ee
11. Väljaandja (Sisestusväli (max pikkus 250 tähemärki)) Vastus: Päring karistusregistrisse riigihangete registri kaudu.
KORRUPTSIOON
Kas ettevõtja ise või tema haldus-, juht- või järelevalveorgani liige või isik, kellel on volitused seda ettevõtjat esindada, tema nimel otsuseid teha või teda kontrollida, on lõpliku süüdimõistva kohtuotsusega süüdi mõistetud korruptsiooni eest kõige rohkem viimase viie aasta jooksul või kehtib süüdimõistvas kohtuotsuses sätestatud kõrvalejäämise kohustus endiselt? See kõrvalejätmise alus hõlmab ka korruptsiooni avaliku sektori hankija (võrgustiku sektori hankija) või ettevõtja riigi õiguses sätestatud määratluses.
Viide seadusele: RHS § 95 lg 1 p 1 ja lg 2 "keda või kelle haldus-, juhtimis- või järelevalveorgani liiget, prokuristi või muud isikut, kellel on volitus seda ettevõtjat esindada, tema nimel otsuseid teha või teda kontrollida, on karistatud aususe kohustuse rikkumise või korruptiivse teo eest". Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.
Ettevõtjalt oodatavad vastused:
1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") Vastus: Ei
8. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") Vastus: Jah
9. URL (Url) Vastus: https://riigihanked.riik.ee
11. Väljaandja (Sisestusväli (max pikkus 250 tähemärki)) Vastus: Päring karistusregistrisse riigihangete registri kaudu.
PETTUS
Kas ettevõtja ise või tema haldus-, juht- või järelevalveorgani liige või isik, kellel on volitused seda ettevõtjat esindada, tema nimel otsuseid teha või teda kontrollida, on lõpliku süüdimõistva kohtuotsusega süüdi mõistetud kelmuse eest kõige rohkem viimase viie aasta jooksul või kehtib süüdimõistvas kohtuotsuses sätestatud kõrvalejäämise kohustus endiselt?
Viide seadusele: RHS § 95 lg 1 p 1 ja lg 2 "keda või kelle haldus-, juhtimis- või järelevalveorgani liiget, prokuristi või muud isikut, kellel on volitus seda ettevõtjat esindada, tema nimel otsuseid teha või teda
8 / 31
Koostatud 16.05.2025 14:30:37 https://riigihanked.riik.ee/rhr-web/#/procurement/8546704/general-info
kontrollida, on karistatud kelmuse eest". Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.
Ettevõtjalt oodatavad vastused:
1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") Vastus: Ei
8. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") Vastus: Jah
9. URL (Url) Vastus: https://riigihanked.riik.ee
11. Väljaandja (Sisestusväli (max pikkus 250 tähemärki)) Vastus: Päring karistusregistrisse riigihangete registri kaudu.
TERRORIAKTI TOIMEPANEK VÕI TERRORISTLIKU TEGEVUSEGA SEOTUD
ÕIGUSRIKKUMISED
Kas ettevõtja ise või tema haldus-, juht- või järelevalveorgani liige või isik, kellel on volitused seda ettevõtjat esindada, tema nimel otsuseid teha või teda kontrollida, on lõpliku süüdimõistva kohtuotsusega süüdi mõistetud terroriakti toimepaneku või terroristliku tegevusega seotud õigusrikkumiste eest kõige rohkem viimase viie aasta jooksul või kehtib süüdimõistvas kohtuotsuses sätestatud kõrvalejäämise kohustus endiselt?
Viide seadusele: RHS § 95 lg 1 p 1 ja lg 2 "keda või kelle haldus-, juhtimis- või järelevalveorgani liiget, prokuristi või muud isikut, kellel on volitus seda ettevõtjat esindada, tema nimel otsuseid teha või teda kontrollida, on karistatud terroriakti toimepaneku või muu terroristliku tegevusega seotud kuriteo või sellele kihutamise, kaasaaitamise või selle katse eest". Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.
Ettevõtjalt oodatavad vastused:
1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") Vastus: Ei
8. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") Vastus: Jah
9. URL (Url) Vastus: https://riigihanked.riik.ee
11. Väljaandja (Sisestusväli (max pikkus 250 tähemärki)) Vastus: Päring karistusregistrisse riigihangete registri kaudu.
9 / 31
Koostatud 16.05.2025 14:30:37 https://riigihanked.riik.ee/rhr-web/#/procurement/8546704/general-info
RAHAPESU VÕI TERRORISMI RAHASTAMINE
Kas ettevõtja ise või tema haldus-, juht- või järelevalveorgani liige või isik, kellel on volitused seda ettevõtjat esindada, tema nimel otsuseid teha või teda kontrollida, on lõpliku süüdimõistva kohtuotsusega süüdi mõistetud rahapesu või terrorismi rahastamise eest kõige rohkem viimase viie aasta jooksul või kehtib süüdimõistvas kohtuotsuses sätestatud kõrvalejäämise kohustus endiselt?
Viide seadusele: RHS § 95 lg 1 p 1 ja lg 2 "keda või kelle haldus-, juhtimis- või järelevalveorgani liiget, prokuristi või muud isikut, kellel on volitus seda ettevõtjat esindada, tema nimel otsuseid teha või teda kontrollida, on karistatud rahapesualase süüteo või terrorismi rahastamise eest". Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.
Ettevõtjalt oodatavad vastused:
1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") Vastus: Ei
8. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") Vastus: Jah
9. URL (Url) Vastus: https://riigihanked.riik.ee
11. Väljaandja (Sisestusväli (max pikkus 250 tähemärki)) Vastus: Päring karistusregistrisse riigihangete registri kaudu.
LASTE TÖÖJÕU KASUTAMINE JA MUUD INIMKAUBANDUSE VORMID
Kas ettevõtja ise või tema haldus-, juht- või järelevalveorgani liige või isik, kellel on volitused seda ettevõtjat esindada, tema nimel otsuseid teha või teda kontrollida, on lõpliku süüdimõistva kohtuotsusega süüdi mõistetud laste tööjõu kasutamise või muude inimkaubanduse vormide eest kõige rohkem viimase viie aasta jooksul või kehtib süüdimõistvas kohtuotsuses sätestatud kõrvalejäämise kohustus endiselt?
Viide seadusele: RHS § 95 lg 1 p 3 ja lg 2 "keda või kelle haldus-, juhtimis- või järelevalveorgani liiget, prokuristi või muud isikut, kellel on volitus seda ettevõtjat esindada, tema nimel otsuseid teha või teda kontrollida, on karistatud laste tööjõu ebaseadusliku kasutamise või inimkaubandusega seotud teo eest". Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.
10 / 31
Koostatud 16.05.2025 14:30:37 https://riigihanked.riik.ee/rhr-web/#/procurement/8546704/general-info
Ettevõtjalt oodatavad vastused:
1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") Vastus: Ei
8. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") Vastus: Jah
9. URL (Url) Vastus: https://riigihanked.riik.ee
11. Väljaandja (Sisestusväli (max pikkus 250 tähemärki)) Vastus: Päring karistusregistrisse riigihangete registri kaudu.
B: Kõrvalejätmise alused seoses maksude või sotsiaalkindlustusmaksete tasumisega
MAKSUDE TASUMINE
Kas ettevõtja on rikkunud oma maksude tasumise kohustusi nii asukohariigis kui ka avaliku sektori hankija või võrgustiku sektori hankija liikmesriigis, kui see erineb asukohariigist?
Viide seadusele: RHS § 95 lg 1 p 4 „kellel on riikliku maksu, makse või keskkonnatasu maksuvõlg maksukorralduse seaduse tähenduses või maksuvõlg /…/ tema asukohariigi õigusaktide kohaselt“
Tingimuse kirjeldus: Piirmäär: 0
Valuuta: EUR
Lisainfo: Maksukorralduse seaduse kohaselt ei väljasta maksuhaldur maksuvõlgade tõendit juhul, kui maksukohustuslasel olev kõikide sama maksuhalduri hallatavate maksude võlg, arvestamata haldusaktiga kindlaksmääramata intressi, on väiksem kui 100 eurot või kui maksuvõla tasumine on ajatatud. Välismaise ettevõtja puhul väljastatakse maksuvõlgade tõend tema asukohariigi õigusaktide kohaselt.
Ettevõtjalt oodatavad vastused:
1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") Vastus: Ei
12. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") Vastus: Jah
13. URL (Url) Vastus: https://riigihanked.riik.ee
15. Väljaandja (Sisestusväli (max pikkus 250 tähemärki)) Vastus: Päring EMTA maksuvõlglaste andmebaasi riigihangete registri kaudu.
SOTSIAALKINDLUSTUSMAKSETE TASUMINE
Kas ettevõtja on rikkunud oma sotsiaalkindlustusmaksete tasumise kohustusi nii asukohariigis kui ka avaliku sektori hankija või võrgustiku sektori hankija liikmesriigis, kui see erineb asukohariigist?
Viide seadusele: RHS § 95 lg 1 p 4 „kellel on riikliku /…/ makse /…/ maksuvõlg maksukorralduse seaduse
11 / 31
Koostatud 16.05.2025 14:30:37 https://riigihanked.riik.ee/rhr-web/#/procurement/8546704/general-info
tähenduses või sotsiaalkindlustusemaksete võlg tema asukohariigi õigusaktide kohaselt
Tingimuse kirjeldus: Piirmäär: 0
Valuuta: EUR
Lisainfo: Maksukorralduse seaduse kohaselt ei väljasta maksuhaldur maksuvõlgade tõendit juhul,kui maksukohustuslasel olev kõikide sama maksuhalduri hallatavate maksude võlg, arvestamata haldusaktiga kindlaksmääramata intressi, on väiksem kui 100 eurot või kui maksuvõla tasumine on ajatatud. Välismaise ettevõtja puhul väljastatakse maksuvõlgade tõend tema asukohariigi õigusaktide kohaselt.
Ettevõtjalt oodatavad vastused:
1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") Vastus: Ei
12. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") Vastus: Jah
13. URL (Url) Vastus: https://riigihanked.riik.ee
15. Väljaandja (Sisestusväli (max pikkus 250 tähemärki)) Vastus: Päring EMTA maksuvõlglaste andmebaasi riigihangete registri kaudu.
C: Kõrvalejätmise alused seoses maksejõuetusega, huvide konfliktiga või ametialaste käitumisreeglite rikkumisega
KESKKONNAÕIGUSE VALDKONNAS KOHALDATAVATE KOHUSTUSTE TÄITMATA
JÄTMINE
Kas ettevõtja on enda teada rikkunud keskkonnaõiguse valdkonnas kohaldatavaid kohustusi?
Viide seadusele: RHS § 95 lg 4 p 2 „kes on rikkunud õigusaktidest või kollektiivlepingust tulenevaid keskkonnaõiguse valdkonnas kohaldatavaid kohustusi“. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.
Ettevõtjalt oodatavad vastused:
1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") Vastus: Ei
5. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") Vastus: Ei
SOTSIAALÕIGUSE VALDKONNAS KOHALDATAVATE KOHUSTUSTE TÄITMATA
JÄTMINE
Kas ettevõtja on enda teada rikkunud sotsiaalõiguse valdkonnas kohaldatavaid kohustusi?
12 / 31
Koostatud 16.05.2025 14:30:37 https://riigihanked.riik.ee/rhr-web/#/procurement/8546704/general-info
Viide seadusele: RHS § 95 lg 4 p 2 „kes on rikkunud õigusaktidest või kollektiivlepingust tulenevaid sotsiaalõiguse valdkonnas kohaldatavaid kohustusi“. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.
Ettevõtjalt oodatavad vastused:
1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") Vastus: Ei
5. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") Vastus: Ei
TÖÖÕIGUSE VALDKONNAS KOHALDATAVATE KOHUSTUSTE TÄITMATA
JÄTMINE
Kas ettevõtja on enda teada rikkunud tööõiguse valdkonnas kohaldatavaid kohustusi?
Viide seadusele: RHS § 95 lg 4 p 2 „kes on rikkunud õigusaktidest või kollektiivlepingust tulenevaid tööõiguse valdkonnas kohaldatavaid kohustusi“. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.
Ettevõtjalt oodatavad vastused:
1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") Vastus: Ei
5. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") Vastus: Ei
PANKROT
Kas ettevõtja on pankrotis?
Viide seadusele: RHS § 95 lg 4 p 3 „kes on pankrotis, välja arvatud asjade ostmisel RHS § 49 lõikes 4 sätestatud juhul ja tingimustel“. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.
13 / 31
Koostatud 16.05.2025 14:30:37 https://riigihanked.riik.ee/rhr-web/#/procurement/8546704/general-info
Ettevõtjalt oodatavad vastused:
1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") Vastus: Ei
4. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") Vastus: Jah
5. URL (Url) Vastus: https://riigihanked.riik.ee
7. Väljaandja (Sisestusväli (max pikkus 250 tähemärki)) Vastus: Päring Äriregistrisse riigihangete registri kaudu.
MAKSEJÕUETUS
Kas ettevõtja suhtes on algatatud maksejõuetus- või likvideerimismenetlus?
Viide seadusele: RHS § 95 lg 4 p 3 „kes on likvideerimisel või kelle suhtes on algatatud pankrotimenetlus, välja arvatud asjade ostmisel RHS § 49 lõikes 4 sätestatud juhul ja tingimustel“. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.
Ettevõtjalt oodatavad vastused:
1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") Vastus: Ei
4. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") Vastus: Jah
5. URL (Url) Vastus: https://www.ametlikudteadaanded.ee/
7. Väljaandja (Sisestusväli (max pikkus 250 tähemärki)) Vastus: Päringut saab käsitsi teha veebilehel Ametlikud Teadaanded.
KOKKULEPE VÕLAUSALDAJATEGA
Kas ettevõtja on sõlminud kokkuleppe võlausaldajatega?
Viide seadusele: RHS § 95 lg 4 p 3 „kes on muus sellesarnases olukorras tema asukohamaa õigusaktide kohaselt, välja arvatud asjade ostmisel RHS § 49 lõikes 4 sätestatud juhul ja tingimustel“. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.
14 / 31
Koostatud 16.05.2025 14:30:37 https://riigihanked.riik.ee/rhr-web/#/procurement/8546704/general-info
Ettevõtjalt oodatavad vastused:
1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") Vastus: Ei
4. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") Vastus: Ei
SISERIIKLIKU ÕIGUSE KOHANE SAMALAADNE OLUKORD, NÄITEKS PANKROT
Kas ettevõtja on siseriiklike õigusnormide alusel toimuva samalaadse menetluse tõttu samalaadses olukorras?
Viide seadusele: RHS § 95 lg 4 p 3 „kes on muus sellesarnases olukorras tema asukohamaa õigusaktide kohaselt“, välja arvatud asjade ostmisel RHS § 49 lõikes 4 sätestatud juhul ja tingimustel. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.
Ettevõtjalt oodatavad vastused:
1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") Vastus: Ei
4. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") Vastus: Jah
5. URL (Url) Vastus: https://riigihanked.riik.ee
7. Väljaandja (Sisestusväli (max pikkus 250 tähemärki)) Vastus: Päring Äriregistrisse riigihangete registri kaudu.
VARA HALDAB LIKVIDEERIJA
Kas ettevõtja vara haldab likvideerija või kohus?
Viide seadusele: RHS § 95 lg 4 p 3 „kes on pankrotis, likvideerimisel või kelle suhtes on algatatud pankrotimenetlus või kes on muus sellesarnases olukorras tema asukohamaa õigusaktide kohaselt, välja arvatud asjade ostmisel RHS § 49 lõikes 4 sätestatud juhul ja tingimustel“. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.
15 / 31
Koostatud 16.05.2025 14:30:37 https://riigihanked.riik.ee/rhr-web/#/procurement/8546704/general-info
Ettevõtjalt oodatavad vastused:
1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") Vastus: Ei
4. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") Vastus: Jah
5. URL (Url) Vastus: https://riigihanked.riik.ee
7. Väljaandja (Sisestusväli (max pikkus 250 tähemärki)) Vastus: Päring Äriregistrisse riigihangete registri kaudu.
ÄRITEGEVUS ON PEATATUD
Kas ettevõtja äritegevus on peatatud?
Viide seadusele: RHS § 95 lg 4 p 3 „kelle äritegevus on peatatud, välja arvatud asjade ostmisel RHS § 49 lõikes 4 sätestatud juhul ja tingimustel“. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.
Ettevõtjalt oodatavad vastused:
1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") Vastus: Ei
4. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") Vastus: Jah
5. URL (Url) Vastus: https://ariregister.rik.ee/
7. Väljaandja (Sisestusväli (max pikkus 250 tähemärki)) Vastus: https://ariregister.rik.ee/
SÜÜDI AMETIALASTE KÄITUMISREEGLITE OLULISES RIKKUMISES
Kas ettevõtja on süüdi ametialaste käitumisreeglite olulises rikkumises? Vt siseriiklikud õigusaktid, asjaomane teade või hankedokumendid, kui see on asjakohane.
Viide seadusele: RHS § 95 lg 4 p 4 „kes on raskelt eksinud ametialaste käitumisreeglite vastu ja see muudab tema aususe küsitavaks“. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.
16 / 31
Koostatud 16.05.2025 14:30:37 https://riigihanked.riik.ee/rhr-web/#/procurement/8546704/general-info
Ettevõtjalt oodatavad vastused:
1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") Vastus: Ei
5. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") Vastus: Ei
KONKURENTSI MOONUTAMISE EESMÄRGIL TEISTE ETTEVÕTJATEGA
SÕLMITUD KOKKULEPPED
Kas ettevõtja on teiste ettevõtjatega sõlminud kokkuleppeid, mille eesmärk on moonutada konkurentsi?
Viide seadusele: RHS § 95 lg 4 p 5 „konkurentsi kahjustava kokkuleppe, ettevõtjate ühenduse otsuse või kooskõlastatud tegevuse tõttu“. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.
Ettevõtjalt oodatavad vastused:
1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") Vastus: Ei
5. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") Vastus: Ei
HANKEMENETLUSES OSALEMISEGA KAASNEV HUVIDE KONFLIKT
Kas ettevõtja on teadlik hankemenetluses osalemisega kaasnevast mis tahes huvide konfliktist siseriikliku õiguse, asjakohase teatise või hankedokumentide kohaselt?
Viide seadusele: RHS § 95 lg 4 p 6 „kui huvide konflikti ei ole muude vahenditega võimalik vältida“. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.
Ettevõtjalt oodatavad vastused:
1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") Vastus: Ei
3. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") Vastus: Ei
17 / 31
Koostatud 16.05.2025 14:30:37 https://riigihanked.riik.ee/rhr-web/#/procurement/8546704/general-info
OTSENE VÕI KAUDNE OSALEMINE KÄESOLEVA HANKEMENETLUSE
ETTEVALMISTAMISEL
Kas ettevõtja või temaga seotud ettevõtja on nõustanud avaliku sektori hankijat või võrgustiku sektori hankijat hankemenetluse ettevalmistamisel või olnud muul viisil seotud hankemenetluse ettevalmistamisega?
Viide seadusele: RHS § 95 lg 4 p 7 „kelle pakkumuse või taotluse koostamisel on osalenud isik, kes on osalenud sama riigihanke ettevalmistamisel või on muul viisil hankijaga seotud, ja sellele isikule seetõttu teadaolev info annab talle eelise teiste riigihankes osalejate eest ning sellest tingitud konkurentsi moonutamist ei ole muude vahendistega võimalik vältida“. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.
Ettevõtjalt oodatavad vastused:
1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") Vastus: Ei
3. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") Vastus: Ei
ENNETÄHTAEGNE LÕPETAMINE, KAHJUTASU VÕI VÕRRELDAVAD
SANKTSIOONID
Kas ettevõtja on kogenud, et varasem riigihankeleping või võrgustiku sektori hankijaga sõlmitud varasem hankeleping või varasem kontsessioonileping on lõpetatud enneaegselt, või on määratud kahjutasu või sellega võrreldavad sanktsioonid seoses kõnealuse varasema lepinguga?
Viide seadusele: RHS § 95 lg 4 p 8 „kes on oluliselt või pidevalt rikkunud eelnevalt sõlmitud hankelepingu olulist tingimust või hankelepingute olulisi tingimusi nii, et rikkumise tulemusena on lepingust taganetud või leping üles öeldud, hinda alandatud, hüvitatud kahju või makstud leppetrahvi". Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud. Alates 1.09.2017 alustatud hangete tulemusena sõlmitud riigihankelepingute kohta leiab infot riigihangete registrist.
Ettevõtjalt oodatavad vastused:
1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") Vastus: Ei
5. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") Vastus: Ei
18 / 31
Koostatud 16.05.2025 14:30:37 https://riigihanked.riik.ee/rhr-web/#/procurement/8546704/general-info
SÜÜDI VALEANDMETE ESITAMISES, ON JÄTNUD TEAVET ESITAMATA, EI SUUDA
NÕUTUD DOKUMENTE ESITADA, HANKINUD KÄESOLEVA MENETLUSE KOHTA
KONFIDENTSIAALSET TEAVET
Kas ettevõtja on olnud ühes järgmistest olukordadest: a) ta on kõrvalejätmise aluste puudumise või valikukriteeriumide täitmise kontrollimiseks nõutava teabe esitamisel esitanud valeandmeid; b) ta on jätnud sellist teavet esitamata; c) ta ei ole esitanud viivitamata avaliku sektori hankija või võrgustiku sektori hankija nõutud täiendavad dokumendid, ja d) ta on tegutsenud eesmärgiga mõjutada lubamatul viisil avaliku sektori hankija või võrgustiku sektori hankija otsustusprotsessi, et saada konfidentsiaalseid andmeid, mis võivad anda talle põhjendamatu eelise hankemenetluses, või hooletusest esitanud eksitavat teavet, mis võib oluliselt mõjutada kõrvalejätmise, valiku või lepingu hindamise kohta tehtavaid otsuseid?
Viide seadusele: RHS § 95 lg 4 p 9 „kes on esitanud valeandmeid käesolevas paragrahvis sätestatud või RHS §- des 98-101 sätestatu alusel hankija kehtestatud kvalifitseerimise tingimustele vastavuse kohta“; RHS § 95 lg 4 p 9 „kes on jätnud andmed käesolevas paragrahvis sätestatud või käesoleva seaduse §-des 98-101 sätestatu alusel hankija kehtestatud kvalifitseerimise tingimustele vastavuse kohta esitamata“; RHS § 95 lg 4 p 9 „kes on jätnud käesoleva seaduse § 104 lõigete 7 ja 8 alusel hankija nõutud täiendavad dokumendid esitamata“; RHS § 95 lg 4 p 10 „kes on tegutsenud eesmärgiga mõjutada hankijat või esitanud hooletusest eksitavat teavet, mis on võinud mõjutada hankija otsuseid riigihankes, või on tegutsenud eesmärgiga saada konfidentsiaalset teavet, mis on võinud anda talle põhjendamatu eelise teiste riigihankes osalejate ees“. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.
Ettevõtjalt oodatavad vastused:
1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") Vastus: Ei
2. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") Vastus: Ei
D: Ainult siseriiklikest õigusaktidest tulenevad kõrvalejätmise alused
AINULT SISERIIKLIKEST ÕIGUSAKTIDEST TULENEVAD KÕRVALEJÄTMISE
ALUSED: SEADUSLIKU ALUSETA VIIBIVALE VÄLISMAALASELE TÖÖTAMISE
VÕIMALDAMISE EEST
Kas ettevõtja on rikkunud RHS § 95 lg 1 p-st 2 tuleneva kõrvalejätmise alusega seotud kohustusi?
Viide seadusele: RHS § 95 lg 1 p 2 „keda või kelle haldus-, juhtimis- või järelevalveorgani liiget, prokuristi või muud isikut, kellel on volitus seda ettevõtjat esindada, tema nimel otsuseid teha või teda kontrollida, on karistatud riigis ilma seadusliku aluseta viibivale välismaalasele töötamise võimaldamise või välismaalase Eestis töötamise tingimuste rikkumise võimaldamise, sealhulgas seaduses sätestatud töötasu määrast väiksema töötasu maksmise eest“. Kohustuslik kõrvaldamise
19 / 31
Koostatud 16.05.2025 14:30:37 https://riigihanked.riik.ee/rhr-web/#/procurement/8546704/general-info
alus. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.
Ettevõtjalt oodatavad vastused:
1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") Vastus: Ei
2. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") Vastus: Jah
3. URL (Url) Vastus: https://riigihanked.riik.ee
5. Väljaandja (Sisestusväli (max pikkus 250 tähemärki)) Vastus:Välismaalasele töötamise võimaldamine, maksualased süüteod, kohalik maks Tallinna
hankijatele päringuga RHRist. Rahvusvahelised sanktsioonid https://www.politsei.ee/et/rahapesu/
AINULT SISERIIKLIKEST ÕIGUSAKTIDEST TULENEVAD KÕRVALEJÄTMISE
ALUSED: RAHVUSVAHELISE SANKTSIOONI SUBJEKT
Kas ettevõtja on rikkunud RHS § 95 lg 1 p-st 5 tuleneva kõrvalejätmise alusega seotud kohustusi?
Viide seadusele: RHS § 95 lg 1 p 5. Kellega hankelepingu sõlmimine rikuks rahvusvahelist või Vabariigi Valitsuse sanktsiooni rahvusvahelise sanktsiooni seaduse tähenduses. Hankija kontrollib käesoleva seaduse § 95 lõike 1 punktis 5 sätestatud kõrvaldamise alust pakkuja või taotleja kinnituse alusel. Hankija võib põhjendatud kahtluse korral nõuda pakkujalt või taotlejalt täiendavate andmete või tõendite esitamist, mis võimaldavad kõrvaldamise alust kontrollida. (RHS § 96 lg 2.1).
Ettevõtjalt oodatavad vastused:
1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") Vastus: Ei
2. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") Vastus: Jah
3. URL (Url) Vastus: https://riigihanked.riik.ee
5. Väljaandja (Sisestusväli (max pikkus 250 tähemärki)) Vastus:Välismaalasele töötamise võimaldamine, maksualased süüteod, kohalik maks Tallinna
hankijatele päringuga RHRist. Rahvusvahelised sanktsioonid https://www.politsei.ee/et/rahapesu/
AINULT SISERIIKLIKEST ÕIGUSAKTIDEST TULENEVAD KÕRVALEJÄTMISE
ALUSED: KARISTATUD MAKSUALASTE SÜÜTEGUDE EEST
Kas ettevõtja on rikkunud RHS § 95 lg 4 p-st 11 tuleneva kõrvalejätmise alusega seotud kohustusi?
20 / 31
Koostatud 16.05.2025 14:30:37 https://riigihanked.riik.ee/rhr-web/#/procurement/8546704/general-info
Viide seadusele: RHS § 95 lg 4 p 11 „keda või kelle haldus-, juhtimis- või järelevalveorgani liiget või muud seaduslikku esindajat on karistatud maksualaste süütegude eest“. Vabatahtlik kõrvaldamise alus. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.
Ettevõtjalt oodatavad vastused:
1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") Vastus: Ei
2. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") Vastus: Jah
3. URL (Url) Vastus: https://riigihanked.riik.ee
5. Väljaandja (Sisestusväli (max pikkus 250 tähemärki)) Vastus:Välismaalasele töötamise võimaldamine, maksualased süüteod, kohalik maks Tallinna
hankijatele päringuga RHRist. Rahvusvahelised sanktsioonid https://www.politsei.ee/et/rahapesu/
IV OSA: KVALIFITSEERIMISTINGIMUSED
B: Majanduslik ja finantsseisund
KONKREETNE AASTAKÄIVE
Ettevõtja konkreetne aastakäive lepinguga hõlmatud valdkonnas on asjaomases teates, hankedokumentides või hankepassis nõutud majandusaastate jooksul järgmine:
Viide seadusele: RHS § 100 lg 1 p 4 „andmed pakkuja või taotleja netokäibe kohta hankelepinguga seotud valdkonnas või selle esemele vastavas osas kuni viimase kolme riigihanke algamise ajaks lõppenud majandusaasta jooksul, sõltuvalt pakkuja või taotleja asutamise või äritegevuse alguse kuupäevast“
Tingimuse selgitus: 1.1. Pakkuja kolme viimase auditeeritud (kui on kohaldatav) majandusaasta netokäive IT- süsteemide arenduse tegevusalal peab riigihanke algamise ajaks olema vähemalt 6 000 000 eurot igal aastal. 1.2. Pakkuja esitab andmed hankepassis. Pakkuja esitab hankija nõudmisel kolme viimase riigihanke algamise ajaks lõppenud majandusaasta aruande väljavõtted, millest selguvad pakkuja viimase kahe riigihanke algamise ajaks lõppenud majandusaasta netokäibed. Juriidilisest isikust Eestis registreeritud pakkuja ei ole kohustatud esitama majandusaastate aruannete väljavõtteid, kui andmed või dokumendid on hankijale andmekogust avalikult kättesaadavad. 1.3. Ühispakkujad võivad oma majandusliku ja finantsseisundi tõendamiseks tugineda teiste ühispakkujate vahenditele (RHS § 103 lg 4). 1.4. Kui pakkuja soovib tõendada oma vastavust majanduslikule ja finantsseisundile esitatud nõuetele teise isiku vahendite alusel, esitab pakkuja hankepassis andmed tuginetava isiku kohta. Teine isik, kelle netokäibele tugineti vastutab koos pakkujaga solidaarselt hankelepingu selle osa täitmise eest, mille suhtes tema vahenditele tugineti. Kui pakkuja soovib tõendada enda vastavust netokäibele esitatud nõuetele teise isiku vahendite alusel, peab pakkuja esitama hankepassi ka selle isiku kohta, kelle vahenditele ta tugineb.
21 / 31
Koostatud 16.05.2025 14:30:37 https://riigihanked.riik.ee/rhr-web/#/procurement/8546704/general-info
Tingimuse kirjeldus: Majandusaastate arv: 3
Miinimumnõue: 6000000
Valuuta: EUR
CPV-d: Tarkvara programmeerimis- ja nõustamisteenused
Tegevusvaldkond: Tarkvara programmeerimis- ja nõustamisteenused
Ettevõtjalt oodatavad vastused:
1. Ajavahemik (Periood) Vastus: 01.01.2023 - 31.12.2023
2. Käive (Summa) Vastus: 100880780
3. Valuuta (Vääring) Vastus: EUR
4. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") Vastus: Ei
1. Ajavahemik (Periood) Vastus: 01.01.2022 - 31.12.2022
2. Käive (Summa) Vastus: 91612748
3. Valuuta (Vääring) Vastus: EUR
4. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") Vastus: Ei
1. Ajavahemik (Periood) Vastus: 01.01.2021 - 31.12.2021
2. Käive (Summa) Vastus: 64075775
3. Valuuta (Vääring) Vastus: EUR
4. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") Vastus: Ei
C: Tehniline ja kutsealane suutlikkus
TEENUSLEPINGUTE PUHUL: TÄPSUSTATUD LIIKI TEENUSTE OSUTAMINE
Ainult teenuste riigihankelepingute puhul: "nimekiri hankija kindlaksmääratud tunnustele vastavate teenuste osutamise lepingutest, mis on täidetud riigihanke algamisele eelneva 36 kuu jooksul, koos teabega nende maksumuse, kuupäevade ja teiste lepingupoolte kohta." Avaliku sektori hankijad võivad võtta arvesse rohkem kui kolme aasta vanuseid kogemusi.
Viide seadusele: RHS § 101 lg 1 p 2 „nimekiri hankija kindlaks määratud tunnustele vastavate teenuste osutamise lepingutest, mis on täidetud riigihanke algamisele eelneva 36 kuu jooksul, koos teabega nende maksumuse, kuupäevade ja teiste lepingupoolte kohta“
22 / 31
Koostatud 16.05.2025 14:30:37 https://riigihanked.riik.ee/rhr-web/#/procurement/8546704/general-info
RHS § 101 lg 2 „hankija võib piisava konkurentsi tagamiseks arvesse võtta andmeid rohkem kui 36 kuu eest täidetud teenuste osutamise lepingute kohta“
Tingimuse selgitus: Tarkvaraarenduse leping 2.1.1. Pakkuja peab alates hanke avaldamisest eelneva 36 kuu jooksul olema nõuetekohaselt täitnud vähemalt ühe tarkvaraarenduse lepingu (sisaldab vähemalt äri- ja süsteemianalüüsi, infosüsteemi arendamist ning testimist), mille maksumus peab olema vähemalt 1 500 000 eurot ilma käibemaksuta. 2.1.2. Täidetuks loetakse leping, mille täitmise tähtaeg on saabunud ning mille kohaselt teostatud tööd on tellijale üle antud ja tellija poolt vastu võetud. Pakkuja esitab hankepassis teabe eelnimetatud lepingu maksumuse, kuupäevade, töö nimetuse või sisu ja teiste lepingupoolte kohta, samuti riigihanke viitenumbri juhul, kui on tegemist täidetud riigihanke lepinguga. 2.1.3. Hankijal on õigus kontrollida esitatud lepingu andmete õigsust. Juhul, kui esitatud lepingu andmeid pole Hankijal võimalik kontrollida, siis antud lepingut kvalifitseerimisel ei arvestata.
23 / 31
Koostatud 16.05.2025 14:30:37 https://riigihanked.riik.ee/rhr-web/#/procurement/8546704/general-info
Tingimuse kirjeldus: Minimaalne teostatud tööde arv: 1
Kirjeldus: Pakkuja peab alates hanke avaldamisest eelneva 36 kuu jooksul olema nõuetekohaselt täitnud vähemalt ühe tarkvaraarenduse lepingu (sisaldab vähemalt äri- ja süsteemianalüüsi, infosüsteemi arendamist ning testimist), mille maksumus peab olema vähemalt 1 500 000 eurot ilma käibemaksuta.
Ettevõtjalt oodatavad vastused:
1. Kirjeldus (Suur sisestusala (max pikkus 4000 tähemärki)) Vastus:Piletilevi müügiplatvormi arendus- ja hooldustööd Piletilevi core-infosüsteem, mis
võimaldab promootoritel ja teistel üritustekorraldajatel panna Piletilevi platvormile ja/või oma keskkonda üles ürituste teave ning müüa erinevates hinnagruppides pileteid nii ilma istekohata kui ka erinevate saaliplaanide alusel müüdavatele istekohtadele. Jälgida müügi statistikat ning arveldust. Rakendus on kasutusel 4 riigis, lähiajal 7+ riigis. Viimase 36 kuu jooksul tähtajaks teostatud ja nõuetekohaselt üle antud tööde maht ületab 4 000 000,00€. 2. Kogusumma (Summa)
Vastus: 5000000 3. Valuuta (Vääring)
Vastus: EUR 4. Ettevõtja vastutusala (Suur sisestusala (max pikkus 4000 tähemärki))
Vastus:Peatöövõtja: projektijuhtimine, äriprotsesside disain, ärianalüüs, prototüüpimine, süsteemianalüüs, süsteemi arhitektuuri loomine, arendus, testimine ja juurutamine. Projektis on viimase 36 kuu jooksul tähtajaks teostatud tööde maht üle 4 000 000,00€ 5. Summa (Summa)
Vastus: 4000000 6. Valuuta (Vääring)
Vastus: EUR 7. Ajavahemik (Periood)
Vastus: 01.08.2018 - 30.04.2025 8. Kas info on konfidentsiaalne? (Raadionupp valikutega "Jah/Ei")
Vastus: Jah
9. Tellija nimi (Sisestusväli (max pikkus 250 tähemärki)) Vastus: AS Piletilevi Group
10. Kontaktisiku nimi (Sisestusväli (max pikkus 250 tähemärki)) Vastus: Jaanus Beilmann
11. E-mail (Sisestusväli (max pikkus 250 tähemärki)) Vastus: [email protected]
13. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") Vastus: Ei
1. Kirjeldus (Suur sisestusala (max pikkus 4000 tähemärki)) Vastus: Telia Norra - Telia Norra Point of Sales süsteemi arendus- ja hooldustööd
2. Kogusumma (Summa) Vastus: 3300000
3. Valuuta (Vääring) Vastus: EUR
4. Ettevõtja vastutusala (Suur sisestusala (max pikkus 4000 tähemärki)) Vastus:Peatöövõtja: Telia Norra füüsiliste poodide müügi- ja laosüsteemi arenduste planeerimine,
äri- ja süsteemi analüüs, arendus ja testimine. Lepingus viimase 36 kuu jooksul vastuvõetud (tähtajaks
24 / 31
Koostatud 16.05.2025 14:30:37 https://riigihanked.riik.ee/rhr-web/#/procurement/8546704/general-info
lõpetatud) tööde maht ületab 2 300 000,00€ 5. Summa (Summa)
Vastus: 2300000 6. Valuuta (Vääring)
Vastus: EUR 7. Ajavahemik (Periood)
Vastus: 01.10.2018 - 30.04.2025 8. Kas info on konfidentsiaalne? (Raadionupp valikutega "Jah/Ei")
Vastus: Jah
9. Tellija nimi (Sisestusväli (max pikkus 250 tähemärki)) Vastus: Telia Norge
10. Kontaktisiku nimi (Sisestusväli (max pikkus 250 tähemärki)) Vastus: Björn Melling
11. E-mail (Sisestusväli (max pikkus 250 tähemärki)) Vastus: [email protected]
13. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") Vastus: Ei
1. Kirjeldus (Suur sisestusala (max pikkus 4000 tähemärki)) Vastus: Telia Rootsi - Telia grupi DevOps tööd CeSIM/WebSheet/Electron platvormidele
2. Kogusumma (Summa) Vastus: 3200000
3. Valuuta (Vääring) Vastus: EUR
4. Ettevõtja vastutusala (Suur sisestusala (max pikkus 4000 tähemärki)) Vastus:Peatöövõtja: Telia Grupi eSIM tehnoloogiat toetavate infosüsteemide äri ja süsteemi
analüüs, arendus, testimine ja hooldus. Lepingus viimase 36 kuu jooksul vastuvõetud (tähtajaks lõpetatud) tööde maht ületab 2 100 000,00€ 5. Summa (Summa)
Vastus: 2100000 6. Valuuta (Vääring)
Vastus: EUR 7. Ajavahemik (Periood)
Vastus: 01.01.2021 - 30.04.2025 8. Kas info on konfidentsiaalne? (Raadionupp valikutega "Jah/Ei")
Vastus: Jah
9. Tellija nimi (Sisestusväli (max pikkus 250 tähemärki)) Vastus: Telia Sverige
10. Kontaktisiku nimi (Sisestusväli (max pikkus 250 tähemärki)) Vastus: Jaana Honkonen
11. E-mail (Sisestusväli (max pikkus 250 tähemärki)) Vastus: [email protected]
13. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") Vastus: Ei
1. Kirjeldus (Suur sisestusala (max pikkus 4000 tähemärki))
25 / 31
Koostatud 16.05.2025 14:30:37 https://riigihanked.riik.ee/rhr-web/#/procurement/8546704/general-info
Vastus: Eesti Töötukassa E-töötukassa arendus- ja hooldustööd 2. Kogusumma (Summa)
Vastus: 6237000 3. Valuuta (Vääring)
Vastus: EUR 4. Ettevõtja vastutusala (Suur sisestusala (max pikkus 4000 tähemärki))
Vastus:Peatöövõtja: projektijuhtimine, äriprotsesside disain, ärianalüüs, prototüüpimine, süsteemianalüüs, süsteemi arhitektuuri loomine, arendus, testimine ja juurutamine. 5. Summa (Summa)
Vastus: 6236998.23 6. Valuuta (Vääring)
Vastus: EUR 7. Ajavahemik (Periood)
Vastus: 03.12.2018 - 17.12.2023 8. Kas info on konfidentsiaalne? (Raadionupp valikutega "Jah/Ei")
Vastus: Ei
9. Tellija nimi (Sisestusväli (max pikkus 250 tähemärki)) Vastus: Eesti Töötukassa
10. Kontaktisiku nimi (Sisestusväli (max pikkus 250 tähemärki)) Vastus: Oliver Närep
11. E-mail (Sisestusväli (max pikkus 250 tähemärki)) Vastus: [email protected]
13. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") Vastus: Jah
14. URL (Url) Vastus: https://riigihanked.riik.ee
15. Kood (Sisestusväli (max pikkus 250 tähemärki)) Vastus: 200183
16. Väljaandja (Sisestusväli (max pikkus 250 tähemärki)) Vastus: Riigihankelepingute andmed on kättesaadavad riigihangete registrist.
1. Kirjeldus (Suur sisestusala (max pikkus 4000 tähemärki)) Vastus: Tervise ja Heaolu Infosüsteemide Keskus SKAIS Väikearendused, RFK, LAVA, LSST
2. Kogusumma (Summa) Vastus: 8000000
3. Valuuta (Vääring) Vastus: EUR
4. Ettevõtja vastutusala (Suur sisestusala (max pikkus 4000 tähemärki)) Vastus:Oleme lepingu alt teostanud töid, mille sees on analüüsid (äri ja süsteemi), arendus,
testimine, arhitektuuri konsepti loomine. Lepingus kokku arveldatud 5 000 000,00€, viimase 36 kuu jooksul vastuvõetud (tähtajaks lõpetatud) tööde maht ületab 1 500 000,00€ 5. Summa (Summa)
Vastus: 5000000 6. Valuuta (Vääring)
Vastus: EUR 7. Ajavahemik (Periood)
Vastus: 17.07.2020 - 16.07.2024 8. Kas info on konfidentsiaalne? (Raadionupp valikutega "Jah/Ei")
Vastus: Ei
26 / 31
Koostatud 16.05.2025 14:30:37 https://riigihanked.riik.ee/rhr-web/#/procurement/8546704/general-info
9. Tellija nimi (Sisestusväli (max pikkus 250 tähemärki)) Vastus: TEHIK
10. Kontaktisiku nimi (Sisestusväli (max pikkus 250 tähemärki)) Vastus: Epp Laanepõld
11. E-mail (Sisestusväli (max pikkus 250 tähemärki)) Vastus: [email protected]
13. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") Vastus: Jah
14. URL (Url) Vastus: https://riigihanked.riik.ee
15. Kood (Sisestusväli (max pikkus 250 tähemärki)) Vastus: 221861
16. Väljaandja (Sisestusväli (max pikkus 250 tähemärki)) Vastus: Riigihankelepingute andmed on kättesaadavad riigihangete registrist.
1. Kirjeldus (Suur sisestusala (max pikkus 4000 tähemärki)) Vastus:Axell Claims Credit Life portaal Kindlustusplatvorm, mida kasutavad kliendid, agendid,
haldusosakonnad, meditsiiniosakonnad, kahjukäsitlejad jne. 2. Kogusumma (Summa)
Vastus: 3500000 3. Valuuta (Vääring)
Vastus: EUR 4. Ettevõtja vastutusala (Suur sisestusala (max pikkus 4000 tähemärki))
Vastus:Peatöövõtja: projektijuhtimine, äriprotsesside disain, ärianalüüs, prototüüpimine, süsteemianalüüs, süsteemi arhitektuuri loomine, arendus, testimine ja juurutamine. Lepingu raames viimase 36 kuu jooksul tähtajaks täidetud teenuste maht ületab 1 500 000,00 € 5. Summa (Summa)
Vastus: 3500000 6. Valuuta (Vääring)
Vastus: EUR 7. Ajavahemik (Periood)
Vastus: 01.11.2018 - 30.04.2025 8. Kas info on konfidentsiaalne? (Raadionupp valikutega "Jah/Ei")
Vastus: Jah
9. Tellija nimi (Sisestusväli (max pikkus 250 tähemärki)) Vastus: Axell Claims
10. Kontaktisiku nimi (Sisestusväli (max pikkus 250 tähemärki)) Vastus: Frits Keij
11. E-mail (Sisestusväli (max pikkus 250 tähemärki)) Vastus: [email protected]
13. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") Vastus: Ei
1. Kirjeldus (Suur sisestusala (max pikkus 4000 tähemärki)) Vastus:
Rahandusministeeriumi Infotehnoloogiakeskus SFOS Struktuuritoetuse registri arendus- ja
27 / 31
Koostatud 16.05.2025 14:30:37 https://riigihanked.riik.ee/rhr-web/#/procurement/8546704/general-info
hooldusteenus 2. Kogusumma (Summa)
Vastus: 5000000 3. Valuuta (Vääring)
Vastus: EUR 4. Ettevõtja vastutusala (Suur sisestusala (max pikkus 4000 tähemärki))
Vastus:Peatöövõtja: projektijuhtimine, äriprotsesside disain, ärianalüüs, prototüüpimine, süsteemianalüüs, süsteemi arhitektuuri loomine, arendus, testimine ja juurutamine. SFOS arendus- ja hooldustööd. SFOS on struktuurifondide infosüsteem, mis võimaldab andmesisestust Eesti välisrahade taotlemisel ning kasutamise kontrollimisel. Tegemist on kriitilise olulisusega finants infosüsteemiga, mis aitab Eesti ettevõtetel areneda ning seeläbi Eesti majandust kasvatada. Süsteem koosneb: • Ametnike pool (SFOS), kus Rahandusministeeriumi ja teiste täitevasutuste ametnikud sisestavad ja töötlevad taotlusi, makseid, auditeid, ebakõlasid, jne. • Taotleja pool (e-toetus), kus taotlejad saavad ise sisestada taotlusi, aruandeid ning paranduspalveid. • Lisaks toetust saanud sihtrühmade andmekorjeks loodud sündmuste infosüsteem (SIS)." Viimase 36 kuu jooksul lõppenud, tähtajaks üle antud ja nõuetekohaselt täidetud tööde maht on 3 126 372,00€ 5. Summa (Summa)
Vastus: 4531571.37 6. Valuuta (Vääring)
Vastus: EUR 7. Ajavahemik (Periood)
Vastus: 06.07.2020 - 05.07.2024 8. Kas info on konfidentsiaalne? (Raadionupp valikutega "Jah/Ei")
Vastus: Ei
9. Tellija nimi (Sisestusväli (max pikkus 250 tähemärki)) Vastus: Rahandusministeeriumi Infotehnoloogiakeskus
10. Kontaktisiku nimi (Sisestusväli (max pikkus 250 tähemärki)) Vastus: Magnus Lõhmus
11. E-mail (Sisestusväli (max pikkus 250 tähemärki)) Vastus: [email protected]
13. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") Vastus: Jah
14. URL (Url) Vastus: https://riigihanked.riik.ee
15. Kood (Sisestusväli (max pikkus 250 tähemärki)) Vastus: 215902
16. Väljaandja (Sisestusväli (max pikkus 250 tähemärki)) Vastus: Riigihankelepingute andmed on kättesaadavad riigihangete registrist.
1. Kirjeldus (Suur sisestusala (max pikkus 4000 tähemärki)) Vastus: Eesti Töötukassa Töötukassa infosüsteemide arendused
2. Kogusumma (Summa) Vastus: 6380000
3. Valuuta (Vääring) Vastus: EUR
4. Ettevõtja vastutusala (Suur sisestusala (max pikkus 4000 tähemärki)) Vastus:
E-töötukassa arendus- ja hooldustööd Peatöövõtja: projektijuhtimine, äriprotsesside disain, ärianalüüs, prototüüpimine, süsteemianalüüs, süsteemi arhitektuuri loomine, arendus, testimine ja
28 / 31
Koostatud 16.05.2025 14:30:37 https://riigihanked.riik.ee/rhr-web/#/procurement/8546704/general-info
juurutamine. Lepingu kehtivuse jooksul lõpetatud, tähtajaks üle antud ja nõuetekohaselt täidetud tööde maht ületab 5 000 000,00€. 5. Summa (Summa)
Vastus: 5000000 6. Valuuta (Vääring)
Vastus: EUR 7. Ajavahemik (Periood)
Vastus: 25.01.2022 - 25.01.2026 8. Kas info on konfidentsiaalne? (Raadionupp valikutega "Jah/Ei")
Vastus: Ei
9. Tellija nimi (Sisestusväli (max pikkus 250 tähemärki)) Vastus: Eesti Töötukassa
10. Kontaktisiku nimi (Sisestusväli (max pikkus 250 tähemärki)) Vastus: Oliver Närep
11. E-mail (Sisestusväli (max pikkus 250 tähemärki)) Vastus: [email protected]
13. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") Vastus: Jah
14. URL (Url) Vastus: https://riigihanked.riik.ee
15. Kood (Sisestusväli (max pikkus 250 tähemärki)) Vastus: 243158
16. Väljaandja (Sisestusväli (max pikkus 250 tähemärki)) Vastus: Riigihankelepingute andmed on kättesaadavad riigihangete registrist.
1. Kirjeldus (Suur sisestusala (max pikkus 4000 tähemärki)) Vastus:Kuehne + Nagel International AG Control Tower Configurator (CTC) Kühne-Nageli
transpordiettevõttele rakenduse arendamine, mis pakub globaalset haldust, käitlemist ja levitamist: * Kliendi põhiandmed (nt kaubanduspartnerid / asukohad, artiklid / osad, kontaktid jne); * Kliendipõhised seadistused ja konfiguratsioonid. * Kasutajate juurdepääsu ja õiguste kontroll. 2. Kogusumma (Summa)
Vastus: 2000000 3. Valuuta (Vääring)
Vastus: EUR 4. Ettevõtja vastutusala (Suur sisestusala (max pikkus 4000 tähemärki))
Vastus:Peatöövõtja - osutatud teenused: projektijuhtimine, äriprotsesside disain, ärianalüüs, prototüüpimine, süsteemianalüüs, süsteemi arhitektuuri loomine, arendus, testimine ja juurutamine. Viimase 36 kuu jooksul lõppenud, tähtajaks üle antud ja nõuetekohaselt täidetud tööde maht ületab 1 500 000,00 € 5. Summa (Summa)
Vastus: 1500000 6. Valuuta (Vääring)
Vastus: EUR 7. Ajavahemik (Periood)
Vastus: 01.09.2019 - 30.04.2025 8. Kas info on konfidentsiaalne? (Raadionupp valikutega "Jah/Ei")
Vastus: Jah
9. Tellija nimi (Sisestusväli (max pikkus 250 tähemärki))
29 / 31
Koostatud 16.05.2025 14:30:37 https://riigihanked.riik.ee/rhr-web/#/procurement/8546704/general-info
Vastus: Kuehne + Nagel International AG 10. Kontaktisiku nimi (Sisestusväli (max pikkus 250 tähemärki))
Vastus: Jevgenia Arno 11. E-mail (Sisestusväli (max pikkus 250 tähemärki))
Vastus: [email protected]
13. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") Vastus: Ei
1. Kirjeldus (Suur sisestusala (max pikkus 4000 tähemärki)) Vastus:Kuehne + Nagel International AG ControLOG Antud infosüsteem on logistika platvorm,
mis on loodud reaalajas tellimuste ja saadetiste jälgimiseks, soodustades koostööd ja võimaldades proaktiivset probleemide lahendamist võtmeosapoolte vahel, sealhulgas juhtimiskeskuse operaatorid, logistiliste teenuste pakkujad (LSP-d) ja kliendid. See toimib reaalajas seire- ja tegevusjuhtimise tööriistana kliendi juhtimiskeskuse operatiivtiimile. 2. Kogusumma (Summa)
Vastus: 1800000 3. Valuuta (Vääring)
Vastus: EUR 4. Ettevõtja vastutusala (Suur sisestusala (max pikkus 4000 tähemärki))
Vastus:Peatöövõtja - osutatud teenused: projektijuhtimine, äriprotsesside disain, ärianalüüs, prototüüpimine, süsteemianalüüs, süsteemi arhitektuuri loomine, arendus, testimine ja juurutamine. Viimase 36 kuu jooksul lõppenud, tähtajaks üle antud ja nõuetekohaselt täidetud tööde maht ületab 1 500 000,00 € 5. Summa (Summa)
Vastus: 1500000 6. Valuuta (Vääring)
Vastus: EUR 7. Ajavahemik (Periood)
Vastus: 01.02.2020 - 30.04.2025 8. Kas info on konfidentsiaalne? (Raadionupp valikutega "Jah/Ei")
Vastus: Jah
9. Tellija nimi (Sisestusväli (max pikkus 250 tähemärki)) Vastus: Kuehne + Nagel International AG
10. Kontaktisiku nimi (Sisestusväli (max pikkus 250 tähemärki)) Vastus: Jevgenia Arno
11. E-mail (Sisestusväli (max pikkus 250 tähemärki)) Vastus: [email protected]
13. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") Vastus: Ei
1. Kirjeldus (Suur sisestusala (max pikkus 4000 tähemärki)) Vastus:OECD - Majanduskoostöö ja Arengu Organisatsioon O.N.E Members & Partners
platvormi arendus Helmese meeskond vastutab tootearenduse, äri ja süsteemi analüüsi, lahenduste väljatöötamise (arendamise), kvaliteedikontrolli (testimise) haldamise ja ONE ning teiste abisüsteemide tehnilise toe eest. OECD võrgukeskkond (ONE) on OECD jaoks ülioluline IT-lahendus, mis pakub turvalist ja koostööl põhinevat digitaalset tööruumi, mis toetab organisatsiooni globaalset tegevust.
30 / 31
Koostatud 16.05.2025 14:30:37 https://riigihanked.riik.ee/rhr-web/#/procurement/8546704/general-info
ONE MP võimaldab sujuvat suhtlust ja koordineerimist OECD mitmekesiste meeskondade, liikmesriikide ja partnerite vahel, pakkudes tööriistu dokumentide jagamiseks, projektijuhtimiseks ja reaalajas koostööks. 2. Kogusumma (Summa)
Vastus: 6000000 3. Valuuta (Vääring)
Vastus: EUR 4. Ettevõtja vastutusala (Suur sisestusala (max pikkus 4000 tähemärki))
Vastus:Peatöövõtja - osutatud teenused: projektijuhtimine, äriprotsesside disain, teenusedisain, UI/ UX, ärianalüüs, prototüüpimine, süsteemianalüüs, süsteemi arhitektuuri loomine, arendus, testimine ja juurutamine. Viimase 36 kuu jooksul lõppenud, tähtajaks üle antud ja nõuetekohaselt täidetud tööde maht ületab 2 000 000,00€. 5. Summa (Summa)
Vastus: 2000000 6. Valuuta (Vääring)
Vastus: EUR 7. Ajavahemik (Periood)
Vastus: 24.09.2021 8. Kas info on konfidentsiaalne? (Raadionupp valikutega "Jah/Ei")
Vastus: Ei
9. Tellija nimi (Sisestusväli (max pikkus 250 tähemärki)) Vastus: OECD - Majanduskoostöö ja Arengu Organisatsioon
10. Kontaktisiku nimi (Sisestusväli (max pikkus 250 tähemärki)) Vastus: Jerome Reverchon
11. E-mail (Sisestusväli (max pikkus 250 tähemärki)) Vastus: [email protected]
13. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") Vastus: Ei
D: Kvaliteeditagamissüsteemid ja keskkonnajuhtimisstandardid
KVALITEEDISTANDARDITE KOHTA SÕLTUMATUTE ASUTUSTE VÄLJASTATUD
TÕENDID
Kas ettevõtjal on võimalik esitada sõltumatute asutuste koostatud tõendeid selle kohta, et ettevõtja järgib teatavaid kvaliteedistandardeid, sealhulgas puudega inimeste ligipääsu tagamise nõuet.
Viide seadusele: RHS § 101 lg 5 „kui hankija nõuab sõltumatute asutuste tõendite esitamist selle kohta, et pakkuja või taotleja järgib kindlaid kvaliteedi tagamise standardeid, viitab ta asjakohastele Euroopa standardite seeriatel põhinevatele kvaliteedi tagamise süsteemidele, mille on kinnitanud sertifitseerimist käsitlevate Euroopa standardite seeriatele vastavad asutused“
Tingimuse selgitus: Pakkujal peab tarkvaraarenduses olema rakendatud kvaliteedijuhtimissüsteem, mis vastaks vähemalt ISO 9001:2015 standardis sätestatud tingimustele. Pakkuja esitab vastava kirjaliku kinnituse koos vastava sertifitseerimisdokumendi koopiaga.
31 / 31
Koostatud 16.05.2025 14:30:37 https://riigihanked.riik.ee/rhr-web/#/procurement/8546704/general-info
Tingimuse kirjeldus: Nõue: Pakkujal peab tarkvaraarenduses olema rakendatud kvaliteedijuhtimissüsteem, mis vastaks vähemalt ISO 9001:2015 standardis sätestatud tingimustele. Pakkuja esitab vastava kirjaliku kinnituse koos vastava sertifitseerimisdokumendi koopiaga.
Ettevõtjalt oodatavad vastused:
1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") Vastus: Jah
3. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") Vastus: Ei
Kokkuvõtlikud kinnitused
Ettevõtja kinnitab, et esitatud teave on täpne ja õige ning et ta on teadlik valeandmete esitamise tagajärgedest. Ettevõtja kinnitab, et tal on võimalik vajaduse korral viivitamata tema kinnitustele vastavad dokumendid hankijale esitada. Ettevõtja kinnitab, et ta on nõus oma kinnitustele vastavate andmete väljastamisega hankijale, kui need andmed on avalike andmete põhjal hankijale oluliste kulutusteta elektroonilisest andmekogust kättesaadavad.
Kinnituse andja nimi: Andres Kaljo
Koostatud 17.05.2025 14:35:59 1 / 2 https://riigihanked.riik.ee/rhr-web/#/procurement/ 8546704/general-info
PAKKUMUS HINDAMISKRITEERIUMID JA HINNATAVAD NÄITAJAD
Viitenumber: 291973 Hankija: Keskkonnaministeeriumi Infotehnoloogiakeskus (70009445) Hange: TTJA e-teenuste keskkonna TARVIK arendus Pakkumus: 551515 Ettevõtja: AKTSIASELTS HELMES (10364097), roll: peapakkuja
Pakkumuse maksumust hinnatakse - Ilma maksudeta
1. Ühe arendus/hooldustöö töötunni maksumus (käibemaksuta eurodes)
Tüüp ja hindamismeetod: Maksumus, vähim on parim
Osakaal: 40%
Hindamismetoodika kirjeldus: 1. Hindamismetoodika kirjeldus 1.1. Töötunni maksumus. 1.1.1. Hindamiskriteeriumi arvestamise aluseks on pakkumuses esitatud ühe arendus/hooldustöö töötunni maksumus. 1.2. Maksimaalsed väärtuspunktid (40) omistatakse madalaima töötunni maksumusega pakkumusele. Teised pakkumused saavad 40-st võimalikust punktist proportsionaalselt vähem punkte. Väärtuspunktide arvutamisel kasutatakse riigihangete registris kasutusel olevat arvutusmetoodikat.
Madalaima väärtusega pakkumus saab maksimaalse arvu punkte. Teised pakkumused saavad punkte arvutades valemiga: "osakaal" - ("pakkumuse väärtus" - madalaim väärtus") / "suurim väärtus" * "osakaal".
Kogus Ühik Ühiku hind Maksumus KM% Maksumus KM-ga Märkused
39,850 39,850 22 48,617
2. Hinnang esitatud visioonile
Tüüp ja hindamismeetod: Kvaliteet, hankija hinnatav
Osakaal: 30%
Hindamismetoodika kirjeldus: Hinnang esitatud visioonile. Visioon koosneb neljast osast. Visiooni osadele antud väärtuspunktid summeeritakse. Iga hindaja hindab esitatud visioone teistest hindajatest sõltumata. Vt täpsemalt hindamismetoodika kohta "Hindamiskriteeriumite vorm"
3. Teostatud tööde ülevaade
Koostatud 17.05.2025 14:35:59 2 / 2 https://riigihanked.riik.ee/rhr-web/#/procurement/ 8546704/general-info
Tüüp ja hindamismeetod: Kvaliteet, hankija hinnatav
Osakaal: 30%
Hindamismetoodika kirjeldus: Teostatud tööde ülevaade Dokumendis „Teostatud tööde ülevaade“ toodud tabeli täitmisel saadud punktide summa. Maksimaalselt on võimalik saada kuni 30 väärtuspunkti.
Pakkumuse maksumus kokku Maksumus kokku KM-ta: 39,850
Maksumus kokku KM-ga: 48,617
1 / 4
Koostatud 17.05.2025 14:35:59 https://riigihanked.riik.ee/rhr-web/#/procurement/8546704/general-info
PAKKUMUS VASTAVUSTINGIMUSED Viitenumber: 291973 Hankija: Keskkonnaministeeriumi Infotehnoloogiakeskus (70009445) Hange: TTJA e-teenuste keskkonna TARVIK arendus Pakkumus: 551515 Ettevõtja: AKTSIASELTS HELMES (10364097), roll: peapakkuja
ÜHISPAKKUJATE VOLIKIRI Ühispakkujad nimetavad riigihankega ning hankelepingu sõlmimise ja täitmisega seotud toimingute tegemiseks endi seast volitatud esindaja.
Ettevõtjalt oodatavad vastused: 1. Kas tegemist on ühispakkumusega? (Raadionupp valikutega "Jah/Ei")
Vastus: Ei
2. Ühispakkujad nimetavad hankemenetlusega ning hankelepingu sõlmimise ja täitmisega seotud toimingute tegemiseks volitatud esindaja. Ühispakkujad esitavad pakkumusega nende esindajale antud hanke alusdokumentide hulgas sisalduval vormil „Volikiri ühispakkuja esindamiseks“ digiallkirjastatud volikirja. Kui tegemist ei ole ühispakkumusega, vastake "Ei"". (Raadionupp valikutega "Jah/Ei")
Vastus: Ei
PAKKUMUSE ESITAMINE Pakkumuse esitamisega kinnitab pakkuja kõigi riigihanke alusdokumentides esitatud tingimuste ülevõtmist.
Tingimusliku pakkumuse esitamine ei ole lubatud.
Ettevõtjalt oodatavad vastused: 1. Kas ettevõtja saab kinnitada, et pakkumus vastab hanke alusdokumentides sätestatud tingimustele? (Raadionupp valikutega "Jah/Ei")
Vastus: Jah
2. Pakkumus peab sisaldama kinnitust pakkumuse jõusoleku kohta vähemalt 90 päeva. (Raadionupp valikutega "Jah/Ei")
Vastus: Jah
PAKKUMUSE MAKSUMUS Pakkumuse maksumus tuleb esitada töölehel "Hindamiskriteeriumid ja hinnatavad näitajad" toodud struktuuri kohaselt.
Ettevõtjalt oodatavad vastused: 1. Kas ettevõtja kinnitab, et täidab pakkumuse lehe "Hindamiskriteeriumid ja hinnatavad näitajad" lehel ette antud struktuuri kohaselt? (Raadionupp valikutega "Jah/Ei")
Vastus: Jah
2. Pakkumus peab sisaldama ühe arendus-/hooldustöö töötunni maksumust. (Raadionupp valikutega "Jah/Ei")
Vastus: Jah
3. Koos pakkumusega tuleb esitada visioon. Pakkuja esitab visiooni vastavalt alusdokumentide koosseisus olevas dokumendis "Visiooni koostamise juhend" kirjeldatud nõuetele. (Vabas vormis dokument)
Vastus: 3_3_Tarvik_visioon_Helmes.pdf
2 / 4
Koostatud 17.05.2025 14:35:59 https://riigihanked.riik.ee/rhr-web/#/procurement/8546704/general-info
4. Koos pakkumusega tuleb esitada dokumendis „Teostatud tööde ülevaade“ toodud tabel ning esitada mainitud dokumendis nõutud kinnitused. (Vabas vormis dokument)
Vastus: 3_4_Kinnituskiri_Teostatud tööde ülevaade_Riigiportaal (eestiee).asice, 3_4_Kinnituskiri_Teostatud tööde ülevaade_Sündmusteenused.asice, 3_4_Kinnituskiri_Teostatud tööde ülevaade_TEIS.asice, 3_4_Teostatud tööde ülevaade kokkuvõte.pdf
5. Kui pakkumuse allkirjastab isik, kes ei ole pakkuja seadusjärgne esindaja, esitab pakkuja volikirja, mis sisaldab pakkuja seadusjärgse esindaja antud volitust pakkumuse allkirjastajal pakkumust allkirjastada. Kas pakkumuse allkirjastab pakkuja seadusjärgne esindaja? (Raadionupp valikutega "Jah/Ei")
Vastus: Jah
ÄRISALADUS Pakkuja märgib pakkumuses, milline teave on pakkuja ärisaladus ning põhjendab teabe määramist ärisaladuseks.
Teabe ärisaladuseks määramisel lähtutakse ebaausa konkurentsi takistamise ja ärisaladuse kaitse seaduse § 5 lõikes 2 sätestatust. Pakkuja ei või ärisaladusena märkida: 1) pakkumuse maksumust ega osamaksumusi; 2) teenuste hankelepingute puhul lisaks punktis 1 nimetatule muid pakkumuste hindamise kriteeriumidele vastavaid pakkumust iseloomustavaid numbrilisi näitajaid; 3) asjade ja ehitustööde hankelepingute puhul lisaks punktis 1 nimetatule muid pakkumuste hindamise kriteeriumidele vastavaid pakkumust iseloomustavaid näitajaid (RHS § 46 ülamärkega 1).
Ettevõtjalt oodatavad vastused: 1. Kirjeldage lühidalt pakkumuses sisalduvat ärisaladust ja lisage selle määramise põhjendus või märkige, et pakkumus ei sisalda ärisaladust. (Suur sisestusala (max pikkus 4000 tähemärki))
Vastus: Kogu Pakkuja poolt esitatud pakkumus on ärisaladus välja arvatud pakkumuse hindamisel kasutatavad numbrilised väärtused, s.h. pakkumuse maksumus. Nimetatud sisu on Pakkuja ärisaladus kuna tegemist on Pakkuja poolt loodud sisuga, mis eristab Pakkujat teistest pakkujatest.
KINNITUS
Vt täpsemalt "Vastavustingimuste vorm"
Ettevõtjalt oodatavad vastused: 1. Pakkumuses peab sisalduma pakkuja kinnitus kõikide punktis 6. nimetatud rollide mehitamise kohta pakkuja poolt kogu raamlepingu tähtaja jooksul ja kinnitus et tal on võimekus täiendava meeskonna kasutamiseks. (Vabas vormis dokument)
Vastus: 5_1_Kinnituskiri_vastavustingimused punkt 6_Helmes.asice
MEESKOND
Pakkuja peab teenuse osutamiseks tagama vähemalt kahe (so. põhimeeskonna ja sama koosseisuga täiendava meeskonna) meeskonna kogu raamlepingu tähtaja jooksul. Põhimeeskonna vajalik koosseis:
Iga punktis 6 kirjeldatud rolli peab täitma erinev isik. Eesti keele nõude võib asendada tõlgiga Pakkuja kulul. Tõlgi kasutamisega seotud kulud ei kuulu kompenseerimisele Hankija poolt. Hankijal on õigus kontrollida punktis 6 esitatud tingimuste täitmist kogu hankelepingu kehtivuse vältel. Hankija kontrollib punktides 6.1 - 6.8 kirjeldatud spetsialistide kvalifikatsiooni pakkumuses sisalduvatest CV-dest, mille pakkuja vormistab hanke alusdokumentide hulgas oleval CV vormil. Täiendava meeskonna kooseis on analoogne punktis 6. toodud nõuetele. Täiendava meeskonna
3 / 4
Koostatud 17.05.2025 14:35:59 https://riigihanked.riik.ee/rhr-web/#/procurement/8546704/general-info
CV-sid ei ole vaja hankes esitada. *Eesti keele nõude võib asendada tõlgiga Pakkuja kulul. Juhul kui mõne meeskonnaliikme puhul asendatakse eesti keele nõue tõlgiga, siis kasutatav tõlk peab valdama vähemalt B2 tasemel nii eesti keelt kui tõlgitavat keelt. Tõlgi kasutamisel tuleb esitada koos hanke pakkumusega keele taset tõendav dokument (tasemeeksami tunnistus, ülikooli lõpudiplom või muu sellega samaväärne, kui tõlgitav keel või eesti keel ei ole tõlgi emakeeleks). Vt täpsemalt "Vastavustingimuste vorm"
Ettevõtjalt oodatavad vastused: 1. Vähemalt üks 5-aastase tarkvaraarenduse projektijuhtimise kogemusega projektijuht (tiimijuht või arenduse koordinaator) kellel on kogemused projektijuhtimise erinevate metoodikatega (nt. Agile, Scrum), riskijuhtimise, eelarve ja ajakava haldamisega ning kes valdab eesti keelt nii kõnes kui ka kirjas väga heal tasemel. Projektijuhi puhul ei ole lubatud tõlgi kasutamine; (Vabas vormis dokument)
Vastus: 6_1_CV_Projektijuht_IN.pdf, 6_1_CV_Projektijuht_LS.pdf
2. Vähemalt kolm tarkvara arendajat kes omavad vähemalt 4-aastast töökogemust full-stack arenduste ja mikroteenustel põhineva arhitektuuri arendustega sealhulgas PostgreSQL, Java, X- Tee SpringBoot, Angular, React ja Python kasutamise kogemust ning kes valdab eesti keelt nii kõnes kui ka kirjas väga heal tasemel* (Vabas vormis dokument)
Vastus: 6_2_CV_Tarkvara_arendaja_AK.pdf, 6_2_CV_Tarkvara_arendaja_EA.pdf, 6_2_CV_Tarkvara_arendaja_KJ.pdf, 6_2_CV_Tarkvara_arendaja_MSM.pdf, 6_2_CV_Tarkvara_arendaja_PL.pdf, 6_2_CV_Tarkvara_arendaja_STL.pdf
3. Vähemalt üks front-end arendaja kes omab vähemalt 3-aastast töökogemust front-end arenduses ja micro front-end arhitektuuriga ning kes valdab eesti keelt nii kõnes kui ka kirjas väga heal tasemel* (Vabas vormis dokument)
Vastus: 6_3_CV_FE_arendaja_PS.pdf, 6_3_CV_FE_arendaja_VP.pdf
4. Vähemalt üks analüütik, kes omab vähemalt 3-aastast töökogemust infosüsteemide analüüside teostamisel ja kes valdab eesti keelt nii kõnes kui ka kirjas väga heal tasemel. Analüütiku puhul ei ole lubatud tõlgi kasutamine; (Vabas vormis dokument)
Vastus: 6_4_CV_Analüütik_HLV.pdf, 6_4_CV_Analüütik_KJ.pdf
5. Vähemalt üks infosüsteemide arhitekt, kes omab vähemalt 5-aastast töökogemust tarkvaraarhitektuuri loomisel ja haldamisel, sh kogemus mikroteenustel põhineva arhitektuuriga ning kes valdab eesti keelt nii kõnes kui ka kirjas väga heal tasemel* (Vabas vormis dokument)
Vastus: 6_5_CV_Arhitekt_AS.pdf, 6_5_CV_Arhitekt_RR.pdf
6. Vähemalt üks UI/UX spetsialist, kes omab vähemalt 3-aastast töökogemust kasutajaliidese disainimisel, prototüüpimisel ja kasutajatestide loomisel ning kes valdab eesti keelt nii kõnes kui ka kirjas väga heal tasemel* (Vabas vormis dokument)
Vastus: 6_6_CV_UX-UI_disainer_JL.pdf, 6_6_CV_UX-UI_disainer_KT.pdf
7. Vähemalt üks DevOps insener, kes omab vähemalt 3-aastast töökogemust DevOps tööriistade (nt GitLab CI/CD, Docker, Kubernetes) kasutamisel. (Vabas vormis dokument)
Vastus: 6_7_CV_DevOps_Insener_MS.pdf, 6_7_CV_DevOps_Insener_SSO.pdf
8. Vähemalt üks testija kellel on vähemalt 3-aastane infosüsteemide testimise töökogemus ning kes valdab eesti keelt nii kõnes kui ka kirjas väga heal tasemel* (Vabas vormis dokument)
Vastus: 6_8_CV_Testija_AK.pdf, 6_8_CV_Testija_KS.pdf
EL NÕUKOGU SANKTSIOON. ALLTÖÖVÕTJAD JA TARNIJAD. Pakkuja kinnitab, et ta ei kaasa üle 10% hankelepingu maksumusest hankelepingu täitmisele alltöövõtjaid ega tarnijaid, kes on: 1. Vene Föderatsiooni kodanik, resident või Vene Föderatsioonis asutatud ettevõtja, sh füüsilisest isikust ettevõtja, juriidiline isik, asutus või muu üksus; 2. rohkem kui 50% ulatuses otseselt või kaudselt punktis 1 nimetatud isiku, asutuse või muu üksuse omandis; 3. punktis 1 või 2 nimetatud isiku, asutuse või muu üksuse esindaja või tegutseb sellise isiku
4 / 4
Koostatud 17.05.2025 14:35:59 https://riigihanked.riik.ee/rhr-web/#/procurement/8546704/general-info
juhiste alusel. Hankija lükkab tagasi pakkumuse, mille alusel sõlmitav hankeleping oleks RSanS § 7 lg 1 alusel tühine.
Määrust kohaldatakse riigihangetele alates rahvusvahelisest piirmäärast. NÕUKOGU MÄÄRUS (EL) 2022/576, 8. aprill 2022, millega muudetakse määrust (EL) nr 833/2014, mis käsitleb piiravaid meetmeid seoses Venemaa tegevusega, mis destabiliseerib olukorda Ukrainas.
Ettevõtjalt oodatavad vastused: 1. Pakkuja kinnitab, et ta ei kaasa üle 10% hankelepingu maksumusest hankelepingu täitmisele alltöövõtjaid ega tarnijaid, kes on: 1. Vene Föderatsiooni kodanik, resident või Vene Föderatsioonis asutatud ettevõtja, sh füüsilisest isikust ettevõtja, juriidiline isik, asutus või muu üksus; 2. rohkem kui 50% ulatuses otseselt või kaudselt punktis 1 nimetatud isiku, asutuse või muu üksuse omandis; 3. punktis 1 või 2 nimetatud isiku, asutuse või muu üksuse esindaja või tegutseb sellise isiku juhiste alusel. (Raadionupp valikutega "Jah/Ei")
Vastus: Jah
2. Riigihankes saavad osaleda ainult pakkujad, kelle elu- või asukoht on Eestis, mõnes muus Euroopa Liidu liikmesriigis, muus Euroopa Majanduspiirkonna lepinguriigis või Maailma Kaubandusorganisatsiooni riigihankelepinguga ühinenud riigis. (Raadionupp valikutega "Jah/Ei")
Vastus: Jah
“TTJA e-teenuste keskkonna TARVIK
arendus”
Visioon
Riigihange nr 291973
Tellija: Dokumendi kuupäev: Dokumendi autorid:
Keskkonna-
ministeeriumi
Infotehnoloogia-
keskus
28.04.2025 Katrin Vaisma,
Kertrud Järg, Rait
Raidma, Marten Tall
2 / 73
Sisukord
Sisukord ..................................................................................................................................................................... 2
1 Sissejuhatus ....................................................................................................................................................... 4
1.1 Mõisted ja lühendid ................................................................................................................................... 4
2 Executive Summary – Visioon TTJA TARVIK arenduseks ............................................................................. 7
3 Visioon .............................................................................................................................................................. 8
3.1 Visiooni lähtepunktid ................................................................................................................................ 8
3.1.1 Analüüsi, disaini ja arenduse koostöö ja projektijuhtimise metoodika – Dual Track Scrum ............ 9
3.2 Menetlustoote kasutajaliidese arendus .................................................................................................... 10
3.2.1 Ülevaade menetlusprotsessi hetkeolukorrast ................................................................................ 10
3.2.2 Menetluse äriprotsessi nõuded ning UI/UX põhimõtete rakendamine ......................................... 13
3.2.3 Võimalikud lahknevused ja ebakõlad võrreldes eelnevalt teostatud kasutajakogemuse analüüsiga
................................................................................................................................................................. 15
3.2.4 Menetleja kasutajaliidese arenduse tegevuskava - analüüs, disain ning arendus ......................... 16
3.3 Mikroteenuste arhitektuur ....................................................................................................................... 30
3.3.1 Mis on mikroteenusarhitektuur?.................................................................................................... 30
3.3.2 Peamised eelised ............................................................................................................................ 30
3.3.3 Peamised probleemid ..................................................................................................................... 32
3.3.4 Mikroteenusteks jaotamine ........................................................................................................... 34
3.3.5 Mikroteenustel põhineva süsteemi arhitektuur ............................................................................ 36
3.3.6 Menetlusprotsesside loomine ........................................................................................................ 43
3.3.7 Üleminekuplaan .............................................................................................................................. 43
3.3.8 Riskid ja maandamismeetmed ....................................................................................................... 45
3.4 Modelleerimismeetodi BPM tööprotsesside ja protsessimootori tehniline rakendamine ....................... 46
3.4.1 Protsessimootori valik .................................................................................................................... 46
3.4.2 Protsessidiagrammid ...................................................................................................................... 47
3.4.3 Teenuste vaheline suhtlus .............................................................................................................. 47
3.4.4 Jälgitavus ........................................................................................................................................ 48
3.4.5 Arhitektuur ..................................................................................................................................... 49
3.4.6 Kompenseerivad tegevused ........................................................................................................... 51
3.4.7 Korduvad tegevused ....................................................................................................................... 51
3.4.8 Rakendamine .................................................................................................................................. 52
3.4.9 Üleminekuplaan .............................................................................................................................. 53
3.4.10 Riskid ja maandamismeetmed ..................................................................................................... 53
3.5 Mikroesitluskihid .................................................................................................................................... 55
3.5.1 TARVIKu mikroesitluskihtide üldarhitektuur .................................................................................. 55
3 / 73
3.5.2 Tehnoloogiad .................................................................................................................................. 57
3.5.3 Andmevahetus ................................................................................................................................ 58
3.5.4 Disain .............................................................................................................................................. 59
3.5.5 Autentimine, autoriseerimine ja infoturve ..................................................................................... 60
3.5.6 Testimine ........................................................................................................................................ 61
3.5.7 Kasutuselevõtt ................................................................................................................................ 61
3.5.8 Integratsioon väliste süsteemidega ................................................................................................ 66
3.5.9 Riskid ja maandamismeetmed ....................................................................................................... 68
4 Tehisaru kasutamine ........................................................................................................................................ 71
4.1 Automaatne menetlemine ....................................................................................................................... 71
4.2 Klienditugi .............................................................................................................................................. 72
4 / 73
1 Sissejuhatus
Meil on hea meel esitada AS Helmes pakkumus „TTJA e-teenuste keskkonna TARVIK arendus“
hankes.
Tarbijakaitse ja Tehnilise Järelevalve Amet (TTJA) on viimastel aastatel suunanud olulist tähelepanu
oma digivõimekuse tõstmisele ning e-teenuste ühtlustamisele. Erinevate süsteemide – sh
Majandustegevuse Register (MTR), Tarbijakaitse ja Tehnilise Järelevalve Ameti Infosüsteem (JVIS)
ja Numbri Broneerimise Andmekogu (NBA) – killustatus on loonud olukorra, kus teenuste
kasutamine ei ole järjepidev ega alati kasutajasõbralik.
TTJA alustas 2023. aastal uue, mikroteenustel põhineva, e-teenuste platvormi arendustega
(TARVIK), kuhu tuuakse aja jooksul üle kõik TTJA poolt pakutavad teenused erinevatest
süsteemidest (MTR, JVIS, NBA). TARVIKu eesmärk on pakkuda oma kasutajatele kaasaegset
teenust, tagades sealjuures süsteemi töökindluse ning kasutusmugavuse. Selle eesmärgi
saavutamiseks on juba 2024. aastal teostatud TARVIKu kasutusmugavuse analüüs.
Hetkel on TARVIKu keskkonda olemasolevast MTRi süsteemist üle toodud 25
majandustegevusteadet koos osade tugifunktsionaalsustega. Iteratiivselt tuuakse funktsionaalsuseid
teistest süsteemidest juurde. Hetkel ei ole seoses menetlusprotsessidega (k.a loataotlused)
TARVIKusse veel ühtegi funktsionaalsust loodud. Samas on loodud menetleja töölaud ning
registripäeviku ja registritoimiku kuvad, mida võib liigitada menetlustoote alla.
Käesoleva dokumendi eesmärk on kirjeldada pakkuja visiooni hanke raames loodavatest
tehnilisest lahendusest ning kirjeldada eesmärkide saavutamiseks vajaminevad tegevused.
1.1 Mõisted ja lühendid
Mõiste Selgitus
AMQP Advanced Message Queuing Protocol. Avatud standardiga sõnumiprotokoll,
mis võimaldab rakendustel usaldusväärselt ja järjekorras andmeid vahetada
sõnumijärjekordade kaudu. See eraldab sõnumite saatjad ja vastuvõtjad,
võimaldades süsteemidevahelist lahtist sidumist ja paremat skaleeritavust.
API Liides, mille kaudu saab rakendusega suhelda.
Backend Serveris jooksutatav rakenduse poolne osa, mis käivitab äriloogikat.
BPMN Business Process Model and Notation. Graafiline standard äriprotsesside
kujutamiseks, mis võimaldab neid selgelt visualiseerida ja erinevate
osapoolte vahel ühtemoodi mõista. See kasutab sümboleid nagu tegevused,
otsused ja vood protsessi kirjeldamiseks.
Camunda Protsessi- ja otsustusmootor, mis toetab BPMN- ja DMN-standardeid ning
võimaldab äriprotsesside ja otsustusloogika automatiseerimist. Seda saab
integreerida erinevatesse süsteemidesse ning kasutada mikroteenuste ja
töövoogude haldamiseks.
CORS Cross-Origin Resource Sharing. Klientrakenduse-väliste domeenidega
suhtlemise reeglid.
CSP Content Security Policy. Failide jm ressursside laadimise reeglid.
DMN Decision Model and Notation. Standard otsustusreeglite modelleerimiseks ja
dokumenteerimiseks. See võimaldab ärikasutajatel reegleid visuaalselt
kujutada ja IT-süsteemides automatiseerida.
5 / 73
Frontend Kasutaja poolne vaade, mille kaudu saab kasutaja rakendusega suhelda.
Git Tarkvara lähtekoodi versioonihalduse tööriist.
gRPC Kaugkutsungite raamistik, mis võimaldab eri süsteemidel efektiivselt
omavahel suhelda. See kasutab Protobuf-serialiseerimist ja töötab HTTP/2
protokollil.
Helm chart Pakett, mis sisaldab kogu vajalikku konfiguratsiooni rakenduse
paigaldamiseks Kuberneteses. See määratleb ressursid (nt Deployment,
Service) ja võimaldab neid lihtsalt uuesti kasutada ning hallata.
HTTP HyperText Transfer Protocol. Võrguprotokoll, mida kasutatakse andmete,
eriti veebilehtede, edastamiseks kliendi (nt veebibrauseri) ja serveri vahel.
See töötab päring-vastus põhimõttel, kus klient saadab serverile päringu ja
server vastab soovitud andmetega.
Istio Teenuste võrgustiku (service mesh) lahendus, mis haldab mikroteenuste
vahelist liiklust, turvalisust, jälgitavust ja poliitikaid Kuberneteses ilma
rakenduse koodi muutmata.
JVIS Tarbijakaitse ja Tehnilise Järelevalve Ameti Infosüsteem.
KeMIT Keskkonnaministeeriumi Infotehnoloogiakeskus.
Kubernetes Platvorm konteinerite haldamiseks ja orkestreerimiseks, mis automatiseerib
rakenduste paigaldust, skaleerimist ja haldust.
MFE Micro front-end (Mikroesitluskiht). Esitluskihirakendus, mis on
autonoomselt tarnitav ning käivitatav.
MFE host MFE-sid orkestreeriv kasutajaliidese komponent.
MFE remote Tarbitav/orkestreeritav MFE.
MFN Mittefunktsionaalsed nõuded kirjeldavad süsteemi omadusi, mis ei ole seotud
konkreetse funktsionaalsusega, vaid määravad ära kvaliteedi, töökindluse,
jõudluse, turvalisuse, skaleeritavuse jms.
Module federation Keskne esitluskihi moodulite (MFE-de) jagamise tehnoloogia.
Mono-repo Mitut moodulit/rakendust koondav Git repositoorium.
Multi-repo Iga mooduli/rakenduse jaoks eraldi Git repositooriumi kasutamine.
mTLS mutual TLS. Turvaprotokoll, kus nii server kui ka klient autentivad üksteist,
kasutades digitaalseid sertifikaate. See tagab kõrge turvalisuse, kuna
mõlemad osapooled peavad enne ühenduse loomist enda identiteeti
tõendama.
MTR Majandustegevuse Register.
npm Node Package Manager. Keskne esitluskihi komponentide haldussüsteem.
OpenTelemetry
(OTel)
Raamistik, mis võimaldab rakendustest koguda jälgimis-, logi- ja
meetrikaandmeid ühtses vormingus. See aitab paremini mõista süsteemide
käitumist ja lihtsustab jälgitavuse tööriistade integreerimist.
OTLP OpenTelemetry Protocol. Standardiseeritud protokoll, mida kasutatakse
jälgitavusandmete (jäljed, meetrikad, logid) edastamiseks OpenTelemetry-
põhistes süsteemides. See võimaldab kasutada ühtset andmeedastust
jälgimisagendi ja analüüsisüsteemi vahel.
POC Proof of concept. Lahenduse põhimõtete katsetamine. Selle raames testitakse
ära süsteemi olulisemad kohad, kuid ei arendata valmis täielikku rakendust.
Pod Väikseim juurutusüksus Kuberneteses, mis sisaldab ühte või mitut
konteinerit.
6 / 73
Prometheus Monitooringusüsteem ja andmebaas, mis kogub ja salvestab aja jooksul
mõõdetud andmeid. Seda kasutatakse peamiselt süsteemide jõudluse
jälgimiseks.
Sanity testing Muudatuse/paranduse kontrollimine.
Sidecar Muster, kus abiteenus käitatakse samas Podis koos põhiteenusega, et pakkuda
lisafunktsionaalsust nagu logimine, monitooring või turvalisus. See
võimaldab põhiteenust laiendada ilma selle koodi muutmata.
Smoke testing Suitsutestimine. Põhifunktsionaalsuse toimimise kontroll pärast muudatusi.
SSO Single Sign-On. Autentimise mehhanism, mis võimaldab kasutajal sisse
logida ühte süsteemi ja pääseda seejärel automaatselt ligi kõigile teistele
seotud rakendustele ilma uuesti sisselogimist nõudmata.
Tree shaking Optimeerimise eesmärgil tarkvarakoodi eemaldamine sõltuvuste mahu
vähendamiseks.
TTJA Tarbijakaitse ja Tehnilise Järelevalve Amet.
7 / 73
2 Executive Summary – Visioon TTJA TARVIK
arenduseks
Helmese visioon TTJA e-teenuste keskkonna TARVIK arenduseks tugineb meie pikaajalisele
kogemusele riiklike infosüsteemide ja menetlusplatvormide ehitamisel, pakkudes tellijale
skaleeritavat, paindlikku ja kasutajasõbralikku lahendust. Meie lähenemine arvestab KeMIT
tehnoloogilise profiiliga, Eesti riigi IT-arhitektuuri põhimõtetega ning lõppkasutaja ootustega.
Visiooni keskmes on neli olulist alustala:
1. Kasutajaliidese arendus – lähtudes olemasolevatest disainijuhistest ja Trinidad Wisemani
UI/UX-analüüsist, pakume välja rollipõhise töölaudade lahenduse, intelligentsete soovituste
süsteemi ning sujuva ülemineku kasutajate harjumustest uue lahenduseni. Eraldi tähelepanu
on pööratud visuaalse hierarhia ja navigatsiooni selgusele.
2. Mikroteenuste arhitektuur – alustuseks seletame mis on mikroteenusarhitektuuri
kasutamise eelised. Samas toome ka välja, milliseid probleeme see võib põhjustada ning
kuidas neid lahendada. Selgitame, mida tuleks silmas pidada süsteemi jaotamisel
mikroteenusteks ja kuidas seda edukalt teostada. Võttes arvesse teadmisi olemas olevast
süsteemist ning süsteemile esitatud nõudeid, pakume välja arhitektuuri kogu süsteemi,
jälgitavuse kui ka üksiku mikroteenuse vaatest, mis tagaks TARVIKu korrektse töö ja
turvalisuse.
3. Protsessimootori rakendamine – kirjeldame visiooni, kuidas integreerida protsessimootor
TARVIKu infosüsteemi. Selgitame koos põhjendustega milline hakkaks olema loodav
arhitektuur koos põhjendustega. Samuti toome välja, kuidas toimuks suhtlus mikroteenuste ja
protsessimootori vahel, kuidas kasutada protsessimootorit andmete terviklikuse tagamiseks,
mis probleemid võivad esile kerkida ning kuidas neid lahendada.
4. Mikroesitluskihtide arhitektuur – kirjeldame visiooni TARVIKu mikroesitluskihtidele
üleviimiseks, toetudes varasemale kogemusele eesti.ee portaalis. Võrdleme erinevaid
tehnoloogilisi valikuid, pakume lahendusi levinud probleemidele ning meetmeid riskide
maandamiseks. Selgitame eesti.ee portaaliga integreerimise võimalusi.
Visiooni loomise iga arhitektuurne ja tehniline otsus toetub varasematele kogemustele ning
praktilistele õppetundidele sarnastes riiklikes süsteemides, kus skaleeritavus, protsesside jälgitavus
ja kasutusmugavus on osutunud kriitiliseks. Tehnoloogiliste otsuste valikul on lähtutud ideest luua
paindlik ja jätkusuutlik platvorm, mis on valmis nii tehnilisteks muudatusteks kui ka
menetlusprotsesside sisuliseks arenguks.
Helmes on varasemalt TARVIK süsteemi arendustesse panustanud nii arendus- kui ka
analüüsitegevustes, mis annab meile süvitsi mineva arusaamise olemasolevast lahendusest, selle
tugevustest ja kitsaskohtadest. Tänu sellele kogemusele suudame pakkuda asjakohast ja realistlikku
visiooni, mis ei alga nullist, vaid toetub teadlikult olemasolevatele komponentidele.
Meie visioon lähtub põhimõttest, et tehniline täiuslikkus peab käima käsikäes reaalse
kasutajamugavuse, arendatavuse ja paindlikkusega.
8 / 73
3 Visioon
3.1 Visiooni lähtepunktid
Meie arusaam TTJA vajadusest tugineb nii hanke tehnilisele kirjeldusele, varasematele
kasutajakogemuse uuringutele (sh 2024. a klienditoote UI/UX analüüs), toimunud infotunnile kui ka
praktilistele kogemustele avaliku sektori digiteenuste disainimisel. Mõistame, et TTJA ei otsi pelgalt
tehnilist teostajat, vaid partnerit, kes:
• suudab mõtestada keerukaid tööprotsesse, leida optimeerimiskohti ja tõlkida need toimivaks
liideseks,
• omab kogemust suurte riiklike süsteemide disainimisel ja arendamisel,
• suudab kavandada lahendusi, mis arvestavad nii olemasolevate süsteemide pärandit kui ka
tulevikku suunatud arhitektuurilisi põhimõtteid.
Disainides TARVIKu keskkonda tuleb silmas pidada, et selle kaugeleulatuvam visioon on olla ühtne
keskkond, mis toob kokku nii lõppkasutaja poolt tehtavad toimingud, TTJA klienditoe kui ka
menetlemise. Selleni liigutakse osade kaupa - täna on seal peamiselt majandustegevusteadete
esitamise ja haldamise funktsionaalsus koos mõningate tugifunktsionaalsustega (näiteks autentimine
ja autoriseerimine, kontaktandmete haldus, klassifikaatorite haldus, teavituste saatmine jne).
Edasiarenduste puhul on soovitatav alustada enam kasutatavatest teenustest.
Visiooni elluviimisel ja lahenduste jätkusuutlikkuse tagamisel peame oluliseks silmas pidada ja
võimalusel rakendada järgmist:
• Täisdisainisüsteemi kasutuselevõtt TARVIKus. Täisdisainisüsteemi (disain + front-end
koodikomponentide kogum) ühtlustab ja parandab kasutajakogemust, hõlbustab vastavust
ligipääsetavuse nõuetele ning kiirendab edasistes arendustes kasutajaliidese töid vähendades
seeläbi kulusid.
• Erinevate teenuste tervikvaate (nt loataotlus ja selle menetlusprotsess) osapoolte
rahulolu mõõtmine. Menetlejate ja kasutajate tagasiside annab ülevaate nii taotluse kui
menetluse kitsaskohtadest kui sisendi, et süsteem saaks olla pidevalt arenev ja jätkusuutlik.
• Muudatuste juhtimise olulisus. Süsteemi uuendus ja kokku toomine ei ole vaid
tehnoloogiline muudatus, vaid nõuab ka ametnike kui teenusepakkujate kaasamist
muudatustesse, muudatuste juhtimist organisatsioonis tervikuna, koolitamist ning tööd
inimestega. Kui ollakse valmis javõimelised muudatustest aru saama ja nendega kaasa
minema, aitab see ühekomponendina tagada loodava süsteemi jätkusuutlikkust.
Oluline on läbi mõelda, kuidas seotud osapooltele kommunikeerida protsessis planeeritavaid
muudatusi. Soovitame muudatuste läbimõtlemisse ja uute protsesside disaini kaasata neid,
kelle tööd menetlusprotsess otseselt puudutab, et ka nemad saaks kaasa rääkida, kuidas oma
tööd teistmoodi või targemalt teha (kuivõrd optimeeritud protsessid võivad tähendada kas
teistsuguseid tööülesandeid või mõnel juhul ka rollide kaotamist).
Kaasates menetlejaid ja teisi rolle, kasutades nt disainmõtlemise metoodikaid, et “kastist
välja” lahendusi otsida minimeerime riski, et läheme uuendama olemuselt vanu protsesse ning
lõikame läbi võimalused innovatsiooniks.
Visiooni elluviimise arendustsüklit juhime Dual Track Scrum meetodil (vt järgmine ptk), et liikuda
edasi agiilselt, kus disain ja analüüs annab arendusele ette teostatavaid loogilise tükke.
9 / 73
3.1.1 Analüüsi, disaini ja arenduse koostöö ja projektijuhtimise metoodika –
Dual Track Scrum
Disaini, analüüsi ja arenduse sujuvaks koostööks ja projektijuhtimise raamistikuks soovitame
kasutada Dual Track Scrum meetodit. Läbinuna ühe loataotluse tüübi menetluse (nt Merenduse
load) eelanalüüsi ja disaini etapid 1-6, millest on täpsemalt kirjutatud lk 15 (ehk joonisel Sprint 0
faas), saab liikuda konkreetse loataotluse menetluse arendusfaasi. Seejuures paralleelselt jääb kestma
ka disaini- ja analüüsitsükkel, mis erinevatele loogiliselt seostatud arendusetappidele detailsemaid
vaateid ja arenduspileteid ette valmistab. Seejärel saab paralleelselt alustada omakorda uue
loataotluse tüübi (nt Taksoload) menetlusprotsessi Sprint 0 faasiga.
Pakkuja kogemusel võimaldab selline lähenemine hoida analüüsi ja UX disaini ajakohasena ning
hoiduda analüüsi „aegumisest“, mis võib juhtuda kui see valmib liialt palju enne vastava
iteratsiooni arendustööde alustamist.
Joonis 1. Analüüsi, disaini ja arenduse koostöö ning projektijuhtimise metoodika - Dual Track Scrum.
Võrreldes teiste levinud metoodikatega nagu Kanban, tavaline Scrum või Waterfall, pakub just Dual
Track Scrum olulisi eeliseid antud projekti kontekstis. Kanban, mis sobib hästi pideva voo ja
töömahu ühtlustamiseks, ei võimalda piisavalt struktureeritud lähenemist paralleelselt toimuvate
analüüsi- ja arendustegevuste koordineerimiseks. Tavaline Scrum, kuigi iteratiivne ja paindlik, ei
paku eraldi "rada" disaini- ja uurimistegevusteks, mis on kriitilise tähtsusega kasutajakeskse arenduse
puhul.
Waterfall meetod omakorda eeldaks kogu analüüsi lõpuleviimist enne arendustegevuste algust, mis
tähendaks arendustiimide ebaühtlast ressursikasutust ning ei võimaldaks paindlikku reageerimist
eelanalüüsi tulemitele. Dual Track Scrumi kasutamine võimaldab meil optimeerida nii
arendusressursside kasutust kui ka tagada, et disaini- ja analüüsitegevused toetavad järjepidevalt
arendustööd, säilitades samal ajal võimekuse reageerida muutuvatele vajadustele ja uutele sisenditele.
10 / 73
3.2 Menetlustoote kasutajaliidese arendus
3.2.1 Ülevaade menetlusprotsessi hetkeolukorrast
TTJA erinevad loateenused, sh nende menetlemine on jagunenud hetkel mitme süsteemi vahel –
Majandustegevuse Register (MTR) ja TTJA Infosüsteem (JVIS). Lisaks, numbrilubasid hallatakse
läbi Numbri Broneerimise Andmekogu (NBA), kuigi numbriloa taotluse esitamine ja selle
menetlemine käib JVIS süsteemis.
Lisaks sellele, et menetlused käivad läbi mitme süsteemi, on ka erinevatel loateenustel erinevad
menetlusprotsessid, mis lisab menetlejate igapäeva töösse veelgi keerukust.
Järgnevalt toome mõned näited olemasolevatest menetlusprotsessidest, mis ilmestab loataotluste
menetlemise erinevusi.
Näide 1. MTR
Majandustegevuse Register (MTR) on Tarbijakaitse ja Tehnilise Järelevalve Ameti (TTJA) hallatav
register, kus hallatakse majandustegevusteateid ning TTJA pädevusse kuuluvaid tegevuslubasid.
Register võimaldab ettevõtjatel esitada vastavaid taotlusi ning ametiasutustel neid menetleda.
MTRis käib menetlus vastavate loataotluste kuvadel. Näitena toome Merenduse tegevusala
loataotluse menetlusprotsessi:
Joonis 2. Vana MTRi tegevusloa taotluse menetleja kuva
Vastavalt loataotluse staatusele kuvatakse nupud, millele vajutades käivitub vastav funktsionaalsus
ning mööda protsessi edasi liikudes jõutakse lõpuks menetlusprotsessi lõppu (negatiivne või
positiivne otsus). Osade loataotluste puhul on vajalik ka allkirjastamine (nt Merenduse loataotlus).
Kuna erinevaid loataotlusi on väga palju, siis on oluline märkida, et osade loataotluste
menetlusprotsess võib sisaldada veel valdkonnaspetsiifilisi samme.
Järgnev joonis annab lihtsustatud ülevaate MTRi menetlusprotsessist Merenduse valdkonna näitel
(näide algab sammust, kus taotlus on juba esitatud, sest menetlustoote kontekstis ei ole taotluse
esitamise protsess oluline, kuna see on klienditoote osa):
11 / 73
Joonis 3. MTRi menetlusprotsess
Loataotluse esitamisel kontrollib menetleja loataotluse andmed üle (samm 1), mille järel ta kas
märgib taotluse läbivaadatuks, juhul kui see oli korras (samm 3) või võtab ühendust taotluse esitajaga
või muudab taotluse andmeid, kui see korras ei olnud (samm 2). Pärast taotluse läbivaatamist valib
menetleja, kas koostada positiivne või negatiivne otsus, ning vormistab otsuse vastavalt tehtud
valikule (sammud 5 või 6).
Juhul kui menetlusprotsess vajab ka allkirjastamist, saadab menetleja otsuse allkirjastamisele (samm
7) ning peale allkirjastamist saab menetleja menetluse lõpetada (samm 8). Kui koostati negatiivne
otsus, märgitakse loataotluse staatuseks, et menetlus on lõpetatud (samm 10). Juhul kui koostati
positiivne otsus, muudab süsteem tegevusloa kehtivaks ning siis menetlus loetakse lõppenuks (samm
9).
Menetluse käigus on igal hetkel võimalik teha veel järgmiseid tegevusi:
• Lisada menetleja, kellel tekib õigus antud loataotlust menetleda;
• Võtta menetluse samm tagasi juhul kui varasemates sammudes ilmneb vigu;
• Pikendada menetluse tähtaega;
• Muuta loataotluse andmeid;
• Lisada dokumente;
• Märkida loataotlus tagasi võetuks, juhul kui taotluse esitaja selleks soovi avaldab;
• Kontrollida taotluse esitaja ning ettevõtte kohta nende võlgu või karistusi.
Kui otsus on juba koostatud, on võimalik MTRis lisada uus otsus ning otsuse dokumendi teksti muuta.
Tegevuslubade peal, mille menetlus on lõpetatud ning mis on kehtivad, saab menetleja teha järgmisi
tegevusi:
• Muuta tegevusluba;
• Parandada registriandmeid;
• Esitada kahtlus registriandmete õigsuses;
• Esitada täielik või ajutine loobumisteade;
• Lisada ametkondliku kasutamise märget;
• Peatada või tunnistada kehtetuks;
12 / 73
• Kontrollida ettevõtte karistusi või võlgasid.
Näide 2. JVIS
Järelevalve Infosüsteem (JVIS) on samuti TTJA poolt hallatav infosüsteem, kus hallatakse osasid
TTJA pädevusse kuuluvaid tegevuslubasid (mis ei ole MTRis) ning teostatakse järelevalvemenetlusi,
näiteks sideload.
Järelevalvemenetluste puhul on võimalik teha järgmiseid tegevusi:
• Sisestada protokolli;
• Sisestada ettekirjutusi;
• Teostada visiite;
• Sisestada akte;
• Sisestada kontroll-lehti;
• Teostada ekspertiise.
Loataotluste puhul on erinevatel taotlustel erinev protsess nende menetlemiseks. Ühe loataotluse
menetlusprotsessi ilmestamiseks toome näite sagedusloa väljastamisest (vastavalt hankesisendis
kirjeldatule):
Joonis 4. JVIS menetlusprotsess
Kui loataotlus on esitatud, võtab menetleja selle menetlusse (samm 1). Seejärel avab ta muutmisvaate
(samm 2) ning kontrollib andmeid (samm 3). Juhul kui selleks on vajadus, saab ta andmeid muuta
(samm 5) ning kui kõik on korras, lisab ta ka õiguslikud alused (samm 4).
Seejärel vastavalt andmetele väljastab menetleja riigilõivu teate (samm 6) ja süsteem jääb ootama
kuniks klient tasub riigilõivu. Kui raamatupidajatelt tuleb info, et riigilõiv on tasutud, märgib
menetleja selle makstuks (samm 7). Siis menetleja saadab taotluse osakonnajuhatajale kinnitamisele
(samm 8). Kui osakonnajuhataja kinnitab taotluse, muudab süsteem loataotluse kinnitatuks ning
sideloa staatus muutub väljastatuks (samm 9). Menetlusprotsess on sellega lõppenud.
Igal hetkel saab menetleja:
• Lõpetada menetluse nii, et sideluba ei väljastata;
• Lisada taotlusele faile;
• Saata taotlus teisele menetlejale menetlemiseks.
13 / 73
Kui sideluba on väljastatud, on võimalik teha sellega edasisi toiminguid, ehk:
• Tühistada;
• Esitada muutmise taotlust;
• Pikendada.
Näide 3. NBA
NBA rakendust kasutavad nii TTJA ametnikud kui ka numbriloa omanikud. Rakendus jaguneb
omakorda kaheks mooduliks: Numbri Broneerimise Andmekogu (NBA) ja Numbri Broneerimise
Andmekogu süsteemi Numbriliikuvuse moodul (NBA NL).
NBA-s on võimalik seadistada süsteemiparameetreid, teostada numbrite ning nende lubadega seotud
päringuid ja neid hallata. Rakenduses NBA NL on võimalik esitada numbriliikuvuse taotlusi ning
neid menetleda. Samuti on seal võimalik teostada numbriliikuvusega seotud päringuid, hallata
sõnumite liikumist ning nende kanaleid.
Alates 2022. aastast kasutatakse numbrilubade menetlemiseks JVIS-i, kus on loodud eraldi
moodul selle jaoks.
3.2.2 Menetluse äriprotsessi nõuded ning UI/UX põhimõtete rakendamine
TARVIK jaguneb funktsionaalselt kahte suuremasse kategooriasse: klienditoode mis teenindab
loataotlejaid, ja menetlustoode, mis teenindab nii TTJA sisemisi kui ka teiste asutuste (Näiteks
Muinsuskaitseamet, erinevad KOV-id, Transpordiamet jne) kasutajaid - menetlejaid. Käesolev
visioon keskendub menetlustoote kasutajaliidese arendusele, mis peab toetama TTJA ning teiste
asutuste ametnike igapäevatööd loataotluste, teavituste ja otsuste menetlemisel.
Eesmärgi saavutamiseks pöörame erilist tähelepanu muuhulgas ka sellele, et:
• pakkuda kasutajatele teenuste tarbimiseks tänapäevaseid ja kasutajakeskseid lahendusi;
• anda ülevaadet menetlusprotsesside seisust ja pudelikaeltest;
• leida kohti, kus siseprotsesse optimeerida ja automatiseerida.
Kasutajakesksete e-teenuste loomist alustati loateenustest, kus analüüsiti loateenuste
klienditeekondi, tuvastati klientide peamised takistused ja raskuskohad ning pakuti välja lahendusi,
mis muudavad teenuste kasutamise mugavamaks ja intuitiivsemaks. Lisaks visualiseeriti
kasutajaliidest olulisemate põhiteekondade lõikes ning pandi kirja olulisemad disainiotsuste
lähtekohad. Samuti on varasemate projektide raames alustatud juba mitmete tugiteenuste
arendamisega, näiteks X-teede päringud (Äriregister, Rahvastikuregister), kontaktandmete haldus,
teavituste saatmine, logide haldamine jpm.
Siit edasi on loogiline samm minna loateenuse TTJA poolse vaate ehk menetlusprotsessi
kasutajakogemuse ja kasutajaliidese arenduse juurde, et loataotleja vaatest tekiks ühtne ja sujuv
teenuse kogemise tervik. TTJA menetlustoote puhul on võtmeküsimuseks kasutajaliidese
funktsionaalne sobivus tööprotsessidega, mis erinevad oluliselt kliendivaates kasutatavatest.
Nii kliendi- kui menetlustootes olulised
kasutatavuse aspektid
Menetlustoote jaoks lisaks olulised
kasutatavuse aspektid
14 / 73
Intuitiivne, funktsionaalne ja ühildub
olemasolevate infosüsteemidega.
Toetab tööprotsesside loogikat ning suurt
andmemahtu
Vastab ligipääsetavuse nõuetele nii disainis kui
abivahendite mõistes (nt ekraanilugerid,
klaviatuurinavigatsioon).
Võimaldab kiiresti liikuda toimingute vahel (nt
lubade kooskõlastamine, otsuste koostamine).
Annab piisava ülevaate menetluse staatusest. Annab lisaks menetluse staatusele ülevaate ka
töövoo protsessist.
Võimaldab efektiivset teabehaldust ja otsuste
tegemist.
Toetab tõrgeteta koostööd teiste süsteemidega
üleminekuperioodil ning võimaldab sujuvat
üleminekut uuele lahendusele.
Hanke tehnilisele kirjeldusele ja visiooni koostamise juhendile tuginedes on alljärgnevalt toodud
pakkuja põhjalikum nägemus menetlustoote kasutajaliidese loomise tegevuskavast. Töö aluseks on
2024. aastal Trinidad Wisemani poolt läbi viidud TTJA klienditoote UI/UX analüüs ja disainijuhised.
Menetlustoote kasutajaliidese disainimisel arvestame loodud disainijuhiste järjepidevusega,
kuid kohandame need vastavalt menetlejate töövajadustele.
Üleminekuperioodil on oluline, et menetlejatel ei katkeks töövoog erinevate süsteemide vahel
liikudes. Selle tagamiseks:
• Märgistame liideses tegevused, mis viivad teise süsteemi (nt JVIS, MTR, NBA vahel
navigeerimine).
• Kuvame viite süsteemile, kust andmed pärinevad.
• Toetame tööprotsessi katkestuspunktide märkimist, et kasutaja saaks pooleli jäänud tegevust
hiljem jätkata.
• Dokumenteerime kõik ristkasutusest tulenevad piirangud ja pakume välja
üleminekustsenaariumid koos riskide maandamisega.
• Võimalusel integreerime vajalikud andmed TARVIKusse ilma kasutajat mujale suunamata.
• Refaktoreerime olemasolevad TARVIKu menetleja kuvad (nt Registripäevik), et need
moodustaks terviku ülejäänud TARVIKu kuvadega ja oleks kooskõlas ülejäänud
menetlustootega.
Pakume menetlustoote kasutajaliidese arendamisel järgmisi uuenduslikke ja praktiliselt
teostatavaid lahendusi:
• Selge, väljaarendatud rollipõhine töövaade, mis võimaldab menetlejatel näha ainult neid
toiminguid, mis on seotud tema vastutusalaga (nt Registripidaja või Järelevalvaja).
• Personaalne töölaud, kus menetlejale või teistele rollidele kuvatakse vastavalt
personaalsetele eelistustele ja seadistustele eespool need toimingud või loatüübid, millega ta
tihedamini kokku puutub. See võimaldab ka tiimide üleselt saada head ülevaadet tööde seisust
ning annab võimaluse töid planeerida.
• Lisaväärtusena UX-kirjutaja kaasamine, et rakenduse abitekstid ja sisutekstid toetaks
kasutajat tegevuses ega põhjustaks arusaamatusi.
• Ligipääsetavuse standardile EN 301 549 vastavuse tagamine läbi spetsialisti kaasamise.
EN 301 549 sisaldab endas nii rahvusvahelise standardi WCAG 2.1 AA taseme nõudeid kui
ka täiendavaid lisanõudeid.
15 / 73
• Täisdisainisüsteemi kasutuselevõtt, sh front-end komponentide kogum, et tagada
kasutajakogemuse järjepidevus ja skaleeritavus ning hilisem ressursisääst front-end töödes.
• Menetlusprotsesside ühtlustamine, et lihtsustada ja kiirendada menetlejate igapäevatööd.
• Jätkusuutlik komponentide taaskasutus, mis võimaldab hilisemates arendusfaasides uusi
teenuseid lihtsasti sama kasutajaliidese loogika alusel liidestada. Samuti paneb komponentide
taaskasutus aluse erinevate menetlusprotsesside ühtlustamisele.
• Otsustusmootori kasutuselevõtt, mis võimaldab vastavalt sisestatud reeglitele ja andmetele
menetluse osas teha automaatseid otsuseid süsteemi poolt, mis lihtsustab menetlejate tööd.
• Menetlusprotsessi sammude kuvamine, et menetleja saaks aru kus ta asub protsessis ning
kui suur osa menetlusest on veel läbimata.
• Süsteemide vaheline integratsioon, sh
o TTJA vanade süsteemide ja TARVIKu vahel, et menetlejad ei peaks andmeid
sisestama mitu korda, vähendades vea tekkimise ohtu
o TARVIKu ja väliste süsteemide vahel, et optimeerida ja automatiseerida
menetlusprotsessi. Näiteks võimaldaks see kontrollida riigilõivude laekumist
automaatselt, et menetlusprotsessi järgmisesse sammu liikuda ilma menetleja poolt
andmeid käsitsi sisestamata (lisaks veel teavituste automaatne saatmine riigilõivu
laekumisel, NANDOga integratsioon jne)
• AI integreerimine TARVIKusse, mis võimaldaks AI poolt teostada automaatseid
menetlusotsuseid ja aidata vastata kasutaja küsimustele. Täpsem AI kasutamise võimalikkus
on kirjeldatud käesoleva dokumendi peatükis „Tehisaru kasutamine“.
3.2.3 Võimalikud lahknevused ja ebakõlad võrreldes eelnevalt teostatud
kasutajakogemuse analüüsiga
Trinidad Wiseman viis 2024. aastal läbi TTJA klienditoote kasutajakogemuse analüüsi, mille põhjal
koostati ka disainijuhised. Menetlustoote arenduses kasutame seda analüüsi alusena, kuid arvestame
menetluskeskkonna eriomadustega.
Kliendivaate puhul on rõhk teenuse leidmisel, juhendamisel ja veateadete mõistmisel. Menetleja töös
on esikohal töökiirus, töövoo selgus ja süsteemne liidese struktuur. Menetlustoote liides peab toetama
süstemaatilist otsustamist, võimaldama kiiret navigeerimist ja olema kooskõlas tööprotsessi
etappidega. Võimalikud lahknevused ja erinevused, mis võivad ilmneda ja millega arvestame:
• Menetlustsükli struktuurne erinevus: kliendivaate ülesehitus on lineaarne, menetluses võib
paralleelselt töös olla mitu protsessi, võidakse eelistada andmete kuvamist tabelitena,
kaardivaadetena vms.
• Kasutuslugude piiratus loataotluste UX analüüsis: teostatud kasutajakogemuse analüüsis
käsitleti vaid piiratud osa loataotluste tüüpidest ja seda eeskätt lõppkasutaja vaatest.
Menetlusprotsessi analüüs võib juurde tuuavajaduse võtta kasutusele täiesti uusi
disainikomponente.
• Paindlikkuse vajadus erinevate interaktsioonide kasutamisel: menetlejate vaadetes võib
olla rohkem tingimuslikke välju ja erijuhtumeid, samuti võivad menetlejad eelistada
vormiväljade kohandamisvõimalust spetsiifilisele menetluse liigile vastavaks.
• Terminoloogia ja pisitekstide erinevus: Kliendivaate abitekstid on rohkem selgitavad,
menetlejatele kuvatakse aga sisekasutajatele suunatud täpsemat ja juriidilisemat sõnakasutust.
16 / 73
Vaatame kriitilise pilguga üle olemasolevad disainimustrid ning vajadusel täiendame või kohandame
neid, et need sobituks menetlejate tööviisiga, arvestades ligipääsetavuse nõudeid ja olemasoleva
disainisüsteemi disainikomponentide taaskasutust (Trinidad Wisemani loodud prototüübis kasutati
Veera disainisüsteemi).
3.2.4 Menetleja kasutajaliidese arenduse tegevuskava - analüüs, disain ning
arendus
Kasutajasõbralikuma menetlusprotsessi saavutamiseks saame lahendusi otsida erinevatest
suundadest:
• lõppkasutajate loataotluse esitamise kitsaskohtadele lahenduste leidmine;
• menetlejate tööprotsesside ja kasutajaliidese kitsaskohtade parendused.
Loataotluse kasutajauuringu tulemused ja murekohtade prioriseerimine TTJA töögrupis tõid välja, et
väga suur osa kasutajakogemuse puudustest tekib ebaselgest kliendiliidesest, mis omakorda tekitab
palju lisatööd menetlejale ja TTJA kasutajatoele.
Näiteks puudub kasutajatel selge arusaam menetlustähtaegadest ning nad ei saa piisavat tagasisidet
taotluse menetlemise staatuse kohta. Seda annaks parandada näiteks selgemate menetlustähtaegade
kommunikeerimisega taotluse esitamisel, automaatsete teavituste lisamisega taotluse staatuse
muutumisel ja lihtsa staatuse jälgimise võimaluse loomisega kasutajaliideses. Seega omab juba
ainuüksi lõppkasutaja kogemuse parandamine ja ühtlustamine automaatselt suurt mõju ka
menetleja töö efektiivsemaks muutmisele - väheneks koormus kasutajate läbiaitamisel loataotluse
protsessist ja tema infoväljas hoidmisel. Kui lõppkasutaja saab asjakohaseid teateid menetluse käigust
ja taotlusvormi vigadest operatiivsetesse kanalitesse (e-mail, SMS), aitab see vähendada menetlejate
ja klienditoe töökoormust info jagamisel.
Menetleja poolelt vaadatuna ilmneb nii MTR kui JVIS dokumentatsioonidest, et täna teeb menetleja
väga palju korduvaid tegevusi käsitööna: nt sisestab riigilõivu laekumised (mille kohta on ka
raamatupidaja eelnevalt teinud käsitööd, saatmaks teatud perioodi laekumised e-kirja teel
menetlejale), teeb sissekande rahvusvahelisse keskkonda NANDO, et kooskõlastada teiste riikidega
antud luba; teeb otsuse ühes süsteemis ja kopeerib selle käsitsi teise jne. Kõiki neid täna käitisi
tehtavaid tegevusi on võimalik automatiseerida läbi vajalike liidestuste.
Taotluse ja menetluse ühte keskkonda toomine aitab kaasa tervikliku kasutajakogemuse loomisele nii
lõppkliendi kui menetleja vaatest. Seda kõike arvesse võttes, soovitame tegevuslubade üle toomisel
TARVIKusse alustada enam esitatavate loataotlustega, koos selle menetlusprotsessiga
üheaegselt.
Menetlustoote kasutajaliidese arendus toimub etapiviisiliselt, lähtudes agiilsest arendusmudelist ja
tihedast koostööst tellijaga. Üleminekuperiood eeldab, et uus menetlusliides töötab paralleelselt
olemasolevate süsteemidega.
Menetlustoote kasutajaliidese arendus jaguneb järgnevateks etappideks. Käesolevad tegevused on
välja toodud ühe loeteluna, kuigi reaalsuses teostatakse neid tegevusi iteratiivselt, ehk Dual
Track Scrumi mõistes on mitu paralleelselt toimuvat teekonda (Tracki), kus käiakse läbi
sammud 1-8:
1. Olemasolevate disainijuhiste ja menetluskeskkonna analüüs. Võrdleme klienditoote
disainimustreid, MTR, JVIS kasutajaliidese funktsioone, et selgitada välja ülekantavad ja
uued komponendid.
17 / 73
2. Menetlejate kasutajakogemuse ja vajaduste kaardistamine. Viime läbi intervjuud
menetlejatega, mõistmaks, millised on tänase menetlusprotsessi kitsaskohad.
3. AS-IS menetlusprotsessi kasutajateekonna kaardistamine. Visualiseerime menetleja kui
kasutaja tänased töövood ja teekonnad ning kokkupuutepunktid lõppkasutajaga.
4. Nõuete ja skoobi täpsustamine. Vastavalt AS-IS analüüsile ja eelmistes faasides tuvastatud
valupunktidele kirjeldatakse koostöös Tellijaga ärinõuded ning selgitatakse välja skoopi
kuuluvad ning sellest välja jääv funktsionaalsus. Lisaks tehakse antud sammus
juriidiline analüüs, et veenduda, et loataotluste menetlused vastavad seadustele
5. TO-BE kasutajateekonna ja navigatsiooniloogika visualiseerimine. Visualiseerime,
milliseid samme menetleja uues süsteemis ideaalis läbib, võttes arvesse ka võimalikke
ühtlustamis- ja optimeerimiskohti.
6. TO-BE lahenduse disain. Loome menetleja vaadete prototüübid, testime neid kasutajatega,
et viimased saaksid kindlust, et arendama asutakse just seda, mida oleme kokku leppinud,
viime sisse muudatused, kinnitame ja disainime lõplikud vaated, kasutades
täisdisainisüsteemi (nt TEDI ja TARVIK erikomponentide kombinatsiooni) ning järgides EL
ligipääsetavuse standardit EN 301 549. EN 301 549 sisaldab endas nii rahvusvahelise
standardi WCAG 2.1 AA taseme nõudeid kui ka täiendavaid lisanõudeid.
7. Arendustööde teostamine. Vastavalt teostatud analüüsidele ja kokkulepitud skoobile,
teostatakse arendustööd.
8. Arendustööde testimine. Valminud arendustööd testitakse testija või analüütiku poolt, et
veenduda arenduse vastavust vastuvõtutingimustele.
Järgnevalt on kirjeldatud iga tegevus detailsemalt, selle eeldatav mõju ning tähelepanekud
üleminekuperioodiks. Lisaks Dual Track Scrumi sammudele 1-8 toome olulise arendusprotsessi
lõppsammuna välja ka arenduste tarnimise detailsema kirjelduse.
1. Olemasolevate disainijuhiste ja menetluskeskkonna analüüs
Tegevuse sisu Koondame varasemad kasutajauuringu analüüsitulemused, UX
disainiotsused ja teeme võrdluse JVIS kasutajaliidese ning uue
disainisüsteemi komponentide vahel. Märgistame ära disainilised ja
sisulised ebakõlad, mis võivad mõjutada töövoogu. Analüüs sisaldab ka
menetleja töökoormuse ja tööprotsessi kaardistust (rutiinsed tegevused,
pudelikaelad, korduvad tegevused, käsitsi töö jne).
Eeldatav mõju Annab disainitöödele selgema fookuse, aitab vähendada hilisemates
faasides UX/UI tööde mahtu ning ja loob järjepideva kasutuskogemuse.
Üleminekuperioodi
tähelepanekud
Teadvustame, et osa menetlejaid võib paralleelselt kasutada nii uut kui
vana süsteemi – disain peab toetama kahe süsteemi vahelist sarnast
navigeerimisloogikat. Samas tagame uue, optimeeritud süsteemi arenduse
kursil püsimist eelanalüüsi käigus loodava TO-BE lahenduse skoobis
hoidmisega, et vana süsteemi loogika ei saaks takistuseks uue loomisel.
Ootused Tellijale • Annab ligipääsu tööprotsesse puudutavale infole ning
töökorraldusele
• Annab tagasisidet ja vastab küsimustele
18 / 73
2. Menetlejate kasutajakogemuse ja vajaduste kaardistamine
Tegevuse sisu Selle tegevuse eesmärk on mõista, milline struktuur ja liidese käitumine
toetab menetlejaid kõige enam. Viime läbi intervjuud menetlejatega,
mille peamine eesmärk on murekohtade ja eelistuste kaardistamine
protsessi erinevates lõikudes, seejuures markeerides ka need kohad, kus
menetlejatele tekib lisategevusi, kuna lõppkasutaja liides ei ole mugav.
Lisaks palume menetlejatel kommenteerida portaali kasutajakogemust
erinevatest aspektidest lähtuvalt: funktsionaalsus, disain, tekstid. Eestis
täna veel pigem uudse lähenemisena kaasame UX-kirjutaja, et testida
sõnastust ning navigeerimise loogikat. Analüüsime kasutaja käitumist
töövoo protsessi lõikes, et tuvastada tööprotsesside ebaefektiivsust ja
optimeerimiskohti, mida annab lahendada erinevate tehniliste lahenduste
abil: süsteemide vaheline integratsioon, automatiseerimine, parem
teavituse- ja meeldetuletuse loogika, AI või protsessimootori kasutusele
võtmine.
Kaasame intervjuudesse võimalikult erineva tausta ja kogemusega
töötajad, et luua lahendus, mis oleks intuitiivne ka ilma pikki juhendeid
lugemata. Intervjuud toimuvad individuaalselt, kestavad kuni 1 tund ning
salvestatakse helis ja pildis, et analüüsida ka tehnilise lahenduse
kasutatavust.
Eeldatav mõju Menetlejate vaatenurk toob välja olulisi faktipõhiseid kitsaskohti, mis on
sisendiks funktsionaalsusele ja kujundusele, võimaldades meil lahendada
päris kasutajate päris probleeme. Menetlejate kaasamine muudatuste
protsessi ja arendustesse lihtsustab hilisemat muudatuste elluviimist.
Üleminekuperioodi
tähelepanekud
Arvestame, et vastavalt hanke alusdokumentidele migreeritakse
menetlusprotsesse järk-järgult. Selgitame koostöös menetlejatega,
millised on nende eelistused valikul ja loogika protsesside
üleminekuperioodiks.
Ootused Tellijale • Annab tagasisidet intervjuu kavale
• Edastab vajalikud töötajate kontaktid
3. AS-IS menetlusprotsessi kasutajateekonna kaardistamine
Tegevuse sisu Enne uue kasutajaliidese prototüüpimist kaardistame olemasolevad
tööprotsessid, mida TTJA menetlejad igapäevaselt läbivad. Kasutame
kogutud andmeid intervjuudest, aga ka varasematest kasutajauuringutest
ja olemasolevaid protsessivooge, et visualiseerida kuidas menetleja liigub
läbi erinevate tegevuste nagu taotluse vastuvõtmine, sisestamine,
täiendamine, otsuse koostamine, edastamine jm. Loome visuaalsed
kasutajateekonnad (Tellijale sobivas keskkonnas), mille kaudu on näha
tegevuste järjestus, tööriistad, infoväljad ja katkestuskohad. Lisaks toome
teekonna pildile ka lõppkasutaja: millises punktis ta täna abi vajab, kus
tahab olla või peaks olema infoväljas, millist täpset infot peaks loataotluse
vigade kohta saama jms.
Tegevuse viime läbi pakkuja sisemise töötoana ning teekondi valideerime
ja kinnitame koos Tellijaga.
Eeldatav mõju Annab tervikliku ja tõenduspõhise aluse uue liidese disainiks, tuues
pildile mitmeid erinevaid tänaseid tööpraktikaid ning välistades oletuste
põhjal otsustamise. Võimaldab paremini mõista, kuidas menetlejad eri
19 / 73
osakondades süsteemi kasutavad ning millised osad vajavad
standardiseerimist või täiustamist.
Üleminekuperioodi
tähelepanekud
AS-IS kaardistus aitab selgelt eristada esialgu olemasolevatesse
süsteemidesse jäävad ning uude menetlustootesse viidavad tegevused.
Märgistame need menetleja teekonnal eraldi, et aidata disainis ja
kasutusjuhistes rõhutada süsteemide piire ja sujuvaid üleminekuid.
Kaardistus saab olla ka koolitusmaterjali ja muudatuste
kommunikatsiooni alus.
Ootused Tellijale Annab tagasisidet AS-IS menetleja kasutajateekonnale
4. Nõuete ja skoobi täpsustamine
Tegevuse sisu Kui AS-IS protsessid ja valukohad on kaardistatud, täpsustatakse
koostöös Tellijaga (äri)nõuded TARVIKusse implementeeritavale
menetlustootele ning teostatakse süsteemi detailanalüüs. Nõuete
täpsustamiseks viiakse läbi analüüsikoosolekuid kliendiga. Lisaks
tehakse koostöös Tellijaga juriidiline analüüs iga loataotluse kohta
veendumaks, et nende esitamine ning menetlusprotsess vastavad Eesti
Vabariigi seadustele.
Antud sammus teostatakse ka süsteemianalüüs, mille käigus
täpsustatakse vajatavad integratsioonid teiste süsteemidega,
konfiguratsioonid, mikroteenused ning nende andmebaasid
veendumaks, et menetlustoote nii äriline, kui ka tehniline disain
moodustab ühtse terviku ning toimib vastavalt nõuetele.
Kogudes vajalikku sisendit, dokumenteerib analüütik kogu info,
sünteesib seda, teeb järeldusi ning kogutud infost lähtuvalt pakub välja
lahendusi, mis kooskõlastatakse Tellijaga. Detailanalüüs käsitleb lisaks
asjaolu, et paralleelselt peavad jääma töötama mitmed süsteemid ning ka
vajadusel infot vahetama (nt JVIS-i ja TARVIKu vaheline integratsioon).
Detailanalüüsi käigus selgitatakse välja ja dokumenteeritakse:
• Nõuete täpsed sõnastused
• Arenduse äriline vajadus
• Sõnavara ja mõistete selgitused
• Protsesside kaardistused
• Süsteemi integratsioonide kirjeldused teiste (väliste)
süsteemidega
• Diagrammid, mis analüüsi kontekstis on olulised ja pakuvad
väärtust (näiteks UML jadadiagrammid, BPMN
protsessidiagrammid jne)
• Vajalikud seadistused ja konfiguratsioonid
• Süsteemi spetsifikatsioonid, sh
o Andmestruktuur/andmebaasi disain
o Mikroteenused
Selleks et tagada arusaadav ja ühene arusaam projekti skoobist kõikidele
osapooltele ning ennetada võimalikke arusaamatusi hilisemates
etappides, dokumenteeritakse nii implementeeritavad nõuded kui ka
need nõuded, mille rakendamist praeguses etapis ei kavandata, koos
vastavate põhjendustega.
20 / 73
Pakkuja varasem kogemus näitab, et selline lähenemine aitab kõikidel
osapooltel mõista oodatavat tulemust ning välistab olukorrad, kus
nõudeid tõlgendatakse erinevalt, mis võiks põhjustada ebaselgust
vastuvõtutestide käigus. Tulevastes iteratsioonides on võimalik skoobi
ülevaatamine vastavalt vajadusele, mis toetab agiilset lähenemist..
Loodud dokumentatsioon kooskõlastatakse Tellijaga, mille järel on
võimalik luua konkreetsed arenduspiletid Jira keskkonda.
Eeldatav mõju Täpselt sõnastatud nõuded ja protsessid annavad mõlemale osapoolele
kindluse, et loodava süsteemi nõuetest ja skoobist on üheselt aru saadud.
Dokumentatsiooni kinnitustega annab Tellija nõusoleku antud
arendustöödega alustamiseks, mis on ühtlasi arenduse eelduseks.
Üleminekuperioodi
tähelepanekud
Nõuete täpsustamisel ning detailanalüüsi käigus arvestatakse asjaoluga,
et paralleelselt peavad jääma tööle mitmed süsteemid. Dokumenteeritakse
nende süsteemide integratsioonid/üleminekud ning ka kitsaskohad,
millega peab edaspidistes töövoogudes arvestama (kui neid on).
Ootused Tellijale • Osaleb analüüsikoosolekutel
• On kättesaadav küsimuste tekkimisel
• Nimetab tooteomaniku/vastutaja (TTJA poolt), kes lahkarvamuste
korral lõppotsuseid teeb
• Vaatab üle ja annab tagasisidet jooksvalt detailanalüüsi tulemitele
5. TO-BE kasutajateekonna ja navigatsiooniloogika visualiseerimine
Tegevuse sisu TO-BE kasutajateekonna ja navigeerimisloogika visualiseerimise
eesmärk on enne detailsete vaadete prototüüpimist kujundada sihipärane
ja kasutajakeskne struktuur menetlustoote uuele liidesele.
Selles etapis visualiseerime, milline on menetlaja jaoks ideaalne
kasutajateekond, st milliseid samme menetleja uues süsteemis läbib,
võttes arvesse ka võimalikke optimeerimiskohti (nt infosüsteemide
paremat omavahelist suhtlust, eeldefineeritud otsustuspuude või tehisaru
kasutamist automaatsete otsuste tekitamiseks, osakondade vahelise
tööjaotuse optimeerimist, vormiväljade maksimaalset standardiseerimist
vms.). Visualiseerime need teekonnad (Tellijale sobivas keskkonnas)
koos seotud vaadete tüüpidega (nt otsinguvaade, loetelu, vormivaade),
määrates ära iga vaate rolli, sisendi ja järgmise loogilise sammu.
Julgustades menetlejaid mõtlema oma tööprotsessidele kõrvalseisjana,
loovalt ja “kastist välja” lähenemisega, viime läbi koosloome tööubasid,
mille käigus kasutame disainmõtlemise metoodikaid lahendusete
ideestamiseks, näiteks:
• Hull 8, kus piiratud aja, 8 minuti jooksul, otsitakse lahendusi
menetlusprotsessis ettetulevale konkreetsele probleemile. Töötoas
osalejad kirjeldavad individuaalselt 8 võimalust, hiljem
hääletatakse neist parim või kasutatakse mõju-teostatavuse
maatriksit parimate lahenduse väljasõelumiseks
• Jah, ja... Metoodika, kus töötoas osalejad peavad kolleegi
lahendusideele leidma asjakohaseid täiendusi, avama võimalust
veelgi enam (jah, hea mõte, ja lisaks veel...) vastukaaluks piiravale
suhtumisele (“hea mõte, aga...”).
21 / 73
Visualiseerime nii kasutajateekondadena, kui ka BPMN
protsessijoonistena, sest kasutajateekonnad ilmestavad inimese poolt
ning BPMN protsessijoonised aitavad tuua tehnilisemat vaadet uutele
teekondadele/protsessidele, mis hõlmavad ka suhtlust väliste
süsteemidega.
TO-BE navigatsiooniloogika hõlmab ka ülevaadet vasakmenüü
struktuurist, töölaudadest, filtritest, breadcrumb loogikast jms.
Kujundame selle loogikaga, mis toetab nii kogenud kasutajate
kiirtegevusi kui juhatab vähemkogenud kasutajaid samm-sammult.
Viime selle tegevuse läbi koosloome töötoana koos Tellijaga ning
vormistame TO-BE kasutajateekonna ja navigatsiooniloogika lõplikule
kujule.
Eeldatav mõju TO-BE kaardistus loob tugeva aluse hilisemaks prototüüpimiseks –
vaated lähtuvad protsessidest, mitte ainult tehnilisest ülesehitusest.
Tagab, et liides on kasutaja jaoks loogiline ja suunav ning toetab töövoo
kiiret läbimist ilma ekslemiseta. Kogu töövoo, sh sisemiste protsesside
visualiseerimine aitab ühtlustada arusaama kogu meeskonnas (TTJA,
disainerid, arendajad, menetlejad), milline on soovitud lõpptulemus.
Üleminekuperioodi
tähelepanekud
TO-BE teekonnad kaardistatakse nii, et oleks võimalik paralleelne
kasutus olemasoleva süsteemiga. Näiteks märgime need osad protsessist,
mida uus süsteem veel ei kata ja mis viivad tagasi JVIS/MTR vaatesse.
Toetame võimalust, et uude süsteemi liidetakse järk-järgult rohkem
protsesse – navigeerimisstruktuur on selleks modulaarne ja skaleeritav.
Ootused Tellijale • Osaleb projektimeeskonnaga aktiivselt koosloome töötoas,
kaasates erinevat majasisest ekspertiisi ja kogemust.
• Annab tagasisidet TO-BE menetleja kasutajateekonnale ja
kasutajaliidese navigatisooniloogikale.
6. TO-BE lahenduse disain
Tegevuse sisu Arendame välja klikitava prototüübi menetlustoote prioriteetsetest
vaadetest, lähtudes TO-BE kasutajateekonnast ja navigatsiooniskeemist.
Prototüüp sisaldab kõiki olulisi tööprotsessi toetavaid komponente ja
elemente: näiteks taotluste loend, menetluse detailvaade, otsuse
koostamise vorm ja töölaud. Samuti mõtleme läbi ja prototüübime
lõppkasutajale olulise info kuvamise viisi menetlusprotsessi konkreetse
etapi staatusest.
Prototüüp luuakse kahes astmes:
• Low-fidelity wireframe – keskendub funktsionaalsele struktuurile,
infopaigutusele ja navigatsiooniloogikale. Võttes kasutusele
Veera disainisüsteemi kohe projekti alguses, saame juba ka selles
faasis kuvada “nagu päris” vaateid.
• High-fidelity prototüüp – visuaalselt kujundatud versioon,
kasutades täisdisainisüsteemi komponente (nt TEDI ja TARVIK
erikomponentide kogum või kokkuleppel mõnda muud
lahendust). Vajadusel loome uued taaskasutatavad komponendid.
22 / 73
Kaasame UX-kirjutaja, kes töötab paralleelselt disaineriga, et
vormiväljade nimed, tegevusnupud ja süsteemsed sõnumid oleksid kohe
prototüübis kasutatavuse seisukohalt sobivad ning igas vaates läbivalt
ühtsed (nt ei kasutataks läbisegi termineid “Kinnita” või “Salvesta”,
“Ootel” või “Avatud” vms).
Prototüüpi testitakse menetlejatega individuaalsete kasutatavuse testide
käigus, kasutades „valjusti mõtlemise“ meetodit. Testitavad täidavad
neile tuttavaid tööülesandeid ning me jälgime nende arusaamist, eksimusi
ja ootusi. Tagasiside põhjal täiustame prototüüpi.
Eeldatav mõju Klikitav prototüüp võimaldab TTJA meeskonnal testida süsteemi
loogikat ja disaini enne arendusressursside kasutamist. Parandused ja
täpsustused on võimalik teha varases faasis, vältides hilisemaid kulukaid
muudatusi. Kasutajatestide tulemusel saame faktipõhise kinnituse, et
süsteem on arusaadav ja toetab tööprotsesse.
Üleminekuperioodi
tähelepanekud
Prototüübi loome arvestusega, et osa menetlejate tööülesannetest jätkub
vanas süsteemis. Seetõttu toome visuaalselt esile kohad, kus prototüüp
suunab teise süsteemi või esitab seotud andmeid sellest. Kasutajale
näidatakse selgelt, milline tegevus toimub millises süsteemis. Testimise
ajal pöörame tähelepanu, kas kasutaja suudab aru saada, millal toimub
tööprotsessi katkestus või süsteemidevaheline liikumine.
Ootused Tellijale • Annab esmast tagasisidet prototüübile
• Annab testijate kontaktid
• Kinnitab menetleja kasutajaliidese põhivaadete disaini
Näited võimalikest TO-BE menetlejavaadete disainist
Kasutajakogemuse parendamise visiooni ilmestamiseks oleme kokku pannud võimaliku
tulevikulahenduse prototüübi Merenduse loataotluse menetlusprotsessi näitel. Prototüübi ja selle
läbimise juhisega saab tutvuda sellelt Figma lingilt.
Alljärgnevalt on toodud põhilised menetlejavaate kasutajakogemuse parendamise mõtted, mida
tahame esile tuua.
23 / 73
Personaalne töölaud
Joonis 5. Personaalse töölaua vaade TARVIKus
Töölaud on heaks alguspunktiks menetleja enda tööde (ja tiimi tööde) progressi ja ülevaate
saamiseks, enamkasutatavate päringute ning poolelioleva tegevuse juurde naasmiseks. Töölaud on
menetleja enda poolt seadistatav. Näiteks saab eespool vastavalt eelistustele ja seadistustele kuvada
need toimingud või loatüübid, millega menetleja tihedamini kokku puutub, talle suunatud teateid,
menetlusprotsessi tähtaegade lähenemist, taotlusi, millele ei ole veel menetlejat määratud jms. See
võimaldab ka tiimide üleselt saada head ülevaadet tööde seisust ning annab võimaluse töid
planeerida.
24 / 73
Kompaktsem menetluse vaade
Joonis 6. Tegevusloa infovaade TARVIKus
Kasutame disainis paremriba (1), et esile tõsta menetluse protsessi puudutav oluline info:
protsessi etapid, tähtaeg, menetleja kommentaarid, allkirjastaja ja otsus koos põhjendusega.
Toome loogiliselt üksteisega seotud infoväljad ühte kohta (2): nt kõik menetlusega seotud
kuupäevad ühes kohas, visuaalselt hästi eristatav tähtaeg ja võimalus seda muuta; menetlusprotsessi
etapiline progressikuva koos samasse kohta toodud võimalusega võtta üks samm tagasi protsessi
tagasi jms.
Kasutame akordioni komponenti, et peita info, mis menetluse otsustusprotsessi seisukohast pole
esmaoluline (3), et hoida fookust olulistel asjadel kompaktsena.
Visualiseerime menetluse protsessi sammudena (4) ja kuvame staatust. See võimaldab ka
väiksema kogemusega menetlejal protsessist lihtsamini ülevaadet saada.
25 / 73
Automatiseerimine ja AI kasutamine
Joonis 7. Tegevusloa infovaade TARVIKus
Toome juurde automaatpäringud seotud andmebaasidesse (5). Menetleja ei pea nupule vajutusega
liikuma nt Maksu- ja Tolliameti infosüsteemi, vaid see päring tehakse tema eest automaatselt ning
tulemus kuvatakse juba vastaval real, seejuures kriitiline ja positiivne info on visuaalselt eristatud
värvidega).
Integreerime AI-põhise sisselülitatava soovitusmootori menetluse otsuse kohta (6), mis kasutab
mustreid varasematest sarnastele tingimustele vastavatest menetlustest. AI-põhine soovitusmootor ei
ole kogu aeg aktiivne, et mitte koormata ressursse – seda saab vajadusel sisse ja välja lülitada.
26 / 73
Kompaktsem TARVIKu vasakmenüü
Joonis 8. Registripäeviku ja registritoimiku võimalik koondvaade
Lihtsustamaks TARVIKu menüüd tervikuna, näeme võimalust liita tänased Registritoimiku ja
Registripäeviku nimekirjad (7), kasutades tõhusat filtrisüsteemi koos otsingufunktsiooniga (8)
ning UX-kirjutamise abi loogilisema menüüpunkti nimetuse leidmiseks, kuid selle otsuse tegemiseks
on kahtlemata vaja põhjalikumalt analüüsi.
Ühendatud nimekirjas kuvame selgelt, millises süsteemis konkreetsed load või taotlused asuvad
(9), kui neid ei ole üleminekuperioodil veel TARVIKusse toodud.
7. Arendustööde teostamine
Tegevuse sisu Vastavalt UI disainis ja detailanalüüsis selgunud sisendile luuakse
vastavad mikroteenused ja mikroesitluskihid. Mikroteenused
liidestatakse protsessimootoriga võimaldamaks paremini juhtida
menetlusprotsesside vooge. Vastavalt vajadusele luuakse liidestused ka
väliste süsteemidega, näiteks JVIS, Äriregister, vana MTR jne.
Arendustöid teostatakse taotluste ja menetluste liikide kaupa. Nii on
menetlejal võimalik üleminekuperioodil töötada ühelaadsete loataotluste
27 / 73
ning menetlustega ühe süsteemi piires. Hoides vanade ja uute süsteemide
vahelised seosed minimaalsed, on võimalik üleminekuperioodi arendus-
kui ka menetlusprotsesse oluliselt lihtsustada.
Tagame süsteemide vahel sujuva navigeerimise rakenduse nime ja ikooni
esile tõstmisega kasutajaliideses ning rakendame põhimõtet „autendi ühe
korra“ kasutades Keycloak SSO lahendust.
Arenduse käigus järgime Scrum põhimõtteid, millest on täpsemalt
kirjutatud peatükis „3.1.1 Analüüsi, disaini ja arenduse koostöö ja
projektijuhtimise metoodika – Dual Track Scrum“.
Arendusi teostatakse piletite põhjal. Loodud pileteid rafineeritakse ehk
valmistatakse arendusteks ette regulaarselt. Lisaks funktsionaalsete
nõuete täitmisele järgitakse ka Tellija mittefunktsionaalseid nõudeid ning
üldlevinud häid tavasid, sh Clean Code printsiipe.
Teostame koodiülevaatusi kogu koodile ning rakendame vähemalt 2
silmapaari põhimõtet. Lisaks inimkontrollile rakendame võimalikult
palju automaatseid koodikontrolle, mis aitavad hoida koodis sarnast stiili
ning ennetavalt leida üles võimalikud probleemid (nt Checkstyle).
Kõik arhitektuurilised jm tehnilised lahendused dokumenteeritakse
põhjalikult Tellija keskkonnas ning vajadusel kinnitatakse Tellijaga enne
arenduste alustamist. Väliste liideste dokumenteerimiseks kasutame
OpenAPI spetsifikatsioone.
Eeldatav mõju Menetlustoode on piisavalt küps (vastuvõtu)testimiseks.
Üleminekuperioodi
tähelepanekud
Ületoomine toimub taotluste ja menetlusliikide kaupa. Arendustööde
teostamisel peetakse silmas, et tuues funktsionaalsust üle TARVIKusse,
peavad paralleelselt toimima kõik süsteemid ning menetlusprotsessid
peavad jääma terviklikuks, et menetlejate tööd mitte takistada. Tehniliste
takistuste ilmnemisel kommunikeeritakse see Tellijale, et leida parim
lahendus. Erinevate taotluste puhul võib kasutaja kasutada erinevaid
süsteeme.
Ootused Tellijale On kättesaadav küsimuste tekkimisel. Osaleb demodel ja retrodel, et
aegsasti arendatud toote osas tagasisidet anda ning arendusprotsessi
parendustes kaasa rääkida.
8. Arendustööde testimine
Tegevuse sisu Valminud arendused läbivad testimist läbi mitme kihi, ehk peale
arendustöö valmimist testib valminud tööd esialgu Pakkujapoolne
meeskond ning kui arendus läbib testimise, suunatakse arendus
Tellijapoolsesse testimisse. Kui arendus testimist ei läbi, teeb Pakkuja
vastavad parandused ning see suunatakse uuesti testimisse.
Pakkuja kogemusel käib valminud arenduste testimine kogu projekti
vältel minimeerimaks riski, et projekti lõpus tuleb korraga teostada palju
parandusi, mis seab ohtu projekti valmimise tähtaja. Seega testimist
teostatakse pidevalt ja iteratiivselt koos arendustööde valmimisega.
Valminud arenduste töökindluse ning funktsionaalsete nõuete täitmise
tagamiseks luuakse arendustööde käigus ühiktestid vähemalt 80%
28 / 73
ärifunktsionaalsuse ulatuses. Samuti lisatakse automaattestid olulistele
integratsioonidele ning tagatakse efektiivne automatsiseeritud
regressioonitestimine. Lisaks kasutame staatilisi koodianalüsaatoreid ja
sõltuvuste kontrollimise teeke, mis aitavad leida üles võimalikud
turvaprobleemid (nt SonarQube, Spotbugs).
Jõudluse tagamiseks teostatakse koormustestimine toodangule
ligilähedases keskkonnas. Koormustestide jaoks kirjutatakse skriptid ja
juhendid võmaldamaks koormusteste lihtsa vaevaga korduvalt
jooksutada.
Kuigi Pakkuja on läbinud vastavad turvalisuse koolitused ning järgib häid
tavasid oma igapäevatöös, tuleks turvalisuses veendumiseks teostada ka
turvatestimine kolmandate osapoolte poolt.
Eeldatav mõju Käesolev tegevus võimaldab veenduda arendustööde korrektsuses,
tarnimise valmiduses, aga lihtsustab ka tulevikus regressioonitestimist.
Üleminekuperioodi
tähelepanekud
Testimisel peetakse silmas, et paralleelselt töötavad mitmed süsteemid
ning testitakse kõik liidesed.
Ootused Tellijale • Osaleb vastuvõtutestimisel
• Annab testimise kohta aegsasti tagasisidet
• On kättesaadav küsimuste tekkimisel
• Korraldab kõikide uute komponentide turvatestimise
9. Arenduste tarnimine
Tegevuse sisu Arenduse alguses pannakse koostöös Tellijaga paika uute loodavate
teenuste tarneahelad, et arenduse käigus oleks võimalik Tellijale pidevalt
uusi lahendusi üle anda. Iga sprindi lõpus tehakse Tellijale demo
implementeeritud funktsionaalsustest ja tarnitakse kood koos testidega
ning nimekiri funktsionaalsustest, mida antud tarne sisaldab. See
võimaldab Tellijal varakult uut funktsionaalsust testida ning anda
võimalikult varajases faasis tagasisidet tehtud töödele. Mida varem
muudatusvajadused välja tulevad, seda lihtsam ja soodsam on neid
juurde lisada.
Uue taotluse ja menetlusprotsessi üle viimisega migreeritakse vajadusel
vanast süsteemist andmed uude süsteemi. Tarnimise alguses lülitatakse
vanas süsteemis olev funktsionaalsus välja, teostatakse
andmemigratsioon, tarnitakse uus kood ning lülitatakse uues süsteemis
funktsionaalsus sisse. Funktsionaalsuste sisse/välja lülitamiseks kasutame
lipukesi, mis võimaldab lihtsasti ja kiiresti funktsionaalsust vajadusel
peita või avalikustada. Näiteks võimaldab see tarnida toodangusse
taotluse koodi, mida pole veel mingil põhjusel soovi avalikustada. See
lihtsustab koodihalduses harude majandamist.
Eeldatav mõju Antud tegevuse järel on loodud arendused Tellijale tarnitud.
Üleminekuperioodi
tähelepanekud
Peame oluliseks, et arenduste tarnimisega käib kaasas ka kasutajate
koolitus ja tehniline tugi ning kommunikatsioon, mida oleme valmis
koostöös Tellijaga planeerima ja korraldama.
29 / 73
Ootused Tellijale • Parima tulemuse tagamiseks testib/valideerib operatiivselt
tarnitavat lahendust agiilselt
• Annab tagasisidet lahenduste osas (kas tarnitav lahendus on
korrektne või mitte, muudatusvajadused, täiendused,
edasiarendused jms)
• Paigaldab jooksvalt tarnitava lahenduse (selle automatiseerimine,
CI/CD)
30 / 73
3.3 Mikroteenuste arhitektuur
Arendajad on pidevalt otsinud uusi viise, kuidas infosüsteeme paremini ehitada. Üks populaarne
lähenemine tänapäeval on viljeleda mikroteenusarhitektuuri. Küll aga ei tohiks
mikroteenusarhitektuur olla omaette eesmärk, vaid vahend oma eesmärkide saavutamiseks. Antud
peatükis räägime, mis on mikroteenusarhitektuur, käime läbi põhiprobleemid, mida
mikroteenusarhitektuur lahendab, milliseid probleeme see võib tekitada, kuidas tekkinud probleeme
omakorda adresseerida ning kuidas minna üle mikroteenusarhitektuurile.
3.3.1 Mis on mikroteenusarhitektuur?
Mikroteenusarhitektuur on arhitektuuristiil, kus süsteem koosneb mitmetest väikestest
autonoomsetest teenustest, mis suhtlevad teineteisega üle kindlaks määratud API. Iga teenus on
loodud lahendamaks mingit konkreetset probleemi ning seda saab iseseisvalt tarnida. Samuti on iga
teenus oma programmeerimiskeele, andmesalvestus- ja muude tehnoloogiate valikul teistest
teenustest sõltumatu. Selline lähenemine võimaldab iga teenuse puhul kasutada just selle probleemi
lahendamiseks mõeldud parimaid tööriistu.
3.3.2 Peamised eelised
Ühtegi arhitektuuristiili ei tasu kasutada lihtsalt kasutamise pärast, vaid see peaks aitama lahendada
mingeid probleeme. Antud peatükis arutame, mis probleeme mikroteenusarhitektuuri kasutamine
lahendab ja kuidas seda rakendada kasutades parimaid praktikaid.
Autonoomsus
Korrektse lahenduse korral on iga mikroteenus autonoomne. See tähendab, et mikroteenus on
piisavalt eraldiseisev, et seda saaks tarnida teistest teenustest sõltumatult. Andmete saatmine üle
võrgu aitab jõustada teenuste vahelist eraldatust. Sellest üksi aga ei piisa. Oluline on ka see, mis
andmeid teenus välja annab ja mida mitte. Kui teenust pakkuv mikroteenus edastab tarbivatele
mikroteenustele liiga palju sisemist infot, siis teenuse tarbijad muutuvad pakkuva teenuse sisemisest
ülesehitusest sõltuvaks, mis omakorda vähendab teenuste autonoomsust.
Agiilsus
Sõltumata muudatuse suurusest nõuab monoliitses rakenduses muudatuse tegemine kogu süsteemi
ehitamist ja paigaldamist. See omab suurt mõju kogu süsteemile, mistõttu võtavad ettevaatusabinõude
kasutamised, näiteks kogu süsteemi testimine, märgatavalt aega. Selle aja jooksul võib aga valmida
juba uusi funktsionaalsusi, mis samuti vajavad testimist. See aga tähendab, et üks hetk, kui ollakse
valmis uut versiooni tarnima, sisaldab kood juba suurel hulgal muudatusi. Mida rohkem aga on
muudatusi seda suurem on tõenäosus, et midagi võib katki minna ning seda raskem on tuvastada
probleemi põhjust.
Mikroteenuste puhul on nende autonoomsuse tõttu võimalik teha muudatus üksnes ühes teenuses ning
tarnida see teistest sõltumatult. See võimaldab uue funktsionaalsusega kiiremini toodangusse minna.
Vea ilmnemise korral on seda aga lihtsam tuvastada ning konkreetse teenuse varasem versioon
taastada.
Skaleeritavus
Jõudluse suurendamiseks võib rakendusest käivitada mitu instantsi. Monoliitse rakenduse puhul
tähendab see kogu rakenduse skaleerimist, mis ei ole ressursikasutuse vaates mõistlik. Mikroteenuste
puhul on võimalik luua lisainstantse üksnes sellest teenusest, mille poolt pakutavat funktsionaalsust
on vaja üles skaleerida. Sarnaselt saab vähendada instantse nendest teenustest, mis nii palju ressursse
31 / 73
ei vaja. Samuti pole monoliitse rakenduse korral võimalik kergesti tuvastada alammoodulite
ressursivajadusi.
Joonis 9. Teenustest kindla arvu instantside loomine vastavalt vajadusele
Vastupidavus
Üks võimalus muuta süsteeme tõrkekindlamaks, on tekitada selle komponentide vahele kindlad
piirid, mis takistavad probleemide levikut. Kui monoliitses rakenduses lakkab teenus töötamast, siis
lakkab töötamast ka kogu süsteem. Kui aga üks mikroteenus lakkab töötamast, siis korrektse
ülesehituse puhul esineb probleem vaid teatud funktsionaalsuses, kuid ülejäänud süsteem töötab
edasi.
Siiski, tuleb aru saada, et süsteemi jagamine väikesteks teenusteks üksi süsteemi vastupidavust ei
tõsta. Teenused peavad olema teineteisest ka piisavalt sõltumatud suutmaks jätkata tööd, kui mõni
teenus enam ei vasta. Selleks peavad teenused omama suurt sisemist ühtekuuluvust kuid lõtvu seoseid
teiste teenustega. Sellest räägitakse lähemalt peatükis Mikroteenusteks jaotamine. Lisaks teistele
teenustele võib lakata töötamast ka võrk üle mille teenused omavahel suhtlevad. Antud teemat on
täpsemalt lahatud peatükis Võrguprobleemid.
Tehnoloogiline heterogeensus
Iga mikroteenus on mõeldud lahendama mingit konkreetset probleemi. Erinevate probleemide
lahendamiseks võib olla aga vaja kasutada erinevaid tehnilisi lahendusi. Monoliitse rakenduse korral
oleme me kammitsetud nende tehnoloogiliste valikutega, milles rakendus on üles ehitatud. Samuti on
uute tehnoloogiate kasutuselevõtu mõju terviksüsteemile suurem.
Mikroteenusarhitektuuri puhul võib aga iga teenus kasutada erinevat tehnoloogilist pinu. Näiteks on
kõik TARVIKu mikroteenused loodud kasutades Java programmeerimiskeelt. Kui aga soovitakse
kasutusele võtta mõni masinõppelahendus, mille jaoks hetkel parimad teegid on loodud näiteks
Pythonis, siis saab konkreetselt selle teenuse jaoks kasutusele võtta täiesti teise
programmeerimiskeele.
Taaskasutatavus
Monoliitsete rakenduste puhul implementeerib iga rakendus enda jaoks vajalikku funktsionaalsust
uuesti. See tähendab, et sama koodi kirjutatakse üha uuesti ning kui selle loogikat on vaja muuta, siis
tuleb seda teha mitmes rakenduses. Näiteks on X-tee liides arendatud valmis nii MTR kui ka JVIS
rakendustes. Kui mõlemas rakenduses oleks vaja hakata üle X-tee lisaandmeid küsima, siis tuleb
vastav arendus teha mõlemas rakenduses eraldi.
Mikroteenuste puhul kapseldatakse loogika eraldi teenusesse, mida teised teenused tarbida saavad.
Võtame näiteks X-tee mikroteenuse. Iga rakendus, mis peab X-tee poole pöörduma, ei pea sisaldama
keerukat SOAP-päringute seadistamise loogikat. Selle asemel võivad nad pöörduda X-tee
32 / 73
mikroteenuse poole, kus antud probleem on ühe korra lahendatud. Samuti saavad tarbivad teenused
ligipääsu ka teistele X-tee päringutele, mida X-tee mikroteenusesse juurde arendatakse.
3.3.3 Peamised probleemid
Samal ajal kui mikroteenusarhitektuur lahendab osad probleemid, võivad tekkida uued, mida näiteks
monoliitsete rakenduste puhul ei esinenud. Antud peatükis käime läbi tekkivad probleemid ning
pakume välja võimalikud lahendused.
Hajutatud transaktsioonid
Transaktsioone kasutatakse andmete tervikluse tagamiseks - kõik tehtud muudatused kas talletatakse
või lükatakse tagasi. See aitab vältida vigase andmekoosseisu teket, kus osad muudatused on
salvestatud ja osad mitte. Selle saavutamiseks rakendavad andmebaasimootorid rida omadusi
(ACID), mis antud võimekust tagavad.
Monoliitses süsteemis on transaktsiooni haldamine üldjuhul lihtne, kuna transaktsioon toimub ühe
konkreetse rakenduse protsessi raames. Mikroteenusarhitektuuri puhul, kus igal mikroteenusel võib
olla oma andmebaas, läbivad päringud mitmeid rakendusi, mis omakorda võivad teostada
andmemuudatusi mitmes andmebaasis. Selleks, et vältida vigase andmekoosluse teket, kus ühes
mikroteenuses andmed salvestati, aga teises mikroteenuses mitte, tuleb läbi mõelda kuidas süsteem
erandjuhtude korral tervikuna käitub.
Kõige lihtsam variant on see, kui muudatuste talletamine ei ole hajutatud mitme mikroteenuse peale
laiali. Seda aitab saavutada mikroteenuste piiride korrektne paikapanek. Täpsemalt räägitakse antud
teemast peatükis Mikroteenusteks jaotamine. Hajutatud andmete talletamine on teatud juhtudel aga
vältimatu. Sellisel juhul tuleb kaaluda alternatiivseid variante.
Üheks hajutatud transaktsioonide haldamise võimaluseks on kasutada kahe-faasilist kinnitamist (two-
phase commit, 2PC). 2PC puhul algatab koordinaator (transaktsioonihaldur) uue transaktsiooni ja
küsib igalt andmebaasilt, kas see saab antud andmed talletada. Selleks veendumiseks tuleb
andmebaasidel lukustada vajalikud tabelid, read või väljad. Kui muudatuste talletamine on võimalik,
siis teavitatakse sellest koordinaatorit. Kui kõik andmebaasid on andnud positiivse vastuse, teavitab
koordinaator kõiki andmebaase, et muudatused võib lõplikult talletada (commit). Kui mõni
andmebaas annab negatiivse vastuse, siis koordinaator annab andmebaasidele tagasivõtmise käsu
(rollback).
2PC negatiivse küljena võib aga välja tuua selle, et kui mõni andmebaas peaks lakkama töötamast
või mõnel muul põhjusel mitte vastama, siis jääb koordinaator ootama ning oma toiminguid ei saa
lõpetada ka teised antud transaktsiooniga seotud andmebaasid. See omakorda aga tähendab, et
andmebaasilukud jäävad peale, mis hakkab takistama juba järgmiste päringute tööd, mis järjekorras
ootavad. Samuti saab koordinaatorist keskne teenus, mille tööst sõltuvad kõik teised teenused. See
vähendab märgatavalt mikroteenuste autonoomsust ja viib need teineteisega suurde sõltuvusse.
Teine võimalus on võtta kasutusele SAGA-muster. SAGA on jada mikroteenuste lokaalsetest
transaktsioonidest. Iga lokaalse transaktsiooni raames uuendatakse ühe mikroteenuse andmebaasi.
Kui muudatused õnnestuvad, siis käivitatakse järgmise mikroteenuse poolt tehtavad
andmebaasimuudatused. Kui lokaalne transaktsioon aga ebaõnnestub, siis käivitatakse
kompenseerivad tegevused, mis juba eelnevalt lõpetatud lokaalsete transaktsioonide muudatused
tagasi võtavad. SAGA mustrit on võimalik implementeerida kasutades protsessimootorit, mis tagab
hea ülevaate põhivoo ja kompenseerivatest tegevustest. SAGA mustri kasutamist protsessimootoris
on käsitletud peatükis Kompenseerivad tegevused.
33 / 73
Võrguprobleemid
Monoliitsetes süsteemides käitatakse suur osa äriloogikast ühe rakenduse piires.
Mikroteenusarhitektuuri puhul toimub aga suur osa andmevahetusest üle võrgu. Seetõttu tekib
vajadus pöörata suuremat tähelepanu võrguliiklusest tingitud probleemidele. Teenused, mille pihta
päringuid tehakse, ei pruugi olla kättesaadavad või vastavad tavapärasest oluliselt aeglasemalt.
Esimesel juhul on veaolukorda lihtsam tuvastada ning sellele ka reageerida. Aeglaselt vastavate
teenuste puhul kõik justkui töötaks, aga reaalsuses pole süsteem kasutatav – selle tuvastamine on
palju keerulisem.
Esimese, kõige lihtsama abimeetodina tuleks määrata päringutele mõistlikud ajapiirangud (timeout),
mis määravad ära, kui kaua päring võib üldse kesta. See aitab vabastada ressursse, lõpetades
hangunud päringud. Samuti aitab see vältida süsteemi tõrgete kaskaadistumist, kus süsteem justkui
töötab, aga kõik teenused ootavad tegelikkuses vastuseid, mida nad kunagi ei saa. See võib omakorda
põhjustada ootamatu teenuste töötamise lõppemise tulenevalt vabade ressursside puudumisest.
Kui alamteenus enam ei vasta, siis pole mõtet sinna rohkem päringuid teatud aja jooksul saata, vaid
tagastada kliendile kohe viga ning lasta alamteenusel taastuda. Selleks kasutatakse kaitselüliteid
(circuit breaker). Kui järjestikuste ebaõnnestunud päringute arv ületab ette antud piirmäära, siis
päringuid enam edasi ei saadeta ning mõne aja jooksul ebaõnnestuvad kõik alamteenusele saadetavad
päringud. Kui oodatav aeg saab läbi, siis hakkab kaitselüliti mõningaid päringuid läbi laskma
kontrollimaks, kas ühendus on taastunud. Kui kontrollpäringud õnnestuvad, siis jätkab kaitselüliti
normaalset tööd.
Joonis 10. Kaitselüliti tööpõhimõte
Idempotentsus
Kuna mikroteenused suhtlevad üle võrgu, siis võib juhtuda, et päring jõudis alamteenusesse kohale,
aga vastus päringu algatajale mitte. Sellisel juhul võidakse sama päring uuesti teostada. Olenevalt
päringu tüübist võib see tekitada probleeme. Näiteks kui päringu tulemusena saadetakse välja uus
email, võib juhtuda, et sama emaili saadetakse mitu korda. Sellise probleemi vältimiseks on mõned
võimalused nii saatja kui vastuvõtja poole jaoks.
Kui toiming on asünkroonne, siis võib kasutada järjekordi (queue) nagu nt RabbitMQ, koos
transaktsiooniga – andmebaasimuudatus ja sõnumi järjekorda panemine tehakse ühe atomaarse
toiminguna kasutades 2PC-d. See garanteerib, et sõnum pannakse järjekorda üksnes siis, kui muud
sammud samuti õnnestuvad. See aitab vältida sama sõnumi mitmekordset väljasaatmist.
Hajutatud transaktsioonide peatükis sai aga välja toodud 2PC negatiivsed küljed. Antud juhul saab
selle vältimiseks kasutada Transactional outbox mustrit, kus ühe transaktsiooni koosseisus salvestab
teenus esmalt andmebaasimuudatused koos välja saadetava sõnumiga andmebaasi. Seejärel saadab
teine eraldiseisev protsess andmebaasi salvestatud sõnumi järjekorda.
34 / 73
Järjekorrast andmete lugemine peab sellisel juhul toimuma samuti transaktsiooni koosseisus. Tarbiv
teenus loeb järjekorrast sõnumi ja teostab vajalikud toimingud. Kui antud toimingud õnnestuvad, siis
sõnum kustutatakse. Ebaõnnestumise korral võtab teenus tehtud muudatused tagasi ning sõnum
pannakse järjekorda tagasi.
Kui järjekorda pole aga võimalik või mõistlik kasutada, siis tuleks tagada päringute idempotentsus.
See tähendab, et sama päringu mitmekordsel saamisel süsteemi olek ei muutu. Selleks antakse kaasa
tunnus(ed), mille abil saab alamteenus veenduda, kas antud tunnusega seotud toimingud juba teostati
või mitte. Näiteks jätab teenus meelde, et teatud tüüpi email on antud aadressile juba saadetud ning
uuesti seda pole vaja enam saata.
Jälgitavus
Võttes kasutusele mikroteenusarhitektuuri, on vaja ühel hetkel jälgida kümnete mikroteenuste tööd
ja nende vahelist suhtlust. Selleks, et saada hea ülevaade süsteemis toimuvast on vaja koondada laiali
olev telemeetria info ühte tsentraalsesse kohta, mis võimaldab andmeid analüüsida ja informatsiooni
otsida. Kui kliendi poolt algatatud päring läbib mitmeid teenuseid, millest võib joosta mitmeid
instantse, siis on vaja telemeetria andmetele lisada juurde unikaalne kirje, mille abil saaks erinevates
rakendustes tekkivad kirjed kokku agregeerida. See võimaldab lihtsasti jälitada päringut läbi mitmete
teenuste, lihtsustab logide uurimist ning võimaldab kiiresti probleeme tuvastada.
Turvalisus
Tänapäeval on levinud praktika, et kogu suhtlus kliendi ja serveri vahel toimub üle turvatud võrgu
kasutades TLS-i. Mikroteenusarhitektuuri puhul tekib juurde aga palju uusi rakendusi, mis samuti
suhtlevad teineteisega üle võrgu. Tavalise HTTPS ühenduse puhul veendub klientrakendus, et
serverrakendus on see, mis ta väidab enda olevat, aga mitte vastupidi. Enamasti toimub see suhtlus
küll sisevõrgus, kuid Zero Trust arhitektuuri põhimõtetest lähtuvalt ei tohi usaldada ühtegi kasutajat,
seadet ega süsteemi isegi siis, kui nad asuvad kohalikus võrgus. Siinkohal tuleb appi mTLS, mis
tagab, et mõlemad osapooled on need, kes väidavad end olevat.
Mikroteenusarhitektuuri puhul on seega vaja turvata kümnete teenuste vahelist suhtlust. Selle
probleemi lahendamiseks on võimalik kasutada näiteks Istiot, tarkvarakihti, mis aitab turvata
mikroteenustel põhinevaid rakendusi ilma, et oleks vaja muuta rakenduste lähtekoodi. Selleks lisab
Istio Kubernetese Podidele juurde sidecar-proxy, mis krüpteerib väljuvad päringud ja dekrüpteerib
sissetulevad päringud, nii et päringu sisu pole välistele osapooltele arusaadav täites MFN-is välja
toodud TLS valmiduse nõude.
3.3.4 Mikroteenusteks jaotamine
Eelnevat kirjeldasime mikroteenusarhitektuuri kasulikke omadusi, aga ka sellega kaasnevat
lisakeerukust ning probleeme. Järgmistes peatükkides anname ülevaate headest praktikatest süsteemi
mikroteenusteks jaotamisel. Heal mikroteenusel on mitmeid omadusi, millest vast kõige olulisemad
on lõdvad seosed väliste teenustega ning suur sisemine ühtekuuluvus.
Lõdvad seosed
Lõdvad seosed (loose coupling) tähendavad, et teenuste vahel on vähe sõltuvusi, kui üldse. Sellisel
juhul ei nõua ühe teenuse muutmine teiste teenuste muutmist, mis on mikroteenuste üks peamisi
eesmärke. Lõdvalt seotud teenused teavad teistest teenustest nii vähe kui võimalik. Samuti suhtlevad
sellised teenused teineteisega minimaalselt, sest lisaks jõudlusprobleemide tekkele võivad palju
suhtlevad teenused olla teineteisega tihedalt seotud, mis tähendab, et me ei pruugi saada neid
teenuseid eraldi tarnida.
35 / 73
Joonis 11. Tihedalt ja lõdvalt seotud teenused
Suur ühtekuuluvus
Suur ühtekuuluvus (high cohesion) tähendab, et igal teenusel on konkreetne kitsas ja selge vastutusala
ning kõik teenuse funktsioonid ja andmed kuuluvad loogiliselt kokku. See võimaldab muuta loogikat
vajadusel ühes kohas ning tarnida muudatused võimalikult kiiresti. Kui sama loogika on jaotatud
mitmesse teenusesse laiali, siis tuleb muudatusi teha mitmes teenuses ja võib-olla need ka koos
tarnida. Sellisel juhul pole tegu mitte mikroteenustega vaid hajutatud monoliidiga.
Domeenipõhine disain
Mikroteenuste piiride määratlemisel on domeenipõhine disain (DDD) tõhus lähenemine, kuna see
keskendub äriloogikale ja domeeni mõistmisele. DDD aitab vältida teenuste lõhkumist tehniliste või
juhuslike piiride järgi, keskendudes selle asemel äriväärtusele. Esimene samm on ärivaldkonna
kaardistamine ning domeeni ekspertidega koostöös ühise sõnavara loomine. Domeeni võib omakorda
jagada väiksemateks spetsiifilisemateks alamdomeenideks. Seejärel jaotatakse domeen selgelt
piiritletud loogilisteks üksusteks (Bounded Context), mille sees mõisted ja reeglid on üheselt
mõistetavad. Iga loogiline üksus on hea kandidaat iseseisvaks mikroteenuseks. Tähtis on leida
loomulikud teenuste piirid, kus muutused ühes teenuses ei mõjutaks teisi. Mikroteenused peavad
omama selget vastutust ning mitte jagama andmebaase teiste teenustega. Kommunikatsioon erinevate
mikroteenuste vahel peab toimuma kindlalt piiritletud API kaudu. Selline lähenemine võimaldab
hõlpsasti lisada uusi komponente või vajadusel olemas olevaid välja vahetada.
Monoliidi lammutamine
Rakenduste üleviimine uutele tehnoloogiatele on aeganõudev protsess. Vana süsteemi ümber
kirjutamine võib võtta aastaid. Selle asemel, et oodata, kuni uus süsteem täielikult valmis saab, võib
sellega hoopis järkjärguliselt toodangusse minna. Strangler Fig muster võimaldab sujuvat ja
kontrollitud moderniseerimist, säilitades süsteemi töökindluse kogu protsessi vältel. Esmalt
identifitseeritakse selged ärifunktsioonid või domeenid, mida saab eraldada ilma kogu süsteemi
korraga ümber kirjutamata (vt peatükki Domeenipõhine disain) ning luuakse nende jaoks iseseisvad
mikroteenused, millel on oma andmehoidla ja API. Pääsulüüsi (API Gateway) abil suunatakse liiklus
kas vana või uue teenuse poole sõltuvalt funktsioonist. Järk-järgult kantakse ka andmed üle uutele
teenustele ning vanas süsteemis vastavad komponendid deaktiveeritakse. Andmete migreerimiseks
saab kasutada nt SQL-is kirjutatud migratsiooniskripte koos Liquibase-ga, mis võimaldab
migratsioone versioneerida. Aja jooksul väheneb monoliidi roll, kuni see muutub täielikult
asendatuks.
36 / 73
Joonis 12. Strangler Fig muster
3.3.5 Mikroteenustel põhineva süsteemi arhitektuur
Võttes aluseks hankes alusdokumentides oleva arhitektuuri visiooni dokumendi, olemasolevat
süsteemi kirjeldava arhitektuuri joonise, KeMITi IT-profiili ning mittefunktsionaalsed nõuded,
pakume antud peatükis välja Pakkuja poolse arhitektuuri visiooni. Samuti võtame arvesse infotunnil
välja toodud asjaolu, et praeguseks implementeeritud mikroteenused suhtlevad teineteisega kasutades
HTTP-d, mitte AMQP protokolli ning seda ei soovita muuta. Küll aga jääb AMQP kasutusse
tegevuslogide saatmiseks praegusel kujul. Samuti kasutame AMQP protokolli uute asünkroonsete
tegevuste puhul nagu näiteks protsessimootoriga suhtlemine.
Diagrammil on välja toodud need teenused, mis hetkel teadaolevalt eksisteerivad. Loodavate
mikroteenuste koosseis selgub alles analüüsi faasis.
Süsteemi arhitektuur
Antud peatükis kirjeldatakse süsteemi arhitektuuri. Mikroesitluskihtide ja Protsessimootori
arhitektuur on kirjeldatud allpool olevates peatükkides. Kolme punktiga (“...”) on näidatud, et lisaks
teada olevatele teenustele kuuluvad siia ka analüüsi käigus selguvad ning teistesse domeenidesse
kuuluvad teenused.
37 / 73
Joonis 13. Mikroteenusarhitektuuril põhineva TARVIKu arhitektuurijoonis
• Pääsulüüs - Kogu suhtlus välismaailma ja mikroteenuste vahel toimub läbi pääsulüüsi.
Pääsulüüs kontrollib, kas kasutaja poolt päringuga kaasa antud token on korrektne ning
vastavalt sellele suunab päringu edasi õigele mikroteenusele või tagastab vea. Kuna tegu on
keskse komponendiga, siis tuleb antud teenus hoida võimalikult lihtne, vältides äriloogika
lisamist antud kihti. Samuti peab sellest kindlasti käivitama mitu instantsi, kuna vastasel juhul
on antud teenuse maha kukkumise korral terve süsteem kättesaamatu.
• Põhiteenused - Teenused, mis sisaldavad ärispetsiifilist funktsionaalsust.
38 / 73
• Tugiteenused – Teenused, mis pakuvad tuge põhiteenustele pakkudes vajalikke teenuseid ja
liidestusi
o Autoriseerimine mikroteenus – Tegeleb rollide ja privileegide haldamisega. Siin
pannakse paika, mis õigused mingi rolli omamisega saadakse.
o X-tee adapter mikroteenus – Pakub liidest välistele süsteemidele info pärimiseks
TARVIKust üle X-tee. Selle teenuse kaudu ei küsi TARVIK andmeid üle X-tee.
o X-tee mikroteenus – Pakub liidest TARVIKu sisemistele mikroteenustele andmete
pärimiseks välistest süsteemidest üle X-tee (nt rahvastikuregistrist ja äriregistrist).
Võimaldab mikroteenustel teha X-tee päringuid ilma, et peaksid implementeerima X-
tee spetsiifilist loogikat.
o Isikud mikroteenus – Haldab süsteemis (nt majandustegevusteadetel) olevaid isikuid
ja nende kontaktandmeid (aadress ja telefon). Vajadusel küsib ja uuendab andmeid
rahvastikuregistrist üle X-tee.
o Failid mikroteenus – Pakub failide üleslaadimise ja allalaadimise teenust.
o Klassifikaatorid – Teenus haldab klassifikaatoreid, mida kasutatakse üle süsteemi.
Tagab, et kõikidel teenustel on kasutada täpselt samad klassifikaatorid.
o Teavitused mikroteenus – Pakub sisemistele teenustele funktsionaalsust, mille abil
saab välja saata erinevat tüüpi teavitusi (nt email, SMS).
o Ärireeglid mikroteenus - Võimaldab hallata ärireegleid kasutades DMN-i. Ärireeglite
abil saab mõjutada süsteemi või protsessimootori käitumist.
o Allkirjastamine mikroteenus – Vastutab mikroteenusele ette antud dokumentide
allkirjastamise eest kasutades riiklikku SiGa teenust.
o Protsessimootor mikroteenus – Teenus, mis käitub vahekihina protsessimootori ja
teiste mikroteenuste vahel. Vaata täpsemalt protsessimootori arhitektuuri peatükist.
o Logid mikroteenus – Kogub kokku teenuste poolt RabbitMQ-sse saadetud toimingute
logid (auditlogid) ning talletab need baasi. Pakub liidest logide vaatamiseks.
Võimaldab administraatoritel saada ülevaate kasutajate tegevustest.
• Üldised teenused – Teenused, mis ei oma spetsiifilisi teadmisi TARVIKu kui süsteemi kohta.
o Keycloak – Identiteedi ja ligipääsuhaldamise süsteem, mis tegeleb kasutajate
autentimisega ja ligipääsuõiguste kontrollimisega. Suunab kasutaja edasiseks
autentimiseks riigi poolt pakutavasse GovSSO-sse.
o X-tee lüüs - KeMITis kasutatav rakendus, läbi mille suhtlevad sisemised rakendused
X-tee turvaserveriga.
o X-tee turvaserver – Rakendus, mille kaudu suheldakse üle X-tee teiste
teenusepakkujatega (nt rahvastikuregister ja äriregister). Turvaserveri peamine
ülesanne on päringute vahendamine viisil, mis tagaks nende hilisema tõendusväärtuse.
o S3 failihoidla – MinIO rakendus, mis implementeerib S3 liidest, mille kaudu saab
lisada ja küsida faile.
o SMTP – Emaili server.
o Protsessimootor – Teenuste komplekt, mis on mõeldud BPMN-is kirjeldatud
protsesside jooksutamiseks. Vaata täpsemalt protsessimootori peatükis.
o RabbitMQ - Sõnumivahetusteenus, mida kasutatakse süsteemi erinevate
komponentide vaheliseks asünkroonseks suhtluseks. TARVIKu puhul saadetakse
selle kaudu näiteks toimingute logisid. Samuti käiks üle selle suhtlus ka
protsessimootoriga.
• Välised teenused
39 / 73
o GovSSO – Riigi poolt pakutav SSO teenus, mille abil asutus saab oma e-teenuses
ühekordse sisselogimisega autentida ID-kaardi, Mobiil-ID, Smart-ID ja Euroopa Liidu
eID kasutaja.
o X-tee - Riiklik andmevahetusplatvorm, mis võimaldab turvalist ja tõestusväärtust
tagavat internetipõhist andmevahetust liitunud asutuste vahel.
o SMS teenusepakkuja - Väline teenusepakkuja, kes pakub API-t, üle mille on võimalik
saata kasutajatele SMS-e (nt Telia, Twilio, vms).
o SiGa – Riiklik allkirjastamise teenus, mis võimaldab luua allkirjastatud ümbrikke.
Toimingud tehakse kasutaja saadetud dokumendiräside põhjal.
Jälgitavuse arhitektuur
Antud peatükis on ära kirjeldatud, kuidas tagatakse ülevaade süsteemi tööst.
Joonis 14. Jälgitavuse arhitektuur
Telemeetria andmete kogumiseks on välja töötatud ja laialdaselt kasutusel gRPC-l põhinev OTLP
protokoll, mis on disainitud kogumaks ja edastamaks telemeetria andmeid nagu logid (logs),
meetrikad (metrics) ja jäljed (traces). Logide puhul on tegemist tekstiliste andmetega, mida
rakendused maha kirjutavad. Meetrikad on ajas mõõdetavad andmepunktid rakenduse oleku,
jõudluse vms hindamiseks. Jäljed kirjeldavad konkreetse päringu voogu läbi hajutatud süsteemi
aidates mõista, päringute teekonda ja kulunud aega. TARVIKus loodud ja loodavad mikroteenused
kasutavad IT-profiilis välja toodud Spring Boot raamistikku, mis toetab telemeetria andmete saatmist
OTLP protokolli põhjal. Arhitektuuri visiooni dokumendis on ka mainitud FluentBiti ning IT-profiilis
Elasticsearchi. Lähtudes nendest teadmistest pakume välja järgmine koosseisu jälgitavuse
tagamiseks. Võimalikult palju on üritatud ära kasutada olemas olevaid lahendusi ning Elastic-u
tooteperekonda kuuluvaid.
• Mikroteenus - Iga mikroteenus saadab välja OTLP gRPC standardile vastavaid päringuid
meetrikate ja jälgede kohta. Logide puhul kirjutatakse logid standardväljundisse, kust
FluentBit neid lugeda saab. Logide formaat järgib ECS spetsifikatsiooni (iga logikirje on
üherealine JSON objekt, isegi veateadete korral) lihtsustamaks nende töötlemist
Elasticsearchi poolt. Samuti sisaldab iga logikirje trace_id ja span_id väärtusi, võimaldades
agregeerida kokku logikirjed, mis on seotud mitut mikroteenust läbinud päringuga.
• FluentBit – Alates versioonist 2.0 toetab FluentBit OTLP protokolli telemeetriaandmete
saatmiseks. Pakutavas visioonis kogub FluentBit rakenduse logiandmeid konteineri logifailist
ning saadaks edasi Elasticsearchi. Samuti võtab see vastu meetrika ja jälgede andmed ning
edastab Elastic APM Serverile. Me ei kasutaks OTLP protokolli logide kogumiseks, kuna
võrreldes failist lugemisega oleks see ressursinõudlikum ja ühenduse puudumise korral
40 / 73
võivad osad logid kaduma minna. Meetrikate ja jälgede puhul see aga probleeme ei
põhjustaks.
• APM Server – Olemasolevat tehnilist pinu tuleks täiendada Elastic-u poolt pakutava APM
Server-iga, mis võimaldab vastu võtta OTLP protokolliga saadetud andmeid ning talletada
need sobival kujul Elasticsearchi.
• Elasticsearch - Elasticsearch on andmebaas ja otsingumootor, mis võimaldab efektiivselt
otsida ja analüüsida suurtes kogustes andmeid.
• Kibana – Kibana abil on võimalik otsida rakenduste logisid, jälgida päringute vooge läbi
hajutatud süsteemi ning visualiseerida meetrikaid. Lisaks on võimalik kirjeldada ära reeglid,
millele meetrikad peavad vastama ning mittevastavuse korral saab välja saata teavitusi. See
võimaldab kiiresti reageerida võimalike süsteemi vigade korral.
Joonis 15. Jälgitavuse kasutajaliidese näidis Kibanas
41 / 73
Joonis 16. Kibana poolt pakutavad vaated jälgede visualiseerimiseks
Mikroteenuste arhitektuur
Loodavad mikroteenuseid käitatakse Kubernetese klastris, mis asub sisevõrgus. Lähtuvalt Zero Trust
arhitektuuri põhimõtetest ei tohiks aga usaldada ka teenuseid, mis asuvad sisevõrgus. Veendumaks,
et nii päringu algataja kui ka vastuvõtja on need, kes nad väidavad end olevat saab kasutada mTLS-i
(mutual TLS). mTLS on meetod vastastikuseks autentimiseks, kus mõlemad osapooled esitavad TLS
sertifikaadi enda õigsuse tõestamiseks ning kogu ülejäänud andmevahetus toimub kasutades juba
krüpteeritud sõnumeid. Selleks, et antud loogikat ei peaks igas mikroteenuses eraldi implementeerima
on võimalik kasutusele võtta nt Istio, mis selle probleemi Kubernetese tasemel ära lahendab. Lisaks
sõnumite turvalisele andmevahetusele pakub Istio ka kaitselülitite funktsionaalsust (loe lähemalt
peatükist Võrguprobleemid). Alljärgnevalt on välja toodud, kuidas Istio ja mikroteenused
Kubernetese klastrisse sobituvad.
42 / 73
Joonis 17. Istio tööpõhimõte Kubernetese platvormil
Iga mikroteenus jookseb oma konteineris, mis omakorda asub Podis. Istio lisab igale Podidele juurde
Istio proxy teenuse, mis hakkab vahendama päringuid teenuste vahel. Vajalike võtmete ja seadistuste
haldamise ning jagamisega tegeleb Kubernetesesse lisatav laiendus Istiod. Selline lahendus
võimaldab lisada mTLS-i toe ilma, et mikroteenused sellest ise teadlikud peaksid olema. Istiot
kasutavad Kubernetese klastris mitmed riigiasutused nagu nt Riigi Infosüsteemide Amet ning
Regionaal- ja Põllumajandusministeerium.
Pea iga mikroteenusega on seotud oma andmebaas. See omakorda tähendab, et mikroteenuse pidevalt
tööl olemiseks peab ka andmebaas kogu aeg kättesaadav olema. Rakenduste puhul jooksutatakse neid
tihtipeale mitme õla peal võimaldamaks suunata päringuid töötava instantsi pihta. Andmebaaside
puhul on lahendus veidi keerulisem, kuna nendega on seotud andmed, mida peab mitme instantsi
vahel sünkroonis hoidma. Samuti peab andmeid iga teatud aja tagant varundama võimaldamaks nende
taastamist kõikide andmebaaside hävinemise korral.
Arhitektuuri visiooni dokumendis on soovitatud majutada andmebaasid eraldiseisvates
virtuaalmasinates. Kubernetese alguaegadel oli see levinud praktika. Tänaseks on aga välja töötatud
mitmeid lahendusi haldamaks andmebaase Kubernetese klastris võimaldades hallata kõiki süsteemi
tööks vajalikke komponente ühes kohas. Siinkohal tuleb appi CloudNativePG, mis on mõeldud
PostgreSQL andmebaasisüsteemi kõrgkäideldavana jooksutamiseks Kubernetese klastris.
CloudNativePG lihtsaks ja kiireks kasutuselevõtuks on loodud vastav Helm chart.
Joonis 18. CloudNativePG tööpõhimõte Kubernetese platvormil
Kõrgkäideldavuse tagamiseks loob CloudNativePG Operaator mitu andmebaasi instantsi, millest üks
on primaarne ja teised ootel olekus. Kui primaarse andmebaasiga peaks midagi juhtuma ning see pole
enam kättesaadav, siis muudetakse üks ootel olev andmebaas primaarseks ja mikroteenus saab ilma
tõrgeteta oma tööd jätkata.
Andmete lisamise ja muutmise päringud suunatakse primaarse baasi vastu, mis omakorda replikeerib
andmemuudatused edasi ootel olevatele andmebaasidele tagades, et kõikides andmebaasides on sama
seis. Koormuse jaotamiseks suunatakse lugemisoperatsioonid ootel olevate andmebaaside vastu.
Andmete varundamiseks saadab CloudNativePG WAL (Write Ahead Log) logid iga teatud aja tagant
S3 andmehoidlasse. Talletatud logide pealt on võimalik taastada andmebaasi varasem seis kindlal
ajahetkel.
43 / 73
3.3.6 Menetlusprotsesside loomine
Analüüsi käigus tuvastatakse taotluste ja menetlusprotsesside tüüpilised sammud ja
funktsionaalsused ning selle põhjal luuakse taaskasutatavad plokid (komponendid või
mikroteenused), näiteks oleku muutmine, digiallkirjastamine, tagasiside andmine, failide laadimine
jms. Need plokid opereerivad taotluse tüübist sõltumatult. Menetlusprotsesside koostamisel
kasutatakse protsessimootorit, mis täidab orkestraatori rolli ning kutsub välja vajalikke
mikroteenuseid. Tänu sellele saab olemasolevaid protsesse lihtsalt muuta või uusi protsesse kiiresti
juurde luua, kombineerides juba olemasolevaid plokke erineval viisil. Selline plokipõhine lähenemine
toetab komponentide ja mikroteenuste sõltumatut asendamist ning täiendamist ilma kogu süsteemi
ümber ehitamata. Uue menetlusprotsessi lisamisel tuleb defineerida protsessiskeem, mis kombineerib
olemasolevad ja vajadusel ka uued teenused ühtseks tervikuks.
3.3.7 Üleminekuplaan
Suurte süsteemide üleviimine mikroteenusarhitektuurile on pikk ja keeruline protsess. Esmalt on vaja
kindlasti veenduda, kas juba loodud lahendused vastavad reaalselt arhitektuuridiagrammidele. Samuti
tuleks enne suuremate arendustööde algust koostöös KEMITi arhitektiga üle valideerida, kas
olemasolev lahendus on jätkusuutlik või vajab tulevaste arendustöid silmas pidades mõningast
eelkorrastamist.
Enne uute mikroteenuste loomist on vaja aru saada domeenist mida hakatakse üle viima. Selleks
analüüsitakse koostöös kliendiga äriprotsesse ning kaardistatakse need. See aitab aru saada
ärivaldkondadest ning panna paika mikroteenused ning nende vahelised liidesed (loe lähemalt
peatükist Domeenipõhine disain). Samuti kaardistatakse ära, millised andmed on vaja vanast
süsteemist uude üle kanda.
Iga loodava mikroteenuse jaoks luuakse koodihoidlasse oma projekt. Samuti seadistatakse GitLabis
rakenduse ehitamise ja tarnimise protsessid. Automatiseeritus aitab hallata suurt hulka teenuseid ning
vältida manuaalsetest tegevustest põhjustatud inimlikke vigu.
Funktsionaalsust hakatakse liigutama olemasolevatest monoliitsetest süsteemidest uutesse
mikroteenustesse kasutades Strangler Fig mustrit (loe lähemalt peatükist Monoliidi lammutamine).
Samuti luuakse vajalikud andmemigratsiooni skriptid olemas olevate andmete liigutamiseks vanast
süsteemist uude. Loodav kood kaetakse automaattestidega aitamaks veenduda koodi korrektsuses
ning vältimaks koodi katkiminekut hilisemate koodimuudatuste korral.
TTJA e-teenuste protsessimootori detailanalüüsi käigus tuli välja, et TARVIKu koodi kvaliteet ei
vasta headele tavadele ega mikroteenusarhitektuuri põhimõtetele sisaldades liiga pikki meetodeid,
koodikordusi, puudulikku testikatvust ning liiga suure vastutusalaga mikroteenuseid. Neid probleeme
lahendatakse vajaduspõhiselt, kui konkreetse koodiosaga kokku puututakse. Näiteks lisatakse testid
TARVIKu olemasolevatele komponentidele, kus testide katvus pole piisav, enne olemasoleva koodi
refaktoreerimist. Samuti tõstetakse mikroteenusesse mittekuuluv loogika välja eraldi teenusesse
kasutades eelpool mainitud Strangler Fig mustrit.
Paralleelselt sisuliste teenuste analüüsimise ja arendamisega saab hakata tegelema infrastruktuuri
täiendamise ja jälgitavuse täiustamise töödega. Jälgitavuse parandamiseks tuleb lisada
mikroteenustele vastav OpenTelemetry teek, lisada APM Server ning seadistada mikroteenused,
FluentBit, APM Server ja Kibana telemeetria-andmete saatmiseks ja kuvamiseks. Sellest sõltumatult
saab tegeleda CloudNativePG seadistamise ning vajadusel olemas olevates andmebaasides olevate
andmete migreerimisega uude andmebaasiklastrisse. Täpsem kirjeldus võimalikest andmebaaside
migreerimise võimalustest on kirjeldatud peatükis Andmebaaside migreerimine. Viimase sammuna
44 / 73
infrastruktuuri muudatustes lisatakse Kubernetese klastri koosseisu Istio ning aktiveeritakse
automaatne Istio proxy lisamine uutesse loodavatesse Podidesse (eeldab uute Podide loomist).
Pakkuja kogemus näitab, et korduvate tegevuste automatiseerimine vähendab töövoos tekkivaid vigu
märgatavalt. Seetõttu loome ja kasutame komponentide paigalduseks ja teenuste tarnimiseks
koodipõhiseid konfiguratsioone nagu nt Helm chart, kubeconfig, .gitlab-ci.yml, ansible, terraform
vms. See võimaldab samu protsesse korduvalt arenduskeskkonnas järgi proovida vältimaks vigade
tekkimist toodangu keskkonnas.
Andmebaaside migreerimine CloudNativePG klastrisse
Sõltuvalt sellest, kas andmebaaside migreerimise hetkeks on TARVIK juba toodangus või mitte ning
kui on, siis kui pikalt võib süsteem kasutajatele kättesaamatu olla, tuleb valida andmebaaside
migreerimiseks vastavad vahendid. Kui TARVIK ei ole antud hetkeks veel toodangus või kui
toodangu keskkond võib olla pool tundi kättesaamatu, saab andmete migreerimiseks CloudNativePG
klastrisse kasutada lihtsamat lähenemist tehes ühes andmebaasis varukoopia pg_dump abiga ning
laadida andmed teise andmebaasi pg_restore abiga.
Kui andmebaasi migreerimine peab käima aga kasutajate jaoks võimalikult märkamatult, siis tuleb
kasutada loogilist replikeerimist. Loogiline replikeerimine on meetod andmeobjektide ja nende
muudatuste liigutamiseks. Loogiline replikeerimine kasutab publish-subscribe mudelit, kus üks või
mitu tellijat (subscriber) tõmbavad andmeid ühelt või mitmelt avaldajalt (publisher). Tabeli loogiline
replikeerimine algab hetketõmmise tegemisega ning selle tellijale saatmisega ning seejärel jooksvalt
ülejäänud muudatuste, mis avaldaja poolel andmekoosseisus pärast hetketõmmise tegemist toimunud
on, saatmisega.
Loogilise replikeerimise eeldused ja tegevused:
• Kuberneteses jooksevad migreeritud rakendused, mis on suunatud vana andmebaasi vastu
• Uus andmebaasiklaster töötab ja pääseb ligi vanale andmebaasile.
• Uues andmebaasis on rakenduse jaoks loodud 2 kasutajat. Esimene lugemise ja kirjutamise
• õigusega (RW) ja teine ainult lugemise õigusega (RO).
• Vanas andmebaasis luuakse PUBLICATION, uues andmebaasis luuakse SUBSCRIPTION
vanas andmebaasis loodud PUBLICATION-i vastu
• Veendutakse, et andmete replikeerimine töötab. Replikeerimise ajal ei tohi teised rakendused
uude andmebaasi midagi kirjutada, et ei rikutaks andmete terviklikkust.
• Muuta rakenduste andmebaasiühenuse parameetreid nii, et päringud lähevad uue andmebaasi
vastu, kasutades üksnes lugemisõigusega kasutajat (RO).
o Praegusest hetkest alates ei saa toodangu andmebaasi midagi kirjutada.
• Oodata, et pärast replikeerimise algust tehtud muudatused jõuaks samuti uude andmebaasi.
• Muuta rakenduste andmebaasikasutaja lugemis- ja kirjutamisõigusega kasutaja vastu (RW).
o Nüüd saab toodangu keskkonnas uude andmebaasi kirjutada.
• Uuest ja vanast andmebaasist tuleb eemaldada PUBLICATION ja SUBSCRIPTION.
45 / 73
Joonis 19. PostgreSQL andmebaasi loogiline replikeerimine
Antud lahenduse puhul toimib lugemine kogu aeg. Kirjutamine on aga lühikest aega võimatu. Üksnes
lugemisõigusega kasutajat kasutatakse selleks, et rakendus oleks pidevalt kättesaadav aga
andmebaasi ei oleks võimalik andmete terviklikkuse tagamiseks võimalik kirjutada vältimaks
olukorra, kus uude baasi lisatakse kirje, kuid vanast baasist pole viimased kirjeid veel üle tulnud.
Pärast antud tegevuste lõpetamist kasutavad süsteemid uut andmebaasiklastrit ning vana andmebaasi
võib eemaldada.
3.3.8 Riskid ja maandamismeetmed
Alljärgnevalt on välja toodud mikroteenusarhitektuurile üleminekuga soetud riskid ja
maandamismeetmed.
Risk Tõenäosus Mõju Maandamismeetmed
Süsteemi keerukuse
kasv
Kõrge Kõrge Võimalikult palju tegevusi automatiseeritakse
vähendamaks manuaalsetest tegevustest
tekkida võivaid vigu. Süsteemi kirjaldamiseks
luuakse ka põhjalik dokumentatsioon.
Võrguprobleemid
(latentsus,
teenustevahelised
tõrked)
Keskmine Kõrge Päringute ajapiirangute kehtestamine,
kaitselülitite rakendamine, põhjalik
monitooring vigade kiireks ja täpseks
tuvastamiseks.
Andmete korrektsus,
mis on hajutatud üle
mitme teenuse
Keskmine Kõrge SAGA-mustri kasutamine hajusate
transaktsioonide haldamiseks.
Korrektne teenuste vaheliste piiride leidmine
vältimaks seotud andmete hajutamist üle
mitme teenuse.
Keeruline testida
rakendust üle
mitmete teenuste
Keskmine Keskmine Mikroteenuste vahelise suhtluse testimine
kasutades lepingute põhilist testimist, kus
teenused lepivad kokku, milliseid andmeid
vahetatakse.
Tarnimise keerukuse
kasv
Keskmine Keskmine Paigaldusprotseduuri automatiseerimine.
Keeruline leida vigu Kõrge Keskmine Kasutusele võetakse vastavad logimise ja
jälgitavuse tööriistad, mis agregeerivad
andmed tsentraalselt kokku pakkudes kiire ja
lihtsa ülevaate süsteemis toimuvast.
46 / 73
3.4 Modelleerimismeetodi BPM tööprotsesside ja
protsessimootori tehniline rakendamine
Levinud lähenemine on kirjeldada ärianalüüsi käigus äriprotsesside diagrammid, mis on üheks
sisendiks arendajatele. Sellisel lähenemisel on aga mitmeid puudusi. Näiteks ei saa veenduda, et
arendatav protsess vastaks diagrammil esitatule. Samuti võib protsess aja jooksul muutuda, kuid
muudatusi ei viida sisse diagrammile. See omakorda võib tekitada arenduse ja äripoolel erineva
arusaama antud protsessist.
Siinkohal tuleb appi standardiseeritud Business Process Model and Notation (BPMN), mis võimaldab
äriprotsessi vastavalt kindlatele reeglitele kirja panna ning hiljem seda sama protsessi rakenduse
poolel käitada. Sellisel viisil tagatakse, et kirja pandud protsess on kõikidele arusaadav ning täpselt
see, mida rakendus oma töö ajal kasutab.
3.4.1 Protsessimootori valik
BPMN-is kirjeldatud protsesside jooksutamiseks on olemas palju erinevaid protsessimootoreid, mille
vahel valida. 2024. aastal teostas Helmes TTJA-le analüüsi, mille käigus võrreldi erinevaid
protsessimootoreid ja nende võimekusi TTJA poolt esitatud nõuete vastu. Nende seast tõusis enim
esile Camunda, mis kattis suurima osa nõutud vajadustest. Samuti tasub mainida, et Camunda on
ennast tõestanud ka teistes riigi infosüsteemides, nt TEHIKu poolt arendatavas Tervise Infosüsteemis.
Teine oluline komponent protsessimootori valikul on aga hind. Kui Camunda 7 oli tasuta kasutatav
ning sisaldas endas nii protsessimootorit kui ka haldusliidest, siis Camunda 8 puhul on
protsessimootor (Zeebe), haldusliides (Operate) ja diagrammide loomise vahend (Web Modeler)
lahku löödud. Zeebe on endiselt tasuta kasutatav, kuid teiste komponentide litsentsi eest tuleb maksta.
Haldusvahendi alternatiivina on vabalt kätte saadav Zeebe Simple Monitor, mida kommuuni poolt
pidevalt arendatakse ja täiendatakse ning protsessidiagramme saab luua ka Desktop Modeleris, mis
on samuti tasuta kättesaadav. Lisaks aegub Camunda 7 tugi 2027. aasta aprillis. Tasuliste
komponentide kasutamisel läheks ainuüksi litsentsikuludeks 141 800 € aastas. Riigi üks eesmärkidest
on aga leida kokkuhoiukohti. Selle raha saaks suunata süsteemide arendusse ja hooldusesse, et
pakkuda veelgi enam lisandväärtust. Vaatamata 2024. aasta analüüsis toodud soovitusele kasutada
tasulist lahendust arvame eelpool välja toodud põhjenduste tõttu, et mõistlikum on kasutada tasuta
pakutavat lahendust. Seetõttu keskendume edaspidises visioonikirjelduses tasuta komponentide
kasutamisele.
Kolmas oluline komponent protsessimootori valikul on selle hallatavuse lihtsus ja seda nii paigalduse
kui ka monitooringu poole pealt. Camundal on välja töötatud Helm chart, mille abil saab kogu
vajaliku tarkvara lihtsasti Kubernetese klastrisse paigaldada, sobitudes KeMITi IT-profiiliga. Helm
chart sisaldab kõiki Camunda poolt pakutavaid komponente, kuid .enabled-võtmega saab määrata
paigaldamiseks vaid tasuta komponente. Samuti pakub see sisse ehitatud lahendusi jõudluse
jälgimiseks. Vaikimisi suudab Zeebe anda välja meetrika infot Prometheusi formaadis, kui ka saata
andmeid standardiseeritud OTLP protokolliga, mida suudavad tarbida mitmed monitooringuandmete
kogumise ja visualiseerimise tööriistad nagu nt FluentBit, OTel Collector, Elastic APM Server,
Zipkin, Jaeger jpm.
Viimane, kuid mitte väheoluline kriteerium on projekti aktiivsus. Camunda koodihoidla statistikat
vaadates (vt Joonis 20) on näha, et seal toimub aktiivne arendus. Samuti on neil väga põhjalik
dokumentatsioon, mis võimaldab arendajatel lihtsasti oma küsimustele vastused saada.
47 / 73
Joonis 20. Camunda arendusaktiivsuse graafik
3.4.2 Protsessidiagrammid
Camunda kasutab protsessidiagrammide loomiseks BPMN 2.0 standardile vastavat graafilist
esitusviisi, mis on mõeldud äriprotsesside kirjeldamiseks. Toetatud pole küll kõik elemendid, kuid
valdav osa. Neid elemente, mida pole toetatud, on võimalik modelleerida teisiti. Nt puudub tugi
“multiple”-elemendi jaoks, mille eesmärk on koondada mitmeid erinevaid sündmusi ühe elemendi
alla. See teeb mudeli mõnevõrra väiksemaks, aga peidab ära olulist informatsiooni, mis võib kahe
silma vahele jääda. Alljärgnevalt on esitatud kaks mudelit, mis täidavad sama eesmärki, aga esimese
puhul on kasutatud “multiple”-elementi, kuid teise mudeli puhul on selgelt välja toodud, millised
tegevused protsessi algatavad ja lõpetavad. Seega nt “multiple”-elemendi puudumine ei tekita
probleeme diagrammide loomisel.
Joonis 21. "Multiple”-elemendi kasutamine ja selle alternatiiv
Lisaks protsessidiagrammidele toetab Camunda ka DMN-i, mis on mõeldud otsustusmudelite
kirjeldamiseks. See võimaldab protsessimootoril vastavalt sisendile võtta automaatselt vastu otsus,
milliste tegevustega jätkata.
3.4.3 Teenuste vaheline suhtlus
Selleks, et hoida protsessimootor ülejäänud TARVIKu süsteemidest eraldiseisvana, käib kogu suhtlus
TARVIKu mikroteenuste ja protsessimootori vahel läbi “Protsessimootori mikroteenuse”. Näiteks ei
pöördu ükski loataotlusega seotud mikroteenus otse protsessimootori (Zeebe) poole vaid vajaduse
korral pöördub see “Protsessimootori mikroteenuse” poole, mis omakorda saadab päringu edasi
protsessimootorile. Sarnaselt toimub suhtlus ka teistpidi.
Sarnast lähenemist on Pakkuja edukalt kasutanud ka teistes projektides. See aitab vältida
protsessimootori-spetsiifilise info lekkimist teistesse teenustesse ning võimaldab vajadusel
protsessimootor välja vahetada ilma, et teisi mikroteenuseid muutma peaks. Võimalus oleks lisaks
kasutusele võtta ka Zeebe Connectors, et protsessimootor saaks teha otse päringuid välistesse
48 / 73
süsteemidesse, kuid see suurendaks protsessimootori poolset keerukust, suurendaks otsest sõltuvust
teistest süsteemidest ning raskendaks automaattestimist. Seetõttu me seda antud lahenduses ei kasuta.
TARVIKu mikroteenused suhtlevad “Protsessimootori mikroteenusega”, kasutades AMQP
protokolli. See aitab suurendada süsteemi töökindlust, kuna protsessi loomise hetkel ei pea
“Protsessimootori mikroteenus” püsti olema. “Protsessimootori mikroteenus” omakorda suhtleb
Zeebe Gateway’ga kasutades gRPC-d. Kuna protsessid oma olemuselt on asünkroonsed, siis juhul,
kui protsessimootoril on vaja suhelda teiste teenustega, käib ka see läbi “Protsessimootori
mikroteenuse”, kasutades AMQP protokolli. Näiteks kui protsessi käigus on vaja teha X-tee päring,
siis pöördub Zeebe protsessimootor “Protsessimootori mikroteenuse” vastava Job Workeri poole, mis
saadab sõnumi läbi RabbitMQ “X-tee mikroteenuse” pihta. Sarnast lähenemist on soovitatud ka
Camunda enda dokumentatsioonis heade tavade all.
Joonis 22. Protsessi käigus andmete küsimine üle X-tee
3.4.4 Jälgitavus
Jälgitavuse puhul räägime kahest eri tüüpi jälgitavusest. Ühel juhul soovime jälgida, mis seisus
protsess parasjagu on. Teisel juhul soovime aga jälgida, kuidas protsessimootor töötab.
Protsessi jälgimiseks on võimalik kasutada kas Camunda poolt pakutavat tasulist haldusliidest
Operate või kommuuni poolt arendatavat teenust Zeebe Simple Monitor. Kuna Operate kasutuskulud
on üpris suured, siis visioonis keskendume Zeebe Simple Monitorile. Selleks, et saada infot protsessis
toimuvate tegevuste kohta, saadab Zeebe Exporter info välisesse teenusesse, mis talletab info
hilisemaks kuvamiseks. Näitaks saab antud juhul ära kasutada Zeebe Redis Exporterit, mis saadab
andmed Redis Streami. Zeebe Simple Monitor omakorda loeb sealt toimunud sündmused sisse ning
talletab need relatsioonilisse andmebaasi, nt PostgresSQL-i. Lisaks pakub Zeebe Simple Monitor
kasutajaliidest protsesside visuaalseks kuvamiseks ning haldamiseks. Kui mingit infot ei saa Zeebe
Simple Monitorist kätte, siis on võimalik lisada juurde Grafana ja teostada spetsiaalsed päringud
huvitava info kättesaamiseks.
Nii Redis kui ka PostgreSQL on TARVIKus juba kasutusele võetud komponendid, seega saab
olemasolevat tehnilist pinu suures osas ära kasutada.
49 / 73
Joonis 23. Protsessimootoris jooksvate protsesside monitoorimiseks vajalik arhitektuur
Teine asi, mida tasub jälgida, on protsessimootor ise. Camundasse on sisse ehitatud võimekus
pakkuda meetrikaid erinevatel kujudel. Meetrika andmeid talletab Camunda oma mälus ning
monitooringu süsteem peab need mingil viisil kätte saama selleks, et neid agregeerida, kuvada ja
vajadusel ka otsus langetada (nt kas on vaja saata välja teade probleemi ilmnemisest). Seda saab teha
kahel viisil – monitooringu süsteem küsib andmeid (polling) või andmed saadetakse monitooringu
süsteemile (pushing). Andmete küsimiseks on Camundas implementeeritud otspunkt, mis pakub
andmeid Prometheusile sobival kujul. Andmete saatmiseks toetab Camunda OTLP protokolli. Selle
lahenduse puhul saadab Camunda iga teatud aja tagant andmed FluentBiti, mis suudab andmeid APM
Serverile ning Elasticsearchi edastada (loe täpsemalt mikroteenuste jälgitavuse peatükist).
Elasticsearchis olevate andmete põhjal saab Kibanas luua erinevaid raporteid ja teavitusi, mis
saadavad hoiatatusi süsteemis tekkivate tõrgete korral. OTLP protokolli kasutamise eelis seisneb
selles, et Camunda jaoks ei ole enam oluline, millist spetsiifilist tööriista monitooringuks kasutatakse
– Camunda saadab andmed lihtsalt kindla formaadi alusel edasi.
Joonis 24. Protsessimootoris toimuva monitoorimiseks vajalik arhitektuur
3.4.5 Arhitektuur
Lähtuvalt eelmistes peatükkides käsitletud lahendustest joonistub välja alljärgnev
arhitektuuridiagramm. Arhitektuuri luues on silmas peetud, et võimalikult palju saaks kasutada ära
juba TARVIKu projektis kasutusel olevaid ning mikroteenusarhitektuuriga kasutusele võetud
lahendusi lahendusi nagu nt PostgreSQL, Redis, RabbitMQ, FluentBit, APM Server, Elasticsearch,
Kibana.
50 / 73
Joonis 25. Protsessimootori koondarhitektuur
Arhitektuuris kasutatavate komponentide kirjeldus:
• Zeebe Gateway – Zeebe klastri komponent, läbi mille toimub suhtlus Zeebe klastriga. Käitub
koormusjaoturina ning suunab päringuid edasi Zeebe Brokeritele.
• Zeebe Broker – Zeebe klastri põhikomponent, mis töötleb päringuid, tegeleb
replikeerimisega, partitsioneerimisega ja andmete ekspordiga.
• RocksDB - Andmebaasisüsteem, mida Zeebe Broker kasutab sisemiselt andmete
talletamiseks.
• Protsessimootori mikroteenus – Mikroteenus, läbi mille toimub suhtlus teiste mikroteenuste
ja protsessimootori vahel.
• Protsessimootorit kasutav mikroteenus - Kõikvõimalikud mikroteenused, mis soovivad
suhelda protsessimootoriga.
• X-tee mikroteenus – Mikroteenus, mille kaudu saab teha X-tee päringuid
• RabbitMQ - Sõnumiedastusvahend, mis aitab erinevatel rakendustel omavahel suhelda
kasutades AMQP protokolli.
• Redis – Mälupõhine NoSQL võti-väärtus andmebaas, mida antud juhul kasutatakse
protsessidega seotud sündmuste edastamiseks Zeebe Simple Monitorile.
• Zeebe Simple Monitor – Kommuuni poolt arendatud rakendus BPMN-is kirjeldatud protsessi
instantside jälgimiseks ja haldamiseks.
• PostgreSQL – Relatsiooniline SQL andmebaas, kuhu Zeebe Simple Monitor talletab Zeebe
Brokerist saadetud protsessidega seotud sündmused.
• Grafana – Andmete visualiseerimise tööriist, millega saab luua graafikuid, tabeleid ja
töölaudu. TTJA e-teenuste protsessimootori detailanalüüsis on välja toodud, kuidas Grafanat
51 / 73
kasutades saab lihtsasti vaadata protsessidega seotud statistikat. Grafana ei sisaldu KEMITi
IT-profiilis, kuid raportite loomiseks on mõistlik see kasutusele võtta.
• FluentBit - Tööriist, mis aitab erinevatest rakendustes koguda, töödelda ja edasi saata
jälgimisandmeid nagu logid (logs), meetrikad (metrics) ja jäljed (traces).
• APM Server – Teenus, mis võimaldab vastu võtta OTLP protokolliga saadetud andmeid ning
talletada need sobival kujul Elasticsearchi.
• Elasticsearch - Andmebaas ja otsingumootor, mis võimaldab efektiivselt otsida ja analüüsida
suurtes kogustes andmeid.
• Kibana – Kibana abil on võimalik otsida rakenduste logisid, jälgida päringute vooge läbi
hajutatud süsteemi ning visualiseerida meetrikaid. Lisaks on võimalik kirjeldada ära reeglid,
millele meetrikad peavad vastama ning mittevastavuse korral saab välja saata teavitusi
võimaldades kiiresti reageerida võimalikele vigadele.
3.4.6 Kompenseerivad tegevused
Protsesside korral tuleb tihti teha muudatusi mitmetes erinevates mikroteenustes, erinevates
andmebaasides ja need muudatused võivad toimuda pika aja jooksul. Kui kõik läheb soovitud rada
pidi, siis esmapilgul ei tundu probleemi olevat. Kui mõni toiming aga ebaõnnestub, siis võib olla
vajadus tehtud muudatused võtta tagasi ka teistes mikroteenustes. Selle jaoks saab kasutada SAGA
mustrit, mida on võimalik disainida ka BPMN diagrammina, mis annab hea ülevaate, kuidas süsteem
veaolukordade ja erandite korral käitub.
Camundas saab SAGA mustrit kirjeldada kasutades kompenseerivaid tegevusi. Need aitavad võtta
tagasi tegevusi, mis eelnevalt edukalt tehtud said, kuid uue vea ilmnedes enam korrektsed ei ole.
Järgnevalt on toodud näide, kus “Tegevus A” ja “Tegevus B” on varasemalt sooritatud, kuid pärast
kontrolli ebaedukat läbimist kutsutakse välja kompensatsiooni nõudev sündmus “Võta kõik tagasi”,
mille peale käivitatakse kompenseerivad tegevused “Võta tagasi tegevus B” ja“Võta tagasi tegevus
A”.
Joonis 26. SAGA mustri kasutamine BPMN diagrammis kompenseerivate tegevuste teostamiseks
3.4.7 Korduvad tegevused
Kogemuse põhjal julgeb Pakkuja väita, et erinevad protsessid sisaldavad tihtipeale sarnaseid tegevusi,
olgu selleks siis üleüldine põhiprotsess, mis sisaldab teenuste põhilisi spetsiifilisi toiminguid,
allkirjastamise protsess, mis peab alati järgima sama loogikat olenemata teenusest vms levinud
toiming. Sellisel juhul ei ole mõistlik igas erinevas protsessidiagrammis seda loogikat eraldi
kirjeldada vaid teha seda ühes konkreetses .bpmn failis ning teistes protsessides sellele viidata.
52 / 73
Selle jaoks on olemas spetsiaalne element Call Activity. Kui Protsess jõuab sammu A, siis luuakse
uus protsessi instants. Kui loodud protsessi instants jõuab lõppu (sammud B ja C saavad tehtud), siis
viimati loodud protsessi instants lõpetatakse ning eelmine protsessi instants jätkab tööd.
Joonis 27. Alamtegevuste väljakutse BPMN diagrammis
3.4.8 Rakendamine
Kui keskkond on püsti ja protsessidiagramm on loodud, siis on vaja see protsessimootorisse sisse
laadida. Seda saaks teha soovi korral ka otse Desktop Modeleri kaudu, kuid see pole soovitatav. Selle
asemel tuleks loodud mudelid talletada koodihoidlasse, mis võimaldab mudeleid versioneerida ning
veenduda, et igasse keskkonda jõuab täpselt sama mudel. Samuti võimaldab see katta loodud mudelid
automaattestidega veendumaks, et loogika erinevate stsenaariumite korral paika peab. Seetõttu tuleks
diagramm lisada “Protsessimootori mikroteenus”-esse, kus sellele automaattestid saab kirjutada, ning
mis koordineeriks mudelite tarnimist kasutades @Deployment annotatsiooni.
Joonis 28. BPMN mudelite tarnimine kasutades @Deployment annotatsiooni
Uue protsessi käivitamiseks on vaja luua diagrammi põhjal uus instants. Selleks tuleb
protsessimootorile teada anda, millise protsessi id-ga protsessi soovitatakse käivitada. Protsessi ID
on ära määratud .bpmn failis ning peab olema unikaalne üle kõikide protsesside. Protsessi instantsi
loomise järel saadud protsessi instantsi id on soovitatav talletada andmebaasi ning siduda see kirjega,
mille põhjal instants loodi. See võimaldab näiteks vajadusel lihtsasti üles leida mis seisus mingi
konkreetne taotlus parasjagu on.
Joonis 29. BPMN diagrammi lähtekoodis olev viide protsessi identifikaatorile
53 / 73
3.4.9 Üleminekuplaan
Protsessimootori kasutuselevõtt hõlmab mitmeid tegevusi nii infrastruktuuri kui ka rakenduse poole
pealt. Järgnevalt käime läbi etapid, mida on vaja teostada selleks, et protsessimootor TARVIKus
kasutusele võtta. Antud juhul lähtub Pakkuja visioonist, kus kasutusele võetakse Zeebe Simple
Monitor, et hoida kulud minimaalsena.
Sõltumata konkreetsetest äriprotsessidest saab koheselt pihta hakata protsessimootori ning sellega
seotud teenuste püstipanekuga. Selleks on vaja kasutusele võtta protsessimootori arhitektuuri
peatükis välja toodud uued komponendid, mida üldises mikroteenusarhitektuuri koosseisus pole veel
paigaldatud: Zeebe Gateway, Zeebe Broker, Zeebe Simple Monitor, Grafana. Kuna tegu on üldiste
komponentidega, mille paigaldamine ei eelda eriarendusi, siis saab sellega tegeleda nii KeMITi
poolne IT, kui ka Pakkuja.
Paralleelselt paigaldustöödega on võimalik täiendada Zeebe Simple Monitori funktsionaalsust
(protsessi sammude tagasivõtmine, instantside üleviimine järgmisesse versiooni, rollide haldamine)
ning töötada välja vajalikke raporteid Grafana-s. Siiski soovitab Pakkuja Tellijal kriitiliselt üle
vaadata, mis funktsionaalsus on reaalselt vajalik, et vältida asjatuid arenduskulusid.
Eelnevatest tegevustes sõltumatult saab hakata välja arendama “Protsessimootori mikroteenust”. See
hõlmaks endas mikroteenuste ja protsessimootori vahelise API kirjeldamist ja implementeerimist,
äriprotsesside tarnimisloogika juurutamist, “X-tee mikroteenuse” liidestamist. Kuna tegu on
TARVIKu süsteemis ühe keskse komponendiga, tuleb kogu teenus katta põhjalikult
automaattestidega.
Protsessimootorit on võib kasutada nii protsesside puhul, mis võivad kesta kaua, nt toimub selle
menetlemine kui ka lühemate protsesside puhul, mis koosnevad mitmest sammust, võimaldades anda
hea ülevaate sammudes toimuvast. Kõigepealt tuleb analüüsi käigus koostöös Tellijaga kaardistada
tegevused, mille jaoks on protsessimootorit mõistlik kasutada. Leitud tegevused tuleb seejärel
modelleerida kasutades BPMN notatsiooni. Loodud BPMN diagrammid on sisendiks arendajale.
Vastavalt sisenddiagrammile ja analüüsidokumendile loob arendaja vastava teenuse. Vajadusel
täiendab arendaja loodud BPMN diagrammi, lisades väljakutsed teistele teenustele. Korduvad
tegevused tõstetakse eraldi BPMN diagrammidesse ning nendele viidatakse sisenddiagrammidest.
BPMN diagrammid tarnitakse koos teenusega. Sarnane arendusprotsess toimub ka äriprotsesside
muutmise korral.
3.4.10 Riskid ja maandamismeetmed
Alljärgnevalt on välja toodud protsessimootori kasutuselevõtuga seotud riskid ja
maandamismeetmed.
Risk Tõenäosus Mõju Maandamismeetmed
Arhitektuuri
keerukuse kasv
Keskmine Keskmine Põhjalik dokumentatsioon, mis annab ülevaate
protsessimootori tööst ja põhimõtetest.
Keeruline leida vigu Kõrge Keskmine Kasutusele võetakse vastavad logimise ja
jälgitavuse tööriistad, mis agregeerivad
andmed tsentraalselt kokku pakkudes kiire ja
lihtsa ülevaate süsteemis toimuvast.
Tööprotsesse ei saa
jooksutada, kui
Keskmine Kõrge Protsessimootori jooksutamine mitme õla peal
suurendamaks jõudlust ja kättesaadavust.
54 / 73
protsessimootor pole
kättesaadav
Integreerimise
keerukus olemas
oleva süsteemiga
Keskmine Keskmine Alustada lihtsamatest protsessidest.
Refaktoreerida vajadusel olemas olevat koodi,
et see sobituks uue arhitektuuriga.
Kogu protsessi
testimine on keeruline
Keskmine Keskmine Testitakse üksnes protsessi. Suhtlus teiste
väliste teenustega mockitakse.
Aktiivsete protsesside
muudatused
Keskmine Keskmine Camundasse sisse ehitatud protsessi
versioneerimise kasutamine.
Migreerimisstrateegia paikapanek ja
dokumenteerimine.
55 / 73
3.5 Mikroesitluskihid
TARVIKu visiooni järgi koondatakse TTJA, JVIS ning NBA süsteemide funktsionaalsus, sh
majandustegevuslubade ja -teadete kuvamine, taotlemine ning menetlemine aga ka administreerimine
jt alamsüsteemid ühele platvormile, et
• parandada kasutajakogemust,
• lihtsustada menetlejate igapäevatööd,
• vähendada praegusest mitme süsteemi ülalpidamisest tulenevat halduskoormust.
Süsteemide liitmisel on aga oht monoliitrakendustele omastest tihedatest seostest tulenevate riskide
realiseerumisele, näiteks:
• ühe (klienditoode) muutmine eeldab teiste (menetlustoode) muutmist,
• ühe toote muudatuste testimine eeldab ka teiste toodete testimist,
• üht toodet pole võimalik tarnida teisi tooteid tarnimata,
• admintoote tehnoloogiaid ei ole võimalik valida sõltumatult kliendi- ja menetlustoote
tehnoloogiatest.
Eelpool nimetatud probleemide leevendamiseks pakume visioonis mikroesitluskihtidel (micro front-
end) põhinevat arhitektuuri. Mikroesitluskihtidega on võimalik rakenduse esitluskiht jagada
komponentideks selliselt, et iga toode on teistest sõltumatu ehk on avatud muudatustele, eraldi
testitav ja tarnitav ning tehnoloogilistes valikutes vaba.
3.5.1 TARVIKu mikroesitluskihtide üldarhitektuur
Pakutav mikroesitluskihtidel (MFE-del) põhinev üldarhitektuur koosneb loodavast kestrakendusest
ning igale tootele vastavast MFE-st.
Kestrakendus (shell/host) on vajalik MFE-de orkestreerimiseks. Selleks tuleb kõik loodavad (1.
taseme) MFE-d registreerida kestrakenduses teekondadena (route). Samuti soovitame koondada
võimalikult palju keskset funktsionaalsust nagu autentimine, rakenduse keele seadistus jms
kestrakendusse.
MFE on autonoomne äriloogiline komponent, millel on selgelt piiritletud äridomeen. Näiteks,
klienditoote, menetlustoote ja admintoote ärifunktsionaalsus ei tohiks omavahel põimuda üheks
MFE-ks, sest sel juhul ületataks selgelt äridomeenide piirid, küll aga sobib neid esitada eraldi
mikroesitluskihi komponentidena:
• Kliendi MFE,
• Menetlus MFE,
• Admin MFE.
56 / 73
Joonis 30. TARVIKu portaali kestrakendus ja MFE-deks jagunemine
Iga MFE on võimeline orkestreerima alam-MFE-sid. Nii on võimalik komponente taaskasutada.
Näiteks, Kliendi MFE ja Menetlus MFE mõlemad võivad tarbida Taotlus MFE-d, et kliendi taotluse
vaadet kuvada. 2. ja kõrgemate tasemete MFE-de loomisel soovitame aga olla ettevaatlik, eriti kui
MFE kasutamine ilma sisendparameetriteta pole võimalik. MFE-des sisendparameetrite kasutamine
loob jäiku seoseid komponentide vahel, mis vähendab nende autonoomsust.
Näiteks, Taotlus MFE taotluse id parameetri nime või andmekuju muutumisel ei ole võimalik Taotlus
MFE-d tarnida ilma, et tehtaks muudatusi ka tarbivates Kliendi MFE-s ja Menetlus MFE-s. Selle
asemel soovitame primitiivseid sisendandmeid lugeda URL-ilt, sest teekondade (path) kuju on
võimalik Taotlus MFE-st juhtida.
MFE-sid on võimalik laadida nii teekondade kui ka iseseisvate komponentide eksponeerimise kaudu.
Näiteks, 1. taseme MFE-sid on otstarbekas eksponeerida teekondadena, sest võivad koosneda
mitmest alamlehest. Kui MFE-d on vaja kuvada aga mõne teise MFE sees (näiteks Taotlus MFE
Kliendi MFE sees), siis võib piisata iseseisva komponendi eksponeerimisest. Sellegipoolest,
soovitame võimalusel alati eelistada teekondade eksponeerimist, sest nii on edaspidi MFE rohkem
avatud funktsionaalsuse laiendamisele.
Joonis 31. Komponendi ja teekondade eksponeerimine
Kuigi päist, vasakmenüüd ja jalust on samuti võimalik MFE-deks jagada, soovitame siiski
TARVIKu puhul need lisada otse kestrakendusse. Päise, vasakmenüü ja jaluse eraldi arendamise ja
57 / 73
tarnimise võimalus suurt eelist ei anna, seega pakutud lahendus aitab vältida liigset keerukust ning
hoida tarnitavate esitluskihi rakenduste arv madalamana
Joonis 32. Päis, menüü ja jalus kestrakenduses või MFE-dena
Täpne MFE-deks jagunemine ning granulaarsus selgub analüüsi tulemusena, seda on täpsemalt
kirjeldatud peatükis „4. Nõuete ja skoobi täpsustamine“.
3.5.2 Tehnoloogiad
Järgnevalt kirjeldame erinevaid MFE-de loomiseks võimalikke tehnoloogilisi lahendusi.
Iframe ehk sisepaneel on pilt-pildis põhimõttel toimiv küps tehnoloogia. Iframe sobib hästi
kolmandate osapoolte sisu kuvamiseks MFE-na, kuid meie hinnangul TARVIKusse
baaslahendusena ei sobi, sest autentimise, stiilide, sõltuvuste jms jagatud sisu propageerimine on
keeruline. Samuti on iframe’id otsingumootorivaenulikud ning ka WCAG nõuete täitmine on
raskendatud.
Web Components tehnoloogia sobib hästi kolmandate osapoolte sisu kuvamiseks, kus tarbijal on vaja
kontrolli sisu üle. Siiski, meie hinnangul TARVIKusse baaslahendusena ei sobi, sest ei võimalda
jagada sõltuvusi, mis võib muuta portaali komponentide laadimise kulukaks. Samuti eeldab nende
kasutamine enamasti versioneerimist, mis tooks kaasa vajaduse kestrakenduses käsitsi iga muudatuse
peale versioone muuta ja kaoks võimalus komponente autonoomselt tarnida.
Webpack Module Federation sobib meie kogemusel suurepäraselt TARVIKusse MFE-de
esitamiseks. Toetudes module federation kogemusele eesti.ee riigiportaalis, kirjeldame selle
peamiseid eeliseid:
• Module federation võimaldab MFE-sid arendada ja tarnida muust ärifunktsionaalsusest
sõltumata ning ei eelda versioneerimist.
• Module federation toetab sõltuvuste jagamist (näiteks Angular) kestrakenduse ja MFE-de
vahel, kuid ei nõua seda. Samuti toetab Webpack laiska laadimist mida on võimalik
kombineerida Angulari teekondade laisa laadimisega ning hoida seeläbi aktiivne rakendus
võimalikult õhuke.
• Webpack Module Federation on laialt levinud, hästi hooldatud ning küllaltki küps
tehnoloogia, mille kohta leidub ohtralt dokumentatsiooni, koodinäiteid ning juhtumiuurimusi,
eriti Angular lahendusteks.
Webpack Module Federationi peamine puudus on otsene sõltuvus Webpackist ning küllalt suur
keerukus, mille peamisi väljakutseid käsitleme peatükis „Väljakutsed“.
58 / 73
Webpack Module Federationi juurutamiseks on võimalik seda kasutada kas otse (1) või kolmandate
osapoolte pistikute kaudu, neist enim levinud on Nx (2) ja Angular Architects (3). Korrektse
seadistuse korral töötab Webpack Module Federation risti kõigi eelnevalt mainitud kolme lahenduse
vahel, kuid TARVIKus soovitame piirduda neist ühega. Meie kogemusel pistikprogrammide
kasutamine lihtsustab module federationi seadistamist oluliselt võrreldes selle otse kasutamisega.
Soovitame mono-repodega valida Nx ning multi-repodega Angular Architects lahendus. Webpack
Module Federationi kasutamine on eelduseks eesti.ee portaaliga liidestumiseks.
Native Federation on oma olemuselt väga sarnane Webpack Module Federation lahendusele, kuid
ei eelda Webpack kasutamist. Varasemalt eesti.ee portaalile teostatud tehnilise analüüsi põhjal
jõudsime aga järeldusele, et tehnoloogiline sõltumatus ei kaalu hetkel üle suuri puuduseid:
• vigaderohked ja ebastabiilsed toodangu versioonid,
• vähe dokumentatsiooni,
• kestrakenduses on nõutud kõikide tasemete MFE-de registreerimine (mitte ainult esimese,
nagu Webpack Module Federationiga).
3.5.3 Andmevahetus
Hoolikalt valitud jaotus MFE-deks tagab süsteemi komponentide maksimaalse autonoomsuse. Siiski
mõningane andmevahetus kestrakenduse ja MFE-de vahel on vältimatu, mõnel juhul isegi eelistatud.
Tagamaks head kasutajakogemust, soovitame luua kestrakendusse üldise veahalduse. Selliselt on
võimalik keskselt lahendada juhud, kus MFE või MFE toimimiseks hädavajalike andmete laadimine
ebaõnnestub, puuduvad õigused sisu nägemiseks jms veaolukorrad. Keskse veahalduse kasutamine
aitab lihtsustada veahalduses muudatuste tegemist ka tulevikus.
Selleks on vaja luua võimalus andmete edastamiseks MFE-de ja kestrakenduse vahel. Järgnevalt
kirjeldame veebibrauserite reaktiivseid tehnoloogiaid, nende puudusi ning pakume lahenduse.
Redux, Angular Service ja RxJS on levinud tehnoloogiad Angular rakendustes andmete hoidmiseks
ja voogedastamiseks, kuid mikroesitlustkihtidele üle viidud (MFE-statud) rakenduses eeldab see
singleton instantside kasutamist, mis võib hilisemalt seada liigselt piiranguid ning kõrget sidusust
konkreetsete tehnoloogiatega, seetõttu ei soovita me sellist lahendust.
Brauseri sündmused (Event) ja PostMessage API on raamistike jm tehnoloogiate suhtes
agnostilised ning küllaltki lihtsad kasutada, kuid neil puudub sisse-ehitatud võimalus luua jäika
versioneeritud andmekuju. Suurte ja keeruliste süsteemide puhul on meie hinnangul vastupidava
andmevahetuse loomiseks see aga väga oluline. Näiteks, versioneerimist kasutamata pole
kestrakenduse veateadete andmekuju muutumisel MFE-d uuest andmekujust teadlikud.
Kestrakenduse ja MFE-de vaheliseks otsesuhtluseks nimetatud tehnoloogaid kasutada me ei
soovita, kuid järgmises peatükis pakume välja lahenduse, kuidas kirjeldatud probleeme lahendada.
Riigiportaali eesti.ee kogemusel soovitame luua TARVIKu andmevahetuseks eraldi teegi, mis
põhineb publish-subscribe põhimõttel. Näiteks, MFE-siseste andmete laadimise ebaõnnestumisel
publitseerib MFE teegi kaudu veateate, mida kestrakendus kuulab ning oskab sellele reageerida.
Teegi loomise ja kasutamise peamised eelised on:
• jäik andmekuju (publitseerijad ja tarbijad teavad täpselt milliseid andmeid oodata ning on
võimalik luua tagasiulatuv ühilduvus),
• võimalus andmete hoiustamise tehnoloogiat muuta (window object, global store,
localStorage, sessionStorage jne),
59 / 73
• võimalus luua selge andmete hierarhia (platvormi sõnumid, MFE-spetsiifilised sõnumid
jne),
• võimalud versioneerida ja paketeerida kasutades npm-i,
• võimalus teeki integreerida andmevahetuseks ka PostMessage API vms tehnoloogiaga.
Peamine puudus sellisele lahendusele on tõsiasi, et see tuleb välja arendada ning kõik MFE-d on
sunnitud aeg-ajalt teegi versiooni uuendama, mis võib autonoomsust vähendada, kuid tagasiulatuva
ühilduvusega on võimalik seda riski maandada.
Joonis 33. Andmevahetus kestrakenduse ja MFE vahel publish-subscribe põhimõttel
Kuigi keel jms süsteemiparameetrid on tihti URL-ilt kättesaadav, soovitame neid ka publish-
subscribe põhimõttel propageerida, et iga MFE ei peaks üldiste parameetrite lugemist ise eraldi
implementeerima ja kestrakendusele jääks võimalus nende loogikat muuta.
MFE-de omavahelist suhtlust (ka Publish-Subscribe teegi kaudu) soovitame vältida, sest see on märk
kehvasti disainitud MFE-dest ning sel juhul tuleks analüüsida, kas MFE komponent on liiga kitsa
ulatusega.
3.5.4 Disain
Ühtne disain kestrakenduse ja MFE-de vahel on kriitilise tähtsusega, et tagada hea kasutajakogemus.
Võib leiduda esitluskihi komponente, mida on vaja ristkasutada kestrakenduses või mitmes MFE-s.
Ei ole otstarbekas implementeerida üldlevinud komponente nagu tabel, nupud, modaalid jms
kestrakenduses ning igas MFE-s eraldi.
Soovitame luua esitluskihi komponentide teek npm pakina ning kaaluda ka TEDI kasutuselevõttu.
TEDI on TEHIKu poolt arendatav, Veera disainisüsteemi järgiv, Angulari ja Reacti kasutajaliidese
komponentide kogumik. Nii on võimalik tulevikus oluliselt arendus- ja hoolduskuludelt säästa ning
portaali kujundus ühtsena hoida.
Lahendus eeldab olemasolevate komponentide asendamist teegi komponentidega, mis võib olla üsna
töömahukas. Esialgu võib kaaluda ka korduvate komponentide kopeerimist erinevatesse MFE-desse,
mida hiljem järk-järguliselt asendada korduvkasutavate komponentidega, et ülemineku keerukust
vähendada.
60 / 73
Joonis 34. TARVIK ja TEDI komponentide taaskasutamine
3.5.5 Autentimine, autoriseerimine ja infoturve
Autentimiseks soovitame kasutada GovSSO-d ning autoriseerimiseks GovSSO silda Pääsukese
pääsuhaldussüsteemi. GovSSO võimaldab kasutajat autentida kasutades TARA ning võimaldab
sessiooni jagada kõigi GovSSO-ga liitunud süsteemide vahel (näiteks eesti.ee portaali ja TARVIKu
vahel navigeerides). Samuti on võimalik GovSSO väljastatud ID Tokenist lugeda kasutaja
esindusõigused ning neid autoriseerimiseks rakendada. Kasutajarolle on võimalik laadida
Pääsukesest ning vajadusel teisendada TARVIKu privileegideks.
Kuna pakutud lahenduse MFE-de route’ide juured on täielikult kestrakenduse kontrolli all, on
võimalik kestrakenduse kaudu juhtida ka route guarde ja nendega rakendada autentimisest ja
autoriseerimisest tulenevaid piiranguid. Kui mõni alam-route Kliendi MFE sees vajab erikohtlemist,
siis on võimalik seda teha MFE sees.
Autentimisest ja autoriseerimisest esitluskihi tasemel ei piisa, seda tuleb teha ka taustteenustes ning
kestrakendus ja MFE-d peavad olema valmis vastavatele veakoodidele reageerima, et kasutajat
ebaõnnestunud päringutest teavitada ning sisu kuvamist piirata.
Autorite visiooni järgi võivad Menetlus MFE ja isegi Admin MFE olla orkestreeritud sama
kestrakenduse poolt, mis Kliendi MFE. Kui mõne MFE (näiteks Admin MFE) andmeteta esitluskiht
võib liigselt reeta sisemiste tööriistade ülesehituse kohta, siis on võimalik vastavad moodulid muuta
ainult sisevõrgust kättesaadavaks.
61 / 73
Joonis 35. Tundlike MFE-de piiramine sisevõrgust kättesaadavaks
3.5.6 Testimine
Süsteemi suurtest muudatustest põhjustatud probleemide vältimiseks soovitame olemasolevad
süsteemi komponendid katta automaattestidega, integratsioonide katvusele ei ole meie hinnangul
otstarbekas keskenduda, sest need võivad MFE-stamise käigus muutuda.
MFE-de testimiseks soovitame järgida mikroteenuste testimise põhimõtteid. Soovitame ühiktestida
ühe MFE piires ning integratsioone testida kestrakenduse ja iga MFE vahel. MFE-de omavahelisi
integratsioone soovitame vältida, kuid nende esinedes tuleks neidki testida, sest muudatused MFE-
de integratsioonide vahel ei avaldu kompileerimise hetkel ning nende muutudes võivad vead
ebapiisava testidega katmise korral jõuda märkamatult toodangusse.
End-to-end testimise vajadus MFE-de vahel viitab kehvasti disainitud hajussüsteemile ning
autonoomsuse puudumisele. Siiski ühe MFE piires on see meie hinnangul suurepärane vahend MFE
smoke ja sanity testimiseks.
Regressioonitestimiseks soovitame kasutada automatiseeritud tööriistu: ühiktestimiseks Jasmine ning
end-to-end testimiseks Playwright. Mõlemad on küpsed, laialt levinud ning regulaarselt hooldatud.
Soovitame jälgida testide katvuse head tava: 80% funktsionaalsetest komponentidest.
3.5.7 Kasutuselevõtt
Järgnevalt kirjeldame olulised sammud ja tegevused Webpack Module Federation
mikroesitluskihtide tehnoloogia juurutamiseks ning kirjeldame lahendusi levinud probleemidele.
Pakutav kasutuselevõtu plaan lähtub CI/CD põhimõtetest, et võimaldada tihedaid tarneid ning järk-
järgulist üleminekut. Siiski tuleks arvestada, et iga loodav MFE peaks läbima ka turvatesti, mis võib
seada tellijale piiranguid toodangusse samm-sammult liikumiseks. MFE-de kasutuselevõtt ei sõltu
otseselt mikroteenustest, seega ei eelda peatükis „Mikroteenuste arhitektuur“ ettepanekute
elluviimist.
I faas: analüüs
Analüüsi faasis tuleb välja selgitada äridomeenide vahelised piirid ning nende vahelised seosed.
Pöörame tähelepanu, et esitluskihi äridomeenid ei pruugi kattuda peatükis „Domeenipõhine disain“
kirjeldatud domeenidega, kuigi samad põhimõtted kehtivad siingi.
62 / 73
Samuti peaks analüüsima ristkasutust vajavaid komponente, näiteks kliendi taotluse koondandmete
vaade menetlejale või lubade ja teadete nimekirja vaade riigiportaalis eesti.ee kuvamiseks. Esimeses
faasis on oluline kaardistada lisaks uuele loodavale funktsionaalsusele ka juba olemasolev.
Äridomeenide vaheliste piiride kaudu on võimalik kirjeldada täpsed MFE-d ning nende puutepunktid.
Soovitame MFE-sid hoida suurte loogiliste komponentidena, kuna liiga palju väikseid MFE-sid võib
tõsta süsteemi keerukuse ebamõistlikult kõrgele. Autorite hinnangul on hästi koostatud MFE
sisendparameetrite arv 0, sest siis on võimalik MFE-d vabalt muuta ilma, et tarbija peaks muudatusi
tegema. Sellega on tagatud täielik autonoomsus ning maksimaalselt lõdvad seosed.
Näiteks, geneeriline komponent Nupp ei ole hea kandidaat MFE-ks, sest eeldab sisendparameetreid
(tekst, ikoon, värv jne), mille kuju võib tihti muutuda ja sobib seetõttu paremini npm pakina
esitamiseks.
Küll aga klienditoode sobib hästi eraldi MFE-ks, sest koondab enda alla ühe äridomeeni (kliendiga
seotud ärifunktsionaalsuse) ning on võimeline teistest äridomeenidest sõltumatult toimima.
II faas: olemasoleva funktsionaalsuse MFE-stamine
Olemasoleva funktsionaalsuse MFE-stamine ei eelda peatükis “Menetlustoote kasutajaliidese
arendus” kirjeldatud ärianalüüsi valmimist.
I samm. Module federationi kasutuselevõtuks soovitame esmaselt värskendada praeguse TARVIKu
esitluskihi rakenduse sõltuvused uusimatele versioonidele. Seejärel paigaldada Webpack Module
Federation ning seadistada TARVIKu rakendus hostiks. Lihtsuse huvides soovitame esialgu
seadistada kõik sõltuvused singletonideks ning mitte nõuda rangeid versioone (brauseri konsoolis
kuvatakse selle kohta hoiatusi). Nüüd on TARVIK võimeline teekondadel (Angular route)
põhinevaid MFE-sid laadima ja kuvama ning seda võib nimetada kestrakenduseks. Hiljem
eraldatakse ärifunktsionaalsus praegusest TARVIK monoliit rakendusest.
Pärast 1. sammu on võimalik TARVIK toodangusse tarnida.
II samm. Järgmiseks soovitame luua proof-of-concept (PoC) MFE projekti ning seadistada see
remoteks. Sarnaselt kestrakendusele kasutada lõtvade versioonireeglitega singletone. Lisada Angular
route(d)/module/component ning eksponeerida see remoteEntry.js failina, kusjuures ühest
remotest on võimalik eksponeerida ka mitu olemit. Pärast eksponeerimist on võimalik kestrakendusel
seda tarbida.
Lisada TARVIKusse juurde uus teekond, millega MFE sisse laetakse. Korrektse seadistuse puhul
sellest piisab, et näidata MFE-de sisse laadimise ja TARVIKus kuvamise võimalikkust. See projekt
saab olema etaloniks järgmistele loodavatele MFE-dele.
Joonis 36. Proof-of-concept MFE lisamine
63 / 73
2. sammus loodud teekonnad ning PoC rakendust toodangusse mitte tarnida.
III samm. Nüüd on võimalik hakata olemasolevat funktsionaalsust MFE-stama. Näiteks, kui
analüüsis jõuti järeldusele, et Kliendi MFE on sobilik autonoomne komponent, siis on võimalik:
1. olemasolev funktsionaalsus tõsta eraldi Git repositooriumisse,
2. eksponeerida kestrakendusele tarbimiseks,
3. luua CI/CD töövoog ehitamiseks ning paigaldamiseks.
Näiteks, kui praeguses lahenduses jaguneb kliendivaade mitmeks Angular routeks, siis on võimalik
need kõik eksponeerida ning lisada kestrakendusse.
Soovitame MFE-lahendusega toodangusse minna peidetult ehk jätta esialgu alles praegune avalik
teekond klientidele ning peidetud MFE-statud teekond testimiseks. Täiendavalt on võimalik lisada ka
piirangud, et teekond on kättesaadav ainult sisevõrgust.
Joonis 37. Olemasoleva funktsionaalsuse MFE-stamine
Alternatiivselt võib ka ajutiselt tarnida 2 eraldi rakendust, kus MFE-statud rakendus asub TARVIKu
alamdomeenil, et lihtsustada CORS jms turvareeglite rakendamist, võimaldamaks toodangusse
tarnida nii MFE-statud kui ka monoliitrakendus korraga. Kui MFE-statud rakenduse töökindluses on
jõutud veendumusele, on võimalik toodangu monoliitrakendus täielikult asendada MFE-statud
rakendusega lõppkasutajale märkamatult.
Üleminekuperioodil soovitame olemasolevat funktsionaalsust muuta minimaalselt, et
monoliitrakenduses ning MFE-statud rakenduses ei peaks muudatusi dubleerima.
III faas: uue funktsionaalsuse lisamine MFE-dena
Uue funktsionaalsuse lisamine MFE-dena eeldab ärianalüüsi. Menetlustoote jaoks on seda kirjeldatud
peatükis “Menetlustoote kasutajaliidese arendus”.
Enne uue funktsionaalsuse lisamist soovitame põhjalikult veenduda vähemalt ühe toimiva MFE
kasutamises mitmes keskkonnas (näiteks Kliendi MFE). Seejärel on võimalik lihtsama vaevaga
hakata looma uusi MFE-sid võttes esimest eeskujuks ning järgides juba mainitud tegevusi. Kõiki
järgmisi MFE-sid on nüüd võimalik arendada ka samaaegselt.
Iga uue MFE rakenduse lisamine eeldab olemasolevasse CI/CD töövoogu ehitus- ja
paigaldusskriptide lisamist.
64 / 73
Väljakutsed
Mikroesitluskihtide areng on olnud kiire. Praegused veebilahendused tihtipeale ei arvesta MFE
paradigma põhimõtetega. Siin peatükis toome välja peamised probleemid, mis riigiportaali eesti.ee
kogemusel võivad vajada lahendamist ka TARVIKu MFE-stamisel.
Probleem I: stiilide (CSS) lekkimine.
Enamik rakendusi kasutavad nii-nimetatud globaalseid stiile, mis rakenduvad kas mõnele HTML
elemendile (nt <body>, <h1>, <p> jne) või kasutavad juurskoobis geneerilist klassinime (nt
„modal“, „button“.jne).
Soovitame alati kõik CSS klassinimed skoopida komponendi piires või kui see ei ole võimalik,
kasutada eesliidet, et vältida nimekonflikte. Näiteks CSS klassi „modal“ asemel kasutada „tarvik-
modal“.
Vaikimisi Angular skoobib komponentide stiilid kasutades ViewEncapsulation.Emulated,
millega rakendatakse ka vanem-komponentide stiilid (näiteks kestrakenduse stiilid MFE-le). Kui
soovitakse täielikku stiilide isoleeritust, tuleks kasutada ViewEncapsulation.ShadowDom
ja/või Web Component tehnoloogiat. Soovitame vältida ViewEncapsulation.None kasutamist,
sest siis rakendatakse alam-komponentide stiilid ka vanem-komponentidele, näiteks kui MFE määrab
tekstivärvi, muutub tekstivärv ka kestrakenduses.
Probleem II: globaalsed komponendid.
Leidub kolmandate osapoolte (näiteks Ng Bootstrap) komponentide implementatsioone, mis
toimimiseks lisavad DOM-i lõppu HTML-i, näiteks modaalid, overlay’d jms. Selliste
valmislahenduste kasutamine MFE-s ilma ViewEncapsulation.None kasutamata võib osutuda
keeruliseks.
Sel juhul soovitame kolmandate osapoolte implementatsioone mitte kasutada, vaid arendada enda
(kasutada TEDI) komponente, mis arvestavad ka MFE-de omapäradega. Tuleks arvestada, et
olemasolevate komponentide asendamine võib olla üsna ajamahukas.
Probleem III: innukas cache’imine.
Kasutajakogemuse tõstmiseks cache’ivad tänapäevased lahendused võimalikult palju staatilisi
ressursse, et vältida nende mitmekordset laadimist. Kuna MFE-sid laetakse staatiliste ressurssidena -
JavaScript (js) või Module JavaScript (mjs) failidena - ning nende aadress ei sisalda unikaalset hashi
ega muud strateegiat cache uuendamiseks, siis soovitame rakendusserveris seadistada remoteEntry.js
failidele no-cache. Kui kasutusel on mõne kolmanda osapoole lahendus, näiteks Cloudflare, siis tuleb
ka sealseid seadistusi kontrollida. Kui remoteEntry.js cache’imine ei ole välja lülitatud, on esitluskihi
rakenduse töö pärast tarneid paljude kasutajate jaoks suure tõenäosusega häiritud.
Probleem IV: staatiliste ressursside laadimine.
MFE staatilised ressursid ehk pildid, ikoonid jms ei ole kestrakenduses kättesaadavad, sest asuvad
MFE aadressil.
Soovitame iga MFE staatilised ressursid paigutada unikaalse nimega kataloogi ning lisada
kestrakenduse veebiserverisse staatiliste ressursside proksimine.
65 / 73
Joonis 38. MFE-de staatiliste ressursside proksimine
Lisaks soovitame seadistada Webpack publicPath (Angular Architects pistikprogramm teeb seda
vaikimisi ). Siis lisab Webpack staatilistele ressurssidele MFE-aadressid automaatselt. Paraku
koodis refereeritud ressursse Webpack dünaamilisest laadima ei ole võimeline, näiteks MFE
piltide laadimine ebaõnnestub, kui kasutada relatiivset teekonda pildini:
<img src=“{relatiivne teekond pildini}“>.
Mainitud probleemi lahendust kirjeldame peatükis „MFE laadimine“.
Probleem V: turvapäistest tulenevad piirangud.
Veebirakenduste ressursside kaitsmiseks kasutatakse levinud klientrakenduste turvapäiseid, näiteks
CSP ja CORS reegleid. CSP-d kasutatakse peamiselt failide (skriptid, pildid jne) laadimise
piiramiseks, CORS-i aga taustteenustega suhtlemise piiramiseks. Kasutades kestrakenduse ja MFE-
de jaoks erinevaid (alam)domeene, muutub kestrakenduse turvapäiste haldamine keerulisemaks.
Joonis 39. MFE skriptide ja muude ressursside laadimiseks CSP reeglite seadistamine
66 / 73
Näiteks, kui Kestrakendus asub domeenil shell ning Kliendi MFE asub domeenil client-mfe,
siis tuleks (iga) MFE domeen lisada turvapäiste erandite hulka, et kestrakendusel oleks lubatud MFE-
d laadida. Ka alamdomeenide kasutamine ei aita, sest kõikide alamdomeenidele erandi lisamine on
tülikas ning wildcard (*) kasutamine domeenireeglite lisamisel pole piisavalt turvaline, sest laiendab
oluliselt ründepinda.
Selle asemel soovitame MFE-de puhul kasutada põhidomeeni alamkatalooge koos proksiga. Selliselt
piisab põhidomeenile (shell) turvapäiste seadistamisest, turvalisuse osas järeleandmisi tegemata.
Joonis 40. MFE staatiliste ressursside laadimine läbi proksi
Probleem VI: Sõltuvuste konfliktid
Webpack Module Federation võimaldab defineerida igale MFE-le oma sõltuvused ja/või nende
versioonid. Nii on võimalik tagada täielik autonoomsus, kuid ühe asutuse piires soovitame siiski
tuumsõltuvuste (nt Angular) versioone hoida sünkroonis. Singleton-konfiguratsiooni kasutamisega
on võimalik maandada vigade tekkimise tõenäosust ning see aitab vältida vigade avaldumist alles
pärast paigaldamist. Siiski, ka singletonidega võib eriversioonide kasutamisel vigu esineda. Selleks,
et neid varakult avastada, soovitame MFE-de integratsioonid kestrakendusega katta
automaattestidega.
Singletonide kasutamisel tuleks arvestada sellega, et nendele sõltuvustele ei ole võimalik teostada
tree shaking optimeerimist. Näiteks, kui sõltuvusena on kasutusel suuremahuline ikoonide pakk,
millest päriselt kasutatakse väikest arvu ikoone, siis singleton sõltuvusena laetakse ikkagi kogu paki
sisu, mitte ainult tarvilik.
Väliste süsteemide integreerimisel või muul juhul vältimatul versioonide/raamistike lahknevusel
tuleks iga MFE skoopida, kasutades Web Component ja Shadow DOM tehnikaid. Need võimaldavad
MFE täielikult isoleerida kestrakendusest ja teistest MFE-dest. Sellise lähenemisega tuleks arvestada,
et iga MFE jaoks laetakse kõik sõltuvused alati uuesti ehk rakenduse laetavate ressursside maht
kasvab oluliselt määral.
3.5.8 Integratsioon väliste süsteemidega
Mikroesitluskihtide üks paljudest kasuteguritest on võimalus esitluskihi komponente taaskasutada nii
lokaalses kui ka välistes süsteemides. Riigiportaal eesti.ee on MFE-valmidusega, mis loob
potentsiaalse võimaluse TARVIKu komponente seal kuvada. Selles peatükis käsitleme integratsiooni
väliste süsteemidega eesti.ee portaali näitel ning sellega kaasnevaid väljakutseid.
67 / 73
MFE laadimine
Kuna TARVIKu MFE asub eesti.ee portaalist erineval domeenil, on vaja eesti.ee portaalis lubada
remoteEntry.js ning MFE staatiliste ressursside laadimine TARVIKu domeenilt. Alternatiivselt on
võimalik lisada proksi eesti.ee domeenilt TARVIKusse, kuid ideaalis soovitame neid välistes
süsteemides vältida, et vähendada süsteemide-vahelisi jäike seoseid. Peatükis “Probleem IV:
staatiliste ressursside laadimine.“ selgitati täpsemalt miks staatilisi ressursse ei ole võimalik
dünaamiliselt MFE-st laadida ilma proksita. Proksi vältimiseks on võimalik kasutada koodis
Webpack publicPath staatilise ressursi relatiivse teekonna ees:
<img src=“__webpack_public_path__ + {relatiivne teekond pildini}“>.
Andmevahetus
Kasutades module federationit, laetakse MFE kood alati orkestreerivasse (kestrakenduse)
komponenti ja seetõttu MFE kood käivitatakse alati orkestreerivas (host) rakenduses. Avaliku
sektori infosüsteemid kasutavad andmevahetuseks enamasti X-teed, kuid MFE-de kasutamiseks
tähendaks see eesti.ee portaalis TARVIKu X-tee teenustega liidestumist. Taoline lahendus loob meie
kogemusel liigseid jäiku seoseid TARVIKu ja eesti.ee portaali vahel. Näiteks, taotluse andmekuju
muutmiseks API muudatuste korral oleks vaja ka eesti.ee portaalis teha arendusi rig-xroad API
komponendis, et uus X-tee teenus kasutusele võtta.
GovSSO-l on valminud OAuth Access Tokenil põhinev lahendus, millel on potentsiaal vältida X-tee
liidestusi ning teostada päringud otse TARVIKu REST APIde kaudu ning TEHIKu lisaarendustega
võimaldaks seda kasutada mustriga Backend for Frontend (BFF). Toimiv Token Mediation lahendus
on eesti.ee ja Riikliku Postkasti vahelise integratsiooni jaoks toodangus juba ka kasutusel.
Joonis 41. Turvalise andmevahetuse alternatiivid eesti.ee portaali ja TARVIKu vahel: access token või X-Tee
Alternatiivina võib kaaluda ka Server Side Rendering (SSR) lahendust, millega puudub vajadus
andmevahetuse integratsiooni loomiseks väliste süsteemide vahel, kuid võib potentsiaalselt tekitada
suurt koormust TARVIKu füüsilisele serveriressursile.
68 / 73
Otstarbekus
Soovitame analüüsida TARVIKusse koondavate lubade ja teadete (aga ka muude potentsiaalsete
TARVIKu komponentide) MFE-na eesti.ee portaalis kuvamise otstarbekust. Riigiportaalis on juba
valminud majandustegevuslubade ja -teadete mitmetest asutustest agregeerimise sündmusteenus,
millega liidestumiseks piisab ühe REST otspunkti lisamisest TARVIKusse. Veelgi enam, TARVIKu
komponent ei annaks lõppkasutajale ammendavat nimekirja tema ettevõttele väljastatud lubadest ja
teadetest, sest ei sisalda andmeid teistelt asutustel. Meie hinnangul arendamise keerukus ei kaalu
saadud kasu üle.
Selle asemel soovitame TARVIKus kasutada GovSSO-d, mis võimaldab kasutajal hõlpsasti
riigiportaali ja TARVIKu vahel navigeerida ning autentida. Niiviisi on riigiportaali tegevuslubade
sündmusteenusest jõudmine TARVIKusse (lubasid vaatama aga ka muutma või esitama) lihtne.
Joonis 42. TARVIKu liidestamine olemasoleva eesti.ee Tegevusload Sündmusteenusega üle X-tee
3.5.9 Riskid ja maandamismeetmed
Selles peatükis kirjeldame mikroesitluskihtide juurutamisega seotud riske ning võimalusi nende
maandamiseks.
Risk Tõenäosus Mõju Maandamismeetmed
Esitluskihi keerukuse kasv. Kõrge Kõrge Vältida süsteemi liigset tükeldamist;
vältida jäike seoseid MFE-de vahel;
vältida erinevate raamistike kasutamist
vähemalt ühe asutuse piires;
analüüsida põhjalikult MFE
komponentide taaskasutuse
otstarbekust; serveerida MFE
komponente samalt domeenilt;
69 / 73
kasutada jäika, kuid tagasiulatuva
ühiduvuse võimalusega
andmevahetuskihti kestrakenduse ja
MFE-de vahel.
Ebaühtlane disain ja
kasutajakogemus.
Keskmine Keskmine Viia olemasolev rakendus üle Veera
disainisüsteemile; kasutada keskset
komponentide teeki (TEDI); rakendada
keskset veahaldust läbi kestrakenduse
ja andmevahetuskihi. Täpsemalt loe
peatükist „3.5.4 Disain“.
Kasvav halduskoormus
väliste rakendustega
integreerumisel (eesti.ee
portaal).
Keskmine Kõrge Maksimaalse isoleerituse tagamine:
Web Componenti kasutamine,
GovSSO access tokeni juurutamine X-
tee asemel. Kaaluda MFE kuvamise
asemel süvalingiga kasutaja suunamist
portaalide vahel. Täpsemalt loe
peatükist „3.5.8 Integratsioon“.
Eesti.ee portaaliga
liidestumise takerdumine
GovSSO liidestuse
puudumisel või GovSSO
pooleliolevate access tokeni
arenduste tõttu.
Keskmine Madal Prioritiseerida GovSSO juurutamist
olemasolevatesse TARVIKu
süsteemidesse; access token lahenduse
puudumisel implementeerida
integratsioon üle X-tee. Loe täpsemal
peatükist „Andmevahetus“.
Infoturbe seisukohalt tundlike
(andmeteta) esitluskihi
komponentide avalik
kättesaadavus.
Madal Madal Muuta tundlikud MFE-d (Menetlus ja
Admin MFE) kättesaadavaks vaid
sisevõrgust. Loe täpsemalt peatükist
„3.5.5 Autentimine, autoriseerimine ja
infoturve“.
Vead MFE-de sõltuvuste
erinevate
versioonide/raamistike
integreerimisel ja tarnimisel
(CI/CD).
Kõrge Kõrge Singleton sõltuvuste kasutamine;
kestrakenduse ajakohasena hoidmine;
MFE-de skoopimine Web
Componentiga. Loe täpsemalt
peatükist: “Probleem VI: Sõltuvuste
konfliktid”.
MFE-de liigsest põimumisest
tekkinud sõltuvuste tõttu
autonoomsuse vähenemine
(hajusa monoliidi tekkimine).
Madal Keskmine Domain-Driven Design põhimõtete
järgimine ning põhjalik eelanalüüs
äridomeenide jaotumiseks. Loe
täpsemalt peatükist „Domeenipõhine
disain“ ning „3.5.1 TARVIKu
mikroesitluskihtide üldarhitektuur“.
Suurest arvust MFE-dest
põhjustatud versioonihalduse
keerukuse kasv (palju
repositooriume).
Madal Madal Domain-Driven Design põhimõtete
järgimine ning põhjalik eelanalüüs
äridomeenide jaotumiseks. Loe
täpsemalt peatükist „Domeenipõhine
disain“ ning „3.5.1 TARVIKu
mikroesitluskihtide üldarhitektuur“.
70 / 73
Olemasoleva
funktsionaalsuse regressiooni
testimise suur keerukus ja
koormus Tellijale.
Kõrge Kõrge Olemasoleva funktsionaalsuse katmine
automaattestidega. Loe täpsemalt
peatükist „3.5.6 Testimine“.
Rakenduse laetavate
ressursside mahu
suurenemine.
Madal Kõrge Seadistada jagatavad ressursid
singletoniks ning lõdvendada
versioonide kattuvuse nõudeid
Webpack konfiguratsioonis. Pöörata
tähelepanu ka tree shaking piirangutele
module federationiga.
Stiilide lekkimine
kestrakenduse ja MFE-de
vahel.
Keskmine Madal Rakendada strateegiaid peatükist
“Probleem I: stiilide (CSS)
lekkimine.”.
71 / 73
4 Tehisaru kasutamine
Kuna Hankija eeldab Pakkujalt AI komponentide kasutuselevõttu loodavates lahendustes (“Hanke
tehniline kirjeldus” ptk 6 lõpp), siis antud pakkumuse lisandväärtusena toob Pakkuja välja mõningad
võimalikud kasutusjuhud, kus tehisaru kasutamine oleks võimalik. Pakutavate lahenduste loetelu ei
ole lõplik.
Tehnoloogiat tuleks kasutada inimeste töö ja elu lihtsustamiseks nii palju kui võimalik. Lisaks
loogilise ja mugava süsteemi disainimisele ja arendamisele on võimalik kasutada ka tehisaru (AI)
protsesside kiiremaks ja lihtsamaks muutmiseks. Alljärgnevalt pakume välja mõned variandid, kuidas
AI-d TARVIKu kontekstis ära saaks kasutada ning kuidas seda tehniliselt realiseerida.
4.1 Automaatne menetlemine
Menetlemise käigus otsustab menetleja hetkel sisendandmete põhjal, kas taotlusele saab menetluse
käigus luua positiivse otsuse või mitte. Need sisendandmed võivad tulla nii kodaniku poolt täidetud
vormilt kui ka võib ametnik vajalikku informatsiooni mujalt juurde hankida. Võttes aluseks lõpetatud
menetluste sisendandmed ja otsuse tulemused, on võimalik treenida AI mudeleid, mis suudavad
menetleja eest võtta vastu otsuse juhul, kui süsteem on selles 100% kindel.
Selle jaoks saab treenida otsustuspuu, mis käivitatakse menetlusprotsessi teatud sammus. Kui mudel
on veendunud, et taotluse võib saata edasi järgmisesse sammu, saab ta selle automaatselt ära teha.
Kui mudel aga ei ole selles täitsa veendunud, siis jätkatakse tavalise menetlusvooga, kus ametnik
peab ise protsessi sekkuma. Alternatiivina võib mudel lihtsalt anda menetlejale omapoolse arvamuse,
kas taotlus tundub positiivse otsuse loomiseks korrektne või mitte. Allpool on toodud näide MTRi
loataotlusprotsessi algusest, kus saaks kasutada ära masinõppe võimalusi.
Joonis 43. Tehisaru kasutamine loataotlusprotsessi koosseisus
Tehniline lahendus
Mudeli treenimiseks ja jooksutamiseks on ühe võimalusena kasutada nt Wekat. Weka on avatud
lähtekoodiga masinõppe tarkvarapakett, mille on välja töötanud Uus-Meremaa Waikato ülikool ning
mis võimaldab andmete analüüsi, mudelite loomist ja visualiseerimist erinevate algoritmide abil.
Kuna see on loodud kasutades Java programmeerimiskeelt, siis sobitub see ka KEMITi IT-profiiliga.
Selleks, et taotlust automaatselt kontrollida, luuakse esiteks vastav mudel. See eeldab piisavas
koguses algandmete olemasolu, et loodav mudel oleks võimalikult täpne. Weka graafiline
kasutajaliides võimaldab nii mudeli loomist kui ka loodud otsustuspuu graafilist visualiseerimist.
Seeläbi on võimalik täpselt näha, mis tingimuste tõttu mingi otsus vastu võeti.
72 / 73
Joonis 44. Mudeli loomise ja kasutamise voog
Seejärel sisestatakse loodud mudel AI mikroteenusesse, mis sisendandmete põhjal tagastab tulemuse
koos kindlustunde väärtusega, mis näitab protsentides, kui suure tõenäosusega tagastatav vastus on
korrektne. Vastavalt kindlustunde väärtusele saab Protsessimootor teha otsuse, kas arvestada mudeli
poolt tagastatud tulemust või mitte.
4.2 Klienditugi
TARVIK on üha kasvava funktsionaalsusega infosüsteem. Ka suurepärase kasutajakogemuse korral
võib kasutajal tekkida küsimusi, nt millist taotlust on vaja mingi loa jaoks täita või mis väärtust
sisendis oodatakse. Tõsi, selle jaoks võib luua põhjalikud juhendid, mida kasutaja läbi saab töötada,
kuid palju mugavam oleks küsida vastust klienditoelt, mis koheselt vastaks. Siinkohal tulevad appi
keelemudelid.
Probleem tekib aga keelemudeli teadmistes, kuna sellel puudub info TARVIKu kohta. Selle
probleemi lahendamiseks kasutatakse tehnikat nimega RAG (Retrieval-Augmented Generation).
RAG kombineerib infootsingu ja keelemudeli teksti genereerimise võimekuse. Kõigepealt otsitakse
andmeallikast (TARVIKu juhendid) asjakohast teavet, mis antakse keelemudelile koos küsimusega
kaasa, et mudelil oleks olemas kontekst, mille põhjal vastata.
Tehniline lahendus
Esmalt on vaja teadmusbaasist otsida üles relevantne info, mida keelemudelile kaasa anda. Iga
päringuga keelemudelile kogu andmeallika kaasa andmine pole mõistlik ega praktiline, kuna see
suurendab nii võrguliiklust kui ka keelemudeli kasutamise kulu.
Teadmusbaasi loomine koosneb järgnevatest sammudest:
• Esmalt tükeldatakse dokumendid väiksemateks osadeks mõningase ülekattega säilitamaks
konteksti. Tükeldamine on vajalik, kuna keelemudelitel on piirangud, kui pikka teksti nad
suudavad vastu võtta.
• Seejärel genereeritakse dokumendiosadest vektorid (embeddings). Need vektorid talletavad
teksti semantilist sisu, mitte sõnu. Sarnase sisuga tekstide vektorid on teineteisele lähemal.
• Vektorid koos tekstiga salvestatakse andmebaasi. Andmebaasisüsteemiks sobib KEMITi IT-
profiilis välja toodud PostgreSQL koos pgvector laiendiga, mis võimaldab vektorandmeid
talletada kui ka nende seast otsida. Tänu vektoritele on nüüd võimalik üles otsida relevantsed
osatekstid.
73 / 73
Joonis 45. Andmete eeltöötlemise protsess. Algtekstist osatekstide ja vastavate vektorite leidmine ja talletamine vektorandmebaasi
Küsimuse põhjal vastuse genereerimine koosneb järgnevatest sammudest:
• Kasutaja küsimusest genereeritakse vektor.
• Teadmusbaasist otsitakse üles küsimuse-vektorile lähedal asuvad osateksti-vektorid. Kuna
antud vektorid talletavad endas teksti semantilist tähendust, siis leitud vektoritega seotud
osatekstid sisaldavad relevantset informatsiooni. Leitud osatekstid annavad keelemudelile
konteksti.
• Leitud osatekstide, küsimuse ning juhise põhjal luuakse sisend (prompt), mis saadetakse
keelemudelile. Keelemudel genereerib antud sisendit arvesse võttes vastuse ja tagastab selle.
Juhised on vajalikud selleks, et anda keelemudelile teada, mida temalt täpselt oodatakse.
Joonis 46. RAG. Küsimusele vastuse genereerimine vektorandmebaasis olevate andmete pealt
Keelemudeli poolt tagastatud vastuse sobivus sõltub olulisel määral keelemudelile saadetavast
sisendist (prompt). Selleks, et suunata keelemudelit andma soovitud ja täpseid vastuseid kasutatakse
prompt-engineering tehnikaid. See hõlmab õige sõnastuse, konteksti ja juhiste valimist, et
maksimeerida mudeli kasulikkust konkreetse ülesande lahendamisel. Hästi kujundatud sisend võib
oluliselt parandada mudeli täpsust, loogikat ja järjepidevust vastustes.
Keelemudeli poolt tagastatud vastus võib sama sisendi puhul iga kord erineda. Samuti ei saa alati
kindel olla vastuse korrektsuses. Seetõttu ei sobi keelemudelite kasutamine suurt täpsust ja
läbinähtavust vajavate protsesside (nt menetlemine) automatiseerimiseks. Küll aga sobib see
suurepäraselt tekstist andmete otsimiseks ja selle põhjal küsimustele vastamiseks ning kasutaja
abistamiseks.
1 / 2
Kinnituskiri
Riigi Infosüsteemi Amet (RIA) kinnitab käesolevaga, et AS Helmese poolt järgnevad hankesse
esitatud andmed referentsprojekti kohta on õiged ning AS Helmese ja RIA vahel sõlmitud
lepingute maht alltoodud tabelis nimetatud IT-teenuse arenduseks oli vähemalt 2000 tundi.
Hinnatav kriteerium Punktide
arv
IT-teenus: Riigiportaali
arendused (eesti.ee)
(isik kes osales): Madis
Sander Maddison
(on täidetud = 1, ei ole täidetud
= 0)
Täiendav selgitus
- kus/kuidas on
täidetud
Avalikult kasutatav
rakendus1 2 1
Eesti.ee
Rakenduse kasutajate
autentimine toimub eID
vahenditega riiklikus2
autentimisteenuses
TARA või GovSSO
1 1
GovSSO
Rakenduse
andmebaasimootorina
kasutatakse PostgreSQL-
i
1 1
menu, dashboard jt
Rakendus töötab
Docker
konteinerlahendusena
2 1
Riigipilve
Kubernetes klastris
Docker konteiritena
Rakendus töötab
horisontaalselt
skaleeritavana3
Kubernetese platvormil
1 1
Jah, rakendusi on
võimalik
horisontaalselt
skaleerida
Rakenduse ehitus ja
paigaldus teostatakse
GitLabi CI/CD
vahenditega
1 1
Koodivaramu
Gitlab töövoog
Rakendus tarbib x-tee
teenuseid 1 1 RR, EMTA jpt
Rakendus pakub x-
tee teenuseid 1 1
https://x-
tee.ee/catalogue/EE/
GOV/70006317/riig
iportaal
Riigi Infosüsteemi amet
Õie-Mari Aasmäe
10
2 / 2
Täpsustused
1Avalikult kasutatav rakendus tähendab, et iga avalik kasutaja saab välisvõrgust rakendusele
ligi, vajadusel sinna sisse logida/kasutaja luua, selle pakutavaid teenuseid kasutada.
2Rakendus on kasutajate autentimiseks kas otse liidestatud TARA/GovSSO teenusega või
liidestatud läbi vaheautentimisserveri (näiteks Keycloak) ning rakenduse ja
autentimisserveri vahel kasutatakse OpenID Connect protokolli.
3Rakendus on loodud tõrgeteta töötama Kubernetese platvormil horisontaalselt
skaleeritavana, st koormuse kasvades võib rakendust replitseerida kahe või enama
instantsina (POD replicas >= 2) manuaalselt või kasutades Kubernetese automatiseeritud
skaleerimist (Horizontal Pod Autoscaling).
Õie-Mari Aasmäe
talituse juhataja
Tehnoloogia arenduse talitus I Personaalriigi osakond
/allkirjastatud digitaalselt/
1 / 2
Kinnituskiri
Riigi Infosüsteemi Amet (RIA) kinnitab käesolevaga, et AS Helmese poolt järgnevad hankesse
esitatud andmed referentsprojekti kohta on õiged ning AS Helmese ja RIA vahel sõlmitud
lepingute maht alltoodud tabelis nimetatud IT-teenuse arenduseks oli vähemalt 2000 tundi.
Hinnatav kriteerium Punktide
arv
IT-teenus: Sündmusteenuste
platvormi ja teenuste arendused
(isik kes osales): Siim
Tanel Laisaar
(on täidetud = 1, ei ole täidetud =
0)
Täiendav selgitus
- kus/kuidas on
täidetud
Avalikult kasutatav
rakendus1 2 1
Riigiportaali
sündmusteenused
Rakenduse kasutajate
autentimine toimub eID
vahenditega riiklikus2
autentimisteenuses
TARA või GovSSO
1 1
GovSSO
Rakenduse
andmebaasimootorina
kasutatakse
PostgreSQL-i
1 1
sun-db
Rakendus töötab
Docker
konteinerlahendusena
2 1
Riigipilve
Kubernetes klastris
Docker konteiritena
Rakendus töötab
horisontaalselt
skaleeritavana3
Kubernetese platvormil
1 1
Jah, rakendusi on
võimalik
horisontaalselt
skaleerida
Rakenduse ehitus ja
paigaldus teostatakse
GitLabi CI/CD
vahenditega
1 1
Koodivaramu
Gitlab töövoog
Rakendus tarbib x-tee
teenuseid 1 1 RR, EMTA jpt
Rakendus pakub x-
tee teenuseid 1 1
https://x-
tee.ee/catalogue/EE/
GOV/70006317/sun
-life-events
Riigi Infosüsteemi amet
Reimo Nõgu
10
2 / 2
Täpsustused
1Avalikult kasutatav rakendus tähendab, et iga avalik kasutaja saab välisvõrgust rakendusele
ligi, vajadusel sinna sisse logida/kasutaja luua, selle pakutavaid teenuseid kasutada.
2Rakendus on kasutajate autentimiseks kas otse liidestatud TARA/GovSSO teenusega või
liidestatud läbi vaheautentimisserveri (näiteks Keycloak) ning rakenduse ja
autentimisserveri vahel kasutatakse OpenID Connect protokolli.
3Rakendus on loodud tõrgeteta töötama Kubernetese platvormil horisontaalselt
skaleeritavana, st koormuse kasvades võib rakendust replitseerida kahe või enama
instantsina (POD replicas >= 2) manuaalselt või kasutades Kubernetese automatiseeritud
skaleerimist (Horizontal Pod Autoscaling).
Reimo Nõgu
Tooteomanik
Teenuste äritalitus I Personaalriigi osakond
/allkirjastatud digitaalselt/
Riigihange „TTJA e-teenuste keskkonna TARVIK arendus“
Viitenumber 291973
Hinnang teostatud töödele
Pakkuja meeskonnas arendaja rollis pakutavate meeskonnaliikmete poolt teostatud
arendustööde ülevaade kuni kolme arendatud IT-teenuse näitel. IT-teenuse all mõtleb Hankija
Pakkuja mainitud rolli täitva meeskonna liikme osalusel kindlat eesmärki täitvat ja
lõppkasutaja jaoks läbi veebiliidese kättesaadavat iseseisvalt toimivat IT-lahendust. Eraldi IT-
teenustena ei tohi pakkuda sama IT-teenuse arendamiseks sõlmitud erinevaid hankelepinguid,
ega sama IT-teenuse erinevaid mooduleid. Pakkuja võib oma teostatud tööde referentsidena
kasutada neid toodangus olevaid IT-teenuseid, mille pakkujapoolne teostatud (akteeritud)
arendustööde maht on vähemalt 2000 tundi ja mille arenduses osales mainitud rolli täitev isik.
Tabeli täitmine
Allolevasse tabelisse tuua välja kuni 3 pakkuja poolt arendatud IT-teenust ning märkida ära
kõigi kriteeriumite osas kas vastav tingimus on täidetud (on täidetud = 1, ei ole täidetud = 0).
Tabeli päises olevad „IT-teenus 1“, „IT-teenus 2“ jne asendada IT-teenuse nime või URLiga,
kui see on avalikult kättesaadav.
Esitatud referentsprojektidel peab olema Tellija/Hankija kinnitus, et käesolevasse hankesse
esitatud andmed on õiged ning Pakkuja sõlmitud lepingute maht nimetatud IT-teenuste
arenduseks oli vähemalt 2000 tundi. Sealjuures on aktsepteeritud nii mitme Tellija/Hankija
poolt allkirjastatud tabel mitme IT-teenuse andmetega, kui ka eraldi allkirjastatud dokument
iga esitatava IT-teenuse kohta. Tabeli viimases reas tuleb esitada Tellija/Hankija esindaja nimi
ja kontaktandmed.
Iga IT-teenuse vastavuse korral hinnatavale kriteeriumile on võimalik saada vastavale
kriteeriumile omistatav punktide arv. Maksimaalselt on võimalik saada iga IT teenuse eest
kõikide kriteeriumitele vastavuse korral 10 väärtuspunkti ja kui kõik 3 IT-teenust vastavad
kõikidele kriteeriumitele, siis on võimalik hankida 30 väärtuspunktipunkti. Kui mõne IT-
teenuse puhul mõni kriteerium ei ole vastav, siis pakkuja sellele kriteeriumile antavaid punkte
selle IT-teenuse eest ei saa.
Hinnatav kriteerium Punktide
arv
IT-teenus 1
Riigiportaal
(eesti.ee)
(isik
kes
osales:
Madis
Sander
Maddis
on)
IT-teenus 2
Tööelu
infosüsteemi
(TEIS)
arendustööd (isik
kes osales: Pearu
Sarv)
IT-teenus 3
Sündmusteenuste
platvormi ja
teenuste
arendused
(isik kes osales:
Siim Tanel
Laisaar)
Avalikult kasutatav
rakendus1
2 2 2 2
Rakenduse kasutajate
autentimine toimub
eID vahenditega
riiklikus2
1 1 1 1
autentimisteenuses
TARA või GovSSO
Rakenduse
andmebaasimootorina
kasutatakse
PostgreSQL-i
1 1 1 1
Rakendus töötab
Docker
konteinerlahendusena
2 2 2 2
Rakendus töötab
horisontaalselt
skaleeritavana3
Kubernetese
platvormil
1 1 1 1
Rakenduse ehitus ja
paigaldus teostatakse
GitLabi CI/CD
vahenditega
1 1 1 1
Rakendus tarbib x-tee
teenuseid
1 1 1 1
Rakendus pakub x-
tee teenuseid
1 1 1 1
Tellija/Hankija
esindaja nimi
Riigi
Infosüsteemi
amet
Õie-Mari Aasmäe
oie-
mari.aasmae@ria
.ee
TEHIK
Rainer Rohtla
e
Riigi Infosüsteemi
amet
Reimo Nõgu
Täpsustused
1Avalikult kasutatav rakendus tähendab, et iga avalik kasutaja saab välisvõrgust rakendusele
ligi, vajadusel sinna sisse logida/kasutaja luua, selle pakutavaid teenuseid kasutada. 2Rakendus on kasutajate autentimiseks kas otse liidestatud TARA/GovSSO teenusega või
liidestatud läbi vaheautentimisserveri (näiteks Keycloak) ning rakenduse ja autentimisserveri
vahel kasutatakse OpenID Connect protokolli. 3Rakendus on loodud tõrgeteta töötama Kubernetese platvormil horisontaalselt
skaleeritavana, st koormuse kasvades võib rakendust replitseerida kahe või enama instantsina
(POD replicas >= 2) manuaalselt või kasutades Kubernetese automatiseeritud skaleerimist
(Horizontal Pod Autoscaling)
Riigihange „TTJA e-teenuste keskkonna TARVIK arendus“
Viitenumber 291973
CV vorm
Spetsialisti ees- ja perekonnanimi: Ian Nelis
Spetsialisti roll: Projektijuht
Pakutud rolli eriala töökogemuse pikkus aastates: 12+ aastat
Eesti keele kõneoskus: emakeel
Eesti keele kirjaoskus: emakeel
Kogemus nõutud rollis
1. Projekti nimetus: Uue Kogumisrakenduse hange II
Tellija info (sh kontaktisiku nimi ja e-
post):
RMIT, Statistikaamet
Arne Puhlov, [email protected]
Projekti toimumise aeg (alates-kuni): 07/2023 – tänaseni
Roll projektis: Projektijuht
Teostatud tööde lühikirjeldus Isik osales projektis vahmikus: 07/2023 – 06/2024
Projekti juhtimine, tööde koordineerimine,
riskihaldus, analüüsi protsessis osalemine jm.
2. Projekti nimetus: Uue kogumisrakenduse arendus
Tellija info (sh kontaktisiku nimi ja e-
post):
RMIT, Statistikaamet
Arne Puhlov, [email protected]
Projekti toimumise aeg (alates-kuni): 11/2020 – 12/2022
Roll projektis: Projektijuht
Teostatud tööde lühikirjeldus Isik osales projektis vahmikus: 11/2020 – 12/2022
Projekti juhtimine, tööde koordineerimine,
riskihaldus, analüüsi protsessis osalemine jm.
3. Projekti nimetus: Javapõhiste PKI (Public Key Infrastructure)
lahenduste arendus
Tellija info (sh kontaktisiku nimi ja e-
post):
Primekey Solutions AB (Rootsi)
Kontaktisik Magnus Andren/arendusjuht
Projekti toimumise aeg (alates-kuni): 04/2018 – …
Roll projektis: Projektijuht
Teostatud tööde lühikirjeldus Isik osales projektis vahmikus: 04/2018 – …
Projekti planeerimine ja läbiviimine, igapäevane
Scrum tiimi juhtimine, projekti aruandlus ja
riskide maandamine.
4. Projekti nimetus: Uue menetlussüsteemi baas, kliendihaldus
(CRM)- ja otsustusmooduli arendus
Tellija info (sh kontaktisiku nimi ja e-
post):
Põllumajanduse Registrite ja Informatsiooni Amet
(PRIA)
Ivo Tamm
Projekti toimumise aeg (alates-kuni): 01/2017 – 03/2018
Roll projektis: Projektijuht
Teostatud tööde lühikirjeldus Isik osales projektis vahmikus: 01/2017 – 03/2018
Projekti juhtimine, tööde koordineerimine,
riskihaldus, analüüsi protsessis osalemine jm.
5. Projekti nimetus: Uue menetlussüsteemi baas, kliendihaldus
(CRM)- ja otsustusmooduli arendus
Tellija info (sh kontaktisiku nimi ja e-
post):
Põllumajanduse Registrite ja Informatsiooni Amet
(PRIA)
Ivo Tamm
Projekti toimumise aeg (alates-kuni): 03/2015 – 12/2016
Roll projektis: Projektijuht/analüütik
Teostatud tööde lühikirjeldus Isik osales projektis vahemikus: 03/2015 –
12/2016
Uue kliendihaldusmooduli (CRM) analüüs,
arendus ja juurutus. Projekti planeerimine ja
läbiviimine, igapäevane Scrum tiimi juhtimine –
SCRUM Master, projekti aruandlus ja riskide
maandamine, süsteemianalüüsi protsessis
osalemine. Meeskonna suurus 7 inimest
Projekti planeerimine ja läbiviimine, igapäevane
Scrum tiimi juhtimine, projekti aruandlus ja
riskide maandamine, süsteemianalüüsi protsessis
osalemine.
Käesolevaga kinnitab pakkuja, et:
• spetsialist on tutvunud hangitava tööga ja andnud nõusoleku lepingu täitmisel
osalemiseks;
• spetsialisti CV-s esitatud andmed on õiged;
• spetsialist valdab kõiki asjakohaseid riigihanke alusdokumentides kirjeldatud
tehnoloogiaid ja metoodikaid ning on nõus neid lepingu täitmisel järgima;
• spetsialist vastab kõikidele esitatud nõuetele, sh keele nõudele;
• hankija võib kõiki siin esitatud andmeid igal ajal kontrollida.
Riigihange „TTJA e-teenuste keskkonna TARVIK arendus“
Viitenumber 291973
CV vorm
Spetsialisti ees- ja perekonnanimi: Linda Sassian
Spetsialisti roll: Projektijuht
Pakutud rolli eriala töökogemuse pikkus aastates: 6 + aastat
Eesti keele kõneoskus: (märkida emakeel/väga hea/hea/vajab tõlki) emakeel
Eesti keele kirjaoskus: (märkida emakeel/väga hea/hea/vajab tõlki) emakeel
Kogemus nõutud rollis
Projekti nimetus: Keskse volituse haldamise süsteemi Pääsuke
analüüsi-, arendus- ja hooldustööd
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Riigi Infosüsteemiamet
Projekti toimumise aeg (alates-kuni): 03/2025- ....
Roll projektis: Projektijuht
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Isik osales projektis vahemikus: 03/2025-...
Projektimeeskonna töö juhtimine. Töö ladusa
edenemise tagamine ja koordineerimine. Agiilsete
tseremooniate läbiviimine. Eelarve ja ajakava
jälgimine, riskijuhtimine, arveldamine.
Projekti nimetus: TTJA e-teenuste platvormi jätkuarendused
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Keskkonnaministeeriumi Infotehnoloogiakeskus
Projekti toimumise aeg (alates-kuni): 08/2024 – 01/2025
Roll projektis: Projektijuht
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Isik osales projektis vahemikus: 08/2024 –
01/2025
Projektimeeskonna töö juhtimine. Töö ladusa
edenemise tagamine ja koordineerimine. Agiilsete
tseremooniate läbiviimine. Eelarve, skoobi ja
ajakava jälgimine, arveldamine. Riskijuhtimine.
Projekti nimetus: TTJA E-teenuste keskkonna pääsuhalduse
arendus
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Keskkonnaministeeriumi Infotehnoloogiakeskus
Projekti toimumise aeg (alates-kuni): 07/2024-01/2025
Roll projektis: Projektijuht
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Isik osales projektis vahemikus: 07/2024-01/2025
Projektimeeskonna töö juhtimine. Töö ladusa
edenemise tagamine ja koordineerimine. Agiilsete
tseremooniate läbiviimine. Eelarve, skoobi ja
ajakava jälgimine, arveldamine.
Projekti nimetus: eesti.ee eraisiku ja ettevõtja vaadete tehniline
kaasajastamine
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Riigi Infosüsteemi Amet
Õie-Mari Aasmäe, [email protected]
Projekti toimumise aeg (alates-kuni): 05/2023-10/2024
Roll projektis: Projektijuht
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Isik osales projektis vahemikus: 05/2023-10/2024
Projektimeeskonna töö juhtimine. Agiilsete
tseremooniate läbiviimine. Eelarve jälgimine,
arveldamine, riskijuhtimine, projektiplaani ja
ajakava jälgimine. Jira, Confluence
Projekti nimetus: CERN (Euroopa Tuumauuringute Keskus)
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
CERN
Juan Lopez Gonzalez, [email protected]
Projekti toimumise aeg (alates-kuni): 07/2022- 03/2024
Roll projektis: Projektijuht
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Isik osales projektis vahemikus: 01/2023-03/2024
Projektimeeskonna töö juhtimine
tarnija vaatest. Töö ladusa edenemise
tagamine ja koordineerimine. Lepinguhaldus,
arveldused.
Projekti nimetus: PPA Isikutuvastuse ja illegaalituvastuse
moodulite arendus
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Politsei- ja piirivalveamet
Projekti toimumise aeg (alates-kuni): 06/2019- 01/2022
Roll projektis: Tiimijuht/scrum master
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Isik osales projektis vahemikus: 06/2019-01/2022
Arendusmeeskonna igapäevane juhtimine,
aruandlus, eelarve juhtimine, lepinguhaldus,
agiilsete meetodite rakendamine, töökoosolekute
korraldamine ja juhtimine, Scrum tseremooniate
(demod, planeerimiskoosolekud,
hindamiskoosolekud, stand-upid, retrod)
läbiviimine. Jira, Confluence, Scrum,
Projekti nimetus: Riikliku rahvusvahelise kaitse andmise registri
(RAKS 2) analüüsi- ja arendustööd
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Politsei- ja piirivalveamet
Kontaktisik: Marina Põldma
Projekti toimumise aeg (alates-kuni): 10/2018-02/2022
Roll projektis: Tooteomanik/projektijuht
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Isik osales projektis vahemikus: 10/2018-10/2019
Projekti ja skoobi juhtimine, ärianalüüs, testimine,
aruandlus, backlogi haldus, lepinguhaldus, eelarve
juhtimine, agiilsete töömeetodite rakendamine,
Jira, Confluence
Projekti nimetus: PPA ABIS süsteemi ja biomeetria teenuste
arendus
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Politsei- ja piirivalveamet
Hannes Lember [email protected]
Projekti toimumise aeg (alates-kuni): 08/2018 – 11/2023
Roll projektis: Tiimijuht/scrum master
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Isik osales projektis vahemikus: 06/2019-08/2022
Arendusmeeskondade igapäevane juhtimine,
aruandlus, eelarve juhtimine, lepinguhaldus,
agiilsete meetodite rakendamine, töökoosolekute
korraldamine ja juhtimine, Scrum tseremooniate
(demod, planeerimiskoosolekud,
hindamiskoosolekud, stand-upid, retrod)
läbiviimine, Kanban koosolekute läbiviimine
Jira, Confluence, Scrum, Kanban
Käesolevaga kinnitab pakkuja, et:
• spetsialist on tutvunud hangitava tööga ja andnud nõusoleku lepingu täitmisel
osalemiseks;
• spetsialisti CV-s esitatud andmed on õiged;
• spetsialist valdab kõiki asjakohaseid riigihanke alusdokumentides kirjeldatud
tehnoloogiaid ja metoodikaid ning on nõus neid lepingu täitmisel järgima;
• spetsialist vastab kõikidele esitatud nõuetele, sh keele nõudele;
• hankija võib kõiki siin esitatud andmeid igal ajal kontrollida.
Riigihange „TTJA e-teenuste keskkonna TARVIK arendus“
Viitenumber 291973
CV vorm
Spetsialisti ees- ja perekonnanimi: Aveli Klaos
Spetsialisti roll: Full-Stack tarkvara arendaja
Pakutud rolli eriala töökogemuse pikkus aastates: 4 aastat ja 3 kuud
Eesti keele kõneoskus: emakeel
Eesti keele kirjaoskus: emakeel
Kogemus nõutud rollis
Projekti nimetus: Eesti.ee tehniline kaasajastamine ja arendus
ning hooldustööd
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Riigi Infosüsteemi Amet. Annaliisa Kenppi,
Projekti toimumise aeg (alates-kuni): 11/2024 - praeguseni
Roll projektis: Full-stack tarkvara arendaja
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Isik osales projektis vahemikus: 11/2024 -
praeguseni
Arendaja on antud rollis full-stack arendaja ning
projektis teostatakse: Java arendus, Angular
arendus, automaattestide kirjutamine, ärireeglite
implementatsioon.Tehtud tööd põhinesid
mikroteenuste arhitektuuril.
Projektis kasutatud tehnoloogiad: PostgreSQL,
Angular, Java, Python, REST API, X-tee,
Spring Boot, Tomcat, Nginx, mikroteenused,
Oauth, ELK, Prometheus, Grafana, Redis,
Docker, Kubernetes, Jenkins, Webpack, Ansible,
Terraform, Maven, Gradle, Gitlab CI/CD, JSON,
Yaml, XML.
Projekti nimetus: Äritegevuseks tegevusloa taotlemise ja
majandustegevusteate esitamise analüüs ja
arendustööd
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Riigi Infosüsteemi Amet. Reimo Nõgu,
Projekti toimumise aeg (alates-kuni): 03/2024 – 12/2024
Roll projektis: Full-stack tarkvara arendaja
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Isik osales projektis vahemikus: 03/2024 –
12/2024
Arendaja oli antud rollis full-stack arendaja ning
projektis teostati: Java arendus, Angular arendus,
automaattestide kirjutamine, ärireeglite
implementatsioon.Tehtud tööd põhinesid
mikroteenuste arhitektuuril.
Projektis kasutatud tehnoloogiad: PostgreSQL,
Angular, Java, REST API, X-tee, Spring Boot,
Tomcat, Nginx, Oauth, ELK, mikroteenused,
Prometheus, Grafana, Redis, Docker, Kubernetes,
Jenkins, Webpack, Ansible, Terraform, Maven,
Gradle, JSON, Yaml, XML.
Projekti nimetus: Eesti.ee eraisiku ja ettevõtja vaadete tehniline
kaasajastamine
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Riigi Infosüsteemi Amet. Õie-Mari Aasmäe, oie-
Projekti toimumise aeg (alates-kuni): 05/2023 – 06/2024
Roll projektis: Full-stack tarkvara arendaja
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Isik osales projektis vahemikus: 11/2023 –
06/2024
Arendaja oli antud rollis full-stack arendaja ning
projektis teostati Java arendus, Angular arendus,
automaattestide kirjutamine, ärireeglite
implementatsioon.Tehtud tööd põhinesid
mikroteenuste arhitektuuril.
Kasutatud tehnoloogiad: PostgreSQL, Angular,
Java, REST API, X-tee, Spring Boot, Tomcat,
Nginx, Oauth, ELK, Prometheus,
mikroteenused, Grafana, Redis, Docker,
Kubernetes, Jenkins, Webpack, Ansible,
Terraform, Maven, Gradle, JSON, Yaml, XML.
Projekti nimetus: OECD Seemneskeemi digitaliseerimine
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
OECD (Majanduskoostöö ja Arengu
Organisatsioon), Csaba Gaspar,
Projekti toimumise aeg (alates-kuni): 10.2022 - praeguseni
Roll projektis: Full-stack tarkvara arendaja
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Isik osales projektisvahemikus: 09.2023 –
11.2023
Arendaja oli antud rollis full-stack arendaja ning
projektis teostati Java arendus, React arendus,
automaattestide kirjutamine, ärireeglite
implementatsioon.
Kasutatud tehnoloogiad: React, Material UI,
React Hook Form, Keycloak, Spring Boot
(Security, Data JPA, OAuth2), Gradle, MapStruct,
Hibernate, PostgreSQL, Liquibase, Swagger,
Docker, Grafana.
Projekti nimetus: Töötukassainfosüsteemi (EMPIS ja EMPIS2)
edasiarendus
Riigihanke viitenumber: 245235
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Töötukassa, Liivi Käär, [email protected]
Projekti toimumise aeg (alates-kuni): 05/2022 – …
Roll projektis: Full-stack tarkvara arendaja
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Isik osales projektis vahemikus: 08/2023 –
09/2023
Arendaja oli antud rollis full-stack arendaja ning
projektis teostati: Java arendus, UI arendus,
andmebaasi arendus, lahenduste valideerimine,
automaattestide kirjutamine, ärireeglite
implementatsioon. Tehtud tööd põhinesid
mikroteenuste arhitektuuril.
Projektis kasutatud tehnoloogiad: Java, JSP,
Spring, Spring Boot, Gradle, JUnit, Mockito,
Oracle Database, PostgreSQL, Hibernate,
mikroteenused, Liquibase, TypeScript, Angular,
Webpack, REST, JSON, YAML, Tomcat,
HTML, CSS (Sass), Grafana, Gitlab CI/CD,
RabbitMQ, X-tee, GitLab.
Projekti nimetus: Küberturbe õppuste tarkvara arendamine
(Cobalt Kingfisher, Golden Osprey)
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Nortal AS, Alar Kuuda, [email protected]
(ei tööta enam Nortal AS-is)
Projekti toimumise aeg (alates-kuni): 02/2021 – 08/2023
Roll projektis: Full-stack tarkvara arendaja
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Isik osales projektis vahemikus: 02/2021 –
08/2023
Arendaja oli antud rollis full-stack arendaja ning
projektis teostati: Java arendus, Python arendus,
.NET arendus, UI arendus, UX/UI disain,
andmebaasi arendus, lahenduste valideerimine,
automaattestide kirjutamine, ärireeglite
implementatsioon. Tehtud tööd põhinesid
mikroteenuste arhitektuuril.
Projektis kasutatud tehnoloogiad: Docker, Java,
Spring, Spring Boot, Gradle, PostgreSQL,
Hibernate, Liquibase, JavaScript, TypeScript,
mikroteenused, React, Webpack, Keycloak,
Nginx, REST, WebSocket, RTMP, JSON,
YAML, Tomcat, C#, .NET, HTML, CSS (Sass),
Figma, Postman, Grafana, Gitlab CI/CD, Python,
Bash, GitLab.
Käesolevaga kinnitab pakkuja, et:
• spetsialist on tutvunud hangitava tööga ja andnud nõusoleku lepingu täitmisel
osalemiseks;
• spetsialisti CV-s esitatud andmed on õiged;
• spetsialist valdab kõiki asjakohaseid riigihanke alusdokumentides kirjeldatud
tehnoloogiaid ja metoodikaid ning on nõus neid lepingu täitmisel järgima;
• spetsialist vastab kõikidele esitatud nõuetele, sh keele nõudele;
• hankija võib kõiki siin esitatud andmeid igal ajal kontrollida.
Riigihange „TTJA e-teenuste keskkonna TARVIK arendus“
Viitenumber 291973
CV vorm
Spetsialisti ees- ja perekonnanimi: Emil Azizov
Spetsialisti roll: Full-stack tarkvara arendaja
Pakutud rolli eriala töökogemuse pikkus aastates: 13 aastat
Eesti keele kõneoskus: väga hea
Eesti keele kirjaoskus: väga hea
Kogemus nõutud rollis
Projekti nimetus: Täienduskoolituste infosüsteem Juhan 2.0
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Haridus- ja Teadusministeerium
Rene Indrek Proos
Projekti toimumise aeg (alates-kuni): 06/2024 - …
Roll projektis: Full-stack tarkvara arendaja
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Isik osales projektis vahemikus: 06/2024 - …
Projekt asendab praegust Täienduskoolituse
infosüsteemi ja on veel arenduses.
Loodud Eesti haridusasutustele oma kursuste ja
koolituste loomiseks ja haldamiseks veebis. Seda
kasutavad üle Eesti asutuste direktorid, koolitajad,
professorid, projektijuhid, õpetajad ja teised
erinevad haridusvaldkonna spetsialistid.
PHP, PostgreSQL, x-tee, React, mikroteenuste
arhitektuur, Kubernetes, Docker, CI/CD
Projekti nimetus: Täienduskoolituste infosüsteem Juhan
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Haridus- ja Teadusministeerium
Rene Indrek Proos
Projekti toimumise aeg (alates-kuni): 06/2016 - …
Roll projektis: Full-stack tarkvara arendaja
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Isik osales projektis vahemikus: 06/2016-…
Loodud Eesti haridusasutustele oma kursuste ja
koolituste loomiseks ja haldamiseks veebis. Seda
kasutavad üle Eesti asutuste direktorid, koolitajad,
professorid, projektijuhid, õpetajad ja teised
erinevad haridusvaldkonna spetsialistid.
PHP, PostgreSQL, TARA, Docker, x-tee,
Kubernetes GitLab CI/CD
Projekti nimetus: SKAIS
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Tervise ja Heaolu Infosüsteemide Keskus
(TEHIK)
Epp Laanepõld
Projekti toimumise aeg (alates-kuni): 07/2020-07/2024
Roll projektis: Full-stack tarkvara arendaja
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Isik osales projektis vahemikus: 05/2021-08/2022
Sisemiseks kasutamiseks iseteenindus ja taotluste
menetlemine, X-tee liideste arendused. Vana
monoliitsüsteemi refaktoorimine ja uute
eraldiseisvate mikroteenuste ehitamine.
Java 11 / Java 8, Spring Boot, Hibernate,
PostgreSQL, Docker, XML, JSOn, REST, x-tee,
Kubernetes, Angular, mikroteenustel põhinev
arhitektuur
Projekti nimetus: My Credit Life frontoffice ja backoffice
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Axell Claims
Frits Keij
Projekti toimumise aeg (alates-kuni): 10/2018 - …
Roll projektis: Full-stack tarkvara arendaja
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Isik osales projektis vahemikus: 10/2018-…
Platvormid, mis katavad Credit Life'i
kindlustusprotsesside kogu elutsükli. Frontoffice'i
platvorm aitab optimeerida kindlustusseltside
igapäevatööd, vähendades töötajate
haldusülesandeid poliiside või kahjunõuete
menetlemisel. Võimalikult palju toiminguid on
automatiseeritud, läbipaistva protsessiga ning tänu
sellele on nüüd rohkem ruumi kindlustusandja ja
kliendi vahel inimfaktorile. Frontoffice'i
kasutavad kliendid, agendid, haldusosakonnad,
meditsiiniosakonnad, kahjukäsitlejad jne.
Backoffice'i platvormi kasutab haldusosakond
konfigureerimiseks ja haldustoiminguteks.
PHP, Symfony raamistik, PostgreSQL, Python,
XML, JSON, Apache, REST API, NPM,
mikroarhitektuur
Käesolevaga kinnitab pakkuja, et:
• spetsialist on tutvunud hangitava tööga ja andnud nõusoleku lepingu täitmisel
osalemiseks;
• spetsialisti CV-s esitatud andmed on õiged;
• spetsialist valdab kõiki asjakohaseid riigihanke alusdokumentides kirjeldatud
tehnoloogiaid ja metoodikaid ning on nõus neid lepingu täitmisel järgima;
• spetsialist vastab kõikidele esitatud nõuetele, sh keele nõudele;
• hankija võib kõiki siin esitatud andmeid igal ajal kontrollida.
Riigihange „TTJA e-teenuste keskkonna TARVIK arendus“
Viitenumber 291973
CV vorm
Spetsialisti ees- ja perekonnanimi: Kristjan Junus
Spetsialisti roll: Full-stack tarkvara arendaja
Pakutud rolli eriala töökogemuse pikkus aastates: 5+ aastat
Eesti keele kõneoskus: emakeel
Eesti keele kirjaoskus: emakeel
Kogemus nõutud rollis
Projekti nimetus: LIS infosüsteemi arendus
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Regionaal – ja Põllumajandusministeerium, Märt
Pakats, [email protected]
Projekti toimumise aeg (alates-kuni): 01.2020 - praeguseni
Roll projektis: Full-stack tarkvara arendaja
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Isik osales projektis vahemikus: 10.2022 -
praeguseni
Maaeluteadmuskeskusele uue laboriinfosüsteemi
ehitamine.
Kasutatud tehnoloogiad: Java, JavaScript,
HTML/CSS, SQL, Apache, Tomcat, SOAP Web
Services, Hibernate, Spring, Angular, Node.js,
Linux, PostgreSQL, x-tee teenused
Projekti nimetus: OECD Seemneskeemi digitaliseerimine
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
OECD (Majanduskoostöö ja Arengu
Organisatsioon), Csaba Gaspar,
Projekti toimumise aeg (alates-kuni): 10.2022 - praeguseni
Roll projektis: Full-stack tarkvara arendaja
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Isik osales projektis vahemikus: 05.2023 –
05.2024
OECD Seemneskeemile ühise süsteemi loomine,
mida kasutatakse 64 riigi poolt.
Kasutatud tehnoloogiad: React, Java, Material
UI, React Hook Form, Keycloak, Spring Boot
(Security, Data JPA, OAuth2), Gradle, MapStruct,
Hibernate, PostgreSQL, Liquibase, Swagger,
Docker, Grafana.
Projekti nimetus: RAKS2
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Politsei- ja Piirivalveamet, Marina Põldma,
Projekti toimumise aeg (alates-kuni): 11.2019 – 10.2022
Roll projektis: Full-stack tarkvara arendaja
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Isik osales projektis vahemikus: 11.2019 –
10.2022
Rahvusvahelise kaitse taotlejate menetlemise
keskkond.
Kasutatud tehnoloogiad: Java, JavaScript,
Typescript, HTML/CSS, SQL, Tomcat, SOAP
Web Services, Hibernate, Spring, Angular,
PostgreSQL, Spring Boot, Atlassian JIRA ja
Confluence, Bitbucket, Bamboo, Cloud Foundry,
RabbitMQ, AWS S3, x-tee teenused,
mikroteenustel põhinev arhitektuur
Projekti nimetus: RAKS
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Politsei- ja Piirivalveamet, Marina Põldma,
Projekti toimumise aeg (alates-kuni): 11.2019 – 10.2022
Roll projektis: Full-stack tarkvara arendaja
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Isik osales projektis vahemikus: 11.2019 –
10.2022
Rahvusvahelise kaitse taotlejate menetlemise
keskkond.
Kasutatud tehnoloogiad: Python 2, HTML/CSS,
Oracle database, Atlassian JIRA ja Confluence,
Bitbucket
Käesolevaga kinnitab pakkuja, et:
• spetsialist on tutvunud hangitava tööga ja andnud nõusoleku lepingu täitmisel
osalemiseks;
• spetsialisti CV-s esitatud andmed on õiged;
• spetsialist valdab kõiki asjakohaseid riigihanke alusdokumentides kirjeldatud
tehnoloogiaid ja metoodikaid ning on nõus neid lepingu täitmisel järgima;
• spetsialist vastab kõikidele esitatud nõuetele, sh keele nõudele;
• hankija võib kõiki siin esitatud andmeid igal ajal kontrollida.
Riigihange „TTJA e-teenuste keskkonna TARVIK arendus“
Viitenumber 291973
CV vorm
Spetsialisti ees- ja perekonnanimi: Madis Sander Maddison
Spetsialisti roll: Full-stack tarkvara arendaja
Pakutud rolli eriala töökogemuse pikkus aastates: 7+ aastat
Eesti keele kõneoskus: (märkida emakeel/väga hea/hea/vajab tõlki) emakeel
Eesti keele kirjaoskus: (märkida emakeel/väga hea/hea/vajab tõlki) emakeel
Kogemus nõutud rollis
Projekti nimetus: Eesti.ee tehniline kaasajastamine ja arendus
ning hooldustööd
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Riigi Infosüsteemi Amet. Annaliisa Kenppi,
Projekti toimumise aeg (alates-kuni): 11/2024 - ...
Roll projektis: Full-stack tarkvara arendaja
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Isik osales projektis vahemikus: 02/2025-....
Riigiportaali eesti.ee ning sellega seotud
rakenduste edasiarendamine, sündmusteenuste
arendus ja edasiarendus.
Kasutatud tehnoloogiad: PostgreSQL, Angular,
Java, REST API, Spring Boot, Tomcat, Nginx,
Oauth, ELK, Prometheus, Grafana, Redis,
Docker, Kubernetes,Webpack, Ansible,
Terraform, Maven, Gradle, JSON, Yaml, XML,
GovSSO, x-tee teenused, Mikroteenustel
põhinev arhitektuur
Projekti nimetus: TTJA E-teenuste keskkonna pääsuhalduse
arendus
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Keskkonnaministeeriumi Infotehnoloogiakeskus
Projekti toimumise aeg (alates-kuni): 07/2024-01/2025
Roll projektis: Full-stack tarkvara arendaja
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Isik osales projektis vahemikus: 07/2024-01/2025
TARVIKU liidestus keskse volituste halduse
süsteemiga Pääsuke, kontaktide ja rollide ning
privileegide migratsioon TARVIKUsse. Tehniline
analüüs, arendus, automaattestide kirjutamine,
koodiülevaatus.
Java, JavaScript/Typescript, , Angular HTML,
CSS, Spring, Hibernate, PostgreSQL, IntelliJ
IDEA, Postman (API), Docker, REST arendus ja
liidestus, JSON, XML, YAML Spring Boot,
klaster, x-tee, mikroteenused
Projekti nimetus: Alpha 3D iseteeninduse loomine
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Alpha 3D OÜ
Rait-Eino Laarmann: [email protected]
Projekti toimumise aeg (alates-kuni): 06/2022-01/2024
Roll projektis: Full-stack tarkvara arendaja
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Isik osales projektis vahemikus: 07/2022- 11/2022
AI-genereeritud 3D mudelite tellimise keskkonna
front-end, back-end arendus, andmebaaside
arendus, SQL päringute tegemine, platvormi
migreerimine AWS-ist Google Cloudi,
automaattestide kirjutamine, koodiülevaatus
Java, JavaScript/Typescript, HTML, CSS, Spring
Boot, Spring, Python, Hibernate, React,
PostgreSQL, IntelliJ IDEA, Postman (API),
Gradle, Docker, GIT, Nginx, REST arendus ja
liidestus, mikroteenused
Projekti nimetus: CERN (Euroopa Tuumauuringute Keskus)
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
CERN
Juan Lopez Gonzalez, [email protected]
Projekti toimumise aeg (alates-kuni): 07/2022- 03/2024
Roll projektis: Full-stack tarkvara arendaja
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Isik osales projektis vahemikus: 11/2022-03/2024
EDH / keskse dokumentide menetelmise süsteemi
arendused Java arendus, UI arendus, lahenduste
valideerimine, liideste teostus, admebaaside
arendus, Helmese arendustiimi juhtimine,
automaattestide kirjutamine (ühik-
integratsioonitestid)
Java 11, JSP, JS, Spring, Oracle DB 19c, Tomcat
(klaster), Activity, Camunda, Spring Boot
(erinevad tehnoloogiad, kuna on uuemaid ja
vanemaid mooduleid), REST, JUnit ATS
(veebipõhine): React 18, Typescript, Spring
Boot, Oracle DB 19c, Docker, Tomcat, Liquibase,
XML, JSON, Kubernetes, Grafana, Helm,
mikroteenused
Projekti nimetus: Lennureiside broneeringuinfo süsteem (PNR)
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Siseministeeriumi infotehnoloogia- ja
arenduskeskus (SMIT) kontaktisik Dmitri Pauts
Projekti toimumise aeg (alates-kuni): 05/2019-06/2022
Roll projektis: Full-stack tarkvara arendaja
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Isik osales projektis vahemikus: 05/2019-06/2022
Lennureiside broneeringuinfo süsteem (PNR)
arendus
Java, HTML, CSS, Bamboo,
JavaScript/Typescript, Webpack, Klasterdatud
lahendus, Cloud Foundry, Spring Boot, Spring,
Hibernate, React, XML, JSON, YAML,
PostgreSQL, RabbitMQ, IntelliJ IDEA, Postman
(API), Junit, SOAP-UI, REST, Mockito, Gradle,
Docker, GIT, SpectX, mikroteenustel põhinev
arhitektuur, x-tee teenused
Projekti nimetus: Nordea (Luminor) internetipanga arendus
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Luminor Bank AS
Kontaktisik: Daina Oša
Projekti toimumise aeg (alates-kuni): Pidev arendus
Roll projektis: Full-stack tarkvara arendaja
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Isik osales projektis vahemikus: 07/2017-03/2019
Töö agiilsete meetoditega (Scrum, Kanban):
T24 arendus (back-end), UI arendus (front-end),
Liideste teostus, Andmebaaside arendus, Testide
kirjutamine (unit, integratsioon)
Käesolevaga kinnitab pakkuja, et:
• spetsialist on tutvunud hangitava tööga ja andnud nõusoleku lepingu täitmisel
osalemiseks;
• spetsialisti CV-s esitatud andmed on õiged;
• spetsialist valdab kõiki asjakohaseid riigihanke alusdokumentides kirjeldatud
tehnoloogiaid ja metoodikaid ning on nõus neid lepingu täitmisel järgima;
• spetsialist vastab kõikidele esitatud nõuetele, sh keele nõudele;
• hankija võib kõiki siin esitatud andmeid igal ajal kontrollida.
Riigihange „TTJA e-teenuste keskkonna TARVIK arendus“
Viitenumber 291973
CV vorm
Spetsialisti ees- ja perekonnanimi: Patrick Lomp
Spetsialisti roll: Full-stack tarkvara arendaja
Pakutud rolli eriala töökogemuse pikkus aastates: 4 aastat ja 7 kuud
Eesti keele kõneoskus: emakeel
Eesti keele kirjaoskus: emakeel
Kogemus nõutud rollis
Projekti nimetus: Keskse volituse haldamise süsteemi Pääsuke
analüüsi-, arendus- ja hooldustööd
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
RIA, Tanel Tsirgu
Projekti toimumise aeg (alates-kuni): 03/2025-…
Roll projektis: Full-stack tarkvara arendaja
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Isik osales projektis vahemikus: 03/2025-…
Volituste haldamise süsteemi Pääsuke
edasiarendused. Front-end ja back-end arendus,
testide kirjutamine, koodiülevaatus.
Angular, Java, PostgreSQL, Prometheus,
Spring Boot, Docker, Grafana, Opensearch, x-tee,
Openapi, Jenkins, Mikroteenustel põhinev
arhitektuur
Projekti nimetus: TTJA e-teenuste platvormi jätkuarendused
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Keskkonnaministeeriumi Infotehnoloogiakeskus
Projekti toimumise aeg (alates-kuni): 08/2024-01/2025
Roll projektis: Full-stack tarkvara arendaja
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Isik osales projektis vahemikus: 09/2024-01/2025
Majandustegevusteadete migratsioon vanast
Majandustegevuse Registrist uude,
majandustegevusteadete vormide back-end ja
front-end arendused, SQL programmeerimine,
avalik koodihoidla.
Java, JavaScript/Typescript, Webpack, Angular,
HTML, CSS, SQL päringute kirjutamine,
SpringBoot, Spring, Hibernate, PostgreSQL,
IntelliJ IDEA, Postman (API), Docker, REST
arendus ja liidestus, JSON, klaster, XML, Nginx,
GitLab, x-tee, mikroteenused
Projekti nimetus: Sündmuste infosüsteemi SIS arendus
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
RMIT/RTK
Kontaktisik: Indrek Mägi
Projekti toimumise aeg (alates-kuni): 01/2021– ...
Roll projektis: Full-stack tarkvara arendaja
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Isik osales projektis vahemikus: 04/2024-03/2025
Rakenduse frontendi ja backendi arendus. Liideste
teostus. Automaattestide kirjutamine (ühiktestid,
integratsioonitestid end-toend testid, UI testid).
Angular 11, Javascript, Typescript 4, npm 7, Java
11, Spring Boot 2.4, Hibernate, Mapstruct,
Lombok, Liquibase, PostgreSQL 12, OpenAPI,
Tomcat (klaster), Apache HTTP Server, Docker,
Hajus arhitektuur, Gradle Testid: Junit-jupiter,
Selenide, Testcontainers, Jest, Spotbugs, Jenkins,
XML, JSON, REST, x-tee
Projekti nimetus: Systemum GmbH & Co. KG - Seghorn
võlglaste portaali arendus
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Systemum , Jan Hansmann
Projekti toimumise aeg (alates-kuni): 04/2023 - 12/2023
Roll projektis: Full-stack tarkvara arendaja
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Isik osales projektis vahemikus: 04/2023 -
11/2023
Inkasso nõuete haldamise platvormi arendus.
Kasutatud tehnoloogiad: Vue, Keycloak,
OpenAPI, Jenkins, Java, Spring Boot, Spring
Web, Spring Security, Spring Data JPA, Spring
OAuth2, Hibernate, MariaDB, MySQL, Flyway,
Maven, Docker, Sonar, JaCoCo, JUnit, AssertJ,
MapStruct, Apache POI, Apache Commons,
Micrometer, Prometheus
Projekti nimetus: Infokogumise ja küsitluste süsteemi PAR.IS
arendus
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
OECD, Nicole Delecluse
Projekti toimumise aeg (alates-kuni): 09/2020 – ...
Roll projektis: Full-stack tarkvara arendaja
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Isik osales projektis vahemikus: 12/2023-03/2024
Tarkvaraarendaja – disain, baasloogika loomine,
prototüüpimine, arendamine, SQL päringute
kirjutamine, suhtlus kliendiga, analüüsimine,
testimine, automaattestide loomine ning
täiendamine, rakenduse ja andmebaasi
ülalpidamine ja hooldus
Java, Javascript, XML, Spring Boot, Docker,
JSON, PostgreSQL, Angular, Apache, Tomcat
(klaster), Jenkins, Junit, Protractor, Jhipster, REST
arendus ja liidestus, Elasticsearch, JAXB, Gradle,
NPM, ELK Stack, CI/CD
Projekti nimetus: ALPHA 3D automaatsete tellimuste
iseteeninduskeskkonna arendus
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
ALPHA 3D OÜ,
kontaktisik Rait-Eino Laarmann [email protected]
Projekti toimumise aeg (alates-kuni): 05/2022 - …
Roll projektis: Full-stack tarkvara arendaja
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Isik osales projektis vahemikus: 01/2023 -...
ALPHA 3D – iseteeninduse platvormi loomine,
Java arendus (back-end, UI arendus (front-end),
Liideste teostus, Andmebaaside arendus, SQL
päringute tegemine, platvormi migreerimine
AWS-ist Google Cloudi, Avalik koodihoidla
Java, JavaScript/Typescript, HTML, CSS, React,
Spring Boot, Spring, Hibernate, PostgreSQL,
Postman (API), Gradle, Docker, Nginx, REST
arendus ja liidestus, AWS, Google Cloud, XML,
JSON, GitLab, Python, mikroteenused
Projekti nimetus: Erimärgistatud diislikütuse õigustatud isikute
registri arendamine
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
PRIA (Põllumajanduse Registrite ja
Informatsiooni Amet) Kontaktisik: Külli Pirksaar
Projekti toimumise aeg (alates-kuni): 01/2022 -
Roll projektis: Full-stack tarkvara arendaja
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Isik osales projektis vahemikus:08/2022 - 12/2022
Tegemist on nii infosüsteemi uute moodulite
loomise kui ka modifitseerimise ja juurutamise
projektiga. Projekti sisu: Olemasolevate PRIA
vaadete täiendamine, uute teenuste, moodulite ja
vaadete loomine. Riigipilve lahenduse
kasutamine. Teenuste disainimine, analüüs,
testimine (sh. automaattestid).)
Fisheye, Bamboo, Java, JavaScript, HTML/CSS,
SQL, Angular, Jest, Spring Boot, Junit,
PostgreSQL, Tomcat, REST, OAuth, Docker,
Grafana, mikroteenused, x-tee
Projekti nimetus: KOLT - Kaitseväe olukorra ja
lahinguteadlikkuse süsteemi arendamine
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Eesti Kaitsevägi, Küberväejuhatus
Kontaktisik: Pearu Pung, [email protected]
Projekti toimumise aeg (alates-kuni): Pidev arendus
Roll projektis: Full-stack tarkvara arendaja
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Isik osales projektis vahemikus: 08/2021-06/2022
Azure DevOps ,Java, TypeScript, HTML/CSS,
SQL, AngularJS, React, Spring Boot, Junit,
PostgreSQL, Ubuntu Linux, MySQL
Projekti nimetus: Boonuste ja rahakoti teenuste arendus
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Playtech
Kontaktisik: Karis Reilent
Projekti toimumise aeg (alates-kuni): Pidev arendus
Roll projektis: Full-stack tarkvara arendaja
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Isik osales projektis vahemikus: 09/2020-07/2021
Bitbucket, Bamboo, Java, JavaScript, PHP,
HTML/CSS, SQL, Apache Tapestry, SpringBoot,
Junit, Oracle SQL, Docker
Käesolevaga kinnitab pakkuja, et:
• spetsialist on tutvunud hangitava tööga ja andnud nõusoleku lepingu täitmisel
osalemiseks;
• spetsialisti CV-s esitatud andmed on õiged;
• spetsialist valdab kõiki asjakohaseid riigihanke alusdokumentides kirjeldatud
tehnoloogiaid ja metoodikaid ning on nõus neid lepingu täitmisel järgima;
• spetsialist vastab kõikidele esitatud nõuetele, sh keele nõudele;
• hankija võib kõiki siin esitatud andmeid igal ajal kontrollida.
Riigihange „TTJA e-teenuste keskkonna TARVIK arendus“
Viitenumber 291973
CV vorm
Spetsialisti ees- ja perekonnanimi: Siim Tanel Laisaar
Spetsialisti roll: Full-stack tarkvara arendaja
Pakutud rolli eriala töökogemuse pikkus aastates: 4 aastat ja 3 kuud
Eesti keele kõneoskus: (märkida emakeel/väga hea/hea/vajab tõlki) emakeel
Eesti keele kirjaoskus: (märkida emakeel/väga hea/hea/vajab tõlki) emakeel
Kogemus nõutud rollis
Projekti nimetus: Eesti.ee tehniline kaasajastamine ja arendus
ning hooldustööd
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Riigi Infosüsteemi Amet
Annaliisa Kenppi,
Projekti toimumise aeg (alates-kuni): 11/2024 - ...
Roll projektis: Full-stack tarkvara arendaja
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Isik osales projektis vahemikus: 11/2024 -
praeguseni
Arendaja on antud rollis full-stack arendaja ning
projektis teostatakse: Java arendus, Angular
arendus, automaattestide kirjutamine, ärireeglite
implementatsioon.Tehtud tööd põhinesid
mikroteenuste arhitektuuril.
Projektis kasutatud tehnoloogiad: PostgreSQL,
Angular, Java, Python, REST API, X-tee,
Spring Boot, Tomcat, Nginx, Oauth, ELK,
Prometheus, Grafana, Redis, Docker, Kubernetes,
Jenkins, Webpack, Ansible, Terraform, Maven,
Gradle, Gitlab CI/CD, JSON, Yaml, XML,
mikroteenused.
Projekti nimetus: Äritegevuseks tegevusloa taotlemise ja
majandustegevusteate esitamise analüüs ja
arendustööd
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Riigi Infosüsteemi Amet
Reimo Nõgu
Projekti toimumise aeg (alates-kuni): 03/2024 – 12/2024
Roll projektis: Full-stack tarkvara arendaja
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Isik osales projektis vahemikus: 03/2024 –
12/2024
Arendaja oli antud rollis full-stack arendaja ning
projektis teostati: Java arendus, Angular arendus,
automaattestide kirjutamine, ärireeglite
implementatsioon.Tehtud tööd põhinesid
mikroteenuste arhitektuuril.
Projektis kasutatud tehnoloogiad: PostgreSQL,
Angular, Java, REST API, X-tee, Spring Boot,
Tomcat, Nginx, Oauth, ELK, Prometheus,
Grafana, Redis, Docker, Kubernetes, Jenkins,
Webpack, Ansible, Terraform, Maven, Gradle,
JSON, Yaml, XML, mikroteenused.
Projekti nimetus: Eesti.ee eraisiku vaate jätkutööd ning
analüütika vahendite korrastamine
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Riigi Infosüsteemi Amet
Õie-Mari Aasmäe
Projekti toimumise aeg (alates-kuni): 06/2023 – 06/2024
Roll projektis: Full-stack tarkvara arendaja
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Isik osales projektis vahemikus: 11/2023 –
06/2024
Arendaja oli antud rollis full-stack arendaja ning
projektis teostati: Java arendus, Angular arendus,
automaattestide kirjutamine, ärireeglite
implementatsioon.Tehtud tööd põhinesid
mikroteenuste arhitektuuril.
Projektis kasutatud tehnoloogiad: PostgreSQL,
Angular, Java, REST API, X-tee, Spring Boot,
Tomcat, Nginx, Oauth, ELK, Prometheus,
Grafana, Redis, Docker, Kubernetes, Jenkins,
Webpack, Ansible, Terraform, Maven, Gradle,
JSON, Yaml, XML, mikroteenused.
Projekti nimetus: OECD Seemneskeemi digitaliseerimine
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
OECD (Majanduskoostöö ja Arengu
Organisatsioon), Csaba Gaspar,
Projekti toimumise aeg (alates-kuni): 10.2022 - praeguseni
Roll projektis: Full-stack tarkvara arendaja
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Isik osales projektisvahemikus: 09.2023 – 11.2023
Arendaja oli antud rollis full-stack arendaja ning
projektis teostati Java arendus, React arendus,
automaattestide kirjutamine, ärireeglite
implementatsioon.
Kasutatud tehnoloogiad: React, Material UI,
React Hook Form, Keycloak, Spring Boot
(Security, Data JPA, OAuth2), Gradle, MapStruct,
Hibernate, PostgreSQL, Liquibase, Swagger,
Docker, Grafana, mikroteenused.
Projekti nimetus: Töötukassainfosüsteemi (EMPIS ja EMPIS2)
edasiarendus
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Töötukassa
Liivi Käär
Projekti toimumise aeg (alates-kuni): 05/2022 – …
Roll projektis: Full-stack tarkvara arendaja
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Isik osales projektis vahemikus: 08/2023 –
09/2023
Arendaja oli antud rollis full-stack arendaja ning
projektis teostati: Java arendus, UI arendus,
andmebaasi arendus, lahenduste valideerimine,
automaattestide kirjutamine, ärireeglite
implementatsioon. Tehtud tööd põhinesid
mikroteenuste arhitektuuril.
Projektis kasutatud tehnoloogiad: Java, JSP,
Spring, Spring Boot, Gradle, JUnit, Mockito,
Oracle Database, PostgreSQL, Hibernate,
Liquibase, TypeScript, Angular, Webpack,
REST, JSON, YAML, Tomcat, HTML, CSS
(Sass), Grafana, Gitlab CI/CD, RabbitMQ, X-tee,
GitLab, mikroteenused.
Projekti nimetus: Küberturbe õppuste tarkvara arendamine
(Cobalt Kingfisher, Golden Osprey)
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Nortal AS,
Alar Kuuda (ei tööta enam Nortal AS-is)
Projekti toimumise aeg (alates-kuni): 02/2021 – 08/2023
Roll projektis: Full-stack tarkvara arendaja
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Isik osales projektis vahemikus: 02/2021 –
08/2023
Arendaja oli antud rollis full-stack arendaja ning
projektis teostati: Java arendus, Python arendus,
.NET arendus, UI arendus, UX/UI disain,
andmebaasi arendus, lahenduste valideerimine,
automaattestide kirjutamine, ärireeglite
implementatsioon. Tehtud tööd põhinesid
mikroteenuste arhitektuuril.
Projektis kasutatud tehnoloogiad: Docker, Java,
Spring, Spring Boot, Gradle, PostgreSQL,
Hibernate, Liquibase, JavaScript, TypeScript,
React, Webpack, Keycloak, Nginx, REST,
WebSocket, RTMP, JSON, YAML, Tomcat, C#,
.NET, HTML, CSS (Sass), Figma, Postman,
Grafana, Gitlab CI/CD, Python, Bash, GitLab,
mikroteenused.
Käesolevaga kinnitab pakkuja, et:
• spetsialist on tutvunud hangitava tööga ja andnud nõusoleku lepingu täitmisel
osalemiseks;
• spetsialisti CV-s esitatud andmed on õiged;
• spetsialist valdab kõiki asjakohaseid riigihanke alusdokumentides kirjeldatud
tehnoloogiaid ja metoodikaid ning on nõus neid lepingu täitmisel järgima;
• spetsialist vastab kõikidele esitatud nõuetele, sh keele nõudele;
• hankija võib kõiki siin esitatud andmeid igal ajal kontrollida.
Riigihange „TTJA e-teenuste keskkonna TARVIK arendus“
Viitenumber 291973
CV vorm
Spetsialisti ees- ja perekonnanimi: Pearu Sarv
Spetsialisti roll: front-end arendaja
Pakutud rolli eriala töökogemuse pikkus aastates: üle 5 aasta
Eesti keele kõneoskus: emakeel
Eesti keele kirjaoskus: emakeel
Kogemus nõutud rollis
Projekti nimetus: Tööelu Infosüsteemi (TEIS) arendus
(2024a hange nr 276737)
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Tervise ja Heaolu Infosüsteemide Keskus
Rainer Rohtla
Projekti toimumise aeg (alates-kuni): 08.2024 – tänaseni
Roll projektis: Front-end arendaja
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Pearu osales projektis 02.2025 – tänaseni.
Micro-FE arendust sisaldav projekt.
Projekti raames arendatakse edasi Tööelu
infosüsteemi, sh ehitusobjektide järelevalve
funktsionaalsust ja töövaidluste funktsionaalsust
Projekti tehnoloogiad/keeled/vahendid: Swagger,
Figma, Confluence, Scrum, Jira, Angular jms.
Projekti nimetus: Tööelu Infosüsteemi (TEIS) arendus
(2020a hange nr 223406)
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Tervise ja Heaolu Infosüsteemide Keskus
Rainer Rohtla
Projekti toimumise aeg (alates-kuni): 10.2020 – 08.2024
Roll projektis: Front-end arendaja
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Pearu osales projektis 08.2021 - 06.2024
Micro-FE arendust sisaldav projekt.
Projekti eesmärgiks oli uue Tööinspektsiooni
infosüsteemi edasiarendus, sh Riskianalüüsi
funktsionaalsuse automatiseerimise ja
digitaliseerimine ning vastava tarkvaraplatvormi
analüüs, disain ning arendus.
Projekti tehnoloogiad/keeled/vahendid: Swagger,
Confluence, Jira, Angular, PostgreSQL, Axure
RP, Figma, TeamRetro, Drupal, Bootstrap,
Webpack, SASS/SCSS, HTML5, Javascript, AXE
(WEB Accessibility Testing), Postman,
VoiceOver ekraanilugeja
Projekti nimetus: eProspera infosüsteemi analüüs, disain ja
arendus
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Vertikal Digital OÜ
Silver Siniavski, [email protected]
Projekti toimumise aeg (alates-kuni): 05.2020 - 06.2023
Roll projektis: Front-end arendaja
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Pearu osales projektis 07.2021 - 06.2023
Hondurases asuva Próspera
erimajandustsooni keskse infosüsteemi
„ePróspera“ loomine.
Projekti tehnoloogiad/keeled/vahendid: React.js,
Next.js, Scrum, agile, Bitbucket, Confluence, Jira,
Swagger, Figma, Postman, Node.js, MongoDB,
Amazon Web Services, NestJS, Jest, Java
Projekti nimetus: Haridussilma veebirakenduse arendamine 2023
(viitenumber 260559)
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Haridus- ja Teadusministeerium
Kairit Peekman
Projekti toimumise aeg (alates-kuni): 09.2023 – tänaseni
Roll projektis: Front-end arendaja
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Pearu osales projektis 09.2023 – tänaseni.
Eesti hariduse teabevärav Haridussilm koondab
kokku alus-, üld-, kutse- ja kõrghariduse, keele- ja
noortevaldkonna andmeid ning kajastab
elukestvas õppes osalemise ja tööturule sisenemise
edukusega seotud näitajaid. Samuti annab
Haridussilm ülevaate haridusstrateegia sihtidest
ning nende poole liikumisest.
Projekti tehnoloogiad/keeled/vahendid:
Figma, Scrum, Confluence, Jira, Rest
API, Spring, Java, Angular.
Projekti nimetus: Telema PDS keskkonna front-end tööd
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Telema AS
Pille Anderson,
Projekti toimumise aeg (alates-kuni): 02.2020 - 08.2022
Roll projektis: Front-end arendaja
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Pearu osales projektis 04.2020 - 06.2022.
Telema Component Libary arenduse projekt, mille
raames loodi komponente, mida oli vaja PDS
toote arendamiseks.
Projekti tehnoloogiad/keeled/vahendid: Jira,
Figma, HTML5, SASS/SCSS, CSS3,
WebComponents, Storybook, kanban, git,
TypeScript, Angular 2+, Vue.js, Axure RP,
Pivotal tracker
Projekti nimetus: Eesti hariduse infosüsteemi (EHIS) uue
tehnilise platvormi (EHIS2) arendusteenuse I
etapp
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Tietoevry Estonia AS (peatöövõtja)
Raili Luumann
Projekti toimumise aeg (alates-kuni): 01.2019 - 02.2020
Roll projektis: Front-end arendaja
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Pearu osales projektis 08.2019 - 02.2020.
Projekt on jagatud etappidesse. Siin on tegu
EHIS1-st EHIS2-le ülemineku esimese etapi
arendustöödega.
Projekti tehnoloogiad/keeled/vahendid: Jira,
Confluence, EndTest, Postman, Browserstack,
JAWS ekraanilugeja, VoiceOver ekraanilugeja,
NVDA ekraanilugeja, SEO inspector, WAVE
Evaluation Tool, Scrum, Figma, Angular 2+,
Storybook, Bootstrap, RxJS, Elasticsearch, Rest
API, Docker, xjson, Json
Projekti nimetus: ERGO Baltics välisveebi ja iseteeninduse
arendus
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
ERGO Insurance SE
Oskars Matisons, [email protected]
Baiba Žuka, [email protected]
Projekti toimumise aeg (alates-kuni): 03.2023 – tänaseni
Roll projektis: Front-end arendaja
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Pearu osales projektis 03.2023 - 11.2023
Ergo Baltics välisveebi ja iseteeninduse arendus.
Drupal CMS + ReactJS headless veebilahendus
(ergo.ee, hiljem ergo.lt ja ergo.lv) ning
iseteeninduse FE arendus.
Projekti tehnoloogiad/keeled/vahendid: React.js,
Java, Next.js, Figma, Jira, Confluence, headless
Drupal, CSS3, Postman, Docker, Drupal 10,
JAWS ekraanilugeja
Projekti nimetus: STAR: Täisealise isiku abivajaduse hindamine
(viitenumber 264459)
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Tervise ja Heaolu Infosüsteemide Keskus
Katre Pukk, [email protected]
Projekti toimumise aeg (alates-kuni): 10.2023 - 08.2024
Roll projektis: Front-end arendaja
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Pearu osales projektis 01.2024 - 12.2024
STAR: Täisealise isiku abi- ja toetusvajaduse
hindamisandmete haldamise, arhiveerimise ning
valdkondade ülese vahetamise digitaliseerimise
detailanalüüs ja arendus.
Projekti tehnoloogiad/keeled/vahendid:
Figma, Confluence, React.js, Postman, Java, Jira,
TeamRetro jms.
Käesolevaga kinnitab pakkuja, et:
• spetsialist on tutvunud hangitava tööga ja andnud nõusoleku lepingu täitmisel
osalemiseks;
• spetsialisti CV-s esitatud andmed on õiged;
• spetsialist valdab kõiki asjakohaseid riigihanke alusdokumentides kirjeldatud
tehnoloogiaid ja metoodikaid ning on nõus neid lepingu täitmisel järgima;
• spetsialist vastab kõikidele esitatud nõuetele, sh keele nõudele;
• hankija võib kõiki siin esitatud andmeid igal ajal kontrollida.
Riigihange „TTJA e-teenuste keskkonna TARVIK arendus“
Viitenumber 291973
CV vorm
Spetsialisti ees- ja perekonnanimi: Voldemar Pungar
Spetsialisti roll: Front-end arendaja
Pakutud rolli eriala töökogemuse pikkus aastates: Üle 4 aasta
Eesti keele kõneoskus: emakeel
Eesti keele kirjaoskus: emakeel
Kogemus nõutud rollis
Projekti nimetus: Tööelu Infosüsteemi (TEIS) arendus
(2024a hange nr 276737)
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Tervise ja Heaolu Infosüsteemide Keskus
Rainer Rohtla
Projekti toimumise aeg (alates-kuni): 08.2024 – tänaseni
Roll projektis: Front-end arendaja
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Voldemar osales projektis 08.2024 – tänaseni.
Micro-FE arendust sisaldav projekt.
Projekti raames arendatakse edasi Tööelu
infosüsteemi, sh ehitusobjektide järelevalve
funktsionaalsust ja töövaidluste funktsionaalsust
Projekti tehnoloogiad/keeled/vahendid: Swagger,
Figma, Confluence, Scrum, Jira, Angular jms.
Projekti nimetus: Tööelu Infosüsteemi (TEIS) arendus
(2020a hange nr 223406)
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Tervise ja Heaolu Infosüsteemide Keskus
Rainer Rohtla
Projekti toimumise aeg (alates-kuni): 10.2020 – 08.2024
Roll projektis: Front-end arendaja
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Voldemar osales projektis 04.2022 - 08.2024.
Micro-FE arendust sisaldav projekt.
Projekti eesmärgiks oli uue Tööinspektsiooni
infosüsteemi edasiarendus, sh Riskianalüüsi
funktsionaalsuse automatiseerimise ja
digitaliseerimine ning vastava tarkvaraplatvormi
analüüs, disain ning arendus.
Projekti tehnoloogiad/keeled/vahendid: Swagger,
Confluence, Jira, Angular, PostgreSQL, Axure
RP, Figma, TeamRetro, Drupal, Bootstrap,
Webpack, SASS/SCSS, HTML5, Javascript, AXE
(WEB Accessibility Testing), Postman,
VoiceOver ekraanilugeja
Projekti nimetus: Oixio.ee veebilehe arendus- ja hooldustööd
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
OIXIO IT AS
Raul Pero, [email protected]
Projekti toimumise aeg (alates-kuni): 11.2017 - 01.2022
Roll projektis: Front-end arendaja
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Voldemar osales projektis 06.2020 - 05.2021.
Oixio.ee kodulehe ja e-poe erinevad analüüsi-,
disaini- ja tarkvaraarendustööd ning seonduvad
tegevused.
Projekti tehnoloogiad/keeled/vahendid: Drupal,
Json, Rest API, Elasticsearch, MongoDB, XML,
Varnish, Jira, HTML, Figma, Javascript, LESS,
CSS3, sCSS, Jira Service Management
Projekti nimetus: Fotode tellimiskeskkonna Photoexpress.ee
arendus
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
NORDIC DIGITAL AS
Allar Häling, [email protected]
Projekti toimumise aeg (alates-kuni): 05.2012 – tänaseni
Roll projektis: Front-end arendaja
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Voldemar osales projektis 08.2020 - 09.2021.
Photopointi fotode tellimiskeskkond
Photoexpress.ee. Sisaldab ka administreerimist ja
statistikakeskkonda. Liidestatud laboritega. Hiljem
loodud ja liidestatud ka IOS ja Androidi native
äpid.
Projekti tehnoloogiad/keeled/vahendid: Android
Studio, Javascript, HTML, Figma, Drupal 7,
Adobe Photoshop, Swift, iOS, HTML5
Projekti nimetus: Haridusportaal edu.ee arendus (2020, viide
220246)
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Haridus- ja Teadusministeerium
Erkki Jakobson, [email protected]
Projekti toimumise aeg (alates-kuni): 09.2020 - tänaseni
Roll projektis: Back-end arendaja (Drupal)
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Voldemar osales projektis 12.2020 - 08.2022
Üleriigilise haridusportaali arendustööd, sh
arendus, analüüs, disain, testimine jms.
Projekti tehnoloogiad/keeled/vahendid: Angular
2+, Storybook, Bootstrap, RxJS, Elasticsearch,
Rest API, Docker, WAVE Evaluation Tool, Jira,
Confluence, EndTest, TeamRetro, Browserstack,
SEO inspector, VoiceOver ekraanilugeja, NVDA
ekraanilugeja, Figma, Miro, Slack, Json, PHP 7,
Drupal, headless Drupal, Graph QL, Zeplin, xjson,
Drupal 8, Drupal 9, JAWS ekraanilugeja,
Postman, PHP 8, UML, Automation for Jira,
Javascript, Bamboo, GitLab
Käesolevaga kinnitab pakkuja, et:
• spetsialist on tutvunud hangitava tööga ja andnud nõusoleku lepingu täitmisel
osalemiseks;
• spetsialisti CV-s esitatud andmed on õiged;
• spetsialist valdab kõiki asjakohaseid riigihanke alusdokumentides kirjeldatud
tehnoloogiaid ja metoodikaid ning on nõus neid lepingu täitmisel järgima;
• spetsialist vastab kõikidele esitatud nõuetele, sh keele nõudele;
• hankija võib kõiki siin esitatud andmeid igal ajal kontrollida.
Riigihange „TTJA e-teenuste keskkonna TARVIK arendus“
Viitenumber 291973
CV vorm
Spetsialisti ees- ja perekonnanimi: Hanna-Liisa Vilbiks
Spetsialisti roll: Analüütik
Pakutud rolli eriala töökogemuse pikkus aastates: 5+ aastat
Eesti keele kõneoskus: emakeel
Eesti keele kirjaoskus: emakeel
Kogemus nõutud rollis
Projekti nimetus: Eesti.ee tehniline kaasajastamine ja arendus
ning hooldustööd
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Riigi Infosüsteemi Amet. Annaliisa Kenppi,
Projekti toimumise aeg (alates-kuni): 11/2024 - praeguseni
Roll projektis: Süsteemianalüütik
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Isik osales projektis vahemikus: 11/2024 -
praeguseni
Kasutajaliidese analüüs (koostöös UI/UX
disaineritega), spetsifikatsioonide analüüs ja
dokumenteerimine (sh äriprotsesside joonised),
rakenduse andmemudeli ning andmemudeli
analüüs ja dokumenteerimine, piletite
ettevalmistamine arendajatele.
Kasutatud tehnoloogiad: PostgreSQL, Angular,
Java, Python, REST API, Spring Boot, Tomcat,
Nginx, Oauth, ELK, Prometheus, Grafana, Redis,
Docker, Kubernetes, Jenkins, Webpack, Ansible,
Terraform, Maven, Gradle, Gitlab CI/CD, JSON,
Yaml, XML.
Projekti nimetus: Äritegevuseks tegevusloa taotlemise ja
majandustegevusteate esitamise analüüs ja
arendustööd
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Riigi Infosüsteemi Amet. Reimo Nõgu,
Projekti toimumise aeg (alates-kuni): 03/2024 – 12/2024
Roll projektis: Süsteemianalüütik
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Isik osales projektis vahemikus: 03/2024 –
12/2024.
Kasutajaliidese analüüs (koostöös UI/UX
disaineritega), spetsifikatsioonide analüüs ja
dokumenteerimine (sh äriprotsesside joonised),
rakenduse andmemudeli ning andmemudeli
analüüs ja dokumenteerimine, piletite
ettevalmistamine arendajatele.
Kasutatud tehnoloogiad: PostgreSQL, Angular,
Java, REST API, Spring Boot, Tomcat, Nginx,
Oauth, ELK, Prometheus, Grafana, Redis, Docker,
Kubernetes, Jenkins, Webpack, Ansible,
Terraform, Maven, Gradle, JSON, Yaml, XML.
Projekti nimetus: Eesti.ee eraisiku vaate jätkutööd ning
analüütika vahendite korrastamine
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Riigi Infosüsteemi Amet. Õie-Mari Aasmäe, oie-
Projekti toimumise aeg (alates-kuni): 06/2023 – 06/2024
Roll projektis: Süsteemianalüütik
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Isik osales projektis vahemikus: 10/2023 –
06/2024.
Kasutajaliidese analüüs (koostöös UI/UX
disaineritega), spetsifikatsioonide analüüs ja
dokumenteerimine (sh äriprotsesside joonised),
rakenduse andmemudeli ning andmemudeli
analüüs ja dokumenteerimine, piletite
ettevalmistamine arendajatele.
Kasutatud tehnoloogiad: PostgreSQL, Angular,
Java, REST API, Spring Boot, Tomcat, Nginx,
Oauth, ELK, Prometheus, Grafana, Redis, Docker,
Kubernetes, Jenkins, Webpack, Ansible,
Terraform, Maven, Gradle, JSON, Yaml, XML.
Projekti nimetus: Microsoft Partner Center ning Azure Portal
APIde integratsiooni tehniline analüüs
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Cloudmore OÜ, Madis Vellamäe,
Projekti toimumise aeg (alates-kuni): 08/2022 – 09/2023
Roll projektis: Analüütik
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Isik osales projektis vahemikus: 08/2022 –
09/2023.
Microsofti teenuste ja API-de liidestamise
andmevahetuse Cloudmore platvormiga analüüs ja
tehnilise spetsifikatsiooni loomine.
Kasutatud tehnoloogiad: .NET, MuleSoft ESB,
PHP, Akeneo PIM, Confluence, Postman, Jira,
REST API, Episerver, XML, MySQL, HTML
Projekti nimetus: Hansaposti e-poe arendus ja hooldus
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Finestmedia OÜ, Raivo Rang,
Projekti toimumise aeg (alates-kuni): 11/2019 – 10/2021
Roll projektis: Analüütik
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Isik osales projektis vahemikus: 11/2019 –
10/2021.
Süsteeminõuete haldus ja analüüs. Kolmandate
osapoolte liidestumise analüüs ja spetsifikatsiooni
loomine. Protsessijooniste ja BPMN diagrammide
koostamine.
Kasutatud tehnoloogiad: .NET, MuleSoft ESB,
PHP, Akeneo PIM, Confluence, Postman, Jira,
REST API, Episerver, XML, MySQL, HTML
Käesolevaga kinnitab pakkuja, et:
• spetsialist on tutvunud hangitava tööga ja andnud nõusoleku lepingu täitmisel
osalemiseks;
• spetsialisti CV-s esitatud andmed on õiged;
• spetsialist valdab kõiki asjakohaseid riigihanke alusdokumentides kirjeldatud
tehnoloogiaid ja metoodikaid ning on nõus neid lepingu täitmisel järgima;
• spetsialist vastab kõikidele esitatud nõuetele, sh keele nõudele;
• hankija võib kõiki siin esitatud andmeid igal ajal kontrollida.
Riigihange „TTJA e-teenuste keskkonna TARVIK arendus“
Viitenumber 291973
CV vorm
Spetsialisti ees- ja perekonnanimi: Kertrud Järg
Spetsialisti roll: Analüütik
Pakutud rolli eriala töökogemuse pikkus aastates: 9+ aastat
Eesti keele kõneoskus: (märkida emakeel/väga hea/hea/vajab tõlki) emakeel
Eesti keele kirjaoskus: (märkida emakeel/väga hea/hea/vajab tõlki) emakeel
Kogemus nõutud rollis
Projekti nimetus: TTJA e-teenuste platvormi jätkuarendused
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Keskkonnaministeeriumi Infotehnoloogiakeskus
Projekti toimumise aeg (alates-kuni): 08/2024 – 01/2025
Roll projektis: Analüütik
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Isik osales projektis: 08/2024 – 01/2025
Projekti skoobis oli majandustegevusteadete
migreerimine TARVIKu platvormile.
Äri- ja süsteemianalüüs, nõuete detailiseerimine,
arenduspiletite kirjeldamine, tehnilise
dokumentatsiooni koostamine, funktsionaalne
testimine, integratsioonide ja päringute
kirjeldamine.
Projekti nimetus: TTJA E-teenuste keskkonna pääsuhalduse
arendus
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Keskkonnaministeeriumi Infotehnoloogiakeskus
Projekti toimumise aeg (alates-kuni): 07/2024-01/2025
Roll projektis: Analüütik
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Isik osales projektis: 07/2024-01/2025
Projekti skoobis oli TARVIKu liidestamine
volituste süsteemiga Pääsuke ning kontaktide ja
rollide ning privileegide migratsioon MTRist
TARVIKUsse.
Äri- ja süsteemianalüüs, nõuete detailiseerimine,
arenduspiletite kirjeldamine, tehnilise
dokumentatsiooni koostamine, funktsionaalne
testimine, integratsioonide ja päringute
kirjeldamine.
Projekti nimetus: eesti.ee eraisiku ja
ettevõtja vaadete tehniline kaasajastamine
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Riigi Infosüsteemi Amet, Õie-Mari Aasmäe
Projekti toimumise aeg (alates-kuni): 05/2023-10/2024
Roll projektis: Analüütik
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Isik osales projektis: 05/2023-10/2024
Projekti skoobis oli eesti.ee portaali liidestamine
volituste süsteemiga Pääsuke ja artiklivaramuga
ning eesti.ee-s mikroesitluskihtide (MFE)
kasutuselevõtt
Süsteemide hetkeprotsesside (AS-IS)
kaardistamine, protsesside optimeerimine,
tulevikuprotsesside (TO-BE) kaardistamine, API
integratsioonide analüüs ja kirjeldamine, tehnilise
dokumentatsiooni koostamine
Projekti nimetus: CERN (Euroopa Tuumauuringute Keskus)
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
CERN
Juan Lopez Gonzalez, [email protected]
Projekti toimumise aeg (alates-kuni): 07/2022- 03/2024
Roll projektis: Analüütik
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Isik osales projektis: 01/2023-03/2024
CERNi finantssüsteemide ja EDH
finantsdokumentide analüüs
Süsteemide hetkeprotsesside (AS-IS)
kaardistamine, protsesside optimeerimine,
tulevikuprotsesside (TO-BE) kaardistamine, API
integratsioonide analüüs ja kirjeldamine, tehnilise
dokumentatsiooni koostamine
Projekti nimetus: Erimärgistatud diislikütuse õigustatud isikute
registri arendamine
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
PRIA,
kontaktisik Ivo Tamm [email protected]
Projekti toimumise aeg (alates-kuni): 01/2022 – 12/2022
Roll projektis: Analüütik
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Isik osales projektis: 01/2022 – 12/2022
Süsteemi äriprotsesside kaardistamine, nõuete
detailiseerimine, prototüüpide loomine, tehnilise
dokumentatsiooni koostamine, äri- ja
süsteemianalüüs, funktsionaalne testimine,
Andmebaasi disainimine, integratsioonide ja
päringute kirjeldused. Liidestused äriregistri,
karistusregistri jm väliste süsteemidega.
Projekti nimetus: PRIA toetuste lahenduse MATS arendus
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
PRIA,
kontaktisik Ivo Tamm [email protected]
Projekti toimumise aeg (alates-kuni): 05/2020 – 12/2021
Roll projektis: Analüütik
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Isik osales projektis: 08/2020-12/2021
Süsteemi äriprotsesside kaardistamine, nõuete
detailiseerimine, prototüüpide loomine, tehnilise
dokumentatsiooni koostamine, äri- ja
süsteemianalüüs, funktsionaalne testimine,
Andmebaasi disainimine, integratsioonide ja
päringute kirjeldused, dokumenteerimine.
Käesolevaga kinnitab pakkuja, et:
• spetsialist on tutvunud hangitava tööga ja andnud nõusoleku lepingu täitmisel
osalemiseks;
• spetsialisti CV-s esitatud andmed on õiged;
• spetsialist valdab kõiki asjakohaseid riigihanke alusdokumentides kirjeldatud
tehnoloogiaid ja metoodikaid ning on nõus neid lepingu täitmisel järgima;
• spetsialist vastab kõikidele esitatud nõuetele, sh keele nõudele;
• hankija võib kõiki siin esitatud andmeid igal ajal kontrollida.
Riigihange „TTJA e-teenuste keskkonna TARVIK arendus“
Viitenumber 291973
CV vorm
Spetsialisti ees- ja perekonnanimi: Ahti Soom
Spetsialisti roll: Arhitekt
Pakutud rolli eriala töökogemuse pikkus aastates: 6+ aastat
Eesti keele kõneoskus: emakeel
Eesti keele kirjaoskus: emakeel
Kogemus nõutud rollis
Projekti nimetus: Struktuuritoetuse registri (SFOS) arendus- ja
hooldusteenus
Tellija info (sh kontaktisiku nimi ja e-
post):
Rahandusministeeriumi Infotehnoloogiakeskus
(RmIT)
Projektijuht Magnus Lõhmus
e-post: [email protected]
Projekti toimumise aeg (alates-kuni): Juuli 2020 – juuli 2024 (tööde teostamine kestab
kuni 04.2025)
Roll projektis: Tarkvaraarhitekt
Teostatud tööde lühikirjeldus: Isik osales projektis vahemikus: 01.2023 –
04.2025
SFOS projektis tehniliste tööde teekaardi loomine
ning kokkulepitud tehniliste tööde elluviimine sh
CAS`i vahetamine Keycloak`i vastu (tehnilise
analüüs ja arendus), teekide uuendamine, uue
mooduli tehnilise platvormi loomine ning
GovSSO lahenduse kasutuselevõtmise tehniline
analüüs, POCi teostamine ja arendus. SFOS uue
maksete prognoosi mooduli arhitektuuri disain.
SFOS on arendatud Java platvormil ning kasutab
relatsioonilist andmebaasi (nii Oracle kui Postgre),
töötab rakendusserveri klastris, kasutab
mikroteenuseid ning omab liideseid väliste
infosüsteemiega (X-tee).
Tehnoloogiad: Spring, Angular, Java, Postgre,
Oracle, Tomcat, JUnit, Jira, Confluence,
WebLogic, Docker, Keycloak, Hazelcast, Gradle,
Apache HTTP server, ETCD, ConfD, Ansible,
docker swarm, Gitea, Jenkins, mikroteenused,
SiGa, X-tee (SOAP)
Projekti nimetus: Riigitöötaja iseteenindusportaali (RTIP)
arendus
Tellija info (sh kontaktisiku nimi ja e-
post):
Rahandusministeeriumi Infotehnoloogiakeskus
(RmIT)
Nimi: Hille Lepp (RTK, projektijuht)
e-post: [email protected]
Projekti toimumise aeg (alates-kuni): 01.2019 – ...
Roll projektis: Arhitekt
Teostatud tööde lühikirjeldus (vajadusel) Isik osales projektis vahemikus: 01.2019 –
12.2022
Riigiasutustes kasutatav Riigitöötaja
iseteenindusportaal (RTIP) hõlmab endas asutuste
töötajate isikuandmete, puhkuste, lähetuste,
majanduskulude, varade ja koolituste haldamist.
Tööd hõlmavad RTIP jätkuarendusi ja
hooldusteenuse osutamist sh väliseid liidestusi üle
X-tee.
Infosüsteemi lahenduste disainimine,
tehnoloogiate valik ja põhjendamine.
Kliendi tellimuste raames arenduste teostamine.
RTIP tükeldatud arhitektuuriga lahenduse
disainimine.
Tehnoloogiad: Spring, Angular, Java, Postgre,
Tomcat, JUnit, Jira, Confluence. Liidesed üle X-
tee.
Arendusmetoodikad: Agile, Scrum. Sh töötab
rakendus Weblogic klastri peal.
Projekti nimetus: Maaelu Arendamise Toetuste Süsteem (MATS)
Tellija info (sh kontaktisiku nimi ja e-
post):
Põllumajanduse Registrite ja Informatsiooni Amet
Nimi: Ivo Tamm (PRIA)
e-post: [email protected]
Projekti toimumise aeg (alates-kuni): 04.2018 – 12.2022
Roll projektis: Arhitekt
Teostatud tööde lühikirjeldus (vajadusel) Isik osales projektis vahemikus: 04.2018 –
12.2022
Tehnilise analüüsi, arhitektuuri ja arenduste
teostamine vastavalt töö skoobile. EDK -
Erimärgilise diislikütuse registri arhitektuuri
disainimine ja teostamine, sh välised liidestused
üle X-tee.
Tehnoloogiad: Spring, Angular, Java, Postgre,
Tomcat, JUnit, mikroteenused, Jira, Confluence
Arendusmetoodikad: Agile, Scrum
Käesolevaga kinnitab pakkuja, et:
• spetsialist on tutvunud hangitava tööga ja andnud nõusoleku lepingu täitmisel
osalemiseks;
• spetsialisti CV-s esitatud andmed on õiged;
• spetsialist valdab kõiki asjakohaseid riigihanke alusdokumentides kirjeldatud
tehnoloogiaid ja metoodikaid ning on nõus neid lepingu täitmisel järgima;
• spetsialist vastab kõikidele esitatud nõuetele, sh keele nõudele;
• hankija võib kõiki siin esitatud andmeid igal ajal kontrollida.
Riigihange „TTJA e-teenuste keskkonna TARVIK arendus“
Viitenumber 291973
CV vorm
Spetsialisti ees- ja perekonnanimi: Rait Raidma
Spetsialisti roll: Arhitekt
Pakutud rolli eriala töökogemuse pikkus aastates: 12+ aastat
Eesti keele kõneoskus: (märkida emakeel/väga hea/hea/vajab tõlki) emakeel
Eesti keele kirjaoskus: (märkida emakeel/väga hea/hea/vajab tõlki) emakeel
Kogemus nõutud rollis
Projekti nimetus: Keskse volituse haldamise süsteemi Pääsuke
analüüsi-, arendus- ja hooldustööd
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Riigi Infosüsteemiamet
Projekti toimumise aeg (alates-kuni): 03/2025- ....
Roll projektis: Arhitekt
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Isik osales projektis vahemikus: 03/2025- ....
Volituste haldamise süsteemi Pääsuke
edasiarendused. Front-end ja back-end arendus,
koodiülevaatus, tehnilise visiooni loomine.
Angular, Java, PostgreSQL, Prometheus,
Spring Boot, Docker, Grafana, Opensearch, x-
tee, Openapi, Jenkins, mikroteenustel põhinev
arhitektuur
Projekti nimetus: TTJA e-teenuste platvormi jätkuarendused
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Keskkonnaministeeriumi Infotehnoloogiakeskus
Projekti toimumise aeg (alates-kuni): 08/2024 – 01/2025
Roll projektis: Arhitekt
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Isik osales projektis vahemikus:08/2024- 01/2025
Majandustegevusteadete migratsioon
TARVIKusse, arendajate juhendamine,
koodiülevaatus
Java, JavaScript/Typescript, Webpack, Angular,
HTML, CSS, Spring Boot, Spring, Hibernate,
PostgreSQL, IntelliJ IDEA, Postman (API),
Docker, REST arendus ja liidestus, JSON, klaster,
XML, Nginx, mikroteenused, x-tee
Projekti nimetus: TTJA E-teenuste keskkonna pääsuhalduse
arendus
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Keskkonnaministeeriumi Infotehnoloogiakeskus
Projekti toimumise aeg (alates-kuni): 07/2024-01/2025
Roll projektis: Arhitekt
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Isik osales projektis vahemikus: 07/2024-01/2025
TARVIKU liidestus keskse volituste halduse
süsteemiga Pääsuke, kontaktide ja rollide ning
privileegide migratsioon TARVIKUsse. Tehniline
analüüs, arendus, automaattestide kirjutamine,
koodiülevaatus.
Java, JavaScript/Typescript, Angular, HTML,
CSS, SQL päringute kirjutamine, Spring Boot,
Spring, Hibernate, PostgreSQL, IntelliJ IDEA,
Postman (API), Docker, REST arendus ja
liidestus, JSON, XML, YAML, klaster, x-tee,
mikroteenused
Projekti nimetus: Statistikaameti majandusüksuste registri
arendustööd
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Rahandusministeeriumi Infotehnoloogiakeskus
Rutt Kivitare, [email protected]
Projekti toimumise aeg (alates-kuni): 02/2024 – 08/2024
Roll projektis: Arhitekt
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Isik osales projektis vahemikus: 02/2024 –
08/2024
Statistikaameti Registrite infosüsteemi arendamine
ettevõttega seotud info haldamiseks ja statistika
tegemiseks. Tarkvaraarehitektuuriga seotud tööd,
liideste teostus, automaattestide kirjutamine
(ühiktestid, integratsioonitestid end-to- end testid,
UI testid)
Java, Javascript, Postgre SQL, Angular, XML,
Json, ELK stack, Jenkins
Projekti nimetus: CERN (Euroopa Tuumauuringute Keskus)
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
CERN
Juan Lopez Gonzalez, [email protected]
Projekti toimumise aeg (alates-kuni): 07/2022- 03/2024
Roll projektis: Arhitekt
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Isik osales projektis vahemikus: 07/2022-03/2024
EDH / keskse dokumentide menetelmise süsteemi
arendused Java arendus, UI arendus, lahenduste
valideerimine, liideste teostus, admebaaside
arendus, Helmese arendustiimi juhtimine,
automaattestide kirjutamine (ühik- ja
integratsioonitestid)
Java 11, JSP, JS, Spring, Oracle DB 19c, Tomcat
(klaster), Activity, Camunda, REST, JUnit ATS
(veebipõhine): React 18, Typescript, Spring
Boot, Oracle DB 19c, Docker, Tomcat, Liquibase,
XML, JSON, Kubernetes, Grafana, Helm
Projekti nimetus: Sündmuste infosüsteemi SIS arendus
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
RMIT/RTK
Indrek Mägi [email protected]
Projekti toimumise aeg (alates-kuni): 01/2021-....
Roll projektis: arhitekt
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Isik osales projektis vahemikus: 01/2021 - ....
Tehniline eelanalüüs lahenduse teostatavusele ja
tulevase lahenduse arhitektuurse visiooni
kujundamine. POCi skoobi analüüs ja arhitektuuri
disain. ISKE klassile S2T2K2 vastavate
turvalahenduste loomine, skoobi analüüs ja
realiseerimine. Rakenduse frontendi ja backendi
arendus. Liideste teostus. Automaattestide
kirjutamine (ühiktestid, integratsioonitestid end-
to-end testid, UI testid). Arendustiimi juhtimine.
Angular 11, Javascript, Typescript 4, npm 7, Java
11, Spring Boot 2.4, Hibernate, Mapstruct,
Lombok, Liquibase, PostgreSQL 12, OpenAPI,
Tomcat (klaster), Apache HTTP Server, Docker,
Hajus arhitektuur, X-tee (rahvastikuregister,
äriregister), Gradle, XML, JSON, mikroteenustel
põhinev arhitektuur
Testid: Junit-jupiter, Selenide, Testcontainers,
Jest, Spotbugs
Tööhaldus: Git, Jira, Confluence, Jenkins
Projekti nimetus: Labori infosüsteemi LIS arendus
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Regionaal- ja põllumajandusministeerium
Märt Pakats [email protected]
Projekti toimumise aeg (alates-kuni): 08/2019-12/2021
Roll projektis: Arhitekt
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Isik osales projektis vahemikus: 08/2019-12/2021
Tehniline konsultant eelanalüüsi etapis, tehnilise
arhitektuuri analüüs ja disain, rakenduse frontendi
ja backendi arendus, turvakriitiliste lahenduste
implementeerimine, keerukamate osade arendus,
koodi ülevaatus, liideste teostus, utomaattestide
kirjutamine (ühiktestid, integratsioonitestid end-
to-end testid, UI testid), arendustiimi juhtimine.
Angular 8, Javascript, Typescript 3, npm 6, Java
11, Spring Boot 2.2, Hibernate, Mapstruct,
Lombok, PostgreSQL 12, Tomcat (klaster),
Nginx, Docker, Hajus arhitektuur, Maven, XML,
JSON ; Tööhaldus: Git, Jira, Confluence,
Bitbucket,
Projekti nimetus: Logistika dokumentide andmevahetuse ja
veokindlustuse lahenduse arendus
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Ericsson Eesti
Andrus Dureiko
Projekti toimumise aeg (alates-kuni): 02/2017 – 12.2017
Roll projektis: Arhitekt
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Isik osales projektis: 02/2017 – 12.2017
LDI eesmärk on lihtsustada ja kiirendada vedude
jaoks vajalike dokumentide saatmist ja töötlemist
erinevate osapoolt vahel vähendamaks
bürokraatiat. Samuti võimaldab LDI jälgida
pakkide liikumist üle maailma.
React, JavaScript, Spring, Java, PostgreSQL,
PostGIS, Cassandra, Geoserver, Fisheye, JQuery,
D3, React, Hajus arhitektuur, Docker, RabbitMQ
Testid: Junit Tööhaldus: Git, Jira, Confluence
Projekti nimetus: Elektrivõrgu jälgimise ja visualiseerimise
lahenduse VOYAGER arendus
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Ericsson Eesti
Andrus Dureiko
Projekti toimumise aeg (alates-kuni): 04/2014 – 02/2017
Roll projektis: Arhitekt vanemarendaja rollis
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Isik osales projektis: 02/2016 – 02/2017
Voyageri eesmärk on anda ülevaade elektrivõrgus
toimuvast. Kaardil kuvatakse mõõtepunktide ja
alajaamade asukohad. Probleemsed mõõtepunktid
ja alajaamad tuuakse esile võimaldamaks kiiret
reageerimist. Detailsemas vaates on võimalik
vaadata iga mõõtepunkti tarbimist.
VanillaJs, JavaScript, Spring, Java, PostgreSQL,
PostGIS, Geoserver, Fisheye, JQuery, D3, React,
Hajus arhitektuur Testid: Junit Tööhaldus: Git,
Jira, Confluence
Käesolevaga kinnitab pakkuja, et:
• spetsialist on tutvunud hangitava tööga ja andnud nõusoleku lepingu täitmisel
osalemiseks;
• spetsialisti CV-s esitatud andmed on õiged;
• spetsialist valdab kõiki asjakohaseid riigihanke alusdokumentides kirjeldatud
tehnoloogiaid ja metoodikaid ning on nõus neid lepingu täitmisel järgima;
• spetsialist vastab kõikidele esitatud nõuetele, sh keele nõudele;
• hankija võib kõiki siin esitatud andmeid igal ajal kontrollida.
Riigihange „TTJA e-teenuste keskkonna TARVIK arendus“
Viitenumber 291973
CV vorm
Spetsialisti ees- ja perekonnanimi: Johhanna Loomets
Spetsialisti roll: UI/UX spetsialist
Pakutud rolli eriala töökogemuse pikkus aastates: üle 8 aasta
Eesti keele kõneoskus: emakeel
Eesti keele kirjaoskus: emakeel
Kogemus nõutud rollis
Projekti nimetus: Haridussilma veebirakenduse arendamine 2023
(viitenumber 260559)
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Haridus- ja Teadusministeerium
Kairit Peekman
Projekti toimumise aeg (alates-kuni): 09.2023 – tänaseni
Roll projektis: UX/UI disainer
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Johhanna osales projektis 09.2024 - tänaseni
Eesti hariduse teabevärav Haridussilm koondab
kokku alus-, üld-, kutse- ja kõrghariduse, keele- ja
noortevaldkonna andmeid ning kajastab
elukestvas õppes osalemise ja tööturule sisenemise
edukusega seotud näitajaid. Samuti annab
Haridussilm ülevaate haridusstrateegia sihtidest
ning nende poole liikumisest.
Spetsialisti tööd: Kasutajaliidese disain,
prototüüpimine.
Projektis teostatud tööd: Kasutatavuse testimine,
intervjuud, raporti kirjutamine, esitlus, uuringu
läbiviimine, kasutajaliidese disain,
prototüüpimine, projektijuhtimine, back-end
arendus, front-end arendus.
Spetsialisti töövahendid: Figma
Projekti nimetus: Eesti.ee platvormi kasutajakogemuse analüüsi
ja kasutajaliidese visualiseerimise tööd
Viitenumber 233288 (seotud raamhankega nr
220412)
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Riigi Infosüsteemi Amet
Õie-Mari Aasmäe, [email protected]
Projekti toimumise aeg (alates-kuni): 06.2021 - 06.2023
Roll projektis: UI/UX disainer
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Johhanna osales projektis 07.2021 - 06.2023
Käesoleva lepingu raames loodi ettevõtjate ja
eraisiku personaliseeritud töölaua prototüüp: lehe
struktuur ja navigatsioon, enam teostatud e-
päringute alusel lemmikteenuste ja/või artiklite
avalehe vaade, meeleoluillustratsioonid jms.
Spetsialisti teostatud tööd: Prototüüpimine,
kasutajaliidese disain, kasutajatestide loomine ja
läbiviimine.
Projektis teostatud tööd: Kasutajaliidese disain,
kasutajatestide loomine ja läbiviimine,
prototüüpimine, intervjuud, koosloome töötoad,
illustreerimine, persoonade loomine,
benchmarking, ärianalüüs, kasutajateekonna
loomine, küsimustik, raporti kirjutamine,
navigatsiooni loomine, navigatsiooni testimine,
andmemudeli loomine.
Spetsialisti töövahendid: Figma
Projekti nimetus: Tööelu Infosüsteemi (TEIS) arendus
(2020a hange nr 223406)
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Tervise ja Heaolu Infosüsteemide Keskus
Rainer Rohtla
Projekti toimumise aeg (alates-kuni): 10.2020 – 08.2024
Roll projektis: UX/UI disainer
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Johhanna osales projektis 04.2022 - 08.2024.
Projekti eesmärgiks oli uue Tööinspektsiooni
infosüsteemi edasiarendus, sh Riskianalüüsi
funktsionaalsuse automatiseerimise ja
digitaliseerimine ning vastava tarkvaraplatvormi
analüüs, disain ning arendus.
Spetsialisti teostatud tööd: Kasutajaliidese
disain, ligipääsetavuse hindamine,
prototüüpimine, kasutajatestide loomine ja
läbiviimine.
Projektis teostatud tööd: Front-end arendus,
kasutajaliidese disain, graafiline disain,
ligipääsetavuse hindamine, ärianalüüs,
süsteemianalüüs, projektijuhtimine,
süsteemiarhitektuur, back-end arendus, arenduse
testimine (QA), kasutajatestide loomine ja
läbiviimine, prototüüpimine.
Spetsialisti töövahendid: Figma, Axure RP, Jira,
Confluence
Projekti nimetus: STAR arendus: BronSys (viitenumber 264459)
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Tervise ja Heaolu Infosüsteemide Keskus
Katre Pukk, [email protected]
Projekti toimumise aeg (alates-kuni): 06.2022 - 07.2023
Roll projektis: UX/UI disainer
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Johhanna osales projektis 08.2022 - 05.2023
Sotsiaalteenuste andmeregistri
broneeringusüsteemi täiendamine ja
edasiarendamine, et vähendada sotsiaaltöötajatel
dokumenteerimisele ja korralduslikule poolele
kuluvat aega. Funktsionaalsuse disain, analüüs ja
arendus.
Spetsialisti teostatud tööd: Kasutajaliidese
disain, UI ülevaatus, kasutajatestide loomine ja
läbiviimine, prototüüpimine
Projektis teostatud tööd:
Ärianalüüs, mahuhinnangute
koostamine, arenduse piletid, andmemudeli
loomine, kasutajaliidese disain, prototüüpimine,
UI ülevaatus, kasutajatestide loomine ja
läbiviimine, ligipääsetavuse hindamine, front-end
arendus.
Spetsialisti töövahendid: Figma
Projekti nimetus: STAR: Standardtoetuste ja üldkomponentide
tööd (viitenumber 264459)
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Tervise ja Heaolu Infosüsteemide Keskus
Katre Pukk
Projekti toimumise aeg (alates-kuni): 06.2023 - 04.2024
Roll projektis: UX/UI disainer
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Johhanna osales projektis 06.2023 - 04.2024.
STAR2-te riiklike ja KOV poolt määratavate
lihttoetuste taotlemise ja määramise
funktsionaalsuse loomine; Kasutajatele mugava
keskkonna loomine, et abivajajatele saaks toetusi
määrata vaid STAR2 kasutajaliidest kasutades.
Spetsialisti teostatud tööd: Kasutajaliidese
disain, kasutajatestide loomine ja läbiviimine
Projektis teostatud tööd: Back-end
arendus, front-end arendus, koosloome
töötoad, kasutajatestide loomine ja
läbiviimine, projektijuhtimine, kasutajaliidese
disain, süsteemianalüüs, arenduse piletid, AS-IS
olukorra kaardistus, andmemudeli loomine.
Spetsialisti töövahendid: Figma
Projekti nimetus: Sisehindamise ärianalüüs (viide 278694)
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Tallinna Tehnikaülikool
Lehor Meius, [email protected]
Projekti toimumise aeg (alates-kuni): 05.2024 - 10.2024
Roll projektis: UX/UI disainer
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Johhanna osales projektis 08.2024 - 09.2024
TalTechi sisehindamise süsteemi eesmärk on
arendada tõhus ja kasutajasõbralik töövahend, mis
võimaldab regulaarset ja süsteemset
õppeprogrammide sisehindamist. See töövahend
toetab programmijuhte oma juhitava
õppeprogrammi analüüsimisel, kasutades
kokkulepitud näitajaid ja lähtudes tasemeõppe
programmide haldamise korrast ning
eneseanalüüsivormist. Projekti eesmärk oli viia
läbi analüüs sellise süsteemi kontseptsiooni
loomiseks, kirjeldada protsessid ja prototüüpida
esialgne lahendus.
Spetsialisti teostatud tööd: Kasutajatestide
loomine ja läbiviimine, prototüüpimine.
Projektis teostatud tööd: Nõuete analüüs,
protsesside kaardistamine, AS-IS olukorra
kaardistus, intervjuud, projektijuhtimine,
kasutajatestide loomine ja läbiviimine,
prototüüpimine.
Spetsialisti töövahendid: Figma
Projekti nimetus: Prokuratuurile sisuloome ja kasutajamugavuse
teenused
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Prokuratuur
Kairi Küngas
Projekti toimumise aeg (alates-kuni): 04.2023 - 08.2023
Roll projektis: UX/UI disainer
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Johhanna osales projektis 04.2023 - 08.2023.
Valitsusportaalis infosisestus parimate SEO
praktikate järgi ja kasutajamugavuse nõustamine
ning testimine.
Spetsialisti teostatud tööd: Kasutajatestide
loomine ja läbiviimine, ligipääsetavuse hindamine
ning kasutajamugavuse osas nõustamine.
Projektis teostatud tööd: Ligipääsetavuse
hindamine, kasutajatestide loomine ja
läbiviimine, sisuloome, kasutajamugavuse osas
nõustamine
Spetsialisti töövahendid: N/A
Projekti nimetus: Välisinvesteeringute usaldusväärsuse
hindamise mooduli ärianalüüsi teostamine
(viide 257367)
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Majandus- ja Kommunikatsiooniministeerium
Verner Eiber
Projekti toimumise aeg (alates-kuni): 02.2023 - 08.2023
Roll projektis: UX/UI disainer
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Johhanna osales projektis 02.2023 - 07.2023
Välisinvesteeringute usaldusväärsuse hindamise
menetlusprotsessi kirjeldamine. Loodava
infosüsteemi ärinõuete, kasutajarollide,
andmekoosseisude ja kontseptuaalse arhitektuuri
kirjeldamine ning prototüübi loomine ja selle
testimine.
Spetsialisti teostatud tööd: Prototüübi loomine.
kasutajatestide loomine ja läbiviimine. Persoonade
loomine.
Projektis teostatud tööd: Kasutuslood, loogiline
andmemudel, nõuete kirjeldamine, nõuete analüüs,
protsesside kaardistamine, persoonade loomine,
prototüüpimine, kasutajatestide loomine ja
läbiviimine.
Spetsialisti töövahendid: Figma, Miro
Projekti nimetus: Tööelu Infosüsteemi (TEIS) arendus (2018,
viide 200150)
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Tervise ja Heaolu Infosüsteemide Keskus
Rainer Rohtla
Projekti toimumise aeg (alates-kuni): 12.2019 - 11.2020
Roll projektis: UX/UI disainer
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Johhanna osales projektis 12.2019 - 11.2020
Projekti eesmärgiks oli uue Tööinspektsiooni
infosüsteemi loomine, täpsemalt I etapi, ehk
järelevalvemenetluste automatiseerimise ja
digitaliseerimine ning vastava tarkvaraplatvormi
analüüs, disain ning arendus.
Spetsialisti teostatud tööd: kasutajaliidese disain,
prototüüpimine.
Projektis teostatud tööd: Front-end arendus,
süsteemianalüüs, ärianalüüs, kasutajaliidese
disain, prototüüpimine, projektijuhtimine,
graafiline disain.
Spetsialisti töövahendid: Figma, Axure RP
Projekti nimetus: SKAIS2 UX/UI etapp 3 (viide 188661)
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Tervise ja Heaolu Infosüsteemide Keskus
Tuuli Pentjärv
Projekti toimumise aeg (alates-kuni): 10.2020 - 06.2021
Roll projektis: UX/UI disainer
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Johhanna osales projektis 02.2021 - 05.2021
Vanemahüvitise ja pensionide teenuste
disainimine ning prototüüpimine,
Sotsiaalkindlustusameti iseteeninduse
kontseptsiooni loomine.
Spetsialisti teostatud tööd: Kasutajatestide
loomine ja läbiviimine, kasutajaliidese disain,
prototüüpimine
Projektis teostatud tööd: Kasutajateekonna
loomine, persoonade loomine, intervjuud,
teenusedisain, kasutajatestide loomine ja
läbiviimine, kasutajaliidese disain,
prototüüpimine, navigatsiooni loomine,
illustreerimine, ligipääsetavuse hindamine,
projektijuhtimine.
Spetsialisti töövahendid: Figma
Projekti nimetus: Haridusportaali arendus (2018, viide 192377)
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Haridus- ja Teadusministeerium
Erkki Jakobson
Projekti toimumise aeg (alates-kuni): 02.2018 - 08.2020
Roll projektis: UX/UI disainer
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Johhanna osales projektis 03.2019 - 06.2019
Projekti sisuks on Haridusportaali (edu.ee)
loomine ja edasiarendamine. Tööd sisaldavad
analüüsi, disaini, arendamist, hooldamist, ning
tellijale tehnilise toe pakkumist infosüsteemi
hooldamiseks ning edasiarendamiseks.
Spetsialisti teostatud tööd: Kasutajatestide
loomine ja läbiviimine, kasutajaliidese disain,
prototüüpimine
Projektis teostatud tööd: front-end arendus,
arenduse testimine (QA), automaattestimine,
ligipääsetavuse hindamine, back-end arendus,
projektijuhtimine, ärianalüüs, süsteemianalüüs,
kasutajaliidese disain, prototüüpimine,
kasutajatestide loomine ja läbiviimine,
nõustamine.
Spetsialisti töövahendid: Confluence, Jira,
Zeplin, Figma
Projekti nimetus: Astangu Kutserehabilitatsiooni Keskuse
veebilehe astangu.ee arendus (viide 201015)
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Tervise ja Heaolu Infosüsteemide Keskus
Helen Simisker, [email protected]
Projekti toimumise aeg (alates-kuni): 10.2018 - 12.2019
Roll projektis: UX/UI disainer
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Johhanna osales projektis 10.2018 - 04.2019
Astangu Kutserehabilitatsiooni Keskuse uue
kodulehekülje loomisega seonduvad tööd.
Spetsialisti teostatud tööd: kasutajaliidese disain,
prototüüpimine, kasutajatestide loomine ja
läbiviimine.
Projektis teostatud tööd: Ligipääsetavuse
hindamine, back-end arendus, front-end
arendus, arenduse testimine
(QA), projektijuhtimine, kasutajaliidese
disain, prototüüpimine, kasutajatestide loomine ja
läbiviimine.
Spetsialisti töövahendid: Axure RP, Figma
Projekti nimetus: Tehik.ee veebi loomine (viide 222594)
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Tervise ja Heaolu Infosüsteemide Keskus
Helen Simisker
Projekti toimumise aeg (alates-kuni): 06.2020 - 01.2021
Roll projektis: UX/UI disainer
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Johhanna osales projektis 07.2020 - 11.2020
TEHIKu uue kodulehe loomisega seotud tööd, sh
disain, analüüs, arendus, testimine
Spetsialisti teostatud tööd: kasutajaliidese disain.
Projektis teostatud tööd: arenduse piletid,
projektijuhtimine, kasutajaliidese disain, back-end
arendus, ligipääsetavuse hindamine, arenduse
testimine (QA), küsimustik, persoonade loomine,
kasutatavuse testimine, navigatsiooni loomine,
intervjuud, front-end arendus, konsultatsioon,
nõustamine.
Spetsialisti töövahendid: Figma, Zeplin
Käesolevaga kinnitab pakkuja, et:
• spetsialist on tutvunud hangitava tööga ja andnud nõusoleku lepingu täitmisel
osalemiseks;
• spetsialisti CV-s esitatud andmed on õiged;
• spetsialist valdab kõiki asjakohaseid riigihanke alusdokumentides kirjeldatud
tehnoloogiaid ja metoodikaid ning on nõus neid lepingu täitmisel järgima;
• spetsialist vastab kõikidele esitatud nõuetele, sh keele nõudele;
• hankija võib kõiki siin esitatud andmeid igal ajal kontrollida.
Riigihange „TTJA e-teenuste keskkonna TARVIK arendus“
Viitenumber 291973
CV vorm
Spetsialisti ees- ja perekonnanimi: Kaire Tekku
Spetsialisti roll: UI/UX spetsialist
Pakutud rolli eriala töökogemuse pikkus aastates: üle 10 aasta
Eesti keele kõneoskus: emakeel
Eesti keele kirjaoskus: emakeel
Kogemus nõutud rollis
Projekti nimetus: Elukestva õppe infosüsteemi arendus (viide
276953)
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Tallinna Tehnikaülikool
Hanno Tomberg
Projekti toimumise aeg (alates-kuni): 07.2024 – tänaseni
Roll projektis: UX/UI disainer
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Kaire osales projektis 08.2024 – tänaseni.
Tegemist on täiendusõppe infosüsteemiga
Taltech-ile ja Tallinna Ülikoolile, mis on
täiendusõppe ettevalmistamise, läbiviimise
korraldamise ja tagasisidestamise haldamiseks.
Täienduskoolituse infosüsteemi ülesanne on
võimaldada täiendusõppe info edastamist,
vahendamist, töötlemist, kättesaadavust,
säilitamist, samuti edastada liidestuse kaudu
EHISesse täiendusõppe õppekavasid (mikrokraadi
õk) ning EHISe E-Tunnistuste registrisse osalejate
lõpudokumente (e-kujul).
Spetsialisti teostatud tööd: Kasutajaliidese
disain, kasutajatestide loomine,
prototüüpimine.
Projektis teostatud tööd: Projektijuhtimine,
automaattestimine, testkeskkonna seadistamine,
arenduse testimine (QA), funktsionaalne
testimine, süsteemiarhitektuur, back-end arendus,
front-end arendus, code review, rätseparendus,
dokumenteerimine, arenduse piletid, kasutuslood,
nõuete analüüs, nõuete kirjeldamine, protsesside
kaardistamine, süsteemianalüüs, user storyde
loomine, ärianalüüs, koosloome töötoad,
intervjuud, kasutajateekonna loomine,
navigatsiooni loomine, kasutajaliidese disain,
prototüüpimine, kasutajatestide loomine ja
läbiviimine.
Spetsialisti töövahendid: Figma
Projekti nimetus: SEB Panga e-lahenduste UX/UI disain,
teenusedisain
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
AS SEB Pank
Madis Rist
Projekti toimumise aeg (alates-kuni): 05.2023 – tänaseni
Roll projektis: UX/UI disainer
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Kaire osales projektis 10.2024 - 03.2025.
SEB avalike ja sisemiste digitaalsete süsteemide
kasutajauuringud, analüüs, prototüüpimine,
testimine ja disain. Luuakse nii klikitavaid
prototüüpe kui ka lõppviimistlusega kujundusi.
Spetsialisti teostatud tööd: Prototüüpimine,
kasutajaliidese disain, kasutajatestide loomine ja
läbiviimine, ligipääsetavuse hindamine.
Projektis teostatud tööd: User storyde loomine,
teenusedisain, koosloome töötoad, kasutajatestide
loomine ja läbiviimine, kasutajateekonna loomine,
kasutajakeskne strateegiline disain, intervjuud,
ideatsioon, esitlus, demode ettevalmistus ja
esitlus, customer journey mapping, benchmarking,
AS-IS olukorra kaardistus, protsesside
kaardistamine, prototüüpimine, kasutajaliidese
disain, ligipääsetavuse hindamine.
Spetsialisti töövahendid: Figma
Projekti nimetus: Telia kasutajaliideste UX/UI disain
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Telia Eesti AS
Teet Liske, [email protected]
Alar Lutsar, [email protected]
Projekti toimumise aeg (alates-kuni): 08.2012 - tänaseni
Roll projektis: UX/UI disainer
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Kaire osales projektis 09.2018 - 01.2021
Erinevate Telia süsteemide UX/UI disainitööde
teostamine.
Spetsialisti teostatud tööd: Kasutajaliidese
disain, graafiline disain, kasutajatestide loomine ja
läbiviimine, küsimustik, koosloome töötoad,
ligipääsetavuse hindamine, teenusedisain,
visandamine, prototüüpimine.
Projektis teostatud tööd: Prototüüpimine,
kasutajatestide loomine ja läbiviimine, intervjuud,
küsimustik, protsesside kaardistamine, jutusein,
koosloome töötoad, mõõdikute loomine,
teenusedisain, kasutajaliidese disain, graafiline
disain, persoonade loomine, ideatsioon,
olemasoleva UIG täiendamine, visandamine,
ligipääsetavuse hindamine, motion-design,
animeerimine.
Spetsialisti töövahendid: Sketch, Avocode,
Zeplin, Figma, Axure RP
Projekti nimetus: Telema eFlow toote UX/UI disain ja FE
arendus
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Telema AS
Pille Anderson
Projekti toimumise aeg (alates-kuni): 06.2020 - 08.2024
Roll projektis: UX/UI disainer, juhtivdisainer
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Kaire osales projektis 06.2020 - 01.2024.
UX/UI disain Telema eFlow tootele. eFlow on
töövahend, mille abil saab arveid elektroonselt
kinnitada ja kulusid jaotada.
Spetsialisti teostatud tööd: UI ülevaatus,
prototüüpimine, kasutajatestide loomine ja
läbiviimine, kasutajaliidese disain, intervjuud,
graafiline disain, persoonade loomine, UIG
loomine.
Projektis teostatud tööd: Front-end arendus,
prototüüpimine, kasutajaliidese disain, UIG
loomine, projektijuhtimine, kasutajatestide
loomine ja läbiviimine, intervjuud, graafiline
disain, persoonade loomine, UI ülevaatus
Spetsialisti töövahendid: Jira, Axure RP, Figma
Projekti nimetus: HKSOS - logistiku disainitööd (viide 238394)
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
SMIT
Vallo Pensa, [email protected]
Häirekeskus
Liisa Soosuu, [email protected]
Projekti toimumise aeg (alates-kuni): 09.2022 - 05.2023
Roll projektis: UX/UI disainer
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Kaire osales projektis 08.2022 - 03.2023.
Töö eesmärgiks oli luua logistiku töövoogude
prototüüp ning kasutajaliidese
vaated/komponendid, mida saab sisendiks
kasutada arendustööde teostamisel.
Spetsialisti teostatud tööd: Prototüüpimine,
kasutajatestide loomine ja läbiviimine, intervjuud,
protsesside kaardistamine, kasutajaliidese disain,
kujunduskontseptsiooni loomine.
Projektis teostatud tööd: Elav stiiliraamat, UX
ekspertanalüüs, kasutajaliidese disain,
teenusplaan, vaatlus, kujunduskontseptsiooni
loomine, jutusein, AS-IS olukorra kaardistus,
mahuhinnangute koostamine, koosloome töötoad,
raporti kirjutamine, prototüüpimine,
projektijuhtimine, kasutajatestide loomine ja
läbiviimine, kasutajateekonna loomine, intervjuud,
dokumenteerimine, protsesside kaardistamine.
Spetsialisti töövahendid: Figma
Projekti nimetus: Päästekorraldaja töövoogude teenusedisaini
(HKSOS), kasutajakogemuse disaini ja
kasutajaliidese disaini tööd (viide 238394)
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
SMIT
Vallo Pensa, [email protected]
Häirekeskus
Liisa Soosuu, [email protected]
Projekti toimumise aeg (alates-kuni): 12.2021 - 09.2022
Roll projektis: UX disainer
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Kaire osales projektis 12.2021 - 09.2022.
Spetsialisti teostatud tööd: Prototüüpimine,
kasutajatestide loomine ja läbiviimine.
Projektis teostatud tööd: Kasutatavuse analüüs,
kujunduskontseptsiooni loomine, infoarhitektuur,
süntees, demode ettevalmistus ja esitlus,
ideatsioon, visandamine, CVI loomine,
teenusedisain, UX ekspertanalüüs, intervjuud,
prototüüpimine, kommunikatsioon, elav
stiiliraamat, kasutajatestide loomine ja
läbiviimine, kasutajaliidese disain, teenusplaan,
vaatlus, jutusein, AS-IS olukorra kaardistus,
dokumenteerimine, raporti kirjutamine,
kasutajateekonna loomine, mahuhinnangute
koostamine, koosloome töötoad.
Spetsialisti töövahendid: Figma
Projekti nimetus: Telema PDS keskkonna UX/UI tööd
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Telema AS
Pille Anderson,
Projekti toimumise aeg (alates-kuni): 04.2020 - 01.2023
Roll projektis: UX/UI disainer
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Kaire osales projektis 11.2020 - 01.2023
Telema PDS (Product Data Sync) ehk
tooteandmete halduskeskkond on teenus, mis
võimaldab hulgimüüjatel, distribuutoritel või
tootjatel kõiki oma tooteandmeid lihtsalt ja
efektiivselt luua, hoida ja administreerida ühes
andmebaasis.
Selline lahendus tagab tooteandmete täpsuse ning
vastavuse nõuetele, sest andmeid ei kopeerita
erinevate baaside ja tabelite vahel.
Kasutajaõigused ning info jagamine läbi turvaliste
kanalite kaitseb andmeid kogemata muutmise või
väärkasutuse eest.
Spetsialisti teostatud tööd: Prototüüpimine,
kasutajaliidese disain, UIG loomine, UI ülevaatus.
Projektis teostatud tööd: UI ülevaatus,
kasutajaliidese disain, UIG loomine,
prototüüpimine, projektijuhtimine, front-end
arendus.
Spetsialisti töövahendid: Axure RP, Figma, Jira
Projekti nimetus: Sündmusteenuste analüüs (viide 202449)
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Majandus- ja Kommunikatsiooniministeerium
Helena Lepp
Projekti toimumise aeg (alates-kuni): 02.2019 - 06.2020
Roll projektis: UX/UI disainer
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Kaire osales projektis 12.2019 - 05.2020.
Töö sisuks oli sündmusteenuste analüüs asutuste,
valdkondade, valitsemistasandite ja sektorite
üleselt, tekitades tervikpildi teenuse tarbijale tema
kohustustest ja õigustest kaardistatud sündmuste
puhul. Analüüsiti 15 elusündmust, nendest 5 puhul
kaardistati tulevikuvaade.
Spetsialisti teostatud tööd: Kasutajatestide
loomine ja läbiviimine, kasutajateekonna loomine,
prototüüpimine.
Projektis teostatud tööd: Animeerimine,
prototüüpimine, kasutajaliidese disain,
illustreerimine, ärianalüüs, süsteemianalüüs,
kasutajatestide loomine ja läbiviimine,
kasutajateekonna loomine, intervjuud, protsesside
kaardistamine, koosloome töötoad, teenusedisain,
süsteemiarhitektuur, persoonade loomine,
mõõdikute loomine, mõjuanalüüs
Projekti nimetus: SKAIS 2 abivahendite ja ITVH disain (188661)
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Tervise ja Heaolu Infosüsteemide Keskus
Tuuli Pentjärv
Projekti toimumise aeg (alates-kuni): 11.2019 - 11.2020
Roll projektis: UX/UI disainer
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Kaire osales projektis 05.2019 - 11.2020.
Sotsiaalkindlustusameti iseteeninduse teenuste
ning kasutajakogemuse disain.
Spetsialisti teostatud tööd: Elav stiiliraamat,
ligipääsetavuse hindamine, intervjuud,
prototüüpimine, kasutajaliidese disain,
kasutajatestide loomine ja läbiviimine.
Projektis teostatud tööd: Navigatsiooni loomine,
kasutajaliidese disain, teenusedisain,
kasutajatestide loomine ja läbiviimine,
illustreerimine, transkribeerimine, intervjuud,
prototüüpimine, ligipääsetavuse hindamine, elav
stiiliraamat, front-end arendus, mahuhinnangute
koostamine, projektijuhtimine.
Spetsialisti töövahendid: Jira, Figma, Axure RP,
Confluence
Projekti nimetus: Sotsiaalkindlustusameti infosüsteemi UX/UI
disain (188661)
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Tervise ja Heaolu Infosüsteemide Keskus
Tuuli Pentjärv
Projekti toimumise aeg (alates-kuni): 04.2018 – 08.2019
Roll projektis: UX/UI disainer
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Kaire osales projektis 05.2018 - 08.2018
Sotsiaalkindlustusameti iseteeninduse teenuste
ning kasutajakogemuse disain
Spetsialisti teostatud tööd: Navigatsiooni
testimine, navigatsiooni loomine, prototüüpimine,
kasutajaliidese disain, persoonade loomine,
kasutajateekonna loomine, intervjuud.
Projektis teostatud tööd: Kasutajaliidese disain,
prototüüpimine, navigatsiooni loomine,
navigatsiooni testimine, intervjuud,
kasutajateekonna loomine, persoonade loomine,
projektijuhtimine.
Spetsialisti töövahendid: Jira, Figma, Axure RP,
Confluence
Projekti nimetus: City24.ee kinnisvaraportaali UX/UI
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Kinnisvaraportaal OÜ
Karin Noppel-Kokerov
Projekti toimumise aeg (alates-kuni): 06.2012 – 02.2023
Roll projektis: UX/UI disainer
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Kaire osales projektis 08.2017 - 05.2018.
City24 kinnisvaraportaali kasutajaliidese tööd
Spetsialisti teostatud tööd: Prototüüpimine,
kasutajaliidese disain.
Projektis teostatud tööd: Kasutajaliidese disain,
konsultatsioon, gamification, esitlus, elav
stiiliraamat, ideatsioon, graafiline disain,
olemasoleva UIG täiendamine, prototüüpimine,
visandamine, kampaaniate disain, front-end
arendus, projektijuhtimine, mentordamine,
sisuloome, motion-design, animeerimine, e-kirja
põhja arendus, bränding, persoonade loomine
Spetsialisti töövahendid: Sketch
Käesolevaga kinnitab pakkuja, et:
• spetsialist on tutvunud hangitava tööga ja andnud nõusoleku lepingu täitmisel
osalemiseks;
• spetsialisti CV-s esitatud andmed on õiged;
• spetsialist valdab kõiki asjakohaseid riigihanke alusdokumentides kirjeldatud
tehnoloogiaid ja metoodikaid ning on nõus neid lepingu täitmisel järgima;
• spetsialist vastab kõikidele esitatud nõuetele, sh keele nõudele;
• hankija võib kõiki siin esitatud andmeid igal ajal kontrollida.
Riigihange „TTJA e-teenuste keskkonna TARVIK arendus“
Viitenumber 291973
CV vorm
Spetsialisti ees- ja perekonnanimi: Mirko Saar
Spetsialisti roll: DevOps insener
Pakutud rolli eriala töökogemuse pikkus aastates: üle 12 aasta
Eesti keele kõneoskus: emakeel
Eesti keele kirjaoskus: emakeel
Kogemus nõutud rollis
Projekti nimetus: Piletilevi uue piletimüügisüsteemi analüüs,
arendus ja hooldus
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Piletilevi Group AS
Nimi: Jaanus Beilmann
e-post: [email protected]
Projekti toimumise aeg (alates-kuni): 08/2010-...
Roll projektis: Devops insener
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Osales projektis: 11/2022-...
Helmes pilve füüsiliste seadmete haldus ja
planeerimine. Linux süsteemide tugi. Piletilevi
serverite ja andmebaaside kolimine, haldus,
uuendamine, monitoorimine. Linux serverite ja
andmebaaside haldus, tarkvara paigalduse
(pipeline’ide) automatiseerimine, monitoorimine.
PostgreSQL, Patroni, etcd, Progress, Haproxy, Nginx,
Apache httpd, RabbitMQ, Elasticsearch, Fluentd(log
aggregation), Kibana, Docker, NFS, AWS, Jenkins
(CI/CD), Grafana(Graphs), Prometheus(timeseries
database) Redis (in memory cache), Linux,
PostgreSQL, Haproxy, SaltStack
Projekti nimetus: Tallinna välisprojektide infosüsteemi arendus-,
hooldus- ja majutusteenus
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Tallinna Strateegiakeskus
Riigihanke viitenumber: 246291
Mari Roots
Projekti toimumise aeg (alates-kuni): 04/2022-…
Roll projektis: Devops Insener
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Osales projektis: 11/2022-...
Linux serverite ja andmebaasi haldus, rakenduse ja
serveri monitoorimine, arenduse pipeline seadistamise
abistamine (Jenkins -> Gitea Actions)
MariaDB, Apache Httpd, php, Gitea, Gitea Actions
(CI/CD), SaltStack
Projekti nimetus: Tallinna välireklaami- ja teabekandjate ning
reklaamimaksu järelevalveliste menetluste
andmekogu arendus-, majutus- ja
hooldusteenus
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Tallinna Strateegiakeskus
Riigihanke viitenumber: 240692
Mari Roots
Projekti toimumise aeg (alates-kuni): 09.2021-…
Roll projektis: Devops Insener
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Osales projektis: 11/2022-...
Linux serverite ja andmebaasi haldus, rakenduse ja
serveri monitoorimine, arenduse pipeline seadistamise
abistamine (Jenkins -> Gitea Actions)
PostgreSQL, Apache Httpd, php, Gitea, Gitea Actions
(CI/CD), SaltStack
Projekti nimetus: Tallinna projekti- ja tegevustoetuste
infosüsteemi majutus-, hooldus- ja
arendusteenus
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Tallinna Strateegiakeskus
Riigihanke viitenumber: 246959
Mari Roots
Projekti toimumise aeg (alates-kuni): 04/2022-…
Roll projektis: Devops Insener
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Osales projektis: 11/2022-...
Linux serverite ja andmebaasi haldus, rakenduse ja
serveri monitoorimine, arenduse pipeline seadistamise
abistamine (Jenkins -> Gitea Actions)
MariaDB, Apache Httpd, php, Gitea, Gitea
Actions(CI/CD), SaltStack
Projekti nimetus: Credit Life portaali arendus, haldus ja hooldus
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Axell Claims
Frits Keij
Projekti toimumise aeg (alates-kuni): 11.2018-…
Roll projektis: DevOps insener
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Osales projektis: 11/2022-...
Linux süsteemide ja andmebaasi haldus ning
backup saidi loomine Helmese Infra peale.
Rakenduste ja serverite monitorimine.
Kasutatud tarkvarad: Nginx, Gitlab CI/CD, sftp
(server), Docker, Minio(Object Storage),
PostgreSQL, Rabbitmq, SaltStack
Projekti nimetus: Helmes AS sisesüsteemide haldus
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Toomas Saar
Roll projektis: DevOps insener
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Alustas projektis: 11/2022-...
Linux süsteemide ja andmebaasi haldus. serverite
seadistamine vastavalt sisekliendi soovidele.
Füüsilise serverite haldus.
Kasutatud tehnoloogiad: Docker, Gitea, Gitea
Actions CI/CD, SpringBoot ConfigServer,
Eureka, PostgreSQL, Mariadb, PHP, Bitbucket,
Jira, Confluence, Nutanix(Virtualization),
Hycu(backup), Proxmox, Cloudflare, Bind,
PowerDNS, Zabbix, Postfix, Gitea, Xtee,
Projekt: Itella Logistika süsteemide haldus
Kontakt: Lauri Laksberg
+3725023644
Projekti Toimumise aeg (alates-kuni): 05.2018-04.2023
Roll: Vanem süsteemi administraator
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Isik osales projektis: 05.2018-04.2023
Linux süsteemide haldus, rakenduste paigalduse
automaatika, monitoringu loomine,
Kasutatud tarkvarad: AWS: EC2, CloudFormation,
CloudWatch, RDS, Elasticache, ECS (Elastic
Conteiner Services), Grafana, Prometheus,
Jenkins(CI/CD), Ansible, Lambda, VPC, IAM,
S3, SNS, SES, Amazon MQ, CloudFront, Sceptre,
AWS Fargate
Projekt: Eesti Posti süsteemide haldus
Kontakt: Toomas Saar
+3725163125
Projekti Toimumise aeg (alates-kuni): 09.2012-04.2018
Roll: Rakendusadministraator - süsteemiadministraator
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Isik osales projektis: 09.2012-04.2018
Linux süsteemide haldus,
Kasutatud tarkvarad: Tomcat, Docker,
Kubernetes, RabbitMQ, Apache Httpd, HAProxy,
Aurea Sonic ESB, Big IP LTM, New Relic,
Grafana, Cacti, Nagios, Prometheus, Python,
OracleSQL-
Käesolevaga kinnitab pakkuja, et:
• spetsialist on tutvunud hangitava tööga ja andnud nõusoleku lepingu täitmisel
osalemiseks;
• spetsialisti CV-s esitatud andmed on õiged;
• spetsialist valdab kõiki asjakohaseid riigihanke alusdokumentides kirjeldatud
tehnoloogiaid ja metoodikaid ning on nõus neid lepingu täitmisel järgima;
• spetsialist vastab kõikidele esitatud nõuetele, sh keele nõudele;
• hankija võib kõiki siin esitatud andmeid igal ajal kontrollida.
Riigihange „TTJA e-teenuste keskkonna TARVIK arendus“
Viitenumber 291973
CV vorm
Spetsialisti ees- ja perekonnanimi: Sten-Silver Ots
Spetsialisti roll: Devops Insener
Pakutud rolli eriala töökogemuse pikkus aastates: 9+ aastat
Eesti keele kõneoskus: emakeel
Eesti keele kirjaoskus: emakeel
Kogemus nõutud rollis
Projekti nimetus: Tavid AS infrastruktuuri planeerimine ja
ülalhoidmine
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Tavid AS
Kontaktisik: Indrek Kalluste
e-mail: [email protected]
Projekti toimumise aeg (alates-kuni): 05/2022-…
Roll projektis: Devops insener
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Osales projektis: 05/2022-...
Linuxi (Ubuntu) administreerimine ja
konfiguratsioonihalduse automatiseerimine
ansible ja AWX’ga, Kubernetese klastrite
ehitamine, haldus ja rakenduste deploymine,
AWS ressursside ja on premise vcenter
infrastruktuurihaldus terraformiga gitops
põhimõtetel. Intune haldus, tuumikvõrgu
haldus, BGP infrastruktuuri juurutamine ja
haldus juniper srx riistvaral. Teamcity haldus,
uuendamine ja CI/CD haldus ja loomine,
opensearch klastri loomine ja haldus, elasticult
opensearchi kolimine, Docker konteinerite
loomine. Postgresql baaside haldus ja loomine,
kitsaskohtade optimeerimine, Prometheuse ja
grafana admininstreerimine Kubernetese kube-
prometheus-stacki põhjal, rakenduste saml ja
openid autentimise ja autoriseerimse
seadistused
Linux (Ubuntu), Ansible, AWX, Terraform,
GitOps, Docker, Kubernetes, kube-
prometheus-stack, AWS, vCenter, On-Premise
Infrastructure, TeamCity and ArgoCD CI/CD
Pipelines, Prometheus, Grafana, OpenSearch,
Elastic stack, Juniper SRX, BGP, infrastructure
core networking, SAML, OpenID Connect,
PostgreSQL, Microsoft Intune
Projekti nimetus: Piletilevi uue piletimüügisüsteemi analüüs,
arendus ja hooldus
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Piletilevi Group AS
Nimi: Jaanus Beilmann
e-post: [email protected]
Projekti toimumise aeg (alates-kuni): 08/2018-…
Roll projektis: Devops insener
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Osales projektis: 09/2018-05.2025
Helmes pilve füüsiliste seadmete haldus ja
planeerimine. Linux süsteemide tugi. Piletilevi
serverite ja andmebaaside kolimine, haldus,
uuendamine, monitoorimine. Linux serverite ja
andmebaaside haldus, tarkvara paigalduse
(pipeline’ide) automatiseerimine, monitoorimine.
PostgreSQL, Patroni, etcd, Progress, Haproxy,
Nginx, Apache httpd, RabbitMQ, Elasticsearch,
Fluentd, Kibana,, Docker, NFS, Salt, AWS,
Jenkins CI/CD, Grafana, Prometheus, Redis,
Linux, PostgreSQL, Haproxy, Httpd, NFS
Projekti nimetus: 2Park arendused (Autopay)
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Asutus: Autopay Technologies AS
(Norra)
Nimi: Kari-Janne Brekke
Operations Manager | Autopay
Telefon: +47 415 63 638
e-posti aadress: [email protected]
Projekti toimumise aeg (alates-kuni): 09/2018-...
Roll projektis: Devops Insener
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Osales projektis: 09/2018-...
Linux serverite ja andmebaaside haldus, tarkvara
paigalduse automatiseerimine, monitoorimine
Linux, PostgreSQL, Haproxy, Httpd, NFS
Projekti nimetus: Tallinna välisprojektide infosüsteemi arendus-
, hooldus- ja majutusteenus
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Tallinna Strateegiakeskus
Riigihanke viitenumber: 246291
Mari Roots
Projekti toimumise aeg (alates-kuni): 04/2022-…
Roll projektis: Devops Insener
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Osales projektis: 04/2022-...
Linux serverite ja andmebaasi haldus, rakenduse ja
serveri monitoorimine, arenduse pipeline
seadistamise abistamine (Jenkins -> Gitea Actions)
MariaDB, Apache Httpd, php, Gitea, Gitea Actions
(CI/CD), SaltStack
Projekti nimetus: Tallinna välireklaami- ja teabekandjate ning
reklaamimaksu järelevalveliste menetluste
andmekogu arendus-, majutus- ja
hooldusteenus
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Tallinna Strateegiakeskus
Riigihanke viitenumber: 240692
Mari Roots
Projekti toimumise aeg (alates-kuni): 09.2021-…
Roll projektis: Devops Insener
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Osales projektis: 09/2021-...
Linux serverite ja andmebaasi haldus, rakenduse ja
serveri monitoorimine, arenduse pipeline
seadistamise abistamine (Jenkins -> Gitea
Actions)PostgreSQL, Apache Httpd, php
PostgreSQL, Apache Httpd, php, Gitea, Gitea
Actions (CI/CD), SaltStack
Projekti nimetus: Tallinna projekti- ja tegevustoetuste
infosüsteemi majutus-, hooldus- ja
arendusteenus
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Tallinna Strateegiakeskus
Riigihanke viitenumber: 246959
Mari Roots
Projekti toimumise aeg (alates-kuni): 04/2022-…
Roll projektis: Devops Insener
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Osales projektis: 04/2022-...
Linux serverite ja andmebaasi haldus, rakenduse ja
serveri monitoorimine, arenduse pipeline
seadistamise abistamine (Jenkins -> Gitea Actions)
MariaDB, Apache Httpd, php, Gitea, Gitea
Actions(CI/CD), SaltStack
Projekti nimetus: Helmes AS sisesüsteemide haldus ja
monitooring
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Toomas Saar
Projekti toimumise aeg (alates-kuni): 09.2018-…
Roll projektis: Devops Insener
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Osales projektis: 09/2018-...
Linux serverite ja andmebaasi haldus, rakenduse ja
serveri ülesseadmine vastavalt erinevate äriklientide
soovidele, edasine serverite ja süsteemide
monitoorimine.
Tehnoloogiad PostgreSQL, Apache httpd, php, nginx,
haproxy, Docker, Kubernetes, Springboot
configserver, eureka, mariadb, mysql, nutanix
ahv/aos, salt, java, bitbucket, jira, confluence, hycu,
proxmox, xroad
Käesolevaga kinnitab pakkuja, et:
• spetsialist on tutvunud hangitava tööga ja andnud nõusoleku lepingu täitmisel
osalemiseks;
• spetsialisti CV-s esitatud andmed on õiged;
• spetsialist valdab kõiki asjakohaseid riigihanke alusdokumentides kirjeldatud
tehnoloogiaid ja metoodikaid ning on nõus neid lepingu täitmisel järgima;
• spetsialist vastab kõikidele esitatud nõuetele, sh keele nõudele;
• hankija võib kõiki siin esitatud andmeid igal ajal kontrollida.
Riigihange „TTJA e-teenuste keskkonna TARVIK arendus“
Viitenumber 291973
CV vorm
Spetsialisti ees- ja perekonnanimi: Alfred Kraft
Spetsialisti roll: Testija
Pakutud rolli eriala töökogemuse pikkus aastates: 3 aastat ja 4 kuud
Eesti keele kõneoskus: emakeel
Eesti keele kirjaoskus: emakeel
Kogemus nõutud rollis
Projekti nimetus: Eesti.ee tehniline kaasajastamine ja arendus
ning hooldustööd
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Riigi Infosüsteemi Amet. Annaliisa Kenppi,
Projekti toimumise aeg (alates-kuni): 11/2024 - praeguseni
Roll projektis: Testija
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Isik osales projektis vahemikus: 11/2024 -
praeguseni
Toote manuaalne testimine, automatiseeritud
testide kirjutamine, testimisega seotud
dokumentide koostamine.
Projektis kasutatud tehnoloogiad: PostgreSQL,
Angular, Java, Python, REST API, Spring Boot,
Tomcat, Nginx, Oauth, ELK, Prometheus,
Grafana, Redis, Docker, Kubernetes, Jenkins,
Webpack, Ansible, Terraform, Maven, Gradle,
JSON, Yaml, XML.
Projekti nimetus: Äritegevuseks tegevusloa taotlemise ja
majandustegevusteate esitamise analüüs ja
arendustööd
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Riigi Infosüsteemi Amet. Reimo Nõgu,
Projekti toimumise aeg (alates-kuni): 03/2024 – 12/2024
Roll projektis: Testija
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Isik osales projektis vahemikus: 03/2024 –
12/2024
Toote manuaalne testimine, automatiseeritud
testide kirjutamine, testimisega seotud
dokumentide koostamine.
Projektis kasutatud tehnoloogiad: PostgreSQL,
Angular, Java, REST API, Spring Boot, Tomcat,
Nginx, Oauth, ELK, Prometheus, Grafana, Redis,
Docker, Kubernetes, Jenkins, Webpack, Ansible,
Terraform, Maven, Gradle, JSON, Yaml, XML.
Projekti nimetus: Eesti.ee eraisiku ja ettevõtja vaadete tehniline
kaasajastamine
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Riigi Infosüsteemi Amet. Annaliisa Kenppi,
Projekti toimumise aeg (alates-kuni): 05/2023 – 06/2024
Roll projektis: Testija
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Isik osales projektis vahemikus: 11/2023 –
06/2024
Toote manuaalne testimine, automatiseeritud
testide kirjutamine, testimisega seotud
dokumentide koostamine.
Projektis kasutatud tehnoloogiad: PostgreSQL,
Angular, Java, REST API, Spring Boot, Tomcat,
Nginx, Oauth, ELK, Prometheus, Grafana, Redis,
Docker, Kubernetes, Jenkins, Webpack, Ansible,
Terraform, Maven, Gradle, JSON, Yaml, XML.
Projekti nimetus: Playtech online kasiinode kasutajahalduse
süsteemide arendus (Pennsylvania online
casinos, Fortuna SSO, Scientific Games Light
& Wonder online casinos)
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Playtech Estonia, Kaarel Rasva,
Projekti toimumise aeg (alates-kuni): 01/2022 – 10/2023
Roll projektis: Testija
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Isik osales projektis vahemikus: 01/2022 –
10/2023
Tarkvara testide analüüs ja disainimine. Tarkvara
manuaalne testimine, automatiseeritud testide
kirjutamine, päringute tegemine andmebaasi,
vigade tuvastamine ja analüüs, leitud vigade
raporteerimine. Regressioonitestide loomine ning
testplaani koostamine.
Projektis kasutatud tehnoloogiad: Java, Postgres
SQL, Spring Boot, Docker, REST, Junit, REST
Assured, Grafana, Jira, Confluence, Bamboo,
XML, JSON, Vue.js
Käesolevaga kinnitab pakkuja, et:
• spetsialist on tutvunud hangitava tööga ja andnud nõusoleku lepingu täitmisel
osalemiseks;
• spetsialisti CV-s esitatud andmed on õiged;
• spetsialist valdab kõiki asjakohaseid riigihanke alusdokumentides kirjeldatud
tehnoloogiaid ja metoodikaid ning on nõus neid lepingu täitmisel järgima;
• spetsialist vastab kõikidele esitatud nõuetele, sh keele nõudele;
• hankija võib kõiki siin esitatud andmeid igal ajal kontrollida.
Riigihange „TTJA e-teenuste keskkonna TARVIK arendus“
Viitenumber 291973
CV vorm
Spetsialisti ees- ja perekonnanimi: Kerttu Sepp
Spetsialisti roll: Testija
Pakutud rolli eriala töökogemuse pikkus aastates: 6+ aastat
Eesti keele kõneoskus: emakeel
Eesti keele kirjaoskus: emakeel
Kogemus nõutud rollis
Projekti nimetus: SKAIS pensionikalkulaatori sündmusteenuse
arendus
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
EHIK
Ott Mihailov
Projekti toimumise aeg (alates-kuni): 02.2025 – …
Roll projektis: Testija
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Isik osales projektis vahemikus: 04.2025 – ...
Tööülesanded: Tervikliku testplaani koostamine ja
arenduse manuaaltestimise ettevalmistus,
testandmete tekitamine, manuaaltestimine
(regresiooni testi teostamine, liideste testimine,
kasutajaliidese testimine, juhuslik katsetestimine)
Projekt on algusfaasis ja hõlmab uue BE mooduli
loomist SKAIS2'te; micro-front end'ile ehitatud
kasutaja liidese kasutsele võtmist ning erinevaid
liidestusi nii SKAIS'i moodulite kui ka välistega.
Tehnoloogiad: Angular 19, Spring Boot 3.x, Java
21, Javascript, Typescript, ORACLE, PostgreSQL,
välised liidesed (sh X-tee).
Projekti nimetus: Personaliseeritud ja proaktiivne iseteenindus
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Riigi Infosüsteemi Amet
Reelika Kask
Projekti toimumise aeg (alates-kuni): 11.2023 - ...
Roll projektis: Testija
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Isik osales projektis vahemikus: 03.2025 –
05.2025
Tööülesanded: Tervikliku testplaani koostamine,
manuaaltestimine, testandmete tekitamine.
Tegemist infosüsteemi loomise, modifitseerimine
ja ka juurutamise projektiga, kus on kasutusel
PL/SQL. Tehnoloogiad: Sonarqube, Redis,
Ansible, Docker, Jenkins, Angular, Spring Boot,
Java, Javascript, Typescript, PostgreSQL, Jacoco,
Nexus, Harbor, Bitbucket, JSON/REST, SOAP,
Koodivaramu, välised liidesed (sh X-tee).
Projekti nimetus: SME- käibemaksu erikord väikeettevõtetele
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
RMIT/EMTA
Katrin Abram
Projekti toimumise aeg (alates-kuni): 12.2023 - ...
Roll projektis: Testija
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Isik osales projektis vahemikus: 11.2024 –
02.2025
Tööülesanded: manuaaltestimine, sõnumivahetuse
testimine, testandmete tekitamine, kasutajalugude
kirjutamine
PostgreSQL, React, Java, Java Spring (Boot),
REST API, Tomcat, Hibernate, Gitlab, Jira,
Confluence, CI/CD, Docker-compose/Docker,
Gradle, Liquibase, Typescript/Javascript, SOAP,
Swagger, Bamboo, Postman, Playwright, rakendus
töötab klastris.
Projekti nimetus: Struktuuritoetuste registri (SFOS) arendus- ja
hooldusteenus
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
RMIT
Rene Välik
Projekti toimumise aeg (alates-kuni): 08/2020 – …
Roll projektis: Testija
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Isik osales projektis vahemikus: 10.2020 –
10.2024
SFOS on struktuurifondide infosüsteem, mis
võimaldab andmesisestust Eesti välisrahade
taotlemisel ning kasutamise kontrollimisel.
Tööülesanded: Rakenduse manuaalne testimine,
päringute tegemine andmebaasi, leitud vigade
raporteerimine, tekkinud ebakõlade selgitamine ja
otsustamine, kas arendus on valmis või mitte.
Regressioonitestide loomine ning testplaani
koostamine. Tegemist on turvakriitlise
süsteemiga.
Java, Angular, PostgreSQL, REST Assured,
XML, JSON, Jenkins, Junit, Jmeter.
Projekti nimetus: COLT- Common Outbound Logistics Tool
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Telia AS, Tulenevalt projekti konfidentsiaalsusest,
saame edastada kontaktandmed eraldi hankija
päringu korral
Projekti toimumise aeg (alates-kuni): 01.2014 - …
Roll projektis: Testija
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Isik osales projektis vahemikus: 04.2020 –
10.2020
Kauba müüki toetava logistika süsteemi
täiendamine, haldus ning tugi. Kasutusel 6 riigis.
Integratsioonid erinevate ERP süsteemide,
kaubatarnijate, laoteenuse pakkujate ning
transportteenuse pakkujate vahel. Kauba ja
tarnega seotud API teenuste disain ning süsteemi
arendus. Kaubamüügi süsteemi tugi ERP
süsteemide vahetamise ajal.
Tööülesanded: Süsteemi ja selle liideste tehniline
testimine, suhtlemine teiste riikide süsteemi
testijatega ning osalemine UAT protsessis.
Regressioonitestide väljatöötamine ja
automatiseerimise kava planeerimine. Arendusega
tutvumine, API testimine Postmaniga, SQL
päringute tegemine andmebaasi, leitud vigade
raporteerimine, tekkinud ebakõlade selgitamine ja
otsustamine, kas arendus on valmis või mitte
C# .NET, MS SQL Server, Postman
Projekti nimetus: Piletilevi müügiplatvormi arendus- ja
hooldustööd
Tellija info (sh asutuse/ettevõtte nimi,
kontaktisiku nimi ja -andmed):
Piletilevi Group
Jaanus Beilmann
Projekti toimumise aeg (alates-kuni): 08/2018 – …
Roll projektis: Testija
Teostatud tööde lühikirjeldus, kasutatud
tehnoloogiad/keeled/vahendid:
Isik osales projektis vahemikus: 08/2019 –
04/2020
Kasutajaliidese funktsionaalne ja
mittefunktsionaalne testimine, demode esitlus
kliendile. Javas Unit ja Integratsioonitestide
kirjutamine. Progress arenduskeskkonnas
lihtsamate arendustööde teostamine ja testimine.
Java 8, PostgreSQL, JUnit, JMeter, Angular, XML,
JSON, Progress
Käesolevaga kinnitab pakkuja, et:
• spetsialist on tutvunud hangitava tööga ja andnud nõusoleku lepingu täitmisel
osalemiseks;
• spetsialisti CV-s esitatud andmed on õiged;
• spetsialist valdab kõiki asjakohaseid riigihanke alusdokumentides kirjeldatud
tehnoloogiaid ja metoodikaid ning on nõus neid lepingu täitmisel järgima;
• spetsialist vastab kõikidele esitatud nõuetele, sh keele nõudele;
• hankija võib kõiki siin esitatud andmeid igal ajal kontrollida.
1 / 2
Kinnituskiri
Riigi Infosüsteemi Amet (RIA) kinnitab käesolevaga, et AS Helmese poolt järgnevad hankesse
esitatud andmed referentsprojekti kohta on õiged ning AS Helmese ja RIA vahel sõlmitud
lepingute maht alltoodud tabelis nimetatud IT-teenuse arenduseks oli vähemalt 2000 tundi.
Hinnatav kriteerium Punktide
arv
IT-teenus: Riigiportaali
arendused (eesti.ee)
(isik kes osales): Madis
Sander Maddison
(on täidetud = 1, ei ole täidetud
= 0)
Täiendav selgitus
- kus/kuidas on
täidetud
Avalikult kasutatav
rakendus1 2 1
Eesti.ee
Rakenduse kasutajate
autentimine toimub eID
vahenditega riiklikus2
autentimisteenuses
TARA või GovSSO
1 1
GovSSO
Rakenduse
andmebaasimootorina
kasutatakse PostgreSQL-
i
1 1
menu, dashboard jt
Rakendus töötab
Docker
konteinerlahendusena
2 1
Riigipilve
Kubernetes klastris
Docker konteiritena
Rakendus töötab
horisontaalselt
skaleeritavana3
Kubernetese platvormil
1 1
Jah, rakendusi on
võimalik
horisontaalselt
skaleerida
Rakenduse ehitus ja
paigaldus teostatakse
GitLabi CI/CD
vahenditega
1 1
Koodivaramu
Gitlab töövoog
Rakendus tarbib x-tee
teenuseid 1 1 RR, EMTA jpt
Rakendus pakub x-
tee teenuseid 1 1
https://x-
tee.ee/catalogue/EE/
GOV/70006317/riig
iportaal
Riigi Infosüsteemi amet
Õie-Mari Aasmäe
10
2 / 2
Täpsustused
1Avalikult kasutatav rakendus tähendab, et iga avalik kasutaja saab välisvõrgust rakendusele
ligi, vajadusel sinna sisse logida/kasutaja luua, selle pakutavaid teenuseid kasutada.
2Rakendus on kasutajate autentimiseks kas otse liidestatud TARA/GovSSO teenusega või
liidestatud läbi vaheautentimisserveri (näiteks Keycloak) ning rakenduse ja
autentimisserveri vahel kasutatakse OpenID Connect protokolli.
3Rakendus on loodud tõrgeteta töötama Kubernetese platvormil horisontaalselt
skaleeritavana, st koormuse kasvades võib rakendust replitseerida kahe või enama
instantsina (POD replicas >= 2) manuaalselt või kasutades Kubernetese automatiseeritud
skaleerimist (Horizontal Pod Autoscaling).
Õie-Mari Aasmäe
talituse juhataja
Tehnoloogia arenduse talitus I Personaalriigi osakond
/allkirjastatud digitaalselt/
1 / 2
Kinnituskiri
Riigi Infosüsteemi Amet (RIA) kinnitab käesolevaga, et AS Helmese poolt järgnevad hankesse
esitatud andmed referentsprojekti kohta on õiged ning AS Helmese ja RIA vahel sõlmitud
lepingute maht alltoodud tabelis nimetatud IT-teenuse arenduseks oli vähemalt 2000 tundi.
Hinnatav kriteerium Punktide
arv
IT-teenus: Sündmusteenuste
platvormi ja teenuste arendused
(isik kes osales): Siim
Tanel Laisaar
(on täidetud = 1, ei ole täidetud =
0)
Täiendav selgitus
- kus/kuidas on
täidetud
Avalikult kasutatav
rakendus1 2 1
Riigiportaali
sündmusteenused
Rakenduse kasutajate
autentimine toimub eID
vahenditega riiklikus2
autentimisteenuses
TARA või GovSSO
1 1
GovSSO
Rakenduse
andmebaasimootorina
kasutatakse
PostgreSQL-i
1 1
sun-db
Rakendus töötab
Docker
konteinerlahendusena
2 1
Riigipilve
Kubernetes klastris
Docker konteiritena
Rakendus töötab
horisontaalselt
skaleeritavana3
Kubernetese platvormil
1 1
Jah, rakendusi on
võimalik
horisontaalselt
skaleerida
Rakenduse ehitus ja
paigaldus teostatakse
GitLabi CI/CD
vahenditega
1 1
Koodivaramu
Gitlab töövoog
Rakendus tarbib x-tee
teenuseid 1 1 RR, EMTA jpt
Rakendus pakub x-
tee teenuseid 1 1
https://x-
tee.ee/catalogue/EE/
GOV/70006317/sun
-life-events
Riigi Infosüsteemi amet
Reimo Nõgu
10
2 / 2
Täpsustused
1Avalikult kasutatav rakendus tähendab, et iga avalik kasutaja saab välisvõrgust rakendusele
ligi, vajadusel sinna sisse logida/kasutaja luua, selle pakutavaid teenuseid kasutada.
2Rakendus on kasutajate autentimiseks kas otse liidestatud TARA/GovSSO teenusega või
liidestatud läbi vaheautentimisserveri (näiteks Keycloak) ning rakenduse ja
autentimisserveri vahel kasutatakse OpenID Connect protokolli.
3Rakendus on loodud tõrgeteta töötama Kubernetese platvormil horisontaalselt
skaleeritavana, st koormuse kasvades võib rakendust replitseerida kahe või enama
instantsina (POD replicas >= 2) manuaalselt või kasutades Kubernetese automatiseeritud
skaleerimist (Horizontal Pod Autoscaling).
Reimo Nõgu
Tooteomanik
Teenuste äritalitus I Personaalriigi osakond
/allkirjastatud digitaalselt/
1
TARKVARAARENDUSE RAAMLEPING NR 6-2/25/125
Tellija Täitja
Nimi Keskkonnaministeeriumi
Infotehnoloogiakeskus
AKTSIASELTS HELMES
Registrikood 7000944510364097
Esindaja teenindusvaldkonna juht
direktori ülesannetes Villu Kägo
juhatuse liige Andres Kaljo
Esindusõiguse alus volitusseadus
Kontaktisiku
andmed
Riina Klais-Peets
+372 56150856
Kert Valamaa
+372 5144865
sõlmisid käesoleva raamlepingu (edaspidi ka: Leping) alljärgnevas:
1. RAAMLEPINGU EESMÄRK JA PÕHITINGIMUSED
1.1. Raamlepingu eesmärgiks on kehtestada tingimused, kuidas toimub Raamlepingu
esemeks olevate Tööde tellimiseks Hankelepingute sõlmimine Tellija ning Täitja
vahel (Raamleping on sõlmitud ÜHE Täitjaga).
1.2. Leping ei kohusta Tellijat töid tellima.
1.3. Lepingu põhitingimused on:
Lepingu sõlmimise alus ja
lahutamatu osa
Riigihanke „TTJA e-teenuste keskkonna TARVIK
arendus“ viitenumbriga 291973 (edaspidi: Riigihange)
alusdokumendid ning Täitja esitatud Raampakkumus.
Lepingu ese
edaspidi ka: Töö või Tööd
Tarbijakaitse ja Tehnilise Järelevalve Ameti e-teenuste
keskkonna TARVIK tarkvara loomine ja
hooldusteenuse osutamine.
Raamlepingu kehtivus 4 aastat.
Maksimaalne maksumus kuni 12 000 000 eurot, millele lisandub käibemaks.
Intellektuaalse omandi õiguste
mudel
Lihtlitsentsi mudel
Arve tasumise tähtaeg 21 päeva
Hinna indekseerimine Ei
2
2. MÕISTED
2.1. Suure algustähega mõisteid tuleb Lepingus tõlgendada nii, nagu need allpool on
määratletud. Kui ei ole teisiti sätestatud, siis viitab mõiste ainsuse vorm ka selle
mitmusele. Kahtluse korral tuleb väljendeid, millel võib olla rohkem kui üks tähendus,
mõista viisil, mis sobib kõige rohkem Lepingu olemuse ja eesmärkidega.
• Akt - dokument, mille allkirjastamisega Täitja annab Tööde etapi raames tehtud
Tööd üle ja Tellija võtab need vastu. Viimase Tööde etapi lõpus allkirjastatakse
Koondakt, millega peab olema hõlmatud kogu Tarkvara. Koondakti
allkirjastamisega kinnitavad Pooled, et Lepingu täitmiseks vajalikud tööd (v.a
garantiikohustus) on teostatud. Akti vorm on toodud Raamlepingu Lisas 1.
• Hankeleping – raamlepingu alusel sõlmitud leping, mis on aluseks Tööde
teostamisele ning vormistatakse Raamlepingus sätestatud tingimuste korral
Raamlepingu Lisas 2 toodud dokumendivormil.
• Raamleping – Raamleping koos lisadega. Raamlepingu eesmärgiks on fikseerida
Tööde edukaks tegemiseks vajalike kokkulepete raamistik raamlepingu raames
sõlmitavate hankelepingute vormis.
• Leping – Raamleping ja/või Hankeleping;
• Raampakkumus – Täitja poolt Riigihankes esitatud ja edukaks tunnistatud
pakkumus, mis on Raamlepingu sõlmimise aluseks ja selle lahutamatu osa.
• Pool – sõltuvalt Lepingu kontekstist kas Tellija või Täitja või mõlemad koos.
• Projekt – Hankelepingu esemeks olevad Tööd.
• Projektiplaan –Töö sisu, teostamise aeg ja koht ning Tööde üleandmise ajakava.
• Spetsifikatsioon – Projekti detailanalüüsi käigus dokumenteeritud lahenduse
kirjeldus, mille alusel tarkvaralahendus programmeeritakse ning tarkvara
funktsionaalsuse toimimist kontrollitakse. Spetsifikatsioonid sisaldavad muuhulgas
tarkvarakomponentide ja teenuste kirjeldusi, sh andmeväljade kirjeldusi,
funktsionaalseid nõudeid jmt;
• Tarkvara – kõik Lepingu täitmiseks rakendatavate tarkvara komponendid
kogumis. Tarkvara võib koosneda järgmistest komponentidest:
o Arendatav tarkvara – tarkvara, mis on loodud spetsiaalselt Tellija jaoks Tellija
konkreetseid huve ja soove silmas pidades hankelepingu alusel;
o Kommertstarkvara – tarkvara, mida kasutatakse Arendatava tarkvara
funktsionaalsuse tagamiseks ning mis kuulub kas Täitjale või kolmandale isikule
ning mille kasutusõigus antakse Täitja või kolmanda isiku poolt Tellijale
litsentsi alusel;
o Tellija tarkvara – mistahes tarkvara, mis on Tellija poolt omandatud, loodud
või temale litsentseeritud, v.a Arendatav tarkvara ja Kommertstarkvara;
o Täitja tarkvara – tarkvara, mis on Täitja poolt omandatud, loodud või temale
litsentseeritud enne Lepingu sõlmimist;
o Vabavaraline tarkvara – tarkvara, mida kasutatakse Arendatava tarkvara
funktsionaalsuse tagamiseks, kuid mida ei ole arendanud Täitja, vaid mis kuulub
kolmandale isikule ning mille kasutusõigus antakse kolmanda isiku poolt
Tellijale tarkvara vaba kasutuse litsentsi alusel;
3
• Täiendusvajadus – vajadus lahendada ilmnenud probleemid või täiendada
funktsionaalsust, mis ei kvalifitseeru Veaks ning mille teostamise ja tasustamise
osas on vaja täiendavalt kokku leppida;
• Tulem – Lepingu esemeks olevate Tööde terviklik lõpp- või konkreetne osa- või
vahetulemus.
• Tööd - Täitja poolt täidetavad tarkvara arenduse, seadistamise, konsultatsiooni,
koolitamise, hoolduse, dokumenteerimise või muud Poolte vahel kokku lepitud
ülesanded, mis on täpsustatud Lepingu põhitingimustes ning teistes Lepingu
dokumentides;
• Töö etapp – Projekti eesmärkide täitmist viiakse ellu etapiviisiliselt vastavalt
Poolte vahel kokku lepitud ajakavale. Projekti ajakavas lepitakse kokku Töö etapi
tulemid ja tähtaeg;
• Viga – Töös, sh selle Tulemis, esinev mittevastavus Lepingu tingimustele.
3. HANKELEPINGUTE SÕLMIMISE KORD
3.1. Tööde teostamise aluseks on Täitjaga sõlmitud Hankeleping. Hankeleping loetakse
sõlmituks nii tellimuse esitamisel ja Tellija poolt pakkumuse aktsepteerimisel kui ka
Hankelepingu sõlmimisel konkreetsel vormil. Pakkumusena käsitletakse käesolevas
peatükis ka pakkumuse täpsustamisena RHS § 30 lg 3 sätestatud tähenduses.
3.2. Tööde tellimiseks esitab Tellija Täitjale kirjalikku taasesitamist võimaldavas vormis
tellimuse, välja arvatud jooksva konsultatsiooni vajaduse korral. Tellimus on täitjale
esitatav pöördumine Tööde teostamiseks, kas tellimusena, mille järel sõlmitakse
Hankeleping kindlal vormil (kasutades eelkõige Lisas 2 toodud vormi) või Tööde
halduskeskkonna (nt Jira) kaudu. Tellimuses fikseeritud tehnilise kirjelduse alusel,
milles on määratud Tööde sisu ja üle antavad tulemid, võimalusel Tööde maht, ajalised
ja eelarvelised piirangud, kas Tellija kohaldab indekseerimist ka Hankelepingule, jm
olulised tingimused Hankelepingu sõlmimiseks. Tingimused võivad olla fikseeritud
etapiti.
3.3. Tellija annab Täitjale mõistliku aja pakkumuse esitamiseks. Pakkumuse esitamisel tuleb
järgida kõiki tellimuses esitatud nõudeid.
3.4. Täitja hindab võimalusel tellimuse alusel töö mahtu ja esitab tellimuses määratud
tähtajaks hinnapakkumuse töö teostamiseks ja/või vajadusel muud tellimuses nõutud
andmed (pakkumus).
3.5. Kui pakkumus ei vasta tellimuse tingimustele või ei ole muul põhjusel vastuvõetav,
lükkab Tellija pakkumuse tagasi.
3.6. Tellijal on õigus esitatud pakkumus tagasi lükata ja otsustada Hankelepingut mitte
sõlmida või vastavalt Raamlepingule esitatud tellimus kehtetuks tunnistada, kui:
3.6.1. pakkumus ei vasta tellimuse tingimustele;
3.6.2. Tellija vajadus tellimuse täitmiseks kaob või muutub;
3.6.3. Pakkumus ületab eeldatavat maksumust või;
3.6.4. Tellija ei saa välisvahenditega seotud Hankelepingu sõlmimiseks heakskiitu.
4
3.7. Pooled võivad pidada tellimuse või pakkumuse muutmiseks või kohandamiseks
läbirääkimisi, et muuta pakkumus tellimusele vastavaks või tellimuse tingimused
pakkumusele sobivaks.
3.8. Kui Hankelepingu ilma käibemaksuta maksumus on vähemalt 20 000 eurot,
vormistavad Pooled Hankelepingu eraldi kirjalikus vormis sõlmitava
lepingudokumendina. Täitja kohustub sellisel juhul Hankelepingu allkirjastama kolme
tööpäeva jooksul Tellijalt Hankelepingu dokumendi saamisest.
4. RAAMLEPINGU HIND, INDEKSEERIMINE
4.1. Raamlepingu kehtivusajal kehtiv Täitja maksimaalne ühikhind/ühikhinnad
käibemaksuta (edaspidi: Hind) on sätestatud Täitja Raampakkumuses.
4.2. Täitja poolt Tellija tellimuse alusel Töö teostamiseks pakutav maksumus ei või ületada
Pakkumuses sätestatud Hinda (kui Hinda ei indekseerita) või pakkumuse esitamise ajal
kehtivat Hinda (kui Hinda indekseeritakse).
4.3. Kui Lepingu põhitingimuste kohaselt on ette nähtud Hinna indekseerimine, siis toimub
Raamlepingu kehtivuse ajal Raampakkumuses sätestatud Hinna indekseerimine
vastavalt käesoleva punkti tingimustele. Hinda indekseeritakse iga Raamlepingu
sõlmimisele järgneva täiskalendriaasta (st 1. jaanuar – 31. detsember) möödumisele
järgneval päeval (st 1. jaanuaril). Näidiseks: kui Raamleping on sõlmitud 1. mail 2023,
siis esimest korda indekseeritakse Hinda 1. jaanuaril 2025 ning järgmine kord 1.
jaanuaril 2026 jne. Hinna indekseerimine toimub tarbijahinnaindeksi alusel, st Hind
tõuseb või langeb indekseerimise hetkele eelneva kalendriaasta tarbijahinnaindeksi
muudatuse võrra. Maksimaalselt võib Raamlepingu koguperioodil indekseerimise
tulemusel Hind tõusta kuni 20% Raampakkumuses märgitud Hinnast. Negatiivse
tarbijahinnaindeksi korral vähendatakse Hinda vastavalt tarbijahinnaindeksi muutusele,
aga mitte väiksemaks kui Raampakkumuses märgitud Hind.
4.4. Raamlepingu maksimaalne maksumus tähistab Täitjaga Raamlepingu alusel
sõlmitavate Hankelepingute maksimaalset summeeritud väärtust, mis on sätestatud
Lepingu põhitingimustes. Raamlepingu maksimaalse maksumuse täitumise korral
loetakse Raamleping automaatselt lõppenuks.
5. ARVELDUSED
5.1. Tellija tasub Täitja teostatud Tööde eest Täitjale tasu, mille suurus ja arveldamise
tingimused on fikseeritud Hankelepingus.
5.2. Kui Hankelepingus ei ole sätestatud teisiti, on Hankelepingus fikseeritud tasu ainus tasu
seoses Hankelepinguga ning see ei ole seatud sõltuvusse inflatsioonist, tööjõu või
muude vahendite kallinemisest või mistahes muudest teguritest ning tasu võib muuta
üksnes Poolte kirjaliku kokkuleppega õigusaktides lubatud juhtudel ja korras.
5.3. Täitja esitab Tellijale masinloetava e-arve üle antud ja vastu võetud Tööde eest pärast
vastava Akti allkirjastamist Poolte poolt. Välisriigis registreeritud Täitja puhul lepitakse
arve esitamise vorm ja viis eraldi kokku esimesel võimalusel pärast Raamlepingu
sõlmimist. Arve loetakse tasutuks arvel näidatud summa laekumisest Täitja
arvelduskontole.
5
5.4. Kui Tellija ei tasu Täitja esitatud arveid õigeaegselt, on Täitjal õigus nõuda viivist
0,01% vastaval arvel märgitud tasumata summalt iga viivitatud kalendripäeva eest kuni
arve täieliku tasumiseni, kuid mitte rohkem kui 25% vastava arve summast.
5.5. Kui Pooled ei lepi eraldi vähemalt kirjalikku taasesitamist võimaldavas vormis kokku
teisiti, siis Lepingu alusel Poole tasutud mistahes maksega loetakse esmajärjekorras
vastavas osas tasutuks Lepingu täitmisega (sh täitmisele pööramisega) seotud kulud (sh
õigusabikulud), seejärel viivis ja leppetrahvid alates varaseimast võlgnevusest ning
seejärel tasumata põhisumma alates varaseimast võlgnevusest.
5.6. Raamlepingu täitmist rahastatakse riigieelarvest, kuid võidakse rahastada ka
välisvahenditest. Konkreetne rahastusallikas ja sellest tulenevad nõuded täpsustatakse
Hankelepingus või Riigihanke alusdokumendis.
5.7. Juhul, kui Raamlepingu või Hankelepingu alguses on määratletud poolena ka
„Rahastaja“, siis toimub Täitjale tasumine Tellija asemel Rahastaja poolt.
6. TELLIJA RESERV HANKELEPINGUS
6.1. Tellijal on õigus tellida ja Täitjal on kohustus teostada Hankelepingu esemega seotud
täiendavaid Töid (hankelepingu esemega seotud Tööde täiendamine või mahu
suurendamine) kuni 10% ulatuses Täitjaga sõlmitud Hankelepingu mahust. Tellijal on
õigus lisatöid tellida juhul, kui see on Hankelepingu eesmärgi täitmiseks vajalik, näiteks
kui Tööde teostamise käigus ilmneb ebatäpsus Hankelepingu sõlmimise aluseks olevas
lähteülesandes, vajadus täpsustub detailanalüüsi käigus, muutuvad vastavat valdkonda
reguleerivad õigusaktid vmt.). Täiendavate Tööde tellimine on võimalik, kui see ei
muuda olemuslikult Hankelepingu eset. Tellija (vajadusel Rahastaja) tasub nimetatud
Tööde eest vastavalt Hankelepingus märgitud ühikhinnale.
6.2. Tellija esitab Lepingu esemega seotud Tööde täiendamiseks Täitjale kirjaliku täienduste
loetelu, mille Täitja vaatab üle viie tööpäeva jooksul ja esitab omapoolse analüüsi ja
ajahinnangu.
6.3. Kui Täitja kohustuste muutmine toob kaasa põhjendatud ajakulu, pikendatakse Tellija
nõusolekul vastavalt Täitja kohustuste täitmise tähtaega.
6.4. Käesolevas peatükis sätestatud täiendavate Tööde tellimisega seotud tingimused
lepitakse kokku Tellija ja Täitja vahel vähemalt kirjalikku taasesitamist võimaldavas
vormis.
7. TÖÖDE TEOSTAMINE
7.1. Üldised nõuded
7.1.1. Täitja tehtavad Tööd on määratletud Hankelepingus. Hankelepingu täitmisele
kohalduvad lisaks Hankelepingu enda tingimustele kõik Raamlepingus
sätestatud tingimused osas, mida Hankeleping ei reguleeri teisiti.
6
7.1.2. Tellija eeldab, et Täitja on Hankelepingu esemeks olevate Tööde
tarkvaraarenduse valdkonna professionaal, kes saab aru ning võtab teadlikult
enda kanda Hankelepingu funktsionaalsete ja mittefunktsionaalsete nõuete
täidetavuse ja tulemuse saavutatavuse riski. Täitjal on kohustus veenduda
Hankelepingu esemeks oleva töö teostamiseks esitatud kirjelduse piisavuses
ning igast puudusest Tellijat enne lepingu sõlmimist teavitama. Täitjal on
kohustus teha Hankelepingu täitmisel ka niisugused Tööd, mida harilikult
niisuguse Hankelepingu puhul välja ei tooda ning mida sel põhjusel ei ole
Hankelepingus otsesõnu kokku lepitud, kuid mis oma olemusest lähtuvalt on
vajalikud Hankelepingu täitmiseks ning professionaalsele Täitjale pidid
olema ettenähtavad pakkumuse esitamise etapis. Siin punktis kirjeldatud
Tööde tegemine ei kuulu teistsuguse kirjaliku kokkuleppe puudumisel eraldi
tasustamisele ning Täitja teostab need Tööd Hankelepingu täitmise raames.
7.1.3. Töövõtja peab teostama Tööd vastavalt Lepingus, sh Riigihanke
alusdokumentides sätestatud tingimustele ning infotehnoloogia- ja
telekommunikatsioonisektori parimas praktikas rakendatavatele tehnilistele
kvaliteedinõuetele, normidele ja standarditele. Töövõtja kohustub tagama
Tööde, sh analüüsi ja disaini kvaliteedi ning terviklikkuse, samuti selle alusel
tehtava Töö Tulemi realiseeritavuse ja rakendatavuse (niivõrd, kuivõrd see on
Tulemist tulenev) koostoimelise ja riigi infotehnoloogia põhimõtetele vastava
infosüsteemina.
7.1.4. Täitja tagab Tarkvara ühilduvuse Tellija toodangukeskkonnaga, sh Tellija
tarkvaraga. Täitja on kohustatud järgima vaid selliseid Tellija
toodangukeskkonna nõudeid, millest Tellija on Täitjat teavitanud.
7.1.5. Tööde käigus loodud lähtekood peab olema kirjutatud ja dokumenteeritud
selliselt, et vajadusel oleks Tellija või kolmas isik võimeline aru saama
tarkvara loogilisest ülesehitusest ning jätkama lähtekoodi arendusega,
juhindudes Tellija veebilehel avaldatud Keskkonnaministeeriumi haldusala
mittefunktsionaalsetest nõuetest ning tehnoloogilisest profiilist.
7.1.6. Täitjapoolne Tööde teostamise kohustuste täitmine ei tohi tekitada häireid
Tellija mistahes teiste liidestatud süsteemide või teenuste talitluses, v.a juhul
kui Täitja lähtus Töö teostamisel Tellijapoolsetest juhistest ja kokkulepetest,
kuid sellele vaatamata tekkisid häired. Juhul kui Töö teostamine toimub
Tellija ruumides, peavad Tellija ruumides viibivad Täitja Teostajad kinni
pidama Tellija sellistest sisekorraeeskirjadest, sh turvanõuetest, mida on
Täitja Teostajatele tutvustatud.
7.1.7. Lepingu suhtluskeel on eesti keel.
7.2. Meeskond ja alltöövõtjad
7.2.1. Töid teostavad üksnes Täitja pakkumuses nimetatud isikud või täiendava
meeskonna liikmed. v.a juhul, kui põhjendatud vajaduse korral on Täitja
meeskonnaliige asendatud Tellija kirjalikku taasesitamist võimaldavas
vormis antud nõusolekul uue, algse hanke tingimustele vastava
meeskonnaliikmega.
7.2.2. Täitja asendab enda kulul Tööd teostava isiku viivitamatult pakkumuses
nimetatud isiku töökogemusele vastava isikuga, saades selleks Tellija eelneva
kirjalikku taasesitamist võimaldavas vormis väljendatud nõusoleku, kui:
7
7.2.2.1. Tööd teostav isik ei ole võimeline teostama tööd haiguse, õnnetusjuhtumi või
muu temast tuleneva asjaolu tõttu;
7.2.2.2. pakkumuses nimetatud isik osutub tellija põhjendatud arvamuse kohaselt
ebakompetentseks või ebasobivaks või kui temapoolne ülesannete täitmine
korduvalt kahjustab Hankelepingu nõuetekohast või õigeaegset täitmist.
7.2.3. Töid võivad Hankelepingu alusel teha üksnes Täitja pakkumuses konkreetselt
nimetatud või Tellijaga muul viisil eelnevalt kirjalikult kooskõlastatud
alltöövõtjad.
7.3. Projekti halduskeskkonnad
7.3.1. Tööülesannete halduskeskkond:
7.3.1.1. Tööülesannete halduskeskkond on konfiguratsiooni- ja tööülesannete
haldustarkvara, mida kasutatakse Projekti töödes leitud Vigade ja
probleemide registreerimiseks tööülesannetena ning tööülesannete täitmise
jälgimiseks. Tellija registreerib Projekti tulemis leitud Vead tööülesannetena
Tööülesannete halduskeskkonnas.
7.3.1.2. Halduskeskkonna tarkvarale luuakse ligipääs veebiaadressi kaudu.
7.3.1.3. Tellija võib lisaks Tööülesannete halduskeskkonnas registreerimisele viidata
leitud Vigadele ka e-kirjavahetuses ja muudes kirjades, kuid
Vea/tööülesandega tegelema hakkamise eelduseks on selle registreerimine
Tööülesannete halduskeskkonnas.
7.3.1.4. Vajadusel lepivad Pooled kokku täpsema Tööülesannete halduskeskkonna
kasutamise korra, milles täpsustatakse ülesannete lisamise nõuded
(pealkirjad, teemad, ülesannete prioriteetide kategooriad jmt).
7.3.1.5. Tööülesannete halduskeskkond lepitakse kokku Hankelepingus.
7.3.2. Projekti dokumendihalduskeskkond:
7.3.2.1. Projekti dokumendihalduskeskkonda kasutatakse Tellija ja Täitja vaheliseks
infovahetuseks ning selle keskkonna kasutamine on kohustuslik dokumentide
vahetamisel. Tellija edastab Tööde lähteinfo Projekti
dokumendihalduskeskkonna kaudu, lisades dokumendi kokkulepitud
dokumendi kataloogi ning edastades e-kirja või Tööülesannete
halduskeskkonna kaudu lingi nimetatud dokumendile.
7.3.2.2. Täitja edastab koostatud dokumendid Tellijale ülevaatamiseks ja
kooskõlastamiseks Projekti dokumendihalduskeskkonna kaudu, lisades need
dokumenditeegi kokkulepitud kausta.
7.3.2.3. Dokumendi kustutamine Projekti dokumendihalduskeskkonnast on lubamatu
(v.a juhul, kui Tellija ja Täitja projektijuhid on kustutamiseks selge nõusoleku
andnud).
7.3.2.4. Dokumendihalduskeskkonna tarkvarale luuakse ligipääs veebiaadressi
kaudu.
7.3.2.5. Vajadusel lepivad Pooled kokku täpsema Projekti
dokumendihalduskeskkonna kasutamise korra, milles täpsustatakse
dokumentide lisamise tingimused (pealkirjad, koodid, teemad, kategooriad
jmt).
8
7.3.2.6. Projekti dokumendihalduskeskkond on määratletud Riigihanke
alusdokumentides.
7.3.3. Arendus-, Test- ja Toodangukeskkonnad:
7.3.3.1. Arenduskeskkond koosneb arendus andmebaasist, rakendusserverist ja
ligipääsust väliste süsteemide liideste testkeskkondadele.
7.3.3.2. Testkeskkond koosneb test andmebaasist, rakendusserverist ja ligipääsust
väliste süsteemide liideste testkeskkondadele.
7.3.3.3. Toodangukeskkond koosneb live andmebaasist, rakendusserverist ja
ligipääsust väliste süsteemide liideste live keskkondadele.
7.3.3.4. Pooled teevad mõistlikud pingutused tagamaks, et Testkeskkond sarnaneks
Toodangukeskkonnale järgmises osas:
(a) arvutivõrgu konfiguratsioon;
(b) liidesed kolmandate süsteemidega;
(c) andmete kvaliteet ja maht.
Kui maksimaalne sarnasus ei ole majanduslikult põhjendatud või tulenevalt
andmekaitse piirangutest mõistlik, kohustub Pool informeerima teist Poolt
Test- ja Toodangukeskkondade disainitud erinevustest. Vajadusel lepivad
Pooled kokku alternatiivse võimaluse keskkondade erinevuse puudujäägi
kompenseerimiseks.
7.3.3.5. Arendus-, Test- ja Toodangukeskkondade installeerimise, keskkondade ning
ligipääsude haldamise osas lepitakse kokku Hankelepingus.
7.4. Projekti põhitegevused
7.4.1. Süsteemianalüüs (detailanalüüs):
7.4.1.1. Täitja teeb süsteemianalüüsi, võttes aluseks tehnilise kirjelduse ning Tellija
edastatud täpsustava lähtematerjali, mis on Tellija äriprotsessi
asjassepuutuvate osapooltega (lõppkasutajad jmt) eelnevalt kooskõlastatud.
7.4.1.2. Süsteemianalüüsi tulemuseks on süsteemi komponente ja nende toimimist
detailselt kirjeldavad dokumendid – Spetsifikatsioonid -, mis on mõlema
Poole jaoks üheselt mõistetavad. Spetsifikatsioonid on sisendiks nii
programmeerijatele kui ka testijatele.
7.4.1.3. Tellija edastab komponendi lähteinfo, mis sisaldab ekraanivaadete mustandit,
tööprotsessi kirjeldust, loogiliste kontrollide loetelu ja kirjeldusi, seoseid
teiste infosüsteemidega jm olulist infot, Projekti dokumendihalduskeskkonna
kaudu Projektiplaanis kokkulepitud tähtajaks. Kui vaja, siis Pooled
täpsustavad eelnevalt, kas ja kui jah, siis millist lähteinfot on Tellijalt vaja
analüüsi alustamiseks.
7.4.1.4. Täitja analüütik tutvub Tellija koostatud eelinfoga.
7.4.1.5. Kui tegemist on visuaalset väljundit omava komponendi Spetsifikatsiooniga,
siis Täitja analüütik koostab komponendi esialgse prototüübi ning
spetsifitseerib komponendi kontrollid, seotud protsessid, seosed andmebaasi
ja teiste infosüsteemidega.
9
7.4.1.6. Täitja analüütik täpsustab komponendi nõuded, seosed jmt analüüsi
koosolekul. Kui Tellija ei oska kõigile analüüsi küsimustele koosolekul
vastata, vastab Tellija projektijuht küsimustele kirjalikult pärast koosolekut
esimesel mõistlikul võimalusel.
7.4.1.7. Kui analüüs vajab teise arendaja kommentaari (nt realiseeritakse liidestumist
teise arendaja koodiga), siis osalevad nõupidamisel kõikide osapoolte
analüütikud (efektiivsuse eesmärgil on soositud arendajate omavaheline
suhtlus ka Skype’i või sarnase teenuse jututoa kaudu) ning kokkulepitud
lahendus kooskõlastatakse Tööülesannete halduskeskkonnas kõikide
osapoolte projektijuhtidega.
7.4.1.8. Täitja analüütik täiendab ja parandab Spetsifikatsiooni. Vajadusel korratakse
eelnevat sammu, kuni kogu komponendi Spetsifikatsiooni esialgne versioon
on valmis.
7.4.2. Spetsifikatsioonide kinnitamine:
7.4.2.1. Analüüsi valmimisel saadetakse Spetsifikatsioon Tellijale ülevaatamiseks ja
kommenteerimiseks, kasutades selleks Tööülesannete halduskeskkonda.
7.4.2.2. Tellija määrab isiku, kelle kaudu toimub analüüsi tööülesannete vahendamine
Tellija ja Täitja vahel. See isik edastab vajadusel tööülesande vastava
teemaga seotud isikutele läbivaatamiseks ning vastutab ülesannete õigeaegse
tagasiside andmise ja kinnitamise eest.
7.4.2.3. Tellija on kohustatud tagasiside Spetsifikatsiooni osas esitama esimesel
mõistlikul võimalusel.
7.4.2.4. Sama Spetsifikatsioon saadetakse ülevaatamiseks ja kommenteerimiseks
kuni Tellija kooskõlastab selle.
7.4.2.5. Tellija tutvub Spetsifikatsiooniga, mis on tööülesandena Tellija nimel, ning
kui analüüsi tulemid vastavad ootustele (st vastavad tehnilisele kirjeldusele
ning analüüsi käigus kokkulepitule), kinnitab Tellija tööülesandes
Spetsifikatsiooni, kirjutades vastava kommentaari. Kui Spetsifikatsioonis
esinevad puudused ning kinnitust veel ei saa anda, lisab Tellija
tööülesandesse vastavad kommentaarid. Pärast tööülesandega tegelemist
suunab Tellija tööülesande tagasi Täitja analüütikule.
7.4.2.6. Kinnitatud Spetsifikatsioon on lähteülesandeks arendustöödele.
7.4.2.7. Nii Tellija kui ka Täitja on kohustatud tegema kõik endast oleneva, et
Spetsifikatsioonid saaksid lõplikult kinnitatud Projektiplaanis kokku lepitud
arendustööde alustamise tähtajaks.
7.4.3. Tarkvaraarendus ja testimine:
7.4.3.1. Süsteemiarenduse etapis on Täitja ülesanne realiseerida Spetsifikatsioonides
kirjeldatu Tarkvara komponentideks – kujundus, veebikihi komponendid,
baasikihi osa jne. Loomise järel komponendid integreeritakse
Arenduskeskkonda, testitakse ja parandatakse Vead.
7.4.3.2. Täitja arendaja realiseerib komponendid vastavalt Spetsifikatsioonile.
7.4.3.3. Täitja testija testib realiseeritud komponentide vastavust Spetsifikatsioonile
ning edastab Täitjale tööülesanded leitud Vigadest. Täitja arendaja parandab
testija leitud Vead.
10
7.4.3.4. Arendusetapi lõpus esitab Täitja realiseeritud ja testitud komponendid
Tellijale Testkeskkonda testimiseks. Arendusetapi Tööde tulemi
Tellijapoolseks testimise hõlbustamiseks esitab Täitja ka Tööde etapi
aruande, milles täpsustatakse tehtud Tööde loetelu.
7.4.3.5. Tellija testib komponendid ning edastab Vead Tööülesannete
halduskeskkonna kaudu mõistliku aja jooksul alates arendustarne
kättesaamisest või Töö tulemite Tellijale vastuvõtmiseks esitamisest.
Eeldatakse, et mõistlik aeg testimiseks on Tööde etappide puhul 5 tööpäeva
alates arendustarne kätte saamisest ning kõikide Tööde lõpliku üleandmise
puhul 20 tööpäeva alates Täitja poolt Töö tulemite Tellijale vastuvõtmiseks
esitamisest. Põhjendatud vajaduse korral teavitab Tellija Täitjat vajadusest
võtta testimiseks eeldatust pikem ajaperiood.
7.4.3.6. Täitja eesmärgiks on kõrvaldada Tellija õigeaegselt raporteeritud Vead
järgmiseks arenduse tarneks.
7.4.3.7. Pärast Vigade parandust ning paranduste Täitjapoolset ületestimist tarnib
Täitja Tööd uuesti Testkeskkonda ning Tellija kordab testimist.
7.4.3.8. Tellijal on alates teisest kordustestimisest õigus nõuda Täitjalt
kordustestidega seotud kulutuste (Tellija kulutatud tööaeg ja/või Tellija
testimispartnerite poolt esitatud arvete alusel) hüvitamist.
7.4.3.9. Kui täitja annab vigade parandamise järgselt üle tööd, milles Tellija
vastuvõtutestimise käigus esineb jätkuvalt Vigu (teistkordne vigadega tööde
üleandmine), võib Tellija otsustada, kas anda Täitjale uus tähtaeg Vigade
parandamiseks või kõrvaldada Vead ise või Kolmanda isiku kaasabil,
vähendades Täitjale makstavat tasu Vigade parandamiseks tehtud kulutustega
või nõudes vastavad kulud eraldi Täitjalt sisse.
7.5. Täiendusvajaduste realiseerimine
7.5.1. Tellija esitab Täitjale Tööülesannete halduskeskkonnas soovi parandada või
täiendada olemasolevat komponenti/funktsionaalsust või luua täiendav
komponent või funktsionaalsus.
7.5.2. Täitja analüüsib Tellija soovi ning selgitab välja, kas tegemist on
Täiendusvajadusega, ning teavitab sellest Tellija projektijuhti, vajadusel
esitades Tellijale täpsustavad küsimused.
7.5.3. Tellija vastab Täitja täpsustavatele küsimustele ning vajadusel täiendab või
muudab oma soovi.
7.5.4. Täitja esitab Tellijale oma hinnangu Täiendusvajaduse realiseerimise mahu,
tähtaegade ja maksumuse osas. Kui tegemist on Täiendusvajadusega Projekti
keskel, annab Täitja hinnangu, milliseid ressursse ja millises mahus on vajalik
muudatuste sissearvestamiseks ümber hinnata ning millised on muudatused
Tööde teostamise tähtaegades.
7.5.5. Tellija teeb otsuse Täiendusvajaduse realiseerimise osas vastavalt Täitja
esitatud tingimustele.
11
7.5.6. Kui Tellija loobub mõnest Tööst, mis oli esialgses Tööde mahus
kokkulepitud, siis kas vähendatakse Lepingu maksumust nende Tööde
maksumuse võrra või, alternatiivselt, teostatakse nende Tööde jaoks
planeeritud töötundide raames skoobiväliseid täiendavaid töid. Vastava
muudatuse kokkuleppimisel tuleb lähtuda riigihangete seaduses sätestatud
tingimustest.
8. TÖÖDE ÜLEANDMINE, VIGADE KÕRVALDAMINE
8.1. Täitja annab Tööd üle hiljemalt Hankelepingus sätestatud tähtaegadel ja tingimustel.
Koos Töödega antakse üle nõuetekohane dokumentatsioon, kommenteeritud lähtekood,
intellektuaalomandi õigused ja muu Hankelepingus kokkulepitu.
8.2. Analüüsitööde vastavuse hindamisel kontrollib Tellija, kas dokumenteeritud lahendus
vastab Hankelepingule ja analüüsiprotsessi käigus Tellija poolt antud sisenditele.
Vajadusel täpsustab Tellija Spetsifikatsioonis kirjeldatut, andes Täitjale tagasisidet.
8.3. Arendustööde vastavust nõuetele hinnatakse Tööde testimisel kokkulepitud
Testkeskkonnas vastavalt eelmises Lepingu peatükis sätestatud tingimustele.
Arendustööde vastavuse hindamisel lähtutakse Hankelepingus ning Spetsifikatsioonis
kokku lepitud ülesandepüstitusest. Spetsifikatsioonis ja Hankelepingus esineva vastuolu
korral lähtutakse hilisemast kokkuleppest ehk Spetsifikatsioonist.
8.4. Tellija võib Töö ülevaatamisele kaasata ja selleks kasutada kolmandaid isikuid,
kusjuures nii Tellijal kui ka tema poolt kaasatud kolmandatel isikutel on õigus täiendava
tasu maksmiseta Töö või selle vahetulemuse ülevaatamiseks kasutada kõiki selleks
vajalikke Tööga või selle vahetulemusega seotud Intellektuaalse omandi õigusi.
8.5. Tööde vastuvõtmine fikseeritakse Aktiga. Viimase Tööde etapi lõpus esitab Täitja
allkirjastamiseks Koondakti, millega peab olema hõlmatud kogu Hankelepingu ese (sh
iga Tööde etapi lõpus üle antud Tööd).
8.6. Täitja annab Tööd üle omalt poolt allkirjastatud Aktiga. Hooldustööde teostamisel tuleb
koos Aktiga esitada ajaaruanne. Sõltuvalt Hankelepingu esemest, peavad tehtud
analüüsi -, hooldus- ja arendustööd olema Aktis teineteisest eristatud.
8.7. Tellija võtab Tööd vastu Akti allkirjastamisega pärast Tööde nõuetekohasuse
kontrollimist või edukat vastuvõtutestimist. Tööde etappide üleandmine ja
vastuvõtmine vormistatakse Aktiga ning Projekti lõplik üleandmine ja vastuvõtmine
vormistatakse Koondaktiga. Tööd loetakse nõuetekohaselt teostatuks, kui Tööd
vastavad Hankelepingule, (asjakohasel juhul) vastuvõtutestid on Vigadeta läbitud ja
Tööd on Aktiga Tellija poolt vastu võetud.
8.8. Tellijal on õigus võtta Töid vastu ka osaliselt ning koos vaegtöödega.
8.9. Tellija teavitab Täitjat Töös või selle Tulemis esinevatest Vigadest, iseloomust ja
ulatusest viivitamatult nende ilmnemisel, kirjeldades leitud vead enda muudatuste- ja
vigade halduskeskkonnas ning määrates Vea kriitilisuse astme.
8.10. Vastavalt Tellija poolt määratletud Vea kriitilisuse astmele peab Täitja kuni Tööde
lõpliku üleandmiseni ning Garantii perioodi jooksul kõrvaldama enda kulul Vead
järgmiste tähtaegade jooksul:
12
8.10.1. Kriitilise taseme viga - lahendus tervikuna mitte-ligipääsetav või kasutatav
tulenevalt tarkvaralisest tõrkest, kõigi kasutajate töö süsteemis on võimatu:
lahendamine 4 tunni jooksul (tööpäevadel kell 9.00-17.00) alates Tellija poolt
tõrke teate esitamisest;
8.10.2. Keskmise taseme viga - mõni tarkvara süsteemi funktsionaalsus ei toimi
ettenähtud moel, ühe osakonna/kasutajate grupi töö on häiritud: lahendamine
2 tööpäeva jooksul alates Tellija poolt tõrke teate esitamisest;
8.10.3. Madala taseme viga - tarkvara süsteem kasutatav, kasutajate töö mugavus
langenud, kuid mitte häiritud või võimatu: lahendamine 10 tööpäeva jooksul
alates Tellija poolt tõrke teate esitamisest või vastavalt kokkuleppele
Tellijaga.
9. GARANTII
9.1. Täitja annab hankelepingu alusel teostatud töödele garantii 12 kuud. Garantii hakkab
kehtima hetkest, millal tellija võtab töö toodangukeskkonnas kasutusele. Kui Tellija ei
võta tööd toodangukeskkonnas kasutusele 3 kuu möödumisel alates tööde
vastuvõtmisest, algab garantii nimetatud aja möödumisel. Kui arendustöö teostatakse ja
võetakse vastu etappidena, algab lisaks eeltoodule tööle kui tervikule 12-kuuline
garantii tervikliku töö toodangus kasutuselevõtmisest või toodangukeskkonnas
kasutusele võtmata jätmisel 3 kuu möödumisel alates tervikliku töö vastuvõtmisest.
9.2. Garantiiga ei ole hõlmatud:
9.2.1. ekspluatatsioonihäirete kõrvaldamine, mis on põhjustatud Tellija või tema
poolt kasutatava kolmanda isiku poolt juhuslikust või tahtlikust Tarkvara
kahjustamisest või ebaõigest kasutamisest;
9.2.2. Vead, mis on tingitud Tarkvara kasutamisest vastuolus Täitja koostatud ja
Tellija poolt vastu võetud dokumentatsiooniga;
9.2.3. probleemid, mis tulenevad Tellija kasutajate andmesisestusvigadest või
liidestatud süsteemide sisenditest, vaatamata sellele, et Täitja on
nõuetekohaselt rakendanud sisendikontrolli;
9.2.4. seotud süsteemide liideste kooskõlastamata muudatusest tulenevad
funktsionaalsed häired ja andmekvaliteedi probleemid;
9.3. Garantiiperioodil ilmnenud Garantiiga hõlmatud Vead kõrvaldab Täitja tasuta vastavalt
Lepingu punktis 8.10 sätestatud tähtaegadele.
9.4. Kui Täitja ei suuda Vigu kokkulepitud tähtajaks kõrvaldada, võib Tellija korraldada
Vigade kõrvaldamise kolmanda isiku abil, teavitades sellest eelnevalt Täitjat. Tellijal on
õigus nõuda, et Täitja katab mõistlikud kulud, mis tekkisid seoses kolmanda isiku
kaasamisega Vea kõrvaldamisse juhul, kui Tellija tõendab, et tegemist oli garantiiga
hõlmatud Veaga. Kolmanda isiku poolt tehtud koodimuudatuste garantiikohustus lasub
nimetatud kolmandal isikul, v.a juhul kui Pooled on kokku leppinud teisiti.
9.5. Kui Viga ei kuulu garantii korras kõrvaldamisele, esitab Täitja Tellijale põhjendused
kirjalikus vormis viivitamatult, kuid mitte hiljem kui järgmisel tööpäeval pärast sellest
asjaolust teada saamist.
13
9.6. Kui Poolte vahel tekib vaidlus Vea üle, lepivad Pooled kokku sõltumatu ekspertiisi
tellimises. Pooled on kohustatud tagama eksperdi nõudmisel ligipääsu vajalikele
andmetele või informatsioonile. Ekspertiisikulud kannab Pool, kes ekspertiisiakti
kohaselt Vea garantiilisuse hindamisel eksis.
9.7. Garantii kaotab kehtivuse, kui Täitjaga kooskõlastamata on muudetud või muudetakse
lähtekoodi (v.a Lepingus sätestatud viisil kolmanda isiku kaasamisel Vea
kõrvaldamisse. Samuti ei kaota garantii kehtivust, kui Tellija suudab eristada
lähtekoodis tehtavaid muudatusi.).
10. INTELLEKTUAALSE OMANDI ÕIGUSED
10.1. Vabavaralitsentsi mudel:
Kui Lepingu põhitingimuste järgi on kasutusel VABAVARALITSENTSI MUDEL, siis
kohaldatakse Lepingus intellektuaalse omandi õigustele järgmisi sätteid:
Kasutusala: Varemsoetatud tarkvara puhul on EUPL juba kasutusel ning
jätkuarenduste osas soovitakse sama mudeliga jätkata (alternatiiviks on ka jätkamine
ühilduvate mudelite alusel) VÕI Kui alustatakse tarkvara loomist, kuid soov on
kasutada EUPLi litsentsimudelit.
10.1.1. Lepingu allkirjastamisega kinnitavad Pooled, et neile kuuluvad Lepingu
täitmiseks vajalikud varalised autoriõigused, litsentsid ja muud
intellektuaalse omandi õigused, mis on tarvilikud Lepingujärgse Töö
täielikuks teostamiseks ja loovutamiseks käesolevas peatükis toodud ulatuses
ning, et nende suhtes ei ole kolmandatel isikutel nõudeid. Pooled kinnitavad,
et on võtnud tarvitusele kõik meetmed autori isiklike õiguste realiseerimiseks
viisil, mis ei takista ega raskenda teose kasutamist ja autori varaliste õiguste
teostamist.
10.1.2. Pool kohustub lahendama kõikvõimalikud litsentseeritud või vahendatud
Tarkvaraga seotud Intellektuaalse omandi õigustest tekkivad vaidlused
kolmandate isikute või oma töötajate või koostööpartneritega. Juhul kui
Täitjapoolsetest litsentseerimisvigadest tulenevalt tekib Tellijale rahaline või
muu kohustus või kui Tellija on kohustatud lõpetama Tarkvara kasutamise,
on Tellijal õigus nõuda Täitjalt selle rahalise või muu kohustuse täitmist ja
või kaotatud Tarkvaraga samaväärse tulemi loomist tasuta ja võimalikult
lühikese aja jooksul, hoidudes mistahes viivitustest tulemi arendamises ja
kasutuselevõtmises Tellija poolt.
Jätkuarenduse korral lisada:
Lepingu allkirjastamisel annab Tellija Täitjale Tarkvara edasiarendamiseks,
vastavalt Tellijaga kokkulepitule, Euroopa Liidu tarkvara vaba kasutuse
litsentsi v.1.1 (EUPL).
10.1.3. Täitja annab Tööle Euroopa Liidu tarkvara vaba kasutuse litsentsi v.1.1
(EUPL).
10.1.4. Tellijal on muuhulgas õigus Töö autoriõiguste kehtivusaja jooksul:
10.1.4.1. Tööd kasutada mis tahes eesmärgil ja mis tahes viisil;
10.1.4.2. Tööd reprodutseerida;
10.1.4.3. originaalteost muuta ja luua teosel põhinevaid tuletatud teoseid;
14
10.1.4.4. Tööd või selle koopiaid üldsusele edastada, sealhulgas neid kättesaadavaks
teha või eksponeerida, samuti avalikult esitada;
10.1.4.5. Tööd või selle koopiaid levitada;
10.1.4.6. Tööd või selle koopiaid laenutada ja rentida;
10.1.4.7. anda all-litsentse Töö või selle koopiate suhtes kehtivate õiguste kohta.
10.1.5. Tellija võib Töö autoriõigusi teostada mistahes olemasolevas või hiljem
loodud keskkonnas, toel või formaadis.
10.1.6. Täitja annab Tellijale vastavalt valdkonnas kehtivatele parimatele
praktikatele dokumenteeritud lähtekoodi.
10.1.7. Tellija viitab Täitjale kui Töö autorile. Tellija ei tohi eemaldada autoriõiguse
märkeid, kui neid esineb lähtekoodis, mida kasutatakse tuletatud Teose
kirjutamisel.
10.1.8. Nimetatud õigused kehtivad kogu autoriõiguste kehtivuse aja ja nende
kehtivuse territooriumiks on kogu maailm.
10.1.9. Litsents loetakse antuks Töö või selle Etapi vastuvõtmise hetkest.
10.1.10. Täitja tagab Tellijale kõik vajalikud autoriõigused Lepingu täitmise käigus
loodava tarkvara kontrollimiseks, testimiseks ning süsteemi paigutamiseks
ajaks, kuni Tellija ei ole üleandmise-vastuvõtmise aktiga Lepingu eset vastu
võtnud. Käesolevas peatükis sätestatud autoriõigused lähevad Tellijale üle
Töö või selle Etapi vastuvõtmise hetkest.
10.1.11. Kommertstarkvara kasutamine:
10.1.11.1. Lepingu täitmisel Kommertstarkvara kasutamise osas juhinduvad Pooled
nende kasutamise litsentsitingimustest. Täitja kinnitab, et eelistab tarkvara
loomisel sellist Kommertstarkvara, mille litsentsimudelid ühilduvad
EUPLiga või on kasutatavad koostoimes EUPLi alusel litsentseeritud
tarkvaraga vastavalt EUPLi rakendusjuhistele;
10.1.11.2. Täitja võib kasutada tarkvara loomisel Kommertstarkvara vaid Tellija
eelneval kirjalikul nõusolekul ning tagades nende Kommertstarkvara
komponentide kasutuselevõtmise vastavalt EUPLi rakendamise nõuetele.
Kirjaliku nõusoleku taotlemisel on Täitja kohustatud esitama Tellijale
litsentsi hinna, litsentsitingimused ja andmed lähtekoodi kättesaamise
võimaluse kohta.
10.1.11.3. Tasu Intellektuaalse omandi õiguste Tellijale ülemineku ja litsentside eest
sisaldub Lepingu maksumuses ning Täitjal ei ole õigust nõuda täiendavat
tasu nende õiguste üleandmise ega litsentsimise eest (sh Lepingu
sõlmimise ajal tundmatute kasutusviiside lubamise eest tulevikus).
10.2. Omandamismudel:
Kui Lepingu põhitingimuste järgi on kasutusel OMANDAMISMUDEL, siis
kohaldatakse Lepingus intellektuaalse omandi õigustele järgmisi sätteid:
15
Kasutusala: Tarkvaralahenduse puhul on tegemist riigi infosüsteemi
baaskomponendiga või tarkvara on oluline riigikaitselistel, sisejulgeoleku või
küberturbe põhjustel, mistõttu on riigil huvi omada tarkvara koopiate levitamise üle
maksimaalset kontrolli kasutades seetõttu tarkvara soetamisel IO õiguste omandamise
mudelit (isiklike õiguste ainulitsents ja varaliste õiguste omandamine). Samuti juhul,
kui loodava tarkvara alusplatvorm on omanduslik ehk kommertstarkvara või tarkvara
sisaldab kommertstarkvara komponente, mille osas tuleb juhinduda tarkvara
intellektuaalse omandi õiguste omaniku poolt kasutatavatest tarkvara
litsentsitingimustest. Tarkvara loomisel tehtud kohandustele (spetsiaaltarkvara
komponentidele) aga rakendatakse ainulitsentsi, mis tagab riigile maksimaalse
kontrolli spetsiaaltarkvara komponentide ning ka loodud terviklahenduse koopiate
levitamise üle.
10.2.1. Lepingu allkirjastamisega kinnitavad Pooled, et neile kuuluvad Lepingu
täitmiseks vajalikud varalised autoriõigused, litsentsid ja muud
intellektuaalse omandi õigused, mis on tarvilikud Lepingujärgse Töö
täielikuks teostamiseks ja loovutamiseks käesolevas peatükis toodud ulatuses
ning, et nende suhtes ei ole kolmandatel isikutel nõudeid. Pooled kinnitavad,
et on võtnud tarvitusele kõik meetmed autori isiklike õiguste realiseerimiseks
viisil, mis ei takista ega raskenda teose kasutamist ja autori varaliste õiguste
teostamist.
10.2.2. Pool kohustub lahendama kõikvõimalikud litsentseeritud või vahendatud
Tarkvaraga seotud Intellektuaalse omandi õigustest tekkivad vaidlused
kolmandate isikute või oma töötajate või koostööpartneritega. Juhul kui
Täitjapoolsetest litsentseerimisvigadest tulenevalt tekib Tellijale rahaline või
muu kohustus või kui Tellija on kohustatud lõpetama Tarkvara kasutamise,
on Tellijal õigus nõuda Täitjalt selle rahalise või muu kohustuse täitmist ja
või kaotatud Tarkvaraga samaväärse tulemi loomist tasuta ja võimalikult
lühikese aja jooksul, hoidudes mistahes viivitustest tulemi arendamises ja
kasutuselevõtmises Tellija poolt.
Jätkuarenduse korral lisada:
Lepingu allkirjastamisel annab Tellija Täitjale Tarkvara edasiarendamiseks
lihtlitsentsi Tarkvara varaliste õiguste kasutamiseks Tellijaga kokkulepitud
tööde teostamiseks ning Tellijale käesolevas jaos sätestatud tingimustel
tehtud Tööde tagasi litsentsimiseks.
10.2.3. Tööde autori varalised õigused lähevad üle Tellijale Töö või selle Etapi
vastuvõtmise hetkest.
10.2.4. Täitja annab Tellijale autori isikliku litsentsi ulatuses, mis võimaldab täiel
määral kasutada üle antud varalisi õigusi.
10.2.5. Täitja annab Tellijale tehtud Tööde osas ainulitsentsi autori isiklikele
õigustele koos all-litsentsi andmise õigusega Tööde või selle Etapi
vastuvõtmise hetkest. Nimetatud õigused kehtivad kogu autoriõiguste
kehtivuse aja ja nende kehtivuse territooriumiks on kogu maailm.
10.2.6. Täitja tagab Tellijale kõik vajalikud autoriõigused Lepingu täitmise käigus
loodava Tarkvara kontrollimiseks, testimiseks ning süsteemi paigutamiseks
ajaks, kuni Tellija ei ole üleandmise-vastuvõtmise aktiga lepingu eset vastu
võtnud.
16
10.2.7. Garantiiperioodi kehtivuse ajaks annab Tellija Täitjale üleilmse lihtlitsentsi
Tarkvara varaliste õiguste kasutamiseks Tellijaga kokkulepitud Tööde
teostamiseks ning Tellijale käesolevas jaos sätestatud tingimustel tuletatud
Teoste tagasi litsentsimiseks.
10.2.8. Täitja annab Tellijale vastavalt valdkonnas kehtivatele parimatele
praktikatele dokumenteeritud lähtekoodi.
10.2.9. Tellija võib Töö autoriõigusi teostada mistahes olemasolevas või hiljem
loodud keskkonnas, toel või formaadis.
10.2.10. Kommertstarkvara kasutamine:
10.2.10.1. Lepingu täitmisel Kommertstarkvara kasutamise osas juhinduvad Pooled
nende kasutamise litsentsitingimustest. Täitja kinnitab, et eelistab tarkvara
loomisel sellist Kommertstarkvara, mille kasutamine ei too Tellijale kaasa
täiendavaid litsentsitasusid või piiranguid tarkvara kasutamisel (v.a juhul,
kui nimetatud Kommertstarkvara kasutamine oli ette nähtud Täitja
hankepakkumuses);
10.2.10.2. Täitja võib kasutada tarkvara loomisel pakkumuses mittenimetatud
Kommertstarkvara vaid Tellija eelneval kirjalikul nõusolekul. Kirjaliku
nõusoleku taotlemisel on Täitja kohustatud esitama Tellijale litsentsi
hinna, litsentsitingimused ja andmed lähtekoodi kättesaamise võimaluse
kohta;
10.2.10.3. Tasu Intellektuaalse omandi õiguste Tellijale ülemineku ja litsentside eest
sisaldub Lepingu maksumuses ning Täitjal ei ole õigust nõuda täiendavat
tasu nende õiguste üleandmise ega litsentsimise eest (sh Lepingu
sõlmimise ajal tundmatute kasutusviiside lubamise eest tulevikus).
10.3. Lihtlitsentsi mudel:
Kui Lepingu põhitingimuste järgi on kasutusel LIHTLITSENTSI MUDEL, siis
kohaldatakse Lepingus intellektuaalse omandi õigustele järgmisi sätteid:
Kasutusala: Tarkvaralahenduse puhul ei ole piiranguid litsentseerimise osas (näiteks ei
ole varasemat tarkvara versiooni litsentseeritud kasutades copyleft nõudega
litsentsimudelit, mis dikteerib seda, milliseid litsentsimudeleid edaspidi tuletatud teoste
osas kasutada saab) ja tegemist ei ole riigi baaskomponendiga ega tarkvaraga mille
levitamise osas peaks riigil olema maksimaalne kontroll riigikaitselistel, sisejulgeoleku
või küberturbe põhjustel. Sellisel tarkvara soetamisel peab riik eelistama
litsentsimudelit, mis tagab riigile kõik vajalikud õigused tarkvara kasutamiseks ja
levitamiseks (s.h. tuletatud teoste loomiseks, all-litsentside andmiseks või müümiseks),
kuid jätab ka tarkvara loojale vajalikud õigused alles, et tarkvara või selle
alamkomponentidega seotud edasisi ärivõimalusi realiseerida.
Järgnev litsentsimudel sobib kasutamiseks ka juhul, kui loodava tarkvara alusplatvorm
on omanduslik ehk kommertstarkvara või Tarkvara sisaldab kommertstarkvara
komponente, mille osas tuleb juhinduda tarkvara intellektuaalse omandi õiguste
omaniku poolt kasutatavatest tarkvara litsentsitingimustest. Tarkvara loomisel tehtud
kohandustele (spetsiaaltarkvara komponentidele) aga rakendatakse lihtlitsentsi, mis
tagab riigile kõik vajalikud õigused kohandatud tarkvara osade kasutamiseks ja
levitamiseks.
17
10.3.1. Lepingu allkirjastamisega kinnitavad Pooled, et neile kuuluvad Lepingu
täitmiseks vajalikud varalised autoriõigused, litsentsid ja muud
intellektuaalse omandi õigused, mis on tarvilikud Lepingujärgse Töö
täielikuks teostamiseks ja loovutamiseks käesolevas peatükis toodud ulatuses
ning, et nende suhtes ei ole kolmandatel isikutel nõudeid. Pooled kinnitavad,
et on võtnud tarvitusele kõik meetmed autori isiklike õiguste realiseerimiseks
viisil, mis ei takista ega raskenda teose kasutamist ja autori varaliste õiguste
teostamist.
10.3.2. Pool kohustub lahendama kõikvõimalikud litsentseeritud või vahendatud
Tarkvaraga seotud Intellektuaalse omandi õigustest tekkivad vaidlused
kolmandate isikute või oma töötajate või koostööpartneritega. Juhul kui
Täitjapoolsetest litsentseerimisvigadest tulenevalt tekib Tellijale rahaline või
muu kohustus või kui Tellija on kohustatud lõpetama Tarkvara kasutamise,
on Tellijal õigus nõuda Täitjalt selle rahalise või muu kohustuse täitmist ja
või kaotatud Tarkvaraga samaväärse tulemi loomist tasuta ja võimalikult
lühikese aja jooksul, hoidudes mistahes viivitustest tulemi arendamises ja
kasutuselevõtmises Tellija poolt.
Jätkuarenduse korral lisada:
Lepingu allkirjastamisel annab Tellija Täitjale Tarkvara edasiarendamiseks
lihtlitsentsi Tarkvara varaliste õiguste kasutamiseks Tellijaga kokkulepitud
tööde teostamiseks ning Tellijale käesolevas jaos sätestatud tingimustel
tehtud Tööde tagasi litsentsimiseks.
10.3.3. Täitja annab Tellijale tehtud Tööde osas autoriõiguse seaduse tähenduses
ülemaailmse tagasivõtmatu lihtlitsentsi kõikide varaliste ja isiklike õiguste
suhtes Tööle nende autoriõiguste kehtivuse tähtajaks alljärgnevatel
tingimustel:
10.3.3.1. Tööd kasutada mis tahes eesmärgil ja mis tahes viisil;
10.3.3.2. Tööd reprodutseerida (s.h. tasuta jagada, avalikult kättesaadavaks teha või
müüa);
10.3.3.3. Ise või kolmandaid isikuid kaasates Teost muuta ja luua Teosel põhinevaid
tuletatud teoseid;
10.3.3.4. Tööd üldsusele edastada, sealhulgas neid (üldsusele) kättesaadavaks teha
(sh internetis) või eksponeerida, samuti avalikult esitada;
10.3.3.5. Tööd laenutada ja rentida;
10.3.3.6. Anda all-litsentse tehtud Töö või selle koopiate suhtes kehtivate õiguste
kohta.
10.3.4. Täitja annab Tellijale vastavalt valdkonnas kehtivatele parimatele
praktikatele dokumenteeritud lähtekoodi.
10.3.5. Tellija viitab Täitjale kui Töö autorile, kuid Tellija ei taga, et kolmandad
isikud (sh riigiasutused, kes kasutavad Tööd) viitavad Täitjale kui Töö
autorile. Tellija ei vastuta eeltoodud isikute Täitjale viitamata jätmise eest.
10.3.6. Tellija võib Teose autoriõigusi teostada mistahes olemasolevas või hiljem
loodud keskkonnas, toel või formaadis.
10.3.7. Litsents loetakse antuks Töö või selle Etapi vastuvõtmise hetkest.
18
10.3.8. Täitja tagab Tellijale kõik vajalikud autoriõigused Lepingu täitmise käigus
loodava Tarkvara kontrollimiseks, testimiseks ning süsteemi paigutamiseks
ajaks, kuni Tellija ei ole üleandmise-vastuvõtmise aktiga lepingu eset vastu
võtnud.
10.3.9. Kommertstarkvara kasutamine:
10.3.9.1. Lepingu täitmisel Kommertstarkvara kasutamise osas juhinduvad Pooled
nende kasutamise litsentsitingimustest. Täitja kinnitab, et eelistab tarkvara
loomisel sellist Kommertstarkvara, mille kasutamine ei too Tellijale kaasa
täiendavaid litsentsitasusid või piiranguid tarkvara kasutamisel (v.a juhul,
kui nimetatud Kommertstarkvara kasutamine oli ette nähtud Täitja
hankepakkumuses);
10.3.9.2. Täitja võib kasutada tarkvara loomisel pakkumuses mittenimetatud
Kommertstarkvara vaid Tellija eelneval kirjalikul nõusolekul. Kirjaliku
nõusoleku taotlemisel on Täitja kohustatud esitama Tellijale litsentsi
hinna, litsentsitingimused ja andmed lähtekoodi kättesaamise võimaluse
kohta;
10.3.9.3. Tasu Intellektuaalse omandi õiguste ja litsentside eest sisaldub Lepingu
maksumuses ning Täitjal ei ole õigust nõuda täiendavat tasu nende õiguste
üleandmise ega litsentsimise eest (sh Lepingu sõlmimise ajal tundmatute
kasutusviiside lubamise eest tulevikus).
11. OMANDIÕIGUSE ÜLEMINEK
11.1. Kui Töö sisaldab Täitja poolt Tellijale üleantavaid asju, siis läheb asja omandiõigus
Täitjalt Tellijale üle vastavat asja sisaldava Töö vastuvõtmise või vastavalt
Hankelepingule vastuvõetuks lugemise hetkest.
12. KONFIDENTSIAALSUS
12.1. Konfidentsiaalne on muu hulgas järgmine informatsioon (olenemata sellest, kas see on
esitatud konkreetses või nähtavas vormis, andmekandjal või suuliselt):
12.1.1. Poolega mistahes viisil seotud avalik-õiguslike ja eraõiguslike füüsiliste ja
juriidiliste isikute, sh Poole töötajate ja nende tegevusega seotud info,
tehnilised andmed, muud andmed, lepingud, finantsandmed ja
raamatupidamise näitajad, teenuste ja kaupade hinnakujundus, Poole
kasutatav infotehnoloogia ja materjalid, spetsifikatsioonid, joonised,
informatsioon, mis puudutab Poole poolt teostatud arendustööd ja
oskusteavet, Poole asutusesiseseks kasutamiseks tunnistatud teave,
riigisaladuseks tunnistatud teave, info teise poole omaniku ja juhtorganite
tegevuse, lepingute sõlmimise, lõppemise ja läbirääkimiste kohta ning muu
teave (sh ärisaladused), mis ei ole kolmandatele isikutele õiguspäraselt
konfidentsiaalsuskohustuseta kättesaadavad ning on Poolele teatavaks saanud
Lepingu või Poolte vahel sõlmitud muu kokkuleppe ettevalmistamise,
täitmise või rikkumise tõttu;
19
12.1.2. informatsioon, millel on märge „konfidentsiaalne” või mille
konfidentsiaalsust nõuab seadus või mille kohta on Pool teatanud, et tegemist
on konfidentsiaalse informatsiooniga või mille kohta Pool peaks põhjendatult
arvama, et teine pool peab seda konfidentsiaalseks.
12.2. Pool ei avalda konfidentsiaalset informatsiooni kolmandatele isikutele ning teeb kõik
endast oleneva, et talle avaldatud konfidentsiaalne informatsioon ei satuks kolmandate
isikute valdusesse. Konfidentsiaalse informatsiooni avaldamine kolmandatele isikutele
võib toimuda ainult seaduses otseselt ettenähtud juhtudel või Poole eelneval kirjalikul
nõusolekul või kui see on vajalik Lepingust tulenevate õiguste või kohustuste
teostamiseks. Pool peab tagama, et Lepingus kokkulepitud konfidentsiaalsuskohustus
laieneb kõigile Lepingu täitmisesse kaasatud isikutele. Konfidentsiaalsusnõue ei laiene
Poolte pankadele, advokaatidele, audiitoritele ja teistele isikutele, kelle kohaldub
õigusaktidest tulenev konfidentsiaalsuskohustus.
12.3. Pool kohustub kasutama konfidentsiaalset informatsiooni ainult Lepingu eesmärkide
täitmiseks. Konfidentsiaalsuskohustuse rikkumine ei ole õigusaktides ettenähtud
juhtudel Lepingut puudutava informatsiooni avaldamine selleks õigustatud riigi- ja
valitsusasutustele. Poolel on õigus avaldada konfidentsiaalset informatsiooni seadusliku
aluse või Poole eelneva kirjaliku nõusoleku puhul üksnes ulatuses, mida on vaja Poolte
vahel sõlmitud Lepingust tulenevate õiguste kohustuste täitmiseks.
12.4. Konfidentsiaalset informatsiooni, mis saab Poolele teatavaks elektrooniliselt või muul
viisil kirjalikku taasesitamist võimaldavas vormis, võib salvestada, paljundada või
(elektrooniliselt) kopeerida ainult Lepingus fikseeritud eesmärkide täitmiseks.
12.5. Konfidentsiaalsuskohustuse kehtib tähtajatult ka pärast Lepingu lõppemist.
13. VASTUTUS
13.1. Pool vastutab enda Lepingust tulenevate kohustuste rikkumise ja selle tagajärgede eest
vastavalt seadusele, välja arvatud juhul, kui rikkumine on vastavalt seadusele
vabandatav (st vääramatu jõu tõttu). Pool kohustub vääramatu jõu asjaolust teist Poolt
viivitamatult teavitama.
13.2. Juhul, kui Töövõtja viivitab mõne Töö etapi või kogu Töö üleandmisega üle
kokkulepitud tähtaja, on Tellijal õigus nõuda Töövõtjalt leppetrahvi, mille suuruseks on
0,5% vastava Töö etapi või Töö kogumaksumusest iga viivitatud päeva eest kuni selle
nõuetekohase üleandmiseni, kuid mitte rohkem kui Töö vastava etapi või kogu Töö
maksumus.
13.3. Kui tegemist on Töövõtjapoolse olulise rikkumisega, on Tellijal õigus nõuda ühekordse
leppetrahvi tasumist summas kuni 10 000 eurot iga sellise rikkumise eest. Tellija
käsitleb Lepingu olulise rikkumisena lisaks seaduses sätestatule järgmisi Täitja
rikkumisi:
13.3.1. Täitja ei täida mistahes Lepingust tulenevat kohustust ega kõrvalda rikkumist
Tellija poolt antud täiendava mõistliku tähtaja jooksul;
13.3.2. kui Täitjal puuduvad Lepingu täitmiseks vajalikud õigused (sealhulgas load,
litsentsid, Intellektuaalse omandi õigused jne);
13.3.3. Täitja rikub konfidentsiaalsuskohustust;
13.3.4. Täitja on kaasanud Lepingu täitmisesse isikuid, kes pole pakkumuses
nimetatud või Tellija poolt eelnevalt kooskõlastatud;
20
13.3.5. kui Täitja annab oma ettevõtte või selle osa koos Lepinguga üle Tellija
eelneva nõusolekuta.
13.3.6. Lepingujärgsete kohustuste korduv (vähemalt kahel korral) täitmata jätmine;
13.3.7. Lepingus sätestatud tähtaegade rikkumine või sedavõrd aeglane Töö
teostamine, et on ilmne, et Töö tähtaegne valmimine ei ole enam realistlik
ja/või Täitja poolse tegevuse või tegevusetuse tõttu ei ole võimalik enam
kasutada Hankelepingu rahastamiseks ettenähtud vahendeid.
13.4. Kui leppetrahvi nõudes ei ole määratud teisiti, tasub Täitja Tellija poolt nõutava
leppetrahvi 14 päeva jooksul Tellija poolt vastava nõude esitamisest.
13.5. Leppetrahvi nõudmine ei võta Tellijalt õigust rakendada Täitja rikkumise vastu ka kõiki
teisi seadusest tulenevaid õiguskaitsevahendeid. Tellija võib nõuda leppetrahvi
sõltumata rikkumisega tekitatud kahju olemasolust või selle suurusest ning leppetrahvi
nõudmise korral on Tellijal õigus nõuda lisaks ka kogu rikkumisega tekitatud kahju
hüvitamist.
13.6. Tellija kaotab õiguse leppetrahvi nõudmiseks, kui ta ei teavita Täitjat kavatsusest nõuda
rikkumise suhtes leppetrahvi mõistliku aja jooksul pärast rikkumisest teadasaamist.
Pooled on kokku leppinud, et mõistlik aeg teavitamiseks on kuni 6 kuud rikkumisest
teadasaamisest.
13.7. Tellijal on õigus tasaarvestada kõik enda rahalised nõuded Täitja vastu Täitja Lepingust
tulenevate tasunõuetega.
14. LEPINGU KEHTIVUS
14.1. Leping jõustub sõlmimisel või Lepingus sätestatud muul kuupäeval.
14.2. Leping lõpeb Lepinguliste kohustuste täitmisega, Lepingu lõpetamise kokkuleppe
sõlmimisega, Lepingus või seaduses sätestatud muul alusel.
14.3. Tellijal on õigus Leping üles öelda järgmistel juhtudel:
14.3.1. 90 päevase etteteatamistähtajaga igal ajal sõltumata põhjusest;
14.3.2. etteteatamistähtaega järgimata, kui Täitja paneb toime Lepingu olulise
rikkumise Lepingu eelmises peatükis sätestatud tähenduses;
14.3.3. etteteatamistähtaega järgimata, kui Täitja suhtes on algatatud
pankrotimenetlus või Täitja pankrot on välja kuulutatud;
14.3.4. etteteatamistähtaega järgimata, kui Täitja varad arestitakse; või
14.3.5. Täitja finantsseisund halveneb Tellija põhjendatud hinnangul oluliselt ja see
halvenemine muudab vähetõenäoliseks Lepingu nõuetekohase täitmise.
14.4. Lisaks eelmises punktis sätestatud alustele on Tellijal õigus Raamleping üles öelda, kui
Täitja ei ole Raamlepingu kehtivuse ajal esitanud pakkumust vähemalt 2-le Tellija poolt
Raamlepingu alusel esitatud tellimusele.
14.5. Täitjal on õigus Leping üles öelda üksnes juhul, kui Tellija on Lepingut oluliselt
rikkunud ega ole rikkumist kõrvaldanud Täitja poolt antud täiendava mõistliku tähtaja
jooksul.
21
14.6. Üksnes Raamlepingu kehtivuse lõppemine ei mõjuta selle alusel sõlmitud
Hankelepingute kehtivust. Kõik Tellija ja Täitja vahel sõlmitud Lepingud lõppevad või
tuleb lõpetada eraldi.
14.7. Hankelepingu lõppemisel mistahes alusel ja põhjusel on Täitja kohustatud Tellijale üle
andma kogu selleks hetkeks tehtud Töö, sh Tööga seotud informatsiooni ja
dokumentatsiooni, mis peab olema süstematiseeritud. Täitja on Tellija nõudmisel
kohustatud andma kirjalikke selgitusi eelkirjeldatud Töö sisu ning sellega seotud
informatsiooni haldamise ja kasutamise kohta.
15. AVALIKUD SUHTED
15.1. Pooled kooskõlastavad omavahel Lepingut puudutavad PR-tegevused (näiteks
pressiteated, pressikonverentsid, kriisikommunikatsioon, kliendireferentsid jms) enne
nende ellu rakendamist ja avalikkuseni jõudmist. Pooled ei kahjusta Lepingu pinnalt
tekkinud erimeelsuste või vaidluste lahendamisel üksteise mainet meedia kaudu.
15.2. Pool tagab vastavate kohustuste täitmise ka kõikide Lepingu täitmisesse kaasatud
isikute poolt.
16. TEATED
16.1. Teade edastatakse teisele Poolele eelkõige e-posti vahendusel Lepingus märgitud
kontaktisiku e-posti aadressil. Kui teade edastatakse kirja teel tähitult, edastatakse see
teisele Poolele Lepingus märgitud aadressil. Kontaktisiku andmete ning Poole aadressi
muutusest on Pool kohustatud koheselt informeerima teist Poolt.
16.2. Kirja teel edastatud teade loetakse kättesaaduks, kui see on üle antud allkirja vastu või
kui teade on saadetud postiasutuse poolt tähitud kirjaga Poole poolt Lepingus näidatud
aadressil ja postitamisest on möödunud 5 (viis) kalendripäeva. E-posti teel teate
saatmise korral loetakse teade kättesaaduks, kui saaja on kinnitanud teate kättesaamist
või vastavale e-kirjale vastanud. Kui teate saaja ei kinnita e-kirja kättesaamist või ei
vasta e-kirjale mõistliku aja jooksul e-kirja saatmisest, võib sama teate saata korduva e-
posti saatmisega, millisel juhul loetakse teade kättesaaduks järgmisel tööpäeval vastava
e-kirja saatmisest.
16.3. Kontaktisikute pädevuses on seoses Lepinguga teostada Poole nimel kõiki Lepingust
tulenevaid õigusi ja kohustusi, välja arvatud Lepingute muutmine ning lõpetamisele
suunatud tahteavalduste esitamine.
17. LÕPPSÄTTED
17.1. Lepingule kohaldatakse Eesti Vabariigi õigust.
17.2. Kui Pooltel tekib vaidlus seoses Lepinguga, lahendatakse see läbirääkimiste teel. Kui
läbirääkimiste teel ei õnnestu vaidlust lahendada, kuulub vaidlus lahendamisele Tellija
asukohajärgses kohtus.
22
17.3. Lepingu või selles kokku lepitud õiguste ja kohustuste kolmandale isikule üleandmine
saab toimuda ettevõtte üleandmise tulemusena, kuid see eeldab Tellija eelnevat
kirjalikku nõusolekut. Tellija annab selles punktis nimetatud kirjaliku nõusoleku juhul,
kui see on riigihangete seaduse kohaselt lubatav ning kui Lepingu või ettevõtte
omandajal on piisav ettevalmistus ja kogemus, mis tagab Lepingu eesmärgi saavutamise
ja Lepingu tingimuste vähemalt samaväärse täitmise.
17.4. Raamlepingul on selle sõlmimisel järgmised lisad:
17.4.1. Akti vorm;
17.4.2. Hankelepingu vorm
17.4.3. Pakkumus;
17.4.4. Riigihanke alusdokumendid.
/Allkirjastatud digitaalselt Poolte või nende esindajate poolt/
23
Lisa 1 - Akti vorm
AKT NR [SISESTA AKTI NR]
Akt on koostatud selle kohta, et Täitja on teostanud ajavahemikul [SISESTA PERIOOD]
Hankelepingu nr [SISESTA TELLIJA LEPINGU NR] raames järgmised Tööd:
Jrk nr Töö kirjeldus Töö maht Töö hind
Hind käibemaksuta:
Käibemaks:
Hind kokku:
Akti allkirjastamisega kinnitab Täitja, et ta on eelnimetatud Tööd koos juurdekuuluva
dokumentatsiooniga Tellijale üle andnud.
Akti allkirjastamisega kinnitab Tellija, et ta on eelnimetatud Tööd koos juurdekuuluva
dokumentatsiooniga Täitjalt vastu võtnud.
/Akt on allkirjastatud digitaalselt/
24
Lisa 2 – Hankelepingu vorm
Hankelepingu üldandmed
Registreerimise kuupäev ja lepingu
number
{regNumber}
Tellija Täitja Rahastaja
Nimi Keskkonnaministeeriumi
Infotehnoloogiakeskus
AKTSIASELTS
HELMES
Registrikood 7000944510364097
Esindaja direktor Marko Arula juhatuse liige Andres
Kaljo
Esindusõiguse alus põhimäärusseadus
Kontaktisiku
andmed (kui
erinevad
Raamlepingust)
Riina Klais-Peets
+372 56150856
Kert Valamaa
+372 5144865
1. Hankelepingu sõlmimise
alus
2025 a sõlmitud raamleping nr ... (291973), täitja
AKTSIASELTS HELMES pakkumus.
2. Hankelepingu ese ………..
3. Rahastamisallikas Riigieelarve ja/või välisvahendid sh struktuuritoetusest või
garandilepingust tulenevad nõuded.
4. Tööde teostamise eritingimused, mis ei ole määratletud Hankelepingu lisades
4.1. Hankelepingus kokku leppimata küsimustes lähtutakse Raamlepingus sätestatust.
4.2. …………….
5. Hankelepingu maksumus ja arveldamise kord
…..
K keskmine tunnihind või muu hind
6. Juhusliku hävimise riisiko
6.1.Täitja kannab Tööde või nende mistahes osa juhusliku hävimise või kahjustumise riisikot
kuni viimase Töö üleandmiseni Tellijale / Töö etapi vakstuvõtmiseni või
Toodangukeskkonnas kasutuselevõtuni.
7. Hankelepingu kehtivus
7.1. Hankeleping jõustub alates hetkest, kui pooled on hankelepingu allkirjastanud.
7.2. Hankeleping kehtib lepinguliste kohustuste täitmiseni.
25
8. Hankelepingu lisad
8.1. Lisa 1 –Tellimus, sh Tööde tehniline kirjeldus;
8.2. Lisa 2 – Täitja pakkumus;
8.3 Muud Tellija poolt vajalikuks peetud lisad.
9. Leping on allkirjastatud digitaalselt.
| Nimi | K.p. | Δ | Viit | Tüüp | Org | Osapooled |
|---|---|---|---|---|---|---|
| Pakkumus turvavigade parandamiseks TARVIKUs | 05.10.2026 | 1 | 4-7-1/2026/5809 🔒 | Sissetulev kiri | rik | |
| Hankeleping TARVIKu turvavigade parandamiseks | 07.09.2026 | 2 | 2/64-26 🔒 | Leping | rik |