PRÍSTUP K PROJEKTU

(Verzia dokumentu v1.01/07_2021)

Identifikovanie požiadaviek na technickú časť riešenia

Identifikácia projektu

Schvaľovanie dokumentu

OBSAH

1. POPIS ZMIEN DOKUMENTU.. 3

1.1         História zmien. 3

1. ÚČEL DOKUMENTU.. 4

2.1         Konvencie používané v dokumentoch – označovanie požiadaviek. 4

1. POPIS NAVRHOVANÉHO RIEŠENIA. 4
2. ARCHITEKTÚRA RIEŠENIA PROJEKTU.. 4

4.1         Biznis vrstva. 5

4.2         Aplikačná vrstva. 7

4.2.1      Rozsah informačných systémov. 7

4.2.2      Využívanie nadrezortných centrálnych blokov a podporných spoločných blokov (SaaS). 9

4.2.3      Prehľad plánovaného využívania podporných spoločných blokov (SaaS). 10

4.2.4      Prehľad plánovaných integrácií ISVS na nadrezortné centrálne bloky – spoločné moduly. 10

4.2.5      Prehľad plánovaných integrácií ISVS na nadrezortné centrálne bloky - modul procesnej integrácie a integrácie údajov  (IS CSRÚ). 10

4.2.6      Poskytovanie údajov z ISVS do IS CSRÚ.. 10

4.2.7      Konzumovanie údajov z IS CSRU.. 11

4.3         Dátova vrstva. 12

4.3.1      Údaje v správe organizácie. 12

4.3.2      Dátový rozsah projektu. 12

4.3.3      Kvalita a čistenie údajov. 13

4.4         Referenčné údaje. 14

4.4.1      Objekty evidencie z pohľadu procesu ich vyhlásenia za referenčné. 14

4.4.2      Identifikácia údajov pre konzumovanie alebo poskytovanie údajov  do/z CSRU.. 15

4.5         Otvorené údaje. 15

4.6         Analytické údaje. 15

4.7         Moje údaje. 16

4.8         Prehľad jednotlivých kategórií údajov. 16

4.9         Technologická vrstva. 17

4.9.1      Prehľad technologického stavu. 17

4.9.2      Požiadavky na výkonnostné parametre, kapacitné požiadavky. 17

4.9.3      Návrh riešenia technologickej architektúry. 17

4.9.4      Využívanie služieb z katalógu  služieb vládneho cloudu. 18

4.9.5      Jazyková lokalizácia. 18

4.10       Bezpečnostná architektúra. 18

1. ZÁVISLOSTI NA OSTATNÉ ISVS / PROJEKTY. 20
2. ZDROJOVÉ KÓDY. 20
3. PREVÁDZKA A ÚDRŽBA.. 20

7.1         Prevádzkové požiadavky. 20

7.1.1      Úrovne podpory používateľov: 20

7.2         Požadovaná dostupnosť IS: 22

7.2.1      Dostupnosť (Availability). 23

7.2.2      RTO (Recovery Time Objective). 23

7.2.3      RPO (Recovery Point Objective). 23

1. POŽIADAVKY NA PERSONÁL. 24
2. IMPLEMENTÁCIA A PREBERANIE VÝSTUPOV PROJEKTU. 24
3. PRÍLOHY. 24

1.     POPIS ZMIEN DOKUMENTU

1.1         História zmien

Šedý text v celom dokumente predstavuje nápovedu pre vyplnenie dokumentu, po vyplnení kapitol odporúčame text šedou farbou vymazať.

Zelenou farbou je nápoveda pre prípravnú fázu projektu (ešte nečerpáte rozpočet) a modrou farbou pre iniciačnú fázu projektu ,rovnako ako v prípade šedého textu odporúčame po vyplnení mazať.

Pre prípravnú fázu, prosím ukladajte dokumenty s prefixom P_XX (podľa vyhlášky) a pre iniciačnú fázu s prefixom I_XX.

Finálna, schválená verzia dokumentácia z predošlej fázy musí byť na karte dokumentov v MetaIS uložená s koncovkou _FIN.

Poznámka: Odporúčame aby ste si VŠETKY TABUĽKOVÉ VSTUPY evidovali a spravovali v jednom centrálnom EXCELI – s cieľom minimalizovať budúcu prácnosť s aktualizáciou a udržiavaním obsahu.

Nápoveda inštrukcie k vypĺňaniu dokumentu  PRÍSTUP K PROJEKTU:

• Text uvedený „zelenou farbou“ vypĺňate v PRÍPRAVNEJ FÁZE projektu
  • j. ešte pred akýmkoľvek schvaľovaním a odsúhlasovaním vášho projektového zámeru vo vedení úradu (OVM) alebo u vašej autority, ktorá je zodpovedná za rozpočet
  • v tejto fáze ešte nečerpáte rozpočet
• Text uvedený „modrou farbou“ vypĺňate v INICIAČNEJ FÁZE projektu
  • j. už po úvodnom odsúhlasení vedením organizácie pokračujete v zdetailizovaní vášho Prístupu k projektu
  • v tejto fáze začínate alokovať pracovníkov na špecializovaných útvaroch – z dôvodu dopĺňania úvodných vstupov

VZORY a ŠABLONY zdrojových súborov sú tu: https://www.mirri.gov.sk/sekcie/informatizacia/riadenie-kvality-qa/riadenie-kvality-qa/index.html.

2.     ÚČEL DOKUMENTU

Doplniť vstupy v PRÍPRAVNEJ FÁZE:

• V súlade s Vyhláškou 85/2020 Z.z. o riadení projektov - je dokument Prístup k projektu pre prípravnú fázu určený na rozpracovanie informácií k projektu z pohľadu aktuálneho stavu, aby bolo možné rozhodnúť o pokračovaní prípravy projektu, alokovaní rozpočtu, ľudských zdrojov a prechode do iniciačnej fázy.

Doplniť vstupy v INICIAČNEJ FÁZE:

• V súlade s Vyhláškou 85/2020 Z.z. o riadení projektov - je dokument Prístup k projektu pre iniciačnú fázu určený na rozpracovanie detailných informácií prípravy projektu z pohľadu budúceho stavu a navrhovaného riešenia.

Dokument Prístup k projektu v zmysle vyššie uvedenej vyhlášky má o.i popisovať riešenie projektu v oblastiach:

1. Požiadaviek na architektúru riešenia – biznis vrstva, aplikačná vrstva, technologická vrstva, ...
2. Požiadaviek na dátový model, dátové konverzie a migrácie
3. Požiadaviek na vládny cloud, prípadne zdôvodnenie jeho použitia
4. Kapacitných požiadaviek na HW, SW a licencie
5. Požiadaviek na bezpečnosť riešenia
6. Požiadaviek na testovanie a akceptačné kritéria
7. Požiadaviek na prevádzku, výkonnosť, dostupnosť a zálohovanie
8. Požiadaviek na integrácie, rozhrania a spoločné komponenty
9. Požiadaviek na dokumentáciu a školenia.

Všetky požiadavky uvedené v Prístupe k projektu v príslušných kapitolách, musia byť v súlade s funkčnými, nefunkčnými a technickými požiadavkami uvedenými v Katalógu požiadaviek (  - I-02 BC/CBA, karta: Katalóg požiadaviek).

2.1         Konvencie používané v dokumentoch – označovanie požiadaviek

Zvoľte si konvenciu pre označovanie požiadaviek, súborov, atd.

Architektúrne požiadavky používajú konvenciu:

Napr.

A_AB_Oxx

• A – architektúrna požiadavka
• AB – označenie systému  (ak existuje členenie; môže byť vypustené)
• O – označenie požiadavky
• xx – číslo požiadavky

Infraštruktúrne požiadavky používajú konvenciu:

Napr.

IP_nn_ORxx

• IP – infraštruktúrna požiadavka
• nn – identifikácia  (ak existuje členenie; môže byť vypustené)
• O – označenie požiadavky
• xx – číslo požiadavky

Komunikačné požiadavky používajú konvenciu: ...

Bezpečnostné požiadavky používajú konvenciu: ...

Požiadavky na dodávateľa používajú konvenciu: ...

