Alusdokumentide kinnitamine riigihankes „Täitmisregistri hooldus- ja arendustööd“ (266570)

HINDAMISKRITEERIUMID JA HINNATAVAD NÄITAJAD Viitenumber: 266570 Hankija: Registrite ja Infosüsteemide Keskus (70000310) Hange: Täitmisregistri hooldus- ja arendustööd Pakkumuse maksumust hinnatakse - Ilma maksudeta Kriteeriumi kaalumise meetod - Osakaaludega Elektroonilist oksjoni kasutatakse: ei Jrk Nimetus Kirjeldus Tüüp / Osakaal Kogus Ühik Pakkuja nr hindamismeetod täidetav 1 Hooldus- ja arendustööde tunnihind Maksumus - 100 jah kogu raamlepingu perioodiks. vähim on parim Kokku: 100 Hindamismetoodika kirjeldus 1. Hooldus- ja arendustööde tunnihind kogu raamlepingu perioodiks. Madalaima väärtusega pakkumus saab maksimaalse arvu punkte. Teised pakkumused saavad punkte arvutades valemiga: "osakaal" - ("pakkumuse väärtus" - madalaim väärtus") / "suurim väärtus" * "osakaal". Koostatud 28.06.2023 13:07:09 1/1 https://riigihanked.riik.ee/rhr-web/#/procurement/ 6083860/general-info  1/2 VASTAVUSTINGIMUSED Viitenumber: 266570 Hankija: Registrite ja Infosüsteemide Keskus (70000310) Hange: Täitmisregistri hooldus- ja arendustööd PAKKUMUSE ESITAMINE Pakkumuse esitamisega kinnitab pakkuja kõigi riigihanke alusdokumentides esitatud tingimuste ülevõtmist. Tingimusliku pakkumuse esitamine ei ole lubatud. Küsimused ettevõtjale: 1. Kas ettevõtja saab kinnitada, et pakkumus vastab hanke alusdokumentides sätestatud tingimustele? (Raadionupp valikutega "Jah/Ei") 2. Andmed lepinguks, mida kasutatakse juhul kui pakkumus tunnistatakse edukaks. Pakkuja esitab andmetena: 1. lepingu allkirjastaja nimi 2. alus lepingu allkirjastamiseks (juhatuse liige, volikiri vms) 3. lepingu allkirjastaja ametinimetus 4. pakkuja kontaktisik(ud) lepingu täitmisel (nimi, ametinimetus, telefoni number, e-posti aadress). (Suur sisestusala (max pikkus 4000 tähemärki)) 3. Pakkumuse esitamisega kinnitab pakkuja, et: • võtab üle kõik hanketeates ja hankedokumentides esitatud tingimused ja esitab pakkumuse üksnes kõigi nende asjaolude kohta, mille kohta hankija soovib võistlevaid pakkumusi; • tal on olemas hankelepingu täitmiseks vajalikud intellektuaalse omandi õigused; • tal on olnud piisavalt aega lepingus sisalduvate tüüptingimustega tutvumiseks, selgitustaotluste esitamiseks ning tüüptingimustega mittenõustumisel vaidlustuse esitamiseks; • kõik tüüptingimused lepingus on pakkujale arusaadavad ja mõistetavad. (Raadionupp valikutega "Jah/Ei") PAKKUMUSE MAKSUMUS Pakkumuse maksumus tuleb esitada töölehel "Hindamiskriteeriumid ja hinnatavad näitajad" toodud struktuuri kohaselt. Küsimused ettevõtjale: 1. Kas ettevõtja kinnitab, et täidab pakkumuse lehe "Hindamiskriteeriumid ja hinnatavad näitajad" lehel ette antud struktuuri kohaselt? (Raadionupp valikutega "Jah/Ei") ÜHISPAKKUJATE VOLIKIRI Ühispakkujad nimetavad riigihankega ning hankelepingu sõlmimise ja täitmisega seotud toimingute tegemiseks endi seast volitatud esindaja. Küsimused ettevõtjale: 1. Kas tegemist on ühispakkumusega? Kui vastate jah, siis tuleb lisada pakkumuse "Lisadokumentide" lehele ühispakkujate volikiri. (Raadionupp valikutega "Jah/Ei") ÄRISALADUS Pakkuja märgib pakkumuses, milline teave on pakkuja ärisaladus ning põhjendab teabe määramist ärisaladuseks. Teabe ärisaladuseks määramisel lähtutakse ebaausa konkurentsi takistamise ja ärisaladuse kaitse seaduse § 5 lõikes 2 sätestatust. Pakkuja ei või ärisaladusena märkida: 1) pakkumuse maksumust ega osamaksumusi; 2) teenuste hankelepingute puhul lisaks punktis 1 nimetatule muid pakkumuste hindamise kriteeriumidele vastavaid pakkumust iseloomustavaid numbrilisi näitajaid; 3) asjade ja ehitustööde hankelepingute puhul lisaks punktis 1 nimetatule muid pakkumuste hindamise kriteeriumidele vastavaid pakkumust iseloomustavaid näitajaid (RHS § 46.1). Koostatud 28.06.2023 12:50:10 https://riigihanked.riik.ee/rhr-web/#/procurement/6083860/general-info  2/2 Küsimused ettevõtjale: 1. Kirjeldage lühidalt pakkumuses sisalduvat ärisaladust ja lisage selle määramise põhjendus või märkige, et pakkumus ei sisalda ärisaladust. (Suur sisestusala (max pikkus 4000 tähemärki)) EL NÕUKOGU SANKTSIOON. ALLTÖÖVÕTJAD JA TARNIJAD. Pakkuja kinnitab, et ta ei kaasa üle 10% hankelepingu maksumusest hankelepingu täitmisele alltöövõtjaid ega tarnijaid, kes on: 1. Vene Föderatsiooni kodanik, resident või Vene Föderatsioonis asutatud ettevõtja, sh füüsilisest isikust ettevõtja, juriidiline isik, asutus või muu üksus; 2. rohkem kui 50% ulatuses otseselt või kaudselt punktis 1 nimetatud isiku, asutuse või muu üksuse omandis; 3. punktis 1 või 2 nimetatud isiku, asutuse või muu üksuse esindaja või tegutseb sellise isiku juhiste alusel. Hankija lükkab tagasi pakkumuse, mille alusel sõlmitav hankeleping oleks RSanS § 7 lg 1 alusel tühine. Määrust kohaldatakse riigihangetele alates rahvusvahelisest piirmäärast. NÕUKOGU MÄÄRUS (EL) 2022/576, 8. aprill 2022, millega muudetakse määrust (EL) nr 833/2014, mis käsitleb piiravaid meetmeid seoses Venemaa tegevusega, mis destabiliseerib olukorda Ukrainas. Küsimused ettevõtjale: 1. Pakkuja kinnitab, et ta ei kaasa üle 10% hankelepingu maksumusest hankelepingu täitmisele alltöövõtjaid ega tarnijaid, kes on: 1. Vene Föderatsiooni kodanik, resident või Vene Föderatsioonis asutatud ettevõtja, sh füüsilisest isikust ettevõtja, juriidiline isik, asutus või muu üksus; 2. rohkem kui 50% ulatuses otseselt või kaudselt punktis 1 nimetatud isiku, asutuse või muu üksuse omandis; 3. punktis 1 või 2 nimetatud isiku, asutuse või muu üksuse esindaja või tegutseb sellise isiku juhiste alusel. (Raadionupp valikutega "Jah/Ei") PAKKUJA MEESKOND Meeskond peab vastama alusdokumendis „Nõuded pakkuja arendusmeeskonnale“ esitatud nõuetele. Küsimused ettevõtjale: 1. Nõuded pakkuja arendusmeeskonnale (Dokumendi vorm / nõuded pakkuja arendusmeeskonnale.docx) Koostatud 28.06.2023 12:50:10 https://riigihanked.riik.ee/rhr-web/#/procurement/6083860/general-info  1 / 22 HANKEPASS Hankepass ehk Euroopa ühtne hankedokument (ESPD) on ettevõtja enda kinnitus, mis on esialgne tõend ametiasutuste või kolmandate isikute poolt väljastatavate tõendite asemel. Käesolev PDF vormingus registri poolt koostatud dokument on selgitava iseloomuga ja sisaldab hankija sätestatud tingimusi, ettevõtjalt oodatavate vastuste vormingu vaadet ja registri poolt lisatud viiteid RHS-ile. Käesolev dokument ei ole ette nähtud täitmiseks vaid tingimustega tutvumiseks. Ettevõtja täidab hankepassi elektrooniliselt infosüsteemis või ESPD teenuses. I OSA: HANKE JA HANKIJAGA SEOTUD TEAVE Teave avaldamise kohta Teate number ELTs: - ELT URL: Riigi ametlik teataja: 266570 Kui Euroopa Liidu Teatajas hankekuulutust avaldatud ei ole või kui selle avaldamist ei nõuta, peab avaliku sektori hankija või võrgustiku sektori hankija ise teabe esitama, et hankemenetlust saaks üheselt identifitseerida (nt viide siseriikliku avaldamise kohta). Hankija andmed Ametlik nimi: Registrite ja Infosüsteemide Keskus (70000310) Riik: Eesti Hankija aadress: Lubja tn 4 Hankija veebiaadress: http://www.rik.ee/ E-posti aadress: [email protected] Koostatud 29.06.2023 09:40:30 https://riigihanked.riik.ee/rhr-web/#/procurement/6083860/general-info  2 / 22 Teave hankemenetluse kohta Hanke menetlusliik: Avatud hankemenetlus Pealkiri: Täitmisregistri hooldus- ja arendustööd Lühikirjeldus: Hanke eesmärk on sõlmida ühe pakkujaga raamleping täitjaga, kes hakkab teostama 24 kuulise raamlepingu perioodil Justiitsministeeriumi Täitmisregistri tarkvara hooldus- ja lisaarendustöid. Avaliku sektori hankija või võrgustiku sektori hankija poolt toimikule antud viitenumber (kui on asjakohane): 266570 Hanke liik: Asjad Hanke CPV-d: 48810000-9 Infosüsteemid Koostatud 29.06.2023 09:40:30 https://riigihanked.riik.ee/rhr-web/#/procurement/6083860/general-info  3 / 22 II OSA: ETTEVÕTJAGA SEOTUD TEAVE A: Teave ettevõtja kohta Nimi: Registrikood: Riik: Aadress: Üldine veebileht: Kontaktisikud: Kontaktide e-posti aadressid: Kontaktide telefoninumbrid: Ettevõtte suurus: Töötajate arv: Käive: Valuuta: Finantsalase võimekuse kirjeldus: Tehnilise võimekuse kirjeldus: Teostatud tööde kirjeldus: Ettevõtja tegevusvaldkond: Koostatud 29.06.2023 09:40:30 https://riigihanked.riik.ee/rhr-web/#/procurement/6083860/general-info  4 / 22 ETTEVÕTJA ON KAITSTUD TÖÖKOHT Ainult reserveeritud hangete puhul: kas ettevõtja puhul on tegemist kaitstud töökohaga, sotsiaalse ettevõttega või ta täidab lepingut kaitstud tööhõive programmide raames? Küsimused ettevõtjale: 1. Mis on Teie vastus? 2. Milline on puudega või ebasoodsas olukorras olevate töötajate osakaal? 3. Kui seda on nõutud, täpsustage, millisesse puudega või ebasoodsas olukorras olevate töötajate kategooriasse või kategooriatesse asjaomased töötajad kuuluvad? 4. Kas see teave on elektrooniliselt kättesaadav? 5. URL 6. Kood 7. Väljaandja ETTEVÕTJA ON KANTUD TUNNUSTATUD ETTEVÕTJATE AMETLIKKU NIMEKIRJA Kui see on asjakohane, siis kas ettevõtja on kantud tunnustatud ettevõtjate ametlikku nimekirja või kas tal on olemas samaväärne tõend (nt riikliku (eel)kvalifitseerimissüsteemi alusel)? Küsimused ettevõtjale: 1. Mis on Teie vastus? 2. a) Vajaduse korral märkige asjakohane registreerimis- või sertifitseerimisnumber: 3. c) Viited, millele registreerimine või sertifitseerimine tugineb ja vajaduse korral ametlikus nimekirjas omistatud klassifikatsioon: 4. d) Kas registreerimine või sertifitseerimine hõlmab kõiki nõutud valikukriteeriume? 5. Kas see teave on elektrooniliselt kättesaadav? 6. URL 7. Kood 8. Väljaandja HANKEMENETLUSES KOOS OSALEVAD ETTEVÕTJAD Kas ettevõtja osaleb hankemenetluses koos teistega? Küsimused ettevõtjale: 1. Ettevõtja nimi 2. Ettevõtja ID 3. Ettevõtja roll 4. Kas see teave on elektrooniliselt kättesaadav? 5. URL 6. Kood 7. Väljaandja TEAVE TEISTE ÜKSUSTE SUUTLIKKUSELE TOETUMISE KOHTA Kas ettevõtja toetub teiste üksuste suutlikkusele, et täita esitatud valikukriteeriumid ning eeskirjad (kui neid on)? Küsimused ettevõtjale: 1. Mis on Teie vastus? 2. Ettevõtja nimi 3. Ettevõtja ID 4. Ettevõtja roll 5. Kas see teave on elektrooniliselt kättesaadav? 6. URL 7. Kood 8. Väljaandja Koostatud 29.06.2023 09:40:30 https://riigihanked.riik.ee/rhr-web/#/procurement/6083860/general-info  5 / 22 TEAVE NENDE ALLHANKIJATE KOHTA, KELLE NÄITAJATELE ETTEVÕTJA EI TUGINE Kas ettevõtja kavatseb sõlmida lepingu mis tahes osa kohta allhanke kolmanda isikuga? Küsimused ettevõtjale: 1. Mis on Teie vastus? 2. Ettevõtja nimi 3. Ettevõtja ID 4. Ettevõtja roll 5. Kas see teave on elektrooniliselt kättesaadav? 6. URL 7. Kood 8. Väljaandja HANKE OSAD Hanke osad, mille kohta ettevõtja soovib pakkumuse esitada Küsimused ettevõtjale: 1. Hanke osa number 2. Kas see teave on elektrooniliselt kättesaadav? 3. URL 4. Kood 5. Väljaandja ETTEVÕTJA KINNITUSED MAKSUDE TASUMISE KOHTA Kas ettevõtja saab esitada tõendi sotsiaalkindlustusmaksete ja maksude tasumise kohta või esitada teabe, mis võimaldaks avaliku sektori hankijal või võrgustiku sektori hankijal saada sellise teabe otse ükskõik millise liikmesriigi tasuta andmebaasist? Küsimused ettevõtjale: 1. Mis on Teie vastus? 2. Kas see teave on elektrooniliselt kättesaadav? 3. URL 4. Kood 5. Väljaandja B: Teave ettevõtja esindajate kohta Eesnimi: Perekonnanimi: Sünniaeg: Sünnikoht: Aadress: Linn/vald: Postiindeks: Riik: E-post: Telefon: Vajaduse korral esitage üksikasjalik teave esindamise kohta (selle vormid, ulatus, eesmärk, ...): Koostatud 29.06.2023 09:40:30 https://riigihanked.riik.ee/rhr-web/#/procurement/6083860/general-info  6 / 22 III OSA: KÕRVALDAMISE ALUSED A: Kõrvalejätmise alused seoses kriminaalasjas tehtud süüdimõistva otsusega OSALEMINE KURITEGELIKUS ORGANISATSIOONIS Kas ettevõtja ise või tema haldus-, juht- või järelevalveorgani liige või isik, kellel on volitused seda ettevõtjat esindada, tema nimel otsuseid teha või teda kontrollida, on lõpliku süüdimõistva kohtuotsusega süüdi mõistetud kuritegelikus organisatsioonis osalemise eest kõige rohkem viimase viie aasta jooksul või kehtib süüdimõistvas kohtuotsuses sätestatud kõrvalejäämise kohustus endiselt? Viide seadusele: RHS § 95 lg 1 p 1 "keda või kelle haldus-, juhtimis- või järelevalveorgani liiget, prokuristi või muud isikut, kellel on volitus seda ettevõtjat esindada, tema nimel otsuseid teha või teda kontrollida, on karistatud kuritegelikus ühenduses osalemise eest". Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud. Ettevõtjalt oodatavad vastused: 1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Süüdimõistmise kuupäev (Kuupäev) 3. Põhjus (Suur sisestusala (max pikkus 4000 tähemärki)) 4. Kes süüdi mõisteti? (Suur sisestusala (max pikkus 4000 tähemärki)) 5. Süüdimõistvas otsuses sõnaselgelt esitatud kõrvalejätmise kestus. (Periood) 6. Kas olete võtnud meetmeid, et tõendada oma usaldusväärsust („Self-Cleaning”)? (Raadionupp valikutega "Jah/Ei") 7. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 8. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 9. URL (Url) 10. Kood (Sisestusväli (max pikkus 250 tähemärki)) 11. Väljaandja (Sisestusväli (max pikkus 250 tähemärki)) KORRUPTSIOON Kas ettevõtja ise või tema haldus-, juht- või järelevalveorgani liige või isik, kellel on volitused seda ettevõtjat esindada, tema nimel otsuseid teha või teda kontrollida, on lõpliku süüdimõistva kohtuotsusega süüdi mõistetud korruptsiooni eest kõige rohkem viimase viie aasta jooksul või kehtib süüdimõistvas kohtuotsuses sätestatud kõrvalejäämise kohustus endiselt? See kõrvalejätmise alus hõlmab ka korruptsiooni avaliku sektori hankija (võrgustiku sektori hankija) või ettevõtja riigi õiguses sätestatud määratluses. Viide seadusele: RHS § 95 lg 1 p 1 "keda või kelle haldus-, juhtimis- või järelevalveorgani liiget, prokuristi või muud isikut, kellel on volitus seda ettevõtjat esindada, tema nimel otsuseid teha või teda kontrollida, on karistatud aususe kohustuse rikkumise või korruptiivse teo eest". Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud. Koostatud 29.06.2023 09:40:30 https://riigihanked.riik.ee/rhr-web/#/procurement/6083860/general-info  7 / 22 Ettevõtjalt oodatavad vastused: 1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Süüdimõistmise kuupäev (Kuupäev) 3. Põhjus (Suur sisestusala (max pikkus 4000 tähemärki)) 4. Kes süüdi mõisteti? (Suur sisestusala (max pikkus 4000 tähemärki)) 5. Süüdimõistvas otsuses sõnaselgelt esitatud kõrvalejätmise kestus. (Periood) 6. Kas olete võtnud meetmeid, et tõendada oma usaldusväärsust („Self-Cleaning”)? (Raadionupp valikutega "Jah/Ei") 7. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 8. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 9. URL (Url) 10. Kood (Sisestusväli (max pikkus 250 tähemärki)) 11. Väljaandja (Sisestusväli (max pikkus 250 tähemärki)) PETTUS Kas ettevõtja ise või tema haldus-, juht- või järelevalveorgani liige või isik, kellel on volitused seda ettevõtjat esindada, tema nimel otsuseid teha või teda kontrollida, on lõpliku süüdimõistva kohtuotsusega süüdi mõistetud kelmuse eest kõige rohkem viimase viie aasta jooksul või kehtib süüdimõistvas kohtuotsuses sätestatud kõrvalejäämise kohustus endiselt? Viide seadusele: RHS § 95 lg 1 p 1 "keda või kelle haldus-, juhtimis- või järelevalveorgani liiget, prokuristi või muud isikut, kellel on volitus seda ettevõtjat esindada, tema nimel otsuseid teha või teda kontrollida, on karistatud kelmuse eest". Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud. Ettevõtjalt oodatavad vastused: 1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Süüdimõistmise kuupäev (Kuupäev) 3. Põhjus (Suur sisestusala (max pikkus 4000 tähemärki)) 4. Kes süüdi mõisteti? (Suur sisestusala (max pikkus 4000 tähemärki)) 5. Süüdimõistvas otsuses sõnaselgelt esitatud kõrvalejätmise kestus. (Periood) 6. Kas olete võtnud meetmeid, et tõendada oma usaldusväärsust („Self-Cleaning”)? (Raadionupp valikutega "Jah/Ei") 7. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 8. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 9. URL (Url) 10. Kood (Sisestusväli (max pikkus 250 tähemärki)) 11. Väljaandja (Sisestusväli (max pikkus 250 tähemärki)) TERRORIAKTI TOIMEPANEK VÕI TERRORISTLIKU TEGEVUSEGA SEOTUD ÕIGUSRIKKUMISED Kas ettevõtja ise või tema haldus-, juht- või järelevalveorgani liige või isik, kellel on volitused seda ettevõtjat esindada, tema nimel otsuseid teha või teda kontrollida, on lõpliku süüdimõistva kohtuotsusega süüdi mõistetud terroriakti toimepaneku või terroristliku tegevusega seotud õigusrikkumiste eest kõige rohkem viimase viie aasta jooksul või kehtib süüdimõistvas kohtuotsuses sätestatud kõrvalejäämise kohustus endiselt? Viide seadusele: Koostatud 29.06.2023 09:40:30 https://riigihanked.riik.ee/rhr-web/#/procurement/6083860/general-info  8 / 22 RHS § 95 lg 1 p 1 "keda või kelle haldus-, juhtimis- või järelevalveorgani liiget, prokuristi või muud isikut, kellel on volitus seda ettevõtjat esindada, tema nimel otsuseid teha või teda kontrollida, on karistatud terroriakti toimepaneku või muu terroristliku tegevusega seotud kuriteo või sellele kihutamise, kaasaaitamise või selle katse eest". Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud. Ettevõtjalt oodatavad vastused: 1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Süüdimõistmise kuupäev (Kuupäev) 3. Põhjus (Suur sisestusala (max pikkus 4000 tähemärki)) 4. Kes süüdi mõisteti? (Suur sisestusala (max pikkus 4000 tähemärki)) 5. Süüdimõistvas otsuses sõnaselgelt esitatud kõrvalejätmise kestus. (Periood) 6. Kas olete võtnud meetmeid, et tõendada oma usaldusväärsust („Self-Cleaning”)? (Raadionupp valikutega "Jah/Ei") 7. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 8. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 9. URL (Url) 10. Kood (Sisestusväli (max pikkus 250 tähemärki)) 11. Väljaandja (Sisestusväli (max pikkus 250 tähemärki)) RAHAPESU VÕI TERRORISMI RAHASTAMINE Kas ettevõtja ise või tema haldus-, juht- või järelevalveorgani liige või isik, kellel on volitused seda ettevõtjat esindada, tema nimel otsuseid teha või teda kontrollida, on lõpliku süüdimõistva kohtuotsusega süüdi mõistetud rahapesu või terrorismi rahastamise eest kõige rohkem viimase viie aasta jooksul või kehtib süüdimõistvas kohtuotsuses sätestatud kõrvalejäämise kohustus endiselt? Viide seadusele: RHS § 95 lg 1 p 1 "keda või kelle haldus-, juhtimis- või järelevalveorgani liiget, prokuristi või muud isikut, kellel on volitus seda ettevõtjat esindada, tema nimel otsuseid teha või teda kontrollida, on karistatud rahapesualase süüteo või terrorismi rahastamise eest". Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud. Ettevõtjalt oodatavad vastused: 1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Süüdimõistmise kuupäev (Kuupäev) 3. Põhjus (Suur sisestusala (max pikkus 4000 tähemärki)) 4. Kes süüdi mõisteti? (Suur sisestusala (max pikkus 4000 tähemärki)) 5. Süüdimõistvas otsuses sõnaselgelt esitatud kõrvalejätmise kestus. (Periood) 6. Kas olete võtnud meetmeid, et tõendada oma usaldusväärsust („Self-Cleaning”)? (Raadionupp valikutega "Jah/Ei") 7. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 8. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 9. URL (Url) 10. Kood (Sisestusväli (max pikkus 250 tähemärki)) 11. Väljaandja (Sisestusväli (max pikkus 250 tähemärki)) Koostatud 29.06.2023 09:40:30 https://riigihanked.riik.ee/rhr-web/#/procurement/6083860/general-info  9 / 22 LASTE TÖÖJÕU KASUTAMINE JA MUUD INIMKAUBANDUSE VORMID Kas ettevõtja ise või tema haldus-, juht- või järelevalveorgani liige või isik, kellel on volitused seda ettevõtjat esindada, tema nimel otsuseid teha või teda kontrollida, on lõpliku süüdimõistva kohtuotsusega süüdi mõistetud laste tööjõu kasutamise või muude inimkaubanduse vormide eest kõige rohkem viimase viie aasta jooksul või kehtib süüdimõistvas kohtuotsuses sätestatud kõrvalejäämise kohustus endiselt? Viide seadusele: RHS § 95 lg 1 p 3 "keda või kelle haldus-, juhtimis- või järelevalveorgani liiget, prokuristi või muud isikut, kellel on volitus seda ettevõtjat esindada, tema nimel otsuseid teha või teda kontrollida, on karistatud laste tööjõu ebaseadusliku kasutamise või inimkaubandusega seotud teo eest". Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud. Ettevõtjalt oodatavad vastused: 1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Süüdimõistmise kuupäev (Kuupäev) 3. Põhjus (Suur sisestusala (max pikkus 4000 tähemärki)) 4. Kes süüdi mõisteti? (Suur sisestusala (max pikkus 4000 tähemärki)) 5. Süüdimõistvas otsuses sõnaselgelt esitatud kõrvalejätmise kestus. (Periood) 6. Kas olete võtnud meetmeid, et tõendada oma usaldusväärsust („Self-Cleaning”)? (Raadionupp valikutega "Jah/Ei") 7. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 8. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 9. URL (Url) 10. Kood (Sisestusväli (max pikkus 250 tähemärki)) 11. Väljaandja (Sisestusväli (max pikkus 250 tähemärki)) B: Kõrvalejätmise alused seoses maksude või sotsiaalkindlustusmaksete tasumisega MAKSUDE TASUMINE Kas ettevõtja on rikkunud oma maksude tasumise kohustusi nii asukohariigis kui ka avaliku sektori hankija või võrgustiku sektori hankija liikmesriigis, kui see erineb asukohariigist? Viide seadusele: RHS § 95 lg 1 p 4 „kellel on riikliku maksu, makse või keskkonnatasu maksuvõlg maksukorralduse seaduse tähenduses või maksuvõlg /…/ tema asukohariigi õigusaktide kohaselt“ Koostatud 29.06.2023 09:40:30 https://riigihanked.riik.ee/rhr-web/#/procurement/6083860/general-info  10 / 22 Tingimuse kirjeldus: Piirmäär: 0 Valuuta: EUR Lisainfo: Maksukorralduse seaduse kohaselt ei väljasta maksuhaldur maksuvõlgade tõendit juhul,kui maksukohustuslasel olev kõikide sama maksuhalduri hallatavate maksude võlg, arvestamata haldusaktiga kindlaksmääramata intressi, on väiksem kui 100 eurot või kui maksuvõla tasumine on ajatatud. Välismaise ettevõtja puhul väljastatakse maksuvõlgade tõend tema asukohariigi õigusaktide kohaselt. Ettevõtjalt oodatavad vastused: 1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Asjaomane riik või liikmesriik (Riigikood) 3. Asjaomane summa (Summa) 4. Valuuta (Vääring) 5. Kas see kohustuste rikkumine on tuvastatud muude vahenditega kui kohtu- või haldusotsusega? (Raadionupp valikutega "Jah/Ei") 6. Kirjeldage kasutatud vahendeid (Suur sisestusala (max pikkus 4000 tähemärki)) 7. Kui kohustuste rikkumine tuvastati kohtu- või haldusotsusega, märkige, kas see otsus on lõplik ja siduv. (Raadionupp valikutega "Jah/Ei") 8. Süüdimõistmise kuupäev (Kuupäev) 9. Süüdimõistvas otsuses sõnaselgelt esitatud kõrvalejätmise kestus. (Periood) 10. Kas ettevõtja on täitnud oma kohustused tasumisele kuuluvate maksude või sotsiaalkindlustusmaksete tasumisega või siduva kokkuleppe sõlmimisega tasumisele kuuluvate maksude või sotsiaalkindlustusmaksete, sealhulgas vajaduse korral kogunenud intresside ja viiviste tasumise kohta? (Raadionupp valikutega "Jah/Ei") 11. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 12. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 13. URL (Url) 14. Kood (Sisestusväli (max pikkus 250 tähemärki)) 15. Väljaandja (Sisestusväli (max pikkus 250 tähemärki)) SOTSIAALKINDLUSTUSMAKSETE TASUMINE Kas ettevõtja on rikkunud oma sotsiaalkindlustusmaksete tasumise kohustusi nii asukohariigis kui ka avaliku sektori hankija või võrgustiku sektori hankija liikmesriigis, kui see erineb asukohariigist? Viide seadusele: RHS § 95 lg 1 p 4 „kellel on riikliku /…/ makse /…/ maksuvõlg maksukorralduse seaduse tähenduses või sotsiaalkindlustusemaksete võlg tema asukohariigi õigusaktide kohaselt Koostatud 29.06.2023 09:40:30 https://riigihanked.riik.ee/rhr-web/#/procurement/6083860/general-info  11 / 22 Tingimuse kirjeldus: Piirmäär: 0 Valuuta: EUR Lisainfo: Maksukorralduse seaduse kohaselt ei väljasta maksuhaldur maksuvõlgade tõendit juhul,kui maksukohustuslasel olev kõikide sama maksuhalduri hallatavate maksude võlg, arvestamata haldusaktiga kindlaksmääramata intressi, on väiksem kui 100 eurot või kui maksuvõla tasumine on ajatatud. Välismaise ettevõtja puhul väljastatakse maksuvõlgade tõend tema asukohariigi õigusaktide kohaselt. Ettevõtjalt oodatavad vastused: 1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Asjaomane riik või liikmesriik (Riigikood) 3. Asjaomane summa (Summa) 4. Valuuta (Vääring) 5. Kas see kohustuste rikkumine on tuvastatud muude vahenditega kui kohtu- või haldusotsusega? (Raadionupp valikutega "Jah/Ei") 6. Kirjeldage kasutatud vahendeid (Suur sisestusala (max pikkus 4000 tähemärki)) 7. Kui kohustuste rikkumine tuvastati kohtu- või haldusotsusega, märkige, kas see otsus on lõplik ja siduv. (Raadionupp valikutega "Jah/Ei") 8. Süüdimõistmise kuupäev (Kuupäev) 9. Süüdimõistvas otsuses sõnaselgelt esitatud kõrvalejätmise kestus. (Periood) 10. Kas ettevõtja on täitnud oma kohustused tasumisele kuuluvate maksude või sotsiaalkindlustusmaksete tasumisega või siduva kokkuleppe sõlmimisega tasumisele kuuluvate maksude või sotsiaalkindlustusmaksete, sealhulgas vajaduse korral kogunenud intresside ja viiviste tasumise kohta? (Raadionupp valikutega "Jah/Ei") 11. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 12. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 13. URL (Url) 14. Kood (Sisestusväli (max pikkus 250 tähemärki)) 15. Väljaandja (Sisestusväli (max pikkus 250 tähemärki)) C: Kõrvalejätmise alused seoses maksejõuetusega, huvide konfliktiga või ametialaste käitumisreeglite rikkumisega KOKKULEPE VÕLAUSALDAJATEGA Kas ettevõtja on sõlminud kokkuleppe võlausaldajatega? Viide seadusele: RHS § 95 lg 4 p 3 „kes on muus sellesarnases olukorras tema asukohamaa õigusaktide kohaselt, välja arvatud asjade ostmisel RHS § 49 lõikes 4 sätestatud juhul ja tingimustel“. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud. Koostatud 29.06.2023 09:40:30 https://riigihanked.riik.ee/rhr-web/#/procurement/6083860/general-info  12 / 22 Ettevõtjalt oodatavad vastused: 1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 3. Märkige põhjused, miks lepingu täitmine on sellest hoolimata võimalik. Seda teavet ei ole tarvis esitada, kui ettevõtja kõrvalejätmine on kohaldatava siseriikliku õiguse alusel muudetud konkreetsel juhul kohustuslikuks ja puudub võimalus teha erandit, isegi kui ettevõtja suudab lepingut täita. (Suur sisestusala (max pikkus 4000 tähemärki)) 4. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 5. URL (Url) 6. Kood (Sisestusväli (max pikkus 250 tähemärki)) 7. Väljaandja (Sisestusväli (max pikkus 250 tähemärki)) SISERIIKLIKU ÕIGUSE KOHANE SAMALAADNE OLUKORD, NÄITEKS PANKROT Kas ettevõtja on siseriiklike õigusnormide alusel toimuva samalaadse menetluse tõttu samalaadses olukorras? Viide seadusele: RHS § 95 lg 4 p 3 „kes on muus sellesarnases olukorras tema asukohamaa õigusaktide kohaselt“, välja arvatud asjade ostmisel RHS § 49 lõikes 4 sätestatud juhul ja tingimustel. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud. Ettevõtjalt oodatavad vastused: 1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 3. Märkige põhjused, miks lepingu täitmine on sellest hoolimata võimalik. Seda teavet ei ole tarvis esitada, kui ettevõtja kõrvalejätmine on kohaldatava siseriikliku õiguse alusel muudetud konkreetsel juhul kohustuslikuks ja puudub võimalus teha erandit, isegi kui ettevõtja suudab lepingut täita. (Suur sisestusala (max pikkus 4000 tähemärki)) 4. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 5. URL (Url) 6. Kood (Sisestusväli (max pikkus 250 tähemärki)) 7. Väljaandja (Sisestusväli (max pikkus 250 tähemärki)) VARA HALDAB LIKVIDEERIJA Kas ettevõtja vara haldab likvideerija või kohus? Viide seadusele: RHS § 95 lg 4 p 3 „kes on pankrotis, likvideerimisel või kelle suhtes on algatatud pankrotimenetlus või kes on muus sellesarnases olukorras tema asukohamaa õigusaktide kohaselt, välja arvatud asjade ostmisel RHS § 49 lõikes 4 sätestatud juhul ja tingimustel“. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud. Koostatud 29.06.2023 09:40:30 https://riigihanked.riik.ee/rhr-web/#/procurement/6083860/general-info  13 / 22 Ettevõtjalt oodatavad vastused: 1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 3. Märkige põhjused, miks lepingu täitmine on sellest hoolimata võimalik. Seda teavet ei ole tarvis esitada, kui ettevõtja kõrvalejätmine on kohaldatava siseriikliku õiguse alusel muudetud konkreetsel juhul kohustuslikuks ja puudub võimalus teha erandit, isegi kui ettevõtja suudab lepingut täita. (Suur sisestusala (max pikkus 4000 tähemärki)) 4. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 5. URL (Url) 6. Kood (Sisestusväli (max pikkus 250 tähemärki)) 7. Väljaandja (Sisestusväli (max pikkus 250 tähemärki)) ÄRITEGEVUS ON PEATATUD Kas ettevõtja äritegevus on peatatud? Viide seadusele: RHS § 95 lg 4 p 3 „kelle äritegevus on peatatud, välja arvatud asjade ostmisel RHS § 49 lõikes 4 sätestatud juhul ja tingimustel“. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud. Ettevõtjalt oodatavad vastused: 1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 3. Märkige põhjused, miks lepingu täitmine on sellest hoolimata võimalik. Seda teavet ei ole tarvis esitada, kui ettevõtja kõrvalejätmine on kohaldatava siseriikliku õiguse alusel muudetud konkreetsel juhul kohustuslikuks ja puudub võimalus teha erandit, isegi kui ettevõtja suudab lepingut täita. (Suur sisestusala (max pikkus 4000 tähemärki)) 4. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 5. URL (Url) 6. Kood (Sisestusväli (max pikkus 250 tähemärki)) 7. Väljaandja (Sisestusväli (max pikkus 250 tähemärki)) SÜÜDI AMETIALASTE KÄITUMISREEGLITE OLULISES RIKKUMISES Kas ettevõtja on süüdi ametialaste käitumisreeglite olulises rikkumises? Vt siseriiklikud õigusaktid, asjaomane teade või hankedokumendid, kui see on asjakohane. Viide seadusele: RHS § 95 lg 4 p 4 „kes on raskelt eksinud ametialaste käitumisreeglite vastu ja see muudab tema aususe küsitavaks“. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud. Koostatud 29.06.2023 09:40:30 https://riigihanked.riik.ee/rhr-web/#/procurement/6083860/general-info  14 / 22 Ettevõtjalt oodatavad vastused: 1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 3. Kas olete võtnud meetmeid, et tõendada oma usaldusväärsust („Self-Cleaning”)? (Raadionupp valikutega "Jah/Ei") 4. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 5. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 6. URL (Url) 7. Kood (Sisestusväli (max pikkus 250 tähemärki)) 8. Väljaandja (Sisestusväli (max pikkus 250 tähemärki)) KONKURENTSI MOONUTAMISE EESMÄRGIL TEISTE ETTEVÕTJATEGA SÕLMITUD KOKKULEPPED Kas ettevõtja on teiste ettevõtjatega sõlminud kokkuleppeid, mille eesmärk on moonutada konkurentsi? Viide seadusele: RHS § 95 lg 4 p 5 „konkurentsi kahjustava kokkuleppe, ettevõtjate ühenduse otsuse või kooskõlastatud tegevuse tõttu“. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud. Ettevõtjalt oodatavad vastused: 1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 3. Kas olete võtnud meetmeid, et tõendada oma usaldusväärsust („Self-Cleaning”)? (Raadionupp valikutega "Jah/Ei") 4. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 5. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 6. URL (Url) 7. Kood (Sisestusväli (max pikkus 250 tähemärki)) 8. Väljaandja (Sisestusväli (max pikkus 250 tähemärki)) HANKEMENETLUSES OSALEMISEGA KAASNEV HUVIDE KONFLIKT Kas ettevõtja on teadlik hankemenetluses osalemisega kaasnevast mis tahes huvide konfliktist siseriikliku õiguse, asjakohase teatise või hankedokumentide kohaselt? Viide seadusele: RHS § 95 lg 4 p 6 „kui huvide konflikti ei ole muude vahenditega võimalik vältida“. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud. Koostatud 29.06.2023 09:40:30 https://riigihanked.riik.ee/rhr-web/#/procurement/6083860/general-info  15 / 22 Ettevõtjalt oodatavad vastused: 1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 3. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 4. URL (Url) 5. Kood (Sisestusväli (max pikkus 250 tähemärki)) 6. Väljaandja (Sisestusväli (max pikkus 250 tähemärki)) OTSENE VÕI KAUDNE OSALEMINE KÄESOLEVA HANKEMENETLUSE ETTEVALMISTAMISEL Kas ettevõtja või temaga seotud ettevõtja on nõustanud avaliku sektori hankijat või võrgustiku sektori hankijat hankemenetluse ettevalmistamisel või olnud muul viisil seotud hankemenetluse ettevalmistamisega? Viide seadusele: RHS § 95 lg 4 p 7 „kelle pakkumuse või taotluse koostamisel on osalenud isik, kes on osalenud sama riigihanke ettevalmistamisel või on muul viisil hankijaga seotud, ja sellele isikule seetõttu teadaolev info annab talle eelise teiste riigihankes osalejate eest ning sellest tingitud konkurentsi moonutamist ei ole muude vahendistega võimalik vältida“. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud. Ettevõtjalt oodatavad vastused: 1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 3. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 4. URL (Url) 5. Kood (Sisestusväli (max pikkus 250 tähemärki)) 6. Väljaandja (Sisestusväli (max pikkus 250 tähemärki)) ENNETÄHTAEGNE LÕPETAMINE, KAHJUTASU VÕI VÕRRELDAVAD SANKTSIOONID Kas ettevõtja on kogenud, et varasem riigihankeleping või võrgustiku sektori hankijaga sõlmitud varasem hankeleping või varasem kontsessioonileping on lõpetatud enneaegselt, või on määratud kahjutasu või sellega võrreldavad sanktsioonid seoses kõnealuse varasema lepinguga? Viide seadusele: RHS § 95 lg 4 p 8 „kes on oluliselt või pidevalt rikkunud eelnevalt sõlmitud hankelepingu olulist tingimust või hankelepingute olulisi tingimusi nii, et rikkumise tulemusena on lepingust taganetud või leping üles öeldud, hinda alandatud, hüvitatud kahju või makstud leppetrahvi". Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud. Alates 1.09.2017 alustatud hangete tulemusena sõlmitud riigihankelepingute kohta leiab infot riigihangete registrist. Koostatud 29.06.2023 09:40:30 https://riigihanked.riik.ee/rhr-web/#/procurement/6083860/general-info  16 / 22 Ettevõtjalt oodatavad vastused: 1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 3. Kas olete võtnud meetmeid, et tõendada oma usaldusväärsust („Self-Cleaning”)? (Raadionupp valikutega "Jah/Ei") 4. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 5. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 6. URL (Url) 7. Kood (Sisestusväli (max pikkus 250 tähemärki)) 8. Väljaandja (Sisestusväli (max pikkus 250 tähemärki)) SÜÜDI VALEANDMETE ESITAMISES, ON JÄTNUD TEAVET ESITAMATA, EI SUUDA NÕUTUD DOKUMENTE ESITADA, HANKINUD KÄESOLEVA MENETLUSE KOHTA KONFIDENTSIAALSET TEAVET Kas ettevõtja on olnud ühes järgmistest olukordadest: a) ta on kõrvalejätmise aluste puudumise või valikukriteeriumide täitmise kontrollimiseks nõutava teabe esitamisel esitanud valeandmeid; b) ta on jätnud sellist teavet esitamata; c) ta ei ole esitanud viivitamata avaliku sektori hankija või võrgustiku sektori hankija nõutud täiendavad dokumendid, ja d) ta on tegutsenud eesmärgiga mõjutada lubamatul viisil avaliku sektori hankija või võrgustiku sektori hankija otsustusprotsessi, et saada konfidentsiaalseid andmeid, mis võivad anda talle põhjendamatu eelise hankemenetluses, või hooletusest esitanud eksitavat teavet, mis võib oluliselt mõjutada kõrvalejätmise, valiku või lepingu hindamise kohta tehtavaid otsuseid? Viide seadusele: RHS § 95 lg 4 p 9 „kes on esitanud valeandmeid käesolevas paragrahvis sätestatud või RHS §- des 98-101 sätestatu alusel hankija kehtestatud kvalifitseerimise tingimustele vastavuse kohta“; RHS § 95 lg 4 p 9 „kes on jätnud andmed käesolevas paragrahvis sätestatud või käesoleva seaduse §-des 98-101 sätestatu alusel hankija kehtestatud kvalifitseerimise tingimustele vastavuse kohta esitamata“; RHS § 95 lg 4 p 9 „kes on jätnud käesoleva seaduse § 104 lõigete 7 ja 8 alusel hankija nõutud täiendavad dokumendid esitamata“; RHS § 95 lg 4 p 10 „kes on tegutsenud eesmärgiga mõjutada hankijat või esitanud hooletusest eksitavat teavet, mis on võinud mõjutada hankija otsuseid riigihankes, või on tegutsenud eesmärgiga saada konfidentsiaalset teavet, mis on võinud anda talle põhjendamatu eelise teiste riigihankes osalejate ees“. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud. Ettevõtjalt oodatavad vastused: 1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 3. URL (Url) 4. Kood (Sisestusväli (max pikkus 250 tähemärki)) 5. Väljaandja (Sisestusväli (max pikkus 250 tähemärki)) KESKKONNAÕIGUSE VALDKONNAS KOHALDATAVATE KOHUSTUSTE TÄITMATA JÄTMINE Kas ettevõtja on enda teada rikkunud keskkonnaõiguse valdkonnas kohaldatavaid kohustusi? Koostatud 29.06.2023 09:40:30 https://riigihanked.riik.ee/rhr-web/#/procurement/6083860/general-info  17 / 22 Viide seadusele: RHS § 95 lg 4 p 2 „kes on rikkunud õigusaktidest või kollektiivlepingust tulenevaid keskkonnaõiguse valdkonnas kohaldatavaid kohustusi“. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud. Ettevõtjalt oodatavad vastused: 1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 3. Kas olete võtnud meetmeid, et tõendada oma usaldusväärsust („Self-Cleaning”)? (Raadionupp valikutega "Jah/Ei") 4. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 5. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 6. URL (Url) 7. Kood (Sisestusväli (max pikkus 250 tähemärki)) 8. Väljaandja (Sisestusväli (max pikkus 250 tähemärki)) SOTSIAALÕIGUSE VALDKONNAS KOHALDATAVATE KOHUSTUSTE TÄITMATA JÄTMINE Kas ettevõtja on enda teada rikkunud sotsiaalõiguse valdkonnas kohaldatavaid kohustusi? Viide seadusele: RHS § 95 lg 4 p 2 „kes on rikkunud õigusaktidest või kollektiivlepingust tulenevaid sotsiaalõiguse valdkonnas kohaldatavaid kohustusi“. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud. Ettevõtjalt oodatavad vastused: 1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 3. Kas olete võtnud meetmeid, et tõendada oma usaldusväärsust („Self-Cleaning”)? (Raadionupp valikutega "Jah/Ei") 4. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 5. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 6. URL (Url) 7. Kood (Sisestusväli (max pikkus 250 tähemärki)) 8. Väljaandja (Sisestusväli (max pikkus 250 tähemärki)) TÖÖÕIGUSE VALDKONNAS KOHALDATAVATE KOHUSTUSTE TÄITMATA JÄTMINE Kas ettevõtja on enda teada rikkunud tööõiguse valdkonnas kohaldatavaid kohustusi? Viide seadusele: RHS § 95 lg 4 p 2 „kes on rikkunud õigusaktidest või kollektiivlepingust tulenevaid tööõiguse valdkonnas kohaldatavaid kohustusi“. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on Koostatud 29.06.2023 09:40:30 https://riigihanked.riik.ee/rhr-web/#/procurement/6083860/general-info  18 / 22 rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud. Ettevõtjalt oodatavad vastused: 1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 3. Kas olete võtnud meetmeid, et tõendada oma usaldusväärsust („Self-Cleaning”)? (Raadionupp valikutega "Jah/Ei") 4. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 5. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 6. URL (Url) 7. Kood (Sisestusväli (max pikkus 250 tähemärki)) 8. Väljaandja (Sisestusväli (max pikkus 250 tähemärki)) PANKROT Kas ettevõtja on pankrotis? Viide seadusele: RHS § 95 lg 4 p 3 „kes on pankrotis, välja arvatud asjade ostmisel RHS § 49 lõikes 4 sätestatud juhul ja tingimustel“. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud. Ettevõtjalt oodatavad vastused: 1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 3. Märkige põhjused, miks lepingu täitmine on sellest hoolimata võimalik. Seda teavet ei ole tarvis esitada, kui ettevõtja kõrvalejätmine on kohaldatava siseriikliku õiguse alusel muudetud konkreetsel juhul kohustuslikuks ja puudub võimalus teha erandit, isegi kui ettevõtja suudab lepingut täita. (Suur sisestusala (max pikkus 4000 tähemärki)) 4. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 5. URL (Url) 6. Kood (Sisestusväli (max pikkus 250 tähemärki)) 7. Väljaandja (Sisestusväli (max pikkus 250 tähemärki)) MAKSEJÕUETUS Kas ettevõtja suhtes on algatatud maksejõuetus- või likvideerimismenetlus? Viide seadusele: RHS § 95 lg 4 p 3 „kes on likvideerimisel või kelle suhtes on algatatud pankrotimenetlus, välja arvatud asjade ostmisel RHS § 49 lõikes 4 sätestatud juhul ja tingimustel“. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud. Koostatud 29.06.2023 09:40:30 https://riigihanked.riik.ee/rhr-web/#/procurement/6083860/general-info  19 / 22 Ettevõtjalt oodatavad vastused: 1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 3. Märkige põhjused, miks lepingu täitmine on sellest hoolimata võimalik. Seda teavet ei ole tarvis esitada, kui ettevõtja kõrvalejätmine on kohaldatava siseriikliku õiguse alusel muudetud konkreetsel juhul kohustuslikuks ja puudub võimalus teha erandit, isegi kui ettevõtja suudab lepingut täita. (Suur sisestusala (max pikkus 4000 tähemärki)) 4. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 5. URL (Url) 6. Kood (Sisestusväli (max pikkus 250 tähemärki)) 7. Väljaandja (Sisestusväli (max pikkus 250 tähemärki)) D: Ainult siseriiklikest õigusaktidest tulenevad kõrvalejätmise alused AINULT SISERIIKLIKEST ÕIGUSAKTIDEST TULENEVAD KÕRVALEJÄTMISE ALUSED: SEADUSLIKU ALUSETA VIIBIVALE VÄLISMAALASELE TÖÖTAMISE VÕIMALDAMISE EEST Kas ettevõtja on rikkunud RHS § 95 lg 1 p-st 2 tuleneva kõrvalejätmise alusega seotud kohustusi? Viide seadusele: RHS § 95 lg 1 p 2 „keda või kelle haldus-, juhtimis- või järelevalveorgani liiget, prokuristi või muud isikut, kellel on volitus seda ettevõtjat esindada, tema nimel otsuseid teha või teda kontrollida, on karistatud riigis ilma seadusliku aluseta viibivale välismaalasele töötamise võimaldamise või välismaalase Eestis töötamise tingimuste rikkumise võimaldamise, sealhulgas seaduses sätestatud töötasu määrast väiksema töötasu maksmise eest“. Kohustuslik kõrvaldamise alus. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud. Ettevõtjalt oodatavad vastused: 1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 3. URL (Url) 4. Kood (Sisestusväli (max pikkus 250 tähemärki)) 5. Väljaandja (Sisestusväli (max pikkus 250 tähemärki)) AINULT SISERIIKLIKEST ÕIGUSAKTIDEST TULENEVAD KÕRVALEJÄTMISE ALUSED: RAHVUSVAHELISE SANKTSIOONI SUBJEKT Kas ettevõtja on rikkunud RHS § 95 lg 1 p-st 5 tuleneva kõrvalejätmise alusega seotud kohustusi? Viide seadusele: RHS § 95 lg 1 p 5. Alates 14.08.2022 kontrollib hankija kõrvaldamise aluse puudumist pakkuja või taotleja kinnituse alusel. Hankija võib põhjendatud kahtluse korral nõuda pakkujalt või taotlejalt täiendavate andmete või tõendite esitamist, mis võimaldavad kõrvaldamise alust kontrollida (RHS § 96 lg 2.1). Koostatud 29.06.2023 09:40:30 https://riigihanked.riik.ee/rhr-web/#/procurement/6083860/general-info  20 / 22 Ettevõtjalt oodatavad vastused: 1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 3. URL (Url) 4. Kood (Sisestusväli (max pikkus 250 tähemärki)) 5. Väljaandja (Sisestusväli (max pikkus 250 tähemärki)) AINULT SISERIIKLIKEST ÕIGUSAKTIDEST TULENEVAD KÕRVALEJÄTMISE ALUSED: KARISTATUD MAKSUALASTE SÜÜTEGUDE EEST Kas ettevõtja on rikkunud RHS § 95 lg 4 p-st 11 tuleneva kõrvalejätmise alusega seotud kohustusi? Viide seadusele: RHS § 95 lg 4 p 11 „keda või kelle haldus-, juhtimis- või järelevalveorgani liiget või muud seaduslikku esindajat on karistatud maksualaste süütegude eest“. Vabatahtlik kõrvaldamise alus. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud. Ettevõtjalt oodatavad vastused: 1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 3. URL (Url) 4. Kood (Sisestusväli (max pikkus 250 tähemärki)) 5. Väljaandja (Sisestusväli (max pikkus 250 tähemärki)) IV OSA: KVALIFITSEERIMISTINGIMUSED B: Majanduslik ja finantsseisund ÜLDINE AASTAKÄIVE Ettevõtja üldine aastakäive on asjaomases teates, hankedokumentides või hankepassis nõutud majandusaastate jooksul järgmine: Viide seadusele: RHS § 100 lg 1 p 4 „andmed pakkuja või taotleja kogu majandustegevuse netokäibe kohta kuni viimase kolme riigihanke algamise ajaks lõppenud majandusaasta jooksul, sõltuvalt pakkuja või taotleja asutamise või äritegevuse alguse kuupäevast“ Tingimuse selgitus: Pakkuja viimase kolme lõppenud majandusaasta summaarne netokäive peab olema kokku vähemalt 200 000 EUR. Pakkuja esitab hankepassis kinnituse ja andmed, et tema kolme viimase lõppenud majandusaasta netokäive kokku on olnud vähemalt 200 000 EUR. Hankija kontrollib esitatud andmeid hankijale avalikes andmekogudes kättesaadava info kaudu. Info kohta, mis ei ole hankijale andmekogudes olevate avalike andmete põhjal oluliste kulutusteta kättesaadavad, kohustub pakkuja hankija nõudmisel esitama täiendavad selgitused, andmed või dokumendid kuni 5 (viie) tööpäeva jooksul alates päringu saamisest. Pakkuja esitab hankepassis vastavad andmed. Kui pakkuja soovib tõendada enda vastavust majanduslikule ja finantsseisundile ja/või tehnilisele ja kutsealasele pädevusele esitatud nõuetele teiste ettevõtjate vahendite alusel, peab pakkuja täitma hankepassi ka selle isiku kohta, kelle vahenditele ta tugineb. Lisaks peab pakkuja Koostatud 29.06.2023 09:40:30 https://riigihanked.riik.ee/rhr-web/#/procurement/6083860/general-info  21 / 22 vastavalt hankija nõudmisele vastuvõetaval viisil tõendama, et sellel ettevõtjal, kelle vahenditele ta tugineb, on vastavad vahendid olemas ning ettevõte on nõus nende vahendite kasutamisega ja pakkuja kasutab neid lepingu täitmisel (RHS § 103 lg 1). RHS § 95 lg 4 p 9: Hankija võib kõrvaldada hankemenetlusest pakkuja, kes on esitanud valeandmeid käesolevas paragrahvis sätestatud või käesoleva seaduse §-des 98–101 sätestatu alusel hankija kehtestatud kvalifitseerimise tingimustele vastavuse kohta või jätnud need andmed või § 104 lõigete 7 ja 8 alusel hankija nõutud täiendavad dokumendid esitamata. Hankepassi esitamine on kohustuslik ka ühispakkujatele. Tingimuse kirjeldus: Miinimumnõue: 200000 Valuuta: EUR Ettevõtjalt oodatavad vastused: 1. Ajavahemik (Periood) 2. Käive (Summa) 3. Valuuta (Vääring) 4. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 5. URL (Url) 6. Kood (Sisestusväli (max pikkus 250 tähemärki)) 7. Väljaandja (Sisestusväli (max pikkus 250 tähemärki)) C: Tehniline ja kutsealane suutlikkus ASJADE HANKELEPINGUTE PUHUL: TÄPSUSTATUD LIIKI TARNETE TEOSTAMINE Ainult asjade riigihankelepingute puhul: Ettevõtja on arvestusperioodi jooksul kohale toimetanud täpsustatud liiki asjade puhul järgmised peamised tarned. Avaliku sektori hankijad võivad nõuda kuni kolme aasta kogemuse tõendamist ja võtta arvesse rohkem kui kolme aasta vanuseid kogemusi. Viide seadusele: RHS § 101 lg 1 p 2 „nimekiri hankija kindlaks määratud tunnustele vastavate asjade müügi lepingutest, mis on täidetud riigihanke algamisele eelneva 36 kuu jooksul, koos teabega nende maksumuse, kuupäevade ja teiste lepingupoolte kohta“ RHS § 101 lg 2 „hankija võib piisava konkurentsi tagamiseks arvesse võtta andmeid rohkem kui 36 kuu eest täidetud asjade müügi lepingute kohta“ Tingimuse selgitus: Pakkuja või taotleja viimase 3 (kolme) aasta jooksul täidetud lepingute hulgas peab olema vähemalt 3 (kolm) hanke objektiga samaväärset lepingut ning esitatavate lepingute kogumaksumus ilma käibemaksuta on kokku vähemalt 100 000 EUR. Lepingud peavad olema täidetud (täitmine on põhikohustuste ulatuses lõppenud). Pakkuja peab hankepassi korrektselt sisestama referentslepingu(te) maksumuse(d), lepingu(te) kuupäeva(d) ja info teise lepingupoole kohta (sh tellija kontaktisiku telefoninumber, e-posti aadress). Juhul, kui tegemist on riigihankega, siis märkida hankepassis ka viitenumber. Kui hankija soovib kontrollida hankepassis esitatud andmeid seoses täidetud lepingutega võib hankija küsida teise lepingu poole käest kinnitusi ja/tõendeid. Kui pakkuja soovib tõendada enda vastavust majanduslikule ja finantsseisundile ja/või tehnilisele ja kutsealasele pädevusele esitatud nõuetele teiste ettevõtjate vahendite alusel, peab pakkuja täitma hankepassi ka selle isiku kohta, kelle vahenditele ta tugineb. Lisaks peab pakkuja vastavalt hankija nõudmisele vastuvõetaval viisil tõendama, et sellel ettevõtjal, kelle vahenditele ta tugineb, on vastavad vahendid olemas ning ettevõte on nõus nende vahendite kasutamisega ja pakkuja kasutab neid lepingu täitmisel (RHS § 103 lg 1). RHS § 95 lg 4 p 9: Hankija võib kõrvaldada hankemenetlusest pakkuja, kes on esitanud valeandmeid käesolevas paragrahvis sätestatud või käesoleva seaduse §-des 98–101 sätestatu alusel hankija kehtestatud kvalifitseerimise tingimustele vastavuse kohta või jätnud need andmed või § 104 Koostatud 29.06.2023 09:40:30 https://riigihanked.riik.ee/rhr-web/#/procurement/6083860/general-info  22 / 22 lõigete 7 ja 8 alusel hankija nõutud täiendavad dokumendid esitamata. Tingimuse kirjeldus: Minimaalne teostatud tööde arv: 3 Kirjeldus: Pakkuja või taotleja viimase 3 (kolme) aasta jooksul täidetud lepingute hulgas peab olema vähemalt 3 (kolm) hanke objektiga samaväärset lepingut ning esitatavate lepingute kogumaksumus ilma käibemaksuta on kokku vähemalt 100 000 EUR. Ettevõtjalt oodatavad vastused: 1. Kirjeldus (Suur sisestusala (max pikkus 4000 tähemärki)) 2. Kogusumma (Summa) 3. Valuuta (Vääring) 4. Ettevõtja vastutusala (Suur sisestusala (max pikkus 4000 tähemärki)) 5. Summa (Summa) 6. Valuuta (Vääring) 7. Ajavahemik (Periood) 8. Kas info on konfidentsiaalne? (Raadionupp valikutega "Jah/Ei") 9. Tellija nimi (Sisestusväli (max pikkus 250 tähemärki)) 10. Kontaktisiku nimi (Sisestusväli (max pikkus 250 tähemärki)) 11. E-mail (Sisestusväli (max pikkus 250 tähemärki)) 12. Telefon (Sisestusväli (max pikkus 250 tähemärki)) 13. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 14. URL (Url) 15. Kood (Sisestusväli (max pikkus 250 tähemärki)) 16. Väljaandja (Sisestusväli (max pikkus 250 tähemärki)) Koostatud 29.06.2023 09:40:30 https://riigihanked.riik.ee/rhr-web/#/procurement/6083860/general-info  EESTI - INFOSÜSTEEMID - TÄITMISREGISTRI HOOLDUS- JA ARENDUSTÖÖD Hanketeade või kontsessiooniteade – üldkord 1. Hankija 1.1 Hankija Ametlik nimi: [Registrite ja Infosüsteemide Keskus] --- Ostja õiguslik vorm: Keskvalitsusasutus Hankija tegevus: Üldised avalikud teenused 2. Menetlus 2.1 Menetlus Pealkiri: Täitmisregistri hooldus- ja arendustööd Kirjeldus: Hanke eesmärk on sõlmida ühe pakkujaga raamleping täitjaga, kes hakkab teostama 24 kuulise raamlepingu perioodil Justiitsministeeriumi Täitmisregistri tarkvara hooldus- ja lisaarendustöid. Menetluse tunnus: c6a4c5ef-84e4-4083-bfe9-37936344f6a0 Sisemine tunnus: 266570 Menetluse liik: Avatud Menetluse peamised põhimõtted: Avatud hankemenetlus 2.1.1 Eesmärk Lepingu olemus: Tarned Peamine liigitus (cpv): 48810000 Infosüsteemid 2.1.2 Lepingu täitmise asukoht Riik: Eesti 2.1.3 Väärtus Eeldatav maksumus käibemaksuta: 200000.00 EUR 2.1.4 Üldine teave Lisateave: Riigihange ei ole ühe menetluse raames osadeks jaotatud, sest raamlepingu esemeks on funktsionaalselt koostoimivad ja sama eesmärgi saavutamiseks vajalikud teenused. Õiguslik alus: Direktiiv 2014/24/EL 2.1.6 Kõrvalejätmise alused Kirjeldus: [https://riigihanked.riik.ee/rhr-web/#/procurement/6083860/procurement-passport] --- 5. Osa 5.1 Osa: LOT-0000 Pealkiri: Täitmisregistri hooldus- ja arendustööd Kirjeldus: Hanke eesmärk on sõlmida ühe pakkujaga raamleping täitjaga, kes hakkab teostama 24 kuulise raamlepingu perioodil Justiitsministeeriumi Täitmisregistri tarkvara hooldus- ja lisaarendustöid. Sisemine tunnus: 266570 https://ted.europa.eu/TED Page 1/4  5.1.1 Eesmärk Lepingu olemus: Tarned Peamine liigitus (cpv): 48810000 Infosüsteemid 5.1.2 Lepingu täitmise asukoht Riik: Eesti 5.1.3 Eeldatav kestus Kestus: 24 MONTH 5.1.5 Väärtus Eeldatav maksumus käibemaksuta: 200 000.00 EUR 5.1.6 Üldine teave Reserveeritud osalus: Ei kohaldata Tuleb esitada lepingu täitmiseks määratud töötajate nimed ja nende kutsekvalifikatsioonid.: Ei ole nõutud Hankeid rahastatakse vähemalt osaliselt Euroopa Liidu vahenditest Hanke suhtes kohaldatakse riigihankelepingut (GPA). Teave eelmiste teadete kohta Lisateave: Riigihange ei ole ühe menetluse raames osadeks jaotatud, sest raamlepingu esemeks on funktsionaalselt koostoimivad ja sama eesmärgi saavutamiseks vajalikud teenused. 5.1.8 Juurdepääsetavuse kriteeriumid Puuetega inimeste juurdepääsukriteeriume pole lisatud, sest hange ei ole mõeldud kasutamiseks füüsilistele isikutele 5.1.9 Valikukriteeriumid Kriteerium Liik: Sobivus tegeleda kutsealase tööga Selle kriteeriumi kasutamine: Ei kasutata Kriteerium Liik: Majanduslik ja finantsseisund Kirjeldus: https://riigihanked.riik.ee/rhr-web/#/procurement/6083860/procurement-passport Selle kriteeriumi kasutamine: Kasutatakse Kriteerium Liik: Tehniline ja kutsealane suutlikkus Kirjeldus: https://riigihanked.riik.ee/rhr-web/#/procurement/6083860/procurement-passport Selle kriteeriumi kasutamine: Kasutatakse 5.1.10 Pakkumuste hindamise kriteeriumid Kriteerium Liik: Hind Kaal (punktid, täpne): 100 5.1.11 Hankedokumendid Keeled, milles hankedokumendid on ametlikult kättesaadavad: EST Hankedokumentide aadress: [ https://riigihanked.riik.ee/rhr-web/#/procurement/6083860/general-info ] --- https://ted.europa.eu/TED Page 2/4  5.1.12 Hanke tingimused Esitamise tingimused Elektrooniline esitamine: Lubatud Avalduse esitamise aadress: https://riigihanked.riik.ee/rhr-web/#/procurement/6083860/tenders Keeled, milles võib pakkumusi või osalemistaotlusi esitada: eesti keel Elektrooniline kataloog: Ei ole lubatud Variandid: Ei ole lubatud Pakkumuste esitamise tähtaeg: 2023-08-18+03:00 12:00:00+03:00 Tähtaeg, mille jooksul pakkumus peab kehtima: 3 MONTH Teave avaliku avamise kohta Kuupäev/kellaaeg: 2023-08-18+03:00 13:00:00+03:00 Koht: https://riigihanked.riik.ee/rhr-web/#/ Lepingutingimused E-arveldamine: Nõutav Kasutatakse elektroonilisi makseid 5.1.15 Meetodid Raamleping Raamleping ilmaminikonkursita Osalejate maksimaalne arv: 1 Teave dünaamilise hankesüsteemi kohta Ei kohaldata 5.1.16 Lisateave, vahendamine ja läbivaatamine Vahendusorganisatsioon: Riigihangete vaidlustuskomisjon Läbivaatav organisatsioon: Riigihangete vaidlustuskomisjon Organisatsioon, mis annab lisateavet hankemenetluse kohta: Registrite ja Infosüsteemide Keskus Organisatsioon, millele laekuvad osalemistaotlused: Registrite ja Infosüsteemide Keskus 8. Organisatsioonid 8.1 ORG-0001 Ametlik nimi: Registrite ja Infosüsteemide Keskus Registreerimisnumber: 70000310 Postiaadress: Lubja tn 4 Linn: Tallinn Sihtnumber: 19081 Riik: Eesti Kontaktpunkt: TEELE NÄSSI E-posti aadress: [email protected] Telefon: +372 58505692 Internetiaadress: http://www.rik.ee/ Hankija profiil: http://www.rik.ee/ Selle organisatsiooni rollidRollid: Hankija Organisatsioon, mis annab lisateavet hankemenetluse kohta: ORG-0001 https://ted.europa.eu/TED Page 3/4  Organisatsioon, millele laekuvad osalemistaotlused: ORG-0001 8.1 ORG-0002 Ametlik nimi: Riigihangete vaidlustuskomisjon Registreerimisnumber: 1000123 Postiaadress: Tartu mnt 85 Linn: Tallinn Sihtnumber: 10115 Riik: Eesti E-posti aadress: [email protected] Telefon: +3726113713 Selle organisatsiooni rollidRollid: Läbivaatav organisatsioon: ORG-0002 Vahendusorganisatsioon: ORG-0002 8.1 ORG-0003 Ametlik nimi: Riigihangete register Registreerimisnumber: TED64 Linn: Tallinn Riik: Eesti E-posti aadress: [email protected] Telefon: +3726113693 Selle organisatsiooni rollidRollid: TED eSender: ORG-0003 11. Teave teate kohta 11.1 Teave teate kohta Teate tunnus/versioon: 36e2bfb3-f19c-400a-b3b6-df9a3d661f79 - 01 Vormi liik: Hange Teate liik: Hanketeade või kontsessiooniteade – üldkord Teate saatmise kuupäev: 2023-06-29+03:00 09:41:15.578+03:00 Keeled, milles käesolev teade on ametlikult kättesaadav: eesti keel 11.2 Avaldamisteave https://ted.europa.eu/TED Page 4/4  KINNITATUD Direktori 10.02.2020 Käskkiri nr 11 Lisa 1 Nõuded arendustele v6.0 Nõude Võti Nõude liik Kokkuvõte Kirjeldus vastutav kontrollija Loodavate lahenduste X-tee Vastavus teenused peavad vastama RIA x- Arendusosa NA-1 üldistele tee juhendis toodud nõuetele. kond standarditele Aluseks tuleb võtta hanke välja kuulutamise hetkel kehtiv versioon. Kui hankes ei spetsifitseerita tarkvaralist lahendust tuleb kasutada vastaval konkreetsele vajadusel allpool toodud tarkvarade viimaseid stabiilseid versioone. Serverite operatsioonisüsteemina: 1) Linux RedHat Enterprise/Centos 2) Windows Andmebaasidena: 1) Microsoft SQL 2) Postgre SQL Vastavus Lahendusega koos tarnitav Veebiserverina: Infrastruktuu NA-2 üldistele standardtarkvara peab vastama 1) Nginx ride standarditele RIK nõuetele 2) Microsoft IIS osakond 3) Apache Rakendusserverina: 1) Tomcat Programmeerimiskeelena : 1) C# 2) Java 3) Python Kui koos tarnega tarnitakse kommertstarkvara peab selle litsents sisaldama vähemalt 5 aasta turvaparandusi Rakendus peab olema kirjutatud nii, et see arvestab selle rakenduse Vastavus poolt töödeldavatele andmetele NA-3 üldistele määratud ISKE klassi nõudeid. standarditele Aluseks tuleb võtta hanke väljakuulutamise hetkel kehtiv ISKE versioon.  Antud nõudes võib erandeid teha ainult juhul, kui on teisiti ette nähtud seadusega või muul tellijaga kokku lepitud põhjendatud juhul. RIKis kasutatavad levinuimad vaba tarkvara litsentsid on EUPL, GNU GPL, MIT. Valik sõltub vajadustest ja kohustustest. Litsentside litsentsitingimustes sisalduvad nõuded, mida tuleb litsentsi kasutamisel täita, on järgmised: EUPLi puhul on nõutav mh: 1) autoriõiguse märge päises (EUPL © Euroopa Liit 2007, 2016, mille järel on märge „Litsentsitud EUPL alusel“); 2) lähtekoodi avalikustamine Euroopa Liidu joinup virtuaalses varamus. GNU GPL puhul on nõutav mh: RIK põhimõte on arendada 1) autoriõiguse märge päises tarkvara avatult ja avaldada (Copyright © <aasta> <autori Vastavus tarkvara vaba litsentsiga. Avaliku nimi>); NA-4 üldistele sektori kohustuseks on arendada 2) litsentsitingimustes ette nähtud Projektijuht standarditele tarkvara eelkõige avatult ja teavitus töö osas garantii avaldada tarkvara vaba litsentsiga välistamise kohta. vastavalt litsentsi nõuetele. MIT puhul on nõutav mh: 1) autoriõiguse märge päises (Copyright © <aasta> <autori nimi>) koos litsentsis ette nähtud teavitusega; 2) litsentsitingimustes ette nähtud teavitus töö osas garantii välistuse kohta. Täpsemalt tuleb nõuetega tutvuda lähtudes valitud litsentsitüübi litsentsitingimustest. Valitud litsentsi litsentsitingimused esitatakse ühel või mõlemal alljärgnevatest viisidest: 1) LICENCE-fail peab olema repositooriumis avalikustatud koos tarkvara koodiga; 2) litsentsitingimuste tekst iga faili päises; 3) lisades päisesse link asukohale, kus on võimalik litsentsitingimustega tutvuda.  Rakenduse, andmebaasi ja kolmanda osapoole komponentide Infrastruktuu platvorm(id)/versioon(id) peavad Kui on tuleb tellijaga paika panna ja NA-5 Arhitektuur ride olema sellised, mille eluea lõpp kokku leppida vahetuse strateegia. osakond (EOL) pole teadaolevalt vähem kui 4 aasta pärast. Tulevase ja olemasolevate infosüsteemide platvormid (rakendusserver, andmebaas, Süsteemi jõudlus peab vastama Infrastruktuu kolmanda osapoole komponendid) kokkulepitud topoloogial eelanalüüsi NA-6 Arhitektuur ride ja topoloogia peab olema enne ja lähteülesande käigus välja toodud osakond reaalse arenduse algust RIK jõudlusnäitajatele. Infrastruktuuride osakonnaga kooskõlastatud. Rakendusserver peab võimaldama Infrastruktuu NA-7 Arhitektuur töötamist andmebaasiserverist ride eraldi serveril. osakond Rakendust peab saama ilma ümber Haldur koos programmeerimata liigutada Lahendus ei tohi olla sisse infrastruktuu NA-8 Arhitektuur erinevate domeenide ja domeeni kompileeritud absoluutseid URL-e. ride saitide vahel osakonnaga Liideseid peab saama konfiguratsioonist välja lülitada. Väliste liidestatud süsteemide tõrke korral ei tohi süsteem hanguda, vaid peab väljastama mõistliku (võimalikult lühikese) aja jooksul Tõrkekindluse tagamiseks tuleb ajakohase veateate. Võimalusel Haldur koos väliseid liidestusi kasutada nii vähe tuleb töökindluse tõstmiseks infrastruktuu NA-9 Arhitektuur kui võimalik. Kui need on vajalikud, kasutada asünkroonseid liideseid ride siis peavad nad olema võimalikult (ntäiteks Rahvastikuregistri, Maa- osakonnaga tõrkekindlad. ameti infosüsteemi või Google analythicsk´i töötamast lakkamisel peab süsteemi põhifunktsionaalsus,kui süsteemi äriloogika seda võimaldab, tööle jääma). Andmevahetus riigi infosüsteemi kuuluvate andmekogudega ja riigi infosüsteemi kuuluvate Kui X-tee päringut teostab inimene, NA-10 Arhitektuur andmekogude vahel toimub läbi siis peab olema päringu päises Haldur riigi infosüsteemi autentinud kasutaja andmed. andmevahetuskihi (x-tee). Avaliku teabe seaduse § 43 (9) lõige 5. Rakenduse testkeskkonnad Infrastruktuu peavad olema ühendatud test X- NA-11 Arhitektuur ride teega ja arenduskeskkonnad osakond arendus X-teega. Rakenduse Rakendus peab neid sealt ka konfiguratsiooniparameetrid tuleb kasutama (mitte kopeerima Arendusosa ühte kohta kokku tuua nii, et nende parameetreid käivitamisel kond koos muutmisel ei peaks rakendust kolmandatesse kohtadesse). NA-12 Arhitektuur infrastruktuu uuesti kokku kompileerima (nt ühte Logimise seaded võivad olla ride tekstipõhisesse rakenduse konfiguratsioonifailist osakonnaga konfiguratsioonifaili, andmebaasi eraldi ühes lisakonfiguratsioonifailis tabelisse). (näit Log4net).  Mõistlikuks ajaks loetakse Arendusosa Rakenduse kompileerimine (saidi maksimaalselt 30 sekundit. Kui kond koos taaskäivitas, konfiguratsiooni rakendus vajab indekseeritud sisu ja NA-13 Arhitektuur infrastruktuu muutmine vms) peaks toimuma see pole kättesaadav, siis peab ride mõistliku aja jooksul. rakendus väljastama selle kohta osakonnaga selge teate. Infrastruktuu NA-14 Arhitektuur Rakendus peab olema 64-bitine. ride osakond Arendusosa kond koos Andmebaas ja rakendus peavad Nõue kehtib Oracle ja Postgre NA-15 Arhitektuur infrastruktuu kasutama UTF-8 kodeeringut. andmebaaside puhul. ride osakonnaga Failisüsteemi salvestamisel ei tohi Arendusosa ühte kausta tekkida üle 10000 objekti Failid peab katalogiseerima kond koos (kaust või fail). Failistruktuur peab NA-16 Arhitektuur kokkulepitud tunnuste alusel infrastruktuu olema mõistlik (kaustu ei tohi olla (aasta, kuu, kuupäev). ride rohkem kui faile) ning ei tohi tekitada osakonnaga märgatavat jõudluskadu. Kasutatav programmeerimise Arendusosa NA-17 Arhitektuur paradigma on objekt-orienteeritud. kond Andmebaasis peab kasutama indekseid või muid meetmeid, et nõuded jõudlusele oleksid täidetud Kõik välised võtmed (Foreign Key) ka tulevikus (1, 3, 5 või 10 aasta NA-18 Arhitektuur Haldur peavad olema indekseeritud. pärast – vastavalt planeeritud kasutusajale). Väliseid võtmeid tuleb kasutada ka ühest andmebaasist teisele viitamisel. SQL päringute väljakutsumisel väljastpoolt andmebaasi, peab kasutama päringumuutujaid, et Tuleb kasutada päringumuutujaid vältida SQL vahemälu Arendusosa NA-19 Arhitektuur (Parameter Binding). fragmentseerumist (When calling kond SQL code from outside the database, Parameter Binding should be used to prevent SQL cache fragmentation). Kõigis andmebaasi tabelites peab olema defineeritud üks tehniline NA-20 Arhitektuur Haldur primaarvõti ja selle nimetus peab olema „ID“. Failide hoidmise asukoht lepitakse iga kord eraldi kokku. Failide Failid ja failide indeks peavad Infrastruktuu hoidmine klassikalises andmebaasis NA-21 Arhitektuur olema replikeeritavad teise ride on kulukas ja seab kõrgendatud serveriruumi. osakond nõudmised ning piirangud andmebaasiserveritele. Rakendusel peab olema haldusliides, mille kaudu rakenduse Vajadus halduril teha otse baasis haldur saab teha tavapäraseid NA-22 Arhitektuur haldustoiminguid peab olema Haldur haldustoiminguid. Halduri viidud miinimumini. haldustoimingud lepitakse tellijaga kokku detailanalüüsi käigus.  Andmebaas peab toetama nii külm- Ei tohi kasutada teenuseid, mis Infrastruktuu NA-23 Arhitektuur kui ka kuumvaru (peegeldamist) välistavad andmebaasi peegeldamist ride teise serveriruumi. (nt "failstream"). osakond Tõusutundlikkus peab olema välja Infrastruktuu Sorteerimisreeglistik peab vastama lülitatud ning accent peab olema NA-24 Arhitektuur ride eesti keele tähestikule. sisse lülitatud. Näiteks: MS SQL osakond puhul Estonian_CI_AS. Kirjade tekst peab olema haldurite poolt hallatav. Kirja saatmisel peab süsteem veenduma, et elektronposti server võttis meili vastu. Kui Kui süsteem saadab elektronkirju, elektronposti server millegi pärast Infrastruktuu NA-25 Arhitektuur peab kasutama süsteemivälist RIK- kirju vastu ei võta, tuleb kirjad ära ride i elektronposti serverit. saata pärast seda kui elektronposti osakond server jälle vastab. Kirjad saatmist peab olema võimalik lihtsalt (näiteks muudatuse ajaks) rakenduse konfiguratsioonist kinni keerata. Arendusosa Konfiguratsiooniparameetrite Näiteks : X-tee Turvaserver, mitte kond koos nimed peavad olema sisulised. NA-26 Arhitektuur XTTS või viitenumber, mitte vk_seb infrastruktuu Juhul kui see ei ole võimalik, peab jne. ride kõrval olema selgitus. osakonnaga Tagasüsteemide ülesanneteks on andmete haldamine ja võrguteenuste Infosüsteemides on eessüsteemid pakkumine. Tagasüsteemid ei tegele Infrastruktuu (front end) ja tagasüsteemid (back NA-27 Arhitektuur lõppkasutaja autentimise ja ride end) arhitektuuriliselt selgelt autoriseerimisega. Lõppkasutaja osakond lahutatud. autoriseerimise tagavad eessüsteemid. Näiteks IIS: *.config , *.resources Arendusosa Konfiguratsioonifailid peavad Apache: *.conf, .htaccess. Kui neid kond koos NA-28 Arhitektuur olema vastavalt rakendusserveri on mitu, siis arendaja peab need infrastruktuu tüübile vaikimisi kaitstud failid eraldi välja tooma ride konfiguratsioonifailide listis. osakonnaga Näiteks: IIS: Bin,App_Code, Arendusosa Rakenduse failid, mida kasutaja App_Data, App_Browsers, kond koos NA-29 Arhitektuur näha ei tohi, peavad olema App_GlobalResources, infrastruktuu vaikimisi kaitstud kaustades. App_LocalResources, App_Themes, ride App_WebReferences osakonnaga Arendusosa Kõiki parameetreid tuleks Konfiguratsioonis ei tohi olla kond koos konfiguratsioonis kirjeldada vaid uhe NA-30 Arhitektuur erinevaid parameetreid, mis on infrastruktuu korra (mitte nii, et mitmes lõigus sama sisuga. ride kirjeldatakse samu asju uuesti). osakonnaga Rakendustes tohib kasutada vaid masinapõhiseid teenuseid, mis lubavad kõrgkäideldavaid (klaster) Arendusosa lahendusi. Kõrgkäideldav kond koos Kõik rakendused peavad töötama lahendus peab olema selline, mida NA-31 Arhitektuur infrastruktuu kõrgkäideldavalt. saab samaaegselt käitada ride erinevates masinates. osakonnaga Kasutajasessioon ei tohi olla ühe klastri üle põhine. Ei tohi kasutada sticky sessioneid.  Arendusosa kond koos Klientrakendus ei tohi pöörduda otse NA-32 Arhitektuur Tuleb kasutada rakendusservereid. infrastruktuu andmebaasi poole. ride osakonnaga Arendusosa Keskkonnapõhiseid muutujad kond koos Näiteks WSDL ei tohi sisaldada NA-33 Arhitektuur peavad olema konfiguratsioonist infrastruktuu viiteid arendusserveritele. seadistatavad. ride osakonnaga Kui kasutatakse Windows Infrastruktuu teenuseid peavad teenuste nimed NA-34 Arhitektuur ride olema serveri administraatori poolt osakond konfigureeritavad. Andmebaas ei tohi sisaldada Rakenduse äriloogika tuleb äriloogikat, mis muudab Arendusosa NA-35 Arhitektuur realiseerida eraldi andmebaasist andmetabelites olevaid ja sinna kond sõltumatus rakenduskihis. kirjutatavaid andmeid. Erandiks on trigerid, mis tekitavad logi. Ei ole tohi kasutada selliseid platvormispetsiifilist lahendusi, mille Andmebaasis võib kasutada vaid üleviimine mõnele muule ISO/IEC 9075 standardiga kaetud andmebaasiplatvormile ei ole Arendusosa NA-36 Arhitektuur funktsionaalsusi. Kuid erandina ei võimalik. kond tohi kasutada sama standardi osas 13 kirjeldatud funktsionaalsusi. ISO/IEC 9075 osa 13 spetsifitseerib Javas kirjutatud programmimoodulite kasutamist andmebaasis. RIK kasutab keskset autentimislahendust (AUP). Kui kui mõni ärinõue välistab AUP kasutamise, esitab RIK arendajale lisanõuded autentimissüsteemile. Haldur koos Rakendus peab kasutama Kasutatavaid autentimisviise peab infrastruktuu NA-37 Arhitektuur autentimiseks RIK olema rakenduse konfiguratsioonist ride autentimisportaali AUP. võimalik sisse ja välja lülitada. osakonnaga Samuti peab rakenduse konfiguratsioonist olema määratav kas ID-kaardiga autenimise korral kasutatakse OCSP või tühistusnimekirjade põhist autentimist. Uniform resource identifier (URI) Haldur koos pikkus ei tohi ületada ühegi IS poolt NA-38 Arhitektuur Max uri < 2000. arendusosa toetatava brauseri maksimaalset konnaga lubatud väärtust. Rakenduse teenusekirjeldus (n: Näiteks: Alajaotis WSDL) peab olema üles ehitatud definitions/types/schem: Arendusosa NA-39 Arhitektuur nii, et see toetaks teenuse complexType defineerimisel tuleb kond versioneerimist. sellele lisada "any" element.  Juhul kui äriprotsess seda Arendusosa võimaldab, tuleb suurte kond koos Rakenduse operatiivbaas peab NA-40 Arhitektuur andmemahtude korral kasutada infrastruktuu olema võimalikult väike. andmete arhiveerimist põhibaasist ride väljapoole. osakonnaga Rakendusega tarnitavad litsentsid Infrastruktuu EU projektide korral tuleb kehtivusaja NA-41 Arhitektuur peavad olema vähemalt 5 aastase ride suhtes lähtuda EU või RIA nõuetest. kehtivusega. osakond Eraldatud peavad olema teenused, kuhu pöörduvad kasutajad ja need teenused, kuhu pöörduvad teised teenused ja serverid (näiteks saidid). Rakendus peab olema tehniliselt Avalikud liidesed tuleb selgelt osadeks jaotatud (tükeldatud) eristada muudest mitteavalikest, vastavalt loogilisele jaotusele. sisemistest, konfigureerimis jms Arendusosa NA-42 Arhitektuur Saadud osised peavad olema liidestest. Kui rakendusel on eraldi kond eraldi versioneeritavad ja turvatasemega liidesed ametnikule ja paigaldatavad. kodanikule, peab rakendus olema jaotatud kaheks eraldi liidesekomponendiks ning nende mõlema poolt kasutatavaks andmebaasiks. Kõik dokumentide konverteerimised ühest formaadist Arendusosa NA-43 Arhitektuur teise tuleb teha kasutades RIK kond keskseid dokumentide konverteerimise teenuseid. Haldur koos Süsteem ei tohi võimaldada arendusosa kasutajale ligipääsu süsteemi konnaga ja NA-44 Arhitektuur toimimise informatsioonile, nagu infrastruktuu failide täisnimed (path), kutsepinud ride (stack trace) jms. osakonnaga Arendusosa Rakendus peab olema võimeline SSL offload, vajalike kond koos NA-45 Arhitektuur töötama koormusjaoturitega kliendiparameetrite edasiandmine infrastruktuu varustatud taristul. kasutades http headereid. ride osakonnaga Arendusosa Rakenduse failidele ei tohi olla kond koos NA-46 Arhitektuur rohkem ligipääsuvajadust, kui read- infrastruktuu execute. ride osakonnaga Kui on planeeritud kasutada Windows servereid peavad kõik Infrastruktuu NA-47 Arhitektuur rakenduse osad (ka baas) olema ride võimelised töötama windows core osakond serveritel. Näiteks, kui on tegemist Andmebaasis tuleb veerutüübiks kuupäevaga, siis date. Kasutada ei NA-48 Arhitektuur määrata selleks sisuliselt sobivaim Haldur tohi varchar(max) andmetüüpi, kui andmetüüp. see pole põhjendatud ja vajalik.  Rakendus peab väljastama oma SOAP teenuste wsdl'e, REST Haldur koos NA-49 Arhitektuur masinliideste teenuste tehnilisi teenustele n:swaggeri v. openapi arendusosa spetsifikatsioone. formaadis kirjeldusi. konnaga Active Directory (AD) autentimise kasutamisel peab rakendus Infrastruktuu kasutama SAML2.0 (Security Teiste standardite kasutus tuleb RIK- NA-50 Arhitektuur ride Assertion Markup Language) ja iga eelnevalt kooskõlastada. osakond ADFS (Active Directory Federation Services) standardeid. Edasine koodi täitmine ja võimalike veaolukordade töötlus peab toimuma rangelt ainult kliendi poolel. Kliendi autentimissertifikaadi kehtivus- ja autentsusekontroll teostatakse maksimaalses võimalikus mahus veebiserveri või proxy poolt. Autentimissertifikaadil on veebiserveri või proxy poolt ID-kaardiga (kliendi sertifikaadiga) kohustuslikult nõutav: autentimist teostavad veebirakendused peavad (juhul, kui Apache: SSLVerifyClient require; Infrastruktuu NA-51 Arhitektuur sessiooni pole algatatud) suhtlema NGINX: ssl_verify_client on; ride kliendi veebirakendusega ainult Pulse TM: ssl.requireCert(); osakond selleks, et saada veebirakendusest HAProxy: verify required; sisselogimiseks vajaliku koodi. Tomcat: clientAuth="true"; jne… Juhul kui toimub pöördub URL poole, kus on nõutud kliendi autentimissertifikaat ning server vastab veaga, peab klientrakendus kuvama korrektse eesti keelse veateate. NB! Rakenduse javascrip-ti tuleb ID- kaardiga autentimise puhuks erand kirjutada! Tuleb kasutada vaid RIK poolt ette NA-52 Arhitektuur antud captcha lahendust. Rakendustevaheline suhtlus tuleb Sobivad liideste formaadid lepitakse NA-53 Arhitektuur realiseerida läbi rest- või soap-vms kokku projekti käigus. veebiteenuste või message queue. Serveris peab olema kirjeldatud, Mitte kirjeldatud meetoditele ei tohi NA-54 Arhitektuur millistele HTTP meetoditele vastata. vastatakse. Meiliaadress peab vastama RFC5322 ja/või RFC6854 standardile. Süsteem, kuhu on Vigastele meiliaadressidele ei tohi NA-55 Arhitektuur võimalik e-posti aadresse sisestada, kirju saata. peab kontrollima nende kehtivust. Kasutaja kontaktinfo tuleb alati valideerida.  Rakendusel peab olema CSP Erandid tuleb kirjeldada NA-56 Arhitektuur header. Vaikeväärtus on "self". pigaldusjuhendis. Turvalisuse ja Tuleb arvestada tingimusega, et Haldur koos Kliendi ja serveri vaheline side terviklikkuse osad ühendused nõuavad infrastruktuu NA-57 peab olema krüpteeritud SSL- tagamisega kahepoolset SSL autentimist (nt: ride protokolli kasutades. seotud nõuded suhtlus turvaserveriga). osakonnaga Turvalisuse ja terviklikkuse Rakendus ei salvesta andmeid Erandiks on mitmekeelse süsteemi Arendusosa NA-58 tagamisega kliendi arvutisse (sh küpsiseid). puhul keelevalik. kond seotud nõuded Sessiooni lõpetamine Turvalisuse ja infosüsteemis (nt logi välja nupu terviklikkuse NA-59 vajutamine) peab serveri poolt tagamisega sessiooni tunnused kehtetuks seotud nõuded tunnistama (nt küpsised). Kõik andmemuudatused peavad baasis säilima. Andmete muutmisel andmeid ei kustutata, vaid tehakse uus kirje uute andmetega. Vana kirjed muudetakse kehtetuks. Iga uus kirje peab sisaldama vähemalt järgmist informatsiooni: 1) viide kirjele, mille ta kehtetuks Kui andmebaasis olevate andmete muutis (kui on); Turvalisuse ja ISKE tervikluse klass on 2 või 2) kasutaja, kes kirje lõi; terviklikkuse NA-60 kõrgem, tuleb kõik klass 2 infot 3) kirje loomise aeg; Haldur tagamisega sisaldavad andmebaasi kirjed ja 4) sessiooni-ID (kui on olemas). seotud nõuded tabelid versioneerida. Iga kehtetuks tunnistatud kirje peab sisaldama lisaks vähemalt järgmist informatsiooni: 1) kasutaja, kes kirje kehtetuks tunnistas; 2) kirje kehtetuks tunnistamise aeg. Kui rakenduse poolt töödeldavate Testandmed peavad säilitama kõik andmete konfidentsiaalsusklass on toodangu andmete omadused Turvalisuse ja 2 või kõrgem, peab rakendusega (pikkuse, tüübi) ja omavahelised terviklikkuse NA-61 kaasas olema lahendus, mis suhted. Toodanguandmetest Haldur tagamisega suudab toota toodangu andmetest testandmete tegemise algoritmid ja seotud nõuded testandmed, mis ei sisalda põhimõtted tuleb eelnevalt konfidentsiaalset informatsiooni. kooskõlastada tellijaga. Schema muutmine ei ole rakenduse töö. Schema omanik ei tohi olla rakenduse tööks kasutatav baasi kasutaja. Turvalisuse ja Andmebaasis olevate rakenduse Infrastruktuu terviklikkuse kontod peavad omama ainult NA-62 tagamisega minimaalselt rakenduse tööks Nõude täitmiseks vajalikud vahendid ride (skriptid) peavad kuuluma rakenduse osakond seotud nõuded vajalikke õiguseid. juurde ja nende sisu peab olema kontrollitav. Kontodele vajalikud õigused peavad olema kirjeldatud rakenduse installatsioonijuhendis.  Turvalisuse ja Rakenduse lõppkasutajatele peab Rakendusepõhiseid kasutajarolle ei terviklikkuse NA-63 olema võimalik jagada õigusi läbi tohi defineerida ainult läbi AD OU'de Haldur tagamisega andmebaasis defineeritud rollide. ja gruppide. seotud nõuded Ligipääs rakendusse ja andmetele Turvalisuse ja tohib olla vaid dokumenteeritud terviklikkuse Arendusosa NA-64 ning tellimuses kirjeldatud teid tagamisega kond mööda ja dokumenteeritud seotud nõuded autentimisprotseduure kasutades. Räsimine peab kasutama turvalist räsifunktsiooni (NA-74) ja soola (salt). Sool peab olema Turvalisuse ja Kõik paroolid ja salasõnad peab andmebaasiüleselt unikaalne, terviklikkuse rakendus alati salvestama vaid piisavalt suure bitiarvuga ja Arendusosa NA-65 tagamisega krüpteeritud või räsitud ja soolatud "random". Krüpteerimata kujul ei tohi kond seotud nõuded kujul. paroole salvestada (ka ajutiselt) ühelegi kettale. Krüpteering peab olema CBC, CRT vms režiimis. Kasutada ei tohi ECB režiimi. Kindlasti peab olema kasutusel ID- Rakendused, kuhu saavad ligi kaardi põhine autentimine. välised kasutajad, peavad Turvalisuse ja võimaldama autentimist vähemalt Kui on vajalik ka parooliga logimine, terviklikkuse NA-66 tagamisega kahe erineva Eesti riigi poolt peavad välised kasutajad autentima Haldur seotud nõuded aktespteeritava kaheastmeilse ennast spetsiaalse väliskasutajate isikutuvastsulahendusega. jaoks mõeldud AD pihta. Mingil juhul Parooliga autentimsit tuleb vältida. ei tohi väliskasutajaid teha RIK-i sisemisse AD-sse. Turvalisuse ja Kasutajaarvutitest otse x-tee terviklikkuse Rakendus ei tohi teostada X-tee Arendusosa NA-67 päringute tegemine on arvutivõrgu tagamisega päringut otse kasutajaarvutist. kond tasemel keelatud. seotud nõuded IIS puhul peab kasutama näiteks URL scan, apache puhul Veebipõhised välise veebilehega modsecurity või vastavat tööriista. Arendaja Turvalisuse ja rakendused, mis on keskmise või Võimalikud piirangud tuleb kokku koos terviklikkuse NA-68 kõrgema ISKE klassiga peavad leppida tellijaga detailanalüüsi käigus Infrastruktuu tagamisega kasutama vahendeid kaitsmaks lähtuvalt tellija vajadustest ja ride seotud nõuded rakendust keelatud päringute eest. nõudmistest. Kasutama peab osakonnaga whitelisting põhimõtet, mitte blacklistingut. Sarnaselt õnnestunud sisselogimisega, tuleb ebaõnnestunud sisselogimise Kui rakenduse mõni ISKE klass on katsete korral kuvama millal need Turvalisuse ja 2 või kõrgem, peab rakendus toimusid ja mitu neid oli. Kasutaja terviklikkuse NA-69 sisenemisel näitama pärast peab saama soovi korral veenduda, Haldur tagamisega õnnestunud sisselogimist eelmise kas keegi pole tema nime all üritanud seotud nõuded õnnestunud sisselogimise aega. sisse logida. ID-kaardi, mobiil-ID ja digi-ID-ga sisenemise ürituse ebaõnnestunud katseid näitama ei pea.  Mõeldud on spetsiaalrakendusi Turvalisuse ja Rakenduse kasutajaliidesest peab (custom built). Nõue ei kehti terviklikkuse olema kasutajal avalehel ilma sisse veebitarkvara (apache, IIS jne), NA-70 Haldur tagamisega logimiseta võimalik näha andmebaaside jms kohta. Viimaste seotud nõuded rakenduse versiooni numbrit. versiooni numbrit tuleb pigem varjata. Aeg peab olema muudetav koos Sessioonide lõpetamine tuleb teiste Turvalisuse ja teostada serveri poolel ja kõigil konfiguratsiooniparameetritega. Kui Infrastruktuu terviklikkuse NA-71 rakendustel peab olema kliendilt pole etteantud aja jooksul ride tagamisega konfigureeritav kasutajasessiooni ühtegi päringut tulnud, tuleb osakond seotud nõuded aegumise aeg. sessioon serveri enda algatusel lõpetada. Veebipõhiste rakenduste Arendusosa Turvalisuse ja mitteautentinud kasutajate poolt Soovitatavalt tuleb seda teha enne kond koos terviklikkuse NA-72 saadetud vormid tuleb puhastada andmebaasi salvestamist, vajadusel infrastruktuu tagamisega XSS-filtriga või eemaldada HTML- andmete väljakuvamisel. ride seotud nõuded tag´id. osakonnaga Veebipõhiste rakenduste poolt Arendusosa Turvalisuse ja saadetavad vormidel peab kond koos terviklikkuse NA-73 paiknema peidetud unikaalne räsi, Eesmärk on vältida CSRF rünnakuid. infrastruktuu tagamisega mida kontrollitakse vormi ride seotud nõuded vastuvõtmisel. osakonnaga Valida tohib vaid neid, mille soovituslik kasutusaeg RIA krüptoprotokollide elutsükliuuringu uuringu kohaselt on üle 12 aasta. Kui räsimine ei pea tagama pikaajalist salastaatust ja tõestusväärtust võib tellijaga kokkuleppel kasutada algoritme, mille soovituslik kasutusaeg on krüptoprotokollide elutsükliuuringu uuringu kohaselt üle 5 aasta. Turvalisuse ja Krüpteerimise ja räside arvutamise Kui tehniliselt vähegi võimalik tuleb terviklikkuse Arendusosa NA-74 korral tuleb kasutada tugevaid sertifikaate hoida RIK HSM tagamisega kond algoritme. lahenduses. Ligipääs võtmetele ja seotud nõuded sertifikaatidele peab olema vaid teadmisvajaduse põhimõttel. Kirjandus: NIST SP-800- 57 Key Management Guidelinesja European Payments Council (2017) Guidelines on cryptographic algorithms usage and key management. Süsteemi kirjelduses tuleb välja tuua kõik krüptoalgoritmid, võtmepikkused ja kasutuskohad. Turvalisuse ja Autenditud sessiooni tunnust ei tohi Sessiooni ei tohi olla võimalik üle terviklikkuse ainult lihtsa küpsisega lahendada Arendusosa NA-75 võtta URLi kopeerimisega ühest tagamisega (kasutada OWASP parimaid kond arvutist teise. seotud nõuded praktikaid).  Halduritel ei tohi olla võimalik Turvalisuse ja Haldur koos muuta rakenduseväliste liidestuste- Tagada tuleb rollide lahusus: terviklikkuse infrastruktuu NA-76 ning nendega seotud äriloogiliste administraatoril ja halduril on tagamisega ride funktsionaalsuste tehnilisi erinevad tööülesanded. seotud nõuded osakonnaga konfiguratsioone. Arendusosa Turvalisuse ja ID-kaardiga autentimisel, peab kond koos terviklikkuse NA-77 rakendus suutma vastu võtta ID- Proxy tugi infrastruktuu tagamisega kaardi sertifikaati ka HTTP päises. ride seotud nõuded osakonnaga Turvalisuse ja Kõik digitembeldamist vajavad terviklikkuse rakendused peavad kasutama RIK- Arendusosa NA-78 tagamisega i-keskset digitembeldamise kond seotud nõuded teenust. Veebirakendus peab probleemideta läbima OWASP ASVS põhineva Arendusosa testi. Esmane väline turvatestimine kond koos Turvalisuse ja Rakenduse turvalisuse tagamiseks tellitakse tellija finantseeringul. Kui infrastruktuu terviklikkuse (näiteks XSS, SQLInjection, jne) selle tulemusel leitakse arendaja ride NA-79 tagamisega tuleb järgida OWASP-i parimaid poolsest tegevusest või osakonna ja seotud nõuded praktikaid. tegevusetusest põhjustatud vigu, sisekontrolli- võib tellija nõuda OWASP ja infoturbe järeltestide kompenseerimist osakonnaga arendajalt. Toodangukeskkonna rakendus ei tohi sisaldada osiseid, mis on Turvalisuse ja toodangu keskkonnas ebavajalikud terviklikkuse Arendus peab olema orienteeritud Arendusosa NA-80 või segavad (näiteks mõeldud tagamisega toodangukeskkonnas toimimiseks. kond testimiseks testkeskkonnas, seotud nõuded arendusabiks arenduskeskkonnas jne). Arendusosa Turvalisuse ja kond koos terviklikkuse Ajatemplite kasutamisel Ajatempli serveri URL peab olema NA-81 infrastruktuu tagamisega eelistatakse Guardtime lahendust. konfigureeritav. ride seotud nõuded osakonnaga Turvalisuse ja Rakendus ei tohi lubada ühe terviklikkuse Nõue ei kehti, kui see tellija poolt NA-82 kasutajaga mitut samaaegset Haldur tagamisega eraldi ärinõuetes nõutud. sessiooni. seotud nõuded  Konkreetne lahendus valitakse ja lepitakse tellijaga eraldi kokku. Käesoleva nõude täpsustuseks vt ISKE nõue HT.34. Ajatemplite, digitemplite ja digitaalallkirjade terviklust tuleb reaalajas ja hiljem perioodiliselt (muudetava perioodiga) valideerida. Valideerimise protsessi tulemusena tuleb genereerima Turvalisuse ja Kui rakenduse tervikluse klass on automaatne raport, mis on vaadeldav Haldur koos terviklikkuse T3 peavad tõestusväärtust omavad süsteemi halduri liidese kaudu ning NA-83 arendusosa tagamisega andmed olema digitaalallkirjastatud mida on võimalik automaatselt konnaga seotud nõuded või digitembeldatud. edastada ettenähtud e-posti dressidele. Raport peab sisaldama infot valideerimise protsessi alguse ja lõpu aja kohta, infot selle kohta, kui mitut ajatemplit kontrolliti ja kas infot kõik ajatemplid olid korrektsed. Kui tembeldamises või allkirjastamises ilmneb viga, peab olema võimalik hiljem katkenud kohast tembeldamist või allkirjastamist jätkata. Ahela moodustamiseks ei tohi kasutada andmetesse kirja pandud viiteid (n: id=2ja andmed="mingid andmed", eelmine_andmed=1 ). Krüptoahela koostamisel tuleb kasutada lahendust, kus järgmise ajatembeldatava kirje koosseisu fikseeritakse eelmise kirje mitte ajatembeldatud räsi. Uue ahela lüli lisamisel tuleb kontrollida eelmise lüli Kui rakenduse tervikluse klass on korrektsust. Turvalisuse ja T3 peavad tõestusväärtust omavad Haldur koos terviklikkuse andmed ja logid olema NA-84 tagamisega krüptoaheldatud, et tagada et Tagatud peab olema ka nõue, et arendusosa seotud nõuded tõestusväärtusega andmeid ei kirjeid ei saaks märkamatult konnaga saaks märkamatult kustutada. kustutada ahela lõpust. Krüptoahela terviklust peab saama perioodiliselt (muudetava perioodiga) kontrollida ja lahendus peab suutma vajadusel and häire (e-kiri) kui terviklus on kompromiteeritud. Krüptoaheldamis e ja selle kontrolli sisse ja väljalülitamine ning kontrolliperioodi muutumiine peab olema teostatav vaid rakenduse konfiguratsioonist rakenduse administraatori poolt, Sümmeetrilise võtme turvamiseks tuleb kasutada asümmeetrilisi algoritme. Sertifikaati tuleb hoida nii, Turvalisuse ja Kui rakenduses on S3 salastatuse et see oleks kättesaadav terviklikkuse astmega andmeid, peavad need nii rakendusele, kuid mitte Arendusosa NA-85 tagamisega transpordil kui ka salvestatult alati rakendusserveri administraatorile. kond seotud nõuded olema krüpteeritud kujul. Sertifikaat peab olema vahetatav, st krüptograafia edasi arenedes peab olema võimalik kasutusele võtta tugevam sertifikaat.  Kui paks klient kasutab ajutisi faile, Paksu kliendi korral ei tohi tuleb tagada nende perioodiline rakendus kasutaja tööjaama jätta Turvalisuse ja kustutamine tagamaks, et ei maha krüpteerimata kujul ajutisi Haldur koos terviklikkuse koormata liigselt kasutaja arvutit. NA-86 faile, mis sisaldavad või võivad arendusosa tagamisega Eesmärk on tagada, et rakenduse sisaldada konfidentsiaalset või konnaga seotud nõuded sulgemisel ei jääks kasutaja kõrget terviklust nõudvat arvutisse maha informatsiooni, mida informatsiooni. sinna jääda ei tohiks. Arendusosa Turvalisuse ja Rakendus peab serverist Kui kasutatakse ajutiste failide kond koos terviklikkuse NA-87 kustutama kõik ajutised failid kausta peab selle asukoht olema infrastruktuu tagamisega koheselt, kui neid enam ei kasutata. konfiguratsioonist konfigureeritav. ride seotud nõuded osakonnaga Rakendus tohib aktsepteerida vaid Turvalisuse ja sessioonivõtmeid, mida ta ise on terviklikkuse väljastanud. Sisselogimisel peab Arendusosa NA-88 tagamisega kasutaja saama uue sessiooni kond seotud nõuded võtme ning endine võti tuleb kehtetuks tunnistada. Faili nimes tuleb lubada vaid suur- ja Kui rakendusse laaditakse faile väiketähti, numbreid, "_" ja "-" ning Turvalisuse ja kasutaja poolt, peab need failid vaid ühte punkti järjest. Viirusetõrje Haldur koos terviklikkuse NA-89 valideerima (kontrollima faili tüüpi, lahenduse pakub välja RIK arendusosa tagamisega suurust). Failid peavad läbima infrastruktuuride osakond. konnaga seotud nõuded viirusetõrje. Võimalusel tuleb teha tüübi ja faili laiendi vastavuse kontroll. Arendusosa Turvalisuse ja Kui rakendusse laetakse faile peab kond koos terviklikkuse faili nimi salvestamisel sisaldama NA-90 infrastruktuu tagamisega random komponenti nii, et faili tee ride seotud nõuded ei ole lihtsalt ära arvatav. osakonnaga Turvalisuse ja Iframe-i kasutamine pole lubatud ja terviklikkuse Rakendus ei tohi lubada ennast NA-91 HTTP päringutele tuleb lisada "X- tagamisega kasutada iframe sees. Frame-Options: DENY" päis. seotud nõuded Turvalisuse ja Sessiooni küpsise korrala tuleb Infrastruktuu terviklikkuse Sessiooni küpsised peavad olema lisada lipud Secure, HttpOnly NA-92 ride tagamisega turvatud. ja SameSite. Küpsise nime prefiks osakond seotud nõuded peab olema "__Host-". Testplaan ja testitulemused tuleb Logimine, Rakenduse kõik üleantavad edastada tellijale koos rakenduse NA-93 debuggimine, versioonid peavad enne tellijale üle üleandmisega. Nõuded testimisele Haldur testimine andmist olema testitud. RIK dokumendis "Arendamise tavad ja töökorraldus". Vastav logi peab asuma teistest logidest eraldi failis ja andmebaasis Turvalisuse seisukohalt kriitilised turvalogide tabelis. Väliste Logimine, sündmused, nagu sessiooni rakenduse puhul tuleb logida NA-94 debuggimine, Haldur algamine ja lõppemise, rolli võimalusel kasutaja IP. Sessiooni testimine muutumine jne tuleb logida. võtmete väärtuses, privaatvõtmeid ja kasutaja salasõnad võivad logisse jääda vaid räsitud kujul.  Peab olema võimalus antud logimist välise süsteemi kaupa sisse-välja lülitada. Logi peab olema struktureeritud selliselt, et päring ja vastus on eraldi failides. Logimine Rakendus peab suutma logida kõiki Haldur koos Logimine, peab olema võimalik nii andmebaasi väliste süsteemidega vahetatavaid infrastruktuu NA-95 debuggimine, kui ka failisüsteemi (iga sõnum eraldi (ka X-tee teenuste kaudu liikuvaid) ride testimine faili, failid vähemalt päeva kaupa pöördumisi andmevahetuslogisse. osakonnaga eraldi kaustas) või mõlemasse korraga. Logifaili asukoht peab olema administraatori poolt ilma rakendust uuesti kompileerimata seadistatav. Logi salvestatakse kasutaja tegevuse logisse. Logi peab sisaldama (toodud järjekorras) millal tehti, kasutaja ID ja isikukood (firma registrikood), kui võimalik kust tehti (seadme nimi, IP, sertifikaat), mis tegevused andmetega tehti ja kas tegevus õnnestus. Kui võimalik siis päringu SQL lause. Logida peab olema võimalik ka konkreetseid Kui rakenduse ISKE andmed, mida kasutaja serveri Logimine, konfidentsiaalsuse klass on 2 või 3 arvates nägi. Viimane peab aga NA-96 debuggimine, peab tagama konfidentsiaalsuse Haldur olema välja lülitatav või asendatav testimine klassiga 2 ja 3 andmete vaatamise põhiobjektide ID-dega päringu liikide logimise. kaupa. Logida tuleb ka kasutajate tegevuste ebaõnnestumised (näiteks õiguste puudumise tõttu). Vastav logi peab asuma tegevuslogi andmebaasi tabelis. Logimise konfiguratsioon peab olema muudetav vaid uue rakenduse paketiga (deploy). Näiteks IOC konteinerist konfigureeritav (late binding). Logi salvestatakse kasutaja tegevuse logisse. Logi peab sisaldama (toodud järjekorras) millal tehti, kasutaja ID ja isikukood (firma registrikood), kui võimalik kust tehti (seadme nimi, IP, sertifikaat), mis tegevused andmetega tehti ja kas Kui rakenduse ISKE tervikluse tegevus õnnestus. Kui võimalik siis Logimine, klass on 2 või 3 peab tagama päringu SQL lause. Logida tuleb ka NA-97 debuggimine, tervikluse klassiga 2 ja 3 andmete Haldur kasutajate tegevuste testimine loomise, muutmise ja kustutamise ebaõnnestumised (näiteks õiguste logimise. puudumise tõttu). Vastav logi peab asuma tegevuslogi andmebaasi tabelis. Logimise konfiguratsioon peab olema muudetav vaid uue rakenduse paketiga (deploy). Näiteks IOC konteinerist konfigureeritav (late binding).  Süsteemi logid peavad asuma teistest logidest eraldi failis ja andmebaasi süsteemi logide tabelis. Logi peab sisaldama minimaalselt (toodud järjekorras) vea tekkimise Haldur koos aega, veakoodi, veakirjeldust (stack infrastruktuu Logimine, Rakendus peab logima kõiki trace, traceback vms), võimalusel ride NA-98 debuggimine, rakenduses tekkivaid tehnilisi vigu kasutaja andmeid (nimi, ID, IP ja osakonna ja testimine süsteemi logisse. URL), HTTP-, GET- ja POST- arendusosa parameetrid ja nende väärtusi. Kas konnaga logitakse baasi või faili või mõlemasse peab olema rakendust uuesti kompileerimata administraatori poolt muudetav. Peab olema võimalus logimist välise Failisüsteemi logimise korral süsteemi kaupa sisse-välja lülitada. peavad logid olema ka Ei tohi esinda olukorda, kus ühte katalogiseeritud (näiteks liigi järgi) kausta tekib rohkem kui 10000 faili. Logimine, Infrastruktuu ja tunnustatud faililaiendiga Peab tagama, et iga rakendusserver NA-99 debuggimine, ride (näiteks .log, .txt, .xml). Logi peab saaks vajadusel kirjutada logid oma testimine osakond olema roteeruv, et ei tekiks liiga logifaili. Logifaili asukoht peab suuri faile või faile kus on vaid olema administraatori poolt ilma üksikuid logikirjeid. rakendust uuesti kompileerimata seadistatav.  Logiväljad, mida lõppkasutaja saab manipuleerida (IP, useragent, URL) peavad salvestuma logisse kodeeritud kujul. Tuleb võimalusel vältida olukorda, kus ühe päringu tõttu tekib kirjeid mitmesse logisse. Igas logikirjes peab olema päringu unikaalne identifikaator, mis võimaldab logikirjet siduda teiste logikirjetega, mis tekkisid sama päringu tagajärjel. Seda nii ühe faili piires, kui ka juhul kui päringu tulemusel kirjutati mitmesse logi asukohta.. Kogu rakenduse logi peab olema Logimine, ühesuguse formaadiga, kergesti Sama infot sisaldavad väljad peavad NA-100 debuggimine, masinloetav ja täielik (kes, mis, (ka erinevates) logiasukohtades Haldur testimine mida, jms). Logis ei tohi kasutada olema sama nimega ja andmed klassifikaatoreid. samas formaadis. Failisüsteemis asuv logi peab olema XML, JSON või CSV formaadis. Kui parameetri väärtus on tühi, tuleb see logis märkida asendusväärtusega (nt “null”). Kui vähegi võimalik peab logi kuupäeva ja ajaformaat olema kujul "AAAA-KK- PP ja hh:mm:ss,nnnn“ lokaalne Eesti ajavöönd. "hh" järgib 24-tunnist kellaajaformaati. Kuupäev ja kellaaeg samas andmeväljas esitatakse kujul, kus kuupäevavormingu ja kellaajavorming vahele lisatakse täht T. Tabeli suurenedes peab olema võimalik hoida vanu kirjeid, näiteks Haldur koos Logimine, Logi tabelid peavad olema kuude või aastate kaupa, infrastruktuu NA-101 debuggimine, arhiveeritavad operatiivbaasist iseseisvates tabelites või teises ride testimine välja. baasis. Mehhanism peab töötama ka osakonnaga krüptoaheldatud logi korral. Kui rakendus kasutab või pakub Näiteks kui palju on kasutatud kuus, Logimine, väliseid teenuseid (näiteks SK aastas jne digitembeldamist, ID- NA-102 debuggimine, teenuseid) peab ta suutma Haldur autentimist, autentimisportaali, testimine arvestust pidada vastavate pangalingi kasutamist jne. teenuste kasutamise mahu üle. Jõudlustestide täpne kirjeldus tuleb kokku leppida detailanalüüsi käigus. Arendaja peab koos rakendusega tarnima skripti ja vajalikud Haldur koos Logimine, Rakendusega peab olema kaasas tarkvaralised vahendid kokkulepitud infrastruktuu NA-103 debuggimine, skript jõudlustestide tegemiseks. jõudlustestide läbiviimiseks. ride testimine Jõudlustestide läbiviimine ei tohi osakonnaga nõuda tellijalt omapoolset tarkvara arendamist, skriptide kirjutamist või litsentside ostmist.  Rakendusel peab olema Logimine, masinloetav XML-staatusleht, mille Staatuslehe nõuded sisalduvad NA-104 debuggimine, Haldur struktuur vastab tellija poolt ette käesoleva dokumendi lisas 1. testimine antud XML struktuurile. Nõuet ei arvestata arendustarkvara Lähtekoodi kommentaarid peavad poolt automaatselt genereeritavate Nõuded kõigis lahenduse kihtides koodilõikude puhul. Samuti ei Arendusosa NA-105 lähetkoodile ja (rakenduse enda kood, rakendata nõuet kolmandate kond paigaldamisele andmebaas, jne) olema kirjutatud osapoolte poolt toodetud eesti keeles. lähtekoodile – nt: erinevad lahtise koodiga kooditükid jne. Lähtekoodi kommentaarid peavad olema: 1. Põhjendatud. Kommenteerida ainult kommenteerimise pärast pole vaja. Kood peab olema kirjutatud selliselt, et see on loetav ka ilma kommentaarideta. Rakenduse kood peab olema Kommentaarid on mõeldud Nõuded piisavalt hästi kommenteeritud, et keeruliste ja/või kohendamist Arendusosa NA-106 lähetkoodile ja erialast haridust omav ja/või edasist tööd (viimaste kond paigaldamisele tarkvaraarendaja on võimeline juurde on tuleks märkida TODO) süsteemile jätkuarendusi teostama. vajavate kohtade jaoks. 2. Aktuaalsed - kommentaar ja kood peavad olema üksteisega vastavuses. 3. Selged ja üheselt mõistetavad. 4. Korrektselt kirjutatud - grammatika ja lauseehitus peavad olema korrektsed. Muutujate, tüüpide ja funktsioonide Nõuded nimed peavad olema sisulised ja Arendusosa NA-107 lähetkoodile ja andma selget informatsiooni nende kond paigaldamisele otstarbest. Koodis kasutatavaid konstante ei Nõuded tohi väärtusena hardcodeda – need Arendusosa NA-108 lähetkoodile ja tuleb defineerida muutujatena ja kond paigaldamisele kasutada läbi nende. Koodis defineeritud andmetüübid Nõuded peavad olema nimetava käände Näiteks "Isik", "Menetlus" jne. Arendusosa NA-109 lähetkoodile ja ainsuses. Kõik andmemassiivid Andmebaasides ei tohi kasutada kond paigaldamisele tuleb nimetada nimetava mitmuses täpitähti. (näiteks collectionid, arrayd, jms). Andmetabelites sisalduvad Nõuded Näiteks kui on tegu tabelitega ’Isikud’ võõrvõtmed peavad nime järgi NA-110 lähetkoodile ja ja ’Autod’, siis seos ’isiku autod’ Haldur seostuma tabeli ja väljaga millele paigaldamisele oleks: Isikud.ID=Autod.Isik_ID need viitavad. Nõuded Näiteks Oracle korral Andmebaasi väljade pikkused tuleb NA-111 lähetkoodile ja Nvarchar(2000) tähendab 2000 baiti Haldur kirjeldada tähemärkides. paigaldamisele mitte tähemärki. Kui kokku pole lepitud teisiti, siis Nõuded Valideerimiseks kasutatakse JAVA rakenduse kood peab olema Arendusosa NA-112 lähetkoodile ja 'checkstyle' vaikimisi kirjutatud vastavalt "SUN Java kond paigaldamisele konfiguratsiooni. Code convention" dokumendile.  Kui kokku pole lepitud teisiti, siis Nõuded Python rakenduse kood peab http://www.python.org/dev/peps/pep Arendusosa NA-113 lähetkoodile ja olema kirjutatud vastavalt "Style -0008/ kond paigaldamisele Guide for Python Code " dokumendile. Kui kokku pole lepitud teisiti, siis .NET rakenduse kood peab olema http://msdn.microsoft.com/en- Nõuded kirjutatud vastavalt "NET us/library/ms229042.aspx. Arendusosa NA-114 lähetkoodile ja Framework Developer's Guide - Valideerimiseks kasutatakse kond paigaldamisele Design Guidelines for Developing 'StyleCop' vaikimisi konfiguratsiooni. Class Libraries". Näiteks PMD (http://pmd.sourceforge.net), Nõuded JAVA koodi valideerimiseks DocCheck Arendusosa NA-115 lähetkoodile kasutatakse validaatorit. (http://java.sun.com/j2se/javadoc/do kond ccheck/) või muud võrreldavat kokkulepitud validaatorit. Näiteks FxCop Nõuded .NET koodi valideerimiseks (http://msdn.microsoft.com/en- Arendusosa NA-116 lähetkoodile kasutatakse validaatorit. us/library/bb429476.aspx) või muud kond võrreldavat kokkulepitud validaatorit. Näiteks Pychecker Nõuded Pythoni koodi valideerimiseks (http://pychecker.sourceforge.net/) Arendusosa NA-117 lähetkoodile kasutatakse validaatorit. või muud võrreldavat kokkulepitud kond validaatorit. Kasutuses mitteolev kood tuleb Nõuded Arendusosa NA-118 rakenduse lähtekoodist lähetkoodile kond kõrvaldada. Andmebaasi tabelid ja väljad ning muu kood (stored procid, Arendusosa funktsioonid, triggerid, viewd, user kond koos Nõuded NA-119 defined data types ja sequencid) infrastruktuu lähetkoodile peab olema kommenteeritud ride rakenduse koodiga samadel osakonnaga alustel. Mitte Dossier vaid Toimik, mitte Person vaid Isik. Lähtekoodis defineeritud muutujate, klasside/tabelite, NB! Nõuet ei arvestata Nõuded meetodite jm. nimed peavad arendustarkvara poolt automaatselt Arendusosa NA-120 lähetkoodile lahenduse kõigis kihtides genereeritavate koodilõikude puhul, kond (rakenduse enda kood, andmebaas mida ei ole vaja tõlkida. Samuti ei jne) olema eesti keelsed. rakendata nõuet kolmandate osapoolte poolt toodetud lähtekoodile. Aadressiandmete sisestamisel, Liidestatakse maa-ameti X-tee Andmekvaliteet kuvamisel ja hoidmisel tuleb teenusega või RIK sisemise vastava NA-121 Haldur ja standardid lähtuda määrusest Maa-ameti andmeid vahendava "Aadressiandmete süsteem". süsteemiga.  Muu hulgas peab kontrollima, kas sisestatav väärtus vastab välja tüübile ja/või etteantud valikväärtustele. Numbriväljale tohib sisestada vaid numbreid, kuupäeva väljale kuupäeva, elektronposti aadressi vilajale elektronposti aadressi, valikväärtuste korral vaid lubatud valikväärtused jne. Andmete sisestamisel (ka läbi Kontrollima peab sisendi suurust. masin-masin liideste või Olukorras, kus veebirakendus peab Andmekvaliteet veebiteenuste) peab rakendus alati NA-122 töötlema potentsiaalselt ohtlikke Haldur ja standardid andmed valideerime. Sobimatuid andmeid (nt tähemärke, millel on andmeid ei tohi olla võimalik rakendatava sisestada. interpretaatorprogrammi jaoks tähendus) ja filtreerimisfunktsiooni ei saa seega kasutada, tuleb need andmed ära maskeerida, st muuta nende kuvamisvormingut. Sisendi kontrolli ebaõnnestumise korral tuleb peatada sisendi kasutamine ja kasutajat sellest teavitada. Iga transaktsiooni juures tuleb Andmekvaliteet veenduda, et kasutajal on õigus NA-123 ja standardid neid vaadata või muuta (isiku õiguste, mitte rolli õiguste kontroll) Tegevusalade andmete sisestamisel, kuvamisel ja hoidmisel tuleb lähtuda Vabariigi Andmekvaliteet Valitsuse 10. Jaanuari 2008. a Liidestatakse RIK EMTAK Arendusosa NA-124 ja standardid määrusest nr 11 "Klassifikaatorite infosüsteemi teenusega. kond süsteem" ja kasutada EMTAK infosüsteemis kehtivat klassifikaatorit. Kasutaja poolt sisestatud andmed Andmekvaliteet Kasutada tuleks võimalusel Arendusosa NA-125 tuleb enne välja kuvamist ja standardid Blacklistingu asemel whitelistingut. kond filtreerida. Kui rakendusel tekib päringu Andmekvaliteet töötlemisel tehniline viga, siis peab Näiteks: "Tekkis tehniline viga. NA-126 ja standardid vastama süsteemi-infot Päringu ID: XXXXX". mittesisaldava veateatega. Erandiks võivad olla tellijaga Dokumentatsioo Kogu rakenduse dokumentatsioon kokkuleppel kolmanda osapoole NA-127 n peab olema kirjutatud eesti keeles. komponentide (mis pole kirjutatud tellija jaoks) dokumentatsioon. Rakenduse dokumentatsioon peab Dokumentatsioo NA-128 vastama RIK n dokumentatsiooniplaani nõuetele. Haldur koos Iga uue versiooniga peab alati välja Release notes peab kajastama kõiki Dokumentatsioo infrastruktuu NA-129 tooma versiooni muudatuse muudatusi eelmise ja uue versiooni n ride kirjeldused (release notes). vahel. osakonnaga  Kõik rakenduse testimiseks, koolituseks või implementeerimiseks üle antavad Arendajale antakse selleks õigused tarkvarapaketid peavad olema Arendusosa NA-130 Versioonihaldus RIK-i koodihoidlas, kus ta peab versioneeritud vastavalt kond hoidma oma PMA versioone. dokumendile RIK Arendamise tavad ja töökorraldus. Kasutama peab RIK-i koodihoidlat. Paralleelse arendamise puhul Arendaja peab veenduma, et teeb Arendusosa NA-131 Versioonihaldus võetakse igal hommikul RIK muudatusi aktuaalsesse koodi. kond koodihoidlast viimane seis koodist. Kõik rakenduste tellijale Ka tagant järgi peab olema 100% lepingujärgsete üleantavate kindel, et üle anti õige arendaja Tellijapoolne NA-132 Versioonihaldus versioonide lähtekoodid peavad signeeritud, mitte kolmanda projektijuht olema varustatud arendaja osapoole poolt kompromiteeritud esindaja digiallkirjaga. versioon. Nii arendamisel kui ka hoolduslepingute korral Kui ei ole tellijaga kokku lepitud NA-133 Versioonihaldus Haldur kasutatakse RIK vigadehalduse teisiti. keskkonda. Puhas link on inimloetav, tähendust Kui veebirakenduses või veebilehel omav, paraja pikkusega, tekstiline on linke, mida kasutajad näevad või (erandina lubatud numbrid ja märgid NA-134 Versioonihaldus Haldur millele nad saavad viidata, peavad „/“, „.“, „-“ ja „_“) ja ajas püsiv. need olema puhtad lingid. Veebisaidi igal kuval peab olema unikaalne link. Kooste kirjelduste alusel valmiv Arendusosa Näiteks: kompileeritavate keelte paigalduspakett tohib sisaldada kond koos Paigalduspaketi puhul ei tohi sisaldada lähtekoodi, kui NA-135 ainult minimaalse rakenduse infrastruktuu kooste see pole vajalik rakenduse käitamiseks vajamineva ride käitamiseks. failikomplekti. osakonnaga Arendusosa Kooste kirjelduste alusel valmivat Eelkõige ei tohi tekitada olukorda, kond koos Paigalduspaketi paigalduspaketti peab olema kus rakenduse jooksutamiseks uues NA-136 infrastruktuu kooste võimalik liigutada erinevate serveris, tuleb see tingimata just ride serverite vahel. sealsamas kokku kompileerida. osakonnaga Lähtekoodi kompileerimine peab Selle nõude täitmise võimaldamiseks Paigalduspaketi Arendusosa NA-137 olema teostatav ka Interneti on RIK-is kasutusel sisemised kooste kond ühenduse puudumise korral. tarkvarakomponentide repod. Infrastruktuu Paigalduspaketi Andmebaasi paigalduse skriptid ei Administraator peab saama NA-138 ride kooste tohi olla kompileeritud. veenduda skriptide sisus. osakond Lisad: Lisa 1 – Staatuslehe nõuded  Nõuded projektiplaanile versioon 1.0 Pakkumuse osana esitatakse projektiplaan, mis sisaldab ajakava kõikide funktsionaalsuste loomise ja selle pakkumuse alustamiseks vajalike tööde läbiviimiseks. Pakkumuses esitatavalt projektiplaanilt eeldatakse vastavust järgmistele tingimustele: PP 1.1 Projektiplaanis kirjeldatud tööde läbiviimise tulemusena peab olema saavutatud projekti eesmärk ja soovitud funktsionaalsus. PP 1.2 Iga projektiplaani töö kohta peab olema kirjeldatud töö nimetus, töö tegija(te) sh vastutaja roll/nimi, ajaline kestus inimtundides ja tähtaeg. PP 1.3 Projektiplaanis peab kajastuma töö tegemiseks vajalikud eeldused/lähteandmed ning töö mõõdetav(ad) tulem(id). Projektiplaan peab sisaldama mh. tähtaegu, mis on rakendatavad hankijale/välisele osapoolele projekti edukaks realiseerimiseks vajalike sisendite tagamise kohta. PP 1.4 Kõik projektiplaanis kirjeldatud tööd peavad olema omavahel loogiliselt seotud ja jaotatud iteratsioonidena. PP 1.5 Projektiplaan peab sisaldama varuaega (puhvrit) ja selles peab arvestama riiklike pühade, puhkepäevade ja projektimeeskonna puhkustega. PP 1.6 Projektiplaan peab olema ajakohastatud kogu projekti teostamise vältel. PP 1.7 Lisaks projektiplaanile tuleb kirjeldada, kuidas projektijuhtimise riske maandada kavatsetakse (pakkumuse eraldi dokument). Majasiseselt: RIKi projektijuht lisab projektiplaani arenduste kasutuselevõtuga seotud õigusloomelise tegevuse, kasutajate koolitamise, kasutusjuhendite jms koostamise kava võttes arvesse, et need tegevused oleks arenduste kasutuselevõtu hetkeks teostatud. Vajalikud tegevuste tähtajad annab tellija ja sisuosakond. Samuti lisab projektijuht projektiplaani ajakava arenduste registreerimiseks ja kooskõlastamiseks RIHA-s vastavalt RIHA põhimäärusele, arvestades ametlikule kooskõlastamisele kuluva maksimaalse aja kuluga (registreerida tuleb nii projekti kavatsus kui kasutuselevõtmine). Vajaliku d tegevuste tähtajad annab tellija ja sisuosakond.  Arenduse tavad ja töökorraldus Tellija jätab endale õiguse muuta raamlepingu alusel sõlmitavate hankelepingute tehnilises kirjelduses kirjeldatud nõudeid. Pakkuja peab lähtuma hankelepingute täitmisel järgnevatest nõuetest, v.a juhul kui tellija on hankelepingu tehnilises kirjelduses märkinud teisti. Arendustööde teostamisel kohustub pakkuja lähtuma mittefunktsionaalsetest nõuetest. 1. Nõuded arenduste üleandmisele Loodavad hanke tulemid antakse üle RIK-i koodirepositooriumi kaudu. Partneri meeskonnaliikmetele luuakse RIK-i poolt ligipääs koodirepositooriumile lähtekoodide, andmebaasimuudatuste ning muude tulemite või nende muudatuste üleandmiseks. 2. Commit Arendamisel lisada commitide (lähtekoodi repositooriumisse lisamine) juurde kindlasti töökäsu 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 ning kindlasti lisada info selle kohta, et kes antud commiti teeb (isiku nimi). Vigade parandamisel tuleb alati committimisel lisada ticketi number märkusena. Muudatusi tuleb commitida vähemalt kord päevas. Enne commiti peab kood/teostatud töö/tulem olema: 1) Iseendaga kooskõlas (pole vastuolusid, katkiseid mooduleid, iseendaga vastuolus funktsionaalsust); 2) Üldharu/muu haru tulemiga kooskõlas (üldharus olemasolev pole peale commiti katki); 3) Edaspidi mugavalt kasutatav ja mõistetav, ehk sellel on olemas oma enda sisseehitatud testid, mis peale järgnevaid võimalikke arendusi/commite/tegevusi näitaks, kas see konkreetne funktsionaalsuse osa on endiselt korras, või läks katki ja tuleb korrastada. Commititav kood/teostatud töö/tulem peab olema piisavalt testitud ja pakkuja poolt testidega kaetud, kasutades selleks: a) Unittest’e, b) Systemtest’e c) Manuaalseid teste 3. Tagimine Versiooni üleandmiseks tuleb sellest koostada tag. Tagi number peab ühtima versiooni numbriga, mida üle antakse, kuid tagi nimi peab alati algama projekti lühendiga. Tagi alla tuleb siduda kõikide arhitektuuriliste komponentide (rakendus, andmebaasiscriptid, x-tee adapter jne) ning muudetud või loodud dokumentatsiooni commitid. Versiooni numbrid peavad olema vähemalt kolmekohalised (X.Y.Z, milles X- põhiversioon, Y - üleantav versioon, Z paranduse number). Vajadusel võib kokku leppida teistsuguses numeratsioonis. http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-branchtag.html#tsvn-dug-branch-1 Iga tagiga (uue versiooniga) peab kaasnema versiooni kirjeldus (mis taskid, mis ticketid, mis baasiscriptid, mis juhendeid täiendati jne), mis tuleb paigutada dokumentatsiooni alla.  4. Dokumentatsioon Dokumentatsiooni tuleb hoida trunk/doc/ kaustas. Alampuud lepitakse eraldi kokku. 5. Baasiscriptid Andmebaas ning selle muudatused tuleb alati üle anda loovate, muutvate, täiendavate jne skriptidena ning neid tuleb alati hoida trunk/baas/ kaustas. Andmebaasiscriptide failinimed peavad olema kujul: YYYYMMDDHHMM_prefiks+Järjekorranr.sql ehk 201105131430_KR0003.sql kus prefiks on süsteemi lühend. 6. Pakkuja poolne testimine Partner peab lisaks kasutuslugude funktsionaalsele testimisele teostatava arenduse/töö/tulemi commitimisel ja üleandmisel ise tõestatavalt veendunud olema, et nende arendus/töö/tulem teeb seda, mis on nõutud ning samaaegselt ei riku/lõhu juba olemasolevat muud arendust/tööd/tulemit. Iga kirjutatud koodiüksuse kohta peaks olemas olema ka vastav test, mis kindlustab, et loodu toimib ja seda ka eriolukordades. Samuti on testid abiks juba olemasolevate komponentide muutmisel, indikeerides koheselt võimaliku probleemolukorra. Arendatav funktsionaalsus peab olema kaetud: 1. Unittestidega 2. Süsteemitestidega 3. Manuaalsete testidega Igal commitimisel ning üleandmisega peab edukalt: 1. käivitama kõik Unittestid ning selle dokumenteerima. 2. käivitama kõik süsteemitestid ning selle dokumenteerima 3. käivitama kõik manuaalsed testid ning selle dokumenteerima 4. dokumenteerima, mis test data't kasutati, mis keskkondi kasutati, jne. 6.1 Unit-testid e. Moodultestid Moodultestid testivad ÜHTE klassi isoleeritult teistest klassidest ja ressurssidest (andmebaas). Ideaalis peaks igal iseseival klassil olema oma moodultest, mis kataks selle funktsionaalust täielikult. Kuna klassid kasutavad teineteist, moodustuvad niiöelda kobarad, siis moodultesti ideoloogiaga see hästi kokku ei sobi. Selleks, et saaks testida tõesti vaid konkreetse ühe klassi funktsionaalsust, on kasutusel mock- objektid(väline komponent Rhino Mocks). 6.2 Süsteemitestid Süsteemitestid testivad süsteemi kasutaja vaatenurgast, eesmärgiks on kontrollida süsteemi vastavust kasutaja nõudmistele. Süsteemitestid jagunevad omakorda kaheks: 1. Funktsionaalsuse testid - üldjuhul koostatakse konkreetse teenuse klassi süsteemitestid sellises mahus, et kaetud oleksid selle kõik erinevad meetodid ning lisaks äriloogiliselt olulisemad stsenaariumid. 2. Mittefunktsionaalsete aspektide testid - näiteks jõudluse testimiseks.  6.3 Üldised nõuded testide kirjutamisel Nagu eelnevalt sai kirjeldatud, on testid liigendatud oma olemuse järgi. Testi sisu ja iseloom varieerub olenevalt selle kategooriale (nt. [Test, Category("Bug")] – testis kirjeldatakse kindel veaolukord ning kontrollitakse selle põhjal vea olemasolu. testi andmed on antud veaolukorra järgi koostatud ja spetsiifilised). Küll aga on kujunenud kindlad head tavad, mida tuleb kõigi testide kirjutamisel järgida – koodieetikat, testide liigendamist, testide automatiseeritust (st. teste peab saama käivitada skriptidega projektiväliselt nt. kategooria alusel iga-öiselt) ning testide autonoomsust (testid peavad võimalikult hästi taluma ET muudatusi). 6.4 Koodieetika ja struktuur testide kirjutamisel Testkood peaks olema liigendatud ja selgelt loetav: 1. Defineerida testis projekti erinevate osade kasutus (nt. using System;); 2. Iga testklass tuleb deklareerida [TestFixture]-raamistikus ning olenevalt testi iseloomust nimetada kujul Bug1234Test (kindlat viga #1234 kirjeldav Bug-test), Ticket1234Test (uuendust #1234 kontrolliv test) või TestiKirjutajaEesnimi_TeenuseNimiTest (teenuse spetsiifiline süvatest); 3. Testis olevad privaatsed klassimuutujad on tava kohaselt kujul _muutujaNimi, näiteks private Menetlus _menetlus; 4. Kaitstud ja avalikud muutujad on kujul muutujaNimi või MuutujaNimi; 5. Vajalik uute klassiobjektide initsialiseerimine (nt. liidesed) toimub meetodis SetUp(). Näiteks: [SetUp] public void SetUp() { _liides = new Liides(); } 6. Iga uus testcase tuleb kirjutada raamistiku sisse kujul [Test, Category("Kategooria")] ning testi enda nimetus tuleneb testi tüübist: a) Bug-testide ja uuendusi kontrollivate testide korral nimetus, mis kirjeldab võimalikult hästi ja konkreetselt kontrollitavat objekti/olukorda . b) Teenusepõhiste süvatestide puhul esiteks test, mis kontrollib, et teenust saaks nii minimaalsete kui ka maksimaalsete andmetega kinnitada, nimetusega A_SetUp() 7. Testandmed võiksid olla võimalikult reaalse elu lähedased ja loogilised, st. ei tohiks tekitada uut objekti klassist Helikopter kujul _a, vaid kujul _helikopter. 8. Iga äridokumendis olev nõue või tingimus tuleb testida eraldi testcase’i all, olenemata sellest kas kontrolliks on üks või rohkem ridu koodi. Kui teha äriloogiline kontroll vaid ühe testi all, siis ei kajasta see teenuse tervist – st. kui esimene kontroll annab veateate, siis ülejäänuteni test ei jõua. Selle vältimiseks on testid ärinõuete kaupa eraldi kirjutatud. 6.5 Autonoomsus Testid peavad taluma pisemaid koodi muudatusi (neid, millega ei kaasne DTO või andmemudeli muutused). 6.6 Automatiseeritus Kõiki teste peab saama käivitada näiteks projektiväliselt skripti abil. Selleks peavad testid olema õigesti kategoriseeritud.  Nõuded testimisele v1.2 versioon 1.2 Sisukord Sissejuhatus 1. Üldine AO-N-TE-Y 2. Dokumentatsioon AO-N-TE-D 3. Testplaan ja -lood AO-N-TE-T 4. Logimine, raporteerimine AO-N-TE-R 5. Nõuded testidele AO-N-TE-N 6. Lähtekood ja spetsiaalsed tööriistad AO-N-TE-I 7. Alusandmed AO-N-TE-A 8. Koormus- ja stressitestid AO-N-TE-S Sissejuhatus Enne projekti tegelikku algust lepitakse kokku kõik erisused - millised punktid vastavas projektis ei rakendu (pole võimalik/vajalik) ja kas rakenduvad mingid täiendavad punktid või all-loetletud punktidele täpsustused. 1. Üldine AO-N-TE-Y Nõue Sisu AO-N- Kõikide üle antavate tarkvara versioonidega peavad kaasas olema vastavad testid, nendega seotud dokumentatsioon ning kirjelduse või raporti leitud ja parandatud vigadest. TE-Y-1 AO-N- Tarkvara vastuvõtmiseks vajalikud hankevõitja poolsed testimised ja skoop (osa testplaanist) lepitakse kokku projekti alguses ning seda muudetakse poolte kokkuleppel. TE-Y-2 AO-N- Vastavalt kokkuleppele tuleb koostada ning üle anda punktis AO-N-TE-Y-2 nimetatud testplaan ja testlood ning eraldi testprojekti ja -programmi puhul ka vajaminev dokumentatsioon ja TE-Y-3 kirjeldus. AO-N- Testitava tarkvara lõplik versioon peab läbima vastavad nõuded koormusele/jõudlusele (ISKE,SLA jm.). Selle tõestamiseks tuleb tarnida ka vastavad testid. TE-Y-4 AO-N- Üle antud testides või vastuvõtutestimisel esinenud probleemid tuleb parandada sarnaselt põhiarendusega. TE-Y-5 AO-N- Testid peavad olema loogiliselt grupeeritud ning numereeritud, nii et skriptide või tööriistade abil saab kindlat osa käivitada. Näiteks teenuse- või tüübi kaupa (süsteemitestid, koormustestid TE-Y-6 vm.). AO-N- Üle antud testide käivitamiseks ei pea RIK soetama lisatarkvara. Näiteks automaattestid, koormustestid jm. võiks olla kirjutatud C#+NUnit'is, Selenium'is, JMeter'is, Robot Framework'is või TE-Y-7 Gattling'us. Kokkuleppel Java+JUnit, Cypress või muu. 2. Dokumentatsioon AO-N-TE-D Nõue Sisu AO-N-TE-D- Dokumentatsiooni eesmärgiks on edasi anda kogu vajalik informatsioon testide kohta (testplaanid, testlood, testide käivitamiseks, jooksutamiseks ja valideerimiseks vajalik informatsioon 1 jne). AO-N-TE-D- Dokumentatsioon peab olema versioneeritud ning iga punkti (Näiteks Testlugu) juures peab olema tekkimise aeg, viimase muudatuse aeg, autor, muutja. 2 3. Testplaan ja -lood AO-N-TE-T Nõue Sisu AO-N- Testplaanile ja –lugudele rakendub peatükk AO-N-TE-D-2 . TE-T-1 AO-N- Testplaan kirjeldab ning selgitab kogu tarkvaraga seotud testimist, kui ei ole kokku lepitud teisiti. TE-T-2 AO-N- Testlood tulenevad kasutuslugudest ja/või süsteemianalüüsi nõuetest, nende kattumisel piisab testimise kirjeldusest, et vältida dokumentatsiooni dubleerimist. TE-T-3 AO-N- Testloos peab minimaalselt olema: testi kirjeldus, viide nõudele või kasutusloole, etapid, oodatud tulemus, tegelik tulemus. TE-T-4 AO-N- Testprojekti ja –programmi puhul võib kood koos kommentaaridega täita testloo rolli (Näiteks Testi nimetus viitab kindlale testloole või süsteeminõudele, C# kirjutatud süsteemitesti TE-T-5 nimetamisloogika ja kommentaarid teevad kergelt selgeks tegevuste ahela). 4. Logimine, raporteerimine AO-N-TE-R Nõue Sisu AO-N- Raportitele rakendub peatükk AO-N-TE-D-2 . Eraldi raporteid pole tingimata vaja kui kasutatakse ühist JIRA + Confluence keskkonda. TE-R-1 AO-N- Testraportis kajastatud vigade juures peab olema märgitud tarne versioon, milles viga leiti ning milles see on kõrvaldatud. TE-R-2 AO-N- Automaatsete testide puhul peab automaatselt genereeruma testraport või statistika tegemiseks vajalik logi (Näiteks NUnit genereerib ise raporti, JMeteris Summary Report+ Aggregate Report TE-R-3 või eraldi .csv fail jne.).  AO-N- Koormus- ja stressitestide puhul peab raport kajastama, millise koormuse juures hakkasid testid negatiivseid tulemusi saama ning millised vead esinesid. TE-R-4 AO-N- Koormus- ja stressitestide juures on vaja minimaalselt välja tuua: saadetud päringute arv, min. päringu käitlemise aeg(ms), max. päringu käitlemise aeg(ms), päringute käitlemise standardhälve TE-R-5 (ms), keskmine päringu käitlemise aeg(ms), vigade %, läbilaskevõime(tegevust/sek.), 90/95/99 protsentiilid. 5. Nõuded testidele AO-N-TE-N Nõue Sisu AO-N-TE- Testprojekti ja –programmi testide juures rakendub peatükk AO-N-TE-D-2 , lisaks peab testi juurde märkima testi tegija ning tarkvara versiooni, millele test koostati. N-1 AO-N-TE- Süsteemitestidega peavad olema kaetud kõik süsteemi osad, kui ei ole kokku lepitud teisiti (Näiteks kõik arendatud teenused, kasutajaliidesega rakenduse testlood jne.). N-2 AO-N-TE- Iga test peab olema süsteemi- või ärianalüütiliselt terviklik põhjendatav kooslus (Näiteks ühes testis ei testita kahte erinevat teenust või süsteemi viga). N-3 AO-N-TE- Iga teenuse kohta peab olema Smoke test, mis kontrollib lihtsaima sisendiga teenuse töökorda. N-4 AO-N-TE- Kuna RIKis arendatakse pideva integratsiooni mudelit järgides, siis peab olema võimalik teste valikuliselt grupeerida ning neid automaatselt käivitada (Näiteks Grupp „Nightly" öiste N-5 integratsioonitestide jaoks). AO-N-TE- Testsessioonid ning omavahel mitte seotud testid ei tohi üksteist mõjutada. N-6 6. Lähtekood ja spetsiaalsed tööriistad AO-N-TE-I Nõue Sisu AO-N-TE-I- Spetsiaalselt arendatud testprojektile ja -programmile rakenduvad „Nõuded arendustele –Nõuded rakenduse koodile" . 1 AO-N-TE-I- Spetsiaalselt arendatud testprojektid peavad kasutama üldtuntud raamistikke Näiteks NUnit, JUnit. 2 AO-N-TE-I- Kui testprojekt kasutab Objektide kihte, omab teenuste kihti või koodi osa, mida saab WSDL, andmebaasi või muu pealt genereerida, siis selleks peab kasutama tööriistu (Näiteks DTOd ei 3 kirjutata käsitsi).  AO-N-TE-I- Punktis AO-N-TE-I-3 mainitud tööriistad ja nende parandused tuleb tarnida koos testidega. 4 7. Alusandmed AO-N-TE-A Nõue Sisu AO-N-TE- Alusandmete genereerimiseks vajalik peab olema vastavate testidega kaasas. A-1 AO-N-TE- Kui testimiseks on vajalikud andmed teistest süsteemidest, siis nende saamine lepitakse eelnevalt kokku. A-2 AO-N-TE- Alusandmed peavad töötama erinevates keskkondades, kaasa arvatud andmed, mida päritakse teistest süsteemidest. A-3 AO-N-TE- Peab vältima teiste süsteemide andmete rikkumist, selle vältimiseks vt. punkt AO-N-TE-A-2 . A-4 AO-N-TE- Eelistama peaks alusandmete genereerimist või eraldi üldkasutatavat kihti, millest andmed võetakse, mitte koodi sisse kirjutatud andmeid (Näiteks Isikukoodid võetakse üldisest jadast või A-5 eraldi testandmete alamprojektist). AO-N-TE- Võimalusel kasutada sünteetilisi, mitte reaalseid andmeid (Näiteks reaalsuses mitte eksisteerivad Isikud), eriti kui arendatavas tarkvaras on automaatseid teavitusi või muud samalaadset A-6 (Näiteks automaatne e-mailide saatmine). 8. Koormus- ja stressitestid AO-N-TE-S Nõue Sisu AO-N-TE-S-1 Testide üleandmisel peab kaasa andma nendega kaasneva dokumentatsiooni, kasutatud konfiguratsiooni ning vajadusel riistvara ja arhitektuuri kirjelduse. AO-N-TE-S-2 Kasutatud konfiguratsioon ning riistvara ja arhitektuur võiks tugevalt sarnaneda vastuvõtja test- või toodangukeskkonna riistvaraga. AO-N-TE-S-3 Testid peavad olema üldisest konfiguratsioonist skaleeritavad: kasutajate arv, kasutajate etapilisus (ramp-up), testide ajastamine jm. on üldised muutujad või üldises konfiguratsioonis. AO-N-TE-S-4 Igal testil peab olema konkreetne kontekst (Näiteks SLA nõue, teenuse või baasiprotseduuri jõudluse hindamine vm.).  Front-End nõuded versioon 1, jaanuar 2019 https://dok.rik.ee/x/viWcAg Sisukord Sissejuhatus Mõisted HTML Nõuded CSS Nõuded Responsiivsus Javascript Nõuded Veebi sisu juurdepääsetavussuunised (WCAG) ja üleüldised kasutajakogemust puudutavad nõuded Nõuded Meediumite kasutamine veebilehel (veebilehe laadimiskiirus) Koodibaasi kvaliteedi tagamine Muud nõuded Nõuded Sissejuhatus Tehnoloogia areng on tekitanud olukorra, kus pakutavate tehnoloogiate virr-varrist on raske leida asjakohaseid suunised, mille järgi juhinduda. Eriti peegeldub see Front-End tehnoloogiate rakendamisel, kus loodavate lahenduste kvaliteet on seinast-seina. Ühest küljest on sellise olukorra tekkimist võimaldanud asjaolu, et veebilehe arendamisel kasutatavad tehnoloogiad on vigade tolerantsed. See tähendab seda, et HTML-is või CSS-is esinevate vigade kohta ei anna veebilehitsejad vaikimisi arendajatele tagasisidet. Kui programmeerimiskeele interpreteerimisel tekib viga, siis veasituatsiooni põhjustatud kohas tegevus lõpetatakse ja selle katkestamise põhjus kirjutatakse kas ekraanile või mõnda faili. Siis HTML/CSS-i korral see nii ei ole. HTML/CSS-is esinevad vead saab tuvastada vaid kaudselt, kuna veebilehitseja tootjad on loonud enda poolt loodud veebilehitsejasse tööriistad, mis parendavad või ignoreerivad vigast koodi. Seega on võimalik kirjutada vigadega koodi, aga kasutaja neid vigu veebilehel ei näe. Käesolev dokument käsitleb endas juhiseid ja suuniseid, mida tuleb järgida veebilehtede programmeerimisel. Käsitlevateks tehnoloogiateks on HTML5, CSS3 ja Javascript ehk see osa, mis toimub veebilehitsejas (browseris). Oluline osa sellest dokumendist keskendub ka sellele, kuidas tagada veebilehtede arendamise järjepidevus ja kvaliteet, mis vastaks tänapäeva veebilahenduste arendamise nõuetele ja WCAG suunistele. Lisaks eelnimetatule tuuakse käesolevas dokumendis välja ka parimad praktikad, mis aitavad meeskonnal paremini luua ja hallata pikaajalisi projekte. Enne projekti tegelikku algust lepitakse kokku kõik erisused - millised nõuded konkreetses projektis ei rakendu (nt pole võimalik või vajalik). Mõisted Grid-system – reeglistik, mis pakub ühtset süsteemi kasutajaliidese komponentide laiuste ja kauguste kirjeldamiseks. Tänapäeval on grid-system see, mis kirjeldab ka veebilehe responsiivsuse. Ehk reegleid, mis kirjeldavad, kuidas veebileht erineva suurusega ekraanidel välja näeb. Javascript – skriptikeel, mille abil luuakse veebilehele erinevaid interaktsioone. Tuvastades kasutaja tekitatud sündmuseid võimaldab keel lisada, muuta või kustutada veebilehe sisu. Üks osa Javascriptist on ka peidetud andmevahetuse võimaldamine. HTML5 (Hyper Text Markup Language) – struktureeritud markeerimise keel. Viies põhiredaktsioon. Keel, mille abil kirjeldatakse veebilehe andmeid ja struktuuri. CSS (Cascading Style Sheets) – keel, mille abil kirjeldatakse veebilehe välimust. WCAG (Web Content Accessibility Guidelines) – dokument, mis pakub suuniseid, kuidas veebilehe sisu juurdepääsetavust parendada. HTML Veebilehe valmistamisel on HTML-i roll kirjeldada lehe struktuuri ja seda, mis andmed sellel lehel olemas on. Semantiline HTML tähendab seda, et HTML-li kirjutamisel on eelistatud esmajärjekorras semantilisi (tähendustega) elemente. Semantilised elemendid annavad olulist teavet nii otsingumootoritele kui ka lehe külastaja abitarkvaradele. Teave puudutab just seda, mis andmed on veebilehel ja kuidas need omavahel seotud on. Semantilise HTML-i teine oluline eelis seisneb selles, et tagab kindluse tuleviku suhtes (future proofing) või kasutuskõlblikuse / väljanägemise browseris ilma CSS'ita. Koodi loetakse arendajate poolt ja tõlgendatakse arvutite poolt. Nõuded Nr Nõude sisu Nõude seletused F Lehe kirjeldamisel on Semantiliste elementide kohta saab täpsemat infot leheküljelt: http://html5doctor.com Nimetatud lehekülg koondab informatsiooni W3C Working Groupi E kasutatud semantilisi dokumentide refereeringut. Leht annab esmase ülevaate võimalikest elementidest ja nende kasutamiskohtadest. Täpsema info saamiseks viidatakse H1 elemente. algmaterjalile. Halb näide Hea näide F Lehe sisupuu Pealkirjad ja mõned HTML5 elemendid (Sections and Outlines of an HTML5 Document) kirjeldavad veebilehe sisupuud. Puudulike pealkirjade või E peegeldab lehe ebakorrektse HTML5 elementide kasutamine moonutab lehe tegelikku sisupuud. H2 tegelikku hierarhiat. Testimiseks sobivad rakendused, mis oskavad välja joonistada HTML5 dokumendi sisupuu. Näiteks WAVE Toolbar või HTML5 Outliner. Loe lähemat WCAG suunistest käesoleva dokumendi vastavast peatükist. F Koodis puuduvad Kuna HTML on mõeldud sisu struktureerimiseks, siis ei tohiks kasutada HTML-is elemente, mille eesmärk on vaid mõne kujunduselemendi ekraanile E elemendid, mida on joonistamine. Näiteks ei ole korrektsuse huvides kohane lisada HTML-i elemente, mis on tühjad (ilma väärtuseta) ja on seal vaid selleks, et näiteks kuvada H3 kasutatud selleks, et ikooni. Graafika eraldamine HTML-ist pakub võimalust juhtida kujundust ühest kohast. Ühtlasi võimaldab selline meetod muudatusi teha nii, et ei peaks näidata ekraanil mõnda sekkuma rakenduse äriloogikasse. kujunduselementi. Näiteks ikoonid või muu Halb näide graafika. Hea näide Märkus. Siin pole mõeldud elemente, mille sisu täidetakse Javascripti abil. Näiteks Google Maps jmt. Küll aga peavad sellised elemendid sisaldama informatsiooni juhuks kui Javascript ei rakendu. Või juhtudeks, kui kasutaja veebilehitsejas on Javascripti kasutamine keelatud. Samuti ei kehti see kriteerium nn Backdrop jmt komponentidel, mida kasutatakse kujunduses komponentide nähtavuse parendamiseks. Selliste komponentide jaoks tuleks kasutada vastavaid ARIA parameetreid. F HTML-is kirjeldatud Veebileht koosneb komponentidest ja komponendile kuuluvatest elementidest. Komponendipõhine lähenemine veebilehe arendamisel tähendab seda, et E lehe komponendid on lehe loomisel on selgelt defineeritud lehe erinevad väiksemad osad (ehk komponendid/elemendid). Neid väiksemaid osasid kasutatakse erinevates H4 eristatavad. sisulehtedes. Ehk lehe komponendid on korduvkasutatavad ja on sõltumatud neid ümbritsevast HTML-ist. HTML-ist on võimalik selgelt eristada, milline osa koodist on sisu ja milline on see osa, mille abil hoitakse koos lehe paigutust (grid-system). Eemaldades või lisades komponente ei muuda see tegevus lehe elementide paigutust. Alljärgnevas näites on kasutatud kahte komponenti: layout ja card. Esimese abil kirjeldatakse veebilehe sisu paigutust horisontaalsel teljel (teda ennast pole lehe külastajale näha), see hoiab veebilehte koos. Teine on aga sisu komponent, mis on lehe külastajale näha ja mille laius sõltub sellest, palju on talle ruumi antud layout komponendi vahendusel. Mõlemad on eraldiseisvad osad, millel on täita oma roll. Seega pole asjakohane märkida layout-ile, milline card tema sees välja näeb. See, milline üks või teine komponent välja näeb, seda kirjeldatakse vaid selle komponendi juures. Sellest siis alljärgnev halb ja hea näide. Halb näide Hea näide F Lehel on teade, kui Javascript on tänapäeval de facto veebi osa. Lisades lehele interaktsioone ja kulissidetagust andmevahetust, pakub see lehe külastajale paremat E kasutajal puudub kasutajakogemust kui seda teeks vaid HTML ja CSS-i kasutamine. Kuna Javascripti osakaal lehe vajaliku funktsionaalsuse tekitamiseks on suur, siis on H5 Javascripti tugi. hädavajalik külastajale teada anda, kui tema veebilehitsejal Javascript ei ole toetatud. F Lehel on teade, kui Kui külastada lehte iganenud veebilehitsejaga, siis kuvatakse külastajale selle kohta teade. Teade sisaldab viiteid, kuidas uuendada või asendada oma E kasutaja külastab veebilehitsejat. H6 veebilehte iganenud veebilehitsejaga. Märkus. Iganenud veebilehitseja all peetakse silmas neid veebilehitsejaid, mille toetamine on tootja poolt lõpetatud. Kuna veebilehitsejate uuenduste tsükkel on kaasaegsetes veebilehitsejatel 6-12 nädala tagant, siis need veebilehitsejad tagavad parima kasutajakogemuse ja turvalisuse. Kasutajaid tuleks suunata kasutama just neid veebilehitsejaid. Vt ka nõuet FEU3.  F Kood on W3C Validaatorite eesmärk on pakkuda esmast teavet testitava koodi kohta. Valideerimise raportit ei saa käsitleda kui põhjust väita, et loodud kood on E valideeruv. kasutuskõlbmatu. Igat raporti rida tuleb käsitleda eraldi ja võrrelda seda kokku lepitud nõuetega. Tarkvaraprojekti planeerimisel tuleb arvestada valitud H7 tehnoloogiatega. Näiteks kui on kasutuses tehnoloogia, mis baseerub mitmetel kolmanda osapoole rakendustel, siis projekti teostajal ei ole võimalik tagada seda, et kõikide osapoolte genereeritud kood oleks täismahus valideeruv. Sellegi poolest tuleks eelistada neid teeke, mille väljund vastaks WCAG suunistele ja võimalikest mööndustest tuleb projekti alustamisel informeerida tellijat. Mööndused peavad olema põhjendatud, näiteks kolmanda osapoole tarkvara kasutamisel ja paremate alternatiivide puudumine. See muidugi ei tähenda seda, et valideerimisel avastatud vead (ehk “errors”) tuleb aktsepteerida. Koodis esinevad vead tuleb parandada. Muud valideerimisel saadud tulemustele tuleb anda hinnang eraldi. F Graafika, mida on Erinevad kujunduselemendid, mis ei ole lehe sisu osa, tuleks realiseerida kasutades CSS-i võimalusi. Näiteks varjud, kumerad ääred, gradiendid jmt. E võimalik realiseerida CS CSS-is kirjeldatud kujunduselemendid võimaldavad eraldada sisu visuaalist. See pakub väga head paindlikkust kujunduse muutmiseks, täienduste H8 S-iga, tuleb ka tegemiseks jmt. Ühtlasi CSS-i abil loodud graafikat on kerge kohandada vastavalt ekraanile, millel teda kuvatakse. Veebilehitseja suudab CSS-i abil loodud realiseerida CSS-iga. graafikat vastavalt külastaja ekraani võimekusele kohandada. F Vormi sisestusväljadel HTML võimaldab ära märkida, millist tüüpi väärtust sisestusväli eeldab (lisaks eeldamisele on võimalik ka lisada valideerimisreeglid, mis ka kontrollivad, kas E on kasutatud sisestatud väärtus vastab reeglitele). Eriti oluline on see aina rohkem levima hakkanud puutetundlikele ekraanidele, milledes andmete sisestamisel H9 asjakohast tüüpi. kuvatavale klaviatuurile saab ette öelda, millist tüüpi sisu on vaja sisestada ja seade automaatselt optimeerib klaviatuuri just selle jaoks. Halb näide Hea näide CSS Veebilehe valmistamisel on CSS-i roll kirjeldada, milline see veebileht välja näeb. Ehk see, millisena oleme tänapäeval harjunud veebilehti nägema, on kirjeldatud kasutades CSS-i keelt. Kui veebilehel puudub viide CSS failile, siis veebilehe väljanägemise kirjeldab HTML elementide vaikeväärtused, mille on ära kirjeldanud veebilehitseja tootja. Keskmiste ja suuremate veebilehtede loomisel ja selle CSS-i koodibaasi haldamiseks on soovitav veebilehe komponendid jagada erinevateks failideks. Siinkohal mängivad olulist rolli erinevad nn CSS-i preprotsessorid, mis võimaldavad luua CSS-i läbi struktureeritud lähenemise. Preprotsessorid on tööriistad, mis pakuvad tarkvaraloojale võimaluse jagada oma CSS pisemateks osadeks. Võimaldavad luua CSS-i arhitektuuri, kus suured komponendid toetuvad pisematele. Tänapäeval ühed levinumad CSS-i preprotsessorid on: LESS ja SASS/SCSS. RIK kasutab SCSS-i. CSS-i koodistandardi paika panemiseks ja kontrollimiseks oleks soovitav kasutada ka SCSS Linterit. Linter on tööriist, mis aitab valideerida SCSS-i koodi vastavalt kokkulepitud reeglitele. Tänapäeval on olemas abivahendid, mis kontrollivad koodi korrektsust töö käigus automaatselt. Nõuded Nr Nõude sisu Nõude seletused F Kasutatud on Arendusprotsessi kiirendamiseks ja jätkusuutlikuse tagamiseks on hea aluseks võtta valmis Front-End komponentide teek, mis pakub ühtset ökosüsteemi ja E mõnda dokumentatsiooni veebilehe valmistamiseks. RIK kasutab Twitter Bootstrap'i ja seda tuleks uutes projektides ka eelistada, kui ei ole kokku lepitud teisiti. C1 levinumat Kuna valmis teek pakub juba hulganisti komponente ja elemente, mida veebilehe valmistamisel saab kasutada, siis nende kombineerimine võimaldab luua pidevalt CSS-i juurde uusi vaateid, ilma et protsessi peaks sekkuma kujundaja. raamistikku Teegi valimisel peab peale kvaliteetse dokumentatsiooni ja populaarsusele olema oluliseks kriteeriumiks ka asjaolu, et see oleks modulaarne ja võimaldaks muuta (eelistatult Twi sisendväärtuseid (on kasutatud SCSS CSS-i preprotsessorit). Igal projektil on oma nõuded ja vajadused. Teek peab võimaldama sisse-välja lülitada oma tter Bootstrap). funktsionaalsust. Modulaarsus ja sisendväärtuste muutmine võimaldab kokku panna just sellise koodibaasi, mida konkreetne projekt vajab. Projektis raames on peab sisse lülitatud olema ainult vajalik funktsionaalsus (kasutaja browser ei tõmba alla staatilisi ressursse, mida ei kasutata). F CSS-i Veebilehitsejate tootjad on loonud võimaluse eksperimentaalseid ja/või mitte standardseid atribuute kasutada lisades atribuudi algusesse veebilehitseja tootja E lähtekood eesliidese. Kuna neid eesliiteid on vaja vaid ajal, mil kasutatav tehnoloogia pole veel standardiks saanud või nimetatud funktsionaalsus pole veel tootja poolt täies C2 sisaldab vaid mahus implementeeritud, siis lähtekoodis neid sisaldada ei tohi. Lähtekood peab sisaldama ainult standardile vastavaid atribuute. standardseid atribuute. Veebilehitsejate tootjate eesliidesed lisab eraldi rakendus (post-production). Selle jaoks on olemas erinevad nn autoprefixer tööriistad, mis pakuvad võimaluse juhtida, milliste veebilehitsejate ja milliste versioonidele eesliidest tuleb suunata (PostCSS). Halb näide Hea näide Antud kriteerium puudutab ka tänaseks juba iganenud meetodeid, mille abil püütakse sihtida mõne konkreetse veebilehitseja spetsiifilisi vigu, mis võimaldab just selle veebilehitseja jaoks kirjutada eraldi CSS-i kirjeid. Selle asemel tuleb välja selgitada mitte konkreetse veebilehitseja ja selle versioon, vaid selle võimekus. Selle jaoks on olemas nii CSS-is kui ka Javascriptis vastavad tööriistad. CSS-is on selle jaoks näiteks @support tingimus, mis võimaldab tuvastada CSS-i abil veebilehitseja võimekust. Näiteks: F CSS-i Visuaali kirjeldamiseks on kasutatud CSS-i klassi selektorit. See tähendab seda, et visuaali rakendamiseks kasutatakse CSS klasse ja/või HTML elemente. Eelistada E selektorina on tuleb visuaali sidumist CSS klassi ja vältida ID selektorit. C3 eelistatud peamiselt Nõuet ei kohaldata tüpograafia kirjeldamiseks. Tüpograafia puudutab lehekülje sisu autoreid, kes sisestavad sisu mõne tekstiredaktori kaudu. Nendeks CSS klasse. tekstiredaktoriteks on peamiselt nn WYSIWYG tüüpi tööriistad, mis võimaldavad sisu sisestada nagu seda tehakse näiteks Microsoft Wordis. Need tööriistad kirjutavad HTML-i koodi taustas ise ja nemad oskavad tähistada teksti osasid peamiselt HTML elementidega (p, h1-h6, table jne). Märkus. CSS-i klassi eelistamise soovitus tuleneb sellest, kuidas toimub CSS-i selektori reeglite täitmine. Kui CSS-is on sarnaseid reegleid, siis mille põhjal otsustab veebilehitseja, millist reeglit rakendada? Et otsus oleks võimalik teha, antakse igale selektorile kaal. Suurema kaaluga selektorite reeglid rakenduvad. ID-ga ja pikad selektorid omavad märkimisväärset kaalu. Kui erinevate arendajate poolt mingi konkreetse komponendi visuaali muutmisel on igaüks kirjutanud enda selektori, siis on ilmselge, et iga arendaja koodi lisandumisel on konkreetse visuaali kirjeldamist puudutav CSS omandanud märkimisväärset kaalu. Selle tulemusel tekib olukord, kus hilisemate muudatuste tegemine võib osutuda võimatuks. Ühtlasi selline lähenemine läheb vastuollu levinumate CSS-i klassi nimetamise põhimõtetega. Halb näide Hea näide F CSS Mida pikem on CSS-i selektor, seda kauem võtab veebilehitsejal aega selle täitmine, samuti väheneb koodi jälgitavus ja loetavus. Seepärast on soovitav, et CSS-i E selektorite selektor ei oleks pikem kui kolm-neli sammu. C4 pikkus on Kuna CSS-i selektori täitmist alustatakse vasakult paremale, siis need kolm-neli sammu peaks eelistatuna olema lähimad struktuurid. Tuleb ka arvestada, et pikem mõistlik. selektor omab märkimisväärset suuremat kaalu reeglite rakendumisel (loe eelmise punkti märkust). Kui erand on põhjendatud, siis on erandid lubatud. Aga läbivalt tuleb siiski kasutada kuni kolme-nelja sammu pikkusi selektoreid. Halb näide Hea näide Veebilehitseja tootjad pidevalt optimeerivad oma algoritme, et CSS-is kirjeldatud reeglite täitmine oleks võimalikult kiire. Kiirust mõõdetakse küll millisekundites, kuid mahukamate projektide korral võib tekkida olukord, kus mahukate selektorite täitmine võtab põhjendamatult palju ressurssi. F On kasutatud CSS-i klasside nimetamine peab olema läbi rakenduse ühesugune. Tänapäeval kõige levinum CSS klasside nimetamise põhimõte on BEM (block-element-modifier). E mõnda Nõue tagab selle, et kui koodi kirjutavad erinevad arendajad, siis klasside nimetamise loogika on läbivalt sama. See muudab koodi ühtsemaks ja lihtsamini C5 levinumat jälgitavamaks. Ühtlasi pakub BEM kahele kõige suuremale veebilehtede arendamise murekohale lahendust. Esiteks nõuab see seda, et kood oleks semantiline ja CSS klassi modulaarne. Teiseks vähendab võimalust, et erinevate arendajate poolt koostatud kood tekitab konflikte (ehk kirjutatakse teineteise vormingud üle). nimetamise põ himõtet. BEM kohta leiab täpsemat infot siit: https://en.bem.info Halb näide Hea näide F SCSS-i Senised praktikad on näidanud, et veebilehe arendamisel ja ülesehitamisel on kõige paremaid tulemusi andnud komponendipõhine lähenemine: SCSS-i lähtekood on E lähtekood on struktureeritud nii, et iga komponent on kirjeldatud oma failis. Sealjuures üldised ehk globaalsed parameetrid on koondatud ühte faili. See tähendab seda, et leht C6 struktureeritu koosneb erinevastest plokkidest ja plokid elementidest. Iga komponendi muutmine/parendamine on võimaldatud nii, et see ei vajaks teiste komponentide samaaegset d muutmist (st ei segaks teiste komponentide arendajaid). Selleks tuleb jagada SCSS koodibaas väiksemateks loogilisteks osadeks, milleks on näiteks navigatsioon, komponendip vormi komponendid, modaalaknad jmt. õhiselt.  F CSS klasse Ei ole hea praktika siduda Javascripti funktsionaalsust HTML elemendiga CSS klassi abi. Kasuta selleks data-* atribuute. Nõnda tekitatakse Javascripti ja HTML-i E kasutatakse sidumiseks universaalne põhimõtte, mis ei mõjuta lehe semantikat ega sega visuaali ja Javascripti funktsionaalsust. C7 vaid visuaali kirjeldamiseks. Responsiivsus Responsiivsete veebilehtede arendamine sai hoo sisse, kui oli vaja hakata veebilehte muutma kasutatavaks ka väiksematel ekraanidel: nutitelefonidel, tahvlitel. Nüüd aga me ei saa enam lähtuda kolmest ekraanist: mobiil, tahvel ja arvuti. Ekraani mõõte, millega veebilehti tänapäeval külastatakse, on väga palju. Selleks, et igas suuruses oleks veebileht tarbitav, tuleb muuta kogu veebileht sõltuvaks ekraani mõõdust. Ühest küljest aitab meil seda teha juba grid süsteemi rakendamine, kuid grid määrab ära vaid komponentide laiused. Et oleks võimalik juhtida ka komponentide ja nende elementide propotsioone (teksti suurus, padding-marging jne) lähtuvalt ekraani suurusest, siis seda aitab meil saavutada juba mõnda aega CSS-is kasutatav ühik „rem“. Mida ühik „rem“ tähendab? Kõige lihtsam on seda seletada nõnda, et selle väärtus sõltub HTML-i juurelemendi (root element) teksti suurusest. HTML-i juurelement on element „html“. Vaikimisi on selle elemendi teksti suurus 16px. See ütleb meile, et 1rem = 16px. Mida me saame selle teadmisega peale hakata? Me saame kogu veebilehel kasutatava disaini panna sõltuma juurelemendi teksti suurusest. Vaatame alljärgnevat näidet: Pikslites kirjutades oleks: Kui aga muudame juurelemendi teksti suuruse sõltuvaks ekraani suurusest (ühtlasi määrame ära minimaalse ja maksimaalse teksti suuruse), siis saame luua olukorra, kus veebilehe komponentide ja elementide propotsioonid muutuvad vastavalt sellele, kui suur on lehe külastaja veebilehitseja aken. Nõnda ei teki enam olukord, kus suurel ekraanil on tekst ja elemendid liiga pisikesed ja väiksel ekraanil aga vastupidi. Meil on olemas nüüd keskne koht, mille kaudu saame muuta kogu veebilahenduse kujunduse propotsioone. Loe täpsemalt Fluid Typegraphy. Lisaks CSS-i rakendamisel on mõistlik kaaluda varianti luua täiendavaid tööriistu (Utilities), mis hõlbustavad teha kasutajaliidese kujunduses parendusi nõnda, et selle jaoks ei pea muutma komponenti või selle elemente. Näiteks Bootstrap pakub selliseid tööriistu https://getbootstrap.com/docs/4.1/utilities/borders/ Responsiivsete lahenduste maailmas osutuvad need tööriistad hädavajalikuks, kuna arenduse käigus on vajadus veebilahenduse propotsioone juhtida vastavalt tekkinud olukorrale (näiteks lähtuvalt ekraani suurusest). Javascript Tänapäeval kuulub Javascript iga veebilahenduse juurde. Javascript on see osa veebilehest, mis annab sellele dünaamilisuse ja võime reageerida kasutaja toimingutele. Ühtlasi aitab luua ka nn pol yfill-e, mille abil saab arendaja kasutada veebilehitsejas API-sid, mis on vaikimisi arendaja poolt toetatud veebilehitsejas puudu. See võimaldab kasutada tehnoloogiaid, mis on muidu kasutatavad vaid uuemates veebilehitsejates. Dokumendiobjektide mudel (DOM, Document Object Model) DOM on platvormist ja keelest sõltumatu W3C poolt standardiseeritud HTML dokumentidega suhtlemise liides. See liides võimaldab näiteks Javascriptil lugeda ja muuta veebilehte. Selle liidesega suhtlemine on ka põhjus, miks osad veebilahendused tunduvad kasutaja jaoks aeglased või lihtsalt ei toimi ootuspäraselt. Kuna DOM sisaldab kogu informatsiooni kuvatava veebilehe kohta, siis on tegemist väga suure objektiga. Selles mingite muudatuste tegemine nõuab veebilehitsejal erinevaid tegevusi. Ja need tegevused, mida veebilehitseja mingi toimingu tulemusel peab täiendavalt tegema, on need, mida me soovime arendamise käigus hoida minimaalsena. Oluline on siinkohal ka meeles pidada, et on andmeid, mida DOM-is ei sisaldu. Näiteks kui me küsime Javascripti vahendusel elemendi kõrgust-laiust, siis veebilehitseja peab selle väärtuse küsimise hetkel välja uurima. Kui seda küsimist aga tehakse korduvalt ja erinevates skriptiosades erinevatel põhjustel, siis see on üks nendest põhjustest, mis võib muuta rakenduse aegalseks. Selles, et neid probleeme vältida, on veebilehitseja tootjad loonud erinevaid täiendavaid API-sid, mille abil oleks võimalik DOM liidesega efektiivsemalt suhelda. Näiteks väga tihti on veebilahendustes vaja teada saada, kas üks või teine element on kasutaja jaoks nähtav. Ajalooliselt on seda probleemi erinevalt lahendatud, kuid kõik need nõuavad veebilehitsejalt liigset tööd. Selle jaoks on nüüd aga olemas eraldi Intersection Observer API, mis võimaldab seda funktsionaalsust paremini oma arendustest rakendada. Arendajal võib tekkida ka vajadus teada saada, kas DOM-is on midagi muutunud. Kas mingi osa skriptist on teinud HTML-is mingeid muudatusi. Varasemalt tuli selleks kirjutada eraldi skript, mis käib DOM-ist perioodiliselt muudatusi otsimas /kontrollimas. Skripti kirjutamise asemel on nüüd olemas efektiivsem muudatuste jälgimise võimalus - kasutada MutationObserver API. DOM-iga suhtlemise meetodites on toimunud viimastel aastatel oluline nihe. Kui eelnevalt tuli arendajal kirjutada kood, mis mingi reegli alusel küsib DOM-ilt infot, siis nüüd on pigem vastupidi. DOM ütleb ise, kui jälgitav tunnus on muutunud. Kui eelnimetatud DOM-i puudutavad API-d on midagi, mida pakuvad veebilehitsejad, siis nendele lisaks on erinevad arendajad loonud veel täiendavaid liideseid, mis on veebilehitsejast sõltumatud. Üks populaarsem liides on Virtual DOM. Internetist võib selle kohta leida väga palju materjali, aga lihtsamalt öeldes on tegemist DOM-i abstraktsiooniga ehk lihtsustatud ja eraldiseisva versiooniga kuvatavast veebilehest. Kuna veebilehitseja enda DOM on väga mahukas ja sellega suhtlemine võib osutuda ressursinõudlikuks, siis Virtual DOM pakub võimalust teha muudatusi veebilehes nõnda, et Virtual DOM ise vastutab selle eest, millised muudatused tuleb saata veebilehitseja DOM-i, et kasutaja saaks neid ka näha. Sellisel viisil muudetakse veebilehitseja DOM-i vaid siis, kui seda tõesti on vaja teha ja seda püütakse teha võimalikult ressursisäästlikult. Virtual DOM-i kasutavad näiteks sellised tehnoloogiad nagu React, Vue, Angular jne. Eelnimetatud tehnoloogiad on pigem raamistikud, mille üks osa on Virtual DOM-i rakendaine. Internetist võib leida ka vaid Virtual DOM-i liidese jaoks mõeldud Javascripti teeke. Nõuded Nr Nõude sisu Nõude seletused FEJ1 JS-i lähtekood on JS kirjutamisele tuleb läheneda modulaarselt. Koodibaas tuleb jagada väiksemateks loogilisteks komponentideks. Eelistada tuleb ES6 komponendipõhine mooduleid (import/export). See parandab: funktsionaalsuse selget eraldatust koodi uuesti kasutamist koodi testimist isolatsioonis koodi hoomatavust arendaja poolt FEJ2 Vorming, linter ja build protsess Projekt sisaldab käske koodi lintimiseks, testimiskes ja vajadusel kompileerimiskes. Projekti raames peab kood jälgima ühtset stiili ja standardit. Ühtne stiil ja standard tagatakse läbi konfigureeritud style guide (mõne laialt levinud) ja linteri. Linter aitab: välja tuua potentsiaalseid vigu koodis parandada koodi loetavust hoida koodi kvaliteeti keskenduda probleemi lahendamisele - https://eslint.org/ - https://standardjs.com/ - https://github.com/airbnb/javascript/  - https://gulpjs.com/ - https://webpack.js.org/ - https://docs.npmjs.com/misc/scripts FEJ3 Kommentaarid Koodi kommenteerimiseks/dokumenteerimiseks eelista JSDoc formaati - http://usejsdoc.org/index.html. kasuta // järgneva koodi rea kommenteerimiseks kasuta // FIXME: et välja tuua probleeme kasuta // TODO: et välja tuua lahendusi probleemidele See annab: võimaluse genereerida dokumentatsiooni funktsioonide, meetodite, konstruktorite kohta ühtne kommenteerimise stiil koodi editorid võivad kuvada lisa informatsiooni kasutatava funktsionaaluse osas Veebi sisu juurdepääsetavussuunised (WCAG) ja üleüldised kasutajakogemust puudutavad nõuded Veebi sisu juurdepääsetavussuunised hõlmavad mitmeid soovitusi veebi sisu juurdepääsetavuse parandamiseks. Eesti keeles on võimalik tutvuda suuniste täisdokumendiga siin: http://www.w3.org /Translations/WCAG20-et/. Arendusprojektis tuleb kasutada raamistikke, mille väljund HTML peab vastama WCAG suunistele. Kuid peamised põhimõtted on: Veebileht on struktureeritud korrektselt. Siin on mõeldud just seda, millest oli juttu ka juba HTML-i peatükis. Tuleb eelistada tähendustega elemente. Kui veebilehel on loetelu, siis tuleb kasutada ka vastavat HTML elementi. Täiendavat semantikat võimaldab lisada WAI-ARIA rollide mudel (https://developer.mozilla.org/en-US/docs/Learn/Accessibility/WAI-ARIA_basics ) Rolle saab kasutada ka sellistes olukordades, kus semantiliste elementide kasutamine pole mingil põhjusel võimalik. Veebilehel esinevatele ajas muutuvatele meediumitele saab WAI-ARIA States and Properties mooduli abil lisada täiendavat informatsiooni. Kasuta tekstilist vastet kui visuaalselt on näha vaid ikoon, video, audio jmt. Kui lehel on kasutatud nupuna ikooni, siis lisa nupule ka info, mida see ikoon tähendab. Seda on kõige lihtsam teha kasutades HTML-is title või alt atribuuti. Vormi elementidel tuleks kasutada label elementi. Ära keskendu ainult visuaalile. Lehe sisu peab olema arusaadav ka siis, kui lülitame välja näiteks CSS või kui lehte loeb ette kasutajale tarkvara. Oluline on silmas pidada, et ikooniga või värviga tähistatud kujunduselemendid oleks ka vaegnägijale tarbitavad (https://www.w3.org/TR/WCAG20-TECHS/G95.html, https://www.w3.org/TR/WCAG20-TECHS/G18.html). Veebileht on kasutatav ka klaviatuuriga. Komponentide loomisel tuleks arvestada kasutaja harjumustega. Kui kasutajal on harjumus checkbox teha tühik klahviga aktiivseks, siis see peaks toimima ka siis, kui see checkbox on loodud kasutades Javascripti abi. Täiendavad kasutajaliidese komponentide nõuded leiad RIKi UIG lehelt Nõuded Nr Nõude sisu Nõude seletused F Meediumitel, mis Igal elemendil, millega kasutaja saab midagi teha (lingid, vormi väljad, nupud jmt), on kirjeldatud hover olek. Hover olek on see, kui kasutaja liigub hiirega E võimaldavad külastajale selle elemendi peale. Erandiks on puutetundlikud ekraanid, kus hover olek võrdub klikiga. See tähendab, et funktsionaalsused, mis sõltuvad hover-ist, tuleb W1 interaktsiooni, on puutetundlikel ekraanidel ümber teha klikipõhiseks. Siit ka soovitus otsutada, milline on primaarne funktsionaalsus. Üldiselt liigub maailm selles suunas, et kirjeldatud nn hover olek. funktsionaalsus, mis toob kasutajale midagi nähtavale hover-i abil, ehitatakse siiski kliki peale, kuna tõusev trend on see, et veebilehti külastatakse pigem puutetundlike ekraanidega. F Vormi elementidel on Focus olek aitab kasutajal eristada aktiivset vormi elementi teistest. E kirjeldatud focus olek. W2 Märkus: selleks, et hinnata, kas focus on normaalselt nähtav, tuleb lähtuda WCAG poolsest soovitusest teksti värvi ja teksti taustavärvi vaheline kontrasti määrast. Tööriist testimiseks: https://webaim.org/resources/contrastchecker/ F Elementidel on Active oleks aitab kasutajal eristada aktiivset elementi. Näiteks klaviatuuri abil lehel ringi liikudes saab aktiivne interaktsiooni võimaldav element teda E kirjeldatud active olek. eristava vormingu. W3 F Elementidel on Mahukate veebilehtede korral on hea anda lehe külastajale tagasisidet viidete kohta, mida ta on juba külastanud. Sedasi lehe korduval külastamisel on E kirjeldatud visited olek. tema persionaalne ajalugu näha. W4 F Veasituatsioonid on Veasituatsioonide tekkimisel antakse kasutajale asjakohast tagasisidet. Teade on tähistatud nii värvi kui ka vastava ikooniga. Kehtib reegel, et süsteemi E sõnastatud asjakohaselt tõrked, mis ei tulene kasutaja tegevusest, tähistatakse punase värviga. Muud tõrked, mis on põhjustatud kasutaja käitumisest, pigem oranziga (ehk W5 ja omavad vastavalt hoiatava, informatiivse tooniga). situatsioonile korrektset visuaali. F Situatsioonid, kus Veebilehel on arvestatud olukordadega, kus näiteks tabel on tühi. Sellistel olukordades tuleb kasutajale anda infot, miks see on tühi ja vajadusel lisada E informatsioon on juurde, mida ta peaks tegema, et see infoga saaks täidetud. W6 mõnes komponendis Sama kehtib ka ajas muutuvate meediumite kohta. Kui mingi informatsiooni laadimine nõuab rohkem aega, siis selle laadimise kohta tuleb anda kasutajale puudu või on alles tagasidet. saabumas, on selgelt tähistatud. F Veebilehel kasutatud Nii nagu päris maailmas, nõnda ka veebis, peavad animatsioonid peegeldama objektide kergust, raskust, suurust jmt. Animatsioonid peavad olema E animatsioonid kasutajat toetavad ja kirjeldama animeeritava elemendi suhet ülejäänud lehega. Et animatsioonid ei hakkaks liialt riistvara koormama ega kasutajat W7 parendavad ärritama, tuleb animatsioonide kirjeldamisel lähtuda animatsiooni optimeerimise põhimõtetest. Nendeks on: kasutajakogemust. - animatsioonid ei tohi nõuda veebilehitsejalt põhjendamatuid kordusi; - animeerida tuleb CSS-i atribuute, mis on veebilehitsejate poolt optimeeritud; - animatsioonid tuleb käivitada komplektina ja ajastatult veebilehitsejale kõige paremal hetkel (requestAnimationFrame). Mida ühe või teise CSS-i atribuudi muutmine veebilehitsejalt nõuab, saab tutvuda lehel CSS Triggers Märkus: Animatsioonid peavad olema põhjendatud, kui animatsioon on põhjendamata ja/või näiteks epileptikutele isegi ohtlik, siis see kriteerium ei ole täidetud . Meediumite kasutamine veebilehel (veebilehe laadimiskiirus) Mitmekesise meediumi kasutamine veebilehel avaldab otsest mõju lehe laadimiskiirusele ja sellele, kui kiiresti veebilehitseja suudab lehe külastajale valmis meisterdada. Mida suurem on veebilehe toimimiseks vaja erinevate ressursside osakaal, seda kauem läheb aega, mil leht on kasutamiseks valmis. Jättes korraks kõrvale CSS ja Javascript failid, siis kõige suuremateks veebilehe kuvamise blokeerijateks on pildid ja videod. Piltide kasutamisel tuleb pöörata tähelepanu nende mahule. Ei ole sobilik lisada veebilehele pilte, mille maht on põhjendamatult suur. Kui on alust arvata, et kasutavate piltide mahud on liiga suured, siis alljärgnevad tööriistad võimaldavad nende mahtusid vähendada: - http://www.jpegmini.com - https://pngquant.org - https://imageoptim.com - https://github.com/google/guetzli Videode kasutamisel tuleb arvestada sellega, et videode vaatamiseks on vaja selle mängijat. Igasuguse mängija visualiseerimine ja käivitamine võtab aega, kuna mängija jaoks on vaja alla laadida selle käivitamiseks vajalikke ressursse. Kui lehel on mitu sellist mängijat, siis iga mängija jaoks tuleb veebilehitsejal tööd teha. Iga täiendav liigutus aga nõuab aega ja see avaldab märkimisväärset mõju lehe kiirusele. Mis puudutab aga CSS-i ja Javacripti faile, siis nende kasutamisel tuleb tekitada olukord, kus: - kõik lehel kasutusel olevad CSS-i failid oleksid liidetud üheks failiks ja faili sisu oleks minimeeritud; - kõik lehel kasutusel olevad Javascripti failid oleksid liidetud üheks ja faili sisu oleks minimeeritud. Veebilehe kiiruse optimeerimise ja selle mõjude kohta saab täiendavalt lugeda lehelt: https://kinsta.com/learn/page-speed/ ja https://developers.google.com/web/fundamentals/performance/critical- rendering-path/ Pildigraafika optimeerimine Tänapäeval on võimalik kasutada erinevaid tööriistu, mis võimaldavad juba töö käigus pildigraafikat optimeerida. Selle jaoks tuleb vaid seadistada taustateenus, mis jälgib kataloogides toimunuid muudatusi ja vastavalt etteantud mustritele käivitavad optimeerimist teostavad skriptid. Kõige levinumad taustateenuste skriptide jooksutajad on: - Gulp - Grunt - Webpack Kuna kõik kolm nimetatud kasutavad mooduleid, mis on kirjutatud kasutades Javascripti, siis on võimalik ilma suurema vaevata luua lähtuvalt vajadusest projektile omane skript pildigraafika optimeerimiseks. Seda siis eeldusel, et mõni juba olemasolevatest ei sobi. Küll aga juba vabalt kättesaadavad skriptid sisaldavad enimlevinud algoritme erinevate pildigraafika optimeerimiseks. Tasulistest tarkvaradest tooks välja JPEGmin-i. Tegemist on suurepärase tööriistaga just JPG piltide optimeerimiseks. Tihti saavutab see pea 3x mahu vähenemise ilma et pilt kaotaks silmnähtavalt kvaliteedist. Tutvu pildigraafika erinevate optimeerimise meetoditega siin. Responsiivsed pildid Tehnoloogi aitab lehe autoril lisada veebilehele piltmaterjali sellisel kujul, mis võimaldab neid tarbida erinevate suurutel ekraanidel. Siinkohal tuleks silmas pidada peale pildi kõrguse ja laiusele ka selle mahtu ja fookuspunkti. Fookuspunktist tuleb kinni pidada, et välitda olukordi, kus pildil kujutatud oluline element oleks ebanormaalselt lõigatud või muul viisil rikutud. HTML-i elementile img on võimalik lisada juurde täiendav parameeter, mis sisaldab informatsiooni võimalike alternatiivsete pildi variatsioonide kohta: https://developer.mozilla.org/en-US/docs/Learn /HTML/Multimedia_and_embedding/Responsive_images Koodibaasi kvaliteedi tagamine CSS-i kirjutamisel on suureks abiks erinevad nn CSS-i preprotsessorid. Need on tööriistad, mille abil on võimalik läheneda CSS-i kirjutamisele struktueeritult. Preprotsessorid muudavad CSS-i skriptikeeleks, mis kompileeritakse tavaliseks CSS-iks, mida veebilehitsejad oskavad lugeda. Skriptikeelelaadne kirjutamine võimaldab korduvaid tegevusi hoida ühes kohas. CSS-i preprotsessorid Tänapäeval levinumad CSS-i preprotsessorid on LESS ja SASS/SCSS. Kuna viimasel ajal on populaarsust kogumas pigem SASS/SCSS, siis võiks täna alustavates projektides pigem eelistada SASS/SCSS preprotsessorit. Seda põhjusel, et nimetatud preprotsessori kompetentsi on tööturul lihtsalt rohkem. CSS-i postprotsessorid (PostCSS) Tänapäeval täiendava võimalusena on loodud tehnoloogia, mille abil on võimalik olemasolevat CSS-i järeltöödelda. Need tööriistad pakuvad võimaluse CSS-i lähtuvalt sisendparameetritele või teatavatele mustritele muuta selliseks nagu vaja. Näitena võib tuua olukorra, kus ühe rakenduse jaoks tehtud CSS oleks vaja muuta teise rakenduse jaoks sobilikuks nõnda, et see hakkaks vastama uue rakenduse stiilinõuetele (näiteks vaja muuta kasutatavat fonti, värve jmt). Üks levinum põhjusi kasutada PostCSS-i on aga vajadus (Autoprefixer) tagada uuemate tehnoloogiate tagasiühilduvat tuge ammutades andmeid Can I Use andmebaasist. Tagasiühilduvat tuge vajavad: - eksperimentaalses staatuses olev funktsionaalsus See on funktsionaalsus, mis on küll veebilehitsejal olemas, aga tootja poolt on märgitud eksperimentaalseks. Eksperimentaalsete funktsionaalsuste eristamiseks kasutavad veebilehitsejad eesliiteid (prefix). Näiteks -webkit-box-shadow (spetsifikatsioon näeb ette aga box-shadow). Igal tootjal on oma. - varasema (kehtetuks tunnistatud) funktsionaalsust kirjeldava spetsifikatsiooni toetamine Uute veebitehnoloogiate lisamine veebilehitsejatesse on modulaarne. Iga tootja otsustab ise, millal millist moodulit oma tootesse lisab. Tulemuseks on see, et osa veebilehitsejaid toetavad funktsionaalsuse varasemat spetsifikatsiooni, teised aga uuemat. Sellest tulenevalt kasutavad veebilehitsejad erinevat süntaksit funktsionaalsuse rakendamiseks. Autoprefixed on PostCSS-i moodul, mis on loodud selleks, et lahendada eelnimetatud tagasiühilduva toega seotud küsimusi, lisab vajadusel eesliitega juurde puuduvad atribuudid ja teeb süntaksi parendusi seal kus vaja. PostCSS pakub lahendusi erinevatele probleemidele. Vabalt kättesaadavatest moodulitest saab ülevaate siit: https://www.postcss.parts. Kuna moodulid on kirjutatud kasutades Javascripti, siis on lihtne neid mooduleid ise lähtuvalt projekti spetsiifikast juurde luua. Linter (lint, linter, linting) Linter on tööriist, mis otsib koodist võimalikke vigu. Front-End arenduses saab sellist tööriista kasutada automaatse validaatorina, mis testib iga arendaja koodi vastavalt ette antud standardile. Selline tööriist pakub võimalust defineerida koodistandard iga projekti jaoks eraldi (ehk saab panna sõltuma projekti spetsiifikast). Selliselt saab tagada, et kõikidel projektis osalevatel arendajatel on kood kirjutatud järgides samu põhimõtteid. Muud nõuded Nõuded Nr Nõude sisu Nõude seletused F Rakendus peab olema Nii avalikuks kui ka sisemiseks kasutamiseks tehtav rakendus peab olema graafiliselt eskaleeruv (responsive web design) ja mugavalt kasutatav kõigi E graafiliselt eskaleeruv. enamlevinud seadmete resolutsioonidega vahemikus 320x568px kuni 3840x2160px. Ühegi nimetatud resolutsiooni korral ei tohi tekkida horisontaalset U1 kerimisriba. Implementatsioon peab jälgima “Mobile first” kontseptsiooni. F Vaikimisi veebilehitseja Kõik aknad, mis avanevad peavad olema sellised, mida üksi brauser oma vaikimisi konfiguratsioonis ei blokeeri. St ei tohi tekkida olukorda, kus E poolt blokeeritavaid veebilehitseja blokeerib vaikimisi avatava akna ning kasutaja peab selle avamise eraldi veebilehitsejas lubama. U2 hüpikaknaid ei tohi kasutada. Veebilehitseja poolt võidakse blokeerida avatav aken olukorras, kus rakendus üritab seda avada automaatselt, st mitte kasutaja vahetu tegevuse peale. Näited: Veebilehitseja blokeerib avaneva akna, sest see avaneb läbi Javascripti automaatselt. Veebilehitseja blokeerib avaneva akna, sest see avaneb läbi Veebilehitseja ei blokeeri avanevat akent, sest see avaneb Javascripti automaatselt. kasutaja vahetu tegevuse peale. F Veebipõhine E kasutajaliides peab olema Operating system Browser U3 kasutatav enamlevinud veebibrauseritega. Windows Internet Explorer 11 Minimaalselt Mozilla Firefox, Safari, Chrome ja Windows Edge (2 viimast versiooni) Edge arenduse testimise hetkel 2 viimast (major) Windows Google Chrome (2 viimast versiooni) versiooni ning Internet Explorer 11. Windows Mozilla Firefox (2 viimast versiooni) macOS Safari (2 viimast versiooni) macOS Google Chrome (2 viimast versiooni) macOS Mozilla Firefox (2 viimast versiooni) iOS Safari (2 viimast versiooni) iOS Google Chrome (2 viimast versiooni) Android Google Chrome (2 viimast versiooni)  Lisa nr 4 Riigihanke „Täitmisregistri hooldus- ja arendustööd“ (viitenumber 266570) hankedokumentide juurde „Täitmisregistri hooldus- ja arendustööd“ hanke raamlepingu tehniline kirjeldus Riigihanke viitenumber 266570 1. Hanke eesmärk ja üldinfo 1.1 Käesoleva hanke eesmärk on sõlmida raamleping ühe pakkujaga, kes hakkab teostama Justiitsministeeriumi Täitmisregistri tarkvara hooldus- ja lisaarendustöid. 1.2 Täitmisregistri hooldus- ja arendustööde eesmärk on registri tõrgeteta töötamise tagamine ning selle kasutamise ja hooldustööde teostamise raames ilmnenud muudatusvajaduste või edasiarenduste realiseerimine. 1.3 Raamleping sõlmitakse 24 (kahekümne neljaks) kuuks. 1.4 Raamlepingu eeldatavaks maksumuseks on 200 000 eurot (km-ta). 2. Täitmisregistri tutvustus 2.1 Täitmisregister on Justiitsministeeriumi haldusalas loodud register, kus peetakse arvestust käimasolevatest aktiivsetest täitemenetlustest ja nendega seotud maksekonto ja registervara arestidest. Täitmisregistri kaudu liiguvad krediidi- ja makseasutustesse elektroonilised maksekonto arestimisaktid. Arestimisakte saavad saata kohtutäiturid, Maksu- ja Tolliamet (edaspidi EMTA) ning Rahapesu Andmebüroo (edaspidi RAB). Lisaks on täitemenetluse raames võimalik arestimisakte edastada ka EMTA-le tagasinõude arestimiseks ja Pensionikeskusele väljavõetava pensionivara arestimiseks. Arestimisakt saab olla maksejuhisega (raha kantakse üle esimesel võimalusel) või maksejuhiseta (raha jääb omaniku kontole, kuid seda ei saa kasutada). Uurimisasutused saavad oma menetluste raames Täitmisregistri kaudu küsida krediidi- ja makseasutustelt pangasaladust. Täitmisregistri juurde on loodud avalik veebiliides. Veebiliidese kaudu on täitemenetluse osapooltel (võlgnik, sissenõudja) võimalik tutvuda endaga seotud täitemenetluse andmete ja arestidega. Peale autentimist kuvatakse kasutajale kõik aktiivsed ja hiljuti lõpetatud sundtäidetavate nõuete detailne info. Isik näeb muuhulgas oma menetluste seisu, nõuete jääke, menetlevat kohtutäituri või EMTA ametniku kontaktinfot ning muud olulist menetluse teavet. 2.2 Tehnilised nõuded: 2.2.1 Äriloogika kihi ehk backend teenuste loomiseks kasutatakse Java programmeerimiskeelt (viimane OpenJDK LTS versioon, hetkel 17). 2.2.2 Mikroteenused on üksteisega lõdvalt ühendatud, eraldi paigaldatavad ning omavad sõltumatuid andmebaase. Ärikihi teenused vahetavad omavahel andmeid Dapr raamistiku (https://dapr.io) abil 2.2.3 Teenused realiseerivad REST liidese JSON andmeformaadiga. Mikroteenuseid tarbivad nii Täitmisregistri kasutajaliides kui ka väliste osapoolte poolt kutsutavad x- tee teenused. 2.2.4 Teenuste loomiseks kasutatakse Spring MVC raamistikku Spring Boot laiendustega: 2.2.4.1 Andmebaasipäringud JPA (Hibernate) ja Spring Data baasil. 2.2.4.2 Autentimine ja autoriseerimine Spring Security baasil (teenuste ligipääsupiirangud). 2.2.4.3 Swagger UI liides teenuste dokumenteerimiseks ja testimiseks (arenduskeskkondades). 2.2.4.4 Logimiseks kasutame SLF4J raamistikku, mille korral tellija saab ise seadistada konkreetse logimise raamistiku (tellija plaanib kasutada OpenTelemetry raamistikku). 2.2.5 Teenus pakendatakse Dockeri konteinerina (Docker image), millesse lisatakse nii teenus nn. paksu jar-ina (fat jar) - see sisaldab nii teenust kui ka tema sõltuvusi ja käivitamiseks vajalikku platvormi ehk Tomcat sisseehitatud rakendusserverit. 2  Teenus ei vaja eraldiseisvat rakendusserverit, see käivitatakse tavalise jar failina Java käitluskeskkonnas. Konkreetse teenuse käivitamiseks vajalik konfiguratsioon (kasutatavate teenuste nagu andmebaasid jne aadressid) antakse konteinerile väljastpoolt, s.t. sama konteinerit saab kasutada erinevates (näiteks test- ja live) keskkondades. Konfiguratsioon antakse ette Helm chart'ina. 2.2.6 Andmebaasiks on PostgreSQL andmebaas. 2.2.7 Täitmisregister pakub X-tee teenuseid välistele andmekogudele (uurimisasutused, krediidi- ja makseasutused) ning väliste andmekogude X-tee teenuseid (Äriregister, Rahvastikuregister). Liidestamiseks kasutame SOAP protokolli. 2.2.8 X-tee liidesed genereeritakse automaatselt WSDL (SOAP teenus) teenuskirjeldusfailidest. Genereeritud kood pakendatakse eraldiseisvasse java paketti (jar package) selleks et põhiteenuste lähtekood oleks selgemini hallatav. 2.2.9 Menetlusinfosüsteem esitluskiht teostatakse veebirakendusena Angular raamistikku kasutades. Võimalusel kasutatakse Javascripti asemel Typescript programmeerimiskeelt kuna see lisab kasutajaliidesele staatilise tüüpimise. 2.2.10 S3 protokollil põhinev repositoorium dokumentide säilitamiseks (tellijal on kasutusel Cloudiani server). 2.3 Arendus- ja testkeskkondades kasutatakse ainult testandmeid. Andmetöötluse vajaduse ilmnedes Live keskkonnast antakse töödeldavad andmed reeglina hägustatud või muul viisil anonümiseeritud kujul. 3. Tööde teostamise tingimused 3.1 Tööde teostamiseks sõlmitakse hankelepinguid (alates 20000 eurot) või esitatakse tööde tellimuskiri. 3.2 Hankelepingute raames peab pakkuja valmis olema pakkumuses fikseeritud tunnitasu alusel: 3.2.1 teostama arendustöid funktsionaalsuse põhiselt: 3.2.1.1 Sisendiks on konkreetse tulemi (skoobi) tellimus (kirjalikus taasesitamist võimaldavas vormis, nt e-post), sh tähtaeg. 3.2.1.2 Pakkuja annab valminud tööd üle hankijale koos tööde üleandmisaktiga. 3.2.1.3 Pärast hankija poolsete tööde vastuvõtmist esitab pakkuja hankijale arve. 3.2.2 teostama hooldustöid: 3.2.2.1 Sisendiks on konkreetse teenuse tellimus (kirjalikus taasesitamist võimaldavas vormis, nt e-post), sh tähtaeg. 3.2.2.2 Pakkuja peab kord kvartalis hankijale raporteerima selleks hetkeks hooldustöödeks kulunud/teostatud tundide arvu koos teostatud tööde kirjeldusega (nt JIRA ticket). 3.2.2.3 Hooldustööde eest tasumine toimub kaheksas osas – pakkuja esitab iga kvartali möödudes hankijale arve. Arve summa suuruseks on kvartalis teostatud tööde maht. 3.2.3 Täpsem tellimuste esitamise kord sätestatakse raamlepingus. 3.3 Hooldustöödena käsitletakse töid, mis tagavad infosüsteemi toimivuse (korrasoleku, terviklikkuse, jõudluse jms). Hooldus sisaldab kaugtuge, vigade ennetamist ja parandamist, uute redaktsioonide ja versioonide ning nendega seotud dokumentatsiooni üleandmist. Samuti hõlmab hooldus infosüsteemi kohandamist Tellija vajadustele, eeldusel, et see ei nõua olulist ümberprogrammeerimist ega uue toote loomist. 3.4 Arendustöödena tellitakse infosüsteemi funktsionaalsuse parandamist ja täiendamist ning teenuse arendamisega seonduvaid töid. Arendustööd sisaldavad endas tehnilist konsultatsiooni, süsteemi- ja detailanalüüsi läbiviimist, programmeerimistöid, testimist, dokumentatsiooni koostamist ja vajadusel koolitusi. 3 3.5 Arendustöö teostatakse tellija juures asuvas arenduskeskkonnas. Tellija tagab ligipääsu vajalikele keskkondadele ja vajadusel omapoolse abi. 3.6 Hankelepingute alusel teostavate tööde aja raporteerimiseks ning tööülesannete jälgimiseks ja haldamiseks kasutatakse RIKi projektijuhtimise keskkonda JIRA. 3.7 Pakkuja poolt teostatavatele arendustöödele kehtib garantii 12 kuud alates töö vastuvõtmisest. 4. Projektipõhised nõuded ja töökorraldus Projekti arendustööd peavad vastama RIKis kehtestatud nõuetele, mille hulgas tuleb arvesse võtta järgmisi nõudeid: 4.1 Nõuded arendustele (lisa 4-1); 4.2 Nõuded dokumentatsioonile (lisa 4-2) 4.3 Arendamise tavad ja töökorraldus (lisa 4-3) 4.4 Nõuded testimisele (lisa 4-4) 4.5 Front-end nõuded (lisa 4-5) 4  KINNITATUD Direktori 24.07.2023 Käskkiri nr 58 Lisa 2 „Täitmisregistri hooldus- ja arendustööd“ Riigihanke viitenumber 266570 Hankedokumendid REGISTRITE JA INFOSÜSTEEMIDE KESKUS Registrite ja Infosüsteemide Keskus teeb hankemenetluses osalemisest huvitatud isikutele ettepaneku esitada pakkumusi vastavalt hanketeates ja hankedokumentides sisalduvatele tingimustele. 2023 1. Üldosa 1.1. Hankedokumendid on kohaldatavad ainult koos riigihangete seaduse ja selle alusel kehtestatud õigusaktidega. Hankija eeldab, et huvitatud isik või pakkuja tunneb riigihangete seadust ja selle alusel kehtestatud õigusakte. 1.2. Huvitatud isik või pakkuja kannab hankemenetluses osalemisega seotud kogukulud ja -riski, kaasa arvatud vääramatu jõu (force majeure) toime võimalused. 1.3. Hankija ei ole otstarbekuse kaalutlusel hanget osadeks jaganud, sest hanke osadeks jaotamine ei ole lepingu olemusest tulenevalt võimalik. 1.4. Hankija ei arvesta olelusringi kulusid, kuivõrd antud hanke puhul on pakkujatel võimatu esitada RHS § 86 lg 2 p 2 nimetatud kulude osas näitajaid, mida oleks võimalik omavahel võrrelda 2. Hankelepingu ese 2.1. Hankelepingu eseme tehniline kirjeldus on esitatud punktis 3.1 märgitud ühes või mitmes vastavas lisas. 3. Hankedokumendid 3.1. Hankedokumendid koosnevad käesolevast hankedokumentide põhitekstist ja selle lisadest: 3.1.1 Lisa 1 kõrvaldamise alused ja kvalifitseerimistingimused (hankepass), 3.1.2 Lisa 2 vastavustingimused, 3.1.3 Lisa 3 hindamiskriteeriumid ja hinnatavad näitajad, 3.1.4 Lisa 4 raamlepingu tehniline kirjeldus; 3.1.5 Lisa 4-1 nõuded arendustele; 3.1.6 Lisa 4-2 nõuded dokumentatsioonile; 3.1.7 Lisa 4-3 arendamise tavad ja töökorraldus; 3.1.8 Lisa 4-4 nõuded testimisele; 3.1.9 Lisa 4-5 front-end nõuded; 3.1.10 Lisa 5 nõuded pakkuja arendusmeeskonnale; 3.1.11 Lisa 6 raamlepingu projekt; 3.1.12 Lisa 7 hankelepingu üldtingimused; 3.1.13 Lisa 8 hankelepingu eritingimused. 3.2. Hankedokumentide põhitekst ja selle juurde kuuluvad dokumendid on teineteist täiendavad. 3.3. Hankedokumentide lahutamatuks osaks on hankepass (alates 1.08.2019 alustatud hankes täidab ettevõtja hankepassi (ESPD v 2.0.2) registris. Vt hankepassi juhiseid https://www.fin.ee/riigihanked-riigiabi-osalused-kinnisvara/riigihangete- register/kasutusjuhendid), mille pakkujad esitavad hankijale esialgse tõendina kõrvaldamise ja kvalifitseerimistingimuste aluste kontrolliks. 3.4. RHS § 95 lg 4 p 9: Hankija võib kõrvaldada hankemenetlusest pakkuja, kes on esitanud valeandmeid käesolevas paragrahvis sätestatud või käesoleva seaduse §-des 98–101 sätestatu alusel hankija kehtestatud kvalifitseerimise tingimustele vastavuse kohta või jätnud need andmed või § 104 lõigete 7 ja 8 alusel hankija nõutud täiendavad dokumendid esitamata. Hankepassi esitamine on kohustuslik kõigile pakkujatele, kaasa arvatud ühispakkujad ning alltöövõtjad, kelle majandus-ja/või finantsnäitajatele tuginetakse. Alltöövõtjate osas tuleb hankepass esitada ka juhul, kui tema näitajatele ei tugineta, kuid keda kavatsetakse kasutada hankelepingu täitmisel. 3.5. Juhul kui pakkujal esineb RHS § 97 nimetatud olukord, esitab ta hankepassis rikkumised ning info, et kohaldatud on heastamismeetmeid. Heastamismeetmetena esitab pakkuja vastavad tõendid hankija sellekohase küsimise peale. 4. Täiendav teave ja selgitused 4.1. Küsimuse või taotluse täiendava teabe või selgituste saamiseks hanke alusdokumentide kohta esitamisel peab huvitatud isik või pakkuja arvestama, et hankijal on õigus tulenevalt riigihangete seaduse § 46 lõikest 1 vastata nimetatule 3 (kolme) tööpäeva jooksul. 4.2. Juhul, kui huvitatud isiku hanke alusdokumentidega seotud selgitustaotluse hankijale laekumisega ja pakkumuste esitamise tähtpäeva vahele ei jää vähemalt 6 (kuus) päeva, RHS § 93 lõike 2 punktis 2 ja § 94 lõike 4 punktis 2 nimetatud juhtudel 4 (nelja) päeva, ei ole hankijal kohustus selgitustaotlusele vastata. 4.3. Punktis 4.1. märgitud küsimus või taotlus esitatakse eesti keeles. 4.4. Hankijal on õigus valida hankelepingu täitmise käigus üleskerkinud vaidluste korral hankijale sobivam alusdokumentide tõlgendus, kui hankija ei ole huvitatud isikule või pakkujale edastanud vaidlusaluses küsimuses teistsugust tõlgendust punktides 4.1. ja 4.5. toodud alustel. 4.5. Huvitatud isik või pakkuja esitab punktis 4.1. märgitud küsimuse või taotluse kirjalikku taasesitamist võimaldavas vormis elektrooniliselt riigihangete registris (https://riigihanked.riik.ee/). Registri töö tõrgete korral esitatakse küsimus või taotlus hanketeates märgitud hankija kontaktisiku elektronposti aadressile. Telefoni teel esitatud küsimusi vastu ei võeta. 4.6. Hankija esitab hankemenetluse käigus koostatud dokumendid ja antava täiendava teabe ning selgitused huvitatud isikule või pakkujale elektrooniliselt läbi riigihangete registri. 5. Pakkumuse koostamine 5.1. Pakkumuse koostamisel lähtutakse muu hulgas lepingu projektis sätestatud tingimustest. 5.2. Pakkumus on konfidentsiaalne kuni nimetatud pakkumuse edukaks tunnistamise otsuse tegemiseni. Hankija ei avalikusta Lk 2/4  pakkumuste sisu ärisaladusega kaetud osas. Hankija ei ole kohustatud täpsustama pakkujalt ärisaladuse ja/või pakkuja huve kahjustada võiva tehnoloogilise lahenduse sisaldumist juhul, kui nimetatud asjaolu on jäänud pakkumuses märkimata. 6. Dokumentide vormistamise üldnõuded 6.1. Dokumentide vormistamisel lähtutakse võimalusel punktis 3.3 märgitud ühes või mitmes lisas esitatud vormidest. 6.2. Dokumendid koostatakse eesti keeles. 6.3. Dokumendid esitatakse hankijale kirjalikku taasesitamist võimaldavas vormis (see tähendab, et dokumendid peavad olema püsivat kirjalikku taasesitamist võimaldaval viisil ja sisaldama pakkumuse esitanud isiku(te) nimesid, kuid ei pea olema omakäeliselt (sh ka digitaalselt) allkirjastatud). 7. Kvalifitseerimise dokumentide vormistamise erinõuded 7.1. Esialgse tõendina pakkuja suhtes kõrvaldamise aluste puudumise ja tema kvalifitseerimise tingimustele vastavuse hindamiseks kasutatakse hankepassi. Juhul, kui pakkuja soovib tõendada enda vastavust majanduslikule ja finantsseisundile ja/või tehnilisele ja kutsealasele pädevusele esitatud nõuetele teiste ettevõtjate vahendite alusel, peab pakkuja esitama hankepassi ka selle isiku kohta, kelle vahenditele ta tugineb. Samuti tuleb esitada hankepass alltöövõtjate kohta. 7.2. Juhul kui pakkuja kasutab alltöövõtjat, võib hankija nõuda lisaks hankepassis esitatule pakkuja poolset kirjeldust millises tööde etapis ja suuruses alltöövõtjat kasutatakse. 7.3. Hankija võib nõuda alltöövõtja asendamist juhul, kui kontrolli käigus tuvastatakse alltöövõtja suhtes kõrvaldamise alus. 7.4. Enne hankelepingu sõlmimist võib hankija nõuda edukalt pakkujalt kõikide asjakohaste hankepassis esitatud kinnitustele vastavate dokumentide esitamist. Hankija võib vastavaid dokumente nõuda ka kvalifitseerimise etapis. Pakkuja võib esitada enda kvalifikatsiooni tõendamiseks lisaks hanketeates märgitud kõrvaldamise aluste puudumist tõendavatele ja kvalifikatsiooni tõendavatele dokumentidele (edaspidi koos nimetatud kvalifitseerimise dokumendid) ka muid dokumente. 7.5. Hankija võib pakkuja esitatud andmete põhjal küsida tõendeid ja kinnitusi teiselt lepingu poolelt kõigi nende lepingute kohta, millele tuginetakse kvalifikatsiooni tõendamisel. 7.6. Pakkuja võib esitada enda kvalifikatsiooni tõendamiseks lisaks hanketeates märgitud kõrvaldamise aluste puudumist tõendavatele ja kvalifikatsiooni tõendavatele dokumentidele (edaspidi koos nimetatud kvalifitseerimise dokumendid) ka muid dokumente. 7.7. Alates maist 2019 saab Euroopa hankepassi vormi täita RHRis või mõnes muus ESPD teenuses - nimekiri on kättesaadav https://ec.europa.eu/docsroom/documents/34484. Hankepassi ei ole vaja esitada juhul kui RHRis on olemas hankepassi osa ja ettevõte täidab selle RHR vormil. Hankepassi juhend https://www.fin.ee/riigihanked-riigiabi-osalused-kinnisvara/riigihangete- register/kasutusjuhendid 7.8. Hankija võib kontrollida pakkumuste vastavust riigihanke alusdokumentides esitatud tingimustele ning hinnata vastavaks tunnistatud pakkumusi käesolevas seaduses sätestatud korras enne pakkujate suhtes kõrvaldamise aluste puudumise ja kvalifikatsiooni kontrollimist (RHS § 52 lg 3). 8. Pakkumuse dokumentide vormistamise erinõuded 8.1. Pakkumuse dokumendid on järgnevad: 8.1.1 Ühise CV vorm (nõuded pakkuja arendusmeeskonnale dokumendis); 8.1.2 hankepass; 8.1.3 vastavustingimused; 8.1.4 hindamiskriteeriumid. 8.2. kui hankedokumentides on nõutud, tuleb esitada lisaks punktis 8.1 toodule muud andmed ja dokumendid. 9. Elektrooniliselt dokumentide esitamine 9.1. Kvalifitseerimise dokumendid ja punktis 8.1 märgitud pakkumuse dokumendid esitatakse elektrooniliselt riigihangete registris. 9.2. Elektrooniliselt esitatavad dokumendid vormistatakse PDF-vormingus või mõnes muus üldlevinud vormingus. 9.3. Kui esitatavate dokumentide koosseisus on dokumente, mida ei ole võimalik esitada elektrooniliselt, esitatakse need, lisaks elektroonilistele koopiatele, paberkandjal enne pakkumuste esitamise tähtpäeva vastavalt punktile 10. 9.4. Kui esitatavate dokumentide koosseisus on kolmanda osapoole poolt kirjalikult allkirjastatud dokumente, esitatakse dokument skaneeritud kujul ning originaaldokument esitatakse ainult juhul, kui hankijal on tekkinud kahtlus dokumendi osas. 9.5. Kui esitatavate dokumentide koosseisus on elektroonilisi dokumente, mida ei ole võimalik terviklikult esitada riigihangete regitsris, siis esitatakse need, lisaks riigihangete registris esitatud väljavõtetele, terviklikult CD-l või muul üldlevinud andmekandjal enne pakkumuste esitamise tähtpäeva vastavalt punktile 10. 10. Paberkandjal dokumentide esitamine 10.1. Paberkandjal dokumendid esitatakse ainult punktis 9.3 märgitud juhul. 10.2. Paberkandjal dokumendid esitatakse 1 (ühes) kinnises läbipaistmatus pakendis. 10.3. Punktis 10.2 märgitud pakendile kantakse järgmised andmed: 10.3.1 riigihanke nimetus, 10.3.2 riigihanke viitenumber, 10.3.3 kõikide pakkujate nimed ja registrikoodid, 10.3.4 märge „Mitte avada enne pakkumuste avamise tähtaega“. Lk 3/4  10.4. Paberkandjal dokumendid esitatakse posti teel või isikliku kättetoimetamisega. 10.5. Isikliku kättetoimetamisega esitatakse dokumendid pakkumuste esitamise tähtpäeval vähemalt 15 minutit enne pakkumuste avamist hankija asukohas Lubja tn 4, Tallinn, II korrusel. 11. Hankelepingu sõlmimine 11.1. Kõik raam- ja hankelepingu olulised tingimused on esitatud punktis 3.1 märgitud vastavas lisas. 11.2. Hankija jätab endale õiguse anda nõustumus raamlepingu sõlmimiseks kuni 30 (kolmekümne) päeva jooksul alates hankelepingu sõlmimise otsuse või pakkumuse edukaks tunnistamise otsuse kohta teate edastamisest. 11.3. Pakkuja peab talle allkirjastamiseks edastatud lepingu allkirjastama hiljemalt 5 tööpäeva jooksul. Antud tähtaja jooksul lepingu allkirjastamisest keeldumist on hankijal õigus käsitleda kui RHS § 119 nimetatud eduka pakkumuse esitanud pakkuja poolset lepingu sõlmimisest keeldumist ja pakkumuse tagasi võtmist. 12. Hankemenetluse kehtetuks tunnistamine 12.1. Hankija jätab endale õiguse tunnistada hankemenetlus kehtetuks, kui: 12.1.1 hankemenetluse toimumise ajal on hankijale saanud teatavaks uued asjaolud, mis välistavad või muudavad ebaotstarbekaks hankemenetluse lõpuleviimise hanke alusdokumentides sätestatud tingimustel; 12.1.2 välisrahastaja ei anna nõustumust eduka pakkujaga lepingu sõlmimiseks; 12.1.3 on toimunud sündmus, mida saab lugeda vääramatuks jõuks (force majeure). Vääramatu jõud on asjaolu, mida hankija ei saa mõjutada ja mõistlikkuse põhimõttest ei saa temalt oodata, et ta hankemenetluse ajal selle asjaoluga arvestaks või seda väldiks või takistava asjaolu või selle tagajärje ületaks. /allkirjastatud digitaalselt/ Rivo Reitmann Direktor Lk 4/4  Riigihanke „Täitmisregistri hooldus- ja arendustööd“ (viitenumber 266570) hankedokumentide juurde Nõuded pakkuja arendusmeeskonnale 1. Üldised nõuded meeskonnale: 1.1. Pakkuja peab olema võimeline komplekteerima raamlepingu alusel sõlmitavate hankelepingute täitmiseks nõuetele vastava meeskonna. 1.2. Pakkuja peab esitama vähemalt kolmeliikmelise meeskonna. 1.3. Meeskond peab koosnema projektijuhist, analüütikust, süsteemiarhitektist, programmeerijast ja testijast. Meeskonnaliikmete rollid võivad kattuda. 1.4. Meeskonnaliikmete esitamisega kinnitab pakkuja, et esitatud meeskonnaliikmed hakkavad riigihanke tulemusel sõlmitud lepingu alusel töid teostama. Pakkumuses esitatud meeskonnaliikme saab hankija eelneval nõusolekul vahetada üksnes uue meeskonnaliikme vastu, kes vastab vormil toodud tingimustele. 2. Meeskonnaliikmete ühise CV vorm 2.1. Rollitäitjate kompetentsinõuetele vastavuse tõendamiseks ja kontrollimiseks vajalik teave esitatakse lisatud ühisel CV-vormil, täites ära kõik nõutud väljad. 2.2. CV-s peab nähtuma kõikide hankija seatud nõuete täitmine. CV peab olema esitatud eesti keeles. Meeskond tunnistatakse vastavaks, kui kõik CV vormil esitatud nõuded, kompetentsid, platvormid ja töövahendid on meeskonnaliikmete poolt kaetud. 2.3. Hankija võib kõikide meeskonnaliikmete kohta esitatud andmeid igal ajal kontrollida. 2.4. Töökogemus eeldab, et tegemist peab olema 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öökogemuse omandamisele töösuhtes. 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. 2.5. Töökogemuse ajaperiood ja andmed tuleb esitada kalendrikuu täpsusega, näitamaks ära nõutud kogemusele vastav periood (nt osalemine projektis X kestusega 12.2020 – 03.2022). 2.6. Hankija küsib meeskonnaliikme sünniaega, et tuvastada hiljem isikusamasus ning välistamaks nimekaimude segi ajamist. PROJEKTIJUHT Ees- ja perenimi, ning sünniaeg: Kodakondsus: Nr Nõue Projektidele viitamisel tuleb märkida projekti nimi, projekti periood kalendrikuudes, projekti tellinud asutus ja tellija kontaktisik, roll projektis arvestades, et hankijal on õigus kontrollida esitatud andmeid viidatud kontaktisiku vahendusel. Töökogemuse puhul tuleb märkida tööandja nimi, töökogemuse omandamise periood, ametinimetud ja tööülesannete lühikirjeldus. Väljade täitmine on kohustuslik. 1 Omab vähemalt 36-kuulist Lisada tööandja nimi, töökogemuse kestvuse periood, ametinimetus, tööülesannete lühikirjeldus töökogemust tarkvara arendusprojektides projektijuhina 2 Omab vähemalt 24-kuulist Lisada projekti nimi, projekti periood kalendrikuudes, projekti tellinud asutus ja tellija kontaktisik ning roll projektis. kogemust üle 100 000 EUR (ilma käibemaksuta) maksumusega infosüsteemi väljatöötamiseks ja kasutuselevõtmiseks sõlmitud projektis projektijuhina 3 Valdab eesti keelt heal tasemel Märkida keeleoskus (kõnes, kirjas) ANALÜÜTIK Ees- ja perenimi ning sünniaeg: Kodakondsus: Nr Nõue Projektidele viitamisel tuleb märkida projekti nimi, projekti periood kalendrikuudes, projekti tellinud asutus ja tellija kontaktisik, roll projektis arvestades, et hankijal on õigus kontrollida esitatud andmeid viidatud kontaktisiku vahendusel. Töökogemuse puhul tuleb märkida tööandja nimi, töökogemuse omandamise periood, ametinimetud ja tööülesannete lühikirjeldus. Väljade täitmine on kohustuslik 1 Omab vähemalt 24-kuulist Lisada tööandja nimi, töökogemuse kestvuse periood, ametinimetus, tööülesannete lühikirjeldus töökogemust tarkvara  arendusprojektides analüütikuna 2 Omab vähemalt 24-kuulist Lisada projekti nimi, projekti periood kalendrikuudes, projekti tellinud asutus ja tellija kontaktisik ning roll projektis. kogemust üle 100 000 EUR (ilma käibemaksuta) maksumusega infosüsteemi väljatöötamiseks ja kasutuselevõtmiseks sõlmitud projektis analüütikuna 3 Valdab eesti keelt heal tasemel Märkida keeleoskus (kõnes, kirjas) SÜSTEEMIARHITEKT Ees- ja perenimi ning sünniaeg: Kodakondsus: Nr Nõue Projektidele viitamisel tuleb märkida projekti nimi, projekti periood kalendrikuudes, projekti tellinud asutus ja tellija kontaktisik, roll projektis arvestades, et hankijal on õigus kontrollida esitatud andmeid viidatud kontaktisiku vahendusel. Töökogemuse puhul tuleb märkida tööandja nimi, töökogemuse omandamise periood, ametinimetud ja tööülesannete lühikirjeldus. Väljade täitmine on kohustuslik 1 Omab vähemalt 24-kuulist Lisada tööandja nimi, töökogemuse kestvuse periood, ametinimetus, tööülesannete lühikirjeldus töökogemust tarkvara arendusprojektides arhitektina 2 Omab vähemalt 24-kuulist Lisada projekti nimi, projekti periood kalendrikuudes, projekti tellinud asutus ja tellija kontaktisik ning roll projektis. kogemust üle 100 000 EUR (ilma käibemaksuta) maksumusega infosüsteemi väljatöötamiseks ja kasutuselevõtmiseks sõlmitud projektis süsteemiarhitektina 3 Tunneb Javat, javaskripti, C#-i. Tuua andmed välja projektidele viidates. Täitmisregister on realiseeritud Javas ning javaskriptis,  liidestuste ja kõrvalsüsteemide puhul tuleb osata C#-i; 4 Valdab eesti keelt heal tasemel Märkida keeleoskus (kõnes, kirjas) PROGRAMMEERIJA Ees- ja perenimi ning sünniaeg: Kodakondsus: Nr Nõue Projektidele viitamisel tuleb märkida projekti nimi, projekti periood kalendrikuudes, projekti tellinud asutus ja tellija kontaktisik, roll projektis arvestades, et hankijal on õigus kontrollida esitatud andmeid viidatud kontaktisiku vahendusel. Töökogemuse puhul tuleb märkida tööandja nimi, töökogemuse omandamise periood, ametinimetud ja tööülesannete lühikirjeldus. Väljade täitmine on kohustuslik 1 Omab vähemalt 24-kuulist Lisada tööandja nimi, töökogemuse kestvuse periood, ametinimetus, tööülesannete lühikirjeldus töökogemust tarkvara arendusprojektides programmeerijana 2 Tunneb Javat, javaskripti, C#-i. Tuua andmed välja projektidele viidates. Lisada projekti nimi, projekti periood kalendrikuudes, projekti tellinud asutus Täitmisregister on realiseeritud ja tellija kontaktisik ning roll projektis. Javas ning javaskriptis, liidestuste ja kõrvalsüsteemide puhul tuleb osata C#-i; 3 Valdab eesti keelt Märkida keeleoskus (kõnes, kirjas) TESTIJA Ees- ja perenimi ning sünniaeg: Kodakondsus: Nr Nõue Projektidele viitamisel tuleb märkida projekti nimi, projekti periood kalendrikuudes, projekti tellinud asutus ja tellija kontaktisik, roll projektis arvestades, et hankijal on õigus kontrollida esitatud andmeid viidatud kontaktisiku vahendusel. Töökogemuse puhul tuleb märkida tööandja nimi, töökogemuse omandamise periood, ametinimetud ja tööülesannete lühikirjeldus. Väljade täitmine on kohustuslik 1 Omab vähemalt 12-kuulist Lisada tööandja nimi, töökogemuse kestvuse periood, ametinimetus, tööülesannete lühikirjeldus töökogemust tarkvara arendusprojektides testijana 2 Valdab eesti keelt Märkida keeleoskus (kõnes, kirjas)  DIREKTOR KÄSKKIRI 24.07.2023. a nr 58 Tallinn Alusdokumentide kinnitamine riigihankes „Täitmisregistri hooldus- ja arendustööd“ (266570) Justiitsministri 18.04.2007. a määruse nr 20 „Registrite ja Infosüsteemide Keskuse põhimäärus“ § 11 lõike 1 punkti 9 alusel ning kooskõlas direktori 29.06.2023 käskkirjaga nr 52 kinnitan lisad. /allkirjastatud digitaalselt/ Rivo Reitmann Lisad: 1. hanketeade „Täitmisregistri hooldus- ja arendustööd“ (266570) (vormistatud digitaalselt), 2. hankedokumendid „Täitmisregistri hooldus- ja arendustööd“ (266570) koos lisadega (vormistatud digitaalselt).  Lisa 6 Riigihanke „Täitmisregistri hooldus- ja arendustööd“ (viitenumber 266570) hankedokumentide juurde RAAMLEPING NR .. Raamlepingu sõlmimise Raamleping sõlmitakse riigihanke „Täitmisregistri hooldus- ja arendustööd“ alus (viitenumber 266570) (edaspidi nimetatud riigihange) tulemusena. Pooled Raamleping sõlmitakse Registrite ja Infosüsteemide Keskuse (edaspidi tellija) ning riigihankes edukaks osutunud pakkuja (edaspidi täitja) vahel, keda nimetatakse edaspidi eraldi pool või koos pooled. Raamlepingu Raamlepingu eesmärgiks on: eesmärk - kehtestada raamlepingu kehtivusaja vältel selle alusel sõlmitavaid hankelepinguid reguleerivad tingimused; - määratleda pooltevahelised õigused, kohustused ning vastutus hankelepingute sõlmimisel; - kehtestada ühtsed tingimused hankelepingute tõlgendamiseks. Tellija Registrite ja Infosüsteemide Keskus Registrikood 70000310 Aadress Lubja 4, Tallinn, 19081 Tellija esindaja Rivo Reitmann Esinduse alus Põhimäärus Täitja Registrikood Aadress Täitja esindaja Esinduse alus 1. Raamlepingu ese ja dokumendid 1.1. Raamlepingu esemeks on täitmisregistri hooldus- ja arendustööde teostamine vastavalt hankedokumentides toodud tingimustele. 1.2. Raamleping koosneb lepingu põhiosast ja selle lisadest. Raamlepinguga samaaegselt allkirjastatavad lisad on: 1.2.1. Lisa 1 – Raamlepingu tehniline kirjeldus; 1.2.2. Lisa 2 – Hankelepingu üldtingimused; 1.2.3. Lisa 3 – Hankelepingu eritingimused; 1.2.4. Lisa 4 – Pakkumus; 1.2.5. Lisa 5 – Poolte volitatud esindajad ja kontaktandmed. 1.3. Raamlepingu lahutamatuks osaks on ka riigihanke dokumentatsioon. 2. Kinnitused 2.1. Pooled kinnitavad, et: 2.1.1. raamlepingu sõlmimisega ei ole nad rikkunud ühegi enda suhetes kehtiva seaduse, põhikirja või muu normatiivakti sätet ega varem sõlmitud lepingu või kokkuleppega endale võetud kohustust; 2.1.2. nad on oma majandustegevuses iseseisvad ja kumbki pool ei vastuta teise poole poolt endale kolmandate isikute ees raamlepingu või hankelepinguga võetud kohustuste täitmise eest; 2.1.3. neil on seaduses ettenähtud piisav õigus- ja teovõime raamlepingu ja hankelepingu sõlmimiseks ning nendest tulenevate kohustuste täitmiseks ja õiguste realiseerimiseks; 2.1.4. nende poolt raamlepingu allkirjastanud isikutele on antud piisavad volitused selle sõlmimiseks kooskõlas seaduste, põhikirjade või muude normatiivaktidega. 2.2. Poolte esindajad kinnitavad, et neil on kõik õigused ja volitused sõlmida raamleping esindatava nimel ning nad ei tea ühtegi takistust raamlepinguga võetud kohustuste täitmiseks. 3. Raam- ja hankelepingute tõlgendamine 3.1. Pooled järgivad raamlepingu ja hankelepingu (antud punkti kontekstis ühiselt nimetatud ka kui leping) täitmisel ja tõlgendamisel järgmisi põhimõtteid: 3.1.1.lepingu jaotiste pealkirjad ei määra nende mõistete ega sätete tähendusi; 3.1.2.lepingus, kui kontekst seda nõuab, võivad ainsuses olevad sõnad tähendada mitmust ja vastupidi. 3.1.3.pooled käituvad teineteise suhtes heas usus ja mõistlikkuse põhimõttest lähtuvalt; 3.1.4.pooled peavad mõistlikuks seda, mida samas olukorras heas usus tegutsevad isikud loeksid mõistlikuks; 3.1.5.mõistlikkuse hindamisel arvestatakse lepingulise suhte olemust ja lepingu eesmärki ning vastava tegevusala praktikat, samuti muid asjaolusid; 3.1.6.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; 3.1.7.lepingu tingimust tuleb tõlgendada koos lepingu teiste tingimustega, andes igaühele neist tähenduse, mis lähtub lepingu kui terviku tähendusest ning poolte omavahelisest praktikast; 3.1.8.lepingu tingimuste tõlgendamisel eelistatakse tõlgendust, mis muudab lepingu tingimuse seaduslikuks või kehtivaks; 3.1.9.kui esineb vastuolu lepingu ja selle lisa vahel, siis lähtutakse tõlgendamisel lepingu lisast; 3.1.10. vastuolu korral lepingu ja / või selle lisade erinevate sätete vahel tühistab hilisem säte varasema ning üld- ja erisätte vastuolu korral kohaldatakse erisätet; 3.1.11. pooled juhinduvad omavaheliste suhete reguleerimisel lepingust ning lepinguga reguleerimata küsimustes Eesti Vabariigis kehtivatest õigusaktidest; 3.1.12. kui mõni lepingu säte osutub vastuolus olevaks Eesti Vabariigi seadustega või muude kehtivate õigusaktidega, ei mõjuta see lepingu ülejäänud sätete kehtivust; 3.1.13. lepingu tõlgendamisel lähtutakse poolte ühisest tegelikust tahtest, isegi kui see erineb sõnade tavapärasest tähendusest; 3.1.14. 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; 3.1.15. ühegi poole mistahes viivitus, hoolimatus või keeldumine teist poolt lepingutingimuste täitma sundimisel või muude nõuete esitamisel ei kujuta endast selle poole mistahes lepingujärgsetest õigustest loobumist või nende tühistamist. 6. Raam- ja hankelepingute ulatus ja maht 6.1. Raamleping kehtib 24 kuud alates selle sõlmimisest või kuni raamlepingu eeldatava maksumuse täitmiseni. 6.2. Raamlepingu eeldatav maksumus on 200 000 eurot (km-ta). 6.3. Raamlepingu alusel sõlmitud hankelepingu(te) kehtivus ei ole piiratud raamlepingu kehtivuse lõpptähtpäevaga. 7. Raamlepingu täitmine 7.1. Hooldustööde tellimiseks esitab Tellija kontaktisik Täitja kontaktisikule kirjalikku taasesitamist võimaldavas vormis (e-posti teel) tellimuse, mis sisaldab tellimuse täitmiseks vajalikke andmeid. Pakkuja esitab tööde ajakulu hinnangu ning asub tellimust täitma pärast tellija poolset aktsepti. 7.2. Arendustööde tellimiseks esitab Tellija kontaktisik Täitja kontaktisikule kirjalikku taasesitamist võimaldavas vormis (e-posti teel) tellimuse esialgse raamlepingu sõlmimiseks esitatud pakkumuse täpsustamiseks. Tellimus sisaldab pakkumuse täpsustamiseks vajaminevaid tingimusi: 7.2.1. kõiki sisulisi andmeid, mis on vajalikud tellimuse täitmiseks (tehniline kirjeldus; tööde teostamise soovitav ajaperiood; eeldatav maksumus; juhul kui on tegemist välisrahastusega, siis välja tuua nimetatu allikas. Kui tellimuses nõutud, esitab Täitja lähteülesandes kirjeldatud funktsionaalsuse/tööde detailseks analüüsiks, realiseerimiseks, testimiseks ning dokumenteerimiseks kuluvat aega arendustundides; infosüsteemiga seotud infosüsteemide tööks vajalike tarkvarakomponentide täienduste kirjelduse; ajahinnangu kalendripäevades hinnapakkumuse aktsepteerimisest Tellijale tööde üleandmiseni); 7.2.2. pakkumuse täpsustuse esitamise tähtaega; 7.2.3. pakkumuse täpsustuse jõusoleku minimaalset tähtaega; 7.2.4. pakkumuse täpsustuse esitamise kontaktaadressi. 7.3. Täitja on kohustatud esitama omapoolse pakkumuse täpsustuse vastavalt punktis 7.1 nimetatud tellimuse saamisel lähtudes vastavas tellimuses märgitud andmetest või esitama põhjenduse tellimuse täitmise võimatuse kohta. 7.4. Pakkumuse täpsustus aktsepteeritakse tellija poolt kui see vastab tellimuses kehtestatud tingimustele. Tellimuse täitmist alustatakse, kui tellija on andnud aktsepti kirjalikku taasesitamist võimaldavas vormis. 7.5. Pakkumise täpsustamiseks kulunud aega ei tasustata. 7.6. Tellijal on õigus jätta kirjalik hankeleping sõlmimata kuni 19 999,99 euro (ilma käibemaksuta) suuruste tehingute korral. 7.7. Kirjaliku hankelepingu sõlmimata jätmisel loetakse hankelepinguks tellimus, aktsepteeritud pakkumuse täpsustus ning hankelepingu üldtingimused kogumina. Hankelepingu lahutamatuteks osadeks on riigihanke alusdokumendid, raamleping koos lisadega, tööde üleandmisevastuvõtmise aktid, pooltevahelised kirjalikud teated ning lepingu muudatused ja lisad. 7.8. Kirjalik hankeleping sõlmitakse alati 20 000 euro (ilma käibemaksuta) või suuremate tehingute korral. Kirjalik hankeleping koosneb hankelepingu eritingimuste projektis toodud lisadest ja hankelepingu lahutamatuks osaks nimetatud dokumentidest. 8. Muutumatud tingimused 8.1. Raamlepingu kehtivuse ajal kehtivad muutumatult raamlepingus ja hankelepingus sätestatud tingimused. Muutumatult kehtivad ka raamlepingu sõlmimiseks esitatud pakkumuses märgitud hankelepingu eseme ühikumaksumused. 8.2. Hankelepingu tingimused võivad erineda raamlepingu tingimustest ainult juhul, kui hankelepingu tingimused on tellija jaoks raamlepingus sätestatud tingimustest soodsamad. 9. Raamlepingu rikkumine ja vastutus 9.1. Pooled vastutavad oma raamlepingust tulenevate kohustuste rikkumise eest iseseisvalt, välja arvatud, kui rikkumine on vabandatav. Eeldatakse, et rikkumine ei ole vabandatav. 9.2. Kohustuse rikkumine on vabandatav, kui Pool rikkus kohustust vääramatu jõu tõttu. 9.3. Täitja vastutab kõikide isikute eest, keda ta kasutab oma lepingujärgsete kohustuste täitmisel. 10. Raamlepingu ülesütlemine 10.1. Raamlepingu korralise ülesütlemise õigus on ainult Registrite ja Infosüsteemide Keskusel. 10.2. Korralise ülesütlemise etteteatamistähtaeg on 90 (üheksakümmend) kalendripäeva. 10.3. Registrite ja Infosüsteemide Keskusel on õigus raamleping erakorraliselt üles öelda ilma etteteatamistähtajata järgmistel juhtudel: 10.3.1. raamlepingu alusel täitjaga sõlmitud hankeleping on erakorraliselt üles öeldud; 10.3.2. täitja on oma lepingujärgsed kohustused üle andnud kolmandale isikule. 10.4. Raamlepingu ülesütlemine ei mõjuta sõlmitud hankelepingute kehtivust. Täitjal ei teki tellija vastu raamlepingu korralisest ülesütlemisest tekkinud kahju hüvitamise nõude esitamise õigust, nt saamata jäänud tulu. 11. Kolmandad isikud ja nõuete loovutamine 11.1. Pooled ei või oma lepingujärgseid kohustusi üle anda kolmandale isikule. 11.2. Pooled võivad loovutada lepingust tulenevaid rahalisi nõudeid kolmandatele isikutele. Pooled on kohustatud teineteist nõude loovutamisest viivitamatult informeerima. 11.3. Registrite ja Infosüsteemide Keskusel on õigus raamlepingu alusel sõlmitud hankelepingu alusel tasumisele kuuluv arve edastada maksmiseks raamlepingu pooleks mitte olevale tellijale juhul, kui vastavasisuline volitus on antud nendevahelises koostöökokkuleppes või nimetatu alusel. 12. Lõppsätted 12.1. Raamlepingu tingimused on avalikud. 12.2. Raamlepingu muudatused vormistatakse lisana. Raamlepingu muutmine ei mõjuta sõlmitud hankelepingute tingimusi. 12.3. Raam- ja hankelepingute täitmise keel on eesti keel. 12.4. Raamlepinguga seotud vaidlused lahendatakse läbirääkimiste teel. Läbirääkimiste tulemusel kokkuleppe mittesaavutamisel lahendatakse vaidlus Harju Maakohtus. 12.5. Leping allkirjastatakse digitaalselt. Tellija Täitja /digitaalselt allkirjastatud/ /digitaalselt allkirjastatud/  Raamleping nr .. Lisa nr 5 POOLTE VOLITATUD ESINDAJAD JA KONTAKTANDMED Poolte volitatud esindajateks raamlepingu täitmisel on: Volitatud Volitatud Volitatud esindaja esindaja Pool Volitatud esindaja email esindaja nimi ametikoht kontakttelefon Tellija Täitja Täitja kontaktandmed tellimuste esitamiseks: Täitja Kontaktisik, e-mail Hankelepinguid sõlmitakse tellija poolt raamlepingus sätestatud korras.  Lisa 8 Riigihanke „Täitmisregistri hooldus- ja arendustööd“ (viitenumber 266570) hankedokumentide juurde Hankeleping nr ... Hankelepingu eritingimused Tallinnas Kaldkirjas tekst lisatakse juhul, kui on leping seotud Euroopa Liidu vahenditest rahastatava projekti ja/või programmiga või kui riigihanget rahastatakse struktuuritoetustest. (punktiiri asemele viide konkreetsele rahastusallikale, EK raha puhul rahastuslepingu andmed ning SF projekti puhul kirja, kas tegemist avatud vooru või investeeringute kavaga ning kindlasti kirja ka projekti täpne nimi). Võttes arvesse ………. projekti „………………….“, mille kohaselt on vastava projekti toetuste saaja ……….: Registrite ja Infosüsteemide Keskus, (registrikoodiga 70000310) asukohaga Lubja 4, 19081 Tallinn, mida esindab põhimääruse alusel direktor Rivo Reitmann, edaspidi Tellija, ja ………………. (registrikoodiga…………) asukohaga …………….., ……., mida esindab …………alusel ………, edaspidi Täitja, keda nimetatakse edaspidi pool või koos pooled, sõlmisid käesoleva arenduslepingu (edaspidi nimetatud Leping) alljärgnevas: 1. Lepingu sõlmimise alus ja ese 1.1. Vastavalt riigihanke „Täitmisregistri hooldus- ja arendustööd“ (viitenumber 266570) tulemusel sõlmitud raamlepingu nr ... alusel esitatud pakkumuse täpsustusele teostab täitja Lepingu lisas 3 mainitud tööd ja täidab kõik muud Lepingust tulenevad kohustused (edaspidi ka Töö). 1.2. Pooled kinnitavad, et teevad kõik enesest oleneva, et täita lepingu eesmärgid käesolevas lepingus, seonduvates õigusaktides ning struktuuritoetuste rakendamise dokumentides sh. struktuuritoetuse rakendamise käsiraamatus ja juhtrühma olemasolu korral juhtrühma otsustes sätestatud tingimustel ja mahus. 2. Hind ja maksetingimused 2.1. Lepingu hind on …………. eurot (netosumma), arvestusega, et hooldus- ja arendustööde tunnihind on ..... eurot (netosumma). 2.2. Leping on …….. euro ulatuses rahastatud välisvahenditest ja …….. euro ulatuses riigieelarvest. 2.4. Tellija tasub lepingu alusel teostatud tööde eest lepingu üldtingimustes sätestatud korras. 3. Lepingu jõustumine ja Töö teostamise tähtaeg 3.1 Leping jõustub allkirjastamise hetkest ja kehtib kuni lepingujärgsete kohustuste nõuetekohase täitmiseni. 3.2 Töö teostamise tähtaeg on ……… arvates Lepingu jõustumise ajahetkest. /Märgitakse etapiviisilise üleandmise korral viimase etapi üleandmise tähtaeg/. 4. Lepingu dokumendid 4.1 Lepingu dokumendid koosnevad Lepingu tekstist, Lepingu lisadest, mis on lisatud Lepingu allkirjastamisel ja lisadest, millistes võidakse kokku leppida pärast Lepingu allkirjastamist. Lepingu allkirjastamisel on Lepingu lisad järgmised: 4.1.1 Hankelepingu üldtingimused Lisa nr 1; 4.1.2 Personal ja kontaktandmed Lisa nr 2; 4.1.3 Pakkumuse täpsustamise ettepanek Lisa nr 3; 4.1.4 Pakkumuse täpsustus Lisa nr 4; 4.1.5 Maksegraafik Lisa nr 5. /antud lisa eksisteerib juhul kui Töö eest tasumine toimub mitmes osas/. 4.2 Lepingu lahutamatuteks osadeks on riigihanke alusdokumendid, sõlmitud raamleping koos lisadega, tööde üleandmise-vastuvõtmise aktid, pooltevahelised kirjalikud teated ning lepingu muudatused ja lisad. Käesoleva Lepingu allakirjutamisega tõendavad pooled, et on tutvunud ja on nõus Lepinguga ja selle lisadega ning mõistavad täielikult enesele võetavate kohustuste sisu ning nende tagajärgi. Tellija: Täitja: / allkirjastatud digitaalselt / / allkirjastatud digitaalselt / Rivo Reitmann Direktor Registrite ja Infosüsteemide Keskus  Hankeleping nr. ………… Lisa nr 2 PERSONAL JA KONTAKTANDMED 1. Tellija esindaja ja kontaktisikud 1.1. Tellija esindajaks tööde vastuvõtmise aktide, teadete jms lepinguga seonduvate dokumentide allkirjastamisel on Registrite ja Infosüsteemide Keskuse …… osakonna juhataja ……………. (tel ………….; e-post …………….). 1.2. Tellija kontaktisikuks tööde teostamise juhendamisel ning Täitjale vajaliku lähteinformatsiooni ja tööülesannete täpsustamisel jmt. on Registrite ja Infosüsteemide Keskuse ………… osakonna …………… (tel …; e-post …………………). 2. Täitja esindaja ja kontaktisikud 2.1 Täitja esindajaks on ………… (tel …………..; e-post………….). 2.2 Täitja kontaktisikuks on ………… (tel …………..; e-post………….). 3. Personali nimekiri 3.1. Tellija personal Nr. Nimi Ametinimetus Kontaktandmed 3.2. Täitja personal Nr. Nimi Ametinimetus Kontaktandmed 4. Kontaktandmed 4.1. Tellija kontaktandmed on: 4.2. Täitja kontaktandmed on: Registrite ja Infosüsteemide Keskus ……………. Reg. nr. 70000310 Registrikood Lubja tn 4 …………… 19081 TALLINN …………… Telefon: 663 6300 Telefon: …………….  Lisa 7 Riigihanke „Täitmisregistri hooldus- ja arendustööd“ (viitenumber 266570) hankedokumentide juurde HANKELEPINGU ÜLDTINGIMUSED 1. Üldosa 1.1 Üldtingimused on riigihanke „Täitmisregistri hooldus- ja arendustööd“ (viitenumber 266570) alusel sõlmitud raamlepingu lisaks ning raamlepingu alt teostatavate tehingute lahutamatuks osaks. 1.2 Pooled võivad hankelepingu eritingimustes kokku leppida üldtingimustes käsitlemata või üldtingimusi täpsustavates küsimustes, samuti erisusi üldtingimustest, kuid nende puudumisel kohaldatakse üldtingimusi. Üldtingimuste ja eritingimustes sisalduvate sätete vastuolu korral, loetakse ülimuslikuks eritingimustes sätestatu. 2. Definitsioonid Järgnevad definitsioonid laienevad nii lepingule kui ka selle osaks olevatele dokumentidele. 2.1 Tarkvara Tarkvara tähendab põhiliselt arvutiprogramme, telekommunikatsioone, andmebaasi-, rakendus- ja muud tarkvara objektikoodis, lähtekoodis või nende mistahes muid vorme või adaptsioone koos sellega seonduva dokumentatsiooniga. Spetsiaalselt Tellijale tema funktsioonide täitmiseks loodud tarkvara käsitletakse lepingu raames spetsiaaltarkvarana. 2.2 Seadmed Seadmed tähendavad lepingus kirjeldatud tooteid, hõlmates nendega otseselt seotud tarkvara, mis on vajalik seadmete funktsioneerimiseks. 2.3 Telekommunikatsioonid Telekommunikatsioonid tähendavad sisemise ja välise telekommunikatsiooni seadmeid, tarkvara ja teenuseid ning vajalikke vahendeid, teenuseid ja protseduure. 2.4 Asukoht Asukoht tähendab kohta või kohti, välja arvatud Täitja asukoht, kuhu seadmeid, telekommunikatsioone või tarkvara tarnitakse või installeeritakse või teenuseid osutatakse (nt Tellija test- arendus-ja toodangukeskkond). 2.5 Puudus ja viga Puuduse või veaga on tegemist juhul, kui seade, telekommunikatsioon või tarkvara ei täida lepingus sätestatud funktsioone, annab valesid tulemusi, kui tema nõuetekohane toimimine katkeb või on (muul viisil) häiritud, nii et seadme, telekommunikatsiooni või tarkvara otstarbekohane kasutamine on takistatud või oluliselt häiritud. Vigu liigitatakse järgnevalt: 2.5.1 Kriitiline/Blocker – viga, mille tõttu süsteemi tervikuna või mistahes süsteemi osa ei ole võimalik kasutada ja/või see piirab sama süsteemi mistahes teise osa kasutamist. 2.5.2 Kõrge – viga, mille tõttu pole võimalik mingit süsteemi osa kasutada, kuid see ei sega mõne teist sama süsteemi osa kasutamast. 2.5.3 Keskmine – viga, mille tõttu süsteemi või selle süsteemi mõnda osa on võimalik kasutada piirangutega ja/või kasutajad peavad tegema mitte ettenähtud tegevusi eesmärgi saavutamiseks (nt. funktsionaalsus lubab vigadega toiminguid lõpetada).  2.5.4 Madal – viga, mille tõttu süsteemis esineb kõrvalekaldeid ettenähtust, kuid üldprotsessi need ei häiri või häirivad vähesel määral. 2.5.5 Väheoluline - viga, mille tõttu otseseid kõrvalekaldeid ei teki kuid vajavad muutmist/parandamist. 2.6 Hooldustööd Hooldus tähendab töid, mis tagavad seadmete, telekommunikatsioonide ja tarkvara (kaasa arvatud nende juurde kuuluvate andmete ja andmebaaside) toimivuse (korrasoleku, terviklikkuse, jõudluse jms). Hooldus sisaldab kaugtuge, vigade ennetamist ja parandamist, uute redaktsioonide ja versioonide ning nendega seotud dokumentatsiooni üleandmist. Samuti hõlmab hooldus lepingus sätestatud tingimustel seadmete, telekommunikatsioonide ja tarkvara kohandamist Tellija vajadustele, eeldusel, et see ei nõua olulist ümberprogrammeerimist ega uue toote loomist. 2.7 Arendustööd Arendustööd tähendavad Täitmisregistri infosüsteemi funktsionaalsuse parandamise ja täiendamise ning teenuse arendamisega seonduvaid töid. Arendustööd sisaldavad endas tehnilist konsultatsiooni, süsteemi- ja detailanalüüsi läbiviimist, programmeerimistöid, testimist, dokumentatsiooni koostamist ja vajadusel koolitusi. 2.8 Toodangukeskkond Reaalseks andmevahetuseks mõeldud keskkond, mis ei ole test- või arenduskeskkond. 3. Hind 3.1 Lepingu hind sisaldab kõiki tolli- ja muid makse, kaasa arvatud käibemaks. Lepingu eritingimustes märgitakse Lepingu hind netosummana (käibemaksuta). 3.2 Lepingu hind väljendatakse eurodes. 3.3 Lepingu hind on Täitja ainuke tasu seoses lepinguga ja Täitja ise ega tema töötajad ei võta päevarahasid, kaudset tasu ega muud lepingus toodud kohustustega seotud tasu. Samuti ei ole Täitjal ega tema töötajal õigust täiendavale autori- või muule sarnasele tasule seoses lepingu täitmisel kasutatud patenteeritud või muul viisil kaitstud eseme või protsessiga. 4. Maksmine 4.1 Täitja esitab Tellijale arve masinloetaval kujul e-arvena. 4.2 Hooldustööde eest tasutakse kvartaalselt kvartali lõpus Täitja poolt esitatud arve alusel. 4.3 Arendustööde arve esitatakse pärast üleandmise-vastuvõtmise akti Tellija poolset allkirjastamist. 4.4 Arve peab sisaldama vähemalt alljärgnevaid andmeid: 4.4.1 info arve esitaja kohta; 4.4.2 info maksja kohta; 4.4.3 viide Lepingule; 4.4.4 käibemaksukohustuslase number; 4.4.5 vastuvõetud Töö nimetus ja kirjeldus; 4.4.6 käibemaks; 4.4.7 kogusumma; 4.5 Tellija tasub Lepingu hinna Täitja poolt esitatud arvel märgitud kuupäevaks. Maksetähtaeg ei tohi olla lühem kui 30 kalendripäeva, va juhul kui hankija on nimetatut pakkumuse esitamise ettepanekus ette näinud. 4.6 Ettemakseid Tellija ei teosta. 4.7 Lõpparve maksmine eeldab Täitja kõigi Lepingu järgsete kohustuste täitmist ning Tellija poolt vastuvõtmist. 4.8 Tellijal on õigus Lepingu rikkumise korral arvestatud leppetrahvid ja kahju hüvitised maha arvata Lepingu alusel Täitjale tasumisele kuuluvatest summadest. 4.9 Tellija poolt makstud mistahes summa, mis ületab Täitjale Lepingus ettenähtu, maksab Täitja Tellijale tagasi 30 kalendripäeva jooksul pärast vastava teate saamist. 4.10 Lepingujärgse hinna tasumisega viivitamisel on Täitjal õigus nõuda viivist iga maksmisega viivitatud kalendripäeva eest 0,15 (null koma viisteist) % maksmata summast päevas. 5. Informatsioon ja aruanded 5.1 Täitja loetakse asukohaga ja lepingu tingimustega tutvunuks. Eelkõige ei rahuldata Täitja nõuet lisamakseteks või ajapikenduseks, kui ta oleks saanud vajaliku informatsiooni hankida visiidiga asukohta, konsulteerides Tellijaga või muul sobilikul viisil. 5.2 Tellija varustab Täitjat tema käsutuses oleva mistahes informatsiooni ja dokumentatsiooniga, mis võib olla lepingu täitmisel oluline, niipea kui võimalik, kuid mitte hiljem kui 2 tööpäeva jooksul vastava nõude saamisest. 5.3 Tellija abistab Täitjat niipalju kui võimalik lepingusse puutuva informatsiooni saamisel, mida Täitja mõistlikkuse piirides lepingu täitmiseks nõuab. 5.4 Täitja annab Tellijale niipea kui võimalik, kuid mitte hiljem kui 2 tööpäeva jooksul vastava nõude saamisest, lepingu täitmist (sealhulgas seadmeid, telekommunikatsioone, tarkvara, projekti kulgemist ja teenuseid) puudutavat informatsiooni. 6. Teated ja kirjavahetus 6.1 Pooltevaheline suhtlus toimub selleks otstarbeks määratud poolte kontaktandmetel ja aadressidel. Pooled on kohustatud kontaktandmete ja aadresside muutusest teineteist teavitama viivitamatult, aga mitte hiljem kui 2 tööpäeva jooksul. 6.2 Kui teisele poolele edastatav teade eeldab vastust, tuleb vastata viivitamatult, kuid mitte hiljem kui 2 tööpäeva jooksul. 6.3 Pooltevahelised Lepinguga seotud teated peavad olema kirjalikku taasesitamist võimaldavas vormis, välja arvatud juhtudel, kui teated on informatsioonilise iseloomuga, mille edastamisel teisele poolele ei ole õiguslikke tagajärgi. Teade loetakse kättesaaduks, kui: 6.3.1 teade on üle antud allkirja vastu; 6.3.2 teade on edastatud tähitud kirjana poole postiaadressil ja teate postitamisest on möödunud 5 (viis) kalendripäeva; 6.3.3 e-posti või telefoni teel on teade edastatud Lepingus märgitud kontaktisikule või esindajale. 7. Asukoht 7.1 Täitja peab andma lepingutäitmise käigus piisavalt informatsiooni korrektselt kirjalikku taasesitamist võimaldavas vormis koostatud kasutusjuhendi näol, et võimaldada Tellijal asukoht lepingujärgsete kohustuste täitmiseks kohaselt ette valmistada. Juhend peab olema antud sellise sisendiga, et objektiivselt keskmise võimekusega programmeerija oleks suuteline asukoha Töö vastuvõtmiseks vajalike testide teostamiseks ette valmistada. Juhend peab olema esitatud piisava ajavaruga selleks, et Tellijal oleks võimalik Töö üleandmisel alustada koheselt vastuvõtmiseks vajalike testide teostamist. Juhul, kui Töö üleandmise hetkeks ei ole juhendit edastatud või kui edastamisest hoolimata ei ole Tellija asukohta ette valmistada jõudnud, algab Töö vastuvõtmiseks ette nähtud tähtaeg kulgema pärast asukoha ette valmistamist. Kui Täitja ei ole ette näinud erilisi keskkonnatingimusi, võib Tellija eeldada, et neid ei nõuta. 7.2 Tellija teeb vastavad ettevalmistused ja loob tingimused omal kulul. 7.3 Kui Tellija ettevalmistused või loodud tingimused ei vasta lepingus sätestatule, esitab Täitja viivitamatult puuduste loetelu. Kui Tellija ei muuda olukorda selliselt, et Täitjal oleks võimalik ajagraafikust kinni pidada, on Täitjal õigus saada lepingujärgsete kohustuste täitmiseks vajalikku ajapikendust. 7.4 Täitjal on õigus taotleda juurdepääsu asukohale Tellija tavalisel tööajal. 7.5 Täitja kulud, mis on seotud lepingus sätestatud juurdepääsupiirangutega ja turvaprotseduuridega, sisalduvad Lepingu hinnas ning neid ei hüvitata. 7.6 Tellija võib igal ajal lepingu kehtivuse vältel muuta või kehtestada juurdepääsupiiranguid ja turvaprotseduure. Kui Täitja tõendab, et selline muudatuste tegemine või piirangute või protseduuride kehtestamine põhjustas lisakulusid, on tal õigus nende hüvitamisele. 8. Lepingu muutmine 8.1 Lepingut võib muuta poolte kirjalikul kokkuleppel. Muudatused jõustuvad pärast nende allkirjastamist mõlema poole poolt või poolte poolt määratud tähtajal. Kirjaliku vormi mittejärgimisel on muudatused tühised. 8.2 Riigihangete seaduse § 123 lg 1 p 1 kirjeldatud muudatused lepitakse kokku Tellija ja Täitja esindajate poolt kirjalikku taasesitamist võimaldavas vormis. 9. Poolte õiguskaitsevahendid 9.1 Lepingu see peatükk fikseerib Lepingu olulised rikkumised, menetluse rikkumisest teatamisel ning Poolte vastutuse. See peatükk ei välista ega piira Poole õigust kasutada muude Lepingu rikkumiste korral muid õigusaktidest tulenevaid õiguskaitsevahendeid, samuti kasutada täiendavaid õiguskaitsevahendeid lisaks selles peatükis kokkulepitule. 9.2 Lepingust või seadusest tuleneva õiguse või õiguskaitsevahendi mittekasutamine või selle kasutamisega viivitamine ei tähenda nimetatud õigusest või õiguskaitsevahendist või muudest õigustest või õiguskaitsevahenditest loobumist. Lepinguga seotud mis tahes loobumised on kehtivad ainult siis, kui need on selgesõnaliselt ja kirjalikult väljendatud. 9.3 Pooled vastutavad Lepinguga võetud kohustuste täitmata jätmise või mittekohase täitmise eest Eesti Vabariigi õigusaktides ning Lepingus ettenähtud korras. 9.4 Oluliseks lepingurikkumiseks loetakse muu hulgas järgmisi rikkumisi:  9.4.1 Pool ei täida mis tahes Lepingust tulenevat kohustust teise Poole poolt Lepingust tuleneva vastava kohustuse täitmiseks antud täiendava tähtaja jooksul; 9.4.2 Täitja ei täida garantiiperioodil Lepingust tulenevaid kohustusi; 9.4.3 Täitja ei ole esitanud Tellijale Asukoha keskkonnatingimusi, millest tulenevalt on häiritud Tellija seadmete, telekommunikatsioonide või tarkvara kohane funktsioneerimine ning mistõttu Tellija kaotab Täitja Lepingu järgsete kohustuste täitmise vastu huvi; 9.4.4 Täitja rikkus kohustust tahtlikult või raske hooletuse tõttu; 9.4.5 Täitja rikub Personaliga seonduvaid tingimusi; 9.4.6 Poolel või tema poolt kaasatud kolmandal isikul puuduvad Lepingu täitmiseks vajalikud õigused (sealhulgas load, litsentsid, Intellektuaalse omandi õigused); 9.4.7 Täitja suhtes on algatatud pankrotimenetlus, pankrot on välja kuulutatud, Täitja varad arestitakse või Täitja finantsseisund halveneb Tellija põhjendatud hinnangul oluliselt ja see halvenemine muudab vähetõenäoliseks Lepingu nõuetekohase täitmise; 9.4.8 Pool on rikkunud Intellektuaalse omandi õigusi ja nende kasutamise tingimusi; 9.4.9 Pool on rikkunud konfidentsiaalsuskohustust ja/või isikuandmete töötlemisega seonduvaid kohustusi; 9.4.10 Pool on rikkunud avalikustamise keelu kohustust; 9.4.11 Pool on rikkunud kolmandate isikutega seonduvaid kohustusi; 9.4.12 Tellija on viivituses Lepingus kokku lepitud maksetähtajaga rohkem kui kolmkümmend (30) kalendripäeva; 9.5 Poolel on õigus nõuda Lepingu olulise rikkumise korral leppetrahvi tasumist kuni 30% Lepingu hinnast iga vastava juhtumi korral. Juhul, kui leppetrahvi nõue on seotud Töö etapi puuduliku teostamisega ja puudus ei sea ohtu lepingujärgse Töö tervikuna nõuetekohast üleandmist ei tohi leppetrahvi nõue ületada 30% teostatud või töös oleva etapi maksumusest. 9.6 Poolte rahaline koguvastutus on piiratud Lepingu kogumaksumusega, kuid see piirang ei kehti tahtliku rikkumise korral. 9.7 Pool peab teavitama teist Poolt leppetrahvi nõudest mõistliku aja jooksul arvates ajast, mil ta sai teada leppetrahvi nõudmise õiguse tekkimisest. Pool on kohustatud tasuma leppetrahvi neljateistkümne (14) kalendripäeva jooksul arvates teiselt Poolelt sellekohase nõude saamisest. Kui Poole hinnangul on leppetrahvi nõue alusetu, on Pool kohustatud neljateistkümne (14) kalendripäeva jooksul oma seisukohta kirjalikult selgitama. Leppetrahvi nõudmine ei mõjuta Poole õigust nõuda Poolelt nõuetekohase Töö või selle osa teostamist ning kahju hüvitamist või kasutada muid seadusest tulenevaid õiguskaitsevahendeid. Tellija käsitleb kahjuna ka projekti „......“ rakendamiseks antud toetuse tagasimakse hüvitamist olukorras, mil tagasimakse on tingitud Täitja tegevusest/ tegevusetusest. 9.8 Lisaks leppetrahvi nõudele ja / või leppetrahvi asemel on Tellijal õigus nõuda Täitjalt Lepingu mittenõuetekohasel täitmisel, et: 9.8.1 Täitja kõrvaldaks puudused, sealhulgas nõuda, et Täitja hangiks parema teenuse osutamiseks vajalikud lisa- või asendusseadmed, -telekommunikatsioonid, -tarkvara ja teenused; 9.8.2 oluliste puuduste, samuti puuduste kõrvaldamise ebaõnnestumise korral nõuda, et Täitja teeks uue Töö ja tarniks uued seadmed, telekommunikatsioonid ja tarkvara või keelduda vastuvõtmisest ning Leping lõpetada;  9.8.3 võtta Täitja pakutud Töö vastu ning alandada vastavalt hinda. 9.9 Lepingust tulenevate leppetrahvide maksmine, samuti tekitatud kahju hüvitamine, ei vabasta Lepingut rikkunud poolt Lepingujärgsete kohustuste täitmisest. 10. Standardid, liidesed ja ühilduvus 10.1 Täitja lepingujärgsete kohustuste täitmine ei tohi tekitada häireid Tellija mistahes teiste liidestatud süsteemide talitluses. 10.2 Täitja garanteerib, et kõik seadmed, telekommunikatsioonid, tarkvara ja teenused on vastastikku ühilduvad, funktsioneerivad ja töötavad standardite ja/või liideste vahendusel rahuldavalt koos mistahes teiste lepingus sätestatud seadmete, telekommunikatsioonide, tarkvara ja teenustega ning lepingus sätestatud keskkonnas. 10.3 Täitja ei muuda ilma Tellija eelneva kirjaliku nõusolekuta mistahes standardeid, liideseid, sideprotokolle jms. 11. Dokumentatsioon 11.1 Lepingu täitmisel kaasneva dokumentatsiooni loomisel toetutakse dokumentatsiooniplaanile. 11.2 Täitja varustab Tellijat piisava ja adekvaatse dokumentatsiooniga, kaasa arvatud informatsioon seadmete, telekommunikatsioonide ja tarkvara projekteerimise ja funktsioneerimise kohta, mis on vajalik, et Tellija saaks seadmeid, telekommunikatsioone, tarkvara ja teenuseid efektiivselt kasutada, hooldada, kohandada ja neile lisaseadmeid lisada. 11.3 Kõik juhendid ja muud dokumendid esitatakse eesti keeles, kui ei ole kokku lepitud teisiti. 11.4 Dokumentatsioon peab vastama tootele, sisaldama muudatusi ja olema terminoloogiliselt üheselt mõistetav. 11.5 Dokumentide valmistamiseks ja levitamiseks kasutatakse paberkandjat või elektroonilist infokandjat. 12. Üleandmine ja vastuvõtmine 12.1 Hooldustööde üleandmine ja vastuvõtmine: 12.1.1 Hooldustööd antakse Tellijale üle aruande esitamisega kord kvartalis, milles märgitakse aruande esitamisele eelnenud perioodil tellimuste alusel teostatud hooldustööde nimekiri ja kirjeldus koos tundide arvuga. Juhul, kui hooldustööde tellimusi ei ole esitatud ja hooldustöid ei ole konkreetsel aruande perioodil teostatud, ei ole Täitjal aruande esitamise kohustust. 12.1.2 Tellijal on õigus esitada pretensioon hooldustööde aruande õigsuse kohta 5 tööpäeva jooksul arvates aruande esitamisest Täitja kontaktisiku poolt Tellija kontaktisikule. Pretensiooni esitamise õigus on muuhulgas olukorras, mil aruandes sisalduvaid töid ei ole tellitud. 12.1.3 Pretensiooni esitamisel on Täitjal kohustus esitada esimesel võimalusel, kuid mitte hiljemalt kui 5 tööpäeva jooksul, arvates pretensiooni esitamisest, aruande täpsustus või mõjuvad põhjendused aruande õigsuse kohta. 12.1.4 Hooldustööd loetakse Tellija poolt vastuvõetuks juhul kui Tellija ei ole esitanud pretensiooni ja möödunud on pretensiooni esitamise tähtaeg. 12.1.5 Hooldustööde eest esitab Täitja Tellijale arve iga kvartali möödudes kvartaliaruande alusel. 12.2 Arendustööde üleandmine ja vastuvõtmine: 12.2.1 Arendustöö või arendustöö etapi valmimise järgselt annab Täitja selle Tellijale üle vastuvõtmiseks. 12.2.2 Täitja peab Tellijat töö või töö etapi üle andmise viivitusest või viivitusse sattumise ohust ja põhjustest koheselt kirjalikku taasesitamist võimaldavas vormis informeerima. Kui Täitja viivituse põhjustab Tellija, on Täitjal õigus nõuda mõistlikku ajapikendust ja põhjendatud lisakulude hüvitamist. 12.2.3 Töö või töö etapi üleandmise kohta koostab Täitja üleandmise akti, milles näidatakse muuhulgas ära üleandmise kuupäev, teostatud töö, osutatud teenuste, hoolduse ja tarnitud seadmete, telekommunikatsioonide ja tarkvara detailiseeritud nimekiri ning vajaduse korral neis esinevad puudused. Iga töö etapi üleandmisel koostab ja esitab Täitja antud etapi kohta koostatud dokumentatsiooni, vastavalt dokumentatsiooniplaanile või Tellija poolt tehnilises kirjelduses esitatud nõudmistele. 12.2.4 Töö või töö etapi üleandmine Tellijale ei ole käsitatav selle vastuvõtmisena Tellija poolt. 12.2.5 Täitjal on õigus nõuda ja Tellijal kohustus töö vatsu võtta kui töös on Täitja poolt kõrvaldatud kõik järgmise prioriteediga vead: kriitiline/blocker, kõrge ja keskmine. Taolisel juhul lasub Täitjal kohustus vaegtöödena madala ja väheolulise tähtsusega vead parandada töö vastuvõtmise aktis toodud ajaperioodiks. 12.2.6 Pärast töö etapi üleandmist on Tellijal õigus töö üle vaadata 10 tööpäeva jooksul. Pärast töö üleandmist on Tellijal õigus töö üle vaadata 20 tööpäeva jooksul. 12.2.7 Juhul, kui Tellija leiab, et töö ei vasta Lepingu tingimustele, on Tellija kohustatud teavitama Täitjat töös avastatud puudustest, keeldumisest tööd enne puuduste kõrvaldamist vastu võtta ja kirjeldama töö puudused. Täitja on kohustatud puudused kõrvaldama 5 tööpäeva jooksul, kui pooled ei ole kokku leppinud mõnda muud tähtaega. Töö puuduste kõrvaldamise kulud kannab Täitja. 12.2.8 Enne töö üleandmist viib Täitja töö nõuetelevastavuse kindlakstegemiseks läbi testid. 12.2.9 Täitja esitab Tellijale kõik tema poolt läbiviidud testide tulemusena valminud dokumentide koopiad. 12.2.10 Enne töö vastuvõtmist viib Tellija töö nõuetelevastavuse kindlakstegemiseks läbi testid. 12.2.11 Kui töö või mistahes töö osa ei läbi teste, viiakse otsekohe pärast seda, kui Täitja on teinud vajalikud korrektuurid testide edukaks läbiviimiseks, läbi kordustestid samadel tingimustel. 12.2.12 Tellija nõudmisel viib kordustestid läbi Täitja. 12.2.13 Parandatud töö üleandmine toimub nagu esmakordsel üleandmiselgi. 12.2.14 Puudustega üle antud tööd ei loeta tähtaegselt üleantuks ning Tellijal on õigus nõuda sellise lepingurikkumise korral Täitjalt leppetrahvi Lepingus sätestatud korras ja määrades või rakendada muid õiguskaitsevahendeid. 12.2.15 Vastuvõtmiseks valmis töö peab vastama Lepingus sätestatud tingimustele. Töö etapi vastuvõtmine Tellija poolt ei tingi ega kohusta töö kui terviku vastuvõtmist Tellija poolt juhul, kui töö ei vasta tingimustele. Töö vastuvõtmise kohta koostab Tellija vastuvõtuakti, milles näidatakse muuhulgas ära vastuvõtmise kuupäev, teostatud töö, osutatud teenuste, hoolduse ja tarnitud seadmete, telekommunikatsioonide ja tarkvara detailiseeritud nimekiri.  12.2.16 Töö või töö etapp loetakse vastuvõetuks vastuvõtuakti allkirjastamisest või toodangukeskkonnas kasutusele võtmisest. Juhul, kui Tellija on võtnud puuduseid sisaldava töö või töö etapi toodangukeskkonnas kasutusele, loetakse vastuvõetuks ainult nõuetekohaselt teostatud tööd ja Täitjal on õigus nimetatute osas esitada arve. Taolises olukorras esitab Tellija Täitjale töös või töö etapis esinevate puuduste nimekirja ning puuduste kõrvaldamise tähtaja, kas enne töö või töö etapi toodangukeskkonnas kasutusele võtmist või vahetult pärast selle toimumist. 12.2.17 Mistahes seadmete, telekommunikatsioonide, tarkvara ja teenuste osa valmimisel võib Tellija anda välja vastuvõtuakti vastava osa kohta. Selline vastuvõtmine ei mõjuta Täitja kohustust täita kõiki Lepingus ettenähtud kohustusi. 12.2.18 Täitja vastutab töö juhusliku hävimise või kahjustumise eest kuni töö vastuvõtmiseni Tellija poolt. Lisatakse vajadusel: 12.2.19 Täitja kohustub Tellija juhendamisel märgistama Töö enne selle üleandmist vastavalt õigusaktides kehtestatud nõuetele (hankelepingu sõlmimisel märgitakse konkreetne viide, nt Vabariigi Valitsuse 30. augusti 2007. a määrusele nr 211 „Struktuuritoetuse andmisest ja kasutamisest teavitamise, selle avalikustamise ning toetusest rahastatud objektide tähistamise ja Euroopa Liidu osalusele viitamise tingimused ning kord“). või 12.2.19. Täitja kohustub seoses Euroopa Komisjoni poolt rahastatava projekti "……….“ tingimustega enne Töö üleandmist Tellijale märgistama Töö vastavalt Tellija poolt antud juhistele. ja 12.2.20. Tellija kinnitab, et ta on teadlik asjaolust, et projekti „……….“ rakendamiseks antud toetuse saamiseks peab Töö vastuvõtmine olema fikseeritud vastuvõtmisaktis ning kinnitatud juhtrühma poolt. 13. Koolitus 13.1 Täitja tagab Tellija personalile adekvaatse väljaõppe, kindlustamaks seadmete, telekommunikatsioonide, tarkvara ja teenuste rahuldava ja efektiivse toimimise, vastavalt Lepingus kokkulepitule. 13.2 Koolituse toimumise aeg, koht ja maht kooskõlastatakse eelnevalt Tellija kontaktisikuga. 14. Garantii 14.1 Täitja annab arendustöödele 12 (kaheteist) kuulise töövõtugarantii. Garantiiperiood algab Tööde kogumina vastuvõtmisest. 14.2 Garantiiperioodil ilmnevad puudused kõrvaldab Täitja omal kulul, v.a punktis 14.6 toodud juhtumitel. Kui ilmnenud puudused ei ole garantii korras kõrvaldatavad, esitab Täitja Tellijale põhjendused kirjalikku taasesitamist võimaldavas vormis, kuid mitte hiljem kui järgmisel tööpäeval pärast sellest asjaolust teada saamist. 14.3 Kui ei ole kokku lepitud teisiti, toimub garantiiliste puuduste üleandmine ja vastuvõtmine Lepingu punktis 10 toodud regulatsiooni kohaselt. 14.4 Juhul kui garantiiperioodil ilmnenud puudused muudavad osa või kõik seadmed, telekommunikatsioonid ja/või tarkvara kasutamiskõlbmatuks, varustab Täitja Tellijat nõutud tasemel toimimise garanteerivate lisa- või asendusosade ja muu vajalikuga omal kulul. 14.5 Tellija informeerib Täitjat puuduse iseloomust ja ulatusest otsekohe selle ilmnemisel. Täitja on kohustatud eemaldama ilmnenud puudused vastavalt lepingus toodule või Tellija poolt määratud ajal. 14.6 Garantiiga ei ole hõlmatud: 14.6.1 puudused, mille tekkimise eest vastutab Tellija; 14.6.2 diagnostikaks kulunud aeg, juhul kui algselt garantii juhtumine registreeritud juhtumi raames tuvastatakse, et tegu ei ole garantiilise juhtumiga. Vastav töö kuulub eraldi tasustamisele Lepingu tunnihinna alusel. 14.7 Garantii kaotab kehtivuse kui Täitjaga kooskõlastamata on muudetud või muudetakse lähtekoodi, v.a juhul kui Tellija suudab eristada lähtekoodis tehtavaid muudatusi. 15. Load ja litsentsid 15.1 Täitja vastutab ainuisikuliselt lepingu täitmiseks vajalike lubade ja litsentside saamise eest. Tellija teeb Täitjaga mõistliku koostööd, hoidmaks ära selliste lubade või litsentside väljaandmise asjatut viivitamist või väljaandmisest keeldumist. 15.2 Tellija võib ilma ette teatamata lepingu lõpetada, kui Täitja ei saa lepingu täitmiseks vajalikku luba või litsentsi. 15.3 Täitja garanteerib, et tal on õigus anda Tellijale lepingu objektiks oleva tarkvara ja teiste autori- või muude sarnaste õigustega kaitstavate esemete kasutamisõigus. 15.4 Täitja garanteerib, et nimetatud kasutusõiguse üleandmisega ei rikuta kolmandate isikute õigusi. Juhul kui kolmas isik esitab oma õiguste rikkumise tõttu Tellija vastu hagi ning see rahuldatakse, tasub Täitja võimalikud kahjuhüvitusnõuded, samuti õigusabikulud ja muud seonduvad kulud. 16. Riski üleminek 16.1 Juhusliku hävimise või kahjustumise risk läheb Tellijale üle töö vastuvõtmisel, samuti hetkel, mil Tellija satub viivitusse toimingu tegemisega, millega ta töö üleandmisele peab kaasa aitama. 17. Intellektuaalne vara 17.1 Lepingu allkirjastamisega kinnitab Täitja Tellijale, et talle kuuluvad Lepingu täitmiseks vajalikud varalised autoriõigused, litsentsid ja muud intellektuaalse omandi õigused, mis on tarvilikud Lepingu järgse Töö täielikuks teostamiseks ja loovutamiseks ning, et nende suhtes ei ole kolmandatel isikutel nõudeid. 17.2 Täitja kinnitab, et ta on võtnud tarvitusele kõik meetmed autori isiklike õiguste realiseerimiseks viisil, mis ei takista ega raskenda teose kasutamist ja autori varaliste õiguste teostamist Tellija poolt. 17.3 Täitja annab spetsiaaltarkvarale Euroopa Liidu tarkvara vaba kasutuse litsentsi v.1.1 (EUPL). Juhul, kui Töö üleandmine toimub etapiviisiliselt, siis loetakse litsents antuks iga etapi (teose) vastuvõtmisel Tellija poolt. 17.4 Tellijal on muuhulgas õigus spetsiaaltarkvara (teose) autoriõiguste kehtivusaja jooksul: 17.4.1 teost kasutada mis tahes eesmärgil ja mis tahes viisil; 17.4.2 teost reprodutseerida; 17.4.3 originaalteost muuta ja luua teosel põhinevaid tuletatud teoseid;  17.4.4 teost või selle koopiaid üldsusele edastada, sealhulgas neid kättesaadavaks teha või eksponeerida, samuti avalikult esitada; 17.4.5 teost või selle koopiaid levitada; 17.4.6 teost või selle koopiaid laenutada ja rentida; 17.4.7 anda all-litsentse teose või selle koopiate suhtes kehtivate õiguste kohta. 17.5 Täitja annab Tellijale spetsiaaltarkvara lähtekoodi, täitmiskoodi ja dokumentatsiooni kujul, mis võimaldab Tellijal sellest aru saada. 17.6 Tellija võib levitada lähtekoodi ja täitmiskoodi ning dokumentatsiooni ja selle muudatusi mistahes kolmandatele isikutele ja asutustele. 17.7 Kõik Täitja poolt Lepingu täitmise käigus koostatud dokumendid ja andmed kuuluvad Tellijale. Täitja annab kõik nimetatud dokumendid ja andmed Tellijale üle. 17.8 Tellija võib spetsiaaltarkvara autoriõigusi teostada mistahes olemasolevas või hiljem loodud keskkonnas, toel või formaadis. 17.9 Täitja tagab, et tema töötajad on loobunud Eesti seadusega lubatud ulatuses oma õigusest teostada isiklikke õigusi, et Tellijale oleks võimalik vajalikke varalisi õigusi litsentsida. 17.10 Lepingujärgse tarkvarasüsteemi loomiseks kolmandatele isikutele kuuluvate komponentide (tarkvara) kasutamise osas juhinduvad Pooled nende kasutamise litsentsitingimustest. Täitja kinnitab, et eelistab tarkvara loomisel selliseid kolmandatele isikutele kuuluvaid komponente, mille kasutamisega ei kaasne täiendavaid litsentsitasusid ega piiranguid tarkvara kasutamisel või alllitsentside andmisel. Täitja on kohustatud Tellijat teavitama juhul, kui Täitja plaanib tarkvara loomisel kasutada selliseid kolmandatele isikutele kuuluvaid komponente, mille kasutamine toob Tellijale kaasa täiendavaid litsentsitasusid või piiranguid tarkvara kasutamisel. Ilma Tellija kirjaliku nõusolekuta ei tohi Täitja tarkvara loomisel nimetatud komponente kasutada. 17.11 Nimetatud õigused kehtivad kogu autoriõiguste kehtivuse aja ja nende kehtivuse territooriumiks on kogu maailm. 18. Personal 18.1 Lepingus kirjeldatud teenuseid osutavad Lepingus nimetatud isikud vastavalt Lepingus sätestatud ülesannetele. Muudatusi tohib teha vaid Tellija kirjalikku taasesitamist võimaldavas vormis antud nõusolekul. 18.2 Täitja asendab Töid teostava isiku viivitamatult Lepingu objekti täitmise seisukohast võrdväärse kvalifikatsiooni ja kogemustega ning Tellijale vastuvõetava isikuga, kui: 18.2.1 Töid teostav isik ei ole võimeline teenuste osutamist jätkama haiguse, õnnetusjuhtumi või muu temast tuleneva põhjuse tõttu; 18.2.2 lepingus nimetatud Töid teostav isik osutub Tellija põhjendatud arvamuse kohaselt lepingujärgsete ülesannete täitmiseks ebakompetentseks või ebasobivaks või kui tema lepingujärgsete ülesannete täitmine pidevalt kahjustab lepingu korrektset ja õigeaegset täitmist. 18.2.3 Isikul on kuriteo toimepanemise eest määratud kehtiv karistus. 18.3 Täitja kannab kõik punktis 18.2 nimetatud asendusest tulenevad või sellega kaasnevad kulud. 18.4 Töid teostavatel isikutel ei tohi olla kuriteo toimepanemise eest määratud kehtivat karistust. 18.5 Töid teostavad isikud ei tohi olla Tellija töötajad ega Tellija töötajaga seotud juriidilised isikud. Seotud juriidiline isik tähendab käesoleva lepingu mõistes juriidilist isikut, mille juhtumis- või kontrollorgani liige Tellija töötaja on või juriidiline isik, milles vähemalt 1/10 osalusest kuulub Tellija töötajale. 19. Kolmandad isikud 19.1 Pooled võivad loovutada lepingust tulenevaid rahalisi nõudeid kolmandatele isikutele. Pooled on kohustatud teineteist nõude loovutamisest viivitamatult kirjalikult informeerima. 19.2 Pooled ei või oma lepingujärgseid kohustusi anda üle kolmandale isikule ega kaasata oma lepingujärgsete kohustuste täitmiseks kolmandat isikut ilma teise poole sellekohase selgesõnalise kirjaliku nõusolekuta.Tellijal on õigus edastada või suunata Täitja poolt esitatud arve tasumisele Tellijast erinevale hankijale nendevahelise koostöökokkuleppest tuleneval alusel juhul kui vastavasisuline teavitus on Tellija poolt pakkumuse esitamise ettepanekus kajastatud. 19.3 Pooled vastutavad kõigi isikute eest, keda nad kasutavad oma lepingujärgsete kohustuste täitmisel. 20. Auditeerimine 20.1 Mõlemal poolel on õigus kaasata auditeerimiseks sõltumatu audiitor.Audiitori kaasamiseks ei ole vajalik teise poole luba. 20.2 Audiitori isik ja muu auditeerimisega seotud asjaolud sätestatakse eraldi kokkuleppes. Auditeerimise käigus avastatud probleemid tuleb registreerida ja vajaduse korral sisestada probleemide lahendamise protsessi. 20.3 Täitja peab täpset arvet lepingu täitmisel töötatud inimpäevade ja –kuude kompenseerimisele kuuluvate kulude kohta. Audiitorile võimaldatakse piiramatu ligipääs nimetatud andmetele. 20.4 Audiitorit kaasanud pool tagab, et audiitor käsitleb saadud informatsiooni konfidentsiaalsena. Vastutus jääb audiitorit kaasanud poolele. 20.5 Pärast andmete auditeerimist ja kontrollimist teeb audiitor järeldusotsuse, mis on lõplik. 20.6 Auditi kulud kannab auditi tellinud pool. 21. Õigustest loobumine 21.1 Kummagi poole mistahes viivitus, hoolimatus või keeldumine teist poolt lepingutingimuste täitmise nõudmisel või muude nõuete esitamisel ei kujuta endast selle poole mistahes lepingujärgsetest õigustest loobumist või nende tühistamist. 22. Konfidentsiaalsus ja isikuandmed 22.1 Täitja ei või oma lepingujärgseid kohustusi anda üle kolmandale isikule ega kaasata oma lepingujärgsete kohustuste täitmiseks kolmandat isikut ilma Tellija sellekohase selgesõnalise kirjaliku nõusolekuta. 22.2 Täitja on kohustatud: 22.2.1 tagama lepingu täitmise käigus Tellijalt ükskõik mis vormis saadud teabe (andmed, tehingudokumentatsioonis ja lepingutes sisalduvad Tellija esindajate isikuandmed, know-how) konfidentsiaalsuse ning ei edasta ega võimalda sellele teabele juurdepääsu kolmandale isikule ilma Tellija sellekohase selgesõnalise kirjaliku nõusolekuta; 22.2.2 tagama lepingueelsete läbirääkimiste, lepingujärgsete kohustuste ja lepingu täitmise käigus ükskõik mis vormis teatavaks saanud isikuandmete (v.a. tehingudokumentatsioonis ja lepingutes sisalduvate Tellija esindajate isikuandmete) konfidentsiaalsuse ning ei edasta ega võimalda nendele juurdepääsu ühelegi kolmandale isikule ilma Tellija sellekohase selgesõnalise kirjaliku nõusolekuta; 22.2.3 ei edasta punktis 22.2.2 nimetatud isikuandmeid väljapoole Euroopa Liidu liikmesriikide ja Euroopa Majandusühendusse kuuluvate riikide territooriumit ilma tellija sellekohase selgesõnalise kirjaliku nõusolekuta; 22.2.4 kasutama ja töötlema punktis 22.2.2. nimetatud isikuandmeid üksnes Lepingu täitmiseks ja Tellija dokumenteeritud juhiste alusel, välja arvatud juhul, kui täitja on kohustatud teavet töötlema täitja suhtes kohalduva õiguse alusel. Viimati nimetatud juhul teavitab Täitja Tellijat vastava kohustuse olemasolust enne teabe töötlemist, kui selline teavitamine ei ole olulise avaliku huvi tõttu Täitja suhtes kohalduva õigusega keelatud; 22.2.5 võimaldab juurdepääsu punktis 22.2.2. nimetatud isikuandmetele ainult nendele isikutele, kellel on selleks oma tööülesannete täitmiseks vajadus ning tagab, et need isikud on teadlikud ning järgivad isikuandmete töötlemisalaseid nõudeid ja õigusakte, nad on saanud asjakohase koolituse eelmainitud nõuete kohta, on võtnud endale konfidentsiaalsuskohustuse või neile kehtib asjakohane seadusest tulenev konfidentsiaalsuskohustus. Vastav konfidentsiaalsuskohustus jääb kehtima pärast käesoleva Lepingu lõppemist; 22.2.6 kohustub täitma kõiki kehtivaid isikuandmete töötlemisalaseid nõudeid, andmete turvalisust puudutavaid ning isikuandmete kaitse alaseid Euroopa Liidu ja Eesti Vabariigi õigusakte ja muid eeskirju. 22.2.7 kohustub rakendama järgmisi organisatsioonilisi, füüsilisi ja infotehnilisi turvameetmeid punktis 22.2.2. nimetatud isikuandmete kaitseks juhusliku või tahtliku volitamata muutmise; juhusliku hävimise ja tahtliku hävitamise eest ning õigustatud isikule andmete kättesaadavuse takistamise eest, volitamata töötlemise s.h. avalikustamise eest: a) vältima kõrvaliste isikute ligipääsu isikuandmete töötlemiseks kasutatavatele seadmetele; b) ära hoidma andmete omavolilist lugemist, kopeerimist ja muutmist andmetöötlussüsteemis, samuti andmekandjate omavolilist teisaldamist; c) ära hoidma isikuandmete omavolilist salvestamist, muutmist ja kustutamist ning tagama, et tagantjärele oleks võimalik kindlaks teha, millal, kelle poolt ja milliseid isikuandmeid salvestati, muudeti või kustutati või millal, kelle poolt ja millistele isikuandmetele andmetöötlussüsteemis juurdepääs saadi; d) tagama, et igal andmetöötlussüsteemi kasutajal oleks juurdepääs ainult temale töötlemiseks lubatud isikuandmetele ja temale lubatud andmetöötluseks; e) tagama andmete olemasolu isikuandmete edastamise kohta: millal, kellele ja millised isikuandmed edastati, samuti selliste andmete muutusteta säilimise; f) tagama, et isikuandmete edastamisel andmesidevahenditega ja andmekandjate transportimisel ei toimuks isikuandmete omavolilist lugemist, kopeerimist, muutmist või kustutamist; g) pidama arvestust isikuandmete töötlemisel kasutatavate tema kontrolli all olevate seadmete ja tarkvara üle, dokumenteerides järgmised andmed: i. seadme nimetus, tüüp ja asukoht ning seadme valmistaja nimi; ii. tarkvara nimetus, versioon, valmistaja nimi ja kontaktandmed.  22.2.8 teavitama tellijat toimunud või põhjendatult kahtlustatavast käesoleva lepingu punktis 22.2.1 ja/või 22.2.2 sätestatud konfidentsiaalsuskohustuse rikkumisest; punktis 22.2.7. ja selle alapunktides a-g sätestatud turvameetmete rikkumisest, mis põhjustab, on põhjustanud või võib põhjustada edastatavate, salvestatud või muul viisil töödeldavate isikuandmete juhusliku või ebaseadusliku hävitamise, kaotsimineku, muutmise või loata avalikustamise või neile juurdepääsu, kirjalikult viivitamata aga mitte hiljem kui kakskümmend neli (24) tundi pärast sellest teada saamist. Teates tuleb vähemalt: a) kirjeldada (Isikuandmetega seotud) rikkumise laadi, sealhulgas puudutatud andmesubjektide liike ja arvu ning puudutatud kirjete liike ja arvu; b) teatada andmekaitse töötaja ja tema kontaktandmed või muu kontaktpunkt, kust saab lisateavet; c) soovitada meetmeid (Isikuandmetega seotud) rikkumise võimalike negatiivsete mõjude leevendamiseks; d) kirjeldada (Isikuandmetega seotud) rikkumise tõttu andmesubjektidele tekkivaid tagajärgi ja potentsiaalseid ohte; e) kirjeldada täitja/või kolmandast isikust alltöötleja poolt välja pakutud või võetud meetmeid (Isikuandmetega seotud) rikkumisega tegelemiseks ja f) esitada muud teavet, mis on mõistlikult nõutav, et Tellija saaks täita Kohaldatavaid andmekaitse õigusakte, sealhulgas riigiasutustega seotud teavitamise ja avaldamise kohustusi, näiteks teavet, mis on nõutav andmesubjekti tuvastamiseks. 22.2.9 Tellija eelnevalt kirjalikul heakskiidul lõpetama käesoleva lepingu punktis 22.2.8.nimetatud rikkumise ning kohaldama meetmeid (isikuandmetega seotud) rikkumise lahendamiseks, sealhulgas vajaduse korral rikkumise võimaliku kahjuliku mõju kõrvaldamiseks ja leevendamiseks; 22.2.10 kohustub lepingu lõppemisel kustutama kõik punktis 22.2.2. nimetatud isikuandmed ja nimetatute koopiad 30 päeva jooksul, v.a juhul, kui õigusaktidest tuleneb teisiti; 22.2.11 teeb Tellijale kättesaadavaks kogu teabe, mida Tellija peab vajalikuks lepingus sätestatud kohustuste täitmise tõendamiseks; 22.2.12 võimaldab Tellijal või Tellija poolt volitatud audiitoril teha auditeid ja kontrolle ning panustab nendesse; 22.2.13 kohustub võimaluse piires asjakohaste tehniliste ja korralduslike meetmete abil punktis 22.2.2. nimetatud isikuandmete osas Tellijal täita Tellija kohustust vastata taotlustele andmesubjekti õiguste teostamiseks ning teostada nende õiguste teostamisest tulenevaid toiminguid (andmete parandamine, sulgemine, kustutamine). 22.3 Käesoleva lepingu punktis 22.2.1. sätestatud konfidentsiaalsuse nõue ei laiene informatsiooni avaldamisele täitja audiitorile ja advokaadile. 22.4 Käesoleva lepingu punktides 22.2.1. ja 22.2.2. sätestatud konfidentsiaalsuskohustuse nõue on tähtajatu ning kehtib nii lepingu täitmise ajal kui ka pärast lepingu lõppemist. 22.5 Tulenevalt konfidentsiaalse informatsiooni laadist on tellijal õigus seada täiendavaid nõuded ja/või juhised isikuandmete töötlemiseks. 22.6 Kõik käesoleva lepingu punktides 22.2.1. – 22.4 kohustused kehtestab täitja kõikidele kolmandatele isikutele, keda ta kasutab oma lepingujärgsete kohustuste täitmisel. Kolmas isik on füüsiline või juriidiline isik või riigi- või kohaliku omavalitsuse asutus, kes ei ole ei tellija ega ka täitja. 23. Avalikud suhted 23.1 Pooled ei tegele seoses lepinguga avalike suhetega ega anna teateid pressile, elektroonilisele meediale, üldsusele või teistele auditooriumidele, välja arvatud teise poole eelneval kirjalikul nõusolekul. Avaldada võib vaid teateid, mis on teise poolega eelnevalt kooskõlastatud. 23.2 Kõik eelnimetatud kohustused kehtestab pool ka kõigile kolmandatele isikutele, keda ta kasutab oma lepingujärgsete kohustuste täitmisel. 24. Lepingu täitmise peatamine ja lepingu lõpetamine 24.1 Tellija võib peatada Täitjale lepingujärgselt makstavate summade maksmise kas osaliselt või täielikult, kui: 24.1.1 Täitja ei täida Lepingut; 24.1.2 vastuvõtmise, testimise või auditeerimise käigus avastatakse puudusi või muid Täitja poolseid kohustuste rikkumisi; 24.1.3 Tellija Lepingu järgsete kohustuste õigeaegset ja korrektset täitmist segab või ähvardab segada muu asjaolu, mille eest vastutab Täitja. 24.2 Täitja võib peatada Tellijale teenuse osutamise kas osaliselt või täielikult, kui: 24.2.1 Tellija ei täida Lepingut; 24.2.2 Täitja Lepingu järgsete kohustuste õigeaegset ja korrektset täitmist segab või ähvardab segada muu asjaolu, mille eest vastutab Tellija. 24.3 Tellija võib igal ajal Lepingu üles öelda, teatades sellest 1 (üks) kuu ette. Sellisel juhul on Täitjal õigus nõuda tasu täidetud kohustuste eest. 24.4 Tellijal on õigus Leping erakorraliselt etteteatamata lõpetada Täitjapoolse olulise Lepingu rikkumise korral. Lepingu lõpetamisel punktides 9.4 nimetatud juhtudel Täitja tehtud Tööd ei tasustata. Täitja poolt tarnitud seadmed, telekommunikatsioonid ja tarkvara tagastatakse, selle võimatuse korral või muul juhul, kui tagastamine on saadu olemuse tõttu välistatud, makstakse hüvitust võlaõigusseaduses sätestatud korras. 24.5 Täitja võib Lepingu üles öelda Tellijapoolse olulise Lepingu rikkumise korral pärast vastava hoiatuse saatmist, kui rikkumist ei ole kõrvaldatud 10 (kümne) tööpäeva jooksul peale hoiatuse esitamist. Sellise Lepingu lõpetamise korral maksab Tellija Täitjale tasu täidetud kohustuste eest. 24.6 Lepingu lõppemisel on Täitja kohustatud Tellijale tagastama kõik Lepingu täitmiseks üleantu. 25. Vääramatu jõud 25.1 Lepingust tulenevate kohustuste mittetäitmist või mittenõuetekohast täitmist ei loeta Lepingu rikkumiseks, kui selle põhjuseks oli vääramatu jõud. Vääramatu jõuna käsitlevad pooled võlaõigusseaduse §-s 103 lg 2 nimetatud asjaolusid. 25.2 Pool, kelle tegevus lepingujärgsete kohustuste täitmisel on takistatud vääramatu jõu asjaolude tõttu, on kohustatud sellest koheselt kirjalikult teatama teisele Poolele, esitades teavitusega ühes tõendid kõigi järgnevate asjaolude esinemise kohta: 25.2.1 takistava asjaolu esinemine, mis takistab kohustuse kohast täitmist; 25.2.2 takistava asjaolu asetsemine väljaspool võlgniku mõjusfääri; 25.2.3 asjaolu ettenägematus;  25.2.4 asjaolu vältimatus ja ületamatus. 25.3 Vääramatu jõu asjaolude ilmnemisel pikeneb Lepingu lõpptähtaeg nimetatud asjaolude esinemise perioodi võrra. Pool peab vääramatu jõu asjaolude äralangemisel Lepingut täitma asuma. Kui vääramatu jõu asjaolude tõttu on Poole Lepingust tulenevate kohustuste täitmine takistatud enam kui 60ne kalendripäeva võrra võib teine Pool öelda lepingu üles. 26. Kehtiv seadusandlus 26.1 Lepingule ning kõikidele lepingu osaks olevatele dokumentidele kohaldatakse Eesti Vabariigi õigusakte. 27. Vaidluste lahendamine 27.1 Käesoleva Lepingu allkirjastamisega kinnitavad pooled, et on tutvunud ja on nõus Lepinguga ja selle lisadega ning mõistavad täielikult enesele võetavate kohustuste sisu ning nende tagajärgi. 27.2 Lepinguga seotud või sellest tulenevate arusaamatuste või vaidluste puhul püüavad pooled leida lahenduse heal tahtel põhinevate läbirääkimiste teel. 27.3 Kokkuleppe mittesaavutamisel lahendatakse vaidlus Harju Maakohtus.