Leping

Riigihange: „Veebide hooldus- ja arendustööde teenuse tellimine“

Minikonkurss – Digiriigi Akadeemia hooldustööde teostamine

Lähteülesanne (töö kirjeldus)

Tellitavaks tööks on Digiriigi Akadeemia keskkonna tõrgeteta toimimiseks vajalike

hooldustööde teostamine alates hankelepingu sõlmimisest kuni 31.08.2025.

1.1. Kooskõlas HD Lisa 1 „Tehniline kirjeldus“ p-s 3 kirjeldatuga hõlmab hooldustööde

teostamine Digiriigi Akadeemia keskkonnas järgnevaid tegevusi:

1.1.1. Digiriigi Akadeemia platvormile sisselogitud kasutajate arvu piiraja loomine ja

juurutamine, mis on vajalik platvormi tõrgeteta toimimise tagamiseks suure

kasutuskoormuse korral. Töö peab olema teostatud alates hankelepingu sõlmimisest

kuni 31.10.2024.

1.1.1.1.Pakkuja peab välja arendama funktsionaalsuse, mis tuvastab, kui platvormil on ületatud

määratud maksimumarv sisselogitud kasutajaid. Funktsionaalsus peab suunama uued

sisselogimiskatsed teavituslehele, mis teavitab kasutajat, et platvorm on hetkel väga

populaarne ning soovitab mõne aja möödudes uuesti proovida.

1.1.1.2.Pakkuja peab looma ja üles seadma teavituslehe, mis vastab Digiriigi Akadeemia

kujunduspõhimõtetele ja tagab selge ning arusaadava teavituse kasutajatele.

Teavitusleht peab olema kohandatav ja hõlpsasti hallatav platvormi administraatorite

poolt.

1.1.1.3.Pakkuja peab sessioonide piiraja arenduse integreerima Digiriigi Akadeemia platvormi

Moodle’i keskkonda, tagades selle sujuva töö ja vastavuse platvormi olemasolevate

seadistustega. Lahendus peab olema võimalikult lihtne ja eelistatavalt põhinev Moodle’i

enda olemasolevatel funktsioonidel ja võimalustel, et vähendada keerukust ja tagada

lihtsam haldamine tulevikus.

1.1.1.4.Pakkuja peab teostama kõik vajalikud testid, et kinnitada sessioonide piiraja

funktsionaalsust erinevate kasutusstsenaariumite korral, sealhulgas maksimaalse

koormuse ja erandjuhtumite testid. Tulemused tuleb dokumenteerida ja esitada tellijale.

1.1.1.5.Pakkuja peab koostama ja esitama juhised platvormi administraatoritele sessioonide

piiraja haldamiseks ning kasutajate teavitamiseks, kui piiraja on aktiveeritud.

1.1.1.6.Pakkuja peab kaardistama, prognoosima ja eelarvestama sessioonide piiraja arenduse ja

juurutamisega kaasnevad kulud.

1.1.2. Digiriigi Akadeemia platvormi integreerimine avalikus sektoris kasutatava MS365

ökosüsteemis oleva Teamsi tarkvaraga, mis on vajalik videokoosolekute

funktsionaalsuse loomiseks ja tõhusama koostöö tagamiseks. Töö peab olema teostatud

alates hankelepingu sõlmimisest kuni 13.01.2025.

1.1.2.1.Pakkuja võib kasutada juba olemasolevaid ametlikke ja turvalisi lahendusi MS365

Teamsi integreerimiseks. Vajadusel peab olema valmis lahendust sobivalt arendama.

Funktsionaalsus peab võimaldama platvormi kasutajatel luua, hallata ja liituda MS

Teamsi koosolekutega otse Moodle'i keskkonnast, säilitades kõik vajalikud turva- ja

privaatsusseaded. Lõpptulemus peab võimaldama Digiriigi Akadeemias kasutada kõiki

Teamsi baasfunktsionaalsusi. Tehnilise keerukuse või finantsilise otstarbekuse tõttu

saab Teamsi funktsionaalsustes tellijaga läbirääkimisel mööndusi teha

1.1.2.2.Pakkuja peab kujundama ja seadistama kasutajaliidese, mis võimaldab Digiriigi

Akadeemia platvormi kasutajatel mugavalt ja intuitiivselt kasutada MS Teamsi

videokoosolekuid. Kasutajaliides peab vastama Digiriigi Akadeemia

kujunduspõhimõtetele ja olema kooskõlas Moodle'i keskkonnaga.

1.1.2.3.Pakkuja peab arvestama ja olema valmis tegelema avaliku sektori MS365 ökosüsteemi

ligipääsude eripäradega lahenduse arendamisel. Eesmärk on luua võimekus, mis

võimaldab erinevate asutuste töötajatel ja avaliku sektori välistel külaliskasutajatel

osaleda ühistes videokoosolekutes.

1.1.2.4.Pakkuja peab tagama, et kõik MS Teamsi ja Moodle'i vahelised andmevood vastavad

RIT-i kehtestatud turvalisuse ja privaatsuse nõuetele.

1.1.2.5.Pakkuja peab tagama sujuva töö ja kooskõla olemasolevate süsteemidega. Pakkuja peab

läbi viima kõik vajalikud testid, sealhulgas funktsionaalsuse, autentimise,

autoriseerimise, andmevahetuse, turvalisuse ja kasutajasõbralikkuse testid erinevate

sihtrühmade jaoks, et kinnitada integratsiooni kvaliteeti ja töökindlust. Kõik API-d ja