Prevádzkové požiadavky používajú konvenciu: ...

Ostatné technické požiadavky používajú konvenciu: ...

3.     POPIS NAVRHOVANÉHO RIEŠENIA

Opis navrhovaného riešenia sa spracováva až po definovaní vybranej alternatívy riešenia, t.j. v iniciačnej fáze projektu (Popis vybraného riešenia – popis TO BE stavu - na základe výsledkov MCA z dokumentu Projektový zámer).

Obsahom tejto kapitoly je manažérsky sumár navrhovaného riešenia z pohľadu architektúry.

4.     ARCHITEKTÚRA RIEŠENIA PROJEKTU

V tejto kapitole detailne rozpracujte  kapitolu 5 Náhľad architektúry z dokumentu I_01 Projektový zámer.

Spracovanie a rozsah tejto kapitoly závisí od typu projektu – budovanie ISVS, rozvoj ISVS, migrácia do vládneho cloudu, nákup HW atď.  Napríklad pri budovaní/rozvoji ISVS navrhujete všetky vrstvy architektúry (biznis, aplikačná, technologická), pri nákupe HW nie je potrebné popisovať biznis a aplikačnú vrstvu architektúry, postačuje v príslušných kapitolách uviesť Nerelevantné a zdôvodnenie a pod.

Architektúra navrhovaného riešenia projektu musí byť v súlade s funkčnými, nefunkčnými a technickými požiadavkami definovanými v katalógu požiadaviek (I-02 BC/CBA, karta: Katalóg požiadaviek).

V prípravnej fáze projektu popíšte súčasný (ďalej AS IS) stav architektúry aj s príslušným architektonickým modelom.

V iniciačnej fáze projektu popíšte budúci (ďalej TO BE)  stav architektúry riešenia aj s príslušným architektonickým modelom.

AS IS architektúra a TO BE architektúra musia byť spracované tak, aby bol zreteľný výsledok projektu (zmena).

