Hanke algatamine ja alusdokumentide kinnitamine riigihankes „Vanglate ettevõtluskeskuse Buumi e-pood" (302688)

1 / 12

Koostatud 11.11.2025 13:06:37 https://riigihanked.riik.ee/rhr-web/#/procurement/9552704/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. Käesolev PDF vormingus registri poolt koostatud dokument on selgitava iseloomuga ja sisaldab hankija sätestatud tingimusi, ettevõtjalt oodatavate vastuste vormingu vaadet ja registri poolt lisatud viiteid RHS-ile. Käesolev dokument ei ole ette nähtud täitmiseks vaid tingimustega tutvumiseks. Ettevõtja täidab hankepassi elektrooniliselt infosüsteemis või ESPD teenuses.

I OSA: HANKE JA HANKIJAGA SEOTUD TEAVE

Teave avaldamise kohta Teate number ELTs:

-

ELT URL:

Riigi ametlik teataja:

302688

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

Hankija andmed Ametlik nimi:

Registrite ja Infosüsteemide Keskus (70000310)

Riik:

Eesti

Hankija aadress:

Lubja tn 4

Hankija veebiaadress:

http://www.rik.ee/

E-posti aadress:

[email protected]

2 / 12

Koostatud 11.11.2025 13:06:37 https://riigihanked.riik.ee/rhr-web/#/procurement/9552704/general-info

Teave hankemenetluse kohta Hanke menetlusliik:

Väljakuulutamiseta läbirääkimistega hankemenetlus

Pealkiri:

Vanglate ettevõtluskeskuse Buumi e-pood

Lühikirjeldus:

Käesoleva hankega otsime vanglateenistuse ettevõtluskeskuse (VEK) e-poe ja kodulehekülje arenduspartnerit, et luua kaasaegne ja kasutajasõbralik e-pood koos täiendavate sisulehtedega, mis tutvustavad asutust ja tooteid. Loodav veebileht peab olema lihtsasti hallatav, visuaalselt meeldiv ja vanglateenistuse ettevõtluskeskuse CVI-le vastav, hästi toimiv nii desktop- kui mobiiliseadmetes ning vastama kõigile tänapäevastele veebiarenduse ja kasutajamugavuse standarditele. Koduleht majutub riigiasutusele sobival platvormil(Drupal, Wordpress), millel on vajalikud liidesed laotarkvaraga Buum. Koduleht ja e-pood peab kasutama analüütikaprogrammi Matomo.

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

302688

Hanke liik:

Teenused

Hanke CPV-d: 72212610-8 Andmebaasitarkvara arendusteenused

3 / 12

Koostatud 11.11.2025 13:06:37 https://riigihanked.riik.ee/rhr-web/#/procurement/9552704/general-info

II OSA: ETTEVÕTJAGA SEOTUD TEAVE

A: Teave ettevõtja kohta

Nimi:

Registrikood:

Riik:

Aadress:

Üldine veebileht:

Kontaktisikud:

Kontaktide e-posti aadressid:

Kontaktide telefoninumbrid:

Ettevõtte suurus:

Töötajate arv:

Käive:

Valuuta:

Finantsalase võimekuse kirjeldus:

Tehnilise võimekuse kirjeldus:

Teostatud tööde kirjeldus:

Ettevõtja tegevusvaldkond:

4 / 12

Koostatud 11.11.2025 13:06:37 https://riigihanked.riik.ee/rhr-web/#/procurement/9552704/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? 2. Milline on puudega või ebasoodsas olukorras olevate töötajate osakaal? 3. Kui seda on nõutud, täpsustage, millisesse puudega või ebasoodsas olukorras olevate töötajate kategooriasse või kategooriatesse asjaomased töötajad kuuluvad? 4. Kas see teave on elektrooniliselt kättesaadav? 5. URL 6. Kood 7. Väljaandja

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? 2. a) Vajaduse korral märkige asjakohane registreerimis- või sertifitseerimisnumber: 3. c) Viited, millele registreerimine või sertifitseerimine tugineb ja vajaduse korral ametlikus nimekirjas omistatud klassifikatsioon: 4. d) Kas registreerimine või sertifitseerimine hõlmab kõiki nõutud valikukriteeriume? 5. Kas see teave on elektrooniliselt kättesaadav? 6. URL 7. Kood 8. Väljaandja

HANKEMENETLUSES KOOS OSALEVAD ETTEVÕTJAD

Kas ettevõtja osaleb hankemenetluses koos teistega?

Küsimused ettevõtjale: 1. Ettevõtja nimi 2. Ettevõtja ID 3. Ettevõtja roll 4. Kas see teave on elektrooniliselt kättesaadav? 5. URL 6. Kood 7. Väljaandja

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? 2. Ettevõtja nimi 3. Ettevõtja ID 4. Ettevõtja roll 5. Kas see teave on elektrooniliselt kättesaadav? 6. URL 7. Kood 8. Väljaandja

5 / 12

Koostatud 11.11.2025 13:06:37 https://riigihanked.riik.ee/rhr-web/#/procurement/9552704/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? 2. Ettevõtja nimi 3. Ettevõtja ID 4. Ettevõtja roll 5. Kas see teave on elektrooniliselt kättesaadav? 6. URL 7. Kood 8. Väljaandja

HANKE OSAD

Hanke osad, mille kohta ettevõtja soovib pakkumuse esitada

Küsimused ettevõtjale: 1. Hanke osa number 2. Kas see teave on elektrooniliselt kättesaadav? 3. URL 4. Kood 5. Väljaandja

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? 2. Kas see teave on elektrooniliselt kättesaadav? 3. URL 4. Kood 5. Väljaandja

B: Teave ettevõtja esindajate kohta

Eesnimi:

Perekonnanimi:

Sünniaeg:

Sünnikoht:

Aadress:

Linn/vald:

Postiindeks:

Riik:

E-post:

Telefon:

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

6 / 12

Koostatud 11.11.2025 13:06:37 https://riigihanked.riik.ee/rhr-web/#/procurement/9552704/general-info

III OSA: KÕRVALDAMISE ALUSED

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

OSALEMINE KURITEGELIKUS ORGANISATSIOONIS

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

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

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Süüdimõistmise kuupäev (Kuupäev) 3. Põhjus (Suur sisestusala (max pikkus 4000 tähemärki)) 4. Kes süüdi mõisteti? (Suur sisestusala (max pikkus 4000 tähemärki)) 5. Süüdimõistvas otsuses sõnaselgelt esitatud kõrvalejätmise kestus. (Periood) 6. Kas olete võtnud meetmeid, et tõendada oma usaldusväärsust („Self-Cleaning”)? (Raadionupp valikutega "Jah/Ei") 7. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 8. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 9. URL (Url) 10. Kood (Sisestusväli (max pikkus 250 tähemärki)) 11. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

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.

7 / 12

Koostatud 11.11.2025 13:06:37 https://riigihanked.riik.ee/rhr-web/#/procurement/9552704/general-info

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Süüdimõistmise kuupäev (Kuupäev) 3. Põhjus (Suur sisestusala (max pikkus 4000 tähemärki)) 4. Kes süüdi mõisteti? (Suur sisestusala (max pikkus 4000 tähemärki)) 5. Süüdimõistvas otsuses sõnaselgelt esitatud kõrvalejätmise kestus. (Periood) 6. Kas olete võtnud meetmeid, et tõendada oma usaldusväärsust („Self-Cleaning”)? (Raadionupp valikutega "Jah/Ei") 7. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 8. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 9. URL (Url) 10. Kood (Sisestusväli (max pikkus 250 tähemärki)) 11. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

PETTUS

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

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

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Süüdimõistmise kuupäev (Kuupäev) 3. Põhjus (Suur sisestusala (max pikkus 4000 tähemärki)) 4. Kes süüdi mõisteti? (Suur sisestusala (max pikkus 4000 tähemärki)) 5. Süüdimõistvas otsuses sõnaselgelt esitatud kõrvalejätmise kestus. (Periood) 6. Kas olete võtnud meetmeid, et tõendada oma usaldusväärsust („Self-Cleaning”)? (Raadionupp valikutega "Jah/Ei") 7. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 8. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 9. URL (Url) 10. Kood (Sisestusväli (max pikkus 250 tähemärki)) 11. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

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:

8 / 12

Koostatud 11.11.2025 13:06:37 https://riigihanked.riik.ee/rhr-web/#/procurement/9552704/general-info

RHS § 95 lg 1 p 1 ja lg 2 "keda või kelle haldus-, juhtimis- või järelevalveorgani liiget, prokuristi või muud isikut, kellel on volitus seda ettevõtjat esindada, tema nimel otsuseid teha või teda kontrollida, on karistatud 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") 2. Süüdimõistmise kuupäev (Kuupäev) 3. Põhjus (Suur sisestusala (max pikkus 4000 tähemärki)) 4. Kes süüdi mõisteti? (Suur sisestusala (max pikkus 4000 tähemärki)) 5. Süüdimõistvas otsuses sõnaselgelt esitatud kõrvalejätmise kestus. (Periood) 6. Kas olete võtnud meetmeid, et tõendada oma usaldusväärsust („Self-Cleaning”)? (Raadionupp valikutega "Jah/Ei") 7. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 8. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 9. URL (Url) 10. Kood (Sisestusväli (max pikkus 250 tähemärki)) 11. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

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") 2. Süüdimõistmise kuupäev (Kuupäev) 3. Põhjus (Suur sisestusala (max pikkus 4000 tähemärki)) 4. Kes süüdi mõisteti? (Suur sisestusala (max pikkus 4000 tähemärki)) 5. Süüdimõistvas otsuses sõnaselgelt esitatud kõrvalejätmise kestus. (Periood) 6. Kas olete võtnud meetmeid, et tõendada oma usaldusväärsust („Self-Cleaning”)? (Raadionupp valikutega "Jah/Ei") 7. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 8. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 9. URL (Url) 10. Kood (Sisestusväli (max pikkus 250 tähemärki)) 11. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

9 / 12

Koostatud 11.11.2025 13:06:37 https://riigihanked.riik.ee/rhr-web/#/procurement/9552704/general-info

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

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

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

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Süüdimõistmise kuupäev (Kuupäev) 3. Põhjus (Suur sisestusala (max pikkus 4000 tähemärki)) 4. Kes süüdi mõisteti? (Suur sisestusala (max pikkus 4000 tähemärki)) 5. Süüdimõistvas otsuses sõnaselgelt esitatud kõrvalejätmise kestus. (Periood) 6. Kas olete võtnud meetmeid, et tõendada oma usaldusväärsust („Self-Cleaning”)? (Raadionupp valikutega "Jah/Ei") 7. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 8. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 9. URL (Url) 10. Kood (Sisestusväli (max pikkus 250 tähemärki)) 11. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

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“

10 / 12

Koostatud 11.11.2025 13:06:37 https://riigihanked.riik.ee/rhr-web/#/procurement/9552704/general-info

Tingimuse kirjeldus: Piirmäär: 0

Valuuta: EUR

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

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Asjaomane riik või liikmesriik (Riigikood) 3. Asjaomane summa (Summa) 4. Valuuta (Vääring) 5. Kas see kohustuste rikkumine on tuvastatud muude vahenditega kui kohtu- või haldusotsusega? (Raadionupp valikutega "Jah/Ei") 6. Kirjeldage kasutatud vahendeid (Suur sisestusala (max pikkus 4000 tähemärki)) 7. Kui kohustuste rikkumine tuvastati kohtu- või haldusotsusega, märkige, kas see otsus on lõplik ja siduv. (Raadionupp valikutega "Jah/Ei") 8. Süüdimõistmise kuupäev (Kuupäev) 9. Süüdimõistvas otsuses sõnaselgelt esitatud kõrvalejätmise kestus. (Periood) 10. Kas ettevõtja on täitnud oma kohustused tasumisele kuuluvate maksude või sotsiaalkindlustusmaksete tasumisega või siduva kokkuleppe sõlmimisega tasumisele kuuluvate maksude või sotsiaalkindlustusmaksete, sealhulgas vajaduse korral kogunenud intresside ja viiviste tasumise kohta? (Raadionupp valikutega "Jah/Ei") 11. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 12. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 13. URL (Url) 14. Kood (Sisestusväli (max pikkus 250 tähemärki)) 15. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

SOTSIAALKINDLUSTUSMAKSETE TASUMINE

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

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

11 / 12

Koostatud 11.11.2025 13:06:37 https://riigihanked.riik.ee/rhr-web/#/procurement/9552704/general-info

Tingimuse kirjeldus: Piirmäär: 0

Valuuta: EUR

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

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Asjaomane riik või liikmesriik (Riigikood) 3. Asjaomane summa (Summa) 4. Valuuta (Vääring) 5. Kas see kohustuste rikkumine on tuvastatud muude vahenditega kui kohtu- või haldusotsusega? (Raadionupp valikutega "Jah/Ei") 6. Kirjeldage kasutatud vahendeid (Suur sisestusala (max pikkus 4000 tähemärki)) 7. Kui kohustuste rikkumine tuvastati kohtu- või haldusotsusega, märkige, kas see otsus on lõplik ja siduv. (Raadionupp valikutega "Jah/Ei") 8. Süüdimõistmise kuupäev (Kuupäev) 9. Süüdimõistvas otsuses sõnaselgelt esitatud kõrvalejätmise kestus. (Periood) 10. Kas ettevõtja on täitnud oma kohustused tasumisele kuuluvate maksude või sotsiaalkindlustusmaksete tasumisega või siduva kokkuleppe sõlmimisega tasumisele kuuluvate maksude või sotsiaalkindlustusmaksete, sealhulgas vajaduse korral kogunenud intresside ja viiviste tasumise kohta? (Raadionupp valikutega "Jah/Ei") 11. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 12. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 13. URL (Url) 14. Kood (Sisestusväli (max pikkus 250 tähemärki)) 15. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

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

12 / 12

Koostatud 11.11.2025 13:06:37 https://riigihanked.riik.ee/rhr-web/#/procurement/9552704/general-info

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 3. URL (Url) 4. Kood (Sisestusväli (max pikkus 250 tähemärki)) 5. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

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") 2. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 3. URL (Url) 4. Kood (Sisestusväli (max pikkus 250 tähemärki)) 5. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

Koostatud 11.11.2025 13:07:09 1 / 2 https://riigihanked.riik.ee/rhr-web/#/procurement/ 9552704/general-info

HINDAMISKRITEERIUMID JA HINNATAVAD NÄITAJAD

Viitenumber: 302688 Hankija: Registrite ja Infosüsteemide Keskus (70000310) Hange: Vanglate ettevõtluskeskuse Buumi e-pood

Pakkumuse maksumust hinnatakse - Ilma maksudeta Kriteeriumi kaalumise meetod - Osakaaludega Elektroonilist oksjoni kasutatakse: ei

Jrk nr

Nimetus Kirjeldus Tüüp / hindamismeetod

Osakaal Kogus Ühik Pakkuja täidetav

1 Hankelepingu järgsete tööde (tehnilise kirjelduse punktid2-3ning selle alapunktid) kogumaksumus

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

Maksumus - vähim on parim

50 EUR jah

2 Lisaarendustöö tunnihind Pakkumuse maksumus peab olema lõplik ja sisaldama kõiki kulusid vastavalt riigihanke alusdokumentidele ning seal nimetamata kulusid, mis on vajalikud lepingu nõuetekohaseks täitmiseks. 0 või negatiivse väärtusega maksumusi ei ole lubatud kasutada ja sellised pakkumused on hankijal õigus tunnistada mittevastavaks ning tagasi lükata. Maksumus esitatakse täpsusega kaks

Kulu - vähim on parim

50 jah

Koostatud 11.11.2025 13:07:09 2 / 2 https://riigihanked.riik.ee/rhr-web/#/procurement/ 9552704/general-info

kohta pärast koma. Hankija ei hüvita lepingu täitmisel pakkujale mingeid täiendavaid kulusid ega tee täiendavaid makseid.

Kokku: 100

Hindamismetoodika kirjeldus 1.   Hankelepingu järgsete tööde (tehnilise kirjelduse punktid2-3ning selle alapunktid) kogumaksumus

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

2.   Lisaarendustöö tunnihind 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".

1 / 2

Koostatud 11.11.2025 13:06:53 https://riigihanked.riik.ee/rhr-web/#/procurement/9552704/general-info

VASTAVUSTINGIMUSED Viitenumber: 302688 Hankija: Registrite ja Infosüsteemide Keskus (70000310) Hange: Vanglate ettevõtluskeskuse Buumi e-pood

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

Tingimusliku pakkumuse esitamine ei ole lubatud.

Küsimused ettevõtjale: 1. Kas ettevõtja saab kinnitada, et pakkumus vastab hanke alusdokumentides sätestatud tingimustele? (Raadionupp valikutega "Jah/Ei")

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

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

PAKKUMUSE MAKSUMUS Pakkumuse maksumus tuleb esitada töölehel "Hindamiskriteeriumid ja hinnatavad näitajad" toodud struktuuri kohaselt.

Küsimused ettevõtjale: 1. Kas ettevõtja kinnitab, et täidab pakkumuse lehe "Hindamiskriteeriumid ja hinnatavad näitajad" lehel ette antud struktuuri kohaselt? (Raadionupp valikutega "Jah/Ei")

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

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

Küsimused ettevõtjale: 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))

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

2 / 2

Koostatud 11.11.2025 13:06:53 https://riigihanked.riik.ee/rhr-web/#/procurement/9552704/general-info

üksuse omandis; 3. punktis 1 või 2 nimetatud isiku, asutuse või muu üksuse esindaja või tegutseb sellise isiku 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.

Küsimused ettevõtjale: 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")

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

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

Küsimused ettevõtjale: 1. Pakkuja kinnitab, et pakkumus vastab hanke alusdokumentides nõutule ja vajadusel on samaväärsus selgitatud ja tõendid samaväärsuse kohta lisatud. (Raadionupp valikutega "Jah/Ei")

BUUM TARKVARA AINUÕIGUST KINNITAV VABAS VORMIS DOKUMENT

Küsimused ettevõtjale: 1. Buum tarkvara ainuõigust kinnitav dokument (Vabas vormis dokument)

Väljakuulutamiseta läbirääkimistega hankemenetluse

„Vanglate ettevõtluskeskuse Buumi e-pood“ (302688) hankedokumentide juurde

Arendusleping nr ...

Arenduslepingu eritingimused

Tallinnas

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

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

………………. (registrikoodiga…………) asukohaga …………….., ……., mida esindab …………alusel

………, edaspidi Täitja,

ja

………………. (registrikoodiga…………) asukohaga …………….., ……., mida esindab …………alusel

………, edaspidi Maksja,

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

Leping) alljärgnevas:

1. Lepingu sõlmimise alus ja ese

1.1. Leping sõlmitakse väljakuulutamiseta läbirääkimistega hankemenetluses „Vanglate ettevõtluskeskuse

Buumi e-pood“ (302688) eduka pakkumuse esitanud pakkujaga (Täitja) Lepingu lisas 3 kirjeldatud tööde

teostamiseks ning kõigi muude Lepingust tulenevate kohustuste täitmiseks (edaspidi ka Töö).

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

seonduvates õigusaktides ja juhtrühma otsustes sätestatud tingimustel ja mahus.

2. Hind ja maksetingimused

2.1. Lepingu hinna moodustavad hankelepingu järgsed tööd ja lisaarendustööd, mis on tellitud 18 kuu

jooksul alates hankelepingu sõlmimisest.

2.2. Lepingu maksimaalne hind on …………. eurot (netosumma), arvestusega, et lepingujärgsete tööde

hind on ..... eurot (netosumma) ja lisaarendustööde tunnihind on ….. eurot (netosumma). Lepingu hinnale

lisandub käibemaks.

2.2.1. Hankelepingu järgsed tööd on sätestatud tehnilise kirjelduse punktides 2-3 ja nende alapunktides.

2.2.2. Lisaarendustööd on sätestatud tehnilise kirjelduse punktis 5 ja selle alapunktides.

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

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

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

täitmiseni.

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

4. Lepingu dokumendid

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

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

Lepingu allkirjastamisel on Lepingu lisad järgmised:

4.1.1 Arenduslepingu üldtingimused Lisa nr 1;

4.1.2 Personal ja kontaktandmed Lisa nr 2;

4.1.3 Tehniline kirjeldus Lisa nr 3;

4.1.4 Pakkumus Lisa nr 4;

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

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

allolevas loetelus) on järgmine:

4.2.1 Eritingimused;

4.2.2 Arenduslepingu üldtingimused;

4.2.3 Tehniline kirjeldus;

4.2.4 Muud riigihanke alusdokumendid;

4.2.5 Pakkumus.

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

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

Tellija: Täitja:

/ allkirjastatud digitaalselt /

/ allkirjastatud digitaalselt /

Rivo Reitmann

Direktor

Registrite ja Infosüsteemide Keskus

Maksja:

/ allkirjastatud digitaalselt /

Arendusleping nr ………

Lisa nr 1

ARENDUSLEPINGU ÜLDTINGIMUSED

Kui eritingimustes on sätestatud teisiti kui üldtingimustes, siis kehtib eritingimustes toodu.

1. Definitsioonid

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

1.1 Tarkvara

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

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

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

lepingu raames spetsiaaltarkvarana.

1.2 Seadmed

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

vajalik seadmete funktsioneerimiseks.

1.3 Telekommunikatsioonid

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

teenuseid ning vajalikke vahendeid, teenuseid ja protseduure.

1.4 Asukoht

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

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

toodangukeskkond).

1.5 Puudus ja viga

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

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

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

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

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

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

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

teist sama süsteemi osa kasutamast.

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

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

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

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

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

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

muutmist/parandamist.

1.6 Lisaarendustööd

Lisaarendustööde alla kuuluvad arendus- ja hooldustööd, mida Tellijal on õigus 18 kuu jooksul vastavalt

vajadusele tellida. Lisaarendustööde tellimine toimub tehnilise kirjelduse punktis 5 ja selle alapunktides

sätestatud protsessi järgi.

1.6.1 Arendustööd tähendavad Buumi e-poe funktsionaalsuse parandamise ja täiendamise ning

teenuse arendamisega seonduvaid töid. Arendustööd sisaldavad endas tehnilist konsultatsiooni,

süsteemi- ja detailanalüüsi läbiviimist, programmeerimistöid, testimist, dokumentatsiooni

koostamist ja koolitusi.

1.6.2 Hooldustööd tähendavad töid, mis tagavad seadmete, telekommunikatsioonide ja tarkvara

(kaasa arvatud nende juurde kuuluvate andmete ja andmebaaside) toimivuse (korrasoleku,

terviklikkuse, jõudluse jms). Hooldus sisaldab kaugtuge, vigade ennetamist ja parandamist, uute

redaktsioonide ja versioonide ning nendega seotud dokumentatsiooni üleandmist. Samuti hõlmab

hooldus lepingus sätestatud tingimustel seadmete, telekommunikatsioonide ja tarkvara

kohandamist Tellija vajadustele, eeldusel, et see ei nõua olulist ümberprogrammeerimist ega uue

toote loomist.

1.7 Toodangukeskkond

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

2. Hind

2.1 Lepingu eritingimustes märgitakse lepingu hind käibemaksuta (netosummas).

2.2 Lepingu hind väljendatakse eurodes.

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

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

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

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

3. Maksmine

3.1 Täitja esitab Maksjale arve masinloetaval kujul e-arvena. Arve esitamise õigus tekib Täitjal pärast Töö

vastuvõtmist Tellija poolt.

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

3.2.1 info arve esitaja kohta;

3.2.2 info maksja kohta;

3.2.3 viide Lepingule;

3.2.4 käibemaksukohustuslase number;

3.2.5 vastuvõetud Töö nimetus ja kirjeldus;

3.2.6 käibemaks;

3.2.7 kogusumma;

3.3 Maksja tasub Lepingu hinna Täitja poolt esitatud arvel märgitud kuupäevaks. Maksetähtaeg ei tohi olla

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

näinud.

3.4 Ettemakseid Maksja ei teosta.

3.5 Lõpparve maksmine eeldab Täitja kõigi Lepingujärgsete kohustuste täitmist ning Tellija poolt

vastuvõtmist.

3.6 Maksjal on õigus Lepingu rikkumise korral arvestatud leppetrahvid ja kahju hüvitised maha arvata

Lepingu alusel Täitjale tasumisele kuuluvatest summadest.

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

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

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

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

4. Informatsioon ja aruanded

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

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

asukohta, konsulteerides Tellijaga või muul sobilikul viisil.

4.2. Tellija varustab Täitjat tema käsutuses oleva mistahes informatsiooni ja dokumentatsiooniga, mis

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

vastava nõude saamisest.

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

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

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

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

kulgemist ja teenuseid) puudutavat informatsiooni.

5. Teated ja kirjavahetus

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

Pooled on kohustatud kontaktandmete ja aadresside muutusest teineteist teavitama viivitamatult,

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

5.2. Kui teisele poolele edastatav teade eeldab vastust, tuleb vastata viivitamatult, kuid mitte hiljem kui

2 tööpäeva jooksul.

5.3. Pooltevahelised Lepinguga seotud teated peavad olema kirjalikku taasesitamist võimaldavas

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

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

5.3.1. teade on üle antud allkirja vastu;

5.3.2. teade on edastatud tähitud kirjana poole postiaadressil ja teate postitamisest on möödunud 5 (viis)

kalendripäeva;

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

6. Asukoht

6.1. Täitja peab andma lepingutäitmise käigus piisavalt informatsiooni korrektselt kirjalikku

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

lepingujärgsete kohustuste täitmiseks kohaselt ette valmistada. Juhend peab olema antud sellise

sisendiga, et objektiivselt keskmise võimekusega programmeerija oleks suuteline asukoha Töö

vastuvõtmiseks vajalike testide teostamiseks ette valmistada. Juhend peab olema esitatud piisava

ajavaruga selleks, et Tellijal oleks võimalik Töö üleandmisel alustada koheselt vastuvõtmiseks

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

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

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

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

6.2. Tellija teeb vastavad ettevalmistused ja loob tingimused omal kulul.

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

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

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

ajapikendust.

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

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

sisalduvad Lepingu hinnas ning neid ei hüvitata.

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

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

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

7. Lepingu muutmine

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

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

on muudatused tühised.

7.2. Riigihangete seaduse § 123 lg 1 p-s 1 kirjeldatud muudatused lepitakse kokku Tellija ja Täitja

esindajate poolt kirjalikku taasesitamist võimaldavas vormis.

8. Poolte õiguskaitsevahendid

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

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

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

