Pöördumine

Hankeleping nr...
Toetuste ja üldkomponentide II etapi arendused

Tervise ja Heaolu Infosüsteemide Keskus, registrikood 70009770, aadress Pärnu mnt 132, 11317 Tallinn, keda esindab põhimääruse alusel direktor Margus Arm (edaspidi tellija), ja

_____, registrikood_______., aadress ________, keda esindab põhikirja alusel _____ (edaspidi täitja), edaspidi eraldi pool või koos pooled, sõlmisid raamlepingu nr 3-9/3681-1 alusel käesoleva hankelepingu (edaspidi leping) alljärgnevas:
1. Lepingu ese
1.1. Lepingu esemeks on riigihanke "Toetuste ja üldkomponentide II etapi arendused" alusdokumentides olevas tehnilises kirjelduses nimetatud tööd (edaspidi tööd);
1.2. Lepingu maht on maksimaalselt 491 803,30 eurot km-ta, 10 kuu jooksul arvates lepingu sõlmimisest, oleneb kumb asjaolu saabub varem;
1.3. Lepingut rahastatakse välisvahenditest, SOMi TAT eelarvest (Sotsiaalministeeriumi Toetuse andmise tingimused rakendusasutuse tegevusteks). Täitjale tehakse välisrahastuse projekti(de)st tulenevad nõuded teatavaks tööde teostamisel.
2. Töö üleandmise ja vastuvõtmise tingimused
2.1. Vajalik funktsionaalsus peab olema toodanguvalmis hiljemalt 10 kuud pärast lepingu sõlmimist, kuid pooled võivad objektiivsete takistuste ilmnemisel ajaraami pikendada kuni 12 kuuni kirjalikku taasesitamist võimaldavas vormis kokkuleppel;
2.2. Täitja annab töö üle tellimuses määratud tähtajal lepingu kehtivuse jooksul;
2.3. 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.4. Võimalike tekkivate lisatööde sisu ja tähtaeg lepitakse poolte vahel kokku kirjalikku taasesitamist võimaldavas vormis;
2.5. Tellitavad tööd antakse vastuvõtutestimiseks üle üleandmise ja vastuvõtmise aktiga (edaspidi akt) vastavalt lepingu tehnilises kirjelduses kokkulepitud tingimustele;
2.6. Tellija vaatab töö üle vastavalt raamlepingu tingimustele, kui lisas 1 ei ole kokku lepitud eritingimusi;
2.7. 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 ....... (maksumus sõnadega) eurot käibemaksuta;
3.3. Täitja esitab tellijale e-arve igakuiselt. E-arvel tuleb märkida lepinguosa viitenumber __.
4. Poolte vahelised teated ja kontaktisikud
4.1. Teadete edastamisel ja kätte toimetamisel lähtutakse raamlepingu regulatsioonist;
4.2. Tellija kontaktisikuks lepingu täitmisel on Priit Parro, tel 7943 943, e-post [email protected] või tema asendaja;
4.3. Täitja kontaktisikuks lepingu täitmisel on ..., tel ..., e-post .... või tema asendaja.
5. Lõppsätted
5.1. Leping jõustub sellele poolte poolt allakirjutamise hetkest ja kehtib kuni poolte poolt oma lepinguliste kohustuste täitmiseni;
5.2. Lepingu dokumendid koosnevad riigihanke alusdokumentidest, sh lepingu lisadest, lepingu muudatustest ja pakkumusest;
5.3. Lepingu lahutamatuteks osadeks lepingu sõlmimise hetkel on järgmised dokumendid, mida ei allkirjastata koos lepinguga:
5.3.1. Lisa 1 - Tehniline kirjeldus;
5.3.2. Lisa 2 – Pakkumus.
6. Poolte allkirjad

Tellija:


Täitja:

Pakkumuskutse lisad
Lisa 1
Meeskonnavorm
Pakkuja esitab iga tööde teostamisel kasutatava meeskonna nimekirja ning juhul, kui isiku CV-d ei ole hankijale varem edastatud, edastab ka selle raamlepingu sõlmimiseks läbiviidud riigihankes märgitud vormil:
Jrk
Roll
Isiku nimi
1.       


2.      


3.      



Lisa 2
Maksumusvorm

Ühe töötunni hind hankelepingu perioodil. Ei tohi olla kõrgem raamlepingus esitatud maksumusest.
Hind käibemaksuta


Hind käibemaksuga

