PRÍSTUP K PROJEKTU

(Verzia dokumentu v1.0/07_2021)

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

Identifikácia projektu

Schvaľovanie dokumentu

OBSAH

1.          ÚČEL DOKUMENTU. 3

1.1        Manažérske zhrnutie. 3

1.2        Použité skratky. 3

2.          POPIS NAVRHOVANÉHO RIEŠENIA. 4

2.1        Úprava integrácie medzi MD SR (JISCD) a MV SR (EUCARIS) 4

2.2        Hľadanie aktuálnych údajov o evidovaných vozidlách v Eucaris (AVI) 4

2.3        Hľadanie počiatočných údajov o nových neevidovaných vozidlách v Eucaris (IVI/COC) 5

2.3.1     Zavedenie aplikačných služieb pre hľadanie údajov o novom vozidle. 6

2.3.2     Funkcionalita intranetu JISCD pre hľadanie počiatočných údajov o novom vozidle  6

2.3.3     Výpis údajov o novom vozidle. 6

2.3.4     Doplnenie výpisu medzi generované dokumenty. 6

2.4        Hľadanie počiatočných a/alebo aktuálnych údajov o vozidle z Eucaris pre ŠDÚ. 6

2.5        Požiadavky MD SR na realizáciu projektu. 6

2.5.1     Funkčné požiadavky. 6

3.          ARCHITEKTÚRA RIEŠENIA PROJEKTU. 9

3.1        Biznis vrstva. 9

3.1.1     Aktuálny stav. 9

3.1.2     Návrh budúceho stavu. 27

3.2        Aplikačná vrstva. 30

3.2.1     Rozsah informačných systémov. 30

3.3        Fyzická architektúra. 31

3.4        Softvérové licencie. 31

3.5        Zálohovanie a obnova riešenia. 31

3.6        Zabezpečenie dostupnosti 31

3.7        Dátová vrstva - Dátový model 31

3.8        Technologická vrstva. 31

3.9        Bezpečnostná architektúra. 31

4.          PREVÁDZKA A ÚDRŽBA. 32

4.1        Prevádzkové požiadavky. 32

4.2        Požadovaná dostupnosť IS: 32

5.          ZÁVISLOSTI NA OSTATNÉ ISVS / PROJEKTY. 32

6.          Prehľad koncových služieb, ktoré sú výstupom projektu. 32

7.          Legislatíva. 32

8.          VÝSTUPY PROJEKTU. 32

9.          HARMONOGRAM.. 33

9.1        ČASOVÉ ZÁVISLOSTI. 33

10.        ROZPOČET A PRÍNOSY. 34

10.1      ROZPOČET. 34

10.2      PRÍNOSY. 34

11.        PRÍLOHY. 34

1. ÚČEL DOKUMENTU

V súlade s Vyhláškou č. 401/2023 Z. z. o riadení projektov a zmenových požiadaviek v prevádzke informačných technológií verejnej správy je dokument Prístup k projektu pre prípravnú a iniciačnú fázu projektu určený na rozpracovanie zadania a požiadaviek k projektu, aby bolo možné rozhodnúť o realizácií projektu, alokovaní rozpočtu, ľudských zdrojov a prechode do inicializačnej, a realizačnej fázy.

1. 
   
   1. Manažérske zhrnutie

Zmenová požiadavka CR098 vyplýva zo zmien webových služieb a modulov systému Eucaris, ktorý poskytuje údaje o vozidlách pre vybrané agendy systému JISCD.

Systém Eucaris v súčasnosti poskytuje údaje o vozidlách prostredníctvom modulu VHinfo, ktorý od 1.7.2025 nebude viac podporovaný. Tento modul bude nahradený modulom AVI (actual vehicle information) na poskytovanie aktuálnych údajov o evidovaných vozidlách pre krajiny zapojené v Eucaris. Zároveň bol v rámci Eucaris vytvorený modul IVI/COC na poskytovanie počiatočných informácií o nových vozidlách.

Systém JISCD dnes v rámci agendy jednotlivých dovozov vozidiel umožňuje pracovníkom okresných úradov vyhľadať údaje z Eucaris prostredníctvom modulu VHinfo. Hľadanie údajov prebieha prostredníctvom integrácie JISCD na slovenský register Eucaris, ktorý je v správe MV SR.

Aby bolo možné naďalej vyhľadávať údaje o vozidlách v Eucaris prostredníctvom modulov AVI a IVI/COC, budú potrebné zmeny v integrácii medzi JISCD a MV SR, úpravy dátových modelov JISCD pre jednotlivé služby poskytované modulom AVI, zavedenie služieb pre hľadanie údajov o vozidlách prostredníctvom modulu IVI/COC a tiež úpravy samotnej funkcionality hľadania údajov o vozidlách v Eucaris v rámci intranetu JISCD. Okrem funkcionality pre okresné úrady pribudne aj funkcionalita pre hľadanie údajov o vozidlách v Eucaris pre MD SR (ŠDÚ).

Uvedené zmeny, ktoré majú dopad na funkcionalitu systému JISCD, sú bližšie popísané v nasledujúcich kapitolách.

1. 
   
   1. Použité skratky

1. POPIS NAVRHOVANÉHO RIEŠENIA

1. 
   
   1. Úprava integrácie medzi MD SR (JISCD) a MV SR (EUCARIS)