õiguskaitsevahendeid lisaks selles peatükis kokkulepitule.

8.2. Lepingust või seadusest tuleneva õiguse või õiguskaitsevahendi mittekasutamine või selle

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

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

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

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

Eesti Vabariigi õigusaktides ning Lepingus ettenähtud korras.

8.4. Oluliseks lepingurikkumiseks loetakse muu hulgas järgmisi rikkumisi:

8.4.1. Pool ei täida mis tahes Lepingust tulenevat kohustust teise Poole poolt Lepingust tuleneva vastava

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

8.4.2. Täitja ei täida garantiiperioodil Lepingust tulenevaid kohustusi;

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

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

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

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

8.4.5. Täitja rikub Personaliga seonduvaid tingimusi;

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

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

8.4.7. Täitja suhtes on algatatud pankrotimenetlus, pankrot on välja kuulutatud, Täitja varad arestitakse

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

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

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

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

kohustusi;

8.4.10. Pool on rikkunud avalikustamise keelu kohustust;

8.4.11. Pool on rikkunud kolmandate isikutega seonduvaid kohustusi;

8.4.12. Maksja on viivituses Lepingus kokku lepitud maksetähtajaga rohkem kui kolmkümmend (30)

kalendripäeva;

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

iga vastava juhtumi korral.

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

kohustust tahtlikult või raske hooletuse tõttu.

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

leppetrahvi nõudmise õiguse tekkimisest. Leppetrahvi nõude esitamisel on Pool kohustatud märkima

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

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

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

Leppetrahvi nõudmine ei mõjuta Poole õigust nõuda Poolelt nõuetekohase Töö või selle osa teostamist

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

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

mittenõuetekohasel täitmisel, et:

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

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

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

Töö ja tarniks uued seadmed, telekommunikatsioonid ja tarkvara või keelduda vastuvõtmisest ning

Leping lõpetada;

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

8.9. Lepingust tulenevate leppetrahvide maksmine, samuti tekitatud kahju hüvitamine, ei vabasta Lepingut

rikkunud poolt Lepingujärgsete kohustuste täitmisest.

9. Standardid, liidesed ja ühilduvus

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

süsteemide talitluses.

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

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

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

ning lepingus sätestatud keskkonnas.

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

sideprotokolle jms.

10. Dokumentatsioon

10.1. Lepingu täitmisel kaasneva dokumentatsiooni loomisel toetutakse dokumentatsiooniplaanile.

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

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

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

kasutada, hooldada, kohandada ja neile lisaseadmeid lisada.

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

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

mõistetav.

10.5. Dokumentide valmistamiseks ja levitamiseks kasutatakse paberkandjat või elektroonilist

infokandjat.

11. Üleandmine ja vastuvõtmine

11.1. Töö või lisaarendustöö valmimise järgselt annab Täitja selle Tellijale üle vastuvõtmiseks.

11.2. Täitja peab Tellijat Töö või lisaarendustöö üleandmise viivitusest või viivitusse sattumise ohust ja

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

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

hüvitamist.

11.3. Töö või lisaarendustöö üleandmise kohta koostab Täitja üleandmise akti, milles näidatakse

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

seadmete, telekommunikatsioonide ja tarkvara detailiseeritud nimekiri ning vajaduse korral neis

esinevad puudused. Töö või lisaarendustöö üleandmisel koostab ja esitab Täitja töö või

lisaarendustöö kohta koostatud dokumentatsiooni, vastavalt dokumentatsiooniplaanile või Tellija

poolt tehnilises kirjelduses esitatud nõudmistele.

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

11.5. Täitjal on õigus nõuda ja Tellijal kohustus Töö või lisaarendustöö vatsu võtta, kui Töös on Täitja

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

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

vastuvõtmise aktis toodud ajaperioodiks.

11.6. Pärast Töö või lisaarendustöö üleandmist on Tellijal õigus Töö üle vaadata 20 tööpäeva jooksul.

11.7. Juhul, kui Tellija leiab, et Töö või lisaarendustöö ei vasta Lepingu tingimustele, on Tellija kohustatud

teavitama Täitjat Töös või lisaarendustöös avastatud puudustest, keeldumisest Tööd või

lisaarendustööd enne puuduste kõrvaldamist vastu võtta ja kirjeldama Töö või lisaarendustöö

puudused. Täitja on kohustatud puudused kõrvaldama 5 tööpäeva jooksul, kui pooled ei ole kokku

leppinud mõnda muud tähtaega. Töö või lisaarendustöö puuduste kõrvaldamise kulud kannab

Täitja.

11.8. Enne töö või lisaarendustöö üleandmist viib Täitja Töö või lisaarendustöö nõuetelevastavuse

kindlakstegemiseks läbi testid.

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

11.10. Enne Töö või lisaarendustöö vastuvõtmist viib Tellija Töö või lisaarendustöö nõuetelevastavuse

kindlakstegemiseks läbi testid.

11.11. Kui Töö või mistahes Töö osa või lisaarendustöö või mistahes lisaarendustöö osa ei läbi teste,

viiakse otsekohe pärast seda, kui Täitja on teinud vajalikud korrektuurid testide edukaks

läbiviimiseks, läbi kordustestid samadel tingimustel.

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

11.13. Parandatud Töö või lisaarendustöö üleandmine toimub nagu esmakordsel üleandmiselgi.

11.14. Puudustega üle antud Tööd või lisaarendustööd ei loeta tähtaegselt üleantuks ning Tellijal on õigus

nõuda sellise lepingurikkumise korral Täitjalt leppetrahvi Lepingus sätestatud korras ja määrades

või rakendada muid õiguskaitsevahendeid.

11.15. Vastuvõtmiseks valmis Töö või lisaarendustöö peab vastama Lepingus sätestatud tingimustele.

Töö või lisaarendustöö vastuvõtmise kohta koostab Tellija vastuvõtuakti, milles näidatakse

muuhulgas ära vastuvõtmise kuupäev, teostatud Töö või lisaarendustöö, osutatud teenuste,

hoolduse ja tarnitud seadmete, telekommunikatsioonide ja tarkvara detailiseeritud nimekiri.

11.16. Töö või lisaarendustöö loetakse vastuvõetuks vastuvõtuakti allkirjastamisest või

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

või lisaarendustöö toodangukeskkonnas kasutusele, loetakse vastuvõetuks ainult nõuetekohaselt

teostatud tööd ja Täitjal on õigus nimetatute osas esitada arve. Taolises olukorras esitab Tellija

Täitjale Töös või lisaarendustöös esinevate puuduste nimekirja ning puuduste kõrvaldamise

tähtaja, kas enne Töö või lisaarendustöö toodangukeskkonnas kasutusele võtmist või vahetult

pärast selle toimumist.

11.17. Mistahes seadmete, telekommunikatsioonide, tarkvara ja teenuste osa valmimisel võib Tellija anda

välja vastuvõtuakti vastava osa kohta. Selline vastuvõtmine ei mõjuta Täitja kohustust täita kõiki

Lepingus ettenähtud kohustusi.

11.18. Täitja vastutab Töö või lisaarendustöö juhusliku hävimise või kahjustumise eest kuni Töö

vastuvõtmiseni Tellija poolt.

12. Koolitus

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

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

kokkulepitule.

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

13. Garantii

13.1. Täitja annab Tööle 6 (kuue) kuulise töövõtugarantii. Garantiiperiood algab Tööde kogumina

vastuvõtmisest.

13.2. Garantiiperioodil ilmnevad puudused kõrvaldab Täitja omal kulul, v.a punktis 13.6 toodud

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

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

pärast sellest asjaolust teada saamist.

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

punktis 11 toodud regulatsiooni kohaselt.

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

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

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

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

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

ajal.

13.6. Garantiiga ei ole hõlmatud:

13.6.1. puudused, mille tekkimise eest vastutab Tellija;

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

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

tunnihinna alusel.

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

v.a juhul kui Tellija suudab eristada lähtekoodis tehtavaid muudatusi.

14. Load ja litsentsid

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

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

viivitamist või väljaandmisest keeldumist.

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

või litsentsi.

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

muude sarnaste õigustega kaitstavate esemete kasutamisõigus.

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

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

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

15. Intellektuaalne vara

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

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

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

kolmandatel isikutel nõudeid.

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

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

15.3. Täitja annab spetsiaaltarkvarale Euroopa Liidu tarkvara vaba kasutuse litsentsi v.1.2 (EUPL).

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

15.4.1. teost kasutada mis tahes eesmärgil ja mis tahes viisil;

15.4.2. teost reprodutseerida;

15.4.3. originaalteost muuta ja luua teosel põhinevaid tuletatud teoseid;

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

eksponeerida, samuti avalikult esitada;

15.4.5. teost või selle koopiaid levitada;

15.4.6. teost või selle koopiaid laenutada ja rentida;

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

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

võimaldab Tellijal sellest aru saada.

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

kolmandatele isikutele ja asutustele.

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

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

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

keskkonnas, toel või formaadis.

15.9. Täitja tagab, et tema töötajad on loobunud Eesti Vabariigi seadusega lubatud ulatuses oma

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

15.10. Lepingujärgse tarkvarasüsteemi loomiseks kolmandatele isikutele kuuluvate komponentide

(tarkvara) kasutamise osas juhinduvad Pooled nende kasutamise litsentsitingimustest. Täitja

kinnitab, et eelistab tarkvara loomisel selliseid kolmandatele isikutele kuuluvaid komponente, mille

kasutamisega ei kaasne täiendavaid litsentsitasusid ega piiranguid tarkvara kasutamisel või

alllitsentside andmisel. Täitja on kohustatud Tellijat teavitama juhul, kui Täitja plaanib tarkvara

loomisel kasutada selliseid kolmandatele isikutele kuuluvaid komponente, mille kasutamine toob

Tellijale kaasa täiendavaid litsentsitasusid või piiranguid tarkvara kasutamisel. Ilma Tellija kirjaliku

nõusolekuta ei tohi Täitja tarkvara loomisel nimetatud komponente kasutada.

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

kogu maailm.

16 Personal

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

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

nõusolekul.

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

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

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

temast tuleneva põhjuse tõttu;

16.2.2 lepingus nimetatud Töid teostav isik osutub Tellija põhjendatud arvamuse kohaselt lepingujärgsete

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

täitmine pidevalt kahjustab lepingu korrektset ja õigeaegset täitmist.

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

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

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

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

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

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

töötajale.

17 Kolmandad isikud

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

kohustatud teineteist nõude loovutamisest viivitamatult kirjalikult informeerima.

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

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

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

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

vastavasisuline teavitus on Tellija poolt pakkumuse esitamise ettepanekus kajastatud.

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

18 Auditeerimine

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

vajalik teise poole luba.

18.2 Audiitori isik ja muud auditeerimisega seotud asjaolud sätestatakse eraldi kokkuleppes.

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

probleemide lahendamise protsessi.

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

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

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

Vastutus jääb audiitori kaasanud poolele.

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

18.6 Auditi kulud kannab auditi tellinud pool.

19 Konfidentsiaalsus ja isikuandmed

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

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

kirjaliku nõusolekuta.

19.2 Täitja on kohustatud:

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

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

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

ilma Tellija sellekohase selgesõnalise kirjaliku nõusolekuta;

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

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

lepingutes sisalduvate Tellija esindajate isikuandmete) konfidentsiaalsuse ning ei edasta ega

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

selgesõnalise kirjaliku nõusolekuta;

19.2.3 mitte edastama punktis 19.2.2 nimetatud isikuandmeid väljapoole Euroopa Liidu liikmesriikide

ja Euroopa Majandusühendusse kuuluvate riikide territooriumit ilma tellija sellekohase

selgesõnalise kirjaliku nõusolekuta;

19.2.4 kasutama ja töötlema punktis 19.2.2. nimetatud isikuandmeid üksnes Lepingu täitmiseks ja

Tellija dokumenteeritud juhiste alusel, välja arvatud juhul, kui täitja on kohustatud teavet

töötlema täitja suhtes kohalduva õiguse alusel. Viimati nimetatud juhul teavitab Täitja Tellijat

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

avaliku huvi tõttu Täitja suhtes kohalduva õigusega keelatud;

19.2.5 võimaldama juurdepääsu punktis 19.2.2. nimetatud isikuandmetele ainult nendele isikutele,

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

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

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

kehtib asjakohane seadusest tulenev konfidentsiaalsuskohustus. Vastav

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

19.2.6 täitma kõiki kehtivaid isikuandmete töötlemisalaseid nõudeid, andmete turvalisust puudutavaid

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

19.2.7 rakendama järgmisi organisatsioonilisi, füüsilisi ja infotehnilisi turvameetmeid punktis 19.2.2.

nimetatud isikuandmete kaitseks juhusliku või tahtliku volitamata muutmise; juhusliku hävimise

ja tahtliku hävitamise eest ning õigustatud isikule andmete kättesaadavuse takistamise eest,

volitamata töötlemise s.h. avalikustamise eest:

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

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

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

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

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

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

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

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

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

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

isikuandmed edastati, samuti selliste andmete muutusteta säilimise;

f) tagama, et isikuandmete edastamisel andmesidevahenditega ja andmekandjate

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

kustutamist;

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

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

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

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

19.2.8 teavitama Tellijat toimunud või põhjendatult kahtlustatavast käesoleva lepingu punktis 19.2.1

ja/või 19.2.2 sätestatud konfidentsiaalsuskohustuse rikkumisest; punktis 19.2.7. ja selle

alapunktides a-g sätestatud turvameetmete rikkumisest, mis põhjustab, on põhjustanud või võib

põhjustada edastatavate, salvestatud või muul viisil töödeldavate isikuandmete juhusliku või

ebaseadusliku hävitamise, kaotsimineku, muutmise või loata avalikustamise või neile

juurdepääsu, kirjalikult viivitamata aga mitte hiljem kui kakskümmend neli (24) tundi pärast

sellest teada saamist. Teates tuleb vähemalt:

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

andmesubjektide liike ja arvu ning puudutatud kirjete liike ja arvu;

b) teatada, kes on Täitja andmekaitse töötaja ja mis on tema kontaktandmed või muu

kontaktpunkt, kust saab lisateavet;

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

leevendamiseks;

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

ja potentsiaalseid ohte;

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

(isikuandmetega seotud) rikkumisega tegelemiseks ja

f) esitada muud teavet, mis on mõistlikult nõutav, et Tellija saaks täita Kohaldatavaid

andmekaitse õigusakte, sealhulgas riigiasutustega seotud teavitamise ja avaldamise

kohustusi, näiteks teavet, mis on nõutav andmesubjekti tuvastamiseks.

19.2.9 Tellija eelneval kirjalikul heakskiidul lõpetama käesoleva lepingu punktis 19.2.8.nimetatud

rikkumine ning kohaldama meetmeid (isikuandmetega seotud) rikkumise lahendamiseks,

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

leevendamiseks;

19.2.10 lepingu lõppemisel kustutama kõik punktis 19.2.2. nimetatud isikuandmed ja nimetatute koopiad

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

19.2.11 tegema Tellijale kättesaadavaks kogu teabe, mida Tellija peab vajalikuks lepingus sätestatud

kohustuste täitmise tõendamiseks;

19.2.12 võimaldama Tellijal või Tellija poolt volitatud audiitoril teha auditeid ja kontrolle ning panustama

nendesse;

19.2.13 võimaluse piires asjakohaste tehniliste ja korralduslike meetmete abil, punktis 19.2.2.

nimetatud isikuandmete osas, aitama täita Tellija kohustust vastata taotlustele andmesubjekti

õiguste teostamiseks ning teostama nende õiguste teostamisest tulenevaid toiminguid

(andmete parandamine, sulgemine, kustutamine).

19.3 Käesoleva lepingu punktis 19.2.1. sätestatud konfidentsiaalsuse nõue ei laiene informatsiooni

avaldamisele Täitja audiitorile ja advokaadile.

19.4 Käesoleva lepingu punktides 19.2.1. ja 19.2.2. sätestatud konfidentsiaalsuskohustuse nõue on

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

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

juhised isikuandmete töötlemiseks.

19.6 Kõik käesoleva lepingu punktides 19.2.1. – 19.4 kohustused kehtestab Täitja kõikidele

kolmandatele isikutele, keda ta kasutab oma lepingujärgsete kohustuste täitmisel. Kolmas isik on

füüsiline või juriidiline isik või riigi- või kohaliku omavalitsuse asutus, kes ei ole ei Tellija, Maksja

ega ka Täitja.

20 Avalikud suhted

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

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

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

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

oma lepingujärgsete kohustuste täitmisel.

21 Lepingu täitmise peatamine ja lepingu lõpetamine

21.1 Maksja võib peatada Täitjale lepingujärgselt makstavate summade maksmise kas osaliselt või

täielikult, kui:

21.1.1 Täitja ei täida oma Lepingujärgseid kohustusi;

21.1.2 vastuvõtmise, testimise või auditeerimise käigus avastatakse puudusi või muid Täitjapoolseid

kohustuste rikkumisi;

21.1.3 Tellija või Maksja Lepingujärgsete kohustuste õigeaegset ja korrektset täitmist segab või ähvardab

segada muu asjaolu, mille eest vastutab Täitja.

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

21.2.1 Tellija või Maksja ei täida oma Lepingujärgseid kohustusi;

21.2.2 Täitja Lepingujärgsete kohustuste õigeaegset ja korrektset täitmist segab või ähvardab segada

muu asjaolu, mille eest vastutab Tellija.

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

õigus nõuda tasu täidetud kohustuste eest.

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

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

poolt tarnitud seadmed, telekommunikatsioonid ja tarkvara tagastatakse võimatuse korral. Muul

juhul, kui tagastamine on saadu olemuse tõttu välistatud, makstakse hüvitist võlaõigusseaduses

sätestatud korras.

21.5 Täitja võib Lepingu üles öelda Tellija- või Maksjapoolse olulise Lepingu rikkumise korral pärast

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

hoiatuse esitamist. Sellise Lepingu lõpetamise korral maksab Tellija Täitjale tasu täidetud

kohustuste eest.

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

22 Vääramatu jõud

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

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

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

22.2 Pool, kelle tegevus lepingujärgsete kohustuste täitmisel on takistatud vääramatu jõu asjaolude

tõttu, on kohustatud sellest koheselt kirjalikult teatama teisele Poolele, esitades teavitusega ühes

tõendi/tõendid kõigi järgnevate asjaolude esinemise kohta:

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

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

22.2.3 asjaolu ettenägematus;

22.2.4 asjaolu vältimatus ja ületamatus.

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

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

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

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

23 Kehtiv seadusandlus

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

õigusakte.

24 Vaidluste lahendamine

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

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

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

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

24.3 Kokkuleppe mittesaavutamisel lahendatakse vaidlus Harju Maakohtus.

Arendusleping nr. …………

Lisa nr 2

PERSONAL JA KONTAKTANDMED

1. Tellija esindaja ja kontaktisikud

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

allkirjastamisel on Registrite ja Infosüsteemide Keskuse …………………. (tel ………….; e-post

…………….).

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

tööülesannete täpsustamisel jmt. on Registrite ja Infosüsteemide Keskuse ………… (tel …; e-post

…………………).

2. Täitja esindaja ja kontaktisikud

2.1 Täitja esindajaks on ………… (tel …………..; e-post………….).

2.2 Täitja kontaktisikuks on ………… (tel …………..; e-post………….).

3. Maksja esindaja ja kontaktisikud

3.1. Maksja esindajaks on ………… (tel ………….; e-post …………….).

3.2. Maksja kontaktisikuks on ………… (tel …; e-post …………………).

4. Personali nimekiri

4.1. Tellija personal

Nr. Nimi Ametinimetus Kontaktandmed

4.2. Täitja personal

Nr. Nimi Ametinimetus Kontaktandmed

5. Kontaktandmed

5.1. Tellija kontaktandmed on: 5.2. Täitja kontaktandmed on: 5.3. Maksja kontaktandmed

Registrite ja Infosüsteemide Keskus ……………. …………….

Reg. nr. 70000310 Registrikood Registrikood

Lubja tn 4 …………… ……………

19081 TALLINN …………… ……………

Telefon: 663 6300 Telefon: ……………. Telefon: …………….

Arendusleping nr ……

Lisa nr 3

TEHNILINE KIRJELDUS KOOS LISADEGA

Tehniline kirjeldus asub arenduslepingu asice konteineris eraldi faili(de)na.

Arendusleping nr ………

Lisa nr 4

PAKKUMUS

Pakkumus asub arenduslepingu asice konteineris eraldi konteinerina.

Nõuded arendustele versioon 7.0 §Requirements

Võti Noude liikKokkuvõte Kirjeldus Olek Täitmise

eest

vastutaja

NA-1 Andme kvalitee t ja standar did

Loodavate lahenduste X-tee teenused peavad vastama RIA x-tee juhendis toodud nõuetele.

KEHTIV Arhitekt /juhtiv arendaja

NA-2 Andme kvalitee t ja standar did

Lahendusega koos tarnitav standardtarkvara peab vastama RIK nõuetele.

Kui hankes ei spetsifitseerita tarkvaralist lahendust tuleb kasutada vastaval konkreetsele vajadusel allpool toodud tarkvarade viimaseid stabiilseid versioone.

Serverite operatsioonisüsteemina: 1) Linux RedHat Enterprise/Rocky 2) Windows

Andmebaasidena: 1) Microsoft SQL 2) Postgre SQL 3) MariaDB

Veebiserverina: 1) Nginx 2) Microsoft IIS 3) Apache

Rakendusserverina: 1) Tomcat

Programmeerimiskeelena : 1) C# 2) Java 3) Python

Kui koos tarnega tarnitakse kommertstarkvara peab selle litsents sisaldama vähemalt 5 aasta turvaparandusi

KEHTIV Arhitekt /juhtiv arendaja

NA-3 Andme kvalitee t ja standar did

Rakendus peab olema loodud vastavalt Eesti Infoturbestandardi nõuetele.

Aluseks tuleb võtta hanke väljakuulutamise hetkel kehtiva versiooni meetmeid. KEHTIV Arhitekt /juhtiv arendaja

NA-4 Andme kvalitee t ja standar did

Avalik sektor arendab riigi tarkvara eelkõige avatult ja avaldab tarkvara vaba litsentsiga vastavalt litsentsi nõuetele.

Antud nõudes võib erandeid teha ainult juhul, kui on teisiti ette nähtud seadusega või muul tellijaga kokku lepitud põhjendatud juhul.

RIKis kasutatavad levinuimad vaba tarkvara litsentsid on EUPL, GNU GPL, MIT. Litsentsi valik sõltub vajadustest ja kohustustest ning tuleb kokku leppida tellijaga.

Litsentside litsentsitingimustes sisalduvad nõuded, mida tuleb litsentsi kasutamisel täita, on järgmised: EUPLi puhul on nõutav mh: 1) autoriõiguse märge päises (Copyright © <aasta> <autori nimi>), mille järel on märge „Litsentsitud EUPL alusel “).

GNU GPL puhul on nõutav mh: 1) autoriõiguse märge päises (Copyright © <aasta> <autori nimi>); 2) litsentsitingimustes ette nähtud teavitus töö osas garantii välistamise kohta.

MIT puhul on nõutav mh: 1) autoriõiguse märge päises (Copyright © <aasta> <autori nimi>) koos litsentsis ette nähtud teavitusega; 2) litsentsitingimustes ette nähtud teavitus töö osas garantii välistuse kohta.

Täpsemalt tuleb nõuetega tutvuda lähtudes valitud litsentsitüübi litsentsitingimustest. Valitud litsentsi litsentsitingimused esitatakse ühel või mõlemal alljärgnevatest viisidest: 1) LICENCE-fail peab olema repositooriumis avalikustatud koos tarkvara koodiga; 2) litsentsitingimuste tekst iga faili päises; 3) lisades päisesse link asukohale, kus on võimalik litsentsitingimustega tutvuda.

KEHTIV Tiimijuht

NA-5 Arhitekt uur

Komponendid peavad olema sellised, mille eluea lõpp (EOL) pole teadaolevalt vähem kui 2 aasta pärast.

Erindid tuleb eraldi kokku leppida Strateegia tiimiga. KEHTIV Arhitekt /juhtiv arendaja

NA-6 Arhitekt uur

Infosüsteemide komponendid ja topoloogia peab olema enne reaalse arenduse algust RIK-iga kooskõlastatud.

Kooskõlastamist koordineerib Strateegia tiim (peaarhitekt). KEHTIV Arhitekt /juhtiv arendaja

NA-7 Arhitekt uur

Rakendusserver peab võimaldama töötamist andmebaasiserverist eraldi serveril.

KEHTIV Arhitekt /juhtiv arendaja

NA-8 Arhitekt uur

Rakendust peab saama ilma ümber programmeerimata liigutada erinevate domeenide ja domeeni saitide vahel

Lahendus ei tohi olla sisse kompileeritud absoluutseid URL-e. KEHTIV Arhitekt /juhtiv arendaja

NA-9 Arhitekt uur

Väliseid liidestusi peab olema nii vähe, kui võimalik. Liideseid peab saama konfiguratsioonist välja lülitada. Väliste liidestuste veaolukorrad peavad olema käsitletud. Süsteem peab toimima mitte-ärikriitiliste liidestusteta.

KEHTIV Arhitekt /juhtiv arendaja

NA-10 Arhitekt uur

Andmevahetus riigi infosüsteemi kuuluvate andmekogudega ja riigi infosüsteemi kuuluvate andmekogude vahel toimub läbi riigi infosüsteemi andmevahetuskihi (x-tee).

Avaliku teabe seaduse § 43 (9) lõige 5. Kui X-tee päringut teostab inimene, siis peab olema päringu päises autentinud kasutaja andmed.

KEHTIV Arhitekt /juhtiv arendaja

NA-11 Arhitekt uur

Rakenduste keskkonnad peavad kasutama vastavate X-tee turvaserverite otspunkte.

Arendus vastu arenduse otspuntki jne. KEHTIV Arhitekt /juhtiv arendaja

NA-12 Arhitekt uur

Rakendus peab olema konfigureeritav ühest kohast ilma kompileerimisvajaduseta.

Konfiguratsiooni võib vajadusel automaatselt kopeerida, ilma muutmata, kesksest kohast mujale (näiteks helm chartis values failist kopeerimine mitmesse configmapi). Logimise seaded võivad olla rakenduse konfiguratsioonifailist eraldi ühes lisakonfiguratsioonifailis (näiteks Log4net).

KEHTIV Arhitekt /juhtiv arendaja

NA-13 Arhitekt uur

