PROJEKTOVÝ ZÁMER
Vzor pre manažérsky výstup I-02
podľa vyhlášky MIRRI č. 401/2023 Z. z. (účinnosť od 1.4.2025)

Schvaľovanie dokumentu

1. HISTÓRIA DOKUMENTU

2. ÚČEL DOKUMENTU, SKRATKY (KONVENCIE) A DEFINÍCIE

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.
Súbežne sa vyhotovujú dokumenty I-04 Katalóg požiadaviek, M-05 Analýza nákladov a prínosov a M-06 Evidencia komponentov v MetaIS.
Odporúčame, si evidovať a vyhodnotiť pripomienky odbornej verejnosti:

• Podľa § 4 odsek 10 – Vyhláška 401/2023 Z.z. o riadení projektov a zmenových požiadaviek v prevádzke je potrebné zrealizovať pripomienkovanie Projektového zámeru 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 401/2023 Z.z. Oznámenie o začatí verejného pripomienkovania sa zverejní v centrálnom metainformačnom systéme verejnej správy (ďalej len „MetaIS“) na mieste určenom Orgánom vedenia. Na schválenie riadiacemu výboru v prípravnej a iniciačnej fáze sa tieto výstupy predkladajú až po zverejnení vyhodnotenia pripomienok.
  Inštrukcia: Šedý text v celom dokumente predstavuje nápovedu pre vyplnenie dokumentu, po vyplnení kapitol odporúčame text šedou farbou vymazať.
  Dokumenty ukladajte s prefixom I_XX.
  Odporúčame, aby ste si TABUĽKOVÉ VSTUPY  vo formáte EXCEL spravovali v jednom centrálnom súbore s cieľom minimalizovať budúcu prácnosť s aktualizáciou a udržiavaním obsahu.

2.1 Použité skratky a pojmy

Tabuľka 1 Skratky a pojmy

2.2 Konvencie pre typy požiadaviek (príklady)

Zvoľte si konvenciu pre označovanie požiadaviek, súborov, atď. Hlavné kategórie požiadaviek v zmysle katalógu požiadaviek, rozdeľujeme na funkčné (funkcionálne), nefunkčné (kvalitatívne, výkonové a pod.). Podskupiny v hlavných kategóriách je možné rozšíriť podľa potrieb projektu, napríklad:
Funkcionálne (používateľské) požiadavky majú nasledovnú konvenciu:
FRxx

• F – funkcionálna alebo používateľská požiadavka
• R – označenie požiadavky
• xx – číslo požiadavky
  Nefunkčné (kvalitatívne, výkonové - Non Functional Requirements - NFR) požiadavky majú nasledovnú konvenciu:
  NRxx
• N – nefukčná požiadavka (NFR)
• R – označenie požiadavky
• xx – číslo požiadavky
  Ostatné typy požiadaviek môžu byť ďalej definované Objednávateľom/PM.

3. DEFINOVANIE PROJEKTU

3.1 Manažérske zhrnutie

Stručný popis projektu, dôvod jeho realizácie, obsah projektu (vývoj SW, nákup HW/licencie, migrácia do vládneho cloudu a pod.), indikatívna výška finančných prostriedkov určených na realizáciu projektu, prínosy a časový horizont realizácie projektu.
Očakáva sa, že stručne, jasne a štruktúrovane popíšete základné zdôvodnenie, prečo by sa mal projekt realizovať. Vo vašom popise odpovedajte najmä na otázky „Prečo chcete projekt zrealizovať? Čo je predmetom projektu? Pre koho sú výsledky projektu určené? Za akú sumu? Čo to prinesie cieľovej skupine?
V prípade projektov financovaných z európskych fondov je potrebné uviesť zdôvodnenie využitia národného/dopytového projektu, prijímateľa/partnera projektu a dôvod jeho určenia, príslušnosť národného/dopytového projektu k programu a jeho časti a cieľom.

3.2 Motivácia a rozsah projektu

• Popíšte PROBLÉM, ktorý chcete realizáciou projektu odstrániť
• STRUČNE popísať koľko a aké vaše biznis procesy sú predmetom projektu
• Doplniť informácie o OBLASTI (AGENDA / ŽIVOTNÁ SITUÁCIA), ktorým sa projekt venuje
• Doplniť rámcový popis ROZSAHU projektu (subjekty a ISVS, ktorých sa problém a projekt týka)
• Doplniť MOTIVÁCIU na dosiahnutie budúceho stavu a OBMEDZENIA pre dosiahnutie cieľov projektu.
• Môžete doplniť vizualizáciu motivácie pomocou notácie ArchiMate¹.
  
  Obrázok 1 Príklad vizualizácie motivácie pre realizáciu projektu

3.3 Zainteresované strany (Stakeholderi)

• Doplňte KTO (zoznam subjektov/osôb) sa zúčastňuje projektu a akú rolu zastáva

Tabuľka 2 Zainteresované strany (Stakeholderi)

3.4 Ciele projektu

Do tabuliek nižšie doplniť CIEĽ /CIELE PROJEKTU, ich mapovanie na strategické ciele (napr. z NKIVS, KRIT a iných strategických dokumentov) a súvisiace merateľné ukazovatele (KPI- key performance indicators). Ciele musia byť S.M.A.R.T. - konkrétne, merateľné, dosiahnuteľné, relevantné, časovo ohraničené.
V prípade financovania cez zdroje EÚ uvádzať aj špecifické ciele zdroja financovania (programu alebo jeho časti a výzvy).

Tabuľka 3 Ciele projektu

3.5 Merateľné ukazovatele (KPI)

Tabuľka 4 Merateľné ukazovatele (KPI)

Vysvetlivky k vyplneniu tabuľky:

• Vzory merateľných ukazovateľov pre projekt sú publikované v Checkliste pre agendu Merateľné ukazovatele/KPI (https://www.mirri.gov.sk/sekcie/informatizacia/riadenie-kvality-qa/riadenie-kvality-qa/index.html )
• AS IS merateľné ukazovatele – t. j. popíšte, aké merateľné ukazovatele máte teraz (vpíšte výsledky meraní – v merateľných jednotkách) .
• TO BE merateľné ukazovatele – t. j. popíšte cieľové merateľné ukazovatele, ktoré chcete dosiahnuť.
• Odporúčame, aby váš budúci IS mal automatizovaný monitoring (na pravidelnej báze, napr. týždenne) vami stanovených merateľných ukazovateľov – s cieľom, aby ste mohli riadiť službu, produkt, proces, ľudí
• V prípade financovania cez zdroje EÚ uvádzať aj Projektové merateľné ukazovatele z programu alebo jeho časti a výzvy (špecifické ciele, merateľné ukazovatele atď.).

3.6 Špecifikácia potrieb koncového používateľa

Táto časť sa týka projektov, ktoré sú zamerané na vývoj alebo rozvoj  ISVS/s elektronickými službami , ktoré  majú grafické alebo iné používateľské rozhranie a sú určené pre občanov/podnikateľov (alebo aj pracovníkov verejnej správy pracujúcich s agendovým systémom), ďalej označených ako koncoví používatelia. 

• Špecifikácia požiadaviek koncových používateľov musí byť v súlade s legislatívou (s aktuálne platnou alebo s návrhom jej zmien ako súčasť projektu) a postupmi pri vytváraní elektronických služieb verejnej správy, ako sú napríklad používateľský prieskum, mapovanie používateľskej cesty, vytváranie informačnej architektúry a testovanie prototypov podľa vyhlášky 547/2021 Z. z. o elektronizácii agendy verejnej správy.
• Definujte skupiny koncových používateľov elektronických služieb a popísať cieľové skupiny koncových používateľov, vrátane sociodemografických charakteristík cieľových skupín alebo účastníkov používateľského prieskumu. Príklad definície skupín koncových používateľov, tzv. persón nájdete v metodike pre tvorbu používateľsky kvalitných elektronických služieb (Metodika pre tvorbu používateľsky kvalitných elektronických služieb).
• Špecifikujte potreby resp. ciele koncových používateľov (ideálne formou tzv.  používateľského príbehu) ktoré identifikujú, čo jednotlivé skupiny koncových používateľov od elektronickej  služby požadujú.  Ak ide o zmenu (upgrade) elektronickej služby, ktorá už existuje, dajú sa ciele  koncových používateľov kvantitatívne odmerať: 
  • ako sa koncovým používateľom svoje potreby (resp. ciele) darí napĺňať (performance indikátory) - napr. priemerný čas pre naplnenie potreby, miera chybovosti, miera dokončenia, pomer online/offline transakcií, 
  • ako sú koncoví používatelia (ne)spokojní s existujúcou  elektronickou službou (Net Promoter Score, Customer effort Score, customer satisfaction....),
• Pri rozvoji existujúcej elektronickej služby je možné použiť výstupy zo zisťovania spätnej väzby k elektronickej službe, ak z nich vyplývajú požiadavky koncových používateľov na rozvoj služby.  
• Ak ide o vytváranie novej koncovej služby, realizuje sa používateľský prieskum spravidla metódou kvalitatívneho prieskumu (formou štruktúrovaného rozhovoru alebo dotazníka, ktorého cieľom je pomenovať základné ciele/potreby koncových používateľov) a očakávania od kvality a funkcionalít plánovanej elektronickej služby (odkaz návod (v angličtine): Ako vybrať vhodnú metódu používateľského prieskumu).
• Priložte Report zákazníckeho prieskumu ako prílohu Projektového zámeru,  ktorý popíše priebeh a metódy prieskumu, základné kvantitatívne ukazovatele, veľkosť vzorky atď. 
• Doplňte Katalóg požiadaviek (funkčné, nefunkčné) o priorizované požiadavky z používateľského prieskumu v dokumente M-05 Analýza nákladov a prínosov, karta Katalóg požiadaviek I-04 Katalóg požiadaviek.

3.7 Detailný opis obmedzení a predpokladov

Uveďte známe vymedzenie rozsahu projektu, dôvodov pre vymedzenie rozsahu projektu a predpokladov, ktoré by mali byť splnené pre úspešnú realizáciu projektu

3.8 Vyhodnotenie rizík a závislostí

Doplňte/stručne popíšte RIZIKÁ a ZÁVISLOSTI projektu. Detailné vyhodnotenie a sledovanie rizík udržujte a aktualizujte počas celej realizácie projektu v prílohe ZOZNAM RIZÍK a ZÁVISLOSTI. Šablóna súboru prílohy Zoznam rizík a závislostí (XLSX, 15 kB) je publikovaná na stránke Riadenie kvality (QA) (odkaz na stránku: https://mirri.gov.sk/sekcie/informatizacia/riadenie-kvality-qa/riadenie-kvality-qa/ )
V prípade projektov financovaných zo zdrojov EÚ je povinné vyhodnotenie rizík súvisiacich s:

• Realizáciou verejného obstarávania (t.j. napr. pred vyhlásením VO bude dopad na projekt Fatálny, ak má Objednávateľ už uzatvorenú dodávateľskú zmluvu, bude dopad nevýznamný a pod...)
• Legislatívou: vyhodnotiť potrebu zmeny legislatívy (ak je potrebné prijať nový zákon tak bude dopad Fatálny)
• Časovým priebehom: ak je harmonogram realizácie naplánovaný do konca roka 2023, tak bude dopad Fatálny.
  V nasledovnej tabuľke uveďte prehľad najzávažnejších rizík a závislostí:

Tabuľka 5 Prehľad najzávažnejších rizík a závislostí

3.9 Detailný opis rozpočtu projektu a jeho prínosov

Počas Prípravnej a iniciačnej fázy, je potrebné predložiť samostatný dokument M-05 Analýza nákladov a prínosov (xls. BC/CBA) v predpísanej štruktúrovanej forme.(povinné v prípade projektov nad 1 000 000,- EUR). Pre iný, než veľký projekt - projekt pod 1 000 000,- EUR - Objednávateľ detailne opíše nákladovú a prínosovú stránku a postup, ktorý je zvolený na cenovú kalkuláciu nákladov a prínosov projektu.
V tejto časti dokumentu sa od Vás očakáva štruktúrovane popísať:

• vypočítané náklady (vývoj + prevádzka) v T10 (t.j. na 10 rokov dopredu)
• vypočítané prínosy v T10 (t.j. na 10 rokov dopredu)
• slovne popísať výpočet prínosov, z čoho sú čerpané vstupné hodnoty
• rok návratnosti (doplnenie ukazovateľov: ENPV, FNPV, BCR)

3.9.1 Sumarizácia nákladov a prínosov

Uveďte prehľad nákladov a prínosov vychádzajúci z dokumentu M-05 Analýza nákladov a prínosov

Tabuľka 6 Sumarizácia nákladov a prínosov

Interpretácia výsledkov:
Ekonomická a finančná efektívnosť projektu je v analýze prínosov nákladov hodnotená kvantitatívne pomocou nasledujúcich ukazovateľov (prahové hodnoty v zmysle platných dokumentov v prípade financovania zo zdrojov EÚ sú uvedené):

• Pomer prínosov a nákladov (BCR): viac ako 1,00
• Ekonomická vnútorná výnosová miera vyjadrená v % (EIRR): viac ako 5,0 %
• Ekonomická čistá súčasná hodnota vyjadrená v eurách (ENPV): viac ako 0
  Pre účely financovania z prostriedkov EU vyjadruje Analýza nákladov a prínosov BC/CBA aj nasledovné ukazovatele:
• Finančná vnútorná výnosová miera v % (FIRR)
• Finančná čistá súčasná hodnota v eur (FNPV).
  Nie všetky sociálno-ekonomické vplyvy sa dajú vždy vyčísliť a zhodnotiť. Je to preto, že okrem odhadu ukazovateľov výkonnosti by sa mala zohľadniť aj úvaha o nepeňažných nákladoch a výnosoch, najmä vo vzťahu k týmto otázkam: (čistý) dosah na zamestnanosť, ochrana životného prostredia, sociálna rovnosť a rovnaké príležitosti.
  V prípade ak dosiahnu uvedené hodnoty viaceré varianty posudzované v rámci Analýzy nákladov, odporúča sa pri výbere finálnej alternatívy zohľadniť výšku BCR, dôležitosť nekvantifikovaných spoločenských prínosov a mieru naplnenia stanovených cieľov. Po vzore krajín ako Veľká Británia sa prioritne odporúča realizovať projekty, kde prínosy prevyšujú náklady štvornásobne (BCR aspoň 4,00).
  Príklad: Kvalitatívne prínosy projektov
  Problém: Proces získania stavebného povolenia jeden z najdlhších v EÚ.
  Príklady kvalitatívnych prínosov projektu, ktoré je možné finančne oceniť:
• Zvýšenie ekonomickej aktivity v stavebnom sektore (zvýšenie rastu HDP)
• Nižšie spoločenské škody, spojené s búraním čiernych stavieb
  Príklady kvalitatívnych prínosov projektu, ktoré nie je možné spoľahlivo finančne oceniť:
• Zníženie miery korupcie
• Zníženie miery stresu zamestnancov stavebných úradov
  Vyššia spokojnosť verejnosti s procesmi územného a stavebného konania.

3.9.2 Zdroj financovania

Uveďte uvažovaný zdroj financovania: Štátny rozpočet, Európske štrukturálne a investičné fondy: program, výzva/národný projekt.

3.10 Harmonogram projektu

Doplňte vysokoúrovňový HARMONOGRAM, ktorý sa neskôr (v ďalších fázach/dokumentoch) bude detailizovať:

• KEDY potrebujete (chcete) ZAČAŤ? Napíšte TERMÍN (mesiac/rok)
• KEDY potrebujete (chcete) SKONČIŤ (mať dodaný výstup)? Napíšte TERMÍN (mesiac/rok).
• Fakturačné míľniky: jednotlivé míľniky projektu naviažte aj na fakturačné míľniky (v jednej tabuľke), aby ste si mohli kontrolovať cashflow v projekte.
• Míľniky Verejného obstarávania (VO) – do harmonogramu si doplňte aj míľnik procesu verejného obstarávania (celý proces).

Odporúčame – pre reportovacie účely projektu si vytvorte high-level projektový plán v MS EXCEL alebo v inom formáte/nástroji pre projektové riadenie.
Doplňte informácie o vybranej metóde riadenia projektu a zdôvodniť výber:
Ak realizujete projekt metódou Waterfall:
Waterfall - vodopádový prístup počíta s detailným naplánovaním jednotlivých krokov a následnom dodržiavaní postupu pri vývoji alebo realizácii projekty. Projektovému tímu je daný minimálny priestor na zmeny v priebehu realizácie. Vodopádový prístup je vhodný a užitočný v projektoch, ktorý majú jasný cieľ a jasne definovateľný postup a rozdelenie prác.

Obrázok 2 Ilustrácia rozdelenia realizácie projektu metódou Waterfall
Ak realizujeme projekt metódou Agile:
Agilný prístup k riadeniu projektov sa uplatňuje v projektoch, u ktorých je jasný rámcový cieľ, ale z najrôznejších dôvodov je nemožné presne definovať všetky dlhodobé požiadavky bez priebežných prototypov. Pri agilných metódach práce sa realizujú malé porcie výsledkov v každom vývojovom cykle, iterácii, v tesnej spolupráci so zákazníkom. Agile metódu je možné aplikovať za podmienok definovaných vo vyhláške MIRRI č. 401/2023 Z.z. o riadení projektov a zmenových požiadaviek v prevádzke.

Obrázok 3 Ilustrácia iteratívneho spôsobu realizácie projektu Agilnou metódou

3.11 Návrh organizačného zabezpečenia projektu (projektový tím)

Popíšte návrh organizačného zabezpečenia projektu: návrh zloženia Riadiaceho výboru a Projektového tímu za realizátora projektu (Objednávateľa, Vlastníka projektu)
Uveďte návrh personálneho obsadenia pre Riadiaci výbor (RV) realizátora projektu minimálne v nasledovnom zložení:

• Predseda RV
• Biznis vlastník
• Zástupca prevádzky
• Projektový manažér realizátora projektu (Objednávateľa) (PM)
  Uveďte návrh personálneho obsadenia pre Projektový tím realizátora projektu:
• kľúčový používateľ,
• IT analytik alebo biznis analytik,
• IT architekt,
• biznis vlastník
• manažér kvality (nepovinný člen pre projekty do 1 000 000,- EUR, povinný pri veľkých projektoch nad 1 000 000,- EUR,
• manažér IT prevádzky (nepovinný člen)
• manažér kybernetickej a informačnej bezpečnosti (nepovinný člen)
• UX dizajnér (nepovinný člen)
• iná špecifická rola (nepovinný člen)
  Pre návrh organizačného zabezpečenia vyplňte tabuľku zodpovedných osôb, ktoré budú participovať v projekte:

Tabuľka 7 Projektový tím

4. LEGISLATÍVA

Doplňte popis potrebných zmien v oblasti legislatívy pre naplnenie cieľov a dodanie výstupov projektu.
Uveďte konkrétne zákony, prípadne aj paragrafy, ktoré budú predmetom legislatívnych zmien.
Doplňte popis, aký je negatívny dopad na výstupy projektu, jeho ciele a rozsah a časový harmonogram, ak vyššie uvedené zmeny v zákonoch nebudú realizované.

5. ARCHITEKTÚRA RIEŠENIA PROJEKTU

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í alebo rozvoji ISVS (vrátane mobilnej aplikácie ako typu ISVS) navrhujete všetky vrstvy architektúry (biznis, aplikačná, technologická), pri nákupe HW alebo migrácii systému na infraštruktúrne cloudové služby nie je potrebné popisovať detailne biznis a aplikačnú vrstvu architektúry, postačuje v príslušných kapitolách uviesť len nevyhnutné detaily popisujúce dopad projektu v týchto vrstvách, aby príslušné zainteresované osoby mohli vyhodnotiť, akým spôsobom ich projekt zmeny infraštruktúry ovplyvní.
Pred uvedením a detailným popisom zvoleného navrhovaného riešenia urobte vyhodnotenie alternatív riešenia pre každú vrstvu architektúry.
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 (M-05 Analýza nákladov a prínosov - BC/CBA, karta: Katalóg požiadaviek, I-04 Katalóg požiadaviek).
Obsah tejto kapitoly je tiež prehľadom realizácie výstupu M-06 - aktualizácia evidencie e-Government komponentov v MetaIS. Objednávateľ³ plní výstupom M-06 povinnosti orgánu riadenia sprístupňovať a aktualizovať informácie o informačných technológiách verejnej správy prostredníctvom MetaIS bezodkladne podľa § 12 ods. 1 písm. b) zákona č. 95/2019 Z.z.
Objednávateľ priebežne aktualizuje evidenciu e-Government komponentov v MetaIS, vrátane architektonických modelov. Pri odovzdaní výstupu I-02 Projektový zámer objednávateľ v rámci výstupu M-06 Evidencia e-Government komponentov v MetaIS:

• vytvorí náhľady architektúry v modelovacom nástroji, ktorý môže byť buď integrovaný na spoločný repozitár  architektonických modelov verejnej správy⁴, alebo ktorý podporuje export modelu do štandardizovaných výmenných formátov súborov,
• uloží architektonické modely súčasnej a budúcej architektúry riešenia buď do repozitára architektonických modelov verejnej správy alebo vo výmennom formáte pre uloženie modelu⁵do projektovej dokumentácie v MetaIS alebo ako prílohu k dokumentu I-02 Projektový zámer, 
• aktualizuje v MetaIS e-Government komponenty, ktoré budú realizované alebo menené projektom alebo veľkou zmenovou požiadavkou a to koncové služby, ISVS, ich moduly, aplikačné služby, atribúty a vzájomné vzťahy týchto e-Government komponentov a ich vzťahy (integrácie) na spoločné ISVS alebo ISVS iných správcov, ktoré budú využívať. 
  Orgán vedenia vyhodnotí náležitosti výstupu I-02 a M-06 v súlade s prílohou č. 2 vyhlášky MIRRI č. 401/2023 Z.z.
  Vyžadujeme, aby návrh architektúry bol zakreslený pomocou modelovacieho jazyka Archimate minimálne vo verzii 3 (linka 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 MetaIS (aktuálna verzia je zverejnená na:https://metais.slovensko.sk/howto/MetaIS_HELP) pre popis, modelovanie a zápis informácií o komponentoch do MetaIS.
  Pre detailnejší popis procesov, ktorých sa projekt týka je možné použiť tiež modelovací jazyk BPMN (ISO 19510) a modelovací nástroj, ktorý podporuje tento jazyk a export súborov podľa špecifikácie BPMN 2.0.⁷) Pre analýzu a modelovanie procesov využite metodiky optimalizácie procesov MV SR pripravené v rámci projektu Optimalizácia procesov vo verejnej správe: https://www.minv.sk/?np-optimalizacia-procesov-vo-verejnej-sprave.
  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 architektúru riešenia a e-Government komponenty, ktoré majú byť predmetom dodávky projektu, ako aj ich vzťahy a závislosti navzájom a vzťahy na ostatné komponenty architektúry verejnej správy (napr. spoločné moduly ústredného portálu verejnej správy, iné vlastné alebo externé ISVS, služby alebo dátové registre).
  
  Obrázok 4 Celkový prehľad metamodelu Archimate pre verejnú správu a evidencie eGovernment komponentov v METAS (tento obrázok inštrukcie odstráňte)

5.1 Stanovenie alternatív architektúry riešenia

Výber alternatív architektúry riešenia prebieha v dvoch kolách. Prvé kolo predstavuje uplatnenie multikriteriálnej analýzy (ďalej len „MCA“) – výber relevantných alternatív. Druhé kolo predstavuje vypracovanie Analýzy nákladov M-05 BC/CBA. Do druhého kola vstupujú alternatívy ktoré splnili všetky vylučovacie kritéria stanovené v multikritériálnej analýze. Minimálny počet variant, je stanovený na 3:

• nulový variant, ktorý sa neposudzuje v MCA a je automaticky porovnávajúcim variantom v M-05 Analýza nákladov a prínosov,
• preferovaný variant, ktorý splnil všetky kritéria MCA,
• „minimalistický variant“, ktorý vychádza z rovnakého biznis variantu ako preferovaný variant, ale realizuje iba „nutné“ aplikačné moduly.
  Ako alternatívu nepovažujeme porovnanie krabicových „off-the-shelf“ riešení (COTS) riešení s alternatívou vývoja aplikácií „na zelenej lúke“ a to z dôvodu toho, že žiadateľ pre zachovanie nediskriminačných podmienok vo verejnom obstarávaní nevie vopred určiť, či dostane ponuku od uchádzača k vývoju na zelenej lúke, alebo sa všetky ponuky od uchádzačov vo verejnom obstarávaní budú vzťahovať na COTS riešenie. Výnimka je v prípade, ak žiadateľ uvažuje použiť konkrétne COTS riešenie ako podmienku pre uchádzača v rámci procesu verejného obstarávania a to vzhľadom na ekonomické alebo iné dôvody preukázané v dokumente.

5.1.1 Stanovenie alternatív v biznisovej vrstve architektúry

Na základe identifikovaného rozsahu problému navrhujete v projektovom zámere rôzne riešenia biznis procesov (podmnožiny problému). Alternatíva môže pokrývať procesy všetkých stakeholderov (zainteresované strany) alebo iba vybraných, celú životnú situáciu alebo len časť. Na úrovni stanovenia alternatívy je budúci stav biznis procesov popísaný rámcovo, pri zúžení alternatív na tie, ktoré vstupujú do CBA konkrétne.

Obrázok 5 Znázornenie alternatív riešenia v biznis vrstve architektúry
Výber alternatív na úrovni biznis vrstvy prebieha prostredníctvom Multikriteriálnej analýzy (MCA) zostavenej na základe kapitoly Motivácia, ktorá obsahuje ciele stakeholderov, ich požiadavky a obmedzenia pre dosiahnutie uvedených cieľov.
Niektoré (nie všetky) kritériá môžu byť označené ako KO kritériá. KO kritériá označujú biznis požiadavky na riešenie, ktoré sú z hľadiska rozsahu identifikovaného problému a motivácie nevyhnutné pre riešenie problému a všetky akceptovateľné alternatívy ich tak musia naplniť. Alternatívy, ktoré nesplnia všetky KO kritériá, môžu byť vylúčené z ďalšieho posudzovania. KO kritériá nesmú byť technologické (preferovať jednu formu technologickej implementácie voči druhej).

Tabuľka 9 Príklad šablóny pre vyhodnotenie MCA

5.1.2 Stanovenie alternatív v aplikačnej vrstve architektúry

Alternatívy na úrovni aplikačnej architektúry reflektujú alternatívy vypracované na základe „nadradenej“ architektonickej biznis vrstvy, pričom vďaka uplatneniu nasledujúcich princípov aplikačná vrstva architektúry dopĺňa informácie k alternatívam stanoveným pomocou biznis architektúry.
Pre klasifikáciu alternatív za účelom ďalšieho porovnania aplikačnej vrstvy a architektúry je potrebné zadefinovať nasledovné požiadavky:

• Nutné – aplikačné moduly/funkcionality, ktoré sú nevyhnutné pre dosiahnutie cieľov
• Preferované – aplikačné moduly/funkcionality, ktoré rozvíjajú biznis alternatívu a vytvárajú dodatočné prínosy, započítané v Analýze nákladov a prínosov M-05 (BC/CBA povinná pre projekty nad 1 000 000,- EUR)
• Aplikačná vrstva by mala byť schopná rozdeliť moduly do skupín podľa koncových služieb/funkcionalít, ktoré plnia nutné a preferované požiadavky.
  
  Obrázok 6 Znázornenie alternatív riešenia v aplikačnej vrstve

5.1.3 Stanovenie alternatív v technologickej vrstve architektúry

Alternatívy na úrovni technologickej architektúry reflektujú alternatívy vypracované na základe „nadradenej“ architektonickej aplikačnej vrstvy, pričom sa prioritne uvažuje o využití služieb vládneho cloudu (privátne aj verejné cloudové služby zverejnené v katalógu služieb vládneho cloudu, odkaz na katalóg služieb).
Pred výberom alternatív v technologickej vrstve je potrebné urobiť si klasifikáciu informačných systémov a samostatne nasadzovaných modulov, ktoré budú predmetom riešenia podľa výsledku analýzy alternatív v aplikačnej vrstve. Klasifikácia pomôže riešiteľovi pri výbere alternatív riešenia technologickej vrstvy architektúry a výbere vhodnej skupiny cloudových služieb pre samostatne nasaditeľné moduly riešenia a využití najvhodnejšej kombinácie hybridného cloudového riešenia.
Klasifikáciu urobte podľa Metodického usmernenia pre klasifikáciu ISVS  (023107/2023/oSBATA-1) (odkaz na usmernenie 023107/2023/oSBATA-1: https://mirri.gov.sk/sekcie/informatizacia/dokumenty/vladny-cloud/metodicke-usmernenia/)

Tabuľka 10 Klasifikácia budovaných informačných systémov

V prípadoch, kedy by nebolo ekonomicky výhodné využiť služby z katalógu služieb vládneho cloudu v plnom rozsahu projektu, je možné uvažovať aj o iných/ďalších alternatívach: hybridnej (časť aplikácií využíva privátny vládny cloud a časť vlastný HW žiadateľa, resp. časť aplikácii využíva služby komerčného poskytovateľa cloudových služieb), nasadenie v prostredí komerčného cloudu alebo v krajnom prípade sú všetky aplikácie nasadené v prostredí vlastného HW žiadateľa (prípady zohľadnenia bezpečnosti alebo iných povinností).
Ekonomická výhodnosť technologickej alternatívy je preukázaná nižšími nákladmi na TCO projektu. Spracovateľ projektového zámeru je povinný preukázať, že zvolené riešenie je ekonomicky výhodnejšie. V prípade, že z bezpečnostných alebo iných dôvodov nezvolil najvýhodnejšiu alternatívu (resp. neposudzoval viacero alternatív), spracovateľ doloží zdôvodnenie potreby daného technologického riešenia. V zdôvodnení sú uvedené konkrétne požiadavky a ich parametre, ktoré neumožnili zvoliť najvýhodnejšie riešenie alebo porovnať viacero alternatív.

Obrázok 7 Znázornenie alternatív riešenia v technologickej vrstve

5.2 Náhľad architektúry a popis budúceho cieľového produktu

• Uveďte krátky POPIS BUDÚCEHO CIEĽOVÉHO PRODUKTU PROJEKTU z pohľadu biznis/aplikačnej/technologickej architektúry v závislosti od charakteru projektu a výsledku analýzy alternatív riešenia,
• Doplňte a detailne spracujte funkčné a nefunkčné požiadavky vyplývajúce z analýz alternatív riešenia vo všetkých vrstvách architektúry a vyplňte požiadavky v dokumente  M-05 Analýza nákladov a prínosov, karta Katalóg požiadaviek., I-04 Katalóg požiadaviek
• Doplňte stručný náhľad budúcej IT architektúry (biznis, aplikačná, technologická) riešenia, ktorý podľa potreby pozostáva aj z viacerých obrázkov (diagramov), aby dostatočne zrozumiteľne znázornil predmet dodávky, jeho kontext a zmeny v architektúre verejnej správy (objednávateľa, realizátora projektu), ktoré projekt realizuje,
  • Náhľad architektúry vytvorte v modelovacom nástroji pomocou notácie ArchiMate (https://publications.opengroup.org/standards/archimate), v prípade potreby väčšej detailizácie biznis procesov môžete použiť notáciu BPMN (http://www.omg.org/spec/BPMN/2.0/),
  • Pre vytvorenie náhľadu architektúry použite modelovací nástroj, ktoré môže byť buď integrovaný na spoločný repozitár⁸ architektonických modelov verejnej správy, alebo modelovací nástroj, ktorý podporuje export modelu do štandardizovaných výmenných formátov súborov (The Open Group ArchiMate Model Exchange File Format Standard) ⁹ a export súborov podľa špecifikácie BPMN 2.0¹⁰,
  • Pre jednoznačnú identifikovateľnosť komponentov v náhľade architektúry uveďte aj ich MetaIS kódy.
  • Očakáva sa, že ak realizujete popis dizajn procesov podľa pravidiel EVS, tak všetky výstupy musia byť v súlade s metodikou a postupom: https://www.minv.sk/?np-optimalizacia-procesov-vo-verejnej-sprave&subor=255448 .
  • Náhľad architektúry v tomto výstupe I-02 Projektový zámer by mal byť v súlade
    • s jeho detailizáciou v nasledujúcich kapitolách popisujúcich obsah realizácie projektu v biznis, aplikačnej, dátovej a technologickej vrstve architektúry.
    • s výstupom M-06 - aktualizáciou evidencie e-Government komponentov v MetaIS a komponenty, ktorých sa projekt týka, by mali mať upravenú evidenciu ich stavu a fázu ich životného cyklu v MetaIS.
      
      Obrázok 8 Príklad náhľadu celkovej architektúry v notácii ArchiMate
      
      Obrázok 9 Príklad náhľadu architektúry v notácii ArchiMate s hlavnými e-Government komponentami a ich vzťahmi podľa metamodelu evidencie eGovernment komponentov v MetaIS

5.3 Biznis vrstva

V tejto kapitole urobte detailnejšie rozpracovanie zvolenej alternatívy riešenia v biznis vrstve architektúry. Uveďte prehľad e-Government komponentov – Koncových služieb, ktoré budú výstupom projektu (dodané nové alebo zmenené) a ktoré sú zaevidované v MetaIS v rámci výstupu M-06.

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

Popíšte návrh riešenia v biznis vrstve architektúry:
Popis súčasného - AS IS - stavu biznis vrstvy:

• V popise treba zvážiť potrebný rozsah popisu súčasnej architektúry. Zvolený rozsah popisu súčasného stavu by mal byť uvedený v takom dostatočnom rozsahu, ktorý je potrebný na znázornenie a popis dôvodov na realizáciu projektu a popis rozdielov medzi súčasným (As-Is) a budúcim (navrhovaným – TO BE) riešením.
• Identifikujte kľúčové životné situácie (ŽS), Koncové služby (KS), biznis služby a procesy, ktorých sa projekt týka. Zamerajte sa hlavne na tie prvky biznis architektúry, ktoré predstavujú väčšinu ekonomických nákladov občanov/podnikateľov a nákladov úradov a ktoré boli predmetom vyhodnotenia v Analýze nákladov a prínosov - BC/CBA.
• Identifikujte existujúce Koncové služby, ktorých sa projekt týka. Skontrolujte, či sú evidované v MetaIS a ich popis zodpovedá aktuálnemu stavu. Ak ich názov a popis nezodpovedá aktuálnemu alebo cieľovému stavu, opravte a doplňte ich evidenciu v MetaIS.
• Identifikujte procesy, ktoré sú v súčasnom stave potrebné pre vyriešenie dotknutých ŽS, poskytnutie koncovej služby alebo dôležitej biznis služby pre pracovníkov Objednávateľa.
• Uveďte Optimalizačné príležitosti, ktoré popisujú možné zlepšenia vo výkone existujúcich procesov, ich podpore informačnými technológiami a prípadne v organizačnom zabezpečení výkonu procesov.
  Popis budúceho - TO BE - stavu biznis vrstvy:
• Doplňte popis a výstižné grafické znázornenia TO BE stavu navrhovaného riešenia vybraného na základe MCA (Multikriteriálna analýza) popísanej v Projektovom zámere. Navrhované riešenie musí korešpondovať s procesnými diagramami a musí popisovať spôsob dosiahnutia a monitoringu prínosov uvedených v CBA.
• Uveďte a znázornite popis zmien medzi súčasným a budúcim stavom navrhovaného riešenia, tzv. Rozdielovú (GAP) analýzu.
• Popis biznis architektúry musí obsahovať minimálne vrcholové pohľady na zmeny biznis architektúry s mapovaním na eGovernment komponenty (v biznis vrstve hlavne Koncové služby, Životné situácie Agendy) a hlavné procesy a biznis služby (pre pracovníkov Objednávateľa), ktoré budú projektom dotknuté a zmenené.
• Do tabuľky prehľadu Koncových služieb uveďte všetky projektom budované/rozvíjané koncové služby, ktoré budú výstupom projektu (súčasť výstupu M-06). Tieto koncové služby musia mať v MetaIS evidované:
  • fázu životného cyklu Plánovaná,
  • všetky povinné atribúty a vzťahy,
  • SLA parametre pre východiskový a cieľový stav.
    Podrobné informácie sú uvedené v Používateľskej príručke MetaIS: https://metais.slovensko.sk/howto/MetaIS_HELP
• Uveďte Ukazovatele a Metriky dôležité pre vyhodnotenie aktuálneho stavu a pre vyhodnotenie dosiahnutia cieľov projektu a vyhodnotenie úrovní poskytovania služieb, napr.:
  • aktuálne a očakávané počty podaní (interakcií, návštev úradov) pre jednotlivé kroky a životné situácie,
  • aktuálne a očakávané časy trvania jednotlivých krokov v procese vybavenia ŽS,
  • aktuálne a očakávané finančné príjmy, spojené s jednotlivými procesnými krokmi (správne poplatky, prípadné pokuty a sankcie),
  • aktuálne a 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).
• Do Katalógu požiadaviek zapíšte požiadavky na monitoring a spracovanie výstupov potrebných na získanie a vyhodnotenie Ukazovateľov a Metrík, pre vyhodnotenie dosiahnutia cieľov projektu a vyhodnotenie úrovní poskytovania služieb.
  
  Obrázok 10 Príklad znázornenia biznis architektúry TO BE a GAP (aktéri-koncoví používatelia, koncové služby, procesy)

5.3.2 Prehľad koncových služieb – budúci stav (TO BE):

V nasledujúcej tabuľke uveďte prehľad budovaných a rozvíjaných Koncových služieb. Údaje o koncových službách treba zapísať do MetaIS ako súčasť výstupu M-06.

Tabuľka 11Prehľad koncových služieb - budúci stav (TO BE)

Požiadavky na realizáciu a zmenu Koncových služieb zapíšte aj do Katalógu požiadaviek.

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

• Popíšte očakávané organizačné dopady navrhovaného riešenia: presun zodpovedností a služieb org. jednotiek, vytvorenie alebo zlúčenie organizačných jednotiek, zapojenie iných organizačných jednotiek, atď.
• Stručne zosumarizujte (napr. tabuľkovým spôsobom), ktoré procesy budú projektom dotknuté a či sú predmetom projektu z operačného programu Efektívna Verejná Správa (EVS) - Národného projektu Optimalizácia procesov vo verejnej správe (https://www.minv.sk/?np-optimalizacia-procesov-vo-verejnej-sprave). Ak áno, tak postup procesnej analýzy by mal byť v zmysle metodiky pre EVS.
• Procesné diagramy, ktoré popisujú postupnosť krokov, komunikácie a zodpovedností, ktoré budú potrebné pre vyriešenie každej dotknutej ŽS alebo poskytnutie koncovej služby by mali byť 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).
• Ak procesné diagramy popisujú použitie Koncových služieb a využitie existujúcich alebo plánovaných informačných systémov (či už znázornených ako aktivity, aktéri procesov (plavebné dráhy) alebo ako dátové úložiská) uveďte ich názvy a kódy evidované v MetaIS, aby bolo možné jednoznačnejšie identifikovať eGovernment komponenty dotknuté projektom.
  
  Obrázok 11 Príklad detailnejšieho znázornenia procesov pomocou BPMN notácie

5.3.4 Jazyková podpora lokalizácia

• Uveďte a do Katalógu požiadaviek zaevidujte požiadavky na jazykovú podporu a lokalizáciu používateľského rozhrania a výstupov do viacerých jazykov v riešení TO BE stavu.
• Uveďte, či služby budú poskytované pre používateľov z členských štátov EÚ alebo z iných krajín a hlavné požiadavky, ktoré musí projekt realizovať, aby boli služby poskytované pre týchto používateľov. Požiadavky uveďte aj do Katalógu požiadaviek.

5.4 Aplikačná vrstva

V tejto kapitole urobte detailnejšie rozpracovanie zvolenej alternatívy riešenia v aplikačnej vrstve architektúry.
Uveďte prehľad e-Government komponentov – Aplikačných služieb, Informačných systémov a ich podsystémov a ich vzájomných vzťahov, ktoré budú výstupom projektu (dodané nové alebo zmenené) a ktoré sú zaevidované v MetaIS v rámci výstupu M-06 (Evidencia e-Government komponentov v MetaIS).
V prehľade uveďte a v MetaIS v rámci výstupu M-06 evidujte aj vzťahy Aplikačných služieb, ktoré budú slúžiť Koncovým službám. Taktiež uveďte Aplikačné služby poskytované na externú integráciu a tiež konzumné integračné Aplikačné služby a ich vzťahy na poskytované služby iných systémov, hlavne spoločných modulov.

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

Popíšte návrh riešenia v aplikačnej vrstve architektúry:
Popis súčasného - AS IS - stavu aplikačnej vrstvy:

• V popise treba zvážiť potrebný rozsah popisu súčasnej architektúry. Zvolený rozsah popisu súčasného stavu by mal byť uvedený v takom dostatočnom rozsahu, ktorý je potrebný na znázornenie a popis rozdielov medzi súčasným (As-Is) a budúcim (navrhovaným – TO BE) riešením.
• Uveďte znázornenie modelu a popis AS IS stavu aplikačnej vrstvy architektúry: informačné systémy (ISVS), aplikačné služby a ich podpora koncových služieb a súčasné integrácie s externými systémami a spoločnými modulmi.
• Identifikujte existujúce informačné systémy a aplikačné služby, ktorých sa projekt týka. Skontrolujte, či sú evidované v MetaIS a ich popis a vzťahy zodpovedajú aktuálnemu stavu. Ak ich názov, popis a vzťahy nezodpovedajú aktuálnemu alebo cieľovému stavu, opravte a doplňte ich evidenciu v MetaIS.
• Identifikujte existujúce Koncové služby a ich podporu Aplikačnými službami. Skontrolujte, či pre je pre každú Koncovú službu známy a evidovaný vzťah s Aplikačnou službou, ktorá jej slúži. Ak vzťahy medzi Aplikačnou službou a Koncovou službou nezodpovedajú aktuálnemu alebo cieľovému stavu, opravte a doplňte ich evidenciu v MetaIS.
• Podrobné informácie k evidencii eGovernment komponentov sú uvedené v Používateľskej príručke MetaIS ( https://metais.slovensko.sk/howto/MetaIS_HELP )
  Popis budúceho - TO BE - stavu aplikačnej vrstvy:
• Uveďte znázornenie modelu a popis TO BE stavu navrhovaného riešenia aplikačnej vrstvy architektúry s prepojením na biznis vrstvu architektúry – ako aplikačná architektúra a jej komponenty podporuje realizáciu biznis služieb (Koncových služieb), riešenia živ. situácií, realizáciu a digitálnu transformáciu procesov a splnenie cieľov projektu.
• Uveďte a znázornite popis zmien medzi súčasným a budúcim stavom navrhovaného riešenia, tzv. Rozdielovú (GAP) analýzu.
• Popis aplikačnej architektúry musí obsahovať minimálne vrcholové pohľady na zmeny aplikačnej architektúry s mapovaním na eGovernment komponenty (v aplikačnej vrstve hlavne Aplikačné služby, Informačné systémy) a ich vzťahov na biznis vrstvu (aplikačné služby a informačné systémy slúžia koncovým službám a biznis procesom) a externé informačné systémy a ich moduly.
• Pre znázornenie internej štruktúry a funkčnosti budovaných informačných systémov pomocou modelovacieho jazyka Archimate použite radšej elementy typu „Application funcion“ namiesto „Application component“, pretože „Application component“ je používaný pre znázornenie samostatne nasadzovaného implementovaného informačného systému alebo jeho samostatne nasadzovaného alebo zdieľaného modulu (napr. web servera, integračného servera, atď.), ktorý by mal byť evidovaný v MetaIS.
• Do tabuliek prehľadov informačných systémov, aplikačných služieb uveďte všetky budované a rozvíjané eGovernment komponenty, ktoré budú výstupom projektu (súčasť výstupu M-06).
  
  Obrázok 12 Príklad rozpracovania detailov budúcej (TO BE) aplikačnej architektúry a závislostí (dátových tokov) medzi systémami
• Popíšte plánované integrácie na externé systémy a hlavne spoločné moduly. Popíšte, aké aplikačné služby budú poskytované na externú integráciu s budovanými informačnými systémami.
• Do tabuliek prehľadov integrácií informačných systémov uveďte všetky budované a rozvíjané integrácie eGovernment komponentov, ktoré budú výstupom projektu (súčasť výstupu M-06).
  
  Obrázok 13 Príklad detailnejšieho znázornenia plánovaných integrácií

5.4.2 Rozsah informačných systémov – budúci stav (TO BE)

Uveďte informácie o dotknutých ISVS z pohľadu ich ďalšej prevádzky po realizácii projektu – budúci stav (TO BE):

Tabuľka 12 Rozsah informačných systémov - budúci stav (TO BE)

5.4.3 Využívanie nadrezortných a spoločných ISVS – AS IS

Uveďte informácie o využívaných, resp. nevyužívaných nadrezortných ISVS (Spoločných ISVS a spoločných blokov SaaS) – AS IS stav. Všetky realizované integrácie na nadrezortné ISVS v AS IS stave musia byť evidované v MetaIS (výstup M-06).

Tabuľka 13 Využívanie nadrezortných a spoločných ISVS – súčasný stav (AS IS)

5.4.4 Prehľad plánovaných integrácií na nadrezortné ISVS – spoločné moduly podľa zákona č. 305/2013 Z.z. o e-Governmente – budúci stav (TO BE)

Uveďte plánované využívanie nadrezortných a spoločných ISVS v TO BE stave.
Povinnosť využívať nadrezortné ISVS ustanovuje najmä 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) a iné legislatívne predpisy. Prehľad a informácie o nadrezortných ISVS sú uvedené v prílohe P8 Zoznam nadrezortných blokov a podporných spoločných blokov Používateľskej príručky MetaIS.

Tabuľka 14 Prehľad plánovaných integrácií na spoločné moduly – budúci stav (TO BE)

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

Uveďte v nasledujúcej tabuľke prehľad ISVS, pri ktorých sa plánuje využívanie služieb iných ISVS, spoločných blokov (SaaS) alebo služieb inf. systémov tretích strán v TO BE stave.
Plánované využívanie a integrácie služieb iných ISVS musí byť evidované v MetaIS – zaevidovanie vzťahu na aplikačnú službu určenú na externú integráciu poskytujúcim ISVS .

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

5.4.6 Aplikačné služby pre Koncové služby – budúci stav (TO BE)

Uveďte v nasledujúcej tabuľke budované alebo rozvíjané aplikačné služby, ktoré sú potrebné pre poskytnutie Koncovej služby – vzťah „Aplikačná služba slúži Koncovej službe“. Koncovú službu by mala podporovať aspoň jedna aplikačná služba. Koncovú službu môže podporovať aj viac aplikačných služieb. Všetky aplikačné služby a ich vzťah na koncové služby musia byť evidované v MetaIS (vzťah „Aplikačná služba slúži Koncovej službe“).

5.4.7 Aplikačné služby na integráciu – budúci stav (TO BE)

Uveďte v nasledujúcej tabuľke budované aplikačné služby a ich využitie na integráciu na spoločné moduly a iné ISVS (ako konzument) alebo ich poskytovanie na externú integráciu a predpokladané vybudovanie cloudových služieb “softvér ako služba“ (SaaS):

• Plánované aplikačné služby musia byť evidované v MetaIS s fázou životného cyklu a musia mať v MetaIS evidované všetky povinné atribúty a vzťahy,
• Evidencia integrácií v MetaIS sa realizuje evidovaním vzťahov aplikačných služieb budovaného alebo rozvíjaného ISVS na príslušné aplikačné služby spoločných modulov ISVS. Podrobné informácie sú uvedené v Používateľskej príručke MetaIS. Detailný popis služieb spoločných modulov (IS CPDI, modulov ÚPVS) určených na integráciu je v aktuálnej verzii integračného manuáloch týchto ISVS.
• Ak IS povinnej osoby potrebuje konzumovať alebo poskytovať služby iným ISVS alebo IS tretích strán prostredníctvom modulu Centrálna API Manažment Platforma (CAMP) a jej modulu API Gateway, je potrebné aplikačné služby IS Povinnej osoby naviazať na príslušné integračné služby CAMP (API Gateway).
• 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.

Tabuľka 17 Aplikačné služby na integráciu – budúci stav (TO BE)

• Na informáciu je v nasledujúcej tabuľke prehľad AS na externú integráciu Spoločných modulov podľa § 10 zákona č. 305/2013 Z. z. Vo finálnom dokumente túto tabuľku prehľadu AS spoločných modulov vymažte:

• Na informáciu sú v nasledujúcich diagramoch vzory modelovania integrácie na nadrezortné a spoločné moduly podľa § 10 zákona č. 305/2013 Z.z. podľa usmernenia v Používateľskej príručke MetaIS. Vo vašom finálnom dokumente tieto vzory vymažte a nahraďte svojím diagramom ilustrujúcim plánované integrácie:
  
  Obrázok 14 Integrácie na spoločné moduly ÚPVS – ref. príklad
  
  Obrázok 15 Integrácie na API manažment platformu - IS CAMP- referenčný príklad
  
  Obrázok 16 Integrácie na IS CPDI (CSRÚ) – ref. príklad

5.5 Dátová architektúra

Popíšte 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 (zverejnená na stránke https://www.minv.sk/?np-optimalizacia-procesov-vo-verejnej-sprave v Aktivite 5).

• Uveďte diagramy tried a štruktúrovaný popis entít a atribútov vhodný aj pre strojové spracovanie. Diagram tried uveďte vo forme úplného logického modelu.
• Popíšte procesy riadenia ž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.
• Popíšte zavedenie systematického manažmentu údajov v organizácií.
• 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.

5.5.1 Objekty evidencie

V nasledujúcej tabuľke uveďte a popíšte Objekty Evidencie (ďalej len OE) v jednotlivých ISVS/registroch súvisiace s projektom.
Pre budované informačné systémy vytvorte tzv. doménový model, ktorý definuje návrh dátových prvkov súvisiacich s projektom.

• Ú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),
• Doménový model by mal byť v súlade so štandardami výmeny údajov medzi informačnými systémami verejnej správy podľa § 30 vyhlášky č. 78/2020 Z.z. o štandardoch pre informačné technológie verejnej správy.
• Pri návrhu objektov evidencie zohľadnite pravidlá pre zabezpečenie výmeny dát a interoperabilitu (viac informácií na: Interoperabilita (web stránky MIRRI) (https://mirri.gov.sk/sekcie/informatizacia/o-sekciach/centralna-datova-kancelaria/interoperabilita/ ) alebo.
• Pre modelovanie doménového modelu odporúčame stiahnuť si Centrálny model údajov verejnej správy v preferovanej distribúcii a v dátovom modeli pre budované informačné systémy použiť existujúce dátové prvky, ak tieto patria do domény projektu. Z technického pohľadu je odporučený jazyk UML. Pre zjednodušený doménový model môžete použiť aj jazyk 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

Tabuľka 18 Objekty evidencie

Obrázok 17 Doménový model - príklad

Obrázok 18 Zjednodušený doménový model - príklad

5.5.2 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.
Za účelom dosiahnutia budúceho (TO BE) stavu, z ktorého bude benefitovať občan / podnikateľský subjekt úsporou svojho času a prostriedkov, je potrebné popísať rozsah a štruktúru údajov na úrovni registrov a objektov evidencie, 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ť“:

• 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).
• 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.
• 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).
• 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 CPDI (kód MetaIS=isvs_5836, pôvodné 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ú na web stránkach MIRRI: Referenčné údaje a stop byrokracii (https://mirri.gov.sk/sekcie/informatizacia/o-sekciach/centralna-datova-kancelaria/referencne-udaje-a-stop-byrokracii/ ).
• V nasledujúcej tabuľke uveďte návrh na vyhlásenie a zmeny referenčných údajov, ktoré budú poskytnuté na dátovú integráciu realizáciou projektu. V tabuľke uveďte OE z tabuľky uvedenej v kapitole 5.5.1 Objekty evidencie :

Tabuľka 19 Návrh na vyhlásenie a zmeny referenčných údajov

5.5.3 Poskytovanie údajov z ISVS do IS CPDI – budúci stav (TO BE)

Uveďte v nasledujúcej tabuľke prehľad poskytovaných údajov (objektov evidencie, ďalej OE) z budovaných alebo rozvíjaných ISVS v tomto projekte do IS Centrálna platforma dátovej integrácie (IS CPDI, kód MetaIS=isvs_5836, pôvodné IS CSRÚ) v budúcom stave (TO BE).
 Uveďte ID OE z tabuľky uvedenej v kapitole 5.5.1 Objekty evidencie

Tabuľka 20 Poskytovanie údajov z ISVS do IS CPDI – budúci stav (TO BE)

5.5.4 Konzumovanie údajov z IS CPDI – budúci stav (TO BE)

Uveďte v nasledujúcej tabuľke prehľad konzumovaných údajov z IS Centrálna platforma dátovej integrácie (IS CPDI, kód MetaIS=isvs_5836, pôvodné IS CSRÚ) v budúcom stave (TO BE).
Súčasné dostupné objekty evidencie a údaje v IS CPDI sú uvedené v integračnom manuáli IS CPDI, ktorý nájdete na web stránkach MIRRI (https://mirri.gov.sk/sekcie/informatizacia/o-sekciach/centralna-datova-kancelaria/datovy-program/).
Uveďte ID OE z tabuľky uvedenej v kapitole 5.5.1 Objekty evidencie

Tabuľka 21 Konzumovanie údajov z IS CPDI – budúci stav (TO BE)

5.5.5 Identifikácia údajov a subjektov pre konzumovanie alebo poskytovanie údajov do/z CPDI (CSRÚ)

Identifikujte a uveďte v nasledujúcej tabuľke potenciálnych konzumentov objektov evidencie, ktoré budú poskytnuté na dátovú integráciu realizáciou projektu, 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é identifikujte osobitné právne predpisy (až na úroveň konkrétneho ustanovenia), ktoré je nutné novelizovať v záujme dosiahnutia budúceho stavu využitia údajov a jeho bezproblémovej aplikovateľnosti.
V tabuľke uveďte OE z tabuľky uvedenej v kapitole 5.5.1 Objekty evidencie
Poznámka: Pre úspešné napojenie ISVS na IS CPDI v roli konzumenta údajov je nutné postupovať podľa integračného manuálu IS CPDI (kód MetaIS=isvs_5836, pôvodné IS CSRÚ).

Tabuľka 22 Identifikácia údajov pre konzumovanie alebo poskytovanie údajov do/z CPDI (CSRÚ)

5.5.6 Kvalita a čistenie údajov

Zhodnoťte objekty evidencie 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:

• uveďte, či a ako bude zapracovaná možnosť overenia hodnoty údaja,
• uveďte, či bude zapracované pri zadávaní údajov obmedzenie hodnôt, napríklad formou číselníka, alebo podmienok,
• uveďte, či budú dáta migrované z iného ISVS.
  V nasledujúcej tabuľke vyhodnoťte významnosť a citlivosť kvality údajov a 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.
  V tabuľke uveďte OE z tabuľky uvedenej v kapitole 5.5.1 Objekty evidencie :

Tabuľka 23 Zhodnotenie dátovej kvality objektov evidencie

V nasledujúcej tabuľke definujte potrebné personálne 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. (informácie k téme: https://mirri.gov.sk/sekcie/informatizacia/egovernment/datova-kancelaria/datova-kvalita/ )

Tabuľka 24 Personálne zabezpečenie a roly pri riadení dátovej kvality

5.5.7 Otvorené údaje

V nasledujúcej tabuľke doplňte objekty evidencie, ktoré budú realizáciou projektu sprístupnené ako otvorené údaje. Uveďte názov objektu evidencie (identifikované v kapitole dátový rozsah projektu) pre kategóriu otvorených údajov a stanovte úroveň požadovanej kvality (interoperability) otvorených údajov (podľa § 38 vyhlášky č. 78/2020 Z.z. o štandardoch pre informačné technológie verejnej správy)
Požadovaná kvalita:

• Automatizované publikovanie otvorených údajov v kvalite úrovne 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 úrovne 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 úrovne 5★ (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.
  V tabuľke uveďte OE z tabuľky uvedenej v kapitole 5.5.1 Objekty evidencie :

Tabuľka 25 Objekty evidencie, ktoré budú sprístupnené ako otvorené údaje

5.5.8 Analytické údaje

Analytické údaje sú údaje, ktoré sú hromadne získavané zo zdrojových registrov a iných zdrojov dát pre ich hromadné spracovanie a vyhodnotenie s cieľom zistenia trendov, faktov a vzorcov v získaných dátach popisujúcich skúmanú oblasť pre účely realizácie legislatívnej iniciatívy, tvorby štátnej politiky, skúmania problematiky v určitej oblasti a navrhovaní opatrení na riešenie rôznych otázok, hodnotenia výsledkov a kvality výkonu verejnej moci. 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.
Informácie k sprístupneniu dátových zdrojov organizácie na analytické účely na web stránke MIRRI: https://mirri.gov.sk/sekcie/informatizacia/o-sekciach/centralna-datova-kancelaria/analyticke-udaje/
V súlade s podmienkami používania údajov pri analytickej činnosti uvedenými na web stránkach MIRRI by mali byť tieto dáta analyticky spracovávané až po pseudonymizovaní alebo anonymizovaní osobných alebo citlivých údajov. Predpokladá sa, že najvhodnejší spôsob pseudonymizácie a anonymizácie bude navrhnutý vo fáze detailného návrhu riešenia a preto ich nemusíte v tejto prípravnej fáze špecifikovať ani obmedzovať rozsah atribútov datasetu poskytnutého pre analytické spracovanie. Požiadavky na detailný návrh riešenia pseudonymizácie a anonymizácie údajov ako aj detailizáciu návrhu ich analytického spracovania si zapíšte do Katalógu požiadaviek.
V nasledujúcej tabuľke uveďte, ktoré objekty evidencie budú projektom pripravené na analytické účely a sprístupňované pre analytické jednotky (napr. pre systém Konsolidovaná Analytická Vrstva – KAV).
V tabuľke uveďte OE z tabuľky uvedenej v kapitole 5.5.1 Objekty evidencie :

Tabuľka 26 Objekty evidencie, ktoré budú projektom pripravené pre analytické účely

5.5.9 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ú sprístupnené prostredníctvom modulu procesnej integrácie a integrácie údajov (IS CPDI (CSRÚ)) pre modul Manažmentu osobných údajov pre dotknuté osoby (občanov a podnikateľov) na základe preukázania elektronickej identity osoby. 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.
  Informácie k sprístupneniu dátových zdrojov organizácie pre službu Moje údaje:
  https://mirri.gov.sk/sekcie/informatizacia/o-sekciach/centralna-datova-kancelaria/moje-udaje/ .
  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 MetaIS,
• 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). 
  V prípade, že predkladateľ projektu disponuje údajmi, ktoré spadajú do kategórie Mojich údajov, je potrebné vyplniť nasledovnú tabuľku. V tabuľke uveďte OE z tabuľky uvedenej v kapitole 5.5.1 Objekty evidencie .

Tabuľka 27 Objekty evidencie, ktoré spadajú do kategórie Mojich údajov

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

Vyplňte nasledujúcu súhrnnú tabuľku pre kategorizáciu údajov dotknutých projektom z pohľadu využiteľnosti týchto údajov.
V tabuľke uveďte OE z tabuľky uvedenej v kapitole 5.5.1 Objekty evidencie .

Tabuľka 28 Prehľad jednotlivých kategórií údajov

5.6 Technologická architektúra

5.6.1 Návrh riešenia technologickej architektúry

Uveďte popis a znázornenie modelu technologickej vrstvy súčasného (AS IS) stavu, používané výpočtové prostriedky, komunikačné prepojenia, problematické body, ktoré je potrebné projektom riešiť.
V popise treba zvážiť potrebný rozsah popisu súčasnej architektúry. Zvolený rozsah popisu súčasného stavu by mal byť uvedený v takom dostatočnom rozsahu, ktorý je potrebný na znázornenie a popis rozdielov medzi súčasným (As-Is) a budúcim (navrhovaným – TO BE) riešením.
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.
Popíšte navrhovaný budúci (TO BE) stav riešenia technologickej vrstvy architektúry s prepojením na aplikačnú vrstvu architektúry – ako navrhovaná technologická architektúra a jej komponenty podporuje vývoj a prevádzku aplikačných komponentov (informačných systémov, aplikačných služieb a integrácií)..
V popise návrhu riešenia budúceho stavu (TO BE) 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é)
• znázornenie (diagramy) modelu navrhovanej technologickej infraštruktúry, jej zmeny oproti súčasnému stavu, jej prepojenie na aplikačnú vrstvu architektúry (nasadenie aplikačných komponentov) a hlavné komunikačné prepojenia.
  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í a zavedenie štandardu používania a vytvárania zdieľaných služieb. Riešenie „Cloud-native“ ISVS, je v čo najväčšej miere nezávislé na umiestnení v datacentre. Nezávislosť novovyvíjaného ISVS od cloudového prostredia by malo byť základnou prioritou a podmienkou architektúry ISVS.
  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ť.

5.6.2 Požiadavky na výkonnostné parametre, kapacitné požiadavky – budúci stav (TO BE)

Doplňte pre budúci stav (TO BE) do nasledujúcej tabuľky požiadavky na výkonnostné parametre a kapacitné požiadavky, ktoré majú vplyv na výkon, sizing prostredia, napr. 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 29 Požiadavky na výkonnostné parametre, kapacitné požiadavky – budúci stav (TO BE)

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

Zaevidujte v MetaIS využívanie infraštruktúrnych služieb vašimi ISVS. Podrobné informácie o evidencii využívania infraštruktúrnych služieb sú uvedené v Používateľskej príručke MetaIS.
V nasledovnej tabuľku uveďte prehľad plánovaného využitia infraštruktúrnych - cloudových služieb pre navrhované ISVS. Pri výbere vhodných cloudových služieb okrem technologických požiadaviek zohľadnite klasifikáciu budovaných a rozvíjaných ISVS, ktorú ste urobili pri výbere vhodnej technologickej architektúry v
v časti 5.1.3 Stanovenie alternatív v technologickej vrstve architektúry. Zvolená infraštruktúrna služba by mala byť zaradená do rovnakej alebo vyššej klasifikačnej úrovne ako ISVS, ktorý ju bude využívať.

Tabuľka 30 Využívanie služieb z katalógu služieb vládneho cloudu

Uveďte parametre (kapacity) požadovaných výpočtových zdrojov (sizing) a využite služieb hybridného vládneho cloudu (uvedené v tabuľkách nižšie) pre jednotlivé prevádzkové prostredia:

• Vývojové – určené pre vývoj systému
• Testovacie – 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é – určené pre produkčnú (ostrú) prevádzku systému
• Ďalšie existujúce alebo plánované prostredia, ktoré budú potrebné, napr. predprodukčné, integračné, fix prostredie
  Poznámky:
  Ak potrebujete pre príslušné prostredie viaceré infraštruktúrne služby, pridajte si potrebné riadky.
  V prípade, že neplánujete využitie cloudových služieb z katalógu služieb vládneho cloudu, uveďte v tabuľke požadovaných výpočtových zdrojov (sizing) pre jednotlivé prostredia parametre výpočtových zdrojov, ktoré plánujete v projekte použiť. Namiesto názvu a kódu infraštruktúrnej služby uveďte kód a názov výpočtového zdroja evidovaného v MetaIS.
  V súlade s NKIVS by technologická architektúra mala byť založená na cloudových službách vládneho cloudu. 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 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: Katalóg cloudových služieb (https://www.mirri.gov.sk/sekcie/informatizacia/egovernment/vladny-cloud/katalog-cloudovych-sluzieb.)

Tabuľka 31Predpokladané kapacity požadovaných výpočtových zdrojov (sizing)

Určite v štruktúrovanej podobe ďalšie potrebné infraštruktúrne alebo iné cloudové služby (PaaS, SaaS) potrebné na prevádzku projektu podľa katalógu cloudových služieb. Tabuľky si treba prispôsobiť, aby čo najlepšie odpovedali podmienkam návrhu riešenia a charakteristikám zvolených cloudových služieb:

Tabuľka 32 Predpokladané kapacity ďalších cloudových (infraštruktúrnych) služieb

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 (napr. MV SR) v súlade s postupom zverejneným na webovom sídle https://mirri.gov.sk/sekcie/informatizacia/dokumenty/vladny-cloud/

5.7 Bezpečnostná architektúra

5.7.1 Návrh riešenia bezpečnosti

Popíšte súčasný stav (AS IS) bezpečnostnej architektúry v rozsahu dostatočnom pre znázornenie a popis rozdielov medzi súčasným (As-Is) a budúcim navrhovaným (TO BE) riešením bezpečnosti.
Popíšte navrhovaný budúci (TO BE) stav riešenia bezpečnostnej architektúry. Stručne popíšte postupy na dosiahnutie potrebnej úrovne bezpečnosti a spôsob zabezpečenia aktív projektu na jednotlivých vrstvách architektúry a dosiahnutie požadovanej úrovne hlavných aspektov bezpečnosti - dôvernosť, dostupnosť a integrita.
Opatrenia a požiadavky pre riešenie bezpečnosti by mali vychádzať z týchto hlavných zdrojov:

• Ohodnotenia rizík a identifikovanie hrozieb pre organizáciu a aktíva realizované projektom, zhodnotenie ich zraniteľností a pravdepodobnosti výskytu hrozieb a odhadnutý potenciálny dopad.
• Legislatívne, právne, štatutárne, regulačné a zmluvné požiadavky, ktoré vaša organizácia, jej dodávatelia, partneri a zákazníci musia splniť.
• Sada princípov, cieľov bezpečnosti a interných smerníc, ktoré používa vaša organizácia na podporu svojej činnosti.  

5.7.2 Určenie obsahu bezpečnostných opatrení

Určite požiadavky vyplývajúce z obsahu minimálnych bezpečnostných opatrení¹¹ podľa vyhlášky ÚPVII č. 179/2020 Z. z.  
Určite požiadavku na vypracovanie bezpečnostného projektu podľa § 8a vyhlášky 401/2023 Z.z ¹²
Určite požiadavky na aplikáciu bezpečnostných opatrení podľa osobitných predpisov.
V nasledujúcej tabuľke uveďte prehľad hlavných zdrojov minimálnach bezpečnostných opatrení.

Tabuľka 33 Určenie zdrojov a obsahu minimálnych bezpečnostných opatrení

Zapíšte do Katalógu požiadaviek, ktoré minimálne bezpečnostné opatrenia (Kategórie) podľa vyhlášky ÚPVII č. 179/2020 Z. z. budú v projekte aplikované.
Zapíšte do Katalógu požiadaviek upresnenie bezpečnostných požiadaviek vyplývajúce z minimálnych bezpečnostných opatrení a identifikovaných špecifických hrozieb pre organizáciu a implementované aktíva v tomto projekte.
Zapíšte do Katalógu požiadaviek upresnenie bezpečnostných požiadaviek vyplývajúce z bezpečnostných opatrení osobitných predpisov aplikovateľných špeciálne na implementované aktíva v tomto projekte.
Zapíšte do katalógu požiadaviek požiadavku na vypracovanie bezpečnostného projektu, ak má byť vytvorený: Bezpečnostný projektu musí byť pripravovaný a dodaný súčasne s Detailným návrhom riešenia (DNR, projektový výstup R1-1), aby opatrenia z bezpečnostného projektu boli zapracované do DNR a dodaného diela. Bezpečnostný projekt musí byť aktualizovaný počas celej realizačnej fázy projektu podľa skutočného stavu implementácie požiadaviek, technologickej infraštruktúry a aj na základe nálezov z bezpečnostného testovania.
Samotný bezpečnostný projekt bude popísaný v samostatnom dokumente Bezpečnostný projekt, ktorý je výstupom etapy R3-4 a jeho náležitosti ustanovuje príloha č. 3 vyhlášky ÚPVII č. 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.

5.7.3 Legislatívne, právne, štatutárne, regulačné a zmluvné požiadavky,

Uveďte požiadavky na 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. Ide najmä o nasledovnú legislatívu:

• 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
• Vyhláška 362/2018 Z. z. ktorou sa ustanovuje obsah bezpečnostných opatrení, obsah a štruktúra bezpečnostnej dokumentácie a rozsah všeobecných bezpečnostných opatrení
• 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.
  Okrem legislatívnych nariadení môžete pre stanovenie požiadaviek na riešenie bezpečnosti v projekte použiť metodiky CSIRT: https://csirt.sk/metodiky-a-hardening.html.
  Uveďte interné smernice a iné relevantné metodické materiály, ktoré používa vaša organizácia na podporu bezpečnosti svojej činnosti a hlavné aplikovateľné požiadavky vyplývajúce z týchto interných smerníc.

5.7.4 Riešenie autentifikácie a prístupov používateľov

Doplňte požiadavky na autentifikáciu používateľov. Ak to použitie systému a bezpečnostné požiadavky nevylučujú, preferujte použitie technológií pre jednotné prihlásenie (Single Sign On) a využitie existujúcich systémov správy identít prepojených na referenčné zdroje dát o identitách (napr. Autentifikačný modul IAM Ústredného portálu verejnej správy).
Doplňte požiadavky na používateľské role, správu prístupov a správu aplikácie:

• Interní používatelia (pracovníci jednotlivých organizačných jednotiek, pracovníci administrácie a správy aplikácie, pracovníci prevádzky a podpory)
• Externí používatelia (zákazníci, partneri - tretie strany).
  Zapíšte požiadavky na riešenie bezpečnosti do Katalógu požiadaviek.

6. PREVÁDZKA A ÚDRŽBA VÝSTUPOV PROJEKTU

6.1 Návrh riešenia prevádzky a údržby

Stručne popíšte AS IS stav zabezpečenia prevádzky a údržby a úroveň poskytovania služieb (SLA). Zamerajte sa hlavne na popis tých oblastí, ktoré plánujete zlepšiť v budúcom stave zabezpečenia prevádzky a údržby.
Popíšte navrhovaný budúci (TO BE) stav riešenia zabezpečenia prevádzky a údržby, úroveň poskytovania služieb (SLA) a obnovy systému a dát po výpadku prevádzky systému.
Uveďte, či používate alebo plánujete používať nejaký informačný systém pre manažment služieb podpory a požadujete jeho integráciu a výmenu dát s informačnými systémami dodávanými v projekte.
Uveďte prehľad všetkých predpokladaných požiadaviek na prevádzku a údržbu cieľového riešenia.

6.2 Zabezpečenie podpory používateľov a prevádzky

Popíšte, ako bude zabezpečovaná podpora používateľov a prevádzky.
Podpora prevádzky a používateľov je zvyčajne realizovaná cez 3 úrovne podpory, s nasledujúcim označením a obsahom činnosti:

• Podpora L1 (podpora 1. stupňa - Level 1) - začiatočná úroveň podpory, ktorej základnou funkciou 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ď. Je zabezpečovaná prostredníctvom pracoviska jednotného kontaktného miesta.
• Podpora L2 (podpora 2. stupňa – Level 2 - postúpenie požiadaviek od L1) – 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 najobtiažnejších Hlásení, vrátane prevádzania hĺbkových analýz a riešenie extrémnych prípadov.
  Typické zodpovednosti za realizáciu podpory sú:
• L1 (Level 1: priamy kontakt zákazníka) - jednotný kontaktný bod verejného obstarávateľa je zvyčajne zabezpečovaný pracoviskom v správe správcu informačného systému, ak nedeleguje túto činnosť na špecializovanú organizáciu v jeho zriaďovacej pôsobnosti (napr. NASES, DataCentrum, NCZI) alebo výnimočne na externého dodávateľa.
• L2 (Level 2: postúpenie požiadaviek od L1) - riešiteľské tímy s hlbšou znalosťou prevádzkovaného systému sú zvyčajne tvorené pracovníkmi prevádzkovateľa informačného systému – buď pracovníkmi správcu alebo pracovníkmi špecializovanej organizácie v jeho zriaďovacej pôsobnosti (napr. NASES, DataCentrum, NCZI). Časť špecializovaných prác môže byť za definovaných podmienok prenesená aj na externého dodávateľa.
• L3 (Level 3, postúpenie požiadaviek od L2) - na základe zmluvy o podpore inf. systému zvyčajne zabezpečuje externý dodávateľ, ktorý má potrebné kapacity a kvalifikovaný personál pre riešenie prevádzkových incidentov a servisných požiadaviek.
  Okrem zabezpečenia podpory používateľov a prevádzky je potrebné určiť spôsob a rozsah zabezpečenia podpory infraštruktúrnych služieb použitých pre prevádzku informačného systému (cloudové služby, komunikačné služby, servery a ich systémové programové vybavenie, sieťová infraštruktúra) a určiť zodpovednosti pri zabezpečení prevádzky technologickej infraštruktúry a spôsob komunikácie s poskytovateľom podpory infraštruktúrnych služieb.
  V nasledovnej tabuľke uveďte prehľad očakávaného riešenia zabezpečenia podpory používateľov a prevádzky, hlavné zodpovednosti a očakávanú úroveň poskytovaných služieb:

Tabuľka 34 Prehľad riešenia zabezpečenia podpory používateľov a prevádzky

Uveďte a tiež do Katalógu požiadaviek zapíšte špeciálne požiadavky týkajúce sa zabezpečenia jednotlivých úrovní podpory, predpokladané obmedzenia alebo rozšírenia služieb a zodpovednosti niektorej úrovne podpory, ktoré bude potrebné zohľadniť pri realizácii projektu a ktoré môžu mať vplyv na rozsah prác dodávateľa riešenia a cenu projektu.

6.3 Riešenie incidentov v prevádzke - parametre úrovní služby

Parametre služby riešenia incidentov v prevádzke sú špecifikované na základe určenia priority incidentu pomocou kombinácie jeho naliehavosti a dopadu podľa najlepších skúseností z praxe (best practice) z oblasti manažmentu IT služieb ( Information Technology Infrastructure Library - ITIL V3) nasledovným spôsobom:
Incident - za incident je považovaná každá nahlásená alebo inak zistená relevantná skutočnosť týkajúca sa aktíva (informačného systému) alebo jeho časti, ktorého nedostupnosť alebo nefunkčnosť má vplyv na poskytovanie služieb.

Tabuľka 36 Klasifikácia Závažnosti incidentu

Určenie priority incidentu je kombináciou dopadu a naliehavosti podľa nasledovnej matice:

Tabuľka 37 Určenie priority incidentu

Parametre služby Riešenia incidentov v prevádzke:

Tabuľka 38 Parametre služby Riešenia incidentov v prevádzke

Vysvetlivky k tabuľke
(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 (Doba konečného vyriešenia incidentu) - znamená čas obnovenia štandardnej prevádzky - čas medzi nahlásením incidentu verejným obstarávateľom a vyriešením incidentu poskytovateľom podpory (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 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 poskytovateľ podpory oprávnený požadovať od verejného obstarávateľa schválenie riešenia incidentu.
(3) Spoľahlivosť - 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 poskytovateľovi podpory v rámci testovacieho prostredia majú prioritu 3 a nižšiu. Vzťahujú sa výhradne k dostupnosti testovacieho prostredia. Za incident v 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.

6.4 Požadovaná dostupnosť informačného systému:

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 nasledovnom prehľade:
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
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).
  Popri špecifikácii dostupnosti systému v percentách uveďte aj upresňujúce ukazovatele, ktoré vyjadrujú požadované doby obnovenia systému a rozsahu dát, o ktoré môžete prísť:
   
• Recovery Time Objective (zvyčajne sa požíva skratka RTO) - vyjadruje množstvo času potrebné pre obnovenie prevádzky systému po jeho výpadku. Môže byť, v závislosti na použitej technológii, vyjadrené v sekundách, hodinách či dňoch. Pre zabezpečenie RTO sa používajú rôzne stratégie a technológie zálohovania alebo replikácie dát (vrátane obrazov a konfigurácií infraštruktúry) a vytvárania a prevádzky záložných systémov v ďalších lokalitách. Kľúčovým prostriedkom pre zabezpečenie dosiahnutia požadovaného RTO je okrem pravidelného a spoľahlivého vykonávania záloh dát a konfigurácií a vytvorenia záložného systému aj podrobný a overený Plán obnovy po výpadku (recovery plán) a aktuálna inštalačná dokumentácia.
• Recovery Point Objective (zvyčajne sa požíva skratka RPO) - je ukazovateľ dostupnosti dát. RPO vyjadruje, do akého stavu (bodu) v minulosti možno obnoviť dáta po výpadku systému. Inými slovami množstvo dát, o ktoré môže organizácia prísť. Pre zabezpečenie RPO sa používajú rôzne stratégie a technológie zálohovania alebo replikácie dát a bod obnovy dát je možné znížiť až k nulovej strate. Existujúce technológie poskytujú orientačne nasledovné úrovne zabezpečenia RPO:
  • Tradičné zálohovanie - strata dát v rozsahu cca hodiny až dni
  • Asynchrónne replikácie dát – strata dát v rozsahu minút až sekúnd, strata sa blíži k nule
  • Synchrónna replikácia dát - nulová strata
    Vo všeobecnosti platí, že čím vyššia dostupnosť systému a kratšie ukazovatele RTO a RPO, tým drahšie prostriedky sú potrebné na zabezpečenie ich dosiahnutia a mali by byť zohľadnené v Analýze nákladov a prínosov M-05 BC/CBA.

6.5 Požiadavky na ľudské zdroje potrebné pre zabezpečenie prevádzky

Uveďte požiadavky na personálne zabezpečenie prevádzky budovaného systému (TO BE) a súvisiacich prevádzkových procesov.
Uveďte požiadavky na zabezpečenie potrebných školení a certifikátov pre používateľov, pracovníkov podpory, prevádzky a správy budovaného systému.

6.6 Požiadavky na zdrojové kódy

Doplňte spôsob zabezpečenia dodávky zdrojových kódov aplikačných častí riešenia a ich dokumentácie podľa § 15 ods. d) zákona č. 95/2019 Z.z. a zabezpečenia dispozičných práv (licencií) k zdrojovým kódom, ich dokumentácii a projektovým výstupom zhotovených dodávateľom.
Doplňte 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,
Doplňte pravidlá pre preberanie, správu a archiváciu zdrojových kódov a tieto pravidlá následne preniesť do Zmluvy o dielo alebo zmluvy na podporu (ZoD/SLA).
Naviažte preberanie/odovzdávanie zdrojových kódov na fakturačné míľniky.
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.
Usmernenia pre oblasť zdrojových kódov:

• Metodické usmernenie č. 024077/2023 – o kvalite zdrojových kódov a balíkov softvéru zverejnené na stránke: https://mirri.gov.sk/sekcie/informatizacia/riadenie-kvality-qa/    
• Inštrukcie k EUPL licenciám: https://commission.europa.eu/content/european-union-public-licence_en

7. OPIS IMPLEMENTÁCIE PROJEKTU A PREBERANIA VÝSTUPOV PROJEKTU

Posúďte požiadavky na spôsob realizácie projektu, harmonogram projektu a ich dopad na preberanie výstupov pripravovaného projektu.
V zmysle vyhlášky MIRRI č. 401/2023 Z.z. o riadení projektov a zmenových požiadaviek v prevádzke je potrebné posúdiť výber spôsobu realizácie projektu metódou waterfall, metódou agile alebo metódou waterfall s prvkami metódy agile.

• Doplňte detailizáciu požadovaných PROJEKTOVÝCH PRODUKTOV - čo bude/čo chcete, aby bolo v jednotlivých etapách, inkrementoch a po ukončení projektu dodané:
  • projektové výstupy podľa vyhlášky MIRRI č. 401/2023 Z.z. o riadení projektov (vrátane zdrojových kódov) – projektová dokumentácia a dokumentácia dodaného produktu
  • koncové služby a transformované alebo nové biznis procesy, ktoré sú predmetom dodávky projektu
  • biznis objekty, ktoré majú byť vstupmi a výstupmi zo systému – napr. podania, formuláre, rozhodnutia, reporty, dáta, aplikačné rozhrania
  • aplikačné komponenty riešenia
  • technologické komponenty riešenia
• Uveďte návrh rozdelenia zodpovednosti za vypracovanie a dodanie projektových výstupov.
• Doplňte informácie a požiadavky na spôsob akceptácie a schvaľovania výstupov projektu.

8. ODKAZY

Doplňte odkazy na iné existujúce materiály, ktoré sú zdrojovými informáciami. V maximálnej miere sa vyhnite duplikovaným informáciám a ich aktualizácii na viacerých miestach v priebehu prípravy prípravnej projektovej dokumentácie, jej pripomienkovania a hodnotenia.

9. PRÍLOHY

Príloha 1: Zoznam rizík a závislostí (Excel): https://www.mirri.gov.sk/sekcie/informatizacia/riadenie-kvality-qa/riadenie-kvality-qa/index.html
Koniec dokumentu
1 Notácia ArchiMate: https://publications.opengroup.org/standards/archimate
2 EUPL licencie: https://joinup.ec.europa.eu/sites/default/files/inline-files/EUPL%201_1%20Guidelines%20SK%20Joinup.pdf
3 Podľa § 2 ods. 1 písm. i) vyhlášky MIRRI č. 401/2023 Z.z. o riadení projektov a zmenových požiadaviek v prevádzke informačných technológií verejnej správy sa objednávateľom rozumie správca alebo prevádzkovateľ ITVS, ktorý projekt realizuje alebo chce realizovať.
4 https://avssr.horizzon.cloud/. O prístup do repozitára a poskytnutie licencie pre modelovací nástroj pracujúci s repozitárom modelov je potrebné požiadať na e-mailovej adrese: sprava_EA@mirri.gov.sk.
5 The Open Group ArchiMate Model Exchange File Format Standard a špecifikácia BPMN 2.0.
6 Napr. modelovací nástroj Archi - Open Source ArchiMate Modelling: https://www.archimatetool.com.
7 Napr. modelovací nástroj pre BPMN - Camunda Modeler - Open Source Desktop Modeler: https://camunda.com/download/modeler/.
8 Aktuálny spoločný repozitár architektonických modelov verejnej správy je https://avssr.horizzon.cloud/. O prístup do repozitára a poskytnutie licencie pre modelovací nástroj pracujúci s repozitárom modelov je potrebné požiadať na e-mailovej adrese: sprava_EA@mirri.gov.sk.
9 Napr. modelovací nástroj Archi - Open Source ArchiMate Modelling: https://www.archimatetool.com.
10 Napr. modelovací nástroj pre BPMN - Camunda Modeler - Open Source Desktop Modeler: https://camunda.com/download/modeler/.
11 Správca ISVS je povinný zaviesť v organizácii systém riadenia informačnej (a kybernetickej) bezpečnosti a vypracovať bezpečnostný projekt pre ISVS podľa vyhlášky Ú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)
12 podľa § 8a vyhlášky 401/2023 Z.z o riadení projektov a zmenových požiadaviek v prevádzke informačných technológií verejnej správy účinného od 1.4.2025 a § 23 ods. 1 a 2 zákona 95/2019 Z.z. o informačných technológiách vo verejnej správe