Väljaminev kiri

Lisa. HANKELEPINGU projekt

Siseministeeriumi infotehnoloogia- ja arenduskeskus (SMIT või Tellija), registrikood 70008440, aadress Mäealuse 2/2, 12618, Tallinn, keda esindab põhimääruse alusel

peadirektor Mart Nielsen

Äriühing OÜ/AS (Täitja), registrikood ………….., aadress, keda esindab …….

1. Üldandmed

1.1 Käesolev hankeleping on sõlmitud 16.07.2024. a sõlmitud raamleping nr 3-3/3527 (riigihanke viitenumber 275561) alusdokumendid, tellija … tellimus (282491) ja

täitja … pakkumuse alusel. 1.2 Rahastamisallikaks on riigieelarve. 1.3 Poolte kontaktisikud hankelepingu täitmisel on:

1.3.1 Tellijal: Martti Rosenblatt, tel. 5301 7536, e-post: [email protected] või tema asendaja;

1.3.2 Täitjal: ……....., tel. ………., e-post: ………….;

2. Lepingu eseme täitmine

2.1 Hankelepinguga ostab tellija: 2.1.1 C#/WPF+TETRA vanemarendaja teenust 3 328 tundi;

2.2 Hankelepingu täitmise periood on 24 kuud alates töödega alustamisest. 2.3 Töid teostatakse ühtlase töövoona: tellijal on kohustus tagada ühtlane töövoog ja

täitjal sellekohane täitmine. Täitja tagab lepingu täitmise esmaspäevast neljapäevani 8

tundi päevas SMIT-i tavapärasel tööajal, välja arvatud rollitäitja puhkuse või haigestumise ajal, riiklikel pühadel ja tööpäevadel, mis on seaduse järgi lühendatud

tööpäevad. Lühendatud tööpäeval on täitja kohustatud tagama teenuse osutamise lühendatud tööpäeva ulatuses.

2.4 Töid teostab hankelepingu lisas toodud CV-s nimetatud isik.

2.5 Töid teostatakse tellija asukohas ühel (1) või kahel (2) päeval nädalas, tavapäraselt ajavahemikul esmaspäevast neljapäevani kell 8:30-17:00 ja muul ajal täitja asukohas.

Tellija nõudmisel kohustub täitja teostama kõiki töid tellija asukohas, sellisel juhul teostatakse töid tavapäraselt ajavahemikul esmaspäevast neljapäevani kell 8:30-17:00. Kui tööprotsessid sujuvad ja projektis ei esine raskusi, võib eraldi kokku leppida, et

töid teostatakse kaugtööna. Sellisel juhul peab täitja osalema kas isiklikult või SMIT meeskonna poolt määratud suhtlustarkvara kaudu ( MS Teams vms) kõikidel tellija

poolt teavitatud meeskonna koosolekutel (nt. pikemad koosolekud reeglina 1-2 korda nädalas ja igahommikustel lühiaruteludel/Standupidel) sh igapäevases suhtluses kasutama SMIT meeskonna poolt määratud suhtlustarkvara (Rocket.chat, MS Teams

vms). 2.6 Tellijal on õigus igal ajal hankeleping üles öelda, esitades täitjale sellekohase kirjaliku

taasesitamist võimaldavas vormis teatise vähemalt 30 päeva ette. 2.7 Hankelepingus kokku leppimata küsimustes lähtutakse raamlepingus ja SMIT

käsunduslepingu üldtingimustes sätestatust, vastuolude korral lähtutakse esmalt

hankelepingus sätestatust, siis raamlepingus sätestatust ning viimaks SMIT käsunduslepingu üldtingimustes sätestatust.

2.8 Teenuse osutamise käigus valminud tulemitele ei kohaldata raamlepingus sätestatud garantiid.

3. Hankelepingu maksumus ja arveldamise kord

3.1 Hankelepingu kogumaksumus on … eurot, millele lisandub käibemaks. 3.2 Lepingu täitmine toimub töötunnipõhisel arvestusel, tellija tasub üksnes lepingu alusel

tellitud ja teostatud töötundide eest.

3.3 Töid teostava C#/WPF+TETRA vanemarendaja ühe (1) töötunni maksumus on ….

3.4 Peale üleandmis-vastuvõtmisakti allkirjastamist, esitab täitja tellijale lepingukohase arve.3.5 Kui meeskonnaliikme asendamine toimub pärast lepingu sõlmimist ja

raamlepingu peatüki 5 alusel läbiviidud taustakontrolli teostamise järgselt esimese 3 kuu jooksul, siis makstakse asendamisele järgneva 3 kuu vältel meeskonnaliikmele ettenähtud tunnitasust 10 % väiksemat tunnitasu.

4. Hankelepingu kehtivus

4.1 Hankeleping jõustub alates hetkest, kui pooled on hankelepingu allkirjastanud. 4.2 Hankeleping kehtib Poolte lepinguliste kohustuste täitmiseni.

5. Lepingu lisad:

5.1 Lisa 1 – tellija tellimus;

5.2 Lisa 2 – täitja pakkumus….. 5.3 Lisa 3 - …..

Leping on koostatud ja allkirjastatud digitaalselt.

Lisa 1.1 Üleandmise-vastuvõtmise akti vorm

Alus (täida need read, mis kohalduvad):

Riigihanke viitenumber: ….

Riigihanke nimetus: … Seotud hanke viitenumber: … Seotud hanke nimetus: …

Hankeleping nr …., sõlmitud …. a.,

Hankelepingu osa viitenumber (15-kohaline): …

Käesolevaga annab ………….. (täitja ettevõtte nimi) üle ning ……… (tellija asutuse nimi)

võtab vastu (edaspidi lepingu ese):

1. …….. (täida lepingu esemest tulenev võimalikult detailne sisu):

 tulemi puhul maksumus, etapi eesmärgi kirjeldus jne;

 arendusteenuse puhul töötunni hind, kogumaksumus, teostamise periood, töötundide

maht, vajadusel jira ticketite viited jne.

 Vajadusel täida allolev tabel

Meeskonnaliige (roll)

Vastuvõetud töö

Periood Teostatud töötunni

d

Töötunni hind

km-ta

Meeskonnaliikme teostatud töö

hind kokku km-ta

Maksumus kokku km-ta:

Maksumus kokku km-ga:

Hankelepingu rahaline jääk km-ta:

2. ………(dokumentide loetelu).

Üleantava lepingu eseme kogumaksumus on ………………. eurot (lisandub käibemaks).

………………. (täitja lepingujärgse kontaktisiku nimi) kinnitab, et lepingu ese on üle antud

tähtaegselt, vastavalt lepingus sätestatud tingimustele.

…………….. (tellija lepingujärgse kontaktisiku nimi) kinnitab, et vastuvõetud lepingu ese

vastab lepingus sätestatud tingimustele ning lepingu ese on üle antud ja vastuvõetud

vastavalt lepingus sätestatud tähtajale ja tingimustele.

