PRÍSTUP K PROJEKTU
Vzor pre manažérsky výstup I-03
podľa vyhlášky MIRRI č. 401/2023 Z. z.

Schvaľovanie dokumentu

1. História dokumentu

Účel dokumentu

V súlade s vyhláškou MIRRI č. 401/2023 Z.z. v znení neskorších predpisov je tento výstup I-02 Projektový zámer určený na rozpracovanie detailných informácií prípravnej a iniciačnej fázy projektu z pohľadu aktuálneho stavu, budúceho stavu a navrhovaného riešenia.

Dokument Projektový zámer má obsahovať manažérske zhrnutie, rozsah, ciele a motiváciu na realizáciu projektu, zainteresované strany, návrh merateľných ukazovateľov a obsahuje aj

                1. detailný opis požadovaných projektových výstupov,

                2. detailný opis obmedzení, predpokladov, tolerancií a návrh organizačného zabezpečenia projektu,

                3. detailný opis rozpočtu projektu a jeho prínosov,

                4. harmonogram projektu,

                5. vyhodnotenie rizík a závislostí,

                6. architektúru riešenia projektu na úrovni biznis vrstvy, aplikačnej vrstvy, dátovej vrstvy, technologickej vrstvy a bezpečnostnej architektúry,

                7. vyhodnotenie alternatív riešenia projektu pre každú vrstvu architektúry riešenia,

                8. špecifikáciu a klasifikáciu údajov spracovaných v projekte,

                9. požiadavky na prevádzku a údržbu výstupov projektu,

                10. požiadavky na technologickú infraštruktúru a posúdenie alternatív prevádzky infraštruktúry cloud computingom,

                11. požiadavky na zdrojové kódy,

                12. opis implementácie projektu a preberania výstupov projektu.

2.1 Použité skratky a pojmy

3. Popis navrhovaného riešenia

Predmetom zákazky je dodanie Platformy elektronického testovania (PET) pre digitálne testovanie a súvisiace služby. Riešenie má poskytovať funkcie pre tvorbu úloh, tvorbu a manažment testov, vykonávanie testov, hodnotenie testov, vytvorenie a export dát pre štatistické spracovanie výsledkov. Súčasťou zákazky je aj podpora prevádzky, školenia pre používateľov, konzultácie a rozvoj.

Nástup nových komunikačných technológií, zlepšenie dostupnosti vysokorýchlostného internetu s dostatočnou kvalitou a stabilitou spojenia a predovšetkým dostupnosť hotových riešení viedli Verejného obstarávateľa k odklonu od budovania vlastného, proprietárneho systému. Nový prístup  počíta s využitím existujúcich riešení s licenčnou politikou zameranou na predom stanovenú mernú jednotku. Zásadnými prínosmi sú:

•              časové hľadisko, teda rýchlosť spustenia elektronického testovania,

•              ľahká škálovateľnosť podľa potrieb trhu a demografickej reality počtu testovaných žiakov,

•              dostupnosť nových vylepšení, ktoré realizuje prevádzkovateľ na základe potrieb trhu,

•              kompatibilita so svetovými štandardami elektronického testovania.

Do nového riešenia je potrebné zapracovať aj skúsenosti zo starého systému (zjednodušenie o funkcie, ktoré majú vhodné alternatívy). Zároveň vnímame aj zmenu trhovej situácie v postpandemickej dobe, kedy sa vyformovala skupina SaaS služieb, poskytujúcich požadované funkcie v značnej zhode s požiadavkami, s vysokou mierou spoľahlivosti a pre vysoké počty žiakov.

4. Architektúra riešenia projektu

Nasledujúci obrázok zobrazuje celkový pohľad na architektúru riešenie. Je výsledkom porovnania alternatív podľa Projektového zámeru.

                                                                                   Obrázok 1 Náhľad celkovej architektúry v notácii ArchiMate

4.1 Biznis vrstva

4.1.1 Návrh riešenia v biznis vrstve architektúry

Navrhovaný systém z hľadiska biznis architektúry rámcovo zachováva väčšinu služieb existujúceho systému :

• tvorba a životný cyklus Banky úloh a  testov,
• národné - certifikačné testovanie žiakov,
• školské (tz. necertifikačné, ale centrálne pripravované) testovanie žiakov,
• realizáciu dotazníkov vo forme anonymných testov,
• adaptívne testovanie,
• pripravenosť na externú komunikáciu s inými systémami, napr. rozhranie pre komunikáciu so školskými IS dôležitú pre prenos údajov, migráciu „uvoľnených“ úloh pre učiteľské testovanie (napr. do VIKI),
• štatistiky a reporting.

Z hľadiska používateľa navrhovaný systém zachováva najviac používané funkcie, pričom bude zefektívnený za účelom zjednodušenia pre používateľa ako aj zjednodušenia vývoja a údržby systému. Jednoduchší systém je lacnejší, obsahuje menej chýb, ľahšie sa používa a tým, že sa sústredí iba na podstatné veci, je predpoklad že ich bude robiť lepšie.

Realizácia systému bude rozdelená na 2 etapy. Súčasťou Release 1 bude plne funkčný systém, pripravený pre tvorbu banky úloh a pilotnú prevádzku (3d).

Súčasťou Release 2 bude systém s plnou prípravou na testovaciu kampaň, vrátane výkonnosti realizácie testov, efektívnosti hodnotenia výsledkov a spracovanie výsledkov do reportov a štatistík.

Systém teda bude zabezpečovať nasledovné funkcie:

Správa číselníkov

sa stará o centrálnu správu spoločných číselníkov a správu registrov škôl, žiakov a zamestnancov škôl. Administrátori číselníkov a registrov tak môžu na jednom mieste spravovať obsahy číselníkov a registrov.

Správa používateľov

Správa používateľov z radov študentov, učiteľov a zamestnancov MŠVVaM SR/NIVAM bude zabezpečovať vytvorenie používateľských účtov.

Banka úloh

V rámci banky úloh sa tvoria, testujú, schvaľujú a klasifikujú jednotlivé úlohy pred zaradením medzi ostré úlohy.

Zostavovanie testov

Pre konkrétne testovanie je možné zostaviť konkrétny test výberom z banky úloh pomocou filtrovacích kritérií, kľúčových slov a ďalších možností.

Integrácia na externé služby

Systém musí byť pripravený na využívanie externých API a s malými zmenami (formou change requestov) na využitie týchto API v rámci interných funkcií systému.

Štatistiky a porovnanie

Štatistiky poskytujú používateľom možnosti štatistického spracovania získaných výsledkov, ako napríklad sledovanie žiakov naprieč testami, alebo zlepšenie žiakov naprieč obdobiami. Bude možné nadefinovať statické štatistiky, ktoré sa budú publikovať pre verejnosť na portál, ako aj vytvárať ad-hoc štatistiky. Systém bude podporovať aj export kompletných údajov (prístup do databázy).

Národné testovanie

Národné testovanie umožňuje realizovať národné testovanie s jeho špecifikami. V prípade potreby bude testovanie môcť byť rozšírené aj na prijímacie testy na vysoké alebo stredné školy.

