Üldkäskkiri

E-Riigi ristfunktsionaalsed nõuded Leht on ainult informatiivne ja arhiivi eesmärgiga, tegelikud nõuded, millest lähtuda on Tehnilised nõuded tarkvaralahendustele

NB! kõik kohustuliku märkega nõuded on SMIT-i arendustes kohustuslik järgida.

Arendus

nõue  alamnõuded ja soovitused laiendatavus SMIT kommentaar

Rakenduse kood on versioneeritud kasutades Git'i.

https://en.wikipedia.org/wiki/Git

Lisaks on ülimalt tähtis, et SSL võtmeid ei talletataks koodihoidlas.

Lisasoovitus: GIT kasutamiseks soovitame Git-flowd.

Lisasoovitus: Andmebaasi versiooniuuenduste puhul oleks olemas ka andmebaasi migratsiooniskriptid, mis varasemaid versioone uuele versioonile tõstavad, et ei toimuks 'versiooni lukustamist'.

KOHUSTUS Koodi halduses lähtume sellest dokumendist: L ähtekoodi halduse ja ehitamise nõuded

.arendajale

Rakenduse lähtekood on kirjutatud selgusega, mis võimaldab erialast ettevalmistust omaval tarkvaraarendajal süsteemi edasi arendada.

Lisasoovitus: Rakenduse lähtekood ja kommentaarid peavad olema inglise keeles. Rakenduse ärilised muutujad aga eesti keeles, kui neile pole mõlemapoolset loogilist vastet.

Lisasoovitus: Võimalusel arvestada ka Clean Code (ISBN 978-0-13-235088-4) printsiipe.

KOHUSTUS Reeglina kasutada inglise keelt.

Rakenduse kood on e-riigi koodivaramus (koodivaramu.eesti.

).ee

Lisasoovitus: sõltuvused on majasisesed, ehk kood koodivaramusse ainult peegeldada ja ehitamiseks kasutada kohalikku majasisest koodihoidlat.

OOTUS Võimalusel jagada kood välja.

Rakenduste ehitamine pole väliselt sõltuv.

Tarkvara ehitamine peab olema võimalik ka siis, kui välised sõltuvused(näiteks GitHub on maas ja teekide ning muud sõltuvused ehitatakse rakendusse või koodivaramu)

kohalikust koodihoidlast, failihoidlast või 'st.artifactory

Lisasoovitus: Arendustes on integratsioonide puhul kasutusel , et võimaldada mock'id paralleelset arendust ja tuvastada arhitektuuri võimalikke vigu ja kitsaskohti.

Lisasoovitus: Rakendus ei tohi eeldada operatsioonisüsteemi komponentidelt spetsiifiliste teekide olemasolu?

OOTUS

Rakenduse arenduses ei kasutata programmeerimiskeeli, mis pole Top 25 TIOBE index'is.

https://www.tiobe.com/tiobe-index/

https://en.wikipedia.org/wiki/TIOBE_index

Nõude eesmärk on minimeerida olukordi, kus arendatakse uusi komponente tehnoloogiates, millele on raske leida arendajaid, kui komponendid vajavad muutmist.

Täpsustusvajadus: kas eksisteerib statistikat Eestis kasutatavate programmeerimiskeelte ja ulatuste kohta?

OOTUS

E-riigi ristfunktsionaalsed nõuded on mittefunktsionaalsete nõuete laiem vaade. Käesolevad nõuded on aluseks (cross-functional requirements) igale haldusalale IT-arenduste põhinõueteks. Igale IT arendusele ja infosüsteemile rakenduvad ainult need nõuded, mida konkreetse tarkvara iseloomu, ülesehituse ja kasutatavate komponentide kontekstis on mõistlik rakendada. IT-majadele jääb vabadus kohandada ja laiendada nõudeid vastavalt enda maja spetsiifikale, võttes arvesse aga   ja   märgistustega nõudeid eesmärgipäraselt.KOHUSTUS OOTUS

Nõuete dokument peab olema kasutatav nii välisel, kui sisemisel auditeerimisel näiteks RIA's, et hinnata SF või muu tarne tulemust.  Lõpptulemus peab olema kujul, kus iga punkti saab hinnata kas   või   . Kui nõue teenusele ei kohaldu, siis hinnata seda .N/A Kui teenus saab  nõudel, mis on  , siis tuleb viga parandada.KOHUSTUS

Kui teenus saab  nõudel, mis on  , siis tuleb viga parandada, kui see on ka asutuse enda ootus. OOTUS

Nõuded, mis on märgitud kui   on puhtalt soovituslikud. Need on head täita, kuna võivad muutuda ootuseks või SOOVITUS

kohustuseks tulevikus. Nõudeid, mis on märgitud kui   võib ignoreerida.MUSTAND

Lisaks on eesmärk kõik masinloetavad nõuded dokumendina plokiahelasse panna, mis võimaldaks hiljem valideerida nõudeid vastu projekti kokkuleppeid. Projekti kokkulepetes on kajastatud spetsiifiline versioon ristfunktsionaalsetest nõuetest, mis on valideeritav ja taasleitav koodivaramust. Nõuetest peaks eksisteerima ka ingliskeelne versioon.

Nõuded on jaotatud loogiliselt viite kategooriasse , aga need nõuded ( , , , , ja )Arendus Tarne Arhitektuur Kvaliteet Turvalisus Andmehaldus pole teineteisest iseseisvad. Näiteks mitmed turvalisuse nõuded eksisteerivad ka tarneprotsessis, sest on otsesemad osad tarnest.

Rakenduse tarkvara markeerida litsentsiga.

Teose autoriõigused tuleb selgelt välja tuua. Standardseks vahendiks selleks on litsents. Litsents esitatakse ühel või mõlemal alljärgnevatest viisidest: 1) LICENCE-fail repos; 2) litsentsi tekst iga faili päises. MKM ja RIA eeldavad vaba litsentsiga koodi litsentseerimist. Erandid turva- jm õigusega pandud piirangute korral. Soovitatav on kasutada MIT litsentsi - nii tagatakse paremini tarkvarade litsentsiline ühtesobivus.   Alternatiiv on EUPL.

KOHUSTUS Vajab kokkulepet

Kõikide arendamisel kasutatavate komponentide (rakenduse, andmebaasi, kolmanda osapoole

eluea lõpp omad) (inglise k End-of- ei tohi teadaolevalt olla Life, EOL)

vähem kui 5 aastat.

OOTUS

Teenuse rakendustele eksisteerivad ajakohased taasteplaanid.

OOTUS

Tarne

nõue  alamnõuded ja soovitused laiendatavus SMIT kommentaar

Rakendus peab olema läbinud enne toodangusse minemist turvatestimise.

Vastavalt rakenduse olemusele ja riskianalüüsile rakendada meetmed OWASP ohuedetabelites (Top 10) jm. tekstides antud soovituste järgimiseks.

 Link: OWASP_Top_Ten_Project

KOHUSTUS Välistele rakendustele kindlasti partneri pool tehtud pen-testid. Siserakendustel Top10 käsitsi. Ootus SECile, et saaks automaatse tööriista pipeline osaks. Testimisel kasutatakse OWASP v3.0 tase2 nõudeid.

Rakendus ei lähe toodangu-keskkonda, kui selles on avastatud turvalisuse vigu.

Vigade tuvastamine on käsitsi või automatiseeritult, näiteks koodianalüüsi tulemusel.

Lisasoovitus: Rakendus ei lähe toodangu- keskkonda, kui selle koodis on avastatud koodikvaliteedi vigu.

KOHUSTUS Kriitilised vead peavad olema parandatud.

Toodangusse ei lähe kood, mis pole läbinud koodi ülevaatamist (code review) minimaalselt nelja-silma printsiibi põhimõttel.

Koodi ülevaatamist saab teostada ja vigasid vähendada näiteks Atlassian BitBucket töövahendiga.

Lisasoovitus: Välise partneri koodi ülevaatamine toimub majasiseste kompetentside poolt (arhitekt

kui see olemas.või vanemarendaja),

OOTUS

Toodangu-keskkonda ei lähe kood, mille testid ebaõnnestuvad.

KOHUSTUS Kriitilised testid ei tohi ebaõnnestuda. Kõik testitulemused tuleb enne toodangusse panemist tuleb meeskonna poolt üle valideerida.

Keskkondadesse tarkvara paigaldamine on automatiseeritud.

Kasutades näiteks Bamboo, Jenkins või muid CI /CD vahend.

OOTUS

Rakenduse tarne toodangu-keskkonda toimub sinine-roheline ( ) blue-green põhimõttel, ehk rakendusest sõltuva teenuse töö ei katke versiooniuuenduse puhul.

Blue-green eeldab ka mitmeid arhitektuurilisi ettevalmistusi.

Link: https://martinfowler.com/bliki /BlueGreenDeployment.html

SOOVITUS

Rakendus on versioneeritud kasutades semantilise versioneerimise põhimõtet.

https://semver.org/

A.B.C kujul, kus C on veaparandus, B on funktsionaalne uuendus, mis töötab ka vanematel integratsioonidel ja A on integratsioone potentsiaalselt lõhkuv uuendus.

Versiooni suurt numbrit A kasutatakse ka API versiooni defineerimiseks.

Lisasoovitus: Kui major versioon saab uuenduse, siis peavad vanema versiooniga teenused hakkama tagastama päises teavitust, et versioon on deprecat ed (nt. X-API-Deprecated)

SOOVITUS

Toodangu keskkondades on rakendused on automaatselt monitooritud.

See eeldab ka monitooringus tekkivate vigadest automaatset teavitamist.

Lisasoovitus: Monitooringut teostada ka arendus ja test-rakenduskeskkondades.

Lisasoovitus: Monitoorida ka teenuse käitumismustreid, näiteks kiirust ja arenduste mõju rakenduse kiirusele.

OOTUS

Arhitektuur

nõue  alamnõuded ja soovitused laiendatavus SMIT kommentaar

Rakenduse tehnilised komponendid logivad korrelatsiooni ID'd või genereerivad selle ise. Korrelatsiooni ID'd saadetakse iga edasise päringuga kaasa.

Korrelatsiooni ID'd ei eksisteeri veel standardit. Soovitus on päise parameeter X-Correlation-ID

https://en.wikipedia.org/wiki/List_of_HTTP_header_fields#Common_non- standard_request_fields

MUSTAND

Kasutajate autentimine käib läbi RIA TARA. https://e-gov.github.io/TARA-Doku/

Lisasoovitus: Hajusa infosüsteemi teenused saavad teiste teenuste komponentidega suhelda ilma, et peaks tekitama omaenda kasutajasessioone. Kaaluda JWT'd, oAuthi.

Lisasoovitus: Seansi identifikaator peab olema piisava pikkusega,juhuslik ja unikaalne kogu aktiivse seansi jooksul.

OOTUS Kasutame UAA- d.

Rakenduse tehnilised komponendid kaitsevad iseennast ja valideerivad nende poole pöördunud kasutaja või tehnilise teenuse õiguseid.

Kui autentimine on soovituslikult tsentraalne, siis autoriseerimine on rakenduste enda tagada.

OOTUS

Tehniliste komponentide API'del eksisteerib automaatselt genereeritud dokumentatsioon.

Näiteks kasutades Swagger lähenemist. OOTUS

Rakendused on disainitud ja arendatud domeenist juhinduva disaini (domain driven

) ja mikroteenuste arhitektuuri design põhimõtteid jälgides.

https://martinfowler.com/tags/domain%20driven%20design.html

http://martinfowler.com/articles/microservices.html

See nõue läheb 'paksemaks', kui defineerida ära autonoomsus ja muud mikroteenuste true/false tingimused.

: Lisasoovitus Komponendid suhtlevad omavahel asünkroonse sõnumivahetuse teel väljaarvatud, kui komponentide vaheline suhtlus peab toimuma sünkroonselt.

Lisasoovitus: Süsteemi arhitektuur peab olema ehitatud kujul, mis võimaldab nii selle tehnoloogiamigratsiooni, kui ka paindlikkust edasises arenduses. V.t. Conway Seadus https://en.wikipedia.org/wiki/Conway% 27s_law

Lisasoovitus: Rakendus peab olema väliste süsteemide tõrgete suhtes vastupanuvõimeline (resilient). Välise süsteemi tõrge tohib mõjutada ainult sellest otseselt sõltuvate kasutuslugude toimimist.

OOTUS

Infosüsteemide vaheline andmevahetus toimub üle X-tee.

https://www.ria.ee/et/riigi-infosusteem/andmevahetuskiht-x-tee.html OOTUS

Kasutajaliides ja teenuse funktsionaalsus on loogiliselt eristatud kihid ja suhtlevad üle API. Äriloogilised tehnilised komponendid on kasutatavad erinevate kasutajaliideste poolt.

Näiteks võib kaaluda Headless CMS põhimõtteid https://en.wikipedia.org /wiki/Headless_content_management_system

Lisasoovitus: Kaaluda ka mikrofrontendide põhist lähenemist https://martinf owler.com/articles/micro-frontends.html

OOTUS

Tehnilised komponendid avaldavad taaskasutuseks REST API

Loe veel: https://en.wikipedia.org/wiki/Representational_state_transfer

HTTP päised ja HTTP seisundi-koodid (https://en.wikipedia.org/wiki  ja /List_of_HTTP_header_fields https://en.wikipedia.org/wiki ) on osa RESTful API teenuse nõuetest./List_of_HTTP_status_codes

Lisasoovitus: REST API URL on kujul https://[teenuse-domeen-ja- keskkond]/api/[versioon]/[ressurss]/[identifikaator]/[jms...]

Lisasoovitus: RPC lähenemine peab olema välistatud nii palju, kui (Remote Procedure Call, ehk 'sisendparameetriteta funktsioonide käivitamine') võimalik. See tähendab, et sama API päring ei tohiks üldjuhul anda erinevaid vastuseid. Ehk GET /api/v1/getMyContactInformation asemel oleks GET /api/v1/contact/23/ (kus 23 on kontakti ID).

Lisasoovitus: Mitte unustada 'idempotentsust' https://restfulapi.net /idempotent-rest-apis/

Lisasoovitus: Toetada HTTP protokolli vahemälu standardeid. See tähendab, et teenustes peaks olema tugi Cache-Control If-Modified-Since,

jms päistele.If-Unmodified-Since

Lisasoovitus: Teenus defineerib omaenda veakoodid. Veakoodid ise peavad olema kategoriseeritud HTTP standardile vastavalt.

Lisasoovitus: Tehniliste komponentide API'del on päring, millega /status saab kontrollida teenuse tööd ja tehniline komponent saab ise läbi kontrollida ka omaenda tervise.

Lisasoovitus: Nii veebilehtede, kui ka API'de URL'id on loetavad ja inimmõistetavad

Lisasoovitus: API teenused peavad toetama JSON andmeformaati. Accept: application/json

Lisasoovitus: CamelCase peaks olema kasutuses API teenuste keeles nii palju, kui võimalik. Fikseeritud väärtused, nagu BOOLEAN ja ENUM tüüpi väärtused peavad olema suurte tähtedega ja snake case stiilis. Näiteks https ://something.ria.ee/api/v1/person/personalCode

OOTUS

Kasutajaliidese olekut ( ) hoitakse kliendi state liidese poolel ja teenused on ise olekuta.

Brauseri kohalikus hoidlas, küpsistes vms. See on vajalik, kui teenused on mitmel õlal koormusjaoturi taga.

SOOVITUS

Rakendus on pilvekõlbulik. Rakendus on skriptiga paigaldatav ning paigaldamine ja taastamine toimub automatiseeritava skripti käivitamisega. Rakendus koosneb mitmest sõltumatust instantsist. Rakendus on automaatselt skaleeritav ja vajadusel kõrgkäideldav kahe asukoha vahel. Rakenduse andmed on varundatavad ja varundatud.

Lisasoovitus: Rakenduse enda mälus või failisüsteemis talletatakse maksimaalselt käimasoleva päringu andmeid. Kõik andmed, mida vaja talletada pikemalt, peavad olema talletatud teenuse instantsist väljaspool.

Lisasoovitus: Teenus suudab püsti jääda või end täisfunktsionaalselt taastada ka Chaos Monkey eksperimenteertestimise tulemusel. https://en. wikipedia.org/wiki/Chaos_engineering

Etalon-ideaal on 12-faktorilised rakendused  Lisasoovitus: https://en.  ja wikipedia.org/wiki/Twelve-Factor_App_methodology https://www.nginx.

com/blog/microservices-reference-architecture-nginx-twelve-factor-app/

OOTUS

Rakenduse tehnilised hajuskomponendid ei jaga sama andmebaasi, mälu ega failisüsteemi.

Ehk komponendi andmed ja failid on ligipääsetavad näiteks ainult läbi kontrollitud API.

OOTUS

Rakenduse konfiguratsioon ei ole (sh. paroolid) osa tarkvara koodist vaid paigaldatakse külge rakenduse tarnel keskkonda läbi keskkonnamuutujate.

Lisasoovitus: Ära talleta paroole tekstina konfiguratsioonides või andmebaasides. Paroolide taaskasutus ainult läbi Vault-sarnase lahenduse.

KOHUSTUS Kui hoida konfiguratsiooni failis, siis peavad failiõigused olema minimaalsed.

Andmebaas ei tohi sisaldada äriloogikat (triggeri d, protseduurid jms).

Täpsustusvajadus: Seda ei saa tõenäoliselt kunagi defineerida kohustuseks. Kahjuks.

OOTUS

Rakendus ei tohi luua uut identiteedisüsteemi. Tuleb tugineda olemasolevatele riiklikele (ID- kaart) või põhiliste op-süsteemide süsteemidele (Kerberos jms).

KOHUSTUS Kasutame UAA- d

Tehnilised komponendid peavad saatma tehnilise manifesti RIHA X'i

täieneb MUSTAND

Kvaliteet

nõue  alamnõuded ja soovitused laiendatavus

Süsteemi funktsionaalne skoop on defineeritud ja dokumenteeritud selgesõnaliste kasutuslugudega. Nimetatud kasutuslood peavad olema toote ärilises dokumentatsioonis.

See on ülimalt tähtis, et oleks võimalik toetada automaat- testimist. Kasutuslood on hea alus ka spetsiifilise SLA defineerimiseks, monitoorimiseks ja süsteemi kvaliteedi tagamiseks.

Vaata veel: ISO9000 kvaliteedisüsteem

SOOVITUS

Kasutajafunktsionaalsus peab olema kaetud automaattestidega.

See hõlmab nii kasutajaliidest, kui ka API integratsioone. OOTUS

Rakendused on läbinud koormustestid vähemalt kahekordse eeldatava kasutajamahuga enne toodangusse minekut.

: Lisasoovitus Koormusteste teostada regulaarselt. OOTUS

Keerulisemad sisemised tarkvaralised funktsioonid on kaetud unit-testidega.

Keeruline sisemine tarkvaraline funktsioon on funktsioon või protsess, mille hoomamine võtab rohkem, kui 30 minutit erialast ettevalmistust omavalt tarkvaraarendajalt.

OOTUS

Kasutajaliides kasutab Riigi Infosüsteemide Amet'i pakutavat e-riigi stiiliraamatut.

Leitav https://koodivaramu.eesti.ee/explore/projects SOOVITUS

Rakendus peab töötama veebisirvijates, mis toetavad eID baastarkvara kaht viimast versiooni.

Peamiselt siis veebisirvijad Chrome, Firefox, Internet Explorer, Edge

: Lisasoovitus Brauseri mitteühilduvusel tuleb kasutajale kuvada inimloetavat ja arusaadavat veateadet.

OOTUS

Veebipõhine kasutajaliides järgib HTML5 ja CSS3 standardeid.

https://validator.w3.org/ ning https://jigsaw.w3.org/css-validator/ OOTUS

W AG 2.0?C https://www.w3.org/TR/WCAG20/ MUSTAND

Turvalisus

nõue  alamnõuded ja soovitused laiendatavus SMIT kommentaar

Tarkvara koodile rakendatakse staatilise koodi analüüsi. Näiteks SonarCube OOTUS

Rakenduse tarkvara tööd logitakse ning audit-logi talletatakse rakendusest ning selle baasist eraldi.

Lisasoovitus: Logitakse aeg, kontekst (kes, kus, mida, mis tulemusega) ja kategooria (DEBUG, INFO, WARNING, ERROR, FATAL). DEBUG kategooria talletamine toodangu keskkonnas pole kohustus.

Täpsustusvajadus: Logide maskimine? GDPR?

Lisasoovitus: Rakenduse funktsionaalsus lukustada, kui tuvastatakse, et logitalletamine ebaõnnestub. Võimalusel tuleks arvestada logipuhvriga, et mitte iga võrguhäire puhul teenuseid maha võtta.

KOHUSTUS Kasutame keskset logisüsteemi.

URL ei tohi sisaldada isikuandmeid või sessioonivõtit. OOTUS

Kui ei ole määratud teisiti, peab rakendus olema kasutatav ISKE klassile K2T2S2 vastavate süsteemide loomisel. 

Turvameetmetega tutvu ISKE portaalis. KOHUSTUS Ei. Vastavalt vajadusele.

Kasutaja või rakenduste (sealhulgas ka enda omade) sisendit kontrollitakse ja puhastatakserakenduse poolel vastu rakenduse enda siseseid ootuseid.

See tähendab, et misiganes sisend kasutaja või teise rakenduse poolt vajab puhastamist ja valideerimist oodatud kujule.

OOTUS

Rakenduse väljundit (sealhulgas ka enda oma) tuleb alati puhastada ja filtreerida enne kasutamist.

Näiteks kasutajaliidestes. OOTUS

Krüptoalgoritmide ja räsifunktsioonide kasutamisel tuleb järgida RIA veebilehel avaldatud krüptograafiliste algoritmide elutsükli uuringu värskeimas versioonis toodud soovitusi ja põhimõtteid.

Täpsustusvajadus: Link RIA blogist katki? OOTUS

Kasutajaliides ja tehnilised komponendid suhtlevad üle TLS /SSL'i

See eeldab ka sisevõrkude rakendusi. KOHUSTUS Jah. Uutel asjadel kindlasti.

Rakenduse tehnilised komponendid suhtlevad omavahel üle TLS/SSL'i

OOTUS

Andmehaldus

nõue  alamnõuded ja soovitused laiendatavus SMIT kommtentaar

Andmete kustutamine ei tohi kustutada tegelikke kirjeid andmebaasist, välja arvatud, kui kirjed pole mittefunktsionaalsed, ehk ei oma ärilist seost.

Kustutamine peaks olema kustutamise lipuga või juhul, kui andmed peavad päriselt kaduma, siis need obfuskeerida taastamatult. Unikaalne ID, mis erinevates teistes logides võib olla talletunud, peab aga jääma alles.

OOTUS

Andmed peavad olema talletatud vähemalt UTF-8 enkoodingus.

UTF-16 või UTF-32 on soovitatavad, eriti kui on vajadus talletada ka kasutajate sisendina emoji'sid.

KOHUSTUS Jah

Aja esitamisel tekstikujul lähtuda standardist ISO 8601. Kuupäevad kirjutatakse kujul AAAA-KK-PP. Näide: 2. juuni 2012 kirjutada kujul   

2012-06-02. Kellaajad kirjutatakse kujul hh:mm:ss, kus hh järgib 24-tunnist kellaajaformaati.  Millisekundi täpsusega kellaaja teksti kujul esitamisel kasutatakse formaati hh:mm: ss,nnnn, kus nnnn on millisekundite arv.  Kuupäev ja kellaaeg samas andmeväljas esitatakse kujul, kus kuupäevavormingu ja kellaajavorming vahele lisatakse täht T. Ajaintervallide kirjeldamiseks kasutatakse kahte sama täpsusega (kuupäev, kellaaeg või kuupäev ja kellaaeg) ajavormingut (algus ja lõpp), mis eraldatakse sümboliga /. Vt ka RFC 3339 Date and Time on the Internet: Timestamps, kus määratletakse internetiprotokollidele sobiv ISO 8601 profiil. Märkus. Mõned standardid nõuavad aja esitamist Unix epochvormingus, nt: 1) nt OpenID Connect ja 2) W3C veebiliidesed. Märkus. Aja esitamisel inimkasutajale kasutajaliidestes lähtuda vastavas kultuuris omaksvõetud vormingutest.

OOTUS

Objektid identifitseerida registrikoodide abil.

Riiklikesse registritesse kantavad objektid (isikud, katastriüksused jne) kantakse andmebaasi nende registrikoodiga, mida täiendab riigiprefiks vastavalt ISO3166-1 Alpha 2 standardile. Näiteks isikute sidumiseks süsteemi kasutajakontoga peab kasutama isikukoodi rahvastikuregistrist. Eesti Vabariigi kodanik identifitseeritakse Eesti Vabariigi poolt väljastatud eIDga. Igasuguse muu identifitseerimisevahendi kasutamine peab olema selgelt põhjendatud. Mittekodanike isikuidentifikaator saadakse järgmisel viisil: riigikood + sookood + sünniaeg + [ dok_nr | id_riigis ], kus riigikood - kolmekohaline ISO 3166-1 Alpha-3 standardile vastav riigi kood  sookood - soo identifikaator nii nagu Eesti Vabariigi isikukoodis  sünniaeg - sünniaeg formaadis   YYYYMMDD id_riigis - kui see on olemas, tuleb kasutada isiku koduriigi isikuidentifikaatorit. 16   kohta, 0-polsterdatud vasakult dok_nr - kui isiku koduriigis isikuidentifikaatorit ei ole, siis kasutatakse isiku dokumendi   numbrit. Dokumendi number, 16 kohta, 0-polsterdatud vasakult.

OOTUS

Rakendada aadressiandmete süsteemi nõudeid.

Eesti aadressiandmete sisestamisel, kuvamisel ja hoidmisel lähtuda Vabariigi Valitsuse 8. oktoobri 2015. a määrusest nr 103 „Aadressiandmete süsteem“.

OOTUS

Rakendada klassifikaatorite süsteemi nõudeid.

Eesti tegevusalade andmete sisestamisel, kuvamisel ja hoidmisel lähtuda Vabariigi Valitsuse 10. jaanuari 2008. a määrusest nr 11 „Klassifikaatorite süsteem“ ja kasutada EMTAK infosüsteemis kehtivat klassifikaatorit.

OOTUS

Kui andmebaasis olevate andmete ISKE tervikluse klass on 2 või kõrgem, siis tuleb kõik klass 2 infot sisaldavad andmebaasi kirjed versioneerida.

KOHUSTUS Ei. Vastavalt ärilisele vajadusele.

Kasutatakse Riigi Infosüsteemide Ameti andmejälgijat.

https://www.ria.ee/et/riigi-infosusteem/x-tee/andmejalgija.html OOTUS

Andmebaaside metaandmete kirjeldused peavad olema saadetud manifestina "RIHA"sse

täieneb seoses RIHA X arendustega MUSTAND

Digiriigi tulevikuarhitektuuri suunad Aastal 2020 uuris Majandus- ja Kommunikatsiooniministeerium erinevatelt IT majadelt hetkeseisu erinevate uue generatsiooni tehnoloogiate ja arhitektuurilahenduste kasutamiste ja praktikate kohta. Nii küsimused kui ka vastused leiti olevat ebaühtlased ning otsustati teema võtta lahti peaarhitektide töögrupis, et ühiselt selgitada välja see, mis on erinevate suundade taga päriselt peidus ja mida erinevate sõnade all mõeldakse. 24.05.2021 käis peaarhitektide töögrupp sellel eesmärgil koos.

Käesolev dokument annab kiire ja selge ülevaate digiriigi erinevate haldusalade peaarhitektide poolt kokkulepitud ja läbi räägitud tehnoloogilistest suundadest järgmise generatsiooni digiriigi teenustes.

Digiriigi tulevikuteenused…

● … on kaasaegselt pilvekõlbulikud

● … on ehitatud autonoomsete mikroteenuste põhimõtetele

● … kasutavad orkestreerimis-mootoreid

● … kasutavad sündmuspõhise arhitektuuri lahendusi Iga suuna kohta on välja toodud selle nii tehniline, kui ka äriline selgitus. Dokument on mõeldud nii IT juhile, kui ka toote- ja teenusejuhile ning arendusmeeskondadele.

Majandus- ja Kommunikatsiooniministeeriumi Digiriigi Arengu Osakond seab eesmärgiks nimetatud suundi ja nende suunas liikumist hinnata regulaarselt digiriigi edasises arengus.

PEAARHITEKTIDE TÖÖGRUPP:

● Kristo Vaher - MKM ● Rainer Türner - RIA ● Priit Parmakson - RIA ● Tarmo Hanga - RIA ● Raimo Reiman - RIA ● Mart Järvi - SMIT ● Siim Vene - SMIT ● Sten Viljus - KeMIT ● Martin Õunap - TEHIK ● Kalle Pärtlas - RMIT ● Viljar Tina - RIK

Tulevikuarhitektuuri suund I

Digiriigi tuleviku tehnilised teenused on kaasaegselt pilvekõlbulikud MIKS Digiriik peab olema skaleeruv vastavalt vajadustele. Kaasaegsed pilveplatvormid võimaldavad maksta selle eest, mida su teenused tegelikult kasutavad ja samal ajal võimaldavad jagada ressursse teiste teenustega hetkedel, kui teenustel on koormuse vajadus madalam.

See tähendab, et näiteks Maksu- ja Tolliameti füüsilise isiku tuludeklaratsiooni deklareerimise teenus ei pea igapäevaselt kasutama ja hõivama ressursside vajadust sama suures mahus, kui füüsilise isiku tuludeklaratsiooni avamise päeval ja sellele järgnevatel nädalatel - mis on riigile kallis.

Hea näitena võib välja tuua ka Amazon’i edu pilveteenuste pakkumisel: Amazon teadis, et e-poodide suurimad koormusvajadused on pühadel, mille tarbeks oli vaja suures mahus taristut. Selline taristu on aga hästi kallis pidada läbi terve aasta, mistõttu Amazon tegi strateegilise otsuse tekitada sinna peale teistele kasutatava pilveteenuse, millest tänaseks on saanud üks hinnatumaid pilveteenuseid.

SEOTUD TEHNILISED OOTUSED ● Rakendus ja selle komponendid on skriptiga paigaldatavad ning paigaldamine ja

taastamine toimub automatiseeritava skripti käivitamisega. miinimum: ainult rakendused eesmärk: rakendused, andmebaasid ja muud seotud komponendid

● Rakendus koosneb mitmest paralleelsest instantsist. ● Rakendus on automaatselt skaleeritav ja vajadusel kõrgkäideldav kahe asukoha

vahel. miinimum: kõik active/passive parem: rakendus active/active ja andmebaas active/passive eesmärk: kõik active/active

● Ideaal - aga mitte eesmärk omaette - 12 faktori metodoloogia rakendustes. https://en.wikipedia.org/wiki/Twelve-Factor_App_methodology

TÄHELEPANEKUD

● Mikroteenused on (enamasti) pilvekõlbulikud, aga kõik, mis on pilvekõlbulik ei pruugi olla mikroteenus - ehk ka ärivajaduste tõttu ehitatud monoliit võib siiski olla pilvekõlbulik.

Tulevikuarhitektuuri suund II

Digiriigi tuleviku tehnilised teenused on ehitatud autonoomsete mikroteenuste põhimõtetele MIKS Digiriik peab olema ehitatud paindlikult, et selles oleks võimalik sisse viia muudatusi vastavalt äriprotsessi vajadustele, seadustele ning kodanike ja ettevõtete ootustele võimalikult kiiresti.