Kompileeritud rakenduse paigaldamine peab toimuma mõistliku aja jooksul.

Mõistlik aeg on kuni 1 minut. KEHTIV Arhitekt /juhtiv arendaja

NA-14 Arhitekt uur

Rakendus peab olema 64-bitine. KEHTIV Arhitekt /juhtiv arendaja

NA-15 Arhitekt uur

Andmebaas ja rakendus peavad kasutama UTF-8 kodeeringut.

Nõue kehtib Oracle ja Postgre andmebaaside puhul. Erindid lepitakse eraldi Strateegia tiimiga kokku. Näiteks UTF-16.

KEHTIV Arhitekt /juhtiv arendaja

NA-16 Arhitekt uur

Failid peab katalogiseerima aasta > kuu > kuupäev. Täpsem lahendus leppida Strateegia tiimiga kokku. KEHTIV Arhitekt /juhtiv arendaja

NA-17 Arhitekt uur

Üldine programmeerimise paradigma on objekt- orienteeritud.

Erindid tuleb eraldi Strateegia tiimiga kokku leppida. KEHTIV Arhitekt /juhtiv arendaja

NA-18 Arhitekt uur

Kõik baasitabelite välisvõtmed peavad olema indekseeritud.

Indekseid ja muid meetmeid kasutatakse andmebaasi jõudluse tõstmiseks. Väliseid võtmeid tuleb kasutada ka ühest andmebaasist teisele viitamisel.

KEHTIV Arhitekt /juhtiv arendaja

NA-19 Arhitekt uur

Tuleb kasutada päringumuutujaid (inglise keeles "Parameter Binding")

SQL päringute väljakutsumisel väljastpoolt andmebaasi peab kasutama päringumuutujaid, et vältida SQL vahemälu fragmenteerumist.

KEHTIV Arhitekt /juhtiv arendaja

NA-20 Arhitekt uur

Andmebaasitabelites peab olema tehniline primaarvõti.

Nimetus peab olema „ID“ KEHTIV Arhitekt /juhtiv arendaja

NA-21 Arhitekt uur

Failid ja failide indeks peavad olema replikeeritavad teise serveriruumi.

Failide hoidmise asukoht ja loogika on vastavalt kokkuleppele. KEHTIV Arhitekt /juhtiv arendaja

NA-22 Arhitekt uur

Haldustoimingute tegemiseks peab olema vastav haldusliides.

Eemärk on vähendada otse baasis tehtavaid toiminguid. KEHTIV Arhitekt /juhtiv arendaja

NA-23 Arhitekt uur

Andmebaas peab toetama külm- ja kuumvarundamist teise serveriruumi.

Ei tohi kasutada teenuseid, mis välistavad andmebaasi peegeldamist (nt "failstream"). KEHTIV Arhitekt /juhtiv arendaja

NA-24 Arhitekt uur

Sorteerimisreeglistik peab vastama eesti keele tähestikule.

Peab kasutama case-insensitive, accent-sensitive sorteerimist. KEHTIV Arhitekt /juhtiv arendaja

NA-25 Arhitekt uur

Kasutama peab RIK-i elektronposti serverit. Kirjade saatmine ja mall peavad olema konfigureeritavad. Juhul kui elektronposti server ei võta kirju vastu, siis tuleb need uuesti saata elektronposti teenuse taastumisel.

KEHTIV Arhitekt /juhtiv arendaja

NA-26 Arhitekt uur

Konfiguratsiooniparameetrite nimed peavad olema sisulised.

Näiteks : X-tee Turvaserver, mitte XTTS või viitenumber, mitte vk_seb jne. KEHTIV Arhitekt /juhtiv arendaja

NA-27 Arhitekt uur

Ees -ja tagasüsteemid peavad olema arhitektuuriliselt selgelt lahutatud.

Ees -ja tagasüsteemid peavad olema eraldi paigaldatavad ja konfigureeritavad. KEHTIV Arhitekt /juhtiv arendaja

NA-28 Arhitekt uur

Konfiguratsioonifailid peavad olema vaikimisi kaitstud failid.

Näiteks IIS: *.config , *.resources Apache: *.conf, .htaccess. Kui neid on mitu, siis arendaja peab need eraldi välja tooma konfiguratsioonifailide listis. 

KEHTIV Arhitekt /juhtiv arendaja

NA-29 Arhitekt uur

Lõpp-kasutaja näeb vaid faile, mida ta peab nägema.

KEHTIV Arhitekt /juhtiv arendaja

NA-30 Arhitekt uur

Konfiguratsioonis ei tohi olla sisult dubleerivaid parameetreid.

Kõiki parameetreid tuleks konfiguratsioonis kirjeldada vaid üks kord.

Näiteks nii ei tohi olla: = "Server=myServerAddress;Database=myDataBase;User Id=myUsername;connectionString

Password=myPassword;" = "Server=myServerAddress;Database=myDataBase;User Id=myUsername;Password=myPassword;"_cString

KEHTIV Arhitekt /juhtiv arendaja

NA-31 Arhitekt uur

Rakendused peavad olema kõrgkäideldavad. Meie arendatud rakendused ja kasutatavad karbitooted peavad olema kõrgkäideldavad. ei ole Sticky sessionid soovitatud, vajadus eraldi läbi rääkida.

KEHTIV Arhitekt /juhtiv arendaja

NA-32 Arhitekt uur

Süsteemiintegratsioonid peavad klientrakendusele olema peidetud.

Näiteks klientrakendus ei tohi pöörduda otse andmebaasi ja x-tee poole. KEHTIV Arhitekt /juhtiv arendaja

NA-33 Arhitekt uur

Keskkonnapõhiseid muutujad peavad olema konfiguratsioonist seadistatavad.

Näiteks WSDL ei tohi sisaldada viiteid arendusserveritele. KEHTIV Arhitekt /juhtiv arendaja

NA-34 Arhitekt uur

Windows teenuste nimed peavad olema konfigureeritavad.

KEHTIV Arhitekt /juhtiv arendaja

NA-35 Arhitekt uur

Andmebaasi ei tohi realiseerida rakenduse äriloogikat.

Andmebaas võib sissetulevate andmetega teha ainult tehnilisi tegevusi. Välja arvatud taustatööd. Näiteks õiguste arvutamine või unikaalsete võtmete genereerimine.

KEHTIV Arhitekt /juhtiv arendaja

NA-36 Arhitekt uur

Andmebaasi peab olema võimalik viia MS-SQL standarditele.

Ei tohi kasutada platvormispetsiifilist lahendusi. Erindid eraldi kokku leppida Strateegia tiimiga. KEHTIV Arhitekt /juhtiv arendaja

NA-37 Arhitekt uur

Rakendus peab kasutama autentimiseks RIK poolt heaks kiidetud OpenID põhist autentimislahendust.

Autentimisviisid peavad olema konfigureeritavad. Samuti peab rakenduse konfiguratsioonist olema määratav, kas ID-kaardiga autentimise korral kasutatakse OCSP või tühistusnimekirjade põhist autentimist.

KEHTIV Arhitekt /juhtiv arendaja

NA-38 Arhitekt uur

Uniform resource identifier (URI) pikkus ei tohi ületada ühegi IS poolt toetatava brauseri maksimaalset lubatud väärtust.

Max uri < 2000. KEHTIV Arhitekt /juhtiv arendaja

NA-39 Arhitekt uur

Rakenduse teenusekirjeldus peab olema üles ehitatud nii, et see toetaks teenuse versioneerimist.

Teenuste kirjelduses võimalike complexType versioonide väärtus "any" KEHTIV Arhitekt /juhtiv arendaja

NA-40 Arhitekt uur

Rakenduse operatiivbaas peab olema arhiveeritav. Enamasti tehakse seda osadena, näiteks juriidiliselt aegunud menetlused, mida kasutajad enam ei näe. KEHTIV Arhitekt /juhtiv arendaja

NA-41 Arhitekt uur

Rakendusega tarnitavad litsentsid peavad olema vähemalt 5-aastase kehtivusajaga.

EU projektide korral tuleb kehtivusaja suhtes lähtuda EU või RIA nõuetest. KEHTIV Tiimijuht

NA-42 Arhitekt uur

Rakendus peab olema jaotatud loogilisteks tehnilisteks osadeks.

Loogiline jaotus lähtub äri vajadustest, haldusest ja arendusest. Tehnilised osad peavad olema eraldi paigaldatavad.

KEHTIV Arhitekt /juhtiv arendaja

NA-43 Arhitekt uur

Failide konverteerimised tuleb teha kasutades RIKi poolt heaks kiidetud teenuseid.

KEHTIV Arhitekt /juhtiv arendaja

NA-44 Arhitekt uur

Kasutaja ei tohi pääseda ligi süsteemi tehnilisele informatsioonile.

Näiteks stack trace, tehnilised logid, täispikavad failinimed, kasutatavad tehnoloogiad ja raamistikud ning nende versioonid.

KEHTIV Arhitekt /juhtiv arendaja

NA-45 Arhitekt uur

Rakendus peab olema stateless. Peab töötama koormusjaoturiga, ei kasuta , SSL offload.sticky sessioneid KEHTIV Arhitekt /juhtiv arendaja

NA-46 Arhitekt uur

Rakenduse failide ligipääsuvajadus peab olema read-execute.

Konteinerite puhul vastutab arendaja, muul juhul administraator. KEHTIV Arendaja /juhtiv arendaja /administraat or

NA-47 Arhitekt uur

Windows serverid peavad töötama windows core serveritel.

KEHTIV Arhitekt /juhtiv arendaja

NA-48 Arhitekt uur

Andmebaasis tuleb veerutüübiks määrata selleks sisuliselt sobivaim andmetüüp.

Lähtuda andmebaasimootori dokumentatsioonist. Keelatud on kasutada (max) tüüpe, kui see pole põhjendatud ja vajalik.

KEHTIV Arhitekt /juhtiv arendaja

NA-49 Arhitekt uur

Rakenduste masinliidestel peab olema publitseeritud tehniline spetsifikatsioon.

Ei kehti karbitoodetele. Näiteks SOAP WSDL ja REST OpenApi Swagger ei tohi olla publitseeritud.

Tehnilises spetsifikatsioonis peavad olema: otspunkti kirjeldus, otspunkti kirjelduse väljalülitamine.

KEHTIV Arhitekt /juhtiv arendaja

NA-50 Arhitekt uur

Active Directory(AD) autentimise kasutamisel peab rakendus kasutama kehtivaid standardeid.

SAML2.0 (Security Assertion Markup Language) ja ADFS (Active Directory Federation Services). KEHTIV Arhitekt /juhtiv arendaja

NA-51 Arhitekt uur

ID-kaardiga autentimise korral kliendipoolne veebirakendus suhtleb veebirakendusega ainult kontrollküsimuse tarbeks.

Edasine koodi täitmine ja võimalike veaolukordade töötlus peab toimuma rangelt ainult kliendi poolel.

Kliendi autentimissertifikaadi kehtivus- ja autentsusekontroll teostatakse maksimaalses võimalikus mahus veebiserveri või proxy poolt.

Autentimissertifikaadil on veebiserveri või proxy poolt kohustuslikult nõutav: Apache: SSLVerifyClient require; NGINX: ssl_verify_client on; Pulse TM: ssl.requireCert(); HAProxy: verify required; Tomcat: clientAuth="true"; jne…                    

Juhul kui toimub pöördub URL poole, kus on nõutud kliendi autentimissertifikaat ning server vastab veaga, peab klientrakendus kuvama korrektse veateate eesti keeles.

KEHTIV Arhitekt /juhtiv arendaja

NA-52 Arhitekt uur

Robotilõksude kasutamine ja valik tuleb kooskõlastada RIK-ga.

Soovitus on robotlõkse vältida ja lahendada potentsiaalne probleem kasutades koormusjaotureid ja IP-põhiseid reegleid.

KEHTIV Arhitekt /juhtiv arendaja

NA-53 Arhitekt uur

Rakendusetevaheline suhtlus peab olema masintöödeldav.

Üldiselt kasutame REST, SOAP(x-tee) või message queued. Muud juhud eraldi läbi rääkida Strateegia tiimiga. KEHTIV Arhitekt /juhtiv arendaja

NA-54 Arhitekt uur

Rakendusserverite otspunktid peavad olema piiratud ja dokumenteeritud.

Rakendus vastab ainult lubatud HTTP-meetoditele, ülejäänud annavad veakoodiga "405" viga. KEHTIV Arhitekt /juhtiv arendaja

NA-55 Arhitekt uur

Rakendusserver peab valideerima ja võimalusel verifitseerima e-posti aadresse.

Peab vastama RFC5322 ja/või RFC6854 standardile.

Võimalusel peab süsteem tõendama kasutaja e-posti aadresse(verifitiseerima)

KEHTIV Arhitekt /juhtiv arendaja

NA-56 Arhitekt uur

Rakendusel peab olema minimaalne CSP header, et funktsionaalsust tagada.

Erandid tuleb hoolikalt läbi mõelda. Väikeväärtus "self"

Täiendav info:

https://csp-evaluator.withgoogle.com/ https://www.hardenize.com/dashboards https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-WebSocket-Accept

KEHTIV Arhitekt /juhtiv arendaja

NA-57 Infoturv e

Kliendi ja serveri vaheline suhtlus peab kasutama TLS-protokolli.

Uusim või kehtiva toega versioon. KEHTIV Arhitekt /juhtiv arendaja

NA-58 Infoturv e

Andmete salvestamisel kliendi arvutisse kasutada baruseri vault-i.

Erandiks on mitmekeelse süsteemi puhul keelevalik. KEHTIV Arhitekt /juhtiv arendaja

NA-59 Infoturv e

Sessiooni lõpetamisel või aegumisel ei tohi kasutajal olla võimalik sessiooni värskendada või uuesti kasutada.

KEHTIV Arhitekt /juhtiv arendaja

NA-60 Infoturv e

Andmebaasis olevate terviklikkuse turvaosaklass 2 või 3 andmete andmebaasi kirjed peab versioneerima.

Versioneerimisel peavad säilima vanad kirjed muutumatul kujul. Uue kirje tehnilistel väljadel peab olema: Kasutaja, kes kirje lõi ja loomise aeg. Kehtetuks tunnistatud kirje peab sisaldama: Kirje muutja, muutmise /kustutamise aeg.

KEHTIV Arhitekt /juhtiv arendaja

NA-61 Infoturv e

Live andmed ei kasutata testimiseks. Testimiseks kasutatakse sünteetilisi, genereeritud andmeid. Erindid tuleb Strateegia tiimiga eraldi kokku leppida.

KEHTIV Arhitekt /juhtiv arendaja

NA-62 Infoturv e

Rakenduse andmebaasikontod peavad omama minimaalseid õigusi.

Rakendus ei kasuta kontot. Kontodele vajalikud õigused peavad olema kirjeldatud rakenduse schema installatsioonijuhendis.

KEHTIV Arhitekt /juhtiv arendaja

NA-63 Infoturv e

Rakenduse lõppkasutajatele peavad olema õigused defineeritud läbi rollide(RBAC).

Kasutada KeyCloaki. AD OU ei tohi anda rolli. KEHTIV Arhitekt /juhtiv arendaja

NA-64 Infoturv e

Rakendusse ja andmebaasi ligipääsemiseks peab kasutama ainult kokkulepitud dokumenteeritud autentimisprotseduure.

KEHTIV Arhitekt /juhtiv arendaja

NA-65 Infoturv e

Salasõnad salvestatakse turvaliselt. Krüpteering peab olema CBC, CRT vms režiimis. Kasutada ei tohi ECB režiimi. Räsi+sool+pipar osas lähtuda OWASP-i juhisest https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html

KEHTIV Arhitekt /juhtiv arendaja

NA-68 Infoturv e

Kõik avalikud veebirakendused peavad kasutama veebitulemüüre.

IIS puhul peab kasutama näiteks URL scan, apache puhul modsecurity või vastavat tööriista. Võimalikud piirangud tuleb kokku leppida tellijaga detailanalüüsi käigus lähtuvalt tellija vajadustest ja nõudmistest. Kasutama peab whitelisting põhimõtet, mitte blacklistingut. Täiendavalt on kasutusel veebitulemüür (CloudFlare)

KEHTIV Arhitekt /juhtiv arendaja

NA-69 Infoturv e

Rakendus peab õnnestunud sisselogimise järgselt näitama eelmise õnnestunud sisselogimise aega.

EU-direktiiv https://www.etsi.org/deliver/etsi_en/301500_301599/301549/03.02.01_60/en_301549v030201p.pdf KEHTIV Arhitekt /juhtiv arendaja

NA-70 Infoturv e

Kasutajaliidesega rakendusel peab olema esilehel rakenduse versioon.

Mõeldud on majas sees arendatud rakendusi. Rakendusserverite ja andmebaaside puhul kehtib vastupidine nõue: .NA-44

KEHTIV Arhitekt /juhtiv arendaja

NA-71 Infoturv e

Sessioonide lõpetamine tuleb teostada serveri poolel ja kõigil rakendustel peab olema konfigureeritav kasutajasessiooni aegumise aeg.

Aeg peab olema muudetav koos teiste konfiguratsiooniparameetritega. Kui kliendilt pole etteantud aja jooksul ühtegi päringut tulnud, tuleb sessioon serveri enda algatusel lõpetada.

Täiendavalt saab lugeda https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet. html

KEHTIV Arhitekt /juhtiv arendaja

NA-72 Infoturv e

Kõik sisendandmed tuleb kodeerida, filtreerida ja valideerida.

Siia hulka kuuluvad vormid, masin-masin liidesed ja veebiteenused. Tuleb teha enne igasugust äriloogika täitmist.

KEHTIV Arhitekt /juhtiv arendaja

NA-73 Infoturv e

Veebipõhiste rakenduste poolt saadetavad vormidel peab paiknema peidetud unikaalne räsi, mida kontrollitakse vormi vastuvõtmisel.

Eesmärk on vältida CSRF rünnakuid. KEHTIV Arhitekt /juhtiv arendaja

NA-74 Infoturv e

Krüpteerimisel ja räsimisel tuleb lähtuda RIA uuringust.

Lähtuda viimasest dokumendist siin nimekirjas https://www.id.ee/artikkel/kruptograafiliste-algoritmide-elutsukli- uuringud-2/

KEHTIV Arhitekt /juhtiv arendaja

NA-75 Infoturv e

Sessiooni tunnused ei tohi olla URL-st kopeeritavad.

https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html KEHTIV Arhitekt /juhtiv arendaja

NA-76 Infoturv e

Konfiguratsioonifaile võivad muuta vaid administraatorid.

Kui rakendusel on admin liides arendatud siis seal muudatuste tegemine on OK. Muud erindid rääkida läbi strateegiatiimiga.

KEHTIV Arhitekt /juhtiv arendaja

NA-77 Infoturv e

Kliendi sertifikaadiga rakenduse poolsel autentimisel (näiteks ID-kaart) peab rakendus vastu võtma sertifikaati HTTP päises.

Kliendi sertifikaadiga autentimisel peaks süsteem vastu võtma kliendi sertifikaati kokkulepitud päises, päise nimi peaks olema rakenduse seadistustega muudetav. Vajadus tuleneb kliendi sertifikaatide usaldusnimekirjade GLB taseme haldusest. Sertifikaat võetakse vastu kliendi veebilehitseja poolt ning edastatakse GLB’le, GLB määrab selle kokkulepitud päisesse sobivuse korral, GLB edastab juba kontrollitud sertifikaadi süsteemi kokkulepitud päises.

Sama asi kehtib mistahes kliendi sertifikaadiga autentimisel ning suvalisest kohast ei tohikski süsteem sertifikaate vastu võtta.

KEHTIV Arhitekt /juhtiv arendaja

NA-78 Infoturv e

Kõik digitembeldamist vajavad rakendused peavad kasutama RIK-i digitembeldamise teenust.

KEHTIV Arhitekt /juhtiv arendaja

NA-79 Infoturv e

Rakenduse turvalisuse tagamiseks tuleb järgida OWASP-i parimaid praktikaid.

Veebirakendus peab probleemideta läbima OWASP ASVS põhineva testi. Esmane väline turvatestimine tellitakse tellija finantseeringul. Kui selle tulemusel leitakse arendaja poolsest tegevusest või tegevusetusest põhjustatud vigu, võib tellija nõuda OWASP järeltestide kompenseerimist arendajalt. Täiendavalt saab uurida https://github. com/OWASP/ASVS

KEHTIV Arhitekt /juhtiv arendaja

NA-80 Arhitekt uur

Rakendus peab olema optimeeritud toodangukeskkonnas toimimiseks.

Toodangukeskkonna rakendus ei tohi sisaldada osiseid, mis on ebavajalikud. NT. Debug logi, testimiseks vajalikud erisused äriloogikast. Rakendust peab olema võimalik uuesti pakendamata tarnida vabalt valitud keskkonda(arendus,test).

KEHTIV Arhitekt /juhtiv arendaja

NA-81 Infoturv e

Ajatemplite kasutamisel eelistatakse RIK-i heaks kiidetud lahendust.

Heaks kiidetud lahenduste kohta info annab OPS-tiim. KEHTIV Arhitekt /juhtiv arendaja

NA-82 Infoturv e

Rakendused peavad toetama SSO kasutamist. Sessioon peab olema stateless KEHTIV Arhitekt /juhtiv arendaja

NA-83 Infoturv e

Süsteemile määratud turvaosaklass peab olema täidetud vastavalt määruse "Võrgu- ja infosüsteemide küberturvalisuse nõuded" paragrahv 10-le.

https://www.riigiteataja.ee/akt/113122022030

Enne arenduste algust tuleb turvaosaklassist tulenevad vajadused kooskõlastada Infoturbe ja IS halduse tiimiga

KEHTIV Arhitekt /juhtiv arendaja

NA-86 Infoturv e

Paks klient peab krüpteerima ajutised failid, mis sisaldavad delikaatseid/konfidentsiaalseid andmeid ja need sulgemisel kustutama.

Kui paks klient kasutab ajutisi faile, tuleb tagada nende perioodiline kustutamine tagamaks, et ei koormata liigselt kasutaja arvutit. Eesmärk on tagada, et rakenduse sulgemisel ei jääks kasutaja arvutisse maha informatsiooni, mida sinna jääda ei tohiks.

KEHTIV Arhitekt /juhtiv arendaja

NA-87 Infoturv e

Rakendus peab serverist kustutama kõik ajutised failid koheselt, kui neid enam ei kasutata.

Ajutiste failide kaust peab olema konfigureeritav. KEHTIV Arhitekt /juhtiv arendaja

NA-88 Infoturv e

Rakendus tohib aksperteerida ainult enda väljastatud sessioonivõtmeid.

KEHTIV Arhitekt /juhtiv arendaja

NA-89 Infoturv e

Rakendusse üleslaetavad failid peab filtreerima, valideerima ja need peavad läbima viirusetõrje.

Tuleb teha tüübi ja faili laiendi vastavause kontroll. Failide üleslaadimise ülempiir peab olema analüüsis kirjeldatud.

Filtreerimine - whitelisting, sh suurus

Valideerimine - äriloogiline vastavus

Viirusetõrje - Rik.Icap.VirusScanner: https://hoidla.rik.ee/#browse/browse:nuget-hosted:Rik.Icap.VirusScanner% 2F1.0.0%2FRik.Icap.VirusScanner-1.0.0.nupkg Kontrollib, kas failis on viirus. Kasutamise näited: KrisDoc2 ( ), KRIS4 ( ), KrAvalik ( ), KAEP ( )KRIS-4642 KRIS-4645 KRIS-4643 KRIS-4644 Alternatiivselt võib dll-i kompileerida lähtekoodist: https://svn.just.ee/!/#riksvn/view/head/VirusScanner/trunk

KEHTIV Arhitekt /juhtiv arendaja

NA-90 Infoturv e

Rakendusse üleslaetava faili peab salvestama unikaalse genereeritud nimega.

Faili originaalnimi tuleb salvestada andmebaasi. KEHTIV Arhitekt /juhtiv arendaja

NA-91 Infoturv e

Rakendus ei tohi lubada ennast kasutada iframe sees.

Kasutada CSP headerit.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-Fetch-Mode

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options

KEHTIV Arhitekt /juhtiv arendaja

NA-92 Infoturv e

Sessiooni küpsisel peavad olema turvalisuse lipud ja prefix __Host.

Sessiooni küpsise korrala tuleb lisada lipud Secure, HttpOnly ja SameSite. Küpsise nime prefiks peab olema "__Host-". Täiendav info: 1)https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie

2) https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/06- Session_Management_Testing/02-Testing_for_Cookies_Attributes

3) https://owasp.org/www-community/HttpOnly

4) https://owasp.org/www-community/controls/SecureCookieAttribute

5) https://owasp.org/www-community/SameSite#:~:text=SameSite%20prevents%20the%20browser%20from, .none%20%2C%20lax%20%2C%20or%20strict%20

KEHTIV Arhitekt /juhtiv arendaja

NA-93 Lähtek ood

Rakenduse kõik üleantavad versioonid peavad enne tellijale üle andmist olema testitud.

Testplaan ja skoop tuleb arenduse käigus tellijaga kokku leppida. KEHTIV Arhitekt /juhtiv arendaja

NA-94 Logimin e ja monito oring

Kriitilised sündmused - sessiooni algamine ja lõppemine ning rolli muutumine tuleb eraldi logida turvalogide tabelis.

Väliste rakenduse puhul tuleb logida kasutaja IP. Sessiooni võtmete väärtused, privaatvõtmed, kasutaja salasõnad ja muu info, mis võimaldab kasutaja isiku kindlakstegemist või on andmekaitset ohustav ei või logisse jääda.

KEHTIV Arhitekt /juhtiv arendaja

NA-95 Logimin e ja monito oring

Rakendus peab logima kõiki väliste süsteemidega vahetatavaid (ka X-tee teenuste kaudu liikuvaid) pöördumisi andmevahetuslogisse.

Parim vahend on Graylog, teine valik baas, kolmas valik on faili logimine. Peab olema võimalus antud logimist välise süsteemi kaupa sisse-välja lülitada. Logi peab olema struktureeritud selliselt, et päring ja vastus on eraldi failides. Logifaili asukoht peab olema administraatori poolt ilma rakendust uuesti kompileerimata seadistatav.

KEHTIV Arhitekt /juhtiv arendaja

NA-98 Logimin e ja monito oring

Rakendus peab logima kõiki rakenduses tekkivaid tehnilisi vigu.

