Väljaminev kiri

1

Lisa 2. Tehniline kirjeldus

Tellija nimi: SMIT

Minikonkursi nimetus: KILP isikukaitse, objektivalve ja suursündmuste juhtimine

Riigihangete registri viitenumber: 303850

Projekti algus esimesel võimalusel. Projekti valmimise tähtaeg21 kuud töödega alustamisest.

Lepingu eesmärk luua Politsei taktikalise juhtimise andmekogusse KILP (edaspidi: KILP) isikukaitse,

objektivalve ja suursündmuste haldamise ja taktikalise juhtimise võimekus.

Tulemid:

1. KILP-is on Objektivalve moodul, kus saab hallata mehitatud ja mehitamata valvatavaid objekte ja nende

teavet (sh kaardil kuvada valvatavaid objekte ja nende olukorda), planeerida objektide valvet ning

formeerida valveressurssi (teenistusleht). Lisaks saab KILP-is täita (k.a e-Politsei/Apollo kaudu) ning

hallata valvatavate objektide kaupa logi ja objektide koondlogi ning koostada valvete ja logi põhist

aruandlust.

2. KILP-is on Isikukaitse tegevuste planeerimise moodul, kus saab hallata isikukaitse subjekte, planeerida

isikukaitse tegevusi detailselt (ajakava, ülesanded, asukohad, ressurss (k.a vahendid), jne) kui ka

kalendervaates. Isikukaitse sündmused võivad olla osa Suursündmusest.

3. KILP-is on Isikukaitse tegevuste haldamise/juhtimise moodul, kus saab hallata ning juhtida aktiivsete

Isikukaitse tegevuste käiku nii operatiiv- kui detailvaates. Isikukaitse tegevuste logidest saab koostada

aruandlust.

4. KILP-is on Suursündmuste planeerimise moodul, kus saab planeerida, hallata ja täitmiseks ette

valmistada erinevat tüüpi suursündmuseid. Suursündmused võivad koosneda erinevatest ajalistest

hetkedest, asukohtadest, marsruutidest, aladest, etappidest ja ülesannetest. Suursündmuste raames

saab erinevaid ülesandeid täitmiseks anda erinevatele ressurssidele. Suursündmusele saab määrata

kasutajapõhist ligipääsu ning hallata sündmuse nägemise ulatust erinevatele kasutajatele.

Suursündmust planeerides saab määrata sündmuse või ülesannete täitmiseks vajalikku (ka kolmandate

osapoolte (PPA välise)) varustuse vajadust (piirded, telgid, jms) ja logistilist tuge (majutus, toitlustus

jms). Planeeritud suursündmusele saab anda ligipääsu kasutajatele väljaspool PPA-d ning

suursündmuse plaani saab eksportida failina.

5. KILP-is on Suursündmuste juhtimise moodul, kus saab hallata ja juhtida suursündmuseid.

Suursündmuste vaates on KILP-is näha vastava sündmuse etapid, asukohad, marsruudid, alad,

ressursid, jne. KILP-is juhtumi juurde määratud ohualad on vastavalt valikule nähtavad KILP üleselt ning

piirangute info on sünkroniseeritud Geoinfosüsteemiga, kus vastavalt ohualadele tehakse ka teekonna

arvutusi. Täiendatud on olemasoleva kaardivaate kasutajapõhiseid sätteid, mis toetavad

suursündmuste planeerimist ja juhtimist. Lisaks KILP-is on eraldiseisvalt võimalik välja sorteerida ja

kuvada valitud juhtumeid ning antud valikut on võimalik jagada teistele kasutajatele. Suursündmustest

saab koostada aruandlust (kokkuvõte).

Arvestada:

 Moodulite UI/UX lahenduste loomisel on kasutatud olemasolevat KILP disainisüsteemi põhimõtteid.

 Kõikide moodulite juures on täiendatud tulemitele vastavalt nii kahepoolseid kui ühepoolseid liidestusi

teiste infosüsteemidega, nagu Apollo (ressurss, teenistuslehed, jm), ALIS, TEPLA (tööaeg), SAP, Geoinfo

(piirangualad), jt.

2

 Olemasolevaid KILP komponente, nagu kasutajate ligipääsude haldus, PPA sisese lisaressursi haldus,

partnerite ressursi haldus, varustuse haldus, asukohaliigid ja -kuva, on täiendatud (analüüsitud,

projekteeritud ja arendatud) vastamaks tulemitele. Kasutajate ligipääsuõiguste süsteemi projekt on

kooskõlastatud SMIT-i ja PPA-ga.

 Enne arendustööde algust on kooskõlastatud antud projekti arhitektuur ning see on kaitstud SMIT

Arhitektuurinõukogu ees.

 Tulemite jaoks kasutatava andmebaasi mudel on projekteeritud ja kooskõlastatud SMIT-iga.

Faasid ja etapid Arendustööd toimuvad viies faasis, mis on jagatud vastavalt sisule etappideks, mille tulemusel on uued

funktsionaalsused kasutusele võetavad toodangukeskkonnas.

Faas I – Objektivalve moodul Etapid

1. Valvatava objekti haldus

2. Objekti valve planeerimine, meeskond ja teenistusleht

3. Valvatavate objektide logi pidamine

4. Valvatavate objektide koondlogi/aruandlus

5. Objekti valve operatiivvaade

Faas II – Isikukaitse planeerimise moodul Etapid

6. IK objektide haldus

7. IK tegevuste detailvaade (ajakava, ülesanded, asukohad, ressurss (k.a vahendid), jne)

8. IK tegevuste kalendervaade

Faas III – Isikukaitse haldamine/juhtimine Etapid

9. IK tegevuste juhtimise detailvaade

10. IK operatiivvaade (üksiktegevus, üldvaade)

