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

2. ÚČEL DOKUMENTU

V súlade s Vyhláškou 401/2023 Z.z. je dokument I-03 Prístup k projektu určený na rozpracovanie detailných informácií prípravy projektu z pohľadu aktuálneho stavu, budúceho stavu a navrhovaného riešenia.

Dokument Prístup k projektu v zmysle vyššie uvedenej vyhlášky má obsahovať opis navrhovaného riešenia, architektúru riešenia projektu na úrovni biznis vrstvy, aplikačnej vrstvy, dátovej vrstvy, technologickej vrstvy, infraštruktúry navrhovaného riešenia, bezpečnostnej architektúry, špecifikáciu údajov spracovaných v projekte, čistenie údajov, prevádzku a údržbu výstupov projektu, prevádzkové požiadavky, požiadavky na zdrojové kódy. Dodávané riešenie musí byť v súlade so zákonom. Zároveň opisuje aj implementáciu projektu a preberanie výstupov projektu.

2.1 Použité skratky a pojmy

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

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

Z pohľadu biznis architektúry dochádza k zvýšeniu užívateľskej prívetivosti vybraných koncových služieb Mesta Trnava implementáciou jednoduchšieho vypĺňania formulárov. Zavedením nových elektronických služieb, ktoré boli doteraz sprístupnená len offline, resp. formou všeobecného podania prostredníctvom ÚPVS/slovensko.sk dôjde k zvýšeniu komfortu pre občanov a rovnako k zníženiu časovej náročnosti spracovania zo strany príslušných úradníkov mesta.

Z pohľadu aplikačnej architektúry dochádza k nasledovným zmenám v rámci komponentov architektúry.

Projekt nadväzuje na realizovaný projekt „Malé zlepšenia eGOV služieb v Meste Trnava (ITMS kód: 311071CDS3)“ v rámci ktorého sa ukázala potreba, mať pre potreby elektronických služieb k dispozícii jednoznačné referenčné dáta, ktoré vzniknú agregáciou a transformáciou zo všetkých dostupných zdrojov dát. Túto funkciu v navrhovanom riešení by mala zastrešiť Integračná platforma eGOV služieb v kombinácií s funkčným Centrálnym dátovým skladom. Realizácia obsahu jednotlivých elektronických služieb si primárne vyžaduje dáta z agendového back-office systému mesta a preto je potrebné v prvom rade zadefinovať výmenné štruktúry a služieb medzi Centrálnym dátovým skladom a agendovým back-office mesta Trnava. Túto funkciu v projekte zastreší Dátový konektor agendového IS.

Realizáciou predchádzajúceho projektu „Malé zlepšenia eGOV služieb v Meste Trnava“ došlo mesto k záveru, že používateľská skúsenosť sa v čase výrazne mení, čo má hlavne s ohľadom na vzhľad, rozloženie prvkov ako aj logickú následnosť krokov podania, vplyv na vzhľad elektronického formulára. Zmenu formulára, povýšenie jeho verzie, je následne nutnú riešiť dodávateľsky, čo  predlžuje čas implementácie  používateľských poznatkov do praxe. Z tohto dôvodu by mesto chcelo disponovať nástrojom, ktorým dokáže elektronické formuláre vytvárať resp. modifikovať, čo by následne prispelo aj k rýchlejšiemu zavádzaniu ďalších elektronických služieb.

Zhrnutie / výsledok:

Výber alternatív prebiehal aplikovaním kritérií multikriteriálnej analýzy (ďalej aj „MCA“). V rámci MCA bola vybratá alternatíva 3, ktorá splnila všetky 4 zadefinované kritériá.

Preferovaný variant predstavuje plnohodnotnú realizáciu projektu v zmysle požiadaviek vyplývajúcich z realizovaného „prieskumu spokojnosti s poskytovanými elektronickými službami mesta Trnava“, to zn. implementácia nových elektronických služieb (viď. Tab. č.1 Komplexný zoznam elektronických služieb a kap. 4.1.1. Prehľad koncových služieb - budúci stav), resp. zvýšenie ich sofistikovanosti.

Rovnako v rámci projektu dôjde k zavedeniu jednoznačnej referenčnosti údajov prostredníctvom Integračnej platformy eGov služieb v kombinácii s funkčným Centrálnym dátovým skladom. Mesto bude disponovať nástrojom, ktorým by dokázalo elektronické formuláre vytvárať, resp. modifikovať aj vo vlastnej réžii, čo by malo za následok rýchlejšie zavádzanie elektronických služieb a ich jednotlivých zmien.

4. ARCHITEKTÚRA RIEŠENIA PROJEKTU

4.1 Biznis vrstva

Projekt sa týka nasledovných agend, resp. biznis procesov:

A0000224          Rozhodovanie vo veciach miestnych daní, miestnych poplatkov, verejnej dávky, prijatia úveru alebo pôžičky a vykonávanie ich správy

