Leping

Lisa 1 - Tehniline kirjeldus Andmela dude ja analüütika arendus- ja hooldustööd e arendusressurss Mõisted ja lühendid See peatükk loob ülevaate käesolevas hankedokumentatsioonis ja tööde käigus enim kasutusel olevatest mõistetest ja lühenditest ning selgitab nende tähendused . T EHIK Tervise ja Heaolu Infosüsteemide K eskus ALV Analüütika Lahenduste Valdkond Andmeladu / Andmeait Andmeladu on struktureeritud kogum integreeritud, kindlale teemale suunatud, püsiva loomuga ja ajast sõltuvaid andmeid, mille ülesandeks on toetada otsuste tegemist. ODS kiht Andme laos olev k i ht ( schema , dbspace või muu andmelao platvormist tulenev objekt ), kuhu kantakse alliksüsteemist andmed sellisel kujul nagu need alliksüsteemis on. EDW kiht Andme laos olev k i ht ( schema , dbspace või muu andmelao platvormist tulenev objekt ) , mis luuakse vajadusel integratsiooni, andmemudeldamise ja transformatsiooni jaoks. DWH kiht Andme laos olev presentats i ooni kiht ( schema , dbspace või muu andmelao platvormist tulenev objekt) kuhu luuakse analüütikute töö aluseks olevad tabelid inimkeelsete nimedega ja arusaadavate seostega. Andmed võetakse ODS kihist või EDW kihist (vastavalt alusandmestikele) ja viiakse optimaalsele kujule aruannete kokkupaneku lihtsustamiseks ja päringute kiiruste optimeerimiseks . Analüütikakeskkond / analüütikarakendus Analüütikakeskkond on presentatsiooni kihil töötav visuaalsete aruannete loomise rakendus , mis toetab äriliste otsuste tegemist ning mille sisendiks on andmelaos ja muudes andmeallikates olevad andmed. Andmete esitlus on visuaalne ja/või masinloetav. Tarkvara Tarkvara tähistab baastarkvara või tarkvaraplatvormi (näiteks Pentaho , Apache Hop , Vertica , Tableau jms andmeladudega seotud tarkvara). Töödekuhi Töödekuhi ehk backlog on tööde / vigade halduskeskkonnas olev nimekiri töökäskudest. Tööde / Vigade halduskeskkond Tööde ja vigade halduskeskkond on tellija keskkonnas asuv rakendus vigade ja arenduste haldamiseks kasutusel olev programm (nt. Jira). Dokumentide halduskeskkond Dokumentide halduskeskkond on tellija keskkonnas asuv rakendus dokumentide ja informatsiooni (nt. spetsifikatsioonid, juhendid, koosolekute memod) haldamiseks kasutusel olev programm (nt. Confluence ). Reageerimisaeg Reageerimisaeg on aeg, mis on täitjal tellija päringule vastamiseks. Teenindusaeg / tööaeg Teenindusaeg ehk tööaeg on vastavalt arendustööde tingimustele SLA (arendustööde tingimused / rakenduste teenustasemed) tabelis sätestatud teenindusaegadele. Muu aeg on tööväline aeg. Lahendusaeg Lahendusaeg tähendab perioodi tellimuse saamisest kuni tööde valmimiseni, mille jooksul täitja on kohustatud teostama kõik tööd (sh. arendustöö, jooksva arendustöö, veaparanduse ning täitma garantiist tulevad kohustused) vastavalt lahendusaja tabelile ja SLA (arendustööde tingimused / rakenduste teenustasemed) tabelile. Tarne Tarne on hankelepingu alusel teostatud tööde paketina üleandmine, mis on toodangusse paigaldamiseks korrektselt konfigureeritud ja koodihalduskeskkonda lisatud. Täitja lisab tarne kirjelduse ja spetsifikatsiooni dokumendihalduskeskkonda. Täitja esitab tarne kohta tarneteatise, lisades tarnega seotud testimise juhendi ja vastavalt hankelepingule automaattestid. Tarneteatise vormi kehtestab tellija hankelepingu täitmise käigus. Paigalduslogi Paigalduslogi on informatsioon rakenduste igasuguste muudatuste (nt. tarnete paigaldamise) kohta kirjalikku taas-esitamist võimaldavas vormis. RL Raamleping TK Tehniline kirjeldus Üldine Hanke eesmärk on sõlmida hankeleping ühe pakkujaga, ke s võimaldab oma ressurssi rakendada TEHIK-u Analüütika Lahenduste Valdkonna (ALV) meeskonna poolt teostatavateks töödeks. Pakkuja hakkab teostama TEHIK-u andmelaoplatvormil paiknevate andmeladude ja nendega seotud rakenduste ja tööriistade (sh analüütikakeskkonda de ) arendus- ja hooldustöid , mis laiendaksid rakenduse funktsionaalsust ning tagaksid turvalisuse, tehnilise optimeerituse , töökindluse ja edasise haldus- ning edasiarendussuutlikkuse . Edukaks tunnistatud pakkujaga sõlmitakse hankeleping. Tööde skoop sisaldab nii jooksvaid arendustöid (sõltuvalt vajadusest), analüüsi, dokumenteerimist (sh. olemasoleva dokumentatsiooni täiendamist ja/või uue dokumentatsiooni loomist) kui konsultatsiooni. Lisaks on tööde skoobis ka hooldustööd, mida teostatakse jooksvalt vastavalt vajadusele, kui neid peaks tarvis minema. Kõik käesolevas tehnilises kirjelduses (TK) punktis 5.1 nimetatud tööd. Hanke eseme tutvustus Hanke esemeks on TEHIK-u andmelaoplatvormi de l ( SAP Sybase IQ ja Vertica ) paiknevad andmelaod ja skeemid ning nendega seotud rakenduste ja tööriistade (nt laadimisrakendused, analüütikarakendused , jne ) arendus- ja hooldustööd. Arhitektuurijoonis: ( Joonis kirjeldab andmete arhitektuuri läbi terviseandmete ökosüsteemi näite ) Põhilised märksõnad kasutusel olevate tehnoloogiate ja teekide osas on SAP Sybase IQ , Vertica ; DBT; CI/CD; Apache Hop ; Pentaho ; Python ; Tableau ; Oracle ; Postgre ; SAP HANA; MS SQL; SQL server. A ndmelaoplatvormi de l olevate andmeskeemide toimimiseks on vaja, et süsteemile oleks tugi. Tegeleda tuleb jooksvate vajaduspõhiste arendustöödega. Vaja on partnerit, kes teostab rakenduste arendustööd ning tagab jooksvate arendustöödega nende toimimise, et rakendused ei oleks ilma toeta. Potentsiaalsed tööd arendusressursile hõlmavad järgnevaid täna teadaolevaid andmelao skeeme , mida teostab TEHIK-u ALV oma ressurssiga , kuid lisaks ka veel realiseerimata uusi skeeme , mis aja jooksul lisanduda võivad: TEIS ja ITI (Tööinspektsiooni infosüsteem) Jira (Jira andmeladu) MEDRE (Tervisehoiukorralduse infosüsteem) MEIS (Terviseameti menetlussüsteem) MTK (Mürgitusteabekeskus) NAKIS (Nakkushaiguste infosüsteem) RA Hulgimüüjate laosesisud , RAR (Ravimiregister) ja RKAB ( Ravimiameti tegevuslubade register ) TUTE ( Tubakateavituse infosüsteem) VSR (Vähi sõeluuringute register) TIS (Tervise Infosüsteem) POHAK (Patsiendiohutuse andmekogu) TAI statistika andmete skeem KTI (Keskkonnatervise infosüsteem) Log (Logi skeem) (...) Eelnevalt kirjeldatule lisanduvad vajadusel ka muud TEHIK ALV arendusprojektid . Teadaolevad skeemid, milleks on kavas või kavandamisel eraldi töölepingud ja mis tänase parima teadmise kohaselt suure tõenäosusega töö skoopi ei kuulu: SKAIS (Sotsiaalkindlustusameti infosüsteemid ) STAR (Sotsiaalkindlustusameti infosüsteem) STEEL (Tervisekassa andmeladu) EESSI (Sotsiaalkindlustusandmete vahetamise infosüsteem) (...) Töö tehnilised nõuded Rakenduste tehniline kirjeldus ja nõuded on dokumenteeritud käesolevas dokumendis ja selle lisades. Tööd teostatakse arvestades tellija poolt esitatud dokumenteerimise nõudeid „TEHIK nõuded infosüsteemi dokumentatsioonile“ ja täiendavaid materjale asukohaga https://www.tehik.ee/arendusjuhendid (vt. ka „ Tööde piirangud “). Tööde teostamine Tööde ks on arendus- ja veaparandus/hooldustööd , mille hulka kuuluvad raamlepingus käsitletud tehnoloogiad ja tööd: analüüsitööd; arhitektuuritööd; arendusressurss ( Bodylease ); programmeerimistööd; testimistööd (end- to -end automaatestimine); juurutustööd; koolitused; konsultatsioon; dokumentatsiooni koostamine; jooksvate muudatusvajaduste realiseerimine; veaparandustööd; hooldustööd; Dev-ops CI/CD. Täitja teostab tööd ühes (1) etapis: I etapp: A rendus-ja hooldustööd. Tavapärasteks tööülesanneteks on seotud keskkondades tekkivate veaolukordade analüüsimine ja parandamine ning arendusvajaduste realiseerimine nt uute laadimiste loomine ja olemasolevate laadimiste muutmine ja konfigureerimine sh ka võimalikud migratsioonid erinevate süsteemide vahel, mille eesmärgiks on äritellija analüütika /aruandluse vajaduste rahuldamine. I etapi tööde tulemiks on: Väikearendus- ja hooldustööd, mis tagaksid turvalisuse, tehnilise optimeerituse , töökindluse ja edasise haldus- ning edasiarendussuutlikkuse. Tööde teostamisel peab arvestama, et: Tööd teostatakse vastavalt TEHIKu arenduskeskkondade tehnilistele nõuetele ja arendusjuhenditele. Kõik loodud töövood, konfiguratsioonid, mudelid ja muud arenduse tulemid peavad olema dokumenteeritud. Andmelao kihid (ODS, EDW, DWH) peavad säilitama struktuurse ja semantilise järjepidevuse. Uute andmeallikate liidestamisel tuleb arvestada võimalikku andmekvaliteedi varieeruvust ning tagada ühtsed laadimis- ja transformatsioonipõhimõtted. Hanke skoopi ei kuulu eraldiseisvad Java põhised rakendused nagu VERX ja Pseudonüümija . Kui SAP Sybase IQ on legacy platvorm, siis Vertica platvormile tekib konkreetseid ladusid ja andmeskeeme aja jooksul juurde ja nendega seonduvad arendusvajadused kuuluvad sellisel juhul käesoleva hankelepingu tööde skoopi. Mõningatele andmeladudele võidakse sõlmida, või on varasemalt olemas, eraldi hankelepingud, mille alt arendus- ja hooldustöid teostatakse ning sellisel puhul ei pruugi kõik antud platvormiga seotud arendusvajadused olla lahendatavad käesoleva hankelepingu tööde raames. Kõik loodud töövood, konfiguratsioonid, mudelid ja muud arenduse tulemid peavad olema dokumenteeritud. Konkreetsed funktsionaalsed nõuded täpsustatakse arendustööde käigus loodavates piletites. Tellija tagab tööde teostamiseks ligipääsu vajalikele keskkondadele ja vajadusel omapoolse abi. Ligipääsu tehnilised tingimused jms täpsustatakse tööde teostamise käigus. Hankelepingu täitmise tulemina peab pakkuja andma tellijale üle: Tööde jooksul tekkivate tellimuste alusel teostatud tööd vastavalt tellimuses, käesolevas tehnilises kirjelduses ja selle lisades toodud skoobile. Teostatud tööde dokumentatsioon (sh kasutusjuhend). Meeskond Käesolevaks tööks peab pakkuja esitama meeskonna, mis koosneb minimaalselt järgnevatest rollidest: Projektijuht Analüütik Arhitekt/vanemarendaja Arendaja Kõik raamlepingus esitatud meeskonnaliikmed tuleb esitada hankega kaasas oleva meeskonna vormil või uue meeskonnaliikme lisamise korral lisaks ka raamlepingu (RL) meeskonna vormil. Uue meeskonnaliikme lisamiseks tuleb täita RL meeskonna vormis plokis 2 individuaalse kogemuse andmed: " 2. Individuaalsed nõuded kogu pakkuja meeskonnale (nõuded tuleb täita iga esitatud meeskonna liikme poolt individuaalselt) " Uus meeskonnaliige peab omama vähemalt ühte kompetentsi/kogemust ühiste nõuete plokist ja see tuleb tõendada RL meeskonna vormis vastavas plokis andmed täites: " 3. Ühised nõuded kogu pakkuja meeskonnale (nõuded tuleb täita esitatud meeskonna peale kokku) ". Pakkuja peab esitama lepingu sõlmimiseks isikuliselt vähemalt 4 meeskonnaliiget eelnevalt defineeritud rollidesse. Rolle ei ole lubatud katta (st sama isik, ei tohi olla esitatud mitmes erinevas rollis). Samasse rolli (näiteks mitme arendaja puhul) ei saa määrata sama isikut. Hankelepingu kehtivuse perioodil võib vastavalt vajadusele tellijaga eelnevalt kooskõlastades RL punkt 5.2 alusel meeskonda uusi täiendavaid nõuetele vastavaid liikmeid juurde lisada käesolevas tehnilises kirjelduses punktis 5.8 kirjeldatud viisil. Pakkuja peab tagama, et pakutud meeskonna koosseis on tööde teostamiseks tellija jaoks kogu hanke perioodil täis töömahus olemas. Hankijal ei ole kohustust tagada täismahus kõigi meeskonnaliikmete hõivatust, kuid pakkujal peab olema valmidus pakkuda eelpool kirjeldatud mahus meeskonda kogu hanke perioodil tellitavate tööde teostamiseks. Mahud ja ajakava Tööde teostamise ajad (etappide korral ka etapid) ja lepingute kehtivusajad on sätestatud hankelepingus. Täitja teostab tööd vastavalt hankelepingus toodud tähtaegadele. Kui etappidele pole lepingu kehtivuse kuupäevadega seatud omavahelist järjestikust sõltuvust, siis võivad etapid ka osaliselt või täielikult kattuda ning toimuda paralleelselt. Projekti eelduslik töömaht kokku on ~ 2300 tundi. Projekti eelduslikud töömahud rollide lõikes: Projektijuht: ca 100 h. Analüütik: ca 10 0 h. Arhitekt/vanemarendaja: ca 10 0 h . A rendaja : ca 2 0 00 h. Võtmeroll on arendajal/ arendaj atel, kes töötavad koostöös tellija tiimiga; teisi rolle kaasatakse vastavalt vajadusele. Projekti eelduslikud töömahud etappide lõikes: I etapp (arendus- ja hooldustööd): ~ 2300 h. Kõik eelduslikud töömahud on hankija eelduslikud arvutused muuhulgas hanke eeldatava maksumuse määramiseks. Märgitud töömahud ei ole hankes siduvad. Hankijal ei ole kohustust nimetatud töömahtude väljaostmiseks. Eelduslike töömahtude puhul arvestatakse kogumahtu ning reaalne mahtude jaotumine rollide lõikes selgub tööde käigus. Tööde aruandlus , testimine ja vastuvõtmine Tehnilises kirjelduses ja selle lisades kirjeldatud tulemite ära toomiseks teostatakse tööd tellija poolt sätestatud prioriteetidest lähtuvalt. Tööde teostamiseks kasutatakse SCRUM arendusmetoodikat. SCRUMi tseremooniad ja nende sagedus lepitakse kokku avakoosolekul. Nii arendustööde kui ka hooldus- ja veaparandustööde tellimise, teostamise ja vastuvõtmise täpsem protsess koos nõuetega on kirjeldatud raamlepingus (RL punkt 7), raamlepingu tehnilises kirjelduses (RL TK punkt 5) kui ka projekti kodukorras . Antud hanke töökorraldus t kirjeldavad ja koostöö toimimiseks olulised punktid on täpsemalt kirjeldatud projekti kodukorras (Kodukord punkt 12). Teenustasemed (SLA) Teenustasemete osas lähtutakse raamlepingu teenustasemetest (SLA) (RL TK punkt 6). Maksimaalsed reageerimis- ja lahendusajad, mille jooksul peavad infosüsteemi, tarkvara või rakenduse vead saama hoolduse käigus lahendatud on toodud raamlepingu tehnilises kirjelduses (RL TK punkt 6.1). Garantii Kõigile lepingu alusel teostatud töödele rakendub garantii. Garantiitingimused on kirjeldatud raam lepingus (RL punkt 10) . Tööde piirangud Kõigi uute loodavate lahenduste puhul tuleb kasutada tehnoloogiaid, mis on kirjeldatud tellija IT profiilis. Tarkvara arenduse käigus tuleb lähtuda suunistest mis on kättesaadaval aadressil https://tehik.ee/arendusjuhendid . Automaattestide nõuded Allkirjastamise teenused SiGa ja SiVa IT-profiil Mittefunktsionaalsed nõuded Õigusruumi võimalikud piirangud võivad täpsustuda tööde käigus ja täitja peab sellega tööde teostamise puhul arvestama. Neid piiranguid enne tööde algust täpselt öelda ei ole võimalik. Õigusruum ei luba valimatult kõike, mis tehniliselt mugav ja need piirangud võivad täpsustuda kogu hanke perioodil . Sõlmitavates hankelepingutes on tellijal ja täitjal õigus kokku leppida täiendavaid tehnilisi vahendeid (näiteks väliste andmefailide laadimiseks, andmete presenteerimiseks). Nii toodangueelsed kui toodangukeskkonnad asuvad tellija juures. Plaanitavad uued komponendid nendes keskkondades peab looma täitja, seejuures eeldab tellija, et kui ei ole spetsifitseeritud teisiti, peab pakkuja eeldama, et tema vastutab projektides järgnevate tegevuste eest: mikroteenuste loomine vastavalt tellija poolt esitatud arhitektuuriplaanile; täies mahus CI/CD töövoogude koostamine; rakenduste paigaldus tellija DEV keskkonda läbi loodud CI/CD töövoo ning testkeskkonda koos tellija poolse süsteemiadministraatoriga; regulaarsete koodiläbivaatuste läbiviimine meeskonna siseselt; automaatsete testide koostamine vastavalt TEHIKu automaattestide koostamise juhendile; peakasutaja(te) koolitamine; dokumentatsiooni koostamine; funktsionaalse monitooringu loomine rakendustele vastavalt kokkuleppele tellijaga. Tarkvara arenduse puhul tuleb eelistada konteiner lahendusi. Esimene eelistus Apache Hop . Kõik muud alternatiivsed variandid tuleb eelnevalt kooskõlastada TEHIK-u arhitektiga. Tarkvara arenduse käigus võib kasutada ainult tellija repositooriumis olevaid teeke. Juhul kui on vajadus kasutada mõnda avalikku või mingit muud teeki siis tuleb see enne kooskõlastada tellija arhitektiga. Kõik kõrvalekalded eelnevast tuleb kooskõlastada tellija arhitektiga. Tellija eeldus on, et täitja ei pea enese juures looma ei eraldi arenduskeskkonda ega keskkondi tööde, dokumentatsiooni ega koodi haldamiseks ja säilitamiseks. Juhul kui täitja peab vajalikuks luua mõne komponendi jaoks enese juures arenduskeskkonda, luuakse see täitja kuludega, sh võimalikud täiendavad litsentsitasud. Arendustööde läbiviimiseks on vajalik ligipääs olemasolevate ning loodavate andmeladude toodangueelsetele keskkondadele. Andmeladude keskkonnad hõlmavad ladude baase, andmelaadimise funktsioone, andmeparandusfunktsioone ning aruandluskeskkondi. Lähtekoodi ja skriptide tarnimiseks ning töövoogude koostamiseks on kasutusel GitLab . Sõltuvuste repositoorium on vaikimisi tellija Artifactory . Kubernetese halduseks on kasutusel Rancher . Dokumentatsioon ja juhendid tarnitakse tellija Confluence keskkonda https://wiki.sm.ee . Andmetabelid peavad olema kirjeldatud. Tarkvara käivitamise ja kasutamise juhendid peavad lisaks olema ka GIT- is koodi juures markdown formaadis. Tööde halduseks on kasutusel JIRA keskkond https://smjira.sm.ee . Aja logimiseks kasutatakse Tempo. Aktsepteeritud suhtluskanaliteks on tellija MS Teams , tellija Jira/ Confluence ja e-mail. Enamuse rakenduste ja keskkondade ligipääs on arendajale võimalik ainult VPN tunneli kaudu. IP põhiseid ligipääse vaikimisi ei looda. VPN tunneli kasutamiseks on vajalik Eesti ID kaart või Digi-ID. Lisad Lisa 1.1 - TEHIK mittefunktsionaalsed nõuded arendustele 19082025 Lisa 1.2 - Andmeladude olemus ja funktsioon juhis 14042023 Lisa 1.3 - IT-Profiil v3 veebidoc Lisa 2 – Kodukord Sissejuhatus Kodukorra eesmärk on täpsustada poolte õiguseid ja kohustusi ja tööde teostamise korraldust. Nõuete haldus Antud peatüki eesmärk on k irjelda da kust ja kuidas nõuded tulevad, kuidas nõuded kaardistatakse , kuidas neid hallatakse, kuidas hallatakse muudatusi, sh kuidas kinnitatakse muudatused , kuidas ärilised nõuded seotakse süsteeminõuetega ja kuidas süsteeminõuded seotakse arenduse taskide , testilugude jms- ga . Projekti skoopi kuuluvad tööd on kirjeldatud hanke tehnilises kirjelduses ja selle lisades. Nende tööde teostamise jälgimiseks loob täitja projektijuht võimalikult sarnase töömahuga piletid projekti tööhalduskeskkonnas. Pileteid võib samadel tingimustel luua ka tellija. Projektis ei teostata töid, mida pole hanke tehnilises kirjelduses defineeritud (ja mille kohta ei ole seega tööhalduskeskkonnas piletit). Tööde läbivaatamisel võib tellija tuua välja erinevaid muudatusvajadusi, mis defineeritakse projekti töörühma poolt tööhalduskeskkonna vastavas piletis nõuetena või uute tööpiletitena. Dokumentatsiooni loomisel tuleb lähtuda suunistest mis on kättesaadaval aadressil https://tehik.ee/arendusjuhendid („Nõuded infosüsteemi dokumentatsioonile“). Kommunikatsiooni haldus Tellija projektijuht säilitab kogu projekti vältel toimuva kommunikatsiooni, mida on võimalik kirjalikult taas esitada, projekti ja garantiiperioodi kehtivuse vältel. Projekti kommun i katsiooni vormid on järgmised , kuid neile võib vastavalt vajadusele kokkuleppeliselt lisanduda ka muid kommunikatsiooni vorme, mida pole alljärgnevas tabelis kirjeldatud : Kommunikatsiooni vorm Sagedus Vastutav roll Reeglid Igapäevane teabevahetus Jooksvalt Tellija PJ Täitja PJ Tööde läbiviimiseks lepib töör ühm kokku vestluskanali ( Teams vms), millesse kuuluvad kõik töörühma liikmed. Projektijuhid tagavad, et kõigil osalistel oleks kanalisse ligipääs Vajadusel lepivad poolte projektijuhid kokku antud kanalis täiendavate alamgruppide loomise konkreetsete teemade arutamiseks Poolte projektijuhid vastutavad, et ebaturvalistes peetavates vestluskanalites ei edastataks tundlikke andmeid (n delikaatsed isikuandmed, tellija rakenduste turvalisust puudutav info). Vestluskanalis tõstatatud küsimusele tuleb vastata koheselt või anda vastamise tähtaeg. Mõlema poole projektijuhid jälgivad jooksvalt vestluskanalit ning viivituste korral korraldavad vastamise enda poolel Vestluskanalis langetatud otsused tuleb eraldi dokumenteerida projektidokumentatsioonis või tööde halduse keskkonnas. Ad hoc koosolekud Vastavalt vajadustele Tellija PJ Täitja PJ Keerulisematele küsimuste arutamiseks võivad tellija ja täitja projektijuht kokku kutsuda eraldi koosoleku. Koosolekule võib kutsuda ka liikmeid väljastpoolt projekti töörühma. Koosolekust antakse ett e teada vähemalt 1 tööpäev . Koosolekusse tuleb märkida päevakord, eesmärk ning toimumise koht. Koosolek võib toimuda nii kohapeal kui veebi vahendusel. Koosoleku tulemina koostab kokku kutsuja memo või delegeerib selle koostamise mõnele koosoleku osalejale. Kui koosoleku osalejad ei suuda leida vastust, eskaleerib koosoleku kokku kutsuja otsustamise projekti töörühma üldkoosolekule. Koosolekut võib tühistada poolte kokkuleppel hiljemalt 2-tunnise etteteatamise ajaga Projekti dokumentatsioon Jooksvalt Tellija PJ Täitja PJ Projekti dokumentatsioon hoitakse t ellija Confluence’i keskkonnas vastavas ruumis. Tellija PJ vastutab, et kõigil töörühma liikmetel oleks sinna ligipääs. Dokumentatsiooni struktuur lepitakse kokku projekti töörühma koosolekul. Igale dokumendile määratakse tellija ja täitja jälgija. Projektijuhid vastutavad, et dokumendi jälgijad teostaksid dokumendi kokkulepitud täiendused ja muudatused ning et dokumentatsioon püsiks ajakohane. Projekti tööülesanded Iganädalaselt Tellija PJ Täitja PJ Projekti kõiki tööülesandeid hallatakse t ellija Jira keskkonna vastavas projektis. Selles keskkonnas registreerimata töid ei teostata ega arveldata. Tellija PJ vastutab, et kõigil töörühma liikmetel oleks tööhalduskeskkonda ligipääs. Igal teostamisele määratud ülesandel peab olema täitja Ülesande täitja vastutab ülesande täitmise staatuse ajakohasena hoidmise eest Ülesanded vaadatakse läbi kord nädalas ning märgitakse juurde vastavad tegevused. Lepingu täitmist puudutav teabevahetus Vastavalt vajadusele Tellija PJ Täitja PJ Lepingu täitmist puudutav ametlik teabevahetus, mis pole kaetud muude kommunikatsioonivormidega (n tööülesannete ja projektidokumentatsiooni haldus) toimub e-kirja teel. Ametlikud e-kirjad registreerib tellija projektijuht tellija dokumendihalduse keskkonnas Kui e-kirjale oodatakse vastust, tuleb see pealkirja real või kirja alguses üheselt määratleda. Vastust eeldavale e-kirjale tuleb vastata hiljemalt järgneva tööpäeva jooksul. Kui see ei ole võimalik, tuleb järgneva tööpäeva jooksul anda sisulise vastamise tähtaeg. Lepingu üleandmis-vastuvõtu akt (ÜVA) tuleb t ellija poolsele lepingu kontaktile edastada meili teel ja digitaalselt allkirjastatuna. Tellija korraldab ÜVA registreerimise ja allkirjastamise dokumendihaldussüsteemis ning täitjale meili teel tagastamise. Arved lepingu täitmise eest esitatakse e-arvete keskkonnas. Erakorraline teabevahetus Vastavalt vajadusele Tellija PJ Täitja PJ Poolte vaheline teabevahetus, mis pole kaetud eelnevalt kirjeldatuga, lepitakse kokku tellija ja täitja PJ poolt vastavalt olukorrale. Projektijuhid lepivad kokku, millises vormis erakorraline kommunikatsioon edastada ning kuidas seda edasi käsitleda. Reeglina on erakorralise kommunikatsiooni vormiks ametlik e-kiri, mis registreeritakse t ellija dokumendihalduse süsteemis. Kommunikatsioon kriisiolukorras on kirjeldatud käesoleva dokumendi punktis 5. Projekti muudatuste haldus Projekti muudatuseks nimetatakse vajadust, mida pole varasemalt kokku lepitud projekti ressurssides, skoobis (sh nõuetes, tulemites, verstapostides, eeldustes, piirangutes või seostes) või tööplaanis ja mille realiseerimine toob kaasa muudatusi varasemalt kokku lepitud: ü le antavates tulemites ja/või a jakavas, projekti eelarves, inimressurssides ja/või p rojekti läbiviimise tööprotsessides Muudatustaotlused registreerib ja nende menetlemise seisu jälgib tellija projektijuht projektidokumentatsiooni keskkonnas. Registreeritud muudatustaotlused vaatavad poolte projektijuhid koos läbi, konsulteerides vastavalt vajadusele projekti töörühmaga. Läbivaatuse käigus märgitakse taotlusse muudatuse mõju projekti tulemitele, ajakavale, eelarvele ning inimressursside kasutamisele. Enne muudatustaotluse esitamist tuleb tagada, et on olemas vajalikud eeldused muudatuse teostamiseks. Juhul , kui muudatus eeldab lisarahastust, hankes nimetamata ressursside kaasamist projekti või läheb muul viisil vastuollu riigihanke dokumentatsiooni sõnastusega, peab tellija projektijuht koostama muudatust põhjendava memo ning kooskõlastama selle tellija dokumendihaldussüsteemis vastavalt kehtivale asjaajamiskorrale. Muudatus ei tohi tekitada täitjale eelist võrreldes teiste riigihankes kandideerinud pakkujatega. Muudatuse realiseerimisega alustatakse alles peale vajalike kooskõlastuste saamist ning vajadusel hankelepingu või projekti kodukorra muudatuse allkirjastamist mõlema poole poolt. Probleemide haldus Kriisiolukorraks loetakse olukorda, kus: poolte esindajad ei suuda kokkuleppele jõuda ; on muutunud võimatuks võtmeisikute osalemine tööde teostamisel ; on ilmnenud muud asjaolud, mis võivad oluliselt mõjutada tööde edukat elluviimist ja/või satuvad olulisse ohtu kokkulepitud tähtajad ja/või funktsionaalsus. Kriisiolukorra tekkimisel on pool kohustatud sellest teise poole esindajat viivitamatult teavitama e-maili teel. Poole projektijuht helistab lisaks üle teise poole projektijuhi ning kontrollib meili kättesaamist. Kui telefonikõnele pole võimalik vastata, tuleb tagasi helistada esimesel võimalusel, aga mitte hiljem kui järgmise tööpäeva lõpus. Kriisi tekkel informeerib tellija projektijuht koheselt TEHIK - u andmeanalüüsi ja/või andmeladude talituse juhte, kes rakendavad täiendavad meetmed kriisi lahendamiseks. Kriisist väljumiseks teevad mõlemad pooled kõik endast sõltuva mõlemat poolt rahuldava lahenduse leidmiseks. Kriisi vältimise ja kriisist väljumise tegevuste edenemise eest vastutavad poolte projektijuhid. Kriisisituatsioonis võivad projektijuhid kokku leppida vajalike isikute kättesaadavuse ka peale tööpäeva lõppu. Kui eelnevate meetmete abil ei suudeta kriisist väljuda, kasutatakse täitja ja tellija vahelises lepingus sätestatud meetmeid. Kvaliteedi tagamine Juhtimise kvaliteet tagatakse käesolevas projektis läbi süstemaatilise ja aktiivse projektijuhtimise, kus regulaarselt jälgitakse kokkulepitud tööplaani ja tööprotsesse ning muid hanke- ja projektidokumentatsioonis sõnastatud meetodeid, reegleid ja põhimõtteid. Töö teostaj a tagab, et projekti üle antavate tulemite kvaliteedi tagamiseks on tulemid (tarned) eelnevalt testitud vastu esitatud (sh funktsionaalseid ja mittefunktsionaalseid) nõudeid ning tuvastatud vead on parandatud enne t ellijale üleandmist. Tulemite valideerimine ja kinnitamine Selliste tulemite nagu aruanded ja dokumentatsioon valideerimiseks vaatab tellija analüütik tulemid läbi, rakendades neid toodangukeskkonna andmetele ning kinnitab tulemite vastavust enda ärivajadustele tellija tööhalduskeskkonnas. Tööd ei võeta vastu enne , kui tellija analüütik või tema esindaja on tööhalduskeskkonnas kinnitanud loodud tulemi sobivust. Laadimise koodi ja infodomeenile vastava andmemudeli vastavust nõuetele kontrollib tellija andmelao spetsialist (arendaja, arhitekt) versioonihaldus keskkonnas (GIT). Andmeparandusalgoritmide valideerimiseks tuleb tagada, et need on tellija keskkonnas rakendatud, tellija andmelao arendaja on kinnitanud nende sobivust ning tellija analüütik on kinnitanud, et aruanded, mille andmekoosseisu algoritmid mõjutavad, on vastuvõetavad. Dokumentatsiooni vastavust kehtivatele mittefunktsionaalsetele nõuetele kontrollib tellija projektijuht, kaasates vastavalt vajadusele täiendavaid spetsialiste. Riskide haldus Riskide haldus hõlmab: riskide tuvastamist, analüüsi ja riskide prioriseerimist, riskide juhtimistegevuste planeerimist, riskide juhtimist, riskide juhtimistulemuse kontrollimist ning otsustamist, kas risk on kontrolli all või vajab lisategevusi. Riskide halduse reeglid ja protsess on järgmine: t äitja projektijuht koos projektimeeskonnaga koostab esialgse riskiplaani vastavalt alljärgnevale tabelile: ID Valdkond Riski kirjeldus Riski realiseerumise tagajärg Riski mõju (M) Riski realiseerumise tõenäosus (TN) Skoor (S) Riski juhtimise tegevused Vastutaja Riskiplaan sisaldab järgmist infot: r iski _ID ; r iski valdkond (nt: k liendist tulenevad riskid, f inantsidest tulenevad riskid, a jahinnangutest tulenevad riskid, s koobist tulenevad riskid, t ehnilisest lahendusest tulenevad riskid jne) ; r iski kirjeldus ; r iski tagajärg ; r iski mõju ; r iski realiseerumise tõenäosus (TN) ; r iskikoefitsient/ skoor ; r iski juhtimise tegevused ja vastutajad . Riskiplaan arutatakse läbi kõigi seotud osapooltega. Riskiplaani muudatusi haldab täitja projektijuht, küsides regulaarselt tagasisidet projekti meeskonnalt ja tellija projektijuhilt. Riskiplaanis olevad kõrge prioriteediga riskid ja nende juhtimise tegevused, vastutajad ja seis vaadatakse üle projekti juhtrühmas. Riskiplaani hoitakse ning hallatakse tellija dokumendihalduskeskkonnas ( Confluence ). Riskide hindamine Riskide hindamine hõlmab riskide tuvastamist, analüüsi ning riskikoefitsiendi/skoori määramist. Riskide hindamisel osalevad kõik t äitja projektimeeskonna liikmed, projektijuhi ülesanne on tulemused kaardistada ning tagada riskiplaani aja- ja asjakohasus. Riskide hindamise reeglid on: riski esinemise tõenäosus 3 palli süsteemis (madal - 1, keskmine – 2, kõrge - 3) ; riski mõju 3 palli süsteemis (madal - 1, keskmine – 2, kõrge - 3) ; skoor on riski esinemise tõenäosuse ja mõju korrutis (S = TN x M) ; prioriteetsed riskid - koefitsiendiga 4-9 - kuuluvad alati ülevaatamisele projekti juhtrühmas ; partneriga seotud riskide hindamisel kaasatakse partneri esindaja/ projektijuht, kes vajadusel kaasab hindamisprotsessi omapoolsed spetsialistid. Riskide kontroll Riskide kontroll hõlmab riskide juhtimise tulemuste kontrollimist ning otsustamist, kas on lisandunud uusi riske, kas on muutunud mõne riski skoor, millised on abinõud riskide edasiseks juhtimiseks. Konkreetsete tegevuste täitmise eest vastutajad ning tähtajad kannab t äitja projektijuht üldisesse tööplaani. Nimetatud tegevuste täitmist kontrollib ja esitab ülevaate t äitja projektijuht projekti edenemise seisu raportis. Tööprotsessid Antud peatüki eesmärk on kirjeldada olulisemad tööprotsessid selleks, et meeskonnal oleks ühene arusaam, kes, mida, millal ja kuidas teeb. Nt protsess, kuidas toimub mingite nõuete ja analüüsitulemite ülevaatus ja kinnitamine projekti erinevate osapoolte vahel. Projekti alguses toimub avakoosolek (vajadusel mitu) ning luuakse kõigile osapooltele vajalikud ligipääsud tööde teostamiseks. Täitja teostab arendustööd vastavalt hanke tehnilisele kirjeldusele ja selle lisadele. Arendustööd teostatakse täitja poolt tellija poolses keskkonnas, millele tellija organiseerib täitja jaoks vajalikud ligipääsud. Tööde tulemid peavad olema täitja poolt testitud ning vastama tehnilises kirjelduses ja selle lisades seatud ootustele vastavalt hankelepingus ja tehnilises kirjelduses ettenähtud ajaraamile ning tähtaegadeks. Tööde registreerimiseks teavitab tellija täitjat töö vajadusest, esitades töö ettepaneku tööde / vigade halduskeskkonnas. Täitja kirjeldab eelanalüüsi käigus vastavalt tellija poolt esitatud lähteülesandele tööle tehnilise lahenduskäigu ning annab tööle mahuhinnangu tundides. Kui tööd ei ole võimalik enne teostamist hinnata, siis arendaja teavitab sellest tellijat . T ellija kinnitusel võtab täitja sõltuvalt töö skoobist mõistliku mahu (4 kuni 8h) tööga tutvumiseks ja annab selle kohta teavituse töö piletisse enne tööga alustamist. Täitja annab tööga tutvumise järgselt tööle seejärel lõpliku hinnangu alles peale mainitud aja jooksul tööga tutvumist. Kui töö nende tundide jooksul laheneb, siis täiendavat hinnangut ei teki. Tellija kinnitab töö teostamise ja suunab selle töödekuhja pakkujale teostamiseks. Tellijal on õigus pakutud mahuhinnang tagasi lükata või töö teostamine peatada ning arendustööd mitte tellida. Täitja teostab tööde osas aruandlust. Täitja peab tööde osas arvestust rollide kaupa ja esitab tööde kohta aruande tööde üleandmise ja vastuvõtmise aktis sisalduva tabeli kujul. Täitja esitab tellijale aruande iga kuu kohta, mis sisaldab täitja poolt veaparandus ja/või tellimuste alusel tehtud tööde (sh garantiiliste tööde) nimekirja (sh. tarneid ja vastuvõetud töid) ning mahtu (töötunnid). Täitja esitab aruanded tellijale vähemalt 1 kord kuus. Täitja peab salvestama tööde aruandlust (logima töö teostamiseks kulunud aega) tööde/vigade halduskeskkonnas ( Jira ) kasutades selleks tellija poolt aktsepteeritud aja logimise lahendust (TEMPO). Täitja peab tööde teostamiseks kulunud aega salvestama vastava töö pileti külge iga päev kui tööd on tehtud. Ei ole aktsepteeritav, et täitja esitab ajaaruanded töö pileti tasemel suuremas mahus kui 1 päev (8 tundi) viivitusega . Tööde aruandluse salvestamine tööde/vigade halduskeskkonda on kohustuslik ja on tööde akteerimise aluseks. Täitja annab aruande alusel tööd üle aktiga. Akteerimisele kuuluvad ainult tööd, mis on hinnatud või muul juhul tellija poolt töösse kinnitatud ja peale täitja poolset tööde teostamist tellija poolt tööde / vigade halduskeskkonnas vastu võetud ja/või jõudnud muu resolutsioonini (nt. katkestatud, tühistatud, ...), kus tellija kinnitab teostatud tööde akteerimise. Tellija l on õigus töösse eelnevalt kinnitamata täitja poolt raporteeritud töö tun de mitte akteeri da . Täitja suunab tööga seotud pileti tellijale kui töö on valmis vastuvõtutestimiseks (test) keskkonnas. Piletisse tuleb märkida seos nõuetega, vastavalt hanke tehnilisele kirjeldusele ja selle lisadele, mida see pilet mõjutab. Piletisse tuleb lühidalt kirjeldada teostatud töö tulem ning võimalusel viidata tehtud tööle tellija keskkonnas ja/ või koodi asukohale koodihalduskeskkonnas. Piletisse tuleb märkida viide dokumentatsioonile, mida tööde käigus loodi, muudeti või täiendati. Kulupõhise arvelduse puhul peab piletis olema tööde teostamiseks kulunud aeg ( TEMPO ). Suunamise eest järgmisele täitjale vastutab vaikimisi isik, kelle nimel pilet on. Uute piletite määramise eest täitjale vastutatavad tellija ja täitja projektijuhid. Tööde tarnimine täitja keskkondadest tellija keskkondadesse toimub peale täitjaga kooskõlastamist ning tarnete puhul lähtutakse tellija muudatuste halduse protsessist. Tellija testib tulemeid esialgu võimalusel test keskkonnas ja peale tarnet ka toodangu ( live ) keskkonnas. Juhul kui töös esineb vigu, annab tellija omalt poolt tagasisidet täitjale, et täitja saaks teha vajalikud parandused. Tellija kinnitab tulemid, kui need vastavad tehnilises kirjelduses ja selle lisades seatud ootustele tulemi suhtes toodangu keskkonnas ( live ) – Definition of Done ( DoD ) . SCRUM protsessid Antud peatükki kohaldatakse juhul, kui projektis on kasutusel SCRUM arendusmetoodika. Tellija on tooteomaniku ( Product Owner ; PO) rollis. Täitja on Scrum Master (SM) rollis. SCRUM sündmused Sprint on Scrum -i konteinersündmus. Sprint sisaldab kõiki vajalikke töid sh : Analüüs Disain Arhitektuur Arendus Testimine Jne. Sprint kestab 1-4 nädalat (maksimaalselt 1 kuu ) . Enamasti on kokkuleppeliselt projektis sprindi kestvuseks 1-2 nädalat. Sprint võimaldab prognoosimist ja riski piirangut – iga sprindi lõpus on mõõdetav tulemus. Sprindi v õtmesisendid: Toote backlog Tiimi võimekus ( velocity ; capacity ) Valmimiskriteeriumid ( DoD – Definition of Done ) Viimane töötav tarkvara versioon ( increment ) ja tagasiside retrospektiivist. Sprindi eesmärk on võtmeväljundina luua töötav ja potentsiaalselt lansseeritav ( tootestatav ) tarkvara versioon ( increment ). Sprindi sündmused: Sprint planning – Sprindi alustamine õige fookusega. Eesmär k: M äärata, millised tööülesanded lähevad toote backlogist sprindi backlogi . Koostada plaan, kuidas sprindi jooksul seatud eesmärk saavutada. Kestvus ja regulaarsus : K uni 2 h iga nädala kohta (maksimaalselt 8 h 4-nädalase sprindi kohta). Väljund: Sprint backlog – konkreetne tööplaan kogu sprindi jaoks. Daily Scrum – Igapäevane lühikoosolek sprindi sujuvaks edenemiseks. Eesmärk: Ülevaade viimase 24h progressist sprindi eesmärgi suhtes. Vajadusel sprindi backlogi uuendamine. Kestvus ja regulaarsus: Kuni 15 minutit iga päev samal ajal. Väljund: Järgmise 24h plaan. Sprint Review – Iteratiivne tagasiside sessioon. Eesmärk: Vaadata üle sprindi jooksul valminud versioon ( increment ). Vajadusel uuendata toote backlogi lähtuvalt tagasisidest. Kestvus ja regulaarsus: Iga sprindi lõpus 1 kord kuni 1 h iga nädala kohta (maksimaalselt 4 h 4-nädalase sprindi kohta). Väljund: Uuendatud toote backlog . Sprint Retrospective – tiimi eneseanalüüs ja parendamine. Eesmärk: Selgitada välja parendused, mida saab rakendada järgmise sprindi jooksul. Kestvus ja regulaarsus: Kohe pärast Sprint Review -d 1 kord kuni 1 h ia nädala kohta (maksimaalselt 4 h 4-nädalase sprindi kohta). 1-2 planeeritud parendust järgmisesse sprinti. Tööde piirangud Tööde teostamisel peab arvestama, et TEHIKu pärandandmelaod laadivad infosüsteemide PostgreSQL ja Oracle baasidest Pentaho abil SAP IQ andmeladudesse. Andmeanalüüsi keskkonnana on kasutusel WebFocus , sh veebipõhine töökeskkond WebFOCUS InfoAssist . Kõigi uute loodavate lahenduste puhul tuleb kasutada tehnoloogiaid, mis on kirjeldatud tellija IT profiilis. IT profiili ning teiste kohalduvate dokumentide viited (mittefunktsionaalsed nõuded, nõuded andmeladude arendusele, automaattestimisele) ning nende materjalide kasutamine ja kohaldamine raamlepingu jooksul on täpsemalt kirjeldatud raamlepingus. Sõlmitavates hankelepingutes on tellijal ja täitjal õigus kokku leppida täiendavaid tehnilisi vahendeid (näiteks väliste andmefailide laadimiseks, andmete presenteerimiseks). Nii toodangueelsed kui toodangukeskkonnad asuvad tellija juures. Plaanitavad uued komponendid nendes keskkondades peab looma täitja, seejuures eeldab tellija, et kui ei ole spetsifitseeritud teisiti, peab pakkuja eeldama, et tema vastutab projektides järgnevate tegevuste eest: m ikroteenuste loomine vastavalt tellija poolt esitatud arhitektuuriplaanile ; t äies mahus CI/CD töövoogude koostamine ; r akenduste paigaldus tellija DEV keskkonda läbi loodud CI/CD töövoo ning test keskkonda koos tellija poolse süsteemiadministraatoriga ; r egulaarsete koodiläbivaatuste läbiviimine meeskonna siseselt ; a utomaatsete testide koostamine vastavalt TEHIKu automaattestide koostamise juhendile ; p eakasutaja(te) koolitamine ; d okumentatsiooni koostamine ; m ittefunktsionaalse monitooringu loomine rakendustele ; f unktsionaalse monitooringu loomine rakendustele vastavalt kokkuleppele tellijaga. Tarkvara arenduse käigus tuleb lähtuda suunistest , mis on kättesaadaval aadressil https://tehik.ee/arendusjuhendid . Tarkvara arenduse puhul tuleb eelistada konteiner lahendus i. E simene eelistus A pache H op või custom konteiner (tuleb kooskõlastada arhitektiga) . Tarkvara arenduse käigus võib kasutada ainult tellija repositooriumis olevaid teeke. Juhul , kui on vajadus kasutada mõnda avalikku või mingit muud teeki , siis see tuleb see enne kooskõlastada tellija arhitektiga. Kõik kõrvalekalded eelnevast tuleb kooskõlastada tellija arhitektiga. Tellija eeldus on, et täitja ei pea enese juures looma ei eraldi arenduskeskkonda ega keskkondi tööde, dokumentatsiooni ega koodi haldamiseks ja säilitamiseks. Juhul , kui täitja peab vajalikuks luua mõne komponendi jaoks enese juures arenduskeskkonda, luuakse see täitja kuludega, sh võimalikud täiendavad litsentsitasud. Arendustööde läbiviimiseks on vajalik ligipääs olemasolevate ning loodavate andmeladude toodangueelsetele keskkondadele. Andmeladude keskkonnad hõlmavad ladude baase, andmelaadimise funktsioone, andmeparandusfunktsioone ning aruandluskeskkondi. Lähtekoodi ja skriptide tarnimiseks ning töövoogude koostamiseks on kasutusel GitLab Sõltuvuste repositoorium on vaikimisi tellija Artifactory . Kubernetese halduseks on kasutusel Rancher . Dokumentatsioon ja juhendid tarnitakse tellija Confluence keskkonda https://wiki.sm.ee . Tööde halduseks on kasutusel JIRA keskkond https://smjira.sm.ee . Aja logimiseks on kasutusel Tempo. Aktsepteeritud suhtluskanaliteks on tellija Rocket.Chat , Microsoft Teams , tellija Jira / Confluence ja e-mail. Enamuse rakenduste ja keskkondade ligipääs on arendajale võimalik ainult VPN tunneli kaudu. IP põhiseid ligipääse vaikimisi ei looda. VPN tunneli kasutamiseks on vajalik Eesti ID kaart või Digi-ID. Koostöö ja töökorraldus Andmelao ja analüütikakeskkonna arendus- ja hooldustööd teostatakse koostöös tellija tiimiga (sh tiimijuht, andmeanalüütikud ja andmelao arendajad). Täitja meeskonnaliikmed peavad osalema tellija tööprotsessides ja koosolekutel. Täitja meeskonnaliikmed peavad töötama tellija töökeeles. Tellija töökeel on eesti keel. Täitja meeskonnaliikmed peavad töötama tellija tööajal vastavalt töökorraldusreeglitele, mis on tehtud täitjale teatavaks. Tellija tööaeg on üldjuhul tööpäevadel (v.a riiklikud pühad) kell 8:30 kuni kell 17:00. Täpne tööaja algus ja sellest tulenev lõpp lepitakse kokku hankelepingu kontaktisikutu vahel. Tellija kasutab agiilset arendusmetoodikat. Praktiline töökorraldus lepitakse kokku koos tellijaga tööde alguses ja vajadusel muudetakse jooksvalt tööde käigus. Täitja meeskonnaliikmetelt oodatakse aktiivselt ja sisulist koostööd. Täitja meeskonnaliikmed peavad vajadusel tegema koostööd ka teiste Andmelao ja analüütika arendus ja hooldustööde seotud infosüsteemide (näiteks alliksüsteemide ) arendus- ja hoolduspartneritega. Tööde üleandmise-vastuvõtmise akt Sisu Lähtudes Tervise ja Heaolu Infosüsteemide Keskuse , keda esindab /lepingus märgitud kontaktisik/ (edaspidi tellija ) ja /ettevõtja nimi/, keda esindab /lepingus märgitud kontaktisik/ (edaspidi täitja ) vahel päev.kuu.aasta sõlmitud hankelepingu nr ___ annab täitja üle ja võtab tellija vastu teostatud tööd. Käesoleva aktiga annab täitja tellijale üle tööd, mis täitja on teostanud vastavalt hankelepingule ja tellija võtab käesolevas aktis nimetatud tööd vastu. Tellija kinnitab, et tema või tema esindajad on käesolevas aktis nimetatud tööd üle vaadanud ning see vastab hankelepingule. Käesolev akt on täitja le tasu maksmise aluseks. Poolte vaheline arveldamine toimub hankelepingu alusel vastavalt käesolevas aktis sisalduvatele andmetele. Käesoleva akti pooled kinnitavad, et aktis sisalduvad andmed on nende parima teadmise kohaselt õiged. Akteeritavad tööd Nr Tööde loetelu (ID) töö nimetus Roll / Nimi Maht (h) Tunnihind (€/h) KM-ta Maksumus kokku (€) KM-ta 1 Roll 1 ___ € Roll 2 2 (...) (...) 3 4 ... ___ € Tööde üleandmise tähtaeg Tööd on üle antud päev.kuu.aasta /etappide puhul ka etapid/. Tööd teostati tähtaegselt. Puudustega tööde nimekiri Puuduseid töös ei esine./Esinevad järgmised puudused töös: ____; ____; Puuduste põhjendus. Puuduste kõrvaldamise tähtaeg on päev.kuu.aasta . Poolte allkirjad Tellija: Täitja: Lepinguline kontaktisik lepinguline kontaktisik /allkirjastatud digitaalselt/ /allkirjastatud digitaalselt/ Hankeleping nr 3-9/4512-8 Lepingu osa viitenumber 273311 001 005 000 Tervise ja Heaolu Infosüsteemide Keskus (edaspidi tellija ) , registrikood 70009770, aadress Pärnu mnt 132, 11317 Tallinn, keda esindab põhimääruse alusel direktor Margus Arm ja Industry62 OÜ (edaspidi täitja ) , registrikood 11124544 , aadress Harju maakond, Tallinn, Põhja-Tallinna linnaosa, Toompuiestee 35, 10149 , keda esindab põhikirja alusel juhatuse liige Andrus Altrov , edaspidi eraldi pool või koos pooled , sõlmisid raamlepingu nr 3-9/4512-1 alusel käesoleva hankelepingu (edaspidi leping ) alljärgnevas: Lepingu ese Lepingu esemeks on riigihanke „ Andmeladude ja analüütika arendus- ja hooldustööde arendusressurss “ alusdokumentides ( minikonkursi viitenumber 309495 ) olevas tehnilises kirjelduses nimetatud tööd (edaspidi tööd ). Lepingu tööde maht on kuni 1 5 0 000 EUR (käibemaksuta) maksimaalse mahuna . Lepingut rahastatakse riigieelarvest või ja/või välisvahenditest. Töö üleandmise ja vastuvõtmise tingimused Täitja annab töö üle igakuiselt alates lepingu sõlmimisest . 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. Tellitavad tööd antakse vastuvõtutestimiseks üle vastavalt lepingu tehnilises kirjelduses kokkulepitud tingimustele. Tellija vaatab töö üle vastavalt raamlepingu tingimustele. Koos üle antava tööga annab täitja tellijale üle kõik tööde intellektuaalse omandi õigused vastavalt raamlepingus kirjeldatule. Töö teostamise tähtaeg on 24 kuud alates lepingu sõlmimisest. Leping jõustub sõlmimise hetkel ja kehtib kuni 25 kuud või kuni poolte poolt oma kohustuste täitmiseni. Lepingu hind Lepingu täitmine toimub töötunnipõhisel arvestusel, tellija tasub üksnes lepingu alusel tellitud ja teostatud töötundide eest. Ühe töötunni maksumuseks lepingu täitmisel on 55,90 ( viiskümmend viis eurot ja üheksakümmend senti) eurot käibemaksuta. Täitja esitab tellijale e-arve igakuiselt . Arvel tuleb märkida riigihanke nimetus, lepingu osa viitenumber , lepingu number ja kontaktisiku andmed. Poolte vahelised teated ja kontaktisikud Teadete edastamisel ja kätte toimetamisel lähtutakse raamlepingu regulatsioonist. Tellija kontaktisikuks lepingu täitmisel on S ergei Erbin , tel 5845 1128 , e-post sergei . erbin @tehik.ee või tema asendaja. Täitja kontaktisikuks lepingu täitmisel on ________, tel ________, e-post ______ või tema asendaja. Lõppsätted Leping jõustub sellele poolte poolt allakirjutamise hetkest ja lõppeb poolte poolt oma lepinguliste kohustuste täitmise ga . Lepingu dokumendid koosnevad riigihanke alusdokumentidest, sh lepingu lisadest, lepingu muudatustest ja pakkumusest. Lepingu lahutamatuteks osadeks lepingu sõlmimise hetkel on järgmised dokumendid : Lisa 1 - Tehniline kirjeldus ühes selle lisadega ; Lisa 2 – Pakkumus (ei allkirjastata koos lepinguga) ; Lisa 3 – Kodukord; Lisa 4 – Tööde üleandmise ja vastuvõtmise akt; Poolte allkirjad Tellija: Täitja: