Hankeleping

1

HANKELEPING nr 4.2-3/24/199-1

Riigi Infosüsteemi Amet (edaspidi tellija), registrikood 70006317, asukoht Pärnu mnt 139a,

15169 Tallinn, mida esindab seaduse ja põhimääruse alusel peadirektor Joonas Heiter

ja

Aktsiaselts Fujitsu Estonia (edaspidi täitja), registrikood 10239452, asukoht Sepise 7, 11415,

Tallinn, mida esindab seaduse ja põhikirja alusel Seth Gustav Lackman, edaspidi ka pool või

pooled, sõlmisid käesoleva hankelepingu (edaspidi leping) alljärgnevas:

1. Lepingu sõlmimise alus ja ese

1.1 Leping sõlmitakse lähtudes täitjaga sõlmitud raamlepingust nr 4.2-3/22166-1.

1.2 Tööde detailsem kirjeldus on toodud lepingu lisas 1 „Tööde kirjeldus“.

1.3 Lepingu lahutamatuteks osadeks on tellija „Riigiportaali arendus- ja hooldustöö“

(viitenumber 251491) hanke alusdokumendid, tellija minikonkursi „Ettevõtte

finantseerimise teenuse ja ettevõtte tähtajaliste kohustuste teenuse analüüsi-,

jätkuarenduste- ja hooldustööd“ viitenumber 279496 dokumendid ning täitja pakkumus.

1.4 Kõik lepingu muudatused sõlmitakse lepingu lisadena, mis jõustuvad pärast nende

allkirjastamist mõlema poole poolt või poolte määratud tähtajal.

2. Lepingu maksumus, maksetingimused ja tööde üleandmine

2.1 Lepingu maksimaalne kogumaksumus on kuni 800 000 eurot, millele lisandub käibemaks

(edaspidi lepingu maksumus). Lepingu maksumus sisaldab kõiki lepingu täitmiseks

vajalikke kulusid.

2.1.1 Projektijuhi ühetöötunni maksumus on 52,00 eurot, millele lisandub käibemaks;

2.1.2 Ärianalüütiku ühe töötunni maksumus on 56,00 eurot, millele lisandub käibemaks;

2.1.3 Süsteemianalüütiku ühe töötunni maksumus on 56,00 eurot, millele lisandub

käibemaks;

2.1.4 Programmeerija ühe töötunni maksumus on 59,00 eurot, millele lisandub

käibemaks;

2.1.5 Arhitekt/arendaja ühe töötunni maksumus on 64,00 eurot, millele lisandub

käibemaks;

2.1.6 Testija ühe töötunni maksumus on 39,00 eurot, millele lisandub käibemaks;

2.1.7 Kasutatavuse eksperdi ühe töötunni maksumus on 42,00 eurot, millele lisandub

käibemaks.

2.2 Lepingut rahastatakse Teadus- ja arendustegevuse (TA) ja/või EL taaste- ja

vastupidavusrahastu vahenditest ja/või muudest vahenditest ja/või Riigi Infosüsteemi Ameti

eelarvest.

2.3 Tööd antakse üle igakuiselt.

2.4 Täitja kohustub esitama tellijale iga kuu 10-ndaks kuupäevaks üleandmis-vastuvõtmisakti

eelnenud arveldusperioodi eest.

2.5 Tööde üleandmisel tuleb järgida raamlepingu punkti 4.

2.6 Akti esitamisele järgnevast tööpäevast arvates on tellijal 15 tööpäeva aega raportide/tööde

ülevaatamiseks. Tellijal on õigus vajadusel nimetatud perioodi pikendada 1 korra

2

maksimaalselt eelmainitud aja võrra, teavitades sellest enne tähtpäeva saabumist täitjat 3

tööpäeva ette.

2.7 Täitja peab omama tööde teostamiseks sobivaid keskkondi, koos kõige sinna juurde

kuuluvaga sh kasutatava tarkvara litsentse.

2.8 Täitja peab kasutama tööde teostamiseks tellija keskkondi.

2.9 Töö teostamise käik ja/või tulem kantakse tellija lähtekoodi repositooriumisse või Githubi,

vastavalt tellija juhistele.

2.10 Aktis tuuakse eraldi välja meeskonnaliikmete kaupa tehtud tööülesannete loetelu ja nendele

kulunud töötunnid.

2.11 Garantiitingimused on sätestatud raamlepingu punktides 8.1 kuni 8.7.

2.12 Täitja poolt esitatav e-arve peab selgelt ja üheselt viitama lepingule nr 4.2-3/24/199-1 ning

vajadusel EL vms rahastusele, sisaldama makse teostamiseks vajalikke andmeid, riigihanke

osa viitenumbrit 251491 003 004 000, tellija kontaktisiku nime ning vastama

käibemaksuseaduse nõuetele. Käesolevas punktis esitatud tingimustele mittevastav arve ei

kuulu tasumisele.

2.12 Arve maksetähtaeg on 21 kalendripäeva.

2.13 Juhul kui täitja kasutab EL ühtekuuluvus- ja siseturvalisuspoliitika fondide vahenditest

rahastatava hankelepingu puhul alltöövõtjaid ning alltöövõtulepingu maksumus ületab 50

000 eurot käibemaksuta, siis peab täitja esitama andmed alltöövõtu kohta. Taaste- ja