A0002777          Organizačné zabezpečenie volieb

A0001856          Tvorba komunitného plánu sociálnych služieb

A0000433          Schvaľovanie a ukladanie zmien cestovného poriadku

A0001220          Spolupráca s okresným dopravným inšpektorátom vo veciach bezpečnosti a plynulosti cestnej premávky

A0000445          Zabezpečovanie výstavby, údržby a výkonu správy miestnych komunikácií

A0000224          Rozhodovanie vo veciach miestnych daní, miestnych poplatkov, verejnej dávky, prijatia úveru alebo pôžičky a vykonávanie ich správy

A0002237          Poskytovanie držiteľovi odpadu informácie o umiestnení a činnosti zariadení na nakladanie s odpadmi na území obce

A0003114          Hospodárenie a nakladanie s vlastným majetkom a s vlastnými príjmami

A0003114          Hospodárenie a nakladanie s vlastným majetkom a s vlastnými príjmami

A0003114          Hospodárenie a nakladanie s vlastným majetkom a s vlastnými príjmami

A0001938          Vykonávanie poradenstva pri zabezpečení základných životných podmienok a pomoci v hmotnej núdzi

A0002082          Riadenie, vykonávanie a kontrola výkonu štátnej správy starostlivosti o životné prostredie

A0002082          Riadenie, vykonávanie a kontrola výkonu štátnej správy starostlivosti o životné prostredie

A0000048          Utváranie podmienok na zásobovanie obce, určovanie pravidiel času predaja v obchode, času prevádzky služieb a spravovanie trhovísk

A0001453          Zvolávanie verejného zhromaždenia občanov

Obr. č.1 Biznis architektúra

Predmetom projektu je okrem iného príspevok k nasledovným prioritným životným situáciám:

ŽS2 Kúpa a vlastníctvo nehnuteľnosti na bývanie

ŽS3 Začatie podnikania 

ZS4 Kúpa a vlastníctvo motorového vozidla

ŽS5 Administratívny chod podniku

ŽS6 Presťahovanie

ŽS9 Som odkázaný, mám odkázaného člena rodiny

Podrobný popis koncových služieb, priradenie služieb k prioritným životným situáciám a agendám a rovnako popis aktuálneho a očakávaného stavu služieb je uvedený v nasledovnej tabuľke:

Tabuľka. č.1 Komplexný prehľad koncových služieb, ktoré sú predmetom projektu

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

Jazyková podpora a lokalizácia

Jazyková podpora a lokalizácia bude v slovenskom jazyku.

4.2 Aplikačná vrstva

Aplikačná architektúra – súčasný stav:

Obr. č.2 Aplikačná architektúra – súčasný stav

Front end mesta

Web aplikácia data.mesta je základným komponentom front-office vrstvy riešenia elektronických služieb a predstavuje používateľské rozhranie pre verejnosť a implementované elektronické služby.

Integračná vrstva

Integračná vrstva / modul napojenia na externé IS slúži ako komunikačná infraštruktúra medzi informačnými systémamimesta a externými systémami (napr. moduly ÚPVS). Modul zabezpečuje logické riešenie pre

integráciu systémov (ich vzájomné prepojenie) a procesné spracovanie správ (smerovanie, zasielanie

a prijímanie).

Back office

Predstavuje agendové systémy mesta, ktorý tvoria najmä Informačný systém mesta Trnava, Registratúrny systém mesta Trnava a Geografický systém mesta Trnava.

Aplikačná architektúra – budúci stav

Obr. č.3 Aplikačná architektúra – budúci stav

ORCHESTRAČNÁ PLATFORMA MESTA

Integračná zbernica služieb (Enterprise Service Bus, ESB) bude samostatným modulom Informačného systému elektronických služieb. Bude hlavnou komunikačnou platformou jednotlivých modulov riešenia a integrovaných interných a externých systémov. ESB bude spĺňať minimálne nasledovné požiadavky:

1. Podpora rôznych komunikačných protokolov

• Platforma musí podporovať široké spektrum protokolov ako napr. SOAP, REST, JMS, FTP, HTTP(S), AMQP, atď., aby umožnila komunikáciu medzi rôznorodými systémami a aplikáciami.

2. Flexibilná a škálovateľná architektúra

• Platforma musí byť škálovateľná, aby zvládala narastajúce požiadavky na výkonnosť a množstvo integrácií bez akýchkoľvek výkonnostných obmedzení. Musí tiež umožniť horizontálne aj vertikálne škálovanie podľa potrieb mesta.

3. Podpora orchestrácie a choreografie služieb

• Platforma musí podporovať rôzne spôsoby integrácie služieb vrátane orchestrácie (centrálna kontrola nad komunikáciou medzi službami) a choreografie (decentralizovaná komunikácia medzi nezávislými službami).