JISCD využíva služby Eucaris na základe integrácie na SK modul Eucaris, ktorý zabezpečuje MV SR.

Z dôvodu úprav existujúcich modulov pre poskytovanie údajov o vozidlách zo strany Eucaris bude potrebné vykonať úpravy v existujúcej integrácii medzi MD SR (JISCD) a MV SR (Eucaris). Za týmto účelom bude potrebné vykonať úpravy v DIZ medzi JISCD a MV SR. Následne bude potrebné upraviť napojenie JISCD na MV SR Eucaris modul podľa špecifikácie ktorá musí byť vydaná zo strany MV SR.

1. 
   
   1. Hľadanie aktuálnych údajov o evidovaných vozidlách v Eucaris (AVI)

Prostredníctvom modulu AVI systému Eucaris je možné vyhľadať aktuálne údaje o vozidlách evidovaných v niektorej zapojenej krajine. Hľadanie aktuálnych údajov o evidovaných vozidlách bude prebiehať buď automaticky (pozri kapitolu Automatické hľadanie údajov o vozidle) alebo na akciu používateľa (pozri kapitolu Manuálne hľadanie údajov o vozidle).

Funkcionalita bude dostupná v týchto návrhoch:

• Jednotlivé uznanie schválenia JDV z členského štátu
• Jednotlivé uznanie schválenia JDV zo zmluvného štátu
• Jednotlivé uznanie TS EÚ JDV z členského štátu
• Jednotlivé uznanie TS EÚ JDV zo zmluvného štátu
• Univerzálny návrh (napr. JDV pre diplomatov)

1. Úprava dátového modelu a služieb

Pre potreby získavania a ďalšieho využívania aktuálnych údajov o vozidle v systéme JISCD, bude potrebné upraviť dátové modely a jednotlivé služby pre hľadanie údajov podľa VIN/EČV/OE. Dátové modely a služby budú upravené podľa špecifikácie Eucaris pre modul AVI, resp. podľa špecifikácie SK modulu Eucaris (v správe MV SR).

1. Úprava funkcionality intranetu JISCD
   1. 
      
      1. 
         
         1. Automatické vyhľadanie aktuálnych údajov o vozidle

Eucaris modul AVI umožňuje poslať požiadavku na vyhľadanie údajov o vozidle konkrétnej zapojenej krajine alebo všetkým zapojeným krajinám (Multi Country Inquiry). Pre uľahčenie práce používateľom intranetu JISCD, bude implementovaná funkcionalita na automatické vyhľadanie údajov o vozidle podľa VIN zadaného v spracovávanom návrhu. Systém po uložení údajov žiadosti automaticky odošle požiadavku na vyhľadanie údajov o vozidle v Eucaris (AVI) všetkým zapojeným krajinám. Ak systém JISCD dostane späť odpoveď s údajmi o vozidle, bude pre používateľa sprístupnený výpis zo systému Eucaris (akcia Zobraziť výpis).

V prípade, že systém JISCD nedostane spať odpoveď s údajmi o vozidle, bude môcť používateľ pokračovať v manuálnom hľadaní údajov o vozidle v Eucaris podľa EČV vozidla alebo čísla OE vozidla.

1. 
   
   1. 
      
      1. 
         
         1. Manuálne vyhľadanie aktuálnych údajov o vozidle

Na vybraných návrhoch v rámci intranetu JISCD bude pre okresné úrady doplnená funkcionalita na vyhľadanie aktuálnych údajov o vozidle v Eucaris na základe výberu kritéria pre hľadanie. Používateľ bude môcť v Eucaris vyhľadať údaje o vozidle, ktoré už bolo v inej krajine prihlásené do evidencie na základe týchto údajov:

• VIN (AVIReqByChassis)
• EČV (AVIReqByRegNum)
• OE (AVIReqByVehRegistrationCertId)

V prípade, že bude v rámci funkcionality komplexného vozidla vyplnený údaj Štát dovozu, tak systém JISCD odošle požiadavku na hľadanie údajov o vozidle jednej konkrétnej zapojenej krajine. Ak štát dovozu nebude vyplnený, systém JISCD odošle požiadavke na hľadanie údajov o vozidle všetkým zapojeným krajinám. Po vyhľadaní údajov o vozidle bude môcť používateľ zobraziť výpis týchto údajov, prípadne si ho aj vytlačiť. Funkcionalita bude umiestnená na obrazovke pre spracovanie návrhu.

1. 
   
   1. 
      
      1. 
         
         1. Zmeny v zozname zapojených krajín

Pre manuálne vyhľadanie aktuálnych údajov o vozidle prostredníctvom požiadavky odoslanej na jednu konkrétnu zapojenú krajinu bude nutné vybrať Štát dovozu v rámci funkcionality komplexného vozidla. Hľadanie v Eucaris bude po výbere štátu dovozu dostupné iba v prípade, ak tento štát bude jednou z krajín zapojených do systému Eucaris. Pre modul AVI, ktorý má nahradiť existujúci modul VHinfo, bude potrebné aktualizovať v systéme JISCD zoznam krajín, pre ktoré bude možné využívať funkcionalitu hľadania údajov o vozidle v Eucaris.

1. 
   
   1. 
      
      1. 
         
         1. Biznis kontrola Eucaris