vastupidavuskava vahendite kasutamisel tuleb edukal pakkujal esitada pärast hankelepingu

sõlmimist riigihangete registri lepingu töölehel „Alltöövõtjad“ kõigi hankelepingu täitmises

osalenud alltöövõtjate kohta sõltumata riigihanke eeldatavast maksumusest ja

alltöövõtulepingu maksumusest. Mõlema rahastusallika puhul (EL ühtekuuluvus- ja

siseturvalisuspoliitika kui ka Taaste- ja vastupidavuskava vahendite kasutamisel) täitja

sisestab jooksvalt alltöövõtjatega seotud info – alltöövõtja nimi ja registrikood,

alltöövõtulepingu nimetus, kuupäev, number ja summa – riigihangete registrisse, kus

hankelepinguga seotud andmete juures on olemas vastav vaheleht alltöövõtu jaoks.

3. Lepingu kehtivus ja lõpetamine

3.1 Leping jõustub hetkel, mil pooled on lepingu allkirjastanud ning kehtib kuni p-s 2.1.

märgitud maksimaalse maksumuseni või kuni 31.12.2026, sõltuvalt asjaolust, kumb

sündmus saabub varem.

3.2 Tellija võib lepingu 30 kalendripäevase etteteatamistähtajaga olenemata põhjusest üles

öelda ning sellisel juhul on täitjal õigus nõuda tasu vaid lepingu ülesütlemise hetkeks

faktiliselt tehtud tööde eest.

3.3. Täitjal on õigus leping üles öelda, teatades sellest tellijale kirjalikult ette vähemalt 2

nädalat, kui tellija keeldub või hoiab kõrvale nõuetekohaselt teostatud tööde vastuvõtmisest

ja/või nende eest tasu maksmisest.

3.4. Ülaltoodud alustel lepingu üles ütlemisel on täitjal õigus tellijalt sisse nõuda tasu lepingu

lõpetamise hetkeks faktiliselt tehtud tööde eest.

4. Kontaktisikud 4.1 Tellija kontaktisikud on:

4.1.1. Tellija esindaja tööde vastuvõtmise aktide, teadete, tellimuste jms lepinguga

seonduvate dokumentide allkirjastamisel on Kai Eisenberg (+372 554 77546,

[email protected]);

3

4.1.2. Tellija kontaktisik tööde teostamise juhendamisel ning täitjale vajaliku

lähteinformatsiooni ja tööülesannete täpsustamisel jmt. on Tanel Tsirgu (+372 5981

9052, [email protected]).

4.2 Täitja kontaktisik on Margus Malva (+372 511 9123, [email protected]).

5. Lõppsätted

5.1 Kõik lepingu muudatused sõlmitakse lepingu lisadena, mis jõustuvad pärast nende

allkirjastamist mõlema poole poolt.

5.2 Käesoleva lepingu täitmisel tekkivad vaidlused ja lahkarvamused lahendavad pooled

läbirääkimiste teel. Kokkuleppe mittesaavutamisel lahendatakse vaidlused Harju

Maakohtus.

5.3 Leping on allkirjastatud digitaalselt.

6. Lisad

6.1 Käesoleva lepingu lahutamatuteks lisadeks selle sõlmimise hetkel on:

6.1.1 lisa 1 „Tööde kirjeldus“;

6.1.2 lisa 2 „Tööde üleandmise-vastuvõtmise akt - näidis“;

6.1.3 lisa 3 „Isikuandmete töötlemise ülevaade - näidis“;

6.1.4 lisa 4 „Dokumentatsiooniplaan“.

4

Raamlepingu nr ……… lisa 2

Riigi Infosüsteemi Ameti ja

…………….. vahel sõlmitud

lepingu nr……………….juurde

TÖÖDE ÜLEANDMISE-VASTUVÕTMISE AKT1 - näidis

Käesolev tööde üleandmise- vastuvõtmise akt (edaspidi akt) on koostatud ……………….

(edaspidi täitja) täitja kontaktisiku ……………… poolt ja esitatud Riigi Infosüsteemi Ameti

(edaspidi tellija)……………., (edaspidi koos nimetatud pool või pooled) tõendamaks, et täitja

andis üle poolte vahel sõlmitud lepingu nr …………. ja riigihanke viitenumber …, alusel

teostatud tööd alljärgnevalt:

1. ……………………………………………………… (tehtud tööd, meeskonnaliikmete

kaupa tehtud tööülesannete loetelu, maht, täidetud tingimused, vajadusel viited

lepingupunktidele vm).

2. Käesolevale aktile allakirjutamisega loetakse tööd täitja poolt tellijale üle antuks ning tööde

juhusliku hävimise ja kahjustumise riisiko tellijale üle läinuks.

3. Kinnitame, et ……………… töötles tööde elluviimisel talle teatavaks saanud isikuandmeid

vaid tellija poolt tellitud töödega seotud tööde teostamiseks. Akti esitamisega kinnitame, et

oleme kustutanud kõik tööde käigus teatavaks saanud isikuandmed.

4. Käesolev akt on aluseks täitja poolt tellijale arve esitamiseks summas ………….. eurot,

millele lisandub käibemaks.

5. Käesoleva akti lahutamatud lisad on:

5.1 …………………….

1 Akti võib muuta vastavalt vajadusele ja tellitavale tööle.