Käesolev üleandmise-vastuvõtmise akt on allkirjastatud digitaalselt.

Täitja:

…………………

/asutuse nimi/

…………………..

/allkirjastaja nimi/

Tellija:

…………………

/asutuse nimi/

…………………..

/allkirjastaja nimi/

Lisa 2 - Tehniline kirjeldus

HKSOS tehniline lahendus

1.1. Üldine

HKSOS on uus Häirekeskuse hädaabiteadete ning abi- ja infoteadete haldamiseks loodud modulaarne lahendus. Lahendus võeti kasutusele alates 09.2019 riigiinfo telefoni 1247

töökohtades ja alates 03.2022 osaliselt 112 töökohtades.

Lahendus võimaldab lähtuvalt kasutaja tööst (rollist) käivitada konkreetses arvutis, vaid vajalik hulk mooduleid, sh vastu soovitud andmekeskuse keskkonda. Vastavalt loodava

funktsionaalsuse korduvkasutatavusele on kavas lahenduse juurutamine ka Häirekeskuse väliselt (SMIT, PPA, SiM jne).

Lahendus koosneb andmekeskuses olevatest serveritest ning kasutaja arvutis asuvast

modulaarsest DESKTOP lahendusest (edaspidi "Desktop"). Kasutaja arvutis olevad moodulid (Frame, UI komponendid ja Serviced) on kõik eraldi tarkvarad.

Moodulid arendatakse .NET core platvormil, UI komponentides kasutatakse WPF-i. Moodulite tööd orkestreerib Frame (autentimine, vajalike UI komponentide käivitamine/sulgemine ja

asukohad/paiknemine frames, Servicete äratamised/uinutamised jne).

Andmekeskuses olevate serveritega suheldakse üldjuhul Servicete kaudu. Andmevahe tus moodulite vahel toimub läbi lokaalse RabbitMq.

2(11)

Erijuhtudel suhtlevad UI komponendid andmekeskuses olevate serveritega otse (Frame

kasutaja autentimiseks, UI moodulid SMIT sisevõrgus avalike n: GEO teenuste tarbimiseks jne).

Logi edastavad moodulid otse lokaalsele logi kogumise ja edastamise moodulile (log servicele),

mis pakub localhost- is logide kogumise teenuseid.

Mooduleid paigaldatakse ja uuendakse eraldi uuendaja mooduli (updater service) kaudu.

1.1.1. RabbitMQ

Andmevahetus moodulite vahel toimub läbi lokaalse RabbitMq. Moodulid edastavad iga erineva sõnumi struktuuri vastava kanali sees kasutatavas ühes queue-s või topic-us.

1.1.2. Frame

Frame on keskne moodul, mis orkestreerib kogu Desktop-i tööd. Hetkel realiseeritud .NET

Windows Forms rakendusena.

Frame põhilised funktsioonid:

 Äratab konkreetsele kasutajale (profiilile) vajalikud Serviced (arvutis võib olla Serviceid, mida ei äratata/pole hetkel vajalikud);

 Kujundab UI komponentidest kasutaja vaate;  Korraldab sisse logimise (autentimise) ning levitab saadud 'SmitTokenId' Servicetele, et

viimased saaksid luua autenditud ühenduse andmekeskuses olevate serveritega;  Esitab Servicete olekud (foor) ning vajadusel Servicete või Ui-de töös esinevad

probleemid (veateated);

 Võimaldab töö käigus vahetada kasutaja profiili;  Sulgeb väljumisel UI moodulid ning uinutab Serviced (laseb lõpetada ühendused

andmekeskuses asuvate serveritega ja oma mälud tühjendada);  Edastab oma logid lokaalsele logi teenusele.

Frame suhtleb Service-tega ning UI komponentidega läbi RabbitMQ kasutades FrameMessaging nuget-is kirjeldatud andmestruktuure.

1.1.3. Serviced

Servicete ülesandeks on hoolitseda andmevahetuse eest ühe konkreetse andmekeskuses oleva serveriga. Realiseeritud .NET core rakendustena (Windows Servicetena). Servicete tööd juhib (äratab, annab serveriga ühenduseks vajalikud parameetrid sh 'SmitTokenId' ning uinutab)

Frame.

Andmekeskuses olevate serveritega ühendustes kasutatakse sertifikaadi põhist krüpteerimist ning suhtlus käib üldjuhul pordil 443 (rest ja sse). Servicete põhilised funktsioonid (sõltuva lt

Servicest võivad need olla erinevad):

3(11)

 Teenuse käivitamisel Windows-i poolt RabbitMQ-ga ühendumine ja sõnumite

kuulama hakkamine;  Ärkamise (wakeup) käsu peale, sõnumis edastatud serveriga ühenduse võtmine ja

autentimist mittevajavate andmete (n: enum-id) pärimine;  Ühenduse (connect) käsu peale, sõnumis edastatud 'SmitTokenId'-ga serveriga

ühenduse loomine (nö autoriseeritud sessioon) sh vajadusel:

o algandmete pärimine; o SSE kanali loomine ning edasine üleval hoidmine;

o varem saatmata jäänud andmete edastamine.  Serverist saadud algandmete edastus UI-dele;  Serverist SSE (server-sent-events) kaudu laekuvate andmete edastus UI-dele;

 UI-delt saadud sõnumite edastus serverile ja vastuse tagastus sh vajadusel serverile edastamata jäänud sõnumi edasiseks saatmiseks salvestamine;

 Uinumise (close) käsu peale serveriga ühenduse lõpetamine ja nö mälu puhastamine;  Oma logide edastus lokaalsele logi teenusele.

Eelnimetatud funktsioonid on realiseeritud SMIT-i universaalsetes komponentides (nuget-ites).

Service suhtleb Frame-i ning UI komponentidega läbi RabbitMQ kasutades selleks vastavalt

FrameMessaging või oma ServiceMessaging nuget-is kirjeldatud andmestruktuure.

Service töö ei sõltu teistest Servicetest.

1.1.4. UI moodulid

UI moodulid käivitab FRAME, mis ühtlasi seadistab kasutaja profiilist sõltuva vaate (paigutab UI moodulid ekraanile).

UI moodul kuvab oma elemendid dünaamiliselt (responsive), st mooduli suuruse muutumise l

ei tohi midagi kaduda 'nurga taha' või tekkida kerimisriba. Rakendust kasutatake FHD (1920x1080) ja QHD (2560x1440) monitoridel, sh näiteks 480 ja 640 pikseli laiuste appidena. Kasutajaliidese värvilahenduse edastab Frame UI mooduli käivitamisel (näiteks 112 ja 1247

kujundus või päeva ja öö režiim).

UI moodulid suhtlevad Servicetega läbi RabbitMq. UI moodul kuulab üksnes neid topic-uid ja nendest Servicetest, mis on talle olulised.

Juhul kui päring ei vaja autentimist võib päringu teostada otse UI moodulist andmekeskuses