Logi peab sisaldama minimaalselt aega(timestamp), veakoodi, vea sisu (komponent, stack trace, traceback vms), kogu HTTP päringut ja võimalusel kasutaja ID-d. Logimine peab olema konfigureeritav rakenduse taaskäivituseta.

KEHTIV Arhitekt /juhtiv arendaja

NA-99 Logimin e ja monito oring

Failisüsteemi logimise korral peavad logid olema katalogiseeritud, tunnustatud faililaiendiga, roteeruvad.

Peab olema võimalus logimist välise süsteemi kaupa sisse-välja lülitada. Failisüsteemi kausta ei teki rohkem kui 10000 faili. Peab tagama, et iga rakendusserver saaks vajadusel kirjutada logid oma logifaili. Logimine peab olema konfigureeritav rakenduse taaskäivituseta.

KEHTIV Arhitekt /juhtiv arendaja

NA-100 Logimin e ja monito oring

Rakenduse logid peavad olema ühesuguse formaadiga, masinloetavad ja täielikud.

Logiväljad, mida lõppkasutaja saab manipuleerida (IP, useragent, URL) peavad salvestuma logisse kodeeritud ja puhastatud kujul. Igas logikirjes peab olema päringu unikaalne identifikaator. Kui parameetri väärtus on tühi, tuleb see logis märkida asendusväärtusega “-”. Logi kuupäeva ja ajaformaat peab vastama ISO 8601 standardile ja olema Eesti ajavööndis.

KEHTIV Arhitekt /juhtiv arendaja

NA-101 Logimin e ja monito oring

Logi tabelid peavad olema arhiveeritavad operatiivbaasist välja.

Tabeli suurenedes peab olema võimalik hoida vanu kirjeid, näiteks kuude või aastate kaupa, iseseisvates tabelites või teises baasis. Mehhanism peab töötama ka krüptoaheldatud logi korral.

KEHTIV Arhitekt /juhtiv arendaja

NA-102 Logimin e ja monito oring

Kui rakendus kasutab või pakub väliseid teenuseid peab nende kohta arvestust pidama.

Peab kasutama statisikamoodulit või OpenTelemetry-t. KEHTIV Arhitekt /juhtiv arendaja

NA-103 Lähtek ood

Süsteem peab enne toodangusse minemist läbima jõudlustestid.

Täpne kirjeldus tuleb kokku leppida detailanalüüsi käigus. Lähtuda sellest -> https://dok.rik.ee/display/SUS /Koormustestimise+tellimise+eeldused+-+Beeta

KEHTIV Arhitekt /juhtiv arendaja

NA-104 Logimin e ja monito oring

Rakendusel peab olema masinloetav staatusleht. KEHTIV Arhitekt /juhtiv arendaja

NA-106 Lähtek ood

Kõik kommentaarid peavad olema põhjendatud. Lähtekoodi kommentaarid peavad olema: 1. Kood peab olema kirjutatud selliselt, et see on loetav ka ilma kommentaarideta. Kommentaarid on mõeldud keeruliste ja/või kohendamist ja/või edasist tööd (viimaste juurde tuleks märkida TODO) vajavate kohtade jaoks. 2. Aktuaalsed - kommentaar ja kood peavad olema üksteisega vastavuses. 3. Selged ja üheselt mõistetavad. 4. Korrektselt kirjutatud - grammatika ja lauseehitus peavad olema korrektsed. 5. Andmebaasi falid ning muud koodid samadel alustel 6. Peavad olema kirjutatud eesti keeles

KEHTIV Arhitekt /juhtiv arendaja

NA-107 Lähtek ood

Nimetused koodis peavad olema sisulised ja andma selget informatsiooni nende otstarbest.

Projekti skoobis peab olema kokku lepitud nimetamis-reeglistik. KEHTIV Arhitekt /juhtiv arendaja

NA-108 Lähtek ood

Koodis kasutatavad konstandid tuleb defineerida muutujatena.

Siia alla ei kuulu klassifikaatorid. Need peavad olema baasis. KEHTIV Arhitekt /juhtiv arendaja

NA-109 Lähtek ood

Koodis defineeritud andmetüübid peavad olema nimetava käände ainsuses. Kõik andmemassiivid tuleb nimetada nimetava mitmuses.

Näiteks "Isik", "Menetlus" jne. Andmebaasides ei tohi kasutada täpitähti.

Lisainformatsioon:

1) C# - https://learn.microsoft.com/en-us/dotnet/standard/design-guidelines/general-naming-conventions

2) JAVA - https://www.oracle.com/java/technologies/javase/codeconventions-namingconventions.html

3) Python - https://peps.python.org/pep-0008/

KEHTIV Arhitekt /juhtiv arendaja

NA-110 Lähtek ood

Andmetabelites sisalduvad võõrvõtmed peavad nime järgi seostuma tabeli ja väljaga millele need viitavad.

Näiteks kui on tegu tabelitega ’Isik’ ja ’Auto’, siis seos ’isik_auto’ oleks: Isik.ID=Auto.Isik_ID KEHTIV Arhitekt /juhtiv arendaja

NA-111 Lähtek ood

Andmebaasi väljade pikkused peavad lähtuma analüüsis kirjeldatud nõuetest.

Tuleb meeles pidada, et 1 byte ei pruugi võrduda 1 tähemärgiga, näiteks täpitähed. KEHTIV Arhitekt /juhtiv arendaja

NA-115 Lähtek ood

Koodi valideerimiseks kasutame SonarQube reegleid.

Koos SonarQube-ga peab tegema ka Trivy skaneerimise. KEHTIV Arhitekt /juhtiv arendaja

NA-118 Lähtek ood

Lähtekoodis ei tohi olla mitte kasutatavaid osasid. KEHTIV Arhitekt /juhtiv arendaja

NA-120 Lähtek ood

Koodibaasis olevad ärilised terminid peavad olema eesti keeles.

Ärianalüüs ja kood peavad teineteist peegeldama. Ka andmebaasis olevad nimetused peavad olema eesti keeles. KEHTIV Arhitekt /juhtiv arendaja

NA-121 Andme kvalitee t ja standar did

Aadressiandmete käitlemisel lähtuda määrusest "Aadressiandmete süsteem."

Kasutada ADS-i. Link määrusele https://www.riigiteataja.ee/akt/128122024043 KEHTIV Arhitekt /juhtiv arendaja

NA-123 Infoturv e

Iga transaktsiooni juures tuleb kontrollida kasutaja õiguseid ja rollikuuluvust.

OWASP nõuetest -> "Validate the Permissions on Every Request" https://cheatsheetseries.owasp.org /cheatsheets/Authorization_Cheat_Sheet.html#validate-the-permissions-on-every-request

KEHTIV Arhitekt /juhtiv arendaja

NA-124 Andme kvalitee t ja standar did

Tegevusalade käitlemisel lähtuda määrusest "Klassifikaatorite süsteem."

Kasutada RIK EMTAK teenust. https://www.riigiteataja.ee/akt/12910889 KEHTIV Arhitekt /juhtiv arendaja

NA-126 Infoturv e

Süsteemist väljaminevad veateated ei tohi sisaldada süsteemiinfot.

Näiteks: "Tekkis tehniline viga. Päringu ID: XXXXX". Reaalne veateade peab logis säilima! KEHTIV Arhitekt /juhtiv arendaja

NA-127 Dokum entatsio on

Kogu rakenduse dokumentatsioon peab olema kirjutatud eesti keeles.

Erandiks kolmandate osapoolte komponendid. KEHTIV Arhitekt /juhtiv arendaja

NA-128 Dokum entatsio on

Dokumentatsioon peab vastama RIK dokumentatsiooniplaani nõuetele.

https://dok.rik.ee/pages/viewpage.action?pageId=190751639 KEHTIV Arhitekt /juhtiv arendaja

Lisad:  Lisa 1.1.1 – Staatuslehe näidis

NA-129 Dokum entatsio on

Iga uue versiooniga käib kaasas muudatuste kirjeldus.

Changelog või .release notes KEHTIV Arhitekt /juhtiv arendaja

NA-130 Version eerimin e

Kõik rakenduse testimiseks, koolituseks või implementeerimiseks üle antavad tarkvarapaketid peavad asuma RIK koodihoidlas.

Arendajale antakse selleks õigused RIK-i koodihoidlas. KEHTIV Arhitekt /juhtiv arendaja

NA-133 Version eerimin e

Peab kasutama RIK piletihalduskeskkonda. Kasutusel on JIRA. Kaasa arvatud välised osapooled. KEHTIV Arhitekt /juhtiv arendaja

NA-137 Version eerimin e

Kolmanda osapoole teegid peavad asuma RIK-i hoidlas.

hoidla.rik.ee KEHTIV Arhitekt /juhtiv arendaja

NA-138 Version eerimin e

Andmebaasi skriptide sisu peab olema kontrollitav. Administraator peab saama veenduda skriptide sisus. KEHTIV Arhitekt /juhtiv arendaja

118 teemat

Nõuded süsteemianalüüsile versioon 1.0

Sisukord:

Sissejuhatus I. Vormistus

SA-v 1. Loomise ja muutmise info: SA-v 2. Oleku info: SA-v 3. Identifitseerimise info:

II. Sisu SA-s 1. Loetavus ja mõistetavus. SA-s 2. Infosüsteemi terviku kirjeldus SA-s 3. Vormide kirjeldused SA-s 4. Kasutuslugude/vormide kasutamise protsesside/tegevuste kirjeldused SA-s 5. Infosüsteemi teenuste kirjeldused SA-s 6. Pildid, skeemid, diagrammid:

III. Töövahendid

Sissejuhatus

Enne projekti tegelikku algust lepitakse kokku kõik erisused - millised punktid vastavas projektis ei rakendu (pole võimalik/vajalik) ja kas rakenduvad mingid täiendavad punktid või all-loetletud punktidele täpsustused.

Antud nõueteloetelu kehtib nii RIKi majasisestele projektidele kui välistele projektidele (majavälised arendajad).

I. Vormistus

Alljärgnevalt on kirjeldatud vormistuse nõuded kõiksugustele nõuetele, nõuete komplektidele, reeglitele, vormidele. Muudatuste haldamine ja seotud viitamine peavad olema kooskõlastatud ja kokkulepitud enne süsteemianalüüsi algust.

SA-v 1. Loomise ja muutmise info:

Loomise eesmärk/taustSA-v 1.1

Tekkimise aegSA-v 1.2

AutorSA-v 1.3

Viimase muutmise põhjusSA-v 1.4

Viimase muutmise aegSA-v 1.5

MuutjaSA-v 1.6

Kui on tegemist nõuete komplektiga (või plokiga), siis peavad olema selgelt eristatavad pealkiri ja sisuSA-v 1.7

SA-v 2. Oleku info:

Kinnitaja ja kooskõlastajadSA-v 2.1

Nõude/nõuete komplekti seis - kasutusel olevad olekunäitajad peavad olema kokkulepitud vastavalt antud projekti vajadustele. SA-v 2.2 Näiteks võivad nõude/nõuete komplekti olekud olla:

tegemisel kooskõlastamisel kinnitatud implementeeritud kehtetu

SA-v 3. Identifitseerimise info:

Igal nõudel/reeglil ja nõete komplektil peab olema unikaalne identifikaatorSA-v 3.1

II. Sisu

Alljärgnevalt on kirjeldatud nõuded süsteemianalüüsi sisule.

SA-s 1. Loetavus ja mõistetavus.

Süsteemianalüüs peab olema:

Loetav ja selgeSA-s 1.1

Kindlas kõneviisisSA-s 1.2

Sisaldama üheselt defineeritud äri- ja süsteemi mõisteidSA-s 1.3

Sisaldama ainult täpseid andmeolemite/andmeväljade nimetusiSA-s 1.4

SA-s 2. Infosüsteemi terviku kirjeldus

Infosüsteemi terviku kirjelduses peavad olema:

Kõikide kasutatavate mõistete definitsioonidSA-s 2.1

Kõikide äriobjektide ja neile vastavate andmeolemite ning seoste kirjeldused ning üldised tööpõhimõttedSA-s 2.2

Andmeolemite kõik andmeväljad ja nende sisu vastastikune mõju üksteiseleSA-s 2.3

Infosüsteemi erinevate kihtide kirjeldused: andmevahetus/kasutajaliides, domeen ja andmebaas.SA-s 2.4

Andmete käitlemine antud süsteemis:SA-s 2.5

versioneerimineSA-s 2.5.1

sünkroniseerimineSA-s 2.5.2

arhiveerimineSA-s 2.5.3

kustutamineSA-s 2.5.4

Kasutusel väljade ja kasutatavate andmeolemite täpsed nimetusedSA-s 2.6

Õiguste kirjeldused: kasutajad, rollid, grupidSA-s 2.7

Süsteemi üldised valideerimisedSA-s 2.8

SA-s 3. Vormide kirjeldused

Kõik kasutajaliidesevormid ja vormide elemendid peavad olema nõuetega/reeglitega kaetudSA-s 3.1

Peab olema loodud prototüüp, mis kajastab kõike realiseeritavat.SA-s 3.2

Märkus: Sõltuvalt projekti kokkulepetest võib seda osa teha ka UX inimene UX ja ärianalüüsi tööde raames.

Iga vormi/vormi osa eesmärk peab olema selge - lühike ja täpne kirjeldus, milleks seda vormi on vaja.SA-s 3.3

Iga vormi jaoks peavad olema välja toodud kõik vormiga seotud sisulised veateated.SA-s 3.4

Märkus: Sõltuvalt projekti kokkulepetest võib seda osa teha ka UX inimene UX ja ärianalüüsi tööde raames.

Iga vormi toimimise juures peavad olema välja toodud erandid, kui need on olemas, võrreldes selle konkreetse süsteemi üldiselt SA-s 3.5 kehtivate reeglitega

Igal vormil peavad olema välja toodud kõik sellega seotud valideerimised ning nendega seotud süsteemi poolt tagastatavad SA-s 3.6 veateated ja hoiatused

Vormi andmeväljade sisestamise ja muutmise kirjeldused; kes (süsteem, kasutaja, sidussüsteem, genereeritakse jooksvalt, ...), SA-s 3.7 mis tingimustel, kuidas?

Millised andmeväljad onSA-s 3.8

kohustuslikudSA-s 3.8.1

valikulisedSA-s 3.8.2

ainult kuvatavadSA-s 3.8.3

tingimuslikult kuvatavad vs alati kuvatavadSA-s 3.8.4

vaikeväärtustega täidetavad + millised need vaikeväärtused onSA-s 3.8.5

Lubatud väärtused väljadele (tekst, numbrid, e-mail, komakohad, jne)SA-s 3.9

Kuidas antud vormile saab - kui see ei tule välja punktis SA-s 4 nõutud kirjeldustestSA-s 3.10

SA-s 4. Kasutuslugude/vormide kasutamise protsesside/tegevuste kirjeldused

Kuidas on erinevad vormid omavahel seotudSA-s 4.1

Kasutajate tegevuste ja tegevuste kogumite kirjeldusedSA-s 4.2

Süsteemi terviklikud kasutamise protsessid/kasutusloodSA-s 4.3

Kriitiliste funktsionaalsuste jaoks testimise stsenaariumidSA-s 4.4

SA-s 5. Infosüsteemi teenuste kirjeldused

Kui tegemist on teenusepõhise (XML-teenuseid pakkuva) infosüsteemiga või liidetustumisega mingi teise infosüsteemiga (teenuste tarbimisega), siis peavad olema kirjeldatud:

Tarbitavad teiste süsteemide teenused (kui on)SA-s 5.1

Kõik edastatavad sisendidSA-s 5.1.1

Kõik tarbitavad väljundid - millised ja kus, kuhu edasi saadetakse/märgitakse/salvestatakseSA-s 5.1.2

Kõik infosüsteemi enda poolt pakutavad teenused (kui on)SA-s 5.2

Iga teenuse kohta detailne sisendite kirjeldusSA-s 5.2.1

Iga teenuse kohta detailne väljundite kirjeldusSA-s 5.2.2

Iga teenusega kaasnevad valideerimised ja sisulised veateatedSA-s 5.2.3

Iga teenuse enda loogika ja funktisonaalsuse kirjeldusSA-s 5.2.4

SA-s 6. Pildid, skeemid, diagrammid:

Peavad:

toetama kirjeldatavat - olema tervikliku kirjelduse osa, mitte tühjalt genereeritud pildialbumSA-s 6.1

omama selget eesmärki - milleks see pilt/skeem/diagramm on, mida ta annab?SA-s 6.2

olema intuitiivselt loetavadSA-s 6.3

Lisaks:

Teenuste puhul on hea lisada ka XML .SA-s 6.4 schema

III. Töövahendid

SA-t 1. Süsteemianalüüsi kajastavad töövahendid peavad olema eelnevalt kokkulepitud

SA-t 2. Spetsifikatsioon peab olema üle antud taaskasutataval kujul.

Näiteks:

skeemi/diagrammi/pildi algfail (mitte suvaline link sellele) *.eap fail Confluence eksportfail ...

Nõuded testimisele v1.2 versioon 1.2

Sisukord

Sissejuhatus 1. Üldine AO-N-TE-Y 2. Dokumentatsioon  AO-N-TE-D 3. Testplaan ja -lood  AO-N-TE-T 4. Logimine, raporteerimine  AO-N-TE-R 5. Nõuded testidele  AO-N-TE-N 6. Lähtekood ja spetsiaalsed tööriistad  AO-N-TE-I 7. Alusandmed  AO-N-TE-A 8. Koormus- ja stressitestid  AO-N-TE-S

Sissejuhatus

Enne projekti tegelikku algust lepitakse kokku kõik erisused - millised punktid vastavas projektis ei rakendu (pole võimalik/vajalik) ja kas rakenduvad mingid täiendavad punktid või all-loetletud punktidele täpsustused.

1. Üldine AO-N-TE-Y

Nõue Sisu

AO-N- TE-Y-1

Kõikide üle antavate tarkvara versioonidega peavad kaasas olema vastavad testid, nendega seotud dokumentatsioon ning kirjelduse või raporti leitud ja parandatud vigadest.

AO-N- TE-Y-2

Tarkvara vastuvõtmiseks vajalikud hankevõitja poolsed testimised ja skoop (osa testplaanist) lepitakse kokku projekti alguses ning seda muudetakse poolte kokkuleppel.

AO-N- TE-Y-3

Vastavalt kokkuleppele tuleb koostada ning üle anda punktis  nimetatud testplaan ja testlood ning eraldi testprojekti ja -programmi puhul ka vajaminev dokumentatsioon ja AO-N-TE-Y-2 kirjeldus.

AO-N- TE-Y-4

Testitava tarkvara lõplik versioon peab läbima vastavad nõuded koormusele/jõudlusele (ISKE,SLA jm.). Selle tõestamiseks tuleb tarnida ka vastavad testid.

AO-N- TE-Y-5

Üle antud testides või vastuvõtutestimisel esinenud probleemid tuleb parandada sarnaselt põhiarendusega.

AO-N- TE-Y-6

Testid peavad olema loogiliselt grupeeritud ning numereeritud, nii et skriptide või tööriistade abil saab kindlat osa käivitada. Näiteks teenuse- või tüübi kaupa (süsteemitestid, koormustestid vm.).

AO-N- TE-Y-7

Üle antud testide käivitamiseks ei pea RIK soetama lisatarkvara. Näiteks automaattestid, koormustestid jm. võiks olla kirjutatud C#+NUnit'is, Selenium'is, JMeter'is, Robot Framework'is või Gattling'us. Kokkuleppel Java+JUnit, Cypress või muu.

2. Dokumentatsioon  AO-N-TE-D

Nõue Sisu

AO-N-TE-D- 1

Dokumentatsiooni eesmärgiks on edasi anda kogu vajalik informatsioon testide kohta (testplaanid, testlood, testide käivitamiseks, jooksutamiseks ja valideerimiseks vajalik informatsioon jne).

AO-N-TE-D- 2

Dokumentatsioon peab olema versioneeritud ning iga punkti (Näiteks Testlugu) juures peab olema tekkimise aeg, viimase muudatuse aeg, autor, muutja.

3. Testplaan ja -lood  AO-N-TE-T

Nõue Sisu

AO-N- TE-T-1

Testplaanile ja –lugudele rakendub peatükk .AO-N-TE-D-2

AO-N- TE-T-2

Testplaan kirjeldab ning selgitab kogu tarkvaraga seotud testimist, kui ei ole kokku lepitud teisiti.

AO-N- TE-T-3

Testlood tulenevad kasutuslugudest ja/või süsteemianalüüsi nõuetest, nende kattumisel piisab testimise kirjeldusest, et vältida dokumentatsiooni dubleerimist.

AO-N- TE-T-4

Testloos peab minimaalselt olema: testi kirjeldus, viide nõudele või kasutusloole, etapid, oodatud tulemus, tegelik tulemus.

AO-N- TE-T-5

Testprojekti ja –programmi puhul võib kood koos kommentaaridega täita testloo rolli (Näiteks Testi nimetus viitab kindlale testloole või süsteeminõudele, C# kirjutatud süsteemitesti nimetamisloogika ja kommentaarid teevad kergelt selgeks tegevuste ahela).

4. Logimine, raporteerimine  AO-N-TE-R

Nõue Sisu

AO-N- TE-R-1

Raportitele rakendub peatükk  AO-N-TE-D-2 . Eraldi raporteid pole tingimata vaja kui kasutatakse ühist JIRA + Confluence keskkonda.

AO-N- TE-R-2

Testraportis kajastatud vigade juures peab olema märgitud tarne versioon, milles viga leiti ning milles see on kõrvaldatud.

AO-N- TE-R-3

Automaatsete testide puhul peab automaatselt genereeruma testraport või statistika tegemiseks vajalik logi (Näiteks NUnit genereerib ise raporti, JMeteris Summary Report+ Aggregate Report või eraldi .csv fail jne.).

AO-N- TE-R-4

Koormus- ja stressitestide puhul peab raport kajastama, millise koormuse juures hakkasid testid negatiivseid tulemusi saama ning millised vead esinesid.

AO-N- TE-R-5

Koormus- ja stressitestide juures on vaja minimaalselt välja tuua: saadetud päringute arv, min. päringu käitlemise aeg(ms), max. päringu käitlemise aeg(ms), päringute käitlemise standardhälve (ms), keskmine päringu käitlemise aeg(ms), vigade %, läbilaskevõime(tegevust/sek.), 90/95/99 protsentiilid.

5. Nõuded testidele  AO-N-TE-N

Nõue Sisu

AO-N-TE- N-1

Testprojekti ja –programmi testide juures rakendub peatükk  AO-N-TE-D-2 , lisaks peab testi juurde märkima testi tegija ning tarkvara versiooni, millele test koostati. 

AO-N-TE- N-2

Süsteemitestidega peavad olema kaetud kõik süsteemi osad, kui ei ole kokku lepitud teisiti (Näiteks kõik arendatud teenused, kasutajaliidesega rakenduse testlood jne.).

AO-N-TE- N-3

Iga test peab olema süsteemi- või ärianalüütiliselt terviklik põhjendatav kooslus (Näiteks ühes testis ei testita kahte erinevat teenust või süsteemi viga).

AO-N-TE- N-4

Iga teenuse kohta peab olema Smoke test, mis kontrollib lihtsaima sisendiga teenuse töökorda.

AO-N-TE- N-5

Kuna RIKis arendatakse pideva integratsiooni mudelit järgides, siis peab olema võimalik teste valikuliselt grupeerida ning neid automaatselt käivitada (Näiteks Grupp „Nightly" öiste integratsioonitestide jaoks).

AO-N-TE- N-6

Testsessioonid ning omavahel mitte seotud testid ei tohi üksteist mõjutada.

6. Lähtekood ja spetsiaalsed tööriistad  AO-N-TE-I

Nõue Sisu

AO-N-TE-I- 1

Spetsiaalselt arendatud testprojektile ja -programmile rakenduvad „Nõuded arendustele –Nõuded rakenduse koodile" .

AO-N-TE-I- 2

Spetsiaalselt arendatud testprojektid peavad kasutama üldtuntud raamistikke Näiteks NUnit, JUnit.

AO-N-TE-I- 3

Kui testprojekt kasutab Objektide kihte, omab teenuste kihti või koodi osa, mida saab WSDL, andmebaasi või muu pealt genereerida, siis selleks peab kasutama tööriistu (Näiteks DTOd ei kirjutata käsitsi).

AO-N-TE-I- 4

Punktis mainitud tööriistad ja nende parandused tuleb tarnida koos testidega.AO-N-TE-I-3

7. Alusandmed  AO-N-TE-A

Nõue Sisu

AO-N-TE- A-1

Alusandmete genereerimiseks vajalik peab olema vastavate testidega kaasas.

AO-N-TE- A-2

Kui testimiseks on vajalikud andmed teistest süsteemidest, siis nende saamine lepitakse eelnevalt kokku.

AO-N-TE- A-3

Alusandmed peavad töötama erinevates keskkondades, kaasa arvatud andmed, mida päritakse teistest süsteemidest.

AO-N-TE- A-4

Peab vältima teiste süsteemide andmete rikkumist, selle vältimiseks vt. punkt .AO-N-TE-A-2

AO-N-TE- A-5

Eelistama peaks alusandmete genereerimist või eraldi üldkasutatavat kihti, millest andmed võetakse, mitte koodi sisse kirjutatud andmeid (Näiteks Isikukoodid võetakse üldisest jadast või eraldi testandmete alamprojektist).

AO-N-TE- A-6

Võimalusel kasutada sünteetilisi, mitte reaalseid andmeid (Näiteks reaalsuses mitte eksisteerivad Isikud), eriti kui arendatavas tarkvaras on automaatseid teavitusi või muud samalaadset (Näiteks automaatne e-mailide saatmine).

8. Koormus- ja stressitestid  AO-N-TE-S

Nõue Sisu

AO-N-TE-S-1 Testide üleandmisel peab kaasa andma nendega kaasneva dokumentatsiooni, kasutatud konfiguratsiooni ning vajadusel riistvara ja arhitektuuri kirjelduse.

AO-N-TE-S-2 Kasutatud konfiguratsioon ning riistvara ja arhitektuur võiks tugevalt sarnaneda vastuvõtja test- või toodangukeskkonna riistvaraga.

AO-N-TE-S-3 Testid peavad olema üldisest konfiguratsioonist skaleeritavad: kasutajate arv, kasutajate etapilisus (ramp-up), testide ajastamine jm. on üldised muutujad või üldises konfiguratsioonis.

AO-N-TE-S-4 Igal testil peab olema konkreetne kontekst (Näiteks SLA nõue, teenuse või baasiprotseduuri jõudluse hindamine vm.).

Arenduse tavad ja töökorraldus

Tellija jätab endale õiguse muuta raamlepingu alusel sõlmitavate hankelepingute tehnilises kirjelduses

kirjeldatud nõudeid. Pakkuja peab lähtuma hankelepingute täitmisel järgnevatest nõuetest, v.a juhul kui tellija on

hankelepingu tehnilises kirjelduses märkinud teisti.

Arendustööde teostamisel kohustub pakkuja lähtuma mittefunktsionaalsetest nõuetest.

1. Nõuded arenduste üleandmisele

Loodavad hanke tulemid antakse üle RIK-i koodirepositooriumi kaudu. Partneri meeskonnaliikmetele luuakse

RIK-i poolt ligipääs koodirepositooriumile lähtekoodide, andmebaasimuudatuste ning muude tulemite või nende

muudatuste üleandmiseks.

2. Commit

Arendamisel lisada commitide (lähtekoodi repositooriumisse lisamine) juurde kindlasti töökäsu nr, mille alusel

muudatus sisse viiakse ning lühisõnaline lühikirjeldus, mida muudatused sisaldavad. Commit sõnumi alguses peab

olema alati projekti nimi, mille raames commit tehakse ning kindlasti lisada info selle kohta, et kes antud commiti

teeb (isiku nimi).

Vigade parandamisel tuleb alati committimisel lisada ticketi number märkusena.

Muudatusi tuleb commitida vähemalt kord päevas.

Enne commiti peab kood/teostatud töö/tulem olema:

1) Iseendaga kooskõlas (pole vastuolusid, katkiseid mooduleid, iseendaga vastuolus funktsionaalsust);

2) Üldharu/muu haru tulemiga kooskõlas (üldharus olemasolev pole peale commiti katki);