1

Ettevõtte finantseerimise teenuse ja ettevõtte tähtajaliste kohustuste

teenuse analüüsi-, jätkuarenduste- ja hooldustööde minikonkurss

1. Olukorrakirjeldus

Majandus- ja Kommunikatsiooniministeeriumi tellimusel valmis aastal 2020 ettevõtja

ühtse veebipõhise kontaktpunkti tulevikuvaade (vt pt 5.2.2) koos prototüübi ja teekaardiga.

Peamiste murekohtadena toodi välja, et:

1. Avaliku sektori osutatavate teenuste, toetuste ning seatud kohustuste info on killustatud

ja sageli raskesti leitav, mõnikord ka vananenud;

2. Palju aega kulub tuvastamaks, kelle poole pöörduda probleemi kiireimaks

lahendamiseks;

3. Asutustele andmete esitamise koormus on kõrge;

4. Puudub ühtne ja terviklik ülevaade riigis pakutavatest avalikest teenustest.

Lahendusena pakuti välja ühtse ettevõtja kontaktpunkti kontseptsioon, kus ettevõtjale

suunatud e-teenused, info ja asjaajamine jm saaks toimuda tervikteenusena „ühest aknast“

eesti.ee portaalist nii riigi sees kui ka piiriüleselt. Ühtse kontaktpunkti kaudu soovitakse

vähendada ettevõtja halduskoormust ja bürokraatiat. Seejuures soovitakse luua ettevõtjatele

ühes keskkonnas ülevaade talle kohalduvatest avaliku sektori seatud kohustustest ning

pakutavatest finantseerimisvõimalustest. Käesolevaks hetkeks on uuenenud eesti.ee ettevõtjale

portaal ehk ühtne kontaktpunkt kasutajatele kättesaadav, samuti on toodangus esimesed uued

ettevõtjatele mõeldud sündmusteenused:

1. Ettevõtte finantseerimise (edaspidi lüh EF1) teenus on RIA poolt arendatav ja hallatav

infosüsteem, kus kasutaja saab ülevaate tema ettevõttele avaliku sektori poolt

pakutavatest finantseerimisvõimalustest. Lisaks suudab teenus suunata kasutajat

taotlust esitama;

2. Ettevõtte tähtajaliste kohustuste (edaspidi lüh ETK2) teenus on RIA poolt arendatav ja

hallatav infosüsteem, kus kasutaja saab ülevaate tema ettevõttele avaliku sektori poolt

seatud tähtajalistest kohustustest. Lisaks suudab teenus suunata kasutajat kohustusi

täitma.

1 https://www.ria.ee/riigi-infosusteem/personaalriik/sundmusteenuste-platvorm 2 Samas

2

2. Tööde eesmärk

EF ja ETK teenuste analüüsi-, jätkuarenduse- ja hooldustööde eesmärgiks on luua

kasutajasõbralikud teenused, mis toimiksid nii desktop- kui mobiilivaates. Kindlustada tarkvara

ajakohasus, toodangukõlblikkus ja kliendivajadustele sobivus läbi jooksvate analüüsi-,

arendus- ja hooldustööde.

3. Tellitavad tööd

Minikonkursiga tellitakse kahe punktis 2 „Tööde eesmärk“ nimetatud ettevõtja rakenduse

analüüsi-, jätkuarendamise- ja hooldusega seotud tööd (tööde loetelu on informatiivne,

valmivad tulemid, nende järjekord, prioriteedid, maht ja sisu võivad tööde teostamise käigus

selguda, täpsustuda või muutuda). Tellijal on õigus koostöös täitjaga täpsustada ja/või

korrigeerida tellitavate tööde skoopi juhul kui tööde käigus selgub selleks põhjendatud vajadus.

Käesoleva minikonkursi alusel võib tellija tellida järgmisi töid:

3.1 äri- ja tehniline analüüs (sh prototüüpimine);

3.2 uute funktsionaalsuste loomine ning edasiarendus;

3.3 jooksvad hooldustööd (sh turvaparandused);

3.4 UX/UI tööd;

3.5 tarkvara testimine (sh vajadusel automaattestide loomine);

3.6 dokumentatsiooni loomine ning uuendamine;

3.7 tellija konsulteerimine ning koolitamine;

3.8 EF ja ETK liidestujate konsulteerimine;

3.9 muud tööd;

4. Tellitavate tööde ajakava

4.1 Hankeleping kehtib kuni 31.12.2026.

4.2 Töödega tuleb alustada kohe peale lepingu sõlmimist.

5. Nõuded tööle ja tulemitele

5.1 Tööde juures lähtutakse järgnevatest nõuetest:

5.1.1 arendused on loodud viisil, mis ei sunni tellijat hankima täiendavat tarkvara või selle

kasutusõigust, on platvormisõltumatud ning kasutatavad vabavaralisena (MIT-

litsents);

5.1.2 valmiv lahendus peab arvestama tellija mittefunktsionaalseid nõudeid. Täpsustatud

3

nõuded saavad täitjale teatavaks lepingu sõlmimisel või vastavasisulise täitja

päringu esitamisel tellijale ning võivad olla ajas muutuvad;

5.1.3 kasutatud on parimaid kaasaegseid tehnoloogiaid ja modulaarse baasarhitektuuri