asuva serveri poolt pakutavasse teenusesse (n: aadressiteenus).

Funktsionaalsuste puhul, mis vajavad klassifitseeritud andmeid (näiteks klassifikaator ite esitatavate väärtuse näitamine) peab UI moodul kasutama arvuti failisüsteemis olevaid JSON

kujul olevaid klassifikaatorite faile.

1.1.5. Updater service

4(11)

Windows service, mis tegeleb moodulite paigaldamise ning uuendamisega. Pakub 'localhost' -

is teenust brauseri vaatele, milles kasutaja valib soovitud keskkonna ja profiili ning teenus paigaldab/uuendab vajalikud moodulid ning konfiguratsiooni failid.

1.1.6. Log service

Windows service, mis pakub kõigile lokaalsetele moodulitele logide edastamise teenust.

Moodul võtab vastu tehnilise- ning kasutajate tegevuste logid ning edastab need kesksetesse logide serveritesse.

1.1.7 Classifier service

Windows service, mis pärib klassifikaatorite andmed ning salvestab need JSON kujul arvuti

failisüsteemi, mida teised moodulid (UI-d ja Service-d) saavad vajadusel kasutada.

1.2. Nõuded service'tele

HKSOS desktop lahenduse olulised komponendid on windows serviced. Windows serviced on ette nähtud andmeid vahendavateks komponentideks UI-de ning andmekeskuses asuvate

serverite vahel. Üks service = üks andmekeskuses olev server rakendus (BackEnd ehk BE). Seega üks service saab pöörduda ainult ühe BE poole. Kogu süsteemis on iga BE kohta üks

eraldi töötav service.

Service ülesanneteks on:

1) hoida lokaalses arvutis süsteemi tööks vajalikke andmeid (näiteks enumid, operatiivtöös vajalikud sisulised algandmed jne);

2) optimeerida UI-de päringuid BE-sse (kui service mälus on operatiivseks tööks

vajalikke andmed ning UI päringu parameetrid võimaldavas siis vastatakse UI-le nö cache-st, mitte ei pärita andmeid BE-st);

3) luua vajadusel BE-ga SSE ühendus, hoida seda üleval (taastada katkemise korral) ning võtta vastu BE-st saabunud operatiivandmed ning edastada need UI-dele sh vajadusel

uuendadas enda operatiivandmete cache;

4) vahendada UI-de andmete salvestusi ja päringuid BE-sse;

5) tagada vajadusel ajutised (BE puudumisel) salvestused;

6) logida oma töö.

Service töötab tavalise windows servicena, mis käivitatakse Windowsi poolt. Service paigaldamisel peab olema märgitud tema sõltuvus servicest - Rabbit MQ. Seega Rabbit MQ

service peab olema enne käima läinud. Service käivitamisel Windowsi poolt loob service ühenduse Rabbit MQ-sse ning jääb sealt käske ootama.

5(11)

Service haldab faile "c:/ProgramData/SMIT/" kataloogi sees oma nimelises kataloogis. Service

poolt hallatavad failid on:

1. enumite fail (kõik BE-st saadud enumid ühes failis) või muude sarnaste st staatilised andmete failid (n: call service-l serviceGroups andmed);

2. ajutiste salvestuste draft failid;

3. mõnel servicel ka nö algandmete failid (näiteks classifier service-l classifiers,

classifierClassifiers ja aikEventDataRules);

Service loeb esmasel käivitamisel failidest endale mällu enumite ja algandmete andmed. Draftidega käitumine on servicetes erinev.

Service haldab enda sees 4 olekute foori: enumid, algandmed, SSE ühendus ja autentimine .

Igal fooril on kolm seisundit - null/false/true. Foori seisundid kuvatakse Frame ui-s värvilise lt (väärtustamata-hall [kui teenus pole foori väärtustanud], null-sinine, false-punane, true-

roheline). Lisaks on servicel mälus draftide arv.

1.2.1. Service'te standardtegevused

1.2.1.1. Windows käivitab service

Service käivitub sõltuvuses Rabbit MQ servicest ehk siis peale Rabbit MQ service tööle hakkamist. Service käivitub vaikimisi logimise tasemega INFO. Logida tuleb käivitumine

INFO tasemel, kirjutades logisse 'Service started' (patternist tuleb see, mis servicega on tegemist). Käima minekul võtab ta ühenduse Rabbit MQ-ga ning hakkab kuulama FRAME-st saabuvat topicut (seda kuulavad kõik serviced) ning UI-dest saabuvat queue (seda kuulab alati

konkreetne service üksinda). Käima mineku järgselt kontrollib service kas enumite ja sarnased staatiliste andmete failid eksisteerivad arvutis. Kui kõik konkreetse service poolt hallatavad

enum jm failid on olemas ja ei ole tühjad, siis paneb service "enumid" oleku false. Kui kasvõi üks enum failidest puudub või on tühi, siis paneb service "enumid" oleku NAN ehk väärtustab tühjana.

Mõned serviced - näiteks classifier service käitub sarnaselt ka algandmetega. See on väga