11. IK tegevuste aruandlus

Faas IV – Suursündmuste planeerimise moodul Etapid

12. Isikute ja vahendite haldamine

13. Suursündmuse andmeobjekt ja loomine

14. Suursündmuse detailvaade (ajakava, etapid (sektorid, objektid, valdkonnad), asukohad,

marsruudid, alad, ülesanded/tegevused, isikute ressurss (töötajad/partnerid, juhid/vastutajad,

osalejad/rakendajad/reageerijad, tugi jne), teniline ressuruss)

15. Suursündmuste kalendervaade

16. IK sündmuste ajakava

17. IK Suursündmuste julgestuskava eksport

Faas V – Suursündmuste juhtimise moodul Etapid

18. Suursündmuse detailvaade operatiivtegevusteks

19. Suursündmuse operatiivvaade (üksiksündmus, üldvaade)

3

20. Suursündmuste aruandlus

Nõuded arendustööde protsessile

Dokumentatsioon ja kood

Töö teostamise käik ja/või tulem kantakse SMIT-i lähtekoodi repositooriumisse vastavalt tellija juhistele.

Dokumenteerimine toimub vastavalt täitja tarkvara arenduse metoodikale ning tellija täiendavatele nõuetele, mille eesmärgiks on tagada jätkusuutlik, läbipaistev ning kvaliteetne rakenduse arendus. Dokumentatsioon peab olema sellisel tasemel, et kui täitja teeb lahenduse valmis, siis edasi oleks võimalik järgmisel arendajal antud dokumentatsiooni pealt ilma raskusteta teha täiendusi.

Kasutusjuhendite testimiseks moodustatakse tellija poolne testgrupp, kes püüab juhendi järgi toiminguid teostada. Kui kasutaja ei suuda kasutusjuhendi järgi toiminguid teostada, peab täitja juhendit vastavalt täiendama.

Analüüs ja analüüsi dokumentatsioon

Teenuste lõplik spetsifikatsioon selgub analüüsi tulemusena, mille teostab täitja. Täitja poolt teostatav arenduse eelne analüüs peab arvestama tellija koostatud nõudeid. Analüüs peab vastama õigusaktidele ja reaalsetele tööprotsessidele.

Olemasolevad tehnilised lahendused ja joonised võivad kuuluda arenduse ja/või analüüsi käigus muutmisele. Kõik sisse viidavad muudatused peavad olema eelnevalt tellijaga kooskõlastatud. Analüüsi dokumendi tööversiooni täiendatakse paralleelselt arendustöödega, kuid arendustööde konkreetne realiseeritav osa peab olema tellijaga eelnevalt kooskõlastatud ja kirjeldatud analüüsi dokumendi tööversioonis. Dokumentatsioon peab tööde lõpliku üleandmise hetkel vastama tegelikkusele (st. kui arendamise käigus on tehtud midagi analüüsist erinevalt, siis tuleb ka analüüsi dokumenti vastavalt sellele muuta). Muudatused analüüsis tuleb kooskõlastada tellijaga.

Dokumentatsioon võetakse vastu arendustööde viimases etapis ning dokumentatsioon peab hõlmama kogu realiseeritavat osa. Projekti dokumentatsioon peab olema terviklik ja terminoloogiliselt üheselt mõistetav.

Täpsustunud arhitektuur ja andmemudel, komponentjoonised ja protsessivaated realiseeritakse UML-is.

Arendusprotsess ja testimine

Tarkvara arendusprotsessiks peab olema väle (Agile) arendusprotsess. Väleda arendusprotsessi all peetakse silmas kergekaalulist arendusprotsessi, muutustega kohandumist, inimestele orienteeritust. Tarkvara arendusprotsess peab olema jaotatud redaktsioonideks (2-3 kuud) ja iga redaktsioon peab olema jaotatud iteratsioonideks (2 nädalat). Vähemalt iga 4 nädala tagant peavad toimuma tarkvara arenduse demonstratsioonid, mille käigus tellija saab esitada omapoolsed ettepanekud, mis on täitjale siduvad.

Täitja koostab ja kirjeldab testlood ning kooskõlastab need tellijaga. Testlood peavad katma kogu täiendatavat funktsionaalsust ning näitama, et tehtud arendus pole rikkunud ülejäänud süsteemi. Testlood peavad sisaldama infot teostatava protseduuri või täpse tegevuse kirjelduse kohta ning vastavat oodatavat tulemust. Üheselt peab olema aru saada, mida tehakse ning mis on selle tegevuse tagajärg. Testlood peavad olema korratavad tellijale ilma täitja abita. Arendustegevused peavad hõlmama endas ka täitja poolset testimist.

4

Arendustöö tulemusena sünnib ka koodist genereeritav dokumentatsioon. See dokumentatsioon on alus ka tuleviku-integratsioonideks.

Arendustööde UI ja UX lahendused peavad järgima olemasoleva KILP disainisüsteemi põhimõtteid.

Uue funktsionaalsuse loomine võib kaasa tuua vana koodi muutmist ning ei tohi luua uut tehnoloogilist

võlga. Jooksvalt peab olema tagatud kogu infosüsteemi tehnilise võla vähendamine (sõltuvuste

uuendamine, haavatavuste parandamine, koodikvaliteedi hoidmine). Kood tuleb katta automaattestidega

vastavalt SMIT-i nõuetele. Logimine (auditlogi, X-tee logi, tehniline logi jms) toimub vastavalt SMIT-i

logimise nõuetele. Tarkvara kvaliteet vastab SMIT eeskirjadele. Mittefunktsionaalsed nõuded vastavad

SMIT eeskirjadele.

Tehniline info Teostatavad arendustegevused ei tohi tellijale kaasa tuua täiendavate tasuliste tehnoloogiate