lahendusi, mis võimaldavad tagada loodava infosüsteemi vastavuse kehtestatud

nõuetele;

5.1.4 arendused ja komponendid on planeeritud selliselt, et need oleks kuluefektiivselt

skaleeritavad (sh mahult, jõudluselt ja funktsionaalsustelt);

5.1.5 tööd peavad arvestama teenusepõhise arhitektuuriloogikaga;

5.1.6 REST API otspunktid dokumenteeritakse automaatselt OpenAPI standardile

vastavalt;

5.1.7 tehtavad tööd ja valmiv lahendus on kooskõlas eesti.ee ettevõtja portaali raames

valmivate tööde tulemitega3;

5.1.8 süsteemi erinevaid komponente/mooduleid on võimalik paralleelselt arendada ja

vajadusel välja vahetada;

5.1.9 uute moodulite lisamine ei põhjusta olulisi muudatusvajadusi olemasolevates

infosüsteemides;

5.1.10 valmivad komponendid peavad olema taaskasutatavad;

5.1.11 lahendus peab olema kasutatavad ka mobiilsetes seadmetes;

5.1.12 valmiv lahendus suurendab andmete automaatse andmetöötluse osakaalu;

5.1.13 pakutav lahendus on kulu/tulu printsiibi ulatuses seadistatav ja konfigureeritav läbi

haldusliidese, ärireeglite muutmisel ei ole vaja muuta tarkvara lähtekoodi;

5.1.14 lahendus töötab välistest liidestest sõltumatult (töö jätkumine peale mõne välise

süsteemi seiskumist);

5.1.15 tööd peavad olema varustatud asjakohase, lihtsasti mõistetava ja edasist arendust

ning haldust võimaldava dokumentatsiooniga/juhendmaterjaliga; dokumentatsioon

valmib eestikeelsena (kui ei ole kokku lepitud teisiti) ning peab vastama raamhanke

(viitenumber 251491) alusdokumendile „Dokumentatsiooniplaani“ nõuetele;

5.1.16 arendustes on kasutatud turvalisi ja jätkusuutlikke tehnoloogilisi lahendusi;

5.1.17 arendustes loodud kood on sellisel tasemel, et see oleks üheselt mõistetav ka projekti

väliste osapoolte ekspertidele;

5.1.18 tellijale üle antud arendused on testitud ja sisaldavad vastavat dokumentatsiooni;

5.1.19 täitja peab tegema koostööd ka teiste tellija poolt nimetatud osapooltega (tellija

3 https://www.eesti.ee/ettevotja/et

4

täpsustab töö käigus);

5.1.20 täitja peab olema valmis tutvustama tehtud töid ja tulemeid Arhitektuurinõukogus

ja/või ka teistel tellija poolt nimetatud kohtumistel;

5.1.21 pakutav lahendus peab olema taaskasutatav ja vaba lähtekoodiga

koodivaramu.eesti.ee lehel;

5.1.22 loodav lahendus peab olema pilvekõlbulik;

5.1.23 loodavaid komponente/mooduleid on võimalik paralleelselt arendada ja vajadusel

välja vahetada;

5.1.24 loodav lahendus peab järgima E-ITS nõudeid4 (võivad aja jooksul täieneda);

5.1.25 loodav lahendus peab järgima eesti.ee stiiliraamatu nõudeid5 (võivad aja jooksul

täieneda);

5.1.26 loodav lahendus peab järgima OWASP ASVS nõudeid6;

5.1.27 loodav lahendus peab järgima WCAG 2.2 nõudeid7;

5.1.28 loodav lahendus peab järgima eesti.ee mittefunktsionaalseid nõudeid8.

5.2 Töödes võetakse aluseks minimaalselt järgnevad materjalid:

5.2.1 Eesti digiühiskonna arengukava 20309;

5.2.2 "Ettevõtjate jaoks ühtse veebipõhise kontaktpunkti visioon“ ja prototüüp ja

teekaart10;

5.2.3 „Ettevõtja ühtse kontaktpunkti arhitektuurianalüüs“11;

5.2.4 „Ettevõtte finantseerimise ärisündmuse analüüs”12 ja arvestatakse desktop13 ning

nutiplatvormi14 prototüüpidega;

4 https://eits.ria.ee/ 5 https://www.figma.com/file/J58K08LMQDeHpdSfM18wU2/Eesti.ee-stiiliraamat-1.0?node-id=146-

5226&t=u8Kw1DR1SOyWyDTR-0 6https://github.com/OWASP/ASVS/blob/v4.0.3/4.0/OWASP%20Application%20Security%20Verification%20

Standard%204.0.3-en.pdf 7 https://www.w3.org/TR/WCAG22/ 8 https://e-gov.github.io/eesti-ee-mfn/ 9 https://www.mkm.ee/digiriik-ja-uhenduvus/digiuhiskonna-arengukava-2030 10 https://mkm.ee/digiriik-ja-uhenduvus/digiteenused/ettevotja-digivarav-ja-

sundmusteenused?view_instance=0&current_page=1 11 https://www.ria.ee/media/727/download 12https://pilv.mkm.ee/s/ZRQQB89TRJZjiYn?path=%2FEttev%C3%B5tte%20finantseerimise%20%C3%A4ris