konkreetne/erandlik juhtum st kus algandmed on BE-st vabalt kätte saadavad kõigile (a'la üldised reeglid ja klassifikaatorid). Kui sellisel servicel on algandmete failid arvutis olemas ja

mitte tühjad, siis paneb service "algandmed" oleku false. Kui esineb probleem kasvõi ühe algandmete failiga, siis märgib service "algandmed" NAN ehk väärtustab tühjana. Enamike l servicetel, mis algandmete laadimiseks vajavad autentimist, paneb service "algandmed" oleku

NAN ehk väärtustab tühjana.

Servicete käima mineku järgselt pannakse paika ka teised olekud. Kui service ei kasuta SSE-d ning autentimist - näiteks classifier service, siis määratakse koheselt "autentimine" oleku

väärtus true. Draftide arv ehk siis failide arv loetakse kokku "c:/programData/SMIT" kataloogis konkreetse service ajutiste salvestuste kataloogist.

Kui kõik olekud on seatud sh draftide arv on kokku loetud, tuleb logida INFO tasemel logi kirje,

kus on muutujana kirjas kõik seatud olekute väärtused ning draftide arv.

6(11)

Service ei tohi veel käivitada ühtki cron-i ega muud arvutit koormavat tegevust (see kehtib

servicete kohta, mida juhib FRAME). Selliselt jääb service ootama käske FRAME-lt ja ka päringuid UI-st.

Sõnumid framelt:

1. Frame töötamisel hakkab ta servicetele saatma iga 5 sek tagant "keepalive" sõnumit, et

FRAME on olemas. See sõnum on to ALL, mitte konkreetsele servicele. 2. Kui FRAME poolt saabub "keepalive" sõnum ning service EI OLE ÄRATATUD

(üksnes Windowsi poolt tööle pandud), siis service logib: 1. TRACE tasemel terve JSON-i. 2. DEBUG tasemel - "received reason (muutuja) but sleeping".

3. INFO tasemel sellise sõnumi saabumist ei logita.

Päringud UI-delt:

1. Kui UI-st saabub päring ja service EI OLE ÄRATATUD, siis service ei vasta sellele ning logib

1. TRACE tasemel terve JSON-i. 2. WARN tasemel - "received request from: (muutuja kellelt) reason: (muutuja),

but sleeping." Mõlemad väärtused on sõnumi päises ning JSON sõnumit ei pea parsima.

1.2.1.2. Service äratamine

Tavapäraselt äratatakse serviced enne UI päringuid. Äratamiseks saadab FRAME konkreetsele servicele äratamise st "wakeup" sõnumi Rabbit MQ kaudu (sama topic, kust saabuvad

"keepalive" sõnumid). FRAME saadab äratamise sõnumi alati vaid konkreetsele servicele, mitte to ALL. Sõnumis on ka BE url, kuhu peab service pöörduma. Lisaks on sõnumis logimise

tase. Kui sõnumis puudub logimise tase, peab logimise tase olema INFO. Kui sõnumis on näiteks DEBUG, siis peab service lülituma logimise tasemele DEBUG.

Logida tuleb:

1. TRACE tasemel received wakeup ning terve saabunud JSON sõnum.

2. INFO tasemel received wakeup, logging - (muutuja), url (muutuja).

Service peab panema enda sees tööle cron-i, mis hakkab iga 5 sek tagant saatma enda olemasolu kohta sõnumit FRAME-le, mis koosneb service olekutest.

NB! - varasemalt saatsime seda FRAME "keepalive" sõnumi vastusena, nüüd teeme selle autonoomseks ning eraldame frame tööst.

Sõnumi järgselt teab Frame, et konkreetne service töötab.

NB! kõiki serviceid ei äratata alati, seega äratamine peab olema service põhine.

Peale äratamist pöördub service saadud url-ile ning küsib BE-st enumid ja kõik muud andmed, milleks ei ole vaja autentimist (näiteks classifier service küsib oma algandmed ehk classifiers, classifierClassifiers ja aikEventDataRules, call service-l serviceGroups andmed jne). Kui

7(11)

enumite teenus (call service-l ka serviceGroup teenus) vastab, siis service uuendab salvestatud

faili ning kirjutab selle kohta INFO tasemel logi kirje. TRACE taseme korral tuleb logida terve päring ja vastus. Lisaks paneb service "enumid" oleku true. Kui vastust ei saadud või faili

salvestamine ei õnnestu siis tuleb logida ERROR ja "enumid" olekut ei muudeta.

Erand:

1. Classifier service uuendab ka algandmed (classifiers, classifierClassifiers ja aikEventDataRules jne), sest neid saab ilma autentimata pärida.

2. Kui päringud õnnestub siis tuleb uuendada failid ning panna "algandmed" olek true ning kirjutada INFO tasemel logi kirje üldiselt. TRACE tasemel terve päring ja vastus.

3. Kui vastust ei saadud või faili(de) salvestamine ei õnnestu siis tuleb logida ERROR ja

"enumid" olekut ei muudeta.

Service hakkab iga 5 sekundi tagant FRAME-le saatma olekute sõnumit, kus on 4 olekut ja draftide arv. Seda tegevust tuleb logida TRACE tasemel terve saadetav sõnum, DEBUG

tasemel üldiselt, "sent message ...", INFO tasemel seda ei logita.

1.2.1.3. Service ühendumine

Ühendumiseks saadab FRAME kõigile servicetele Rabbit MQ kaudu (sama topic, kust saabuvad "keepalive" ja "wakeup" sõnumid) ühendumise st "connect" sõnumi, kus on token,

millega saab BE-s ennast autentida. Ühendumise käsk saabub to ALL, mitte konkreetsele servicele. Kui varasemalt ei ole saabunud konkreetsele servicele äratamise st "wakeup" käsku, siis service ei tea BE aadressi/asukohta ning ignoreerib FRAME poolt antud ühendumise

korraldust. See on normaalne olukord, sest konkreetne service ei ole hetkel kasutuses. Saabunud sõnum tuleb logida TRACE tasemel terve JSON-ina. Kui service oli varem äratatud siis

ühendub ta "connect" ühendumise sõnumis saadud tokeniga wakeup/äratamise sõnumis saadud aadressil/asukohaga BE-ga. Kui autentimine õnnestub ja BE-st EI TULE vastuseks 40X viga, siis service:

 paneb "autentimine" oleku true;

 saadab kõigile UI-dele (to ALL) Rabbit MQ kaudu sõnumi, ühenduse loomise kohta

(peale mida saavad UI-d servisele päringuid saata);

 kirjutab logisse INFO tasemel - received reason connect, authenticated = true.

 Kui autentimine EI ÕNNESTU, siis tuleb vaadata miks ei õnnestunud. Kui põhjuseks on

võrgu puudumine, siis tuleb logida WARN tasemel üldiselt mis juhtus. Kui BE ei lase tokeniga sisse, tuleb logida ERROR. Mõlemal juhul peab service jätma sh vajadusel

muutma "autentimine" oleku false-ks.

 Seoses tokeni vahetamisega saabub Framelt ka juba autentitud servicele regulaarselt uus

"connect" käsk, kus on uus token. Kui servicele on ette nähtud siis loob ta BE-ga peale autentimist ka SSE ühenduse/socketi. Kui see õnnestub, siis logitakse see INFO tasemel

ja pannakse "SSE ühendus" olekuks true. Kui ei õnnestu, siis ERROR ja olekut ei muudeta.

 Service jätkab iga 5 sekundi tagant FRAME-le olekute sõnumite saatmist, kus on 4 olekut

ja draftide arv. Tegevust tuleb logida TRACE tasemel terve saadetava sõnumina, DEBUG tasemel üldiselt, "sent message ...", INFO tasemel seda ei logita.

1.2.1.4. Service ühendumise lõppemine

8(11)

HKSOS Desktopis on olemas ka ühendumise lõpetamise ehk väljalogimise võimalus.

Ühendumise lõpetamiseks saadab FRAME kõigile servicetele Rabbit MQ kaudu (sama topic, kust saabuvad "keepalive", "wakeup", "connect" sõnumid) ühendumise lõpetamise st

"disconnect" sõnumi. Ühendumise lõpetamise käsk saabub to ALL, mitte konkreetsele servicele. Sõnumi peale tuleb servisel unustada varasemalt saabunud token ja lõpetada SSE ühenduse, kui see eksisteeris. Enam ei tee service ühtki päringut BE-sse. Frame 'dicconnect"

sõnum tuleb logida: TRACE tasemel - terve saabunud JSON sõnum. INFO tasemel üldiselt - received reason disconnect, all disconnected (logi pattern paneb kõik service üldised andmed).

Sellised serviced, millel on SSE ühendus ja autentimine, panevad mõlemad olekud false ning edastavad uued olekud sõnumiga FRAME-le. Serviced, kus SSE ühendus ja/või autentimine ei ole kasutusel, jätavad olekud jätkuvalt true-ks (need pandi true juba service käivitamisel), sest

need pole antud service juures kasutusel. Kui mingi olek muutus ehk siis sellisel servicel, kus oli näiteks SSE ühendus kasutusel ja see pandi false-ks siis tuleb muutus logida INFO tasemel

näiteks new flags ning sinna järgi kõikide fooride olekud.

1.2.1.5. Service magama minek close sõnumiga

Servise magama minekuks saadab FRAME kõigile servicetele Rabbit MQ kaudu magama mineku st "close" sõnumi. Service katkestab selle peale SSE ühenduse ja ei tee enam BE-sse

päringuid. Isegi siis mitte kui UI-st tuleb salvestuse päring. Close sõnumi järgselt läheb service magavasse olekusse, paneb kõik KASUTUSEL olevad olekud false, sest ühendusi enam pole. Kui pole ka enumeid ja ei ole neid kunagi saanud, siis enumite olekud ei muutu ehk jäävad

NAN. Sellised olekud, mis EI OLE KASUTUSEL on alati, juba service käivitamisest alates true. Olekud peavad olema paigas, sest kohe võib saabuda uus äratus ning siis peab service ka

kohe frame-le vastama. Magav olek tähendab sama seisundit nagu service on kohe peale windows käivitamist. Magama minemisel tuleb eranditult ka kõik cron-id ja timerid sulgeda! Service ei saada enam FRAME -le iga 5 sek tagant olekuid.

Magama minek tuleb logida:

1. TRACE tasemel terve saabunud JSON,

2. INFO tasemel üldiselt received close, going sleep.

Magavas olekus tuleb käituda nagu peale service käivitamist windowsi poolt.

1.2.1.6. Service magama minek kui FRAME ei saada enam iga 5 sek tagant sõnumeid

Service peab jälgima kas FRAME saadab talle ikka iga 5 sek tagant "keepalive" sõnumit st et ta on alles. Selleks võiks olla services timer, mis nullitakse iga FRAME-st saabuva "keepalive"

sõnumi peale. Kui FRAME sõnumid lakkavad, siis peab service eeldama, et FRAME on sulgunud või lihtsalt kadunud. Kui 12 sek ei ole FRAME-lt tulnud sõnumeid, siis läheb service

magama nagu ka close sõnumi korral. Antud olukord tuleb logida WARN tasemel - keepalive stopped, going sleep. Jälgida tuleb, et mitte ühtki protsessi ei jääks tööle. Üksnes FRAME-st ja UI-dest sõnumite kuulamine jääb tööle.

2. Tarkvaraarenduse nõuded

2.1 Arenduse protsess

9(11)

Tarkvara tarnitakse SMIT-i GIT-i;

Tulemit jooksvalt st JIRA arenduspiletite kaupa tarnides:

 laeb arendaja koodi ülesse JIRA pileti nimelisse harusse sh viitab commit-is JIRA piletile. Commit-e soovitame teha korra päevas, näiteks tööpäeva lõpetades;

 funktsionaalsuse valmimisel teeb arendaja pull requesti JIRA pileti nimelisest harust

develop harusse ning muudab JIRA pileti olekusse 'code review';  kontrollib arendaja pull request järgselt koodile tehtud staatilise SONAR analüüsi tulemi

vastavust nõuetele;  ootab arendaja teise/teiste arendaja(te) poolt koodi ülevaatuse tulemit (märkuste korral

lahendab need);

 aktsepteeringu(te) korral mergeb commiti teinud arendaja koodi develop harusse;  kontrollib arendaja merge järgselt, kas koodist ehitus automaatselt exe, mis on

testijale/vastuvõtjatele kättesaadav. Kui ehitus toimis siis muudab JIRA pileti olekusse 'in review', kui ei siis lahendab iseseisvalt või koostöös Hankijaga ehitusel tekkinud probleemid.

2.2. Nõuded koodi ülesehitusele

Rakendus tuleb üles laadida SMIT-i GIT-i järgmise struktuuriga:

 ROOT kataloogis peab olema mooduli nimeline projekti fail (Smit<moodul>.sln);  Rakendus peab olema ROOT kataloogis olevas mooduli nimelises kataloogis

Smit<moodul>;

 Testid peavad olema ROOT kataloogis olevas eraldi kataloogis Smit<moodul>.Tests;  ROOT kataloogis peab olema kataloog nimega 'doc', kus peab olema mooduli kirjeldus

ning juhend. Kui moodul vajab välist konfifaili, siis ka kommenteeritult näidis konfifail.

Andmevahetuses esinevad andmestruktuurid (näiteks serverist saabuvad JSON-id või RabbitMQ kaudu vahendatavad JSON-id) tuleb kirjeldada eraldi nugeti projektina, mille nimi on <mooduli nimi>-service-messaging. Igal servicel on oma andmestruktuuridega kirjeldatud

nuget. Antud nuget kaasatakse nii servicele kui ka UI moodulitele, mis suhtlevad konkreetse servicega.

UI moodulites tuleb hoida eraldi andmete mudel ning esitlusmudel st kasutada Model View

ViewModel (MVVM) mustrit.

Moodulites ei tohi kasutada kolmandate osapoolte teeke. Mooduli sõltuvused võib laadida üksnes SMIT-i sisemisest repositooriumist. Juhul kui kolmandate osapoolte teekide kasutamine

oleks 'mõistlik', tuleb see iga kord eraldi tellijaga kokku leppida.

Kood tuleb kokku pakkida 'publish' käsuga üheks versioneeritud exe failiks.

Kasutada tuleb SMIT-is seni loodud järgmisi universaalseid komponente sh vajadusel neid täiendada:

 Nuget, mis korraldab RabbitMQ ühenduse ning konkreetsete queue/topic-ute kuulamise;

 Nuget, mis tegeleb FRAME integratsiooniga;

10(11)

 Nuget, mis tegeleb andmekeskuses oleva serveri sessiooniga ning SSE kanali

hoidmisega;  Nuget, mis tegeleb logimisega;

 Nuget, kus on UI komponendid.

2.3. Nõuded koodi kvaliteedile

 Kood peab olema inglise keelne, meetodite ning muutujate nimest peab olema aru saada milleks neid kasutatakse.

 Kõik klassid ning meetodid peavad olema kommenteeritud.  Olulised klassid peavad olema kommenteeritud.  Kood peab läbima standardse SONAR analüüsi. SMIT-is kasutatavad

kvaliteedimõõdikud ja nende lubatud väärtused: o Coverage - mõõdik määrab mitu protsenti kogu lahenduse lähtekoodist on

kaetud automaattestidega. Alampiir on 80%; o Duplicated Lines (%) - mõõdik määrab mitu protsenti lähtekoodi koodist võib

olla dubleeritud. Ülempiir on 3%;

o Maintainability Rating - mõõdik määrab mitu protsenti kogu rakendusele kulunud ajast on tekitanud tehnilist võlga (Code Smell) koodi stiili ja

standarditele vastavuse osas. Lubatud maht on alla 5%-i (tase A); o Reliability Rating - mõõdik näitab palju on koodis erinevaid vigu. Uues ja

refaktooritud koodis ei tohi olla ühtegi viga (tase A);

o Security Rating - mõõdik näitab palju on turvanõrkuseid rakenduses, mis on Sonari poolt tuvastatud. Ei ole lubatud ühtegi turvanõrkust (tase A).

 Vähemalt pooled (arvuliselt) koodi automaattestidest peavad olema testid, kus läbitakse äriprotsess tervikuna. Mõte seisneb selles, et ühe meetodi teste oleks vähe, kogu protsess moodulis tuleb testimisel läbida. Näiteks tuleb simuleerida UI mooduli testis JSON

sõnumi saatmist ning seejärel kontrollida kas ViewModel-isse on andmed kohale jõudnud.

2.4. Nõuded logimisele

Kasutada tuleb SMIT-is loodud spetsiaalset logimise nuget-it, kus on defineeritud logi kirje

muster, kohad kuhu logi kirjutatakse ning ka log objekt. Iga äriprotsessi alguses tuleb luua uus log objekt, kuhu pannakse äriprotsessi alguse aeg ning sisendiks saadud info (näiteks moodulisse saabunud JSON). Log objekti tuleb kaasas kanda kuni äriprotsessi lõpuni, kus logi

kirje luuakse. Protsessi käigus saadud vea korral kirjutatakse log objektist võetud sisend veateate juurde.

 Moodulid kirjutavad logi INFO tasemel.

 INFO tasemel logitakse üksnes olulisi, konkreetses arvutis toimuvaid tegevusi.  Perioodilisi tegevusi üldjuhul ei logita INFO tasemel.

 Üks äriprotsess peab olema logitud ühe logi reana. Logi peab olema informatiivne, ühelt realt peab olema aru saada mida moodul tegi.

 Vea korral peab olema logi kirje alusel võimalik viga korrata st logis peab olema sisend,

mis põhjustas vea.

Tehnilisele logile lisaks tuleb SMIT-iga kokkulepitud UI-i funktsioonide kasutamine logida nö täiendavate kasutaja tegevuslogi kirjetena. Tegevlogi kirje peab sisaldama viidet hallatava le

objektile, tegevuse nime/tunnust, teostamise aega ning tegevuse teostanud kasutaja andmeid.

11(11)

Tegevuslogi koostamisel tuleb kasutada vastavat nuget-it ning selles kirjeldatud logimise

mustrit.

Tehniline logi ja tegevuslogi edastatakse kirjete kaupa lokaalsele logiteenusele, mis edastab tehnilise logi kesksele logi serverile ja error logi ning tegevuslogi eraldi seisvale HKSOS

teenuse log rakendusele.

1 / 2

Koostatud 06.08.2024 00:48:05 https://riigihanked.riik.ee/rhr-web/#/procurement/7617685/general-info

VASTAVUSTINGIMUSED Viitenumber: 282491 Hankija: Siseministeeriumi infotehnoloogia- ja arenduskeskus (70008440) Hange: Vanemarendaja ressursi ostmine (C#, WPF, TETRA) HKSOS-le

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. Andmed lepingusse, mida kasutatakse juhul, kui pakkumus tunnistatakse edukaks. Pakkuja esitab andmetena: 1. ettevõtte 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). (Suur sisestusala (max pikkus 4000 tähemärki))

2. Kas pakkujal on isikuid, kellel on volitus ettevõtjat esindada, tema nimel otsuseid teha või teda kontrollida, ning kelle olemasolu ei kajastu äriregistris. Pakkuja esitab 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- p 3. (Suur sisestusala (max pikkus 4000 tähemärki))

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

4. Pakkumuste jõusoleku tähtaeg on 3 kuud. Kas pakkuja kinnitab, et on pakkumus on jõus 3 kuud? (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))

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

