I-03 Prístup k projektu (pristup_k_projektu)

PRÍSTUP K PROJEKTU

 Vzor pre manažérsky výstup I-03

podľa vyhlášky MIRRI č. 401/2023 Z. z. 

Schvaľovanie dokumentu

1. História dokumentu

1. Úč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.

Účelom dokumentu je na technickej úrovni popísať cieľ projektu “Implementačný nástroj podpory gigabitových infraštruktúr v zmysle Digitálneho kompasu 2030”, ktorého zámerom je posilnenie rozvoja širokopásmových sietí a budovanie trhového prostredia, ktoré podporuje zdravú konkurenciu medzi poskytovateľmi infraštruktúry.

Cieľom projektu je prekonať doterajšie limity v systéme Monitorovací systém pre reguláciu a štátny dohľad (ďalej len “MSRŠD”), ktorý dokáže údaje o bielych adresách, projektoch a investíciách síce evidovať, no neponúka ucelenú analytickú vrstvu či automatizované riadenie intervenčných procesov. 

1. 
   
   1. Použité skratky a pojmy

1. 
   
   1. Konvencie pre typy požiadaviek (príklady)

Funkcionálne (používateľské) požiadavky majú nasledovnú konvenciu:

FRxx

1. U            – užívateľská požiadavka
2. R             – označenie požiadavky
3. xx            – číslo požiadavky

Nefunkčné (kvalitatívne, výkonové - Non Functional Requirements - NFR) požiadavky majú nasledovnú konvenciu:

NRxx

1. N            – nefukčná požiadavka (NFR)
2. R             – označenie požiadavky
3. xx            – číslo požiadavky

Ostatné typy požiadaviek môžu byť ďalej definované PM.

1. 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.

Primárnym cieľom projektu GigaOffice je uľahčiť a zefektívniť rozvoj širokopásmovej infraštruktúry na Slovensku prostredníctvom automatizácie kľúčových procesov, prepojenia dostupných údajov a zosúladenia postupov medzi relevantnými inštitúciami (BCO, telekomunikační operátori, samosprávy, rezortné orgány). Projekt reflektuje potreby moderného eGovernmentu, minimalizuje administratívne zaťaženie a vytvára predpoklady na transparentné a cielené investovanie do rozvoja digitálnej konektivity v súlade s národnými a európskymi stratégiami.

Podciele projektu GigaOffice:

• Zjednodušená identifikácia bielych adries: Zavedením centrálnej evidencie a automatizovaného spracovania dát sa znižuje riziko chýb a duplicít, urýchľuje sa vyhlasovanie verejných konzultácií a zlepšuje sa plánovanie intervencií.
• Efektívne zdieľanie a využitie dostupných údajov: Uplatnením princípu „jeden-krát a dosť“ sa minimalizuje opakované zadávanie dát, čím sa šetrí čas a zvyšuje kvalita a aktuálnosť rozhodovacích podkladov.
• Uľahčenie participácie a spolupráce: Online nástroje pre verejné konzultácie a elektronickú komunikáciu zlepšujú zapojenie firiem a samospráv, posilňujú transparentnosť a pomáhajú reagovať na reálne potreby konkrétnych lokalít.
• Rýchlejšie a flexibilnejšie projektové riadenie: Jednotná platforma na monitorovanie rozvojových projektov prispieva k efektívnemu čerpaniu verejných zdrojov, zrýchľuje realizáciu investícií a poskytuje lepší prehľad o stave a výsledkoch projektov.
• Komplexný prehľad a strategické rozhodovanie: Vďaka prepojeným systémom a dostupným dátam získavajú kompetentné orgány ucelený obraz o pokrytí, potrebách a prioritách, čo umožňuje adresné a transparentné plánovanie ďalšieho rozvoja širokopásmovej infraštruktúry.

Z možných variantov riešenia tento dokument na detailnejšej úrovni popisuje Optimálny (želaný) variant v zmysle záverov Multikriteriálnej analýzy (MCA). Tento variant pokrýva požiadavky všetkých stakeholderov.

Ide o

Alternatíva 3 – TO BE STAV Optimálny (želaný)

Rozšírenie existujúceho Monitorovacieho systému pre reguláciu a štátny dohľad (MSRŠD) o nové funkcionality potrebné pre GigaOffice predstavuje efektívne riešenie, ktoré umožňuje využitie existujúcej infraštruktúry a overených technologických komponentov. Tento prístup prináša významnú úsporu nákladov na implementáciu, keďže eliminuje potrebu budovania nového systému a umožňuje zachovať existujúce integrácie s inými systémami.

Ďalšou výhodou je, že prevádzkový tím už disponuje znalosťami systému, čo znižuje požiadavky na školenia a urýchľuje adaptáciu na nové funkcionality. Správa jedného centralizovaného systému je zároveň jednoduchšia a efektívnejšia, pričom zostávajú zachované existujúce bezpečnostné mechanizmy, čím sa eliminuje potreba dodatočných bezpečnostných opatrení.

Implementácia nových funkcionalít v rámci MSRŠD zároveň umožňuje skrátiť čas potrebný na implementáciu riešenia, zabezpečuje jednotné používateľské rozhranie a centralizovanú správu dát, čím sa zjednodušuje riadenie a ukladanie informácií. Zachovanie existujúcich procesov prevádzky a podpory navyše minimalizuje potrebu rozsiahlych zmien v operačných a podporných postupoch, čím sa zabezpečí plynulý prechod na nové funkcionality bez narušenia súčasných procesov.

1. 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ľ[1] 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[2], 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,[3] 
• 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[4], 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[5].  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).

1. 
   
   1. Biznis 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

1. 
   
   1. 
      
      1. Prehľ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

1. 
   
   1. 
      
      1. Jazyková 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.

1. 
   
   1. Aplikač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

Aktuálny stav aplikačnej architektúry - AS IS

Aplikačná architektúra projektu MSRŠD bola postavená modulárne postavená na princípoch SOA. Projekt bol rozdelený do niekoľkých aplikačných komponentov, ktoré sú usporiadané do 3 hlavných celkov združujúcich aplikačné moduly podľa zamerania ich činnosti. MSRŠD pozostáva z nasledujúcich modulov:

1. Centrálny dohľad nad meracou technikou
2. Monitoring stavu pokrytia Broadband
3. Spracovávanie mapových a priestorových podkladov (zakresľovanie infraštruktúry)
4. Mobilná analytika (Spracovanie dát z meracej techniky)
5. Zber dát pre potreby BCO
6. Plánovanie a riadenie investícií do Broadband
7. Správa štátnych intervencií pre oblasť Broadband
8. Správa a riadenie verejných konzultácií
9. BCO BackOffice
10. BCO Portál
11. Integračná platforma
12. DMS
13. SmartAnalytics/CFMS

Hlavnými celkami súčasnej aplikačnej architektúry, ktoré združujú funkcionalitu MSRŠD a zabezpečujú hlavný chod systému sú:

• BCO Backoffice
• BCO portál
• CDNMT

1. Modul – Centrálny dohľadu nad meracou technikou (CDNMT)

Zhrnutie funkcionality:

Modul obsahuje nástroje na správu a výkon meraní frekvenčného spektra a QoS parametrov služby prístupu do siete internet.

Zdroje dát:

Dáta k plánovaným meraniam sú vkladané do systému podľa potrieb BCO a ÚPREKaPS vo forme požiadaviek na meranie.

Mobilné meracie jednotky sú združené systémom Movys Integra, ktorý predstavuje zdroj dát vo forme výsledkov z merania zasielaných do CDNMT.

Integrácia s inými modulmi a systémami:

Monitoring stavu pokrytia Broadband, Nástroj pre spracovávanie mapových a priestorových podkladov (zobrazovanie meracích jednotiek v reálnom čase v priestore), Mobilná analytika (Spracovanie dát z meracej techniky)

Popis funkcionality:

Pre účely plánovania meraní modul obsahuje nástroj s prehľadom už vykonaných meraní vo forme filtrovateľného zoznamu ako aj mapového rozhrania. Zoznam meraní obsahuje relevantné atribúty ako dátum merania, lokalita a výsledky. Mapové rozhranie zakresľuje historické výsledky merania na mapu SR. Modul ďalej obsahuje nástroj na plánovanie budúcich meraní. Tento nástroj spravuje harmonogram merania pre jednotlivé mobilné meracie jednotky. V rámci plánovania merania sú špecifikované konkrétne parametre merania, trasa, prípadne fixná lokalite. Nástroj cez používateľsky prívetivé rozhranie umožňuje systematickým spôsobom plánovať merania. Modul poskytuje Centru dohľadu nad meracou technikou, nástroje pre riadenie prebiehajúcich meraní, umožňuje sledovať meraciu techniku v reálnom čase a tým prispôsobovať merania podľa potreby. Tento modul tiež prijíma a ukladá dáta z meracej techniky v „surovom“ formáte pre potrebu ich auditu v budúcnosti v dátovej vrstve MSRŠD.

Merania sú plánované na základe:

• Interných potrieb a plánov BCO/ÚPREKaPS plynúcich z aktuálneho pokrytia SR širokopásmovým internetom
• Vstupov do verejných konzultácií, v rámci ktorých sa operátori zaviazali pokryť určitú lokalitu s pevným harmonogramom
• Vstupov do verejných konzultácií, v rámci ktorých operátori tvrdia, že v danej lokalite poskytujú služby širokopásmového internetu
• Potrieb a plánov meraní ÚPREKaPS
• Externých žiadostí o premeranie jednotlivých lokalít

Z pohľadu ÚPREKaPS je možné v rámci nástroja koordinovať plánované merania s plánmi BCO, špecifikovať vlastné plánované merania a alokovať mobilnú meraciu techniku.

Výstupy:

Výstupom modulu je podrobný plán meraní BCO a ÚPREKaPS, ktorý ďalej špecifikuje typ merania, lokalitu alebo trasu a účel merania.

1. Modul – Monitoring stavu pokrytia Broadband

Zhrnutie funkcionality:

Modul slúži na generovanie aktuálneho a plánovaného stavu pokrytia SR širokopásmovým internetom na základe viacerých zdrojov dát.

Zdroje dát:

Zdrojové dáta pre súčasný stav pokrytia sú čerpané z primárnych zdrojov:

1. Vstupy nadefinované v rámci verejných konzultácií a následne zhromaždených pomocou modulu Zber dát pre potreby BCO
2. Z meraní realizovaných prostredníctvom mobilnej meracej techniky.

Integrácia s inými modulmi a systémami:

Vzhľadom na dátové požiadavky je modul integrovaný na moduly: Zber dát pre potreby BCO, Centrum dohľadu nad meracou technikou, Mobilná analytika (Spracovanie dát z meracej techniky)

Popis funkcionality:

Modul priebežne aktualizuje zoznam bielych miest na úrovní adries v rámci SR a kategorizuje ich podľa maximálnej rýchlosti možného pripojenia (<30 Mbps; <100 Mbps; <1 Gbps; atď.). Pre účely identifikovania stavu zoznamu bielych miest modul využíva vstupy do verejných konzultácií k plánovanej infraštruktúre ako aj podklady z modulu Nástroj pre spracovávanie mapových a priestorových podkladov (mapa pokrytia, zakresľovanie infraštruktúry) k plánovanej infraštruktúre. Po premeraní danej lokality mobilnou meracou technikou alebo po tom, ako poskytovateľ širokopásmového internetu nedodrží plánovaný harmonogram zavádzania pokrytia, BCO má možnosť prehodnotiť stav pokrytia (prípadne plánovaného pokrytia) bieleho miesta. BCO má ďalej možnosť:

• Generovať stav očakávaného pokrytia k danému dátumu v budúcnosti
• Skúmať stav pokrytia k špecifickému dátumu v minulosti
• Filtrovať pokrytie územia SR na základe zvolenej rýchlosti pre koncového používateľa

Pred zaradením nových dát do stavu pokrytia SR musia byť najprv validované zo strany BCO a ÚPREKaPS a vyhodnotené ako platné, aby bolo zabránené korupcií dát.

Modul poskytuje verejne dostupné rozhranie cez webový portál v rámci ktorého je prostredníctvom grafického mapového rozhrania prezentovaný súčasný ako aj budúci stav pokrytia širokopásmovým internetom na úrovni adresy.

Výstupy:

Výstup je vo forme zoznamu, ktorý je exportovateľný do bežne používaných formátov (CSV, XLS apod.). Modul ďalej poskytuje grafické mapové rozhranie, na ktorom je možné znázorniť súčasný ako aj plánovaný stav pokrytia pre jednotlivé adresné body.

1. Modul – Spracovávanie mapových a priestorových podkladov (GIS)

Zhrnutie funkcionality:

Modul spracováva priestorové podklady k súčasnej a plánovanej infraštruktúre pre daný účel s možnosťou ich prezentácie v mapovej podobe.

Zdroje dát:

Dáta sú zadávané prostredníctvom mapového, webového rozhrania, ktoré je dostupné na webovom portáli a z modulu Zber dát pre potreby BCO.

Integrácia s inými modulmi a systémami:

1. Mobilné meracie jednotky
2. Integrácia na modul Zber dát pre potreby BCO

Popis funkcionality:

Modul spravuje súčasný stav pasívnej telekomunikačnej infraštruktúry, ako aj jej plánovaný rozvoj na základe vstupov (vo forme priestorových podkladov) do verejných konzultácií a podkladov k plánovaným intervenciám. U plánovanej infraštruktúry nástroj eviduje očakávaný harmonogram jej výstavby a spustenia. Nástroj ďalej umožňuje zobrazenie uložených priestorových podkladov na mape.

Z pohľadu BCO nástroj poskytuje nasledujúcu funkcionalitu:

• Vizualizácia súčasného stavu širokopásmovej infraštruktúry v mapovom rozhraní
• Zobrazenie vstupov z jednotlivých verejných konzultácií alebo dopytových výziev v rámci mapového rozhranie (pre jednotlivých poskytovateľov širokopásmového internetu alebo pre všetky vstupy z danej konzultácie)
• Vizualizácia budúceho stavu širokopásmovej infraštruktúry k danému dátumu na základe geografických údajov poskytnutých v rámci verejných konzultácií a harmonogramov ich zavedenia
• Možnosť správy informácií o prvkoch pasívnej infraštruktúry (napr. konverzia prvkov z plánovanej vrstvy do súčasnej, v prípade že prvky boli už vybudované, alebo možnosť pridať/vymazať prvok na základe externých informácií, pridávanie plánov na výstavbu infraštruktúry štátom alebo na základe dopytových výziev)

Modul má verejne dostupný nástroj pre prezentáciu súčasného stavu širokopásmového pokrytia v rámci mapového rozhrania na webovom portáli. Kým podklady k súčasnému stavu sú verejne dostupné, vstupy do verejných konzultácií sú považované za obchodne dôverné a nie sú verejne dostupné. Pre účely možnosti lepšieho plánovania vlastnej infraštruktúry pre poskytovateľov širokopásmového internetu a za účelom transparentnosti sú ďalej zverejňované plány k výstavbe infraštruktúry štátom alebo formou dopytových výziev.

Výstupy:

Výstupy modulu sú informácie o súčasnom a plánovanom širokopásmového pokrytia vo forme mapového rozhrania.

1. Modul – Mobilná analytika

Zhrnutie funkcionality:

Modul Mobilná Analytika predstavuje aplikačné programové vybavenie pre podporu meraní širokopásmového internetu, podporu bezpečnosti prenosu a monitoring pokrytia oblasti širokopásmovým internetom.

Zdroje dát:

1. Mobilné meracie jednotky

