Leping

Käskkirja lisa 2 Majandus- ja Kommunikatsiooniministeerium HANKEDOKUMENT Funktsioonide registri keskkonna arenduse tellimine CPV kood: 72200000-7 „Tarkvara programmeerimis- ja nõustamisteenused“ Tallinn 2023 SISUKORD 1. Hanke üldandmed ja riigihanke objekt ....................................................................................... 4 2. Nõuded Pakkumusele.................................................................................................................. 4 3. Nõuded projektimeeskonnale...................................................................................................... 6 4. Teavitamine ja selgitused ............................................................................................................ 8 5. Pakkumuste avamine ja vastavuse kontrollimine ....................................................................... 9 6. Pakkumuste võrdlemine, hindamine ja pakkumuste edukaks tunnistamine ............................... 9 7. Kõigi pakkumuste tagasilükkamine ja hankemenetluse lõpetamine ........................................ 11 8. Hankelepingu sõlmimine, Töö tulemuste vastuvõtmine ja tasumine ....................................... 11 9. Hankedokumendi lisad .............................................................................................................. 12 Lugupeetud Pakkuja! Majandus- ja Kommunikatsiooniministeerium teeb ettepaneku pakkumuse esitamiseks riigihankele, millega tellitakse funktsioonide registri keskkonna analüüsi, disaini ja arenduse teostamise teenust. Hankija: Majandus- ja Kommunikatsiooniministeerium Suur-Ameerika 1, 10122 Tallinn rg-kood: 70003158 e-post: [email protected] (edaspidi Hankija) Riigihanke nimetus: Funktsioonide registri keskkonna arenduse tellimine Pakkumuste jõusolek: 90 kalendripäeva Lepingu täitmise kestus: 7 kuu jooksul alates hankelepingu sõlmimisest Lepingu eeldatav maksumus: 110 000 eurot (lisandub käibemaks) Riigihanke läbiviimise eest Karl Andreas Sprenk vastutav isik: Digiriigi arengu osakonna IT oskuste valdkonna juht Hankeleping rahastatakse Euroopa Regionaalarengu Fondist, majandus- ja kommunikatsiooniministri 14. märtsi 2023 käskkirja nr 44 „Toetuse andmise tingimused digiriigi alusbaasi kindlustamise, digiriigi arenguhüpete hoogustumise ning küberruumi turvalisuse tagamise toetamiseks“ alusel, millega kehtestatakse meetme nr 21.1.2.1 “Digiriik” sekkumise 21.1.2.1 „Digilahenduste ja uuenduste väljatöötamine ja kasutuselevõtt avalikus sektoris” raames toetuse andmise tingimused ja kord. Riigihankes saavad osaleda ainult pakkujad, kelle elu- või asukoht on Eestis, mõnes muus Euroopa Liidu liikmesriigis, muus Euroopa Majanduspiirkonna lepinguriigis või Maailma Kaubandusorganisatsiooni riigihankelepinguga ühinenud riigis. 1. Hanke üldandmed ja riigihanke objekt 1.1. Riigihanke lepingu esemeks on funktsioonide registri keskkonna analüüsi, disaini ja arenduse teostamine (edaspidi Töö). Hankelepingu eseme täpsem kirjeldus on esitatud Hankedokumendi (HD) Lisa 1 „Tehniline kirjeldus“. 1.2. Töö teostamise tähtaeg on hankelepingu sõlmimisest alates 7 kuu jooksul. Hankija nägemuses teostatakse tellitavad tööd kahes etapis: 1.2.1. I etapi raames teostatakse keskkonnale tehniline analüüs, koostatakse prototüüp ja tehakse keskkonna disain. I etapi tööde eeldatav teostamise tähtaeg on kuni 50% kogu hankelepingu perioodist, kuid mitte kauem kui 3,5 kuud alates hankelepingu sõlmimisest. 1.2.2. II etapp tugineb Hankija nägemuses I etapis läbiviidud analüüsile, infole, disainile ja tulemitele ning viiakse läbi ja antakse Tellijale üle 7 kuu jooksul pärast hankelepingu sõlmimist. 1.2.3. Pakkujal peab olema valmisolek alustada Töö teostamisega hankelepingu sõlmimisele järgnevast tööpäevast arvates ja nimetatud tingimusega tuleb Pakkujatel pakkumust, s.h projektiplaani, esitades arvestada. 1.3. Hankija ei jaga hanget osadeks, sest projekt tuleb ellu viia ühe tervikliku protsessina. Hankija hinnangul ei ole hanke osadeks jagamine ajaliselt ega kulude lõikes mõistlik ega efektiivne. 1.4. Lepingu eeldatav maksumus on kuni 110 000 eurot (lisandub käibemaks). Pakkumuses esitatud hind on lõplik. 2. Nõuded Pakkumusele 2.1. Pakkumuste esitamine 2.1.1. Pakkumus peab vastama riigihanke alusdokumentides esitatud tingimustele ja tuleb esitada kogu riigihanke alusdokumentides nõutud mahus. Alternatiivsed lahendused ei ole lubatud. 2.1.2. Pakkuja peab arvestama, et pakkumuse edukaks tunnistamise korral vastutab Pakkuja Töö teostamise eest kooskõlas hanketingimustega ning tema poolt esitatud pakkumusega. 2.1.3. Pakkumus ja kõik pakkumuse juurde kuuluvad dokumendid peavad olema eesti keeles. Kõik võõrkeelsed dokumendid peavad olema vormistatud trükitult ning eesti keelde tõlgitud, kusjuures tõlge peab vahetult järgnema originaalile. 2.1.4. Tulenevalt RHS § 461 lg-st 1 peab Pakkuja märkima pakkumuses selgelt eristataval viisil, milline teave on pakkuja ärisaladus ning põhjendab ärisaladuseks määramist. Ärisaladusena ei ole lubatud märkida pakkumuse maksumust, osamaksumusi ega muid pakkumuste hindamise kriteeriumidele vastavaid pakkumust iseloomustavaid numbrilisi näitajaid.  2.1.4.1. Hankija juhib tähelepanu, et eduka pakkuja pakkumus on avalik lähtuvalt RHS § 110 lg 5, välja arvatud pakkuja poolt õigustatult ärisaladuseks määratletud osas. Juhul kui pakkuja ei määratle pakkumuses arusaadavalt ärisaladust või ei põhjenda asjakohaselt, miks on tegemist ärisaladusega, on Hankijal kohustus teabenõude laekudes pakkumus täies ulatuses avalikustada. 2.1.5. Ühispakkumuse esitamise korral peab Pakkuja kinnitama HD Lisa 4 vormil, et hankelepingu täitmise eest vastutavad ühispakkujad solidaarselt. 2.1.6. Pakkumus peab olema esitatud riigihangete registri kaudu registris märgitud tähtajaks digitaalselt allkirjastatuna Pakkuja seadusjärgse või volitatud esindaja poolt (volitatud isiku määramisel on lisatud vastav volikiri HD Lisa 5 vormil) 2.1.7. Pärast pakkumuste esitamise tähtaja möödumist pakkumust esitada ei saa. 2.2. Pakkumuse struktuur 2.2.1. Detailne kirjeldus Töö teostamise loogikast, mis peab vastama järgmistele tingimustele: 2.2.1.1. Pakkumusest selgub I ja II etapi saavutamise metoodika (koos metoodika valiku põhjendustega) ning teostatava Töö ja Töö tegevuste kirjeldus. Pakkumusest selgub muuhulgas Pakkuja arusaam hanke eesmärkidest ning seatud eesmärkide saavutamiseni ja hankelepingu tingimustele vastavate tulemiteni viivast protsessist (sh Pakkuja visioon koostööst Hankijaga). Kõik kirjeldatud tööd peavad olema omavahel loogiliselt seotud; 2.2.1.2. Pakkuja kirjeldab detailselt Töö edukat teostamist toetavaid tegevusi. Töö tegevused jaotatakse kaheks selgelt eristatavaks I ja II etapi töödeks ning etappide ja tegevuste lõikes peab olema välja toodud kavandatava etapi või tegevuse maksumus. Iga etapi juures peab tegevuste lõikes kirjeldama Pakkuja ja Hankija rolli ning tooma välja tegevuste lõikes töömahu (tundides) igas etapis. 2.2.1.2.1. Pakkuja peab pakkumuse koostamisel ning tegevuste jagamisel I ja II etappi arvestama, et I etapi täitmise eest tasub Hankija 40% kogusummast ja II etapi eest 60% kogusummast. 2.2.1.3. Pakkuja esitatud Töö tegevuste ja maksumuse etappideks jaotamise alused peavad olema põhjendatud (põhjendatust arvestatakse ka pakkumuse hindamisel). 2.2.2. Projektiplaan ja läbiviimise ajakava, mis kirjeldavad hankelepingu täitmise ajakava, sh kaasatavate projektimeeskonna liikmete jt spetsialistide tööjaotust ja koormust (tundides), vastates järgmistele tingimustele: 2.2.2.1. Projektiplaanis peab Pakkuja välja tooma, millist sisendinfot on vastava Töö etapi teostamisel vaja (sh Hankija poolt) ning millised on I ja II etapi tulemi saavutamiseks koostatavad dokumendid ja tulemid. Lisaks tuleb esitada Töö käigu ja Töö I ja II etapi tulemi dokumenteerimise põhimõtted. 2.2.2.2. Projektiplaan ja läbiviimise ajakava peavad olema realistlikud ning sisaldama tegevuste jaotust kuude kaupa alates lepingu sõlmimise tähtajast. Töö  ajakavas on arvestatud Töö vastuvõtmise vahe- ja lõpptähtajaga. Ajakava peab sisaldama varuaega (puhvrit) ja selles peab arvestama riiklike pühade, puhkepäevade ja meeskonna puhkustega. 2.2.3. Projektijuhtimise, kvaliteedijuhtimise ja riskide haldamise meetmete kirjeldus, põhjendades kõigi nimetatud elementide mõju riigihanke eesmärkide saavutamisele. 2.2.4. Projektimeeskonna ülevaade, milles Pakkuja kirjeldab hanketingimustes kirjeldatud I ja II etapi tulemi saavutamiseks ning projektiplaani elluviimiseks vajalike rollide ja vastutuse isikulist jaotust. Projektimeeskonna ülevaates on välja toodud ka I etapi ja II etapi realiseerimise peavastutaja ja kaasvastutajad. Pakkuja meeskonna suurus, koosseis ja rollide jaotus peab olema ülesande täitmiseks optimaalne. 2.2.5. Pakkuja esitab koos pakkumusega: 2.2.5.1. Pakkuja ajakohastatud kinnitusi sisaldava hankepassi esialgse tõendina Pakkuja suhtes kõrvaldamise aluste puudumise ja tema kvalifitseerimise tingimustele vastamise kohta kooskõlas RHS §104 lg 2 punktidega 1, 2, 4 ja 5; 2.2.5.2. Allkirjastatud projektimeeskonna kinnituse (HD Lisa 2); 2.2.5.3. (kui asjakohane) Ärisaladuse teabe esitamise vormi (HD Lisa 3); 2.2.5.4. (kui asjakohane) Ühispakkujate volikiri (HD Lisa 4); 2.2.5.5. (kui asjakohane) Volikiri (HD Lisa 5); 2.2.5.6. Pakkumuse eelarve (HD Lisa 8). 2.3. Pakkumuse maksumus 2.3.1. Pakkumuse kogumaksumus arvestab olelusringi kulusid. Arvestatakse analüüsi, disaini ja veebilehe loomise kulusid (sh teenuste standardi ja kasutajaliideste ja kasutajakogemuste disainimise ja veebilehe arendamise kulusid). 2.3.2. Pakkumuse maksumus esitatakse HD Lisa 8 „ Pakkumuse eelarve“ vormil. 2.3.3. Pakkumuses esitatud hinnad väljendatakse eurodes. 2.3.4. Tööde maksumus esitatakse koos muude asjakohaste maksudega, ilma käibemaksuta ja ka koos käibemaksuga. 2.3.5. Pakkumuses esitatud hind on lõplik. Töö teostamisega seoses ei tohi Pakkuja Hankijalt nõuda muid tasusid täiendavalt HD Lisa 8 „Pakkumuse eelarve“ vormil esitatule. 2.3.6. Juhul, kui Töö vajab Pakkuja Tööks mingeid täiendavaid litsentse, sertifikaate vms, siis need hangib Pakkuja ning lisab litsentsi/litsentside, sertifikaadi/sertifikaatide vms hinna maksumusele ning esitab Pakkumuses. 2.3.7. Valuutakursside, kauba tootjahinna muutumine või muud tegurid hinda ei mõjuta. 3. Nõuded projektimeeskonnale Tabel 1. Nõuded projektimeeskonna koosseisule ja kompetentsile  Roll/vastavat rolli täitvate nõutud Rolli kirjeldus Nõuded kompetentsile isikute arv Projektijuht vastutab Pakkumuse esitamisele eelneva 60 hankelepingu täitmise kuu jooksul vähemalt kolme (3) IT eest, juhib meeskonda, arenduse projekti juhtimine 3.1. Projektijuht (1) suhtleb Hankija (nõuetekohaselt lõpetatud projektid). esindajaga ja korraldab Omab vähemalt 3 aastast töökogemust aruandlust. projektijuhina. Pakkumuse esitamisele eelneva 60 Analüütik vastutab hanke kuu jooksul vähemalt kolmes (3) IT tehnilise kirjelduse põhjal 3.2. Analüütik (1) arenduses koostanud tehnilise arenduse analüüsi. Omab vähemalt 3 aastast dokumenteerimise eest. töökogemust tehnilise analüütikuna. Pakkumuse esitamisele eelneva 60 Teenusedisainer vastutab kuu jooksul vähemalt kolmes (3) IT keskkonna tervikliku 3.3. Teenusedisainer (1) arenduses keskkonna disaini teinud. disaini ja funktsionaalsuse Omab vähemalt 4 aastast töökogemust eest. teenusedisainerina. Pakkumuse esitamisele eelneva 60 kuu jooksul vähemalt kolmes (3) IT UI disainer vastutab 3.4. UI disainer (1) arenduses keskkonna disaini teinud. keskkonna disaini eest. Omab vähemalt 3 aastast töökogemust UI disainerina. Pakkumuse esitamisele eelneva 60 UX disainer vastutab kuu jooksul vähemalt kolmes (3) IT 3.5. UX disainer (1) keskkonna kasutaja arenduses kasutajapõhist keskkonna kogemuse eest. disaini teinud. Omab vähemalt 4 aastast töökogemust UX disainerina. Veebilehe arendaja Pakkumuse esitamisele eelneva 60 arendab vastavalt kuu jooksul vähemalt kolmes (3) IT Veebilehe arendaja tehnilisele analüüsile ja 3.6. arenduses töötanud arendajana. Omab (vähemalt 2) tellijaga konsulteerimise vähemalt 3 aastast töökogemust tulemusena koostatud arendajana. analüüsi alusel.  Pakkumuse esitamisele eelneva 60 Vastutab keskkonna kuu jooksul vähemalt kolmes (3) IT tervikliku töötamise ja 3.7. Tarkvara testija (1) arenduses töötanud tarkvara testijana. erinevate vigade leidmise Omab vähemalt 2 aastast töökogemust eest. tarkvara testijana. 3.8. Iga meeskonna liige (p. 3.2-3.7.) võib lisaks enda rollile täita ka projektijuhi rolli (p. 3.1.). 3.9. Punktides 3.3., 3.4. ja 3.5. esitatud rollid võivad olla täidetud sama isiku poolt. 3.10. Punktides 3.2. ja 3.3. esitatud rollid võivad olla täidetud sama isiku poolt. 3.11. Pakkuja võib soovi korral lisaks kaasata eksperte (sh välismaiseid eksperte), kui nad annavad Töö teostamisele lisandväärtust juurde. Sellisel juhul tuleb Pakkujal põhjendada kaasatud eksperdi rolli ja eeldatavat panust Töö teostamisel. Pakkuja omal soovil ekspertide kaasamine (täiendavalt HD-s nõutud rollidele) ei anna Pakkujale eelist ega lisaväärtuspunkte. 3.12. Pakkuja määrab ühe järgmistest rollidest – teenusedisaineri (p. 3.3.) või UX disaineri (p. 3.5.) – vastutavaks strateegilise vaate hoidmise ja sisutöö sidusa ja tervikliku lõpplahenduseni juhtimise eest, kes koos projektijuhiga (p. 3.1.) tagavad erinevate rollide koostöö terviklahenduse ehitamiseks. 3.13. Pakkuja esitab nimetatud nõuetele vastavuse tõendamiseks Tööd teostavate spetsialistide CV-d ja eelnimetatud spetsialistide poolt allkirjastatud kinnitused, et vastavad spetsialistid on nõus käesolevas riigihankes osalema. 4. Teavitamine ja selgitused 4.1. Riigihanke alusdokumentide sisu kohta saab selgitusi ainult kirjalikul pöördumisel läbi riigihangete registri „Teabevahetus“ töölehe. Pöördumine tuleb vormistada eesti keeles. 4.2. Hankija vastab HD punktis 4.1 nimetatud pöördumistele 3 tööpäeva jooksul vastava taotluse saamisest arvates, riigihangete registri kaudu. 4.3. Pakkuja võtab enda kanda pakkumuse ja pakkumuse tagasivõtmise teate Hankijale üleandmise kogu riski, kaasa arvatud vääramatu jõu toime võimalus. 4.4. Pakkuja kannab kõik pakkumuse ettevalmistamise ning esitamisega seotud kulud kuni hankelepingu sõlmimiseni. 4.5. Pakkuja peab hoidma oma pakkumuse jõus vähemalt 3 kuud. Pakkumuse jõusoleku tähtaeg algab pakkumuste esitamise tähtpäevast, mis on märgitud riigihangete registri hanke üldandmete lehel. 4.6. Kõikidest hankemenetluses tehtud otsustest teavitatakse Pakkujaid riigihangete registri kaudu viivitamatult, kuid mitte hiljem kui 3 tööpäeva jooksul vastava otsuse tegemisest arvates. 5. Pakkumuste avamine ja vastavuse kontrollimine 5.1. Pakkumuste avamine toimub elektrooniliselt riigihangete registri töökeskkonnas märgitud tähtpäeval. 5.2. Hankija kontrollib hankepassis toodud kinnituste alusel kvalifitseeritud Pakkujate esitatud pakkumuste vastavust riigihanke alusdokumentides esitatud tingimustele. 5.3. Pakkumuse esitamisega kinnitab pakkuja riigihanke alusdokumentides esitatud tingimuste ülevõtmist. 5.4. Hankija lükkab pakkumuse tagasi, kui see ei vasta riigihanke alusdokumentides esitatud tingimustele. Hankija võib tunnistada pakkumuse vastavaks, kui selles ei esine sisulisi kõrvalekaldeid riigihanke alusdokumentides nimetatud tingimustest. 5.5. Pakkuja, kelle pakkumus on tagasi lükatud, ei osale edasises hankemenetluses. 6. Pakkumuste võrdlemine, hindamine ja pakkumuste edukaks tunnistamine 6.1. Hankija hindab kõiki vastavaks tunnistatud pakkumusi. 6.2. Hankijal on õigus põhjendamatult madala maksumusega pakkumus tagasi lükata, kui Hankija leiab pärast Pakkujalt nõutud selgituse saamist ja tõendite hindamist, et pakkumuse maksumus on põhjendamatult madal või Pakkuja ei ole tähtajaks esitanud nõutud selgitust (RHS § 115). 6.3. Pakkumuste hindamise metoodika: 6.3.1. Töö kogumaksumus (50 punkti); 6.3.1.1. Maksimaalsed väärtuspunktid omistatakse Pakkumusele, mille kogumaksumus on madalaim, teiste Pakkumuste väärtuspunktid arvutatakse järgmise valemi järgi: „väärtuspunktid“ = „kõige odavama Pakkumuse kogumaksumus” ÷ „hinnatava Pakkumuse kogumaksumus” × 50. Arvutuste tulemused ümardatakse ühe komakoha täpsusega. Kogumaksumus tuleb esitada HD Lisa 8 „Pakkumuse eelarve“ vormil. Kogumaksumust hinnatakse koos KM- iga. 6.3.2. „Töö teostamise vastavus tehnilisele kirjeldusele“ (50 punkti). Kriteeriumit hinnatakse Tabelis 3 nimetatud kolme alamkriteeriumi alusel, milleks on: 6.3.2.1. „Töö teostamise loogika ja protsessi kirjeldus“ (25 punkti); 6.3.2.2. „Projektiplaan ja läbiviimise ajakava“ (20 punkti); 6.3.2.3. „Riskide haldamise meetmete kirjeldus“ (5 punkti); 6.3.2.4. „Töö teostamise vastavus tehnilisele kirjeldusele“ kriteeriumi iga alamkriteeriumit hindavad Hankija hankekomisjoni liikmed individuaalselt. Maksimaalselt on igalt hindamiskomisjoni liikmelt võimalik saada 50 punkti, liikmete antud punktid summeeritakse ja leitakse aritmeetiline keskmine. Seejärel rakendatakse väärtuspunktide süsteemi ehk maksimaalsed väärtuspunktid omistatakse suurima punktisumma saanud pakkumusele. Ülejäänud hinnatavate pakkumuste väärtuspunktid alamkriteeriumi osas leitakse  järgmise valemi järgi: „punktimäär“ = „ hinnatava pakkumuse aritmeetiline keskmine“ ÷ „suurim aritmeetiline keskmine“ x „50“ Tabel 3. Kriteeriumi „Töö teostamise vastavus tehnilisele kirjeldusele“ alamkriteeriumiteks on: Alamkriteeriumid Punktid Kriteeriumi komponendid Töö teostamise Pakkuja on täielikult aru saanud hanke ülesandepüstitusest. Pakutud loogika ja 25 metoodika ja protsessi loogika aitavad saavutada hanke eesmärki protsessi kirjeldus ning hankelepingu tingimustele vastavat tulemit. Pakkuja on aru saanud hanke ülesandepüstitusest. Pakutud 15 metoodika ja protsessi loogika aitavad osaliselt saavutada hanke eesmärki ning hankelepingu tingimustele vastavat tulemit. Pakkuja ei ole aru saanud hanke ülesandepüstitusest. Pakutud 5 metoodika ning protsessi loogika ei võimalda saavutada hanke eesmärke ega hankelepingu tingimustele vastavat tulemit. Projektiplaan ja Projektiplaanis kirjeldatud hanke eesmärkide ja tulemite läbiviimise saavutamiseks vajalikud tegevused (sh tegevuste ja ajakava 20 kogumaksumuse etappideks jaotamise põhjendatus) on täielikult kooskõlas hanke tehnilise kirjelduse ja hanke eesmärkidega. Ajakava on realistlik Projektiplaanis kirjeldatud hanke eesmärkide ja tulemite saavutamiseks vajalikud tegevused (sh tegevuste ja 12 kogumaksumuse etappideks jaotamise põhjendatus) on suures osas kooskõlas hanke tehnilise kirjelduse ja hanke eesmärkidega. Ajakava kirjelduses esineb üksikuid puuduseid. Projektiplaanis kirjeldatud hanke eesmärkide ja tulemite saavutamiseks vajalikud tegevused (sh tegevuste ja 6 kogumaksumuse etappideks jaotamise põhjendatus) ei ole kooskõlas hanke tehnilise kirjelduse ja hanke eesmärkidega ega saavutatav planeeritud ajakavas. Riskide haldamise 5 Riskide haldamise meetmed on proportsionaalsed. meetmete 3 Riskide haldamise meetmete kirjelduses esineb üksikuid puuduseid. kirjeldus Riskide haldamise meetmed ei toeta hanke eesmärkide saavutamist 1 etteantud ajaraamis.  6.5. Saadud väärtuspunktid summeeritakse ning edukaks tunnistatakse pakkumus, mille väärtuspunktide summa on eelpool kirjeldatud arvutuste tulemusel kokku suurim. Võrdse arvu väärtuspunkte kogunud pakkumuste puhul osutub edukaks pakkumuseks kriteeriumi „Töö kogumaksumus“ eest enim väärtuspunkte saanud pakkumus. Juhul, kui ka antud kriteeriumi eest on võrdsed pakkumused saanud sama palju väärtuspunkte, siis selgub edukas pakkumus hindajate hääletuse tulemusel. 6.6. Väärtuspunktide arvutamisel arvestatakse tulemused täpsusega 2 (kaks) kohta pärast koma. 6.7. Juhul kui nõuetele vastab vaid üks pakkumus ja sellele omistati hindamiskriteeriumi "Töö teostamise vastavus tehnilisele kirjeldusele" osas kõigi hindamiskomisjoni liikmete poolt vähemalt ühe alamkriteeriumi osas miinimumpunktid, siis pakkumust edukaks ei tunnistata. 7. Kõigi pakkumuste tagasilükkamine ja hankemenetluse lõpetamine 7.1. Hankija võib teha põhjendatud kirjaliku otsuse kõigi pakkumuste tagasilükkamise kohta lisaks RHS § 116 lõikes 1 nimetatule, kui: 7.1.1. hankemenetluse toimumise ajal on Hankijale saanud teatavaks uued asjaolud, mis välistavad või muudavad Hankijale ebaotstarbekaks hankemenetluse lõpule viimise riigihanke alusdokumentides sätestatud tingimustel. 7.2. Hankija ei kanna vastutust Pakkujate ees, kui kõigi pakkumuste tagasilükkamine on toimunud käesolevas dokumendis sätestatud tingimustel. 7.3. Kui kõigi Pakkujate esitatud Töö teostamise kava ei ole realiseeritav Töö 7-kuulises ajaraamis, võib Hankija kuulutada hanke nurjunuks. 8. Hankelepingu sõlmimine, Töö tulemuste vastuvõtmine ja tasumine 8.1. Hankeleping sõlmitakse eduka pakkumuse esitanud Pakkujaga, kellel puuduvad hankemenetluselt kõrvaldamise alused ja kes vastab kvalifitseerimise tingimustele hankepassis esitatud kinnitusi tõendavate dokumentide ja andmete alusel. 8.2. Pakkuja teostab Töö eesti keeles ja esitab I etapi ja II etapi Tulemi eesti keeles, välja arvatud osades, kus HD lisades (Lisa 1 Tehniline kirjeldus) on Hankija selgelt määratlenud, et mõni Töö tegevus (sh Tulem) tuleb esitada inglise keeles. 8.3. Pakkuja annab Töö Hankijale üle etappide kaupa. 8.3.1. I etapi tulem antakse Hankijale üle pärast I etapi tööde teostamist edukaks tunnistatud pakkumuses esitatud ajagraafikust tulenevatel tähtaegadel. I etapi tulemiga antakse üle vähemalt etapi tegevuste dokumentatsioon, sh dokumenteeritud ettepanekud koos kokkuvõtliku põhjendusega, funktsioonide registri esialgsest kontseptsioonist, iganädalastest memodest, koosolekute protokollidest ning I etapi tulemit tutvustava ettekande slaidid ja muu koostatud dokumentatsioon. Lisaks antakse üle prototüübi failid. Täpsemad nõuded on esitatud HD Lisa 1 „Tehniline  kirjeldus“. Koos I etapi Tulemiga esitab Pakkuja HD Lisa 7 vormile vastava digitaalselt allkirjastatud üleandmise-vastuvõtmise akti. 8.3.1.1. Hankija otsustab pärast I etapi Tulemi vastuvõtmist, kas Töö teostamisega jätkamine on mõistlik. Kui Hankija otsustab, et Töö järgmise etapiga ei jätkata (peale I etappi), siis hankeleping lõpetatakse (Hankija tasub Pakkujale I etapis tehtud Töö eest ja II etapi eest tasu ei maksta). 8.3.2. II etapi tulem antakse Hankijale üle hiljemalt 7 kuud pärast Lepingu allkirjastamist. II etapi Tulemiga antakse üle vähemalt II etapi tegevuste dokumentatsiooni tekstifaili(de)na (nt Word, PDF vms), tehniline teave ja soovitused, projekti lühikokkuvõte, ingliskeelse tõlke lisamise juhend, testimiste tulemid, iganädalased memod, koosolekute protokollid, vajaduse korral prototüübi täiendatud failid. Täitja teeb klikitava prototüübi Hankijale kättesaadavaks ja kasutatavaks vähemalt 2 aasta jooksul Töö Tulemi vastuvõtmisest. Täpsemad nõuded on esitatud HD Lisa 1 „Tehniline kirjeldus“. Koos II etapi Tulemiga esitab Pakkuja HD Lisa 7 vormile vastava digitaalselt allkirjastatud üleandmise-vastuvõtmise akti. 9. Hankedokumendi lisad Lisa 1 – Tehniline kirjeldus Lisa 2 – Projektimeeskonna kinnitus Lisa 3 – Ärisaladuse vorm Lisa 4 – Ühispakkujate volikiri Lisa 5 – Volikiri vorm Lisa 6 – Töövõtuleping (projekt) Lisa 7 – Tööde üleandmise-vastuvõtmise akt Lisa 8 – Pakkumuse eelarve  Riigihange: Funktsioonide registri keskkonna arenduse tellimine Lisa 1 – Tehniline kirjeldus 1. Sissejuhatus Antud dokument kirjeldab kavandatava riikliku funktsioonide registri arendamisega seonduvaid nõudeid. Projekti eesmärk on luua ühtne digiriigi keskkond, mis toetab kogukonnast juhinduvat e- riigi arendust, riigi infosüsteemi koosvõimelisena toimimist ja mis võimaldaks levitada taaskasutatavat koodi, koodijuppe ja infot ning toetaks ja edendaks era- ja avaliku sektori koostööd ning ühis- ja taaskasutust. Loodava keskkonna eesmärk on koondada kõikide ministeeriumite infotehnoloogia- ja arenduskeskuste (edaspidi IT majad) avalikult jagatav kood, mikroteenused, Software as a Service (edaspidi SaaS) teenused jne ühte keskkonda. Vastavalt lisatud objektile näidatakse kasutajale infot selle kohta ja suunatakse edasi koodi repositooriumisse, kust on võimalik koodi alla laadida. Funktsioonide registri teenuse haldaja (edaspidi haldaja) on Majandus- ja Kommunikatsiooniministeerium. Tehnilist tuge pakub RIA. 2. Töö taustinfo MKM koos RIAga arendas 4 aastat tagasi keskkonna koodivaramu.eesti.ee, kuhu koondati IT majade avalikku koodi. See on aastaid üleval olnud, aga selle keskkonna täielikku potentsiaali pole veel suudetud kasutada. Et suurendada koodi taaskasutamist, vähendada rahakulu ja uute teenuste korduvat arendamist, on otsustanud MKM koostöös IT majadega tulla välja funktsioonide registriga, kus saavad keskkonnas olevad kasutajad lihtsalt jagada ja kasutusele võtta avalikku koodi. Keskkonna peamiseks eesmärgiks on viidata lisatud koodi repositooriumile, mis võib olla koodivaramu kui ka mingi muu koodihoidla. Aastal 2022 tutvus Tellija riigi IT majade koodi taaskasutamisega ja kuidas seda jagatakse teistega. Intervjuude käigus selgus et hetkel olevast koodivaramu keskkonnast ei piisa, kuna tuleb avaldama koodi erinevates kohtades ja tekitab lisatööd kõigile. Intervjuude tulemusel leidis MKMi digiriigi arengu osakond, et koodivaramu täiustamisest üksi ei piisa ja vaja on uut lähenemist. Intervjuud toimusid TEHIK, SMIT, KEMIT, RIA, RMIT ja RIT esindajatega. Intervjuudest järeldus peamiste probleemidena: • riigiasutustel on oma repositooriumid, kus jagatakse koodijuppe ja teenuseid; • ei soovita tekitada lisatööd sellega, et koodi tuleb dubleerida erinevates repositooriumites; • kogu koodi pole võimalik jagada, kuna võib sisaldada asutusesiseseks kasutamiseks infot;  • soovitakse valideerida, kes saab koodile ligi. Eeltoodust tulenevalt on hanke tulemusena teostatava töö eesmärkideks: • keskkonna tehnilise analüüsi teostamine; • kasutajaliidese disain vastavalt tänapäevaste UX ja UI disaini stiilile; • keskkonna arendamine jälgides taaskasutuse printsiipe, sh teha kood võimalikult lihtsalt taaskasutatavaks, eraldiseisvaks ja modulaarseks; • kogu koodi lisamine avalikult kasutatavana koodivaramusse. Olulised mõisted ja lühendid • MKM – Majandus- ja Kommunikatsiooniministeerium • Avaandmed – Avaandmete all mõistame kõigile veebi kaudu vabalt kasutamiseks antud ja masinloetavas formaadis toorandmeid, millel puuduvad autoriõiguste ja patendikaitse ning kasutus- ja levitamispiirangud. Üldjuhul, kui seaduses ei ole andmete hankimise eest ette nähtud tasu, saab avaandmeid kätte tasuta ja ilma juurdepääsupiiranguteta. Avaandmete loojaks ja avaldajaks on enamasti avaliku sektori asutused, aga võivad olla ka ettevõtted, teadusasutused jt organisatsioonid, kes oma töö käigus koguvad ja toodavad andmeid, mis võiksid avalikkusele huvi pakkuda. • Metaandmed – Metaandmed on andmed andmete kohta ja nende roll on näidata andmete erinevate struktuuride (element, objekt, andmestik) tähendust eelkõige andmekirjeldusena. • Administraator – Autenditud kasutaja, kellel on õigus: o muuta teiste kasutajate õiguseid: teha neid sisuhalduriks või vaatlejaks või administraatoriks. o lisada/eemaldada sisuhaldureid olemasolevate objektide külge/küljest. o kustutada kommentaare o kommenteerida ja hinnata komponente/teenuseid o lisada/muuta/eemaldada põhikategooriaid (nt Saas, kood, must kast). o lisada/eemaldada/muuta "silte" (nt. mikroteenus, pilvekõlbulik vms) ja neile defineerida väljakuvatava sildi värve. o Administraatoril on samuti ka kõik allpool-olevad sisuhalduri ja vaatleja ja külastaja õigused. o Valida milliseid TOP koodi kuvatakse kas vaadatuimad või kõige rohkem alla laetud kood • Sisuhaldur – Autenditud kasutaja, kellel on õigus: o lisada uusi objekte kataloogi o kommenteerida ja hinnata komponente/teenuseid o muuta enda hallatavate objektide andmeid. (nimi, pilt, kategooria, kontaktinfo, kirjeldus, sildid, lingid, kasutusjuhud jms) o enda hallatavatele objektidele määrata teisi sisuhaldureid. 2  o peita kommentaare. o muuta komponendi/teenuse nähtavust (avalik/piiratud). o Sisuhalduril on samuti ka kõik vaatleja ja külastaja õigused. • Vaatleja – Autenditud kasutaja, kellel on õigus: o kommenteerida ja hinnata komponente/teenuseid o muuta enda kasutajaga seotud kontaktinfot (e-mail, telefoninumber, asutus, roll/amet). • Külastaja – Autentimata kasutaja kellel on õigus näha tervet kataloogi (v.a. peidetud komponendid) • Objekt – Selle all mõeldakse ühte järgnevast taaskasutatavast komponendist: o Software as a Service (SaaS üle API või veebikeskkonnana kasutatav teenus) o Kood (koodi repositooriumis - nt koodivaramu.eesti.ee või GitHub - olev kasutatav kood) o Jupp (jupivaramus või kuskil hoidlas kättesaadav binaartarkus, õpetatud mudel, dockeri image vms) o Must Kast (asutuse poolt pakutav digiriigi IT põhine teenus, mida saab kasutusele võtta muude kokkulepete teel, aga millel ei pruugi olla avalikku API't, avalikult levitatavat koodi vms) 3. Nõuded hanke esemele 3.1. Koodivaramu ülesandeks on pakkuda klientidele kaasaegset ning mugavat keskkonda avatud lähtekoodiga seotud tegevuste tegemiseks. 3.2. Koodivaramus on avalik vaade ja autenditud kasutaja vaade. 3.3. Koodivaramu funktsionaalsus on järgmine: 3.3.1. Autentimine. Kasutaja autentimine peab olema tehtud läbi riigi autentimisteenuse (TARA autentimislahendus). Erandjuhtumil peab olema võimalik autentida kasutajanime ja parooliga. 3.3.2. Logimine. Kõik tegevused Koodivaramus peavad olema logitud ja vastavaid õigusi omaval kasutajal peab olema võimalik näha tegevuste logi läbi kasutajaliidese. Logimised tehakse nii keskkonna endasse kui ka RIA/MKM süsteemi 3.3.3. Kasutajakonto loomine Koodivaramusse ja kustutamine. Kasutajad loovad endale konto TARA autentimislahendust kasutades. Koodivaramu loob konto isikukoodi räsi alusel. Administraatoril peab olema võimalik kasutajakontosid kustutada ja blokeerida. 3.3.4. Objektide lisamine. Objekte saavad lisada ainult Sisuhaldurid ja Administraatorid. 3.3.4.1. Nimi (nt Riigi autentimisteenus TARA) – kohustuslik väli: 3.3.4.1.1. Nimi ei tohi korduda, ehk sama nimega ei tohi olla mitu objekti (sõltumata tühikutest ja suurtest/väikestest tähtedest) 3.3.4.1.2. Nimi on aluseks ka objekti URL'i võtmesõnale 3  3.3.4.2. Pilt (nt objekti logo): 3.3.4.2.1. Kasutaja saab lisada ise logo, mille suurim lubatud maht ja mõõtmed lepitakse kokku arenduse protsessis. 3.3.4.2.2. Kui kasutaja ei lisa ise logo siis lisatakse projekti esimesest tähest genereeritud pilt. 3.3.4.3. Põhikategooria – kohustuslik väli: 3.3.4.3.1. Software as a Service (SaaS üle API või veebikeskkonnana kasutatav teenus) 3.3.4.3.2. Kood (koodi repositooriumis - nt koodivaramu.eesti.ee või GitHub - olev kasutatav kood) 3.3.4.3.3. Jupp (jupivaramus või kuskil hoidlas kättesaadav binaartarkus, õpetatud mudel, dockeri image vms) 3.3.4.3.4. Must Kast (asutuse poolt pakutav digiriigi IT põhine teenus, mida saab kasutusele võtta muude kokkulepete teel, aga millel ei pruugi olla avalikku API't, avalikult levitatavat koodi vms) 3.3.4.3.5. võimalikud muud Administraatori poolt lisatavad põhikategooriad. 3.3.4.4. Komponendi/teenuse halduri kontaktinfo 3.3.4.4.1. Asutus (nt. SMIT) 3.3.4.4.2. E-mail 3.3.4.4.3. Telefon 3.3.4.4.4. Kommentaaride teavituse emaili aadress koos checkboxiga, kus määratakse kas soovitakse meili või mitte 3.3.4.5. Objektil on küljes 0..* linki. Linkidel toimub 24 tunni tagant lingi-kontroll, kas link on kehtiv. Mittekehtiva lingi puhul saadetakse keskkonna haldurile email 3.3.4.6. Nähtavus (avalik või piiratud ainult selle objekti sisuhaldurile) 3.3.4.7. Objektil on küljes 0..* kasutusjuhtu 3.3.4.7.1. Projekt (nt SKAIS2) 3.3.4.7.2. Lühikirjeldus 3.3.4.7.3. Link 3.3.4.7.4. Lisajal on võimalus lisada märksõnu. Kui kasutaja hakkab kirjutama märksõna, siis pakutakse talle jooksvalt hetkel olevaid. Kui märksõna on uus siis see lisatakse andmebaasi 3.3.4.7.5. Kommenteerimine ja hinnangud. Kasutajad saavad kommenteerida objekte ja jätta neile hinnanguid (hinnangu tüüp vajab selgitamist, 10p süsteem või 5p süsteem või thumbs-up/down). Kommentaar pole kohustuslik. Kui kommentaar lisatakse siis on koodi omanikul võimalus tellida sisestatud e-mailile teavitus selle kohta. 3.3.5. Otsingusüsteem 3.3.5.1. Otsingusüsteem otsib ja kuvab klikitavaid vasteid järgmiste andmete pealt, sorteerides vasteid vastavalt tabamuste arvule: 4  3.3.5.1.1. Nimi 3.3.5.1.2. Kirjeldus 3.3.5.1.3. Kasutusjuht 3.3.5.1.4. Silt (ehk kui otsid "mikroteenus", siis leiad need objektid, millel on küljes silt mikroteenus ja eespool on need vasted, millel on mikroteenus ka kirjelduses ja nimes - mida rohkem seda eespool) 3.3.5.1.5. Kategooria (vt eelmine näide) 3.3.5.1.6. Märksõnad 3.3.5.2. Otsingusüsteemil peab olema valmisolek tulevikus teha otsepäringuid teistes keskkondades. 3.3.5.2.1. Otsingu komponent on arendatud eraldiseisvalt, mis töötab üle API ja on paigaldatud keskkonna külge. Selle komponendi otsingu allikas on esimeses etapis ainult funktsioonide register vastavalt eelmisele punkt 1-le. 3.3.5.2.2. Otsingusüsteemile on võimalik lisada juurde teisi otsinguallikaid, mille vasteid suudaks otsingusüsteem välja näidata. Kui sama otsingukomponent paigaldada teise veebikeskkonda (näiteks digiriik.eesti.ee) ja seda seal vastavalt konfigureerida, siis oleks võimalik teha otsinguid üle mitme süsteemi korraga. Ehk funktsioonide registri otsingusüsteem suudaks otsida nii registrist endast, kui ka teistest sama komponentidega süsteemidest, kui funktsioonide registri otsingule anda ka teisi allikaid. 3.3.5.2.3. Teistest allikatest vastete leidmisel ning siis neile klikkimisel suunatakse kasutaja tolle allika keskkonda. 3.3.6. Meetrika 3.3.6.1. Kasutajaga seoses talletatakse meetrikat: 3.3.6.1.1. Millal kasutaja loodi 3.3.6.1.2. Millal ta viimati süsteemi külastas 3.3.6.1.3. Mitu unikaalset päeva on ta süsteemi külastanud (ehk talletada nii counter, kui ka viimane külastamise päev, kui see on muutunud, tõsta counterit) 3.3.6.2. Objektiga seoses talletatakse meetrikat 3.3.6.2.1. Millal objekt lisati kataloogi 3.3.6.2.2. Kui tihti on objekti vaadatud (per kasutaja, per unikaalne päev). 3.3.6.2.3. Kui palju on objektiga seotud linkidel klikitud. (unikaalsest allikast max 1 klikk viie minuti jooksul) 3.3.6.2.4. Objekti avamisel kuvatakse välja lisaks põhi-infole veel: 3.3.6.2.5. Hinnangute ja kommentaaride arv 3.3.6.2.6. Kasutusjuhtude arv 3.3.6.2.7. Objekti enda meetrika (üleval eelmised punktid) 3.3.6.3. Otsinguga seoses talletatakse meetrikat 3.3.6.3.1. Otsingu märksõnad 5  3.3.7. Taaskasutatavus. Kogu keskkond on arendatud võimalikult modulaarselt ja koodi taaskasutamise seisukohast. Iga lehe funktsionaalsus peab olema eraldi seisev komponent ja lihtsalt taaskasutatav koos taaskasutamise juhendiga. 3.3.8. Ligipääsetavus. Lehekülg peab toetama kahte keelt (eesti ja inglise keel). Peab olema võimalus lisada ka teisi keeli. 3.3.8.1.1. Kasutajaliides peab olema juurdepääsetav ning vastama vähemalt EN 301 548 V3.2.1 (2021-03) nõudele 3.3.8.1.2. Keskkond peab toetama masintõlget 3.3.9. Kujundus 3.3.9.1. Keskkonna kujundus peab olema kaasaegne. 3.3.9.2. Platvormi avaleht on niiöelda single-page navigaator/explorer. Leht võiks kasutajakogemuse osas minimaalselt võtta eeskuju järgnevast lahendusest: https://sourceforge.net/directory/os:windows/ 3.3.9.3. Avalehel saab vaadata tervet nimekirja tunnustele vastavalt filtreeritavaid objekte. 3.3.9.4. Objektile klikkides on objektil unikaalne SEO-sõbralik URL, mis automaatselt genereeritud objekti nimest. 3.3.9.5. Objekti vaates näidatakse välja objekti täisinfot. 3.3.9.6. Keskkond peab olema arendatud kasutades Veerat 3.3.10. Avaandmed 3.3.10.1. Süsteem peab välja andma avaandmeid API'na sidudes järgmiseid andmeid: 3.3.10.1.1. Objekti meetrika väljastamine (vt funktsionaalsus pt 7) avaandmetena (JSON formaat, API) 3.3.10.1.2. Otsingusüsteemi API käitub ka kui kataloogi (avalike) andmete väljastaja. 3.3.10.2. Tehniliselt on võimalik ka otsingusüsteemi API panna sisaldama objektide meetrikat. 3.3.11. Avaleht 3.3.11.1. Administraatoril peab olema võimalus kuvada diagramme 3.3.11.2. Kuvatakse Top 5 kõige vaadatumat/lingile klikitud koodi 3.3.11.3. Vasakul kuvatakse kõiki kategooriaid 3.3.12. Teavitused 3.3.12.1. Kasutaja saab lisada ennast e-maili teavituse listi. Kui koodi omanikul on vaja teavitada kõiki kasutajaid mingitest muudatustest, siis tal on võimalik võtta ühendust kõigiga, kes seda koodi jälgivad 3.3.12.2. Kui koodi omanik on riigiasutus ja avastab turvavea, siis on võimalik saata teavitused teavitused teistele IT Majadele eraldi ja kõigile koodi jälgijatele 4. Arenduse etappide ja teostatavate tööde kirjeldus 6 4.1. I etapp - Detailanalüüs, prototüüp ja disain. 4.1.1. Detailanalüüsi käigus tuleb välja selgitada funktsionaalsused ja vajadused tehnilises kirjelduses esitatud nõuetest ja teistest UX headest tavadest ning teha kasutajaliidese prototüüp (html + js + css), mis võetakse II osas aluseks. Loodud kasutajaliidese prototüübi osas on arvestatud kasutajate tagasisidega. 4.1.2. Esimese etapi kestvus on kuni 2 kuud. 4.1.3. I etapi Tulem on: 4.1.3.1. Disain – kasutades Veerat ja konsulteerides Tellijaga on keskkonna disain valmis ja kinnitatud 4.1.3.2. Prototüüp – koos hankes esitatud nõuetega, Tellijaga konsulteerides ja toetudes UX ja UI headele tavadele on valmis klikitav prototüüp 4.1.3.3. Analüüs – Töövõtja on toetudes hanke dokumentidele ja konsulteerides Tellijaga valmis saanud ja kinnitanud arenduse analüüsi dokumendid, millest lähtutakse keskkonna arendusel 4.1.3.4. Ettepanekud - Töövõtja on teinud Tellijale kõik ettepanekud ja täiendused arendatavale keskkonnale, mille Tellija peab üle vaatama, kinnitama või kehtetuks tunnistama 4.1.3.5. Taaskasutamise arhitektuur – Töövõtja tutvustab Tellijale, kuidas seda projekti saavad teised lihtsalt taaskasutada ja kuidas on taaskasutus ülesehitatud 4.1.3.6. I etapi tulemi tutvustamine projekti juhtrühma koosolekul; 4.1.3.7. I etapi tegevuste dokumentatsioon koos lühikese kokkuvõtliku põhjendusega ja dokumenteeritud ettepanek koos esialgse kontseptsiooni edasiarendamise ajakavaga ning I etapi tulemite tutvustamise ettekanne slaididena. 4.1.4. I etapi Tulemi saavutamiseks teostab Töövõtja järgmised tegevused: 4.1.4.1. Tutvub Tellija poolt koostatud e-teenuse disainimise protsessi kirjeldusega, sh. etappide ja sammudega läbi teenuse elutsükli ning esitab omapoolsed ettepanekud protsessi, etappide ja tegevuste täiendamiseks; 4.1.4.2. Teostab tehnilise ja ärilise analüüsi ja kinnitab tellijaga; 4.1.4.3. Koostab taaskasutamise arhitektuuri dokumendi ja kinnitab tellijaga. Tellija juhib tähelepanu, et dokumentatsiooni keeleline korrektsus on Töös väga oluline; 4.1.4.4. Analüüsi käigus koostatud dokumendi alusel teeb prototüübi; 4.1.4.5. Vastavalt prototüübile ja tagasisidele koostab keskkonna disaini; 4.1.4.6. Tutvustab viisi kuidas saaks pidada meetrikat mingi koodi populaarsuse või kasutamise üle; 4.1.4.7. Tutvustab I etapi tulemeid projekti koosolekul (vajalikud materjalid saadab juhtrühmale 3 tööpäeva ette) ning annab vajalikku lisateavet 1 nädal enne l etapi lõppu; 4.1.4.8. Täiendab vajadusel tulemeid juhtrühmalt saadud tagasiside põhjal; 4.1.4.9. Annab Tellijale üle I etapi Tulemi. 4.2. II etapp - Keskkonna arendus, dokumenteerimine, koolitus, testimine ja andmete migratsioon. 7 4.2.1. II osas realiseerib Töövõtja vastavalt valminud ja kinnitatud detailanalüüsile kõik arendustööd täisfunktsionaalse infosüsteemi juurutamiseks. Arendustööde käigus tuleb üle tuua hetkel olevast koodivaramust välja valitud andmekogud. 4.2.2. Teise etapi pikkus on kuni 5 kuud 4.2.3. II etapi Tulem on: 4.2.3.1. keskkonna täielik sisu, mis sisaldab uute koodi juppide linkides lisamist kategoriseerimist, esitamist, analüütika kasutamist ja vajalike diagrammide koostamist ja esitamist; 4.2.3.2. veebileht koos vajalike visuaalide ja funktsionaalsustega sisu esitamiseks ja kasutamiseks; 4.2.3.3. keskkonna ja kasutajate haldamiseks ja uuendamiseks vajalik tehniline teave ja soovitused; 4.2.3.4. äripaneeli kontseptsiooni arendamise ettepanekud kirjalikult vormistatud kujul; 4.2.3.5. online teavitusüritus II etapi Tulemi tutvustamiseks; 4.2.3.6. projekti ja selle tulemuste lühikokkuvõte; 4.2.3.7. läbi on viidud vajalikud testid UX, UI ja turvatestid; 4.2.3.8. kasutajatel on võimalik jätta kommentaare koodide juurde ja koodiomanikul neile vastata; 4.2.3.9. koodi lisajal on võimalik tellida teavitused meilile kui keegi lisab kommentaari; 4.2.3.10. keskkond on võimalik teha mitmekeelseks aga selle etapi tulem on ainult eesti keelne keskkond; 4.2.3.11. automaatne lingikontroll; 4.2.3.12. koodi lisajal on võimalus lisada märge, kas turvaaudit on tehtud ja mis tasemele. 4.2.4. II etapi Tulemi saavutamiseks teostab Töövõtja järgmised tegevused: 4.2.4.1. Töötab välja koodi linkimise ja lisamise tööriista täieliku sisu; 4.2.4.2. Arendab välja veebivaadete kasutajaliidese ja kasutajakogemuse (s.t. protsessi, teemade ja praktiliste materjalide vahelise hea sidususe ja navigeerimisloogika) ning vajalikud visuaalsed ja funktsionaalsed lahendused selle esitamiseks; 4.2.4.3. Viib keskkonna väljaarendamise ja kasutajatestimiste käigus läbi vajalikud UI ja UX testid (sh kasutaja navigeerimise test); 4.2.4.4. Lisab võimaluse koostada ja lisada diagramme ja muid andmekuvamise viise avalehel; 4.2.4.5. Osaleb äripaneeli kontseptsiooni testimisel (kutsub kokku Tellija), milles hindab äripaneeli toimimist ning mille tulemusena teeb Töövõtja omapoolsed ettepanekud keskkonna ja äripaneeli kontseptsiooni täiendamiseks; 4.2.4.6. Koostab soovitused ja kirjeldab tehnilise teabe, mis on vajalikud keskkonna haldamiseks ja uuendamiseks; 4.2.4.7. Koostab keskkonna lõppversiooni tekstide ingliskeelse tõlke; 4.2.4.8. Tutvustab II etapi tulemeid, sh keskkonna toimimist, projekti juhtrühma koosolekul (vajalikud materjalid saadab juhtrühmale 3 tööpäeva ette) ja annab vajalikku lisateavet; 8  4.2.4.9. Lisab kogu projekti taaskasutamise eesmärgil korrektselt koodivaramusse; 4.2.4.10. Paneb keskkonna üles riigipilve; 4.2.4.11. Annab Tellijale üle II etapi Tulemi. Tellija juhib tähelepanu, et dokumentatsiooni keeleline korrektsus on antud Töös väga oluline 4.3. Dokumenteerimine ja nõuded dokumentatsioonile 4.3.1. II etapis dokumenteerib Töövõtja kõik tööd ning üleantava lahendusega peavad kaasnema järgnevad dokumendid: 4.3.1.1. Detailanalüüs; 4.3.1.2. Kommenteeritud lähtekood; 4.3.1.3. Süsteemi kasutusjuhend; 4.3.1.4. Süsteemi administreerimise juhend (sh paigaldamise ja konfigureerimise juhend ning varunduse ja taaste protseduuride kirjeldus); 4.3.1.5. Arhitektuuridokument. 4.3.1.6. Koodi taaskasutamise juhend. 4.4. Kasutajate koolitus. Töövõtja viib läbi süsteemi peakasutajate koolitused ning koolitustele eelnevalt valmistab ette ja teeb kõigile osapooltele kättesaadavaks koolitusmaterjalid. Koolitusmaterjalid ja kasutusjuhend peavad olema kättesaadavad. Või koostab detailse kasutusjuhendi ja edastab selle tellijale. 4.5. Testimine. Infosüsteemi kõik üleantavad versioonid peavad enne Tellijale üle andmist olema Töövõtja poolt testitud. Testide läbimine on eelduseks tööde vastuvõtmisel. 4.5.1. Testida tuleb kõikide oluliste funktsionaalsete ja mittefunktsionaalsete nõuete täidetust. 4.5.2. Töövõtja koostab testiplaani ja testilood ning testimise lõppedes annab need koos testimise raportiga üle Tellijale. 4.5.3. Tellija meeskond testib seejärel üleantavat versiooni ning koostab Töövõtjale aruande. 4.5.4. Süsteemi mittevastavuse korral parandab Töövõtja ilmnenud vead, täiendab dokumentatsiooni ning paigaldab ja annab Tellijale üle uue parandatud versiooni koos täiendatud dokumentatsiooniga. 4.5.4.1. Vigade parandamise ja uue versiooni paigaldusega seotud kulud katab Töövõtja. 5. Nõuded keskkonnale 5.1. Arenduse käigus peab arendaja veenduma järgmiste punktide täitmises: 5.1.1. Keskkond peab olema kasutamiseks loogiline, lihtne ja intuitiivne: 5.1.2. Keskkonda saab logida tavakasutaja ainult TARA kaudu; 5.1.3. Keskkonna halduril peab olema võimalus ka logida keskkonda kasutajanime ja parooliga; 5.1.4. disainimise etapid on loogilises järjekorras ja vajaduse korral on välja toodud etappide vaheline sõltuvus (millise etapi läbimine on teise etapi eeldus); 5.1.5. välja on toodud peamised soovitused ja nõuanded, millega etapis arvestada; 9  5.1.6. kui kasutaja suunatakse keskkonnast välja mingile muule aadressile mis ei ole koodivaramu, siis kuvatakse talle teade sellest millest edasisest kuvamisest on võimalik loobuda; 5.1.7. kasutaja peab vajaliku info leidmiseks tegema võimalikult vähe klikke; 5.1.8. Esitatavad objektid tuleks vormistada ühtlustatud mallile; 5.1.9. Kasutajad kelle õigused on sisuhaldur ja kõrgem saab lisada läbi keskkonna kasutajaliidese uusi objekte; 5.1.10. Kasutatavate ja mõistlikult üles ehitatud keskkonna ühe näitena võib tuua Sourceforge (https://sourceforge.net/directory/), milles on juhised ja kasutuslihtsus omavahel hästi seotud; 5.1.11. Avalehel kuvatavad top taaskasutatavate koodide nimekiri ja erinevad graafilised andmeedastamise viisid peavad olema automaatselt uuenevad. Administraator saab valida milliseid graafikuid keskkond kuvab. Töövõtja võib lisaks pakkuda lahendusi või soovitusi, kuidas kasutajateni jõuaks kiiresti info. 6. Nõuded prototüübile ja tehnilisele lahendusele 6.1. Klikitav prototüüp luuakse disaini tarkvara(de) abil, mis võimaldab luua klikitavate high- fidelity ekraani piltide abil terviktöövooge desktop, tahvelarvuti ja mobiili vaates (nt Figma). 6.2. Prototüübi tööfailid antakse Tellijale üle. Lisaks jätab Töövõtja klikitava prototüübi Tellijale kättesaadavaks ja kasutatavaks 2 aasta jooksul Töö Tulemi vastuvõtmisest. 6.3. Töövõtja võimaldab prototüüpi kasutada nii, et Tellijal või intervjuus osaleval kolmandal osapoolel ei tule selleks teha lisakulutusi, hankida täiendavat tarkvara või kasutusõigust. 7. Nõuded veebilehe arendamisele 7.1. Tellija tellib sisse Funktsioonide registri veebilehe esimese etapi arendamise, mille eesmärk on pakkuda veebiplatvormi ja tööriista lahendusele ning tagada valmisolek Funktsioonide registri veebilehe edasiarenduseks lähtuvalt punktis 4.4.2.-4.4.4. kirjeldatud tehnilistele nõuetele ja soovitud funktsionaalsustele. 7.2. Veebilehe platvormi valikul ja arendamisel arvestatakse järgmiste tehniliste nõuetega: 7.2.1. Kasutajaliides peab olema juurdepääsetav ning vastama vähemalt tasemele EN 301 548 V3.2.1 (2021-03); 7.2.2. Kasutajaliides peab olema kasutatav järgmiste veebibrauseritega: Chrome, Safari, Firefox ja Microsoft Edge; 7.2.3. Kasutajaliides peab ühilduma täielikult HTML5, CSS3 ja Javascript kehtivate standarditega ning kõikide nõutud veebilehitsejate versioonidega; 7.2.4. Rakenduse kasutajaliides peab kohanduma erinevate ekraanivaadetega (arvuti, tahvel ja mobiiltelefon); 7.2.5. Rakenduse kasutajaliides peab olema tehtud lähtudes värskeimatest UX trendidest; 10  7.2.6. Kasutajaliidese loomisel tuleb lähtuda VEERA disainiraamistikust (veera.eesti.ee) ja Valitsusportaali disainiraamistikust kombineeritud lahendusena, mille rakendamiseks vajalikud täpsustused lepitakse Tellijaga kokku töö käigus; 7.2.7. Veebileht peab toetama ühte keelt (eesti keel). Arenduse käigus peab olema arendatud võimekus lihtsalt lisada teisi keeli vastavalt tellija nägemisele; 7.2.8. Keskkond peab toetama masintõlke võimekust; 7.2.9. keskkond peab vastama E-ITS v2022 infosüsteemide küberturvalisuse nõudele; 7.2.10. pilvekompetentsid ja pilvepraktikad ja use-cased; 7.2.11. koodivaramu ja tulevase artifactory kasutamise praktikad; 7.2.12. avaandmete kasutamise praktikad ja use-cased; 7.2.13. koosvõimeraamistik; 7.2.14. arhitektuuri tulevikuvisioon; 7.2.15. kratijupid ja nende kasutamise võimalused, use-case'd ja põhimõtted; 7.2.16. andmete kasutamine, põhimõtted ja andmeteadus; 7.2.17. andmehalduse praktikad; 7.2.18. jagada infot koostööprojektide kohta (keskkond tagab protsessi läbipaistvuse, kus kõigil osapooltel on võrdne võimalus osalemiseks). 7.3. Veebiplatvorm võimaldab järgmiste funktsionaalsuste arendamist hilisemas arendusetapis: 7.3.1. Küsimused ja vastused ning kommenteerimise/arutelu funktsionaalsus - mitmed küsimused, mida digiriigi eestvedajatelt küsitakse jäävad tihti e-mailidesse ja samu küsimusi küsitakse korduvalt. Mõned küsimused on ka tehnilised, näiteks X-tee turvaserveri liidestuste kohta, mis oleks väärtuslik avalikus ruumis avaldada. Küsimustele vastamine/kommenteerimine peaks olema võimalik. Sealhulgas peaks olema võimalik küsimuste vastuseid ja kommentaare jälgida (subscribe). 7.3.2. Idee-pank/probleemide-korje kasutajatel on võimalik kusagile keskkonnas jätta teateid keskkonna haldajale näiteks kui kasutaja avastab mingi bugi või soovitab mingit ettepanekut, et parandada keskkonna kasutusmugavust. 7.3.3. Digiriigi ristfunktsionaalsed nõuded inforuumis inimloetaval kujul - XML ja XSL stylesheet inimloetaval kujul ja automatiseeritult koodivaramust tõmmatud inforuumi automaatselt (ja uuenevalt). 8. Nõuded Töö teostamisele 8.1. Tellija eesmärgiks uue keskkonna arendamisel on pakkuda arendajatele keskset platvormi taaskasutatava koodi jagamiseks. Oodatava tulemina: 8.1.1. Tekib keskkonda kogu koodi juppe teenuseid ja muud taaskasutatavat koodi, mida avalike e-teenuste elutsüklis arvestada ja mida mõistavad kõik e-teenuste arendamise ja haldamisega seotud osapooled. 8.1.2. Arendajal (või teemast huvitatud isikul) tekib võimalus näha jagatud koodi või võimalus minna edasi detailsemat infot saama – kas siis koodivaramusse või lingi kaudu mujale. 11  8.2. Neid eesmärke silmas pidades analüüsib ja kasutab Töövõtja lisaks digiteenuste standardile vähemalt järgmisi juhiseid (Töövõtja võib soovi korral juhiste loetelu täiendada): 8.2.1. MKMi juhised otseste avalike teenuste korraldajatele1: 8.2.1.1. Juhised määruse „Teenuste korraldamise ja teabehalduse alused“ rakendajatele (2019); 8.2.1.2. Avalike teenuste kataloog, avalike teenuste kataloogi teenuste sisestamise ja haldamise juhend ning oluliste otseste avalike teenuste kvaliteedinäitajate esitamise juhis; 8.2.1.3. Sündmusteenuste analüüsi tulemid – Lõpparuanne, ptk 5 (2020); 8.2.1.4. E-teenuste disainimise käsiraamat; 8.2.1.5. Protsessianalüüsi käsiraamat;; 8.2.1.6. Kasutatavuse mõõdikute süsteem avaliku sektori tarkvarasüsteemidele (2014); 8.2.1.7. avaliku sektori e-teenuse projekti materjalid – Detailanalüüs ja kontseptsiooni väljatöötamine. Kokkuvõte, jagu Riskid (2014); 8.2.1.8. Klienditagasiside süsteemi pilootprojekti lõpparuanne ja soovitused (2014); 8.2.1.9. Riigi nõuete ja maksete infosüsteemide analüüs (2014); 8.2.1.10. Iseteeninduskeskkonna raamistik (2014) 8.2.2. Juhendmaterjal krattide hankimiseks (2019)2 8.2.3. Andmeteaduse projekti lõuend (2019) 8.2.4. MKMi juhised infosüsteemide arendajatele: 8.2.4.1. Riigi infosüsteemi semantilise koosvõime raamistik (2014)3 8.2.4.2. Riigi infosüsteemi koosvõime raamistik (2007–2012)4 8.2.4.3. Digiriigi ristfunktsionaalsed nõuded5 8.2.4.4. Masinõppe projektiks valmistumine: kontroll küsimustik (2020)6 8.2.5. Juhised avalike teenuste IKT-projektide rahastuse taotlejatele: 8.2.5.1. Taotluse vormistamise juhend. Taotlusele lisatav vorm (toetused avalike IKT teenuste arendamiseks)7 8.2.5.2. Taotlus (toetused avalike teenuste koosvõime loomiseks)8 8.2.6. Andmekaitse Inspektsiooni juhised9: 8.2.6.1. Andmekaitse ja andmeturbe eneseabi küsimustik (2013); 8.2.6.2. Andmekogude juhend – 4. jagu „Juurdepääs andmekogus olevatele andmetele“ (2016); 8.2.6.3. Isikuandmete töötleja üldjuhend (2018, uuendatud 2019); 1 https://www.mkm.ee/et/tegevused-eesmargid/infouhiskond/infouhiskonna-teenused 2 https://www.kratid.ee/juhendmaterjalid 3 https://www.mkm.ee/sites/default/files/riigi_infosusteemide_semantilise_koosvoime_raamistik.pdf 4 https://www.mkm.ee/et/riigi-infosusteemi-koosvoime-raamistik 5 https://koodivaramu.eesti.ee/e-gov/cfr 6 https://www.kratid.ee/juhendmaterjalid 7 https://www.ria.ee/et/struktuuritoetused/2014-2020/avalikud-teenused/voor-valitsusasutuste-IKT.html 8 https://mkm.ee/et/viited 9 https://www.aki.ee/et/juhised 12  8.2.6.4. Suurandmed ja privaatsus (2017). 8.2.7. Riigikontrolli „E-harta ehk Igaühe õigused e-riigis“ (2018)10 8.2.8. Õigusaktid ja muud materjalid: 8.2.8.1. Vajaduse korral kasutab Töövõtja asjaomaseid õigusakte (sh vajadusel ka inglise keeles), nagu näiteks avaliku teabe seadus, isikuandmete kaitse seadus, valitsuse määrus „Teenuste korraldamise ja teabehalduse alused“. Eesti õigusaktide eesti- ja ingliskeelsed tekstid on kättesaadavad aadressil https://www.riigiteataja.ee 8.2.8.2. Vajaduse korral kasutab Töövõtja ka Andmekaitse Inspektsiooni kodulehel https://www.aki.ee/et olevaid muid suuniseid jaotises „Eraelu kaitse“, Riigi Infosüsteemi Ameti juhendeid riigi infosüsteemi ja küberturvalisuse küsimustes https://www.ria.ee/et/ametist/juhendid.html ning asjaomaseid Euroopa Liidu õigusakte nagu näiteks andmekaitse üldmäärus ja eIDAS määrus (kättesaadavad aadressil https://eur-lex.europa.eu/homepage.html?locale=et). 8.2.8.3. Vajaduse korral ja vastavalt oma valikule kasutab Töövõtja erinevaid teenusedisaini juhendmaterjale ja soovitusi, näiteks: 8.2.8.3.1. Riigikantselei innovatsiooni rakkerühma loodud veebileht avalike teenuste disainimiseks https://teenusedisain.info/ 8.2.8.3.2. Teenusedisaini standardid teistest riikidest https://platformland.github.io/government-service-standards/data/service- standards/ 8.2.8.3.3. Digital Services Playbook (USA) https://playbook.cio.gov/ 8.2.8.3.4. Mõne avaliku sektori asutuse teenusedisaini protsessi juhised (edastab Tellija); 8.2.8.3.5. Muud asjakohased materjalid. 8.2.8.3.6. Analüüsitavate juhiste, õigusaktide ja muude materjalide lõplik loetelu kooskõlastatakse Tellijaga. 9. Nõuded Töö dokumenteerimisele 9.1. Töövõtja peab Töö käigu ja Töö tulemid eesti keeles dokumenteerima, sealjuures peab Töövõtja tagama Töö dokumenteerimise tehnilise toe (koguma ja dokumenteerima Tellija juhtrühma ja projektirühmade ning Töö Tulemi saavutamiseks vajaliku sisendi). 9.2. Dokumentatsioon peab olema ühetaoliselt vormistatud ning lihtsalt loetav. Vajadusel kaasab Töövõtja projekti dokumentatsiooni koostamiseks tehnilise tööjõu. 9.3. Dokumentatsiooni keeleline korrektsus on antud Töös väga oluline. 9.4. Vahearuanded, memod, protokollid allkirjastab Töövõtja hiljemalt iga etapi lõpus ja esitab allkirjastatult koos aktiga. 10 https://www.riigikontroll.ee/Riigikontrollipublikatsioonid/Muudpublikatsioonid/Eharta/tabid/305/language/et- EE/Default.aspx 13  9.5. Töö raames tehtud tegevused, materjalid ja teostatud Töö tuleb tähistada vastavalt Vabariigi Valitsuse määrusele 12.05.2022 nr 54 „Perioodi 2021–2027 ühtekuuluvus- ja siseturvalisuspoliitika fondide vahendite andmisest avalikkuse teavitamine“11 10. Nõuded Töö teostamisele 10.1. Töövõtja tagab Töö teostamiseks ja selle tulemite saavutamiseks vajaliku projektimeeskonna koosseisu. 10.2. Töövõtja tagab ühtse metoodika kasutamise, juhendab ja teostab Töö tegevusi ning saavutab kokkulepitud tulemused. 10.3. Töövõtja ülesanne on Töö teostamise ja selle tulemite tagamine vastavalt lepingu tingimustele. Töö teostamisel tagab Töövõtja ülesannete tähtaegse täitmise vastavalt hankelepingule, plaanides ja rakendades võimalike riskide maandamismeetmeid. 10.4. Töövõtja loob vajadusel Tööde teostamise eesmärgil projektirühmad. Töövõtja projektijuht korraldab projektirühmade üld-, teemapõhiseid ja erakorralisi koosolekuid: valmistab ette päevakava ja vajalikud töömaterjalid koostöös ja kooskõlastatuna Tellija projektijuhiga, juhib koosolekuid, korraldab protokollimise ja juhtrühmas juhtrühma liikmete vastuvõetud otsuste täitmise. 10.5. Töövõtja kutsub vastavalt vajadusele kokku ja protokollib hankelepingu täitmisel läbiviidavad koosolekud ja kohtumised ning edastab protokollid kolme tööpäeva jooksul Tellijale kooskõlastamiseks. Töövõtja koostab toimunud koosolekute kohta protokollis kokkuvõtte (olulisemad töökoosolekute tulemused, tekkinud probleemid koos lahendustega, plaanid järgmisteks töökoosolekuteks). 10.6. Koosolekute korraldamisel organiseerib Töövõtja kõik selleks vajaliku, nt tehnika ja kohvipausid, osalejate registreerimise, protokollimise jm. Töövõtja organiseerib koosolekute ruumid, välja arvatud juhul, kui Tellijaga on kokku lepitud teisiti. Tellija projekti juhtrühma koosolekud viiakse läbi Tellija ruumides. Vajadusel ja kokkuleppel Tellijaga viiakse koosolek läbi videosilla vahendusel. 10.7. Avakohtumine Töövõtjaga toimub Tellija ruumides või virtuaalselt või Töövõtja ruumides esimesel võimalusel peale lepingu sõlmimist (kohtumise aeg ja koht lepitakse eelnevalt kokku). 10.8. Töövõtja edastab Tellijale iganädalase memo nädala jooksul teostatud Tööga seotud tegevuste ning järgmise nädala tööplaani kohta (memo esitamise aeg lepitakse Töövõtjaga Tellija ja Töövõtja esimesel kohtumisel kokku). 10.9. Projekti lõppedes esitab Töövõtja kogu projekti dokumentatsiooni Tellijale. 11. Tellija ja Töövõtja koostöö 11.1. Tellija projekti juhtrühma liikmed määrab Tellija. Tellija projekti juhtrühm ja iga Töö etapi jaoks Töövõtja poolt (vajadusel) loodavad projektirühmad on Töövõtja partnerid. 11.2. Tellija on Tööde teostamisel aktiivne koostööpartner. 11 https://www.riigiteataja.ee/akt/117052022012 14  11.3. Tellija projekti juhtrühm jälgib hankelepingu tähtajalist täitmist, vaatab üle hankelepingu etappide tulemid ning kinnitab tulemite vastuvõtmise. 11.4. Tellija projekti juhtrühm kinnitab tulemused enne nende vastuvõtmist Tellija poolt. 11.5. Töökoosolekud Tellija ja Töövõtja vahel toimuvad üks kord kahe nädala jooksul ja vajaduse korral sagedamini. Töökoosolekud Tellija projekti juhtrühmaga toimuvad vastavalt vajadusele, kuid kindlasti enne iga etapi tegevuste vastuvõtmist. 11.6. Dokumentide ja koosolekumaterjalide haldamiseks kasutatakse Tellija poolt tagatud Confluence projektikeskkonda. 11.7. Kõik koosolekud protokollib Töövõtja, protokolli allkirjastab Töövõtja ning need tehakse Tellijale ja projekti juhtrühmale kättesaadavaks projektikeskkonnas. 11.8. Mõlema poole projektijuhid vastutavad enda organiseeritud koosolekute planeerimise, kokkukutsumise ning ettevalmistamise eest. 11.9. Teadete edastamine ning Tööde üleandmine toimub vastavalt lepingule. 12. Projekti tulemite vastuvõtmine 12.1. Enne lõplike tulemite vastuvõtmist peab Tellija kinnitama, et tulemid vastavad lähteülesandele. Pärast Tellija ja tööde üleandmise vastuvõtmise akti kinnitust tehakse väljamakse. 12.2. Tööd peavad olema jagatud kahte etappi – I ja II etapp – millest lähtutakse ka Tulemi eest tasumisel. Tööde eest tasutakse kahes etapis (sealjuures I etapi täitmise eest tasub Tellija 40% kogusummast ja II etapi eest 60% kogusummast). 12.3. Töövõtja annab Töö Tellijale üle etappide kaupa. I etapi Tööd antakse üle pärast nende teostamist Töövõtja esitatud ajagraafikust tulenevatel tähtaegadel ning lõpptulem (II etapp) Töövõtjaga sõlmitud töövõtulepingu (lisa 3) punktis 1.2 sätestatud tähtajal. 13. Garantii 13.1. Töövõtja garanteerib arendustöö vastavuse Lepinguga sätestatud tingimustele 24 (kahekümne nelja) kuu jooksul pärast Töö vastuvõtmist Tellija poolt (edaspidi Garantiiperiood). Kui töid võetakse hankelepingu raames vastu etappide kaupa, siis algab garantiiperiood viimase hankelepingus kokkulepitud etapi vastuvõtmise kuupäevale järgnevast kuupäevast ning garantii kehtib kõikidele hankelepingu raames teostatud töödele tervikuna. 13.2. Garantii kehtib ainult Tööle ning ei laiene koos Tööga kasutatavatele toodetele ja Tööst Tellija või kolmanda isiku poolt tehtud töötlustele 14. Mittefunktsionaalsed ja tehnilised nõuded Nõude kirjeldus Selgitus Kategooria 15 Kui rakendus eeldab kasutaja veebibrauseris skriptide käivitamist, kuid kasutatav skriptimiskeel pole kasutaja brauseris lubatud Platvorm või toetatud, tuleb lõppkasutajale kuvada arusaadav veateade. Rakenduse kasutajaliides peab olema juurdepääsetav ning vastama vähemalt EN 301 Kasutajaliides 548 V3.2.1 (2021-03). Rakenduse kasutajaliides peab olema kasutatav järgmiste veebibrauseritega: Chrome, Safari, Kasutajaliides Firefox ja Microsoft Edge. Rakenduse kasutajaliides peab ühilduma täielikult HTML5, CSS3 ja Javascript kehtivate Kasutajaliides standarditega ning kõikide nõutud veebilehitsejate versioonidega. Rakenduse kasutajaliides peab kohanduma erinevate ekraanivaadetega (arvuti, tahvel ja Kasutajaliides mobiiltelefon). Rakenduse kasutajaliidese disainiotsused tuleb Kasutajaliides tellijaga kooskõlastada. Rakenduse kasutajaliides peab olema tehtud Kasutajaliides lähtudes värskeimatest UX trendidest Tellija edastab stiiliraamatu ja sellega seotud disani näited. Rakenduse kasutajaliidese loomisel tuleb https://github.com/e-gov/cvi Kasutajaliides kasutada Veerat https://e- gov.github.io/cvi/?path=/story/intr o--page Rahuoluküsitlus peab järgima Rakenduse kasutajaliidesele tuleb lisada soovitusindeksi (Net Promoter Kasutajaliides teenuse rahuloluküsitluse link Score) metoodikat. Rakendus peab töötama veebibrauseritega, mis eID toetavad ID-kaarditarkvara 2 viimast versiooni 16 Rakendus peab kasutama kasutaja https://e-gov.github.io/TARA- tuvastamiseks keskset TARA eID Doku/ autentimisteenust https://www.ria.ee/et/riigi- Rakendus peab lähtuma ID kaardi, mobiil-ID, infosusteem/elektrooniline- TARA integreerimisel Riigi Infosüsteemi identiteet-eid/sumboolika.html ja eID Ameti disaininõuetest https://e-gov.github.io/TARA- Doku/Arikirjeldus Arendusprojekti juhtimiseks ja projekti läbiviimiseks kasutatakse Tellija Arendustööde tellimused ja organisatsioon projektijuhtimistarkvara JIRA tarkvaravigade haldamine. (https://jira.mkm.ee) Arendusprojekti käigus loodav lähtekood korrektselt vormistatuna läbi organisatsioon koodihalduskeskkonnahttps://git.mkm.ee/proje ktinimi Arendusprojekti käigus loodavate binaarsete teekide hoidmiseks kasutatakse JFROG organisatsioon Artifactory lahendusthttps://artifactory.mkm.ee Arendusprojekti käigus loodav dokumentatsioon (analüüsidokumendid, kasutusjuhendid, arhitektuuri kirjeldused, organisatsioon paigaldusjuhendid jne) tuleb üle andahttps://confluence.mkm.ee/projektinimi Statistilisi parameetreid mõõdetakse Google Tellija annab omalt poolt vastava analüütika Analytics keskkonna kaudu. Google Analytics konto andmed Rakenduses loodud avaandmed avalikustatakse Täpne avaandmete koosseis REST JSON API teenusena, lisaks peavad avaandmed lepitakse kokku tellijaga olema toetatud XML ja CSV. 17  https://eur-lex.europa.eu/legal- content/ET/TXT/?uri=CELEX%3 A32016R0679 Rakendus peab olema kooskõlas isikuandmete infoturve kaitse regulatsiooniga https://www.riigiteataja.ee/akt/104 012019011 Rakenduse ja andmebaasi turvalisuse tagamiseks tuleb järgida Eesti https://eits.ria.ee/ infoturve infoturbestandardi praktikaid. Rakendus peab salvestama kõik paroolid ainult krüpteeritud kujul infoturve Kui ainult TARA autent jääb siis seda ei ole vaja Rakenduse ja kasutaja vaheline infovahetus infoturve tohib käia ainult üle HTTPS protokolli. Rakendus peab olema kirjutatud arvestades töödeldavatele andmetele määratud ISKE https://eits.ria.ee/ infoturve turvaklassi nõudeid. Loodavat infosüsteemi majutatakse Riigipilve keskkonda ning sellega tuleb arvestada https://riigipilv.ee/ infra arhitektuuri planeerimisel. Eelistatud on vabavaraliste andmebaaside platvormide kasutamine. nt PostgreSQL, infra MySQL, mongoDB Eelistatud on vabavaraliste otsingute kasutamine nt Apache Lucene, SOLR, infra Elasticsearch, MeiliSearch, Typesense Rakendusserverite ja andmebaasi teenuste jooksutamisel tuleb kasutada infra plokksalvestuskeskkonda. 18 Faililao loomisel eelistatakse https://www.riigipilv.ee/teenused/a objektsalvestuskeskkonna kasutamist S3 REST infra ndmesalvestuse-teenus API-ga. Rakenduse isikuandmete töötlemine peab olema kooskõlas isikuandmete kaitse andmekaitse seadusega 1. Rakendus on skriptiga paigaldatav ning paigaldamine ja taastamine toimub automatiseeritava skripti käivitamisega. 2. Rakendus koosneb mitmest Rakendus on pilvekõlbulik. DevOps sõltumatust instantsist. 3. Rakendus on automaatselt skaleeritav ja vajadusel kõrgkäideldav kahe asukoha vahel. 4. Rakenduse andmed on varundatavad ja varundatud. 19  Pakkuja ärisaladuse määramine 1. Pakkuja ärisaladuse ulatus RHS § 111 lg 5 kohaselt on pakkuja ärisaladuse piiritlemine pakkuja pädevuses. Trinidad Wiseman OÜ (edaspidi: pakkuja) avaldab, et käesolev pakkumus (sealhulgas pakkumuse lisad) ja pakkuja poolt muul viisil hankijale hankemenetluses avaldatud teave moodustab tervikuna pakkuja ärisaladuse. Pakkumus ja pakkumuse lisad ei moodusta pakkuja ärisaladust osas, milles pakkuja on käesoleva dokumendiga ärisaladuse sõnaselgelt välistanud. Kooskõlas RHS § 111 lg-ga 5 avaldab pakkuja, et pakkuja ärisaladuse hulka ei kuulu: a) pakkumuse maksumus ja osamaksumus osas, milles see on pakkumuste hindamise kriteeriumiks; b) pakkumuste hindamise kriteeriumitele vastavad pakkumust iseloomustavad numbrilised näitajad. Ärisaladusega hõlmatud teabe avalikustamine toob kaasa pakkuja subjektiivsete õiguste olulise riive, majandusliku kahju ning nõudeõiguse teabe avalikustaja vastu. 2. Ärisaladuseks määramise põhjendus Pakkuja ärisaladusena määratud teave vastab järgmistele kriteeriumitele: a) teave on saladus selles tähenduses, et see ei ole kogumis või üksikosade täpses paigutuses ja kokkupanus üldteada või kergesti kättesaadav nende ringkondade isikutele, kes tavaliselt kõnealust laadi teabega tegelevad; b) teabel on kaubanduslik väärtus selle salajasuse tõttu; c) pakkuja on teabe üle seaduslikku kontrolli omava isikuna võtnud kasutusele vajalikke meetmeid, et hoida seda salajas. Pakkuja ärisaladusena määratud teave vastab intellektuaalomandi õiguste kaubandusaspektide lepingu (nn TRIPS leping) artikli 31 lg-s 2 nimetatud teabele, mille osas peab pakkujal olema võimalus takistada tema seadusliku kontrolli all oleva teabe avaldamist teistele või selle omandamist või kasutamist teoste poolt pakkuja nõusolekuta. Pakkuja ärisaladusena määratud teave vastab ärisaladuse definitsioonile, mis on esitatud Euroopa Parlamendi ja nõukogu direktiivis (EL) 2016/943, milles käsitletakse avalikustamata oskusteabe ja äriteabe (ärisaladuste) ebaseadusliku omandamise, kasutamise ja avalikustamise vastast kaitset (direktiivi artikkel 2). Hankemenetluses osalemise eelduseks on pakkuja poolt teatud ärisaladuse avaldamine hankijale. Ärisaladuse hankijale teatavaks saamine ei vabasta hankijat direktiivi 2016/943 kohaselt talle ärisaladuse omaja poolt edastatud teabe konfidentsiaalsuskohustuse ja ärisaladuse kasutamise piirangu järgimise kohustusest. Direktiivi 2016/943 preambuli p-s 18 viidatakse, et konfidentsiaalsuskohustus hõlmab muuhulgas kohustusi seoses avaliku sektori hankijale hankemenetluste raames edastatud teabega, nagu on sätestatud Euroopa Parlamendi ja nõukogu direktiivis 2014/23/EL, Euroopa Parlamendi ja nõukogu direktiivis 2014/24/EL ning Euroopa Parlamendi ja nõukogu direktiivis 2014/25/EL. Riigihangete valdkonna direktiivid kinnitavad hankija kohustusi ärisaladuse kaitsel. Direktiivi 2014/24/EL artikli 21 kohaselt ei avalikusta avaliku sektori hankija talle ettevõtjate poolt edastatud konfidentsiaalsena märgitud teavet, sh tehnika- või ärialaseid saladusi ja pakkumuste konfidentsiaalseid aspekte. Piirang ärihuve kahjustavale andmete avaldamisele on esitatud ka direktiivi 2014/24/EL artikli 55 lg-s 3. Riigikohtu praktika kohaselt ei ole konkurentsiseaduse § 63 lg-s 1 esitatud ärisaladuse definitsioon väljaspool Konkurentsiameti haldusmenetlusi kohaldatav (vt nt Riigikohtu lahend kohtuasjas 3-1-1-46-09). Kahtluse vältimiseks kinnitab pakkuja siiski, et käesoleva dokumendi kohaselt ärisaladusena määratud teave vastab konkurentsiseaduse § 63 lg-s 1 nimetatud kriteeriumitele. Tegemist on teabega pakkuja äritegevuse kohta, mille avaldamine teistele isikutele võib pakkuja huve kahjustada. 3. Selgitus pakkuja poolt hankemenetluses täiendavalt esitatava teabe kohta Kui pakkuja ei ole edasises infovahetuses sõnaselgelt väljendanud vastupidist, on pakkuja poolt järgnevas hankemenetluses ja hankelepingu sõlmimisel esitatav teave pakkuja ärisaladus. Pakkuja märgib edasises teabevahetuses sõnaselgelt ära selle teabe või dokumendid, millele pakkuja ärisaladus ei laiene. 4. Selgitus hankija poolt hankemenetluses täiendavalt kogutava teabe kohta Pakkuja ei välista, et hankija kogub hankemenetluses pakkuja või pakkumuse kohta iseseisvalt täiendavat teavet. Mistahes hankija poolt täiendavalt kogutavale teabele, mis vastab direktiivi 2016/943 artiklis 2 esitatud ärisaladuse definitsioonile, laienevad hankemenetluses ärisaladuse käitlemise nõuded. Kui hankija asub seisukohale, et täiendavalt kogutav teave ei vasta mingis osas ärisaladuse definitsioonile ja selle avaldamine teistele isikutele või avalikkusele võib olla lubatud, taotleb pakkuja sellekohase kinnituse küsimist pakkujalt. Teabe avaldamine pakkuja kinnituseta ärisaladuse puudumise kohta võib tuua kaasa hankija poolt ärisaladuse avaldamise ja pakkuja subjektiivsete õiguste olulise riive. 5. Hankija kohustused ärisaladusega hõlmatud teabe käitlemisel Pakkuja poolt ärisaladuseks määratud teave ei kuulu avaldamisele teabepäringu alusel, samuti vaide- või kohtumenetluses. Hankija on kohustatud korraldama töö ja hankemenetluse läbiviimise viisil, mis välistab ärisaladuse avaldamise teistele isikutele. RHS § 47 lg 5 alusel jätab hankija ettevõtjate teavitamisel oma otsusest esitamata teabe, mille avaldamine rikuks ettevõtjate ärisaladust või kahjustaks konkurentsi. RHS § 83 lg 6 alusel jätab hankija hankelepingu sõlmimise teates märkimata teabe, mille avaldamine rikuks ettevõtjate ärisaladust või kahjustaks konkurentsi. RHS § 113 kohaselt ei avalikusta hankija pakkumuste sisu selles osas, mille pakkuja on pakkumuses ärisaladusena märkinud. RHS § 138 sätestab kõrgetasemelist kaitset nõudva ärisaladuse kaitseks erisused kontsessioonilepingu sõlmimisel. Avaliku teabe seaduse § 31 lg 3 kohaselt peab teabe üldiseks kasutamiseks andmisel olema tagatud ärisaladuse kaitse. Avaliku teabe seaduse § 35 lg 1 p 17 kohaselt on teabevaldaja kohustatud tunnistama asutusesiseseks kasutamiseks mõeldud teabeks teabe, mille avalikustamine võib kahjustada ärisaladust. Võimalikus vaidlustusmenetluses ja sellele järgnevas kohtumenetluses on hankijal kohustus tagada, et ärisaladusena määratud teave ei saaks teatavaks teistele menetlusosalistele ja kohustus esitada selleks vajalikud taotlused (nt taotluse esitamine menetluse kinniseks kuulutamiseks teatud dokumentide või teabe osas). Pakkuja on valmis hankija päringu korral andma ärisaladust puudutatavates küsimustes täiendavaid selgitusi.  HD Lisa 7 Teenuse üleandmise-vastuvõtmise akt (vorm) Teenuse üleandmise-vastuvõtmise akt Käesolev t eenuse üleandmise-vastuvõtmise akt (edaspidi akt ) on koostatud………… (edaspidi töövõtja ) juhatuse liikme ……… poolt ja esitatud Majandus- ja Kommunikatsiooniministeeriumile (edaspidi tellija ), tõendamaks, et töövõtja andis üle p oolte vahel ….. ……20 23 . aastal sõlmitud l epingu nr …. alusel osutatud t eenuse alljärgnevalt: ……………………………………………(üle antava(te) t eenus(t)e nimetus, detailne kirjeldus, ajavahemik, maht, täidetud tingimused, vajadusel viited l epingu punktidele vms) Tellija on t eenuse osutamise tulemustega tutvunud ning võtab vastu ja allkirjastab t eenuse osutamise tulemused, millega ühtlasi loetakse töövõtja poolt üle antud t eenus vastuvõetuks. Käesolev akt on aluseks töövõtja poolt tellijale kooskõlas l epingu punktiga … … arve esitamiseks summas …….. (summa sõnades) eurot. Käesolev a kt omab digitaalselt allkirjastatuna juriidilist jõudu ning edastatakse elektrooniliselt mõlemale p oolele. Töövõtja Tellija /allkirjastatud digitaalselt/ /allkirjastatud digitaalselt/ TÖÖVÕTULEPING nr 24.8-2/483-1 ERITINGIMUSED Majandus- ja Kommunikatsiooniministeerium, registrikood 70003158, asukoht Suur- Ameerika 1, Tallinn 10122, mida esindab Majandus- ja Kommunikatsiooniministeeriumi hankekorra alusel ettevõtlus- ja tarbimiskeskkonna asekantsler Sandra Särav kantsleri ülesannetes (edaspidi tellija), ja Trinidad Wiseman OÜ, registrikood 11244225, asukoht Meistri 14, Tallinn 13517, mida esindab juhatuse liige Marko Leppik (edaspidi töövõtja), keda edaspidi nimetatakse üheskoos ka pooled ja eraldi pool, sõlmivad töö teostamiseks lepingu (edaspidi leping) alljärgnevate tingimuste kohaselt: 1. Üldsätted 1.1. Leping sõlmitakse tellija korraldatud riigihanke „Funktsioonide registri keskkonna arenduse tellimine“ (viitenumber 265933) tulemusena ning vastavalt riigihanke alusdokumentidele ning töövõtja edukaks tunnistatud pakkumusele. 1.2. Lepingu moodustavad eri- ja üldtingimused koos lisadega kui konkreetsest lepingu sättest ei tulene teisiti. Eritingimused sisaldavad üldtingimuste täiendusi ja parandusi. 1.3. Lepingu dokumentide prioriteetsus on järgmine: eritingimused (I), lepingu lisad (II) ja üldtingimused (III). Vastuolude korral lepingu dokumentide vahel prevaleerib prioriteetsem dokument. 1.4. Leping on allkirjastatud digitaalselt. 1.5. Lepingu allakirjutamise hetkel on Lepingule lisatud: Lisa 1 – Riigihanke alusdokumendid (sh Hankedokument); Lisa 2 – Tehniline kirjeldus; Lisa 3 – Töövõtja pakkumus; Lisa 4 – Projektimeeskonna kinnitus; Lisa 5 – Pakkuja ärisaladus; Lisa 6 – Pakkumuse eelarve; Lisa 7 – Teenuse üleandmise-vastuvõtmise akt. 2. Lepingu ese ja töö teostamise tähtaeg 2.1. Lepingu esemeks on funktsioonide registri keskkonna arendus (edaspidi Töö), mida töövõtja kohustub tegema vastavalt lepingus ja lepingu lisades sätestatud tingimustele. Töö hõlmab Lisa 2 „Tehniline kirjeldus“ punktides 4.1. ja 4.2. kirjeldatud tulemit. 2.2. Töövõtja teostab punktis 2.1 nimetatud töö ja annab selle koos lähtekoodi ja analüüsi dokumentidega tellijale üle hiljemalt 28 nädala viimasel tööpäeval arvates lepingu sõlmimisest. 2.2.1. Hiljemalt 14 nädala viimasel tööpäeval arvates lepingu sõlmimist on teostatud I etapi tööd ning antud Tellijale üle I etapi tulem. 2.2.2. Hiljemalt 28 nädala viimasel tööpäeval arvates lepingu sõlmimist on teostatud II etapi tööd ning antud Tellijale üle II etapi tulem. 2.3. Töövõtja annab punktis 3.1.2.3 nimetatud aktidega punktis 2.1 kirjeldatud töö Tellijale üle kahes (2) etapis vastavalt lepingu punktidele 3.1.2.1 ja 3.1.2.2. 3. Poolte kohustused 3.1. Töövõtja kohustub: 3.1.1. Teostama punktis 2.1 nimetatud tööd; 3.1.2. Andma Tellijale teostatud töö üle vastavalt lepingu punktides 3.1.2.1 ja 3.1.2.2. toodud etappide kaupa: 3.1.2.1. Hiljemalt 14 nädala viimasel tööpäeval arvates lepingu sõlmimist on teostatud I etapi tööd ning antud Tellijale üle I etapi tulem, milleks on keskkonnale tehnilise analüüsi teostamine, prototüübi ja keskkonna disaini koostamine. I etapi tööde tulem peab vastama Lisa 1 „Hankedokument“ (edaspidi HD) punktile 8.3.1. ja Lisa 2 „Tehniline kirjeldus“ esitatud nõuetele. 3.1.2.2. Hiljemalt 28 nädala viimasel tööpäeval arvates lepingu sõlmimist on teostatud II etapi tööd ning antud Tellijale üle II etapi tulem, mis vastab HD punktis 8.3.2. ja Lisas 2 „Tehniline kirjeldus“ esitatud nõuetele ning tugineb I etapis läbiviidud analüüsile, infole, disainile ja tulemitele. 3.1.2.3. Pärast lepingu punktides 3.1.2.1 ja 3.1.2.2 nimetatud tööde ülevaatamist Tellija poolt vormistavad pooled üleandmise-vastuvõtmise akti (edaspidi akt), mis allkirjastatakse digitaalselt. 3.1.3. Arvestama töö teostamise käigus Tellija juhistega ning kõrvaldama Tellija nõudmisel esinevad puudused Tellija määratud tähtajaks. 3.2. Tellija kohustub: 3.2.1. Lepingu punktides 3.1.2.1 ja 3.1.2.2 nimetatud tööde tulemiga tutvuma 14 tööpäeva jooksul arvates tööde üleandmise kuupäevast ning teatama ülevaatamise tähtajale järgneva 5 tööpäeva jooksul Töövõtjale, kui tulem ei vasta lepingutingimustele. 3.2.1.1. Punktis 3.2.1. nimetatud tähtaja jooksul kirjaliku teate mittesaatmisel loetakse teostatud tööd Tellija poolt heakskiidetuks. 3.2.1.2. Puuduste esinemise korral või teostatud tööde lepingutingimustele mittevastavuse korral määrab Tellija mõistliku tähtaja puuduste kõrvaldamiseks. 3.2.2. Tellija otsustab lepingu punktis 3.1.2.1 nimetatud tehnilise analüüsi tulemi põhjal II etapi teostamise vajalikkuse punktis 3.2.1 nimetatud tähtaja jooksul. 3.2.2.1. Kui Tellija otsustab, et Töö järgmise etapiga ei jätkata (pärast I etappi), siis leping lõpetatakse ning Tellija tasub Töövõtjale akti alusel I etapis tehtud Töö eest ja II etapi töödega ei alustata, sh tasu ei maksta. 4. Tasu suurus, väljamaksmise tähtaeg ja kord 4.1. Tellija tasub Töövõtjale lepingus sätestatud töö teostamise eest maksimaalselt tasu summas 109 869,00 € (ükssada üheksa tuhat ja kaheksasada kuuskümmend üheksa eurot), millele lisandub käibemaks. 4.2. Tellija tasub Töövõtjale teostatud töö eest pärast selle vastuvõtmist punktis 2.3. nimetatud aktide alusel väljastatud arvete alusel kahes (2) osas: 4.2.1. I etapi tööde eest summas 43 947,60 € (nelikümmend kolm tuhat üheksasada nelikümmend seitse eurot ja kuuskümmend senti), millele lisandub käibemaks; 4.2.2. II etapi tööde eest summas 65 921,40 € (kuuskümmend viis tuhat üheksasada kakskümmend üks eurot ja nelikümmend senti), millele lisandub käibemaks. 5. Poolte volitatud esindajad  5.1. Tellija volitatud esindaja lepingu tingimuste täitmisel, täitmise kontrollimisel ja töö vastuvõtmisel on IT arhitektuuri ja taristu nõunik Indrek Kotkas, telefon +372 625 6393, e-post [email protected]. 5.2. Töövõtja volitatud esindaja lepingu tingimuste täitmisel ja täitmise kontrollimisel on Kadi Rosenthal, telefon +372 5599 5958, e-post [email protected]. 6. Muud sätted 6.1. Töövõtja kinnitab, et on üldtingimustega tutvunud elektroonselt riigihangete registris või Majandus- ja Kommunikatsiooniministeeriumi veebis aadressil: https://mkm.ee/ministeerium-uudised-ja-kontakt/ministeerium-ja- ministrid/hanketeated 6.2. Töövõtja on teadlik, et leping on avalik, välja arvatud osades, mis on märgitud AvTS-st tulenevatel alustel asutusesiseseks kasutamiseks. 6.3. Leping allkirjastatakse digitaalselt. Tellija Töövõtja /allkirjastatakse digitaalselt/ /allkirjastatakse digitaalselt/