• tvorbu nových úloh, ich overenie a zaradenie do banky úloh,
• zostavovanie úloh do testov a ich priraďovanie žiakom, resp. skupinám žiakov,
• štatistiky a reporty z údajov systému,
• národné testovanie,
• učiteľské testovanie,
• voľne dostupné testovanie.

Školské testovanie

Školské testovanie umožňuje realizovať testovanie veľmi podobné národnému, ale na menšej vzorke pre všetky druhy testov národného testovania.

                                                                                                                                                                    Obrázok 2 Biznis vrstva architektúry

4.1.2 Požiadavky na priebeh testovaní a ich bezpečnosť

4.1.2.1 Typy testov

PET umožní realizáciu nasledovných typov testov: 

1. Certifikačné a pilotné testovanie 

Certifikačné a pilotné testovanie spravuje realizátor e-testovania. Účelom je testovanie na základných školách, externá časť maturitných skúšok (eMaturita) a iné (napr. prijímacie skúšky na stredné, resp. vysoké školy) a pilotáž pre účely prípravy úloh pre testovania.  Základné požiadavky: 

• vykonávanie testu na zabezpečenej pracovnej stanici s kontrolovaným prístupom (zabezpečenie na úrovni informačného systému alebo prehliadača, nie manuálne) k systémovým funkciám, ktorá neumožňuje používanie neoprávnených zdrojov,  počas realizácie testu, alebo neumožní pokračovanie v teste v prípade porušenia pravidiel, 
• možnosť overenia identity testovanej osoby aj počas realizácie testu (vizuálna kontrola iba ako doplnková požiadavka v rámci rozvoja), 
• vysoký stupeň zabezpečenia neoprávneného prístupu k úlohám v banke úloh a testov a v rámci procesu prípravy a realizácie testu, zabezpečenie neoprávneného prístupu k už vytvorenému testu, aj s využitím šifrovania obsahu, 
• nekvalitný internet nemá mať zásadný vplyv na výsledok testovania. Vypracovanie odpovedí na testové otázky má prebehnúť korektne aj pri krátkodobých výpadkoch pripojenia na internet,  
• paralelné prihlásenie – identifikácia a autentifikácia (v priebehu 5 sekúnd) pre počty žiakov podľa kapitoly 5.2 a následná realizácia testovania, za účasti administrátorských používateľov, 
• komplexné logovanie všetkých akcií žiaka a administrátora, aj v prípade, ak nie je pripojenie na Internet.

2. Školské testovanie  

Školské testovanie spravuje realizátor e-testovania. Účelom je poskytnúť školám elektronické testy pre priebežné, sumatívne aj formatívne (kriteriálne) testovanie.  

Základné požiadavky: 

• nižšia úroveň bezpečnosti, pričom ale musí byť monitorovateľné a v informačnom systéme zaznamenávané, či sa žiak prepol do iného prostredia, 
• paralelné testovanie cca 1 000 – 3 000 žiakov, rozdelené do viacerých dní, nižšia záťaž pri prihlasovaní. 

3. Dotazníky 

Účelom dotazníkov je realizácia výskumu a monitorovanie úrovne vedomostí, zručností a kľúčových kompetencií žiakov, rovnako ako aj sledovanie trendov kvality škôl.  

Dotazník bude realizovaný samostatne alebo bude byť reťazovo prepojený s testom (buď hneď za sebou, test + dotazník,  pričom sa vytvorí dokument s obsahom vykonaného testu a bude k nemu pripojený dotazník spätnej väzby, alebo sa bude môcť dotazník realizovať aj v časovom odstupe od testu, ale databázy a výsledky budú prepojiteľné). 

Dotazníky budú: 

• neanonymné (žiaci, učitelia, vedenie školy) – prepojenie s databázou používateľov, 
• anonymné (rodičia, verejnosť) – jednorazové prístupy do dotazníka bez prístupových práv do informačného systému, dáta prichádzajú do informačného systému a poskytujú výstupy pre realizátora e-testovania. 

Pre konkrétne testovanie je možné zostaviť test výberom z banky úloh pomocou filtrovania kritérií. 

Nástroj umožní autorovi určiť povahu testu: statický, čiastočne dynamický a dynamický:  

• Statický test má úlohy pevne určené a jednoznačne nemenne usporiadané pred spustením testovania.  
• Dynamický test vyberá v priebehu testovania nasledujúcu testovú úlohu náhodne zo súboru podľa nastavených parametrov, napr. tak, aby bol dodržaný rovnaký stupeň obťažnosti testov pre všetkých kandidátov. Do tejto kategórie spadá aj adaptívne testovanie, ktoré je budúcou rozvojovou požiadavkou. 
• Čiastočne dynamický test umožní kombináciu statických a dynamických položiek. 

4.1.2.2 Testovanie eTest 2.0

Testovanie žiakov pozostáva z nasledovných krokov: 

• príprava testovania (vytvorenie súboru testovaní, nastavenie testov k súboru testovaní, parametrov testovania),
• naplánovanie testovania, 
• testovanie žiakov, 
• vyhodnotenie testu pre žiaka po skončení testu (tzv. predbežný výsledok), 
• hodnotenie odpovedí žiakov na otvorené otázky v teste vrátane hodnotenia esejí,
• celkové štatistické vyhodnotenie. 

4.1.2.3 Príprava testovania

PET umožní tvorbu úloh prinajmenšom nasledovnými spôsobmi: importom, vytvorením v autorskom nástroji, vytvorením zo šablóny, duplikovaním – skopírovaním úlohy alebo niektorých prvkov úlohy.  

Pre jeden test je možné vytvoriť viacero predpisov, resp. foriem pre test (líšia sa presne stanovaným pevným poradím úloh a distraktorov, resp. úprava pre účely žiakov so zdravotným znevýhodnením – zámena položky za inú).  

V rámci testu je možné  

• definovať sekcie testu zoskupením položiek podľa  určitých kritérií (pozrite katalóg požiadaviek),  
• vytvárať spoločné obsahy pre viacero úloh – príklad PISA testu s úlohami so spoločným obsahom,
• definovať povolené zdroje (kalkulačka, slovníky). 

Autor testu bude mať možnosť vykonať skúšku vytvoreného testu a vytvoriť tlačovú predlohu testu. 

Pre certifikačné a pilotné testovanie, a rovnako aj pre školské testovanie, je potrebné vytvoriť aj tzv. súbory testovaní, ktoré sa po zadefinovaní realizátora e-testovania naplánujú a následne zverejnia, aby si mohli školy na základe týchto publikovaných súborov testovaní  plánovať jednotlivé testy. Samotné vytváranie súborov testovaní spočíva v zadávaní všetkých potrebných metaúdajov k jednotlivým súborom a z výberu požadovaných predpisov testov, ktoré budú obsiahnuté v rámci vytváraného súboru testovaní. 

4.1.2.4  Plánovanie testu