See aga tähendab, et tehniline arhitektuur peab olema ehitatud paindlikult, et oleks võimalik sisse viia ärivajadustest lähtuvaid muutuseid. Paindumatu ning tihti monoliitne tehniline arhitektuur hoiab tagasi ka sellest sõltuvat organisatsiooni.

Mikroteenused on arhitektuurimuster tehniliste teenuste ehitamiseks ning on mõeldud selleks, et organisatsioonil säiliks paindlikkus. Autonoomsus tähendab seda, et teenused on võimelised enda piirides toimima ka siis, kui nendega seotud teised teenused on ajutiselt - aga ka jäädavalt - maas või ümberehitamisel. Sarnaselt nagu on autonoomsus tähtis organisatsioonil terviklikult - ehk inimese haigestumine ei tohiks tähendada terve organisatsiooni kinnikiilumist - on see tähtis ka tehniliste teenuste puhul.

Mikroteenused võimaldavad ka paremat tehnoloogiamigratsiooni, ehk kasutusele saab võtta uusi tehnoloogiaid ilma tervet lahendust ümberehitamata. Lisaks võimaldavad mikroteenused ka digiriigis suuremat taaskasutust, sest üksikute domeenide - näiteks TARA näitel riigis autentimine - on jagatav ja taaskasutatav teistele asutustele

SEOTUD TEHNILISED OOTUSED ● Infosüsteem > Domeenid > Mikroteenused > Komponendid

Infosüsteem teenindab erinevaid domeene/rolle organisatsioonis; Domeenide vajadusi katavad erinevaid funktsioone pakkuvad mikroteenused; Mikroteenused koosnevad ühest või mitmest tehnilisest komponendist (sh omaenda andmebaas)

● Infosüsteemid on ehitatud mitmest koosvõimelisest autonoomsest - ehk väheste otseste sõltuvustega - mikroteenusest. Mikroteenus on teenuse komponent, milles on kokku koondatud kõik funktsioonid, mis muutuvad samadel põhjustel - erinevatel põhjustel muutuvad komponendid on tõstetud eraldi mikroteenusteks.

● Mikroteenused ei jaga teiste mikroteenustega andmebaasi, failisüsteemi, mälu jms. Integratsioonid on ainult üle kokkulepitud teenusekihtide (API’d, sh sõnumiruumide API’d)

● Äriloogilised tehnilised komponendid on kasutatavad erinevate kasutajaliideste poolt. Kasutajaliides ja teenuse funktsionaalsus on loogiliselt eristatud kihid ja suhtlevad üle API.

Tulevikuarhitektuuri suund III

Digiriigi tuleviku tehnilised teenused kasutavad orkestreerimis-mootoreid MIKS Digiriigis on mitmed teenused äriliste seoste ja sõltuvustega mitte ainult üle erinevate haldusalade, aga ka haldusala siseselt üle mitme haldusala enda teenuse ja andmekogude. Mitme teenuse tegevuste orkestreerimine - ehk erinevate teenuste tegevuste toimumise tagamine selges ahelas ja selgetel tingimustel - on seetõttu tähtis.

Traditsiooniliselt ehitatakse sellist protsesside sõltuvusahelat infosüsteemide enda sisse, aga see tekitab raskuseid selle hilisemal muutmisel - näiteks olukordades, kus arenduspartner vahetub või on möödas piisav hulk aega ja tehakse tehnilisel muutmisel inimlikke vigu. See lõppeb tihti sellega, et sildistatakse hea lahendus enneaegselt legacy’ks ehk pärandvaraks.

Tihti on suurem äriprotsess ehitatud ja kirjeldatud mitte ainult ühe teenuse, vaid mitme teenuse - ka üle mitme haldusala teenuse - sisse, mis teeb eksponentsiaalselt keeruliseks äriprotsessi muutmise, kui ka sellest selge ülevaate saamise. Rahvusvaheliselt tuntud teenused nagu Netflix ja Spotify on seetõttu pidanud strateegiliselt tähtsaks suure äriarhitektuuri pildi orkestreerimist just läbi tehniliste orkestraatorite, mis annab kai juhtidele tegeliku visuaalse pildi - mitte tõlgenduse - äriprotsessist.

Visioonidokumendis NEXT GENERATION DIGITAL GOVERNMENT ARCHITECTURE tõstsime hüpoteesi, et kuigi orkestreerimislahendused ei pruugi olla ideaalne lahendus tehniliste teenuste äriarhitektuuriliste seoste haldamiseks, siis võib olla see täna just esmajärjekorras esimene lahendus, mida tõsisemalt uurida ja selle jätkusuutlikkust valideerida just selliste vajaduste ulatuses, nagu mitut organisatsiooni koosvõimelisena hõlmav ja teineteisest sõltuv digiriik.

SEOTUD TEHNILISED OOTUSED ● Rakenduste enda sisse on kirjutatud ainult rakenduse enda piiridesse jääv

äriloogika. Üle mitme teenuse sõltuv äriprotsess ei tohi olla kirjutatud teenuste enda sisse.

● Kui tegu on teenusega, millel täna on või tekib tulevikus seos sündmusteenustega või muude haldusalade üleste äriprotsessidega, siis peab olema teenus ehitatud kujul, et ta on orkestreeritav. Ehk rakendusel peab olema API või rakendus peab oskama enda teenust pakkuda mõne sõnumiruumi kaudu.

● Orkestraatori mootoreid nullist ise mitte ehitada. Katsetada rakendusi nagu Camunda, Flowable, jt avatud lähtekoodiga BPM lahendusi.

Tulevikuarhitektuuri suund IV

Digiriigi tuleviku tehnilised teenused kasutavad sündmuspõhise arhitektuuri lahendusi MIKS Sõltuvused osapoolte vahel - nii organisatsiooni enda inimestevahelised sõltuvused või siis tehniliste komponentide vahelised sõltuvused - on üks keerulisemaid kohti mis iganes protsessi disainis. Sarnaselt nagu igapäevaelus oleme frustreeritud, kui kodupanga veeb mingil põhjusel ei tööta, siis me ei taha, et elu sellest täiesti seisma jääb. Organisatsiooni teenuste eest vastutajatena ei taha me selliseid sõltuvusi tekitada ka enda teenuste ja nende tehniliste komponentide vahele.

Teenuste autonoomsuse tagamiseks on sündmuspõhise arhitektuuri lahendused, nagu sõnumiruumid - üks parimaid lahendusi. See tähendab, et üks-ühele sõltuvuste vahele tekitatakse ruum, mis on füüsilises maailmas võrreldav näiteks igapäevase avatud kontori või kabinetiga, kuhu saavad liituda erinevad osapooled ja seal vahetada omavahel erinevaid ülesandeid või infokilde. Samal ajal võimaldavad sellised tehnilised sõnumiruumid ka “järele jõuda”, ehk ajutine ruumis mitteviibimine ei takista teenuse enda edasist tööd - ruumiga uuesti liitudes saab vahepeal kaotsiläinud sõnumid uuesti kätte.

Selline lähenemine võimaldab ka andmete liigutamist laiemalt, kui kahe osapoole vahel, ehk ühte sõnumit või päringut saab korraga edastada mitmele osapoolele ning ruumiga saab panna liituma uusi teenuseid ilma teisi teenuseid ümberehitamata. Selline paindlikkus on igapäevaelus organisatsioonide protsessi disainivatele inimestele iseenesestmõistetav, aga enamus infosüsteemid pole tehniliselt täna sellistel põhimõtetel ehitatud.

SEOTUD TEHNILISED OOTUSED ● Rakenduste sisse mitte ehitada otsepäringuid teiste lõpp-infosüsteemide pihta,

kui selleks pole selget põhjendatud vajadust. ● Rakenduse integratsioonid andmete saatmiseks või pärimiseks või ülesannete

andmiseks disainida asünkroonselt sõnumiruumide kaudu - kui selleks pole põhjendatud vajadust teisiti.

● Sõnumiruumi lahendusi nullist ise mitte ehitada. Katsetada lahendusi nagu Kafka ja RabbitMQ.

● Digiriigis on aga pigem mõistlik kasutada rumalaid sõnumiruume - ehk ruum ise äriprotsessist midagi ei tea ning teadmine ja vastutus jääb andmekogude ja infosüsteemide enda kätte.

● Tulevikus on plaan tagada ka sellise lahenduse kasutamine hõlpsalt otse üle X-tee niiöelda X-ruum lahendusena. Täpsem ajakava ja plaan selle osas on alles selgumisel.

Mida saad sina teha juhi või arhitektina VEEL teha, et tagada enda teenuste areng nendes suundades?

● Tee ja arenda ja ehita ise seda, mida sina tead paremini - muu osta teenusena sisse. Ehk kui su organisatsioon ei oma eesmärki ehitada maailma parimat pilvetaristut, siis tasub pilveteenust osta sisse teenusena kelleltki teiselt. See võimaldab säästa aega, raha ning keskenduda enda organisatsiooni tugevustele ja ärivajadustele. Kontrollküsimus: Kas see toode/teenus, mida me teeme ja arendame ja haldame, on meile unikaalne või teevad sama asja ka teised?

● Organisatsioonis on ülimalt tähtis tagada vastutavates teenustetiimides CI/CD (Continuous Integration/Delivery) võimekus. See tähendab, et arendusmeeskonnad peavad automatiseerima oma arendusprotsesside ja tarneprotsesside kõikvõimalikud rutiinid. Live keskkonda minek peaks olema nupuvajutusega lahendatud. Kontrollküsimus: Kas sinu toode/teenus läheb Live’i ühe nupuvajutusega?

● Kaalu kvaliteedi tagamiseks Chaos Engineering lähenemise juurutamist kas täielikult või vähemalt tähtsamatel teenustel. See tähendab, et sinu teenuste tehniline taristu ei tohiks kaardimajana kõik maha variseda, kui üks või teine suvaline tehniline komponent oma töö ettearvamatult lõpetama peaks. Tehniline teenuste arhitektuur, mis suudab nii vastu pidada on märgatavalt autonoomsem. Vt. veel: https://en.wikipedia.org/wiki/Chaos_engineering Kontrollküsimus: Kui me ühe misiganes komponendi enda tootest/teenusest maha võtame, mis juhtub? Kas teised teenused jäävad püsti? Kuidas me saame kindlad olla? Kas meil on olemas selge plaan sellisteks olukordadeks?

● Valideeri kasutatavate tehnoloogiate pikemat jätkusuutlikkust. Iga tehnoloogia kasutamine - sealhulgas ka programmeerimiskeelte kasutamine - on ajas muutuv. Tagada tuleb, et ei kasutataks tehnoloogiaid, mida enam ei toetata (näiteks mis ei saa enam turvauuendusi) ning ei kasutataks programmeerimiskeeli, mille osas pole turul enam kompetentsi või mille osas on risk, et kompetents on hääbumas. Mõlemal juhul on vaja organisatsioonil tagada selge vastutusega ‘exit plan’ sellisest tehnoloogiast väljamigreerimiseks. Vt. veel: https://www.tiobe.com/tiobe-index/ Kontrollküsimus: Kas meil on kasutuses tehnoloogiaid, mis ei ole TIOBE Top 25 indeksis? Top 50? Mida me teeme, et seda riski minimeerida?

● On tähtis vältida sõltuvust ühte kindlasse partneritesse ja seotud tehnoloogiatesse. Vastasel juhul tekib olukord, kus partner dikteerib üksinda hinda ning muutub raskemaks tehnoloogiamigratsioon. Kontrollküsimus: Kas meie kasutatavad rakendused ja nende koodi on meil võimalik edasi arendada ka teiste partneritega? Kas meie rakendused on meie jaoks avatud lähtekoodi litsentsidega (MIT License, etc).

● On tähtis tagada, et tehnilistel teenustel on olemas põhifunktsionaalsuse ulatuses API’d ja et neid saaks kasutada ilma traditsioonilise veebibrauseri kasutajaliidese või muu seotud rakenduseta. See on vajalik digiriigis nii sündmusteenuste orkestreerimistel, aga mitte ainult, sest see võimaldab enda teenuste funktsionaalsuseid kasutada ka enda teiste tiimide poolt või ka üle haldusalade.

Kontrollküsimus: Kas meie tehnilistel teenustel on olemas API’d ja kas kasutajaliidesed kasutavad ise ka neid samu API’sid?

Tehnoloogiakaart Kui keegi soovib mõnda tehnoloogiat siit eemaldada või juurde lisada, siis palun tulla koos eelanalüüsiga Arhitektuuri ümarlauda. Arendustes tuleb lähtuda siin välja toodud tehnoloogiatest.

Ülevaade Standard Implementatsioon Kommentaarid

Funktsionaalsus Eelistatud ja võib kasutada

Kasutamiseks arhitektuuri nõukoja otsust vaja.

Eelistatud ja võib kasutada

Kasutamiseks arhitektuuri nõukoja otsust vaja.

Integratsioonikiht

Sisemine integratsioon

REST, , AMQP KeyValue store

 JMS, GRAPHQL RabbitMQ, Redis ActiveMQ, Kafka

Väliste osapooltega integratsioon

REST SOAP, GRAPHQL X-tee v6.x

Koormustestid Apache JMeter, k6

Kasutajaliides

Arendusraamistik MVC,MVVM Javascript (Vue. js, Angular)

 C# (.NET) Tekitada näidislahendused koos visualiseerimise raamistikuga.

Rakendusserver Express, Nginx Apache HTTPD

Proxy Server Haproxy, Nginx Apache HTTPD

Testimisraamistik (E2E)

 Playwright Test Cafe,Cypress, Selenium

Vajalik näidisprojektid luua

Serveripoolne osa

Arendusraamistik Java (Spring Boot, Micronaut) 

Groovy ( )Micronaut

Python (Flask)

GO (Gofiber)

C#, Kotlin, Ruby, PHP, Javascript (serveris)

Rakendusserver Apache Tomcat, Nginx, Express

IIS, Apache HTTPD

Sisuhaldusmootor (CMS)

Payload 2

Protsessimootor (BPMN)

Flowable

Raportite genereerimine

JasperReports, OpenPDF

https://github.com/LibrePDF/OpenPDF https://www.jaspersoft.com/products/jaspersoft- community

Näidis: https://source.smit.sise/projects/EXAMPLES /repos/jasperreports-demo/browse

Haldusliides JMX

ORM (andmebaasiga suhtlemise kiht)

Hibernate, JOOQ, GORM, Micronaut Data

https://micronaut.io/launch/

https://start.spring.io

https://gorm.io

https://www.jooq.org

Andmebaas

Relatsiooniline PostgreSQL MS-SQL

MariaDB

Mitterelatsiooniline (NoSQL)

Redis, PostgreSQL MongoDB

MS-SQL

PostgreSQL sisaldab NoSQL võimalusi. Redist ametliku DBAAS teenusena ei pakuta, soovitus ainult cachena kasutada.

Veerupõhine Vertica

SAP IQ

HBase

MS-SQL

Täistekstiotsing Lucene, andmebaasi sisene funktsionaalsus

PostgreSQL ElasticSearch /Opensearch, Solr

MS-SQL

Relatsioonilise andmebaasi struktuuri haldus

Liquibase, Flyway, Alembic

Identifitseerimine

Kataloogiserver LDAP MS Active Directory

Tuvastamine Oauth2 SAML  UAA

Autoriseerimine RBAC  UAA+AD grupid

Identiteedi haldus AD

Platvorm

Kettapind S3, NFS, Voluumkettad

Virtualiseerimine Full Virt Nutanix AHV KVM, Hyper-V, Vmware

Konteiner OCI Kubernetes, Docker virtuaalmasinas

Virtuaalmasin Ubuntu,Oracle Linux, Windows

CentOS Soovitus CentOS 7-et mitte kasutada.

Monitooring

Zabbix MS SCOM

AppDynamics Prometheus

Tehnilised nõuded tarkvaralahendustele

Käesolevad nõuded/põhimõtted spetsifitseerivad millele peaksid loodavad tarkvara komponendid vastama, et nad ei oleks infrastruktuurist jäigalt sõltuvuses, töötaksid SMIT majutusplatvormil, nende skaleerimist  ja paigaldamist saaks automatiseerida ning tehnoloogiline võlg on hallatav ja mõõdetav. Dokument on abimaterjal arendajatele ja arhitektidele kes konkreetset tarkvaralahendust disainivad.

Kategooria Nõue Laiendatavus Kommentaar

Üldine

Rakendused luuakse põhimõttel, kus ühte paigaldatavasse komponenti ei panda kokku sisult väga erinevat funktsionaalsust, vaid pigem jaotatakse vajadusel erinevate komponentide vahel. Komponentideks jaotamine toimub sisulistest, mitte tehnilistest funktsionaalsustest lähtudes v.a kasutajaliideste eraldamine eraldi rakendusteks.  (vt. B )ounded Context

KOHUSTUS Komponentideks jaotamisel mitte lähtuda tehnilitest mõõdikutest nagu koodiridade arv või et tõstame näiteks tehnilise funktsionaalsuse nagu logimise eraldi komponendiks. Kui üks komponent on jäigas sõltuvuses teisest ( ei saa tööprotsessi lõpuni viia või ei saa paigaldada, kui teine ei vasta samal ajal), siis on tegemist hajusa monoliidiga ja tuleks need komponendid kokku tõsta koodi tasemel. Täiendavat lugemist: http://martinfowler.com

/articles/microservices.html https://martinfowler. com/bliki/BoundedContext.html

https://microservices.io/microservices/general /2018/11/04/potholes-in-road-from-monolithic-hell. html

Komponent peab jooksma vähemalt 2 instantsi peal, et vältida platvormi muudatuste käigus tekkida võivaid katkestusi.

KOHUSTUS Konteinerplatvormile paigaldatud rakenduste puhul peaks vähemalt toodangu keskkonnas minimaalselt 2 instantsi jooksma, et vältida katkestusi.

Eelistada ka jõudluse vaates komponentide hulga tõstmist, mitte tõsta olemasolevate komponente ressursikasutust. Näiteks mitte teha VM-e suuremaks (mälu/CPU vaates).

Rakendust ehitatakse ja pakendatakse SMIT CI/CD lahendusega (Bamboo) ning komponendile kohandatakse automaatset staatilise koodi analüüsi vastavalt SonarQube profiilile, mille tulemused on kättesaadavad SMIT SonarQube keskkonnast. Lähtekood ei tohi sisaldada vigu mis on analüsaatori poolt leitud.

KOHUSTUS Kehtib nii loogika kui kasutajaliidese komponendi puhul. Minimaalne on vaikeprofiil, kui arendajad ei lepi kokku täiendavates nõuetes. Täiendav info: Tehnoloogilise võla mõõtmine (SonarQube)

Lähtekood on UTF-8 formaadis ning tekstilised väärtused tuleb liigutada tõlkefailidesse (i8n), lisaks mitte kasutada Deprecated meetodeid.

KOHUSTUS

Rakenduse lähtekoodi haldus toimib SMITi kesksete versioonihalduspõhimõtete järgi.

KOHUSTUS Kehtib nii loogika kui kasutajaliidese komponendi puhul. Lisainfo leiab dokumendist: Lähtekoodi halduse ja ehitamise nõuded

Keskkondadesse rakenduste paigaldamine on automatiseeritud SMIT CI /CD mehhanismidega. 

KOHUSTUS Kasutatakse Bamboo paigaldusplaane:  https://co nfluence.atlassian.com/bamboo/deployment- projects-338363438.html

Kokku ehitatatud rakendust peab saama paigaldada erinevatesse keskkondadesse, ilma et seda peaks uuesti kokku ehitama. 

KOHUSTUS Konfiguratsioon määratakse keskkonna muutujatena või muude rakenduseväliste võimalustega (näiteks Kubernetes configmap) 

Auditlogi tuleb markeerida ära logikirjetes, et oleks pärast otsingus eristatav

KOHUSTUS

Rakendustel puudub ligipääs avalikku internetti (sh klientidel). Kui on vajalik ligipääs äriandmetele väljaspool SMIT võrku, tuleb tellida webproxy ligipääs.

KOHUSTUS

Rakenduste sõltuvuste (maven,npm jne) allikana tuleb kasutada SMIT sisest keskset repositooriumi (Artifactory) .

KOHUSTUS Kõik välised sõltvused peavad olema sealt kättesaadavad.

Kõik välised sõltuvused tuleb rakenduse ehitamisprotsessikäigus läbi skaneerida Artifactory Xray töövahendiga ja mitte kasutada kõrge kriitilisusega turvanõrkuseid sisaldavaid teeke/komponente.  

https://jfrog.com/help/r/jfrog-cli/cli-for-jfrog-xray

Kasutajaliidese sõltuvused/osad nagu JS,CSS,FONTS,GIF jms, mida kasutatakse kasutajaliidese kuvamisel, peavad rakenduse käivitusel tulema samast allikast.

KOHUSTUS Väliste sõltuvuste ja repode kasutamine ei ole lubatud (nagu välised cdn-id, google fonts, github jne). Arendamisel tuleb kontrollida browseri võrguliikluse lehelt, et välisperimeetrisse ei mindaks päringuid tegema.

Väliste teenuste nagu ReCaptcha, Google Analytics jms kasutamine ei ole lubatud.

KOHUSTUS Tuleb kasutada SMIT siseseseid lahendusi.

Rakenduse arhitektuuri koostamisel tuleks arvestada, et rakenduse koosseisu kuuluvaid komponente peab saama uuendada iseseisvalt.

Soovituslik kasutada "Blue-Green" paigalduspõhimõtteid.

Rakenduse loogikakomponentide üldine sisemine arhitektuur peaks järgima MVC mustrit.

Rakendustevahelisi integratsioone teostatakse kokkulepitud põhimõtete järgi (võimalikud variandid on XTEE, HTTP otse või MQ).

KOHUSTUS Kasutatavatest protokollidest olenemata teostatakse integratsioonid, lähtudes nõuetedokumendist: "Rakendustevahelised+int

"egratsioonimustrid

Kui loodav lahendus koosneb mitmest komponendist, on need lahus arendatavad, pakendatavad, versioneeritavad ja paigaldatavad. KOHUSTUS

Testitavus

Komponendil on olemas minimaalne genereeritav testandmete komplekt. Peamiselt koormustestide või suitsutestide läbiviimise keskkonna jaoks.

Test- ja toodangukeskkonnad peavad olema üksteisest lahus ning testandmed ei tohi olla toodanguandmed (v.a juhul kui tegemist ei ole avalike andmetega - näiteks aadressid).

Loogikakomponendil on olemas integratsioonitestid veebiteenuste või sõnumivahetusteenuste jaoks ning vajadusel täiendavad ühiktestid spetsiiflise äriloogika valideerimiseks.

KOHUSTUS  Ühiktestide maht ja olemasolu on vabatahtlik.

Kasutajaliidese automaattestide kirjutamine, mis simuleerivad kasutaja käitumist põhivoogude taseme, on arendusmeeskonna otsustada.

Testide loomisel on soovitav kasutada ilma kasutajaliidesta sirvijat, et oleks võimalik kergesti testida ilma graafilist keskkonda omamata.

Rakenduse automaattestide mahtu tuleb analüüsida CI/CD mehhanismide abil ning tulemused peab publitseerima SMIT SonarQube keskkonnas. KOHUSTUS

Avaklikke teenuseid tuleb täiendavalt turvatestida. KOHUSTUS Turvatestide juhendid ja nõuded leiab dokumendist: Turvatestimine

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

Kasutajaliides

Kasutajaliides tuleb täielikult eraldi arendada loogikakomponendist ning ei eelda selle implementatsiooni olemasolu.

KOHUSTUS

Kasutajaliides võib korraga suhelda mitme loogikakomponendiga.

Kasutajaliides ja loogikakomponent suhtelvad omavahel üle HTTP /WEBSOCKET protokolli ning ainult läbi eeldefineeritud liidestuse (vahetatakse ainult andmeid).

KOHUSTUS Võimalikud integratsioonitehnoloogiad: REST, graphQL, STOMP.

Kasutajaliidese olekut hoitakse kliendi poolel. Kas siis veebilehitsejas (sessionstorage) või sessioonis mis asub kasutajaliidest pakkuvas serverkomponendis.

Kasutajaliides vahetab loogikakomponendiga ainult andmeid, visuaalset sisu (nn. html-i javascripti) sellest komponendist ei laeta.

KOHUSTUS Vaikimisi on andmete formaat JSON

Kasutajaliides suhtleb loogikakomponentidega üle SSL kanali (SSL termineeritakse koormusjaoturis, kust kõik kasutaja päringud läbi lastakse).

KOHUSTUS

Kasutajaliides on soovitav arendada õhukese kliendina.

Äriloogika ja õigused

Komponentide vaheline andmevahetus peab olema turvaline või kaitstud kasutades TLS-i, mille sertifikaate verifitseeritakse. Autentimata ja/või krüpteerimata protokollide kasutamisel rakendatakse täiendavaid konfidentsiaalsust ja terviklust tagavaid turvameetmeid.

Nii sisemised kui välimised süsteemid peavad kasutaja tuvastamiseks kasutama SMIT kesksest tuvastamise teenust (UAA).

KOHUSTUS UAA on tuvastamislahendus, mis on integreeritud lisaks sisemisele parooliga tuvastamisele ka RIA Taraga, et saaks kasutada ID-kaart, Mobiil-Id või SmartId tuvastamisvõimalusi. Rakendustega integratsiooniks kasutame Open-ID protokolli. UAA liidestamise dokumentatsioon: https://docs. cloudfoundry.org/api/uaa/version/76.13.0/index. html#overview

Kasutajaid ja nende grupi või rollipõhiseid õiguseid tuvastatakse kesksest Active Directory andmebaasist. Andmetepõhised õigused (ACL) asuvad rakenduse juures andmebaasis.

KOHUSTUS Vähemalt üks roll peab asuma AD-s (ja selle küljes vastav UAA skoop), mis määratleb kas rakendusele saab ligi. Kehtib kõigi uute arenduste puhul. AD gruppidest võetakse info ja lisatakse see UAA tokeni skoopi. Eeldus on et AD gruppide külge lisatakse skoobi info ning rakendusel ei ole vaja minna AD-sse eraldi grupinfot küsima. 

Komponendid suhtlevad omavahel ainult üle HTTP või JMS/AMPQ protokolli. Suurema jõudluse saavutamiseks on eelistatud sõnumivahetus.

KOHUSTUS Soovitus on kasutada protokolle üle turvalise kanali (HTTPS/AMPQS).

Komponent on sessioonivaba - kasutaja andmete hoidmiseks ei kasutata HTTP sessiooni, vaid iga päringuga valideeritakse "tokeni" kehtivust. Tokenile vastav kasutaja info peab asuma keskses tokeni hoidlas, kus on märgitud ka aegumistähtaeg.

KOHUSTUS Tokenite haldamise mehhanismina tuleb kasutada SMIT kesksest tuvastamise teenust.

Komponendid peavad ka omavahel saama autoriseerituna andmeid vahetada analoogselt kasutajaliidesele ilma sessioone tekitamata.

KOHUSTUS

Komponentide omavahelises integratsioonis peab iga komponent omama oma kontot, ei tohi taaskasutada kontosid, mis on väljastatud teistele rakendustele.

KOHUSTUS Kasutatakse AD-st väljastatavaid teenuskontosid läbi keskse tuvastamise teenuse.

Igal komponendil on oma andmebaas mille skeemi ja süsteemsete andmete muudatusi hallatakse komponendiga koos, kui komponent vajab andmete salvestamise võimekust.

KOHUSTUS Haldab kas rakendus ise või hallatakse eraldi automaatikaga.

Komponendi versiooniuuendusi teostatakse reeglina ilma katkestusteta teenuse töös (tehakse nn. instantsi haaval), andmebaasi muudatuste tegemisel tuleb tagada, et muudatus töötaks ka eelmise komponentide versioonidega (kohustuslike väljade mitmeetapiline sisseviimine jms)

Üks võimalikke lahendusi on näiteks "Blue-Green deployment" mehhanism.

Komponent käivitub ka ilma ühenduseta liidestetavate süsteemidega ehk on nn. nõrgalt liidestatud (v.a andmebaasid)

  KOHUSTUS

Komponent töötab osaliselt edasi ka liidestuste katkestuste puhul ja taastab töö peale katkestuste lõppemist, kõik ühendused on olekuta. "Stateful" ühendused nagu RMI ei ole lubatud kasutada.

KOHUSTUS  Kui rakendusel mingi väline liidestus on maas, siis kas kasutatakse "Circuit Breakerit" või näiteks "retry" mehhanismi teatud pikkusega. Kui võrguühendus taastub, taastab komponent oma töö. Kui ootamine ei ole võimalik, peaks kindlasti "healthcheck" teada andma probleemist, mis võimaldab antud rakenduse vajadusel eemaldada teenindavate komponentide hulgast ja hiljem taastada.

Spring ja Micronaut rakendustes saab kasutada  @Retryable annotatsiooni.

Komponendil puudub eraldi väline konfiguratsioonifail - vajalik konfiguratsioon määratakse kas keskkonna muutujatena või kasutatakse muid platvormi pakutavaid võimalusi (Kubernetese secrets/configmap näiteks).

KOHUSTUS Rakenduse saladused, mida ei genereerita teenuste poolt automaatselt (näiteks andmebaas või s3) tuleb panna saladuste hoidlasse. Saladuste hoidlast saab saladus liikuda rakendusse ainult läbi CI/CD mehhanismi. Saladuste hoidla jaoks on SMIT-is olemas vastav teenus.

Suurte koormuste teenindamiseks vähemuutuvate andmete puhul kasutatakse rakendusserveris vajadusel vähemälusid mis on kesksed, kiired, kõrgkäideldavad ning ei sõltu konkreetse rakendusserveri instantsist. Ei kasuta mitte cachede replitseerimist vaid distributeeritud lahendust.

KOHUSTUS Võimalik kasutada näiteks Redist või olemasolevat andmebaasi selleks ettenähtud tabelite abil.

Komponendil on tööks kõik vajalikud teegid kaasa pakendatud, allolevast operatsioonisüsteemis mingite teekide olemasolu eeldada ei tohi.

Soovituslik komponendi pakendamisformaat on Docker konteiner, mille ehitamisel tohib kasutada ainult SMIT dockerhubis asuvad baasimageid: htt ps://source.smit.sise/projects/dockerhub

Komponent on olekuta ehk kõik mis vaja hoida kauem kui üks süsteemiväline päring (request), salvestatakse kas andmebaasi või mõnda teise hoidlasse.

KOHUSTUS Oleku hoidmiseks kasutatakse väliseid teenuseid.

Komponent ei tohi eeldada failisüsteemi olemasolu, kus andmed säilitatakse. Mälus võib hoida ühe päringu sees opereeritavate andmete olekuid või andmebaasist taasloodavaid cachesid.

KOHUSTUS

Talletamiseks mõeldud binaarfailide jaoks tuleb kasutada eraldi failide hoidmise teenust, mis pakub vastavat veebipõhist teenust.

KOHUSTUS SMIT-is on selleks olemas eraldi sisemine S3 objektihoidla.

Komponentide poolt publitseeritavad REST teenused on versioneeritud, dokumenteeritud ning veahaldust tuleb teostada HTTP veakoodidega. Teenused on peavad olema dokumenteeritud OpenAPI spetsifikatsioonile vastavalt ning spetsifikatsioon peab olema vajadusel eraldi kättesaadav kolmandatale osapooltele.