Podľa nového zoznamu krajín zapojených v systéme Eucaris (modul AVI), bude aktualizovaná aj biznis kontrola Eucaris. Biznis kontrola bude upozorňovať na potrebu získania výpisu zo systému Eucaris, pri dovoze vozidiel z krajín zapojených do systému Eucaris. 

1. 
   
   1. Hľadanie počiatočných údajov o nových neevidovaných vozidlách v Eucaris (IVI/COC)

Do systému JISCD bude zavedená nová funkcionalita pre získanie výpisu o počiatočných údajov o vozidle zo systému Eucaris prostredníctvom modulu IVI/COC. Výpis bude slúžiť pre kontrolu údajov o novom neevidovanom vozidle pri spracovaní vybraných návrhov v intranete JISCD pre okresné úrady.

Funkcionalita bude dostupná v týchto návrhoch:

• Jednotlivé uznanie schválenia JDV z členského štátu
• Jednotlivé uznanie schválenia JDV zo zmluvného štátu
• Jednotlivé uznanie TS EÚ JDV z členského štátu
• Jednotlivé uznanie TS EÚ JDV zo zmluvného štátu
• Jednotlivé uznanie TS EÚ JDV z tretieho štátu
• Vnútroštátne jednotlivé schválenie JDV z členského štátu
• Vnútroštátne jednotlivé schválenie JDV z tretieho štátu
• Vnútroštátne jednotlivé schválenie JDV zo zmluvného štátu
• Univerzálny návrh (napr. JDV pre diplomatov)

Okrem týchto návrhov, bude možné získať výpis zo systému Eucaris aj v samostatnej funkcionalite intranetu JISCD určenej pre MD SR (ŠDÚ).

1. 
   
   1. 
      
      1. Zavedenie aplikačných služieb pre hľadanie údajov o novom vozidle

Za účelom získavania počiatočných údajov o vozidle zo systému Eucaris prostredníctvom modulu IVI/COC a ich využitia na generovanie výpisu zo systému Eucaris bude potrebné v systéme JISCD vytvoriť zodpovedajúce aplikačné služby. Dátové modely a služby budú vytvorené podľa špecifikácie Eucaris pre modul IVI/COC, resp. podľa špecifikácie SK modulu Eucaris (v správe MV SR).

1. 
   
   1. 
      
      1. Funkcionalita intranetu JISCD pre hľadanie počiatočných údajov o novom vozidle

Na vyššie uvedených návrhoch pribudne na obrazovke spracovania návrhu funkcionalita pre vyhľadanie počiatočných údajov o novom vozidle v systéme Eucaris prostredníctvom modulu IVI/COC.  Vyhľadanie údajov bude viazané na akciu používateľa. Po prijatí údajov zo systému Eucaris bude pre používateľa k dispozícii výpis údajov na stiahnutie alebo tlač.

1. 
   
   1. 
      
      1. Výpis údajov o novom vozidle

V systéme JISCD bude vytvorená nová šablóna pre výpis údajov zo systému Eucaris (modul IVI/COC). Výpis údajov bude pre používateľa k dispozícii vo formáte .pdf alebo .docx. Detailný návrh jednotlivých údajov zobrazených vo výpise bude upresnený v detailnom návrhu riešenia.

1. 
   
   1. 
      
      1. Doplnenie výpisu medzi generované dokumenty

Výpis údajov z Eucaris (modul IVI/COC) bude pri návrhoch v ktorých bude možné požiadať o tento výpis pridaný medzi generované dokumenty v rámci konania o návrhu. Výpis bude medzi generované dokumenty pridaný iba v prípade, že používateľ odošle požiadavku na prijatie údajov zo systému Eucaris a tiež ak z Eucaris  do JISCD tieto údaje prídu v rámci odpovede na požiadavku.

1. 
   
   1. Hľadanie počiatočných a/alebo aktuálnych údajov o vozidle z Eucaris pre ŠDÚ

Funkcionalita pre hľadanie počiatočných a/alebo aktuálnych údajov o vozidle z Eucaris bude zavedená aj v intranete JISCD pre ŠDÚ. Funkcionalita nebude viazaná na agendové návrhy, ale bude dostupná samostatne v rámci menu intranetu. Po vyhľadaní údajov o vozidle bude pre používateľa k dispozícii výpis z Eucaris na stiahnutie alebo tlač.

1. 
   
   1. Požiadavky MD SR na realizáciu projektu
      1. Funkčné požiadavky

Tabuľka 1- požiadavky MD SR na realizáciu projektu

1. ARCHITEKTÚRA RIEŠENIA PROJEKTU

1. 
   
   1. Biznis vrstva
      1. Aktuálny stav

Táto kapitola obsahuje prehľad aktuálneho stavu procesov obsiahnutých v tomto dokumente v systéme JISCD. Informácie predstavujú výsek služieb z existujúceho dokumentu Prehľad funkcionality Jednotného informačného systému v cestnej doprave Časť II. Funkcie JISCD dodaného MD SR.

1. 
   
   1. 
      
      1. 
         
         1. Spracovanie návrhu na jednotlivé uznanie schválenia JDV z členského štátu

Obrázok 1 - Spracovanie návrhu na jednotlivé uznanie schválenia JDV z členského štátu

1. 
   
   1. 
      
      1. 
         
         1. Spracovanie návrhu na jednotlivé uznanie schválenia JDV zo zmluvného štátu