Integrácia s inými modulmi a systémami:

1. Centrum dohľadu nad meracou technikou
2. Monitoring stavu pokrytia Broadband
3. Spracovávanie mapových a priestorových podkladov (zakresľovanie infraštruktúry)
4. Dátová vrstva

Popis funkcionality:

• Zobrazovanie a analýza údajov z meraní pripojených systémov
• Podpora bezpečnosti prenosu prenášaných dát šifrovaním
• Monitoring polohy, kvality prenosu a stavu pripojených zariadení
• VPN a vzdialený prístup k sieti fixných a mobilných monitorovacích staníc
• Vizualizáciu pokrytia analyzovanej oblasti mobilným signálom
• Diagnostika pripojenia konfigurovateľná na desktope pracovníkov ÚPREKaPS
• Funkcie sieťovej analýzy a vizualizácie monitoringu
• Vykonávanie sofistikovaných analýz nad dátami
• Automatizovanie opakujúcich sa úloh prostredníctvom intuitívneho vizuálneho modelovacieho nástroja
• Dátová integrácia na ostatné moduly MSRŠD

Na základe plánovaných meraní z modulu Centrum dohľadu nad meracou technikou sú vykonávané mobilnými meracími jednotkami merania frekvenčného spektra a fyzických pripojení do internetu. Výstupy z týchto meraní obsahujú dáta, ktoré sú pripravené do formy vhodnej na spracovanie, analyzovanie a uložené v štruktúrovanej podobe. Merania sú vždy realizované na určité územie, trasu alebo konkrétu adresu.

Prostredníctvom služieb modulu Mobilnej analytiky je možné zobrazovať, analyzovať a editovať údaje o parametroch elektronických komunikácii v reálnom čase a v prostredí webu. Namerané údaje sú uložené v dátovej vrstve riešenia MSRŠD. Koncové služby modulu sú poskytované iným modulom a IS prostredníctvom API rozhraní..

Pre účely BCO modul zabezpečuje mapovanie meraného územia na konkrétne adresy, ktoré spadajú do predmetného územia. BCO ďalej používa nasledujúce údaje na úrovni adries:

• Pokrytie širokopásmovým internetom
• Zoznam poskytovateľov prístupu do širokopásmového internetu, u ktorých bolo namerané pokrytie danej adresy
• Maximálna nameraná rýchlosť sťahovania
• Indikácia kvality poskytovaného pokrytia (u rádiových sietí sila signálu, latencia a pod.)
• Možnosť spracovania údajov v rámci štvorcov 100 x 100 m

Úložisko dát z meraní (databáza modulu)

• Databáza modulu je úložiskom metadát z meraní
• Každá zmena v databáze je auditovateľná
• Dátový model databázy umožňuje zobraziť stav dát ku konkrétnemu dátumu v minulosti

Správa dátového úložiska modulu umožňuje, aby boli namerané dátové entity začleňované do konceptu jednotného dátového modelu MSRŠD a ÚPREKaPS. Dodané riešenie zaručuje vlastnosti ACID (atomicita, konzistencia, oddelenosť, trvalosť). Podporuje výmenu dát v reálnom čase.

Systém na správu databázy podporuje:

• Import dát a konverziu dát z rôznych vstupných formátov meracích zariadení a senzorov
• Tvorbu a úpravu dát prijatých dát
• Vyhľadávanie v dátach cez webové API Vykonávanie konfigurovateľných analýz a reportov
• Vizualizáciu vytvorených analýz cez webové rozhranie

Výstupy:

Modul poskytuje vstupné dáta do analýzy pokrytia (Monitoring stavu pokrytia Broadband), plánovania budúcich meraní a plánovania investícií do širokopásmovej infraštruktúry.

1. Modul – Zber dát pre potreby BCO

Zhrnutie funkcionality:

Modul zabezpečuje nahrávanie dát od telekomunikačných operátorov a ďalších relevantných strán prostredníctvom verejného webového portálu a API rozhrania.

Zdroje dát:

Dáta sú nahrávané prostredníctvom používateľsky prívetivého webového rozhrania alebo prostredníctvom API rozhrania s verejne dostupnou dokumentáciou.

Štruktúra dát obsahuje:

• Identifikačné údaje poskytovateľa širokopásmového internetu alebo telekomunikačného operátora (napr. IČO, Názov firmy, atď.).
• Geografické údaje na zakresľovanie telekomunikačnej infraštruktúry.
• Podporné údaje v štruktúrovanej forme definované v rámci modulu Správy a riadenia verejných konzultácií (napr. atribút špecifikujúci, či sa jedná o súčasnú, alebo plánovanú infraštruktúru; plánovaný dátum dokončenia výstavby infraštruktúry; informácie o územných a iných povoleniach vo forme prílohy PDF alebo obrázku; apod.).

Nahrávané údaje sa môžu vzťahovať k pokrytiu konkrétnych adries z IS CSRÚ Registra Adries. V tomto prípade je špecifikovaný atribút rýchlosti pokrytia danej adresy pre koncového zákazníka.

Integrácia s inými modulmi a systémami:

Vzhľadom na to, že modul slúži pre zhromažďovanie veľkej časti externých dát systému, je integrovaný cez Integračnú platformu.

Popis funkcionality z pohľadu BCO:

Modul efektívnym spôsobom umožňuje tretím stranám nahrávanie dát k pokrytiu vysokorýchlostným internetom (vrátane podporných materiálov). BCO potvrdzuje, že nahrané dáta sú platné a relevantné, pre účely zabránenia plnenia databáze falošnými údajmi.

Popis funkcionality z pohľadu iných strán:

Modul ďalej poskytuje verejne prístupný webový portál s používateľsky prívetivým rozhraním, kde sú sekcie ako:

• Sekcia verejných konzultácií: Po tom, ako BCO vyhlási verejnú konzultáciu prostredníctvom modulu Správy a riadenia verejných konzultácií sú v sekcii verejných konzultácií dostupné informácie o povahe konzultácie, jej cieľoch, trvaní a požadovaných. Po zahájení konzultácie je umožnené používateľom webového portálu vyplniť požadované informácie a ich odoslanie.
• Sekcia telekomunikačnej infraštruktúry: V rámci sekcii je umožnené na ad hoc bázy nahrávanie geografických údajov k súčasnej telekomunikačnej infraštruktúre. Údaje sú nahrávané ako prílohy, alebo zakresľované v rámci webového rozhrania pomocou modulu Nástroj pre spracovávanie mapových a priestorových podkladov (zakresľovanie infraštruktúry).
• Sekcia štátnych intervencií: V prípade vyhlásenia dopytovej výzvy umožní sekcia pre konkrétnu výzvy poskytovateľovi širokopásmového internetu alebo inému telekomunikačnému operátorovi možnosť nahrať podporné informácie k plánovanej vstavbe infraštruktúry a následného pokrytia

Výstupy:

Po nahraní údajov a ich odsúhlasení pracovníkom BCO sú údaje v štruktúrovanej podobe uložene do databázy, geografické údaje budú uložené do priestorovej databázy.

1. Modul – Plánovanie a riadenie investícií do Broadband

Zhrnutie funkcionality:

Modul slúži ako plánovací nástroj pre potreby BCO, prostredníctvom ktorého sú koordinované a monitorované verejné a súkromné investície po širokopásmovej infraštruktúry.

Zdroje dát:

Zdrojom dát je stav súčasného pokrytia (modul Monitoring stavu pokrytia Broadband), vstupy do verejných konzultácií k plánovaným investíciám do širokopásmovej infraštruktúry (modul Správa a riadenie verejných konzultácií), namerané pokrytie (modul Mobilná analytika (Spracovanie dát z meracej techniky)) a plánované investície v rámci štátnych intervencií (modul Správa štátnych intervencií pre oblasť Broadband).

Integrácia s inými modulmi a systémami:

1. Monitoring stavu pokrytia Broadband
2. Mobilná analytika (Spracovanie dát z meracej techniky)
3. Správa štátnych intervencií pre oblasť Broadband
4. Správa a riadenie verejných konzultácií

Popis funkcionality:

Modul poskytuje BCO nástroj, ktorým je možné jasne definovať, ktoré lokality (prípadne adresy) sú pokryté širokopásmovým internetom do vybraného dátumu. Modul poskytuje nástroj, prostredníctvom ktorého je (v rámci grafického rozhrania) jednoduché syntetizovať údaje k plánovaným investíciám z viacerých zdrojov (verejné konzultácie, plány organizácií verejnej správy, dopytové projekty a pod.).

Výstupy:

Nástroj poskytuje funkcionalitu jednotného harmonogramu, ktorý spája informácie o plánovaných verejných konzultáciách, súčasnej a plánovanej infraštruktúre a pokrytí širokopásmovým internetom a plánov inštitúcií verejnej správy na budovanie širokopásmovej infraštruktúry. Tieto informácie sú prezentované v podrobnom harmonograme v rámci grafického rozhrania. Ďalej sú údaje prezentované v mapovom rozhraní, v rámci ktorého je možné prehliadať plánované pokrytie k špecifickému dátumu v budúcnosti.

1. Modul – Správa štátnych intervencií pre oblasť Broadband

Zhrnutie funkcionality:

Modul umožňuje správu/vyhodnocovanie plánov na budovanie širokopásmovej infraštruktúry inštitúciami verejnej správy alebo v rámci dopytových projektov.

Zdroje dát:

Modul umožňuje nahranie geografických údajov k plánovanej infraštruktúre prostredníctvom grafického rozhrania. Integráciou na modul Nástroj pre spracovávanie mapových a priestorových podkladov (zakresľovanie infraštruktúry) je ďalej umožnené zakresľovanie geografických údajov prostredníctvom mapového rozhrania.

Integrácia s inými modulmi a systémami:

1. Nástroj pre spracovávanie mapových a priestorových podkladov (zakresľovanie infraštruktúry)
2. Plánovanie a riadenie investícií do Broadband
3. Monitoring stavu pokrytia Broadband
4. Zber dát pre potreby BCO

Popis funkcionality:

Modul umožňuje nahrávanie (prostredníctvom grafického rozhrania alebo zakresľovaním do mapového rozhrania) geografických údajov k plánovanej širokopásmovej infraštruktúre. Tieto geografické údaje obsahujú nasledujúce atribúty:

• Identifikácia inštitúcie, ktorá je zodpovedná za predmetnú výstavbu / projekt
• Časový harmonogram projektu (územne povolenia, zahájenie výkopových práci, spustenie infraštruktúry do prevádzky a pod.)
• Identifikácia lokality a adries, ktoré budú pokryté širokopásmovým internetom po spustení plánovanej infraštruktúry do prevádzky
• Pasívnu infraštruktúru, existujúcu i plánovanú

Výstupy:

Modul poskytuje dáta do modulov Monitoring stavu pokrytia Broadband a Plánovanie a riadenie investícií do Broadband. Ďalej umožňuje zobrazenie plánovanej infraštruktúry.

1. Modul – Správa a riadenie verejných konzultácií

Zhrnutie funkcionality:

Modul poskytuje nástroj na podporu agendy BCO v rámci verejných konzultácií k pokrytiu SR širokopásmovom internetom.

Zdroje dát:

Pre plánovanie verejnej konzultácie sú využívané dáta z modulov Monitoring stavu pokrytia Broadband a Plánovanie a riadenie investícií do Broadband. V rámci samotnej verejnej konzultácie je umožnené poskytovateľom sietí nahrávať relevantné dáta prostredníctvom webového rozhrania (modul Zber dát pre potreby BCO).

Integrácia s inými modulmi a systémami:

1. Monitoring stavu pokrytia Broadband
2. Plánovanie a riadenie investícií do Broadband
3. Zber dát pre potreby BCO.

Popis funkcionality:

Modul má tieto kľúčové funkcie: plánovanie a definovanie verených konzultácií, realizácia verejnej konzultácie a vyhodnocovanie verejnej konzultácie.

V rámci plánovania a definovania verejných konzultácií, modul poskytuje nástroj, kde je možné definovať časový priebeh budúcej konzultácie, zoznam priamo oslovených strán (poskytovateľov širokopásmového internetu, telekomunikačných operátorov a pod.) a podrobný zoznam požiadaviek, ktoré účastníci verejnej konzultácie musí vyplniť (napr. identifikačné informácie firmy, adresné body, ktoré sú pokryté, technológia pokrytia, dátum pokrytia, geografické údaje a pod.).

V rámci realizácie verejnej konzultácie, ktorá je zahájená v rámci nástroja, sú rozposlané emailové správy potenciálnym účastníkom a je verejne sprístupnený webový portál v rámci ktorého sa môžu subjekty zúčastniť verejnej konzultácie. Portál obsahuje všeobecné informácie o danej verejnej konzultácií definované v rámci plánovania a definovania verejných konzultácií. Portál ďalej obsahuje formulár, ktorý daný subjekt má možnosť vyplniť a odoslať. Po odoslaní sú informácie uložené medzi výsledky danej verejnej konzultácie.

Pre vyhodnocovanie verejnej konzultácie modul poskytuje nástroj na prehľadné filtrovanie vstupov od účastníkov verejnej konzultácie. Nástroj umožňuje odstraňovanie údajov, o ktorých bude mať BCO dôvodné podozrenie, že nie sú platné, alebo ktoré nie sú úplné. Po schválení vstupov zo strany BCO vygeneruje modul Monitoring stavu pokrytia Broadband aktualizovaný zoznam bielych miest z pohľadu určenej rýchlosti pripojenia koncového zákazníka.

Pri realizácií verejnej konzultácie, modul poskytuje verejne dostupný webový portál, v rámci ktorého majú účastníci verejnej konzultácie možnosť vyplniť požadované údaje k pokrytiu vybraných adries širokopásmovom internetom. Portál obsahuje sekciu s informáciami k danej verejnej konzultácií a sekciu s formulárom, kde je možné vyplniť / nahrať požadované podklady k vybraným adresám (jedna adresa alebo zoznam adries). Nástroj validuje vstupné dáta od účastníkov verejnej konzultácie a v prípade ich neplatnosti neumožní odoslanie formuláru. Webový portál je prehľadný a používateľsky prívetivý. Po odoslaní formuláru sa zobrazí používateľovi potvrdenie o úspešnom odoslania taktiež mu je poslané potvrdenie na uvedenú emailovú adresu.

1. Modul – BCO BackOffice

Zhrnutie funkcionality:

Modul slúži pre zamestnancov BCO, pričom je rozdelený do dvoch častí, a to:

• Časť v kompetencií ÚPREKaPS
• Časť v kompetencií BCO

Zdroje dát:

1. Správa plánovania a riadenia investícií do Brodband – stav súčasného pokrytia (modul Monitoring stavu pokrytia Broadband), vstupy do verejných konzultácií k plánovaným investíciám do širokopásmovej infraštruktúry, namerané pokrytie (modul Mobilná analytika (Spracovanie dát z meracej techniky)) a plánované investície v rámci štátnych intervencií.
2. Správa štátnych intervencií pre oblasť Broadband – geografické údaje k plánovanej infraštruktúre. Integráciou na modul Nástroj pre spracovávanie mapových a priestorových podkladov (zakresľovanie infraštruktúry) je ďalej umožnené zakresľovanie geografických údajov prostredníctvom mapového rozhrania.
3. Správa a riadenie verejných konzultácií – pre plánovanie verejnej konzultácie sú využívané dáta z modulu Monitoring stavu pokrytia Broadband a z plánovanie a riadenie investícií do Broadband.

Integrácia s inými modulmi a systémami:

1. Plánovanie a riadenie investícií do Broadband
2. Správa štátnych intervencií pre oblasť Broadband
3. Správa a riadenie verejných konzultácií
4. Integračná platforma

Popis funkcionality:

Pozostáva sa z dvoch častí a to Portálovej a BackOffice, pričom tieto časti sú logicky oddelené na základe poskytovanej funkcionality a biznis procesov.

Modul BackOffice je prístupný iba pre zamestnancov BCO, pričom autentifikácia prebieha pomocou dedikovaného IAM systému.

BackOffice časť a Portálová časť spolu zdieľajú dátové úložisko a to z dôvodu výmeny dát, nakoľko BackOffice je tvorcom obsahu pre Portál a to v prípade oznámení ale aj verejných konzultácií.

Výstupy:

• Jednotný harmonogram, ktorý spája informácie o plánovaných verejných konzultáciách, súčasnej a plánovanej infraštruktúre a pokrytí širokopásmovým internetom a plánov inštitúcií verejnej správy na budovanie širokopásmovej infraštruktúry. Tieto informácie sú prezentované v podrobnom harmonograme v rámci grafického rozhrania.
• Údaje sú prezentované v mapovom rozhraní, v rámci ktorého je možné prehliadať plánované pokrytie k špecifickému dátumu, zobrazenie plánovanej infraštruktúry.
• Platné a validované vstupy do verejnej konzultácie, z ktorých sa následne vygeneruje aktualizovaný zoznam bielych miest podľa rýchlosti pripojenia.
• Dáta do modulu Monitoring stavu pokrytia Broadband.

1. Modul – BCO Portál

Zhrnutie funkcionality:

Modul slúži ako informačný CMS systém, ktorý je spravovaný zamestnancami BCO z privátnej časti a zároveň ako portál pre zber údajov od externých subjektov, akými sú napríklad telekomunikačné podniky.

Zdroje dát:

1. Správa plánovania a riadenia investícií do Brodband – vstupy do verejných konzultácií k plánovaným investíciám do širokopásmovej infraštruktúry.
2. Správa štátnych intervencií pre oblasť Broadband – geografické údaje k plánovanej infraštruktúre. Integráciou na modul Nástroj pre spracovávanie mapových a priestorových podkladov (zakresľovanie infraštruktúry) je ďalej umožnené zakresľovanie geografických údajov prostredníctvom mapového rozhrania.
3. Správa a riadenie verejných konzultácií – v rámci samotnej verejnej konzultácie je umožnené poskytovateľom sietí nahrávať relevantné dáta (modul Zber dát pre potreby BCO).

Integrácia s inými modulmi a systémami:

1. Zber dát pre potreby BCO
2. Plánovanie a riadenie investícií do Broadband
3. Správa štátnych intervencií pre oblasť Broadband
4. Správa a riadenie verejných konzultácií

Popis funkcionality:

Pozostáva sa z 2 častí a to Portálovej a BackOffice, pričom tieto časti sú logicky oddelené na základe poskytovanej funkcionality a biznis procesov.

BCO Portál je rozdelený do dvoch častí a to verejnú zónu, do ktorej má prístup každý bez nutnosti autentifikácie. Druhú časť tvorí privátna zóna, ktorá vyžaduje autentifikáciu používateľa, pričom táto autentifikácia je zabezpečená ÚPVS IAM. Privátna zóna slúži fyzickým a právnickým osobám, ktoré v tejto časti môžu pristupovať do konaní v rámci ich možnosti.

Portálová časť a BackOffice časť spolu zdieľajú dátové úložisko a to z dôvodu výmeny dát, nakoľko BackOffice je tvorcom obsahu pre portál a to v prípade oznámení ale aj verejných konzultácií.

Výstupy:

• Jednotný harmonogram, ktorý spája informácie o plánovaných verejných konzultáciách, súčasnej a plánovanej infraštruktúre a pokrytí širokopásmovým internetom a plánov inštitúcií verejnej správy na budovanie širokopásmovej infraštruktúry. Tieto informácie sú prezentované v podrobnom harmonograme v rámci grafického rozhrania.
• Údaje sú prezentované v mapovom rozhraní, v rámci ktorého je možné prehliadať plánované pokrytie k špecifickému dátumu, zobrazenie plánovanej infraštruktúry.
• Platné a validované vstupy do verejnej konzultácie, z ktorých sa následne vygeneruje aktualizovaný zoznam bielych miest podľa rýchlosti pripojenia.

1. Modul – Integračná platforma

Zhrnutie funkcionality:

Komponenty sú prepojené voľnými väzbami (Loose coupling). Architektúrny princíp voľnej väzby systémov znamená, že mapovanie a transformácie dát v rámci integrácie systémov sú realizované na úrovni integračného rozhrania, alebo integračnej vrstvy a nie zásahom do integrovaných systémov. Voľná väzba umožní zabezpečiť, aby neboli integrované systémy dotknuté výmenou či úpravou okolitých systémov. V súčasnosti rozvoj integrácie vyžaduje zásah v integračnej platforme a vlastný vývoj logiky.

Zdroje dát:

• Všetky aplikačné moduly

Integrácia s inými modulmi a systémami:

• Všetky aplikačné moduly

Popis funkcionality:

Na komunikáciu medzi komponentami systému slúži primárne integračná platforma, ktorá je základným komponentom pre riadenie tokov údajov, orchestráciu a kompozíciu služieb, a zároveň plní funkciu izolačnej vrstvy medzi vonkajším a vnútorným prostredím systému, ale aj jednotlivými subsystémami a to ako pre online spracovanie správ, tak dávkové spracovanie.

Platforma sa skladá z:

• Aplikačná integračná vrstva (OpenApi)
• Dátová integračná vrstva (custom vývoj)

Výstupy:

Všetky integrácie okrem natívnych sú realizované výhradne niektorou z vyššie popísaných vrstiev. Integračná vrstva je aj hlavným transformačným a synchronizačným prvkom architektúry.

1. Modul – DMS

Zhrnutie funkcionality:

Pre správu nahratých súborov je použité riešenie, ktoré umožňuje manažovať uložené súbory.

Zdroje dát:

• Nahrávané súbory z aplikačných modulov

Integrácia s inými modulmi a systémami:

• Integračná platforma

Popis funkcionality:

Nástroj ukladá metadáta nahratých súborov do relačnej databázy a samotné nahrané súbory nahráva do súborového systému do príslušného repozitára, do ktorého súbor patrí. Súbory je možné zabezpečiť pomocou šifrovania.

Nástroj obsahuje grafické rozhranie, ktorým je možné manažovať repozitáre, lokálnych používateľov, role a ich právomoci v rámci DMS, pričom role je možné mapovať na role v príslušnom IAM.

Ďalšia výhoda nástroja je podpora štandardných API, čím poskytuje webové služby ostatným komponentom.

Výstupy:

Podpora pre centrálne ukladanie súborov.

1. Modul – SmartAnalytics / CFMS

Zhrnutie funkcionality:

Predstavuje manažment a spracovanie dát z meraní jednotlivých meracích vozidiel. Samotná aplikačná logika komponentu je postavená vysokoodbornom HW a SW, ktoré sú zamerané na spracovanie dát z meraní frekvenčného spektra.

Zdroje dát:

• Meracie zariadenia vo vozidlách

Integrácia s inými modulmi a systémami:

• Integračná platforma, ktorá rozposiela spracované údaje

Výstupy:

Výsledky z merania, ktoré sú spracované z raw podoby do technických údajov, ktoré je možné využiť v ďalších procesoch štátneho dohľadu a monitoringu frekvenčného spektra.

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

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

1. 
   
   1. 
      
      1. Rozsah 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:

1. 
   
   1. 
      
      1. 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.

1. 
   
   1. 
      
      1. Prehľ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.

1. 
   
   1. 
      
      1. Prehľ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 .

1. 
   
   1. 
      
      1. Aplikač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.