kasutuselevõttu. Olemasolev arendusraamistik on Spring Boot/ Java/ Hibernate ning ReactJS/ Redux/

Redux-Saga/ JavaScript/ Typescript. Klient- ja serverteenused kasutavad omavaheliseks andmevahetuseks

REST API teenuseid, serverteenused lisaks RabbitMQ. Teiste andmekogudega andmevahetus toimub üle X-

tee (REST/SOAP), lisaks on muude andmeallikatega liidestuste puhul kasutusel REST ja WMS. Kasutusel on

PostgreSQL andmebaasid. Rakenduse autentimine ja autoriseerimine toimub praegu UAA (SMIT)

mooduliga. Logimine (auditlogi, X-tee logi, tehniline logi jms) toimub vastavalt SMIT-i logimise nõuetele.

Hankelepingu tulemid ja vastuvõtmine Hankelepingu tulemite vastuvõtmine toimub faaside lõpus tulemi saavutamisel.

KILP Arendusjuhend

Arenduses kasutatav tarkvara* • Java 17 JDK • Spring Boot 2.7.7 • PostgreSQL 13 + PostGIS • Hibernate 5.6 • Spring Framework 5.3 • React 17

o GUI (Javascript) • React 18

o tactical-ui (Typescript) o aviation-dashboard(Typescript)

• Lombok 1.18 • H2 integratsioonitestides 1.4 • Caffeine Cache 2.9 • Junit 5 • Mockito 4.5 • REST Assured 2.9 • Liquibase 4.9.0

*See info siin võib mingitel hetkedel olla mitte-ajakohane

Rakenduse arhitektuur • Rakenduste kood töötab serveris Java virtuaalmasinal, mille versioon on vähemalt 17.0 • Rakenduse konfigureerimisparameetrid on muudetavad väljaspool rakendust • Rakendus toimib edasi võrgukatkestuse puhul • Ühenduvust väliste liidestega saab kontrollida JMX vahenditega

Rakendus koosneb eraldiseisvatest valdkonnapõhistest moodulitest, mis on paigaldatavad iseseisvalt kas spring-boot rakendusena Maven-i pluginaga või Tomcati war- na. Rakenduse arendamisel järgitakse microteenuste arhitektuuri, mis võimaldab erinevatel meeskondadel rakendusi üksteisest sõltumatult arendada ja paigaldada. Andmebaas on arendusfaasis kõikidele üks, asudes keskses serveris, millele on kõikidel arendajatel üle JDBC ligipääs. Arendajal on võimalik ka arendusmasina-lokaalset andmebaasi kasutada (H2 või PostgreSQL). Loodav lähtekood asub Git-is.

Rakenduse struktuur Rakendus koosneb eraldiseisvatest moodulitest, mis suhtlevad omavahel üle REST-i. Mooduliteks jaotus on tehtud vastavalt valdkondadele ning moodulisisene struktuur on kirjeldatud järgnevalt:

Olemasolevad tehnilised lahendused ja joonised võivad kuuluda arenduse ja/või analüüsi käigus muutmisele. Kõik sisseviidavad muudatused peavad olema eelnevalt Tellijaga kooskõlastatud.

projektA src main resources java ee.smit.kilp.{rakenduse nimi}.{mooduli nimi} boot tests controllers services persistence test resources java boot - spring-boot rakenduse käivitamiseks vajalik kood ja spring configuration klassid tests - integratsioonitestid kogu rakenduse testimiseks controllers - rest-i kontrollerid services - teenused, mida kontrollerite kaudu välja kutsutakse persistence - andmebaasiga suhtluseks vajalikud komponendid

Rakenduse konfiguratsiooniparameetrid Rakenduse konfiguratsioon asub failis application.yml ning loetakse sisse rakenduse ülestulekul. Konfiguratsioon asub väljaspool rakendust ning parameetrid on muudetavad ilma rakendust restartimata, kasutades selleks spring-cloud-i funktsionaalsust.

Moodulitevaheline suhtlus KILP omavaheliste moodulite suhtlus toimub üle:

• REST • SSE • RabbitMQ

Kõik moodulid, mis omavad REST liidest, väljastavad ka mooduli urli alt enda REST-i liidese spetsifikatsiooni, mida saab liidestuva mooduli arendaja kasutada liidestuse loomiseks.

Suhtlus KILP väliste süsteemidega KILP väliste teiste andmekogude ja süsteemidega suheldakse kasutades:

• SOAP üle XTEE

• REST üle XTEE • REST

Suhtlus andmebaasiga Andmebaasiga suhtlusel kasutatakse jdbc datasource, mis on poolitavad. CRUD operatsioonide puhul kasutatakse Spring Data repository-sid, mis injectitakse vastavasse teenusklassi. Andmebaasi mudeli klassid luuakse andmebaasi pealt Hibernatetoolsi kasutades. Teenusloogika andmebaasi ei kirjutata ning loodav SQL funktsionaalsus püütakse hoida maksimaalselt andmebaasist sõltumatuna, sest see võimaldaks testimist käivitada H2 andmebaasi kasutades.

Puhverdamine Puhverdamiseks kasutatakse Caffeine Cache'i.

Transaktsionaalsus Transaktsionaalsust rakendatakse annotatsioonipõhiselt teenuskihis.

Logimine Rakenduses kasutatakse slf4j API-t ning logbacki implementatsiooni. Loggeri lisamiseks klassile kasutatakse @slf4j annotatsiooni projektist Lombok. Logifail kirjutatakse failisüsteemi maha ning on masintöödeldav. Iga päringu kohta tehakse vastavasisuline audit logi kirje.

Kasutajaliides Kasutajaliides realiseeritakse eraldi javascripti/typescripti rakendusena, mis suhtleb serveris asuva teenuskihiga üle REST-i.