KOHUSTUS Versiooninumber võib olla kas päises või URI-is. Teenuse tehnilises dokumentatsioonis wikis peab olema link OpenAPI spetsifikatsionile (SwaggerUI). API disainimisel lähtuda dokumendist: "Rakendustevahelised

"integratsioonipõhimõtted

Andmebaas

Andmebaasi "read-only" oleku puhul tuleb andmete muutmise päringutele rakendada kordust (vähemalt 30s), et muudatused õnnestuks, kui baasi kirjutamise funktsionaalsus taastub.

KOHUSTUS Spring ja Micronaut rakendustes saab kasutada  @Retryable annotatsiooni andmebaasi teenusklassides.

Täpsemad näidised: Andmebaasi kirjutamise kordamine

Andmebaaside vahelised integratsioonid ei ole lubatud. KOHUSTUS

Andmebaase komponentide integratsioonivahendina ei tohi kasutada (mitu erinevat komponenti ühe andmebaasi poole pöörduda ei ole lubatud).

KOHUSTUS See põhimõte ei tähenda et ühte sama loogika komponenti jõudluse mõistes skaleerides ei tohiks kasutada sama andmebaasi.

Andmeobjektide muutmisel tuleb luua ka migratsiooniskriptid mis teisendavad automaatselt olemasolevad andmed uuele kujule.

Migratsiooniskripte on soovitav käivitada paigaldusprotsessi ühe osana ja mitte määrata neid käivitatavaks iga rakenduse restardiga (see võib tekitada ebavajalikke lukke rakenduste restartimisel, kui neid on mitu instantsi)

 Kõige lihtsam variant on määrata CI/CD keskkonna muutujaga, kas migratsioon käivitada. Mõistlik on migratsiooni teha ühe intsantsiga, kui see tehtud, siis teha vajadusel uuesti paigaldus mitme instantsiga. Alternatiiv on kasutada "job /task" tüüpi paigaldusmehhanisme tavalise rakenduse paigaldamise asemel.

Andmebaasi äriloogikat vaikimisi ei kirjutata (protseduurid ja triggerid). KOHUSTUS Kõrvalekalded tuleb defineerida ja põhjendada konkreetse komponendi arhitektuuridokumendis - lisaks tuleb ära näidata mehhanismid, kuidas funktsionaalsus töötab andmebaasis, kui kasutusel on mitu andmebaasi instantsi.

Andmebaasi pöördutakse ainult rakenduse jaoks eraldatud süsteemsete kasutajatena.

KOHUSTUS  Mõeldud on, et andmebaasiga suheldakse läbi rakendusele eraldatud kasutaja. SYS ja POSTGRES tüüpi superuser kontodega baasis käia ei tohi.

Operatiiv- ja arhiivi andmebaasid on eraldi lahendused, kasutatakse kas eraldi arhiivibaase või mõnda muud spetsiaallahendust.

KOHUSTUS

Tekstiotsingute jaoks kasutatakse ainult täisteksti indekseid (Lucene või andmebaasi sisemine täistekstiotsing).

KOHUSTUS

Jõudlus

Komponendi sisemised alamosad suhtlevad omavahel võimalusel sõnumivahetuse või muude asünkroonsete meetodite abil, et välistada blokeeruvaid lõimesid ja tagada et iga alamtöö töötab eraldi lõimes, kasutades efektiivselt virtuaalmasinate mitut protsessorituuma - see soovitus ei kehti kui komponentide suhtlus peab toimuma ühe kasutaja transaktsiooni sees (mitte segamini ajada andmebaasi transaktsiooniga).

Lisainfo: , http://12factor.net/concurrency http://ww w.reactivemanifesto.org/

Pikalt töötavad operatsioonid tuleb viia eraldi taustaprotsessideks, mis toimivad ka mitmete instantside puhul, ehk taustatööde info peab olema salvestatud.

KOHUSTUS

Komponent peab peatumisel lõpetama käimasolevad protessid ning pikad taustaprotsessid peavad pooleli jääma ja käimasolev töö tuleb tagastada tööde nimekirja (näiteks "queue").

KOHUSTUS Lisainfo: http://12factor.net/disposability

Komponendis loodud protsessid peavad arvestama, et võib toimuda ootamatu rakenduse seiskumine ning selle tulemusel peavad samuti käimasolevad tööd minema järjekorda tagasi.

KOHUSTUS

Jõudluse kasvamisel saab automaatselt komponentide instantside hulka tõsta (horisontaalne skaleerimine) ning koormus jaotatakse instantside vahel laiali.

Ei tohiks kasutada nö. "scale-up" lahendust, kui seda ei määra konkreetne toote pakkuja.

Komponent peaks käima minema (olema valmis esimeste päringut teenindamiseks) kuni 60 sekundi jooksul

KOHUSTUS

Monitooritav us

Komponentide poolt publitseeritavad teenuste monitoorimiseks vajalik info on kättesaadav kokkulepitud formaadis ja protokolliga - soovitavalt REST formaadis.

KOHUSTUS Koormusjaotur peab aru saama, kas suunata liiklus konkreetsele nodele või mitte. Kõige lihtsam näide või näidis selleks on Spring Boot Actuator endpoint mis annab infot, kas /health rakendus on korras või mitte. Seda saab vastavalt täiendada ka lisainfoga. https://docs. spring.io/spring-boot/docs/current/reference/html

. /production-ready-endpoints.html

Komponenti on võimalik monitoorida APM tarkvara agendiga, mis oskab komponendi seest kõikide lähtekoodis realiseeritud protsesside kohta statistikat (sh. kasutamise sagedus, töötluse aeg) väljastada.

Toetatud tehnoloogiad leiab siit: https://docs. appdynamics.com/display/PRO45 /App+Server+Agents+Supported+Environments

Komponent logib enamus tegevused erinevatel tasemetel ning suunab need "stdouti" või sõnumitena sõnumiserverisse (auditlogi). Komponent ei tegele logifailide haldamisega.

KOHUSTUS Lisainfo: http://12factor.net/logs

Failihaldus  

Kui teenus võtab vastu faili, siis tuleb seda skaneerida ennem baasi või objektihoidlasse salvestamist.

KOHUSTUS Kasutada tuleb SMIT-i poolt pakutavat MetaVault teenust.

Logimine

Erindite (Exception) kinnipüüdmisel tuleb logisse salvestada kogu stacktrace, mitte ainult veateade.

KOHUSTUS

Logimisel tuleb arvesse võtta Infoturbeosakonna poolt kehtestatud logimise nõudeid. 

KOHUSTUS Lisainfot leiab dokumendist " " Logimise nõuded

Taaskasutus

Uut komponenti arendades, tuleks eelnevalt kontrollida, ega sellist pole juba eelnevalt SMIT-is välja töötatud. Eelistatud on kasutada olemasolevat lahendust teenusena ning äärmisel juhul paigaldada endale toode. 

KOHUSTUS

Olemasoleva teenuse koodi eraldamine eraldi projektiks ja selle iseseisev edasiarendus peaks saama SMIT arhitektuuripaneeli heakskiidu, sellele võiks eelneda diskussioon olemasoleva tiimiga, et vajalikud muudatused nemad viiks sisse või aksepteeriksid muudatusettepanekuid.

KOHUSTUS

Kui arendatakse teenust, millele hakkavad olema kliendid väljaspool konkreetset infosüsteemi/lahendust, tuleks luua sellele iseseisev tehnilise liidestuse võimekus.

Üks võimalik tehniline lahendus on Kuberneteses Operator ( )https://operatorframework.io

Arvutitöökoht

Uued seadmed/lahendused peavad olema Windows või IOS põhised KOHUSTUS

Rakendus/lahendus peab olema suuteline vähemalt minor versioone ise uuendama.

KOHUSTUS

Rakenduse paigalduse või uuendamise käigus EI TOHI rakendus arvuti SERVICEID kinni"Disabled" panna (Näide... DocCheck pani ID kaardi serti edastuse teenuse kinni arvutites)

KOHUSTUS

Rakendus/lahendus ei tohi olla seotud ühe konkreetse lehitseja või selle versiooniga. Kõik Tehnoloogia valikute lehel olevad lehitsejad peavad olema toetatud ja testitud.

KOHUSTUS

Kui soovitakse arvutitöökohta paigaldada mingit rakendust/lahendust, siis tarkvara koos konfiguratsiooniga tuleb arenduselt ATKH-le

KOHUSTUS

Valdkond peab kontrollima enda lahendust standard ATK profiilis või eriprofiilis SMIT tehnikupoolt väljastatud seadmes ja kinnitama kas paigaldus on edukas ja vastab teenuse pakkumis nõuetele. Kui ei ole, siis annab infot mida on vaja konfiguratsioonis muuta.

KOHUSTUS

Rakendus peab olema käsurealt paigaldatav. KOHUSTUS

Rakendus ei tohi nõuda administreerimise õigust kasutamiseks KOHUSTUS

Nõuded karbitoodetele. Nõude tüüp

Nõue 1 valik 2 valik kohustuslikkus Keelatud

Alusplatvormid

Rakenduse paigaldamine Kuberneteses konteiner Virtuaalserver

Välised integratsioonid

rakendus ei tohi andmeid SMIT andmekeskusest välja saata

väliseid integratsioone ei ole üldse välisteks integratsioonideks on näiteks tarkvara uuenduste alla laadimised või muud andmete kohale toomised

Litsentsid rakenduse tööks vajalikud litsentsid peavad olema üles loetletud

tasulisi litsentse ei ole

Andmete varundus

kui ostetud lahends kogub andmeid, tuleb need varundada - peab olema võimalik ...

varundatavad andmed asuvad eraldi andmebaasi serveris, milleks on näiteks Postgres 

Süsteemi taastamine

probleemide korral peab olema võimalik lahendus kiirelt tööle panna uues serveris

süsteemile on paigaldusskriptid

Äriloogika ning andmete eraldatus

äriloogikat ning andmeid ei hoita ühes serveris

süsteemi äriloogika töötab rakendusserveris, varundatavad andmed hoitakse andmebaasi serveris

Logimine Logimiseks tuleb kasutada SMITi keskset logiteenust 

Edastavate sündmuste näidised

Tarne Rakendus peab olema läbinud enne toodangusse minemist turvatestimise.

Välistele rakendustele kindlasti partneri pool tehtud pen-testid. 

Arhitektuur Kasutajate tuvastamine Kas meie UAA, TARA või KeyCloack vahendusel?

Tehnoloogiat e valikud

Tehnoloogiakaart

Nõuded arendustele

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

a. b. c. d. e.

Lähtekoodi halduse ja ehitamise nõuded 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 väljastamine 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  töövooge.Continuous Delivery Continuous Deployment

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 kontakt 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 on toimunud vastavad tegevused:

Bamboo ehitusserver on edukalt üleantava haru ära ehitanud SonarQube analüsaator näitab, et SMIT poolt kasutatav   on läbitudQuality Gate SMITi poolne vastuvõtja on tarnele  teinud koodi analüüsi ja need heaks kiitnud Kood on ilma konfliktideta süsteemi poolt mestitud harusse ( on täidetud)"develop" pull-request Kõik tarnes sisalduvad on seotud konkreetsete JIRA piletinumbritega kujul XXXX-YYYcommitid

-i Pull-request kinnitamisel automaatselt kustutatakse vastav arendaja poolt tehtud haru ära, kui mestimine on olnud edukas; Pull-request-i 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); 

-Pull-request i kirjeldus peaks kokkuvõtlikult selgitama üleantava tarne sisu.

Bamboo (CI/CD) kasutamine

Igal tarkvaral on bamboos defineeritud  1 ehitusplaan, mis ehitab ennast " " või " " haru pealt automaatselt (haru valik sõltub, develop master|main kumba protsessi kasutatakse koodi halduseks). Arendajad peaksid oma arendusi tegema " harudes, mida automaatselt Bamboo on võimeline ehitama. Samuti saab vajadusel feature" seadistada Bambood ehitama kõik harusid, mida git-ist leitakse (https://docs.atlassian.com/bamboo-specs-docs/9.4.1/specs.html?yaml#plan-

)branches Bamboo ehitusplaan ehitab  koodi, teeb koodile staatilist analüüsi, võimalusel turvaanalüüsi, jooksutab testid ning olenevalt harust siis paigaldusplaan paigaldab lõpuks rakenduse määratud keskkonda (feature harude puhul paigaldusi ei toimu). Git-flow puhul on reeglina ehitusplaan liidestatud " haruga ning paigaldatakse tulem arenduskeskkonda, testi ja toodangu jaoks develop" versioonid tekivad harude pealt (" " harud reeglina), mida paigaldatakse Bamboo kaudu käsitsi.release Feature-branche-workflow protsessi puhul on ehitusplaan liidestatud " haruga, mille tulemus paigaldatakse automaatselt master|main" testkeskkonda. Võimalus on selle kõrvale luua ka täiendavaid harusid ja siduda neid konkreetse keskkonnaga - näiteks paigaldatakse " "develop automaatselt arenduskeskkonda. 

Toodangu keskkonda paigaldus tehakse käsitsi Bamboo sees  ning sinna paigaldatakse sama tulem, mis läks testi. Bamboo paigaldusprojekt luuakse eraldi git-i spec repona (nimekuju xxx-deploy) ning Bamboo paigaldusprojekti sees on iga keskkond defineeritud eraldi Bamboo "env"-ina ( ).https://docs.atlassian.com/bamboo-specs-docs/9.3.0/specs.html?yaml#environments

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;        8.6.    andmed, mille logimise keeld tuleneb õigusaktidest (nt krediitkaardiandmed). 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, kasutaja loomine, rolli muut(u)mine, seadistuste 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?}

Nõuded infosüsteemi dokumentatsioonile Dokumendid peavad vastama vähemalt alljärgnevatele tingimustele

Sisukord

Süsteemi üldine kirjeldus Andmemudel Kasutaja õiguste ja tegevuste vastavustabel Teenuste/kasutuslugude dokumentatsioon Arhitektuuridokument Seadmete ja tarkvara kasutajakesksed juhendid Paigalduse ja administreerimise juhend Lähtekood (sh andmebaasi struktuur) Koormustestide dokumentatsioon Taasteplaani tegemise juhend

Süsteemi üldine kirjeldus

Eeldus dokumendile

Otstarve Kirjeldada süsteemi üldine olemus

Sisu Dokument sisuks on:

Süsteemi eesmärk sh probleem, mida lahendab ja/või väärtus, mida pakub Süsteemi üldine ülesehitus ning selle protsessid Sisemised ja välised komponendid, nende vahelised liidestumised Peamised nõuded ja vajadused

Sihtgrupp Tellija äriprotsesse valdavad kontaktisikud, ärianalüütikud, süsteemianalüütikud, täitjast sõltumatud tarkvara hooldajad, arendajad ja edasiarendajad, testijad, arhitektid, tootejuhid.

Andmemudel

Eeldus dokumendile Teenuste/kasutuslugude dokumentatsioon

Otstarve Kirjeldada andmeobjekte ja nendevahelisi seoseid

Sisu Andmebaasi põhjal luua andmetabelite ja -objektide seosdiagramm

Sihtgrupp Tellija, peakasutajad, rakenduse administraatorid

Kasutaja õiguste ja tegevuste vastavustabel

Eeldus dokumendile

Süsteemi üldine kirjeldus

Otstarve Kirjeldada kasutaja rollide õigusi erinevates kasutuslugudes ja tegevustes

Sisu CRUD maatriks

Sihtgrupp Tellija äriprotsesse valdavad kontaktisikud, ärianalüütikud, süsteemianalüütikud, täitjast sõltumatud tarkvara hooldajad, arendajad ja edasiarendajad, testijad, arhitektid, tootejuhid.

Teenuste/kasutuslugude dokumentatsioon

1. 2. 3.

4. 5.

6.

Eeldus dokumendile

Süsteemi üldine kirjeldus

Otstarve Kirjeldab detailselt üleantavaid teenuseid/kasutuslugusid

Sisu Teenuste/kasutuslugude detailse kirjelduse sisuks on:

Tehnilised parameetrid; Veateated/Hoiatused; Teostatavad kontrollid; Funktsionaalsuse enda põhiprotsess ja mõned sagedamini esinevad alternatiivsed protsessid (vastavalt vajadusele); Üldine kirjeldus, kuidas ja kus kajastub antud teenus/kasutuslugu tervikprotsessis; Nõudeid ja reegleid toetavad (sisu mõistmisele kaasaaitavad) pildid, diagrammid, tabelid, loendid Andmevahetuse teenuste kirjeldus (andmete küsimine/vastuvõtmine, turvalisus, teenuse andmestik, klassifikaatorid, xml/xsd schema ) Protsesside UML vaated

Sihtgrupp Tellija äriprotsesse valdavad kontaktisikud, ärianalüütikud, süsteemianalüütikud, täitjast sõltumatud tarkvara hooldajad, arendajad ja edasiarendajad, testijad, arhitektid, tootejuhid.

Arhitektuuridokument

Eeldus dokumendile

Süsteemi üldine kirjeldus

Otstarve Dokumendi eesmärgiks on kirjeldada loodava süsteemi üldist ehitust. Kirjeldatakse rakenduse loogilist struktuuri, näidates ära selle kihtideks jagunemise korda. Kirjeldatakse ka füüsilist arhitektuuri, antakse ülevaade kasutatavatest tehnoloogiatest ning vahenditest

Sisu Dokument peab rahuldama vähemalt alljärgnevaid sisunõudeid:

Topoloogia, süsteemi füüsiline arhitektuur (süsteemi komponendid andmebaasiserver, rakendusserver, meiliserver jms) Nõuded arhitektuurile (operatsioonisüsteem, andmebaasid, liidestused, rakendusserverid, raamistikud, teenused) Nõuded käideldavusele (süsteemi soovituslikud näitajad komponentide kaupa, näiteks andmesidekiirused, kättesaadavus, andmemahud, protsessori kiirus, mälumaht, komponentide arv süsteemi osade kaupa, kettasüsteemi jõudlus jms) Liidesed teiste süsteemidega (x-tee, meilisüsteemid) ja sõltuvused teistest süsteemidest. Liideste kirjeldused/otstarve Süsteemi tehnilised (sh automaatsed) protsessid ehk töövoog – komponentide omavahelised suhtlusstsenaariumid ja koostoimimine (näiteks, mis komponent ja millal pöördub n teenuse poole) kolmandate osapoolte poolt toodetud kasutatavad tarkvarad/riistvarad, mis on vajalikud süsteemi toimimiseks

Sihtgrupp Arhitekt, administraator, turvaspetsialist

Seadmete ja tarkvara kasutajakesksed juhendid

Eeldus dokumendile

Teenuste/kasutuslugude dokumentatsioon 

Otstarve Teenuse funktsionaalsuse kasutamiseks ja kasutuslugude läbimiseks vajalikud juhised

Sisu Igale esitluskihile peab olema koostatud eraldi kasutusjuhend, mis kirjeldab vastava komponendi funktsionaalsuse kasutusvoo põhiselt. Kirjeldus tarkvara ja seadmete kasutamise üldisest protsessist, protsessi olulisemate sammude kirjeldus. Koostatakse  projekti lähteanalüüsi aluseks võttes. Tarkvara kasutusjuhend on aluseks kasutajate koolitamisel. Kasutajajuhend kirjeldab kõiki kasutajate funktsionaalsusi koos tööprotsesside kirjeldusega ning ekraanipiltide vormis näidetega. Haldusliidese kasutusjuhend (peakasutaja ja rakenduse administraatori funktsionaalsus) peab olema eraldi tavakasutaja kasutusjuhendist.

Esitluskihi kasutusjuhendi minimaalne ülesehitus:

lühitutvustus üldine kirjeldus koos komponentidega autentimine (kui eksisteerib) komponentide detailne kirjeldus koos kõikide funktsionaalsustega Rollide kirjeldus ja õigused

Sihtgrupp Tarkvara kasutajad, peakasutaja, rakenduse administraator

Paigalduse ja administreerimise juhend

1.

2. 3. 4.

a. b. c. d. e.

Eeldus dokumendile Arhitektuuridokument

Süsteemi üldine kirjeldus 

Otstarve Juhend on aluseks süsteemi administreerimisele 

Sisu Juhend peab rahuldama vähemalt alljärgnevaid sisunõudeid:

süsteemi parameetrite (seadistuste) kirjeldus ning nende muutmiste mõjud ja protseduurid. Konfiguratsioonifailide kirjeldus koos asukohtadega failisüsteemis; logimise realisatsiooni kirjeldused (kuhu, mida, logide struktuur; rutiinsete hooldusprotseduuride kirjeldus (komponentide taaskäivituse vajadus parameetrite muutmisel); paigaldamise protseduurid.

Nõuded rakenduse komponentidele Rakenduse paigaldus (Vajalik tarkvara ja konfigureerimine, rakenduse pakkimine ja paigaldamine) Andmete alglaadimine Varundusskript Monitooringu kirjeldus

Juhendis kirjeldatakse iga realiseeritud osa rakendamine (deployment) koos spetsiifiliste seadistustega. Paigaldamise protseduurid peavad olema kirjutatud selliselt (samm sammult), et süsteemiadministraator suudab rakenduse paigaldada ilma kõrvalise abita.

Sihtgrupp Peakasutaja, projektijuht, süsteemiadministraator

Lähtekood (sh andmebaasi struktuur)

Eeldus dokumendile Arhitektuuridokument

Teenuste/kasutuslugude dokumentatsioon Andmemudel Kasutaja õiguste ja tegevuste vastavustabel Prototüüp 

Otstarve Lähtekood on vajalik selleks et kompileerida rakendust, ning võimaldada tulevikus rakenduse muutmist. 

Sisu Lähtekood peab olema hästi struktureeritud, piisavalt dokumenteeritud ning võimalikult lihtne, et sellest saaksid aru ka teised arendajad. Lähtekood peab vastama MFNile Lähtekood peab olema pakendatud vastavalt versioonimisjuhendile. Rakenduste lähtekood peab olema piisavalt modulaarne, et seda saaks tulevikus lihtsasti täiendada ning muuta.

Koormustestide dokumentatsioon

Eeldus dokumendile Teenuste/kasutuslugude dokumentatsioon

Prototüüp (ainult kasutajaliidesega rakenduse puhul) Arhitektuuridokument

Otstarve Määrata kindlaks arendusetapil testitavad kasutuslood ja liidesed (sh välja tuua need, mille puhul rakendatakse koormusteste) tuues välja nende järjekorra.

Sisu Järjestatud (võib olla ka paralleelne) nimekiri kasutuslugudest ja liidestest (vajadusel määrates nende ulatust) koos märkega, mis on koormustestiga tagatud ning millel on testandmed

Sihtgrupp Tellijapoolne projektijuht, vastuvõtutestijad

Taasteplaani tegemise juhend

Otstarve Kirjeldada erisused, millega tuleb arvestada taasteplaani loomisel

1. 2.

3.

Sisu Taasteplaan peab rahuldama vähemalt alljärgnevaid sisunõudeid:

süsteemi halvamist võimaldavad riskid ja nende esinemise võimalikkus; varundamisele kuuluvate komponentide ja asukohtade loetelu (nt rakenduse konfiguratsioonifailid rakendusserverist ja andmebaas jne), nende kirjeldused ja kasutuselevõtu protseduurid; süsteemi komponentide asendusvõimalused, nende alternatiivkomponentide spetsifikatsioonid

Sihtgrupp Arhitekt, süsteemiadministraator, turvaspetsialist, äri, tellijapoolne projektijuht

KÄSKKIRI

Tallinn 28.01.2025 nr 3-1/10

Avatud hankemenetlusena riigihanke Rahvastikuregistri andmelattu päringu logide baasil

aruannete loomine (288139) korraldamine

Siseministeeriumi infotehnoloogia- ja arenduskeskuse riigihangete korra punkti 6.4 alusel:

1. Viia läbi avatud hankemenetlusena riigihange Rahvastikuregistri andmelattu päringu logide

baasil aruannete loomine.

2. Kinnitada riigihanke alusdokumendid (lisatud). Hanke eest vastutaval isikul on õigus muuta

pakkumuste esitamise tähtaega ning teha alusdokumentides menetluse käigus avastatud

vajalikke mittesisulisi muudatusi ning parandusi.

3. Komisjoni liikmed kohustuvad kinnitama hankemenetluse käigus tehtavates otsustes, et neil

puudub huvide konflikt pakkumuse esitanud iga pakkuja suhtes ning huvide konflikti

ilmnemisel on nad kohustatud teavitama asjaoludest viivitamatult riigihanke eest vastutavat

isikut ja vahetut juhti kirjalikku taasesitamist võimaldavas vormis.

Hankija tegevust on võimalik vaidlustada riigihangete seaduse § 185 sätestatud alustel ja § 189 toodud

tähtaegadel.

(allkirjastatud digitaalselt)

peadirektor

Lisa 1. 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 …

ja

… (täitja), registrikood ……..….., aadress……., keda esindab seaduse alusel/ volikirja alusel …….

1 Üldandmed

1.1 Lepingu sõlmimise alus: riigihange ,,Rahvastikuregistri andmelattu päringu logide baasil

aruannete loomine" (viitenumber 288139).

1.2 Rahastamisallikas: Euroopa Liidu poolt kaasrahastatud Siseministeeriumi valdkondliku

digipöörde 2023-2024 algatuse „RR Andmelao lahenduse II etapp“ vahendid, toetuse kood

1S40-RF21-01212-RR4 (projekti nr 2021-2027.1.02.23-0012).

1.3 Poolte lepingulised kontaktisikud on:

1.3.1 Tellija kontaktisik …………., e-post ………., tel. ….…. või tema asendaja;

1.3.2 Täitja kontaktisik ………...…., e-post …….…., tel. ……...;

1.4 Lepingu lahutamatuks osadeks on järgnevad lisad:

1.4.1 Lisa 1.1 – SMIT töövõtulepingu üldtingimused;

1.4.2 Lisa 1.2 – ÜVA vorm;

1.4.3 Lisa 2 – Tehniline kirjeldus;

1.4.4 Lisa 2.2 – Kodukord;

1.4.5 Lisa 3 – Täitja pakkumus;

1.4.6 Lisa 4 – CV vormid;

1.4.7 Lisa 5 – Mittefunktsionaalsed nõuded

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

alusdokumendid ning täitja riigihankes esitatud pakkumus ja pooltevahelised kirjalikud

teated, mida lepingu lisadena eraldi ei allkirjastata.

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

reeglitest ning prioriteetsuselt hankelepingust ning seejärel käsunduslepingu üldtingimustest.

Kui hankelepingus ei ole välistusi üldtingimustest, siis kohaldatakse üldtingimustes

sätestatut.

2 Lepingu ese

2.1. Täitja teostab järgneva töö: eraldiseisev lahenduse loomine rahvastikuregistri ja tema

kõikide rakenduste poolt tehtavate päringute logide hoidmiseks, aruandluseks ning

hävitamiseks, et parandada RR andmete kasutamise läbipaistvust ning teenuste kvaliteeti

läbi töökindluse ning jõudluse tõstmise.

2.2. Lepingu kogumaksumus on maksimaalselt … eurot, millele lisandub käibemaks.

Kogumaksumus on lõplik ja sisaldab ka kõiki intellektuaalomandiga seotud tasusid.

2.3. Täitja tagab lepingu täitmise 10 kuu jooksul alates töödega alustamisest.

2.4. Töö sisu ja eesmärk on kirjeldatud lepingu lisas 2.

2(5)

3. Lepingu täitmine

3.1 Täitja alustab lepingu täitmist esimesel võimalusel pärast selle sõlmimist, kuid mitte hiljem

kui 15 tööpäeva jooksul lepingu sõlmimisest arvates.

3.2 Tellija annab täitjale teada lepingu 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). Tellija teavitab täitjat lepingu täitmise

hilisemast algustähtajast ja täitmisega viibimise põhjusest e-kirja teel.

3.3 Töid teostatakse Lisa 2 punktis 6 nimetatud etappide kaupa (järjestikku).

3.3.1 Tellija võib (koostöös täitjaga) põhjendatud vajadusel teha täitjale ettepaneku muuta

teostatavate tööde järjestust tingimusel, et ei muutu lepingu täitmise lõpptähtaeg ega

kogumaksumus. Nimetatud muudatused lepitakse kokku poolte kontaktisikute poolt

kirjalikku taasesitamist võimaldavas vormis.

3.4 Täitja 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äitmise ajal

lisanduva alltöövõtja kohta.

3.5 Täitja rakendab tööde teostamisel pakkumuses esitatud meeskonnaliikmeid.

3.6 Arendusmeeskonnas on igapäevase suhtlusvahendina kasutusel Rocket.Chat või Teams või

mõni muu hetkel SMIT-s lubatud suhtlusvahend, mida kasutatakse kiireloomuliseks ja

operatiivseks suhtluseks. Teams / Rocket.Chat või mõne muu kõneteenuse või telefoni kaudu

kokku lepitud otsused tuleb kinnituseks fikseerida e-kirjaga või arutada ja protokollida

koosolekul.

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

iseseisvalt.

3.8 Töid teostatakse üldjuhul tellija asukohas. Väljaspool Siseministeeriumi infotehnoloogia- ja

arenduskeskus (edaspidi SMIT) ning selle haldusala ruume töötamisel transpordikulusid,

sidekulusid, ruumide renti jms Hankija ei hüvita.

3.9 Täitja esindaja võib kasutada isiklikku või Täitja poolt väljastatud töövahendeid

tingimusel, et nende kasutamine ei takista projekti sujuvat valmimist.

4 Vastutus

4.1 Lisaks mujal lepingu dokumentides sätestatud tingimustele on tellijal õigus nõuda ja täitjal

on kohustus maksta leppetrahvi tarne üleandmisega viivitamisel 0,5 % vastava hankelepingu

kogumaksumusest iga viivitatud tööpäeva eest.

4.2 Lepingu olulise rikkumise korral on tellijal õigus esitada täitjale leppetrahvi nõue 10 000

eurot iga rikkumise eest.

5 Tööde vastuvõtmine ja arveldamine

5.1 Tööd antakse üle etappides ning järjestikus, mis on toodud tehnilise kirjelduse punktis 6.

Etappide 1 ja 2 üle andmisel makstakse iga etapi eest 30% lepingu summast, summas …

eurot. Etapi 3 üle andmisel makstakse 40% lepingu summast, summas …

5.2 Peale iga etapi teostamist koostatakse üleandmise-vastuvõtmise akt, mis on aluseks punktis

5.1 nimetatud maksete teostamiseks. Lepinguperioodi lõpus koostatakse terviktulemi

üleandmiseks koondakt, mille järgselt esitab täitja maksjale viimase arve teostatud tööde eest

vastavalt üleandmise-vastuvõtmise aktile ja punktile 5.5.

5.3 Üleandmis-vastuvõtmisakti valmistab ette täitja vastavalt tellija poolt etteantud vormile ning

see allkirjastatakse tellija ja täitja kontaktisikute poolt digitaalselt. Täitja esitab tellijale

3(5)

üleandmis-vastuvõtmisakti, milles on sätestatud täitja poolt teostatud tulemi kirjeldus, ning

tööde maksumus. Vajadusel täpsustatakse aktis üle antud tulemit.

5.4 Arved tuleb edastada vastavalt Eesti e-arve standardile. E-arves peab lisaks standardis

