HANKELEPING NR 2/138-18
Tallinnas, september 2018
Registrite ja Infosüsteemide Keskus, (registrikoodiga 70000310) asukohaga Lõkke tn 4, 19081 Tallinn,
keda esindab põhimääruse alusel direktor Mehis Sihvart, edaspidi Tellija,
ja
Avalanche Laboratory OÜ (registrikoodiga 14175080) asukohaga Toompuiestee 33a, 10149 Tallinn,
keda esindab põhikirja alusel juhatuse liige Rain Kirjanen, edaspidi Täitja,
ning
Kultuuriministeerium (registrikood 70000941), asukohaga Suur-Karja 23, 15076 Tallinn, keda esindab
põhimääruse alusel kantsler Tarvi Sits, edaspidi Maksja,
keda nimetatakse edaspidi pool või koos pooled, sõlmisid käesoleva hankelepingu (edaspidi nimetatud
leping) alljärgnevas:
1. Lepingu ese
1.1. Vastavalt riigihankes „Muuseumide infosüsteemi ja digitaalhoidla hooldustööde ja lisaarenduste
tellimine“ (viitenumber 198812) esitatud edukaimale pakkumusele teostab Täitja muuseumide
infosüsteemi ja digitaalhoidla hooldustöid fikseeritud kuutasu alusel ja lisaarendusi vastavalt Tellija
esitatud tellimustele ning täidab kõik muud lepingust tulenevad kohustused (edaspidi ka Töö). Töö
sisulised tingimused ja tellimuste esitamise kord on sätestatud lepingu lisades.
1.2. Pooled kinnitavad, et teevad kõik enesest oleneva, et täita lepingu eesmärgid käesolevas lepingus,
seonduvates õigusaktides ning juhtrühma otsustes sätestatud tingimustel ja mahus.
2. Hind ja maksetingimused
2.1. Lepingu hind moodustub tellitud hooldus- ja lisaarendustööde hinnast.
2.2. Hooldustööde tasu on 3 333,32 eurot kuus, mille eest tagab Täitja maksimaalselt 128,01 tundi
hooldustöid, arvestusega, et hooldustööde tunnihind on 26,04 eurot.
2.3. Tellijal on õigus, kuid mitte kohustus igakuiselt suurendada hooldustööde tundide arvu kuni 30%
ulatuses punktis 2.2 toodud hooldustööde mahust. Vastavate hooldustööde eest tasutakse punktis
2.2 sätestatud hooldustööde tunnihinna alusel.
2.4. Lisaarenduste tunnihind on 90 eurot.
2.5. Lepingus toodud hinnad sisaldavad kõiki makse, sh käibemaksu.
2.6. Lepingus 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. Juhud, mil Täitjal on
õigus nõuda reisi- või transpordikulude hüvitamist, sätestatakse lepingus.
2.7. Tellija/Maksja tasub lepingu alusel teostatud Tööde eest lepingu lisades sätestatud korras.
3. Lepingu kehtivus
Leping jõustub selle allkirjastamisest ning kehtib kuni 31.12.2019.
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.Dokumentatsiooniplaan Lisa nr 3;
4.1.4.Tehniline kirjeldus Lisa nr 4;
4.1.5.Pakkumus Lisa nr 5.
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.
Täitja: Maksja:
Tellija:
/allkirjastatud digitaalselt/ /allkirjastatud digitaalselt/ /allkirjastatud digitaalselt/
Mehis Sihvart Rain Kirjanen Tarvi Sits
Direktor Juhatuse Liige Kantsler
Registrite ja Infosüsteemide
Avalanche Laboratory OÜ Kultuuriministeerium
Keskus
2
Hankeleping nr 2/138-18
Lisa nr 1
HANKELEPINGU ÜLDTINGIMUSED
Kui eritingimustes on sätestatud teisiti kui üldtingimustes, siis kehtib eritingimustes toodu.
1. Definitsioonid
Järgnevad definitsioonid laienevad nii lepingule kui ka selle osaks olevatele dokumentidele.
1.1. Tarkvara – Tarkvara tähendab põhiliselt arvutiprogramme, telekommunikatsioone, andmebaasi-,
rakendus- ja muud tarkvara objektikoodis, lähtekoodis või nende mistahes muid vorme või
adaptsioone koos sellega seonduva dokumentatsiooniga. Spetsiaalselt Tellijale tema funktsioonide
täitmiseks loodud tarkvara käsitletakse lepingu raames spetsiaaltarkvarana.
1.2. Infosüsteem – Muuseumide infosüsteem ja digitaalhoidla.
1.3. Seadmed – Seadmed tähendavad lepingus kirjeldatud tooteid, hõlmates nendega otseselt seotud
tarkvara, mis on vajalik seadmete funktsioneerimiseks.
1.4. Telekommunikatsioonid – Telekommunikatsioonid tähendavad sisemise ja välise
telekommunikatsiooni seadmeid, tarkvara ja teenuseid ning vajalikke vahendeid, teenuseid ja
protseduure.
1.5. 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.
1.6. 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.
1.7. Hooldus – 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.
Lepingu raames teostatavate hooldustööde täpsemad tingimused on fikseeritud lepingu lisades.
1.8. Lisaarendus – Lisaarendus tähendab muuseumide infosüsteemi ja digitaalhoidla tarkvara
eesmärgipärase funktsioneerimise tagamiseks teostatavaid töid, mis sisaldavad endas tehnilist
konsultatsiooni, süsteemi- ja detailanalüüsi läbiviimist ning muuseumide infosüsteemi ja/või
digitaalhoidla tarkvara lähtekoodi programmeerimist. Lisaarenduste tellimise protsess on fikseeritud
lepingu lisades.
1.9. Toodangukeskkond – Reaalseks andmevahetuseks mõeldud keskkond, mis ei ole test- või
arenduskeskkond.
2. Maksmine
2.1. Täitja esitab Tellijale / Maksjale arve elektroonselt, eelistatuna masinloetaval kujul. Arve esitatakse
pärast üleandmise-vastuvõtmise akti Tellija poolset allkirjastamist. Hooldustööde eest tasutakse
kvartaalselt.
2.2. Arve peab sisaldama vähemalt alljärgnevaid andmeid:
2.2.1. info arve esitaja kohta;
2.2.2. info Maksja kohta;
2.2.3. viide Lepingule;
2.2.4. riigihanke viitenumber;
2.2.5. käibemaksukohustuslase number;
2.2.6. vastuvõetud Töö nimetus ja kirjeldus;
2.2.7. käibemaks;
2.2.8. kogusumma.
3
2.3. Tellija / Maksja tasub arve Täitja poolt esitatud arvel märgitud kuupäevaks. Maksetähtaeg ei tohi olla
lühem kui 30 kalendripäeva. Ettemakseid Tellija / Maksja ei teosta.
2.4. Lõpparve maksmine eeldab Täitja kõigi lepingu järgsete kohustuste täitmist ning Tellija poolt
vastuvõtmist.
2.5. Tellijal / Maksjal on õigus lepingu rikkumise korral arvestatud leppetrahvid ja kahju hüvitised maha
arvata lepingu alusel Täitjale tasumisele kuuluvatest summadest.
2.6. Tellija / Maksja poolt makstud mistahes summa, mis ületab Täitjale Lepingus ettenähtu, maksab
Täitja Tellijale / Maksjale tagasi 30 kalendripäeva jooksul pärast vastava teate saamist.
2.7. 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.
3. Informatsioon ja aruanded
3.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.
3.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.
3.3. Tellija abistab Täitjat niipalju kui võimalik lepingusse puutuva informatsiooni saamisel, mida Täitja
mõistlikkuse piirides lepingu täitmiseks nõuab.
3.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.
4. Teated ja kirjavahetus
4.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.
4.2. Kui teisele poolele edastatav teade eeldab vastust, tuleb vastata viivitamatult, kuid mitte hiljem kui 2
tööpäeva jooksul.
4.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:
4.3.1. teade on üle antud allkirja vastu;
4.3.2. teade on edastatud tähitud kirjana poole postiaadressil ja teate postitamisest on möödunud 5
(viis) kalendripäeva;
4.3.3. e-posti või telefoni teel saadud teate saamist on kinnitatud e-posti teel.
5. Asukoht
5.1. Täitja peab andma lepingus piisavalt informatsiooni, et võimaldada Tellijal asukoht lepingujärgsete
kohustuste täitmiseks kohaselt ette valmistada. Kui Täitja ei ole ette näinud erilisi
keskkonnatingimusi, võib Tellija eeldada, et neid ei nõuta.
5.2. Tellija teeb vastavad ettevalmistused ja loob tingimused omal kulul vastavalt poolte vahel
kokkulepitud ajagraafikule.
5.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.
5.4. Täitjal on õigus taotleda juurdepääsu asukohale Tellija tavalisel tööajal.
5.5. Täitja kulud, mis on seotud lepingus sätestatud juurdepääsupiirangutega ja turvaprotseduuridega,
sisalduvad lepingu hinnas ning neid ei hüvitata.
5.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.
4
6. Poolte õiguskaitsevahendid
6.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.
6.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.
6.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.
6.4. Oluliseks lepingurikkumiseks loetakse muu hulgas järgmisi rikkumisi:
6.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;
6.4.2. Täitja ei täida garantiiperioodil lepingust tulenevaid kohustusi;
6.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 lepingujärgsete kohustuste täitmise vastu huvi;
6.4.4. Täitja rikkus kohustust tahtlikult või raske hooletuse tõttu;
6.4.5. Täitja rikub personaliga seonduvaid tingimusi;
6.4.6. Poolel või tema poolt kaasatud kolmandal isikul puuduvad lepingu täitmiseks vajalikud õigused
(sealhulgas load, litsentsid, intellektuaalse omandi õigused);
6.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;
6.4.8. Pool on rikkunud intellektuaalse omandi õigusi ja nende kasutamise tingimusi;
6.4.9. Pool on rikkunud konfidentsiaalsuskohustust ja/või isikuandmete töötlemisega seonduvaid
kohustusi;
6.4.10. Pool on rikkunud avalikustamise keelu kohustust;
6.4.11. Pool on rikkunud kolmandate isikutega seonduvaid kohustusi;
6.4.12. Tellija / Maksja on viivituses lepingus kokku lepitud maksetähtajaga rohkem kui
kolmkümmend (30) kalendripäeva.
6.5. Poolel on õigus nõuda lepingu olulise rikkumise korral leppetrahvi tasumist kuni 10 000 eurot iga
vastava juhtumi korral.
6.6. Leppetrahvide ja viiviste kogumaksumus ei tohi ületada Lepingu hinda, välja arvatud juhul, kui Pool
rikkus kohustust tahtlikult või raske hooletuse tõttu.
6.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.
6.8. Lisaks leppetrahvi nõudele ja / või leppetrahvi asemel on Tellijal õigus nõuda Täitjalt lepingu
mittenõuetekohasel täitmisel, et:
6.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;
6.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;
6.8.3. võtta Täitja pakutud Töö vastu ning alandada vastavalt hinda.
6.9. Lepingust tulenevate leppetrahvide maksmine, samuti tekitatud kahju hüvitamine, ei vabasta lepingut
rikkunud poolt lepingujärgsete kohustuste täitmisest.
5
7. Standardid, liidesed ja ühilduvus
7.1. Täitja lepingujärgsete kohustuste täitmine ei tohi tekitada häireid Tellija mistahes teiste liidestatud
süsteemide talitluses.
7.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.
7.3. Täitja ei muuda ilma Tellija eelneva kirjaliku nõusolekuta mistahes standardeid, liideseid,
sideprotokolle jms.
8. Dokumentatsioon
8.1. Lepingu täitmisel kaasneva dokumentatsiooni loomisel toetutakse dokumentatsiooniplaanile.
Dokumentatsiooni maksumus sisaldub lepingu hinnas ja täitjal ei ole õigust täiendavale tasule
seoses lepingu täitmisel loodava dokumentatsiooniga.
8.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.
8.3. Kõik juhendid ja muud dokumendid esitatakse eesti keeles, kui ei ole kokku lepitud teisiti.
8.4. Dokumentatsioon peab vastama tootele, sisaldama muudatusi ja olema terminoloogiliselt üheselt
mõistetav.
8.5. Dokumentide valmistamiseks ja levitamiseks kasutatakse paberkandjat või elektroonilist infokandjat.
9. Üleandmine ja vastuvõtmine
9.1. Hooldustööde üleandmine ja vastuvõtmine:
9.1.1. Hooldustööd antakse Tellijale üle aruande esitamisega üks kord kuus, 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 kuul teostatud, ei ole Täitjal aruande esitamise kohustust.
9.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.
9.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.
9.1.4. Hooldustööd loetakse Tellija poolt vastuvõetuks juhul kui Tellija ei ole esitanud pretensiooni
ja möödunud on pretensiooni esitamise tähtaeg. Hooldustööde eest esitab Täitja Tellijale /
Maksjale arve iga kvartali lõpus.
9.2. Lisaarenduste üleandmine ja vastuvõtmine:
9.2.1. Lisaarenduste või lisaarenduste etapi valmimise järgselt annab Täitja selle Tellijale üle
vastuvõtmiseks. Üleandmise kohta koostab Täitja üleandmise-vastuvõtmise akti, milles
näidatakse muuhulgas ära üleandmise kuupäev, teostatud töö(d), osutatud teenuste,
hoolduse ja tarnitud seadmete, telekommunikatsioonide ja tarkvara detailiseeritud nimekiri.
9.2.2. Täitja peab Tellijat üleandmise 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.
9.2.3. Üleandmine Tellijale ei ole käsitatav selle vastuvõtmisena Tellija poolt.
9.2.4. Tellijal on 20 tööpäeva aega kontrollida vastuvõtmiseks esitatud töö(de) lepingu tingimustele
vastavust.
9.2.5. Juhul, kui Tellija leiab, et töö ei vasta lepingu tingimustele, on Tellija kohustatud teavitama
Täitjat töös avastatud puudustest ja keeldumisest tööd enne puuduste kõrvaldamist vastu
võtta. Töö puudused (vaegtööd) koos puuduste kõrvaldamise tähtajaga fikseeritakse
üleandmise-vastuvõtmise aktis. Akti allkirjastamisega kinnitab Täitja et on teadlik aktis
6
märgitud puuduste kõrvaldamise ja vaegtööde teostamise tähtaegadest ning võtab
kohustuse nendest tähtaegadest kinni pidada. Kõrvaldatud puuduste kohta vormistatakse
eraldi üleandmise-vastuvõtmise akt.
9.2.6. Täitja on kohustatud puudused kõrvaldama 5 tööpäeva jooksul, kui pooled ei ole
üleandmise-vastuvõtmise aktis kokku leppinud mõnda muud tähtaega. Töö puuduste
kõrvaldamise kulud kannab Täitja.
9.2.7. Kui Tellijal puuduvad üleantud tööde osas pretensioonid, allkirjastavad pooled lepingu
eseme üleandmise-vastuvõtmise akti.
9.2.8. Täitja annab Tellijale koos üleandmise-vastuvõtmise aktiga üle töö või töö etapi kohta
koostatud dokumentatsiooni, vastavalt dokumentatsiooniplaanile või Tellija poolt tellimuses
esitatud nõudmistele.
9.2.9. Enne töö üleandmist viib Täitja Töö nõuetelevastavuse kindlakstegemiseks läbi testid. Täitja
esitab Tellijale kõik tema poolt läbiviidud testide tulemusena valminud dokumentide koopiad.
9.2.10. Enne töö vastuvõtmist viib Tellija lisaarenduse nõuetelevastavuse kindlakstegemiseks läbi
testid.
9.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.
Tellija nõudmisel viib kordustestid läbi Täitja.
9.2.12. 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.
9.2.13. Vastuvõtmiseks valmis töö peab vastama Lepingus sätestatud tingimustele. Töö etapi
vastuvõtmine Tellija poolt ei tingi iseenesest ega kohusta töö kui terviku vastuvõtmist Tellija
poolt juhul, kui töö ei vasta tingimustele
9.2.14. 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.
9.2.15. 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.
9.2.16. Täitja vastutab töö juhusliku hävimise või kahjustumise eest kuni töö vastuvõtmiseni Tellija
poolt.
10 Garantii
10.1. Täitja annab Lisaarendustele 12 (kaheteist) kuulise töövõtugarantii. Garantiiperiood algab
Lisaarenduste kogumina vastuvõtmisest.
10.2. Garantiiperioodil ilmnevad puudused kõrvaldab Täitja omal kulul, v.a punktis 10.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.
10.3. Kui ei ole kokku lepitud teisiti, kõrvaldab Täitja puudused 10 tööpäeva jooksul puudusest
teada saamisest.
10.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.
10.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.
10.6. Garantiiga ei ole hõlmatud:
10.6.1. puudused, mille tekkimise eest vastutab Tellija;
10.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 Lisaarenduste tunnihinna alusel.
7
10.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.
11 Load ja litsentsid
11.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.
11.2. Tellija võib ilma ette teatamata lepingu lõpetada, kui Täitja ei saa lepingu täitmiseks vajalikku
luba või litsentsi.
11.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.
11.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.
12 Riski üleminek
Juhusliku hävimise või kahjustumise risk läheb Tellijale üle lisaarenduste vastuvõtmisel,
samuti hetkel, mil Tellija satub viivitusse toimingu tegemisega, millega ta lisaarenduste
üleandmisele peab kaasa aitama.
13 Intellektuaalne vara
13.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 Lepingujärgse Töö täielikuks teostamiseks ja loovutamiseks ning, et nende suhtes ei
ole kolmandatel isikutel nõudeid.
13.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.
13.3. Täitja annab spetsiaaltarkvarale Euroopa Liidu tarkvara vaba kasutuse litsentsi v.1.1 (EUPL).
13.4. Tellijal on muuhulgas õigus spetsiaaltarkvara (edaspidi teos) autoriõiguste kehtivusaja jooksul:
13.4.1. teost kasutada mis tahes eesmärgil ja mis tahes viisil;
13.4.2. teost reprodutseerida;
13.4.3. originaalteost muuta ja luua teosel põhinevaid tuletatud teoseid;
13.4.4. teost või selle koopiaid üldsusele edastada, sealhulgas neid kättesaadavaks teha või
eksponeerida, samuti avalikult esitada;
13.4.5. teost või selle koopiaid levitada;
13.4.6. teost või selle koopiaid laenutada ja rentida;
13.4.7. anda all-litsentse teose või selle koopiate suhtes kehtivate õiguste kohta.
13.5. Täitja annab Tellijale spetsiaaltarkvara lähtekoodi, täitmiskoodi ja dokumentatsiooni kujul, mis
võimaldab Tellijal sellest aru saada.
13.6. Tellija võib levitada lähtekoodi ja täitmiskoodi ning dokumentatsiooni ja selle muudatusi
mistahes kolmandatele isikutele ja asutustele.
13.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.
13.8. Tellija võib spetsiaaltarkvara autoriõigusi teostada mistahes olemasolevas või hiljem loodud
keskkonnas, toel või formaadis.
13.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.
13.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
8
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 (v.a. juhul, kui nimetatud komponentide kasutamine oli ette
nähtud Täitja hankepakkumuses).
13.11. Nimetatud õigused kehtivad kogu autoriõiguste kehtivuse aja ja nende kehtivuse
territooriumiks on kogu maailm.
14 Personal
14.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.
14.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:
14.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;
14.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.
14.3. Täitja kannab kõik punktis 14.2 nimetatud asendusest tulenevad või sellega kaasnevad
kulud.
14.4. Töid teostavatel isikutel ei tohi olla kuriteo toimepanemise eest määratud kehtivat karistust.
14.5. Tellijal on õigus kontrollida, kas Töid teostavatel isikutel on kuriteo toimepanemise eest
määratud kehtiv karistus.
14.6. 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.
15 Kolmandad isikud
15.1. Pooled võivad loovutada Lepingust tulenevaid rahalisi nõudeid kolmandatele isikutele.
Pooled on kohustatud teineteist nõude loovutamisest viivitamatult kirjalikult informeerima.
15.2. Pooled ei või oma Lepingujärgseid kohustusi anda üle kolmandale isikule.
15.3. Pooled vastutavad kõigi isikute eest, keda nad kasutavad oma Lepingujärgsete kohustuste
täitmisel.
16 Auditeerimine
16.1. Mõlemal poolel on õigus kaasata auditeerimiseks sõltumatu audiitor.
16.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.
16.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.
16.4. Audiitor käsitleb saadud informatsiooni konfidentsiaalsena.
16.5. Pärast andmete auditeerimist ja kontrollimist teeb audiitor järeldusotsuse, mis on lõplik.
16.6. Auditi kulud kannab auditi tellinud pool.
17 Õigustest loobumine
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.
9
18 Konfidentsiaalsus ja isikuandmed
18.1. Pooled tagavad lepingueelsete läbirääkimiste ja lepingu täitmise käigus teineteiselt ükskõik
mis vormis saadud teabe (sh andmed, isikuandmed, know-how) konfidentsiaalsuse ja ei anna
seda edasi ega võimalda sellele teabele juurdepääsu kolmandatele isikutele ilma teise poole
sellekohase selgesõnalise kirjaliku nõusolekuta.
18.2. Täitja kohustub mitte edastama lepingueelsete läbirääkimiste ja lepingu täitmise käigus
ükskõik mis vormis saadud teavet (sh andmed, isikuandmed, know-how) väljapoole Euroopa
Liidu liikmesriikide ja Euroopa Majandusühendusse kuuluvate riikide territooriumit ilma Tellija
sellekohase selgesõnalise kirjaliku nõusolekuta.
18.3. Täitja kohustub kasutama ja töötlema lepingueelsete läbirääkimiste ja lepingu täitmise käigus
Tellijalt ükskõik mis vormis saadud teavet (andmed, isikuandmed, know-how) ü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.
18.4. Pooled võimaldavad juurdepääsu konfidentsiaalsele teabele ainult nendele isikutele, kellel on
selleks oma tööülesannete täitmiseks vajadus ning tagavad, et need isikud on teadlikud ja
järgivad isikuandmete töötlemisalaseid nõudeid ja õigusakte, nad on saanud asjakohase
koolituse eelnimetatud nõuete kohta, on võtnud endale konfidentsiaalsuskohustuse või neile
kehtib asjakohane seadusest tulenev konfidentsiaalsuskohustus.
18.5. Pooled täidavad kõiki kehtivaid isikuandmete töötlemisalaseid nõudeid, andmete turvalisust
puudutavaid ning isikuandmete kaitse alaseid Euroopa Liidu ja Eesti Vabariigi õigusakte ja
muid eeskirju.
18.6. Täitja kohustub rakendama järgmisi organisatsioonilisi, füüsilisi ja infotehnilisi turvameetmeid
teabe kaitseks juhusliku või tahtliku volitamata muutmise; juhusliku hävimise ja tahtliku
hävitamise eest ning õigustatud isikule andmete kättesaadavuse takistamise eest, volitamata
töötlemise, sh avalikustamise eest:
18.6.1. vältima kõrvaliste isikute ligipääsu isikuandmete töötlemiseks kasutatavatele seadmetele;
18.6.2. ära hoidma andmete omavolilist lugemist, kopeerimist ja muutmist
andmetöötlussüsteemis, samuti andmekandjate omavolilist teisaldamist;
18.6.3. ära hoidma isikuandmete omavolilist salvestamist, muutmist ja kustutamist ning tagama,
et tagantjärele oleks võimalik kindlaks teha, millal, kelle poolt ja milliseid isikuandmeid
salvestati, muudeti või kustutati või millal, kelle poolt ja millistele isikuandmetele
andmetöötlussüsteemis juurdepääs saadi;
18.6.4. tagama, et igal andmetöötlussüsteemi kasutajal oleks juurdepääs ainult temale
töötlemiseks lubatud isikuandmetele ja temale lubatud andmetöötluseks;
18.6.5. tagama andmete olemasolu isikuandmete edastamise kohta: millal, kellele ja milliseid
isikuandmeid edastati, samuti selliste andmete muutusteta säilimise;
18.6.6. tagama, et isikuandmete edastamisel andmesidevahenditega ja andmekandjate
transportimisel ei toimuks isikuandmete omavolilist lugemist, kopeerimist, muutmist või
kustutamist;
18.6.7. pidama arvestust isikuandmete töötlemisel kasutatavate tema kontrolli all olevate
seadmete ja tarkvara üle, dokumenteerides järgmised andmed:
1) seadme nimetus, tüüp ja asukoht ning seadme valmistaja nimi;
2) tarkvara nimetus, versioon, valmistaja nimi ja kontaktandmed.
18.7. Täitja kohustub teavitama Tellijat toimunud või põhjendatult kahtlustatavast punktis 18.1
ja/või 18.2 sätestatud konfidentsiaalsuskohustuse rikkumisest ning punktis 18.6 sätestatud
turvameetmete rikkumisest, mis põhjustab, on põhjustanud või võib põhjustada edastatavate,
salvestatud või muul viisil töödeldavate isikuandmete juhusliku või ebaseadusliku hävitamise,
kaotsimineku, muutmise või loata avalikustamise või neile juurdepääsu, kirjalikku
taasesitamist võimaldavas vormis ilma põhjendamatu viivituseta. Teates tuleb vähemalt:
a) kirjeldada (isikuandmetega seotud) rikkumise laadi, sh 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;
10
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.
18.8. Täitja kohustub Tellija nõudmisel lõpetama punktis 18.7 nimetatud rikkumise ja kohaldama
meetmeid (isikuandmetega seotud) rikkumise lahendamiseks, sh vajaduse korral rikkumise
võimaliku kahjuliku mõju kõrvaldamiseks või leevendamiseks.
18.9. Täitja kohustub lepingu lõppemisel kustutama kõik talle lepingu täitmisel teatavaks saanud
isikuandmed ja nimetatute koopiad 5 päeva jooksul, v. a juhul, kui poolte kokkuleppest või
õigusaktidest tuleneb teisiti.
18.10. Täitja kohustub tegema Tellijale kättesaadavaks kogu teabe, mis on mõistlikult vajalik ja
õigusaktidest tulenevalt kohustuslik käesolevas punktis sätestatud kohustuste täitmise
tõendamiseks.
18.11. Täitja kohustub abistama võimaluse piires asjakohaste tehniliste ja korralduslike meetmete
abil Tellijat täita Tellija kohustust vastata taotlustele andmesubjekti õiguste teostamiseks
ning teostada nende õiguste teostamisest tulenevaid toiminguid (andmete parandamine,
sulgemine, kustutamine).
18.12. Lepingus sätestatud konfidentsiaalsuse nõue ei laiene teabe avaldamisele poolte
audiitoritele ja advokaatidele. Enne teabe avaldamist on pool kohustatud teist poolt
avaldamise kavatsusest teavitama.
18.13. Käesolevas lepingu punktis sätestatud konfidentsiaalsuskohustuse nõue on tähtajatu ning
kehtib nii lepingu täitmise ajal kui ka pärast lepingu lõppemist.
18.14. Tulenevalt konfidentsiaalse informatsiooni laadist on Tellijal õigus seada täiendavaid
nõudeid ja/või juhiseid isikuandmete töötlemiseks.
18.15. Kõik eelnimetatud 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 Täitja.
19 Avalikud suhted
19.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.
19.2. Kõik eelnimetatud kohustused kehtestab Täitja ka kõigile kolmandatele isikutele, keda ta
kasutab oma Lepingujärgsete kohustuste täitmisel.
20 Lepingu täitmise peatamine ja lepingu lõpetamine
20.1. Tellija / Maksja võib peatada Täitjale lepingujärgselt makstavate summade maksmise kas
osaliselt või täielikult, kui:
20.1.1. Täitja ei täida Lepingut;
20.1.2. vastuvõtmise, testimise või auditeerimise käigus avastatakse puudusi või muid Täitja
poolseid kohustuste rikkumisi;
20.1.3. Tellija Lepingu järgsete kohustuste õigeaegset ja korrektset täitmist segab või
ähvardab segada muu asjaolu, mille eest vastutab Täitja.
20.2. Täitja võib peatada Tellijale teenuse osutamise kas osaliselt või täielikult, kui:
20.2.1. Tellija ei täida Lepingut;
20.2.2. Täitja Lepingu järgsete kohustuste õigeaegset ja korrektset täitmist segab või
ähvardab segada muu asjaolu, mille eest vastutab Tellija.
20.3. Tellijal on õigus Leping erakorraliselt etteteatamata lõpetada Täitjapoolse olulise Lepingu
rikkumise korral. Lepingu lõpetamisel punktides 6.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.
11
20.4. 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.
20.5. Lepingu lõppemisel on Täitja kohustatud Tellijale tagastama kõik Lepingu täitmiseks üleantu.
21 Vääramatu jõud
21.1. Vääramatuks jõuks on sõda, mäss, terroriakt, rahutused, loodusõnnetus, transpordi, energia
katkemine või mingi muu mõjult sama oluline ja ebatavaline, pooltest sõltumatu asjaolu.
21.2. Kumbki pool ei vastuta Lepingujärgsete kohustuste mittetäitmise eest vääramatu jõu tõttu, st
tingimuste tõttu, mis on poolte mõistliku kontrolli alt väljas. Pool peab teist poolt selliste
asjaolude saabumisest ja lõppemisest koheselt informeerima. Kui vääramatu jõud kestab
vähemalt 30 kalendripäeva, on mõlemal poolel õigus Leping üles öelda.
22 Kehtiv seadusandlus
Lepingule ning kõikidele Lepingu osaks olevatele dokumentidele kohaldatakse Eesti Vabariigi
õigusakte.
23 Vaidluste lahendamine
23.1. Lepinguga seotud või sellest tulenevate arusaamatuste või vaidluste puhul püüavad pooled
leida lahenduse heal tahtel põhinevate läbirääkimiste teel.
23.2. Kokkuleppe mittesaavutamisel lahendatakse vaidlus Harju Maakohtus.
12
Hankeleping nr 2/138-18
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 kohturegistrite osakonna juhataja
Ingmar Vali (tel: 663 6531, e-post:
[email protected]).
1.2. Tellija kontaktisikuks tööde teostamise juhendamisel ning Täitjale vajaliku lähteinformatsiooni ja
tööülesannete täpsustamisel jmt. on Registrite ja Infosüsteemide Keskuse kultuuripärandi
infosüsteemide talituse juhataja Elis Riispapp (tel: 663 6334, e-post:
[email protected]).
2. Täitja esindaja ja kontaktisikud
2.1 Täitja esindajaks ja kontaktisikuks on Katre Vahtra (tel: 55617828, e-post:
[email protected]).
3. Maksja esindaja ja kontaktisikud
2.2 Maksja esindajaks ja kontaktisikuks on Indrek Reimand (e-post:
[email protected]).
4. Personali nimekiri
4.1. Tellija personal
Nr. Nimi Ametinimetus Kontaktandmed
1 Elis Riispapp Talituse juhataja
[email protected]
4.2. Täitja personal
Nr. Nimi Ametinimetus Kontaktandmed
1 Katre Vahtra Eriprojektide divisjoni juht
[email protected]
4. Kontaktandmed
Tellija kontaktandmed on: Täitja kontaktandmed on: Maksja kontaktandmed on:
Registrite ja Infosüsteemide Keskus Avalanche Laboratory OÜ Kultuuriministeerium
Registrikood: 70000310 Registrikood: 14175080 Registrikood: 70000941
Lõkke tn 4 Toompuiestee 33a Suur-Karja 23,
19081 Tallinn 10149 Tallinn 15076 Tallinn
Telefon: 663 6300 Telefon: 7309 508 Telefon: 628 2222
13
Hankeleping nr 2/138-18
Lisa nr 3
Dokumentatsiooni täpne koosseis määratakse iga tellimuse puhul eraldi.
DOKUMENTATSIOONIPLAAN
1. Täitja poolt Tellijale üle antavad dokumendid
Tellimuse täitmisel annab Täitja Tellijale järgmised dokumendid digitaalsel kujul:
1.1. Süsteemi (muudatuste) ülevaatlik detailne kirjeldus;
1.2. Teenuste/kasutuslugude dokumentatsioon;
1.3. Arhitektuuridokument;
1.4. Seadmete ja tarkvara kasutajakesksed juhendid;
1.5. Administreerimisjuhend/ installatsioonijuhend;
1.6. Testide tulemusena valminud dokumentatsioon (vastuvõtutestid);
1.7. Varundus/taasteplaan;
1.8. Versioonihalduse dokumentatsioon;
1.9. Mittefunktsionaalsete nõuete vastavustabel;
1.10. Andmekogude semantiline kirjeldus ja andmekoosseis.
2. Dokumendid peavad vastama vähemalt alljärgnevatele tingimustele:
2.1. Süsteemi (muudatuste) ülevaatlik detailne kirjeldus
Otstarve: Anda detailne ülevaade süsteemi lisatud/tehtud kesksetest muudatustest,
uuendustest ja nende muudatuste ja uuendustega kaasnevast funktsionaalsusest.
Tegemist on süsteemi terviklikult kirjeldava dokumendiga, mida võib nimetada ka
„süsteemikirjelduseks“ (ja selle komponentidest) kui tervikust süsteemi
funktsionaalsuse seisukohast.
Sisu: Üks ülevaatlik dokument, milles on kajastatud kõik süsteemiga teostatud
muudatused/keskne funktsionaalsus – andmeolemid, andmeolemite seosed ja
atribuudid. Nõuded ja reeglid on süsteemikirjelduses andmeolemite põhised:
1. Uued/lisatud andmeolemid ja nende andmeväljad;
2. Uued/lisatud andmeväljad olemasolevatel andmeolemitel (kui tegemist on
mingi olemasoleva süsteemi laiendamisega);
3. Olemasolevate andmeolemite muudatused – muutunud seosed, muutunud
andmeväljad (kui tegemist on mingi olemasoleva süsteemi laiendamisega);
4. Uute ja/või muutunud andmeolemite funktsionaalsuse kirjeldus:
4.1. nõuded/reeglid andmeolemitele/andmeväljadele, muutunud
andmeolemite puhul tuleb öelda millised reeglid ja nõuded on
edaspidi kehtivad ja millised enam ei kehti;;
14
4.2. vaikekäitumine ja vaikeväärtused;
4.3. uued või muutunud piirangud;
4.4. uued või muutunud tingimused;
4.5. kus ja kuidas andmeolemeid ja nende iga konkreetset välja
üldjuhul kasutatakse (kui esinevad erisused, siis neid peab kas
välja tooma selles samas dokumendis, või viitama
teenustele/kasutuslugudele, kus käitumine on detailiseeritult
kirjeldatud/teistsugune).
5. Üldreeglid süsteemile, mis kehtivad alati, kui mingis spetsiifilises
teenuses/kasutusloos pole öeldud teisiti (kui tegemist on mingi olemasoleva
süsteemi laiendamisega, siis millised üldreeglid tulid juurde, millised
muutusid, millised kaovad);
6. Funktsionaalsuse/muudatuste/täienduste kirjeldus tuleb teha nii
andmevahetuskihi tasandil, domeenikihi tasandil, kui ka andmebaasi tasandil
– sõltuvalt sellest, mitu selgelt eristatud ja omavahel erinevat kihti
konkreetses loodavas/täiendatavas süsteemis parajasti on
7. Muudatuste selgitamiseks on vajalik lisada iga süsteemis eksisteeriva ja
selgelt eristatud kihi kohta pilt – kuidas antud muudatus antud kihis välja
näeb.
Sihtgrupp: Tellija äriprotsesse valdavad kontaktisikud, ärianalüütikud, süsteemianalüütikud,
Täitjast sõltumatud tarkvara hooldajad, arendajad ja edasiarendajad, testijad,
arhitektid, projektijuhid.
Ajakava: Dokument esitatakse Tellijale kinnitamiseks jooksvalt vastavalt projektiplaanile ja
projekti tegevustele.
Dokument on järkjärgult täienev – seega peab olema selgelt eristatud, mis on
pakutud, mis on kinnitatud, mis on implementeeritud. Implementeerida võib ainult
neid muudatusi, mis on eelnevalt kinnitatud.
Täisversioon esitatakse Lepingu lõppemisel – selleks ajaks peab antud dokument
sisaldama kõiki uuendusi/muudatusi arendatava süsteemi kohta.
2.2. Teenuste/kasutuslugude dokumentatsioon
Otstarve: Kirjeldab detailselt üleantavaid teenuseid/kasutuslugusid.
Sisu: Teenuste/kasutuslugude detailse kirjelduse sisuks on Kasutusloo/teenusepõhised
nõuded (ärinõuded ja neile vastavad detailsed funktsionaalsuse nõuded).
1. Nõuete vormistuse juures peab olema välja toodud:
1.1. tekkimise aeg;
1.2. viimase muutmise aeg;
1.3. seis – pakutud/kinnitatud/implementeeritud/tühistatud,
1.4. nõude identifikaator;
15
1.5. nõude autor;
1.6. nõude muutja(d);
1.7. nõude kinnitaja(d);
1.8. nõude tüüp – funktsionaalne, informatiivne, valideeriv, jne.
2. Nõuete tekst peab olema:
2.1. struktureeritud;
2.2. loetav ja selge;
2.3. kindlas kõneviisis;
2.4. täpsete andmeolemite/andmeväljade nimetuste ja mõistetega;
2.5. nõude tekst ei tohi sisaldada teksti sisse integreerimata kommentaare.
3. Kasutajaliidese (kui see on süsteemil olemas) juures:
3.1. kõik kasutajaliidesevormid ja elemendid peavad olema nõuetega kaetud;
3.2. iga vormi jaoks peab olemas olema prototüüp;
3.3. iga vormi/vormi osa eesmärk peab olema selge;
3.4. välja toodud kõik vormiga seotud (ärisisuga) veateated.
4. Nõuete sisus peab selguma:
4.1. Andmeväljade kasutus (nii sisuliste kui tehniliste):
4.1.1. näidatud peavad olema väljade ja kasutatavate andmeolemite täpsed
nimetused;
4.1.2. mis välju kasutatakse, kas on erisusi võrreldes üldreeglitega (mis peavad iga
välja kohta olema süsteemikirjelduses);
4.1.3. kuidas väljade väärtused muutuvad;
4.1.4. millised andmeväljad on kohustuslikud, millised valikulised, milliseid aga antud
teenuses/kasutusloos ainult kuvatakse kuid kasutada ei saa, jne;
4.1.5. kuidas võivad ühed andmeväljad antud teenuses/kasutusloos mõjutada teisi
andmevälju;
4.1.6. lubatud väärtused väljadele just antud teenusest/kasutusloost lähtudes;
4.1.7. kui teenuses/kasutusloos kasutatavate väljade osas erisusi võrreldes
süsteemikirjelduses öelduga pole, siis tuleb see mainida ja anda viide
süsteemikirjelduses olevale;
4.2. Andmete liikumine:
4.2.1. kust ja millised andmed teenusesse/kasutusloosse tulevad;
4.2.2. kes ja millise info teenusesse/kasutusloo vormi/vmt lisab – kas lisab süsteem,
kasutaja, sidussüsteem, jne;
16
4.3. Kuidas andmeid loodavas/muudetavas süsteemis käsitletakse, mis nendega
sisemiselt juhtub – versioneerimine, sünkroniseerimine, võrdlemine;
4.4. Kõik teenuses/kasutusloos teostatavad kontrollid ning nendega seotud
tagastatavad veateated ja/või hoiatused;
4.5. Teenuse/kasutusloo/funktsionaalsuse enda põhiprotsess ja kõik sagedamini
esinevad alternatiivsed protsessid (vastavalt olemasolule ja vajadusele);
4.6. Üldine kirjeldus, kuidas ja kus kajastub antud teenus/kasutuslugu
loodava/muudetava/täiendatava infosüsteemi tervikprotsessis;
4.7. Nõudeid ja reegleid toetavad (sisu mõistmisele kaasaaiatavad) pildid, diagrammid,
tabelid, loendid, prototüübid – kui on selge, et mõnda funktsionaalsust või protsessi
on lihtsam ja selgem kujutada pildina;
4.8. Teenuste puhul XML schema.
Teenuste/kasutuslugude kirjeldus ei pea olema üks dokument – sõltuvalt sellest, kuidas
teenuseid/kasutuslugusid on parajasti mõistlik grupeerida ja kui palju neid on, võib
tegemist olla ka mitme dokumendiga.
Võib teha iga teenuse/kasutusloo kohta eraldi dokumendi.
Sihtgrupp: Tellija äriprotsesse valdavad kontaktisikud, ärianalüütikud, süsteemianalüütikud, Täitjast
sõltumatud tarkvara hooldajad, arendajad ja edasiarendajad, testijad, arhitektid,
projektijuhid.
Ajakava: Dokumendid esitatakse Tellijale kinnitamiseks jooksvalt vastavalt projektiplaanile.
Teenuse/kasutusloo kirjelduse lõppversioon peab olema valmis ja kinnitatud enne, kui
seda hakatakse arendama. Teisisõnu, see ei jäeta projekti lõppu.
Vaheversioonid esitatakse koos üleandmise ja vastuvõtmise aktiga.
2.3. Arhitektuuridokument
Otstarve: Dokumendi eesmärgiks on kirjeldada loodava süsteemi üldist ehitust. Kirjeldatakse
rakenduse loogilist struktuuri, näidates ära selle kihtideks jagunemise korda.
Kirjeldatakse ka füüsilist arhitektuuri, antakse ülevaade kasutatavatest tehnoloogiatest
ning vahenditest.
Sisu: Dokument peab rahuldama vähemalt alljärgnevaid sisunõudeid:
1. topoloogia, süsteemi füüsiline arhitektuur (süsteemi komponendid
andmebaasiserver, rakendusserver, meiliserver jms):
1.1 süsteemi soovituslikud näitajad komponentide kaupa, näiteks
andmesidekiirused, andmemahud, protsessori kiirus, mälumaht, komponentide
arv süsteemi osade kaupa, kettasüsteemi jõudlus jms;
2. liidesed teiste süsteemidega (x-tee, meilisüsteemid) ja sõltuvused teistest
süsteemidest;
17
3. süsteemi tehnilised (sh automaatsed) protsessid ehk töövoog – komponentide
omavahelised suhtlusstsenaariumid ja koostoimimine (näiteks, mis komponent
ja millal pöördub RR teenuse poole);
4. kolmandate osapoolte poolt toodetud kasutatavad tarkvarad/riistvarad, mis on
vajalikud süsteemi toimimiseks.
Sihtgrupp: Arhitekt, administraator, turvaspetsialist
Ajakava: Esialgne versioon esitatakse enne arendustööde algust.
Täisversioon esitatakse lepingu lõppemisel.
Vaheversioon esitatakse koos üleandmise ja vastuvõtmise aktiga.
2.4. Seadmete ja tarkvara kasutajakesksed juhendid
Sisu: Kirjeldus tarkvara ja seadmete kasutamise üldisest protsessist; protsessi olulisemate
sammude kirjeldus.
On aluseks kasutajate koolitamisel.
Kasutajajuhend kirjeldab kõiki kasutajate funktsionaalsusi koos tööprotsesside
kirjeldusega ning ekraanipiltide vormis näidetega.
Haldusliidese kasutusjuhend (halduri funktsionaalsus) peab olema eraldi tavakasutaja
kasutusjuhendist.
Sihtgrupp: Tarkvara kasutajad, haldurid
Ajakava: Vaheversioon (sisaldab sisse viidud muudatusi) tuleb esitada koos üleandmise ja
vastuvõtmise aktiga;
Täisversioon (kogu uuendatud dokument täies mahus) tuleb esitada lepingu lõppemisel.
2.5. Administreerimisjuhend/installatsioonijuhend
Otstarve: Juhend on aluseks süsteemi administreerimisele ja installeerimisele
Sisu: Juhend peab rahuldama vähemalt alljärgnevaid sisunõudeid:
1. süsteemi parameetrite (seadistuste) kirjeldus ning nende muutmiste mõjud
ja protseduurid (näiteks .net rakenduste puhul konfiguratsiooniparameetrite
kirjeldused/selgitused ja näidisväärtused);
2. logimise realisatsiooni kirjeldused (kuhu ja mida, kas kasutatakse roteerimist
või katalogiseerimist jms);
3. rutiinsete hooldusprotseduuride kirjeldus;
4. installeerimispaketi koostamise protseduurid;
5. installeerimisprotseduurid;
6. süsteemi halvamist võimaldavad riskid ja nende esinemise võimalikkus.
Installeerimisjuhendis kirjeldatakse iga realiseeritud osa rakendamine (deployment) koos
spetsiifiliste seadistustega. Installeerimisprotseduurid peavad olema kirjutatud selliselt,
et RIK-i administraator suudab rakenduse installeerida ilma kõrvalise abita.
18
Sihtgrupp: Haldur, projektijuht, administraatorid, arhitekt
Ajakava: Vaheversioon (sisaldab sisse viidud muudatusi) tuleb esitada koos esimese
funktsionaalsuse üleandmisel, kuid mitte hiljem, kui koos üleandmise ja vastuvõtmise
aktiga;
Täisversioon (kogu uuendatud dokument täies mahus) tuleb esitada lepingu lõppemisel.
2.6. Testide tulemusena valminud dokumentatsioon
Otstarve: Testide dokumentatsiooni järgides peab hankijal olema võimalik kontrollida süsteemi
nõuetekohast käitumist
Sisu: Teostatud arenduste testimisel saadud informatsioon (näiteks testlood, testraport,
testiplaan, testide kood jms). Peab vastama tehnilises kirjelduses toodud nõuetele
testimise kohta.
Dokumenteeritakse eesmärgid (testimise maht ja ulatus), tegevused ja tulemused igal
testimisel. Sisaldab jõudlus- ja mahutestide infot ning versiooni infot.
Teste mitteläbinud testlugudele on lisatud parandused või ülesjäänud vead.
Sihtgrupp: Tellijapoolne projektijuht, vastuvõtutestijad
Ajakava: Testide tulemusena valminud dokumentatsioon esitatakse peale süsteemi sisse viidud
arenduste (muudatuste) testimist koos üleandmise ja vastuvõtmise aktiga.
2.7. Varundus/taasteplaan
Otstarve: Tagada süsteemi hävingujärgse kiire ja tõrgeteta taastamise. Taasteplaan on aluseks
süsteemi taastamisele peale suuremat hävingut.
Sisu: Taasteplaan peab rahuldama vähemalt alljärgnevaid sisunõudeid:
1. süsteemi backup’id, varundamisele kuuluvate komponentide ja asukohtade
loetelu (nt rakenduse konfiguratsioonifailid, rakenduse failid failiserveril
paiknevad failid ja andmebaas jne), nende kirjeldused ja kasutuselevõtu
protseduurid (Näiteks: tuua kataloogi (vajadusel faili) tasemel välja list failidest,
mida peab varundama; varunduse järjekord (kui see on oluline);
2. taastamise sammud kasutades installatsiooni juhendit ja varundatud andmeid;
3. süsteemi komponentide asendusvõimalused, nende alternatiivkomponentide
spetsifikatsioonid. Miinimumis peab vastama küsimusele: milline
riistvara/tarkvara on sobiv arendaja arvates (tehtud nt jõudlustestid) seda
süsteemi käitama.
Sihtgrupp: Administraator
Ajakava: Täisversioon (kogu uuendatud dokument täies mahus) tuleb esitada koos esimese
üleandmise ja vastuvõtmise aktiga ja lepingu lõppemisel;
Vaheversioon (sisse viidud muudatuste osas) tuleb esitada taasteplaani muutumisel.
19
2.8. Versioonihalduse dokumentatsioon
Otstarve: Vajalik ülevaate saamiseks infosüsteemi versioonide muudatustest.
Sisu: Detailne info iga versiooniuuenduse kohta - avaldamise kuupäev, versiooni nr,
versiooni olemus (peamine, keskmine, parandus, erakorraline), millised muudatused;
leitud, kuid parandamata vead.
Sihtgrupp: Tellijapoolne projektijuht
Ajakava: Esitatakse iga üleantava versiooniga koos ja versiooni kohta.
2.9. Mittefunktsionaalsete nõuete vastavustabel
Otstarve: Kontrolltabel nii Täitjale kui ka Tellijale veendumaks, et arvestatud on hankes nõutud
nõuetega.
Sisu: Kõik mittefunktsionaalsed nõuded ning täitmismärge. Täitmismärke tegemise aluseks
peab olema testimine. Vajadusel lisatakse selgitused.
Sihtgrupp: Arhitekt, administraator, turvaspetsialist
Ajakava: Esialgne versioon esitatakse enne arendustööde algust.
Täisversioon esitatakse lepingu lõppemisel.
Vaheversioon esitatakse koos üleandmise ja vastuvõtmise aktiga.
2.10. Andmekogude semantiline kirjeldus ja andmekoosseis
Sisu: Andmekogu(de) semantiline kirjeldus masinloetaval kujul (OWL-formaadis) ja
andmekoosseis (XMI-formaadis) vastavalt RIHA määrusega kehtestatud nõuetele ning
infosüsteemi ontoloogiat kirjeldav dokument.
Sihtgrupp: Tellija, Tellijapoolne projektijuht
Ajakava: Täielik versioon (kogu uuendatud dokument täies mahus) tuleb esitada lepingu
lõppemisel.
20
Hankeleping nr 2/138-18
Lisa nr 4
TEHNILINE KIRJELDUS
Tehniline kirjeldus asub Lepingu bdoc konteineris eraldi pdf faili „Tehniline kirjeldus“ (lisa 4) ja tihendatud
(zip) kaustana „Süsteemi dokumentatsioon“ (lisa 4-1)
21
ASUTUSESISESEKS KASUTAMISEKS
03.09.2018.a
Juurdepääsupiirang kehtib kuni
03.09.2023.a.
Alus: AvTS § 35 lg 1 p 17
Hankeleping nr 2/138-18
Lisa nr 4
PAKKUMUS
Pakkumus asub Lepingu bdoc konteineris eraldiseisva bdoc konteinerina.
22
Hankeleping nr 2/138-18
Lisa nr 4
HANKELEPINGU ESEME TEHNILINE KIRJELDUS
Käesolev tehniline kirjeldus koosneb alljärgnevatest dokumentidest:
Lisa 4-1 Tööde teostamise tingimused
Lisa 4-2 Nõuded arendusmeeskonnale
Lisa 4-3 Mittefunktsionaalsed nõuded
Lisa 4-4 Nõuded logimisele
Lisa 4-5 Arendamise tavad ja töökorraldus
Lisa 4-6 Nõuded testimisele
Lisa 4-1
TÖÖDE TEOSTAMISE TINGIMUSED
1.1 Pakkuja peab hankelepingu kehtivuse perioodil pakkuma hankijale kiirreageerimisega
hooldustööde teenust fikseeritud kuutasu ja pakkumuses kajastatud pakkuja poolsete igakuiste
maksimaalsete töötundide põhiselt, sh ka konsultatsiooni, analüüsi. Hankijal on eelarveliste
vahendite olemasolu korral õigus, kuid mitte kohustus, igakuiselt suurendada ning tellida pakkujalt
juurde kiirreageerimisega hooldustööde töötunde juhul, kui maksimaalne töötundide arv on ühes
kuus, mis on pakkuja poolt vormile PAM1 väljatoodud, täitunud. Hankijal on õigus igakuiselt
vastavalt vajadusele suurendada kiirreageerimisega hooldustööde töötundide arvu, mis on
väljatoodud vormil PAM1, kuni 30% ulatuses, kusjuures pakkuja peab lähtuma täiendavalt
tellitavate töötundide hinnastamisel PAM1 vormil välja toodud kiirreageerimisega hooldustööde
töötunni maksumusest. Vastavalt vajadusele on hankijal õigus tellida tarkvara arenduse teenuseid
või muid madalama reageerimiskiirust vajavaid töid väljaspool fikseeritud kuutasu (lisaarendused).
1.2 Kiirreageerimisega hooldustööd (kriisihooldustööd):
1.2.1 Hankija eelarve igakuiselt kiirreageerimisega hooldustööde tellimiseks on 2777,77 eurot (km-
ta). Selle summa eest peab pakkuja tagama maksimaalse arvu töötunde, mis pakkumuses on
esitatud. Eelarveliste vahendite olemasolu korral on hankijal õigus, kuid mitte kohustus,
igakuiselt suurendada (kuni 30%) ulatuses kiirreageerimisega hooldustööde töötundide arvu
juhul kui PAM1 vormil välja toodud maksimaalne töötundide arv on kuulõikes täitunud (vt punkt
1.1)
1.2.2 Hankija annab pakkujale hooldustööde tegemise vajadusest teada kirjalikku taasesitamist
võimaldavas vormis (e-post, Skype, JIRA ticket). Juhul kui hankijaga pole kokkulepitud teisiti,
on pakkuja kohustatud hooldustööd teostama esimesel võimalusel ning andma esmast
tagasisidet juba teostatud tööde kohta hiljemalt järgmiseks tööpäevaks.
1.2.3 Pakkuja peab vajadusel täiendama/muutma dokumentatsiooniplaanis toodud dokumente.
Dokumentide muudatuste/täienduste maksumus peab sisalduma kiirreageerimisega
hooldustööde kuutasus.
1.2.4 Kiirreageerimisega hooldustööde teostamine toimub ainult tööpäeviti ning tööajal.
Nädalavahetustel, riigipühadel ning töövälisel ajal ei ole pakkuja kohustatud kriisihooldustöid
teostama.
1.2.5 Pakkuja peab kaks korda kuus hankijale raporteerima selleks hetkeks kulunud/teostatud
tundide arvust koos teostatud tööde kirjeldusega. Hankija kasutab Jirat.
1.2.6 Juhul kui hankija ei kuluta ära pakkuja pakkumuses välja toodud maksimaalselt igakuist
kriisihooldustööde töötundide arvu, loetakse pärast kalendrikuu lõppemist töötunnid kulutatuks.
1.2.7 Kokkuleppel on võimalik järgmisest kalendrikuust kriisihooldustööde töötunde laenata. Juba
möödunud kuu ülejäänud tunde ei ole võimalik tagant järgi kasutada.
1.2.8 Kriisihooldustööde eest tasumine toimub neljas osas – pakkuja esitab iga kvartali möödudes
hankijale arve. Arve summa on igakuiselt fikseeritud olenemata sellest, kui palju töötunde
kulutamata jäeti. Arve tasujaks on Kultuuriministeerium.
1.3 Lisaarendused:
1.3.1 Tööde tellimiseks esitab hankija pakkujale kirjalikku taasesitamist võimaldavas vormis
pakkumuse tegemise ettepaneku koos tööde kirjeldusega, mille alusel esitab pakkuja hankijale
lisatööde maksumuse hinnangu koos ajagraafikuga.
1.3.2 Pakkuja peab vajadusel täiendama/muutma dokumentatsiooniplaanis toodud dokumente.
Dokumentide muudatuste/täienduste maksumus peab sisalduma lisaarenduste tunnihinnas.
1.4 Pakkuja annab valminud tööd üle hankijale koos tööde üleandmise-vastuvõtmise aktiga. Pärast
hankija poolsete tööde vastuvõtmist esitab pakkuja Kultuuriministeeriumile arve, kes on hankija
poolt tellitud tööde eest tasuja. Vajadusel võib arvete eest tasuda ka Registrite ja Infosüsteemide
Keskus.
2
Lisa 4-2
NÕUDED ARENDUSMEESKONNALE
Pakkuja peab olema võimeline komplekteerima hankelepingu täitmiseks järgmistes punktides märgitud
nõuetele vastava meeskonna. Projektijuht-analüütiku rollid võivad kattuda.
Hankelepingu täitmisel osalev projektijuht peab:
1) Omama töökogemust tarkvara arendusprojektides projektijuhina vähemalt 3 (kolm) aastat;
2) Omama kogemust projektijuhina vähemalt 2 (kahe) üle 40 000 EUR (ilma käibemaksuta) maksumusega
infosüsteemi väljatöötamiseks ja kasutuselevõtmiseks sõlmitud lepingu täitmisel;
3) Valdama eesti keelt väga heal tasemel.
Hankelepingu täitmisel osalev analüütik peab:
1) Omama töökogemust tarkvara arendusprojektides analüütikuna vähemalt 3 (kolm) aastat;
2) Omama kogemust analüütikuna vähemalt 2 (kahe) üle 40 000 EUR (ilma käibemaksuta) maksumusega
infosüsteemi väljatöötamiseks ja kasutuselevõtmiseks sõlmitud lepingu täitmisel;
3) Valdama eesti keelt väga heal tasemel.
Hankelepingu täitmisel osalev süsteemiarhitekt peab:
1) Omama töökogemust tarkvara arendusprojektides arhitektina vähemalt 2 (kaks) aastat;
2) Omama kogemust süsteemiarhitektina vähemalt 2 (kahe) üle 40 000 EUR (ilma käibemaksuta)
maksumusega infosüsteemi väljatöötamiseks ja kasutuselevõtmiseks sõlmitud lepingu täitmisel;
3) Valdama eesti keelt väga heal tasemel.
Hankelepingu täitmisel osalev programmeerija peab:
1) Omama töökogemust tarkvara arendusprojektides programmeerijana vähemalt 1 (üks) aastat;
2) Valdama eesti keelt.
Hankelepingu täitmisel osalev juhtivprogrammeerija peab:
1) Omama töökogemust tarkvara arendusprojektides programmeerijana vähemalt 3 (kolm) aastat;
2) Valdama eesti keelt.
Hankelepingu täitmisel osalev testija peab:
1) Omama töökogemust tarkvara arendusprojektides testijana vähemalt 1 (üks) aasta;
2) Valdama eesti keelt.
3
Lisa 4-3
MITTEFUNKTSIONAALSED NÕUDED
Hankija jätab endale õiguse muuta käesolevas peatükis kirjeldatud nõudeid, sätestades vastavad
muudatused hankelepingu alusel teostatavates tellimustes. Pakkuja peab lähtuma hankelepingute täitmisel
järgnevatest nõuetest, v.a juhul kui hankija on tellimuses märkinud teisti.
Nõu Nõude sisu Seletused
de
nr.
1.2 Lahenduse X-tee teenused peavad vastama https://www.ria.ee/x-tee-juhendid/
RIA nõuetele. Aluseks tuleb võtta hanke
välja kuulutamise hetkel kehtiv versioon.
1.3 Lahendus peab vastama RIK IT-profiilile. http://www.rik.ee/et/asutusest/it-profiil
1.4 Rakendus peab olema kirjutatud arvestades http://www.ria.ee/27220
selle rakenduse poolt töödeldavatele
andmetele määratud ISKE klassi nõudeid
Aluseks tuleb võtta hanke väljakuulutamise
hetkel kehtiv ISKE versioon.
1.6 Rakenduse kasutajaliides peab vastama http://www.w3.org/
vähemalt WCAG 2.0 tasemele AA.
1.7 Veebipõhine kasutajaliides peab ühilduma http://www.w3.org/
täielikult HTML 5 ja CSS 3 standarditega.
1.8 Eesti ID-kaardiga allkirjastamisel on Muud võimalused erikokkuleppel.
eelistatud veebipõhine digidoc-teenuste
kasutamine.
1.9 Rakenduse lähtekood peab olema avatav Ei tohi olla kasutatud piiratud litsentsidega
vastavalt OSOR tingimustele. tarkvara komponente, mis läheksid OSOR
nõuetega vastuollu, kui tellijaga pole eelnevalt
kokku lepitud teisiti.
www.osor.eu
1.10 Rakendus peab olema kirjutatud arvestades https://www.ria.ee/riigiarhitektuur/wiki/doku.ph
RIA Riigi Infosüsteemi mittefunktsionaalseid p?id=mfn
nõuded
2.1 Rakenduse, andmebaasi ja kolmanda
osapoole komponentide
platvorm(id)/versioon(id) peavad olema
sellised, mille eluea lõpp (EOL) pole
teadaolevalt vähem kui 2 aasta pärast.
2.2 Tulevase ja olemasolevate infosüsteemide Süsteemi jõudlus peab vastama kokkulepitud
platvormid (rakendusserver, andmebaas, topoloogial eelanalüüsi ja lähteülesande
kolmanda osapoole komponendid) ja käigus välja toodud jõudlusnäitajatele.
topoloogia peab olema enne reaalse
arenduse algust Infrastruktuuride
osakonnaga kooskõlastatud.
2.3 Rakendusserver peab võimaldama töötamist
andmebaasiserverist eraldi serveril.
4
2.4 Rakendusserver peab olema vajadusel
klasterdatav aktiivklastris (kasutajasessioon
ei tohi olla klastri node põhine).
Sessiooniinfot tuleb hoida andmebaasis
ning seda ei tohi replikeerida
rakendusserverite vahel.
2.5 Rakendust peab saama ilma Lahendus ei tohi olla sisse kompileeritud
ümberprogrammeerimata liigutada erinevate absoluutseid URL-e
domeenide ja domeeni saitide vahel
2.6 Rakenduse äriloogiliselt mittekriitilised Väliste liidestatud süsteemide tõrke korral ei
liidesed peavad olema tõrkekindlad. tohi süsteem hanguda, vaid väljastama
mõistliku (võimalikult lühikese) aja jooksul
ajakohase veateate. Kui vähegi võimalik tuleb
töökindluse tõstmiseks kasutada
asünkroonseid liideseid. Näiteks RR, maa-
ameti infosüsteemi, Google analythicsk´i,
töötamast lakkamisel peab saama süsteemis
tööd jätkata.
2.7 Andmevahetus riigi infosüsteemi kuuluvate Kui X-tee päringut teostab inimene, siis peab
andmekogudega ja riigi infosüsteemi olema päringu päises autentinud kasutaja
kuuluvate andmekogude vahel toimub läbi andmed ja infosüsteemi kood. Kui päringut
riigi infosüsteemi andmevahetuskihi (x-tee). teeb infosüsteem, siis peab päises olema
Avaliku teabe seaduse § 43 (9) lõige 5. infosüsteemi RIHA kood.
2.8 Rakenduse testkeskkonnad peavad olema
ühendatud test X-teega ja
arenduskeskkonnad arendus X-teega.
2.9 Rakenduse konfiguratsiooniparameetrid Rakendus peab neid sealt ka kasutama (mitte
tuleb ühte kohta kokku tuua nii, et nende kopeerima parameetreid käivitamisel
muutmisel ei peaks rakendust uuesti kokku kolmandatesse kohtadesse), logimise seaded
kompileerima (nt ühte tekstipõhisesse võivad olla rakenduse konfiguratsioonifailist
konfiguratsioonifaili, andmebaasi tabelisse). eraldi ühes lisakonfiguratsioonifailis (näit
Log4net).
2.10 Rakenduse kompileerimine (saidi Maksimaalselt 30 sek. Kui rakendus vajab
taaskäivitus, konfiguratsiooni muutmine indekseeritud sisu ja see pole kättesaadav,
vms) peaks toimuma mõistliku aja jooksul. siis peab rakendus väljastama selle kohta
selge teate
2.11 Rakendus peab olema 64-bitine kui ei ole Suund on 64-bitiste rakenduste op
kokku lepitud teisiti. süsteemide kasutamise poole.
2.12 Kui tellijaga kokku lepitud, et rakendus on Suund on 64-bitiste rakenduste op
32-bitine, peab ta olema võimeline töötama süsteemide kasutamise poole.
(testitud) ka 64-bitisel opsüsteemil.
2.13 Andmebaas ja rakendus peavad kasutama Kehtib Oracle ja Postgre andmebaaside
UTF-8 kodeeringut. puhul.
2.14 Failid peab katalogiseerima kokkulepitud Failisüsteemi salvestamisel ei tohi ühte
tunnuste alusel (aasta, kuu, kuupäev). kausta tekkida üle 10000 faili.
2.15 Rakendus peab olema kirjutatud
objektorienteeritult.
2.16 Viidud punkti 2.17 osaks.
5
2.17 Kõik välised võtmed (Foreign Key) peavad Andmebaasis peab kasutama indekseid või
olema indekseeritud. muid meetmeid, et nõuded rakenduse
jõudlusele oleksid täidetud ka tulevikus. (1, 3,
5 või 10 aasta pärast – vastavalt planeeritud
kasutusajale). Väliseid võtmeid tuleb
kasutada ka ühest andmebaasist teisele
viitamisel.
2.18 Tuleb kasutada päringumuutujaid SQL päringute väljakutsumisel väljastpoolt
(Parameter Binding). andmebaasi, peab kasutama
päringumuutujaid, et vältida SQL vahemälu
fragmentseerumist (When calling SQL code
from outside the database, Parameter Binding
should be used to prevent SQL cache
fragmentation)
2.19 Kõigis andmebaasi tabelites peab olema
defineeritud üks primaarvõti ja selle nimetus
peab olema „ID“
2.20 Rakenduse tööks vajalikud andmebaasi Need õigused, mis on vajalikud ainult
objektid ja skeemid luuakse Oracle rakenduse baasi loomiseks, on eraldi välja
andmebaasis rakenduse kasutaja õigustes. toodud ja tuleb peale installi ära võtta. Ei kehti
Objektide loomiseks vajalikud õigused ja MS SQL ja Postgre korral, seal tekitaks see
ressursid on loetletud rakenduse mõttetut keerukust.
dokumentatsioonis.
Failide hoidmise asukoht lepitakse iga kord
kokku. Failide hoidmine klassikalises
andmebaasis on kulukas ja seab kõrgendatud
Failid ja failide indeks peavad olema nõudmised ja piirangud
2.21 replikeeritavad teise serveriruumi. andmebaasiserveritele.
2.22 Peab olema minimiseeritud vajadus, et Halduri haldustoimingud lepitakse tellijaga
haldur teeb haldustoiminguid otse baasis. St kokku detailanalüüsi käigus.
rakendusel peab olema haldusliides, mille
kaudu rakenduse haldur saab teha
tavapäraseid haldustoiminguid.
2.23 Rakendus peab olema võimeline kasutama Näiteks logifailides.
keskkonnamuutujaid (serverinimi, kuu, päev
jne).
2.24 Andmebaas peab toetama nii külm- kui ka Ei tohi kasutada teenuseid, mis välistavad
kuumvaru (peegeldamist) teise serviruumi. andmebaasi peegeldamist (nt "failstream").
2.25 Sorteerimisreeglistik peab olema Eesti Näiteks MS SQL puhul Estonian_CI_AS.
tähestikule vastav. Tõusutundlikkus peab
olema välja lülitatud. Accent peab olema
sisse lülitatud.
2.26 Kui infosüsteemid saadavad elektronkirju,
peavad nad kasutama süsteemivälist RIK-i Kirjade saatmist peab olema võimalik (näiteks
elektronposti serverit. Meiliteavituste tekst muudatuse ajaks) konfiguratsiooni faillist kinni
peab olema haldurite poolt hallatav. Kirja keerata. Kui elektronposti server kirju vastu ei
saatmisel peab rakendus veenduma, et võta, tuleb kirjad ära saata pärast seda kui
elektronposti server võttis meili vastu. elektronposti server jälle vastab.
2.27 Konfiguratsiooniparameetrite nimed peavad Näiteks : X-tee Turvaserver, mitte XTTS või
olema sisulised. Kui see ei ole võimalik, siis viitenumber, mitte vk_seb jne
peab kõrval olema seletus.
6
2.28 Infosüsteemides on eessüsteemid (front Koostöövõime raamistik 2011. Punkt 3.1.
end) ja tagasüsteemid (back end) Tagasüsteemide ülesanneteks on andmete
arhitektuuriliselt selgelt lahutatud. haldamine ja võrguteenuste pakkumine.
Tagasüsteemid ei tegele lõppkasutaja
autentimise ja autoriseerimisega.
Lõppkasutaja autoriseerimise tagavad
eessüsteemid.
2.29 Konfiguratsioonifailid peavad olema Näiteks IIS: *.config , *.resources Apache:
vastavalt rakendusserveri tüübile vaikimisi *.conf, .htaccess. Arendaja peab välja tooma
kaitstud failid konfiguratsioonifailide listi, kui neid on mitu.
2.30 Rakenduse failid, mida kasutaja näha ei Näiteks: IIS: Bin,App_Code, App_Data,
tohi, peavad olema vaikimisi kaitstud App_Browsers, App_GlobalResources,
kaustades. App_LocalResources, App_Themes,
App_WebReferences
2.31 Konfiguratsiooniparameetrite taaskasutus. Kõiki parameetreid tuleks konfiguratsioonis
Erinevaid sama sisuga parameetreid ei tohi kirjeldada vaid korra, mitte nii, et igas lõigus
konfiguratsioonis eksisteerida. kirjeldatakse samu asju uuesti.
2.32 Kõik rakenduse liidesed peavad töötama Rakendustes tohib kasutada vaid
kõrgkäideldavalt. masinapõhiseid teenuseid, mis lubavad
kõrgkäideldavaid (klaster) lahendusi.
Kõrgkäideldav lahendus on selline, mida saab
samaaegselt käitada erinevates masinates.
2.33 Tuleb kasutada rakendusservereid. Klientrakendus ei tohi pöörduda otse
andmebaasi poole.
2.34 Viidud punkti 2.6 koosseisu.
2.35 Keskkonnapõhiseid muutujad peavad olema Näiteks WSDL ei tohi sisaldada viiteid
konfiguratsioonifailist seadistatavad. arendusserveritele.
2.37 Rakendus ei tohi kasutada meetodeid, mis .NET rakenduste puhul on suund shared
välistavad shared hostingu kasutamise. hostingu kasutamise suunas.
2.38 Rakenduse äriloogika tuleb realiseerida Andmebaas ei tohi sisaldada äriloogikat, mis
eraldi andmebaasist sõltumatus muudab andmetabelites olevaid/sinna
rakenduskihis. kirjutatavaid andmeid ,v.a trigerid, mis
tekitavad logi.
2.39 Andmebaasis võib kasutada vaid ISO/IEC *Ei ole soovitav kasutada mingit
9075 standardiga kaetud funktsionaalsusi. platvormispetsiifilist lahendust, mille
Lisaks ei tohi kasutada ka sama standardi üleviimine mõnele muule
osas 13 kirjeldatud funktsionaalsusi. andmebaasiplatvormile ei ole võimalik.
*ISO/IEC 9075 osa 13 spetsifitseerib Javas
kirjutatud programmimoodulite kasutamist
andmebaasis.
2.40 Rakendus peab kasutama autentimiseks Suund on keskse autentimislahenduse poole.
RIK autentimisportaali AUP. Kui mingi ärinõue välistab AUP kasutamise
esitab RIK arendajale lisanõuded
autentimissüsteemile.
2.41 Uniform resource identifier (URI) pikkus ei
tohi ületada ühegi IS poolt toetatava
brauseri maksimaalset lubatud väärtust.
2.42 SOAP teenuseid pakkuva rakenduse WSDL Näiteks: Alajaotis definitions/types/schema:
peab olema üles ehitatud nii, et see toetaks * complexType defineerimisel tuleb sellele
teenuste versioneerimist. lisada any element.
7
2.44 Rakenduse operatiivbaas tuleb hoida
võimalikult väike. Suurte andmemahtude
korral, kui äriprotsess seda võimaldab, tuleb
kasutada andmete arhiveerimist väljapoole
põhibaasi.
2.46 Rakendusega tarnitavad litsentsid peavad EU projektide korral tuleb selle asemel
olema vähemalt 5 aastase kehtivusega. lähtuda EU/RIA nõuetest.
2.47 Rakenduses peavad olema eraldatud Käideldavuse, seadistuse ja turvanõuded on
teenused, kuhu pöörduvad kasutajad, erinevad
teenustest kuhu pöörduvad teised
teenused/serverid (näiteks eraldi saidid).
2.48 Kõik dokumentide konverteerimised ühest
formaadist teise tuleb teha kasutades RIK
keskseid dokumentide konverteerimise
teenuseid.
2.49 Faili asukohta (path) süsteemis ei tohi
edastada kliendi poolele
2.50 Rakendus peab olema võimeline töötama SSL offload, vajalike kliendiparameetrite
koormusjaoturitega varustatud taristul. edasiandmine kasutades http headereid.
2.51 Rakenduse failidele ei tohi olla rohkem
ligipääsuvajadust kui read-execute
2.52 Rakendus peab võimaldama kasutajate
inventuuri vastavalt tellija poolt ette antud
metateenuste kirjeldusele (käesoleva korra
lisa).
2.52 Rakendus peab võimaldama kasutajate
inventuuri vastavalt tellija poolt ette antud
metateenuste kirjeldusele (käesoleva korra
lisa).
3.2 Kliendi ja serveri vahel peab autenditud Välisvõrgus peab kasutama HTTPS-protokolli,
kasutajasessioonide korral olema sessioon kui ISKE konfidentsiaalsus või terviklusklass
krüpteeritud HTTPS-protokolli kasutades. on 1 või kõrgem. Sisevõrgus peab kasutama
HTTPS-protokolli kui andmete ISKE
konfidentsiaalsus või terviklusklass on 2 või
kõrgem.
3.3 Rakendus tohib kasutada vaid sessiooni Sessiooni lõpetamine infosüsteemis (logi välja
küpsiseid. Muude küpsiste kasutamine on nupu vajutamine), peab IS-i poolt sessiooni
keelatud. tunnused (näiteks küpsised) kehtetuks
tunnistama.
3.4 Kui andmebaasis olevate andmete ISKE St kõik andmemuudatused peavad baasis
tervikluse klass on 2 või kõrgem, siis tuleb säilima. Andmete muutmisel andmeid ei
kõik klass 2 infot sisaldavad andmebaasi kustutata, vaid tehakse uus kirje uute
kirjed/tabelid versioneerida. andmetega. Vana muudetakse kehtetuks. Iga
uus kirje peab sisaldama järgmist
informatsiooni: *viide kirjele, mille ta kehtetuks
muutis (kui on) *kasutaja, kes kirje lõi *kirje
loomise aeg *sessiooni-ID (kui on olemas).
Iga kehtetuks tunnistatud kirje peab omama
järgmist informatsiooni: *kasutaja, kes kirje
kehtetuks tunnistas *kirje kehtetuks
tunnistamise aeg.
8
3.5 Kui rakenduse poolt töödeldavate andmete Testandmed peavad säilitama kõik toodangu
konfidentsiaalsusklass on 2 või kõrgem, andmete omadused (pikkuse, tüübi) ja
peab rakendusega kaasas olema lahendus, omavahelised suhted. Toodanguandmetest
mis suudab toota toodangu andmetest testandmete tegemise algoritmid ja
testandmed, mis ei sisalda konfidentsiaalset põhimõtted tuleb eelnevalt kooskõlastada
informatsiooni. tellijaga.
3.6 Andmebaasis olevate rakenduse kontod Ei resource, dba, ANY ega muud sellist.
peavad omama ainult minimaalselt Nõude täitmiseks vajalikud vahendid (skriptid)
rakenduse tööks vajalikke õiguseid. peavad kuuluma rakenduse juurde ja nende
sisu peab olema kontrollitav. Kontodele
vajalikud õigused peavad olema kirjeldatud
rakenduse installimisjuhendis.
3.7 Rakenduse lõppkasutajatele peab olema Rakendusepõhiseid kasutajarolle ei tohi
võimalik jagada õigusi läbi andmebaasis defineerida ainult läbi AD OU'de ja gruppide.
defineeritud rollide.
3.8 Rakendusse ja andmetele tohib olla ligipääs St rakendustes ega andmebaasides ei tohi
vaid dokumenteeritud ja tellimuses olla ligipääsemiseks teisi võimalusi.
kirjeldatud teid mööda ning dokumenteeritud
autentimisprotseduure kasutades.
3.9 Kõik paroolid ja salasõnad peab rakendus Räsimine peab kasutama turvalist
alati salvestama vaid krüpteeritud või räsifunktsiooni (vt nõue 3.18) ja soola (salt).
räsitud+soolatud kujul. Sool peab olema andmebaasiüleselt
unikaalne, piisavalt suure bitiarvuga ja
random. Krüpteerimata kujul ei tohi paroole
salvestada (ka ajutiselt) ühelegi kettale.
Krüpteering peab olema CBC, CRT vms
režiimis. Kindlasti ei tohi kasutada ECB
režiimi. Kooskõlastatavas lahenduse
kirjeklduses peavad olema ära toodud
kasutatavad räsi ja krüptoalgoritmid,
võtmepikkused ja nende kasutuskohad.
3.10 Rakendused, kuhu saavad ligi välised Kui on vajalik ka parooliga logimine, peavad
kasutajad, peavad võimaldama ID-kaardiga välised kasutajad autentima ennast
sisselogimist. spetsiaalse väliskasutajate jaoks mõeldud AD
pihta. Mingil juhul ei tohi väliskasutajaid teha
RIK-i sisemisse AD-sse.
3.11 Rakendus ei tohi teostada X-tee päringut Kasutajaarvutitest otse x-tee päringute
otse kasutajaarvutist. tegemine on arvutivõrgu tasemel kinni.
3.12 Veebipõhised välise veebilehega IIS puhul peab kasutama näiteks URL scan,
rakendused, mis on keskmise või kõrgema apache puhul modsecurity või vastavat
ISKE klassiga peavad kasutama vahendeid tööriista. Võimalikud piirangud tuleb kokku
kaitsmaks rakendust keelatud päringute leppida tellijaga detailanalüüsi käigus lähtuvalt
eest. tellija vajadustest ja nõudmistest. Kasutama
peab whitelisting põhimõtet, mitte blacklisting.
3.13 Kui rakenduse mõni ISKE klass on 2 või Kasutaja peab saama soovi korral veenduda,
kõrgem, peab rakendus sisenemisel kas keegi pole tema nime all vahepeal sisse
näitama pärast õnnestunud sisselogimist loginud. ID-kaardi, mobiil-ID ja digi-ID-ga
eelmise õnnestunud sisselogimise aega. Kui sisenemise ürituse ebaõnnestunud katseid
on toimunud ebaõnnestunud sisselogimise näitama ei pea.
katseid, siis peab kuvama ka, millal need
toimusid ja mitu neid oli.
9
3.14 Rakenduse kasutajaliidesest peab olema Mõeldud on spetsiaalrakendusi (custom built).
kasutajal avalehel ilma sisse logimiseta Ei kehti veebitarkvara (apache, IIS jne),
võimalik näha rakenduse versiooni numbrit. andmebaaside jms kohta. Nende versiooni
tuleb pigem varjata.
Aeg peab olema muudetav koos teiste
Sessioonide lõpetamine tuleb teostada konfiguratsiooniparameetritega. Kui kliendilt
serveri poolel ja kõigil rakendustel peab pole etteantud aja jooksul ühtegi päringut
olema konfigureeritav kasutajasessiooni tulnud, tuleb sessioon serveri enda algatusel
3.15 aegumise aeg. lõpetada.
3.16 Veebipõhiste rakenduste mitteautentinud Soovitatavalt enne andmebaasi salvestamist,
kasutajate poolt saadetud vormid tuleb vajadusel andmete väljakuvamisel.
puhastada XSS-filtriga või eemaldada
HTML-tag´id.
3.17 Veebipõhiste rakenduste poolt saadetavad Vältimaks CSRF rünnakuid.
vormidel peab paiknema peidetud unikaalne
räsi, mida kontrollitakse vormi vastuvõtmisel.
3.18 Krüpteerimise ja/või räside arvutamise korral Vastavalt AES-256, RSA-2048, SHA-2,
tuleb kasutada tugevaid algoritme. Blowfish-256 või tugevamaid milles pole leitud
teadaolevaid turvanõrkuseid. Süsteemi
kirjelduses tuleb välja tuua kõik
krüptoalgoritmid, võtmepikkused ja
kasutuskohad. Vt. RIA krüptoprotokollide
uuring:
https://www.ria.ee/public/PKI/kruptograafiliste
_algoritmide_elutsukli_uuring_II.pdf
3.19 Autenditud sessiooni tunnust ei tohi ainult Sessiooni ei tohi olla võimalik üle võtta
lihtsa küpsisega lahendada. sessioonitunnuse kopeerimisega ühest
arvutist teise.
3.21 Tagada tuleb rollide lahusus. Halduritel ei Administraatoril ja halduril on erinevad
tohi olla võimalik muuta ega näha rakenduse tööülesanded.
konfiguratsiooni.
3.22 ID-kaardiga autentimisel, peab rakendus Proxy tugi
suutma vastu võtta ID-kaardi sertifikaati ka
HTTP päises.
3.24 Rakenduste sisselogimisvormidel ei tohi
salvestada (meelde jätta) kasutajainfot.
3.26 Kõik digitembeldamist vajavad rakendused
. peavad kasutama RIK-i-keskset
digitembeldamise teenust.
Esmane väline turvatestimine tellitakse tellija
finantseeringul. Kui selle tulemusel leitakse
arendaja poolsest tegevusest või
tegvusetusest põhjustatud vigu, võib tellija
nõuda OWASP järeltestide kompenseerimist
arendajalt. Kui pole eraldi kokku lepitud teisiti,
Rakenduse turvalisuse tagamiseks (näiteks siis on tellitava testi tasemeks OWASP ASVS
XSS, SQLInjection jne) tuleb järgida v2.0 (2014) järgi tase 2.
OWASP-i parimaid praktikaid. https://www.owasp.org/index.php/Category:O
Veebirakendus peab probleemideta läbima WASP_Application_Security_Verification_Sta
3.26 OWASP ASVS baasil põhineva testi ndard_Project
10
3.27 Arendus peab olema orienteeritud Toodangukeskkonna rakendus ei tohi
toodangukeskkonnas toimimiseks. sisaldada osiseid, mis on toodangu
keskkonnas ebavajalikud või segavad
(näiteks mõeldud testimiseks testkeskkonnas,
arendusabiks arenduskeskkonnas jne).
3.28 Ajatemplite kasutamisel eelistatakse Ajatempli serveri URL peab olema
Guardtime lahendust. konfigureeritav.
3.29 Rakendus ei tohi lubada ühe kasutajaga Juhul kui lähteülesanne ei ütle teisiti.
mitut samaaegset sessiooni.
Milline lahendus valitakse tuleb kokku leppida
tellijaga. Täpsustuseks vt ISKE nõue HT.34.
Antavate ajatemplite, digitemplite ja
digitaalallkirjade terviklus tuleb reaalajas ja
hiljem perioodiliselt (muudetava perioodiga)
kontrollida ja anda häire kui terviklus on
Kui rakenduse tervikluse klass on 3 (T3) kompromiteeritud. Kui tembeldamises või
peavad tõestusväärtust omavad andmed allkirjastamises ilmneb viga, peab olema
olema kas ajatembeldatud, võimalik hiljem katkenud kohast tembeldamist
3.30 digitaalallkirjastatud või digitembeldatud. või allkirjastamist jätkata.
Ahela moodustamiseks ei tohi kasutada
andmetesse kirjapandud viiteid (n: id=2;
andmed="mingid andmed",
eelmine_andmed=1 ). Krüptoahela
koostamisel tuleb kasutada lahendust, kus
järgmise ajatembeldatava kirje koosseisu
pannakse eelmise kirje mitte ajatembeldatud
räsi. Uue ahela lüli panemisel tuleb kontrollida
eelmise lüli korrektsust. Peab olema tagatud
Kui rakenduse tervikluse klass on T3 ka, et kirjeid ei saaks märkamatult kustutada
peavad tõestusväärtust omavad andmed ahela lõpust. Krüptoahela terviklust peab
olema krüptoaheldatud, et tagada et saama perioodiliselt (muudetava perioodiga)
tõestusväärtusega andmeid ei saaks kontrollida ja anda häire kui terviklus on
3.31 märkamatult kustutada. kompromiteeritud.
3.32 Kui rakenduses on S3 salastatuse astmega Sümmeetrilise võtme turvamiseks tuleb
andmeid, peavad need olema nii transpordi kasutada asümmeetrilisi algoritme. Sertifikaati
ajal ja ka salvestatult alati krüpteeritult. tuleb hoida nii, et see oleks kättesaadav
rakendusele, kuid mitte rakendusserverit
administreerivale isikule. Sertifikaat peab
olema vahetatav, st krüptograafia
edasiarenedes peab olema võimalik
kasutusele võtta tugevam sertifikaat.
3.33 Kui paks klient kasutab ajutisi faile, tuleb
Paksu kliendi korral ei tohi rakendus tagada nende perioodiline kustutamine
kasutaja tööjaama jätta maha krüpteerimata tagamaks, et ei koormata liigselt kasutaja
kujul ajutisi faile, mis sisaldavad või võivad arvutit. Nõude eesmärk on tagada, et
sisaldada konfidentsiaalse või kõrget rakenduse sulgemisel ei jääks kasutaja
terviklust nõudvat informatsiooni. arvutisse maha informatsiooni mida sinna
jääda ei tohiks.
3.34 Rakendus peab serverist kustutama kõik
ajutised failid koheselt, kui neid enam ei
kasutata.
11
Rakendus tohib aktsepteerida vaid
sessioonivõtmeid, mida ta ise on
väljastanud. Sisselogimisel peab kasutaja
saama uue sessiooni võtme ning endine võti
3.35 tuleb kehtetuks tunnistada.
Kui rakendusse laetakse faile väliskasutaja Faili nimes tuleks lubada vaid suur- ja
(mitte tellija haldusala kasutaja) poolt, peab väiketähti, numbreid, _ ja - ning vaid ühte
kontrollima faili tüüpi ja failid peavad läbima punkti järjest. Viirusetõrje lahenduse pakub
3.36 viirusetõrje. välja RIK infrastruktuuride osakond..
3.37 Kui rakendusse laetakse faile väliskasutaja
(mitte tellija haldusala kasutaja) poolt, siis
peab faili nimi salvestamisel sisaldama
random komponenti nii, et faili tee ei ole
lihtsalt ära arvatav.
Testlehe kättesaadavus (mis võrgust) peab
olema konfigureeritav. Testleht peab
uuendama ennast lehe pärimisel. Testleht
peab sisaldama rakenduse versiooni numbrit
ning infot rakenduse (vajadusel tema
erinevate osade) ja tema kõigi väliste liideste
staatuse kohta (töötab, ei tööta). Rakenduse,
andmebaasi ja liideste töökorda kontrollitakse
testpäringute teel, mis tuleb tellijaga kokku
leppida. Testleht peab oma konfiguratsiooni
võtma rakenduse üldisest konfiguratsioonist
(baasistring, välised ühendused).
Testlehe reeglistik konfiguratsioonihalduse
põhjal: Nimi - status.xml;
baasikirje -
<uri>baasinimi@server/instance</uri>
rakendusekirje -
Rakendusel peab olema masinloetav XML- <uri>http(s)://aadress.just.sise/</uri>;
testleht, mille struktuur vastab tellija poolt xteekirje -
ette antud XML struktuurile (käesoleva <uri>xteelühinimi@http(s)://turvaserveriip</uri
4.1 dokumendi lisa). >;
4.2 Rakenduse kõik üleantavad versioonid Testplaan ja testitulemused tuleb edastada
peavad enne tellijale üle andmist olema tellijale koos rakenduse üleandmisega.
testitud. Nõuded testimisele RIK dokumendis
Arendamise tavad ja töökorraldus.
Logida ei tohi sessiooni võtme väärtust,
privaatvõtmeid ega kasutaja salasõnu
Rakendus peab logima sessiooni algamise tekstilisel kujul. Vastav logi peab asuma
ja lõppemise. Väliste rakenduse puhul ka teistest logidest eraldi spetsiaalses turvalogi
4.3 võimalusel kasutaja IP tabelis.
4.4 Rakendus peab suutma logida kõiki välja ja Vajalik eelkõige silumiseks ja toodangu
sisse tulevaid (ka X-tee teenuste kaudu keskkonna probleemide lahendamiseks.
liikuvaid) päringuid. Peab olema võimalus Vastav logi peab asuma teistest logidest
logimist sisse-välja lülitada. eraldi spetsiaalses silumislogi tabelis või failis.
12
4.5 Kui rakenduse ISKE konfidentsiaalsus klass Logi peab sisaldama (toodud järjekorras)
on 2 või kõrgem, peab rakendus logima kõiki Millal tehti, kasutaja ID ja isikukood (firma
konfidentsiaalsus klassiga 2 või kõrgemate registrikood), kui võimalik kust tehti (seadme
andmete loomist, muutmist (sh kustutamist) nimi, IP, serifikaat), mis tegevused
ja vaatamist. andmetega teht ja kas tegevus õnnestus. Kui
võimalik siis päringu SQL lause. Logida peab
olema võimalik ka konkreetsed andmed mida
kasutaja serveri arvates nägi. Viimane peab
aga olema välja lülitatav või asendatava
põhiobjektide ID-dega. Logida tuleb ka
kasutajate tegevuste ebaõnnestumised.
Näiteks õiguste puudumise tõttu. Vastav logi
peab asuma tegevuslogi andmebaasi tabelis.
4.6 Kui rakenduse ISKE tervikluse klass on 2 või Logi peab sisaldama (toodud järjekorras)
kõrgem peab rakendus logima kõiki Millal tehti, kasutaja ID ja isikukood (firma
tervikluse klassiga 2 andmete loomist ja registrikood), kui võimalik kust tehti (seadme
muutmist (sh kustutamist). nimi, IP, sertifikaat), mis tegevused
andmetega teht ja kas tegevus õnnestus. Kui
võimalik siis päringu SQL lause. Logida tuleb
ka kasutajate tegevuste ebaõnnestumised.
Näiteks õiguste puudumise tõttu. Vastav logi
peab asuma tegevuslogi andmbaais tabelis.
4.7 Kui rakenduse andmete Lahendus peab tagama, et
konfidentsiaalsusklass on 3, siis ka kõiki administraatorid/haldurid ei saa andmete
administraatorite ja haldurite poolt tehtavaid vaatamise logimist ise (ka tavakasutajate
andmete vaatamised (ka otse baasis) tuleb logimist) kinni keerata või logisid
logida. kustutada/muuta. Võib tellijaga kokku leppel
nõudest loobuda kui andmed on krüpteeritud.
4.8 Kui rakenduse andmete terviklusklass on 3 Lahendus peab tagama, et
siis ka kõiki administraatorite ja haldurite administraatorid/haldurid ei saa andmete
poolt tehtavaid andmete muudatused (ka muutmise logimist ise (ka tavakasutajate
otse baasis) tuleb logida. logimist) kinni keerata või logisid
kustutada/muuta. Tellijaga kokkuleppel võib
nõudest loobuda, kui andmed on kaitstud
digiallkirja, digitempli või välise osapoole
ajatempliga.
4.10 Rakendusega peab olema kaasas skript Jõudlustestide täpne kirjeldus tuleb kokku
jõudlustestide tegemiseks. leppida detailanalüüsi käigus. Arendaja peab
koos rakendusega tarnima skripti ja vajalikud
tarkvaralised vahendid kokkulepitud
jõudlustestide läbiviimiseks. Jõudlustestide
läbiviimine ei tohi nõuda tellijalt omapoolset
tarkvara arendamist, skriptide kirjutamist või
litsentside ostmist.
4.11 Rakendus peab logima kõiki rakenduses Vea logid peavad asuma teistest logidest
tekkivaid tehnilisi vigu. eraldi failis/tabelis. Logi peab sisaldama
minimaalselt (toodud järjekorras) vea
tekkimise aega, veakoodi, veakirjeldust (stack
trace, traceback vms), võimalusel kasutaja
andmeid (nimi, ID, IP ja URL), HTTP-, GET-
ja POST-parameetrid ja nende väärtusi.
13
4.12 Vea ja turvalogid peavad olema Logi peab olema lihtsalt masintöödeldav.
andmebaasis ja dubleeritud tekstifaili. Näiteks XML, CSV. Peab olema kirjeldatud
milline on logi struktuur.
4.13 Failisüsteemi logimise korral peavad logid Ei tohi esinda olukorda, kus ühte kausta tekib
olema ka katalogiseeritud (näiteks liigi järgi) rohkem kui 10000 faili.
ja üldtunnustatud faililaiendiga (näiteks .log,
.txt, .xml), logi peab olema roteeruv, et ei
tekiks liiga suuri faile. Logifailide
seadistamisel peab olema
failinime/kaustatee nimedes võimalik
kasutada keskkonnamuutujaid (kuupäev,
masinanimi jne).
4.14 Logi tabelid peavad olema arhiveeritavad Ka krüptoaheldatud logi korral.
operatiivbaasist välja.
Kui ühe päringu tõttu tekib kirjeid mitmesse
logisse, peab olema võimalik neid kirjeid
ühise välja abil siduda unikaalne päringu id-ga
.Sama infot sisaldavad väljad peavad (ka
erinevates) logitabelites olema sama nimega
ja andmed samas formaadis. Kui parameetri
väärtus on tühi, tuleb see logis märkida
Kogu rakenduse logi peab olema ühesuguse asendusväärtusega (nt. “null”). Kui vähegi
formaadiga, kergesti masinloetav ja täielik võimalik peab logi kuupäeva ja ajaformaat
(kes, mis, mida, jms), logis ei tohi kasutada olema kujul "PP.TT.AAAA TT:MM:SS.UUU“
4.15 klassifikaatoreid. lokaalne Eesti ajavöönd.
Kui rakendus kasutab või pakub teenuseid
(näiteks SK teenuseid) peab ta suutma Näiteks kui palju on kasutatud kuus/aastas
arvestust pidada vastavate teenuste digitembeldamist, ID-autentimist,
4.16 kasutamise mahu üle. autentimisportaali, pangalingi kasutamist jne.
4.17 Veebirakendus ei tohi jätta sulgemisel
kasutaja tööjaama maha ajutisi faile, mis
sisaldavad mitteavalikke andmeid.
5.1 Lähtekoodi kommentaarid peavad kõigis NB! Nõuet ei arvestata arendustarkvara poolt
lahenduse kihtides (rakenduse enda kood, automaatselt genereeritavate koodilõikude
andmebaas, jne) olema kirjutatud eesti puhul – neid ei ole vaja tõlkida. Samuti ei
keeles. rakendata nõuet kolmandate osapoolte poolt
toodetud lähtekoodile – nt:igasugu erinevad
lahtise koodiga koodijupid jms
5.2 Lähtekoodi kommentaarid peavad olema Rakenduse kood peab olema piisavalt hästi
selged, arusaadavad ja sisuliselt kirjeldama kommenteeritud, et erialast haridust omav
vastavat koodi, mille juures nad on ning tarkvaraarendaja on võimeline süsteemile
moodustama vähemalt 20% koodi mahust. jätkuarendusi teostama.
5.3 Muutujate, tüüpide ja funktsioonide nimed
peavad olema sisulised ja andma aimu
nende otstarbest.
5.4 Koodis kasutatavad konstandid ja lühendid Näiteks: Identifikaator -->ID
tuleb kirjutada suurte tähtedega.
14
5.5 Koodis kasutatavaid konstante ei tohi selle
kasutamise kohta väärtusena hardcodeda –
need tuleb defineerida muutujatena ja
kasutada läbi nende.
5.6 Koodis defineeritud andmetüübid peavad N:Isik; Menetlus; jne. Andmebaasides ei tohi
olema nimetava käände ainsuses. Kõik kasutada täpitähti.
andmemassiivid tuleb nimetada nimetava
mitmuses (st igasugu collectionid, arrayd,
jms).
5.7 Andmetabelites sisalduvad võõrvõtmed N: Kui on tegu tabelitega ’Isikud’ ja ’Autod’,
peavad nime järgi seostuma tabeli ja väljaga siis seos ’isiku autod’ oleks:
millele need viitavad. Isikud.ID=Autod.Isik_ID
5.8 Andmebaasi väljade pikkused tuleb Selle asemel, et eraldada väljale x baiti, tuleb
kirjeldada sümbolites, mitte baitides. eraldada x tähemärki. (Instead of allocating x
bytes of storage for the field, x chars of
storage must be allocated).
5.9 Kui kokku pole lepitud teisiti, siis JAVA
rakenduse kood peab olema kirjutatud
http://java.sun.com/docs/codeconv/
vastavalt "SUN Java Code convention"
Valideerimiseks kasutatakse 'checkstyle'
dokumendile. vaikimisi konfiguratsiooni
5.10 Kui kokku pole lepitud teisiti, siis Python http://www.python.org/dev/peps/pep-0008/
rakenduse kood peab olema kirjutatud
vastavalt "Style Guide for Python Code "
dokumendile
5.11 Kui kokku pole lepitud teisiti, siis .NET
rakenduse kood peab olema kirjutatud
http://msdn.microsoft.com/en-
vastavalt "NET Framework Developer's
us/library/ms229042.aspx Valideerimiseks
Guide - Design Guidelines for Developing
kasutatakse 'StyleCop' vaikimisi
Class Libraries".
konfiguratsiooni
1. PMD(http://pmd.sourceforge.net)
2.
DocCheck(http://java.sun.com/j2se/javadoc/d
occheck/) või muud võrreldavat kokkulepitud
5.12 JAVA koodi valideerimiseks kasutatakse: validaatorit.
FxCop(http://msdn.microsoft.com/en-
us/library/bb429476.aspx) või muud
5.13 .NET koodi valideerimiseks kasutatakse: võrreldavat kokkulepitud validaatorit.
Pychecker(http://pychecker.sourceforge.net/)
või muud võrreldavat kokkulepitud
5.14 Pythoni koodi valideerimiseks kasutatakse: validaatorit.
Kasutuses mitteolev kood tuleb rakenduse
5.15 lähtekoodist kõrvaldada.
Andmebaasi tabelid ja väljad ning muu kood
(stored procid, funktsioonid, triggerid, viewd,
user defined data types ja sequencid) peab
olema kommenteeritud rakenduse koodiga
5.16 samadel alustel. Selged, arusaadavad, jne.
15
N:Mitte Dossier vaid Toimik; mitte Person vaid
Isik.
NB! Nõuet ei arvestata arendustarkvara poolt
Lähtekoodis defineeritud muutujate, automaatselt genereeritavate koodilõikude
klasside/tabelite, meetodite jms. nimed puhul – neid ei ole vaja tõlkida. Samuti ei
peavad lahenduse kõigis kihtides rakendata nõuet kolmandate osapoolte poolt
(rakenduse enda kood, andmebaas, jne) toodetud lähtekoodile – nt:igasugu erinevad
5.17 olema eesti keelsed. lahtise koodiga koodijupid jms
6.1 Aadressiandmete sisestamisel, kuvamisel ja Liidestatakse maa-ameti X-tee teenusega või
hoidmisel tuleb lähtuda Vabariigi Valitsuse RIK sisemise vastava maa-ameti andmeid
20. detsembri 2007. a määrusest nr 251 vahendava süsteemiga.
"Aadressiandmete süsteem".
6.2 Rakendus peab võimalikult palju
informatsiooni eeltäitma automaatselt (kirje
sisestamise kuupäev, kasutaja nimi jne).
Numbriväljale tohib sisestada vaid numbreid,
kuupäeva väljale kuupäeva, elektronposti
Andmete sisestamisel peab rakendus alati aadressi vilajale elektronposti aadressi,
kontrollima, kas sisestatav tekst vastab välja valikväärtuste korral vaid lubatud
tüübile ja/või etteantud valikväärtustele. valikväärtused jne. Sisendi kontrolli
Sobimatut teksti ei tohi olla võimalik ebaõnnestumise korral tuleb peatada sisendi
6.3 sisestada. kasutamine ja kasutajat sellest teavitada.
6.4 Tegevusalade andmete sisestamisel, Liidestatakse RIK EMTAK infosüsteemi
kuvamisel ja hoidmisel tuleb teenusega.
lähtuda Vabariigi Valitsuse 10. Jaanuari
2008. a määrusest nr 11 "Klassifikaatorite
süsteem" ja kasutada EMTAK infosüsteemis
kehtivat klassifikaatorit.
6.5 Kasutaja poolt sisestatud andmed tuleb
enne välja kuvamist filtreerida. Kasutada
tuleks võimalusel Blacklistingu asemel
whitelistingut.
7.1 Kasutajaliidese kõik disainiotsused peavad
olema kooskõlastatud tellijaga enne nende
realiseerimist.
7.2 Veebipõhine kasutajaliides peab olema Minimaalselt Mozilla Firefox, Safari ja Chrome
kasutatav enamlevinud veebibrauseritega. arenduse testimise hetkel tootja poolt toetatud
versioonid ning Internet Explorer 9.0 ning
uuemad.
7.3 Rakenduse värviskeem ja logo kasutamine Kui tegemist on struktuurfondide projektiga on
peab vastama RIK-i ametlikule CVI-le ja lisaks nõutud ka vastav SF sümboolika. RIK-i
UIG-le. ametlikud CVI esitluspõhjad, logo
kasutusjuhend ja kõik logod (ka jpg-na)
küsida tellijalt.
UIG on kättesaadav: http://uig.rik.ee/.
7.4 Kasutajaliidese kõik osad peavad olema
eestikeelsed.
7.5 Avalikuks kasutamiseks tehtav rakendus Ühegi nimetatud resolutsiooni korral ei tohi
peab olema graafiliselt eskaleeruv ja tekkida horisontaalset kerimisriba.
mugavalt kasutatav kõigi enamlevinud
arvutite monitoride resolutsioonidega
vahemikus 1024x600 kuni 1920x1200.
16
7.6 Sisemiseks kasutamiseks tehtav rakendus Ühegi nimetatud resolutsiooni korral ei tohi
peab olema graafiliselt eskaleeruv ja tekkida horisontaalset kerimisriba.
mugavalt kasutatav monitoridel
resolutsioonidega 1024x768 kuni1920 x
1200.
7.7 POP-UP-aknaid ei tohi kasutada.
7.8 Kasutajaliideses toiminguni (põhi- ehk Kõik rakenduse kasutajaliidesest tehtavad
enamkasutatavad tegevused) toimingud tohivad üksteisest olla
navigeerimiseks peab kehtima 3 kliki maksimaalselt 3 hiirekliki kaugusel. Toimingut
printsiip, väljalogimiseks 1 kliki printsiip. ei pea nende 3 klikiga tehtud saama.
Väljalogimime peab olema alati võimlaik ühe
klikiga ja väljalogimise nupp asuma
arusaadavas/intuitiivses kohas.
7.9 Kasutajaliides peab alati küsima kinnituse
andmete kustutamise ja massmuutmiste
kohta kui pole kokku lepitud teisiti.
Veateated peavad olema sellised, mis
võimaldavad IT-abil võimalikult lihtsalt
tuvastada vea olemuse ja asukoha, kuid ei
anna üleliigset või süsteemi ründamist
Rakenduse kasutamisel tekkinud veale peab lihtsamaks tegevat informatsiooni (näiteks
kasutajaliides vastama kasutajale sisevõrgu aadressid jne.). Veateadete tekst
eestikeelse kasutajasõbraliku, süsteemiinfot tuleb määrata ära serveri poolel ja
mittesisaldava veateatega, mis sisaldab veaolukorra tekkides anda kaasa vaid vastava
7.10 soovituslikult ka vea koodi. veaolukorra viide.
7.11 Kasutajaliides peab olema ilma rakenduse Uue keele lisamine peab olema teostatav
koodi muutmata tõlgitav teise keelde, v.a kui konfiguratsiooni failist või
ei ole kokkulepitud teisiti. administreerimisliidesest.
7.12 Rakenduse tausta, menüüde ja teksti värvid
peavad olema ilma rakenduse koodi
muutmata vahetatavad.
7.13 Rakenduse kasutajaliides peab teavitama Ette teavitamise aeg peab olema
kasutajat ette sessioon aegumisest. konfigureeritav.
7.14 Kui vormile sisestatakse mahukaid Kui vorm koosneb paljudest väiksest
andmeväljad peab kasutajaliides kokku andmeväljadest (nt taotlus), siis jagatakse
lepitud ajavahemike järel salvatama välja vorm etappideks ning salvestatakse vastava
sisu, et sessiooni aegumisel või võrgu etapi lõpus.
katkestuse korral juba sisestatud andmed ei
kaoks.
7.17 Sisestusvormidel andmete sisestamisel
peab saama väljade vahel vastavalt
äriloogikale liikuda tabulaatoriga.
7.18 Interaktiivsete vormide puhul (näiteks faili
üleslaadimine), ei tohiks lehe
värskendamisega tegevust korrata (faili taas
üles laadida, andmeid saata, avaldust
esitada).
7.19 Kui päring võtab aega kauem kui 3 sekundit, Ikoon peab muutuma liivakellaks ja/või
peab kasutaja saama visuaalse teavituse, et kuvatakse teade: päringut sooritatakse või
süsteem tegeleb päringu läbiviimisega. muu tellijaga kokkulepitud indikaator.
17
7.20 Pärast kasutaja sisselogimist peab olema Näiteks võimalikud teavituses: süsteemi osa
lihtne võimalus teavitada kasutajat on vigane, tuli mingi uus funktsionaalsus,
muudatustest või probleemidest. Teavitus vahetage oma parool, uuendage
peab olema halduri poolt lihtsalt lisatav ja isikuandmeid jne.
olema kasutajale märgatav.
8.1 Kogu rakenduse dokumentatsioon peab Erandiks võivad olla tellijaga kokkuleppel
olema kirjutatud eesti keeles. kolmanda osapoole komponentide (mis pole
kirjutatud tellija jaoks) dokumentatsioon.
8.2 Käesolevast versioonist välja jäetud.
8.3 Rakenduse dokumentatsioon peab vastama .
RIK dokumentatsiooniplaani nõuetele.
8.4 Rakenduse dokumentatsioon peab Esialgne kirjete mahu hinnang peab tulema
sisaldama tabelite-andmete-logide mahu lähteülesandest, ning täpsustuma eel ja
kasvu arvestuslikku hinnangut rakenduse detailanalüüsi käigus. Mahuhinnang peab
sihipärase kasutamise korral ettenähtud sisaldama ka logide säilitamise, arhiveerimise
arvu kasutajate poolt. (MB/GB kuus/aastas). tähtaegu.
8.5 Iga uue versiooniga peab alati välja tooma Release notes peab kajastama kõiki
versiooni muudatuse kirjeldused (release muudatusi eelmise ja uue versiooni vahel.
notes).
9.1 Kõik rakenduse testimiseks, koolituseks või Arendajale antakse selleks õigused RIK-i
implementeerimiseks üle antavad SVN-i, kus ta peab hoidma oma pma
tarkvarapaketid peavad olema versioone.
versioneeritud vastavalt dokumendile RIK
Arendamise tavad ja töökorraldus.
Kasutama peab RIK-i SVN-i.
9.2
Arendaja peab veenduma, et teeb
muudatusi aktuaalsesse koodi. Ehk
paralleelse arendamise puhul võetakse igal
hommikul SVN-i viimane seis koodist.
9.3 Kõik rakenduste tellijale lepingujärgsete Ka tagant järgi peab olema 100% kindel, et
üleantavate versioonide lähtekoodid peavad üle anti õige arendaja signeeritud, mitte
olema varustatud arendaja esindaja kolmanda osapoole poolt kompromiteeritud
digiallkirjaga. versioon.
9.4 Nii arendamisel kui ka hoolduslepingute Kui ei ole tellijaga kokku lepitud teisiti.
korral kasutatakse RIK vigadehalduse
keskkonda (Jira).
9.5 Kui veebirakenduses või veebilehel on linke, Puhas link on inimloetav, tähendust omav,
mida kasutajad näevad või millele nad paraja pikkusega, tekstiline (erandina lubatud
saavad viidata, peavad need olmea puhtad numbrid ja märgid „/“, „.“, „-“ ja „_“) ja ajas
lingid. püsiv. Veebisaidi igal kuval peab olema
unikaalne link.
10.2 Kooste kirjelduste alusel valmiv Näiteks: kompileeritavate keelte puhul ei tohi
paigalduspakett tohib sisaldada ainult sisaldada lähtekoodi, kui see pole vajalik
minimaalse rakenduse käitamiseks rakenduse käitamiseks.
vajamineva failikomplekti.
10.3 Kooste kirjelduste alusel valmivat Näiteks ei tohi tekitada olukorda, kus
paigalduspaketti peab olema võimalik rakenduse jooksutamiseks uues serveris tuleb
liigutada erinevate masinate vahel. see tingimata just sealsamas kokku
kompileerida.
18
10.4 Lähtekoodi kompileerimine peab olema
teostatav ka võrguühenduse puudumise
korral.
10.5 Andmebaasi paigalduse skriptid ei tohi olla Administraator tahab veenduda skripti sisus.
kompileeritud.
19
Lisa 4-4
NÕUDED LOGIMISELE
Hankija jätab endale õiguse muuta käesolevas peatükis kirjeldatud nõudeid, sätestades vastavad
muudatused hankelepingu alusel teostatavates tellimustes. Pakkuja peab lähtuma hankelepingute täitmisel
järgnevatest nõuetest, v.a juhul kui hankija on tellimuses märkinud teisti.
Logides eristatakse kasutajate tegevuste logisid, süsteemi logisid ning andmevahetuslogisid.
Kasutajate tegevuste logid
Kasutajate kõik tegevused logitakse ning läbi kasutajaliidese on näha, kes ning millal on konkreetset
tegevust teinud või midagi vaadanud.
Andmeid andmebaasis ei kustutata. Kui kasutaja kustutab andmeid, siis tuleb need märkida andmebaasis
kustutatud olekusse, mille tulemusena neid enam välja ei kuvata.
Kui infosüsteemi ISKE klass on kõrge, siis andmete muutmisel tuleb käituda analoogselt. Kui muudetakse
juba eksisteerivaid andmeid, siis tuleb muudetavast olemist (näiteks luba või toiming) teha uus versioon, et
säiliksid ka enne muutmist eksisteerinud andmed. Fakt sellise muutmise kohta tuleb salvestada.
Logida tuleb ka kasutaja sisselogimised. Info tuleb talletada nii õnnestunud kui ebaõnnestunud
logimiskatsete kohta.
Andmevahetuslogid
Lisaks tuleb logida x-tee sõnumid. X-tee sõnumite logimine peab olema võimalik nii andmebaasi kui ka
failisüsteemi (iga sõnum eraldi faili, failid vähemalt päeva kaupa eraldi kaustas) ning see, kuhu logitakse
(kas andmebaasi või failisüsteemi), peab olema ilma rakendust uuesti kompileerimata muudetav.
Süsteemi logid
Samuti tuleb logida kõik rakenduses tekkivad veateated. Neid logisid tuleb hoida nii andmebaasis (teistest
logidest eraldi tabelites, kuid ID-dega tegevuste logiga seotuna) kui failisüsteemis (iga päeva logid eraldi
failis, mis on eraldi kaustades) ning see, kuhu logitakse (kas andmebaasi või failisüsteemi), peab olema
ilma rakendust uuesti kompileerimata muudetav.
Logimise mittefunktsionaalsed nõuded
Logimine toimub nii baasi kui ka failisüsteemi, lisaks peab olema võimalik süsteemi tõrkeid edastada emaili
teel.
1. Failisüsteemi logimine:
a. Failisüsteemi peab saama logida:
i. Süsteemi tõrked (handled ja unhandled exceptions jne)
ii. Xtee päringud (päringud ja vastused)
b. Süsteemi tõrked tuleb logida:
i. ühe päeva logi kohta tekiks üks masintöödeldav fail (näiteks XML või CSV
formaadis)
ii. faili asukohta peab olema konfigureeritav (näiteks:
rakenduse_nimi/masina_nimi/aasta/kuu/) ning vajalikud kaustad peab rakendus
suutma ise tekitada.
iii. logi peab sisaldama: kellaaeg, kasutaja, vea koht, vea sisu.
c. Süsteemi tõrgete logimist peab saama sisse-välja lülitada
d. Andmevahetuslogid (näiteks xtee logid) peavad:
i. Olema üles struktureeritud selliselt, et päring ja vastus on eraldi failides.
ii. faili asukohta peab olema konfigureeritav (näiteks:
rakenduse_nimi/masina_nimi/aasta/kuu/paev) ning vajalikud kaustad peab
rakendus suutma ise tekitada.
iii. Xtee logi faili nimi peab sisaldama: teenuse nimi, kasutaja isikukood,
request/response, kellaaeg (kellaaeg ms-ga tagaks ka failinime unikaalsust)
iv. Xtee failide logimine peab saama sisse-välja lülitada
20
e. Konfimine (sisse/väljalülitused, asukohaadressid) võib toimuda läbi log4net.config (kui
kasutatakse log4net komponenti).
f. Debug ja Info logimine ei ole keelatud aga see peab olema samuti konfigureeritav
2. Süsteemi tõrgete e-mailile saatmine:
a. Süsteemi tõrkeid peab olema võimalik edastada konfiguratsioonis sätestatud e-mailidele.
b. E-mailimist peab saama sisse-välja lülitada
c. E-mail peab sisaldama: kellaaeg, kasutaja, vea koht, vea sisu.
3. Andmebaasi logimine:
a. Andmebaasi peab saama logida:
i. Kasutajate tegevuste logi
ii. Süsteemi tõrked (handled ja unhandled exceptions jne)
iii. Xtee päringud (päringud ja vastused)
b. Logide tabelid peavad olema eraldatud teistest tabelitest prefiksiga.
c. Sisse-välja logimise informatsioon peab olema eraldi tabelis.
d. Xtee logid (kes, millal, miks mingi teenuse poole pöördus ning mis oli tulemus) peavad
olema eraldi tabelis ning failid (request ja response) peavad olema iseseisvas tabelis.
e. Logitabeleid peab olema võimalik versioneerida (tabeli suureks kasvades teha hoida
vanu kirjeid näiteks aastate kaupa iseseisvates tabelites).
f. Süsteemi tõrked peavad olema eraldi tabelites.
g. Kasutajate tegevused peavad olema eraldi tabelites.
h. Süsteemi tõrgete logimine ja xtee logimine baasi peab saama eraldi sisse-välja lülitada.
i. Kasutajate tegevuste logimist ei tohi saada välja lülitada.
4. Krüptoaheldamine (ainult kõrge ISKE klassiga süsteemide puhul):
a. Andmebaasis hoitavad logid peavad olema krüptoaheldatud kasutades Guardtime
ajatemplit.
b. Detailanalüüsis kokkulepitavad ärikriitilised andmed tuleb samuti krüptoaheldada
kasutades Guardtime ajatemplit.
c. Tuleb luua valideerimise lahendus, mis valideeriks selleks seadistatud ajal (näiteks igal
öösel) viimasel 7 päeval muudetud ja lisandunud andmeid ning logisid (arvutaks üle
nende ajatemplite väärtused).
Üks kord nädalas valideeritakse vanemaid andmeid (see peab olema konfigureeritav),
perioodi pikkus sõltub jõudlusest. Valideerimise teenust peab olema võimalik seisma
panna ja peab olema võimalik ka käivitada kasutaja poolt valitud osade kohta. Teenus
peab olema konfigureeritav eraldi konfiguratsiooni failist. Valideerimise protsess peab
olema võimeline töötama ka klasterdatud andmebaasi puhul ning second-site korral.
d. Valideerimise protsessi tulemusena peab genereerima automaatne raport, mis on
vaadeldav süsteemi administraatori liidese kaudu ning mida on võimalik automaatselt
edastada ettenähtud e-mailiaadressidele. Raport peab sisaldama infot valideerimise
protsessi alguse ja lõpu aja kohta, infot selle kohta, kui mitut ajatemplit kontrolliti. Kui
esines ebaõnnestunud kontrolle, siis tuleb nendega seotud andmed välja tuua, et oleks
võimalik tuvastada rikutud andmed.
5. Rakenduse töö käigus kasutavad mitu rakenduse instance-i sama conf-faili ja kirjutavad sama
failisüsteemi. See tähendab, et konfiguratsioonis peab olema võimalik kasutada
keskkonnamuutujaid. Näiteks failitee puhul on vajalik kasutada keskkonnamuutujaid (computer
name).
21
Lisa 4-5
ARENDAMISE TAVAD JA TÖÖKORRALDUS
Hankija jätab endale õiguse muuta käesolevas peatükis kirjeldatud nõudeid sätestades vastavad
muudatused hankelepingu alusel teostatavates tellimustes. Pakkuja peab lähtuma hankelepingute täitmisel
järgnevatest nõuetest, v.a juhul kui hankija on tellimuses märkinud teisti.
Nõuded arenduste üleandmisele
Loodavad hanke tulemid antakse üle RIK-i koodirepositooriumi (SVN) kaudu. Partneri meeskonnaliikmetele
luuakse RIK-i poolt ligipääs SVN-ile lähtekoodide, andmebaasimuudatuste ning muude tulemite või nende
muudatuste üleandmiseks.
RIKi SVNiga suhtlemiseks on soovitatav kasutada tortoisesvn nimelist tarkvara:
Kättesaadav: http://code.google.com/p/tortoisesvn/downloads/list
Manual: http://tortoisesvn.net/docs/release/TortoiseSVN_en/
Commit
Arendamisel lisada commitide (lähtekoodi depositooriumisse lisamine) juurde kindlasti töökäsu nr, mille
alusel muudatus sisse viiakse. Töökäsu puudumisel sobib 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.
Täpsemalt on võimalik lugeda:
http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-commit.html
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 arendaja poolt testidega kaetud,
kasutades selleks:
a) Unittest’e,
b) Systemtest’e
c) Manuaalseid teste
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 kokkuleppida 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.
22
Dokumentatsioon
Dokumentatsiooni tuleb hoida trunk/doc/ kaustas. Alampuud lepitakse eraldi kokku.
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.
Arendaja 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.
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).
Süsteemitestid
Süsteemitestid testivad süsteemi kasutaja vaatenurgast, eesmärgiks on kontrollida süsteemi vastavust
kasutaja nõudmistele.
Süsteemitestid jagunevad omakorda kaheks:
Funktsionaalsuse testid - üldjuhul koostatakse konkreetse teenuse klassi süsteemitestid sellises
mahus, et kaetud oleksid selle kõik erinevad meetodid ning lisaks äriloogiliselt olulisemad
stsenaariumid.
Mittefunktsionaalsete aspektide testid - näiteks jõudluse testimiseks.
Ü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 ET-s, st. 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
23
taluma ET muudatusi).
Koodieetika ja struktuur testide kirjutamisel
Testkood peaks olema liigendatud ja selgelt loetav:
Defineerida testis projekti erinevate osade kasutus (nt. using System;);
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);
Testis olevad privaatsed klassimuutujad on tava kohaselt kujul _muutujaNimi, näiteks
private Menetlus _menetlus;
Kaitstud ja avalikud muutujad on kujul muutujaNimi või MuutujaNimi;
Vajalik uute klassiobjektide initsialiseerimine (nt. liidesed) toimub meetodis SetUp(). Näiteks:
[SetUp]
public void SetUp()
{
_liides = new Liides();
}
Iga uus testcase tuleb kirjutada raamistiku sisse kujul
[Test, Category("Kategooria")]
ning testi enda nimetus tuleneb testi tüübist:
o Bug-testide ja uuendusi kontrollivate testide korral nimetus, mis kirjeldab võimalikult hästi
ja konkreetselt kontrollitavat objekti/olukorda (nt. teenusel VäärteoMenetluseAlustamine
ei salvestu süüteod ET-baasi: testi pealkiri SyyteoSalvestumineTest());
o Teenusepõhiste süvatestide puhul esiteks test, mis kontrollib, et teenust saaks nii
minimaalsete kui ka maksimaalsete andmetega kinnitada, nimetusega A_SetUp() ning
edasi kujul B_Äridokumendi_esimene_punkt() jne.
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.
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.
Autonoomsus
Testid peavad taluma pisemaid koodi muudatusi (neid, millega ei kaasne DTO või andmemudeli
muutused).
Automatiseeritus
Kõiki teste peab saama käivitada näiteks projektiväliselt skripti abil. Selleks peavad testid olema õigesti
kategoriseeritud.
Kujundus
Funktsionaalsuse arendamisel tuleb lähtuda olemasolevast kujundus- ja navigeerimisloogikast , mis on
kirjeldatud http://uig.rik.ee veebilehel.
Uute komponentide lisandumisel tuleb need eelnevalt Tellijaga kooskõlastada.
24
Lisa 4-6
NÕUDED TESTIMISELE
Hankija jätab endale õiguse muuta käesolevas peatükis kirjeldatud nõudeid, sätestades vastavad
muudatused hankelepingu alusel teostatavates tellimustes. Pakkuja peab lähtuma hankelepingute täitmisel
järgnevatest nõuetest, v.a juhul kui hankija on tellimuses märkinud teisti.
Dokumendi eesmärk
Dokumendi eesmärk on kirjeldada Tellija nõutavad minimaalsed nõuded Arendaja poolt teostatavale
testimisele.
Mõisted
Kasutaja – rakendust kasutav isik
Tellija – RIK
Arendaja – pakkuja
Lõpptarne – viimase üleandmise-vastuvõtmise aktiga üleantav arenduse tulem
Akteeritav tarne – muu üleandmise-vastuvõtmise aktiga üleantav arenduse tulem
Vahetarne – ilma aktita üleantav arenduse tulem
Viga – tarkvaralahenduses esinev tõrge või puudus, mis läheb vastuollu arenduse aluseks olevate
dokumentidega või kokkulepetega ja põhjustab tarkvara käitumist mittesoovitud viisil.
Ühiktest – unit test
Süsteemitest – systemtest
Üldised nõuded testimisele
Esmase testimise eest vastutab alati Arendaja. Üle antud koodi/etappi testib Tellija omalt poolt.
Mõlemapoolne testimine peab algama arenduse algfaasides.
Enne arenduse ülespanekut üldharusse/alamharusse või ükskõik mis muul moel koodiosa või etapi
üleandmise eel peab arenduse tulem vastama üldistele testimise nõuetele:
1) Arendus on iseendaga kooskõlas (pole katkiseid mooduleid, iseendaga vastuolus olevat
funktsionaalsust).
2) Commititava haruga kooskõlas (varasemad arendused ei lähe katki, sh. mitte antud projekti
arendused).
3) Varasemat projekti muutes peab uus arendus olema kooskõlas varasemaga (sh. sellel on olemas
sisseehitatud testid, mis peale järgnevaid võimalikke arendusi näitaks, kas see konkreetne
funktsionaalsus on endiselt töötav).
Arenduse tulem peab olema piisavalt testitud ning testidega kaetud, kasutades selleks parasjagu erinevaid
sobivaid:
d) Ühikteste
e) Süsteemiteste
f) Manuaalseid teste
Kus piisavalt tähendab:
Arendaja on tõestatavalt veendunud, et nende arenduse tulem teeb seda, mis on Tellija poolt tellitud ning
samaaegselt ei lõhu või ole vastuolus eelnevate arendustega. Antud veendumus piisavas testimises peab
olema tõestatav, st Tellijale peab olema selgelt näha nii üleantavates dokumentides kui koodis, et Arendaja
reaalselt on testinud vastavalt väidetele. See ei pea alati olema ülimalt detailne testilugudest ja testraportist
koosnev dokument (st. dokumentide paljusus ei tõesta tehtud arenduse korrektset töötamist). Üldjuhul
piisab järgnevast kirjeldusest:
1. Mida, miks, kuidas testiti/prooviti
2. Asjakohane informatiivne kokkuvõte.
Vajadusel peab Arendaja suutma näidata järgmist:
1) Ühikteste
25
2) Süsteemiteste
3) Manuaalseid teste
4) mis andmeid, keskkondi jm. kasutati
Vajadusel üleantav testimisdokumentatsioon
1. Nõuded
2. Testlood
3. Testandmed
4. Liidestumise testimise skriptid
5. Automaattestimise skriptid
6. Versiooni tagasikeeramise testimise skriptid
7. Käideldavuse testimise, koormustestimise ja stressitestimise skriptid ning seadistamise
juhend
8. Testiraport
Nõuded testimise dokumentatsioonile ja testitulemitele
Testlugusid kirjutatakse vastavalt vajadusele nende testide kohta, mille juures on neist kasu (nt. enamus
süsteemi- ja unit teste ei vaja testlugusid).
1.1 Testiplaan
Testiplaan koostatakse Tellija poolt kinnitatud analüüsi järgi enne programmeerimise algust ja vajadusel
täiendatakse testimise vältel.
Testiplaan sisaldab testlugusid, nende läbiviimise järjekorda ja omavahelisi seoseid – testiplaan peab
näitama mismoodi loodavat funktsionaalsust testida.
Testiplaan ja testlood peavad olema muust dokumentatsioonist iseseisvad, st et kolmandatel osapooltel
peab olema võimalik selle järgi testida muusse dokumentatsiooni süvenemata.
Soovitavalt on testiplaan esitatud muude võimalike vormingute kõrval ka testipuuna.
1.2 Testlood
1. Testilugude komplekt tuleb esitada ühes inimloetavas vormis (.doc / .docx/ .xls/ .xslx/ .rtf/ .html).
2. Kogu arendatav funktsionaalsus peab olema kaetud testilugudega (sh. kõik veaohtlikud- ja
eriolukorrad Vt. Viga definitsiooni).
3. Üks testilugu võib sisaldada maksimaalselt ühte negatiivset stsenaariumit – mitme negatiivse voo
kirjeldamine ühes testiloos ei ole lubatud.
4. Testlugude läbimiseks vajalikud eeltingimused ei tohi olla sõltuvuses teistest testlugudest.
5. Üks testilugu võib kontrollida mitut nõuet.
6. Testlood peavad sisaldama andmeväljade valideerimist vastavalt analüüsidokumentides toodud
nõuetele (piirjuhud, negatiivsed-, positiivsed-, erijuhud).
1.2.1 Nõuded testloo sisule
1. Kõik testiloo läbimise eeldused peavad olema kirjeldatud testiloo juures.
2. Iga testilugu peab käsitlema terviklikku tegevuste kogumit, mille tulemusel andmebaasi andmehulk
muutub va. juhud, kui kontrollitakse andmeväljade valideerimist või negatiivseid stsenaariume.
3. Testiloos kirjeldatud testisammud peavad olema eraldi läbitavad ning hinnangu sammu edukusele
peab saama anda igale testsammule eraldi.
4. Kõik analüüsis kirjeldatud veateated peavad olema testilugudes kaetud (nendeks pole tingimata
vaja eraldi testlugusid).
5. Kui testilugu sisaldab andmete sisestamist või menetlemist, siis peab testilugu katma kõik vajalikud
etapid testitulemite saavutamiseks.
6. Loodud/muudetud/täiendatud andmesisestusväljadel korral tuleb testiloos välja tuua nende
valideerimisreegleid (nt. viide analüüsinõudele).
Testlood peavad sisaldama järgmist infot:
1. Testloo grupp.
2. Testloo nimetus.
3. Testloo kirjeldus.
4. Seotud testlood ja analüüsinõuded.
26
5. Testiloo prioriteet (kriitiline – kasutusloo põhivoog, kõrge – kasutusloo alternatiivvoog ja
mittefunktsionaalsed nõuded, keskmine – kasutusloo põhivoo veaolukordade testimine, madal –
kasutusloo alternatiivvoo veaolukordade testimine) kui see on vajalik.
6. Testiloo läbimise eeldused (testiloo läbimiseks vajalikud õigused ja eelnevad toimingud).
7. Testiloo testandmed.
8. Testisammud.
9. Oodatavad tulemid vastavalt testisammudele.
1.3 Testandmed
1. Testandmed antakse üle koos tarnega (antud tarne testimiseks vajalik komplekt) kui ei kasutata
Tellija poolseid testandmeid.
2. Tulemitega tarnitavad testid peavad kasutama eelpoolmainitud testandmeid.
3. Kui tarnitav rakendus integreerub teiste süsteemidega ning eeldab sealt spetsiifilisi andmeid mida
eelnevalt ei eksisteeri, tuleb vajalikud testandmed luua või loob need Tellija vastava kokkuleppe
alusel.
4. Testandmed peavad olema reaalsusega vastavuses (nt reaalsed isikukoodid, registrinumbrid,
autonumbrid, seaduse paragrahvid jms).
5. Testandmetega peavad olema kaetud kõik ekvivalentsklassid ja piirjuhud (va kui selliste andmete
esinemine ei ole võimalik).
6. Testandmete hulk peab olema võrdväärne eeldatava andmete hulgaga, kui on teada, et süsteemi
andmete hulk on kiiresti kasvav või süsteemi tehakse andmesiire (vajalik veendumaks, et
süsteem töötab ka peale andmesiiret või pikaaegset kasutamist sama kvaliteetselt).
1.4 Testiraport
1. Testiraport esitatakse koos tarnega. Tellija poolse testimise eeldus on eelnevat nõuetele vastava
testimise teostamine Arendaja poolt.
2. Testiraportist peab olema selgelt aru saada, milliseid situatsioone ja milliste andmetega testiti,
milline oli testimise tulem, millised vead tuvastati, millised nõuded / kasutuslood on testilugudega
kaetud.
3. Testiraporti dokumentatsioon ja lisadokumendid peavad olema selgelt struktureeritud ja omavahel
seostatud.
1.5 Testidest täpsemalt
Arendaja peab testidega katma kogu arendatava funktsionaalsuse ja peidetud funktsionaalsuse
vastavalt analüüsidokumentides olevatele nõuetele (vt p 1 Üldised nõuded testimisele).
Käideldavus-, koormus- ja stressitestid viiakse läbi reaalsete või reaalsele lähedaste andmetega,
siinjuures mõeldakse ka andmemahtusid.
1.5.1 Ühiktestimine
Kogu muudetud ja uus funktsionaalsus tuleb katta süsteemitestidega ja/või ühiktestidega.
1.5.2 Paigaldustestimine
1. Tuleb veenduda, et paigaldamine on võimalik kui eelnevalt ei ole paigaldatud ühtegi versiooni (nn
clean installation).
2. Tuleb veenduda, et paigaldamine on võimalik kui eelnevalt on paigaldatud viimane stabiilne (Tellija
toodangukeskkonnas olev) versioon.
3. Tuleb veenduda, et paigaldamine on võimalik kui eelnevalt on paigaldatud eelmine tarne.
1.5.3 Liidestumise testimine
1. Kõik arenduse käigus loodud/muudetud väliste süsteemidega liidesed, mida arendatav süsteem
tarbib või ise pakub peab olema testitud vastavalt nõuetele.
2. Arendaja peab koos tarnega esitama liidestumise testiraporti.
1.5.4 Automaattestimine
Vajadusel luuakse Automaattestid, et vähendada regressioonitestidele kuluvat aega, enamasti on
süsteemitestid ka automaattestid.
1.5.5 Funktsionaalsete nõuete testimine
Funktsionaalsete nõuete kontrollimisel tuleb silmas pidada, et kontrollitakse muudetud ja/või uue
27
funktsionaalsuse korrektset toimimist.
1. Arendaja koostab kõikide rakenduse siseste funktsionaalsete nõuete kontrollimiseks testlood.
2. Juhul, kui rakendus suhtleb tänu kasutaja toimingule mõne muu rakendusega, tuleb süsteemide
vaheliste nõuete funktsionaalsete nõuete kontrollimiseks koostada testlood.
3. Juhul kui rakendus suhtleb automaatselt mõne muu rakendusega, tuleb süsteemide vaheliste
funktsionaalsete nõuete kontrollimiseks koostada testlood.
4. Käsitsi läbitavaid testlugusid võib asendada samaväärset funktsionaalsust kontrolliva
automaattestiga (vt p 3.4.4). Sel juhul tuleb lähtuda automaattesti koostamise nõuetest, mis
kehtivad testilugudele.
5. Kui mõne funktsionaalse testimise jaoks koostatud testlugu asendatakse automaattestiga (vt 3.4.4
Funktsionaalsete nõuete testimine p.5), siis sama funktsionaalsuse kontrollimiseks manuaalset
testilugu koostada ja läbida ei tule (tuleb ainult kirjeldada testiloo pealkiri ja testiloo kirjeldusena
automaattesti number).
1.5.6 Veaolukordade testimine
Veaolukordade kontrollimisel tuleb silmas pidada, et kontrollitakse muudetud ja/või uue funktsionaalsuse
mittekorrektset toimimist. Veaolukordade testimise eesmärgiks on veenduda, et arendatud ja/või muudetud
funktsionaalsus annab korrektsed (grammatiliselt korrektses ja arusaadavas eesti keeles) veateated
valideerimisreeglite vastu sisestatud andmete puhul.
1.5.7 Versiooni tagasikeeramise testimine
Versiooni tagasikeeramise testimisel tuleb veenduda, et tarkvara versiooni tagasikeeramine on võimalik ja
tarkvara funktsionaalsus töötab korrektselt tagasikeeratud versioonis esialgsete võimaluste piires.
1. Tarnega üleantava versiooni vaatest tuleb testida eelnevale versioonile üleminekut ja veenduda,
et üleminek on võimalik ning eelmise tarne funktsionaalsus on täies mahus töötav.
1.5.8 Regressioonitestimine
Regressioonitestimisel kontrollitakse varasemalt tarkvaras või eelnevates tarnetes olnud funktsionaalsuste
toimimist peale uue tarne paigaldamist. Regressioonitestimise põhieesmärgiks on veenduda, et uus
arendus ja/või vigade parandus ei ole varasemat funktsionaalsust katki teinud.
1. Testitakse üle kõik varasemates tarnetes üle antud funktsionaalsus ning veendutakse, et uus
funktsionaalsus ei ole ühtegi varasema tarne funktsionaalsusesse vigu tekitanud.
2. Kui tegemist on olemasoleva rakenduse edasiarendusega, siis tuleb regressioonitestidega
veenduda, et kõik varem olemas olnud funktsionaalsused toimivad samasuguse kvaliteediga kui
nad toimisid enne edasiarenduse algust (veendutakse ka, et süsteem ei ole muutunud
põhjendamatult aeglasemaks).
1.5.9 Käideldavuse testimine
Käideldavuse testimisel tuleb kontrollida süsteemi reaktsiooniaegu keskmise kasutatavuse korral.
Reaktsiooniaegade mõõtmisel tuleb lähtuda kolmest parameetrist: paralleelsete kasutajate arv, toimingute
arv, süsteemi lisatav info.
1.5.10 Koormustestimine
Koormustestimisel tuleb kontrollida süsteemi reaktsiooniaegu maksimaalse kasutatavuse korral.
Reaktsiooniaegade mõõtmisel tuleb lähtuda kolmest parameetrist: paralleelsete kasutajate arv, toimingute
arv, süsteemi lisatav info.
Koormustestimisel tuleb lähtuda järgmistest nõuetest:
1. Koormustestimise eesmärk on kontrollida tarkvara käitumist maksimaalse lubatud koormuse korral
(nõuded on kirjeldatud mitte-funktsionaalsete nõuete juures, kui seal vastav info puudub siis Tellija
täpsustab).
2. Koormustestimise testilood/testiskriptid koos seadistamisjuhendiga tuleb Tellijale üle anda koos
testiraportiga, mis kirjeldab stressitestimise tulemust.
1.5.11 Stressitestimine
Stressitestimisel tuleb kontrollida süsteemi reaktsiooniaegu maksimaalset kasutatavust ületamise korral.
Reaktsiooniaegade mõõtmisel tuleb lähtuda kolmest parameetrist: paralleelsete kasutajate arv, toimingute
arv, süsteemi lisatav info.
Stressitestimisel tuleb lähtuda järgmistest nõuetest:
28
1. Stressitestimise eesmärk on kontrollida tarkvara käitumist lubatud maksimaalsest koormusest 25%
suurematel koormustel (nõuded on kirjeldatud mitte-funktsionaalsete nõuete juures, kui seal vastav
info puudub siis Tellija täpsustab).
2. Stressitestimise testilood/testiskriptid koos seadistamisjuhendiga tuleb Tellijale üle anda koos
testiraportiga, mis kirjeldab stressitestimise tulemust.
Turvalisus
1. Tarkvara peab infot vastu võtma ja väljastama ainult rakenduse nendest kohtadest ning
seadmetest, kust see on ette nähtud.
2. Tarkvara peab infot vastu võtma ja väljastama ainut ennast korrektselt autentinud ning korrektset
õigust omavalt kasutajalt.
3. Vastavale arendusele esitatakse eraldi spetsiifilised turvanõuded.
Juurdepääsu andmetele, andmemuudatusi ning andmete kopeerimist ei tohi lubada, kui kõik ülalpool
mainitud kriteeriumid ei ole täidetud.
Vigade haldus
1.1 Vigade raporteerimine
1. Vigade raporteerimine ja haldamine toimub Tellija veahalduskeskkonnas JIRA. Arendaja peab
tagama, et JIRA on alati ajakohane info vigade ning nende parandamise kohta.
2. Vea parandamise puhul tuleb parandamismärkele lisaks viidata tarkvara versioonile, milles viga on
parandatud. Kui Arendajal ei ole see teada vea paranduse kontrollimise hetkel, siis enne
veaparandust sisaldava paketi/deploy/tarne üleandmise eel tuleb vea piletit täiendada versiooni
numbriga.
1.2 Vigade prioriteedid
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 (st. Viga millega live minek
on absoluutselt võimatu).
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.
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).
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.
5. Väheoluline - viga, mille tõttu otseseid kõrvalekaldeid ei teki kuid vajavad muutmist/parandamist.
1.3 Vigade raport
1. Arendaja on kohustatud esitama konkreetse etapi lõpus kõikide hetkel teadaolevate vigade
nimekirja, ka nende, mis pole Tellija veahalduskeskkonnas JIRA.
2. Teadaolevate vigade juurde tuleb märkida, millises nõudes ja/või koodi osas viga esineb (olenevalt
vea tüübist).
Kvaliteet
Tarkvara loetakse vastuvõtmiskõlbulikuks, kui:
Üleandmise-vastuvõtmise aktiga üleantud tarkvaras on parandatud kõik nii Tellija kui ka Arendaja pool
leitud vead (sõltumata vea prioriteedist) või lepitakse Tellijaga kokku vigadega vastuvõtmine, kus aktis on
kirjas teadaolevad vead ja nende hiliseim parandustähtaeg.
Muu info
1. Üleandmise-vastuvõtmise akti allakirjutamine ei vabasta Arendajat teostatud arendustöödes
esinevate vigade parandamise kohustusest, sh vigade parandamisest, mille olemasolust on Tellija
teadlik üleandmise-vastuvõtmise akti allakirjutamise hetkel või mis esinevad garantiiperioodi ajal.
2. Tellijal on õigus tulemite kvaliteedi ja sisu hindamiseks kasutada väliste ekspertide abi
29
Allkirjastatud digitaalselt
MUUSEUMIDE INFOSÜSTEEMI KASUTAMISE LEPINGU nr 1.1-8/121
LISA 2
Kultuuriministeerium ja Sihtasutus Betti Alveri Muuseum (edaspidi muuseum), edaspidi
eraldi pool või koos pooled, leppisid nende vahel 23.09.2014 sõlmitud muuseumide infosüsteemi
kasutamise lepingu nr 1.1-8/121 (edaspidi leping) muutmises kokku alljärgnevalt.
1. Lepingu punkt 3.1.4 muudetakse ja museaalide digitaalse kujutise infosüsteemi lisamise
tähtpäev „31.12.2018” asendatakse tähtpäevaga „31.12.2020”.
2. Lisa jõustub, kui pooled on selle allkirjastanud.
Kultuuriministeerium Sihtasutus Betti Alveri Muuseum
Registrikood: 70000941 Registrikood: 90001440
E-posti aadress:
[email protected] E-posti aadress:
[email protected]
(allkirjastatud digitaalselt) (allkirjastatud digitaalselt)
Indrek Saar Toomas Muru
minister juhatuse liige
Allkirjastatud digitaalselt
MUUSEUMIDE INFOSÜSTEEMI KASUTAMISE
L E P I N G nr 6-9.1/179-1
Kultuuriministeerium ja Eesti Pank (edaspidi muuseum), edaspidi eraldi pool või koos pooled, on
sõlminud käesoleva muuseumide infosüsteemi kasutamise lepingu (edaspidi leping) alljärgnevas.
1. Üldsätted
1.1. Lepingu eesmärk on kokku leppida muuseumiseaduse § 15 alusel asutatud muuseumide andmekogu
ametliku nimega „Muuseumide infosüsteem” (edaspidi infosüsteem) kasutamise tingimused.
1.2. Infosüsteem on andmebaas, mille tegijaks autoriõiguse seaduse (edaspidi AutÕS) § 75 3 mõistes on
Kultuuriministeerium.
1.3. Lepingu täitmisel juhindutakse muuseumiseadusest ja selle rakendusaktidest ning infosüsteemi
kasutusjuhenditest. Muuseum on teadlik, et pärast käesoleva lepingu sõlmimist kohaldatakse tema
tegevusele muuseumiseaduse paragrahve 5, 6, 7, 11, 14, 15, 16, 22 ja 23.
2. Poolte õigused
2.1. Muuseumil on õigus:
2.1.1. kasutada infosüsteemi museaalide, hoiule võetud asjade ja abikogusse arvatud asjade
metaandmete ja digitaalsete kujutiste (edaspidi andmete) elektrooniliseks haldamiseks ja
säilitamiseks;
2.1.2. sisestada, muuta ja kustutada tema poolt sisestatud andmeid, järgides kultuuriministri
08.07.2013. a määruses nr 30 „Muuseumikogu täiendamise ja kultuuriväärtusega asja
muuseumisse hoiule võtmise kord“, 08.07.2013. a määruses nr 31 „Museaali ja muuseumisse
kauemaks kui aastaks hoiule võetud asja märgistamise ja säilitamise kord“ ning 08.07.2013. a
määruses nr 32 „Muuseumide andmekogu asutamine ja põhimäärus“ sätestatud nõudeid. Kui
museaal on autoriõigusega kaitstav teos, siis teeb muuseum sellest digitaalse kujutise AutÕS §
20 lg 1 p 4 alusel ning see tehakse üldsusele kättesaadavaks infosüsteemis AutÕS § 20 lg 3
tingimustel;
2.1.3. kasutada infosüsteemis sisalduvaid tema poolt sisestatud andmeid ning muuseumile mõeldud
loogilist infosüsteemi osa, millele puudub juurdepääs teistel kasutajatel;
2.1.4. teha lihtlitsentsi alusel tasuta väljavõtteid infosüsteemis olevatest andmetest Väljavõtte
tegemiseks loetakse infosüsteemis olevate andmete mis tahes viisil või mis tahes vormis ajutist
või alalist ülekandmist teise väljendusvormi;
2.1.5. koostada ning käivitada päringuid museaalide, hoiule võetud asjade ja abikogusse arvatud
asjade ning nendega seotud tegevuste ja dokumentide kohta;
2.1.6. saada Kultuuriministeeriumilt nõustamist muuseumikogu korraldamisel ning muuseumi
ülesannete täitmisel.
2.2. Kultuuriministeeriumil on õigus:
2.2.1. teha üldsusele kättesaadavaks avalikkusele suunatud andmeid. Muuseum annab selleks
lihtlitsentsi kogu autoriõiguse tähtaja ulatuses ning litsents kehtib Eestis ja kõigis välisriikides.
Kultuuriministeeriumil on õigus anda vastavaid all-litsentse. Andmed tehakse üldsusele
kättesaadavaks järgneva litsentsi alusel: The Creative Commons Universal Public Domain
Dedication (CC0 1.0). Kui digitaalne kujutis on autoriõigusega kaitstav teos või digitaalsel
kujutisel on kujutatud autoriõigusega kaitstavad teosed, siis neile CC0 litsents ei kohaldu;
2.2.2. muuseumi antud lihtlitsentsi alusel kasutada andmeid infosüsteemis ja Europeana
andmebaasides ning otsingusüsteemides;
2.2.3. anda avalikkusele suunatud juurdepääsupiiranguta andmeid üldsusele kasutada ilma tasu ja
piiranguteta, sh ärikasutuse jaoks;
2.2.4. kasutada avalikkusele suunatud juurdepääsupiiranguta andmeid infosüsteemi tutvustamiseks;
sulgeda avalik juurdepääs andmetele juhul, kui see on vajalik andmete korrastamiseks, isikuandmete
või autoriõiguste kaitse tagamiseks. Kultuuriministeerium teavitab viivitamatult selliste muudatuste
tegemisest muuseumit.
Allkirjastatud digitaalselt
3. Poolte kohustused
3.1. Muuseum kohustub:
3.1.1. järgima infosüsteemi kasutusjuhendit ja turvanõudeid (lepingu lisa 1), tutvustama infosüsteemi
turvanõudeid kõigile infosüsteemi kasutavatele töötajatele enne esmast sisselogimist ning
tegema turvanõuded neile kättesaadavaks;
3.1.2. andmete sisestamisel järgima isikuandmete kaitse seadusest tulenevaid nõudeid. Kui
avalikustatakse museaali digitaalne kujutis, millel on kujutatud isik, siis eeldatakse, et isik on
eelnevalt andnud nõusoleku kujutise kasutamiseks. Kui isik nõuab oma isikukujutise ja või
teiste isikuandmete eemaldamist infosüsteemist, siis peab muuseum vastavad andmed
eemaldama infosüsteemi osast, mis on ligipääsetav avalikkusele;
3.1.3. läbi viima enne käesoleva lepingu sõlmimist arvele võetud museaalide esmase
dokumenteerimise ja kirjeldamise esimese etapi infosüsteemis kultuuriministri 08.07.2013. a
määruse nr 32 „Muuseumide andmekogu asutamine ja põhimäärus“ 2. peatükis esitatud nõuete
kohaselt hiljemalt 31.12.2023;
3.1.4. lisama enne käesoleva lepingu sõlmimist arvele võetud museaali digitaalse kujutise
infosüsteemi hiljemalt 31.12.2023.
4. Vastutus
4.1. Kultuuriministeerium ei vastuta infosüsteemis esitatud andmete õigsuse eest.
4.2. Kultuuriministeerium ei hüvita muuseumile kahju, mis on tekkinud infosüsteemis tehniliste tõrgete
tõttu.
4.3. Kultuuriministeerium säilitab andmed infosüsteemis vastavalt tehnika arengu tasemele ning
võimalusel arendab infosüsteemi.
5. Vääramatu jõud
5.1. Lepingu rikkumine on vabandatav, kui kohustuse rikkumise põhjuseks on vääramatu jõud
võlaõigusseaduse § 103 tähenduses. Muu hulgas mõistavad pooled vääramatu jõu all õigusakti (nt
riigieelarve seaduse muutmise seaduse või riigi lisaeelarve seaduse) jõustumist, mis takistab oluliselt
lepingu täitmist või muudab selle võimatuks.
5.2. Pool peab teist poolt vääramatu jõu asjaolude ilmnemisest ja lõppemisest kohe teavitama.
5.3. Kui vääramatu jõud kestab kauem kui 3 kuud, on mõlemal poolel õigus leping lõpetada.
6. Lepingu jõustumine, muutmine ja lõppemine
6.1. Leping jõustub, kui mõlema poole esindajad on lepingu allkirjastanud.
6.2. Lepingut võib muuta poolte kirjaliku või kirjalikku taasesitamist võimaldavas vormis kokkuleppega,
mis vormistatakse lepingu lisana.
6.3. Leping lõpeb:
6.3.1. infosüsteemi sulgemisega;
6.3.2. poolte kokkuleppel;
6.3.3. ühepoolselt, teatades sellest teisele poolele ette vähemalt 3 kuud;
6.3.4. muul seadusest tuleneval alusel.
6.4. Lepingu lõppemisel lõpevad lihtlitsentsid, lõpetatakse andmete kuvamine infosüsteemi avalikkusele
ligipääsetavas osas ning andmed märgitakse kustutatuks.
6.5. Lepingu lõppemisel antakse muuseumile üle muuseumi museaalide metaandmed CSV formaadis
lepingu lõppemise päeva seisuga. Üleantavad andmed ei kajasta muuseumi poolt kasutamisperioodi
jooksul tehtud muudatusi ja parandusi juhul, kui need ei kajastu lepingu lõppemise päeval
aktuaalsetes museaalide metaandmete kirjeldustes. Muul viisil ja formaadis andmete üleandmise osas
võivad pooled eraldi kokku leppida. Muul viisil ja formaadis andmete üleandmisel tekkivad kulud
kannab muuseum juhul, kui pooled ei ole kokku leppinud teisiti.
Allkirjastatud digitaalselt
7. Lõppsätted
7.1. Lepinguga seotud teabe vahetamiseks määratud kontaktisikud:
7.1.1 Kultuuriministeeriumi kontaktisik on Kadri Nigulas,
[email protected], 6282352.
7.1.2 Muuseumi kontaktisik on Siiri Ries,
[email protected], 668 0840.
7.2. Lepinguga reguleerimata küsimustes lähtuvad pooled Eesti Vabariigi õigusaktidest.
7.3. Lepingust tulenevad vaidlused lahendatakse läbirääkimiste teel. Kokkuleppe mittesaavutamisel
lahendatakse vaidlused kohtus.
Kultuuriministeerium Eesti Pank
Registrikood: 70000941 Registrikood: 74000174
E-posti aadress:
[email protected] E-posti aadress:
[email protected]
(allkirjastatud digitaalselt) (allkirjastatud digitaalselt)
Indrek Saar Raoul Lättemäe
minister rahvusvaheliste ja avalike suhete osakonna juhataja
Allkirjastatud digitaalselt
Lisa 1
Muuseumide infosüsteemi (edaspidi infosüsteem) turvanõuded
1. Infosüsteemi kasutajaõiguste andmisel lähtutakse kultuuriministri 08.07.2013 määruse nr 32
„Muuseumide andmekogu asutamine ja põhimäärus“ §-st 6.
2. Kasutusõiguse realiseerimiseks loob muuseumi juhi poolt määratud MuISi vastutav isik (edaspidi
peakasutaja) uuele kasutajale MuISi kasutajakonto. Kasutajaõiguste andmise, muutmise või
äravõtmise vajadusest informeerib peakasutajat isik, kelle otseses alluvuses tööl või kelle juures
praktikal või teaduslikul uurimistööl kasutaja on.
3. Kasutajaõigused on isiklikud ja ei ole üleantavad. Kasutaja vastutab kõigi toimingute eest, mis on
teostatud tema kasutajatunnust kasutades.
4. Kasutaja identifitseeritakse kasutajatunnuse ja ID-kaardi, mobiil-ID või parooli abil. Turvalisuse
huvides peab kasutaja eelistama ID-kaarti või mobiil-ID-d.
5. Parooli tuleb vahetada vähemalt üks kord aastas, seda ka siis, kui infosüsteem seda kasutajalt
automaatselt ei nõua.
6. Parooli tuleb vahetada viivitamatult, kui on tekkinud kahtlus selle avalikuks tulemisest.
7. Parool ei tohi olla salvestatud veebilehitsejasse.
8. Parool peab olema vähemalt kaheksa tähemärki pikk, sisaldama väikseid ja suuri tähti ning
numbreid.
9. Paroolis on keelatud kasutada täpitähti.
10. Keelatud on kasutada vanu paroole uuesti.
11. Parool ei tohi olla seostatav millegagi, mis võiks kolmandale isikule kasutaja kohta teada olla,
näiteks:
11.1. kasutajatunnus või kasutajatunnus tagurpidi kirjutatuna;
11.2. kasutaja või tema lähedase ees- või perekonnanimi või kasutaja või tema lähedase ees- või
perekonnanimi tagurpidi kirjutatuna;
11.3. kasutaja või tema lähedaste sünnidaatum.
12. Infosüsteemi kasutamisel on eelistatud muuseumile kuuluv paikne riistvara.
13. Infosüsteemi kasutamisel mobiilseadmega (sülearvutid ja nutiseadmed) peab selle valdaja vältima
selle väärkasutust (näiteks seadme mittekasutamisel lukustama ekraani) ning kindlustama, et
mobiilseadmel oleks toimiv ning ajakohane pahavaratõrje tarkvara.
14. Infosüsteemi kasutamisel on keelatud:
14.1. kasutajatunnuse ning parooli üleandmine kolmandale isikule;
14.2. infosüsteemi kasutusjuhendis märkimata vormingus faili üles laadimine;
14.3. pahavara sisaldavate failide üles laadimine.
Allkirjastatud digitaalselt
MUUSEUMIDE INFOSÜSTEEMI KASUTAMISE
L E P I N G nr 6-9.1/115-1
Kultuuriministeerium ja SA Eesti Piimandusmuuseum (edaspidi muuseum), edaspidi eraldi pool või
koos pooled, on sõlminud käesoleva muuseumide infosüsteemi kasutamise lepingu (edaspidi leping)
alljärgnevas.
1. Üldsätted
1.1. Lepingu eesmärk on kokku leppida muuseumiseaduse § 15 alusel asutatud muuseumide andmekogu,
ametliku nimega „Muuseumide infosüsteem” (edaspidi infosüsteem), kasutamise tingimused.
1.2. Infosüsteem on andmebaas, mille tegijaks autoriõiguse seaduse (edaspidi AutÕS) § 75 3 mõistes on
Kultuuriministeerium.
1.3. Lepingu täitmisel juhindutakse muuseumiseadusest ja selle rakendusaktidest ning infosüsteemi
kasutusjuhenditest.
2. Poolte õigused
2.1. Muuseumil on õigus:
2.1.1. kasutada infosüsteemi museaalide, hoiule võetud asjade ja abikogusse arvatud asjade
metaandmete ja digitaalsete kujutiste (edaspidi andmete) elektrooniliseks haldamiseks ja
säilitamiseks;
2.1.2. sisestada, muuta ja kustutada tema poolt sisestatud andmeid, järgides kultuuriministri
08.07.2013. a määruses nr 30 „Muuseumikogu täiendamise ja kultuuriväärtusega asja
muuseumisse hoiule võtmise kord“, 08.07.2013. a määruses nr 31 „Museaali ja muuseumisse
kauemaks kui aastaks hoiule võetud asja märgistamise ja säilitamise kord“ ning 08.07.2013. a
määruses nr 32 „Muuseumide andmekogu asutamine ja põhimäärus“ sätestatud nõudeid. Kui
museaal on autoriõigusega kaitstav teos, siis teeb muuseum sellest digitaalse kujutise AutÕS §
20 lg 1 p 4 alusel ning see tehakse üldsusele kättesaadavaks infosüsteemis AutÕS § 20 lg 3
tingimustel;
2.1.3. kasutada infosüsteemis sisalduvaid tema poolt sisestatud andmeid ning muuseumile mõeldud
loogilist infosüsteemi osa, millele puudub juurdepääs teistel kasutajatel;
2.1.4. lihtlitsentsi alusel teha tasuta väljavõtteid infosüsteemis olevatest andmetest. Väljavõtte
tegemiseks loetakse infosüsteemis olevate andmete mis tahes viisil või mis tahes vormis ajutist
või alalist ülekandmist teise väljendusvormi;
2.1.5. koostada ning käivitada päringuid museaalide, hoiule võetud asjade ja abikogusse arvatud
asjade ning nendega seotud tegevuste ja dokumentide kohta;
2.1.6. saada Kultuuriministeeriumilt nõustamist muuseumikogu korraldamisel ning muuseumi
ülesannete täitmisel.
2.2. Kultuuriministeeriumil on õigus:
2.2.1. teha üldsusele kättesaadavaks avalikkusele suunatud andmeid. Muuseum annab selleks
lihtlitsentsi kogu autoriõiguse tähtaja ulatuses ning litsents kehtib Eestis ja kõigis välisriikides.
Kultuuriministeeriumil on õigus anda vastavaid all-litsentse. Andmed tehakse üldsusele
kättesaadavaks järgneva litsentsi alusel: The Creative Commons Universal Public Domain
Dedication (CC0 1.0). Kui digitaalne kujutis on autoriõigusega kaitstav teos või digitaalsel
kujutisel on kujutatud autoriõigusega kaitstav teos, siis neile CC0 litsents ei kohaldu;
2.2.2. muuseumi antud lihtlitsentsi alusel kasutada andmeid infosüsteemis ja Europeana
andmebaasides ning otsingusüsteemides;
2.2.3. anda avalikkusele suunatud juurdepääsupiiranguta andmeid üldsusele kasutada ilma tasu ja
piiranguteta, sh ärikasutuse jaoks;
2.2.4. kasutada avalikkusele suunatud juurdepääsupiiranguta andmeid infosüsteemi tutvustamiseks;
2.2.5. sulgeda avalik juurdepääs andmetele juhul, kui see on vajalik andmete korrastamiseks,
isikuandmete või autoriõiguste kaitse tagamiseks. Kultuuriministeerium teavitab viivitamatult
selliste muudatuste tegemisest muuseumit.
Allkirjastatud digitaalselt
3. Poolte kohustused
3.1. Muuseum kohustub:
3.1.1. järgima infosüsteemi kasutusjuhendit ja turvanõudeid (lepingu lisa 1), tutvustama infosüsteemi
turvanõudeid kõigile infosüsteemi kasutavatele töötajatele enne esmast sisselogimist ning
tegema turvanõuded neile kättesaadavaks;
3.1.2. andmete sisestamisel järgima isikuandmete kaitse seadusest tulenevaid nõudeid. Kui
avalikustatakse museaali digitaalne kujutis, millel on kujutatud isik, siis eeldatakse, et isik on
eelnevalt andnud nõusoleku kujutise kasutamiseks. Kui isik nõuab oma isikukujutise ja või
teiste isikuandmete eemaldamist infosüsteemist, siis peab muuseum vastavad andmed
eemaldama infosüsteemi osast, mis on ligipääsetav avalikkusele;
4. Vastutus
4.1. Kultuuriministeerium ei vastuta infosüsteemis esitatud andmete õigsuse eest.
4.2. Kultuuriministeerium ei hüvita muuseumile kahju, mis on tekkinud infosüsteemis tehniliste tõrgete
tõttu.
4.3. Kultuuriministeerium säilitab andmed infosüsteemis vastavalt tehnika arengu tasemele ning
võimalusel arendab infosüsteemi.
5. Vääramatu jõud
5.1. Lepingu rikkumine on vabandatav, kui kohustuse rikkumise põhjuseks on vääramatu jõud
võlaõigusseaduse § 103 tähenduses. Muu hulgas mõistavad pooled vääramatu jõu all õigusakti (nt
riigieelarve seaduse muutmise seaduse või riigi lisaeelarve seaduse) jõustumist, mis takistab oluliselt
lepingu täitmist või muudab selle võimatuks.
5.2. Pool peab teist poolt vääramatu jõu asjaolude ilmnemisest ja lõppemisest kohe teavitama.
5.3. Kui vääramatu jõud kestab kauem kui 3 kuud, on mõlemal poolel õigus leping lõpetada.
6. Lepingu jõustumine, muutmine ja lõppemine
6.1. Leping jõustub, kui mõlema poole esindajad on lepingu digitaalselt allkirjastanud.
6.2. Lepingut võib muuta poolte kirjaliku või kirjalikku taasesitamist võimaldavas vormis kokkuleppega,
mis vormistatakse lepingu lisana.
6.3. Leping lõpeb:
6.3.1. infosüsteemi sulgemisega;
6.3.2. poolte kokkuleppel;
6.3.3. ühepoolselt, teatades sellest teisele poolele ette vähemalt 3 kuud;
6.3.4. muul seadusest tuleneval alusel.
6.4. Lepingu lõppemisel lõpevad lihtlitsentsid, lõpetatakse andmete kuvamine infosüsteemi avalikkusele
ligipääsetavas osas ning andmed märgitakse kustutatuks.
6.5. Lepingu lõppemisel antakse muuseumile üle muuseumi museaalide metaandmed CSV formaadis
lepingu lõppemise päeva seisuga. Üleantavad andmed ei kajasta muuseumi poolt kasutamisperioodi
jooksul tehtud muudatusi ja parandusi juhul, kui need ei kajastu lepingu lõppemise päeval
aktuaalsetes museaalide metaandmete kirjeldustes. Muul viisil ja formaadis andmete üleandmise osas
võivad pooled eraldi kokku leppida. Muul viisil ja formaadis andmete üleandmisel tekkivad kulud
kannab muuseum juhul, kui pooled ei ole kokku leppinud teisiti.
Allkirjastatud digitaalselt
7. Lõppsätted
7.1. Lepinguga seotud teabe vahetamiseks määratud kontaktisikud:
7.1.1 Kultuuriministeeriumi kontaktisik on Kadri Nigulas,
[email protected], 6282352.
7.1.2 Muuseumi kontaktisik on Mailis Kutsar,
[email protected], 38 97 533.
7.2 Lepinguga reguleerimata küsimustes lähtuvad pooled Eesti Vabariigi õigusaktidest.
7.3 Lepingust tulenevad vaidlused lahendatakse läbirääkimiste teel. Kokkuleppe mittesaavutamisel
lahendatakse vaidlused kohtus.
Kultuuriministeerium SA Eesti Piimandusmuuseum
Registrikood: 70000941 Registrikood: 90014135
E-posti aadress:
[email protected] E-posti aadress:
[email protected]
(allkirjastatud digitaalselt) (allkirjastatud digitaalselt)
Indrek Saar Anneli Siimussaar
minister juhatuse liige
Allkirjastatud digitaalselt
Lisa 1
Muuseumide infosüsteemi (edaspidi infosüsteem) turvanõuded
1. Infosüsteemi kasutajaõiguste andmisel lähtutakse kultuuriministri 08.07.2013 määruse nr 32
„Muuseumide andmekogu asutamine ja põhimäärus“ §-st 6.
2. Kasutusõiguse realiseerimiseks loob muuseumi juhi poolt määratud MuISi vastutav isik (edaspidi
peakasutaja) uuele kasutajale MuISi kasutajakonto. Kasutajaõiguste andmise, muutmise või
äravõtmise vajadusest informeerib peakasutajat isik, kelle otseses alluvuses tööl või kelle juures
praktikal või teaduslikul uurimistööl kasutaja on.
3. Kasutajaõigused on isiklikud ja ei ole üleantavad. Kasutaja vastutab kõigi toimingute eest, mis on
teostatud tema kasutajatunnust kasutades.
4. Kasutaja identifitseeritakse kasutajatunnuse ja ID-kaardi, mobiil-ID või parooli abil. Turvalisuse
huvides peab kasutaja eelistama ID-kaarti või mobiil-ID-d.
5. Parooli tuleb vahetada vähemalt üks kord aastas, seda ka siis, kui infosüsteem seda kasutajalt
automaatselt ei nõua.
6. Parooli tuleb vahetada viivitamatult, kui on tekkinud kahtlus selle avalikuks tulemisest.
7. Parool ei tohi olla salvestatud veebilehitsejasse.
8. Parool peab olema vähemalt kaheksa tähemärki pikk, sisaldama väikseid ja suuri tähti ning numbreid.
9. Paroolis on keelatud kasutada täpitähti.
10. Keelatud on kasutada vanu paroole uuesti.
11. Parool ei tohi olla seostatav millegagi, mis võiks kolmandale isikule kasutaja kohta teada olla,
näiteks:
11.1. kasutajatunnus või kasutajatunnus tagurpidi kirjutatuna;
11.2. kasutaja või tema lähedase ees- või perekonnanimi või kasutaja või tema lähedase ees- või
perekonnanimi tagurpidi kirjutatuna;
11.3. kasutaja või tema lähedase sünnidaatum.
12. Infosüsteemi kasutamisel on eelistatud muuseumile kuuluv paikne riistvara.
13. Infosüsteemi kasutamisel mobiilseadmega (sülearvutid ja nutiseadmed) peab selle valdaja vältima
selle väärkasutust (näiteks seadme mittekasutamisel lukustama ekraani) ning kindlustama, et
mobiilseadmel oleks toimiv ning ajakohane pahavaratõrje tarkvara.
14. Infosüsteemi kasutamisel on keelatud:
14.1. kasutajatunnuse ning parooli üleandmine kolmandale isikule;
14.2. infosüsteemi kasutusjuhendis märkimata vormingus faili üles laadimine;
14.3. pahavara sisaldava faili üles laadimine.
Allkirjastatud digitaalselt
MUUSEUMIDE INFOSÜSTEEMI KASUTAMISE
L E P I N G nr 6-9.1/117-1
Kultuuriministeerium ja SA Eesti Maaelumuuseumid (edaspidi muuseum), edaspidi eraldi pool või
koos pooled, on sõlminud käesoleva muuseumide infosüsteemi kasutamise lepingu (edaspidi leping)
alljärgnevas.
1. Üldsätted
1.1. Lepingu eesmärk on kokku leppida muuseumiseaduse § 15 alusel asutatud muuseumide andmekogu,
ametliku nimega „Muuseumide infosüsteem” (edaspidi infosüsteem), kasutamise tingimused.
1.2. Infosüsteem on andmebaas, mille tegijaks autoriõiguse seaduse (edaspidi AutÕS) § 75 3 mõistes on
Kultuuriministeerium.
1.3. Lepingu täitmisel juhindutakse muuseumiseadusest ja selle rakendusaktidest ning infosüsteemi
kasutusjuhenditest.
2. Poolte õigused
2.1. Muuseumil on õigus:
2.1.1. kasutada infosüsteemi museaalide, hoiule võetud asjade ja abikogusse arvatud asjade
metaandmete ja digitaalsete kujutiste (edaspidi andmete) elektrooniliseks haldamiseks ja
säilitamiseks;
2.1.2. sisestada, muuta ja kustutada tema poolt sisestatud andmeid, järgides kultuuriministri
08.07.2013. a määruses nr 30 „Muuseumikogu täiendamise ja kultuuriväärtusega asja
muuseumisse hoiule võtmise kord“, 08.07.2013. a määruses nr 31 „Museaali ja muuseumisse
kauemaks kui aastaks hoiule võetud asja märgistamise ja säilitamise kord“ ning 08.07.2013. a
määruses nr 32 „Muuseumide andmekogu asutamine ja põhimäärus“ sätestatud nõudeid. Kui
museaal on autoriõigusega kaitstav teos, siis teeb muuseum sellest digitaalse kujutise AutÕS §
20 lg 1 p 4 alusel ning see tehakse üldsusele kättesaadavaks infosüsteemis AutÕS § 20 lg 3
tingimustel;
2.1.3. kasutada infosüsteemis sisalduvaid tema poolt sisestatud andmeid ning muuseumile mõeldud
loogilist infosüsteemi osa, millele puudub juurdepääs teistel kasutajatel;
2.1.4. lihtlitsentsi alusel teha tasuta väljavõtteid infosüsteemis olevatest andmetest. Väljavõtte
tegemiseks loetakse infosüsteemis olevate andmete mis tahes viisil või mis tahes vormis ajutist
või alalist ülekandmist teise väljendusvormi;
2.1.5. koostada ning käivitada päringuid museaalide, hoiule võetud asjade ja abikogusse arvatud
asjade ning nendega seotud tegevuste ja dokumentide kohta;
2.1.6. saada Kultuuriministeeriumilt nõustamist muuseumikogu korraldamisel ning muuseumi
ülesannete täitmisel.
2.2. Kultuuriministeeriumil on õigus:
2.2.1. teha üldsusele kättesaadavaks avalikkusele suunatud andmeid. Muuseum annab selleks
lihtlitsentsi kogu autoriõiguse tähtaja ulatuses ning litsents kehtib Eestis ja kõigis välisriikides.
Kultuuriministeeriumil on õigus anda vastavaid all-litsentse. Andmed tehakse üldsusele
kättesaadavaks järgneva litsentsi alusel: The Creative Commons Universal Public Domain
Dedication (CC0 1.0). Kui digitaalne kujutis on autoriõigusega kaitstav teos või digitaalsel
kujutisel on kujutatud autoriõigusega kaitstav teos, siis neile CC0 litsents ei kohaldu;
2.2.2. muuseumi antud lihtlitsentsi alusel kasutada andmeid infosüsteemis ja Europeana
andmebaasides ning otsingusüsteemides;
2.2.3. anda avalikkusele suunatud juurdepääsupiiranguta andmeid üldsusele kasutada ilma tasu ja
piiranguteta, sh ärikasutuse jaoks;
2.2.4. kasutada avalikkusele suunatud juurdepääsupiiranguta andmeid infosüsteemi tutvustamiseks;
2.2.5. sulgeda avalik juurdepääs andmetele juhul, kui see on vajalik andmete korrastamiseks,
isikuandmete või autoriõiguste kaitse tagamiseks. Kultuuriministeerium teavitab viivitamatult
selliste muudatuste tegemisest muuseumit.
3. Poolte kohustused
3.1. Muuseum kohustub:
Allkirjastatud digitaalselt
3.1.1. järgima infosüsteemi kasutusjuhendit ja turvanõudeid (lepingu lisa 1), tutvustama infosüsteemi
turvanõudeid kõigile infosüsteemi kasutavatele töötajatele enne esmast sisselogimist ning
tegema turvanõuded neile kättesaadavaks;
3.1.2. andmete sisestamisel järgima isikuandmete kaitse seadusest tulenevaid nõudeid. Kui
avalikustatakse museaali digitaalne kujutis, millel on kujutatud isik, siis eeldatakse, et isik on
eelnevalt andnud nõusoleku kujutise kasutamiseks. Kui isik nõuab oma isikukujutise ja või
teiste isikuandmete eemaldamist infosüsteemist, siis peab muuseum vastavad andmed
eemaldama infosüsteemi osast, mis on ligipääsetav avalikkusele;
4. Vastutus
4.1. Kultuuriministeerium ei vastuta infosüsteemis esitatud andmete õigsuse eest.
4.2. Kultuuriministeerium ei hüvita muuseumile kahju, mis on tekkinud infosüsteemis tehniliste tõrgete
tõttu.
4.3. Kultuuriministeerium säilitab andmed infosüsteemis vastavalt tehnika arengu tasemele ning
võimalusel arendab infosüsteemi.
5. Vääramatu jõud
5.1. Lepingu rikkumine on vabandatav, kui kohustuse rikkumise põhjuseks on vääramatu jõud
võlaõigusseaduse § 103 tähenduses. Muu hulgas mõistavad pooled vääramatu jõu all õigusakti (nt
riigieelarve seaduse muutmise seaduse või riigi lisaeelarve seaduse) jõustumist, mis takistab oluliselt
lepingu täitmist või muudab selle võimatuks.
5.2. Pool peab teist poolt vääramatu jõu asjaolude ilmnemisest ja lõppemisest kohe teavitama.
5.3. Kui vääramatu jõud kestab kauem kui 3 kuud, on mõlemal poolel õigus leping lõpetada.
6. Lepingu jõustumine, muutmine ja lõppemine
6.1. Leping jõustub, kui mõlema poole esindajad on lepingu digitaalselt allkirjastanud.
6.2. Lepingut võib muuta poolte kirjaliku või kirjalikku taasesitamist võimaldavas vormis kokkuleppega,
mis vormistatakse lepingu lisana.
6.3. Leping lõpeb:
6.3.1. infosüsteemi sulgemisega;
6.3.2. poolte kokkuleppel;
6.3.3. ühepoolselt, teatades sellest teisele poolele ette vähemalt 3 kuud;
6.3.4. muul seadusest tuleneval alusel.
6.4. Lepingu lõppemisel lõpevad lihtlitsentsid, lõpetatakse andmete kuvamine infosüsteemi avalikkusele
ligipääsetavas osas ning andmed märgitakse kustutatuks.
6.5. Lepingu lõppemisel antakse muuseumile üle muuseumi museaalide metaandmed CSV formaadis
lepingu lõppemise päeva seisuga. Üleantavad andmed ei kajasta muuseumi poolt kasutamisperioodi
jooksul tehtud muudatusi ja parandusi juhul, kui need ei kajastu lepingu lõppemise päeval
aktuaalsetes museaalide metaandmete kirjeldustes. Muul viisil ja formaadis andmete üleandmise osas
võivad pooled eraldi kokku leppida. Muul viisil ja formaadis andmete üleandmisel tekkivad kulud
kannab muuseum juhul, kui pooled ei ole kokku leppinud teisiti.
7. Lõppsätted
7.1. Lepinguga seotud teabe vahetamiseks määratud kontaktisikud:
7.1.1 Kultuuriministeeriumi kontaktisik on Kadri Nigulas,
[email protected], 6282352.
7.1.2 Muuseumi kontaktisik on Kaire Ilula,
[email protected], 738 3814.
7.2 Lepinguga reguleerimata küsimustes lähtuvad pooled Eesti Vabariigi õigusaktidest.
7.3 Lepingust tulenevad vaidlused lahendatakse läbirääkimiste teel. Kokkuleppe mittesaavutamisel
lahendatakse vaidlused kohtus.
Kultuuriministeerium SA Eesti Maaelumuuseumid
Registrikood: 70000941 Registrikood: 90014017
E-posti aadress:
[email protected] E-posti aadress:
[email protected]
(allkirjastatud digitaalselt) (allkirjastatud digitaalselt)
Indrek Saar Merli Sild
minister juhatuse liige
Allkirjastatud digitaalselt
Lisa 1
Muuseumide infosüsteemi (edaspidi infosüsteem) turvanõuded
1. Infosüsteemi kasutajaõiguste andmisel lähtutakse kultuuriministri 08.07.2013 määruse nr 32
„Muuseumide andmekogu asutamine ja põhimäärus“ §-st 6.
2. Kasutusõiguse realiseerimiseks loob muuseumi juhi poolt määratud MuISi vastutav isik (edaspidi
peakasutaja) uuele kasutajale MuISi kasutajakonto. Kasutajaõiguste andmise, muutmise või
äravõtmise vajadusest informeerib peakasutajat isik, kelle otseses alluvuses tööl või kelle juures
praktikal või teaduslikul uurimistööl kasutaja on.
3. Kasutajaõigused on isiklikud ja ei ole üleantavad. Kasutaja vastutab kõigi toimingute eest, mis on
teostatud tema kasutajatunnust kasutades.
4. Kasutaja identifitseeritakse kasutajatunnuse ja ID-kaardi, mobiil-ID või parooli abil. Turvalisuse
huvides peab kasutaja eelistama ID-kaarti või mobiil-ID-d.
5. Parooli tuleb vahetada vähemalt üks kord aastas, seda ka siis, kui infosüsteem seda kasutajalt
automaatselt ei nõua.
6. Parooli tuleb vahetada viivitamatult, kui on tekkinud kahtlus selle avalikuks tulemisest.
7. Parool ei tohi olla salvestatud veebilehitsejasse.
8. Parool peab olema vähemalt kaheksa tähemärki pikk, sisaldama väikseid ja suuri tähti ning numbreid.
9. Paroolis on keelatud kasutada täpitähti.
10. Keelatud on kasutada vanu paroole uuesti.
11. Parool ei tohi olla seostatav millegagi, mis võiks kolmandale isikule kasutaja kohta teada olla,
näiteks:
11.1. kasutajatunnus või kasutajatunnus tagurpidi kirjutatuna;
11.2. kasutaja või tema lähedase ees- või perekonnanimi või kasutaja või tema lähedase ees- või
perekonnanimi tagurpidi kirjutatuna;
11.3. kasutaja või tema lähedase sünnidaatum.
12. Infosüsteemi kasutamisel on eelistatud muuseumile kuuluv paikne riistvara.
13. Infosüsteemi kasutamisel mobiilseadmega (sülearvutid ja nutiseadmed) peab selle valdaja vältima
selle väärkasutust (näiteks seadme mittekasutamisel lukustama ekraani) ning kindlustama, et
mobiilseadmel oleks toimiv ning ajakohane pahavaratõrje tarkvara.
14. Infosüsteemi kasutamisel on keelatud:
14.1. kasutajatunnuse ning parooli üleandmine kolmandale isikule;
14.2. infosüsteemi kasutusjuhendis märkimata vormingus faili üles laadimine;
14.3. pahavara sisaldava faili üles laadimine.
Allkirjastatud digitaalselt
MUUSEUMIDE INFOSÜSTEEMI KASUTAMISE
L E P I N G nr 6-9.1/116-1
Kultuuriministeerium ja SA Ikoonimuuseum (edaspidi muuseum), edaspidi eraldi pool või koos
pooled, on sõlminud käesoleva muuseumide infosüsteemi kasutamise lepingu (edaspidi leping)
alljärgnevas.
1. Üldsätted
1.1. Lepingu eesmärk on kokku leppida muuseumiseaduse § 15 alusel asutatud muuseumide andmekogu,
ametliku nimega „Muuseumide infosüsteem” (edaspidi infosüsteem), kasutamise tingimused.
1.2. Infosüsteem on andmebaas, mille tegijaks autoriõiguse seaduse (edaspidi AutÕS) § 75 3 mõistes on
Kultuuriministeerium.
1.3. Lepingu täitmisel juhindutakse muuseumiseadusest ja selle rakendusaktidest ning infosüsteemi
kasutusjuhenditest. Muuseum on teadlik, et pärast käesoleva lepingu sõlmimist kohaldatakse tema
tegevusele muuseumiseaduse paragrahve 5, 6, 7, 11, 14, 15, 16, 22 ja 23.
2. Poolte õigused
2.1. Muuseumil on õigus:
2.1.1. kasutada infosüsteemi museaalide, hoiule võetud asjade ja abikogusse arvatud asjade
metaandmete ja digitaalsete kujutiste (edaspidi andmete) elektrooniliseks haldamiseks ja
säilitamiseks;
2.1.2. sisestada, muuta ja kustutada tema poolt sisestatud andmeid, järgides kultuuriministri
08.07.2013. a määruses nr 30 „Muuseumikogu täiendamise ja kultuuriväärtusega asja
muuseumisse hoiule võtmise kord“, 08.07.2013. a määruses nr 31 „Museaali ja muuseumisse
kauemaks kui aastaks hoiule võetud asja märgistamise ja säilitamise kord“ ning 08.07.2013. a
määruses nr 32 „Muuseumide andmekogu asutamine ja põhimäärus“ sätestatud nõudeid. Kui
museaal on autoriõigusega kaitstav teos, siis teeb muuseum sellest digitaalse kujutise AutÕS §
20 lg 1 p 4 alusel ning see tehakse üldsusele kättesaadavaks infosüsteemis AutÕS § 20 lg 3
tingimustel;
2.1.3. kasutada infosüsteemis sisalduvaid tema poolt sisestatud andmeid ning muuseumile mõeldud
loogilist infosüsteemi osa, millele puudub juurdepääs teistel kasutajatel;
2.1.4. lihtlitsentsi alusel teha tasuta väljavõtteid infosüsteemis olevatest andmetest. Väljavõtte
tegemiseks loetakse infosüsteemis olevate andmete mis tahes viisil või mis tahes vormis ajutist
või alalist ülekandmist teise väljendusvormi;
2.1.5. koostada ning käivitada päringuid museaalide, hoiule võetud asjade ja abikogusse arvatud
asjade ning nendega seotud tegevuste ja dokumentide kohta;
2.1.6. saada Kultuuriministeeriumilt nõustamist muuseumikogu korraldamisel ning muuseumi
ülesannete täitmisel.
2.2. Kultuuriministeeriumil on õigus:
2.2.1. teha üldsusele kättesaadavaks avalikkusele suunatud andmeid. Muuseum annab selleks
lihtlitsentsi kogu autoriõiguse tähtaja ulatuses ning litsents kehtib Eestis ja kõigis välisriikides.
Kultuuriministeeriumil on õigus anda vastavaid all-litsentse. Andmed tehakse üldsusele
kättesaadavaks järgneva litsentsi alusel: The Creative Commons Universal Public Domain
Dedication (CC0 1.0). Kui digitaalne kujutis on autoriõigusega kaitstav teos või digitaalsel
kujutisel on kujutatud autoriõigusega kaitstav teos, siis neile CC0 litsents ei kohaldu;
2.2.2. muuseumi antud lihtlitsentsi alusel kasutada andmeid infosüsteemis ja Europeana
andmebaasides ning otsingusüsteemides;
2.2.3. anda avalikkusele suunatud juurdepääsupiiranguta andmeid üldsusele kasutada ilma tasu ja
piiranguteta, sh ärikasutuse jaoks;
2.2.4. kasutada avalikkusele suunatud juurdepääsupiiranguta andmeid infosüsteemi tutvustamiseks;
2.2.5. sulgeda avalik juurdepääs andmetele juhul, kui see on vajalik andmete korrastamiseks,
isikuandmete või autoriõiguste kaitse tagamiseks. Kultuuriministeerium teavitab viivitamatult
selliste muudatuste tegemisest muuseumit.
Allkirjastatud digitaalselt
3. Poolte kohustused
3.1. Muuseum kohustub:
3.1.1. järgima infosüsteemi kasutusjuhendit ja turvanõudeid (lepingu lisa 1), tutvustama infosüsteemi
turvanõudeid kõigile infosüsteemi kasutavatele töötajatele enne esmast sisselogimist ning
tegema turvanõuded neile kättesaadavaks;
3.1.2. andmete sisestamisel järgima isikuandmete kaitse seadusest tulenevaid nõudeid. Kui
avalikustatakse museaali digitaalne kujutis, millel on kujutatud isik, siis eeldatakse, et isik on
eelnevalt andnud nõusoleku kujutise kasutamiseks. Kui isik nõuab oma isikukujutise ja või
teiste isikuandmete eemaldamist infosüsteemist, siis peab muuseum vastavad andmed
eemaldama infosüsteemi osast, mis on ligipääsetav avalikkusele;
3.1.3. läbi viima enne käesoleva lepingu sõlmimist arvele võetud museaalide esmase
dokumenteerimise ja kirjeldamise esimese etapi infosüsteemis kultuuriministri 08.07.2013. a
määruse nr 32 „Muuseumide andmekogu asutamine ja põhimäärus“ 2. peatükis esitatud nõuete
kohaselt kõige hiljem 30.06.2019;
3.1.4. lisama enne käesoleva lepingu sõlmimist arvele võetud museaali digitaalse kujutise
infosüsteemi kõige hiljem 31.12.2019.
4. Vastutus
4.1. Kultuuriministeerium ei vastuta infosüsteemis esitatud andmete õigsuse eest.
4.2. Kultuuriministeerium ei hüvita muuseumile kahju, mis on tekkinud infosüsteemis tehniliste tõrgete
tõttu.
4.3. Kultuuriministeerium säilitab andmed infosüsteemis vastavalt tehnika arengu tasemele ning
võimalusel arendab infosüsteemi.
5. Vääramatu jõud
5.1. Lepingu rikkumine on vabandatav, kui kohustuse rikkumise põhjuseks on vääramatu jõud
võlaõigusseaduse § 103 tähenduses. Muu hulgas mõistavad pooled vääramatu jõu all õigusakti (nt
riigieelarve seaduse muutmise seaduse või riigi lisaeelarve seaduse) jõustumist, mis takistab oluliselt
lepingu täitmist või muudab selle võimatuks.
5.2. Pool peab teist poolt vääramatu jõu asjaolude ilmnemisest ja lõppemisest kohe teavitama.
5.3. Kui vääramatu jõud kestab kauem kui 3 kuud, on mõlemal poolel õigus leping lõpetada.
6. Lepingu jõustumine, muutmine ja lõppemine
6.1. Leping jõustub, kui mõlema poole esindajad on lepingu digitaalselt allkirjastanud.
6.2. Lepingut võib muuta poolte kirjaliku või kirjalikku taasesitamist võimaldavas vormis kokkuleppega,
mis vormistatakse lepingu lisana.
6.3. Leping lõpeb:
6.3.1. infosüsteemi sulgemisega;
6.3.2. poolte kokkuleppel;
6.3.3. ühepoolselt, teatades sellest teisele poolele ette vähemalt 3 kuud;
6.3.4. muul seadusest tuleneval alusel.
6.4. Lepingu lõppemisel lõpevad lihtlitsentsid, lõpetatakse andmete kuvamine infosüsteemi avalikkusele
ligipääsetavas osas ning andmed märgitakse kustutatuks.
6.5. Lepingu lõppemisel antakse muuseumile üle muuseumi museaalide metaandmed CSV formaadis
lepingu lõppemise päeva seisuga. Üleantavad andmed ei kajasta muuseumi poolt kasutamisperioodi
jooksul tehtud muudatusi ja parandusi juhul, kui need ei kajastu lepingu lõppemise päeval
aktuaalsetes museaalide metaandmete kirjeldustes. Muul viisil ja formaadis andmete üleandmise osas
võivad pooled eraldi kokku leppida. Muul viisil ja formaadis andmete üleandmisel tekkivad kulud
kannab muuseum juhul, kui pooled ei ole kokku leppinud teisiti.
Allkirjastatud digitaalselt
7. Lõppsätted
7.1. Lepinguga seotud teabe vahetamiseks määratud kontaktisikud:
7.1.1 Kultuuriministeeriumi kontaktisik on Kadri Nigulas,
[email protected], 6282352.
7.1.2 Muuseumi kontaktisik on on Tiina Jurjeva,
[email protected], 6410057.
7.2 Lepinguga reguleerimata küsimustes lähtuvad pooled Eesti Vabariigi õigusaktidest.
7.3 Lepingust tulenevad vaidlused lahendatakse läbirääkimiste teel. Kokkuleppe mittesaavutamisel
lahendatakse vaidlused kohtus.
Kultuuriministeerium SA Ikoonimuuseum
Registrikood: 70000941 Registrikood: 90010930
E-posti aadress:
[email protected] E-posti aadress:
[email protected]
(allkirjastatud digitaalselt) (allkirjastatud digitaalselt)
Indrek Saar Raivo Touart
minister juhatuse liige
Allkirjastatud digitaalselt
Lisa 1
Muuseumide infosüsteemi (edaspidi infosüsteem) turvanõuded
1. Infosüsteemi kasutajaõiguste andmisel lähtutakse kultuuriministri 08.07.2013 määruse nr 32
„Muuseumide andmekogu asutamine ja põhimäärus“ §-st 6.
2. Kasutusõiguse realiseerimiseks loob muuseumi juhi poolt määratud MuISi vastutav isik (edaspidi
peakasutaja) uuele kasutajale MuISi kasutajakonto. Kasutajaõiguste andmise, muutmise või
äravõtmise vajadusest informeerib peakasutajat isik, kelle otseses alluvuses tööl või kelle juures
praktikal või teaduslikul uurimistööl kasutaja on.
3. Kasutajaõigused on isiklikud ja ei ole üleantavad. Kasutaja vastutab kõigi toimingute eest, mis on
teostatud tema kasutajatunnust kasutades.
4. Kasutaja identifitseeritakse kasutajatunnuse ja ID-kaardi, mobiil-ID või parooli abil. Turvalisuse
huvides peab kasutaja eelistama ID-kaarti või mobiil-ID-d.
5. Parooli tuleb vahetada vähemalt üks kord aastas, seda ka siis, kui infosüsteem seda kasutajalt
automaatselt ei nõua.
6. Parooli tuleb vahetada viivitamatult, kui on tekkinud kahtlus selle avalikuks tulemisest.
7. Parool ei tohi olla salvestatud veebilehitsejasse.
8. Parool peab olema vähemalt kaheksa tähemärki pikk, sisaldama väikseid ja suuri tähti ning numbreid.
9. Paroolis on keelatud kasutada täpitähti.
10. Keelatud on kasutada vanu paroole uuesti.
11. Parool ei tohi olla seostatav millegagi, mis võiks kolmandale isikule kasutaja kohta teada olla,
näiteks:
11.1. kasutajatunnus või kasutajatunnus tagurpidi kirjutatuna;
11.2. kasutaja või tema lähedase ees- või perekonnanimi või kasutaja või tema lähedase ees- või
perekonnanimi tagurpidi kirjutatuna;
11.3. kasutaja või tema lähedase sünnidaatum.
12. Infosüsteemi kasutamisel on eelistatud muuseumile kuuluv paikne riistvara.
13. Infosüsteemi kasutamisel mobiilseadmega (sülearvutid ja nutiseadmed) peab selle valdaja vältima
selle väärkasutust (näiteks seadme mittekasutamisel lukustama ekraani) ning kindlustama, et
mobiilseadmel oleks toimiv ning ajakohane pahavaratõrje tarkvara.
14. Infosüsteemi kasutamisel on keelatud:
14.1. kasutajatunnuse ning parooli üleandmine kolmandale isikule;
14.2. infosüsteemi kasutusjuhendis märkimata vormingus faili üles laadimine;
14.3. pahavara sisaldava faili üles laadimine.
Allkirjastatud digitaalselt
MUUSEUMIDE INFOSÜSTEEMI KASUTAMISE
L E P I N G nr 6-9.1/133-1
Kultuuriministeerium ja Järvakandi Klaasimuuseum (edaspidi muuseum), edaspidi eraldi pool või
koos pooled, on sõlminud käesoleva muuseumide infosüsteemi kasutamise lepingu (edaspidi leping)
alljärgnevas.
1. Üldsätted
1.1. Lepingu eesmärk on kokku leppida muuseumiseaduse § 15 alusel asutatud muuseumide andmekogu,
ametliku nimega „Muuseumide infosüsteem” (edaspidi infosüsteem), kasutamise tingimused.
1.2. Infosüsteem on andmebaas, mille tegijaks autoriõiguse seaduse (edaspidi AutÕS) § 75 3 mõistes on
Kultuuriministeerium.
1.3. Lepingu täitmisel juhindutakse muuseumiseadusest ja selle rakendusaktidest ning infosüsteemi
kasutusjuhenditest. Muuseum on teadlik, et pärast käesoleva lepingu sõlmimist kohaldatakse tema
tegevusele muuseumiseaduse paragrahve 5, 6, 7, 11, 14, 15, 16, 22 ja 23.
2. Poolte õigused
2.1. Muuseumil on õigus:
2.1.1. kasutada infosüsteemi museaalide, hoiule võetud asjade ja abikogusse arvatud asjade
metaandmete ja digitaalsete kujutiste (edaspidi andmete) elektrooniliseks haldamiseks ja
säilitamiseks;
2.1.2. sisestada, muuta ja kustutada tema poolt sisestatud andmeid, järgides kultuuriministri
08.07.2013.a määruses nr 30 „Muuseumikogu täiendamise ja kultuuriväärtusega asja
muuseumisse hoiule võtmise kord“, 08.07.2013. a määruses nr 31 „Museaali ja muuseumisse
kauemaks kui aastaks hoiule võetud asja märgistamise ja säilitamise kord“ ning 08.07.2013. a
määruses nr 32 „Muuseumide andmekogu asutamine ja põhimäärus“ sätestatud nõudeid. Kui
museaal on autoriõigusega kaitstav teos, siis teeb muuseum sellest digitaalse kujutise AutÕS §
20 lg 1 p 4 alusel ning see tehakse üldsusele kättesaadavaks infosüsteemis AutÕS § 20 lg 3
tingimustel;
2.1.3. kasutada infosüsteemis sisalduvaid tema poolt sisestatud andmeid ning muuseumile mõeldud
loogilist infosüsteemi osa, millele puudub juurdepääs teistel kasutajatel;
2.1.4. lihtlitsentsi alusel teha tasuta väljavõtteid infosüsteemis olevatest andmetest. Väljavõtte
tegemiseks loetakse infosüsteemis olevate andmete mis tahes viisil või mis tahes vormis ajutist
või alalist ülekandmist teise väljendusvormi;
2.1.5. koostada ning käivitada päringuid museaalide, hoiule võetud asjade ja abikogusse arvatud
asjade ning nendega seotud tegevuste ja dokumentide kohta;
2.1.6. saada Kultuuriministeeriumilt nõustamist muuseumikogu korraldamisel ning muuseumi
ülesannete täitmisel.
2.2. Kultuuriministeeriumil on õigus:
2.2.1. teha üldsusele kättesaadavaks avalikkusele suunatud andmeid. Muuseum annab selleks
lihtlitsentsi kogu autoriõiguse tähtaja ulatuses ning litsents kehtib Eestis ja kõigis välisriikides.
Kultuuriministeeriumil on õigus anda vastavaid all-litsentse. Andmed tehakse üldsusele
kättesaadavaks järgneva litsentsi alusel: The Creative Commons Universal Public Domain
Dedication (CC0 1.0). Kui digitaalne kujutis on autoriõigusega kaitstav teos või digitaalsel
kujutisel on kujutatud autoriõigusega kaitstav teos, siis neile CC0 litsents ei kohaldu;
2.2.2. muuseumi antud lihtlitsentsi alusel kasutada andmeid infosüsteemis ja Europeana
andmebaasides ning otsingusüsteemides;
2.2.3. anda avalikkusele suunatud juurdepääsupiiranguta andmeid üldsusele kasutada ilma tasu ja
piiranguteta, sh ärikasutuse jaoks;
2.2.4. kasutada avalikkusele suunatud juurdepääsupiiranguta andmeid infosüsteemi tutvustamiseks;
2.2.5. sulgeda avalik juurdepääs andmetele juhul, kui see on vajalik andmete korrastamiseks,
isikuandmete või autoriõiguste kaitse tagamiseks. Kultuuriministeerium teavitab viivitamatult
selliste muudatuste tegemisest muuseumit.
Allkirjastatud digitaalselt
3. Poolte kohustused
3.1. Muuseum kohustub:
3.1.1. järgima infosüsteemi kasutusjuhendit ja turvanõudeid (lepingu lisa 1), tutvustama infosüsteemi
turvanõudeid kõigile infosüsteemi kasutavatele töötajatele enne esmast sisselogimist ning
tegema turvanõuded neile kättesaadavaks;
3.1.2. andmete sisestamisel järgima isikuandmete kaitse seadusest tulenevaid nõudeid. Kui
avalikustatakse museaali digitaalne kujutis, millel on kujutatud isik, siis eeldatakse, et isik on
eelnevalt andnud nõusoleku kujutise kasutamiseks. Kui isik nõuab oma isikukujutise ja või
teiste isikuandmete eemaldamist infosüsteemist, siis peab muuseum vastavad andmed
eemaldama infosüsteemi osast, mis on ligipääsetav avalikkusele;
3.1.3. läbi viima enne käesoleva lepingu sõlmimist arvele võetud museaalide esmase
dokumenteerimise ja kirjeldamise esimese etapi infosüsteemis kultuuriministri 08.07.2013. a
määruse nr 32 „Muuseumide andmekogu asutamine ja põhimäärus“ 2. peatükis esitatud nõuete
kohaselt kõige hiljem 31.12.2020;
3.1.4. lisama enne käesoleva lepingu sõlmimist arvele võetud museaali digitaalse kujutise
infosüsteemi kõige hiljem 31.12.2020.
4. Vastutus
4.1. Kultuuriministeerium ei vastuta infosüsteemis esitatud andmete õigsuse eest.
4.2. Kultuuriministeerium ei hüvita muuseumile kahju, mis on tekkinud infosüsteemis tehniliste tõrgete
tõttu.
4.3. Kultuuriministeerium säilitab andmed infosüsteemis vastavalt tehnika arengu tasemele ning
võimalusel arendab infosüsteemi.
5. Vääramatu jõud
5.1. Lepingu rikkumine on vabandatav, kui kohustuse rikkumise põhjuseks on vääramatu jõud
võlaõigusseaduse § 103 tähenduses. Muu hulgas mõistavad pooled vääramatu jõu all õigusakti (nt
riigieelarve seaduse muutmise seaduse või riigi lisaeelarve seaduse) jõustumist, mis takistab oluliselt
lepingu täitmist või muudab selle võimatuks.
5.2. Pool peab teist poolt vääramatu jõu asjaolude ilmnemisest ja lõppemisest kohe teavitama.
5.3. Kui vääramatu jõud kestab kauem kui 3 kuud, on mõlemal poolel õigus leping lõpetada.
6. Lepingu jõustumine, muutmine ja lõppemine
6.1. Leping jõustub, kui mõlema poole esindajad on lepingu digitaalselt allkirjastanud.
6.2. Lepingut võib muuta poolte kirjaliku või kirjalikku taasesitamist võimaldavas vormis kokkuleppega,
mis vormistatakse lepingu lisana.
6.3. Leping lõpeb:
6.3.1. infosüsteemi sulgemisega;
6.3.2. poolte kokkuleppel;
6.3.3. ühepoolselt, teatades sellest teisele poolele ette vähemalt 3 kuud;
6.3.4. muul seadusest tuleneval alusel.
6.4. Lepingu lõppemisel lõpevad lihtlitsentsid, lõpetatakse andmete kuvamine infosüsteemi avalikkusele
ligipääsetavas osas ning andmed märgitakse kustutatuks.
6.5. Lepingu lõppemisel antakse muuseumile üle muuseumi museaalide metaandmed CSV formaadis
lepingu lõppemise päeva seisuga. Üleantavad andmed ei kajasta muuseumi poolt kasutamisperioodi
jooksul tehtud muudatusi ja parandusi juhul, kui need ei kajastu lepingu lõppemise päeval
aktuaalsetes museaalide metaandmete kirjeldustes. Muul viisil ja formaadis andmete üleandmise osas
võivad pooled eraldi kokku leppida. Muul viisil ja formaadis andmete üleandmisel tekkivad kulud
kannab muuseum juhul, kui pooled ei ole kokku leppinud teisiti.
Allkirjastatud digitaalselt
7. Lõppsätted
7.1. Lepinguga seotud teabe vahetamiseks määratud kontaktisikud:
7.1.1 Kultuuriministeeriumi kontaktisik on Kadri Nigulas,
[email protected], 6282352.
7.1.2 Muuseumi kontaktisik on Külli Muromägi,
[email protected], 5182610.
7.2 Lepinguga reguleerimata küsimustes lähtuvad pooled Eesti Vabariigi õigusaktidest.
7.3 Lepingust tulenevad vaidlused lahendatakse läbirääkimiste teel. Kokkuleppe mittesaavutamisel
lahendatakse vaidlused kohtus.
Kultuuriministeerium Järvakandi Klaasimuuseum
Registrikood: 70000941 Registrikood: 75022663
E-posti aadress:
[email protected] E-posti aadress:
[email protected]
(allkirjastatud digitaalselt) (allkirjastatud digitaalselt)
Indrek Saar Allan Kima
minister juhataja
Allkirjastatud digitaalselt
Lisa 1
Muuseumide infosüsteemi (edaspidi infosüsteem) turvanõuded
1. Infosüsteemi kasutajaõiguste andmisel lähtutakse kultuuriministri 08.07.2013 määruse nr 32
„Muuseumide andmekogu asutamine ja põhimäärus“ §-st 6.
2. Kasutusõiguse realiseerimiseks loob muuseumi juhi poolt määratud MuISi vastutav isik (edaspidi
peakasutaja) uuele kasutajale MuISi kasutajakonto. Kasutajaõiguste andmise, muutmise või
äravõtmise vajadusest informeerib peakasutajat isik, kelle otseses alluvuses tööl või kelle juures
praktikal või teaduslikul uurimistööl kasutaja on.
3. Kasutajaõigused on isiklikud ja ei ole üleantavad. Kasutaja vastutab kõigi toimingute eest, mis on
teostatud tema kasutajatunnust kasutades.
4. Kasutaja identifitseeritakse kasutajatunnuse ja ID-kaardi, mobiil-ID või parooli abil. Turvalisuse
huvides peab kasutaja eelistama ID-kaarti või mobiil-ID-d.
5. Parooli tuleb vahetada vähemalt üks kord aastas, seda ka siis, kui infosüsteem seda kasutajalt
automaatselt ei nõua.
6. Parooli tuleb vahetada viivitamatult, kui on tekkinud kahtlus selle avalikuks tulemisest.
7. Parool ei tohi olla salvestatud veebilehitsejasse.
8. Parool peab olema vähemalt kaheksa tähemärki pikk, sisaldama väikseid ja suuri tähti ning numbreid.
9. Paroolis on keelatud kasutada täpitähti.
10. Keelatud on kasutada vanu paroole uuesti.
11. Parool ei tohi olla seostatav millegagi, mis võiks kolmandale isikule kasutaja kohta teada olla,
näiteks:
11.1. kasutajatunnus või kasutajatunnus tagurpidi kirjutatuna;
11.2. kasutaja või tema lähedase ees- või perekonnanimi või kasutaja või tema lähedase ees- või
perekonnanimi tagurpidi kirjutatuna;
11.3. kasutaja või tema lähedase sünnidaatum.
12. Infosüsteemi kasutamisel on eelistatud muuseumile kuuluv paikne riistvara.
13. Infosüsteemi kasutamisel mobiilseadmega (sülearvutid ja nutiseadmed) peab selle valdaja vältima
selle väärkasutust (näiteks seadme mittekasutamisel lukustama ekraani) ning kindlustama, et
mobiilseadmel oleks toimiv ning ajakohane pahavaratõrje tarkvara.
14. Infosüsteemi kasutamisel on keelatud:
14.1. kasutajatunnuse ning parooli üleandmine kolmandale isikule;
14.2. infosüsteemi kasutusjuhendis märkimata vormingus faili üles laadimine;
14.3. pahavara sisaldava faili üles laadimine.
Allkirjastatud digitaalselt
MUUSEUMIDE INFOSÜSTEEMI KASUTAMISE LEPINGU NR 1.1-8/135 (23.10.2014)
LISA 3
Kultuuriministeerium ja Liivi Muuseum (edaspidi muuseum), edaspidi eraldi pool või koos
pooled, leppisid nende vahel 23.10.2014. a sõlmitud muuseumide infosüsteemi kasutamise
lepingu nr 1.1-8/135 (edaspidi leping) muutmises käesoleva lisaga (edaspidi lisa) kokku
alljärgnevalt.
1. Lepingu punkti 3.1.3. muudetakse ja museaalide esmase dokumenteerimise ja kirjeldamise
esimese etapi tähtaeg „31.12.2017” asendatakse kuupäevaga „31.12.2019”.
2. Lepingu punkti 3.1.4. muudetakse ja museaalide digikujutiste infosüsteemi lisamise tähtaeg
„31.12.2018” asendatakse kuupäevaga „31.12.2019”.
3. Lisa jõustub, kui pooled on selle allkirjastanud.
Kultuuriministeerium Liivi Muuseum
Registrikood: 70000941 Registrikood: 75006262
E-posti aadress:
[email protected] E-posti aadress:
[email protected]
(allkirjastatud digitaalselt) (allkirjastatud digitaalselt)
Indrek Saar Mari Niitra
minister juhataja
Allkirjastatud digitaalselt
MUUSEUMIDE INFOSÜSTEEMI KASUTAMISE LEPINGU nr 1.1-8/119 (24.09.2014)
LISA 3
Kultuuriministeerium ja Muhu Muuseum (edaspidi muuseum), edaspidi eraldi pool või koos
pooled, leppisid nende vahel 24.09.2014 sõlmitud muuseumide infosüsteemi kasutamise lepingu
nr 1.1-8/119 (edaspidi leping) muutmises kokku alljärgnevalt.
1. Lepingu punkt 3.1.3 muudetakse ja museaalide esmase dokumenteerimise ja kirjeldamise
esimese etapi kirjeldamise tähtpäev „31.12.2018” asendatakse tähtpäevaga „31.12.2025”.
2. Lepingu punkt 3.1.4 muudetakse ja museaalide digitaalsete kujutiste infosüsteemi lisamise
tähtpäev „31.12.2018” asendatakse tähtpäevaga „31.12.2025”.
3. Lisa jõustub, kui pooled on selle allkirjastanud.
Kultuuriministeerium Muhu Muuseum
Registrikood: 70000941 Registrikood: 75021468
E-posti aadress:
[email protected] E-posti aadress:
[email protected]
(allkirjastatud digitaalselt) (allkirjastatud digitaalselt)
Indrek Saar Meelis Mereäär
minister juhataja
Allkirjastatud digitaalselt
MUUSEUMIDE INFOSÜSTEEMI KASUTAMISE LEPINGU nr 1.1-8/120 (24.09.2014)
LISA 2
Kultuuriministeerium ja Sihtasutus Narva Muuseum (edaspidi muuseum), edaspidi eraldi
pool või koos pooled, leppisid nende vahel 24.09.2014 sõlmitud muuseumide infosüsteemi
kasutamise lepingu nr 1.1-8/120 (edaspidi leping) muutmises kokku alljärgnevalt.
1. Lepingu punkt 3.1.3 muudetakse ja museaalide esmase dokumenteerimise ja kirjeldamise
esimese etapi tähtpäev „31.12.2018” asendatakse tähtpäevaga „31.12.2023”.
2. Lepingu punkti 3.1.4 muudetakse ja museaalide digitaalse kujutise infosüsteemi lisamise
tähtpäev „31.12.2018” asendatakse tähtpäevaga „31.12.2023”.
3. Lepingu punktis 7.2 muudetakse Kultuuriministeeriumi poolne kontaktisik lepinguga seotud
küsimustes, kelleks on Kadri Nigulas, kultuuriväärtuste osakonna peaspetsialist, tel 6282352,
e-post:
[email protected].
4. Lisa jõustub, kui pooled on selle allkirjastanud.
Kultuuriministeerium Sihtasutus Narva Muuseum
Registrikood: 70000941 Registrikood: 90011481
E-posti aadress:
[email protected] E-posti aadress:
[email protected]
(allkirjastatud digitaalselt) (allkirjastatud digitaalselt)
Indrek Saar Ivo Posti
minister juhatuse liige
Allkirjastatud digitaalselt
MUUSEUMIDE INFOSÜSTEEMI KASUTAMISE LEPINGU nr 6-9/26 (07.03.2016)
LISA 2
Kultuuriministeerium ja Põltsamaa Muuseum (edaspidi muuseum), edaspidi eraldi pool või
koos pooled, leppisid nende vahel 07.03.2016 sõlmitud muuseumide infosüsteemi kasutamise
lepingu nr 6-9/26 (edaspidi leping) muutmises kokku alljärgnevalt.
1. Lepingu punkt 3.1.3 muudetakse ja museaalide esmase dokumenteerimise ja kirjeldamise
esimese etapi tähtpäev „31.12.2018” asendatakse tähtpäevaga „31.12.2020”.
2. Lepingu punkt 3.1.4 muudetakse ja museaalide digitaalsete kujutiste infosüsteemi lisamise
tähtpäev „31.12.2018” asendatakse tähtpäevaga „31.12.2020”.
3. Lisa jõustub, kui pooled on selle allkirjastanud.
Kultuuriministeerium Põltsamaa Muuseum
Registrikood: 70000941 Registrikood: 75003105
E-posti aadress:
[email protected] E-posti aadress:
[email protected]
(allkirjastatud digitaalselt) (allkirjastatud digitaalselt)
Indrek Saar Rutt Tänav
minister juhataja
Allkirjastatud digitaalselt
MUUSEUMIDE INFOSÜSTEEMI KASUTAMISE LEPINGU nr 1.1-8/126
LISA 3
Kultuuriministeerium ja Setomaa Muuseumid (edaspidi muuseum), edaspidi eraldi pool või
koos pooled, leppisid nende vahel 26.09.2014 sõlmitud muuseumide infosüsteemi kasutamise
lepingu nr 1.1-8/126 (edaspidi leping) muutmises kokku alljärgnevalt.
1. Võttes arvesse, et Seto Talumuuseum (registrikood 75025221) ja Obinitsa Muuseum
(registrikood 75038049) liitusid. Ümberkorralduste tulemusena jätkab tegevust Setomaa
Muuseumid (vana nimega Seto Talumuuseum, registrikood 75025221). Obinitsa Muuseum
(registrikood 75038049) kustutatakse registrist. Liitmise aluseks on Setomaa Vallavolikogu
otsus 27.09.2018 otsus nr 42. Seoses liitumisega loetakse Obinitsa Muuseumiga sõlmitud
muuseumide infosüsteemi kasutamise leping nr 1.1-8/118 lõppenuks.
2. Lepingu punkt 3.1.3 muudetakse ja museaalide esmase dokumenteerimise ja kirjeldamise
esimese etapi tähtpäev „31.12.2018” asendatakse tähtpäevaga „31.12.2021”.
3. Lepingu punkt 3.1.4 muudetakse ja museaalide digitaalsete kujutiste infosüsteemi lisamise
tähtpäev „31.12.2018” asendatakse tähtpäevaga „31.12.2021”.
4. Lepingu punktis 7.1. muudetakse muuseumi poolne kontaktisik lepinguga seotud küsimustes,
kelleks on edaspidi Tiiu Kunst, peavarahoidja, tel 5656 6898, e-kiri:
[email protected].
5. Lisa jõustub, kui pooled on selle allkirjastanud.
Kultuuriministeerium Setomaa Muuseumid
Registrikood: 70000941 Registrikood: 75025221
E-posti aadress:
[email protected] E-posti aadress:
[email protected]
(allkirjastatud digitaalselt) (allkirjastatud digitaalselt)
Indrek Saar Merily Marienhagen
minister direktor
Allkirjastatud digitaalselt
MUUSEUMIDE INFOSÜSTEEMI KASUTAMISE LEPINGU nr 1.1-8/113
LISA 3
Kultuuriministeerium ja Tallinna Linnamuuseum (edaspidi koos pooled), leppisid nende
vahel 18.09.2014 sõlmitud muuseumide infosüsteemi kasutamise lepingu nr 1.1-8/113 (edaspidi
leping) muutmises kokku alljärgnevalt.
1. Lepingu punkt 3.1.3 muudetakse ja museaalide esmase dokumenteerimise ja kirjeldamise
esimese etapi tähtpäev „31.12.2018” asendatakse tähtpäevaga „31.12.2023”.
2. Lisa jõustub, kui pooled on selle allkirjastanud.
Kultuuriministeerium Tallinna Linnamuuseum
Registrikood: 70000941 Registrikood: 75016183
E-posti aadress:
[email protected] E-posti aadress:
[email protected]
(allkirjastatud digitaalselt) (allkirjastatud digitaalselt)
Indrek Saar Triin Siiner
minister direktor
Allkirjastatud digitaalselt
MUUSEUMIDE INFOSÜSTEEMI KASUTAMISE LEPINGU nr 1.1-8/114
LISA 3
Kultuuriministeerium ja Tallinna Ülikool (edaspidi koos pooled), leppisid nende vahel
22.09.2014 sõlmitud muuseumide infosüsteemi kasutamise lepingu nr 1.1-8/114 (edaspidi
leping) muutmises kokku alljärgnevalt.
1. Lepingu punkt 3.1.3 muudetakse ja museaalide esmase dokumenteerimise ja kirjeldamise
esimese etapi tähtpäev „31.12.2018” asendatakse tähtpäevaga „31.12.2020”.
2. Lepingu punkt 3.1.4 muudetakse ja museaalide digitaalsete kujutiste infosüsteemi lisamise
tähtpäev „31.12.2018” asendatakse tähtpäevaga „31.12.2020”.
3. Lisa jõustub, kui pooled on selle allkirjastanud.
Kultuuriministeerium Tallinna Ülikool
Registrikood: 70000941 Registrikood: 74000122
E-posti aadress:
[email protected] E-posti aadress:
[email protected]
(allkirjastatud digitaalselt) (allkirjastatud digitaalselt)
Indrek Saar Tiit Land
minister rektor
Allkirjastatud digitaalselt
MUUSEUMIDE INFOSÜSTEEMI KASUTAMISE LEPINGU nr 1.1-8/123
LISA 3
Kultuuriministeerium ja Tallinna Tehnikaülikool (edaspidi koos pooled), leppisid nende
vahel 24.09.2014 sõlmitud muuseumide infosüsteemi kasutamise lepingu nr 1.1-8/123 (edaspidi
leping) muutmises kokku alljärgnevalt.
1. Lepingu punkt 3.1.4 muudetakse ja museaalide digitaalsete kujutiste infosüsteemi lisamise
tähtpäev „31.12.2018” asendatakse tähtpäevaga „31.12.2020”.
2. Lisa jõustub, kui pooled on selle allkirjastanud.
Kultuuriministeerium Tallinna Tehnikaülikool
Registrikood: 70000941 Registrikood: 74000323
E-posti aadress:
[email protected] E-posti aadress:
[email protected]
(allkirjastatud digitaalselt) (allkirjastatud digitaalselt)
Indrek Saar Jüri Järs
minister raamatukogu direktor
Allkirjastatud digitaalselt
MUUSEUMIDE INFOSÜSTEEMI KASUTAMISE
L E P I N G nr 6-9.1/134-1
Kultuuriministeerium ja Tartu Ülikool (edaspidi muuseum), edaspidi eraldi pool või koos pooled, on
sõlminud käesoleva muuseumide infosüsteemi kasutamise lepingu (edaspidi leping) alljärgnevas.
1. Üldsätted
1.1. Lepingu eesmärk on kokku leppida muuseumiseaduse § 15 alusel asutatud muuseumide andmekogu
ametliku nimega „Muuseumide infosüsteem” (edaspidi infosüsteem) kasutamise tingimused.
1.2. Infosüsteem on andmebaas, mille tegijaks autoriõiguse seaduse (edaspidi AutÕS) § 75 3 mõistes on
Kultuuriministeerium.
1.3. Lepingu täitmisel juhindutakse muuseumiseadusest ja selle rakendusaktidest ning infosüsteemi
kasutusjuhenditest. Muuseum on teadlik, et pärast käesoleva lepingu sõlmimist kohaldatakse tema
tegevusele muuseumiseaduse paragrahve 5, 6, 7, 11, 14, 15, 16, 22 ja 23.
2. Poolte õigused
2.1. Muuseumil on õigus:
2.1.1. kasutada infosüsteemi museaalide, hoiule võetud asjade ja abikogusse arvatud asjade
metaandmete ja digitaalsete kujutiste (edaspidi andmete) elektrooniliseks haldamiseks ja
säilitamiseks;
2.1.2. sisestada, muuta ja kustutada tema poolt sisestatud andmeid, järgides kultuuriministri
08.07.2013. a määruses nr 30 „Muuseumikogu täiendamise ja kultuuriväärtusega asja
muuseumisse hoiule võtmise kord“, 08.07.2013. a määruses nr 31 „Museaali ja muuseumisse
kauemaks kui aastaks hoiule võetud asja märgistamise ja säilitamise kord“ ning 08.07.2013. a
määruses nr 32 „Muuseumide andmekogu asutamine ja põhimäärus“ sätestatud nõudeid. Kui
museaal on autoriõigusega kaitstav teos, siis teeb muuseum sellest digitaalse kujutise AutÕS §
20 lg 1 p 4 alusel ning see tehakse üldsusele kättesaadavaks infosüsteemis AutÕS § 20 lg 3
tingimustel;
2.1.3. kasutada infosüsteemis sisalduvaid tema poolt sisestatud andmeid ning muuseumile mõeldud
loogilist infosüsteemi osa, millele puudub juurdepääs teistel kasutajatel;
2.1.4. teha lihtlitsentsi alusel tasuta väljavõtteid infosüsteemis olevatest andmetest Väljavõtte
tegemiseks loetakse infosüsteemis olevate andmete mis tahes viisil või mis tahes vormis ajutist
või alalist ülekandmist teise väljendusvormi;
2.1.5. koostada ning käivitada päringuid museaalide, hoiule võetud asjade ja abikogusse arvatud
asjade ning nendega seotud tegevuste ja dokumentide kohta;
2.1.6. saada Kultuuriministeeriumilt nõustamist muuseumikogu korraldamisel ning muuseumi
ülesannete täitmisel.
2.2. Kultuuriministeeriumil on õigus:
2.2.1. teha üldsusele kättesaadavaks avalikkusele suunatud andmeid. Muuseum annab selleks
lihtlitsentsi kogu autoriõiguse tähtaja ulatuses ning litsents kehtib Eestis ja kõigis välisriikides.
Kultuuriministeeriumil on õigus anda vastavaid all-litsentse. Andmed tehakse üldsusele
kättesaadavaks järgneva litsentsi alusel: The Creative Commons Universal Public Domain
Dedication (CC0 1.0). Kui digitaalne kujutis on autoriõigusega kaitstav teos või digitaalsel
kujutisel on kujutatud autoriõigusega kaitstavad teosed, siis neile CC0 litsents ei kohaldu;
2.2.2. muuseumi antud lihtlitsentsi alusel kasutada andmeid infosüsteemis ja Europeana
andmebaasides ning otsingusüsteemides;
2.2.3. anda avalikkusele suunatud juurdepääsupiiranguta andmeid üldsusele kasutada ilma tasu ja
piiranguteta, sh ärikasutuse jaoks;
2.2.4. kasutada avalikkusele suunatud juurdepääsupiiranguta andmeid infosüsteemi tutvustamiseks;
2.2.5. sulgeda avalik juurdepääs andmetele juhul, kui see on vajalik andmete korrastamiseks,
isikuandmete või autoriõiguste kaitse tagamiseks. Kultuuriministeerium teavitab viivitamatult
selliste muudatuste tegemisest muuseumit.
Allkirjastatud digitaalselt
3. Poolte kohustused
3.1. Muuseum kohustub:
3.1.1. järgima infosüsteemi kasutusjuhendit ja turvanõudeid (lepingu lisa 1), tutvustama infosüsteemi
turvanõudeid kõigile infosüsteemi kasutavatele töötajatele enne esmast sisselogimist ning
tegema turvanõuded neile kättesaadavaks;
3.1.2. andmete sisestamisel järgima isikuandmete kaitse seadusest tulenevaid nõudeid. Kui
avalikustatakse museaali digitaalne kujutis, millel on kujutatud isik, siis eeldatakse, et isik on
eelnevalt andnud nõusoleku kujutise kasutamiseks. Kui isik nõuab oma isikukujutise ja või
teiste isikuandmete eemaldamist infosüsteemist, siis peab muuseum vastavad andmed
eemaldama infosüsteemi osast, mis on ligipääsetav avalikkusele;
3.1.3. läbi viima enne käesoleva lepingu sõlmimist arvele võetud museaalide esmase
dokumenteerimise ja kirjeldamise esimese etapi infosüsteemis kultuuriministri 08.07.2013. a
määruse nr 32 „Muuseumide andmekogu asutamine ja põhimäärus“ 2. peatükis esitatud nõuete
kohaselt hiljemalt 31.12.2022;
3.1.4. lisama enne käesoleva lepingu sõlmimist arvele võetud museaali digitaalse kujutise
infosüsteemi hiljemalt 31.12.2024.
4. Vastutus
4.1. Kultuuriministeerium ei vastuta infosüsteemis esitatud andmete õigsuse eest.
4.2. Kultuuriministeerium ei hüvita muuseumile kahju, mis on tekkinud infosüsteemis tehniliste tõrgete
tõttu.
4.3 Kultuuriministeerium säilitab andmed infosüsteemis vastavalt tehnika arengu tasemele ning
võimalusel arendab infosüsteemi.
5. Vääramatu jõud
5.1. Lepingu rikkumine on vabandatav, kui kohustuse rikkumise põhjuseks on vääramatu jõud
võlaõigusseaduse § 103 tähenduses. Muu hulgas mõistavad pooled vääramatu jõu all õigusakti (nt
riigieelarve seaduse muutmise seaduse või riigi lisaeelarve seaduse) jõustumist, mis takistab oluliselt
lepingu täitmist või muudab selle võimatuks.
5.2. Pool peab teist poolt vääramatu jõu asjaolude ilmnemisest ja lõppemisest kohe teavitama.
5.3. Kui vääramatu jõud kestab kauem kui 3 kuud, on mõlemal poolel õigus leping lõpetada.
6. Lepingu jõustumine, muutmine ja lõppemine
6.1. Leping jõustub, kui mõlema poole esindajad on lepingu allkirjastanud.
6.2. Lepingut võib muuta poolte kirjaliku või kirjalikku taasesitamist võimaldavas vormis kokkuleppega,
mis vormistatakse lepingu lisana.
6.3. Leping lõpeb:
6.3.1. infosüsteemi sulgemisega;
6.3.2. poolte kokkuleppel;
6.3.3. ühepoolselt, teatades sellest teisele poolele ette vähemalt 3 kuud;
6.3.4. muul seadusest tuleneval alusel.
6.4. Lepingu lõppemisel lõpevad lihtlitsentsid, lõpetatakse andmete kuvamine infosüsteemi avalikkusele
ligipääsetavas osas ning andmed märgitakse kustutatuks.
6.5. Lepingu lõppemisel antakse muuseumile üle muuseumi museaalide metaandmed CSV formaadis
lepingu lõppemise päeva seisuga. Üleantavad andmed ei kajasta muuseumi poolt kasutamisperioodi
jooksul tehtud muudatusi ja parandusi juhul, kui need ei kajastu lepingu lõppemise päeval
aktuaalsetes museaalide metaandmete kirjeldustes. Muul viisil ja formaadis andmete üleandmise osas
võivad pooled eraldi kokku leppida. Muul viisil ja formaadis andmete üleandmisel tekkivad kulud
kannab muuseum juhul, kui pooled ei ole kokku leppinud teisiti.
Allkirjastatud digitaalselt
7. Lõppsätted
7.1. Lepinguga seotud teabe vahetamiseks määratud kontaktisikud:
7.1.1 Kultuuriministeeriumi kontaktisik on Kadri Nigulas,
[email protected], 6282352.
7.1.2 Muuseumi kontaktisik on Tiina Vint,
[email protected], 737 5676.
7.2. Lepinguga reguleerimata küsimustes lähtuvad pooled Eesti Vabariigi õigusaktidest.
7.3. Lepingust tulenevad vaidlused lahendatakse läbirääkimiste teel. Kokkuleppe mittesaavutamisel
lahendatakse vaidlused kohtus.
Kultuuriministeerium Tartu Ülikool
Registrikood: 70000941 Registrikood: 74001073
E-posti aadress:
[email protected] E-posti aadress:
[email protected]
(allkirjastatud digitaalselt) (allkirjastatud digitaalselt)
Indrek Saar Erik Puura
minister arendusprorektor
Allkirjastatud digitaalselt
Lisa 1
Muuseumide infosüsteemi (edaspidi infosüsteem) turvanõuded
1. 1.Infosüsteemi kasutajaõiguste andmisel lähtutakse kultuuriministri 08.07.2013 määruse nr 32
„Muuseumide andmekogu asutamine ja põhimäärus“ §-st 6.
2. Kasutusõiguse realiseerimiseks loob muuseumi juhi poolt määratud MuISi vastutav isik (edaspidi
peakasutaja) uuele kasutajale MuISi kasutajakonto. Kasutajaõiguste andmise, muutmise või
äravõtmise vajadusest informeerib peakasutajat isik, kelle otseses alluvuses tööl või kelle juures
praktikal või teaduslikul uurimistööl kasutaja on.
3. Kasutajaõigused on isiklikud ja ei ole üleantavad. Kasutaja vastutab kõigi toimingute eest, mis on
teostatud tema kasutajatunnust kasutades.
4. Kasutaja identifitseeritakse kasutajatunnuse ja ID-kaardi, mobiil-ID või parooli abil. Turvalisuse
huvides peab kasutaja eelistama ID-kaarti või mobiil-ID-d.
5. Parooli tuleb vahetada vähemalt üks kord aastas, seda ka siis, kui infosüsteem seda kasutajalt
automaatselt ei nõua.
6. Parooli tuleb vahetada viivitamatult, kui on tekkinud kahtlus selle avalikuks tulemisest.
7. Parool ei tohi olla salvestatud veebilehitsejasse.
8. Parool peab olema vähemalt kaheksa tähemärki pikk, sisaldama väikseid ja suuri tähti ning
numbreid.
9. Paroolis on keelatud kasutada täpitähti.
10. Keelatud on kasutada vanu paroole uuesti.
11. Parool ei tohi olla seostatav millegagi, mis võiks kolmandale isikule kasutaja kohta teada olla,
näiteks:
11.1.kasutajatunnus või kasutajatunnus tagurpidi kirjutatuna;
11.2.kasutaja või tema lähedase ees- või perekonnanimi või kasutaja või tema lähedase ees- või
perekonnanimi tagurpidi kirjutatuna;
11.3.kasutaja või tema lähedaste sünnidaatum.
12. Infosüsteemi kasutamisel on eelistatud muuseumile kuuluv paikne riistvara.
13. Infosüsteemi kasutamisel mobiilseadmega (sülearvutid ja nutiseadmed) peab selle valdaja vältima
selle väärkasutust (näiteks seadme mittekasutamisel lukustama ekraani) ning kindlustama, et
mobiilseadmel oleks toimiv ning ajakohane pahavaratõrje tarkvara.
14. Infosüsteemi kasutamisel on keelatud:
14.1.kasutajatunnuse ning parooli üleandmine kolmandale isikule;
14.2.infosüsteemi kasutusjuhendis märkimata vormingus faili üles laadimine;
14.3.pahavara sisaldavate failide üles laadimine.
Allkirjastatud digitaalselt
MUUSEUMIDE INFOSÜSTEEMI KASUTAMISE
L E P I N G nr 6-9.1/120-1
Kultuuriministeerium ja Tarvastu Muuseum (edaspidi muuseum), edaspidi eraldi pool või koos
pooled, on sõlminud käesoleva muuseumide infosüsteemi kasutamise lepingu (edaspidi leping)
alljärgnevas.
1. Üldsätted
1.1. Lepingu eesmärk on kokku leppida muuseumiseaduse § 15 alusel asutatud muuseumide andmekogu,
ametliku nimega „Muuseumide infosüsteem” (edaspidi infosüsteem), kasutamise tingimused.
1.2. Infosüsteem on andmebaas, mille tegijaks autoriõiguse seaduse (edaspidi AutÕS) § 75 3 mõistes on
Kultuuriministeerium.
1.3. Lepingu täitmisel juhindutakse muuseumiseadusest ja selle rakendusaktidest ning infosüsteemi
kasutusjuhenditest. Muuseum on teadlik, et pärast käesoleva lepingu sõlmimist kohaldatakse tema
tegevusele muuseumiseaduse paragrahve 5, 6, 7, 11, 14, 15, 16, 22 ja 23.
2. Poolte õigused
2.1. Muuseumil on õigus:
2.1.1. kasutada infosüsteemi museaalide, hoiule võetud asjade ja abikogusse arvatud asjade
metaandmete ja digitaalsete kujutiste (edaspidi andmete) elektrooniliseks haldamiseks ja
säilitamiseks;
2.1.2. sisestada, muuta ja kustutada tema poolt sisestatud andmeid, järgides kultuuriministri
08.07.2013. a määruses nr 30 „Muuseumikogu täiendamise ja kultuuriväärtusega asja
muuseumisse hoiule võtmise kord“, 08.07.2013. a määruses nr 31 „Museaali ja muuseumisse
kauemaks kui aastaks hoiule võetud asja märgistamise ja säilitamise kord“ ning 08.07.2013. a
määruses nr 32 „Muuseumide andmekogu asutamine ja põhimäärus“ sätestatud nõudeid. Kui
museaal on autoriõigusega kaitstav teos, siis teeb muuseum sellest digitaalse kujutise AutÕS §
20 lg 1 p 4 alusel ning see tehakse üldsusele kättesaadavaks infosüsteemis AutÕS § 20 lg 3
tingimustel;
2.1.3. kasutada infosüsteemis sisalduvaid tema poolt sisestatud andmeid ning muuseumile mõeldud
loogilist infosüsteemi osa, millele puudub juurdepääs teistel kasutajatel;
2.1.4. lihtlitsentsi alusel teha tasuta väljavõtteid infosüsteemis olevatest andmetest. Väljavõtte
tegemiseks loetakse infosüsteemis olevate andmete mis tahes viisil või mis tahes vormis ajutist
või alalist ülekandmist teise väljendusvormi;
2.1.5. koostada ning käivitada päringuid museaalide, hoiule võetud asjade ja abikogusse arvatud
asjade ning nendega seotud tegevuste ja dokumentide kohta;
2.1.6. saada Kultuuriministeeriumilt nõustamist muuseumikogu korraldamisel ning muuseumi
ülesannete täitmisel.
2.2. Kultuuriministeeriumil on õigus:
2.2.1. teha üldsusele kättesaadavaks avalikkusele suunatud andmeid. Muuseum annab selleks
lihtlitsentsi kogu autoriõiguse tähtaja ulatuses ning litsents kehtib Eestis ja kõigis välisriikides.
Kultuuriministeeriumil on õigus anda vastavaid all-litsentse. Andmed tehakse üldsusele
kättesaadavaks järgneva litsentsi alusel: The Creative Commons Universal Public Domain
Dedication (CC0 1.0). Kui digitaalne kujutis on autoriõigusega kaitstav teos või digitaalsel
kujutisel on kujutatud autoriõigusega kaitstav teos, siis neile CC0 litsents ei kohaldu;
2.2.2. muuseumi antud lihtlitsentsi alusel kasutada andmeid infosüsteemis ja Europeana
andmebaasides ning otsingusüsteemides;
2.2.3. anda avalikkusele suunatud juurdepääsupiiranguta andmeid üldsusele kasutada ilma tasu ja
piiranguteta, sh ärikasutuse jaoks;
2.2.4. kasutada avalikkusele suunatud juurdepääsupiiranguta andmeid infosüsteemi tutvustamiseks;
2.2.5. sulgeda avalik juurdepääs andmetele juhul, kui see on vajalik andmete korrastamiseks,
isikuandmete või autoriõiguste kaitse tagamiseks. Kultuuriministeerium teavitab viivitamatult
selliste muudatuste tegemisest muuseumit.
Allkirjastatud digitaalselt
3. Poolte kohustused
3.1. Muuseum kohustub:
3.1.1. järgima infosüsteemi kasutusjuhendit ja turvanõudeid (lepingu lisa 1), tutvustama infosüsteemi
turvanõudeid kõigile infosüsteemi kasutavatele töötajatele enne esmast sisselogimist ning
tegema turvanõuded neile kättesaadavaks;
3.1.2. andmete sisestamisel järgima isikuandmete kaitse seadusest tulenevaid nõudeid. Kui
avalikustatakse museaali digitaalne kujutis, millel on kujutatud isik, siis eeldatakse, et isik on
eelnevalt andnud nõusoleku kujutise kasutamiseks. Kui isik nõuab oma isikukujutise ja või
teiste isikuandmete eemaldamist infosüsteemist, siis peab muuseum vastavad andmed
eemaldama infosüsteemi osast, mis on ligipääsetav avalikkusele;
3.1.3. läbi viima enne käesoleva lepingu sõlmimist arvele võetud museaalide esmase
dokumenteerimise ja kirjeldamise esimese etapi infosüsteemis kultuuriministri 08.07.2013. a
määruse nr 32 „Muuseumide andmekogu asutamine ja põhimäärus“ 2. peatükis esitatud nõuete
kohaselt kõige hiljem 31.12.2018;
3.1.4. lisama enne käesoleva lepingu sõlmimist arvele võetud museaali digitaalse kujutise
infosüsteemi kõige hiljem 31.12.2020.
4. Vastutus
4.1. Kultuuriministeerium ei vastuta infosüsteemis esitatud andmete õigsuse eest.
4.2. Kultuuriministeerium ei hüvita muuseumile kahju, mis on tekkinud infosüsteemis tehniliste tõrgete
tõttu.
4.3. Kultuuriministeerium säilitab andmed infosüsteemis vastavalt tehnika arengu tasemele ning
võimalusel arendab infosüsteemi.
5. Vääramatu jõud
5.1. Lepingu rikkumine on vabandatav, kui kohustuse rikkumise põhjuseks on vääramatu jõud
võlaõigusseaduse § 103 tähenduses. Muu hulgas mõistavad pooled vääramatu jõu all õigusakti (nt
riigieelarve seaduse muutmise seaduse või riigi lisaeelarve seaduse) jõustumist, mis takistab oluliselt
lepingu täitmist või muudab selle võimatuks.
5.2. Pool peab teist poolt vääramatu jõu asjaolude ilmnemisest ja lõppemisest kohe teavitama.
5.3. Kui vääramatu jõud kestab kauem kui 3 kuud, on mõlemal poolel õigus leping lõpetada.
6. Lepingu jõustumine, muutmine ja lõppemine
6.1. Leping jõustub, kui mõlema poole esindajad on lepingu digitaalselt allkirjastanud.
6.2. Lepingut võib muuta poolte kirjaliku või kirjalikku taasesitamist võimaldavas vormis kokkuleppega,
mis vormistatakse lepingu lisana.
6.3. Leping lõpeb:
6.3.1. infosüsteemi sulgemisega;
6.3.2. poolte kokkuleppel;
6.3.3. ühepoolselt, teatades sellest teisele poolele ette vähemalt 3 kuud;
6.3.4. muul seadusest tuleneval alusel.
6.4. Lepingu lõppemisel lõpevad lihtlitsentsid, lõpetatakse andmete kuvamine infosüsteemi avalikkusele
ligipääsetavas osas ning andmed märgitakse kustutatuks.
6.5. Lepingu lõppemisel antakse muuseumile üle muuseumi museaalide metaandmed CSV formaadis
lepingu lõppemise päeva seisuga. Üleantavad andmed ei kajasta muuseumi poolt kasutamisperioodi
jooksul tehtud muudatusi ja parandusi juhul, kui need ei kajastu lepingu lõppemise päeval
aktuaalsetes museaalide metaandmete kirjeldustes. Muul viisil ja formaadis andmete üleandmise osas
võivad pooled eraldi kokku leppida. Muul viisil ja formaadis andmete üleandmisel tekkivad kulud
kannab muuseum juhul, kui pooled ei ole kokku leppinud teisiti.
Allkirjastatud digitaalselt
7. Lõppsätted
7.1. Lepinguga seotud teabe vahetamiseks määratud kontaktisikud:
7.1.1 Kultuuriministeeriumi kontaktisik on Kadri Nigulas,
[email protected], 6282352.
7.1.2 Muuseumi kontaktisik on Aili Anderson,
[email protected], 4366262.
7.2. Lepinguga reguleerimata küsimustes lähtuvad pooled Eesti Vabariigi õigusaktidest.
7.3. Lepingust tulenevad vaidlused lahendatakse läbirääkimiste teel. Kokkuleppe mittesaavutamisel
lahendatakse vaidlused kohtus.
Kultuuriministeerium Tarvastu Muuseum
Registrikood: 70000941 Registrikood: 75034028
E-posti aadress:
[email protected] E-posti aadress:
[email protected]
(allkirjastatud digitaalselt) (allkirjastatud digitaalselt)
Indrek Saar Aili Anderson
minister direktor
Allkirjastatud digitaalselt
Lisa 1
Muuseumide infosüsteemi (edaspidi infosüsteem) turvanõuded
1. Infosüsteemi kasutajaõiguste andmisel lähtutakse kultuuriministri 08.07.2013 määruse nr 32
„Muuseumide andmekogu asutamine ja põhimäärus“ §-st 6.
2. Kasutusõiguse realiseerimiseks loob muuseumi juhi poolt määratud MuISi vastutav isik (edaspidi
peakasutaja) uuele kasutajale MuISi kasutajakonto. Kasutajaõiguste andmise, muutmise või
äravõtmise vajadusest informeerib peakasutajat isik, kelle otseses alluvuses tööl või kelle juures
praktikal või teaduslikul uurimistööl kasutaja on.
3. Kasutajaõigused on isiklikud ja ei ole üleantavad. Kasutaja vastutab kõigi toimingute eest, mis on
teostatud tema kasutajatunnust kasutades.
4. Kasutaja identifitseeritakse kasutajatunnuse ja ID-kaardi, mobiil-ID või parooli abil. Turvalisuse
huvides peab kasutaja eelistama ID-kaarti või mobiil-ID-d.
5. Parooli tuleb vahetada vähemalt üks kord aastas, seda ka siis, kui infosüsteem seda kasutajalt
automaatselt ei nõua.
6. Parooli tuleb vahetada viivitamatult, kui on tekkinud kahtlus selle avalikuks tulemisest.
7. Parool ei tohi olla salvestatud veebilehitsejasse.
8. Parool peab olema vähemalt kaheksa tähemärki pikk, sisaldama väikseid ja suuri tähti ning numbreid.
9. Paroolis on keelatud kasutada täpitähti.
10. Keelatud on kasutada vanu paroole uuesti.
11. Parool ei tohi olla seostatav millegagi, mis võiks kolmandale isikule kasutaja kohta teada olla,
näiteks:
11.1. kasutajatunnus või kasutajatunnus tagurpidi kirjutatuna;
11.2. kasutaja või tema lähedase ees- või perekonnanimi või kasutaja või tema lähedase ees- või
perekonnanimi tagurpidi kirjutatuna;
11.3. kasutaja või tema lähedase sünnidaatum.
12. Infosüsteemi kasutamisel on eelistatud muuseumile kuuluv paikne riistvara.
13. Infosüsteemi kasutamisel mobiilseadmega (sülearvutid ja nutiseadmed) peab selle valdaja vältima
selle väärkasutust (näiteks seadme mittekasutamisel lukustama ekraani) ning kindlustama, et
mobiilseadmel oleks toimiv ning ajakohane pahavaratõrje tarkvara.
14. Infosüsteemi kasutamisel on keelatud:
14.1. kasutajatunnuse ning parooli üleandmine kolmandale isikule;
14.2. infosüsteemi kasutusjuhendis märkimata vormingus faili üles laadimine;
14.3. pahavara sisaldava faili üles laadimine.
Allkirjastatud digitaalselt
MUUSEUMIDE INFOSÜSTEEMI KASUTAMISE
L E P I N GU nr 6-9.1/120-1 (20.04.2018) LISA 3
Kultuuriministeerium ja Tarvastu Muuseum (edaspidi muuseum), edaspidi eraldi pool või koos
pooled, leppisid nende vahel 20.04.2018 sõlmitud muuseumide infosüsteemi kasutamise lepingu nr 6-
9.1/120-1 (edaspidi leping) muutmises kokku alljärgnevalt.
1. Lepingu punkt 3.1.3 muudetakse ja museaalide esmase dokumenteerimise ja kirjeldamise esimese
etapi tähtpäev „31.12.2018” asendatakse tähtpäevaga „31.12.2020”.
2. Lepingu punkt 3.1.4 muudetakse ja museaalide digitaalsete kujutiste infosüsteemi lisamise
tähtpäev „31.12.2020” asendatakse tähtpäevaga „31.12.2025”.
3. Lisa jõustub, kui pooled on selle allkirjastanud.
Kultuuriministeerium Tarvastu Muuseum
Registrikood: 70000941 Registrikood: 75034028
E-posti aadress:
[email protected] E-posti aadress:
[email protected]
(allkirjastatud digitaalselt) (allkirjastatud digitaalselt)
Indrek Saar Aili Anderson
minister Tarvastu raamatukogu direktor
Allkirjastatud digitaalselt
MUUSEUMIDE INFOSÜSTEEMI KASUTAMISE LEPINGU nr 1.1-8/148
LISA 3
Kultuuriministeerium ja Eesti Teaduste Akadeemia Underi ja Tuglase Kirjanduskeskus
(edaspidi koos pooled), leppisid nende vahel 03.12.2014 sõlmitud muuseumide infosüsteemi
kasutamise lepingu nr 1.1-8/148 (edaspidi leping) muutmises kokku alljärgnevalt.
1. Lepingu punkt 3.1.3 muudetakse ja museaalide esmase dokumenteerimise ja kirjeldamise
esimese etapi tähtpäev „31.12.2019” asendatakse tähtpäevaga „31.12.2021”.
2. Lepingu punkt 3.1.4 muudetakse ja museaalide digitaalsete kujutiste infosüsteemi lisamise
tähtpäev „31.12.2018” asendatakse tähtpäevaga „31.12.2021”.
3. Lisa jõustub, kui pooled on selle allkirjastanud.
Kultuuriministeerium Eesti Teaduste Akadeemia Underi ja Tuglase
Kirjanduskeskus
Registrikood: 70000941 Registrikood: 74000381
E-posti aadress:
[email protected] E-posti aadress:
[email protected]
(allkirjastatud digitaalselt) (allkirjastatud digitaalselt)
Indrek Saar Jaan Undusk
minister direktor
Allkirjastatud digitaalselt
MUUSEUMIDE INFOSÜSTEEMI KASUTAMISE LEPINGU nr 1.1-8/111 (15.09.2014)
LISA 1
Kultuuriministeerium ja MTÜ Vene Muuseum (edaspidi muuseum), edaspidi eraldi pool või
koos pooled, leppisid nende vahel 15.09.2014 sõlmitud muuseumide infosüsteemi kasutamise
lepingu nr 1.1-8/111 (edaspidi leping) muutmises kokku alljärgnevalt.
1. Lepingu punkti 3.1.3 muudetakse ja museaalide esmase dokumenteerimise ja kirjeldamise
esimese etapi kirjeldamise tähtpäev „31.12.2017” asendatakse tähtpäevaga „31.12.2021”.
2. Lepingu punkti 3.1.4 muudetakse ja museaalide digitaalse kujutise infosüsteemi lisamise
tähtpäev „31.12.2019” asendatakse tähtpäevaga „31.12.2021”.
3. Lisa jõustub, kui pooled on selle allkirjastanud.
Kultuuriministeerium MTÜ Vene Muuseum
Registrikood: 70000941 Registrikood: 80141140
E-posti aadress:
[email protected] E-posti aadress:
[email protected]
(allkirjastatud digitaalselt) (allkirjastatud digitaalselt)
Indrek Saar Irina Budrik
minister juhatuse liige
Koostöökokkuleppe 6/8-14
Lisa 7
Koostöökokkuleppe 6/8-14 muutmine
Kultuuriministeerium (registrikood 70000941), aadress Suur-Karja 23, 15076 Tallinn Harju maakond, keda
põhimääruse alusel esindab kantsler Tarvi Sits (edaspidi KuM või tellija)
ja
Registrite ja Infosüsteemide Keskus, (registrikoodiga 70000310), asukohaga Lubja 4, 10115 Tallinn, keda
põhimääruse alusel esindab direktor Mehis Sihvart (edaspidi RIK või täitja),
keda edaspidi nimetatakse ühiselt pooled, leppisid kokku muuta poolte vahel 12.01.2015 sõlmitud
koostöökokkulepet nr 6/8-14 järgmiselt:
1. Asendada koostöökokkuleppe punkt 8.1 sõnastus järgmise sõnastusega:
„8.1 Täitja kontaktisikuks, kelle on mh õigus esitada Tellijale Täitja seisukohti hinnamuudatuste
osas ja pidada läbirääkimisi teenustasu muudatustes on Registrite ja Infosüsteemide Keskuse
kohturegistrite osakonna juhataja või tema asendaja (e-post:
[email protected] tel: 663 6531).“
2. Lisada koostöökokkuleppesse punkt 10 alljärgnevas sõnastuses ja sellest tulenevalt muuta
järgnevate punktide numeratsiooni:
„10. Isikuandmed
10.1 Pooled tagavad oma tegevuses vastavuse kohalduvatele andmekaitse õigusaktidele.
Pooled täidavad kõiki lepingu täitmise kohas kehtivaid isikuandmete töötlemisalaseid
nõudeid, andmete turvalisust puudutavaid ning isikuandmete kaitse alaseid Euroopa Liidu
ja Eesti Vabariigi õigusakte ja muid eeskirju.
10.2 Käesolevas lepingu punktis toodud tingimused moodustavad andmetöötluslepingu,
millega sätestatakse tellija, kui vastutava töötleja ja täitja, kui volitatud töötleja vahel
kehtivad õigused ja kohustused teenuse raames täitjale töötlemiseks edastatavate
isikuandmete kaitseks.
10.3 Tellija on isikuandmete vastutav töötleja ja täitja töötleb teenuse osutamiseks vajalikus
ulatuses isikuandmeid tellija ülesandel. Tellija kinnitab ja vastutab vastutava töötlejana
selle eest, et teenuse raames isikuandmete töötlemine toimub kehtival õiguslikul alusel
õiguspäraste eesmärkide saavutamiseks, andmesubjektid on isikuandmete töötlemisest
teadlikud ja/või sellega nõus ning tellijal on õigus isikuandmeid täitjale teenuse osutamise
raames edastada.
10.4 Täitja kasutab teenuse osutamise käigus saadud isikuandmeid üksnes lepingus sätestatud
eesmärkide täitmiseks. Lepingu lõppemisel kohustub täitja kustutama kõik talle lepingu
täitmisel teatavaks saanud isikuandmed ja nimetatute koopiad, v.a juhul, kui õigusaktidest
tuleneb teisiti.
10.5 Täitja võimaldab juurdepääsu isikuandmetele üksnes 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 ka pärast käesoleva lepingu lõppemist.
10.6 Täitja rakendab vajalikke organisatsioonilisi, füüsilisi ja infotehnilisi turvameetmeid
isikuandmete kaitseks juhusliku või tahtliku volitamata muutmise, juhusliku hävimise,
tahtliku hävitamise, avalikustamise jms eest.
10.7 Täitjal ei ole õigust edastada isikuandmeid kolmandatele isikutele ega kasutada
isikuandmete töötlemiseks omakorda volitatud töötlejaid ilma tellija eelneva kirjaliku loata.
10.8 Võttes arvesse isikuandmete töötlemise laadi ja olemasolevat teavet, aitab täitja mõistlikus
ulatuses tellijal tagada õigusaktidest tulenevate isikuandmete turvalisusega seotud
vastutava töötleja kohustuste täitmist.
10.9 Täitja kohustub abistama võimaluste piires asjakohaste tehniliste ja korralduslike
meetmete abil tellijat täita tellija kohustust vastata taotlustele andmesubjekti õiguste
teostamiseks ning teostada nende õiguste teostamisest tulenevaid toiminguid (andmete
parandamine, kustutamine).
10.10 Täitja võimaldab tellijal või tellija poolt volitatud audiitoril teha auditeid ja kontrolle ning
kohustub panustama nendesse.
10.11 Teenuse osutamise raames töödeldavate isikuandmetega seotud rikkumise korral
teavitab täitja tellijat sellest põhjendamatu viivituseta pärast seda, kui ta on rikkumisest
teada saanud.“
3. Asendada koostöökokkuleppe lisa nr 4 „Teenuse maksumus“ käesolevale kokkuleppele lisatud
lisaga nr 4 “Teenuse maksumus”.
4. Käesolev kokkulepe on allkirjastatud digitaalselt ning jõustub pärast mõlema poole
allkirjastamist.
Tellija: Täitja:
/digitaalselt allkirjastatud/ /digitaalselt allkirjastatud/
Tarvi Sits Mehis Sihvart
Kantsler Direktor
Kultuuriministeerium Registrite ja Infosüsteemide Keskus
2
ASUTUSESISESEKS KASUTAMISEKS
07.01.2019. a
Juurdepääsupiirang kehtib kuni
07.01.2024. a
Alus: AvTS § 35 lg 1 p 17
Lepingu nr 6/8-14
Lisa 4
TEENUSE MAKSUMUS
2019. a osutatavate teenuste kogumaksumus lepingu lisa allkirjastamise hetkel on 219 938,00 eurot
lisaks lisandub 3 444,86 eurot testkeskkonna supordi kulu.
Teenuste maksumus alates 01. jaanuar 2019:
Teenus Aasta kokku
MuIS süsteemi halduskulu, sh test ja 21 600,00
koolituskeskkonnad
MuIS digihoidla 100TB 67 500,00
MuIS haldusteenus 130 838,00
Kokku 219 938,00
Ühekordne investeering
Teenus Hind
Testkeskkonna support kulu 3 444,86
Kokku 3 444,86
Täiendavad märkused teenuste kohta:
1. MuIS´i haldusteenuse osutamiseks tagab RIK ühes kuus 1,0 analüütiku, 1,5 halduri ja 0,5
administreerimise töökohta.
2. MuIS´i haldusteenus sisaldab ka tuge riigihangete läbiviimiseks, st prognoosivate tegevuste
raames kahe riigihanke läbiviimist aastas (kuni 148 töötundi kokku).
3. Vastavalt poolte kokkuleppele pakutakse haldusteenust arvestusega, et pöördumiste arv ühes
kuus ei ületa 100 juhtumit.
4. Arendustöid teostatakse tunnihinna alusel, mille maht lepitakse poolte vahel kokku ja
kogumaksumus arvestatakse kehtiva tunnihinna põhjal. 2019. aastal on arendustööde
tunnihinnaks 32 eurot tunnis.
5. KuM kohustub RIK´ile kompenseerima täiendavate teenuste ja või mahu suurenemisest
tekkinud kulud. Juhul, kui täiendavate teenuste ja või mahu suurenemise eest ei ole võimalik
näha eraldamist RIK´i eelarvesse, toimub arveldamine arvega.
6. Kõik maksumused on toodud eurodes ning arvega arveldamisel lisandub hinnale käibemaks.
7. Kord aastas vaadatakse üle kõikide teenuste sisu, mahud ja fikseeritud hinnad ning tehakse
vajadusel muutmisettepanek.
3
Lepingu nr 6/8-14
Lisa 5
KOOSTÖÖKOKKULEPPE nr 6/8-14 MUUTMISE KOKKULEPE
Kultuuriministeerium (registrikood 70000941), asukohaga Suur-Karja 23 15076 Tallinn Harju
maakond, keda põhimääruse alusel esindab kantsler Paavo Nõgene (edaspidi Tellija) ja
Registrite ja Infosüsteemide Keskus, (registrikoodiga 70000310), asukohaga Lõkke tn 4, 19081
Tallinn, keda põhimääruse alusel esindab direktor Mehis Sihvart (edaspidi Täitja),
keda nimetatakse edaspidi Pool või koos Pooled, leppisid kokku muuta Poolte vahel 22. detsembril
2014. a sõlmitud lepingut nr 6/8-14 järgmiselt:
1. Täiendada koostöökokkulepet punktidega 8.5 ja 8.6:
„8.5. Täitja esindajaks tööde vastuvõtmise aktide, teadete jms lepinguga seonduvate dokumentide
allkirjastamisel on Registrite ja Infosüsteemide Keskuse notariaadi infosüsteemi talituse juhataja Robin
Lõo (e-post:
[email protected]).
8.6. Tellija esindajaks tööde vastuvõtmise aktide, teadete jms lepinguga seonduvate dokumentide
allkirjastamisel on Indrek Reimand (e-post:
[email protected] ).“
2. Asendada koostöökokkuleppe Lisa 4 „Teenuse maksumus“ käesolevale kokkuleppele lisatud
lisaga 4 „Teenuse maksumus“.
3. Käesolev kokkulepe on allkirjastatud digitaalselt ning jõustub pärast mõlema Poole
allkirjastamist.
Tellija: Täitja:
/digitaalselt allkirjastatud/ /digitaalselt allkirjastatud/
Paavo Nõgene Mehis Sihvart
Kantsler Direktor
Kultuuriministeerium Registrite ja Infosüsteemide Keskus
REGISTRITE JA INFOSÜSTEEMIDE KESKUS
ASUTUSESISESEKS KASUTAMISEKS
11.01.2017. a
Juurdepääsupiirang kehtib kuni
11.01.2022. a
Alus:AvTS § 35 lg 1 p 17
Lepingu nr 6/8-14
Lisa 4
Teenuse maksumus
MuISi majutus- ja haldusteenuse maksumus alates 1. jaanuar 2017:
Maksumus
Maht Maht HIND Maksumus
Nimetus aastas
(kuus) (aastas) km'ta aastas km-ta
km'ga
MuIS süsteemi halduskulu, sh test ja
1,00 12,00 1 800,00 21 600,00 25 920,00
koolituskeskkonnad*
MuIS haldusteenus 2,60 31,20 13 230,92 109 167,20 131 000,64
MuIS digihoidla 100TB 1,00 12,00 5 625,00 67 500,00 81 000,00
KOKKU aastas: 198 267,20 237 920,64
Arenduste tellimise (arendustellimuse koostamise teenus) tunnihind 2017. aastal on 40 eurot (koos
käibemaksuga).
Pooled sõlmivad Lepingu arvestusega, et pöördumiste arv ühes kuus ei ületa 100 juhtumit (puudutab
haldusteenust).
Kord aastas vaadatakse fikseeritud hinnad üle ning vajadusel tehakse muutmisettepanek.
ASUTUSESISESEKS KASUTAMISEKS
04.12.2017. a
Juurdepääsupiirang kehtib kuni
04.12.2022.a.
Alus: AvTS § 35 lg 1 p 17
Koostöökokkuleppe 6/8-14
Lisa 6
Koostöökokkuleppe 6/8-14 muutmine
Kultuuriministeerium (registrikood 70000941), aadress Suur-Karja 23 15076 Tallinn Harju maakond, keda
põhimääruse alusel esindab kantsler Paavo Nõgene (edaspidi KuM või tellija)
ja
Registrite ja Infosüsteemide Keskus, (registrikoodiga 70000310), asukohaga Lõkke tn 4, 19081 Tallinn, keda
põhimääruse alusel esindab direktor Mehis Sihvart (edaspidi RIK või täitja),
keda edaspidi nimetatakse ühiselt pooled, leppisid kokku muuta poolte vahel 12.01.2015 sõlmitud
koostöökokkulepet nr 6/8-14 järgmiselt:
1. Asendada koostöökokkuleppe lisa nr 4 „Teenuse maksumus“ käesolevale kokkuleppele lisatud
lisaga 4 “Teenuse maksumus”.
2. Käesolev kokkulepe on allkirjastatud digitaalselt ning jõustub pärast mõlema poole allkirjastamist.
Tellija: Täitja:
/digitaalselt allkirjastatud/ /digitaalselt allkirjastatud/
Paavo Nõgene Mehis Sihvart
Kantsler Direktor
Kultuuriministeerium Registrite ja Infosüsteemide Keskus
ASUTUSESISESEKS KASUTAMISEKS
04.12.2017. a
Juurdepääsupiirang kehtib kuni
04.12.2022.a.
Alus: AvTS § 35 lg 1 p 17
Lepingu nr 6/8-14
Lisa 4
Teenuse maksumus
2018. a osutatavate teenuste kogumaksumus lepingu lisa allkirjastamise hetkel on 229 219,00 eurot, mis
ümardatakse 229 000,00 euroks. Teenuste maksumus alates 01. jaanuar 2018:
Teenused Ühiku hind kuus Aastas kokku
MuIS süsteemi halduskulu, sh test ja koolituskeskkonnad 1 800,00 21 600,00
MuIS digihoidla 100TB 5 625,00 67 500,00
MuIS haldusteenus 11 579,50 138 954,00
Kokku 19 004,50 228 054,00
Ühekordne investeering
Teenus Ühiku hind
Oracle litsentsid 1 165,00
Kokku 1 165,00
Täiendavad märkused teenuste kohta:
1. MuISi haldusteenuse osutamiseks tagab RIK ühes kuus 1,0 analüütiku, 1,5 halduri ja 0,5
administeerimise töökohta.
2. MuISi haldusteenus sisaldab ka tuge riigihangete läbiviimiseks, st prognoositavate tegevuste
raames kahe riigihanke läbiviimist aastas (kuni 148 töötundi kokku).
3. Vastavalt poolte kokkuleppele pakutakse haldusteenust arvestusega, et pöördumiste arv ühes
kuus ei ületa 100 juhtumit.
4. Oracle litsentside maksumus on hinnanguline ja täpsustub litsentside üleandmisel RIKile.
5. Arendustöid teostatakse tunnihinna alusel, mille maht lepitakse poolte vahel kokku ja
kogumaksumus arvestatakse kehtiva tunnihinna põhjal. 2018. aastal on arendustööde tunnhinnaks
36 eurot tunnis.
6. Kord aastas vaadatakse üle kõikide teenuste sisu, mahud ja fikseeritud hinnad ning tehakse
vajadusel muutmisettepanek.
7. KuM kohustub RIKile kompenseerima täiendavate teenuste ja või mahu suurenemisest tekkinud
kulud. Juhul, kui täiendavate teenuste ja või mahu suurenemise eest ei ole võimalik näha ette tasu
eraldamist RIKi eelarvesse, toimub arveldamine arvega.
8. Kõik maksumused on toodud eurodes ning arvega arveldamisel lisandub hinnale käibemaks.
ASUTUSESISESEKS KASUTAMISEKS
16.08.2016.a
Juurdepääsupiirang kehtib kuni
16.08.2021.a.
Alus:AvTS § 35 lg 1 p 9 ja 10
Koostöökokkuleppe 6/8-14
Lisa 3
Koostöökokkuleppe 6/8-14 muudatus
Kultuuriministeerium (registrikood 70000941), aadress Suur-Karja 23 15076 Tallinn Harju maakond,
keda põhimääruse alusel esindab kantsler Paavo Nõgene (edaspidi Tellija) ja
Registrite ja Infosüsteemide Keskus, (registrikoodiga 70000310), asukohaga Lõkke tn 4, 19081
Tallinn, keda põhimääruse alusel esindab direktor Mehis Sihvart (edaspidi Täitja) leppisid kokku:
1. muuta koostöökokkulepet nr 6/8-14 lisa nr 2 „Muis ekspluatatsiooninõuded“ ning kehtestada see
järgnevalt alates 1.augustist 2016.a.:
Lepingu nr 6/8-14
Lisa 2
Muuseumide infosüsteemi (MuIS) teenusteenustaseme lepe (SLA)
1. Muuseumide infosüsteemi (MuIS) teenus
Muuseumide infosüsteemi (MuIS) majutuse, majutuse administreerimise ja haldusteenuse osutamine.
ISKE turvaklass K1T1S1
2. Üldmääratlus
Jrk. nr Tingimus Väärtus
2.1 Kriitilisuse klass III
2.2 Andmete varukoopiaklass P
1
2.3 Varukoopiate paigutamine lühiajalisele säilitamisele 7P, 4N, 12K
2.4 Aasta viimase varukoopia säilitustähtaeg 3A
3. IT-Teenuse kättesaadavus
E-R L, P
3.1 Tööaeg II II
3.2 Süsteemi sisutoe tööaeg I -
2
3.3 Maksimaalne lubatud üheaegne kasutajate arv 200 kasutajat
4. Planeeritud katkestus
4.1 Planeeritud katkestusest etteteatamisaeg (vähemalt) 72h
4.2 Planeeritud katkestuste maksimaalne kogukestvus 48h
aastas
4.3 Ühe planeeritud katkestuse maksimaalne kestvus 4h
4.4 Maksimaalne planeeritud katkestuste arv kuus 1 tk
5. Planeerimata katkestus
5.1 Lubatud planeerimata katkestuste kogukestvus 96h
aastas
5.2 Maksimaalne ühekordse planeerimata katkestuse 8h
kestvus
6. Logide säilitamine
Tingimus Väärtus
6.1 Rakendusserveri logide säilitamine 3 kuud
6.2 Andmebaasi logide säilitamine 6 kuud
1
Igapäevane täielik varundus (säilitatakse 7 päeva), iganädalane täielik varundus (säilitatakse 4 nädalat), igakuine
täielik varundus (säilitatakse 12 kuud).
2
Portaalid ja rakendus
SLA mõisted
1. Kriitilisuse klass – lähtuvalt taasteaegadest jaotatakse IT-teenuse osad järgmistesse kriitilisuse
klassidesse:
I (tegevuskriitiline) - taasteaeg kuni 2 ööpäeva,
II (kriitiline) - taasteaeg kuni 7 ööpäeva,
III (oluline) - taasteaeg kuni 21 ööpäeva,
IV (vajalik ) - taasteaeg kuni 28 ööpäeva.
2. Logide säilitamine – määratletakse kui kaua säilitatakse IT-teenuse jaoks vajalikke (andmebaasi,
rakendusserveri) logisid. Logi on kronoloogiline sündmuste andmestik, mis talletatakse andmefailina
järgnevaks läbivaatuseks ja analüüsimiseks.
3. Lubatud planeerimata katkestuste kogukestvus – lubatud planeerimata katkestuse kogukestvus on
maksimaalne lubatud planeerimata katkestuste kestvus mingil ajaperioodil (nt kuus, aastas).
4. Maksimaalne lubatud üheaegne kasutajate arv – maksimaalne lubatud üheaegne kasutajate arv on
süsteemi kvaliteetseks toimimiseks suurim lubatud sessioonide arv või suurim lubatud üheaegne
kasutajate arv, kes IT-teenust kasutab.
5. Maksimaalne lubatud üheaegne toimingute arv – maksimaalne lubatud üheaegne kas toimingute arv
on süsteemi kvaliteetseks toimimiseks suurim lubatud üheaegne toimingute, sh logimine, otsimine,
pärimine arv erinevate kasutajate poolt. Maksimaalne lubatud üheaegne toimingute arv on
jõudlustestide tegemise aluseks.
6. Maksimaalne planeeritud katkestuste arv kuus – maksimaalne planeeritud katkestuste arv kuus on
mitu katkestust (korralist hooldustööd) maksimaalselt võib ühte kuusse IT-teenuses planeerida.
7. Maksimaalne viide – maksimaalne viide on maksimaalne lubatud reaktsiooniaeg.
8. Maksimaalne ühekordse planeerimata katkestuse kestvus – maksimaalne ühekordse planeerimata
katkestuse kestvus on maksimaalne lubatud ajavahemik, kus IT-teenus ei ole tööajal kättesaadav või
on oluliselt häiritud vähemalt ühe asutuse piires.
9. Normaalne viide – normaalne viide on tavapärane reaktsiooniaeg sekundites, mille jaoks on süsteem
optimeeritud.
10. Planeeritud katkestus – planeeritud katkestus on eelnevalt kokkulepitud ajavahemik, mille jooksul IT-
teenus ei ole kättesaadav. Planeeritud katkestused toimuvad ainult IT-teenuse tööajal.
11. Planeerimata katkestus – planeerimata katkestus on tööajal aset leidev mitteplaanipärane katkestus
IT-teenuse toimimises.
12. Reaktsiooniaeg – reaktsiooniaeg on aeg, mis kulub sisestushetkest või päringusignaalist kuni vastuse
saamiseni. Reaktsiooniaegade tabelis kirjeldatud funktsioonid on aluseks teenustaseme mõõtmisel ja
peavad olema IT-teenuse seisukohast olulised ja millede monitoorimisel saab kinnituse IT-teenuse
toimimisest.
13. Tööaeg – tööaeg on ajavahemik, millal IT-teenus peab olema kasutajatele kättesaadav. Tööaeg
määratakse eraldi tööpäevadele ning nädalavahetustele.
Tööaeg on jaotatud klassidesse järgnevalt:
I 8:00 – 18:00
II 6:00 – 22:00
III 00:00 – 00:00
14. Süsteemi sisutoe tööaeg – süsteemi sisutoe tööaeg on ajavahemik, mille jooksul on võimalik saada
halduri tuge IT-teenusele.
Süsteemi sisutoe tööaeg on jaotatud klassidesse järgnevalt:
I 8:30 – 17:00 – pöördumised, mis vajavad halduri või muu teise osapoole osalemist pöördumise
lahendamisel.
II 7.30 – 18.30 – pöördumised, mis ei vaja halduri või muu teise osapoole osalemist pöördumise
lahendamisel.
15. Varukoopia klass – varukoopia klass määratleb varukoopiate tegemise sageduse lähtuvalt süsteemi
olulisusest ning maksimaalsest lubatud andmekaost.
16. Varukoopiate säilitamine – varukoopia säilitamine määratleb varukoopia tsükli pikkuse ehk
ajavahemiku, kui kaua säilitatakse varukoopiaid enne kustutamist (P-päev, N-nädal, K-kuu, A-aasta).
2. Täiendata lepingut lisaga nr 4 järgmises sõnastuses:
Lepingu nr 6/8-14
Lisa 4
Teenuse maksumus
MuISi majutus- ja haldusteenuse maksumus alates 1. juunist 2016:
Halduskulu aastal 2016 (alates 1. juuni):
Hind Hind
Maht Maht Kulu (EUR) Kulu (EUR)
Halduskulud (EUR) (EUR)
(kuus) (aastas) km-ta km-ga
km-ta km-ga
Süsteemi halduskulu * sh test ja
koolituskeskkonnad
Hinna sisse kuulub majutus; serverid;
virtuaalserverid; andmebaas; lisaks kõik
vajalikud tarkvarad koos toega (support);
kettapind (kiire) 300GB koos
varundusega (aeglastele ketastele) ja
elektrikulu 1 12 1 800,00 2 160,00 21 600,00 25 920,00
Töötasu (haldur) 1 12 1 950,00 2 340,00 23 400,00 28 080,00
Töötasu (projektijuht) 0,1 1,2 3 345,00 4 014,00 4 014,00 4 816,80
Töötasu (admin) sh valve 24/7 0,6 7,2 2 900,00 3 480,00 20 880,00 25 056,00
Töötasu (analüütik) 0,7 8,4 2 700,00 3 240,00 22 680,00 27 216,00
Töökoha maksumus (haldur 1,
projektijuht 0,1, analüütik 0,7, admin 0,6
= kokku 2,4 ühes kuus) 2,4 28,8 810,83 973,00 23 351,90 28 022,28
MuIS digihoidla 100TB 1 7 5 625,00 6 750,00 39 375,00 47 250,00
KOKKU aastas: 155 300,90 186 361,08
Arenduste tellimise (arendustellimuse koostamise teenus) tunnihind 2016. aastal on 40 eurot
(koos käibemaksuga).
Pooled sõlmivad Lepingu arvestusega, et pöördumiste arv ühes kuus ei ületa 100 juhtumit
(puudutab haldusteenust).
Kord aastas vaadatakse fikseeritud hinnad üle ning vajadusel tehakse muutmisettepanek.
/allkirjastatud digitaalselt/ /allkirjastatud digitaalselt/
Mehis Sihvart Paavo Nõgene
RIIGIVARA ÜLEANDMISE-VASTUVÕTMISE AKT nr 4-10.1/38
Käesolev riigivara üleandmise-vastuvõtmiste akt (edaspidi akt) on koostatud lähtudes
kultuuriministri 24.04.2019. a käskkirjast nr 91 „Riigivara üleandmine“.
1. Kultuuriministeerium (edaspidi üleandja) annab üle ning Muinsuskaitseamet (edaspidi
vastuvõtja) võtab vastu 01.05.2019. a seisuga alljärgneva riigivara:
1.1. Muuseumide infosüsteem (MuIS) (inventari nr M100-9-14, soetamise aeg 01.04.2009. a,
soetusmaksumus 862 476,35 eurot, jääkväärtus 30.04.2019. a seisuga 59 423,26 eurot);
1.2. MuIS infosüsteem (inventari nr M100-0000001000000000, soetamise aeg 01.11.2011. a,
soetusmaksumus 10 816 eurot, jääkväärtus seisuga 30.04.2019. a seisuga 0 eurot).
2. Koos punktis 1 nimetatud riigivaraga annab üleandja vastuvõtjale üle akti lisas nimetatud
riigivaraga seotud dokumendid.
Üleandja: Vastuvõtja:
Kultuuriministeerium Muinsuskaitseamet
Registrikood: 70000941 Registrikood: 70000958
Aadress: Suur-Karja 23, 15076, Tallinn Aadress: Pikk 2, 10123, Tallinn Harju maakond
E-post:
[email protected] E-post:
[email protected]
(allkirjastatud digitaalselt) (allkirjastatud digitaalselt)
Tarvi Sits Siim Raie
kantsler peadirektor
Lisa 1
Dokumendi
Dokumendi allkirjastamise
Dokumendi nimetus reg nr Teine pool kuupäev
Muuseumide infosüsteemi
1 kasutusleping 1.1-8/121 Betti Alveri Muuseum SA 23.09.2014
Muuseumide infosüsteemi
2 kasutuslepingu 1.1-8/121 lisa 2 6-9.1/287-1 Betti Alveri Muuseum SA 26.04.2019
Muuseumide infosüsteemi Carl Robert Jakobsoni
3 kasutusleping 1.1-8/115 Talumuuseum 17.09.2014
Muuseumide infosüsteemi
kasutamise lepingu nr 1.1-8/115 Carl Robert Jakobsoni
4 lisa 1 1.1-8/115 Talumuuseum 2.05.2017
Muuseumide infosüsteemi
5 kasutamise kokkulepe 1.1-8/101 Eesti Ajaloomuuseum 13.08.2014
Muuseumide infosüsteemi Eesti
6 kasutamise kokkulepe 1.1-8/100 Arhitektuurimuuseum 12.08.2014
Muuseumide infosüsteemi
7 kasutamise kokkulepe 1.1-8/99 Eesti Kunstimuuseum 11.09.2014
Muuseumide infosüsteemi Eesti Lennundusmuuseum
8 kasutusleping 6-9/25 SA 13.03.2016
Muuseumide infosüsteemi
kasutamise lepingu nr 6-9/25 lisa Eesti Lennundusmuuseum
9 1 6-9/25 SA 27.02.2017
Muuseumide infosüsteemi
10 kasutusleping 1.1-8/131 Maanteeamet 13.10.2014
Muuseumide infosüsteemi
kasutamise lepingu nr 1.1-8/131
11 lisa nr 2 Maanteeamet 7.01.2016
Muuseumide inosüsteemi
12 kasutamise kokkulepe 1.1-8/92 Eesti Meremuuseum SA 6.08.2014
Muuseumide infosüsteemi
13 kasutamise leping 6-9.1/179-1 Eesti Pank 16.10.2018
Muuseumide infosüsteemi Eesti Piimandusmuuseum
14 kasutamise leping 6-9.1/115-1 SA 23.04.2018
Muuseumide infosüsteemi Eesti Maaelumuuseumid
15 kasutamise leping 6-9.1/117-1 SA 19.04.2018
Muuseumide infosüsteemi
16 kasutamise kokkulepe 1.1-8/98 Eesti Rahva Muuseum 22.08.2014
Muuseumide infosüsteemi Eesti Spordi- ja
17 kasutamise kokkulepe 1.1-8/97 Olümpiamuuseum SA 1.08.2014
Eesti Sõjamuuseum -
Muuseumide infosüsteemi Kindral Laidoneri
18 kasutusleping 6-9/34 Muuseum 26.03.2015
Muuseumide infosüsteemi Eesti Tarbekunsti- ja
19 kasutamise kokkulepe 1.1-8/84 Disainimuuseum 14.08.2014
Muuseumide infosüsteemi Eesti Teatri- ja
20 kasutamise kokkulepe 1.1-8/82 Muusikamuuseum 4.08.2014
Muuseumide infosüsteemi Eesti Tervishoiu
21 kasutamise kokkulepe 1.1-8/87 Muuseum SA 4.08.2014
2 (6)
Muuseumide infosüsteemi Eesti Trükimuuseum
22 kasutusleping 1.1-8/116 MTÜ 2.10.2014
Muuseumide infosüsteemi
23 kasutusleping 1.1-8/130 Päästeamet 13.10.2014
Muuseumide infosüsteemi Eesti Vabaõhumuuseum
24 kasutamise kokkulepe 1.1-8/86 SA 1.08.2014
Muuseumide infosüsteemi Haapsalu ja Läänemaa
25 kasutamise kokkulepe 1.1-8/93 Muuseumid SA 12.04.2014
Muuseumide infosüsteemi
26 kasutamise kokkulepe 1.1-8/102 Harjumaa Muuseum 11.08.2014
Muuseumide infosüsteemi
27 kasutamise leping 6-9/96 Harjumaa Muuseum 28.06.2017
Muuseumide infosüsteemi
28 kasutamise kokkulepe 1.1-8/96 Hiiumaa Muuseum 28.08.2014
Muuseumide infosüsteemi
29 kasutamise leping 6-9.1/116-1 Ikoonimuuseum SA 27.04.2018
Muuseumide infosüsteemi Iisaku Kihelkonna
30 kasutamise leping 6-9/29 Muuseum SA 14.03.2017
Muuseumide infosüsteemi Järvakandi
31 kasutamise leping 6-9.1/133-1 Klaasimuuseum 23.05.2018
Muuseumide infosüsteemi
32 kasutamise kokkulepe 1.1-8/101 Ajakeskus Wittenstein SA 26.08.2014
Muuseumide infosüsteemi
33 kasutusleping 1.1-8/122 Jööri Küla Selts MTÜ 23.09.2014
Muuseumide infosüsteemi
34 kasutusleping 1.1-8/135 Liivi Muuseum 23.10.2014
Muuseumide infosüsteemi
kasutamise lepingu nr 1.1-8/135
35 lisa 2 Liivi Muuseum 13.01.2016
Muuseumide infosüsteemi
kasutamise lepingu nr 1.1-8/135
36 lisa 3 Liivi Muuseum 15.02.2018
Juuru ja Hageri
Muuseumide infosüsteemi Kihelkonna Muuseumid
37 kasutamise kokkulepe 1.1-8/88 SA 1.09.2014
Muuseumide infosüsteemi Eesti Mootorspordi
38 kasutusleping 1.1-8/117 Ajalugu MTÜ 01.10.2014
Muuseumide infosüsteemi
kasutamise lepingu nr 1.1-8/117 Eesti Mootorspordi
39 lisa 2 Ajalugu MTÜ 4.01.2016
Muuseumide infosüsteemi
40 kasutusleping 1.1-8/119 Muhu Muuseum 24.09.2014
Muuseumide infosüsteemi
kasutamise lepingu nr 1.1-8/119
41 lisa 2 Muhu Muuseum 31.12.2015
Muuseumide infosüsteemi
kasutamise lepingu nr 1.1-8/117
42 lisa 3 Muhu Muuseum 12.03.2019
Muuseumide infosüsteemi
43 kasutusleping 1.1-8/120 Narva Muuseum SA 24.09.2014
Muuseumide infosüsteemi
kasutamise lepingu nr 1.1-8/120
44 lisa 2 Narva Muuseum SA 4.04.2018
3 (6)
Muuseumide infosüsteemi
45 kasutamise leping 12-2/29 NUKU SA 25.06.2015
Muuseumide infosüsteemi Palamuse O.Lutsu
46 kasutamise kokkulepe 1.1-8/80 Kihelkonnakoolimuuseum 4.08.2014
Muuseumide infosüsteemi
47 kasutamise leping 6-9/26 Põltsamaa Muuseum 7.03.2016
Muuseumide infosüsteemi
kasutamise lepingu nr 6-9/26 lisa
48 2 Põltsamaa Muuseum 4.04.2019
Muuseumide infosüsteemi
49 kasutamise kokkulepe 1.1-8/91 Pärnu Muuseum SA 2.09.2014
Muuseumide infosüsteemi
50 kasutusleping 1.1-8/110 Rannarahva Muuseum SA 23.09.2014
Muuseumide infosüsteemi
kasutamise lepingu nr 1.1-8/110
51 lisa 2 Rannarahva Muuseum SA 4.01.2016
Muuseumide infosüsteemi
52 kasutamise kokkulepe 1.1-8/89 Rannarootsi Muuseum 1.08.2014
Muuseumide infosüsteemi
53 kasutamise kokkulepe 1.1-8/85 Saaremaa Muuseum 11.08.2014
Muuseumide infosüsteemi
54 kasutusleping 1.1-8/126 Seto Talumuuseum 26.09.2014
Muuseumide infosüsteemi
kasutamise lepingu nr 1.1-8/126
55 lisa 2 Seto Talumuuseum 13.01.2016
Muuseumide infosüsteemi
kasutamise lepingu nr 1.1-8/126
56 lisa 3 6-9.1/293-1 Setomaa Muuseumid 25.04.2019
Muuseumide infosüsteemi
57 kasutusleping 1.1-8/132 Pühalepa Vallavalitsus 8.10.2014
Muuseumide infosüsteemi
kasutamise lepingu nr 1.1-8/132
58 lisa 1 Pühalepa Vallavalitsus 19.04.2017
Muuseumide infosüsteemi
59 kasutamise leping 6-9/28 Tallinna Kirjanduskeskus 28.03.2017
Muuseumide infosüsteemi
60 kasutusleping 1.1-8/113 Tallinna Linnamuuseum 18.09.2014
Muuseumide infosüsteemi
kasutamise lepingu nr 1.1-8/113
61 lisa 2 Tallinna Linnamuuseum 15.01.2016
Muuseumide infosüsteemi
kasutamise lepingu nr 1.1-8/113
62 lisa 3 6-9.1/292-1 Tallinna Linnamuuseum 15.04.2019
Muuseumide infosüsteemi
63 kasutusleping 1.1-8/114 Tallinna Ülikool 22.09.2014
Muuseumide infosüsteemi
kasutamise lepingu nr 1.1-8/114
64 lisa 2 Tallinna Ülikool 6.01.2016
Muuseumide infosüsteemi
kasutamise lepingu nr 1.1-8/113
65 lisa 3 6-9.1/290-1 Tallinna Ülikool 15.04.2019
Muuseumide infosüsteemi
66 kasutusleping 1.1-8/123 Tallinna Tehnikaülikool 24.09.2014
4 (6)
Muuseumide infosüsteemi
kasutamise lepingu nr 1.1-8/123
67 lisa 2 Tallinna Tehnikaülikool 4.01.2016
Muuseumide infosüsteemi
kasutamise lepingu nr 1.1-8/114
68 lisa 3 1.1-8/1232 Tallinna Tehnikaülikool 24.04.2019
Muuseumide infosüsteemi
69 kasutamise kokkulepe 1.1-8/83 Tartu Kunstimuuseum 4.08.2014
Muuseumide infosüsteemi
70 kasutusleping 12-2/17 Tartu Linnamuuseum 11.05.2015
Muuseumide infosüsteemi
71 kasutamise leping 6-9.1/134-1 Tartu Ülikool 21.05.2018
Muuseumide infosüsteemi
72 kasutamise leping 6-9.1/120-1 Tarvastu Muuseum 20.04.2018
Muuseumide infosüsteemi
kasutamise lepingu nr 6-9.1/120-
73 1 lisa 3 Tarvastu Muuseum 8.04.2019
Eesti Teaduste Akadeemia
Muuseumide infosüsteemi Underi ja Tuglase
74 kasutusleping 1.1-8/148 Kirjanduskeskus 2.12.2014
Muuseumide infosüsteemi Eesti Teaduste Akadeemia
kasutamise lepingu nr 1.1-8/148 Underi ja Tuglase
75 lisa 1 Kirjanduskeskus 17.02.2017
Muuseumide infosüsteemi Eesti Teaduste Akadeemia
kasutamise lepingu nr 1.1-8/148 Underi ja Tuglase
76 lisa 3 6-9.1/291-1 Kirjanduskeskus 15.04.2019
Muuseumide infosüsteemi
77 kasutusleping 6-9/5 Uue Kunsti Muuseum SA 9.01.2015
Muuseumide infosüsteemi
78 kasutamise kokkulepe 1.1-8/81 Valga Muuseum 5.08.2014
Muuseumide infosüsteemi
79 kasutamise leping 6-9/68 Valga Muuseum 9.05.2017
Muuseumide infosüsteemi
80 kasutusleping 1.1-8/111 Vene Muuseum MTÜ 12.09.2014
Muuseumide infosüsteemi
kasutamise lepingu nr 1.1-8/111
81 lisa 1 Vene Muuseumi MTÜ 15.02.2019
Muuseumide infosüsteemi
82 kasutamise kokkulepe 1.1-8/79 Viljandi Muuseum 1.08.2014
Muuseumide infosüsteemi
83 kasutamise kokkulepe 1.1-8/109 Virumaa Muuseumid SA 23.09.2014
Muuseumide infosüsteemi
84 kasutamise kokkulepe 1.1-8/90 Põlva Talurahvamuuseum 4.08.2014
Muuseumide infosüsteemi Dr.Fr.R.Kreutzwaldi
85 kasutamise kokkulepe 1.1-8/94 Memoriaalmuuseum 1.08.2014
Muuseumide infosüsteemi
86 kasutusleping 1.1-8/134 Väike-Maarja Muuseum 5.11.2014
Registrite ja
MuIS hooldusteenuse Infosüsteemide Keskus,
87 hankeleping 2018 6-9.1/170-1 Avalanche Laboratory OÜ 10.09.2018
Registrite ja
88 Koostöökokkulepe nr 6/8-14 6-9/6-1 Infosüsteemide Keskus 12.01.2015
5 (6)
Koostöökokkuleppe 6/8-14
muudatus (Muuseumide
infosüsteemi teenusteenustaseme Registrite ja
89 lepe) 6-9/19-8 Infosüsteemide Keskus 23.08.2016
Koostöökokkuleppe nr 6/8-14 Registrite ja
90 muutmise kokkulepe 6-9/3 Infosüsteemide Keskus 20.01.2017
Koostöökokkuleppe 6/8-14 lisa 6 Registrite ja
91 ja lisa 4 6-9/105-13 Infosüsteemide Keskus 5.12.2017
Koostöökokkuleppe 6/8-14 Registrite ja
92 muutmine 6-9.6/220-1 Infosüsteemide Keskus 16.01.2019
Kõik
[email protected]
postkastiga seotud e-kirjad kuni
30.04.2019 k.a ja Kadri Nigulase
kontoga failid 30.04.2019
seisuga. (kantakse üle otse
[email protected]
93 kontole)
6 (6)