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

1.História dokumentu

2.Účel dokumentu

V súlade s Vyhláškou 401/2023 Z.z. je dokument I-03 Prístup k projektu určený na rozpracovanie detailných informácií prípravy projektu Inteligentný cestovný ruch v Prešovskom samosprávnom kraji 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 obsahuje 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 je v súlade so zákonom. Zároveň opisuje aj implementáciu projektu a preberanie výstupov projektu.

2.1Použité skratky a pojmy

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

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

• U – užívateľská požiadavka
• R – označenie požiadavky
• xx – číslo požiadavky
  Nefunkčné (kvalitatívne, výkonové - Non Functional Requirements - NFR) požiadavky majú nasledovnú konvenciu:
  NRxx
• N – nefunkčná požiadavka (NFR)
• R – označenie požiadavky
• xx – číslo požiadavky
  Ostatné typy požiadaviek môžu byť ďalej definované objednávateľom/PM.
  Všetky požiadavky uvedené v Prístupe k projektu v príslušných kapitolách, musia byť v súlade s funkčnými, nefunkčnými a technickými požiadavkami uvedenými v Katalógu požiadaviek I-04 (M-05 Analýza nákladov a prínosov - BC/CBA, karta: Katalóg požiadaviek).

3.Popis navrhovaného riešenia

V súlade s vyhláškou č. 401/2023 Z. z. o riadení projektov a zmenových požiadavkách v prevádzke informačných technológií verejnej správy je dokument I-03 Prístup k projektu určený na rozpracovanie detailných informácií o príprave projektu „Inteligentný cestovný ruch v PSK“. Dokument obsahuje opis aktuálneho stavu, budúceho stavu a navrhovaného riešenia, a to z pohľadu funkčnej, technickej, dátovej a prevádzkovej architektúry.

Cieľom projektu je vybudovanie uceleného systému pre zber, spracovanie, analýzu a vizualizáciu údajov o návštevnosti turistických a cykloturistických lokalít na území Prešovského samosprávneho kraja. Projekt zahŕňa inštaláciu 78 automatických IoT sčítačov osôb, budovanie prenosovej infraštruktúry a nasadenie dátovej platformy s výstupmi dostupnými prostredníctvom Geoportálu PSK a data.gov.sk.

Obsah dokumentu v súlade s vyhláškou zahŕňa:

• Opis navrhovaného riešenia, jeho účel, rozsah a požiadavky používateľov,
• Biznis vrstvu – definícia aktérov (PSK, mestá a obce, DMO, podnikatelia, akademická verejnosť) a ich úloh pri využívaní údajov,
• Aplikačnú vrstvu – funkcionality centrálneho systému pre zber, správu, publikovanie a vizualizáciu dát,
• Dátovú vrstvu – štruktúra údajov (počty osôb, smery pohybu, časové pečiatky), dátové modely, open data,
• Technologickú a infraštruktúrnu vrstvu – IoT sčítače, prenosové technológie (LoRaWAN, GSM), zabezpečený prístup, cloud hosting,
• Bezpečnostnú architektúru – ochrana integrity údajov, anonymizácia výstupov, GDPR súlad,
• Prevádzku a údržbu – monitoring zariadení, aktualizácie systému, škálovateľnosť, SLA,
• Špecifikáciu údajov – spôsob zberu, štruktúra, periodicita, spôsob publikovania,
• Požiadavky na prevádzku, dokumentáciu a zdrojové kódy v prípade rozšíriteľnosti platformy.

Merané údaje a prínosy systému:

IoT sčítače budú poskytovať údaje o:

• počte prechádzajúcich osôb za určený časový interval,
• smere pohybu,
• presnom čase,
• type trasy (turistická, cykloturistická, mestská),
• možnostiach vyhodnotenia intenzity návštevnosti podľa dňa, času, sezóny a lokality.

Tieto údaje budú využívané na:

• strategické rozhodovanie PSK a miestnych samospráv,
• plánovanie infraštruktúry cestovného ruchu a mobility,
• zvýšenie transparentnosti cez otvorené dáta,
• cieľový marketing a podpora menej navštevovaných oblastí,
• ochranu preťažených lokalít a rovnomerné rozloženie návštevnosti.

Technické požiadavky a integrácia:

Projekt predpokladá integráciu výstupov do Geoportálu PSK, ktorý bude slúžiť ako analytický a vizualizačný nástroj pre celé územie kraja. Údaje budú zároveň sprístupňované prostredníctvom Integračného dátového systému verejnej správy na portáli data.gov.sk.

4.Architektúra riešenia projektu

4.1Biznis vrstva

Súčasný stav v oblasti správy údajov o návštevnosti v Prešovskom samosprávnom kraji je charakteristický absenciou jednotného systému na zber, uchovávanie, analýzu a vizualizáciu dát, ktoré by slúžili ako podklad pre plánovanie, rozvoj cestovného ruchu a územné rozhodovanie.