nimetatud andmetele olema toodud tellija kontaktisiku perekonnanimi, riigihanke

viitenumber, hankelepingu number, riigihanke lepingu osa viitenumber ja toetuse kood 1S40-

RF21-01212-RR4. E-arve tuleb saata e-arvete operaatori kaudu. E-arve loetakse laekunuks

selle laekumise kuupäevast.

5.5 Arve maksetähtaeg on 21 kalendripäeva arvates nõuetekohase arve saamisest.

6 Välisvahendite kasutamisest tulenevad nõuded

6.1 Lepingut rahastatakse välisvahenditest.

6.2 Välisvahendite kasutamise lõpptähtpäev on 31.08.2029

6.3 Kui tegevuste raames tekib avalik vaade kliendile, siis lisatakse võimalusel tööde teostaja

logo või viide töö teostajale.

6.4 Pooled on teadlikud ja kohustatud täitma nõudeid, mis kohalduvad partnerile ja Euroopa

Liidu ühtekuuluvus- ja siseturvalisuspoliitika fondidest rahastatud projektidele ning mis on

toodud:

6.4.1 Perioodi 2021–2027 Euroopa Liidu ühtekuuluvus- ja siseturvalisuspoliitika fondide

rakendamise seaduses (https://www.riigiteataja.ee/akt/130062023056);

6.4.2 Vabariigi Valitsuse 12.05.2022 määruses nr 55 „Perioodi 2021–2027 Euroopa Liidu

ühtekuuluvus- ja siseturvalisuspoliitika fondide rakenduskavade vahendite andmise

ja kasutamise üldised tingimused“ (https://www.riigiteataja.ee/akt/105072023254 );

6.4.3 Vabariigi Valitsuse 12.05.2022 määruses nr 54 „Perioodi 2021–2027 ühtekuuluvus-

ja siseturvalisuspoliitika fondide vahendite andmisest avalikkuse teavitamine“

(https://www.riigiteataja.ee/akt/117052022012).

7 Lepingu kehtivus ja selle muutmine

7.1 Leping loetakse sõlmituks hetkest, mil pooled on selle allkirjastanud ning kehtib kuni poolte

kohustuste täitmiseni.

7.2 Tellijal on õigus lepingu täitmise tähtaega pikendada tellijast või vääramatu jõu asjaolu

esinemisest tingitud viivituse võrra.

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 hankeleping täitja suhtes erakorraliselt üles öelda hankelepingu olulise

rikkumise tõttu või muul üldtingimustes kehtestatud alusel.

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 käsunduslepingu üldtingimustega

ja kodukorraga.

4(5)

Leping on allkirjastatud digitaalselt.

Lisa 1.2 Üleandmise-vastuvõtmise akti vorm (ÜVA)

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

Riigihanke viitenumber: ….

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

Vastuvõetud

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

5(5)

…………….. (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/

Siseministeeriumi infotehnoloogia- ja arenduskeskuse

TÖÖVÕTULEPINGUTE ÜLDTINGIMUSED

1. Üldsätted

1.1. Leping koosneb töövõtulepingu üldtingimustest (edaspidi üldtingimused) ja eritingimustest (edaspidi eritingimused) ning nende lisadest, mis reguleerivad tellija,

maksja (kui maksja on eritingimustes kaasatud) ja töövõtja vahel lepingu (edaspidi leping) alusel tekkivaid õigussuhteid.

1. 2. Pooled on oma tegevuses iseseisvad ja kumbki pool ei vastuta teise poole poolt endale

kolmandate isikute ees võetud kohustuste täitmise eest. 1.3. Pooled tagavad ja avaldavad, et lepingu sõlmimisega ei ole nad rikkunud ühegi enda

suhtes kehtiva seaduse, põhikirja või muu õigusakti sätet ega ühtki endale varem sõlmitud lepingute ja kokkulepetega võetud kohustust.

1.4. Pooled kinnitavad ja tõendavad, et:

1.4.1. neil on seaduses ettenähtud piisav õigus- ja teovõime (füüsilisest isikust poole puhul) lepingu sõlmimiseks ning lepingust tulenevate kohustuste täitmiseks ja õiguste

realiseerimiseks; 1.4.2. lepingu allkirjastajale on antud piisavad volitused selle lepingu sõlmimiseks

kooskõlas põhikirjade, õigusaktide ja muude asjakohaste dokumentidega.

1. 5. Lepingu sõlmimisega kaotavad kehtivuse kõik pooltevahelised varasemad lepingud ja muud kokkulepped niivõrd, kuivõrd need on vastuolus lepinguga.

2. Lepingu ese

2.1. Töövõtja poolt tehtavad tööd (edaspidi tööd) on määratletud lepinguga ja selle juurde

kuuluvate dokumentidega. Töövõtjale laieneb ka nende tööde ja toimingute, sh kõrvalkohustuste, teostamise ning teenuste osutamise kohustus, mis ei ole lepingus

sätestatud, kuid mis oma olemusest lähtuvalt kuuluvad lepinguga seotud tööde hulka. Nimetatu ei kuulu teistsuguse kokkuleppe puudumisel eraldi tasustamisele ning töövõtja teostab need tööd, toimingud ja teenused lepingus fikseeritud tähtaja raames

ja tasu eest. 2.2. Töövõtja teostab kogumaksumuse eest ka nn sidustöid, mis ei ole lepingus sõnaselge lt

sätestatud, kuid mille teostamine on headest tavadest ja töövõtja ametiala sest professionaalsusest lähtudes nõutavad ja/või vajalikud lepingust tuleneva eesmärgi saavutamiseks. Sidustööde all ei peeta silmas tellijast tulenevat lähteülesande või

töömahu muudatust.

3. Lepingu täitmine

3.1. Lepingut täidetakse 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)l vahetult osaleda nii meeskonnatöös (koosolekud jmt) kui teostada lepingu esemeks olevaid arendustöid ja saada iseseisvalt, ilma täiendava tellija

poolse juhendamiseta, aru 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öövõtja meeskonnaliikme(te ) le

omal kulul tõlgi, sh juba sõlmitud lepingu täitmise olukorras, kui ilmnevad probleemid eespoolviidatud kompetentsidega.

3.2. Töid teostatakse üldjuhul täitja valitud asukohas tellija ja täitja poolt kokku lepitud arendusmetoodikaid kasutades. Tellija nõudmisel (näiteks, kuid mitte ainult, kui töö ei

valmi oodatud tempos), teostab täitja 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-15:45.

3.3. Töövõtja teostab tööd omal kulul ja vastutusel hoolikalt, kvaliteetselt, tähtaegselt ning professionaalsel tasemel kooskõlas lepingu, õigusaktide, oma tegevus- või kutsealal kehtivate standardite ja heade kommetega ning andma need tellijale või tema poolt

osutatud isikutele üle kokkulepitud ajal ja korras. Töövõtja arvestab tellija poolt tehtud ettepanekuid ning teeb koostööd tellija poolt osutatavate isikutega.

3. 4. Juhul kui füüsilisest isikust töövõtjaga sõlmitud lepingu esemeks olevaks tööks on teose loomine, eeldatakse, et töövõtja loob selle isiklikult, välja arvatud juhul, kui pooled lepivad kokku teisiti. Eelkirjeldatud juhul toimub kolmandate isikute kaasamine

tööde teostamisele (teose loomine) tellija eelneval kirjalikku taasesitamist võimaldavas vormis antud nõusolekul ning tingimusel, et kaasatud isikutega sõlmitud kokkulepped

ei lähe vastuollu lepingutingimustega. 3.5. Töövõtja kohustub rakendama tööde teostamisel muuhulgas meeskonnaliikmeid, kelle

ta on esitanud lepingu sõlmimise aluseks olevas hankemenetluses, meeskonnaliikmete

CV-d on lisatud lepingule. 3.6. Lisaks meeskonnaliikmetele, kelle CV-d on lisatud lepingule, võib töövõtja vajadusel

kaasata lepingu täitmisesse meeskonnaliikmeid, kes ei pea vastama hankemenetluses

vastavatele spetsialistidele tellija poolt kehtestatud nõuetele. Nimetatud spetsialist id

osalevad lepingu täitmisel ainult koos hankemenetluses kehtestatud nõuetele vastavate

spetsialistidega. Töövõtja peab tellijat piisava aja võrra ette kirjalikku taasesitamis t

võimaldaval viisil planeeritavast meeskonnaliikme lisamisest.

3.7. Töid vahetult teostavate spetsialistide asendamine või lisamine võib toimuda vaid tellija

kirjalikku taasesitamist võimaldavas vormis antud nõusolekul. Töövõtja on kohustatud teavitama tellijat kirjalikku taasesitamist võimaldavas vormis meeskonnali ikme

asendamisest/lisamisest vähemalt 20 päeva enne meeskonnaliikme asendamist/lisamis t, kusjuures töövõtja on kohustatud tagama, et uue meeskonnaliikme kompetentsus on võrdne või ületab lepingu sõlmimise aluseks olevas hankes vastavale

meeskonnaliikmele esitatud nõudeid (sh peab uue meeskonnaliikme kompetents olema võrdne või ületama hankemenetluses esitatud meeskonnaliikme hindamiskriteeriumite

kohast kompetentsi). 3.8. Tellijal on õigus keelduda töövõtja poolt lepingu täitmiseks esitatud meeskonnali ikme

asendamiseks või lisamiseks pakutavast meeskonnaliikmest, kui asendamiseks pakutav

spetsialist ei vasta eelnimetatud nõuetele. 3.9. Lisaks punktis 3.7 sätestatule kohustub töövõtja tellijat vähemalt 14 päeva kirjalikku

taasesitamist võimaldavas vormis ette teavitama meeskonnaliikmete planeeritud puhkustest ja lähetustest juhul, kui puhkuse või lähetuse kestus on 4 või rohkem kalendripäeva.

3. 10. Töövõtja annab kogu lepingu täitmise perioodi vältel jooksvalt tagasisidet tellija küsimustele ja arupärimistele ning annab tellija nõudmisel jooksvalt ülevaate ja esitleb

juba teostatud või teostamisel olevaid töid. 3. 11. Tööde teostamise käigus tuleb töövõtjal vajadusel uuendada ka lepingu eseme

dokumentatsiooni (kirjeldused, juhised, protsessianalüüs jmt) ja dokumentats ioon

tellijale kokkulepitud viisil üle anda, v. a juhul, kui see on tehnilises kirjelduses selgesõnaliselt välistatud.. Dokumentatsiooni üleandmisel eelistatakse elektroonil is t

vormi. 3.12. Tellija vastutab tema poolt kaasatud meeskonnaliikmete poolt tellija juhiste kohase

täitmise eest.

3.13. Juhul, kui töövõtja meeskonnaliikmele on tagatud ligipääs tellija asukohale või

infosüsteemidele või on tellija poolt talle kasutusse antud info- ja kommunikatsioonitehnoloogia (edaspidi IKT) seadmed, kohustub töövõtja tagama ja

vastutama töövõtja meeskonnaliikme poolt alljärgnevate juhiste kohase täitmise: 3. 13.1. töövõtja meeskonnaliige kohustub talle eraldatud elektroonilist läbipääsukaart i

kasutama isiklikult ning registreerima sellega oma sisenemise ja väljumise tellija

ruumides; 3.13.2. töövõtja meeskonnaliige kohustub kasutama tellija poolt talle kasutamiseks antud IKT

seadmeid ja ligipääse infosüsteemidele üksnes isiklikult ning üksnes lepingukohaste ülesannete kohaseks täitmiseks. IKT vahendite kasutamisel ei ole töövõtja meeskonnaliikmel õiguspärast ootust privaatsusele ning tellija logib nende tegevus i

IKT seadmetes ja süsteemides. 3. 14. Tellija poolt meeskonnaliikmele antud IKT seadmete ja ligipääsude kasutamisel ei ole

töövõtja poolt kaasatud meeskonnaliikmel õiguspärast ootust privaatsusele ning tellija logib meeskonnaliikmete tegevusi IKT seadmetes ja süsteemides.

3. 15. Tööde üldisteks vastuvõtukriteeriumiteks on:

3. 15.1. vastavus lähteülesandes toodud ärilisele- ja tehnilisele kirjeldusele;

3.15.2. vigade ja kõrvalmõjude puudumine.

3. 16. Tellija poolt meeskonnaliikmele antud IKT seadmete ja ligipääsude kasutamisel ei ole töövõtja poolt kaasatud meeskonnaliikmel õiguspärast ootust privaatsusele ning tellija logib meeskonnaliikmete tegevusi IKT seadmetes ja süsteemides.

4. Töövõtja kohustused:

Töövõtja on kohustatud: 4.1. teavitama viivitamatult, kuid mitte hiljem kui 3 (kolme) tööpäeva jooksul alates

vastavate asjaolude ilmnemisest, tellijat kirjalikku taasesitamist võimaldavas vormis

asjaoludest, mis takistavad lepingu nõuetekohast täitmist, mõjutavad kvaliteed i saavutamist, maksumust või omavad lepingu täitmisele muud ebasoodsat mõju vms.

Seejuures ei anna eelnimetatud juhtumeil informeerimiskohustuse täitmine töövõtjale ilma tellija vastavasisulise lepinguga samas vormis antud nõusolekuta automaatselt õigust ületada tööde kogumaksumust, teostamise tähtaegu, mitte kinni pidada

lepinguga tööde suhtes kehtestatud kvaliteedinõuetest vms; 4.2. tasuma omal kulul kõik lepingu täitmisega seotud autori- ja mistahes iseloomuga muud

tasud kolmandatele isikutele; 4.3. andma valminud tööd ja nendega seotud õigused ning koostatud dokumentats iooni

tellijale üle. Samuti kohustub töövõtja andma tellijale üle andmed kolmandate isikute

intellektuaalse omandi õiguste kohta seoses töödega (nimi, funktsioon tööde teostamisel, õiguste maht jms) ning koostama lepingu täitmisega seotud

dokumentatsiooni eesti keeles, kui tellija ei ole nõustunud muus keeles dokumentatsiooni esitamisega. Tellija nõudmisel tagab töövõtja tõlke omal kulul;

4. 4. järgima tellija juhiseid ning tellija asukoha ruumide kasutamise korda ja teisi

turvalisusega või ohutusega seotud nõudeid ja piiranguid, mida tellija on töövõtjale tutvustanud enne lepingu täitmisele asumist või lepingu täitmise ajal;

4. 5. tagama, et tema poolt kaasatud meeskonnaliige kasutab talle eraldatud elektroonilist läbipääsukaarti isiklikult ning registreerib sellega oma liikumist tellija ruumides, kui tellija on võimaldanud meeskonnaliikmele juurdepääsu tellija ruumidesse;

4.6. tagama, et töövõtja poolt kaasatud meeskonnaliige kasutab tellija poolt talle kasutamiseks antud vara, seadmeid ja ligipääse infosüsteemidele üksnes isiklikult ,

otstarbekohaselt ja heaperemehelikult, üksnes lepinguliste kohustuste kohaseks täitmiseks ning tagama talle usaldatud vara kaitstuse ja säilimise. Töövõtja kannab

varalist vastutust tema meeskonnaliikme tahtliku või hooletu käitumise tõttu tellija le

tekitatud kahju eest; 4.7. täitma muid tööde teostamisega kaasnevaid ning lepingus ja õigusaktides sätestatud

kohustusi. 5. Töövõtja õigused

Töövõtjal on õigus: 5. 1. nõuda tellijalt lepingutingimustest kinnipidamist;

5.2. saada tellijalt tööde teostamise eest tasu lepingus sätestatud tingimustel ja korras; 5.3. teha tellijale ettepanekuid tööde teostamise osas, esitades selle kohta omapoolsed

põhjendused kirjalikku taasesitamist võimaldavas vormis, mille tellija vaatab läbi ja

teatab töövõtjale otsustusest ettepaneku arvestamise või arvestamata jätmise kohta; 5.4. nõuda tellijast sõltuvate õigusvastaste takistuste kõrvaldamist tööde teostamisel;

5.5. nõuda tööde teostamisega seotud koosolekute korraldamist, kui see on vältimatu tööde normaalseks teostamiseks, tähtaegadest kinnipidamiseks ja kvaliteedi tagamiseks. Tellija korraldab töövõtja eelkirjeldatud nõudmisel koosoleku 3 (kolme) tööpäeva

jooksul alates töövõtja vastavast kirjalikku taasesitamist võimaldavas vormis edastatud nõudmisest.

5. 6. teostada muid lepingus ja õigusaktides sätestatud õigusi. 6. Tellija kohustused

Tellija on kohustatud: 6.1. maksma töövõtjale tööde eest tasu lepingus sätestatud tingimustel ja korras;

6.2. looma töövõtjale tööde teostamiseks vajalikud tingimused vastavalt eritingimustes sätestatule;

6. 3. kõikidele töövõtja lepingu täitmisega seotud põhjendatud küsimustele vastama

hiljemalt kolme tööpäeva jooksul. Juhul, kui küsimusele vastamine nõuab tellija lt pikemat analüüsi, on tellija kohustatud andma eeltoodud 3 (kolme) tööpäeva jooksul

töövõtjale täpse kuupäeva, millal tagasisidet antakse; 6.4. mitte tegema töövõtjale põhjendamatult takistusi tööde teostamisel; 6.5. vastu võtma töövõtja poolt nõuetekohaselt teostatud lepingujärgsed tööd;

6. 6. osalema töödega seotud korralistel koosolekutel; 6.7. täitma muid lepingus ja õigusaktides sätestatud kohustusi.

7. Tellija õigused

Tellijal on õigus:

7. 1. nõuda töövõtjalt lepingutingimustest kinnipidamist; 7.2. põhjendatult keelduda kooskõlastamast töövõtja poolt kooskõlastamiseks

esitatud ettepanekuid; 7.3. kutsuda kokku poolte koosolek, sellest töövõtjale võimalusel 3 (kolm) tööpäeva

kirjalikku taasesitamist võimaldavas vormis ette teatades;

7.4. lisaks seaduses sätestatud juhtudele pikendada poolte kokkuleppel lepingu täitmise või kehtivuse tähtaega kuni kuue kuu võrra;

7. 5. kaasata lepingu täitmisse tellija poolele (eelkõige maksja rollis) teisi riigiasutusi; 7. 6. igal ajal kontrollida lepingu eseme vastavust lepingule ja nõuda töövõtjalt

informatsiooni lepingu täitmise kohta.

8. Taustakontrolli teostamine

8.1. Kõigi töövõtja poolt töid teostavate meeskonnaliikmete osas viiakse enne nende poolt

tööde teostamisega alustamist läbi politsei ja piirivalve seaduse § 7(59) sätestatud taustakontroll (alus § 7 (59) lg 1 p 2).

8. 2. Töövõtja on kohustatud informeerima tööle asuvaid meeskonnaliikmeid taustakontro lli teostamise vajadusest.

8.3. Taustakontrolli läbiviimiseks edastab töövõtja tellijale tellija etteantud nõusoleku vormil

vastava meeskonnaliikme kirjaliku nõusoleku hiljemalt 5 (viie) tööpäeva jooksul. Juhul, kui töövõtja ei edasta viidatud aja jooksul nõusolekut, loetakse see töövõtja poolseks

viivituseks. 8.4. Kui meeskonnaliige keeldub taustakontrolliks nõusoleku andmisest, keeldub tellija

vastava meeskonnaliikme tööle lubamisest ning nõuab meeskonnaliikme vahetamist.

8.5. Tellijal on õigus keelduda meeskonnaliiget töid teostama lubamast, kui taustakontro lli tulemusena teatavaks saanud informatsiooni kohaselt ei ole meeskonnaliige sobilik

tellija töid teostama. Lähtuvalt informatsiooni tundlikkusest, ei avaldata töövõtjale taustakontrolli käigus saadud andmeid.

8.6. Juhul kui meeskonnaliige ei nõustu taustakontrolliga või ei osutu selle tulemusena

tellijale sobivaks, kohustub töövõtja tagama meeskonnaliikme kohese vahetamise. Kui konkreetses tellimuses või lepingus ei ole sätestatud teisiti, siis nimetatud põhjusel

meeskonnaliikme vahetamine ei ole aluseks tarne tähtaja muutmiseks.

9. Lepingu maksumus, arveldamise kord

9.1. Lepingu maksumus sisaldab endas muuhulgas töövõtja poolt lepingu raames tehtavaid kõiki kulutusi ja tasu lepingus sätestatud autoriõiguste eest (autori varaliste õiguste

loovutamine ja isiklike õiguste osas kasutusõiguse ehk litsentsi andmine), samuti kõiki muid tööde teostamiseks tehtud kulutusi.

9.2. Tellija tasub töövõtjale nõuetekohaselt teostatud tööde eest vastavalt eritingimustes

sätestatule, kas peale poolte poolt tööde üleandmis-vastuvõtmisakti (edaspidi ÜVA) allkirjastamist ning selle alusel esitatud arve saamist ja selle heakskiitmist või peale

tööde teostamist esitatud arve saamist või füüsilisest isikust töövõtja korral peale poolte poolt tööde ÜVA allkirjastamist.

9.3. Arve esitamise õigus tekib pärast ÜVA allkirjastamist poolte poolt.

9.4. Arve maksetähtaeg peab olema vähemalt 21 (kakskümmend üks) kalendripäeva arvates selle kättesaamisest. Juhul kui lepingu maksumus tasutakse füüsilisest isikust

töövõtjale, makstakse lepingu täitmise eest hiljemalt 14. (neljateistkümnenda l) kalendripäeval pärast tööde üleandmise-vastuvõtmise akti allkirjastamist.

9. 5. Kui töövõtja on Eestis registreeritud ettevõte, saadab töövõtja tellijale Eesti e-arve

standardile vastava e-arve e-arvete operaatori kaudu. Kui töövõtja ei ole Eestis registreeritud ettevõte, saadab töövõtja tellijale pdf formaadis e-arve e-posti aadressile

[email protected]. E-arve loetakse laekunuks selle laekumise kuupäevast. 9. 6. Arvel peab lisaks standardis nimetatud andmetele olema toodud tellija kontaktisiku

perekonnanimi, riigihanke viitenumber, hankelepingu number (kui on asjakohane) ja

tellimuse viitenumber (kui on asjakohane), hankelepingu osa 15-kohaline viitenumber ning välisvahendite projekti tunnus (kui on tegemist välisvahenditest rahastatava

lepinguga). 9.7. Tingimustele mittevastav arve ei kuulu tasumisele. Arve maksetähtaeg on

kakskümmend üks kalendripäeva, v.a juhul, kui kohalduvate välisvahend ite

tingimustest tuleneb ja on konkreetses lepingus sätestatud teisiti. 9. 8. Juhul kui pooled on lepingus sätestanud lepingu maksimaalse maksumuse, käsitlevad

pooled nimetatud summat indikatiivsena, st kui leping öeldakse kooskõlas lepingu tingimustega üles või on tellija esitanud lepingu alusel tellimusi lepingu lõppemise

hetkeks väiksemas mahus kui on lepingu maksimaalne maksumus, ei kuulu

maksimaalse maksumuse ja tegeliku maksumuse vahe töövõtjale välja maksmisele ega muul moel hüvitamisele.

9. 9. Juhul kui tellijal on alus nõuda töövõtjalt leppetrahvi ja/või kahju hüvitamist, on tellija l õigus leppetrahv ja/või kahjutasu maha arvata lepingu alusel töövõtjale tasumise le kuuluvast summast.

9.10. Juhul kui tööd ei vasta lepingus toodud nõuetele, võib tellija lepingu maksumust ühepoolselt alandada, teavitades sellest töövõtjat kirjalikku taasesitamist võimaldavas

vormis. 10. Tööde kvaliteet. Üleandmine ja vastuvõtt

10.1. Tehtud tööde kvaliteet peab vastama vähemalt lepingus toodud nõuetele ja antud töödele tavapäraselt esitatavatele nõuetele. Nimetatud nõuetele peavad vastama ka

tööde juurde kuuluvad dokumendid jms. 10.2. Pretensioonid töö tulemi plaanipärase edenemise, teostamise efektiivsuse ja kvaliteed i

kohta annab tellija teada lisaks meeskonnaliikmele ka töövõtja lepingulise le

kontaktisikule. Olulises ulatuses või korduvaid kõrvalekaldeid tellija juhiste järgimata jätmisel loetakse lepingu rikkumiseks.

10.3. Lepingu ese antakse töövõtja poolt tellijale üle tellija asukohas kooskõlas lepingu tingimustega.

10.4. Tellijal on kakskümmend tööpäeva aega kontrollida vastuvõtmiseks esitatud tööde

lepingutingimustele vastavust ning ÜVA allkirjastamiseks. Tellija võib nimetatud tähtaega pikendada, kui pikendamine on põhjendatud.

10.5. Kui lepingu eseme vastuvõtmine toimub arve heakskiitmise teel, tuleb see sätestada lepingu eritingimustes, tellimuses või pakkumise esitamise ettepanekus.

10.6. ÜVA valmistab ette töövõtja vastavalt tellija poolt etteantud vormile ning see

allkirjastatakse tellija ja töövõtja kontaktisikute poolt digitaalselt. Töövõtja esitab tellijale iga hankelepingu punktis 4.1 nimetatud lõppenud etapi järel ÜVA, milles on

sätestatud töövõtja poolt teostatud tööde etapi nr, tulemi kirjeldus, ning vastava etapi tööde maksumus. Vajadusel täpsustatakse aktis üle antud tulemit.

10.7. Töö loetakse vastu võetuks ÜVA allkirjastamise hetkest, kuid mitte hiljem kui tulem on

toodangukeskkonnas kasutusele võetud. Juhul kui töö võetakse töö tulemis esinevate vigade tõttu toodangukeskkonnas (live) kasutusele osaliselt, siis fikseeritakse ÜVA-s,

millises osas on tööd vastu võetud ning kuuluvad tasumisele. 10.8. Juhul kui tellija ei ole punktis 10.4 nimetatud tähtaja jooksul ÜVA allkirjastanud ega

teatanud tähtaja pikendamisest, loetakse lepingu ese vastuvõetuks ning vastuvõtmise

hetkeks punktis 10.4 sätestatud tähtaja möödumisele järgnevat kalendripäeva. Käesolevas punktis sätestatu ei kuulu kohaldamisele juhul, kui lepingut rahastatakse

osaliselt või täielikult välisvahenditest. 10.9. Juhul kui tellija avastab vastuvõtmiseks esitatud lepingu esemes vigu, puudusi või muu

lepingutingimustele mittevastavuse, on töövõtja lepingu rikkumises ning rikkumise

kõrvaldamine toimub tellija sellekohaste juhiste alusel. 10.10. Tellijal on õigus puudustega lepingu eseme vastuvõtmisest keelduda, näidates ära

keeldumise põhjused või võtta puudustega lepingu ese vastu, lisades puuduste või vaegtööde nimekirja koos puuduste kõrvaldamise tähtajaga ÜVA-s. ÜVA allkirjastamisega kinnitab töövõtja, et on teadlik märgitud puuduste kõrvaldamise ja

vaegtööde teostamise tähtaegadest ning võtab kohustuse nendest tähtaegadest kinni pidada. Kõrvaldatud puuduste kohta vormistatakse eraldi ÜVA.

10.11. Tellija ei tasusta aega, mis kulub töövõtjal korduvate vigade lahendamiseks (näiteks samaliigiliste probleemide kordumine lähtekoodis vaatamata tellija varasemale

tagasisidele koodiülevaatuste käigus) ning tellijal on õigus vähendada töövõtjale

makstavat tasu korduvate vigade ülevaatamise eest 70 euro võrra tunnis, mille le lisandub käibemaks.

10.12. Kui tellijal puuduvad lepingu eseme osas pretensioonid, allkirjastavad pooled lepingu eseme ÜVA.

10.13. Töövõtja annab tellijale koos ÜVA-ga üle lepingu eseme juurde kuuluva tehnilise ja

muu lepingu eseme kasutamiseks ja haldamiseks vajaliku dokumentatsiooni tellija soovi kohaselt kas paberil ja/või elektroonilisel andmekandjal (CD/DVD vms) ja/või

e-posti teel või paigaldab selle tellija näidatud keskkonda. 10.14. Kui arendustööde üleandmiseks ei ole ÜVA allkirjastatud ja ei kohaldu punkt 10.8,

loetakse arendustööde vastuvõtmise ajaks päeva, mil tellija on töö tulemi tervikuna

toodangukeskkonnas (live) kasutusele võtnud. Käesolevas punktis sätestatu ei kuulu kohaldamisele juhul, kui lepingut rahastatakse osaliselt või täielikult välisvahenditest.

10.15. Tellija poolt lepingu eseme vastuvõtmine ei vabasta töövõtjat vastutusest lepingu eseme üleandmisel-vastuvõtmisel avastamata jäänud vigade või nende mittenõuetekohasuse eest ning töövõtja kohustub lepingu eseme üleandmise hetkel

esinenud vastavad vead või puudused kõrvaldama omal kulul mõistliku aja jooksul. 10.16. Kui töövõtja ei nõustu tellija poolt lepingu eseme vastuvõtmisest keeldumisel või

puudustega või vigadega vastuvõtmisel tuvastatud vigade või puuduste olemasoluga, on töövõtjal õigus nõuda ekspertiisi teostamist. Sel juhul tellib töövõtja tellija poolt osundatud lepingu eseme puuduste või vigade tuvastamiseks tellijaga kokku lepitud

isikult ekspertiisi. Kui ekspertiisi tulemusel ilmneb, et tööde vastuvõtmisest keeldumine on olnud põhjendamatu, hüvitab tellija töövõtjale ekspertiisikulud, vastasel

korral kannab ekspertiisikulud töövõtja. Kui ekspertiisi tulemusel ilmneb, et tellija osundatud lepingu eseme puudused või vead olid osaliselt põhjendatud, hüvitab tellija töövõtjale ekspertiisikulud proportsionaalselt üksnes nende puuduste või vigade osas

ekspertiisi kogukuludest, mille puudumist ekspertiis on tuvastanud.

11. Poolte vastutus. Vääramatu jõud

11.1. Pooled vastutavad lepinguliste kohustuste rikkumise eest. Kohustuse rikkumisel on teisel poolel õigus kasutada kõiki seadusest või lepingust tuleneva id

õiguskaitsevahendeid vastavalt võlaõigusseadusele. 11.2. Töövõtja vastutab igasuguse lepingurikkumise eest, eelkõige kui tööd ei vasta lepingus

ja selle lisades kokkulepitud nõuetele. Tööd loetakse muuhulgas mittevastavaks juhul, kui töövõtja ei esita tööde üleandmisel-vastuvõtmisel tööde kohta nõuetekohast dokumentatsiooni, ei anna töid tähtaegselt üle, ei teosta töid nõuetekohaselt, jätab

tellijale lepingu täitmise kohta informatsiooni esitamata vms. 11.3. Juhul kui töövõtja rikub lepingust tulenevat kohustust, mille heastamine ei ole

võimalik, on tellijal õigus nõuda töövõtjalt leppetrahvi 5% lepingu maksumusest iga rikkumise eest. Juhul kui tegemist on olulise lepingurikkumisega, on tellijal lisaks leppetrahvinõudele õigus ka leping erakorraliselt ühepoolselt lõpetada.

11.4. Juhul kui töövõtja rikub lepingust tulenevat kohustust, mille heastamine on võimalik, on tellijal õigus esitada töövõtjale nõue rikkumiste kõrvaldamiseks (edaspidi ka

„ettekirjutus“), andes töövõtjale rikkumise kõrvaldamiseks mõistliku tähtaja (sõltuva lt tööde iseloomust, rikkumise asjaoludest jms, kuid üldjuhul mitte rohkem kui 5 (viis) tööpäeva). Kui töövõtja ei täida ettekirjutust selleks antud tähtaja jooksul, peab töövõtja

maksma tellijale leppetrahvi 1 % lepingu maksumusest iga rikkumise kõrvaldamisega viivitatud päeva eest, välja arvatud punktis 11.3 või 11.8 sätestatud juhtudel, mil

kohaldatakse nimetatud punktis sätestatud leppetrahvimäära. 11.5. Samuti annab töövõtja poolt rikkumise kõrvaldamisega viivitamine vaatamata tellija

poolt ettekirjutuse tegemisele tellijale õiguse leping erakorraliselt ühepoolselt lõpetada.

Juhul kui tegemist on olulise rikkumisega, ei pea tellija töövõtjale rikkumise kõrvaldamiseks täiendavat tähtaega andma ning võib lepingu olulise rikkumise

esinemisel erakorraliselt ühepoolselt lõpetada. 11.6. Juhul kui töövõtja viivitab tööde teostamise või üleandmisega või garantiitööde

teostamisega üle lepingus kokku lepitud tähtpäevade, on tellijal õigus nõuda töövõtjalt

leppetrahvi, mille suuruseks on 1% teostamata või üle andmata töö maksumusest iga viivitatud päeva eest.

11.7. Töövõtja kohustub hüvitama kõik kulud ja kahjud, mis tekivad tellijale seoses töövõtja poolt teostatud töödes esinevate puudustega.

11.8. Lepingu olulise rikkumise korral on tellijal õigus esitada töövõtjale leppetrahvi nõue 10

000 eurot iga rikkumise eest. Töövõtja poolse olulise lepingu rikkumise korral ei pea tellija määrama töövõtjale lepingu täitmiseks võlaõigusseaduse §-s 114 nimetatud

täiendavat tähtaega ning tellijal on muu hulgas õigus leping üles öelda või lepingus t taganeda.

11.9. Oluliseks rikkumiseks loevad pooled lisaks võlaõigusseaduses ja mujal lepingus

sätestatule muuhulgas: 11.9.1. mõjuva põhjuseta lepingu täitmise katkestamine või täitmisele mitte asumine;

11.9.2. valeinfo esitamine; 11.9.3. lepingu täitmiseks vajalike õiguste (sealhulgas load, litsentsid, intellektuaalse omandi

õigused) puudumine;

11.9.4. intellektuaalse omandi õiguste ja nende kasutamise tingimuste rikkumine; 11.9.5. korduv (vähemalt kahel korral) meeskonnaliikme asendamine isikuga, kes ei vasta

kokku lepitud nõuetele või meeskonnaliikme asendamine ilma tellija eelneva vähemalt kirjalikku taasesitamist võimaldavas vormis antud nõusolekuta;

11.9.6. lepingu täitmisel korduv (vähemalt kahel korral) VÕS §-des 5 ja 6 sätestatud hea usu

ja mõistlikkuse põhimõtete mittejärgimine, sh koostöö takistamine tellija ja tema määratud isikute vahel ja lepingus määratud eesmärkide saavutamise takistamine;

11.9.7. konfidentsiaalsuskohustuse rikkumine; 11.9.8. lepingujärgsete kohustuste korduvat (vähemalt kahel korral) täitmata jätmist; 11.9.9. tähtaegselt lepingu täitmata jätmist selliselt, et tehnilises kirjelduses sätestatud

eesmärgi täitmine ei ole enam tähtaegselt realistlik ja/või töövõtja poolse tegevuse või tegevusetuse tõttu ei ole võimalik enam kasutada lepingu rahastamiseks ettenähtud

vahendeid; 11.9.10. lepingujärgsete kohustuste üleandmine kolmandale isikule ilma tellija

digiallkirjastatud nõusolekuta.

11.10. Lepingu erakorraline lõpetamine ei võta tellijalt õigust nõuda töövõtjalt leppetrahvi ja kahju hüvitamist. Juhul kui ühe ja sama rikkumise eest võimaldab leping nõuda

leppetrahvi mitme sätte alusel, on tellijal õigus otsustada, millise sätte alusel ta leppetrahvi nõuab.

11.10.1. Tellijal on õigus tööde eest tasumisel vähendada lepingu maksumust

leppetrahvi summa võrra. Lepingus sätestatud leppetrahvid on kokku lepitud kohustuste täitmisele sundimiseks ning leppetrahvi nõudmine ei mõjuta tellija õigust

nõuda töövõtjalt täiendavalt ka kohustuse täitmist ja kahju hüvitamist. 11.10.2. Juhul kui tellija viivitab lepingus sätestatud rahaliste kohustuste täitmisega, on

töövõtjal õigus nõuda tellijalt viivist 0,05% (null koma null viis protsenti) päevas

tähtaegselt tasumata summalt, kuid mitte rohkem kui 5% (viis protsenti) lepingu maksumusest.

11.11. Lepingust tulenevate kohustuste mittetäitmist või mittenõuetekohast täitmist ei loeta lepingu rikkumiseks, kui selle põhjuseks oli vääramatu jõud. Kui vääramatu jõu

asjaolude tõttu on poole lepingust tulenevate kohustuste täitmine takistatud enam kui

60 (kuuskümmend) kalendripäeva järjest, võib kumbki pool lepingu lõpetada. 11.12. Poolte koguvastutus lepingu täitmisel on piiratud lepingu kogumaksumusega, v.a

konfidentsiaalsuskohustuse rikkumisel tahtlikult või raskest hooletusest. 12. Teadete edastamine ja kontaktisikud

12.1. Teadete edastamine toimub üldjuhul telefoni, e-posti või posti teel. Juhul kui teate edastamisel on olulised õiguslikud tagajärjed, peavad teisele poolele edastatavad teated

olema edastatud kirjalikus vormis, muuhulgas näiteks poolte lepingu lõpetamise avaldused, samuti poole nõue teisele poolele, mis esitatakse tulenevalt lepingu rikkumisest jms.

12.2. Lepinguga seotud teated edastatakse teisele poolele lepingus märgitud kontaktandmetel. Kontaktandmete muutusest on pool kohustatud koheselt

informeerima teist poolt. Juhul kui pool on lepingu kehtivuse aja jooksul muutnud oma kontaktandmeid ning ei ole sellest teist poolt kirjalikku taasesitamist võimaldavas vormis informeerinud, loetakse teade poole poolt kättesaaduks, kui see on saadetud

kõige viimastel poole poolt teatatud kontaktandmetel. 12.3. Kirjalik teade loetakse poole poolt kättesaaduks, kui see on üle antud allkirja vastu või

kui teade on saadetud postiasutuse poolt tähitud kirjaga poole poolt teatatud aadressil ja postitamisest on möödunud 5 (viis) kalendripäeva. E-posti teel, sh digitaa lse lt allkirjastatud dokumentide, saatmise korral loetakse teade kättesaaduks kohale

jõudmise teates märgitud kellaajal või e-kirjas näidatud saatmise kellaajal. 12.4. Poolte kontaktisikud on määratud lepingu eritingimustes. Tellija kontaktisikul on õigus

esindada tellijat kõikides lepingu täitmisega seotud küsimustes, v.a lepingu muutmine (sh lepingu mahu suurendamine, lepingu eseme või tähtaja oluline muutmine jms), lepingu ühepoolne erakorraline lõpetamine ning leppetrahvi, viivise või kahjude

hüvitamise nõude esitamine.

13. Omandiõigus. Autoriõigused. Dokumentide ja informatsiooni säilitamine

13.1. Lepingu alusel töövõtja poolt loodud või tema poolt kolmandatelt isikutelt omandatud ja lepingu alusel tellija poolt vastuvõetud ning tasutud lepingu ese ja sellega seotud

võõrandatavad intellektuaalse omandi õigused, sh autori kõik varalised õigused (edaspidi „õigused“) lähevad lepingu eseme vastuvõtmisega lepingus sätestatud tasu

eest täies mahus üle tellijale või juhul kui maksjaks on teine asutus, siis maksjale . Lepingu eseme suhtes kehtivate intellektuaalse omandi õiguste osas, mis oma olemuselt üleantavad ei ole, sh autori isiklikud õigused, annab töövõtja tellijale või kui

on kaasatud maksja, siis maksjale, arvates materjalide üleandmisest tagasivõtmatu kogu autoriõiguste kehtivuse aja kehtiva ainulitsentsi.

13.2. Hankelepingu täitmise ajal on tellija määratud isikul õigus muuta tarkvara lähtekoodi, mille suhtes töövõtja arendustöid teostab. Töövõtjal on keelatud takistada tellija määratud isikul tarkvara lähtekoodile ja dokumentatsioonile juurdepääsu, muudatuste

tegemist ja teostada mistahes muudatusi tellija määratud isiku poolt tehtud muudatustes ilma tellija eelneva nõusolekuta. Töövõtjal ei ole õigust nõuda eraldi tasu

intellektuaalse omandi õiguste eest hankelepingu täitmise ajal. 13.3. Tellijal või juhul kui maksjaks on teine asutus, siis maksjal, on pärast lepingu eseme

vastuvõtmist muuhulgas õigus omal äranägemisel otsustada lepingu eseme

kasutamisega seonduvad asjaolud, sh reprodutseerimine, levitamine ja üldsusele kättesaadavaks tegemine mistahes vormis ja kandjal, ilma geograafiliste piiranguteta,

otsustada lepingu eseme avaldamise viis, lepingu eseme kasutamise algusaeg ja tingimused, teha muudatusi, täiendusi ja parandusi lepingu esemes või lepingu esemeks

olevas teoses, selle pealkirjades või autorinime tähistuses, lisada lepingu esemele teiste

isikute teoseid ja õigus vaidlustada lepingu eseme või lepingu esemeks oleva teose, nende pealkirjades ja autorinime tähistuses tehtavaid moonutusi ning nende kohta

antud kahjustavaid hinnanguid, ning nõuda lepingu eseme kasutamise lõpetamist (ainulitsents koos all-litsentseerimisõigusega). Töövõtja kohustub tagama, et tal on kõik õigused eelpool nimetatud viisil varalised õigused loovutada ja isiklike õiguste

osas ainulitsents anda. 13.4. Lepingu eseme või lepingu esemeks oleva teose kasutamise viis ega territoorium ei ole

piiratud, st neid võib kasutada mistahes viisil (sh internetikeskkonnas) ja kogu maailmas.

13.5. Lepingu alusel üle antud õigused ja litsents hõlmab kõiki edasisi tulemi arendusi.

Tulemi üleandmisega tellijale läheb töövõtjalt tellijale või juhul kui maksjaks on teine asutus, siis maksjale, üle õigus tulemit ja selle dokumentatsiooni muuta, täiendada,

kasutada mistahes viisil ilma täiendava tasuta. Nimetatud õiguse üleminek jääb kehtima ka lepingu lõppemisel mistahes põhjusel.

13.6. Töövõtjal ei ole ilma tellija eelneva kirjaliku nõusolekuta õigust kasutada lepingu eset

või nende iseseisva tähendusega osasid või õigusi. Töövõtjal on õigus tulemit või selle osa kasutada näidisena oma loomingut sisaldavas portfoolios, sealhulgas avaldada

portfoolio digitaalsel kujul või paberkandjal, üksnes tellija või maksja eelneval kirjalikul nõusolekul.

13.7. Töövõtja poolt lepingu alusel kogutud informatsioon või selle töötlused loetakse tellija

omandiks ja lepingu lõppemise korral või tellija nõudmisel on töövõtja kohustatud viivitamatult omal kulul üle andma tellijale kogu tema valduses oleva sellise

informatsiooni. Samuti kuulub tellijale andmekandja, mille vahendusel lepingu ese, lepingu esemeks olev teos või lepingu esemega seotud dokumendid reprodutseeritakse, omandiõigus.

13.8. Kõik lepingu alusel loodud mistahes vormis ja sisuga projektid, plaanid, joonised, spetsifikatsioonid ja muud dokumendid, mis on loodud töövõtja poolt või sattunud

töövõtja valdusesse või kontrolli alla lepingu alusel tööde teostamisel, loetakse tellija omandiks. Kui pooled ei lepi kokku teisiti, on töövõtja lepingu lõppemise korral või tellija nõudmisel kohustatud oma kulul viivitamatult tagastama tellijale kõik tema

valduses olevad ja eespool viidatud dokumendid, muud infokandjad ja tehnilised vahendid.

13.9. Kui kolmas isik takistab tellijat tema lepingust tulenevate intellektuaalse omandi õiguste kasutamisel või rikub neid õigusi, teatab tellija sellest töövõtjale, kes peab viivitamata võtma tarvitusele kõik vajalikud abinõud, et võimaldada lepingust

tulenevate õiguste kasutamist ja lõpetada tellija õiguste rikkumine. Kui töövõtja võtab sellised abinõud tarvitusele, teeb tellija temaga vajalikul määral koostööd.

13.10. Juhul kui tellija vastu esitatakse nõue tööde tegemisel toimunud autoriõigus te rikkumise tõttu, vastutab tellijale tekkinud kahju eest töövõtja.

13.11. Töövõtja kohustub tagama, et isiklikud õigused on teostatavad muuhulgas alljärgnevas

ulatuses: 13.11.1. tellijal või tellija tellimusel või juhul kui maksjaks on teine asutus, siis maksjal

ja maksja tellimusel, on kolmandatel isikutel õigus teha üle antud tulemis muudatus i ning seda täiendada ilma töövõtja nõusolekuta;

13.11.2. tellijal või tellija tellimusel või juhul kui maksjaks on teine asutus, siis maksjal

ja maksja tellimusel, on kolmandatel isikutel on õigus lisada tulemile teiste autorite teoseid ilma töövõtja nõusolekuta;

13.11.3. tulemi üleandmisega tellijale kinnitab töövõtja, et tulem on üldsusele esitamiseks valmis ning töövõtja on loobunud õigusest seda ise avalikustada, välja

arvatud tellija või juhul kui maksjaks on teine asutus, siis maksja, eelneval kirjalikul

nõusolekul. 13.12. Töövõtja kinnitab ja tagab, et:

13.12.1. töövõtja on vastavad õigused täielikult omandanud oma töötajate, töövõtjate, alltöövõtjate või koostööpartneritega sõlmitud lepingute alusel ning töövõtjal on lepingu alusel õigus nimetatud varaliste õiguste võõrandamiseks ning

isiklike õiguste litsentseerimiseks tellijale või maksjale; 13.12.2. alates lepingu sõlmimisest puuduvad temal, tema töötajatel, töövõtjatel,

alltöövõtjatel, koostööpartneritel tellija või maksja vastu mistahes nõuded tuleneva lt varaliste autoriõiguste ja litsentseeritud isiklike õiguste võimalikust rikkumisest;

13.12.3. juhul kui tulemi kasutamine on takistatud kolmandate isikute

intellektuaalomandi õigustest või nende rikkumisest tulenevate nõuete tõttu, on töövõtja kohustatud nimetatud takistused omal kulul kõrvaldama;

13.12.4. töövõtja ei paku tulemit ja/või sellega äravahetamiseni sarnaseid teoseid ja/või tuletatud tulemit kolmandatele isikutele. Äravahetamiseni sarnasuse määramise l arvestatakse tulemi ning selle kujunduse jäetavat üldmuljet, kusjuures suuremat

osatähtsust omistatakse tulemis sisalduvatele autoriõigusega kaitstud elementidele. 13.13. Töövõtja tagab tellijale kõik vajalikud õigused lepingu täitmise käigus loodava tulemi

kontrollimiseks, testimiseks ning süsteemi paigutamiseks ka ajaks, mil tarne on üle antud, kuid pole veel lepingukohaselt tellija poolt vastu võetud.

14. Konfidentsiaalsus

14.1. Töövõtja kohustub lepingu kehtivuse ajal ning pärast lepingu lõppemist määramata

tähtaja jooksul hoidma konfidentsiaalsena kõiki talle seoses lepingu täitmisega teatavaks saanud asutusesiseseks kasutamiseks mõeldud teavet kuni teabepiirangu tähtaja lõpuni. Eelkõige, kuid mitte ainult, kohustub töövõtja hoidma

konfidentsiaalsena andmeid, mis sisalduvad lepingus, lepingu täitmiseks üleantud dokumentides ja muudes dokumentides, mille sisuga on töövõtjal olnud võimalus

seoses lepingu täitmisega tutvuda, lisaks eeltoodule mistahes muid andmeid. 14.2. Konfidentsiaalse informatsiooni avaldamine kolmandatele isikutele on lubatud vaid

tellija eelneval kirjalikku taasesitamist võimaldavas vormis antud nõusolekul.

Lepingus sätestatud konfidentsiaalsuse nõue ei laiene informatsiooni avaldamise le poolte audiitoritele, advokaatidele, pankadele ning juhtudel, kui pool on õigusaktidest

tulenevalt kohustatud informatsiooni avaldama. Töövõtja on teadlik, et leping on avaliku teabe seaduses sätestatud ulatuses avalik.

14.3. Töövõtja kohustub täitma organisatsioonilisi, füüsilisi ja infotehnoloogilis i

turvameetmeid konfidentsiaalsete andmete kaitseks juhusliku või tahtliku volitamata muutmise, juhusliku hävimise, tahtliku hävitamise, avalikustamise jms eest.

14.4. Töövõtja kohustub mitte kasutama konfidentsiaalset teavet mitte ühelgi viisil isikliku kasu saamise eesmärgil ega kolmandate isikute huvides.

14.5. Muuhulgas kohustub töövõtja tagama, et tema esindaja(d), töötajad, lepingupartner id

ning muud isikud, keda ta oma kohustuste täitmisel kasutab, oleksid käesolevas lepingus sätestatud konfidentsiaalsuse kohustusest teadlikud ning nõudma nimetatud

isikutelt selle kohustuse täitmist samadel tingimustel. 14.6. Töövõtja ei tohi tegeleda lepingu osas avalike suhetega ning anda teateid pressile,

elektroonilisele meediale, üldsusele või teistele auditooriumidele, välja arvatud tellija

eelneval kirjalikku taasesitamist võimaldaval nõusolekul.

15. Garantii

15.1. Üle antud tulemi osas kohaldub garantii alljärgnevatel põhimõtetel:

15.1.1. garantiiperioodi kestus on üks aasta (12 kuud) alates hetkest, mil lõplik tulem on tellija

poolt lepingu kohaselt vastu võetud, kui eritingimustes ei ole teisiti kokku lepitud; 15.1.2. töövõtja on kohustatud tagama garantiiajal tulemil ilmnenud puuduste tasuta

kõrvaldamise vastavalt vea prioriteetsusele järgnevalt: 15.1.2.1 kriitilised vead 2 tööpäeva jooksul peale sellekohase teate edastamist tellija poolt töövõtjale. Kriitiliseks veaks loetakse tarkvara arendusega seotud viga, mille tõttu: tarkvara

tervikuna ei ole võimalik kasutada; tarkvara põhifunktsionaalsus ei tööta või on olulise lt häiritud; tarkvara lubab/teostab mitteautoriseeritud operatsioone; kahjustatud on süsteemis

olevad andmed; kasutajale või seotud infosüsteemidele/andmebaasidele väljastatakse ebaõigeid andmeid/tulemusi. Kriitiliseks veaks loetakse sealhulgas ebamõistliku sagedusega esinevad sarnased mittekriitilised vead;

15.1.2.2 mittekriitilised vead 5 tööpäeva jooksul peale sellekohase teate edastamist tellija poolt töövõtjale. Mittekriitiliseks veaks loetakse infosüsteemi toimehäiret, mis ei ole põhjustatud

riistvarast või muust tarkvarast või muust arendustööst ja mida ei saa käsitleda kriitilise veana. 15.2. Garantiiaja alguseks loetakse lepingu eseme vastuvõtmise hetke. Kui lepingu

ese antakse üle osade kaupa, loetakse garantiiaja alguseks viimase osa üleandmise-

vastuvõtmise aega, kui lepingu eritingimustes ei ole sätestatud teisiti. 15.3. Garantiiga ei ole hõlmatud puudused, mis on tekkinud tellija hooletuse või

tahtliku tegevuse või tegevusetuse tagajärjel. 15.4. Töövõtja kohustub asuma omal kulul kõrvaldama garantiiaja kestel lepingu

esemel ilmnevad puudused alates tellija poolt töövõtjale esitatava vastavasisulise nõude hetkest

ja kooskõlas lepinguga ning mitte lõpetama vajalikke tegevusi enne, kui puudused on kõrvaldatud.

15.5. Kõik kulud, mis kaasnevad garantiiperioodil ilmnenud garantii alla kuuluva puuduse kõrvaldamisega, sh veo-, posti- jm kaasnevad kulud, kannab töövõtja.

15.6. Juhul kui töövõtja ei käsitle puudust garantii alla kuuluva puudusena, teavitab ta

sellest tellijat viivitamatult koos asjakohaste põhjendustega enne vea parandamist. Kui tellija töövõtjaga ei nõustu, on tellijal õigus tellida kolmandalt osapoolelt enne asja parandamist asja

defekteerimine. Kui defekteerimise tulemusel ilmneb, et puudus või viga kuulub garantii alla, kohustub töövõtja kandma defekteerimise ja vea parandamise kulud, muul juhul kannab defekteerimise kulud tellija. Kui asja puudus või viga ei kuulu garantii alla on töövõtjal õigus

vastavalt lepingule dokumenteerida vea kõrvaldamisele kulunud aeg ning nõuda selle hüvitamist kooskõlas lepinguga või kui lepinguga ei ole kokku lepitud töö teostamise tunni- vm

kohalduvat tasu, lepivad pooled kulude hüvitamises eraldi kokku, kokkuleppe aluseks on töövõtja poolt tavapäraselt taoliste tööde eest esitatav hinnakiri või vastava töö tavapärane maksumus.

15.7. Tellija nõudmisel kohustub töövõtja kõrvaldama garantiiperioodil ilmnenud vead ja puudused lepingu esemel tellija asukohas, kui kohapealne vea ja/või puuduse

kõrvaldamine on tulenevalt lepingu eseme olemusest võimalik. 15.8. Kui töövõtja ei asu puudust kõrvaldama kooskõlas lepinguga, on tellijal õigus

kõrvaldada see ise või kasutada kolmanda isiku abi ning nõuda töövõtjalt lisaks leppetrahvile

kõrvaldamisega seotud kulude hüvitamist. 15.9. Kui lepingu esemeks on asi ning selle või mõne selle komponendi tootjapoolne

garantiiaeg on pikem lepinguga kokku lepitud garantiiajast, ei katkesta lepingukohase garantiiaja lõppemine tootjapoolse garantii kehtivust. Käesolevas punktis toodud tootjapoolse garantiiga seonduva dokumentatsiooni on töövõtja kohustatud andma tellijale eraldi üle, kuid

garantiidokumentide üleandmise kohustuse täitmata jätmine ei mõjuta garantii kehtivust. 15.10. Juhul kui lepingu esemeks on asi ja töövõtja kõrvaldab lepingu esemel ilmnenud

lepingutingimustele mittevastavuse parandamise teel, pikeneb garantiiperiood eseme parandamise aja kestuse võrra. Kui töövõtja kõrvaldab lepingu esemel või selle komponendil

ilmnenud lepingutingimustele mittevastavuse eseme või komponendi asendamise teel, algab

vastava eseme või komponendi garantiiaja kulgemine algusest alates ümbervahetamise kuupäevast.

16. Nõuete ja kohustuste üleandmine ja lepingu ülesütlemine

16.1. Tellijal on õigus sõltumata põhjusest leping igal ajal üles öelda, teatades töövõtjale

vähemalt kuuskümmend (60) kalendripäeva ette. Nimetatud õigus on tellijal ka juhul, kui pooled on kokku leppinud tähtajalises lepingus. Sel juhul tasub tellija töövõtjale

ülesütlemise hetkeks faktiliselt üle antud esemete või osutatud teenuste eest, muud summad hüvitamisele ei kuulu.

16.2. Poolel on õigus leping ennetähtaegselt ühepoolselt üles öelda, teatades sellest ette, kui:

16.2.1. teine pool on rikkunud lepingut ning pole rikkumist kõrvaldanud poole poolt määratud mõistliku tähtaja jooksul; või

16.2.2. tegemist on olulise lepingu rikkumisega; või 16.2.3. rikkumine on korduv. 16.3. Lepingu ülesütlemisel töövõtja süü tõttu, on töövõtja õigus nõuda tasu vaid lepingu

lõppemise hetkeks faktiliselt üle antud esemete või osutatud teenuste eest, mida tellija l on tegelikkuses võimalik kasutada.

16.4. Lisaks mujal sätestatule, on poolel õigus igal ajal leping üles öelda juhul, kui: 16.4.1. lepingu täitmine on takistatud vääramatu jõu tõttu ning nimetatud mõju on peatanud

lepingu täitmist kauem kui 60 (kuuskümmend) kalendripäeva järjest; või

16.4.2. teise poole suhtes on alustatud pankrotimenetlust, pankrot on välja kuulutatud või tema varad on arestitud või tema finantsseisund on teise poole põhjendatud hinnangul

oluliselt halvenenud ja see halvenemine muudab vähetõenäoliseks lepingu nõuetekohase täitmise.

16.5. Lepingu lõppemise kohase arvelduse kohustub tellija teostama kahe kuu jooksul

lepingu lõppemise hetkest. 16.6. Õigused ja kohustused, mis oma olemusest tulenevalt ei sõltu lepingu kehtivusest,

jäävad kehtima peale lepingu lõppemist.

17. Lõppsätted

17.1. Leping jõustub allakirjutamisest poolte poolt ja kehtib kuni lepingust tulenevate õiguste realiseerimise ja kohustuste täitmiseni. Lepingu tingimusi võib muuta ainult

pooltevahelise kirjaliku või digitaalselt allkirjastatud kokkuleppega. 17.2. Pooled võivad lepingu erakorraliselt ühepoolselt lõpetada ja kasutada muid

õiguskaitsevahendeid jms lisaks lepingus sätestatule seaduses sätestatud juhtudel ja

korras. 17.3. Lepingu lõppemine ei mõjuta selliste kohustuste täitmist, mis oma olemuse tõttu

kehtivad ka pärast lepingu lõppemist (nt konfidentsiaalsuskohustus, kokkulepped materjalide suhtes kehtivate intellektuaalse omandi õiguste osas jms).

17.4. Pooled on kokku leppinud, et pooltel on õigus loovutada lepingust tulenevaid ja sellega

seotud õigusi ja kohustusi kolmandatele isikutele ainult teise poole eelneval kirjalikku taasesitamist võimaldavas vormis antud nõusolekul. Kolmandale isikule õiguste ja

kohustuste loovutamiseks käesoleva sätte tähenduses ei ole tellija poolt lepingust tulenevate ja sellega seotud õiguste ja kohustuste loovutamine teisele riigiasutusele või riigi äriühingule.

17.5. Lepingule kohaldatakse Eesti Vabariigis kehtivat õigust. Juhul kui lepingu mõni säte osutub vastuolus olevaks Eesti Vabariigis kehtivate õigusaktidega, ei mõjuta see

ülejäänud sätete kehtivust. Kui kirjeldatud juhul on tegemist imperatiivsete sätetega, millest erinevalt ei saa kokku leppida, viiakse seadusega vastuolus olevad sätted

esimesel võimalusel kehtiva regulatsiooniga kooskõlla.

17.6. Juhul, kui lepingu dokumendid on omavahel vastuolus, lähtutakse järgmisest prioriteetsuse järjekorrast: 1) leping; 2) üldtingimused; 3) muud lepingu dokumendid.