Testimine Rakenduse testimiseks kasutatakse nii integratiooniteste kui ka unitteste. Integratsioonitestide jaoks luuakse moodulis alammoodul, kus asub testi käivitamiseks vajalik konfiguratsioon ning andmete eeltäitmine. Unittestid asuvad testitava koodiga samas moodulis.

Rakenduse monitoorimine Monitoorimine toimub JMX-i vahenditega.

Rakenduse dokumentatsioon Koodi kirjutamisel rakendatakse Robert C. Martin raamatus “Clean Code” kirjeldatud metodoloogiat ehk koodi kirjutatakse maksimaalselt isedokumenteeruvana. Vajadusel lisatakse kommentaarid JavaDoc-ina.

Koodi kvaliteet Koodi kvaliteedi formaalseks hindamiseks kasutatakse Sonar-it:

• Sonar-i hoiatused • Automaattestidega kaetuse protsent (>=80%)

Mitteformaalne kvaliteet: • Pull-requestide peer review'd. • Koodi loetavus, lihtsus ja mõistetavus. • Andmete töötluse kiirus ja optimaalsus.

KILP skeemid

1 / 3

Koostatud 16.12.2025 14:33:48 https://riigihanked.riik.ee/rhr-web/#/procurement/9675984/general-info

VASTAVUSTINGIMUSED Viitenumber: 303850 Hankija: Siseministeeriumi infotehnoloogia- ja arenduskeskus (70008440) Hange: KILP isikukaitse, objektivalve ja suursündmuste juhtimine

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. Kinnitame, et käesolev pakkumus on jõus 3 kuud ja on esitatud tingimustel pakkujale siduv, alates pakkumuste esitamise tähtpäevast. (Raadionupp valikutega "Jah/Ei")

2. Andmed lepingusse, mida kasutatakse juhul, kui pakkumus tunnistatakse edukaks. Pakkuja esitab andmetena: 1. ettevõtte Nimi, reg.kood, aadress; 2. lepingu allkirjastaja nimi; 3. alus lepingu allkirjastamiseks (juhatuse liige, volikiri vm); 4. lepingu allkirjastaja ametinimetus; 5. pakkuja kontaktisik lepingu täitmisel (nimi, ametinimetus, telefoni number ja e-posti aadress); ettevõtja arveldusarve number. (Suur sisestusala (max pikkus 4000 tähemärki))

3. Kas pakkujal on isikuid, kellel on volitus ettevõtjat esindada, tema nimel otsuseid teha või teda kontrollida, ning kelle olemasolu ei kajastu äriregistris? Kui jah, esitab pakkuja eelpool nimetatud isikute ees- ja perekonnanime, isikukoodi ning esinduse aluse, et hankija saaks nende puhul viia läbi kõrvaldamise aluste kontrolli vastavalt RHS § 95 lg 1 p 1- 3 ja 5. (Suur sisestusala (max pikkus 4000 tähemärki))

4. Pakkuja kinnitab, et hankelepingu sõlmimine temaga ei riku rahvusvahelist sanktsiooni rahvusvahelise sanktsiooni seaduse (RSanS ) tähenduses. (Raadionupp valikutega "Jah/Ei")

5. Pakkuja kinnitab, et esitab hankelepingu täitmise alustamise ajaks iga oma alltöövõtja nime, registrikoodi, kontaktandmed, teabe nende seaduslike esindajate kohta ning alltöövõtulepingu nimetuse, kuupäeva, numbri ja summa. Samad andmed esitab täitja iga hankelepingu täitmisel lisanduva alltöövõtja kohta. (Raadionupp valikutega "Jah/Ei")

NÕUDED HANKELEPINGU TÄITMISESSE KAASATUD MEESKONNALIIKMETELE

Pakkuja esitab hankelepingu täitmiseks kolme (3) full-stack vanemarendaja CVd, kahe (2) süsteemianalüütiku CVd ja ühe (1) testija CV, kes vastavad rollile kehtestatud vastavustingimustele (toodud vastavas CVs).

Hankija juhib tähelepanu, et vastavalt hankelepingu punktile 2.6. võib pakkuja kaasata hankelepingu täitmisesse lisa meeskonnaliikmeid, kes ei pea vastama minikonkursis vastavale spetsialistile hankija poolt kehtestatud nõuetele. Nimetatud isikute CVsid ei pea pakkumusega koos esitama ning need saab esitada hankija nõudmisel lepingu täitmise käigus.

Pakkuja esitab meeskonnaliikmete andmed, täites iga nõutud meeskonnaliikme kohta etteantud CV vormi (PEE lisa 3.1.- 3.3.). Esitatud andmed peavad võimaldama hankijal kontrollida meeskonnaliikmete vastavust esitatud nõuetele ja hankija kontrollib tingimuste täitmist eelkõige CVs esitatud andmete alusel.

1. Kui tingimuses on nõutud (kõrg)haridus, peab see olema lõpetatud. 2. Kui tingimuses ei ole nõutud töökogemust projektis, võib viidata ka töösuhtele. Projektiks ei loeta (varasemat) töösuhet. 3. Töökogemuse nõude täitmisena ei arvestata vabakutselisena tegutsemist, v.a kui selle perioodi osas on viidatud konkreetsetele projektidele, millel on tellijaks kolmas isik. 4. Töökogemuse nõude täitmisena ei arvestata täiendkoolitust või koolitööd. 5. Kui tingimuses on nõutud konkreetse kestusega töökogemust, siis (ka osaliselt) samaaegsete projektide kattuvaid aegu mitmekordselt ei arvestata. St sama ajaperioodi eest ei ole võimalik omandada mitmekordset kogemust.

2 / 3