Dátová podpora destinačného manažmentu, regionálneho plánovania či marketingu v cestovnom ruchu sa zväčša opiera o sporadické, manuálne a nesystematické zdroje informácií, ako sú ankety, krátkodobé sčítania, subjektívne odhady miestnych aktérov alebo výstupy z jednotlivých podujatí.

Aktuálne neexistuje digitálna infraštruktúra, ktorá by umožnila automatizovaný zber a jednotnú správu údajov o pohybe návštevníkov, ani možnosť centrálne sprístupňovať výstupy samosprávam, organizáciám cestovného ruchu, podnikateľom, akademickej obci či verejnosti.

Chýbajú nasledovné kľúčové funkcionality:

• zber údajov v reálnom čase prostredníctvom automatizovaných zariadení (IoT sčítače),
• centralizované dátové úložisko, zabezpečené z pohľadu integrity a kvality dát,
• nástroje pre analytiku a vizualizáciu – umožňujúce interpretáciu trendov a rozhodovanie na základe dôkazov,
• prehľadné rozhranie pre prácu s dátami, filtrovanie, reporting a export,
• napojenie na iné systémy PSK (napr. GIS, územnoplánovacie nástroje, ekonomické a strategické plánovanie),
• publikovanie otvorených dát, ktoré by posilnili transparentnosť a participáciu verejnosti.

V súčasnosti dochádza k informačnej fragmentácii, kedy údaje o pohybe návštevníkov buď nevznikajú vôbec, alebo sú rozptýlené, neoverené, prípadne málo dostupné.

Navrhované riešenie – centrálny systém podporujúci zber, spracovanie, využívanie a zverejňovanie údajov o návštevnosti prostredníctvom IoT sčítačov – bude zásadne meniť spôsob, akým PSK a jeho partneri pristupujú k plánovaniu a riadeniu cestovného ruchu a územného rozvoja. Odstráni nedostatky súčasného stavu a umožní:

• pravidelný a spoľahlivý monitoring návštevnosti,
• zvýšenie efektivity rozhodovania samospráv a organizácií CR,
• podporu udržateľného turizmu a rovnomerného rozvoja územia,
• otvorenie dátovej platformy širokému spektru používateľov, od analytikov po verejnosť.

Budúci pohľad

Možnosti využitia údajov o návštevnosti prostredníctvom automatizovaného zberu dát z IoT sčítačov predstavujú významný príspevok k rozvoju inteligentného riadenia cestovného ruchu a regionálneho plánovania v Prešovskom samosprávnom kraji. Získané údaje umožnia efektívne reagovať na reálne potreby územia, optimalizovať investície a vytvárať lepšie podmienky pre návštevníkov, obyvateľov i podnikateľské prostredie.

Očakávané prínosy navrhovaného riešenia zahŕňajú:

• Tvorbu cieľových akčných plánov rozvoja CR a údržby infraštruktúry – založených na presných údajoch o pohybe osôb v čase a priestore,
• Zvýšenie efektivity investícií – údaje poslúžia ako rozhodovací nástroj pri výbere lokalít pre rozvoj cyklotrás, mobiliáru či marketingových aktivít,
• Zníženie prevádzkových a organizačných nákladov – vďaka lepšiemu plánovaniu údržby a prevencie preťaženia exponovaných lokalít,
• Zavedenie jednotného systému zberu a správy údajov o návštevnosti – ktorý zabezpečí ich dlhodobú porovnateľnosť a využiteľnosť naprieč úrovňami riadenia,
• Podpora tvorby verejných politík – najmä v oblastiach CR, územného plánovania, dopravy, životného prostredia a regionálneho rozvoja,
• Otvorenie údajov širokej verejnosti a partnerom v území – prostredníctvom Geoportálu PSK a data.gov.sk, čím sa zvýši transparentnosť a participácia,
• Identifikáciu sezónnych a priestorových trendov – ktoré budú využiteľné pri optimalizácii služieb, marketingu a riadení záťaže územia,
• Zdieľanie príkladov dobrej praxe – ako súčasť pripravovaného národného projektu Kapacity pre regióny, vrátane zapojenia krajských centier dátovej podpory,
• Rozvoj lokálneho podnikania a zamestnanosti – lepšie dáta umožnia podnikateľom prispôsobiť ponuku skutočnému dopytu,
• Podpora inovatívnych technológií a netechnologických riešení – ktoré stimulujú rozvoj územia a zvyšujú jeho konkurencieschopnosť,
• Umožnenie reálnej evaluácie verejných intervencií – údaje poskytnú spätnú väzbu na dopady podujatí, investícií či nových trás.

Zavedením tohto systému vznikne platforma pre rozhodovanie založené na dôkazoch (data-driven governance), ktorá bude dôležitým prvkom pre udržateľný rozvoj cestovného ruchu a lepšie riadenie verejných zdrojov v území PSK.

Obrázok 1 Schéma technologickej, aplikačnej a prezentačnej vrstvy ÚPSK

Obrázok 2 Schéma budúcej business architektúry

IS inteligentného cestovného ruchu v PSK umožňuje zber a spracovanie dát zo senzorov v reálnom čase, čo vedie k efektívnejšiemu vyhodnocovaniu pohybu osôb (turisti, cyklisti) v území PSK.