Obrázok 2 - Spracovanie návrhu na jednotlivé uznanie schválenia JDV zo zmluvného štátu

1. 
   
   1. 
      
      1. 
         
         1. Spracovanie návrhu na uznanie typového schválenia EÚ jednotlivo dovezeného vozidla z členského štátu

Obrázok 3 - Spracovanie návrhu na uznanie typového schválenia EÚ jednotlivo dovezeného vozidla z členského štátu

1. 
   
   1. 
      
      1. 
         
         1. Spracovanie návrhu na uznanie typového schválenia EÚ jednotlivo dovezeného vozidla zo zmluvného štátu

Obrázok 4 - Spracovanie návrhu na uznanie typového schválenia EÚ jednotlivo dovezeného vozidla zo zmluvného štátu

1. 
   
   1. 
      
      1. 
         
         1. Spracovanie návrhu na uznanie typového schválenia EÚ jednotlivo dovezeného vozidla z tretieho štátu

Obrázok 5 - Spracovanie návrhu na uznanie typového schválenia EÚ jednotlivo dovezeného vozidla z tretieho štátu

1. 
   
   1. 
      
      1. 
         
         1. Spracovanie návrhu na vnútroštátne jednotlivé schválenie jednotlivo dovezeného vozidla z členského štátu

Obrázok 6 - Spracovanie návrhu na vnútroštátne jednotlivé schválenie jednotlivo dovezeného vozidla z členského štátu

1. 
   
   1. 
      
      1. 
         
         1. Spracovanie návrhu na vnútroštátne jednotlivé schválenie jednotlivo dovezeného vozidla zo zmluvného štátu

Obrázok 7 - Spracovanie návrhu na vnútroštátne jednotlivé schválenie jednotlivo dovezeného vozidla zo zmluvného štátu

1. 
   
   1. 
      
      1. 
         
         1. Spracovanie návrhu na vnútroštátne jednotlivé schválenie jednotlivo dovezeného vozidla z tretieho štátu

Obrázok 8 - Spracovanie návrhu na vnútroštátne jednotlivé schválenie jednotlivo dovezeného vozidla z tretieho štátu

1. 
   
   1. 
      
      1. 
         
         1. Univerzálny návrh

Obrázok 9- Univerzálny návrh

1. 
   
   1. 
      
      1. Návrh budúceho stavu

V tejto kapitole je návrh nových procesov, ktoré budú vytvorené v rámci zmenového konania alebo existujúcich procesov, ktoré budú v rámci zmenového konania upravené.

1. 
   
   1. 
      
      1. 
         
         1. Vyhľadanie aktuálnych údajov o evidovaných vozidlách v Eucaris (AVI)

Na nasledujúcom obrázku je zaznačený proces pre vyhľadanie aktuálnych údajov o evidovaných vozidlách v Eucaris prostredníctvom modulu AVI, tak ako je popísaný v kapitole Popis navrhovaného riešenia.

Obrázok 10- Vyhľadanie aktuálnych údajov o evidovaných vozidlách v Eucaris (AVI)

1. 
   
   1. 
      
      1. 
         
         1. Vyhľadanie počiatočných údajov o nových neevidovaných vozidlách v Eucaris (IVI/COC)

Na nasledujúcom obrázku je zaznačený proces pre vyhľadanie počiatočných údajov o nových neevidovaných vozidlách v Eucaris prostredníctvom modulu IVI/COC, tak ako je popísaný v kapitole Popis navrhovaného riešenia.

Obrázok 11 - Vyhľadanie počiatočných údajov o nových neevidovaných vozidlách v Eucaris (IVI/COC)

1. 
   
   1. 
      
      1. 
         
         1. Vyhľadanie počiatočných a/alebo aktuálnych údajov o vozidle z Eucaris pre ŠDÚ

Na nasledujúcom obrázku je zaznačený proces pre vyhľadanie počiatočných a/alebo aktuálnych údajov o vozidle z Eucaris pre ŠDÚ, tak ako je popísaný v kapitole Popis navrhovaného riešenia.

Obrázok 12 - Vyhľadanie počiatočných a/alebo aktuálnych údajov o vozidle z Eucaris pre ŠDÚ

1. 
   
   1. Aplikačná vrstva

Predpokladáme v tejto zmenovej požiadavke zmeny v aplikačnej architektúre, ktoré budú mať rozširujúci charakter bez zásadnej zmeny existujúcej architektúry.  

1. 
   
   1. 
      
      1. Rozsah informačných systémov

V rámci úprav, ktoré majú byť realizované sa bude meniť integrácia na systémy MVSR. Pribudne nová SOAP služba na ktorú sa bude JISCD integrovať a existujúca bude zmenená v súlade s modelom publikovaným MVSR podľa dodanej WSDL špecifikácie.  Pri existujúcej službe sa ráta len so zmenou modelu a zmenou obrazoviek, kde sa výstup služby zobrazuje.

1. 
   
   1. Fyzická architektúra

Fyzická architektúra ostáva nezmenená, nezavádzajú sa žiadne nové prvky a žiadne nie sú ani odstraňované.

1. 
   
   1. Softvérové licencie

V rámci zmenového konania nie je riešená úprava/zmena/rozšírenie licencií nad rámec existujúceho riešenia.