Koostatud 16.12.2025 14:33:48 https://riigihanked.riik.ee/rhr-web/#/procurement/9675984/general-info

6. Projektide andmete esitamisel tuleb iga projekti kohta esitada vähemalt: projekti nimi ja lühikirjeldus, projekti algus- ja lõppaeg kalendrikuu täpsusega, projekti tellinud asutus ja tellija kontaktisik ning riigihanke korral märkida riigihanke number. 7. Viidatud projektid peavad olema pakkumuse esitamise ajaks nõutud mahus/ kompetentsi osas täidetud ja tellija poolt vastu võetud. 8. Projekti tellija peab olema kolmas isik, st projekti tellijaks ei saa olla (ühis)pakkuja ise või pakkumusse hõlmatud alltöövõtja või (varasemas) töösuhtes tööandjale endale teostatud töö. Selliseid projekte on lubatud esitada üldise töökogemuse nõude täitmiseks või näitlikustamiseks. 9. Hankijal on õigus pöörduda tellija poole esitatud andmete kontrollimiseks. 10. Kui mõne nõutud kompetentsi/kogemuse osas on andmed esitamata või viitab nende andmete mitteesitamise põhjenduseks konfidentsiaalsusele ja/või nende alusel ei ole võimalik järeldada, kas nõue on täidetud, on hankijal õigus tunnistada pakkumus mittevastavaks. Hankija ei avalda pakkumuses esitatud andmeid. 11. Juhul, kui lepingu täitmise käigus meeskonnas liikmeid asendatakse või täiendatakse, siis peab isik nõutud tingimustele vastama sellise taotluse esitamise ajaks. 12. Kui see on objektiivselt võimalik, tuleb lugeda tingimusi täiendatuks märkega "või samaväärne". Samaväärsuse tõendamise kohustus lasub pakkujal, kes sellele tugineda soovib. Tõendid samaväärsuse kohta peavad olema esitatud pakkumuse koosseisus. 13. Tellijal on õigus CV-s esitatud informatsiooni kontrollida ja täpsustada, kuid juhul, kui mõnd nõutud kogemust ei ole CV-s esitatud, lähtub hankija seisukohast, et pakkuja on vastava kogemuse kohta esitanud ammendavad andmed, st vastav kogemus meeskonnaliikmel puudub. 14. Hankija ei küsi pakkujalt selgitusi väärtuspunktide saamiseks esitatud andmete kohta. Kui pakkuja on esitanud andmeid, millest ei saa kogemuse olemasolu üheselt järeldada, punkte ei anta.

Küsimused ettevõtjale: 1. Lisa 3.1. Full-stack vanemarendaja 1 CV vorm (Vabas vormis dokument)

2. Lisa 3.1. Full-stack vanemarendaja 2 CV vorm (Vabas vormis dokument)

3. Lisa 3.1. Full-stack vanemarendaja 3 CV vorm (Vabas vormis dokument)

4. Lisa 3.2. Süsteemianalüütiku 1 CV vorm (Vabas vormis dokument)

5. Lisa 3.2. Süsteemianalüütiku 2 CV vorm (Vabas vormis dokument)

6. Lisa 3.3. Testija CV vorm (Vabas vormis dokument)

ÜHISPAKKUJATE VOLIKIRI Ühispakkujad nimetavad riigihankega ning hankelepingu sõlmimise ja täitmisega seotud toimingute tegemiseks endi seast volitatud esindaja.

Küsimused ettevõtjale: 1. Kas tegemist on ühispakkumusega? (Raadionupp valikutega "Jah/Ei")

2. Lisa 3.4. Ühispakkujate volikirja vorm (kui ei ole ühispakkumus, lisa tühi dokument) (Vabas vormis dokument)

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

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

3 / 3

Koostatud 16.12.2025 14:33:48 https://riigihanked.riik.ee/rhr-web/#/procurement/9675984/general-info

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

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

EL NÕUKOGU SANKTSIOON. ALLTÖÖVÕTJAD JA TARNIJAD. Pakkuja kinnitab, et ta ei kaasa üle 10% hankelepingu maksumusest hankelepingu täitmisele alltöövõtjaid ega tarnijaid, kes on: 1. Vene Föderatsiooni kodanik, resident või Vene Föderatsioonis asutatud ettevõtja, sh füüsilisest isikust ettevõtja, juriidiline isik, asutus või muu üksus; 2. rohkem kui 50% ulatuses otseselt või kaudselt punktis 1 nimetatud isiku, asutuse või muu üksuse omandis; 3. punktis 1 või 2 nimetatud isiku, asutuse või muu üksuse esindaja või tegutseb sellise isiku 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")

Koostatud 16.12.2025 14:23:10 1 / 1 https://riigihanked.riik.ee/rhr-web/#/procurement/ 9675984/general-info

HINDAMISKRITEERIUMID JA HINNATAVAD NÄITAJAD

Viitenumber: 303850 Hankija: Siseministeeriumi infotehnoloogia- ja arenduskeskus (70008440) Hange: KILP isikukaitse, objektivalve ja suursündmuste juhtimine

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 Pakkumuse kogumaksumus Pakkumuse kogumaksumus peab sisaldama kõiki tulemi saavutamiseks vajalikke kulusid.

Maksumus - vähim on parim

100

Faas I maksumus PEE lisa 2. Tehniline kirjeldus toodud "Faas I – Objektivalve moodul" maksumus

jah

Faas II maksumus PEE lisa 2. Tehniline kirjeldus toodud "Faas II – Isikukaitse planeerimise moodul" maksumus

jah

Faas III maksumus PEE lisa 2. Tehniline kirjeldus toodud "Faas III – Isikukaitse haldamine/ juhtimine" maksumus

jah

Faas IV maksumus PEE lisa 2. Tehniline kirjeldus toodud "Faas IV – Suursündmuste planeerimise moodul" maksumus