1. 
   
   1. 
      
      1. Aplikač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.

• 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

1. 
   
   1. 
      
      1. Poskytovanie ú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.

1. 
   
   1. 
      
      1. Konzumovanie ú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Ú.

1. 
   
   1. Dá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.

1. 
   
   1. 
      
      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.

1. 
   
   1. 
      
      1. Dá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

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

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

1. 
   
   1. 
      
      1. 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 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).
  1. 
     
     1. 
        
        1. Objekty 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:

1. 
   
   1. 
      
      1. 
         
         1. Identifiká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Ú.

1. 
   
   1. 
      
      1. Kvalita a čistenie údajov

1. 
   
   1. 
      
      1. 
         
         1. Zhodnotenie 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:

1. 
   
   1. 
      
      1. 
         
         1. Roly 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/ )

1. 
   
   1. 
      
      1. 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 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:

1. 
   
   1. 
      
      1. Analytické ú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/

1. 
   
   1. 
      
      1. 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 - 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.

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

1. 
   
   1. Technologická vrstva

1. 
   
   1. 
      
      1. Prehľ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ť.

1. 
   
   1. 
      
      1. Pož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, …).

1. 
   
   1. 
      
      1. Ná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.

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

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

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:

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

1. 
   
   1. Bezpeč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[6]

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).

1. 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.

1. 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

V rámci tohto projektu, realizovaného prostredníctvom verejného obstarávania, platia nasledovné podrobné požiadavky na dodanie zdrojového kódu a jeho integráciu do infraštruktúry objednávateľa. Tieto požiadavky zabezpečujú transparentnosť, konzistentnosť a kontrolu nad procesom vývoja, nasadzovania a údržby aplikácií.

1. 
   
   1. Kompletný zdrojový kód pre aplikácie vyvinuté na zákazku 

Zdrojový kód: Dodávka bude obsahovať kompletný zdrojový kód každej aplikácie vytvorenej na zákazku. Táto dodávka zahŕňa všetky potrebné moduly, skripty, konfiguračné súbory, knižnice a iné závislosti potrebné pre správne zostavenie a nasadenie aplikácie.

Závislosti a verzie: Každá integrovaná externá knižnica alebo modul bude definovaný v kóde spolu s presnou verziou, aby sa zabezpečila konzistentnosť prostredia. Na tento účel bude pripravený súbor so závislosťami (napr. requirements.txt pre Python, package.json pre Node.js, pom.xml pre Maven a pod.), ktorý objednávateľovi uľahčí správu závislostí.

Dokumentácia kódu: Kód bude obsahovať internú dokumentáciu, ktorá vysvetľuje jednotlivé časti kódu, ich účel a spôsob interakcie. Pripojená bude aj technická dokumentácia popisujúca kľúčové architektonické komponenty a návrhové princípy, aby sa uľahčila údržba a rozšírenie riešenia.

1. 
   
   1. Dodanie zdrojového kódu pre aplikácie postavené na open-source projektoch

Kompletný kód s modifikáciami: V prípade aplikácií postavených na open-source projektoch bude dodaný celý kód vrátane všetkých úprav a prispôsobení open-source komponentov. Tým sa zabezpečí konzistentnosť medzi prostrediami.

Informácie o verziách a závislostiach: Každý použitý open-source komponent bude explicitne uvedený s presnou verziou a informáciami o jeho kompatibilite. Na správu závislostí bude poskytnutý súbor s ich zoznamom.

Licenčné informácie: K dodanému kódu budú priložené licenčné informácie pre každý použitý open-source komponent. Dokumentácia bude zahŕňať informácie o prípadných obmedzeniach a súlade s licenčnými podmienkami.

1. 
   
   1. Dodanie aplikácií založených na closed-source produktoch

Predpis na build kontajnera alebo VM image: Pre aplikácie postavené na closed-source komponentoch bude dodaný presný predpis na vytvorenie (build) kontajnera alebo VM image. Tento predpis bude obsahovať všetky konfiguračné kroky a presné verzie použitých closed-source komponentov.

Alternatíva - VM image: Ak nie je možné použiť kontajnerizáciu, dodávateľ dodá obraz virtuálneho stroja (VM image) pripravený na integráciu do nasadzovacieho prostredia.

Dokumentácia pre konfiguráciu closed-source komponentov: Ak aplikácia využíva closed-source komponenty, dodávateľ poskytne detailné inštrukcie, ako ich integrovať a konfigurovať v rámci riešenia, vrátane krokov na ich aktualizáciu.

1. 
   
   1.  Automatizovaný CI/CD kôd na nasadenie

Pipeline pre CI/CD: Dodávateľ pripraví kód pre implementáciu CI/CD pipeline, ktorý umožní nasadzovanie aplikácie do vývojového, predprodukčného a produkčného prostredia. CI/CD pipeline bude navrhnutý podľa potrieb projektu a bude pokrývať všetky kroky, vrátane zostavenia, testovania a nasadenia.

Podpora pre viacero cloudových prostredí: Pipeline bude obsahovať mechanizmy na nasadenie do privátneho a verejného cloudového prostredia v súlade s bezpečnostnými a prevádzkovými štandardmi.

Dokumentácia k CI/CD procesu: Dokumentácia bude obsahovať kroky pre inicializáciu a konfiguráciu pipeline, postup riešenia chýb a podporu pri škálovaní CI/CD riešenia.

1. 
   
   1. Integrácia zdrojového kódu do git repozitára objednávateľa 

Prístup do Git repozitára objednávateľa: Git repozitár spravuje objednávateľ, ktorý dodávateľovi poskytne prístup s obmedzenými právami, určenými na zapisovanie do vývojových vetiev a na vytváranie pull requestov na implementáciu zmien. Dodávateľ bude dodržiavať predpísané postupy pre verzie a riadenie vetiev.

Štruktúra dodaného kódu a organizácia v repozitári: Dodávateľ dodrží dohodnutú štruktúru adresárov a súborov v repozitári, pričom budú dodržané interné štandardy objednávateľa na organizáciu zdrojových súborov a ich štruktúru. Tým sa uľahčí orientácia v kóde a efektívna údržba.

Tagovanie verzií: Dodávateľ označí jednotlivé verzie kódu (tagging), ktoré umožnia jednoznačnú identifikáciu verzií pre účely testovania a nasadenia. Verziovací systém bude dohodnutý na začiatku projektu (napr. Semantic Versioning).

1. 
   
   1. Proces nasadenia a integrácie v git repozitári

CI/CD integrácia s repozitárom: CI/CD pipeline bude nakonfigurovaný tak, aby umožnil spúšťanie priamo z Git repozitára objednávateľa. Automatizované buildy a nasadzovanie sa budú spúšťať na základe zmien v určených vetvách (napr. staging a production), čím sa zabezpečí konzistentné nasadenie kódu.

Automatizované buildy a nasadenia: Zmeny v kóde budú spúšťať build a nasadzovacie procesy, čo zaručí, že do predprodukčných a produkčných prostredí budú vstupovať len plne testované verzie kódu.

1. 
   
   1. Kontrola kvality kódu a zabezpečenie štandardov

Code Review a schvaľovanie zmien: Dodávateľ je povinný vytvárať pull requesty (PR) na každú zmenu, pričom tieto budú prechádzať schválením zo strany objednávateľa. Tento proces zabezpečí kontrolu nad kódom pred jeho nasadením.

Štandardy kódu: Dodávateľ bude dodržiavať štandardy kódu definované objednávateľom, vrátane formátovania, konvencií pomenovania a štruktúry komentárov.

1. 
   
   1. Komunikácia a správa git repozitára

Pravidelná synchronizácia: Dodávateľ bude pravidelne synchronizovať svoj pracovný kód s Git repozitárom objednávateľa. Pravidelné zálohovanie kódu zabezpečí, že objednávateľ má priebežný prehľad o stave projektu.