%C3%BCndmuse%20anal%C3%BC%C3%BCs#pdfviewer 13 https://www.figma.com/proto/CNjaC1R7iPn5tfD4ARfX3A/%C3%84ris%C3%BCndmus?page-

id=16271%3A38052&node-id=16271%3A43351&viewport=2146%2C4401%2C0.27&scaling=scale-

down&starting-point-node-id=16271%3A43351 14 https://www.figma.com/proto/CNjaC1R7iPn5tfD4ARfX3A/%C3%84ris%C3%BCndmus?page-

id=16585%3A36176&node-id=16589%3A39865&viewport=381%2C179%2C0.02&scaling=scale-

down&starting-point-node-id=16589%3A39865

5

5.2.5 „Ettevõtete tähtajaliste kohustuste ja nendest eesti.ee keskkonnas teavitamise

analüüs“15 ja arvestatakse desktop16 ning nutiplatvormi17 prototüüpidega;

5.2.6 Tööde teostamisel arvestatakse Riigi SSO (single sign-on) teenuse18 tehnilise

kirjeldusega;

5.2.7 Valmivad tööd peavad olema kooskõlas kehtivate ühtse digivärava määruse (SDG)19

nõuetega (valmimisel);

5.2.8 Tööde teostamisel arvestatakse üldiste avaliku sektori arhitektuuri arendamise

põhimõtetega20;

5.2.9 Tööde teostamisel arvestatakse tellija teiste koostööpartnerite poolt valmivate

analüüside ja disainitöödega (UX analüüsid jne);

5.2.10 Riigi Infosüsteemi Ameti Mittefunktsionaalseid21 nõuded (võivad aja jooksul

täieneda);

15 https://pilv.mkm.ee/s/TBtg4v9DqkJt5ZC#pdfviewer 16 https://www.figma.com/proto/r06WtU00pvIwaRwg7WovFb/ETTEV%C3%95TJA-

DIGIV%C3%84RAV?page-id=1%3A34687&node-id=507%3A29831&viewport=-

8875%2C318%2C0.25&scaling=min-zoom&starting-point-node-id=1446%3A90808&show-proto-sidebar=1 17 https://www.figma.com/proto/r06WtU00pvIwaRwg7WovFb/ETTEV%C3%95TJA-

DIGIV%C3%84RAV?page-id=1%3A34687&node-id=844%3A44649&viewport=-

8875%2C318%2C0.25&scaling=min-zoom&starting-point-node-id=1454%3A140618&show-proto-sidebar=1 18 https://e-gov.github.io/GOVSSO/ 19 Euroopa Parlamendi ja nõukogu määrus (EL) 2018/1724, 2. oktoober 2018, millega luuakse ühtne digivärav

teabele ja menetlustele ning abi- ja probleemilahendamisteenustele juurdepääsu pakkumiseks ning millega

muudetakse määrust (EL) nr 1024/2012 https://eur-lex.europa.eu/legal-

content/ET/TXT/?uri=uriserv:OJ.L_.2018.295.01.0001.01.EST&toc=OJ:L:2018:295:TOC 20https://projektid.hitsa.ee/download/attachments/34120852/Next%20Generation%20Digital%20Government%

20Architecture.pdf?version=1&modificationDate=1582268586780&api=v2 21 https://e-gov.github.io/MFN/

6

5.3 Tööde juures lähtutakse teadus- ja arendustegevuse põhimõtetest

Eesti.ee ettevõtjale keskkonna ning ettevõtja sündmusteenuste väljaarendamisel on

eesmärgiks seatud uuringute ning eksperimentaalarenduste puhul järgida teadus- ja

arendustegevuse põhitingimusi[22]. Eesti.ee ettevõtjale kontaktpunkti loomise eelduseks on

ettevõtjatele suunatud avalike teenuste uudse sündmusteenuste lahenduste metoodika

väljatöötamine ning kontaktpunkti kui terviku toimimise tehnoloogia põhiprintsiipide

väljaselgitamine ja tehnoloogilise kontseptsiooni sõnastamine. Kontaktpunkti toimimiseks

vajalike protsesside ja tehnoloogiate kasutusele võtmiseks on vaja täiendavalt selgitada nii

tehnoloogia kui ka uuendusliku sündmusteenuste metoodika toimimist asjakohastes

tingimustes, sh töökeskkonnas.

5.3.1 Eesti.ee ettevõtjale lahenduste loomisel ja tegevuste käigus tuleb seega silmas

pidada järgnevaid kriteeriume:

5.3.1.1 uudsus – tegevuste käigus luuakse uut teadmist, ning, midagi sellist, mida ettevõtja

sündmusteenuste ja digivärava väljaarendamise projekti raames praegu Eestis

tehakse, ei ole varasemalt tehtud;

5.3.1.2 loomingulisus – toetudes olemasolevatele teadmistele ning kasutades ka

olemasolevaid tehnilisi lahendusi ja süsteeme pannakse need koos toimima uute

käsitluste ja ideede loomiseks teenuste ja lahenduste jaoks;

5.3.1.3 ettemääramatu tulemus – planeeritud tegevustes ei ole täpselt ette teada, kas

tegevused on ka reaalses elus teostatavad ja millise tulemuseni tegelikult jõutakse;

5.3.1.4 süstemaatilisus – tegevus toimub vastavalt koostatud plaanile, nii protsessid kui ka

