Leping

Hankeleping nr 3-9/3050-7

Tervise ja Heaolu Infosüsteemide Keskus, registrikood 70009770, aadress Pärnu maantee 132, 11317,

Tallinn, keda esindab põhimääruse alusel direktor Margus Arm, (edaspidi tellija), ja

Bitweb, registrikood11737838, aadress Vallikraavi tn 2, 51003 Tartu, keda esindab põhikirja alusel

Tõnis Tobre (edaspidi täitja),

edaspidi eraldi pool või koos pooled, sõlmisid raamlepingu nr 3-9/3050-1 alusel käesoleva

hankelepingu (edaspidi leping) alljärgnevas:

1. Lepingu ese

1.1. Lepingu esemeks on TEHIK stiilijuhise haldus, mis on kirjeldatud lisatud tehnilises kirjelduses

(edaspidi tööd).

1.2. Lepingu tööde maht on maksimaalselt 416 töötundi. Leping lõpeb mahu täitumisel.

1.3. Lepingut rahastatakse riigi eelarvelistest vahenditest.

2. Töö üleandmise ja vastuvõtmise tingimused

2.1. Täitja annab töö üle kolme kuu jooksul peale lepingu sõlmimist.

2.2. Töötunni põhise lepingu korral esitab täitja eelmise kuu töötundide ajaaruande, mis sisaldab

teostatud töötunde ja nende jooksul teostatud töid. Ajaaruanne esitatakse allkirjastatult

hiljemalt järgmise kalendrikuu 5. tööpäeval. Viimane ajaaruanne esitatakse koos aktiga.

2.3. Tellitavad tööd antakse üle vastavalt lepingu tehnilises kirjelduses kokkulepitud

tingimustele.

2.4. Tellija vaatab töö üle vastavalt raamlepingu tingimustele.

2.5. Koos üle antava tööga annab täitja tellijale üle kõik tööde intellektuaalse omandi õigused

vastavalt raamlepingus kirjeldatule.

3. Lepingu hind

3.1. Lepingu täitmine toimub töötunnipõhisel arvestusel, tellija tasub üksnes lepingu alusel

tellitud ja teostatud töötundide eest.

3.2. Ühe töötunni maksumuseks lepingu täitmisel on 48 (nelikümmend kaheksa) eurot

käibemaksuta.

3.3. Täitja esitab tellijale e-arve pärast töö üleandmise-vastuvõtmise akti allkirjastamist.

3. Poolte vahelised teated ja kontaktisikud

3.1. Teadete edastamisel ja kätte toimetamisel lähtutakse raamlepingu regulatsioonist.

3.2. Tellija kontaktisikuks lepingu täitmisel on Siret Tuula, e-post [email protected] või tema

asendaja.

3.3. Täitja kontaktisikuks lepingu täitmisel on Tõnis Tobre, tel 53439003, e-post

[email protected] või tema asendaja.

4. Lõppsätted

4.1. Leping jõustub sellele poolte poolt allakirjutamise hetkest ja kehtib kuni poolte poolt oma

lepinguliste kohustuste täitmiseni.

4.2. Lepingu dokumendid koosnevad riigihanke alusdokumentidest, sh lepingu lisadest, lepingu

muudatustest ja pakkumusest.

4.3. Lepingu lahutamatuteks osadeks lepingu sõlmimise hetkel on järgmised dokumendid, mida

ei allkirjastata koos lepinguga:

4.3.1. Lisa 1 - Tehniline kirjeldus;

4.3.2. Lisa 2 – Pakkumus.

5. Poolte allkirjad

Tellija: Täitja:

1

Lisa 1 - Tehniline kirjeldus

TEHIK stiilijuhise haldus

1. Taust

1.1. Tervise- ja heaolu infosüsteemide Keskus (edaspidi TEHIK) kasutab teenuste disainimisel

stiilijuhist. Stiilijuhis koosneb kolmest osast: React komponentide library aka storybook,

Figma disainifailid ja GIT koodivaramu.

1.2. Stiilijuhist kasutavad praegu sotsiaal-, tervise- ja töövaldkond ning eesmärk on võtta see

TEHIKus kasutusele kõikide teenuste arendamisel ja disainimisel.

1.3. Stiilijuhise üldine haldus ei ole praegu keskselt korraldatud, kuid teenuste lisandudes on

vajadus sellele kasvanud.

1.4. Täitja ülesandeks ongi stiilijuhise keskne haldus ning sellega seotud kasutajaliideste disaini-

ja arendustööd ja majasisene konsultatsioon.

2. Eesmärk

2.1. Eesmärk on luua üle TEHIKu toimiv stiilijuhise haldus, nii et kõik stiilijuhise osad oleks

ajakohastatud ja sünkroniseeritud ning projektimeeskonnad saaksid kõikides stiilijuhist

