Pöördumine - Tervise- ja heaolu infosüsteemide keskus

Failid

Sisu (failidest)

Hankelepingu projekt 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 _____ (edaspidi täitja), registrikood_______., aadress ________, keda esindab põhikirja alusel _____, edaspidi eraldi pool või koos pooled, sõlmisid raamlepingu nr 3-9/4283-1 alusel käesoleva hankelepingu (edaspidi leping) alljärgnevas: 1. Lepingu ese 1.1. Lepingu esemeks on „SKAIS2 hallatavate teenuste ja nendega seotud tarkvara arhitektuursete ning tehniliste probleemide alased tööd“ Tehnilises kirjelduses nimetatud tööd (edaspidi tööd). 1.2. Lepingu tööde maht on kuni 1 132 000 (üks miljon ükssada kolmkümmend kaks tuhat) eurot ilma käibemaksuta. 2. Töö üleandmise ja vastuvõtmise tingimused 2.1. Täitja annab töö üle vastavuses lepingu lisas 1 kirjeldatud projekti vaheetappide ajakavale, lepingu lõpptähtaeg on 31.12.2027. 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 vastuvõtutestimiseks üle vastavalt lepingu lisas 1 „Tehniline kirjeldus“ 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 ____ (maksumus sõnadega) eurot käibemaksuta. 3.3. Arve esitatakse e-arvena, pärast akti tellija poolt allkirjastamist. 3.4. Täitja esitab tellijale e-arve pärast töö üleandmise-vastuvõtmise akti allkirjastamist. Arvel tuleb märkida raamlepingu ja hankelepingu number, lepingu osa viitenumber, riigihanke viitenumber ja tellija kontaktisiku nimi. 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 Maiu Nagel, projektijuht, tel +372 5090 782, e-post [email protected] või Epp Laanepõld, Heaolu valdkonnajuht, telefon +372 512 9729, e- post: [email protected] 3.3. Täitja kontaktisikuks lepingu täitmisel on ________, tel ________, e-post ______. 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; 4.3.3. Lisa 3 – Isikuandmete töötlemise tingimused. 5. Poolte allkirjad Tellija: Täitja: Lisa 1 Tehniline kirjeldus - SKAIS2 hallatavate teenuste ja nendega seotud tarkvara arhitektuursete ning tehniliste probleemide alased tööd. 1. Mõisted ja lühendid Mõiste/Lühend Kirjeldus EBS Majandustarkvara Oracle E-Business Suite GAP-analüüs Lahknevusanalüüs, olemasoleva SKA infosüsteemi analüüs vastu arhitektuuri tulevikuvisiooni (TO-BE), et selgitada välja ja prioriseerida lahknevuste (GAP) likvideerimiseks vajalikud tööd GovSSO Riigi SSO teenus (tehnilise nimega GovSSO) on Riigi Infosüsteemi Ameti poolt keskselt osutatav teenus, millega asutus saab oma e-teenuses ühekordse sisselogimisega autentida ID-kaardi, mobiil-ID, smart-ID ja Euroopa Liidu eID kasutaja (võimaldab kasutajal sisse logida ühe ja sama identifikaatori ja parooliga mitmes seotud, kuid omaette seisvas tarkvarasüsteemis) SKA Sotsiaalkindlustusamet SKAIS1 Sotsiaalkaitse infosüsteem (vananenud platvormil) SKAIS2 Sotsiaalkaitse infosüsteem uus rakendus (hõlmab Ametnikurakendust ja Iseteenindust) TO-BE lahendus SKA infosüsteemi arhitektuuri tulevikuvisiooni väljatöötamise projekt UAT Vastuvõtutestimine (user acceptance test) 2. Ülevaade Sotsiaalkindlustusamet (SKA) kasutab ülesannete täitmiseks sotsiaalkaitse infosüsteemi, mis koosneb SKAIS1, EBS, ja SKAIS2 rakendustest. Tegemist on infosüsteemiga, mida on arendatud hulk aastaid nii, et uute funktsionaalsuste loomise kõrval ei ole jätkunud ressurssi tehnoloogilise ajakohasuse tagamiseks. Süsteemis tekkinud oluliste kitsaskohtade leevendamiseks käivitati 2025.aastal SKA infosüsteemi arhitektuuri tulevikuvisiooni (TO-BE lahenduse) väljatöötamise projekt, mille käigus loodi arhitektuuri reeglistik, millele peavad vastama teostatavad arendused ning migreerimisplaan. Ühtlasi kaardistati probleemid ja eesmärgid, teostati GAP-analüüs, st analüüsiti olemasolevat lahendust vastu TO-BE arhitektuuri, et selgitada välja ja prioriseerida GAP likvideerimiseks vajalikud tööd. Lisaks oli juba varasemast teada kitsaskohti (nt seotud taustaprotsessidega), mis vajavad lahendamist. Antud lepingusse on koondatud mitmed olulised SKAIS2 hallatavate teenuste ja nendega seotud tarkvara arhitektuursete ja tehniliste probleemide alased alamprojektid ning SKAIS2 infosüsteemi töökorras hoidmiseks ja arendusprotsessi toetamiseks vajalikud regulaarsed tööd. 2.1. SKAIS2 Taustaprotsessid. Täna on SKAISis väga palju erinevate andmeallikatest regulaarseid päringuid, mida siis töödeldakse, nt. Rahvastikuregister. Need protsessid on hetkel ühes kohas ning ei ole eriti hästi jälgitavad. Projekti eesmärk on taustaprotsessid ümberstruktureerida, liigutada need ärimoodulitesse, ehitada neile juurde keskne haldusliides. Eelneva töö käigus on analüüsitud ja kaardistatud olemasolevate SKAIS2 infosüsteemi taustaprotsesside seis üle keskkondade ning on välja pakutud mikroteenuse lahendus, mille ülesandeks on taustaprotsesside töö orkestreerimine ja haldamine. Ühtlasi on välja selgitatud arendusvajadused koos esialgsete mahuhinnangutega pakutud lahenduse realiseerimiseks. Lisainfo: https://wiki.sm.ee/spaces/SKAIS2/pages/407087806/Ettepanek+cronjob-service+teenus 2.2. GAP 2.1: API lüüsi loomine Vajalik on luua ühine otspunkt kõigile süsteemivälistele API päringutele (ei hõlma X-tee päringuid). API lüüsi (API Gateway) muster on mikroteenuste arhitektuuris kriitilise tähtsusega komponent, mis võimaldab üheselt hallata teenuste otspunkte, nendega seotud turvapoliitikaid, päringute suunamist ja koormuse kontrolli (rate limiting). Ajalooliselt on iga SKAIS kasutajaliidese komponent pöördunud otse vastava ärifunktsionaalsuse eest vastutava sisemise serverikomponendi poole. Selline arhitektuur ei võimalda üheselt kontrollida süsteemi jõudvate päringute juurdepääsuõiguseid ega juhtida jõudlust. Samuti on kasutajaliidese konfiguratsiooni keerulisem, kuna peab iga otspunkti eraldi sisaldama. GovSSO-ga liitumisel loodi GovSSO autentimist haldav otspunkt, mille kaudu liiguvad kõik SKAIS iseteeninduse päringud. Käesoleva projekti käigus on vaja luua lisaks kõikehõlmav API lüüsi moodul (või täiendada GovSSO jaoks loodud moodulit viimaks see üle täielikult API lüüsi rolli süsteemis). SKAIS serverimoodulite vahelise suhtluse koordineerimine ei jää käesoleva projekti skoopi, serveritevahelist suhtlust käsitletakse Teenus võrgu projektis. Kuna tegemist on potentsiaalse pudelikaelaga, siis tuleb lahenduse loomisel juba eos mõelda jõudluse peale. Lisainfo: https://wiki.sm.ee/spaces/SKAIS2/pages/403843996/2.1.+API+l%C3%BC%C3%BCsi+loomine 2.3. GAP 2.5: Töökindel sõnumivahetus Töökindel sõnumivahetus ja idempotentsuse kontroll on süsteemi andmete terviklikkuse tagamise üks alustaladest. Idempotentsus - omadus teatud tehetel ja operatsioonidel matemaatikas ja informaatikas, mis tähendab, et operatsiooni on võimalik mitu korda rakendada ilma, et tulemus muutuks peale esimest rakendamist. SKAIS kontekstis tähendab see, et igasugune andmevahetus-töötlus protsess peab olema korratav kõrvalmõjudeta, s.t. sama sisendi mitmekordsel töötlemisel jääb süsteemi lõppseis alati samaks - sama tegevuse mitmekordsel läbimisel ei muutu tulemus, n.t. teenus saab sama sõnumi kaks korda - teistkordsel saabumisel ei töödelda sõnumit topelt. SKAIS puhul on hetkel puudu andmete terviklikkuse tagamine, so puudu on:  kõige lihtsam säilenõtkus lühiajaliste infrastruktuuriprobleemide korral (mida ei ole julgetud implementeerida kartuses andmetes vigu tekitada);  andmete salvestamise ja saatmise terviklikkuse tagamine (outbox muster);  idempotentsuse tagamine. Probleemi kõrvaldamiseks on SKAIS Arhitektuuri TO-BE vaates välja pakutud kolmest osast koosneva lahenduse ettepanek, kusjuures nende osade õiges järjekorras implementeerimine on oluline: 1) Idempotentsuse raamistiku juhendi ja tööpõhimõtte kirjelduse loomine (GAP 1.7.) – mis on sisendiks antud lepinguga tellitavale tööle ja mille teostab TEHIK tähtajaga hiljemalt 30.06.2026;  2) Idempotentsuse raamistiku loomine – mis on antud lepingu tööde skoobis;  3) Säilenõtkuse mehhanism (GAP 1.6) - mille teostab TEHIK tähtajaga hiljemalt 31.12.2027 - 1.6.REST/RabbitMQteenustetarbimisesäilenõtkus Vt ka https://wiki.sm.ee/spaces/SKAIS2/pages/403844005/2.5.+T%C3%B6%C3%B6kindel+s%C3%B5numi vahetus 2.4. GAP 2.3: Jälgitavus SKAISis on juba implementeeritud omajagu meetrikat ja logimist, kuid puudub selgelt ette kirjutatud standard ning mitmes kohas puudub halduritel adekvaatne ülevaade süsteemi protsesside tööst. Vajalik on luua läbimõeldud ja kõikehõlmav jälgitavuse raamistik, mis on iga infosüsteemi stabiilse töö aluseks. Korralikult implementeeritud jälgitavus muudab probleemidega tegelemise pigem ennetavaks tegevuseks, kuid annab süsteemi halduritele robustsed tööriistad probleemidele kiiresti reageerimiseks. Jälgitavuse probleem tuleb lahendada 4 osas:  Logimine o Kuigi logimine on tehnilisest mõttes õigesti lahendatud, tuleb üle vaadata logide sisu. o Auditeerida kõik tausta- ja automaatsed protsessid ning teha kindlaks, et nendega seotud logiväljundid vastavad SKAIS arendus- ja TEHIKu MFN standarditele.  Serveri meetrika o Viia kogu serveri meetrika ühtsele OpenTelemetry standardile. o Luua (või täiendada commons-telemetry teeki) ühine teek meetrika implementeerimise standardiks. Teek peab võimalikult palju mustri ja/või standardi alusel automaatselt tekitatavat meetrikat pakkuma ning võimaldama äriloogika spetsiifilist meetrikat võimalikult lihtsalt lisada.  Kasutajaliidese meetrika o Tuleb kasutusele võtta RUM (real user monitoring) teek, mis võimaldab kasutajaliidese meetrikat koguda OpenTelemetry formaadis. Teek peab võimalikult palju mustri ja/või standardi alusel automaatselt tekitatavat meetrikat pakkuma ning võimaldama äriloogika spetsiifilist meetrikat võimalikult lihtsalt lisada.  Graafikud ja teavitused o Analüüsida olemasolevaid graafikud ning teavitusi kaardistamaks jälgitavuse tühimikke. o Kõik graafikud ja teavitused peavad olema kirjeldatud koodis või konfiguratsioonifailides ning olemas hallatud versioonikontrolliga. Lisaks on vajalik luua standard reageerimisjuhiste formaadile, reageerimisjuhendid seni teada olevatele tüüp-probleemidele ning luua eeskiri, mille alusel luuakse esmakordselt esinevale probleemile reageerimisjuhis. Vt ka: https://wiki.sm.ee/spaces/SKAIS2/pages/403844001/2.3.+J%C3%A4lgitavus 2.5. GAP 1.10: Suitsutestide automatiseerimine SKAIS infosüsteemi GAP analüüsi kohaselt parendab suitsutestide automatiseerimine süsteemi tööd ja stabiilsust olulisel määral ning aitab kaasa SKAIS vastavusse viimisele Arhitektuurimanifestiga. Suitsutestide automatiseerimise eesmärk:  Tagada kiire ja automatiseeritud kontroll, kas süsteem on pärast muudatusi kasutuskõlblik;  Tuvastada varakult kriitilised vead, mis takistavad põhilist funktsioneerimist. Tööde fookus:  Põhivoogude kontroll suitsutasemel;  Lahendus ei kata detailset äriloogikat ega asenda regressiooniteste;  Lahendus peab olema paindlik ja edasiarendatav. 2.6. SKAIS2 Autotestid SKAIS2 infosüsteemis on arendustööde käigus loodud ja luuakse erinevaid automaatteste mis moodustavad SKAIS2 autotestide raamistiku. 2025.aastal käivitati SKAIS2 autotestide uuenduse projekt, mille eesmärk on hoida ja parandada SKAIS2 autotestide ning tagada stabiilne suitsu- ja regressioonitaseme katvus ka muutuvate arenduspartnerite korral.  Alustati töödega, et kaardistada, millised vood ja tegevused on juba olemasolevate autotestide poolt kaetud ning millised vood ja tegevused on testide poolt katmata ja järjestada need prioriteetsuse järgi;  Tööd kokku lepitud skoobi alusel.  Käesolev projekt keskendub SKAIS2 autotestide töökindlusele ja jätkusuutlikkusele. 2.7. SKAIS2 Tehnilised kaasnevad tööd SKAIS2 infosüsteemi töökorras hoidmiseks ja arendusprotsessi toetamiseks on vajalik teostada igakuiselt erinevaid kaasnevaid töid, sh:  keskkondadega seotud probleemide lahendamine ja keskkondade seadistamine;  gitlab pipeline'ide korrastamine, erinevate väiksemate tehniliste probleemide ja vigade juurpõhjuste kõrvaldamine;  arenduste code review, tarnetegevused;  arhitektuuri alased konsultatsioonitööd. 3. Hankelepingu eesmärk Lepingu eesmärgiks on realiseerida SKAIS2 hallatavate teenuste ja nendega seotud tarkvara arhitektuursete ning tehniliste probleemide lahendamise alaseid töid. 4. Tellitavad tööd 4.1. Lepinguga tellitakse SKA infosüsteemi taustaprotsesside ümberstruktureerimise, SKA infosüsteemi arhitektuuri tulevikuvisiooni (TO-BE lahenduse) ja olemasoleva olukorra lahknevuse (GAP) analüüsi töid, SKAIS2 kvaliteedi tagamise süsteemi (autotestid, regressioonitestid) parendamise ning SKAIS2 infosüsteemi töökorras hoidmiseks ja arendusprotsessi toetamiseks vajalikud tööd, sh vähemalt: 4.1.1. Taustaprotsesside ümberstruktureerimine – luua uus mikroteenus cronjob-service, mis kasutab db-scheduler teeki  -service teenuse loomine: pipeline’id, repo, uus mikroteenus, graafiline kasutajaliides;  Taustaprotsesside migratsioon: (28 teenust, 97 taustaprotsessi): cronjob põhjal Liquibase skripti tegemine, RabbitMQ binderi taha panek, KeyDB paigaldamine, FF taha panek;  Testimine;  Koodi puhastamine: @Scheduled/@SchedulerLock annotatsioonidega seotud kood, taustaprotsesside konfiguratsioonid, andmebaasi tabelid, FF-d;  Dokumentatsiooni uuendamine. 4.1.2. GAP 2.1: API lüüsi loomine  Luua 2 API lüüsi teenust – ametnikurakendust ning iseteenindust teenindavad API lüüsi teenused 4.1.3. GAP 2.5: Töökindel sõnumivahetus Idempotentsuse raamistiku loomine – s.t. ühiskasutatav tarkvara teek, millega on kaetud SKAIS põhilised andmesalvestusloogikad võimaldades täielikku protsesside täielikku idempotentsust. 4.1.4. GAP 2.3: Jälgitavus  Logimine Kuigi logimine on tehnilisest mõttes õigesti lahendatud, tuleb üle vaadata logide sisu. Auditeerida kõik tausta- ja automaatsed protsessid ning teha kindlaks, et nendega seotud logiväljundid vastavad SKAIS arendus- ja TEHIKu MFN standarditele.  Serveri meetrika Viia kogu serveri meetrika ühtsele OpenTelemetry standardile. Luua (või täiendada commons-telemetry teeki) ühine teek meetrika implementeerimise standardiks. Teek peab võimalikult palju mustri ja/või standardi alusel automaatselt tekitatavat meetrikat pakkuma ning võimaldama äriloogika spetsiifilist meetrikat võimalikult lihtsalt lisada.  Kasutajaliidese meetrika Tuleb kasutusele võtta RUM (real user monitoring) teek, mis võimaldab kasutajaliidese meetrikat koguda OpenTelemetry formaadis. Teek peab võimalikult palju mustri ja/või standardi alusel automaatselt tekitatavat meetrikat pakkuma ning võimaldama äriloogika spetsiifilist meetrikat võimalikult lihtsalt lisada. 4.1.5. GAP 1.10: Suitsutestide automatiseerimine Töö sisu (kõrgtasemel):  Luua suitsutestide automatiseerimise lahenduse ülesehitus;  olemasoleva süsteemi ja testimise konteksti arvestamine;  kriitiliste funktsionaalsuste katmine suitsutestidega;  edasist kasutamist võimaldava dokumentatsiooni loomine. 4.1.6. SKAIS2 Autotestid Töö sisu (kõrgtasemel):  olemasolevate autotestide stabiliseerimine;  testide struktuuri ja loetavuse parandamine;  ebastabiilsete testide vähendamine;  tehnilise võla vähendamine autotestides Skoobis olevad ärivaldkonnad (indikatiivne loetelu, mitte nõuete nimekiri):  pensionid (sh SKAIS2 arvestus ja väljamaksed);  arstlik ekspertiis (P26);  puudega isiku toetused;  nõuded ja kohustused;  registriliidestused (nt rahvastikuregister);  tingimuskontrollid;  tööülesanded;  suhtlus ja teavitused;  abivahendid, TSD, ESD. 4.1.7. SKAIS2 Tehnilised kaasnevad tööd   gitlab pipeline'ide korrastamine, erinevate väiksemate tehniliste probleemide ja vigade juurpõhjuste kõrvaldamine;  arenduste code review, tarnetegevused;  arhitektuuri alased konsultatsioonitööd. 4.1.8. Alamprojektide tööde alguses teostatakse analüüs 4.1.1 Taustaprotsesside ümberstruktureerimine puhul, kus analüüs on 2025.aastal teostatud):  arendusskoobi täpsustamiseks;  arendustööde prioriseeritud nimekirja koostamiseks. Nimekiri peab olema kirjeldatud detailsusega, mille alusel on võimalik iga töö suurusjärku hinnata; Tööde käigus täpsustakse ka automaattestidega kaetud funktsionaalsus ja koormustestide skoop, hinnatakse arendusskoobi teostusmaht (prioriseeritud tööde nimekirjas (backlogis) olevatele töödele esialgsete mahuhinnangute täpsustamine) ning täpsustatakse koostöös tellijaga projekti vaheetappide detailne kava ja ajaplaan. Tööde teostamine lähtuvalt alamprojektide täpsustatud vaheetappide kavast ja vahetähtaegadest. 4.1.10. Arenduste testimise tagasiside alusel lahenduse täiendused ja parendused. Tööd tuleb üle anda vastuvõtutestimisteks vastavalt käesoleva dokumendi punktis 6 toodud ajakavale. 4.2. Tööde loetelu tekib eelnevalt kokkulepitud backlogi alusel ja hallatakse Jiras:  Eelanalüüsi suunatud ülesanded (analüüsi task), mille tulemusel valmivad mahuhinnangutega kasutajalood (story’d) ja tehnilised eeldustööd (technical taskid);  Arendusse suunatud kasutajalood (story’d) ja tehnilised eeldustööd (technical taskid) backlog staatuses vastavalt tööde järjekorrale (rank). 4.3. Tellijal on õigus koostöös täitjaga täpsustada ja/või korrigeerida hankega tellitavate tööde skoopi ja/või ajaplaani juhul kui tööde elluviimise käigus selgub selleks põhjendatud vajadus. 4.4. Juhul, kui töö käigus selgub täiendavaid ärinõudeid või detaile, mille realiseerimine on küll vajalik, kuid ei mahu punktis 4.1 kirjeldatud skoopi, tehakse ühine taasesitamist võimaldavas vormis otsus (Tellija ja Täitja poolt) vastavalt töö mahule ja/või kriitilisuse astmele, kas täiendavat tööd teostatakse käesoleva või uue lepingu raames. Juhul, kui töö käigus selgub, et mõistlik on punktis 4.1 kirjeldatud skoobist midagi välja jätta, teeb selle otsuse taasesitamist võimaldavas vormis Tellija. 4.5. Hankelepingu mahu muutumine, st täiendavate tööde tellimine või skoobis kirjeldatud tööde teostamata jätmine, lepitakse Poolte vahel kokku hankelepingu muudatusega. 4.6. Punktis 4.1 on välja toodud loetelu teostatavatest põhitöödest, mis täitjal tuleb teostada. Antud loetelule lisaks kohustub täitja teostama ka muud tööd, mis on vajalikud teenuse nõuetekohaseks toimimiseks. 5. Tööprotsess ja tulemid Järgnevalt täpsustatakse Täitjaga sõlmitud raamlepingus (nr 3-9/4283-1) kirjeldatud tingimusi tööprotsessi, dokumenteerimise, töökorralduse, testimise ja mittefunktsionaalsete nõuete osas. 5.1 Tööprotsess 5.1.1. Tööraamistik peab tuginema etapiviisilisele planeerimisele, võimaldades arendusmeeskonna prioriteete jooksvalt muuta; 5.1.2. Tööraamistik peab võimaldama süsteemset ülevaadet iga kokkulepitud töö saavutustest; 5.1.3. Tööraamistik peab võimaldama arendusmeeskonna tulemuslikkuse (kasvu) jälgimist ajas; 5.1.4. Tööraamistik peab tagama, et arendusmeeskond tegeleb omal initsiatiivil enda tulemuslikkuse parandamisega ja parendusettepanekute esitamisega; 5.1.5. Täpsem töökorraldus lepitakse kokku pärast lepingu sõlmimist; 5.1.6. Tööde loetelu tekib eelnevalt kokkulepitud backlogi alusel ja hallatakse Jiras: 5.1.6.1. Eelanalüüsi suunatud ülesanded (analüüsi task), mille tulemusel valmivad mahuhinnangutega kasutajalood (story’d) ja tehnilised eeldustööd (technical taskid); 5.1.6.2. Arendusse suunatud kasutajalood (story’d) ja tehnilised eeldustööd (technical taskid) backlog staatuses vastavalt tööde järjekorrale (rank). 5.2 Dokumentatsioon Vastavalt punktis 4 kirjeldatud skoobile tuleb töö käigus luua ja täiendada SKAIS2 dokumentatsiooni, milleks on minimaalselt: 5.2.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. 5.2.2. Tehniline dokumentatsioon (nt paigaldusjuhendid, Confluence keskkonnas). 5.2.3. Andmemudel. 5.2.4. Dokumentatsiooni täpsed liigid ja sisu formaat lepitakse kokku tööde käigus kuid see peab vastama minimaalselt TK Lisa 2 – Nõuded arendusprojektide dokumentatsioonile SKAISi näitel kirjeldatud nõuetele ning nõuded liidestuste dokumenteerimisele on kirjeldatud TK Lisa 3 – Andmevahetusteenuse kirjelduse mall (draft). 5.3 Töökorraldus Projekti töökorraldus toetub kodukorrale. Täitja peab tagama piisava kaasamise ja ülevaadete andmise Tellijale. 5.3.1 Tööde üleandmine Arendustööde lähtekoodi tarne toimub pideva integreerimise (continuous integration) teel. Tööde järjekord, üleandmise aeg ja UAT tagasiside andmise aeg lepitakse kokku tööde käigus taasesitamist võimaldavas vormis (Tellija ja Täitja poolt). Töö üleandmisel kontrollib Tellija üle töö nõuetekohasuse ning annab vajadusel tähtaja töö parandamiseks. 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. 5.4 Nõuded automaattestimisele Automaattestide tegemine lepitakse Tellija ja Täitja poolt kokku tööde käigus. Automaattestimise nõuete täitmisel tuleb lähtuda nõuetest, mis on leitavad TEHIK arendusjuhendid veebilehelt menüüpunktist Automaattestide nõuded. Testidega kaetakse serveripoolne ja kasutajaliidese kood. Kaetavuse kontrolliks ja raporteerimiseks seatakse Tellija koodihoidla keskkonnas (Gitlab) üles pideva integratsiooni töövoog, mis seadistatakse koos toimima SonarQube koodi ja testide kaetavuse analüsaatoriga. Automaattestid peavad üle antavas lähtekoodis continuous-integration’i töövoo edukalt läbima. Samuti peab Täitja hoolt kandma, et varasemalt loodud testid jäävad töö lõpetamisel edukalt läbitavaks. Nõuete muutumisel peab Täitja viima testid vastavusse uute nõuetega või neid eemaldama, kui selliseid nõudeid enam ei eksisteeri. 5.5 Koormustestimised Koormustestide tegemine lepitakse Tellija Täitja poolt kokku tööde käigus. 5.6 Mittefunktsionaalsed nõuded Mittefunktsionaalsete nõuete täitmisel tuleb lähtuda järgnevast: 5.6.1. Loodud kasutajaliidesed peavad vastama Euroopa standardi EN 301 549 V3.2.1 nõuetele. 5.6.2. Uue funktsionaalsuse loomisel tuleb lähtuda raamlepingus (nr 3-9/4283-1) ja selle lisades kirjeldatud nõuetest ning SKAISi Arhitektuurimanifestist. 5.6.3. Täpsemad mittefunktsionaalsed nõuded, millest lähtuda, on leitavad TEHIK arendusjuhendid veebilehelt menüüpunktist Mittefunktsionaalsed nõuded. 5.6.4. Nõuded kiirusele ja latentsusele Allpool kirjeldatud nõuded kehtivad ainult SKAIS2 sisemisele rakendusele ehk väliste süsteemide vasteaegasid ei loeta ajalise nõude sisse.  API teenustele ning keskmine päringu teenindamise aeg ei tohi olla suurem kui 2 sekundit. Teenuse kvaliteedi tõstmiseks on poolel õigus teha teisele poolele ettepanekuid kiiruse ja latentsuse nõuete muutmiseks. Muudatuste korral kirjeldatakse kasutuslugude vastuvõtukriteeriumidesse mittefunktsionaalse nõudena. 5.7. Tulemid 5.7.1. Projekti tööde SKAIS2 poolsed arendused vastavalt skoobile ja nõuetele 5.7.1.1. Taustaprotsesside ümberstruktureerimine Taustaprotsesside haldus on viidud äriteenuste seest cronjob-service teenuse sisse, mis haldab neid protsesse keskselt. Võimalik on ametnikurakenduse kaudu taustaprotsesse konfigureerida ja muuta. Samuti on võimalik ametnikurakenduse kaudu taustaprotsesside hetke seisu näha. Võimalik on ka taustaprotsesside manuaalne käivitamine ametnikurakenduse kaudu. Äriteenuste seest on varasem taustaprotsesside konfiguratsioon ja kood eemaldatud. Samuti on puhastatud vastava äriteenuse andmebaasi skeema varasema taustaprotsesside funktsionaalsusest (seotud tabelid). Teenustest on eemaldatud taustaprotsessidega seotud Shedlock teegi kasutus. Uuendatud on dokumentatsioon. 5.7.1.2. GAP 2.1: API lüüsi loomine Loodud on eraldi API lüüs iseteenindusele ja ametnikurakendusele. Tulemiks on töötav(ad) API lüüsi moodul(id), SKAIS täielikult API lüüs arhitektuurile üle viidud. 5.7.1.3. GAP 2.5: Töökindel sõnumivahetus Loodud on kaaskasutatav raamistik teegi kujul, mida saab SKAIS moodulites integreerida andmetöötlemise loogikasse ning selle integreerimine SKAIS moodulites. 5.7.1.4. GAP 2.3: Jälgitavus Loodud on:  SKAIS mooduliteülene logide audit;  OpenTelemetry toega ühiskasutatav serveri meetrika teek ning selle integreerimine kõikidesse SKAIS moodulitesse;  OpenTelemetry toega ühiskasutatav kasutajaliidese meetrika teek ning selle integreerimine SKAIS kasutajaliidesega (ITP ja AR). 5.7.1.5. GAP 1.10: Suitsutestide automatiseerimine  Automatiseeritud suitsutestide kogum, mida saab regulaarselt käivitada  Selged ja kiiresti tõlgendatavad testitulemused  Tehniline alus edasiseks laiendamiseks. 5.7.1.6. SKAIS2 Autotestid Oodatav tulemus:  stabiilsemad autotestide käivitused;  testitulemused, mis peegeldavad päris probleeme, mitte tehnilisi tõrkeid;  autotestide raamistiku parem hallatavus ja arusaadavus meeskonnale. 5.7.1.7. SKAIS2 Tehnilised kaasnevad tööd Jooksvalt teostatavad kaasnevad tööd vastavalt igakuiselt kooskõlastatavatele arendusprotsessi toetamise ja SKAIS2 töökorras hoidmise vajadustele. 5.7.2. Valminud tööde tulemid antakse üle hiljemalt 31.12.2027 üleandmise-vastuvõtmise aktiga, tööde tulemid peavad sisaldama: 5.7.2.1. Viiteid dokumentatsioonile Confluence’is; 5.7.2.2. Viited tehtud töödele (Jira piletitena); 5.7.2.3. Viiteid koodile GitLabis. 5.7.2.4. Toimiv rakendus ja paigaldusjuhend. 6. Tööde teostamise ajakava ja tähtaeg 6.1. Projekti käigus teostatavate tööde vaheetappide ajakava ja tähtajad on toodud alljärgnevas tabelis, detailsem tegevusplaan ja vahetähtajad täpsustatakse projekti käigus lähtuvalt vaheetappide alguses teostatava detailanalüüsi tulemustest: Jrk Vastuvõtutestimiseks üle antava Arendustööde Lõpptähtaeg alamprojekti kirjeldus, sh seonduvad tööd üleandmise tähtaeg1 (hiljemalt) 6.1.1. Taustaprotsesside ümberstruktureerimine - 31.10.2026 31.12.2026 mikroteenuse cronjob-service loomine Järgneb toe periood 2 kuud 6.1.2. GAP 2.1: API lüüsi loomine 31.10.2026 31.12.2026 Järgneb toe periood 2 kuud 6.1.3. GAP 2.5: Töökindel sõnumivahetus 31.03.2027 31.05.2027 Järgneb toe periood 2 kuud 6.1.4. GAP 2.3: Jälgitavus 31.10.2026 31.12.2026 Järgneb toe periood 2 kuud 6.1.5. GAP 1.10: Suitsutestide automatiseerimine 30.09.2026 30.11.2026 Järgneb toe periood 2 kuud 6.1.6. SKAIS2 Autotestid jooksvalt 31.12.2026  2025: jätkutööd ja stabiliseerimine  2026: planeeritud hooldus ja vajaduspõhised täiendused 6.1.7. SKAIS2 Tehnilised kaasnevad tööd jooksvalt 31.12.2027 6.2. Kõikide eelnevalt kirjeldatud arendustööde vastuvõtutestimiseks (so Jira piletid "Ready for AT" ja toodangu keskkonda paigaldatav kvaliteetne lähtekood) üleandmise lõpptähtaeg on sätestatud punktis 6.1. ja täpsustatakse projekti käigus lähtuvalt detailanalüüsi tulemustest. Lepingu lõpptähtaeg on 31.12.2027. 6.3. Tööde üleandmisele järgneb Tellija poolne Tööde testimine mõistliku aja jooksul ja vajadusel Täitja poolne paranduste tegemine üle antud Töödes, kui testimise käigus ilmneb, et Tööd ei ole lõpptähtajaks teostatud nõuetekohaselt. 6.4. Tööd loetakse teostatuks tööde üleandmise-vastuvõtmise akti tellija poolt allkirjastamise hetkest. 6.5. Muudatused punktis 6.1 toodud ajakavas on võimalikud vaid tulenevalt arendustööde käigus selgunud asjaoludest kokkuleppel tellijaga tingimusel, et see ei ohusta järgnevate vaheetappide tähtaegu ja/või hanke objekti tarnimise tähtaega ning muudatusega ei muudeta lepingu üldist olemust. 1 Kõikide eelnevalt kirjeldatud arendustööde vastuvõtutestimiseks (so Jira piletid „Ready for AT“ ja toodangu keskkonda paigaldatav kvaliteetne lähtekood) üleandmise lõpptähtaeg 7. Tehnilise kirjelduse (ehk TK) lisad: - TK Lisa 1 – SKAISi Front-end arendusreeglid; - TK Lisa 2 – Nõuded arendusprojektide dokumentatsioonile SKAISi näitel; - TK Lisa 3 – Andmevahetusteenuse kirjelduse mall (draft) Lisa 3 ISIKUANDMETE TÖÖTLEMISE TINGIMUSED 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 AS HELMES, (edaspidi volitatud töötleja), registrikood 10364097, aadress Lõõtsa tänav 6 Tallinn 11415, keda esindab volikirja alusel Julia Mozberg, on sõlminud käesoleva isikuandmete töötlemise lepingu hankelepingu nr 3-9/4283-.... lisana nr 3 (edaspidi leping): 1. Ese ja eesmärk 1.1. Lepingu esemeks on volitaja ja volitatud töötleja (edaspidi koos nimetatud kui pooled) vaheliste tingimuste sätestamine seoses SKAIS tööde käigus käsitletavate andmete töötlemisega. 1.2. Isikuandmete vastutavaks töötlejaks on Sotsiaalkindlustusamet, kes on andud Volitajale 16.10.2018 teenuslepinguga nr 1-10/1486-1 (p 3.8) õiguse kaasata isikuandmete töötlemiseks täiendavaid volitatud töötlejaid seoses Sotsiaalkindlustusameti (edaspidi SKA) infosüsteemide arendamise, hooldamise või muu taolise eesmärgi täitmiseks. 1.2.1. Ligipääs isikuandmetele võimaldatakse vajaduspõhiselt üksnes konkreetset tööülesannet täitvale isikule ja üksnes mahus, mis on vältimatult vajalik ilmnenud vea kõrvaldamiseks. 1.2.2. Volitatud töötlejal on õigus saada ligipääs isikuandmete töötlemiseks üksnes raamlepingu nr 3-9/4283-1 täitmiseks, täpsemalt on õigus saada ligipääs raamlepingus kokku lepitud toodangu-eelses ja toodangukeskkonnas tekkivate vigade juurpõhjuste tuvastamiseks ja lahendamiseks, mida ei ole võimalik teisel viisil lahendada. 1.3. Lepingu täitmiseks on volitatud töötleja isikuandmete töötlemisega seotud tegevused lepingu alusel piiratud hankelepingu täitmiseks vajalike tegevustega. 2. Isikuandmed 2.1. Volitatud töötlejale võivad hankelepingu täitmise käigus teatavaks saada volitaja poolt hallatavas infosüsteemis või andmekogus töödeldavad isikuandmed (SKAIS põhimääruse § 7 -15 kirjeldab võimalikud isikuandmete koosseisud): 2.1.1. isiklikud andmed, nt inimese nimi, sünniaeg, isikukood, isikut tõendava dokumendi andmed; 2.1.2. kontaktandmed, nt aadress, telefoninumber ja e-posti aadress; 2.1.3. eriliigilised isikuandmed, nt andmed isiku või tema pereliikme terviseseisundi, majandusliku seisundi või perekonna kohta 2.1.4. jne 3. Volitatud töötleja kohustused 3.1. Volitatud töötleja on kohustatud: 3.1.1. tagama lepingueelsete läbirääkimiste ja lepingu täitmise käigus volitajalt ükskõik mis vormis saadud isikuandmete konfidentsiaalsuse ja mitte edastama ega võimaldama sellele teabele juurdepääsu kolmandale isikule ilma volitaja sellekohase selgesõnalise kirjaliku nõusolekuta; 3.1.2. tagama, et lepingu täitmise raames töödeldavaid isikuandmeid ei edastata väljapoole Euroopa Liidu liikmesriikide ja Euroopa Majandusühendusse kuuluvate riikide territooriumi ilma volitaja sellekohase selgesõnalise kirjaliku nõusolekuta; 3.1.3. kasutama ja töötlema isikuandmeid üksnes hankelepingu täitmiseks ja volitaja dokumenteeritud juhiste alusel, välja arvatud juhul, kui volitatud töötleja on kohustatud teavet töötlema volitatud töötleja suhtes kohalduva õiguse alusel. Viimati nimetatud juhul teavitab volitatud töötleja volitajat vastava kohustuse olemasolust enne teabe töötlemist; 3.1.4. võimaldama juurdepääsu isikuandmetele ainult nendele isikutele, kellel on selleks oma tööülesannete täitmiseks vajadus ning tagab, et need isikud on teadlikud ning järgivad isikuandmete töötlemis alaseid nõudeid ja õigusakte, nad on saanud asjakohase koolituse eelmainitud nõuete kohta, on võtnud endale konfidentsiaalsuskohustuse või neile kehtib asjakohane seadusest tulenev konfidentsiaalsuskohustus; 3.1.5. teavitama volitajat toimunud või põhjendatult kahtlustatavast lepingu punktis 3.1.4. sätestatud konfidentsiaalsuskohustuse rikkumisest viivitamatult; 3.1.6. täitma kõiki kehtivaid isikuandmete töötlemisalaseid nõudeid, andmete turvalisust puudutavaid ning isikuandmete kaitse alaseid Euroopa Liidu ja Eesti Vabariigi õigusakte ja muid eeskirju; 3.1.7. rakendama alltoodud organisatsioonilisi, füüsilisi ja infotehnilisi turvameetmeid isikuandmete kaitseks juhusliku või tahtliku volitamata muutmise; juhusliku hävimise ja tahtliku hävitamise eest ning õigustatud isikule andmete kättesaadavuse takistamise eest, volitamata töötlemise, sh avalikustamise eest: 3.1.7.1. vältima kõrvaliste isikute ligipääsu isikuandmete töötlemiseks kasutatavatele seadmetele; 3.1.7.2. ära hoidma andmete omavolilist lugemist, kopeerimist ja muutmist andmetöötlussüsteemis, samuti andmekandjate omavolilist teisaldamist; 3.1.7.3. ära hoidma isikuandmete omavolilist salvestamist, muutmist ja kustutamist ning tagama, et tagantjärele oleks võimalik kindlaks teha, millal, kelle poolt ja milliseid isikuandmeid salvestati, muudeti või kustutati või millal, kelle poolt ja millistele isikuandmetele andmetöötlussüsteemis juurdepääs saadi; 3.1.7.4. tagama, et igal andmetöötlussüsteemi kasutajal oleks juurdepääs ainult temale töötlemiseks lubatud isikuandmetele ja temale lubatud andmetöötluseks; 3.1.7.5. tagama andmete olemasolu isikuandmete edastamise kohta: millal, kellele ja millised isikuandmed edastati, samuti selliste andmete muutusteta säilimise; 3.1.7.6. tagama, et isikuandmete edastamisel andmesidevahenditega ja andmekandjate transportimisel ei toimuks isikuandmete omavolilist lugemist, kopeerimist, muutmist või kustutamist; 3.1.7.7. pidama arvestust isikuandmete töötlemisel kasutatavate tema kontrolli all olevate seadmete ja tarkvara üle, dokumenteerides järgmised andmed: 3.1.7.7.1. seadme nimetus, tüüp ja asukoht ning seadme valmistaja nimi; 3.1.7.7.2. tarkvara nimetus, versioon, valmistaja nimi ja kontaktandmed. 3.1.8. teavitama kirjalikult volitajat turvameetmete rikkumisest, mis põhjustab, on põhjustanud või võib põhjustada töödeldavate isikuandmete juhusliku või ebaseadusliku hävitamise, kaotsimineku, muutmise või loata avalikustamise või neile juurdepääsu viivitamata, kuid mitte hiljem kui kakskümmend neli tundi pärast sellest teada saamist. Juhul, kui rikkumisest teadasaamine langeb nädalavahetusele või riiklikule pühale, kohustub volitatud töötleja volitajat kirjalikult teavitama viivitamatult, kuid mitte hiljem kui nelikümmend kaheksa tundi pärast rikkumisest teada saamist. Kirjeldatud teates tuleb vähemalt: 3.1.8.1. kirjeldada isikuandmetega seotud rikkumise laadi, sealhulgas puudutatud andmesubjektide liike ja arvu ning puudutatud kirjete liike ja arvu; 3.1.8.2. teatada andmekaitsespetsialisti või mõne teise täiendavat teavet andva kontaktisiku nimi ja kontaktandmed; 3.1.8.3. soovitada meetmeid isikuandmetega seotud rikkumise võimalike negatiivsete mõjude leevendamiseks; 3.1.8.4. kirjeldada isikuandmetega seotud rikkumise võimalikke tagajärgi; 3.1.8.5. kirjeldada volitatud töötleja poolt pakutud või võetud meetmeid isikuandmetega seotud rikkumisega tegelemiseks ja 3.1.8.6. esitada muud teavet, mis on mõistlikult nõutav, et volitaja saaks täita kohaldatavaid andmekaitse õigusakte, sealhulgas riigiasutustega seotud teavitamise ja avaldamise kohustusi, näiteks teavet, mis on nõutav andmesubjekti tuvastamiseks. 3.1.9. lõpetama eelnevalt kirjeldatud rikkumised või tegema kõik endast oleneva nende lõpetamiseks ja kohaldama meetmeid isikuandmetega seotud rikkumise lahendamiseks, sealhulgas vajaduse korral rikkumise võimaliku kahjuliku mõju kõrvaldamiseks ja leevendamiseks; 3.1.10. kustutama, niivõrd kui see on võimalik, lepingu lõppemisel kõik tööde teostamise käigus teatavaks saanud isikuandmed ja nimetatute koopiad 30 päeva jooksul, v.a juhul, kui õigusaktidest tuleneb teisiti; 3.1.11. tegema volitajale kättesaadavaks kogu teabe, mida volitaja peab vajalikuks lepingus sätestatud kohustuste täitmise tõendamiseks; 3.1.12. võimaldama volitajal või volitaja poolt määratud audiitoril teha seoses isikuandmete töötlemisega auditeid ja kontrolle ning panustama nendesse. 4. Lõppsätted 4.1. Volitatud töötleja ei või oma lepingujärgseid kohustusi anda üle kolmandale isikule ega kaasata oma lepingujärgsete kohustuste täitmiseks kolmandat isikut. 4.2. Isikuandmete konfidentsiaalsena hoidmise kohustus jääb kehtima ka pärast käesoleva lepingu lõppemist tähtajatult. 4.3. Isikuandmete konfidentsiaalsena hoidmise kohustus ei laiene teabe avaldamisele volitatud töötleja audiitorile ja advokaadile. 4.4. Leping on kehtiv poolte poolt allkirjastamisest kuni hankelepingu järgsete kohustuste täitmiseni, v.a konfidentsiaalsuskohtustus, mis kehtib tähtajatult. 5. Poole allkirjad Volitaja: Volitatud töötleja: /Allkirjastatud digitaalselt/ /Allkirjastatud digitaalselt/ HANKIJA NIMI: Tervise ja Heaolu Infosüsteemide Keskus Pakkumusettepaneku nimetus: „SKAIS2 hallatavate teenuste ja nendega seotud tarkvara arhitektuursete ning tehniliste probleemide alased tööd.“ Käesolevaga teeb Tervise ja Heaolu Infosüsteemide Keskus (Hankija) Teile ettepaneku esitada pakkumus „SKAIS2 hallatavate teenuste ja nendega seotud tarkvara arhitektuursete ning tehniliste probleemide alased tööd“ teostamiseks raamlepingu nr 3-9/4283-1 alusel. Hankeleping sõlmitakse tulenevalt vajadusest realiseerida SKAIS2 hallatavate teenuste ja nendega seotud tarkvara arhitektuursete ning tehniliste probleemide lahendamise alaseid töid. Hankija soovib hankelepingu sõlmida ühe partneriga. Hankija soovib kõrvale kalduda raamlepingu „Sotsiaalkaitse valdkonna teenuste arendus- ja hooldustööd“ nr 3-9/4283-1 tellimuse esitamise korrast ja pöörduda kohe paremusjärjestuselt järgmise pakkumuse teinud raamlepingu täitja poole tuginedes raamlepingu punktile 6.2.4, Pakkumuse esitamise tähtaeg on 09.02.2026 kell 16:00 (võib esitada ka varem). Pakkumus saata e-posti aadressile [email protected]. Pakkumus tuleb esitada eesti keeles ja digitaalselt allkirjastatult. Pakkumus esitatakse Hankelepingu eseme tehnilises kirjelduses (Lisa 1) toodud tööde teostamiseks. Alternatiivsete pakkumuste esitamine ei ole lubatav. Töid tellitakse mahus kuni 1 132 000 eurot (ilma km-ta). Lepingu täitmist rahastatakse riigieelarve raames. Töid teostatakse jooksva tunnihinna arvestuse põhiselt lähtudes projekti vaheetappide ajakavast ja vaheetappide raames kavandatud funktsionaalsusest. Tööde ajaaruandes tuuakse välja tööde teostamiseks kulunud töötunnid isikute lõikes, seostades nimetatud isikud Jiras logitud tööülesannete ja kirjeldatud tegevustega. Projekti käigus teostatavate tööde aluseks on SKA infosüsteemi arhitektuuri tulevikuvisiooni (TO-BE lahenduse) väljatöötamise projekti käigus loodud arhitektuuri reeglistiku ja teostatud GAP-analüüsi käigus välja selgitatud ning prioriseeritud GAP likvideerimiseks vajalikud tööd. Lisaks oli juba varasemast teada kitsaskohti (nt seotud taustaprotsessidega), mis vajavad lahendamist ning SKAIS2 infosüsteemi töökorras hoidmiseks ja arendusprotsessi toetamiseks vajalikud regulaarsed tööd. Projekti vaheetappide sisu kirjeldus ja hetkel teadaolev ajakava on toodud Hankelepingu eseme tehnilise kirjelduse (Lisas 1) punktis 6. Vaheetappide käigus loodav funktsionaalsus tuleb vastuvõtutestimiseks üle anda tähtaegadeks:  1.vaheetapp: Taustaprotsesside ümberstruktureerimine - mikroteenuse cronjob-service loomine - hiljemalt 31.10.2026;  2.vaheetapp: GAP 2.1: API lüüsi loomine – hiljemalt 31.10.2026;  3.vaheetapp: GAP 2.5: Töökindel sõnumivahetus – hiljemalt 31.03.2027  4.vaheetapp: GAP 2.3: Jälgitavus – hiljemalt 31.10.2026  5.vaheetapp: GAP 1.10: Suitsutestide automatiseerimine – hiljemalt 30.09.2026  6.vaheetapp: SKAIS2 Autotestid - vastavalt analüüsi tulemina täpsustatud vahetähtaegadele;  Kõikide kirjeldatud tööde lõpptähtaeg on 31.12.2027. Pakkuja meeskond peab olema koheselt valmis täistööajaga panustama üksnes selle projekti õnnestumisse. Pakkumusena tuleb esitada: 1. Tööde teostamiseks planeeritud meeskonnaliikmed isikuliselt, tuues välja ka meeskonnaliikmete roll. Tööde teostamiseks peavad täitja meeskonda kuuluma minimaalselt 1 analüütik, 1 arhitekt, 4 arendajat, 1 testija ning projektijuht, kes vastutab tööde korrektse ja tähtajalise elluviimise ning tellijaga suhtluse eest. Töid peavad teostama pakkumuses nimetatud isikud. Kui meeskonnaliikmed erinevad riigihankes pakutud meeskonnast, tuleb pakkujal esitada nõuetele vastavate meeskonnaliikmete andmed etteantud vormil koos pakkumusega; 2. Tööde teostamise ühe töötunni hind (ilma käibemaksuta); 3. Tööde teostamise detailne projektiplaan, mis lähtub Hankelepingu tehniline kirjeldus (Lisas 1) punktis 6 toodud vaheetappide ajakavast. Pakkumuse esitamisega kinnitab pakkuja, et pakkuja on suuteline kinni pidama Hankelepingu eseme tehnilise kirjelduse (Lisas 1) punktis 6 toodud vaheetappide ajakavast ja lepingu tähtaja saabumiseks on teostatud Hankelepingu eseme tehnilises kirjelduse (lisas 1) punktis 4 toodud tööd. Pakkujal ei ole õigust tööde teostamiseks nõuda ajapikendust, täiendavat tasu või väljamakseid. Küsimuste tekkimise korral palun võtke ühendust enne pakkumuse esitamise tähtaega aadressil [email protected] . Pakkumusettepanekuga koos edastatavad dokumendid: Lisa 1. Hankelepingu eseme tehniline kirjeldus (koos lisadega) Lisa 2. Hankelepingu projekt. Lisa 3. Isikuandmete töötlemise tingimused. Front-end arendusreeglid FE arendusreeglid Versioon: 1.0 Lühendid FE – Front-end BE – Back-end FF – Mozilla Firefox IE – Internet Explorer UI – User interface (kasutajaliides) SEO – Search engine optimization Eesmärk ja sihtgrupp FE arendusreeglid on mõeldud kõigile FE ja BE arendajatele. Reeglite järgimine on kohustuslik. Veebilehitsejate tugi A klass: IE10+, Chrome (viimane versioon), FF (viimane versioon), Microsoft Edge (viimane versioon) Lõpptulem ei tohi kujundusest erineda, välja arvatud veebilehitsejate implementatsioonist tulenevad erandid (näide: selectboxi native kujundus on veebilehitsejates omavahel erinev ja see on lubatud) B klass: Safari Visuaalselt korrektne, aga võib erineda algsest kujundusest. Optimeerimise ja kodeerimise lihtsustamise eesmärkidel ei pea näiteks toetama ümarad nurkasid, gradiente jne. Stiililehed Üks peamine stiilileht nimega main.css, kus sees loogilises järjestuses kommentaaridega eristatult kõik rakenduse stiilid. Printimise jaoks on print media abil eraldi kuvatav stiilifail, mille eesmärk on kuvada sisuosa ilma illustreerivate elementideta. Ära peidetud on navigatsiooni elemendid, mis prinditud versioonis ei ole olulised. Kataloogide stuktuur gfx – CSSid koos CSSis defineeritud piltidega. images – HTMLis lingitud pildid. Alamkataloogid vajadustel komponendi põhistele elementidele, kui on ühes komponendis kasutusel rohkem kui 15 pilti. fonts – rakenduses kasutatavad fondi failid. scripts – rakenduses kasutatavad JS failid. CSSi haldamine CSSi stiilidel on üks haldaja ja vastutaja, kes on kursis kõigi muudatustega. Tema kohustus on üle vaadata teiste poolt kirjutatud CSS ja vastavalt vajadusele muuta või saata tagasi arendajale parandamiseks. CSSi haldamise eesmärk on, et ainult CSSi haldaja ja/või FE meeskond kirjutab CSSi. Arendajad peavad pöörduma CSSi haldaja ja/või FE meeskonna poole, kui on muudatusi vaja. CSSi haldaja koordineerib teiste arendajate tööd. BE arendajad tohivad stiile kirjutada ainult põhilise stiilifaili lõppu pärast vastavat kommentaari. Enda arendused peavad olema kommenteeritud nii, et CSSi haldaja saaks võimalikult kiirelt koodi üle vaadata ning sobivasse asukohta paigutada ja vajadusel koodi muuta. Eelnev kirjeldab olemas oleva koodi muutmist või väikseid uusi arendusi olemas olevas raamistikus. Uute arenduste korral tuleb tellida FE antud ala spetsialist, kellele on edastatud antud dokument. Kui uue koodi kirjutada ei ole CSSi haldaja on haldajal kohustus ülevaadata uus kood. Illustreerivad pildid Illustreerivad pildid peavad olema lisatud CSSi abiga. Pildid on optimeeritud. Salvestamisel valitud sobiv laiend vastavalt suurusele ja kvaliteedile. Võimalusel kasutatud Fireworksi, PNG optimizerit või antud hetkel sobivat vahendit vähendamaks piltide mahtu. Photoshopis tuleks pildid salvestada save for web abil. JPG puhul võib salvestada 75-80% ilma, et oleks visuaalset kadu. Kui pildi suuruseks on u 150KB, siis kontrollida üle optimeerimise võimalused. CSSis ja HTMLis lingitud pildid asuvad eraldi kataloogis. CSSis lingitavad illustreerivad pildid asuvad CSSiga samas kataloogis. Eelistada illustreerivate piltide kuvamist läbi CSSi. HTMLis lingitud piltide nimetamisel arvestada SEOd ja ühtset stiili. CSSi pildid nimetada sarnase loogikaga. Ikoonide alguses on icon_, taustapiltidel bg_ logodel logo_, nimekirjadel ul_ ja komponentide spetiifiliste piltidel puhul selle classi nimetus. Pildi nimed on läbivalt inglise keeles ja semantiliste nimetusega. Ei tohi kirjeldada pildil olevat värvi. Semantika Front-end kood peab vastama semantika reeglitele, välja arvatud juhul, kui kokkulepitud kasutatav raamistik ei võimalda seda saavutada. Kodeerimisel tuleb arvestada responsive (kohandub iseenesest ümber erinevatele ekraanisuurustele) versioonile üleminekuga. Olulisemad punktid Classi nimed on üldised või komponendi spetsiifilised Classi nimedes ei tohi olla kasutatud visuaalseid kirjeldusi. Näiteks värvid, suurused jne. Kasutada semantiliselt korrektseid HTMLi elemente. Näiteks nimekirjade puhul peab olema kasutatud UL või OL tagi vastavalt sisule. BR ei tohi kasutada. Layouti loomisel ei tohi kasutada tabeleid. Inline elemendi sisse ei tohi panna block elemente. Paragraafide sisse ei tohi kirjutada DIVe. Vältida tühjade HTMLi elementide kasutamist. Re-usable front-end 1. Enne kodeerimist tutvuda olemasolevate komponentidega. 2. Võimalusel kasutada olemasolevaid elemente. 3. Kujunduses olevate väikeste erinevuste puhul pakkuda välja ühtlustamise võimalusi ja lahendusi. 4. Kasutada üldiseid classi nimetusi ja arvestada kodeerimisel, et antud stiile oleks võimalik kasutada läbivalt. Erandite puhul kasutada eraldi classi nimetust. 5. Kodeerimisel arvestada, et uue elemendi muutmine ja haldamine oleks võimalikult lihtne. Näiteks arvestada keelsusega. Võimalusel vältida keelte jaoks erandite tegemist. HTMLi reeglid HTML peab valideeruma kasutades https://validator.w3.org HTML valideerimisvahendit. Inline CSSi ei tohi kirjutada ja kasutada. Cellpadding'uid ja cellspacing'uid ei tohi kasutada HTMLis. Võimalusel kirjutada optimeeritud koodi ja vältida üleliigseid elemente ja defineeringuid. Kasutada läbivalt ühtset stiili. Jutumärkideks on topelt jutumärgid näide class="style01" Arenduse failid on ühe tabi abil trepitud. Arvestada SEO soovitusi Vajadusel illustreeritavatel piltidel korrektsed alt väärtused. Meta tagid vastavalt kaasaegsetele nõudmistele. Piltide või ikoonide puhul, mis on kasutusel linkidena, kasutada title tagi. Title sisu peab kasutajale andma informatsiooni, et kuhu see link kasutaja suunab. Näide logo title väärtus on "Avalehele" HTMLis vältida ja eemaldada üleliigsed kommentaarid. CSSi reeglid Kehtib FE arendaja poolt loodud stiililehtede kohta. Ei kehti juhul, kui kokkulepitud kasutatav raamistik ei võimalda seda saavutada. CSS peab valideeruma kasutades https://jigsaw.w3.org/css-validator/ CSS valideerimisvahendit. CSSi treppimine Selektori ja loogeliste sulgude vahele üks tühik. Üks tab enne atribuuti (laiuselt võrdne nelja tühikuga). Selektorid ja atribuudid on eraldi ridadel. Näide ul*{ ****margin:*0; } Selectori blokkide vahel tühjad read eraldamaks erinevaid elemente aga üldiselt ilma tühja reata. h1 { font-size: 34px; } h2 { font-size: 24px; } a { color: #08c; } a:focus, a:hover { color: #ff6; } Esimese taseme ja teise taseme kommentaari ees ja järgi üks tühi rida. CSSis blokkide järjekord: normalize/reset, global common vastavalt struktuurile header, content ... Plugina CSSid, kui on tegemist pluginaga, mida kasutatakse samade stiilidega erinevates asukohtades, siis antud CSS lisada eraldi faili. media queries CSS Atribuutide järjekord: display: ; position: ; top: ; float: ; clear: ; width: ; height: ; overflow: ; margin: ; padding: ; outline: ; border: ; background: ; list-style: ; table-layout: ; border-collapse: ; vertical-align: ; text-align: ; text-indent: ; text-transform: ; line-height: ; word-spacing: ; color: ; font: ; cursor: ; visibility: ; opacity: ; z-index: ; content: ; quotes: ; CSS3 Ühikud Eelistatult läbivalt kasutada pixleid. 0 väärtuse korral ühik pole vajalik. 0em == 0px == 0 Class' ja ID nimetused läbivalt väikeste tähtedega, semantilised ja eralduseks kasutatud sidekriipsu. Näide: data-table-outer Classide nimetamisel kasutada läbivalt inglise keelt. ID kasutada ainult juhul, kui ollakse täiesti kindel, et seda elementi tulevikus ei kasutata lehel korduvalt. Näiteks lehe layout päis, jalus, menüü. CSSis on kaks taset kommentaare. 1. esimene tase /** =Kommentaar */ 2. teine tase /** =Kommentaar */ Kommentaarid läbivalt inglise keeles. Vajadusel rakenduse spetiifilisi mõisteid kasutada eesti keeles. Välja kommenteeritud koodi ei tohi jätta alles. Margin ja paddingute korrektne kasutamine. Paddingut kasutada antud elemendi sisse nn õhu jätmiseks ja marginit väljapoole. Tekstide joondamisel vältida line-heighti abil joondamist ja eelistada paddingut. Floatide clearimiseks on class clear, mis läheb floatitud elementide ümber olevale tagile. .clear:before, .clear:after { content: " "; display: table; } .clear:after { clear: both; } CSS kirjutada ainult selleks mõeldud faili. Inline CSSi ja HTMLi failis eraldi <style> kasutada ei tohiks. Võimalusel vältida ka visuaalsete stiilide defineerimist JS failides. Pildi URLi lisamisel jutumärke ei ole vaja kasutada. Vältida veebilehitsejaspetiifilisi häkke. Kodeerimisel arvestada mõistlikkuse piirides "Web Content Accessibility Guidelines (WCAG) 2.0" soovitusi. http://www.w3.org/WAI/WCAG20/quickref/ http://kristjankure.com/ Optimeerimine FE tehnikate abil https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Writing_efficient_CSS tbody#select-01 => #select-01 #navigation li a => #nav a tr.tr-name td.td-name => .td-name HTMLis olevatele piltide määrata kõrgus ja laius, kui on võimalik. Eesmärk vähendada re-flow'ed. Gradientide, ümarate nurkade jne puhul kasutada CSS3 ning vanematel veebilehitsejatel peab kujundus välja nägema visuaalselt korrektne aga ei pea olema visuaalselt identne. Kontrollida veebilehitseja võimalusi siit http://caniuse.com/. Kui on võimalik illustreerivad pildid nt nooled, bulletid asendada CSS3 lahendusega, siis seda võimalust kasutada. Kui vajadus tühja elementi kasutada, siis selle asemel kasutada CSSis before'i võimalust. Selle juures tuleks arvestada veebilehitsejate tuge ja kasutajamugavust mõistlikuse piirides. Informatsioon peab olema arusaadav ja kättesaadav ka B klassi veebilehitseja toele. Reflow ja repaint'iga arvestamine. CSSi reseti asemel kasutada normalize. Värvid kirjutada koodi abil (soovitavalt hex aga vajadusel rgba) ja läbivalt väikeste tähtedega. Võimalusel lühendada kolme tähelisteks. #ffffff => #fff #ff88aa => #f8a, #ff0000 => #f00 Võimalusel CSSi väärtused tõsta kokku ühele reale. Border-top, border-left, border-bottom, border-right => border CSSis ei tohi kasutada * lahendust määramaks kõigile elementide CSSi väärtuseid. Important kasutamist CSSi failis vältida. Normalize/reseti puhul ei tohiks olla defineeritud elemente, mida praktikas ei kasutata. Uue projekti alguses tuleks reset/normalize optimeerida ja vajadusel jooksvalt juurde lisada elemente. Võimalusel ja vajadusel kasutada sprite tehnikat. Pluginatega kaasa tulevat CSSi peab ülevaatama, optimeerima ja järjekorda uuendama. Kujundus Linkidele, nuppudele alati korrektsed :hover, :focus ja :active staatused määrata. hoveri ja fookuse puhul on eesmärk tuua visuaalselt element rohkem esile ja paremini loetavaks. aktiivse staatuse puhul tuleks jätta mulje, et nupule või lingile on vajutatud. Visuaalselt poolelt näiteks gradient on vastupidine või lingi värv on tagasihoidlikum. Arvestada olemasoleva kujundusega ja jälgida sellele sarnast stiili. Ühtlustada ja jälgida lõpptulemuse joonduseid. Nõuded arendusprojektide dokumentatsioonile SKAISi näitel Versioon kuupäev muutja kommentaar 0.1 04.07.2024 Epp Laanepõld esmane versioon tagasiside saamiseks Sissejuhatus 1. Süsteemi üldine kirjeldus 1.1. Sõnastik 2. Teenuste ja kasutuslugude dokumentatsioon 2.1. Näide: 2.2. CRUD maatriks 3. Arhitektuuri dokumentatsioon 3.1. Näide: 3.2. Andmebaasi kirjeldus 3.3. Näide: Andmebaasimudel: 4. Paigaldus ja administreerimisjuhend(TO DO) Versiooni muudatuse kirjeldus (release notes) 5. Täitja poolt teostatud testide dokumentatsioon Sissejuhatus Projekti väitel annab Täitja Tellijale üle dokumentatsiooni vastavalt arendusetapi kokkulepitud tulemitele. Dokumentatsioon luuakse ja antakse üle digitaalsel ja redigeeritaval(Confluence wiki lehena) kujul Tellija Confluence keskkonnas. Üleandmise hetkel fikseeritakse üleantav versioon. Dokumentatsioon peab sisaldama versiooni ajalugu, et oleks üheselt tuvastatav dokumendi versiooni sisse viidud muudatused võrreldes viimati üleantuga. Vajadusel vormistatakse dokumentidest PDF-versioonid. Dokumenteerimisel valmivad joonised ja prototüübid antakse Tellijale üle ka redigeeritavate failidena (joonised on redigeeritavad, eelistatult .EAP formaadis või draw.io). Prototüübid on redigeeritavad FIGMA tarkvaraga. Minimaalselt peab olema kaetud arendusprojektide läbiviimisel alljärgnevad osad dokumentatsiooniga: Süsteemi üldine kirjeldus Teenuste/kasutuslugude dokumentatsioon Arhitektuuri dokumentatsioon Paigaldus ja administreerimisjuhend Loodavate testide dokumentatsioon Juhendid ja abimaterjal Vajadusel migratsiooniga seotud dokumentatsioon Mittefunktsionaalsete nõuete vastavustabel* *vastavuste/mittevastavuste fikseerimine vorm on projektimeeskonna kokkulepe. Iga loodav dokument peab olema: Struktureeritud; Loetav ja selge; Kindlas kõneviisis ning keeleliselt korrektselt kirjutatud; Täpsete andmeväljade nimetustega ja mõistetega; Vormistatud lõppversioonis nii, et tekst ei sisalda enam täiendavaid kommentaare ja täpsustusi. 1. Süsteemi üldine kirjeldus Kirjeldada mis on arendusprojekti eesmärk, loodava funktsionaalsuse põhiülesanne; Mis on arendusprojekti taust, probleemi või hetkeolukorra kirjeldus(Sisend arenduvajaduse vormilt); Mis on arendusprojekti skoop; Viited õigusaktidele; Huvigrupid ja kasutajate kirjeldus; Liidestused teiste infosüsteemidega; Kasutatavad klassifikaatorid. 1.1. Sõnastik Ot Kirjeldada projektis läbivalt kasutatavaid mõisteid ja lühendeid. sta rv e: Si Ühtne projekti(de) ülene sõnastik. Mõistete selgitamisel võib kasutada näiteid, mis annavad edasi mõistete sisu ning viidata dokumentidele, milles su: mõisted enim kasutusel on, kuid see ei ole kohustuslik. Ül Dokument esitatakse Tellijale kinnitamiseks jooksvalt vastavalt projektiplaanile ja projekti tegevustele. Dokument on järk-järgult täienev ning ea dokumendi lõppversioon fikseeritakse üleandmise hetkel – vastavalt projektiplaanile kas projekti vaheetappide üleandmisel ja/või lõppemisel. nd Järgnevate projektide tulemite loomisel võidakse aluseks võtta juba eelmiste projektide käigus loodud sõnastik, mida täiendatakse. mi ne: Vii Wiki te d: 2. Teenuste ja kasutuslugude dokumentatsioon Eeld Süsteemi üldine kirjeldus us dok ume ndil e: Otst Kirjeldab detailselt üleantavaid teenuseid/kasutuslugusid. arve: Sisu: Kasutuslugude kirjeldamise käigus koostatakse kõikide kasutusjuhtude kirjeldused kasutaja ja süsteemi vahelise interaktsiooni vormis. Kirjeldused luuakse mitmel erineval tasemel – kirjeldatakse süsteemi ja kasutaja vahelist interaktsiooni koos süsteemisiseste tegevustega ning kasutaja ja süsteemi objektide vahelist interaktsiooni. Kirjeldused tehakse nii tekstiliselt kui vajadusel graafiliselt (nt. activity, sequence, collaboration, usecase diagrammidena), et saada võimalikult hea ülevaade kasutusjuhtudest. Dokument sisaldab: · Kasutusloo/teenuse kirjeldust; · Ärinõudeid ja piiranguid; · Ärireegleid(teostatavaid kontrolle); · Tehnilise teenuse kirjeldust(API); · 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 jne; · Andmevahetuse teenuste kirjeldus(andmete küsimine/vastuvõtmine, turvalisus, teenuse andmestik, klassifikaatorid, xml/xsd schemad); · Protsesside UML vaated; · Feature flagide nimekiri. 2.1. Näide: 2.2. CRUD maatriks On tööriist mida kasutatakse selleks, et kaardistada kasutaja poolseid tegevusi andmebaasi tasemel. See on lühend neljast põhitoimingust, mida rakendused saavad andmetega teha: Loomine Lugemine Värskendamine/uuendamine Kustutamine Maatriks koosneb tabelist milles erinevad andmeükskused on paigutatud veergu ja CRUD toimingud on paigutatud piki teist telge. Iga maatriksi lõikepunkt näitab, kas konkreetset toimingut saab teha konkreetse andmeüksusega. 3. Arhitektuuri dokumentatsioon Eeldus Süsteemi üldine kirjeldus, teenuste ja kasutuslugude dokumentatsioon dokume ndile: 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: Dokumendis on kirjeldatud: · Topoloogia, süsteemi füüsiline arhitektuur(süsteemi komponendid – andmebaasiserver, rakendusserver, meiliserver, xtee server jne.) sh süsteemi soovituslikud näitajad komponentide kaupa: näiteks andmesidekiirused, andmemahud, protsessori kiirus, mälumaht, kettasüsteemi jõudlus jne. · Liidesed teiste süsteemidega ja sõltuvused teistest süsteemidest; · Kolmandate osapoolte poolt toodetud kasutatavad tarkvarad/riistvada mis on vajalikud süsteemi toimimiseks; 3.1. Näide: 3.2. Andmebaasi kirjeldus Eeldus dokumendile: Süsteemi üldine kirjeldus, teenuse ja kasutuslugude dokumentatsioon Otstarve: Kirjeldada andmeobjekte ja nendevahelisi seoseid. Sisu Füüsilise andmebaasi andmetabelite ja -objektide seoste diagramm koos tabelite semantika kirjeldusega kujul: Tabeli nimi Semantika PERSON Siin tabelis hoitakse inimestega seotud andmestikku.... Ja olemite omaduste kirjeldustega (andmetüübid, NULL/NOT NULL, kohutuslik, semantika, jne.)kujul: Atribuudid Tüüp NULL/NOT NULL Semantika PERSON_ID INTEGER NOT NULL Tabeli primaarvõti .... ...... ..... ..... 3.3. Näide: Loogiline andmemudel Andmebaasimudel: 4. Paigaldus ja administreerimisjuhend(TO DO) Eeldus Süsteemi üldine kirjeldus, arhitektuuri dokumentatsioon, teenuste/kasutuslugude dokumentatsioon dokume ndile: Otstarve Süsteemi paigaldamiseks ja administreerimiseks loodud dokumentatsioon. : Sisu: Juhendis on kirjeldatud sõltuvalt tarnest: · Süsteemi parameetrite(seadistuste) kirjeldus; · Logimise realisatsiooni kirjeldused(kuhu, mida, logide struktuur); · Rutiinsete hooldusprotseduuride kirjeldus(komponentide taaskäivituse vajadus parameetrite muutmisel); · Nõuded rakenduse komponentidele; · Andmete alglaadimine*; · Varundusskriptid; · Monitooringu kirjeldus. Paigaldusjuhendis kirjeldatakse iga realiseeritud osa rakendamine koos spetsiifiliste seadistustega, sh tuuakse välja esmakordsel paigaldusel vajalikud tegevused ning erisused. Paigaldusprotseduurid peavad olema kirjutatud selliselt, et TEHIK administraator suudab rakenduse paigaldada ilma kõrvalise abita. Taasteplaan vajadusel* Versiooni muudatuse kirjeldus (release notes) Otsta Anda tellijale ülevaade infosüsteemi versioonide muudatustest ja versiooni ülespaneku hetkel teada olevatest vigadest. rve: Sisu: Detailne info iga versiooniuuenduse kohta – avaldamise kuupäev, versiooni number, tehtud muudatused, viited taskidele, ülevaade teadaolevatest probleemidest, nt. vead mis ei sisaldu selles tarnes. 5. Täitja poolt teostatud testide dokumentatsioon Otsta Anda Tellijale ülevaade läbiviidud testimiste tulemustest. Testide dokumentatsiooni järgides peab olema Tellijal võimalik kontrollida süsteemi rve: nõuetekohast toimimist. Sisu: Dokumentatsioon sisaldab teostatud arenduste testimisel saadud informatsiooni: · Testiplaan; · Testlood; · Testraport; · Jms. Dokumenteeritakse iga testimise eesmärgid, tegevused ja tulemid. Teste mitteläbinud testlugudele on lisatud parandused või ülesjäänud vead. Sisaldab jõudlus- ja mahutestide infot ning versioonide infot. Automaattestide puhul antakse üle kood ning ülevaade Sonarqube’is(testide nimekiri, testide käivitamise tulemus, koodi kaetus). Viited: JIRA keskkonda kasutatakse testimispiletite haldamiseks. Andmevahetusteenuse kirjelduse mall (draft) Teenuse nimi Teenuse kirjeldus Teenuse tehniline spetsifikatsioon Päringu ja andmetöötluse arhitektuur Päringu näide Päringu väljundi vastavus päriva registri X mooduli andmetabelite väärtustega Seotud klassifikaatorid Kasutuslood Andmetöötlus Veahaldus Monitooring Ärivajadustest lähtuv monitooring Tehniline monitooring Teenuse nimi Teenuse kirjeldus Teenuse tehniline spetsifikatsioon Teenuse kirjeldus Link www.x-tee.ee dokumentatsiooni keskkonda Teenuse kood RR458 Teenuse liik SOAP/REST Teenuse WSDL x-tee.ee/catalogue-data/EE/EE/GOV/70008440/rr/173.wsdl Versioon V2 Näidis päringu tegemiseks Mis selle all mõeldi, all näide olemas Dokumentatsioon (Registripidajalt) RR458 dokumentatsioon Päringu ja andmetöötluse arhitektuur Kirjeldus ja diagramm teenusega seotud moodulitest ning nende omavahelistest suhtlustest, võiks olla valmistatud kasutades draw.io pluginat otse wikis et hilisemad täiendused oleks lihtsasti teostatavad Päringu näide Üks või rohkem näiteid päringu sisust (xml) + Sisendparameetrid NÄIDE SISEND XML Vcurl --location 'https://xtee6.test' \ --header 'Content-type: text/xml; charset=UTF-8' \ --data '<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:iden="http://x-road.eu/xsd/identifiers" xmlns:prod="ht tp://rr.x-road.eu/producer/rr" xmlns:xro="http://x-road.eu/xsd/xroad.xsd"> <SOAP-ENV:Header> <xro:userId>EE11111111111</xro:userId> <xro:id>my1XSJpzA0THmGa404Lweg</xro:id> <xro:protocolVersion>4.0</xro:protocolVersion> <xro:client iden:objectType="SUBSYSTEM"> <iden:xRoadInstance>ee-test</iden:xRoadInstance> <iden:memberClass>COM</iden:memberClass> <iden:memberCode>10364097</iden:memberCode> <iden:subsystemCode>helmesskais2</iden:subsystemCode> </xro:client> <xro:service iden:objectType="SERVICE"> <iden:xRoadInstance>ee-test</iden:xRoadInstance> <iden:memberClass>GOV</iden:memberClass> <iden:memberCode>70008440</iden:memberCode> <iden:subsystemCode>rr</iden:subsystemCode> <iden:serviceCode>RR458isikuTDkontroll</iden:serviceCode> <iden:serviceVersion>v2</iden:serviceVersion> </xro:service> </SOAP-ENV:Header> <SOAP-ENV:Body> <prod:RR458isikuTDkontroll xmlns:ns2="http://rr.x-road.eu/producer"> <request> <Isikukood>39703030012</Isikukood> <pohjus>pohjus</pohjus> </request> </prod:RR458isikuTDkontroll> </SOAP-ENV:Body> </SOAP-ENV:Envelope>'astuse näide NÄIDE SISENDPARAMEETRID Sisendparameeter Kohustuslikkus Lisainfo Isikukood Kohustuslik Isiku isikukood Pohjus Mittekohustuslik Päringu põhjus (kui see väli on täidetud, siis see kuvatakse andmejälgijas - Andmejälgija | RIA.) Päringu vastuse näide Üks või rohkem näiteid päringu vastuse sisust (xml) NÄIDE VASTUS XML <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xrd="http ://x-road.eu/xsd/xroad.xsd" xmlns:prod="http://rr.x-road.eu/producer" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:id="http://x-road.eu /xsd/identifiers" xmlns:repr="http://x-road.eu/xsd/representation.xsd" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"> <SOAP-ENV:Header> <xrd:client id:objectType="SUBSYSTEM"> <id:xRoadInstance>ee-dev</id:xRoadInstance> <id:memberClass>GOV</id:memberClass> <id:memberCode>70008440</id:memberCode> <id:subsystemCode>viisaregister</id:subsystemCode> </xrd:client> <xrd:service id:objectType="SERVICE"> <id:xRoadInstance>ee-dev</id:xRoadInstance> <id:memberClass>GOV</id:memberClass> <id:memberCode>70008440</id:memberCode> <id:subsystemCode>rr</id:subsystemCode> <id:serviceCode>RR458isikuTDkontroll</id:serviceCode> <id:serviceVersion>v2</id:serviceVersion> </xrd:service> <xrd:issue>elukohateate testimine</xrd:issue> <xrd:userId>EE47905250367</xrd:userId> <xrd:id>11ea521824f8c942c706238e71e39692d5f0190b</xrd:id> <xrd:protocolVersion>4.0</xrd:protocolVersion> </SOAP-ENV:Header> <SOAP-ENV:Body> <prod:RR458isikuTDkontrollResponse> <request> <isikukood>37704020965</isikukood>  <pohjus>1</pohjus> </request> <response> <dokumendid> <dokument> <nimetus>ELAMISLUBA</nimetus> <number>1009889467/TE</number> <asutus>POLITSEI- JA PIIRIVALVEAMET</asutus> <valjaKpv>22.04.2020</valjaKpv> <kehtibKuni>22.04.2025</kehtibKuni> <staatus>KEHTIV</staatus> <isikukood>37704020965</isikukood> <perenimi>TEHIKJK</perenimi> <eesnimi>JUKU</eesnimi> </dokument> <dokument> <nimetus>ELAMISÕIGUS</nimetus> <number>1009930329/TO</number> <asutus>POLITSEI- JA PIIRIVALVEAMET</asutus> <valjaKpv>05.01.2023</valjaKpv> <kehtibKuni>04.01.2028</kehtibKuni> <staatus>KEHTIV</staatus> <valjastamiseAlus>TA01</valjastamiseAlus> <valjastamiseAluseTekst>ELKS § 22 lg 1 TO pereliikmele</valjastamiseAluseTekst> <isikukood>37704020965</isikukood> <perenimi>TEHIKJK</perenimi> <eesnimi>JUKU</eesnimi> </dokument> <dokument> <nimetus>ELAMISLOAKAART</nimetus> <number>BD2002024</number> <asutus>POLITSEI- JA PIIRIVALVEAMET</asutus> <valjaKpv>14.05.2020</valjaKpv> <kehtibKuni>11.12.2020</kehtibKuni> <staatus>KEHTETU</staatus> <isikukood>37704020965</isikukood> <perenimi>TEHIKJK</perenimi> <eesnimi>JUKU</eesnimi> </dokument> </dokumendid> </response> </prod:RR458isikuTDkontrollResponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope> NÄIDE VÄLJUNDPARAMEETRID Väljund Andmetüüp Tingimus, kirjeldus Dokument Dokument andmete plokk. dokument.nimetus Tekst RRis dokumendi liigi nimetus. dokument.number Tekst Dokumendi number, kui puudub, siis väärtus tühi. dokument.seeria Tekst Dokumendi seeria, kui puudub, siis väärtus tühi. Päringu väljundi vastavus päriva registri X mooduli andmetabelite väärtustega NÄIDE RR458 RR458 Kommentaar DM tabel DM andmeväli DM andme Kohustu Väljund Andmetüüp tüüp slik nimetus Tekst Dokumendi nimetus RR, võimalikud väärtused vaata RR458 teenus cl . DOCUMENT_TYPE_ VARCHAR2 EI assifer DO_LIIK DOCUME CL_ID (18) NT number Tekst Dokumendi number . DOCUMENT_NUMB VARCHAR2 EI DOCUME ER (256) NT Seotud klassifikaatorid Todo Sihtregistri veakoodid - kui päringule ei saadud vastust NÄIDE Väärtus Kirjeldus 10001 Isikukoodi pikkus ei ole 11 sümbolit. 10002 Isikukoodis ei ole kõik sümbolid numbrid. 10022 Kohustuslikud sisendparameetrid puuduvad. L134 Päringu registreerimine ei õnnestunud. L120 Kohustuslikud sisendparameetrid &1 puuduvad. Sihtregistri klassifikaatorid - mille vastu töötluses enda poolel teeme kvaliteedikontrolli NÄIDE Väärtus Väärtuse kirjeldus FormOfStudy enumi kood E Eksternõpe EKSTERNOPE MS Mittestatsionaarne MITTESTATS_OPE S Statsionaarne õpe STATS_OPE K Kaugõpe KAUGOPE Kasutuslood TODO - Ehk ei ole vaja? Andmetöötlus TODO Kirjeldada üldiselt päringuvastuse töötlemise üldised põhimõtted ja detailselt kõigi väärtuste töötlemise reeglid koos võimalike vea väärtustega Töötluse kirjeldusest peab olema aru saada: Milliseid kontrolle rakendatakse Millised andmed millisel juhul ja kuhu maha kirjutatakse (moodul, tabel, veerud) Milliseid andmeid millisel juhul maha ei kirjutada - > veateated + veahaldus Veahaldus TODO Päringu vead - kui väljaminev päring on õnnestunud, aga vastuvõtja ei saanud päringut töödeldud mingi vea tõttu päringus. NÄIDE Veakood Selgitus Veateade ametnikurakenduses Töötluse tulemus RR458_IS_DOK_ISI "response": { Päring ebaõnnestus - Päring ebaõnnestus sisend andmed ei olnud KUKOOD_VIGA1 "faultCode": "10001", RR458_IS_DOK_ISIKUKOOD_VIGA1 -"Isikukoodi pikkus piisavad, teenusest andmeid ei edastatud "faultString": "Isikukoodi ei ole 11 sümbolit." pikkus ei ole 11 sümbolit." Teavita SKA Tugi. } Viga tekib kui RR458 teenus tagastab vea. RR458_IS_DOK_ISI "response": { Päring ebaõnnestus - Päring ebaõnnestus sisend andmed ei olnud KUKOOD_VIGA2 "faultCode": "10002", RR458_IS_DOK_ISIKUKOOD_VIGA2 -"Isikukoodis ei ole piisavad, teenusest andmeid ei edastatud "faultString": "Isikukoodis ei kõik sümbolid numbrid." ole kõik sümbolid numbrid." Teavita SKA Tugi. } Viga tekib kui RR458 teenus tagastab vea. Andmekvaliteedi vead - kui päringuvastuse töötlemisel ilmnevad saadud andmetes vead. NÄIDE Veakood Selgitus Veateade ametnikurakenduses Töötluse tulemus RR458_IS_DOK_NIMETUS_ <nimetus>ELAMISLUBA</nimetus> Andmetöötluse viga RR458_IS_DOK_NIMETUS_TYHI - dokumendil pu Dokumenti ei TYHI udub elemendi kood. Saadud dokumenti ei salvestatud! Teavita SKA salvestata Viga tekib juhul, kui XML-is dokument. Tugi. nimetus on tühi. RR458_IS_DOK_NIMETUS_ <nimetus>ELAMISLUBA</nimetus> Andmetöötluse viga RR458_IS_DOK_NIMETUS_VALE - Isiku Dokumenti ei VALE dokumentide töötlemisel ei leitud SKAIS2 klassifikaatori tunnust salvestata Viga tekib juhul, kui dokumendi dokumendi [nimetus] . Saadud dokumenti ei salvestatud! Teavita SKA Tugi. liigi väärtus ei leita klasifikaatorite hulgast. Monitooring Ärivajadustest lähtuv monitooring Vastavalt ärivajadustele monitooring, s.t. kirjeldada kuidas veahalduses välja tulevaid probleeme jälgida ja rakendusest väljapoole näidata. TODO üldisem mudel äriloogiliste vigade monitoorimiseks ja haldamiseks. Tehniline monitooring Minimaalne tehniline monitooring iga päringu kohta: Päringute hulk (kokku/ajaühikus) Päringute kestus Päringute tulemuste counter (OK vs veaolukord), TODO vajab eestikeelset sõna siia Teenuse otspunkti hetkeseis (töötab vs maas) Lisaks on iga päringu korral arendaja vastutus mõelda loodava teenuse spetsiifiliste monitoorimist vajavate näitajate peale tagamaks teenuse hea jälgitavus ja probleemide ennetamine.

Allikas: Tervise- ja heaolu infosüsteemide keskus dokumendiregister →