saadud tulemused dokumenteeritakse ning vastavalt vajadusele osalevad ka

teadustöö tegijad;

5.3.1.5 ülekantavus ja/või korratavus –tulemused ja nendega seotud uus teadmine peavad

olema kättesaadavad ja kasutatavad rakendamise või kordamise eesmärgil teiste

projektide käigus, et uuest teadmisest saadav kasu oleks maksimaalne. Uuringud ja

lahendused tehakse tasuta kättesaadavaks.

5.3.2 Tööde teostamise ülesehitus ja iseloom peavad toetama loodud uue teadmise

kasutamist publikatsioonide sisendina teaduslikus väljaandes avaldamiseks ja/või

akadeemilise kraadi kaitsmiseks.

22 „Frascati käsiraamat. Teadusuuringuid ja eksperimentaalarendust käsitlevate andmete kogumise ja esitamise

suunised“ (2015), 2. peatükk „Teadus- ja arendustegevust kirjeldavad mõisted ja määratlused“,

https://www.etag.ee/wp-content/uploads/2016/11/FrascatiManual2015_2ptk.pdf

7

6. Nõuded töökorraldusele

6.1 Töid teostatakse vastavalt raamlepingu tingimustele ning töö käigus kokkulepitud

arendusmudelile ja tingimustele.

6.2 Tööde skoop ja prioriseerimine lepitakse kokku tellija esindajaga regulaarsetel

kohtumistel ja toimub tellija JIRA keskkonnas.

6.3 Tellija varustab täitjat kasutuslugude kirjeldustega ning tööde teostamiseks vajaliku

igakülgse informatsiooniga

6.4 Tellijat esindab üks töötaja (lepingus toodud tööülesannete kontaktisik), täitja esindaja

peab ja täidab igapäevaselt projekti portfooliot ning hoiab info ajakohasena vastavalt

kokkulepitud protsessile.

6.5 Projekti dokumentatsioon kirjeldatakse RIA Confluence’is, lähtekoodiga seonduv

tellija poolt valitud koodivaramus.

6.6 Tellija kontaktisik toimib arendusprotsessis tootejuhina, kes prioriseerib

arendusülesandeid ja korraldab vajadustest lähtuvalt ja kokku lepitud

arendusprotsessile vastavalt projekti koosolekuid.

6.7 Täitja annab tööde teostamisel tellijale koheselt teada vajaliku info puudumisest,

tööülesannete lõppemisest, tekkinud tõrgetest jms. Viivituse ajal, mil tellija täpsustab

infot, lahendab tõrget vms, teostab täitja neid tööülesandeid, milles on vajalik info

olemas ja pole tõrkeid.

6.8 Kokkuleppel tellijaga võib toimuda igal tööpäeval eelmise päeva kokkuvõte ja uue

päeva planeerimise kiirkoosolek (stand-up) (võib kasutada tellijaga kooskõlastatult

kaugtöövahendeid).

6.9 Täitja osaleb hanke tulemite esitlusel.

6.10 Täitja meeskonnalt eeldatakse pidevat kontakti ja koostööd tellija ja teiste

koostööpartneritega.

6.11 Täitja ei kasuta töö teostamiseks lahendusi, millega kaasnevad kasutamist

piiravad litsentsitingimused ja/või täiendavad (püsi)kulud, juhul kui ei ole teisiti kokku

lepitud.

6.12 Tarkvara tarnimine, ülespanek, seadistamine ja testimine toimub tellija CI/CD

keskkonnas ehk arendused peavad läbima RIA CI/CD keskkonna. Lisaks on oluline

info leitav ka RIA MFNis. Täpsemad nõuded saavad täitjale teatavaks hankelepingu

sõlmimisel.

6.13 Kõik tööde (vahe)tulemused ja lähtekood laetakse iga tööpäeva lõpus üles ning

hoitakse git protokollil tuginevas RIA poolt määratud keskkonnas.

8

6.14 Töötundide osas toimub igapäevane raporteerimine tellija JIRAs tööülesannete

ja meeskonnaliikme täpsusega.

6.15 Tellija võib nõuda agiilse meeskonna töötamist tellija juures, seonduvaid

sõidukulusid ei hüvitata.

6.16 Täitja peab töö planeerimisel ja teostamisel arvestama ning tegema

konstruktiivset koostööd tellija teiste koostöö- ja arenduspartneritega.

6.17 Arendustöödeks vajalik sisend saadakse ja võimalikud lahenduskäigud

kooskõlastatakse tellija esindajaga (arhitekt, tootejuht vm tellija poolt selleks määratud

isik).

6.18 Täitja ei alusta arendustöödega enne, kui arendustööde skoop ja tehniline

lahendus on kokku lepitud.

6.19 Arendustööde hinnanguline töömaht fikseeritakse enne töödega alustamist

JIRAs.

Riigi Infosüsteemi Ameti ja …………….. vahel sõlmitud hankelepingu nr …./….-… juurde

DOKUMENTATSIOONIPLAAN

Lepingu tööde raames on tellijal õigus nõuda allpool nimetatud dokumenditüüpe.

Esitatav dokumentatsioon peab olema piisav, et tellija saaks käesoleva lepingu alusel loodud

Tööd efektiivselt kasutada, hooldada ja kohandada, täiendades juba olemasolevat