jah

Faas V maksumus PEE lisa 2. Tehniline kirjeldus toodud "Faas V – Suursündmuste juhtimise moodul" maksumus

jah

Kokku: 100

Hindamismetoodika kirjeldus 1.   Pakkumuse 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".

1 / 2

Koostatud 09.12.2025 12:34:00 https://riigihanked.riik.ee/rhr-web/#/procurement/9675984/general-info

KÕRVALDAMISE ALUSED JA KVALIFITSEERIMISTINGIMUSED Viitenumber: 303850 Hankija: Siseministeeriumi infotehnoloogia- ja arenduskeskus (70008440) Hange: KILP isikukaitse, objektivalve ja suursündmuste juhtimine

KÕRVALDAMISE ALUSED

KÕRVALDAMISE ALUSED

Hankija kontrollib edukal pakkujal vastavalt RHS § 30 toodule RHS § 95 lg 1 ja 4 kõrvaldamise aluseid enne lepingu sõlmimist. RHS § 95 lg 1 nimetatud kõrvaldamise aluste kontroll toimub riigihangete registri liidese ja EU Sanctions Map abil. Kui andmed ei ole hankijale päringute kaudu kättesaadavad, siis nõuab hankija edukalt pakkujalt enne hankelepingu sõlmimist kõikide asjakohaste andmete või dokumentide esitamist.

Kehtib: Kõik osad

Küsimused ettevõtjale: 1) Kinnitame, et meil puuduvad riigihangete seaduse § 95 lõikes 1 kirjeldatud kõrvaldamise alused ning saame aru, et kõrvaldamise aluse esinemisel kõrvaldatakse meid minikonkursilt riigihangete seaduse §-s 95 sätestatud korras. (Raadionupp valikutega "Jah/Ei") 2) Kinnitame, et meil puuduvad riigihangete seaduse § 95 lõikes 4 kirjeldatud kõrvaldamise alused ning saame aru, et kõrvaldamise aluse esinemisel kõrvaldatakse meid minikonkursilt riigihangete seaduse §-s 95 sätestatud korras. (Raadionupp valikutega "Jah/Ei")

KVALIFITSEERIMISTINGIMUSED

C: Tehniline ja kutsealane suutlikkus

REFERENTSLEPINGUD

Pakkuja peab olema täitnud nõuetekohaselt vähemalt 2 lepingut, millest iga lepingu raames on pakkuja: 1) teostanud infosüsteemi arendust ja 2) täitnud lepingu rahalise mahuga 75 000 eurot km-ta.

Hankija arvestab lepinguid, mis on täidetud minikonkursi algusele eelneva 36 kuu jooksul.

Pakkuja esitab lepingute nimekirja koos järgmiste andmetega: - lepingu nimi, - sõlmimise ja täitmise kuupäev, - referentsperioodil pakkujale lepingu alusel välja makstud summa, - lepingu lühikirjeldus, - teise lepingupoole andmed (tellija ja tema kontaktisiku nimi, e-posti aadress, telefon), Riigihanke korral lisatakse viitenumber. Pärast pakkumuste esitamise tähtpäeva ei ole lubatud lepingute nimekirja täiendada. Referentslepinguks ei saa esitada raamlepinguid, küll aga sobib kvalifikatsiooni tõendamiseks raamlepingu alusel sõlmitud (hanke)leping, kui see vastab nõutud tingimustele. Hankija võib esitatud andmeid kontrollida teise lepingupoole kaudu.

Kehtib: Kõik osad

2 / 2

Koostatud 09.12.2025 12:34:00 https://riigihanked.riik.ee/rhr-web/#/procurement/9675984/general-info

Küsimused ettevõtjale: 1) Pakkuja esitab nõutud teabe tingimusele vastavate lepingute kohta. (Suur sisestusala (max pikkus 4000 tähemärki))

Siseministeeriumi infotehnoloogia- ja arenduskeskus

Mäealuse 2/2, Tallinn 12618

Telefon 612 6200

E-post [email protected]

Reg. kood 70008440

www.smit.ee

23.01.2026 nr 3-17/18

Pakkumuse esitamise ettepanek minikonkursil "KILP isikukaitse, objektivalve ja

suursündmuste juhtimine" (303850) raamlepingu nr 3-3/3404 alusel

Siseministeeriumi infotehnoloogia- ja arenduskeskus (edaspidi SMIT või hankija) soovib

riigihanke „Politsei taktikalise juhtimise andmekogu (KILP) infosüsteemi arendus, analüüs,

testimine ja disainimine“ (265036) tulemusel sõlmitud raamlepingu alusel sõlmida

hankelepingu raamlepingu partneriga ja teeb ettepaneku pakkumuse esitamiseks minikonkursi

dokumentides toodud tingimustel.

1. Üldteave

1.1. Raamleping: reg nr 3-3/3404;

1.2. Hanke eest vastutav isik: Lagle Sokmann, [email protected]

1.3. Hanke liik: minikonkurss raamlepingu alusel, minikonkursi viitenumber 303850.

1.4. Eeldatav maksumus: 994 560.00 eurot km-ta.

1.5. CPV kood: 72200000-7 Tarkvara programmeerimis- ja nõustamisteenused.

1.6. Menetluse teostamise viis: e-menetlus eRHR vahendusel.

1.7. Hankelepingu kestus: lepinguliste kohuste täitumiseni/kuud (sh ka arve maksmise aeg)

1.8. Finantseerimisallikas: riigieelarve.

1.9. Pakkumuse esitamise tähtaeg: Pakkumuse esitamise täpne kuupäev ja kellaaeg

sätestatakse hankemenetluse eest vastutava isiku poolt eRHR-s. Pakkujal on õigus