puudutavates küsimustes asjatundlikku nõustamist ja abi.

2.2. Täitja ülesanne on lisaks pakkuda konsultatsioone stiilijuhise haldusprotsessi lõpliku

versiooni väljatöötamiseks. Alljärgnevalt on lisatud haldusprotsessi joonise tööversioon

aktiivses arenduse faasis, mille kirjeldus tehnilise kirjelduse lisas 1.

3. Tööde teostamine

3.1. Töötundide arvestust peetakse TEHIKu Confluence keskkonnas ning tööde eest tasumine

toimub igakuiselt, esitatud akti alusel.

4. Tööde tulemid

4.1. Lepingu lõpuks peab olema valminud stiilijuhise haldusprotsessi lõplik versioon ning kõik

stiilijuhise osad peavad olema ajakohastatud ja omavahel sünkroniseeritud.

STIILIJUHISE PROTSESSIKIRJELDUS

Mõisted

Figma – disainilahenduste loomise platvorm

Projektimeeskond – teenuse/projekti arendamisega seotud TEHIKu meeskond

RIA stiilijuhis – ehk VEERA stiilijuhis. VEERA 1.0 arendusprotsessi käigus võib nimi muutuda, seega

käesolevas protsessikirjelduses on sellele viidatud kui RIA stiilijuhisele.

RIA stiilijuhise haldusmeeskond (RIHAL) – meeskond RIA-s, kes vastutavad üleriigilise RIA

stiilijuhise haldamise ja populariseerimise eest.

TEHIK stiilijuhis – Edasiarendus VEERA beta versiooni stiilijuhisest, mida TEHIKus teenuste

disainimisel järgitakse ja kasutatakse.

TEHIK stiilijuhise haldusmeeskond (TEHAL) – arenduspartner, kellega TEHIK on sõlminud lepingu

TEHIKu stiilijuhise haldamiseks.

Üldised põhimõtted

1. Taaskasutame nii paljusid komponente kui võimalik. TEHIK stiilijuhise kasutamise soovitus

kõigile, kes kasutavad Reacti;

2. Lähtume nii palju kui võimalik RIA stiilijuhisest (VEERA);

3. Loodavad komponendid peavad olema üldisemad, mitte suunatud ühele spetsiifilisele

probleemile või projektile;

4. Storybook, Figma ja GIT peavad olema omavahel sünkroniseeritud;

5. RIHAL annab TEHAL-ile pidevalt infot RIA stiilijuhise suunistest ning selle nõuete

muutumise kohta;

6. Stiilijuhise ametlikuks suhtluskanaliks on Slack.

Projektimeeskonna kasutajateekond

1. Uue teenuse arendustellimus, kasutajateekonna kirjeldus

Arendustellimus peab sisaldama nõuet TEHIK stiilijuhise rakendamiseks. Nõue kohustab

maksimaalselt TEHIK stiilijuhise rakendamist teenuse disainimisel. TEHIK stiilijuhis peab

omakorda arvestama võimaluste piires RIA stiilijuhisest lähtuvate soovitustega.

Projektimeeskond on kohustatud sellest eeldusest lähtuma ka kasutajateekonna

kirjeldamisel.

Arendustellimuses tuleb välja tuua, et arenduspartnet kasutaks disainilahenduse

loomisel Figma platvormi või põhjendatud vajadusel muud platvormi, mis võimaldab

hiljem loodud disainilahenduse elemendid Figma platvormile üle tuua nii, et vajalik

funktsionaalsus säiliks.

2. Disainivajaduste valideerimine vastu olemasolevat stiilijuhendit ja prototüübi loomine ning

valideerimine

Kasutajateekonna kirjeldamisel tekkinud disainivajadused peab projektimeeskond

kooskõlastama TEHAL-iga;

Kui olemasolev stiilijuhend katab vajadused, siis teeb projektimeeskond koostöös

arenduspartneriga prototüübi või täiendab seda;

Prototüüp valideeritakse TEHAL-iga. Kui prototüüp vajab täiendusi, mida olemasolev

stiilijuhend ei kata, kaardistatakse muudatuste vajadus koostöös TEHAL-iga ning

lepitakse kokku muudatuste teostaja;

Teenuse aktiivses arendusfaasis on muudatuste teostaja alati projektimeeskond. Pärast

aktiivset arendusfaasi võib teostaja olla ka TEHAL;

Komponentide loomise etappi liigutakse edasi alles siis, kui prototüüp on saanud

TEHAL-i heakskiidu.

3. Komponentide loomine

Kui olemasolevad raamistiku komponendid katavad vajadused, siis on

projektimeeskonnal võimalik liikuda koheselt edasi arendusse;

Kui arenduse tulemuste valideerimisel on selgunud täiendavad vajadused, pöördutakse

tagasi kõigepealt raamistiku olemasolevate komponentide võimaluste juurde ning alles