dokumentatsiooni või koostades vajadusel uue dokumentatsiooni. Vastavalt Tööde iseloomule

lepitakse tellijaga kokku dokumentatsiooni piisav pakett.

Dokumendid peavad vastama vähemalt alljärgnevatele tingimustele:

1. Süsteemi üldine kirjeldus

Otstarve: Anda detailne ülevaade süsteemist (ja selle komponentidest) kui tervikust

süsteemi funktsionaalsuse seisukohast.

Sisu: Dokumentatsioon, mis annab detailse ülevaate süsteemist kui tervikust.

Kui on tegemist olemasoleva süsteemi täiendamisega, siis peab kirjeldama

muutuvat ja lisanduvat osa nii, et seda saaks peale üleandmist liita

olemasoleva dokumentatsiooniga.

Süsteemi üldreeglid ja nõuded, süsteemi kõik komponendid – kõik

andmeolemid/tabelid ja nende atribuudid koos nõuete ja reeglitega iga

komponendi jaoks ning nõuete ja reeglitega, mis kehtivad süsteemiüleselt.

Nõuded ja reeglid, mis:

 Kehtivad üle terve süsteemi;

 Kehtivad süsteemi konkreetse komponendi puhul alati;

 Kirjeldavad süsteemi terviklikku protsessi.

Nõudeid ja reegleid toetavad (sisu mõistmisele kaasa aitavad)

diagrammid, tabelid, pildid, stsenaariumid. Keerukate ja mitmekihiliste

süsteemide puhul tuleb kaaluda teha süsteemikirjeldus kihiti eraldi –

näiteks süsteemikirjeldus andmevahetuskihi/kontseptuaalse mudeli põhjal

ja süsteemikirjeldus andmebaasi põhjal (andmemudel), mille sihtgrupp on

teine.

Sihtgrupp: Tellija äriprotsesse valdavad kontaktisikud, ärianalüütikud,

süsteemianalüütikud, täitjast sõltumatud tarkvara hooldajad, arendajad ja

edasiarendajad, testijad, arhitektid, projektijuhid.

Ajakava: Dokumendid esitatakse tellijale kinnitamiseks jooksvalt vastavalt

projektiplaanile. Täisversioon esitatakse lepingu lõppemisel.

Vaheversioonid esitatakse koos üleandmise ja vastuvõtmise aktiga.

2. Teenuste/kasutuslugude dokumentatsioon

Otstarve: Kirjeldab detailselt üleantavaid teenuseid/kasutuslugusid.

Sisu: Teenuste/kasutuslugude detailse kirjelduse sisuks on:

 Kasutusloo/teenusepõhised nõuded (ärinõuded ja neile vastavad

detailsed funktsionaalsuse nõuded);

 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, prototüübid.

Teenuste puhul xml schema (xsd, wsdl) või RESTful teenuste puhul

Swagger.

Sihtgrupp: Tellija äriprotsesse valdavad kontaktisikud, ärianalüütikud,

süsteemianalüütikud, täitjast sõltumatud tarkvara hooldajad, arendajad ja

edasiarendajad, testijad, arhitektid, projektijuhid.

Ajakava: Dokumendid esitatakse tellijale kinnitamiseks jooksvalt vastavalt

projektiplaanile.

Täisversioon esitatakse lepingu lõppemisel. Vaheversioonid esitatakse

koos üleandmise ja vastuvõtmise aktiga.

3. Arhitektuuridokument

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:

1. topoloogia, süsteemi füüsiline arhitektuur (süsteemi komponendid

andmebaasiserver, rakendusserver, meiliserver jms)

2. süsteemi soovituslikud näitajad komponentide kaupa, näiteks

andmesidekiirused, andmemahud, protsessori kiirus, mälumaht,

komponentide arv süsteemi osade kaupa, kettasüsteemi jõudlus

jms

3. liidesed teiste süsteemidega (x-tee, meilisüsteemid) ja sõltuvused

teistest süsteemidest

4. süsteemi tehnilised (sh automaatsed) protsessid ehk töövoog –

komponentide omavahelised suhtlusstsenaariumid ja

koostoimimine (näiteks, mis komponent ja millal pöördub

Rahvastikuregistri teenuse poole)

5. kolmandate osapoolte poolt toodetud kasutatavad

tarkvarad/riistvarad, mis on vajalikud süsteemi toimimiseks

Sihtgrupp: Arhitekt, administraator, turvaspetsialist

Ajakava: Esialgne versioon esitatakse enne arendustööde algust. Täisversioon

esitatakse lepingu lõppemisel. Vaheversioon esitatakse koos üleandmise

ja vastuvõtmise aktiga.

4. Andmemudeli kirjeldus

Otstarve: Süsteemi andmeloogika ülevaate andmiseks ja mõistmise hõlbustamiseks

Sisu: Tarkvara andmeloogika kirjeldus: olemid, olemitevahelised suhted ja

olemite ning olemi atribuutide kirjeldus.

Sihtgrupp: Tellija, tootejuhid, rakenduse administraatorid

Ajakava: Täielik versioon (kogu uuendatud dokument täies mahus) tuleb esitada

lepingu lõppemisel.

5. Seadmete ja tarkvara kasutajakesksed juhendid

Otstarve: Kirjeldus tarkvara ja seadmete kasutamise üldisest protsessist, protsessi

