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:
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.
1
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.....