4. Centralizovaná správa a monitorovanie

• Platforma musí umožňovať centralizovanú správu všetkých integrácií, vrátane monitorovania výkonu, záznamu udalostí, chybovej diagnostiky a podrobnejšieho logovania.

5. Bezpečnosť a kontrola prístupu

• Platforma musí poskytovať robustné bezpečnostné mechanizmy, vrátane šifrovania, autentifikácie, autorizácie a podpory bezpečnostných štandardov ako OAuth, JWT, SAML, SSL/TLS na ochranu citlivých údajov.

6. Podpora transformačných nástrojov

• Platforma musí poskytovať nástroje na transformáciu dátových formátov medzi rôznymi systémami (napr. z XML na JSON, CSV, atď.), aby zabezpečila interoperabilitu medzi rôznymi modulmi a informačnými systémami.

7. Asynchrónna komunikácia a spracovanie správ

• ESB musí podporovať asynchrónne spracovanie a odosielanie správ t.j. okamžitá odpoveď nie je nevyhnutná, alebo kde môže dôjsť k zdržaniu v spracovaní.

8. Podpora pre rozširovateľnosť a prispôsobiteľnosť

• Platforma by mala byť dostatočne modulárna, aby umožnila prispôsobenie a rozšírenie podľa konkrétnych potrieb mesta, vrátane možnosti integrácie vlastných konektorov alebo rozhraní.

9. Zabezpečenie vysokej dostupnosti a zotavenia po poruche (high availability & failover)

• Platforma musí zabezpečiť nepretržitú dostupnosť služieb aj v prípade porúch jednotlivých komponentov, s podporou funkcionalít ako automatický failover, clustering a záložné systémy.

10. Kompatibilita s rôznymi technológiami a systémami

• ESB musí byť schopná integrácie s rôznymi platformami a technológiami vrátane cloudových služieb, lokálnych systémov, databáz, ERP systémov a pod. Okrem toho by musí umožňovať jednoduché nasadenie do hybridných prostredí (cloud a on-premise).

V rámci realizácie predmetu zákazky zabezpečí integračná platforma minimálne:

• Komunikáciu všetkých modulov realizovaných v rámci predmetu zákazky
• Publikovanie otvorených údajov a analytických služieb smerom do verejného prostredia
• Vybudovanie integračného rozhrania pre externé systémy, ktoré poskytujú referenčné údaje štátu, primárne CSRÚ, IS CISMA, ESKN a iné, ktoré budú identifikované v rámci realizačnej fázy analýza a dizajn, nevyhnutné pre realizáciu projektu
• Vybudovanie integračného rozhrania pre interné systémy obsahujúce referenčné objekty mesta

Podrobný rozsah služieb integračnej platformy bude definovaný v rámci realizačnej fázy analýza a dizajn.

CENTRÁLNY DÁTOVÝ SKLAD

Centrálny dátový sklad bude samostatný modul Informačného systému elektronických služieb mesta Trnava, ktorý bude zabezpečovať správu a distribúciu údajov o referenčných objektoch evidencie mesta Trnava. Za referenčný objekt evidencie bude považovaný každý objekt evidencie, ktorý je informačnými systémami mesta Trnava využívaný na realizovanie viac ako jednej agendy.

Centrálny dátový sklad bude obsahovať kompletný dátový model o uložení údajov a väzieb všetkých objektov evidencie.

Všetky existujúce informačné systémy mesta budú prispievať dátami do tohto dátového skladu. Platí to aj pre zhromažďovanie dát z rôznych implementovaných IoT snímačov, či kamerových systémov. Nad takýmito agregovanými a referencovateľnými dátami budú prebiehať ďalšie operácie IS mesta s nimi. Platí teda, že do elektronického formulára konkrétnej koncovej služby bude použitý referenčný údaj z dátového skladu, ktorý zohľadňuje stav v centrálnych referenčných registroch, pričom pre ich získanie sú využívané už existujúce integračné komponenty. 

Centralizovaná správa dát bude prebiehať prostredníctvom integračnej zbernice, ktorá zabezpečí prostredníctvom služieb komunikáciu jednotlivých informačných systémov a modulov prevádzkovaných na úrovni mesta Trnava.

Centrálny dátový skład bude obsahovať funkcionalitu „Data Handler“, ktorá bude zabezpečovať overovanie a autorizáciu dát. V prípade, že budú o tom istom objekte evidencie v rôznych informačných systémoch evidované rôzne hodnoty toho istého atribútu (napríklad adresa bydliska), data hanlder na základe stanovených pravidiel vyhodnotí, ktorú hodnotu bude považovať za pravdivú a referenčnú do doby, kým nebude preukázaný opak. O možnom konflikte údajov musí notifikovať zodpovedný informačný systém. Údaje považované za pravdivé budú mať v centrálnom dátovom sklade príznak „referenčné“ pra daný objekt evidencie. Všeobecný princíp činnosti data handlera je uvedený na nasledovnom obrázku:

Obr. č.4 Princíp činnosti data handlera

Data handler bude zodpovedný za to, že pri pravidelných aktualizáciách centrálneho dátového skladu bude zabezpečená konzistencia dát a nedôjde k znehodnoteniu referenčných údajov nepravdivými alebo neoverenými údajmi. Pravidlá priority údajov budú definované v realizačnej fáze Analýza a dizajn.

DÁTOVÝ KONEKTOR PRE SPOJENIE S INFORMAČNÝM SYSTÉMOM SAMOSPRÁVY

Dátový konektor pre spojenie s Informačným systémom samosprávy predstavuje samostatný informačný systém/rozšírenie existujúce IS samosprávy, ktorého úlohou bude migrácia údajov o všetkých objektoch a relevantných atribútoch informačného systému samosprávy do centralizovaného dátového skladu.

Súčasťou realizácie predmetu zákazky bude dodanie nasledovných funkčností/elementov:

• Dokumentácia dátového modelu ISS pre objekty evidencie, ktoré sú predmetom migrácie do centrálneho dátového skladu
• Iniciačná migrácia údajov o objektoch evidencie
• Zabezpečovanie pravidelnej aktualizácie údajov o objektoch evidencie vedených v centrálnom dátovom sklade na báze 24 hodín (mimo pracovného času) z databázy ISS
• Zabezpečovanie „on demand“ aktualizácie údajov o objektoch evidencie v centrálnom dátovom sklade potrebných pre realizáciu príslušnej služby na základe volania používateľa

Predmetom migrácie do centrálneho dátového skladu budú údaje o minimálne nasledovných objektoch evidencie mesta Trnava.

Finálny rozsah migrácie bude stanovený v realizačnej etape Analýza a dizajn.

Dizajnér elektronických formulárov

Táto samostatná aplikácia umožní plnohodnotné vytvorenie elektronického formulára, nadefinovaním jeho jednotlivých prvkov podľa jednotného dizajnmanuálu ID-SK v3 s možnosťou ich prepojenia s dátovým zdrojom.

Aplikácia po vytvorení návrhu formulára vygeneruje registračný balíček so všetkými povinnými transformáciami pre registráciu elektronického formulára v centrálnom úložisku formulárov ÚPVS.

Aplikácia umožní vytvorenie novej verzie formulárov modifikáciou predchádzajúcej verzie zapracovaním ľubovoľných úprav.

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

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

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

Predmetom projektu nie sú integrácie na nadrezortné ISVS.

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

Predmetom projektu nie sú integrácie na iné / externé ISVS.

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

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

Predmetom projektu nie je integrácia aplikačných služieb.

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

Predmetom projektu nie je poskytovanie údajov do IS CSRÚ.

Konzumovanie údajov z IS CSRU – TO BE

Predmetom projektu nie je konzumovanie  údajov z IS CSRÚ.

4.3 Dátová vrstva

Údaje v správe organizácie z pohľadu predkladaného projektu

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

Referenčné údaje

Projekt nebude vytvárať ani poskytovať referenčné údaje.

Kvalita a čistenie údajov

Predmetom projektu nie je čistenie údajov.

Otvorené údaje

Predmetom projektu nie je poskytovanie otvorených údajov.

Analytické údaje

Predmetom projektu nie je poskytovanie analytických údajov verejnosti.

Moje údaje

Predmetom projektu nie je poskytovanie „mojich údajov“.

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

N/A

4.4 Technologická vrstva

Prehľad technologického stavu - AS IS

Riešenie projektu bude prevádzkované na existujúcej infraštruktúre mesta Trnava.

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

Návrh riešenia technologickej architektúry

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

V rámci projektu sa nepredpokladá využívanie služieb vládneho cloudu.

4.5 Bezpečnostná architektúra

Základnými východiskami pre rozvíjané riešenie bezpečnosti IS sú rovnako ako v súčasnom stave právne predpisy ako zákon č. 18/2018 Z.z. o ochrane osobných údajov, 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.

Povinnosťou bude preukázať súlad so zákonom č. 95/2019 zákona o informačných technológiách vo verejnej správe a o zmene a doplnení niektorých zákonov. Pre úspešnú realizáciu projektu je potrebné zabezpečiť dodržanie pravidiel stanovených Vyhláškou č. 78/2020 (resp. jej novelizácii) Z. z. o štandardoch pre informačné technológie verejnej správy. Z hľadiska ochrany osobných údajov bude dátový manažment realizovaný v súlade so zákonom č. 18/2018 Z.z. o ochrane osobných údajov a o zmene a doplnení niektorých zákonov. Implementácia a prevádzka systému musí v oblasti bezpečnosti brať do úvahy aj Zákon 69/2018 Z. z. o kybernetickej bezpečnosti, v znení neskorších predpisov. Bude vypracovaný bezpečnostný projekt rešpektujúci tieto pravidlá.