17.7. Lepinguga seotud vaidlused, mida pooled ei ole suutnud läbirääkimiste teel lahendada, antakse lahendamiseks Harju maakohtule.

SMIT: KESKSE PÄRINGUTE LOGIMISE LAHENDUSE LOOMINE - ARUANDLUS

1. Projekti väljund

Vajadus on luua eraldiseisev lahendus rahvastikuregistri ja tema kõikide rakenduste poolt

tehtavate päringute logide hoidmiseks, aruandluseks ning hävitamiseks, et parandada RR

andmete kasutamise läbipaistvust ning teenuste kvaliteeti läbi töökindluse ning jõudluse

tõstmise.

2. Projekti taustainformatsioon 2.1. Mõisted

Rahvastikuregister

(edaspidi RR)

Infosüsteem, mis koondab Eesti kodanike, Eestis elukoha registreerinud

Euroopa Liidu kodanike ja Eestis elamisloa või elamisõiguse saanud

välismaalaste ja teiste rahvastikuregistrisse kantud isikute peamisi

isikuandmeid ja isikuandmetega seotud andmeid, RR pidamist

abistavaid andmeid, RR objekti staatust ettevalmistavaid andmeid ja RR

arhiivis säilitatavaid andmeid. Rahvastikuregistrit haldab ja arendab

volitatud töötlejana Siseministeeriumi infotehnoloogia- ja

arenduskeskuse (SMIT). Rahvastikuregistri kirjeldus

RIHAs https://www.rihal.ee/Infos%C3%BCsteemid/Vaata/rr#uldkirjeldus.

Rahvastikuregistri

menetlustarkvara

(edaspidi MT)

Rahvastikuregistri rakendus.

Töölauarakendus RR andmete töötlemiseks.

MT kasutajateks on Siseministeeriumi töötajad, SMIT registripidajad,

menetlejad - notarid, KOV ametnikud, sh perekonnaseisuametnikud jne.

Vastavalt pädevusele ja õigustele saab MTs teha isiku kohta RRi kantud

isikuandmete, dokumentide, kannete ja toimikute päringuid,

menetlustoimingud ja kandeid, andmete ja kannete parandamist,

aruandlust ja statistika päringuid, väljavõtete ja tõendite väljatrükke,

aadressmuudatuste ja valimisteatiste edastamist ja vastuvõtmist;

kasutajate, rollide ja õiguste haldamist ning järelevalvetoiminguid.

Ametnikuportaal

Rahvastikuregistri rakendus.

Ametnikuportaal on koht riigiportaalis eesti.ee rahvastikuregistrist

päringute tegemiseks kasutajatele antud erinevate teenuste kaudu nii

avalike ülesannete täitmiseks kui õigustatud huvi alusel.

Rahvastikuregistri

andmeladu

Rahvastikuregistri rakendus.

Töölauarakendus RR ja MT statistika vaatamiseks ja töötlemiseks.

Andmelao kasutajateks on Siseministeeriumi töötajad, sh

järelevalveametnikud, SMIT registripidajad, menetlejad - KOV

ametnikud, jm menetlejad, kellele on vastav ligipääs ja aruandlus

loodud.

Vastavalt pädevustele ja õigustele saab andmelaos luua uusi ja vaadata

juba loodud aruandeid.

X-tee Eesti riigi põhilisi andmebaase ühendav turvaline ja tõestusväärtust

tagav keskkond, mis korraldab internetipõhist andmevahetust

riigiasutuste vahel ja erasektoriga.

2.2. Rahvastikuregistris ja selle alaminfosüsteemides kasutatavad tehnoloogiad

1. Rahvastikuregister (RR) on keskne andmekogu, selles hoitakse isikute põhiandmeid. RR

andmebaasiks on Progress OpenEdge. Teenused on realiseeritud keeles OpenEdge