Plánovanie testu pozostáva z viacerých aktivít, ktoré je potrebné vykonať na strane subjektu, ktorý plánuje daný test (realizátor e-testovania). Plánovanie je zastrešené lokálnym administrátorom, ktorý  na začiatku vyberie zo zoznamu dostupných testov konkrétny test, ktorý plánuje realizovať. Pre zvolený test je potrebné nastaviť časové intervaly pre zviditeľnenie a sprístupnenie testu z pozície školy (tieto časové intervaly musia byť podmnožinou časových intervalov pre zviditeľnenie a sprístupnenie testu, ktoré stanoví realizátor e-testovania pre daný súbor testovaní, resp. test) a zvoliť, ktoré ročníky a triedy v ročníkoch, resp. ktorí žiaci môžu predmetný test absolvovať. V prípade potreby musí PET umožniť upraviť zoznam žiakov, ktorí budú mať plánovaný test dostupný a modifikovať iné parametre, napr. parametre termínu testovania (deň, čas, názov termínu, administrátorov). 

PET zároveň musí umožniť naplánovať žiakov do „virtuálnej“ testovacej miestnosti – nemusí korešpondovať s reálnou triedou, resp. reálnou školou a toto plánovanie budú môcť vykonať administrátori informačného systému na strane realizátora e-testovania alebo aj administrátor na strane vybranej školy. Táto funkcionalita je potrebná napr. pri realizácii opravného a náhradného termínu maturity, keď je potrebné otestovať žiakov rôznych škôl v jednom „testovacom centre“. 

4.1.2.5 Realizácia testu

Realizácia samotného testovania žiakov prebieha vo vopred určený čas, kedy sa testovaným žiakom zobrazí konkrétny test v rámci ich profilu. Následne si môžu žiaci konkrétny test spustiť v rámci svojho žiackeho profilu a prejsť na samotné testovanie.  

Dozorujúci pedagóg počas samotného testu dohliada predovšetkým na korektný priebeh testu. Jeho hlavnou úlohou je zabezpečiť, aby sa podarilo všetkým testujúcim žiakom spustiť potrebný test a aby celé testovanie prebiehalo bezproblémovo a plynule. V prípade potreby mu PET umožní na vzniknuté mimoriadne situácie zareagovať a vyriešiť ich, najmä zablokovanie testu a jeho opätovné spustenie.

S cieľom eliminácie zlyhania ľudského faktoru je potrebné monitorovať dozorujúcich pedagógov počas testovania. Každá zmena priebehu testovania bude preto zaznamenaná a vyhodnotená. Po zastavení testu testovaným bude následné pokračovanie vyžadovať asistenciu dozoru, pričom všetky udalosti budú zaznamenané v PET s presným časovým údajom a identifikáciou dozorujúceho. Doba opustenia testu, počet opustení testu, ako aj opakované porušenie pravidiel testovania budú tvoriť základ
pre proaktívne sledovanie priebehu testovania a zapojenie centrálneho dohľadu realizátora e-testovania.

Každý test je časovo obmedzený, o čom sú žiaci informovaní a pred uplynutím času aj notifikovaní.  V prípade, že nestihnú uložiť test pred ukončením časového limitu, PET uloží všetky ich vyplnené odpovede a test automaticky uzavrie.  

V závislosti od predpisu testu, resp. typu testovania, PET umožní vytvoriť tlačový výstup ukončeného testu (.pdf alebo adekvátny formát dokladu o vykonanom teste pre žiaka aj pre realizátora e-testovania)  s možnosťou voľby, či súčasťou testu bude aj porovnanie odpovedí žiaka a správnych odpovedí podľa kľúča, alebo bez kľúča správnych odpovedí. 

Bezprostredne po ukončení testu sú žiaci oboznámení s výsledkami automaticky hodnotených odpovedí (tzv. predbežný výsledok dostupný hneď po ukončení testu). Slovné odpovede žiakov (otvorené úlohy) budú vyhodnotené neskôr a o finálnom výsledku testu bude PET každého žiaka notifikovať a kompletný výsledok si  môže následne pozrieť v rámci svojho profilu.  

Predbežný výsledok obsahuje predbežné informačným systémom automaticky vyhodnotené odpovede žiakov v zmysle nastaveného kľúča správnych odpovedí. Automatické výsledky, tzv. predbežné, musia byť zobrazené žiakovi hneď po ukončení testu (vo forme počtu získaných bodov a aj v percentuálnom vyjadrení úspešnosti žiaka v teste)  a zároveň budú uložené v histórii daného žiaka. Úplné výsledné údaje budú k dispozícii po ukončení hodnotenia testov hodnotiteľmi a po ukončení štatistického spracovania výsledkov. 

PET bude po uvedení do prevádzky Release 2 podporovať aj „inteligentné“ efektívne hodnotenie odpovedí, t.j. bez zásahu hodnotiteľa (voliteľne) dokáže automaticky správne ohodnotiť odpovede bez diakritiky, alebo  vyhodnotiť odpoveď v rámci definovaného rozsahu (autor úlohy pri jej tvorbe nastaví, že daná úloha môže byť týmto spôsobom automaticky vyhodnocovaná, lebo napr. v odpovedi nezáleží na správnej diakritike, výsledok „čižmička“ bude vyhodnotený rovnako správne ako „cyzmycka“). Odpovede, ktoré PET označí za správne ale s menšou ako 100% úrovňou pravdepodobnosti pôjdu na review ľudskému hodnotiteľovi. Cieľom je hodnotenie zrýchliť a zefektívniť – hodnotiteľ (človek) následne bude iba kontrolovať správnosť automatického vyhodnotenia. Tento PET bude následne rozširovaný prostredníctvom zmenových konaní na základe skúseností z používania. 

Zároveň PET rozšíri kľúč správnych odpovedí aj o odpovede, ktoré hodnotitelia pri hodnotení úlohy v rámci predchádzajúceho testovania označili ako správne. 

4.1.2.6 Hodnotenie testu

Hodnotenie testu pozostáva z automatizovaného hodnotenia (uzavreté úlohy a otvorené úlohy voči existujúcemu kľúču) a z hodnotenia otvorených odpovedí hodnotiteľmi. Aby bola zabezpečená transparentnosť procesu hodnotenia, hodnotenie slovných odpovedí hodnotiteľmi prebieha v dvoch úrovniach. Na prvej úrovni hodnotia jednotlivé odpovede nezávisle na sebe dvaja primárni hodnotitelia. Po ukončení hodnotenia zo strany primárnych hodnotiteľov nasleduje druhá úroveň hodnotenia. Toto hodnotenie vykonáva hlavný hodnotiteľ, pričom PET prehľadne (farebne) zvýrazní, v ktorých hodnoteniach sa prví dvaja hodnotitelia nezhodovali, a v ktorých áno, odlíši (farebne) správne a nesprávne vyhodnotené odpovede. Hlavný hodnotiteľ reviduje a posudzuje hodnotenia z prvej úrovne a k jednotlivým odpovediam dáva oficiálne hodnotenie, ktoré bude následne publikované ako hodnotenie odpovedí jednotlivých testov a doplní tak automaticky vyhodnotené odpovede, aby mohol byť predmetný test kompletne vyhodnotený.  

Súčasťou aplikácie a modulu hodnotenia bude aj nástroj na definovanie stupnice hodnotenia. Počas hodnotenia majú hodnotitelia možnosť rozšíriť hodnotiaci kľúč.  

                                                                                                       Obrázok 3 Aplikačná vrstva architektúry

4.1.3 Prehľad koncových služieb – budúci stav:

4.1.4 Organizačné zmeny a Procesy dotknuté navrhovaným riešením