vajadusel teha ettepanek pakkumuse esitamise tähtaja pikendamiseks.

1.10. Pakkumuse jõusoleku tähtaeg: vähemalt 3 kuud alates pakkumuse esitamise tähtpäevast.

1.11. Hankija ootus huvitatud isikutele on, et pakkujad teavitaks hankijat aegsasti RHR kaudu

riigihanke alusdokumentides avastatud vigade, ebatäpsuste ja ebaselguste parandamiseks.

1.12. RHR üldandmetes lahtris "Hankelepingu eeldatav kestus" määratud tähtaeg tähendab

lepingu kehtivust, mitte üksnes täitja kohustuste täitmise tähtaega ning lähtub seetõttu nii

täitja kui hankija/maksja kohustuste nõuetekohase täitmise tähtaegadest, sh hõlmatud on

ka hankija arve tasumiseks kuluv aeg. Pakkujal tuleb lepingu sõlmimise korral lähtuda

enda kohustuste tähtaegsel täitmisel lepingus või tehnilises kirjelduses määratud

täitmise/lepingu eseme tarnimise tähtajast.

1.13. Täitja esitab hankelepingu täitmise alustamise ajaks iga oma alltöövõtja nime,

registrikoodi, kontaktandmed, teabe nende seaduslike esindajate kohta ning

2(4)

alltöövõtulepingu nimetuse, kuupäeva, numbri ja summa. Samad andmed esitab täitja iga

hankelepingu täitmisel lisanduva alltöövõtja kohta.

2. Minikonkursi dokumendid

2.1. Minikonkursi dokumendid koosnevad käesolevast dokumendist ning järgmistest lisadest:

2.1.1. Lisa 1 - Hankelepingu projekt;

2.1.2. Lisa 2 – Tehniline kirjeldus;

2.1.3. Lisa 2.1 - KILP Arendusjuhend;

2.1.4. Lisa 3 – Vastavustingimused (eRHR vorm);

2.1.5. Lisa 3.1 – Full-stack vanemarendaja CV vorm;

2.1.6. Lisa 3.2 – Süsteemianalüütiku CV vorm;

2.1.7. Lisa 3.3 – Testija CV vorm;

2.1.8. Lisa 3.4 – Ühispakkujate volikirja vorm;

2.1.9. Lisa 4 - Hindamiskriteeriumid ja hinnatavad näitajad (eRHR vorm);

2.1.10. Lisa 5 - Kõrvaldamise alused ja kvalifitseerimistingimused (eRHR vorm).

3. Olelusringi kulude arvestamine

Tegemist on hankijal juba olemas ja kasutuses oleva infosüsteemi arendustöödega.

Lepingu täitmise tulemusel ei teki uut iseseisvat infosüsteemi terviklahendust, mille

käitamine eeldaks märkimisväärsete täiendavate kulutuste tekkimist nt riistvarale või

erinevatele kaudsetele kuludele vmt ning mida saaks arvesse võtta ja lahendada käesoleva

minikonkursi raames. Infosüsteemi käitamisega seotud kulutuste määr on praktikas

üldjoontes välja kujunenud (lähtuvalt sihtotstarbest, kasutusintensiivsusest jpm) ning

tulenevalt hankija asutuse struktuurist ja eelarvestamise süsteemist on infosüsteemide

ülalpidamiskulude katmine lahendatud erinevate kombineeritavate tark- ja riistvaraliste

lahendustega, mida hangitakse teiste hangete kaudu. Lisaks on planeeritud katta suur osa

võimalikest tekkivatest olelusringikuludest hankija oma ressursiga.

4. Minikonkursil osalemise tingimused

4.1. Minikonkursi dokumendid moodustavad ühtse terviku. Dokumendid tehakse täitjatele

tasuta kättesaadavaks eRHR-i keskkonna vahendusel.

4.2. Minikonkursi dokumentide sisu kohta saab hankijalt selgitusi küsida kirjalikul

pöördumisel läbi eRHR-i keskkonna teabevahetuse töölehe. Hankija vastab esitatud

küsimustele esimesel võimalusel, võttes arvesse RHS § 46 lg 1 ja konkreetse

minikonkursi pakkumuste esitamise tähtaega.

5. Pakkumuse vormistamine, esitamine ja muutmine

5.1. Pakkumus tuleb esitada elektrooniliselt eRHR-i kaudu aadressil

https://riigihanked.riik.ee.

5.2. Dokumendid vormistada PDF-vormingus või mõnes muus üldlevinud vormingus.

5.3. Kui esitatavate dokumentide koosseisus on kolmanda osapoole poolt kirjalikult

allkirjastatud dokumente, esitada dokument skaneeritud kujul ning originaaldokument

esitada ainult juhul, kui hankijal on tekkinud kahtlus dokumendi osas.

3(4)

5.4. Samaväärsuse pakkumisel peab pakutav lahendus ühtima hankija olemasolevate

süsteemidega ning toote ja/või teenuse hind peab sisaldama kõiki migreerimisega seotud

lisatasusid. Pakkumus peab vastama esitatud nõuetele või olema sellega vähemalt

samaväärne, kuid ühilduma olemasoleva lahendusega. Samaväärsust tõendavad andmed

ja dokumendid esitab pakkuja koos pakkumusega. Pakkumuse samaväärsust kontrollivad

ja hindavad hankija vastavate erialateadmistega töötajad.

5.5. Iga viidet, mille hankija teeb minikonkursi alusdokumentides mõnele RHS-i § 88 lõikes

2 nimetatud alusele (standardile, tehnilisele tunnustusele, tehnilisele kontrollisüsteemile,

märgisele vms), tuleb lugeda selliselt, et see on täiendatud märkega „või sellega

samaväärne“. Iga viidet, mille hankija teeb minikonkursi alusdokumentides ostuallikale,