Advanced Business Language (ABL) ning neid käitatakse OpenEdge WebSpeed

keskkonnas.

2. Rahvastikuregistri menetlustarkvaras (MT-s) viiakse läbi rahvastikutoimingute menetlusi

ning hoitakse menetlustega seotud andmeid. Antud taotluse vaates on tegemist

haldusandmete tarbijaga. MT arenduskeeleks C#. Alusraamistikuks .Net Framework 4.7.

Andmebaasihaldussüsteemina on kasutusel Microsoft SQL Server. Suhtlusel

andmebaasiga kasutatakse lisa raamistikku Entity Framework (EF). Klientrakenduseks

on töölauarakendus, mille loomisel on kasutatud lisa raamistikku Windows Form

(WinForms). Klient- ja serverrakenduse vahelises suhtluses kasutatakse lisa raamistikku

Windows Communication Foundation (WCF), kasutusel SOAP protokoll.

3. Rahvastikuregistri Andmelaos luuakse RR ja MT andmete pealt aruanded ning

vaadatakse neid. Andmebaasimootorina on kasutusel PostgreSQL, laadeprotsesside

orkestreerimine toimub Apache Airflow abil. Kasutusel on püütoni (Python)

programmeerimise keel ning SQL skriptid. Raportite loomiseks ning tarbimiseks on

kasutusel analüütika tarkvara Tableau.

2.3. Arendus- ja hooldustööde definitsioonid

1. analüüsitööd – süsteemi-, äri- ja/või andmeanalüüs; tellija ja/või äripoolega

analüüsikoosolekute läbiviimine projekti tööde teostuseks, analüüsi dokumentatsiooni

koostamine, muutmine ja uuendamine; süsteemi nõuete ja vajalikku funktsionaalsuse,

andmeobjektide ja seoste (sh erinevate diagrammide loomine), andmemudelite

kirjeldamine (sh arendusülesannete kirjeldamine arendajatele); süsteemi nõuete ja

funktsionaalsuse selgitamine osapooltele; süsteemi disaini väljatöötamisel osalemine

pakkudes erinevaid kliendile parimaid lahendusi arvestades infosüsteemi kui tervikut.

Vastavalt koostatud analüüsidokumentatsioonile Tableau aruannete testimine; jm tööd,

mis kuuluvad analüüsitööde hulka;

2. andmeteadustööd – struktureeritud info erinevatest allikatest kombineerimine;

andmemudelite loomine; töö dokumenteerimine; suurandmete (big data – äärmiselt

suured andmekogumid), arvutuslik analüüs mustrite, trendide ja seoste loomiseks;

andmeanalüüsi ja arendustööde toetamine; jm tööd, mis kuuluvad andmeteadustööde

hulka;

3. programmeerimistööd/arendustööd – tarkvara lähtekoodi, automaattestide ja ühiktestide

kirjutamine ja täiendamine; lähtekoodi ülevaatamine ja parandamine vastavalt koodistiili

reeglitele; oma töö tulemuse tutvustamine (demo) huvigruppidele; andmesiirde

teostamine; töö dokumenteerimine; andmemudelite loomine/täiendamine; tarnepakkide

koostamine; andmevahetus- ja liidestustööde tegemine/arendamine; tiimis kokku lepitud

tarkvaraarenduse loogika rakendamine; süsteemi disaini väljatöötamisel osalemine

pakkudes erinevaid tehnilisi lahendusi (sh nõuete tehniline analüüsimine), arvestades

süsteemi kui tervikut. Struktureeritud info erinevatest allikatest kombineerimine,

andmelettide arendamine ja testimine; andmelao ja ELT protsessi seadistamine,

laadimisvastavuste kontrolli teostamine; jooksvate muudatusvajaduste realiseerimine;

arvestades agiilset arendusmeetodit jooksvalt muudatuste töösse võtmine ja

realiseerimine; jm tööd, mis kuuluvad programmeerimis/arendustööde hulka;

4. testimistööd (käsitsi- ja automaatestimine) – vastavalt spetsifikatsioonidele ja

arendusülesannetele testimine, loodud dokumentatsiooni üle vaatamine/valideerimine;

testjuhtumite loomine ja täiendamine valminud lahenduse testimiseks; automaattestide

kirjutamine ja täiendamine; manuaaltestimine; andmevahetus- ja liidestustööde

testimine, testandmete loomine jm tööd, mis kuuluvad testimistööde hulka;

5. juurutustööd – tarkvara levitamine (sh installeerimine riistvarale), seadistamine ja

paigaldamine (reliisimine/ release) projektis kasutusel olevatesse keskkondadesse;

juhendmaterjalide koostamine erinevatele sihtrühmadele; koolitamine; jm tööd, mis

tagavad tarkvara eduka kasutuselevõtu toodangukeskkonnas; jm tööd, mis kuuluvad

juurutustööde hulka;

6. koolitused – praktiliste koolituste ettevalmistamine ja läbiviimine erinevatele

sihtrühmadele (lõppkasutajad, administraatorid, rahvastikuregistri klienditoe liikmed,

Siseministeerium); lähtuvalt sihtrühma vajadusest tarkvara juhendmaterjalide ja

kasutusjuhendite koostamine ja täiendamine;

7. dokumentatsiooni koostamine – dokumentatsiooni loomine, täiendamine ja üleandmine

täitja poolt digitaalsel kujul tellija Wiki (Atlassian Confluence) keskkonnas; juhendite

koostamine ja täiendamine vastavalt tellija juhistele ja hanke alusdokumentide Lisale

2 (Nõuded lahendusele ja dokumentatsioonile);

8. hooldustööd – olemasolevate infosüsteemide käideldavuse/töökindluste (nt päringute

optimeerimistööd, komponentide versioonide uuendamised jne) tagamine; tarnitud

tarkvara modifitseerimine eesmärgiga parandada vigu, jõudlust ja muid näitajaid (nt

süsteemi muudatused, et tulla toime muutustega tarkvara keskkonnas); jm tööd, mis

kuuluvad hooldustööde hulka;

9. disainimistööd – vajadusel kasutajauuringute läbiviimine, kasutuslugude kirjeldamine,

ekraanijooniste loomine, stiiliraamatute loomine ja täiendamine ning ühtse disaini

hoidmine kogu arenduse vältel;

10. tehnilise lahenduse arhitektuuritööd – tehnoloogiliste otsuste vastuvõtmine, sh

infosüsteemi projekteerimine ja arendamine; infosüsteemide ja toodete valmimise

tagamine; tarkvaraarenduse protsesside, meetodite, parimate praktikate ja standardite

välja töötamine (jälgimine); tiimiliikmete juhendamine ja nõustamine, et tagada projekti

või rakenduse versiooni õigeaegne ja spetsifikatsioonikohane valmimine; arhitektuuri ja

projekteerimislahenduste välja töötamine ja dokumenteerimine; teabe edastamine

sihtrühmadele (klient, tooteomanik, süsteemiadministraator, tehniline juht), et tagada

projekteerimise ja arhitektuuri nõuetelevastavus ning õigeaegsed tarned; jm tööd, mis

kuuluvad arhitektuuritööde hulka;

11. Tableau aruannete tööd – aruannete/juhtimislaudade loomine, visualiseerimine

(visualiseerimine tähendab erinevat tüüpi diagramme, graafikuid, erineva tasemega

kaarte, tabeleid jne); visuaali teostuseks kliendi soovide ja vajaduse väljaselgitamine

ning Tableaus parimate/tellija ootustele vastavate visuaalsete lahenduste pakkumine;

statistika, lineaarse algebra, tõenäosusteooria ja andmestruktuuride teadmiste oma töös

rakendamine; tööde dokumenteerimine vastavalt tellija juhistele ja hanke

alusdokumentide Lisale 2 (Nõuded lahendusele ja dokumentatsioonile); vastavalt

koostatud analüüsidokumentatsioonile Tableau aruannete arendamine ja testimine. jm

tööd, mis kuuluvad Tableau aruannetega seotud tööde hulka.

3. Hetkeolukord ja probleemid praeguse lahendusega 3.1. Rahvastikuregister üldiselt

Rahvastikuregistri näol on tegemist taakvaraga:

1. mis võeti kasutusele aastal 2010.

2. mille arhitektuur ja tehnilised valikud on tehtud ca 15 aasta tagasi.

3. kus kasutusel on Progress OpenEdge andmebaas ja Progress ABL

programmeerimiskeel – antud tehnoloogia ei ole riigi ristfunktsionaalsete nõuetes toodud

TIOBE indeksi TOP25 hulgas. Eestis on see vähe levinud ja suurim probleem on

spetsialistide leidmisega.

4. Ei ole pilvepõhine.

5. Koodibaas on ebaühtlase tasemega.

6. Enamus koodi on ühiktestidega katmata.

7. Ei ole võimalik kasutada kaasaegset mitme õlaga kõrgkäideldavat rakendusarhitektuuri.

8. Ei ole kasutusel tänapäevaseid riigiarhitektuuri keskseid komponente (TARA).

3.2. Olukord logimisega

Andmete säilitamist ning säilitamise tähtaegu reguleerib rahvastikuregistri seaduse (edaspidi

RRS) paragrahv 8: https://www.riigiteataja.ee/akt/122122018013?leiaKehtiv ning

Siseministeeriumi infotehnoloogia- ja arenduskeskuse (edasipidi SMIT) ja Siseministeeriumi

(edaspidi SiM) vahel sõlmitud Rahvastikuregistri (edaspidi RR) teenuse kokkulepe (SLA).

RR andmeid kasutavad ning kannavad neid RR-i üle 340 riigi- ja erasektori asutuse ning e-

rahvastikuregistri kasutajad. 2023 aastal ületasid erinevad päringud kokku 200 miljoni piiri.

Päringute arv on viimase kolme aastaga kasvanud 57%. Andmeid päritakse üle X-tee v6,

ametnikuportaali, e-Rahvastikuregistri (mõlemad samuti X-tee v6), läbi MT (X-tee v4), läbi RR

Admini. Kõik RRi tehtavad päringud salvestatakse (logitakse) ning säilitatakse viis aastat.

Päringute logisid hoitakse Rahvastikuregistri operatiivandmebaasis, see tähendab, et:

DB

kokku

(GB)

3

päringute

tabelit

(GB)

%

30.07.2023 3005,01 2246,63 75%

20.06.2022 2472,2 1760,87 71%

kasv 532,81 485,76 91%

 Päringute logid moodustavad andmebaasist 75% (kogu andmebaasi maht 3 TB) ja

andmebaasi iga-aastane mahukasv tuleb 91% ulatuses logide mahukasvust.

Andmebaasi mahu kasv on ~530GB aastas (2023. a kasv).

 Päringute logide suur maht tekitab andmebaasis jõudlusprobleeme.

 Andmebaasi taastamise aeg on vastuvõetamatult suur (~8 tundi) ning andmebaasi

intsidendi korral on mõju rahvastikuregistri käideldavusele väga suur.

3.3. Logide lahenduse üldine joonis

3.4. RR andmeladu ja aruandlus 3.4.1. RR andmeladu

Andmeladu on kasutajatele kättesaadav 01.01.2024.

1. Loodud on andmelao arhitektuur, osas, mis katab senist vajadust

2. Andmelao tehnoloogiline lahendus:

1. Andmete laadimine - Apache Airflow

2. Andmebaas - PostgreSQL

3. Andmete visualiseerimise tarkvara - Tableau

4. Andmete transformatsioon - Python

3. Andmelao andmesiirde kiht, baasis on 2 ODS skeemi

1. ods_rr, mis on täidetud RR andmetega

2. ods_mt, mis on täidetud MT andmetega

4. Loodud on vahetabelid ja andmeletid

5. Loodud on kasutajate autentimise ja autoriseerimise lahendus:

1. kasutajate tuvastus: UAA,

2. kasutajate autoriseerimine: Tableau,

3. kasutaja haldus: AD (Orbiit).

6. Loodud on andmete logimise lahendus ja tööle on rakendatud andmejälgija

1. Andmejälgijasse edastatakse andmed isikustatud aruannete vaatamisel

7. Loodud on liidestus Eesti avaandmete portaaliga

3.4.2. Aruandlus

1 Andmelaos on realiseeritud kokkuvõtlikult 3 eri tüüpi aruanded:

1.1. juhtimislauad - erinevaid visualiseerimise võimalusi kasutav kompleksaruannet (koosneb

mitmest andmekomplektist) ja/või on loodud Tableau workbook võimalusi kasutades.

1.2. aruanded - aruanded, mille sisend tuleneb ühest konkreetsest andmehulgast, võib

sisaldada erinevaid visuaale, mitte ainult tabelaruannet

1.3. kompleks aruanded - aruanded, mille sisend tuleneb mitmest erinevast andmekoosseisust.

2 Aruannete jagunemine:

2.1. isikustatud andmetega:

2.1.1. rahvastiku detailaruanded

2.1.2. menetluse detailaruanded

2.2. isikustamata andmetega:

2.2.1. rahvastiku koondaruanded

2.2.2. menetluse koondaruanded

2.3. järelevalve aruanded

2.3.1. siseministeeriumi järelevalve aruanded (sh kvaliteedi aruanne)

2.3.2. kohalike omavalitsuse järelevalve

3 Rahvastikuregistri aruandluse üldine eesmärk on toetada andmevajadusi:

3.1. avaliku ülesande täitmisel - aruandeid kasutavad riigiasutused (sh SIM või SMIT) ja KOV-id

oma tööülesannete täitmiseks.

3.2. õigustatud huvi täitmisel - välised osapooled (füüsilised isikud, juriidilised isikud,

riigiasutused) esitavad taotluse andmetele ligipääsuks. Siseministeerium hindab õigustatud

huvi olemasolu ning positiivsel juhul saavad andmetele ligipääsu.

3.3. Aruanded on jaotatud nelja erinevasse loogilisse gruppi eelkõige selle järgi, kuidas neile ligi

saab ning kes on nende peamisteks tarbijateks:

3.3.1. Vajaduspõhine aruandlus – kaetakse ära need kasutusjuhud, mida olemasolevad valmis

tehtud aruanded ei toeta. Vajaduspõhine aruanne on koostatud vastavalt üksiku kasutaja

vajadustele just tema tööülesannete täitmiseks.

3.3.2. Menetluste aruandlus – kajastab ainult neid andmeid, mis on tekkinud

Rahvastikuregistriga seotud menetluste käigus. Andmestik baseerub eraldi

Menetlustarkvara andmebaasi andmetel. Aruanded jagunevad:

3.3.2.1. Automaatne aruanne - MT kaudu kättesaadav aruanne, mis genereeritakse

kindla sagedusega (genereerimise graafik määratud iga aruande kohta eraldi).

3.3.2.2. Tellitav aruanne - Menetlustarkvara rakenduse kaudu kättesaadav aruanne, kus

kasutaja defineerib aruande filtrid ning käivitab selle. Aruanne koostatakse öiste

andmetöötluste käigus ning on kättesaadav järgmisel päeval Menetlustarkvara

rakenduse kaudu.

3.3.3. Rahvastikuregistri aruandlus – baseerub ainult nendel andmetel, mis on kantud

Rahvastikuregistrisse. Aruanded on kättesaadavad läbi Menetlustarkvara

aruandluskeskkonna, ning selle aluseks on RR-i andmebaas. Analoogselt MT

aruandlusega jaguneb ka RR aruandlus omakorda automaatseks ja tellitavaks.

3.3.3.1. RR aruandeid, mis saadakse kätte MT-st on hetkel veel 18.

3.3.4. Organisatoorne aruandlus – ametisisene aruandlus, mis koostatakse käsitsi SMIT-i

töötajate poolt ning edastatakse SMIT-i ja Siseministeeriumi ametnikele tööalaseks

kasutamiseks. Baseeruvad erinevate andmestike peal (Rahvastikuregistri andmebaas,

Menetlustarkvara andmebaas, JIRA jne).

4 Nõuded projektile 4.1. Nõuded lahendusele

Pakutav tehnoloogiline lahendus:

1. Peab olema pilvesõbralik ehk sobima SMITi pilvekeskkonda (Kubernetes) ja

Riigipilvega.

2. Arvestab SMITis infosüsteemide arendamisele kehtestatud nõuetega, sealhulgas turva-

ning logimisnõuetega.

3. Arvestab RR tulevikuvisiooniga tehnoloogia ja komponentide valikus.

4. Arvestab SMITis juba loodud või loodavate sarnaste lahendustega (sh arhitektuuri

ümarlaua suunised) komponentide taaskasutatavuse kontekstis.

5. Andmesiirdel ja uuele tehnoloogilisele lahendusele ümberlülitumisel on täidetud RR

SLA.

6. Lahenduse etappidena teostamisel peab olema täidetud RR SLA.

7. SMIT-s kasutava koodikvaliteedi mõõtmise tarkvara SonarQube "quality gate" peab

olema vähemalt 80%.

8. Lahendus peab olema liidestatud SMIT keskse kasutajate autentimise ja autoriseerimise

lahendusega (UAA).

1. The User Account and Authentication Service (UAA)

9. Rakenduse tehnilised komponendid kaitsevad iseennast sh valideerivad nende poole

pöördunud kasutaja või tehnilise teenuse õiguseid.

10. Komponentide vaheliseks suhtluseks kasutatakse SSL kanalit.

11. Tehniliste komponentide API'del eksisteerib automaatselt genereeritud dokumentatsioon

(näiteks Swagger).

12. Kasutajaliidese olekut (state) hoitakse kliendi liidese poolel ja teenused ise on olekuta.

13. Kasutajaliides tuleb lahendada Tableau tarkvaras.

14. Kasutama peab PostgreSQL andmebaasi.

15. Andmed peavad olema talletatud vähemalt UTF-8 tähemärgi kodeeringut.

16. Andmete kustutamine ei tohi kustutada tegelikke kirjeid andmebaasist, välja arvatud, kui

kirjed pole mittefunktsionaalsed, ehk ei oma ärilist seost. Ärilist seost ja eesmärki ei oma

kirjed, mille säilitustähtaeg on möödunud.

17. Andmebaasi komponenti integratsioonivahendina ei tohi kasutada.

18. Andmebaasi pöördutakse ainult rakenduse jaoks eraldatud süsteemsete kasutajatega.

19. Rakendusse tuleb luua võimekus leida vajadusel mitme andmebaasi instantsi sest

peamine, kuhu on võimalik kirjutamispäringuid saata. Vaike seadistuses kasutab SMIT

PgBouncer-it.

4.2. Nõuded aruannetele 4.2.1. Aruannete logimine

Andmelao andmestiku pealt tehtud kõik päringud (nii rakenduskiht kui ka andmebaas) on vaja

logida (kes, millal ja mida tegi). Andmelao päring on teatud kriteeriumitel baseeruv otsing.

Päringu tulemuste logimist käsitletakse punktis 4.2.2. Aruannete logimisel tuleb lähtuda SMIT

logimise nõuetest, mis on sätestatud Lisa 8 (mittefunktsionaalsed nõuded) dokumendis ,, 08.

Logimise nõuded (sh välisele partnerile)’’

4.2.2. Aruande tulemuste logimine

Aruande tulemused jagunevad logimise vajaduse põhiselt kaheks:

1. Konkreetse isikuga seostatav aruande tulemus. Isik on päringu tulemuste põhjal

tuvastatav. Lisaks aruannetele endile tuleb logida, kas päring peab olema andmejälgijas

peidetud rahvastikuregistri seaduse § 45 lõike 3 alusel

(https://www.riigiteataja.ee/akt/122122018013?leiaKehtiv).

2. Aruande tulemus, mis ei ole konkreetse isikuga seostatav.

4.2.3. Andmete kustutamine

Andmeladu peab toetama andmete loogilist kustutamist, st kui alliksüsteemis märgitakse vastav

kirje kustutatuks, siis märgitakse vastav staatus ka andmelao kirje juurde.

4.2.4. Ligipääsetavus

Tuleb tagada olukord, kus andmelao kasutaja ei pääseks ligi rohkematele andmetele kui talle

juurdepääsuloaga õigused anti.

4.2.5. Andmete terviklikkus

Tagatud peab olema andmete terviklikkus ning selle kontroll operatiivsüsteemide ja andmelao

vahel.

4.2.6. Jõudlus

Lihtsamad aruanded (tulevad ainult andmelettidelt) ja valdkonna töölaua avamine ei tohi võtta

aega rohkem kui 95% juhtudest 7 sekundit ja 100% juhtudest 20 sekundit. Keerukamad

aruanded võivad aega võtta 95% juhtudest maksimaalselt 1 minuti ja 100% juhtudest 5 minutit.

Lihtsamad päringud/aruanded on need, kus andmeid päritakse ühe andmeleti pealt ja tulemuste

arv jääb alla 50 000 kirje. Keerukamad päringud/aruanded on need, kus andmeid päritakse

mitme andmeleti ja/või andmetabeli pealt ja tulemus on üle 50 000 kirje.

4.2.7. Skaleeritavus

Andmelao andmekoosseisu peab olema võimalik tulevikus täiendada ja laiendada, sealhulgas

uute andmeallikatega sidumine, olemasolevate andmetabelite täiendamine, täiendavate

andmelettide, andmetabelite, kasutajate, kasutajagruppide ja juhtimislaudade loomine, mõistliku

vaevaga

4.3. Nõuded kasutajate haldusega liidestamisele

1. Kasutajad ning kasutaja grupid on kirjeldatud SMITi Active Directory-s.

2. Kasutajate tuvastamine ning autoriseerimine toimub kasutades SMIT-i User Account and

Authentication Service (UAA) teenust sh teenuskontod.

3. Kasutajate tuvastamine toimub RIA TARA integrastiooniga SMIT-i UAA teenusega,

millega võimalik kasutajat tuvastada ID-kaardi ja MobiilID-ga.

4. Suhtluseks kasutatakse OpenID Connect protokolli.

4.4. Nõuded testidele

1. Iga tarnega peab üle andma testilood ja testiraportid, mida antud tarne käigus testiti.

2. Iga tarnega peab üle andma teadaolevate vigade vearaportid, mida planeeritakse

parandada järgnevate tarnetega.

3. Arendustest/automaattest peab katma nii uue tarnitava funktsionaalsuse kui ka varem

tarnitud funktsionaalsuse regressioonitestid.

4. Teostama peab jõudlustestid kontrollimaks mittefunktsionaalsetes nõuetes kirjeldatud

nõudeid. Jõudlustestid koos raportitega tuleb üle anda Tellijale.

5. Kogu loodav funktsionaalsus tuleb manuaaltestide kaudu testidega katta.

5 Hankelepingu tulem

Hanke käigus Täitja poolt loodav ja Tellijale üle antav tulem on:

1. 9 (üheksa) aruande või juhtimislaua loomine Tableau tarkvaras. Sealhulgas:

1. Loodavad aruanded vastavad punktis 4 toodud nõuetele.

2. Täitja on iseseisvalt teostanud andmelaos aruannete/andmelettide loomiseks

vajalike andmete detailanalüüs allikandmebaasis.

3. Täitja on teostanud aruannete ja andmelettide detailanalüüsi ärikasutajaga

(vastavalt tehnilise kirjelduse 2.3 punktile 1) .

4. Täitja on arendanud aruannete/kompleksaruannete/juhtimislaudade loomiseks

vajalikud vahetabelid ja andmeletid andmelaos või logide lahenduses.

2. Täitja pakub välja optimaalse tehnilise lahenduse aruannete arendamiseks Tableau

tarkvaras, tellija peab lahenduse kinnitama.

1. Lahendus peab maksimaalselt ära kasutama olemasolevat funktsionaalsust.

2. Lahendus ei tohi tekitada täiendavat haldamise koormust.

3. Vajadusel luuakse ühendus andmelao andmebaasiga. Andmete siirdel tuleb

lähtuda minimaalse andmete vajalikkuse printsiibist.

4. Täitja on teostanud tehnilise analüüsi andmelao arendustööde (laadimisplatvorm,

tabelid andmelao baasis või muud tulemi saavutamiseks teostatavad tööd)

teostamiseks.

3. Isikustatud aruannete vaatamise faktid tuleb edastada Andmekasutuse järelvalve

lahendusse kasutades juba loodud REST otspunkti. Isikustatud pärimised hoiustatakse

täna PostgreSQL andmebaasis.

4. Täitja on dokumenteerinud vastavalt olemasolevale struktuurile ja reeglitele teostatud

tööd (andmemudelid, seosed, tehnilised tööd jm).

6. Hankelepingu tulemi etapid 6.1 Etapp 1:

1. 3 aruannet või juhtimislauda Tehnilise kirjelduse punktist 5.1 

2. Tehnilise kirjelduse punkt 5.2 (Tehniline lahendus) punktis 6.1.1. mainitud aruannete või

juhtimislaudade osas. 

3. Tehnilise kirjelduse punkt 5.3. 

4. Tehnilise kirjelduse punkt 5.4 (dokumentatsioon)  punktis 6.1.1. mainitud aruannete või

juhtimislaudade osas. 

6.2 Etapp 2 

1. 4 aruannet või juhtimislauda Tehnilise kirjelduse punktist 5.1 

2. Tehnilise kirjelduse punkt 5.2 (Tehniline lahendus) punktis 6.2.1. mainitud aruannete või

juhtimislaudade osas. 

3. Tehnilise kirjelduse punkt 5.4 punktis (dokumentatsioon) 6.2.1. mainitud aruannete või

juhtimislaudade osas. 

6.3 Etapp 3 

1. 2 aruannet või juhtimislauda Tehnilise kirjelduse punktist 5.1 

2. Tehnilise kirjelduse punkt 5.2 (Tehniline lahendus) punktis 6.3.1. mainitud aruannete või

juhtimislaudade osas. 

3. Tehnilise kirjelduse punkt 5.4 (dokumentatsioon) punktis 6.3.1. mainitud aruannete või

juhtimislaudade osas. 

1 / 21

Koostatud 18.12.2024 11:43:17 https://riigihanked.riik.ee/rhr-web/#/procurement/8172764/general-info

HANKEPASS

Hankepass ehk Euroopa ühtne hankedokument (ESPD) on ettevõtja enda kinnitus, mis on esialgne tõend ametiasutuste või kolmandate isikute poolt väljastatavate tõendite asemel. Käesolev PDF vormingus registri poolt koostatud dokument on selgitava iseloomuga ja sisaldab hankija sätestatud tingimusi, ettevõtjalt oodatavate vastuste vormingu vaadet ja registri poolt lisatud viiteid RHS-ile. Käesolev dokument ei ole ette nähtud täitmiseks vaid tingimustega tutvumiseks. Ettevõtja täidab hankepassi elektrooniliselt infosüsteemis või ESPD teenuses.

I OSA: HANKE JA HANKIJAGA SEOTUD TEAVE

Teave avaldamise kohta Teate number ELTs:

-

ELT URL:

Riigi ametlik teataja:

288139

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

Hankija andmed Ametlik nimi:

Siseministeeriumi infotehnoloogia- ja arenduskeskus (70008440)

Riik:

Eesti

Hankija aadress:

Mäealuse tn 2/2

Hankija veebiaadress:

http://www.smit.ee

E-posti aadress:

[email protected]

2 / 21

Koostatud 18.12.2024 11:43:17 https://riigihanked.riik.ee/rhr-web/#/procurement/8172764/general-info

Teave hankemenetluse kohta Hanke menetlusliik:

Avatud hankemenetlus

Pealkiri:

Rahvastikuregistri andmelattu päringu logide baasil aruannete loomine

Lühikirjeldus:

Rahvastikuregistri andmelattu päringu logide baasil aruannete loomine

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

288139

Hanke liik:

Teenused

Hanke CPV-d: 72200000-7 Tarkvara programmeerimis- ja nõustamisteenused

3 / 21

Koostatud 18.12.2024 11:43:17 https://riigihanked.riik.ee/rhr-web/#/procurement/8172764/general-info

II OSA: ETTEVÕTJAGA SEOTUD TEAVE

A: Teave ettevõtja kohta

Nimi:

Registrikood:

Riik:

Aadress:

Üldine veebileht:

Kontaktisikud:

Kontaktide e-posti aadressid:

Kontaktide telefoninumbrid:

Ettevõtte suurus:

Töötajate arv:

Käive:

Valuuta:

Finantsalase võimekuse kirjeldus:

Tehnilise võimekuse kirjeldus:

Teostatud tööde kirjeldus:

Ettevõtja tegevusvaldkond:

4 / 21

Koostatud 18.12.2024 11:43:17 https://riigihanked.riik.ee/rhr-web/#/procurement/8172764/general-info

ETTEVÕTJA ON KAITSTUD TÖÖKOHT

Ainult reserveeritud hangete puhul: kas ettevõtja puhul on tegemist kaitstud töökohaga, sotsiaalse ettevõttega või ta täidab lepingut kaitstud tööhõive programmide raames?

Küsimused ettevõtjale: 1. Mis on Teie vastus? 2. Milline on puudega või ebasoodsas olukorras olevate töötajate osakaal? 3. Kui seda on nõutud, täpsustage, millisesse puudega või ebasoodsas olukorras olevate töötajate kategooriasse või kategooriatesse asjaomased töötajad kuuluvad? 4. Kas see teave on elektrooniliselt kättesaadav? 5. URL 6. Kood 7. Väljaandja

ETTEVÕTJA ON KANTUD TUNNUSTATUD ETTEVÕTJATE AMETLIKKU NIMEKIRJA

Kui see on asjakohane, siis kas ettevõtja on kantud tunnustatud ettevõtjate ametlikku nimekirja või kas tal on olemas samaväärne tõend (nt riikliku (eel)kvalifitseerimissüsteemi alusel)?

Küsimused ettevõtjale: 1. Mis on Teie vastus? 2. a) Vajaduse korral märkige asjakohane registreerimis- või sertifitseerimisnumber: 3. c) Viited, millele registreerimine või sertifitseerimine tugineb ja vajaduse korral ametlikus nimekirjas omistatud klassifikatsioon: 4. d) Kas registreerimine või sertifitseerimine hõlmab kõiki nõutud valikukriteeriume? 5. Kas see teave on elektrooniliselt kättesaadav? 6. URL 7. Kood 8. Väljaandja

HANKEMENETLUSES KOOS OSALEVAD ETTEVÕTJAD

Kas ettevõtja osaleb hankemenetluses koos teistega?

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

TEAVE TEISTE ÜKSUSTE SUUTLIKKUSELE TOETUMISE KOHTA

Kas ettevõtja toetub teiste üksuste suutlikkusele, et täita esitatud valikukriteeriumid ning eeskirjad (kui neid on)?

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

5 / 21

Koostatud 18.12.2024 11:43:17 https://riigihanked.riik.ee/rhr-web/#/procurement/8172764/general-info

TEAVE NENDE ALLHANKIJATE KOHTA, KELLE NÄITAJATELE ETTEVÕTJA EI TUGINE

Kas ettevõtja kavatseb sõlmida lepingu mis tahes osa kohta allhanke kolmanda isikuga?

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

HANKE OSAD

Hanke osad, mille kohta ettevõtja soovib pakkumuse esitada

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

ETTEVÕTJA KINNITUSED MAKSUDE TASUMISE KOHTA

Kas ettevõtja saab esitada tõendi sotsiaalkindlustusmaksete ja maksude tasumise kohta või esitada teabe, mis võimaldaks avaliku sektori hankijal või võrgustiku sektori hankijal saada sellise teabe otse ükskõik millise liikmesriigi tasuta andmebaasist?

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