Dokumentácia k úpravám: Každý commit bude obsahovať popis zmien. Pravidelná aktualizácia dokumentácie bude objednávateľovi poskytovať prehľad o všetkých zmenách a ich účele.

1. 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.

Pre zabezpečenie dlhodobej prevádzky, údržby a vysokej dostupnosti informačného systému sú medzi objednávateľom a dodávateľom dohodnuté pravidlá prevádzky, údržby a riadenia systému. Tieto pravidlá, vrátane úrovne podpory, monitorovania, bezpečnostných aktualizácií a súladu s ITIL procesmi, sú definované v dokumente Zmluva o poskytovaní služieb podpory a údržby informačného systému, ktorý je súčasťou podkladov jednotlivých verejných obstarávaní, aby bolo možné parametre zmluvy nastaviť špecificky pre potreby obstarávaných riešení a komponentov. Tento dokument predstavuje záväzné rámce pre podporu a údržbu systému.

Jednotlivé parametre SLA služieb sú uvedené v rámci Prílohy 2 Katalóg požiadaviek. Popisy služieb prevádzky a údržby sú uvedené v  Prílohe č.9  - Popis služieb vzor a procesy prevádzkové sú uvedené v prílohe č.10 - Manažment služieb Vzor.

1. 
   
   1. Prevá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.

1. 
   
   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í),

1. 
   
   1. 
      
      1. Riešenie incidentov – SLA parametre

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

Označenie naliehavosti incidentu:

možný dopad:

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

Vyžadované reakčné doby:

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

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

(4) Incidenty nahlásené verejným obstarávateľom úspešnému uchádzačovi v rámci testovacieho prostredia majú prioritu 3 a nižšiu

Vzťahujú sa výhradne k dostupnosti testovacieho prostredia. Za incident na testovacom prostredí sa nepovažuje incident vztiahnutý k práve testovanej funkcionalite.

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

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

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

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

1. 
   
   1. 
      
      1. Dostupnosť (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).