V rámci projektu nebude realizovaný presun zodpovedností a služieb org. jednotiek, vytvorenie alebo zlúčenie organizačných jednotiek, zapojenie iných organizačných jednotiek, atď.

4.1.5 Jazyková podpora lokalizácia

Požiadavky na jazykovú lokalizáciu riešenia a používateľské prostredie bude implementované v slovenskom, a v jazyku národnostných menšín.

4.2 Aplikačná vrstva

Predpokladá sa využitie SaaS služby ako nosnej časti informačného systému.

SaaS nástroje pre realizáciu elektronického testovania dnes poskytujú pomerne ucelené riešenia a dávajú možnosť výberu. Na druhej strane očakávame, že nie všetky funkcie musia byť vo vhodnom nástroji pokryté ideálne.

Preto predpokladáme, že systém môže byť doplnený o ďalšie komponenty a služby, ktoré budú realizovať požiadavky, ktoré vybraný SaaS produkt nie je schopný efektívne realizovať. Príkladom sú špecifické integrácie, nástroj typu BI a ďalšie.

Požaduje sa, aby návrh riešenia v rámci ponuky obsahoval popis aplikačnej architektúry so zdôraznením, aké funkcie dodáva SaaS služba a aké prípadné ďalšie komponenty a prečo.

4.2.1 Návrh riešenia v aplikačnej vrstve architektúry

4.2.1.1 Portál

Portál predstavuje jediné centrálne rozhranie pre používateľov informačného systému a sú cez neho dostupné všetky funkcionality informačného systému. 

4.2.1.2        Správa používateľov

Správa používateľov bude spravovať účty používateľov z radov žiakov a študentov, zamestnancov škôl (učitelia, koordinátori a IT administrátori) a zamestnancov realizátora e-Testovania (NIVaM), prípadne iných oprávnených osôb v súvislosti s prevádzkou PET a realizáciou elektronického testovania. Bude umožňovať: 

• služby evidencie používateľov, 
• identifikácie a autentifikácie prostredníctvom štandardných protokolov, 
• hromadný import a export používateľov a hromadné aj čiastkové zmeny ich údajov, 
• integráciu na externého providera / SSO / federácia s iným autentifikačným serverom (napr. Facebook, Google, Apple, Microsoft), 
• dvojfaktorovú autentifikáciu, minimálne štandardné OTP 2FA autentifikačné aplikácie

(Authy, Microsoft Authenticator, LastPass, alebo ekvivalent), 

• funkcionalitu na komplexnú správu používateľských identít, 
• funkcionalitu na riadenie prístupových práv k dátam a službám informačného systému. 

Integrácia na IAM UPVS ani rezortné systémy sa v rámci dodávky nebude realizovať. V rámci rozvoja je zamýšľaná integrácia, ktorá umožní čo synchronizáciu údajov o školách, žiakoch a učiteľoch s minimálnou mierou manuálnej práce.

4.2.1.3 Správa úloh, testov

V rámci správy úloh sa tvoria, klasifikujú, pilotujú a schvaľujú jednotlivé úlohy pred zaradením medzi ostré úlohy.  

Nástroj na tvorbu úloh umožní centrálny vývoj úloh – to znamená, že všetci používatelia – autori, recenzenti, hodnotitelia, atď. budú pracovať na jednej centrálnej databáze úloh. Prístupy používateľov do aplikácie a k dátam budú jednoznačne dané rolami a oprávneniami. Nástroj umožní tvorbu rôznych typov úloh. 

Typy aktuálne využívaných testových úloh: 

• Otvorené: 
  • s tvorbou krátkej odpovede – doplňovanie textu, čísla, 
  • s tvorbou dlhej odpovede (napr. eseje). 
• Uzavreté: 
  • výber z viacerých možností – jedna správna odpoveď,
  • výber z viacerých možností – viac správnych odpovedí,
  • binárne (dichotomické), pravda, nepravda,
  • priraďovacie – prepojenia dvoch zoznamov, dvoch tvrdení, dvoch obrázkov,
  • zoraďovacie – zoradenie podľa vhodnosti, dôležitosti,
  • s označením odpovede v texte alebo obrázku,
  • s odovzdaním riešenia v súbore (ako príloha k odpovedi), 
  • typ sore finger – výber z viacerých možností, kde napr. slovo nezapadá do kontextu,
  • drag and drop – uchopenie a premiestnenie objektu (textového, obrázku) na správne,
  • identifikácia objektu alebo pozície,
  • Matica: 
    • single matrix (jedna správna odpoveď v riadku), 
    • multiple matrix (viac správnych odpovedí v riadku). 

Nástroj umožní: 

• • realizovať otázky založené na vypočutí nahrávky (audio/video nahrávky): PET bude mať zabudovaný vlastný prehrávač nahrávok – cieľom je, aby bolo možné nastaviť, že žiak nemôže zastaviť, resp. prehrať, resp. spustiť viacnásobne nahrávku (umožní vykonávať iba povolené činnosti), 
  • manipuláciu s obrázkami, objektami – podpora animácií, napr. simulácia telesa v pohyb,  o vytvárať interaktívne úlohy (tento typ úloh využíva napr. testovanie PISA - PISA (oecd.org), príklad úlohy),
  • využitie formátu na chatovanie – simulácia  chatovania: 

https://www.oecd.org/pisa/test/CPS-Xandar-scoring-guide.pdf,

• • využitie grafických nástrojov (open source) na rysovanie a grafické zobrazovania objektov pre tvorcov úloh (napr. GeoGebra),
  • Úlohy na priestorovú predstavivosť v matematickej gramotnosti:

https://www.geogebra.org/m/h5rHMprZ#material/CZrMVQ3t .

PET musí byť navrhnutý tak, aby bolo možné typy úloh v budúcnosti rozšíriť v rámci príslušných štandardov podľa potrieb pedagogických pracovníkov, zodpovedajúcich za tvorbu testov a úloh. 

4.2.1.4     Zabezpečenie pracovnej stanice

Certifikačné testy sa majú vykonávať v prípade :

• aktívnej kontroly pracovnej stanice na zabezpečenej pracovnej stanici s kontrolovaným alebo monitorovaným prístupom k systémovým funkciám (napr. menu Štart, panel úloh, prepínanie/spustenie/ukončenie úloh/okien/aplikácií, tlač, vybrané klávesové skratky,  zamknutie obrazovky, zmena používateľa, odhlásenie, zmena hesla, vypnutie, reštartovanie, pravé tlačidlo myši, atď.), ktorá neumožňuje nekontrolované používanie neoprávnených zdrojov (napr. internetových stránok, okien/aplikácií, súborov atď.), počas realizácie testu. Pracovná stanica má byť zabezpečená systémovo, nie manuálne administrátorom školy na každej pracovnej stanici. Kontrola prístupu má byť konfigurovateľná (napríklad technológia SAFE EXAM BROWSER).
• pasívnej kontroly pracovnej stanice (iba monitorovanie z prehliadača) na bežnej pracovnej stanici s pripojením na internet, aktualizovaným operačným systémom a internetovým prehliadačom, pričom o incidentoch (napr. prepnutie mimo testovacie okno) musí byť dostupný záznam s presným časovým vymedzením. Test musí byť po každom incidente zastavený s  vyžiadaním prítomnosti dozoru.