1. 
   
   1. Zálohovanie a obnova riešenia

V rámci zmenového konania nie je riešená úprava/zmena zálohovania a obnovy nad rámec existujúceho riešenia.

1. 
   
   1. Zabezpečenie dostupnosti

V rámci zmenového konania nie je riešená úprava/zmena zabezpečenia dostupnosti systému nad rámec existujúceho riešenia.

1. 
   
   1. Dátová vrstva - Dátový model

Existujúci dátový model ostáva bez zásadných zmien. 

Rozširuje o evidenciu histórie taxi vozidiel a dátumov priradenia k jednotlivým koncesiám v rámci registrov.

1. 
   
   1. Technologická vrstva

Toto zmenové konanie nemá dopad na technologickú vrstvu a nevyžaduje žiadnu zmenu na tejto vrstve.

1. 
   
   1. Bezpečnostná architektúra

Zmenové konanie nebude mať dopad na bezpečnosť a jej implementáciu v rámci systému.

1. PREVÁDZKA A ÚDRŽBA
   1. Prevádzkové požiadavky

Zmenové konanie nemá dopad na už existujúce prevádzkové požiadavky.

1. 
   
   1. Požadovaná dostupnosť IS:

Zmenové konanie nemá dopad na už existujúce požiadavky dostupnosti a parametre RTO a RPO.

1. ZÁVISLOSTI NA OSTATNÉ ISVS / PROJEKTY

V rámci realizácie projektu je vo všetkých jeho fázach systém JISCD závislý na funkčnosti a dostupnosti IS Eucaris v správe MV SR.

1. Prehľad koncových služieb, ktoré sú výstupom projektu

1. Legislatíva

• Zákon č. 106/2018 Z. z. o prevádzke vozidiel v cestnej premávke v znení neskorších právnych prepisov

1. VÝSTUPY PROJEKTU

Podľa platnej zmluvy sú výstupy projektu nasledovné

• Úprava dohody o integračnom zámere (DIZ) medzi MDVRR a MV SR o prepojení JISCD-ESD a EUCARIS
• Detailný návrh riešenia (DNR, podľa zmluvy so zadávateľom Funkčná špecifikácia)
• Testovacie prípady a testovacie scenáre
• Úprava používateľských príručiek v intranete JISCD pre OÚ a pre ŠDÚ
• Report stavu akceptačného testovania, protokoly, prezenčné listiny  akceptačného testovania

Prehľad akceptačných výhrad / Klasifikácia chýb a Plán testov, ktorého súčasťou je kapitola Manažment riadenia chýb a opráv

• Vykonané školenie s vybranými OÚ a prezenčné listiny
• Release notes
• Upravené časti aplikácie JISCD nasadené na produkčné prostredie

Iné produkty nie sú súčasťou dodávky projektu.

1. HARMONOGRAM

Doplnenie požadovanej funkcionality zaberie celkovo 6 mesiacov od potvrdenia objednávky po nasadenie do asistovanej prevádzky na produkčnom prostredí. Predpokladáme jeden aplikačný release a po nasadení podporu pri stabilizácii v trvaní 1 kalendárneho mesiaca od nasadenia. Celkovo 7 mesiacov od potvrdenia objednávky.

Práce na zmenovej požiadavke budú inicializované doručením objednávky. V rámci inicializačnej fázy vznikne Plán projektu vrátane harmonogramu implementácie. Implementácia je závislá na aktualizácii číselníkov, ktoré sú súčasťou riešenia.

Harmonogram implementácie bude upresnený na základe detailného návrhu riešenia. Po schválení DNR bude prebiehať príprava Testovacích prípadov a testovacích scenárov, ktoré tvoria akceptačné kritéria pre implementačnú časť. Testovacie prípady a testovacie scenáre budú predmetom akceptácie zástupcov vybraných OÚ. Vybrané OÚ budú súčasťou akceptačných testov. Posudzovanie chýb počas Akceptačného testovania sa riadi bodom č. 6.6  Zmluvy.

V realizačnej fáze projektu budú odovzdané všetky produkty/výstupy do akceptácie. Implementácia požadovaných zmien bude realizovaná ako jeden produkt.

Školenie vybraných OÚ bude realizované v rozsahu UAT testovania, formou online prezentácie. Školenie bude nahrávané a nahrávka bude tvoriť doplnok k prezenčnej listine.

Riadenie zmenovej požiadavky bude kontrolované mesačnými správami o stave projektu. Mesačná správa zhodnotí časové plnenie, stav tímu,  stav prípravy dohodnutých produktov, issues na projekte a riziká  projektu.

Účinnosť Zmenového konania: Po schválení Zmenového konania na základe vystavenej a doručenej objednávky.

Harmonogram obsahuje 2 fakturačné míľniky  FM1 – Fakturačný míľnik 1 akceptácia DNR  a FM2 – Fakturačný míľnik 2 nasadenie akceptovanie a Go Live.

• 
  
  1. ČASOVÉ ZÁVISLOSTI
• Inicializačná fáza projektu začína doručením objednávky dodávateľovi.
• V prvých krokoch inicializačnej fázy vznikne Detailný plán
• V realizačnej fáze projektu bude tvorený návrh riešenia (DNR) s popisom všetkých zmien a návrhom riešenia týchto zmien.
• Schválenie DNR  je nevyhnutnou požiadavkou pre spustenie implementácie.
• Pre pripomienkovanie a schválenie DNR je alokovaný čas 10 pracovných dní.
• Testovacie prípady a testovacie scenáre sú pripravované až po schválení DNR a sú predmetom schvaľovania.
• V prípade, že nedôjde k schváleniu Testovacích prípadov a testovacích scenárov do 5 pracovných dní pred Akceptačným testovaním, bude Akceptačné testovanie realizované na základe predložených dokumentov bez aplikovania nedohodnutých výhrad.
• Testovacie prípady a testovacie scenáre budú doručené najneskôr 5 kalendárnych dní pred Akceptačným testovaním tímu, ktorý bude realizovať UAT.
• Najskorší možný termín nasadenia na produkčné prostredie je po úspešnom UAT.

1. ROZPOČET A PRÍNOSY
   1. ROZPOČET

Rozpočet pre implementáciu požadovanej zmeny je definovaný na základe platných sadzieb zmluvy a stanovených náročností realizácie. Rozpočet je zahrnutý v prílohe č. 1

1. 
   
   1. PRÍNOSY

1. PRÍLOHY

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

1.História dokumentu

2.Účel dokumentu

V súlade s Vyhláškou 401/2023 Z.z. je dokument I-03 Prístup k projektu určený na rozpracovanie detailných informácií prípravy projektu z pohľadu aktuálneho stavu, budúceho stavu a navrhovaného riešenia.
Dokument Prístup k projektu v zmysle vyššie uvedenej vyhlášky má obsahovať opis navrhovaného riešenia, architektúru riešenia projektu na úrovni biznis vrstvy, aplikačnej vrstvy, dátovej vrstvy, technologickej vrstvy, infraštruktúry navrhovaného riešenia, bezpečnostnej architektúry, špecifikáciu údajov spracovaných v projekte, čistenie údajov, prevádzku a údržbu výstupov projektu, prevádzkové požiadavky, požiadavky na zdrojové kódy. Dodávané riešenie musí byť v súlade so zákonom. Zároveň opisuje aj implementáciu projektu a preberanie výstupov projektu.
Inštrukcia: Šedý text v celom dokumente predstavuje nápoveď 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.1Použité skratky a pojmy

2.2Konvencie 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

• U – uží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 – nefunkč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.
  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-04 (M-05 Analýza nákladov a prínosov - BC/CBA, karta: Katalóg požiadaviek).

3.Popis navrhovaného riešenia

Opis navrhovaného riešenia sa spracováva až po definovaní vybranej alternatívy riešenia na základe výsledkov MCA z dokumentu Projektový zámer (I-02).
Obsahom tejto kapitoly je manažérsky sumár navrhovaného riešenia z pohľadu architektúry.

4.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í/rozvoji 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 ilustrujúce dopad projektu v týchto vrstvách, aby príslušné zainteresované osoby mohli vyhodnotiť, akým spôsobom ich projekt ovplyvní.
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 ).
V  dokumente Prístup k projektu popíšte súčasný stav (ďalej AS IS) architektúry aj s príslušným architektonickým modelom a budúci stav (ďalej TO BE) 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).
Obsah tejto kapitoly je tiež prehľadom realizácie výstupu M-06 - aktualizácia evidencie e-Government komponentov v centrálnom metainformačnom systéme verejnej správy (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 centrálneho metainformačného systému verejnej správy (MetaIS) bezodkladne podľa § 12 ods. 1 písmeno b zákona 95/2019 Z.z.
Objednávateľ priebežne aktualizuje evidenciu e-Government komponentov v centrálnom metainformačnom systéme verejnej správy (MetaIs), vrátane architektonických modelov. Pri odovzdaní výstupu I-03 Prístup k projektu 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 do projektovej dokumentácie I-03 Prístup k projektu ako prílohu  vo výmennom formáte pre uloženie modelu,³ 
• 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-03 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 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) 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 eGov (napr. spoločné moduly ústredného portálu verejnej správy, iné vlastné alebo externé ISVS, služby alebo dátové registre).

4.1Biznis vrstva

Doplňte 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,
Doplňte popis súčasného - AS IS - stavu biznis vrstvy:

• Identifikácia kľúčových životných situácii (ŽS), ktorých sa projekt týka. Sústrediť sa menší počet najdôležitejších životných situácií, ktoré predstavujú väčšinu ekonomických nákladov občanov/podnikateľov a nákladov úradov.
• Identifikácia existujúcich koncových služieb, ktorých sa projekt týka
• Procesné diagramy, ktoré popisujú postupnosť krokov, komunikácie a zodpovedností, ktoré sú v súčasnom stave potrebné pre vyriešenie každej dotknutej ŽS alebo poskytnutie koncovej služ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),
• Optimalizačné príležitosti, ktoré popisujú možnú zmenu vo výkone procesov VS, v IKT podporujúcich výkon procesov, prípadne v organizačnom zabezpečení výkonu procesov ŽS.
• Ukazovatele a metriky dôležité pre vyhodnotenie aktuálneho stavu poskytovania služieb, napr.:
• 
  
  • 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, poštovné, atď.).
    Doplňte popis budúceho - TO BE - stavu biznis vrstvy:
• Doplňte 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 (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,
• Identifikujte a popíšte projektom budované, resp. rozvíjané koncové služby. 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. 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),
• 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, 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é ukazovatele a metriky dôležité pre vyhodnotenie dosiahnutia cieľov projektu a vyhodnotenie úrovní poskytovania služieb, napr.:
  • 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).
    
    Obrázok 1 Procesný diagram - príklad

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

Obrázok 2 Model biznis architektúry (aktéri-koncoví používatelia, koncové služby, procesy) – príklad

4.1.2Jazyková podpora a 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.

4.2Aplikačná vrstva

Popíšte aplikačnú architektúru riešenia na úrovni ISVS, ich modulov a vzťahov medzi nimi a vzťahov na externé prostredie. Podľa potreby zvýraznite dôležité zmeny v architektúre, dôležité vzťahy a toky dát, vzťah riešených ISVS s okolím a externými SVS.
Budované/rozvíjané informačné systémy, vrátene ich 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).
Uveďte model a popis AS IS stavu aplikačnej vrstvy architektúry: informačné systémy (ISVS), aplikačné služby a ich podpora realizácie koncových služieb.
Uveďte model a popis TO BE stavu navrhovaného riešenia aplikačnej vrstvy architektúry s prepojením na biznis architektúru – ako aplikačná architektúra a jej komponenty podporuje realizáciu biznis služieb, riešenia živ. situácií a splnenie cieľov projektu

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

Obrázok 4 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

4.2.1Rozsah informačných systémov – AS IS

Uveďte dotknuté ISVS a ich moduly AS IS:

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

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

4.2.3Využí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.

4.2.4Prehľad plánovaných integrácií ISVS na nadrezortné ISVS – spoločné moduly podľa zákona č. 305/2013 e-Governmente – 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.

4.2.5Prehľad plánovaného využívania iných ISVS (integrácie) – 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 .

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

Uveďte v nasledujúcej tabuľke budované aplikačné služby, realizáciu koncových služieb aplikačnou službou, koncová služba by mala byť realizovaná aspoň jednou aplikačnou službou (KS môžu realizovať aj viaceré aplikačné služby). Všetky aplikačné služby a ich vzťah na koncové služby musia byť evidované v MetaIS.

4.2.7Aplikačné služby na integráciu – 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 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//rozvíjaného ISVS na príslušné aplikačné služby nadrezortných ISVS. 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. Detailný popis služieb IS CSRÚ a poskytovaných objektov evidencie je v aktuálnej verzii integračného manuálu IS CSRÚ.
• 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 Gatewy).
• 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.

  AS (Kód MetaIS)	Názov AS	Realizuje ISVS (kód MetaIS)	Poskytujúca alebo Konzumujúca	Integrácia cez CAMP	Integrácia s IS tretích strán	SaaS	Integrácia na AS poskytovateľan (kód MetaIS)

• 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 Zz. 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 Zz 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 5 Integrácie na spoločné moduly ÚPVS – ref. príklad
  
  Obrázok 6 Integrácie na IS CAMP- referenčný príklad
  
  Obrázok 7 Integrácie na IS CSRÚ – ref. príklad
  
   

4.2.8Poskytovanie údajov z ISVS do IS CSRÚ – TO BE

Uveďte v nasledujúcej tabuľke prehľad poskytovaných údajov (objektov evidencie, ďalej OE) z ISVS do IS CSRÚ v TO BE stave.

4.2.9Konzumovanie údajov z IS CSRU – TO BE

Uveďte v nasledujúcej tabuľke prehľad konzumovaných údajov z IS CSRÚ v TO BE stave. Súčasné dostupné objekty evidencie a údaje v IS CSRÚ sú uvedené v integračnom manuáli IS CSRÚ.

4.3Dátová 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

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.

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

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),
• V nasledujúcej tabuľke uveďte a popíšte Objekty Evidencie (ďalej len OE) v jednotlivých ISVS/registroch súvisiace s projektom.
• Doménový model by mal byť v súlade s existujúcim Centrálnym modelom údajov verejnej správy (viac informácií na: https://mirri.gov.sk/sekcie/informatizacia/egovernment/datova-kancelaria/interoperabilita/ a https://metais.vicepremier.gov.sk/publicspace?pageId=59836112.).
• 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 (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

ID OE	Objekt evidencie - názov	Objekt evidencie - popis	Referencovateľný identifikátor URI dátového prvku
			(Ak nie je priradené URI uveďte „Nemá“)
			Obrázok 8 Doménový model - príklad Obrázok 9 Zjednodušený doménový model - príklad

4.3.3Referenč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 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.3.3.1Objekty evidencie z pohľadu procesu ich vyhlásenia za referenčné

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ť“.

• 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é v metodickom usmernení 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
• 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 4.3.2 Dátový rozsah projektu - Prehľad objektov evidencie - TO BE:

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

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 TO BE stavu využitia údajov a jeho bezproblémovej aplikovateľnosti.
V tabuľke uveďte OE z tabuľky uvedenej v kapitole 4.3.2 Dátový rozsah projektu - Prehľad objektov evidencie - TO BE:
Poznámka: Pre úspešné napojenie ISVS na IS CSRÚ v roli konzumenta údajov je nutné postupovať podľa integračného manuálu IS CSRÚ.

4.3.4Kvalita a čistenie údajov

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

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 4.3.2 Dátový rozsah projektu - Prehľad objektov evidencie - TO BE:

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

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

4.3.5Otvorené ú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 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 údajov RDF, OWL, TriX, JSON.
  V tabuľke uveďte OE z tabuľky uvedenej v kapitole 4.3.2 Dátový rozsah projektu - Prehľad objektov evidencie - TO BE:

4.3.6Analytické údaje

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.  
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: https://data.gov.sk/id/egov/isvs/9655 ).
Informácie k sprístupneniu dátových zdrojov organizácie na analytické účely: https://mirri.gov.sk/sekcie/informatizacia/egovernment/datova-kancelaria/analyticke-udaje/

4.3.7Moje ú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 - 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/egovernment/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 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). 
  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 4.3.2 Dátový rozsah projektu - Prehľad objektov evidencie - TO BE.

4.3.8Prehľ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 4.3.2 Dátový rozsah projektu - Prehľad objektov evidencie - TO BE.

4.4Technologická vrstva

4.4.1Prehľad technologického stavu - AS IS

Uveďte popis a model technologickej vrstvy AS IS stavu, používané výpočtové prostriedky, konfigurácie siete, problematické body, ktoré je potrebné projektom riešiť.

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

Doplňte pre TO BE stav do nasledujúcej tabuľky požiadavky na výkonnostné parametre, 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, …).