B: Teave ettevõtja esindajate kohta

Eesnimi:

Perekonnanimi:

Sünniaeg:

Sünnikoht:

Aadress:

Linn/vald:

Postiindeks:

Riik:

E-post:

Telefon:

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

6 / 21

Koostatud 18.12.2024 11:43:17 https://riigihanked.riik.ee/rhr-web/#/procurement/8172764/general-info

III OSA: KÕRVALDAMISE ALUSED

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

OSALEMINE KURITEGELIKUS ORGANISATSIOONIS

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

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

Ettevõtjalt oodatavad vastused:

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

KORRUPTSIOON

Kas ettevõtja ise või tema haldus-, juht- või järelevalveorgani liige või isik, kellel on volitused seda ettevõtjat esindada, tema nimel otsuseid teha või teda kontrollida, on lõpliku süüdimõistva kohtuotsusega süüdi mõistetud korruptsiooni eest kõige rohkem viimase viie aasta jooksul või kehtib süüdimõistvas kohtuotsuses sätestatud kõrvalejäämise kohustus endiselt? See kõrvalejätmise alus hõlmab ka korruptsiooni avaliku sektori hankija (võrgustiku sektori hankija) või ettevõtja riigi õiguses sätestatud määratluses.

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

7 / 21

Koostatud 18.12.2024 11:43:17 https://riigihanked.riik.ee/rhr-web/#/procurement/8172764/general-info

Ettevõtjalt oodatavad vastused:

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

PETTUS

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

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

Ettevõtjalt oodatavad vastused:

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

TERRORIAKTI TOIMEPANEK VÕI TERRORISTLIKU TEGEVUSEGA SEOTUD

ÕIGUSRIKKUMISED

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

Viide seadusele:

8 / 21

Koostatud 18.12.2024 11:43:17 https://riigihanked.riik.ee/rhr-web/#/procurement/8172764/general-info

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

Ettevõtjalt oodatavad vastused:

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

RAHAPESU VÕI TERRORISMI RAHASTAMINE

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

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

Ettevõtjalt oodatavad vastused:

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

9 / 21

Koostatud 18.12.2024 11:43:17 https://riigihanked.riik.ee/rhr-web/#/procurement/8172764/general-info

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

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

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

Ettevõtjalt oodatavad vastused:

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

B: Kõrvalejätmise alused seoses maksude või sotsiaalkindlustusmaksete tasumisega

MAKSUDE TASUMINE

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

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

10 / 21

Koostatud 18.12.2024 11:43:17 https://riigihanked.riik.ee/rhr-web/#/procurement/8172764/general-info

Tingimuse kirjeldus: Piirmäär: 0

Valuuta: EUR

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

Ettevõtjalt oodatavad vastused:

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

SOTSIAALKINDLUSTUSMAKSETE TASUMINE

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

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

11 / 21

Koostatud 18.12.2024 11:43:17 https://riigihanked.riik.ee/rhr-web/#/procurement/8172764/general-info

Tingimuse kirjeldus: Piirmäär: 0

Valuuta: EUR

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

Ettevõtjalt oodatavad vastused:

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

C: Kõrvalejätmise alused seoses maksejõuetusega, huvide konfliktiga või ametialaste käitumisreeglite rikkumisega

KESKKONNAÕIGUSE VALDKONNAS KOHALDATAVATE KOHUSTUSTE TÄITMATA

JÄTMINE

Kas ettevõtja on enda teada rikkunud keskkonnaõiguse valdkonnas kohaldatavaid kohustusi?

Viide seadusele: RHS § 95 lg 4 p 2 „kes on rikkunud õigusaktidest või kollektiivlepingust tulenevaid keskkonnaõiguse valdkonnas kohaldatavaid kohustusi“. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.

12 / 21

Koostatud 18.12.2024 11:43:17 https://riigihanked.riik.ee/rhr-web/#/procurement/8172764/general-info

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 3. Kas olete võtnud meetmeid, et tõendada oma usaldusväärsust („Self-Cleaning”)? (Raadionupp valikutega "Jah/Ei") 4. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 5. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 6. URL (Url) 7. Kood (Sisestusväli (max pikkus 250 tähemärki)) 8. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

SOTSIAALÕIGUSE VALDKONNAS KOHALDATAVATE KOHUSTUSTE TÄITMATA

JÄTMINE

Kas ettevõtja on enda teada rikkunud sotsiaalõiguse valdkonnas kohaldatavaid kohustusi?

Viide seadusele: RHS § 95 lg 4 p 2 „kes on rikkunud õigusaktidest või kollektiivlepingust tulenevaid sotsiaalõiguse valdkonnas kohaldatavaid kohustusi“. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 3. Kas olete võtnud meetmeid, et tõendada oma usaldusväärsust („Self-Cleaning”)? (Raadionupp valikutega "Jah/Ei") 4. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 5. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 6. URL (Url) 7. Kood (Sisestusväli (max pikkus 250 tähemärki)) 8. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

TÖÖÕIGUSE VALDKONNAS KOHALDATAVATE KOHUSTUSTE TÄITMATA

JÄTMINE

Kas ettevõtja on enda teada rikkunud tööõiguse valdkonnas kohaldatavaid kohustusi?

Viide seadusele: RHS § 95 lg 4 p 2 „kes on rikkunud õigusaktidest või kollektiivlepingust tulenevaid tööõiguse valdkonnas kohaldatavaid kohustusi“. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.

13 / 21

Koostatud 18.12.2024 11:43:17 https://riigihanked.riik.ee/rhr-web/#/procurement/8172764/general-info

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 3. Kas olete võtnud meetmeid, et tõendada oma usaldusväärsust („Self-Cleaning”)? (Raadionupp valikutega "Jah/Ei") 4. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 5. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 6. URL (Url) 7. Kood (Sisestusväli (max pikkus 250 tähemärki)) 8. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

PANKROT

Kas ettevõtja on pankrotis?

Viide seadusele: RHS § 95 lg 4 p 3 „kes on pankrotis, välja arvatud asjade ostmisel RHS § 49 lõikes 4 sätestatud juhul ja tingimustel“. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 3. Märkige põhjused, miks lepingu täitmine on sellest hoolimata võimalik. Seda teavet ei ole tarvis esitada, kui ettevõtja kõrvalejätmine on kohaldatava siseriikliku õiguse alusel muudetud konkreetsel juhul kohustuslikuks ja puudub võimalus teha erandit, isegi kui ettevõtja suudab lepingut täita. (Suur sisestusala (max pikkus 4000 tähemärki)) 4. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 5. URL (Url) 6. Kood (Sisestusväli (max pikkus 250 tähemärki)) 7. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

MAKSEJÕUETUS

Kas ettevõtja suhtes on algatatud maksejõuetus- või likvideerimismenetlus?

Viide seadusele: RHS § 95 lg 4 p 3 „kes on likvideerimisel või kelle suhtes on algatatud pankrotimenetlus, välja arvatud asjade ostmisel RHS § 49 lõikes 4 sätestatud juhul ja tingimustel“. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.

14 / 21

Koostatud 18.12.2024 11:43:17 https://riigihanked.riik.ee/rhr-web/#/procurement/8172764/general-info

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 3. Märkige põhjused, miks lepingu täitmine on sellest hoolimata võimalik. Seda teavet ei ole tarvis esitada, kui ettevõtja kõrvalejätmine on kohaldatava siseriikliku õiguse alusel muudetud konkreetsel juhul kohustuslikuks ja puudub võimalus teha erandit, isegi kui ettevõtja suudab lepingut täita. (Suur sisestusala (max pikkus 4000 tähemärki)) 4. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 5. URL (Url) 6. Kood (Sisestusväli (max pikkus 250 tähemärki)) 7. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

KOKKULEPE VÕLAUSALDAJATEGA

Kas ettevõtja on sõlminud kokkuleppe võlausaldajatega?

Viide seadusele: RHS § 95 lg 4 p 3 „kes on muus sellesarnases olukorras tema asukohamaa õigusaktide kohaselt, välja arvatud asjade ostmisel RHS § 49 lõikes 4 sätestatud juhul ja tingimustel“. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 3. Märkige põhjused, miks lepingu täitmine on sellest hoolimata võimalik. Seda teavet ei ole tarvis esitada, kui ettevõtja kõrvalejätmine on kohaldatava siseriikliku õiguse alusel muudetud konkreetsel juhul kohustuslikuks ja puudub võimalus teha erandit, isegi kui ettevõtja suudab lepingut täita. (Suur sisestusala (max pikkus 4000 tähemärki)) 4. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 5. URL (Url) 6. Kood (Sisestusväli (max pikkus 250 tähemärki)) 7. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

SISERIIKLIKU ÕIGUSE KOHANE SAMALAADNE OLUKORD, NÄITEKS PANKROT

Kas ettevõtja on siseriiklike õigusnormide alusel toimuva samalaadse menetluse tõttu samalaadses olukorras?

Viide seadusele: RHS § 95 lg 4 p 3 „kes on muus sellesarnases olukorras tema asukohamaa õigusaktide kohaselt“, välja arvatud asjade ostmisel RHS § 49 lõikes 4 sätestatud juhul ja tingimustel. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.

15 / 21

Koostatud 18.12.2024 11:43:17 https://riigihanked.riik.ee/rhr-web/#/procurement/8172764/general-info

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 3. Märkige põhjused, miks lepingu täitmine on sellest hoolimata võimalik. Seda teavet ei ole tarvis esitada, kui ettevõtja kõrvalejätmine on kohaldatava siseriikliku õiguse alusel muudetud konkreetsel juhul kohustuslikuks ja puudub võimalus teha erandit, isegi kui ettevõtja suudab lepingut täita. (Suur sisestusala (max pikkus 4000 tähemärki)) 4. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 5. URL (Url) 6. Kood (Sisestusväli (max pikkus 250 tähemärki)) 7. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

VARA HALDAB LIKVIDEERIJA

Kas ettevõtja vara haldab likvideerija või kohus?

Viide seadusele: RHS § 95 lg 4 p 3 „kes on pankrotis, likvideerimisel või kelle suhtes on algatatud pankrotimenetlus või kes on muus sellesarnases olukorras tema asukohamaa õigusaktide kohaselt, välja arvatud asjade ostmisel RHS § 49 lõikes 4 sätestatud juhul ja tingimustel“. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 3. Märkige põhjused, miks lepingu täitmine on sellest hoolimata võimalik. Seda teavet ei ole tarvis esitada, kui ettevõtja kõrvalejätmine on kohaldatava siseriikliku õiguse alusel muudetud konkreetsel juhul kohustuslikuks ja puudub võimalus teha erandit, isegi kui ettevõtja suudab lepingut täita. (Suur sisestusala (max pikkus 4000 tähemärki)) 4. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 5. URL (Url) 6. Kood (Sisestusväli (max pikkus 250 tähemärki)) 7. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

ÄRITEGEVUS ON PEATATUD

Kas ettevõtja äritegevus on peatatud?

Viide seadusele: RHS § 95 lg 4 p 3 „kelle äritegevus on peatatud, välja arvatud asjade ostmisel RHS § 49 lõikes 4 sätestatud juhul ja tingimustel“. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.

16 / 21

Koostatud 18.12.2024 11:43:17 https://riigihanked.riik.ee/rhr-web/#/procurement/8172764/general-info

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 3. Märkige põhjused, miks lepingu täitmine on sellest hoolimata võimalik. Seda teavet ei ole tarvis esitada, kui ettevõtja kõrvalejätmine on kohaldatava siseriikliku õiguse alusel muudetud konkreetsel juhul kohustuslikuks ja puudub võimalus teha erandit, isegi kui ettevõtja suudab lepingut täita. (Suur sisestusala (max pikkus 4000 tähemärki)) 4. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 5. URL (Url) 6. Kood (Sisestusväli (max pikkus 250 tähemärki)) 7. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

SÜÜDI AMETIALASTE KÄITUMISREEGLITE OLULISES RIKKUMISES

Kas ettevõtja on süüdi ametialaste käitumisreeglite olulises rikkumises? Vt siseriiklikud õigusaktid, asjaomane teade või hankedokumendid, kui see on asjakohane.

Viide seadusele: RHS § 95 lg 4 p 4 „kes on raskelt eksinud ametialaste käitumisreeglite vastu ja see muudab tema aususe küsitavaks“. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 3. Kas olete võtnud meetmeid, et tõendada oma usaldusväärsust („Self-Cleaning”)? (Raadionupp valikutega "Jah/Ei") 4. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 5. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 6. URL (Url) 7. Kood (Sisestusväli (max pikkus 250 tähemärki)) 8. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

KONKURENTSI MOONUTAMISE EESMÄRGIL TEISTE ETTEVÕTJATEGA

SÕLMITUD KOKKULEPPED

Kas ettevõtja on teiste ettevõtjatega sõlminud kokkuleppeid, mille eesmärk on moonutada konkurentsi?

Viide seadusele: RHS § 95 lg 4 p 5 „konkurentsi kahjustava kokkuleppe, ettevõtjate ühenduse otsuse või kooskõlastatud tegevuse tõttu“. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.

17 / 21

Koostatud 18.12.2024 11:43:17 https://riigihanked.riik.ee/rhr-web/#/procurement/8172764/general-info

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 3. Kas olete võtnud meetmeid, et tõendada oma usaldusväärsust („Self-Cleaning”)? (Raadionupp valikutega "Jah/Ei") 4. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 5. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 6. URL (Url) 7. Kood (Sisestusväli (max pikkus 250 tähemärki)) 8. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

HANKEMENETLUSES OSALEMISEGA KAASNEV HUVIDE KONFLIKT

Kas ettevõtja on teadlik hankemenetluses osalemisega kaasnevast mis tahes huvide konfliktist siseriikliku õiguse, asjakohase teatise või hankedokumentide kohaselt?

Viide seadusele: RHS § 95 lg 4 p 6 „kui huvide konflikti ei ole muude vahenditega võimalik vältida“. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.

Ettevõtjalt oodatavad vastused:

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

OTSENE VÕI KAUDNE OSALEMINE KÄESOLEVA HANKEMENETLUSE

ETTEVALMISTAMISEL

Kas ettevõtja või temaga seotud ettevõtja on nõustanud avaliku sektori hankijat või võrgustiku sektori hankijat hankemenetluse ettevalmistamisel või olnud muul viisil seotud hankemenetluse ettevalmistamisega?

Viide seadusele: RHS § 95 lg 4 p 7 „kelle pakkumuse või taotluse koostamisel on osalenud isik, kes on osalenud sama riigihanke ettevalmistamisel või on muul viisil hankijaga seotud, ja sellele isikule seetõttu teadaolev info annab talle eelise teiste riigihankes osalejate eest ning sellest tingitud konkurentsi moonutamist ei ole muude vahendistega võimalik vältida“. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.

18 / 21

Koostatud 18.12.2024 11:43:17 https://riigihanked.riik.ee/rhr-web/#/procurement/8172764/general-info

Ettevõtjalt oodatavad vastused:

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

ENNETÄHTAEGNE LÕPETAMINE, KAHJUTASU VÕI VÕRRELDAVAD

SANKTSIOONID

Kas ettevõtja on kogenud, et varasem riigihankeleping või võrgustiku sektori hankijaga sõlmitud varasem hankeleping või varasem kontsessioonileping on lõpetatud enneaegselt, või on määratud kahjutasu või sellega võrreldavad sanktsioonid seoses kõnealuse varasema lepinguga?

Viide seadusele: RHS § 95 lg 4 p 8 „kes on oluliselt või pidevalt rikkunud eelnevalt sõlmitud hankelepingu olulist tingimust või hankelepingute olulisi tingimusi nii, et rikkumise tulemusena on lepingust taganetud või leping üles öeldud, hinda alandatud, hüvitatud kahju või makstud leppetrahvi". Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud. Alates 1.09.2017 alustatud hangete tulemusena sõlmitud riigihankelepingute kohta leiab infot riigihangete registrist.

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 3. Kas olete võtnud meetmeid, et tõendada oma usaldusväärsust („Self-Cleaning”)? (Raadionupp valikutega "Jah/Ei") 4. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 5. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 6. URL (Url) 7. Kood (Sisestusväli (max pikkus 250 tähemärki)) 8. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

SÜÜDI VALEANDMETE ESITAMISES, ON JÄTNUD TEAVET ESITAMATA, EI SUUDA

NÕUTUD DOKUMENTE ESITADA, HANKINUD KÄESOLEVA MENETLUSE KOHTA

KONFIDENTSIAALSET TEAVET

Kas ettevõtja on olnud ühes järgmistest olukordadest: a) ta on kõrvalejätmise aluste puudumise või valikukriteeriumide täitmise kontrollimiseks nõutava teabe esitamisel esitanud valeandmeid; b) ta on jätnud sellist teavet esitamata; c) ta ei ole esitanud viivitamata avaliku sektori hankija või võrgustiku sektori hankija nõutud täiendavad dokumendid, ja d) ta on tegutsenud eesmärgiga mõjutada lubamatul viisil avaliku sektori hankija või võrgustiku sektori hankija otsustusprotsessi, et saada konfidentsiaalseid andmeid, mis võivad anda talle põhjendamatu eelise hankemenetluses, või hooletusest esitanud eksitavat teavet, mis võib oluliselt mõjutada kõrvalejätmise, valiku või lepingu hindamise kohta tehtavaid otsuseid?

Viide seadusele: RHS § 95 lg 4 p 9 „kes on esitanud valeandmeid käesolevas paragrahvis sätestatud või RHS §- des 98-101 sätestatu alusel hankija kehtestatud kvalifitseerimise tingimustele vastavuse kohta“;

19 / 21

Koostatud 18.12.2024 11:43:17 https://riigihanked.riik.ee/rhr-web/#/procurement/8172764/general-info

RHS § 95 lg 4 p 9 „kes on jätnud andmed käesolevas paragrahvis sätestatud või käesoleva seaduse §-des 98-101 sätestatu alusel hankija kehtestatud kvalifitseerimise tingimustele vastavuse kohta esitamata“; RHS § 95 lg 4 p 9 „kes on jätnud käesoleva seaduse § 104 lõigete 7 ja 8 alusel hankija nõutud täiendavad dokumendid esitamata“; RHS § 95 lg 4 p 10 „kes on tegutsenud eesmärgiga mõjutada hankijat või esitanud hooletusest eksitavat teavet, mis on võinud mõjutada hankija otsuseid riigihankes, või on tegutsenud eesmärgiga saada konfidentsiaalset teavet, mis on võinud anda talle põhjendamatu eelise teiste riigihankes osalejate ees“. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.

Ettevõtjalt oodatavad vastused:

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

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

AINULT SISERIIKLIKEST ÕIGUSAKTIDEST TULENEVAD KÕRVALEJÄTMISE

ALUSED: SEADUSLIKU ALUSETA VIIBIVALE VÄLISMAALASELE TÖÖTAMISE

VÕIMALDAMISE EEST

Kas ettevõtja on rikkunud RHS § 95 lg 1 p-st 2 tuleneva kõrvalejätmise alusega seotud kohustusi?

Viide seadusele: RHS § 95 lg 1 p 2 „keda või kelle haldus-, juhtimis- või järelevalveorgani liiget, prokuristi või muud isikut, kellel on volitus seda ettevõtjat esindada, tema nimel otsuseid teha või teda kontrollida, on karistatud riigis ilma seadusliku aluseta viibivale välismaalasele töötamise võimaldamise või välismaalase Eestis töötamise tingimuste rikkumise võimaldamise, sealhulgas seaduses sätestatud töötasu määrast väiksema töötasu maksmise eest“. Kohustuslik kõrvaldamise alus. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.

Ettevõtjalt oodatavad vastused:

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

AINULT SISERIIKLIKEST ÕIGUSAKTIDEST TULENEVAD KÕRVALEJÄTMISE

ALUSED: RAHVUSVAHELISE SANKTSIOONI SUBJEKT

Kas ettevõtja on rikkunud RHS § 95 lg 1 p-st 5 tuleneva kõrvalejätmise alusega seotud kohustusi?

20 / 21

Koostatud 18.12.2024 11:43:17 https://riigihanked.riik.ee/rhr-web/#/procurement/8172764/general-info

Viide seadusele: RHS § 95 lg 1 p 5. Kellega hankelepingu sõlmimine rikuks rahvusvahelist või Vabariigi Valitsuse sanktsiooni rahvusvahelise sanktsiooni seaduse tähenduses. Hankija kontrollib käesoleva seaduse § 95 lõike 1 punktis 5 sätestatud kõrvaldamise alust pakkuja või taotleja kinnituse alusel. Hankija võib põhjendatud kahtluse korral nõuda pakkujalt või taotlejalt täiendavate andmete või tõendite esitamist, mis võimaldavad kõrvaldamise alust kontrollida. (RHS § 96 lg 2.1).

Ettevõtjalt oodatavad vastused:

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

AINULT SISERIIKLIKEST ÕIGUSAKTIDEST TULENEVAD KÕRVALEJÄTMISE

ALUSED: KARISTATUD MAKSUALASTE SÜÜTEGUDE EEST

Kas ettevõtja on rikkunud RHS § 95 lg 4 p-st 11 tuleneva kõrvalejätmise alusega seotud kohustusi?

Viide seadusele: RHS § 95 lg 4 p 11 „keda või kelle haldus-, juhtimis- või järelevalveorgani liiget või muud seaduslikku esindajat on karistatud maksualaste süütegude eest“. Vabatahtlik kõrvaldamise alus. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.

Ettevõtjalt oodatavad vastused:

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

IV OSA: KVALIFITSEERIMISTINGIMUSED

B: Majanduslik ja finantsseisund

ÜLDINE AASTAKÄIVE

Ettevõtja üldine aastakäive on asjaomases teates, hankedokumentides või hankepassis nõutud majandusaastate jooksul järgmine:

Viide seadusele: RHS § 100 lg 1 p 4 „andmed pakkuja või taotleja kogu majandustegevuse netokäibe kohta kuni viimase kolme riigihanke algamise ajaks lõppenud majandusaasta jooksul, sõltuvalt pakkuja või taotleja asutamise või äritegevuse alguse kuupäevast“

Tingimuse selgitus:

21 / 21

Koostatud 18.12.2024 11:43:17 https://riigihanked.riik.ee/rhr-web/#/procurement/8172764/general-info

Pakkuja viimase kolme lõppenud majandusaasta iga aasta minimaalne netokäive peab olema vähemalt 400 000 eurot käibemaksuta. Pakkuja esitab andmed netokäibe kohta hankepassis.

Tingimuse kirjeldus: Miinimumnõue: 400000

Valuuta: EUR

Ettevõtjalt oodatavad vastused:

1. Ajavahemik (Periood) 2. Käive (Summa) 3. Valuuta (Vääring) 4. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 5. URL (Url) 6. Kood (Sisestusväli (max pikkus 250 tähemärki)) 7. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

1 / 2

Koostatud 18.12.2024 11:47:16 https://riigihanked.riik.ee/rhr-web/#/procurement/8172764/general-info

VASTAVUSTINGIMUSED Viitenumber: 288139 Hankija: Siseministeeriumi infotehnoloogia- ja arenduskeskus (70008440) Hange: Rahvastikuregistri andmelattu päringu logide baasil aruannete loomine

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

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

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

2. Kui tegemist on ühispakkumusega, kas olete lisanud pakkumuse "Lisadokumentide" lehele ühispakkujate volikirja? Kui tegemist ei ole ühispakkumusega, vastake "Ei"". (Raadionupp valikutega "Jah/Ei")

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

Tingimusliku pakkumuse esitamine ei ole lubatud.

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

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,

2 / 2

Koostatud 18.12.2024 11:47:16 https://riigihanked.riik.ee/rhr-web/#/procurement/8172764/general-info

tuleb lugeda selliselt, et see on täiendatud märkega „või sellega samaväärne“ (RHS § 88 lg-d 5-6, § 89 lg 2, 114 lg-d 5-7). Hankija aktsepteerib objektiivsetel põhjustel muid asjakohaseid tõendeid, kui pakkuja tõendab hankijale vastuvõetaval viisil, et pakutav asi, teenus või ehitustöö vastab konkreetse märgise või hankija esitatud nõuetele, välja arvatud juhul, kui hankija nõutud märgis, samaväärne märgis või konkreetse või samaväärse vastavushindamisasutuse väljastatud katsearuanne või muu tõend on seaduse alusel eelduseks asja, teenuse või ehitustöö pakkumiseks turul (RHS § 114 lg 7).

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

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

ANDMELAO VANEMARENDAJA

Pakkuja rakendab hankelepingu täitmisele andmelao varemarendaja. Spetsialist peab vastama CV- s toodud nõuetele. Igasse rolli esitatatakse üks isik, rolle katta ei ole lubatud.

Küsimused ettevõtjale: 1. Pakkuja esitab spetsialisti CV hankija etteantud vormil (Lisa 4.2) (Vabas vormis dokument)

TABLEAU ARUANNETE ARENDAJA

Pakkuja rakendab hankelepingu täitmisele aruannete varemarendaja. Spetsialist peab vastama CV- s toodud nõuetele. Igasse rolli esitatatakse üks isik, rolle katta ei ole lubatud.

Küsimused ettevõtjale: 1. Pakkuja esitab spetsialisti CV hankija etteantud vormil (Lisa 4.3) (Vabas vormis dokument)

Koostatud 20.01.2025 15:26:51 1 / 2 https://riigihanked.riik.ee/rhr-web/#/procurement/ 8172764/general-info

HINDAMISKRITEERIUMID JA HINNATAVAD NÄITAJAD

Viitenumber: 288139 Hankija: Siseministeeriumi infotehnoloogia- ja arenduskeskus (70008440) Hange: Rahvastikuregistri andmelattu päringu logide baasil aruannete loomine

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

Jrk nr

Nimetus Kirjeldus Tüüp / hindamismeetod

Osakaal Kogus Ühik Pakkuja täidetav

1 Pakkumuse kogumaksumus Maksumus - vähim on parim

28 EUR jah

2 Spetsialisti kogemus – Andmelao vanemarendaja; Uus alliksüsteem (projektide arv)

Vanemarendaja osalemine projektis/ projektides, kus ta on loonud uuest allikandmebaasist esmase andmete laadimine andmelattu.

Kvaliteet - hankija hinnatav

18

3 Spetsialisti kogemus - Andmelao vanemarendaja; Tableau Prep (projektide arv)

Andmelao arendaja osalemine projektis/ projektides, kus ta on teostanud Tableau Prep’iga (või muu samaväärne) andmete ettevalmistamise (puhastamise) Tableau (või muu samaväärne) aruannete arendamiseks.

Kvaliteet - hankija hinnatav

18

4 Spetsialisti kogemus - Tableau aruannete arendaja; Story funktsionaalsus (projektide arv)

Tableau (või muu samaväärne) aruannete arendaja osalemine projektis/ projektides, kus ta on loonud igas projektis vähemalt vähemalt ühe (1) aruande kasutades Story funktsionaalsust.

Kvaliteet - hankija hinnatav

18

5 Spetsialisti kogemus - Tableau aruannete arendaja; Andmeanalüüs (projektide arv)

Tableau (või muu samaväärne) aruannete arendaja osalemine IT analüütikuna andmelao projektis/ projektides, kus ta on kirjeldanud igas projektis vähemalt 1 andmemudeli, kus on kasutatud enam kui 5

Kvaliteet - hankija hinnatav

18

Koostatud 20.01.2025 15:26:51 2 / 2 https://riigihanked.riik.ee/rhr-web/#/procurement/ 8172764/general-info

allikandmebaasi tabelite vahelisi seoseid.

Kokku: 100

Hindamismetoodika kirjeldus 1.   Pakkumuse kogumaksumus

Madalaima väärtusega pakkumus saab maksimaalse arvu punkte. Teised pakkumused saavad punkte arvutades valemiga: "osakaal" - ("pakkumuse väärtus" - madalaim väärtus") / "suurim väärtus" * "osakaal".

2.   Spetsialisti kogemus – Andmelao vanemarendaja; Uus alliksüsteem (projektide arv) Spetsialisti kogemus osas saab maksimaalse arvu punkte spetsialist, kes on osalenud rohkemates hindamiskriteeriumidele vastavates projektides. Teised spetsialistid saavad punkte proportsionaalselt vähem ja arvutatakse valemiga: pakkumuse väärtus (projektide arv) / "suurim väärtus (suurim projektide arv)" * "osakaal (15 väärtuspunkti)".

3.   Spetsialisti kogemus - Andmelao vanemarendaja; Tableau Prep (projektide arv) Spetsialisti kogemus osas saab maksimaalse arvu punkte spetsialist, kes on osalenud rohkemates hindamiskriteeriumile vastavates projektides. Teised spetsialistid saavad punkte proportsionaalselt vähem ja arvutatakse valemiga: pakkumuse väärtus (projektide arv) / "suurim väärtus (suurim projektide arv)" * "osakaal (15 väärtuspunkti)".

4.   Spetsialisti kogemus - Tableau aruannete arendaja; Story funktsionaalsus (projektide arv) Spetsialisti kogemus osas saab maksimaalse arvu punkte spetsialist, kes on osalenud rohkemates hindamiskriteeriumile vastavates projektides. Teised spetsialistid saavad punkte proportsionaalselt vähem ja arvutatakse valemiga: pakkumuse väärtus (projektide arv) / "suurim väärtus (suurim projektide arv)" * "osakaal (15 väärtuspunkti)".

5.   Spetsialisti kogemus - Tableau aruannete arendaja; Andmeanalüüs (projektide arv) Spetsialisti kogemus osas saab maksimaalse arvu punkte spetsialist, kes on osalenud rohkemates hindamiskriteeriumile vastavates projektides. Teised spetsialistid saavad punkte proportsionaalselt vähem ja arvutatakse valemiga: pakkumuse väärtus (projektide arv) / "suurim väärtus (suurim projektide arv)" * "osakaal (15 väärtuspunkti)".

Eesti: Tarkvara programmeerimis­ ja nõustamisteenused Rahvastikuregistri andmelattu päringu logide baasil aruannete loomine

Hanketeade või kontsessiooniteade – üldkord

1 Hankija

1.1 Hankija Ametlik nimi: Siseministeeriumi infotehnoloogia­ ja arenduskeskus Hankija õiguslik vorm: Keskvalitsusasutus Hankija tegevus: Riigikaitse

2 Menetlus

2.1 Menetlus Pealkiri: Rahvastikuregistri andmelattu päringu logide baasil aruannete loomine Kirjeldus: Rahvastikuregistri andmelattu päringu logide baasil aruannete loomine Menetluse tunnus: d2b6292a­a837­48d4­977e­a1cf47e73258 Sisemine tunnus: 288139 Menetluse liik: Avatud Kiirendatud menetluse põhjendus:  Menetluskorra kirjeldus: Avatud hankemenetlus

2.1.1 Eesmärk Lepingu olemus: Teenused Peamine liigitus (cpv): 72200000 Tarkvara programmeerimis­ ja nõustamisteenused

2.1.4 Üldine teave Lisateave: Hanke osadeks jaotamine ei ole lepingu olemusest tulenevalt võimalik. Hankija ostab arendusteenust ühelt  täitjalt, et tagada hanke tulemusel tarnitava tulemi ühetaolisus. Analüüsitöid, mis osaliselt eelnevad arendustöödele  ja osaliselt toimuvad samal ajal, ei ole lepinguga taotletava eesmärgi saavutamist ohtu seadmata võimalik  arendustöödest selliselt eraldada, et neid saaks teostada erinevad täitjad. Õiguslik alus: Direktiiv 2014/24/EL

2.1.6 Kõrvaldamise alused Ainult siseriiklikest õigusaktidest tulenevad kõrvalejätmise alused: https://riigihanked.riik.ee/rhr­web/#/ procurement/8172764/procurement­passport

5 Osa

5.1 Osa tehniline tunnus: LOT­0000 Pealkiri: Rahvastikuregistri andmelattu päringu logide baasil aruannete loomine Kirjeldus: Rahvastikuregistri andmelattu päringu logide baasil aruannete loomine Sisemine tunnus: 288139

5.1.1 Eesmärk Lepingu olemus: Teenused

https://ted.europa.eu/TED Page 1/5

Peamine liigitus (cpv): 72200000 Tarkvara programmeerimis­ ja nõustamisteenused

5.1.2 Lepingu täitmise koht Riik – jaotus (NUTS): Kesk­Eesti (EE009) Riik: Eesti Lisateave: ­

5.1.2 Lepingu täitmise koht Riik – jaotus (NUTS): Kirde­Eesti (EE00A) Riik: Eesti Lisateave: ­

5.1.2 Lepingu täitmise koht Riik – jaotus (NUTS): Lääne­Eesti (EE004) Riik: Eesti Lisateave: ­

5.1.2 Lepingu täitmise koht Riik – jaotus (NUTS): Lõuna­Eesti (EE008) Riik: Eesti Lisateave: ­

5.1.2 Lepingu täitmise koht Riik – jaotus (NUTS): Põhja­Eesti (EE001) Riik: Eesti Lisateave: ­

5.1.3 Eeldatav kestus Alguskuupäev: 07/04/2025 Kestus: 10 Kuu

5.1.6 Üldine teave Reserveeritud osalemine: Osalemine ei ole reserveeritud. Tuleb esitada lepingu täitmiseks määratud töötajate nimed ja nende kutsekvalifikatsioonid: Ei ole nõutud Hankeprojekt, mida rahastatakse täielikult või osaliselt ELi vahenditest Teave Euroopa Liidu vahendite kohta

ELi vahendite täiendavad üksikasjad: Euroopa Liidu poolt kaasrahastatud Siseministeeriumi valdkondliku  digipöörde 2023­2024 algatuse „RR Andmelao lahenduse II etapp“ vahendid, toetuse kood 1S40­RF21­01212­ RR4

Hanke suhtes kohaldatakse riigihankelepingut (GPA): jah Lisateave: Hanke osadeks jaotamine ei ole lepingu olemusest tulenevalt võimalik. Hankija ostab arendusteenust ühelt  täitjalt, et tagada hanke tulemusel tarnitava tulemi ühetaolisus. Analüüsitöid, mis osaliselt eelnevad arendustöödele  ja osaliselt toimuvad samal ajal, ei ole lepinguga taotletava eesmärgi saavutamist ohtu seadmata võimalik  arendustöödest selliselt eraldada, et neid saaks teostada erinevad täitjad.

5.1.7 Strateegilised hanked

5.1.8 Ligipääsetavuse kriteeriumid Puuetega inimeste juurdepääsukriteeriume ei ole lisatud järgmise põhjendusega Põhjendus: Eraldi ligipääsetavuse nõudeid ei ole riigihankes kehtestatud seetõttu, et arendatavate toodete puhul  järgitakse ettevõtlus­ ja infotehnoloogiaministri 28.02.2019 määrusega nr 20 „Veebilehe ja mobiilirakenduse  ligipääsetavuse nõuded ning ligipääsetavust kirjeldava teabe avaldamise kord“ nõudeid.

https://ted.europa.eu/TED Page 2/5

5.1.9 Kvalifitseerimistingimused Kriteerium:

Liik: Sobivus tegeleda kutsealase tööga Kriteerium:

Liik: Majanduslik ja finantsseisund Kirjeldus: https://riigihanked.riik.ee/rhr­web/#/procurement/8172764/procurement­passport

Kriteerium: Liik: Tehniline ja kutsealane suutlikkus Kirjeldus: https://riigihanked.riik.ee/rhr­web/#/procurement/8172764/procurement­passport

5.1.10 Pakkumuste hindamise kriteeriumid Kriteerium:

Liik: Hind Nimi:  Kirjeldus: Vaata hanke alusdokumentidest Kaal (punktid, täpne): 28

Kriteerium: Liik: Kvaliteet Nimi:  Kirjeldus: Vaata hanke alusdokumentidest Kaal (punktid, täpne): 18

Kriteerium: Liik: Kvaliteet Nimi:  Kirjeldus: Vaata hanke alusdokumentidest Kaal (punktid, täpne): 18

Kriteerium: Liik: Kvaliteet Nimi:  Kirjeldus: Vaata hanke alusdokumentidest Kaal (punktid, täpne): 18

Kriteerium: Liik: Kvaliteet Nimi:  Kirjeldus: Vaata hanke alusdokumentidest Kaal (punktid, täpne): 18

Selle meetodi kirjeldus, mida kasutatakse juhul, kui hindamist ei ole võimalik kriteeriumide abil teostada:  Pakkumuste hindamise kriteeriumide osakaalu märkimata jätmise põhjendus: 

5.1.11 Hankedokumendid Hankedokumentide aadress: https://riigihanked.riik.ee/rhr­web/#/procurement/8172764/general­info

5.1.12 Hanke tingimused Esitamise tingimused:

Elektrooniline esitamine: Nõutav Esitamise aadress: https://riigihanked.riik.ee/rhr­web/#/procurement/8172764/tenders Keeled, milles võib pakkumusi või osalemistaotlusi esitada: eesti keel Elektrooniline kataloog: Ei ole lubatud Variandid: Ei ole lubatud Pakkumuste esitamise tähtaeg: 06/03/2025 15:00 +02:00

https://ted.europa.eu/TED Page 3/5

Pakkumuse jõusoleku tähtaeg: 4 Kuu Teave avaliku avamise kohta:

Avamise kuupäev: 06/03/2025 16:00 +02:00 Koht: https://riigihanked.riik.ee/rhr­web/#/

Lepingutingimused: Lepingu täitmine peab toimuma kaitstud tööhõive programmide raames: Ei E­arveldamine: Nõutav Kasutatakse elektroonilisi tellimusi: ei Kasutatakse elektroonilisi makseid: jah

5.1.15 Vahendid Raamleping:

Ei kohaldata raamlepingut Teave dünaamilise hankesüsteemi kohta:

Ei kohaldata dünaamilist hankesüsteemi Elektrooniline oksjon: ei

5.1.16 Lisateave, lepitus ja vaidlustus Lepitusorganisatsioon: Riigihangete vaidlustuskomisjon Vaidlustusorgan: Riigihangete vaidlustuskomisjon Organisatsioon, mis annab lisateavet hankemenetluse kohta: Siseministeeriumi infotehnoloogia­ ja arenduskeskus Organisatsioon, millele laekuvad osalemistaotlused: Siseministeeriumi infotehnoloogia­ ja arenduskeskus TED eSender: Riigihangete register

8 Organisatsioonid

8.1 ORG­0001 Ametlik nimi: Siseministeeriumi infotehnoloogia­ ja arenduskeskus Registreerimisnumber: 70008440 Postiaadress: Mäealuse tn 2/2   Linn: Tallinn Sihtnumber: 12618 Riik: Eesti Kontaktpunkt: EVELYN KUUSIK E­posti aadress: [email protected] Telefon: +372 56859003 Internetiaadress: http://www.smit.ee Hankija profiil: http://www.smit.ee Selle organisatsiooni rollid:

Hankija Organisatsioon, mis annab lisateavet hankemenetluse kohta Organisatsioon, millele laekuvad osalemistaotlused

8.1 ORG­0002 Ametlik nimi: Riigihangete vaidlustuskomisjon Registreerimisnumber: 1000123 Postiaadress: Tartu mnt 85   Linn: Tallinn Sihtnumber: 10115

https://ted.europa.eu/TED Page 4/5

Riik: Eesti E­posti aadress: [email protected] Telefon: +3726113713 Selle organisatsiooni rollid:

Vaidlustusorgan Lepitusorganisatsioon

8.1 ORG­0003 Ametlik nimi: Riigihangete register Registreerimisnumber: TED64 Linn: Tallinn Riik: Eesti E­posti aadress: [email protected] Telefon: +3726113693 Selle organisatsiooni rollid:

TED eSender

11 Teave teate kohta

11.1 Teave teate kohta Teate tunnus/versioon: 23703d25­f1e1­40ce­9d9d­026cdcd0a616 ­ 01 Vormi liik: Hange Teate liik: Hanketeade või kontsessiooniteade – üldkord Teate saatmise kuupäev: 27/01/2025 11:51 +02:00 Teate saatmise kuupäev (eSender): 27/01/2025 11:51 +02:00 Keeled, milles käesolev teade on ametlikult kättesaadav: eesti keel 

11.2 Avaldamisteave

https://ted.europa.eu/TED Page 5/5

Lisa 7. Kodukord

Hankija nimi: Siseministeeriumi infotehnoloogia- ja arenduskeskus (70008440)

Riigihanke nimetus: Rahvastikuregistri andmelattu päringu logide baasil aruannete

loomine

Riigihanke viitenumber: 288139

Kodukord

Käesolev dokument kirjeldab üldised töökorralduse põhimõtted ning töökorralduse

täpsemad põhimõtted lepitakse kokku iga hankelepingu sõlmimise järgselt.

1. Üldise töökorralduse põhimõtted

1.1 Täitja esindaja võib kasutada isiklikku või Täitja poolt väljastatud töövahendeid

tingimusel, et nende kasutamine ei takista projekti sujuvat valmimist.

1.2 Juhul, kui töö teostamine toimub tellija ruumides, peavad tellija ruumides

viibivad täitja esindajad kinni pidama seal kehtivatest sisekorraeeskirjadest, sh

turvanõuetest, mis on tellija poolt täitjale eelnevalt teatavaks tehtud.

1.3 Töid teostatakse üldjuhul tellija asukohas. Väljaspool Siseministeeriumi

infotehnoloogia- ja arenduskeskus (edaspidi SMIT) ning selle haldusala ruume

töötamisel transpordikulusid, sidekulusid, ruumide renti jms Hankija ei hüvita.

1.4 Vajadusel täpsustavad pooled lepingu sõlmimisel projektimeeskonna liikmete

rollid ja nende ülesanded.

1.5 Täitja tagab tööde teostamise ajal igakülgse läbipaistvuse (sh otsekontakt ja

vajadusel igapäevane suhtlus kõikide täitja meeskonna liikmetega).

1.6 Tööde teostamine toimub vastavalt Scrum agiilse tarkvara arendamise

raamistikule. Poolte kokkuleppel võib tööde teostamise viisi muuta, lähtudes

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

vastavas tegevusvaldkonnas kehtivaid õigusakte, standardeid ja head tava.

1.7 Täitja koostöös tellija kontaktisikuga valmistavad ette (analüüsivad ja

kirjeldavad) tööülesanded tellija projektihaldustarkvaras SMITi Jira (JIRA

Software). Regulaarselt toimuvad toote kuhja (backlog) täpsustamise ja

rafineerimise koosolekud (Backlog Refinement, Grooming), kus analüüsitakse ja

hinnatakse tööde eeldatavad töömahud. Tööd tuleb jagada väiksemateks töödeks

(tükkideks/osadeks) viisil, mis võimaldab tellijale iga sprindi järel saavutatut

esitleda/tutvustada (demo).

1.8 Lepingu teostamine toimub sprintidena (Sprint), mille pikkus on vaikimisi kaks

nädalat, kui tellija ja täitja pole kokku leppinud teisiti.

1.9 Sprindi jooksul toimuvad igapäevaselt püstijalakoosolekud (Daily Scrum,

Standup), kus osaleb kogu arendusmeeskond, kui tellija ja täitja pole kokku

leppinud teisiti.

1.10 Igale sprindile eelneb vaikimisi planeerimiskoosolek (Sprint Planning), kus

võimalikult ühtlase detailsusega määratletakse etapis teostatavad tööd, nende

prioriteedid, teostajad ja/või eeldatav töömaht.

1.11 Kui töö käigus selgub vajadus töö jagamiseks väiksemateks osadeks, tuleb

seda teha koheselt.

1.12 Iga sprindi järel esitleb/tutvustab (demo) täitja saavutatud tulemeid

tellijale/huvigruppidele.

1.13 Iga sprindi järel esitab täitja ülevaate planeeritud ja tegelikult teostatud

arendustööde mahust (nn „põlemisgraafik“, Burndown chart, Sprint Review) koos

selgituste ja vajadusel tulemuslikkuse suurendamise ettepanekutega.

1.14 Igale sprindile järgneb tagasivaatekoosolek (Retrospective, Retro), kus

tehakse tagasivaade viimasele lõppenud sprindile, mille käigus analüüsitakse,

kuidas kulges viimane sprint ja millised olid murekohad ning kuidas neid järgmises

sprindis vältida (vajadusel pannakse kirja tegevuspunktid (action item)).

1.15 Kui täitja ei suuda põhjendada etapi/sprindi planeeritud tööde teostamata

jätmist või tellija ei pea põhjendusi veenvaks, on tellijal õigus leping

ennetähtaegselt üles öelda (vt Lisa 1.1. SMIT toovotulepingu uldtingimused p

16.2) ning korraldada lepingu sõlmimiseks uus seotud hange.

1.16 Arendusmeeskonnas on igapäevase suhtlusvahendina kasutusel Rocket.Chat

või Teams või mõni muu hetkel SMIT-s lubatud suhtlusvahend, mida kasutatakse

kiireloomuliseks ja operatiivseks suhtluseks. Teams / Rocket.Chat või mõne muu

kõneteenuse või telefoni kaudu kokku lepitud otsused tuleb kinnituseks fikseerida

e-kirjaga või arutada ja protokollida koosolekul.

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

eest iseseisvalt.

1.17 Lepingu täitmisega seotud muu (igapäevane) teabevahetus toimub e-kirja,

telefoni, Teams või mõne muu hetkel SMIT-s lubatud suhtlusvahendi teel või

koosoleku vormis. Poolte projektijuhid tagavad teabe edastamise ja saamise.

1.18 Pooled säilitavad projekti e-kirjad, Teamsi ja/või muudes

sõnumivahetuskeskkondades toimunud vestlused projekti ja garantiiperioodi

kehtivuse ajal.

1.19 Koosoleku kokkukutsumisel esitatakse päevakord ja eesmärk. Korralisi

koosolekuid võib poolte kokkuleppel tühistada (hiljemalt samal päeval 2-tunnise

etteteatamise ajaga). Muude koosolekute kutsed tuleb esitada vähemalt 3 (kolm)

tööpäeva enne koosoleku toimumist. Koosoleku kutsele tuleb vastata esimesel

võimalusel.

1.20 Koosoleku toimumise järel koostatakse memo (vastutab koosoleku

korraldaja), otsused protokollitakse ja saadetakse e-kirjaga koosolekul osalenutele

teadmiseks ja/või vajadusel kinnitamiseks.

1.21 E-kirja kasutatakse ametliku suhtluskanalina (v.a kui infot tuleb vastavalt

kodukorrale edastada täitja projektikeskkondade kaudu).

1.22 Kui e-kirjale oodatakse vastust, tuleb pealkirja real või kirja alguses see

üheselt määratleda. Vastust eeldavale e-kirjale tuleb vastata hiljemalt 3 (kolme)

tööpäeva jooksul. Kui e-kirjale ei ole võimalik anda selle aja jooksul sisulist vastust,

tuleb hiljemalt 3 (kolme) tööpäeva jooksul saata sisulise vastuse andmise aeg.

1.23 Telefoni kasutatakse operatiivse ja olulise informatsiooni edastamiseks,

samuti kriisisituatsioonides. Telefonikõnele mitte vastates tuleb tagasi helistada

esimesel võimalusel, aga mitte hiljem kui järgmise tööpäeva lõpus. Olulistel

juhtudel (näiteks arendustööde juurutusfaasis) peavad mõlema poole projektijuhid

olema telefoni teel kättesaadavad ka pärast ametlikku tööpäeva lõppu. Valmisolek

lepitakse eraldi kokku.

1.24 Projektihaldustarkvaraks on SMITi Jira (JIRA Software), mida kasutatakse

arendustööde ning vigade ja probleemide registreerimiseks tööülesannetena ning

tööülesannete täitmise jälgimiseks ja töötundide registreerimiseks.

1.24.1 Vigade menetlemise käigus registreeritakse kõik poolte leitud vead SMITi

Jiras.

1.24.2 Täitja analüüsib vea kirjeldust ning selgitab välja vea põhjuse.

1.24.3 Vigadele määratakse tellija poolt kriitilisuse aste ning neid asutakse

parandama kriitilisuse järjekorras või muus tellija poolt teatavaks tehtud

järjekorras.

1.24.4 Garantiiperioodil asub täitja viga parandama vastavalt lepingus sätestatud

tingimustele.

1.25 Iga meeskonnaliige isiklikult on kohustatud registreerima töötunnid SMITi

Jiras iga tööpäeva lõpuks, kui tellija ja täitja ei lepi kokku teisiti.

1.26 Projekti dokumendihalduskeskkonnaks on SMITi Wiki (Atlassian Confluence)

ning selle keskkonna kasutamine on täitjale kohustuslik dokumentatsiooni

koostamiseks/täiendamiseks/muutmiseks. Dokumenteerimine toimub vastavalt

tellija juhistele või hanke lisale 10 mittefunktsionaalsed nõuded

1.27 Dokumentide hoidmise struktuur, selle täiendused ja muudatused lepitakse

kokku poolte projektijuhtide vahel.

1.28 Dokumentide lisamise, muutmise ja kustutamise reeglid lepitakse kokku

poolte projektijuhtide vahel, kes tagavad kokkulepitud reeglite järgimise oma

meeskonnas.

1.28.1 Projektimeeskonna liikmed (teostajad) vastutavad, et nende poolt

teostatud tööd on teostatud ja dokumenteeritud vastavalt kokkulepitud töö

eesmärgile ning tellija suunistele ja nõuetele ning valdkonnas kehtivatele parimale

praktikale.

1.29 Täitja on kohustatud järgima SMITis kehtivaid arendusnõudeid, sh nõudeid

lähtekoodile. Kehtivad arendusnõuded lisatakse igale hankele.

1.30 Lähtekoodi kvaliteedist ja tehnoloogilisest võlast ülevaate saamiseks

kasutatakse platvormi SonarQube ja täitjal on kohustus SonarQube-i poolt leitud

lähtekoodi vead ja halvad lõhnad (code smells) enne tulemi/commiti üleandmist

parandada. Kui selgub, et tulemi üleandmisel olid lähtekoodis vead ja halvad

lõhnad parandamata, on tellijal õigus tulemit/commiti mitte vastu võtta.

1.31 Täitjal lasub kohustus teha teiste arendajate tulemitele koodiülevaatust (Code

Review) tagamaks lähtekoodi vastavuse koodistiili reeglitele.

1.32 Lähtekood peab olema Täitja poolt piisavalt kommenteeritud, et hiljem oleks

võimalik teha edasiarendusi või parandusi.

1.33 Arendustööde tulemusel valmiva lähtekoodi hoidmiseks on SMITi Git

koodirepositoorium (Atlassian Bitbucket). Täitja meeskonnaliikmetele luuakse

tellija poolt ligipääs koodirepositooriumile lähtekoodi, andmebaasimuudatuste ning

muude tulemite või nende muudatuste üleandmiseks.

1.34 Tarkvara järjepidevaks integreerimiseks ja tarnimiseks (Continuous

Integration, Continuous Deployment CI/CD) kasutatakse Atlassian Bamboo-d.

1.35 CI töövoogude loomine arenduskeskkonnas on arendaja ülesanne.

1.36 Loodavad hanke tulemid antakse üle SMITi koodirepositooriumi kaudu

vastavalt tellija juhistele. Arendustööde tulemite üleandmine (lähtekoodi tarne)

toimub pideva integreerimise (CI) teel või kokkulepitud sagedusega (nt iga

arendustööde sprindi/etapi järel).

1.37 Tarne pre-live keskkonda toimub täitja ning tellija administraatori koostöös.

1.38 Arendamisel lisatakse commitide (lähtekoodi repositooriumisse lisamine)

juurde Jira pileti nr, mille alusel muudatus sisse viiakse ning lühisõnaline

lühikirjeldus, mida muudatused sisaldavad. Commit sõnumi alguses peab olema

alati projekti nimi, mille raames commit tehakse ja informatsioon, kes antud

commiti teeb (isiku nimi).

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

1.39.1 iseendaga kooskõlas (pole vastuolusid, katkiseid mooduleid, iseendaga

vastuolus funktsionaalsust);

1.39.2 üldharu/muu haru tulemiga kooskõlas (üldharus olemasolev pole peale

commiti katki);

1.39.3 SonarQube-i poolt leitud lähtekoodi vead ja halvad lõhnad (code smells)

parandatud (uut tehnoloogilist võlga tekitada ei tohi);

1.39.4 läbinud edukalt SMITis kehtiva kvaliteedivärava (SonarQube-is Quality

Gate);

1.39.5 edaspidi mugavalt kasutatav ja mõistetav, ehk sellel on olemas oma enda

sisseehitatud testid, mis peale järgnevaid võimalikke arendusi/commite/tegevusi

näitaks, kas see konkreetne funktsionaalsuse osa on endiselt korras, või läks katki

ja tuleb korrastada.

1.40 Tarnitav lepingu ese peab ühilduma tellija poolt nõutud tehnilise lahendusega

(erisused on lubatud tellija kontaktisiku kirjalikku taasesitamist võimaldavas

vormis esitatud nõusolekuga), sealhulgas:

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

protseduuride osas ja infosüsteemi arhitektuurset lahendust ja kasutusloogikat;

1.40.2 taaste- ja varundusprotseduurid peavad olema ühilduvad tellija poolt

soovitud tehnilise lahendusega;

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

häireid ega jõudluse langust;

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

sobituma olemasolevatesse ekraanivormidesse ja töövoogu;

1.41 Tööde teostamine ei tohi tekitada häireid tellija mistahes teiste liidestatud

süsteemide või teenuste talitluses, v.a juhul, kui see on tellija ja täitja poolt

eelnevalt kokku lepitud.

1.42 Lepingu alusel teostatud tööde raames loodud tulemid peavad olema testitud

etteantud funktsionaalsuste täitmise kinnitamiseks ja vastama SMITis kehtivatele

arendusnõuetele.

1.43 Tellija jätab endale hankelepingu tingimuste piires õiguse ühepoolselt

täiendada ja muuta üldist töökorraldust, sh arendusnõudeid, teavitades täitjat

kirjalikult ette 1 (üks) kuu.

Siseministeeriumi infotehnoloogia- ja arenduskeskus

Mäealuse 2/2, Tallinn 12618

Telefon 612 6200

E-post [email protected]

Reg. kood 70008440

www.smit.ee

Pakkumuse esitamise ettepanek ja hanke alusdokumendid avatud

hankemenetluses ,,Rahvastikuregistri andmelattu päringu logide baasil

aruannete loomine’’ (288139)

1. Lisad

1.1. Lisa 1 - Hankelepingu projekt;

1.2. Lisa 1.1 - SMIT töövõtulepingu üldtingimused;

1.3. Lisa 2 - Tehniline kirjeldus;

1.4. Lisa 3 - Hankepass;

1.5. Lisa 4 - Vastavustingimused;

1.6. Lisa 4.1 - Ühispakkujate volikiri;

1.7. Lisa 4.2 - Andmelao vanemarendaja CV vorm;

1.8. Lisa 4.3 - Tableau aruannete arendaja CV vorm;

1.9. Lisa 5 - Hindamiskriteeriumid;

1.10. Lisa 6 - Hanketeade;

1.11. Lisa 7 - Kodukord;

1.12. Lisa 8 - Mittefunktsionaalsed nõuded.

2. Riigihanke osadeks jaotamine

2.1. Hankija ei jaga käesolevat riigihanget osadeks.

2.2. Hanke osadeks jaotamine ei ole lepingu olemusest tulenevalt võimalik põhjusel, et

tagatud peab olema hanke tulemi ühetaolisus ja terviklikkus. Analüüsitöid, mis osaliselt

eelnevad arendustöödele ja osaliselt toimuvad samal ajal, ei ole lepinguga taotletava eesmärgi

saavutamist ohtu seadmata võimalik arendustöödest eraldada.

3. Olelusringi kulude arvestamine

3.1. Olelusringi kulusid arvestatakse pakkumuste hindamisel läbi kogumaksumuse. Teisel

viisil olelusringi kulusid arvestada ei ole võimalik, kuna kõik tehnoloogiad hangitavate tööde

teostamiseks peavad kuuluma hankija IT profiili, mistõttu pärast konkreetse tarkvara

arendusteenuse osutamist märkimisväärseid olelusringi kulusid ei teki, tarkvara kasutamise

käigus ei vajata enam täiendavaid arendustöid ega hooldusteenust ning olelusringi kulude

hindamine läbipaistval viisil pole projekti spetsiifilisuse tõttu võimalik.

4. Pakkumuse vormistamine ja esitamine

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

detailsusega, mis võimaldavad hankijal kontrollida nende vastavust riigihanke

alusdokumentides toodud tingimustele.

4.2. Pakkumuse maksumused tuleb esitada eurodes täpsusega kuni kaks kohta pärast koma.

4.3. Pakkumuse maksumus peab olema lõplik ja sisaldama kõiki lepingu tingimuste

nõuetekohaseks täitmiseks vajalikke kulusid, tasusid või makse (v.a käibemaks, mis tuuakse

välja eraldi). 0 või negatiivse väärtusega maksumusi ei ole lubatud kasutada ja sellised

pakkumused on hankijal õigus tunnistada mittevastavaks ning tagasi lükata.

4.4. Kui esitatavate dokumentide koosseisus on kolmanda osapoole poolt paberkandjal

allkirjastatud dokumente, esitada dokument skaneeritud kujul ning originaaldokument esitada

ainult juhul, kui hankija nõuab originaali esitamist.

4.5. Alternatiivlahendused ei ole lubatud.

2(3)

4.6. Iga viidet, mille hankija teeb hanke alusdokumentides mõnele RHS-i § 88 lõikes 2

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

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

Iga viidet, mille hankija teeb hanke alusdokumentides ostuallikale, protsessile, kaubamärgile,

patendile, tüübile, päritolule, märgisele või tootmisviisile, tuleb lugeda selliselt, et see on

täiendatud märkega „või sellega samaväärne“. Samaväärsus tähendab täpselt samu

kasutusomadusi ja funktsionaalsusi.

4.7. Samaväärse lahenduse pakkumisel esitab pakkuja seda tõendavad dokumendid või

andmed. Hankija aktsepteerib objektiivsetel põhjustel muid asjakohaseid tõendeid, kui pakkuja

tõendab hankijale vastuvõetaval viisil, et pakutav asi või teenus 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 või teenuse pakkumiseks turul (RHS § 114 lg 7).

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

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

lisatasusid. Pakkumuse samaväärsust kontrollivad ja hindavad hankija vastavate

erialateadmistega töötajad.

5. Ühispakkumuse esitamine ja/või teise isiku vahenditele tuginemine. Heastamismeetmed

5.1. Ühispakkumuse esitamisel või teise isiku vahenditele tuginemisel tuleb iga ühispakkuja

või tuginetava isiku kohta, kelle majandus-ja/või finantsnäitajatele ja/või tehnilisele ja

kutsealasele pädevusele tuginetakse, esitada hankepass koos kinnitustega kõrvaldamise

aluste puudumise kohta ja nendele kvalifitseerimise tingimustele vastamise kohta, mille

osas isiku näitajatele tuginetakse, et hankija saaks teostada RHS § 103 toodud

kontrollikohustuse. Samuti tuleb esitada välismaa äriühingu hankepass, kelle nimel esitab

pakkumuse filiaal.

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

6. Pakkumuste hindamine, pakkumuse maksumuse esitamine ja edukaks tunnistamine

6.1. Vastavaks tunnistatud pakkumusi hindab hankija 100-väärtuspunkti süsteemis. Edukaks

tunnistatakse majanduslikult soodsaim pakkumus riigihanke alusdokumentides toodud

hindamiskriteeriumide alusel.

6.2. Kui hindamise järgselt on enim võrdselt väärtuspunkte saanud üle ühe pakkumuse,

tunnistatakse edukaks pakkumus, milles pakutud maksumus on madalaim. Juhul, kui ka see

kriteerium on saanud võrdselt punkte, korraldab hankija eduka pakkumuse väljaselgitamiseks

liisuheitmise, võimaldades nendel pakkumuse esitanud pakkujatel liisuheitmise juures viibida.

7. Kõikide pakkumuste tagasilükkamine. Hankemenetluse kehtetuks tunnistamine

7.1. Hankijal on õigus kõik esitatud või vastavaks tunnistatud pakkumused tagasi lükata igal

ajal enne lepingu sõlmimist vastavalt RHS §-s 116 lg 1 sätestatule. Kõigi pakkumuste

tagasilükkamisel teeb hankija sellekohase põhjendatud otsuse.

7.2. Hankija võib teha kõikide pakkumuste tagasilükkamise otsuse punktis 7.2.4 nimetatud

juhul või põhjendatud vajadusel omal algatusel hankemenetluse kehtetuks tunnistada.

Põhjendatud vajaduseks võib olla eelkõige, kuid mitte ainult:

7.2.1. vajadus lepingu eset olulisel määral muuta;

7.2.2. riigihanke läbiviimise aluseks olevad tingimused on oluliselt muutunud ja

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

3(3)

7.2.3. hankemenetluses ilmnenud ebakõlasid ei ole võimalik kõrvaldada ega

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

7.2.4. kui hindamisele kuuluvaid pakkumusi on esitatud vähem kui kaks;

7.2.5. hankija projektile otsustatakse rahastust mitte tagada.

8. Muud tingimused

8.1. Hankija ootus huvitatud isikutele on, et huvitatud isikud 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.

8.2. Pakkuja peab talle allkirjastamiseks edastatud lepingu allkirjastama ja hankijale välja

saatma hiljemalt 5 tööpäeva jooksul alates päevast, mil hankija selle pakkujale välja saatis.

Mõjuval põhjusel võib hankija allkirjastamise tähtaega pikendada, andes edukale pakkujale

sellest kirjalikku taasesitamist võimaldavas vormis teada. Antud tähtaja jooksul lepingu

allkirjastamisest keeldumist või lepingu täitmisele mitte asumist on hankijal õigus käsitleda,

kui edukaks tunnistatud pakkumuse esitanud pakkuja poolset lepingu sõlmimisest keeldumist

ja pakkumuse tagasi võtmist RHS § 119 lg 1 mõttes ning sel juhul tegutseb hankija edasi

vastavalt RHS-s sätestatule.

8.3. Riigihankes saavad osaleda ainult pakkujad või taotlejad, kelle elu- või asukoht on

Eestis, mõnes muus Euroopa Liidu liikmesriigis, muus Euroopa Majanduspiirkonna

lepinguriigis või Maailma Kaubandusorganisatsiooni riigihankelepinguga ühinenud riigis.

Nõuet rakendatakse ka ühispakkujate ja alltöövõtjate suhtes.

8.4. 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 tellija/maksja kohustuste nõuetekohase täitmise tähtaegadest, sh arve tasumiseks

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

8.5. Täitja 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.