1. 
   
   1. 
      
      1. RTO (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

1. 
   
   1. 
      
      1. RPO (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

1. 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.

Projektový manažér:

• zodpovedá za riadenie projektu počas celého životného cyklu projektu. Riadi projektové (ľudské a finančné) zdroje, zabezpečuje tvorbu obsahu, neustále odôvodňovanie projektu (aktualizuje BC/CBA) a predkladá vstupy na rokovanie Riadiaceho výboru. Zodpovedá za riadenie všetkých (ľudských a finančných) zdrojov, členov projektovému tím objednávateľa a za efektívnu komunikáciu s dodávateľom alebo stanovených zástupcom dodávateľa.
• zodpovedá za riadenie prideleného projektu - stanovenie cieľov, spracovanie harmonogramu prác, koordináciu členov projektového tímu, sledovanie dodržiavania harmonogramu prác a rozpočtu, hodnotenie a prezentáciu výsledkov a za riadenie s tým súvisiacich rizík. Projektový manažér vedie špecifikáciu a implementáciu projektov v súlade s firemnými štandardami, zásadami a princípmi projektového riadenia.
• zodpovedá za plnenie projektových/programových cieľov v rámci stanovených kvalitatívnych, časových a rozpočtovým plánov a za riadenie s tým súvisiacich rizík. V prípade externých kontraktov sa vedúci projektu/ projektový manažér obvykle podieľa na ich plánovaní a vyjednávaní a je hlavnou kontaktnou osobou pre zákazníka.

Kľúčový používateľ:

• zodpovedný za reprezentáciu záujmov budúcich používateľov projektových produktov alebo projektových výstupov a za overenie kvality produktu.
• zodpovedný za návrh a špecifikáciu funkčných a technických požiadaviek, potreby, obsahu, kvalitatívnych a kvantitatívnych prínosov projektu, požiadaviek koncových používateľov na prínos systému a požiadaviek na bezpečnosť.
• Kľúčový používateľ (end user) navrhuje a definuje akceptačné kritériá, je zodpovedný za akceptačné testovanie a návrh na akceptáciu projektových produktov alebo projektových výstupov a návrh na spustenie do produkčnej prevádzky. Predkladá požiadavky na zmenu funkcionalít produktov a je súčasťou projektových tímov

IT analytik:

• zodpovedá za zber a analyzovanie funkčných požiadaviek, analyzovanie a spracovanie dokumentácie z pohľadu procesov, metodiky, technických možností a inej dokumentácie. Podieľa sa na návrhu riešenia vrátane návrhu zmien procesov v oblasti biznis analýzy a analýzy softvérových riešení. Zodpovedá za výkon analýzy IS, koordináciu a dohľad nad činnosťou SW analytikov.
• analyzuje požiadavky na informačný systém/softvérový systém, formálnym spôsobom zaznamenáva činnosti/procesy, vytvára analytický model systému, okrem analýzy realizuje aj návrh systému, ten vyjadruje návrhovým modelom.
• Analytik informačných technológií pripravuje špecifikáciu cieľového systému od procesnej až po technickú rovinu. Mapuje a analyzuje existujúce podnikateľské a procesné prostredie, analyzuje biznis požiadavky na informačný systém, špecifikuje požiadavky na informačnú podporu procesov, navrhuje koncept riešenia a pripravuje podklady pre architektov a vývojárov riešenia, participuje na realizácii zmien, dohliada na realizáciu požiadaviek v cieľovom riešení, spolupracuje pri ich preberaní (akceptácie) používateľom.
• Pri návrhu IT systémov využíva odbornú špecializáciu IT architektov a projektantov. Študuje a analyzuje dokumentáciu, požiadavky klientov, legislatívne a technické podmienky a možnosti zvyšovania efektívnosti a výkonnosti riadiacich a informačných procesov. Navrhuje a prerokúva koncepcie riešenia informačných systémov a analyzuje ich efekty a dopady. Zabezpečuje spracovanie analyticko-projektovej špecifikácie s návrhom dátových a objektových štruktúr a ich väzieb, užívateľského rozhrania a ostatných podkladov pre projektovanie nových riešení.
• Spolupracuje na projektovaní a implementácii návrhov. Môže tiež poskytovať poradenstvo v oblasti svojej špecializácie. Zodpovedá za návrhovú (design) časť IT - pôsobí ako medzičlánok medzi používateľmi informačných systémov (biznis pohľad) a ich realizátormi (technologický pohľad).

IT architekt:

• zodpovedá za návrh architektúry riešenia IS a implementáciu technológií predovšetkým z pohľadu udržateľnosti, kvality a nákladov, za riešenie architektonických cieľov projektu dizajnu IS a súlad s architektonickými princípmi.
• vykonáva, prípadne riadi vysoko odborné tvorivé činnosti v oblasti návrhu IT. Študuje a stanovuje smery technického rozvoja informačných technológií, navrhuje riešenia na optimalizáciu a zvýšenie efektívnosti prostriedkov výpočtovej techniky. Navrhuje základnú architektúru informačných systémov, ich komponentov a vzájomných väzieb. Zabezpečuje projektovanie dizajnu, architektúry IT štruktúry, špecifikácie jej prvkov a parametrov, vhodnej softvérovej a hardvérovej infraštruktúry podľa základnej špecifikácie riešenia.
• zodpovedá za spracovanie a správu projektovej dokumentácie a za kontrolu súladu implementácie s dokumentáciou. Môže tiež poskytovať konzultácie, poradenstvo a vzdelávanie v oblasti svojej špecializácie. IT architekt, projektant analyzuje, vytvára a konzultuje so zákazníkom riešenia na úrovni komplexných IT systémov a IT architektúr, najmä na úrovni aplikačného vybavenia, infraštruktúrnych systémov, sietí a pod. Zaručuje, že návrh architektúry a/alebo riešenia zodpovedá zmluvne dohodnutým požiadavkám zákazníka v zmysle rozsahu, kvality a ceny celej služby/riešenia.

Manažér kvality:

• zodpovedá za priebežné vyžadovanie, hodnotenie a kontrolu kvality (vecnej aj formálnej) počas celého projektu. Je zodpovedný za úvodné nastavenie pravidiel riadenia kvality a za následné dodržiavanie a kontrolu kvality jednotlivých projektových výstupov. Sleduje a hodnotí kvalitatívne ukazovatele projektových výstupov a o zisteniach informuje projektového manažéra objednávateľa formou pravidelných alebo nepravidelných správ/záznamov.
• plánuje, koordinuje, riadi a kontroluje systém manažérstva kvality, monitoruje a meria procesy a identifikuje príležitosti na trvalé zlepšovanie systému manažérstva kvality v organizácii v súlade s platnými normami. Zabezpečuje tvorbu cieľov a koncepcie kvality, vrátane kontroly ich plnenia a vykonáva interné a externé audity kvality v súlade s plánom.
• Počas celej doby realizácie projektu zabezpečuje zhodu kvality projektových výstupov s požiadavkami. Realizuje postupy riadenia kvality tak, aby výsledkom boli projektové výstupy spĺňajúce požiadavky objednávateľa. Kontroluje, či sa riadenie a proces zabezpečenia kvality vykonáva správnym spôsobom, v správnom čase a správnymi osobami.

Vlastník procesov:

• zodpovedá za proces - jeho výstupy i celkový priebeh poskytnutia služby alebo produktu konečnému užívateľovi. Kľúčová rola na strane zákazníka (verejného obstarávateľa), ktorá schvaľuje biznis požiadavky a zodpovedá za výsledné riešenie, prínos požadovanú hodnotu a naplnenie merateľných ukazovateľov. Úlohou tejto roly je definovať na užívateľa orientované položky (user-stories), ktoré budú zaradzované a prioritizované v produktovom zásobníku. Zodpovedá za priebežné posudzovanie vecných výstupov dodávateľa v rámci analýzy, návrhu riešenia vrátane DNR z pohľadu analýzy a návrhu riešenia aplikácii IS.
• zodpovedný za schválenie funkčných a technických požiadaviek, potreby, obsahu, kvalitatívnych a kvantitatívnych prínosov projektu. Definuje očakávania na kvalitu projektu, kvalitu projektových produktov, prínosy pre koncových používateľov a požiadavky na bezpečnosť. Definuje merateľné výkonnostné ukazovatele projektov a prvkov. Vlastník procesov schvaľuje akceptačné kritériá, rozsah a kvalitu dodávaných projektových výstupov pri dosiahnutí platobných míľnikov, odsúhlasuje spustenie výstupov projektu do produkčnej prevádzky a dostupnosť ľudských zdrojov alokovaných na realizáciu projektu.

Manažér kybernetickej a informačnej bezpečnosti:

• zodpovedá za dodržanie princípov a štandardov na kybernetickú a IT bezpečnosť, za kontrolu a audit správnosti riešenia v oblasti bezpečnosti.
• koordinuje a riadi činnosť v oblasti bezpečnosti prevádzky IT, spolupracuje na projektoch, na rozvoji nástrojov a postupov k optimalizácii bezpečnostných systémov a opatrení. Stanovuje základné požiadavky, podmienky a štandardy pre oblasť bezpečnosti programov, systémov, databázy či sieti. Spracováva a kontroluje príslušné interné predpisy a dohliada nad plnením týchto štandardov a predpisov. Kontroluje a riadi činnosť nad bezpečnostnými testami, bezpečnostnými incidentmi v prevádzke IT. Poskytuje inštrukcie a poradenstvo používateľom počítačov a informačných systémov pre oblasť bezpečnosti

DevSecOps inžinier:

• Zodpovedá za integráciu bezpečnostných postupov do všetkých fáz životného cyklu vývoja aplikácií v prostredí DevOps. Spolupracuje s vývojármi a prevádzkovými tímami na implementácii bezpečnostných opatrení a štandardov. Rieši zraniteľnosti, monitoruje bezpečnosť v prostredí CI/CD a vykonáva pravidelné testovanie bezpečnostných kontrol.
• Implementuje automatizované bezpečnostné kontroly a dohliada na ich neustále aktualizovanie podľa najnovších hrozieb. Zodpovedá za zabezpečenie infraštruktúry, vrátane správy práv a prístupov, ochrany dát, bezpečnosti sietí a nástrojov.

Test manažér:

• Zodpovedá za vytvorenie a riadenie testovacej stratégie, koordináciu testovacích aktivít a zdrojov, vrátane manuálneho a automatizovaného testovania. Vytvára testovacie plány a metodiky, definuje testovacie prípady a zodpovedá za sledovanie kvality výstupov.
• Dohliada na priebeh akceptačných testov a vykonáva kontrolu kvality výstupov v súlade s dohodnutými kritériami. Spolupracuje s kľúčovými používateľmi na definovaní akceptačných kritérií a dohliada na riešenie zistených chýb pred nasadením do produkcie.

Cloud architekt

• Zodpovedá za návrh, implementáciu a optimalizáciu cloudovej infraštruktúry, vrátane výberu vhodných cloudových technológií a služieb pre zabezpečenie dostupnosti, škálovateľnosti a bezpečnosti IS. Navrhuje cloudové riešenia v súlade s požiadavkami na bezpečnosť a compliance.
• Zabezpečuje integráciu cloudových služieb s existujúcou IT infraštruktúrou a dohliada na správu, optimalizáciu a nákladovú efektívnosť cloudového prostredia. Poskytuje konzultácie v oblasti cloudových technológií a služieb.

Data inžinier

• Zodpovedá za návrh a implementáciu riešení pre zber, spracovanie, transformáciu a ukladanie dát. Vyvíja a optimalizuje dátové pipeline procesy, zodpovedá za bezpečnosť a kvalitu dát, ktoré sú potrebné pre analytické a prevádzkové účely.
• Navrhuje riešenia pre spracovanie a distribúciu veľkého objemu dát (big data), pracuje s dátovými skladmi a ETL nástrojmi. Poskytuje podporu analytikom a ďalším členom tímu pri prístupe k relevantným dátovým zdrojom.

Scrum Master (alebo Agile Coach)

• Riadi agilné procesy projektu a zodpovedá za efektívne využitie agile metodológie v projektovom tíme. Facilitátor pre projektové tímy v rámci pravidelných agilných meetingov, zaisťuje plynulý priebeh agile procesov a pomáha riešiť prekážky.
• Zodpovedá za zvyšovanie produktivity tímu, zlepšovanie procesov a zvyšovanie transparentnosti práce prostredníctvom vizualizácie progresu a pravidelného hodnotenia prác (retrospektíva).

1. 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.

Všetky výstupy projektu sú v zmysle Vyhlášky MIRRI č. 401/2023 Z.z. o riadení projektov.

Forma a štruktúra výstupu z hlavných etáp projektu je v zmysle Vyhlášky 401/2023 o riadení projektov a zmenových požiadaviek a príručky riadenie kvality, administrovanej zo strany útvaru Riadenia kvality MIRRI.

Dekompozícia hlavného produktu:

Jednotlivé produkty / výstupy v zmysle dekompozície hlavného produktu rozdelené do dvoch základných skupín:

• Manažérske produkty a
• Špecializované (technické) produkty.

Výstupy z podpornej aktivity Publicita a informovanosť v zmysle Zmluvy o PPM a aktuálneho Manuálu pre informovanosť a publicitu pre POO a Dizajnového manuálu komunikačných materiálov pre POO sú:

• Elektronická obrazovka
• Odporúčaná veľkosť formát A4 najneskôr 3 mesiace od ukončenia projektu (osadenie na 5 rokov po ukončení projektu).
• Koordinácia a tvorba obsahu publicity a informovanosti a jeho prezentovanie na konferenciách/workshopoch.
• Príprava tlačových správ a publikovanie informácií na Webovej stránke NASES.

1. 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)