4.2.1.5     Testovanie

Od informačného systému sa požaduje bezpečné testovanie cez sieťové pripojenie, ktoré nebude možné napadnúť a prípadne modifikovať.  

PET musí byť odolný voči krátkodobým výpadkom (max niekoľko minút) pripojenia k počítačovej sieti. V prípade opätovného pripojenia sa, musí byť zabezpečená možnosť pokračovať v rozpracovanom teste od bodu, v ktorom došlo k prerušeniu. Požaduje sa tiež možnosť nahrania najbližších úloh (minimálne 3) do vyrovnávacej pamäte prehliadača a pokračovať v teste týmito úlohami aj počas krátkodobého výpadku.

Pozn. Rozlišujeme pripojenie k počítačovej sieti a pripojenie na internet. Školy majú pripojenie na internet, avšak existujú medzi nimi veľké rozdiely v kvalite pripojenia a šírke pásma. Internet v školách je často zdieľaný pre celú školu a nedá sa vyhradiť len na účely e-testovania. 

Testovanie bude realizované cez portál, pomocou webového prehliadača v počítači, notebooku alebo mobilnom zariadení. Prezentácia testu má byť čo najviac zhodná vo všetkých formách a obsahovo musí byť ekvivalentná.

4.2.1.6     Zabezpečenie proti podvodom

Dôležitou požiadavkou je: vyriešenie autentifikácie žiaka, obmedzenie možností žiaka podvádzať, zabezpečiť alebo monitorovať prostriedkami prehliadača alebo operačného systému, že žiak pracuje samostatne a nepoužíva nepovolené aplikácie alebo nepracuje s inými zdrojmi informácií. V návrhu riešenia v rámci ponuky bude vysvetlené, akým spôsobom budú tieto problémy adresované tak, aby ich bolo možné účinne eliminovať alebo monitorovať na centrálnej úrovni a na úrovni školy či triedy.

4.2.1.7     Podpora žiakov so znevýhodnením

Riešenie musí zabezpečiť podporu inklúzie znevýhodnených skupín a umožňovať základnú podporu pre realizáciu testov pre žiakov zdravotne postihnutých, pre žiakov s poruchami pozornosti, pre žiakov so sluchovým znevýhodnením a žiakov so zrakovým znevýhodnením.

4.2.2 Rozsah informačných systémov – TO BE

4.2.3 Prehľad plánovaného využívania iných ISVS (integrácie) – TO BE

Tabuľka 5 Prehľad plánovaných integrácií na iné ISVS  – budúci stav (TO BE)

4.2.4 Aplikačné služby pre realizáciu koncových služieb – TO BE

Tabuľka 6 Aplikačné služby pre Koncové služby – budúci stav (TO BE)

4.3Dátová vrstva

Navrhovaná dátová architektúra vychádza z cieľa podporiť biznis procesy testovania. Z používateľského pohľadu ostáva portál jediným vstupným bodom pre žiakov, učiteľov, školských administrátorov a pracovníkov realizátora; vnútri systému sa však funkcie zoskupujú do jasných domén: správa referenčných a identitných údajov, tvorba obsahu (úlohy a testy), plánovanie a realizácia testovania, hodnotenie, dotazníky, analytika a integrácie.

4.3.1Údaje v správe organizácie

4.3.2Dátový rozsah projektu - Prehľad objektov evidencie - TO BE

4.3.3 Referenčné údaje

Predmetom projektu nie je vyhlásenie objektov evidencie za referenčné.

4.3.4 Roly a predbežné personálne zabezpečenie pri riadení dátovej kvality

4.3.5 Otvorené údaje

4.3.6 Prehľad jednotlivých kategórií údajov

4.4Technologická vrstva

Vzhľadom na SaaS podstatu riešenie nie je detailný popis technologickej vrstvy relevantný. Popis sa bude orientovať na opis požadovaných vonkajších charakteristík technologickej vrstvy.

4.4.1Návrh riešenia technologickej architektúry

Informačný systém bude dodaný ako SaaS v cloude. Na strane škôl ani ministerstva sa nebuduje „tučný klient“ ani lokálna infraštruktúra testovania; žiak pracuje výlučne v internetovom prehliadači (príp. v zabezpečenom prehliadači typu SEB). Prevádzka, bezpečnosť, škálovanie a modernizácia infraštruktúry sú zodpovednosťou poskytovateľa služby. MŠVVaM SR definuje parametre výkonu, dostupnosti a bezpečnosti, monitoruje plnenie a riadi integrácie a exporty. Stanovené parametre definujú minimálne zaťaženie, na ktoré musí infraštruktúra škálovať:

• Národné testovanie: 45 000 súbežných používateľov s burst prihlasovaním v 5 sekundách (≈ 9 000 login operácií/s), a zobrazovanie ďalšej úlohy do 5 s pre 45 000 relácií. Pri modelovej veľkosti položky 10 kB to znamená ~450 MB / 5 s ≈ 90 MB/s ≈ 720 Mbit/s čistej dátovej priepustnosti len na stream položiek (mimo TLS/HTTP overheadu). Perimeter (CDN + edge) musí mať rezervu >1 Gbit/s pre certifikačné okná.
• Bežná prevádzka (necertifikačné): 3 000 súbežných používateľov → ~30 MB / 5 s ≈ 6 MB/s ≈ 48 Mbit/s.
• Externé portály: 3 000 súbežných konzumentov výsledkov (čítacie dopyty, cache-ovateľné).
• Backoffice: cca 100 používateľov (tvorba úloh, štatistiky, administrácia).

Z uvedeného vyplývajú hardvérové profilácie v SaaS:

• Edge/CDN: globálna priepustnosť >1–2 Gbit/s s TLS offloadom, WAF s min. 10k RPS pravidlami a autoscale na burst 9k RPS pri prihlasovaní.
• Aplikačná vrstva: horizontálne škálovanie na >10k RPS pre autentizačné toky a niekoľko tisíc RPS pre API testovacieho enginu; limity sa merajú p95/p99 latenciou <1 s pre „ďalšiu úlohu“, aby sa aj s rezervou siete splnila hranica 5 s koncového zobrazenia.
• Cache: klaster s desiatkami GB RAM (sessions, renderované položky, číselníky) a throughput v stovkách tisíc operácií/s, aby sa DB odbremenila od „hot“ čítaní počas kampaní.
• DB: vysoko-dostupný klaster (primár + min. 2 repliky), partície/shardy podľa kampane/testu; write-ahead log optimalizovaný na krátke transakcie (uloženie odpovede), cieľ p95 zápisu <50–100 ms.
• Objektové úložisko: škálovateľné na stovky MB/s pre čítanie počas špičky (multimédiá, PDF), s CDN predným cachom; ER (expedited recovery) pre náhodné zmazania počas skúšok.
• Fronty/streamy: kapacita na tisíce eventov/s so spracovaním v hlbokej špičke (back-pressure bez straty), aby automatické vyhodnotenie bežalo v reálnom čase.