4.4.3Návrh riešenia technologickej architektúry

Uveďte 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.
  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ť novo vyvíjaného ISVS od cloudového prostredia by malo byť základnou prioritou a podmienkou architektúry ISVS.

4.4.4Využí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, kap. 2.1.4.3 ISVS využívajúci infraštruktúrne služby.

• 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. 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: https://www.mirri.gov.sk/sekcie/informatizacia/egovernment/vladny-cloud/katalog-cloudovych-sluzieb.

4.5Bezpečnostná architektúra

Uveďte popis AS IS stavu z pohľadu súčasného riešenia bezpečnostnej architektúry,
Uveďte popis TO BE stavu riešenia bezpečnostnej architektúry (+ popis alternatív),
Uveďte 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íšte 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).
  Uveďte požiadavky na realizáciu Bezpečnostného projektu⁶
  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).

5.Závislosti na ostatné ISVS / projekty

Uveďte sumárny prehľad všetkých projektov, programov a informačných systémov (ISVS), od ktorých je realizácia pripravovaného projektu závislá.
Uveďte ako záujmové osoby (stakeholder) organizačné jednotky verejnej správy zodpovedné za poskytnutie potrebnej súčinnosti pre pripravovaný projekt.

6.Zdrojové kódy

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.Prevádzka a údržba

Doplňte popis AS IS stavu zabezpečenia prevádzky a údržby a úroveň poskytovania služieb (SLA).
Doplňte popis TO BE stavu zabezpečenia prevádzky a údržby 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.1Prevádzkové požiadavky

Uveďte popis L1 úrovne – požiadavky / očakávania
Uveďte popis L2 úrovne – požiadavky / očakávania
Uveďte popis L3 úrovne – požiadavky / očakávania
Uveďte štandardný čas podpory, čas/rýchlosť odstraňovania vád, dostupnosť systému, zálohovanie, plán obnovy systému, atď.
Uveďte 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í),

7.1.2Rieš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:

• 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.2Požadovaná dostupnosť IS:

7.2.1Dostupnosť (Availability)

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
  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.2RTO (Recovery Time Objective)

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.3RPO (Recovery Point Objective)

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ť 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

Posúďte a doplňte spôsoby realizácie projektu a ich dopad na harmonogram projektu a preberanie výstupov pripravovaného projektu.
V zmysle Vyhlášky 401/2023 Zz 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.
V zmysle vyhlášky 401/2023 Zz o riadení projektov a zmenových požiadaviek v prevádzke 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 PI-03 Prístup k projektu a v M-05 Analýza nákladov a prínosov - 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.

10.Prílohy

V prípade potreby doplňte zoznam príloh 
Poznámka: odporúčame, aby ste si VŠETKY TABUĽKOVÉ VSTUPY evidovali a spravovali v jednom centrálnom súbore formátu EXCEL – s cieľom minimalizovať budúcu prácnosť s aktualizáciou a udržiavaním obsahu.
Inštrukcie k verejnému pripomienkovaniu:

• Podľa §4 ods. 10 vyhlášky č. 401/2023 Z.z je potrebné zrealizovať pripomienkovanie Projektového prístupu odbornou verejnosťou, zaevidovať a vyhodnotiť pripomienky odbornej verejnosti.
• Oznámenie o začatí verejného pripomienkovania zverejniť v centrálnom metainformačnom systéme verejnej správy na mieste určenom Orgánom vedenia.
• Dať na schválenie riadiacemu výboru výstupy po zverejnení vyhodnotenia pripomienok.
• Vyhodnotenie zverejniť na webovom sídle objednávateľa (do projektového adresára).
  1 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ť.
  2 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.
  3 The Open Group ArchiMate Model Exchange File Format Standard a špecifikácia BPMN 2.0
  4 Napr. modelovací nástroj Archi - Open Source ArchiMate Modelling: https://www.archimatetool.com.
  5 Napr. modelovací nástroj pre BPMN - Camunda Modeler - Open Source Desktop Modeler: https://camunda.com/download/modeler/.
  6 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)
  Strana 23/23