1. Dáta sú najprv spracované – prebieha čistenie a štandardizácia dát prijatých zo senzorov (cleansing/clearing).
2. Následne sa analyzujú voči vopred nastaveným pravidlám, ktoré definujú významné zmeny pohybu v daných lokalitách (napr. prekročenie limitu návštevnosti, detekcia výpadku).
3. Na základe výsledkov analýzy sa vyvoláva reakcia, ako napríklad spustenie notifikácie alebo zásah správcu pri chybových stavoch.
4. Systém zároveň pripravuje automatizované vizualizácie a reporty, ktoré sumarizujú trendy, anomálie či využitie turistickej infraštruktúry.
5. Tieto reporty slúžia ako podklad pre tvorbu stratégií rozvoja cestovného ruchu, efektívnejšie riadenie infraštruktúry a rozhodovanie o umiestnení nových investícií (napr. cykloprístrešky, nabíjacie stanice a pod.).

Projekt zavádza Informačný systém (IS) pre spracovanie dát zo senzorov v rámci podpory správy cestovného ruchu a turizmu v Prešovskom samosprávnom kraji (PSK). Tento systém rozšíri existujúce funkcie v oblasti manažmentu dát o automatizovanú správu dát z lokalít, generovanie reportov a prehľadov, vizualizáciu online stavu návštevnosti a analýzu pohybu turistov. Cieľom je automatizácia a digitalizácia v oblasti turizmu, čo výrazne podporí a uľahčí riešenie agendy PSK, prevádzku turistických lokalít, efektívnu správu dát a tvorbu politík cestovného ruchu. Systém umožní efektívne zbieranie, spracovanie a prezentáciu dát pre občanov, Úrad PSK a aktérov cestovného ruchu, čím sa zlepší informovanosť a podpora strategického rozhodovania.

Obrázok 5 Modely biznis architektúry pre ENM a MSB

Predkladaný model To BE aplikačnej architektúry popisuje komplexný informačný systém pre správu a analýzu senzorových dát s dôrazom na flexibilitu, modularitu a integráciu. Architektúra je navrhnutá tak, aby podporovala širokú škálu funkcionalít a zabezpečovala efektívnu prácu s dátami pre rôznych užívateľov a systémy.

• IS Senzorov (Cloud platforma): Predstavuje jadro systému umiestnené v cloudovom prostredí, čo zabezpečuje škálovateľnosť a dostupnosť.
  • Modul IoT – Zber dát: Kľúčový modul pre zber surových dát priamo zo senzorov, zabezpečujúci ich spoľahlivé a efektívne prijímanie. Obdobne ako pri energetickom manažmente, kde sa zbierajú dáta o spotrebe energií, tento modul zabezpečuje príjem dát z rôznych typov senzorov (napr. sčítače dopravy, chodcov a cyklistov).
  • Modul Analýza dát: Zodpovedný za spracovanie a transformáciu surových dát na agregované analytické dáta. Tento modul vykonáva komplexné analýzy, ktoré sú základom pre generovanie reportov a vizualizácií, a to vrátane vyhodnocovania spotreby energií alebo pohybu turistov.
  • Modul Vizualizácia dát: Umožňuje interaktívne zobrazenie dát, reportov a dashboardov, zabezpečujúc prehľadné prezentovanie informácií pre rôznych užívateľov.
  • Modul Správa senzorov: Slúži na komplexnú evidenciu a správu pripojených senzorov, vrátane ich konfigurácie a monitorovania stavu. Zabezpečuje notifikácie na termíny, hodnoty a prípadné poruchy.
  • Modul Exportu dát: Poskytuje funkcie pre export spracovaných dát do rôznych formátov pre ďalšie spracovanie alebo archiváciu.
• API vrstva: Centrálny bod pre komunikáciu s externými systémami, zabezpečujúci otvorenosť a možnosť integrácie.
  • Verejné API (OpenAPI): Umožní prístup k vybraným informáciám a dátam pre externých partnerov a aplikácie, napríklad pre vizualizáciu dát na Geoportáli.
  • Neverejné API: Určené pre internú komunikáciu a špecifické integrácie s inými systémami v rámci Kraja, napríklad pre prepojenie s modulom Spracovanie dát a reportov.
• Dávkové spracovanie dát/reportov: Modul pre dávkové spracovanie dát, navrhnutý tak, aby neovplyvňoval bežný chod IS systémov, čím zabezpečuje stabilitu a výkon.
• Integračný modul: Generický modul na integráciu celého riešenia, zabezpečujúci bezproblémovú komunikáciu s rôznymi externými a internými komponentmi.
  • IAM – integrácia na centrálnu správu a autentifikáciu a autorizáciu užívateľov kraja: Zabezpečuje jednotnú správu prístupových práv a autentifikáciu pre všetkých užívateľov systému.
  • IoT – integrácia na IoT zariadenia: Umožňuje priamu komunikáciu a zber dát z rôznych typov IoT senzorov.
  • Integration API – integrácia na externé systémy: Poskytuje rozhrania pre pripojenie k ďalším externým systémom, ako sú napríklad:
    • Kataster portál: Pre získavanie relevantných geopriestorových informácií, ak by boli potrebné pre kontext senzorových dát.
    • SPIN: Predpokladá sa integrácia s informačným systémom PSK (SPIN), čo umožní komplexné využitie senzorových dát v širšom kontexte agendy kraja.