olulisemate sammude kirjeldus. On aluseks kasutajate koolitamisel.

Kasutajajuhend kirjeldab kõiki kasutajate funktsionaalsusi koos

tööprotsesside kirjeldusega ning ekraanipiltide vormis näidetega.

Haldusliidese kasutusjuhend (tootejuhi ja rakenduse administraatori

funktsionaalsus) peab olema eraldi tavakasutaja kasutusjuhendist.

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

1. topoloogia, süsteemi füüsiline arhitektuur (süsteemi komponendid,

andmebaasiserver, rakendusserver, meiliserver jms)

2. süsteemi soovituslikud näitajad komponentide kaupa, näiteks

andmesidekiirused, andmemahud, protsessori kiirus, mälumaht,

komponentide arv süsteemi osade kaupa, kettasüsteemi jõudlus

jms

3. liidesed teiste süsteemidega (x-tee, meilisüsteemid) ja sõltuvused

teistest süsteemidest

4. süsteemi tehnilised (sh automaatsed) protsessid ehk töövoog –

komponentide omavahelised suhtlusstsenaariumid ja

koostoimimine (näiteks, mis komponent ja millal pöördub

Rahvastikuregistri teenuse poole)

5. kolmandate osapoolte poolt toodetud kasutatavad

tarkvarad/riistvarad, mis on vajalikud süsteemi toimimiseks

Sihtgrupp: Tarkvara kasutajad, tootejuht, rakenduse administraator

Ajakava: Vaheversioon (sisaldab sisse viidud muudatusi) tuleb esitada koos

üleandmise ja vastuvõtmise aktiga. Täisversioon (kogu uuendatud

dokument täies mahus) tuleb esitada lepingu lõppemisel.

6. Administreerimisjuhend

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;

 logimise realisatsiooni kirjeldused (kuhu ja mida, kas kasutatakse

roteerimist või katalogiseerimist jms)

 rutiinsete hooldusprotseduuride kirjeldus;

 installeerimispaketi koostamise protseduurid;

 installeerimisprotseduurid.

 installeerimisjuhendis kirjeldatakse iga realiseeritud osa

rakendamine (deployment) koos spetsiifiliste seadistustega.

 installeerimisprotseduurid peavad olema kirjutatud selliselt, et RIA

süsteemiadministraator suudab rakenduse installeerida ilma

kõrvalise abita.

Sihtgrupp: Tootejuht, projektijuht, süsteemiadministraator

Ajakava: Vaheversioon (sisaldab sisse viidud muudatusi) tuleb esitada koos

esimese funktsionaalsuse üleandmisel, kuid mitte hiljem, kui koos

üleandmise ja vastuvõtmise aktiga. Täisversioon (kogu uuendatud

dokument täies mahus) tuleb esitada lepingu lõppemisel.

7. Testide tulemusena valminud dokumentatsioon

Otstarve: Testide dokumentatsiooni järgides peab tellijal olema võimalik

kontrollida süsteemi nõuetekohast käitumist

Sisu: Teostatud arenduste testimisel saadud informatsioon (näiteks testlood,

testraport, testiplaan, testide kood jms). Dokumenteeritakse iga testimise

eesmärgid (testimise maht ja ulatus), tegevused ja tulemused. Sisaldab

jõudlus- ja mahutestide infot ning versiooni infot.

Teste mitteläbinud testlugudele on lisatud parandused või ülesjäänud

vead.

Sihtgrupp: Tellijapoolne projektijuht, vastuvõtutestijad

Ajakava: Testide tulemusena valminud dokumentatsioon esitatakse peale süsteemi

sisse viidud arenduste (muudatuste) testimist koos üleandmise ja

vastuvõtmise aktiga.

8. Taasteplaan

Otstarve: Tagada süsteemi hävingujärgse kiire ja tõrgeteta taastamise.

Taasteplaan on aluseks süsteemi taastamiseks peale suuremat hävingut.

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

1. süsteemi halvamist võimaldavad riskid ja nende esinemise

võimalikkus;

2. süsteemi backup’id, varundamisele kuuluvate komponentide ja

asukohtade loetelu (nt rakenduse konfiguratsioonifailid

rakendusserverist ja andmebaas jne), nende kirjeldused ja

kasutuselevõtu protseduurid;

3. süsteemi komponentide asendusvõimalused, nende

alternatiivkomponentide spetsifikatsioonid

Sihtgrupp: Süsteemiadministraator

Ajakava: Täisversioon (kogu uuendatud dokument täies mahus) tuleb esitada koos

esimese üleandmise ja vastuvõtmise aktiga ning lepingu lõppemisel.

Vaheversioon (sisse viidud muudatuste osas) tuleb esitada taasteplaani

muutumisel.

9. Versioonihalduse dokumentatsioon

Otstarve: Vajalik ülevaate saamiseks infosüsteemi versioonide muudatustest

Sisu: Detailne info iga versiooniuuenduse kohta - avaldamise kuupäev,

versiooni nr, versiooni olemus (peamine, keskmine, parandus,

erakorraline), sisalduvad muudatused, parandamata vead.

Sihtgrupp: Tellijapoolne projektijuht, süsteemiadministraatorid

Ajakava: Esitatakse iga üleantava versiooniga koos ja versiooni kohta.