SF täistaotlus: Elatisabi maksmise teenuse analüüsi koostamine - Tervise- ja heaolu infosüsteemide keskus

Failid

6-23169-3 06.01.2021 Väljaminev kiri.asice5522 KB

Sisu (failidest)

AS Helmes Lõõtsa 6B Registri number: 10364097 11415 Tallinn, Estonia “SKAIS2 elatisabi maksmise teenuse analüüs” Helmes AS Pakkumine Tellija: Tervise ja Heaolu Infosüsteemide Keskus Pakkuja: Helmes AS Dokumendi kuupäev: 05.01.2020 Dokumendi autorid: Eliis Väert, Aleksandr Knjazetski KONFIDENTSIAALSUS Käesolev pakkumus sisaldab AS Helmese töötajate isikuandmeid. Isikuandmete töötlemine on lubatud üksnes AS Helmes nõusolekul. Käesolev pakkumus sisaldab AS Helmes ärisaladust. Ärisaladuseks loetakse kogu pakkumus, v.a. riigihankes avaldamisele kuuluv pakkumuse maksumus. © AS Helmes. Autor hoiab endale kõik õigused. Teksti ja dokumentide esitamine ja reprodutseerimine ilma autori loata on keelatud www.helmes.ee 1 Pakkumise taust Meil on rõõm esitada pakkumine “SKAIS2 elatisabi maksmise teenuse analüüsile”. Pakkumise aluseks on Tervise ja Heaolu Infosüsteemide Keskus (Hankija) pakkumuskutse “SKAIS2 elatisabi maksmise teenuse analüüs” raamlepingu nr 3-9/2307-1 alusel. 2 Pakkumise sisu, tulemid ja meeskond Tööd tehakse vastavalt TEHIKu poolt saadetud Pakkumiskutse Lisa 1 Tehnilisele kirjeldusele. Pakkumise töö tulemusel valmib koostöös SKA ja TEHIKuga analüüs, mis sisaldab järgmist: • valdkonna põhimõistete kirjeldust; • tänase olukorra kirjeldust ja hetkeolukorraga võrreldes lisanduvad nõuded ja vajadused; • kirjeldust, kuidas elatisabi maksmise teenus hakkab andmeid vahetama teiste infosüsteemidega; • andmekoosseisusid; • andmevoogude diagrammid; • äriliste tööprotsesside kirjeldusi ja eesmärke; • ärireeglite ja -nõuete kirjeldust, sh vajalikke kasutuslugusid; • ülevaadet arendusega seotud tehnilistest komponentidest ja asendatavatest SKAIS2 komponentide funktsionaalsustest; • arendustest lähtuvaid muudatusi andmemudelis ja arhitektuurilises pildis; • lahendustest lähtuvaid muudatusi süsteemi läbipaistvuse/jälgitavuse parandamiseks. • Loodava lahenduse prototüüp ametniku- ja kliendivaates koos lõppkasutajate testimise infoga (prototüüpi testinud lõppkasutajate arv, aeg ja tagasiside). • Prioriseeritud tööde nimekiri (backlog), sh vajalike liideste loetelu. • Tööde nimekiri koos mahuhinnangutega. 2 www.helmes.ee Tööde teostamisel arvestame: • Olemasoleva elatisabi teenuse käsitlusega; • Loodava elatisabi teenuse käsitlusega, • Olemasoleva SKAIS2 andmebaasi struktuuriga; • Olemasoleva SKAIS2 rakendusega ja arhitektuuri nõuetega, sh olemasolevate väliste liidestega; • Loodud prototüüpidega SKAIS2 ametnikurakenduse ja iseteeninduse kohta; • Raamlepingus kokku lepitud mittefunktsionaalsete nõuetega; • Raamlepingus kokku lepitud dokumenteerimise nõuetega; • Raamlepinguga kokku lepitud kodukorraga. Järgnevalt on välja toodud tööde teostamiseks vajaminevad keskkonnad ja nende ligipääsud. • SKAIS2 - projekti dokumentatsioon Confluence’i keskkonnas; • Jira – backlog ja teostatud kasutuslood; • Iseteeninduse prototüüp (kodaniku vaade); • Gitlab – koodikeskkond Tööd antakse üle hiljemalt 08.03.2021 Confluence'i keskkonnas. Tööde üleandmisele järgneb tellija poolne tööde vastuvõtmisaeg mõistliku aja jooksul. Tööde teostamiseks planeeritud meeskonnaliikmed: • Aleksandr Knjazetski – projektijuht, analüütik • Helen Kirs – projektijuht, analüütik (alltöövõtja) • Merike Üts - analüütik • Antti Haljak – analüütik • Anna Linskaja – analüütik • Markus Karileet – arhitekt • Eliis Väert - projektijuht Tööde teostamise ühe töötunni hind on viiskümmend kolm eurot ja nelikümmend seitse senti. Tööde teostamise kogumaksumus on 70 045,70 eurot (ilma käibemaksuta). 3 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 valida Eelistatud Aktsepteeritav Mitte valida KOMMENTAARID KOMPONENT (TE (Preferred) (Acceptable) (Do not select) (Preferred) (Acceptable) (Do not select) (COMMENTS) CHNOLOGY COMPONENT) Kliendi kiht (Client Layer) Lauaarvuti ja sülearvuti OS / Windows Linux keskkond macOS (Desktop & laptop client OS / environment) Lauaarvuti ja sülearvuti kliendi HTML5 HTML 4 Internet Explorer Safari kasutajaliides Firefox Native for COTS (Desktop & laptop Chrome (commercial off- client user the-shelf) in interface) special cases EDGE - ID kaardi logimine ei tööta Mobiilse kliendi OS / keskkond iOS Windows Phone (Mobile client OS / Android Java application environment) (Java ME Runtime Environment) Mobiilse kliendi kasutajaliides HTML5 Native App HTML 4 Chrome HTML5 IE for mobile (Mobile client user Safari packaged into Opera interface) Android browser Native app Native App Eelistatud Aktsepteeritav Mitte valida Eelistatud Aktsepteeritav Mitte valida KOMMENTAARID (Preferred) (Acceptable) (Do not select) (Preferred) (Acceptable) (Do not select) (COMMENTS) Esitluskiht (Presentation Layer) Portaali raamistik Liferay MS Sharepoint (Portal framework) Sisuhaldussüsteem (Web content Typo3 Drupal Wordpress management Joomla system) Esitluskihi raamistik MVC pattern Java: JSP Microsoft .Net (Presentation JS: JSF framework (View)) Python Angular* Bootstrap Veebiserver Apache Microsoft IIS (Web server) Nginx (for Microsoft based applications) Funktsionaalne testimine Selenium (Functional testing) Eelistatud Aktsepteeritav Mitte valida Eelistatud Aktsepteeritav Mitte valida KOMMENTAARID (Preferred) (Acceptable) (Do not select) (Preferred) (Acceptable) (Do not select) (COMMENTS) Rakenduskiht (Application Layer) Rakenduse For Javascript raamistik MVC pattern Java: Spring Microsoft .Net include tools from (Application JS: AngularJS Yeoman, Karma, framework) Java: Digidoc4j Jasmine Persistence Updates pending framework ORM frameworks Java: MyBatis jOOQ Hibernate Otsingumootori indeks Elasticsearch (Search Engine Index) Integratsioon (External SOAP AQ SOAP: Apache AQ integration REST JMS Axis 2, Apache JMS (integration to other AMQP CXF RabbitMQ systems)) REST: Language based frameworks Andmete laadimine (Data Loading - Pentaho iWay service ETL) manager Sybase ETL Aplikatsiooniserver (Application server) Java .NET Tomcat WildFly Java EE: Java EE WSGI .NET: MS IIS Apache JServ Webmethods Sun Java Integration System Server Application Server SAP IBM WebSphere Oracle iAS Oracle iPlanet Web Server WebLogic Aplikatsiooni haldus- ja JMX Plumbr NewRelic monitooringu Appdynamics raamistik (Application management framework) Funktsionaalne testimine SoapUI (Functional testing) Eelistatud Aktsepteeritav Mitte valida Eelistatud Aktsepteeritav Mitte valida KOMMENTAARID (Preferred) (Acceptable) (Do not select) (Preferred) (Acceptable) (Do not select) (COMMENTS) Andmekiht (Persistence Layer / Database layer) Andmebaasi migratsioon Liquibase (Database migration) Relatsiooniline andmebaas SQL PostgreSQL MariaDB (OLA: Sybase (Relational DBMS) XML (OLA: Standard) Standard) MS SQL Server (OLA: Ärikriitiline) Oracle (OLA: Ärikriitiline) Mitterelatsioonilised andmebaasid: MongoDB Memcached NoSql, puhver, CouchBase sessioonihoidla Redis (Non-Relational DBMS: NoSql, Cache, Session store) Andmeladu (Data Warehouse) Vertica Sybase IQ CouchBase Andmete replikatsioon Oracle Active PostgreSQL (Data Replication) Data Guard Londiste Postgres-BDR Eelistatud Aktsepteeritav Mitte valida Eelistatud Aktsepteeritav Mitte valida KOMMENTAARID (Preferred) (Acceptable) (Do not select) (Preferred) (Acceptable) (Do not select) (COMMENTS) Infrastruktuuri kiht (Infrastructure Layer) Directory services LDAP v3 MS Active OpenLDAP Directory OpenDJ Oracle Internet Directory Autentimine (Authentication) Kerberos SAML MS AD (Local JASIG CAS OpenID Connect Java network) Atlassian Crowd Authentication TARA and AAM (TEHIK-u Authorization API komponent OAUTH Autentimis- autoriseerimismo odul) Ühekordne sisselogimine AAM (Single Sign On - SSO) Kasutajaõiguste haldus RBAC MS AD Atlassian Crowd (Authorization) Application specific AAM Identiteedi haldus (Identity management) Konfiguratsioonihal dus SaltStack Ansible Spacewalk (Configuration MS SCCM management) Logihaldus (Log management) SysLog RSysLog RELP ELK Stack GreyLog Süsteemi haldamine ja SNMP Agent Zabbix ja zabbix Nagios järelevalve agendid Inhouse built (System Extreme Cacti management and Management Oracle monitoring) Center Enterprise Manager Koormusjaotur (Traffic Nginx F5 management) (OpenResty) A10 Puhverdamine (Caching) Nginx Squid (OpenResty) Varnish Tööde ajastamine (Job scheduling) Application Webmethods IS specific scheduler decision ie Quartz or cron, windows scheduler Serveri operatsioonisüsteem Linux Unix Linux Debian (OLA: IBM AIX Windows RedHat (OLA: Standard) Other UNIXs (Server OS) Ä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 Konteinerid Docker Virtualiseerimine (Virtualization) Full virtualization Paravirtualization VMWare OracleVM Hyper-V Xen Serveri riistvara (Server HW) x86 RISC HP IBM Power Varundamine (Backup) Centralized SW: Mitte- Veritas tsentraalset Netbackup hallatavaid asju Symantec Backup Exec HW: HP IBM Qualstar Storage HW SAN Hitachi HDS NAS Fujitsu LAN Extreme HP Networks Juniper VPN SSL VPN PulseSecure Checkpoint IPSec Microsoft DA SAN Fibre Channel iSCSI Brocade Cisco Riistvaraline krüptomoodul Utimaco Thales Gemalto (HSM - Hardware security module) Tulemüür (Firewall) NGFW Juniper Checkpoint Eelistatud Aktsepteeritav Mitte valida Eelistatud Aktsepteeritav Mitte valida KOMMENTAARID (Preferred) (Acceptable) (Do not select) (Preferred) (Acceptable) (Do not select) (COMMENTS) Muud aspektid (Other Aspects) Programmeerimiske eled ja raamistikud Java .NET (Programming JavaScript C/C++/C# languages / PHP framework) Python Webmethods flow iWay Functional Language Java virtuaalmasina OpenJDK Oracle JDK implementatsioon Versioonihaldus (Version control GitLab SVN system) Atlassian Bitbucket Tarkvara binaar repositoorium (Artif JFrog artifactory acts repository) Pidev tarne/Pidev integratsioon (Conti Jenkins nuous integration) Gitlab CI Lähtekoodi analüüs (Code analysis) SonarQube Analüütika (Analytics) Tableau Webfocus Qlik Sense Oracle BI Publisher SAP® Business Objects Legend Kuidas valida? Ohutu valik Vajab arhitektuuri- Ära raiska aega Ohutu valik Vajab arhitektuuri- Ära raiska aega (How to select?) tugeva toetusega nõukogu (Do not waste tugeva toetusega nõukogu (Do not waste (Safe selection heakskiitu time) (Safe selection heakskiitu time) with strong (Needs with strong (Needs support) Architecture support) Architecture Board acceptance) Board acceptance) Sotsiaalkaitse infosüsteem Front-end arendusreeglid Raamlepingu lisa 4 Lühendid FE – Front-end BE – Back-end FF – Mozilla Firefox IE – Internet Explorer UI – User interface (kasutajaliides) SEO – Search engine optimization Eesmärk ja sihtgrupp FE arendusreeglid on mõeldud kõigile FE ja BE arendajatele. Reeglite järgimine on kohustuslik. Veebilehitsejate tugi Laua ja sülearvutid  A klass: IE11+, Chrome (viimane versioon), FF (viimane versioon), Microsoft Edge (viimane versioon) Lõpptulem ei tohi kujundusest erineda, välja arvatud veebilehitsejate implementatsioonist tulenevad erandid (näide: selectboxi native kujundus on veebilehitsejates omavahel erinev ja see on lubatud)  B klass: Safari Visuaalselt korrektne, aga võib erineda algsest kujundusest. Mobiilsed seadmed  IOS + Safari  Android + Samsung Internet  Android+ Chrome Abistavad tehnoloogiad Iseteenindus peab olema kasutatav järgmiste ekraanilugeritega  Windows – JAWS  Windows – NVDA  OSX – VoiceOver Ekraanilugerid peavad töötama järgmistes ekraaniluger–veebilehitseja kombinatsioonides  JAWS+InternetExplorer  JAWS+GoogleChrome  NVDA+Firefox  VoiceOver+Safari Stiililehed Peab lähtuma RIA stiiliraamatus kasutatud praktikatele. Kataloogide stuktuur Peab lähtuma RIA stiiliraamatus kasutatud praktikatele. Style-Guide Driven Development ja Living Style-Guide Selleks, et võimalikult palju front-end komponentidest oleks dokumenteeritud ja lihtsasti leitavad tuleb rakendada style-guide driven developmenti. Üldiselt tähendab see – kui tekib vajadus uue komponendi järgi, mida veel süsteemis kasutusel ei ole siis esmalt dokumenteeritakse see stiiliraamatus. Kindlasti peavad dokumenteeritud saama komponendid, mida kasutatakse rohkem, kui ühes kohas. Living Style-Guide kontsept tähendab seda, et infosüsteemi kasutajaliidese dokumentatsioon ja rakenduse lähtekood on alati sünkroonis ja kõik ajas toimuvad muudatused saavad dokumenteeritud. Dokumentatsioonis peab sisaldama  Komponendid ja nende erilahendused. N: nuppude puhul nende suuruste ja värvi variatsioonid. o Näidised kuidas komponenti rakenduses välja kutsuda o Komponendiga seotud HTML ja CSS classid o Sisend parameetrid o Meetodid ja funktsioonid Re-usable front-end 1. Enne kodeerimist tutvuda olemasolevate komponentidega. 2. Võimalusel kasutada olemasolevaid elemente. 3. Kujunduses olevate väikeste erinevuste puhul pakkuda välja ühtlustamise võimalusi ja lahendusi. 4. Kasutada üldiseid classi nimetusi ja arvestada kodeerimisel, et antud stiile oleks võimalik kasutada läbivalt. Erandite puhul kasutada eraldi classi nimetust. 5. Kodeerimisel arvestada, et uue elemendi muutmine ja haldamine oleks võimalikult lihtne. Näiteks arvestada keelsusega. Võimalusel vältida keelte jaoks erandite tegemist. CSSi haldamine Selleks, et tagada kasutajaliidese ühtne väljanägemine ja vähendada sarnaste stiilide topelt kirjutamist on stiilide haldus reglementeeritud. Seni kuni see ei muutu arenduses pudelikaelaks on stiilidel üks haldaja ja vastutaja, kes on kursis kõigi muudatustega. Tema kohustus on üle vaadata teiste poolt kirjutatud CSS ja vastavalt vajadusele muuta või saata tagasi arendajale parandamiseks. Arendusmeeskonna ja mahtude kasvades tuleb stiilide haldamise rolli laiendada laiemale meeskonnale. Illustreerivad pildid  Illustreerivad pildid peavad olema lisatud CSSi abiga.  Pildid on optimeeritud  Eelistada illustreerivate piltide kuvamist läbi CSSi.  HTMLis lingitud piltide nimetamisel arvestada SEOd ja ühtset stiili.  CSSi pildid nimetada sarnase loogikaga. Näiteks: Ikoonide alguses on icon_, taustapiltidel bg_ logodel logo_, nimekirjadel ul_ ja komponentide spetiifiliste piltidel puhul selle classi nimetus. Kui kasutatakse CSS raamistikku siis lähtuda raamistikus kehtestatud reeglitest  Pildi nimed on läbivalt inglise keeles ja semantiliste nimetusega. Ei tohi kirjeldada pildil olevat värvi. Semantika Front-end kood peab vastama semantika reeglitele, välja arvatud juhul, kui kokkulepitud kasutatav raamistik ei võimalda seda saavutada. Kodeerimisel tuleb arvestada responsive (kohandub iseenesest ümber erinevatele ekraanisuurustele) versioonile üleminekuga. Olulisemad punktid  Classi nimed on üldised või komponendi spetsiifilised  Kasutada semantiliselt korrektseid HTMLi elemente. o Näiteks nimekirjade puhul peab olema kasutatud UL või OL tagi vastavalt sisule. o BR ei tohi kasutada paigutuse loomiseks. Võib kasutada otstrabeliselt tekstide sees o Tabeleid tohib kasutada ainult tabelite jaoks, mitte üldise lehe struktuuri loomiseks. o Inline elemendi sisse ei tohi panna block elemente. o Paragraafide sisse ei tohi kirjutada DIVe.  Vältida tühjade HTMLi elementide kasutamist. HTMLi reeglid  HTML peab valideeruma kasutades https://validator.w3.org HTML valideerimisvahendit. o Arvestada, et eristatakse Angular– ja HTML spetsiifilisi valideerimise tulemusi. – Eesmärk on tagada korrektne ja standardile vastav HTML kood aga ignoreerida Angular raamistikust tulenevaid HTML valideerimise veateateid.  Inline CSSi ei tohi kirjutada ja kasutada.  Cellpadding'uid ja cellspacing'uid ei tohi kasutada HTMLis.  Võimalusel kirjutada optimeeritud koodi ja vältida üleliigseid elemente ja defineeringuid.  Kasutada läbivalt ühtset stiili. o Jutumärkideks on topelt jutumärgid  näide class="style01" o Arenduse failid on ühe tabi abil trepitud.  Arvestada SEO soovitusi o Vajadusel illustreeritavatel piltidel korrektsed alt väärtused. o Meta tagid vastavalt kaasaegsetele nõudmistele.  Piltide või ikoonide puhul, mis on kasutusel linkidena, kasutada title tagi. Title sisu peab kasutajale andma informatsiooni, et kuhu see link kasutaja suunab. o Näide logo title väärtus on "Avalehele"  HTMLis vältida ja eemaldada üleliigsed (näiteks arendajate kommentaarid) kommentaarid. CSSi reeglid Kehtib FE arendaja poolt loodud stiililehtede kohta. Ei kehti juhul, kui kokkulepitud kasutatav raamistik ei võimalda seda saavutada. Iseteenindus hakkab kasutama RIA stiiliraamatut, mis on ehitatud Bootstrap4 CSS raamistikule – Iseteeninduse stiilid peaksid jälgima Bootstrap css juhiseid http://codeguide.co/#css. Allikas https://github.com/twbs/bootstrap/blob/v4.0.0/.github/CONTRIBUTING.md#code-guidelines  CSS peab valideeruma kasutades https://jigsaw.w3.org/css-validator/ CSS valideerimisvahendit. o CSS valideerimisel võetakse aluseks profiil CSS level 3 + SVG, brauseri tootjate spetsiifiliste (vendor prefix) css reegleid käsitletakse kui hoiatusi ja nende kasutamine on aktsepteeritav. Kui tekib vajadus vanemate brauserite toetamiseks kasutada mitte valideeruvat CSS-i siis selles lepitakse eraldi kokku.  CSSi treppimine o Selektori ja loogeliste sulgude vahele üks tühik. o Üks tab enne atribuuti (laiuselt võrdne nelja tühikuga). o Selektorid ja atribuudid on eraldi ridadel. o Näide o ul*{ o ****margin:*0; }  Selectori blokkide vahel tühjad read eraldamaks erinevaid elemente aga üldiselt ilma tühja reata.  h1 {  font-size: 34px;  }  h2 {  font-size: 24px;  }  a{  color: #08c;  }  a:focus,  a:hover {  color: #ff6; }  Esimese taseme ja teise taseme kommentaari ees ja järgi üks tühi rida.  CSSis blokkide järjekord: o normalize/reset, global o common o vastavalt struktuurile header, content ...  media queries hoida komponendi lähedal o Plugina CSSid, kui on tegemist pluginaga, mida kasutatakse samade stiilidega erinevates asukohtades, siis antud CSS lisada eraldi faili.  CSS Atribuutide järjekord:  .declaration-order {  /* Positioning */  position: absolute;  top: 0;  right: 0;  bottom: 0;  left: 0;  z-index: 100;   /* Box-model */  display: block;  float: right;  width: 100px;  height: 100px;   /* Typography */  font: normal 13px "Helvetica Neue", sans-serif;  line-height: 1.5;  color: #333;  text-align: center;   /* Visual */  background-color: #f5f5f5;  border: 1px solid #e5e5e5;  border-radius: 3px;   /* Misc */  opacity: 1; }  Ühikud o Eelistatult läbivalt kasutada rem ühikuid. https://getbootstrap.com/docs/4.1/migration/#global-changes o 0 väärtuse korral ühik pole vajalik. 0em == 0px == 0  Class' ja ID nimetused läbivalt väikeste tähtedega, semantilised ja eralduseks kasutatud sidekriipsu. o Näide: data-table-outer  Classide nimetamisel kasutada läbivalt inglise keelt.  ID kasutamine stiilide jaoks on välistatud  CSSis on kaks taset kommentaare. 1. esimene tase /** =Kommentaar */ 2. teine tase /** =Kommentaar */  Kommentaarid läbivalt inglise keeles. Vajadusel rakenduse spetiifilisi mõisteid kasutada eesti keeles.  Välja kommenteeritud koodi ei tohi jätta alles.  Margin ja paddingute korrektne kasutamine. Paddingut kasutada antud elemendi sisse nn õhu jätmiseks ja marginit väljapoole.  Tekstide joondamisel vältida line-heighti abil joondamist ja eelistada paddingut.  CSS kirjutada ainult selleks mõeldud faili. Inline CSSi ja HTMLi failis eraldi <style> kasutada ei tohiks. Võimalusel vältida ka visuaalsete stiilide defineerimist JS failides.  Pildi URLi lisamisel jutumärke ei ole vaja kasutada.  Vältida veebilehitsejaspetiifilisi häkke.  Kodeerimisel arvestada WCAG 2.1 AA taseme ligipääsetavuse nõuetega o http://www.w3.org/WAI/WCAG20/quickref/ o http://kristjankure.com/ Eeltöötlus (preprocessor) keeled Kasutada SASS preprocessor keelt SCSS süntaksiga. Selektorite nestimine Selektorite nestimisel tuleb piirduda kolme tasemega. Üle kolme taseme nestimine teeb koodi lugemise liialt keeruliseks .element { .element-child { p{ //Siit sügavamale ära mine } } } Optimeerimine FE tehnikate abil  https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Writing_efficient_CSS o tbody#select-01 => #select-01 o #navigation li a => #nav a o tr.tr-name td.td-name => .td-name  HTMLis olevatele piltide määrata kõrgus ja laius, kui on võimalik. Eesmärk vähendada re-flow'ed.  Gradientide, ümarate nurkade jne puhul kasutada CSS3 ning vanematel veebilehitsejatel peab kujundus välja nägema visuaalselt korrektne aga ei pea olema visuaalselt identne. Kontrollida veebilehitseja võimalusi siit http://caniuse.com/.  Kui on võimalik illustreerivad pildid nt nooled, bulletid asendada CSS3 lahendusega, siis seda võimalust kasutada. Kui vajadus tühja elementi kasutada, siis selle asemel kasutada CSSis before'i võimalust. Selle juures tuleks arvestada veebilehitsejate tuge ja kasutajamugavust mõistlikuse piirides. Informatsioon peab olema arusaadav ja kättesaadav ka B klassi veebilehitseja toele.  Reflow ja repaint'iga arvestamine.  CSSi reseti asemel kasutada normalize.  Värvid kirjutada koodi abil (soovitavalt hex aga vajadusel rgba) ja läbivalt väikeste tähtedega. Võimalusel lühendada kolme tähelisteks. o #ffffff => #fff o #ff88aa => #f8a, #ff0000 => #f00  Võimalusel CSSi väärtused tõsta kokku ühele reale. o Border-top, border-left, border-bottom, border-right => border  Important kasutamist CSSi failis vältida.  Normalize/reseti puhul ei tohiks olla defineeritud elemente, mida praktikas ei kasutata. Uue projekti alguses tuleks reset/normalize optimeerida ja vajadusel jooksvalt juurde lisada elemente.  Võimalusel ja vajadusel kasutada sprite tehnikat.  Pluginatega kaasa tulevat CSSi peab ülevaatama, optimeerima ja järjekorda uuendama. Kujundus  Linkidele, nuppudele alati korrektsed :hover, :focus ja :active staatused määrata. o hoveri ja fookuse puhul on eesmärk tuua visuaalselt element rohkem esile ja paremini loetavaks. o aktiivse staatuse puhul tuleks jätta mulje, et nupule või lingile on vajutatud. Visuaalselt poolelt näiteks gradient on vastupidine või lingi värv on tagasihoidlikum.  Arvestada olemasoleva kujundusega ja jälgida sellele sarnast stiili.  Ühtlustada ja jälgida lõpptulemuse joonduseid. Lisa 5. Tehniline kirjeldus Sisukord: 1. Hanke eesmärk ................................................................................................................................ 2 2. Äriline taust ....................................................................................................................................... 2 2.1. SKA teenuste tutvustus .......................................................................................................... 3 2.2. Teenuste kirjeldus ja arendussoovid .................................................................................... 8 2.3. SKAIS alamsüsteemide toimimine ...................................................................................... 14 2.4. SKAIS teenuste kasutajagrupid ........................................................................................... 15 2.5. SKAIS arendustööde teostamise üldised ärilised nõuded .............................................. 16 3. Hangitav skoop .............................................................................................................................. 16 4. Tööde tellimise põhimõtted .......................................................................................................... 16 5. SKAIS2 arenduste indikatiivne teekaart ..................................................................................... 17 1 1. Hanke eesmärk Riigihanke eesmärk on sõlmida kaks raamlepingut, kumbki ühe partneriga. Riigihange on jaotatud osadeks järgmiselt:  Osa 1 - Sotsiaalkaitse infosüsteemi SKAIS2 pensionite teenuste ja nendega seonduvate arendustööde tellimine: o Praegu on pensionite teenused SKAIS1 platvormil. Tellijal on soov teenus üle viia SKAIS2 platvormile ning võtta teenus kasutusele iseteeninduses. o Esmaste töödena on planeeritud tänase parima teadmise põhjal raamlepingu alusel tellida analüüsitööd, kuidas tellija soove on mõistlik realiseerida.  Osa 2 - Sotsiaalkaitse infosüsteemi SKAIS2 hallatavate avalike teenuste (v.a pensionite teenustega seonduv) ja nendega seotud arendustööde tellimine. Hankija soovib jõuda teenuste arendamisega valmis võimalikult kiiresti, et hoida kokku riigi ressursse ja pakkuda kasutajatele paremaid lahendusi. 2. Äriline taust Sotsiaalkaitse infosüsteem (edaspidi SKAIS) katab Sotsiaalkindlustusameti (edaspidi SKA) peamisi tegutsemisvaldkondi, toetades eelkõige igapäevaseid rutiinseid ja töömahukaid avalike teenuste tööprotsesse. SKAISi vastutav töötleja on Sotsiaalkindlustusamet, üheks volitatud töötlejaks on TEHIK. Täna kasutusel olev SKAIS koosneb tehniliselt neljast infosüsteemist - SKAIS1, SKAIS2, AVE ja EBS. SKAIS1 on 1999. aastast kasutusel olev infosüsteem, mis toetab hüvitiste arvutamist ja rahaliste väljamaksete teostamist, mida saavad kasutada ainult ametnikud. Teatud e-teenused on isikutele kättesaadavad eesti.ee portaalis. SKAIS2 on kasutusel 2017.a algusest. Erinevalt SKAIS1-st peab SKAIS2 võimaldama inimestel ja SKA partneritel kasutada SKA teenuseid üle veebi ja iseteeninduskeskkonna kaudu, sh kasutades nutiseadmeid. Mõlemas infosüsteemis toimub hüvitiste ja toetuste menetlemine ning väljamaksmine. AVE kaudu toimub täna abivahendite teenuseosutajate aruandlus, mille tulemusena saab abivahendite teenuseosutaja SKA-le arve esitada. AVE on kasutusel abivahendite eriotsuste ja arvestuse eesmärgil. SKAIS1 on mõeldud ainult ametkondlikuks kasutamiseks ehk ametnikuportaalina. SKAIS2 on kasutusel nii ametnikuportaalina kui ka kodanikele iseteenindusena e-teenuste kasutamiseks. Lisaks on inimestel võimalik täna veel ka e-teenuseid kasutada läbi portaali eesti.ee. Enamus kasutajaliidese lahendusi on nii iseteeninduses kui ka ametnikurakenduses sarnased või samased. Täpsemalt on kasutajagrupid välja toodud punktis 2.4. Väljamakseid teostatakse majandustarkvara Oracle E-Business Suite (edaspidi EBS) ja SKAIS1 finantsmooduli kaudu. Samas tuleb arvestada, et inimese maksuarvestust tuleb teostada süsteemide üleselt. 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. Praegu 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. Lisandunud on ka Euroopa Komisjoni poolt loodud EESSI 2 (Electronic Exchange of Social Security Information) IT-süsteem, 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 ehk SED-ide vahendusel. SKAIS1 kaudu toimub punktis 2.1. nimetatud teenuste menetlemine, määramine ning väljamaksmine. SKAIS2-s on praeguseks kasutusel elatisabiteenus (kohtumenetlusaegne elatisabi ja täitemenetlusaegne elatisabi), puude raskusastme tuvastamine ja sotsiaaltoetuse teenus (puude raskusastme tuvastamine, puuetega inimeste sotsiaaltoetus, puudega isiku kaart), peretoetused, finantsarvestus ja väljamaksed (finantsarvestus, raamatupidamiskannete tegemine ja väljamaksed). Peagi valmib abivahendite õigustatuse kontrolli ja tehinguinfo vahetamise teenus. 2.1. SKA teenuste tutvustus Teenuste kasutus SKAIS1s, SKAIS2s ja AVEs: Valdkond Teenus Teenuse lühikirjeldus LIVE infosüst. Sotsiaalne Teenus on mõeldud puuetega inimestele ja osalise või puuduva SKAIS1 rehabilitatsioon töövõimega inimestele. Inimesele pakutakse välja rehabilitatsiooniprogramm või teenuste vajaduste hindamise käigus koostatakse inimesele tegevuskava või suunatakse inimene rehabilitatsiooniasutusse isikliku rehabilitatsiooniplaani koostamisele. Teenus on mitterahaline hüvitis, millega SKA võtab isiku eest üle tasu maksmise kohustuse teenuse eest. Rahalise hüvitisena kuuluvad isikule ja tema saatjale hüvitamiseks majutus- ja sõidukulud, mis on tehtud seoses rehabilitatsiooni teenusega. Erihoolekanne Teenus on mõeldud alates 18-aastastele inimestele, kes vajavad oma SKAIS1 vaimse tervise olukorra tõttu igapäevaelus juhendamist, nõustamist, kõrvalabi ja järelevalvet vastava eriala spetsialistilt. Erihoolekandeteenustena on võimalik saada toetavaid teenuseid elades Sotsiaal- oma kodus või kogukonnas elamise teenust ja ööpäevaringset teenused erihooldusteenust teenuseosutaja pakutud elupinnal. SKA peab ühtset järjekorda, kuhu on 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. Abivahendi Teenus on mõeldud inimestele, kellel on tuvastatud puue või osaline või SKAIS1/ hüvitamise puuduv töövõime või kes on 63-aastane või vanem SKAIS2 teenus vanaduspensioniealine inimene, kellele arst on väljastanud tõendi või AVE 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 inimese eest üle abivahendi soetamise või rentimise tasu maksmise kohustuse. Riiklik pension Teenus on mõeldud vanaduspensioniealistele inimestele, SKAIS1 töövõimekaotusega inimestele või toitjakaotuse korral toitja ülalpidamisel olnud inimestele. Riiklik pension koosneb kolmest komponendist: baasosast, pensioni staažiosast ja Pensionid pensionikindlustusosast. Pensioni staažiosa ja pensionikindlustusosa 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 arvutatakse 3 kindlustusosa, mis arvutatakse isiku eest makstud sotsiaalmaksust. Riiklik pension on rahaline perioodiline hüvitis, mida makstakse igakuiselt. Alates 01.01.2021 muutuvad riikliku pensioni arvutamise ärireeglid. Eripension Teenus on mõeldud inimestele, kes on seaduses ettenähtud vanuses SKAIS1 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 staažiosa ja pensionikindlustusosa. Pensioni staažiosa ja pensionikindlustusosa 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 arvutatakse kindlustusosa, mis arvutatakse isiku eest makstud sotsiaalmaksust. Eripension on rahaline perioodiline hüvitis, mida makstakse igakuiselt. Rahvusvahelin Teenus on mõeldud vanadusepensioniealistele inimestele, SKAIS1 e pension töövõimekaotusega inimestele või toitjakaotuse korral toitja ülalpidamisel olnud inimestele, kui inimene on töötanud vähemalt aasta Euroopa Majanduspiirkonna riigis või mõnes järgnevatest riikidest: Ukraina, Vene Föderatsioon, Valgevene, Moldova, Kanada või Austraalia. Rahvusvaheline pension koosneb kolmest komponendist: baasosast, pensioni staažiosast ja pensionikindlustusosast. Pensioni staažiosa ja pensionikindlustusosa 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 arvutatakse kindlustusosa, mis arvutatakse isiku eest makstud sotsiaalmaksust. Rahvusvahelise pensioni määramisel ja maksmisel tuleb arvestada 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 inimesele või pädevale asutusele. Üksi elava Teenus on mõeldud inimestele, kellele on määratud pension ja kes on SKAIS1 pensionäri vanaduspensioniealine, kes elab Rahvastikuregistri andmetel oma toetus elukohas üksi ning kelle pensioni suurus on alla 1,2-kordse Eesti keskmise vanaduspensioni. Teenuse saamiseks inimene 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 inimene vastab nõutud tingimustele perioodil 01.04 - 30.09. Pensioni Teenus on mõeldud inimestel, kes ei ole veel vanaduspensionieas. SKAIS1/ määramiseks Pensioni määramiseks vajaliku info kogumine on inimese töötamise, SKAIS2 vajaliku info õppimise, armees teenimise või laste kasvatamise eest pensioni kogumine määramiseks vajalike andmete sisestamine infosüsteemi. Lisaks isikutele võivad tööraamatuid SKA-le esitada ka tööandjad. Andmete tulemi põhjal peab süsteem hakkama tegema inimestele pakkumusi enne vanaduspensioniea saabumist ning pakkumusega nõustumisel või täiendavate andmete esitamisel võetakse olemasolevad andmed pensioni määramise aluseks. Peretoetused Teenus on mõeldud lapsi kasvatavatele peredele. Peretoetused on SKAIS2 rahalised hüvitised, mida makstakse seoses laste kasvatamisega perekonnas. Hüvitiste suurused on seadusega kindlaks määratud summad. Makstava peretoetuse suurus sõltub perekonnas kasvavate Perehüvitise laste arvust, laste vanusest ning õppimisest. Peretoetused on rahalised d hüvitised, mis jagunevad ühekordseteks hüvitisteks ja perioodilisteks hüvitisteks. Ühekordseid peretoetuseid on kaks alamliiki ja perioodiliselt makstavaid hüvitisi on seitse alamliiki ning neid makstakse üks kord kuus. 4 Vanemahüvitis Teenus on mõeldud vanemale seoses lapse sünniga, lapsendajale, SKAIS1 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. Vanemahüvitise ärireeglite muudatused, mis on tänaseks teada on järgmised: 01.07.2020 tekib isal õigus isapuhkusele senise 10 tööpäeva asemel 30 päevaks ning saada selle perioodi eest vanemahüvitist. Vanemahüvitist on võimalik periooditi kasutada lapse kuni 3-aastaseks saamiseni. Aastaks 2022 on planeeritud olulisemad muudatused vanemahüvitise teenused. Kohustusliku Teenus on mõeldud lapsevanematele, kes kasvatavad kuni 3-aastast SKAIS1 kogumispensio last ja on liitunud II pensionisambaga. SKA teeb lapse ühe vanema eest ni täiendavad lapse sünnist kuni lapse 3-aastaseks saamiseni täiendavaid sissemaksed sissemakseid kohustusliku kogumispensioni kontole. Sissemaksete suuruseks on 4% Eesti keskmisest sotsiaalmaksuga maksustatavast ühe kalendrikuu tulust. Kohtumenetlus Teenus on mõeldud kuni 18-aastasele lapsele või õppivale kuni 21- SKAIS2 -aegne aastasele lapsele, kelle vanem või vanemad ei täida elatisabi ü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 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 vanemalt, kellele kohus tegi otsuse elatise väljamõistmiseks. Elatisabi Täitemenetlus- Teenus on mõeldud kuni 18-aastasele lapsele või õppivale kuni 21- SKAIS2 aegne elatisabi aastasele lapsele, 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. Puude Teenus on mõeldud inimestele, kellel on terviseprobleemide tõttu raske SKAIS2 raskusastme igapäevaelus toime tulla ja ühiskonnas tegutseda või kes vajab tuvastamine igapäevaelus eakaaslastest rohkem juhendamist, järelevalvet või abi. Puude raskusastet tuvastatakse nii lastel, tööealistel kui ka vanaduspensioniealistel. Puude Puude raskusastme tuvastamisel hinnatakse inimese toimetulekut raskusastme tervikuna ning kõrvalabi vajadust. Selle tulemusel tekib inimesel õigus tuvastamine puuetega inimeste sotsiaaltoetusele ja puudega isiku kaardile. ja Puuetega Teenus on mõeldud inimestele, kellel on tuvastatud puude raskusaste SKAIS2 sotsiaaltoetu inimeste ja kellel on erivajadusest tulenevaid lisakulutusi. Lisakulutused võivad s sotsiaaltoetus 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 Puudega isiku kaardi väljastamise teenus on isikutele, kellel on SKAIS2 kaart tuvastatud puude raskusaste. Puudega isiku kaart väljastatakse puude 5 raskusastme kehtivuse ajaks. Kaardiga on võimalik tõendada oma puude raskusastet. Isikustatud Pensioniindeksi arvestamise aluseks on 80 protsendi ulatuses eelmise SKAIS1 sotsiaalmaksu aasta sotsiaalmaksu pensionikindlustuse osa laekumise muutus ja 20 pensionikindlus protsendi ulatuses eelmise aasta tarbijahinnaindeksi muutus. Nende tuse osa muudatuste alusel arvutatakse indeks, mille kinnitab Vabariigi Valitsus. keskmise Indeksiga korrutatakse riiklike pensionite arvutamise aluseks olevaid suuruse näitajaid – pensioni baasosa, aastahinnet ja rahvapensioni määra. arvutamine ja Sotsiaalmak indekseerimine su-andmete Pensioniõigust EL institutsioonis töötanud ametnikul on õigus valida, kas kanda oma SKAIS1 töötlemine e ülekandmine välja teenitud pensioniõigused Euroopa ühenduste institutsioonide Eesti ja EL pensioniskeemi või Eesti Vabariigi pensioniskeemi. Pensioniõiguste institutsioonide ülekandmine võib toimuda nii Eesti pensioniskeemist Euroopa vahel ühenduste institutsioonide pensioniskeemi kui ka Euroopa ühenduste institutsioonidest Eesti pensioniskeemi. Teenusega toimub rahaliste vahendite ülekandmine inimese avalduse alusel. Inimesel on õigus pensioniõiguseid kanda ühe korra Euroopa ühenduste institutsioonide pensioniskeemist Eestisse ja vastupidi. Raamatupidam Toimuvad väljamaksed ja kohustuste, nõuete, tasaarvestuste ning SKAIS1/ is- kannete maksude finantsarvestusse kandmine (raamatupidamiskannete SKAIS2 Finants- tegemine ja tegemine). (EBS) arvestus ja väljamaksed väljamaksed Finantsarvestu Finantsarvestuses toimub kohustuste ja nõuete arvele võtmine ja SKAIS1/ s tehakse tasaarvestusi ning toimub maksustamisele kuuluvate summade SKAIS2 arvutamine. Puhkusetasu ja Teenus on mõeldud tööandjatele, kellele hüvitatakse esitatud andmete SKAIS1 töötasu alusel nende poolt tehtud kulutused seoses lisapuhkepäevadega: isale hüvitamine enne lapse sündi või pärast lapse sündi; puudega lapse vanemale; kuni 14-aastaste laste ühele vanemale; osalise või puuduva töövõimega inimese või alaealise töötaja põhipuhkus, sügava puudega täisealise inimese hooldajale; lapse rinnaga toitmise vaheaegade eest keskmise töötasu maksmisega Kuriteoohvri Teenus on mõeldud vägivallakuriteo tagajärjel kannatada saanud SKAIS1 riiklik hüvitis inimestele juhul, kui vägivallakuritegu on toime pandud Eesti riigi territooriumil. Kuriteoohvri 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. Tõendi A1 Tõendi A1 väljastamise teenus on mõeldud inimestele, kes viibivad SKAIS1 väljastamine lähetuses välisriigis või töötavad mitmes riigis. Nii töötaja, tööandja kui ka ametnik võivad vastava sooviavalduse esitada. Tõendiga määratakse kindlaks inimese kindlustajariik. Tõendi väljastab riik, mille sotsiaalkindlustuse õigusakte kohaldatakse ja sellega tõendab lähetuses viibiv või mitmes riigis töötav inimene vastu võtva riigi ametkonnale, et tema suhtes ei kohaldata ühegi teise tema tööga seotud riigi sotsiaalkindlustuse õigusakte. Riigipoolne Riigipoolne sotsiaalmaksu tasumise teenus on mõeldud inimestele, SKAIS1 sotsiaalmaksu kelle eest tööandja ei tasu sotsiaalmaksu ning kellel puudub hüvitamine ravikindlustus, kuid kes kasvatavad Eestis väikeseid lapsi või kellel on õigus saada 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öörduja toetust või riiklikku pensioni. Tegemist on mitterahalise hüvitisega, mida SKA maksab teatud hüvitiste saamisel inimese eest automaatselt või inimese nõusolekul, kui nõutavad tingimused on täidetud. 6 Kahjuhüvitis Teenus on mõeldud inimestele, kellel on tööõnnetuse või kutsehaiguse SKAIS1 tagajärjel tekkinud tervisekahjustus 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 inimestele, kellel on tuvastatud kutsehaigus või tööõnnetuse puhul tekkinud tervisekahjustus või surma korral toitja ülalpeetavatele. Tegemist on nii ühekordsete rahaliste hüvitistega kui ka perioodiliste maksetega, mida makstakse igakuiselt. Õppelaenu Teenus on mõeldud lapsevanematele, kes kasvatavad kuni 5-aastast SKAIS1 osaline last ning kellel on õppelaen. SKA kustutab kvartaalsete maksetena kustutamine krediidiasutusele ühe lapsevanema õppelaenu, mille kohta on tehtud õppelaenu kustutamise otsus. Teenust rakendatakse kuni 2022. aastani. Õppelaenu Õppelaenu Õppelaenu kustutamise teenus on mõeldud õppelaenu saajale, kellel täna pole kustutamine kustutamine on tuvastatud puuduv töövõime või kelle 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. Sotsiaaltoetus Teenus on mõeldud välisriigist Eestisse elama asunud Eesti kodanikule SKAIS1 Eestisse või eesti rahvusest inimesele ja temaga koos Eestisse elama asunud tagasipöördujal abikaasale, lapsele või vanematele, kes on jõudnud vanaduspensioni e 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. Olümpiavõitja Teenus on mõeldud Eesti kodanikule, kes on tulnud olümpiamängudel SKAIS1 toetus või paraolümpiamängudel olümpiavõitjaks. Olümpiavõitja toetus määratakse kas vanuse alusel kümme aastat enne vanaduspensioniea 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. Represseeritu Teenus on mõeldud okupatsioonirežiimide poolt represseeritud SKAIS1 toetus ja inimestele. Represseeritule või represseerituga võrdsustatud inimesele tunnistus väljastatakse represseeritu tunnistus, millega saab tõendada õigust represseeritud inimestele ettenä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. Sotsiaaltoetus Teenus on mõeldud nendele inimestele, kes saadeti Eestist SKAIS1 Tšernobõli AEJ sunniviisiliselt likvideerima Tšernobõli tuumakatastroofi avarii tagajärgi. avarii Toetust saavad ka need, kes elasid enne Tšernobõli katastroofi Eestis, likvideerijale kuid asusid elama mõnda teise riiki, kust ta saadeti avarii tagajärgi likvideerima ja kes tulid tagasi Eestisse ning elavad Eestis. Toetus makstakse välja üks kord kalendriaastas. Ohvriabi ja Teenus on mõeldud inimestele, kes on langenud kuriteo ohvriks või on SKAIS1 lepitusteenus kogenud vägivalda, hoolimatust või halba kohtlemist. Teenuse raames hüvitatakse ohvri ja tema pereliikme psühholoogilise abi kulud, viiakse läbi lepitusteenust II astme kuritegude puhul, tagatakse täiendavad teenused inimkaubanduse ohvritele, seksuaalselt väärkoheldud alaealistele ja saatjata alaealistele välismaalastele. SKA hüvitab kulutused inimesele osutatud teenuste eest teenuseosutajale esitatud arvete alusel. 7 Parkimiskaardi Vastavalt liiklusseadusele on teenus mõeldud püsiva või ajutise täna pole d liikumis- või nägemisfunktsiooni kõrvalekaldega inimese sõiduki või teda teenindava sõiduki parkimiseks. Parkimisõiguse kasutamiseks väljastatakse täna parkimiskaart kohalikus omavalitsuses. Vajalik on luua andmeregister, mille alusel saab üle Eesti kontrollida parkimiskaartide kehtivust ja õigustatust ning seeläbi vähendada väärkasutust. 2.2. Teenuste kirjeldus ja arendussoovid 1) 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õimalik 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 vanaduspensioniealine inimene, 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. Käimasolevate arenduste raames asendub paberkandjal abivahendi kaart, elektroonse abivahendi kaardiga alates 2020 II poolest. Nende kõigi teenuste puhul ei toimu rahaliste hüvitiste väljamaksmist inimesele, vaid SKA võtab inimese eest üle tasu maksmise kohustuse ehk inimene saab teenust või abivahendi ning arve teenuse või abivahendi saamise eest tasub SKA teenuseosutajale, kellega on SKA-l sõlmitud tähtajalised halduslepingud. Erandiks on sotsiaalse rehabilitatsiooniteenuse alamteenusena olev sõidu- ja majutuskulude hüvitamine inimesele seoses sotsiaalse rehabilitatsiooniteenuse saamisega. Iseteenindusse tuleb luua vaade, kus inimene näeb enda kohta ja talle osutavate teenuste kohta käivat infot. 2) 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, Valgevene, Kanada, Moldova, Ukraina ja Austraalia). Täna on olemas üle 110 erineva pensioni liigi, mille määramiseks peab tegema pöördumise inimene ise või esitab andmed kokkulepitud vormil pädev asutus. Pensionid saame grupeerida kolme suurde rühma: 1) pensionid, mis koosnevad kolmest osast (baasosa, staažiosa, kindlustusosa); 2) pensionid, kus arvutatakse protsent inimese valitud ametipalgast; 3) välisriigi pensionid. Pensioni kolm osa on: 1) baasosa, mis on kindlaks määratud suurus; 8 2) staažiosa, mis arvutatakse kliendipõhiselt ning päeva täpsusega kuni 31.12.1998.a perioodide eest, mil inimene töötas, õppis või oli armees; 3) kindlustusosa, mis arvutatakse kliendipõhiselt makstud sotsiaalmaksu andmete alusel alates 01.01.1999. SKAIS1 võimaldab 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. Infosüsteemides olevate andmete alusel ning etteantud reeglite põhjal peab SKAIS2 hakkama tegema ka proaktiivseid pakkumisi vanaduspensioni ea saabudes. Infosüsteemis olevate andmete alusel arvutatakse välja eelduslik pension ning inimesel peab olema võimalus kinnitada pakkumus, lisada andmeid või lükata esitatud pakkumus tagasi. Iseteeninduses peab inimesel olema võimalik näha talle määratud pensioni suurust ja alusandmeid. SKAIS2 tuleb üle viia SKAIS1 olevad penisoni määramiseks vajalikud andmed. Pensioni menetluses koostatud otsused peavad olema digitembeldatud ning salvestatud süsteemi. 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. Tuleb luua iseteeninduse vaade, kust inimesel on võimalik kontrollida, kas ta vastab hüvitise saamise tingimustele. Pensioni määramiseks vajaliku info kogumise teenus on mõeldud inimestele, kes ei ole veel vanaduspensionieas. Pensioni määramiseks vajaliku info kogumine on inimese töötamise, õppimise, armees teenimise või laste kasvatamise eest pensioni määramiseks vajalike andmete sisestamine infosüsteemi. Andmed jõuavad infosüsteemi teiste registrite või inimese poolt esitatud dokumentide kaudu. 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 SKA-le hoiule või inimesele tagastatud. SKAIS2-e jaoks on vajalikud pensioni määramiseks vajaliku info kogumise teenuse jätkuarendused. 3) Perehüvitised Perehüvitiste teenus on seotud riigipoolse sotsiaalmaksu hüvitamise teenusega, puhkusetasu ja töötasu hüvitamise teenusega ja puudega lapse toetusega. Praegu toimub perehüvitiste arvestamine SKAIS1 ja SKAIS2, arendustööd kõigi perehüvitiste teenuste SKAIS2 üleviimiseks käivad. Perehüvitised koosnevad: • peretoetused, mis on konkreetsed suurusega ning mis on määratud seadusega; • vanemahüvitis, mis sõltub saaja sotsiaalmaksuga maksustatud tulude suurusest; • kohustusliku kogumispensioni sissemaksest, mis on 4% Eesti keskmisest sotsiaalmaksuga maksustatavast ühe kalendrikuu tulust. Lapse sünniga seotud perehüvitisi pakutakse vanematele proaktiivse teenusena. Kinnitamist vajav pakutav toetus on nähtav ametnikule mõeldud kasutajaliideses (= ametnikuportaalis) , lapse mõlemale vanemale iseteeninduses ning info võimaliku toetuse kohta saadetakse mõlema vanema e-postile. SKAIS2 võimaldab pakkuda perehüvitisi nn komplekstoetusena, st ühe kinnitusega saab vanem vastu võtta peretoetust, vanemahüvitist ja kohustusliku pensioni sissemakseid. Süsteem moodustab teenuste lõikes otsused, kuid inimesele edastatakse kompleks teavitus, mis hõlmab kõiki perehüvitiste otsuseid. Kõiki teenuseid, mida on võimalik koheselt automaatselt menetleda, menetletakse automaatselt. Kui mingi teenus ei vasta automaatmenetluse tingimustele, siis 9 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 vanema poolse pöördumiseta või suunata menetlejale otsuse tegemiseks manuaalmenetlusse. Perehüvitistest ligikaudu 10% moodustavad perehüvitised, mille määramisel ning maksmisel tuleb kohaldada EL-i õigusakte. 4) 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 saada nii kohtumenetluse alustamise korral kui ka täitemenetluse ajal. Kohtumenetlusaegse 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 kohtuotsust 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 (SKA) poole. Väljamakstud hüvitise nõuab SKA tagasi vanemalt, kellelt on kohtuotsusega mõistetud välja elatis. Täitemenetlusaegse 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.. 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 ametnikuportaalis. Elatisabi taotlust saab täna esitada riigiportaalis (eesti.ee). Käesoleva teenuse puhul tuleb SKAIS2-te luua iseteenindus. 5) 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 inimese toimetulekut tervikuna ning kõrvalabi vajadust. Selle tulemusel tekib inimesel õ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 inimestele, kellel on tuvastatud puude raskusaste. Puudega isiku kaart väljastatakse inimesele puude raskusastme kehtivuse ajaks, tõendamaks puude raskusastet. Puudega isiku kaardi trükib ja väljastab inimesele SKA. Infosüsteemis säilitatakse kaardi väljastamise andmed. Puude raskusastme tuvastamine ja sotsiaaltoetuse teenus on SKAIS2 ametnikuportaalis. Käesoleva teenuse puhul tuleb SKAIS2-te luua iseteenindus. 10 6) 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. 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 inimese soovil kanda üle kas Eestist EL institutsioonide pensioniskeemi või vastupidi, kumbagi valikut on inimesel õigus kasutada ühe korra. Pensioniõiguste kandmiseks Eesti pensioniskeemist EL institutsioonide pensioniskeemi teeb SKA kalkulatsiooni inimese Eestis omandatud pensioniõigustele vastavate rahaliste vahendite suuruse kohta. Rahaliste vahendite suurus arvutatakse vastavalt pensionistaažile. Inimese Eestis omandatud pensioniõiguste rahalised vahendid kantakse EL Institutsioonidele üle, millest teavitatakse ka EMTA-t ning kui inimene on liitunud II sambaga siis ka Pensionikeskust. Pensioniõiguste kandmisel EL institutsioonide pensioniskeemist Eesti pensioniskeemi, kantakse EL Institutsioonist pensioniõigustele vastavad rahalised vahendid Eesti pensioniskeemi koos täiendavate dokumentidega. 7) Finantsarvestus ja väljamaksed SKA poolt osutatavaid avalikke teenuseid toetavad nii SKAIS1 kui SKAIS2, viimase lahutamatuks osaks on finantsinfosüsteem EBS. Hüvitist makstakse vastavalt inimese soovile kas pangaarvele või kojukandeteenusena, mida hangitakse riigihankena. Lisaks toimuvad välislepingute alusel väljamaksed välisriigi pangaarvetele nii kliendipõhiselt kui ka teostatakse väljamakseid välisriigi pädevatele asutustele, edastades õigustatud inimeste nimekirjad. Menetlus- ja finantstehingud peavad olema täielikult omavahel integreeritud. SKAIS2-e finantsmoodulis võetakse arvele kõik nõuded ja kohustused, teostatakse vajalikud kinnipidamised ning tulumaksuarvestus. SKA-s on praegu kolm teenust, mis kuuluvad tulumaksuga maksustamisele (pension, kahjuhüvitis ja vanemahüvitis). Finantsarvestus peab võimaldama tulu- ja sotsisaalmaksu deklaratsioonide täitmist ja edastamist. Maksudeklaratsioonid (ESD ja TSD) tuleb Maksu- ja Tolliametile esitada hiljemalt väljamakse kuule järgneva kuu 10. kuupäevaks. ESD ehk sotsiaalmaksu deklaratsioonide moodustamine 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. Väljamakseid teostatakse EBS-i kaudu kasutades AS Swedbanki pangakanalit „Gateway“ ja AS SEB Pank Baltic Gateway. Kolmandatesse pankadesse toimub väljamaksmine AS Swedbanki või AS SEB kaudu. Väljamaksete õnnestumise kohta saabuv info liigub pangast tagasi EBS-i 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. 8) 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äevade andmisega puudega 11 lapse vanemale; kuni 14-aastaste laste ühele vanemale; osalise või puuduva töövõimega inimese või alaealise töötaja põhipuhkuse saajale, sügava puudega täisealise inimese hooldajale; lapse rinnaga toitmise vaheaegade eest keskmise töötasu maksmisel. Õigustatud inimeste ringi kuuluvad ka vabade elukutsete esindajad (nt notarid, kohtutäiturid), kes ei ole äriregistris. Vabade elukutsete esindajad kasutavad isikukoodi registri numbri asemel. Andmed kohtutäiturite ja notarite kohta on eraldi registris. Seega peab SKAIS2 suutma eristada isikuandmeid eelpool nimetatud isikute puhul, kas inimene kasutab teenust füüsilise isiku rollis või juriidilise isiku rollis. Praegu on teenus kasutusel SKAIS1-s ning riigiportaalis (eesti.ee). 9) Kuriteoohvri riiklik hüvitis Teenus on mõeldud täna vägivallakuriteo tagajärjel kannatada saanud inimestele. Kuriteoohvri hüvitis koosneb ravikuludest, perioodilisest hüvitisest ja matusekuludest. Varaline kahju hüvitatakse kuni 80% ulatuses, kuid mitte üle 9590 euro. Uus teenus peab võimaldama kuriteoohvri riikliku hüvitise maksmisel perioodilisi makseid ning ühekordsete maksetena ravikulude ja matusekulude hüvitamist. Inimese 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 kulutust 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 peavad olema kuriteoohvri riiklikud hüvitised seotud regresside menetlusega. 10) Tõendi A1 väljastamine Tõendi A1 väljastamise teenus on mõeldud inimestele, kes viibivad välisriigis lähetuses või töötavad mitmes riigis. Nii töötaja, tööandja kui ka ametnik võivad vastava sooviavalduse esitada. Tõendiga A1 määratakse kindlaks inimese kindlustajariik ja selle väljastab riik, mille sotsiaalkindlustuse õigusakte kohaldatakse. Tõendiga A1 tõendab välisriigis lähetuses viibiv või mitmes riigis töötav inimene 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 EL-is töötajate ja füüsilisest isikust ettevõtjate suhtes selle liikmesriigi sotsiaalkindlustuse õ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 inimene 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 inimese kindlustajariik ning vältida olukorda, kus inimene on sotsiaalselt kindlustatud mitmes riigis samaaegselt või vastupidi – pole kindlustatud üheski riigis. Täna on taotlust võimalik esitada riigiportaali (eesti.ee) kaudu ja see laekub otse SKAIS1 (A1 moodul) infosüsteemi, kus menetlemine toimub manuaalselt. Uus teenus peab olema loodud tõendi A1 sooviavalduse esitamiseks ja vajadusel väljatrüki teostamiseks võimalus ka 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 vajadusel väljatrükki. Tuleb luua võimalus, kus online’is on võimalik ilma autentimata kontrollida konkreetse tõendi kehtivust sisestades üksnes tõendi numbri. 11) Riigipoolne sotsiaalmaksu tasumine Riigipoolne sotsiaalmaksu tasumise teenus on mõeldud inimestele, kelle eest tööandja ei tasu sotsiaalmaksu ning kellel puudub ravikindlustus, kuid kes kasvatavad Eestis väikeseid lapsi või kellel on õigus saada 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öörduja toetust või riiklikku pensioni. 12 SKA tasub inimese eest sotsiaalmaksu, mille tulemusena tekib inimesel ravikindlustus. Täna hallatakse seda teenust SKAIS1-s. Riigipoolse sotsiaalmaksu hüvitamise teenuses peab olema võimalik alustada menetlust ka kliendi poolse pöördumisega. Tegemist on üldjuhul siiski automaatmenetlusega. Täna on teenus SKAIS1-s 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. 12) Kahjuhüvitis Teenus on mõeldud inimestele, kellel on tekkinud tervisekahjustus tööõnnetuse või kutsehaiguse tagajärjel ning tööandja on likvideeritud ja puudub õigusjärglane. Kahjuhüvitis on otsese varalise kahju või saamata jäänud tulu hüvitamine inimeneutele, 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 kindlakstegemiseks on vajalik SKA ekspertarsti hinnang ning pensioni või töövõimetoetuse suurus. Infosüsteem peab võimaldama ekspertarstihinnangu sisestamist ning arvestama vajadusel pensioni või töövõimetoetuse suurusega. Kahjuhüvitise perioodilise hüvitise suurus arvutatakse menetleja poolt käsitsi, seega peab olema võimalik sisestada menetleja poolt välja arvutatud summat ning alusandmeid. Kahjuhüvitise suurus võib olla kindlaks määratud ka kohtuotsusega. Vajalik on ka funktsionaalsus, mis lubab süsteemi sisestada lisakulutusi tõendavaid dokumente ja teha nende alusel ühekordseid väljamakseid. 13) Õppelaenu kustutamine Õppelaenu osalise 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. 14) Muud hüvitised Toetuste ja hüvitiste, mille sihtrühm on suhteliselt väike, haldamine toimub läbi universaalmenetluse, mis peab vastama erinevate väljamaksete ärinõuetele.  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 vanaduspensioniealised ning kelle igakuine sissetulek 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.  Olümpiavõitja toetus Teenus on mõeldud inimestele, kes on tulnud olümpiamängudel või paraolümpiamängudel olümpiavõitjaks. Olümpiavõtja toetus määratakse kas vanuse alusel kümme aastat enne vanaduspensioniea 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. Toetuse suurus on Statistikaameti avaldatud eelmise kalendriaasta kolmanda kvartali keskmine brutokuupalk. Toetuse uus suurus ei või olla väiksem eelmise aasta toetuse suurusest.  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 ettenähtud 13 soodustustele. Inimesele, kellele on väljastatud represseeritu tunnistus, tekib õigus represseeritu hüvitisele, mis on rahaline hüvitis, mida makstakse represseeritule üks kord aastas.  Sotsiaaltoetus Tšernobõli AEJ avarii likvideerijale Teenus on mõeldud nendele inimestele, kes saadeti Eestist sunniviisiliselt likvideerima Tšernobõli tuumakatastroofi avarii tagajärgi. Toetust saavad ka need, kes elasid enne Tšernobõli katastroofi Eestis, kuid asusid elama mõnda teise riiki, kust ta saadeti avarii tagajärgi likvideerima ja kes tulid tagasi Eestisse ning elavad Eestis. 15) Parkimiskaardid Vastavalt liiklusseadusele on teenus mõeldud püsiva või ajutise liikumis- või nägemisfunktsiooni kõrvalekaldega inimese sõiduki või teda teenindava sõiduki parkimiseks. Parkimisõiguse kasutamiseks väljastatakse täna parkimiskaart kohalikus omavalitsuses. Täna peab inimene kohalikule omavalitsusele esitama SKA puude raskusastme tuvastamise otsuse või ajutise liikumis- või nägemisfunktsiooni kõrvalekalde puhul pere- või eriarsti teatise, mille alusel parkimiskaart väljastatakse. Parkimiskaart väljastatakse kuni puude kehtivusajaks, kuid mitte kauemaks kui 5 aastaks. Ajutise liikumis- või nägemisfunktsiooni kõrvalekalde puhul kuni 6 kuuks. Parkimiskaartide väljastamise üle peab arvestust selle väljastanud kohalik omavalitsus. Üldine register puudub. Vajalik on luua e-teenus, mille alusel saab üle-Eesti kontrollida parkimiskaartide kehtivust ja õigustatust ning seeläbi vähendada väärkasutust. Parkimisõiguse ja/või kaardi kehtivuse kontrollimiseks peab olema lahendus, mis võimaldab ilma autentimata online kontrolli, sisestades kas kaardi numbri või auto registreerimisnumbri. 2.3. SKAIS alamsüsteemide toimimine Täna kasutusel olev SKAIS koosneb tehniliselt neljast infosüsteemist, milleks on SKAIS1, SKAIS2, EBS ja AVE. Nii SKAIS1 kui SKAIS2 toimub hüvitiste ja toetuste menetlemine ning väljamaksmine. SKAIS1 on ainult ametkondlikuks kasutamiseks ehk ametnikuportaalina. SKAIS2 on kasutusel nii ametnikuportaalina kui ka iseteenindusena. SKA iseteeninduse on hetkel peretoetuste teenus ja arendamisel on abivahendite teenus. Iseteeninduses saab inimene enda jaoks vajalikke toiminguid teha lihtsalt ja kiirelt, hoides sellega kokku nii enda kui ametkonna ressurssi. Enamus kasutajaliidese lahendusi on nii iseteeninduses kui ka ametnikurakenduses sarnased või samased. Üldprintsiibina peavad SKA e-teenused olema proaktiivsed, st kui infosüsteemis on vajalikud andmed olemas ning vastavalt kehtivatele ärireeglitele on inimesel sellele teenusele õigustatus, siis teavitatakse inimest personaalse võimaliku toetuse või teenuse olemasolust. SKA kliendil on iseteeninduse kaudu võimalik saada operatiivselt infot talle võimaldatud teenustest, pakutavatest teenustest (proaktiivsete teenuste info), vajadusel esitada oma pöördumisi, jälgida teenuste menetlusprotsessi, saada teated ja teavitusi teenuste/toetuste saamise või lõppemiste kohta. SKA teenustes ristkasutatakse andmeid, mistõttu on vajalik teenuste üleviimisel arvestada erisustega, kui teenuses kasutatavad andmed asuvad erinevates infosüsteemides. Lisaks on SKA-l kohustus hüvitisi määrata, teha neist ümberarvutusi ja maksta hüvitisi tagasiulatuvalt, 14 mistõttu on nii varasemate ärireeglite kasutamise vajadus kui ka varasemate andmete migreerimise vajadus. SKA teostab igakuiselt enam kui 700 000 makset, mis moodustavad kokku üle 200 mln euro väljamakseteks igas kuus. Väljamakseid teostatakse nii SKAIS1-st kui ka SKAIS2-st (viimase puhul majandustarkvara EBS kaudu). SKA kasutab järgmisi EBS-i mooduleid:  Oracle General Ledger ehk Pearaamat  Oracle Accounts Payables ehk Ostureskontro  Oracle Accounts Receivables ehk Müügireskontro  Oracle Cash Management ehk Pangamoodul Käesoleva hanke raames ei hangita SKAIS1, AVE ega EBS mooduli arendusi ega hooldust. 2.4. SKAIS teenuste kasutajagrupid 1) Kasutajaliides teenuste kasutajatele ehk iseteenindus Iseteeninduse kasutajad on füüsilised või juriidilised isikud. Iseteeninduses peavad kasutajale olema kättesaadavad kõik talle pakutavad ja osutatavad teenused, samuti peab olema näha teenuste menetluste seis ning ajalugu. Iseteenindus peab vastama ligipääsetavuse direktiivi nõuetele (vt FE nõuded). . Iseteeninduskeskkonnas pakutavad teenused on kolmekeelsed eesti-, vene ja inglisekeelne. Iseteeninduses peavad olema nähtavad vähemalt: • isikuandmed; • inimesele pakutavad ja osutatavad teenused ja teenuste ajalugu; • inimesele riigi poolt pakutavad toetused (tema andmete põhjal teave teenustest, millele on tal õigus); • hüvitiste väljamaksete info; • teavitused uute reeglite, tähtaegade saabumise või vajalike toimingute tegemise kohta. 2) Kasutajaliides ametnikule ehk ametnikuportaal Ametnikuportaalis SKAIS2-s on juba täna loodud isiku põhine vaade (SKAIS1-s on teenuste- põhine vaade). Ametnikuportaalis peab saama teha kõiki toiminguid, mida saab teha isik iseteeninduses või teenuseosutaja läbi teenuseosutaja funktsionaalsuse. Lisaks peab olema loodud võimalus laadida üles dokumente. Sisestatud dokumendid ja süsteemis loodud dokumendid peavad olema nähtavad ametnikuportaali kasutajale ning kokkulepitud ulatuses ka iseteeninduses. Inimese vaates peab olema tagatud: • juba sisestatud andmed peavad olema järgmiste menetlusetappide menetlejatele 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; • rahalised vaated, sh ajaloolised andmed. 15 2.5. SKAIS arendustööde teostamise üldised ärilised nõuded Arendustööde teostamisel tuleb arvestada järgmiste üldiste nõuetega: 1) SKAIS2-s peab olema kliendipõhine vaade ja võimalik alusandmete ristkasutus; 2) peab olema võimalik erinevate kanalite kaudu saabunud pöördumiste vastuvõtmine, registreerimine ning vajadusel täiendavate dokumentide lisamine; 3) peab olema võimalik kokkulepitud reeglitel automaatmenetluse käivitamine, mille tulemusel koostatakse inimesele kinnitamiseks riigile teadaolev võimalik toetus või inimesele määratud otsus; 4) SKAIS2 peab kontrollima regulaarselt hüvitise/teenuse määramise tunnuste komplekti inimese kohta, arvestama teistest andmekogudest saabunud andmeuuendusi ning käivitama automaatselt vajalikud tegevused; 5) manuaalmenetlusse suunamine toimub juhul, kui süsteem ei saa automaatmenetlust läbi viima; 6) tööülesannete suunamine menetlejatele peab toimuma automaatselt ja/või manuaalselt, vastavalt kokkulepitud reeglitele; 7) süsteem lisab tähtajad ja jälgib nende saabumist kokkulepitud reeglite alusel ning saadab teavitusi nii ametnikuportaalis kui ka iseteeninduses; 8) peab olema võimalik ärireeglite haldamine, mis võimaldab hüvitisi määrata ja ümber arvutada tagasiulatuvalt kehtinud ärireeglite alusel. 3. Hangitav skoop Hangitavaks skoobiks on kaasaegsete e-teenuste arendamine SKAIS2-s, sh:  ärinõuete analüüs ja kaardistamine;  arendus- ja juurutustööd koos (automaat)testimistega ning seotud komponentide ühise töökindluse tagamine;  andmemigratsioon;  X-tee liideste arendus infosüsteemide vahel (vt. lisa „Arhitektuuri ülevaade“);  muud töid, mis on vajalikud arendustöö tõrgeteta toimimise tagamiseks. 4. Tööde tellimise põhimõtted 1. Tööde teostamiseks sõlmitakse hankelepingud. 2. Pakkuja ülesandeks on olla valmis: 1) teostama SKAIS2 arendustöid funktsionaalsuse põhiselt, kus sisendiks on konkreetse tulemi (skoobi) tellimus, sh tähtaeg ja/või piirsumma; 2) teostama SKAIS2 arendustöid arendusmeeskonna töötundide põhiselt, kus arendused realiseeritakse agiilse arendusprotsessi põhimõtetel; 3) andma arendustega seotud konsultatsioone ja koolitusi. 16 5. SKAIS2 arenduste indikatiivne teekaart Märkus:  Arendustööde ajaplaan on koostatud tänase parima teadmise põhjal ja on indikatiivne. Tellija ei garanteeri teekaardil toodud tööde tellimist viidatud ajaperioodidel. 17 Sotsiaalkaitse infosüsteem Lähtekoodi haldus Raamlepingu lisa 6 1 Üldine kirjeldus Lähtekoodi hallatakse GIT tarkvaraga. Tsentraalne tarkvara lähtekoodi hoidla (Gitlab) asub TEHIKus, kuhu on koondatud kõik repositooriumid. a. Iga tarkvara arendaja võib teha enda lähtekoodi hoidlasse koopiaid TEHIKu hoidlast, kuid iga tööülesande (JIRA story/task) valmides peavad muudatused jõudma TEHIKu lähtekoodi hoidlasse. b. Tarkvara continuous integration keskkond on TEHIKu Gitlab keskkond ja selle töövood. c. Tarkvara paigalduspakettide kokku ehitamine testi, prelive ja Live keskkondade jaoks toimub TEHIKu lähtekoodi hoidlast. d. Käesoleva reeglistiku järgimine on kohustuslik kõigile infosüsteemide arendajatele ja arendustööde tellijale. e. Tellija peab enne uue mestitava arenduse testima ja arendajale veahaldussüsteemis kinnitama, et arendatav kood töötab korrektselt. 2 Lähtekoodi versiooni harude haldus 2.1 Peamised harud TEHIKu lähtekoodi hoidlas on kohustuslike harudena olemas:  Master  Release  Develop Lähtekoodi harus origin/master hoitakse Live keskkonnas oleva tarkvara lähtekoodi seisu. Lähtekoodi harus origin/release hoitakse järgmise toodangu uuenduse oleva tarkvara lähtekoodi seisu. Release haru on vajalik nende süsteemi osade puhul, kus TEHIK ja/või SKA teostab eraldi vastuvõtutestimist ja sellel perioodil arendatakse juba järgmise tarne töid ning võib tekkida vajadusi hotfixide järgi. Lähtekoodi harus origin/develop hoitakse test keskkonnas oleva tarkvara lähtekoodi seisu. Develop harust võtab alati järgmine arendaja viimase lähtekoodi edaspidiste andmete sünkroniseerimiseks. Kui lähtekood on saavutanud stabiilse seisu, teeb tellija arendajale ettepaneku paigaldada lähtekood Live keskkonda. Lähtekood paigaldatakse Live keskkonda pärast seda, kui arendustöö on arendaja poolt tellijale aktiga üle antud. Kõik Develop harus olevad muudatused tuleb mestida Master harusse ja sildistada vastava tarkvara versiooni numbriga. 2.2 Toetavad harud Iga uue arenduse algul loob arendaja ühe alljärgnevatest lähtekoodi harudest:  Feature  Release  Hotfix 2.2.1 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. 2.2.2 Release haru Väljavõte tehakse: Develop Mestimine tehakse: Develop ja Master Haru nime kuju: release Peale arenduse edukat testimist teeb tellija ettepaneku tarnida arendustöö release harusse. Release haru 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. Pärast tööde lõppu Release harus, peab Develop harus olema kogu vajalik lähtekood järgmisteks suuremateks arendusteks. Release harust võtab arendaja vajaliku lähtekoodi peaharusse tarnimiseks (master). Lähtekoodi on kohustatud arendaja peaharusse panema hiljemalt järgmise tööpäeva lõpuks. 2.2.3 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/ Sotsiaalkaitse valdkonna teenuste arendustööd Kodukord Raamlepingu lisa 8 1. EESMÄRK 1.1. Kodukorra eesmärgiks on täpsustada hankelepingute alusel (edaspidi nimetatud ka projekt) tööde tellimise kord ja põhimõtted, täitja ja tellija omavaheline suhtlus ning tagasiside andmise kord. 1.2. Tellija võib teha kodukorda muudatusi, teavitades täitjat kodukorra muutmisest. 2. MÕISTED 2.1. Töö – Lepingus (hankeleping) fikseeritud töö(d)/tegevus(ed) ja üle antav(ad) tulem(id), mida saab testida või mille valmimist saab kinnitada tellija. 2.2. Ü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. 2.3. Teenuse kasutaja/äritellija – Sotsiaalkindlustusamet, kes hakkab tööna tellitud teenuseid kasutama, sh testib üle antud töid sisuliselt. 2.4. MVP (Minimum Viable Product) – minimaalne töötav toode/teenus. Tegemist on toote/teenuse (või selle alamosa) esmaversiooniga, mida klient saab kasutada ning mis lahendab esmased vajadused. MVP etapis kasutatakse tehniliselt lihtsaid lahendusi ning jäetakse kõrvale sekundaarse prioriteediga ärinõuded ja sihtgrupid. 2.5. Arendustööd – programmeerimine koos selle juurde kuuluvate tugitegevustega. 3. TÖÖKORRALDUS TÖÖDE TEOSTAMISEL 3.1. Täitja peab olema võimeline arendustöid teostama MVP (punkt 2.4) põhimõtetest lähtudes: 3.1.1. Pakkumuskutses on fikseeritud loodava funktsionaalsuse loetelu (skoop) ärinõuetena ilma konkreetsete lahenduskäikudeta. Täitja ülesandeks on tellija poolt seatud ajalistes ja eelarvelistes piirides leida koostöös tellijaga igale ärinõudele antud tingimustes parim võimalik (mõistlik) lahendus. Parima võimaliku lahenduse all peab tellija siinkohal silmas arendustööde lõppmaksumuse proportsionaalsust lahendatava probleemi keerukusega. 3.2. Täitja tagab tööde teostamise ajal igakülgse läbipaistvuse vastavalt tellija nõuetele (sh otsekontakt ja vajadusel igapäevane suhtlus kõikide täitja meeskonna liikmetega): 3.2.1. Arendustööde (punkt 2.5) teostamine on jagatud etappideks (mitte pikemateks kui kaks nädalat); 3.2.2. Iga etapi järel esitleb täitja saavutatud tulemeid tellijale (viib läbi demo); 3.2.3. Arendustööd on hiljemalt etapi planeerimise hetkeks jagatud ühtlase detailsusega väiksemateks osadeks (iga töö maht maksimaalselt 24 tundi). Kui vajadus töö jagamiseks väiksemateks osadeks tekib töö käigus, siis tuleb seda teha koheselt; 3.2.4. Iga etapi järel esitab täitja ülevaate planeeritud arendustööde mahust ja tegelikult teostatud tööde mahust (nn „põlemisgraafik“, Burndown chart) koos selgituste ja tulemuslikkuse suurendamise kavaga. 1 3.3. Tööde teostamine ei tohi tekitada häireid tellija mistahes teiste liidestatud süsteemide või teenuste talitluses, v.a juhul kui see on tellija ja täitja vahel eelnevalt kokku lepitud. 3.4. Juhul, kui töö teostamine toimub tellija ruumides, peavad tellija ruumides viibivad täitja esindajad kinni pidama tellija juures kehtivatest sisekorraeeskirjadest, sh turvanõuetest, mis on tellija poolt teatavaks tehtud. 3.5. Lepingu täitmisest tulenev suhtlus toimub eesti keeles, täitja peab tagama võimekuse tööde teostajatega eesti keeles infot vahetada (vajadusel korraldab nt tõlke täitja). 4. TÖÖDE ÜLEANDMINE 4.1. Arendustööde tulemite üleandmise eelselt viib täitja läbi süsteemitestimise (System Test). Nõuded süsteemitestimisele (sh automaattestimisele) kehtestab tellija (üldise korrana, vajadusel konkreetse lepingu raames). 4.1.1. Süsteemitestimise tulemusena peab lähtekood olema vigadeta, st kõlbulik toodangukeskkonda paigaldamiseks. 4.2. Arendustööde tulemite üleandmine (lähtekoodi tarne) toimub pideva integreerimise (Continuous Integration) teel või kokkulepitud sagedusega (nt iga arendustööde etapi järel). 4.2.1. Täitja teab, et tellija võib igat üle antud funktsionaalsust paigaldada toodangusse ning täitja peab tagama, et lõplikult valmimata funktsiooni protsessid on võimalik toodangust välja lülitada (feature flags). 4.3. Täitja korraldab tulemite üleandmise järel vajalikud lähtekoodi paigaldused keskkondadesse, kus tellija viib läbi vastuvõtutestimise (Acceptance Test, User Acceptance Test). 5. TÖÖDE TEOSTAMISE MEESKOND JA VASTUTUSED 5.1. Tööde teostamiseks moodustatakse projektimeeskond. 5.2. Tellija (so Tervise ja Heaolu Infosüsteemide Keskuse) poolt osalevad tööde tellimisel ja teostamisel järgmised rollid: 5.2.1. Tellija projektijuht - juhib 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. 5.2.2. Tooteomanik (Product Owner) – esindab äritellijat igapäevatöös, sh korraldab ja viib läbi kokkulepitud ärinõuete defineerimise ja prioriseerimise, juhib projekti skoopi (ulatust). 5.2.3. Süsteemiarhitekt – juhib tervikliku süsteemiarhitektuuri planeerimist, vastavuse kontrollimist esitatud nõuetele ja projektis defineeritud ärivajadustele. Korraldab tehniliste otsuste vastuvõtmist ja jõustamist seotud osapoolte (sh erinevate arenduspartnerite) vahel. 5.2.4. Kvaliteedijuht – kehtestab kvaliteedi tagamise ja kvaliteedikontrolli põhimõtted ning kontrollib nende täitmist (tööde teostamise käigus ja selle järgselt). Juhib vastuvõtutestimise läbiviimist. 5.2.5. Teenusehaldur – kooskõlastab paigaldused toodangukeskkonda. 2 5.3. Sõltuvalt tellitavate tööde iseloomust võib Tellija enda poolt tööde tellimisel ja teostamisel osalevate rollide nimekirja muuta (sh täiendada). 5.4. Täitja poolne projektijuht ei ole kohustuslik, piisab kui on meeskonnas olemas üks meeskonna juhtimise kogemusega inimene, kes juhib täitja poolt tööde tulemi kokkuleppimist, tööde teostamise ajaplaani koostamist ning tagab kokkulepitud tööde tulemi valmimise ja ajaplaani täitmise. 5.5. 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. 5.6. Vajadusel täpsustavad pooled hankelepingu sõlmimisel projektimeeskonna liikmete rollid ja nende ülesanded. 5.7. Tellija juures töötab projekti juhtrühm, mis jälgib raamlepingu alusel sõlmitud lepingute täitmist tervikuna. 6. ARUANDLUS 6.1. Töötunnipõhiselt tasustavate tellimuste (arendusprojektide) puhul on täitja meeskond kohustatud esitama tööaja aruandeid vastavalt tellija poolt nimetatud tingimustele. 6.1.1. Tellija nimetab tööaja aruannete esitamiseks kasutatava töövahendi (nt Jira) lepingus ja tagab selle kättesaadavuse. 6.1.2. Tööaja aruande esitab täitja iga meeskonnaliige isiklikult (iga meeskonnaliige täidab aruandevormid ise). 6.1.3. Tööaja aruannete esitamise sagedus on üks kord nädalas (reedese tööpäeva lõpuks, riigipühade puhul sellele eelneva tööpäeva lõpuks), kui tellija ja täitja ei lepi kokku teisiti. 6.1.4. Nõuded ajaaruande detailsusele (täidetud tööülesannete kirjeldusele) kehtestab tellija projektijuht. 7. TASUSTAMINE 7.1. Töötunnipõhiste tellimuste (arendusprojektide) puhul kuuluvad tellija poolt tasustamisele üksnes reaalselt töö teostamiseks kulutatud efektiivsed töötunnid, mis loovad tellijale otsest väärtust. 7.1.1. Tellija ei tasusta (ei aktsepteeri ajaaruannetes) seadusest tulenevaid puhkepause (nt lõunapausid, paus silmade puhkamiseks jmt). 7.1.1.1. Täitja peab lähtuma Vabariigi Valitsuse määrusest nr 362, vastu võetud 15.11.2000 (Kuvariga töötamise töötervishoiu ja tööohutuse nõuded), võimaldades täitja meeskonnaliikmetele puhkepause nõutaval määral. 7.1.1.2. Täitja peab lähtuma kehtivast töölepingu seadusest. Täitja peab planeerima meeskonnaliikmete töökoormuse selliselt, et tööülesanded täidetakse nominaaltöötundide piires. Ületunnitöö rakendamine täitja meeskonnas toimub kokkuleppel tellijaga. 7.1.2. Tellija ei tasusta (ei aktsepteeri ajaaruannetes) ajakulu, mis on seotud täitja spetsialistide oskusteabe täiendamisega, mis on vajalik lepingus sätestatud tööde nõuetekohaseks teostamiseks. Nende hulka kuuluvad näiteks: 7.1.2.1. Uute tehnoloogiate tundmaõppimine (mille järele vajadus võib selguda töö teostamise käigus). 3 7.1.2.2. Uue metoodikate tundmaõppimine (mille järele vajadus võib selguda töö teostamise käigus). 7.1.3. Tellija ei tasusta punktist 7.1.2 lähtuvalt täitja meeskonnaliikmete täiendavat tööaega, mis kaasneb tööülesannete täitmiseks uue oskusteabe omandamisega. 7.1.4. Tellija ei tasusta aega, mis kulub täitjal korduvate (esineb vähemalt kaks korda) vigade lahendamiseks (näiteks samaliigiliste probleemide kordumine lähtekoodis vaatamata täitja varasemale tagasisidele koodiülevaatuste käigus). 7.1.5. Tellija ei tasusta aega, mis kulub täitjal pakkumuse koostamiseks ja esitamiseks. 7.1.6. Tellija eeldab, et täitja arvestab meeskonnaliikmete vahetumisel selle mõjuga tööviljakusele (produktiivsusele) ja kajastab seda ajaaruannetes. 7.2. Fikseeritud lõpphinnaga tellimuste (arendusprojektide) puhul kuulub akteerimisele töö, mis on edukalt läbinud tellija poolse vastuvõtutestimise (Acceptance Test, User Acceptance Test). 8. LEPINGU TÄITMISEGA SEOTUD INFOVAHETUS 8.1. Lepingute täitmisega seotud dokumentatsiooni haldamiseks ja jagamiseks kasutatakse tellija poolt nimetatud keskkonda (nt Confluence). Tellija tagab nimetatud keskkonna kättesaadavuse. 8.2. Konfiguratsiooni- ja arendustööde ülesannete suunamiseks ja jälgimiseks, vigade ja probleemide haldamiseks ning tööaja arvestuseks kasutatakse tellija poolt nimetatud töövahendit (nt Jira). 8.2.1. Tellija võib lisaks töövahendis registreerimisele viidata leitud vigadele ka e-kirja vm suhtluskanali vahendusel, kuid vea/tööülesandega tegelema hakkamise eelduseks täitja poolt on vea registreerimine töövahendis ning lepingus toodud nimetatud tööde eest vastutava (tellija) isiku poolt antud korraldus tööde alustamiseks. 8.3. 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. 8.4. Teabevahetuse vormid ja reageerimisajad: 8.4.1. 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. 8.4.1.1. Koosoleku toimumise järel koostatakse memo (vastutab koosoleku korraldaja), otsused protokollitakse ja saadetakse e-kirjaga koosolekul osalenutele teadmiseks/vajadusel kinnitamiseks. Kui memo adressaat ei esita kahe tööpäeva jooksul pretensiooni memo sisu osas, loetakse, et isik nõustub memos toodud seisukohtade/otsustega ja nimetatud fikseeriti memos toodud kujul koosoleku käigus. 8.4.2. E-kiri – kasutatakse igapäevase suhtluskanalina (v.a kui konkreetset infot tuleb vastavalt kodukorrale edastada täitja projektikeskkondade kaudu). 8.4.2.1. Kui e-kirjale oodatakse vastust, tuleb pealkirja real või kirja alguses see üheselt määratleda. Kui e-kirjale ei ole võimalik anda selle aja jooksul sisulist 4 vastust, tuleb hiljemalt järgneva tööpäeva jooksul teha teatavaks sisulise vastuse andmise aeg. 8.4.3. Telefon, Skype, Rocket Chat – kasutatakse kiireloomuliseks ja operatiivseks suhtluseks. Skype’i kõneteenuse või telefoni kaudu kokkulepitud olulised otsused tuleb kinnituseks fikseerida e-kirjaga või arutada ja protokollida koosolekul. 8.4.3.1. Pooled säilitavad projekti e-kirjad, Skype vestlused ja Rocket chat vestlused projekti ja garantiiperioodi kehtivuse ajal. 8.4.3.2. Poolte projektijuhid lepivad kokku e-posti, Skype gruppide ja Rocket chat gruppide loomise. 8.4.4. Stand-up kohtumine – Toimub tellija soovitud sagedusega täitja esindajate osalusel. Stand-up kohtumisi ei toimu, kui täitjal ei ole tellija poolt esitatud tellimusi töös. 9. NÕUDED DOKUMENTEERIMISELE 9.1. Projekti dokumentatsioon peab olema terviklik ja terminoloogiliselt üheselt mõistetav. 9.2. Nõuded dokumenteerimisele on esitatud dokumendis „Nõuded infosüsteemi dokumentatsioonile“. 10. ARENDUS-, TEST-, PRELIVE- ja LIVE KESKKONNAD 10.1. Arenduskeskkond asub täitja juures, kes tagab selle olemasolu ja toimimise. 10.2. Tellija testkeskkond koosneb vähendatud võimsusega komponentidest. Täitjal on tellija testkeskkonnale lugemisõigusega ligipääs. 10.3. Tellija Prelive keskkond koosneb Live keskkonnale sarnastest komponentidest, sh andmebaasid, rakendusserverid ning väliste süsteemide liidesed. Täitjal puudub alaline ligipääs Tellija Prelive keskkonnale. 10.4. Live keskkonna konfiguratsioon lepitakse kokku arenduse käigus. Täitjal puudub ligipääs Tellija Live keskkonnale. 10.5. Pooled teevad mõistlikud pingutused tagamaks, et tellija testkeskkond sarnaneks Live keskkonnale järgmises osas: 10.5.1. arvutivõrgu konfiguratsioon; 10.5.2. liidesed kolmandate süsteemidega; 10.5.3. andmemahud; 10.5.4. kui maksimaalne sarnasus ei ole majanduslikult põhjendatud või tulenevalt andmekaitse piirangutest võimalik, kohustub pool informeerima teist poolt Test- ja Live keskkondade disainitud erinevustest. Vajadusel lepivad pooled kokku alternatiivse võimaluse keskkondade erinevuse puudujäägi kompenseerimiseks. 10.6. Keskkondade ning nende ligipääsude haldamise ja tarnete paigalduse reeglid lepitakse kokku projekti alguses. 11. VEA PARANDAMINE ARENDUSE, JUURUTAMISE VÕI GARANTIIPERIOODI KÄIGUS 11.1. Vigade menetlemise käigus registreeritakse kõik poolte leitud vead tellija poolt nimetatud keskkonnas (nt Jira). 11.2. Täitja analüüsib vea kirjeldust ning selgitab välja vea põhjuse. 5 11.3. Vigadele määrab tellija kriitilisuse astme ja neid asutakse parandama kriitilisuse järjekorras, lähtudes tellija poolt teatavaks tehtud prioriteetidest vigade parandamisel. 11.4. Garantiiperioodil asub täitja viga parandama vastavalt raamlepingus sätestatud tingimustele. 12. KRIISISITUATSIOONIDE HALDAMINE 12.1. 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. 12.2. Kriisi tekkimisel on pool kohustatud sellest teise poole esindajat viivitamatult kirjalikult teavitama. 12.3. Kriisist väljumiseks teevad 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. 12.4. Kriisi tekkel informeerib tellija projektijuht koheselt projekti juhtrühma, kes rakendab meetmed kriisi lahendamiseks. 12.5. Kui kriisi ei suudeta projekti juhtrühma poolt likvideerida, kasutatakse täitja ja tellija vahelises lepingus sätestatud meetmeid. 6 Sotsiaalkaitse infosüsteemi arendustööd Nõuded pakkuja meeskonnale Helmese kinnitus Tellija nõue ja selgitused. Kinnitame 1. Pakkujal peab olema raamlepingu alusel tööde võimekuse teostamiseks võimekus teostada detailanalüüsi olemasolu. (sh ärianalüüs, süsteemianalüüs), arendus- ja testimistöid. Kinnitame. 2. Pakkuja peab esitama pakkumuse koosseisus vähemalt kaheliikmelise meeskonna, tuues isikuliselt välja vähemalt analüütiku ja arhitekti: Kinnitame. a. Arhitekt täidab hankelepingus tööülesandeid täiskohaga, teostades vajadusel lisaks arhitekti töödele ka arendustöid. Kinnitame, et 3. Vähemalt ühel meeskonnaliikmetest peab Aleksandr olema meeskonna juhtimise kogemus. Knjazetskil ja Vaiko Karusionil on meeskonna juhtimise kogemus. Kinnitame, 4. Pakkuja esitab meeskonnaliikmete andmed, kirjeldatud täites iga nõutud rolli kohta all toodud vormid. elulookirjeldustes. Kinnitame. 5. Kui üks isik on esitatud mitmesse rolli, peab ta täitma võetud rollide kõik kohustuslikud nõuded. Kinnitame. 6. Esitatud andmed peavad võimaldama hankijal kontrollida meeskonnaliikmete vastavust esitatud nõuetele. Kinnitame. 7. Ühe viidatud lepingu/projektiga võib olla hõlmatud mitu kompetentsi/kogemust. Kõik nõutud kompetentsid/kogemused peavad olema lepingute või projektidega omandatud kogemusega kaetud. Kui mõne nõutud kompetentsi/kogemuse osas vastavad lepingu või väljaõpet tõestavad andmed esitamata, on hankijal õigus tunnistada pakkumus mittevastavaks. Kinnitame. 8. Meeskonnaliikmete esitamisega kinnitab pakkuja, et esitatud meeskonnaliikmed hakkavad riigihanke tulemusel sõlmitud lepingu alusel töid teostama. Pärast pakkumuse esitamist saab pakkumuses esitatud meeskonnaliikme välja vahetada üksnes samaväärse kogemusega meeskonnaliikme vastu, juhul kui tellija annab selleks eelnevalt oma nõusoleku. Kinnitame. 9. Pakkuja kinnitab riigihankes pakkumuse esitamisega, et suudab hankelepingu sõlmimiseks tagada ja hankijale tõendada järgnevalt toodud vormidel esitatud nõuetele vastavad arendajad, projektijuhi ja testijad, keda ei ole vaja isikuliselt riigihankes pakkumuse esitamisel välja tuua. Kinnitame. a. Vastavalt kodukorrale ei ole üldjuhul eraldi projektijuhi rolli vaja. Kinnitame. b. Testija roll võib olla kaetud ka arendaja rolli täitva isiku poolt, kes loob automaattestid ja tagab kvaliteedinõuded (arendaja ja testija võivad olla ühes isikus). Kinnitame. 10. Vanemarendajate ja keskmise tasemega arendajate suhe meeskonnas peab hankelepingu täitmisel olema vähemalt1: Kinnitame. a. 1-3 keskmise tasemega arendaja kaasamisel hankelepingu täitmisesse peab meeskonda kuuluma vähemalt 1 vanemarendaja; Kinnitame. b. 4 või enama keskmise tasemega arendaja kaasamisel hankelepingu täitmisesse peab meeskonda kuuluma vähemalt 2 vanemarendajat. 1 Punkt kohaldub ainult keskmise tasemega arendajate olemasolul. Kui meeskonnas on ainult vanemarendajad, siis ei ole tarvilik seda punkti järgida. Ühe meeskonna suuruseks loetakse kuni 8 inimest. 1. Meeskonna juhtimise kogemus Meeskonna liige, kellel on meeskonna juhtimise kogemus:  Aleksandr Knjazetski ja Vaiko Karusion. Kirjeldus, kus ja kuidas kogemus on omandatud: Aleksandr Knjazetski omandas meeskonna juhtimise kogemuse töötades SwiftLOG projektis analüütikuna ka tehnilise tiimi juhina ning Scrum Masterina. Alates jaanuarist, 2020 täidab Aleksandr Knjazetski Helmeses Tiimijuhi rolli olles 7 liikmelise Java meeskonna juht. Vaiko Karusion omandas meeskonna juhtimise kogemuse järgmistes projektides: GSK Reporting, KN FreightNet LCL ja paljudes teistes profiili juures toodud projektides. Projektide kirjeldused ja kontaktisikud on välja toodud järgmistel lehekülgedel elulookirjeldustes. 2. Analüütik (Aleksandr Knjazetski, 38605163721): Nõude Nõuded Täpsustus selle kohta kus/millal/kuidas on nõue kood täidetud. Projektidele viitamisel märkida projekti nimi, projekti kestus vähemalt kalendrikuudes projekti tellinud asutus ja tellija kontaktisik, arvestades, et hankijal on õigus kontrollida esitatud andmeid viidatud kontaktisiku vahendusel. Välja täitmine on kohustuslik. 1a2 Omab kõrgharidust ja Omab vähemalt 3 aastat töökogemust analüütikuna või tarkvara projekteerijana. 1b Omab vähemalt 5 aastat Aleksandr omab töökogemust: töökogemust analüütikuna ärianalüütikuna Ericssonis Eesti AS ajavahemikul või tarkvara 08/2010-11/2017; projekteerijana. töögemust ärianalüütikuna Lasita Maja AS ajavahemikul 03/2019-02/2020; ja töökogemust äri- ja süsteemianalüütikuna, Helmes AS ajavahemikul 11/2017-03/2019 ja 02/2020- tänaseni. 2 On osalenud vähemalt ühes IT projektis viimase Aleksandri osalus projektis, mille maht on rohkem kui 3 aasta jooksul alates 5000 töötundi analüütik, Scrum Master, tehnilise tiimi hanke juhina: väljakuulutamisest, mille arendusmaht on rohkem SwiftLOG, Periood: 01/2018 – 03/2019, 5000+ töötundi, kui 5000 töötundi. Tellija: Kühne + Nagel IT Service Centre AS, Toomas Gavrilin [email protected] 3 Omab varasemates Tuua andmed välja projektidele viidates. projektides töökogemust: 3.1 Menetlussüsteemide Aleksandr osales SwiftLOG Laohalduse ja tellimuste arendamisel ja/või menetlemise süsteemi loomise projektis, kus analüüsimisel meneteleti klienditellimuseid mitmeetapiliselt: tellimuse vastuvõtmine, kontroll, lattu saatmine, laost materjali toomine, pakimine, W&D kontroll, etiketide printimine, tellimuse täitmine. välja saatmine. Tellimustele määrati erinevad staatuseid vastavalt protsessi ja etapi sammust, vajadusel või vea leidmisel lükati tellimusi tagasi või väljastati lõppkliendile tellimuse täitmisel. Menetlusprotsessis osalesid erinevad rollid. Projekti käigus mh. 2 Siin ja edaspidi: Täita tuleb kas väli 1a või 1b. optimeeriti äriprotsessid. 01/2018 – 03/2019, 5000+ töötundi, Tellija: Toomas Gavrilin toomas.gavrilin@kuehne- nagel.com Supply Chain Optimization Program Kliendi tellimuste mitme.etapiline menetlussüsteem: tellimuste vastuvõtt, kontroll, planeerimine, meenetlemine, täitmine ja väljasaatmine koos ärireeglite ja erinevate õigustega menetlejatega. Projekti käigus mh. optimeeriti äriprotsessid. Periood: 06/2015 – 05/2016. Tellija: Ericsson Eesti AS, Ericsson North America, Sirli Männiksaar sirli.mä[email protected] 3.2 äriprotsesside Aleksandr osales äriprotsesside optimeerimisel optimeerimisel allolevates projektides: SwiftLog: vaata projekti detaile eelmises kategoorias. Supply Chain Optimization Program: vaata projekti detaile eelmises kategoorias. Integrated Planning: Rahvusvahelise planeerimissüsteemi loomine ja juurutamine, äriprotsesside analüüs, äriprotsesside optimeerimine, kaardistamine, parandamine, IT lahenduste prototüübide loomine, äriloogika analüüs ja jurutamine, IT lahenduste tarnimine, tööinstruktsioonide kirjutamine ja koolitused lõppkasutajatele, proejkti juhtimine, IT-lahenduste testimine. 11/ 2013 – 10/2014, Tellija: Ericsson Eesti AS, Ericsson AB, Sirli Männiksaar sirli.mä[email protected] 3.3 Prototüüpide koostamisel Aleksandr osales prototüüpide loomisel allolevas projektis: SBS Menetlussüsteem, arvete ning kulukohtade menetlussüsteem koos rollipõhiste menetlejaõigustega: veebipõhiste prototüüpide loomine vastavalt kokkulepitud protsessile. Projekti kestvus Periood: 02/2019 – 09/2019 Tellija: SBS Seebauer Business Solutions GmbH, Thomas Seebauer, [email protected] 3. Arhitekt (Vaiko Karusion, 38312294910) Nõude Nõuded Täpsustus selle kohta kus/millal/kuidas on nõue kood täidetud. Projektidele viitamisel märkida projekti nimi, projekti kestus vähemalt kalendrikuudes projekti tellinud asutus ja tellija kontaktisik, arvestades, et hankijal on õigus kontrollida esitatud andmeid viidatud kontaktisiku vahendusel. Välja täitmine on kohustuslik. 1a Omab kõrgharidust 2011 aasta, Informaatika Magistrikraad, Tallinna reaalainete valdkonnas3 ja Tehnikaülikool omab vähemalt 5 aastat KN CTC, vanemarendaja töökogemust süsteemi- Periood: 09/2019 – tänaseni või tarkvara arhitektina või Tellija: Kuehne+Nagel AG & Co, Inge Leesman, vanemarendajana. [email protected] SBS Menetlussüsteem arhitekt, tehnilise meeskonna juht, Periood: 02/2019 – 09/2019 Tellija: SBS GmbH Thomas Seebauer, Thomas Seebauer, [email protected] GSK Reporting, arhitekt, tehnilise meeskonna juht Periood: 09/2017-01/2019 Tellija: Kuehne+Nagel AG & Co, Ansgar Bunte, +49 172 415 55 37 [email protected] Seadmekindlustus vanemarendaja, Periood: 02/2017-09/2017 Tellija: Telia Eesti AS, Gleb Semenjuk, +372 639 7130, [email protected] LCL Sailing Schedule, arhitekt, tehnilise meeskonna juht, Periood: 05/2016 - 01/2017 Tellija: Kuehne+Nagel AG & Co, Ansgar Bunte, +49 172 415 55 37 [email protected] KN FreightNet LCL, vanemarendaja, tehnilise meeskonna juht, mooduli arhitekt, Periood: 05/2015 – 05/2016 Tellija: Kuehne+Nagel AG & Co, Martin Fritz, [email protected] 3 Siin ja edaspidi käsitleb hankija reaalainetena Tartu Ülikoolis: Loodus ja täppisteaduste erialad; Tallinna Tehnikaülikoolis: Inseneri-, infotehnoloogia ja loodusteaduskonna erialad; Tallinna Ülikoolis: Digitehnoloogiate instituudi erialad; või samaväärne. Eesti.ee hooldustööd, vanemarendaja, Periood: 10/2013-05/2014 Tellija: RIA, Mikk Vainik, Riigi Infosüsteemi Amet (+372) 666 8841 Trixxa, arhitekt, tehnilise meeskonna juht , Tellija: Baltic Quality AB, Peter Karlsson, [email protected] Tele2 e-pood ja iseteenindus, arhitekt, Periood: 02/2008 – 09/2011 ja 11/2012-10/2013 Tele2 Eesti AS, [email protected], 1b Omab vähemalt 10 aastat töökogemust süsteemi- või tarkvara arhitektina või vanemarendajana. 2 On osalenud vähemalt Vaiko osalus projektides mille maht on rohkem kui ühes IT projektis viimase 5000 töötundi: 3 aasta jooksul alates hanke KN CTC väljakuulutamisest, mille Periood: 09/2019 – tänaseni arendusmaht on rohkem Tellija: Kuehne+Nagel AG & Co, Inge Leesman, [email protected] kui 5000 töötundi. GSK Reporting, Periood: 09/2017-01/2019 Tellija: Kuehne+Nagel AG & Co, Ansgar Bunte, +49 172 415 55 37 [email protected] Vähemalt kõikides alltoodud Kuehne+Nagel AG & Co projektides on meeskonna poolt arendatud koodi kaetud automaattestidega vähemalt 70% ulatuses. 3 Omab vähemalt 60 Vaiko 60 kalendrikuuga kogemus on omandatud kalendrikuu kestusega allolevates projektides: töökogemust projektides relatsiooniliste KN CTC, andmebaaside ja Java’ga. Periood: 09/2019 – tänaseni Tellija: Kuehne+Nagel AG & Co, Inge Leesman, [email protected] GSK Reporting, 09/2017-01/2019 Tellija: Kuehne+Nagel AG & Co, Ansgar Bunte, +49 172 415 55 37 [email protected] SBS Menetlussüsteem, Periood: 02/2019 – 09/2019 Tellija: SBS GmbH Thomas Seebauer, Thomas Seebauer, [email protected] Seadmekindlustus, Periood: 02/2017-09/2017 Tellija: Telia Eesti AS, Gleb Semenjuk, +372 639 7130, [email protected] LCL Sailing Schedule, Periood: 05/2016 - 01/2017 Tellija: Kuehne+Nagel AG & Co, Ansgar Bunte, +49 172 415 55 37 [email protected] KN FreightNet LCL, Periood: 05/2015 – 05/2016 Tellija: Kuehne+Nagel AG & Co, Martin Fritz, [email protected] Tele2 e-pood ja iseteenindus, arhitekt, vanemarendaja Periood: 02/2008 – 09/2011 ja 11/2012-10/2013 Tellija: Tele2 Eesti AS, [email protected] 4 Omab varasemates Tuua andmed välja projektidele viidates. projektides töökogemust järgmistega: 4.1 töökogemus menetlus- ja Vaiko osales arhitekti rollis SBS menetlussüsteemi finantssüsteemide arendamisel, mis sisaldab rollipõhiseid menetleja projekteerimisel ja õigusteid. Süsteemis menetletakse riistvara tellimusi arendamisel ja nende haldust. Süsteemis käsitletakse tellimusi, tellimuste alusel koostatakse arved ja jälgitakse võlgnevusi. Sõltuvalt tellimuse suurusest kaasati menetluse töövoogudesse erinevaid rolle Tellija: SBS Seebauer Business Solutions GmbH, Thomas Seebauer, [email protected] Vaiko osales Tele2 e-poe ja iseteeninduse arhitekti rollis. Süsteemis menetletakse ostutellimuste tegemist, arveldust, arvete väljastamist, järelmaksu, klientide riskikäitumist arvutades ja lähtudes nende krediidiskoorist, laos kauba olemasolu ja väljastamist. Tellimusi menetletakse mitme etapiliselt kaasates erinevaid rolle. Süsteemis genereeritakse tellimuste alusel arveid ning krediidimüügi liimiidid arvutatakse tellijate riskiskoorist lähtudes. Tellija: Tele2 Eesti AS, [email protected] KREGMAN Reporting, Laenu- ja liisinguvõlglaste raporteerimise süsteem Läti Keskpangale. Ülesanne oli leida üles kliendid, kes on võlgu ja raporteerida võla periood ja summa. Tellija: Hanspank Latvia, [email protected] Stardikonto avamine. Teenus võimaldab ettevõtetel stardikapitali kohtudeposiiti kandmise asemel avada konto otse pangas jättes vahele kohtudeposiidi ja 5 päevase ooteaja. Hanspank Eesti. Tellija: Swedbank Eesti, [email protected] 4.2 Liquibase Vaiko omandas Liquibase kogemuse allolevates projektides: GSK Reporting Tellija: Kuehne+Nagel AG & Co, Ansgar Bunte, +49 172 415 55 37 [email protected] LCL Sailing Schedule, Tellija: Kuehne+Nagel AG & Co, Ansgar Bunte, +49 172 415 55 37 [email protected] 4.3 Continuous integration Vaiko omandas Continuous integration kogemuse vahenditega (nt Jenkins, allolevates projektides: Gitlab vms) GSK Reporting, Tellija: Kuehne+Nagel AG & Co, Ansgar Bunte, +49 172 415 55 37 [email protected] LCL Sailing Schedule Tellija: Kuehne+Nagel AG & Co, Ansgar Bunte, +49 172 415 55 37 [email protected] 4.4 Linux/Unix Vaiko omandas kogemuse Linux/Unix operatsioonisüsteemidega operatsioonisüsteemidega järgmistes projektides: GSK Reporting, Tellija: Kuehne+Nagel AG & Co, Ansgar Bunte, +49 172 415 55 37 [email protected] LCL Sailing Schedule, Tellija: Kuehne+Nagel AG & Co, Ansgar Bunte, +49 172 415 55 37 [email protected] 4.5 Spring raamistikuga Vaiko omandas kogemuse Spring raamistikuga järgmistes projektides: GSK Reporting Tellija: Kuehne+Nagel AG & Co, Ansgar Bunte, +49 172 415 55 37 [email protected] LCL Sailing Schedule Tellija: Kuehne+Nagel AG & Co, Ansgar Bunte, +49 172 415 55 37 [email protected] 4.6 SOAP Vaiko omandas SOAP kogemuse järgmistes projektides: Eesti.ee hooldustööd. Tellija: RIA, Mikk Vainik, Riigi Infosüsteemi Amet (+372) 666 8841 Iseteeninduse liidestus uue arveldussüsteemiga. Tellija: SIA Tele2 Latvia, Elgars Goba, [email protected] 5 Peab omama töökogemust vähemalt ühega järgnevast: 5.1 SOA ja Mikroteenustel Vaiko omandas SOA ja mikroteenustel põhineva põhinevate arhitektuurilahenduse loomise kogemuse järgmistes arhitektuurilahenduste projektides: projekteerimisel ning realiseerimisel GSK Reporting. SOA ja loodi võimekus üle minna mikroteenustel põhinevale arhitektuurile. Tellija: Kuehne+Nagel AG & Co, Ansgar Bunte, +49 172 415 55 37 [email protected] KN DMS Next, Vaiko nõustas monoliitarhitektuuril põhineva süsteemi meeskonda ning arendas visiooni koos tegevuskavaga, ning arendas töötava MVP monoliidi üle viimiseks mikroteenustele. Tellija: Kuehne+Nagel AG & Co, Jüri Vesterblom, [email protected] 5.2 Konteinerlahenduse Vaiko omandas konteinerlahendusel põhineva loomisel süsteemi loomise kogemuse järgmistes projektides: SBS Menetlussüsteem, Tellija: SBS GmbH Thomas Seebauer, [email protected] Seadmekindlustus, Tellija: Telia Eesti AS, Gleb Semenjuk, +372 639 7130, [email protected] Pakkuja kinnitab, et suudab hankelepingute täitmiseks tagada ja esitada järgmistele nõuetele vastavad meeskonnaliikmed: 4. Vanemarendaja Nõude Nõuded kood 1a Omab kõrgharidust reaalainete valdkonnas ja Omab vähemalt 3 aastat töökogemust IT arendajana. 1b Omab vähemalt 5 aastat töökogemust IT arendajana. 2 On osalenud vähemalt ühes IT projektis viimase 3 aasta jooksul alates andmete esitamisest, mille arendusmaht on rohkem kui 5000 töötundi ning projektis on kasutatud Spring ning REST/SOAP protokollil baseeruvaid veebiteenuseid. 3 Omab vähemalt 24 kalendrikuu kestusega töökogemust projektides relatsiooniliste andmebaaside ja Java’ga. 4 Omab varasemat töökogemust projektides järgmistega: 4.1 GIT 4.2 Intellij IDEA/Eclipse 5. Keskmise tasemega arendaja Nõude Nõuded kood 1a Omab kõrgharidust reaalainete valdkonnas ja Omab vähemalt 2 aastat töökogemust IT arendajana. 1b Omab vähemalt 3 aastat töökogemust IT arendajana. 2 On osalenud vähemalt ühes IT projektis viimase 2 aasta jooksul alates andmete esitamisest, mille arendusmaht on rohkem kui 5000 töötundi ning projektis on kasutatud Spring ning REST/SOAP protokollil baseeruvaid veebiteenuseid. 3 Omab vähemalt 24 kalendrikuu kestusega töökogemust projektides relatsiooniliste andmebaaside ja Java’ga. 4 Omab varasemat töökogemust projektides järgmistega: 4.1 GIT 4.2 Intellij IDEA/Eclipse . 6. Kasutajaliidese arendaja Nõude Nõuded kood 1 Omab vähemalt 3 aastat töökogemust IT arendajana. 2 On osalenud vähemalt ühes IT projektis viimase 3 aasta jooksul alates andmete esitamisest, mille arendusmaht on rohkem kui 5000 töötundi ning projektis on kasutatud Spring ning REST protokollil baseeruvaid veebiteenuseid. 3 Omab vähemalt 2-aastast töökogemust esitluskihi loomisel. 4 Omab varasemat töökogemust projektides järgmistega: 4.1 GIT 4.2 Intellij IDEA/Eclipse 4.3 Javascript (Angular) 7. Testija Nõude Nõuded kood 1 Omab vähemalt 2 aastat töökogemust testijana või programmeerijana. 2 On osalenud vähemalt kahes tarkvara arenduse projektis, kus on isiklikult kirjutanud automaatteste. 8. Projektijuht Nõude Nõuded kood 1 Omab vähemalt 2 aastat töökogemust tarkvara arenduse projektijuhina. 2 On juhtinud vähemalt ühte tarkvara arendusprojekti viimase 2 aasta jooksul alates andmete esitamisest, mille projekti maht ületab 5000 töötundi. Hankelepingu projekt tööde tellimiseks Hankeleping nr..... Hankelepingu nimetus Tervise ja Heaolu Infosüsteemide Keskus, registrikood 70009770, aadress Uus-Tatari 25, Tallinn, keda esindab põhimääruse alusel direktor Katrin Reinhold (edaspidi tellija), ja ...., registrikood ..., aadress ..., keda esindab põhikirja alusel ... (edaspidi täitja), edaspidi eraldi pool või koos pooled, sõlmisid raamlepingu nr ... alusel käesoleva hankelepingu (edaspidi leping) alljärgnevas: 1. Lepingu ese 1.1. Lepingu esemeks on lisas 1 „Hankelepingu eseme tehniline kirjeldus“ nimetatud tööd koos garantiiteenustega (edaspidi tööd). 1.2. Lepingu tööde maht on kuni ... töötundi (täidetakse juhul, kui tööd tellitakse töötunnipõhisel arvestusel). 1.3. Vajadusel on tellijal õigus tellida lepingu esemega seotud täiendavaid töid kuni 20% ulatuses kokkulepitud mahust, eeldusel, et hankelepingu üldist olemust ei muudeta. 1.4. 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. 2. Töö üleandmise ja vastuvõtmise tingimused 2.1. Täitja annab töö üle hiljemalt ... (lisada tähtaeg või tähtajad, kui töö teostamine toimub etappides). 2.2. Tellitavad tööd antakse vastuvõtutestimiseks üle vastavalt lepingu lisas 1 kokkulepitud tingimustele. 2.3. Tellija vaatab töö üle vastavalt raamlepingu tingimustele. 2.4. Töö antakse üle üleandmise ja vastuvõtmise aktiga (edaspidi ka akt). 2.5. Koos üle antava tööga annab täitja tellijale üle kõik tööde intellektuaalse omandi õigused vastavalt raamlepingus kirjeldatule. 3. Lepingu hind 3.1. Kui lepingu maksumus ei ole kokku lepitud fikseeritud summana ja tööde teostamine toimub töötunnipõhisel arvestusel, tasub tellija üksnes lepingu alusel tellitud ja teostatud töötundide eest. Täitja esitab iga kalendrikuu lõpus allkirjastatud ajaaruande järgmise kalendrikuu 5. tööpäevaks, millelt kajastuvad teostatud töötunnid ja nende jooksul teostatud tööd. Viimane ajaaruanne esitatakse koos aktiga. 3.2. Ühe töötunni maksumuseks tööde teostamisel on ..... (maksumus sõnadega) eurot ilma käibemaksuta (Lepitakse kokku tööde mahust lähtudes. Vajadusel, nt fikseeritud tasu kasutamise korral, ühe töötunni hinda eraldi välja ei tooda, vaid märgitakse fikseeritud tasu suurus ja see punkt kustutatakse). 3.3. Tellija tasub lepingu alusel tellitud tööde eest kokku ..... (maksumus sõnadega) eurot ilma käibemaksuta (Lepitakse kokku lähtudes pakkumusest, kui tööde teostamine on kokku lepitud etappides, fikseeritakse ühtlasi etappide maksumused). 3.4. Arve esitatakse e-arvena, pärast akti tellija poolt allkirjastamist. 3.5. Täitja annab tellijale arve tasumiseks tähtaja minimaalselt 21 kalendripäeva alates arve laekumisest. Arvel tuleb märkida raamlepingu ja hankelepingu number, riigihanke viitenumber ja tellija kontaktisiku nimi. 4. Poolte vahelised teated ja kontaktisikud (lisada juhul kui erinevad raamlepingu omast) 4.1. Teadete edastamine toimub üldjuhul telefoni, e-posti, või posti teel. Juhul, kui teate edastamisel on olulised õiguslikud tagajärjed, peavad teisele poolele edastatavad teated olema edastatud taas-esitamist võimaldavas vormis (s.o kirjalikus vormis või e- posti teel). Informatiivset teadet võib edastada ka telefoni teel. 4.2. Teate edastamise hetkeks loetakse elektronkirja tehniliselt tõendatud saatmise hetk või kirjaliku teate allkirjaga tõendatud vastuvõtmise hetk. 4.3. Tellija kontaktisikuks lepingu täitmisel on ..., tel ..., e-post .... 4.4. Täitja kontaktisikuks lepingu täitmisel on ..., tel ...., e-post .... 5. Lepingu kehtivus 5.1. Leping jõustub sellele poolte poolt allakirjutamisest ja kehtib kuni poolte poolt oma lepinguliste kohustuste täitmiseni. 5.2. Tellijal on õigus leping igal ajal üles öelda, teatades sellest 60 kalendripäeva ette. 6. Lõppsätted 6.1. Lepingu täitmisel tekkinud vaidlused ja lahkarvamused lahendavad pooled läbirääkimiste teel. Kokkuleppe mittesaavutamisel lahendatakse vaidlused Harju Maakohtus. 6.2. Lepingu täitmisel ja lepingust tulenevate vaidluste lahendamisel lähtutakse Eesti Vabariigi õigusaktidest. 6.3. Pooled ei tohi lepingust tulenevaid õigusi ja kohustusi üle anda kolmandatele isikutele ilma teise poole kirjaliku nõusolekuta. 6.4. Lepingu dokumendid koosnevad käesolevast lepingust, lepingu lisadest ning lepingu muudatustest, milles pooled võivad kokku leppida lepingu allakirjutamise järgselt. 6.5. Lepingu lahutamatuteks osadeks lepingu sõlmimise hetkel on järgmised dokumendid: 6.5.1. Lisa 1 - Hankelepingu eseme tehniline kirjeldus; 6.5.2. Lisa 2 - Vajadusel isikuandmete töötlemise tingimused. 7. Poolte allkirjad Tellija: Täitja: (allkirjastatud digitaalselt) (allkirjastatud digitaalselt) ISIKUANDMETE TÖÖTLEMISE TINGIMUSED ... (edaspidi volitaja), registrikood ...., asukohaga ......, keda esindab direktor ....... ja ..... (edaspidi volitatud töötleja), registrikood ......, asukohaga ......., keda esindab juhatuse liige ........ on sõlminud käesoleva isikuandmete töötlemise lepingu hankelepingu nr ... lisana nr ... (edaspidi leping): 1. Lepingu ese ja eesmärk 1.1. Lepingu esemeks on volitaja ja volitatud töötleja (edaspidi koos nimetatud kui pooled) vaheliste tingimuste sätestamine seoses ... tööde käigus käsitletavate andmete töötlemisega. 1.2. Isikuandmete vastutavaks töötlejaks on Sotsiaalkindlustusamet, kes on andud Volitajale 16.10.2018 teenuslepinguga nr 1-10/1486-1 (p 3.8) õiguse kaasata isikuandmete töötlemiseks täiendavaid volitatud töötlejaid seoses Sotsiaalkindlustusameti (edaspidi SKA) infosüsteemide arendamise, hooldamise või muu taolise eesmärgi täitmiseks. 1.3. Volitatud töötleja töötleb lepingus kirjeldatud isikuandmeid hankelepingu nr ... täitmiseks, millele on volitatud töötlejal õigus saada ligipääs hankelepingus määratletud tööde teostamiseks vastavalt lepingus sätestatud piirangutele. 1.4. Lepingu täitmiseks on volitatud töötleja isikuandmete töötlemisega seotud tegevused lepingu alusel piiratud hankelepingu täitmiseks vajalike tegevustega. 2. Isikuandmed 2.1. Volitatud töötlejale võivad hankelepingu täitmise käigus teatavaks saada sotsiaalkaitse infosüsteemis töödeldavad isikuandmed (SKAIS põhimääruse § 7 -15 kirjeldab võimalikud isikuandmete koosseisud): 2.1.1. isiklikud andmed, nt inimese nimi, sünniaeg, isikukood, isikut tõendava dokumendi andmed; 2.1.2. kontaktandmed, nt aadress, telefoninumber ja e-posti aadress; 2.1.3. eriliigilised isikuandmed, nt andmed isiku või tema pereliikme terviseseisundi, majandusliku seisundi või perekonna kohta; 2.1.4. ..... 3. Volitatud töötleja kohustused 3.1. Volitatud töötleja on kohustatud: 3.1.1. tagama lepingueelsete läbirääkimiste ja lepingu täitmise käigus volitajalt ükskõik mis vormis saadud isikuandmete konfidentsiaalsuse ja mitte edastama ega võimaldama sellele teabele juurdepääsu kolmandale isikule ilma volitaja sellekohase selgesõnalise kirjaliku nõusolekuta; 3.1.2. tagama, et lepingu täitmise raames töödeldavaid isikuandmeid ei edastata väljapoole Euroopa Liidu liikmesriikide ja Euroopa Majandusühendusse kuuluvate riikide territooriumi ilma volitaja sellekohase selgesõnalise kirjaliku nõusolekuta; 3.1.3. kasutama ja töötlema isikuandmeid üksnes hankelepingu täitmiseks ja volitaja dokumenteeritud juhiste alusel, välja arvatud juhul, kui volitatud töötleja on kohustatud teavet töötlema volitatud töötleja suhtes kohalduva õiguse alusel. Viimati nimetatud juhul teavitab volitatud töötleja volitajat vastava kohustuse olemasolust enne teabe töötlemist; 3.1.4. võimaldama juurdepääsu isikuandmetele ainult nendele isikutele, kellel on selleks oma tööülesannete täitmiseks vajadus ning tagab, et need isikud on teadlikud ning järgivad isikuandmete töötlemis alaseid nõudeid ja õigusakte, nad on saanud asjakohase koolituse eelmainitud nõuete kohta, on võtnud endale konfidentsiaalsuskohustuse või neile kehtib asjakohane seadusest tulenev konfidentsiaalsuskohustus; 3.1.5. teavitama volitajat toimunud või põhjendatult kahtlustatavast lepingu punktis 3.1.4. sätestatud konfidentsiaalsuskohustuse rikkumisest viivitamatult; 3.1.6. täitma kõiki kehtivaid isikuandmete töötlemisalaseid nõudeid, andmete turvalisust puudutavaid ning isikuandmete kaitse alaseid Euroopa Liidu ja Eesti Vabariigi õigusakte ja muid eeskirju; 3.1.7. rakendama alltoodud organisatsioonilisi, füüsilisi ja infotehnilisi turvameetmeid isikuandmete kaitseks juhusliku või tahtliku volitamata muutmise; juhusliku hävimise ja tahtliku hävitamise eest ning õigustatud isikule andmete kättesaadavuse takistamise eest, volitamata töötlemise, sh avalikustamise eest: 3.1.7.1. vältima kõrvaliste isikute ligipääsu isikuandmete töötlemiseks kasutatavatele seadmetele; 3.1.7.2. ära hoidma andmete omavolilist lugemist, kopeerimist ja muutmist andmetöötlussüsteemis, samuti andmekandjate omavolilist teisaldamist; 3.1.7.3. ära hoidma isikuandmete omavolilist salvestamist, muutmist ja kustutamist ning tagama, et tagantjärele oleks võimalik kindlaks teha, millal, kelle poolt ja milliseid isikuandmeid salvestati, muudeti või kustutati või millal, kelle poolt ja millistele isikuandmetele andmetöötlussüsteemis juurdepääs saadi; 3.1.7.4. tagama, et igal andmetöötlussüsteemi kasutajal oleks juurdepääs ainult temale töötlemiseks lubatud isikuandmetele ja temale lubatud andmetöötluseks; 3.1.7.5. tagama andmete olemasolu isikuandmete edastamise kohta: millal, kellele ja millised isikuandmed edastati, samuti selliste andmete muutusteta säilimise; 3.1.7.6. tagama, et isikuandmete edastamisel andmesidevahenditega ja andmekandjate transportimisel ei toimuks isikuandmete omavolilist lugemist, kopeerimist, muutmist või kustutamist; 3.1.7.7. pidama arvestust isikuandmete töötlemisel kasutatavate tema kontrolli all olevate seadmete ja tarkvara üle, dokumenteerides järgmised andmed: 3.1.7.7.1. seadme nimetus, tüüp ja asukoht ning seadme valmistaja nimi; 3.1.7.7.2. tarkvara nimetus, versioon, valmistaja nimi ja kontaktandmed. 3.1.8. teavitama kirjalikult volitajat turvameetmete rikkumisest, mis põhjustab, on põhjustanud või võib põhjustada töödeldavate isikuandmete juhusliku või ebaseadusliku hävitamise, kaotsimineku, muutmise või loata avalikustamise või neile juurdepääsu viivitamata, kuid mitte hiljem kui kakskümmend neli tundi pärast sellest teada saamist. Juhul, kui rikkumisest teadasaamine langeb nädalavahetusele või riiklikule pühale, kohustub volitatud töötleja volitajat kirjalikult teavitama viivitamatult, kuid mitte hiljem kui nelikümmend kaheksa tundi pärast rikkumisest teada saamist. Kirjeldatud teates tuleb vähemalt: 3.1.8.1. kirjeldada isikuandmetega seotud rikkumise laadi, sealhulgas puudutatud andmesubjektide liike ja arvu ning puudutatud kirjete liike ja arvu; 3.1.8.2. teatada andmekaitsespetsialisti või mõne teise täiendavat teavet andva kontaktisiku nimi ja kontaktandmed; 3.1.8.3. soovitada meetmeid isikuandmetega seotud rikkumise võimalike negatiivsete mõjude leevendamiseks; 3.1.8.4. kirjeldada isikuandmetega seotud rikkumise võimalikke tagajärgi; 3.1.8.5. kirjeldada volitatud töötleja poolt pakutud või võetud meetmeid isikuandmetega seotud rikkumisega tegelemiseks ja 3.1.8.6. esitada muud teavet, mis on mõistlikult nõutav, et volitaja saaks täita kohaldatavaid andmekaitse õigusakte, sealhulgas riigiasutustega seotud teavitamise ja avaldamise kohustusi, näiteks teavet, mis on nõutav andmesubjekti tuvastamiseks. 3.1.9. lõpetama eelnevalt kirjeldatud rikkumised või tegema kõik endast oleneva nende lõpetamiseks ja kohaldama meetmeid isikuandmetega seotud rikkumise lahendamiseks, sealhulgas vajaduse korral rikkumise võimaliku kahjuliku mõju kõrvaldamiseks ja leevendamiseks; 3.1.10. kustutama, niivõrd kui see on võimalik, lepingu lõppemisel kõik tööde teostamise käigus teatavaks saanud isikuandmed ja nimetatute koopiad 30 päeva jooksul, v.a juhul, kui õigusaktidest tuleneb teisiti; 3.1.11. tegema volitajale kättesaadavaks kogu teabe, mida volitaja peab vajalikuks lepingus sätestatud kohustuste täitmise tõendamiseks; 3.1.12. võimaldama volitajal või volitaja poolt määratud audiitoril teha seoses isikuandmete töötlemisega auditeid ja kontrolle ning panustama nendesse. 4. Lõppsätted 4.1. Volitatud töötleja ei või oma lepingujärgseid kohustusi anda üle kolmandale isikule ega kaasata oma lepingujärgsete kohustuste täitmiseks kolmandat isikut. 4.2. Isikuandmete konfidentsiaalsena hoidmise kohustus jääb kehtima ka pärast käesoleva lepingu lõppemist tähtajatult. 4.3. Isikuandmete konfidentsiaalsena hoidmise kohustus ei laiene teabe avaldamisele volitatud töötleja audiitorile ja advokaadile. 4.4. Leping on kehtiv poolte poolt allkirjastamisest kuni hankelepingu järgsete kohustuste täitmiseni, v.a konfidentsiaalsuskohtustus, mis kehtib tähtajatult. 5. Poole allkirjad Volitaja: Volitatud töötleja: /Allkirjastatud digitaalselt/ /Allkirjastatud digitaalselt/ Raamleping nr 3-9/2307-1 SOTSIAALKAITSE VALDKONNA TEENUSTE ARENDUSTÖÖD Osa 2 Tervise ja Heaolu Infosüsteemide Keskus (edaspidi tellija), registrikood 70009770, aadress Uus-Tatari 25, 10134 Tallinn, keda esindab Tervise ja Heaolu Infosüsteemide Keskuse põhimääruse punkt 22 alusel Rasmus Kästik ja AS HELMES (edaspidi täitja), registrikood 10364097, aadress Lõõtsa tn 6 Tallinn 11415, keda esindab juhatuse liige Andres Kaljo, edaspidi nimetatud ka eraldi pool või koos pooled, sõlmisid raamlepingu alljärgnevas: 1. Raamlepingu eesmärk ja ese 1.1. Tellija poolt korraldatud riigihanke „Sotsiaalkaitse valdkonna teenuste arendustööd“ (riigihanke viitenumber 221861) osa 2 alusel sõlmitud raamlepingu eesmärk on kokku leppida, kuidas toimub raamlepingu kehtivuse ajal raamlepingu esemeks olevate tööde tellimiseks hankelepingute sõlmimine tellija ning raamlepingu partneri vahel. 1.2. Raamlepingu esemeks on sotsiaalkaitse infosüsteemi SKAIS2 hallatavate avalike teenuste (v.a pensionite teenusega seonduv) ja nendega seotud tarkvara arendus- ja kasutuselevõtu tööd ning konsultatsioon (edaspidi ka töö või tööd). Tööd hõlmavad muuhulgas: 1.2.1. ärinõuete analüüsi ja kaardistamist koos arendustöö hinnangulise mahuga ning arenduseelse lähteülesande püstitamisega; 1.2.2. arendus- ja juurutustöid koos (automaat)testimistega ning seotud komponentide ühise töökindluse tagamist; 1.2.3. andmemigratsioon; 1.2.4. X-tee liideste arendus infosüsteemide vahel (vt. lisa „Arhitektuuri ülevaade“); 1.2.5. muud töid, mis on vajalikud arendustöö tõrgeteta toimimise tagamiseks. 1.3. Raamleping ei kohusta tellijat töid tellima. 2. Üldtingimused 2.1. Raamlepingu juurde kuuluvateks lahutamatuteks osadeks loetakse kõik lisad ja riigihanke alusdokumendid ning täitja riigihankes esitatud pakkumus, mida raamlepingu lisadena eraldi ei allkirjastata. 2.2. Tööde tellimine ja nende täpne sisu lepitakse kokku raamlepingu alusel sõlmitud hankelepingus. Hankelepingu vorm on leitav raamlepingu lisas. 2.3. Tööde teostamisel lähtutakse lisaks raamlepingule hankelepingu ja seotud lisade tingimustest. Tellija võib teha muudatusi kodukorda, mittefunktsionaalsetesse 1 nõuetesse, nõuetesse infosüsteemi dokumentatsioonile, IT-profiili ja Front-End arendusreeglitesse,1 teavitades täitjat tehtud muudatustest. 2.4. Kui hankelepingus tingimus erineb raamlepingu tingimusest, loetakse ülimuslikuks hankelepingu tingimus. 2.5. Raamlepingu täitmise käigus võib kokku leppida täiendavaid tingimusi, kui need on vajalikud välisvahendite rakendamisest tulenevate nõuete täitmiseks. Selliseid muudatusi ei käsitleta raamlepingu tingimuste muutmisena riigihangete seaduse mõttes. 2.6. Kui hankelepingu alusel teostatavaid töid rahastatakse välisvahenditest, on täitjal kohustus järgida hankelepingus teatavaks tehtud välisvahendite kasutamisest tulenevaid nõudeid, sh kasutada programmi tingimustes nõutud sümboolikat. 2.7. Pooled teevad raamlepingu ja selle alusel sõlmitud hankelepingute täitmiseks ja nende eesmärkide saavutamiseks koostööd. Pooled kohustuvad tegema kõik vajalikud pingutused, et täita hankeleping õigeaegselt ja vastavalt kokkulepetele. 2.8. Täitja kohustub teostama tööd kvaliteetselt ning vastavalt valdkonna headele tavadele ja praktikale. Tellija eeldab, et täitja on tarkvaraarenduse valdkonna professionaal, kes saab aru ning võtab teadlikult enda kanda hankelepingu 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 hankelepingus kokku lepitud, kuid mis oma olemusest lähtuvalt kuuluvad hankelepinguga seotud tööde hulka. Nimetatud tööde tegemine ei kuulu teistsuguse kirjaliku kokkuleppe puudumisel eraldi tasustamisele ning täitja teostab kirjeldatud tööd hankelepingu täitmise raames. 2.9. Tellija ootab täitjalt võimekust leida lahendusi etteantud piirangute kontekstis, pöörates sealjuures tähelepanu nii arendusprotsessi tõhustamisele, arendusmeeskonna tulemuslikkuse pidevale suurendamisele kui ka mõistliku keerukusega tehniliste lahenduste loomisele ja kasutamisele. 2.10. Kui tööde teostamisel tekivad täitja ja tellija vahel erimeelsused, lähtutakse hankelepingu eesmärkidest tellija seisukohalt. 2.11. Poolel on õigus teha teisele poolele ettepanekuid tööde kvaliteedi tõstmiseks. Kui pool on esitanud teisele poolele hankelepingu täitmisega seotud küsimuses päringu, on pool kohustatud sellele sisuliselt reageerima (asjakohast tagasisidet andma) võimalikult kiiresti, kuid hiljemalt 3 tööpäeva jooksul, v.a juhul kui pöördumine nõuab täiendavat analüüsi või info süstematiseerimist. 2.12. Pooltel on kohustus osa võtta töökoosolekutest töö käigus tekkinud probleemide lahendamiseks ja infovahetuseks tellija juures kohapeal või virtuaalselt. 2.13. Tööde teostamise keel on eesti keel, muuhulgas on see ka hankelepingute sõlmimise, töökoosolekute jm suhtluse ning tööde dokumenteerimise keel. 2.14. Tööde dokumentatsioon ja kasutusjuhendid peavad tagama tellijale võimaluse tööde tulemit tulevikus parandada ja arendada, samuti koolitada ja juhendada oma töötajaid tööde kasutamisel. Tööde dokumentatsioon peab olema laetud üles tellija määratud keskkonda. 2.15. Pooled võivad kokkuleppel kaasata tööde kvaliteedi või tööde vastuvõtmise hindamiseks mõlema poole poolt aktsepteeritud sõltumatu eksperdi või audiitori. Kui tellija hinnang tööde kvaliteedile või tööde vastuvõtmisele osutub ekspertiisi tulemusel 1 Vastavate dokumentide, v.a kodukord ja IT-profiil, uusim versioon on kättesaadav: https://wiki.sm.ee/display/AV/Avalik 2 põhjendamatuks, hüvitab tellija ekspertiisikulud. Kui ekspertiis kinnitab tellija hinnangut kvaliteedile või tööde vastuvõtmisele, jäävad ekspertiisikulud täitja kanda. 3. Poolte õigused ja kohustused 3.1. Täitja kohustub: 3.1.1. teostama tööd hankelepingus kokkulepitud tingimustel ja ulatuses, sh tagama tööde õigeaegse alustamise, teostamise, valmimise ja tellijale üleandmise; 3.1.2. tagama hankelepingu täitmiseks vajalike ressursside olemasolu, sh tagama tööde teostajate kõrge professionaalse taseme ning vajaliku tehnoloogia ja metoodikate väga hea tundmise; 3.1.3. omama tööde teostamiseks sobivaid keskkondi, koos kõige sinna juurde kuuluvaga, sh kasutatava tarkvara litsentsid, või kasutama tellija olemasolevaid jagatud keskkondi; 3.1.4. võtma jätkuarenduste puhul litsentsimudeli valikul arvesse tellija varem soetatud tarkvara litsentsitingimusi või juhinduma tellija vajadustest; 3.1.5. tegema koostööd tellija palvel kolmandate osapooltega pidades silmas tellija vajadusi (nt äritellijaga, teised tellija arenduspartnerid jne); 3.1.6. koolitama tellijat tööde valmimise järgselt; 3.1.7. teavitama viivitamatult tellijat tööde teostamist takistavatest asjaoludest, mis segavad hankelepingu nõuetekohast täitmist; 3.1.8. lähtekoodi dokumenteerimisel juhinduma raamlepingu lisast „Lähtekoodi haldus“. 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; 3.1.9. teavitama tööde teostamisel tuvastatud vastuolu korral selle esinemisest viivitamatult tellijat ja juhinduma tellija suunistest hankelepingu eesmärkide saavutamisel, pöördudes juhiste saamiseks või läbirääkimisteks vajadusel tellija poole; 3.1.10. täitma kõiki tellija juures kehtivaid eeskirju (kui need on täitjale teatavaks tehtud) ja õigusaktidest tulenevaid andmekaitsealaseid ja andmete turvalisust puudutavaid nõudeid; 3.1.11. arvestama, et ärinõuete täitmiseks võib olla vajadus muuta ja täiendada olemasolevat koodi ning tagama protsesside ja funktsionaalsuse tervikluse pärast koodi muutmist või täiendamist; 3.1.12. kasutama tööde teostamisel tellija tööajahalduse ja projektijuhtimiskeskkondi, mis on täitjale kättesaadavaks tehtud; 3.1.13. töötunni põhiselt tellitavate tööde puhul esitama tellijale tööde teostamise ajaaruandeid (iga meeskonnaliige isiklikult); 3.1.14. tagama rakenduste hooldusteenuste osutamiseks valmisoleku ja omapoolse abi kuni veaolukorra kõrvaldamiseni vastavalt tehnilises kirjelduses toodud tingimustele, vajadusel ka väljakutse korras kohapeal; 3.1.15. osutama tellijale teostatud töö osas tuge, sh pakkuma konsultatsiooni kuni garantiiaja lõpuni. 3.2. Täitjal on õigus: 3.2.1. saada tööde teostamise eest hankelepingus kokkulepitud ulatuses ja korras tasu; 3 3.2.2. kasutada tööde teostamisel alltöövõtjaid, kooskõlastades alltöövõtjate kasutamise eelnevalt tellijaga. Alltöövõtjate tegevuse ja tegevusetuse eest vastutab tellija ees täitja. 3.3. Tellija kohustub: 3.3.1. tasuma vastu võetud tööde eest hankelepingus kokkulepitud ulatuses ja korras; 3.3.2. tagama tööde teostamiseks täitjale ligipääsu vajalikule teabele ja keskkondadele; 3.3.3. tagama tööde teostamiseks oluliste tellija hallatavate keskkondade olemasolu ja toimimise. 3.4. Tellijal on õigus: 3.4.1. kontrollida igal ajal hankelepingu täitmist ja anda täitjale selleks suuniseid; 3.4.2. keelduda osaliselt või täielikult tasu maksmisest, kui täitja ei teostanud nõuetekohaseid töid kokku lepitud tähtajaks täitja poolne rikkumine ei ole objektiivselt põhjendatud; 3.4.3. kaasata hankelepingu täitmiseks tellija poolel kolmandaid osapooli maksja rollis, nt teisi riigiasutusi (eelkõige Sotsiaalministeeriumi valitsemisala asutused). Kolmanda osapoole selline kaasamine tellija poolt ei ole käsitletav raamlepingu muutmisena riigihangete seaduse mõttes. 4. Raamlepingu hind 4.1. Raamlepingu kehtivuse ajal on ühe töötunni maksimaalne hind käibemaksuta vastavalt pakkumusele 53,47 (viiskümmend kolm eurot ja nelikümmend seitse senti) eurot. Täitjal ei ole lubatud nimetatud hinda tõsta. 4.2. Raamlepingu maht on maksimaalselt 8 000 000 (kaheksa miljonit) eurot ilma käibemaksuta. Mahu täituvusel raamleping lõpeb. 4.3. Täitjal on õigus esitada e-arve pärast tööde aktiga vastu võtmist, kui hankelepingus ei ole kokku lepitud teisiti. Arvel tuleb märkida riigihanke nimetus, raamlepingu ja hankelepingu number ning kontaktisiku andmed.2 4.4. Arve tasumiseks annab täitja minimaalselt tähtaja 21 kalendripäeva alates arve laekumisest. 5. Täitja meeskond 5.1. Täitja tagab pakkumuses esitatud meeskonnaliikmete osalemise tööde teostamisel, v.a juhul, kui täitjast mittesõltuval asjaolul ei ole seda võimalik teha ja meeskonnaliige on asendatud tellija kirjalikku taasesitamist võimaldaval nõusolekul uue hanke tingimustele vastava meeskonnaliikmega. 5.2. Täitja garanteerib riigihankes isikuliselt mitte välja toodud meeskonnaliikmete olemasolu ja vastavuse riigihankes nõutud kvalifikatsioonile/varasemale töökogemusele ning esitab tööde teostajad nimeliselt hankelepingu sõlmimisel. 5.3. Täitja meeskonnaliikme ettevõttest lahkumise, haigestumise jms juhtumite korral asendab täitja konkreetse spetsialisti hiljemalt kahe nädala jooksul. 5.4. Täitja võib lisada täiendavaid riigihanke tingimustele vastavaid meeskonnaliikmeid juhul, kui riigihankes pakkumusega esitatud meeskonnaliikmed on tellitud tööde täitmisega hõivatud. 2 Välisriigi pakkujad võivad esitada arve pdf-vormingus aadressil [email protected], kui e-arve esitamine ei ole võimalik. 4 5.5. Täitja kohustub tellija nõudmisel meeskonnaliikme asendama, kui isik osutub tellija põhjendatud arvamuse kohaselt hankelepingujärgsete ülesannete täitmiseks ebakompetentseks või ebasobivaks või kui tema hankelepingujärgsete ülesannete täitmine kahjustab pidevalt hankelepingu korrektset ja õigeaegset täitmist. Täitja kannab kõik asendusest tulenevad või sellega kaasnevad kulud. 6. Tööde tellimine 6.1. Tööde teostamise aluseks on sõlmitud hankeleping, mille sõlmimiseks pöördub tellija täitja poole tellimusega. Tellimus on täitjale esitatav kirjalik pöördumine tööde teostamiseks. 6.2. Tellija esitab tellimusi vastavalt tegelikule vajadusele ning täitja peab olema valmis võimalike ajaliste pauside tekkimiseks tööde tellimuste esitamise vahepealsel ajal. 6.3. Tellija annab mõistliku aja pakkumuse esitamiseks, arvestades tellitavate tööde keerukust ja pakkumuse esitamiseks vajalikku aega. Pakkumuse esitamisel tuleb järgida kõiki tellimuses esitatud nõudeid. 6.4. Täitja hindab võimalusel tellimuse alusel töö mahu ja esitab tellimuses määratud tähtajaks hinnapakkumuse töö teostamiseks ja/või vajadusel muud tellimuses nõutud andmed (pakkumus). 6.5. Kui pakkumus ei vasta tellimuse tingimustele, lükatakse see tagasi. 6.6. Tellijal on õigus hankelepingu pakkumus tagasi lükata ja otsustada hankelepingut mitte sõlmida või vastavalt raamlepingule esitatud tellimus kehtetuks tunnistada, kui: 6.6.1. pakkumus ei vasta tingimustele; 6.6.2. ületab eeldatavat maksumust või; 6.6.3. tellija ei saa välisvahenditega seotud hankelepingu sõlmimiseks heakskiitu täistaotlusele. 6.7. Kui pakkumus vastab tellimusele ja on tellijale vastuvõetav (nt maksumuse osas), sõlmivad pooled hankelepingu. Tööde teostamine toimub tellimuses fikseeritud tehnilise kirjelduse alusel, milles on määratud tööde sisu ja üle antavad tulemid, tööde maht, ajalised ja eelarvelised piirangud jm olulised tingimused. Tingimused võivad olla fikseeritud etapiti. 6.8. Täitja kohustub hankelepingu allkirjastama hiljemalt 3 tööpäeva jooksul hankelepingu allkirjastamiseks saatmisest. 7. Tööde üleandmine ja vastuvõtmine 7.1. Tööde üleandmise ja vastuvõtmise eritingimused, tööde teostamise etapid ja tähtajad ning tööde testimiseks esitamise tähtajad ja kord ning muud tööde teostamiseks vajalikud kokkulepped fikseeritakse hankelepingus. 7.2. 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, kommenteeritud lähtekood ja intellektuaalomandi õigused. 7.3. Kõik töö tulemused dokumenteeritakse ja hallatakse tellija dokumendihaldus- keskkonnas või/ja koodihalduskeskkonnas (näiteks wiki, gitlab, SVN). 7.4. Üleantavad tööd tuleb täitja poolt enne tellijale üle andmist testida, koostada testiraportid ja testilood. 7.5. Tarnena käsitletakse hankelepingu alusel teostatud töö üleandmist paketina. Tarne kirjeldus ja spetsifikatsioon peab olema täitja poolt lisatud dokumendihalduskeskkonda, konfigureeritud korrektselt toodangusse 5 paigaldamiseks ja lisatud koodihalduskeskkonda. Täitja esitab tarne kohta tarneteatise, lisades tarnega seotud testimise juhendi ja vastavalt hankelepingule automaattestid. 7.6. Täitja annab tööd üle allkirjastatud üleandmise ja vastuvõtmise aktiga (edaspidi akt). 7.7. Tööd loetakse nõuetekohaselt teostatuks, kui tööd vastavad hankelepingule, vastuvõtutestid on vigadeta läbitud ja töö on aktiga tellija poolt vastu võetud. 7.8. Tellija võtab tööd vastu akti allkirjastamisega pärast edukat vastuvõtutestimist kehtivas kodukorras või tehnilises kirjelduses fikseeritud tingimustel. 7.9. Tellija võib tööd vastu võtta, kui töödes esineb üksikuid ja tellija jaoks väheolulisi pisivigasid (vt p 8.4.3), mis fikseeritakse aktis. Tellija poolne pisivigadega tööde vastuvõtmine ei vabasta täitjat kohustusest vead kõrvaldada ning üle anda vigadeta tööd. Tellijal on õigus määrata mõistlik tähtaeg pisivigade parandamiseks. 7.10. Tellijal on õigus keelduda töö vastuvõtmisest, kui töö ei vasta esitatud nõuetele ja/või kvaliteedile või töös esineb muid vigu (vastuvõtutestide tulemus on negatiivne). Vastuvõtmisest keeldumisel koostab tellija aktile vastuse, milles toob välja töödes esinevad vead ja määrab tähtaja nende parandamiseks. 7.11. Kui tellija esitab oma vastuväited töö nõuetekohasusele, peab täitja tegema töös vastavad parandused, muudatused või täiendused tellija poolt määratud mõistliku tähtaja jooksul. Kui täitja ei ole tellija määratud tähtaja jooksul avastatud vigu kõrvaldanud, võib tellija töö ise parandada või lasta seda teha kolmandatel isikutel ja nõuda täitjalt selleks tehtud mõistlike kulutuste hüvitamist. 7.12. 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 tellija 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. 7.13. Kõigi hankelepingujärgsete tööde vastuvõtmise ajaks loetakse viimase akti allkirjastamise aeg või aktis märgitud hilisem kuupäev. 8. Vigadest teavitamine ja veaparanduste teostamine 8.1. Tellija teavitab avastatud rakenduse ja tarkvara vigadest täitjat esimesel võimalusel, tehes kande tööde halduskeskkonda. Tellija registreerib vea, märkides võimalusel vea põhjuse, eeldatava vea parandamise tähtaja ning kriitilisuse (märkides lisaks kui tegemist on garantiilise tööga) ja suunab selle täitjale. 8.2. Täitja võib avastatud vigadest tellijat teavitada, tehes kande tööde halduskeskkonda, st registreerida vea, märkides võimalusel vea põhjuse, eeldatava vea parandamise tähtaja ning kriitilisuse, märkides lisaks, kas tegemist on garantiilise tööga ja suunata selle tellijale. 8.3. Veaparandustööde teostamise aja määrab tellija. 8.4. 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 tellija 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. 6 9. Intellektuaalne omand 9.1. Täitja kinnitab raamlepingu ja selle alusel sõlmitud hankelepingute allkirjastamisega, et talle kuuluvad tööde teostamiseks vajalikud autoriõigused, litsentsid ja muud intellektuaalse omandi õigused, mis on vajalikud tööde teostamiseks ja õiguste loovutamiseks tellijale ning nende suhtes ei ole õigusi ega nõudeid kolmandatel isikutel. 9.2. Tasu intellektuaalse omandi õiguste loovutamise ja litsentsi andmise eest sisaldub hankelepingu täitmise hinnas. 9.3. 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ööde üleandmise hetkest, loobudes sellega hankelepingu alusel üle antud originaalteoste osas õiguste kasutamisest. 9.4. Täitja tagab, et isiklikud õigused on ilma täitja nõusolekuta teostatavad muuhulgas järgnevas ulatuses: 9.4.1. tellijal on õigus tööd kasutada mis tahes eesmärgil ja viisil; 9.4.2. tellijal või tellija tellimusel kolmandatel isikutel on õigus teha üle antud töödes muudatusi ning neid täiendada; 9.4.3. 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; 9.4.4. tööde üleandmisega tellijale kinnitab täitja, et tööd on avaldamiseks valmis. 9.5. Täitja tagab tellijale kõik vajalikud õigused hankelepingu 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. 9.6. Täitja on kohustatud tagama intellektuaalse omandi õiguste olemasolu ja kehtivuse, samuti nende ülemineku tellijale viisil, mis võimaldab tellijal hankelepingu lõppedes üle võtta täitja funktsioonid. 9.7. Täitja kohustub lahendama kõikvõimalikud 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. Kui eeltoodust tekib tellijale rahaline või muu kohustus või juhul, kui tellija on kohustatud lõpetama hankelepingu 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. 9.8. Kõik tellijale kaasnevad otsesed ja kaudsed kahjud, mis tulenevad sellest, et kolmandal isikul on või väidetavalt on varalisi või mittevaralisi intellektuaalsest omandist tulenevaid õigusi hankelepingu alusel üle antavate intellektuaalse omandi objektide suhtes, kannab täitja. 9.9. Selles alapeatükis kirjeldatud õigused ja litsentsid loetakse tellijale lõplikult üle läinuks pärast töö vastuvõtmist. 10. Garantii 10.1. Täitja annab hankelepingu alusel teostatud töödele garantii 12 kuud, mis hakkab kehtima hetkest, mil tellija paneb töö toodangukeskkonda. Kui tellija ei pane 7 tööd toodangukeskkonda 3 kuu möödumisel alates tööde vastuvõtmisest, algab garantii nimetatud aja möödumisel. 10.2. Garantiiga on hõlmatud kõik garantii tähtaja jooksul tarkvaras ilmnevad vead ja mittevastavused kokkulepitule, mis ei ole tekkinud tellija või kolmandate osapoolte tegevuse tagajärjel. Garantiiga on hõlmatud ka kõik töö muudatused ja modifikatsioonid, mis on tehtud täitja poolt ja mis ei ole oluliselt muutnud varasemalt tehtud tööd. 10.3. Täitja on garantii kehtivuse ajal kohustatud kõrvaldama töös avaldunud vead ja hankelepingu tingimustele mittevastavused tasuta, sealhulgas on täitja kohustatud uuendama või asendama veaga seonduva dokumentatsiooni. 10.4. Täitjale peab saama edastada teateid garantiiga hõlmatud vigade ilmnemise kohta vähemalt igal tööpäeval ajavahemikul kell 8:00 kuni 17:00. 10.5. Täitja on kohustatud garantii korras teostama eelkõige järgmist: 10.5.1. vea ilmnemisel vea lokaliseerimine, veaolukorrale lahenduse leidmine ja vea parandamine; 10.5.2. vea põhjuste analüüs ning selle tulemuste kirjalikku taasesitamist võimaldavas vormis (näiteks e-posti teel) esitamine tellijale koos ettepanekutega ennetavate meetmete kasutusele võtmiseks; 10.5.3. vea parandamisega seoses paigaldamise ja seadistamise toe pakkumine, samuti sellega seotud konsultatsioonid; 10.5.4. dokumentatsiooni parandamine või täiendamine, kui selline vajadus tuleneb vea parandamisest. 10.6. Tellija määrab võimalusel, milline on vea kriitilisuse aste ja määrab vea kõrvaldamiseks tähtaja, lähtudes vigade kriitilisuse astmetest. 10.7. Maksimaalsed lahendusajad vigade kriitilisuse alusel: 10.7.1. kriitiline viga (blocker ja critical) - täitja teatab hiljemalt 24 tunni jooksul alates teate saamisest esialgse hinnangu kriitilise vea võimalike põhjuste kohta ning juhtnöörid, kuidas tööd edasi kasutada. Kriitiline viga peab olema kõrvaldatud hiljemalt 3 tööpäeva jooksul alates teate saamisest, kui pooled ei ole kokku leppinud teisiti. 10.7.2. Häiriv viga (major) või pisiviga (minor) - täitja teatab hiljemalt 48 tunni jooksul alates teate saamisest esialgse hinnangu vea võimalik põhjuste kohta ning vajadusel juhtnöörid, kuidas tööd edasi kasutada. Viga peab saama kõrvaldatud hiljemalt 10 tööpäeva jooksul alates teate saamisest, kui pooled ei ole kokku leppinud teisiti. 10.8. Kui täitja tõendab, et kõrvaldatud viga ei olnud garantiiga hõlmatud, hüvitab tellija vea kõrvaldamisega seoses kantud otsesed kulud. Kulude hüvitamisel võetakse aluseks hankelepingus, mille raames teostatud töödes on viga ilmnenud, määratud ühe töötunni hind või raamlepingus määratud maksimaalne töötunni hind. 10.9. Tellija tagab täitjale kaasaabi garantiikohustuse alla käivate vigade kõrvaldamisel tellija võimaluste piires. 10.10. Kui täitja ei suuda vigasid kokkulepitud tähtajaks kõrvaldada, võib tellija need ise kõrvaldada või korraldada nende kõrvaldamise kolmanda isiku kaasabil, teavitades sellest täitjale. Tellijal on õigus täitjalt nõuda kõigi kulutuste hüvitamist, mis tekkisid seoses eelkirjeldatud viisil vea kõrvaldamisega, kui tegemist oli garantiiga hõlmatud vea. 8 10.11. Garantii kaotab kehtivuse, kui tellija muudab täitjaga kooskõlastamata lähtekoodi, välja arvatud tööde osale, mida ei ole muudetud, kui tellija suudab eristada lähtekoodis tehtud muudatusi. 11. Poolte vastutus 11.1. Pool vastutab oma lepinguliste kohustuste rikkumise eest, välja arvatud, kui rikkumine on vabandatav vääramatu jõud või muu objektiivse asjaolu tõttu, mille esinemisest kohustub pool teavitama viivitamatult. Nimetatud asjaolu esinemist peab tõendama pool, kes sellele tugineda soovib. 11.2. Pool vastutab lepinguliste kohustuste rikkumise eest, mis tuleneb tema poolt hankelepingu täitmisse kaasatud isikute tegevusest või tegevusetusest. 11.3. Pool ei vastuta lepinguliste kohustuste rikkumise eest, mis tulenes teise poole kohustuste rikkumisest või kolmandate isikute tegevusest või tegemata jätmistest. Kui tellija viivitab omapoolsete kohustuste täitmisega ja nende kohustuste mittetähtaegne täitmine ei võimalda täitjal omapoolseid kohustusi täita, pikendatakse tööde üleandmise tähtaega vastava aja võrra. Nimetatud asjaolu esinemist peab tõendama pool, kes sellele tugineda soovib. 11.4. Kohustuse rikkumisel on teisel poolel õigus kasutada kõiki seadusest või raamlepingust tulenevaid õiguskaitsevahendeid ja leppetrahvi. Kui rikkumise eest on võimalik kohaldada mitut õiguskaitsevahendit ja/või leppetrahvi, valib õiguskaitsevahendi ja/või leppetrahvi rakendamise tellija. 11.5. Poolte rahaline koguvastutus on piiratud raamlepingu kogumaksumusega, kuid nimetatud piirang ei kehti süülise rikkumise, intellektuaalomandiõiguse või andmekaitsealaste kohustuste rikkumisel. 11.6. Tasu maksmisega viivitamisel on täitjal õigus nõuda viivist võlaõigusseaduses sätestatud määras maksmisele kuuluvast tasust iga tasumisega viivitatud kalendripäeva eest. Viivise maksimaalne määr on 25% tähtaegselt tasumata summast. Viivise nõue tuleb esitada allkirjastatult. 11.7. Täitja poolse lepinguliste kohustuste rikkumisena käsitletakse eeskätt olukorda, kus üle antud tööd ei vasta osaliselt või täielikult hankelepingu tingimustele, sealhulgas kokkulepitud veaparandustööde tingimustele või esineb muid täitja poolseid lepingu rikkumisi. 11.8. Kui täitja rikub lepingulist kohustust, on tellijal õigus nõuda leppetrahvi tasumist, mille suuruseks on 200 eurot iga rikkumises oldud kalendripäeva eest, kuid mitte rohkem kui 25% hankelepingu kogumaksumusest. Kui tööde teostamine on kokku lepitud etappide kaupa, siis mitte rohkem kui 25% etapi kogumaksumusest. 11.9. Kui täitja poolsetest viivitustest tingitult ei ole tööde kasutuselevõtt enam realistlik või vajalik, on tellijal õigus hankelepingust taganeda vastavalt võlaõigusseaduse § 116 lõikele 1 ning täitja on kohustatud tegema juba makstud osa eest tellijale tagasimakse. 11.10. Raamlepingu või hankelepingu olulise rikkumise korral on tellijal õigus esitada täitjale leppetrahvi nõue 10 000 eurot iga rikkumise eest. Täitja poolse olulise rikkumise korral ei pea tellija määrama täitjale lepingu täitmiseks võlaõigusseaduse §- s 114 nimetatud täiendavat tähtaega ning tellijal on muu hulgas õigus leping üles öelda või lepingust taganeda. 11.11. Oluliseks rikkumiseks loevad pooled lisaks võlaõigusseaduses sätestatule muuhulgas: 9 11.11.1. mõjuva põhjuseta hankelepingu sõlmimata või täitmata jätmine; 11.11.2. valeinfo esitamine; 11.11.3. hankelepingu täitmiseks vajalike õiguste (sealhulgas load, litsentsid, intellektuaalse omandi õigused) puudumine; 11.11.4. intellektuaalse omandi õiguste ja nende kasutamise tingimuste rikkumine; 11.11.5. korduv (vähemalt kahel korral) meeskonnaliikme asendamine isikuga, kes ei vasta kokku lepitud nõuetele või meeskonnaliikme asendamine ilma tellija eelneva vähemalt kirjalikku taasesitamist võimaldavas vormis antud nõusolekuta; 11.11.6. konfidentsiaalsuskohustuse rikkumine; 11.11.7. lepingujärgsete kohustuste korduvat (vähemalt kahel korral) täitmata jätmist; 11.11.8. tähtaegselt tööde teostamata jätmist selliselt, et tehnilises kirjelduses sätestatud eesmärgi täitmine ei ole enam tähtaegselt realistik ja/või täitja poolse tegevuse või tegevusetuse tõttu ei ole võimalik enam kasutada hankelepingu rahastamiseks ettenähtud vahendeid; 11.11.9. lepingujärgsete kohustuste üleandmine kolmandale isikule. 11.12. Töö vastuvõtmine tellija poolt ei vabasta ega vähenda täitja vastutust rikkumise eest. 11.13. Leppetrahvi nõude kohustub tellija esitama mõistliku aja jooksul, kuid mitte hiljem kui 3 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. 11.14. Täitja on kohustatud leppetrahvi tasuma 2 nädala jooksul alates tellija poolt vastava nõude esitamisest, kui leppetrahvi nõudes ei ole määratud teisiti. 11.15. Tellijal on õigus tasaarvestada leppetrahvi summa täitjale töö teostamise eest tasumisele kuuluvate maksetega. Tasaarvestamise korral ei rakendata leppetrahvi tasumise kohustust. 12. Konfidentsiaalsuskohustus 12.1. Pooled kohustuvad vastastikku hoidma salajas ja mitte avaldama kolmandatele isikutele ükskõik missugust konfidentsiaalseks peetavat informatsiooni, mis on saadud teiselt poolelt tööde teostamise käigus või muul viisil või juhuslikult. Kolmanda isikuna on käsitletavad kõik, kes otseselt raamlepingu täitmisega seotud ei ole. 12.2. Täitja peab võtma kasutusele isikuandmete ja tellija infosüsteemide kaitseks organisatsioonilisi, füüsilisi ja infotehnilisi turvameetmeid, lähtudes muuhulgas kehtivatest õigusaktidest. Täitja ei tohi töödelda arenduskeskkondades isikustatud andmeid. 12.3. Kui hankelepingu täitmise raames osutub vajalikuks isikuandmete töötlemine, lepivad pooled isikuandmete töötlemise tingimused kokku hankelepingus, juhindudes isikuandmete kaitse üldmääruse3 artiklis 28 kirjeldatust. 12.4. Konfidentsiaalse informatsiooni all mõistavad pooled igasugust informatsiooni (sh ärisaladusi, isikuandmeid, lepingute andmeid, infosüsteeme, turvasüsteemide kirjeldusi, riistvara ja tarkvara kirjeldusi, pakkumuse kirjeldusi, kasutatavaid 3 Euroopa Parlamendi ja Nõukogu määrus nr (EL) 2016/679. 10 tehnoloogiaid, spetsifikatsioone jms), mis on saadud seoses tööde teostamisega ja mille sattumine kolmandate isikute kätte võib pooltele põhjustada turvariske või majanduslikku kahju või kolmandate isikute (eelkõige tellija klientide) eraelu puutumatuse rikkumist. Kahtluse korral eeldatakse informatsiooni konfidentsiaalsust. 12.5. Konfidentsiaalne informatsioon ei hõlma endas informatsiooni, mille avalikustamise kohustus tuleneb õigusaktidest või mille avalikustamiseks pooled on andnud nõusoleku. 12.6. 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 konfidentsiaalsuskohustusest teadlikud ning nõudma neilt kohustuse tingimusteta ja tähtajatut täitmist. Vastutus konfidentsiaalsuskohustuste täitmise eest lasub täitjal. 12.7. Pooled ei tohi kasutada raamlepingu täitmisel neile teatavaks saanud konfidentsiaalset informatsiooni oma huvides ega muul eesmärgil, kui tellitud tööde teostamiseks. 12.8. Konfidentsiaalsuskohustus kehtib tähtajatult, sõltumata raam- ja hankelepingute kehtivusest. 12.9. Täitja on teadlik, et raam- ja hankelepingud on avalikud, v.a osades, mis on avaliku teabe seadusest tulenevatel alustel määratud asutusesiseseks kasutamiseks või märgitud täitja poolt ärisaladuseks. 12.10. Konfidentsiaalsuskohustuse rikkumisel kohustub täitja hüvitama kogu kahju, mis sellise rikkumise tagajärjel tellijale või kolmandale isikule tekkis, sõltumata sellest, kas rikkumine pandi toime raam- või hankelepingu kehtivuse ajal või lepinguliste kohustuste lõppemise järgselt. 13. Raamlepingu kehtivus, muutmine ja lõpetamine 13.1. Raamleping jõustub sõlmimisel ja kehtib 48 kuud või kuni raamlepingu mahu täitumiseni või raamlepingu lõpetamiseni. Hankelepingud tuleb sõlmida raamlepingu kehtivuse ajal, kuid võivad kehtida kauem. 13.2. Tellija võib raamlepingu igal ajal ühepoolselt üles öelda, teatades täitjale 60 päeva ette. Raamlepingu ülesütlemine ei muuda automaatselt kehtetuks selle alusel varem sõlmitud hankelepinguid. 13.3. Tellijal on õigus raamleping ühepoolselt etteteatamistähtaega järgimata üles öelda, kui täitja on oluliselt raamlepingut rikkunud või juhul, kui täitja: 13.3.1. suhtes on algatatud pankrotimenetlus; 13.3.2. pankrot on välja kuulutatud; 13.3.3. täitja varad arestitakse; 13.3.4. täitja finantsseisund halveneb tellija põhjendatud hinnangul oluliselt ja see muudab raam- või hankelepingute nõuetekohase täitmise vähetõenäoliseks. 14. Teadete edastamine ja kontaktisikud 14.1. Teadete edastamine toimub üldjuhul e-posti teel, lähtudes kehtivast kodukorrast. Kui teate edastamisel on olulised õiguslikud tagajärjed, peab teade olema edastatud allkirjastatult poole allkirjaõigusliku isiku poolt. 14.2. Kirjalik teade loetakse poole poolt kättesaaduks, kui see on üle antud allkirja vastu või kui teade on saadetud postiasutuse poolt tähitud kirjaga poole poolt teatatud 11 aadressil ja postitamisest on möödunud 5 kalendripäeva. E-posti teel, sh digitaalselt allkirjastatud dokumentide saatmisel loetakse teade kättesaaduks kohale jõudmise teates märgitud kellaajal või e-kirjas näidatud saatmise kellaajal. 14.3. Tellija kontaktisikud on: 14.3.1. Tuuli Pentjärv, telefon 5115410, e-post: [email protected] 14.3.2. Saskia Estudillo, telefon 53972266, e-post: [email protected] 14.3.3. Marili Markus, telefon 54536702, e-post: [email protected] 14.4. Täitja kontaktisik on: Eliis Väert, telefon 5021150, e-post: [email protected]. 14.5. Kontaktisikute pädevuses on anda teisele poolele vajaliku informatsiooni ja juhiseid töö teostamiseks, kontrollida teostatud töö kvaliteeti, anda töö üle ja võtta töö vastu ning allkirjastada akt. 14.6. Kontaktisiku muutumisest teavitab pool kirjalikult teist poolt viivitamatult. 15. Lõppsätted 15.1. Raamlepingu alusel sõlmitud hankelepingutele kohalduvad raamlepingu tingimused, olenemata raamlepingu kehtivusest. 15.2. Täitjal ei ole õigust raamlepingut või sellest tulenevaid kohustusi kolmandatele isikutele üle anda, välja arvatud tellija kirjalikku taasesitamist võimaldaval nõusolekul riigihangete seaduses ette nähtud alustel. Kolmas isik on mistahes füüsiline või juriidiline isik, kes ei ole selle raamlepingu pooleks. 15.3. Raamlepingut muudetakse poolte vahelise kokkuleppega raamlepinguga samas vormis. 15.4. Täitjal puudub volitus tegeleda raamlepingu osas avalike suhetega ning anda teateid pressile, elektroonilisele meediale, üldsusele või teistele auditooriumidele, välja arvatud tellija eelneval kirjalikku taasesitamist võimaldaval nõusolekul. 15.5. Raamlepinguga seotud vaidlused, mida pooled ei ole suutnud läbirääkimiste teel lahendada, antakse lahendamiseks Harju Maakohtule. Raamlepingule kohaldub Eesti õigus. 15.6. Kui raamlepingu mõni tingimus on vastuolus Eesti Vabariigis kehtivate õigusaktidega, jätavad pooled võimalusel selle tingimuse kohaldamata ja see ei mõjuta ülejäänud raamlepingu kehtivust. 16. Lisad 16.1. Lisa 1 – Arhitektuuri ülevaade; 16.2. Lisa 2 – Mittefunktsionaalsed nõuded; 16.3. Lisa 3 – Nõuded infosüsteemi dokumentatsioonile; 16.4. Lisa 4 – Front-end arendusreeglid; 16.5. Lisa 5 – Tehniline kirjeldus; 16.6. Lisa 6 - Lähtekoodi haldus; 16.7. Lisa 7 – IT-profiil; 16.8. Lisa 8 – Kodukord; 16.9. Lisa 9 – Nõuded pakkuja meeskonnale; 16.10. Lisa 10 – Hankelepingu projekt; 16.11. Lisa 11 – Isikuandmete töötlemise tingimused. 12 17. Poolte allkirjad Tellija: Täitja: (allkirjastatud digitaalselt) (allkirjastatud digitaalselt) 13 Arhitektuuri ülevaade (as is 2020.01) Sisukord  Sisukord  Sissejuhatus  Süsteemi taust  Paigaldusvaade  Rajadokument  Süsteemi arhitektuuris kasutatavad tehnoloogiad  Tehnoloogia maatriks Sissejuhatus Antud dokument kirjeldab SKAIS2-s juba valminud infosüsteemi arhitektuuri, sisaldades antud süsteemi komponentide kirjeldust, omavahelist suhestumist, paigaldusvaadet ning kirjeldust loodava süsteemi ning teda ümbritsevate keskkondade vahel. Süsteemi taust Sotsiaalkindlustusameti infosüsteem (SKAIS) on riigi infosüsteemi kuuluv andmekogu, mida peetakse seadustest tulenevate Sotsiaalkindlustusameti avalike ülesannete täitmise eesmärgil. Täna kasutusel olev SKAIS koosneb tehniliselt neljast infosüsteemist - SKAIS1,SKAIS2, AVE ja EBS. SKAIS1 on 1999. aastast kasutusel olev infosüsteem, mis toetab hüvitiste arvutamist ja rahaliste väljamaksete teostamist, mida saavad kasutada ainult ametnikud. Teatud e- teenused on isikutele kättesaadavad eesti.ee portaalis. SKAIS2 on kasutusel 2017.a algusest. Erinevalt SKAIS1-st peab SKAIS2 võimaldama inimestel ja SKA partneritel kasutada SKA teenuseid üleveebi ja iseteeninduskeskkonna kaudu, sh kasutades nutiseadmeid. Mõlemas infosüsteemis toimub hüvitiste ja toetuste menetlemine ning väljamaksmine. Praeguseks on välja arendatud SKAIS2-te elatisabi ning riigile üle läinud elatisnõuete sissenõudmise, puude raskusastme ja puudest tulenevate lisakulude ning püsiva töövõimetuse tuvastamise funktsionaalsus. Osaliselt ka perehüvitise teenus. SKAIS2 on liidestatud erinevate üleriigiliste infosüsteemidega. Süsteemis on 1,6 miljoni isiku andmed. Paigaldusvaade Kirjeldamaks süsteemi komponentide paigaldust ning omavahelist suhtlust. Infosüsteem on laias laastus jagatud kaheks: sisevõrgus paiknevad süsteemi osad ja välisvõrgust otse ligipääsetavad süsteemi osad (turvalisusest tulenev nõue). Välisvõrgus asub Avalik portaal, mis suhtleb sisevõrgus olevate komponentidega üle standardsete protokollide. Ligipääs sisevõrgus olevatele komponentidele on määratud välisvõrgus asuva serveri(te) IP aadressi(de) näol. Rakendusserveritele (Apache Tomcat) paigaldatud komponendid (Avalik portaal ja Ametniku portaal) on paljundatavad (sessiooni jaotamine: sticky-session 2017 loodud ametnikurakendus, jwt-token - 2019 iseteenindus). Süsteem võimaldab lisada N arv lisa servereid, koormust juhib rakendusserverite ette paigaldatud koormusjaotur apache mod proxy. Andmebaasi ühendusi haldab rakendustel Connection Pool. Infosüsteem töötab UTF8 kodeeringus. Süsteem on paigaldatud kahte erinevasse serveriruumi (active/passive site), kus ainult üks andmebaas on aktiivses olekus. Klasterdatud Java rakendustel on aktiivset 2 õlga (node), mis on paigutad erinevatesse serveriruumidesse (st. 1 õlg serveriruumi peale). Ametniku portaal – Sotsiaalkindlustusameti ametnikele mõeldud veebirakendus. Komposiit - ajutine veebirakendus, mis pakendab endas erinevate valdkondade mikroteenuseid (isik, pakkumus, otsus/hüvitis, perehüvitis, parameeter, teated jne). Asendatakse iga käivitatavate jar'idega. Iseteeninduse portaal – Avalik veebirakendus, mis sisaldab teenuseosutaja portaali ja iseteenindust. Iseteeninduse kasutajad on füüsilised või juriidilised isikud, kes tarbivad SKA teenuseid. Teenuseosutaja portaali kasutajaks on juriidilised isikud, kes on SKA-ga sõlminud halduslepingu sotsiaalteenuste osutamiseks. Protsessimootor - kasutuses eraldiseisva protsessina (jar) virtuaalmasinas täitmaks süsteemis defineeritud ja järjekorda seatud taustaprotsesse. Võimalus on paigaldada jõudluse tõstmiseks mitu protsessimootorit. Dokumendi generaator- vahend (Oracle BI publisher) menetlusprotsesside käigus koostatavate dokumentide jaoks eri keeltes dokumendipõhjade koostamiseks ja automaatseks eri formaadis (doc, pdf, xls, rtf jne.) dokumentide genereerimiseks. Liidestatakse teiste süsteemidega kasutades Oracle BI Publisher Java Integration API'si. X-tee turvaserver – X-tee liidestus. Installeeritud vastavalt turvaserveri installeerimisjuhendile: http://x-road.ee/docs/est/turvaserveri_kasutusjuhend.pdf. HSM - (hardware security module) riistvaraline turvamoodul PKI infrastruktuuris turvaliselt saladuste krüpteerimiseks ja signatuuride kinnitamiseks. X-tee teenusepakkuja - Installeeritud eraldiseisvana virtuaalmasinasse (Apache + Tomcat). Vahendab SKAIS2 pakutavaid x-tee teenuseid välistele süsteemidele. Liidestus X-Tee turvaserveriga, pakub andmeid. "Tuum" Andmebaas – Oracle Database 12c Enterprise Edition, hoitakse ja töödeldakse kogu SKAIS2 andmestikku. Kasutusel 3 schemat (skais2, skais2sys, skais2valine) Failihoidla – Oracle Database 12c Enterprise Editon hoidmaks dokumendigeneraatori poolt loodud, süsteemi kasutajate poolt üleslaetud ja protsessi mootori poolt loodud dokumente. Dokumentide arhivaator – Daemon komponent (jar) operatiivbaasi salvestatud dokumentide liigutamiseks failihoidlasse. Digitembeldaja – Daemon komponent (jar) dokumentide (otsused jne) digitaalselt allkirjastamiseks. Sisend tembeldamiseks andmebaasis olevast sisend/väljund queuest (Oracle AQ), väljund/sisend failide näol failihoidlasse EBS - Oracle eBusiness Suite paigaldatuna eraldi serverile. Haldab/töötleb SKAIS2 raamatupidamisinfot (maksed panka või muudesse maksekanalitesse (Omniva), pangast tagasiside jne). ERPi taga on erinevad liidestused pankadega, mida joonisel pole eraldi välja toodud. SKAIS2 integratsioon ERPiga on tehtud läbi vahetabelite. SKAIS2 lisab read tabelitesse, kus ERP need üles korjab. Pärast tagasisidet pangast kirjutab ERP read tabelisse, kus SKAIS2 need üles korjab ja oma ärilistesse tabelitesse laiali salvestab. Skais1fassaad – SKAIS1 andmebaasist andmete pärimiseks loodud rakendus. Abivahendid - abivahendite äridomeeni mikroteenus Abivahendite xtee pakkuja - serveerib abivahendite Xtee teenuseid turvaserverile Ave-migraator - ajutine rakendus abivahendite kasutuses olevast vanast süsteemist (AVE) andmete perioodiliselt SKAIS2 baasi sünkroniseerimiseks. Rajadokument "Tuum" Andmebaas  Oracle Database 12c Enterprise Edition. Iseteenindus portaal  Sotsiaalkindlustusameti klientidele mõeldud veebirakendus, sealhulgas teenuseosutajad.  Tüüp: avalikke teenuseid pakkuv veebilehekülg  Kasutatud protokoll: avalik veebileht,https  Käideldavus: klastrisse ja koormusjaoturi taha paigaldatud virtualiseeritud masinad. Ametniku portaal  Sotsiaalkindlustusameti ametnikele mõeldud veebirakendus  Tüüp: avalikke teenuseid pakkuv veebilehekülg  Kasutatud protokoll: sisevõrgu veebileht,https  Käideldavus: klastrisse ja koormusjaoturi taha paigaldatud virtualiseeritud masinad. Protsessimootor  kasutuses Ametniku portaalis, Avalikus portaalis kui ka eraldiseisva protsessina virtuaalmasinas täitmaks süsteemis defineeritud ja järjekorda seatud taustaprotsesse või üle Oracle AQ saabunud sõnumeid. Töötab eraldiseisva(te) protsessi(de)na deemon protsesside jooksutamiseks.  Tüüp: sünkroonne ja asünkroonne teenus; süsteemne taustprotsess  Kasutatud protokoll: integreeritud süsteemi osa Digitembeldaja  Daemon protsess, digitembeldab etteantud faile, lisab failid failihoidlasse. Sisemiselt kasutab digitembeldamise APIt. Signeerimiseks kasutab majutuskohas olevat võrgu HSM seadet.  Tüüp: Daemon protsess  Kasutatud protokoll: jdbc; https; PKCS11 Failihoidla  Süsteem (Andmebaas, Java API) hoidmaks dokumendi generaatori poolt loodud, süsteemi kasutajate poolt üleslaetud ja protsessi mootori poolt loodud dokumente. Paigaldatuna eraldiseisvasse virtuaalmasinasse.  Tüüp: Teenus (API), Andmebaas Dokumendi generaator  Vahend menetlusprotsesside käigus koostatavate dokumentide jaoks eri keeltes dokumendipõhjade koostamiseks ja automaatseks eri formaadis (doc, pdf, xls, rtf jne.) dokumentide genereerimiseks. Liidestatakse teiste süsteemidega kasutades Oracle BI Publisher Java Integration API'si.  Tüüp: sünkroonsed teenused API tarbijatele, veebileht administreerimiseks  Vastaspool: liidese tarbijaks on Avalik portaal, Ametniku portaal ja protsessimootor.  Kasutatud protokoll: Oracle BI Publisheri põhine, ühenduse hoidmiseks kasutatakse Oracle poolt pakutud APIt. Port millelt ühendus luuakse, konfigureeritav süsteemis  Lisa: Rakendus vajab oma repositooriumi hoidmiseks andmebaasi. EBS  Oracle eBusiness Suite paigaldatuna eraldi serverile. Haldab/töötleb SKAIS2 raamatupidamisinfot (maksed panka või muudesse maksekanalitesse (Omniva), pangast tagasiside jne). ERPi taga on erinevad liidestused pankadega, mida joonisel pole eraldi välja toodud. SKAIS2 integratsioon ERPiga on tehtud läbi vahetabelite. SKAIS2 lisab read tabelitesse, kus ERP need üles korjab. Pärast tagasisidet pangast kirjutab ERP read tabelisse, kus SKAIS2 need üles korjab ja oma ärilistesse tabelitesse laiali salvestab. Turvaserver  X-tee turvaserver, vajalik X-teel andmete vahetamiseks.  Kasutatud protokoll: SOAP Dokumentide arhiveerija  Daemon protsess, eesmärgiga arhiveerida operatiivbaasi salvestatud dokumente failihoidlasse.  Tüüp: Deemon protsess  Kasutatud protokoll: jdbc SSO (Keycloak)  Autentimislahendus, liidestatud RIA TARA keskkonnaga, et pakkuda ID, Mobiil- ID ja SMART-ID sisselogimist  karbitoode: https://www.keycloak.org/ Sertifitseerimiskeskus  digiallkirjade kehtivuskinnitus  Tüüp: sünkroonne teenus Pank  Väljamaksete edastamine panka  Tüüp: asünkroonne gateway  Kasutatud protokoll: SOAP X-tee  Erinevate andmekogudega suhtlus  SKAIS2 poolt pakutavad teenused: Teenus Selgitus Teenus väljastab kohtutäituritele täitemenetluse aegse elatisabi maksekorralduste staatused. Info selle kohta, kas Sotsiaalkindlustusamet on EAFmakseraport maksekorralduse põhjal väljamakse teinud. Või tagastab veateated, miks maksekorraldust ei ole võimalik täita. Teenus võtab vastu kohtutäituritelt täitemenetluse EAFmakseteatised aegse elatisabi maksekorraldused. Teenus väljastab Töötukassale päritava isiku kohta info, milliseid hüvitisi ja töövõimetusi on määratud isikule TKToovoimPuueHyvitised Sotsiaalkindlustusametis. Lisaks väljastatakse ka rahaliste väljamaksete, kinnipidamiste ja tulumaksu info. Teenus võtab vastu Töötukassast isikukoodide TKToovoimPuueHyvitisedMassTeenus loetelu, kelle kohta Töötukassa soovib hüvitiste infot. Teenus väljastab Töötukassale päritavate isikute kohta info, TKToovoimPuueHyvitisedMassTeenusVastus milliseid hüvitisi ja töövõimetusi on määratud isikule Sotsiaalkindlustusametis. Teenus võtab vastu TVHTaotlusYksUks Töötukassast puude määramise taotluse andmed. Teenus väljastab postiettevõttele rahaliste courierDelivery hüvitiste posti teel kojukandega väljamaksete info. Teenus väljastab postiettevõttele tühistatud courierDeliveryAnnulation rahaliste hüvitiste väljamaksete info. Teenus võtab vastu postiettevõttelt teostatud courierDeliveryReply kojukande väljamaksete info. Kas postiettevõttel õnnestus raha kliendile viia või mitte. Teenus väljastab kohalikele omavalitsustele päritava isiku kohta info, milliseid hüvitisi on star1Tulud isikule määratud Sotsiaalkindlustusameti poolt. Millised on olnud hüvitiste väljamaksed ja kinnipidamised. Teenus väljastab Tallinna LV-le tlvIsikuPuudeInfo päritava isiku kohta info, mis liiki puue on isikule määratud.  SKAIS2 poolt tarbitavad teenused: Andmekogu Teenus Selgitus Kinnipeetava KIR AnnaArvelolekuAndmed arveloleku andmed Muudetud LeiaMuudetudAndmetegaKinnipeetav KIR andmetega ad kinnipeetavad IK alusel isiku Rahvastikuregist RR456 andmed ja kõik er suhted ja hooldus Isikuandmete Rahvastikuregist muudatuste päring RR67_muutus er edastatud ajavahemiku järgi PKR STAR1_TULUD STAR tulude päring Töötamise TOR TORIK informatsiooni küsimine TÖR-ist Eesti töötukassa töövõime hindamise ja puude TKIS EkspertiisArvamusV1 raskusastme tuvastamise ekspertii si andmeid välistele asutustele Töövõime hindamise ja TKIS TVHOtsusV1 puuderaskusastme tuvastamis otsus Töövõime hindamise ja puude TKIS TVHTaotlusNimekiriV1 raskusastme tuvastamise taotluste nimekiri Töövõime hindamise ja puude TKIS TVHYhisTaotlus raskusastme tuvastamise taotluse SAP SAP finantskandeImport finantskandeimpordi päring Isiku kindlustatuse KIRST kindlustatus kontrolli päring Äriregister lihtandmed_v1 Lihtandmete päring Ettevõtja lihtandmete Äriregister paringliht_v5 päring Õppuri andmed EHIS sotsList1 peretoetuste jaoks Õppurite andmed EHIS sotsList2 toitjakaotuspensionid e jaoks EHIS sotsOppur1 Õppuri andmed  Tüüp: sünkroonne  Kasutatud protokoll: SOAP Süsteemi arhitektuuris kasutatavad tehnoloogiad Apache HTTP Server Versioon: 2.4. Konfiguratsioon ja nõuded: SSL, ID-Kaardi sertifikaadi tuvastamine (ssl konfiguratsioon), koormusjaotur (mod_proxy_balancer), sticky session. Operatsioonisüsteem: RedHat / CentOS. Apache Tomcat Versioon: 9.x Konfiguratsioon ja nõuded: klusterdamine Tomcat rakendusserverite tasemel(SimpleTcpCluster). Operatsioonisüsteem: RedHat / CentOS Oracle BI Publisher Versioon: Oracle Business Intelligence (11.1.1.x). Konfiguratsioon ja nõuded: Repositoorium Oracle XE 11g; rakendusserver: Oracle WebLogic(kaasas by default installatsiooni paketis). Operatsioonisüsteem: Oracle Linux Oracle 12c EE Versioon: Oracle Database 12c Enterprise Edition 12.1.0x. Konfiguratsioon ja nõuded: klasterdatud andmebaas. Operatsioonisüsteem: RedHat / CentOS. Oracle Database Advanced Queuing - kasutatakse erinevate komponentide vahel asünkroonseks suhtluseks. Tehnoloogia maatriks SSO Apach Jav Oracl (oauth) Jav SOA e PostgreS Märku Rakendus a e 12c a8 P Tomc ql 9.x s 10+ EE (Keycloa at 9 k) Ametniku portaal x x x x x Komposiit x x Dokumentide x x digitembeldaja Dokumentide x x arhivaator Xtee teenuspakkuja x x x x (sisenevad) Protsessimootor x x x Abivahendid x x x Abivahendid Xtee x x x pakkuja Avemigraator x x x x Xtee turvaserver x Failihoidla x Andmebaas (ametnik/iseteenind x us) Sotsiaalkaitse infosüsteem Mittefunktsionaalsed nõuded Raamlepingu lisa 2 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ähtuda põhidokumendis kirjeldatust. Põhidokumendis viidatud Sotsiaalministeeriumi poolt koostatud dokumentide ja kolmandate osapoolte poolt koostatud dokumentide erisuste puhul tuleb 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õu Koostamise eest de Nõude sisu Seletused vastutaja nr. 1. Vastavus üldistele standarditele Lahendus peab olema kooskõlas riigi IT https://www.mkm.ee/sites/default/files/riigi_it_koosvoime_raamistik 1.1 Arendaja koosvõime raamistiku nõuetega. .pdf Lahenduse X-tee teenused peavad 1.2 https://www.ria.ee/ee/xtee-juhendid.html Arendaja vastama RIA nõuetele. Lahendus peab vastama 1.3 Arendaja Sotsiaalministeeriumi IT-profiilile. Rakendus peab olema kirjutatud SKAIS2 ISKE turvaklass on K2T2S2. arvestades selle rakenduse poolt 1.4 Arendaja töödeldavatele andmetele määratud https://www.ria.ee/ee/iske-kkk.html ISKE turvaklassi nõudeid. Lahendus peab vastama veebide 1.5 https://www.mkm.ee/sites/default/files/veebide_raamistik.pdf Arendaja koosvõime raamistikule. Veebirakenduse kasutajaliides peab 1.6 vastama vähemalt WCAG 2.0 tasemele http://www.w3.org/TR/WCAG20/ Arendaja AA. Valideerimiseks kasutatakse vastavaid validaatoreid: http://validator.w3.org/ Kui on tegu olemasoleva süsteemi edasiarendusega, siis tuleb järgida olemasolevat HTML ja CSS versiooni. HTML valideerimisel arvestatakse sellega, et SKAIS infosüsteemides kasutusel olev Angular javascript raamistik lisab HTML atribuute, mis ei vasta HTML5 standardile. Sellest lähtuvalt Veebipõhine kasutajaliides peab eristatakse HTML valideerimisel Angular – ja HTML spetsiifilisi 1.7 ühilduma täielikult standarditega HTML vigasid. Angular spetsiifilised HTML valideerumise vead ei kuulu Arendaja 5 ja CSS 3 parandamisele. Valideerimise tulemustest parema ülevaate saamiseks saab kasutada w3 validaatori filtreerimis funktsionaalsusi. CSS valideerimisel võetakse aluseks profiil CSS level 3 + SVG, brauseri tootjate spetsiifiliste (vendor prefix) css reegleid käsitletakse kui hoiatusi ja nende kasutamine on aktsepteeritav. Kui tekib vajadus vanemate brauserite toetamiseks kasutada mitte valideeruvat CSS-i siis selles lepitakse eraldi kokku. ID-kaardiga allkirjastamisel on Arendaja loodud lahenduse dokumentatsioonis (nt detailanalüüs 1.8 eelistatud veebipõhine digidoc-teenuste vms) peab olema välja toodud digidoc-teekide versioonid ja Arendaja kasutamine. kasutuskohad. Kui pole arenduse eraldi kokku lepitud teisiti, siis on OWASP ASVS 3.0 tasemeks 2 (https://www.owasp.org/index.php/Category: OWASP_Application_Security_Verification_Standard_Project). Veebirakendus peab probleemideta Kinnise lähtekoodiga kommertstoote kasutamisel ei eeldata 1.9 läbima OWASP ASVS baasil põhineva ligipääsu kinnisele lähtekoodile. Tellija poolset turvatestimist Arendaja testi. 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. Krüptoalgoritmide ja räsifunktsioonide kasutamisel tuleb järgida uusimat RIA Arendaja loodud lahenduse dokumentatsioonis (nt detailanalüüs kodulehel avaldatud krüptograafiliste vms) tuleb välja tuua kasutatavad krüpto- ja räsialgoritmid, nende algoritmide kasutusvaldkondade ja 1.10 võtmepikkused, kasutuskohad, sh SSL sertifikaatide kasutuskohad. Arendaja elutsükli uuringut, st lahendustes ei tohi Värskeima uuringu leiab aadressilt https://www.ria.ee/ee/iske- kasutada uuringus väljatoodud dokumendid.html ebaturvalisi algoritme ja võtmepikkuseid. Andmete edastus peab välisvõrgu liikluses olema kaitstud kasutades 1.11 Arendaja turvalisi ja üldteada andmeedastusprotokolle. Infosüsteem peab kasutama serveri 1.12 Arendaja kellaaega ja ajatsooni. Süsteemi edasiarendamisel/loomisel peab arvestama selle võimaliku 1.13 Arendaja laiendamisega nii andmemahtude, kui ka kasutajate arvu osas. Rakendus peab olema tehniliselt Näiteks, kui rakendusel on eraldi turvakontekstidega liidesed tükeldatud vastavalt loogilisele ametnikule ja kodanikule, peab rakendus olema jagatav kaheks 1.14 Arendaja jaotusele. Saadud osised peavad olema eraldi liidesekomponendiks ning nende mõlema poolt kasutatavaks eraldi versioneeritavad ja paigaldatavad. andmebaasiks. Avalike e-teenuste loomisel peab https://www.valitsus.ee/et/eesmargid-tegevused/valitsusasutuste- 1.15 arvestama valitsusasutusele kehtestatud Arendaja visuaalse-identiteedi-stiilijuhis visuaalse identiteedi stiilijuhisega. https://www.mkm.ee/sites/default/files/iseteeninduskeskkondade_ra Avalike e-teenuste loomisel peab amistik_08.07.2015.pdf 1.16 arvestama valitsusasutustele kehtestatud Arendaja iseteeninduskeskkonna raamistikuga. https://www.mkm.ee/sites/default/files/iseteeninduskeskkondade_ra amistiku_kasutatavuse_nouded_dets.pdf 2. Nõuded rakenduse arhitektuurile Arendaja loodud lahenduse dokumentatsioonis (nt detailanalüüs Rakenduse, andmebaasi ja kolmanda vms) peab olema välja toodud kasutatavate komponentide nimetused osapoole komponentid peavad olema 2.1 ja versioonid. Versiooni eluea lõppu ei loeta võrdseks terve Arendaja sellised, mille eluea lõpp (EOL) pole komponendi eluea lõpuks, st versiooni tugi võib aeguda, kui uus teadaolevalt vähem kui 2 aasta pärast. versioon on välja lastud. Tulevase ja olemasolevate infosüsteemide platvormid (rakendusserver, andmebaas, kolmanda Süsteemi jõudlus peab vastama kokkulepitud topoloogial eelanalüüsi 2.2 osapoole komponendid) ja topoloogia Arendaja ja lähteülesande käigus välja toodud jõudlusnäitajatele. peab olema enne reaalse arenduse algust infosüsteemide halduse osakonna juhiga kooskõlastatud. Rakendusserver peab võimaldama 2.3 töötamist andmebaasiserverist eraldi - Arendaja serveril. Rakendusserver peab olema vajadusel klasterdatav aktiivklastris 2.4 - Arendaja (kasutajasessioon ei tohi olla klastri node põhine). Rakendust peab saama ilma ümberprogrammeerimata liigutada 2.5 Lahendus ei tohi olla sisse kompileeritud absoluutseid URI-sid Arendaja erinevate domeenide ja domeeni saitide vahel. Väliste liidestatud süsteemide tõrke korral ei tohi süsteem hanguda, Rakenduse liidesed peavad olema vaid väljastama mõistliku (võimalikult lühikese) aja jooksul 2.6 tõrkekindlad kolmandate osapoolte Arendaja ajakohase veateate. Võimalusel tuleb kasutada asünkroonseid süsteemide vigade suhtes. liideseid. Rakendus peab neid sealt ka kasutama (mitte kopeerima parameetreid käivitamisel kolmandatesse kohtadesse), logimise seaded võivad olla rakenduse konfiguratsioonifailist eraldi ühes Rakenduse konfiguratsiooniparameetrid lisakonfiguratsioonifailis (näit Log4net). Samuti on väga soovitatav tuleb ühte kohta kokku tuua nii, et nende eraldi konfiguratsioonifailis hoida arendaja ja administraatori muutmisel ei peaks rakendust uuesti 2.7 vastutusala parameetrid. Infosüsteem peab olema seadistatav Arendaja kokku kompileerima (nt ühte konfiguratsiooniparameetrite(de) abil. Konfiguratsioonifailiks ei saa tekstipõhisesse konfiguratsioonifaili, lugeda faili, kus hoitakse lisaks konfiguratsioonile ka muud andmebaasi tabelisse). programmikoodi. Rakenduse kompileerimine < 10min Rakenduse kompileerimine, saidi Mooduli taaskäivitus < 1min taaskäivitus ja konfiguratsiooni Konfiguratsiooni muutmine < 30s 2.8 Arendaja muutmine peavad toimuma mõistliku aja jooksul. Kui rakendus vajab indekseeritud sisu ja see pole kättesaadav, siis peab rakendus väljastama selle kohta selge teate Rakendus peab kasutama 64-bitist 2.9 arvutiarhitektuuri kui ei ole kokku Suund on 64-bitiste rakenduste op süsteemide kasutamise poole. Arendaja lepitud teisiti. Kõik andmed, andmebaasid, SQL 2.10 skriptid ja rakendus peavad kasutama - Arendaja UTF-8 kodeeringut. Failisüsteemi salvestamisel ei tohi ühte Failid peab katalogiseerima kokkulepitud tunnuste alusel (nt aasta, 2.11 Arendaja kausta tekkida üle 10000 faili. kuu, kuupäev). Rakenduse loomisel tuleb eelistada Eelistuse eiramine tuleb kooskõlastada projektijuhiga enne 2.12 Arendaja objektorienteeritud mudelit. arendamise alustamist. Ühest andmetabelist teise viitamisel 2.13 tuleb kasutada väliseid võtmeid (Foreign - Arendaja key). Andmebaasis peab kasutama indekseid või muid meetmeid, et Kõik välised võtmed (Foreign Key) 2.14 nõuded rakenduse jõudlusele oleksid täidetud ka tulevikus. (1, 3, 5 Arendaja peavad olema indekseeritud. või 10 aasta pärast – vastavalt planeeritud kasutusajale). SQL päringute väljakutsumisel väljastpoolt andmebaasi, peab kasutama päringumuutujaid, et vältida SQL vahemälu Tuleb kasutada päringumuutujaid 2.15 fragmentseerumist (When calling SQL code from outside the Arendaja (Parameter Binding). database, Parameter Binding should be used to prevent SQL cache fragmentation) Kõigis andmebaasi tabelites peab olema defineeritud üks primaarvõti. Kasutada vastava andmebaasisüsteemi nimetamise parimaid 2.16 Andmebaasi objektide nimetused Arendaja praktikaid. peavad olema sisulised ja andma aimu nende otstarbest. Andmebaasis defineeritakse üldjuhul kaks või enam kasutajat:  Rakenduse peakasutaja, kellena luuakse objektid ja skeemid. Need õigused, mis on vajalikud ainult rakenduse baasi loomiseks, on  Rakenduse piiratud õigustega eraldi välja toodud ja tuleb peale installi ära võtta. Ei kehti teiste 2.17 Arendaja kasutaja, kellena pöördub andmebaasisüsteemide korral, seal võib see tekitada mõttetut rakendusserver/rakendus. keerukust. Objektide loomiseks vajalikud õigused ja ressursid on loetletud rakenduse dokumentatsioonis. Failide hoidmise asukoht lepitakse Failide hoidmine klassikalises andmebaasis on kulukas ja seab igakord kokku. Kuid failid ja failide kõrgendatud nõudmised ja piirangud andmebaasiserveritele. 2.18 Arendaja indeks peavad olema replikeeritavad Lahenduse dokumentatsioonis tuleb ära tuua failide hoidmise teise serveriruumi. asukoht. Peab olema minimiseeritud vajadus, et haldur teeb haldustoiminguid otse baasis. St rakendusel peab olema Halduri haldustoimingud lepitakse tellijaga kokku detailanalüüsi 2.19 Arendaja haldusliides, mille kaudu rakenduse käigus. haldur saab teha tavapäraseid haldustoiminguid. Rakendus peab olema võimeline 2.20 kasutama keskkonnamuutujaid Näiteks logifailides. Arendaja (serverinimi, kuu, päev jne). Andmebaas peab toetama nii külm- kui Ei tohi kasutada teenuseid, mis välistavad andmebaasi peegeldamist 2.21 ka kuumvaru (peegeldamist) Arendaja (nt "failstream"). teise serviruumi. Sorteerimisreeglistik peab olema Eesti tähestikule vastav. Tõusutundlikkus 2.22 Näiteks MS SQL puhul Estonian_CI_AS. Arendaja peab olema välja lülitatud. Accent peab olema sisse lülitatud. Kui infosüsteemid saadavad e- kirju, peavad nad kasutama välist e- Saatja ja adressaadid, pealkiri ja sisu ei tohi olla rakendusse mailiserverit. Kirja saatmisel peab kodeeritud, vaid on muudetavad konfiguratsioonifaili kaudu. 2.23 rakendus veenduma, et e-mailiserver Genereeritud kirjade puhul peab tagama kirjade jälitatavuse (näiteks Arendaja võttis meili vastu. E-kirjade lisada X-päise kodeeritud kirje, milles on kirjeldatud, mis vormindamine peab järgima interneti protsess/skriptifail/kasutaja kirja genereeris jms abistav info). standardeid (RFC 5322). Konfiguratsiooniparameetrite nimed Näiteks : X-tee Turvaserver, mitte XTTS või viitenumber, mitte 2.24 peavad olema sisulised. Kui see ei ole Arendaja vk_seb jne võimalik, siis peab kõrval olema seletus. Infosüsteemides on eessüsteemid (front Välise süsteemi tõrge tohib mõjutada ainult sellest otseselt sõltuvate end; presentatsiooni kiht) ja 2.25 kasutuslugude toimimist. Välise süsteemi taastumisel peab süsteem Arendaja tagasüsteemid (back end; äriloogika olema suuteline oma tööd jatkama taaskäivitamata. kiht) arhitektuuriliselt selgelt lahutatud. Konfiguratsioonifailid peavad olema Näiteks IIS: *.config , *.resources Apache: *.conf, 2.26 vastavalt rakendusserveri tüübile .htaccess. Arendaja peab välja tooma konfifailide listi, kui neid on Arendaja vaikimisi kaitstud failid mitu. Rakenduse failid, mida kasutaja näha ei Näiteks: IIS: Bin,App_Code, App_Data, App_Browsers, 2.27 tohi, peavad olema vaikimisi kaitstud App_GlobalResources, App_LocalResources, App_Themes, Arendaja kaustades. App_WebReferences Konfiguratsiooniparameetrite taaskasutus. Erinevaid sama sisuga Kõiki parameetreid tuleks konfiguratsioonis kirjeldada vaid korra, 2.28 Arendaja parameetreid ei tohi konfiguratsioonis mitte nii, et igas lõigus kirjeldatakse samu asju uuesti. eksisteerida. Rakendustes tohib kasutada vaid masinapõhiseid teenuseid, mis Kõik rakenduse liidesed peavad olema lubavad kõrgkäideldavaid (klaster) lahendusi. Kõrgkäideldav 2.29 Arendaja võimelised töötama kõrgkäidetavalt. lahendus on selline, mida saab samaaegselt käitada erinevates masinates. Klientrakendus ei tohi pöörduda otse 2.30 Tuleb kasutada rakendusservereid. Arendaja andmebaasi poole. Keskkonnapõhised muutujad peavad 2.31 olema konfiguratsioonifailist Näiteks WSDL ei tohi sisaldada viiteid arendusserveritele. Arendaja seadistatavad. Eelistama peaks IP-aadressipõhist blokeeringut. Erandina tellijaga kokkuleppel võib kasutada captchat või konto lukustamist. Rakenduses peab olema võimalik piirata Blokeeringute ajavahemikku ja logimiskatsete arvu peab saama ebaõnnestunud logimisi ajaühiku konfiguratsioonifailist muuta. 2.32 Arendaja kohta (mobiil-ID, ID-kaart, paroolid) ühelt IP-aadressilt. Allikas: https://iske.ria.ee/8_06/ISKE_kataloogid/7_Kataloog_M/M4/M_4.1 5 Rakenduse äriloogika tuleb realiseerida Andmebaas ei tohi sisaldada äriloogikat, mis muudab 2.33 andmebaasist eraldi sõltumatus andmetabelites olevaid/sinna kirjutatavaid andmeid, va trigerid, mis Arendaja rakenduskihis. tekitavad logi. Andmebaasis võib kasutada vaid *Ei ole soovitav kasutada mingit platvormispetsiifilist lahendust, ISO/IEC 9075 standardiga kaetud mille üleviimine mõnele muule andmebaasiplatvormile ei ole 2.34 funktsionaalsusi. Lisaks ei tohi kasutada võimalik. Arendaja ka sama standardi osas 13 kirjeldatud *ISO/IEC 9075 osa 13 spetsifitseerib Javas kirjutatud funktsionaalsusi. programmimoodulite kasutamist andmebaasis. Uniform resource identifier (URI) Harilikult on piiriks 2000 tähemärki, kuid iga IS puhul tuleb seda pikkus ei tohi ületada ühegi IS poolt 2.35 eraldi järele uurida sõltuvalt IS komponentidest. Asjakohased viited: Arendaja toetatava brauseri maksimaalset lubatud RFC 3986 ja RFC 7239. väärtust. SOAP teenuseid pakkuva rakenduse Näiteks: Alajaotis definitions/types/schema: 2.36 WSDL peab olema üles ehitatud nii, et Arendaja * complexType defineerimisel tuleb sellele lisada any element. see toetaks teenuste versioneerimist. Rakendus peab olema võimeline 2.37 töötama koormusjaoturitega varustatud Arendaja taristul. Sidusinfosüsteemide mitte kättesaadavus ei tohi segada rakenduse Sidussüsteemi tõrge tohib mõjutada ainult sellest otseselt sõltuvate 2.38 töötamist. Sidusinfosüsteemidega kasutuslugude toimimist. Sidussüsteemi taastumisel peab süsteem Arendaja andmevahetamisel tekkinud vead olema suuteline oma tööd jatkama taaskäivitamata. logitakse ja kasutajat hoiatatakse. Kui ajastatult käivitatav taustatöö, ei ole mõeldud käima paralleelselt, peab selles olema realiseeritud kontrollmehhanism, 2.39 mis tagab, et sama taustatööd ei ole Arendaja võimalik käivitada uuesti enne, kui eelmisena käivitatud instants on oma töö lõpetanud. Ühe tarkvarakomponendi raames ei tohi Näiteks kui rakenduse komponent pöördub andmebaasi või 2.40 sama parameetri seadistamine toimuda veebiteenuse poole, siis selle pöördumise parameetrid peavad olema Arendaja rohkem kui ühes kohas. muudetavad vaid ühes kohas. Uue toote arenduse ja olemasolevate infosüsteemide versiooniuuendustel 2.41 kasutusele võetavate Tehnoloogiate ja Arendaja standardite valik tuleb kooskõlastada Tellija poolse arhitektiga. Implementeeritud peab olema vähemalt maksimaalsete ühenduste Rakenduse ühenduste (s.h. andmebaasi arvu piirang ja päringu aegumise aeg (request timeout). Rakenduse ja sidusinfosüsteemide ühendused) ühenduste tõrge tohib mõjutada ainult sellest otseselt sõltuvate 2.42 Arendaja realiseerimisel tuleb kasutada ühenduste kasutuslugude toimimist. Ühenduste taastumisel peab rakendus puulimist (connection pooling). olema suuteline oma tööd jatkama taaskäivitamata. Tekkinud vead logitakse ja kasutajat hoiatatakse. Rakenduse uuendustega kaasnevad 2.43 andmebaasi muudatused tuleb Näiteks Liquibase või Flyway Arendaja automatiseerida. 3. Turvalisuse tagamisega seotud nõuded Erandina tellija kooskõlastusel võib sellest loobuda ja kasutada vaid Sisemised rakendusliidese autentimised ID-kaardi ja mobiil-ID põhist autentimist. Isiku sertifikaatide 3.1 peab saama teha Active directory Arendaja kehtivust peab saama kontrollida vastu OCSP ja CRL-i (vastavalt põhiselt. vajadusele). Kliendi ja serveri vahel peab autenditud kasutajasessioonide korral olema 3.2 - Arendaja sessioon krüpteeritud HTTPS-protokolli kasutades. SSL veebiserver peab kasutama turvalisi 3.3 https://www.ssllabs.com/ssltest/ Arendaja ja SSL/TLS versioone ja šifrikomplekte Rakendus tohib kasutada vaid sessiooni 3.4 küpsiseid. Muude küpsiste kasutamine - Arendaja on keelatud. St kõik andmemuudatused peavad baasis säilima. Andmete muutmisel andmeid ei kustutata, vaid tehakse uus kirje uute Kui andmebaasis olevate andmete ISKE andmetega. Vana muudetakse kehtetuks. Iga uus kirje peab tervikluse turvaosaklass on 2 või sisaldama järgmist informatsiooni: *viide kirjele, mille ta kehtetuks 3.5 kõrgem, siis tuleb kõik klass 2 infot Arendaja muutis (kui on) *kasutaja, kes kirje lõi *kirje loomise aeg sisaldavad andmebaasi kirjed/tabelid *sessiooni-ID (kui on olemas). Iga kehtetuks tunnistatud kirje peab versioneerida. omama järgmist informatsiooni: *kasutaja, kes kirje kehtetuks tunnistas *kirje kehtetuks tunnistamise aeg. Kui rakenduse poolt töödeldavate andmete konfidentsiaalsuse turvaosaklass on 2 või kõrgem, peab Testandmed peavad säilitama kõik toodangu andmete omadused 3.6 rakendusega kaasas olema lahendus, mis Arendaja (pikkuse, tüübi) ja omavahelised suhted. suudab toota toodangu andmetest testandmed, mis ei sisalda konfidentsiaalset informatsiooni. Ei resource, dba, ANY ega muud sellist. Nõude täitmiseks vajalikud Andmebaasis olevate rakenduse kontod vahendid (skriptid) peavad kuuluma rakenduse juurde ja nende sisu 3.7 peavad omama ainult minimaalselt Arendaja peab olema kontrollitav. Kontodele vajalikud õigused peavad olema rakenduse tööks vajalikke õiguseid. kirjeldatud rakenduse installijuhendis. Rakendusse ja andmetele tohib olla ligipääs vaid dokumenteeritud ja St rakendustes ega andmebaasides ei tohi olla ligipääsemiseks teisi 3.8 tellimuses kirjeldatud teid mööda ning Arendaja võimalusi. dokumenteeritud autentimisprotseduure kasutades. Räsimine peab kasutama turvalist räsifunktsiooni (nt SHA2, SHA3, RIPEMD-160) ja kindlasti ka soola (salt). Sool peab olema andmebaasiüleselt unikaalne, piisavalt suure bitiarvuga ja Kõik paroolid ja salaküsimuste vastused (pseudo)random. Krüpteerimisel peab kasutama turvalisi algoritme peab rakendus salvestama vaid (nt AES256) ja CBC, CRT vms režiimis. Kindlasti ei tohi kasutada räsitud+soolatud. Kui räsimise asemel 3.9 ECB režiimi. Paroolid ja salaküsimuste vastused tohivad olla Arendaja valitakse krüpteerimine, siis tuleb krüpteerimata kujul vaid ajutiselt serveri muutmälus. Krüpteerimata kirjeldadakrüptovõtme turvalise kujul ei tohi paroole salvestada (ka ajutiselt) ühelegi kettale. hoidmise protseduur. Arendaja loodud lahenduse 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) Kui on vajalik ka parooliga logimine, peavad välised kasutajad autentima ennast spetsiaalse väliskasutajate jaoks mõeldud AD pihta. Kui parooliga autentimist tehakse alati samadelt üksikutelt IP- Rakendused, kuhu saavad ligi välised delt, siis tuleb lisaks paroolile kasutada ka IP-põhist kasutajad, peavad võimaldama ligipääsukontrolli. Rakendus ei tohi lubada kasutada nõrku paroole, 3.10 sisselogimist ID-kaardi ja mobiil-ID-ga. Arendaja peab võimaldama paroolide eelmääratud aegumist ja mitme Paroolipõhist autentimist ei tohi valesisestuse (nt 5 korda) korral kontode lukustamist. kasutada. Sertifitseerimiskeskuse dokument digisertifikaatide kasutamise kohta EV dokumentidel: https://sk.ee/upload/files/SK-CPR- ESTEID-ET-v5_0-20150101.pdf Mobiil-ID autenimise korral tuleb lisaks Veebilehel kuvatav kontrollkood peab olema selgelt nähtav, sh ka 3.11 kasutaja telefoninumbrile küsida ka Arendaja nutitelefonidel ilma ekraanipilti kerimata. kasutaja isikukoodi. Rakendus ei tohi teostada X-tee päringut Kasutajaarvutitest otse x-tee päringute tegemine on arvutivõrgu 3.12 Arendaja otse kasutajaarvutist. tasemel kinni. Veebipõhised välise veebilehega IIS puhul peab kasutama näiteks URL scan, apache puhul rakendused, mis on keskmise või modsecurity või vastavat tööriista. Lubatud päringud on kõik 3.13 kõrgema ISKE turbeastmega, peavad päringud, mis ei ole detailanalüüsi käigus vastavalt kasutusjuhtudele Arendaja kasutama vahendeid kaitsmaks ette nähtud. Kasutama peab whitelisting põhimõtet, mitte rakendust lubamatute päringute eest. blacklisting. Kõigil rakendustel peab olema Aeg peab olema muudetav koos teiste 3.14 konfigureeritav kasutajasessiooni Arendaja konfiguratsiooniparameetritega. aegumise aeg. Järgida tuleb uusimat RIA kodulehel avaldatud krüptograafiliste Krüpteerimise ja/või räside arvutamise algoritmide kasutusvaldkondade ja elutsükli uuringut. Lubatud on: 3.15 korral tuleb kasutada tugevaid AES-256, Blowfish-256, RSA-2048, SHA-2, RIPEMD-160 või Arendaja algoritme. tugevamaid. Lahenduses tuleb välja tuua kõik krüptoalgoritmid, võtmepikkused ja kasutuskohad. Autenditud sessiooni tunnust ei tohi Sessiooni ei tohi olla võimalik üle võtta sessioonitunnuse 3.16 Arendaja ainult lihtsa küpsisega lahendada. kopeerimisega ühest arvutist teise. AD või AAM-i autentimise kasutamisel peab rakendus kasutama ka AD või Näiteks: konto on lukus, parool aegunud, konto aegunud, 3.17 Arendaja AAM-i kontoga kaasnevaid paroolipoliitika jne. piiranguparameetreid. Tagada tuleb rollide lahusus. Halduritel Administraatoril, halduril ja tavakasutajal on erinevad tööülesanded. 3.18 ei tohi olla võimalik muuta ega näha Rollide/õiguste kirjeldus peab lähtuma detailanalüüsist ja Arendaja rakenduse konfiguratsiooni. kasutusjuhtudest. ID-kaardiga autentimisel, peab rakendus 3.19 suutma vastu võtta ID-kaardi sertifikaati Proxy tugi Arendaja ka päises. Kui kasutajaid hallatakse ka rakenduses ja autenditakse AD või AAM-i vahendusel, tuleb sisselogimisel 3.20 Eesmärk vähendada AD ja AAM-i koormust. Arendaja kõigepealt kontrollida kasutaja olemasolu rakenduses ja alles siis pöörduda AD või AAM-i poole. Kui rakenduse tervikluse turvaosaklass on T3, peavad tõestusväärtust omavad Milline lahendus valitakse tuleb kokku leppida tellijaga. 3.21 Arendaja andmed olema kas ajatembeldatud, Täpsustuseks vt ISKE nõue HT.34. digiallkirjastatud või digitembeldatud. Kui lahendus peaks kasutama ajatempli Ajatempli kasutamise vajadus lepitakse eraldi kokku Tellija IT 3.22 teenust, siis tuleks eelistada Guardtime juhiga ja infoturbejuhiga. See sõltub Tellija keskse ajatempli Arendaja lahendust. kasutamise võimalustest. Kui rakenduse tervikluse turvaosaklass on T3, peavad tõestusväärtust omavad Täpsustuseks vt ISKE nõue HT.10. Krüptoahela kasutamise vajadus 3.23 andmed olema krüptoaheldatud, et lepitakse eraldi kokku Tellija infrastrktuuri juhiga ja infoturbejuhiga. Arendaja tagada et tõestusväärtusega andmeid ei See sõltub Tellija keskse krüptoahela kasutamise võimalustest. saaks märkamatult kustutada. Kui rakenduses on S3 salastuse astmega andmeid, peavad need olema nii 3.24 Täpsustuseks vt ISKE nõue HT.37 . Arendaja transpordi ajal ja ka salvestatult alati krüpteeritult. Arendaja arendab arenduskeskkonnas ja annab tarne üle tellijale Rakendus ja selle komponendid peavad paigalduspakkidena. Tellija paigaldab selle testkeskkonda ja testib 3.25 võimaldama kasutada keskkondade Arendaja ning seejärel paigaldab tarne toodangu keskkonda. Reaalseid lahusust andmekogu andmeid tohib töödelda üksnes toodangu keskkonnas. Krüptograafiat kasutav rakenduskood ei tohi nimeliselt välja kutsuda krüptograafilisi algoritme, vaid peaksid seda tegema vahendavate Rakendus peab võimaldama hõlpsalt vaheteekide kaudu üldiste funktsioonide järgi (nt krüpteerimine, 3.26 välja vahetada aegunud ja ebaturvalise Arendaja dekrüpteerimine, signeerimine, signatuuri verifitseerimine jne). krüptoalgoritmi. Dokumentatsioon peab kajastama üldist kirjeldust, kuidas vajadusel ebaturvaline krüptoalgoritm välja vahetada. Andmebaasides kasutatavad krüpteerimisfunktsioonidest tingitud Rakenduse andmebaasi krüpteerimisega lisaväljad peaksid olema muudetava pikkusega, et formaati 3.27 seotud andmeväljad peavad olema Arendaja muutmata saaks kasutada teistsuguste parameetritega muudetava pikkusega. krüpteerimisalgoritme. 4. Logimine, debuggimine, testimine Testlehe kättesaadavus erinevatest arvutivõrkudest peab olema konfigureeritav. Testleht peab uuendama 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 Rakendusel peab olema masinloetav 4.1 rakenduse (vajadusel tema erinevate osade) ja tema kõigi väliste Arendaja testleht (JSON, XML). 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). Rakenduse kõik üleantavad versioonid Testitulemused tuleb edastada tellijale koos rakenduse 4.2 peavad enne tellijale üle andmist olema Arendaja üleandmisega. testitud. Rakendus peab logima kasutaja edukat Logima peab ka autentimise ebaõnnestumise koos põhjusega (vale ja ebaedukat autentimist ja sessiooni parool, aegunud konto jne). Logida tuleks IP-aadress, meetod ja kui lõpetamist, kasutaja IP ja võimalik kasutajatunnus (mobiil-ID puhul telefoni number, ID- 4.3 autentimismeetodit (ID-kaart, mobiil-ID kaardi puhul isikukood). Kui rakendus kasutab kasutajate Arendaja vms), eduka autendi puhul tuleks logida autentimiseks AAM-i või TARA, siis leppida projektijuhiga eraldi ka kasutaja isikukood ja mobiil-ID kokku autentimise detailsus ehk mis kajastatakse AAM-is või puhul telefoninumber TARA-s ja mis rakenduses. Erinevate logifailide kirjeid peab olema 4.4 võimalik seotud komponentide logidega Näiteks timestamp või mingi (request)ID abil. Arendaja loogiliselt kokku viia. Rakendus peab suutma logida kõiki X- tee teenuste kaudu liikuvaid andmeid. Vajalik eelkõige debuggimiseks ja toodangu keskkonna probleemide 4.5 Arendaja Peab olema võimalus logimist sisse- lahendamiseks. välja lülitada. Kui rakenduse ISKE konfidentsiaalsus turvaosaklass on 2 või kõrgem, peab rakendus logima kõiki konfidentsiaalsus Isikuandmete töötlemisel lähtub täitja turvameetmetest vastavalt IKS 4.6 Arendaja klassiga 2 või kõrgemate andmete §-le 43. loomist, muutmist (sh kustutamist) ja vaatamist. Kui rakenduse ISKE tervikluse turvaosaklass on 2 või kõrgem peab Isikuandmete töötlemisel lähtub täitja turvameetmetest vastavalt IKS 4.7 rakendus logima kõiki tervikluse Arendaja §-le 43. klassiga 2 andmete loomist ja muutmist (sh kustutamist). Kui rakenduse andmete Lahendus peab tagama, et administraatorid/haldurid ei saa andmete konfidentsiaalsuse turvaosaklass on 3, vaatamise logimist ise (ka tavakasutajate logimist) deaktiveerida või 4.8 siis ka kõiki administraatorite ja Arendaja logisid kustutada/muuta. Võib tellijaga kokku leppel nõudest haldurite poolt tehtavaid andmete loobuda kui andmed on krüpteeritud. vaatamised (ka otse baasis) tuleb logida. Kui rakenduse andmete tervikluse Lahendus peab tagama, et administraatorid/haldurid ei saa andmete turvaosaklass on 3, siis ka kõiki muutmise logimist ise (ka tavakasutajate logimist) kinni keerata või 4.9 administraatorite ja haldurite poolt logisid kustutada/muuta. Tellijaga kokkuleppel võib nõudest Arendaja tehtavaid andmete muudatused (ka otse loobuda, kui andmed on kaitstud digiallkirja, digitempli või välise baasis) tuleb logida. osapoole ajatempliga. Andmete 4.10 loomise/vaatamise/muutmise/kustutamis Logid peavad asetsema tsentraalses logiserveris Arendaja e tegevused peab logima. Andmebaasi logidest saadetakse reaalajas koopia failisüsteemi logisse ja Failisüsteemi logide eesmärk on koguda logid ühtesesse 4.11 seal logis peab kajastuma ka Arendaja logihaldussüsteemi, et neid krüptoaheldada ja aegtembeldada. logimisfunktsionaalsuse aktiveerimise ja deaktiveerimise info (aeg, kasutaja jms) Jõudlustestide täpne kirjeldus tuleb kokku leppida detailanalüüsi käigus. Arendaja peab koos rakendusega tarnima skripti ja vajalikud Rakendusega peab olema kaasas skript 4.12 tarkvaralised vahendid kokkulepitud jõudlustestide läbiviimiseks. Arendaja jõudlustestide tegemiseks. Jõudlustestide läbiviimine ei tohi nõuda tellijalt omapoolset tarkvara arendamist, skriptide kirjutamist või litsentside ostmist. Logi sisaldab minimaalselt vea tekkimise aega, veakoodi, Rakendus peab logima kõiki rakenduses 4.13 veakirjeldust (stack trace, traceback vms), võimalusel kasutaja Arendaja tekkivaid tehnilisi vigu. andmeid, HTTP-, GET- ja POST-parameetrid ja nende väärtusi. Vea ja süsteemilogid peavad Kui logitakse mitmesse kohta, siis vajadusel peab saama ühte või olema vähemalt failisüsteemi tekstifailis teise kohta logimist välja lülitada. Logi peab olema lihtsalt 4.14 Arendaja üldtuntud vormingus, lisaks võib ka masintöödeldav ja tuntud vormingus. Näiteks syslog, syslog-ng, andmebaasis hoida. XML, CSV. Failisüsteemi logimise korral peavad logid olema ka katalogiseeritud (näiteks kuupäeva või liigi järgi) ja üldtunnustatud faililaiendiga (näiteks .log, .txt, .xml), logi peab olema 4.15 Ei tohi esinda olukorda, kus ühte kausta tekib rohkem kui 1000 faili. Arendaja roteeruv, et ei tekiks liiga suuri faile (nt 5MB). Logifailide seadistamisel peab olema failinime/kaustatee nimedes võimalik kasutada keskkonnamuutujaid (kuupäev, masinanimi jne). Logimis parameetreid peab saama 4.16 Näiteks log4j konfiguratsiooni failis "monitoring-interval". Arendaja muuta rakendust taaskäivitamata. Arhitektuuriline lahendus peab olema 4.17 75% ulatuses kaetud Arendaja komponenditestidega (unit test). Arhitektuuriline lahendus peab olema 50% ulatuses kaetud automatiseeritud 4.18 Arendaja integratsiooni ja vastuvõtutestidega (integrationtest, api end-to-end test). Kasutajaliidese testimise osakaal kogu testimise mahust peab olema mõistlik (mitte ületades 30%), rakendades seda kriitilisele funktsionaalsusele (lepitakse 4.19 Arendaja tööde käigus kokku). 50% kasutajaliidese testimisest peab olema automatiseeritud ja korduvkasutatav kokkulepitud raamistikul (nt Selenium) 5. Nõuded rakenduse lähtekoodile NB! Nõuet ei arvestata arendustarkvara poolt automaatselt Lähtekoodi kommentaarid peavad genereeritavate koodilõikude puhul – neid ei ole vaja tõlkida. Samuti kõigis lahenduse kihtides (rakenduse ei rakendata nõuet kolmandate osapoolte poolt toodetud lähtekoodile 5.1 Arendaja enda kood, andmebaas, jne) olema – nt igasugu erinevad lahtise koodiga koodilõigud jms. Kui on tegu kirjutatud inglise keeles. olemasoleva süsteemi edasiarendusega, siis peaks kommentaarides kasutama eelnevalt kasutatud keelt. Muutujate, tüüpide ja funktsioonide 5.2 nimed peavad olema sisulised ja andma Parim praktika Arendaja aimu nende otstarbest. Koodis kasutatavad konstandid ja Parim praktika. Nt Identifikaator --> ID. Front-End reeglid on 5.3 lühendid tuleb kirjutada suurte Arendaja kirjeldatud Front-end arendusreeglid lehel tähtedega. Koodis kasutatavaid konstante ei tohi selle kasutamise kohta väärtusena 5.4 - Arendaja hardcodeda – need tuleb defineerida muutujatena ja kasutada läbi nende. Koodis defineeritud andmetüübid peavad olema nimetava käände N:Isik; Menetlus; jne. Andmebaaside 5.5 ainsuses. Kõik andmemassiivid tuleb Arendaja struktuurikirjeldustes/andmemudelis ei tohi kasutada täpitähti. nimetada nimetava mitmuses (st igasugu collectionid, arrayd, jms). Andmetabelites sisalduvad võõrvõtmed Kasutada tuleb konkreetse andmebaasisüsteemi nimetamise 5.6 peavad nime järgi seostuma tabeli ja parimaid praktikaid. Nt kui on tegu tabelitega ’Isikud’ ja ’Autod’, Arendaja väljaga millele need viitavad. siis seos ’isiku autod’ oleks: Isikud.ID=Autod.Isik_ID Selle asemel, et eraldada väljale x baiti, tuleb eraldada x tähemärki. Andmebaasi väljade pikkused tuleb 5.7 (Instead of allocating x bytes of storage for the field, x chars of Arendaja kirjeldada sümbolites, mitte baitides. storage must be allocated). Kui kokku pole lepitud teisiti, siis Java rakenduse kood peab olema kirjutatud vastavalt "Google Java Style Guide" 5.8 Arendaja dokumendile: https://google.github.io/styleguide/javag uide.html TEHIK-us on automaatseks koodivalideerimiseks kasutusel SonarQube (https://www.sonarqube.org/). Ennem üleandmist tuleb veenduda, et koodis puuduvad: Java koodi valideerimiseks kasutatakse 5.9 tellija SonarQube paigalduses 1. Turbedefektid Arendaja seadistatud reeglistiku 2. Blokeerivad ja kriitilised vead Mõistlik on koodivalideerimine automatiseerida Gitlabi või Jenkinsi abil. Sõltub milline lahendus on projektis kasutusel. Kasutuses mitteolev kood tuleb 5.10 - Arendaja rakenduse lähtekoodist kõrvaldada. Arendamisel kasutatakse DRY ja http://en.wikipedia.org/wiki/Don%27t_repeat_yourself 5.11 Arendaja SOLID printsiipe http://en.wikipedia.org/wiki/SOLID_(object-oriented_design) Üleantavas koodis ei tohi olla paroole, Kehtib ka siis, kui need on välja kommenteeritud. Kõik sellised 5.12 Arendaja mida on kasutatud arenduse käigus paroolid tuleb asendada fraasiga “<password>“. Rakenduste lähtekoodi tasemel ei tohi 5.13 olla ühtegi sisse kodeeritud parameetrit, Eelpoolmainitu haldamine toimub failis või andmebaasis. Arendaja väljade nimetust, veateadet. 6. Andmekvaliteet ja standardid Rakendus peab võimalikult palju informatsiooni eeltäitma automaatselt 6.1 Välja arvatud logimisvormi lahtrid autentimisel Arendaja (kirje sisestamise kuupäev, kasutaja nimi jne). Tegevusalade andmete sisestamisel, kuvamisel ja hoidmisel tuleb lähtuda Vabariigi Valitsuse 10. Jaanuari 6.2 2008. a määrusest nr 11 Arendaja "Klassifikaatorite süsteem" ja kasutada EMTAK infosüsteemis kehtivat klassifikaatorit. 7. Kasutajaliides Kasutajaliidese kõik disainiotsused peavad olema 7.1 - Arendaja kooskõlastatud tellijaga enne nende realiseerimist Veebipõhine kasutajaliides peab olema Minimaalselt Internet Explorer, Mozilla Firefox, Chrome ja Safari kasutatav enamlevinud 7.2 arenduse testimise hetkel tootja poolt toetatud versioonid. Täpsemad Arendaja veebibrauseritega, sh nutiseadmetel nõuded dokumendis "Front-end arendusreeglid" (Android, IOS, Windows Phone) Kui tegemist on struktuurfondide projektiga on lisaks nõutud ka Rakenduse värviskeem ja logo vastav SF sümboolika. Tellija ametlikud CVI esitluspõhjad, logo kasutamine peab vastama Tellija kasutusjuhend ja kõik logod (ka jpg-na) küsida tellijalt. Iseteeniduse 7.3 Arendaja ametlikule visuaalsele identiteedile väljanägemine tuleb vastaval RIA stiiliraamatule. (CVI) ja disainijuhistele (UIG). Ametnikurakenduse väljanägemine vastavalt ametnikurakenduses kehtestatud stiiliraamatule. Kasutajaliidese kõik osad ja teated Kui soovitakse juurde eraldi ka muid keeli, siis see on 7.4 Arendaja peavad olema eestikeelsed. spetsifitseeritud hankedokumentides Toetatud peavad olema vähemalt resolutsioonid: 1920x1200, 1920x1080, 1680x1050, 1600x1200, 1440x900, 1360x768, Avalikuks kasutamiseks tehtav rakendus 1280x1024, 1280x960, 1280x800, 1280x768, 1152x864, peab olema graafiliselt eskaleeruv ja 1024x768, 1024x600. Ühegi nimetatud resolutsiooni korral ei tohi 7.5 Arendaja mugavalt kasutatav kõigi enamlevinud tekkida lehe ülest horisontaalset kerimisriba. Mahukate arvutite monitoride resolutsioonidega. andmekogumite väikestel ekraanidel kuvamiseks üks lahendus võib olla komponendi sisene kerimine x ja y teljel. Täpsed lahendused lepitakse kokku töö käigus ja vastavalt vajadusele. Sisemiseks kasutamiseks tehtav Ühegi nimetatud resolutsiooni korral ei tohi tekkida lehe ülest rakendus peab olema graafiliselt horisontaalset kerimisriba. Mahukate andmekogumite väikestel eskaleeruv ja mugavalt kasutatav 7.6 ekraanidel kuvamiseks üks lahendus võib olla komponendi sisene Arendaja järgmiste monitoride resolutsioonidega: kerimine x ja y teljel. Täpsed lahendused lepitakse kokku töö käigus 1024x768, 1280x1024, 1680x1050, ja vastavalt vajadusele. 1920 x 1080, 1920x1200. 7.7 Hüpikaknaid (pop-up) ei tohi kasutada. Silmas on peetud uusi veebilehtiseja aknaid avavaid hüpikaknaid Arendaja Kasutajaliides peab alati küsima kinnituse andmete kustutamise ja 7.8 - Arendaja massmuutmiste kohta kui pole kokku lepitud teisiti. Rakenduse kasutamisel tekkinud veale Veateated peavad olema sellised, mis võimaldavad IT-abil peab kasutajaliides vastama kasutajale võimalikult lihtsalt tuvastada vea olemuse ja asukoha. Kui kasutaja 7.9 Arendaja eestikeelse kasutajasõbraliku veateatega, kasutab süsteemi mõnes võõrkeeles siis peavad veateated olema mis sisaldab soovituslikult ka vea koodi. selles keeles Kasutajaliides peab olema ilma rakenduse koodi muutmata tõlgitav teise Uue keele lisamine peab olema teostatav konfiguratsiooni failist või 7.10 Arendaja keelde, v.a kui ei ole kokkulepitud administreerimisliidesest. teisiti. Rakenduse kasutajaliides peab 7.11 teavitama kasutajat ette sessioon Ette teavitamise aeg peab olema konfigureeritav. Arendaja aegumisest. Kui vormile sisestatakse mahukaid andmevälju peab kasutajaliides kokku Kui vorm koosneb paljudest väiksest andmeväljadest (nt taotlus), lepitud ajavahemike järel salvetama 7.12 siis jagatakse vorm etappideks ning salvestatakse vastava etapi Arendaja välja sisu, et sessiooni aegumisel või lõpus. võrgu katkestuse korral juba sisestatud andmed ei kaoks. Sisestusvormidel andmete sisestamisel peab saama väljade vahel vastavalt Tabuleerimise järjekord tuleb HTML struktuurist. Pigem vältida 7.13 Arendaja äriloogikale liikuda klaviatuuri abil käsitsi tabindex-ite seadmist. tabulaatoriga. Interaktiivsete vormide puhul (näiteks faili üleslaadimine), ei tohiks lehe 7.14 värskendamisega tegevust korrata (faili - Arendaja taas üles laadida, andmeid saata, avaldust esitada). Kui päring võtab aega kauem kui 3 sekundit, peab kasutaja saama visuaalse Ikoon peab muutuma liivakellaks ja/või kuvatakse teade: päringut 7.15 Arendaja teate, et süsteem tegeleb päringu sooritatakse või muu tellijaga kokkulepitud indikaator. läbiviimisega. Esilehel (sisselogimata) ja ka pärast kasutaja sisselogimist peab olema lihtne võimalus teavitada kasutajat Näiteks võimalikud teavituses: mingi süsteemi osa on vigane, tuli 7.16 muudatustest või probleemidest. mingi uus funktsionaalsus, vahetage oma parool, uuendage Arendaja Teavitus peab olema halduri poolt isikuandmeid jne. lihtsalt lisatav ja olema kasutajale märgatav. Infosüsteem peab funktsionaalse vea (näiteks kohustuslikkude väljade 7.17 täitamata jätmisel) korral kasutajale Arendaja kuvama kasutajasõbraliku veateate. Veateated peavad olema hallatavad. Päringu vastusena kuvatud tabeli veerge 7.18 on võimalik andmete/teksti Arendaja tähestikulises järjekorras sorteerida. Vastavalt RIA stiiliraamatule tähistatakse kohustuslikud väljad tekstiga. Kui vormil on kohustuslikke väljasid on rohkem kui mittekohustuslikke siis tähistatakse hoopiski mittekohustuslikud. Vormide täitmisel peab kasutaja saama Kui ametniku rakendus ei kasuta RIA stiiliraamatut siis tähistatakse 7.19 ülevaate kohustuslikest andmeväljadest kohustuslikud väljad tärniga. Oluline on ka meeles pidada, et Arendaja enne vormi täitmist lähtuvalt WCAG nõuetest https://www.w3.org/TR/WCAG20- TECHS/H90.html peab iga vormi alguses olema legend, mis selgitab kohustuslikke väljasid tähistavat sümbolit. Nt: *tähistab kohustuslikke väljasid Rakenduse andmeväljade mõisted peavad olema üheselt identifitseeritavad, korrektses eesti keeles (ilma kirjavigadeta) ja vajadusel sisaldama Korrektne keel ja õigekirjareeglite järgimine on sisuhaldajate 7.20 Arendaja selgitavat teksti. Abiinfo ülesanne. (kasutusjuhendid) peab olema kättesaadav rakenduse toimimise erinevatel etappidel. Kasutajaliides peab vastama ka 7.21 dokumendis "Front-end arendusreeglid" Front-end arendusreeglid Arendaja kirjeldatud reeglitele 8. Dokumentatsioon Erandiks võivad olla kolmanda osapoole komponentide (mis pole Kogu rakenduse dokumentatsioon peab kirjutatud tellija jaoks) dokumentatsioon. Samuti võib erandiks olla 8.1 Arendaja olema kirjutatud eesti keeles. välispooltega seotud projektid. Erandid tuleb kooskõlastada tellijaga enne dokumentatsiooni koostamist Lahendus kirjeldatakse RIHA määruse Arendaja / Projektijuht 8.2 https://www.riigiteataja.ee/akt/12933746?leiaKehtiv#para6 nõuete kohaselt. / Tellija RIHA haldur Rakenduse dokumentatsioon peab sisaldama paigaldusjuhiseid, varundatavate komponentide kirjeldust, Dokumentatsioon peab olema versioneeritud, kasutajate kasutusjuhendeid, muutmiskuupäevadega, autori nimedega, korrektse keelekasutusega, peakasutajate ja administraatorite selge struktuuriga. Dokumentatsiooni detailsus peab olema piisav, et 8.3 kasutusjuhendeid, andmemudeleid, sõltumatu kolmas tehnliste IT baasteadmistega isik suudaks Arendaja arhidektuurilisi mudeleid, dokumendist vajalikke järeldusi teha (st dokument peab olema süsteemitehnilisi kirjeldusi, nõudeid arusaadav sellele isikule, kuid näiteks paigaldusjuhise järgi riistavarale, krüptoalgoritme ja toimetades ei pea ta ebaõnnestunud tarnele teostama veaanalüüsi). võtmepikkuseid, SSL sertifikaatide kasutuskohti jms Rakenduse dokumentatsioon peab sisaldama tabelite-andmete-logide mahu Esialgne kirjete mahu hinnang peab tulema lähteülesandest, ning kasvu arvestuslikku hinnangut 8.4 täpsustuma eel ja detailanalüüsi käigus. Mahuhinnang peab Arendaja rakenduse sihipärase kasutamise korral sisaldama ka logide säilitamise, arhiveerimise tähtaegu. ettenähtud arvu kasutajate poolt. (MB/GB kuus/aastas). Iga uue versiooniga peab alati välja Release notes peab kajastama kõiki muudatusi eelmise ja uue 8.5 tooma versiooni muudatuse kirjeldused Arendaja versiooni vahel. (release notes). Rakenduse dokumentatsioon peab vastama ka dokumendis "Nõuded 8.6 Nõuded infosüsteemi dokumentatsioonile Arendaja infosüsteemi dokumentatsioonile" kirjeldatud nõuetele 9. Versioonihaldus Kõik rakenduse testimiseks, koolituseks Arendajale antakse selleks õigused Tellija versioonihalduse või implementeerimiseks üle antavad repositooriumi, kus ta peab hoidma oma erinevaid versioone. 9.1 tarkvarapaketid peavad olema Arendaja Versioonihalduse repositooriumi juurdepääsutaotlus esitatakse versioneeritud. Kasutama peab Tellija Tellija kasutajatoele läbi projektijuhi. versioonihalduse repositooriumi. Nii arendamisel kui ka hoolduslepingute Arendajale antakse selleks õigused Tellija veahalduse keskkonda. 9.2 korral kasutatakse Tellija veahalduse Arendaja Juurdepääsutaotlus esitatakse Tellija kasutajatoele läbi projektijuhi. keskkonda. 10. Paigalduspaketi kooste Näiteks võib lahenduse paigalduspaketi koosteprotsess ette näha, et Tarnitava lahenduse koosseisus üle käivitada tuleb rida shell-käske või võivad lahenduse koosseisus olla antava lähtekoodiga peavad kaasas valmis (Gradle, ..) koosteskriptid või mis iganes muu moodus 10.1 Arendaja olema kirjeldused sellest paigalduspaketi tekitamiseks. paigalduspaketi koosteks. Eelistatud on kasutada GitLab skripte. Kooste kirjelduste alusel valmiv paigalduspakett tohib sisaldada ainult Näiteks: kompileeritavate keelte puhul ei tohi sisaldada lähtekoodi, 10.2 Arendaja minimaalse rakenduse käitamiseks kui see pole vajalik rakenduse käitamiseks. vajamineva failikomplekti. Kooste kirjelduste alusel valmivat Näiteks ei tohi tekitada olukorda, kus rakenduse jooksutamiseks 10.3 paigalduspaketti peab olema võimalik Arendaja uues serveris tuleb see tingimata just sealsamas kokku kompileerida. liigutada erinevate masinate vahel. Administraatoril peab olema võimalus 10.4 andmebaasi muudatuste skriptide sisus Arendaja veenduda. Sotsiaalkaitse infosüsteem Nõuded infosüsteemi dokumentatsioonile Raamlepingu lisa 3 Versioon: 1.0 Dokumendid peavad vastama vähemalt alljärgnevatele tingimustele: 1. Andmemudel Eeldus Teenuste/kasutuslugude dokumentatsioon dokumendile: Otstarve: Kirjeldada andmeobjekte ja nendevahelisi seoseid Sisu: Andmebaasi põhjal luua andmetabelite ja -objektide seosdiagramm. Sihtgrupp: Tellija, peakasutajad, rakenduse administraatorid enne igat enne esimese arendusetapi igakordsel tellijale arendusetapi algust testimisse andmisel algust Ajakava: Kirjeldada andmemudelit kontseptuaalse mudelina jah jah interaktioone/seoseid 2. Kasutaja õiguste ja tegevuste vastavustabel Eeldus Süsteemi üldine kirjeldus dokumendile: Otstarve: Kirjeldada kasutaja rollide õigusi erinevates kasutuslugudes ja tegevustes Sisu: CRUD maatriks Tellija äriprotsesse valdavad kontaktisikud, ärianalüütikud, Sihtgrupp: süsteemianalüütikud, täitjast sõltumatud tarkvara hooldajad, arendajad ja edasiarendajad, testijad, arhitektid, projektijuhid. enne esimese enne igat igakordsel tellijale arendusetapi algust arendusetapi algust testimisse andmisel Ajakava: jah Nimetada kasutaja rollid 3. Teenuste/kasutuslugude dokumentatsioon Süsteemi üldine kirjeldus Eeldus dokumendile: Otstarve: Kirjeldab detailselt üleantavaid teenuseid/kasutuslugusid. Teenuste/kasutuslugude detailse kirjelduse sisuks on:  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 Sisu: 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 )  Protsesside UML vaated Tellija äriprotsesse valdavad kontaktisikud, ärianalüütikud, Sihtgrupp: süsteemianalüütikud, täitjast sõltumatud tarkvara hooldajad, arendajad ja edasiarendajad, testijad, arhitektid, projektijuhid. enne esimese enne igat igakordsel tellijale arendusetapi algust arendusetapi algust testimisse andmisel Ajakava: Nimetada kasutuslood jah 4. Arhitektuuridokument Eeldus Süsteemi üldine kirjeldus dokumendile: Dokumendi eesmärgiks on kirjeldada loodava süsteemi üldist ehitust. Kirjeldatakse rakenduse loogilist struktuuri, näidates ära selle kihtideks Otstarve: jagunemise korda. Kirjeldatakse ka füüsilist arhitektuuri, antakse ülevaade kasutatavatest tehnoloogiatest ning vahenditest. Dokument peab rahuldama vähemalt alljärgnevaid sisunõudeid: 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 Sisu: 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 n teenuse poole) 6. kolmandate osapoolte poolt toodetud kasutatavad tarkvarad/riistvarad, mis on vajalikud süsteemi toimimiseks Sihtgrupp: Arhitekt, administraator, turvaspetsialist enne esimese enne igat igakordsel tellijale arendusetapi algust arendusetapi algust testimisse andmisel Ajakava: jah Dokumendi esialgne versioon 5. Seadmete ja tarkvara kasutajakesksed juhendid Eeldus Teenuste/kasutuslugude dokumentatsioon dokumendile: Teenuse funktsionaalsuse kasutamiseks ja kasutuslugude läbimiseks Otstarve: vajalikud juhised 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. Sisu: 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 enne esimese enne igat igakordsel tellijale arendusetapi algust arendusetapi algust testimisse andmisel Ajakava: jah 6. Paigalduse ja administreerimise juhend  Arhitektuuridokument Eeldus  Süsteemi üldine kirjeldus dokumendile: Otstarve: Juhend on aluseks süsteemi administreerimisele 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. 4.1 Nõuded rakenduse komponentidele 4.2 Rakenduse paigaldus (Vajalik tarkvara ja konfigureerimine, rakenduse Sisu: pakkimine ja paigaldamine) 4.3 Andmete alglaadimine 4.4 Varundusskript 4.5 Monitooringu kirjeldus 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. Sihtgrupp: Peakasutaja, projektijuht, süsteemiadministraator enne esimese enne igat igakordsel tellijale arendusetapi algust arendusetapi algust testimisse andmisel Ajakava: jah 7. Lähtekood (sh andmebaasi struktuur)  Arhitektuuridokument  Teenuste/kasutuslugude dokumentatsioon Eeldus  Andmemudel dokumendile:  Kasutaja õiguste ja tegevuste vastavustabel  Prototüüp Lähtekood on vajalik selleks et kompileerida rakendust, ning võimaldada Otstarve: tulevikus rakenduse muutmist.  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 Sisu:  Lähtekood peab olema pakendatud vastavalt versioonimisjuhendile.  Rakenduste lähtekood peab olema piisavalt modulaarne, et seda saaks tulevikus lihtsasti täiendada ning muuta. enne esimese enne igat igakordsel tellijale arendusetapi algust arendusetapi algust testimisse andmisel Ajakava: Versioonihaldus tuleb teha Tellijakeskkonnas (nt Gitlab), sh ka jooksvaid commit’e 8. Koormustestide dokumentatsioon  Teenuste/kasutuslugude dokumentatsioon Eeldus  Prototüüp (ainult kasutajaliidesega rakenduse puhul) dokumendile:  Arhitektuuridokument Määrata kindlaks arendusetapil testitavad kasutuslood ja liidesed (sh välja Otstarve: tuua need, mille puhul rakendatakse koormusteste) tuues välja nende järjekorra. Järjestatud (võib olla ka paralleelne) nimekiri kasutuslugudest ja liidestest Sisu: (vajadusel määrates nende ulatust) koos märkega, mis on koormustestiga tagatud ning millel on testandmed Sihtgrupp: Tellijapoolne projektijuht, vastuvõtutestijad enne igat enne esimese arendusetapi igakordsel tellijale arendusetapi algust testimisse andmisel algust Ajakava: Nimetada kasutuslood, mille puhul rakendatakse jah koormusteste 9. Testimise tulemite dokumentatsioon Koormustestide dokumentatsioon Eeldus dokumendile: Anda tellijale ülevaade läbiviidud testimise tulemustest ning esitada Otstarve: soovitused testandmete ja dokumentatsiooni parendamiseks (ettevalmistus, paigaldus, kasutuslugude kirjeldus jne). Teostatud arenduste testimisel saadud informatsioon (näiteks testlood, testraport, testiplaan, testide kood jms). Dokumenteeritakse iga testimise Sisu: 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 Arhitekt, süsteemiadministraator, turvaspetsialist Sihtgrupp: enne esimese enne igat igakordsel tellijale arendusetapi algust arendusetapi algust testimisse andmisel Ajakava: jah 10. Automaattestimise tulemite dokumentatsioon Lähtekood (sh andmebaasi struktuur) Eeldus dokumendile: Otstarve: Anda tellijale ülevaade läbiviidud automaattestimise tulemustest. Ülevaade SonarQube’is (testide nimekiri, testide käivitamise tulemus, koodi Sisu: kaetavus). Arhitekt, süsteemiadministraator, turvaspetsialist Sihtgrupp: enne esimese enne igat igakordsel tellijale arendusetapi algust arendusetapi algust testimisse andmisel Ajakava: jah 11. Taasteplaani tegemise juhend Otstarve: Kirjeldada erisused, millega tuleb arvestada taasteplaani loomisel 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 Sisu: 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: Arhitekt, süsteemiadministraator, turvaspetsialist, äri, tellijapoolne projektijuht enne esimese enne igat igakordsel tellijale arendusetapi algust arendusetapi algust testimisse andmisel Ajakava: jah 12. Üldised nõuded: Üleantav dokument peab sisaldama sisseviidud muudatusi nii, et on väljatoodud muutunud ja lisandunud osa (võrreldes viimati üleantuga). HANKELEPING nr 3- 9 / .... Elatisabi maksmise teenuse analüüsi koostamine Tervise ja Heaolu Infosüsteemide Keskus, registrikood 70009770, aadress Uus-Tatari 25, Tallinn, keda esindab põhimääruse alusel direktor Katrin Reinhold (edaspidi tellija ) ja AS HELMES , registrikood 103 64097, aadress Lõõtsa tänav 6 Tallinn 11415 , keda esindab volikirja alusel Eliis Väert (edaspidi nimetatud ka t äitja ) , edaspidi eraldi pool või koos pooled , sõlmisid raamlepingu nr 3-9/2307-1 alusel käesoleva hankelepingu (edaspidi leping) alljärgnevas: Lepingu ese Lepingu esemeks on li sas 1 „ Tehniline kirjeldus “ ja lisas 2 „Äriline kirjeldus“ nimetatud tööd (edaspidi t öö d ). Vajadusel on tellijal õigus tellida lepingu esemega seotud täiendavaid töid kuni 20% ulatuses kokkulepitud mahust, eeldusel, et hankelepingu üldist olemust ei muudeta. 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. Tööde üleandmise ja vastuvõtmise tingimused Täitja annab töö üle hiljemalt 0 8.03.2021 . Tellitavad tööd antakse vastuvõtutestimiseks üle vastavalt lepingu lisas 1 kokkulepitud tingimustele. Tellija vaatab töö üle vastavalt raamlepingu tingimustele. 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 kirjeldatule. Lepingu hind Kui lepingu maksumus ei ole kokku lepitud fikseeritud summana ja tööde teostamine toimub töötunnipõhisel arvestusel, tasub tellija üksnes lepingu alusel tellitud ja teostatud töötundide eest. Täitja esitab iga kalendrikuu lõpus allkirjastatud ajaaruande järgmise kalendrikuu 5. tööpäevaks, millelt kajastuvad teostatud töötunnid ja nende jooksul teostatud tööd. Viimane ajaaruanne esitatakse koos aktiga. Tellija tasub lepingu alusel tellitud tööde eest kokku 70 045,7 ( seitsekümmend tuhat nelikümmend viis eurot ja seitsekümmend senti ) eurot ilma käibemaksuta . Arve esitatakse e-arvena , pärast akti tellija poolt allkirjastamist. Täitja annab tellijale arve tasumiseks tähtaja minimaalselt 21 kalendripäeva alates arve laekumisest. Arvel tuleb märkida raamlepingu ja hankelepingu number, riigihanke viitenumber ja tellija kontaktisiku nimi. Vastavalt raamlepingu punktile 2.5 lepivad pooled kokku, et lepingu täitmist rahastatakse Euroopa Liidu struktuurifondide vahenditest projekti „Elatisabi teenuse analüüs“, nr 2014-2020.12.03.20-0813 raames. Kõik lepingu raames loodavad esemed, tegevused, dokumendid ja muud teabekandjad tuleb tähistada vastavalt ,,Perioodi 2014–2020 struktuuritoetuse andmisest avalikkuse teavitamise, toetusest rahastatud objektide tähistamise ning Euroopa Liidu osalusele viitamise nõuded ja kord'' määrusele. Poolte vahelised teated ja kontaktisikud Tellija kontaktisikuks lepingu täitmisel on Maris Vaino , sotsiaalkaitse talituse projektijuht , telefon +372 53 442 200 , e-post: [email protected] . Täitja kontaktisikuks lepingu täitmisel on Eliis Väert , projektijuht, telefon +372 502 1150 , e-post: [email protected] . Täitja kontaktisik on: Aleksandr Knjazetski, tiimijuht, telefon +372 58 553 059 , e-post: [email protected] . Lepingu kehtivus Leping jõustub sellele poolte poolt allakirjutamisest ja kehtib kuni poolte poolt oma lepinguliste kohustuste täitmiseni. Tellijal on õigus leping igal ajal üles öelda, teatades sellest 60 kalendripäeva ette. L õppsätted Lepingu täitmisel tekkinud vaidlused ja lahkarvamused lahendavad pooled läbirääkimiste teel. Kokkuleppe mittesaavutamisel lahendatakse vaidlused Harju Maakohtus. Lepingu täitmisel ja lepingust tulenevate vaidluste lahendamisel lähtutakse Eesti Vabariigi õigusaktidest. Pooled ei tohi lepingust tulenevaid õigusi ja kohustusi üle anda kolmandatele isikutele ilma teise poole kirjaliku nõusolekuta. Lepingu dokumendid koosnevad käesolevast lepingust, lepingu lisadest ning lepingu muudatustest, milles pooled võivad kokku leppida lepingu allakirjutamise järgselt. Lepingu lahutamatuteks osadeks lepingu sõlmimise hetkel on järgmised dokumendid: Lisa 1 - Hankelepingu eseme tehniline kirjeldus; Lisa 2 – Äriline kirjeldus. Poolte allkirjad Tellija Täitja /allkirjastatud digitaalselt/ / allkirjastatud digitaalselt / Lisa 1. Tehniline kirjeldus Elatisabi maksmise teenuse analüüs Mõisted ja lühendid Mõiste/Lühend Kirjeldus SKA Sotsiaalkindlustusamet TEHIK Tervise ja Heaolu Infosüsteemide Keskus SKAIS2 Sotsiaalkaitse infosüsteem (hõlmab ametnikurakendust ja iseteenindust) SKA iseteenindus Sotsiaalkindlustusameti iseteenindus E-täitur Kohtutäiturite infosüsteem EBS Majandustarkvara Oracle E- Business Suite Ülevaade Sotsiaalkindlustusamet kasutab elatisabi maksmise teenuse haldamiseks ja ülesannete täitmiseks SKAIS2 infosüsteemi. SKAIS2s on kasutusel elatisabiteenus, puude raskusastme tuvastamine, sotsiaaltoetuse teenus, peretoetused ja sügisest ka abivahendite teenus. Sotsiaalkindlustusameti teenuste kasutajate jaoks on arendatud Sotsiaalkindlustusameti iseteenindus, kus kasutaja saab enda jaoks vajalikke toiminguid teha lihtsalt ja kiirelt. Iseteeninduses kuvatakse praegu isikuandmetega seotud infot, isikule maksete teostamise infot, perehüvitiste teenuseid ja abivahendite teenust. SKAISis olevate teenuste finantsarvestust, raamatupidamiskandeid ja väljamakseid teostatakse Oracle E- Business Suite majandustarkvaras. Elatisabi kuni 100 eurot kuus maksab riik lastele, kelle vanem või vanemad ei täida ülalpidamiskohustust. Elatisabi on hetkel võimalik taotleda nii kohtumenetluse kui täitemenetluse ajal. Muutmisel on perehüvitise seadus, millega lisandub õiguslik alus elatisabi maksmiseks riigi poolt ka pankrotimenetluse ajal ehk lisandub uus teenus. Hankelepingu eesmärk H ankelepingu eesmärgiks on teostada detailanalüüs elatisabi maksmise e- teenu sele, et s elgitada välja edasised arendusvajadused. Tellitavad tööd Järgnevalt kirjeldatakse hankelepingu alusel teostatavad tööd. Analüüsida elatisabi maksmise teenust lähtudes äriliste eesmärkide k irjeldusest ( lisa 2). Analüüsida elatisabi maksmise teenust koostöös SKA ja TEHIKuga ning kaasates vajalikul määral lõppkasutajaid. Analüüsis tuleb kirjelda da lahendused uue elatisabi teenuse proaktiivseks pakkumiseks kui ka olemasolevate elatisabi teenuste õigustatud isikule mugavalt kättesaadavaks tegemiseks. Analüüsitööde jooksul luua vajalikud kasutajalood ning prototüüp loodavast lahendusest , sh testida prototüüpi lõppkasutajatega . Luua prioriseeritud tööde nimekiri ( backlog ) koostöös SKA ja TEHIKu ga . Tööde nimekiri peab olema kirjeldatud detailsusega, mille alusel on võimalik iga töö mahu suurusjärku hinnata. Anda prioriseeritud tööde nimekirjas ( backlogis ) olevatele töödele mahuhinnangud. Tööde teostamine Tööde teostamisel tuleb arvestada: Olemasoleva elatisabi teenuse käsitlusega ; Loodava elatisabi teenuse käsitlusega, Olemasoleva SKAIS2 andmebaasi struktuuriga; Olemasoleva SKAIS2 rakendusega ja arhitektuuri nõuetega, sh olemasolevate väliste liidestega; Teenuseosutajatega arveldamine käib e-arvete keskkonna Fiteki kaudu; Loodud prototüüpidega SKAIS2 ametnikurakenduse ja iseteeninduse kohta; Raamlepingus kokku lepitud mittefunktsionaalsete nõuetega; Raamlepingus kokku lepitud dokumenteerimise nõuetega; Raamlepinguga kokku lepitud kodukorraga. Järgnevalt on välja toodud tööde teostamiseks vajaminevad keskkonnad ja nende ligipääsud. SKAIS2 - projekti dokumentatsioon Confluence’i keskkonnas; Jira – backlog ja teostatud kasutuslood; Iseteeninduse prototüüp (kodaniku vaade); Gitlab – koodikeskkond. Tööde tulemid Punktis 4 välja toodud tööd antakse üle hiljemalt 08 . 03 .202 1 Confluence'i keskkonnas. Üle antav detailanalüüs peab si saldama : valdkonna põhimõistete kirjeldust; tänase olukorra kirjeldust ja hetkeolukorraga võrreldes lisanduvaid nõudeid ja vajadusi; kirjeldust, kuidas e latisabi maksmise teenus hakkab andmeid vahetama teiste infosüsteemidega; andmekoosseisusid; andmevoogude diagrammid; äriliste tööprotsesside kirjeldusi ja eesmärke; ärireeglite ja -nõuete kirjeldust , sh vajalikke kasutuslugusid; ülevaadet arendusega seotud tehnilistest komponentidest ja asendatavatest SKAIS2 k omponentide funktsionaalsustest; arendustest lähtuvaid muudatusi andmemudelis ja arhitektuurilises pildis ; lahendustest lähtuvaid muudatusi süsteemi lä bipaistvuse/ jälgitavuse parandamiseks . Loodava lahenduse prototüüp koos lõppkasutajate testimise infoga (prototüüpi testinud lõppkasutajate arv, aeg ja tagasiside) . Prioriseeritud tööde nimekiri ( backlog ) , sh vajalike liideste loetelu. Tööde nimekiri koos mahuhinnangutega. Tööde teostamise tähtaeg Tööde üleandmise lõpptähtaeg on 08 .03 .2021 . Tööd antakse üle Confluence’i keskkonnas. Tööde üleandmisele järgneb tellija poolne tööde vastuvõtmisaeg mõistliku aja jooksul ja vajadusel täitja poolne paranduste tegemine üle antud töödes, kui ilmneb, et tööd ei ole lõpptähtajaks teostatud nõuetekohaselt. Lisa 2. Äriline kirjeldus Ä riline kirjeldus P rojekti nimetus Elatisabi maksmise teenuse analüüs E e smärgid Analüüsi raames otsitakse vastuseid küsimustele: Kuidas pakkuda õigustatud sihtgrupile teenust intutiivse , lihtsa ja läbipaistavana? Kuidas teha teenus õigustatud sihtgrupile mugavalt kättesaadavaks? Kuidas kasutada erinevates registrites olemasolevaid andmeid halduskoormuse vähendamiseks? Analüüsi eesmärk on leida parim võimalik lahendus elatisabi tervikliku teenuse elektroonseks pakkumiseks ning anda vajalik sisend arendustöödeks, et saavutada järgmine olukord: Elatisabi teenused on läbipaistvad ja õigustatud isikud saavad infot neile vajalikul ajal; Loodud on pankrotimenetlusaegses elatisabi teenuse proaktiivne tehniline lahendus. Tänane olukord e hk analüüsi lähteolukord Elatisabi makstakse perehüvitiste seaduse alusel lapsele, kelle vanem või vanemad ei täida ülalpidamiskohustust. Riigi poolt hüvitatava elatisabi suurus on 100 eurot kuus. Elatisabi on hetkel võimalik taotleda nii kohtumenetluse kui täitemenetluse ajal. Olemasolev elatisabi teenus ei ole hetkel õigustatud sihtgrupile teada ning soov on kujundada kohtumenetlusaegne ja täitemenetlusaegse elatisabi teenus läbipaistvamaks ja selle kasutus lihtsaks ning intu i tiivseks. Ühtlasi ei kasutata t äitemenetlu saegse elatisabi teenuse osas ära tehniliste tõkete tõttu maksimaalset registrites olemasolevaid andmeid tekitades sellega õigustatud sihtgrupile kui ka teenuse erinevatele osapooltele (SKA, EMTA, kohtutäiturid) täiendavat halduskoormust. Lisaks olemasolevatele teenustele lisandub seoses perehüvitise seaduse muudatusega uus elatisabi maksmise teenus – pankrotimenetlu saegne elatisabi maksmine . Siseministeeriumi poolt koostatava seaduseelnõuga tekib õiguslik alus maksta riigi poolt lastele, kelle vanemad osalevad pankrotimenetluses, elatisabi. Uus lisanduv pankrotimenetlusaegse elatisabi maksmise teenus on tarvis kujundada proaktiivseks sarnaselt teistele riiklikele sotsiaalteenustele SKA iseteenindusse. Soovitud olukord ja eesmärk Allpool on välja toodud erinevad teenuse komponendid, mille osas on vaja teha analüüs, et leida parim võimalik arenduslahendus. L ahendusvariantide analüüsis on oluline kaasata erinevate osapoolte esindajaid , sh lõppkasutajaid . 2.1. Pankroti menetlus aegse elatisabi maksmise teenuse kujundamine U us lisanduv pankroti menetlus aegne elatisabi maksmise teenus on soov kujundada SKAIS2-te. Eesmärk on luua uue teenuse protsess lihtsaks ning intuitiivseks sarnaselt teistele SKAIS2-s juba olemas olevatele teenustele. Koostöös SKA ja protsessi osapoolte esindajatega tuleb analüüsida pankrotimenetlusaegne elatisabi maksmise teenust ja leida parimad lahendused selle välja arendamiseks. P ankrot i menetlus aegne elatisabi maksmise teenuse lahendus peab võimaldama näiteks : kontrollida ametnikurakenduses vajalikke tingimusi õigustatud isikule pakkumuse koostamiseks; koostada õigustatud isikule elatisabi pakkumust, pakkumust muuta ja vaadata; pakkumuse edastamist õigustatud isikule; õigustatud isikul pakkumuse vastuvõtmist ja kinnitamist; makseraportite genereerimist ja kohtutäituritele edastamist ; jt vajalikke funktsionaalsusi. 2 . 2 Täitemenetlusaegse elatisabi maksmise teenuse protsessi tehniliste takistuste parandamine Eesmärk analüüsida tänaseid täitemenetlusaegseid elatisabi maksmise teenuse protse ssi tehnilisi takistusi ja puuduseid ning teha ettepanekud analüüsis protsessi parendamiseks ja lihtsustamiseks protsessis osalevate osapoolte (nt kohtutäiturid) vaates . Näiteks automaatkontrollide täiendamine, võlgniku põhiste kontrollide täiustamine, kohtutäituritele tagasiside makseteatise vastuvõtmisest keeldumise kohta , ametlike teadaannetega andmevahetuse loomine jt funktsionaalsuste osas. 2 . 3 Elatisabi maksmise teenuse protsessi iseteenindusse viimine Koostöös SKA ja kasutajagruppide esindajatega analüüsida elatisabi maksmise teenuse protsessi viimist iseteenindusse. Eesmärk analüüsida läbi vajalikud funktsionaalsused ja leida võimalikud iseteeninduse täiendusvajadused, mis parendaksid elatisabi maksmise teenuse kättesaadavust ja lihtsat kasutamist õigustatud isikutele, vähendades ühtlasi protsessi erinevate osapoolte halduskoormust. ASUTUSESISESEKS KASUTAMISEKS Märge tehtud 05.01.2021 Kehtiv kuni 05.01.2026 Alus: AvTS § 35 lg 1 p 17 Teabevaldaja: Tervise ja Heaolu Infosüsteemide Keskus Helina Aunapuu Riigi Infosüsteemi Amet Teie nr [email protected] Meie 06.01.2021 nr 6-2/3169-3 Pärnu mnt 139a Tallinn, 15169 Projekti nr 2014- 2020.12.03.20-0813 "Elatisabi teenuse analüüs" täistaotluse esitamine Esitame projekt nr 2014- 2020.12.03.20-0813 „Elatisabi teenuse analüüs“ täistaotluse. Palume määrata projekti lõpliku toetuse suuruseks 71 445 (seitsekümmend üks tuhat nelisada nelikümmend viis) eurot ning kinnitame omafinantseeringu katmise omavahenditest summas 12 610 (kaksteist tuhat kuussada kümme) eurot. Palume lisada abikõlblikkuse perioodi pikkuseks 3 kuud. Lugupidamisega (allkirjastatud digitaalselt) Katrin Reinhold Direktor Maris Vaino [email protected] Uus-Tatari 25 / 10134 Tallinn / 794 3900 / [email protected] / www.tehik.ee / registrikood 70009770

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