• Platforma kraja: Predstavuje koncové platformy, ktoré využívajú dáta a služby IS senzorov.
  • Geoportál: Slúži na prezentáciu dát na interaktívnej mape a vizualizáciu výstupov pre širokú verejnosť a odborníkov.
  • Iné platformy: Reprezentujú ďalšie informačné systémy alebo aplikácie v rámci kraja, ktoré budú benefitovať z prístupu k spracovaným senzorovým dátam.

Táto architektúra zabezpečí nielen efektívny zber a analýzu dát zo senzorov, ale aj ich integráciu do existujúcich systémov a nástrojov PSK, čím výrazne prispeje k automatizácii a digitalizácii procesov súvisiacich s cestovným ruchom, dopravou a správou majetku kraja.

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

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

4.1.2Jazyková podpora a lokalizácia

Všetky GUI obrazovky IS a reporty budú dodané v slovenskom jazyku. Riešenie musí podporovať multi-jazyčnosť v prípade potreby do budúcnosti pridať aj iný jazyk.u.

4.2Aplikačná vrstva

Obrázok 6 Model AS IS aplikačnej architektúry

Obrázok 7 Model To BE aplikačnej architektúry

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

Aktuálne neexistujú existujúce IS.

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

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

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

Projekt nebude využívať nadrezortné ISVS.

4.2.4Prehľad plánovaných integrácií ISVS na nadrezortné ISVS – spoločné moduly podľa zákona č. 305/2013 e-Governmente – TO BE

Irelevantné.

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

Irelevantné.

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

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

4.2.7Aplikačné služby na integráciu – TO BE

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

 as_67350         Dátová analytika,                                            Poskytovaná / Konzumujúca            Áno/Nie                       Áno/Nie                                 Áno/Nie

                     zber a archivácia dát

 

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

Irelevantné.

4.2.9Konzumovanie údajov z IS CSRU – TO BE

Irelevantné.

4.3Dátová vrstva

Popis dát, ktoré PSK spracováva

V oblasti cestovného ruchu a regionálneho rozvoja Prešovský samosprávny kraj v súčasnosti nedisponuje jednotným, automatizovaným systémom na zber, správu a analýzu údajov o pohybe návštevníkov. Zber dát je realizovaný manuálne, nepravidelne a fragmentovane, čo výrazne znižuje ich výpovednú hodnotu a využiteľnosť pre strategické plánovanie.

• Agenda dát o návštevnosti je spracovávaná prostredníctvom rôznych ad hoc nástrojov, ako sú anketové prieskumy, emailová komunikácia, samostatné Excelové tabuľky alebo výstupy z jednorazových sčítaní osôb.
  Neexistuje automatizovaný algoritmus ani ucelený systém, ktorý by tieto údaje kontinuálne zbieral, vyhodnocoval a sprístupňoval pre potreby kraja a jeho partnerov.
• PSK nemá vybudovanú IoT infraštruktúru pre zber údajov o návštevnosti, no v projekte sa predpokladá jej zavedenie prostredníctvom 78 sčítačov osôb, ktoré budú inštalované v strategických lokalitách. Cieľom je zaviesť automatizovaný zber údajov v reálnom čase, bez potreby manuálneho zásahu.
• Aktuálne spracovanie údajov si vyžaduje fyzické získavanie a prepisovanie údajov, čo je časovo a personálne náročné a náchylné na chyby. Dátové toky nie sú centralizované, ani previazané s ďalšími informačnými systémami PSK (napr. GIS, strategické plánovanie, ekonomické nástroje).

• Predmetom projektu je odstránenie týchto nedostatkov a vybudovanie centrálnej platformy, ktorá umožní:

  • zber údajov prostredníctvom IoT zariadení,
  • ich bezpečné uchovávanie,
  • vizualizáciu trendov (časové, priestorové, sezónne),
  • analytické spracovanie pre potreby odborov Úradu PSK, miestnych samospráv, organizácií CR a podnikateľov,
  • publikovanie otvorených dát vo forme API alebo datasetov na Geoportáli PSK a data.gov.sk.

4.3.1Údaje v správe organizácie

Zavedenie procesu riadenia pre manažment údajov

Pre úspešné a dlhodobo udržateľné fungovanie systému inteligentného zberu a využívania údajov o návštevnosti v rámci projektu „Inteligentný cestovný ruch v PSK“ je nevyhnutné zaviesť proces riadenia dát (data governance) nad informačnými systémami a platformami, ktoré budú obsahovať objekty evidencie súvisiace s pohybom osôb, lokalitami, časovými pečiatkami, sezónnosťou či typom trasy.

Tento proces sa musí opierať o technickú, organizačnú aj dátovú vrstvu riešenia:

• Zavedenie jednotnej dátovej politiky, ktorá bude definovať zodpovednosti, kvalitu údajov, ich štruktúru, periodicitu aktualizácie, bezpečnosť a publikovanie.
• Zriadenie úlohy dátového kurátora (dátového architekta) – v zmysle strategickej priority Manažment údajov a Otvorené údaje, ktorého úlohou bude koordinovať koncepčný prístup k správe údajov v rámci projektu a nadväzujúcich systémov PSK (napr. Geoportál PSK, Smart Data Hub, územnoplánovacie nástroje).

• Dátový kurátor bude zodpovedný za:

  • metodické vedenie v oblasti štruktúrovania, kvality a bezpečnosti údajov,
  • riadenie životného cyklu dát (zber, validácia, archivácia, publikovanie),
  • koordináciu spolupráce medzi odbormi a dátovými vlastníkmi,
  • údržbu katalógu údajov a metadát,
  • publikovanie vybraných datasetov ako otvorené údaje cez data.gov.sk.
• Z organizačného hľadiska sa predpokladá úprava vnútornej štruktúry PSK smerom k zriadeniu rezortnej dátovej kancelárie, ktorá bude plniť úlohu centrálneho garanta kvality a koordinácie dátových tokov v rámci celého kraja – v súlade s Národnou koncepciou informatizácie verejnej správy (NKIVS).

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

Obrázok 8 Zjednodušený doménový model

4.3.3Referenčné údaje

Nerelevantné. Projekt nevyužíva referenčné údaje.

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

Nerelevantné. Projekt nevyužíva referenčné údaje.

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

4.3.4Kvalita a čistenie údajov

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

Projekt neimplementuje procesy kvality a čistenia údajov.

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

Nerelevantné

4.3.5Otvorené údaje