3) Edaspidi mugavalt kasutatav ja mõistetav, ehk sellel on olemas oma enda sisseehitatud testid, mis peale

järgnevaid võimalikke arendusi/commite/tegevusi näitaks, kas see konkreetne funktsionaalsuse osa on

endiselt korras, või läks katki ja tuleb korrastada.

Commititav kood/teostatud töö/tulem peab olema piisavalt testitud ja pakkuja poolt testidega kaetud, kasutades

selleks:

a) Unittest’e,

b) Systemtest’e

c) Manuaalseid teste

3. Tagimine

Versiooni üleandmiseks tuleb sellest koostada tag. Tagi number peab ühtima versiooni numbriga, mida üle

antakse, kuid tagi nimi peab alati algama projekti lühendiga. Tagi alla tuleb siduda kõikide arhitektuuriliste

komponentide (rakendus, andmebaasiscriptid, x-tee adapter jne) ning muudetud või loodud dokumentatsiooni

commitid.

Versiooni numbrid peavad olema vähemalt kolmekohalised (X.Y.Z, milles X- põhiversioon, Y - üleantav versioon,

Z paranduse number). Vajadusel võib kokku leppida teistsuguses numeratsioonis.

http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-branchtag.html#tsvn-dug-branch-1

Iga tagiga (uue versiooniga) peab kaasnema versiooni kirjeldus (mis taskid, mis ticketid, mis baasiscriptid, mis

juhendeid täiendati jne), mis tuleb paigutada dokumentatsiooni alla.

4. Dokumentatsioon

Dokumentatsiooni tuleb hoida trunk/doc/ kaustas. Alampuud lepitakse eraldi kokku.

5. Baasiscriptid

Andmebaas ning selle muudatused tuleb alati üle anda loovate, muutvate, täiendavate jne skriptidena ning neid

tuleb alati hoida trunk/baas/ kaustas.

Andmebaasiscriptide failinimed peavad olema kujul:

YYYYMMDDHHMM_prefiks+Järjekorranr.sql ehk 201105131430_KR0003.sql kus prefiks on süsteemi

lühend.

6. Pakkuja poolne testimine

Partner peab lisaks kasutuslugude funktsionaalsele testimisele teostatava arenduse/töö/tulemi commitimisel ja

üleandmisel ise tõestatavalt veendunud olema, et nende arendus/töö/tulem teeb seda, mis on nõutud ning

samaaegselt ei riku/lõhu juba olemasolevat muud arendust/tööd/tulemit.

Iga kirjutatud koodiüksuse kohta peaks olemas olema ka vastav test, mis kindlustab, et loodu toimib ja seda ka

eriolukordades. Samuti on testid abiks juba olemasolevate komponentide muutmisel, indikeerides koheselt

võimaliku probleemolukorra.

Arendatav funktsionaalsus peab olema kaetud:

1. Unittestidega

2. Süsteemitestidega

3. Manuaalsete testidega

Igal commitimisel ning üleandmisega peab edukalt:

1. käivitama kõik Unittestid ning selle dokumenteerima.

2. käivitama kõik süsteemitestid ning selle dokumenteerima

3. käivitama kõik manuaalsed testid ning selle dokumenteerima

4. dokumenteerima, mis test data't kasutati, mis keskkondi kasutati, jne.

6.1 Unit-testid e. Moodultestid

Moodultestid testivad ÜHTE klassi isoleeritult teistest klassidest ja ressurssidest (andmebaas).

Ideaalis peaks igal iseseival klassil olema oma moodultest, mis kataks selle funktsionaalust täielikult.

Kuna klassid kasutavad teineteist, moodustuvad niiöelda kobarad, siis moodultesti ideoloogiaga see hästi kokku

ei sobi. Selleks, et saaks testida tõesti vaid konkreetse ühe klassi funktsionaalsust, on kasutusel mock-

objektid(väline komponent Rhino Mocks).

6.2 Süsteemitestid

Süsteemitestid testivad süsteemi kasutaja vaatenurgast, eesmärgiks on kontrollida süsteemi vastavust kasutaja

nõudmistele.

Süsteemitestid jagunevad omakorda kaheks:

1. Funktsionaalsuse testid - üldjuhul koostatakse konkreetse teenuse klassi süsteemitestid sellises mahus, et

kaetud oleksid selle kõik erinevad meetodid ning lisaks äriloogiliselt olulisemad stsenaariumid.

2. Mittefunktsionaalsete aspektide testid - näiteks jõudluse testimiseks.

6.3 Üldised nõuded testide kirjutamisel

Nagu eelnevalt sai kirjeldatud, on testid liigendatud oma olemuse järgi. Testi sisu ja iseloom varieerub olenevalt

selle kategooriale (nt. [Test, Category("Bug")] – testis kirjeldatakse kindel veaolukord ning kontrollitakse selle

põhjal vea olemasolu. testi andmed on antud veaolukorra järgi koostatud ja spetsiifilised). Küll aga on kujunenud

kindlad head tavad, mida tuleb kõigi testide kirjutamisel järgida – koodieetikat, testide liigendamist, testide

automatiseeritust (st. teste peab saama käivitada skriptidega projektiväliselt nt. kategooria alusel iga-öiselt) ning

testide autonoomsust (testid peavad võimalikult hästi taluma ET muudatusi).

6.4 Koodieetika ja struktuur testide kirjutamisel

Testkood peaks olema liigendatud ja selgelt loetav:

1. Defineerida testis projekti erinevate osade kasutus (nt. using System;);

2. Iga testklass tuleb deklareerida [TestFixture]-raamistikus ning olenevalt testi iseloomust nimetada kujul

Bug1234Test (kindlat viga #1234 kirjeldav Bug-test), Ticket1234Test (uuendust #1234 kontrolliv test)

või TestiKirjutajaEesnimi_TeenuseNimiTest (teenuse spetsiifiline süvatest);

3. Testis olevad privaatsed klassimuutujad on tava kohaselt kujul _muutujaNimi, näiteks

private Menetlus _menetlus;

4. Kaitstud ja avalikud muutujad on kujul muutujaNimi või MuutujaNimi;

5. Vajalik uute klassiobjektide initsialiseerimine (nt. liidesed) toimub meetodis SetUp(). Näiteks:

[SetUp]

public void SetUp()

{

_liides = new Liides();

}

6. Iga uus testcase tuleb kirjutada raamistiku sisse kujul

[Test, Category("Kategooria")]

ning testi enda nimetus tuleneb testi tüübist:

a) Bug-testide ja uuendusi kontrollivate testide korral nimetus, mis kirjeldab võimalikult hästi ja

konkreetselt kontrollitavat objekti/olukorda .

b) Teenusepõhiste süvatestide puhul esiteks test, mis kontrollib, et teenust saaks nii minimaalsete

kui ka maksimaalsete andmetega kinnitada, nimetusega A_SetUp()

7. Testandmed võiksid olla võimalikult reaalse elu lähedased ja loogilised, st. ei tohiks tekitada uut objekti

klassist Helikopter kujul _a, vaid kujul _helikopter.

8. Iga äridokumendis olev nõue või tingimus tuleb testida eraldi testcase’i all, olenemata sellest kas

kontrolliks on üks või rohkem ridu koodi. Kui teha äriloogiline kontroll vaid ühe testi all, siis ei kajasta

see teenuse tervist – st. kui esimene kontroll annab veateate, siis ülejäänuteni test ei jõua. Selle

vältimiseks on testid ärinõuete kaupa eraldi kirjutatud.

6.5 Autonoomsus

Testid peavad taluma pisemaid koodi muudatusi (neid, millega ei kaasne DTO või andmemudeli muutused).

6.6 Automatiseeritus

Kõiki teste peab saama käivitada näiteks projektiväliselt skripti abil. Selleks peavad testid olema õigesti

kategoriseeritud.

Dokumentatsiooniplaan v2 versioon 2.0

Täitja poolt Tellijale üle antavad dokumendid

Arenduste kirjeldus Arhitektuuri kirjeldus Seadmete ja tarkvara kasutusjuhendid Testplaan ja testimise tulemusena valminud dokumendid Varundus/taasteplaan Versiooni kirjeldus Nõuded arendustele vastavustabel Front-end nõuete vastavustabel Kasutajaliideste ja WCAG nõuete vastavustabel Andmekogude semantiline kirjeldus ja koosseis

Dokumendid peavad vastama vähemalt alljärgnevatele tingimustele

Tehnilise dokumentatsiooni võiks võimaluse korral hoida git’is koodi juures .md failides.  Ärilised dokumendid peavad olema RIK Confluence keskkonnas

  Dokumendi nimi hankelepingus Dokumendi sisu vastavalt arenduslepingule Sihtgrupp

1 Arenduste kirjeldus Dokumendi/dokumentide eesmärgiks on anda selge ja konkreetne ülevaade süsteemi sisust ja realiseeritud arendustest.

Eraldiseisvaid dokumente üle ei anta vaid RIK Confluence keskkonda kirjutatakse analüüsi jooksvalt projekti käigus. 

Kirjeldused peavad olema kinnitatud Tellija poolt enne arendustöö algust.

Üle antavad dokumendid peavad sisaldama:

Infosüsteemi terviku kirjeldus – olemasoleva süsteemi täiendamisel lisatud/muudetud osade kirjeldus. Tegemist on süsteemi ärisisul põhinevate baaskomponentidega, millele toetuvad kasutaja tegevused, ekraanivormid, kasutuslood/protsessid, teenused, jms; Vormide (ekraanivormide) kirjeldused; Kasutuslugude / vormide kasutamise protsesside / tegevuste kirjeldused; Infosüsteemi teenuste kirjeldused.

Tellija äriprotsesse valdavad kontaktisikud:

ärianalüü tikud süsteemi analüütik ud

Täitjast sõltumatud

tarkvara hooldajad arendaja d ja edasiare ndajad testijad arhitektid projektiju hid

2 Arhitektuuri kirjeldus Dokumendi eesmärgiks on kirjeldada loodava süsteemi tehnilist ülesehitust. Kirjeldatakse rakenduse loogilist struktuuri, näidates ära selle kihtideks jagunemise. Kirjeldatakse ka füüsilist arhitektuuri, antakse ülevaade kasutatavatest tehnoloogiatest ning vahenditest.

Dokument peab rahuldama vähemalt alljärgnevaid sisunõudeid:

topoloogia, süsteemi füüsiline arhitektuur (süsteemi komponendid andmebaasiserver, rakendusserver, meiliserver jms): süsteemi soovituslikud näitajad komponentide kaupa, näiteks andmesidekiirused, andmemahud, protsessori kiirus, mälumaht, komponentide arv süsteemi osade kaupa, kettasüsteemi jõudlus jms; liidesed teiste süsteemidega (x-tee, meilisüsteemid) ja sõltuvused teistest süsteemidest; süsteemi tehnilised (sh automaatsed) protsessid ehk töövoog – komponentide omavahelised suhtlusstsenaariumid ja koostoimimine (näiteks, mis komponent ja millal pöördub RR teenuse poole); kolmandate osapoolte poolt toodetud kasutatavad tarkvarad/riistvarad, mis on vajalikud süsteemi toimimiseks; süsteemi krüpto-, allkirjastamise, digitemebeldamise lahendused ja algoritmid.

Esmane kirjeldus esitatakse enne arendustööde algust.

Täiendatud kirjeldus antakse üle koos vaheetapi üleandmise aktiga.

Lõplik (täielik) kirjeldus esitatakse lõppaktiga

arhitekt administraator turvaspetsialist

3 Seadmete ja tarkvara kasutusjuhendid

Süsteem tuleb ehitada selliselt, et see ei vajaks täiendavaid selgitusi (oleks intuitiivne).

Siiski võib teatud hetkedel kasutaja vajada täiendavat infot, mis aitaks kasutajatel mõista, kuidas oma ülesandeid täita, sellisel juhul peab info sisu olema hõlpsasti leitav ja keskenduma kasutaja ülesandele. Seega tuleks alati eelistada kasutajale kontekstipõhist abiinfo andmist, mis on realiseeritud UI vaates, milles kasutaja parasjagu oma ülesandeid täidab.

Abiinfo peab olema lühike ja sisaldama konkreetsete sammude kirjeldusi, mis tuleb läbi viia.

Kasutusjuhendi materjali eraldiseisvalt üle ei anta, vaid need kuuluvad üle antava rakenduse juurde.

tarkvara kasutajad haldurid

4 Administreerimisjuhend,  paigal dusjuhend

Juhend on aluseks süsteemi administreerimisele, paigaldamisele ja seadistamisele.

Juhend peab rahuldama vähemalt alljärgnevaid sisunõudeid:

süsteemi parameetrite (seadistuste) kirjeldus ning nende muutmiste mõjud ja protseduurid (näiteks .net rakenduste puhul konfiguratsiooniparameetrite kirjeldused/selgitused ja näidisväärtused); logimise realisatsiooni kirjeldused (kuhu ja mida, kas kasutatakse roteerimist või katalogiseerimist jms); rutiinsete hooldusprotseduuride kirjeldus; paigalduspaketi koostamise protseduurid; paigaldusprotseduurid; süsteemi halvamist võimaldavad riskid ja nende esinemise võimalikkus.

Paigaldusjuhendis kirjeldatakse iga realiseeritud osa rakendamine (deployment) koos spetsiifiliste seadistustega. Paigaldusprotseduurid peavad olema kirjutatud selliselt, et RIK-i administraator suudab rakenduse paigaldada ja seadistada ilma kõrvalise abita. 

Etapi juhendid antakse üle koos vaheetapi üleandmise aktiga.

Lõplikud (täielikud) juhendid esitatakse lõppaktiga. 

haldurid projektijuht adminitraator arhitekt

1.

2. 3.

5 Testplaan ja testimise tulemusena valminud dokumendid

Annab detailse ülevaate teostatud arenduste testimisest ning testimise tulemustest.

Kesksel kohal on testplaan, mis kirjeldab testimise strateegia, skoobi, vahendid, tegevused, tulemid jne. Vastavalt kokkuleppele koostatakse testlood, mis võivad olla laiendatud kasutuslood. Vastavalt kokkuleppele teostatud funktsionaalsuse-, jõudluse-, koormuse-, integratsiooni-, kasutatavuse-, turvalisuse- jm. testimise dokumendid (plaan, lood, juhendid, puudused, puuduste kõrvaldamise info, tulemid). Testimisel ilmnenud vead ning paranduste info (versiooniinfo, vajadusel sisu). Testimise otstarbel loodud kood, skriptid, kasutusjuhendid.

Testimise dokumentatsioon ei pea olema üks dokument, dokumendid võib grupeerida loogilisteks osadeks:

Testplaan Nõuetele vastavus Testlood

Etapi juhendid antakse üle koos vaheetapi üleandmise aktiga.

Lõplikud (täielikud) juhendid esitatakse lõppaktiga. 

projektijuht vastuvõtu testijad

6 Varundus/taasteplaan Tagada süsteemi hävingujärgne kiire ja tõrgeteta taastamine.

Taasteplaan on aluseks süsteemi taastamisele peale suuremat hävingut.

Taasteplaan peab rahuldama vähemalt alljärgnevaid sisulisi nõudeid:

Süsteemi backup’id, varundamisele kuuluvate komponentide ja asukohtade loetelu (nt rakenduse konfiguratsioonifailid, rakenduse failid failiserveril paiknevad failid ja andmebaas jne), nende kirjeldused ja kasutuselevõtu protseduurid (Näiteks: tuua kataloogi (vajadusel faili) tasemel välja list failidest, mida peab varundama; varunduse järjekord (kui see on oluline); Taastamise sammud kasutades installatsiooni juhendit ja varundatud andmeid; Süsteemi komponentide asendusvõimalused, nende alternatiivkomponentide spetsifikatsioonid. Miinimumis peab vastama küsimusele: milline riistvara/tarkvara on sobiv arendaja arvates (tehtud nt jõudlustestid) seda süsteemi käitama.

Esmane dokument esitatakse enne arendustööde algust.

Täiendatud dokument antakse üle koos vaheetapi üleandmise aktiga.

Lõplik (täielik) dokument esitatakse lõppaktiga.

administraator

7  Versiooni kirjeldus  Vajalik ülevaate saamiseks infosüsteemi versioonide sisust.

Detailne info iga versiooniuuenduse kohta: 

avaldamise kuupäev versiooni number versiooni tüüp (peamine, vaheversioon, parandus, erakorraline) versiooni sisu - milliseid teostatud arendusi sisaldab (töökasu numbrid, näiteks Jira taskide numbrid ja/või lingid taskile) leitud, kuid parandamata vead

Versioni kirjeldus võib põhineda tarnitud Jira piletitel.

Esitatakse koos iga üleantava versiooniga ja iga versiooni kohta.

projektijuht

8 Nõuded arendustele vastavustabel

Kontrolltabel nii Täitjale kui ka Tellijale veendumaks, et arvestatud on hankes nõutud arenduse nõuetega.

Kõik raamlepingus, lähteülesandes või tehnilises kirjelduses kirjeldatud mittefunktsionaalsed nõuded ning täitmismärge. 

Täitmismärke tegemise aluseks peab olema testimine. Vajadusel lisatakse selgitused.

Esmane dokument esitatakse enne arendustööde algust.

Täiendatud dokument antakse üle koos vaheetapi üleandmise aktiga.

Lõplik (täielik) dokument esitatakse lõppaktiga.

arhitekt administraator turvajuht

9 Front-end nõuete vastavustabel

Kontrolltabel nii Täitjale kui ka Tellijale veendumaks, et arvestatud on hankes nõutud front-end nõuetega.

Kõik raamlepingus, lähteülesandes või tehnilises kirjelduses kirjeldatud front-end nõuded ning täitmismärge. 

Täitmismärke tegemise aluseks peab olema testimine. Vajadusel lisatakse selgitused.

Esmane dokument esitatakse enne arendustööde algust.

Täiendatud dokument antakse üle koos vaheetapi üleandmise aktiga.

Lõplik (täielik) dokument esitatakse lõppaktiga.

arhitekt

10 Kasutajaliideste ja WCAG nõuete vastavustabel

Kontrolltabel nii Täitjale kui ka Tellijale veendumaks, et arvestatud on hankes nõutud kasutajaliideste ja WCAG nõuetega.

Kõik raamlepingus, lähteülesandes või tehnilises kirjelduses kirjeldatud kasutajaliideste ja WCAG nõuded ning täitmismärge. 

Täitmismärke tegemise aluseks peab olema testimine. Vajadusel lisatakse selgitused.

Esmane dokument esitatakse enne arendustööde algust.

Täiendatud dokument antakse üle koos vaheetapi üleandmise aktiga.

Lõplik (täielik) dokument esitatakse lõppaktiga.

haldurid

11 Andmekogude semantiline kirjeldus ja koosseis

Vajalik ülevaate saamiseks, mis andmed andmekogus on ja mida need tähendavad.

Andmekogus töödeldavate andmete koosseisu kirjeldus sisaldab:

vanemandmeobjekti nimetus (tabeli nimetus); andmeobjekti nimetus (veeru nimetus); märge, kas tegemist on isikuandmetega; märge, kas tegemist on eriliigiliste isikuandmetega; märge, kas tegemist on andmekogu põhiandmetega; märge, kas tegemist on arhiiviväärtuslike andmetega; viide andmekogule, kust mittepõhiandmed pärinevad; andmeobjekti semantiline kirjeldus (selgitus, mis andmeobjektiga on tegemist).

(Kõik märked formaadis jah/ei.)

Dokument (fail) esitatakse lõppaktiga.

tellija tellija poolne projektijuht

Nõuded projektiplaanile

Pakkumuse osana esitatakse projektiplaan, mis sisaldab ajakava kõikide funktsionaalsuste loomise ja selle pakkumuse alustamiseks vajalike tööde läbiviimiseks. Pakkumuses esitatavalt projektiplaanilt eeldatakse vastavust järgmistele tingimustele:

PP 1.1 Projektiplaanis kirjeldatud tööde läbiviimise tulemusena peab olema saavutatud projekti eesmärk ja soovitud funktsionaalsus.

PP 1.2 Iga projektiplaani töö kohta peab olema kirjeldatud töö nimetus, töö tegija(te) sh vastutaja roll/nimi, ajaline kestus inimtundides ja tähtaeg.

PP 1.3 Projektiplaanis peab kajastuma töö tegemiseks vajalikud eeldused/lähteandmed ning töö mõõdetav(ad) tulem(id). Projektiplaan peab sisaldama mh. tähtaegu, mis on rakendatavad hankijale/välisele osapoolele projekti edukaks realiseerimiseks vajalike sisendite tagamise kohta.

PP 1.4 Kõik projektiplaanis kirjeldatud tööd peavad olema omavahel loogiliselt seotud ja jaotatud iteratsioonidena.

PP 1.5 Projektiplaan peab sisaldama varuaega (puhvrit) ja selles peab arvestama riiklike pühade, puhkepäevade ja projektimeeskonna puhkustega.

PP 1.6 Projektiplaan peab olema ajakohastatud kogu projekti teostamise vältel.

PP 1.7 Lisaks projektiplaanile tuleb kirjeldada, kuidas projektijuhtimise riske maandada kavatsetakse (pakkumuse eraldi dokument).

Lisa väljakuulutamiseta läbirääkimistega hankemenetluse

„Vanglate ettevõtluskeskuse Buumi e-pood“ (302688)

hankedokumentide juurde

TEHNILINE KIRJELDUS

1. Hanke üldinfo

1.1. Käesoleva hankega otsime vanglateenistuse ettevõtluskeskuse (VEK) e-poe ja

kodulehekülje arenduspartnerit, et luua kaasaegne ja kasutajasõbralik e-pood koos

täiendavate sisulehtedega, mis tutvustavad asutust ja tooteid. Loodav veebileht peab

olema lihtsasti hallatav, visuaalselt meeldiv ja vanglateenistuse ettevõtluskeskuse CVI-

le vastav, hästi toimiv nii desktop- kui mobiiliseadmetes ning vastama kõigile

tänapäevastele veebiarenduse ja kasutajamugavuse standarditele. Koduleht majutub

riigiasutusele sobival platvormil (Drupal, Wordpress), millel on vajalikud liidesed

laotarkvaraga Buum. Koduleht ja e-pood peab kasutama analüütikaprogrammi

Matomo.

1.2. Hankelepingu järgsete tööde (tehnilise kirjelduse punktid 2-3 ning selle alapunktid)

eeldatav maksumus on 60 000 eurot (km-ta). Hankija jätab õiguse hankemenetlus

tunnistada kehtetuks, kui pakkumuse maksumus ületab eeldatavat maksumust või kui

hankemenetluse toimumise ajal on hankijale saanud teatavaks uued asjaolud, mis

välistavad või muudavad ebaotstarbekaks hankemenetluse lõpuleviimise hanke

alusdokumentides sätestatud tingimustel.

1.3. Lisaarendustööde maksimaalne maksumus on 30 000 eurot (km-ta). Hankijal on õigus,

mitte kohustus, lisaarendustöid tellida. Lisaarendustöid on hankijal võimalik tellida 18

kuu jooksul alates hankelepingu sõlmimisest.

1.4. VEK e-poe/ veebilehe ja selle kasutusjuhendi üleandmise tähtaeg on hiljemalt

15.12.2025. E-poega seotud lõpliku dokumentatsiooni üleandmine tuleb teostada

lepingu perioodi jooksul. Hankija poolt antav tööde teostamise tähtaeg on hankija

hinnang. Juhul, kui pakkuja leiab, et hankija poolt etteantud tähtaeg on ebarealistlik,

siis on pakkuja kohustatud seda pakkumust tehes või sellele eelnevalt hankijale teada

andma. Hankelepingu täitmisel on vastavate sooviavalduste esitamine välistatud, v.a

hankija poolt lisatööde tellimise olukorras või muul riigihangete seaduse §-s 123 toodud

lepingu muudatust võimaldavas olukorras.

1.5. Hankelepingu järgsete tööde (tehnilise kirjelduse punktid 2-3 ning selle alapunktid) eest

tasumine toimub ühes osas hankelepingus (hankesse lisatud dokument

Arenduslepingu projekt) täpsustatud tingimustel. Lisaarendustööde eest tasumine

toimub pärast vastavate tööde vastuvõtmist hankelepingus täpsustatud tingimustel.

1.6. Nõuded pakkumusele:

1.6.1. Pakkumuses tuleb esitada hinnapakkumine koos tööde lõpptähtajaga ja detailse

ajakava kirjeldusega (projektiplaan).

1.6.2. Pakkumusele tuleb lisada detailne pakkumuse maksumuse kirjeldus, milles tuleb

eristada kogu veebirakenduse erinevate komponentide maksumust (nt tavaveebi

osa, sisuhalduse osa, rakenduse osa(d)).

1.6.3. Pakkumuses tuleb kirjeldada pakkuja meeskonda ning meeskonnaliikmete

vastutusalasid.

1.7. Hankeleping jõustub allkirjastamise hetkest ja kehtib kuni lepingujärgsete kohustuste

nõuetekohase täitmiseni. Pakkujal peab olema valmisolek alustada

hankelepingujärgsete tööde teostamisega hiljemalt kahe nädala jooksul hankelepingu

sõlmimisest ja nimetatud tingimusega tuleb pakkujal pakkumust, sh projektiplaani

esitades arvestada. Eeldatav lepingu sõlmimise aeg on 25.11.2025. Täpne töödega

alustamise aeg lepitakse poolte vahel kokku.

1.8. Hanke läbiviijaks ja hankelepingu allkirjastajaks on Registrite ja Infosüsteemide

Keskus.

1.9. Maksjaks on Tallinna Vangla.

1.10. Vajadusel peavad pooled läbirääkimisi hanke tehnilise kirjelduse küsimustes, va

üldised tehnilised funktsionaalsused.

1.11. Iga viidet, mille hankija teeb käesolevas dokumendis mõnele riigihangete seaduse

paragrahvi 88 lõikes 2 nimetatud alusele kui pakkumuse tehnilisele kirjeldusele

vastavuse kriteeriumile, tuleb lugeda selliselt, et see on täiendatud märkega „või

sellega samaväärne“.

1.12. Iga viidet, mille hankija teeb käesolevas dokumendis ostuallikale, protsessile,

kaubamärgile, patendile, tüübile, päritolule või tootmisviisile, tuleb lugeda selliselt, et

see on täiendatud märkega „või sellega samaväärne“.

2. Praegune olukord ja eesmärgid

2.1. Praegu on Vanglateenistus.ee lehel vaid eraldi vaheleht, mis tutvustab

ettevõtluskeskust pealiskaudselt – seal on kontaktandmed ja tegevusalade loetelu,

kuid sisu on suures osas suunatud Stovemani brändile. Näha saab tootevaliku

pildigaleriid ja edasimüüjate infot, kuid terviklik ülevaade VEK-ist ja selle arengust

puudub. Olemasolev info tuleks uuele kodulehele üle tuua, kuid seal võiks vanglate

tööstuste harud olla visuaalselt atraktiivselt ja süsteemselt esitatud, näiteks kolme

vangla kaupa. Selline lahendus annaks ettevõtetele selgema ja mugavama arusaama,

millistes vanglates mida tehakse ning millised on võimalused koostööks. Samuti võiks

e-poes eraldi olla Stovemani toodete alajaotus sarnaste kategooriate ja edasimüüjate

infoga, et brändi väärtus ja eripära oleks paremini esile toodud.

2.2. Veebikeskkonna lõppkasutaja profiilideks on peamiselt uued ettevõtted, kes otsivad

tootmisvõimalusi või tööjõudu, eraisikud, kes soovivad osta VEK-i toodangut, meedia

ja avalikkus, kes otsivad infot VEK-i tegevuse kohta.

2.3. Hanke eesmärkideks on:

2.3.1. Luua intuitiivne ja kasutajasõbralik koduleht koos e-poega, mis võimaldab

külastajatel hõlpsasti tutvuda asutuse infoga ja toodetega ning neid tellida.

2.3.1.1. Luua sujuv ja kiire ostuteekond. Sh mugav toodete filtreerimissüsteem -

õmblustooted, metallitooted, puidutooted, kingikomplektid, väiksemad-

suuremad esemed. Samuti võiks filtreerimissüsteemis olla võimalus

tooteid leida hinnaklassi järgi.

2.3.1.2. Tagada lisaks arvutile ka mugav mobiilisõbralik disain.

2.3.2. Luua informatiivsed ja selged sisulehed ning menüüjaotised, mis tutvustavad

ettevõtet ja selle tegevusvaldkondi. Veebilehe eesmärk on aidata leida VEK-ile

uusi koostööpartnereid, pakkudes ülevaadet olemasolevatest tööstustest ja

tehtud tööde näidetest. See annab ettevõtetele võimaluse hinnata, kuidas oma

tootmist või töölõike meie juurde tuua, et suurendada vangide tööhõivet.

Veebileht peab pakkuma ettevõtetele ka selget valikut:

2.3.2.1. tuua oma töölõigud meie juurde teostamiseks, või

2.3.2.2. palgata avavangla kinnipeetavad tööle oma ettevõttesse, tutvudes

veebileheküljel toodud eeliste ja võimalustega.

2.3.3. Tagada veebilehe kiire ja turvaline toimimine ning mugav kättesaadavus.

2.3.4. Integreerida vajalikud makse, lao-, ja tarnesüsteemid.

2.3.5. Tagada lihtne haldusliides toote, sisu ja tellimuste haldamiseks, mida kasutab

edaspidi tellija.

2.3.6. Veebikeskkond peab olema visuaalselt atraktiivne ning VEK-i kuvandit toetav,

olema VEK-i CVI-ga kooskõlas, ühtlasi sarnane karjaar.vanglateenistus.ee

leheküljega ülesehituse poolest.

2.3.6.1. Veebikeskkond, koduleht ja e-pood, peavad looma usaldusväärse

esmamulje, mis esindab VEK-i kui professionaalset ja kvaliteetset tootjat

ja teenuspakkujat.

2.3.7. Tagada intuitiivne haldusliides, mis võimaldaks VEK-i töötajatel iseseisvalt

veebilehte hallata.

3. Hanke tulemite nõuete kirjeldus

Hanke tulemusena peab valmima uus VEK e-pood/veebileht, mis on võimeline pärima

andmeid (laoseisu) kasutades Buumi liidest. VEK e-poe ja veebilehe funktsionaalsusi

hõlmavate tulemite nõuded on eraldi kirjeldatud punktis 3.2. „Funktsionaalsed nõuded“.

Lisaks eeltoodule loetakse tulemiks ka projekti arendusfaasi jooksul tekkinud

dokumentatsiooni. Hankijale antakse üle järgnevad dokumendid:

1. Arenduste kirjeldus, sh äri- ja süsteemianalüüsi dokumentatsioon

2. Veebirakenduse arhitektuuri kirjeldus

3. Veebirakenduse kasutus- ja haldusjuhendid

4. Administreerimisjuhend/paigaldusjuhend

5. Testimise tulemusena valminud dokumendid

6. Varundus/taasteplaan

7. Versiooni kirjeldus

8. Mittefunktsionaalsete nõuete vastavustabel

9. Andmekogude semantiline kirjeldus ja andmekoosseis.

Detailsed nõuded üleantavatele dokumentidele on leitavad Lisas 5 – Dokumentatsiooniplaan.

Arenduste kirjelduse dokumendi sisule esitatud täiendavad nõuded leiab Lisast 2 – Nõuded

süsteemianalüüsile. Testimise tulemusena valminud dokumentide sisule esitatud täiendavad

nõuded leiab Lisast 3 – Nõuded testimisele.

3.1. Nõuded arendusele

Loodav rakendus tuleb luua Drupal või Wordpress sisuhaldusplatvormil või Hankija kirjalikku

taasesitamist võimaldavas vormis antud nõusolekul muu samaväärne sisuhaldusplatvorm.

Rakendada peab olema võimalik lisamooduleid nagu Solr ja Matomo.

Hankija soovib, et rakenduse arhitektuur ja protsessid jääksid lihtsaks ning selle haldamine ja

edasised arendused on tulevikus jõukohased ka nooremarendajale.

Veebileht ja selle haldusliides peavad olema kasutatavad koos Cloudflare teenusega.

Arendustöödes arvestatakse arendustööde tegemise ajal kehtivate WCAG nõuetega.

Veebirakendus peab vastama avaliku teabe seaduse §-s 32 ja ministri määruses nr 20

„Veebilehe ja mobiilirakenduse ligipääsetavuse nõuded ning ligipääsetavust kirjeldava teabe

avaldamise kord„ kehtestatud ligipääsetavusnõuetele (sealhulgas vastavus standardile EN

301 549). EN 301 549 V3.2.1 (2021-03) on avaldatud pdf-versioonis standardiorganisatsiooni

ETSI veebilehel:

https://www.etsi.org/deliver/etsi_en/301500_301599/301549/03.02.01_60/en_301549v03020

1p.pdf.

Ülejäänud nõuded arendusele on toodud Lisas 1 – Nõuded arendustele. Arendamisel tuleb

lähtuda Hankija sätestatud arenduse tavadest ja töökorraldusest, täpsemad nõuded on toodud

Lisas 4– Arenduse tavad ja töökorraldus.

3.2. Funktsionaalsed nõuded

3.2.1. Käesoleva peatüki eesmärgiks on teada anda sõlmitava lepingu eset

puudutavatest peamistest tehnilistest tingimustest, mis ei asenda lepingu

täitmisel kohalduvaid täiendavaid mittefunktsionaalseid nõudeid jmt. Tegemist ei

ole seega lõplike nõuetega. Hankelepingujärgsete tööde teostamisel on pakkujal

õigus teha omapoolseid täiendus- ja muudatusettepanekuid. Kui hankija nõustub

pakkuja poolsete täiendus ja/või muudatusettepanekutega, ei ole pakkuja

kohustatud tööde teostamisel lähtuma sõlmitava hankelepingu aluseks olevast

tehnilisest kirjeldusest määral, mis vastab uutele kokkulepetele. Juhul kui

pakkuja poolne muudatusettepanek tähendab lisatöid hankijale, peab pakkuja

seda eraldi rõhutama. Vastava teavituse puudumisel eeldab hankija, et

muudatuse realiseerimiseks ei teostata lisatöid.

3.2.2. E-poe funktsionaalsuse raames peab olema tagatud:

 Tootehaldus: Võimalus lisada, redigeerida ja eemaldada tooteid, määrata

kategooriad, hinnad, kampaaniad ja laoseis. Samuti on võimalik töötajatel

iseseisvalt lisada uusi kategooriaid vastavalt vajadusele, näiteks hooajapõhised

lahendused (nt jõulukomplektid, kingitused tähtpäevaks vms).

 Liidesed: Buumi liides, mis on juba omakorda SAPiga liidestatud,

maksekorralduse liides, tellimuse kinnituste liides tellija meilitsi teavitamine.

 Tooteotsing: Lihtne ja efektiivne otsinguvõimalus toodete leidmiseks, koos

filtreerimisvalikutega (hind, kategooriad, populaarsus jms).

 Ostukorv ja kassa: Selge ostukorv ja lihtne kassaprotsess, kus kasutaja saab

sisestada tarne- ja makseandmed. Isikuandmete kaitse ja säilitamine.

 Makselahenduste integratsioon: Makseteenuse pakkujaga, kes on liidestatud

Eesti ja Balticumi pankadega (nt Swedbank, SEB, LHV, Luminor, Citadele) ning

lisaks võimaldab vastu võtta makseid erinevate kanalite kaudu (nt pangalingid,

kaardimaksed (Visa, Mastercard), PayPal, makselingid jms) nt EveryPay.

 Tarnelahenduste integratsioon: Koostööpakkujatega nagu Omniva, DPD,

Smartposti jms – tarneviiside valik ja hinnastamine.

 Tellimuste haldus: Administreerimissüsteem tellimuste jälgimiseks ja

haldamiseks, koos kliendi e-posti teavituste funktsiooniga.

 Tagasiside: Teenuse ja toote tagasiside küsimine meili teel ja võimalus tagasiside

sisestada kodulehel.

 Tagastus- ja garantiisüsteem: Võimalus algatada tagastusi ja hallata

garantiiteenuseid.

 Klienditeekonna mugavuse funktsionaalsused: Kui kasutaja naaseb eelmisele

lehele (nt tootenimekirja), taastab süsteem automaatselt sama kerimisasendi ja

kuvab lehe selles punktis, kus kasutaja eelnevalt sirvimise lõpetas.

3.2.3. Sisulehed ja asutust tutvustavad jaotiste välja töötamine ja disainimine vastavalt

vanglateenistuse stiiliraamatule (lisa 7), võttes arvesse selle lisas 1 olevaid

erisusi vanglateenistuse ettevõtluskeskuse kujundustele

3.2.4. Peale e-poe funktsionaalsuse on vajalikud järgmised sisulehed ja menüüjaotised:

 Avaleht: jaotistena ülevalt alla: päis – videod-pildid, lühitutvustus,

tootekategooriate karusell, meist lähemalt – meeskond, kontakt, populaarsemate

toodete karusell,

 Asutuse kohta: Info ettevõtte kohta (missioon, visioon, ajalugu, meeskond,

kontaktandmed).

 Teenused: Ülevaade pakutavatest teenustest (nt. konsultatsioonid, hooldus või

muud seotud teenused).

 Tagasiside

 Uudiskirjaga liitumise võimalus

 Avalehe dünaamiline teaberiba: Avalehe alumisele osale lisada liikuva sisuga

riba, mis kuvab uudiseid, uusi tooteid ja kampaaniaid. Riba sisu peab olema

hallatav haldusliidese kaudu, võimaldades edaspidistel kasutajatel seda lihtsalt ja

kiiresti muuta ning uuendada.

3.2.5. Täiendavad sisulehed:

 Klienditugi: KKK, tagasisidevorm ja kontaktandmed klienditeeninduse jaoks.

 Privaatsus ja tingimused: Juriidilised lehed nagu kasutustingimused,

privaatsuspoliitika, ligipääsetavuse teatis ja küpsiste poliitika.

3.2.6. Tehnilised Nõuded

 Sisuhaldussüsteem: Drupal või Wordpress

 SEO optimeeritus: Leht peab kindlasti olema optimeeritud otsingumootoritele.

 Seadmesõbralikkus: Veebileht peab olema täielikult mobiilseadmetele ja

tahvlitele kohandatud.

 Kasutusmugavus (UX/UI): Veebilehe disain peab olema kasutajasõbralik, lihtne

ja intuitiivne.

 Kiirus ja jõudlus: Veebileht peab olema optimeeritud kiireks laadimiseks ja

probleemivabaks kasutamiseks suure koormuse korral. Piltide suuruse ja

kuvamise kirjeldus?

 Analüütika: Matomo

 Dockeri võimekus: Projekti peab saama käivitada Dockeri abil (Dockerfile ja/või

docker-compose)

 Pilve võimekus: Veebilehele peab olema loodud Kubernetese lahendus Helm

vahenditega ja kaasa pandud Helm Chart koos soovituslike väärtustega

 Andmevahetusteenus Buumi ja e-poe vahel: Tagada e-poe töö Buumi

mahakäimisel.

 Cloudflare: Veebileht, e-pood ja selle haldusliides peavad olema kasutatavad

koos Cloudflare teenusega.

4. Projektipõhised nõuded ja töökorraldus

4.1. Projekti juhib pakkuja. Projekti elluviimisel on oluline tihe koostöö RIKi

tugiinfosüsteemide tiimiga ning VEK esindajatega. Koostööna jõutakse ühistele

arusaamadele kooskõlastatavate tegevuste osas ning üleantavate tulemite detailides,

sh peab hankija olema pakkujaga samas infoväljas ning omama ülevaadet teostatavate

tööde seisust ja pakkumuse koosseisus esitatava projektiplaani järgimisest.

4.2. Projekti arendustööd peavad vastama RIKis kehtestatud nõuetele, mille hulgas tuleb

arvesse võtta nõudeid:

4.2.1. Arendustele (Lisa 1 – Nõuded arendustele);

4.2.2. Süsteemianalüüsile (Lisa 2 – Nõuded süsteemianalüüsile);

4.2.3. Testimisele (Lisa 3– Nõuded testimisele);

4.3. Projekti raames tuleb järgida RIKi sätestatud arendamise tavasid ja töökorraldust (Lisa

4 – Arendamise tavad ja töökorraldus).

4.4. Hankija hinnangul saab hankelepingujärgsed tööd jaotada järgmisteks etappideks:

4.4.1. Esialgne konsultatsioon ja planeerimine: Koosolekud, kus arutatakse projekti

detaile ja ajakava.

4.4.2. Disain ja prototüüpimine: Disain valitakse pakkuja olemasolevatest näidistest.

4.4.3. Arendus ja testimine: Arendusfaasis luuakse kõik vajalikud funktsioonid, mille

järel toimub testimine.

4.4.4. Koolitus ja dokumentatsioon: Peakasutajate koolitus (umbes 10 inimesele) ja

tehniline dokumentatsioon veebilehe haldamiseks.

4.4.4.1. Pakkuja tagab peakasutajatele adekvaatse väljaõppe, kindlustamaks

seadmete, telekommunikatsioonide, tarkvara ja teenuste rahuldava ja

efektiivse toimimise.

4.4.4.2. Pakkuja viib peakasutajate koolituse(d) läbi Tallinnas um kümnele

inimesele. Koolitus(t)e toimumise aeg ja koht lepitakse poolte vahel kokku.

4.4.5. Veebilehe/e-poe avalikustamine: Lõplik testimine, veebilehe avalikustamine.

4.5. Projekti raames tuleb järgida dokumentatsiooniplaani nõudeid. Tehnilise kirjelduse p

1.4. tähtajaks annab pakkuja hankijale üle arendusega seotud dokumentatsiooni

vastavalt dokumentatsiooniplaanis esitatule (Lisa 5 – Dokumentatsiooniplaan).

4.6. Kogu dokumentatsioon tuleb vormistada RIK Confluence keskkonnas, kui ei lepita

kokku teisiti.

4.7. Projekti raames koostatud dokumentatsioon peab vastama järgmistele

vormistusnõuetele:

4.7.1. Dokumentide teemad ja peatükid on loogiliselt struktureeritud ja esitatud koos

sisukorraga (või seda asendava funktsionaalsusega).

4.7.2. Dokumendid ei sisalda kirjavigu ja on koostatud võimalikult üheselt arusaadava

ja selge lauseehitusega.

4.7.3. Dokumentide sisu osas vastutuse selgemaks eristamiseks on dokumendis

märgitud kõik selle koostajad eraldi nende osade juures, mida iga koostaja

koostas.

4.7.4. Kõik kasutatud allikmaterjalid peavad olema viidetes ära märgitud ning viitamine

teistele dokumentidele on selge ja ühtses stiilis.

4.7.5. Dokumendid on koostatud eesti keeles.

4.8. Hankelepingu tööde teostamise tegevuskava kirjeldatakse ära pakkumuse osana

esitatavas projektiplaanis. Tegevuste ajalise järjestuse ja korduvuse valib pakkuja.

Projektiplaan peab sisaldama ajakava kõikide hanke tehnilises kirjelduses kirjeldatud

tööde läbiviimiseks ja vastama projektiplaanile esitatud nõuetele (Lisa 6– Nõuded

projektiplaanile).

4.9. Lisaks projektiplaanile tuleb kirjeldada, kuidas projektijuhtimise riske maandada

kavatsetakse (pakkumuse eraldi dokument). Riskide maandamise võimalused ja

halduse ettepanekud (lähtuvalt käesolevast projektist) on esitatud selgelt, detailselt,

läbimõeldult, struktureeritult ja põhjendatult.

4.10. Pakkuja poolt üleantud ja testitud arendusi testitakse RIKi hallatavas keskkonnas.

5. Lisaarendused

5.1. Lisaarenduste tellimise protseduur:

Hankijal on õigus, kuid mitte kohustus, tellida 18 kuu jooksul lisaarendustöid

(hindamiskriteeriumis märgitud lisaarendus töötunni maksumus). Hankija jätab endale õiguse

tellida hooldus- ja arendustöid vastavalt tekkivale vajadusele maksimaalselt kuni 30000 euro

(km-ta) ulatuses. Lisaarendustööde tellimused rahastatakse hankija eelarvelistest vahenditest.

5.2. Lisaarenduste tellimine toimub tellimuste esitamise teel. Tellimused esitatakse Hankija

kontaktisiku poolt Teenusepakkuja kontaktisikule. Tellimus peab sisaldab vähemalt

järgnevat:

5.2.1. kõiki sisulisi andmeid, mis on vajalikud pakkumuse koostamiseks;

5.2.2. pakkumuse eeldatavat maksumust eurodes (km-ta);

5.2.3. pakkumuse esitamise tähtaega.

5.3. Teenusepakkuja esitab Hankijale hiljemalt 5 tööpäeva jooksul arvates tellimuse

edastamisest pakkumuse. Pakkumus peab sisaldama:

5.3.1. tellimuses nõutud andmeid;

5.3.2. juhul, kui tellimuses nõutud, tuleb pakkumuses esitada ka lähteülesandes

kirjeldatud funktsionaalsuse detailseks analüüsiks, realiseerimiseks, testimiseks

ning dokumenteerimiseks kuluvat aega arendustundides; infosüsteemi

riistvaralistest komponentides vajalike muudatuste kirjeldust; Infosüsteemiga

seotud infosüsteemide arendustööks vajalike tarkvarakomponentide täienduste

kirjeldust;

5.3.3. ajahinnangut kalendripäevades pakkumuse aktsepteerimisest Hankijale

arendustööde üleandmiseni.

5.4. Hankijal on õigus hinnapakkumus aktsepteerida või sellest loobuda.

5.5. Lisaarenduste (eel)analüüsiks ja pakkumise koostamiseks kulunud aega ei käsitleta

arendustööna ja nimetatut ei tasustata.

5.6. Teenusepakkuja alustab tellimuse täitmist, kui Hankija on andnud kirjalikku

taasesitamist võimaldavas vormis kinnituse pakkumuse sobivuse kohta.

5.7. Tellimuse üleandmine ja vastuvõtmine toimub vastavalt hankelepingus sätestatud

korrale.

Lisad:

1. Nõuded arendustele

2. Nõuded süsteemianalüüsile

3. Nõuded testimisele

4. Arenduse tavad ja töökorraldus

5. Dokumentatsiooniplaan

6. Nõuded projektiplaanile

7. Vanglateenistuse stiiliraamat

Visuaalne identiteet

Sissejuhatus

Missioon Vanglateenistuse mission on toetada õigusrikkuja naasmist õiguskuuleka elu juurde.

Visioon Vanglateenistuse sihiks on, et Eesti korduvkuritegevuse tase oleks üks madalamaid Euroopas. 



Vanglateenistus pakub ühiskonnale turvatunnet, õigusrikkujatele võimalust edukalt naasta tavaellu ning sisejulgeoleku professionaalidele missiooniga motiveerivat tööd.

sissejuhatus

väärtused

Oleme mõistvad ja toetavad

Märkame ja tunnustame teisi inimesi

Suhtume igasse inimesse lugupidavalt

Usaldame ennast ja teisi

Kujundame üheskoos turvalisemat Eestit

Teeme tööd pühendunult ja missioonitundega

Teadvustame iga töötaja rolli asutuse eesmärkide elluviimisel

Peame kinni kokkulepetest ja lubadustest

Väärtustame teadmispõhisust ja argumenteeritust

Märkame oma eksimusi ja õpime nendest

Teeme igakülgset koostööd kõikide osapooltega

Julgeme otsustada ja vastutada

Oleme avatud uutele ideedele ja muutustele

Töötame välja paindlikke lahendusi

Võtame initsiatiivi ja näeme väljakutsetes võimalusi

Soovime õppida ja areneda

pühendumus asja-
 tundlikkus

Inimlikkus uuendus-
 meelsus

sissejuhatus brändi olemus

INIMLIKKUS ENNEKÕIKE Meie tähelepanu keskmes on inimesed ja nende heaolu. Töötame selle nimel, et õigusrikkujate käitumises toimuks muutus ja nende elu jätkuks pärast kokkupuudet vanglateenistusega õiguskuulekamalt.

MUUDAME KOOS
 EESTI turvalisemaks

LOOME KOOS VÄÄRTUST Meie edu saab sündida vaid üheskoos partnerite ja kogukonnaga. Koos muudame mõttemustreid, anname uusi võimalusi ja suurendame oma tegevuse mõju.

OLEME AVATUD Selgitame ja tutvustame avatult meie töö olulisust ning võimalusi, pakume ekspertarvamust õigusrikkujate paremaks taasühiskonnastamiseks ja inimeste turvatunde suurendamiseks. Iga töötaja on meile tähtis, hoolime ja hoiame üksteist.

ARENG ON MEILE TÄHTIS Meie neli strateegilist eesmärki, mille nimel igapäevaselt tööd teeme on järgmised

Efektiivne organisatsioo Tulemuslik taasühiskonnastaj Turvaline keskkond kõigil Hinnatud tööandja

SISSEJUHATUS HÄÄLETOON

Vanglateenistus on oma hääletoonilt pigem tõsine ja asjalik, kuid seejuures ei kasuta kantseliitlikke ega inimeste jaoks mõistmatuid väljendeid.

Kuigi Vanglateenistus võib väljast vaatajale mõjuda kinnise asutusena, siis oma suhtlusviisilt on Vanglateenistus alati avatud ja läbipaistev, kuid ei muutu seejuures liialt familiaarseks.

Vanglateenistus austab oma väärtusi, mis kajastuvad kõneviisis ja kommunikatsioonis ning kohandub uuendustele oma isikupära kaotamata.

Vanglateenistus väärtustab iga indviidi, kes ühel või teiselt viisil Vanglateenistusega kokku puutub, kuid tegutseb ühtse ja kokkuhoidva kollektiivina, kus kedagi ei jäeta kõrvale. Nii on ka Vanglateenistus oma suhtlusviisilt kaasav ja arvestav ning iga meeskonnaliikme panust esiletoov.

Humoorikas

FAMILIAARNE

ametlik

TRADITSIOONILINE

KINNINE

Tõsine

VÄÄRIKAS

INIMLIK

uuendusmeelne

avatud

sissejuhatus hüüdlause

Ühiselt loome turvalisemat Eestit

vanglateenistus.ee

Kujundustes võib hüüdlause olla nii põhisõnum kui ka lisasõnum, mis põhisõnumit täiendab.

Hüüdlause kirjutamiseks kasutatakse läbivate suurtähtedega fonti Inter Black 
 (vt tüpograafia lehte).

vanglate nimetuste ja nimede õigekiri

Kõigi kolme vangla nimetuste kirjutamisel eelistatakse väikest algustähte.

Asutusel, äriühingul, organisatsioonil või ühendusel võib olla kas nimi või nimetus. Nende kirjutamise reegli tuum on lihtne: nimi kirjutatakse suure tähega, nimetus väiksega (üksnes kindlatel tingimustel ka suurega). Nimed on nt Tallinna Vesi, Kangas ja Nööp. Nimetused on nt justiitsministeerium, linnamuuseum, vanglateenistus.

Ühtseks keelekasutuseks kirjutame vangla suure algustähega õigusaktides ja ametlikus kirjavahetuses dokumendiregistri vahendusel:

Tallinna Vangla Viru Vangla

E-kirjades, mitteametlikel kujundustel ning sotsiaalmeedia tekstides kirjutame vangla väikese tähega:

Tallinna vangla Viru vangla justiitsministeerium

NB! Mistahes muu asutuse nimetuse kirjutamiseks suure tähega veenduge, et

suure tähega kirjutatud asutus on juriidiline isik esitatud nimekuju on täpne ja täielik.

Kui kahtlete, siis kirjutage nimetus väikeste tähtedega, v.a kohanimi.

Ametlik suurtäht ei laiene osakondade ega muude allüksuste nimetustele ja need kirjutame alati väikese algustähega:

vanglateenistuse relvastatud üksus

vanglateenistuse Ida-Harju kriminaalhooldusosakond

Kui teksti laad ei nõua ametlikku suurtähte, siis eelistame väikest – ei ole olemas üksikuid nimetusi, mille puhul oleks suurtäht kohustuslik.

Põhielemendid

Põhielemendid riiklik sümboolika

Riigivapi süsteem vanglateenistuse TurundussüsteemVastavalt valitsuse otsusele kasutavad kõik valitsusasutused olulistes kommunikatsioonikanalites ja infokandjatel riigivapi logo, muudel infokandjatel riigivapist tuletatud kolme lõviga logo.

Muudel infokandjatel kasutatava logo osas andis justiitsminister 8.05.2014 vanglateenistusele erisuse ning loa jätkata riigivapi süsteemist eristuva sümboolika kasutamist.

Riigivapiga logo kujundus on kinnitatud Riigikantseleis. Etteantud mõõtude, proportsioonide ja trükiettevalmistuse tehniliste nõuete järgimine on kohustuslik. Erandjuhtudel tuleb pidada nõu justiitsministeeriumi avalike suhete talituse või vastava töölõigu eest vastutavate töötajatega.

Korrektsed logod saab alla laadida aadressilt riigikantselei.ee/valitsuslogo#

logode struktuur

Vanglateenistuse vapp

Vanglateenistuse vappi kasutatakse vormiriietel ja lipul.

Ühes kujunduses ei kasutata korraga nii Vanglateenistuse vappi kui ka Vanglateenistuse logo.

Vanglateenistuse vapp

Põhielemendid turundussümboolika

logo

Logomärk Vanglateenistuse logod koosnevad sümbolist ja sõnamärgist “VANGLATEENISTUS” või vastava allasutuse sõnamärgist.

Sõnamärki kasutada ilma sümbolita.ei või

Sümbol Vanglateenistuse sümbol koosneb kilbist ja lõvist.

Sümbolit võib kasutada ilma sõnamärgita.

Vesimärk Vesimärki kasutatakse videotes all paremal nurgas.

Vesimärgiga tekitatud mustrit võib kasutada ainult tumehallil taustal (helehall taust on lubatud erandina vaid videokoosolekute juures) ja erandina valitud kohtades brändingu rõhutamiseks (nt Talendipank, videokoosolekute taust, vaheslaidid ja šokolaadiümbrised).

Sümbol Sõnamärk

Vesimärk (valge värv, mis on 50% läbipaistev)

Vesimärgi muster (valge värv, mis on 10% läbipaistev)

asutuste logod

Vanglateenistuse asutuste logod kasutavad ühesuguseid ülesehituspõhimõtteid. Logod koosnevad sümbolist, suurest sõnamärgist ja täiendist. Vanglateenistuse põhilogo eestikeelses versioonis täiend puudub.

Asutuste põhilogodeks on üherealised logod.

Erandjuhtudel – näiteks väikestel kitsastel pindadel – võib kasutada ka kompaktlogo.

NB! Kriminaalhooldusel puudub kompaktlogo.

Kriminaalhooldusel puudub kompaktlogo

Põhilogod Kompaktlogod

logode variatsioonid

Heledatel taustadel ja fotodel kasutatakse tumehalli tekstiga logo.

Tumedatel taustadel kasutatakse valge tekstiga logo. Sümboli värv seejuures ei muutu.

Ühevärvilist logo kasutatakse ainult tootmisviisist tingitud piirangute tõttu, näiteks graveerimisel ja pimetrüki korral.

LOGO TÄISVÄRVIDES MONOKROOMNE KASUTUS
 (ERANDJUHTUMITEL)

Logo kaitsTUD ala

Kõikide Vanglateenistuse asutuste logode kaitstud ala konstrueeritakse logo sõnamärgis olevate tähtede kõrgusest. Kaitstud alasse ei tohi sattuda logoga konkureerivaid tekste ja teisi graafiliselt intensiivseid elemente.

Logo lubatud ja 
 keelatud kasutusE NÄITED

Ära muuda logo värve

Ära muuda sümboli ja sõnamärgi omavahelist suurust

Ära muuda logo proportsioone

Ära lisa efekte

Ära muuda logo sõnamärgi kirjatüüpi

Ära paiguta logo väikese kontrastiga või kirjule taustale

Logo sõnamärki ei või kasutada ilma sümbolita

Ära kasuta logo kollasel taustal

Inter Black

Inter Regular / Italic

Inter Bold / Bold Italic

Arial Regular / Bold / Italic ABCDEFGHIJKLMNOPQRSTUVWXYZÄÖÜÕ
 abcdefghijklmnopqrstuvwxyzäöüõ
 1234567890€

Helvetica Regular / Bold / Italic ABCDEFGHIJKLMNOPQRSTUVWXYZÄÖÜÕ
 abcdefghijklmnopqrstuvwxyzäöüõ
 1234567890€

Sisutekstid: Inter Regular / Italic Inter Bold / Bold Italic

Asenduskirja-
 perekonnad Arial (PC) Helvetica (Mac)

Asenduskirjaperekondadena kasutatakse juhtudel, kus Interi kasutamine ei ole vajalik või võimalik (näiteks e-kirjad), kirjaperekondi Arial (PC) ja Helvetica (Mac).

Asenduskirjatüüpe ei või kasutada kujundatud avalikes kommunikatsiooni- materjalides.

ABCDEFGHIJKLMNOPQRSTUVWXYZÄÖÜÕ 1234567890€

ABCDEFGHIJKLMNOPQRSTUVWXYZÄÖÜÕ abcdefghijklmnopqrstuvwxyzäöüõ 1234567890€

ABCDEFGHIJKLMNOPQRSTUVWXYZÄÖÜÕ abcdefghijklmnopqrstuvwxyzäöüõ 1234567890€

ABCDEFGHIJKLMNOPQRSTUVWXYZÄÖÜÕ abcdefghijklmnopqrstuvwxyzäöüõ 1234567890€

ABCDEFGHIJKLMNOPQRSTUVWXYZÄÖÜÕ abcdefghijklmnopqrstuvwxyzäöüõ 1234567890€

Tüpograafia

Vanglateenistuse kirjaperekonnaks on 
 Inter, mida kasutatakse Vanglateenistuse graafilistes ja kirjalikes materjalides kõikjal, kus see on tehniliselt võimalik ja ühtse visuaalse kuvandi loomiseks vajalik.

Inter on tasuta kirjaperekond, mille saab alla laadida Google Fontsist: fonts.google.com/specimen/Inter? query=inter

Pealkirjad: Inter Black

Tüpograafia kasutamine

Vanglateenistuse kujundatud materjalide pealkirjades kasutatakse läbiva suurtähega kirjastiili Inter Black, mille tähevahe on vähendatud -5%. Samuti kasutatakse tavalisest väiksemat reavahet, mille puhul tuleb jälgida täpitähtede täppide-katuste võrdset kaugust tekstiridadest.

Tavatekstides ja väikepealkirjades tähe- ja reavahet ei vähendata.

Sotsiaalse rehabilitatsiooni programmid õigusrikkujatele

kuidas
 töötab päike ja kust tuleb tolm?

kuidas
 töötab päike ja kust tuleb tolm?

kuidas
 töötab päike ja kust tuleb tolm?

Üldharidus on hariduse alus

Üldharidust pakuvad Tartu vanglas Tartu täiskasvanute gümnaasium ja Tartu Kroonuaia kool, Tallinna vanglas Tallinna täiskasvanute gümnaasium ja Viru vanglas Kohtla-Järve täiskasvanute gümnaasium. Põhiharidust on võimalik omandada nii eesti kui ka vene keeles. Vangid, kes on enne vangistust omandanud põhiharidust lihtsustatud õppekava alusel, võivad jätkata selle omandamist samadel alustel.

vanglakeskkonnas
 ÕppimisE võimalused

Pealkiri 1
 Inter Black Läbiv suurtäht Tähevahe -5% Vähendatud reavahe

reavahe näide pealkirjades: sobiv

reavahe näide pealkirjades: liiga tihe

reavahe näide pealkirjades: liiga hõre

Pealkiri 2
 Inter Black Läbiv suurtäht Tähevahe -5% Vähendatud reavahe

Pealkiri 3
 Inter Bold Tähevahe muutmata

Sisutekst Inter Regular Tähevahe muutmata Vajadusel suurendatud reavahe

GraafiliSED elemenDID

Sinust algab eesti turvalisus

Sissepääs eelregistreerimiseta.
 Vajalik ID-kaart või pass!

Laupäev, 9. september 2023 Turu 56, Tartu

Vanglateenistuse peamiseks graafiliseks elemendiks on logo sümbolist tuletatud kilbi fragment, mida saab kasutada värviaksendina või raamina, mille sisse paigutada fotot.

Teine graafiline element on kollane joon, mida võib kasutada ainult koos fotoga.

Värvid

KUJUNDUSKEELE VÄRVID Vanglateenistuse kujunduskeele värvideks on tumehall, kollane ja valge. Kollane on täiendvärv, mida kasutatakse peamiselt graafilistel elementidel aktsendina. Kujunduskeeles rohekaskollast ja kuldset värvi reeglina ei kasutata. Rohekaskollase või kuldse kasutus on lubatud vaid erandjuhtumitel väga esinduslikes materjalides, mis ei ole tavapärased avalikud turundusmaterjalid. Rohekaskollase või kuldse kasutamise osas teeb igal korral otsuse Justiitsministeeriumi kommunikatsiooniosakond.

LOGO VÄRVID
 Vanglateenistuse logo värvideks on rohekaskollane/kuldne ja tumehall. Kilbil olev lõvi on kujutatud valgega. Vapikilbi värvina on digitaalselt võimalik vaid rohekaskollase kasutamine, sama toon on eelistatud ka trükitud materjalides. Vaid äärmisel juhul kasutatakse logos rohekaskollase asemel trükkimisel kuldset trükivärvi või kuldset fooliumi (fooliotrükk).

RGB 
 RGB#

CMYK Pantone Kleebis

tumehall
 Logo sõnamärgi värv

343A40 52 58 64

44 34 22 77 Cool Grey 11 Avery 759 Dark Grey

FFFFFF 255 255 255 0 0 0 0

FFFFFF 255 255 255 0 0 0 0

000000 0 0 0 0 0 0 100

RGB 
 RGB#

CMYK Pantone Kleebis

tumehall
 Tekstide ja taustade värv

52 58 64 343A40

44 34 22 77 Cool Grey 11 Avery 759 Dark Grey

valge

RGB 
 RGB# CMYK

valge

RGB 
 RGB# CMYK

must

RGB 
 RGB# CMYK

RGB 
 RGB#

CMYK Pantone Kleebis

Rohekaskollane / kuldne
 Logo sümboli kilbi värv

178 150 38 B29626

7 28 100 30 118 / 871 metallik kuldne Avery 736 Gold Metallic

RGB 
 RGB#

CMYK Pantone Kleebis

kollane
 Täiendvärv

255 200 0 
 FFC800

0 20 100 0 116 Avery 739 Bright Yellow

TUMENDATUD KOLLANE

Veebiaadressi vanglateenistus.ee kujutamiseks valgel taustal

RGB#
 EDBA00

CMYK 8 26 100 0

8A8E91

B5B8BA

E1E1E2

47 45 34 14

33 23 23 3

14 10 10 0

FFDF6C

FFEBA3

FFF7D9

RGB# FFD436

RGB# 5F6469

CMYK 60 47 43 31

0 11 67 0

0 6 45 0

0 2 20 0

CMYK 0 17 84 0

Sissepääs eelregistreerimiseta.
 Vajalik ID-kaart või pass!

Laupäev, 9. september 2023 Turu 56, Tartu

Sissepääs eelregistreerimiseta.
 Vajalik ID-kaart või pass!

Laupäev, 9. september 2023 Turu 56, Tartu

Sissepääs eelregistreerimiseta.
 Vajalik ID-kaart või pass!

Laupäev, 9. september 2023 Turu 56, Tartu

Esita avaldus: vangla.ee

Kandideerimiseks saada enda CV
 hiljemalt 31.08.2024

Esita avaldus: vanglateenistus.ee

Kandideerimiseks saada enda
 CV hiljemalt 31.08.2024

Sissepääs eelregistreerimiseta.
 Vajalik ID-kaart või pass!

Laupäev, 9. september 2023 Turu 56, Tartu

Esita avaldus: vangla.ee

Tule
 Tallinna Vangla
 finantsjuhiks Kandideerimiseks saada enda CV
 hiljemalt 31.08.2023

Vanglateenistuses töötajaile on esmatähtsad neli olulist väärtust, millest juhindume oma tegudes nii tööl kui eraelus.

Oleme mõistvad ja toetavad Märkame ja tunnustame teisi inimesi

Suhtume igasse inimesse lugupidavalt Usaldame ennast ja teisi.

Tunneme suurt vastutust turvalisema Eesti loomisel Teeme tööd pühendunult ja missioonitundega

Teadvustame iga töötaja rolli asutuse eesmärkide elluviimisel Peame kinni kokkulepetest ja lubadustest.

Väärtustame teadmispõhisust ja argumenteeritust Märkame oma eksimusi ja õpime nendest

Teeme igakülgset koostööd kõikide osapooltega Julgeme otsustada ja vastutada.

Oleme avatud uutele ideedele ja muutustele Töötame välja paindlikke lahendusi

Võtame initsiatiivi ja näeme väljakutsetes võimalusi Soovime õppida ja areneda.

Esita avaldus: vangla.ee

Kandideerimiseks saada enda CV
 hiljemalt 31.08.2024

Esita avaldus: vanglateenistus.ee

Kandideerimiseks saada enda
 CV hiljemalt 31.08.2024

VärvidE lubatud ja keelatud KASUTAMINE

Esita avaldus: vangla.ee

Tule
 Tallinna Vangla
 finantsjuhiks Kandideerimiseks saada enda CV
 hiljemalt 31.08.2023

Vanglateenistuses töötajaile on esmatähtsad neli olulist väärtust, millest juhindume oma tegudes nii tööl kui eraelus.

Oleme mõistvad ja toetavad Märkame ja tunnustame teisi inimesi

Suhtume igasse inimesse lugupidavalt Usaldame ennast ja teisi.

Tunneme suurt vastutust turvalisema Eesti loomisel Teeme tööd pühendunult ja missioonitundega

Teadvustame iga töötaja rolli asutuse eesmärkide elluviimisel Peame kinni kokkulepetest ja lubadustest.

Väärtustame teadmispõhisust ja argumenteeritust Märkame oma eksimusi ja õpime nendest

Teeme igakülgset koostööd kõikide osapooltega Julgeme otsustada ja vastutada.

Oleme avatud uutele ideedele ja muutustele Töötame välja paindlikke lahendusi

Võtame initsiatiivi ja näeme väljakutsetes võimalusi Soovime õppida ja areneda.

Foto koos halli nurgaga

Näidised on seotud üheleheküljeliste kujundustega: plakatid, trükised jms.

Kollast kasutame peamiselt aktsentvärvina – graafilise elemendi või tekstina. Kollane ei tohiks kunagi kujundustes domineerida.

Hall taust ja valge nurk Hall taust ja kollane nurk Valge taust ja kollane nurk Hall taust ja foto koos kollase joonega

Valge taust ja foto koos kollase joonega

Ära kasuta fotol halli joont Ära kasuta fotol halli joont, kollast põhitausta ega logo kollasel taustal

Ära kasuta kollast tausta terves ulatuses (v.a esitlused, küljendatud raamatud/dokumendid, kus kollane mõjub aktsentvärvina)

Ära kasuta fotot ja kollast nurka koos ega logo kollasel taustal

Ära kasuta kollast tausta koos valge nurgaga

Ära kasuta kollast tausta koos halli nurgaga

Sissepääs eelregistreerimiseta.
 Vajalik ID-kaart või pass!

Laupäev, 9. september 2023 Turu 56, Tartu

Ära kasuta kuldset tausta terves ulatuses

Ühiselt loome turvalisemat Eestit

Tallinna Vangla ootab registreerima hea käitumise ja õppeedukusega 10. – 12. klassi õpilasi, kes tunnevad huvi riigi sisejulgeoleku ja aktiivse sportliku tegevuse vastu.

Enesekaitse koolitusele registreerimiseks saada oma ees- ja perekonnanimi, isikukood, kooli nimi, klass ja kontakttelefon aadressile [email protected]

vanglateenistus.ee Registreerimine

kestab kuni 17.09.2024

Rakendusnäited

karjäärilehe näidisKUJUNDUS

Näidis illustreerib värvide, graafika ja kirjastiilide kasutust töökuulutuste keskkonnas Talendipank.

Oleme mõistvad ja toetavad

Märkame ja tunnustame teisi inimesi

Suhtume igasse inimesse lugupidavalt

Usaldame ennast ja teisi

Tunneme suurt vastutust turvalisema Eesti loomisel

Teeme tööd pühendunult ja missioonitundega

Teadvustame iga töötaja rolli asutuse eesmärkide elluviimisel

Peame kinni kokkulepetest ja lubadustest

Väärtustame teadmispõhisust ja argumenteeritust

Märkame oma eksimusi ja õpime nendest

Teeme igakülgset koostööd kõikide osapooltega

Julgeme otsustada ja vastutada

Oleme avatud uutele ideedele ja muutustele

Töötame välja paindlikke lahendusi

Võtame initsiatiivi ja näeme väljakutsetes võimalusi

Soovime õppida ja areneda

pühendumus asjatundlikkusInimlikkus uuendusmeelsus

Meie väärtused

Ootame Sind kandideerima, kui Sinu sisemised väärtused lähevad kokku Vanglateenistuse väärtustega:

Tule alusta oma juhtimiskogemuse omandamist järelevalve- korralduse üksuses.

Töö põhiülesandeks on juhtida ja kontrollida valvetoimkondi. Lisaks saad panustada erakorraliste sündmuste-lahendamisse ning tagada vangla julgeolek.

Kandideerimise tähtaeg: 23. august 2023

Meil on

Töötasu alates 1870 euro

Väärt väljaõp

Sport töö os

Head karjäärivõimaluse

Toetav meeskon

Töö ja vaba aja tasakaal

Sul on

Laitmatu taus

Missioonitunn

Kõrgharidu

Eestikeele oskus C1 taseme

Hea füüsiline, vaimne vor

Soov töötada meeskonnas

Sinu küsimustele vastab

Annika Tamm [email protected] tel. 8765 8765

Eesnimi

Sinu andmed

E-post

Kandideerimisavaldus

Lisa oma CV

Lisa failid

Saada avaldus

Perekonnanimi

Telefon

inspektor- korrapidaja abi
 TALLINNA VANGLAS

MUUDAME KOOS EESTI turvalisemaks

Oleme mõistvad ja toetavad

Märkame ja tunnustame teisi inimesi

Suhtume igasse inimesse lugupidavalt

Usaldame ennast ja teisi

Tunneme suurt vastutust turvalisema Eesti loomisel

Teeme tööd pühendunult ja missioonitundega

Teadvustame iga töötaja rolli asutuse eesmärkide elluviimisel

Peame kinni kokkulepetest ja lubadustest

Väärtustame teadmispõhisust ja argumenteeritust

Märkame oma eksimusi ja õpime nendest

Teeme igakülgset koostööd kõikide osapooltega

Julgeme otsustada ja vastutada

Oleme avatud uutele ideedele ja muutustele

Töötame välja paindlikke lahendusi

Võtame initsiatiivi ja näeme väljakutsetes võimalusi

Soovime õppida ja areneda

pühendumus asjatundlikkusInimlikkus uuendusmeelsus

Meie väärtused

Ootame Sind kandideerima, kui Sinu sisemised väärtused lähevad kokku Vanglateenistuse väärtustega:

Tule alusta oma juhtimiskogemuse omandamist järelevalve- korralduse üksuses.

Töö põhiülesandeks on juhtida ja kontrollida valvetoimkondi. Lisaks saad panustada erakorraliste sündmuste-lahendamisse ning tagada vangla julgeolek.

Kandideerimise tähtaeg: 23. august 2023

Meil on

Töötasu alates 1870 euro

Väärt väljaõp

Sport töö os

Head karjäärivõimaluse

Toetav meeskon

Töö ja vaba aja tasakaal

Sul on

Laitmatu taus

Missioonitunn

Kõrgharidu

Eestikeele oskus C1 taseme

Hea füüsiline, vaimne vor

Soov töötada meeskonnas

Sinu küsimustele vastab

Annika Tamm [email protected] tel. 8765 8765

Eesnimi

Sinu andmed

E-post

Kandideerimisavaldus

Lisa oma CV

Lisa failid

Saada avaldus

Perekonnanimi

Telefon

inspektor- korrapidaja abi
 TALLINNA VANGLAS

Ühiselt loome 
 turvalisemat Eestit

Esitluste näide

Esitlustes ja infograafikas võib info paremaks eristamiseks kasutada brändi põhivärvide pooltoone.

Kollast värvi võib taustana kasutada vaid esitlustes ja näiteks raamatute küljendamisel vahelehena. Muudes materjalides on see keelatud.

Kollase taustavärvi kasutamisel ei tohi sinna lisada Vanglateenistuse graafilisi elemente.

NB! Siin esitatud slaidid näitlikustavad erinevaid slaiditüüpe ega ole korrektse sisuga.

infograafika

4151201 Tallinna VanglasInimest töötas aastavahetuse

seisuga vanglateenistuses

Vanglateenistuse tööd kordineerib Justiitsministeeriumi vanglate osakond, kus töötas aastavahetuse seisuga 29 inimest

321 Tartu Vanglas

465 Viru Vanglas

vanglateenistuse töötajad

68 korda

kainenemised 42

korda reaalne vangistus

36 korda reaalne

vangistus

Elu jooksul enim kordi vanglas

Vangla eelarve 2023

53% Personalikulud

29% Kinnistute ülapidamine

8% Majandamis- kulud

7% Käibemaks

3% Ülekantavad

vahendid 2022 LEA

Esitlustes ja infograafikas võib info paremaks eristamiseks kasutada brändi põhivärvide pooltoone.

Vanglateenistus

Tallinna Vangla Tartu Vangla Viru Vangla

Vangla direktor Vangla direktor Vangla direktor

Direktori asetäitja Direktori asetäitja Direktori asetäitja

Juhiabi Sisekontrolli valdkond Relvastatud üksuse juht

Avavangla üksuse juht Sisekontrolli valdkond Haldusosakona juhataja

Näidis illustreerib infograafika kasutust esitluste näitel.

Sotsiaalmeedia päise- JA PROFIILIPILDID

Sotsiaalmeedias kasutatakse profiilipildina ilma kilbi kujutiseta sümbolit: valge lõvi rohekaskollasel taustal.

Kaanefotode loomisel võib kasutada fotot koos sõnumiga, ainult fotot või ainult teksti.

Ühiselt loome turvalisemat Eestit

Vanglateenistus @Vanglateenistus

Profiilipilt

Linkedin

Facebook

Vanglateenistus @Vanglateenistus

Ühiselt loome turvalisemat Eestit

Sandra Lembitu Sandra Lembitu

Vanglateenistus @Vanglateenistus

Ühiselt loome turvalisemat Eestit

Vanglateenistus 2.3K likes • 2.5K followers

Sotsiaalmeedia postitused ja reklaamid

Ühiselt loome turvalisemat Eestit

stereotüübid on murd- miseks

Väärikas töö parema Eesti heaks

Tule tööle vanglateenistusse 
 ja aita muuta Eesti turvalisemaks

Aita luua muutust

Tule sotsiaaltöötajaks vanglateenistusse!

vanglateenistus.ee/cv

Vanglateenistus 1920 followers

Send

Vanglateenistus Siia saab kirjutada selgitava teksti, mis saadab pilti. Seetõttu ei ole vaja kõike pildile kirja panna. Teksti maht ei ole sisuliselt piiratud, kuid arvestada tuleb inimeste tähelepanuvõimega. Kõike ei ole vaja püüda alati välja öelda.5200

5324

2022 saabumised ja vabanemised

saabus

vabanes Sinust algab eesti turvalisus

Väärikas töö parema Eesti heaks

Inimlikkus Oleme mõistvad ja toetavad

Märkame ja tunnustame teisi inimesi

Suhtume igasse inimesse lugupidavalt

Usaldame ennast ja teisi

Oleme mõistvad ja toetavad

Märkame ja tunnustame teisi inimesi

Suhtume igasse inimesse lugupidavalt

Usaldame ennast ja teisi

Tunneme suurt vastutust turvalisema Eesti loomisel

Teeme tööd pühendunult ja missioonitundega

Teadvustame iga töötaja rolli asutuse eesmärkide elluviimisel

Peame kinni kokkulepetest ja lubadustest

Väärtustame teadmispõhisust ja argumenteeritust

Märkame oma eksimusi ja õpime nendest

Teeme igakülgset koostööd kõikide osapooltega

Julgeme otsustada ja vastutada

Oleme avatud uutele ideedele ja muutustele

Töötame välja paindlikke lahendusi

Võtame initsiatiivi ja näeme väljakutsetes võimalusi

Soovime õppida ja areneda

pühendumus asjatundlikkusInimlikkus uuendusmeelsus

väärtuste PlakatiTE NÄITED graafikaga

Vanglateenistuse väärtuste kommunikeerimiseks kasutatatavate plakatite kujundusnäiteid.

Failid leiad brändi failipakist.

Desktop

Oleme mõistvad ja toetavad.

Suhtume igasse inimesse lugupidavalt.

Märkame ja tunnustame teisi inimesi.

Usaldame ennast ja teisi.

Ühiselt loome turvalisemat Eestit

Tunneme suurt vastutust turvalisema Eesti loomisel.

Teeme tööd pühendunult ja missioonitundega.

Teadvustame iga töötaja rolli asutuse eesmärkide elluviimisel.

Peame kinni kokkulepetest ja lubadustest.

Ühiselt loome turvalisemat Eestit

Väärtustame teadmispõhisust ja argumenteeritust.

Teeme igakülgset koostööd kõikide osapooltega.

Märkame oma eksimusi ja õpime nendest.

Julgeme otsustada ja vastutada.

Ühiselt loome turvalisemat Eestit

Oleme avatud uutele ideedele ja muutustele.

Võtame initsiatiivi ja näeme väljakutsetes võimalusi.

Töötame välja paindlikke lahendusi.

Soovime õppida ja areneda.

Ühiselt loome turvalisemat Eestit

Oleme mõistvad ja toetavad

Märkame ja tunnustame teisi inimesi

Suhtume igasse inimesse lugupidavalt

Usaldame ennast ja teisi.

Tunneme suurt vastutust turvalisema Eesti loomisel

Teeme tööd pühendunult ja missioonitundega

Teadvustame iga töötaja rolli asutuse eesmärkide elluviimisel

Peame kinni kokkulepetest ja lubadustest.

Väärtustame teadmispõhisust ja argumenteeritust

Märkame oma eksimusi ja õpime nendest

Teeme igakülgset koostööd kõikide osapooltega

Julgeme otsustada ja vastutada.

Oleme avatud uutele ideedele ja muutustele

Töötame välja paindlikke lahendusi

Võtame initsiatiivi ja näeme väljakutsetes võimalusi

Soovime õppida ja areneda.

Ühiselt loome turvalisemat Eestit

Plakatite NÄITED

Täpsem info: Registreerimine:

vanglateenistus.ee [email protected]

31.08.2023 / 9:00 Paunküla heaolukeskus

Registreeri: vanglateenistus.ee

17–25.08.2023 18:00–20:00

vanglateenistus.ee

Sissepääs eelregistreerimiseta.
 Vajalik ID-kaart või pass!

Laupäev, 9. september 2023 Turu 56, Tartu

Tutvu: vanglateenistus.eeTule tööle Vanglateenistusse Esita avaldus: vanglateenistus.ee

Tule Tallinna Vangla Finants- analüütikuks Kandideerimiseks saada enda CV
 hiljemalt 31.08.2023

Esita avaldus: vanglateenistus.ee

Kandideerimiseks saada enda CV
 hiljemalt 31.08.2023

rollup-reklaamide näited

Tule valvuriks vangla-
 teenistusse

vanglateenistus.ee

TULE ühis- konnale kasu toovale TÖÖLE

vanglateenistus.ee

tagame KINDLAmat eestit

vanglateenistus.ee

Tänukiri

Mart Kotkas Suur tänu meeldiva koostöö ja osalemise eest üritusel “Siil 2023”

Mailis Kukk Juhiabi

Tartu Vangla 08.08.2023

tänukiri, diplom

Dokumendipõhjad on vormistatud docx- formaadis.

diplom

Sandra Lembitu Suur tänu meeldiva koostöö ja osalemise eest üritusel “Siil 2023”

Mailis Kukk Juhiabi

Tartu Vangla 08.08.2023

Paber: Conqueror 
 Iridescent Silver Mist

Curious Metallics White Silver

TöökuUlutusE näidis lühem tekst

Esita avaldus: vanglateenistus.ee

Kandideerimiseks saada enda CV
 hiljemalt 31.08.2023

Esita avaldus: vanglateenistus.ee

Kandideerimiseks saada enda CV
 hiljemalt 31.08.2023

Esita avaldus: vanglateenistus.ee

Tule
 Psühholoogiks tallinna vanglasse Kandideerimiseks saada enda CV hiljemalt 31.08.2023

Esita avaldus: vanglateenistus.ee

Tule
 inspektor- kontaktisikuks tallinna vanglasse

Kandideerimiseks saada enda CV
 hiljemalt 31.08.2023

Tule
 Psühholoogiks tallinna vanglasse Kandideerimiseks saada enda CV hiljemalt 31.08.2023

Esita avaldus: vanglateenistus.ee

TöökuUlutuse näidis pikem tekst

Tule alusta oma juhtimiskogemuse omandamist järelevalve- korralduse üksuses.

Töö põhiülesandeks on juhtida ja kontrollida valvetoimkondi. Lisaks saad panustada erakorraliste sündmuste- lahendamisse ning tagada vangla julgeolek.

Meil on

Töötasu alates 1870 euro

Väärt väljaõp

Sport töö os

Head karjäärivõimaluse

Toetav meeskon

Töö ja vaba aja tasakaal

Kandideerimiseks saada CV hiljemalt 31.08.2023 läbi kandideerimisportaali

Sul on

Laitmatu taus

Missioonitunn

Kõrgharidu

Eestikeele oskus C1 taseme

Hea füüsiline, vaimne vor

Soov töötada meeskonnas

Tule inspektor-kontaktisikuks Tallinna Vanglasse

Tallinna Vangla Linnaaru tee 5, Rae vald

+372 1234 5678 [email protected] vanglateenistus.ee

Tallinna Vangla köögitoimkond ootab oma meeskonda kokka, kelle peamine ülesanne on valmistada personalile kvaliteetset ja tervislikku toitu. Selle juures on abiks kogu köögitoimkond

Meil on

Töötasu alates 1300 euro

Tööaeg E-R, 7.00–15.3

Sport töö os

Regulaarne tervisekontrol

35 päeva puhkust

Kandideerimiseks saada CV hiljemalt 31.08.2023 läbi kandideerimisportaali

Sul on

Erialane haridu

Laitmatu taus

Missioonitunn

Eestikeele oskus B2 taseme

Soov töötada meeskonnas

Tule Tallinna Vanglasse kokaks


Tallinna Vangla Linnaaru tee 5, Rae vald

+372 1234 5678 [email protected] vanglateenistus.ee

digitaalne kutse

Digitaalsetel kutsetel kasutatakse fotosid, millele on lisatud graafiline element, Vanglateenistuse logo, hüüdlause ja lühidalt kutse põhisõnum.

Pikem ja detailsem tekst on lisatud e-kirjas lahtise tekstina.

Plakat

Ühiselt loome turvalisemat Eestit vanglateenistus.ee

Tallinna Vangla ootab registreerima hea käitumise ja õppeedukusega 10.–12. klassi õpilasi, kes tunnevad huvi riigi sisejulgeoleku ja aktiivse sportliku tegevuse vastu.

Enesekaitse koolitusele registreerimiseks saada oma ees- ja perekonnanimi, isikukood, kooli nimi, klass ja kontakttelefon aadressile [email protected] või külasta meie kodulehte vanglateenistus.ee

Registreerimine kestab kuni 17.09.2024

Mihkel Kotkas Treener

To:

From:

Subject:

Mari-Johanna Kuusepuu

Vanglateenistus

Tallinna vangla

Ühiselt loome turvalisemat Eestit

Tallinna Vangla ootab registreerima hea käitumise ja õppeedukusega 10. – 12. klassi õpilasi, kes tunnevad huvi riigi sisejulgeoleku ja aktiivse sportliku tegevuse vastu.

Enesekaitse koolitusele registreerimiseks saada oma ees- ja perekonnanimi, isikukood, kooli nimi, klass ja kontakttelefon aadressile [email protected]

vanglateenistus.ee Registreerimine

kestab kuni 17.09.2024

Ühiselt loome turvalisemat Eestit vanglateenistus.ee

Hea kolleeg

Meil on hea meel kutsuda sind Tallinna Vangla B-korpuse avamisele 25. septembril kell 14.00.

Pane end kirja hiljemalt 17.09.2024.

Rait Kuuse Vanglateenistuse juht

To:

From:

Subject:

Mari-Johanna Kuusepuu

Vanglateenistus

Kutse B-korpuse avamisele

digitaalne õnnitluskaart

Õnnitluskaartidel kasutatakse fotosid, millele on lisatud graafiline element, Vanglateenistuse logo, hüüdlause ja lühidalt kutse põhisõnum.

Pikem ja detailsem tekst on lisatud e-kirjas lahtise tekstina.

vanglateenistus.ee

Ühiselt loome turvalisemat Eestit

Häid jõule ja ilusat aastavahetust, Mari!

Soovime, et veedad selle erilise aja just sulle kõige olulisemate inimestega. Lähedastega, kellega saad südamlikult vana aasta ära saata ja uue säravalt vastu võtta.

Kõike jätkuvalt kaunist soovides,

Mart Tamm Juhiabi Vanglateenistus

To:

From:

Subject:

Mari-Johanna Kuusepuu

Vanglateenistus

Jõulutervitus

Ühiselt loome turvalisemat Eestit vanglateenistus.ee

Hea Mari!

Soovime sulle imelist sünnipäeva ja suurepäraseid kordaminekuid uuel eluaastal!

Las olla su elus vaid rõõmsad värvid,
 et säraks su silmad kui heledad pärlid.
 Et su helisev naer ika kaugele kajaks,
 et sind vajaksid need, keda sinagi vajad.

Tallinna Vangla toimekas pere

To:

From:

Subject:

Mari-Johanna Kuusepuu

Vanglateenistus

Sünnipäevatervitus

dokumendikaaned

Dokumendikaaned on mõeldud A4 lehtede hoidmiseks. Kujundus on puhas, minimalistlik.

Esiküljel on ainult logo, tagaküljel on kontaktandmed.

Paberite hoidmise nurk on kollase trükiga. Paber: Invercote Creato 300 või 350 gr

Esikaas Tagakaas

Sisekülg 1 Sisekülg 2

Vanglateenistus

Juriidiline tee 12
 Tallinn

vanglateenistus.ee

nahast kaaned /
 märkmikud

Logo on võimalik teostada monotrükiga – suru- ja/või värvitrükiga.

Visiitkaart

Visiitkaardid on kahepoolsed.

Mõõdud: 85x55 mm

Soovituslik paber: 
 Invercote Creato matt 300 g/m²

Dokumendipõhjad

Dokumendipõhjad on eelvormistatud docx- formaadis.

Failid leiad brändi failipakist.

E-kirja signatuur

Raul Kotkas Inspektor-kontaktisik +372 2345 6789 [email protected]

Tallinna vangla

See kiri on mõeldud adressaadireal nimetatud isikule. Isik, kes ei ole märgitud kirja adressaadiks, ei tohi seda kirja mingil viisil kasutada. Kui olete saanud kirja eksituse tõttu, palun teavitage sellest kohe kirja saatjat ja kustutage kiri koos kõikide lisadega.

Kirjastiil: Sans-serif / Arial

Sõnamärgi värv: RGB #5F6469

Raul Kotkas Inspektor-kontaktisik +372 2345 6789 [email protected]

Tallinna vangla

See kiri on mõeldud adressaadireal nimetatud isikule. Isik, kes ei ole märgitud kirja adressaadiks, ei tohi seda kirja mingil viisil kasutada. Kui olete saanud kirja eksituse tõttu, palun teavitage sellest kohe kirja saatjat ja kustutage kiri koos kõikide lisadega.

E-kirja signatuurina on soovituslik kasutada tekstipõhist varianti. Signatuuris Vanglateenistuse logo kasutamiseks oleme loonud erandina helehalli sõnamärgi, mis eristub peamisest hallist toonist, mida tavapäraselt kasutame. Nii on logo nähtav nii valgel kui ka mustal taustal. Helehalli sõnamärki võib kasutada ainult e-kirja signatuuri jaoks.

rõivad polosärgid

Vanglateenistuse polosärkide värvitoonideks soovitame kahte põhivärvi: valget ja tumehalli.

Särkidel ei kasutata graafikat ega muid elemente peale põhilogo ja sümboli.

rõivad t-särgid

Vanglateenistuse T-särkide värvitoonideks soovitame kahte põhivärvi: valget ja tumehalli.

Särkidel ei kasutata graafikat ega muid elemente peale põhilogo ja sümboli.

rõivad pusa ja püksid

Vanglateenistuse dresside värvitoonideks soovitame kahte põhivärvi: valget ja tumehalli.

Pusal ja pükstel ei kasutata graafikat ega muid elemente peale põhilogo ja sümboli.

rõivad Spordisärk- ja püksid

Vanglateenistuse spordiriiete värvitoonideks soovitame kahte põhivärvi: valget ja tumehalli.

Spordiriietel kasutame lisaks põhilogole ja sümbolile ka kollast triipu, et pimedamal ajal oleks sportija paremini nähtav.

rõivad spordipusa

Vanglateenistuse spordipusa värvitoonideks soovitame kahte põhivärvi: valget ja tumehalli. Lisaks toome siin sisse aksentvärvi – hallile pusale kollase ja 
 valgele halli.

Spordipusal ei kasutata graafikat ega muid elemente peale põhilogo ja sümboli.

surfilipp

Kasutatakse mitteametlikel üritustel.

vimpel

Vanglateenistuse vimpel on on logomärgikujuline ja trükitud kuldse värviga.

meened veepudel

Veepudel võib olla halli ja valget värvi või läbipaistev.

Pudelitel ei kasutata graafikat ega muid elemente peale põhilogo ja sümboli.

šokolaadiümbrised

Ühiselt loome turvalisemat Eestit

Esikülg Logo surutrükina

Tagakülg

Veebikoosolekute taustapilt

Veebikoosolekute taustaks kasutatakse neutraalsetes halltoonides tausta Vanglateenistuse sümboolikaga.

video vesimärk

Vanglateenistuse vesimärk paigutatakse videol alla paremasse nurka.

Vesimärgi puhul peas kasutama valget värvi 50%-lise läbipaistvusega.

Kasutage valget vesimärki läbipaistvusega 50%

Teenistussõiduk

Fotokeel

fotod portreed

Portreed on eelistatult pildistatud töökeskkonnas, mitte stuudios. Inimeste olek lihtne, pigem sõbralik. Lisavalguse, näiteks välkude kasutamine on lubatud, kui selleks on vajadus, kuid lisavalgust peab kasutama delikaatselt.

Inimesi kujutatakse nii vormirõivais kui vabas riietuses, kuid alati korrektsena.

Kasutatud näidispiltide autorid
 VT = Vanglateenistus KP = Katrin Press RA = Renee Altrov
 Tähistamata = pildipangad

fotod töö

Naturaalne, dokumentaalne, minimaalse lavastuslikkusega. Töötamist kujutatakse selle erinevates vormides, mida Vanglateenistus pakub: kontoritööst jõusituatsioonideni.

Inimesi kujutatakse situatsioonile kohases rõivastuses.

Kasutatud näidispiltide autorid
 VT = Vanglateenistus KP = Katrin Press RA = Renee Altrov
 Tähistamata = pildipangad

VT

fotod ÜHISTEGEVUSED

Vaba aja kujutamise eesmärk on näidata igapäevatööga mitteseotud tegevusi, sotsiaalseid olukordi, tööga kaasnevate võimaluste mitmekesisust.

Kasutatud näidispiltide autorid
 VT = Vanglateenistus KP = Katrin Press RA = Renee Altrov
 Tähistamata = pildipangad

fotod TÖÖKESKKOND

Töökeskkonda kujutatakse visuaalselt kvaliteetselt, sisult neutraalselt. Eelistatud on helged toonid, valgusrikkus. Vältida negatiivseid konnotatsioone.

Kasutatud näidispiltide autorid
 VT = Vanglateenistus KP = Katrin Press RA = Renee Altrov
 Tähistamata = pildipangad

LISA 1

Sisukord

Logo Värvid Tüpograafia Täiendav graafika Pildikeel Rakendamine

(02 — 03)

(04)

(05)

(06)

(07)

(08 — 14)

Käesoleva dokumendi eesmärgiks on anda ülevaade Vanglateenistuse Ettevõtluskeskuse visuaalse keele elementidest ja juhised nende rakendamiseks.


Vanglateenistuse Ettevõtluskeskus — Visuaalse keele juhis 2024

Logo

Vanglateenistuse Ettevõtluskeskuse logo on loodud tuginedes põhibrändi loogikale ja olemusele.



Logo kasutamisel järgida samu reegleid nagu on ette nähtud ka Vanglateenistuse põhibrändi puhul.

Vanglateenistuse Ettevõtluskeskus — Visuaalse keele juhis 2024

PÕHILOGO

PÕHILOGO NEGATIIVIS

Logo

Vanglateenistuse Ettevõtluskeskuse logo on loodud tuginedes põhibrändi loogikale ja olemusele.



Logo kasutamisel järgida samu reegleid nagu on ette nähtud ka Vanglateenistuse põhibrändi puhul.

KOMPAKTLOGO

KOMPAKTLOGO NEGATIIVIS

Vanglateenistuse Ettevõtluskeskus — Visuaalse keele juhis 2024

VÄRVID

Vanglateenistuse Ettevõtluskeskuse visuaalse keele värvilahendus on loodud tuginedes põhibrändi olemusele, et tagada sidusus aga teisalt on eristuvuse loomiseks kasutusel täiendvärvina hele- sinine, mis Vanglateenistuse brändi puhul on kollane.



Värvide kasutamisel kujunduskeele ja logo puhul lähtuda põhibrändi juhistest aga arvestada asjaoluga, et täiendvärviks on kollase asemel helesinine.

Tumehall

Tekstide ja taustade värv

HEX: #343A40 RGB: 52 / 58 / 64 CMYK: 44 / 34 / 22 / 77 Pantone Cool Grey 11 
 Kleebis Avery 759 Dark Grey

Helesinine

Täiendvärv

HEX: #85C4D6 RGB: 133 / 196 / 214 CMYK: 51/ 07 / 15 / 0 Pantone 630 C

Valge

HEX: #FFFFFF RGB: 255 / 255 / 255 CMYK: 0 / 0 / 0 / 0

Must

HEX: #000000
 RGB: 0 / 0 / 0 CMYK: 0 / 0 / 0 / 100

Vanglateenistuse Ettevõtluskeskus — Visuaalse keele juhis 2024

Tüpograafia

Vanglateenistuse Ettevõtluskeskuse visuaalse keele tüpograafiline lahendus on loodud tuginedes põhibrändi olemusele, et tagada sidusus aga teisalt on eristuvuse loomiseks kasutusel pealkirjadeks sama kirjastiiliperekonna teine kirjastiil.



Tüpograafia kasutamisel lähtuda põhibrändi juhistest aga arvestada asjaoluga, et pealkirjadeks on kasutusel Inter Black kirjastiili asemel Inter Light läbiva suurtähega.

Pealkirjad: Inter Light (läbiva suurtähega)

Alapealkirjad: Inter Medium

Sisu (body copy) ja täiendavad tekstid: Inter Regular

Loome alused eluks kogukonnas.

OSKUSED.


LooTUS. ENESEUSK.


Anna oma panus
 vanglateenistus.ee

Vanglateenistuse Ettevõtluskeskus — Visuaalse keele juhis 2024

Täiendav graafika

Vanglateenistuse Ettevõtluskeskuse visuaalse keele täiendava graafika lahendus ühtib põhibrändi puhul kasutatavaga ning rakendamine ei vaja täiendavaid juhiseid.

Tegemist on sama logo sümbolist tuletatud kilbi fragmendiga, mida saab kasutada värviaksendina või raamina, mille sisse paigutada foto.

Teine graafiline element on helesinine joon, mida võib kasutada ainult koos fotoga (Vanglateenistuse põhibrändi puhul on nimetatud joon kollane).

Loome alused eluks kogukonnas.

OSKUSED.
 ENESEUSK.
 LooTUS.

Anna oma panus vanglateenistus.ee

Loome alused eluks kogukonnas.

Anna oma panus vanglateenistus.ee

OSKUSED.
 ENESEUSK.
 LooTUS.

Vanglateenistuse Ettevõtluskeskus — Visuaalse keele juhis 2024

Pildikeel

Piltide valikul peaks jälgima nende tonaalsust, et need oleks sooja ja naturaalse olemusega. Eesmärgiks on edasi anda üldiselt natuke pehmemat ja kergemat olemust kui Vangla- teenistuse enda brändi puhul.

Fotodel olevad olukorrad peaksid olema lihtsad ja selged visuaalid inimestest tegemas kätega tehtavaid töid, mis peegeldaks võimalikult hästi Vanglateenistuse Ettevõtluskeskuse olemust.



Pildid peaksid olema helge iseloomu ja valgusküllase keskonna kooslus, mis loob visuaalselt soovitud emotsiooni kogu brändile.

Piltidel inimeste nägusi.

Kasutada järgnevaid pildipanku: • Unsplash.com • Pexels.com

ei näita

Vanglateenistuse Ettevõtluskeskus — Visuaalse keele juhis 2024

Rakendus- näidised

Vanglateenistuse Ettevõtluskeskus — Visuaalse keele juhis 2024

Digitaalsed Bännerreklaamid

Loome alused eluks kogukonnas.

Anna oma panus vanglateenistus.ee

Eesmärk. Rutiin. Võimekus.

Loome alused eluks kogukonnas.

Eesmärk. Rutiin. Võimekus.

Anna oma panus vanglateenistus.ee

Loome alused eluks kogukonnas.

OSKUSED.


LooTUS. ENESEUSK.


Anna oma panus vanglateenistus.ee

Vanglateenistuse Ettevõtluskeskus — Visuaalse keele juhis 2024

Reklaamid/postitused sotsiaalmeedias

Vanglateenistuse Ettevõtluskeskus — Visuaalse keele juhis 2024

Loome alused eluks kogukonnas.

OSKUSED.


LooTUS. ENESEUSK.


Anna oma panus vanglateenistus.ee

Loome alused eluks kogukonnas.

OSKUSED.
 ENESEUSK.
 LooTUS.

Anna oma panus vanglateenistus.ee

Loome alused eluks kogukonnas.

Eesmärk. rutiin. võimekus.

Alus eluks kogukonnas.

Eesmärk. .

võimekus. rutiin

Loome alused eluks kogukonnas.

OSKUSED.
 ENESEUSK.
 LooTUS.

Anna oma panus vanglateenistus.ee

Roll-up bänner

Vanglateenistuse Ettevõtluskeskus — Visuaalse keele juhis 2024

Visiitkaart

Tallinna vangla Linnaaru tee 5, Talinn

+372 5432 0345 [email protected]

Turundusspetsialist

Pille-Riin Loots

vanglateenistus.ee

Vanglateenistuse Ettevõtluskeskus — Visuaalse keele juhis 2024

Tootesilt

Vanglateenistuse Ettevõtluskeskus — Visuaalse keele juhis 2024

vanglateenistus.ee

See toode on valmistatud kinnipeetavate poolt, pakkudes neile võimalust õppida ja arendada uusi oskuseid. Vanglates toimuv tööhõive toetab kinnipeetavate paremat toimetulekut peale vabanemist.

Vali käsitöö, mis loob uut algust!

Digitaalne presentatsioon

Vanglateenistuse Ettevõtluskeskus — Visuaalse keele juhis 2024

OSKUSED.


LooTUS. ENESEUSK.


Siim-Gustav Maaler 02.07.2024

Siim-Gustav Maaler 02.07.2024

2024. aastal loodud vanglate ettevõtluskeskuse eesmärgiks on leida üha enam väliseid koostöö- partnereid avalikust- ja erasektorist.

01

MEIST

Detsember 2024

DIREKTOR

KÄSKKIRI 12.11.2025. a nr 70

Tallinn

Justiitsministri 18.04.2007. a määruse nr 20 „Registrite ja Infosüsteemide Keskuse põhimäärus“ § 11 lõike

1 punkti 9 alusel:

1. Algatan riigihanke „Vanglate ettevõtluskeskuse Buumi e-pood" (302688).

2. Nimetan käesoleva riigihanke komisjoni (edaspidi komisjon) koosseisus:

komisjoni esimees: Vesta Laansoo Tugiinfosüsteemide tiimi tiimijuht

hankenõunik: Teele Nässi Hankejuht

liikmed: Maarja Ottis Tugiinfosüsteemide tiimi ärianalüütik

Albert Lamartson Tugiinfosüsteemide tiimi tootejuht

Elgo Pehk Tallinna Vangla Vanglateenistuse

ettevõtluskeskuse juhataja

3. Kohustan komisjoni korraldama käesolev riigihange eesmärgiga sõlmida hankeleping.

4. Kinnitan riigihanke alusdokumendid.

5. Edastada hankedokumendid läbi Riigihangete registri ID Süsteemide OÜ-le (14259084). Menetluse liigi (väljakuulutamiseta läbirääkimistega hankemenetlus) ning läbirääkimiste partneri valiku põhjuseks on asjaolu, et vanglates on kasutusel IDS tarkvara BUUM, mida soovime liidestada hangitava e-poega. BUUM'le on IDS poolt juba vastav liides olemas ning ei tuleks uuesti nullist arenda. Laoarvestustarkvara Buum intellektuaalomandi õigused kuuluvad ID SÜSTEEMIDE OÜ-le, kellel on ainuõigus pakkuda nimetatud tarkvara liidest.RHS § 49 lg 1 p 2 kohaselt on hankijal õigus korraldada riigihange väljakuulutamiseta läbirääkimistega hankemenetlusena, kui hankelepingu saab sõlmida ainult ühe ettevõtjaga tehniliste või ainuõiguste, sh intellektuaalomandi õiguste kaitsega seotud põhjustel.

Käesoleva käskkirjaga moodustatud hankekomisjoni liikmed kinnitavad käskkirja kooskõlastamisega järgnevat:

• komisjoni liikmed on tutvunud Registrite ja Infosüsteemide Keskuse sisekorraeeskirjas ja hankekorras sisalduvate ametiisikutele kohalduvate kohustustega, mis seisneb eelkõige vajaduses taandada ennast hankekomisjoni liikme kohalt huvide konflikti olukorda sattumisel;

• komisjoni liikmed ei tegele kõrvaltegevusega, mis võiks seada neid käesoleva riigihanke komisjoni liikmeks olles huvide konflikti olukorda;

• dokumendihaldussüsteemis riigihanke dokumentide kooskõlastamisega kinnitab komisjoni liige, et ta on läbi töötanud kõik dokumendi failid ning nõustunud dokumendi failides sisalduvaga. Teise asutuse töötaja, kes on komisjoni liige, esitab vastava kinnituse e-kirja teel.

/allkirjastatud digitaalselt/

Rivo Reitmann

Hanke algatamine ja alusdokumentide kinnitamine riigihankes „Vanglate ettevõtluskeskuse Buumi e- pood" (302688)

Lisad: hankedokumendid „Vanglate ettevõtluskeskuse Buumi e-pood" (302688) koos lisadega

(vormistatud digitaalselt).