seejärel komponentide täiendavate arenduste juurde;

Täiendavate komponentide loomine ja ka olemasolevate komponentide täiendamine

tuleb valideerida TEHAL-iga, et muudatused vastaksid RIHAL-i ootustele ja kajastuksid

ka Figmas. Disainimuudatuste tegemine vaata punkt 2;

Teenuse aktiivses arendusfaasis on uue komponendi loomine või olemasoleva

komponendi täiendamine alati projektimeeskonna ülesanne. Pärast aktiivset

arendusfaasi on teostaja samuti projektimeeskond. Välja arvatud juhul, kui komponendi

muudatuse vajadus tuleneb otseselt RIA stiilijuhise nõuetest või TEHIK stiilijuhise

täiendamise/parendamise eesmärgil, mitte teenuse/projekti vajadustest. Seejuures on

projektimeeskonnal alati õigus TEHAL-ilt igakülgset abi ja nõustamist saada, et tagada

stiilijuhise komponentide ühtlane kvaliteet.

4. Projekti/teenuse haldusfaas

Projektimeeskond kohustub TEHAL-i soovitusel läbi viima vajalikud versiooniuuendused

teenuse komponentidele.

TEHIK stiilijuhise haldusmeeskonna (TEHAL)

kasutajateekond

1. Protsessiülesed ülesanded

TEHAL vastutab TEHIK stiilijuhise Figma, storybook’i ja GIT-i vastavuse ning

sünkroonsuse eest;

Haldab suhtluskanalit Slack. Nõustab ja abistab komponentidega seotud muredega

pöördunud kasutajaid;

Korraldab korralisi koosolekuid, et projektitiimid oleksid komponentide uuendustega

kursis;

TEHAL seab eesmärke stiilijuhise jätkusuutlikkuse osas ning koostab vastavalt

tegevusplaani.

2. Disainivajaduste valideerimine vastu olemasolevat stiilijuhendit ja prototüübi valideerimine

TEHAL tagab võimaluste piires TEHIK stiilijuhise vastavuse RIA stiilijuhisele ja WCAG

reeglitele;

Kasutajateekonna kirjeldamisel tekkinud disainivajaduste kooskõlastamine

projektimeeskonnaga (sh osalemine projektitiimi koosolekutel vajaduspõhiselt);

Teenuse disaini prototüüp valideerimine. Kui prototüüp vajab täiendusi, mida

olemasolev stiilijuhend ei kata, kaardistatakse muudatuste vajadus koostöös

projektimeeskonnaga ning lepitakse kokku muudatuste teostaja;

Teenuse aktiivses arendusfaasis on muudatuste teostaja alati projektimeeskond.

Pärast aktiivset arendusfaasi võib teostaja olla ka TEHAL;

TEHAL peab valideerima kõik disainijuhise täiendamisel tehtavad muudatused

vastavalt RIA stiilijuhise nõuetele;

TEHAL valideerib prototüübi enne komponentide loomise etappi liikumist.

3. Komponentide loomine

TEHAL nõustab projektimeeskonda olemasolevate komponentide kasutamise osas

vastavalt RIA stiilijuhise nõuetele (sh osalemine projektitiimi koosolekutel

vajaduspõhiselt);

Täiendavate komponentide loomise ja olemasolevate komponentide muutmise

valideerimine vastavalt RIA stiilijuhise nõuetele (sh testimine, uute funktsionaalsuste

analüüs, code-review);

TEHAL teostab komponentide muudatusi, mille vajadus tuleneb otseselt kas RIA

stiilijuhise nõuetest või TEHIK stiilijuhise täiendamise/parendamise eesmärgil (sh

bugide lahendamine), mitte teenuse/projekti vajadustest;

TEHAL peab tagama kvaliteetse versioonihalduse. Täpsemad ootused

versioonihaldusele versioonihalduse peatükis. punktis...

4. Projekti/teenuse haldusfaas

TEHAL teavitab projektimeeskondi neid puudutavatest versiooniuuendustest ning

jälgima uute versioonide rakendamist. Vajadusel nõustab projektimeeskonda.

Versioonihaldus

1. Iga komponendiuuendusega peab komponent saama selge versioonimärgise.

2. Vanemad versioonid peavad jäämad kättesaadavaks .....

3. Versioneerime komponenti ennast (mitte package't). Nii säilib versiooniuuenduste

rakendamisel paindlikkus.

4. Projektitiimid peavad aktiivses arendusfaasis olevale teenusele viima versiooniuuendustest

tulenevad muudatused sisse esimesel võimalusel, kuid mitte harvem kui kord kuus.

5. Projektitiimid peavad haldusfaasis olevale teenusele viima versiooniuuendustest tulenevad

muudatused sisse esimesel võimalusel, kui mitte harvem kui.....