Raamleping

Nõuded infosüsteemi dokumentatsioonile Nõuded infosüsteemi dokumentatsioonile Versioon: 1.0 Dokumendid peavad vastama vähemalt alljärgnevatele tingimustele: Andmemudel Eeldus dokumendile: Teenuste/kasutuslugude dokumentatsioon Otstarve: Kirjeldada andmeobjekte ja nendevahelisi seoseid Sisu: Andmebaasi põhjal luua andmetabelite ja -objektide seosdiagramm. Sihtgrupp: Tellija, peakasutajad, rakenduse administraatorid Ajakava: enne esimese arendusetapi algust enne igat arendusetapi algust igakordsel tellijale testimisse andmisel Kirjeldada andmemudelit kontseptuaalse mudelina jah jah interaktioone/seoseid Kasutaja õiguste ja tegevuste vastavustabel Eeldus Süsteemi üldine kirjeldus dokumendile: Otstarve: Kirjeldada kasutaja rollide õigusi erinevates kasutuslugudes ja tegevustes Sisu: CRUD maatriks Sihtgrupp: Tellija äriprotsesse valdavad kontaktisikud, ärianalüütikud, süsteemianalüütikud, täitjast sõltumatud tarkvara hooldajad, arendajad ja edasiarendajad, testijad, arhitektid, projektijuhid. Ajakava: enne esimese arendusetapi algust enne igat arendusetapi algust igakordsel tellijale testimisse andmisel Nimetada kasutaja rollid jah Teenuste/kasutuslugude dokumentatsioon Eeldus Süsteemi üldine kirjeldus dokumendile: Otstarve: Kirjeldab detailselt üleantavaid teenuseid/kasutuslugusid. Sisu: Teenuste/kasutuslugude detailse kirjelduse sisuks on: Tehnilised parameetrid; Veateated/Hoiatused; Teostatavad kontrollid; Funktsionaalsuse enda põhiprotsess ja mõned sagedamini esinevad alternatiivsed protsessid (vastavalt vajadusele); Üldine kirjeldus, kuidas ja kus kajastub antud teenus/kasutuslugu tervikprotsessis; Nõudeid ja reegleid toetavad (sisu mõistmisele kaasaaitavad) pildid, diagrammid, tabelid, loendid Andmevahetuse teenuste kirjeldus (andmete küsimine/vastuvõtmine, turvalisus, teenuse andmestik, klassifikaatorid, xml/xsd schema ) Protsesside UML vaated Sihtgrupp: Tellija äriprotsesse valdavad kontaktisikud, ärianalüütikud, süsteemianalüütikud, täitjast sõltumatud tarkvara hooldajad, arendajad ja edasiarendajad, testijad, arhitektid, projektijuhid. Ajakava: enne esimese arendusetapi algust enne igat arendusetapi algust igakordsel tellijale testimisse andmisel Nimetada kasutuslood jah Arhitektuuridokument Eeldus Süsteemi üldine kirjeldus dokumendil e: Otstarve: Dokumendi eesmärgiks on kirjeldada loodava süsteemi üldist ehitust. Kirjeldatakse rakenduse loogilist struktuuri, näidates ära selle kihtideks jagunemise korda. Kirjeldatakse ka füüsilist arhitektuuri, antakse ülevaade kasutatavatest tehnoloogiatest ning vahenditest. Sisu: Dokument peab rahuldama vähemalt alljärgnevaid sisunõudeid: 1. topoloogia, süsteemi füüsiline arhitektuur (süsteemi komponendid andmebaasiserver, rakendusserver, meiliserver jms) 2. Nõuded arhitektuurile (operatsioonisüsteem, andmebaasid, liidestused, rakendusserverid, raamistikud, teenused) 3. Nõuded käideldavusele (süsteemi soovituslikud näitajad komponentide kaupa, näiteks andmesidekiirused, kättesaadavus, andmemahud, protsessori kiirus, mälumaht, komponentide arv süsteemi osade kaupa, kettasüsteemi jõudlus jms) 4. liidesed teiste süsteemidega (x-tee, meilisüsteemid) ja sõltuvused teistest süsteemidest. Liideste kirjeldused/otstarve 5. süsteemi tehnilised (sh automaatsed) protsessid ehk töövoog – komponentide omavahelised suhtlusstsenaariumid ja koostoimimine (näiteks, mis komponent ja millal pöördub n teenuse poole) 6. kolmandate osapoolte poolt toodetud kasutatavad tarkvarad/riistvarad, mis on vajalikud süsteemi toimimiseks Sihtgrupp: Arhitekt, administraator, turvaspetsialist Ajakava: enne esimese arendusetapi algust enne igat arendusetapi algust igakordsel tellijale testimisse andmisel Dokumendi esialgne versioon jah Seadmete ja tarkvara kasutajakesksed juhendid Eel Teenuste/kasutuslugude dokumentatsioon dus dok um end ile: Ots Teenuse funktsionaalsuse kasutamiseks ja kasutuslugude läbimiseks vajalikud juhised tarv e: Sis Igale esitluskihile peab olema koostatud eraldi kasutusjuhend, mis kirjeldab vastava komponendi funktsionaalsuse kasutusvoo põhiselt. Kirjeldus tarkvara ja u: seadmete kasutamise üldisest protsessist, protsessi olulisemate sammude kirjeldus. Koostatakse projekti lähteanalüüsi aluseks võttes. Tarkvara kasutusjuhend on aluseks kasutajate koolitamisel. Kasutajajuhend kirjeldab kõiki kasutajate funktsionaalsusi koos tööprotsesside kirjeldusega ning ekraanipiltide vormis näidetega. Haldusliidese kasutusjuhend (peakasutaja ja rakenduse administraatori funktsionaalsus) peab olema eraldi tavakasutaja kasutusjuhendist. Esitluskihi kasutusjuhendi minimaalne ülesehitus: lühitutvustus üldine kirjeldus koos komponentidega autentimine (kui eksisteerib) komponentide detailne kirjeldus koos kõikide funktsionaalsustega Rollide kirjeldus ja õigused Siht Tarkvara kasutajad, peakasutaja, rakenduse administraator gru pp: Aja enne esimese arendusetapi algust enne igat arendusetapi algust igakordsel tellijale testimisse andmisel kav a: jah Paigalduse ja administreerimise juhend Eeldus dokumendil Arhitektuuridokument e: Süsteemi üldine kirjeldus Otstarve: Juhend on aluseks süsteemi administreerimisele Sisu: Juhend peab rahuldama vähemalt alljärgnevaid sisunõudeid: 1. süsteemi parameetrite (seadistuste) kirjeldus ning nende muutmiste mõjud ja protseduurid. Konfiguratsioonifailide kirjeldus koos asukohtadega failisüsteemis; 2. logimise realisatsiooni kirjeldused (kuhu, mida, logide struktuur 3. rutiinsete hooldusprotseduuride kirjeldus (komponentide taaskäivituse vajadus parameetrite muutmisel); 4. paigaldamise protseduurid. 4.1 Nõuded rakenduse komponentidele 4.2 Rakenduse paigaldus (Vajalik tarkvara ja konfigureerimine, rakenduse pakkimine ja paigaldamine) 4.3 Andmete alglaadimine 4.4 Varundusskript 4.5 Monitooringu kirjeldus Juhendis kirjeldatakse iga realiseeritud osa rakendamine (deployment) koos spetsiifiliste seadistustega. Paigaldamise protseduurid peavad olema kirjutatud selliselt (samm sammult), et süsteemiadministraator suudab rakenduse paigaldada ilma kõrvalise abita. Sihtgrupp: Peakasutaja, projektijuht, süsteemiadministraator Ajakava: enne esimese arendusetapi algust enne igat arendusetapi algust igakordsel tellijale testimisse andmisel jah Lähtekood (sh andmebaasi struktuur) Eeldus dokumendile: Arhitektuuridokument Teenuste/kasutuslugude dokumentatsioon Andmemudel Kasutaja õiguste ja tegevuste vastavustabel Prototüüp Otstarve: Lähtekood on vajalik selleks et kompileerida rakendust, ning võimaldada tulevikus rakenduse muutmist. Sisu: Lähtekood peab olema hästi struktureeritud, piisavalt dokumenteeritud ning võimalikult lihtne, et sellest saaksid aru ka teised arendajad. Lähtekood peab vastama MFNile Lähtekood peab olema pakendatud vastavalt versioonimisjuhendile. Rakenduste lähtekood peab olema piisavalt modulaarne, et seda saaks tulevikus lihtsasti täiendada ning muuta. Ajakava: enne esimese arendusetapi algust enne igat arendusetapi algust igakordsel tellijale testimisse andmisel Versioonihaldus tuleb teha Tellijakeskkonnas (nt Gitlab), sh ka jooksvaid commit’e Koormustestide dokumentatsioon Eeldus dokumendile: Teenuste/kasutuslugude dokumentatsioon Prototüüp (ainult kasutajaliidesega rakenduse puhul) Arhitektuuridokument Otstarve: Määrata kindlaks arendusetapil testitavad kasutuslood ja liidesed (sh välja tuua need, mille puhul rakendatakse koormusteste) tuues välja nende järjekorra. Sisu: Järjestatud (võib olla ka paralleelne) nimekiri kasutuslugudest ja liidestest (vajadusel määrates nende ulatust) koos märkega, mis on koormustestiga tagatud ning millel on testandmed Sihtgrupp: Tellijapoolne projektijuht, vastuvõtutestijad Ajakava: enne esimese arendusetapi algust enne igat arendusetapi algust igakordsel tellijale testimisse andmisel Nimetada kasutuslood, mille puhul rakendatakse koormusteste jah Testimise tulemite dokumentatsioon Eeldus Koormustestide dokumentatsioon dokume ndile: Otstarv Anda tellijale ülevaade läbiviidud testimise tulemustest ning esitada soovitused testandmete ja dokumentatsiooni parendamiseks (ettevalmistus, paigaldus, e: kasutuslugude kirjeldus jne). Sisu: Teostatud arenduste testimisel saadud informatsioon (näiteks testlood, testraport, testiplaan, testide kood jms). Dokumenteeritakse iga testimise eesmärgid (testimise maht ja ulatus), tegevused ja tulemused. Sisaldab jõudlus- ja mahutestide infot ning versiooni infot. Teste mitteläbinud testlugudele on lisatud parandused või ülesjäänud vead. MFNi vastavustabel Sihtgru Arhitekt, süsteemiadministraator, turvaspetsialist pp: Ajakava: enne esimese arendusetapi algust enne igat arendusetapi algust igakordsel tellijale testimisse andmisel jah Automaattestimise tulemite dokumentatsioon Eeldus dokumendile: Lähtekood (sh andmebaasi struktuur) Otstarve: Anda tellijale ülevaade läbiviidud automaattestimise tulemustest. Sisu: Ülevaade SonarQube’is (testide nimekiri, testide käivitamise tulemus, koodi kaetavus). Sihtgrupp: Arhitekt, süsteemiadministraator, turvaspetsialist Ajakava: enne esimese arendusetapi algust enne igat arendusetapi algust igakordsel tellijale testimisse andmisel jah Taasteplaani tegemise juhend Otstarve: Kirjeldada erisused, millega tuleb arvestada taasteplaani loomisel Sisu: Taasteplaan peab rahuldama vähemalt alljärgnevaid sisunõudeid: 1. süsteemi halvamist võimaldavad riskid ja nende esinemise võimalikkus; 2. varundamisele kuuluvate komponentide ja asukohtade loetelu (nt rakenduse konfiguratsioonifailid rakendusserverist ja andmebaas jne), nende kirjeldused ja kasutuselevõtu protseduurid; 3. süsteemi komponentide asendusvõimalused, nende alternatiivkomponentide spetsifikatsioonid Sihtgrupp: Arhitekt, süsteemiadministraator, turvaspetsialist, äri, tellijapoolne projektijuht Ajakava: enne esimese arendusetapi algust enne igat arendusetapi algust igakordsel tellijale testimisse andmisel jah Üldised nõuded: Üleantav dokument peab sisaldama sisseviidud muudatusi nii, et on väljatoodud muutunud ja lisandunud osa (võrreldes viimati üleantuga).  RAAMLEPING nr 5-6/25-212-1 Riigi Info- ja Kommunikatsioonitehnoloogia Keskus, (edaspidi Tellija) registrikood 77001613, aadress Lõõtsa 8a, Tallinn 11415, mida esindab direktor Ergo Tars, ja HEISI IT OÜ (edaspidi Täitja), registrikood 12765966, asukohaga Pärnu mnt 105, Tallinn 11312, mida esindab juhatuse liige Talvi Pihl sõlmisid käesoleva raamlepingu (edaspidi „Leping”) ja leppisid kokku alljärgnevas: 1. Lepingus kasutatavad mõisted 1.1. Suure algustähega mõisteid tuleb Lepingus tõlgendada nii, nagu need allpool on määratletud. Kui ei ole teisiti sätestatud, siis viitab mõiste ainsuse vorm ka selle mitmusele. Kahtluse korral tuleb väljendeid, millel võib olla rohkem kui üks tähendus, mõista viisil, mis sobib kõige rohkem Lepingu olemuse ja eesmärkidega. 1.2. Akt - dokument, mille allkirjastamisega Täitja annab tehtud Tööd üle ja Tellija võtab need vastu; 1.3. Intellektuaalse omandi õigused – intellektuaalse omandi õiguste käsitlemisel lähtutakse autoriõiguse seadusest; 1.4. Kodukord – Lepingu alusel teostavate tegevuste, nende tegevuste teostamise eest vastutajate, tegevuste tulemusel valmivate tulemite, samuti tulemite valmimise eelduseks oleva Täitja ja Tellija omavahelise suhtluse ning tagasiside edastamise kord. Kodukord on Lepingu lisaks; 1.5. Leping – Leping koos lisadega. Lepingu eesmärgiks on fikseerida Tööde edukaks tegemiseks vajalike kokkulepete raamistik; 1.6. Kolmas isik – iga isik, kes ei ole lepingu pool; 1.7. Pool – sõltuvalt Lepingu kontekstist kas Tellija või Täitja või mõlemad koos; 1.8. Tarkvara – kõik Lepingu täitmiseks rakendatavate tarkvarade komponendid kogumis, ka RIT portaal, infosüsteem või veebipõhine info- ja teenindusportaal. Tarkvara võib koosneda järgmistest komponentidest: a) Arendatav tarkvara – tarkvara, mis on loodud spetsiaalselt Tellija jaoks Tellija konkreetseid huve ja soove silmas pidades Lepingu alusel; b) Kommertstarkvara – tarkvara, mida kasutatakse Arendatava tarkvara funktsionaalsuse tagamiseks ning mis kuulub kas Täitjale või kolmandale isikule ning mille kasutusõigus antakse Täitja või kolmanda isiku poolt Tellijale litsentsi alusel; c) Tellija tarkvara – mistahes tarkvara, mis on Tellija poolt omandatud, loodud või temale litsentseeritud, v.a Arendatav tarkvara ja Kommertstarkvara; d) Täitja tarkvara – tarkvara, mis on Täitja poolt omandatud, loodud või temale litsentseeritud enne Lepingu sõlmimist; e) Vabavaraline tarkvara – tarkvara, mida kasutatakse Arendatava tarkvara funktsionaalsuse tagamiseks, kuid mida ei ole arendanud Täitja, vaid mis kuulub kolmandale isikule ning mille kasutusõigus antakse kolmanda isiku poolt Tellijale tarkvara vaba kasutuse litsentsi alusel. 1.9. Tellija – Riigihanke korraldaja ja läbiviija isik, keda Lepingu dokumentides võidakse nimetada ka hankijaks; 1.10. Teostajad - Lepingu täitmiseks kasutatavad isikud, eelkõige Tellija või Täitja spetsialistid, sealhulgas töötajad, alltöövõtjad, Tellija järelevalve vmt; 1.11. Täitja – Riigihankes eduka pakkumuse teinud isik, kellega Tellija sõlmib Lepingu; 1.12. Töö – Täitja poolt täidetavad tarkvara arenduse, seadistamise, konsultatsiooni, koolitamise või muud Poolte vahel kokku lepitud ülesanded ja dokumenteerimine. Tööd jagunevad:  a) Garantiitööd – garantiiliste kohustuse täitmiseks tehtavad tööd; b) Arendustööd – arendusteenus, mida Täitja osutab uue infosüsteemi funktsionaalsuse loomiseks või tööde käigus loodud olemasoleva funktsionaalsuse muutmiseks, mis on eelnevalt Tellija ja Täitja vahel kokku lepitud ja tellimusega kinnitatud; c) Hooldustööd – hooldusteenus, mida Täitja osutab infosüsteemi omaduste säilitamiseks, parandamiseks või parendamiseks etteplaneeritavalt. Hooldustöö eesmärgiks on tagada infosüsteemi, millele hooldustööd osutatakse, toimimine. 1.13. Tööpäev – kalendripäevad esmaspäevast reedeni (kell 8:00-17:00), v.a riiklikud pühad; 1.14. Viga - tarkvaralahenduses esinev mittevastavus tellimusele. Vigade kriitilisuse astmed: a) Kriitiline astme Viga (P1) – Tarkvaral põhinev teenus/süsteem ei toimi. Andmed on rikutud. Tarkvara tekitab serveri ebanormaalset toimimist (mh luues ülemääraselt ajutisi faile, tekitades serveritele ebanormaalset koormust, mis tingib serveri töös tõrkeid või funktsioonide seiskumise). Tarkvara interpreteerib teistest süsteemidest ületulevaid andmeid või protsesse mittesoovitud viisil. Esineb tööde või kasutajasessioonide ebanormaalne katkemine. Probleem mõjutab süsteemi käideldavust ja andmete integreeritust. Mõjutatud on enamus Tarkvara kasutajatest. Ajutine lahendus probleemi vältimiseks praktiliselt puudub; b) Keskmine astme Viga (P2) – Tarkvaraga seotud igapäevaste või perioodiliste toimingute teostamine on osaliselt võimatu või nende tegevuste käigus on oht andmevigade tekkeks. Mõjutatud on osad Tarkvara kasutajatest. Tähtsad Tarkvara funktsioonid pole käideldavad, süsteem on ebastabiilne või on kiirus madalamal normaalsest koormuse nõudest. Ajutised lahendused pole efektiivsed. Taastamine on keeruline; c) Madal astme Viga (P3) – Tarkvaraga seotud vähemtähtsad funktsionaalsused ei toimi. Süsteem võimaldab tarkvara põhifunktsionaalsust kasutada. 2. Lepingu üldsätted 2.1. Leping sõlmitakse Tarkvara loomise ja pideva toimimise ning jätkusuutliku arendamise tagamiseks. 2.2. Lepingu eesmärgiks on sätestada Poolte õigused, kohustused ja vastutus Töö teostamisel käesoleva Lepingu ja selle alusel sõlmitud hankelepingute raames. 2.3. Lepingu täitmist võidakse rahastada Euroopa Liidu vahenditest. Juhul kui täitja kasutab EL ühtekuuluvus- ja siseturvalisuspoliitika fondide vahenditest rahastatava hankelepingu puhul alltöövõtjaid ning alltöövõtulepingu maksumus ületab 50 000 eurot käibemaksuta, siis peab täitja esitama andmed alltöövõtu kohta. Taaste- ja vastupidavuskava vahendite kasutamisel tuleb edukal pakkujal esitada pärast hankelepingu sõlmimist riigihangete registri lepingu töölehel „Alltöövõtjad“ kõigi hankelepingu täitmises osalenud alltöövõtjate kohta sõltumata riigihanke eeldatavast maksumusest ja alltöövõtulepingu maksumusest. Täitja sisestab jooksvalt alltöövõtjatega seotud info – alltöövõtja nimi ja registrikood, alltöövõtulepingu nimetus, kuupäev, number ja summa – riigihangete registrisse, kus hankelepinguga seotud andmete juures on olemas vastav vaheleht alltöövõtu jaoks. 2.4. Hanke dokumendid on Lepingu lahutamatuks osaks ning neid kasutatakse Lepingu tõlgendamiseks. Vastuolu korral lähtutakse dokumentidest nende prioriteetsuse järjekorras: 2.4.1. käesolev raamleping; 2.4.2. hankeleping; 2.4.3. tehniline kirjeldus koos lisadega; 2.4.4. muud hanke alusdokumendid; 2.4.5. Täitja riigihankes esitatud ja edukaks tunnistatud pakkumus. Lk 2/13 2.5. Hiljem tehtud muudatuste osas kehtib põhimõte, et ajaliselt hilisem muudatus prevaleerib ajaliselt varasema muudatuse üle. Kui vastuolu esineb sama pädevusjärjekorra dokumentide vahel, siis lähtutakse tõlgendamisel Lepingu eesmärgist ja mõistlikkuse põhimõttest. 2.6. Lepingu osaks on garantii teostatud Tööle ning teostatud Töö toimimisele olemasolevas süsteemis. Garantiiperiood on 12 kuud pärast Töö vastuvõtmist. 2.7. Lepingu tõlgendamisel lähtutakse Poolte ühisest tegelikust tahtest, isegi kui see erineb sõnade tavapärasest tähendusest. Kui Poolte ühist tegelikku tahet ei õnnestu kindlaks teha, tuleb Lepingut tõlgendada nii, nagu teise Poolega samasugune mõistlik isik pidi Lepingut samade asjaolude esinemise korral mõistma. 2.8. Pooled kohustuvad teist Poolt koheselt informeerima tehnilistest või organisatoorsetest piirangutest, mis võivad seada ohtu Lepingu eesmärkide saavutamise. 2.9. Lepingu allkirjastamisel on lepingu lisad järgmised: 2.9.1. Lisa 2 Tehniline kirjeldus; 2.9.2. Lisa 2.1 Mittefunktsionaalsed nõuded; 2.9.3. Lisa 2.2 Nõuded dokumentatsioonile; 2.9.4. Lisa 2.3 Esimese etapi arendustööd; 2.9.5. Lisa 2.4 RIT portaali visiooni kavand; 2.9.6. Lisa 3 Kodukord; 2.9.7. Lisa 4 Nõuded meeskonnale; 2.9.8. Lisa 5 Raamlepingu alusel sõlmitav hankeleping. 3. Lepingu ese 3.1. Lepingu esemeks on veebipõhise info- ja teenindusportaali arendamine, toimimine ja regulaarne hooldus. 3.2. Lepinguga kohustub Täitja teostama töid käesolevas Lepingus, selle lisadokumentides ja Lepingu alusel sõlmitud hankelepingutes kokkulepitud tingimustel ja korras. 3.3. Tellija ostab Täitjalt Töid 48 kuu jooksul lähtuvalt Tellija eelarvelistest vahenditest ja vajadustest tunnihinnaga 40,00 eurot, millele lisandub käibemaks. 3.4. Raamlepingu kogumaksumus on 500 000,00 (viissada tuhat) eurot, millele lisandub käibemaks. 3.5. Hankelepingute kehtivus ei ole piiratud raamlepingu kehtivuse lõpptähtpäevaga. 3.6. Tellija poolt sõlmitavate hankelepingute arv ei ole piiratud ja maht on piiratud raamlepingu kogumaksumusega. 3.7. Täitja tehtavad Tööd on määratletud Riigihanke alusdokumentides, sõlmitavates hankelepingutes ja muudes Lepingu lisades. Tööde täpsem sisu lepitakse kokku etapiviisiliselt ning dokumenteeritakse tellimuses (detailne ülesande püstitus, analüüs, kirjeldus). 3.8. Tellija eeldab, et Täitja on Lepingu esemeks olevate Tööde tarkvaraarenduse valdkonna professionaal, kes saab aru ning võtab teadlikult enda kanda Lepingust tuleneva koostoime, ristfunktsionaalsete nõuete täidetavuse ja tulemuse saavutatavuse riski. Seepärast laieneb Täitjale ka nende tööde tegemise kohustus, mida ei ole otsesõnu kokku lepitud, kuid mis oma olemusest lähtuvalt kuuluvad seotud Tööde hulka ja pidid olema ettenähtavad Täitjale kui professionaalile riigihankes pakkumuse esitamise etapis ning on vajalikud lõpptulemuse saavutamiseks. Viimati nimetatud tööde tegemine ei kuulu teistsuguse kirjaliku kokkuleppe puudumisel eraldi tasustamisele ning Täitja teostab need tööd Lepingu täitmise raames. Täiendava kokkuleppeta ei kuulu täitmisele uued funktsionaalsed või ristfunktsionaalsed nõuded, mida ei olnud nimetatud Riigihanke alusdokumentides. 3.9. Täitja tagab Tarkvara ühilduvuse Tellija toodangukeskkonnaga, sh Tellija tarkvaraga. 4. Poolte õigused ja kohustused Lk 3/13 4.1. Tellijal on õigus: 4.1.1. tellida Töid lähtuvalt vajadusest ja eelarvelistest vahenditest; 4.1.2. kontrollida Töö protsessi ning Täitja poolt lepingu tingimustest kinnipidamist; 4.1.3. kontrollida tehnoloogia valikuid, nõuda täiendavaid selgitusi ja põhjendusi valikute kohta, kaasata infosüsteemi auditeerimisse kolmandaid isikuid; 4.1.4. nõuda töötaja väljavahetamist, kui Tellija leiab, et töötaja ei ole piisavalt kompetentne, esitades selleks oma põhjendatud seisukoha. Vajadusel täidab töötaja selleks testülesande. 4.2. Tellija on kohustatud: 4.2.1. tasuma töö tegemise eest tähtaegselt; 4.2.2. teavitama Täitjat kõikidest Töö tegemise käigus avastatud puudustest; 4.2.3. teavitama Täitjat kõigist planeeritavatest ja/või teadaolevatest muudatustest, mis võivad oluliselt mõjutada Tööd; 4.2.4. tagama Täitjale tööks vajaliku informatsiooni kättesaadavuse. 4.3. Täitja on kohustatud: 4.3.1. tegema Tellija poolt soovitud Tööd vastavalt lepingu tingimustele ja Töö valdkonda reguleerivatele seadustele; 4.3.2. kõrvaldama operatiivselt Töö tegemisel ilmnenud takistused ja probleemid, mis alluvad Täitja kontrollile; 4.3.3. teatama Tellijale koheselt asjaoludest, mis võivad ohustada Töö tähtajaks valmimist või kvaliteeti; 4.3.4. kasutama Lepingu täitmisel riigihanke pakkumuses nimetatud Teostajaid või Tellija eelneval kirjalikul nõusolekul asendama nad Teostajatega, kes vastavad hankes nimetatud tingimustele; 4.3.5. informeerima Tellijat muutustest töötajate koosseisus, tagades uue töötaja samaväärse kompetentsuse ning kandes kõik tööga tutvumise ja sisseelamise kulud. 5. Garantii, vead ja sanktsioonid 5.1. Täitja annab Töödele garantii 12 kuud. Garantiiperiood hakkab kulgema Tellija poolt Tööde vastuvõtmise päevast. Kui Tööd võetakse vastu etapiviisiliselt, algab garantiiperiood viimase etapi vastuvõtmisest. 5.2. Täitja parandab ilmnenud vead ja puudused garantiiaja jooksul omal kulul, sealhulgas uuendab või asendab kõik seonduvad dokumendid, ja kannab uue versiooni paigaldusega seotud kulud. 5.3. Nõuded Toodangukeskkonnas avastatud Vigade reageerimisele ning lahendamisele on alljärgnevad: 5.3.1. Kriitiliste Vigade (P1) puhul tuleb Veale reageerida ja lahendada hiljemalt 3 Tööpäeva jooksul. Kui Vea kõrvaldamine 3 Tööpäeva jooksul ei õnnestu, kohustub Täitja esitama raporti Vea kõrvaldamisega seotud tegevuste kohta kuni Vea kõrvaldamiseni alates 4 (neljandast) Tööpäevast igal Tööpäeval; 5.3.2. Keskmise astme Vigade (P2) puhul tuleb Veale reageerida ja lahendada hiljemalt 10 Tööpäeva jooksul; 5.3.3. Madala astme Vigade (P3) puhul tuleb Veale reageerida ja lahendada Tellijaga kokkulepitud tähtajaks, kuid mitte hiljem kui 15 Tööpäeva Vea teavitusest. 5.4. Tellijal on õigus nõuda punktis 5.3.1, 5.3.2 ja 5.3.3 sätestatud tähtaja ületamisel igakordsel vea esinemisel ühekordset leppetrahvi 3 000 eurot. 5.5. Leppetrahvi tasumine ei välista Tellija õigust nõuda kohustuste täitmist. 5.6. Kokkulepitud Tööde rakendamise tähtaja ületamisel on Tellijal õigus rakendada leppetrahvi 0.15% päevas Töö maksumusest. Lk 4/13 5.7. Leppetrahvide rakendamise otsusest informeeritakse Täitjat otsuse tegemisele järgneval Tööpäeval e-posti teel Lepingus märgitud kontaktisiku poolt. 5.8. Garantiiga ei ole hõlmatud: 5.8.1. ekspluatatsioonihäirete kõrvaldamine, mis on põhjustatud Tellija või tema poolt kasutatava kolmanda isiku poolt juhuslikust või tahtlikust Tarkvara kahjustamisest või ebaõigest kasutamisest; 5.8.2. vead, mis on tingitud Tarkvara kasutamisest vastuolus Täitja koostatud ja Tellija poolt vastu võetud dokumentatsiooniga; 5.8.3. probleemid, mis tulenevad liidestatud süsteemide sisenditest, vaatamata sellele, et Täitja on nõuetekohaselt rakendanud sisendikontrolli; 5.8.4. seotud süsteemide liideste kooskõlastamata muudatusest tulenevad funktsionaalsed häired ja andmekvaliteedi probleemid; 5.8.5. diagnostikaks kulunud aeg, juhul kui algselt garantii juhtumina registreeritud juhtumi uurimise raames tuvastatakse, et tegu ei ole garantiilise juhtumiga. 5.9. Garantii kaotab kehtivuse, kui Täitjaga kooskõlastamata on muudetud või muudetakse lähtekoodi. Garantii ei kaota kehtivust, kui Tellija suudab eristada lähtekoodis tehtavad muudatusi. 5.10. Kui Viga ei kuulu garantii korras kõrvaldamisele, esitab Täitja Tellijale põhjendused kirjalikus vormis viivitamatult, kuid mitte hiljem, kui järgmisel Tööpäeval pärast sellest asjaolust teada saamist. 5.11. Garantii alla mittekuuluvate vigade korral rakendatakse punktis 5.3 sätestatud tähtaegu, kuid nende lahendamisega seotud kulud kannab Tellija. 5.12. Kui Poolte vahel tekib vaidlus Vea üle, on kummalgi Poolel õigus tellida sõltumatu ekspertiis, teavitades sellest eelnevalt teist Poolt. Pooled on kohustatud tagama eksperdi nõudmisel ligipääsu vajalikele andmetele või informatsioonile. Ekspertiisikulud kannab Pool, kes ekspertiisiakti kohaselt Vea garantiilisuse hindamisel eksis. 5.13. Tellija viib läbi turvatestimisi. Sama turvanõrkuse kordumisel mitmes erinevas turvatestis toimub selle parandamine Täitja poolt ilma lisakuludeta Tellijale. 6. Omandiõigused 6.1. Kui Töö sisaldab Täitja poolt Tellijale üle antavaid asju, siis läheb asja omandiõigus Täitjalt Tellijale üle vastavat asja sisaldava Töö vastuvõtmise või vastavalt Lepingule vastuvõetuks lugemise hetkest. 7. Autoriõigused 7.1. Lepingu alusel välja töötatud ja Tellijale üle antud Töö, selle üksikute osade ja kõigi muude Töö tulemite autori varalised õigused kuuluvad tervikuna Tellijale. 7.2. Töövõtja annab tellijale ainulitsentsi isiklike õiguste teostamiseks. Tellijal on õigus teostada Töös ja selle üksikutes osades muudatusi, kohandusi, töötlusi, kombineerida Töö teiste tarkvaradega ning saadud tarkvara kasutada ja levitada või teostada töö ja selle osade suhtes muid autori isiklikke ja varalisi õigusi. 7.3. Töö üleandmise- vastuvõtmise akti allkirjastamise järgselt lähevad töö ja selle andmekandjate omandiõigus ja kõik autori varalised õigused üle Tellijale. 7.4. Täitja kinnitab, et on sõlminud Tööd teostavate töötajatega lepingud, mille alusel enne Täitja lepingule alla kirjutamist on Töötajad loovutanud Täitjale kõik lepingu täitmisega seoses valmivatele tulemustele (k.a lõpule viimata Tööle) või nende osadele tekkivad autoriõigusega kaasnevad varalised õigused ning andnud ainulitsentsi isiklikele õigustele. Lk 5/13 7.5. Täitja kinnitab, et Lepinguga Tellijale üle antavad autoriõigusega kaasnevad varalised õigused ning ainulitsents isiklikele õigustele on Täitja poolt üle antavad ning et Täitja ei ole selliseid õigusi enne Tellijale üleandmist võõrandanud ega koormanud kolmandate isikute õigustega. 7.6. Täitja kinnitab, et annab Tellijale üle autoriõigusega kaasnevad varalised õigused ning ainulitsentsi isiklikele õigustele Töö tulemustele (sh kogu dokumentatsiooni) ning need kuuluvad Tellijale eeldusel, et Tellija on töö eest tasunud lepingus ettenähtud hinna. 7.7. Lepingu allkirjastamisega kinnitavad Pooled, et neile kuuluvad Lepingu täitmiseks vajalikud varalised autoriõigused, litsentsid ja muud intellektuaalse omandi õigused, mis on tarvilikud Lepingujärgse Töö täielikuks teostamiseks ja loovutamiseks käesolevas peatükis toodud ulatuses ning, et nende suhtes ei ole kolmandatel isikutel nõudeid. Pooled kinnitavad, et on võtnud tarvitusele kõik meetmed autori isiklike õiguste realiseerimiseks viisil, mis ei takista ega raskenda teose kasutamist ja autori varaliste õiguste teostamist. 7.8. Pool kohustub lahendama kõikvõimalikud litsentseeritud või vahendatud Tarkvaraga seotud Intellektuaalse omandi õigustest tekkivad vaidlused kolmandate isikute või oma töötajate või koostööpartneritega. Juhul kui Täitjapoolsetest litsentseerimisvigadest tulenevalt tekib Tellijale rahaline või muu kohustus või kui Tellija on kohustatud lõpetama Tarkvara kasutamise, on Tellijal õigus nõuda Täitjalt selle rahalise või muu kohustuse täitmist ja või kaotatud Tarkvaraga samaväärse tulemi loomist tasuta ja võimalikult lühikese aja jooksul, hoidudes mistahes viivitustest tulemi arendamises ja kasutuselevõtmises Tellija poolt. 7.9. Lepingu täitmisel Kommertstarkvara kasutamise osas juhinduvad Pooled nende kasutamise litsentsitingimustest. Täitja kinnitab, et eelistab tarkvara loomisel sellist Kommertstarkvara, mille kasutamine ei too Tellijale kaasa täiendavaid litsentsitasusid või piiranguid tarkvara kasutamisel. 7.10. Täitja võib kasutada tarkvara loomisel pakkumuses mittenimetatud Kommertstarkvara vaid Tellija eelneval kirjalikul nõusolekul. Kirjaliku nõusoleku taotlemisel on Täitja kohustatud esitama Tellijale litsentsi hinna, litsentsitingimused ja andmed lähtekoodi kättesaamise võimaluse kohta. 7.11. Tasu Intellektuaalse omandi õiguste Tellijale ülemineku ja litsentside eest sisaldub Lepingu maksumuses ning Täitjal ei ole õigust nõuda täiendavat tasu nende õiguste üleandmise ega litsentsimise eest (sh Lepingu sõlmimise ajal tundmatute kasutusviiside lubamise eest tulevikus). 8. Töö tellimine ja üleandmine-vastuvõtmine 8.1. Töö esimene tellimus esitatakse raamlepingu lisa 2 kohaselt. 8.2. Töö tellimus esitatakse või kinnitatakse Tellija esindaja poolt ja kinnitatakse Täitja esindaja poolt ning fikseeritakse tööde halduskeskkonnas (vt lisa 3). Tellimuse esitamist ja kinnitamist osapoolte esindajate poolt loetakse hankelepingu sõlmimiseks käesoleva lepingu kontekstis. 8.3. Alates 20 000 eurot (ilma käibemaksuta) maksvate Tööde tellimisel vormistatakse kirjalik hankeleping. 8.4. Tellija kontaktisik on Liisbeth Pakats, tel 5341 9535, e-post [email protected]; 8.5. Täitja kontaktisik on Talvi Pihl, tel 5669 7313, e-post [email protected]. 8.6. Tellija kontaktisikul on õigus tellida Tööd ja allkirjastada Tellija nimel vastavaid Akte. 8.7. Täitja kontaktisikul on õigus anda Tööd Tellijale üle ja allkirjastada Täitja nimel vastavaid Akte ning kohustus nõutada Tellija juhiseid ja informatsiooni Lepingu täitmise käigus tekkinud küsimuste ja probleemide lahendamiseks. 8.8. Täitja esitab eelmise kuu töötundide ajaaruande, mis sisaldab teostatud töötunde ja nende jooksul teostatud Töid. Ajaaruanne esitatakse hiljemalt järgmise kalendrikuu 5. tööpäeval või hankelepingus kokkulepitud arenduse etapi lõppemise järgse kalendrikuu 5. tööpäeval. Viimane ajaaruanne esitatakse koos Aktiga. Aktis peavad tehtud hooldus- ja arendustööd olema teineteisest eristatud. Lk 6/13 8.9. Tellijal on kümme tööpäeva aega kontrollida vastuvõtmiseks esitatud tööde lepingutingimustele vastavust ning Akti allkirjastamiseks. Tellija võib nimetatud tähtaega pikendada, kui pikendamine on põhjendatud. 8.10. Tellija võtab Tööd vastu Akti allkirjastamisega pärast tööde nõuetekohasuse kontrollimist ja edukat vastuvõtutestimist. 8.11. Tellija võib Tööd vastu võtta, kui Töödes esineb üksikuid ja tellija jaoks väheolulisi pisivigasid, mis fikseeritakse Aktis. 8.12. Tellija poolne pisivigadega Tööde vastuvõtmine ei vabasta täitjat kohustusest vead kõrvaldada ning üle anda vigadeta Tööd. 8.13. Tellija määrab mõistliku tähtaja pisivigade parandamiseks. 8.14. Tellijal on õigus keelduda Tööde vastuvõtmisest kui Tööd ei vasta esitatud nõuetele või Töödes esineb muid vigu. 8.15. Kui Tellija esitab vastuväited töödele, peab Täitja tööd parandama Tellija poolt määratud mõistliku tähtaja jooksul. Kui Täitja ei ole Tellija antud tähtaja jooksul kõrvaldanud avastatud vigu, võib Tellija Tööd ise parandada või lasta seda teha kolmandatel isikutel ja nõuda Täitjalt selleks tehtud mõistlike kulutuste hüvitamist. 8.16. Alates teisest kordustestimisest võib Tellija kordustestidega seotud kulutused (Tellija kulutatud tööaeg ja/ või Tellija testimispartnerite poolt esitatud arvete alusel) Täitjalt välja nõuda või tasaarvestada. 8.17. Garantiitööd fikseeritakse tööde halduskeskkonnas ja teostatakse lähtuvalt lepingu punktist 5. 8.18. Täitjal on õigus tõendada Tööde vastuvõtmisest keeldumise põhjuste ebaõigsust, nõudes selleks mõlemaid Pooli rahuldava sõltumatu ekspertiisi tegemist. Kui Tööde vastuvõtmisest keeldumine osutub ekspertiisi tulemusel põhjendamatuks, loetakse Tööd vastuvõetuks ning Tellija tasub Täitjale ekspertiisikulud, vastasel korral kannab ekspertiisikulud Täitja. 8.19. Tellijale tuleb üle anda ka Tööde juurde kuuluv või nendega seotud dokumentatsioon, tehes kõik dokumendid Tellija dokumendihalduskeskkonna kaudu Tellijale kättesaadavaks, järgides lisa 2.2 „Nõuded dokumentatsioonile“ toodud dokumentatsiooni koostamise ja esitamise nõudeid. 9. Arveldused 9.1. Lepingus fikseeritud tasu on Täitja ainus tasu seoses Lepinguga ning tasu võib muuta üksnes Poolte kirjaliku kokkuleppega õigusaktides lubatud juhtudel ja korras. 9.2. Töö eest tasumine toimub Tellija poolt allkirjastatud valminud ja üle antud Tarkvara üleandmise- vastuvõtmise aktide alusel pärast Täitja poolt masinloetava e-arve väljastamist. 9.3. Täitja poolt esitatud arve maksetähtaeg ei või olla lühem kui 30 päeva arve saamise kuupäevast arvates. 9.4. Arve loetakse tasutuks peale arvel näidatud summa ülekandmist Tellija poolt. 9.5. Kui Tellija ei tasu Täitja esitatud arveid õigeaegselt, on Täitjal õigus nõuda viivist 0,15% vastaval arvel märgitud tasumata summalt iga viivitatud kalendripäeva eest kuni arve täieliku tasumiseni, kuid mitte rohkem kui 50% vastava arve summast. Viivise maksmiseks kohustatud Tellija on kohustatud tasuma viivise 30 kalendripäeva jooksul arvates Täitjalt sellekohase nõude saamisest. 9.6. Lepingu alusel Poole tasutud mistahes maksega loetakse esmajärjekorras vastavas osas tasutuks Lepingu täitmisega (sh täitmisele pööramisega) seotud kulud (sh õigusabikulud), seejärel viivis ja leppetrahvid alates varaseimast võlgnevusest ning seejärel tasumata põhisumma alates varaseimast võlgnevusest. Seda nõuete rahuldamise järjekorda saab muuta ainult Poolte kirjaliku kokkuleppega. 10. Konfidentsiaalsus ja isikuandmete töötlemine Lk 7/13 10.1. Pooled tagavad käesoleva lepingu täitmise ja lepingust tulenevate kohustuste täitmise käigus teineteiselt ükskõik mis vormis saadud teabe (sh andmed, isikuandmed, spetsiifilise teadmise) konfidentsiaalsuse ja ei anna seda edasi ega võimalda sellele teabele juurdepääsu kolmandatele isikutele ilma teise poole sellekohase selgesõnalise kirjaliku nõusolekuta. 10.2. Andmete töötlemisel kolmanda isiku (edaspidi Alltöötleja) kasutamiseks peab volitatud töötleja esitama Tellijale kirjalikku taasesitamist võimaldavas vormis taotluse, milles toob ära selle kolmanda isiku nime, aadressi, kontaktisiku ja üksikasjaliku kirjelduse funktsioonidest, mille jaoks volitatud töötleja kavatseb Alltöötlejat rakendada. Tellija nõustumise korral peab Täitja Alltöötlejaga lepingu sõlmimisel kaasama sõlmitavasse alltöötlemise lepingusse käesolevas lepingus sisalduvatega samaväärsed tingimused. 10.3. Täitja vastutab kõigi Alltöötleja poolsete seaduste, eeskirjade või lepingu rikkumiste eest nii, nagu oleks selle rikkumise põhjustanud Täitja ise. 10.4. Täitja kohustub mitte edastama lepingu täitmise käigus ükskõik mis vormis saadud teavet (sh andmed, isikuandmed, spetsiifilise teadmise) ilma Tellija sellekohase selgesõnalise kirjaliku nõusolekuta. 10.5. Lepingu täitmise käigus Täitjale teatavaks saadud isikuandmed ei kuulu Tellija nõusolekuta protokollides ning loodavates dokumentides avaldamisele. 10.6. Täitja kohustub kasutama ja töötlema Tööde teostamise täitmise käigus Tellijalt ükskõik mis vormis saadud teavet (andmed, isikuandmed, spetsiifilise teadmise) üksnes Tööde teostamiseks 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. 10.7. Pooled võimaldavad juurdepääsu konfidentsiaalsele teabele (sh isikuandmetele) ainult nendele isikutele, kellel on selleks oma tööülesannete täitmiseks vajadus ning tagavad, et need isikud on teadlikud ja järgivad isikuandmete töötlemisalaseid nõudeid ja õigusakte, nad on saanud asjakohase koolituse eelnimetatud nõuete kohta, on võtnud endale konfidentsiaalsuskohustuse või neile kehtib asjakohane seadusest tulenev konfidentsiaalsuskohustus. Konfidentsiaalsus- kohustuse nõue on tähtajatu ning kehtib nii raamlepingu kehtivuse ja Tööde teostamise ajal, kui ka pärast Tööde teostamise ja raamlepingu lõppemist. 10.8. Pooled täidavad kõiki kehtivaid isikuandmete töötlemisalaseid nõudeid, andmete turvalisust puudutavaid ning isikuandmete kaitse alaseid Euroopa Liidu ja Eesti Vabariigi õigusakte ja eeskirju. 10.9. Täitja ei tohi edastada andmeid kolmandasse riiki (väljapoole EL-i/EMÜ-d) ega rahvusvahelisele organisatsioonile, kui seda ei nõua EL-i või selle liikmesriigi õigus, mis Täitjale kohaldub. 10.10. Täitja kohustub rakendama organisatsioonilisi, füüsilisi ja infotehnilisi turvameetmeid punktis 10.1 nimetatud teabe, sh isikuandmete, kaitseks juhusliku või tahtliku volitamata muutmise; juhusliku hävimise ja tahtliku hävitamise eest ning õigustatud isikule andmete kättesaadavuse takistamise eest, volitamata töötlemise, sh. avalikustamise eest. Kasutatavad turvameetmed peavad vastama vähemalt Eesti infoturbestandardi (E-ITS) tasemele "VS" ehk väga suur. 10.11. Täitja kohustub viivitamatult (hiljemalt 24 tunni jooksul teadasaamisest) kirjalikku taasesitamist võimaldavas vormis teavitama Tellijat toimunud või põhjendatult kahtlustatavast käesolevas kokkuleppes sätestatud konfidentsiaalsuskohustuse rikkumisest; punktis 10.10 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, kirjalikku taasesitamist võimaldavas vormis ilma põhjendamatu viivituseta. Teates tuleb vähemalt: Lk 8/13  10.11.1. kirjeldada (isikuandmetega seotud) rikkumise laadi, sealhulgas puudutatud andmesubjektide liike ja arvu ning puudutatud kirjete liike ja arvu; 10.11.2. teatada andmekaitse töötaja ja tema kontaktandmed või muu kontaktpunkt, kust saab lisateavet; 10.11.3. soovitada meetmeid (isikuandmetega seotud) rikkumise võimalike negatiivsete mõjude leevendamiseks; 10.11.4. kirjeldada (isikuandmetega seotud) rikkumise tõttu andmesubjektidele tekkivaid tagajärgi ja potentsiaalseid ohte; 10.11.5. kirjeldada Täitja või kolmandast isikust alltöötleja poolt välja pakutud või võetud meetmeid (isikuandmetega seotud) rikkumisega tegelemiseks ja 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. 10.12. Täitja kohustub Tellija nõudmisel lõpetama käesoleva lepingu punktis 10.11 nimetatud rikkumise ning kohaldama isikuandmetega seotud meetmeid rikkumise lahendamiseks, sealhulgas vajaduse korral rikkumise võimaliku kahjuliku mõju kõrvaldamiseks ja leevendamiseks. 10.13. Täitja kohustub Töö teostamise lõppemisel kustutama kõik talle Töö teostamise käigus teatavaks saanud isikuandmed ja nimetatute koopiad 90 kalendripäeva jooksul, v.a juhul, kui õigusaktidest tuleneb teisiti. 10.14. Täitja kohustub Tellijale tegema kättesaadavaks kogu teabe, mis on mõistlikult vajalik ja õigusaktidest tulenevalt kohustuslik käesolevas punktis sätestatud kohustuste täitmise tõendamiseks. 10.15. Täitja kohustub abistama võimaluse piires asjakohaste tehniliste ja korralduslike meetmete abil Tellijat täita Täitja kohustust vastata taotlustele andmesubjekti õiguste teostamiseks ning teostada nende õiguste teostamisest tulenevaid toiminguid (andmete parandamine, sulgemine, kustutamine). 10.16. Käesoleva kokkuleppe punktis 10.1 sätestatud konfidentsiaalsuse nõue ei laiene informatsiooni avaldamisele Täitja audiitorile ja advokaadile. Enne teabe avaldamist on pool kohustatud teist poolt avaldamise kavatsusest teavitama. 10.17. Tulenevalt konfidentsiaalse informatsiooni laadist on Tellijal õigus seada täiendavaid nõuded ja/või juhised isikuandmete töötlemiseks. 10.18. Kõik eelnimetatud kohustused kehtestab Täitja kõikidele kolmandatele isikutele, keda ta kasutab oma lepingujärgsete kohustuste täitmisel. Kolmas isik on iga füüsiline või juriidiline isik või riigi- või kohaliku omavalitsuse asutus, kes ei ole Tellija ega Täitja. 11. Vastutus 11.1. Pool vastutab Lepingulise avalduse, kinnituse ja/või kohustuse rikkumise eest vastavalt Lepingule ja õigusaktides sätestatule. Pool vastutab teise Poole ees ka Lepingu rikkumise eest, mis tuleneb Poole poolt Lepingu täitmisele kaasatud Teostajate tegevusest või tegevusetusest. 11.2. Pool ei vastuta Lepingu rikkumiste eest, mis tulenevad teise Poole Lepingu rikkumistest või kolmandate isikute tegevusest või tegemata jätmistest (näiteks ei valmi kolmanda isiku loodav liides tähtaegselt). 11.3. Poolte rahaline koguvastutus on piiratud Lepingu kogumaksumusega, kuid see piirang ei kehti tahtliku rikkumise korral. 11.4. Tellijal on õigus arvestada Tellija esitatud leppetrahvinõuete ja kahjuhüvitiste summad maha Täitjale tasumisele kuuluvast lepingutasust Täitjat sellest eelnevalt teavitades. 11.5. Oluliseks lepingurikkumiseks loetakse muu hulgas järgmisi rikkumisi: Lk 9/13  11.5.1. kui Pool ei täida mistahes Lepingust tulenevat kohustust teise Poole poolt Lepingust tuleneva vastava kohustuse täitmiseks antud täiendava mõistliku tähtaja jooksul; 11.5.2. Täitja ei täida garantiiperioodil Lepingust tulenevaid kohustusi; 11.5.3. kui Poolel või tema poolt kaasatud Teostajal puuduvad Lepingu täitmiseks vajalikud õigused (sealhulgas load, litsentsid, Intellektuaalse omandi õigused) ja Tellija on eeltoodud puudustele korrektselt viidanud; 11.5.4. Pool on rikkunud Intellektuaalse omandi õigusi ja nende kasutamise tingimusi; 11.5.5. Pool on rikkunud konfidentsiaalsuskohustust; 11.5.6. Tellija on viivituses Lepingus kokku lepitud maksetähtajaga rohkem kui kolmkümmend (30) kalendripäeva; 11.5.7. Täitja vahetab riigihanke pakkumuses nimetatud Teostajaid isikute vastu, kes ei vasta hankes kehtestatud tingimustele; 11.5.8. kui Täitja annab oma ettevõtte või selle osa koos Lepinguga üle Tellija eelneva kirjaliku nõusolekuta. 11.6. Täitja on vastutav dokumentaalselt tõestatud kahju eest, mis tekib Tellijale täitja poolt osutatud töö kasutamisest. 11.7. Kui üks Pooltest paneb toime olulise lepingurikkumise, on teisel Poolel õigus kasutada rikkuva Poole suhtes õiguskaitsevahendina omapoolsete kohustuste täitmisest keeldumise õigust kuni rikkuva Poole võlgnetavate kohustuste täitmiseni. Kahjustunud Pool on kohustatud teavitama Lepingu teist Poolt omapoolsete kohustuste täitmise peatamisest kirjalikus vormis. Kui Pool peatab oma Lepingust tulenevate kohustuste täitmise selle punkti alusel või muul põhjusel kui vääramatu jõu esinemise tõttu, pikeneb Lepingu täitmise tähtaeg kalendripäevade võrra, mille vältel oli Poole kohustuste täitmine nõuetekohaselt peatunud ning rikkunud Pool on kohustatud hüvitama teisele Poolele Töö peatamise ja taasalustamisega seoses tekkinud mõistlikud ja põhjendatud kulud. 12. Vääramatu jõud 12.1. Poole kohustuste mittetäitmist või mittenõuetekohast täitmist ei loeta rikkumiseks, kui selle põhjuseks oli vääramatu jõud. Vääramatu jõuna käsitavad Pooled võlaõigusseaduses nimetatud asjaolusid. 12.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. 12.3. Vääramatu jõu asjaolude ilmnemisel pikeneb Lepingu täitmise lõpptähtaeg nimetatud asjaolude esinemise perioodi võrra. Pool peab vääramatu jõu asjaolude ära langemisel asuma viivitamatult Lepingut täitma. 12.4. Vääramatu jõu asjaolu ei vabasta pooli kohustusest võtta tarvitusele kõik võimalikud abinõud lepingu mittetäitmisega või mittekohase täitmisega tekitatava kahju vältimiseks või vähendamiseks. 13. Lepingu kehtivus ja muutmine ja lõpetamine 13.1. Leping jõustub selle allakirjutamise hetkest ja on sõlmitud 48 kuuks. Lepingu alusel esitatavad tellimused ehk sõlmitud hankelepingud, ning ka eraldi dokumendina sõlmitud hankelepingud kehtivad kuni kõigi hankelepingutest tulenevate kohustuste täitmiseni mõlema poole poolt. 13.2. Leping lõpeb lepinguliste kohustuste täitmisega, Lepingu lõpetamise kokkuleppe sõlmimisega, Lepingus ettenähtud alusel või seadusest tuleneval alusel. 13.3. Kõik dokumendid, kokkulepped ning tulevikus poolte vahel käesoleva lepinguga seonduvalt sõlmitud täiendavad kokkulepped (kus viidatakse lepingule) sõlmitakse kirjalikult ja on lepingu lisad, mis moodustavad lepingu lahutamatu osa. Lk 10/13 13.4. Lepingut võib muuta poolte kirjalikul kokkuleppel, mis vormistatakse lepingu lisana. Lepingu muudatused ja täiendused jõustuvad nende allakirjutamise momendist poolte poolt. 13.5. Poolel on õigus Leping üles öelda ette teatamistähtaega järgimata ainult järgmistel asjaoludel, kui: 13.5.1. teine Pool on toime pannud olulise lepingurikkumise ega ole rikkumist heastanud 30 kalendripäeva jooksul kannatanud Poolelt vastava põhjendatud nõudesaamisest arvates; 13.5.2. teine Pool on näidanud üles kavatsust Lepingut oluliselt rikkuda ega ole Lepingu täitmist taganud 14 kalendripäeva jooksul kannatanud Poolelt vastava nõude saamisest arvates; 13.5.3. vääramatu jõu asjaolude tõttu on Poole Lepingust tulenevate kohustuste täitmine takistatud enam kui 2 kuu jooksul. 13.6. Tellijal on õigus Leping üles öelda: 13.6.1. 90-päevase ette teatamistähtajaga igal ajal sõltumata põhjusest; 13.6.2. ette teatamistähtaega järgimata, kui Täitja: 13.6.2.1. suhtes on algatatud pankrotimenetlus; 13.6.2.2. pankrot on välja kuulutatud; 13.6.2.3. Täitja varad arestitakse; või 13.6.2.4. Täitja finantsseisund halveneb Tellija põhjendatud hinnangul oluliselt ja see halvenemine muudab vähetõenäoliseks Lepingu nõuetekohase täitmise. 13.6.2.5. Täitja viivitab oma lepinguliste kohustuste täitmisega rohkem kui 30 päeva. 13.7. Sõltumata Lepingu lõpetamise alusest kohustub Tellija Lepingu lõppemisel tasuma Täitjale Lepingu lõppemise hetkeks faktiliselt teostatud ja tellimusele vastava Töö eest. Pooled teostavad kõik nõuete tasaarvestused 3 kuu jooksul Lepingu lõppemise kuupäevast arvates. 13.8. Peale lepingu lõppemist on Täitja kohustatud Tellijale üle andma kogu tema valduses oleva Tarkvara dokumentatsiooni, koodi, andmebaasi ja Täitja tööhalduskeskkonnas olevate Tööde kirjelduste detailse väljavõtte. Peale seda on Täitja kohustatud hävitama kogu tema valduses oleva Tarkvara puudutava informatsiooni. 14. Nõuete ja kohustuste üleminek 14.1. Lepingu või selles kokku lepitud õiguste ja kohustuste kolmandale isikule üleandmine saab toimuda ettevõtte üleandmise tulemusena, kuid see eeldab Tellija eelnevat kirjalikku nõusolekut. Tellija annab selles punktis nimetatud kirjaliku nõusoleku juhul, kui Lepingu või ettevõtte omandajal on piisav ettevalmistus ja kogemus, mis tagab Lepingu eesmärgi saavutamise ja Lepingu tingimuste vähemalt samaväärse täitmise. 15. Vaidluste lahendamine 15.1. Lepingu täitmisel ja tõlgendamisel lähtuvad Pooled kõikidel juhtudel Lepingust, selle lisadest ja Eesti Vabariigi õigusaktidest. 15.2. Lepingus reguleerimata küsimustes kohaldatakse Tööle töövõtulepingu sätteid. 15.3. Lepingu täitmisel tekkinud vaidlusküsimused lahendatakse läbirääkimiste teel. Kokkuleppe mittesaavutamisel lahendatakse vaidlus vastavalt õigusaktidega kehtestatud korrale. 16. Poolte vahelised teated ja kontaktisikud 16.1. Lepinguga seotud informatsioonilise iseloomuga teated edastatakse poolte vahel elektronposti teel või lepingu lisades sätestatud tööde halduskeskkonna abil. Poolte vahelised lepingu muutmisega seotud teated peavad olema allkirjastatud, välja arvatud teisele poolele õiguslikke tagajärgi mittepõhjustavad teated. 16.2. Pooled kohustuvad teavitama teineteist liigse viivituseta kontaktisikute (p 8) ja/või kontaktandmete muutumisest. Lk 11/13 17. Lõppsätted 17.1. Pooled kinnitavad, et: 17.1.1. Lepingu sõlmimisega ei ole nad rikkunud ühtegi enda suhtes kehtiva seaduse, põhikirja või muu normatiivakti sätet ega ühtki endale varem sõlmitud lepingute ja kokkulepetega võetud kohustust; 17.1.2. neil on õigus- ja teovõime Lepingu sõlmimiseks ning Lepingust tulenevate kohustuste täitmiseks ja õiguste realiseerimiseks; 17.1.3. nende poolt Lepingule ja selle lisadele allakirjutanud isikutele on antud piisavad volitused Lepingu sõlmimiseks kooskõlas seaduste, põhikirjade või muude õigusaktidega. 17.2. Kui mõni Lepingu tingimus peaks osutuma osaliselt või täielikult kehtetuks või täitmisele mittepööratavaks, ei mõjuta see teiste Lepingu tingimuste kehtivust ning Lepingu ülejäänud tingimused jäävad kehtima ja täitmisele pööratavaks. Sel juhul asendatakse kehtetu või täitmisele mittepööratav tingimus õiguslikult kehtiva tingimusega, mis on sisult võimalikult lähedane Poolte kavatsustele ja kehtetu tingimuse majanduslikule mõjule. Poolte esindajate allkirjad: Tellija Täitja (allkirjastatud digitaalselt) (allkirjastatud digitaalselt) Ergo Tars Talvi Pihl direktor juhatuse liige Lk 12/13  Lisa 2 Riigihange „Veebipõhise info- ja teenindusportaali arendus- ja hooldustööd“ (290452) Lisa 2 - Tehniline kirjeldus 1. Hanke üldinfo 1.1. Riigihanke nimetus on „Veebipõhise info- ja teenindusportaali arendus- ja hooldustööd“ (viitenumber 290452). 1.2. Hankijaks on Riigi Info- ja Kommunikatsioonitehnoloogia Keskus (edaspidi Riigi IT Keskus või RIT). 1.3. Riigihanke eesmärk on sõlmida raamleping veebipõhise info- ja teenindusportaali (edaspidi RIT portaal või infosüsteem) arendus- ja hooldustööde teostamiseks. Raamlepingu esemeks on tagada RIT portaali arendamine, toimimine ja regulaarne hooldus. 2. Tehnilise kirjelduse lugemine 2.1. Iga viidet, mille hankija teeb käesolevas dokumendis mõnele riigihangete seaduse paragrahvi 88 lõikes 2 ja paragrahvi 89 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“. 2.2. 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. Hetkeolukorra ja vajaduse kirjeldus Riigi IT Keskus pakub avalikule sektorile arvutitöökoha-, serveri alustaristu teenuseid ja mitmeid erilahendusi. RIT pakub täna teenuseid enam kui 80 asutusele ja ligikaudu 9000 avaliku sektori kasutajale. Praegu puudub Riigi IT Keskuse kliendi (avaliku sektori asutus) ja kasutaja (riigitöötaja) vaatest terviklik ja kasutajasõbralik lahendus arvutitöökohaga seotud informatsiooni ja teenuste tarbimiseks. Oluline informatsioon on hajali, keskkondi on palju ning kasutaja jaoks olulised töövood osaliselt puuduvad. RIT portaali eesmärk on olla põhiline kontaktpunkt, mis võimaldab klientidel ja lõppkasutajatel juurdepääsu Riigi IT Keskuse teenustele ja seotud teabele. RIT portaal koondab hajali paikneva RITi teenustega seotud informatsiooni, pakkudes struktureeritud ja selget ülevaadet kasutaja jaoks olulistest andmetest. RIT portaal saab olema integreeritud mitmete infosüsteemidega, et kuvada ülevaatlikult ja ajakohaselt informatsiooni ning võimaldada kasutajatel teostada toiminguid läbi ühtse kasutajaliidese. RIT portaal tagab ühetaolise ja sujuva kasutajakogemuse, parandab infokorraldust ning tõstab teenuste kättesaadavust ja kvaliteeti. RIT portaali vajaduste kaardistamiseks on varasemalt läbi viidud kasutajakogemuse ja -liidese disain ja analüüs ning loodud esmased disainivaated ja prototüübid. Need on aluseks antud hanke eseme tellimisel, kuid ei ole lõplikud ning pakkuja peab olema valmis vastavalt hankija tellimusele tegema täiendavaid vaateid ja muudatusi olemasolevates disainivaadetes. 3.1. RIT portaali kasutajad RIT portaal saab olema suunatud peamiselt kahele erinevale profiilile: RITi teenuste lõppkasutajad ja RITi klientasutuse esindajad. RITi teenuste lõppkasutaja on avaliku sektori töötaja, kes töötab asutuses, mis on RITi arvutitöökohateenusega liitunud. 2025. aasta alguse seisuga teenindab RIT ligikaudu 9000 lõppkasutajat ning lähiaastatel on ennustatav kasutajate arvu kasv üle 27 000. Lõppkasutajate esmaseks kontaktpunktiks RITis on täna IT-abi, kas läbi kirjalike pöördumiste või telefoni teel. Lõppkasutaja huvi on, et ta enda arvutitöökoha muredele, tellimustele ja päringutele võimalikult kiirelt ja lihtsalt lahenduse leiaks ning ei kulutaks aega erinevate keskkondade ja teadmusbaaside vahel liikumisele. Klientasutuse esindaja on avaliku sektori töötaja, kes töötab asutuses, mis on RITi arvutitöökohateenusega liitunud ning esindab avaliku sektori asutust RITiga suhtlusel. Klientasutuse esindajaid on üldjuhul sama palju kui arvutitöökohateenusega liitunud asutusi, ehk 2025. aasta alguse seisuga ligikaudu 80. Lähiaastatel on eeldatav klientasutuse arv üle 125, mis tähendab ka esindajate arvu kasvu. Klientasutuse esindajatega hoiavad regulaarset suhtlust RITi kliendisuhete juhid. Klientasutuse esindaja huvi on saada ülevaade enda esindatavast asutuseülesest teabest seoses RITiga (nt varade, pöördumiste, kasutajate, meiligruppide jne ülevaade), lisaks näha ülevaated kokkulepetest RITiga (nt sõlmitud lepingud, tellitud teenused, eelarve täituvus jne). 4. Hanke eseme kirjeldus Hanke esemeks on hankija vajadustele vastava RIT portaali arendus- ja hooldustööd. Arendustööna käsitletakse arendusteenust, mida pakkuja osutab uue funktsionaalsuse loomiseks või tööde käigus loodud olemasoleva funktsionaalsuse muutmiseks, mis on eelnevalt hankija ja pakkuja vahel kokku lepitud ja tellimusega kinnitatud. Hooldustöö all mõistetakse teenust, mida pakkuja osutab infosüsteemi omaduste säilitamiseks, parandamiseks või parendamiseks etteplaneeritavalt. Hooldustöö eesmärgiks on tagada infosüsteemi, millele hooldustööd osutatakse, toimimine. Pakkuja kohustus on teha järgnevad tööd: 4.1. Hankija poolt esitatud (või edasise arendamise käigus esitatava) lähteülesande täiendav analüüsimine ja vastava lahenduse disainimine (tarkvaraarhitektuuri loomine ja oodatava kasutajakogemuse ja -liidese kontseptsiooni väljapakkumine). 4.2. Disainitud lahenduste arendustööd. 4.3. Infosüsteemi liidestamine hankija teiste infosüsteemidega. 4.4. Ühekordsed täiendavad loodava infosüsteemiga seotud arendustööd hankija tellimisel. 4.5. Hooldustööd, milleks on hankija poolt teenuse saamiseks esitatud ja pakkujale laekunud pöördumine või pakkuja poolt registreeritud juhtum, mille käigus kõrvaldatakse viga, tõrge või arendatakse uus infosüsteemi funktsionaalsus. Lk 2/8  4.6. Ettepanekute tegemine komponentide uuendamiseks vastavalt tootja väljalastud uuenduste ilmumisele ja infosüsteemi iseärasustele. Pakkuja pädevus on erinevate komponentide koosmõjust tingitud rikete ja tõrgete vältimine. Vajadusel teostab pakkuja arendustöid, mis on tingitud tootjate poolt väljastatud uuendustest. 4.7. Infosüsteemi ja selle arendustööde dokumenteerimine ning dokumentatsiooni kaasajastamine. 4.8. Hankija nõustamine ja koolitamine infosüsteemi kasutamisel ja arendamisel. 4.9. Infosüsteemis esinevate tõrgete ja probleemide põhjuste väljaselgitamine ja nende kõrvaldamine. 4.10. Infosüsteemi tehniline administreerimistugi lepinguperioodil koostöös RITi IT spetsialistidega. 4.11. Muud infosüsteemi loomiseks, kasutuselevõtmiseks, hooldamiseks ja arendamiseks vajalikud tööd. 5. Nõuded arendustöödele, lähtekoodile ja kasutatavad tehnoloogiad 5.1. Arendustöid teostatakse vastavalt lisas 3 kirjeldatud Kodukorrale. 5.2. Kõik infosüsteemi arendustööde raames loodud tulemid peavad olema testitud etteantud funktsionaalsuste täitmise kinnitamiseks ja kooskõlastatud RITi poolse kontaktisikuga. 5.3. Tellimuse aluseks on kirjalik pöördumine tööde teostamiseks, kas tellimuskirjana või tööde halduskeskkonna (Jira) kaudu. Tellimusi esitab RITi poolne kontaktisik. 5.4. Arendused on loodud viisil, mis ei sunni hankijat hankima täiendavat tarkvara või selle kasutusõigust, on platvormisõltumatud ning vabavaralised. 5.5. Pakutava lahenduse puhul peab olema võimalik kuluefektiivselt kasutada automaatset skaleerimist nii horisontaalselt (uute ressursside lisamine) kui ka vertikaalselt (olemasolevate ressursside suurendamine) vastavalt kasutajate hulgale. 5.6. Infosüsteemi erinevaid komponente/mooduleid peab olema võimalik paralleelselt arendada ja vajadusel välja vahetada. 5.7. Uute moodulite lisamine peab olema võimalik ilma oluliste muudatuste vajaduseta juba kasutuses olevates moodulites. 5.8. Valmivad komponendid peavad olema taaskasutatavad. 5.9. Arendustöid teostatakse lähtuvalt tarkvaraarenduse standarditest, tunnustatud reeglitest ja headest tavadest. 5.10. Tööde käigus loodud lähtekood peab olema kirjutatud ja dokumenteeritud selliselt, et vajadusel oleks hankija või kolmas isik võimeline aru saama infosüsteemi loogilisest ülesehitusest ning jätkama lähtekoodi arendusega. 5.11. Tööde vastavust standarditele võivad hinnata vastava ala eksperdid. 5.12. Arendustöödel on kasutusel vähemalt järgmised keskkonnad (Tabel 1): Keskkond Funktsioon Kasutajad Haldaja Märkused Lk 3/8  Arendus- RIT portaali Pakkuja arendajad, pakkuja Hankija Majutatakse hankija keskkond arendamiseks testijad, vajadusel hankija süsteemides. kasutajad. Testkeskkond Hankijapoolne Hankija testijad, pakkuja Hankija Majutatakse hankija testimine, vastavalt vajadusele ja süsteemides. Pakkuja automaat-testimine, kokkulepetele poolsed tegevused liideste testimine tuleb registreerida tööde halduskeskkonnas. Toodangu- RIT portaali Lõppkasutajad ja Hankija Majutatakse hankija keskkond eesmärki täitev klientasutuse esindajad. süsteemides. igapäevane Reeglina arendaja ligipääs töökeskkond vajalik ei ole. Tabel 1. Ülevaade arendustöödel nõutud keskkondadest. 5.13. Test- ja toodangukeskkonda infosüsteemi uuenduse paigaldamiseks peab pakkuja seadistama vajalikud automaatsed paigalduse töövood, mille tingimused peavad olema hankijaga koostöös kokku lepitud. Töövoo esialgse seadistamise, muudatuste ja lepingu vältel käimas hoidmise eest vastutab pakkuja. 5.13.1. Pakkuja peab hankijale üle andma dokumentatsiooni loodud töövoogude kohta, mis on piisav selleks, et hankija saaks lepingu lõppedes halduse üle võtta. 5.14. Kogu teostatav töö ja üleantavad tulemid, versioonihaldus ja konfiguratsioonid, tuleb salvestada hankija poolt määratud versioonihalduse (Git) projektina. 5.15. Infosüsteemi paigaldus automatiseeritakse pakkuja ja hankija koostöös ja lahenduse arhitektuur kavandatakse selliselt, et see tagaks infosüsteemi tööaja 24/7. 5.16. Pakutav lahendus peab olema realiseeritud mikroteenustena ning kasutatav hankija Kubernetese konteinerplatvormil ja allolevast failisüsteemist sõltuvusi ei tohi olla, kõik failid tuleb salvestada S3-e. 5.17. Serveripoolne osa (back-end) peab olema teostatud kas Go Fiber raamistikus või kasutama Java Spring Boot koos JOOQ-ga. 5.18. Kasutajaliides (front-end) peab olema arendatud kas React või Angular raamistikus. 5.19. Andmebaasina tuleb kasutada hankija relatsioonilist andmebaasi PostgreSQL. 5.20. Püsiva integratsiooni töövood lahendatakse GitLab-i abil. 5.21. Autentimise mehhanismiks kasutatakse Entra ID tehnoloogiat. SSO ja kasutaja õiguste gruppide haldamise lahendusena kasutatakse KeyCloak-i. 5.22. Liidestuse ühe lahendusena kasutatakse OpenID Connect tehnoloogiat. 5.23. Mikroteenuste omavahelise suhtluse puhul tuleb kasutada asünkroonset liiklust ning arhitektuuri tuleb lisada ka sobiv MQ. 5.24. Rakenduste sõltuvuste (maven, npm jne) allikana tuleb kasutada hankija sisest keskset repositooriumi (Artifactory). Lk 4/8 5.25. Lähtekoodi kvaliteedist ja tehnoloogilisest võlast ülevaate saamiseks kasutatakse hankija platvormi SonarQube. Pakkujal on kohustus SonarQube-i poolt leitud lähtekoodi vead ja halvad lõhnad (code smells) enne tulemi/commiti üleandmist parandada. Kui selgub, et tulemi üleandmisel olid lähtekoodis vead ja halvad lõhnad parandamata, on hankijal õigus tulemit/commiti mitte vastu võtta. 5.26. Pakkujal lasub kohustus teha teiste arendajate tulemitele koodiülevaatust (Code Review) tagamaks lähtekoodi vastavuse koodistiili reeglitele. 5.27. Lähtekood peab olema pakkuja poolt piisavalt kommenteeritud, et hiljem oleks võimalik teha edasiarendusi või parandusi. 5.28. Arendustööde tulemusel valmiva lähtekoodi hoidmiseks on hankija Git koodirepositoorium (Gitlab). Pakkuja meeskonnaliikmetele luuakse hankija poolt ligipääs koodirepositooriumile lähtekoodi, andmebaasimuudatuste ning muude tulemite või nende muudatuste üleandmiseks. 5.29. Tarkvara järjepidevaks integreerimiseks ja tarnimiseks (Continuous Integration, Continuous Deployment CI/CD) kasutatakse Gitlab-i. 5.30. CI töövoogude loomine on arendaja ülesanne, sealhulgas järgida põhimõtet et konfiguratsioonid teostatakse läbi keskkonnamuutujate. 5.31. Loodavad hanke tulemid antakse üle hankija koodirepositooriumi kaudu vastavalt hankija juhistele. Arendustööde tulemite üleandmine (lähtekoodi tarne) toimub pideva integreerimise (CI) teel või kokkulepitud sagedusega (nt iga arendustööde sprindi/etapi järel). 5.32. Kõik välised sõltuvused tuleb rakenduse ehitamisprotsessi käigus läbi skaneerida hankija Artifactory Xray töövahendiga ja mitte kasutada kõrge ega ülikõrge kriitilisusega (CVE hinne 7.0 või kõrgem) turvanõrkuseid sisaldavaid teeke/komponente. 5.33. Arendamisel lisatakse commitide (lähtekoodi repositooriumisse lisamine) juurde Jira pileti nr, mille alusel muudatus sisse viiakse ning lühisõnaline lühikirjeldus, mida muudatused sisaldavad. Commit sõnumi alguses peab olema alati projekti nimi, mille raames commit tehakse ja informatsioon, kes antud commiti teeb (isiku nimi). 5.34. Enne commiti peab kood/teostatud töö/tulem olema: 5.34.1. iseendaga kooskõlas (pole vastuolusid, katkiseid mooduleid, iseendaga vastuolus funktsionaalsust); 5.34.2. üldharu/muu haru tulemiga kooskõlas (üldharus olemasolev pole peale commiti katki); 5.34.3. SonarQube-i poolt leitud lähtekoodi vead ja halvad lõhnad (code smells) parandatud (uut tehnoloogilist võlga tekitada ei tohi); 5.34.4. läbinud edukalt hankija kehtiva kvaliteedivärava (SonarQube-is Quality Gate); 5.34.5. selgelt mõistetav ja hõlpsasti kasutatav. Selle tagamiseks peavad olema olemas sisseehitatud testid, mis aitavad tuvastada, kas edasiste arenduste, commitide Lk 5/8  või muude tegevuste järel on vastav funktsionaalsus endiselt töökorras või vajab parandamist. 5.35. Tarnitav lepingu ese peab ühilduma hankija poolt nõutud tehnilise lahendusega (erisused on lubatud hankija kontaktisiku kirjalikku taasesitamist võimaldavas vormis esitatud nõusolekuga), sealhulgas: 5.35.1. järgima hankija poolt nõutud tehnilise lahenduse ideoloogiat süsteemsete protseduuride osas ja infosüsteemi arhitektuurset lahendust ja kasutusloogikat; 5.35.2. taaste- ja varundusprotseduurid peavad olema ühilduvad hankija poolt soovitud tehnilise lahendusega; 5.35.3. ei tohi põhjustada tööde käigus loodud olemasoleva infosüsteemi tervikluse või muid toimimise häireid ega jõudluse langust. 5.36. Tööde teostamine ei tohi tekitada häireid hankija mistahes teiste liidestatud süsteemide või teenuste talitluses, v.a juhul, kui see on hankija ja pakkuja poolt eelnevalt kokku lepitud. 5.37. Lepingu alusel teostatud tööde raames loodud tulemid peavad olema testitud etteantud funktsionaalsuste täitmise kinnitamiseks ja vastama hankes kehtestatud nõuetele. Pakkuja peab olema valmis looma integratsiooni ja unit teste vastavalt hankija nõuetele. 5.38. Pakkuja kohustub teostama koormusteste, et tagada infosüsteemi toimimine prognoositava kasutajate arvu kasvu piirides. Koormustestide käigus tuleb hinnata süsteemi jõudlust, töökindlust ja skaleeritavust, tagades, et see suudab toimida eeldatava kasutusmahu kasvades ilma märgatava jõudluse languseta. Testimise metoodika ja mõõdikud tuleb kooskõlastada hankijaga ning testitulemused esitada koos vastava aruandlusega. 5.39. Hankija jätab endale hankelepingu tingimuste piires õiguse ühepoolselt täiendada ja muuta üldist töökorraldust, sh arendusnõudeid, teavitades pakkujat kirjalikult ette 1 (üks) kuu. 6. Nõuded hooldusteenusele 6.1. Pakkuja pakub hankijale RIT portaali hooldusteenust, et tagada infosüsteemi töö. 6.2. Hooldusteenuse sisu: 6.2.1. Telefoni või elektroonilisel teel või vajadusel hankija juures kohapeal antavad konsultatsioonid infosüsteemi kasutamise ja toimimisega seotud küsimuste kohta. 6.2.2. Hoolduse käigus avastatud infosüsteemi vigadest teavitamine või arendust vajavate tööde puhul arendusettepanekute tegemine hankijale tööde halduskeskkonna kaudu. 6.2.3. Infosüsteemi uute versioonide tarnete koostamine, tarnete dokumenteerimine vastavalt tarneteatistele ja paigaldamine ning paigalduslogide koostamine. 6.2.4. Logide analüüsimine. 6.2.5. Infosüsteemi versiooniuuenduste, paranduste ja turvapaikade paigaldamine ja seadistamine ning vajadusel juhendite koostamine ja versiooniuuenduste dokumenteerimine paigalduslogis. Lk 6/8  6.2.6. Turvapaikade paigaldamine teostatakse mitte hiljem kui 1 (üks) nädal peale turvapaikade väljastamist tootja poolt; turvapaikade väljastamise teavet jälgib pakkuja. 6.2.7. Kõrge turvakriitilisusega vigade korral võib pakkuja ettepanekul katkestuste arv olla suurem kui 1 (üks) kord kuus. 6.2.8. Konfiguratsioonimuudatuste sisseviimine vastavalt hankija vajadustele. 6.2.9. Hooldustööde teostamiseks tagab pakkuja valmisoleku ja omapoolse abi kuni veaolukorra kõrvaldamiseni vastavalt rakenduse SLA eesmärkidele, vajadusel ka väljakutse korras kohapeal. 6.2.10. Hankija tagab hooldustööde teostamiseks ligipääsu vajalikele keskkondadele ja vajadusel omapoolse abi. Ligipääsu tehnilised tingimused jms täpsustatakse tööde teostamise käigus. 6.2.11. Pakkuja peab hooldustööde osas arvestust ja esitab hooldustööde kohta igakuiselt või kvartaalselt hooldusakti olenevalt kokkuleppest, mis sisaldab minimaalselt teostatud hooldustööde ning pakkuja poolt veaparanduse ja/või tellimuste alusel tehtud tööde (sh garantiiliste tööde) nimekirja (sh. tarneid ja vastuvõetud töid) ning teostatud tööde mahtu (töötunnid). 6.2.12. Tellimuskirjaga või Jira pileti alusel tellitud töödele tuleb esitada mahuhinnang. 7. Esimene tellimus 7.1. Lisas 2.3 on määratletud esimene arendustööde tellimus ning sealsete arendustööde teostamise maksumuse pakkumus on üks riigihanke hindamiskriteeriume. Pärast raamlepingu jõustumist sõlmitakse viivitamata hankeleping raamlepingu partneriga Lisa 2.3 alusel määratletud tööde teostamiseks (hankemenetluses esitatud pakkumus on siduv). 8. Lisad 8.1. Lisa 2.1 - Mittefunktsionaalsed nõuded 8.2. Lisa 2.2 - Nõuded dokumentatsioonile 8.3. Lisa 2.3 - Esimese etapi arendustööd 8.4. Lisa 2.4 - RIT portaali visiooni kavand Lk 7/8  Lisa 2.1 Riigihange „Veebipõhise info- ja teenindusportaali arendus- ja hooldustööd“ (290452) Lisa 2.1 Mittefunktsionaalsed nõuded Käesoleva riigihanke mittefunktsionaalsete nõuete koostamisel on võetud aluseks Tervise ja Heaolu Infosüsteemide Keskuse (edaspidi TEHIK) poolt välja töötatud mittefunktsionaalsete nõuete dokument ("TEHIK mittefunktsionaalsed nõuded arendustele", 2024), mis on lisatud hanke alusdokumentide hulka. Antud riigihanke mittefunktsionaalsed nõuded järgivad TEHIKu dokumendis väljatoodud, kuid teatud nõuded on kohandatud vastavalt hankeeseme spetsiifilistele vajadustele. Mittefunktsionaalsete nõuete vastuolu korral Lisas 2.1 „Mittefunktsionaalsed nõuded“ ja „TEHIK mittefunktsionaalsed nõuded arendustele“ lähtutakse Lisas 2.1 „Mittefunktsionaalsed nõuded“ esitatud nõuetest. 1. TEHIKu dokumendi kohandatud nõuded Järgnevas tabelis on välja toodud TEHIKu dokumendis kirjeldatud nõuded, mida on kohandatud antud riigihanke vajadustele vastavaks. Nõude TEHIK-u nõue Kohandatud nõue Kohandatud seletused nr 1.5 Rakendus peab olema Rakendus peab olema TEHIKu dokumendi kirjutatud kirjutatud arvestades selle selgitus pädeb arvestades selle lahenduse lahenduse äriprotsesside ja äriprotsesside andmete E-ITS väga suure ja andmete E-ITS ja ISKE kaitsetarbe või ISO/IEC turvaklassi 27001 nõudeid. nõudeid. 3.1 Asutusesiseseks Rakenduse kasutajate Kasutajate ja rollide kasutamiseks mõeldud autoriseerimist peab saama hoiustamiseks kasutatakse rakenduse kasutajate teha vastu RITi keskset hankija Keycloak teenust. autoriseerimist peab saama autoriseerimisteenust. Täpsem tehniline lahendus teha vastu TEHIKu keskset leida koos RITi poolse autoriseerimisteenust. arhitektiga. 3.4 Kui andmebaasis olevate Kui andmebaasis olevate TEHIKu dokumendi andmete E-ITS tervikluse andmete E-ITS tervikluse (I selgitus pädeb (I ehk integrity) ehk integrity) kaitsetarbe tase turvaosaklass on S või VS, on S või VS, siis tuleb kõik siis tuleb kõik andmebaasi andmebaasi kirjed/tabelid kirjed/tabelid versioneerida versioneerida. 6.3 Rakendus peab pakkuma Rakendusel peab olema Hankija annab ette täpse monitooringu lehte, kus masinloetav XML- kirjelduse. leidub informatsioon staatusleht, mille struktuur rakenduse funktsionaalsuse vastab hankija poolt ette toimimise kohta. antud XML struktuurile. 2. Kehtetuks tunnistatud nõuded Järgnevas tabelis on välja toodud TEHIKu mittefunktsionaalsete nõuete dokumendis sisalduvad nõuded, mis antud riigihanke kontekstis ei kehti. Nõude nr Nõude sisu 1.3 Lahendus peab vastama Sotsiaalministeeriumi IT-profiilile 1.8 Allkirjastamisel tuleb kasutada Tellija SiGA/SiVa vahendusteenust. 1.15 Avalike e-teenuste loomisel peab arvestama valitsusasutusele kehtestatud visuaalse identiteedi stiilijuhiseid. 1.16 Avalike e-teenuste loomisel peab arvestama Veera disainisüsteemiga. 1.19 Tegevusalade andmete sisestamisel, kuvamisel ja hoidmisel tuleb lähtuda Vabariigi Valitsuse 10. jaanuari 2008. a määrusest nr 11 "Klassifikaatorite süsteem" ja kasutada EMTAK infosüsteemis kehtivat klassifikaatorit. 3.10 Kasutaja peab saama soovi korral veenduda, kas keegi pole tema nime all vahepeal sisse loginud. 3.13 LDAP lahenduse (nt Active Directory) kasutamisel peab rakendus kasutama kontoga kaasnevaid piiranguparameetreid. 3.16 Kui rakenduse tervikluse turvaosaklass on T3, peavad tõestusväärtust omavad andmed olema kas ajatembeldatud, digiallkirjastatud või digitembeldatud ning krüptoaheldatud. 3.17 Kui rakenduses on S3 salastatuse astmega andmeid, peavad need olema nii transpordi ajal ja ka salvestatult alati krüpteeritult. 6.1 Rakendusel peab olema masinloetav tervise testleht (health check) JSON kujul. 6.2 Rakendusel peavad olema elususe ja tööks valmiduse otspunktid. 10.2 Lahendus kirjeldatakse RIHA määruse nõuete kohaselt. 3. Tehnoloogilise võla mõõtmine (SonarQube) Kogu tarnitav kood peab läbima standardse SONAR analüüsi. RITis kasutatavad kvaliteedimõõdikud ja nende lubatud väärtused:  Coverage - mõõdik määrab mitu protsenti kogu lahenduse lähtekoodist on kaetud automaattestidega. Alampiir on 75%;  Duplicated Lines (%) - mõõdik määrab mitu protsenti lähtekoodi koodist võib olla dubleeritud. Ülempiir on 3%;  Maintainability Rating - mõõdik määrab mitu protsenti kogu rakendusele kulunud ajast on tekitanud tehnilist võlga (Code Smell) koodi stiili ja standarditele vastavuse osas. Lubatud maht on alla 5%-i (tase A); Lk 2/3  Reliability Rating - mõõdik näitab palju on koodis erinevaid vigu. Uues ja refaktooritud koodis ei tohi olla ühtegi viga (tase A);  Security Rating - mõõdik näitab palju on turvanõrkuseid rakenduses, mis on SonarQube rakenduse poolt tuvastatud. Ei ole lubatud ühtegi turvanõrkust (tase A). Lk 3/3  Lisa 2.3 Riigihange „Veebipõhise info- ja teenindusportaali arendus- ja hooldustööd“ (290452) Lisa 2.3 - Esimese etapi arendustööd Hankija poolne ootus on, et esimese etapi arendustööd on lõpetatud ja tellija poolt vastu võetud hiljemalt kolm (3) kuud peale RIT portaali projekti käivitamist (kick-off koosolekust). Pärast raamlepingu jõustumist sõlmitakse viivitamata hankeleping raamlepingu partneriga esimese etapi arendustööde teostamiseks. Projekti kick-off koosolek peab aset leidma ühe (1) kuu jooksul alates hankelepingu sõlmimisest poolte kokkuleppel, võttes arvesse suvist puhkuste perioodi. Esimese etapi arendustööde loetelu: 1. RIT portaalile mikroteenustel põhineva platvormi disain ja loomine. 1.1. Infosüsteemi disainimisel ja loomisel lähtutakse mikroteenuste põhimõtetest: 1.1.1. iga teenus keskendub ühele äriprobleemile; 1.1.2. teenused on minimaalse omavahelise sõltuvusega; 1.1.3. komponendid on võimalikult sõltumatud ja iseseisvalt hallatavad; 1.1.4. komponente on võimalik eraldi sisse ja välja lülitada; 1.1.5. komponentidel on lokaalsed seadistusfailid, millega on võimalik komponendipõhist seadistust uuendada; 1.1.6. teenused on sõltumatult uuendatavad ja süsteemis rakendatavad; 1.1.7. teenused on kõrge käideldavusega ning lihtsasti testitavad. 1.2. Loodav lahendus peab olema konteineriseeritud ja allolevast failisüsteemist sõltuvusi ei tohi olla, kõik failid tuleb salvestada S3-e. 1.3. Infosüsteem peab olema skaleeritav nii horisontaalselt (uute ressursside lisamine) kui ka vertikaalselt (olemasolevate ressursside suurendamine). 1.4. Infosüsteem peab tagama kõrge töökindluse ja olema võimeline automaatselt taastuma tõrgete korral. 1.5. Infosüsteemil peab olema kasutajaliides, mis , mis võimaldab vähemalt järgnevaid toiminguid: 1.5.1. õiguste põhine alammoodulite ligipääs. 1.6. Infosüsteemil peab olema halduriliides, mis võimaldab vähemalt järgnevaid administratiivsed toiminguid: 1.6.1. kasutajate ülevaade; 1.6.2. kasutajate õiguste haldus, mis peab olema eraldiseisev mikroteenus, mille kaudu saab hankija Keycloakis hallata kasutaja õiguste gruppe, liidestus tuleb teha kasutades Keycloaki API-t; 1.6.3. kasutajate rollide õiguste haldus RIT portaali siseselt; 1.6.4. logi jälgimine; 1.6.5. süsteemiüleste teavituste loomist ja haldamist. 1.6.5.1. Teavitused peavad olema kasutajatele nähtavad RIT portaalis.  1.6.5.2. Teavituste kuvamine peab olema kohandatav vastavalt kasutaja rollile ja asutusele, et tagada asjakohasus ja relevantsus. 1.7. Kasutajate õiguste haldus peab olema paindlik ja võimaldama vajadusel integreerimist teiste süsteemidega, et tagada sujuv ja täpne kasutajate haldus. 1.8. Infosüsteem peab toetama kasutajate õiguste dünaamilist muutmist vastavalt vajadusele. 1.9. Infosüsteem peab toetama erinevaid kasutajarolle ja privileege, sealhulgas tavakasutaja, administraator ja klientasutuse esindaja. 1.10. Moodulite ligipääsu peab olema võimalik määrata õiguste kaudu vastavalt vajadusele. 2. RIT portaali integratsioon Confluence Cloud tarkvaraga, kus talletatakse RITi teenuste kasutajatele mõeldud juhised ja abimaterjalid. Liidestuse tulemusena kuvatakse kasutajale RIT portaalis teadmistebaas. Arendustööde aluseks on ideekavanditena valminud disainivaated ja prototüübid, mille eesmärk on anda visuaalne suunis ning toetada pakkujat üldise kontseptsiooni ja kasutajakogemuse mõistmisel. Disainivaated, mis käsitlevad teadmistebaasi integratsiooni asuvad Figmas ‘UI’ lehel, ‘Lõppkasutaja’ blokis ning vaadete pealkirjas on mainitud ‘Juhendid’. Disainivaated ei ole arendustele siduv lähteülesanne. Pakkuja peab olema valmis tegema täiendavaid vaateid ja muudatusi olemasolevates disainivaadetes vastavalt hankija tellimusele. Teadmistebaasi integratsiooni tulem: 2.1. Kasutajatele kuvatakse teadmistebaas, mis võtab oma andmete aluseks RITi poolt defineeritud Confluence Cloud lehed. 2.2. Teadmistebaasist tuleb läbi API liidestuse võtta kogu andmestik ning seda kuvada loodava RIT portaali kujundusele vastavalt. Kujunduses võib töö käigus tekkida lisavajadusi, mille tulemusena tuleb disainivaateid kohendada. 2.3. Teadmistebaasi sisu peab olema RIT portaalis struktureeritud vastavalt Confluence Cloud tarkvaras ettemääratud struktuurile, mis võib ajas muutuda. 2.4. Juhenditele ja abimaterjalidele tuleb määrata metaandmeteks asutuse info, mille järgi kuvatakse juhendid sisse logitud kasutajatele vastavalt nende asutustele. See info asub Confluence'i labelite all. 2.5. Kasutajal peab olema võimalus otsida teadmistebaasist juhendeid ja abimaterjale. 2.6. Otsingumootor peab võimaldama laiapõhist täistekstiotsingut. Otsing peab arvestama sisu konteksti ja relevantsust ning tooma esile täpsed tulemused vastavalt otsingupäringule. Sisu indekseerimine peab olema teostatud infosüsteemis. 2.7. Teadmistebaasi juhendid ja abimaterjalid peavad avanema RIT portaali samas veebilehitseja aknas. 2.8. Kasutajal on võimalik tegevusnupu „Teavita veast dokumendis“ abil alustada pöördumist, et teavitada juhendi täiendamise vajadusest. 2.9. Infosüsteem peab võimaldama hankijal paindlikult integreerida täiendavaid teadmistebaase ja liidestusi teiste süsteemidega, et tagada kasutajatele vajalik ja terviklik juurdepääs teabele. Lahendus ei tohi piirata võimalust uusi teadmistebaase lisada ega liidestusi tellida. Lk 2/3  2.10. Hankijal peab olema võimalik piirata ligipääsu erinevatele juhenditele ja abimaterjalidele samas teadmistebaasis. 2.11. Kasutajatele kuvatavas teadmistebaasis peab regulaarselt aset leidma automaatne sünkroniseerimine, et tagada teadmistebaasi ajakohasus ja täpsus. 2.12. RITi IT spetsialistil peab olema võimalik vajaduse korral üksikut sünkroniseeritud teadmistebaasi uuesti sünkroniseerida või seda süsteemist kustutada ja seejärel sünkroniseerimist käivitada. 2.13. Teadmistebaasi kasutuse kohta peab olema võimalik koguda statistikat ning seda peab olema võimalik RITi IT spetsialistil näha. Infosüsteemi kasutajaliideste loomisel on hankija eelistus taaskasutada TEHIKu disainisüsteemi (edaspidi TEDI) disaini- ja arenduskomponente (täpsem info https://tedi.tehik.ee/1ee8444b7/p/33df89-sissejuhatus). Selle eesmärgiks on nii disaini- ja arendusprotsessi lihtsustamine ja kiirendamine kui ka visuaalse ühtsuse suurendamine riiklikes digikeskkondades. Hankija ja pakkuja kokkleppel otsustatakse TEDI rakendamise ulatus RIT portaali kasutajaliideste arendamisel. Arendustööde teostamisel tuleb järgida tehnilises kirjelduses (Lisa 2) ja selle lisades seatud nõuded. Pakkuja poolt proovitöö ülesandes 1 (Lisa 6) esitatud arhitektuuri visioon ja ettepanekud kasutuselevõtuks tuleb võtta aluseks RIT portaali loomisel. Lk 3/3  Lisa 2.4 Riigihange „Veebipõhise info- ja teenindusportaali arendus- ja hooldustööd“ (290452) Lisa 2.4 - RIT portaali visiooni kavand Dokumendi eesmärk on pakkuda terviklikku ülevaadet RIT portaali pikaajalisest suunast ja soovitud funktsionaalsustest. Dokument kirjeldab prioriteetseid arendusvaldkondi ning tutvustab kasutuslugusid, mis toetavad sihtrühmade vajadusi ja ootusi. See on aluseks RIT portaali arenduste planeerimisele. RIT portaali eesmärgiks on olla põhiliseks kontaktpunktiks, mis võimaldab klientidel ja lõppkasutajatel juurdepääsu Riigi IT Keskuse teenustele ja seotud teabele. Eesmärgi saavutamiseks on vaja luua mikroteenustel põhinev, skaleeritav platvorm, mis kasutaja vaatest on ühtseks kontaktpunktiks ning taustal koondab ja vahetab informatsiooni erinevate infosüsteemidega. Portaal on suunatud peamiselt kahele erinevale profiilile, RITi arvutikohateenuse lõppkasutaja (riigitöötaja) ja klientasutus (avaliku sektori asutus), mistõttu peab portaalil olema ka erinevad vaated ja funktsionaalsused vastavalt profiilile. RIT portaali vajaduste kaardistamisel selgunud olulisemad funktsionaalsused on kuvatud Joonis 1 pildil. Joonis 1. RIT portaali soovitud funktsionaalsuste ülevaade lõppkasutaja ja klientasutuse vaatest. Näited potentsiaalsetest liidestustest RIT portaali platvormiga:  Keycloak  Confluence Cloud  Bürokratt  OpenText™ Service Management (SMAX)   VaRe – RITi varade halduse infosüsteem  Kasutaja- ja juurdepääsuhalduse (IAM) süsteem  Sympa – meililistide halduse tarkvara  Power BI – andmete visualiseerimise tarkvara Joonisel 1. olev funktsionaalsuste nimekiri on esialgne visioon ning nende reaalne tellimine sõltub tegelikust vajadustest, tööde tellimise ajal olevatest prioriteetidest, eelarve võimalustest jne. Funktsionaalsuste detailsemalt lahti mõtestamiseks ning arendustööde aluseks on kirjeldatud kasutuslood nii lõppkasutaja kui klientasutuse esindaja vaatest. Järgnev kasutuslugude nimekiri on näitlik, andmaks ülevaate võimalikest arendusvajadustest. Täpsed arendustellimused lepitakse kokku töö käigus vastavalt hankija vajadustele. 1.1. Kasutuslood lõppkasutaja vaatest: 1.1.1. Kasutaja soovib portaali ligi pääseda võimalikult lihtsalt läbi enda arvutitöökoha kasutades ühekordse sisselogimise autentimise süsteemi (SSO). Peale sisselogimist valib kasutaja rolli ja konto, millega soovitakse toiminguid teostada. Peale portaali sisenemist kuvatakse kasutajale lehe sisu. 1.1.1.1. Konto valik kuvatakse kasutajale juhul kui tal on mitu kontot. 1.1.1.2. Rolli valik kuvatakse kasutajale juhul kui talle on määratud mitu rolli (nt. tavakasutaja ja klientasutuse esindaja) 1.1.2. Kasutaja saab vaadata enda kontaktandmeid (amet, telefon, email, kontori asukoht, ruum). 1.1.3. Kasutaja saab vaadata enda meiligruppide infot (kuulun meiligruppi andmed, hallatavate meiligruppide andmed). 1.1.4. Kasutaja saab vaadata enda seadmete infot (arvuti ID, kasutajanimi, võrguliidesed, viimane sisselogimise kuupäev). Lisaks kuvatakse kasutajale tema kasutusel olevat vara (vara tüüp, vara liik, mudel, seeria nr, kasutuse lõpp) ning litsentse. 1.1.5. Kasutaja saab vaadata enda konto andmestikku (konto kasutusala, konto loomise kuupäev, konto kehtivusaeg, asutus, struktuuri üksus, otsene juht). 1.1.6. Kasutaja soovib vaadata temale suunatud teavitusi. Avalehel kasutaja nimega samal real kuvatakse teavitusi tähistav ikoon ning tekst teavitused. Avades akordioni kuvatakse kasutajale teavituste plokk, kus kuvatakse kõik asjakohased teavitused. Uued teavitused on tähistatud ning samuti on kuvatud uute sõnumite arv. 1.1.7. Kasutaja soovib otsida juhendit, mille sisu ta vaadata soovib. Kasutaja sisestab otsinguväljale märksõna. Süsteem kuvab automaatseid vasteid (autocomplete), lisaks on kuvatud tegevusnupp „Otsingu tulemused“. Otsitav märksõna on automaatsete vastete kuvamisel Lk 2/4  markeeritud värviga. Valiku tegemise järel teostab andmebaas filtreerimise valitud otsingukriteeriumite alusel ning kuvab kasutajale otsingutulemused. 1.1.8. Kasutaja soovib leida temale sobivat juhendit, selleks on tal võimalik valida meelepärane teema ning näha antud teema alamteemasid. Alamteemade sisu ehk juhendite loetelu kuvatakse kujul pealkiri ja lühikirjeldus. Vajutades konkreetsele juhendile, avaneb parempoolses ekraaniosas juhend. Kasutajal on võimalik tegevusnupu „Teavita veast dokumendis“ abil alustada pöördumist, et teavitada juhendi täiendamise vajadusest. 1.1.9. Kasutaja saab vaadata meiligruppide nimekirju, mis on jaotatud kahte tabelisse – hallatavad grupid ja grupid, milles ollakse liige. Iga meiligrupi kohta kuvatakse meiligrupi nimi, omanik, loomise kuupäev ja roll, avades akordioni kuvatakse veel täiendavalt meiligrupi meiliaadress, lühikirjeldus, viimati saadetud meili kuupäev, viimati vaadatud meili kuupäev ning kokku saadetud meilide arvu. Olles meiligrupi haldaja on võimalik antud akordionivaatest suunduda meiligruppi haldama. Meiligruppide nimekirjavaatelt on võimalik alustada uue meiligrupi loomist. 1.2. Kasutuslood klientasutuse esindaja vaatest: 1.2.1. Kasutaja soovib vahetada rolli, et näha enda esindatava asutuse andmeid. Rolli vahetamise alustamine on võimalik avalehel enda nime real olevalt ikoonilt või ekraani paremalt ülevalt nurgast enda nimele vajutades. Vajutades enda nimele, siis kuvatakse rollid, mille vahel on võimalik valida. Vajutades soovitud rollil vahetatakse kasutajal profiil. 1.2.2. Kasutaja saab vaadata enda asutuse kohta käivat varade infot. Esmalt kuvatakse kasutajale varade koondinfo – arvutite koguarv, kuvarite koguarv, printerite koguarv, videokonverentsi seadmete koguarv. Seejärel on kasutajal võimalik tutvuda detailsete varade tabelitega ehk vaadata kõiki varasid, ühisvarasid ja litsentse. Tabelist õige info leidmiseks on kasutajal võimalik kasutada filtreid, vaikimisi on kuvatud 3 olulisemat filtrit kuid tegevusnupp „Ava kõik filtrid“ esitab kõik filtrid. Peale nupule „Rakenda filtrid“ vajutamist teostab süsteem päringu ning kuvab kasutajale soovitud andmed. Tabelit on kasutajal võimalik alla laadida tegevusnupu „Laadi tabel alla“ abi. 1.2.3. Kasutaja saab vaadata enda asutuse kasutajate kohta käivat infot. Õige kasutaja leidmiseks on võimalik kasutada otsingut. Kasutajate info kuvatakse tabelis, kus iga kasutaja kohta kuvatakse tema nimi, vara tüüp, asutus, asukoht, ametikoht. Avades kasutaja rea (akordioni) on võimalik näha täiendavat infot- kasutaja õigusgrupid, meiligrupid ning tema kasutuses olevate varade infot tabelis. Tabelit on kasutajal võimalik alla laadida tegevusnupu „Laadi tabel alla“ abi. 1.2.4. Kasutaja soovib vaadata aktiivseid teenuseid ning samas on võimalik vaadata ka tellitavaid teenuseid. Teenuste kohta kuvatakse teenuse nimi, vastutaja, staatus, eeldatav rakendusaeg. Akordioni avades näeb täiendavalt teenuse kirjeldust ning aktiveerimise kuupäeva, samuti antud teenuse kohta käivaid juhendeid ning nende lühikirjeldust. Lk 3/4  Lisa 3 Riigihange „Veebipõhise info- ja teenindusportaali arendus- ja hooldustööd“ (290452) Lisa 3 - Kodukord 1. Eesmärk 1.1. Kodukorra eesmärgiks on selgelt välja tuua Lepingu alusel teostatavad tegevused, tegevuste teostamiste vastutajad, tegevuste tagajärjel valmivad tulemid, samuti tulemite valmimise eelduseks oleva Täitja ja Tellija omavahelise suhtluse ning tagasiside edastamise kord. 1.2. Antud dokumendis kasutatakse mõisteid vastavalt raamlepingus sätestatud tähendustele. 2. Suhtlemist ja Tööde elluviimist toetavad keskkonnad ja vahendid 2.1. Teated 2.1.1. Kõik ettepanekud, muudatused, nõuded, avaldused, nõusolekud jm Lepingust tulenevad õiguslikku tähendust omavad ametlikud teated tuleb esitada teisele Poolele vähemalt kirjalikku taasesitamist võimaldavas vormis (e-post, tööde halduskeskkond), kui Lepingus ei ole ette nähtud teisiti. 2.1.2. Teade loetakse kätte toimetatuks pärast seda, kui see on edastatud Lepingus toodud kontaktaadressile või aadressile, millest Pool on teist Poolt viimati teavitanud. 2.1.3. Teade loetakse teisele Poolele kätte toimetatuks vastuse või kättesaamist kinnitava teate saamisel saajalt, kuid mitte hiljem kui järgmisel tööpäeval pärast teate saatmist. 2.2. Suhtluskanalid 2.2.1. MS Teams – Arendusmeeskonna igapäevane suhtlusvahend, mida kasutatakse kiireloomuliseks ja operatiivseks suhtluseks. Teamsi või telefoni kaudu kokku lepitud otsused tuleb kinnituseks fikseerida kirjalikku taasesitamist võimaldavas vormis (nt e- kirjas, koosoleku protokollis, tööde halduskeskkonnas). 2.2.2. E-kiri – Arendusmeeskonna ametlik suhtluskanal, v.a kui infot tuleb vastavalt kodukorrale edastada tööde halduskeskkonna või dokumendihalduskeskkonna kaudu). Kui e-kirjale oodatakse vastust, tuleb see kirjas üheselt määratleda. Vastust eeldavale e-kirjale tuleb vastata hiljemalt järgneva tööpäeva jooksul. Kui e-kirjale ei ole võimalik anda selle aja jooksul sisulist vastust, tuleb hiljemalt järgneva tööpäeva jooksul saata sisulise vastuse andmise aeg. 2.2.3. Koosolek – Koosoleku kokkukutsumisel esitatakse koosoleku päevakord ja eesmärk. Korralised koosolekud võib poolte kokkuleppel tühistada (hiljemalt samal päeval 2-tunnise etteteatamise ajaga). Muude koosolekute kutsed tuleb esitada vähemalt 2 (kaks) tööpäeva enne koosoleku toimumist. Koosoleku korraldaja koostab koosoleku või muu kohtumise toimumise järel protokolli, kus protokollitakse vastu võetud otsused. Protokoll saadetakse e-kirjaga koosolekul osalenutele teadmiseks/vajadusel kinnitamiseks. 2.2.4. Telefon – Kasutatakse operatiivse ja olulise informatsiooni edastamiseks, samuti kriisisituatsioonides. Telefonikõnele mitte vastates tuleb tagasi helistada esimesel võimalusel, aga mitte hiljem kui järgmise tööpäeva lõpus. Olulistel juhtudel (näiteks arendustööde juurutusfaasis) peavad mõlema poole esindajad olema telefoni teel kättesaadavad ka pärast ametlikku tööpäeva lõppu. Valmisolek lepitakse eraldi kokku. 2.2.5. Pooled säilitavad Lepingu täitmisega seotud e-kirjad, Teamsi ja/või muudes sõnumivahetuskeskkondades toimunud vestlused Lepingu kehtivuse perioodil. 2.3. Tööde haldus ja dokumenteerimine 2.3.1. Kogu arendusprotsessi projektijuhtimine, tööde korraldamine, dokumenteerimine, tööülesannete määramine, vastuvõtmine ja teostamine ning suhtlus toimub Tellija määratud töö- ja koodihalduse keskkondades. Tellija tagab Täitjale vajaliku ligipääsu nendesse keskkondadesse Lepingu kestvuse perioodil. 2.3.2. Tööde halduskeskkonnaks on Tellija Atlassian JIRA Software, mida kasutatakse arendustööde ning vigade ja probleemide registreerimiseks tööülesannetena, nende hindamiseks ning tööülesannete täitmise jälgimiseks ja töötundide registreerimiseks. 2.3.3. Tööde halduskeskkonnas antud ülesandeid käsitletakse hankelepingutena. Alates 20 000 eurot (ilma käibemaksuta) maksvate Tööde tellimisel vormistatakse kirjalik hankeleping (raamlepingu lisa 5). 2.3.4. Tööde halduskeskkonnas fikseeritakse Töö kohta nimi, kirjeldus, maht tundides, teostamise logi, teostajad, prioriteetsus, lõpptähtaeg ning tööd kirjeldavad failid ja spetsifikatsioonid. 2.3.5. Enne Täitja poolt Töö mahule hinnangu andmist valmib detailne ülesande püstitus (analüüs või detailne kirjeldus). Ülesande püstituse vastavust soovidele kinnitab Tellija poolne kontaktisik. 2.3.6. Tellija annab mõistliku aja pakkumuse esitamiseks, arvestades tellitavate Tööde keerukust ja pakkumuse esitamiseks vajalikku aega. Pakkumuse esitamisel tuleb järgida kõiki tellimuses esitatud nõudeid. 2.3.7. Täitja hindab võimalusel tellimuse alusel Tööde mahtu ja esitab tellimuses määratud tähtajaks pakkumuse töö teostamiseks ja/või vajadusel muud tellimuses nõutud andmed. 2.3.8. Tööde halduskeskkonnas fikseeritud Töö maht peab sisaldama kogu selle Töö täitmiseks vajalikku kulu. 2.3.9. Kui pakkumus ei vasta tellimuse tingimustele või ei ole muul põhjusel vastuvõetav, lükkab Tellija pakkumuse tagasi. 2.3.10. Tellijal on õigus esitatud pakkumus tagasi lükata kui: 2.3.10.1. pakkumus ei vasta tingimustele; 2.3.10.2. tellija vajadus tellimuse täitmiseks kaob või muutub või; 2.3.10.3. ületab eeldatavat maksumust. Lk 2/4  2.3.11. Pooled võivad pidada tellimuse või pakkumuse muutmiseks või kohandamiseks läbirääkimisi, et muuta pakkumus tellimusele vastavaks või tellimuse tingimused pakkumusele sobivaks. 2.3.12. Iga Töö peab enne konkreetse Töö algust saama Tellijapoolse kontaktisiku heakskiidu. 2.3.13. Muutunud prioriteetide korral korrigeeritakse Tellija ja Täitja koostöös ajagraafikut. Täitja kaasab tööde teostamisse täiendavaid ressursse, kui tähtaegade korrigeerimine on võimatu. 2.3.14. Töö mahtu muutvate täiendavate nõuete ilmnemisel täpsustatakse tööde halduskeskkonnas Töö, sellega seonduvad dokumendid ning antakse Täitja poolt Tööle uus mahuhinnang. Enne Töö täitmise jätkamist peab Tellija poolne kontaktisik muudatused heaks kiitma. 2.3.15. Tööde halduskeskkonda, mida Täitja hoiab jooksvalt aktuaalsena, võivad Töid sisestada nii Täitja kui ka Tellija. 2.3.16. Dokumendihalduskeskkonnaks on Tellija Atlassian Confluence ning selle keskkonna kasutamine on Täitjale kohustuslik dokumentatsiooni koostamiseks, täiendamiseks, muutmiseks. Dokumenteerimine toimub vastavalt Tellija juhistele ja hanke Lisale 2.2 „Nõuded dokumentatsioonile“. Dokumentatsioon koostatakse eesti keeles, kui ei ole kokku lepitud teisiti. Täitja tagab koostatud teksti nii keelelise kui ka vormilise korrektsuse ning hea keelekasutuse. 3. Tööde teostamine 3.1. Tööde teostamise metoodika lepitakse kokku projekti esimesel kohtumisel poolte kokkuleppel. 3.2. Tellija eelistab kasutada arendusmetoodikat, kus arendustööd ja nende ülevaatamine toimuvad kahenädalaste tsüklitena. Selline lähenemine võimaldab arendustööd jagada osadeks ning fokusseerida kindlale lahenduse osale. 3.3. Vähemalt üks töökoosolek toimub igal nädalal, kus täitja tutvustab teostatud töid ja lepitakse kokku järgmise perioodi töödes. 3.4. Lõplikud töö tegemise põhimõtted fikseeritakse poolte kokkuleppel kirjalikult taasesitamist võimaldavas vormis dokumendihalduskeskkonnas, e-kirjas või eraldi dokumendiga. 3.5. Tööde teostamise töökeeleks on eesti keel. Täitja ning Tellija esindajad suhtlevad omavahel eesti keeles. Vajadusel tagab Täitja omal kulul alalise tõlke olemasolu suuliseks ja kirjalikuks suhtlemiseks vastava meeskonnaliikme ja Tellija vahel. Tõlk peab olema kompetentne tehnilise teksti tõlkimisel. 3.6. Täiendavad nõuded Tööde teostamisele (sh kasutatavad tehnoloogiad) on kirjeldatud Lisa 2 Tehnilises kirjelduses. Lk 3/4  Lisa 4 Riigihange „Veebipõhise info- ja teenindusportaali arendus- ja hooldustööd“ (290452) Lisa 4 - Nõuded pakkuja meeskonnale 1. Pakkuja peab esitama isikuliselt meeskonna liikmed (minimaalselt 5 liiget), kes täidavad järgmisi rolle: Isiku ees- ja perekonnanimi Isiku sünniaeg/isikukood Isiku roll lepingu täitmisel Projektijuht Tarkvaraarhitekt Analüütik Arendaja Arendaja Testija UX-UI disainer 2. Pakkuja meeskonnal peavad kogumis olema kaetud CV vormil (punktis 8.5.) märgitud kogemuse nõuded. Iga meeskonnaliige üksikult peab omama vähemalt ühte nõutud kogemust. 3. Üks isik võib täita maksimaalselt 2 (kahte) erinevat rolli, näiteks analüütik-testija, kuid sellisel juhul peab antud isik vastama punktis 2 esitatud nõuetele üksiku rolli täitmiseks ning peab olema tagatud meeskonna nõutav minimaalne suurus (5 liiget). 4. Pakkuja peab arvestama, et hankijal võib olla vajadus meeskonda suurendada, et riigihankes püstitatud eesmärgid täita. 5. Pakkumuses esitatud meeskonnaliikme saab lepingu käigus hankija eelneval nõusolekul vahetada uue meeskonnaliikme vastu kui pakkuja meeskond tervikuna katab CV vormil märgitud nõutud kogemused. Meeskonnaliikme asendamise taotluse esitamise ajaks peab isik nõutud tingimustele vastama. 6. Hankija küsib meeskonnaliikme sünniaega või isikukoodi, et tuvastada hiljem isikusamasus ning välistamaks nimekaimude segi ajamist. 7. Meeskonnaliikmete rollid ja vastutus 7.1. Projektijuht, kes koostab ja jälgib projektiplaani (sh ajakava, riskid), juhib projektimeeskonna igapäevatööd, korraldab tööde üleandmise ja arveldamise, planeerib tööde üleandmise hankijale ning veendub enne üleandmist nende vastavuses hankija soovidele. Samuti koordineerib teostatud töödele nõuetekohase dokumentatsiooni teostamise, korraldab infovahetuse ja osaleb projektimeeskonna koosolekutel. Projektijuht on hankijale kontaktisikuks tööde teostamise ning üleandmise käigus. 7.2. Arhitekt, kelle üheks ülesandeks on koostada plaan, milliseid tarkvaralisi lahendusi, platvorme või muid tehnoloogilisi abivahendeid arendusmeeskond RIT portaali arendamisel kasutab. Arhitekt vastutab lahenduste tervikuna toimimise ning valitud arendusvahendite ning platvormide otstarbeka kasutamise eest. Arhitekti ülesanne on tagada loodud arhitektuuri jätkusuutlikkus (kokkuleppel hankijaga) pidevalt suunates arendusmeeskonna aega arhitektuuri parendamisse ning tehnilise võla vähendamisse. Arhitekt vastutab, et arendustegevuse keerukus muutuks ajas võimalikult aeglaselt ja jääks hoomatavaks. 7.3. Analüütik, kelle peamised ülesanded on RIT portaali ärivajaduste, äriprotsesside analüüs, tehniline analüüs, arendusteks vajalike protsesside kirjeldamine, äriarenduseks vajaliku dokumentatsiooni loomine ja haldamine. Lisaks on analüütiku ülesandeks koostada planeeritava infosüsteemi dokumentatsioon, sh detailne dokumentatsioon kõikide funktsionaalsuste ootuspärasest ja korrektsest toimimisest, kasutuslood, ning funktsionaalsed ning mittefunktsionaalsed nõuded. Analüütikud koostavad ka arenduspiletid nii taustasüsteemide kui ka esitluskihi arendajatele. 7.4. Arendajad, kes teostavad pakkuja poolt arendus- ja hooldustöid ning vastavalt kokkuleppele pakub hankijale tööde ettevalmistamisel ja/või teostamise järgselt konsultatsioone ning koolitusi. Meeskonnas peab olema nii front-end kui back-end oskusega arendaja, et teostada süsteemide esitluskihi ja taustasüsteemide arendused. Arendaja vastutab arenduste teostamise kvaliteedi eest, sh tegeleb ilmnevate vigade parandamisega ning vajadusel koostab tehnilist dokumentatsiooni. 7.5. Testija, kes teostab tehtud töödele testimisi, koostab testimistega seonduva dokumentatsiooni ning vastavalt kokkuleppele pakub hankijale tööde ettevalmistamisel ja/või teostamise järgselt konsultatsioone ning koolitusi. Testija ülesandeks on tagada arendatud tarkvaralahenduste nõuetekohane toimimine läbi arenduse piisava testimise enne lahenduste kasutajale kättesaadavaks tegemist. 7.6. UX-UI disainer, kelle peamised ülesanded on kavandada ning illustreerida uute funktsionaalsuste või protsesside toimimist kasutajasõbralikul viisil. Samuti olemasolevate funktsionaalsuste ja protsesside kasutajasõbralikkuse tõstmine ja parendusettepanekute tegemine. Lisaks luua koostatud lähteülesandele vastavalt kasutajaliidese disain, vajadusel ka uusi komponente, mis on kooskõlas vastava projekti stiilinõuetega. Samuti hoida ning Lk 2/7  parendada stiilinõuetes sisalduvaid komponente. UX disaini ja UI disaini valideerimine ja testimine kasutajatega, muudatuste sisseviimine vastavalt testi tulemustele. 8. Meeskonnaliikmete ühine CV vorm 8.1. CV-s peab nähtuma kõikide hankija seatud nõuete täitmine. Hankija kontrollib nõude täitmist esitatud andmete alusel. CV peab olema esitatud eesti keeles. Meeskond tunnistatakse vastavaks, kui kõik CV vormil esitatud nõutud kogemused on meeskonnaliikmete poolt kaetud. 8.2. Töökogemus eeldab, et tegemist on tööandja heaks töötamisega töösuhtes või tellija heaks töötamisega projektis. Kui tingimuses ei ole nõutud töökogemust projektis, võib viidata ka töösuhtele. Täiendkoolituse või koolitöö raames saadud kogemus ei ole arvesse võetav. Samuti ei arvestata töökogemusena vabakutselisena tegutsemist, v.a kui selle perioodi osas on viidatud konkreetsetele projektidele, millel on tellijaks kolmas isik. 8.3. Töökogemuse andmed tuleb esitada vähemalt kalendrikuude kestuse alusel, näitamaks ära nõutud kogemusele vastav periood (nt osalemine projektis X kestusega 12.2020 – 01.2023). 8.4. „Projekt“ peab olema teostatud kolmanda isiku ehk pakkujast eraldiseisva välise tellija jaoks ning hankija ei käsitle selle dokumendi tähenduses „projektina“ tööandja enda tarbeks või majasisese tellimuse alusel teostatud töid. Selliseid töid aktsepteerib hankija töökogemusena, kui tingimuses ei ole nõutud projektile viitamist. 8.4.1. Projektide andmete esitamisel tuleb iga projekti kohta esitada vähemalt: projekti nimi ja sisu kirjeldus, projekti algus- ja lõppaeg kalendrikuu täpsusega, projekti tellinud asutus ja tellija kontaktisik ning riigihanke korral märkida riigihanke number. 8.4.2. Samaaegselt väldanud projektide alusel omandatud töökogemust ei summeerita. 8.4.3. Viidatud projektid peavad olema hanke algamise ajaks nõutud kogemuse mahus täidetud ja tellija poolt vastu võetud. 8.4.4. Hankijal on õigus pöörduda projekti tellija poole esitatud andmete kontrollimiseks. 8.4.5. Projektiks ei loeta (varasemat) töösuhet. 8.4.6. Hankija ei aktsepteeri tingimuste täitmiseks „konfidentsiaalseid“ projekte, mille osas pakkujal ei ole võimalik esitada projekti andmeid tingimuses nõutu kohta ja mille osas ei ole võimalik kolmandal isikul tellijana anda kinnitust projekti nõuetekohase täitmise kohta. 8.4.7. Töökogemusele viidatav projekt peab olema teostatud viimase 7 (seitsme) aasta jooksul, arvestades käesoleva riigihanke hanketeate avaldamise kuupäeva. Lk 3/7  8.4.8. Iga loetelus toodud projekt eraldi ei pea sisaldama andmeid kopeerituna, piisab viitest varasemalt samas dokumendis esitatud projekti informatsioonile. 8.5. Meeskonna ühine CV tuleb esitada järgmisel vormil, täites kõik nõutud väljad: Jrk Nõuded Kes vastab esitatud nõudele Täpsustus selle kohta kus/kuidas Projekti algus- ja Projektidele viitamisel (isiku nimi) on nõue täidetud. lõppaeg kalendrikuu märkida projekti täpsusega. Riigihanke tellinud asutus, tellija Kas projekti nimi ja sisu korral lisada riigihanke kontaktisik, kirjeldus (sh kasutatud viitenumber. kontaktandmed (e- tehnoloogiad ja tööülesanded mail) projektis, välja tuua ka Projekt peab olema infosüsteem, millega töötamisel teostatud viimase 7 kogemus omandati) või viide (seitsme) aasta jooksul, töösuhtele (tööandja nimi, arvestades käesoleva töökogemuse kestuse periood ja riigihanke hanketeate tööülesannete lühikirjeldus) avaldamise kuupäeva. 1. Veebipõhise sh Sisesta projekti tellinud Sisestada selle Sisestada projekti autoriseerimist nõudva asutus ning tellija meeskonnaliikme nimi, kes Projekti nimi ja sisu kirjeldus periood. Riigihanke rakenduse arendamise kontaktisik koos vastab nimetatud nõudele korral lisada viitenumber. kogemus projektis kontaktandmetega. 2. Sisesta projekti tellinud PostgreSQL andmebaasiga Sisestada selle Sisestada projekti asutus ning tellija töötamise kogemus meeskonnaliikme nimi, kes Projekti nimi ja sisu kirjeldus periood. Riigihanke kontaktisik koos projektis vastab nimetatud nõudele korral lisada viitenumber. kontaktandmetega. 3. Kogemus projektis pideva Sisesta projekti tellinud Sisestada selle Sisestada projekti integratsiooni (CI- asutus ning tellija meeskonnaliikme nimi, kes Projekti nimi ja sisu kirjeldus periood. Riigihanke continuous integration) kontaktisik koos vastab nimetatud nõudele korral lisada viitenumber. põhimõtete rakendamisega kontaktandmetega. Lk 4/7 4. Vähemalt 36-kuune Sisestada selle Lisada tööandja nimi, projektijuhtimise Tööandja kontaktisik meeskonnaliikme nimi, kes töökogemuse kestuse periood, - töökogemus tarkvara koos kontaktandmetega. vastab nimetatud nõudele tööülesannete lühikirjeldus arenduses 5. Vähemalt 36-kuuline Sisestada selle Lisada tööandja nimi, Tööandja kontaktisik töökogemus tarkvara meeskonnaliikme nimi, kes töökogemuse kestuse periood, - koos kontaktandmetega. analüüsi läbiviimisel vastab nimetatud nõudele tööülesannete lühikirjeldus 6. Sisesta projekti tellinud Kogemus projektis UML- Sisestada selle Sisestada projekti asutus ning tellija iga (Unified Modeling meeskonnaliikme nimi, kes Projekti nimi ja sisu kirjeldus periood. Riigihanke kontaktisik koos Language) vastab nimetatud nõudele korral lisada viitenumber. kontaktandmetega. 7. Sisesta projekti tellinud Prototüübi koostamise Sisestada selle Sisestada projekti asutus ning tellija kogemus (Figma vm meeskonnaliikme nimi, kes Projekti nimi ja sisu kirjeldus periood. Riigihanke kontaktisik koos sarnane vahend) projektis vastab nimetatud nõudele korral lisada viitenumber. kontaktandmetega. 8. Vähemalt 24-kuuline Sisestada selle Lisada tööandja nimi, Tööandja kontaktisik töökogemus süsteemi- või meeskonnaliikme nimi, kes töökogemuse kestuse periood, - koos kontaktandmetega. tarkvara arhitekti rollis vastab nimetatud nõudele tööülesannete lühikirjeldus 9. Sisesta projekti tellinud Sisestada selle Sisestada projekti GIT versioonihalduse asutus ning tellija meeskonnaliikme nimi, kes Projekti nimi ja sisu kirjeldus periood. Riigihanke kogemus projektis kontaktisik koos vastab nimetatud nõudele korral lisada viitenumber. kontaktandmetega. 10. Kogemus projektis DevOps Sisesta projekti tellinud arendustsükli Sisestada selle Sisestada projekti asutus ning tellija ülesehitamisel (Plan, Code, meeskonnaliikme nimi, kes Projekti nimi ja sisu kirjeldus periood. Riigihanke kontaktisik koos Build, Test, Release, vastab nimetatud nõudele korral lisada viitenumber. kontaktandmetega. Deploy, Operate, Monitor) 11. Kogemus projektis Sisestada selle Sisestada projekti Sisesta projekti tellinud mikroteenustel põhineva meeskonnaliikme nimi, kes Projekti nimi ja sisu kirjeldus periood. Riigihanke asutus ning tellija arhitektuurilahenduse vastab nimetatud nõudele korral lisada viitenumber. Lk 5/7  projekteerimisel ja kontaktisik koos realiseerimisel kontaktandmetega. 12. Sisesta projekti tellinud Sisestada selle Sisestada projekti asutus ning tellija K8S kogemus projektis meeskonnaliikme nimi, kes Projekti nimi ja sisu kirjeldus periood. Riigihanke kontaktisik koos vastab nimetatud nõudele korral lisada viitenumber. kontaktandmetega. 13. Kogemus proovitöös Sisesta projekti tellinud pakutava serveripoolse Sisestada selle Sisestada projekti asutus ning tellija raamistiku arendamisel meeskonnaliikme nimi, kes Projekti nimi ja sisu kirjeldus periood. Riigihanke kontaktisik koos projektis (kas Go või Java vastab nimetatud nõudele korral lisada viitenumber. kontaktandmetega. Spring Boot) 14. Kogemus proovitöös Sisesta projekti tellinud pakutava kasutajaliidese Sisestada selle Sisestada projekti asutus ning tellija raamistiku arendamisel meeskonnaliikme nimi, kes Projekti nimi ja sisu kirjeldus periood. Riigihanke kontaktisik koos projektis (kas React või vastab nimetatud nõudele korral lisada viitenumber. kontaktandmetega. Angular raamistik) 15. Sisesta projekti tellinud REST API Sisestada selle Sisestada projekti asutus ning tellija (https://restfulapi.net/) meeskonnaliikme nimi, kes Projekti nimi ja sisu kirjeldus periood. Riigihanke kontaktisik koos kogemus projektis vastab nimetatud nõudele korral lisada viitenumber. kontaktandmetega. 16. Kogemus vähemalt kahes Sisesta projekti tellinud Sisestada selle Sisestada projekti tarkvara arenduse projektis asutus ning tellija meeskonnaliikme nimi, kes Projekti nimi ja sisu kirjeldus periood. Riigihanke testide automatiseerimise kontaktisik koos vastab nimetatud nõudele korral lisada viitenumber. teostamisel kontaktandmetega. 17. Sisesta projekti tellinud Kogemus projektis Sisestada selle Sisestada projekti asutus ning tellija koormustestide ja API meeskonnaliikme nimi, kes Projekti nimi ja sisu kirjeldus periood. Riigihanke kontaktisik koos testide kirjutamisel vastab nimetatud nõudele korral lisada viitenumber. kontaktandmetega. Lk 6/7 18. Kogemus Sisesta projekti tellinud digiligipääsetavuse Sisestada selle Sisestada projekti asutus ning tellija nõuetega projektis (nt EN meeskonnaliikme nimi, kes Projekti nimi ja sisu kirjeldus periood. Riigihanke kontaktisik koos 301 549 või WCAG vastab nimetatud nõudele korral lisada viitenumber. kontaktandmetega. standard) 19. Sisesta projekti tellinud Kasutajaliidese ja Sisestada selle Sisestada projekti asutus ning tellija kasutajateekonna loomise meeskonnaliikme nimi, kes Projekti nimi ja sisu kirjeldus periood. Riigihanke kontaktisik koos kogemus projektis vastab nimetatud nõudele korral lisada viitenumber. kontaktandmetega. Lk 7/7  Lisa 5 Riigihange „Veebipõhise info- ja teenindusportaali arendus- ja hooldustööd“ (290452) Lisa 5. RAAMLEPINGU ALUSEL SÕLMITAV HANKELEPING Riigi Info- ja Kommunikatsioonitehnoloogia Keskus, (edaspidi „tellija“) registrikood 77001613, aadress Lõõtsa 8a, Tallinn 11415, mida ________2024 sõlmitud raamlepingu nr ____ (edaspidi „raamleping“) alusel esindab _________________, ja ________________ (edaspidi „täitja”), registrikood _____________, aadress_______________, mida esindab ___________ sõlmisid lähtuvalt raamlepingu tingimustest käesoleva hankelepingu (edaspidi „leping”) ja leppisid kokku alljärgnevas: 1. Täitja kohustub teostama raamlepingus sätestatud tingimustel järgmised tööd (edaspidi töö): 1.1. _________________________; 1.2. _________________________. 2. Täitja kohustub teostama lepingus kokku lepitud töö ning andma selle koos tööst tulenevate varaliste õigustega tellijale üle hiljemalt ___________________. 3. Täitja kohustub viivitamatult teatama tellijale kõigist töö teostamisega seotud olulistest asjaoludest, eelkõige aga nendest, mis võivad mõjutada või mõjutavad töö tähtaegselt valmimist või töö vastavust lepingu tingimustele ja/või mille vastu on või võib olla tellijal äratuntav oluline huvi. 4. Tellija maksab punktis 1 nimetatud töö teostamise eest täitjale tasu ________ eurot, millele lisandub käibemaks. 5. Lepingu finantseerimise allikas: /märkida vajadusel/. 6. Punktis 1 nimetatud töö täpsem kirjeldus on toodud lepingule lisatud lähteülesandes. Tellija Täitja (allkirjastatud digitaalselt) (allkirjastatud digitaalselt)