Na školách netreba žiadny špeciálny HW mimo bežných počítačov/notebookov/tabletov so zabezpečeným prehliadačom a stabilným pripojením. Indikatívne kapacity linky: trieda s 30 žiakmi a položkou 10 kB každých 5 s generuje približne 60 kB/s ≈ 480 kbit/s čisto na položky; s režijnými dátami a rezervou je potrebné počítať ~2–5 Mbit/s na triedu. V praxi väčšiu záťaž predstavuje burst prihlasovania, preto je vhodné časovo „rozplánovať“ štarty medzi triedami alebo použiť lokálne cache-ovanie statických komponentov cez CDN.

V rámci rezortu školstva sú realizované investície do digitálneho vybavenia a infraštruktúry na školách (C7-7: Zvýšiť percentuálny podiel škôl s plným vstupným digitálnym vybavením), ktorých hlavným cieľom je zvýšenie percentuálneho podielu škôl s plným vstupným digitálnym vybavením z 30 % na aspoň 90 %. Toto významné skvalitnenie pokrytia škôl komplexnou digitálnou infraštruktúrou otvára nové možností využitia, najmä v oblasti vzdialeného prístupu k centralizovaným riešeniam a rýchlej interakcii.

SaaS poskytovateľ dodá izolované PROD so škálovaním na kampane (certifikačné termíny) a UAT/TEST pre overenie obsahov a integrácií. MŠVVaM SR potrebuje len sieťové prepojenie na integračné kanály (napr. SFTP/VPN pre exporty) a SLA reporty. Zálohy (snapshoty DB a objektov) sa vykonávajú automaticky s testovanou obnovou.

4.4.2 Požiadavky na výkonnostné parametre, kapacitné požiadavky – TO BE

Predbežne sú predpokladané nasledovný kapacitné požiadavky:

• Predpokladaný počet súčasných používateľov (tzv. concurrent users) pri národnom testovaní – 45 000 používateľov prihlasujúcich sa naraz v priebehu 5 sekúnd, pričom zároveň musí byť zabezpečená funkcionalita pre administrátorov testovania. 5 sekúnd na zobrazenie ďalšej úlohy s veľkosťou do 10kB (okrem zdržania siete) počas certifikačného testovania pre 45 000 testovacích relácií. Celkový počet testovaných v jednom termíne sa bude v čase postupne zvyšovať, pričom prvé dva roky dosiahne maximálne 30000.
• Predpokladaný počet súčasných používateľov (tzv. concurrent users) bežná denná prevádzka pre necertifikačné testovanie – 3000 používateľov prihlasujúcich sa naraz v priebehu 3 sekúnd. 5 sekúnd na zobrazenie ďalšej úlohy s veľkosťou do 10kB (okrem zdržania siete) počas necertifikačného testovania pre 3000 testovacích relácií.
• Predpokladaný počet súčasných používateľov (tzv. concurrent users) pre bežnú prevádzku na externých portáloch (prezeranie výsledkov študentami, revízia realizovaných testov) min. 3 000 používateľov.
• Predpokladaný počet súčasných používateľov (tzv. concurrent users) pre backoffice aktivity (príprava úloh a testov, štatistické spracovanie, administrácia testovaní) 100 používateľov.

4.4.3 Návrh riešenia technologickej architektúry

Informačný systém bude dodaný ako SaaS v cloude. Na strane škôl ani ministerstva sa nebuduje „tučný klient“ ani lokálna infraštruktúra testovania; žiak pracuje výlučne v internetovom prehliadači (príp. v zabezpečenom prehliadači typu SEB). Prevádzka, bezpečnosť, škálovanie a modernizácia infraštruktúry sú zodpovednosťou poskytovateľa služby. MŠVVaM SR definuje parametre výkonu, dostupnosti a bezpečnosti, monitoruje plnenie a riadi integrácie a exporty. Stanovené parametre definujú minimálne zaťaženie, na ktoré musí infraštruktúra škálovať:

• Národné testovanie: 45 000 súbežných používateľov s burst prihlasovaním v 5 sekundách (≈ 9 000 login operácií/s), a zobrazovanie ďalšej úlohy do 5 s pre 45 000 relácií. Pri modelovej veľkosti položky 10 kB to znamená ~450 MB / 5 s ≈ 90 MB/s ≈ 720 Mbit/s čistej dátovej priepustnosti len na stream položiek (mimo TLS/HTTP overheadu). Perimeter (CDN + edge) musí mať rezervu >1 Gbit/s pre certifikačné okná.
• Bežná prevádzka (necertifikačné): 3 000 súbežných používateľov → ~30 MB / 5 s ≈ 6 MB/s ≈ 48 Mbit/s.
• Externé portály: 3 000 súbežných konzumentov výsledkov (čítacie dopyty, cache-ovateľné).
• Backoffice: cca 100 používateľov (tvorba úloh, štatistiky, administrácia).

Z uvedeného vyplývajú hardvérové profilácie v SaaS:

• Edge/CDN: globálna priepustnosť >1–2 Gbit/s s TLS offloadom, WAF s min. 10k RPS pravidlami a autoscale na burst 9k RPS pri prihlasovaní.
• Aplikačná vrstva: horizontálne škálovanie na >10k RPS pre autentizačné toky a niekoľko tisíc RPS pre API testovacieho enginu; limity sa merajú p95/p99 latenciou <1 s pre „ďalšiu úlohu“, aby sa aj s rezervou siete splnila hranica 5 s koncového zobrazenia.
• Cache: klaster s desiatkami GB RAM (sessions, renderované položky, číselníky) a throughput v stovkách tisíc operácií/s, aby sa DB odbremenila od „hot“ čítaní počas kampaní.
• DB: vysoko-dostupný klaster (primár + min. 2 repliky), partície/shardy podľa kampane/testu; write-ahead log optimalizovaný na krátke transakcie (uloženie odpovede), cieľ p95 zápisu <50–100 ms.
• Objektové úložisko: škálovateľné na stovky MB/s pre čítanie počas špičky (multimédiá, PDF), s CDN predným cachom; ER (expedited recovery) pre náhodné zmazania počas skúšok.
• Fronty/streamy: kapacita na tisíce eventov/s so spracovaním v hlbokej špičke (back-pressure bez straty), aby automatické vyhodnotenie bežalo v reálnom čase.

Na školách netreba žiadny špeciálny HW mimo bežných počítačov/notebookov/tabletov so zabezpečeným prehliadačom a stabilným pripojením. Indikatívne kapacity linky: trieda s 30 žiakmi a položkou 10 kB každých 5 s generuje približne 60 kB/s ≈ 480 kbit/s čisto na položky; s režijnými dátami a rezervou je potrebné počítať ~2–5 Mbit/s na triedu. V praxi väčšiu záťaž predstavuje burst prihlasovania, preto je vhodné časovo „rozplánovať“ štarty medzi triedami alebo použiť lokálne cache-ovanie statických komponentov cez CDN.

V rámci rezortu školstva sú realizované investície do digitálneho vybavenia a infraštruktúry na školách (C7-7: Zvýšiť percentuálny podiel škôl s plným vstupným digitálnym vybavením), ktorých hlavným cieľom je zvýšenie percentuálneho podielu škôl s plným vstupným digitálnym vybavením z 30 % na aspoň 90 %. Toto významné skvalitnenie pokrytia škôl komplexnou digitálnou infraštruktúrou otvára nové možností využitia, najmä v oblasti vzdialeného prístupu k centralizovaným riešeniam a rýchlej interakcii.