Bezpečnostná architektúra budúceho stavu bude v súlade 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 a o zmene a doplnení niektorých zákonov
• zákon č. 69/2018 Z.z. o kybernetickej bezpečnosti a o zmene a doplnení niektorých zákonov
• 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.
• smernica Európskeho parlamentu a Rady (EÚ) (EÚ) 2022/2555 zo 14. decembra 2022 o opatreniach na zabezpečenie vysokej spoločnej úrovne kybernetickej bezpečnosti v Únii, ktorou sa mení nariadenie (EÚ) č. 910/2014 a smernica (EÚ) 2018/1972 a zrušuje smernica (EÚ) 2016/1148 (smernica NIS 2)
• zákon č. 69/2018 Z. z. o kybernetickej bezpečnosti a o zmene a doplnení niektorých zákonov v znení neskorších predpisov (ďalej aj „zákon o kybernetickej bezpečnosti“),
• vyhláška Národného bezpečnostného úradu č. 164/2018 Z. z., ktorou sa určujú identifikačné kritériá prevádzkovanej služby (kritériá základnej služby),
• vyhláška Národného bezpečnostného úradu č. 165/2018 Z. z., ktorou sa určujú identifikačné kritériá pre jednotlivé kategórie závažných kybernetických bezpečnostných incidentov a podrobnosti hlásenia kybernetických bezpečnostných incidentov,
• vyhláška Národného bezpečnostného úradu č. 264/2023 Z. z. ktorou sa mení a dopĺňa vyhláška Národného bezpečnostného úradu č. 362/2018 Z. z., ktorou sa ustanovuje obsah bezpečnostných opatrení, obsah a štruktúra bezpečnostnej dokumentácie a rozsah všeobecných bezpečnostných opatrení,
• vyhláška Národného bezpečnostného úradu č. 493/2022 Z. z. o audite kybernetickej bezpečnosti,
• zákon č. 301/2023 Z. z. ktorým sa mení a dopĺňa zákon č. 95/2019 Z. z. o informačných technológiách vo verejnej správe a o zmene a doplnení niektorých zákonov v znení neskorších predpisov a ktorým sa menia a dopĺňajú niektoré zákony,
• 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, ktorou sa ustanovuje spôsob kategorizácie a obsah bezpečnostných opatrení informačných technológií verejnej správy,
• 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) – GDPR,
• zákon č. 18/2018 Z. z. o ochrane osobných údajov a o zmene a doplnení niektorých zákonov v znení neskorších predpisov,
• Metodika analýzy rizík kybernetickej bezpečnosti - Metodika analýzy rizík pre uplatnenie v procesoch riadenia rizika v zmysle požiadaviek zákona č. 69/2018 Z. z. o kybernetickej bezpečnosti (NBÚ)

5. ZÁVISLOSTI NA OSTATNÉ ISVS / PROJEKTY

Predkladaný projekt nie je závislý na iných pripravovaných resp. prebiehajúcich projektoch.

6. ZDROJOVÉ KÓDY

Súčasťou dodávky budú aj zdrojové kódy k vytvorenému riešeniu, pokiaľ to nevylučujú licenčné podmienky tretích osôb vo vzťahu k štandardným Softvérovým produktom, s komentármi a technickým popisom, a to pre prevádzkové a testovacie verzie počítačových programov, a práva na ich zverejnenie v centrálnom repozitári zdrojových kódov podľa § 15 ods. 2 písm. d) Zákona o informačných technológiách vo verejnej správe a § 31 vyhlášky Úradu podpredsedu vlády Slovenskej republiky pre investície a informatizáciu o štandardoch pre informačné technológie verejnej správy č. 78/2020 Z. z., a iného predpisu, ktorý môže v budúcnosti vyhlášku č. 78/2020 Z. z. nahradiť alebo doplniť.

ŠÚKL plánuje pri obstarávaní postupovať v zmysle vzoru Zmluvy o dielo. Zmluvnú úpravu predkladáme nasledujúcu:

• Zhotoviteľ je povinný pri akceptácii Informačného systému odovzdať Objednávateľovi funkčné vývojové a produkčné prostredie, ktoré je súčasťou Informačného systému.
• Zhotoviteľ je povinný pri akceptácii Informačného systému alebo jeho časti odovzdať Objednávateľovi Vytvorený zdrojový kód v jeho úplnej aktuálnej podobe, zapečatený, na neprepisovateľnom technickom nosiči dát s označením časti a verzie Informačného systému, ktorej sa týka. Za odovzdanie Vytvoreného zdrojového kódu Objednávateľovi sa na účely tejto Zmluvy o dielo rozumie odovzdanie technického nosiča dát Oprávnenej osobe Objednávateľa. O odovzdaní a prevzatí technického nosiča dát bude oboma Zmluvnými stranami spísaný a podpísaný preberací protokol.
• Informačný systém (Dielo) v súlade s Technickou špecifikáciou obsahuje od zvyšku Diela oddeliteľný modul (časť) vytvorený Zhotoviteľom pri plnení tejto Zmluvy o dielo, ktorý je bez úpravy použiteľný aj tretími osobami, aj na iné alebo podobné účely, ako je účel vyplývajúci z tejto Zmluvy o dielo (ďalej ako „Modul"). A to najmä pre modul Karta občana. Vytvorený zdrojový kód Informačného systému (s výnimkou Modulu) vrátane jeho dokumentácie bude prístupný v režime podľa § 31 ods. 4 písm. b) Vyhlášky č. 78/2020 (s obmedzenou dostupnosťou pre orgán vedenia a orgány riadenia v zmysle Zákona o ITVS – vytvorený zdrojový kód je dostupný len pre orgán vedenia a orgány riadenia). Pre zamedzenie pochybností uvádzame, že sa jedná len o zdrojový kód ktorý Dodávateľ vytvoril, alebo pozmenil v súvislosti s realizáciou diela. Objednávateľ je oprávnený sprístupniť Vytvorený zdrojový kód okrem orgánov podľa predchádzajúcej vety aj tretím osobám, ale len na špecifický účel, na základe riadne uzatvorenej písomnej zmluvy o mlčanlivosti a ochrane dôverných informácií.
• Ak je medzi zmluvnými stranami uzatvorená SLA zmluva, od prevzatia Informačného systému sa prístup k vytvorenému zdrojovému kódu vo vývojovom a produkčnom prostredí, vrátane nakladania s týmto zdrojovým kódom, začne riadiť podmienkami dohodnutými v SLA zmluve.
• Vytvorený zdrojový kód musí byť v podobe, ktorá zaručuje možnosť overenia, že je kompletný a v správnej verzii, t. j. v takej, ktorá umožňuje kompiláciu, inštaláciu, spustenie a overenie funkcionality, a to vrátane kompletnej dokumentácie zdrojového kódu (napr. interfejsov a pod.) takejto Informačného systému alebo jeho časti. Zároveň odovzdaný Vytvorený zdrojový kód musí byť pokrytý testami (aspoň na 90%) a dosahovať rating kvality (statická analýza kódu) podľa CodeClimate/CodeQLa pod. (minimálne stupňa B).
• Pre zamedzenie pochybností, povinnosti Zhotoviteľa týkajúce sa Vytvoreného zdrojového kódu platí i na akékoľvek opravy, zmeny, doplnenia, upgrade alebo update Vytvoreného zdrojového kódu a/alebo vyššie uvedenej dokumentácie, ku ktorým dôjde pri plnení tejto Zmluvy o dielo alebo v rámci záručných opráv. Vytvorené zdrojové kódy budú vytvorené vyexportovaním z produkčného prostredia a budú odovzdané Objednávateľovi na elektronickom médiu v zapečatenom obale. Zhotoviteľ je povinný umožniť Objednávateľovi pri odovzdávaní Vytvoreného zdrojového kódu, pred zapečatením obalu, skontrolovať v priestoroch Objednávateľa prítomnosť Vytvoreného zdrojového kódu na odovzdávanom elektronickom médiu.
• Nebezpečenstvo poškodenia zdrojových kódov prechádza na Objednávateľa momentom prevzatia Informačného systému alebo jeho časti, pričom Objednávateľ sa zaväzuje uložiť zdrojové kódy takým spôsobom, aby zamedzil akémukoľvek neoprávnenému prístupu tretej osoby. Momentom platnosti SLA zmluvy umožní Objednávateľ poskytovateľovi, za predpokladu, že to je nevyhnutné, prístup k Vytvorenému zdrojovému kódu výlučne na účely plnenia povinností z uzatvorenej SLA zmluvy.

Ďalej uvádzame postupy, v zmysle ktorých bude narábané so zdrojovým kódom.

• Centrálny repozitár zdrojových kódov: https://www.zakonypreludi.sk/zz/2020-78/znenie-20200501#p31+
• Overenie zdrojového kódu s cieľom jeho prepoužitia: https://www.zakonypreludi.sk/zz/2020-85/znenie-20200501#p7-3-c+
• Spôsoby zverejňovania zdrojového kódu: https://www.zakonypreludi.sk/zz/2020-85/znenie-20200501#p8-9+
• Inštrukcie k EUPL licenciám: https://joinup.ec.europa.eu/sites/default/files/inline-files/EUPL%201_1%20Guidelines%20SK%20Joinup.pdf+

Uvedeným spôsobom obstarávania dôjde k zamedzeniu „Vendor lock-in" v súlade so Zákonom o ITVS.

7. PREVÁDZKA A ÚDRŽBA

Prevádzka a údržba navrhnutého riešenia projektu bude zabezpečená internými personálnymi kapacitami na úrovni podpory L1 až L3 (L3 externe). Pre hlásenie problémov bude využívaný Helpdesk. Predpoklad riešenia problémov a požiadaviek bude od nahlásenia problému alebo požiadavky prostredníctvom helpdesku (e-mailom, telefonicky, formulárom), identifikácia a preverenie problému/požiadavky, vykonanie opravy/podpory.

7.1 Prevádzkové požiadavky

Prevádzkové požiadavky budú zabezpečené na úrovni podpory L1, L2 a L3.

Úrovne podpory používateľov

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

• L1 podpora - 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ď.
• L2 podpora - 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.
• L3 podpora - Podpora 3. stupňa predstavuje najvyššiu úroveň podpory pre riešenie tých najobťažnejších hlásení, vrátane prevádzania hĺbkových analýz a riešenie extrémnych prípadov, ktorú bude zabezpečovať výrobca implementovaných nástrojov.

Prevádzka implementovaných nástrojov v rámci projektu L1 až L3 bude zabezpečená internými zamestnancami ŠÚKL. V prípade nevyhnutnej potreby bude zabezpečená L3 podpora výrobcu implementovaných nástrojov, ktorá bude financovaná z vlastných zdrojov ŠÚKL.

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:

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

7.2 Požadovaná dostupnosť IS:

Dostupnosť (Availability)

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. V projekte sa uvažuje 97% dostupnosť znamená výpadok 10,95 dňa.

RTO (Recovery Time Objective)

V rámci projektu sa očakáva tradičné zálohovanie - výpadok a obnova trvá cca hodiny až dni.

RPO (Recovery Point Objective)

V rámci projektu sa očakáva tradičné zálohovanie - výpadok a obnova trvá cca hodiny až dni.

8. POŽIADAVKY NA PERSONÁL

Riadiaci výbor projektu tvorí predseda riadiaceho výboru projektu a vlastníci procesov alebo nimi poverení zástupcovia.

Riadiaci výbor sa riadi “Štatútom riadiaceho výboru”, ktorý je popísaný v dokumente Štatút RV projektu ako najvyšší riadiaci orgán na účely realizácie projektu na základe schválenej projektovej dokumentácie.

Štatút Riadiaceho výboru upravuje najmä jeho pôsobnosť, úlohy, zloženie, zasadnutie a hlasovanie. Členom riadiaceho výboru projektu môže byť aj zástupca dodávateľa. Väčšina členov riadiaceho výboru projektu s hlasovacím právom sú osoby navrhnuté objednávateľom a zastupujú záujmy objednávateľa. Riadiaci výbor projektu dozerá na hospodárnosť, efektívnosť a účelové využívanie finančných prostriedkov a môže prispôsobiť štandardy projektového riadenia na realizovaný projekt.

Riadiaci výbor má minimálne 5 členov, vrátane predsedu Riadiaceho výboru (ďalej len „predseda“) :

Riadiaci výbor projektu budú tvoriť:

1. 
   
   1. predseda Riadiaceho výboru projektu,
   2. podpredseda Riadiaceho výboru projektu,
   3. vlastník alebo vlastníci procesov (biznis vlastník infraštruktúra) alebo nimi poverený zástupca alebo zástupcovia,
   4. zástupcu kľúčových používateľov (end user),
   5. zástupca za Dodávateľa v zmysle Zmluvy o Dielo s Dodávateľom.
   6. projektový manažér prijímateľa.

Riadiaci výbor je riadený predsedom, ktorým je zástupca Objednávateľa. V prípade neprítomnosti predsedu na zasadnutí Riadiaceho výboru, predseda musí na toto konkrétne zasadnutie písomne delegovať svoju funkciu v rozsahu svojich práv a povinností formou splnomocnenia na zástupcu, ktorým môže byť aj iný člen Riadiaceho výboru s hlasovacím právom. Na rokovanie Riadiaceho výboru môžu byť v prípade potreby prizvaní aj iní účastníci tak zo strany Objednávateľa alebo za stranu Dodávateľa.

Riadiaci výbor zasadá pravidelne, spravidla raz za mesiac avšak najmenej jedenkrát za tri (3) po sebe nasledujúce kalendárne mesiace. Zasadnutie Riadiaceho výboru zvoláva predseda. Závery zo zasadnutia Riadiaceho výboru a jednotlivé body zo zasadnutia Riadiaceho výboru sa prijímajú súhlasným hlasovaním nadpolovičnej väčšiny prítomných členov Riadiaceho výboru s hlasovacím právom. Hlas predsedu má v prípade rovnosti hlasov hodnotu dvoch hlasov.

Hlavné dokumenty spojené s činnosťou Riadiaceho výboru sú program zasadnutia, pracovný materiál a záznam zo zasadnutia Riadiaceho výboru, ktorého prílohou musí byť aj prezenčná listina, prípadne aj písomné splnomocnenia členov Riadiaceho výboru.

Program zasadnutia a pracovné materiály Riadiaceho výboru distribuuje Asistent projektového manažéra na základe podkladov a inštrukcií predsedu alebo toho člena Riadiaceho výboru, ktorý požiadal o zasadnutie Riadiaceho výboru.

Asistent projektového manažéra zabezpečí ich distribúciu členom Riadiaceho výboru najneskôr 3 pracovné dni pred zasadnutím Riadiaceho výboru. Za vecnú správnosť distribuovaného materiálu zodpovedá člen Riadiaceho výboru, ktorý ho predkladá.

Riadiaci výbor zaniká ukončením plnohodnotnej implementácie projektu a jeho uvedením do produktívnej prevádzky. Zoznam členov Riadiaceho výboru je súčasťou dokumentu Komunikačná matica uloženom na zdieľanom projektovom úložisku.

Riadenie projektu zo strany Objednávateľa bude zabezpečené prostredníctvom Projektového manažéra a Finančného manažéra a bude trvať počas celej doby realizácie projektu. Bude pokrývať oblasť projektového riadenia (projektový manažment, celková koordinácia projektu, celkový dohľad nad vývojom dodávaného Diela, vrátane kvality), finančného riadenia a monitorovania realizácie projektu v zmysle riadenia podľa vyhlášky MIRRI č. 401/2023 Z. z. v platnom znení.

V súlade s výzvou Mesto Trnava zabezpečí, aby počas implementácie projektu a po jeho skončení (počas obdobia udržateľnosti) bol k dispozícii interný personál na obsluhu, prevádzku a rozvoj riešenia. Zároveň bude minimálne počas obdobia udržateľnosti zabezpečené financovanie tohto personálu zo zdrojov Mesta Trnava.

Projektový manažér Objednávateľa bude zabezpečovať koordináciu projektových činností a manažment v súlade s metodikou PRINCE2 (hlavné dokumenty, priebežné manažérske výstupy, a pod.).

Projektový manažér Objednávateľa  bude riadiť, administratívne a organizačne zabezpečovať implementáciu projektu, komunikovať s  dodávateľmi, sledovať plnenie harmonogramu projektu a zabezpečovať dokumenty požadované MIRRI. Zároveň bude v spolupráci s projektovým manažérom dodávateľa koordinovať realizáciu hlavných aktivít, činností a úloh projektu.

Zodpovednosťou projektového manažéra je v spolupráci s finančným manažérom (objednávateľa) finančné riadenie projektu kontrolu rozpočtu projektu a jeho súlad s účtovnými dokladmi. Kontrolu podpornej účtovnej dokumentácie a poradenstvo pri definovaní oprávnených výdavkov bude zabezpečovať finančný manažér Objednávateľa.

Súčasťou projektového riadenia bude tiež operatívna projektová podpora zabezpečujúca administratívnu podporu pre písomnú komunikáciu, administratívne vedenie projektovej dokumentácie a prípravu podkladov pre členov projektového tímu, organizáciu stretnutí a pod.. V rámci aktivity budú taktiež zabezpečovaný manažment a hodnotenie kvality zo strany Objednávateľa.

RV je riadiaci orgán projektu, ktorý zodpovedá najmä za splnenie stanovených cieľov projektu, rozhoduje o zmenách, ktoré majú zásadný význam a prejavujú sa hlavne dopadom na časový harmonogram a finančné prostriedky projektu. Reprezentuje najvyššiu akceptačnú autoritu projektu. Štatút Riadiaceho výboru projektu upravuje najmä úlohy, zloženie a pôsobnosť RV, ako aj práva a povinnosti členov RV pri riadení a realizácii predmetného projektu.

Projektový manažér riadi projekt, kvalitu a riziká projektu a zabezpečuje plnenie úloh uložených RV. Členovia projektového tímu zabezpečujú plnenie úloh uložených projektovým manažérom, alebo RV.

Ďalšie povinnosti členov RV, projektového manažéra a členov projektového tímu sú uvedené vo Vyhláške č. 401/2023 Z. z. a v doplňujúcich vzoroch a šablónach zverejnených na webovom sídle MIRRI SR.

9. IMPLEMENTÁCIA A PREBERANIE VÝSTUPOV PROJEKTU

Implementácia a preberanie výstupov projektu bude realizované v súlade s Vyhláškou Ministerstva investícií, regionálneho rozvoja a informatizácie Slovenskej republiky č. 401/2023 Z. z. o riadení projektov a zmenových požiadaviek v prevádzke informačných technológií verejnej správy v zmysle ustanovení podľa § 5 a nasledovných ustanovení.

10. PRÍLOHY

Koniec dokumentu