protsessile, kaubamärgile, patendile, tüübile, päritolule, märgisele või tootmisviisile,

tuleb lugeda selliselt, et see on täiendatud märkega „või sellega samaväärne“.

Samaväärsus tähendab täpselt samu kasutusomadusi ja funktsionaalsusi. Samaväärse

lahenduse korral tuleb pakkujal pakkumuses esitada seda tõendavad dokumendid.

6. Pakkumuste vastavuse kontrollimine

6.1. Pakkumus tunnistatakse vastavaks, kui see vastab kõikidele minikonkursi tingimustele

ning selles ei esine sisulisi kõrvalekaldumisi esitatud tingimustest.

6.2. Pakkumuses esitatud andmed peavad olema tõesed, esitatud viisil ja piisava detailsusega,

mis võimaldavad hankijal kontrollida nende vastavust riigihanke alusdokumentides

toodud tingimustele.

6.3. Hankija nõudel peab täitja pakkumuses esitatud teavet selgitama, piiritlema või

täpsustama.

6.4. Hankijal on õigus lükata pakkumus tagasi, kui see ei vasta minikonkursis esitatud

tingimustele ning juhul, kui täitja on esitanud lisatingimusi, mis ei ole kooskõlas

minikonkursi tingimustega.

6.5. Hankija lükkab pakkumuse tagasi, kui hankelepingu sõlmimine selle pakkumuse alusel

rikuks rahvusvahelist sanktsiooni rahvusvahelise sanktsiooni seaduse tähenduses

(RSansS).

6.6. Hankija võib pakkumusi hinnata enne pakkumuste vastavuse või pakkujate suhtes

kõrvaldamise aluste puudumise kontrollimist. Sellisel juhul kontrollib hankija

pakkumuse vastavust ja kõrvaldamise aluste puudumist vaid edukal pakkujal. Kui eduka

pakkuja pakkumus osutub kontrollimise tulemusena mittevastavaks või pakkuja

kõrvaldatakse menetlusest, on hankijal õigus tunnistada edukaks hindamise tulemusena

paremusjärjestuses järgmine pakkuja ning teostada kirjeldatud kontrollid tema osas.

7. Pakkumuste hindamine, edukaks tunnistamine või tagasi lükkamine

7.1. Hankijal on õigus pakkumus tagasi lükata ja otsustada hankelepingut mitte sõlmida või

vastavalt raamlepingule minikonkurss kehtetuks tunnistada, kui:

7.1.1. pakkumus(ed) ei vasta tingimustele;

7.1.2. pakkumus(ed) ületavad eeldatavat maksumust;

7.1.3. hankija/maksja ei saa projektile rahastust.

7.2. Tellijal on õigus enne hankelepingu sõlmimist tunnistada minikonkurss omal algatusel

põhjendatud vajadusel kehtetuks, teavitades sellest täitjaid.

4(4)

7.3. Minikonkursil on raamlepingu p 2.15.2 kohaselt hindamiskriteeriumiks tulemi

kogumaksumus. Tulemi kogumaksumus peab sisaldama kõiki tulemi saavutamiseks

vajalikke kulusid (sh erinevate rollide töötunde). Madalaima kogumaksumuse pakkujale

antakse 100 väärtuspunkti. Järgnevad pakkumused saavad punkte proportsionaalselt

vähem. Edukaks tunnistatakse üks pakkumus, mis vastab esitatud tingimustele, on

madalaima hinnaga ja selle maksumus ei ületa hankija rahalisi võimalusi.

8. Kõrvaldamise aluste kontrollimine, eduka pakkuja äralangemine

8.1. Hankija kontrollib enne hankelepingu sõlmimist edukal pakkujal RHS § 95 lõikes 1 ja 4

nimetatud kõrvaldamise aluseid sama paragrahvi lõigetes 2, 3, 5 ja 6 sätestatud

tingimustel, ega sõlmi hankelepingut pakkujaga, kellel mõni kõrvaldamise alus esineb.

8.2. Hankija kontrollib RHS § 30 lõike 10 ja raamlepingu punkti 2.14. alusel eduka pakkuja

kvalifikatsiooni vastavust raamlepingus ja minikonkursi alusdokumentides toodud

tingimustele ja kvalifitseerib pakkuja, kui ta täidab kvalifitseerimistingimused. Pakkuja

jäetakse kvalifitseerimata, kui ta ei täida minikonkursi kvalifitseerimistingimusi.

8.3. Minikonkursil kohaldatakse heastamist. Pakkuja esitab vajadusel kohased ja põhjendatud

heastamismeetmed kooskõlas RHS § 97.

8.4. Kui edukas pakkuja kõrvaldatakse minikonkursilt või jäetakse kvalifitseerimata, või

minikonkursil edukas pakkuja võtab hankijast mitteolenevatel põhjustel oma pakkumuse

tagasi või ei allkirjasta hankelepingut, mida käsitletakse kui pakkumuse tagasi võtmist

RHS § 119 tähenduses, hindab hankija kõiki ülejäänud minikonkursi pakkumusi uuesti ja

tunnistab soodsaimaks pakkumuse, mis on pakkumustest majanduslikult soodsaim.

Hankija ei ole kohustatud pakkumusi uuesti hindama ja võib tunnistada soodsaimaks

esialgsel hindamisel edukuselt järgmiseks osutunud pakkumuse juhul, kui soodsaimaks

tunnistatud pakkumuse äralangemine ei saa mõjutada ülejäänud pakkumuste omavahelist

järjestust.

Lugupidamisega

(allkirjastatud digitaalselt)

Mait Vaiksaar

peadirektori asetäitja baasteenuste valdkonnas

peadirektori ülesannetes

Lisa: Loetletud punktis 2.