Leping

Tehniline kirjeldus

Siseministeeriumi haldusala asutuste erinevate kaardirakenduste ja muude rakenduste jaoks on

loodud erinevad kesksed aluskaardi teenused, infokihi teenused, asukoha otsinguteenused ja

teekonnaarvutuse teenused, mida kasutatakse erinevates ärirakendustes. Lisaks on nende

asutuste ruumiandmete haldamiseks on loodud Geoinfo rakendus.

Taust

Raamlepingu eesmärgiks on tellida arendustööde teenust (front-end arendaja (Angular) ja Java

vanemarendaja (back-end)) ruumiandmete halduse platvormi ja sellega seotud süsteemide

(teenuste, rakenduste, infosüsteemide) arendamiseks.

Siseministeeriumi haldusala asutuste ruumiandmete haldamiseks on loodud Geoinfo

rakendused. Kasutusel on neli erinevat kasutajaliidest, mis jagunevad erinevate asutuste ja

valdkondlike kasutajate vahel. Praegune lahendus on tehnoloogiliselt vananenud ning

kasutajate soovid on aastatega muutunud, seega pole võimalik vana süsteemi enam edasi

arendada. Geoinfosse liigub andmeid automaatselt ka erinevatest infosüsteemisest ja samuti

saadab see andmeid edasi teistesse API-desse või ruumiandmete teenustesse.

Raamlepingu perioodiks on kavandatud uue Geoandmete haldamise keskkonna loomine,

kasutades selleks uusi ja olemasolevaid tehnoloogiaid. Planeeritav Geoandmete haldamise

keskkond on piiritletud uue kasutajaliidese, andmete haldamise keskkonna, sh uue

kasutajaliidese ja backend rakendusega. Kasutajaliidese juures on plaanitud kasutada

Openlayersi kaarditeeki ja UI lahendus luuakse Angular raamistikku kasutades. Ruumiandmete

jagamiseks kasutatakse ArcGIS Server lahendust. Samuti tuleb lahendada Geoinfo rakenduses

erinevad liidestused. Uue halduskeskkonna loomisel võib olla vajalik teha

muudatusi/migratsioonitöid ka nn vanadest Geoinfo rakendustest.

Front-end arendaja lähtub Geoandmete uue platvormi front-endi loomisel uuest disainist, mida

tutvustatakse eduka pakkuja front-end arendajale.

Raamlepingu ajal on vajalik ka erinevate teiste ruumiandmete teenuste edasi arendamine

(kesksed aluskaardi teenused, infokihi teenused, asukoha otsinguteenused ja teekonnaarvutuse

teenused).

Töökorraldus

Arendajatelt eeldame aktiivset ja sisulist osalust arendatava rakenduse ja teenuste arhitektuuri

planeerimisel, erinevate lahendusalternatiivide analüüsil ja koodikvaliteedi tagamisel.

Arendustööd viiakse läbi agiilseid arendusmetoodikaid kasutades koostöös SMITi vastava

tootetiimiga (tooteomanik, vanemarendaja, arendaja, geoinformaatik, süsteemiadministraator).

Arendustööde tegemisel tuleb lähtuda SMITis kehtivast arendusnõuetest (vt PEE lisad 2.1-2.4)

Arendaja salvestab igapäevaselt valminud koodi SMIT tarkvara repositooriumisse vastavasse

harusse.

Tarned

1. Töö toimub iganädalaste planeerimiste alusel ning töö sisu kirjeldatakse

piletihaldustarkvaras JIRA.

2. Valminud lahendused tarnitakse jooksvalt Tellija tarkvara repositooriumisse.

Üldine

1. Edukas pakkuja peab suutma tagada järjepidevust olukorras, kus värvatud

meeskonnaliige lahkub/haigestub vmt. Olukorras, kus meeskonnaliige vahetub, tuleb

väljavahetamine tellijaga kirjalikult kokku leppida;

2. Edukas pakkuja kohustub kirjalikult koheselt informeerima tellijat kõikidest edukale

pakkujale teadaolevatest asjaoludest, mis võivad takistada Lepingu täitmist ning

esitama ettepanekud probleemide optimaalseks lahendamiseks.

3. Täpsemad nõuded lepingu täitmisele jmt on kirjeldatud raamlepingus ja hankelepingus

4. Kui esineb vastuolu käesoleva tehnilise kirjelduse ja (raam/hanke)lepingu vahel, tuleb

lähtuda lepingust.

Lisad:

1) Lähtekoodi halduse ja ehitamise nõuded arendajale

2) Logimise nõuded

3) Rakendustevahelised integratsioonipõhimõtted

4) Tehnilised nõuded tarkvaralahendustele

a. b. c. d. e. f. g. h. i. j.

Lähtekoodi halduse ja ehitamise nõuded arendajale Versioonihalduse kasutamine

Tarkvara lähtekoodi halduseks tuleb kasutada   aadressil asuvad GIT repositooriumi (ligipääs antakse projekti põhiselt).https://source.smit.sise Tarkvara versioonihalduses jälgitakse üldises mõistes protsessi ( ) või  "git-flow" http://nvie.com/posts/a-successful-git-branching-model/ "feature-

( ) protsessi.branche-workflow" https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow "Git-flow" lähenemist on sobilikum kasutada siis, kui tarkvara versioonide on aeglasem ja harvem ning versioonides toimuvad stabiliseerimisperioodid, samuti kui on vaja mitut erineva funktsionaalsusega versiooni pikaajaliselt toetada. Teine mudel sobib neile kes on rohkem automatiseerinud oma paigaldus ja tarneprotsessid ning kasutavad kas või "Continuous Delivery" "Continuous Deployment" töövooge.