2 / 2

Koostatud 06.08.2024 00:48:05 https://riigihanked.riik.ee/rhr-web/#/procurement/7617685/general-info

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

NÕUDED C#/WPF+TETRA VANEMARENDAJALE

Pakkuja esitab oma pakkumuses vanemarendaja CV. Vanemarendaja rolli täidab üks isik.

C#/WPF+TETRA vanemarendaja peab: 1) omama vähemalt 5 aastat töökogemust C# arendajana; 2) omama vähemalt 2 aastat töökogemust vanemarendajana (st laiem tehniline kogemus, sh tarkvaraarhitektuuri kavandamine ja loomine, süsteemi struktuuri ja komponentide määratlemine, teiste arendajate koodi ülevaatamine ja tagasiside andmine (code-review), arendajate juhendamine, uute tehnoloogiate/raamistike ja arendusmeetodite uurimine/rakendamine, lisaks unit-testidele funktsionaalsete testide koostamine); 3) olema vähemalt 3200 tundi arendanud projektides WPF-is, sh vähemalt kahes projektis kasutanud MVVM arendusmustrit ning funktsionaalseid unit-teste ; 4) omama vähemalt 960 tundi AirBus TETRA raadioside süsteemiga integratsiooni loomise kogemust (TETRA Voice Gateway (TVG) ja TETRA Connectivity Server (TCS)) projektides; 5) omama G.711 standardil põhineva heli voogedastus lahenduse arendamise kogemust projektis.

Pakkuja esitab nõuetele vastava C#/WPF+TETRA vanemarendaja andmed CV vormil.

Küsimused ettevõtjale: 1. Pakkuja esitab lepingut täitma ühe C#/WPF+TETRA vanemarendaja, kes vastab hankija vormil seatud vastavustingimustele. Esitada täidetud CV vorm (Vabas vormis dokument)

Lisa 3.1. CV vorm – C#/WPF+TETRA vanemarendaja

Hankija nimi: Siseministeeriumi infotehnoloogia- ja arenduskeskus (70008440)

Riigihanke nimetus: Vanemarendaja ressursi ostmine (C#, WPF, TETRA) HKSOS-le Riigihanke viitenumber: 282491

Ees- ja perenimi: ____________

Vastavustingimused rollile ja selle tõendamiseks esitatavad kohased andmed (kohustuslikud):

1. Kogemused:

Nõue Nõude täpsustus Pakkuja kirjeldab nõuete täitmist. Andmete esitamisel

tuleb lähtuda RHR-i vastavustingimustes ja käesolevas

dokumendis toodud nõuetest.

Vajadusel lisada ridu

Spetsialisti rollile vastav

tööstaaž

kuudes

1.1. omab C# arendajana

töökogemust kokku vähemalt 5

aastat (60 kuud)

1. Ettevõte/asutus, kus on töötanud/projekt, kus

kogemus on omandatud (riigihanke projekti

korral lisada selle number)

Kontaktisiku nimi ja kontaktid

Kogemuse algus- ja lõppaeg kuu täpsusega

Kogemuse/projekti kirjeldus

1.2. omab vanemarendajana töökogemust kokku vähemalt 2

aastat (24 kuud). (st laiem tehniline

kogemus, sh tarkvaraarhitektuuri

kavandamine ja loomine, süsteemi

struktuuri ja komponentide

1. Ettevõte/asutus, kus on töötanud/projekt, kus

kogemus on omandatud (riigihanke projekti korral lisada selle number)

Kontaktisiku nimi ja kontaktid

Kogemuse algus- ja lõppaeg kuu täpsusega

määratlemine, teiste arendajate koodi

ülevaatamine ja tagasiside andmine

(code-review), arendajate

juhendamine, uute

tehnoloogiate/raamistike ja

arendusmeetodite

uurimine/rakendamine, lisaks unit-

testidele funktsionaalsete testide

koostamine)

Kogemuse/projekti kirjeldus

/vajadusel lisada ridu/

1.3. olema vähemalt 3200 tundi arendanud projektides WPF-is , sh vähemalt kahes (2) projektis kasutanud MVVM

arendusmustrit ning

funktsionaalseid unit-teste (töötunnid peavad olema teostatud ja tellija poolt vastu võetud)

1. Projekti tellija ja projekti nimi, kus kogemus

on omandatud (riigihanke projekti korral

lisada selle number)

Tellija kontaktisiku nimi ja kontaktid

Kogemuse algus- ja lõppaeg kuu täpsusega

Töötundide maht …. töötundi

Kogemuse/projekti kirjeldus, sh märkida kas on kasutanud MVVM arendusmustrit ning funktsionaalseid unit-teste.

2. Projekti tellija ja projekti nimi, kus kogemus

on omandatud (riigihanke projekti korral

lisada selle number)

Tellija kontaktisiku nimi ja kontaktid

Kogemuse algus- ja lõppaeg kuu täpsusega

Töötundide maht …. töötundi

Kogemuse/projekti kirjeldus, sh märkida kas on kasutanud MVVM arendusmustrit ning

funktsionaalseid unit-teste.

/vajadusel lisada ridu/

1.4. omab vähemalt 960 tundi

AirBus TETRA raadioside

süsteemiga integratsiooni

loomise kogemust (TETRA Voice Gateway (TVG) ja

TETRA Connectivity Server (TCS)) projektides. (töötunnid peavad olema teostatud ja tellija poolt vastu võetud)

1. Projekti tellija ja projekti nimi, kus kogemus

on omandatud (riigihanke projekti korral

lisada selle number)

Tellija kontaktisiku nimi ja kontaktid

Kogemuse algus- ja lõppaeg kuu täpsusega

Töötundide maht …. töötundi

Kogemuse/projekti kirjeldus, sh AirBus TETRA

raadioside süsteemiga integratsiooni loomise

kogemus

2. Projekti tellija ja projekti nimi, kus kogemus

on omandatud (riigihanke projekti korral lisada selle number)

Tellija kontaktisiku nimi ja kontaktid

Kogemuse algus- ja lõppaeg kuu täpsusega

Töötundide maht …. töötundi

Kogemuse/projekti kirjeldus, , sh AirBus TETRA

raadioside süsteemiga integratsiooni loomise

kogemus

/vajadusel lisada ridu/

1.5. omab G.711 standardil

põhineva heli voogedastus lahenduse arendamise kogemust projektis

1. Projekti tellija ja projekti nimi, kus kogemus

on omandatud (riigihanke projekti korral lisada

selle number)

Tellija kontaktisiku nimi ja kontaktid

Kogemuse algus- ja lõppaeg kuu täpsusega

Kogemuse/projekti kirjeldus

/vajadusel lisada ridu/

2. Meeskonnaliikmete CV vormi esitamise nõuded minikonkursil

Pakkuja esitab minikonkursil vanemarendaja andmed. Esitatud andmed peavad võimaldama hankijal kontrollida vanemarendaja vastavust

esitatud nõuetele ja hankija kontrollib tingimuste täitmist eelkõige esitatud andmete alusel.

2.1. Kui tingimuses on nõutud (kõrg)haridus, peab see olema lõpetatud. Hankija arvestab kvalifikatsiooniraamis t iku

(https://www.hm.ee/et/tegevused/kvalifikatsioonid/kvalifikatsiooniraamistik) vastavaid tasemeid. Arvestatakse ka välisriikide vastavat

haridust.

2.2. Kui tingimuses ei ole nõutud töökogemust projektis, võib viidata ka töösuhtele. Projektiks ei loeta (varasemat) töösuhet.

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

2.4. Töökogemuse nõude täitmisena ei arvestata täiendkoolitust või koolitööd.

2.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.6. Projektide andmete esitamisel tuleb iga projekti kohta esitada vähemalt: projekti nimi ja lühikirjeldus, projekti algus- ja lõppaeg

kalendrikuu täpsusega, vajadusel spetsialisti kogemus tundides, projekti tellinud asutus ja tellija kontaktisik ning riigihanke korral märkida

riigihanke number.

2.7. Viidatud projektid peavad olema pakkumuse esitamise ajaks nõutud mahus/ kompetentsi osas täidetud ja tellija poolt vastu võetud.

2.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äitmis eks

või näitlikustamiseks.

2.9. Hankijal on õigus pöörduda tellija poole esitatud andmete kontrollimiseks.

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

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

2.12. Kui see on objektiivselt võimalik, tuleb lugeda tingimusi täiendatuks märkega "või samaväärne". Samaväärsuse tõendamise kohus tus

lasub pakkujal, kes sellele tugineda soovib.

Koostatud 06.08.2024 00:42:16 1 / 1 https://riigihanked.riik.ee/rhr-web/#/procurement/ 7617685/general-info

HINDAMISKRITEERIUMID JA HINNATAVAD NÄITAJAD

Viitenumber: 282491 Hankija: Siseministeeriumi infotehnoloogia- ja arenduskeskus (70008440) Hange: Vanemarendaja ressursi ostmine (C#, WPF, TETRA) HKSOS-le

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 C#/WPF+TETRA vanemarendaja töötunni maksumus

Palun märkida C#/WPF+TETRA vanemarendaja ühe (1) töötunni maksumus

Maksumus - vähim on parim

100 3328 tund (h) jah

Kokku: 100

Hindamismetoodika kirjeldus 1.   C#/WPF+TETRA vanemarendaja töötunni maksumus

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

Koostatud 14.08.2024 15:46:16 https://riigihanked.riik.ee/rhr-web/#/procurement/7617685/general-info

KÕRVALDAMISE ALUSED JA KVALIFITSEERIMISTINGIMUSED Viitenumber: 282491 Hankija: Siseministeeriumi infotehnoloogia- ja arenduskeskus (70008440) Hange: Vanemarendaja ressursi ostmine (C#, WPF, TETRA) HKSOS-le

KÕRVALDAMISE ALUSED

KÕRVALDAMISE ALUSED

Hankija kontrollib osade lõikes pakkujat, kellega hankija kavatseb hankelepingu sõlmida, 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 pakkujalt, kellega hankija kavatseb hankelepingu sõlmida, 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")

D: Ainult siseriiklikest õigusaktidest tulenevad kõrvalejätmise alused

AINULT SISERIIKLIKEST ÕIGUSAKTIDEST TULENEVAD KÕRVALEJÄTMISE

ALUSED: OSALEJA PIIRAMINE ETTEVÕTJA ELU- VÕI ASUKOHA PÕHISELT Kas ettevõtja rikub hankija kehtestatud piirangut pakkumust või taotlust esitada?

RHS § 95 lg 4 p 12 „kellel puudub käesoleva seaduse alusel õigus pakkumust või taotlust esitada, välja arvatud § 111 lõikes 6 sätestatud juhul". RHS § 7 lg 3 sätestab, et hankija võib piirata pakkujate ja taotlejate ringi, lubades riigihankes osaleda ainult RHS § 3 punktis 2 nimetatud riikidest pärit ettevõtjatel või andes nendest riikidest pärit ettevõtjate esitatud pakkumustele eeliseid teistest riikidest pärit ettevõtjate esitatud pakkumuste ees. Hankija sätestab piirangu ettevõtja elu- või asukohale hanke alusdokumentides.

Kehtib: Kõik osad

Küsimused ettevõtjale: 1) Kas pakkuja kinnitab, et tema elu- või asukoht on Eestis, mõnes muus Euroopa Liidu liikmesriigis, muus Euroopa Majanduspiirkonna lepinguriigis või Maailma Kaubandusorganisatsiooni riigihankelepinguga ühinenud riigis. (Raadionupp valikutega "Jah/Ei")

Siseministeeriumi infotehnoloogia- ja arenduskeskus

Mäealuse 2/2, Tallinn 12618

Telefon 612 6200

E-post [email protected]

Reg. kood 70008440

www.smit.ee

14.08.2024 nr 3-17/386

Pakkumuse esitamise ettepanek minikonkursil "Vanemarendaja ressursi ostmine (C#, WPF, TETRA) HKSOS-le" (282491) raamlepingu nr 3-3/3527 alusel

1. Üldteave

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

1.2. Hanke eest vastutav isik: Paavo Kirsi

1.3. Hanke liik: minikonkurss raamlepingu alusel, raamhanke viitenumber 275561,

minikonkursi viitenumber 282491

1.4. Eeldatav maksumus: 300 000 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 (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. Hanke eest vastutaval isikul on

õigus muuta pakkumuste esitamise tähtaega ning teha alusdokumentides menetluse käigus

avastatud vajalikke mittesisulisi muudatusi ning parandusi. 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 ja/või

teeks ettepaneku pakkujate hinnangul riigihanke eseme hankimiseks seatud

ebaproportsionaalsete või põhjendamatute piirangute leevendamiseks.

1.12. RHR üldandmetesse/hanketeate lahtris "lepingu täitmise tähtaeg" määratud kuupäev 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 lepingu projektis või tehnilises kirjelduses määratud

täitmise/lepingu eseme tarnimise tähtajast.

2(4)

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

registrikoodi, kontaktandmed, teabe nende seaduslike esindajate kohta ning alltöövõtulep ingu nimetuse, kuupäeva, numbri ja summa. Samad andmed esitab täitja iga hankelepingu täitmise l

lisanduva alltöövõtja kohta.

2. Minikonkursi dokumendid koosnevad käesolevast dokumendist ning järgmistest

lisadest: 2.1. Lisa 1 – Hankelepingu projekt;

2.2. Lisa 2 – Tehniline kirjeldus; 2.3. Lisa 3 – Vastavustingimused (eRHR vorm); 2.4. Lisa 3.1 – C#/WPF+TETRA vanemarendaja CV vorm;

2.5. Lisa 4 – Hindamiskriteeriumid ja hinnatavad näitajad (eRHR vorm); 2.6. Lisa 5 – Kõrvaldamise alused (eRHR vorm);

3. Olelusringi kulude arvestamine

3.1 Tegemist on hankijal juba olemas ja kasutuses olevate ja loodavate infosüsteemide

arendustöödega. Hankija hindab pakkumuste hindamisel ühe töötunni teostamise tasu, mis väljendab pakkuja võimekust optimaalsete kuludega töid teostada, täiendavalt ei ole hankija

hinnangul oleluskulude hindamine võimalik. Pakkuja pakutav meeskonna koosseis ei mõjuta infosüsteemi elukaare kulusid. Lisaks on planeeritud katta võimalikud tekkivad olelusringikulud SMITi 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 minikonkurs i

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.

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. 6. Pakkumuste vastavuse kontrollimine

6.1. Pakkumus tunnistatakse vastavaks, kui see vastab kõikidele minikonkursi tingimuste le ning selles ei esine sisulisi kõrvalekaldumisi esitatud tingimustest.

3(4)

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

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 pakkujal, kelle ta kavatseb edukaks tunnistada. Kui selle 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. Tellijal 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. tellija ei saa projektile rahastust;

7.1.4. omal algatusel põhjendatud vajadusel.

7.2. Hankijal on õigus minikonkurss kehtetuks tunnistada ettenägematutel ja hankijast

olenevatel/mitteolenevatel põhjustel, kui minikonkursi toimumise ajal on hankijale saanud

teatavaks uued asjaolud, mis välistavad või muudavad hankijale ebaotstarbekaks minikonkurs i

lõpule viimise esitatud tingimustel (sh muudatused seadusandluses või teistes õigusaktides).

7.3. Hankija hindab hindamiskriteeriumi majanduslikult soodsaim: madalaim hind alusel

ning edukaks tunnistatakse 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 edukal pakkujalt RHS § 95 lõikes 1 ja 4 sätestatud kõrvaldamise aluseid.

Hankija ei sõlmi hankelepingut eduka pakkujaga, kellel esineb mõni § 95 lõikes 1 nimetatud kõrvaldamise alus ning hankija võib kõrvaldada minikonkursilt eduka pakkuja, kellel esineb mõni

RHS § 95 lõikes 4 nimetatud kõrvaldamise alus. 8.2. Juhul, kui pakkujal esineb vähemalt üks RHS § 95 lõike 1 punktides 1–3 ja 5 ning lõike 4 punktides 2–11 nimetatud alustest, peab pakkuja esitama hankija nõudmisel RHS § 97

kohased ja põhjendatud heastamismeetmed iga sellise esinenud asjaolu kohta. 8.3. Kui edukas pakkuja kõrvaldatakse minikonkursilt, 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.

4(4)

Lugupidamisega

(allkirjastatud digitaalselt)

Mart Nielsen

peadirektor

Lisa: Loeteletud punktis 2

Paavo Kirsi, [email protected]