Pri tvorbe otvorených dát požadujeme zabezpečiť kompatibilitu s centrálnym portálom otvorených dát MIRRI SR - data.slovensko.sk.
Dodávateľ musí v rámci projektu zabezpečiť vytvorenie lokálneho katalógu otvorených dát (LKOD) podľa štandardu DCAT-AP-SK2.0 (https://github.com/datova-kancelaria/dcat-ap-sk-2.0), alebo SPARQL Endpoint, sprístupniť datasety data.slovensko.sk, a registrovať LKOD do centrálneho Národného katalógu otvorených údajov (dostupný na data.gov.sk).
 

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.

4.3.6Analytické údaje

PSK neplánuje integráciu modulov na sprístupňovanie údajov pre analytické jednotky a pre špeciálne organizačné útvary orgánov verejnej moci.

4.3.7Moje údaje

 Realizáciou projektu nebudú spracovávané údaje, ktoré spĺňajú charakter definície mojich údajov.

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

Vyplňte nasledujúcu súhrnnú tabuľku pre kategorizáciu údajov dotknutých projektom z pohľadu využiteľnosti týchto údajov.
V tabuľke uveďte OE z tabuľky uvedenej v kapitole 4.3.2 Dátový rozsah projektu - Prehľad objektov evidencie - TO BE.

4.4Technologická vrstva

4.4.1Prehľad technologického stavu - AS IS

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

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

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

4.4.3Návrh riešenia technologickej architektúry

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

• prístup k riešeniu technologickej architektúry a súvisiace architektonické rozhodnutia
• popis požiadaviek na prevádzkové prostredia (vývoj, test, produkčné)
• diagram nasadenia a komunikačnej infraštruktúry.
  Pri výbere požiadaviek na riešenie, je potrebné klásť dôraz na výber služieb, ktoré sú založené na najmodernejších technológiách, prostredníctvom ktorých bude vytvorený predpoklad na vývoj/tvorbu moderného ISVS. Pre navrhované riešenie odporúčame použiť prístup pre vývoj takzvaných Cloud Native aplikácií. Riešenie „Cloud-native“ ISVS, je v čo najväčšej miere nezávislé na umiestnení v cloude, resp. datacentre. Nezávislosť novo vyvíjaného ISVS od cloudového prostredia by malo byť základnou prioritou a podmienkou architektúry ISVS.

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

Zaevidujte v MetaIS využívanie infraštruktúrnych služieb vašimi ISVS. Podrobné informácie o evidencii využívania infraštruktúrnych služieb sú uvedené v Používateľskej príručke MetaIS, kap. 2.1.4.3 ISVS využívajúci infraštruktúrne služby.

• Vývojové – určené pre vývoj systému
• Testovacie – určené pre testy nových modulov, úprav, zmenových požiadaviek a retesty na úrovni upgrade‑ov (nie pre záťažové testovanie).
• Produkčné – určené pre produkčnú (ostrú) prevádzku systému
• Ďalšie existujúce alebo plánované prostredia, ktoré budú potrebné, napr. predprodukčné, integračné, fix prostredie
  Poznámky:
  Ak potrebujete pre príslušné prostredie viaceré infraštruktúrne služby, pridajte si potrebné riadky.
  V prípade, že neplánujete využitie cloudových služieb z katalógu služieb vládneho cloudu, uveďte v tabuľke požadovaných výpočtových zdrojov (sizing) pre jednotlivé prostredia parametre výpočtových zdrojov, ktoré plánujete v projekte použiť. Namiesto názvu a kódu infraštruktúrnej služby uveďte kód a názov výpočtového zdroja evidovaného v MetaIS.
  V súlade s NKIVS by technologická architektúra mala byť založená na cloudových službách. V rámci verejného obstarávania je potrebné potenciálneho uchádzača o zákazku požiadať o návrh technologickej infraštruktúry potrebnej pre implementáciu a prevádzku navrhovaného riešenia. Dodávateľ by pre svoj návrh technologického prostredia mal využiť hlavne cloudové služby vládneho cloudu uvedené v katalógu služieb, ktoré prešli procesom klasifikácie, hodnotenia, registrácie a zaradenia do katalógu služieb zverejnenom na stránke MIRRI: https://www.mirri.gov.sk/sekcie/informatizacia/egovernment/vladny-cloud/katalog-cloudovych-sluzieb.

4.5Bezpečnostná architektúra

Uveďte popis AS IS stavu z pohľadu súčasného riešenia bezpečnostnej architektúry,
Uveďte popis TO BE stavu riešenia bezpečnostnej architektúry (+ popis alternatív),
Uveďte súlad navrhovanej bezpečnostnej architektúry s dotknutými právnymi normami a zároveň s technickými normami, ktoré stanovujú úroveň potrebnej bezpečnosti IS, pre manipuláciu so samotnými dátami, alebo technické/technologické/personálne zabezpečenie samotnej výpočtovej techniky/HW vybavenia. Ide najmä o:

• Zákon č. 95/2019 Z.z. o informačných technológiách vo verejnej správe
• Zákon č. 69/2018 Z.z. o kybernetickej bezpečnosti
• Zákon č. 45/2011 Z.z. o kritickej infraštruktúre
• vyhláška Úradu podpredsedu vlády Slovenskej republiky pre investície a informatizáciu č. 78/2020 Z. z. o štandardoch pre informačné technológie verejnej správy
• vyhláška Úradu podpredsedu vlády Slovenskej republiky pre investície a informatizáciu č. 179/2020 Z. z., ktorou sa ustanovuje spôsob kategorizácie a obsah bezpečnostných opatrení informačných technológií verejnej správy
• vyhláška Úradu na ochranu osobných údajov Slovenskej republiky č. 158/2018 Z. z. o postupe pri posudzovaní vplyvu na ochranu osobných údajov
• Nariadenie Európskeho parlamentu a Rady (EÚ) 2016/679 z 27. apríla 2016 o ochrane fyzických osôb pri spracúvaní osobných údajov a o voľnom pohybe takýchto údajov, ktorým sa zrušuje smernica 95/46/ES (všeobecné nariadenie o ochrane údajov)
• Zákon č. 18/2018 Z. z. o ochrane osobných údajov a o zmene a doplnení niektorých zákonov.
  Stručne popíšte postupy na dosiahnutie potrebnej úrovne bezpečnosti a spôsob zabezpečenia aktív projektu na jednotlivých vrstvách architektúry (dôvernosť, dostupnosť a integrita).
  Uveďte požiadavky na realizáciu Bezpečnostného projektu⁶
  Doplňte požiadavky na používateľské role, správu prístupov a správu aplikácie:
• Interní používatelia (pracovníci jednotlivých organizačných jednotiek, pracovníci administrácie a správy aplikácie, pracovníci prevádzky a podpory)
• Externí používatelia (zákazníci, partneri - tretie strany).

5.Závislosti na ostatné ISVS / projekty

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

6.Zdrojové kódy

Doplňte požiadavky na zdrojové kódy (napr. zo vzorovej zmluvy). Aké druhy, formy a štruktúry zdrojových kódov požadujte odovzdať. Stručne popíšte aj spôsob ich preberania, periodicitu (pri akých míľnikoch) a spôsob archivácie,
Doplňte pravidlá pre preberanie, správu a archiváciu zdrojových kódov a tieto pravidlá následne preniesť do Zmluvy o dielo alebo zmluvy na podporu (ZoD/SLA).
Naviažte preberanie/odovzdávanie zdrojových kódov na fakturačné míľniky.
Navrhnite spôsob, ako predísť „Vendor lock-in“ = t.j. dodávané riešenie musí byť v súlade so Zákonom o ITVS (ktorý „vendor lock-in“ nepovoľuje). Následne ustanovenia predchádzaniu vendor-lockinu musia byť zahrnuté aj v ZoD a SLA.
Usmernenia pre oblasť zdrojových kódov:

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

7.Prevádzka a údržba

Doplňte popis AS IS stavu zabezpečenia prevádzky a údržby a úroveň poskytovania služieb (SLA).
Doplňte popis TO BE stavu zabezpečenia prevádzky a údržby a úroveň poskytovania služieb (SLA).
Uveďte prehľad všetkých predpokladaných požiadaviek na prevádzku a údržbu cieľového riešenia.

7.1Prevádzkové požiadavky

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

7.1.1Úrovne podpory používateľov

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

• L1 podpory IS (Level 1, priamy kontakt zákazníka) - jednotný kontaktný bod verejného obstarávateľa – IS Solution manager, ktorý je v správe verejného obstarávateľa a v prípade jeho nedostupnosti Centrum podpory používateľov (zabezpečuje prevádzkovateľ IS a DataCentrum).
• L2 podpory IS (Level 2, postúpenie požiadaviek od L1) - vybraná skupina garantov, so znalosťou IS (zabezpečuje prevádzkovateľ IS – verejný obstarávateľ).
• L3 podpory IS (Level 3, postúpenie požiadaviek od L2) - na základe zmluvy o podpore IS (zabezpečuje úspešný uchádzač).
  Definícia:
• Podpora L1 (podpora 1. stupňa) - začiatočná úroveň podpory, ktorá je zodpovedná za riešenie základných problémov a požiadaviek koncových užívateľov a ďalšie služby vyžadujúce základnú úroveň technickej podpory. Základnou funkciou podpory 1. stupňa je zhromaždiť informácie, previesť základnú analýzu a určiť príčinu problému a jeho klasifikáciu. Typicky sú v úrovni L1 riešené priamočiare a jednoduché problémy a základné diagnostiky, overenie dostupnosti jednotlivých vrstiev infraštruktúry (sieťové, operačné, vizualizačné, aplikačné atď.) a základné užívateľské problémy (typicky zabudnutie hesla), overovanie nastavení SW a HW atď.
• Podpora L2 (podpora 2. stupňa) – riešiteľské tímy s hlbšou technologickou znalosťou danej oblasti. Riešitelia na úrovni Podpory L2 nekomunikujú priamo s koncovým užívateľom, ale sú zodpovední za poskytovanie súčinnosti riešiteľom 1. úrovne podpory pri riešení eskalovaného hlásenia, čo mimo iného obsahuje aj spätnú kontrolu a podrobnejšiu analýzu zistených dát predaných riešiteľom 1. úrovne podpory. Výstupom takejto kontroly môže byť potvrdenie, upresnenie, alebo prehodnotenie hlásenia v závislosti na potrebách Objednávateľa. Primárnym cieľom riešiteľov na úrovni Podpory L2 je dostať Hlásenie čo najskôr pod kontrolu a následne ho vyriešiť - s možnosťou eskalácie na vyššiu úroveň podpory – Podpora L3.
• Podpora L3 (podpora 3. stupňa) - Podpora 3. stupňa predstavuje najvyššiu úroveň podpory pre riešenie tých najobťiažnejších Hlásení, vrátane prevádzania hĺbkových analýz a riešenie extrémnych prípadov.
  Pre služby sú definované takéto SLA:
• Help Desk je dostupný cez IS Solution manager a pre vybrané skupiny užívateľov cez telefón a email, incidenty sú evidované v IS Solution manager,
• Dostupnosť L3 podpory pre IS je 8x5 (8 hodín x 5 dní od 8:00h do 16:00h počas pracovných dní),

7.1.2Riešenie incidentov – SLA parametre

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

• Služby systémovej podpory na požiadanie (nad paušál)
• Služby realizácie aplikačných zmien vyplývajúcich z legislatívnych a metodických zmien (nad paušál)
  Pre tieto služby budú dohodnuté osobitné parametre dodávky.

7.2Požadovaná dostupnosť IS:

7.2.1Dostupnosť (Availability)

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

• 90% dostupnosť znamená výpadok 36,5 dňa
• 95% dostupnosť znamená výpadok 18,25 dňa
• 98% dostupnosť znamená výpadok 7,30 dňa
• 99% dostupnosť znamená výpadok 3,65 dňa
• 99,5% dostupnosť znamená výpadok 1,83 dňa
• 99,8% dostupnosť znamená výpadok 17,52 hodín
• 99,9% (“tri deviatky”) dostupnosť znamená výpadok 8,76 hodín
• 99,99% (“štyri deviatky”) dostupnosť znamená výpadok 52,6 minút
• 99,999% (“päť deviatok”) dostupnosť znamená výpadok 5,26 minút
• 99,9999% (“šesť deviatok”) dostupnosť znamená výpadok 31,5 sekúnd
  Hoci je obvyklé uvádzať dostupnosť v percentách, presnejšie ukazovatele sú vyjadrením doby obnovenia systému a na množstvo dát, o ktoré môžeme prísť:
• RTO (Recovery Time Objective) - doba obnovenia systému, t.j. za ako dlho po výpadku musí byť systém funkčný (pre bližšie info klik na nadpis)
• RPO (Recovery Point Objective) - aké množstvo dát môže byť stratené od vymedzeného okamihu
• Recovery Time - čas potrebný k obnove
  Riešenie dostupnosti v praxi: Nedostupnosť dát je jedným z rizík, ktorý môže postihnúť každú organizáciu. Dostupnosť je jedným s kľúčových požiadaviek na každý dôležitý informačný systém a vplyv na dostupnosť má mnoho faktorov, napríklad:
• Dostupnosť servera
• Dostupnosť pripojenie k internetu
• Dostupnosť databázy
• Dostupnosť webových stránok
  V prípade, že je časť softvér alebo infraštruktúra zabezpečovaná externe (napr. hosting, webhosting), prenáša sa zodpovednosť za dostupnosť týchto komponentov na dodávateľa. Potom je potrebné mať vhodným spôsobom ošetrenú úroveň dostupnosti, ktorú musí dodávateľ dodržať. Zvyčajne je dostupnosť súčasťou dohody o úrovni poskytovaných služieb (SLA).

7.2.2RTO (Recovery Time Objective)

Recovery Time Objective (zvyčajne sa požíva skratka RTO) je jeden z ukazovateľov dostupnosti dát. RTO vyjadruje množstvo času potrebné pre obnovenie dát a celej prevádzky nedostupného systému (softvér). Môže byť, v závislosti na použitej technológii, vyjadrené v sekundách, hodinách či dňoch.
Využitie RTO v praxi: Ukazovateľ RTO sa z pohľadu zákazníka využíva pre vyjadrenie doby pre obnovu dát. (napr. formou SLA). Na druhú stranu poskytovatelia dnes môžu voliť rôzne technológie zálohovanie, respektíve replikovanie dát a dobu obnovy dát znížiť až k nulovému výpadku. Existujúce technológie sa delia zhruba nasledovne:

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

7.2.3RPO (Recovery Point Objective)

Recovery Point Objective (zvyčajne sa požíva skratka RPO) je jeden z ukazovateľov dostupnosti dát. RPO vyjadruje, do akého stavu (bodu) v minulosti možno obnoviť dáta. Inými slovami množstvo dát, o ktoré môže organizácia prísť.
Využitie RPO v praxi: Ukazovateľ RPO sa z pohľadu zákazníka využíva pre vyjadrenie množstva obnoviteľných dát. (napr. formou SLA). Na druhú stranu poskytovatelia dnes môžu voliť rôzne technológie zálohovanie, respektíve replikovanie dát a bod obnovy dát znížiť až k nulovej strate. Existujúce technológie sa delia zhruba nasledovne:

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

8.Požiadavky na personál

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

9.Implementácia a preberanie výstupov projektu

Posúďte a doplňte spôsoby realizácie projektu a ich dopad na harmonogram projektu a preberanie výstupov pripravovaného projektu.
V zmysle Vyhlášky 401/2023 Zz o riadení projektov a zmenových požiadaviek v prevádzke je potrebné posúdiť výber spôsobu realizácie projektu metódou waterfall, metódou agile alebo metódou waterfall s prvkami metódy agile.
V zmysle vyhlášky 401/2023 Zz o riadení projektov a zmenových požiadaviek v prevádzke je možné pristupovať k realizácii projektu prostredníctvom čiastkových plnení, t.j. inkrementov, a to:

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

10.Prílohy

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

• Podľa §4 ods. 10 vyhlášky č. 401/2023 Z.z je potrebné zrealizovať pripomienkovanie Projektového prístupu odbornou verejnosťou, zaevidovať a vyhodnotiť pripomienky odbornej verejnosti.
• Oznámenie o začatí verejného pripomienkovania zverejniť v centrálnom metainformačnom systéme verejnej správy na mieste určenom Orgánom vedenia.
• Dať na schválenie riadiacemu výboru výstupy po zverejnení vyhodnotenia pripomienok.
• Vyhodnotenie zverejniť na webovom sídle objednávateľa (do projektového adresára).
  1 Podľa § 2 ods. 1 písm. i) vyhlášky MIRRI č. 401/2023 Z.z. o riadení projektov a zmenových požiadaviek v prevádzke informačných technológií verejnej správy sa objednávateľom rozumie správca alebo prevádzkovateľ ITVS, ktorý projekt realizuje alebo chce realizovať.
  2 https://avssr.horizzon.cloud/. O prístup do repozitára a poskytnutie licencie pre modelovací nástroj pracujúci s repozitárom modelov je potrebné požiadať na e-mailovej adrese: sprava_EA@mirri.gov.sk.
  3 The Open Group ArchiMate Model Exchange File Format Standard a špecifikácia BPMN 2.0
  4 Napr. modelovací nástroj Archi - Open Source ArchiMate Modelling: https://www.archimatetool.com.
  5 Napr. modelovací nástroj pre BPMN - Camunda Modeler - Open Source Desktop Modeler: https://camunda.com/download/modeler/.
  6 Správca ISVS je povinný zaviesť v organizácii systém riadenia informačnej (a kybernetickej) bezpečnosti a vypracovať bezpečnostný projekt pre ISVS podľa vyhlášky Úradu podpredsedu vlády Slovenskej republiky pre investície a informatizáciu č. 179/2020 Z. z., ktorou sa ustanovuje spôsob kategorizácie a obsah bezpečnostných opatrení informačných technológií verejnej správy)
  Strana 23/23