Leping

Tehnilise kirjelduse Lisa 1.2 . SKAIS2 front-end arendusreeglid Kasutajaliideses tuleb jälgida üldisi põhimõtteid, mis aitavad tagada ühtse, kasutatava ja arusaadava veebi: Üldnõuded Veebi vaated, vormid ja nende elemendid peavad olema üle veebi ühtlustatud paigutuslikku ja kujundusliku ülesehitusega. Sama tüüpi elemendid nagu näiteks nupud, lingid, sisestusväljad, tabelid jms peavad olema veebi üleselt sarnased. Sarnaste tegevuste sooritamisviisid peavad toimima sarnaselt. Näiteks nupp “Esita” peab toimina veebi üleselt ühte moodi. Kasutatud märksõnastus, sh nupu- ja vormiväljanimed, peab olema veebis ühtlustatud. Näiteks samasuguse tegevusega nupud on nimetatud ühtemoodi, sisutekstide keeleline stiil on sarnane. Sama tööloogika alusel sooritatavad toimingud funktsioneerivad sarnaselt. Näiteks kõigis toimingutes „Salvesta” nupule vajutades kuvatakse teade, et vorm on salvestatud. Erinevad toimingud peavad välja nägema erinevad. Näiteks peavad lingid, nupud, edasi liikumine, tagasi liikumine jms üksteisest erinema. Kasutajaliidese teenusedisaini ja graafilise disaini etappides tuleb lähtuda minimalismi põhimõttest – vähem on rohkem. Kasutajaliides elementide paigutamisel peab olema lähtutud vertikaalsest ja horisontaalsest sümmeetriast. Domeeninimi võiks võimalusel olla tähenduslik n ii eesti kui ka inglise keeles. Domeeninimi peab töötama ka ilma “ www “‘ta. Domeeninimi peab olema meeldejääv ja omama konteksti mõttes tähendust. Veebilehel peavad olema kergesti leitavad viited kasutustingimustele ja privaatsuspoliitikale, kuid arvestada tuleb, et tegemist ei ole lehe mõttes esmase infoga. Lehe üleselt peavad kõik elemendid, mis avavad või peidavad sisu, olema klikitaval põhimõttel, mitte ülelibisemise (hover) põhimõttel. Nõue tagab, et sisu oleks kasutatav ka puutetundlikel ekraanidel. Näiteks lisainfo avamiseks tuleb elemendil klikkida, mitte sellest üle libiseda. Kasutajaliides peab andma kasutajale andmete laadimisest teada (loader), et kasutaja saaks aru, et leht ei ole hangunud vaid toimub andmetöötlus. Page loaderina on soovitav kuvada graafilist elementi, mitte tekstilist. Põhjus selles, et juhul, kui lehe laadimiskiirus on kiire, siis kasutajal on hetkeks näidatavat graafilist elementi lihtsam haarata, kui näiteks teksti “Laen, palun oodake”. Page loaderi puhul võib probleemiks osutuda olukord, kus page loaderit näidatakse iga kord, kuid tema kuvamise pikkus sõltub lehe laadimise kiirusest. Kui leht on kiire, siis sellisel juhul pageloader justkui “vilgub”/ilmub hetkeks ja kasutaja ei saa aru, millega tegu. Sellise olukorra lahendamiseks on soovitav kasutada praktikat, kus page loader ilmub (fadein, opacity 0-1) ühe sekundi vältel (0-1sek). Sellisel juhul, kui lehe laadimine on kiirem, kasutaja page loaderit ei näe, kui lehe laadimine võtab rohkem aega, on page loader talle nähtav. Täpsemalt saab lehe laadimisest ja kolmest olulisemast tunnetuslikust limiidist lugeda Nielseni lehelt . Kasutaja peab saama kõiki enda poolt algatatud tegevusi katkestada. Näiteks sisselogimist, avalduse koostamist jms. Lisaks brauseri akna kinnipanemise võimalusele peab kasutajal olema igas vaates katkestamise/väljumise võimalus. Lisainfo ja abiinfo kuvamisel ei tohi jääda kasutajale muljet, et ta on süsteemist ära liikunud. See tähendab, et igal ajahetkel peab kasutajale näha jääma lehe üldraamistik – näiteks päis, jalus, navigatsioon jms Kasutajale peab olema lihtsasti leitav temaga seotud info “minu asjad”, kuhu alla on kokku koondatud kõik, mida süsteem tema kohta teab ja mis võib olla kasutaja jaoks relevantne. Veebi keelt vahetades peab kasutaja navigatsiooni mõttes jääma samale vaatele, millelt ta keelt vahetas. Kaaluda, millise sisu allkirjastmine on absoluutselt vajalik ja millise sisu puhul piisab kinnitusest. Näiteks tuludeklaratsiooni esitamisel ei ole vajalik deklaratsiooni allkirjastada, sest kasutaja on autenditud ja sellega on piisavalt tugev seos tekitatud kasutaja isiku ja tahteavalduse vahel. Kui kasutajal on võimalik liikuda ühest süsteemist teise, peab ta igal ajahetkel aru saama, millises süsteemis ta parasjagu on. Arusaadavust toetab vastava lehe päis, logo, lehe pealkiri jms. Domeeninimedes ei tohi kasutada kirjavahemärke. Näiteks on kasutajatele keeruline sisestada aadressi reale www.e-toimik.ee, selle asemel peaks olema võimaldatud www.etoimik.ee. Veebileht peab toetama enamlevinute veebilehitsejate ja operatsioonisüsteemide kolme viimast versiooni. V eebilehel tuleb luua automaatselt genereeritav sisukaardi fail otsingumootoritele ( XML sitemap ). Kui on veebirakendusele on tellitud administreerimisliides, siis seal peab saama: lisada ja hallata artiklite, uudiste ja kõikide muude lehe tüüpide sisu, pealkirju ning „meta“-kirjeldusi ( keyword ’e). määrata võimalikult kasutajasõbralikke, lihtsaid ja lühikesi URL -e kõikidele lehtedele (ka nendele mille sisu tuleb liideste kaudu). vaadata statistikat lehtede ja funktsionaalsuste, linkide, nuppude jms kasutaja poolt kasutatavate või tehtavate tegevuste jälgimiseks . Veebirakenduse kõik avalikud osad peavad olema otsingumootorite jaoks optimeeritud. Abiinfo Kui vormivälja täitmisel tuleb kasutajal lähtuda kindlatest reeglitest, mis ei pruugi olla koheselt ilmselged, tuleb lisada abiinfo vastava vormivälja täitmisviisi kohta. Näiteks failide laadimisel – millised failiformaadid on lubatud. Kõik erialased ja kasutajale arusaamatud terminid peavad olema lahti selgitatud. Selleks võib kasutada lehel kuvatavaid tekste või näiteks süsteemiülest sõnastikku. Lehel peab olema viide, milliste õigusaktide alusel süsteem töötab. Lehel peab olema viide, kes süsteemi haldab. Abiinfo ikoonid koos avaneva lisainfoga tuleb paigutada kohtadesse, kus kasutaja võiks vajada täiendavat selgitust. Kui abiinfo kuvamiseks on kasutatud tooltipe, siis tooltipi alast välja “klikkides” peab tooltip sulgema. Lühikeste abitekstide korral on soovitatav kasutada tooltip lahendust, mis peab olema tekstiga sobivaks vormindatud (nt tooltip ei tohi “venida” horisontaalselt ega vertikaalselt ebapraktiliselt suureks) ning pikemate abitekstide korral tuleks infot kuvada modaalaknas. Lisaks modaalakna lahendusele võib kaaluda pikemate tekstide linkimist näiteks mõnele abiinfo portaalile või teisele süsteemi alamlehele, aga mõlemal juhul tuleb need avada uuele brauseri vahelehele. Lisaks abiinfo kuvamisele vormil konkreetsete osade juures on võimalik lisada ka nö “leheülene” abiinfo, kus on konkreetse lehe kohta käiv selgitus. Samas tuleks leheüleseid abisid pigem vältida, sest see on kasutajale koormav, kuna kasutaja tahab konkreetse asja juures näha konkreetset infot. Üleüldiselt tuleks püüelda vähema abiinfo lisamisele ja intuitiivsema veebi poole. Failid Failile viitamisel/linkimisel peab olema linginime juurde lisatud failitüüp ja maht. Failide süsteemi üleslaadimisel peavad olema välja toodud lubatud failiformaadid. Failide süsteemi üleslaadimisel peab olema toodud failide lubatud maht (maht kokku ja üksiku faili maht). Failide süsteemi üleslaadimise järel peab andma kasutajale ülevaate, millised failid süsteemi lisati. Failide süsteemi üleslaadimise järel peab olema võimalik neid sealt kustutada. Kui on nõue failide digitaalseks allkirjastamiseks süsteemi sees, peab neid olema võimalik ühe toimingu raames allkirjastada korraga. Kui vormil on failide üleslaadimise võimalus, siis kasutajale peab näitama, millise sisuga dokumente oodatakse. Näiteks loetelu dokumendi liikidest – riigilõivu kviitung, hagiavaldus jms. Fondid, tekstid ja sisu Sisuteksti suurus peab olema vähemalt 12px. Teksti reavahe peab olema fondi suurusega võrreldes 1,4 korda suurem. Tekstide rööp joondusele peab olema eelistatud vasakjoondust. Nõue tuleneb inimese silma liikumise ja teksti töötlemise võimekusest. Vältida tuleb trükitähtede kasutamist rohkema, kui mõne üksiku sõna rõhutamiseks. Vältida tuleb trükitähtedes esitatud menüüpunkte, lauselõike ja pikemaid pealkirju. Rõhutatud teksti võib kasutada vaid üksikute märksõnade või fraaside esiletõstmiseks. Vältida tuleb erialaste terminite kasutamist info jagamisel, kui see ei ole võimalik, tuleb kasutajale terminid lahti seletada (vt ka Abiinfo UX102). Veebis kasutatavad pealkirjad peavad kirjeldama sisu lühidalt, konkreetselt ja sisu lahti seletavalt. Tekstide maht peab olema viidud miinimumini, sest kasutaja on valmis veebis lugema minimaalselt. Tekstilõigud peavad olema liigendatud. Sisutekstid ei tohi olla liiga pikad ja laialivalguvad. Vähemoluline, aga mahukam sisu peab olema viidud eraldi lehele ning sellele tuleb põhiosast viidata. Avalehel peab olema toodud lühikirjeldus, et oleks võimalik mõista, millisesse veebi kasutaja on jõudnud. Lühikirjeldus peab olema silmatorkavalt nähtavas asukohas. Lühikirjeldus tuleb esitada nii, et selle nägemiseks ei pea ekraanivaate kerimisriba kasutama. Loetelude kirjed peavad olema järjestatud nii, et kõige olulisemad kirjed kuvatakse eespool. Sarnastes veebitoimingutes peab kasutatama ühtlustatud märksõnu, sh nupunimetusi. Veebisisu toimetamiseks peavad olema kokku lepitud ühtsed reeglid (kes toimetab, millal toimetatakse, milline on keeleline stiil jms). Veebi sisu peab täiendatama ja muutma kasutajatelt tulnud tagasiside põhjal. Igale veebilehele peab olema lisatud eraldi tiitelpealkiri. Uudiste ja teadete juures peab olema selle lisamise kuupäev koos aastanumbriga. Kasutatud pildid ja ikoonid peavad aitama sisu paremini kirjeldada, kui nad sisule midagi juurde ei anna, tuleb need veebist välja jätta. Arvestama peab ka sellega, et pildid muudavad lehe aeglasemaks. Süsteemi nimi peab olema alati päises nähtav. Veebis peab olema läbivalt kasutatud vabavaralisi veebifonte nagu näiteks Google Fonts. Tuleks kaaluda, kas on mõistlik süsteemis kuvada erinevat sisu tulenevalt kasutajate gruppidest ja nende teadmistest. Näiteks ametnikule kuvatakse ühe sisuga veeb, tavakodanikule teise sisuga. Sisutekstides kasutada järgmisi fonte: Roboto, Roboto Condensed, Roboto Slab Nunito Open Sans, Open Sans Condensed Lato Source Sans Pro Lehel/süsteemis ei tohi kasutada rohkem kui kolme erinevat fonti. Olulisemat sisu peab saama vaadata ilma kerimisriba kasutamata. Hiire kursor (pointer/cursor) peab muutuma vastavalt sellele, missugune on tema käitumine: tekstikursor, lingi kursor jms. Millises olukorras millist kursori stiili kasutada leiab MSDN lehelt. Kirillitsa tugi peab olema tagatud venekeelse versiooni kõigil kuvadel, kirillitsas loodud sisu peab olema kuvatud korrektselt ja kujundus säilima tervikuna. Jalus Veebi jaluses peab olema kuvatud rakenduse versiooni number. Veebi jaluses peab olema lehe haldaja kontakt. Jalusele tuleb määrata minimaalne kõrgus, et vältida olukorda, kus lühema sisulehe korral jääks jalus ekraani keskele. Jalusele fikseeritud positsiooni andmise tulemusel on eesmärgiks hoida jalus alati ekraani alumises osas. Lingid Peab olema üheselt arusaadav, mis on lingi eesmärk, mida ta teeb või kuhu ta viib. Link peab paiknema sisu suhtes õigesti (vastava sisu läheduses) ja lingi nimi peab olema sisukas. Lingid peavad olema tavatekstist eristatud (ikoon, stiil, värv). Peab vältima sisutühjade nagu „siin”, “link” linginimede kuvamine. Peab vältima samanimeliste linkide kuvamine, mis viitavad erinevale sisule. Peab vältima erineva nimega linkide kuvamine, mis viitavad samale sisule. Juba külastatud linkide nimed peavad olema esitatud tavatekstist ja -linkidest erinevas värvitoonis. Veebist välja viitavad lingid peavad olema teistest linkidest eristuvalt tähistatud. Veebist välja viitavad lingid peavad avanema veebilehitsejas uuel vahelehel. Lingipealkirja kõrval kuvatav ja sellega seotud pisipilt peab olema samuti lingiks muudetud. Ehk kasutaja peab saama edasi liikuda ka pildil klikkides. Menüüpunkt ja sellega seotud ikoonike peavad linkima mõlemad samale sisule. Loeteludes, sh menüüdes peavad linginimed üksteisest visuaalselt hästi eristatud (vahed, jooned jms). Linkide pealkirjad ei tohi paikneda menüüdes rohkemal kui kahel tekstireal. Kasutada ei tohi pikemaid kui 4 sõnalisi linginimesid. Linginimedest peavad olema eemaldatud mõttetud kordused. Modaalaknad Modaalakna avades peab olema selle taha jääv taust tumendatud, et aken oleks lihtsasti eristatav ja taustal olev sisu ei tõmbaks tähelepanu. Modaalakna sulgemiseks peab sellel olema vastav nupp, lisaks peab saama akent sulgeda Esc klahviga ja vajutades hiirega modaalakna alast välja poole jäävale alale. Vältida tuleb sisu jagamist lehtedele ( paging ) ja vahelehtedele ( tabs ) ning modaalaknasse tekkivat scrolli . Navigeerimine Hetkel avatud menüüpunkt peab olema teistest menüüpunktidest koheselt eristatav. Igal veebi alamlehel peab olema selge ja arusaadav pealkiri. Veebilehe pealkiri peab olema vastava menüüpunkti pealkirjaga sarnases sõnastuses. Igal veebilehel peab olema logo, mis lingib avalehele. Igal veebilehel peab olema link avalehele. Avalehel peab olema link “avalehele” peidetud. Keerulisemates veebides peab olema kasutusel sisukaart. Sisukaart peab kajastama veebi sisukorda menüüstruktuuri põhiselt. Veebis peab olema kasutusel üks menüü. See tähendab, et sama menüü ei tohi olla kuvatud topelt, näiteks vasaku menüüna ja ülemise menüüna korraga. Menüüs peab olema kasutatud erinevaid pealkirju st erinevad menüüpunktid ei tohi olla sama nimetusega. Tagasitee tähised ( breadcrumbs ) peavad olema kasutajale kuvatud, kui kasutajal on võimalik navigeerida sügavamale, kui kaks taset. Tagasitee tähised peavad olema kuvatud iga veebilehe ülemises osas. Tagasitee tähised peavad kajastama korrektselt veebi menüüstruktuuri st samme ei tohi vahelt ära jätta. Tagasitee tähistes peavad olema menüüpunktid arusaadavalt eraldatud st tagasitee tähised ei tohi olla kuvatud sellise stiiliga, et neid võiks segi ajada menüüga. Pikema sisutekstiga lehtedel, mis sisaldavad vähemalt 6000 tähemärki ja mitut alapealkirja, peab olema eraldi sisukord (nt kasutustingimused, KKK jms lehed). Samalt lehelt samale lehele viitavaid linke olla ei tohi. Põhinavigatsiooni peab saama vaadata ilma kerimisriba kasutamata. Tagasitee tähised peavad olema linkidena, mis viivad lehel vastava sisuni. Veebilehitseja “back” nupuga peab saama veebis navigeerida. Kui lehe sisuosa on väga pikk, siis peab veebi menüü (nii ülemise menüü korral, kui vasaku menüü korral) lehe kerimisega kaasa liikuma. Kui lehe sisuosa on väga pikk, siis peab lehe kerimisel limuma “tagasi üles” nupp (lehe paremal allosas), millega kasutaja saab mugavalt suunduda lehe algusesse tagasi. Nupud Veebis peavad olema ainult nupud kujundatud nupu moodi. See tähendab, et kõik elemendid, mis ei ole nupud peavad nuppudest eristuma (näiteks lingid, menüü, teetähised ( breadcrumbs )). Nupunimed peavad olema tegevust kirjeldavad. Näiteks “Edasi”, “Salvesta”, “Tühista”, “Allkirjasta”, “Esita” jne. UX180 Ühe toimingu piires erinevate vormivaadete vahel liikudes peab kasutajal olema võimalus liikuda edasi ja tagasi, mida üldjuhul lahendatakse vastavate nuppude kuvamisega. Vormi esimeses vaates peaks olema “tagasi” nupu asemel “tühista” ja vormi viimasel vaatel “edasi” asemel näiteks “esita”. Pikemaid, kui 1-2 sõnalisi nupunimesid ei tohi kasutada. Nupud peavad olema klikkimiseks piisavalt suured ja terve nupp peab olema klikitav (mitte ainult tekst). Nupunimedest peavad olema eemaldatud mõttetud kordused. Näiteks “Esita avaldus” asemel tuleb kasutada “Esita”. Otsing Leitud otsingutulemuste pealkirjad ja sisu kokkuvõtted peavad olema üksteisest piisavalt hästi eristatatud st pealkiri ja sisu eelvaade ei tohi olla samas stiilis. Leitud tulemuste pealkirjad peavad linkima leitud sisule. Leitud failide kohta käiv info – failitüübid ja -mahud peavad olema välja toodud. Iga tulemuse juures peab olema leitud sisu lühikokkuvõte/eelvaade. Otsingutulemuste kuvamisel on eelistatud „näita rohkem“ valikut ja lehe kerimist ( scroll ) kui tulemuste jaotamist erinevatele lehtedele ( paging ) Leheülene otsing peab olema kasutajale koheselt leitav st otsing ei tohi olla menüüsse peidetud. Tavaotsing ja detailne otsing peavad olema eraldatud st kasutajal peab olema võimalus valida lihtsa otsingule lisaks ka detailset otsingut. Otsinguväli peab olema otsingutingimuste sisestamiseks piisava suurusega (vähemalt 25 tähemärki). Otsingutulemuste vaates peavad olema kuvatud otsitud parameetrid, et kasutaja näeks, mille järgi otsing teostati. Otsingutulemuste vaates peab saama otsitud parameetreid kohe muuta ja uusi sisestada. Otsingu sooritamise järel peab olema kuvatatud leitud tulemuste arv. Leitud tulemuste arv peab olema kohe nähtav st see ei tohi olla peidetud. Otsingutulemuste mitte leidmisel peab olema kasutajale kuvatatud sellekohane teade. Otsingu tegemine peab olema võimalikult lihtne ja selge. Otsinguvälju ei tohi olla palju, sest muidu võib kasutajale tekkida küsimus, kas otsingu sooritamiseks pean täitma maksimaalselt või minimaalselt otsinguvälju Võõrkeelse sisuga letedel peb otsing töötama sarnase kvaliteeditasemega nagu eestikeelsel versioonil, kuid otsingute puhul tuleb lisada selgitav info, et otsingu tulemused on valdavalt eestikeelsed, aga otsingu väljanimetused ja abitekstid on vastavalt valitud keelele. Printimine ja salvestamine Sisulehtede, mille sisu kasutaja sooviks tõenäoliselt printida või oma arvutisse salvestada, päisesse peab olema lisatud toimingule vastav tegevus (nupp, link, ikoon). Sisulehed tuleb prindida või salvestada järgides minimaalsuse printsiipi st ilmselt ei ole mõistlik print vaatesse kaasa panna menüüd jms. Printimisel ja salvestamisel tuleb lisada lehele/lehtedele väljavõtte aeg, koht (veebi aadress) ja vajadusel isiku nimi (väljavõtte tegija). Lisaks printimisele ja salvestamisele kaaluda sisu saatmise võimalust ka e-postile. Näiteks kinnistusraamatu väljavõte saatmine oma e-postile. Tabelid ja andmeplokid Tabeleid ei tohi infoga üle koormata, sest sellisel juhul muutuvad nad loetamatuks. Peab olema tehtud valik, milline info on kõige olulisem, mis koheselt tabelis kuvatakse ja vähemoluline info tuleb lisada detailinfo alla või järgnevatesse vaadetesse. Tegevused tuleb üldjuhul tabeli rea lõppu lisada. Kui on võimalik, siis tegevuste nimetuste tekstid tuleb kuvada koos ikooniga. Lehe sisuosasse, kus kasutaja soovib tõenäoliselt andmeid filtreerida ja sorteerida, lisada vastavad tegevused. Näiteks tuleks nimetatud võimalused luua andmetabelite, nimekirjade ja otsingutulemuste juurde. Tühje andmetabeleid ja andmeplokke ei tohi kuvada. Kui tühi andmeplokk tuleb ärireeglitest tulenevalt kuvada, siis ei tohi näidata tabeli päiseid, vaid selle asemel tuleb kuvada teade, et andmed puuduvad. Lehe sisu, andmeplokid ja tabelid peavad olema loogiliselt grupeeritud, sarnane sisu on koos ja erinevad plokid peavad olema visuaalselt eristatud. Pikemate andmetabelite paremaks lugemiseks võiks kaaluda tabeli ridade “triibutamist”. Andmetabelite ridade kõrgused peavad olema fondi suurus korda 1,6-1,8px. Tabeli tulpade vahel peab olema piisavalt, kuid mitte raiskavalt ruumi. Tabelis pikemate väärtuste kuvamisel on kaks võimalust: kas mitmel real osa andmetest läheb “peitu” ja lõppu kuvatakse kolm punkti. See, kumb variant valitakse sõltub sellest, kui olulised on konkreetsed andmed konteksti vaatest. Sõltuvalt tabelis kuvatavate andmete iseloomust ja sellest, kas tabelis kuvatava infoga saab tegevusi teha (avada detailsem infovaade, salvestada vms) tuleks kaaluda lisaks rea lõpus olevatele tegevustele, muuta terve tabeli rida “klikitavaks”. Sellisel juhul peab jääma vastava tegevuse viide ka rea lõppu. Selline lahendus muudaks andmete kasutamise mugavamaks. Tähelepanu tuleks pöörata kahele asjaolule: kui terve rida on “klikitav”, siis reas olevaid andmeid ei ole enam mugav hiire kursoriga selekteerida (kas seda üldse tehakse selles tabelis?) kui tabeli reaga on võimalik teha mitut tegevust nagu salvestada ja avada, siis milline tegevus tehakse real “klikkimise” tulemusel (kas on intuitiivne?). Kui lehel kuvatavad tabelid on pikad, peab lehe kerimisel tabeli päis sisuga kaasa liikuma. Teated Vormiväljad, mille täitmine sõltub mõne eelneva vormivälja täitmisest, peavad olema eristatud või algselt peidetud. Näiteks, kui tellimuste valimiseks peab olema e-post sisestatud, siis tellimused peavad olema algselt peidetud või mitteaktiivsed. Seosed vormiväljade vahel, mille täitmine on seotud mõne eelneva vormivälja täitmisest, peavad olema kasutajale esitatud üheselt arusaadavalt. Näiteks, kui tellimuste valimine sõltub e-posti välja täidetusest, siis peab olema kahe vormivälja vaheline seos kasutajale arusaadavaks tehtud. Peab olema tagatud, et kasutaja saaks kohe aru, kui valitud toimingut ei saa või pole hetkel võimalik sooritada. Näiteks kasutajal lubatakse täita avaldus, mille esitamise aeg on möödunud. Vormi täitmisel peab olema kasutusel abistavad tehnoloogiad (nt AJAX), mis annavad reaalajas tagasiside valikute võimalikkusest ja sisestatud andmete sobivusest. Näiteks kas e-post vastab formaadile, parooli valimisel tugevuse aste, postiaadresside ennustus jms. Toimingute valikud, mida kasutaja ei tohi teostada, peavad olema piiratud. Näiteks võimaldatakse otsida andmeid ja tulemused kuvatakse, aga tulemuse avamisel ilmub teade, mis ütleb, et kasutajal puuduvad õigused sisu vaatamiseks. Sel juhul peaks olema kohe piiratud otsingu teostamine, sest tulemusi ei saa niikuinii vaadata. Valesti sisestatud andmete puhul tuleb kuvada sellekohane teade. Veateade tuleb kuvada vormivälja läheduses, kus viga tekkis. Vea tekitanud vormiväljad peavad olema tähistatud, et nad oleksid eristuvad muudest vormiväljadest. Veateade peab piisavalt eristuma ülejäänud sisust ja tekitama piisavalt liikumist, et kasutaja märkaks seda. Inimese silm märkab ja reageerib liikumisele. Veateade peab olema kuvatud silmatorkavas kirjas, see ei tähenda, et kiri peab olema punane. Veateate sõnum peab olema üheselt mõistetav, et kasutaja saaks sellest aru ja tal oleks võimalik viga kõrvaldada. Süsteemi lehtedele peab olema planeeritud olulise info (nt süsteemi tõrked ja hooldustööd vms) kuvamise koht. Teadete asukoht peab olema kergesti märgatav. Veateated tuleb kuvada koheselt samal vormivaatel, kus viga tekkis. Vormis peab olema küsitud vaid sellist infot, mille küsimatajätmine takistaks toimingu sooritamist. Näiteks ei ole üldjuhul vajalik kohtusse avalduse esitamisel küsida kasutaja käest tema sugu. Kasutajale peab olema arusaadav, mis eesmärgil andmeid küsitakse. Kui küsitakse andmeid, mis ei ole koheselt seostatav eesmärgiga, tuleb kasutajale selgitada, miks neid andmeid küsitakse. Vormis peavad olema kohustuslikud väljad eraldi tähistatud. Peab olema läbi mõeldud kas vormis on küsitud vaid neid andmeid, mille sisestamine on jõukohane kõikidele kasutajatele. Näiteks, kas kõigil süsteemi kasutajatel on olemas e-post või kas kõik kasutajad oskavad valida õiget dokumendi liiki. Veebil peavad olemas olema nii 404 kui 500 lehed. Toimingu sammud Pikemate toimingute sooritamise protsess peab olema jagatud mitme ekraanivaate vahel. Toimingusammude järjestus peab olema kasutajale hästi nähtav ja jälgitav. Tuvastus Kasutaja ei pea samas süsteemis erinevate teenuste kasutamiseks end korduvalt tuvastama. Kasutaja autentimise sessiooni peab pikendama kasutaja poolt tehtud tegevuste korral. Tegevused, mille korral sessiooni pikendatakse, tuleb valida konkreetses veebis tehtavate põhitegevuste järgi, et sessiooni pikendamise sagedus oleks piisav. Sessiooni peatsest aegumisest peab kasutajat teavitama (tavaliselt 5 min enne lõppu). Kasutajale peab teada andma kui palju aega tal on veel sessiooni aegumiseni jäänud, soovitav on kasutada lahendust, kus aja vähenedes seda kasutajale ka kuvatakse ( counter ). Kasutajal peab olema võimalik pikendada sessiooni. Kasutajal peab olema võimalik loobuda sessiooni pikendamisest. Sessiooni vaikimisi pikkus peab olema optimaalne võrreldes süsteemis tehtavate tegevuste eesmärgi ja kestvusega. Peale sessiooni aegumist peab võimaldama kasutajal jätkata sealt, kus ta pooleli jäi. See tähendab, et kui kasutajale kuvatakse teade, et sessioon on aegunud, siis peab tal olema võimalus end uuesti autentida ja jätkata pooleli jäänud kohast. Peale autentimist tuleb kuvada kasutajale erinevate sisselogimise rollide valimiseks rollivalik, kui rolle on rohkem, kui üks. Näiteks juhul, kui kasutajal on lisaks oma eraisiku rollile ka ettevõtte esindaja või asutuse esindaja rollid olemas. Kui autenditud kasutajal on võimalik siseneda süsteemi vaid ühe rolliga, siis rollivalikut kuvada ei tohi. Sisseloginud kasutaja roll peab olema minimaalsuse printsiipi arvestades süsteemi päises kuvatud. Näiteks ei ole kasutajale vajalik kuvada korraga nii tema eesnime, perenime kui ka isikukoodi, sest ta teab seda juba ise ka. Küll aga peab olema võimalik eristada, kas kasutaja on eraisikuna või ametnikuna süsteemis. Vältima peab kontrollkoodi ( capcha ) küsimist. Robotite eemale hoidmiseks tuleks kasutada teisi vahendeid näiteks IP piirangud, päringute arv sekundi kohta jms. Veebi sisenemiseks ja sealt väljumiseks peab olema üks koht. Tavapäraselt asub selleks vastav nupp päises. Kasutajale ei pea kogu aeg olema kuvatud sessiooni aegumiseni jäänud aeg. Kuna sessiooni pikendatakse üldjuhul teatud tegevuste peale, siis pidevalt kuvatav sessiooni aeg ei pruugi muutuda sujuvalt ja võib seetõttu pigem tekitada küsimusi ja segadust. Vormid Eelmisesse vaatesse tagasi liikudes peavad alles jääma kõik kasutaja poolt eelnevalt sisestatud andmed. Ekraanivaadet uuendades ( refresh ) peavad alles jääma kõik sisestatud andmed. Süsteem peab kontrollima sisestatud väärtuse vastavust formaadile (e-post, telefon, kuupäev jms). Sisestusvea avastamisel peavad alles jääma kõik kasutaja poolt sisestatud andmed. Vormi avades peab olema esimene sisestusväli vaikimisi aktiivne. Vormi iga sisestusvälja juures peab olema välja pealkiri ( label ), mis peab olema joondatud vasakule. Vormipealkirjad peavad olema vormiväljade juurde paigutatud nii, et need on hetkega omavahel seostatavad. Vormipealkiri peab alles jääma ka peale seda, kui vormiväli on aktiivne ehk kasutaja on alustanud sellesse väärtuse sisestamist. Sisestusvälja vihje ( hint, placeholder ) ei tohi jätta muljet, et tegemist on sisestatud andmetega. Vormides peab saama ühelt vormiväljalt teisele liikuda tabulaatorklahvi kasutades. Tabulaatorklahviga edasi liikumise järjestus peab vastama vormi andmete tavapärasele sisestusjärjestusele. Tabulaatorklahviga peab saama liikuda ka toimingu sooritamise nupule, nagu näiteks “esita”, “edasi” jms. Enter nuppu vajutamine peab olema võrdsustatud aktiivse vormivälja juurde kuuluva tegevuse ( call to action )/ toimingu sooritamise nupu vajutusega. Valikute kastid ( radiobuttonid, checkboxid ) peavad olema valitavad tühiku klahviga. Vormidel ei tohi küsida korduvalt samu andmeid. Varasemalt sisestatud andmeid tuleb kasutada toimingute sooritamiseks korduvalt (nt e-post, isikukood jms), st samu andmeid samas süsteemis kuid erinevates vaadetes ei tohi kasutaja käest küsida. Andmeid tuleb taaskasutada. Pikemate tekstide sisestamiseks mõeldud vormiväljad peavad arvestama sisestatava sisu mahuga/pikkusega. Kasutaja peab saama mugavalt üle lugeda teksti, mida ta vormiväljadesse on sisestanud. Vabateksti välja juures peab olema näidatud järelejäänud tähemärkide arv. Tuleb vältida, et kasutaja peab vormivälja sisestatavat sisu üle kontrollima tekstiredaktoris ehk süsteem peaks kasutajale kuvama tehtud vead. Ei tohi olla vormivälju, mis jätavad mulje, et on aktiivsed, aga ei ole käsitsi muudetavad. Näiteks kuupäeva väli, mida käsitsi muuta ei saa, vaid tuleb vajutada kalendri ikooni ja kuupäev valida kalendrist. Täidetud vormivälju peab olema võimalik tühjendada ühe toiminguga. Võimalikult palju sisestusvälju peab olema asendatud valikuväljadega (nt ripploend). Kindlate ja piiritletud valikutega andmete lisamiseks peab olema välja toodud valikuvariandid. See vähendab eksimuste arvu. Näiteks tuleb vabateksti asemel pakkuda kasutajale valikuid. Enim kasutatud valikud peavad vaikimisi olema valitud. Kasutajal peab olema võimalik valikuid lisada, kui ei ole veendutud valikute ammendatuses. Kuupäeva sisestamisel peab olema võimalus valida kuupäev kalendrist. Kalendrist peab olema võimalik valida eraldi nii päeva, kuud kui ka aastat. Kalendri avanedes peab olema vaikimisi avatud optimaalseim kuupäev. Näiteks avalduse koostaja sünniaja sisestamisel ei ole mõistlik avada vaikimisi 2015 aasta kalendrit. Kasutajal peab olema võimalik kõiki enda poolt sisestatud andmeid muuta ja kustutada. Kui andmete sisestamiseks on vormid jaotatud erinevatele vahelehtedele ( tabid ), siis peavad olema eristatud vahelehed, millel mõni kohustuslik väli on veel täitmata. Kasutajale peavad olema näha kõik tema poolt sisestatud andmed. Näiteks, kui andmete sisestamiseks avaneb vormil modal ja kasutaja kinnitab andmete sisestuse ning sisestatud andmed ilmuvad vormile, tuleb kasutajale näidata kõiki tema poolt sisestatud andmeid. Värvid ja mustrid Veebis tuleb kasutada tagasihoidlike värve ja mustreid, mis toetavad teenuse sisu, mitte ei tõmba tähelepanu oluliselt ära. Lähtuma peab minimalismist ja lihtsusest. Tekst peab olema taustaga võrreldes piisavalt kontrastne, et see oleks loetav. Kontrastsuse kontrollimiseks saab kasutada vastavat tööriista . Vältima peab intensiivseid taustamustreid. Läbipaistvate taustade pealt peab tekst piisavalt välja paistma. TEHIK Lähtekoodi haldus Juhend Anti Urm 4.08.2017 Dokumendi eesmärk Kirjeldatakse ära SKAIS2 infosüsteemi arenduste käigus tekkiva lähtekoodi halduse reeglistik . Üldine kirjeldus SKAIS2 lähtekoodi hallatakse GIT tarkvaraga. Tsentraalne tarkvara lähtekoodi hoidla asub TEHIKus aadressil https://gitlab.sotsiaalministeerium.ee/skais/skais2 Iga tarkvara arendaja võib teha enda lähtekoodi hoidlasse koopiaid TEHIKu hoidlast. Tarkvara paigalduspakettide kokku ehitamine testi, prelive ja Live keskkonade jaoks toimub TEHIKu lähtekoodi hoidlast. Lähtekoodi versiooni harude haldus Peamised harud TEHIKu lähtekoodi hoidlas on kohustuslike harudena olemas Master Develop Lähtekoodi harus origin / master hoitakse Live keskkonnas oleva tarkvara lähtekoodi seisu. Lähtekoodi harus origin / develop hoitakse prelive keskkonnas oleva tarkvara lähtekoodi seisu. Kui lähtekood on saavutanud stabiilse seisu, et paigaldada see Live keskkonda, siis kõik D evelop harus olevad muudatused tuleb mestida M aster harusse ning sidistada vastava tarkvara versiooni numbriga. Toetavad harud Iga uue arenduse algul loob arendaja ühe alljärgnevatest lähtekoodi harudest Feature Release Hotfix Feature haru Väljavõte tehakse: Develop Mestimine tehakse: Develop Haru nime kuju: [projekti lühinimetus]-*, või Jira taski number Feature haru kasutatakse tarkvara uue funktsionaalsuse arendusteks. Release haru Väljavõte tehakse: Develop Mestimine tehakse: Develop ja Master Haru nime kuju: release -* Release harus kasutatakse tarkvara live mineku ettevalmistamiseks. Selles võib teostada nn viimase minuti tarkvara korrigeerimise tegevusi. Lisaks on veel lubatud pisikesi veaparandusi ning meta -andmete täiendusi. Peale tööde lõppu Release harus, peab Develop harus olema kogu vajalik lähte kood järgmisteks suuremateks arendusteks. Hotfix haru Väljavõte tehakse: Master Mestimine tehakse: Develop ja Master Haru nime kuju: hotfix -* Hotfix harus kasutatakse live keskkonnas oleva tarkvara vigade parandamiseks. Kasutatud materjalid: http://nvie.com/posts/a-successful-git-branching-model/ IT-Profiil Versioon: 1.0 Käesolev dokument (edaspidi IT-profiil) sätestab tehnilised nõuded Sotsiaalministeeriumi haldusala e-teenustele, lähtudes olemasolevatest infosüsteemidest ja infrastruktuurist. Tehnoloogilise standardi kasutuselevõtu eesmärgid: 1. haldus-, hooldus- ja koolituskulude vähendamine olemasolevale infosüsteemile; 2. tekkida võivate probleemide ja kulude minimeerimine läbi erinevate infosüsteemi osade integreerimise; 3. jätkuva arengu garanteerimine kõigile kasutatavatele infotehnoloogilistele (edaspidi IT) lahendustele Sotsiaalministeeriumi haldusalas; 4. kasutatava tarkvara ja riistvara ühtsuse saavutamine, mille abil on tsentraliseeritud hangete kaudu võimalik märkimisväärselt kokku hoida; 5. süsteemidele mõjuvate turvariskide minimeerimine; 6. tekitada süsteemide kasutajatele efektiivne, turvaline ja mugav töökeskkond. Eeltoodud eesmärkide saavutamiseks järgitakse IT toodete ja komponentide valikul järgmisi põhimõtteid: 1. sama funktsionaalsusega, kuid erinevate tootjate komponentide arv peab olema viidud miinimumini. Standard riistvara soetamisel eelistada soovitavalt ühe tootja seadmeid, mis tagab kogu IT infrastruktuuri parema toimivuse ja seadmete ühilduvuse; 2. kõik valitud tooted peavad de facto vastama kehtivatele tööstusstandarditele, kusjuures tuleb eelistada avatud standardeid; 3. testistaadiumis (beta, release candidate jne) tarkvara võib kasutada ainult testimise eesmärgil; 4. komponendid ja tooted peavad vastama asutuse poolt määratud turvareeglitele; 5. komponentide ja tootete, mis ei ole antud dokumendis kajastatud, kasutuselele võtmine vajab eelnevat arhitektuurinõukogu heakskiitu. Kehtib nii olemasolevate süsteemide uudendamise kui ka uute süsteemide loomise kohta (Applies to building brand new systems and also to refactoring existing systems) KOMPONENTIDE STANDARDID ja TEHNOLOOGIAD ÜLEVAADE (STANDARDS and TECHNOLOGIES) (COMPONENT OVERVIEW) STANDARDID TOOTJAD, TÖÖRIISTAD ja LAHENDUSED KOMMENTAARID (STANDARDS) (VENDORS, TOOLS & SOLUTIONS) (COMMENTS) TEHNOLOOGIA Eelistatud Aktsepteeritav Mitte Eelistatud Aktsepteeritav Mitte valida KOMMENTAARID KOMPONENT (TECHN (Preferred) (Acceptable) valida (Preferred) (Acceptable) (Do not select) (COMMENTS) OLOGY COMPONENT) (Do not select) Kliendi kiht (Client Layer) Lauaarvuti ja sülearvuti Windows Linux OS / keskkond macOS (Desktop & laptop client OS / environment) Lauaarvuti ja sülearvuti HTML5 HTML 4 Internet Explorer Safari kliendi kasutajaliides Firefox Native for COTS (Desktop & laptop client Chrome (commercial user interface) off-the-shelf) in special cases EDGE - ID kaardi logimine ei tööta Mobiilse kliendi OS / iOS Windows Phone keskkond Android Java application (Mobile client OS / (Java ME environment) Runtime Environment) Mobiilse kliendi HTML5 HTML HTML5 IE for mobile kasutajaliides Native App 4 packaged into Opera (Mobile client user Native app Chrome interface) Native App Safari Eelistatud Aktsepteeritav Mitte Eelistatud Aktsepteeritav Mitte valida KOMMENTAARID (Preferred) (Acceptable) valida (Preferred) (Acceptable) (Do not select) (COMMENTS) (Do not select) Esitluskiht (Presentation Layer) Portaali raamistik MS Sharepoint (Portal framework) Sisuhaldussüsteem Typo3 Wordpress (Web content Drupal management system) Esitluskihi raamistik MVC Java: JSP Microsoft .Net (Presentation framework pattern Python JSF (View)) JS: AngularJS Bootstrap Veebiserver Apache Microsoft IIS (for (Web server) Nginx Microsoft based applications) Funktsionaalne Selenium testimine (Functional testing) Eelistatud Aktsepteeritav Mitte Eelistatud Aktsepteeritav Mitte valida KOMMENTAARID (Preferred) (Acceptable) valida (Preferred) (Acceptable) (Do not select) (COMMENTS) (Do not select) Rakenduskiht (Application Layer) Rakenduse raamistik MVC Java: Spring Microsoft .Net For Javascript (Application framework) pattern JS: AngularJS include tools from Java: Digidoc4j Yeoman, Karma, Jasmine Persistence framework ORM JDO Java: MyBatis jOOQ Updates pending frameworks Hibernate Otsingumootori indeks Elasticsearch (Search Engine Index) Integratsioon SOAP AQ SOAP: Apache JMS, AQ (External integration REST JMS Axis 2 (integration to other AMQP REST: systems)) Language based frameworks AMQP: Andmete laadimine Pentaho iWay (Data Loading - ETL) Aplikatsiooniserver Java EE .NET Tomcat WildFly Java EE: (Application server) WSGI .NET: MS IIS Apache Webmethods JServ Integration Sun Java Server System Application Server SAP IBM WebSphere Oracle iAS Oracle iPlanet Web Server WebLogic Aplikatsiooni haldus JMX raamistik (Application management framework) Funktsionaalne SoapUI testimine (Functional testing) Eelistatud Aktsepteeritav Mitte Eelistatud Aktsepteeritav Mitte valida KOMMENTAARID (Preferred) (Acceptable) valida (Preferred) (Acceptable) (Do not select) (COMMENTS) (Do not select) Andmekiht (Persistence Layer / Database layer) Andmebaasi Liquibase migratsioon (Database migration) Relatsiooniline SQL PostgreSQL MariaDB (OLA: Sybase andmebaas XML (OLA: Standard) Standard) (Relational DBMS) MS SQL Server (OLA: Ärikriitiline) Oracle (OLA: Ärikriitiline) Mitterelatsioonilised MongoDB andmebaasid: NoSql, puhver, sessioonihoidla (Non-Relational DBMS: NoSql, Cache, Session store) Andmeladu Vertica Sybase IQ (Data Warehouse) Andmete replikatsioon Oracle Active PostgreSQL (Data Replication) Data Guard Londiste Postgres-BDR Eelistatud Aktsepteeritav Mitte Eelistatud Aktsepteeritav Mitte valida KOMMENTAARID (Preferred) (Acceptable) valida (Preferred) (Acceptable) (Do not select) (COMMENTS) (Do not select) Infrastruktuuri kiht (Infrastructure Layer) Directory services LDAP v3 MS Active Open LDAP Directory OpenDJ Oracle Internet Directory Autentimine Kerberos SAML MS AD (Local JASIG CAS (Authentication) Java network) Atlassian Crowd Authentication and Authorization API OAUTH Kasutajaõiguste haldus RBAC MS AD Atlassian Crowd (Authorization) Application specific Identiteedi haldus (Identity management) Konfiguratsioonihaldus SaltStack Spacewalk (Configuration MS SCCM Ansible management) Logihaldus ELK Stack (Log management) Süsteemi haldamine ja SNMP Agent Zabbix Nagios järelevalve Zabbix Oracle Inhouse built (System management agent Enterprise Cacti and monitoring) Manager Extreme Management Center Koormusjaotur Nginx F5 (Traffic management) (OpenResty) A10 Puhverdamine Varnish Squid (Caching) Tööde ajastamine Application Webmethods IS (Job scheduling) specific scheduler decision ie Quartz or cron Serveri Linux Unix Linux Debian (OLA: IBM AIX operatsioonisüsteem Windows RedHat Standard) Other UNIXs (Server OS) (OLA: Ärikriitiline) CentOS (OLA: Standard) Ubuntu (OLA: Ärikriitiline) Oracle Linux (OLA: Ärikriitiline) Windows: MS (64 bit) (OLA: Ärikriitiline) Tootja poolt viimane pikaajalise toega või stabiilne versioon Virtualiseerimine Full Paravirtualization VMWare Hyper-V (Virtualization) virtualization Xen OracleVM Serveri riistvara x86 RISC HP IBM Power (Server HW) Varundamine Centralized SW: Mitte tsentraalset (Backup) Veritas hallatavaid asju Netbackup Symantec Backup Exec HW: HP IBM Qualstar Storage HW SAN Hitachi HDS HP EVA NAS Fujitsu LAN Extreme Juniper Networks HP VPN SSL VPN PulseSecure Checkpoint IPSec Microsoft DA SAN iSCSI Brocade Fibre Cisco Channel Riistvaraline Utimaco Thales Gemalto krüptomoodul (HSM - Hardware security module) Tulemüür Juniper Checkpoint (Firewall) Eelistatud Aktsepteeritav Mitte Eelistatud Aktsepteeritav Mitte valida KOMMENTAARID (Preferred) (Acceptable) valida (Preferred) (Acceptable) (Do not select) (COMMENTS) (Do not select) Muud aspektid (Other Aspects) Programmeerimiskeeled Java .NET ja raamistikud JavaScript C/C++/C# (Programming PHP languages / framework) Python Webmethods flow iWay Functional Language Versioonihaldus GitLab SVN (Version control system) Atlassian Bitbucket Lähtekoodi analüüs SonarQube (Code analysis) Analüütika Tableau Webfocus (Analytics) Qlik Sense Oracle BI Publisher SAP® Business Objects Legend Kuidas valida? Ohutu valik Vajab Ära raiska Ohutu valik tugeva Vajab Ära raiska aega (How to select?) tugeva arhitektuuri-nõukogu aega toetusega arhitektuuri-nõukogu (Do not waste time) toetusega heakskiitu (Do not (Safe selection with heakskiitu (Safe selection (Needs Architecture waste strong support) (Needs Architecture with strong Board acceptance) time) Board acceptance) support)  KODUKORD Raamlepingu l isa 2 EESMÄRK Kodukorra ee smärgiks on täpsustada lepingu (ka nimetatud projekt) täitmisel teostatavad tegevused ning Täitja ja Tellija omavaheli ne suhtlus ning tagasiside andmise kord. Kodukorras toodud tööprotsesse võivad pooled koostöös täpsustada. Mõisted Töö – Lepingus (hankeleping või tellimuskiri) fikseeritud töö(d)/ tegevus( ed ) ja üle antav( ad ) tulem(id), mida saab testida või mille valmimist saab kinnitada Tellija. Üleandmise ja vastuvõtmise akt (Akt) - Töö üleandmist ja vastuvõtmist kinnitav dokument, mis allkirjastatakse nii Täitja kui Tellija poolt ja mis on Täitjale aluseks arve esitamiseks ning Tellijale arve tasumiseks. Teenuse kasutaja – SKA sisuosakond, kes hakkab Töös tellitud teenuseid kasutama sh testib sisulist osa. TÄITJA JA TELLIJA ÜLESANDED Täitja põhiülesanded: teostada kokkulepitud tööd kokkulepitud ulatuses , mahus ning ajakavas; koostada ja täiendada tööde teostamise eelselt ja käigus kokkulepitud dokumentatsioon; anda selgitusi teostatud töödest; konsulteerida Tellijat tööde rakendamisel; hoida Tellijat kursis tööde arengu ja hetkeseisuga ning täita muid Lepingust tulenevaid kohustusi. Vajadusel täpsustavad pooled tööde teostamise eelselt Täitja ülesandeid. Tellija põhiülesanded on: tagada Täitjale tööde teostamiseks vajalik informatsioon, dokumentatsioon ja juurdepääsud; üle vaad ata, testida ja kooskõlastada Täitja esitatavad tulemid, parandus- ja täiendusettepanekud kokkulepitud tähtaegade jooksul; tagada Tellija hallatavate infotehnoloogiliste keskkondade korrektne toimimine Tööde teostamise vältel, mis on olulised T äitja poolsete kohustuste täitmiseks. 2.4. Vajadusel täpsustavad Pooled tööde teostamise eelselt Tellija ülesandeid. ÜLDINE TÖÖKORRALDUS Arenduste läbiviimise metoodika kehtestab Tellija konkreetse hanke tingimusena. Arenduste läbiviimine toimub kas: funktsionaalsuse põhiselt, kus sisendiks on konkreetse tulemi (skoobi) tellimus, sh tähtaeg ja/või piirsumma või arendusmeeskonna töötundide põhiselt, kus arendused realiseeritakse agiilse arendusprotsessi põhimõtetel. Lepingus fikseerivad Tellija ja Täitja selle alusel tehtavad Tööd. Iga Töö osas fikseeritakse selle maht ja valmimise tähtaeg. Arendustööde puhul fikseeritakse esmase tarne tähtaeg ja Live keskkonda panemise tähtaeg. Lepingu eesmärgi saavutamiseks vajalikud tegevuste täpsem kirjeldus ja tähtajad fikseerit akse Projektiplaanis. Töökorraldus arendustööde testimisel: Täitja annab Tellijale üle omalt poolt testitud Töö. Tellija poolel testivad Tööd TEHIK kui Tellija esindaja (testib tehnilist osa) ja SKA kui Teenuse kasutaja (testib sisulist osa). Tellija esindaja ja Teenuse kasutaja testivad Tööd Testkeskkonnas ja Prelive keskkonnas. Üldjuhul viiakse Töö Testkeskkonnast Prelive keskkonda pärast vigade parandamist. Pisivigadega Tööd võib viia Prelive keskkonda, kui Tellija ja Täitja vahel on kokku lepitud pisivigade kõrvaldamise aeg. Juhul kui Töö valmib etapiviisiliselt , kuid tuleb kasutusele võtta tervikuna, toimub pärast Töö etappide valmimist ja enne L ive keskkonda panemist kogu Töö Tellija poolne vastuvõtutestimine Prelive keskkonnas ( kindlustamaks Töö nõuetele vastamine ja toimimine tervikuna ) . Tellija projektijuht otsustab, kas Töö on võimalik viia järgmisesse testimise etappi (nt Testkeskkonnast Prelive keskkonda jmt). Akteerimisele kuulub Töö , mis on edukalt läbinud vastuvõtutestimise Prelive keskkonnas . Täitja poolne (arendus)tööde teostamine ei tohi tekitada häireid Tellija mistahes teiste liidestatud süsteemide või teenuste talitluses, v.a juhul kui Täitja lähtus töö teostamisel Tellijapoolsetest juhistest ja kokkulepetest, kuid sellele vaatamata tekkisid häired. Juhul, kui töö teostamine toimub Tellija ruumides, peavad Tellija ruumides viibivad Täitja Teostajad kinni pidama Tellija sellistest sisekorraeeskirjadest, sh turvanõuetest, mida on Tellija tutvusta n ud. Lepingu täitmisest tulenev suhtlus toimub eesti keeles. TÖÖDE TEOSTAMISE MEESKOND JA VASTUTUSED Tööde teostamiseks moodustatakse projektimeeskond. Kumbki Pool nimetab tööde teostamiseks omapoolse projektijuhi. Täitja projektijuht juhib Täitja poolt tööde tulemi kokkuleppimist, vastutab tööde teostamise ajaplaani koostamise eest ning tagab kokkulepitud tööde tulemi ja ajaplaani täitmise. Tellija projektijuht juhib Tellija poolt tööde tellimuse ja ajaplaani kokkuleppimist ning tööde teostamist. Tellija projektijuhil on õigus kontrollida Lepingu täitmise käiku ning kohustus anda T äitjale töödega seotud informatsiooni ja juhiseid vastava nõude esitamisel. Kumbki Pool peab tagama, et tema projektijuhil on vajalik ajaressurss ning kõik vajalikud õigused ja pädevus vastava Poole nimel tegutseda. Projektimeeskonna liikmed (teostajad) vastutavad, et nende poolt teostatud tööd on teostatud ja dokumenteeritud vastavalt kokkulepitud töö eesmärgile ning Tellija suunistele ja nõuetele ning valdkonnas kehtivatele parimale praktikale. Kumbki Pool peab tagama, et tema kaasatud teostajal on kõik vajalikud teadmised, oskused ja kogemused ning piisav ajaressurss vastava Poole nimel töid teostada. Juhul kui tööde teostamisel ilmnevad takistused, mille tõttu vähemalt üks Pooltest ei saa kokkulepitud tegevusplaani täita, tuleb sellest koheselt informeerida mõlema Poole projektijuhte. Sõltuvalt sellest, millise ulatusega on tegevusplaani täitmise viivitus, tuleb vajadusel korrigeerida ka seotud tööde plaani. Sõltuvalt probleemi ulatusest peavad vastavad projektorganisatsiooni liikmed analüüsima tekkinud olukorra põhjusi ja vajadusel võtma tarvitusele abinõud, et ennetada sarnase olukorra tekkimist. T äitja on kohustatud kasutama tööde teostamisel Pakkumuses nimetatud meeskonnaliikmeid või asendamisel järgima raamlepingus sätestatud tingimusi. Vajadusel täpsustavad Pooled tööde teostamise eelselt meeskonnas teostajate rollid. Tellija juures töötab projekti juhtrühm, mis jälgib riigihanke raamlepingu lepingute täitmist tervikuna. LEPINGU TÄITMISEGA SEOTUD INFOVAHETUS Lepingute / Projekti täitmisega seotud dokumentatsiooni haldamiseks ja jagamiseks kasutatakse Tellija dokumendihalduskeskkonda Confluence . Dokumentide hoidmise struktuur, selle täiendused ja muudatused lepitakse kokku Poolte projektijuhtide vahel. Dokumentide lisamise, muutmise ja kustutamise reeglid lepitakse kokku Poolte projektijuhtide vahel, kes tagavad kokkulepitud reeglite järgimise oma meeskonna poolel. Konfiguratsiooni- ja arendustööde tellimiseks ja jälgimiseks, vigade ja probleemide haldamiseks ning tööaja arvestuseks kasutatakse T ellija projektik eskkonda Jira . Tellija võib lisaks Jiras registreerimisele viidata leitud vigadele ka e-kirja vm suhtluskanali vahendusel, kuid vea/tööülesandega tegelema hakkamise eelduseks T äitja poolel on vea registreerimine Jiras ning lepingus toodud nimetatud tööde eest vastutava isiku poolt antud korraldus tööde alustamiseks. Vajadusel täpsustavad Pooled tööülesannete lisamise nõuded (pealkirjad, teemad, ülesannete prioriteetide kategooriad jmt). Rakenduse lähte koodi hoidmiseks kasutatakse https://gitlab.sotsiaalministeerium.ee . Lähtekoodi haldamisel ja versioneerimisel tuleb lähtuda http://nvie.com/posts/a-successful-git-branching-model/ mudelist. Lepingu täitmisega seotud muu, igapäevane teabevahetus toimub e-kirja , telefoni, Skype teel või koosoleku vormis. Poolte projektijuhid tagavad teabe edastamise ja saamise. Teabevahetuse kord ja reageerimisajad: Koosolek – koosoleku kokkukutsumisel esitatakse päevakord ja eesmärk. Võimaluse korral lepitakse Projekti alguses kokku korralised koosolekud. Korralisi koosolekuid võib Poolte kokkuleppel tühistada (hiljemalt samal päeval 2-tunnise etteteatamise ajaga). Muude koosolekute kutsed tuleb esitada vähemalt 2 tööpäeva enne koosoleku toimumist. Iga koosoleku kohta tehakse (vastutab koosoleku korraldaja) memo, otsused protokollitakse ja saadetakse e-kirjaga koosolekul osalenutele teadmiseks/ vajadusel kinnitamiseks E - kiri – kasutatakse igapäevase suhtluskanalina (v.a kui konkreetset infot tuleb vastavalt kodukorrale edastada T äitja projektikeskkondade kaudu). Kui e- kirjale oodatakse vastust, tuleb subjekti real või kirja alguses see üheselt määratleda. Vastust eeldavale e-kirjale tuleb vastata hiljemalt järgneva t ööpäeva jooksul . Kui e-kirjale ei ole võimalik anda selle aja jooksul sisulist vastust, tuleb hiljemalt järgneva tööpäeva jooksul saata sisulise va stuse andmise aeg. Telefon, Skype – kasutatakse kiireloomuliseks ja operatiivseks suhtluseks. S kype’i kõneteenuse või telefoni kaudu kokkulepitud olulised otsused tuleb kinnituseks kas saata e-kirjaga või üle rääkida ja protokollida koosolekul. Pooled säilitavad projekti e-kirjad ja Skype vestluse d projekti ja garantiiperioodi kehtivuse ajal. Poolte projektijuhid lepivad kokku e-posti ja Skype gruppide loomise. NÕUDED DOKUMENTEERIMISELE Projekti dokumentat sioon on terviklik ja terminoloogiliselt üheselt mõistetav. Dokumentatsiooni kvaliteedi eest vastutavad Poolte projektijuhid. Nõuded dokumenteerimisele on esitatud dokumendis „Mittefunktsionaalsed nõuded“: https://wiki.sm.ee/pages/viewpage.action?pageId=3834694 plokis 8 ja selle alamdokumendis „Nõuded infosüsteemi dokumentatsioonile“: https://wiki.sm.ee/pages/viewpage.action?pageId=3834696 . ARENDUS-, TEST-, PRELIVE - ja LIVE KESKKONNAD Arenduskeskkond asub Täitja juures, kes tagab selle olemasolu ja toimimise. Täitja arenduskeskkond koosneb vähendatud võimsusega komponentidest ja peetakse üleval Täitja kulul. Täitja omab kõiki vajalikke litsentse arenduste teostamiseks. Tellija testkeskkond koosneb vähendatud võimsusega komponentidest. T äitja l on T ellija testkeskkonnale lugemisõigusega ligipääs. Tellija P relive keskkond koosneb Live keskkonnale sarnastest komponentidest, sh. a ndmebaasid, rakendusserverid ning väliste süsteemide liidesed. T äitjal puudub alaline ligipääs T ellija P relive keskkonnale. Live keskkonna konfiguratsioon lepitakse kokku arenduse käigus. T äitja l puudub ligipääs Tellija Live keskkonnale. Pooled teevad mõistlikud pingutused tagamaks, et T ellija t estkeskkond sarnaneks Live keskkonnale järgmises osas: (a) arvutivõrgu konfiguratsioon; (b) liidesed kolmandate süsteemidega; (c) Kui maksimaalne sarnasus ei ole majanduslikult põhjendatud või tulenevalt andmekaitse piirangutest, kohustub Pool informeerima teist Poolt T est- ja Liv e keskkondade disainitud erinevustest. Vajadusel lepivad Pooled kokku alternatiivse võimaluse keskkondade erinevuse puudujäägi kompenseerimiseks. K eskkondade ning nende ligipääsude haldamise ja tarnete paigalduse reegli d lepitakse kokku projekti alguses. VEA PARANDAMINE ARENDUSE, JUURUTAMISE VÕI GARANTIIPERIOODI KÄIGUS Vigade menetlemise käigus registreeritakse kõik Poolte leitud vead Jira projektikeskkonnas. Täitja analüüsib vea kirjeldust ning selgitab välja vea põhjuse. Vigadele määratakse kriitilisuse aste ning neid asutakse parandama kriitilisuse järjekorras. Garantiiperioodil asub Täitja viga parandama vastavalt Lepingus sätestatud tingimustele. KRIISISITUATSIOONIDE HALDAMINE Kriisisituatsiooniks loetakse olukorda, kus Poolte esindajad ei suuda kokkuleppele jõuda või on muutunud võimatuks võtmeisikute osalemine tööde teostamisel või ilmnenud on 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. Kriisi tekkimisel on Pool kohustatud sellest teise Poole esindajat viivitamatult kirjalikult teavitama. Kriisist väljumiseks teevad mõlemad Pooled kõik endast sõltuva kriisist väljatulekuks ja mõlemat Poolt rahuldava lahenduse leidmiseks. Kriisi vältimise ja kriisist väljumise eest vastutavad Poolte projektijuhid. Kriisi tekkel informeerib Tellija projektijuht koheselt Projekti juhtrühma, kes rakendab meetmed kriisi lahendamiseks . Kui kriisi ei suudeta P rojekti juhtrühma poolt likvideerida, kasutatakse T äitja ja Tellija vahelises lepingus sätestatud meetmeid. Osa 2 meeskonnale esitatavad nõuded 1. Osa 2 tööde teostamiseks peab pakkujal olema võimekus teostada järgmisi töid: - teenuse disain; - kasutajaliidese disain; - kasutatavuse analüüs. 2. Meeskonnas peab olema 2 liiget: - projektijuht (1); - veebidisainer/UX disainer (1). 3. Meeskonnaliikme roll ei tohi olla jagatud. Projektijuht (nimi, isikukood): Helen Kirs, 48412064718 Nõude Nõuded Kas Täpsustus selle kohta kus/millal/kuidas on nõue kood vastab täidetud. esitatud Projektidele viitamisel märkida projekti tellinud asutus, nõudele tellija kontaktisik ja projekti nimi. (JAH/ EI) Välja täitmine on kohustuslik. 1a* Omab kõrgharidust infotehnoloogia, EI 2003 – 2007, Tallinna Ülikool, andragoogika eriala majanduse või matemaatika – bakalaureus füüsika valdkonnas ja omab vähemalt 1-aastast JAH töökogemust projektijuhina IT valdkonnas. 1b* Omab vähemalt 3-aastast JAH 02.2016 - tänaseni Trinidad Wiseman OÜ töökogemust projektijuhina IT Projektijuht, äri- ja süsteemianalüütik, valdkonnas. kasutajakogemuse ekspert 08.2012 – 02.2016 Elisa Eesti AS Projektijuht – analüütik 2a Valdab eesti keelt emakeelena JAH Eestlane 2b Valdab eesti keelt Keeleseaduse lisa 1 kohasel tasemel B2. *Täita tuleb kas väli 1a või 1b.  Veebidisainer/UX disainer (nimi, isikukood): Kaire Tekku, 48312184918 Nõude Nõuded Kas Täpsustus selle kohta kus/millal/kuidas on nõue täidetud. kood vastab Projektidele viitamisel märkida projekti tellinud asutus, esitatud tellija kontaktisik ja projekti nimi. nõudele Välja täitmine on kohustuslik. (JAH/ EI) 1a* Omab vähemalt EI Eesti IT Kolledž, lõpetamise aasta 2007, IT süsteemide rakenduskõrgharidust graafilise administreerimine, rakenduskõrghariduse diplom disaini, interaktsioonidisaini või veebitehnoloogiate erialal ja omab vähemalt 3-aastast JAH töökogemust veebidisainerina. 1b* Omab vähemalt 5-aastast JAH 05.2014 – tänaseni Trinidad Wiseman OÜ töökogemust veebidisainerina. Kasutajakogemuse disainer, veebidisainer ja front-end arendaja 04.2012 – 05.2014 CGI Eesti (endine Logica Eesti) Kasutajakogemuse disainer, veebidisainer ja kasutajaliideste spetsialist, front-end arendaja 10.2009 – 12.2011 SMITi veebiteenuste haldur 09.2006 – 06.2008 Statistikaameti veebitoimetaja 2 On osalenud veebidisainerina JAH 08.2014 – 09.2016 Qlaara keskkonna väljatöötamine, vähemalt 6 veebilehe Imprimaatur OÜ, [email protected] kasutajaliidese (e-kommerts, iseteenindus või samaväärne) 03.2016 – 12.2016 SKAIS2 infosüsteemi disaini projektis viimase 3 aasta kasutajakogemuse parendamine ja analüüs/disain, jooksul. Tõenduseks esitab enda peatöövõtja Tieto Estonia AS, süsteemi tellija poolt loodud veebidisaini visuaalse Sotsiaalministeerium, [email protected] faili. 08.2017 - 02.2018 Medicumi Patsiendi broneerimissüsteemi keskkonna väljatöötamine, kujundus. Baltic Medicum. [email protected] 01.2017 – 05.2017 Elektri ja gaasi infosüsteemide arendus, süsteemi tellija Euroopa Energiaregulaatorite Agentuur (ACER), peatöövõtja TripleDev OÜ, [email protected] 06.2014 – 11.2015 Elroni piletimüügisüsteemi kasutajakogemuse parendamine/disain, peatöövõtja AgileWorks OÜ, süsteemi tellija Elron, [email protected] 05.2014 – 09.2014 MKMi iseteenindusraamistiku loomine, [email protected] 04.2017 – 08.2017 Uue eesti.ee visuaalse identiteedi lisatööd, RIA, [email protected]  12.2016 – 02.2017 Politsei infosüsteemi POLIS analüüsi, disaini ja front-end arenduse tööd, SMIT, [email protected] 01.2017 – 03.2017 Koolide veebilehtede ja kasutajakogemuse ärianalüüs/disain, HITSA, Kristi.Kadaja- [email protected] 05.2017 - tänaseni City24 kasutajakogemuse parendamine/disain ja front-end arendus, Kinnisvaraportaal AS, [email protected] 05.2017 - tänaseni Homer.ee väljatöötamine, Kinnisvaraportaal AS, [email protected] 12.2017 - tänaseni City24 kliendipäevade portaali front- end arendus, Kinnisvaraportaal AS, Karin.Noppel- [email protected] 06.2015 - 12.2015 - Tallinki iseteeninduskioskite kujundus ja arendus, Tallink Grupp AS, [email protected] 05.2015 - 06.2015 - Õhuseire keskkonna kujundus, Brainart OÜ, Rainer Nagel, [email protected] 3 On läbinud vähemalt ühe JAH On osalenud Maailma Kasutatavuse Päeva (WUD) kasutajakogemuse koolituse (esitab konverentsidel, seminaridel ning erinevatel Trinidad tunnistuse). Wisemani kasutajakogemuse disaini koolitustel. Olulisemad koolitused: • Rajiv Arjan (Google) - Sustainability-Focused Creative Problem Solving, 2016 • Eric Reiss - Usable Usability, 2016. a • Vitaly Friedman (Smashing Magazine) - Responsive Design: Clever Tips, Tricks And Techniques, 2015 • Juurdepääsetavus ja WCAG nõuded 01.02.18, Trinidad Wiseman • Service Blueprint 26.10.17 Trinidad Wiseman • PET disaini metoodika ja kasutajate mõjutamine 11.05.17 Trinidad Wiseman 4 Omab töökogemust: 4.1 veebilehtede graafilise disaini JAH 08.2017 - 02.2018 Medicumi Patsiendi loomisel broneerimissüsteemi keskkonna väljatöötamine, kujundus. Baltic Medicum. [email protected] 08.2014 – 09.2016 Qlaara keskkonna väljatöötamine, Imprimaatur OÜ, [email protected] 03.2016 – 12.2016 SKAIS2 infosüsteemi kasutajakogemuse parendamine ja analüüs, peatöövõtja Tieto Estonia AS, süsteemi tellija Sotsiaalministeerium, [email protected]  06.2015 - 12.2015 - Tallinki iseteeninduskioskite kujundus ja arendus, Tallink Grupp AS, [email protected] 4.2 persoonade loomisel JAH 03.2016 – 12.2016 SKAIS2 infosüsteemi kasutajakogemuse parendamine ja analüüs/disain, peatöövõtja Tieto Estonia AS, süsteemi tellija Sotsiaalministeerium, [email protected] 01.2017 – 03.2017 HITSA koolide veebilehtede ja kasutajakogemuse ärianalüüs/disain, [email protected] 4.3 töövoogude kirjeldamisel JAH 03.2016 – 12.2016 SKAIS2 infosüsteemi kasutajakogemuse parendamine ja analüüs/disain, peatöövõtja Tieto Estonia AS, süsteemi tellija Sotsiaalministeerium, [email protected] 01.2017 – 03.2017 HITSA koolide veebilehtede ja kasutajakogemuse ärianalüüs/disain, [email protected] 4.4 Wireframe ja prototüüpide JAH 03.2016 – 12.2016 SKAIS2 infosüsteemi loomisel (HTML5; CSS(SASS); kasutajakogemuse parendamine ja analüüs/disain, Javascript) peatöövõtja Tieto Estonia AS, süsteemi tellija Sotsiaalministeerium, [email protected] 1.2017 – 05.2017 Elektri ja gaasi infosüsteemide arendus, süsteemi tellija Euroopa Energiaregulaatorite Agentuur (ACER), peatöövõtja TripleDev OÜ, [email protected] 12.2016 – 01.2017 KIK Ohumärgid, peatöövõtja TripleDev OÜ, [email protected] 06.2014 – 11.2015 Elroni piletimüügisüsteemi kasutajakogemuse parendamine/disain, peatöövõtja AgileWorks OÜ, lõppklient Elron, [email protected] 4.5 kasutatavuse (UX) analüüside JAH 04.2017 – 08.2017 Uue eesti.ee visuaalse identiteedi teostamisel1 lisatööd, RIA, [email protected] 03.2016 – 12.2016 SKAIS2 infosüsteemi kasutajakogemuse parendamine ja analüüs/disain, peatöövõtja Tieto Estonia AS, süsteemi tellija Sotsiaalministeerium, [email protected] 05.2014 – 09.2014 20 e-teenuse detailanalüüs, MKM, [email protected] 11.2014 – 01.2015 HITSA õppeinfosüsteemi (ÕIS2) detailne kasutajanõuete analüüs/disain, Janar Mürkhain, 562 200 11 5 On osalenud vähemalt kahes JAH 03.2016 – 12.2016 SKAIS2 infosüsteemi projektis viimase 2a jooksul, kus kasutajakogemuse parendamine ja analüüs/disain, 1 Siin ja edaspidi lugeda koos märkega "või samaväärne" kui see on realistlikult võimalik. Samaväärsust peab tõendama pakkuja, kes sellele tugineda soovib.  järgiti WCAG 2.0 AA-taset ja W3C peatöövõtja Tieto Estonia AS, süsteemi tellija standardit. Sotsiaalministeerium, [email protected] 04.2017 – 08.2017 Uue eesti.ee visuaalse identiteedi lisatööd, RIA, [email protected] 6a Valdab eesti keelt emakeelena JAH Eestlane 6b Valdab eesti keelt Keeleseaduse lisa 1 kohasel tasemel B2 *Täita tuleb kas väli 1a või 1b. Veebidisainer/UX disainer (nimi, isikukood): Hardi Niilo, 38612174921 Nõude Nõuded Kas Täpsustus selle kohta kus/millal/kuidas on nõue täidetud. kood vastab Projektidele viitamisel märkida projekti tellinud asutus, esitatud tellija kontaktisik ja projekti nimi. nõudele Välja täitmine on kohustuslik. (JAH/ EI) 1a* Omab vähemalt JAH 2008 – 2011 Eesti Kunstiakadeemia, graafilise disaini rakenduskõrgharidust graafilise bakalaureus disaini, interaktsioonidisaini või veebitehnoloogiate erialal ja omab vähemalt 3-aastast JAH 03.2011 – tänaseni Trinidad Wiseman OÜ töökogemust veebidisainerina. Front-end arendaja, kasutajakogemuse disainer, veebidisainer, kasutatavuse ekspert, meeskonnajuht 06.2009 – 04.2011 vabakutseline interaktsioonidisainer, graafiline disainer, veebidisaine, front-end arendaja 1b* Omab vähemalt 5-aastast JAH töökogemust veebidisainerina. 2 On osalenud veebidisainerina JAH 08.2015 – 12.2017 shopping.tallink.ee väljatöötamine, vähemalt 6 veebilehe Tallink Grupp AS, [email protected] kasutajaliidese (e-kommerts, iseteenindus või samaväärne) 01.2016 – 04.2016 Tallink IPC tootekataloogide disaini projektis viimase 3 aasta väljatöötamine, Tallink Grupp AS, [email protected] jooksul. Tõenduseks esitab enda poolt loodud veebidisaini visuaalse 04.2012 – 08.2016 Mascus.com rasketehnika e- faili. kaubanduse veebilehe kujundus ja arendus (lisaks ka rakendused), Mascus International BV, [email protected] 06.2016 - tänaseni, SMITi UX/UI disain ja front-end tööd asutusesiseses suurprojektis, mille materjalide jagamine on keelatud. Täpsem info: [email protected] 10.2014 – 02.2015 Tallinna linna infosüsteemide stiiliraamatu (UIG) koostamine, [email protected] 03.2014 – 11.2016 PERHi infosüsteemi arendustööd, lõppklient Põhja-Eesti Regionaalhaigla, peatöövõtja Helmes, [email protected]  09.2014 – 02.2017 Qlaara kasutajakogemuse ja front-end tööd, Imprimaatur OÜ, [email protected] 11.2015 -05.2016 EMTA ETT keskkonna väljatöötamine, peatöövõtja Cybernetica AS, süsteemi tellija EMTA [email protected] 3 On läbinud vähemalt ühe JAH On osalenud erinevatel Trinidad Wisemani kasutajakogemuse koolituse (esitab kasutajakogemuse disaini koolitustel. Samuti andnud ise tunnistuse). koolitusi. Olulisemad koolitused: • Juurdepääsetavus ja WCAG nõuded 01.02.18, Trinidad Wiseman • Service Blueprint 26.10.17 Trinidad Wiseman • Axure prototüüpimine edasijõudnutele 25.05.17 Trinidad Wiseman • PET disaini metoodika ja kasutajate mõjutamine 11.05.17 Trinidad Wiseman • Sketchi kasutamise koolitus 16.02.17 Trinidad Wiseman • Axure’i prototüüpimise koolitus 09.11.16 Trinidad Wiseman • Ärivajaduste ja äriprotsesside analüüs 27.10.16 Trinidad Wiseman • Kasutajaliidese animeerimine 09.06.16, Trinidad Wiseman • UX trendid, mustrid ja head tavad 26.05.16 Trinidad Wiseman • Trendid ja intranetid 22.01.15 Trinidad Wiseman • CodeSchool: The Shape of JavaScript to Come, 2016 • CodeSchool: Powering Up With React, 2016 4 Omab töökogemust: 4.1 veebilehtede graafilise disaini JAH 08.2015 – 12.2017 shopping.tallink.ee väljatöötamine, loomisel Tallink Grupp AS, [email protected] 04.2012 – 08.2016 Mascus.com rasketehnika e- kaubanduse veebilehe kujundus ja arendus (lisaks ka rakendused), Mascus International BV, [email protected] 4.2 persoonade loomisel JAH 08.2015 – 12.2017 shopping.tallink.ee väljatöötamine, Tallink Grupp AS, [email protected] 10.2014 – 12.2014 KIK välisveebi loomine, [email protected] 4.3 töövoogude kirjeldamisel JAH 08.2015 – 12.2017 shopping.tallink.ee väljatöötamine, Tallink Grupp AS, [email protected] 04.2012 – 08.2016 Mascus.com rasketehnika e- kaubanduse veebilehe kujundus ja arendus (lisaks ka rakendused), Mascus International BV, [email protected]  4.4 Wireframe ja prototüüpide JAH 08.2015 – 12.2017 shopping.tallink.ee väljatöötamine, loomisel (HTML5; CSS(SASS); Tallink Grupp AS, [email protected] Javascript) 04.2012 – 08.2016 Mascus.com rasketehnika e- kaubanduse veebilehe kujundus ja arendus (lisaks ka rakendused), Mascus International BV, [email protected] 05.2015 – 10.2015 KIKi välisveebi prototüüpimine [email protected] 4.5 kasutatavuse (UX) analüüside JAH 08.2015 – 12.2017 shopping.tallink.ee väljatöötamine, teostamisel2 Tallink Grupp AS, [email protected] 04.2012 – 08.2016 Mascus.com rasketehnika e- kaubanduse veebilehe kujundus ja arendus (lisaks ka rakendused), Mascus International BV, [email protected] 5 On osalenud vähemalt kahes JAH 06.2016 - tänaseni , SMITi UX/UI disain ja front-end tööd projektis viimase 2a jooksul, kus asutusesiseses projektis, [email protected] järgiti WCAG 2.0 AA-taset ja W3C standardit. 03.2014 – 11.2016 PERHi infosüsteemi arendustööd, lõppklient Põhja-Eesti Regionaalhaigla, peatöövõtja Helmes, [email protected] 11.2015 -05.2016 EMTA ETT keskkonna väljatöötamine peatöövõtja Cybernetica AS, süsteemi tellija EMTA [email protected] 6a Valdab eesti keelt emakeelena JAH Eestlane 6b Valdab eesti keelt Keeleseaduse lisa 1 kohasel tasemel B2 *Täita tuleb kas väli 1a või 1b. 2 Siin ja edaspidi lugeda koos märkega "või samaväärne" kui see on realistlikult võimalik. Samaväärsust peab tõendama pakkuja, kes sellele tugineda soovib.  Hankelepingu projekt HANKELEPING nr..... Tervise ja Heaolu Infosüsteemide Keskus (edaspidi nimetatud ka Tellija ), registrikood 70009700, aadress Uus-Tatari 25/Veerenni 13 Tallinn, keda esindab põhimääruse alusel direktor Katrin Reinhold ja Trinidad Wiseman OÜ , (edaspidi nimetatud ka Täitja ), registrikood 11244225 , aadress Akadeemia tee 21/4, Tallinn , Eesti, keda esindab Ander Tenno , edaspidi koos või eraldi nimetatud ka P ool või P ooled, sõlmisid Tellija läbiviidud riigihanke s „Sotsiaalkaitse infosüsteemi arendustööd ( riigihanke viitenumber 188661 ) hankeosas I I P oolte vahel ....... sõlmitud raamlepingu alusel käesoleva hanke lepingu (edaspidi nimetatud ka Leping ) alljärgnevas: LEPINGU ESE Lepingu esemeks on Sotsiaalkaitse infosüsteem i ............. töö d ( Tellija võib hankelepinguga tellida arendustöid koos garantiiteenusega , arhitektuuri- ja arendustöid koos garantiiteenusega , hooldustöid jmt töid , mis on vajali kud Sotsiaalkaitse infosüsteemi arendamiseks – täpne hankelepingu sisu lepitakse kokku lepingu sõlmimise käigus ) (edaspidi nimetatud ka Töö d ). Tööde loetelu, T ööde teostamise tingimused ja konkreetsed realiseerimistähtajad on sätestatud Lepingu lisas 1. Lepingu Tööde maht on ... (hankelepingu sõlmimisel lepitakse kokku hankelepingu konkreetne maht kas töö tundides, fikseeritud hinnana kogu teostatava töö eest , kuutasuna vmt moel vastavalt Poolte kokkuleppele ) . Vajadusel on Tellijal õigus tellida ja Täitjal kohustus teostada Lepingu esemega seotud täiendavaid Töid kuni 20% ulatuses kokkulepitud mahust. Täiendavate Tööde tellimine ja sellega kaasnevad muudatused Lepingu täitmisel lepitakse Poolte vahel kokku vähemalt kirjalikku taasesitamist võimaldavas digitaalselt allkirjastatud vormis. LEPINGU ÜLDTINGIMUSED Pooled teevad Lepingu täitmiseks ja Lepingu ees märkide saavutamiseks koostööd. Lepingu täitmisel kohustuvad Pooled tegema kõik vajalikud pingutused, et täita Leping õigeaegselt ja vastavalt kokkulepetele , lähtudes Poolte vahel sõlmitud raamlepingus, käesolevas Lepingus ja Lepingu lisades ning õi gusaktides sätestatud kohustustest . Käesolevas hankelepingus reguleerimata osas juhinduvad Pooled raamlepingus fikseeritud tingimustest. TÖÖDE ÜLEANDMISE JA VASTUVÕTMISE KORD Täitja kohustub Töö üle andma .... ( tähtaeg ). Täitja annab Töö üle vastavalt lisas 1 kokku lepitud tingimustele, juhindudes lisaks käesolevas Lepingus sätestatule ka Poolte vahel sõlmitud raamlepingust ja selle lisadest . Töö antakse Tellijale üle koos nõuetekohase dokumentatsiooniga vastavalt raamlepingu lisale 1 .1 .1 „Nõuded infosüsteemi dokumenteerimisele“ . Vajadusel täpsustab Tellija dokumenteerimise nõudeid või nõutud dokumentide nimekirja konkreetse hanke lepingu sõlmimisel. Töö antakse üle üleandmise ja vastuvõtmise aktiga (edaspidi ka Akt ) . Koos üle antava Tööga annab Täitja Tellijale üle kõik Tööde intellektuaalse omandi õigused vastavalt raamlepingus sätestatule. TÖÖDE MAKSUMUS JA ARVELDUSTE KORD Tellija tasub üksnes Lepingu alusel tellitud, teostatud ja üle antud Tööde eest. Ü he töötunni maksumuseks Tööde teostamise l on ..... (maksumus sõnadega) eurot ilma käibemaksuta ( L epitakse kokku punktis 1.3 sätestatud Tööde mahust lähtudes . V ajadusel , nt fiksee ritud kuutasu kasutamise korral, ühe töötunni hinda eraldi välja ei tooda , vaid märgitakse fikseeritud tasu suurus ) . Tellija tasub Lepingu alusel tellitud Tööde eest kokku ..... ( maksumus sõnadega) eurot ilma käibemaksuta ( L epitakse kokku lähtudes punktis 1.3 sätestatud Tööde mahust ) . Täitjal on õigus esitada arve pärast Akti allkirjastamist. Täitja annab Tellijale arve tasumiseks tähtaja minimaalselt 30 kalendri päeva alates arve esitamisest. Täitja esitab Tellijale arve masinloetaval kujul aadressil [email protected] . LEPINGU LÕPETAMINE JA ÜLES ÜTLEMINE Leping lõpeb kohustuste täitmisega, Lepingu lõpetamise kokkuleppe sõlmimisega, muul Lepingus ettenähtud või seadusest tuleneval alusel. Tellijal on õigus Leping igal ajal üles öelda , teatades sellest 6 0 ( kuus kümmend) kalendri päeva ette. Poolel on õigus Leping etteteatamistähtaega järgimata igal ajal üles öelda, kui teine Pool on Lepingut oluliselt rikku nud või esineb raamlepingu punktis 14.4 nimetatud alus Lepingu üles ütlemiseks . Olulise lepingurikkumisena mõistavad pooled raamlepingu punktis 14.5 sätestatut. KONTAKTISIKUD Tellija kontaktisik on: …. …, telefon …., e-post: …. Täitja kontaktisik on: …, …., telefon … e-post: …. LÕPPSÄTTED Täitjal puudub volitus tegeleda Lepingu raames avalike suhetega ning anda teateid pressile, elektroonilisele meediale, üldsusele või teistele auditooriumidele, välja arv atud Tellija eelneval kirjalikku taasesitamist võimaldaval nõusolekul. Leping, Lepingu lisad ja muud selle alusel või selle täitmiseks sõlmitavad kokkulepped jõustuvad alla kirjutamisel ning kehtivad kuni Poolte kõikide kohustuste täitmiseni. Kõik teated seoses Lepingu täitmisega esitatakse e-posti või kirja teel Lepingus nimetatud aadressi l või mõnel muul aadressil, mille P ool on teisele Poolele teatavaks teinud. Informatiivset teadet võib edastada ka telefoni teel. Informatiivseks loetakse teade, millega ei kaasne iseseisvaid õiguslikke tagajärgi. Käesolevat Lepingut saab muuta Poolte kirj alikku taasesitamist võimaldavas vormis sõlmitud kokkuleppel. Kõik Lepingu muudatused tuleb sõlmida Lepinguga samas vormis ja need jõustuvad alla kirjutamisel . Kõik käesoleva Lepingu täitmisest tulenevad vaidlused ja lahkarvamused püütakse lahendada Poolte vaheliste läbirääkimiste teel. Kokkuleppe mittesaavutamisel lahendatakse vaidlus Harju Maakohtus. Lepingule kohaldub Eesti õigus. LISAD Lisa 1 - Hankelepingu eseme tehniline kirjeldus ; Lisa 2 – Tellija poolt esitatud pakkumusettepanek hankelepingu sõlmimiseks koos lisadega ; Lisa 3 – Täitja poolt esitatud pakkumus hankelepingu sõlmimiseks . Poolte allkirjad Tellija Täitja Katrin Reinhold Ander Tenno ( allkirjastatud digitaalselt ) ( allkirjastatud digitaalselt ) Pakkumuse maksumuse vorm Pakkumus 163892, pakkuja: Trinidad Wiseman OÜ (11244225) Nr Nimetus Kirjeldus Kogus Ühi Ühiku hind Maksumus KM-ta KM Maksumus KM- Märkused Ei k % ga summeeru kogu- maksumu- sele 1 Ühe töötunni hind Töö 1 48,00 48,00 20 57,60 (maksimaalne) tunnihind raamlepingu perioodil Maksumus kokku KM-ta: 48,00 Maksumus kokku KM-ga: 57,60 Kriteerium Numbri hindamine Väärtus Hanke osa  Raamleping nr 3-8/180-1 SOTSIAALKAITSE INFOSÜSTEEMI ARENDUSTÖÖD Tervise ja Heaolu Infosüsteemide Keskus (edaspidi nimetatud ka Tellija ), registrikood 70009700, aa dress Uus-Tatari 25/Veerenni 13, Tallinn, keda esindab põhimääruse alusel direktor Katrin Reinhold ja Trinidad Wiseman OÜ , (edaspidi nimetatud ka Täitja ), registrikood 11244225 , aadress Akadeemia tee 21/4, Tallinn , keda esindab Ander Tenno , edaspidi ka eraldi Pool või koos P ooled, sõlmisid raamlepingu alljärgnevas : Raamlepingu eesmärk Tellija poolt korraldatud riigi hanke „ Sotsiaalkaitse infosüsteemi arendustööd “ ( riigihanke viitenumber 188661 ) hankeosa I I alusel sõlmitud raamlepingu eesmärk on sätestada raamlepingu kehtivuse ja raamlepingu alusel tellitud tööde teostamise ajal kehtivad Poolte õigused ja kohustused ning määrata kindlaks tingimused , kuidas toimub tööde tellimine. Raamlepingus fikseeritakse Tööde tellimise tingimused ning poolte õigused ja kohustused kogu raamlepingu kehtivuse ja raamlepingu alusel tööde teostamise perioodi ks. Raamlepingu alusel t ellitavate Tööde sisu , maht ja teostamise tähtajad lepitakse kokku han k elepingus või tellimuskirjas. R aamleping ei kohusta Tellijat T äitjalt töid tellima . Raamlepingu ese Raamlepingu esemeks on Sotsiaalkaitse infosüsteemi (SKAIS) tarkvara arendamise ja kasutusele võtmisega seonduvad tööd ning tarkvara hooldustööd (edaspidi nimetatud ka tarkvara arendustööd või Tööd ), mida Täitja kohustub teostama lähtudes raamlepingu alusel sõlmitud hankelepingu s või tellimuskirjas kokku lepitud tingimustest. Käesoleva raamlepingu alusel teostatakse vähemalt k asutajaliideste disainimine ametnikule, isikule ja teenuseosutajale , sh teostatakse järgmised Tööd: UX-i analüüs; UI (kasutajaliidese disain), sh: Kujunduselemendid Ekraanivormide näidised; Olemasoleva stiiliraamatu muutmine ja täiendamine vastavalt äri- ja UX analüüsi tulemitele; Uute teenuste arendusprotsessis arendaja poolt teostatud HTML prototüüpide üle vaatamine, nõuetele vastavuse kontrollimine ja kinnitamine. Raamlepingu punkti 1.3 alusel ei kohustu Tellija konkreetseid Töi d tellima. Punktis 2.1 välja toodud T ööd e tellimused täpsustatakse raamlepingu alusel sõlmitavate hankelepingute või tellimuskirjade alusel tellimuste esitamisega, samuti võib Tellija lisaks tellida eelpool nimetatud Töödega seonduvaid Töi d. Tööde teostamisel lähtutakse lisaks käesolevale raamlepingule hankelepingu või tellimuskirja (edaspidi koos nimetatud ka Leping ) tingimustest ja kehtiva kodukorra regulatsioonist . Tööde teostamise täpsed tingimused lepitakse kokku Tööde tellimisel Lepingus . Käesoleva raamlepingu juurde kuuluvateks lahutamatuteks osadeks loetakse riigi hanke alus dokumendid, T ellija riigi ha nke käigus antud selgitused ja T äitja riigi hankes esitatud pakkumus. LEPINGU ÜLDTINGIMUSED Pooled teevad Lepingu täitmiseks ja Lepingu eesmärkide saavutamiseks koostööd. Lepingu täitmisel kohustuvad Pooled tegema kõik vajalikud pingutused, et täita Leping õigeaegselt ja vastavalt kokkulepetele, lähtudes Poolte vahel sõlmitud raamlepingus ja Lepingu lisades ning õigusaktides sätestatud kohustustest. Tellija eeldab, et Täitja on Lepingu esemeks olevate Tööde tarkvaraarenduse valdkonna professionaal, kes saab aru ning võtab teadlikult enda kanda Lepingu funktsionaalsete ja mittefunktsionaalsete nõuete täidetavuse ja tulemuse saavutatavuse riski. Sellest tulenevalt laieneb Täitjale ka selliste Tööde tegemise kohustus, mida ei ole Lepingus otsesõnu kokku lepitud, kuid mis oma olemusest lähtuvalt kuuluvad Lepinguga seotud Tööde hulka ja pidid olema Täitjale kui professionaalile ettenähtavad riigihankes pakkumuse esitamisel ning mis on Lepingu täitmiseks vajalikud. Nimetatud Tööde tegemine ei kuulu teistsuguse kirjaliku kokkuleppe puudumisel eraldi tasustamisele ning Täitja teostab kirjeldatud Tööd Lepingu täitmise raames. Töö käigus tuvastatud vastuolu korral teavitab Täitja vastuolu esinemisest viivitamatult Tellijat. Tööde teostamisel juhindub Täitja Tellija poolsetest suunistest ja Tellija tahtest Lepingu eesmärkide saavutamisel , pöördudes juhiste saamiseks või läbirääkimisteks vajadusel Tellija poole. K ui Tööde teostamisel (s h vigade kõrvaldamisel) tekivad Täitja ja Tellija vahel erimeelsused, lähtutakse Lepingu eesmärkidest Tellija seisukohalt. Tellijal on õigus jooksvalt Lepingu täitmist kontrollida. Tellijal on õigus anda Täitjale suuniseid Lepingu täitmiseks ning Täitja kohustub neid järgima. POOLTE ÕIGUSED JA KOHUSTUSED Täitja kohustub: teostama Tööd Lepingus kokkulepitud tingimustel ja ulatuses , sh tagama Tööde õigeaegse alustamise, teostamise, valmimise ja Tellijale üleandmise; järgima Tööde teostamisel Poolte jaoks kohustuslikke dokumente ; täitma kõiki Tellija juures kehtivaid ja õigusaktidest tulenevaid andmekaitsealaseid ja andmete turvalisust puudutavaid eeskirju, kui need on Täitjale teatavaks tehtud; pidama kinni raamlepingus kokkulepitud konfidentsiaalsuskohustusest ja muudest raamlepingu tingimustest; tagama Tööde teostajate kõrge professionaalse taseme ning vajalike tehnoloogiate ja metoodika väga hea tundmise vastavuses hankemenetluse alusdokumentides meeskonnale esitatud nõuetele kogu Lepingu täitmise perioodi jooksul; saama Tellija poolse kirjaliku nõusoleku Töid teostavasse meeskonda kuuluva meeskonnaliikme asendamiseks ning esitama Tellijale uue meeskonnaliikme kompetentsi (riigihanke alusdokumentides esitatud nõuded) tõendavad dokumendid; asendama Tellija nõudmisel meeskonnaliikme juhul, kui isik osutub Tellija põhjendatud arvamuse kohaselt lepingujärgsete ülesannete täitmiseks ebakompetentseks või ebasobivaks või kui tema lepingujärgsete ülesannete täitmine kahjustab pidevalt Lepingu korrektset ja õigeaegset täitmist. Täitja kannab kõik asendusest tulenevad või sellega kaasnevad kulud; teostama Tööd kuni kokku lepitud Tööde üleandmise ja vastuvõtmiseni oma ressursside arvel ning pidama arve esitamisel kinni Poolte vahel kokku lepitud Tööde maksumuse suurusest ja maksetingimustest; kasutama Tööde teostamisel Tellija tööajahalduse ja projektijuhtimiskeskkondi juhindudes kehtivast kodukorrast; pöörduma juhiste saamiseks Tellija poole, kui need o n Tööde teostamiseks vajalikud, samuti teavitama Tellijat koheselt kõikidest asjaoludest, mis mõjutavad Tööde teostamist või Täitja poolsete muude L epinguliste kohustuste täitmist. Täitjal on õigus: saada Tööde teostamise eest Lepingus kokkulepitud ulatuses ja korras tasu; asendada Tellija eelneval kirjalikul nõusolekul meeskonnaliikmeid tingimusel, et meeskonnaliikmed asendatakse vähemalt samaväärse kompetentsiga isikutega, kes vastavad kõikidele raamlepingu alusdokumentides meeskonnaliikmetele esitatud nõuetele ; kasutada Tööde teostamisel allhankijaid ( pidades silmas, et kasutatavad meeskonnaliikmed peavad vastama kõikidele raamlepingu alusdokumentides meeskonnaliikmetele esitatud nõuetele ) , kooskõlastades allhankijate kasutamise eelnevalt Tellijaga ning pidades silmas, et allhankijate tegevuse ja tegevusetuse eest vastutab Tellija ees Täitja . Tellija kohustub: tasuma Täitjale nõuetele vastavate Tööde teostamise eest Lepingus kokkulepitud ulatuses ja korras pärast Tööde üleandmise ja vastuvõtmise akti allkirjastamist; tagama Täitjale ligipääsu Tööde teostamiseks vajaliku le informatsiooni le ja vastama Täitja küsimustele seoses Lepingu täitmise või Lepingu alusdokumentide tõlgendamisega 3 (kolme) tööpäeva jooksul ; võtma Tööde üleandmise ja vastuvõtmise aktiga vastu Täitja poolt üle antud puudusteta Tööd mõistliku aja jooksul või vastavalt Lepingus sätestatud tähtajale ; teavitama Täitjat üle antud Töödes esinevatest puudustest ning kohustusest puudused kõrvaldada, andes vajadusel selleks täiendava tähtaja, kui tähtaeg ei tulene muudest kokkulepetest . Tellijal on õigus: kontrollida jooksvalt Tööde teostamise käiku andes vajadusel juhiseid, mis ei välju Lepingus sätestatu raamest ega moonuta Lepingu sisu ning on mõistlikud ja vajalikud Lepingu eesmärgi saavutamiseks; nõuda Täitja meeskonnaliikme asendamist juhul, kui isik osutub Tellija põhjendatud arvamuse kohaselt lepingujärgsete ülesannete täitmiseks ebakompetentseks või ebasobivaks või kui tema lepingujärgsete ülesannete täitmine kahjustab pidevalt Lepingu korrektset ja õigeaegset täitmist; keelduda osaliselt või täielikult tasu maksmisest, kui Täitja ei teostanud Töid kokku lepitud tähtajaks või vastavuses Lepingule ja selle juurde kuuluvatele dokumentidele ning Täitja poolne Lepingu rikkumine ei ole objektiivselt põhjendatud (nt on Tööde teostamine viibinud Tellija või kolmanda osapoole tegevuse tõttu) ; nõuda Täitjalt tekkinud kulutuste ja kahju hüvitamist, kui Täitja poolne Lepingu mittetäitmine või mittekohane täitmine on toonud Tellijale kaasa kulutusi , v.a kui rikkumine oli põhjustatud Tellija või kolmanda osapoole tegevusest ; öelda Täitja poolse olulise L epingu rikkumise korral raamleping ja/ või Leping igal ajal üles ja nõuda lepingu ülesütlemisega kaasnevate kulutuste ja kahju hüvitamist täies ulatuses . NÕUDED DOKUMENTATSIOONILE JA KASUTUSJUHENDITELE Tööde dokumentatsioon ja kasutusjuhend id peavad tagama Tellijale võimaluse tulevikus parandada ja arendada Tööde tulemit, samuti koolitada ja juhendada oma töötajaid Tööde kasutamisel. Tööde dokumentatsioon peab olema laetud üles Tellija määratud keskkonda. Täitja kohustub lähtekoodi dokumenteerimisel juhinduma raamlepingu lisast 1 .3 „ Lähtekoodi halduse kirjeldus“ . T ööde käigus loodud lähtekood peab olema kirjutatud ja dokumenteeritud selliselt, et vajadusel oleks Tellija või kolmas isik võimeline aru saama tarkvara loogilisest ülesehitusest ning jätkama lähtekoodi arendusega, juhindudes Riigi Infosüsteemi Arhitektuuri nõuetest. Tööde tulem peab olema dokumenteeritud konkreetsete Tööde iseloomust lähtudes , juhindudes kehtivas kodukorras ning raamlepingu lisades 1 .1 „Mittefunktsionaalsed nõuded“ ja 1 .1 .1. „Nõuded infosüsteemi dokumenteerimisele“ sätesta tust . Raamlepingu hind Riigih anke hinnapakkumuses pakutud Tööde ühe töötunni maksimaalne maksumus ilma käibemaksuta fikseeritakse kogu raamlepingu keht ivuse ajaks eeldatava mahuga kuni 1 000 000 ( üks miljon ) eurot ( ilma käibemaksuta) . Täitjal ei ole lubatud raamlepingu keht ivuse ajal punktis 6 .2 sätestatud ühe töötunni maksimaalset hinda tõsta. Tööde teostamise maksimaalne ühe töötunni hind käibemaksuta on 48 , 00 ( nelikümmend kaheksa eurot ) eurot. Vajadusel on Tellijal õigus raamlepingu mahtu kuni 20% ulatuses suurendada . Täitja meeskond Täitja tagab riigi hankes pakkumusega esitatud meeskonnaliikmete (Lisa 3 ) osalemise T ööde teostamisel, v . a juhul , kui Täitjast mittesõltuval asjaolul ei ole seda võimalik teha ja meeskonnaliige on asendatud Tellija nõusolekul hankemenetluses esitatud tingimustele vastava uue meeskonnaliikmega. Täitja võib komplekteerida täie ndavaid meeskondi juhul, kui riigi hanke s pa kkumusega esitatud meeskonnaliikmed on tellitud T ööde täitmisega hõivatud. Täiendava meeskonna saab luua Tellija nõusolekul juhul, kui täiendav ad meeskon naliikmed vasta vad hankem enetluses esitatud tingimustele . TÖÖDE tellimine Tööde teostamiseks sõlmib Tellija T äitjaga hankelepingu(d) , milles määratakse Tööde täpne sisu ja üle antavad tulemid (T ööde loetelu), Tööde maht, konkreetne realiseerimist ähtaeg jm olulised tingimused. Hankelepingu sõlmimiseks esitab Tellija T äitja te le pakkumuskutse ja annab mõistliku aja pakkumuse esitamiseks, arvestades tellitavate T ööde keerukust ja pakkumuse esitamiseks vajalikku aega . Pakkumuse esitamisel tuleb järgida kõiki pakkumuskutses esitatud nõudeid. Tellijal on õigus pidada Täitja ga kirjalikus vormis või protokollituna läbirääkimisi ning küsida täiendavaid kinnitusi ja andmeid T ööde osutamiseks vaj alike eelduste olemasolu kohta. Tellija sõlmib Täitjaga hankelepingu vastavalt pakkumuskutse tingimustele . Täitja kohustub hankelepingu allkirjastama hiljemalt 3 (kolme) tööpäeva jooksul hankelepingu allkirjastamiseks saamisest. Tööde tellimiseks eeldatava mahuga vähem kui 2 0 000 ( kakskümmend tuhat) eurot ilma käibemaksuta , võib Tellija esitada Täitjale tellimuskirja. Täitja esitab Tellijale omapoolse kinnituse tellimuskirja vastu võtmise ja valmisoleku kohta tellimuskirja alusel Tööde teostamisega alustamise osas . Tellimuskirja alusel T öö de teostamisega alustamiseks esitab Tellija Täitjale kinnituse . TÖÖDE ÜLEANDMINE JA VASTUVÕTMINE Tööde üleandmise ja vastuvõtmise täpne kord, Tööde teostamise etapid ja tähtajad ning Tööde testimiseks esitamise tähtajad ja kord lepitakse Poolte vahel kokku Lepingu sõlmimisel , juhindudes muuhulgas kehtivas kodukorras sätestatust . Täitja kohustub Tööd üle andma hankelepingus kokkulepitud tähtaegadel ja tingimustel . Tööde lahutamatuks osaks, mis tuleb üle anda koos Töödega , on Tööde juurde kuuluv nõuetekohane dokumentatsioon (sh kasutusjuhendid) ja intellektuaalomandi õigused . Tellija võtab Tööd vastu üleandmise ja vastuvõtmise aktiga ( edaspidi nimetatud ka Akt ) pärast edukat v astuvõtutestimist kehtivas kodukorras sätestatud tingimustel . A kt peab olema mõlemapoolse lt allkirjasta tud . Tellija võib Tööd vastu võtta, kui Töödes esineb üksikuid ja Tellija jaoks väheolulisi pisivigasid , mis fikseeritakse vastuvõtmisel Aktis . Tellija poolne pisivigadega Tööde vastuvõtmine ei vabasta Täitjat kohustusest vead Tellija poolt määratud mõistliku tähtaja jooksul kõrvaldada ning üle anda vigadeta Tööd. Tellija teavitab Täitjat testimise käigus avastatud vigadest , andes Täitjale mõistliku tähtaja vigade parandamiseks enne Tööde teistkordset ül e andmist. Töödes ilmnevates vigades eristatakse järgnevaid kriitilisuse astmeid: k riitiline viga – T arkvaral põhinev teenus või süsteem ei toimi ega ole kasutatav, näiteks on andmed rikutud; esineb kasutajasessioonide ebanormaalne katkemine; probleem mõjutab süsteemi käideldavust ja andmete terviklikkust ; mõjutatud on enamus Tarkvara kasutajatest; vastukaal probleemi vältimiseks praktiliselt puudub; tõsine finantsmõju; h äiriv viga – T arkvaraga seotud probleem ei sega teatavate reservatsioonide järgimisel igapäevast töötamist; mõjutatud ei ole kõik Tarkvara kasutajad; väiksema tähtsusega funktsionaalsused pole käideldavad, kasutatavad või süsteemi jõudlus on madalamal maksimaalsest nõudest; eksisteerib ajutine aktsepteeritav vastukaal probleemi vältimiseks. p isiviga - väikesed puudused minimaalse mõjuga Tööde kasutajatele või klientidele; kosmeetilised probleemid (ekraanikomponendid on nihkes, kuid see ei takista komponendi eesmärgipärast kasutamist); pikaajaline vastukaalu kasutamine kasutajatele vastuvõetav. Tööde testimise käigus avastatud ja Täitjale raporteeritud vead parandab Täitja omal kulul, teavitades vigade parandamisest Tellijat. Kui Täitja annab vigade parandamise järgselt üle Tööd, milles Tellija vastuvõtutestimise käigus esineb jätkuvalt vigu (teistkordne vigadega Tööde üleandmine) , võib Tellijal otsustada, kas anda Täitjale uus tähtaeg vigade parandamiseks , kõrvaldada vead ise või kolmanda isiku kaasabil, vähendades Täitjale makstavat tasu võrdeliselt vigade parandamiseks tehtud kulutustega. Kõigi Lepingu järgsete Tööde vastuvõtmise ajaks loetakse kõigi Lepingu alusel teostatud Tööde osas viimase Akti allkirjastamise aeg. INTELLEKTUAALNE OMAND Täitja kinnitab Lepingu allkirjastamisega, et talle kuuluvad Tööde teostamiseks vajalikud autoriõigused, litsentsid ja muud intellektuaalse om andi õigused, mis on vajalikud L epingu järgsete Tööde teostamiseks ja õiguste loovutamiseks Tellijale ning nende suhtes ei ole õigusi ega nõudeid kolmandatel isikutel. Tasu autoriõiguste loovutamise ning litsentsi andmise eest sisaldub Lepingu hinnas. Täitja loovutab Tellijale Tööde teostamise käigus loodud Tööde kõik autori varalised õigused ning annab lihtlitsentsi autori isiklikele õigustele koos all-litsentsi andmise õigusega kogu autoriõiguste kehtivuse ajaks ilma geograafiliste piiranguteta. Täitja tagab, et isiklikud õigused on ilma Täitja nõusolekuta teostatavad muuhulgas järgnevas ulatuses: Tellijal on õigus Tööd kasutada mis tahes eesmärgil ja viisil; Tellijal või Tellija tellimusel kolmandatel isikutel on õigus teha üle antud Töödes muudatusi ning neid täiendada; Tellijal või Tellija tellimusel kolmandatel isikutel on õigus teostatud Tö id muuta või Tö ödele lisada Tellija või kolmandate isikute poolt loodud Töid ; Tööde üleandmisega Tellijale kinnitab Täitja, et Tööd on üldsusele avaldamiseks valmis. Täitja tagab Tellijale kõik vajalikud õigused Lepingu täitmise käigus loodava Töö kontrollimiseks, testimiseks ning süsteemi paigutamiseks ka ajal, mil Tööd on vastuvõtutestimiseks üle antud, kuid ei ole veel Tellija poolt Aktiga vastu võetud. Käesolevas alapeatükis sätestatud õigused ja litsentsid loetakse Tellijale lõplikult üle läinuks pärast Töö vastuvõtmist. Täitja kohustub lahendama kõikvõimalikud lepingujärgsete Töödega seotud intellektuaalse omandi õigustest tekkivad vaidlused kolmandate isikute või oma töötajate või koostööpartneritega , v.a. juhul, kui tarkvara või tarkvara osa litsentside soetamise kohustus oli Tellijal või kolmandal osapoolel . Juhul, kui eeltoodust tekib Tellijale rahaline või muu kohustus või juhul, kui Tellija on kohustatud lõpetama Lepingu alusel teostatud ja vastuvõetud Tööde kasutamise, on Tellijal õigus nõuda Täitjalt sellega kaasneva rahalise või muu kohustuse täitmist ja/või samaväärse Töö loomist ilma täiendavat tasu nõudmata võimalikult lühikese aja jooksul, hoidudes mistahes viivitustest tarkvara arendamises, kasutuselevõtmises ja kasutamises Tellija poolt. Juhul, kui Täitja ei täida punktis 10.7 nimetatud kohustust mõistliku aja jooksul, on Tellijal õigus nõuda kogu kahju hüvitamist, mis on Tellijale kaasnenud või kaasneb Täitja poolt kohustuse mittenõuetekohase täitmisega. GARANTII Täitja annab Lepingu alusel teostatud Töödele garantii 12 ( kaksteist ) kuud , mis hakkab kulgema kõigi Lepingu alusel teostatud Tööde üleandmisest (viimase lepingujärgsete Tööde Akti allkirjastamisest alates). Juhul , kui Töö teostamine on kokku lepitud etapiviisiliselt , algab garantiiperiood Töö etapi osas selle toodangukeskkonnas kasutuselevõtust alates . Kui T ellija ei võta töid toodangukeskkonnas kasutusele 3 (kolme) kuu möödumisel tööde vastuvõtmisest alates, algab garantii nimetatud aja möödumis el alates tööde vastuvõtmisest. Garantiiga on hõlmatud kõik tarkvaras ilmnevad vead, mis ei ole tekkinud Tellija või kolmandate osapoolte tegevuse tagajärjel. Täitjale peab saama edastada teateid garantiiga hõlmatud vigade ilmnemise kohta vastavalt kehtiva kodukorra regulatsioonile garantiist tulenevate õiguste teostamiseks igal tööpäeval vähemalt ajavahemikul kell 8:00 kuni 17:00. Garantiikohustusega hõlmatud vea ilmnemisel teavitab Tellija Täitjat veast, edastades kogu teabe, mis Tellijal on vea ja selle tekkimise olukorra ning võimalike põhjuste kohta . Tellija määra b võimalusel, milline on vea kriitilisuse aste või kas tegemist on muu garantiikohustusega hõlmatud puudusega ning määrab vea kõrvaldamiseks tähtaja, lähtudes punktis REF _Ref494457058 \r \h \* MERGEFORMAT 9 .7 fikseeritud vigade kriitilisuse astmetest. Kui tegemist on k riitilise veaga, teatab Täitja hiljemalt 24 ( kahekümne nelja ) tunni jooksul alates k riitilise vea kohta teate saamisest oma esialgse hinnangu k riitilise vea võimalike põhjuste kohta ning juhtnöörid, kuidas Tööde tulemit edasi kasutada . Täitja peab kaasama k riitilise vea kõrvaldamisse nii palju spetsialiste, et eelduslikult võiks k riitiline viga saada kõrvaldatud 3 ( kolme ) t ööpäeva jooksul alates vea kohta teate saamisest. Kui tegemist on h äiriva vea, pisivea või muu garantiikohustusega hõlmatud puudusega, teatab Täitja hiljemalt 48 ( neljakümne kaheksa ) tunni jooksul alates selle kohta teate s aamisest oma esialgse hinnangu h äiriva vea, pisivea või muu puuduse võimalike põhjuste kohta ning vajadusel juhtnöörid, kuidas Tööde tulemit edasi k asutada . Täitja peab kaasama h äiriva vea, pisivea või muu puuduse kõrvaldamisse nii palju spetsialiste, et eelduslikult võ iks nimetatu saada kõrvaldatud 10 ( kümne ) tööpäeva jooksul alates teate saamisest. Täitja garantiist tuleneva te kohustuste täitmine on arvestatud Lepingus kokkulepitud tasu hulka. Juhul, kui Täitja tõendab, et kõrvaldatud viga või muu puudus ei olnud Lepingu garantiiga hõlmatud, hüvitab Tellija Täitja kantud otsesed kulud seoses nimetatud vea või puuduse kõrvaldamisega. Kulude hüvitamisel võetakse aluseks Lepingus, mille raames teostatud Töödes on viga või puudus ilmnenud, fikseeritud Tööde teostamise ühe töötunni hind . Tellija tagab Täitjale kaasaabi garantiikohustuse alla käivate vigade ja puuduste kõrvaldamisel Tellija võimekuse ja võimaluste piires . Kui Täitja ei suuda vig asid või puuduseid kokkulepitud tähtajaks kõrvaldada, võib Tellija nimetatud ise kõrvaldada või korraldada nende kõrvaldamise kolmanda isiku kaasabil , teavitades sellest Täitja le . Tellijal on õigus Täitja lt nõuda mõistlike kulutuste hüvitamist , mis tekkisid seoses eelkirjeldatud viisil vea või puuduse kõrvaldamisega , kui tegemist oli vea või puudusega, mis oli garantiiga hõlmatud . Garantii kaotab kehtivuse, kui Tellija muudab Täitjaga kooskõlastamata lähtekoodi, välja arvatud Tööde osale , mida ei ole muudetud, kui Tellija suud ab eristada lähtekoodis tehtud muudatusi. Garantiiga ei ole hõlmatud: h ooldus- ja arendustööd, mis ei ole tingitud vajadusest kõrvaldada punkti s 9.7 nimetatud vigasid või kokku lepitud tingimustele mittevastavusest tulenevaid puudusi; ekspluatatsioonihäirete kõrvaldamine, mis on põhjustatud Tellija või kolmanda isiku poolt Tööde juhuslikus t või tahtlikust kahjustamisest. POOLTE VASTUTUS Pooled vastutavad oma lepinguliste kohustuste rikkumise eest, välja arvatud, kui rikkumine on vabandatav. Rikkumine on vabandatav, kui esineb vääramatu jõud. Pool vastutab teise Poole ees muuhulgas Lepingu rikkumise eest, mis tuleneb Poole poolt Lepingu täitmisele kaasatud isikute tegevusest või tegevusetusest (sh allhankijate tegevuse eest, keda Täitja tööde teostamise kasutab) . Pool ei vastuta l epingu liste kohustuste rikkumise eest, mis tulene s teise Poole kohustuste rikkumisest või kolmandate isikute tegevusest või tegemata jätmistest . Nimetatud asjaolu esinemist peab tõendama Pool, kes sellele tugineda soovib. Poole lepingulise kohustuse rikkumise korral on teisel Poolel õigus kasutada kõiki seadusest tulenevaid õiguskaitsevahendeid. Poolte rahaline koguvastutus on piiratud Lepingu kogumaksumusega, kuid see piirang ei kehti tahtliku rikkumise korral. Juhul, kui Tellija satub Täitjale Tööde eest tasu maksmisega viivitusse, on Täitjal õigus esitada viivise nõue , mille suuruseks on 0,05 % lepingujärgse konkreetse Töö eest maksmisele kuuluvalt tasult iga tasumiseg a viivitatud kalendripäeva eest, kuid mitte rohkem kui 2 5 % konkreetse Töö eest tasumisele kuuluvast kogusummast. Täitja esitab viivise nõude Tellijale allkirjastatult vähemalt kirjalikku taasesitamist võimaldavas vormis. Täitja poolse l epingu liste kohustuste rikkumisena käsitletakse eeskä tt olukorda, kus Tööd ei vasta L epingu tingimustele või esineb muid Täitja poolseid L epingu rikkumisi (nt üle antud Tööd ei ole kvaliteetsed või ei vasta muudele Poolte vahel kokku lepitud tingimustele jmt ). Juh ul, kui Täitja ei anna Tööd üle Lepingus fikseeritud tähtajal või Poolte poolt kirjalikult kokkulepitud muul tähtajal, on Tellijal õigus nõuda leppetrahvi tasumist, mille suuruseks on 0,05% Lepingu kogumaksumusest iga Töö üleandmisega viivitatud kalendripäeva eest, kuid mitte rohkem kui 2 5 % Lepingu kogumaksumusest. Lepingu olulise rikkumise korral on Tellijal õigus esitada Täitjal e leppetrahvi nõue kuni 15 000 ( viisteist tuhat) eurot iga rikkumise eest. Oluliseks lepingurikkumiseks loetakse punktis 14.5 sätestatut. Leppetrahvi nõude kohustub Tellija esitama mõistliku aja jooksul, kuid mitte hiljem kui 3 (kolme) kuu jooksul alates päevast, mil Tellija sai teadlikuks leppetrahvi nõude aluseks olevast asjaolust. Leppetrahvi nõude vaidlustamine ei vabasta Täitjat selle maksmise kohustusest enne vastava kohtuotsuse jõustumist. Täitja on kohustatud leppetrahvi tasuma 2 ( kahe ) nädala jooksul alates Tellija poolt vastava nõude esitamisest. Tellijal on õigus tasaarvestada leppetrahvi summa Täitjale Töö teostamise eest tasumisele kuuluvate maksetega. Tööde vastuvõtmine Tellija poolt ei vabasta ega vähenda Täitja vastutust L epingu rikkumise eest. Konfidentsiaalsuskohustus Pooled kohustuvad vastastikku hoidma salajas ja mitte avaldama kolmandatele isikutele ükskõik missugust konfidentsiaalseks peetavat informatsiooni, mis on saadud teiselt P oolelt käesole va raamlepingu alusel tellitud T ööde teostamise käigus või muul viisil või juhuslikult. Konfidentsiaals e informatsiooni all mõistavad P ooled igasugust informatsiooni (s h ärisaladust, isikuandmeid, Lepingute andmeid , infosüsteeme, turvasüsteemide kirjeldusi, riistvara ja tarkvara kirjeldusi, pakkumuse kirjeldusi, kasutatavaid tehnoloogiaid, spetsifikatsioone jms), mis on saadud seoses T ööde teostamisega ja mille sattumine kolmandate isikute kätte võib P ooltele põhjustada turvariske või majanduslikku kahju või kolmandate isikute (eelkõige Tellija klientide) eraelu puutumatuse rikkumist. Kahtluse korral eeldatakse informatsiooni konfidentsiaalsust. Konfidentsiaalne informatsioon ei hõlma endas informatsiooni, mille avalikustamise k ohustus tuleneb õigusaktidest või mille avalikustamiseks P ooled on andnud nõusoleku . Pooled võivad edastada konfidentsiaalset informatsiooni ainult nendele isikutele, kes on tellitud T ööde täitmisega otseselt seotud. Täitja kohustub tagama, et isikud, keda ta oma kohustuste täitmisel kasutab, oleksid konfidentsiaalsuse kohustusest teadlikud ning nõudma nimetatud isikutelt selle kohustuse tingimusteta ja tähtajatut täitmist. Vastutus konfidentsiaalsuskohustuste täitmise eest lasub Täitjal. Pooled ei kasuta raamlepingu täitmisel neile teatavaks saanud konfidentsiaalset informatsiooni oma huvides e ga muul eesmärgil, kui tellitud T ööde teostamiseks. Konfidentsiaalsuskohustus jääb kehtima tähtajatult, ka raamlepingu ja raamlepingu alusel sõlmitud Lepingute lõpetamise või lõppemise järgselt. Täitja on teadlik, et raamleping ning raamlepingu alusel sõlmitud Lepingud ja kokkulepped on avalikud, v.a osades, mis on avaliku teabe seadusest tulenevatel alustel määratud asutusesiseseks kasutamiseks või märgitud Täitja poolt ärisaladuseks . Konfidentsiaalsuskohustuse r ikkumise korral kohustub Täitja hüvitama kõik kahjud, mis sellise rikkumise tagajärjel Tellijale või kolmandale isikule tekkisid , sõltumata sellest, kas rikkumine pandi toime L epingu kehtivuse ajal või lepinguliste kohustuste lõppemise järgselt . Raamlepingu kehtivus ja ülesütlemine Raamleping jõustub sõlmimise hetkel ja kehtib 48 (nelikümmend kaheksa) kuud. Lepingud tuleb sõlmida raamlepingu kehtivuse ajal, kuid võivad kehtida kauem. Vajadusel võib Tellija raamlepingu mahtu kuni 20% võrra suurendada ja P oolte kokkuleppel raamlepingut kuni mahu täitumiseni pikendada . Tellija võib raamlepingu igal ajal ühepoolselt üles öelda, teatades T äitjale 60 (kuus kümmend) päeva ette . Raamlepingu ülesütlemine ei muuda automaatselt kehtetuks selle alusel varem sõlmitud Lepingud . Tellijal on õigus raamleping ühepoolselt etteteatamistähtaega järgimata üles öelda, kui T äitja on oluliselt raamlepingut rikkunud või juhul, kui Täitja: suhtes on algatatud pankrotimenetlus; pankrot on välja kuulutatud; Täitja varad arestitakse; Täitja finantsseisund halveneb Tellija põhjendatud hinnangul oluliselt ja see muudab Lepingu nõuetekohase täitmise vähetõenäoliseks . Raamlepingu oluliseks rikkumiseks Täitja poolt loetakse muuhulgas: mõjuva põhjuseta Lepingu sõlmimata jätmine; vale andmete või valeinfo esitamine; Täitjal puuduvad Lepingu täitmiseks vajalikud õigused (sealhulgas load, litsentsid, intellektuaalse omandi õigused ); alapunktis 10 sätestatud intel lektuaalse omandi õiguste ja nende kasutamise tingimuste rikkumine ; korduv (vähemalt kahel korral) meeskonnaliikme asendamine isikuga, kes ei vasta riigi hanke alusdokumentides esitatud nõuetele või meeskonnaliikme asendami ne ilma T ellija eelneva vähemalt kirjalikku taasesitamist võimaldavas vormis antud nõusolekuta; konf identsiaalsuskohustuse rikkumine ; korduv (vähemalt kahel korral) L epingu jär gsetele tingimustele vast ava kohustuse täitmata jätmine , sh L epingu järgsete T ööde mittekoha ne teostamine ja kohustuste täitmata jätmine garantiiperioodil ; L epin gu järgsete kohustuste üleandmine kolmandale isikule , saamata selleks eelnevalt Tellija poolse t kirj alikku taasesitamist võimaldavat nõusoleku t . Pooltevahelised teated ja kontaktisikud Teadete edastamine toimub üldjuhul e-posti teel. Juhul, kui teate edastamisel on olulised õiguslikud tagajärjed, peab t eade olema edastatud kirjalikku taasesitamist võimaldavas vormis. Tellija kontaktisik on: sotsiaalkaitse talituse juhataja Martin Hunt; telefon +372 7943 979 , e-post: [email protected]. Täitja kontaktisik on: projektijuht Ander Tenno ; telefon + 372 526 3652 ; e-post: [email protected] . Kontaktisiku muutumisest teavitab pool kirjalikult teist poolt viivitamatult. Muud tingimused Raamlepingu alusel sõlmitud Lepingutele kohalduvad raamlepingu tingimused, olenemata raamlepingu kehtivusest. Täitjal ei ole õigust ilma T ellija kirjaliku nõusolekuta raamlepingut või sellest tulenevaid kohustusi kolmandatele isikutele üle anda . Kolmas isik on mistahes füüsiline või juriidiline isik, kes ei ole käesoleva raam lepingu pooleks. Raamlepingut muudetakse pooltevahelise kirjaliku kokkuleppega raamlepinguga samas vormis . Raamlepinguga seotud vaidlused, mida pooled ei ole suutnud läbirääkimiste teel lahendada, antakse lahendamiseks Harju Maakohtule. Raamlepingule kohaldub Eesti õigus. Kui raamlepingu mõni säte on vastuolus Eesti Vabariigis kehtivate õigusaktidega, ei mõjuta see ülejäänud sätete kehtivust. Lisad Lisa 1 . Tehniline kirjeldus ja selle lisad ; Lisa 1 . 1 . Mittefunktsionaalsed nõuded ; Lisa 1 .1 .1. Nõuded infosüsteemi dokumenteerimisele ; Lisa 1 . 2 . Front-end arendusreeglid ; Lisa 1 .3 . Lähtekoodi halduse kirjeldus ; L isa 1 . 4 . IT-profiil (tehnilised nõuded e-teenustele) ; Lisa 2. Kodukord; Lisa 3. Täitja riigihankes esitatud meeskond; Lisa 4 . Hankelepingu projekt; Lisa 5. Riigihankes esitatud hinnapakkumus. Poolte allkirjad Tellija: Täitja: Katrin Reinhold Ander Tenno ( allkirjastatud digitaalselt ) ( allkirjastatud digitaalselt ) Lisa 1. Tehniline kirjeldus Sisukord: TOC \o "1-3" \h \z \u 1. Eesmärk PAGEREF _Toc500792639 \h 2 2. Äriline taust PAGEREF _Toc500792640 \h 2 2.1. SKA teenuste tutvustus PAGEREF _Toc500792641 \h 2 2.2. Teenuste kirjeldus ja arendussoovid PAGEREF _Toc500792642 \h 6 2.3. SKAIS alamsüsteemide toimimine PAGEREF _Toc500792643 \h 15 2.4. SKAIS teenuste kasutajagrupid PAGEREF _Toc500792644 \h 16 2.5. SKAIS arendustööde teostamise üldised ärilised nõuded PAGEREF _Toc500792645 \h 17 3. Hangitav skoop PAGEREF _Toc500792646 \h 19 4. Tööde tellimise põhimõtted PAGEREF _Toc500792647 \h 20 5. SKAIS2 arenduste indikatiivne teekaart (2018 -2019) PAGEREF _Toc500792648 \h 20 Lisad PAGEREF _Toc500792649 \h 21 Lisa 1.1. SKAIS2 arhitektuur PAGEREF _Toc500792650 \h 21 Lisa 1.2. Mittefunktsionaalsed nõuded PAGEREF _Toc500792651 \h 21 Lisa 1.2.1. Nõuded infosüsteemi dokumenteerimisele PAGEREF _Toc500792652 \h 21 Lisa 1.3. Front-end arendusreeglid PAGEREF _Toc500792653 \h 21 Lisa 1.4. Lähtekoodi halduse kirjeldus PAGEREF _Toc500792654 \h 21 Lisa 1.5. SK2 andmevahetusteenused PAGEREF _Toc500792655 \h 21 Lisa 1.6. IT-profiil (tehnilised nõuded e-teenustele) PAGEREF _Toc500792656 \h 21 Eesmärk Käesoleva riigihanke eesmärk on sõlmida 2 raamleping ut pakkuja te ga, kes hakka vad arendama ja hooldama sotsiaalkindlustuse valdkonna avalikke teenuseid (sh uued, olemasolevad) ja nendega seotud töi d Sotsiaalkaitse infosüsteem is. Täpsem kirjeldus on esitatud p eatükis 3 . Äriline t aust Sotsiaalkaitse infosüsteem ( edaspidi: SKAIS) katab Sotsiaalkindlustusameti (edaspidi: SKA) peamisi tegutsemisvaldkondi, toetades eelkõige igapäevaseid rutiinseid ja töömahukaid avalike teenuste tööprotsesse . Täna kasutusel olev SKAIS koosneb tehniliselt kahest infosüsteemist - SKAIS1 ja SKAIS2. Lisaks on kasutusel majandustarkvara Oracle E- Business Suit e (edaspidi: EBS) . Tuleviku eesmärgiks on viia kõik SKA poolt pakutavad teenused SKAIS2-le (vt p 2.3) . SKAIS1 põhimoodulid olid algselt isikustatud sotsiaalmaksu, sh riikliku pensionikindlustusosa kogumine ning pensionide ja peretoetuste määramine ja maksmine. Süsteemi arhitektuur ja loogika olid üles ehitatud sellest lähtuvalt. Viimase 12 aasta jooksul on SKAIS-i funktsionaalsust laiendatud üle 20 valdkonna võrra. Kasvanud on teenuste liikide arv ja teenuste mahud. Lisaks kasvab infovahetus teiste riikidega. Täna toetab SKAIS SKA poolt pakutavate teenuste menetlust, rahaliste hüvitiste väljamaksmist nii füüsilistele kui juriidilistele isikutele ning andmevahetust teiste andmekogude ning riigiportaali eesti.ee teenustega . SKAIS1 kaudu toimub täna 21 teenuse menetlemine, määramine ning väljamaksmine. Täpne loetelu ja teenuste lühikirjeldused on esita tud punktis 2.1 . SKAIS2 -s on tänaseks kasutusel elati sabiteenus (kohtumenetlusaegne elatisabi ja täitemen e tlusaegne elatisabi) , puude raskusastme tuvastamine ja sotsiaaltoetus e teenus (puude raskusastme tuvastamine, puuetega inimeste sotsiaaltoetus, puu dega isiku kaart), finantsarvestus ja väljamaksed ( finantsarvestus, raamatupidamiskannete tegemine ja väljamaksed) . 2.1. SKA teenuste tutvustus Teenuste kasutus hetkel SKAIS1 ja SKAIS2 poolel: Katusnimetus Teenus Teenuse lühikirjeldus LIVE infosüst. Plaanis Sotsiaal - teenused Sotsiaalne rehabilitatsioon Teenus on mõeldud puuetega inimestele ja osalise või puuduva töövõimega inimestele. Inimesele pakutakse välja rehabilitatsiooniprogramm või teenuste vajaduste hindamise käigus koostatakse inimesele tegevuskava või suunatakse inimene rehabilitatsiooniasut usse isikliku rehabilitatsiooni plaani koostamisele. Teenus on mitterahaline hüvitis, millega SKA võtab isiku eest üle tasu maksmise kohustuse teenuse eest . Rahalise hüvitisena kuulu vad isikule ja tema saatjale hüvitamiseks majutus- ja sõidukulud, mis on tehtud seoses rehabilitatsiooni teenusega. SKAIS1 Vaja arendada SKAIS2-le. Erihoolekanne Teenus on mõeldud alates 18-aastastele inimestele, kes vajavad oma vaimse tervise olukorra tõttu igapäevaelus juhendamist, nõustamist, kõrvalabi ja järelevalvet vastava eriala spetsialistilt. Erihoolekandeteenustena on või malik saada toetavaid teenuseid elades oma kodus või kogukonnas elamise teenust ja ööpäevaringset erihooldusteenust teenuseosutaja pakutud elupinnal. SKA peab ühtset järjekorda, kuhu peab olema võimalik isikut registreerida alates 16-ndast eluaastast. Erihoolekandeteenus on mitterahaline hüvitis, millega SKA võtab isiku eest üle tasu maksmise kohustuse teenuse saamise eest . SKAIS1 Vaja arendada SKAIS2-le. Abivahendi hüvitamise teenus Teenus on mõeldud inimestele, kellel on tuvastatud puue või osaline või puuduv töövõime või kes on 63-aastane või vanem vanaduspensioniealine isik, kellele arst on väljastanud tõendi või on rehabilitatsiooniasutus märkinud abivahendi vajaduse rehabilitatsiooniplaanis. SKA väljastab inimesele isikliku abivahendi kaardi, millega inimene saab pöörduda abivahendeid müüvasse või neid rentivasse ettevõttesse, kellega SKA on sõlminud halduslepingu. Teenus on mitterahaline hüvitis, millega SKA võtab isiku eest üle abivahendi soetamise või rentimise tasu maksmise kohustuse. SKAIS1 Vaja arendada SKAIS2-le. Pensionid Riiklik pension Tee nus on mõeldud vanadusepensioni ealistele isikutele, töövõimekaotusega isikutele või toitjakaotuse korral toitja ülalpidamisel olnud isikutele. Riiklik pension koosneb kolmest komponendist : baasosast, pensioni s taa žiosast ja pensionikindlustusosast. Pensioni staažiosa ja pensionikindlust usosa on isiku põhised . Pensioni staažiosa arvutatakse kuni 31.12.1998 töötatud, õpitud või armees teenitud perioodide alusel. Alates 01.01.1999 aastast arvutatakse kindlustusosa, mis arvutatakse isiku eest makstud sotsiaalmaksust. Riiklik pension on rahaline perioodiline hüvitis, mida makstakse igakuiselt. SKAIS1 Vaja arendada SKAIS2-le. Eripension Teenus on mõeldud isikutele, kes on seaduses ettenähtud vanuses ning kes on töötanud ettenähtud perioodi nimetatud kutse- või ametikohal. Olenevalt eripensioni liigist arvutatakse eripensioni suurus isiku ametipalga alusel või kolme komponendi alusel : baasosa, pensioni s taa žiosa ja pensionikindlustusosa. Pensioni staažiosa ja pensi onikindlustusosa on isiku põhised . Pensioni staažiosa arvutatakse kuni 31.12.1998 töötatud, õpitud või armees teenitud perioodide alusel. Alates 01.01.1999 aastast arvutatakse kindlustusosa, mis arvutatakse isiku eest makstud sotsiaalmaksust. Eripension on rahaline perioodiline hüvitis, mida makstakse igakuiselt. SKAIS1 Vaja arendada SKAIS2-le. Rahvusvaheline pension Tee nus on mõeldud vanadusepensioni ealistele isikutele, töövõimekaotusega isikutele või toitjakaotuse korral toitja ülalpidamisel olnud isikutele, kui isik on töötanud vähemalt aasta Euroopa Majanduspiirkonna riigis või mõnes järgnevates t riikides t: Ukraina , Vene Föderatsioon, Moldova, Kanada . Rahvusvaheline pension koosneb kolmest komponendist : baasosast, pensioni s taa žiosast ja pensionikindlustusosast. Pensioni staažiosa ja pensi onikindlustusosa on isiku põhised . Pensioni staažiosa arvutatakse kuni 31.12.1998 töötatud, õpitud või armees teenitud perioodide alusel. Alates 01.01.1999 aastast arvutatakse kindlustusosa, mis arvutatakse isiku eest makstud sotsiaalmaksust. Rahvusvahelise pensioni määramisel ja maksmisel tuleb arve sta da erisustega, mis tulenevad Euroopa Liidu määrustest või sõlmitud kahepoolsetest lepingutest. Rahvusvaheline pension on rahaline perioodiline hüvitis, mida makstakse igakuiselt või kvartaalselt kas isikule või pädevale asutusele. SKAIS1 Vaja arendada SKAIS2-le. Üksi elava pensionäri toetus Teenus on mõeldud isikutele, kellele on määratud pension ja kes on vanaduspensioniealine, kes elab Rahvastikuregistri andmetel oma elukohas üksi ning ke lle pensioni suurus on alla 1,2- kordse Eesti keskmise vanaduspensioni. Teenuse saamiseks isikud SKA- sse pöörduma ei pea, hüvitis makstakse välja automaatselt pärast andmete kontrollimist. Hüvitis kuulub väljamaksmisele üks kord aastas , oktoobris, kui isik vastab nõutud tingimustele perioodil 01.04 - 30.09. SKAIS1 Vaja arendada SKAIS2-le. Pensioni määramiseks vajaliku info kogumine Teenus on mõeldud inimestel, kes ei ole veel vanaduspensioni eas. Pensioni määramiseks vajaliku info kogumine on isiku töötamise, õppimise, armees teenimise või laste kasvatamise eest pensioni määramiseks vajalike andmete sisestamine infosüsteemi. Lisaks isikutele võivad tööraamatu id SKA- le esitada ka tööandjad. Andmete tulemi põhjal peab süsteem hakkama tegema isikutele pakkumusi enne vanaduspensioni ea saabumist ning sisestatud andmed võetakse aluseks pensioni määramisel. SKAIS1/ SKAIS2 Vaja b jätkuarendusi SKAIS2-s. Perehüvitised Peretoetused Tee nus on mõeldud lapsi kasvatavatele pere dele . Peretoetused on rahalised hüvitised, mida makstakse seoses laste kasvatamisega perekonnas . Hüvitis t e suurused on seadusega kindlaks määratud summad. Makstava peretoetuse suur us sõltub perekonnas kasvavate laste arvust, laste vanusest ning õppimisest. Peretoetused on rahalised hüvitised, mis jagunevad ühekordseteks hüvitisteks ja perioodilisteks hüvitisteks. Ühekordseid peretoetuseid on kolm alamliiki ja perioodiliselt makstavaid hüvitisi on viis alamliiki ning neid makstakse üks kord kuus. SKAIS1 Vaja arendada SKAIS2-le. Vanemahüvitis Teenus on mõeldud vanemale seoses lapse sünniga, lapsendajale , vanema abikaasale, eestkostjale või hooldajale, kelle sissetulek väheneb lapse kasvatamise tõttu. Õigus vanemahüvitisele tekib vanemal alates lapse sünnist või sünnitus- või lapsendamislehe lõpukuupäevale järgnevast kuupäevast. Hüvitise suurus arvutatakse hüvitise saaja õiguse tekkimisele eelnenud kalendriaasta isikustatud sotsiaalmaksu andmete alusel. Vanemahüvitis on rahaline hüvitis, mida makstakse perioodiliselt üks kord kuus kas 435 kalendri päeva eest või kuni lapse 18 kuuseks saamiseni. SKAIS1 Vaja arendada SKAIS2-le. Kohustusliku kogumispensioni täiendavad sissemaksed Teenus on mõeldud lapsevanematele, kes kasvatavad kuni 3-aastast last ja on l iitunud II pensionisambaga. SKA teeb lapse ühe vanema eest lapse sünnist kuni lapse 3-aastaseks saamiseni täiendavaid sissemakseid kohustusliku kogumispensioni kontole. Sissemaksete suuruseks on 4% Eesti keskmisest sotsiaalmaksuga maksustatavast ühe kalendrikuu tulust. SKAIS1 Vaja arendada SKAIS2-le. Elatisabi Kohtumenetlus - aegne elatisabi Teenus on mõeldud kuni 18-aastasele lapsele või õppivale kuni 21-aastasele lapsele , kelle vanem või vanemad ei täida ülalpidamiskohustust ning elatise maksmiseks on laps või teine vanem pöördunud kohtusse elatise väljamõistmiseks ja kohus ei ole veel elatise määramise asjus kohtuotsust teinud. Kohtumenetlusaegse elatisabi saamiseks peab olema väljastatud hüvitise saajale makseettepaneku määrus või hagi tagamise määrus. Kohtumenetlusaegse elatisabi suurus on seadusega kindlaks määratud summa, mida makstakse perioodiliselt üks kord kuus kuni 150 kalendripäeva eest. Väljamakstud hüvitise nõuab SKA tagasi vanema l t, kellele kohus tegi otsuse elatise väljamõistmiseks. SKAIS2 Võib vajada muudatusi/ jätkuarendusi. Täitemen e tlus - ae gne elatisabi Teenus on mõeldud kuni 18-aastasele lapsele või õppivale kuni 21-aasta s ele la psele , kelle vanem või vanemad ei täida ülalpidamiskohustust ning elatise maksmiseks on laps või teine vanem pöördunud kohtutäituri poole ning alustatud on täitemenetlus. Täitemenetlusaegse elatisabi väljamakseid teeb SKA info põhjal , mida edastab kohtutäitur e-täituri kaudu. Hüvitise suurus on kuni 100 eurot kuus. Kohtutäiturid edastavad e-täituri kaudu igakuiselt info, kelle eest ja kui suures summas kuulub hüvitis väljamaksmisele. SKA poolt väljamakstud summad kuuluvad tagasi nõudmisele vanema käest, kelle vastu on täitemenetlus algatatud. SKAIS2 Vajab muudatusi/ arendusi. Puude raskusastme tuvastamine ja so ts iaaltoetus Puude raskusastme tuvastamine Teenus on mõeldud inimes t ele, kellel on terviseprobleemide tõttu raske igapäevaelus toime tulla ja ühiskonnas tegutseda või kes vajab igapäevaelus eakaaslastest rohkem juhendamist , järelevalvet või abi. Puude raskusastet tuvastatakse nii lastel, tööealistel kui ka vanaduspensioniealistel. Puude raskusastme tuvastamisel hinnatakse isiku puude raskusaste t ning kõrvalabi vajadus t . Selle tulemusel tekib isikul õigus puuetega inimeste sotsiaaltoetusele ja puudega isiku kaardile. SKAIS2 Vajab jätkuarendusi. Puuetega inimeste sotsiaaltoetus Teenus on mõeldud inimestele, kellel on tuvastatud puude raskusaste ja kellel on erivajadusest tulenevaid lisakulutusi. Lisakulutused võivad olla seotud näiteks abivahendite või transpordi kasutamisega, hoolduse või rehabilitatsiooniga. Puuetega inimeste sotsiaaltoetus on perioodiline hüvitis, mida makstakse kord kuus ning mille suuruse arvutamise aluseks on sotsiaaltoetuse määr kuus. SKAIS2 Vajab jätkuarendusi. Puudega isiku kaart Puudega isiku kaardi väljastamise teenus on isikutele, kellel on tuvastatud puude raskusaste. Puudega isiku kaart väljastatakse puude raskusastme kehtivuse ajaks. Kaardiga on võimalik tõendada oma puude raskusastet. SKAIS2 Vajab jätkuarendusi. Sotsiaalmaksu - andmete töötlemine Isikustatud sotsiaalmaksu pensionikindlustu - se osa keskmi s e suurus e arvutamine ja indekseerimine Pensioniindeksi arvestamise aluseks on 80 protsendi ulatuses eelmise aasta sotsiaalmaksu pensionikindlustuse osa laekumise muutus ja 20 protsendi ulatuses eelmise aasta tarbijahinnaindeksi muutus. Nende muudatuste alusel arvutatakse indeks, mille kinnitab V abariigi V alitsus. Indeksiga korrutatakse riiklike pensionite arvutamise aluseks olevaid näitajaid – pensioni baasosa, aastahinnet ja rahvapensioni määra. SKAIS1 Vaja arendada SKAIS2-le. Pensioniõiguste ülekandmine Eesti ja EL institutsioonide vahel EL i nstitutsioonis töötanud ametnikul on õigus valida, kas kanda oma välja teenitud pensioniõigused Euroopa ü henduste institutsioonide pensioniskeemi või Eesti Vabariigi pensioniskeemi. Pensioniõiguste ülekandmine võib toimuda nii Eesti pensioniskeemist Euroopa ühenduste institutsioonide pensioniskeemi kui ka Euroopa ühenduste institutsioonidest Eesti pensioniskeemi. Teenusega toimub rahaliste vahendite ülekandmine isiku avalduse alusel. Isikul on õigus pensioniõiguseid kanda ühe korra Euroopa ühenduste institutsioonide pensioniskeemist Eestisse ja vastupidi. SKAIS1 Vaja arendada SKAIS2-le. Finants - arvestus ja väljamaksed Raamatupidamis - kannete tegemine ja väljamaksed Toimuvad väljamaksed ja kohustuste, nõuete, tasaarvestuste ning maksude finantsarvestusse kandmine (raamatupidamiskannete tegemine). SKAIS1/ SKAIS2 (EBS) Vajab jätkuarendusi SKAIS2-s. Finants arvestus Finants arvestuses toimub kohustuste ja nõuete arvele võtmine ja tehakse tasaarvestusi ning toimub maksustamisele kuuluvate summade arvutamine . SKAIS1/ SKAIS2 Vajab jätkuarendusi. Puhkusetasu ja töötasu hüvitamine Teenus on mõeldud tööandjatele, kellele hüvitatakse esitatud andmete alusel nende poolt tehtud kulutused seoses lisapuhkepäevadega : isale enne lapse sündi või pärast lapse sündi; puudega lapse vanemale; kuni 14-aastaste laste ühele vanemale; lapse rinnaga toitmise vaheaegade eest keskmise töötasu maksmisega. SKAIS1 Vaja arendada SKAIS2-le. Kuriteoohvri riiklik hüvitis Teenus on mõeldud vägivallakuriteo tagajä rjel kannatada saanud isikutele juhul, kui vägivallakuritegu on toime pandud Ee sti riigi territooriumil. Kurit e o ohvri hüvitis koosneb ravikuludest, perioodilisest hüvitisest ja matusekuludest. Varaline kahju hüvitatakse kuni 80% ulatuses , kuid mitte üle 9590 euro. SKA poolt väljamakstud summad kuuluvad tagasinõudmisele kahju tekitajalt . SKAIS1 Vaja arendada SKAIS2-le. Tõend A1 väljastamine Tõendi A1 väljastamise teenus on mõeldud isikutele, kes viibivad lähetuses välisriigis või t öötavad mitmes riigis. Seda võivad taotleda nii tööandja, töötaja kui ka ametnik. Tõendiga määratakse kindlaks isiku kindlustajariik . T õendi väljastab riik, mille sotsiaalkindlustuse õigusakte kohaldatakse ja sellega tõendab lähetuses viibiv või mitmes riigis töötav isik vastu võtva riigi ametkonnale, et tema suhtes ei kohaldata ühegi teise tema tööga seotud riigi sotsiaalkindlustuse õigusakte. SKAIS1 Vaja arendada SKAIS2-le. Riigipool n e sotsiaalmaksu hüvitamine Riigi poolne sotsiaalmaksu tasumise teenus on mõeldud isikutele, kelle eest tööandja ei tasu sotsiaalmaksu ning kellel puudub ravikindlustus, kuid kes kasvatavad Eestis väikeseid lapsi või kes on taotlenud Eestist rahvusva h e l ist kaitset ning saanud politsei- ja piirivalveametilt rahvusvahelise kaitse andmise otsuse ja Eestis elamise loa või kes on Eesti kodanikud, kellele SKA maksab Eestisse tagasipööduja toetust või riiklikku pensioni. Tegemist on mitterahalise hüvitisega, mida SKA maksab teatud hüvitiste saamisel isiku eest automaatselt ja isiku avalduse alusel , kui määratud tingimused on täidetud. SKAIS1 Vaja arendada SKAIS2-le. Kahjuhüvitis Teenus on mõeldud isikutele, kellel on tekkinud tervisekahjustus tööõnnetuse või kutsehaiguse tagajärjel ja kelle tööandja on likvideeritud ning puudub ka õigusjärglane. Kahjuhüvitis on tööandaja süül tekkinud otsese varalise kahju või saamata jäänud tulu hüvitamine isikutele, kellel on tuvastatud kutsehaigus või tööõnnetuse puhul tekkinud tervisekahjustus või surma korral toitja ülalpeetavatele. Tegemist on nii ühekordsete rahaliste hüviti stega kui ka perioodiliste makseteg a, mida makstakse igakuiselt . SKAIS1 Vaja arendada SKAIS2-le. Õppela enu kustutamine Õppelaenu osalin e kustutamine Teenus on mõeldud lapsevanematele, kes kasvatavad kuni 5-aastast last ning kellel on õppelaen. SKA kustutab kvartaalsete maksetena krediidiasutusele ühe lapsevanema õppelaenu, mille kohta on tehtud õppelaenu kustutamise otsus. SKAIS1 kuni 2022, siis teenus lõpetataks e Ei arendata SKAIS2-le. Õppe l a enu kustutamine *) Õppelaenu kustutamise teenus on mõeldud õppelaenu saajale, kellel on tuvastatud puuduv töövõime või k elle lapsel on tuvastatud raske või sügav puue või laenusaaja surma korral . SKA kustutab õppelaenu kustutamise otsuse alusel ühekordse maksena krediidiasutusele laenusaaja surma, temal puuduva töövõime tuvastamise või laenusaaja lapsel raske või sügava puude tuvastamise korral õppelaenu. täna pole Vaja arendada SKAIS2-le. Sotsiaaltoetus Eestisse tagasipöördujale *) Teenus on mõeldud välisriigist Eestisse elama asunud Eesti kodanikule või eesti rahvusest inimesele ja temaga koos Eestisse elama asunud abikaasale, lapsele või vanematele, kes on jõudnud vanaduspensioni ikka ning nende kuusissetulek on alla rahvapensioni määra. Toetuse eesmärgiks on tagada sissetulek vanaduspensionieas tagasipöördujale , kellel puudub Eestis vanaduspensioni määramiseks vajalik tööstaaž. Hüvitist makstakse perioodiliste maksetena üks kord kuus ning hüvitise suurus arvutatakse rahvapensioni määras. SKAIS1 Vaja arendada SKAIS2-le. Olümpiavõitja toetus *) Teenus on mõeldud inimestele, kes on tulnud olümpiamängudel või paraolümpiamängudel Eesti Vabariiki esindades olümpiavõitjaks. Olümpiavõ i tja toetus m ääratakse kas vanuse alusel kü mme aastat enne vanaduspensioni ea saabumist või osalise või puuduva töövõime alusel alates osalise või puuduva töövõime tuvastamisest. Olümpiavõitja toetus on rahaline perioodiline hüvitis, mida makstakse välja üks kord kuus. Hüvitise suuruse määrab Riigikogu ig a- aastaselt riigieelarve seadusega. SKAIS1 Vaja arendada SKAIS2-le. Represseeritu toetus ja tunnistus *) Teenus on mõeldud okupatsioonirežiimide poolt represseeritud või nendega võrdsustatud inimestele. Represseeritule või represseerituga võrdsustatud inimesele väljastatakse represseeritu tunnistus, millega saab tõendada õigust represseeritud inimestele ett enähtud soodustustele. Inimesel , kellele on väljastatud represseeritu tunnistus , tekib õigus represseeritu toetusele, mis on rahaline hüvitis ning mida makstakse represseeritule üks kord aastas. SKAIS1 Vaja arendada SKAIS2-le. Matusetoetus Riiklik ule matusetoetusele on õigus nendel matusekorraldajatel, kelle perekonnale määrati matusetoetuse taotlemise kuul või sellele eelnenud 12 kuu jooksul vähemalt ühel korral toimetulekutoetus. Matusetoetust makstakse ka valla- või linnavalitsusele, kui nad korraldavad tundmatu või omasteta isiku matuse. Riiklik matusetoetus on matuse korraldamiseks ette nähtud ühekordne toetus. Riikliku matusetoetuse suuruse kehtestab Riigikogu iga-aastase riigieelarve seadusega. SKAIS1 kuni 01.07.2018 Ei arendata SKAIS2-le. Ohvriabi ja lepitusteenus Teenus on mõeldud isikutele, kes on langenud kuriteo ohvriks või on kogenud vägivalda, hoolimatus t või halba kohtlemist. Teenuse raames hüvitatakse ohvri ja tema perel iikme psühholoogilise abi kulud, v iiakse läbi lepitusteenust II astme k uritegude puhul, t agatakse täiendavad teenused inimkaubanduse ohvritele, seksuaalselt väärkoheldud alaealistele ja saatjata alaealistele välismaalastele. SKA hüvitab kulutused isikule osutatud teenuste eest teenuseosutajale esitatud arvete alusel . SKAIS1 Ei arendata SKAIS2-le (läheb STAR-i alla) *) Teenust e i arendat a SKAIS2-le iseseisva teenusena, vaid "u niversaaltoetuse väljamaksmise" teenus ena, mis katab ka seda teenust. 2.2. Teenuste kirjeldus ja arendussoovid Sotsiaalteenused Sotsiaalteenused moodustavad: sotsiaalne rehabilitatsiooniteenus, erihoolekandeteenus ja abivahendi hüvitamise teenus. Sotsiaalne rehabilitatsiooniteenus on mõeldud puuetega inimestele ja osalise või puuduva töövõimega inimestele. Inimesele pakutakse välja rehabilitatsiooniprogramm või koostatakse teenuste vajaduste hindamise käigus inimesele tegevuskava või suunatakse inimene rehabilitatsiooniasutusse isikliku rehabilitatsiooni plaani koostamisele. Erihoolekandeteenus on mõeldud alates 18-aastaseks saanud inimestele, kes vajavad oma vaimse tervise olukorra tõttu igapäevaelus juhendamist, nõustamist, kõrvalabi ja järelevalvet vastava eriala spetsialistilt. Erihoolekandeteenustena on või malik saada toetavaid teenuseid elades oma kodus või kogukonnas elamise teenust ja ööpäevaringset erihooldusteenust teenuseosutaja pakutud elupinnal. Abivahendi hüvitamise teenus on mõeldud inimestele, kellel on tuvastatud puue või osaline või puuduv töövõime või kes on 63-aastane või vanem vanaduspensioniealine isik, kellele arst on väljastanud tõendi või on rehabilitatsiooniasutus märkinud abivahendi vajaduse rehabilitatsiooniplaanis. Sotsiaalkindlustusamet väljastab inimesele isikliku abivahendi kaardi, millega inimene saab pöörduda abivahendeid müüvasse või neid rentivasse ettevõttesse, kellega SKA on sõlminud halduslepingu. Nende kõigi teenuste puhul ei toimu rahaliste hüvitiste väljamaksmist isikutele, vaid SKA võtab isiku eest üle tasu maksmise kohustuse ehk isik saab teenust või abivahendi ning arve teenuse või abivahendi saamise eest tasub SKA teenuseosutajale , kellega on SKA-l sõlmitud tähta jalised halduslepingud. Erandiks on sotsiaalse rehabilitatsiooniteenuse alamteenusena olev sõidu- ja majutuskulude hüvitamine isikule seoses sotsiaalse rehabilitatsiooniteenuse saamisega. SKAIS2-s on vajal ik luua sotsiaals e rehabilitatsiooniteenuse ja erihoolekandeteenuse menetluseks hindamisinstrument (küsimustik), mille alusel saab isiku vastavalt tema profiilile teenusele suunata. Eelpool nimetatud teen uste puhul on vajalik luua vastuvõtu aegade broneerimissü steem ning järjekordade haldamise süsteem. Abivahendi hüvitamise teenuse puhul tuleb luua andmevahetus selliselt, et isikul puuduks vajadus pöörduda abivahendi saamiseks SKA- sse , kogu info peab olema teenuseosutajale kättesaadav teenuseosutajaportaalis . Abivahendi taotleja peab enda kohta käivat infot nägema iseteeninduses. Vajalik on kasutajaliidese loomine teenuseosutajale (= teenuseosutajaportaal ), mille kaudu saab teenuseosutaja kliendipõhise teenuse osutamiseks SKA-st kliendi kohta vajaliku andmestiku. Süsteem peab suutma kont rollida kliendi- ja/või asutuse põhist eelarve täitumist. Teenuseosutajal peab olema võimalik volitada kindlaksmääratud isikut täitma teenuseosutajaportaalis onlines nõutud andmeid teenuse osutamise kohta. Sisestatud andmetest peab igakuiselt genereeruma arve, mis kuulub SKA poolt tasumisele. Sotsiaalteenuste puhul on oluline, et süsteem võimaldaks: teenuseosutajatega lepingute sõlmimist; teenuseosutaja te andmete haldamist; lepingu te andmete haldamist , sh e rinevad sihtrühmad, mahud, rahastamis allikad, kasutamata teenuste summade vabastamine; lepinguliste teenuseosutajate järelevalve planeerimistegevused, aktide säilitamine jms. Pensionid Pensionide määramist ja maksmist reguleerivad erinevad Eesti sisesed õigusaktid, lisaks on Euroopa Liidu (edaspidi: EL) õigusaktid ning kehtivad bilateraalsed lepingud (Vene Föderatsioon, Kanada, Moldova, Ukraina ja alates 01.01.2018 Austraalia). Täna on olemas üle 110 erineva pensioni liigi, mille määramiseks peab esitama taotluse isik ise või esitab andmed kokkulepitud vormil pädev asutus. Pensionid saame grupeerida kolme suurte rühma: p ensionid, mis koosnevad kolmest osast (baasosa, staažiosa, kindlustusosa) ; p ensionid, kus arvutatakse protsent isiku valitud ametipalgast ; v älisriigi pensionid . Pensioni kolm osa on: baasosa, mis on kindlaks määratud suurus; staažiosa, mis arvutatakse kliendipõhiselt ning päeva täpsusega kuni 31.12.1998.a perioodide eest, mil isik töötas, õppis või oli armees; kindlustusosa, mis arvutatakse kliendipõhiselt makstud sotsiaalmaksu andmete alusel alates 01.01.1999. SKAIS1 võimaldab täna sisestada pensioni määramise algandmed, mille põhjal arvutab pensioni suuruse ning moodustab staažiosa õiendi ja pensioni määramise otsuse. Nimetatud dokumente süsteemi ei salvestata ja neid ei ole võimalik süsteemis digiallkirjastada ega digitembeldada . Määratud pensione saab ümber arvutada , sh ümber arvutada tagasiulatuvalt, peatada, jätkata ja lõpetada. Iga-aastane indekseerimine toimub automaatselt. SKAIS2-s peab olema võimalik määrata pensioni kehtivate ärireeglite alusel. Süsteemis peavad olema alusandmed, mis on sisestatud SKAIS1-te. Samuti peab olema võimalik SKAIS2-te lisada vajalikke dokumente vastava menetluse juurde. Pensioni menetluses koostatud otsused peavad olema digitembeldatud ning salvestatud süsteemi. Süsteemis olevate andmete põhjal ning etteantud reeglite alusel pea b SKAIS2 hakkama tegema ka proaktiivseid pakkumisi vanaduspensioni ea saabudes. Iseteeninduses pea b isikul olema võimalik näha talle määratud pensioni suurust ja alusandmeid. Isikul peab tekkima võimalus kinnitada süsteemi poolt koostatud proaktiivs eid pakkumusi. Üksi elava pensionäri toetuse maksmise teenus on mõeldud isikutele, kellele on määratud pension , kes on vanaduspensioni eas, elab Rahvastikuregistri andmetel oma elukohas üksi ja kelle pensioni suurus on alla 1,2 kordse Eesti keskmise vanaduspensioni. Teenuse saamiseks isikud ise Sotsiaalkindlustusametisse pöörduma ei pea, hüvitis makstakse välja automaatselt peale andmete kontrollimist. Hüvitis kuulub väljamaksmisele üks kord aastas oktoobris, kui isik vastab nõutud tingimustele perioodil 01.04 kuni 30.09. SKAIS2-s peab olema võimalik üksi elava pensionäri toetuse automaatne menetlemine ja väljamaksmine. Samuti peab olema võimalik täiendavalt andmeid manuaalselt lisada. Tule b luua iseteeninduse vaade, kust isikul on võimalik kontrollida , kas ta vastab hüvitise saamise tingimustele. Pensioni määramiseks vajaliku info kogumise teenus on mõeldud inimestel e , kes ei ol e veel vanaduspensioni eas. Pensioni määramiseks vajaliku info kogumine on isiku töötamise, õppimise, armees teenimise või laste kasvatamise eest pensioni määramiseks vajalike andmete sisestamine infosüsteemi. Andmed sisestatakse infosüsteemi dokumentide alusel, mida peab saama lisada infosüsteemi vastavate andmete juurde. Samuti peab olema võimalus märkida infosüsteemi, kes dokumendid on esitanud ning kas tööraamat (on üks peamine töötamist tõendav dokument) on jäetud Sotsiaalkindlustusametile hoiule või isikule tagastatud. Lisaks füüsilistele isikutele võivad Sotsiaalkindlustusametile esitada oma endiste töötajate tööraamatu id ka juriidilised isikud, see ga on vajalik, et SKAIS2-te saaks märkida, millise töötaja tööraamatud on konkreetne tööandaja esita nud ning mitu tööraamatut kokku esitati. Andmete tulemi põhjal peab süsteem hakkama tegema isikutele pakkumusi enne vanaduspensioni ea saabumist ning sisestatud andmed võetakse aluseks pensioni määramisel. SKAIS2-e jaoks on vajalikud pensioni määramiseks vajaliku info kogumise teenuse jätkuarendused . Perehüvitised Perehüvitiste teenus on seotud riigipoolse sotsiaalmaksu hüvitamise teenuse ga, puhkusetasu ja töötasu hüvitamise teenuse ga ja puudega lapse toetusega. Täna arvutab SKAIS1 perehüvitiste suurused ja perioodid ette antud ärireeglite põhjal välja ning perekoos s eisu muutumisel teeb automaatselt ümberarvutused. Perehüvitisi saab täna isik taotleda riigiportaali (eesti.ee) kaudu. Perehüvitised koosnevad: peretoetused, mis on konkreetsed suurused ning mis on määratud seadusega; vanemahüvitis, mis sõltub saaja hüvitisele õiguse tekkimisele eelneva kalendriaasta sotsiaalmaksuga maksustatud tulude suurusest ; kohustusliku kogumispensioni sissemaksest, mis on 4% Eesti keskmisest sotsiaalmaksuga maksustatavast ühe kalendrikuu tulust. SKAIS2 peab hakkama seoses lapse sünniga perehüvitisi proaktiivse teenusena isikutele pakkuma. Pakkumus peab olema nähtav ametnikule mõeldud kasutajaliideses (= ametnikuportaalis) kliendipõhises vaates, lapse mõlemale vanemale iseteeninduses ning info pakkumuse kohta peab minema mõlema vanema e-postile, kui SKA- le on teada isiku e-posti aadress. Pakkumisega nõustumisel peab olema võimalik automaatmenetlus, mille tulemusel vormistab süsteem etteantud nõuetele, sh digitembeldab , koheselt otsuse (haldusakti). Pakkumise ga nõustu misel peab teisele vanemale tehtud pakkumine muutuma mitteaktiivseks ehk teine vanem ei saa enam pakkumusega nõustuda . Isikul peab olema võimalik pakkumisega mittenõustumisel täiendada/lisada andmeid - eelkõige andmeid, mis on seotud Euroopa Majanduspiirkonnas töötamise, elamise, õppimise ja samaliigiliste toetuste saamisega. Samuti peab saama vanemahüvitise korral lisada sotsiaalmaksuga maksustatava tulu saamist. SKAIS2 peab võimaldama pakkuda perehüvitisi ja taotleda perehüvitisi nn komplekstaotlusena , st ühe pakkumuse või taotlusega saab isik taotleda peretoetust, vanemahüvitist ja kohustusliku pensioni sissemakseid. Süsteem peab võimaldama moodustada kompleksotsust, kui kõik i teenuse i d on võimalik koheselt automaatselt menetleda. Kui mingi teenus ei vasta automaatmenetluse tingimustele, siis tuleb suunata mittevastav teenus manuaalmenetlusse, ülejäänud teenused tuleb automaatmenetlusega menetleda ning määratud hüvitised kuuluvad väljamaksmisele. Perekoosseisu muutumisel (laste arvu muutus, laste vastamine perehüvitiste saamise tingimustele) tuleb perehüvitised automaatselt ümber arvutada ilma isiku taotluseta või suunata menetlejale otsuse tegemiseks manuaalmenetlusse. Perehüvitistest ligikaudu 10% moodustavad perehüvitised, mille määramisel ning maksmisel tuleb kohaldada E L-i õigusakte. Sellest tulenevalt peab olema võimalik hüvitiste määramisel või ümberarvutamisel kasutada eelnevatel perioodidel kehtinud äriree gleid ning olulised on varasemalt väljamakstud perehüvitiste summad ja alusandmed, mis on täna SKAIS1-s. Elatisabi Elatisabi on mõeldud lapsele või kuni 21-aastastele lapsele, kui ta õpib, kelle vanem või vanemad ei täida ülalpidamiskohustust. Elatisabi on oluline abinõu lapse parema toimetuleku toetamiseks. Elatisabi on võimalik taotleda nii kohtumenetluse alustamise korral kui ka täitemenetluse ajal. Kohtumenetlusaegs e elatisabi saamiseks peab olema laps või teine vanem pöördunud kohtusse elatise väljamõistmiseks ja kohus ei ole veel elatise määramise asjus kohtuot sust teinud. Kohtumenetlusaegse elatisabi saamiseks peab olema väljastatud hüvitise saajale makseettepaneku määrus või hagi tagamise määrus. Kohtumenetlusaegse elatisabi saamiseks peab laps või teine vanem pöörduma Sotsiaalkindlustusameti poole hiljemalt 45-päeva jooksul makseettepaneku või hagi tagamise määruse saamisest. Kohtumenetlusaegse elatisabi suurus on seadusega kindlaks määratud summa, mida makstakse perioodiliselt üks kord kuus kuni 150 kalendripäeva eest. Enne 150 kalendripäeva täitumist lõpetatakse hüvitise maksmine juhul , kui: hagi tagamise määrus tühistatakse; elatisnõude kohtumenetlus lõpetatakse; ilmneb, et hüvitise maksmise tingimused ei olnud täidetud või ei ole enam täidetud; võlgnik täidab ülalpidamiskohustust seaduses ettenähtud ulatuses või kohtu poolt ettenähtud ulatuses; võlgniku surma korral või lapse surma korral. Väljamakstud hüvitise nõuab SKA tagasi vanema l t , kellelt on kohtuotsusega mõistetud välja elatis. Täitemenetlusaeg s e elatisabi saamiseks peab olema jõustunud kohtuotsus elatise välja mõistmiseks. Laps või vanem on pöördunud kohtutäituri poole, kuna teine vanem või vanemad ei maksa ettenähtud elatist ning alustatud on täitemenetlus. Täitemenetlusaegse elatisabi väljamakseid teeb SKA info põhjal , mida edastab kohtutäitur e-täituri kaudu. Hüvitise suurus on kuni 100 eurot kuus. Kohtutäiturid edastavad e-täituri kaudu igakuiselt info, kelle eest ja kui suures summas kuulub hüvitis väljamaksmisele. SKA poolt väljamakstud summad kuuluvad tagasi nõudmisele vanema või vanemate käest, kelle suhtes on täitemenetlus algatatud. Elatisabi menetlus toimub täna SKAIS2-s. Elatisabi taotlust saab täna esitada riigiportaalis (eesti.ee) , SKAIS2-s iseteenindus puudub, seega on SKAIS2- s vajalik käivitada iseteenindus ja ametniku portaalis täitemenetlusaegse elatisabi manuaalmenetluse loomise funktsionaalsus. Puude raskusastme tuvastamine ja sotsiaaltoetus Puue on inimese tervislikust seisundist tulenev vaegus või kõrvalekalle, mille korral on inimesel takistusi ja raskusi teistega võrdsetel alustel igapäevaelus hakkama saada ning ühiskonnaelus osaleda. Puude raskusastet tuvastatakse nii lastel, tööealistel kui ka vanaduspensioniealistel. Puude raskusastme tuvastamisel hinnatakse isiku puude raskusaste t ja kõrvalabi vajadus t . Selle tulemusel tekib isikul õigus puuetega inimeste sotsiaaltoetusele ja puudega isiku kaardile. Puuetega inimeste sotsiaaltoetus on mõeldud inimestele, kellel on tuvastatud puude raskusaste ja inimesel on erivajadusest tulenevaid lisakulutusi. Lisakulutused võivad olla seotud näiteks abivahendite või transpordi kasutamisega, hoolduse või rehabilitatsiooniga. Puuetega inimeste sotsiaaltoetus on perioodiline hüvitis, mida makstakse kord kuus ning mille suuruse arvutamise aluseks on sotsiaaltoetuse määr kuus. Puudega isiku kaardi väljastamise teenus on isikutele, kellel on tuvastatud puude raskusaste. Puudega isiku kaart väljastatakse isikule puude raskusastme kehtivuse ajaks , tõendamaks puude raskusastet. Puude isiku kaardi väljastamiseks moodustatakse infosüsteemis olevatest andmetest kokkulepitud formaadis fail, mis edastatakse trükikotta. Infosüsteemis säilitatakse kaardi väljastamise andmed. Puude raskusastme tuvastamine ja sotsiaaltoetuse teenus on alates 01.01.2017 kasutusel SKAIS2-s ametnikuportaalis, iseteenindus puudub. Käesoleva teenuse puhul tuleb SKAIS2 -te luua iseteenindus. Sotsiaalmaksu andmete töötlemine Isikustatud sotsiaalmaksu pensionikindlustuse osa keskmise suuruse arvutamisel liidetakse pensionikindlustatute isikustatud sotsiaalmaksu pensionikindlustuse osa suurused ning jagatakse pensionikindlustatute selle kalendriaasta pensionikindlustusstaaži kogusummaga. Pensioniindeksi arvestamise aluseks on 80 protsendi ulatuses eelmise aasta sotsiaalmaksu pensionikindlustuse osa laekumise muutus ja 20 protsendi ulatuses eelmise aasta tarbijahinnaindeksi muutus. Nende muudatuste alusel tekib indeks, mille kinnitab Vabariigi Valitsus. Indeksiga korrutatakse ehk indekseeritakse riiklike pensionite arvutamise aluseks olevaid näitajaid – pensioni baasosa ja aastahinnet, samuti rahvapensioni määra. Täna tehakse kõiki arvutusi SKAIS1-s, tulevikus tuleb viia kõik need arvutused SKAIS2-te koos ajalooliste andmetega ja nimetatud teenuse kasutamine on eelduseks pensioni kasutuselevõtuks SKAIS2-s. Pensioniõigused võib isiku soovil kanda üle kas Eestist EL institutsioonide pensioniskeemi või vastupidi, kumbagi valikut on isikul õigus kasutada ühe korra. Pensioniõiguste kandmi seks Eesti pensioniskeemist Euroopa ühenduste institutsioonide pensioniskee mi teeb SKA kalkulatsiooni isiku Eestis omandatud pensioniõigustele vastavate rahaliste vahendite suuruse kohta. Rahaliste vahendite suurus arvutatakse vastavalt pensionistaažile. Isiku Eestis omandatud pensioniõiguste rahalised vahendid kantakse EL Institutsioonidele üle, millest teavitatakse ka EMTA-t ning kui isik on liitunud II sambaga siis ka Väärtpaberikeskust, kes kannab II sambasse kogunenud vahendid SKA- le . Pensioniõiguste kandmi sel Euroopa ühenduste in stitutsioonide pensioniskeemist Eesti pensioniskeemi, kantakse EL Institutsioonist pensioniõigustele vastavad rahalised vahendid Eesti pensioniskeemi koos täiendavate dokumentidega. Võimalikust ülekandest teavitatakse EMTA-t. SKA sisestab oma andmebaasi isiku EL Institutsioonides töötatud aja. Täna toimub menetlus SKAIS1-s, tulevikus peab olema kogu arvutus ja menetlus SKAIS2-s ning oluline on ka ajalooliste andmete üle viimine SKAIS1-st SKAIS2-le. Finantsarvestus ja väljamaksed SKA-s on täna kasutusel teenused mõlemas infosüsteemis ehk nii SKAIS1-s ja SKAIS2-s, viimase lahutamatu ks osaks on EBS. Tuleviku vaates peavad olema kõik teenused SKAIS2-s, seega ka finantsarvestust ja väljamakseid jäävad teostama SKAIS2 ja EBS. Isikutele makstakse hüvitist vastavalt isiku soovile kas pangaarvele või kojukandeteenusena, viimast osutab SKA- le täna AS Omniva . Lisaks toimuvad välislepingute alusel väljamaksed välisriigi pangaarve te le nii kliendipõhiselt kui ka teostatakse väljamakse id välisriigi pädeva te le asutus t ele , edastades õigustatud isikute nimekirjad. Menetlus- ja finantstehingud peavad olema täielikult omavahel integreeritud. SKAIS2-e finantsmoodulis võetakse arvele kõik nõuded ja kohustused, tehakse vajalikud kinnipidamised näiteks kohtutäiturite aktide alusel ja tehakse tulumaksuarvutused. SKA-s on kolm teenust, mis kuuluvad tulumaksuga maksustamisele (pension, kahjuhüvitis ja vanemahüvitis). Samuti toimub finantsarvestuse nõuete arvele võtmine ja tehakse tasaarvestusi . SKAIS2-e finantsarvestus peab võimaldama tulu- ja sotsisaalmaksu deklaratsioonide täitmist ja edastamist. Iga kuu 8. kuupäeval (või muul kokkulepitud/klassifikaatoriga määratud kuupäeval) moodustatakse ESD ja TSD maksufailid SKAIS2-e andmete alusel. Kuna tulumaksuarvestuses on toimunud 01.01.2018 kehtima hakkavad muudatused, mis suurel määral muudavad ka SKA teenuste tulumaksustamist, on vajalik uute muudatuste arendamine SKAIS2-s. ESD ehk sotsiaalmaksu deklaratsioonide moodustami ne tuleb teostada kahel õiguslikul alusel: sotsiaalmaksu seaduse alusel riigi poolt makstavate erijuhtude sotsiaalmaksu andmete alusel ; kogumispensionide seaduse alusel täiendavate sissemaksete eest kuni kolme aastase lapse kasvatamise eest. Massmaksete ettevalmistamine peab toimuma jooksvalt kalendrikuu jooksul. Juhul, kui süsteem ei ole tuvastanud andmete kontrollimise käigus muudatusi, toimub väljamakse eelmise kalendrikuu summas. SKA-s on kohustus prognoosida järgmise perioodi väljamakseid ning vastavad summad riigikassas broneerida, mis tähendab vajadust etteantud perioodi väljamaksete mahu väljaselgitamiseks päringute koostamist. Väljamakseid teostatakse EBS-i kaudu kasutades AS Swedbanki pangakanalit „ Gateway “ ja AS SEB Pank puhul pangakanalit „Pangaliides“. Kolmandatesse pankadesse toimub väljamaksmine AS Swedbanki või AS SEB kaudu. Väljamaksete õnnestumise kohta saabuv info liigub pangast tagasi EBS ning sealt edasi SKAIS2-te. Püsiväljamakseid tehakse teenuste kaupa üldjuhul 1 kord kuus massmaksetena. Vahepealseid, st uute hüvitiste määramiste või jätkamiste väljamakseid , tehakse vastavalt vajadusele, kuid mitte harvem kui kord nädalas. Välisriikide pädevatele asutustele tehakse väljamakseid kord kvartalis. Puhkusetasu ja töötasu hüvitamine Puhkusetasu ja töötasu hüvitamise teenus on mõeldud tööandjatele, kellele hüvitatakse esitatud andmete alusel nende poolt tehtud kulutused seoses lisapuhkepäevadega isale enne lapse sündi või pärast lapse sündi; puudega lapse vanemale; kuni 14-aastaste laste ühele vanemale; lapse rinnaga toitmise vaheaegade eest keskmise töötasu maksmisega. Õigustatud isikute ringi kuuluvad ka vabade elukutsete esindajad (näiteks notarid, kohtutäiturid jne), kes ei ole äriregistris. Vabade elukutsete esindajad kasutavad isikukoodi registri numbri asemel. Seega peab SKAIS2 suutma eristada isikuandmeid eelpool nimetatud isikute puhul, kas isik kasutab teenust füüsilise isiku rollis või juriidilise isiku rollis. Täna on teenus kasutusel SKAIS1-s ning riigiportaalis (eesti.ee). SKAIS2-s peab olema loodud nimetatud teenuse taotlemiseks iseteenindus ja automaatmenetlus saab katta 90% ulatuses kogu teenusest. Iseteeninduses peab olema võimalik asutusel ka etteantud struktuurile fail üles laadida, ilma, et peaks sisestama kõiki alusandmeid ükshaaval. Kuriteoohvri riiklik hüvitis Teenus on mõeldud vägivallakuriteo tagajärjel kannatada saanud isikutele, kui vägivallakuritegu on toime pandud Eesti riigi territooriumil. Kurite o ohvri hüvitis koosneb ravikuludest, perioodilisest hüvitisest ja matusekuludest. Varaline kahju hüvitatakse kuni 80% ulatuses kuid mitte üle 9590 euro. SKAIS2 peab võimaldama kuriteoohvri riikliku hüvitise maksmisel perioodilisi makseid ning ühekordsete maksetena ravikulude ja matusekulude hüvitamist. Isiku vaates peab suutma süsteem arvestada, et hüvitist makstakse kuni 9590 euro täitumiseni. Varalise kahju hüvitamisel peab saama sisestada tehtud kulutused, lisada kultust tõendavad dokumendid ning teha arvestuse, mille alusel kuulub hüvitamisele kuni 80% ulatuses tehtud kulutustest. Kuriteoohvri riiklike hüvitistena väljamakstud summad nõutakse tagasi kahju tekitajalt, seega peab olema SKAIS2-s kuriteoohvri riiklikud hüvitised seotud regresside menetlusega. Tõend i A1 väljastamine Tõendi A1 väljastamise teenus on mõeldud isikutele, kes viibivad välisriigis lähetuses või t öötavad mitmes riigis. Seda võivad taotleda nii tööandja, töötaja kui ka ametnik. Tõendiga A1 määratakse kindlaks isiku kindlustajariik ja selle väljastab riik, mille sotsiaalkin dlustuse õigusakte kohaldatakse. Tõendiga A1 tõendab välisriigis lähetuses viibiv või mitmes riigis töötav isik vastu võtva riigi ametkonnale, et tema suhtes ei kohaldata ühegi teise tema tööga seotud riigi sotsiaalkindlustuse õigusakte. Üldise põhimõtte kohaselt kohaldatakse E L-is töötajate ja füüsilisest isikust ettevõtjate suhtes selle liikmesriigi sotsiaalkindlustus e õigusakte, kus nad tegutsevad ehk töökohariigi sotsiaalkindlustuse õigusakte . See tähendab, et olenemata töötaja elukohast ja tema tööandja asukohast kehtib selle riigi õigus, kus isik füüsiliselt töötab. Seda põhimõtet nimetatakse töökohariigi õiguseks. T õendi A1 eesmärk on määrata kindlaks piiriülese töötamise puhul isiku kindlustajariik ning vältida olukorda, kus isik on sotsiaalselt kindlustatud mitmes riigis samaaegselt või vastupidi – pole kindlustatud üheski riigis . Täna on taotlust võimalik esitada riigiportaali (eesti.ee) ka udu ja see laekub otse SKAIS1 (A1 moodul) infosüsteemi, kus menetlemine toimub manuaalselt. SKAIS2-s peab olema loodud tõendi A1 taotlemiseks ja väljatrüki teostamiseks võimalus iseteeninduses. Tõendi väljastamine peab olema automaatprotsess. Kui ärireeglitest tulenevad tingimused on täidetud , peab süsteem väljastama tõendi automaatselt, kinnitama selle digitempliga ning võimaldama ka väljatrükki. Hetkel vahetavad kõik asutused infot paberkandjal ( tõendi A1 ko opiatena), kuid 2018 – 2019 peavad EL liikmesriikide sotsiaalkindlustusasutused liidestuma Euroopa Komisjoni poolt loodud EESSI ( Electronic Exchange of Social Security Information ) IT-süsteem iga , mis aitab sotsiaalkindlustusasutustel kõikjal EL - is vahetada teavet kiiremini ja turvalisemalt, nagu on nõutud sotsiaalkindlustuse koordineerimist käsitlevate EL - i määrustega. Kogu piiriüleseid sotsiaalkindlustusjuhtumeid käsitlev teabevahetus hakkab toimuma riiklike ametiasutuste vahel struktureeritud elektrooniliste dokumentide SED-ide vahendusel. Sisuliselt kõik, mis praegu liigub paberil, peaks tulevikus liikuma läbi EESSI süsteemi. Nii ka kindlustajariigi määramise dokumendid. Kuni EESSI rakendumiseni peab SKAIS2-s olema võimalik moodustada koondaruannet excelis A1 tõenditest, mida SKA esialgu hakkab vahetama Soome pädeva asutusega sTesta läbi. Riigipoolne sotsiaalmaksu hüvitamine Riigipoolne sotsiaalmaksu tasumise teenus on mõeldud isikutele, kelle eest tööandja ei tasu sotsiaalmaksu ning kellel puudub ravikindlustus, kuid kes kasvatavad Eestis väikeseid lapsi või kes on taotlenud Eestis rahvusvahelist kaitset ning saanud politsei-ja piirivalveametilt rahvusvahelise kaitse andmise otsuse ja Eestis elamise loa või kes on Eesti kodanikud, kellele SKA maksab Eestisse tagasipööduja toetust või riiklikku pensioni. Tegemist on mitterahalise hüvitisega, mida SKA maksab teatud hüvitiste saamisel isiku eest automaatselt ja isiku avalduse alusel , juhul kui määratud tingimused on täidetud. Näiteks perehüvitiste puhul vanemahüvitise määramisel peab käivituma automaatselt riigipoolse sotsiaalmaksu hüvitamise teenus ning vanemahüvitise saaja eest tasub sotsiaalmaksu SKA . SKA tasub isiku eest sotsiaalmaksu, mille tulemusena tekib isikul ravikindlustus. Täna on teenus SKAIS1-s kasutusel. Riigipoolse sotsiaalmaksu hüvitamise teenuses peab olema võimalik alustada menetlust ka kliendi poolt taotluste esitamisega. Tegemist on üldjuhul siiski automaatmenetlusega. Täna on teenus SKAIS1-s tervikuna kasutusel, tulevikus peab teenus olema kasutusel SKAIS2-s, üleviimisel on oluline jälgida, milliste teiste SKA teenuste tulemusel tekib automaatne riigipoolse sotsiaalmaksu hüvitamise kohustus. Kahjuhüvitis Teenus on mõeldud isikutele, kellel on tekkinud tervisekahjustus tööõnnetuse või kutsehaiguse tagajärjel ning tööandja on likvideeritud ja puudub ka õigusjärglane. Kahjuhüvitis on tööandaja süül tekkinud otsese varalise kahju või saamata jäänud tulu hüvitamine isikutele, kellel on tuvastatud kutsehaigus või tööõnnetuse tagajärjel tekkinud tervisekahjustus või surma korral toitja ülalpeetavatele. Kahjuhüvitise moodustavad perioodilised maksed ja lisakulude hüvitamine. Kahjuhüvitise määramisel ja suuruse kindlaks tegemiseks on vajalik SKA ekspertarsti hinnang ning pensioni või töövõime toetuse suurus. Infosüsteem peab võimaldama ekspertarstihinnangu sisestamist ning arvestama vajadusel pensioni või töövõime toetuse suurusega. Kahjuhüvitise perioodilise hüvitise suurus arvutatakse menetleja poolt käsitsi diferents hüpoteesi alusel, seega peab olema võimalik SKAIS2-te sisestada menetleja poolt välja arvutatud summat ning alusandmeid. Kahjuhüvitise suurus võib olla kindlaks määratud ka kohtuotsusega, seega peab olema võimalik ka faili lisamine. Lisakulude hüvitamisel on vajalik luua võimalus kulutusi tõendavate dokumentide lisamiseks SKAIS2-te. Etteantud reeglitele peab süsteem võimaldama ka taotluse ja lisakulude kuludokumentide esitamisel automaatmenetlust. Õppelaenu kustutamine Õppelaenu osali s e kustutamise teenus on mõeldud lapsevanematele, kes kasvatavad kuni 5-aastast last ning kellel on õppelaen. SKA kustutab kvartaalsete maksetena krediidiasutusele ühe lapsevanema õppelaenu, mille kohta on tehtud õppelaenu kustutamise otsus. Täna toimub SKA poolt õppelaenude osaline kustutamine läbi SKAIS1. Nimetatud teenuse puhul enam uusi taotlusi ei esitata, toimub üksnes kehtivate otsuste alusel hüvitamine krediidiasutustele. Sotsiaalkindlustusametil tuleb väljamaksed teostada aastani 2022. Nimetatud teenust ei ole plaanis arendada SKAIS2-te kuna uusi menetlusi ei lisandu. Alates 01.01.2018 on SKA-s õppelaenu kustutamise teenus, mis on mõeldud õppelaenu saajale, kellel on tuvastatud puuduv töövõime või kelle lapsel on tuvastatud raske- või sügav puue. SKA kustutab õppelaenu kustutamise otsuse alusel ühekordse maksena krediidiasutusele laenusaaja surma, temal puuduva töövõime tuvastamise või laenusaaja lapsel raske või sügava puude tuvastamise korral õppelaenu. Teenust ei arendata SKAIS1-te ja SKAIS 2 -s peab olema võimalik menetleda see universaaltoetuse väljamaksmise teenuses. Muud hüvitised Täna SKAIS1 sellist teenust ei ole, kõik SKA poolt pakutavad teenused on teenusepõhiselt arendatud. SKAIS2-s on vaja luua nn univers aaltoetuse väljamaksmise teenus . Nimetatud teenus on üks nes ametnikuportaalis taotletav ja menetletav. Teenus peab võimalda m a ametnikul määratleda kliendipõhiselt, millist teenust soovitakse määrata. Hüvitise kontrollid ja summad arvutatakse süsteemi väliselt ametniku poolt ning süsteemi sisestatakse üksnes hüvitise summa. Süsteem kontrollib automaatselt vaid surma fakti, mis lõpetab hüvitise saamise automaatselt. Ülejäänud kontrollid teostatakse manuaalselt ja igakui ne väljamaks e toimub üksnes siis, kui menetleja on selle välja maks miseks suunanud. Sotsiaaltoetus Eestisse tagasi pöördujale Teenus on mõeldud välisriigist Eestisse elama asunud Eesti kodanikule või eesti rahvusest inimesele ja temaga koos Eestisse elama asunud abikaasale, lapsele või vanematele, kes on vanaduspensioni ealised ning kelle igakuine s issetulek on alla rahvapensioni määra. Toetuse eesmärgiks on tagada sissetulek vanaduspensionieas tagasipöördujale , kellel puudub Eestis vanaduspensioni määramiseks vajalik tööstaaž. Hüvitist makstakse perioodiliste maksetena üks kord kuus ning hüvitise suurus arvutatakse rahvapensioni määras. Teenus on täna kasutusel SKAIS1-s, mille kaudu toimuvad igakuised perioodilised maksed. Tagasipöörduja sotsiaaltoetuse määramisel peab automaatselt käivituma riigipoolse sotsiaalmaksu hüvitamise teenus. SKAIS2-s peab olema võimalik nimetatud teenust välja maksta universaaltoetuse väljamaksmise teenuse kaudu. Olümpiavõitja toetus Teenus on mõeldud inimestele, kes on tulnud olümpiamängudel või paraolümpiamängudel Eesti Vabariiki esindades olümpiavõitjaks. Olümpiavõtja toetus m ä äratakse kas vanuse alusel kü mme aastat enne vanaduspensioni ea saabumist või osalise või puuduva töövõime tuvastamisel alates töövõime kao tuvastamisest. Olümpiavõitja toetus on rahaline perioodiline hüvitis, mida makstakse välja üks kord kuus. Hüvitise suuruse määrab Riigikogu iga -a astaselt riigieelarve seadusega. Teenus on täna kasutusel SKAIS1-s, mille kaudu toim u vad perioodilised maksed. Olü mpiavõitja toetus vanuse alusel on kindlaks määratud summa. Olümpiavõitja toetus töövõime alusel on kindlaks perioodiks (perioodiks, kui töövõime kaotus on tuvastatud) määratud hüvitis, mille suurus sõltub sellest , kas isikul on osaline töövõime või puuduv töövõime. SKAIS2-s peab olema võimalik nimetatud teenust välja maksta universaaltoetuse väljamaksmise teenuse kaudu. Represseeritu toetus ja tunnistus Teenus on mõeldud okupatsioonirežiimide poolt represseeritud või nendega võrdsustatud inimestele. R epresseeritule või represseerituga võrdsustatud inimesele väljastatakse represseeritu tunnistus, millega saab tõendada õigust represseeritud inimestele ettenähtud soodustustele. Inimesele , kellele on väljastatud represseerit u tunnistus, tekib õigus represseeritu hüviti sele, mis on rahaline hüvitis, mida makstakse represseeritule üks kord aastas. Täna on teenus kasutusel SKAIS1-s, kus isiku taotluse ja täiendavate dokumentide alusel teeb SKA otsuse, et isikul on õigus represseeritu tunnistusele. SKAIS1 moodustab nimetatud otsuse kohta trükise ja vajalikest andmetest moodustatakse fail, mis edastatakse trükikotta, mille alusel trük itakse represseeritu tunnistus (plastik kaart) , mille SKA isikule väljastab. SKAIS2-s peab olema võimalik nimetatud hüvitist v älja maksta universaaltoetuse väljamaksmise teenuse kaudu ning väljastada isikutele represseeritu tunnistus i , sh ka duplikaate . 2.3. SKAIS alamsüsteemide toimimine Täna kasutusel olev SKAIS koosneb tehniliselt kahest infosüsteemist, milleks on SKAIS1 ja SKAIS2. Tuleviku eesmärgiks on viia kõik SKA poolt pakutavad teenused SKAIS2-le ning kõik riigiportaalis eesti.ee olevad tänased SKA teenused peavad olema kätte saadavad SKAIS2 iset eeninduses. Käesolev riigihange on välja kuulutatud eelpool nimetatud eesmärgi täitmiseks ning sellest tulenevate tööde teostamiseks. SKA teenustes ristkasutatakse andmeid (näiteks SKAIS2-s paikneva puude raskusastme tuvastamise teenuse andmeid vajab sotsi aalse rehabilitatsiooni teenus SKAIS1-s ) , mistõttu on vajalik teenuste üleviimisel arvestada erisustega, kui teenuses kasutatavad andmed asuvad erinevates infosüsteemi des . Lisaks on SKA-l kohustus hüvitisi määrata, teha neist ümberarvutusi ja maksta hüvitisi tagasiulatuvalt, mistõttu on nii varasemate ärireeglite kasutamise vajadus kui ka varasemate andmete migreerimise vajadus. SKA teostab teenuste eest väljamakseid nii SKAIS1 -st kui ka SKAIS2-st majandustarkvara EBS kaudu, mis on SKAIS2 lahutamatu moodul väljamaksete teostamisel. SKAIS2 on juurutatud SKA- le järgmised EBS-i moodulid: Oracle General Ledge r ehk Pearaamat Oracle Accounts Payables ehk Ostureskontro Oracle Accounts Receivables ehk Müügireskontro Oracle Cash Management ehk Pangamoodul Käesoleva hanke raames EBS mooduli arendusi ega hooldust ei hangita. SKA teostab igakuiselt enam kui 700 000 makset , mis moodustavad kokku ca 200 000 000 eurot väljamakseteks igas kuus. Hüvitisi makstakse välja nii isikute arveldusarvetele kui ka kojukande teenusena. SKAIS2 arendamisel tuleb arvestada, et SKAIS2 annab sisendi väljamaksete tegemiseks EBS-ile ja digitembeldab maksekorraldusi. Samuti vahendab SKAIS2 kojukande infot Omnivale . Rahaliste hüvitiste väljamaksmiseks saab EBS infot SKAIS2-st rahaliste hüvitiste ma ksete kohta. EBS on liidestatud ja kasutab AS Swedbanki pangakanalit „ Gateway “ ja AS SEB Pank puhul pangakanalit „Pangaliides“ . Planeerimisel on liides Riigikassaga üle x-tee. Kojukande teenus on hangitav teenus, mida hetkel osutab AS Omniva . EBS edastab iga kuu üle x-tee kojukande teenuse osutajale hüvitiste väljamaksmise info ning kuu lõpus saab info teenuseosutajalt hüvitiste väljamaksmise õnnestumiste kohta . SKAIS1 on 1999. aastast kasutusel olev infosüsteem, mis toetab hüvitiste arvutamist ja rahal iste väljamaksete teostamist, mida saavad kasutada ainult ametnikud. SKAIS2 on kasutusel 2017 .a alguse st. Erinevalt SKAIS1-st peab SKSAIS2 võimaldama isikutel ja SKA partneritel kasutada SKA teenuseid üle veebi ja iseteeninduskeskkonna kaudu, sh kasutades nutiseadme id. Lisaks hakkab SKAIS2 pakkuma erinevat aruandlust (a ruandluse lahendus ei ole käesoleva riigihanke skoobis) . SKAIS2 on mõeldud kasutamiseks: klientidele (läbi iseteeninduse) ; SKA ametnikele ja töötajatele (läbi ametnikuportaali) ; j uriidilistele isikutele, kes on SKA- ga sõlminud halduslepingu (läbi teenuseosutajaportaali ) ; a nalüüsiandmete ja statistika kasutaja tele (läbi analüüsimooduli) . S KAIS2 võimaldab kliendil läbi iseteeninduse saada operatiivselt infot talle võimaldatud teenustest, pakutavatest teenustest ( p roaktiivsete teenuste info ) , samuti esitada taotlusi, jälgida teenuste menetlusprotsessi, saada teated ja teavitusi teenuste pakkumuste, saamise või lõppemiste kohta . 2. 4. SKAIS teenuste kasutajagrupid Kasutajaliides isikule ehk i seteenindus Iseteeninduse kasutajad on füüsilised või juriidilised isikud. Iseteeninduses peavad kasutajale olema kättesaadavad kõik t alle pakutavad ja osutatavad teenused, samuti peab olema näha teenuste menetluste seis ning ajalugu. Füüsilise või juriidilise isiku taotlusi võib iseteeninduses esitada ka volitatud isik. Seega peab olema tagatud volituste haldus, kus isikul on võimalik teha volitus nii iseteeninduses, ametnikuportaalis või tekivad esindusõigused Äriregistri või Rahvastikuregistri andmete põhjal. Iseteenindus peab arvestama puuetega inimeste kasutusvajadusi. Realiseerida tuleb vaegnägija liides (teksti suuruse, kontrastsuse muutmine). Iseteenindus keskkond peab toetama mitmekeelsust ja olema vähemalt eesti-, vene ja inglisekeel ne , sh peaks olema võimalik uute keelte lisamine. Iseteenindus es peab isikul olema võimalik näha, milliseid andmeid tema kohta on kogutud ning milliseid andmed võetakse teistest andmekogudest ja milliseid saadetakse teistesse andmekogudesse. Kasutajale kuvatakse teenuste eeltäidetud taotlusvormid teenuste saamiseks. Iseteeninduses pea vad olema nähtavad vähemalt: isiku andmed; isikule pakutavad ja osutatavad t eenused ja teenuste ajalugu ; isikule tehtud pakkumused (tema andmete põhjal teave te enustest, millele on tal õigus); hüvitiste väljamaksete info ; võimalus teenuste taotlemiseks: taotluse esitamine – eeltäidetud andmetega oma tahteavalduse esitamine toetuse/teenuse saamiseks; taotluse juures viis, kuidas otsusest teavitatakse; teavitused uute reeglite, tähtaegade saabumise või vaj alike toimingute tegemise kohta; võimalus edastada porta ali teavitusi kliendile e-post i /SMS-iga ; printimine, salvestamine, vahesalvestamin e, kinnitamine . Kasutajaliides ametnikule ehk a metnikuportaal Ametnikuportaalis SKAIS2-s on juba täna loodud isiku põhine vaade (SKAIS1 on teenuste - põhine vaade). Ametnikuportaalis peab saama teha kõiki toiminguid , mida saab teha isik iseteeninduses või teenus e osutaja teenus e os u tajaportaalis . Lisaks pea b olema loodud võimalus laadida üles dokumente, mis tõendavad teatud tegevusi. Sisestatud dokumendid ja süsteemis loodud dokumendid peavad olema nähtavad ametnikuportaali kasutajale ning kokkulepitud ulatuses nii iseteeninduses kui ka teenuseosutajaportaalis . I siku vaates peab olema t agatud: taotluste vastuvõtmine, kusjuures taotlused peavad olema eeltäidetud , ning ka puudustega taotluste vastu võtmine; juba sisestatud andmed peavad olema järgmiste menetlusetappide men e tlejatele nähtavad ja kasutatavad, juba süsteemi sisestatud andmeid ei pea uuesti sisestama; teenuste erinevad menetlusetapid peavad olema nähtavad; arvutuskäik peab olema menetleja jaoks arusaadaval kujul visualiseeritud; otsuste/vajalike trükiste koostamine; rahalis ed vaated, sh ajaloolised and m e d. Kasutajaliides t eenuseosutaja le ehk teenuseosutaja portaal Teenuseosutaja portaali kasutajaks on juriidilised isiku d , kes on SKA- ga sõlminud halduslepingu sotsiaalteenuste osutamiseks (teenused, teenuste hind, lepingu tähtae g). Teenuseosutajaportaalis peavad olema loodud võimalus ed: sisestada/uuendada teenuse alustamise vabade aegade info kalendervaatesse; vaadata SKA teenuseotsuse andmeid; registreerida inimesega sõlmitud teenuse osutamise kokkulepe , sh teenuse alustamise kuupäeva ; planeerida inimesele teenuse osutamist ajalises ja rahalises mõõtmes, sh pidada isikupõhist limiidi arvestust (tegevusplaan e ajakava/kalendervaade); vaadata inimese teenuste ajalugu; vaadata inimese kohta koostatud dokumente ja kokkuvõtteid; koostada dokumente vastavalt õigusaktide nõuetele ja etteantud andmeväljadele, juba eeltäidetuna kuvatakse andmed teist est andmebaasidest/registritest, allkirjastada ja esitada SKA ametnikule ; täita osutatud teenuse andmestik vastavalt määruses sätestatud andmekoosseisule. Andmestik on ühendatud ajakavaga ; kinnitada teenuse osutamise andmestiku alusel süsteemi poolt formeeritud isikupõhine teenuste aruanne, mille alusel genereeritakse teenuste arve automaatselt. Arve tasutakse automaatselt SKAIS2 arvestusmooduli kaudu; registreerida teenuse osutamisega seotud isikupõhised pöördumised; esitada taotlus teenuse osutamise lepingu sõlmimiseks, kusjuures taotluse esitamisel kontrollitakse teenuseosutaja andmeid teistest registritest (tegevusluba, maksuvõlg). 2.5 . SKAIS arendustööde teostamise üldised ärilised nõuded Arendustööde teostamisel tuleb arvestada järgmiste üldiste nõuetega: SKAIS2-s peab olema kliendi põhine vaade ning võimalik alusandmete ristkasutus; SKAIS2 kasutajate rollid ja privileegid peavad olema kooskõlas isikuandmete ja delikaatsete isikuandmete töötlemisele kehtestatud reeglitega; p eab olema võimalik erinevate kanalite kaudu saabunud taotluste vastuvõtmine, registreerimine ning vajadusel täiendavate dokumentide lisamine; p eab olema võimalik kokkulepitud reeglitel automaatmenetluse käivitamine, mille tulemusel tehakse isikule pakkumus või koostatakse otsus; SKAIS2 peab kontrollima regulaarselt hüvitise/teenuse määramise tunnuste komplekti isiku kohta, arvesta ma teistest andmekogudest saabunud andmeuuendusi ning käivita ma automaatselt vajalikud tegevused; manuaal menetlusse suunamine toimub üksnes juhul , kui süsteem ei saa või ei ole volitatud auto maat menetlust läbi viima; peab olema võimalik menetluste uuendamine ilma avalduseta; kogu teenuste tööprotsess peab olema läbi viidud infosüsteemi s ; dokumendid registreeritakse süsteemis ning vastavalt dokumendi liigile digitembel d atakse (näiteks kõik otsused digitembeldatakse ); tööülesannete suunamine menetlejatele peab toimuma automaatselt ja/või manuaalselt, vastavalt kokkulepitud reeglitele; süsteem lisab tähtajad ja jälgib nende saabumist kokkulepitud reeglite alusel ning saadab teavitusi nii ametnikuportaalis kui ka iseteeninduses; peab olema võimalik teenuseosutajate ja teenuste lepingute ning arvete haldamine; peab olema võimalik ärireeglite haldamine, mis võimaldab hüvitisi määrata ja ümber arvutada tagasiulatuvalt kehtinud ärireeglite alusel; k uivõrd SKA väljastab isikule erinevate staatuste tõendamiseks erinevaid tunnistus i /kaarte (sh pensionitunnistus, puudega isiku kaart, represseeritu kaart ) peab SKAIS2 olema võimeline edastama trükikojale andmefaile väljatrükkimisele kuuluvate andmetega. Juhul kui SKA hangib endale selleks spetsiaalse printeri, siis peab SKAIS2 suutma edastada eelnimetatud andmed sinna. SKAIS2 peab säilitama info, kellele, mis kuupäeval, millise kanali kaudu ja kelle poolt on kaart väljastatud. Hangitav skoop H angitav skoop koosneb 2 osast (edaspidi Osa 1 ja Osa 2 ), mõlemale osale sõlmitakse eraldi raamleping . Osad on: Osa 1: SKAIS infosüsteemi arhitektuuri korrastamine , SKAIS2 jätkuarenduste elluviimine puuduolevate funktsionaalsuste realiseerimisek s ning SKAIS2 tarkvara hooldus , sh : Arhitektuuri analüüs; Arhitektuuri muudatuste arendus, sh ü ldkasutatava te komponen tide (sh nt isikute haldus , dig i tembeldamine , dokumendihoidla, dokumendi generaator jne) arendus ; X-tee liides te arendus infosüsteemide vahel ( vt. Lisa 1.5. „ SK2 andmevahetusteenused “ ) ; Liides te arendus ärikomponentide vahel ; Olemasolevate teenuste vastavusse viimine uue arhitektuuriga ; Uute teenuste arendamine ja andmemigratsioon SKAIS1-st (sh analüüs, konsultatsioon) ; SKAIS2 jooksvate muudatusvajaduste realiseerimine ; SKAIS2 tarkvara hooldusteenus . Osa 1 raames arendata vad k asutajaliidese d teevad SKA teenused kättesaadavaks erinevatele kasutajagruppidele. Konkreetses kasutajaliideses arendatavad teenused peavad alluma ühtsele kontseptsioonile ning järgima mittefunktsionaalseid nõuded. Kasutajaliideste loomisel personaal- ja tahvelarvutite jaoks tuleb tehnoloogiate valikul ning arhitektuuris arvestada dünaamilis e veebidisaini nõudega ( Responsive web design ): http://en.wikipedia.org/wiki/Responsive_web_design Iseteeninduse keskkonna jaoks tuleb luua eraldi kasutajaliides nutitelefonidele. Osa 2 : Kasutajaliideste disainimine ametniku le, isikule ja teenuseosutajale , sh: UX-i analüüs ; UI (kasutajaliidese disain), sh: Kujunduselemendid Ekraanivormide näidised ; Olemasoleva stiiliraamatu muutmine ja täiendamine vastavalt äri- ja UX analüüsi tulemitele ; Uute teenuste arendusprotsessis arendaja poolt teostatud HTML prototüüpide üle vaat amine, nõuetele vastavuse kontrollimine ja kinnitamine . Arvestada tuleb (sh kujunduselementide valikul) , et kasutajaliideste loomisel personaal- ja tahvelarvutite jaoks tuleb kasutada dünaamilist veebidisaini ( Responsive web design ): http://en.wikipedia.org/wiki/Responsive_web_design . Iseteeninduse keskkonna jaoks tuleb luua eraldi kasutajaliides nutitelefonidele . Tööde tellimise põhimõtted Tööde teostamiseks sõlmitakse hankelepingud või esitatakse tööde tellimuskiri. Pakkuja ülesandeks on olla valmis: teostama SKAIS2 arendustöid f unktsionaalsuse põhiselt, kus sisendiks on konkreetse tulemi (skoobi) tellimus, sh tähtaeg ja/või piirsumma ; teostama SKAIS2 arendustöid a rendusmeeskonna töötundide põhiselt, kus arendused realiseeritakse agiilse arendusprotsessi põhimõtetel; andma arendustega seotud konsultatsioone ja koolitusi. SKAIS2 arenduste indikatiivne teekaart (2018 -2019) LINK Excel.Sheet.12 "\\\\sotsiaalministeerium.ee\\dfs\\Groups\\Organisatsioonid\\TEHIK\\TULEVIK\\SKAIS2 Var 3\\SKAIS teekaardid_koond 211217.xlsx" "Teekaart Hankesse 131217!R1C1:R14C67" \a \f 4 \h \* MERGEFORMAT Hanke osad ja teenused 2018 2019 IV I II III IV I II III IV Osa 1: Arhitektuuri korrastamine. SKAIS2 jätkuarendused. SKAIS2 hooldusteenus. Arhitektuuri analüüs Arhitektuuri muudatuste, liideste jm arendus Olemasolevate teenuste uuele arhitektuurile viimine Uute teenuste arendus: Perehüvitiste funktsionaalsus Uute teenuste arendus: Hindamisvahendi funktsionaalsus Uute teenuste arendus: Arvemenetlus teenuseosutajatega Uute teenuste arendus: Pensionid Uute teenuste arendus: Sotsiaalteenused - Abivahendid SKAIS2 jooksvate muudatusvajaduste realiseerimine SKAIS2 tarkvara hooldusteenus Osa 2: Kasutajaliideste disainimine ametnikule, isikule ja teenuseosutajale . Märkused: Arendustööde ajaplaan on koostatud tänase parima teadmise põhjal. Arhitektuuri muudatuste ja sellega seonduvate tööde täpsem maht ning uute teenuste arenduste järjestus ja ajaraam täpsustuvad arhitektuuri analüüsi tulemina. Teekaart võib muutuda tulenevalt poliitikamuudatustest . Arenduste ajaplaani koostamisel on järgitud järgmisi põhimõtteid: Esmaselt viime läbi arhitektuuri muutmise analüüsi. Pärast arhitektuuri muutmise analüüsi valmimist realiseerime: arhitektuuri muutused; iseseisvad baaskomponentide moodulid. Seejärel viime olemasolevad teenused vastavusse uue arhitektuuriga ning alustame uute teenuste arendustega. Jätkuarendus i ( väikearendusi) ja hooldustöid teostatakse kogu raamlepingu perioodil. Lisad Lisa 1.1 . Mittefunktsionaalsed nõuded Lisa 1.1 .1. Nõuded infosüsteemi dokumenteerimisele Lisa 1.2 . Front-end arendusreeglid Lisa 1.3 . Lähtekoodi halduse kirjeldus Lisa 1.5 . IT-profiil (tehnilised nõuded e-teenustele) Mittefunktsionaalsed nõuded arendustele Versioon: 1.0 Käesolev dokument määrab kvaliteedi- ja mittefunktsionaalsed nõuded uutele infosüsteemidele ning nende dokumentatsioonile. Käesolevat dokumenti tuleb vaadata kui arenduste kvaliteedi- ja mittefunktsionaalsete nõuete põhidokumenti. Põhidokumendi ja viidatud dokumentide erisuste puhul tuleb lähtud põhidokumendis kirjeldatust. Põhidokumendis viidatud Sotsiaalministeeriumi poolt koostatud dokumentide ja kolmandate osapoolte poolt koostatud dokumentide erisuste puhul t lähtuda Sotsiaalministeeriumi poolt loodud dokumentides kirjeldatust. Kui mõnda nõuet ei ole võimalik või otstarbekas täita, tuleb selle mittetäitmise fakt ja põhjendus välja tuua pakkumuse esitamisel. Nõudeid tuleb järgida ka olemasolevate infosüsteemide versiooniuuendustel nii palju kui versiooniuuenduse käigus võimalik. Nõude Nõude Nõude sisu Seletused liik nr. Vastavus üldistele standarditele 1.1 Lahendus peab olema kooskõlas riigi IT https://www.mkm.ee/sites/default/files/riigi_it_koosvoime_raamistik.pdf koosvõime raamistiku nõuetega. 1.2 Lahenduse X-tee teenused peavad https://www.ria.ee/ee/xtee-juhendid.html vastama RIA nõuetele. 1.3 Lahendus peab vastama Sotsiaalministeeriumi IT-profiilile. 1.4 Rakendus peab olema kirjutatud Tervise infosüsteemi ISKE turvaklass on K2T3S2. arvestades selle rakenduse poolt töödeldavatele andmetele määratud https://www.ria.ee/ee/iske-kkk.html ISKE turvaklassi nõudeid. 1.5 Lahendus peab vastama veebide https://www.mkm.ee/sites/default/files/veebide_raamistik.pdf koosvõime raamistikule. 1.6 Veebirakenduse kasutajaliides peab http://www.w3.org/TR/WCAG20/ vastama vähemalt WCAG 2.0 tasemele AA. 1.7 Veebipõhine kasutajaliides peab Valideerimiseks kasutatakse vastavaid validaatoreid: http://validator.w3.org/ Kui on tegu olemasoleva ühilduma täielikult standarditega süsteemi edasiarendusega, siis tuleb järgida olemasolevat HTML ja CSS versiooni. vähemalt HTML 4.01 ja CSS 2.1, eelistatult HTML 5 ja CSS 3 1.8 ID-kaardiga allkirjastamisel on eelistatud Arendaja loodud lahenduse dokumentatsioonis (nt detailanalüüs vms) peab olema välja toodud veebipõhine digidoc-teenuste digidoc-teekide versioonid ja kasutuskohad kasutamine. 1.9 Veebirakendus peab probleemideta Kui pole arenduse eraldi kokku lepitud teisiti, siis on OWASP ASVS 3.0 tasemeks 2 (https://www.owasp.org/ läbima OWASP ASVS baasil põhineva index.php/Category: testi OWASP_Application_Security_Verification_Standard_Project). Kinnise lähtekoodiga kommertstoote kasutamisel ei eeldata ligipääsu kinnisele lähtekoodile.Tellija poolset turvatestimist teostab kolmas sõltumatu pool.Selline esmane kolmanda poole turvatestimine tellitakse tellija finantseeringul. Ilmnenud vigade korral ja peale nende parandamist peab järeltestimise rahaliselt kompenseerima arendaja, kui tellija vastava nõudmise esitab. 1.10 Krüptoalgoritmide ja räsifunktsioonide Arendaja loodud lahenduse dokumentatsioonis (nt detailanalüüs vms) tuleb välja tuua kasutatavad krüpto- ja kasutamisel tuleb järgida uusimat RIA räsialgoritmid, nende võtmepikkused, kasutuskohad, sh SSL sertifikaatide kasutuskohad. Värskeima uuringu kodulehel avaldatud krüptograafiliste leiab aadressilt https://www.ria.ee/ee/iske-dokumendid.html algoritmide kasutusvaldkondade ja elutsükli uuringut, st lahendustes ei tohi kasutada uuringus väljatoodud ebaturvalisi algoritme ja võtmepikkuseid 1.11 Andmete edastus peab välisvõrgu liikluses olema kaitstud kasutades turvalisi ja üldteada andmeedastusprotokolle 1.12 Infosüsteem peab kasutama serveri kellaaega ja ajatsooni 1.13 Süsteemi edasiarendamisel/loomisel peab arvestama selle võimaliku laiendamisega nii andmemahtude, kui ka kasutajate arvu osas.  1.14 Rakendus peab olema tehniliselt Näiteks, kui rakendusel on eraldi turvakontekstidega liidesed ametnikule ja kodanikule, peab rakendus tükeldatud vastavalt loogilisele jaotusele. olema jagatav kaheks eraldi liidesekomponendiks ning nende mõlema poolt kasutatavaks andmebaasiks. Saadud osised peavad olema eraldi versioneeritavad ja paigaldatavad 1.15 Avalike e-teenuste loomisel peab https://www.valitsus.ee/et/eesmargid-tegevused/valitsusasutuste-visuaalse-identiteedi-stiilijuhis arvestama valitsusasutusele kehtestatud visuaalse identiteedi stiilijuhisega 1.16 Avalike e-teenuste loomisel peab https://www.mkm.ee/sites/default/files/iseteeninduskeskkondade_raamistik_08.07.2015.pdf arvestama valitsusasutustele kehtestatud iseteeninduskeskkonna raamistikuga https://www.mkm.ee/sites/default/files/iseteeninduskeskkondade_raamistiku_kasutatavuse_nouded_dets.pdf Nõuded rakenduse arhitektuurile 2.1 Rakenduse, andmebaasi ja kolmanda Arendaja loodud lahenduse dokumentatsioonis (nt detailanalüüs vms) peab olema välja toodud kasutatavate osapoole komponentid peavad olema komponentide nimetused ja versioonid. Versiooni eluea lõppu ei loeta võrdseks terve komponendi eluea sellised, mille eluea lõpp (EOL) pole lõpuks, st versiooni tugi võib aeguda, kui uus versioon on välja lastud. teadaolevalt vähem kui 2 aasta pärast. 2.2 Tulevase ja olemasolevate Süsteemi jõudlus peab vastama kokkulepitud topoloogial eelanalüüsi ja lähteülesande käigus välja toodud infosüsteemide platvormid jõudlusnäitajatele. (rakendusserver, andmebaas, kolmanda osapoole komponendid) ja topoloogia peab olema enne reaalse arenduse algust infosüsteemide halduse osakonna juhiga kooskõlastatud. 2.3 Rakendusserver peab võimaldama - töötamist andmebaasiserverist eraldi serveril. 2.4 Rakendusserver peab olema vajadusel - klasterdatav aktiivklastris (kasutajasessioon ei tohi olla klastri node põhine). 2.5 Rakendust peab saama ilma Lahendus ei tohi olla sisse kompileeritud absoluutseid URI-sid ümberprogrammeerimata liigutada erinevate domeenide ja domeeni saitide vahel 2.6 Rakenduse liidesed peavad olema Väliste liidestatud süsteemide tõrke korral ei tohi süsteem hanguda, vaid väljastama mõistliku (võimalikult tõrkekindlad kolmandate osapoolte lühikese) aja jooksul ajakohase veateate. Võimalusel tuleb kasutada asünkroonseid liideseid. süsteemide vigade suhtes 2.7 Rakenduse konfiguratsiooniparameetrid Rakendus peab neid sealt ka kasutama (mitte kopeerima parameetreid käivitamisel kolmandatesse tuleb ühte kohta kokku tuua nii, et nende kohtadesse), logimise seaded võivad olla rakenduse konfiguratsioonifailist eraldi ühes muutmisel ei peaks rakendust uuesti lisakonfiguratsioonifailis (näit Log4net). Samuti on väga soovitatav eraldi konfiguratsioonifailis hoida kokku kompileerima (nt ühte arendaja ja administraatori vastutusala parameetrid. Infosüsteem peab olema seadistatav tekstipõhisesse konfiguratsioonifaili, konfiguratsiooniparameetrite(de) abil. Konfiguratsioonifailiks ei saa lugeda faili, kus hoitakse lisaks andmebaasi tabelisse). konfiguratsioonile ka muud programmikoodi. 2.8 Rakenduse kompileerimine, saidi Maksimaalselt 30 sek. Kui rakendus vajab indekseeritud sisu ja see pole kättesaadav, siis peab rakendus taaskäivitus, konfiguratsiooni muutmine väljastama selle kohta selge teate vms peaks toimuma mõistliku aja jooksul. 2.9 Rakendus peab kasutama 64-bitist Suund on 64-bitiste rakenduste op süsteemide kasutamise poole. arvutiarhitektuuri kui ei ole kokku lepitud teisiti. 2.10 Kui tellijaga kokku lepitud, et rakendus Suund on 64-bitiste rakenduste op süsteemide kasutamise poole. kasutab 32-bitist arvutiarhitektuuri, peab ta olema võimeline töötama (testitud) ka 64-bitisel opsüsteemil. 2.11 Kõik andmed, andmebaasid, SQL skriptid - ja rakendus peavad kasutama UTF-8 kodeeringut. Alternatiivina on kokkuleppel tellijaga lubatud ka UTF-16. 2.12 Failisüsteemi salvestamisel ei tohi ühte Failid peab katalogiseerima kokkulepitud tunnuste alusel (nt aasta, kuu, kuupäev). kausta tekkida üle 10000 faili. 2.13 Rakenduse loomisel tuleb eelistada Eelistuse eiramine tuleb kooskõlastada projektijuhiga enne arendamise alustamist objektorienteeritud mudelit 2.14 Ühest andmetabelist teise viitamisel tuleb - kasutada väliseid võtmeid (Foreign key). 2.15 Kõik välised võtmed (Foreign Key) Andmebaasis peab kasutama indekseid või muid meetmeid, et nõuded rakenduse jõudlusele oleksid peavad olema indekseeritud. täidetud ka tulevikus. (1, 3, 5 või 10 aasta pärast – vastavalt planeeritud kasutusajale). 2.16 Tuleb kasutada päringumuutujaid SQL päringute väljakutsumisel väljastpoolt andmebaasi, peab kasutama päringumuutujaid, et vältida SQL (Parameter Binding). vahemälu fragmentseerumist (When calling SQL code from outside the database, Parameter Binding should be used to prevent SQL cache fragmentation) 2.17 Kõigis andmebaasi tabelites peab olema Kasutada vastava andmebaasisüsteemi nimetamise parimaid praktikaid. defineeritud üks primaarvõti. Andmebaasi objektide nimetused peavad olema sisulised ja andma aimu nende otstarbest. 2.18 Andmebaasis defineeritakse üldjuhul Need õigused, mis on vajalikud ainult rakenduse baasi loomiseks, on eraldi välja toodud ja tuleb peale kaks või enam kasutajat: installi ära võtta. Ei kehti teiste andmebaasisüsteemide korral, seal võib see tekitada mõttetut keerukust. Rakenduse peakasutaja, kellena luuakse objektid ja skeemid. Rakenduse piiratud õigustega kasutaja, kellena pöördub rakendusserver/rakendus. Objektide loomiseks vajalikud õigused ja ressursid on loetletud rakenduse dokumentatsioonis. 2.19 Failide hoidmise asukoht lepitakse Failide hoidmine klassikalises andmebaasis on kulukas ja seab kõrgendatud nõudmised ja piirangud igakord kokku. Kuid failid ja failide indeks andmebaasiserveritele. Lahenduse dokumentatsioonis tuleb ära tuua failide hoidmise asukoht. peavad olema replikeeritavad teise serveriruumi. 2.20 Peab olema minimiseeritud vajadus, et Halduri haldustoimingud lepitakse tellijaga kokku detailanalüüsi käigus. haldur teeb haldustoiminguid otse baasis. St rakendusel peab olema haldusliides, mille kaudu rakenduse haldur saab teha tavapäraseid haldustoiminguid. 2.21 Rakendus peab olema võimeline Näiteks logifailides. kasutama keskkonnamuutujaid (serverinimi, kuu, päev jne). 2.22 Andmebaas peab toetama nii külm- kui Ei tohi kasutada teenuseid, mis välistavad andmebaasi peegeldamist (nt "failstream"). ka kuumvaru (peegeldamist) teise serviruumi. 2.23 Sorteerimisreeglistik peab olema Eesti Näiteks MS SQL puhul Estonian_CI_AS. tähestikule vastav. Tõusutundlikkus peab olema välja lülitatud. Accent peab olema sisse lülitatud. 2.24 Kui infosüsteemid saadavad e-kirju, Saatja ja adressaadid, pealkiri ja sisu ei tohi olla rakendusse kodeeritud, vaid on muudetavad peavad nad kasutama välist konfiguratsioonifaili kaudu. Genereeritud kirjade puhul peab tagama kirjade jälitatavuse (näiteks lisada e-mailiserverit. Kirja saatmisel peab X-päise kodeeritud kirje, milles on kirjeldatud, mis protsess/skriptifail/kasutaja kirja genereeris jms abistav rakendus veenduma, et e-mailiserver info). võttis meili vastu. E-kirjade vormindamine peab järgima interneti standardeid (RFC 5322). 2.25 Konfiguratsiooniparameetrite nimed Näiteks : X-tee Turvaserver, mitte XTTS või viitenumber, mitte vk_seb jne peavad olema sisulised. Kui see ei ole võimalik, siis peab kõrval olema seletus. 2.26 Infosüsteemides on eessüsteemid (front Koostöövõime raamistik 2011. Punkt 3.1. Tagasüsteemide ülesanneteks on andmete haldamine ja end; presentatsiooni kiht) ja võrguteenuste pakkumine. Tagasüsteemid ei tegele lõppkasutaja autentimise ja autoriseerimisega. tagasüsteemid (back end; äriloogika kiht) Lõppkasutaja autoriseerimise tagavad eessüsteemid. Välise süsteemi tõrge tohib mõjutada ainult sellest arhitektuuriliselt selgelt lahutatud. otseselt sõltuvate kasutuslugude toimimist. Välise süsteemi taastumisel peab süsteem olema suuteline oma tööd jatkama taaskäivitamata. 2.27 Konfiguratsioonifailid peavad olema Näiteks IIS: *.config , *.resources Apache: *.conf, .htaccess. Arendaja peab välja tooma konfifailide listi, kui vastavalt rakendusserveri tüübile neid on mitu. vaikimisi kaitstud failid 2.28 Rakenduse failid, mida kasutaja näha ei Näiteks: IIS: Bin,App_Code, App_Data, App_Browsers, App_GlobalResources, App_LocalResources, tohi, peavad olema vaikimisi kaitstud App_Themes, App_WebReferences kaustades. 2.29 Konfiguratsiooniparameetrite Kõiki parameetreid tuleks konfiguratsioonis kirjeldada vaid korra, mitte nii, et igas lõigus kirjeldatakse samu taaskasutus. Erinevaid sama sisuga asju uuesti. parameetreid ei tohi konfiguratsioonis eksisteerida.  2.30 Kõik rakenduse liidesed peavad olema Rakendustes tohib kasutada vaid masinapõhiseid teenuseid, mis lubavad kõrgkäideldavaid (klaster) võimelised töötama kõrgkäidetavalt. lahendusi. Kõrgkäideldav lahendus on selline, mida saab samaaegselt käitada erinevates masinates. 2.31 Klientrakendus ei tohi pöörduda otse Tuleb kasutada rakendusservereid. andmebaasi poole. 2.32 Keskkonnapõhised muutujad peavad Näiteks WSDL ei tohi sisaldada viiteid arendusserveritele. olema konfiguratsioonifailist seadistatavad. 2.33 Rakenduses peab olema võimalik piirata Eelistama peaks IP-aadressipõhist blokeeringut. Erandina tellijaga kokkuleppel võib kasutada captchat või ebaõnnestunud logimisi ajaühiku kohta konto lukustamist. Blokeeringute ajavahemikku ja logimiskatsete arvu peab saama konfiguratsioonifailist (mobiil-ID, ID-kaart, paroolid) ühelt muuta. IP-aadressilt. 2.34 Rakendus ei tohi kasutada meetodeid, .NET rakenduste puhul on suund shared hostingu kasutamise suunas. mis välistavad shared hostingu kasutamise. 2.35 Rakenduse äriloogika tuleb realiseerida Andmebaas ei tohi sisaldada äriloogikat, mis muudab andmetabelites olevaid/sinna kirjutatavaid andmeid, andmebaasist eraldi sõltumatus va trigerid, mis tekitavad logi. rakenduskihis. 2.36 Andmebaasis võib kasutada vaid *Ei ole soovitav kasutada mingit platvormispetsiifilist lahendust, mille üleviimine mõnele muule ISO/IEC 9075 standardiga kaetud andmebaasiplatvormile ei ole võimalik. funktsionaalsusi. Lisaks ei tohi kasutada *ISO/IEC 9075 osa 13 spetsifitseerib Javas kirjutatud programmimoodulite kasutamist andmebaasis. ka sama standardi osas 13 kirjeldatud funktsionaalsusi. 2.37 Kui rakendus eeldab eraldi kasutajate, AAM on keskne autentimislahendus ehk SSO rollide ja õiguste registri pidamist, siis peab rakendus kasutama Tellija autentimis- ja autoriseerimismoodulit AAM. 2.38 Uniform resource identifier (URI) pikkus Harilikult on piiriks 2000 tähemärki, kuid iga IS puhul tuleb seda eraldi järele uurida sõltuvalt IS ei tohi ületada ühegi IS poolt toetatava komponentidest. Asjakohased viited: RFC 3986 ja RFC 7239. brauseri maksimaalset lubatud väärtust. 2.39 SOAP teenuseid pakkuva rakenduse Näiteks: Alajaotis definitions/types/schema: WSDL peab olema üles ehitatud nii, et * complexType defineerimisel tuleb sellele lisada any element. see toetaks teenuste versioneerimist. 2.40 Rakendus peab olema võimeline töötama SSL offload koormusjaoturitega varustatud taristul. 2.41 Sidusinfosüsteemide mitte kättesaadavus Sidussüsteemi tõrge tohib mõjutada ainult sellest otseselt sõltuvate kasutuslugude toimimist. Sidussüsteemi ei tohi segada rakenduse töötamist. taastumisel peab süsteem olema suuteline oma tööd jatkama taaskäivitamata. Sidusinfosüsteemidega andmevahetamisel tekkinud vead logitakse ja kasutajat hoiatatakse. 2.42 Kui ajastatult käivitatav taustatöö, ei ole mõeldud käima paralleelselt, peab selles olema realiseeritud kontrollmehhanism, mis tagab, et sama taustatööd ei ole võimalik käivitada uuesti enne, kui eelmisena käivitatud instants on oma töö lõpetanud. 2.43 Ühe tarkvarakomponendi raames ei tohi Näiteks kui rakenduse komponent pöördub andmebaasi või veebiteenuse poole, siis selle pöördumise sama parameetri seadistamine toimuda parameetrid peavad olema muudetavad vaid ühes kohas. rohkem kui ühes kohas. 2.44 Uue toote arenduse ja olemasolevate infosüsteemide versiooniuuendustel kasutusele võetavate Tehnoloogiate ja standardite valik tuleb kooskõlastada Tellija poolse arhitektiga 2.45 Rakenduse ühenduste (s.h. andmebaasi Implementeeritud peab olema vähemalt maksimaalsete ühenduste arvu piirang ja päringu aegumise aeg ja sidusinfosüsteemide ühendused) (request timeout). Rakenduse ühenduste tõrge tohib mõjutada ainult sellest otseselt sõltuvate realiseerimisel tuleb kasutada ühenduste kasutuslugude toimimist. Ühenduste taastumisel peab rakendus olema suuteline oma tööd jatkama taaskäivi puulimist (connection pooling). tamata. Tekkinud vead logitakse ja kasutajat hoiatatakse. 2.46 Rakenduse uuendustega kaasnevad Näiteks Liquibase. andmebaasi muudatused tuleb automatiseerida. Turvalisuse tagamisega seotud nõuded 3.1 Sisemised rakendusliidese autentimised Erandina tellija kooskõlastusel võib sellest loobuda ja kasutada vaid ID-kaardi ja mobiil-ID põhist autentimist. peab saama teha Active directory Isiku sertifikaatide kehtivust peab saama kontrollida vastu OCSP ja CRL-i (vastavalt vajadusele). põhiselt. 3.2 Kliendi ja serveri vahel peab autenditud - kasutajasessioonide korral olema sessioon krüpteeritud HTTPS-protokolli kasutades. 3.3 SSL veebiserver peab kasutama turvalisi https://www.ssllabs.com/ssltest/ ja SSL/TLS versioone ja šifrikomplekte 3.4 Rakendus tohib kasutada vaid sessiooni - küpsiseid. Muude küpsiste kasutamine on keelatud. 3.5 Kui andmebaasis olevate andmete ISKE St kõik andmemuudatused peavad baasis säilima. Andmete muutmisel andmeid ei kustutata, vaid tehakse tervikluse turvaosaklass on 2 või kõrgem, uus kirje uute andmetega. Vana muudetakse kehtetuks. Iga uus kirje peab sisaldama järgmist siis tuleb kõik klass 2 infot sisaldavad informatsiooni: *viide kirjele, mille ta kehtetuks muutis (kui on) *kasutaja, kes kirje lõi *kirje loomise aeg andmebaasi kirjed/tabelid versioneerida. *sessiooni-ID (kui on olemas). Iga kehtetuks tunnistatud kirje peab omama järgmist informatsiooni: *kasutaja, kes kirje kehtetuks tunnistas *kirje kehtetuks tunnistamise aeg. 3.6 Kui rakenduse poolt töödeldavate Testandmed peavad säilitama kõik toodangu andmete omadused (pikkuse, tüübi) ja omavahelised suhted. andmete konfidentsiaalsuse turvaosaklass on 2 või kõrgem, peab rakendusega kaasas olema lahendus, mis suudab toota toodangu andmetest testandmed, mis ei sisalda konfidentsiaalset informatsiooni. 3.7 Andmebaasis olevate rakenduse kontod Ei resource, dba, ANY ega muud sellist. Nõude täitmiseks vajalikud vahendid (skriptid) peavad kuuluma peavad omama ainult minimaalselt rakenduse juurde ja nende sisu peab olema kontrollitav. Kontodele vajalikud õigused peavad olema rakenduse tööks vajalikke õiguseid. kirjeldatud rakenduse installijuhendis. 3.8 Rakendusse ja andmetele tohib olla St rakendustes ega andmebaasides ei tohi olla ligipääsemiseks teisi võimalusi. ligipääs vaid dokumenteeritud ja tellimuses kirjeldatud teid mööda ning dokumenteeritud autentimisprotseduure kasutades. 3.9 Kõik paroolid ja salaküsimuste vastused Räsimine peab kasutama turvalist räsifunktsiooni (nt SHA2, SHA3, RIPEMD-160) ja kindlasti ka soola (salt). peab rakendus salvestama vaid Sool peab olema andmebaasiüleselt unikaalne, piisavalt suure bitiarvuga ja (pseudo)random. Krüpteerimisel räsitud+soolatud. Kui räsimise asemel peab kasutama turvalisi algoritme (nt AES256) ja CBC, CRT vms režiimis. Kindlasti ei tohi kasutada ECB valitakse krüpteerimine, siis tuleb režiimi. Paroolid ja salaküsimuste vastused tohivad olla krüpteerimata kujul vaid ajutiselt serveri muutmälus. kirjeldadakrüptovõtme turvalise hoidmise Krüpteerimata kujul ei tohi paroole salvestada (ka ajutiselt) ühelegi kettale. Arendaja loodud lahenduse protseduur. dokumentatsioonis (nt detailanalüüs vms) peab olema ära toodud kasutatavad räsi ja krüptoalgoritmid, võtmepikkused ja nende kasutuskohad (vt nõue p 1.10) 3.10 Rakendused, kuhu saavad ligi välised Kui on vajalik ka parooliga logimine, peavad välised kasutajad autentima ennast spetsiaalse väliskasutajate kasutajad, peavad võimaldama jaoks mõeldud AD pihta. Kui parooliga autentimist tehakse alati samadelt üksikutelt IP-delt, siis tuleb lisaks sisselogimist ID-kaardi ja mobiil-ID-ga. paroolile kasutada ka IP-põhist ligipääsukontrolli. Rakendus ei tohi lubada kasutada nõrku paroole, peab Paroolipõhist autentimist ei tohi kasutada. võimaldama paroolide eelmääratud aegumist ja mitme valesisestuse (nt 5 korda) korral kontode lukustamist. Sertifitseerimiskeskuse dokument digisertifikaatide kasutamise kohta EV dokumentidel: https://sk.ee/upload/ files/SK-CPR-ESTEID-ET-v5_0-20150101.pdf 3.11 Mobiil-ID autenimise korral tuleb lisaks Veebilehel kuvatav kontrollkood peab olema selgelt nähtav, sh ka nutitelefonidel ilma ekraanipilti kerimata. kasutaja telefoninumbrile küsida ka kasutaja isikukoodi. 3.12 Rakendus ei tohi teostada X-tee päringut Kasutajaarvutitest otse x-tee päringute tegemine on arvutivõrgu tasemel kinni. otse kasutajaarvutist. 3.13 Veebipõhised välise veebilehega IIS puhul peab kasutama näiteks URL scan, apache puhul modsecurity või vastavat tööriista. Lubatud rakendused, mis on keskmise või päringud on kõik päringud, mis ei ole detailanalüüsi käigus vastavalt kasutusjuhtudele ette nähtud. kõrgema ISKE turbeastmega, peavad Kasutama peab whitelisting põhimõtet, mitte blacklisting. kasutama vahendeid kaitsmaks rakendust lubamatute päringute eest. 3.14 Kui rakenduse mõni ISKE turvaosaklass Kasutaja peab saama soovi korral veenduda, kas keegi pole tema nime all vahepeal sisse loginud. on 2 või kõrgem, peab rakendus sisenemisel näitama pärast õnnestunud sisselogimist eelmise õnnestunud sisselogimise aega. Kui on toimunud ebaõnnestunud sisselogimise katseid, siis peab kuvama ka, millal need toimusid, mitu neid oli ja mis IP-aadressilt pöörduti. 3.15 Kõigil rakendustel peab olema Aeg peab olema muudetav koos teiste konfiguratsiooniparameetritega. konfigureeritav kasutajasessiooni aegumise aeg.  3.16 Krüpteerimise ja/või räside arvutamise Järgida tuleb uusimat RIA kodulehel avaldatud krüptograafiliste algoritmide kasutusvaldkondade ja elutsükli korral tuleb kasutada tugevaid algoritme. uuringut. Lubatud on: AES-256, Blowfish-256, RSA-2048, SHA-2, RIPEMD-160 või tugevamaid. Lahenduses tuleb välja tuua kõik krüptoalgoritmid, võtmepikkused ja kasutuskohad. 3.17 Autenditud sessiooni tunnust ei tohi ainult Sessiooni ei tohi olla võimalik üle võtta sessioonitunnuse kopeerimisega ühest arvutist teise. lihtsa küpsisega lahendada. 3.18 AD või AAM-i autentimise kasutamisel Näiteks: konto on lukus, parool aegunud, konto aegunud, paroolipoliitika jne. peab rakendus kasutama ka AD või AAM-i kontoga kaasnevaid piiranguparameetreid. 3.19 Tagada tuleb rollide lahusus. Halduritel ei Administraatoril, halduril ja tavakasutajal on erinevad tööülesanded. Rollide/õiguste kirjeldus peab lähtuma tohi olla võimalik muuta ega näha detailanalüüsist ja kasutusjuhtudest. rakenduse konfiguratsiooni. 3.20 ID-kaardiga autentimisel, peab rakendus Proxy tugi suutma vastu võtta ID-kaardi sertifikaati ka päises. 3.21 Kui kasutajaid hallatakse ka rakenduses Eesmärk vähendada AD ja AAM-i koormust. ja autenditakse AD või AAM-i vahendusel, tuleb sisselogimisel kõigepealt kontrollida kasutaja olemasolu rakenduses ja alles siis pöörduda AD või AAM-i poole. 3.22 Arendus peab olema orienteeritud Toodangukeskkonna rakendus ei tohi sisaldada osiseid, mis toodangu keskkonnas on ebavajalikud või toodangukeskkonnas toimimiseks. segavad (näiteks kasutuseta funktsionaalsus ja komponendid, mõeldud testimiseks testkeskkonnas, arendusabiks arenduskeskkonnas jne). 3.23 Rakendus ei tohi lubada ühe kasutajaga Juhul kui lähteülesanne spetsiaalselt ei ütle teisiti. mitut samaaegset sessiooni. 3.24 Kui rakenduse tervikluse turvaosaklass Milline lahendus valitakse tuleb kokku leppida tellijaga. Täpsustuseks vt ISKE nõue HT.34. Vt ka nõuet 3.28. on T3, peavad tõestusväärtust omavad andmed olema kas ajatembeldatud, digiallkirjastatud või digitembeldatud. 3.25 Kui lahendus peaks kasutama ajatempli Ajatempli kasutamise vajadus lepitakse eraldi kokku Tellija IT juhiga ja infoturbejuhiga. See sõltub Tellija teenust, siis tuleks eelistada Guardtime keskse ajatempli kasutamise võimalustest. lahendust. 3.26 Kui rakenduse tervikluse turvaosaklass Täpsustuseks vt ISKE nõue HT.10. Krüptoahela kasutamise vajadus lepitakse eraldi kokku Tellija on T3, peavad tõestusväärtust omavad infrastrktuuri juhiga ja infoturbejuhiga. See sõltub Tellija keskse krüptoahela kasutamise võimalustest. andmed olema krüptoaheldatud, et tagada et tõestusväärtusega andmeid ei saaks märkamatult kustutada. 3.27 Kui rakenduses on S3 salastuse astmega Täpsustuseks vt ISKE nõue HT.37 . andmeid, peavad need olema nii transpordi ajal ja ka salvestatult alati krüpteeritult. 3.28 Veebirakendus ei tohi jätta sulgemisel Kui paks klient kasutab ajutisi faile, tuleb tagada nende perioodiline kustutamine tagamaks, et ei koormata kasutaja tööjaama maha ajutisi faile. liigselt kasutaja arvutit. Nõude eesmärk on tagada, et rakenduse sulgemisel ei jääks kasutaja arvutisse Paksu kliendi korral ei tohi rakendus maha informatsiooni, mida sinna jääda ei tohiks, sh pääsuandmeid, isikuandmeid, andmekogu sisulisi kasutaja tööjaama jätta maha andmeid jms krüpteerimata kujul ajutisi faile, mis sisaldavad või võivad sisaldada konfidentsiaalse või kõrget terviklust nõudvat informatsiooni. 3.29 Rakendus ja selle komponendid peavad Arendaja arendab arenduskeskkonnas ja annab tarne üle tellijale paigalduspakkidena. Tellija paigaldab selle võimaldama kasutada keskkondade testkeskkonda ja testib ning seejärel paigaldab tarne toodangu keskkonda. Reaalseid andmekogu andmeid lahusust tohib töödelda üksnes toodangu keskkonnas. 3.30 Rakendus peab võimaldama hõlpsalt Krüptograafiat kasutav rakenduskood ei tohi nimeliselt välja kutsuda krüptograafilisi algoritme, vaid peaksid välja vahetada aegunud ja ebaturvalise seda tegema vahendavate vaheteekide kaudu üldiste funktsioonide järgi (nt krüpteerimine, dekrüpteerimine, krüptoalgoritmi. signeerimine, signatuuri verifitseerimine jne). Dokumentatsioon peab kajastama üldist kirjeldust, kuidas vajadusel ebaturvaline krüptoalgoritm välja vahetada. 3.31 Rakenduse andmebaasi krüpteerimisega Andmebaasides kasutatavad krüpteerimisfunktsioonidest tingitud lisaväljad peaksid olema muudetava seotud andmeväljad peavad olema pikkusega, et formaati muutmata saaks kasutada teistsuguste parameetritega krüpteerimisalgoritme. muudetava pikkusega. Logimine, debuggimine, testimine 4.1 Rakendusel peab olema masinloetav Testlehe kättesaadavus erinevatest arvutivõrkudest peab olema konfigureeritav. Testleht peab uuendama testleht (JSON, XML). ennast lehe pärimisel. Testleht peab sisaldama custom builtrakenduse versiooni numbrit, standardsed komponendid (veebiserver, andmebaas, CMS'id jms) ei tohi oma versioone reeta. Samuti peab testlehel olema infot rakenduse (vajadusel tema erinevate osade) ja tema kõigi väliste liideste staatuse kohta (töötab, ei tööta). Rakenduse, andmebaasi ja liideste töökorda kontrollitakse testpäringute teel, mis tuleb tellijaga kokku leppida eelanalüüsi käigus. Testleht peab oma konfiguratsiooni võtma rakenduse üldisest konfiguratsioonist (baasistring, välised ühendused). 4.2 Rakenduse kõik üleantavad versioonid Testitulemused tuleb edastada tellijale koos rakenduse üleandmisega peavad enne tellijale üle andmist olema testitud 4.3 Rakendus peab logima kasutaja edukat Logima peab ka autentimise ebaõnnestumise koos põhjusega (vale parool, aegunud konto jne). Logida ja ebaedukat autentimist ja sessiooni tuleks IP-aadress, meetod ja kui võimalik kasutajatunnus (mobiil-ID puhul telefoni number, ID-kaardi puhul lõpetamist, kasutaja IP ja isikukood). Kui rakendus kasutab kasutajate autentimiseks AAM-i, siis leppida projektijuhiga eraldi kokku autentimismeetodit (ID-kaart, mobiil-ID autentimise detailsus ehk mis kajastatakse AAM-is ja mis rakenduses. vms), eduka autendi puhul tuleks logida ka kasutaja isikukood ja mobiil-ID puhul telefoninumber 4.4 Erinevate logifailide kirjeid peab olema Näiteks timestamp või mingi ID abil. võimalik seotud komponentide logidega loogiliselt kokku viia. 4.5 Rakendus peab suutma logida kõiki X-tee Vajalik eelkõige debuggimiseks ja toodangu keskkonna probleemide lahendamiseks. teenuste kaudu liikuvaid andmeid. Peab olema võimalus logimist sisse-välja lülitada. 4.6 Kui rakenduse ISKE konfidentsiaalsus Andmetöötlust peab olema võimalik kokku viia konkreetse kasutajaga ning sessiooniinfoga. Isikuandmete turvaosaklass on 2 või kõrgem, peab kaitse seadus §25 lg2 p3:(Isikuandmete töötleja on kohustatud) ära hoidma isikuandmete omavolilist rakendus logima kõiki konfidentsiaalsus salvestamist, muutmist ja kustutamist ningtagama, et tagantjärele oleks võimalik kindlaks teha, millal, kelle klassiga 2 või kõrgemate andmete poolt ja milliseid isikuandmeid salvestati, muudeti või kustutati või millal, kelle poolt ja millistele loomist, muutmist (sh kustutamist) ja isikuandmetele andmetöötlussüsteemis juurdepääs saadi; vaatamist. 4.7 Kui rakenduse ISKE tervikluse Andmetöötlust peab olema võimalik kokku viia konkreetse kasutajaga ning sessiooniinfoga. Isikuandmete turvaosaklass on 2 või kõrgem peab kaitse seadus §25 lg2 p3:(Isikuandmete töötleja on kohustatud) ära hoidma isikuandmete omavolilist rakendus logima kõiki tervikluse klassiga salvestamist, muutmist ja kustutamist ningtagama, et tagantjärele oleks võimalik kindlaks teha, millal, kelle 2 andmete loomist ja muutmist (sh poolt ja milliseid isikuandmeid salvestati, muudeti või kustutati või millal, kelle poolt ja millistele kustutamist). isikuandmetele andmetöötlussüsteemis juurdepääs saadi; 4.8 Kui rakenduse andmete Lahendus peab tagama, et administraatorid/haldurid ei saa andmete vaatamise logimist ise (ka konfidentsiaalsuse turvaosaklass on 3, tavakasutajate logimist) deaktiveerida või logisid kustutada/muuta. Võib tellijaga kokku leppel nõudest siis ka kõiki administraatorite ja haldurite loobuda kui andmed on krüpteeritud. poolt tehtavaid andmete vaatamised (ka otse baasis) tuleb logida. 4.9 Kui rakenduse andmete tervikluse Lahendus peab tagama, et administraatorid/haldurid ei saa andmete muutmise logimist ise (ka turvaosaklass on 3, siis ka kõiki tavakasutajate logimist) kinni keerata või logisid kustutada/muuta. Tellijaga kokkuleppel võib nõudest administraatorite ja haldurite poolt loobuda, kui andmed on kaitstud digiallkirja, digitempli või välise osapoole ajatempliga. tehtavaid andmete muudatused (ka otse baasis) tuleb logida. 4.10 Andmete Logid peavad asetsema andmetest eraldi andmebaasi failides-andmeruumides, et neid oleks võimalik loomise/vaatamise/muutmise/kustutamise vajadusel lihtsalt andmetest eraldi arhiveerida või anda nendele ligipääsuks eraldi õiguseid. Kui rakendusel logid peavad asuma andmebaasis ja on eraldi liides administraatorile või peakasutajale, siis seal peab olema eraldi logidega tutvumise võimalus neile on loodud vastav logide vaatamise vastavate pääsuõiguste olemasolul. liides rakenduse peakasutajale. 4.11 Andmebaasi logidest saadetakse Failisüsteemi logide eesmärk on koguda logid ühtesesse logihaldussüsteemi, neid krüptoaheldada ja reaalajas koopia failisüsteemi logisse ja aegtembeldada. seal logis peab kajastuma ka logimisfunktsionaalsuse aktiveerimise ja deaktiveerimise info (aeg, kasutaja jms) 4.12 Rakendusega peab olema kaasas skript Jõudlustestide täpne kirjeldus tuleb kokku leppida detailanalüüsi käigus. Arendaja peab koos rakendusega jõudlustestide tegemiseks. tarnima skripti ja vajalikud tarkvaralised vahendid kokkulepitud jõudlustestide läbiviimiseks. Jõudlustestide läbiviimine ei tohi nõuda tellijalt omapoolset tarkvara arendamist, skriptide kirjutamist või litsentside ostmist. 4.13 Rakendus peab logima kõiki rakenduses Logi sisaldab minimaalselt vea tekkimise aega, veakoodi, veakirjeldust (stack trace, traceback vms), tekkivaid tehnilisi vigu. võimalusel kasutaja andmeid, HTTP-, GET- ja POST-parameetrid ja nende väärtusi. Logimise detailsusrežiimi (info, warning, errog, debug) peab saama muuta. 4.14 Vea ja süsteemilogid peavad Kui logitakse mitmesse kohta, siis vajadusel peab saama ühte või teise kohta logimist välja lülitada. Logi olema vähemalt failisüsteemi tekstifailis peab olema lihtsalt masintöödeldav ja tuntud vormingus. Näiteks syslog, syslog-ng, XML, CSV. üldtuntud vormingus, lisaks võib ka andmebaasis hoida.  4.15 Failisüsteemi logimise korral peavad Ei tohi esinda olukorda, kus ühte kausta tekib rohkem kui 1000 faili. logid olema ka katalogiseeritud (näiteks kuupäeva või liigi järgi) ja üldtunnustatud faililaiendiga (näiteks .log, .txt, .xml), logi peab olema roteeruv, et ei tekiks liiga suuri faile (nt 5MB). Logifailide seadistamisel peab olema failinime/kaustatee nimedes võimalik kasutada keskkonnamuutujaid (kuupäev, masinanimi jne). 4.16 Logimis parameetreid peab saama muuta Näiteks log4j konfiguratsiooni failis "monitoring-interval". rakendust taaskäivitamata. Nõuded rakenduse lähtekoodile 5.1 Lähtekoodi kommentaarid peavad kõigis NB! Nõuet ei arvestata arendustarkvara poolt automaatselt genereeritavate koodilõikude puhul – neid ei ole lahenduse kihtides (rakenduse enda vaja tõlkida. Samuti ei rakendata nõuet kolmandate osapoolte poolt toodetud lähtekoodile – nt igasugu kood, andmebaas, jne) olema kirjutatud erinevad lahtise koodiga koodilõigud jms. Kui on tegu olemasoleva süsteemi edasiarendusega, siis peaks eelistatult inglise keeles, vähem kommentaarides kasutama eelnevalt kasutatud keelt. eelistatud alternatiivina eesti keeles. 5.2 Lähtekoodi kommentaarid peavad olema Rakenduse kood peab olema piisavalt hästi kommenteeritud, et erialast haridust omav tarkvaraarendaja on selged, arusaadavad ja sisuliselt võimeline süsteemile jätkuarendusi teostama. kirjeldama vastavat koodi, mille juures nad on ning moodustama vähemalt 20% koodi mahust. 5.3 Muutujate, tüüpide ja funktsioonide nimed Parim praktika peavad olema sisulised ja andma aimu nende otstarbest. 5.4 Koodis kasutatavad konstandid ja Parim praktika. Nt Identifikaator --> ID lühendid tuleb kirjutada suurte tähtedega. 5.5 Koodis kasutatavaid konstante ei tohi - selle kasutamise kohta väärtusena hardcodeda – need tuleb defineerida muutujatena ja kasutada läbi nende. 5.6 Koodis defineeritud andmetüübid peavad N:Isik; Menetlus; jne. Andmebaaside struktuurikirjeldustes/andmemudelis ei tohi kasutada täpitähti. olema nimetava käände ainsuses. Kõik andmemassiivid tuleb nimetada nimetava mitmuses (st igasugu collectionid, arrayd, jms). 5.7 Andmetabelites sisalduvad võõrvõtmed Kasutada tuleb konkreetse andmebaasisüsteemi nimetamise parimaid praktikaid. Nt kui on tegu tabelitega peavad nime järgi seostuma tabeli ja ’Isikud’ ja ’Autod’, siis seos ’isiku autod’ oleks: Isikud.ID=Autod.Isik_ID väljaga millele need viitavad. 5.8 Andmebaasi väljade pikkused tuleb Selle asemel, et eraldada väljale x baiti, tuleb eraldada x tähemärki. (Instead of allocating x bytes of storage kirjeldada sümbolites, mitte baitides. for the field, x chars of storage must be allocated). 5.9 Kui kokku pole lepitud teisiti, siis JAVA Checkstyle (http://checkstyle.sourceforge.net/) ei tohi käivitamisel järgmise konfiguratsioonifailiga väljastada rakenduse kood peab olema kirjutatud ühtegi viga. vastavalt "Oracle Java Code convention" dokumendile. 5.10 Kui kokku pole lepitud teisiti, siis Python http://www.python.org/dev/peps/pep-0008/ rakenduse kood peab olema kirjutatud vastavalt "Style Guide for Python Code " dokumendile 5.11 Kui kokku pole lepitud teisiti, siis .NET http://msdn.microsoft.com/en-us/library/ms229042.aspx Valideerimiseks kasutatakse 'StyleCop' vaikimisi rakenduse kood peab olema kirjutatud konfiguratsiooni vastavalt "NET Framework Developer's Guide - Design Guidelines for Developing Class Libraries". 5.12 JAVA koodi valideerimiseks kasutatakse: 1. PMD (http://pmd.sourceforge.net/) reeglistikud „Basic Rules“, „Import Statement Rules“, „Security Code Guidelines“ ja „Unused Code Rules“ ei tohi väljastada ühtegi viga. 2. DocCheck(http://java.sun.com/j2se/javadoc/doccheck/) 3. Findbugs (http://findbugs.sourceforge.net/) Sotsiaalministeeriumi poolt kirjeldatud reeglistikus “Java koodi kvaliteedi nõuded.zip” ei tohi väljastada vigu. 5.13 .NET koodi valideerimiseks kasutatakse: FxCop(http://msdn.microsoft.com/en-us/library/bb429476.aspx)  5.14 Pythoni koodi valideerimiseks Pychecker(http://pychecker.sourceforge.net/) kasutatakse: 5.15 Kasutuses mitteolev kood tuleb - rakenduse lähtekoodist kõrvaldada. 5.16 Arendamisel kasutatakse DRY ja SOLID http://en.wikipedia.org/wiki/Don%27t_repeat_yourself printsiipe http://en.wikipedia.org/wiki/SOLID_(object-oriented_design) 5.17 Üleantavas koodis ei tohi olla paroole, Kehtib ka siis, kui need on välja kommenteeritud. Kõik sellised paroolid tuleb asendada fraasiga mida on kasutatud arenduse käigus “<password>“. 5.18 Rakenduste lähtekoodi tasemel ei tohi Eelpoolmainitu haldamine toimub failis või andmebaasis. olla ühtegi sisse kodeeritud parameetrit, väljade nimetust, veateadet. Andmekvaliteet ja standardid 6.1 Aadressiandmete sisestamisel, Liidestatakse maaameti X-tee teenusega. kuvamisel ja hoidmisel tuleb lähtuda Vabariigi Valitsuse määrusest https://www.riigiteataja.ee/akt/103102017005?leiaKehtiv "Aadressiandmete süsteem". 6.2 Rakendus peab võimalikult palju Välja arvatud logimisvormi lahtrid autentimisel informatsiooni eeltäitma automaatselt (kirje sisestamise kuupäev, kasutaja nimi jne). 6.3 Tegevusalade andmete sisestamisel, - kuvamisel ja hoidmisel tuleb lähtuda Vabariigi Valitsuse 10. Jaanuari 2008. a määrusest nr 11 "Klassifikaatorite süsteem" ja kasutada EMTAK infosüsteemis kehtivat klassifikaatorit. 6.4 Tervishoiuteenuste osutajate andmete Liidestatakse Terviseameti x-tee teenusega kasutamisel peab kontrollima nende andmeid, sh tegevuslubade kehtivust Terviseameti Tegeuslubade registrist 6.5 Tervishoiutöötajate andmete kasutamisel Liidestatakse Terviseameti x-tee teenusega peab kontrollima nende andmeid Terviseameti tervishoiutöötajate registrist 6.6 Meditsiiniandmete vahetamiseks tuleb www.hl7.org Vajadusel on lubatud ka teiste standardite kasutamine, kuid see tuleb tellijaga eraldi kokku kasutada meditsiiniandmete leppida andmevahetuse standardit HL7 6.7 Tervise valdkonna klassifikaatorid Võimalusel tuleb kasutada olemasolevaid OID-e ja klassifikaatoreid, mida vajadusel täiendatakse või peavad olema kooskõlas Tellija OID-ide luuakse uued ning publitseeritakse samuti publitseerimiskeskuses http://pub.e-tervis.ee ja publitseerimiskeskusega Kasutajaliides 7.1 Kasutajaliidese kõik disainiotsused - peavad olema kooskõlastatud tellijaga enne nende realiseerimist 7.2 Veebipõhine kasutajaliides peab olema Minimaalselt Internet Explorer, Mozilla Firefox, Chrome ja Safari arenduse testimise hetkel tootja poolt kasutatav enamlevinud toetatud versioonid. Täpsemad nõuded dokumendis "Front-end arendusreeglid" veebibrauseritega, sh nutiseadmetel (Android, IOS, Windows Phone) 7.3 Rakenduse värviskeem ja logo Kui tegemist on struktuurfondide projektiga on lisaks nõutud ka vastav SF sümboolika. Tellija ametlikud CVI kasutamine peab vastama Tellija esitluspõhjad, logo kasutusjuhend ja kõik logod (ka jpg-na) küsida tellijalt. ametlikule visuaalsele identiteedile (CVI) ja disainijuhistele (UIG). 7.4 Kasutajaliidese kõik osad ja teated Kui soovitakse juurde eraldi ka muid keeli, siis see on spetsifitseeritud hankedokumentides peavad olema eestikeelsed. 7.5 Avalikuks kasutamiseks tehtav rakendus Toetatud peavad olema vähemalt resolutsioonid: 1920x1200, 1920x1080, 1680x1050, 1600x1200, peab olema graafiliselt eskaleeruv ja 1440x900, 1360x768, 1280x1024, 1280x960, 1280x800, 1280x768, 1152x864, 1024x768, 1024x600. Ühegi mugavalt kasutatav kõigi enamlevinud nimetatud resolutsiooni korral ei tohi tekkida horisontaalset kerimisriba. arvutite monitoride resolutsioonidega. 7.6 Sisemiseks kasutamiseks tehtav Ühegi nimetatud resolutsiooni korral ei tohi tekkida horisontaalset kerimisriba. rakendus peab olema graafiliselt eskaleeruv ja mugavalt kasutatav järgmiste monitoride resolutsioonidega: 1024x768, 1280x1024, 1680x1050, 1920 x 1080, 1920x1200. 7.7 Hüpikaknaid (pop-up) ei tohi kasutada. Silmas on peetud uusi veebilehtiseja aknaid avavaid hüpikaknaid 7.8 Kasutajaliideses toiminguni (põhi- ehk Kõik rakenduse kasutajaliidesest tehtavad toimingud tohivad üksteisest olla maksimaalselt 3 hiirekliki enamkasutatavad tegevused) kaugusel. Toimingut ei pea nende 3 klikiga tehtud saama. Väljalogimise nupp/link peab olema ühe kliki navigeerimiseks peab kehtima 3 kliki kaugusel ja arusaadavas/intuitiivses kohas. printsiip, väljalogimiseks 1 kliki printsiip. 7.9 Kasutajaliides peab alati küsima kinnituse - andmete kustutamise ja massmuutmiste kohta kui pole kokku lepitud teisiti. 7.10 Rakenduse kasutamisel tekkinud veale Veateated peavad olema sellised, mis võimaldavad IT-abil võimalikult lihtsalt tuvastada vea olemuse ja peab kasutajaliides vastama kasutajale asukoha. eestikeelse kasutajasõbraliku veateatega, mis sisaldab soovituslikult ka vea koodi. 7.11 Kasutajaliides peab olema ilma Uue keele lisamine peab olema teostatav konfiguratsiooni failist või administreerimisliidesest. rakenduse koodi muutmata tõlgitav teise keelde, v.a kui ei ole kokkulepitud teisiti. 7.12 Rakenduse tausta, menüüde ja teksti - värvid peavad olema ilma rakenduse koodi muutmata vahetatavad. 7.13 Rakenduse kasutajaliides peab teavitama Ette teavitamise aeg peab olema konfigureeritav. kasutajat ette sessioon aegumisest. 7.14 Kui vormile sisestatakse mahukaid Kui vorm koosneb paljudest väiksest andmeväljadest (nt taotlus), siis jagatakse vorm etappideks ning andmevälju peab kasutajaliides kokku salvestatakse vastava etapi lõpus. lepitud ajavahemike järel salvetama välja sisu, et sessiooni aegumisel või võrgu katkestuse korral juba sisestatud andmed ei kaoks. 7.15 Sisestusvormidel andmete sisestamisel - peab saama väljade vahel vastavalt äriloogikale liikuda klaviatuuri abil tabulaatoriga. 7.16 Interaktiivsete vormide puhul (näiteks faili - üleslaadimine), ei tohiks lehe värskendamisega tegevust korrata (faili taas üles laadida, andmeid saata, avaldust esitada). 7.17 Kui päring võtab aega kauem kui 3 Ikoon peab muutuma liivakellaks ja/või kuvatakse teade: päringut sooritatakse või muu tellijaga kokkulepitud sekundit, peab kasutaja saama visuaalse indikaator. teate, et süsteem tegeleb päringu läbiviimisega. 7.18 Esilehel (sisselogimata) ja ka pärast Näiteks võimalikud teavituses: mingi süsteemi osa on vigane, tuli mingi uus funktsionaalsus, vahetage oma kasutaja sisselogimist peab olema lihtne parool, uuendage isikuandmeid jne. võimalus teavitada kasutajat muudatustest või probleemidest. Teavitus peab olema halduri poolt lihtsalt lisatav ja olema kasutajale märgatav. 7.19 Nutiseadmetele tuleb luua eraldi See vajadus spetsifitseeritakse arenduse tellimisel. kohaldatud kasutajaliides. 7.20 Infosüsteem peab funktsionaalse vea (näiteks kohustuslikkude väljade täitamata jätmisel) korral kasutajale kuvama kasutajasõbraliku veateate. Veateated peavad olema hallatavad. 7.21 Päringu vastusena kuvatud tabeli veerge on võimalik andmete/teksti tähestikulises järjekorras sorteerida. 7.22 Andmeväljade kohustuslikkus peab olema infosüsteemi väljadel märgitud tärniga (*).  7.23 Rakenduse andmeväljade mõisted peavad olema üheselt identifitseeritavad, korrektses eesti keeles (ilma kirjavigadeta) ja vajadusel sisaldama selgitavat teksti. Abiinfo (kasutusjuhendid) peab olema kättesaadav rakenduse toimimise erinevatel etappidel. 7.24 Kasutajaliides peab vastama ka Front-end arendusreeglid dokumendis "Front-end arendusreeglid" kirjeldatud reeglitele Dokumentatsioon 8.1 Kogu rakenduse dokumentatsioon peab Erandiks võivad olla kolmanda osapoole komponentide (mis pole kirjutatud tellija jaoks) dokumentatsioon. olema kirjutatud eesti keeles. Samuti võib erandiks olla välispooltega seotud projektid. Erandid tuleb kooskõlastada tellijaga enne dokumentatsiooni koostamist 8.2 Lahendus kirjeldatakse RIHA määruse https://www.riigiteataja.ee/akt/12933746?leiaKehtiv#para6 nõuete kohaselt. 8.3 Rakenduse dokumentatsioon peab Dokumentatsioon peab olema versioneeritud, muutmiskuupäevadega, autori nimedega, korrektse sisaldama paigaldusjuhiseid, keelekasutusega, selge struktuuriga. Dokumentatsiooni detailsus peab olema piisav, et sõltumatu kolmas varundatavate komponentide kirjeldust, tehnliste IT baasteadmistega isik suudaks dokumendist vajalikke järeldusi teha (st dokument peab olema kasutajate kasutusjuhendeid, arusaadav sellele isikule, kuid näiteks paigaldusjuhise järgi toimetades ei pea ta ebaõnnestunud tarnele peakasutajate ja administraatorite teostama veaanalüüsi). kasutusjuhendeid, andmemudeleid, arhidektuurilisi mudeleid, süsteemitehnilisi kirjeldusi, nõudeid riistavarale, krüptoalgoritme ja võtmepikkuseid, SSL sertifikaatide kasutuskohti jms 8.4 Rakenduse dokumentatsioon peab Esialgne kirjete mahu hinnang peab tulema lähteülesandest, ning täpsustuma eel ja detailanalüüsi käigus. sisaldama tabelite-andmete-logide mahu Mahuhinnang peab sisaldama ka logide säilitamise, arhiveerimise tähtaegu. kasvu arvestuslikku hinnangut rakenduse sihipärase kasutamise korral ettenähtud arvu kasutajate poolt. (MB/GB kuus/aastas). 8.5 Iga uue versiooniga peab alati välja Release notes peab kajastama kõiki muudatusi eelmise ja uue versiooni vahel. tooma versiooni muudatuse kirjeldused (release notes). 8.6 Rakenduse dokumentatsioon peab Nõuded infosüsteemi dokumentatsioonile vastama ka dokumendis "Nõuded infosüsteemi dokumentatsioonile" kirjeldatud nõuetele Versioonihaldus 9.1 Kõik rakenduse testimiseks, koolituseks Arendajale antakse selleks õigused Tellija versioonihalduse repositooriumi, kus ta peab hoidma oma või implementeerimiseks üle antavad erinevaid versioone. Versioonihalduse repositooriumi juurdepääsutaotlus esitatakse Tellija kasutajatoele läbi tarkvarapaketid peavad olema projektijuhi versioneeritud. Kasutama peab Tellija versioonihalduse repositooriumi. 9.2 Arendaja peab veenduma, et teeb - muudatusi aktuaalsesse koodi. Ehk paralleelse arendamise puhul võetakse igal hommikul versioonihalduse repositooriumist viimane seis koodist. 9.3 Paigalduspaketile koostatakse Räsialgoritmiks tuleb kasutada SHA256. Linuxi käsurealt kontrollkoodi koostamiseks: $ sha256sum filename kontrollkood (checksum), mis pannakse [filename2] ... > kontrollkood.sum eraldi .sum failina tarnele kaasa. 9.4 Kõik rakenduste tellijale lepingujärgsete Ka tagant järgi peab olema 100% kindel, et üle anti õige arendaja signeeritud, mitte kolmanda osapoole üleantavate versioonide lähtekoodid poolt kompromiteeritud versioon. Mahuka lähtekoodi asemel võib signeerida paigladuspaki kontrollkoodi. peavad olema varustatud arendaja esindaja digiallkirjaga. 9.5 Nii arendamisel kui ka hoolduslepingute Arendajale antakse selleks õigused Tellija veahalduse keskkonda. Juurdepääsutaotlus esitatakse Tellija korral kasutatakse Tellija veahalduse kasutajatoele läbi projektijuhi keskkonda. Paigalduspaketi kooste 10.1 Tarnitava lahenduse koosseisus üle Näiteks võib lahenduse paigalduspaketi koosteprotsess ette näha, et käivitada tuleb rida shell-käske või antava lähtekoodiga peavad kaasas võivad lahenduse koosseisus olla valmis (ant, ..) koosteskriptid või mis iganes muu moodus paigalduspaketi olema kirjeldused sellest paigalduspaketi tekitamiseks. koosteks. Eelistatud on kasutada Jenkins skripte/Jenkinsfile. 10.2 Kooste kirjelduste alusel valmiv Näiteks: kompileeritavate keelte puhul ei tohi sisaldada lähtekoodi, kui see pole vajalik rakenduse paigalduspakett tohib sisaldada ainult käitamiseks. minimaalse rakenduse käitamiseks vajamineva failikomplekti. 10.3 Kooste kirjelduste alusel valmivat Näiteks ei tohi tekitada olukorda, kus rakenduse jooksutamiseks uues serveris tuleb see tingimata just paigalduspaketti peab olema võimalik sealsamas kokku kompileerida. liigutada erinevate masinate vahel. 10.4 Lähtekoodi kompileerimine peab olema Erandina võib kasutada NuGet pakette väliste teekide jaoks, kuid erand tuleb kooskõlastada esmalt tellijaga teostatav ka võrguühenduse puudumise projekti alguses korral. 10.5 Andmebaasi paigalduse skriptid ei tohi Administraator tahab veenduda skripti sisus. olla kompileeritud.  Nõuded infosüsteemi dokumentatsioonile Nõuded infosüsteemi dokumentatsioonile Versioon: 1.0 Dokumendid peavad vastama vähemalt alljärgnevatele tingimustele: Andmemudel (kuuluvus: [Tervise Infosüsteem] -> Infosüsteemi dokumentatsioon -> alamsüsteem -> Andmemudel) Eeldus dokumendile: Teenuste/kasutuslugude dokumentatsioon Otstarve: Kirjeldada andmeobjekte ja nendevahelisi seoseid Sisu: Andmebaasi põhjal luua andmetabelite ja -objektide seosdiagramm. Sihtgrupp: Tellija, peakasutajad, rakenduse administraatorid Ajakava: enne esimese arendusetapi algust enne igat arendusetapi algust igakordsel üleandmisel Kirjeldada andmemudelit kontseptuaalse mudelina jah jah interaktioone/seoseid Kasutaja õiguste ja tegevuste vastavustabel (kuuluvus: [Tervise Infosüsteem] -> Infosüsteemi dokumentatsioon -> alamsüsteem -> Kasutaja õiguste ja tegevuste vastavustabel) Eeldus Süsteemi üldine kirjeldus dokumendile: Otstarve: Kirjeldada kasutaja rollide õigusi erinevates kasutuslugudes ja tegevustes Sisu: CRUD maatriks Sihtgrupp: Tellija äriprotsesse valdavad kontaktisikud, ärianalüütikud, süsteemianalüütikud, täitjast sõltumatud tarkvara hooldajad, arendajad ja edasiarendajad, testijad, arhitektid, projektijuhid. Ajakava: enne esimese arendusetapi algust enne igat arendusetapi algust igakordsel üleandmisel Nimetada kasutaja rollid jah jah Teenuste/kasutuslugude dokumentatsioon (kuuluvus: [Tervise Infosüsteem] -> Infosüsteemi dokumentatsioon -> alamsüsteem -> Teenused ja kasutuslood) Eeldus Süsteemi üldine kirjeldus dokumendile: Otstarve: Kirjeldab detailselt üleantavaid teenuseid/kasutuslugusid. Sisu: Teenuste/kasutuslugude detailse kirjelduse sisuks on: • Infosüsteemi kasutusloo/andmevahetuse teenusepõhised nõuded (ärinõuded ja neile vastavad detailsed funktsionaalsuse nõuded); • Tehnilised parameetrid; • Veateated/Hoiatused; • Teostatavad kontrollid; • Funktsionaalsuse enda 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 • Andmevahetuse teenuste kirjeldus (andmete küsimine/vastuvõtmine, turvalisus, teenuse andmestik, klassifikaatorid, xml/xsd schema ) Sihtgrupp: Tellija äriprotsesse valdavad kontaktisikud, ärianalüütikud, süsteemianalüütikud, täitjast sõltumatud tarkvara hooldajad, arendajad ja edasiarendajad, testijad, arhitektid, projektijuhid. Ajakava: enne esimese arendusetapi algust enne igat arendusetapi algust igakordsel üleandmisel Nimetada kasutuslood jah jah Arhitektuuridokument (kuuluvus: [Tervise Infosüsteem] -> Infosüsteemi dokumentatsioon -> alamsüsteem -> Arhitektuur) Eeldus Süsteemi üldine kirjeldus dokumendile: 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: Dokument peab rahuldama vähemalt alljärgnevaid sisunõudeid (Arhitektuuridokumendimall_v1.1): 1. topoloogia, süsteemi füüsiline arhitektuur (süsteemi komponendid andmebaasiserver, rakendusserver, meiliserver jms) 2. Nõuded arhitektuurile (operatsioonisüsteem, andmebaasid, liidestused, rakendusserverid, raamistikud, teenused) 3. Nõuded käideldavusele (süsteemi soovituslikud näitajad komponentide kaupa, näiteks andmesidekiirused, kättesaadavus, andmemahud, protsessori kiirus, mälumaht, komponentide arv süsteemi osade kaupa, kettasüsteemi jõudlus jms) 4. liidesed teiste süsteemidega (x-tee, meilisüsteemid) ja sõltuvused teistest süsteemidest. Liideste kirjeldused/otstarve 5. süsteemi tehnilised (sh automaatsed) protsessid ehk töövoog – komponentide omavahelised suhtlusstsenaariumid ja koostoimimine (näiteks, mis komponent ja millal pöördub X teenuse poole) 6. kolmandate osapoolte poolt toodetud kasutatavad tarkvarad/riistvarad, mis on vajalikud süsteemi toimimiseks Sihtgrupp: Arhitekt, administraator, turvaspetsialist Ajakava: enne esimese arendusetapi algust enne igat arendusetapi algust igakordsel üleandmisel Dokumendi esialgne versioon jah Seadmete ja tarkvara kasutajakesksed juhendid (kuuluvus: [Tervise Infosüsteem] -> Infosüsteemi dokumentatsioon -> alamsüsteem -> -> Seadmete ja tarkvara kasutajakesksed juhendid) Eeldus Teenuste/kasutuslugude dokumentatsioon dokumendile: Otstarve: Teenuse funktsionaalsuse kasutamiseks ja kasutuslugude läbimiseks vajalikud juhised Sisu: Igale esitluskihile peab olema koostatud eraldi kasutusjuhend, mis kirjeldab vastava komponendi funktsionaalsuse kasutusvoo põhiselt. Kirjeldus tarkvara ja seadmete kasutamise üldisest protsessist, protsessi olulisemate sammude kirjeldus. Koostatakse projekti lähteanalüüsi aluseks võttes. Tarkvara kasutusjuhend on aluseks kasutajate koolitamisel. Kasutajajuhend kirjeldab kõiki kasutajate funktsionaalsusi koos tööprotsesside kirjeldusega ning ekraanipiltide vormis näidetega. Haldusliidese kasutusjuhend (peakasutaja ja rakenduse administraatori funktsionaalsus) peab olema eraldi tavakasutaja kasutusjuhendist. Esitluskihi kasutusjuhendi minimaalne ülesehitus: lühitutvustus üldine kirjeldus koos komponentidega autentimine (kui eksisteerib) komponentide detailne kirjeldus koos kõikide funktsionaalsustega Rollide kirjeldus ja õigused Sihtgrupp: Tarkvara kasutajad, peakasutaja, rakenduse administraator Ajakava: enne esimese arendusetapi algust enne igat arendusetapi algust igakordsel üleandmisel jah Paigalduse ja administreerimise juhend (kuuluvus: [Tervise Infosüsteem] -> Infosüsteemi dokumentatsioon -> alamsüsteem -> Paigalduse ja administreerimise juhend) Eeldus Arhitektuuridokument dokumendile: Süsteemi üldine kirjeldus Otstarve: Juhend on aluseks süsteemi administreerimisele Sisu: Juhend peab rahuldama vähemalt alljärgnevaid sisunõudeid: 1. süsteemi parameetrite (seadistuste) kirjeldus ning nende muutmiste mõjud ja protseduurid. Konfiguratsioonifailide kirjeldus koos asukohtadega failisüsteemis; 2. logimise realisatsiooni kirjeldused (kuhu, mida, logide struktuur 3. rutiinsete hooldusprotseduuride kirjeldus (komponentide taaskäivituse vajadus parameetrite muutmisel); 4. paigaldamise protseduurid. Juhendis kirjeldatakse iga realiseeritud osa rakendamine (deployment) koos spetsiifiliste seadistustega. Paigaldamise protseduurid peavad olema kirjutatud selliselt (samm sammult), et süsteemiadministraator suudab rakenduse paigaldada ilma kõrvalise abita. 4.1 Nõuded rakenduse komponentidele 4.2 Rakenduse paigaldus (Vajalik tarkvara ja konfigureerimine, rakenduse pakkimine ja paigaldamine) 4.3 Andmete alglaadimine 4.4 Varundusskript 4.5 Monitooringu kirjeldus Sihtgrupp: Peakasutaja, projektijuht, süsteemiadministraator Ajakava: enne esimese arendusetapi algust enne igat arendusetapi algust igakordsel üleandmisel jah Lähtekood (sh andmebaasi struktuur) (Kuuluvus:Lähtekoodi üleandmine lepitakse kokku Tellijapoolse projektijuhiga) Eeldus dokumendile: Arhitektuuridokument Teenuste/kasutuslugude dokumentatsioon Andmemudel Kasutaja õiguste ja tegevuste vastavustabel Prototüüp Otstarve: Lähtekood on vajalik selleks et kompileerida rakendust, ning võimaldada tulevikus rakenduse muutmist. Sisu: Lähtekood peab olema hästi struktureeritud, piisavalt dokumenteeritud ning võimalikult lihtne, et sellest saaksid aru ka teised arendajad. Lähtekood peab vastama MFNile Lähtekood peab olema pakendatud vastavalt versioonimisjuhendile. Rakenduste lähtekood peab olema piisavalt modulaarne, et seda saaks tulevikus lihtsasti täiendada ning muuta. Ajakava: enne esimese arendusetapi algust enne igat arendusetapi algust igakordsel üleandmisel Minimaalselt iga nädalal tagant uuendada versioonihalduskeskkonnas. Testide ettevalmistuse dokumentatsioon (kuuluvus: [Tervise Infosüsteem] -> Infosüsteemi dokumentatsioon -> alamsüsteem -> Testiplaanid) Eeldus dokumendile: Teenuste/kasutuslugude dokumentatsioon Prototüüp (ainult kasutajaliidesega rakenduse puhul) Arhitektuuridokument Otstarve: Määrata kindlaks arendusetapil testitavad kasutuslood ja liidesed (sh välja tuua need, mille puhul rakendatakse koormusteste) tuues välja nende järjekorra. Sisu: Järjestatud (võib olla ka paralleelne) nimekiri kasutuslugudest ja liidestest (vajadusel määrates nende ulatust) koos märkega, mis on koormustestiga tagatud ning millel on testandmed Sihtgrupp: Tellijapoolne projektijuht, vastuvõtutestijad Ajakava: enne esimese arendusetapi algust enne igat arendusetapi algust igakordsel üleandmisel Nimetada kasutuslood, mille puhul jah rakendatakse koormusteste Testimise tulemite dokumentatsioon (kuuluvus: [Tervise Infosüsteem] -> Infosüsteemi dokumentatsioon -> alamsüsteem -> Testimise tulemid) Eeldus Testide ettevalmistuse dokumentatsioon dokumendile: Otstarve: Anda tellijale ülevaade läbiviidud testimise tulemustest ning esitada soovitused testandmete ja dokumentatsiooni parendamiseks (ettevalmistus, paigaldus, kasutuslugude kirjeldus jne). Sisu: Teostatud arenduste testimisel saadud informatsioon (näiteks testlood, testraport, testiplaan, testide kood jms). Peab vastama „Nõuded testimisele“ dokumendile. Dokumenteeritakse iga testimise eesmärgid (testimise maht ja ulatus), tegevused ja tulemused. Sisaldab jõudlus- ja mahutestide infot ning versiooni infot. Teste mitteläbinud testlugudele on lisatud parandused või ülesjäänud vead. MFNi vastavustabel Sihtgrupp: Arhitekt, süsteemiadministraator, turvaspetsialist Ajakava: enne esimese arendusetapi algust enne igat arendusetapi algust igakordsel üleandmisel jah Taasteplaani tegemise juhend (kuuluvus: [Tervise Infosüsteem] -> Infosüsteemi dokumentatsioon -> alamsüsteem -> Taasteplaani juhend) Otstarve: Kirjeldada erisused, millega tuleb arvestada taasteplaani loomisel Sisu: Taasteplaan peab rahuldama vähemalt alljärgnevaid sisunõudeid: 1. süsteemi halvamist võimaldavad riskid ja nende esinemise võimalikkus; 2. varundamisele kuuluvate komponentide ja asukohtade loetelu (nt rakenduse konfiguratsioonifailid rakendusserverist ja andmebaas jne), nende kirjeldused ja kasutuselevõtu protseduurid; 3. süsteemi komponentide asendusvõimalused, nende alternatiivkomponentide spetsifikatsioonid Sihtgrupp: Süsteemiadministraator Ajakava: enne esimese arendusetapi algust enne igat arendusetapi algust igakordsel üleandmisel jah Andmekogude semantiline kirjeldus ja andmekoosseis (kuuluvus: [Tervise Infosüsteem] -> Infosüsteemi dokumentatsioon -> alamsüsteem -> [Loomise kuupäev YYYY-MM-DD]_[Tervise_infosüsteem_alamsüsteemi_nimi].owl; [Loomise kuupäev YYYY-MM-DD]_[Tervise_infosüsteem_alamsüsteemi_nimi].xmi ) Sisu: Andmekogu(de) semantiline kirjeldus masinloetaval kujul (OWL-formaadis) ja andmekoosseis (XMI-formaadis) vastavalt RIHA määrusega kehtestatud nõuetele ning infosüsteemi ontoloogiat kirjeldav dokument. Sihtgrupp: Tellija, tellijapoolne projektijuht Ajakava: enne esimese arendusetapi algust enne igat arendusetapi algust igakordsel üleandmisel Esitada viimasel etapil UML vaated (kuuluvus: [Tervise Infosüsteem] -> Infosüsteemi dokumentatsioon -> alamsüsteem -> [Tervise_infosüsteem_alamsüsteemi_nimi].eap) Otstarve: Protsessi, kasutuslugude, süsteemi arhitektuuri vaadete kaudu muuta süsteem läbipaistvamaks ja ülevaatlikumaks Sisu: Loogiline vaade (Logical view) - komponendid, liidesed, rakenduskihi ja ärikihi loogika Protsessi vaade (Process view) – jõudlus, skaleeritavus, läbilaskevõime Rakendus vaade (Deployment diagram) – süsteemi topoloogia, kasutuselevõtmine, paigaldamine Sihtgrupp: Peakasutaja, projektijuht, süsteemiadministraator, arhitekt Ajakava: enne esimese arendusetapi algust enne igat arendusetapi algust igakordsel üleandmisel jah jah Üldised nõuded: Üleantav dokument peab sisaldama sisseviidud muudatusi nii, et on väljatoodud muutunud ja lisandunud osa (võrreldes viimati üleantuga)