Iga  JIRA pileti realiseerimise alguses loob arendaja JIRA abil (kasutades JIRA sees pileti juures käsku create branche)  nimelisest develop harust endale vastava konvensiooni (vt. joonis) põhiselt  nimelise haru kus arendust tehakse.feature/xxx Konfliktide vältimiseks peab kesksest harust järjepidevalt enda harusse muudatused mestima. Piletis realiseeritud lähtekoodi üleandmiseks SMIT-ile tuleb minna versioonihaldus keskkonna (  vastava tarkvara ruumi https://source.smit.sise) ning valida sealt tab ning luua uus , kus tuleb määrata lähteharuks enda tehtud arendusharu ning lõppharuks keskne pull-requests pull-request haru. Ülevaatajaks tuleb valida SMIT poolne arendaja ning sisuks täiendavad kommentaarid, mida silmas pidada antud tarnes (näiteks et muutus konfiguratsioon või baas vms).

Tarne üleandmise eelduseks on, et üleantav kood vastab kõikidele kokkulepitud nõuetele, mis arenduse alguses on fikseeritud või on konkreetsed puudused toodud välja kirjelduses;pull-requesti  Tarne loetakse vastuvõetuks, kui tarneharus oleva koodiga on toimunud vastavad tegevused:

kood kompileerub SMIT ehitusserveris koodi staatiline analüsaator ei leia koodist vigu (kasutada Bitbucket Sonar pluginat code review raames või Bamboos Sonar taske) ühiktestid jooksevad läbi ilma vigadeta integratsioonitestidjooksevad läbi ilma vigadeta funktsionaalsed testid jooksevad läbi ilma vigadeta Koodi testide kattuvuse analüüs näitab et ei ole toodetud juurde ärikriitilist koodi, mis on testidega katmata arhitekt on tarne muudatustele teinud koodi analüüsi ja need heaks kiitnud kood on ilma konfiliktideta süsteemi poolt mestitud harusse ( on täidetud)develop  pull-request

develop harust ehitatud versioon on paigaldunud arenduskeskkonda ja sinna on võimalik sisselogida Kõik tarnes sisalduvad on seotud konkreetsete JIRA piletinumbritega kujul XXXX-YYYcommitid

Pull-request-i kinnitamisel automaatselt kustutatakse vastav partneri poolt tehtud haru ära, kui mestimine on olnud edukas; Pull-request-ii võib SMIT tagasi lükata, kui seal esineb puudusi või alustada seal sees dialoogi puuduste kõrvaldamiseks (koodi ülevaatuse tegemisel lisatakse kommentaarid otse koodi ridade vahele);  Arendaja peab arendusega seotud dokumentatsiooni kandma SMIT’i wikisse (https://wiki.smit.sise), vastava tarkvara ruumi (v.a paigaldusjuhend mis läheb koodi juurde versioonihaldusesse); Arendaja peab alati arendusi tegema JIRA (https://jira.smit.sise) piletite raames (iga koodimuudatus, mida soovitakse kesksesse versioonihaldusesse saata, peab sisaldama JIRA piletinumbrit) ning muutma nende staatuseid vastavalt arendusele.

Bamboo (CI/CD) kasutamine

Igal tarkvaral on bamboos defineeritud  1 ehitusplaan, mis ehitab ennast " " või " " plaani pealt automaatselt (haru valik sõltub, develop master kumba protsessi kasutatakse koodi halduseks). Arendajad peaksid oma arendusi tegema feature harudes, mida automaatselt Bamboo on võimeline ehitama. 

Bamboo ehitusplaan ehitab  koodi, teeb koodile staatilist analüüsi, võimalusel turvaanalüüsi, jooksutab testid ning Bamboo paigaldusplaan paigaldab lõpuks rakenduse määratud keskkonda. "Git-flow" puhul on reeglina ehitusplaan liidestatud " haruga ning paigaldatakse tulem arenduskeskkonda, testi ja toodangu jaoks develop" versioonid tekivad harude pealt ("release" harud reeglina), mida paigaldatakse Bamboo kaudu käsitsi. "Feature-branche-workflow" protsessi puhul on ehitusplaan liidestatud " haruga, mille tulemus paigaldatakse automaatselt sobivasse master" keskkonda. Võimalus on selle kõrvale luua ka täiendavaid harusid ja siduda neid konkreetse keskkonnaga. Toodangu keskkonda paigaldus tehakse reeglina käsitsi Bamboo sees  ning sinna paigaldatakse sama tulem, mis läks testi.

Logimise nõuded (sh välisele partnerile) Nõuded logimisele, arendus-tiimidele ning välistele partneritele (täitmist kontrollib meeskond, kes välist teenust tellib):

1.    Logimiseks tuleb kasutada alus süsteemi võimalusi ja standardseid teeke. 2.    Logi peab olema loetav tekstilisel kujul UTF-8 kodeeringus.  3.    Süsteemispetsiifilised andmed logikirjes peab võimaluse korral koostama JSON-formaadis.  4.    Logitavates andmetes tuleb enne logifaili kirjutamist kodeerida kõik mittekuvatavad ( ) sümbolid, süsteemispetsiifilised andmed, logides non-printable sisalduvad kasutaja sisestatud väärtused ning välja- ja reaeraldajad (st kogu kasutaja sisendit peab olema võimalik taastada, va punktis 8 toodud andmed), välistamaks logisüste ja sellega seonduvaid ründeid. Logitavad andmeväljad eraldatakse tabulatsiooniga. 5.    Juhul kui ühe päringu kohta tekib kirjeid mitmesse logisse, siis peab olema võimalik neid kirjeid ühise välja abil siduda. Selleks ei sobi kellaaeg, aga sobib näiteks unikaalne päringu ID. 6.    Kõik väljanimede kirjeldused, parameetrite nimetused ja muu informatsioon peab olema võimalusel inglise keeles. 7.    Logitud peavad olema kõik tegevused andmetega, sh:        7.1.    kõik autentimise katsed (hoolimata tulemusest);        7.2.    kõik kasutajate poolt algatatud tegevused;        7.3.    kõik taustaprotsesside tegevused;        7.4.    nii õnnestunud kui ka ebaõnnestunud tegevused. 8.    Andmed, mida on keelatud logida:        8.1.    kasutajate autentimisega seotud saladust või salasõna teksti või räsi kujul;        8.2.    privaatvõtmed;        8.3.    seansivõtme väärtus (nt seansi tokenid või -küpsised) –  logida võib ainult seansivõtmest tuletatud räsi või muud pöördumatut tuletist;        8.4.    andmebaasidest tagastatud päringute täisvastused tekstilisel kujul – logida võib andmete tagastamise fakti või vastuse pikkust.        8.5.    biomeetriliste andmete väärtust taasesitamist võimaldaval kujul. 9.    Sisendandmed peavad olema eristatavad rakenduselt endalt pärinevatest andmetest, kuid olema arusaadavad ilma rakenduse andmebaasita. 10.    Logikirjed jaotatakse võimalusel järgnevalt (eraldi konfigureeritavatesse failidesse):       10.1.    Seansilogi - info kasutajate tuvastamise, rakendusse või kõrgema turvalisusega rakenduse osasse sisenemiste, väljumiste, seansi aegumise, tühistamiste jmt kohta.       10.2.    Tegevuslogi - kogu informatsioon kasutajate ja taustaprotsesside tegevuste kohta koos sisendparameetritega (sh väliste ressursside kasutamise kohta). Tegevuse- ja seansilogi kirjes peab olema vähemalt:            10.2.1.    Silumislogi - arendajate jaoks vajalik debug info, toodangukeskkonnas peaks debug vaikimisi välja olema lülitatud;            10.2.2.    Turvalogi/auditlogi - turvalisusega seotud eeldefineeritud sündmused, mis võimaldavad tuvastada, mis tegevusi mis järjestuses tehti ning leida viiteid võimalikele turvaprobleemidele (SQL injection, IP muutus seansi keskel kui see pole lubatud, kasutaja käivitas käsu, mida tal ei ole lubatud käivitada jms). Sinna kuuluvad turvalisuse seisukohalt kriitilised sündmused (sisenemine, väljumine, rolli muut(u)mine) ning tegevused, mis toovad kaasa rahalisi või juriidilisi tagajärgi.       10.3.    Vealogi - erinevate veaolukordade info, mida võimalusel jaotada kaheks:            10.3.1.    tehniline vealogi - erinevad süsteemsed veateated (probleemid liidestega, süsteemsete taustatööde veateated, vead, mida ei ole püütud (unhandled exceptions));            10.3.2.    kasutajate vealogi - kasutajate tegevuse tõttu esile kutsutud vead mis on käsitletud (handled exceptions). 11.    Logide spetsiifika (mida logitakse, kuidas sündmused logifailidesse on jagatud, rakendusspetsiifiliste logide struktuur ja detailid) peavad olema kirjeldatud teenuse dokumentatsioonis. 12.    Logimine peab olema optimeeritud, st et peab vältima liigsete logiandmete edastamist  logihaldussüsteemi ning välistama informatsiooni dubleerimist logides, juhul kui seda ei ole eraldi nõutud. Vajaduse korral filtreeritakse logid teenuses. 13.    Logimisvahendid ja informatsioon logi kohta peab olema kaitstud volitamata muudatuste, hävitamise ja juurdepääsu eest. 14.    Logisid peab logi edastav teenus saatma reaalajas SMIT’i kesksesse logihaldussüsteemi. Kasutusel peab olema ühtne NTP (Network Time Protocol) ajateenus. 15.    Logide keskne kogumine sisaldab:        15.1.    reaalajas saadetavate logivoogude vastuvõtmist ja salvestamist;       15.2.    salvestatud logivoogude arhiveerimist olenevalt saadetavate logide tüübist ja neile kehtestatud säilitustähtaegadest.  16.    Salvestatavad logiandmed signeeritakse digitaalselt.  17.    Logiandmete turvaliseks edastamiseks SMITi kesksesse logihaldussüsteemi väljapoolt SMITi hallatavat taristut peab kasutama VPNi või mTLS-i ühendust. 18.    Arhiiviväärtusega logide terviklus peab olema tagatud kolmanda poole usaldusteenuse (nt. TrueTrail) abil. 19.    Tõestusväärtusega logisid ei tohi hoiustada ega töödelda rakenduse serveris või andmebaasis. Selline kirje on vaid informatiivse väärtusega ning seda logikirjena ei käsitata. 20.    Ligipääs logiandmetele      20.1.    Logikeskkondadele ligipääs peab olema kitsendatud ja piiratud, logides sisalduvaid andmeid tohib töödelda vaid kasutaja, kellel on selleks õigus ja teadmusvajadus.      20.2.    Logisid on keelatud töödelda väljaspool lubatud keskkondi (kaasarvatud kopeerida). Arhiveeritud ja väljaspool logitaristut hoitavad või edastatavad logiandmed on alati krüpteeritud.      20.3.    Logisid ei tohi avalikustada ega jagada teistele osapooltele, kui selleks ei ole põhjendatud vajadust.      20.4.    Logide töötlemisel peab järgima andmete töötlemisel kehtivaid isikuandmete ning avaliku teabe töötlemist reguleerivaid õigusakte, sh täitma konfidentsiaalsuse kohustust nii töö- või teenistussuhte ajal kui ka pärast selle lõppemist. 21.    Logide säilitustähtaegade määramine ja kustutamine peab vastama andmekogu põhimääruses või teenuse kokkuleppes sätestatud tingimustele. 22.    Säilitustähtaja määramisel peab silmas pidama, et ressursikasutus oleks proportsionaalne ja mõistlik. 23.    Kui logide säilitusaega ei ole teenuse dokumentatsioonis täpsustatud, peab logisid hoidma käesoleva aasta kohta ning säilitama neid kuni ühe aasta. 24.    Logimise puhul kehtivad vähemalt sama taseme turvanõuded, mida on rakendatud logitavale teenusele. 25.    Kui rakenduse äriloogika ei vasta kehtestatud nõuetele tuleb tehnoloogilist lahendust eelnevalt infoturbeosakonnaga kooskõlastama.

Logikirjes peab sisalduma vähemalt teave, et vastata küsimustele: kes, millal, mida, kus ja kust süsteemis tegi ning mis oli tegevuse tulemus.

Logikirje miinimumnõuded on

1.    Logikirjes (minimaalselt tegevus- ja seansilogi) peab sisalduma vähemalt teave, et vastata järgmistele küsimustele:       1.1.     on tegevuse teostaja, sealjuures:KES            1.1.1.    peab ta olema unikaalne vähemalt teenuse piires;            1.1.2.    peab ta olema seostatav füüsilise isikuga, kui see on võimalik;            1.1.3.    tema automaatprotsessid peavad olema selgelt tuvastatavad.       1.2.   on ajamärgistus, mis sisaldab täpset sündmuse kuupäeva ning kellaaega, sealjuures peab aeg olema: MILLAL            1.2.1.    vähemalt sekundi täpsusega;            1.2.2.    UTC ajavööndis;            1.2.3.    ajaformaadis ISO8601 koos ajavööndi infoga, näiteks formaat YYYY-MM-DDTHH:mm:ss.SSSZ.       1.3.     on logitava tegevuse või sündmuse liik või klass, näiteks kasutaja tuvastamine, administreerimine, operatsioon ja kasutus, ning liigi või MIDA klassi tegevuse detailid. Märgitakse:            1.3.1.    üheselt tuvastatav viide objektile või selle komponendile, mida kasutati;            1.3.2.    tegevuse tüüp, näiteks , või kasutatud meetod ja nende sisendandmed;login, timeout, search, request, query            1.3.3.    tegevusega seotud muud andmed ja sisendväärtused, mida tegevuse käigus töödeldi või mis on olulised, näiteks failide nimed, päringu objektid, autentimismeetod.       1.4.     on süsteemi identifikaator, mille abil on võimalik teha kindlaks täpne rakendus ja selle instants, mille suhtes tegevus tehti.KUS       1.5.     on seadme unikaalne identifikaator, näiteks nimi, IP-aadress või seadme sertifikaat, kust tegevus toime pandi, sealjuures peab:KUST            1.5.1.    identifikaatori abil olema võimalik üheselt tuvastada seade, kust sündmus toime pandi;            1.5.2.    IP-aadressi puhul olema tuvastatav lõppseadme IP-aadress.       1.6.     – kui ei ole kokku lepitud teisiti, siis päringute vastuseid täies mahus ei salvestata. Logisse peab kirjutama tulemust kirjeldavad TULEMUS andmed, näiteks tulemuse tüüp (success, attempt, failure, error), vastuse suurus (nii baitides kui ka ridade arvuna).

Logikirje elementide soovituslik järjestus:

{when}\t{where}\t{what}\t{whence}\t{who}\t{procid?}\t{result}\t{msg-payload?}

1. 2. 3. 4. 5. 6. 7. 8.

1. 2. 3. 4.

1.

2.

3.

4. 5. 6.

Rakendustevahelised integratsioonipõhimõtted

Sünkroonne ja asünkroonne suhtlusviis Integratsioon süsteemide vahel (nii välised kui sisemised)

Sõnumivahetuse nõuded (MQ) Sõnumivahetuse mudelid Sõnumid Sõnumiserveri kanalid Sõnumi edastamine Ühenduskiht

REST API ja HTTP/JSON API rakenduste teenuste arendamise nõuded Kontekst Üldised nõuded API-le

Ressurside URL-i kujud Ressursside nimetamine Toimingud ressurssidega Otsingu tugi API ressurssides API ressursside/teenuste versioneerimine API veahaldus API rakenduse kättesaadavus Tuvastamine

SOAP teenuste arendamise nõuded SOAP teenuste tarbimise head tavad

Sünkroonne ja asünkroonne suhtlusviis Rakendused saavad omavahel suhelda s või :ünkroonselt asünkroonselt

S – teenuskutse tegija ootab seni kuni teenusepakkuja poolt on vastus saadaval. Samaaegselt võib toimuda üks toiming:ünkroonne suhtlemine

Üks laialdasemalt kasutatud suhtlusstiile; Kontseptuaalne lihtsus võimaldab hõlpsalt rakendada; Enamikes olukordades sobiv suhtlusstiil; Tihedalt seotud HTTP protokolliga, kuid on ka teisi protokolle, nt RPC; Sünkroonse integratsiooni puhul on eelistatud protokolliks HTTP ning andmeformaadiks JSON; SOAP/XML lahendusi kasutada ainult nö olemasolevate süsteemidega liidestamisel, kus muid võimalusi ei ole; Kasutada saab nii X-tee integratsiooni kui ka otse tehtavaid HTTP teenuseid; Kõige levinum stiil HTTP teenuse loomisel on , kuid on võimalus ka kasutada -i(ainult läbi eelneva kooskõlastuse) REST GraphQL

As – teenuskutse tegija ei oota teenusepakkuja poolt vastust. Samaaegselt võib toimuda mitu toimingut:ünkroonne suhtlemine ehk sõnumivahetus

Sobib hästi hajussüsteemi, -arhitektuuri jaoks; Teenused ei ole omavahel seotud, sest suhtlemiseks kasutatakse sõnumisiini, mis võimaldab rakenduste vahel sõnumeid vahetada. Andmevahetusformaadiks võib tekstiliste andmete puhul samuti eelistada JSON-it Andmevahetuseprotokollina on soovituslik kasutada AMQP protokolli

Allikas: Gupta, P. (05.06.2018). Patterns for Microservices – Sync vs. Async. DZone. https://dzone.com/articles/patterns-for-microservices-sync-vs-async

Integratsioon süsteemide vahel (nii välised kui sisemised)

Rakendusi omavahel integreerides peame peamiselt arvestama kolme aspekti. Kas kaks omavahel liidestavat komponenti on määratletud sama andmekogu alla, ehk toimub andmekogu sisene integratsioon või toimub andmekogu ülene integratsioon ning kas üks liidestavatest komponentidest asub välisperimeetris/õues (taotluskeskkonnad).

Andmekogu on see süsteem, mis on määrusega registreeritud, kui on segadus, konsulteeri oma tooteomanikuga.

Andmekogusiseseid integratsioone või liidestus lahendusega, mis ei kuulu ühegi andmekogu alla, võib teha nii sünkroonselt kui asünkroonselt ning ei pea kasutama X-TEEd; Andmekogude vahelisi integratsioone tohib teha ainult üle X-TEE ning tulenevalt X-TEE piirangutest, siis täna ainult sünkroonselt (lähtuda tuleb X-

;TEE dokumentatsioonist) Komponendid, mis asuvad välisperimeetris/õues (igasugu veebid, taotluskeskkonad jms), ei ole lubatud otse liidestuda sisemiste süsteemidega sh. X-TEE-ga (neil tuleb sisevõrku teha vaheadapter, mis päringud edastab); Kui andmekogu soovib andmeid pärida lahenduselt, mis ei kuulu andmekogusse, võib seda teha ilma X-TEEd kasutamata. Kui sisemine süsteem pärib andmekogu käest andmeid, tuleb kasutada X-TEEd. Välist rakendust disainides, tuleks pöörata tähelepanu, et selle mõju sisemistele komponentidele oleks minimaalne (turva, käideldavus, terviklikkus). Eriti arvesse võtta olukordi, kus väline rakendus võib rünnaku alla sattuda.

1. 2. 3.

Sõnumivahetuse nõuded (MQ)

Sõnumivahetuse mudelid

Lubatud on kasutada vastavalt vajadusele nii publish/subscribe (queue - järjekorrad), kui point-2-point (topic - teemad) mudelit.

Sõnumid

Kui ei ole määratud teisiti, on nõutud tekst tüüpi sõnumite kasutamine Kui sõnumi sisu on JSON dokument, tuleb seda valideerida kasutades json-schema validaatorit (https://github.com/fge/json-schema-validator) või sellega samaväärset lahendust Binaarkujul failide edastamiseks läbi sõnumite tuleb kasutada tekst tüüpi sõnumit, ning faili sisu lisada Base64 kodeeritud kujul Küsimus-vastus (request-response) tüüpi sõnumivahetuses tuleb küsimuse vastust identifitseerida korrelatsiooni identifikaatoriga (correlation-id)

Sõnumiserveri kanalid

Juhul kui kanalite nimetused ning nende sisu ei ole eelnevalt kokku lepitud, tuleb kasutatavate kanalite arv ning nimetused kooskõlastada SMIT- iga Juhul kui sõnumite sisu on XML dokument, tuleb kanalite nimed koos tema sisuga defineerida XML-i kirjeldavas dokumendis (XSD-s)

Sõnumi edastamine

Kanalite nimetuste nimekonventsioonina järgida üldjoontes malli: "[andmete omanik].[sõnumis olevad andmed]" näiteks: "amr.ametijuhend"

Küsimus-vastus (request-response) tüüpi sõnumivahetuse puhul lisada suffiksina kanalinimele vastavalt Request või Response - näide manuses näiteks "amr.ametijuhendRequest" ja "amr.ametijuhendResponse"

Sõnumiedastuse ühelt-mitmele (topic) puhul lisada suffiksina kanalinimele vastavalt Topic - näide manuses.  näiteks "amr.ametijuhendTopic"

Sõnumiedastuse ühelt-ühele, ilma vastust ootamata (queue) tüüpi sõnumivahetuse puhul lisada suffiksina kanalinimele vastavalt Queue - näide manuses

näiteks "amr.ametijuhendQueue"

Ühenduskiht

Juhul kui ole määratud teisiti, käib suhtlus sõnumiserveriga TCP tasemel (vm tase oleks kiire aga mõistlik on sõnumiserver hoida rakendusest väljaspool, et tagada käideldavus)

REST API ja HTTP/JSON API rakenduste teenuste arendamise nõuded

Kontekst

REST on arhiekturistiil, mis kirjeldab nõuded/piirangud rakenduste loomiseks, võttes aluseks veebiarhitektuuri (world-wide-web ehk www)

REST puhul on peamine informatsiooni abstraktsioon ressurss (ingl resource). Mistahes teave, mida saab nimetada, võib olla ressurss. (Fielding, 2000)

Ressurss varieerub ajas ning tähistab konkreetsel ajahetkel olemite kogumit või väärtusi (Fielding, 2000). Väärtused võivad olla ressursi esitused (ingl resource representation) ja/või ressursi identifikaatorid (ingl resource identifier). REST-komponendid, teisisõnu omavahel suhtlevad rakendused, teevad toiminguid ressurssidega, kasutades ressursi esitust praeguse või kavandatud oleku fikseerimiseks ja selle esituse ülekandmiseks rakenduste vahel. (Fielding, 2000)

Allikas: Fielding, R. T. (2000). Architectural Styles and the Design of Network-based Software Architectures. University of California, Irvine. https://www.ics. uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

Üldised nõuded API-le

API-del peaks olema loodud dokumentatsioon, mis sisaldab detailset api kirjeldust. Soovituslik on läheneda API-FIRST, ehk api kirjeldatakse ära ja siis luuakse implementatsioon.

Võib kasutada näiteks: https://swagger.io/

1. a.

2. a.

3. a.

4. a.

5. a.

1. a.

2. 3.

a.

1. a. b. c.

i. 1.

d. e.

1. a.

2. a. b.

1. 2. 3.

a.

1. a.

1.

API-i juures kasutatavatel andmekomplektidel (eeldatavasti siis JSON dokumendid) peaksid eksisteerima "schema" kirjeldused. Soovituslik on see teha API enda kirjelduse juures, kus saab API väljakutsed lihtsasti siduda "schema" objektidega.

Schemad on vajalikud nii kommunikeerimisel teiste osapooltega, kes API-t kasutavad, kui ka võimaldab luua paremini valideerimisloogikat lähtekoodis.

Ressurside URL-i kujud

/X - tagastab ressursi X massiivi. /persons

/X/{id} - tagastab konkreetse X ressursi id järgi /persons/1 - tagastab isiku 1

/X/Y - tagastab X listi, mida on filtreeritud Y järgi /persons/applications - üldiselt ei kasutata aga võiks tähendada: anna kõik isikud, kus on mõni taotlus küljes

/X/{id}/Y - tagastab ressursi Y listi, mis on X id-ga seotud /persons/1/applications - tagastab kõik isiku 1 taotlused 

/X/Y/{id} - tagastab X ressursi listi, mida on filtreeritud Y id järgi /applications/persons/1 - anna kõik isiku 1 taotlused

{id} ehk id kui path variable-ga identifitseeritakse ressursi

Ressursside nimetamine

Lihtsad ja arusaadavad ressursid vastavalt äriloogikale ja seostele Nt /persons/1/applications

Ressursi nimetus mitmuses väljendab, et ressurss on mitmuses Ressursside nimetamisel ei kasutata käske (nt )/getPersons või /createPerson ei ole õige

Ressursi nimetamise asemel väljendavad HTTP käsud/meetodid ressurssidega tehtavaid toiminguid (vt  )Toimingud ressurssidega

Toimingud ressurssidega

Ressursidega toiminguteks tuleb kasutada HTTP käske. Nt /persons puhul GET /persons - tagastab massiivi kõikidest isikutest POST /persons - loob uue isiku DELETE /persons - antud kontekstis vähetõenäoline kasutus, aga kustutab olemasolevad isikud ja nende seosed 

Sõltub ärivajadusest, kas rakenduses on otsustatud, et tegemist on loogilise või füüsilise kustutamisega Mitte kasutada DELETE-i loogiliseks JA füüsiliseks kustutamiseks ilma, et API ressurss väljendaks, millega täpselt tegemist

PUT /persons - antud kontekstis vähetõenäoline kasutus, aga asendab kõik olemasolevad kirjed PUT teenuskutse sisendiga täies mahus PATCH /persons - antud kontekstis vähetõenäoline kasutus, aga asendab kõikidel olemasolevatel kirjetel PATCH teenuskutse sisendiga antud konkreetsete väljade väärtused

Otsingu tugi API ressurssides

Kui tahta sorteerida, filtreerida, otsida, siis kasutada query parameetrit ehk päringu keerukus viia ‘?’ taha Nt GET /persons?name=X&age=Y

Kui API võib tagastada pikki nimekirku, siis tuleb kindlasti kasutada osade kaupa küsimist (ingl )pagination/paging Nt /persons?limit=25&offset=50 vaikimisi limit=10 ja offset=0

API ressursside/teenuste versioneerimine

API versioonimine on loomulik API muutuste juhtimise osa

Iga kasutuses oleva API muudatus peab olema tagasiühilduv Uus versioon tuleb luua nt kui muudetakse API sisendi/väljundi struktuuri; eemaldatakse mõni väli Uue versiooni loomisel peab eelmine versioon toetatud olema

Vanade versioonide eemaldamine eeldab tarbijatega kokkulepet ja vastavat protsessi/reeglistikku

Näide -

Versiooninimes kasutada v eesliidet ning väikeste versioonide asemel kasutada suuri versiooni numbreid, nt v1, v2, v3 Versiooninumber tuleb hoida URL-i sees kõige vasakul pool: /v1/persons

: Kõige lihtsam versioonimine, aga Märkus ei ole REST arhitektuuristiiliga kooskõlas

API veahaldus

API rakenduses peab olema lahendatud, kuidas vigu hallatakse ning neid tarbijatele väljastatakse

1.

1. a.

Luua korrektne veahaldus HTTP koodide põhiselt (seda mõistavad hästi ka teised süsteemid)                 200 - OK                 400 - Bad Request from client                 500 - Internal Server Error                 304 - Not Modified                 404 – Not Found                 401 - Unauthorized                 403 - Forbidden                 Lisaks veakoodile lisada ka detailsem veateade                 {"status" : "401", "message":"Authentication Required","code": 20003}

API rakenduse kättesaadavus

Kogu rakenduse API võiks kättesaadav olla eraldi domeeninime või kausta alt Nt api.rakendus.smit või rakendus.smit/api/

Tuvastamine Tuvastamist või isikustatud päringute tegemisel, peab identifitseerimist määratleb token (JWT) või vastav räsi minema HTTP päringu päisess (headers).

SOAP teenuste arendamise nõuded  Liidesed luuakse   põhimõttel kasutades SOAP Document Literal sõnumivahetuse põhimõtet;Contract-First XSD-sse peab saama sisse viia uuendusi, ilma et olemasolevate kasutamine oleks häiritud;

Nõuded XML schemale:

Complex Type definitsioonid:

tohivad sisaldada ainult   tüüpi   komponenti kordsustega minOccurs="1" ja maxOccurs="1".sequence model group ei tohi sisaldada atribuutide deklaratsioone. liik ( ) peab olema  .variety element-only

Sequence peab koosnema kas:

ühest   deklaratsioonist kordsustega   ja element minOccurs="0" maxOccurs="unbounded" nullist või rohkemast   deklaratsioonist minimaalse kordsusega   või  , maksimaalse kordusega element minOccurs="0" minOccurs="1" maxOccurs="

 ning lõppema   deklaratsiooniga atribuutidega processContents="lax" minOccurs="0" maxOccurs="unbounded" namespace="##any".1" any

Näide

<?xml version="1.0" encoding="UTF-8"?> <xs:schema targetNamespace="http://ametnik.smit/services" xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormD efault="qualified" xmlns:veeb="http://ametnik.smit/services" xmlns:smit="http://ametnik.smit/smit">

<xs:annotation> <xs:documentation xml:lang="et"> Näitedokumendi dokumentatsioon (seletav ja kirjeldav tekst) </xs:documentation> </xs:annotation>

<xs:complexType name="Ametijuhend"> <xs:sequence> <xs:element name="isikukood" type=" "xs:string /> <xs:element name="failiNimi" type=" "xs:string /> <xs:element name="failiSuurus" type=" "xs:int /> <xs:element name="failiLaiend" type=" "xs:string /> <xs:element name="fail" type=" "xs:base64Binary /> </xs:sequence> </xs:complexType>

Struktuur kus viimane element on kordsusega ei ole XML Schema 1.0 nõuete alusel deklaratsioon lubatud minOccurs="0" any Unique Particle reegli tõttu. Vastavat reeglit on korrigeeritud XML Schema 1.1 versioonis. Juhul kui tööriistad ei toeta vastavat deklaratsiooni võib Attribution

selle ära jätta eeldusel et on tagatud selle eesmärk - vastuvõtjale tundmatute elementide lisamine struktuuri lõppu ei põhjusta vastuvõtjas valideerimisviga.

<xs:element name="AmetijuhendRequest"> <xs:annotation> <xs:documentation xml:lang="et"> Ametijuhendi(te) pärimiseks vajaliku sõnumi element. </xs:documentation> <xs:appinfo> <smit:queue>amr.ametijuhendRequest</smit:queue> </xs:appinfo> </xs:annotation> <xs:complexType> <xs:sequence> <xs:element name="asutusId" type=" "xs:integer /> <xs:element name="aktiivsedOnly" type=" "xs:boolean /> <xs:element name="isikukood" type=" "xs:string minOccurs="0" /> <xs:element name="yksusId" type=" "xs:integer minOccurs="0" /> <xs:element name="muudetudAlates" type=" "xs:date minOccurs="0" /> <xs:element name="muudetudKuni" type=" "xs:date minOccurs="0" /> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="AmetijuhendResponse"> <xs:annotation> <xs:documentation xml:lang="et"> Ametijuhendi(te) päringu vastusena tagstatav sõnumi element. </xs:documentation> <xs:appinfo> <smit:queue>amr.ametijuhendResponse</smit:queue> </xs:appinfo> </xs:annotation>

<xs:complexType> <xs:sequence> <xs:element name="Ametijuhend" type="veeb:Ametijuhend" minOccurs="0"/> </xs:sequence> </xs:complexType> </xs:element>

<xs:element name="AmetijuhendTopic"> <xs:annotation> <xs:appinfo> <smit:topic>amr.ametijuhendTopic</smit:topic> </xs:appinfo> <xs:documentation xml:lang="et"> Ametijuhendi(te) uuenemisel publitseeritava sõnumi sisu </xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence> <xs:element name="Ametijuhend" type="veeb:Ametijuhend" minOccurs="0"/> </xs:sequence> </xs:complexType> </xs:element>

<xs:element name="AmetijuhendQueue"> <xs:annotation> <xs:appinfo> <smit:queue>amr.ametijuhendQueue</smit:queue> </xs:appinfo> <xs:documentation xml:lang="et"> Ametijuhendi(te) uuenemisel publitseeritava sõnumi sisu </xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence> <xs:element name="Ametijuhend" type="veeb:Ametijuhend" minOccurs="0"/> </xs:sequence> </xs:complexType> </xs:element>

</xs:schema>

SOAP teenuste tarbimise head tavad

1.

2. 3.

Nt Java puhul dünaamilise keele (nt Groovy) kasutamine SOAP päringute/vastuste konverteerimiseks selle asemel, et WSDL-ist klasse genereerida ning tekitada töömahtu ja pallastkoodi. Näidis SOAP-ist andmete kättesaamiseks: https://stackoverflow.com/questions/39526932/groovy-parse-soap-response-xml-to-get-data Näidis SOAP päringute koostamiseks: https://stackoverflow.com/questions/42290675/groovy-markupbuilder-how-to-create-markup-and-append- string

Tehnilised nõuded tarkvaralahendustele

Need nõuded määratlevad millele peaksid loodavad tarkvara komponendid vastama, et nad ei

oleks infrastruktuurist jäigalt sõltuvates, töötaksid SMIT majutusplatvormil, nende skaleerimist

ja paigaldamist saaks automatiseerida ning tehnoloogiline võlg oleks hallatav ja mõõdetav.

Arhitektuurinõuded ja infrastruktuuriotsused

1. Üldine

Nr Nõue Kohustuslik Märkused ja lingid

1.1

Rakendused luuakse "bounded

context" põhimõttel - ühte

komponenti ei panda sisult

erinevat funktsionaalsust

KOHUSTUS

Komponentideks jaotamine toimub

sisulistest, mitte tehnilistest

funktsionaalsustest lähtudes v.a

kasutajaliideste eraldamine. Vältida

hajust monoliiti. Vt: Microservices,

Bounded Context, Microservices Pitfalls

1.2

Komponent peab jooksma

vähemalt 2 instantsi peal

platvormi katkestuste

vältimiseks

KOHUSTUS

Konteinerplatvormile paigaldatud

rakenduste puhul minimaalselt 2

instantsi toodangus. Eelistada

komponentide hulga tõstmist, mitte

ressursikasutuse tõstmist

1.3

Ehitamine SMIT CI/CD-ga

(Bamboo), staatilise koodi

analüüs SonarQube-ga

KOHUSTUS

Lähtekood ei tohi sisaldada analüsaatori

poolt leitud vigu. Minimaalne

vaikeprofiil. Vt: "Tehnoloogilise võla

mõõtmine (SonarQube)" dok

1.4

Rakenduse lähtekood kirjutatud

selgusega, mis võimaldab

erialast ettevalmistust omaval

tarkvaraarendajal süsteemi

edasi arendada

KOHUSTUS

Rakenduse lähtekood ja kommentaarid

peavad olema inglise keeles. Rakenduse

ärilised muutujad aga eesti keeles, kui

neile pole mõlemapoolset loogilist

vastet

1.5

Rakenduse lähtekoodi haldus

toimib SMIT kesksete

versioonihalduspõhimõtete

järgi

KOHUSTUS

Kehtib nii loogika kui kasutajaliidese

komponendi puhul. Lisainfo leiab

dokumendist: "Lähtekoodi halduse ja

ehitamise nõuded"

1.6

Keskkondadesse rakenduste

paigaldamine on

automatiseeritud SMIT CI/CD

mehhanismidega

KOHUSTUS Kasutatakse Bamboo paigaldusplaane:

Bamboo Deployment Projects

Nr Nõue Kohustuslik Märkused ja lingid

1.7

Rakendustel puudub ligipääs

avalikku internetti (sh

klientidel)

KOHUSTUS

Kui on vajalik ligipääs äriandmetele

väljaspool SMIT võrku, tuleb tellida

"webproxy" ligipääs

1.8

Kõik välised sõltuvused tuleb

rakenduse ehitamisprotsessi

käigus läbi skaneerida

Artifactory Xray töövahendiga

KOHUSTUS

Mitte kasutada kõrge kriitilisusega

turvanõrkuseid sisaldavaid

teeke/komponente. JFrog CLI for Xray

1.9

Rakenduse arhitektuuri

koostamisel tuleks arvestada, et

komponente peab saama

uuendada iseseisvalt

Soovituslik Soovituslik kasutada "Blue-Green"

paigalduspõhimõtteid

1.10

Rakendustevahelisi

integratsioone teostatakse

kokkulepitud põhimõtete järgi

KOHUSTUS

Võimalikud variandid: XTEE, HTTP

otse või MQ. Integratsioonide disainis

lähtuda dokumendist:

"Rakendustevahelised

integratsioonipõhimõtted"

1.11

API spetsifikatsioonid peavad

olema kättesaadavad

kolmandatele osapooltele

KOHUSTUS

OpenAPI/Swagger spetsifikatsioon peab

olema eraldi ligipääsetav

välispartneritele integratsioonide jaoks.

Versiooninumber võib olla kas päises

või URI-s. Teenuse tehnilises

dokumentatsioonis peab olema viide

OpenAPI spetsifikatsionile

(SwaggerUI). API disainimisel tuleb

lähtuda dokumendist:

"Rakendustevahelised

integratsioonipõhimõtted"

1.12

Kui loodav lahendus koosneb

mitmest komponendist, on need

lahus arendatavad,

pakendatavad, versioneeritavad

ja paigaldatavad

KOHUSTUS Võimaldab erinevate komponentide

iseseisvat arendamist ja paigaldamist

1.13 Rakendused automaatselt

monitooritud toodangus KOHUSTUS

Toodangu keskkondades on automaatne

monitooring kohustuslik

1.14

Kasuta SMIT raamistike

põhjasid uute komponentide

jaoks

KOHUSTUS

Erandid nõuavad arhitektuurinõukogu

heakskiitu. Kasuta SMIT Examples

starterkit malle. Kui sobilikku põhja ei

eksisteeri, tuleb selle minimaalne

versioon projekti käigus tekitada

Nr Nõue Kohustuslik Märkused ja lingid

1.15

Rakendus on versioneeritud

kasutades "semantic

versioning" põhimõtet

KOHUSTUS

A.B.C kujul, kus C on veaparandus, B

on funktsionaalne uuendus mis töötab

vanematel integratsioonidel ja A on

integratsioone potentsiaalselt lõhkuv

uuendus. Versiooni suurt numbrit A

kasutatakse ka API versiooni

defineerimiseks. Vt: Semantic

Versioning. Soovitus: major versiooni

uuendamisel tagastada vanema

versiooniga teenused päises X-API-

Deprecated

1.16

Ehitamise, reliisimise ja

paigaldamise etapid on rangelt

eraldatud

KOHUSTUS

Ehitamine toodab muutumatu artefakti,

reliis laeb artifakti ülesse, paigaldamine

kombineerib artifakti konfiguratisooniga

ja käivitab keskonnas. Iga etapp peab

olema iseseisev ja korratav. Vt: "12-

Factor Build Release Run"

1.17

Komponendid peavad

käivituma kiiresti ja sulguma

korrektselt (graceful shutdown)

KOHUSTUS

Käivitusaeg maksimaalselt 60 sekundit,

korrektne sulgumine SIGTERM signaali

peale. Komponendid peavad olema

"disposable" - saab igal hetkel peatada

ja käivitada. Toetab kiiremat

skaleerimist ja paigaldamist

1.18

Üks lähtekood repositoorium

komponendi kohta - kõik

keskkonnad paigaldatakse

samast koodist

KOHUSTUS

Iga komponent peab omama ühte Git

repositooriumit. Erinevad keskkonnad

(arendus, test, toodang) kasutatavad

sama lähtekoodi, kuid erinevat

konfiguratsiooni. Git "branching"

strateegia peab toetama sellist

lähenemist

1.19

Kõik sõltuvused tuleb

deklareerida spetsfiiliselt ja

isoleerida

KOHUSTUS

Komponendid ei tohi sõltuda süsteemi-

laadsetes teekidest. Kasutada

"dependency manifest" faile ja

lukustatud versioone reprodutseeritavate

ehituste jaoks. Isoleerida sõltuvused

konteinerite või virtuaalsete

keskkondadega

Nr Nõue Kohustuslik Märkused ja lingid

1.20

Administratiivsed ülesanded

käivitatakse eraldi

protsessidena

KOHUSTUS

Andmebaasi migratsioonid,

ühekordased skriptid ja muud

administratiivsed toimingud peavad

töötama eraldi komponent

põhiprotsessidest. Admin ülesanded

kasutavad sama koodi baasi, kuid

käivitatakse eraldi

1.21

Komponendid peavad olema

iseseisavad ja eksportima

teenuseid pordi sidumise kaudu

KOHUSTUS

Komponendid ei tohi sõltuda välisest

runtime serverist (Apache, Nginx). Iga

komponent peab sisaldama oma HTTP

serverit ja siduma end konfigureeritava

pordi külge. Toetab mitme instantsi

käivitamist samal masinal

1.22

Kasutamata kood ja välja

kommenteeritud kood tuleb

koodibaasist eemaldada

KOHUSTUS

Hoia kood puhas: eemalda "dead code"

ja välja kommenteeritud plokid; koodi

taastamiseks kasuta Git ajalugu, mitte

kommenteeritud fragmente. Vastavus

SonarQube "commented-out code" ja

kasutamata koodi reeglitele

2. Testimine

Nr Nõue Kohustuslik Märkused ja lingid

2.1 Minimaalne testandmete

genereerimise võimekus Soovituslik

Peamiselt koormustestide või "smoke" testide

keskkondade jaoks

2.2

Test- ja

toodangukeskkonnad

eraldatud

KOHUSTUS

Testandmed ei tohi olla toodanguandmed

(välja arvatud avalikud andmed nagu

aadressid)

2.3

Kasutajaliidese

automaattestide (E2E)

kirjutamine on

arendusmeeskonna

otsustada

Soovituslik Testide loomisel on soovitav kasutada ilma

kasutajaliideta sirvijat ("headless" brauserid)

2.4

Rakenduse

automaattestide mahtu

tuleb analüüsida CI/CD

mehhanismidega ja

publitseerida SMIT

SonarQube keskkonnas

KOHUSTUS

Testide mahu miinimum määratakse

SonarQube kvaliteediväravaga (reeglina 80%

kogu koodist)

Nr Nõue Kohustuslik Märkused ja lingid

2.5

Testikattuvus peab olema

vähemalt 80% kogu

koodist

KOHUSTUS

Testikattuvuse miinimum jõustatakse

SonarQube kvaliteediväravaga. Erandid või

madalama läve kasutamine tuleb

arhitektuurinõukogus kooskõlastada.

Staatilised HTML ja stiilifailid

(CSS/SCSS/SASS) võib testikattuvuse

arvutusest välja jätta, kuna nende eraldi

testimine on raskendatud; soovitatav on

kasutada SonarQube

sonar.coverage.exclusions sätteid

2.6 Turvatestid avalike

teenuste jaoks KOHUSTUS

Turvatestide juhendid ja nõuded leiab

dokumendist: "Turvatestimine"

2.7

Rakenduste poolt

toodetavale logi väljundile

tuleb kirjutada

automaattestid

KOHUSTUS

Testid peavad veenduma, et rakenduses

genereeritud logi vastab "Logimise nõuded"

dokumendis kirjeldatud nõuetele

3. Kasutajaliides

Nr Nõue Kohustuslik Märkused ja lingid

3.1 Kasutajaliides võib korraga suhelda mitme

loogikakomponendiga Soovituslik

Võimaldab paindlikku

arhitektuuri disaini

3.2 Kasutajaliides on soovitav arendada õhukese

kliendina Soovituslik

Thin client arhitektuuri

eelistamine

3.3

Avalikud kasutajaliidesed peavad järgima

VEERA disainistandardit ning omama WCAG

tuge

Soovituslik Vajadusel kohaldatav

avalike teenuste puhul

4. Infrastruktuur ja paigaldamine

Nr Nõue Kohustuslik Märkused ja lingid

4.1

Rakendused peavad

jooksma vähemalt 2

instantsi peal

KOHUSTUS

Platvormi muudatuste käigus katkestuste

vältimine. Konteinerplatvormil minimaalselt

2 instantsi toodangus

Nr Nõue Kohustuslik Märkused ja lingid

4.2

Komponendid peavad

olema iseseisvalt

arendatavad,

pakendatavad,

versioneeritavad ja

paigaldatavad

KOHUSTUS Võimaldab sõltumatut arendust ja

paigaldamist

4.3

Komponendid suhtlevad

omavahel ainult üle

HTTP/HTTPS või

JMS/AMPQ protokolli

KOHUSTUS Soovitus kasutada protokolle üle turvalise

kanali (HTTPS/AMPQS)

4.4

Iga komponent peab

omama oma andmebaasi,

kui vajab andmete

salvestamist

KOHUSTUS

Andmebaasidevahelised integratsioonid on

keelatud. Mitu komponenti ei tohi kasutada

sama andmebaasi

4.5

Kasutada eraldi failide

hoidmise teenust

binaarfailide jaoks

KOHUSTUS SMIT-is on selleks olemas sisemine S3

objektihoidla

4.6 Toetada horisontaalset

skaleerimist KOHUSTUS

Suurendada instantside arvu, mitte ressursse

instantsi kohta

4.7

Komponent käivitub ilma

ühenduseta liidestetavate

süsteemidega

KOHUSTUS Nõrgalt liidestatud, välja arvatud

andmebaasid

4.8

Komponent töötab

osaliselt ka liidestuste

katkestuste puhul

KOHUSTUS

Kasutada Circuit Breaker või retry

mehhanisme. Healthcheck peab andma teada

probleemist

4.9 Komponentide käivitusaeg

peab olema alla 60 sekundi KOHUSTUS

Kiire käivitamine skaleerimise ja

taaskäivitamise jaoks

4.10 Kasutada SSL kõigile UI-

backend suhtlustele KOHUSTUS SSL termineeritakse koormusjaoturis

4.11 Kasutada distribueeritud

vahemälulahendusi KOHUSTUS

Vältida vahemälu replikatsiooni, kasutada nt.

Redis või andmebaasi

4.12

Konfiguratsioon

keskkonna muutujatena

või platvormi

võimalustega

KOHUSTUS

Puudub eraldi väline konfiguratsioonifail.

Kasutada Kubernetes secrets/configmap.

Rakenduse saladused, mida ei genereerita

teenuste poolt automaatselt, panna SMIT

saladuste hoidlasse. Saladused liiguvad

rakendusse ainult läbi CI/CD

Nr Nõue Kohustuslik Märkused ja lingid

4.13

Komponendi pakendamine

Docker konteinerina SMIT

baasimageidega

Soovituslik

Soovituslik pakendamisformaat on Docker

konteiner. Kasutada ainult SMIT

dockerhubis asuvaid baasimageid: SMIT

DockerHub

4.14 Failid tuleb skaneerida

enne salvestamist KOHUSTUS Kasutada SMIT MetaVault teenust

5. Sõltuvuste haldamine

Nr Nõue Kohustuslik Märkused ja lingid

5.1

Kõik sõltuvused tuleb

lahendada SMIT sisesest

repositooriumist

KOHUSTUS

SMIT Artifactory. Ei tohi kasutada

väliseid repositooriume (Maven Central,

NPM, PyPI) otse

5.2 Konfigureerida ehitusvahendid

kasutama SMIT repositooriumi KOHUSTUS

Kõik välised sõltuvused peavad olema

Artifactory kaudu kättesaadavad

6. Äriloogika

Nr Nõue Kohustuslik Märkused ja lingid

6.1

Komponentide vaheline

andmevahetus peab olema

turvaline TLS-iga,

sertifikaate verifitseeritakse

Soovituslik

Autentimata ja/või krüpteerimata protokollide

kasutamisel rakendatakse täiendavaid

konfidentsiaalsust ja terviklust tagavaid

turvameetmeid

6.2 Kasuta SMIT keskset

tuvastamise teenust (UAA) KOHUSTUS

UAA integreeritud RIA Taraga ID-kaart,

mobiil-ID, Smart-ID jaoks. UAA API Docs.

Väliste kasutajate puhul kasuta e-posti põhist

OTP-d

6.3

Kasutajate ja nende

gruppide/rollipõhiste

õiguste tuvastamine

kesksest Active Directory-

st

KOHUSTUS

Vähemalt üks AD roll peab asuma AD-s (ja

vastav UAA skoop). AD gruppidest võetakse

info ja lisatakse UAA tokeni skoopi.

Andmetepõhised õigused (ACL) asuvad

rakenduse andmebaasis

6.4 Iga komponent peab

omama oma kontot KOHUSTUS

Ei tohi taaskasutada kontosid, mis on

väljastatud teistele rakendustele

Nr Nõue Kohustuslik Märkused ja lingid

6.5

Komponendid peavad

saama omavahel

autoriseerituna andmeid

vahetada kasutades

tokeneid

KOHUSTUS

Kahe komponendi vaheliseks

andmevahetuseks, mis ei toimu lõppkasutaja

kontekstis, tuleb kasutada SVC tüüpi

süsteemikontosid ADs lisatud vajalike

skoopidega

6.6

Tuvastatud kasutajal peab

eksisteerima serveripoolne

sessioon keskses hoidlas

KOHUSTUS

Kasutada ainult OAuth2 Authorization Code

mehhanismi. Keskse seansi hoidlana Redis

või PostgreSQL. Klient peab saama tokeniga

seotud info kustutada. Mitmest komponendist

koosneva rakenduse puhul kasutada API

gateway sessioonihaldajana

6.7

Komponendi

versiooniuuendused

tehakse ilma katkestusteta

teenuse töös

Soovituslik

Soovitav "Blue-Green deployment"

mehhanism. Blue-Green Deployment.

Andmebaasi muudatuste tegemisel tagada

töötamine ka eelmiste versioonidega

6.8

Töövoogude

koordineerimisel kasutada

protsessimootorit

Soovituslik

Tagab protsesside parema läbipaistvuse ja

modelleerimisvõimekuse. Näiteks Camunda

või Flowable

6.9

Kasutada välist ACL

süsteemi õiguste

haldamiseks

Soovituslik Keskne õiguste haldus ja auditeeritavus.

Näiteks Permify või sarnased lahendused

7. Andmebaas

Nr Nõue Kohustuslik Märkused ja lingid

7.1 Eraldi operatiiv- ja arhiiv

andmebaasid KOHUSTUS

Kasuta eraldi arhiivandmebaase või

spetsialiseeritud arhiveerimislahendusi

7.2

Andmebaaside vahelised

integratsioonid ei ole

lubatud

KOHUSTUS Erinevad andmebaasid ei tohi omavahel

integreeruda

7.3

Andmebaase komponentide

integratsioonivahendina ei

tohi kasutada

KOHUSTUS

Mitu erinevat komponenti ühe andmebaasi

poole pöörduda ei ole lubatud. See ei

tähenda, et sama komponenti skaleerides ei

võiks kasutada sama andmebaasi

Nr Nõue Kohustuslik Märkused ja lingid

7.4

Migratsiooniskriptide

käivitamine

paigaldusprotsessi osana

KOHUSTUS

Migratsioone on soovitav käivitada

paigaldusprotsessi ühe osana, mitte iga

rakenduse restardiga. Kõige lihtsam variant

on määrata CI/CD keskkonna muutujaga.

Mõistlik on migratsiooni teha ühe

instantsiga, siis vajadusel uuesti paigaldus

mitme instantsiga

7.5

Andmebaasi äriloogikat

vaikimisi ei kirjutata

(protseduurid ja triggerid)

KOHUSTUS

Kõrvalekalded tuleb defineerida ja

põhjendada konkreetse komponendi

arhitektuuridokumendis

8. Jõudlus

Nr Nõue Kohustuslik Märkused ja lingid

8.1

Sisemised komponendid

kasutavad asünkroonset

suhtlust

Soovituslik

Blokeeruvate lõimede vältimine ja efektiivne

protsessorituumade kasutamine. Erand:

kasutaja transaktsioonisisene suhtlus. Vt: 12

Factor Concurrency, Reactive Manifesto

8.2

Jõudluse kasvamisel

horisontaalne skaleerimine

(instantside hulga

tõstmine)

KOHUSTUS Ei tohiks kasutada "scale-up" lahendust, kui

seda ei määra konkreetne toote pakkuja

8.3

Mitte-operatiivsed

lugemispäringud suunata

võimalusel andmebaasi

replikatele

Soovituslik

Vähendab peaandmebaasi koormust ja

parandab jõudlust. Rakendada read-only

operatsioonide jaoks

9. Monitooring ja jälgimine

Nr Nõue Kohustuslik Märkused ja lingid

9.1

Komponentide

monitooringu info

kättesaadavus kokkulepitud

formaadis ja protokolliga

KOHUSTUS

Soovitavalt REST formaadis.

Koormusjaotur peab aru saama, kas suunata

liiklus konkreetsele nodele. Näide: Spring

Boot Actuator endpoint /health. Spring Boot

Health

9.2

Rakendused automaatselt

monitooritud toodangus

APM tarkvara agentidega

KOHUSTUS

Monitooringu seadistamine ja haldamine.

Toetatud tehnoloogiad: AppDynamics

Supported Environments

10. Failid

Nr Nõue Kohustuslik Märkused ja lingid

10.1 Failide skaneerimine enne salvestamist

andmebaasi või objektihoidlasse KOHUSTUS

Kasutada tuleb SMIT-i poolt

pakutavat MetaVault teenust

11. Taaskasutus

Nr Nõue Kohustuslik Märkused ja lingid

11.1

Kontrollida enne uue komponendi

arendamist SMIT-is olemasolevaid

lahendusi

KOHUSTUS

Eelistada olemasolevaid

lahendusi teenusena või

paigaldatava tootena

11.2

Olemasoleva teenuse koodi

eraldamine eraldi projektiks vajab

arhitektuuripaneeli heakskiitu

KOHUSTUS Eelnev diskussioon olemasoleva

tiimiga soovitatav

11.3

Teenuste puhul väljaspool konkreetset

infosüsteemi luua iseseisev tehnilise

liidestuse võimekus

Soovituslik Nt Kubernetes Operator:

operatorframework.io

12. Arvutitöökoht

Nr Nõue Kohustuslik Märkused ja lingid

12.1 Uued seadmed peavad olema

Windows või iOS põhised KOHUSTUS

Toetatud seadmetüübid

organisatsiooni IT-poliitika

kohaselt

12.2 Rakendus võimeline väikeste

versioonide iseuuendamiseks KOHUSTUS

Võimaldab automaatseid

väiksemaid uuendusi ilma IT-toe

sekkumiseta

12.3 Paigaldus ei tohi keelata arvuti

teenuseid KOHUSTUS

Näide: DocCheck keelas ID kaardi

sertifikaaditeenuse

12.4

Toetada kõiki heakskiidetud

brausereid, mitte seotud konkreetse

versiooniga

KOHUSTUS Kõik brauserid tehnoloogiavaliku

lehelt peavad olema toetatud

12.5 Tarkvara ja konfiguratsiooni tarne

ATKH-le töökoha paigaldamiseks KOHUSTUS

Arendus peab andma tarkvara +

konfiguratsiooni ATKH-le

12.6 Domeeni valideerimine

standard/erilises ATK profiilis KOHUSTUS

Domeen peab valideeruma

standard ATK profiilis või SMIT

erilises profiilis

Nr Nõue Kohustuslik Märkused ja lingid

12.7 Rakendus peab olema käsurealt

paigaldatav KOHUSTUS

Võimaldab automatiseeritud

paigaldamist ja masshaldust

12.8 Rakendus ei tohi nõuda

administraatoriõigusi kasutamiseks KOHUSTUS

Tavakasutaja peab saama

rakendust kasutada ilma

kõrgendatud õigusteta

12.9 Veebirakendused peavad toetama

Chrome'i ja Firefoxi sisevõrgus KOHUSTUS

Minimaalne brauserite tugi

organisatsiooni sisevõrgus

LEPING nr 3-3/4095

Siseministeeriumi infotehnoloogia- ja arenduskeskus (SMIT või Tellija), registrikood

70008440, aadress Mäealuse 2/2, 12618, Tallinn, keda esindab põhimääruse alusel peadirektor

Kirke Saar

ja

SRINI OÜ (Täitja 1), registrikood 14449790, aadress A. H. Tammsaare tee 56, 11316 Tallinn,

keda esindab põhikirja alusel juhatuse liige Mattias Mölder või René Oruman;

Webquer OÜ (Täitja 2), registrikood 16234220, aadress Lepiku tee 25, 11913 Tallinn, keda

esindab põhikirja alusel juhatuse liige Helena Eiland;

Ühispakkujad Osaühing ALPHAGIS, registrikood 11026468, aadress Veerenni tn 40a, 10138

Tallinn, keda esindab ühispakkujate volikirja alusel juhatuse liige Sergei Fedulov, ja OSAÜHING

LOREX-GRUPP, registrikood 10568121, aadress Kabli tn 5-2, 13516 Tallinn (Täitja 3), keda

esindab põhikirja alusel juhatuse liige Sergei Fedulov;

OÜ Quretec (Täitja 4), registrikood 11043739, aadress Ülikooli 6a, 51003 Tartu, keda esindab

põhikirja alusel juhatuse liige Margus Jäger;

FINEST AS (Täitja 5), registrikood 10714404, aadress Tartu mnt 80D, 10112 Tallinn, keda

esindab põhikirja alusel juhatuse liige Jan Urva;

Trinidad Wiseman OÜ (Täitja 6), registrikood 11244225, aadress Meistri 14, 13517 Tallinn,

keda esindab põhikirja alusel juhatuse liige Marko Leppik;

osaühing Elvior (Täitja 7), registrikood 10031987, aadress Mäealuse 2/4, 12618 Tallinn, keda

esindab põhikirja alusel juhatuse liige Margus Metsanurm;

Wisercat Software OÜ (Täitja 8), registrikood 11664849, aadress Lelle tn 24, 11318 Tallinn,

keda esindab põhikirja alusel juhatuse liige Anatoli Derõšev;

Askend Estonia OÜ (Täitja 9), registrikood 14133207, aadress Tartu mnt 80f, 10112 Tallinn,

keda esindab põhikirja alusel juhatuse liige Vassili Ljahhovets;

2(14)

Aktsiaselts Datel (Täitja 10), registrikood 10324057, aadress Endla 4, 10142 Tallinn, keda

esindavad põhikirja alusel juhatuse liikmed Urmas Kõlli ja Volle Vint;

CGI Eesti OÜ (Täitja 11), registrikood 10006966, aadress A. H. Tammsaare tee 56, 11316

Tallinn, keda esindab põhikirja alusel juhatuse liige Andres Birnbaum;

POSITIUM OÜ (Täitja 12), registrikood 10883762, aadress Soola 8, 51004 Tartu, keda esindab

põhikirja alusel juhatuse liige Gerttu Pilsas;

Solutional OÜ (Täitja 13), registrikood 14917587, aadress Kaselaane põik 8/1-14, 76401 Laagri

alevik, keda esindab põhikirja alusel juhatuse liige Kristjan Kokk;

BigEye OÜ (Täitja 14), registrikood 16140329, aadress Lääneringtee 39, 51006 Tartu, keda

esindab põhikirja alusel juhatuse liige Lauri Kepler.

1. Üldised tingimused

1.1 Käesolev leping sõlmitakse riigihangete seaduse alusel läbi viidud riigihanke

„Ruumiandmete halduse platvormi ja sellega seonduvate süsteemide arendustööd“

(viitenumber 303276) alusdokumentide ja täitja 1 04.03.2026 pakkumuse, täitja 2

05.03.2026 pakkumuse, täitja 3 04.03.2026 pakkumuse, täitja 4 03.03.2026 pakkumuse,

täitja 5 03.03.2026 pakkumuse, täitja 6 03.03.2026 pakkumuse, täitja 7 04.03.2026

pakkumuse, täitja 8 19.02.2026 pakkumuse, täitja 9 04.03.2026 pakkumuse, täitja 10

04.03.2026 pakkumuse, täitja 11 25.02.2026 pakkumuse, täitja 12 26.02.2026 pakkumuse,

täitja 13 04.03.2026 pakkumuse ja täitja 14 05.03.2026 pakkumuse alusel.

1.2 Raamlepingus kehtestatakse lepingu kehtivusaja vältel selle alusel sõlmitavaid

hankelepinguid reguleerivad üldised tingimused, täpsemad tingimused lepitakse kokku

hankelepingus.

1.3 Raamlepingul põhinev hankeleping sõlmitakse raamlepingu poolteks olevate täitjate vahel

raamlepingus sätestatud korras korraldatud minikonkursi tulemusena.

1.4 Raamleping ei kohusta tellijat täitja(te)lt teenust tellima. Tellijal on õigus raamlepingu

kehtivuse jooksul otsustada, millises mahus ta teenust tellib. Tellijal on õigus tellida teenust

ka teistelt võimalikelt teenusepakkujatelt.

1.5 Raamlepingu juurde kuuluvateks lahutamatuteks osadeks loetakse kõik lisad ja riigihanke

alusdokumendid, tellija antud selgitused ning täitja(te) riigihankes esitatud pakkumused ja

pooltevahelised kirjalikud teated, mida raamlepingu lisadena eraldi ei allkirjastata.

1.6 Kui hankelepingu tingimus erineb raamlepingu tingimusest, loetakse ülimuslikuks

hankelepingu tingimus.

1.7 Raamlepingu täitmise käigus võib kokku leppida täiendavaid hankelepingute tingimusi, kui

need on vajalikud välisvahendite rakendamisest tulenevate nõuete täitmiseks.

1.8 Kui hankelepingu alusel teostatavaid töid rahastatakse välisvahenditest, on täitjal kohustus

järgida hankelepingus teatavaks tehtud välisvahendite kasutamisest tulenevaid nõudeid, sh

kasutada projekti tingimustes nõutud sümboolikat.

1.9 Lepingu täitmise keel on eesti keel, muuhulgas on see ka hankelepingute sõlmimise,

töökoosolekute jm suhtluse ning tööde dokumenteerimise keel.

1.10 Raamlepingule ja hankelepingule kohaldatakse SMIT töövõtu-, käsundus- ja

müügilepingute üldtingimusi, mis on kättesaadavad: https://www.smit.ee/files/2025-

11/smiti-kaesundus-toeoevotu-ja-mueuegilepingute-ueldtingimused-17.11.2025-

.pdf?0e5a56c3e2;

3(14)

1.11 Poolte kontaktisikud lepingu täitmisel on:

1.11.1 Tellija kontaktisik Tõnu Oro, tooteomanik, e-post [email protected], tel. 525 2510,

või tema asendaja;

1.11.2 Täitja 1 kontaktisikud on

1.11.2.1 René Oruman, juhatuse liige, e-post [email protected], tel +372 501 3672;

1.11.2.2 Mattias Mölder, juhatuse liige, e-post [email protected], tel +372 5332 3932;

1.11.2.3 Kärt Kaldoja, hanke- ja müügispetsialist, e-post [email protected], +372

5352 9904;

1.11.2.4 Kadri Kaurit, hanke- ja müügispetsialist, e-post [email protected], +372

5330 2817;

1.11.3 Täitja 2 kontaktisik on Helena Eiland, tegevjuht, e-post [email protected], tel.

54554555;

1.11.4 Täitja 3 kontaktisik on Sergei Fedulov, arhitekt, e-post [email protected], tel.

+372 5110929;

1.11.5 Täitja 4 kontaktisik on Glein Kiissa, projektijuht, e-post [email protected], tel.

+372 5667 8678;

1.11.6 Täitja 5 kontaktisikud on

1.11.6.1 Ulvi Olivares Kaiva, valdkonnajuht, e-post [email protected],

tel. +372 5303 9094;

1.11.6.2 Raivo Rang, Tehnoloogia- ja protsessijuht, e-post [email protected], tel.

+372 525 5744;

1.11.7 Täitja 6 kontaktisik on Eva Salumäe, Digimuutuse valdkonnajuht, e-post

[email protected], tel. +3725185580;

1.11.8 Täitja 7 kontaktisik on Andrus Lehtmets, tegevdirektor, e-post

[email protected], tel. 5142671;

1.11.9 Täitja 8 kontaktisik on Julia Ostapiv, projektijuht, e-post [email protected],

tel. +372 5199 1151;

1.11.10Täitja 9 kontaktisik on Triin Tikk, Tiimijuht, e-post Triin Tikk, Tiimijuht,

55919490, [email protected], tel. 55919490;

1.11.11Täitja 10 kontaktisik on Jaanus Sulakatko, e-post [email protected], tel.

526 0039;

1.11.12Täitja 11 kontaktisik on Liisa Abel, ärijuht, e-post [email protected];

1.11.13Täitja 12 kontaktisik on Gerttu Pilsas, tegevjuht, e-post

[email protected], tel. 5223740;

1.11.14Täitja 13 kontaktisik on Kristjan Kokk, tegevjuht, e-post [email protected], tel.

55697941;

1.11.15Täitja 14 kontaktisik on Karl-Erik Talvistu, Front-end team lead, e-post

[email protected]; tel. 53240293.

1.12 Lepingu lahutamatuteks osadeks on järgnevad lisad:

1.12.1 Lisa 1 – Tehniline kirjeldus;

1.12.2 Lisa 1.1 – Lähtekoodi halduse ja ehitamise nõuded arendajale;

1.12.3 Lisa 1.2 – Logimise nõuded;

1.12.4 Lisa 1.3 – Rakendustevahelised integratsioonipõhimõtted;

1.12.5 Lisa 1.4 – Tehnilised nõuded tarkvaralahendustele.

2 Raamlepingu ese

2.1 Raamlepingu esemeks on ruumiandmete halduse platvormi ja sellega seonduvate

süsteemide (teenuste, rakenduste, infosüsteemide) arendustööde teenus (edaspidi ka

„teenus“ või „tööd“) vastavalt riigihanke alusdokumentidele, sõlmitud raamlepingule ning

minikonkursi tingimustele ja nende alusel tellijaga sõlmitud hankelepingutele ja nende

lisadele.

2.2 Käesoleva lepingu ning tellija vastavasisuliste minikonkursside ja sõlmitavate

hankelepingute alusel osutab täitja tellijale teenust ressursi põhimõttel (st pakub (front-end

4(14)

arendaja (Angular) ja Java vanemarendaja (back-end) tundi) ning tellija kohustub selle eest

vastavalt raamlepingule, minikonkurssidele ja hankelepingutele tasuma.

2.3 Täitja on kohustatud hankelepingu alusel ja selles sätestatud maksumuse eest teostama ka

nn sidustöid, mis ei ole hankelepingus sõnaselgelt sätestatud, kuid mille teostamine on

headest tavadest ja täitja ametialasest professionaalsusest lähtudes nõutavad ja/või

vajalikud lepingust tuleneva eesmärgi saavutamiseks. Tööde teostamisel tuleb lähtuda

tõhususe, kvaliteedi, säästlikkuse ja otstarbekuse põhimõtetest ning arvestades vastavas

tegevusvaldkonnas kehtivaid õigusakte, standardeid ja head tava.

2.4 Tellijal on õigus ühepoolselt muuta raamlepingu kehtivuse vältel lepingu lisasid 1.1-1.4

teavitades sellest täitjat kirjalikku taasesitamist võimaldavas vormis. Juhul, kui tellija

muudab hankelepingu kehtimise vältel raamlepingu lisasid 1.1-1.4, kohaldatakse

hankelepingule hankelepingu sõlmimise hetkel kehtinud lisasid.

3 Raamlepingu maksumus ja arveldamise kord 3.1 Raamlepingu maksimaalne kogumaksumus on 600 000 eurot, millele lisandub käibemaks.

Tellija ei ole kohustatud lepingu eset maksimaalse maksumuse ulatuses tellima.

Minikonkursse korraldatakse ja hankelepinguid sõlmitakse vastavalt tellija vajadustele.

3.2 Meeskonnaliikmetele minikonkursil kohalduvad töötunni maksumused esitatakse

minikonkursside käigus.

3.3 Meeskonnaliikme töötunni hind sisaldab ka kõiki intellektuaalomandiga seotud tasusid

ning kohaldub vastavalt kaasatud rollidele ja vastavalt reaalselt kulunud töötundidele.

3.4 Raamlepingu täitmist rahastatakse riigieelarvest või välisvahenditest. Täpne

finantseerimisallikas täpsustatakse minikonkursil.

3.5 Kui konkreetses hankelepingus ei ole sätestatud teisiti, tuleb arved edastada tellijale

vastavalt Eesti e-arve standardile. E-arves peab lisaks standardis nimetatud andmetele

olema toodud tellija kontaktisiku perekonnanimi, raamhanke riigihangete registri

viitenumber, raamlepingu number, minikonkursi riigihangete registri viitenumber,

hankelepingu number, hankelepingu riigihangete registri 15-kohaline viitenumber ja

välisvahendite projekti tunnus, kui on tegemist välisvahenditega. E-arve tuleb saata e-

arvete operaatori kaudu. E-arve loetakse laekunuks selle e-arvete operaatorile laekumise

kuupäevast.

3.6 Kui konkreetses hankelepingus ei ole sätestatud teisiti, siis on tööde arveldusperioodiks

kalendrikuu. Sellisel juhul esitab täitja tellijale iga kuu 5. kuupäevaks üleandmis-

vastuvõtmisakti, milles on sätestatud eelnenud arveldusperioodil töötatud töötundide arv

(kui minikonkurssi tulemusel on sama täitja poolt rohkem kui üks meeskonna liige, siis iga

meeskonnaliikme kohta eraldi ) koos tunnihinnaga, teostatud tööd ja kogumaksumus.

Tellijal on õigus esitada täitjale täiendavaid arupärimisi ning selgitusi kajastatud

tööde/töötundide kohta. Peale üleandmis-vastuvõtmisakti allkirjastamist, esitab täitja

tellijale (või kui maksjaks on teine asutus, siis maksjale) lepingukohase arve. Üleandmis-

vastuvõtmisakti allkirjastamise õigus on hankelepingu kontaktisikul või tema asendajal.

3.7 Kui konkreetses hankelepingus ei ole sätestatud teisiti, on välisvahenditest rahastatava

hankelepingu korral arveldusperioodiks kolm kuud.

3.8 Arve maksetähtaeg 21 kalendripäeva (kui konkreetses minikonkursis või hankelepingus ei

ole sätestatud teisiti).

3.9 Juhul kui konkreetses hankelepingus on sätestatud käesoleva peatükiga võrreldes erinevad

põhimõtted, kohaldatakse vastavat kokkulepet.

4 Hankelepingu sõlmimine raamlepingu alusel

4.1 Raamlepingu alusel hankelepingu sõlmimiseks korraldab tellija raamlepingu osapoolteks

olevate täitjate vahel minikonkursse. Tellija võib korraldada minikonkursse paralleelselt ja

sõlmida hankelepinguid eraldi või korraga:

4.1.1 Kuni kahele (2) nõuetele vastava front-end (Angular) arendaja ressursile;

4.1.2 Kuni kahele (2) nõuetele vastava Java vanemarendaja (back-end) ressursile;

5(14)

4.2 Lepingu eseme tellimine toimub vastavalt tellija vajadusele kogu lepingu kehtivuse

perioodil. Lepingu eseme tellimiseks esitab tellija minikonkursi korras kõikidele

raamlepingu täitjatele pakkumuse esitamise ettepaneku koos hankelepingu eseme

kirjelduse, pakkumuse esitamise tingimuste ja vajadusel hankelepingu projektiga. Üldjuhul

esitab tellija täitjale ettepaneku pakkumuse esitamiseks riigihangete registris. Riigihangete

seadusega kooskõlas on hankijal õigus esitada ettepanek pakkumuse esitamiseks ka e-kirja

teel. Täitja vastutab riigihangete registris täitja kohta esitatud andmete (sh kontaktandmete)

õigsuse eest.

4.3 Lepingu täitmine toimub esitatud minikonkursside tulemusel sõlmitud hankelepingute

alusel. Hankelepingu all peetakse silmas raamlepingu alusel sõlmitavat vastastikuste

varaliste õiguste ja kohustustega kokkulepet, kus spetsifitseeritakse lepingu ese,

maksumus, tähtajad ja muud olulised tingimused. Hankelepingud sõlmitakse poolte

kokkuleppel raamlepingu kehtivusaja jooksul riigihangete seaduses ja käesolevas lepingus

sätestatud korras. Raamlepingu kehtivusajal selle alusel sõlmitud hankelepingute tähtaeg

võib olla raamlepingu tähtajast lühem või pikem.

4.4 Hankelepingud, mille maksumus on 20 000 eurot või enam, lisandub käibemaks,

sõlmitakse kirjalikult. Eelnimetatust väiksemas rahalises mahus sõlmitava hankelepingu

moodustab tellimus, pakkumus ja tellija aktsept, eraldi kirjalikku hankelepingut ei pea

sõlmima v.a kui selline tingimus on tellija poolt tellimuses sätestatud või kui see nõue on

seotud välisvahendite kasutamise tingimustega.

4.5 Lepingu eseme tellimiseks, mille eeldatav maksumus on 30 000 eurot või enam, esitab

tellija täitjatele e-riigihangete keskkonnas tellimuse koos hankelepingu eseme tehnilise

kirjelduse ja hankelepingu projektiga.

4.6 Lepingu eseme tellimiseks, mille eeldatav maksumus on madalam kui 30 000 eurot, esitab

tellija täitjatele kas e-riigihangete keskkonnas või e-posti teel tellimuse koos hankelepingu

eseme tehnilise kirjelduse ja vajadusel hankelepingu projektiga.

4.7 Tööde tellimiseks maksumusega alates 30 000 eurot (lisandub käibemaks) esitab tellija

täitjale elektroonilises riigihangete keskkonnas tellimuse korras pakkumuse esitamise

ettepaneku koos hankelepingu eseme kirjelduse ja hankelepingu projektiga. Väiksema

maksumusega tööde tellimine, pakkumuse esitamine ja pakkumuse aktsepteerimine.

4.8 Minikonkursil esitab tellija täitjale hankelepingu täitmiseks nõutava(te)

meeskonnaliikme(te) nimekirja koos vastavustingimustega, mis on toodud CV vormidel.

4.9 Sõlmitavas hankelepingus või selle tehnilises kirjelduses määrab tellija hankelepingu

eesmärgi, nõutud rollide töömahud ning muud ajalised ja eelarvelised piirangud, vajadusel

tööde loetelu ja sisu. Hankelepingus määratakse ühtlasi ka muud olulised tingimused nende

olemasolul. Kui see on konkreetse minikonkursi või hankelepingu eseme olemusest

tulenevalt vajalik, esitab tellija minikonkursi pakkumuse esitamise ettepaneku kujul, kus

on tellitavate arendustööde andmed esitatud lähteülesande kujul, nt: taustinformatsioon,

lahendatav probleem, eesmärk ja oodatavad ja mõõdetavad tulemused, soovitav teostamise

tähtaeg jmt.

4.10 Teenuse tellimisel võib tellija vastavalt vajadusele igakordses minikonkursis tellida

ühe või mitu meeskonnaliiget korraga. Meeskonnaliikme koormust võib täita rohkem, kui

ühe tingimustele vastava isikuga, kui tellija on selle minikonkursi tingimustes lubanud.

4.11 Teenuse tellimisel sätestatakse konkreetne töötundide maht meeskonnaliime(te)

lõikes igakordselt minikonkursi dokumentides.

4.12 Kõik hankelepingu täitmisse kaasatud meeskonnaliikmed peavad läbima

taustakontrolli.

4.13 Tellija võib minikonkursi osadeks jaotada.

4.14 Teenuse tellimisele kohalduvad SMIT-i töövõtu-, käsundus- ja müügilepingute

üldtingimused.

4.15 Pakkumuse esitamisel tuleb järgida kõiki minikonkursi nõudeid ja tingimusi. Tellija

ootab täitjalt võimekust leida lahendusi etteantud piirangute kontekstis, pöörates sealjuures

tähelepanu nii arendusprotsessi tõhustamisele, arendusmeeskonna tulemuslikkuse pidevale

6(14)

suurendamisele, kui ka mõistliku keerukusega tehniliste lahenduste loomisele ja

kasutamisele ning olelusringi kuludele.

4.16 Minikonkursil on pakkumuse hindamise kriteeriumiks pakkumuse kogumaksumus

osakaaluga 100%, mis kujuneb meeskonnaliikme rolli töötunni hinna ja konkreetse rolli

töötundide mahu korrutisena. Kui hankija tellib ühel minikonkursil mitu meeskonnaliiget,

siis tellitavate meeskonnaliikmete rolli töötunni hinna ja töötundide mahu korrutised

summeeritakse. Madalaima kogumaksumuse esitanud pakkujale antakse 100

väärtuspunkti. Järgnevad pakkumused saavad punkte proportsionaalselt vähem. Hankija

tunnistab edukaks enim väärtuspunkte saanud pakkumuse ja sõlmib edukaks tunnistatud

pakkumuse esitanud pakkujaga hankelepingu.

4.17 Kui minikonkursi käigus esitab kaks või enam pakkujat võrdse madalaima hinnaga

pakkumused, selgitatakse edukas pakkuja välja liisku heites. Liisuheitmise korra määrab

hankija.

4.18 Tellija võib minikonkursi käigus esitatud pakkumusi hinnata enne pakkumuste

vastavuse või pakkujate suhtes kõrvaldamise aluste puudumise kontrollimist. Sellisel juhul

kontrollib tellija pakkumuse vastavust ja kõrvaldamise aluste puudumist vaid pakkujal,

kelle ta plaanib minikonkursil edukaks tunnistada. Kui tema pakkumus osutub

kontrollimise tulemusena mittevastavaks või pakkuja kõrvaldatakse minikonkursilt, on

tellijal õigus teostada kirjeldatud kontrollid järgmise pakkuja osas, kelle ta plaanib

hindamise tulemusena paremusjärjestuses järgmisena edukaks tunnistada.

4.19 Täitjad esitavad kas elektrooniliselt või kirjalikku taasesitamist võimaldavas vormis

pakkumused minikonkursil määratud tähtajaks. Pakkumuse tähtaegse esitamise eest

vastutab täitja. Pakkumuse esitamise tähtajast hiljem esitatud pakkumusi arvesse ei võeta.

4.20 Tellija ei vastuta võimalike viivituste, tõrgete või katkestuste eest, mida põhjustavad

e-keskkonna (riigihangete registri või e-posti) tellija kontrolli alt väljas olevad asjaolud

nagu vääramatu jõud, elektrikatkestused, häired tellija või täitja telefoni või interneti

ühenduses või muude elektrooniliste seadmete ja vahendite, sh tarkvara, töös. Tellija ei

vastuta e-keskkonna kasutamisest või mittekasutamisest täitjale tekkinud kahjude või

saamata jäänud tulu eest.

4.21 Minikonkursil esitatud täitja pakkumus on täitja tahteavaldus hankelepingu

sõlmimiseks, mis on täitjale siduv alates minikonkursi pakkumuste esitamise tähtpäevast

vähemalt 3 kuud. Tingimusliku pakkumuse esitamine ei ole lubatud.

4.22 Tellija lükkab täitja pakkumuse tagasi, kui see ei vasta minikonkursi tingimustele,

kui täitja on esitanud lisatingimusi, mis ei ole kooskõlas minikonkursi tingimustega, kui

täitja ei esita tähtajaks tellija nõutud selgitusi või täitja selgituste põhjal ei ole võimalik

üheselt hinnata pakkumuse vastavust.

4.23 Pakkumus tunnistatakse vastavaks, kui see vastab minikonkursi tingimustele.

Tellija võib tunnistada pakkumuse vastavaks, kui selles ei esine sisulisi kõrvalekaldeid

minikonkursi tingimustest.

4.24 Tellija kontrollib enne hankelepingu sõlmimist pakkujal, kellega ta kavatseb

lepingu sõlmida, kõrvaldamise aluste puudumist vastavalt riigihangete seadusele.

4.25 Tellijal on õigus määrata hankelepingu sõlmimiseks tähtaeg. Kui minikonkursil

eduka pakkumuse esitanud pakkuja (täitja) võtab tellijast mitteolenevatel põhjustel oma

pakkumuse tagasi või ei allkirjasta tellija antud tähtaja jooksul hankelepingut, mida

käsitletakse kui pakkumuse tagasivõtmist RHS § 119 tähenduses, hindab tellija kõiki

ülejäänud minikonkursi pakkumusi uuesti ja tunnistab soodsaimaks pakkumuse, mis on

pakkumustest majanduslikult soodsaim. Tellija 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.26 Tellijal on õigus pakkumus tagasi lükata ja otsustada hankelepingut mitte sõlmida

või vastavalt raamlepingule minikonkurss kehtetuks tunnistada, kui:

4.26.1 pakkumus(ed) ei vasta tingimustele;

4.26.2 pakkumus(ed) ületavad eeldatavat maksumust;

7(14)

4.26.3 tellija ei saa projektile rahastust;

4.26.4 tekib vajadus lepingu eset olulisel määral muuta;

4.26.5 minikonkursi läbiviimise aluseks olevad tingimused on oluliselt muutunud ja

seetõttu osutub lepingu sõlmimine mittevajalikuks või võimatuks;

4.26.6 minikonkursis ilmnenud ebakõlasid ei ole võimalik kõrvaldada ega minikonkurssi

seetõttu ka õiguspäraselt lõpule viia;

4.26.7 omal algatusel põhjendatud vajadusel.

4.27 Tellijal on õigus kaasata hankelepingute täitmisel tellija poolele maksja rollis

kolmandaid osapooli, kelleks võivad olla Siseministeerium ja selle valitsemisala asutused

(Häirekeskus, Politsei- ja piirivalveamet, Päästeamet, Sisekaitseakadeemia jt). Sellisel

juhul sõlmitakse hankeleping mitmepoolsena.

5 Hankelepingu täitmine, tööde teostamine

5.1 Töid teostatakse tellija asukohas või täitja asukohas vastavalt hankelepingule. Tellija

nõudmisel kohustub täitja teostama töid tellija asukohas, sellisel juhul teostatakse töid

tavapäraselt ajavahemikul esmaspäevast neljapäevani kell 8:30-17:00 ja reedel kell 8:30-

16: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 (Rocket chat, MS Teams vms) kõikidel

tellija poolt teavitatud meeskonna koosolekutel (nt. pikemad koosolekud reeglina 1-2

korda nädalas ja igahommikustel lühiaruteludel (Standup)).

5.2 Hankelepingu alusel töid vahetult teostava meeskonnaliikme vahetamine või asendamine

võib toimuda tellija kirjalikku taasesitamist võimaldavas vormis antud nõusolekul. Täitja

esitab meeskonnaliikme vahetamise või asendamise teate tellijale kirjalikku taasesitamist

võimaldavas vormis vähemalt 20 päeva enne meeskonnaliikme vahetamist või

asendamist.. Uus meeskonnaliige peab vastama minikonkursis esitatud nõuetele taotluse

esitamise seisuga. Tellijal on õigus keelduda vahetusest, kui pakutav isik ei vasta lepingu

aluseks olnud minikonkursis vastava rolli kohta esitatud nõuetele.

5.3 Kui meeskonnaliikme vahetamine või asendamine toimub pärast lepingu sõlmimist ja

taustakontrolli teostamist esimese 3 kuu jooksul, siis makstakse vahetamisele või

asendamisele järgneva 3 kuu vältel meeskonnaliikmele ettenähtud tunnitasust 10%

väiksemat tunnitasu.

5.4 Lisaks punktis 5.2 kirjeldatule kohustub täitja tellijat vähemalt 14 päeva kirjalikult ette

teavitama ka meeskonnaliikmete planeeritud puhkustest ja lähetustest, tagamaks sujuv

töökorraldus hankelepingu täitmisel.

5.5 Täitja tagab lepingu täitmise eesti keeles. Lepingu täitmisesse kaasatud

meeskonnaliikme(te) eesti keele oskus kõnes ja kirjas peab olema vähemalt tasemel, mis

võimaldab meeskonnaliikme(te)le vahetult osaleda nii meeskonnatöös (koosolekud jmt)

kui teostada lepingu esemeks olevaid arendustöid ja saada iseseisvalt aru täiendava tellija

poolse juhendamiseta tööülesannete ja tehniliste juhiste sisust ja tellijal kasutusel olevate

töökeskkondade juhistest. Juhul, kui meeskonnaliikme(te) eesti keele oskus ei ole piisaval

tasemel eelpool nimetatud osas, siis tagab täitja meeskonnaliikme(te)le omal kulul tõlgi,

sh juba sõlmitud lepingu täitmise olukorras, kui ilmnevad probleemid eespoolviidatud

kompetentsidega.

5.6 Teenuse ostmisel on tellija arvestanud, et hankelepingu perioodi kestel on

meeskonnaliikmel õigus vähemalt töölepingu seaduses ette nähtud põhipuhkusele. Sellest

tingitud lepingu tähtaegse täitmise viivitust ei käsitleta hankelepingu mittekohase

täitmisena vmt rikkumisena. Samuti ei käsitleta hankelepingu rikkumisena tellijast tingitud

viivitust tööde tähtaegsel teostamisel seoses ebapiisavas mahus tööülesannete andmisega.

5.7 Juhul, kui hankelepingus sätestatud töötundide mahu täitumine hankelepingus sätestatud

perioodi jooksul on takistatud täitjast sõltuvatel põhjusel (nt meeskonnaliikme

haigestumine, vahetamine), tuleb kokkulepitud mahus teenust osutada tähtaega ületades,

millisel juhul on täitja tähtaja osas lepingu rikkumises. Juhul, kui tellijal puudub vajadus

teenuse järgi peale kokkulepitud teenuse osutamise tähtaega, võib tellija keelduda edasisest

8(14)

teenuse osutamisest, millisel juhul arveldatakse täitmise tähtajaks tegelikult osutatud

teenuse tundide eest.

5.8 Juhul, kui meeskonnaliige ei saa hankelepingu täitmisel osaleda muul põhjusel kui

põhipuhkus ning tellija seda nõuab, peab täitja teostama vastava meeskonnaliikme osas

vahetamise vastavalt raamlepingus sätestatule.

5.9 Kui konkreetses minikonkursis või hankelepingus ei ole sätestatud teisiti, alustab täitja

hankelepingu täitmist esimesel võimalusel pärast selle sõlmimist, kuid mitte hiljem, kui

ühe kuu jooksul alates hankelepingu allkirjastamist poolte poolt. Pooled täpsustavad

hankelepingu täitmise algustähtaja e-kirja teel. Tellijal on õigus ühepoolselt nimetatud

tähtaega edasi lükata vajaliku perioodi võrra põhjendatud vajaduse esinemisel (nt

taustakontrolli teostamine viibib), teavitades sellest täitjat e-kirja teel.

5.10 Kui konkreetses minikonkursis või hankelepingus ei ole sätestatud teisiti, siis annab

tööülesandeid tellija täitjale läbi SMIT-i tööülesannete haldussüsteemi JIRA või mõnes

muus analoogses keskkonnas või kohtumistel, leppides igakordselt kokku tulemi ehk uue

versiooni nõuded. Tööülesannete täitmisel märgitakse süsteemis tehtava töö ajakulu iga

konkreetse tööülesande kohta ja töö märgitakse tehtuks, kui tellija otsusel on tööülesande

eesmärk saavutatud. Töö tulemid kantakse SMIT-i lähtekoodi repositooriumisse vastavalt

tellija juhistele.

5.11 Kui konkreetses minikonkursis või hankelepingus ei ole sätestatud teisiti,

kohaldatakse tööde üleandmisele-vastuvõtmisele SMIT töövõtu-, käsundus- ja

müügilepingute üldtingimustes sätestatut.

5.12 Pretensioonid tööde plaanipärase edenemise, meeskonnaliikme töö teostamise

efektiivsuse ja kvaliteedi kohta annab tellija teada lisaks meeskonnaliikmele ka täitja

lepingulisele kontaktisikule. Olulises ulatuses või korduvaid kõrvalekaldeid tellija juhiste

järgimata jätmisel, ülesannete teostamisel, meeskonnatööga arvestamise vmt osas, loetakse

lepingu rikkumiseks. Lisaks mujal lepingus sätestatud õigustele, on tellijal õigus nõuda

selle meeskonnaliikme vahetamist, kelle töö ei vasta tellija õigustatud ootustele. Nimetatud

vahetuse nõue on tellijapoolne otsustus ning täitja kohustub tagama meeskonnaliikme

vahetuse 10 tööpäeva jooksul alates tellijapoolsest otsustuse teavitusest.

5.13 Tellijal on õigus igal ajal hankelepingu täitmise käigus kolme-kalendripäevase

etteteatamisega kokku kutsuda koosolekuid, kus täpsustatakse töökorraldust, tellija ja

täitja ootuseid vmt.

5.14 Tellija on kohustatud kõikidele täitja lepingu täitmisega seotud põhjendatud

küsimustele vastama hiljemalt kolme tööpäeva jooksul. Juhul, kui küsimusele vastamine

nõuab tellijalt pikemat analüüsimist, on tellija kohustatud andma eeltoodud kolme

tööpäeva jooksul täitjale täpse kuupäeva, millal tagasisidet antakse, sellisel juhul on täitjal

õigus nõuda tarne tähtaja proportsionaalset pikendamist.

5.15 Täitja peab lepingu täitmisel juhinduma tellija poolt edastatud juhistest ja

ülesannetest. Tellijal on õigus igal ajal kontrollida tööde vastavust hankelepingule ning

nõuda täitjalt informatsiooni lepingu täitmise kohta. Tellija nõudmisel kohustub täitja

meeskonnaliige jooksvalt andma ülevaate ja esitlema juba teostatud või teostamisel olevaid

töid.

5.16 Täitja tagab ja vastutab tööks vajalike töövahendite, litsentside ja autoriõiguste eest

iseseisvalt. Eraldi kokkuleppel võimaldab tööks vajalikud vahendid tellija.

5.17 Tellija jätab endale hankelepingu tingimuste piires õiguse ühepoolselt täiendada ja

muuta üldist töökorraldust, sh töökorralduse nõudeid jmt, teavitades täitjat kirjalikult ette

1 (üks) kuu.

5.18 Minikonkursis või hankelepingus võib olla sätestatud täiendavaid nõudeid vastavalt

välisvahendite rakendamisele kehtestatud reeglitele. Välisvahendite kasutamisel on täitja

kohustatud tagama lepingu eseme märgistamise vastavalt välisvahendite rakendamisele

kehtestatud reeglitele, täpsed nõuded sätestatakse vastavalt finantseerimisallikale

konkreetses minikonkursis ja/või hankelepingus.

5.19 Teenuse käigus tehtavad arendused peavad ühilduma tellija poolt nõutud tehnilise

lahendusega (erisused on lubatud tellija kontaktisiku kirjalikul nõusolekul), sealhulgas:

9(14)

5.19.1 järgima tellija poolt nõutud tehnilise lahenduse ideoloogiat süsteemsete

protseduuride osas ja infosüsteemi arhitektuurset lahendust ja kasutusloogikat;

5.19.2 taaste- ja varundusprotseduurid peavad olema ühilduvad tellija poolt soovitud

tehnilise lahendusega;

5.19.3 lepingu ese ei tohi põhjustada süsteemi töö terviklikkuse või muid toimimise

häireid ega jõudluse langust;

5.19.4 lepingu ese peab olema tellija poolt nõutud infosüsteemiga ühetaoline ning

sobituma olemasolevatesse ekraanivormidesse ja töövoogu;

5.20 Tööde teostamise käigus tuleb täitjal vajadusel uuendada ka lepingu eseme

dokumentatsiooni (kirjeldused, juhised, protsessianalüüs jmt) ja dokumentatsioon tellijale

kokkulepitud viisil üle anda. Dokumentatsiooni üleandmisel eelistatakse elektroonilist

vormi.

5.21 Lepingu täitmisel peab täitja ja tema töötajad või lepingupartnerid järgima

veebiaadressil https://www.smit.ee/et/hanked avaldatud infoturbekorda ning tellija

töövahendi kasutamisel SMIT töövahendiga reisimise korda.

5.22 Täitja peab lepingu täitmisel eelistama keskkonnahoidlikke lahendusi, milleks on

võimalusel veebikoosolekud jne.

6 Lepingu tõlgendamine ja erisätted

6.1 Lepingu tõlgendamisel lähtutakse võlaõigusseaduses sätestatud lepingu tõlgendamise

reeglitest ning järgnevast dokumentide prioriteetsusest:

6.1.1 hankeleping;

6.1.2 raamleping;

6.1.3 SMIT-i töövõtu-, käsundus- ja müügilepingute üldtingimused.

7 Kehtivus

7.1 Leping jõustub alates hetkest, mil pooled on selle allkirjastanud.

7.2 Leping kehtib 24 kuud või kuni maksimaalse maksumuse täitumiseni, kohalduv on

esimene täituv.

7.3 Õigused ja kohustused, mis oma olemusest tulenevalt ei sõltu lepingu kehtivusest, jäävad

kehtima peale lepingu lõppu.

7.4 Tellijal on õigus raamleping ühe täitja suhtes erakorraliselt üles öelda, kui täitja rikub

oluliselt raamlepingu või selle alusel sõlmitava hankelepingu tingimusi või muul SMIT-i

töövõtu-, käsundus- ja müügilepingute üldtingimustes kehtestatud alusel. Ühe täitja suhtes

raamlepingu erakorralise ülesütlemise korral jääb raamleping teiste täitjate osas täies

ulatuses kehtima.

8 Täitja kinnitused

8.1 Täitja avaldab ja kinnitab, et:

8.1.1 ta on lepinguga ja riigihanke alusdokumentidega tutvunud ning mõistab täielikult

enesele võetavate kohustuste sisu ja tagajärgi ning on nõus nendes toodud

tingimustega;

8.1.2 lepingu täitmisega ei kahjustata kolmandate isikute õigusi ja huve ning puuduvad

mistahes asjaolud, mis välistaksid tema õigusi sõlmida leping ja seda

nõuetekohaselt täita;

8.1.3 ta on tutvunud lepingu lahutamatuks osaks olevate SMIT-i töövõtu-, käsundus- ja

müügilepingute üldtingimustega.

8.2 Täitja esitab tellijale 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.

Leping on allkirjastatud digitaalselt.

10(14)

Lisa. HANKELEPINGU projekt

* Hankelepingu täpsem sisu ja punktid võivad muutuda sõltuvalt konkreetsest hankelepingu

esemest.

Siseministeeriumi infotehnoloogia- ja arenduskeskus (SMIT või Tellija), registrikood

70008440, aadress Mäealuse 2/2, 12618, Tallinn, keda esindab põhimääruse alusel …

Asutus (Maksja), registrikood …………, aadress, keda esindab ……. (kui maksjana on kaasatud

teine asutus)

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

1. Üldandmed

1.1 Käesolev hankeleping on sõlmitud … 202…. a sõlmitud raamleping nr ... (riigihanke

viitenumber ….) alusdokumendid, tellija … tellimus ja täitja … pakkumus.

1.2 Rahastamisallikaks on riigieelarve ja/või välisvahendid.

1.3 Poolte kontaktisikud hankelepingu täitmisel on:

1.3.1 Tellijal: ……..., tel. ………., e-post: ……..….. või tema asendaja;

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

1.3.3 Maksjal: …….., tel. ………., e-post: ………….;(kui Maksja lepingu osapooleks)

2. Lepingu eseme täitmine

2.1 Hankelepinguga ostab tellija või maksja (kui maksjana on kaasatud teine asutus):

2.1.1 …. (märkida rolli(de) nimetus(ed), kelle teenust ostetakse) teenust mahus …. tundi.

2.2 Hankelepingu täitmise periood on ….. (rolli nimi) puhul … kuu(d) alates töödega

alustamisest/ täitmise tähtaeg on …..

2.3 Teenust osutatakse igakuiselt mahus, mis vastab täistööajale, võttes muuhulgas arvesse

riigipühasid ning SMIT-i töökorralduse reeglitest tulenevaid lühendatud tööpäevi.

/täidetakse iga hangitava meeskonnaliikme kohta/

2.4 Töid teostab/teostavad täitja pakkumuses esitatud CV-s/CV-des nimetatud isik/isikud.

2.5 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.6 Hankelepingus kokku leppimata küsimustes lähtutakse raamlepingus ja SMIT töövõtu-,

käsundus- ja müügilepingute üldtingimustes sätestatust, vastuolude korral lähtutakse

esmalt hankelepingus sätestatust, siis raamlepingus sätestatust ning viimaks SMIT

töövõtu-, käsundus- ja müügilepingute üldtingimustes sätestatust.

2.7 Täitja esitab tellijale 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.

2.8 Kui meeskonnaliikme asendamine toimub pärast lepingu sõlmimist ja pärast

taustakontrolli teostamist esimese 3 kuu jooksul, siis makstakse asendamisele järgneva 3

kuu vältel meeskonnaliikmele ettenähtud tunnitasust 10 % väiksemat tunnitasu.

3. Hankelepingu maksumus ja arveldamise kord

3.1 Hankelepingu kogumaksumus on … eurot, millele lisandub käibemaks. Kogumaksumus

sisaldab ka kõiki intellektuaalomandiga seotud tasusid.

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 teostavate meeskonnaliikmete ühe (1) töötunni maksumused on (rolli nimi valitakse

vastavalt sellele, millist rolli ostetakse):

3.3.1 Front-end (Angular) arendajal…………. eurot, millele lisandub käibemaks;

3.3.2 Java vanemarendajal (back-end)…………. eurot, millele lisandub käibemaks.

11(14)

3.4 Lepingu ese antakse üle igakuiste vahetarnete kaupa / lepingu eseme üleandmise

perioodiks on … kuu(d).

3.5 Pärast üleandmis-vastuvõtmisakti allkirjastamist, esitab täitja tellijale lepingukohase

arve.

3.6 Tööde arveldusperioodiks on (kalendrikuu / kolm kuud, vastavalt rahastusallikale).

3.7 Arved tuleb edastada tellijale vastavalt Eesti e-arve standardile. E-arves peab lisaks

standardis nimetatud andmetele olema toodud tellija kontaktisiku perekonnanimi,

raamhanke riigihangete registri viitenumber, raamlepingu number, minikonkursi

riigihangete registri viitenumber, hankelepingu number, hankelepingu riigihangete

registri 15-kohaline viitenumber ja välisvahendite projekti tunnus, kui on tegemist

välisvahenditega. E-arve tuleb saata e-arvete operaatori kaudu. E-arve loetakse laekunuks

selle e-arvete operaatorile laekumise kuupäevast.

* lisatakse arveldamise kord, kui see erineb raamlepingus sätestatust.

4. Kaasrahastab Euroopa Liit. Välisvahendite kasutamisest tulenevad nõuded (punkti 4 sisu

võib muutuda sõltuvalt rahastusallikast ja konkreetsest projektist, sh. sisaldada

teistsuguseid nõudeid)

4.1 Välisvahendite kasutamise lõpptähtpäev on …..

4.2 Lähtuvalt rahastusallikast (välisvahendid) ning sellele kohalduvatest kohustuslikest

nõuetest, kohustub täitja tagama alljärgnevat:

4.2.1 kõigile projekti tegevusega seotud dokumentidele peab olema trükitud Euroopa Liidu

ja Siseministeeriumi logo ning tunnuslause „Projekti kaasrahastavad Euroopa Liit

Sisejulgeolekufondi kaudu ja EV Siseministeerium“;

4.2.2 Euroopa Liidu ja Siseministeeriumi logo peab olema paigaldatud kõigile füüsilistele

esemetele, mis on projekti läbiviimiseks ostetud;

4.2.3 toetuse ja kaasfinantseeringu nähtavuse tagamiseks esitatav Euroopa Liidu embleem ja

Siseministeeriumi logo peavad vastama Lisas 3, „ISF märgistamise juhis“, kirjeldatud

juhistele;

4.2.4 täitja võimaldab välisvahenditest finantseeritud lepingu korral järelevalve teostamiseks

kogu vajaliku teabe ja volitatud isikutel viibida lepingu täitmises osalevate isikute

ruumides ja territooriumil, mis on rajatud välisvahendite abil või mis on seotud toetuse

kasutamisega ning teostada paikvaatlust.

4.3 Täitja on kohustatud säilitama 7 (seitse) aastat pärast projekti lõppemise kuupäeva

lepinguga seonduva dokumentatsiooni ja materjalid ning võimaldama vajadusel auditite

ja järelevalve (sh kohapealsete kontrollide) teostamist ning osutama selleks igakülgset abi,

sh võimaldama volitatud isikul ligipääsu esitatud andmete õigsuse kontrollimiseks kõigile

lepingu rakendamisega seotud dokumentidele ja informatsioonile, sealhulgas

elektroonilisel kujul olevale teabele. Juhul kui pärast projekti lõppu avastatakse rikkumine,

pikeneb dokumentide säilitusaeg vähemalt 7 (seitse) aastat alates päevast, mil tellija või

maksja tagastab toetuse ja kaasfinantseeringu Siseministeeriumile.

5. Hankelepingu kehtivus

5.1 Hankeleping jõustub alates hetkest, kui pooled on hankelepingu allkirjastanud.

5.2 Hankeleping kehtib Poolte lepinguliste kohustuste täitmiseni või … kuud alates

hankelepingu sõlmimisest sõltuvalt kumb sündmustest saabub varem.

6. Lepingu lisad:

6.1 Lisa 1 – täitja pakkumus;

6.2 Lisa 2 – tellija tellimus;

6.3 Lisa 3 - …..

12(14)

Lepingu juurde kuuluvateks lahutamatuteks osadeks loetakse kõik lisad ja minikonkursi

alusdokumendid ning täitja riigihankes esitatud pakkumus ja pooltevahelised kirjalikud teated,

mida lisadena eraldi ei allkirjastata.

Leping on koostatud ja allkirjastatud digitaalselt.

13(14)

Lepingu lisa. Üleandmise-vastuvõtmise akti vorm

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

Riigihanke viitenumber: ….

Riigihanke nimetus: …

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

Minikonkursi viitenumber: …

Minikonkursi nimetus: …

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

Hankelepingu osa viitenumber (15-kohaline): …

Välisvahenditest rahastatud projekti toetuse kood ja nimetus: …

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;

 arendus- või hooldusteenuse puhul töötunni hind, kogumaksumus, teostamise

periood, töötundide maht, vajadusel jira ticketite viited jne. Vajadusel täida allolev

tabel

Meeskonnaliige

(roll)

Üle antav

töö

Periood Teostatud

töötunnid

Töötunni

hind km-ta

Meeskonnaliikme

teostatud töö hind kokku

km-ta

Maksumus kokku km-ta:

Maksumus kokku km-ga:

Lepingu rahaline jääk km-ta:

2. ………(dokumentide loetelu).

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

Lepingu ese on üle antud …………. (kuupäev, millal täitja teenuse üle andis).

………………. (täitja lepingujärgse kontaktisiku nimi) kinnitab, et lepingu ese vastab lepingus

sätestatud tingimustele.

…………….. (tellija lepingujärgse kontaktisiku nimi) kinnitab, et on üle antud lepingu eseme vastu

võtnud ning see vastab lepingus sätestatud tingimustele.

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

Täitja:

…………………

/asutuse nimi/

…………………..

/allkirjastaja nimi/

Tellija:

…………………

/asutuse nimi/

…………………..

/allkirjastaja nimi/

14(14)