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

Dokument I-03 sumarizuje prístup k projektu podľa vyhlášky 401/2023: popis navrhovaného riešenia, stručnú architektúru (AS-IS/TO-BE), dátový rozsah, technologické a bezpečnostné požiadavky, prevádzku a prílohy.

2. Použité skratky a pojmy

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

Pre účely tohto projektu sa zavádza jednotný systém označovania požiadaviek, ktorý umožní ich jednoznačnú identifikáciu, jednoduchú správu a sledovanie v projektovej dokumentácii (najmä v Katalógu požiadaviek I-04).

• Funkcionálne (používateľské) požiadavky
• Označenie: FRxx
• Vysvetlenie:
  • F – funkcionálna (používateľská) požiadavka,
  • R – požiadavka,
  • xx – poradové číslo požiadavky.

Príklad:

• FR01 – Systém musí umožniť evidenciu podnetov od občanov.
• FR02 – Systém musí poskytovať export dát do formátu CSV/XML.

• Nefunkcionálne (kvalitatívne, výkonové) požiadavky

• Označenie: NRxx
• Vysvetlenie:
  • N – nefunkčná požiadavka (NFR),
  • R – požiadavka,
  • xx – poradové číslo požiadavky.

Príklad:

• NR01 – Dostupnosť systému musí byť minimálne 98,5 %.
• NR02 – Odozva systému pri vyhľadávaní údajov nesmie presiahnuť 3 sekundy.

• Ostatné typy požiadaviek

Podľa potrieb projektu je možné definovať aj ďalšie kategórie:

• SRxx – Security Requirements (bezpečnostné požiadavky).
  • SR01 – Všetky prenosy dát musia byť zabezpečené protokolom HTTPS/TLS.
• DRxx – Data Requirements (požiadavky na údaje).
  • DR01 – Systém musí ukladať všetky záznamy v súlade so zákonom o archívoch.
• IRxx – Integration Requirements (požiadavky na integráciu).

IR01 – Systém musí umožniť export údajov pre napojenie na MetaIS

4.Popis navrhovaného riešenia

Vybraná alternatíva (MCA): minimalistická dátová platforma s IoT zberom a agregáciou, výstupy CSV/HTML, publikovanie otvorených dát a odovzdávanie analytických údajov podľa Prílohy č. 11. Alternatíva bola zvolená pre pomer prínos/náklady, rýchlu implementáciu, nižšie riziko a udržateľnosť prevádzky.

Architektonický koncept (5 blokov):

1. IoT senzory – anonymný zber počtov a pohybu objektov + doplnkové prevádzkové veličiny.
2. Zber/validácia – prijem (HTTP/MQTT), normalizácia, kontrola kvality.
3. Úložisko časových rád + metadáta – jednotné dátové modely, verzovanie a retenčná politika.
4. API a exporty – dávkové generovanie CSV/HTML pre interné rozhodovanie, CSV/JSON pre publikáciu a analytiku.
5. Publikácia/odovzdanie údajov – LKOD/DCAT‑AP‑SK 2.0 → data.slovensko.sk (open data); odovzdanie ne‑OD analytických údajov podľa Prílohy č. 11.

Rozhrania a integrácie:

• Externé: data.slovensko.sk (NKOD), centrálne analytické rozhranie (def. formát a periodicita).
• Interné: obecný web (HTML reporty), prístup pre vedenie a oddelenia.

Dáta a správa údajov:

• Hlavné datasety: mobilita (počty/intervaly), doplnkové prevádzkové veličiny.
• Otvorené údaje (min. 3★): pravidelné publikovanie; licenčné a technické metadáta podľa DCAT‑AP‑SK 2.0.
• Ochrana súkromia: len agregované, anonymné merania; bez obrazových záznamov.

Nefunkčné požiadavky:

• Dostupnosť verejných rozhraní ≥ 99,5 %; denné zálohy; základný monitoring.
• Bezpečnosť: TLS, IAM/RBAC, audit prístupov.

Prevádzka a udržateľnosť:

• Jednoduchý L1/L2 support (obec/dodávateľ), dokumentácia v CIMS (vyhláška 401/2023).
• Prevencia „vendor lock‑in“: otvorené formáty (CSV/JSON), zdokumentované API, prenositeľné konfiguračné skripty.

Etapy (návrh):

• E1 – Pilot (PoC): 2–3 lokality, overenie kvality dát a procesu publikácie.
• E2 – Roll‑out: rozšírenie senzoriky, stabilizácia exportov a pravidelnej publikácie.

.

5. Architektúra riešenia projektu

Typ projektu a rozsah popisu: projekt nebuduje nový veľký ISVS; ide o nasadenie IoT zberu dát a minimalistickej dátovej platformy (ingest → úložisko časových rád → exporty CSV/HTML a API) s publikáciou otvorených údajov a odovzdávaním analytických údajov podľa výzvy. Preto je biznis vrstva popísaná stručne (dopad na rozhodovanie), detailnejšie uvádzame aplikačnú, dátovú a technologickú vrstvu.

Metodika a nástroj: ArchiMate ≥ v3 (odporúčaný nástroj Archi alebo iný s exportom do The Open Group ArchiMate Model Exchange File Format). Modely budú priložené vo formáte .archimate a vo formáte PNG/PDF.

Súlad s I-04 (Katalóg požiadaviek): návrh je zosúladený s funkčnými, nefunkčnými a technickými požiadavkami definovanými v I‑04/BC‑CBA. Kľúčové väzby:

• Funkčné: príjem meraní, validácia/normalizácia, agregácie, generovanie CSV/HTML, publikácia open data (LKOD/DCAT‑AP‑SK 2.0), odovzdávanie analytických údajov.
• Nefunkčné: dostupnosť ≥ 99,5 % pre verejné rozhrania, TLS, IAM/RBAC, audit, zálohy a retenčné politiky.
• Technické: štandardné protokoly (MQTT/HTTP), otvorené formáty (CSV/JSON), OGC pre geo-vrstvy, DCAT‑AP‑SK 2.0 pre metadáta, OpenAPI pre API.

Prehľad modelov a náhľadov (minimálny súbor):

• AS‑IS – Layered View: Obec → Rozhodovanie; Zber dát neexistuje (dopad: rozhodovanie bez časových rád).
• TO‑BE – Application Cooperation: IoT senzory → Zber/validácia → Dátová platforma (API+LKOD) → Dashboardy/HTML → Rozhodovanie.
• TO‑BE – Technology Usage/Deployment: IoT brána → MQTT broker → TimeSeries DB → Export/API → Dashboard/HTML (hybrid: on‑prem edge + hostované služby).
• TO‑BE – Motivation (voliteľné): ciele, požiadavky, obmedzenia a ich väzba na komponenty.

Delta (zmena AS‑IS → TO‑BE):

• Nové komponenty: IoT brána, ingest, TimeSeries DB, API/LKOD, Dashboard/HTML.
• Nové aplikačné služby: príjem meraní, analytika, publikácia otvorených údajov.
• Nové dátové objekty: časové rady mobilita/prevádzka, metadáta DCAT‑AP‑SK, exporty CSV/HTML.
• Dopad na procesy: rozhodovanie založené na pravidelných dátach; žiadna zmena kompetencií úradu, iba pracovné postupy s dátami (validácia/publikácia).
• Bez negatívneho dopadu na existujúce IS (spisová služba, web) – iba využitie na publikáciu.

Väzba na M‑06 (MetaIS):

• Vytvorenie/aktualizácia komponentov: Koncová služba „Zverejňovanie otvorených údajov obce“ (Plánovaná), Aplikačná služba „Dátová platforma – rozhodovacie podklady“, Technologický komponent „IoT brána/MQTT/TimeSeries DB“.
• Evidencia vzťahov: integrácia na NKOD (data.slovensko.sk), integrácia „Odovzdávanie analytických údajov“.
• Uloženie modelov: priložiť AS‑IS a TO‑BE architektúru do MetaIS (alebo do I‑03 ako prílohy) vo formáte .archimate a PNG/PDF.
• Priebežná aktualizácia atribútov a SLA pre budované/rozvíjané koncové služby podľa používateľskej príručky MetaIS.

Umiestnenie príloh (názvy súborov):

• I-03_VLM_AS-IS.archimate, I-03_VLM_AS-IS.png
• I-03_VLM_TO-BE.archimate, I-03_VLM_TO-BE.png

Poznámka k rozsahu: keďže projekt nie je migrácia do vládneho cloudu ani rozvoj veľkého ISVS, biznis vrstva je stručná (dopad na ŽS a rozhodovanie), aplikačná/dátová/technologická vrstva obsahujú detail, ktorý umožní vyhodnotiť dopady a realizovateľnosť.

Obrázok 1. stav AS IS

Obrázok 2. Stav TO BE

5. Biznis vrstva

Projekt má dopad najmä na rozhodovanie samosprávy. Nezavádza novú „front-office“ agendu pre občana, ale vytvára interné rozhodovacie podklady a verejné otvorené dáta. Biznis vrstva je preto zameraná na 3 kľúčové životné situácie (ŽS) s najväčším dopadom na rozpočet a spokojnosť obyvateľov.

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

Tabuľka 1 prehľad koncových služieb

Obrázok 3 Model biznis architektúry TO BE

5.2 Jazyková podpora a lokalizácia

Používateľské rozhranie a výstupy sú určené pre obec a verejnosť.

• Jazyk rozhraní a reportov: slovenčina.
• Formát výstupov: CSV a HTML reporty s popismi v slovenskom jazyku.
• Open data metadáta: DCAT-AP-SK 2.0 – povinné atribúty v slovenčine; názvy datasetov budú zrozumiteľné aj pre širšiu komunitu (G2B, akademická obec).
• Nepredpokladá sa viacjazyčná lokalizácia – všetky služby sú určené pre územie SR, hlavnými používateľmi sú slovenskí občania, podnikatelia a štátne orgány.

6. Aplikačná vrstva

AS-IS stav

• Obec v súčasnosti nemá aplikačný komponent na systematický zber dát.
• Používané sú iba ad-hoc tabuľky (Excel), webové sídlo a spisová služba.
• Pre rozhodovanie neexistuje dátová podpora, údaje sa zbierajú jednorazovo.
•  

TO-BE stav – aplikačná vrstva

Popis:
Projektom sa vytvorí jednoduchý aplikačný komponent – „Systém na zber a spracovanie dát“, ktorý bude samostatným riešením obce. Tento komponent bude:

• agregovať údaje zo senzorických zariadení (IoT senzory),
• exportovať ich vo formáte CSV/HTML (príp. XML) na účely reportingu a rozhodovania,
• všetky dáta budú anonymizované a agregované, systém nebude identifikovať osoby.

Vzťahy na biznis architektúru:

• Aplikačný komponent podporuje biznis službu: Rozhodovanie na základe dát o stave verejného priestoru.
• Prepája sa s aktérmi: vedenie obce, technické služby, investičný pracovník.

Aplikačné komponenty a služby (Archimate pojmy):

• Application Component: Systém na zber a spracovanie dát
• Application Function: Agregácia, anonymizácia, export dát
• Application Interface: Užívateľské rozhranie pre export/report (CSV/HTML súbory)
• Application Service: Podpora rozhodovania o údržbe, bezpečnosti a investíciách

Vzťah na externé prostredie:

• V tejto fáze projekt nemá integrácie na centrálne ISVS ani moduly eGov.
• Výstupy budú poskytované ako otvorené údaje (publikácia datasetov) a ako súbory pre rozhodovanie.
• Možný budúci rozvoj (napr. prepojenie na GIS systémy alebo centrálne platformy) nie je súčasťou projektu.

Obrázok 2  Model aplikačnej architektúry TO BE– príklad

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

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

Tabuľka 2 ISVS – as is

Obec v súčasnosti nemá ISVS na systematický zber a analýzu dát, využíva len web a spisovú službu, ktoré projekt nemení 

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

Tabuľka 3 Rozsah informačných systémov – to be

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

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

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

Projekt neplánuje priame integrácie na iné ISVS; externé prepojenia budú realizované len formou zverejňovania datasetov (NKOD/data.slovensko.sk) a odovzdávania analytických údajov MIRRI.

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

Tabuľka 4 Aplikačné služby pre realizáciu koncových služieb – TO BE

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

Tabuľka 5 Aplikačné služby na integráciu To BE

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

Projekt nepredpokladá poskytovanie údajov do IS CSRÚ. Údaje budú poskytované ako otvorené dáta prostredníctvom NKOD (data.slovensko.sk) a ako analytické súbory odovzdávané MIRRI podľa Prílohy č. 11 výzvy.

6.2.3 Konzumovanie údajov z IS CSRU – TO BE

Projekt nepredpokladá konzumáciu údajov z IS CSRÚ. Systém na zber a spracovanie dát využíva výlučne vlastné senzorické dáta obce.

7. Dátová vrstva

.

Projekt sa zameriava na zber a spracovanie lokálnych senzorických údajov. V súčasnosti obec nedisponuje systematickou dátovou architektúrou – údaje sú spracovávané ad-hoc (napr. excelovské tabuľky, manuálne počítania).
Budúci stav (TO BE) prinesie zavedenie základnej dátovej platformy s jasným životným cyklom dát: zber → validácia → uloženie → export → publikácia/odovzdanie.

7.1 Údaje v správe organizácie

AS-IS stav

• Obec nezbiera kontinuálne dáta, rozhodovanie sa opiera o jednorazové podklady (fotodokumentácia, odhady).

• Neexistuje evidencia objektov evidencie (OE) v štruktúrovanej podobe.

• Dátová správa je manuálna a nesystematická.

TO-BE stav

• Projektom sa zavedie jednoduchý systém manažmentu údajov so zameraním na senzorické dáta.

Objekty evidencie (OE):

• OE-01: Mobilita – počty chodcov, cyklistov, vozidiel v čase a priestore.

• OE-02: Vyťaženosť verejných priestranstiev (frekvencia využitia).

• OE-03: Prevádzkové údaje zo senzorov (napr. teplota, vlhkosť – ak budú k dispozícii).

Životný cyklus údajov:

• Zber: IoT senzory generujú anonymizované dáta.

• Validácia: kontrola úplnosti a formátu.

• Uloženie: lokálne úložisko časových rád.

• Export: CSV/HTML reporty pre vedenie, XML/CSV súbory pre analytické účely.

Publikácia/odovzdanie:

• otvorené dáta do NKOD (data.slovensko.sk),

• analytické súbory MIRRI podľa Prílohy č. 11.

• Procesy dátového manažmentu:

• Štandardizované pomenovanie datasetov,

• Periodická archivácia a zálohovanie,

• Publikovanie metadát podľa DCAT-AP-SK 2.0,

• Anonymizácia (iba agregované údaje, bez identifikácie osôb).

Organizačné zabezpečenie:

• Dátový kurátor = poverený pracovník obce (napr. referent IT/rozvoja).

• Úloha kurátora: dohľad nad kvalitou dát, správnosť publikovaných datasetov, komunikácia s MIRRI.

• Zavedenie základnej dokumentácie v CIMS (v súlade s vyhláškou 401/2023 Z.z.).  

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

Tabuľka 6 Dátový rozsah

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

Projekt nebude poskytovať ani konzumovať referenčné údaje prostredníctvom CSRÚ. Zberané údaje (mobilita, vyťaženosť verejných priestorov, prevádzkové údaje senzorov) nie sú súčasťou referenčných registrov a nie sú viazané na identifikáciu osôb.

• Právny predpis: nevzťahuje sa, keďže sa nepracuje s osobnými ani referenčnými údajmi.
• Konzumenti údajov: vedenie obce, odborné komisie, verejnosť (formou open data).

Tabuľka 7 Konzumovanie údajov

7.1.3.Kvalita a čistenie údajov

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

Tabuľka 8 Kvalita a čistenie údajov

  Najvyššia priorita je zabezpečiť kvalitu údajov o mobilite, pretože priamo ovplyvňuje rozhodovanie o dopravných opatreniach.

  Vyťaženosť verejných priestranstiev je dôležitá pre plánovanie údržby, preto má strednú prioritu.

  Prevádzkové údaje zo senzorov sú skôr doplnkové, preto nižšia priorita.

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

Tabuľka 9 Roly a personálne zabezpečenie

  V projekte sa počíta s kombináciou interných kapacít obce (dátový kurátor, IT podpora) a dodávateľa systému (špecialisti na databázy a kvalitu dát).

  Úlohy budú rozdelené tak, aby si obec vedela zabezpečiť dlhodobú udržateľnosť aj po skončení projektu.

Otvorené údaje

 Projekt bude sprístupňovať vybrané objekty evidencie ako otvorené údaje v súlade s požiadavkami DCAT-AP-SK 2.0 a zákona č. 95/2019 Z. z. Údaje budú publikované v kvalite 3★ (strojovo spracovateľné formáty CSV, XML, JSON) a registrované v NKOD (data.slovensko.sk).

Tabuľka 10  Otvorené údaje

Poznámky:

• Údaje budú anonymizované a agregované, aby nebolo možné identifikovať jednotlivcov.
• Metadáta datasetov budú evidované v MetaIS a v NKOD (min. názov, popis, periodicita, licencia CC-BY).
• Obec plánuje publikovať minimálne 2 dataset-y ročne s garanciou aktualizácie podľa stanovených periodicít.

Analytické údaje

Projekt vytvára agregované dátové súbory, ktoré budú slúžiť na analytické účely MIRRI podľa Prílohy č. 11 výzvy. Nejde o osobné ani referenčné údaje, všetky výstupy sú anonymizované.

Tabuľka 11  Analytické údaje

Poznámka:
Analytické údaje budú exportované v štruktúrovaných formátoch (CSV, XML) a odovzdávané v pravidelných intervaloch (napr. mesačne/štvrťročne) podľa požiadaviek výzvy.

Moje údaje

V rámci budovaného riešenia sa nepredpokladá spracovanie osobných údajov v rozsahu, ktorý by bol priamo poskytovaný občanom ako služba „Moje údaje“. Projekt je zameraný najmä na zber a agregáciu údajov zo senzorických zdrojov (napr. monitoring verejného priestranstva), pričom dáta sú spracované anonymizovane a nie je možné identifikovať konkrétne fyzické osoby.

• Moje údaje v zmysle metodiky sa teda netýkajú priamych výstupov tohto projektu.
• V prípade budúceho rozvoja sa však počíta s možnosťou rozšírenia funkcionality, aby boli údaje o využívaní verejného priestoru a rozhodovacích procesoch dostupné aj obyvateľom prostredníctvom e-služieb, a to formou otvorených a anonymizovaných dátových sád.

Tabuľka 12 Moje údaje

Prehľad jednotlivých kategórií údajov
Projekt generuje a sprístupňuje dáta predovšetkým v kategórii otvorených údajov a analytických údajov. Keďže ide o agregované a anonymizované dáta, v kategórii referenčné údaje a moje údaje zatiaľ neevidujeme priame objekty evidencie.

Tabuľka 13 Prehľad jednotlivých kategórií

8. Technologická vrstva

Technologická vrstva opisuje infraštruktúru potrebnú na prevádzku aplikačného komponentu „Systém na zber a spracovanie dát“. Projekt je koncipovaný minimalisticky, využíva existujúce prostredie obce doplnené o nový server, úložisko a sieťové prvky.

8.1 Prehľad technologického stavu - AS IS

  Obec v súčasnosti nemá dedikovanú infraštruktúru pre zber a spracovanie senzorických dát.

  Používané technológie:

• kancelárske počítače pre administratívu,
• webový server (CMS pre obecný web),
• základná LAN sieť a internetové pripojenie (optická sieť).

  Technologické problémy:

• chýba centrálne úložisko pre kontinuálny zber a archiváciu dát,
• neexistuje nástroj na integráciu IoT zariadení a analytických výstupov.

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

Tabuľka 14  Požiadavky na parametre

8.2 Návrh riešenia technologickej architektúry

Navrhované riešenie technologickej architektúry pre projekt Veľká Lomnica vychádza z princípu jednoduchosti, škálovateľnosti a udržateľnosti. Projekt sa nezameriava na rozsiahlu modernizáciu existujúcich ISVS, ale na vybudovanie samostatného aplikačného komponentu – Systém na zber a spracovanie dát, ktorý je možné v budúcnosti integrovať do širších platforiem.

1. Prístup k riešeniu technologickej architektúry

• Riešenie bude implementované ako samostatný modul obce, nasadený na bežnej serverovej infraštruktúre (lokálnej alebo v hostingovom prostredí).
• Systém je navrhnutý ako ľahko rozšíriteľný – do budúcnosti je možné jeho rozšírenie o integráciu na nadrezortné systémy a spoločné moduly ISVS.
• Preferovaný prístup je Cloud Native-ready – to znamená, že aplikácia môže byť v budúcnosti prenesená do vládneho cloudu alebo iných cloudových prostredí bez nutnosti rozsiahlych úprav.

1. Popis prostredia a požiadaviek

• Vývojové a testovacie prostredie: zabezpečené na lokálnej infraštruktúre alebo cez jednoduchý hosting.
• Produkčné prostredie: samostatný server alebo virtuálne prostredie s prístupom obmedzeným na oprávnených používateľov (vedenie obce, technické služby).
• Komunikačná infraštruktúra: využitie bežných protokolov (HTTPS, XML exporty), bez zložitých integračných brán.

1. Hlavné charakteristiky riešenia

• Nízka technologická náročnosť: projekt nepredpokladá vysoké výpočtové požiadavky.
• Bezpečnosť a ochrana údajov: dáta budú ukladané v anonymizovanej a agregovanej podobe, bez identifikácie osôb.
• Škálovateľnosť: možné rozšírenie na viac senzorických vstupov (napr. doplnenie o environmentálne senzory).
• Pripravenosť na budúce integrácie: v ďalších etapách je možné dopojiť sa na spoločné moduly ISVS alebo regionálne GIS platformy.

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

Projekt v aktuálnej fáze nevyužíva žiadne služby z katalógu vládneho cloudu. Nasadenie je zabezpečené lokálne, prostredníctvom vlastnej infraštruktúry obce. Riešenie je však koncipované ako Cloud Native-ready, čo umožňuje jeho budúcu migráciu do vládneho cloudu.

8.4  Bezpečnostná architektúra

AS IS stav

• Obec v súčasnosti nemá vybudovanú špecializovanú bezpečnostnú architektúru pre zber a spracovanie dát.
• Používa sa len základné zabezpečenie kancelárskych počítačov (antivírus, heslá, firewall na úrovni ISP).
• Neexistuje centrálna správa prístupov ani systémové logovanie prístupov k dátam.
• Údaje o rozhodovaní obce sú spracovávané prevažne manuálne, bezpečnostné riziká sú preto nízke, ale nie sú systematicky riadené.

TO BE stav

Projekt vytvorí základnú bezpečnostnú architektúru na úrovni:

• Dôvernosť: všetky údaje budú anonymizované, agregované a ukladané v šifrovanej podobe. Prenosy medzi senzormi a serverom budú zabezpečené pomocou štandardných šifrovaných protokolov (TLS).
• Integrita: výstupy budú generované automatizovane a elektronicky podpísané systémom, čím sa zabráni neoprávneným zmenám.
• Dostupnosť: server a úložisko budú prevádzkované v redundantnom režime s pravidelnými zálohami.

Alternatívy riešenia:

1. Lokálne nasadenie (zvolená alternatíva): server prevádzkovaný obcou, správa IT zabezpečená dodávateľom.
2. Cloudové nasadenie (rezerva do budúcna): systém pripravený na migráciu do vládneho cloudu, ak by bolo vyžadované vyššie SLA alebo integrácie na eGov komponenty.

Súlad s právnymi a technickými normami

Navrhovaná bezpečnostná architektúra bude v súlade s:

• Zákonom č. 95/2019 Z.z. o IT VS,
• Zákonom č. 69/2018 Z.z. o kybernetickej bezpečnosti,
• Zákonom č. 18/2018 Z.z. a nariadením GDPR,
• Vyhláškami č. 78/2020 Z.z. a č. 179/2020 Z.z. o štandardoch a bezpečnostných opatreniach IT VS,
• Vyhláškou č. 158/2018 Z.z. (posudzovanie vplyvu na OÚ).

Projekt bude realizovať Bezpečnostný projekt ISVS, ktorý stanoví podrobné opatrenia a kategorizáciu podľa vyhlášky č. 179/2020 Z.z.

Používateľské role a správa prístupov

• Interní používatelia:
  • Vedenie obce (iba čítanie výstupov),
  • Administrátori a IT podpora (údržba, správa aplikácie),
  • Technické služby (prístup k dátam relevantným pre operatívu).
• Externí používatelia:
  • Verejnosť a partneri majú prístup len k open data datasetom publikovaným na webe.
• Správa prístupov bude založená na princípe least privilege a bude kombinovať autentifikáciu (heslá, dvojfaktor) a autorizáciu (rolový model).

8.5 Závislosti na ostatné ISVS / projekty

Projekt je koncipovaný ako samostatné riešenie obce a nemá priamu závislosť na iných informačných systémoch verejnej správy (ISVS) ani na iných prebiehajúcich projektoch. Riešenie je realizované lokálne a nevyžaduje integráciu na externé ISVS.

Možné budúce závislosti (nad rámec tohto projektu):

• MetaIS – evidencia eGovernment komponentov a architektonických modelov (povinnosť podľa zákona č. 95/2019 Z. z.).
• Národný katalóg otvorených dát (data.gov.sk) – povinnosť publikovať vybrané výstupy projektu ako otvorené údaje.

Tabuľka 15  Závislosti

9. Zdrojové kódy

Projekt „Inteligentné IoT riešenia pre bezpečnosť a efektívnu správu verejných priestorov v obci Veľká Lomnica“ nepredstavuje vývoj nového informačného systému vo verejnej správe, ale nasadenie a konfiguráciu komerčne dostupných senzorických zariadení a jednoduchého systému na zber a spracovanie dát.

Požiadavky na zdrojové kódy

• Projekt nevyžaduje dodanie vlastných zdrojových kódov, keďže implementované komponenty pozostávajú zo štandardného hardvéru, softvéru na spracovanie dát a konfiguračných nástrojov.
• Všetky použité komponenty budú v súlade so zákonom č. 95/2019 Z. z. o IT VS a so štandardmi verejnej správy.
• V prípade, že dodávateľ použije vlastné skripty alebo moduly (napr. pre export dát do CSV/XML/HTML), tieto budú odovzdané obci v otvorenom formáte a s dokumentáciou.

Archívacia a odovzdanie

• Konfiguračné súbory a prípadné skripty budú odovzdané obci pri kolaudácii projektu ako súčasť prevádzkovej dokumentácie.
• Periodicita odovzdania: pri odovzdaní diela a následne pri aktualizáciách (ak budú realizované).
• Archívacia: Obec zabezpečí uchovávanie kódov a konfiguračných súborov v rámci svojej internej infraštruktúry (server + zálohovanie).

Vendor lock-in

• Projekt je navrhnutý tak, aby nevytváral vendor lock-in.
• Riešenie je Cloud Native-ready, ale v aktuálnej fáze beží lokálne a je možné ho v budúcnosti migrovať do vládneho cloudu alebo iného prostredia.
• Všetky použité komponenty musia byť zdokumentované a nahraditeľné ekvivalentnými riešeniami iných výrobcov.

Licencie

• V prípade softvérových modulov budú preferované open-source komponenty alebo riešenia s jasne definovanou licenciou.
• Dodávateľ je povinný zabezpečiť, aby licencie neobmedzovali budúce používanie a správu riešenia obcou.

10. Prevádzka a údržba

AS IS stav

• Obec v súčasnosti nemá zavedenú prevádzku špecializovaných IT riešení na zber a spracovanie dát.
• Prevádzkované sú len základné kancelárske IT prostriedky a webové sídlo obce, bez formálneho SLA.
• Údržba a správa sa rieši ad-hoc, zvyčajne externým dodávateľom.

TO BE stav

Projekt zavádza samostatný aplikačný komponent – systém na zber a spracovanie dát zo senzorických zariadení. Pre jeho prevádzku a údržbu bude zabezpečené:

• zmluvná SLA s dodávateľom na úrovni systémovej a aplikačnej podpory,
• pravidelné aktualizácie softvéru a bezpečnostných záplat,
• monitoring dostupnosti servera a úložiska,
• plán obnovy systému vrátane pravidelného zálohovania dát,
• ročný servisný kontrakt s možnosťou predĺženia.

• 
  
  1. Prevádzkové požiadavky
• L1 úroveň (základná podpora, helpdesk)
  • dostupnosť v pracovných dňoch 8:00 – 16:00,
  • reakčný čas: do 8 hodín,
  • riešenie bežných užívateľských otázok, kontrola exportov dát.
• L2 úroveň (pokročilá podpora, administrácia systému)
  • reakčný čas: do 4 hodín,
  • odstránenie incidentu: do 24 hodín,
  • aplikácia aktualizácií a bezpečnostných opráv, monitoring výkonu a kapacity.
• L3 úroveň (vývojové zásahy, eskalácia k dodávateľovi)
  • reakčný čas: do 2 hodín,
  • odstránenie kritickej poruchy: do 8 hodín,
  • úpravy konfigurácie, oprava chýb v exportných skriptoch.

Štandardy podpory a SLA

• Dostupnosť systému: min. 99 % počas roka.
• Zálohovanie: denne, uchovávanie dát min. 30 dní.
• Plán obnovy: max. výpadok 24 hodín.
• Servisné služby sa vzťahujú na produkčné aj testovacie prostredie.

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.

Úrovne podpory používateľov

Prevádzková podpora systému bude zabezpečená v troch úrovniach:

Podpora L1 (1. stupeň)

• Základná používateľská podpora, helpdesk.
• Rieši jednoduché problémy a otázky: prístup do systému, zabudnuté heslá, kontrola exportov dát.
• Zodpovednosť: pracovník obecného úradu alebo IT podpora.
• Reakčný čas: do 8 hodín počas pracovných dní.

Podpora L2 (2. stupeň)

• Technická podpora s hlbšou znalosťou systému a jeho konfigurácie.
• Rieši eskalované incidenty z L1: nefunkčné exporty, problémy so spracovaním dát, konfigurácia senzorov.
• Zodpovednosť: dodávateľ systému (servisný kontrakt).
• Reakčný čas: do 4 hodín, odstránenie incidentu do 24 hodín.

Podpora L3 (3. stupeň)

• Najvyššia úroveň podpory – vývojové a expertné zásahy.
• Rieši komplexné incidenty vyžadujúce zásah do aplikačného kódu alebo hardvérovej konfigurácie.
• Zodpovednosť: výrobca/dodávateľ senzorických zariadení alebo softvéru.
• Reakčný čas: do 2 hodín, odstránenie kritického incidentu do 8 hodín.

SLA parametre podpory

• Dostupnosť helpdesku (L1): pracovné dni 8:00 – 16:00, kontakt cez telefón a email.
• Dostupnosť L2 podpory: 8×5 (8 hodín denne, 5 dní v týždni).
• Dostupnosť L3 podpory: 8×5 s garantovaným zásahom do 8 hodín od nahlásenia kritickej poruchy.
• Incidenty budú evidované v systéme dodávateľa a vyhodnocované podľa dohodnutých SLA.

Riešenie incidentov – SLA parametre

Označenie naliehavosti incidentu

• A – Kritická: úplné zlyhanie systému alebo jeho časti, systém neposkytuje požadovaný výstup (napr. nefunguje spracovanie dát zo senzorov).
• B – Vysoká: čiastočné zlyhanie systému, ktoré bráni plnému využívaniu (napr. nefunkčný export do CSV/XML).
• C – Stredná: obmedzená funkčnosť, systém je použiteľný, ale s obmedzeniami (napr. výpadok jednej lokality).
• D – Nízka: kozmetické a drobné chyby (napr. vizuálna chyba reportu).

Možný dopad incidentu

• 1 – Katastrofický: úplná strata dát alebo úplná nefunkčnosť systému, zásadný dopad na činnosť obce.
• 2 – Značný: čiastočná strata dát alebo významné obmedzenie poskytovania výstupov.
• 3 – Malý: minimálny dopad, drobná strata dát alebo funkčnosti.

Označenie naliehavosti incidentu:

Tabuľka 16 Naliehavosť incidentu

možný dopad:

Tabuľka 17 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:

Tabuľka 18 Priorita incidentu

Vyžadované reakčné doby:

Tabuľka 19 Reakčné doby

Reakčné časy podľa priority

• Priorita 1 (A1 – kritická s katastrofickým dopadom):
  • Reakčná doba: 0,5 hodiny od nahlásenia incidentu.
  • Konečné vyriešenie: do 4 hodín.
  • Spoľahlivosť: max. 1 takýto incident za mesiac.
• Priorita 2 (A2, B1, C1):
  • Reakčná doba: 1 hodina.
  • Konečné vyriešenie: do 8 hodín.
• Priorita 3 (A3, B2, C2, D1):
  • Reakčná doba: 4 hodiny.
  • Konečné vyriešenie: do 24 hodín.
• Priorita 4 (B3, C3, D2, D3):
  • Reakčná doba: do 1 pracovného dňa.
  • Konečné vyriešenie: do 5 pracovných dní.

Zásady riešenia incidentov

• Incidenty sú evidované v systéme dodávateľa a priraďované podľa závažnosti.
• Kritické incidenty sa riešia okamžite s preferenciou obnovy základnej funkcionality.
• Po vyriešení je vždy vyhotovená správa o príčine, priebehu a prijatých opatreniach.
• Obec bude mať prístup k mesačným reportom o SLA plnení.

​​​​​​​ Požadovaná dostupnosť IS:

Tabuľka 20 Požadovaná dostupnosť

Dostupnosť (Availability)

V rámci projektu je definovaná požadovaná dostupnosť informačného systému (IS) pre obec Veľká Lomnica nasledovne:

Prevádzkové hodiny:

• 12 hodín denne, od 06:00 do 18:00 počas pracovných dní.

Servisné okno:

• 10 hodín denne, od 19:00 do 05:00 počas pracovných dní.
• 24 hodín denne (00:00 – 23:59) počas dní pracovného pokoja a štátnych sviatkov.
• Servis a údržba budú vykonávané mimo prevádzkového času, aby nedošlo k ovplyvneniu produkčného prostredia.

Dostupnosť produkčného prostredia IS:

• 98,5 % v režime 24/7/365, čo zodpovedá max. ročnému výpadku 66 hodín.
• Maximálny mesačný výpadok je 5,5 hodiny.
• Za takúto dobu sa považuje čas od 00:00 do 23:59 počas pracovných dní v týždni.
• Do výpočtu nedostupnosti sa nezapočítavajú plánované servisné okná a odstávky IS.
• V prípade nedodržania dostupnosti IS bude každý ďalší začatý pracovný deň nedostupnosti braný ako deň omeškania pri odstraňovaní vád alebo incidentov.

.

RTO (Recovery Time Objective)

Pre informačný systém obce Veľká Lomnica je stanovený ukazovateľ obnovy po výpadku nasledovne:

• Tradičné zálohovanie: výpadok a obnova môže trvať do 2 hodín.
• Asynchrónne replikácie dát: výpadok a obnova v rozsahu sekúnd až minút.
• Synchrónne replikácie dát: prakticky nulový výpadok.

Projekt bude realizovaný s cieľom minimalizovať RTO na úroveň do 30 minút pri štandardných incidentoch, pričom kritické incidenty budú riešené prioritne podľa SLA parametrov.

RPO (Recovery Point Objective)

Pre informačný systém obce Veľká Lomnica je stanovený ukazovateľ obnoviteľnosti dát nasledovne:

• Tradičné zálohovanie: strata dát max. za posledné 2 hodiny.
• Asynchrónne replikácie dát: strata dát v rozsahu niekoľkých minút.
• Synchrónne replikácie dát: nulová strata dát.

Projekt predpokladá RPO na úrovni maximálne 15 minút, čím sa zabezpečí minimálna strata informácií aj pri neočakávaných výpadkoch.

Požiadavky na personál

Projekt bude vyžadovať zapojenie kľúčových rolí, ktoré zabezpečia úspešnú realizáciu a následnú prevádzku systému:

• Projektový manažér – zodpovedný za riadenie projektu, harmonogram a komunikáciu s MIRRI a dodávateľmi.
• IT špecialista obce / správca IS – zabezpečenie technickej infraštruktúry, údržba systému, správa prístupov.
• Dátový kurátor – zodpovedný za kvalitu dát, správu údajov a ich správne sprístupňovanie podľa prílohy č. 11 výzvy.
• Dodávateľská podpora (externý partner) – inštalácia, konfigurácia, školenie a záručný/pozáručný servis.
• Užívatelia – pracovníci obce – vyškolení zamestnanci, ktorí budú systém využívať pre rozhodovanie a tvorbu reportov.

TO BE proces počíta s tým, že obec si udrží základné know-how interne, pričom odborné činnosti (údržba, servis, aktualizácie) budú zabezpečené dodávateľom formou SLA.

Implementácia a preberanie výstupov projektu

Realizácia projektu bude vedená metódou waterfall s prvkami agile, keďže ide o dodávku technológie, ktorá vyžaduje postupné fázy (analýza, inštalácia, testovanie, nasadenie). Agile princípy sa využijú pri konzultáciách s obcou a pri iteratívnom nastavovaní parametrov zberu dát.

Hlavné etapy implementácie:

1. Príprava a analýza – definovanie lokalít, technických parametrov a harmonogramu.
2. Implementácia – inštalácia senzorických zariadení, konfigurácia servera a aplikácie.
3. Testovanie – overenie funkčnosti senzorov, dátového toku a exportov do požadovaných formátov.
4. Nasadenie do produkcie – spustenie prevádzky systému v plnom rozsahu.
5. Školenie používateľov – pracovníci obce budú zaškolení na prácu so systémom a exportmi dát.
6. Odovzdanie výstupov – dodávateľ odovzdá všetky komponenty, dokumentáciu a nastaví SLA.

Výstupy projektu budú preberané formou čiastkových plnení, pričom každá etapa bude ukončená odovzdávacím protokolom. Hlavným míľnikom je odovzdanie funkčného systému vrátane dátových exportov v súlade s prílohou č. 11 výzvy.

Prílohy

• Bez príloh