pluginad peavad olema täielikult ühilduvad olemasolevate autentimis- ja

autoriseerimismehhanismidega.

1.1.2.6.Integratsioon peab olema optimeeritud suure kasutajate arvu jaoks, tagades, et süsteem

suudab hallata nii autentimis- kui ka API-kõnesid tõhusalt ilma jõudlust vähendamata.

Pakkuja peab tagama, et lahendus on optimeeritud tippkoormuse ajal, kasutades tõhusat

ressursihaldust ja koormuse tasakaalustamist.

1.1.2.7.Pakkuja peab koostama ja esitama põhjalikud juhised platvormi administraatoritele ja

kasutajatele MS Teamsi integratsiooni kasutamiseks.

1.1.2.8.Pakkuja peab kaardistama, prognoosima ja eelarvestama MS Teamsi integratsiooniga

kaasnevad kulud, sealhulgas arenduse, seadistamise ja hoolduse kulud. Eelarve peab

hõlmama kõiki võimalikke lisakulusid, mis võivad integratsiooni käigus tekkida.

1.1.3. Keskkonna uuendamine Moodle 4.3.3. versioonilt 4.5. versioonile (sh vajalike tarkvara

uuenduste ja paranduste paigaldamine, platvormi vana versiooni funktsionaalsuste uue

versiooniga ühildamine ja toimimise kontrollimine), mis peab olema teostatud hiljemalt

13.01.2025:

1.1.3.1. Pakkuja peab kaardistama, prognoosima ja eelarvestama hooldustööde maksumuse

prognoosis võimalikud kaasnevad kulud, mis uuendamisega kaasnevad.

1.1.4. Süsteemi häireteta töökorras hoidmine, sealhulgas süsteemi töös esilekerkivate vigade

tuvastamine, Hankija teavitamine avastatud vigadest (koos lahendusettepanekuga) ning

lahendamine:

1.1.4.1. Pakkuja peab vähemalt kord kalendrikuu jooksul kontrollima veebilehtede

sisuhaldustarkvarade, kooditeekide ning nende komponentide turvauuenduste

olemasolu.

1.1.4.2. Pakkuja peab turvauuendused planeerima ja paigaldama esimesel võimalusel,

hoiatades sealjuures Hankijat eelnevalt töödest, mis mõjutavad keskkonna

kättesaadavust:

1.1.4.2.1. kui tegemist on kriitiliste turvauuendustega, siis tuleb uuendused paigaldada

ühe tööpäeva jooksul.

1.1.4.2.2. kui tegemist on vähekriitiliste turvauuendustega, siis tuleb nende

paigaldamine planeerida ajale, mil keskkonna kasutajate hulk ning seeläbi

muudatustega kaasnevatest ebamugavustest mõjutatute arv on võimalikult

madal (sh öötundidele).

1.1.4.3. Perioodil 11.11.2023-26.08.2024 kulus kokku 758 töötundi, millest p-s 1.1.2.

nimetatud teenuse osutamiseks kaks kolmandikku kogu töötundide arvust.

1.1.5. (vajadusel) Klienditoe pakkumist platvormi lõppkasutajatele tööpäeviti vahemikus kl

9.00-17.00 (v.a riigipühad):

1.1.5.1. klienditoe päringud tuleb registreerida „ticket-põhises“ süsteemis, mis võimaldab

taasesitatavas formaadis jälgida päringu lahendamiseks kuluvat aega ning teha

Hankija päringu põhjal kokkuvõtteid levinumatest küsimustest ja/või tõrgetest,

mille korral lõppkasutajad pöörduvad.

1.1.5.2. Perioodil 11.11.2023-26.08.2024 tellija p-s 1.1.3. nimetatud teenust ei tellinud.

Hinnanguline vajadus uuel perioodil kuni 10 tundi kalendrikuus.

1.1.6. Hankija konsulteerimine teenusega seotud küsimuste ja probleemide osas.

1.2. Pakkuja on kohustatud:

1.2.1. teavitama esimesel võimalusel, kuid mitte hiljem kui 24 tunni jooksul Hankijat süsteemi

planeerimatutest hooldustöödest ja nende teostamise käigus ilmnevatest probleemidest

teavitamine;

1.2.2. planeerima koostöös Hankijaga aegsasti süsteemi tööga seotud katkestused;

1.2.3. teavitama Hankijat hooldustööde käigus tuvastatud ilmnenud arendusvajadustest (koos

esialgse ajakuluhinnanguga);

1.2.4. kajastama süsteemis tehtud muudatused dokumentatsioonis ja juhendites;

1.2.5. tagama p 1.1.1. nimetatud keskkonna uuendamisel eelmise versiooni funktsionaalsused.

1.3. Hooldustööde teostamise kohta on Pakkuja kohustatud pidama elektroonilist päevikut, kus

peavad olema eraldi välja toodud hankija tellitud konsultatsiooniks kulunud aeg, vigade

parandamiseks kulunud aeg ja hooldusrutiinidele kulunud aeg.

1.4. Töö Pakkumuse eelarvestamisel koostab Pakkuja prognoosi maksimaalsetest võimalikest

kuludest. Hankelepingu lõplik maksumus moodustub elektroonilises päevikus kajastatud

töötundide alusel.

1.4.1. Hankija nõudmisel esitab Pakkuja Hankijale viivitamatult, aga mitte hiljem kui 2

tööpäeva jooksul väljavõtte teenuse päevikust.