Tehniline kirjeldus - Toetuste ja üldkomponentide II etapi arendused
Lisa 1 - Tehniline kirjeldus
1. Töö sisu ja saavutatav tulem
1.1. Sotsiaaltoetuste ja -teenuste andmeregistri (STAR1 ja STAR2) toetuste ja seotud üldkomponentide arendamine ja analüüs, vigade tuvastamine, parandamine, testimine ning tarkvara tarnimine tellija keskkonda;
1.2. Saavutatavad tulemid: Sotsiaaltoetuste ja -teenuste andmeregistri (STAR1 ja STAR2) toetuste ja seotud üldkomponentide analüüs, arendus- ja muud seotud tööd ning vigade tuvastamine ja parandamine;
1.3. Saavutatud kokkulepped: toetuste ja seotud üldkomponentide arendus ja analüüsitööde täpsustatud projektiplaan ning skoop lepitakse kolme osapoole (täitja, TEHIK ja SKA) vahel kokku pärast arendaja poolt teostatud eelanalüüsi viivitamatult. Kokkulepitud projektiplaan saab aluseks tööde teostamisele. Projektiplaanis on välja toodud etapid. Viimaste sisu ja tähtajad lepitakse poolte vahel kokku lepingu täitmisel. Projektiplaan ja skoop võib ühiste eesmärkide täitmise nimel SKA ja TEHIK’u kirjalikul tellimusel ajas muutuda, kuid muudatuseni on see pooltele siduv dokument, millest tuleb tööde teostamisel kinni pidada kuni lepingu lõpuni või muudatuse tegemiseni. Tegemis on RHS § 123 lg 1 p 2 muudatustega.
2. Projekti eesmärk
2.1. Projekti II etapi eesmärk on teostada analüüs ja luua võimekus toetuste menetlemiseks STAR2-s. Kuna toetused, mida tuntakse ka lihttoetustena (universaaltoetustena), defineeritakse üle Eestiliselt erinevalt, luuakse tingimused selleks, et iga kohalik omavalitsus saaks seadistada ja menetleda toetusi infosüsteemi vahendusel vastavalt kehtestatud korrale ja tingimustele.
3. Projekti tulemid
3.1. II etapi raames võetakse fookusesse valitud toetuste üle toomine uuele platvormile.
3.2. II etapi tulemusena on loodud võimekus:
3.2.1. toetuste haldamiseks;
3.2.2. toetuste menetlemiseks ja haldusotsuste koostamiseks vajaliku täiendava lisafunktsonaalsuse loomine;
3.2.3. toetuste väljamaksete ja aruandluse lahenduse täiendamine;
3.2.4. kõik muud olulised lisa funktsionaalsused kasutusmugava lahenduse väljatöötamiseks;
3.2.5. Antud projekti raames teostatakse ka STARi üldkomponentidega seotud vajalikud tööd.
4. Tööprotsess
4.1. Järgnevalt täpsustatakse raamlepingus kirjeldatud tingimusi tööprotsessi, dokumenteerimise, töökorralduse, testimise ja mittefunktsionaalsete nõuete osas.
4.2. Töökorraldus
4.2.1. Projekti töökorraldus toetub kodukorrale;
4.2.2. Täpsem tööprotsess lepitakse poolte vahel kokku lepingu täitmisel;
4.2.3. Tellija ei ole kohustatud vastu võtma tehtud arendustööde tarneid, kui arendustööl puuduvad automaattestid;
4.2.4. Arendustööd kaetakse tellija arhitektiga kokku lepitud ulatuses feature flag’dega.
4.3. Tööde üleandmine
4.3.1. Arendustööde lähtekoodi tarne toimub pideva integreerimise (continuous integration) teel;
4.3.2. Tööde järjekord, tarneprotsess, üleandmise aeg ja UAT tagasiside andmise aeg lepitakse kokku tööde käigus taasesitamist võimaldavas vormis (Tellija ja Täitja poolt);
4.3.3. Tellija korraldab tulemite üleandmise järel vajalikud lähtekoodi paigaldused keskkondadesse;
4.3.4. Täitja viib läbi testkeskkonnas suitsutesti;
4.3.5. Tellija viib läbi vastuvõtutestimise (Acceptance Test, User Acceptance Test);
4.3.6. Täitja teab, et tellija võib igat üle antud funktsionaalsust paigaldada toodangusse ning täitja peab tagama, et lõplikult valmimata funktsiooni protsessid on võimalik toodangust välja lülitada (feature flags). Funktsioonide sisse-välja lülitamise võimekus lepitakse Tellija ja Täitja vahel kokku tööde käigus.
4.4. Dokumentatsioon
4.4.1. Vastavalt alapunktis 4 kirjeldatud arendustööde skoobile tuleb töö käigus luua ja täiendada STARi dokumentatsiooni, milleks on minimaalselt:
4.4.1.1. Funktsionaalsuse ja äriprotsesside kirjeldused kokkulepitud kujul (nt BPMN standard, diagrammid ja kirjeldused Confluence’is) koos ärireeglitega, mida peab olema hiljem võimalik täiendada järgnevates etappides lisanduva funktsionaalsuse alusel ning siduda tervikliku protsessi- ja ärireeglite kirjeldusega;
4.4.1.2. Tehniline dokumentatsioon (nt paigaldusjuhendid Confluence keskkonnas);
4.4.1.3. Andmemudel;
4.4.1.4. Kasutusjuhend;
4.4.2. Dokumentatsiooni täpsed liigid ja sisu formaat lepitakse kokku tööde tellimise käigus.
4.5. Nõuded automaattestimisele
4.5.1. Loodav lähtekood peab olema kaetud 75% ulatuses ühiktestidega, 50% ulatuses integratsiooni/liideste/süsteemi/”end-to-end” automatiseeritud testidega;
4.5.2. Unit testid käivitatakse enne koodi kokku ehitamist;
4.5.3. Unit testid on üks osa üleantavast koodist;
4.5.4. Testidega kaetakse serveripoolne ja kasutajaliidese kood, kui arendaja ei lepi TEHIKu arhitektiga kokku teisiti;
4.5.5. Funktsionalsed automaattestide tegemine lepitakse Tellija Täitja poolt kokku tööde käigus;
4.5.6. Tellija ja täitja peavad koostöös panema arenduskeskkonnas olevad automaattestid (API testid) tööle ka vähemalt testkeskkonnas või kui on kokkulepitud, siis ka teistes olemasolevates keskkondades;
4.5.7. Automatiseeritud testiliikide haldamisega ja ajakohasena hoidmisega tegeleb arendaja;
4.5.8. Automaattestide raporteerimiseks seatakse TEHIKu koodihoidla keskkonnas (Gitlab) üles pideva integratsiooni töövoog, mis seadistatakse SonarQube koodi ja testide kaetuse analüsaatoriga koos toimima;
4.5.9. SonarQube's kontrollitavate vigade ja haavatavuse taseme kontroll peab olema edukalt läbitud;
4.5.10. Kõik testide automatiseerimise tööriistad/raamistikud peavad oskama töötada GitLab PipeLine's ja Docker Container's;
4.5.11. Liideste testimisel tuleb lisaks positiivsele töövoole katta ka negatiivseid töövooge;
4.5.12. Liideste testide lähtekood peab olema kättesaadav GitLabis;
4.5.13. Automaattestid peavad üle antavas lähtekoodis pideva integratsiooni töövoo edukalt läbima;
4.5.14. Arendaja peab hoolt kandma, et varasemalt loodud testid jäävad töö lõpetamisel edukalt läbitavaks;
4.5.15. Nõuete muutumisel peab arendaja viima testid vastavusse uute nõuetega või neid eemaldama, kui selliseid nõudeid enam ei eksisteeri;
4.5.16. Mõistlik ulatus kasutajaliidese testimisest peab olema automatiseeritud ja korduvkasutatav tööde käigus kokkulepitud raamistikul;
4.5.17. Automaattestimise (API test) artefaktidena luuakse:
4.5.17.1. Paigaldusjuhend automaattestide integreerimiseks testkeskkonda ja teistesse kokkulepitud keskkondadesse;
4.5.17.2. Kasutusjuhend automaattestide käivitamiseks.
4.6. Koormustestimised
4.6.1. Rakendus peab toetama paralleelselt 500 päringut (siinkohal on oodatav arendajapoolne hinnang, kas see on piisav päringute maht, vajadusel tõsta arvu);
4.6.2. API teenustele ning keskmine päringu teenindamise aeg ei tohi olla suurem kui 3 sekundit (peab hindama API päringu keerukust). Projekti käigus täpsustatakse vastamiseajad;
4.6.3. Nõude täitmise kontrolliks tuleb luua koormustestid. Koormustestid peavad olema juhitavad muutujatega ehk seadistatavad. Koormustestide tegemine lepitakse tellija ja täitja poolt kokku tööde käigus.
4.7. Mittefunktsionaalsed nõuded
4.7.1. Mittefunktsionaalsete nõuete täitmisel tuleb lähtuda järgnevast:
4.7.1.1. Uue funktsionaalsuse loomisel tuleb lähtuda raamlepingus ja selle lisades kirjeldatud nõuetest;
4.7.1.2. Täpsemad mittefunktsionaalsed nõuded, millest lähtuda, asuvad Confluence keskkonnas: https://tehik.ee/arendusjuhendid ja https://wiki.sm.ee/pages/viewpage.action?pageId=42184818;
4.7.1.3. Põhjendatud juhtudel võib seatud nõuetest kõrvale kalduda taasesitamist võimaldavas vormis sõlmitud kokkuleppel tellijaga.