Vyžadujeme, aby návrh architektúry bol zakreslený pomocou modelovacieho jazyka Archimate minimálne vo verzii 3 (link na špecifikáciu: https://www.opengroup.org/archimate-forum/archimate-overview). Pre modelovanie a popis AS IS aj TO BE architektúry odporúčame použiť modelovací nástroj, ktorý podporuje export modelu do štandardizovaného formátu „The Open Group ArchiMate Model Exchange File Format  Standard“. V návrhu zohľadnite usmernenia z používateľskej príručky centrálneho metainformačného systému verejnej správy (aktuálna verzia je zverejnená na: https://metais.vicepremier.gov.sk/help) pre popis, modelovanie a zápis informácií o komponentoch do metainformačného systému verejnej správy (ďalej MetaIS). Pre detailnejší popis procesov, ktorých sa projekt týka je možné použiť tiež modelovací jazyk BPMN (ISO 19510). Pre detailnejší návrh riešenia v aplikačnej vrstve je možné použiť aj jazyk UML (ISO 19505).

Modely môžu obsahovať viac náhľadov na riešenú oblasť tak, aby dostatočne zrozumiteľne popisovali eGov komponenty, ktoré majú byť predmetom riešenia, ako aj ich vzťahy a závislosti navzájom a vzťahy na ostatné komponenty eGov (napr. spoločné moduly ústredného portálu verejnej správy, iné vlastné alebo externé ISVS, služby alebo dátové registre).

Upozorňujeme: V prípade, že súčasťou projektu sú zmeny v biznis procesoch, musí byť technické riešenie postavené na aktualizovaných  / redizajnovaných biznis procesoch, s cieľom získať úspory v čase, napr. zrýchlením poskytnutia služby, v znížení nákladov atď.

4.1         Biznis vrstva

Doplniť vstupy v  PRÍPRAVNEJ FÁZE:

• doplniť výstižné grafické zobrazenia (pohľady na model biznis architektúry) a popis AS IS stavu biznis vrstvy architektúry a krátky popis TO BE stavu z pohľadu biznis architektúry
• doplniť popis AS IS stavu biznis vrstvy pozostávajúci z nasledujúcich častí:
• identifikácia kľúčových životných situácii (ŽS), ktorých sa projekt týka. Pri kvantifikácii prínosov je vhodné sústrediť sa na jeden až päť najdôležitejších životných situácií, ktoré predstavujú väčšinu ekonomických nákladov občanov/podnikateľov a nákladov úradov.
• procesné mapy, ktoré popisujú postupnosť krokov, žiadostí a zodpovedností, ktoré sú v súčasnom stave potrebné pre vyriešenie každej dotknutej ŽS, vypracované v súlade s metodikou optimalizácie procesov MV SR(či už v spolupráci s MV SR v rámci projektu Optimalizácie procesov alebo samostatnom projekte).
• Skutočné počty podaní (interakcií, návštev úradov) pre jednotlivé kroky a životné situácie.
• Skutočné časy trvania jednotlivých krokov v procese vybavenia ŽS.
• Skutočné finančné príjmy, spojené s jednotlivými procesnými krokmi (správne poplatky, prípadné pokuty a sankcie).
• Skutočné finančné náklady, spojené s jednotlivými procesnými krokmi (náklady na tlač, obálkovanie a poštovné, atď.).

Obrázok č.1 Procesná mapa - príklad

Doplniť vstupy v  INICIAČNEJ FÁZE:

• doplniť výstižné grafické zobrazenia (pohľady na model architektúry riešenia) a popis TO BE stavu navrhovaného riešenia vybraného na základe MCA popísanej v Projektovom zámere. Navrhované riešenie musí korešpondovať s procesnými mapami a musí popisovať spôsob dosiahnutia a monitoringu prínosov uvedených v CBA.
• v popise riešenia uviesť popis zmien medzi súčasným a budúcim stavom navrhovaného riešenia.
• identifikovať a popísať projektom budované, resp. rozvíjané koncové služby. Do tabuľky č.1 uviesť všetky projektom budované/rozvíjané koncové služby, ktoré budú výstupom projektu. Projektom budované/rozvíjané koncové služby musia byť evidované v MetaIS s fázou životného cyklu Plánovaná a musia mať v MetaIs evidované všetky povinné atribúty a vzťahy. Projektom budované/rozvíjané koncové služby musia mať v MetaIs evidované SLA parametre pre východiskový a cieľový stav. Podrobné informácie sú uvedené v Používateľskej príručke MetaIS kap. 2.1.1  (https://metais.vicepremier.gov.sk/help).
• doplniť popis TO BE stavu pozostávajúci z nasledujúcich častí:
• procesné mapy, ktoré popisujú postupnosť krokov, žiadostí a zodpovedností, ktoré budú po realizácii projektu potrebné pre vyriešenie každej dotknutej ŽS, vypracované v súlade s metodikou optimalizácie procesov MV SR (či už v spolupráci s MV SR v rámci projektu Optimalizácie procesov alebo samostatnom projekte).
• očakávané počty podaní (interakcií, návštev úradov) pre jednotlivé kroky a životné situácie.
• očakávané časy trvania jednotlivých krokov v procese vybavenia ŽS.
• očakávané finančné príjmy, spojené s jednotlivými procesnými krokmi (správne poplatky, prípadné pokuty a sankcie).
• očakávané finančné náklady, spojené s jednotlivými procesnými krokmi (náklady na tlač, obálkovanie a poštovné, atď.).

Trvanie vybavenia ŽS zdôvodní predkladateľ projektu jedným z nasledujúcich spôsobov:

• Vynechanie procesného kroku z dôvodu reformy (zmeny legislatívy) a/alebo jeho automatizácie (čas potrebný na vykonanie tohto kroku tak bude 0).
• Odhadom dĺžky trvania procesného kroku v budúcom stave (čas potrebný na vykonanie tohto kroku bude iný ako v súčasnom stave).
• Odhadom dĺžky trvania nového procesnú kroku, ktorý vznikol z dôvodu procesnej reformy, zmeny legislatívy či zmeny fungovania informačného systému (čas potrebný na vykonanie tohto kroku bude väčší ako nula).

Tabuľka č.1 Prehľad koncových služieb, ktoré budú výstupom projektu

Obrázok č.2 Model biznis architektúry – príklad

4.2      Aplikačná vrstva

Doplniť vstupy v  PRÍPRAVNEJ FÁZE:

• Uviesť model a popis AS IS stavu aplikačnej vrstvy architektúry.

Doplniť vstupy v  INICIAČNEJ FÁZE:

• uviesť model a popis TO BE stavu navrhovaného riešenia aplikačnej vrstvy architektúry s prepojením na biznis architektúru.
• popísať aplikačnú architektúru riešenia na úrovni ISVS, ich modulov a vzťahov medzi nimi a vzťahov na externé prostredie. Budované/rozvíjané informačné systémy, vrátene modulov musia byť evidované v MetaIS. Podrobné informácie sú uvedené v Používateľskej príručke MetaIS kap. 2.1.4 (https://metais.vicepremier.gov.sk/help).

4.2.1       Rozsah informačných systémov

Doplniť vstupy v  PRÍPRAVNEJ FÁZE:

• uviesť dotknuté ISVS a ich moduly AS IS stavu vyplnením tabuľky č.2.
• uviesť informácie o dotknutých ISVS z pohľadu ich ďalšej prevádzky po realizácii projektu.

Tabuľka č.2 Prehľad dotknutých informačných systémov v projekte – súčasný stav

Doplniť vstupy v  INICIAČNEJ FÁZE:

• uviesť dotknuté ISVS a ich moduly pre TO BE stav vyplnením tabuľky č.3
• uviesť v tabuľke č.4 budované aplikačné služby, aplikačné služby na externú integráciu a predpokladané vybudovanie cloudových služieb “softvér ako služba“ (SaaS), ktoré budú výstupom projektu. Plánované aplikačné služby musia byť evidované v MetaIS s fázou životného cyklu Plánovaná a musia mať v MetaIs evidované všetky povinné atribúty a vzťahy. Budované aplikačné služby musia mať v MetaIs evidované SLA parametre pre východiskový a cieľový stav. Podrobné informácie sú uvedené v Používateľskej príručke MetaIS kap. 2.1.3  (https://metais.vicepremier.gov.sk/help).

Tabuľka č. 3 Prehľad budovaných/rozvíjaných ISVS v projekte – budúci stav

Tabuľka č.4 Prehľad budovaných aplikačných služieb – budúci stav

Obrázok č.3 Model aplikačnej architektúry - príklad

4.2.2       Využívanie nadrezortných centrálnych blokov a podporných spoločných blokov (SaaS)

Doplniť vstupy v  PRÍPRAVNEJ FÁZE:

• uviesť informácie o v súčasnosti využívaných, resp. nevyužívaných nadrezortných centrálnych blokoch a podporných spoločných blokoch (SaaS) verejnej správy – AS IS stav. Všetky realizované integrácie na nadrezortné centrálne bloky a podporné spoločné bloky (SaaS) v AS IS stave musia byť evidované v MetaIS.
• uviesť v tabuľke č.5 informácie o využívaní nadrezortných centrálnych blokov (spoločné moduly podľa zákona č. 305/2013 e-Governmente) a podporných spoločných blokov (SaaS) podľa aktuálneho stavu.

Tabuľka č.5 Prehľad integrácii ISVS na nadrezortné centrálne bloky – súčasný stav

Doplniť vstupy v  INICIAČNEJ FÁZE:

• v nasledovných kapitolách uviesť plánované využívanie nadrezortných centrálnych blokov a podporných spoločných blokov (SaaS) verejnej správy v TO BE stave. Povinnosť využívať nadrezortné centrálne bloky - spoločné moduly stanovuje zákon č. 305/2013 Z. z. o elektronickej podobe výkonu pôsobnosti orgánov verejnej moci a o zmene a doplnení niektorých zákonov (zákon o e-Governmente) v znení neskorších predpisov (najmä § 10 a nasl.). Prehľad a  informácie o nadrezortných centrálnych blokoch a podporných spoločných blokoch (SaaS) sú uvedené v prílohe P8 Zoznam nadrezortných blokov a podporných spoločných blokov Používateľskej príručky MetaIS (https://metais.vicepremier.gov.sk/help).
• v MetaIS evidovať plánované využívanie nadrezortných centrálnych blokov a podporných spoločných blokov (SaaS). Evidencia integrácií v MetaIS sa realizuje evidovaním vzťahov  aplikačných služieb budovaného//rozvíjaného ISVS na príslušné aplikačné služby nadrezortných centrálnych blokov a podporných spoločných blokov. Podrobné informácie sú uvedené v Používateľskej príručke MetaIS kap. 2.1.3.3.1 a kap. 2.1.3.3.2 (https://metais.vicepremier.gov.sk/help). Detailný popis funkcionalít a služieb IS CSRÚ: Integračný manuál služieb IS CSRÚ (https://datalab.digital/dokumenty/).

Obrázok č.4 Integrácie na IS CSRÚ - príklad

4.2.3       Prehľad plánovaného využívania podporných spoločných blokov (SaaS)

Doplniť vstupy v  INICIAČNEJ FÁZE:

• uviesť v tabuľke č. 6 prehľad ISVS, ktoré plánujú využívanie podporných spoločných blokov (SaaS) v TO BE stave. Plánované využívanie SaaS riešení musí byť evidované v MetaIS.

Tabuľka č.6 Prehľad integrácii ISVS na podporné spoločné bloky (SaaS) – budúci stav

4.2.4       Prehľad plánovaných integrácií ISVS na nadrezortné centrálne bloky – spoločné moduly

Doplniť vstupy v  INICIAČNEJ FÁZE:

• uviesť v tabuľke č.7 prehľad ISVS integrovaných na spoločné moduly ÚPVS v TO BE stave. Plánované integrácie musia byť evidované v MetaIS.

Tabuľka č.7 Prehľad integrácii ISVS na spoločné moduly – budúci stav

4.2.5       Prehľad plánovaných integrácií ISVS na nadrezortné centrálne bloky - modul procesnej integrácie a integrácie údajov  (IS CSRÚ)

Doplniť vstupy v  INICIAČNEJ FÁZE:

• uviesť v tabuľke č.8 prehľad ISVS, ktoré sa budú integrovať na nadrezortné centrálne bloky – modul procesnej integrácie a integrácie údajov v TO BE stave. Plánované integrácie musia byť evidované v MetaIS.

Tabuľka č.8  Prehľad integračných väzieb medzi ISVS a IS CSRÚ – budúci stav

4.2.6       Poskytovanie údajov z ISVS do IS CSRÚ

Doplniť vstupy v  INICIAČNEJ FÁZE:

• uviesť v tabuľke č. 9 prehľad poskytovaných údajov (objektov evidencie, ďalej OE) z ISVS do IS CSRÚ v TO BE stave.

Tabuľka č.9 Prehľad ISVS a objektov evidencie poskytovaných do IS CSRÚ – budúci stav

4.2.7       Konzumovanie údajov z IS CSRU

Doplniť vstupy v  INICIAČNEJ FÁZE:

• uviesť v tabuľke č. 10 prehľad konzumovaných údajov z IS CSRÚ v TO BE stave. Súčasné dostupné objekty evidencie a údaje v IS CSRÚ (https://datalab.digital/referencne-udaje/dostupne-udaje-v-is-csru/).

Tabuľka č. 10 Prehľad ISVS a objektov evidencie konzumovaných z IS CSRÚ – budúci stav

4.3      Dátova vrstva

Každá organizácia by mala mať zavedený systematický manažment údajov (vrátane nastavenie príslušných procesov a metodík pre správu celého životného cyklu údajov) a byť schopná evidovať a spravovať údaje v strojovo-spracovateľnej podobe. V kapitolách nižšie je potrebné popísať AS IS a následne TO BE stav organizácie z pohľadu údajov, ich štruktúry a následného výkonu príslušnej agendy vo vzťahu k projektu.

4.3.1       Údaje v správe organizácie

Doplniť vstupy v  PRÍPRAVNEJ FÁZE:

• popísať dátovú architektúru riešenia na úrovni objektov evidencie a vzťahov medzi nimi v AS IS stave.
• pri popise je potrebné vychádzať z metodiky Ministerstva vnútra - Metodika identifikácie, vizualizácie a referencovania údajov pri dátovom modelovaní vo verejnej správe. (https://www.minv.sk/swift_data/source/mvsr_a_eu/fabianova/np_optimalizacia/metodika-modelovania-udajov-vs.pdf).

Doplniť vstupy v  INICIAČNEJ FÁZE:

• uviesť diagram tried a štruktúrovaný popis entít a atribútov vhodný aj pre strojové spracovanie. Diagram tried uviesť vo forme úplného logického modelu.
• definovať a popísať plánované procesy organizácie riadenia celého životného cyklu správy údajov, kde je potrebné zrozumiteľne zdokumentovať dátové štruktúry, proces tvorby údajov, štatistické metodológie (ak budú použité), dátové zdroje, kontext a ďalšie aspekty manažmentu údajov.
• Proces riadenia pre manažment údajov musí byť zavedený nad informačnými systémami, ktoré obsahujú objekty evidencie a budú riešené v projekte.
• Po organizačnej stránke je podmienkou zavedenie role dátového kurátora (dátový architekt) v organizácii, v rozsahu ako ju definuje strategická priorita Manažment údajov a strategická priorita Otvorené údaje, ktorý bude zodpovedný za koncept systematického manažmentu údajov a úpravu organizačnej štruktúry smerom k vytvoreniu rezortnej dátovej kancelárie.
• Popísať zavedenie systematického manažmentu údajov v organizácií.

4.3.2       Dátový rozsah projektu

Doplniť vstupy v  INICIAČNEJ FÁZE:

• pre budované informačné systémy vytvoriť tzv. doménový model, ktorý definuje návrh dátových prvkov súvisiacich s projektom v súlade s existujúcim Centrálnym modelom údajov verejnej správy publikovaným na https://datalab.digital/dokumenty/. Úlohou doménového modelu je vizuálne znázorniť rozsah predmetných údajov daného projektu, pričom je možné abstrahovať od nepodstatných detailov. Je platformovo nezávislý (nie je určený pre konkrétny programovací jazyk).
• V tabuľke č.11 uviesť a popísať OE, súvisiace s projektom.

Pre modelovanie doménového modelu je potrebné stiahnuť si Centrálny model údajov verejnej správy v preferovanej distribúcii a v novom modeli použiť existujúce dátové prvky, ak tieto patria do domény projektu. Z technického pohľadu je odporučený jazyk UML alebo ArchiMate.

V prípade, že sa používa dátový prvok z Centrálneho dátového modelu je nutné použiť skrátenú formu URI identifikátora daného prvku, napr. pper:PhysicalPerson je skrátený tvar https://data.gov.sk/def/ontology/physical-person/PhysicalPerson https://metais.vicepremier.gov.sk/publicspace?pageId=59836112.

Tabuľka č.11 Prehľad objektov evidencie v jednotlivých ISVS/registroch  súvisiace s projektom – budúci stav

Obrázok 5 Doménový model - príklad                                                  Obrázok 6 Zjednodušený doménový model - príklad

4.3.3       Kvalita a čistenie údajov

4.3.3.1       Zhodnotenie objektov evidencie z pohľadu dátovej kvality

Doplniť vstupy v  INICIAČNEJ FÁZE:

• zhodnotiť objekty evidencie (uvedené v kap. 4.3.2) so zameraním sa na významnosť kvality údajov pre biznis procesy (možné riziká v dôsledku dátovej nekvality), t.j. ak bude údaj nepresný, bude mať nesprávnu hodnotu, formát, nebude vyplnený, alebo stotožnený voči referenčnému registru, ako významne to ovplyvní príslušnú agendu.
• zhodnotiť objekty evidencie so zameraním sa na citlivosť kvality údajov, ktorú ovplyvňuje, najmä spôsob vstupu údajov do ISVS. Uviesť ako budú údaje do ISVS zadávané.
• uviesť informácie či a ako bude zapracovaná možnosť overenia hodnoty údaja.
• uviesť informácie či bude zapracované pri zadávaní údajov obmedzenie hodnôt, napríklad formou číselníka, alebo podmienok
• uviesť informácie či budú dáta migrované z iného ISVS. Ak áno, je potrebné zhodnotiť a na základe toho stanoviť v tabuľke č.12 prioritu (poradie dôležitosti) pre meranie dátovej kvality objektov evidencií – t.j. poradie v akom bude správca ISVS približne realizovať meranie dátovej kvality a čistiť údaje. Prvé 2 záznamy sú vyplnené ako príklad. Vymažte, resp. prepíšte ich vlastnými údajmi. Riadky v tabuľke doplňte podľa potreby.

Tabuľka č.12 Kategorizácia objektov evidencie z pohľadu dátovej kvality – budúci stav

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

Doplniť vstupy v  INICIAČNEJ FÁZE:

• v tabuľke č.13 definovať potrebné kapacity pre zabezpečenie riadenia dátovej kvality – napr. dátový kurátor, data steward, dátový špecialista pre dátovú kvalitu, databázový špecialista, projektový manažér a pod. (https://datalab.digital)

Tabuľka č.13 Prehľad rolí a personálneho zabezpečenia pre riadenie dátovej kvality

4.4      Referenčné údaje

V národnej koncepcii informatizácie verejnej správy bol zadefinovaný princíp „jedenkrát a dosť“, ku ktorému boli ďalej detailnejšie rozpracované úlohy v dokumente Strategická priorita Manažment údajov. Cieľom je dosiahnutie stavu, kedy orgány verejnej moci pri poskytovaní svojich služieb odstránia povinnosti občanov alebo podnikateľských subjektov predkladať údaje vo forme rôznych výpisov, odpisov, potvrdení, atď., ktorými už disponuje verejná správa v rámci svojich registrov.

Doplniť vstupy v  PRÍPRAVNEJ FÁZE:

• uviesť ako sa ide rozvíjať AS IS stav v oblasti Referenčných údajov a následne vyplniť podkapitoly uvedené nižšie z pohľadu TO BE stavu projektu.

Doplniť vstupy v  INICIAČNEJ FÁZE:

Za účelom dosiahnutia TO BE stavu, z ktorého bude benefitovať občan / podnikateľský subjekt úsporou svojho času a prostriedkov, je potrebné popísať viacero nasledujúcich krokov na úrovni participujúcich subjektov verejnej správy:

• popísať aká je aktuálna kvalita údajov v zdrojových registroch.
• uviesť dôvod vyhlásenia referenčných údajov (údaje musia byť k subjektu evidencie jedinečné a k týmto údajom je podľa osobitných predpisov uvedená domnienka správnosti).
• uviesť poskytovateľov a konzumentov (vlastníkov) údajov do centrálnej platformy dátovej integrácie (modulu procesnej integrácie a integrácie údajov slúžiacim pre výmenu údajov pri výkone verejnej moci elektronicky).
• popísať legislatívu a procesy vo verejnej správe (konkrétnej životnej situácie) , pre konkrétne údaje identifikované v projekte (odstránenie legislatívnych povinností predkladať úradom výpisy a potvrdenia a automatizácia procesov viažucich sa k životným situáciám a interakcie s občanom / podnikateľským subjektom).

4.4.1       Objekty evidencie z pohľadu procesu ich vyhlásenia za referenčné

V predchádzajúcich kapitolách boli identifikované integrácie budovaného/rozvíjaného ISVS na IS CSRÚ. V tejto časti dokumentu je potrebné definovať/popísať rozsah a štruktúru na úrovni registrov / objektov evidencie / údajov, ktoré sa navrhujú vyhlásiť za referenčné v naviazanosti na ich zrealizovateľné vzájomné zdieľanie medzi subjektami verejnej správy a dodržanie pravidla, že za referenčné údaje/atribúty sú vyhlasované také údaje/atribúty, ktoré sú k subjektu evidencie jedinečné a práve tie, ktoré využívajú subjekty verejnej správy pri realizácii princípu „1 x a dosť“.

Doplniť vstupy v  INICIAČNEJ FÁZE:

• popísať a zdôvodniť navrhované objekty evidencie k vyhláseniu za referenčné z pohľadu ich dátovej kvality v zmysle podkapitoly venujúce sa kvalite a čisteniu údajov.
• popísať ako bude zabezpečená dostupnosť poskytovania navrhovaných objektov evidencie za referenčné (t.j. v rámci nich údaje/atribúty) cez Modul procesnej integrácie a integrácie údajov, t.j. integráciou cez jeho dátovú časť - IS CSRÚ.
• uviesť časový harmonogram procesu vyhlasovania a zmeny referenčných údajov. Informácie o procese vyhlasovania a zmeny referenčných údajov sú uvedené na https://datalab.digital/referencne-udaje/referencne-udaje-a-zakladne-ciselniky/proces-vyhlasovania-a-zmeny-referencnych-udajov/. Metodické usmernenie MIRRI o postupe zaraďovania referenčných údajov do zoznamu referenčných údajov vo väzbe na referenčné registre a vykonávania postupov pri referencovaní https://metais.vicepremier.gov.sk/confluence/download/attachments/2621442/Metodicke_usmernenie_UPVII_3639_2019_oDK_1_FINAL.pdf?version=1&modificationDate=1554714761337&api=v2.

Tabuľka č.14 Prehľad identifikovaných referenčných údajov – budúci stav

4.4.2       Identifikácia údajov pre konzumovanie alebo poskytovanie údajov  do/z CSRU

Doplniť vstupy v  INICIAČNEJ FÁZE:

• identifikovať/kvantifikovať v tabuľke č.15 potenciálnych konzumentov týchto objektov evidencie (t.j. navrhovaných k vyhláseniu za referenčné), vrátane ich oprávnenosti/nároku na konzumovanie v zmysle konkrétnych ustanovení osobitných právnych predpisov na strane konzumenta, prípadne aj na strane poskytovateľa. V nadväznosti na uvedené identifikovať osobitné právne predpisy (až na úroveň konkrétneho ustanovenia), ktoré je nutné novelizovať v záujme dosiahnutia TO BE stavu a jeho bezproblémovej aplikovateľnosti.

Poznámka: Pre úspešné napojenie ISVS na IS CSRÚ v roli konzumenta údajov je nutné postupovať v zmysle predložených dokumentov:

• „Postup pripojenia OVM do IS CSRÚ v roli poskytovateľa údajov“ (https://datalab.digital/dokumenty)
• „Postup pripojenia OVM do IS CSRÚ v roli konzumenta údajov“ (https://datalab.digital/dokumenty)
• Zoznam dostupných údajov pre konzumovanie cez IS CSRÚ (https://datalab.digital/referencne-udaje/).

Tabuľka č.15 Prehľad konzumovaných/poskytovaných referenčných údajov – budúci stav

4.5      Otvorené údaje

V tejto časti je potrebné uviesť informácie súvisiace s otvorenými údajmi z pohľadu TO BE stavu projektu.

Doplniť vstupy v  INICIAČNEJ FÁZE:

• v tabuľke č.16 doplniť názov objektu evidencie (identifikované v kapitole dátový rozsah projektu) pre kategóriu otvorených údajov a stanoviť úroveň požadovanej kvality (interoperability) otvorených údajov. Pravidlá pre úroveň interoperability verejných otvorených údajov sú stanovené v https://wiki.vicepremier.gov.sk/pages/viewpage.action?pageId=23986518.
• Požadovaná kvalita:
  • Automatizované publikovanie otvorených údajov v kvalite 3★ (Všetky datasety je potrebné registrovať v centrálnom katalógu otvorených údajov na data.gov.sk). Formát CSV, XML, ODS, JSON
  • Automatizované publikovanie otvorených údajov v kvalite 4★ (Všetky datasety je potrebné registrovať v centrálnom katalógu otvorených údajov na data.gov.sk) Formát údajov RDF, OWL, TriX, JSON
  • Automatizované publikovanie otvorených údajov v kvalite 5★ (Všetky datasety je potrebné registrovať v centrálnom katalógu otvorených údajov na data.gov.sk) Formát udajov RDF, OWL, TriX, JSON.

Tabuľka č.16 Prehľad otvorených údajov – budúci stav

4.6      Analytické údaje

V tejto časti je potrebné uviesť informácie súvisiace s analytickými údajmi z pohľadu TO BE stavu projektu.

Analytické údaje predstavujú obrovskú skupinu dát získavaných vysokou rýchlosťou z vysokého počtu rôznych typov zdrojov. V priestore verejnej správy sa jedná o dátové zdroje, ktoré sú vytvárané a spravované jednotlivými organizáciami za účelom podpory služieb verejnej správy, služieb vo verejnom záujme alebo verejných služieb. Tieto údaje môžeme okrem uvedenej primárnej funkcie využiť aj na analytické spracovanie, tak aby verejná správa dokázala využívať svoje údaje pre potreby prípravy analýz, na podporu rozhodovania, riadenia a lepší návrh politík. Podmienkou pre plné využitie potenciálu údajov vo verejnej správe je ich poznanie (informácie o dátových zdrojoch, ich obsahu a atribútoch) a zabezpečenie prístupu k analytickým údajom pre analytické jednotky.  

Doplniť vstupy v  INICIAČNEJ FÁZE:

• uviesť informácie či je organizácia integrovaná na IS CSRÚ, alebo plánuje inú možnosť integrácie s modulom na sprístupňovanie údajov pre analytické jednotky (napr. KAV).
• Sprístupnenie dátových zdrojov organizácie na analytické účely v zmysle zákona (Zákon o údajoch - https://datalab.digital/legislativa/).

Tabuľka č.17 Prehľad sprístupnených dátových zdrojov určených na analytické účely – budúci stav

4.7      Moje údaje

V tejto časti je potrebné uviesť informácie súvisiace s údajmi, ktoré spadajú do kategórie mojich údajov, z pohľadu budúceho TO BE stavu projektu.

Za moje údaje sa považujú najmä: 

• množina údajov o konaní, ktoré sa týkajú fyzickej osoby alebo právnickej osoby 
• množina údajov, vrátane osobných údajov, viažucich sa k fyzickej osobe alebo právnickej osobe ako ku subjektu evidencie, ktoré sú predmetom evidovania povinným subjektom, 
• množina údajov obsiahnutých v návrhu na začatie konania, žalobe, rozhodnutí, žiadosti, sťažnosti, vyjadrení, stanovisku a ohlásení alebo inom dokumente, ktorý vydáva v konaní povinný subjekt, viažuci sa ku konkrétnej fyzickej osobe alebo právnickej osobe.

Relevantné údaje budú dostupné na centrálnej platforme integrácie údajov pre občanov a podnikateľov prostredníctvom modulu Manažmentu osobných údajov. 

Podmienkou je zabezpečiť, aby údaje identifikované pre službu moje údaje boli prístupné elektronicky v strojovo-spracovateľnom formáte automatizovaným spôsobom cez aplikačné programovacie rozhranie, alebo prostredníctvom modulu procesnej integrácie a integrácie údajov) pre fyzickú osobu alebo právnickú osobu, ktorej sa týkajú, na základe preukázania elektronickej identity osoby (Zákon o údajoch - https://datalab.digital/legislativa/).

.

Doplniť vstupy v  INICIAČNEJ FÁZE:

• v prípade, že predkladateľ projektu disponuje údajmi, ktoré spadajú do kategórie mojich údajov, je potrebné vyplniť tabuľku č.18.

Minimálny rozsah pre vyhlásenie dátových prvkov za moje údaje, ktoré musí žiadateľ v projekte zabezpečiť: 

• označenie povinného subjektu,
• názov ISVS v ktorom je dátový prvok obsiahnutý,
• kód informačného systému, v ktorom je dátový prvok obsiahnutý, podľa centrálneho metainformačného systému,
• označenie dátového prvku,
• strojovo-spracovateľný formát dátového prvku,
• technickú špecifikáciu aplikačného programovacieho rozhrania,
• ďalšie doplňujúce informácie.
• transparentný pohľad na prístup k údajom subjektu, k logom (kto pristupoval k údajom, za akým účelom a kedy).

Tabuľka č.18 Prehľad údajov identifikovaných pre službu „moje údaje“ – budúci stav

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

Doplniť vstupy v  INICIAČNEJ FÁZE:

• vyplniť tabuľku č.19 z pohľadu TO BE stavu projektu. Výstupom predchádzajúcich kapitol je súhrnná tabuľka pre kategorizáciu množiny údajov z pohľadu ich využiteľnosti.

Tabuľka č.19 Kategorizácia údajov z pohľadu ich využiteľnosti (účelu)  - budúci stav

4.9      Technologická vrstva

4.9.1       Prehľad technologického stavu

Doplniť vstupy v  PRÍPRAVNEJ FÁZE:

• uviesť popis a model technologickej vrstvy ASIS stavu, používané výpočtové prostriedky, konfigurácie siete, problematické body, ktoré je potrebné projektom riešiť

4.9.2       Požiadavky na výkonnostné parametre, kapacitné požiadavky

Doplniť vstupy v  INICIAČNEJ FÁZE:

• doplniť pre TO BE stav v tabuľke nižšie, požiadavky na výkonnostné parametre, kapacitné požiadavky, ktoré majú vplyv na výkon, sizing prostredia, počet interných používateľov, počet externých používateľov, počet spracovávaných procesov, dokumentov, komunikáciu medzi vrstvami architektúry IS, využívanie sieťovej infraštruktúry (Govnet, LAN, VPN, …)

Tabuľka č.20 Prehľad vybraných kapacitných a výkonových požiadaviek– budúci stav

4.9.3       Návrh riešenia technologickej architektúry

Doplniť vstupy v  INICIAČNEJ FÁZE:

• Uviesť návrh a model architektúry technologickej vrstvy s prihliadnutím na zavedenie Cloud-Native ako štandardu pre vývoj nových ITVS a pre programovanie starých ITVS do nového štandardu a na zavedenie štandardu vytvárania a používania zdieľaných služieb.  V prípade, že riešenie nepredpokladá využívanie cloudových služieb z katalógu služieb vládneho cloudu (Iaas,PaaS,SaaS podľa katalógu služieb VC), je potrebné nevyužitie cloudových služieb z katalógu služieb vládneho cloudu dostatočne zdôvodniť. Taktiež požiadavky riešenia na HW, SW a licencie v zmysle požadovaného sizingu pre vývojové, testovacie a produkčné prostredie je potrebné uviesť v dokumente BC/CBA na príslušných kartách.
• V popise návrhu riešenia je požadované uviesť:
• prístup k riešeniu technologickej architektúry a súvisiace architektonické rozhodnutia
• popis požiadaviek na prevádzkové prostredia (vývoj, test, produkčné)
• diagram nasadenia a komunikačnej infraštruktúry.

Poznámka:

Pri výbere požiadaviek na riešenie, je potrebné klásť dôraz  na výber služieb, ktoré sú založené na najmodernejších technológiách, prostredníctvom ktorých bude vytvorený predpoklad na vývoj/tvorbu moderného ISVS. Pre navrhované riešenie odporúčame použiť prístup pre vývoj takzvaných Cloud Native aplikácií. Riešenie „Cloud-native“ ISVS, je v čo najväčšej miere nezávislé na umiestnení v cloude, resp. datacentre. Nezávislosť novovyvíjaného ISVS od cloudového prostredia by malo byť základnou prioritou a podmienkou architektúry ISVS.

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

Doplniť vstupy v  INICIAČNEJ FÁZE:

• popísať navrhované riešenia využívania služieb vládneho cloudu  (uvedené v tabuľkách nižšie) a uviesť parametre požadovaných prostredí:
• Vývojové (v zmysle požadovaného sizingu uvedeného v tabuľkách nižšie)
• Testovacie (v minimálnom možnom sizingu uvedeného v tabuľkách nižšie) – určené pre testy nových modulov, úprav, zmenových požiadaviek a retesty na úrovni upgrade‑ov (nie pre záťažové testovanie).
• Produkčné (v zmysle požadovaného sizingu uvedeného v tabuľkách nižšie)
• určiť v štruktúrovanej podobe (tabuľka č.21) množstvo požadovaných zdrojov projektu, vyskladaním virtuálnych serverov zo šablón zverejnených na stránke https://sk.cloud v sekcii “Katalóg služieb - Aktuálne ponúkané šablóny VM”

Poznámka:

V súlade s NKIVS by technologická architektúra mala byť založená na cloudových službách. V rámci verejného obstarávania je potrebné potenciálneho uchádzača o zákazku požiadať o návrh technologickej infraštruktúry potrebnej pre implementáciu a prevádzku navrhovaného riešenia. Dodávateľ by pre svoj návrh technologického prostredia mal využiť hlavne cloudové služby vládneho cloudu alebo služby uvedené v katalógu služieb, ktoré prešli procesom klasifikácie, hodnotenia, registrácie a zaradenia do katalógu služieb zverejnenom na stránke MIRRI:

https://www.mirri.gov.sk/sekcie/informatizacia/egovernment/vladny-cloud/katalog-cloudovych-sluzieb/index.html

                Tabuľka č.21 Prehľad požiadaviek na výpočtové kapacity prevádzkových prostredí vo vládnom cloude – budúci stav

• určiť v štruktúrovanej podobe (tabuľka č.22) ďalšie služby potrebné na prevádzku projektu podľa katalógu cloudových služieb. Tabuľku si treba prispôsobiť, aby čo najlepšie odpovedala aktuálnym podmienkam zadania a návrhu riešenia.

Tabuľka č.22 Ďalšie doplnkové služby z katalógu cloudových služieb – budúci stav

Poznámka:

Požiadavky na služby vládneho cloudu odporúčame mať ešte pred vyhlásením VO odkomunikované s prevádzkovateľom vládneho cloudu (MV SR) v súlade s postupom zverejneným na webovom sídle https://sk.cloud v sekcii “Postup a hlavné kroky pre vytvorenie projektu vo Vládnom cloude” alebo https://www.sk.cloud/data/Postup_a_hlavne_kroky_pre_vytvorenie_projektu_vo_Vladnom_cloude.pdf.

4.9.5       Jazyková lokalizácia

Doplniť vstupy v  INICIAČNEJ FÁZE:

• uviesť požiadavky na jazykovú lokalizáciu riešenia TO BE stavu.

4.10   Bezpečnostná architektúra

Doplniť vstupy v  PRÍPRAVNEJ FÁZE:

• uviesť popis AS IS stavu z pohľadu súčasného riešenia bezpečnostnej architektúry.

Doplniť vstupy v  INICIAČNEJ FÁZE:

• uviesť popis TO BE stavu riešenia bezpečnostnej architektúry  (+ popis alternatív)
• uviesť súlad navrhovanej bezpečnostnej architektúry s dotknutými právnymi normami a zároveň s technickými normami, ktoré stanovujú úroveň potrebnej bezpečnosti IS, pre manipuláciu so samotnými dátami, alebo technické/technologické/personálne zabezpečenie samotnej výpočtovej techniky/HW vybavenia. Ide najmä o:
• Zákon č. 95/2019 Z.z. o informačných technológiách vo verejnej správe
• Zákon č. 69/2018 Z.z. o kybernetickej bezpečnosti
• Zákon č. 45/2011 Z.z. o kritickej infraštruktúre
• vyhláška Úradu podpredsedu vlády Slovenskej republiky pre investície a informatizáciu č. 78/2020 Z. z. o štandardoch pre informačné technológie verejnej správy
• vyhláška Úradu podpredsedu vlády Slovenskej republiky pre investície a informatizáciu č. 179/2020 Z. z., ktorou sa ustanovuje spôsob kategorizácie a obsah bezpečnostných opatrení informačných technológií verejnej správy
• vyhláška Úradu na ochranu osobných údajov Slovenskej republiky č. 158/2018 Z. z. o postupe pri posudzovaní vplyvu na ochranu osobných údajov
• Nariadenie Európskeho parlamentu a Rady (EÚ) 2016/679 z 27. apríla 2016 o ochrane fyzických osôb pri spracúvaní osobných údajov a o voľnom pohybe takýchto údajov, ktorým sa zrušuje smernica 95/46/ES (všeobecné nariadenie o ochrane údajov)
• Zákon č. 18/2018 Z. z. o ochrane osobných údajov a o zmene a doplnení niektorých zákonov.
• Stručne popísať postupy na dosiahnutie potrebnej úrovne bezpečnosti a spôsob zabezpečenia aktív projektu na jednotlivých vrstvách architektúry (dôvernosť, dostupnosť a integrita).
• Doplniť požiadavky na používateľské role a správu aplikácie
  • Interní používatelia (pracovníci ABC – administrácia , správa, podpora)
  • Externí používatelia (zákazníci, partneri tretie strany).

5.     ZÁVISLOSTI NA OSTATNÉ ISVS / PROJEKTY

Doplniť vstupy v  INICIAČNEJ FÁZE:

• Uviesť v tabuľke č.23 sumárny prehľad všetkých projektov a programov, ktoré sú v štádiu vývoja a v korelácii s pripravovaným projektom.

Tabuľka č. 23 Prehľad projektov, ktoré sú v štádiu vývoja a v korelácii s pripravovaným projektom

V popise závislostí per budovaný/rozvíjaný ISVS zohľadnite:

• Požiadavky pre časť „Napojenie na API Gateway“ (volanie backendových služieb výlučne cez API Gateway, jednotné pripojenie a interakcia prístupových miest, frontendov cez ISVS prevádzkovateľa NASES).

6.     ZDROJOVÉ KÓDY

Doplniť vstupy v  INICIAČNEJ FÁZE:

• doplniť požiadavky na zdrojové kódy (napr. zo vzorovej zmluvy). Aké druhy, formy a štruktúry zdrojových kódov požadujte odovzdať. Stručne popíšte aj spôsob ich preberania, periodicitu (pri akých míľnikoch) a spôsob archivácie.
• doplniť pravidlá pre preberanie, správu a archiváciu zdrojových kódov a tieto pravidlá následne preniesť do ZoD/SLA. po uzatvorení zmluvy s dodávateľom riešenia – zohľadniť ich aj v PIDe
• Doporučujeme naviazať preberanie/odovzdávanie zdrojových kódov na fakturačné míľniky.

Upozorňujeme: navrhnite spôsob, ako predísť „Vendor lock-in“ = t.j. dodávané riešenie musí byť v súlade so Zákonom o ITVS (ktorý „vendor lock-in“ nepovoľuje). Následne ustanovenia predchádzaniu vendor-lockinu musia byť zahrnuté aj v ZoD a SLA.

Dôležité usmernenie pre oblasť zdrojových kódov:

• Centrálny repozitár zdrojových kódov: https://www.zakonypreludi.sk/zz/2020-78/znenie-20200501#p31
• Overenie zdrojového kódu s cieľom jeho prepoužitia: https://www.zakonypreludi.sk/zz/2020-85/znenie-20200501#p7-3-c
• Spôsoby zverejňovania zdrojového kódu: https://www.zakonypreludi.sk/zz/2020-85/znenie-20200501#p8-9
• Inštrukcie k EUPL licenciám: https://joinup.ec.europa.eu/sites/default/files/inline-files/EUPL%201_1%20Guidelines%20SK%20Joinup.pdf

7.     PREVÁDZKA A ÚDRŽBA

Doplniť vstupy v  PRÍPRAVNEJ FÁZE:

• doplniť popis AS IS stavu zabezpečenia prevádzky a údržby - popísať AS IS stav podpory prevádzky a úroveň poskytovania služieb (SLA).

Doplniť vstupy v  INICIAČNEJ FÁZE:

• doplniť popis TO BE stavu zabezpečenia prevádzky a údržby - popísať TO BE stav podpory prevádzky a úroveň poskytovania služieb (SLA).
• uveďte prehľad všetkých predpokladaných požiadaviek na prevádzku a údržbu cieľového riešenia.

7.1      Prevádzkové požiadavky

Doplniť vstupy v  INICIAČNEJ FÁZE:

• uviesť popis L1 úrovne – požiadavky / očakávania
• uviesť popis L2 úrovne – požiadavky / očakávania
• uviesť popis L3 úrovne – požiadavky / očakávania
• štandardný čas podpory, čas/rýchlosť odstraňovania vád, dostupnosť systému, zálohovanie, plán obnovy systému, atď.
• požadované SLA na služby systémovej a aplikačnej podpory – servisné služby vzťahujúce sa na produkčné a testovacie prostredie IS.

7.1.1       Úrovne podpory používateľov:

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

• L1 podpory IS (Level 1, priamy kontakt zákazníka) - jednotný kontaktný bod verejného obstarávateľa – IS Solution manager, ktorý je v správe verejného obstarávateľa a v prípade jeho nedostupnosti Centrum podpory používateľov (zabezpečuje prevádzkovateľ IS a DataCentrum).

• L2 podpory IS (Level 2, postúpenie požiadaviek od L1) - vybraná skupina garantov, so znalosťou IS (zabezpečuje prevádzkovateľ IS – verejný obstarávateľ).

• L3 podpory IS (Level 3, postúpenie požiadaviek od L2) - na základe zmluvy o podpore IS (zabezpečuje úspešný uchádzač).

Definícia:

• 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ťiaž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:

• Help Desk je dostupný cez IS Solution manager a pre vybrané skupiny užívateľov cez telefón a email, incidenty sú evidované v IS Solution manager,
• Dostupnosť L3 podpory pre IS je 8x5 (8 hodín x 5 dní od 8:00h do 16:00h počas pracovných dní),

Riešenie incidentov – SLA parametre

Za incident je považovaná chyba IS, t.j. správanie sa v rozpore s prevádzkovou a používateľskou  dokumentáciou IS. Za incident nie je považovaná chyba, ktorá nastala mimo prostredia IS napr. výpadok poskytovania konkrétnej služby Vládneho cloudu alebo komunikačnej infraštruktúry.

• Označenie naliehavosti incidentu:

možný dopad:

• Výpočet priority incidentu je kombináciou dopadu a naliehavosti v súlade s best practices ITIL V3 uvedený v nasledovnej matici:

Vyžadované reakčné doby:

• (1) Reakčná doba je čas medzi nahlásením incidentu verejným obstarávateľom (vrátane užívateľov IS, ktorí nie sú v pracovnoprávnom vzťahu s verejným obstarávateľom) na helpdesk úrovne L3 a jeho prevzatím na riešenie.

• (2) DKVI znamená obnovenie štandardnej prevádzky - čas medzi nahlásením incidentu verejným obstarávateľom a vyriešením incidentu úspešným uchádzačom (do doby, kedy je funkčnosť prostredia znovu obnovená v plnom rozsahu). Doba konečného vyriešenia incidentu od nahlásenia incidentu verejným obstarávateľom (DKVI) sa počíta počas celého dňa. Do tejto doby sa nezarátava čas potrebný na nevyhnutnú súčinnosť verejného obstarávateľa, ak je potrebná pre vyriešenie incidentu. V prípade potreby je úspešný uchádzač oprávnený požadovať od verejného obstarávateľa schválenie riešenia incidentu.

• (3) Maximálny počet incidentov za kalendárny mesiac. Každá ďalšia chyba nad stanovený limit spoľahlivosti sa počíta ako začatý deň omeškania bez odstránenia vady alebo incidentu. Duplicitné alebo technicky súvisiace incidenty (zadané v rámci jedného pracovného dňa, počas pracovného času 8 hodín) sú považované ako jeden incident.

• (4) Incidenty nahlásené verejným obstarávateľom úspešnému uchádzačovi v rámci testovacieho prostredia

1. Majú prioritu 3 a nižšiu
2. Vzťahujú sa výhradne k dostupnosti testovacieho prostredia
3. Za incident na testovacom prostredí sa nepovažuje incident vztiahnutý k práve testovanej funkcionalite.

Vyššie uvedené SLA parametre nebudú použité pre nasledovné služby:

• Služby systémovej podpory na požiadanie (nad paušál)
• Služby realizácie aplikačných zmien vyplývajúcich z legislatívnych a metodických zmien (nad paušál)

Pre tieto služby budú dohodnuté osobitné parametre dodávky.

7.2      Požadovaná dostupnosť IS:

TEXT pre inšpiráciu – vyberte si pre vás potrebné

7.2.1       Dostupnosť (Availability)

Čo je Dostupnosť (Availability)

Dostupnosť (Availability) znamená, že dáta alebo iné zariadenie sú prístupné v okamihu ich potreby. Vyjadruje sa v percentách dostupného času.

Dostupnosť (Availability) je pojem z oblasti riadenia bezpečnosti v organizácii. Dostupnosť znamená, že dáta sú prístupné v okamihu jej potreby. Narušenie dostupnosti sa označuje ako nežiaduce zničenie (destruction) alebo nedostupnosť. Dostupnosť je zvyčajne vyjadrená ako percento času v danom období, obvykle za rok. Orientačný zoznam dostupnosti je uvedený v tabuľke:

• 90% dostupnosť znamená výpadok 36,5 dňa
• 95% dostupnosť znamená výpadok 18,25 dňa
• 98% dostupnosť znamená výpadok 7,30 dňa
• 99% dostupnosť znamená výpadok 3,65 dňa
• 99,5% dostupnosť znamená výpadok 1,83 dňa
• 99,8% dostupnosť znamená výpadok 17,52 hodín
• 99,9% (“tri deviatky”) dostupnosť znamená výpadok 8,76 hodín
• 99,99% (“štyri deviatky”) dostupnosť znamená výpadok 52,6 minút
• 99,999% (“päť deviatok”) dostupnosť znamená výpadok 5,26 minút
• 99,9999% (“šesť deviatok”) dostupnosť znamená výpadok 31,5 sekúnd

Hoci je obvyklé uvádzať dostupnosť v percentách, presnejšie ukazovatele sú vyjadrením doby obnovenia systému a na množstvo dát, o ktoré môžeme prísť:

• RTO (Recovery Time Objective) - doba obnovenia systému, t.j. za ako dlho po výpadku musí byť systém funkčný (pre bližšie info klik na nadpis)
• RPO (Recovery Point Objective) - aké množstvo dát môže byť stratené od vymedzeného okamihu
• Recovery Time - čas potrebný k obnove

Riešenie dostupnosti v praxi: Nedostupnosť dát je jedným z rizík, ktorý môže postihnúť každú organizáciu. Dostupnosť je jedným s kľúčových požiadaviek na každý dôležitý informačný systém a vplyv na dostupnosť má mnoho faktorov, napríklad:

• Dostupnosť servera
• Dostupnosť pripojenie k internetu
• Dostupnosť databázy
• Dostupnosť webových stránok

V prípade, že je časť softvér alebo infraštruktúra zabezpečovaná externe (napr. hosting, webhosting), prenáša sa zodpovednosť za dostupnosť týchto komponentov na dodávateľa. Potom je potrebné mať vhodným spôsobom ošetrenú úroveň dostupnosti, ktorú musí dodávateľ dodržať. Zvyčajne je dostupnosť súčasťou dohody o úrovni poskytovaných služieb (SLA).

7.2.2       RTO (Recovery Time Objective)

RTO (Recovery Time Objective) je jeden z ukazovateľov dostupnosti dát. RTO vyjadruje množstvo času potrebné pre obnovenie dát a celého prevádzky nedostupného systému (softvér).

Recovery Time Objective (zvyčajne sa požíva skratka RTO) je jeden z ukazovateľov dostupnosti dát. RTO vyjadruje množstvo času potrebné pre obnovenie dát a celej prevádzky nedostupného systému (softvér). Môže byť, v závislosti na použitej technológii, vyjadrené v sekundách, hodinách či dňoch.

Využitie RTO v praxi: Ukazovateľ RTO sa z pohľadu zákazníka využíva pre vyjadrenie doby pre obnovu dát. (napr. formou SLA). Na druhú stranu poskytovatelia dnes môžu voliť rôzne technológie zálohovanie, respektíve replikovanie dát a dobu obnovy dát znížiť až k nulovému výpadku. Existujúce technológie sa delia zhruba nasledovne:

• Tradičné zálohovanie - výpadok a obnova trvá cca hodiny až dni
• Asynchrónne replikácie dát - výpadok a obnova v poriadku sekúnd až minút
• Synchrónny replikácie dát - nulový výpadok

7.2.3       RPO (Recovery Point Objective)

RPO (Recovery Point Objective) je jeden z ukazovateľov dostupnosti dát. RPO vyjadruje, do akého stavu (bodu) v minulosti možno obnoviť dáta.

Recovery Point Objective (zvyčajne sa požíva skratka RPO) je jeden z ukazovateľov dostupnosti dát. RPO vyjadruje, do akého stavu (bodu) v minulosti možno obnoviť dáta. Inými slovami množstvo dát, o ktoré môže organizácia prísť.

Využitie RPO v praxi: Ukazovateľ RPO sa z pohľadu zákazníka využíva pre vyjadrenie množstva obnoviteľných dát. (napr. formou SLA). Na druhú stranu poskytovatelia dnes môžu voliť rôzne technológie zálohovanie, respektíve replikovanie dát a bod obnovy dát znížiť až k nulovej strate. Existujúce technológie sa delia zhruba nasledovne:

• Tradičné zálohovanie - výpadok a obnova trvá cca hodiny až dni
• Asynchrónne replikácie dát - výpadok a obnova v poriadku sekúnd až minút, strata sa blíži k nule
• Synchrónny replikácie dát - nulová strata

8.     POŽIADAVKY NA PERSONÁL

Doplniť vstupy v  INICIAČNEJ FÁZE:

• Doplniť požiadavky na projektové personálne zabezpečenie (projektové role a ich obsadenie)
• Doplniť rámcové požiadavky na obsadenie TO BE procesu
• Doplniť požiadavky potrebných školení a certifikátov.

9.     IMPLEMENTÁCIA A PREBERANIE VÝSTUPOV PROJEKTU

Doplniť vstupy v  INICIAČNEJ FÁZE:

• Posúdenie spôsobov nasadzovania jednotlivých prístupov v praxi

V zmysle Vyhlášky 85/20202 Zz o projektovom riadení je potrebné posúdiť spôsob realizácie projektu metódou waterfall, agile alebo ich kombináciou.

V zmysle vyhlášky 85/2020 Zz o projektovom riadení je možné pristupovať k realizácii projektu prostredníctvom čiastkových plnení, t.j. inkrementov, a to:

• Inkrement musí obsahovať z realizačnej fázy projektu aspoň etapu Implementácia a Testovanie a Nasadenia do produkcie; je možné ho realizovať viacerými iteráciami v závislosti od charakteru projektu a každý doručený inkrement projektu je nasadený na produkčnom prostredí informačnej technológie a je možné začať s dokončovacou fázou projektu, alebo pokračovať ďalším inkrementom
• Ak realizačná fáza veľkých projektov pozostáva z dodania jedného funkčného celku alebo dodania výlučne technických prostriedkov, objednávateľ v produkte P-03 Prístup k projektu – rámcový, I-03 Prístup k projektu - detailný a v I-02 BC/CBA, posúdi a vyhodnotí aj alternatívy rozdelenia na inkrementy na preukázanie ekonomickej nevýhodnosti alebo technických obmedzení rozdeliť projekt na inkrementy.

Poznámka: odporúčame, aby ste si VŠETKY TABUĽKOVÉ VSTUPY evidovali a spravovali v jednom centrálnom EXCELI – s cieľom minimalizovať budúcu prácnosť s aktualizáciou a udržiavaním obsahu.

10.  PRÍLOHY

Doplniť vstupy v  INICIAČNEJ FÁZE:

• V prípade potreby doplniť zoznam príloh

Poznámka: Odporúčame, si evidovať a vyhodnotiť pripomienky odbornej verejnosti

• Podľa §7, odsek 4 – Vyhlášky 85/2020 Z.z – je potrebné zrealizovať pripomienkovanie Projektového prístupu odbornou verejnosťou
• Odporúčame túto aktivitu formalizovať (do dokumentu)
• Odporúčame vyhodnotenie zverejniť na webové sídlo objednávateľa (do projektového adresára) – v súlade s Vyhláškou 85/2020 Zz.

Koniec dokumentu