Raamleping

Han g e „Kohtute infosüsteemi arendustööd“ (296052) Arendusmetoodika Sisukord TOC \o "1-3" \h \z \u 1. Eesmärk ja ulatus PAGEREF _Toc207028145 \h 4 2. Põhiprintsiibid (miks ja kuidas) PAGEREF _Toc207028146 \h 4 3. Projekti läbiviimise metoodika PAGEREF _Toc207028147 \h 4 3.1. Arendusmetoodika Scrumban + Dual-Track Agile PAGEREF _Toc207028148 \h 4 3.1.1. Scrum PAGEREF _Toc207028149 \h 5 3.1.2. Kanban PAGEREF _Toc207028150 \h 5 3.1.3. Dual-Track PAGEREF _Toc207028151 \h 5 3.2. Sprinti tsükli neli sammu PAGEREF _Toc207028152 \h 6 3.3. Rollid PAGEREF _Toc207028153 \h 6 3.4. Töökorraldus ja kasutatavad tööriistad PAGEREF _Toc207028154 \h 6 3.4.1. Jira töövoog Delivery-töödele (Story, Task, Bug) PAGEREF _Toc207028155 \h 7 3.4.2. Jira töövoog analüüsiülesannetele (Analysis issue type) PAGEREF _Toc207028156 \h 7 3.5. Tseremooniad PAGEREF _Toc207028157 \h 9 3.6. Artefaktid PAGEREF _Toc207028158 \h 9 3.7. Keskkonnad PAGEREF _Toc207028159 \h 9 4. Planeerimine ja prioriseerimine PAGEREF _Toc207028160 \h 10 4.1. Release plaan PAGEREF _Toc207028161 \h 10 4.2. Versioonide haldus Jiras (praktika) PAGEREF _Toc207028162 \h 10 5. Kvaliteet ja testimine PAGEREF _Toc207028163 \h 11 6. Incident management ja pidev parendamine PAGEREF _Toc207028164 \h 13 6.1. Eesmärk PAGEREF _Toc207028165 \h 13 6.2. Mõisted PAGEREF _Toc207028166 \h 13 6.3. Elutsükkel PAGEREF _Toc207028167 \h 13 7. Dokumenteerimine PAGEREF _Toc207028168 \h 13 7.1. Arendatava süsteemiga kaasnev dokumentatsioon PAGEREF _Toc207028169 \h 14 8. Kommunikatsioon PAGEREF _Toc207028170 \h 14 8.1. JIRA PAGEREF _Toc207028171 \h 14 8.2. Confluence PAGEREF _Toc207028172 \h 14 8.3. E-kiri PAGEREF _Toc207028173 \h 15 8.4. Koosolek PAGEREF _Toc207028174 \h 15 8.5. Teams PAGEREF _Toc207028175 \h 15 8.6. Telefon PAGEREF _Toc207028176 \h 15 Eesmärk ja ulatus Käesoleva dokumendi eesmärk on kirjeldada ühtset, korratavat ja mõõdetavat tarkvaraarenduse metoodikat, mis: lühendab idee → tootmine tsüklit; tõstab kvaliteeti ja turvalisust ; eristab ja sünkroniseerib analüüsi (Discovery) ja arenduse (Delivery) tööd. Metoodika katab ideatsiooni, analüüsi, planeerimise, arenduse, testimise, väljalasked, tootmistoe ja pideva parenduse. Põhiprintsiibid ( miks ja kuidas) Väärtus esimesena – prioriseerime töö ärilise mõju järgi. Väikesed inkremendid – tarnime väikestes, releasitavates tükkides; väldime pikki „big-bang“ väljalaskeid. Läbipaistev voog + mõõdikud – juhime voogu andmetega ( tarneaeg, teostusaeg, pooleliolevate tööde arv, valmis tööde arv ajaperioodis). Kvaliteet sisse ehitatud – testide püramiid, koodireview, kvaliteedi väravad ( quality gates ) ; kvaliteet on iga sammu osa. Security & privacy by design – GDPR, least privilege, audit; turve ja privaatsus on disainis, mitte „pärast“. DevOps-kultuur – “You build it, you run it”, CI/CD ja jälgitavus; tiim vastutab nii ehituse kui opereerimise eest. Projekti läbiviimise metoodika Arendusmetoodika Scrumban + Dual-Track Agile Projekti läbiviimiseks kasutame agiilset metoodikat. Agiilne tarkvaraarendus baseerub põhimõtetel, mille järgi tarkvara nõuded ja lahendused arenevad inkrementaalselt läbi pideva koostöö arendusmeeskonna ja kliendimeeskonna liikmete vahel. See võimaldab kiiret ja paindlikku arendusprotsessi, inkrementaalset tarkvara valmimist. Arendusprotsessis kasutame Scrumban’it ( Scrum + Kan ban ) koos Dual-Track Agile’iga: Scrum’i rütm annab ennustatavuse, Kan bani voo-juhtimine hoiab fookuse ja piirab WIP-i (töösolevate ülesannete arvu). Dual-Track eristab paralleelselt töötavad rajad: Discovery (analüüs) ja Delivery (arendus), vähendades ebakindlust ning võimaldades tarnida väärtust väikeste, sagedaste inkrementidena. Dual-Track rakendub juhtudel, kus analüüsi tuleb teha paralleelselt arendusega (uus domeen, keerukad integratsioonid, kriitilised NFR-id). Kui ebakindlus on madal, piisab tavapärasest grooming’ust . Muidu töötab Discovery umbes 1 sprindi võrra ees ja täidab Next Sprint Ready (NSR) padi järgmise sprindi planeerimiseks. Scrum Scrum jagab suure töö lühikesteks sprintideks (tavaliselt 2 nädalat; alati < 1 kuu). Iga sprindi lõpus on releasitav inkrement . Sprintide väärtus on sage tagasiside ja paindlik planeerimine . Kanban Kanbani põhimõtted Scrumbanis: WIP-piirangud → vähem kontekstilülitusi, rohkem „Done“. Pull-süsteem → töö liigub edasi, kui järgmine samm on valmis seda võtma. Pudelikaelad on nähtavad (tahvel, ageing): kui mõnes olekus (nt testimine, code review) kasvab saba, aitame enne need tööd ära lõpetada , mitte ei alusta uut. Reaalajas prioriseerimine enne sprindi algust; sprindi sees väldime tormamist ja skoobi muutmist. Näited: Code Review ummistus: tiim ei alusta uut tööd enne, kui review’d on tehtud → voog taastub. Töö vananemine: tahvel näitab „vananevaid“ kaarte → uurime takistusi, tükeldame tööd või täpsustame vastuvõtukriteeriumeid. Hotfix: võib minna järjekorrast mööda (WIP-erand, tooteomaniku heakskiidul ), kuid logime ja mõõdame, et see ei muutuks normiks. Dual-Track Dual-Track lühiidee seisneb selles, et töötame kahel paralleelsel rajal: Discovery (analüüs) vähendab ebakindlust ja valmistab järgmise sprindi jaoks valmis piletid. Discovery töötab 1 sprindi võrra ees ja täidab Next-Sprint-Ready-padja (eesmärgiks ≥ 1 sprindi tööülesanded). Delivery (arendus) ehitab, testib ja tarnib väikeste release’de kaupa . Kui ebakindlus on madal, piisab tavapärasest grooming’ust - Dual-Tracki ga pole vaja üle pingutada. Grooming (backlog refinement ) käigus tooteomanik ja tiim täpsustavad ja tükeldavad backlogi , lisavad aksepteerimiskriteeriumid, hinnangud ja prioriteedid , eemaldavad vananenud kirjed. Groomingu väljundiks on “ Next Sprint Ready ” tööülesanded. Sprinti tsükli neli sammu Sprinti planeerimine Tiim lepib kokku sprindi eesmärgi ja tööde nimekirja. Koosolek on “ lean ” – keskendume ainult sellele, mis peab järgmise 1–2 nädala jooksul valmis saama. Igapäevased stand-up’id (päevakoosolekud, ~15 min) Lühikesed ja sagedased sync’id, kus iga tiimiliige vastab kolmele küsimusele: Mida tegin eile? Mida teen täna? Mis mind takistab (blocker)? Eesmärk on hoida fookust, leida takistused varakult ning tõsta vastutustunnet tiimis. Sprinti ülevaatus (Review) Sprindi lõpus näitab tiim valmis inkrementi sidusrühmadele ja kogub tagasisidet . Retrospektiiv (Retro) Vaadatakse üle protsess : mis läks hästi, mis vajab parandamist, milliseid töövõtteid või tööriistu tuleb kohandada. Rollid Product Owner (PO) – omab visiooni ja otsustusõigust ; kogub ja tasakaalustab sidusrühmade vajadusi; hoiab ja prioriseerib backlogi . Scrum Master / Agile Coach – hoiab protsessi terve ja voolavana; eemaldab takistused , fasiliteerib tseremooniaid (planning, daily, review, retro) ning toetab tooteomanikku . Arendustiim – äri- ja süsteemianalüütikud, arendajad, testijad, kasutatavuse/UX-spetsialistid, DevOps-insenerid ; vastutavad ühiselt “Done” eest. Sidusrühmad (stakeholders) – kõik, kes toodet mõjutavad või on selle ga mõjutatud (kliendid, kasutajad, äripooled, tehnilised tiimid, tarnijad jm). Nendega tehakse regulaarsed demod ja jagatakse roadmap’i ülevaateid. Töökorraldus ja kasutatavad tööriistad Dokumentatsiooni hoiame Atlassiani Confluences: siia koonduvad analüüsi põhidokumentatsioon, UX-vood ja prototüübid, API-spetsifikatsioonid ja andmemudeli mustandid, arhitektuuridokumendid, koosolekute memod ja kokkulepped. Tööülesandeid haldame Atlassiani Jiras. Iga Jira kaart viitab vastavale Confluence’i dokumendile, et üks tõeallikas oleks alati käepärast ning dokumentatsioon elaks samas rütmis koodiga. Jira töövoog Delivery-töödele (Story, Task, Bug) Jira töövoog Delivery-töödele (Story, Task, Bug) peegeldab tahvlit järgmise loogika järgi: Backlog Do →To Do → In Progress /Reopen → Code Review → Ready for internal test Do → Ready for UAT Do → Done Kuidas kirje liigub Millal kirje liigub Olulised väravad Backlog → To Do Töö tõmmatakse sprinti; assignee lepitakse kokku sprindi alguses (vajadusel muudetakse sprindi käigus nt daily- koosolekul). Selge eesmärk, aksepteerimiskriteeriumid, UX/API/NFR-lingid, sõltuvused kirjeldatud. To Do → In progress Arendaja alustab tööd ja märgib kaardi In Progress . - In Progress → Code Review Implementatsioon on valmis; Merge Request on avatud. Avatud Merge request, Esmane CI (build) on edukas. Code Review → Ready for Internal Test Code Review on edukalt läbitud; Kood on heaks kiidetud ja merge’tud; Automaat- ja kokkulepitud E2E testid käivitatud (testid on “rohelised”). Automaat- ja kokkulepitud E2E testid rohelised Ready for Internal Test → Ready for UAT Sisemine testimine läbitud, defektid on suletud või eraldi bug’ina backlog’is. Sisemine testimine läbitud Ready for UAT → Done Kli e nt/tooteomanik aksepteerib valminud töö (vastuvõtukriteeriumid on täidetud) Kood merge’itud, testid “rohelised”, dokumentatsioon on uuendatud. →Reopen Kui review, automaattestide, sisemise või kliendi testimise käigus ilmneb tõrge, tehakse Reopen , et arendaja saaks vea kohe parandada. Jira töövoog analüüsiülesannetele (Analysis issue type) Ideatsioon Kuidas töö jõuab analüüsi: Ideatsioon → Discovery → “Analysis” issue kaart . Eesmärk: püüda kinni kõik ideed, hinnata need kiiresti ja ühtsete kriteeriumide alusel ning saata ainult parimad lühikesse, Discovery’sse , kust sünnivad analüüsimiseks piletid. Ideede allikad: Kasutajad & kliendid: intervjuud, küsitlused, töötoad, kasutajatega testimine. Äri: KPI vajadused, turu- või regulatiivsed nõuded. Operatsioonid: incidentide õppetunnid, monitooringu ja logide leiud. Tehnika: tehnilised võlad, jõudluse/turbe auditid, arendajate ettepanekud. Igal ideel peab olema minimaalselt: Probleemikirjeldus (mitte lahendus!), väärtushüpotees + mõõdik/KPI , Sihtkasutaja/segment , Riskid/sõltuvused , Omanik . Ideatsiooni tulem on läbi vaadatud ja hinnatud ideed (probleem, väärtushüpotees ja mõõdetav tulemus) ning heakskiidu korral loodud “Analysis” pilet(-id) , millega analüütik võib hakkata tegelema. Analüüs Jira töövoog analüüsiülesannetele (Analysis issue type) on lühem ja toetab Dual-Track’i: To Do → In Progress → Review → Done Kuidas kirje liigub Millal kirje liigub Olulised väravad → To Do Idee on heaks kiidetud (probleem, väärtushüpotees ja ootused KPI-le on sõnastatud); Sidusrühmad, piirangud, eeldused on defineeritud; Link Idea kaardile või Confluence’i idee logile Idee on ära kirjeldatud, sh on sõnastatud probleem, väärtushüpotees ja ootused. To Do → In progress Analüü ti k alustab valitud teema analüüsimisega; - In Progress → Review Analüüsidokumendid on ülevaatamiseks valmis, sh: Confluence’I analüüsidokumendi leht on valmis; Jira arenduspiletid on loodud ja lingitud Analüüsidokumendid on lisatud conflence’I; Loodud Jira pilet(id), sh aksepteerimiskriteeriumid (UX/API/andmemudeli lingid, NFR-id, sõltuvused. Handover (tulemuse tutvustamine) kliendile on tehtud. Review → Done Kli e nt/tooteomanik aksepteerib tulemuse. →Reopen Kui valminud töö vajab täiendust . Tseremooniad Backlog Refinement (1× nädalas, 45–60 min): backlog on täidetud? Definition-of-Done on ok? Sprint Planning (≤ 2 h): tõmbame töö backlogist ; eesmärk + vastuvõtukriteeriumitest ühtne arusaam. Daily (15 min): fookus voo takistustele (mitte status-report). Demo/Review (45–60 min): releasitav inkrement + tagasiside sidusrühmadelt. Retrospektiiv (45 min): 1–2 konkreetset parandusmeedet järgmisse sprinti. Discovery Sync (15–20 min, 1x sprindi lõpus): backlogi tervis, takistused. Artefaktid Product Backlog – üks tõeallikas (äri + tehnilised). Roadmap & Release Plan – kvartali sihid, ajaaknad, sõltuvused. DoD – kvaliteediväravad nii Analysis’ele kui Delivery’le. Testistrateegia & riskiregister – nähtavus NFR-idele ja riskidele. ADR-id (Architecture Decision Records) – lühikesed, versioneeritud. Keskkonnad Soovitame minimaalselt seadistada järgmised keskkonnad: Keskkond Kelle oma/Kus asub Mille jaoks Paigald us Git haru DEV Arendusmeeskond Sisemise testimise jaoks arendusmeeskonna poolt Automaatne release, develop või feature TEST Arendusmeeskonna või kliendi oma Kliendi/tiimi vahetestide ja UAT jaoks Manual ne release, develop, main/ master või muu kokku lepitud LIVE Kliendi oma Toodangukeskkond Manual ne (kontrollitud aja aknas) M ain/m aster Planeerimine ja prioriseerimine Release pla a n Projekti alguses koostatakse projektiplaan , mille eesmärk on fikseerida sihtseis, tööpaketid ja nende järjestus, peamised verstapostid, sõltuvused, riskid ning esmane release’i graafik . Plaanist saab baasjoon (baseline), mida uuendatakse ainult kokkulepitud muudatusprotsessi kaudu. Projekti teostus on jaotatud etappideks , iga etapp omakorda sprintideks (soovituslikult 2-nädalased). Iga sprint on lühike ajaraam, mille lõpus valmib potentsiaalselt releasitav inkrement . Etappi võib käsitleda kui väikest alamprojekti: etapi tulemuseks on konkreetne tarkvaraversioon (release candidate), mis on valmis tootmisesse viimiseks. Iga sprindi lõpus toimub valideerimine ja ülevaatus . Tiim demonstreerib valminud funktsionaalsust, tehakse QA-testid ning kogutakse tagasisidet. Kliendi esindajad (eelkõige tooteomanik) osalevad ülevaatusel/katsetustel, et kontrollida aksepteerimiskriteeriumide täitumist ning kinnitada, kas inkrement vastab ootustele. Pärast ülevaatust peetakse retrospektiiv , kus hinnatakse sprindi kulgu ja lepitakse kokku parendused; vajadusel korrigeeritakse plaani ja backlogi prioriteete. Iga etapi lõpus viiakse läbi täismahus regressioonitestid (sh kriitiliste ärivoogude E2E, jõudlus ja mittefunktsionaalsed nõuded). Seejärel valmistatakse ette väljalase tootmisse : koostatud on release notes, andmemigratsioonid on testitud, monitooring ja alertid on seadistatud, ning olemas on rollback-plaan . Paigaldus toimub kooskõlastatud aknas. Pärast paigaldust on kokkulepitud hypercare-periood , mil jälgitakse süsteemi tervist ja lahendatakse kiiresti võimalikud kõrvalekalded. Versioonide haldus Jiras (praktika) JIRA „Versions“ võimaldab planeerida ja koondadamuudatusi kindlateks release’ideks . Nimekonventsioon: MAJOR.MINOR.PATCH Näited: v1.4.0 (tavaline release), v1.4.1 (kiirparandus), v2.0.0 (suuremate muudatuste release). Põhireeglid Fix Version/s – versioon, kuhu muudatus parandati/valmib (seome kõik Story/Task/Bug piletid planeeritud versiooniga). Affects Version/s – versioon(id), kus viga esineb (kasutame bugide puhul tootmisvigade päritolu märkimiseks). Release – kasutame Jira Release vaadet, et näha, mis on valmis/pooleli/failed; sellest saab koostada Release Notes . Sprinti alguses märgib tooteomanik/tiim sprindis olevatele kaartidele eesmärgiks seatud Fix Version’i (nt v1.5.0 ). Release’i hetkel : Jira Release tehakse pärast edukat prod-deploy’d (mitte enne), Jira genereerib Release Notes (muudatuste loetelu) – link Confluence’i. Töövoog versioonidega Planeeri versioon Jiras (Project → Releases): nimi, sihtkuupäev. Seo piletid : lisa Fix Version kõigile tööläbivatele kaartidele - Kontrolli Release lehel : kas kõik „must-have“ kaardid on Done? Kui ei, de-scope (lükka ülejäänud järgmisse versiooni). Enne r elease ’i : tee regressioon ja NFR-testid. Prod-deploy -> Jira Release + Release Notes link. Kvaliteet ja testimine Meie arendusprotsess näeb ette, et edukas iteratsioon lõppeb potentsiaalselt valmis tarkvaraosaga, mida on võimalik lasta toodangusse. Just see eesmärk toob esile testimise olulisuse iteratsiooni jooksul. Kõik funktsionaalsused ja detailid, mis valmivad iteratsiooni jooksul peavad saama ka testitud selle iteratsiooni ajaakna sees, seega peavad kõik testimistegevused on planeeritud tervikliku iteratsiooni osana. Sisendid Süsteeminõuete ja funktsionaalsuse spetsifikatsioon ; Kasutajaliidese prototüüp ; valmiv funktsionaalsus. Protsess Testplaani koostamine Testide läbiviimine ja automatiseerimine Vigade haldus Tulemid Testplaan Testispetsifikatsioonid Testilogi Testide tüübid (näited) Ühiktestid – äriloogika ja validaatorid. Integratsioon / API / liidestused (nt Postman/SoapUI; automaatselt REST-/message-tasemel). Mooduli- ja süsteemitestid – „musta kasti“ vaade kasutaja tasemel. Kasutatavus (UX) – kasutusmugavus, ligipääsetavus. Code Review – vähemalt teine paar silmi; Merge Requesti osa. Installatsioonitestid – paigaldus, migratsioonid, rollback. Jõudlus/koormus – NFR-nõuete kontroll; kitsaskohtade leidmine. Valideerimine & verifitseerimine – spetsifikatsioon vs tegelik tulemus. Vastuvõtutest – kliendi allkirjastatav üleandmine; AC täidetud. Vastutused Ühiktestid – arendajad (soovitavalt test-enne ). Süsteemi-/integratsioonitestid jm testid (v. lõplik vastuvõtutest) – testijad koostöös analüütikute ja arendajatega; automatiseerimine on prioriteet. Vastuvõtutest – kliendi meeskond (tooteomanik/koostöös sidusrühmadega). Incident management ja pidev parendamine Eesmärk Tagada töökindlus ja kiire taastumine , minimeerida mõju ning õppida igast juhtumist, et vältida kordusi . Mõisted Intsident: ootamatu katkestus või kvaliteedilangus (nt aeglus, vead, turvarisk). Probleem: intsidentide juurpõhjus, mis vajab püsivat lahendust. Muutus (Change): plaanitud tegevus; erandina emergency change intsidenti leevendamiseks. Elutsükkel Tuvastus → Prioriseeri mine → Piiramine → Lahendus → Taastamine → Järelevalve (monitoring) → Sulgemine → Post-incident review Tuvastus: alert/logi/metrika või klienditeade. Prioriseeri : määra tõsidus, ava Jira “Incident” pilet. Piiramine: rollback/ressursi skaleerimine Lahendus & taastamine: juurpõhjuseni parandused, teenus taastatud. Antud samm võib käivitada Delivery töövoogu. Järelevalve: kõrgendatud monitooring (hypercare 24–72 h). Sulgemine ja Post-Incident Review : pane Jira pilet kinni , lisa vajalikud piletid backlog’i. Dokumenteerimine Eesmärk on tagada ajakohane ja kättesaadav info ning kiire ligipääs. Dokumentatsioon on integreeritud protsessi: Varane baasdokument – mustand valmis varakult; detailid täpsustuvad töö käigus. Elav dokument – kuni valmimiseni on dokument muutuv ; pärast kinnitamist versioonihaldus. Asukoht – kogu projekti dokumentatsioon hoitakse Confluence’is . Arendatava s üsteemiga kaasnev dokumentatsioon Arendusmeeskond koostab projekti käigus ja annab kliendile üle vähemalt järgmised dokumendid: Detailanalüüsi dokumendi (ärinõuded, protsessid, kasutajalood, liidestused, seadistused). Arhitektuuri dokumendi (lahendus, keskkonnad, võrgu- ja tarkvaranõuded, arendusplatvorm). Andmemudeli kirjelduse (skeemid, seosed). Juurutuse ja installeerimisjuhendid (paigaldus, migratsioonid, käitamine, hädade lahendus). Projektijuhtimise dokumentatsiooni (plaan, koosolekute memod, riskid/probleemid, aktid). Testplaani (ulatus, keskkonnad, meetodid, logimine). Riskiplaani (mõjud, tõenäosus, tegevuskavad; pidev uuendus). Koolitusmaterjalid Kommunikatsioon Suhtlemist ja projekti loomist toetavad keskkonnad ja vahendid . JIRA Jira on tööülesannete halduse keskne tööriist: arendused, vead, tööülesanded, intsidendid. Lepime kokku Jira kasutusreeglid (töövoog, versioneerimine jmt), et otsing ja aruandlus oleks ühtne . Veaparanduse või töö alguseks on registreerimine Jiras (e-kirjas mainimine ei asenda piletit). Confluence Confluence on dokumendikeskkond ja info vahetuse koht kliendi ja arendusmeeskonna vahel. Spetsifikatsioonid edastatakse ülevaatuseks/kooskõlastuseks Confluence’i kaudu. Info kustutamine on keelatud (v.a projektijuhtide kooskõlastusel). E-kiri Kasutame e-kirja siis, kui Jira/Confluence ei sobi (nt pikad arutelud → tulemus lisatakse hiljem Confluence’i). Vastamise ootus märgitakse selgelt; vastus ≤ 2 tööpäeva (v.a teavitused). Digiallkirjastatavad dokumendid edastatakse elektrooniliselt . Koosolek Kutsel on päevakord ; korralised koosolekud (analüüs, projekt) lepitakse varakult kokku. Korralisi koosolekuid võib tühistada , kui need ei lisa väärtust (nt analüütiku tööjärg ees). Teams Kiireks suhtluseks; oluline info korratakse e-kirjas või protokollitakse. Vajadusel luuakse eraldi jututuba projekti osapooltele. Telefon Operatiivseks suhtluseks ja kriisiolukordades; juurutuse ajal lepitakse kokku kättesaadavus ka väljaspool tööaega. Han g e „Kohtute infosüsteemi arendustööd“ (296052) Riskianalüüs Sisukord TOC \o "1-3" \h \z \u Riskianalüüsi metoodika PAGEREF _Toc207027447 \h 3 1. Esimese hankelepingu täitmisega seotud riskid PAGEREF _Toc207027448 \h 4 RISK-001 Ligipääsude viibimine KIS süsteemile ja selle dokumentatsioonile PAGEREF _Toc207027449 \h 4 RISK-002 Kasutajagruppidega kohtumiste kokkuleppimine ei õnnestu PAGEREF _Toc207027450 \h 4 RISK-003 Kasutajate antud info osutub ebapiisavaks või vastuoluliseks PAGEREF _Toc207027451 \h 4 RISK-004 Andmete struktuur KIS-is ei võimalda automaatset edastust RR-i PAGEREF _Toc207027452 \h 4 RISK-005 RR-i poolel andmete vastuvõtmiseks teenus puudub või selle valmimine venib PAGEREF _Toc207027453 \h 5 RISK-006 Kliendi poolsed otsused viibivad PAGEREF _Toc207027454 \h 5 RISK-007 Prototüüp ei vasta kasutajate ootustele PAGEREF _Toc207027455 \h 5 RISK-008 Kokkulepitud TO-BE protsess ei sobitu kõigile KIS kasutajagruppidele PAGEREF _Toc207027456 \h 5 RISK-009 Klassifikaatorite loetelu on ebajärjekindel või puudub RR’s PAGEREF _Toc207027457 \h 6 RISK-010 Dokumentatsiooni maht ja keerukus PAGEREF _Toc207027458 \h 6 2. Üldriskid PAGEREF _Toc207027459 \h 6 RISK-011 Kinnitatud ja kooskõlastatud ajakavast ei peeta kinni lepingu osapoolte süül PAGEREF _Toc207027460 \h 6 RISK-012 Täitja meeskonna oskused osutuvad ebapiisavaks PAGEREF _Toc207027461 \h 7 RISK-013 Täitja meeskonna suurus osutub ebapiisavaks PAGEREF _Toc207027462 \h 7 RISK-014 Lõpptulemusele esitatavaid nõudeid ei ole Täitja poolt mõistetud õigesti PAGEREF _Toc207027463 \h 7 RISK-015 Täitja poolt pakutud arhitektuu rilahendus ei sobi PAGEREF _Toc207027464 \h 8 RISK-016 Hankija ei ole tulemusega rahul PAGEREF _Toc207027465 \h 8 RISK-017 Täitja meeskonna motivatsiooni langus PAGEREF _Toc207027466 \h 9 RISK-018 Muudatuste juhtimine ei toimi PAGEREF _Toc207027467 \h 9 RISK-019 Suur osapoolte hulk projekti teostamisel PAGEREF _Toc207027468 \h 10 RISK-020 Funktsionaalsuse prioritiseerimine/ärianalüüsi mitteaktuaalsus PAGEREF _Toc207027469 \h 10 RISK-021 Disaini ja funktsionaalsuse kooskõlastamine ja osapoolte erinevate seisukohtade risk PAGEREF _Toc207027470 \h 10 RISK-022 Eelarvestus ajakavale ja ressurssidele on ebatäpne PAGEREF _Toc207027471 \h 11 RISK-023 Hankija mõni oluline inimkompetents vahetub PAGEREF _Toc207027472 \h 11 Riskianalüüsi metoodika Lähtudes ISO 9001:2015 standardi nõuetest me kasutame prosessikeskset lähenemist ning riskipõhist mõtlemist, mis võimaldab meil planeerida oma protsesse, hindades pidevalt, mis võiks minna valesti, millised riskid on olulised, ning kehtestada ennetavad ohjemeetmed negatiivsete mõjude vähendamiseks. Väga oluline on riskide ning nende realiseerumisega kaasnevate võimalike tagajärgede määratlemine nii varases projekti staadiumis kui vähegi võimalik. Selliselt käitudes oleme me võimelised võtma tarvitusele ettevaatusabinõusid, vältimaks võimaliku õnnetuse juhtumist, või vähendama mõjusid, mida õnnetuse juhtumine kaasa toob. Järgnev perioodiline projekti riskide ümberhindamine on projekti dünaamilise juhtimise protsessi lahutamatu osa. Projektimeeskond hindab riske pidevalt ning kasutab neid otsuste tegemisel kõikides projekti etappides. Käesoleva pakkumise raames kavandame projekti riskijuhtimist järgnevate tegevustena: Riskide esmane kaardistamine, tuvastatud riskide tõenäosuse ja mõju kvalitatiivne hindamine – projekti võtmeisikute workshop koos riskimaatriksi koostamisega, Riskijuhtimise meetmete (vältimine, siirdamine, maandamine, aktsepteerimine) määramine tuvastatud riskidele, Riskijuhtimise rollide ja personaalse vastutuse seadmine kogu projektorganisatsioonis, Projekti edenemise käigus teostatavate regulaarsete riskide ümberhindamiste protseduuride kokku leppimine. Meie praeguses nägemuses on kavandatava projekti mahtu arvestades vajalik riskide ümberhindamine minimaalselt enne ja pärast iga arendusetappi. Eeldatavasti muutub erinevate riskirühmade (planeerimise risk, finantsrisk, kasutatava tehnoloogia sobimatuse risk, seaduste või haldusstruktuuri muutumise risk, projektimeeskonna võtmeisikute isikurisk jne) osatähtsus projekti edenedes, mistõttu ei ole harvemini teostatav riskide hindamine piisav. Riskide analüüsimisel hindasime nende esinemise tõenäosust ( skaalal „madal/keskmine/kõrge“ ) ning riski mõju (samuti skaalal „madal/keskmine/kõrge“) . Alljärgnevat toome välja REF _Ref206506215 \h \* MERGEFORMAT Esimese hankelepingu täitmisega seotud riskid ja REF _Ref206506222 \h \* MERGEFORMAT Üldriskid ning nende maandamise viisid tagamaks projekti eduka realiseerumise. Suurimad riskid on seotud suure hulga inimeste kaasamisega ja ühistöö korraldamisega. Esimese hankelepingu täitmisega seotud riskid RISK-0 01 Ligipääsude viibimine KIS süsteemile ja selle dokumentatsioonile ID RISK-0 01 Kirjeldus Ligipääsud KIS süsteemile ja selle dokumentatsioonile ei tule õigeaegselt , mis takistab andmestruktuuride või protsesside analüüsi . Tõenäosus Keskmine Mõju Kõrge Tulemus/tagajärg Tööd hilinevad , mitme etapi töödega ei saa alustada ( nt andmeanalüüs ja prototüüp ). Maandamismeetmete kirjeldus Taotleda ligipääsud kohe pärast projekti algust . K asutada vajadusel dump- andmeid või näidiseid . RISK-0 02 Kasutajagruppidega kohtumiste kokkuleppimine ei õnnestu ID RISK-0 02 Kirjeldus Kasutajad ei leia aega sisendikohtumisteks või ei osale piisava aktiivsusega . Tõenäosus Keskmine Mõju Keskmine Tulemus/tagajärg Vajaduste analüüs jääb ebatäpseks või puudulikuks . Maandamismeetmete kirjeldus Planeerida kohtumised aegsasti , leida asendusisikud või kasutada kirjalikke küsimustikke . RISK-0 03 Kasutajate antud info osutub ebapiisavaks või vastuoluliseks ID RISK-0 03 Kirjeldus Intervjuudes saadud sisend ei pruugi peegeldada tegelikke tööprotsesse või rollierinevusi . Tõenäosus Keskmine Mõju Keskmine Tulemus/tagajärg TO-BE protsesside ja vormide disainis võivad esineda vead või vajalike funktsioonide puudumine . Maandamismeetmete kirjeldus Struktureeritud küsimustikud , mitme allika võrdlus , kordusintervjuud . RISK-004 Andmete struktuur KIS-is ei võimalda automaatset edastust RR-i ID RISK-004 Kirjeldus Osa vajalikest andmetest on vabatekstina lahendi failis , mitte struktureerituna . Tõenäosus Madal Mõju Kõrge Tulemus/tagajärg Automaatsest edastusest ei piisa, tuleb arvestada käsitööga või KIS muudatustega. Maandamismeetmete kirjeldus Varajane andmeanalüüs ja andmelünkade kaardistus , vajadusel soovitused andmestruktuuri täiendamiseks . RISK-005 RR-i poolel andmete vastuvõtmiseks teenus puudub või selle valmimine venib ID RISK-005 Kirjeldus RR poolel puudub liides , mis võimaldaks struktureeritud andmete vastuvõttu KISist . Tõenäosus Keskmine Mõju Kõrge Tulemus/tagajärg KIS poolel luuakse liidesed, mis ei täida püstitatud eesmärke. Maandamismeetmete kirjeldus Antud riski tuleb arvesse võtta, kuna pole võimalik mõjutada RR poolel liidese valmimist. RISK-006 Kliendi poolsed otsused viibivad ID RISK-006 Kirjeldus Projekt ei saa liikuda järgmisesse etappi ilma kliendi kinnituste ja otsusteta . Tõenäosus Keskmine Mõju Kõrge Tulemus/tagajärg Projekti ajakava venib, suureneb ebaselgus ja korduvtegevuste vajadus. Maandamismeetmete kirjeldus Planeerida regulaarne otsuste ülevaatus ja tähtajad , tuletada aktiivselt meelde . RISK-007 Prototüüp ei vasta kasutajate ootustele ID RISK-007 Kirjeldus Prototüübi esmane versioon ei rahulda lõppkasutaja ootusi või ei toeta tööprotsesse. Tõenäosus Madal Mõju Keskmine Tulemus/tagajärg Tagasiside voorud pikenevad ja tuleb teha olulisi ümbertegemisi . Maandamismeetmete kirjeldus Iteratiivne prototüüpimine , vaheetapid ja kasutajate aktiivne kaasamine kujundusse . RISK-008 Kokkulepitud TO-BE protsess ei sobitu kõigile KIS kasutajagruppidele ID RISK-008 Kirjeldus KIS kasutajagruppide töökorralduses on piisavalt erinevusi , mis muudavad ühe universaalse protsessi keerukaks . Tõenäosus Keskmine Mõju Keskmine Tulemus/tagajärg Lahendus muutub keeruliseks või killustub mitmeks variandiks . Maandamismeetmete kirjeldus Töökorralduse võrdlus ettenähtud mahus , vajadusel mitmeprotsessiline lahendus . RISK-009 Klassifikaatorite loetelu on ebajärjekindel või puudub RR’s ID RISK-009 Kirjeldus Kohtulahendite resolutsioonide korrektne sidumine edastatavate andmetega eeldab ühtset ja kooskõlastatud klassifikaatorite loetelu ning selle rakendamist nii KIS-is kui RR-is. Tõenäosus Keskmine Mõju Keskmine Tulemus/tagajärg Ebapiisava või ebajärjekindla klassifikaatori kasutuse korral tekivad tõrked andmevahetuses, mis võivad põhjustada ebaõigeid või mittetäielikke kandeid RR-is. Maandamismeetmete kirjeldus Koostada esmase versiooni klassifikaatorite loetelust analüüsi käigus ja kooskõlastada see RR haldajaga; vajadusel algatada arendustööde eel täiendav liidestuse standardiseerimine. RISK-010 Dokumentatsiooni maht ja keerukus ID RISK-010 Kirjeldus Kasutajad või arendajad ei suuda keerulist analüüsitulemit täielikult mõista või kasutada. Tõenäosus Madal Mõju Keskmine Tulemus/tagajärg Arendus ei toimu vastavalt analüüsile või tehakse valesid eeldusi . Maandamismeetmete kirjeldus Luua struktureeritud dokumendimallid , kasutada visualiseeringuid ja lühikokkuvõtteid . Üldriskid RISK-0 1 1 Kinnitatud ja kooskõlastatud ajakavast ei peeta kinni lepingu osapoolte süül ID RISK-0 1 1 Kirjeldus Projekti ajakavast ei peeta kinni ja tähtajad nihkuvad Tõenäosus Keskmine Mõju Keskmine Tulemus/tagajärg Projekt ei valmi ettenähtud tähtajaks. Projekti eelarve võib suureneda. Maandamismeetmete kirjeldus Projekti alguses selgitatakse osapoolte ootused, kliendile selgitatakse eeldused koostööks Olulistel teemadel tehakse eelkokkuleped Jooksev suhtlus poolte vahel, tagasiside, aruandlus, meeldetuletused enne tähtaegade saabumist. Tegevuskava realiseerumisel Lepitakse kokku uued reaalsed tähtajad ja detailne tegevusplaan tähtajas püsimiseks. RISK-0 1 2 Täitja meeskonna oskused osutuvad ebapiisavaks ID RISK-0 1 2 Kirjeldus Täitja meeskond pole võimeline projekti kvaliteetselt realiseerima ja projekti realiseerimise ajakava lükkub edasi. Tõenäosus Madal Mõju Keskmine Tulemus/tagajärg Projekti tähtaegne ja kvaliteetne realiseerimine ei õnnestu. Maandamismeetmete kirjeldus Kasutame projektis kogemustega spetsialiste, keerukamate teemade puhul kaasatakse siseseid või väliseid eksperte Ei võeta üleliigseid tehnoloogilisi riske Tegevuskava realiseerumisel Keerukamate probleemide lahendamiseks kaasatakse lisaeksperte ja leitakse alternatiivsed lahendused. RISK-0 1 3 Täitja meeskonna suurus osutub ebapiisavaks ID RISK-0 13 Kirjeldus Täitja meeskonna suurus osutub ebapiisavaks (töötajate arv muutub vms) ja tööde teostamine võtab seetõttu planeeritust rohkem aega. Tõenäosus Madal Mõju Keskmine Tulemus/tagajärg Projekti tähtaegne realiseerimine ei õnnestu. Maandamismeetmete kirjeldus Täitja on projekti ressursivajaduse detailselt läbi töötanud Ülesannete planeerimine vastavalt olemasolevatele ressurssidele Projekti käigus jooksev ressursivajaduse planeerimine ja optimeerimine Pakkujal on võimalik operatiivselt suurendada meeskonnaliikmete arvu nõutava suuruseni. Tegevuskava realiseerumisel Lisaressursi kaasamine Uute spetsialistide värbamine RISK-0 1 4 Lõpptulemusele esitatavaid nõudeid ei ole Täitja poolt mõistetud õigesti ID RISK-0 1 4 Kirjeldus Täitja ei ole projekti sisu ja nõudeid õigesti tõlgendanud Tõenäosus Madal Mõju Keskmine Tulemus/tagajärg Luuakse süsteem, mis ei vasta 100% soovitule. Maandamismeetmete kirjeldus Agiilse arendusmetoodika kasutamine Valdkonda tundvate spetsialistide kasutamine (x-tee jm spetsialistid) Analüütik teeb endale selgeks vajadused ja kaasab vajadusel täpsustamiseks lisaspetsialiste Analüüsis täpsustatakse nõuded ja koostatakse kasutuslood ning nõuete kontrollimise testid, mis aktsepteeritakse Hankija poolt Riskipuhvri planeerimine eelarvesse Tegevuskava realiseerumisel Täpsustatakse nõudeid, täiendatakse aktsepteerimise teste ning kaasatakse vajadusel spetsialiste. RISK-0 1 5 Täitja poolt pakutud arhitektuu rilahendus ei sobi ID RISK-0 1 5 Kirjeldus Täitja ei ole projekti sisu ja nõudeid õigesti tõlgendanud Tõenäosus Madal Mõju Keskmine Tulemus/tagajärg Luuakse süsteem, mille arhitektuur on liiga keeruline või ei täida püstitatud eesmärke Maandamismeetmete kirjeldus Tihe koostöö analüütiku ja infosüsteemi arhitekti vahel Arhitekt vaatab süsteemi arhitektuuri pidevalt üle, et tagada arhitektuuri vastavus nõuetele, kõigi aspektide vastastikune ühilduvus, mastaabitavuse kasutamisvõimalus ja turvalisus. Arhitekt teeb kindlaks muutmise vajaduse ja muutmist/optimeerimist vajavad komponendid Tegevuskava realiseerumisel Täpsustatakse nõudeid ning kaasatakse vajadusel muid spetsialiste. RISK-0 16 Hankija ei ole tulemusega rahul ID RISK-0 16 Kirjeldus Hankija pole realiseeritud lahendusega rahul sest sisu ja kvaliteet ei vasta projekti osaliste ootustele. Tõenäosus Madal Mõju Keskmine Tulemus/tagajärg Arendaja loob süsteemi mis ei vasta 100% soovitule Maandamismeetmete kirjeldus Projekti alguses selgitatakse osapoolte ootused, piirangud ja olulistel teemadel tehakse eelkokkulepped Kasutatakse iteratiivset arendusmetoodikat, pidev demo ja täpsustamine Arenduse käigus antakse palju tagasisidet, kliendile selgitatakse eeldused koostööks Tugev kommunikatsioon Hankija ja Täitja vahel Tegevuskava realiseerumisel Kirjeldatakse puudused, lepitakse kokku parandamise või alternatiivsete lahenduste realiseerimise ajakava vastavalt projekti kokkulepetele. Vajadusel kaasatakse lisaressurssi. RISK-0 17 Täitja meeskonna motivatsiooni langus ID RISK-0 17 Kirjeldus Täitja meeskonna motivatsioon langeb ja seetõttu langeb tööde realiseerimise kiirus ja kvaliteet. Tõenäosus Madal Mõju Keskmine Tulemus/tagajärg Projekti teostuse kvaliteet langeb ja ajakava pikeneb Maandamismeetmete kirjeldus Projekti alguses selgitatakse osapoolte ootused, piirangud ja olulistel teemadel tehakse eelkokkulepped Projekti käigus pidev selgitustöö ja konstruktiivne arutelu, võimalusel kompromisside tegemine Pudelikaelade ennetamine pideva planeerimise kaudu Tegevuskava realiseerumisel Meeskonna kokkukutsumine ja eesmärkide ja ootuste selgitamine, ajurünnak olukorra parandamiseks ja edasise tegevuskava kokkuleppimine. RISK-0 18 Muudatuste juhtimine ei toimi ID RISK-0 18 Kirjeldus Muudatuste juhtimine ei toimi ja seetõttu tekivad erimeelsused projekti skoobi teemadel. Tõenäosus Madal Mõju Keskmine Tulemus/tagajärg Projekti ajakava ja eelarve satuvad ohtu, süsteem ei vasta 100% ootustele. Maandamismeetmete kirjeldus Nõuete ja kasutuslugude piisavalt detailne kirjeldamine Muudatuste pidev haldamine projektijuhi poolt ning selge kommunikeerimine Hankijaga Muudatussoovide planeerimine Tegevuskava realiseerumisel Käiakse koos Hankijaga muudatussoovid üle, prioritiseeritakse ning lepitakse kokku realiseerimise ajakava üldiste projekti kokkulepete alusel. RISK-01 9 Suur osapoolte hulk projekti teostamisel ID RISK-01 9 Kirjeldus Kõik osapooled ei ole piisavalt kaasatud projekti ning projekti eesmärkidest tekib kõrvalekalle. Tõenäosus Keskmine Mõju Kõrge Tulemus/tagajärg Projekti teostus venib ja süsteem pole kõikidele osapooltele vastuvõetav. Maandamismeetmete kirjeldus Arenduse käigus antakse palju tagasisidet, kliendile selgitatakse eeldused koostööks Tugev kommunikatsioon Hankija ja Täitja vahel Tegevuskava realiseerumisel Kaardistada puuduvad vajadused ning leida nende realiseerimiseks ajalised ning rahalised vahendud. RISK-0 20 Funktsionaalsuse prioritiseerimine/ärianalüüsi mitteaktuaalsus ID RISK-0 20 Kirjeldus Projekti käigus muutuvad soovitud funktsionaalsuse prioriteedid. Teostatud ärianalüüs on kaotanud oma aktuaalsuse vahepeal tekkinud uute ideede tõttu. Tõenäosus Madal Mõju Kõrge Tulemus/tagajärg Ajakava pikeneb ja eelarve võib muutuda. Maandamismeetmete kirjeldus Oleme juba maandanud selle riski, kasutades iteratiivset arendusmeetodit. Enne iga uut iteratsiooni vaadatakse üle järgmised kasutuslood, mis tulevad realiseerimisele ning neid saab lisada iteratsiooni või eemaldada sealt Projekti ärianalüütik aitab pakkuda parimat lahendust äriliste eesmärkide täitmiseks. Tegevuskava realiseerumisel Käiakse koos Hankijaga arendussoovid üle, prioriteeritakse ning lepitakse kokku realiseerimise ajakava üldiste projekti kokkulepete alusel RISK-02 1 Disaini ja funktsionaalsuse kooskõlastamine ja osapoolte erinevate seisukohtade risk ID RISK-0 21 Kirjeldus Disaini ja funktsionaalsuse vaevarikas kooskõlastamine (subjektiivsete arvamuste paljusus) Tõenäosus Keskmine Mõju Kõrge Tulemus/tagajärg Ajakava pikeneb ja eelarve võib muutuda. Maandamismeetmete kirjeldus Hankija määrab omalt poolt minimaalse hulga inimesi, kes kooskõlastavad kasutajaliidese disaini, ekraanivaated ja funktsioonaalsused Hankija tagab vastavatele inimestele piisava ajaressursi võimaluse projekti raames. Tegevuskava realiseerumisel Selgitada välja ebakõlad ning leida kompromissid, vajadusel kutsuda kokku juhtkomitee ja leida probleemile kiire lahendus. RISK-02 2 Eelarvestus ajakavale ja ressurssidele on ebatäpne ID RISK-02 2 Kirjeldus Kuna pakkumise hetkel ei ole veel tehtud detailset analüüsi ning informatsioon on üldine, siis ei suudeta garanteerida 100% täpsusega ajakava ja ressursside vajadust Tõenäosus Madal Mõju Keskmine Tulemus/tagajärg Ületatakse ajakava ja ressursse kulub rohkem Maandamismeetmete kirjeldus Riskide pidev hindamine, projekti monitoorimine ja aruandlus juhtrühmale. Iteratiivne tarkvaraarendus tagab ajakavas püsimise. Ilmingute korral varane reageerimine ja otsuste vastuvõtmine. Eeldab tugevat projektijuhtimist. Riskipuhvrite planeerimine nii ajakavasse kui eelarvesse Tegevuskava realiseerumisel Kutsuda kokku projekti juhtrühm ning teha otsused projekti ajakava ja eelarve kohta. RISK-0 2 3 Hankija mõni oluline inimkompetents vahetub ID RISK-0 2 3 Kirjeldus Hankija mõni oluline inimkompetents vahetub Tõenäosus Madal Mõju Keskmine Tulemus/tagajärg Projekt realiseerimise tähtaeg ja kvaliteet võivad sattuda ohtu. Maandamismeetmete kirjeldus Projekti õnnestumise seisukohast on oluline, et projekti Hankija oleks valmis sellesse aktiivselt panustama. Keskendume projektiliikmete motivatsiooni kõrgelhoidmisele läbi ladusa meeskonnatöö. Koostame kliendi oluliste kompetentside rollikirjeldused käesolevas projektis. Tegevuskava realiseerumisel Projektiplaan tuleb täpsustada ning teha muudatused kas projekti ajakavas või skoobis. Han g e „Kohtute infosüsteemi arendustööd“ (296052) I hankelepingu projektiplaan Kohtumenetluse protsesside analüüsimine kohtulahendite andmete automatiseeritud edastamiseks kohtute infosüsteemi ja rahvastikuregistri vahel Sisukord TOC \o "1-3" \h \z \u 1. Analüüsiprobleemi arusaam PAGEREF _Toc207026545 \h 3 2. Pakutava analüüsimeetodika kirjeldus (sh piirangud ja maandamismeetmed) ja selle põhjendatus PAGEREF _Toc207026546 \h 4 3. Analüüsitööde tegevuskava PAGEREF _Toc207026547 \h 5 ETAPP 1: Ideatsioon ja vajaduste analüüs PAGEREF _Toc207026548 \h 5 ETAPP 2: AS-IS protsesside ja andmeanalüüs PAGEREF _Toc207026549 \h 5 ETAPP 3: TO-BE protsesside modelleerimine PAGEREF _Toc207026550 \h 6 ETAPP 4: Kasutajaliidese prototüüpimine PAGEREF _Toc207026551 \h 6 ETAPP 5: KIS → E-toimik → RR andmeedastus ja liidestuste analüüs PAGEREF _Toc207026552 \h 7 ETAPP 6: Tulemuste kokkuvõte ja üleandmine hankijale PAGEREF _Toc207026553 \h 8 4. Kasutatav arendusmetoodika PAGEREF _Toc207026554 \h 9 5. Riskianalüüs ja juhtimise kava PAGEREF _Toc207026555 \h 10 Analüüsiprobleemi arusaam Analüüsi keskne probleem seisneb vajaduses luua tehniline ja sisuline alus selleks, et KISis (Kohtute Infosüsteemis) registreeritud kohtulahendite andmeid oleks võimalik struktureeritud kujul edastada Rahvastikuregistrile (RR). Tänane olukord on killustunud: KISis on saadaval lahendite põhiandmed, kuid RR-i sisestatavad (va. lahendi põhiandmed) andmed on täna olemas vaid lahendi failis teksti kujul. Andmevahetus toimub käsitsi ning RR-l puudub sageli ligipääs õigeaegsele ja korrektselt struktureeritud infole. Hetkel on kohtulahendite edastamise protsess Rahvastikuregistrile (RR) suurel määral manuaalne ja hõlmab kohalike omavalitsuste (KOV) ametnike sekkumist. Kohtud edastavad lahendite failid KOVi ametnikele e-posti teel. Seejärel kontrollivad KOVi ametnikud kohtulahendite sisu ning sisestavad andmed käsitsi RR-i. Selline töökorraldus on ajamahukas, koormav ja vigadele avatud. Probleemi lahendamine eeldab automatiseeritud ja standardiseeritud andmevahetust, kus kogu protsess — alates kohtulahendi koostamisest kuni andmete jõudmiseni RR-i — toimuks elektrooniliselt ja ilma manuaalse sekkumise vajaduseta. Automatiseerimine tagab, et eriti tundliku sisuga lahendid (nt eestkoste, hooldusõigus, nime muutmine, a bielulahutamine ja kooselulepingute lõpetamine jne) jõuavad RR-i viivitamatult ja veatult. See on oluline, sest vastavad andmed mõjutavad teiste riiklike teenuste (nt SKA, MTA, PPA) toimimist. Eesmärk on kaotada vajadus failide käsitsi edastamiseks ning vähendada KOVi ametnike töökoormust — nad ei pea enam kontrollima ega sisestama andmeid käsitsi. Selle tulemusel jõuavad andmed RR-i seaduses ettenähtud ajal: kas kohtulahendi tegemise kuupäeval või jõustumise kuupäeval. Analüüsiprotsessi raames tuleb selgelt mõista ja kirjeldada: millised kohtulahendid on analüüsi fookuses; milliseid andmeid saab struktureerida; kuidas neid andmeid edastatakse KISist E-toimiku kaudu RR-i; millised on andmeväljade, klassifikaatorite ja töövoogude vahelised vastavused ja lüngad; millised on erijuhud, mis vajavad eraldi käsitlust (nt edasikaebus, tühistamine, kehtetuks tunnistamine). Kogu analüüs peab looma arendustööks piisavalt täpse sisendi, mille põhjal saab edasi liikuda prototüüpide, liidestuste ja ärireeglite rakendamisega. Lisaks peab analüüs andma selge hinnangu, kas olemasolevad teenused (nt X-tee, REST API) võimaldavad seda edastust, või tuleb arvestada nende täiendamise või uute teenuste arendamise vajadusega. Kuna tegemist on eluliselt tundliku ja õiguslikult olulise andmevahetusega, on eriti oluline, et analüüsis oleks tagatud nii sisuline kui tehniline täpsus, arvestades andmete tähendust lõppkasutajale ja teistele registritele/teenustele. Pakutava analüüsimeetodika kirjeldus (sh piirangud ja maandamismeetmed) ja selle põhjendatus Analüüsi teostamiseks rakendatakse kombineeritud lähenemist, mis ühendab traditsioonilise süsteemianalüüsi, kasutajakeskse disainimõtlemise (design thinking) ning iteratiivse töökorralduse põhimõtted. Ideatsioon ja vajaduste kaardistus: Kasutajaintervjuud ja töötoad erinevate sihtrühmadega Probleemkohtade ja vajaduste struktureeritud kogumine Eelvisiooni loomine: võimalike töövoogude ja lahendusmustrite visandamine AS-IS analüüs: Olemasolevate süsteemide , teenuste ja töövoogude kaardistamine Kohtulahendite struktuuri ja andmeväljade sisuanalüüs KISis Protsesside ja andmeedastuskanalite (sh X-tee, failiedastus, API-d) toimimise mõistmine TO-BE mudeldamine ja lahenduste valideerimine: Parendusettepanekud töövoogude automatiseerimiseks Protsesside ja andmestruktuuride modelleerimine (BPMN, kasutusjuhtumid ) I interaktiivse prototüübi loomine (Figmas) Tehnilise teostatavuse analüüs: RR ja E-toimiku teenuste võimekuse hindamine Puudujääkide ja lünkade tuvastamine teenuste liidestuses Liidestuse kirjeldaminne Klassifikaatorite ja andmeväljade vastavuse kontroll Koordineeritud tulemuste valideerimine: Iga etapi lõpus toimub vahekokkuvõtte esitlus hankijale Iteratiivne tagasiside kogumine ja kaasamine Analüüsitöid võivad mõjutada mitmed piirangud , millele on planeeritud ka vastavad maandamismeetmed . Osapoolte (nt RR, E-toimik) vähene saadavus või aeglane reageerimine maandatakse varakult planeeritud kohtumiste ja määratud kontaktisikute abil. Süsteemide dokumentatsioonile ligipääsu probleemide korral kaardistatakse varakult vajalikud materjalid ja esitatakse ametlikud taotlused; vajadusel kaasatakse asutuste esindajad suulise sisendi andmiseks. Kohtute vabatekstina esitatud info struktureerimiseks nähakse ette standardsete sisestusvormide kasutuselevõttu ja vajadusel tekstianalüüsi reegleid. Kui andmete liikumiseks (KIS → E-toimik → RR) puuduvad vajalikud teenused, kaardistatakse analüüsi käigus puudujäägid ja tehakse ettepanekud olemasolevate teenuste täiendamiseks või uute arendamiseks koos esmase spetsifikatsiooniga. Valitud lähenemine võimaldab probleemidele läheneda süsteemselt, võttes arvesse nii õiguslikke, protseduurilisi kui ka tehnilisi aspekte. Iteratiivne koostöö hankijaga võimaldab esmased kitsaskohad kiiresti tuvastada ja järk-järgult analüüsi laiendada, süvenedes järjest keerukamatesse detailidesse. Design thinking aitab keskenduda tegelikule kasutusvajadusele, protsessianalüüs toetab mõjusat lahenduste kaardistamist ning tehniline analüüs tagab lahenduste teostatavuse ja kooskõlastatuse kõigi osapooltega. Analüüsitööde tegevuskava Analüüsiprojekti tegevuskava on jaotuatud kuueks etapiks, mis hõlmavad kogu tööprotsessi ideatsioonist kuni tulemuste üleandmiseni. Iga etapi lõpus toimub tulemite ülevaatus hankijaga , tagamaks, et tegevused liiguvad vastavalt ootustele ning kõik vajalikud sisendid järgmisse etappi on olemas. Kõik tegevused ja nende ajakava koos täpse tööjaotusega on toodud lisas Esimese hankelepingu projektiplaan _täpsustatud .xlsx , mis on antud pakkumuse lahutamatu osa . ETAPP 1: Ideatsioon ja vajaduste analüüs Kestus: 4 nädalat Sisu: Projekti visiooni kujundamine ning ärivajaduste kaardistamine koostöös kasutajatega (kohtunikud, menetlusgrupp, kantselei). Toimuvad töötoad ja intervjuud. Kaardistatakse esialgsed probleemid ja soovid. Koostatakse ideede loetelu ja esmane ülevaade lahendusest. Eeldused: Hankija poolt on määratud kontaktisikud Sidurühmade (kohtunikud, menetlusgrupp, kantselei) valmisolek koosolekutel osalemiseks Tulemid: Probleemide ja vajaduste nimekiri Dokumenteeritud ideedekogum Eelvisioon töövoogudest ja lahendusest Pakkuja poolt kaasatud rollid: Projektijuht, analüütik, UX disainer, lahendusarhitekt ETAPP 2: AS-IS protsesside ja andmeanalüüs Kestus: 3 nädalat (+ 1 nädal pakkujapoolset eeltööd, mida viiakse läbi enne etapi algust ) Sisu: Olemasoleva olukorra (AS-IS) analüüs KIS-is: tööprotsessid, andmeväljad, kasutatavad vormid, manuaalsed sammud ja puudused. Protsesside dokumenteerimine (või dokumentatsiooni valideerimine ja täiendamine) BPMN kujul. Võrdlus RR andmevajadustega. Eeldused: Ligipääs KIS süsteemile, selle andmebaasile ja dokumentatsioonile Olemasolevad kohtulahendite failid (struktuur ja sisu) Sidurühmade (kohtunikud, menetlusgrupp, kantselei) valmisolek koosolekutel osalemiseks Tulemid: AS-IS protsesside mudelid (BPMN) Andmeväljade ja sisestusloogika kirjeldus Lünkade kaardistus KIS ja RR vahel Pakkuja poolt kaasatud rollid: Analüütik, UX disainer, lahendusarhitekt , projektijuht ETAPP 3: TO-BE protsesside modelleerimine Kestus: 3 nädalat (+2 nädalat pakkujapoolset eeltööd , mida viiakse läbi enne etapi algust ) Sisu: Tuleviku töövoogude (TO-BE) kirjeldus ja modelleerimine, kasutusjuhtude kirjeldused, sealhulgas erijuhud (edasi-/määruskaebused, kehtetuks tunnistamine). Protsesside optimeerimise ettepanekud, valideerimine kasutajatega. Eeldused: Valmis AS-IS analüüs Kaardistatud KIS ja RR vaheline andmelünkade info Sidurühmade (kohtunikud, menetlusgrupp, kantselei) valmisolek koosolekutel osalemiseks Tulemid: TO-BE protsesside BPMN-diagrammid Kasutusjuh tude ja erandite käsitlemise loogika kirjeldused Pakkuja poolt k aasatud rollid: Analüütik, UX disainer, lahendusarhitekt , projektijuht ETAPP 4: Kasutajaliidese prototüüpimine Kestus: 3 nädalat (+1 nädal pakkujapoolset eeltööd , mida viiakse läbi enne etapi algust ) Sisu: Interaktiivse prototüübi loomine valitud juhtumitele (nt eestkoste, põlvnemine, hooldusõigus , abielulahutamine ja kooselulepingute lõpetamine ). Tagasiside kogumine ja prototüübi täiustamine. Eeldused: TO-BE analüüs ja vormide kirjeldused Kasutajagruppide valmisolek tagasisideks Pakkujapoolse UX disaineri osalemine AS-IS ja TO-BE protsesside aruteludes Sidurühmade (kohtunikud, menetlusgrupp, kantselei) valmisolek koosolekutel osalemiseks Tulemid: Figmas loodud prototüüp Dokumenteeritud tagasiside ja soovitused täiustusteks Pakkuja poolt k aasatud rollid: Analüütik, UX disainer, lahendusarhitekt , projektijuht ETAPP 5: KIS → E-toimik → RR andmeedastus ja liidestuste analüüs Kestus: 3 nädalat NB! Etapp 5 on võimalik alustada paralleelselt Etapp 4-ga, kuna etappide teostamiseks vajalikud rollid ei kattu oluliselt. Etapp 4 keskendub peamiselt UX-disaineri tööle, samas kui Etapp 5 fookuses on lahendusarhitekti ja analüütiku tegevused. Selline jaotus võimaldab ajakava optimeerimist ja tagab töövoogude sujuvuse. Sisu: Andmevahetuse tehnilise ja sisulise teekonna analüüs. E-toimiku ja RR olemasolevate teenuste sobivuse hindamine, vajadusel uute teenuste kirjeldamine. Andmeväljade mapping, klassifikaatorid, turvanõuded, liideste kirjeldused . Eeldused: Ligipääs E-toimiku ja RR dokumentatsioonile ja kontaktisikutele TO-BE andmevoogude visioon Sidurühmade (kohtunikud, menetlusgrupp, kantselei , E-toimiku ja RR esindajad ) valmisolek koosolekutel osalemiseks Tulemid: Liidestusanalüüs (KIS → E-toimik → RR) Teenuste vajaduste kirjeldused Mappingu dokument ja liidestamise spetsifikatsioon Pakkuja poolt k aasatud rollid: Analüütik, lahendusarhitekt , projektijuht ETAPP 6: Tulemuste kokkuvõte ja üleandmine hankijale Kestus: 3 nädalat (sh puhver) Sisu: Kõikide etappide dokumentide täiendamine ja vormistamine. Analüüsi tulemuste süstematiseeritud esitlemine hankijale. Planeeritud puhver võimaldab reageerida tagasisidele ja ootamatutele küsimustele. Eeldused: Kõigi eelmiste etappide töövalmidus Koostöö hankijaga Tulemid: Analüüsi dokumentatsioon on valmis Tulemused on üle antud hankijale Pakkuja poolt k aasatud rollid: Analüütik, lahendusarhitekt, UX disainer, projektijuht Kasutatav arendusmetoodika Lorex-Grupp OÜ kasutab arendustöödeks kombineeritud metoodikat Scrumban + Dual-Track Agile , mis ühendab Scrum’i iteratiivse planeerimise ja Kanban’i pideva voo juhtimise eelised. Lähenemine võimaldab paindlikult hallata kiiresti muutuvat töösisu kui ka säilitada fookuse läbipaistval planeerimisel ja kvaliteedil. Täpsem kirjeldus on esitatud dokumendis Lorex-Grupp arendusmetoodika.docx . Dual-Track Agile rakendamine käesolevas projektis Antud projektis rakendatakse Dual-Track Agile metoodikat eelkõige selleks, et paralleelselt arendustöödega toimuks ka analüüsirajal backlog’i piletite järjepidev täiendamine. See tähendab, et: Discovery track keskendub analüüsidokumentide loomisele ja täiendamisele ning backlog’i ettevalmistamisele: analüüsipiletite (vormid, äriprotsessid, liidestused jmt) sisu ülevaatus, täiendamine ja aksepteerimiskriteeriumide kirjeldamine. Delivery track võtab tööse olulisemad ja piisavalt küpsed piletid järgmiseks sprindiks. Selline tööjaotus toetab kiiremat iteratiivset arengut, minimeerides töö seiskumise või pideva ümbertöötlemise riski. Tegemist on sisuliselt struktureeritud backlog grooming protsessiga. Sprintitsükkel ja tseremooniad Projektis rakendatakse kahe-nädalasi sprinte. Iga sprint algab planeerimisega, millele järgnevad igapäevased stand-up’id, ning lõpeb ülevaatuse ja retrospektiiviga. Paraleelselt toimuvad backlog’i täpsustamised ning vajadusel ka temaatilised töörühmad (nt UX, liidestused). Töö on läbipaistev, korraga töös olevate piletite piirangud aitavad vältida ületöötamist ja fookuse hajumist. Rollid ja töövahendid Tüüpiline tiim sisaldab: Scrum Master / Agile Coach – protsessi jälgimine, takistuste eemaldamine Product Owner (Hankija poolne) – prioriseerimine, sisuline suund Arendajad, testijad, analüütikud, arhitektid – tööde teostamine UX disaineri d – vastavalt vajadusele Tööde halduseks kasutatakse Jira’t (nii analüüsi- kui arenduspiletid), dokumentatsiooni jaoks Confluence’it , Git versioonihaldust ja CI/CD-d testimiseks ja juurutamiseks. Piletite valmidust hinnatakse D efinition- o f- D one põhimõtete alusel. Kvaliteet ja turvalisus Projektis järgitakse põhimõtet “Quality by Design” , st juba analüüsi- ja disainifaasis arvestatakse turva-, privaatsus- ja kvaliteedinõuetega. Testimine on mitmetasandiline ( ühik -, automaat -, manuaal- ja regressioonitestid). Soovi korral kasutatakse automatiseeritud turvakontrollide raamistikku. Riskianalüüs ja juhtimise kava Projekti riskijuhtimise aluseks on protsessikeskne ja riskipõhine lähenemine . Riskide ennetamine ja mõjude vähendamine toimub alates projekti algfaasist ning riskide ümberhindamine on kavandatud iga olulisema etapi järel. Riskijuhtimise protsess hõlmab: riskide varajast tuvastamist ja hindamist töötoa vormis, riskimaatriksi koostamist (tõenäosus vs mõju), riskide maandamise, vältimise või aktsepteerimise strateegiate määramist, vastutusrollide määramist projektiorganisatsioonis, ja riskide perioodilist ümberhindamist projekti jooksul. Olulisemad tuvastatud riskid ja maandamismeetmed (täielik loetelu dokumendis Lorex-Grupp Riskianalüüs.docx ): Ligipääsu de viibimine – lahendatakse varase taotlusega ja vajadusel dump-andmete kasutamisega. Kasutajate sisendi puudulikkus – maandatakse struktureeritud küsimustike, intervjuude ja korduvanalüüsidega. Struktureerimata andmed KIS-is – lahenduseks on varajane andmeanalüüs ja standardiseeritud sisestusvormid. Teenuste puudumine RR-i suunal – maandamine toimub teenuste vajaduse kaardistamisega. Ajagraafikust kõrvalekalded ja kooskõlastusprobleemid – lahendatakse tugeva projektijuhtimise, meeldetuletuste ning rollide täpsustamisega. Arhitektuuri sobimatus või kasutajate ootuste mittetäitumine – iteratiivse prototüüpimise, aktiivse kaasamise ja arhitekti pideva ülevaatusega. Funktsionaalsuse muutuv prioriseerimine – agiilne metoodika võimaldab paindlikku muudatuste haldust ja prioriteetide ümberhindamist. Kõige olulisemad maandamismeetmed on: iteratiivne töökorraldus (võimaldab riskidele kiirelt reageerida), aktiivne suhtlus hankijaga , regulaarne infovahetus ja ootuste selgitamine, tõhus meeskonnatöö ja selged vastutusalad (sh võtmeisikute asendatavus), ning dokumenteeritud muudatuste juhtimine . Projekti edukas kulg sõltub kõikide osapoolte aktiivsest panusest ning riskipõhise juhtimise järjepidevast rakendamisest. Arendusleping nr 2/48-25 Arenduslepingu eritingimused Tallinnas Registrite ja Infosüsteemide Keskus, (registrikoodiga 70000310) asukohaga Lubja 4, 19081 Tallinn, mida esindab põhimääruse alusel direktor Rivo Reitmann, edaspidi Tellija, ja OSAÜHING LOREX-GRUPP (registrikoodiga 10568121) asukohaga Kabli 5-2, 13516 Tallinn, mida esindab põhikirja alusel Kristina Kallaste, edaspidi Täitja, keda nimetatakse edaspidi pool või koos pooled, sõlmisid käesoleva arenduslepingu (edaspidi nimetatud Leping) alljärgnevas: 1. Lepingu sõlmimise alus ja ese 1.1. Kooskõlas riigihankega „Kohtute infosüsteemi arendustööd“ (viitenumber 296052) tulemusel sõlmitud raamlepinguga nr 2/46-25 esitatud pakkumuse täpsustusele teostab täitja Lepingu lisas 3 kirjeldatud tööd ning täidab kõik muud Lepingust tulenevad kohustused (edaspidi ka Töö). 1.2. Pooled kinnitavad, et teevad kõik enesest oleneva, et täita lepingu eesmärgid käesolevas lepingus, seonduvates õigusaktides. 2. Hind ja maksetingimused 2.1. Lepingu hind on 18 468,00 eurot (netosumma), arvestusega, et arendustööde tunnihind on 38,00 eurot (netosumma). 2.2. Tellija tasub lepingu alusel teostatud tööde eest lepingu üldtingimustes sätestatud korras. 3. Lepingu jõustumine ja Töö teostamise tähtaeg 3.1. Leping jõustub allkirjastamise hetkest ja kehtib kuni lepingujärgsete kohustuste nõuetekohase täitmiseni. 3.2. Töö teostamise tähtaeg on 6 kuud arvates Lepingu jõustumise ajahetkest. 4. Lepingu dokumendid 4.1. Lepingu dokumendid koosnevad Lepingu tekstist, Lepingu lisadest, mis on lisatud Lepingu allkirjastamisel ja lisadest, millistes võidakse kokku leppida pärast Lepingu allkirjastamist. Lepingu allkirjastamisel on Lepingu lisad järgmised: 4.1.1. Arenduslepingu üldtingimused Lisa nr 1; 4.1.2. Personal ja kontaktandmed Lisa nr 2; 4.1.3. Tehniline kirjeldus (Tellimus) Lisa nr 3; 4.1.4. Pakkumus (Pakkumuse täpsustus) Lisa nr 4; 4.2. Kui Lepingu dokumendid on oma sisult vastuolulised ja/või nendes antud informatsioon erinevalt tõlgendatav, siis dokumentide pädevusjärjekord (ülimuslik lepingu dokument on nimetatud eespool allolevas loetelus) on järgmine: 4.2.1. Eritingimused; 4.2.2. Arenduslepingu üldtingimused;  4.2.3. Tehniline kirjeldus; 4.2.4. Muud riigihanke alusdokumendid; 4.2.5. Pakkumus. Käesoleva Lepingu allakirjutamisega tõendavad pooled, et on tutvunud ja on nõus Lepinguga ja selle lisadega ning mõistavad täielikult enesele võetavate kohustuste sisu ning nende tagajärgi. Tellija: Täitja: / allkirjastatud digitaalselt / / allkirjastatud digitaalselt / Rivo Reitmann Direktor Registrite ja Infosüsteemide Keskus  Arendusleping nr 2/48-25 Lisa nr 1 ARENDUSLEPINGU ÜLDTINGIMUSED Arenduslepingu üldtingimused asub arenduslepingu asice konteineris eraldi failina.  Arendusleping nr 2/48-25 Lisa nr 2 PERSONAL JA KONTAKTANDMED 1. Tellija esindaja ja kontaktisikud 1.1. Tellija esindajaks tööde vastuvõtmise aktide, teadete jms lepinguga seonduvate dokumentide allkirjastamisel on Registrite ja Infosüsteemide Keskuse Risto Vatsar (tel 5646 0258; e-post: [email protected]). 1.2. Tellija kontaktisikuks tööde teostamise juhendamisel ning Täitjale vajaliku lähteinformatsiooni ja tööülesannete täpsustamisel jmt. on Registrite ja Infosüsteemide Keskuse Reigo Kalamets (tel 5663 4305; e-post: [email protected]). 2. Täitja esindaja ja kontaktisikud 2.1 Täitja esindajaks on Sergei Fedulov (tel. 3725110929, e-post: [email protected]). 2.2 Täitja kontaktisikuks on Kristina Kallaste (tel. 37255542173, e-post: [email protected]). 3. Personali nimekiri 3.1. Tellija personal Nr. Nimi Ametinimetus Kontaktandmed 1 Risto Vatsar KIS tiimijuht [email protected] 2 Reigo Kalamets KIS tootejuht [email protected] 3 Merilyn Anton ET tiimijuht [email protected] 4 Kaisa Kask AET tootejuht [email protected] 5 Rasmus Varblane DT tiimijuht [email protected] 3.2. Täitja personal Nr. Nimi Ametinimetus Kontaktandmed 1 Kristina Kallaste Projektijuht/analüütik [email protected] 2 Sergei Fedulov Arhitekt [email protected] 3 Madis Roosioks Arendaja [email protected] 4 Ruslan Duhhov Testija [email protected] 5 Viktor Jakovlev UX/UI kujundaja [email protected] 6 Jegor Borissov Arendaja [email protected] 7 Valeria Smolina Analüütik [email protected] 8 Dmitri Nikitin Testija [email protected] 4. Kontaktandmed 4.1. Tellija kontaktandmed on: 4.2. Täitja kontaktandmed on: Registrite ja Infosüsteemide Keskus OSAÜHING LOREX-GRUPP Reg. nr. 70000310 Registrikood 10568121 Lubja tn 4 Kabli tn 5-2 19081 TALLINN 13516, Tallinn Telefon: 663 6300 Telefon: 5554 2173  Arendusleping nr 2/48-25 Lisa nr 3 TEHNILINE KIRJELDUS KOOS LISADEGA Tehniline kirjeldus asub arenduslepingu asice konteineris eraldi faili(de)na.  Arendusleping nr 2/48-25 Lisa nr 4 PAKKUMUS Pakkumus asub arenduslepingu asice konteineris eraldi konteinerina.  Arendusleping nr 2/48-25 Lisa nr 1 ARENDUSLEPINGU ÜLDTINGIMUSED Kui eritingimustes on sätestatud teisiti kui üldtingimustes, siis kehtib eritingimustes toodu. 1. Definitsioonid Järgnevad definitsioonid laienevad nii lepingule kui ka selle osaks olevatele dokumentidele. 1.1 Tarkvara Tarkvara tähendab põhiliselt arvutiprogramme, telekommunikatsioone, andmebaasi-, rakendus- ja muud tarkvara objektikoodis, lähtekoodis või nende mistahes muid vorme või adaptsioone koos sellega seonduva dokumentatsiooniga. Spetsiaalselt tellijale tema funktsioonide täitmiseks loodud tarkvara käsitletakse lepingu raames spetsiaaltarkvarana. 1.2 Seadmed Seadmed tähendavad lepingus kirjeldatud tooteid, hõlmates nendega otseselt seotud tarkvara, mis on vajalik seadmete funktsioneerimiseks. 1.3 Telekommunikatsioonid Telekommunikatsioonid tähendavad sisemise ja välise telekommunikatsiooni seadmeid, tarkvara ja teenuseid ning vajalikke vahendeid, teenuseid ja protseduure. 1.4 Asukoht Asukoht tähendab kohta või kohti, välja arvatud täitja asukoht, kuhu seadmeid, telekommunikatsioone või tarkvara tarnitakse või installeeritakse või teenuseid osutatakse (nt tellija test- arendus-ja toodangukeskkond). 1.5 Puudus ja viga Puuduse või veaga on tegemist juhul, kui seade, telekommunikatsioon või tarkvara ei täida lepingus sätestatud funktsioone, annab valesid tulemusi, kui tema nõuetekohane toimimine katkeb või on (muul viisil) häiritud, nii et seadme, telekommunikatsiooni või tarkvara otstarbekohane kasutamine on takistatud või oluliselt häiritud. Vigu liigitatakse järgnevalt: 1.5.1 Kriitiline/Blocker – viga, mille tõttu süsteemi tervikuna või mistahes süsteemi osa ei ole võimalik kasutada ja/või see piirab sama süsteemi mistahes teise osa kasutamist. 1.5.2 Kõrge – viga, mille tõttu pole võimalik mingit süsteemi osa kasutada, kuid see ei sega mõne teist sama süsteemi osa kasutamast.  1.5.3 Keskmine – viga, mille tõttu süsteemi või selle süsteemi mõnda osa on võimalik kasutada piirangutega ja/või kasutajad peavad tegema mitte ettenähtud tegevusi eesmärgi saavutamiseks (nt. funktsionaalsus lubab vigadega toiminguid lõpetada). 1.5.4 Madal – viga, mille tõttu süsteemis esineb kõrvalekaldeid ettenähtust, kuid üldprotsessi need ei häiri või häirivad vähesel määral. 1.5.5 Väheoluline - viga, mille tõttu otseseid kõrvalekaldeid ei teki kuid vajavad muutmist/parandamist. 1.6 Toodangukeskkond Reaalseks andmevahetuseks mõeldud keskkond, mis ei ole test- või arenduskeskkond. 2. Hind 2.1 Lepingu hind sisaldab kõiki tolli- ja muid makse, kaasa arvatud käibemaks. Lepingu eritingimustes märgitakse lepingu hind käibemaksuta (netosummas). 2.2 Lepingu hind väljendatakse eurodes. 2.3 Lepingu hind on täitja ainuke tasu seoses lepinguga ja täitja ise ega tema töötajad ei võta päevarahasid, kaudset tasu ega muud lepingus toodud kohustustega seotud tasu. Samuti ei ole täitjal ega tema töötajal õigust täiendavale autori- või muule sarnasele tasule seoses lepingu täitmisel kasutatud patenteeritud või muul viisil kaitstud eseme või protsessiga. 3. Maksmine 3.1 Täitja esitab tellijale arve masinloetaval kujul e-arvena. Arve esitamise õigus tekib täitjal pärast töö või etapi vastuvõtmist tellija poolt. 3.2 Arve peab sisaldama vähemalt alljärgnevaid andmeid: 3.2.1 info arve esitaja kohta; 3.2.2 info maksja kohta; 3.2.3 viide Lepingule; 3.2.4 käibemaksukohustuslase number; 3.2.5 vastuvõetud Töö nimetus ja kirjeldus; 3.2.6 käibemaks; 3.2.7 kogusumma; 3.3 Tellija tasub lepingu hinna täitja poolt esitatud arvel märgitud kuupäevaks. Maksetähtaeg ei tohi olla lühem kui 30 kalendripäeva, va juhul kui tellija on nimetatut tehnilises kirjelduses (tellimuses) ette näinud. 3.4 Ettemakseid tellija ei teosta. 3.5 Lõpparve maksmine eeldab täitja kõigi lepingu järgsete kohustuste täitmist ning tellija poolt vastuvõtmist. 3.6 Tellijal on õigus lepingu rikkumise korral arvestatud leppetrahvid ja kahju hüvitised maha arvata lepingu alusel täitjale tasumisele kuuluvatest summadest. 3.7 Tellija poolt makstud mistahes summa, mis ületab täitjale lepingus ettenähtu, maksab täitja tellijale tagasi 30 kalendripäeva jooksul pärast vastava teate saamist. 3.8 Lepingujärgse hinna tasumisega viivitamisel on täitjal õigus nõuda viivist iga maksmisega viivitatud kalendripäeva eest 0,15 (null koma viisteist) % maksmata summast päevas. 4. Informatsioon ja aruanded 4.1 Täitja loetakse asukohaga ja lepingu tingimustega tutvunuks. Eelkõige ei rahuldata täitja nõuet lisamakseteks või ajapikenduseks, kui ta oleks saanud vajaliku informatsiooni hankida visiidiga asukohta, konsulteerides tellijaga või muul sobilikul viisil. 4.2 Tellija varustab täitjat tema käsutuses oleva mistahes informatsiooni ja dokumentatsiooniga, mis võib olla lepingu täitmisel oluline, niipea kui võimalik, kuid mitte hiljem kui 2 tööpäeva jooksul vastava nõude saamisest. 4.3 Tellija abistab täitjat niipalju kui võimalik lepingusse puutuva informatsiooni saamisel, mida täitja mõistlikkuse piirides lepingu täitmiseks nõuab. 4.4 Täitja annab tellijale niipea kui võimalik, kuid mitte hiljem kui 2 tööpäeva jooksul vastava nõude saamisest, lepingu täitmist (sealhulgas seadmeid, telekommunikatsioone, tarkvara, projekti kulgemist ja teenuseid) puudutavat informatsiooni. 5. Teated ja kirjavahetus 5.1 Pooltevaheline suhtlus toimub selleks otstarbeks määratud poolte kontaktandmetel ja aadressidel. Pooled on kohustatud kontaktandmete ja aadresside muutusest teineteist teavitama viivitamatult, aga mitte hiljem kui 2 tööpäeva jooksul. 5.2 Kui teisele poolele edastatav teade eeldab vastust, tuleb vastata viivitamatult, kuid mitte hiljem kui 2 tööpäeva jooksul. 5.3 Pooltevahelised lepinguga seotud teated peavad olema kirjalikku taasesitamist võimaldavas vormis, välja arvatud juhtudel, kui teated on informatsioonilise iseloomuga, mille edastamisel teisele poolele ei ole õiguslikke tagajärgi. Teade loetakse kättesaaduks, kui: 5.3.1 teade on üle antud allkirja vastu; 5.3.2 teade on edastatud tähitud kirjana poole postiaadressil ja teate postitamisest on möödunud 5 (viis) kalendripäeva; 5.3.3 e-posti või telefoni teel on teade edastatud lepingus märgitud kontaktisikule või esindajale. 6. Asukoht 6.1 Täitja peab andma lepingutäitmise käigus piisavalt informatsiooni korrektselt kirjalikku taasesitamist võimaldavas vormis koostatud kasutusjuhendi näol, et võimaldada tellijal asukoht lepingujärgsete kohustuste täitmiseks kohaselt ette valmistada. Juhend peab olema antud sellise sisendiga, et objektiivselt keskmise võimekusega programmeerija oleks suuteline  asukoha töö vastuvõtmiseks vajalike testide teostamiseks ette valmistada. Juhend peab olema esitatud piisava ajavaruga selleks, et tellijal oleks võimalik töö üleandmisel alustada koheselt vastuvõtmiseks vajalike testide teostamist. Juhul, kui töö üleandmise hetkeks ei ole juhendit edastatud või kui edastamisest hoolimata ei ole tellija asukohta ette valmistada jõudnud, algab töö vastuvõtmiseks ette nähtud tähtaeg kulgema pärast asukoha ette valmistamist. Kui täitja ei ole ette näinud erilisi keskkonnatingimusi, võib tellija eeldada, et neid ei nõuta. 6.2 Tellija teeb vastavad ettevalmistused ja loob tingimused omal kulul. 6.3 Kui tellija ettevalmistused või loodud tingimused ei vasta lepingus sätestatule, esitab täitja viivitamatult puuduste loetelu. Kui tellija ei muuda olukorda selliselt, et täitjal oleks võimalik ajagraafikust kinni pidada, on täitjal õigus saada lepingujärgsete kohustuste täitmiseks vajalikku ajapikendust. 6.4 Täitjal on õigus taotleda juurdepääsu asukohale tellija tavalisel tööajal. 6.5 Täitja kulud, mis on seotud lepingus sätestatud juurdepääsupiirangutega ja turvaprotseduuridega, sisalduvad lepingu hinnas ning neid ei hüvitata. 6.6 Tellija võib igal ajal lepingu kehtivuse vältel muuta või kehtestada juurdepääsupiiranguid ja turvaprotseduure. Kui täitja tõendab, et selline muudatuste tegemine või piirangute või protseduuride kehtestamine põhjustas lisakulusid, on tal õigus nende hüvitamisele. 7. Lepingu muutmine 7.1 Lepingut võib muuta poolte kirjalikul kokkuleppel. Muudatused jõustuvad pärast nende allkirjastamist mõlema poole poolt või poolte poolt määratud tähtajal. Kirjaliku vormi mittejärgimisel on muudatused tühised. 7.2 Riigihangete seaduse § 123 lg 1 p 1 kirjeldatud muudatused lepitakse kokku tellija ja täitja esindajate poolt kirjalikku taasesitamist võimaldavas vormis. 8. Poolte õiguskaitsevahendid 8.1 Lepingu see peatükk fikseerib Lepingu olulised rikkumised, menetluse rikkumisest teatamisel ning poolte vastutuse. See peatükk ei välista ega piira poole õigust kasutada muude lepingu rikkumiste korral muid õigusaktidest tulenevaid õiguskaitsevahendeid, samuti kasutada täiendavaid õiguskaitsevahendeid lisaks selles peatükis kokkulepitule. 8.2 Lepingust või seadusest tuleneva õiguse või õiguskaitsevahendi mittekasutamine või selle kasutamisega viivitamine ei tähenda nimetatud õigusest või õiguskaitsevahendist või muudest õigustest või õiguskaitsevahenditest loobumist. Lepinguga seotud mis tahes loobumised on kehtivad ainult siis, kui need on selgesõnaliselt ja kirjalikult väljendatud. 8.3 Pooled vastutavad lepinguga võetud kohustuste täitmata jätmise või mittekohase täitmise eest Eesti Vabariigi õigusaktides ning lepingus ettenähtud korras. 8.4 Oluliseks lepingurikkumiseks loetakse muu hulgas järgmisi rikkumisi: 8.4.1 pool ei täida mis tahes lepingust tulenevat kohustust teise poole poolt lepingust tuleneva vastava kohustuse täitmiseks antud täiendava tähtaja jooksul;  8.4.2 täitja ei täida garantiiperioodil lepingust tulenevaid kohustusi; 8.4.3 täitja ei ole esitanud tellijale asukoha keskkonnatingimusi, millest tulenevalt on häiritud tellija seadmete, telekommunikatsioonide või tarkvara kohane funktsioneerimine ning mistõttu tellija kaotab täitja lepingu järgsete kohustuste täitmise vastu huvi; 8.4.4 täitja rikkus kohustust tahtlikult või raske hooletuse tõttu; 8.4.5 täitja rikub personaliga seonduvaid tingimusi; 8.4.6 poolel või tema poolt kaasatud kolmandal isikul puuduvad lepingu täitmiseks vajalikud õigused (sealhulgas load, litsentsid, Intellektuaalse omandi õigused); 8.4.7 täitja suhtes on algatatud pankrotimenetlus, pankrot on välja kuulutatud, täitja varad arestitakse või täitja finantsseisund halveneb tellija põhjendatud hinnangul oluliselt ja see halvenemine muudab vähetõenäoliseks lepingu nõuetekohase täitmise; 8.4.8 pool on rikkunud Intellektuaalse omandi õigusi ja nende kasutamise tingimusi; 8.4.9 pool on rikkunud konfidentsiaalsuskohustust ja/või isikuandmete töötlemisega seonduvaid kohustusi; 8.4.10 pool on rikkunud avalikustamise keelu kohustust; 8.4.11 pool on rikkunud kolmandate isikutega seonduvaid kohustusi; 8.4.12 tellija on viivituses lepingus kokku lepitud maksetähtajaga rohkem kui kolmkümmend (30) kalendripäeva; 8.5 Poolel on õigus nõuda lepingu olulise rikkumise korral leppetrahvi tasumist kuni 30% Lepingu hinnast iga vastava juhtumi korral. Juhul, kui leppetrahvi nõue on seotud töö etapi puuduliku teostamisega ja puudus ei sea ohtu lepingujärgse töö tervikuna nõuetekohast üleandmist ei tohi leppetrahvi nõue ületada 30% teostatud või töös oleva etapi maksumusest. 8.6 Poolte rahaline koguvastutus on piiratud lepingu maksumusega, välja arvatud juhul, kui pool rikkus kohustust tahtlikult või raske hooletuse tõttu. 8.7 Pool peab teavitama teist poolt leppetrahvi nõudest mõistliku aja jooksul arvates ajast, mil ta sai teada leppetrahvi nõudmise õiguse tekkimisest. Leppetrahvi nõude esitamisel on pool kohustatud märkima mõistliku tähtaja leppetrahvi tasumiseks, tähtaeg ei tohi olla lühem kui 30 kalendripäeva. Pool on kohustatud leppetrahvi tasuma nõudes märgitud tähtaja jooksul. Kui poole hinnangul on leppetrahvi nõue alusetu, on pool kohustatud esitama oma vastuväited enne leppetrahvi tasumise tähtaega. Leppetrahvi nõudmine ei mõjuta poole õigust nõuda poolelt nõuetekohase töö või selle osa teostamist ning kahju hüvitamist või kasutada muid seadusest tulenevaid õiguskaitsevahendeid. 8.8 Lisaks leppetrahvi nõudele ja / või leppetrahvi asemel on tellijal õigus nõuda täitjalt lepingu mittenõuetekohasel täitmisel, et: 8.8.1 täitja kõrvaldaks puudused, sealhulgas nõuda, et täitja hangiks parema teenuse osutamiseks vajalikud lisa- või asendusseadmed, -telekommunikatsioonid, -tarkvara ja teenused; 8.8.2 oluliste puuduste, samuti puuduste kõrvaldamise ebaõnnestumise korral nõuda, et täitja teeks uue töö ja tarniks uued seadmed, telekommunikatsioonid ja tarkvara või keelduda  vastuvõtmisest ning leping lõpetada; 8.8.3 võtta täitja pakutud töö vastu ning alandada vastavalt hinda; 8.9 Lepingust tulenevate leppetrahvide maksmine, samuti tekitatud kahju hüvitamine, ei vabasta lepingut rikkunud poolt Lepingujärgsete kohustuste täitmisest. 9. Standardid, liidesed ja ühilduvus 9.1 Täitja lepingujärgsete kohustuste täitmine ei tohi tekitada häireid tellija mistahes teiste liidestatud süsteemide talitluses. 9.2 Täitja garanteerib, et kõik seadmed, telekommunikatsioonid, tarkvara ja teenused on vastastikku ühilduvad, funktsioneerivad ja töötavad standardite ja/või liideste vahendusel rahuldavalt koos mistahes teiste lepingus sätestatud seadmete, telekommunikatsioonide, tarkvara ja teenustega ning lepingus sätestatud keskkonnas. 9.3 Täitja ei muuda ilma tellija eelneva kirjaliku nõusolekuta mistahes standardeid, liideseid, sideprotokolle jms. 10. Dokumentatsioon 10.1 Lepingu täitmisel kaasneva dokumentatsiooni loomisel toetutakse dokumentatsiooniplaanile. 10.2 Täitja varustab tellijat piisava ja adekvaatse dokumentatsiooniga, kaasa arvatud informatsioon seadmete, telekommunikatsioonide ja tarkvara projekteerimise ja funktsioneerimise kohta, mis on vajalik, et tellija saaks seadmeid, telekommunikatsioone, tarkvara ja teenuseid efektiivselt kasutada, hooldada, kohandada ja neile lisaseadmeid lisada. 10.3 Kõik juhendid ja muud dokumendid esitatakse eesti keeles, kui ei ole kokku lepitud teisiti. 10.4 Dokumentatsioon peab vastama tootele, sisaldama muudatusi ja olema terminoloogiliselt üheselt mõistetav. 10.5 Dokumentide valmistamiseks ja levitamiseks kasutatakse paberkandjat või elektroonilist infokandjat. 11. Üleandmine ja vastuvõtmine 11.1 Töö või töö etapi valmimise järgselt annab täitja selle tellijale üle vastuvõtmiseks. 11.2 Täitja peab tellijat töö või töö etapi üle andmise viivitusest või viivitusse sattumise ohust ja põhjustest koheselt kirjalikku taasesitamist võimaldavas vormis informeerima. Kui täitja viivituse põhjustab tellija, on täitjal õigus nõuda mõistlikku ajapikendust ja põhjendatud lisakulude hüvitamist. 11.3 Töö või töö etapi üleandmise kohta koostab täitja üleandmise akti, milles näidatakse muuhulgas ära üleandmise kuupäev, teostatud töö, osutatud teenuste, hoolduse ja tarnitud seadmete, telekommunikatsioonide ja tarkvara detailiseeritud nimekiri ning vajaduse korral neis esinevad puudused. Iga töö etapi üleandmisel koostab ja esitab täitja antud etapi kohta koostatud dokumentatsiooni, vastavalt dokumentatsiooniplaanile või tellija poolt tehnilises kirjelduses  esitatud nõudmistele. 11.4Töö või töö etapi üleandmine tellijale ei ole käsitatav selle vastuvõtmisena tellija poolt. 11.5Täitjal on õigus nõuda ja tellijal kohustus töö vatsu võtta kui töös on täitja poolt kõrvaldatud kõik järgmise prioriteediga vead: kriitiline/blocker, kõrge ja keskmine. Taolisel juhul lasub täitjal kohustus vaegtöödena madala ja väheolulise tähtsusega vead parandada töö vastuvõtmise aktis toodud ajaperioodiks. 11.6Pärast töö etapi üleandmist on tellijal õigus töö üle vaadata 10 tööpäeva jooksul. Pärast töö üleandmist on tellijal õigus töö üle vaadata 20 tööpäeva jooksul. Tellija võib tehnilises kirjelduses (tellimuses) ette näha töö üle vaatamisele käesolevast erinevad tähtajad. 11.7Juhul, kui tellija leiab, et töö ei vasta lepingu tingimustele, on tellija kohustatud teavitama täitjat töös avastatud puudustest, keeldumisest tööd enne puuduste kõrvaldamist vastu võtta ja kirjeldama töö puudused. Täitja on kohustatud puudused kõrvaldama 5 tööpäeva jooksul, kui pooled ei ole kokku leppinud mõnda muud tähtaega. Kui tellija näeb töö üle vaatamisel ette käesolevatest üldtingimustest erineva tähtaja, täpsustab tellija tehnilises kirjelduses (tellimuses) puuduste kõrvaldamiseks antava tähtaja. Töö puuduste kõrvaldamise kulud kannab Täitja. 11.8Enne töö üleandmist viib täitja töö nõuetelevastavuse kindlakstegemiseks läbi testid. 11.9Täitja esitab tellijale kõik tema poolt läbiviidud testide tulemusena valminud dokumentide koopiad. 11.10 Enne töö vastuvõtmist viib tellija töö nõuetelevastavuse kindlakstegemiseks läbi testid. 11.11 Kui töö või mistahes töö osa ei läbi teste, viiakse otsekohe pärast seda, kui täitja on teinud vajalikud korrektuurid testide edukaks läbiviimiseks, läbi kordustestid samadel tingimustel. 11.12 Tellija nõudmisel viib kordustestid läbi täitja. 11.13 Parandatud töö üleandmine toimub nagu esmakordsel üleandmiselgi. 11.14 Puudustega üle antud tööd ei loeta tähtaegselt üleantuks ning tellijal on õigus nõuda sellise lepingurikkumise korral täitjalt leppetrahvi lepingus sätestatud korras ja määrades või rakendada muid õiguskaitsevahendeid. 11.15 Vastuvõtmiseks valmis töö peab vastama lepingus sätestatud tingimustele. Töö etapi vastuvõtmine tellija poolt ei tingi ega kohusta töö kui terviku vastuvõtmist tellija poolt juhul, kui töö ei vasta tingimustele. Töö vastuvõtmise kohta koostab tellija vastuvõtuakti, milles näidatakse muuhulgas ära vastuvõtmise kuupäev, teostatud töö, osutatud teenuste, hoolduse ja tarnitud seadmete, telekommunikatsioonide ja tarkvara detailiseeritud nimekiri. 11.16 Töö või töö etapp loetakse vastuvõetuks vastuvõtuakti allkirjastamisest või toodangukeskkonnas kasutusele võtmisest. Juhul, kui tellija on võtnud puuduseid sisaldava töö või töö etapi toodangukeskkonnas kasutusele, loetakse vastuvõetuks ainult nõuetekohaselt teostatud tööd ja täitjal on õigus nimetatute osas esitada arve. Taolises olukorras esitab tellija täitjale töös või töö etapis esinevate puuduste nimekirja ning puuduste kõrvaldamise tähtaja, kas enne töö või töö etapi toodangukeskkonnas kasutusele võtmist või vahetult pärast selle toimumist. 11.17 Mistahes seadmete, telekommunikatsioonide, tarkvara ja teenuste osa valmimisel võib tellija anda välja vastuvõtuakti vastava osa kohta. Selline vastuvõtmine ei mõjuta täitja kohustust  täita kõiki Lepingus ettenähtud kohustusi. 11.18 Täitja vastutab töö juhusliku hävimise või kahjustumise eest kuni töö vastuvõtmiseni tellija poolt. 12. Koolitus 12.1Täitja tagab tellija personalile adekvaatse väljaõppe, kindlustamaks seadmete, telekommunikatsioonide, tarkvara ja teenuste rahuldava ja efektiivse toimimise, vastavalt lepingus kokkulepitule. 12.2Koolituse toimumise aeg, koht ja maht kooskõlastatakse eelnevalt tellija kontaktisikuga. 13. Garantii 13.1Täitja annab tööle 6 kuulise töövõtugarantii. Garantiiperiood algab tööde kogumina vastuvõtmisest. 13.2Garantiiperioodil ilmnevad puudused kõrvaldab täitja omal kulul, v.a punktis 13.6 toodud juhtumitel. Kui ilmnenud puudused ei ole garantii korras kõrvaldatavad, esitab täitja tellijale põhjendused kirjalikku taasesitamist võimaldavas vormis, kuid mitte hiljem kui järgmisel tööpäeval pärast sellest asjaolust teada saamist. 13.3Kui ei ole kokku lepitud teisiti, toimub garantiiliste puuduste üleandmine ja vastuvõtmine lepingu punktis 11 toodud regulatsiooni kohaselt. 13.4Juhul kui garantiiperioodil ilmnenud puudused muudavad osa või kõik seadmed, telekommunikatsioonid ja/või tarkvara kasutamiskõlbmatuks, varustab täitja tellijat nõutud tasemel toimimise garanteerivate lisa- või asendusosade ja muu vajalikuga omal kulul. 13.5Tellija informeerib täitjat puuduse iseloomust ja ulatusest otsekohe selle ilmnemisel. Täitja on kohustatud eemaldama ilmnenud puudused vastavalt lepingus toodule või tellija poolt määratud ajal. 13.6Garantiiga ei ole hõlmatud: 13.6.1 puudused, mille tekkimise eest vastutab tellija; 13.6.2 diagnostikaks kulunud aeg, juhul kui algselt garantii juhtumine registreeritud juhtumi raames tuvastatakse, et tegu ei ole garantiilise juhtumiga. Vastav töö kuulub eraldi tasustamisele lepingu tunnihinna alusel. 13.7Garantii kaotab kehtivuse kui täitjaga kooskõlastamata on muudetud või muudetakse lähtekoodi, v.a juhul kui tellija suudab eristada lähtekoodis tehtavaid muudatusi. 14. Load ja litsentsid 14.1Täitja vastutab ainuisikuliselt lepingu täitmiseks vajalike lubade ja litsentside saamise eest. Tellija teeb täitjaga mõistliku koostööd, hoidmaks ära selliste lubade või litsentside väljaandmise asjatut viivitamist või väljaandmisest keeldumist. 14.2Tellija võib ilma ette teatamata lepingu lõpetada, kui täitja ei saa lepingu täitmiseks vajalikku luba  või litsentsi. 14.3Täitja garanteerib, et tal on õigus anda tellijale lepingu objektiks oleva tarkvara ja teiste autori- või muude sarnaste õigustega kaitstavate esemete kasutamisõigus. 14.4Täitja garanteerib, et nimetatud kasutusõiguse üleandmisega ei rikuta kolmandate isikute õigusi. Juhul kui kolmas isik esitab oma õiguste rikkumise tõttu tellija vastu hagi ning see rahuldatakse, tasub täitja võimalikud kahjuhüvitusnõuded, samuti õigusabikulud ja muud seonduvad kulud. 15. Riski üleminek 15.1Juhusliku hävimise või kahjustumise risk läheb tellijale üle töö vastuvõtmisel, samuti hetkel, mil tellija satub viivitusse toimingu tegemisega, millega ta töö üleandmisele peab kaasa aitama. 16. Intellektuaalne vara 16.1Lepingu allkirjastamisega kinnitab täitja tellijale, et talle kuuluvad lepingu täitmiseks vajalikud varalised autoriõigused, litsentsid ja muud intellektuaalse omandi õigused, mis on tarvilikud lepingu järgse töö täielikuks teostamiseks ja loovutamiseks ning, et nende suhtes ei ole kolmandatel isikutel nõudeid. 16.2Täitja kinnitab, et ta on võtnud tarvitusele kõik meetmed autori isiklike õiguste realiseerimiseks viisil, mis ei takista ega raskenda teose kasutamist ja autori varaliste õiguste teostamist tellija poolt. 16.3Täitja annab spetsiaaltarkvarale Euroopa Liidu tarkvara vaba kasutuse litsentsi v.1.1 (EUPL). Juhul, kui töö üleandmine toimub etapiviisiliselt, siis loetakse litsents antuks iga etapi (teose) vastuvõtmisel tellija poolt. 16.4Tellijal on muuhulgas õigus spetsiaaltarkvara (teose) autoriõiguste kehtivusaja jooksul: 16.4.1 teost kasutada mis tahes eesmärgil ja mis tahes viisil; 16.4.2 teost reprodutseerida; 16.4.3 originaalteost muuta ja luua teosel põhinevaid tuletatud teoseid; 16.4.4 teost või selle koopiaid üldsusele edastada, sealhulgas neid kättesaadavaks teha või eksponeerida, samuti avalikult esitada; 16.4.5 teost või selle koopiaid levitada; 16.4.6 teost või selle koopiaid laenutada ja rentida; 16.4.7 anda all-litsentse teose või selle koopiate suhtes kehtivate õiguste kohta. 16.5Täitja annab tellijale spetsiaaltarkvara lähtekoodi, täitmiskoodi ja dokumentatsiooni kujul, mis võimaldab tellijal sellest aru saada. 16.6Tellija võib levitada lähtekoodi ja täitmiskoodi ning dokumentatsiooni ja selle muudatusi mistahes kolmandatele isikutele ja asutustele. 16.7Kõik täitja poolt lepingu täitmise käigus koostatud dokumendid ja andmed kuuluvad tellijale. Täitja annab kõik nimetatud dokumendid ja andmed tellijale üle. 16.8Tellija võib spetsiaaltarkvara autoriõigusi teostada mistahes olemasolevas või hiljem loodud keskkonnas, toel või formaadis. 16.9Täitja tagab, et tema töötajad on loobunud Eesti seadusega lubatud ulatuses oma õigusest teostada isiklikke õigusi, et tellijale oleks võimalik vajalikke varalisi õigusi litsentsida. 16.10 Lepingujärgse tarkvarasüsteemi loomiseks kolmandatele isikutele kuuluvate komponentide (tarkvara) kasutamise osas juhinduvad pooled nende kasutamise litsentsitingimustest. Täitja kinnitab, et eelistab tarkvara loomisel selliseid kolmandatele isikutele kuuluvaid komponente, mille kasutamisega ei kaasne täiendavaid litsentsitasusid ega piiranguid tarkvara kasutamisel või alllitsentside andmisel. Täitja on kohustatud tellijat teavitama juhul, kui täitja plaanib tarkvara loomisel kasutada selliseid kolmandatele isikutele kuuluvaid komponente, mille kasutamine toob tellijale kaasa täiendavaid litsentsitasusid või piiranguid tarkvara kasutamisel. Ilma tellija kirjaliku nõusolekuta ei tohi täitja tarkvara loomisel nimetatud komponente kasutada. 16.11 Nimetatud õigused kehtivad kogu autoriõiguste kehtivuse aja ja nende kehtivuse territooriumiks on kogu maailm. 17 Personal 17.1 Lepingus kirjeldatud teenuseid osutavad lepingus nimetatud isikud vastavalt lepingus sätestatud ülesannetele. Muudatusi tohib teha vaid tellija kirjalikku taasesitamist võimaldavas vormis antud nõusolekul. 17.2 Täitja asendab töid teostava isiku viivitamatult lepingu objekti täitmise seisukohast võrdväärse kvalifikatsiooni ja kogemustega ning tellijale vastuvõetava isikuga, kui: 17.2.1 töid teostav isik ei ole võimeline teenuste osutamist jätkama haiguse, õnnetusjuhtumi või muu temast tuleneva põhjuse tõttu; 17.2.2 lepingus nimetatud töid teostav isik osutub tellija põhjendatud arvamuse kohaselt lepingujärgsete ülesannete täitmiseks ebakompetentseks või ebasobivaks või kui tema lepingujärgsete ülesannete täitmine pidevalt kahjustab lepingu korrektset ja õigeaegset täitmist. 17.2.3 isikul on kuriteo toimepanemise eest määratud kehtiv karistus. 17.3 Täitja kannab kõik punktis 17.2 nimetatud asendusest tulenevad või sellega kaasnevad kulud. 17.4 Töid teostavatel isikutel ei tohi olla kuriteo toimepanemise eest määratud kehtivat karistust. 17.5 Töid teostavad isikud ei tohi olla tellija töötajad ega tellija töötajaga seotud juriidilised isikud. Seotud juriidiline isik tähendab käesoleva lepingu mõistes juriidilist isikut, mille juhtumis- või kontrollorgani liige tellija töötaja on või juriidiline isik, milles vähemalt 1/10 osalusest kuulub tellija töötajale. 18 Kolmandad isikud 18.1 Pooled võivad loovutada lepingust tulenevaid rahalisi nõudeid kolmandatele isikutele. Pooled  on kohustatud teineteist nõude loovutamisest viivitamatult kirjalikult informeerima. 18.2 Pooled ei või oma lepingujärgseid kohustusi anda üle kolmandale isikule ega kaasata oma lepingujärgsete kohustuste täitmiseks kolmandat isikut ilma teise poole sellekohase selgesõnalise kirjaliku nõusolekuta.Tellijal on õigus edastada või suunata täitja poolt esitatud arve tasumisele tellijast erinevale hankijale nendevahelise koostöökokkuleppest tuleneval alusel juhul kui vastavasisuline teavitus on tellija poolt pakkumuse esitamise ettepanekus kajastatud. 18.3 Pooled vastutavad kõigi isikute eest, keda nad kasutavad oma lepingujärgsete kohustuste täitmisel. 19 Auditeerimine 19.1 Mõlemal poolel on õigus kaasata auditeerimiseks sõltumatu audiitor. Audiitori kaasamiseks ei ole vajalik teise poole luba. 19.2 Audiitori isik ja muu auditeerimisega seotud asjaolud sätestatakse eraldi kokkuleppes. Auditeerimise käigus avastatud probleemid tuleb registreerida ja vajaduse korral sisestada probleemide lahendamise protsessi. 19.3 Täitja peab täpset arvestust lepingu täitmisel töötatud kalendripäevade ja –kuude kompenseerimisele kuuluvate kulude kohta. Audiitorile võimaldatakse piiramatu ligipääs nimetatud andmetele. 19.4 Audiitorit kaasanud pool tagab, et audiitor käsitleb saadud informatsiooni konfidentsiaalsena. Vastutus jääb audiitorit kaasanud poolele. 19.5 Pärast andmete auditeerimist ja kontrollimist teeb audiitor järeldusotsuse, mis on lõplik. 19.6 Auditi kulud kannab auditi tellinud pool. 20 Õigustest loobumine 20.1 Kummagi poole mistahes viivitus, hoolimatus või keeldumine teist poolt lepingutingimuste täitmise nõudmisel või muude nõuete esitamisel ei kujuta endast selle poole mistahes lepingujärgsetest õigustest loobumist või nende tühistamist. 21 Konfidentsiaalsus ja isikuandmed 21.1 Täitja ei või oma lepingujärgseid kohustusi anda üle kolmandale isikule ega kaasata oma lepingujärgsete kohustuste täitmiseks kolmandat isikut ilma tellija sellekohase selgesõnalise kirjaliku nõusolekuta. 21.2 Täitja on kohustatud: 21.2.1 tagama lepingu täitmise käigus tellijalt ükskõik mis vormis saadud teabe (andmed, tehingudokumentatsioonis ja lepingutes sisalduvad tellija esindajate isikuandmed, know- how) konfidentsiaalsuse ning ei edasta ega võimalda sellele teabele juurdepääsu kolmandale isikule ilma tellija sellekohase selgesõnalise kirjaliku nõusolekuta; 21.2.2 tagama lepingueelsete läbirääkimiste, lepingujärgsete kohustuste ja lepingu täitmise käigus  ükskõik mis vormis teatavaks saanud isikuandmete (v.a. tehingudokumentatsioonis ja lepingutes sisalduvate Tellija esindajate isikuandmete) konfidentsiaalsuse ning ei edasta ega võimalda nendele juurdepääsu ühelegi kolmandale isikule ilma tellija sellekohase selgesõnalise kirjaliku nõusolekuta; 21.2.3 ei edasta punktis 21.2.2 nimetatud isikuandmeid väljapoole Euroopa Liidu liikmesriikide ja Euroopa Majandusühendusse kuuluvate riikide territooriumit ilma tellija sellekohase selgesõnalise kirjaliku nõusolekuta; 21.2.4 kasutama ja töötlema punktis 21.2.2. nimetatud isikuandmeid üksnes lepingu täitmiseks ja tellija dokumenteeritud juhiste alusel, välja arvatud juhul, kui täitja on kohustatud teavet töötlema täitja suhtes kohalduva õiguse alusel. Viimati nimetatud juhul teavitab täitja tellijat vastava kohustuse olemasolust enne teabe töötlemist, kui selline teavitamine ei ole olulise avaliku huvi tõttu täitja suhtes kohalduva õigusega keelatud; 21.2.5 võimaldab juurdepääsu punktis 21.2.2. nimetatud 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öötlemisalaseid 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. Vastav konfidentsiaalsuskohustus jääb kehtima pärast käesoleva lepingu lõppemist; 21.2.6 kohustub 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. 21.2.7 kohustub rakendama järgmisi organisatsioonilisi, füüsilisi ja infotehnilisi turvameetmeid punktis 21.2.2. nimetatud 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 s.h. avalikustamise eest: a) vältima kõrvaliste isikute ligipääsu isikuandmete töötlemiseks kasutatavatele seadmetele; b) ära hoidma andmete omavolilist lugemist, kopeerimist ja muutmist andmetöötlussüsteemis, samuti andmekandjate omavolilist teisaldamist; c) ä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; d) tagama, et igal andmetöötlussüsteemi kasutajal oleks juurdepääs ainult temale töötlemiseks lubatud isikuandmetele ja temale lubatud andmetöötluseks; e) tagama andmete olemasolu isikuandmete edastamise kohta: millal, kellele ja millised isikuandmed edastati, samuti selliste andmete muutusteta säilimise; f) tagama, et isikuandmete edastamisel andmesidevahenditega ja andmekandjate transportimisel ei toimuks isikuandmete omavolilist lugemist, kopeerimist, muutmist või  kustutamist; g) pidama arvestust isikuandmete töötlemisel kasutatavate tema kontrolli all olevate seadmete ja tarkvara üle, dokumenteerides järgmised andmed: i. seadme nimetus, tüüp ja asukoht ning seadme valmistaja nimi; ii. tarkvara nimetus, versioon, valmistaja nimi ja kontaktandmed. 21.2.8 teavitama tellijat toimunud või põhjendatult kahtlustatavast käesoleva lepingu punktis 21.2.1 ja/või 21.2.2 sätestatud konfidentsiaalsuskohustuse rikkumisest; punktis 21.2.7. ja selle alapunktides a-g sätestatud turvameetmete rikkumisest, mis põhjustab, on põhjustanud või võib põhjustada edastatavate, salvestatud või muul viisil töödeldavate isikuandmete juhusliku või ebaseadusliku hävitamise, kaotsimineku, muutmise või loata avalikustamise või neile juurdepääsu, kirjalikult viivitamata aga mitte hiljem kui kakskümmend neli (24) tundi pärast sellest teada saamist. Teates tuleb vähemalt: a) kirjeldada (Isikuandmetega seotud) rikkumise laadi, sealhulgas puudutatud andmesubjektide liike ja arvu ning puudutatud kirjete liike ja arvu; b) teatada andmekaitse töötaja ja tema kontaktandmed või muu kontaktpunkt, kust saab lisateavet; c) soovitada meetmeid (Isikuandmetega seotud) rikkumise võimalike negatiivsete mõjude leevendamiseks; d) kirjeldada (Isikuandmetega seotud) rikkumise tõttu andmesubjektidele tekkivaid tagajärgi ja potentsiaalseid ohte; e) kirjeldada täitja/või kolmandast isikust alltöötleja poolt välja pakutud või võetud meetmeid (Isikuandmetega seotud) rikkumisega tegelemiseks ja f) esitada muud teavet, mis on mõistlikult nõutav, et tellija saaks täita kohaldatavaid andmekaitse õigusakte, sealhulgas riigiasutustega seotud teavitamise ja avaldamise kohustusi, näiteks teavet, mis on nõutav andmesubjekti tuvastamiseks. 21.2.9 tellija eelnevalt kirjalikul heakskiidul lõpetama käesoleva lepingu punktis 21.2.8.nimetatud rikkumise ning kohaldama meetmeid (isikuandmetega seotud) rikkumise lahendamiseks, sealhulgas vajaduse korral rikkumise võimaliku kahjuliku mõju kõrvaldamiseks ja leevendamiseks; 21.2.10 kohustub lepingu lõppemisel kustutama kõik punktis 21.2.2. nimetatud isikuandmed ja nimetatute koopiad 30 päeva jooksul, v.a juhul, kui õigusaktidest tuleneb teisiti; 21.2.11 teeb tellijale kättesaadavaks kogu teabe, mida tellija peab vajalikuks lepingus sätestatud kohustuste täitmise tõendamiseks; 21.2.12 võimaldab tellijal või tellija poolt volitatud audiitoril teha auditeid ja kontrolle ning panustab nendesse; 21.2.13 kohustub võimaluse piires asjakohaste tehniliste ja korralduslike meetmete abil punktis 21.2.2. nimetatud isikuandmete osas tellijal täita tellija kohustust vastata taotlustele andmesubjekti õiguste teostamiseks ning teostada nende õiguste teostamisest tulenevaid toiminguid (andmete parandamine, sulgemine, kustutamine). 21.3 Käesoleva lepingu punktis 21.2.1. sätestatud konfidentsiaalsuse nõue ei laiene informatsiooni avaldamisele täitja audiitorile ja advokaadile. 21.4 Käesoleva lepingu punktides 21.2.1. ja 21.2.2. sätestatud konfidentsiaalsuskohustuse nõue on tähtajatu ning kehtib nii lepingu täitmise ajal kui ka pärast lepingu lõppemist. 21.5 Tulenevalt konfidentsiaalse informatsiooni laadist on tellijal õigus seada täiendavaid nõuded ja/või juhised isikuandmete töötlemiseks. 21.6 Kõik käesoleva lepingu punktides 21.2.1. – 21.4 kohustused kehtestab täitja kõikidele kolmandatele isikutele, keda ta kasutab oma lepingujärgsete kohustuste täitmisel. Kolmas isik on füüsiline või juriidiline isik või riigi- või kohaliku omavalitsuse asutus, kes ei ole ei tellija ega ka täitja. 22 Avalikud suhted 22.1 Pooled ei tegele seoses lepinguga avalike suhetega ega anna teateid pressile, elektroonilisele meediale, üldsusele või teistele auditooriumidele, välja arvatud teise poole eelneval kirjalikul nõusolekul. Avaldada võib vaid teateid, mis on teise poolega eelnevalt kooskõlastatud. 22.2 Kõik eelnimetatud kohustused kehtestab pool ka kõigile kolmandatele isikutele, keda ta kasutab oma lepingujärgsete kohustuste täitmisel. 23 Lepingu täitmise peatamine ja lepingu lõpetamine 23.1 Tellija võib peatada täitjale lepingujärgselt makstavate summade maksmise kas osaliselt või täielikult, kui: 23.1.1 täitja ei täida lepingut; 23.1.2 vastuvõtmise, testimise või auditeerimise käigus avastatakse puudusi või muid täitja poolseid kohustuste rikkumisi; 23.1.3 tellija lepingu järgsete kohustuste õigeaegset ja korrektset täitmist segab või ähvardab segada muu asjaolu, mille eest vastutab täitja. 23.2 Täitja võib peatada tellijale teenuse osutamise kas osaliselt või täielikult, kui: 23.2.1 tellija ei täida lepingut; 23.2.2 täitja lepingu järgsete kohustuste õigeaegset ja korrektset täitmist segab või ähvardab segada muu asjaolu, mille eest vastutab tellija. 23.3 Tellija võib igal ajal lepingu üles öelda, teatades sellest 1 (üks) kuu ette. Sellisel juhul on täitjal õigus nõuda tasu täidetud kohustuste eest. 23.4 Tellijal on õigus leping erakorraliselt etteteatamata lõpetada täitjapoolse olulise lepingu rikkumise korral. Lepingu lõpetamisel punktides 8.4 nimetatud juhtudel täitja tehtud tööd ei tasustata. Täitja poolt tarnitud seadmed, telekommunikatsioonid ja tarkvara tagastatakse, selle võimatuse korral või muul juhul, kui tagastamine on saadu olemuse tõttu välistatud, makstakse hüvitust võlaõigusseaduses sätestatud korras. 23.5 Täitja võib lepingu üles öelda tellijapoolse olulise lepingu rikkumise korral pärast vastava hoiatuse saatmist, kui rikkumist ei ole kõrvaldatud 10 (kümne) tööpäeva jooksul peale  hoiatuse esitamist. Sellise lepingu lõpetamise korral maksab tellija täitjale tasu täidetud kohustuste eest. 23.6 Lepingu lõppemisel on täitja kohustatud tellijale tagastama kõik lepingu täitmiseks üleantu. 24 Vääramatu jõud 24.1 Lepingust tulenevate kohustuste mittetäitmist või mittenõuetekohast täitmist ei loeta lepingu rikkumiseks, kui selle põhjuseks oli vääramatu jõud. Vääramatu jõuna käsitlevad pooled võlaõigusseaduse §-s 103 lg 2 nimetatud asjaolusid. 24.2 Pool, kelle tegevus lepingujärgsete kohustuste täitmisel on takistatud vääramatu jõu asjaolude tõttu, on kohustatud sellest koheselt kirjalikult teatama teisele poolele, esitades teavitusega ühes tõendid kõigi järgnevate asjaolude esinemise kohta: 24.2.1 takistava asjaolu esinemine, mis takistab kohustuse kohast täitmist; 24.2.2 takistava asjaolu asetsemine väljaspool võlgniku mõjusfääri; 24.2.3 asjaolu ettenägematus; 24.2.4 asjaolu vältimatus ja ületamatus. 24.3 Vääramatu jõu asjaolude ilmnemisel pikeneb lepingu lõpptähtaeg nimetatud asjaolude esinemise perioodi võrra. Pool peab vääramatu jõu asjaolude äralangemisel lepingut täitma asuma. Kui vääramatu jõu asjaolude tõttu on poole lepingust tulenevate kohustuste täitmine takistatud enam kui 60ne kalendripäeva võrra võib teine pool öelda lepingu üles. 25 Kehtiv seadusandlus Lepingule ning kõikidele lepingu osaks olevatele dokumentidele kohaldatakse Eesti Vabariigi õigusakte. 26 Vaidluste lahendamine 26.1 Käesoleva lepingu allkirjastamisega kinnitavad pooled, et on tutvunud ja on nõus lepinguga ja selle lisadega ning mõistavad täielikult enesele võetavate kohustuste sisu ning nende tagajärgi. 26.2 Lepinguga seotud või sellest tulenevate arusaamatuste või vaidluste puhul püüavad pooled leida lahenduse heal tahtel põhinevate läbirääkimiste teel. 26.3 Kokkuleppe mittesaavutamisel lahendatakse vaidlus Harju Maakohtus.  Arendusleping nr 2/48-25 Lisa nr 3 Registrite ja Infosüsteemide Keskus „Kohtulahendite andmete automatiseeritud edastamine kohtute infosüsteemi ja rahvastikuregistri vahel- analüüs“ Hankelepingu tehniline kirjeldus  Tallinn 2025 Sisukord 1. Hankelepingu üldinfo ...................................................................................................................... 3 2. Hankelepingu nõuded ..................................................................................................................... 4 2.1. Hetkeolukorra kirjeldus ............................................................................................................... 4 2.2. Probleemid .................................................................................................................................. 5 2.3. Kasutajagrupid ............................................................................................................................. 5 2.4. Analüüsi ja arendustööde hankelepingu eesmärgid ja tulem ..................................................... 5 2.5. KIS-RR edastatavad andmed ....................................................................................................... 6 2.6. Andmete edastamise sagedus ja kord vastavalt hetkel kehtivale seadusele.............................. 8 3. Projektipõhised nõuded ja töökorraldus ......................................................................................... 8 2  1. Hankelepingu üldinfo 1.1. Hankelepingu eesmärgiks on kohtumenetluse protsesside analüüsimine kohtulahendite andmete automatiseeritud edastamiseks kohtute infosüsteemi ja rahvastikuregistri vahel. 1.2. Hankelepingu tulemusena valmiv analüüs peab olema sobilik ning piisav teise hankelepingu arendustööde läbiviimiseks. 1.3. Hankeleping jõustub allkirjastamise hetkest ja kehtib kuni lepingujärgsete kohustuste nõuetekohase täitmiseni. Pakkujal peab olema valmisolek alustada hankelepingujärgsete tööde teostamisega kahe nädala jooksul hankelepingu sõlmimisest ja nimetatud tingimusega tuleb pakkujatel pakkumust, s.h projektiplaani, esitades arvestada. 1.4. Hankelepingu eeldatavaks maksumuseks on 20 000 eurot (km-ta). 1.5. Töid teostatakse ja arveldatakse ühes (1) etapis. Hankelepingu alusel teostatavate töö eest tasumine toimub ühes osas pärast töö lõplikku vastuvõtmist. 1.6. Hankelepingu järgsete tööde (tehnilise kirjelduse punkt 2 ning selle alapunktid) üleandmise lõpptähtaeg on 6 kuud arvates hankelepingu sõlmimisest. Hankija poolt antav tööde teostamise tähtaeg on hankija hinnang. Hankija ei anna ette konkreetset meeskonnaliikmete arvu tööde teostamisel. Pakkuja on kohustatud tagama tööde teostamise hankija poolt hankes ette antud tähtajaks pakkuja poolt vajalikuks peetavate meeskonnaliikmete arvuga. Juhul, kui pakkuja leiab, et hankija poolt etteantud tähtaeg on ebarealistlik, siis on pakkuja kohustatud seda pakkumust tehes või sellele eelnevalt hankijale teada andma. Hankelepingu täitmisel on vastavate sooviavalduste esitamine välistatud, v.a hankija poolt lisatööde tellimise olukorras või muul riigihangete seaduse §-s 123 toodud lepingu muudatust võimaldavas olukorras 1.7. Lepingujärgsete tööde teostamisel on pakkujal õigus teha omapoolseid täiendus- ja muudatusettepanekuid. Kui hankija nõustub pakkuja poolsete täiendus- ja/või muudatusettepanekutega, ei ole pakkuja kohustatud tööde teostamisel lähtuma sõlmitava tellimuse kirjeldusest määral, mis vastab uutele kokkulepetele. Vajadusel koostatakse vastav lepingu lisa. Pakkuja peab rõhutama juhul kui pakkuja poolne muudatusettepanek tähendab lisatöid hankijale. Vastava teavituse puudumisel eeldab hankija, et muudatuse realiseerimiseks ei teostata lisatöid. 1.8. Pakkuja poolt teostatavate tööde garantiiperioodiks on 6 kuud. 1.9. Iga viidet, mille hankija teeb käesolevas dokumendis mõnele riigihangete seaduse paragrahvi 88 lõikes 2 nimetatud alusele kui pakkumuse tehnilisele kirjeldusele vastavuse kriteeriumile, tuleb lugeda selliselt, et see on täiendatud märkega „või sellega samaväärne“. 1.10. Iga viidet, mille hankija teeb käesolevas dokumendis ostuallikale, protsessile, kaubamärgile, patendile, tüübile, päritolule või tootmisviisile, tuleb lugeda selliselt, et see on täiendatud märkega „või sellega samaväärne“. 3  2. Hankelepingu nõuded 2.1. Hetkeolukorra kirjeldus Rahvastikuregistri seaduse (RRS) kohaselt on kohtud andmeandjaks. Rahvastikuregistri (RR) andmeandjateks on asutused ja isikud, kes annavad välja või koostavad RRS § 22 lõikes 1 loetletud dokumente (sh kohtulahend), annavad rahvastikuregistrisse andmeid nendelt dokumentidelt või kelle tegevuse tulemusel muutuvad RRS § 21 lõikes 1 sätestatud isikuandmed (RRS § 29 lg 1). Kohtud on kohustatud andma kohtulahendi väljaandmise, jõustumise, muutmise ja kehtetuks tunnistamise andmed, mis tekitavad, muudavad või täpsustavad rahvastikuregistri andmeid (RRS § 28). Käesoleval ajal toimub automatiseeritud andmete edastamine kohtu ja RR-i vahel vaid abielulahutuse kohtulahendite korral. Täna on KISis lahendite osas andmetena olemas ja kättesaadavad lahendi põhiandmed, kuid mitte seda osa andmetest, mida on vaja sisestada RR-i täieliku kande sooritamiseks. RR-i sisestatavad (va. lahendi põhiandmed) andmed on täna olemas vaid lahendi failis teksti kujul. Teistes kohtuasjades (näiteks eestkostja määramine, isiku põlvnemine, lapsendamine jms) edastavad kohtud lahendid kohalike omavalitsuste (KOV) perekonnaseisuametnikele RRi sisestamiseks. Lahend saadetakse elektronposti teel KOV-ile, eelnevalt vastavale KOVi ametniku nimele krüpteerides. Ametnik kontrollib, kas kohtulahend on jõustunud või muutunud täidetavaks ning kas lahend muudab RR-is olevaid andmeid. Kui kohtulahend vastab seaduses sätestatud nõuetele, avab ametnik toimiku, valides toimiku liigi vastavalt kohtulahendi sisule. Andmeid sisestatakse KOV ametniku poolt RR-is vastavalt kohtulahendi resolutsioonile ja kohtulahendite sisestamise juhendile. Liigiti tuleb täita erinevaid andmevälju ja andmehõive sakke. Näiteks teovõime lahendi puhul tuleb täna vastavalt kohtulahendi resolutsioonile ametnikul täita „Teovõime liik“ andmeväli ja sisestada otsus „Märkus“ andmeväljale. Teovõime liik on alati tühi, kui isikul puudub varasem kogemus temale eestkoste määramisega. Vastavalt kohtulahendi resolutsioonile valib ametnik isiku teovõime liigiks kas „Piiratud (valimisõiguseta)“ või „Piiratud (valimisõigusega)“. Juhul, kui uus kohtulahend tühistab olemasoleva piirangu, siis lisatakse isikule teovõime liigiks „Teovõimeline“. Muude lahendi liikide puhul täpsustatakse andmestikku lepingu täitmisel. 2024.a edastati kohtute poolt KOV ametnikele andmete RRi sisestamiseks 3487 kohtulahendit:  Eestkostja määramise, muutmise, tühistamise kohtulahendid - 2457;  Isiku põlvnemise, tühistamise tuvastamise kohtulahendid - 66;  Ruumist väljatõstmise kohtulahendid – 3;  Surnuks tunnistamise kohtulahendid – 35;  Vanema hooldusõiguse muutmise kohtulahendid – 779;  Vanema kande vaidlustamise kohtulahendid – 15;  Lapsendamise kohtulahend – 52. 4 2.2. Probleemid Peamised probleemid tänase elektronpostiga andmete edastamise protsessi osas: aeganõudev ja töömahukas andmete käsitsi sisestamine, lahendite tõlgendamisest tingitud vead, kohtulahendite hilinenud või ebaühtlane edastamine, koormus Siseministeeriumile järelevalve ja koolituse osas. Kohtunikul puudub võimalus koostada lahend andmete põhjal. Kohtulahendi andmete sisestamisele RR-is kulub KOV perekonnaseisuametnikul täna keskmiselt 40 minutit. Lahendi sisestamine nõuab tihti kohtulahendist arusaamiseks lahendi tõlgendamist ja sellest tulenevalt ka aeg ajalt kohtu või Siseministeeriumiga suhtlemist. KOV ametniku poolt lahendi tõlgendamine võib kaasa tuua aga tõlgendusvigu. Samuti on ette tulnud probleeme kohtulahendite õigeaegse edastamisega. On kohtuid, kes edastavad lahendid viivitamata, samal päeval, kuid on ka kohtuid, kes edastavad lahendi alles siis, kui KOV ametnikul tekib põhjus lahendit küsida või ta saab osapoolelt teada, et lahend on tehtud. Kohtu poolt andmete sisestamine KIS-is ja nende automaatne edastamine RR-i aitab oluliselt kaasa ülaltoodud probleemide ärahoidmisele ning lisaks väheneb nii KOV ametniku töömaht kui ka üldine halduskoormus riigis, kuna protsessis jääb üks lüli vahelt välja. Kohtu poolt andmete sisestamine KIS-is suurendab ka õiguskindlust, sest kohus sisestab enda tehtud lahendit ning perekonnaseisuametnik ei pea lahendit enam tõlgendama. See tähendab vähem vigu, mis seotud lahendist valesti arusaamisega. Siseministeerium teeb rahvastikuregistris erinevaid kvaliteeditöid, sealhulgas selliseid, mis puudutavad kohtulahendite alusel tehtud muudatusi rahvastikuregistris. Kui andmed liiguksid kohtust otse RR-i, väheneks oluliselt ka Siseministeerium töömaht, kuna edastatud kohtulahendite sisestamise üle ei pea Siseministeerium teostama enam järelevalvet ega koolitama selles osas perekonnaseisuametnikke ega kohtuid. 2.3. Kasutajagrupid KISi kasutajad jagunevad kolme peamisesse kasutajagruppi: menetleja, menetlusgrupi liige, kantselei. Esimese hankelepingu raames analüüsitav ja teise hankelepingu raames arendatav lahendus on suunatud neist kahele: kohtunik (menetleja) ja menetlusgrupi liige. Vajadusel peab ka kantselei ametnikul olema võimalik lahendust kasutada. Kasutajagruppide vajadused kohtulahendite andmete edastamise osas sõltuvad järgnevast: a) Kohtuaste – I astme, II astme ja III astme menetlevate kasutajate vajadused on erinevad; b) Töökorraldus – Erisused töökorralduses sõltuvad nii kohtust kui ka kohtunikust; c) Kasutaja roll menetluses – Kohtunike kasutajagrupis on neli eristatavat rolli ja menetlusgrupi liikme kasutajagrupis on kolm eristatavat rolli. 2.4. Analüüsi ja arendustööde hankelepingu eesmärgid ja tulem 2.4.1. „Kohtulahendite andmete automatiseeritud edastamine kohtute infosüsteemi ja rahvastikuregistri vahel“ projekti üldeesmärgiks on tagada õigeaegne, täpne ja sujuv kohtulahendite kajastumine rahvastikuregistris, toetades seeläbi usaldusväärset andmekvaliteeti ning õiguskindlust. Andmete edastamine kohtute infosüsteemi ja rahvastikuregistri vahel toimub automaatselt kohtulahendi koostamisel ning seeläbi 5  on tagatud andmete ühekordne sisestamine ja õigsus - kohtulahendis olevad andmed liiguvad automaatselt RRi. 2.4.2. Üldeesmärgist lähtuvalt on käesoleva analüüsi hankelepingu objektiks kasutajakeskse ja (töö)aega säästva lahenduse loomine, mis arvestab erinevate kasutajagruppide vajadustega ning sisaldab järgmisi tegevusi: ideatsioon ja äri- ning süsteemianalüüs, kasutajaliidese prototüübi loomine ja tagasisidestamine. Silmas tuleb pidada, et erinevate kasutajagruppide vajadustega arvestamine toob kaasa mitmete spetsiifiliste vormide loomise. 2.4.3. Erinevaid kasutajagruppe esindavate kasutajatega viiakse läbi detailsem vajaduste analüüs, mis on täiendavaks sisendiks analüüsile järgnevale tööprotsesside optimeerimisele ja töökeskkonna disainile. 2.4.4. Pakkuja süstematiseerib kasutajatelt kogutud probleemide ja ettepanekute kirjeldused tööprotsesside etappide või teemavaldkonna põhiselt ning esitab analüüsi käigus kogutud teabe ja analüüsi tulemused Hankijale tagasiside andmiseks. Analüüsis väljapakutavad lahendused kooskõlastatakse hankijaga. 2.4.5. Käesoleva hankelepingu tulemi (analüüsi) alusel teostatava teise (arendustööde) hankelepingu tööde tulemusena on lihtsustatud ja automatiseeritud kohtulahendite andmete edastamine ja RR-i kandmise protsess resolutsiooni klassifikaatorite loomise abil. Andmete edastamine KIS  RR teostatakse tulevikus kokkulepitud klassifikaatorite kaudu ja ametnik ei pea RR-i enam andmeid sisestama. RR hakkab küsima kohtulahendite andmeid KIS-i poolt klassifikaatorite kaudu. Käsitsi andmete sisestamist RRis enam ei toimu. 2.4.6. Kasutajaliides peab võimaldama hõlpsalt sisestada ja muuta lahendi osas RR-i edastatavaid andmeid. Analüüsi ja arenduse käigus tuleb arvestada ka olukordadega, kus esitatakse algsele lahendile kaebus ja seda menetletakse edasi enne lõplikku otsuse jõustumist, sealjuures algne lahend saab mõjutatud uuest otsusest teises sama kohtuasja menetluses. Näiteks kui kohtulahendi peale esitatakse määruskaebus, peab lahendus automaatselt tuvastama edasikaebamise fakti ja jälgima määruse kehtivust. Lahendus peab tagama, et edasikaebuse rahuldamisel, lahendi muutmisel või tühistamisel edastatakse RRi ajakohastatud andmed. Süsteem peab võimaldama määruskaebuse lahendamist kõigil kohtutasanditel (maakohus, ringkonnakohus ja Riigikohus). 2.4.7. KIS-i sisestatud andmete põhjal peavad moodustuma lisaks RRi minevatele andmetele ka lahendi erinevad osad tekstilisel kujul. Tekstilist osa peab olema näha ja võimalik mõjutada muutes vastavaid algandmeid, millest tekst moodustub. Lisaks peab olema vajadusel võimalik genereerida andmete pealt tervik kohtulahendi fail või selle osa (nt resolutiivosa), mida saab vajadusel kasutada näiteks pankadele esitamiseks. 2.4.8. Analüüsi ja arendustööde hankelepingute tulemuseks peab olema automatiseeritud lahendus, mille kaudu edastatakse kohtulahendite andmeid RR-i ilma manuaalse sekkumiseta. 2.5. KIS-RR edastatavad andmed Kasutajaliideses peab saama sisestada ja muuta eestkoste seadmise, lõpetamise ja muudatustega seotud määruseid; teovõime piiramisega seotud määruseid (sh valimisõigusega seotud); vanema õiguste äravõtmise, taastamise ja hooldusõiguse 6 muudatusi; isiku surnuks tunnistamise määrusi ja sellega seotud määruste tühistamisi; isiku põlvnemise tuvastamise ja selle tühistamise määruseid ning lapsendamise määruseid. 2.5.1. Kohtulahendi andmed:  Dokumendi liik (kohtulahend)  Dokumendi nimetus (kohtumäärus)  Dokumendi number  Dokumendi koostamise, jõustumise, kehtetuks tunnistamise või tühistamise kuupäev  Dokumendi koostanud kohtu nimetus 2.5.2. Eestkoste andmed:  Eestkostja(te) ees- ja perekonnanimi või asutuse nimetus  Eestkostja(te) isiku- või registrikood  Eestkoste alguse ja lõppemise kuupäev  Eestkoste lõpp/pikendamine (määrus kehtib kuni 5 aastat määruse tegemisest).  Piiratud teovõimega isiku poolt iseseisvalt tehtavad tehingud:  Rahaliste tehingute tegemise tingimused (summa, periood, % sissetulekust)  Vabatekstiväli muude tehingupiirangute kirjeldamiseks  Perekonnaõiguslike tehingute luba  Kohus võib lisaks: eestkostja ülesannete ringi laiendada; eestkostja ametiaega pikendada; lõpetada eestkoste; eestkostja ülesannete ringi kitsendada; laiendada eestkostetava iseseisvalt tehingute tegemise õigust; eestkostja ametist vabastada. 2.5.3. Teovõime piiramise andmed:  Teovõime piiramise fakt  Valimisõiguse tähenduses teovõimetuks tunnistamise fakt 2.5.4. Vanema hooldusõiguse muudatuste andmed:  Vanema nimi ja isikukood  Lapse nimi ja isikukood  Hooldusõiguse liik: täielik isikuhooldusõigus, täielik varahooldusõigus, piiratud isikuhooldusõigus, piiratud varahooldusõigus, osaline isikuhooldusõigus, osaline varahooldusõigus, lapse eraldamine vanemast (Kõik hooldusõiguse liigid tuleb valida eraldi, korraga liiki valida ei ole võimalik)  Hooldusõiguse olek: kehtiv, peatatud, piiratud, osaliselt üle antud, täielikult üle antud, täielikult ära võetud, taastatud, lõppenud, tühistatud  Hooldusõiguse kehtivuse algus- ja lõppkuupäev  Hooldusõiguse sisu ja kohtulahendi resolutsiooni kokkuvõte (vabatekstiväli)  Muuta peab saama kõiki hooldusõiguste liike ja olekuid, lisaks peab saama muuta ka hooldusõiguse alguse ja lõpukuupäeva. 2.5.5. Andmete sisestuse osas jagatakse andmesisestus kaheks blokiks (vaateks): 1) vanemate hooldusõiguse muudatusega seotud andmed ning 2) eestkostet puudutavad andmed (millega on seotud ka alaealise isiku eestkostja hooldusõiguse andmed vähemalt alaealisele esmasel konkreetse eeskostja määramisel). 7   Teatud tingimustel peab kohtukasutajal olema võimalik sisestada mõlemaid andmeid ühe lahendi juurest ning võimalikud on ka olukorrad, kus kasutaja peab saama sisestada kas üksnes hooldusõiguse muutustega seotud andmeid või eestkostet puudutavaid andmeid. 2.5.6. Isiku põlvnemise tuvastamise kohtulahend  KIS - RRi läheb isa kanne ja hooldusõigus (hooldusõiguse kohtulahend) 2.5.7. Isiku põlvnemise tühistamise kohtulahend  Kohus tühistab isiku põlvnemise 2.5.8. Surnuks tunnistamise kohtulahend  Isik tunnistatakse surnuks ja määratakse surmakuupäev 2.5.9. Vanema kande vaidlustamise kohtulahend  Kohus tuvastab, et laps ei põlvne sellest isast. Lisaks määrab kohus isa, kellest laps põlvneb (isiku põlvnemise tuvastamise kohtulahend) 2.5.10. Lapsendamise kohtulahend  Uue/uute vanemate andmed  Andmete sisestamise eeldus on ka õiguste süsteemi täiendamine uue tasemega 2.5.11. Abielulahutamise ja kooselulepingute lõpetamise kohtulahendid  Kohus lahutab või tunnistab kehtetuks poole vahel sõlmitud abielu  Vajadusel toimub nime muudatus  Kohus lõpetab või tunnistab kehtetuks kooselulepingu  Kohus tuvastab abielu või kooselulepingu olemasolu või puudumise 2.6. Andmete edastamise sagedus ja kord vastavalt hetkel kehtivale seadusele 2.6.1. Esialgse õiguskaitse korras tehtud lahendite andmed edastatakse RR-i lahendi tegemise kuupäeval. 2.6.2. Eestkoste seadmist puudutavad andmed edastatakse RR-i samuti lahendi tegemise kuupäeval. 2.6.3. Vanema hooldusõiguse andmed edastatakse RR-i pärast lahendi jõustumist. 2.6.4. Kui määrus vaidlustatakse, edastatakse RR-i info peale kaebuse menetlemist tekkinud muudatused kohe pärast uue määruse jõustumist. Andmeliidese KIS-ET-RR tööpõhimõtted selguvad analüüsis ja vajadusel täpsustatakse arendustellimuses. 3. Projektipõhised nõuded ja töökorraldus 3.1. Projekti ja arendustöid juhib pakkuja. Pakkuja peab kinni pidama hanke alusdokumentidest ja tellimustest ning esitatud pakkumustest. Projekti elluviimisel on 8  oluline tihe koostöö RIKi kohtute infosüsteemi tiimiga, JDM Tellijaga ning kohtutest kasutajate esindajatega. Koostööna jõutakse ühistele arusaamadele kooskõlastatavate tegevuste osas ning üleantavate tulemite detailides, sh peab hankija olema pakkujaga samas infoväljas ning omama ülevaadet teostatavate tööde seisust ja pakkumuse koosseisus esitatava projektiplaani järgimisest. Kõik arhitektuursed lahendused peavad olema enne tööde alustamist kooskõlastatud hankijaga. Vajadusel moodustatakse juhtrühm. 3.2. Käesoleva hankelepingu tööd peavad vastama RIKis kehtestatud nõuetele, mille hulgas tuleb lähtuda alljärgnevatest nõuetest. 3.2.1. Arendustele (Lisa 1 – Nõuded arendustele); 3.2.2. Süsteemianalüüsile (Lisa 2– Nõuded süsteemianalüüsile) 3.3. Projekti raames koostatud dokumentatsioon peab vastama järgmistele vormistusnõuetele: 3.3.1. Dokumentide teemad ja peatükid on loogiliselt struktureeritud ja esitatud koos sisukorraga (või seda asendava funktsionaalsusega). 3.3.2. Dokumendid ei sisalda kirjavigu ja on koostatud võimalikult üheselt arusaadava ja selge lauseehitusega. 3.3.3. Dokumentide sisu osas vastutuse selgemaks eristamiseks on dokumendis märgitud kõik selle koostajad eraldi nende osade juures, mida iga koostaja koostas. 3.3.4. Kõik kasutatud allikmaterjalid peavad olema viidetes ära märgitud ning viitamine teistele dokumentidele on selge ja ühtses stiilis. 3.3.5. Dokumendid on koostatud eesti keeles. 3.4. Projektiplaani esitamine. Hangitavate tööde teostamise tegevuskava kirjeldatakse ära pakkumuse osana esitatavas projektiplaanis. Tegevuste ajalise järjestuse ja korduvuse valib pakkuja. Projektiplaan, peab sisaldama ajakava kõikide hanke tehnilises kirjelduses (tellimuses) kirjeldatud tööde läbiviimiseks ja vastama vähemalt järgmistele nõuetele: 3.4.1. Projektiplaanis kirjeldatud tööde läbiviimise tulemusena peab olema saavutatud hankelepingu raames soovitud tööd. Projektiplaanis peavad kajastuma need tegevused, mis on vajalikud lõpptulemuse saavutamiseks. 3.4.2. Tegevused tuleb planeerida selliselt, et iga planeeritud etapi eel kooskõlastatakse tegevused Hankijaga. 3.4.3. Pärast iga etapi lõppemist tuleb planeerida etappide tulemite presenteerimine Hankijale. 3.4.4. Iga projektiplaani töö kohta peab olema kirjeldatud töö nimetus, töö tegija(te) roll/nimi, ajaline kestus ja tähtaeg. 3.4.5. Projektiplaanis peab kajastuma töö tegemiseks vajalikud eeldused/lähteandmed ning töö mõõdetav(ad) tulem(id). Projektiplaan peab sisaldama mh. tähtaegu, mis on rakendatavad hankijale/välisele osapoolele projekti edukaks realiseerimiseks vajalike sisendite tagamise kohta. 3.4.6. Kõik projektiplaanis kirjeldatud tööd peavad olema omavahel loogiliselt seotud ja jaotatud iteratsioonidena. 3.4.7. Projektiplaan peab sisaldama ka töid, mille teostamist eeldatakse Hankijalt või teiste kaasatud väliste osapoolte poolt. 3.4.8. Projektiplaan peab sisaldama varuaega (puhvrit) ja selles peab arvestama riiklike pühade, puhkepäevade ja projektimeeskonna puhkustega. 3.4.9. Projektiplaan peab olema ajakohastatud kogu projekti teostamise vältel. 9 3.4.10. Lisaks projektiplaanile tuleb kirjeldada, millist agiilset arendusmetoodikat kasutatakse ja kuidas seda plaanitakse praktiliselt rakendada (pakkumuse eraldi dokument). 3.4.11. Lisaks projektiplaanile tuleb kirjeldada, kuidas projektijuhtimise riske maandada kavatsetakse (pakkumuse eraldi dokument). Riskide maandamise võimalused ja halduse ettepanekud (lähtuvalt käesolevast projektist) on esitatud selgelt, detailselt, läbimõeldult, struktureeritult ja põhjendatult. 10