SaaS poskytovateľ dodá izolované PROD so škálovaním na kampane (certifikačné termíny) a UAT/TEST pre overenie obsahov a integrácií. MŠVVaM SR potrebuje len sieťové prepojenie na integračné kanály (napr.FTP/VPN pre exporty).  Zálohy (snapshoty DB a objektov) sa vykonávajú automaticky s testovanou obnovou.

4.4.4 Využívanie služieb z katalógu služieb vládneho cloudu

Realizácia projektu nevytvára požiadavky na využívanie služieb vládneho cloudu.

4.5 Bezpečnostná architektúra

Bezpečnostná architektúra bude zahŕňať minimálne nasledovné oblasti

• dodržiavanie pravidiel riadenia informačnej bezpečnosti (podľa zákona č. 69/2018 o  kybernetickej bezpečnosti a o zmene a doplnení niektorých zákonov a podľa zákona č. 95/2019 Z. z. o informačných technológiách vo verejnej správe a o zmene a doplnení niektorých zákonov), 
• monitorovanie bezpečnosti a incident management, 
• segmentácia siete, monitoring a ochrana sieťového spojenia, 
• šifrovanie komunikácie a dátových prenosov, 
• šifrovanie údajov v databáze,  
• možnosť využitia dvoj-faktorovej autentifikácie, 
• možnosť vygenerovať nové prístupové údaje v prípade, že ich používateľ zabudol – reset hesla (v prípade žiaka reset hesla vie zabezpečiť aj iná rola), 
• súlad s GDPR (súhlas so spracovaním osobných údajov, cookies).

V rámci bezpečnostnej architektúry budú zohľadnené nasledovné kritériá bezpečnosti: 

• stála dostupnosť a automatickú škálovateľnosť,
• autentizácia používateľov pristupujúcich k IS musí byť adekvátna spôsobu ich pripojenia a oprávnení používateľov na činnosti v sieti, 
• komunikácia bude zabezpečená šifrovaním s použitím adekvátnych a schválených kryptografických algoritmov.
• v rámci realizácie projektu bude potrebné z pohľadu bezpečnosti zabezpečiť najmä: 
• uplatnenie zásady „vendor diversity“ aktívnych bezpečnostných komponentov prepájajúcich školy so serverovou infraštruktúrou,
• samostatné testovanie bezpečnosti a bezpečnostných funkcií riešenia minimálne na úrovni OWASP WSTG v4.2, 
• používateľské akceptačné testy, 
• logovanie všetkých dôležitých aktivít, 
• prístup k jednotlivým testom a úlohám bude možný len v rámci špecifickej, pričom  bude možné zapnúť povinnú 2-faktorovú autentifikáciu

V rámci realizácie projektu bude potrebné z pohľadu bezpečnosti zabezpečiť najmä:

• samostatné testovanie bezpečnosti a bezpečnostných funkcií riešenia,
• anonymizáciu osobných dát a identít osôb pre účely testovania,
• logický a fyzický prístup k testovaciemu a vývojovému prostrediu,
• používateľské akceptačné testy,
• bezpečnú implementáciu kryptografických algoritmov, vrátane hash algoritmov použitých na autentifikačné účely,
• logovanie všetkých dôležitých aktivít,
• u vybraných záznamov z logovania zabezpečiť osobitné ukladanie a vyhľadávanie,
• nad vybranými citlivými úkonmi administrátorov a operátorov v systéme zabezpečiť viacfaktorovú autentifikáciu a autorizáciu týchto úkonov
• prístup k vybraným testom bude možný len v rámci špecifickej roly (a bude možné zapnúť povinnú viac faktorovú autentifikáciu). Samotné testy budú v aplikácii uložené v šifrovanej podobe.

5. Závislosti na ostatné ISVS / projekty

Počas najbližšieho obdobia nie sú známe závislosti na iné ISVS alebo projekty.

6. Zdrojové kódy

Predmetom obstarávanie je SaaS služba, ktorá môže byť zákaznícky prispôsobená. Pokiaľ bude predmetom úprav vývoj nových častí, špecificky pre potreby projektu, majú byť zdrojové kódy pre tieto časti dodané pod EUPL licenciou.

Zdrojový kód bude preferovane dodaný vo forme Git repozitára. Dodávateľ môže použiť vlastný verejný repozitár alebo centrálny repozitár MIRRI.

7. Prevádzka a údržba

Prevádzka SaaS cloudovej služby predpokladá model, kde dodávateľ a/alebo poskytovateľ cloudu dodáva jednak COTS softvér spravidla vrátane rozvoja, jednak prevádzkové služby, ktoré sú riadené plne na strane dodávateľa.

Predpokladá sa využitie systému pre hlásenie incidentov a zmien, poskytnutého dodávateľom.

Prevádzkovateľom informačného systému bude verejný obstarávateľ a ním poverený realizátor e-testovania, ktorý si podporu činností súvisiacich s prevádzkou a rozvojom PET v trvaní 60 mesiacov po nasadení do produkčnej prevádzky zabezpečí u úspešného uchádzača. Pričom skutočná doba prevádzky sa bude odvíjať od objednávky kumulatívneho predplatného na služby PET s minimálnou dobou trvania 12 mesiacov od zriadenia služby PET.

Cena za poskytnutie, prispôsobenie a prevádzku riešenia bude spojená s počtom zrealizovaných testov počas predom stanovenej jednotky času.

Úpravy, prispôsobenie komunikačného prostredia, ako aj potrebný rozvoj budú predmetom dielčích zadaní, pričom ich rozsah a prácnosť bude limitovaná celkovým počtom človekohodín .

7.1 Prevádzkové požiadavky

Predpokladá sa poskytnutie dodávateľom:

• call centra počas certifikačných a ďalších testovaní (L1)
• systému/služby pre evidovanie a prehľad stavu riešenia chybových hlásení a zmenových požiadaviek dodávateľom.

Úlohou call centra je poskytnúť riešenie jednoduchých a opakujúcich sa incidentov, zaznamenať incident do evidencie a posunúť na ďalšie spracovanie, pokiaľ call centrum incident nevie vyriešiť.

Ďalšie úrovne podpory sú vzhľadom na využitie služby SaaS v zodpovednosti dodávateľa.

7.1.1 Úrovne podpory používateľov

Help Desk je realizovaný cez 3 úrovne podpory, s nasledujúcim označením:

• L1 podpory IS (Level 1, priamy kontakt zákazníka) – zabezpečuje dodávateľ
• L2 podpory IS (Level 2, postúpenie požiadaviek od L1) - vybraná skupina garantov, so znalosťou IS (zabezpečuje dodávateľ).
• L3 podpory IS (Level 3, postúpenie požiadaviek od L2) - zabezpečuje dodávateľ.

Definície:

• Podpora L1 (podpora 1. stupňa) - začiatočná úroveň podpory, ktorá je zodpovedná za riešenie základných problémov a požiadaviek koncových užívateľov a ďalšie služby vyžadujúce základnú úroveň technickej podpory. Základnou funkciou podpory 1. stupňa je zhromaždiť informácie, previesť základnú analýzu a určiť príčinu problému a jeho klasifikáciu. Typicky sú v úrovni L1 riešené priamočiare a jednoduché problémy a základné diagnostiky, overenie dostupnosti jednotlivých vrstiev infraštruktúry (sieťové, operačné, vizualizačné, aplikačné atď.) a základné užívateľské problémy (typicky zabudnutie hesla), overovanie nastavení SW a HW atď.
• Podpora L2 (podpora 2. stupňa) – riešiteľské tímy s hlbšou technologickou znalosťou danej oblasti. Riešitelia na úrovni Podpory L2 nekomunikujú priamo s koncovým užívateľom, ale sú zodpovední za poskytovanie súčinnosti riešiteľom 1. úrovne podpory pri riešení eskalovaného hlásenia, čo mimo iného obsahuje aj spätnú kontrolu a podrobnejšiu analýzu zistených dát predaných riešiteľom 1. úrovne podpory. Výstupom takejto kontroly môže byť potvrdenie, upresnenie, alebo prehodnotenie hlásenia v závislosti na potrebách Objednávateľa. Primárnym cieľom riešiteľov na úrovni Podpory L2 je dostať Hlásenie čo najskôr pod kontrolu a následne ho vyriešiť - s možnosťou eskalácie na vyššiu úroveň podpory – Podpora L3.
• Podpora L3 (podpora 3. stupňa) - Podpora 3. stupňa predstavuje najvyššiu úroveň podpory pre riešenie tých najobťažnejších Hlásení, vrátane prevádzania hĺbkových analýz a riešenie extrémnych prípadov.

Pre služby sú definované takéto SLA:

• Riešenie poruchy Po – Pia 9:00 - 17:00
• Manažment a správa PROD prostredia 9:00 - 17:00

7.2 Požadovaná dostupnosť IS:

Prevádzka PET bude zahŕňať zabezpečenie definovaných prevádzkových parametrov uchádzačom pre jednotlivé typy testovaní a bežnú prevádzku, riešenie vád a súvisiacich incidentov podľa definovaných parametrov uchádzačom.

Prevádzkové parametre sú definované v tabuľke nižšie, pričom sú sledované počas bežného pracovného dňa, t.j. pondelok - piatok od 9:00 do 17:00. Mimo tohto časového intervalu je možné servisné okno.

Do doby odozvy sa počíta kompletný čas od kliknutia užívateľom na ovládací prvok v prostredí PET. po načítanie ďalšej web stránky s kompletným obsahom a dátami. Dávkové úlohy, napr. generovanie zložitých reportov sa do „doby odozvy“ nezapočítavajú.

Požiadavky na služby podpory prevádzky a údržby PET zahŕňajú najmä činnosti na zabezpečenie servisnej podpory počas bežnej prevádzky a počas silnej prevádzky (certifikačné testovanie) – Call centrum, platformu pre evidovanie a prehľad stavu riešenia chybových hlásení a zmenových požiadaviek (taskov), poskytovanie podpory pre zaistenie spoľahlivej, kontinuálnej a bezpečnej prevádzky v súlade s prevádzkovou dokumentáciou na vopred definované obdobie. Zároveň počas tohto obdobia bude prebiehať aj ďalší rozvoj systému vo vopred definovanom rozsahu.

Prevádzkované budú nasledovné prostredia:

• produkčné prostredie
• testovacie prostredie
• demo prostredie

Uvedené SLA parametre sú platné pre produkčné prostredie.

V nasledujúcej tabuľke je uvedený rámcový časový zoznam všetkých testovaní a súvisiacich prípravných a hodnotiacich procesov počas jedného školského roka. Tieto testovania ovplyvňujú prevádzkové parametre PET, primárne požiadavky na parametre riešenia incidentov, RPO a RTO. Okrem toho musí v tomto rámcovo definovanom čase počas vyučovacích hodín úspešný uchádzač zabezpečiť nepretržitú podporu pre realizáciu certifikačného testovania.

Prehľad plánovaných testovaní na 1 kalendárny rok

8. Požiadavky na personál

Vzhľadom na využitie služby SaaS je personálne zabezpečenie prevádzky v kompetencii dodávateľa. Na strane verejného obstarávateľa sa nepredpokladá personálna zmena.

Uchádzač v rámci ponuky dodá aj cenovú ponuku na:

• Školenia a školiace materiály pre tvorcov banky úloh a testov.
• Školenia a školiace materiály pre manažment používateľov a testovania.
• Školenia a školiace materiály pre hodnotiteľov.
• Školenia a školiace materiály pre spracovanie štatistík.
• Školiace materiály pre dozor – školský personál.

Rozsah školenia navrhne v návrhu riešenia v rámci ponuky uchádzač podľa skúseností z iných implementácií. Školenia budú organizované v  termínoch dohodnutých s verejným obstarávateľom. Školiace materiály bude možné publikovať na portáli obstarávaného systému.

9.Implementácia a preberanie výstupov projektu

V projekte bude vyžadované, v rámci procesu zriadenia služby PET, dodanie nasledovných manažérskych a špecializovaných produktov (dokumentácie) (uvádzame iba hlavné skupiny produktov). 

• Detailný návrh riešenia v rozsahu vhodnom pre formu služby SaaS
  • Stručný popis biznis architektúry.
  • Stručný popis aplikačnej architektúry s dôrazom na prípadné rozšírenia o ďalšie komponenty a služby.
  • Uchádzač môže použiť štandardnú dokumentáciu pre tie časti PET, ktoré budú prevzaté bezo zmeny zo služby SaaS.
  • Popis funkčností, špecifických pre projekt.
  • Dizajn obrazoviek (wireframe) a UX prvkov, špecifických pre projekt.
  • Testovacie scenáre.
• Špecifikácia potrebných cloudových služieb.
• Popis zálohovania a obnovy produkčného prostredia.
• Nástroj a popis riešenia incidentov a zmien.
• Dodávka licencií (ak relevantné).
• Výsledky záťažových a zrealizovaných funkčných testov.
• Používateľská dokumentácia vrátane rolí pre správu systému zo strany realizátora testovania.
• Školiace materiály pre relevantné roly.

PET bude odovzdaný formou poskytnutia prístupov k SaaS riešeniu na dohodnutú dobu verejnému obstarávateľovi a ním poverenému realizátorovi e-testovania.

Verejný obstarávateľ získa majetkové práva k zdrojovým kódom podľa EUPL pre časti, ktoré budú preňho špecificky vyvinuté. Súčasťou zdrojových kódov budú aj komentáre, technická dokumentácia a spôsob kompilácie a/alebo zostavenia príslušných komponentov z kódu. V prípade dodávky celého produktu ako otvoreného software, je požadovaná aj dokumentácia pre zostavenie, inštaláciu a prevádzku.

Časti riešenia a dokumentáciu, ktoré sú distribuované ako bežne distribuovaný OSS, postačuje deklarovať s uvedením licencie a zdroja. Ako zdroj odporúčame použiť repozitár napr. Github.

Pri uvedení PET do prevádzky bude vystavený akceptačný protokol, ktorý v zmysle katalógu požiadaviek bude sumarizovať dodané riešenie alebo jeho časti, vrátane výsledkov prevádzkových a výkonnostných testov.

10.Prílohy