Formulář žádosti
Formulář žádosti
o stanovisko Hlavního architekta eGovernmentu
k plánované změně řešení v rámci uzavřené smlouvy na provoz, podporu, údržbu, rozvoj a další
k existujícímu ICT řešení –
typ B2
Odbor Hlavního architekta eGovernmentu MV
Praha, únor 2020 verze 6.0.4a
UPOZORNĚNÍ: Přestože je formulář zveřejněn ve formátu umožňujícím změny, žadatel není oprávněn měnit strukturu vybraných otázek, či předepsaných odpovědí. Pokud se tak stane, Xxxxx Hlavního architekta eGovernmentu vyhodnotí takovou změnu jako porušení pravidel při schvalování a formulář bude vrácen bez vydání stanoviska.
Toto dílo podléhá licenci Creative Commons Uveďte původ 4.0 Mezinárodní Licence
1. Z Á K L A D N Í P O D M Í N K Y P R O J E K T U
1.1. Úvodní informace o žadateli o stanovisko k projektu
Tabulka 1: Úvodní informace o žadateli projektu: | ||||
Organizace žadatele | Ministerstvo vnitra | xxxxxxx Xxxxxx 0000/0, Xxxxx 4 | 00007064 | |
Ředitel pro informatiku nebo Statutární zástupce | Xxx. Xxxxx Xxxx | ředitel odboru eGovernmentu | 974 817 524 | |
Kontaktní osoba projektu | Xxx. Xxx Xxxxxx | vedoucí oddělení optimalizace eGovernmentu, MV | 000 000 000 | |
Architekt projektu | Xxxxxxxx Xxxxxxx | enterprise architekt, XXXXX | 773 083 343 | |
Datum vypracování žádosti: | 4. 5. 2020 | |||
Tabulka 2: Žádost o stanovisko dle (druh žádosti): | |
Usnesení vlády č. 86, ze dne 27. ledna 2020, ve znění pozdějších předpisů | Ano |
Zákona č. 365/2000 Sb., o informačních systémech veřejné správy, ve znění pozdějších předpisů | Ano |
Výzev v Integrovaném regionálním operačním programu (IROP), vypište číslo výzvy | Ne |
Dobrovolná žádost o stanovisko | Ne |
1.2. Shrnutí charakteristik projektu
Tabulka 3: Shrnutí charakteristik projektu: | |||
Název projektu: | Rozvoj Portálu veřejné správy v roce 2020 | ||
Hlavní předmět projektu: | Předmětem projektu je navazující rozvoj Portálu veřejné správy, informační a transakční části, konkrétně jeho rozšíření a úprava vybraných stávajících funkcionalit v návaznosti na platnou legislativu a záměry Strategie koordinované a komplexní digitalizace České republiky 2018+ (neboli Digitálního Česka). Cílem projektu je mj. zvýšení hospodárnosti a bezpečnosti dotčeného informačního systému. Jedná se o realizaci dílčí změny řešení v souladu se závazkem z dříve schváleného formuláře žádosti typu B1 „Rozvoj Portálu veřejné správy“ vč. návazností na legislativní a strategické rámce. | ||
Výpis dotčených určených IS dle UV 86/2020 a zákona 365/2000 Sb. | Portál veřejné správy | ||
Termín plánovaného zahájení realizace projektu (zahájení výstavby, je- li součástí): | 08/2020 | ||
Termín plánovaného dokončení realizace projektu (akceptace a uvedení do produkčního provozu): | 12/2020 | ||
Termín plánovaného zahájení provozu (spuštění produkčního provozu): | 12/2020 | ||
Termín plánovaného ukončení provozu (konec smluvního vztahu s dodavatelem): | není stanoven | ||
Předpokládaný počet let využívání výstupů projektu (počet let od začátku využívání do konce využívání): | nejméně 5 let | ||
Možnost zveřejnění | Možno zveřejnit | V případě požadované | |
Tabulka 3: Shrnutí charakteristik projektu: | ||||
formuláře: | bez omezení | anonymizace (nebo nemožnosti zveřejnění) vypište údaje a úpravy, aby bylo zveřejnění možné (případně proč není možné): | ||
Shrnutí shody se základními principy a standardy českého eGovernmentu: | ||||
Žádáte výjimku(y)? | Ne | Počet žádostí o výjimku v přílohách: | ||
Komentář k výjimkám: | ||||
Určení: věcného správce, technického správce a provozovatele (pokud je předmětem více IS, klasifikujte hlavní a ostatní vysvětlete v tabulce 8) | ||||
Věcný správce: | Odbor eGovernmentu, MV | |||
Technický správce: | Odbor eGovernmentu, MV | |||
Provozovatel: | Národní agentura pro komunikační a informační technologie, s. p. | |||
Realizační (implementační) výdaje v rámci projektu (součet hodnot ve sloupci 1 tabulky 57 v kapitole 3.2.1) v Kč bez DPH: | 37 070 082,64 Kč | |||
Provozní výdaje plánované v rámci projektu (součet hodnot ve sloupci 2 tabulky 57 v kapitole 3.2.1) v Kč bez DPH: | 0 Kč | |||
1.3. Popis, potřebnost a výstupy projektu
Tabulka 4: Popis projektu: |
Popis výchozí situace projektu (tzv. As-Is): |
Stávající PVS, především jeho transakční část (Portál občana), představuje informační systém postavený na moderních trendech vývoje softwaru, jeho testování, nasazování a provozu, který pro svůj provoz využívá cloudovou platformu. Tato investice se netýká obměny ani pořízení nového majetku, nýbrž implementace nových funkcionalit a rozvoje stávajícího majetku. PVS je provozován kompletně v cloudu na škálovatelné platformě (Microsoft Azure) a jedná se o modulární aplikaci, kde vedle sebe běží několik modulů (lze tedy jednoduše přidávat a ubírat jednotlivé služby). Sám PVS neukládá žádné osobní informace o uživatelích (vede pouze bezvýznamový identifikátor a to, co si sám uživatel uloží, např. přílohu datové zprávy). Přímo je napojen na velmi omezený počet systémů, konkrétně: Informační systém datových schránek (přihlášení přes datovou schránku + připojení vlastní datové schránky k portálu pro odesílání formulářů a činění podání vůči veřejné správě), propojený datový fond (Informační systém základních registrů + eGon Service Bus pro napojení na agendové informační systémy), Národní bod (přihlášení přes elektronickou identitu). |
Popis projektu (tzv. To-Be): |
Jedná se o rozvoj informačního systému Portál veřejné správy (dále též „PVS“), v jehož rámci se předpokládá realizace následujících částí: a) úprava bezpečnostní vrstvy perimetru PVS: 1. úprava práce s šifrovacími klíči (jejich generováním, rotacemi a zálohováním) vč. implementace security modulů; b) úpravy a rozvoj transakční části PVS (Portálu občana): 1. migrace na aktuální verze frameworků (aplikačních rámců) webové aplikace, v rámci které proběhne komplexní analýza současné verze frameworků; 2. implementace mikro-služby pro zprostředkování SMTP a SMS komunikace (jedno místo pro nastavení a parametrizace SMS a e-mailů pro weby v perimetru PVS); 3. implementace služby založení datové schránky prostřednictvím dálkového přístupu a příp. přidružených služeb; 4. zobrazení či využívání údajů a jiných výstupů poskytovaných z informačních systémů veřejné správy; 5. rozvoj testovacího (DEV) a předprodukčního (Stage) prostředí; 6. implementace dalších podání vybraných žádostí o výstupy z informačních systémů veřejné správy a jiných formulářových řešení prostřednictvím datových zpráv či |
Tabulka 4: Popis projektu: | |||
prostřednictvím jiných způsobů a nástrojů vč. dalšího testování a rozvoje konceptu úplného elektronického podání; c) úpravy a rozvoj informační části PVS: 1. publikace katalogu služeb a úkonů v souladu se zákonem o právu na digitální služby a úprava postupů řešení životních situací; 2. úpravy spojené s podporou implementace platebních bran ve veřejné správě (nová sekce PVS obsahující informace o platebních branách, případnou dokumentaci, instrukce pro pořízení platební brány atp.); 3. první fáze implementace jednotné digitální brány dle evropského nařízení o jednotné digitální bráně (publikace informací o vybraných společných službách); 4. rozvoj testovacího prostředí a povýšení na aktuální verze frameworků (aplikačních rámců); d) úpravy a rozvoj design systému; e) vývoj mobilní aplikace pro poskytování služeb Portálu občana, potažmo PVS. Využití a změny stávající aplikace a infrastruktury: • V rámci rozvoje PVS dojde k širšímu využití služeb Centrálního místa služeb, konkrétně centrální sdílené služby eGon Service Bus (Informačního systému sdílené služby), jejích komunikačních kontextů a protokolů. • V rámci rozvoje PVS dojde k širšímu využití služeb Informačního systému základních registrů a též nového OpenAPI RPP. • V rámci rozvoje PVS dojde k širšímu využití služeb Informačního systému datových schránek prostřednictvím jeho veřejných i neveřejných rozhraní. Nově bude PVS v rámci funkcionality založení datové schránky využívat webovou službu ISDS FindDataBox2 pro ověření existence datové schránky. Rozhraní ISDS je popsáno v přílohách provozního řádu na adrese: xxxxx://xxx.xxxxxxxxxxxxxx.xxxx/xxxxxxxx-xxxxxxxxx/xxxxxxxx-xxx. V rámci rozvoje PVS nejsou kladeny požadavky na vznik nový webových služeb ISDS, pouze dojde k úpravě stávajících funkcionalit ISDS (nově např. práce s návratovými URL na straně ISDS – např. v případě, že je uživatel přesměrován na portál ISDS, zde provede určitou akci jako např. založení nové DS, načež je následně přesměrován zpět na původní portál/web, ze kterého přišel – to vše za uplatnění principu single sign-on). • I nadále se bude architektonicky stavět na konceptu mikro služeb provozovaných a orchestrovaných v kontejnerech za kooperace „infrastruktury jako kódu“ a nasazených na cloudové platformě. • Nadále se využívá a rozvíjí design systém vyvinutý pro webové aplikace, portály a informační systémy MV (xxxxx://xxxxxxxxxxxx.xxx.xx/), s jehož použitím se počítá i v budoucnu a který v rámci projektu dozná klíčových změn (např. v souvislosti se zákonem č. 99/2019, o přístupnosti internetových stránek a mobilních aplikací a o změně zákona č. 365/2000 Sb.). | |||
Důvod změny – označte všechny relevantní | |||
Legislativní důvody | ☒ | Konec licencí | ☐ |
Modernizace, optimalizace řešení (výsledky business analýz) | ☒ | Lepší nabídka trhu | ☐ |
Požadavky zaměstnanců, uživatelů | ☒ | Konec podpory od dodavatele | ☐ |
Konec podpory produktu | ☐ | Jiné (vysvětlete v tabulce 8) | ☐ |
Tabulka 4: Popis projektu: |
Přehled případných alternativ řešení rozdílných od „Popis projektu (tzv. To-Be)“ specifikovaném výše |
Nejsou relevantní alternativy – vychází a staví se na stávající architektuře PVS za využití již integrovaných centrálně sdílených nástrojů, za snahy o maximální dodržení ITIL v4 Guiding Principles a v souladu s platnou legislativou. Pro úplnost uvádíme přehled alternativ: Nulová varianta (vč. xxxxx vyplývajících z nerealizování investičního záměru): • Uložené úkoly nebude možné bez vyžadovaného majetku plnit. • Nebude-li v tomto případě majetek pořízen, poté: o nedojde k rozšíření funkcionalit již existujícího Portálu veřejné správy; o nedojde k naplnění povinností stanovených platnou českou a evropskou legislativou; o nedojde k naplnění vybraných záměrů Digitálního Česka, které jsou výslovně navázány na PVS. Varianta vertikální spolupráce: Zadavatel potřebuje pro svou činnost vyplývající z organizačního řádu MV výkon odborné činnosti, přičemž potřebné lidské zdroje s odpovídající kvalifikací nemá k dispozici mezi svými kmenovými zaměstnanci. NAKIT je připraven požadované služby poskytnout prostřednictvím vlastních kmenových zaměstnanců a poddodavatele, přičemž již nyní disponuje kapacitami zkušených odborníků v oboru ICT, kteří znají činnost a projekty zadavatele (bez nutností např. jejich zaškolení nebo proškolení). Další rozvoj Portálu veřejné správy pod NAKIT byl vybrán z několika dalších konkrétních důvodů: • NAKIT zajišťoval vývoj a následující rozvoj transakční části Portálu veřejné správy, • jako jeden z mála dodavatelů má zkušenosti s nasazováním informačních systémů veřejné správy do prostředí cloudu a zároveň disponuje vlastními zaměstnanci, kteří jsou toto schopni zajistit, • provozuje a dále rozvíjí informační a komunikační infrastrukturu veřejné správy a datové sítě Ministerstva vnitra, na které je Portál veřejné správy napojen, a to včetně Centrálního místa služeb a Dohledového centra pro provoz ICT systémů a kybernetickou bezpečnost. Další alternativní varianty: • nutnost zaškolení nebo proškolení zaměstnanců dodavatele v oblasti PVS, ale i v dalších tématech, např. v oblasti bezpečnosti (PVS je součástí kritické informační infrastruktury veřejné správy); • nutnost seznámení s napojenými informačními systémy a infrastrukturou, které PVS využívá; • chybějící dohled ovládajícího veřejného zadavatele. |
Tabulka 5: Přehled výstupů projektu: | ||||
Označení výstupu | Množství a jednotka | Celková cena výstupu [Kč] | Vysvětlení výstupu | Rozsah změny pro SW |
Rozšíření PVS | 1 ks | 37 070 082,64 Kč bez DPH | Zahrnuje následující rozšíření a změny: | Rozšířený |
• úpravy bezpečnostní vrstvy celého perimetru; • úpravy a rozvoj transakční části; • úpravy a rozvoj informační části; • úpravy a rozvoj design systému; • vývoj mobilní aplikace (resp. | ||||
Tabulka 5: Přehled výstupů projektu: | ||||
Označení výstupu | Množství a jednotka | Celková cena výstupu [Kč] | Vysvětlení výstupu | Rozsah změny pro SW |
mobilního rozhraní). Na majetkové účtárně bude tento výstup evidován jako zhodnocení stávajícího majetku (PVS), stejně jako tomu bylo u předcházejících projektů „PVS 2.0 – Portál občana“ a „Navazující rozvoj Portálu veřejné správy“. | ||||
Zvolte položku. | ||||
Zvolte položku. | ||||
1.4. Právní klasifikace předmětu projektu
Tabulka 6: Klasifikace předmětu projektu dle zákonů eGovernmentu (pokud je předmětem více IS, klasifikujte hlavní a ostatní vysvětlete): | |||
Klasifikace | Vyberte | ||
Druh informačního systému dle klasifikace zák. č. 365/2000 Sb., o informačních systémech VS | Informační systém veřejné správy | ||
Je projektem určený informační systém dle zák. 365/2000 Sb., o informačních systémech VS | Ano - VYPLŇTE DLE JAKÉHO KRITÉRIA | ☒ | Využívá služby referenčního rozhraní nebo poskytuje služby referenčnímu rozhraní |
☒ | Má vazbu na systém dle bodu 1 | ||
☒ | Je určený k poskytování služby fyzickým nebo právnickým osobám s předpokládaným počtem uživatelů, kteří využívají přístup se zaručenou identitou, alespoň 5000 ročně | ||
Je projektem agendový informační systém dle zák. 111/2009 Sb., o základních registrech | Ano | ||
Budou předmětem projektu přijímány a odesílány datové zprávy dle zák. č. 300/2008 Sb., o elektronických úkonech a autorizované konverzi dokumentů? | Ano | ||
Druh informačního/komunikačního systému dle klasifikace zák. č. 181/2014 Sb., o kybernetické bezpečnosti | Kritická informační infrastruktura | ||
Je předmět projektu v souladu s usnesením vlády ČR č. 241/2018 ukládající zacházení se všemi ICT minimálně jako Významnými Informačními Systémy? | Ano | ||
Tabulka 7: Vazba projektu na informace v Portálu veřejné správy | ||
Klasifikace | Vyberte | Vysvětlete |
Budou v Portálu veřejné správy (resp. v Portálu občana) popsány všechny související životní situace v souladu s vyhláškou č. 442/2006 Sb.? | Ano | |
Bude pro přístup občanů k el. službám úřadu využita struktura služeb v Portálu veřejné správy (resp. v Portálu občana)? | Ano | |
Budou projektem využívané formuláře při el. komunikaci s klienty VS dostupné s využitím struktury služeb v Portálu veřejné správy (resp. Portálu občana)? | Ano | |
Tabulka 8: Vysvětlení k základním podmínkám (nutným předpokladům dosažení cílů) projektu: |
Vzhledem k průběžným aktualizacím, výmazům a přibývání záměrů Digitálního Česka si dovolujeme upozornit, že podoba vazby na Digitální Česko se může v čase měnit. |
2. A R C H I T E K T O N I C K É I N F O R M A C E O P R O J E K T U
2.1. Dodržení architektonických principů NA VS ČR
Odbor Hlavního architekta eGovernmentu MV předpokládá soulad projektu s principy Národní architektury veřejné správy ČR tak, jak jsou popsány v metodickém pokynu k formuláři. Případný nesoulad v návrhu je možný výhradně, pokud je k němu vyplněna žádost o výjimku, jejíž schválení bude rovněž předmětem posouzení. Otázky na doložení souladu s architektonickými principy jsou obsaženy průběžně v celém formuláři.
2.2. Enterprise architektura projektu a její kontext
Tabulka 9: Architektonický model: | |
V rámci Enterprise Architektury projektu přiložte jako přílohu model exportovaný ve standardizovaném výměnném formátu The Open Group ArchiMate Model Exchange File Format | Ano, model je přiložen jako příloha ve standardizovaném formátu |
Případně vysvětlete, proč není model přiložen ve standardizovaném formátu či není přiložen vůbec. | |
2.2.1. Motivační architektura - strategie a směrování
Tabulka 10: Vysvětlete, proč projekt realizujete v této podobě a čeho jím chcete dosáhnout. Pro vysvětlení motivace použijte zejména pojmy z odpovídajícího modelu motivační architektury (motivátory, zainteresované, cíle, principy, podmínky, architektonické požadavky): |
Motivátory: • legislativní změny s účinností od roku 2020, především zákon č. 12/2020 Sb., o právu na digitální služby a o změně některých zákonů, a nařízení EP a Rady (EU) 2018/1724 ze dne 2. října 2018, kterým se zřizuje jednotná digitální brána; • záměry Strategie koordinované a komplexní digitalizace České republiky 2018+ (dále též „Digitální Česko“), např. záměr „Další rozvoj Portálu občana (transakční části Xxx.xx)“ nebo „Prezentace informací o službách veřejné správy na PVS“; • požadavky na bezpečnost a implementaci nových funkcionalit, potažmo služeb na PVS. Cíle: • zvýšení transparentnosti veřejné správy prostřednictvím nástrojů eGovernmentu; |
Tabulka 10: Vysvětlete, proč projekt realizujete v této podobě a čeho jím chcete dosáhnout. Pro vysvětlení motivace použijte zejména pojmy z odpovídajícího modelu motivační architektury (motivátory, zainteresované, cíle, principy, podmínky, architektonické požadavky): |
• implementace základních principů eGovernmentu (zásada „pouze jednou“ atp.); • zvýšení přístupnosti a uživatelské přívětivosti veřejné správy; • dostupnost služeb z jednoho místa kontaktu s veřejnou správou. Výsledek: • Portál veřejné správy (upravený). Posouzení: • Portál Xxx.xx (Vize a strategie rozvoje). Zainteresovaní: • Ministerstvo vnitra; • Dodavatel (NAKIT). |
Tabulka 10: Vysvětlete, proč projekt realizujete v této podobě a čeho jím chcete dosáhnout. Pro vysvětlení motivace použijte zejména pojmy z odpovídajícího modelu motivační architektury (motivátory, zainteresované, cíle, principy, podmínky, architektonické požadavky): |
Portál veřejné správy (upravený) Zvýšení trasparentnosti Implementace základních Zvýšení přístupnosti a Dostupnost služeb z veřejné správy principů eGovermmentu uživatelské přívětivosti jednoho místa kontaktu s prostřednictvím nástrojů (zásada "pouze jednou" veřejné správy veřejnou správou eGovermmentu atp.) Cíle Portálu VS Požadavky na bezpečnost a implementaci nových funkcionalit, potažmo služeb na PVS Záměry Strategie koordinované a komplexní digitalizace České republiky 2018+ (dále též Sdružené motivátory „Digitální Česko“), např. záměr „Další rozvoj Legislativní změny s Portálu občana (transakční účinností od roku 2020, části Xxx.xx)“ nebo především zákon č. „Prezentace informací o 12/2020 Sb., o právu na službách veřejné správy digitální služby a o změně na PVS“ některých zákonů, a nařízení EP a Rady (EU) 2018/1724 ze dne 2. října 2018, kterým se zřizuje jednotná digitální brána Portál Xxx.xx (Vize a Ministerstvo vnitra ČR NAKIT strategie rozvoje) |
2.2.2. Efektivita projektu – výkonnostní architektura
Tabulka 11: Vysvětlete dopad projektu na hospodárnost, účelnost, účinnost, časovou a kvalifikační náročnost a na kvalitu služeb v organizaci (viz metodika TCO zveřejněná zde): |
Portál veřejné správy představuje informační systém postavený na moderních trendech vývoje softwaru, jeho testování, nasazování a provozu, který pro svůj provoz využívá cloudovou platformu. Také v rámci rozvoje se pracuje s řešením odpovídajícím moderním trendům i ICT standardům, modularity návrhu řešení a efektivity v oblasti nákladů na provoz a následný rozvoj. Právě modularita systému a uplatnění ICT standardů tam, kde to je možné, zajistí efektivnější implementaci změn v rámci budoucích komplexů nových služeb a funkcí. Rozvíjen a i nadále Portálem veřejné správy využíván bude také stávající design systém. Účelem design systému je a bylo vytvořit jednoduchá pravidla pro tvorbu webových stránek a aplikací, které budou konzistentní |
Tabulka 11: Vysvětlete dopad projektu na hospodárnost, účelnost, účinnost, časovou a kvalifikační náročnost a na kvalitu služeb v organizaci (viz metodika TCO zveřejněná zde): |
s webovými stránkami pod doménou Xxx.xx. V současné době design systém Xxx.xx přebírají další rezorty za účelem sjednocení designu také na svých webových stránkách. Dlouhodobým cílem je tento trend prohlubovat a rozšiřovat tak využívání design systému napříč webovými stránkami a aplikacemi celé veřejné správy, a to i v rámci intranetových aplikací pro úředníky. Využívání jednotného design systému má několik velkých výhod. Především splňuje nároky na uživatelskou přívětivost moderních webových stránek. Jednotný vzhled, jednotná funkcionalita ovládacích prvků a jednotná struktura informací vzbuzují v uživateli pocit jistoty, neboť ví, že je v interakci s veřejnou správou, ať se pohybuje na stránkách Ministerstva vnitra nebo jiné instituce, ví, co od stránek může očekávat a nemusí vynakládat velké úsilí na to, aby se na stránkách zorientoval. Ve vztahu k uživatelům systému budou nabídnuty nové formuláře. Ty budou tvořeny v otevřených formátech (eliminace vendor lock-in). Data a definice všech parametrů bude v rámci jednoho xml souboru, což poskytne komfort standardu, který bude využitelný nejen pro Portál veřejné správy, ale také Czech POINT 2.0, ale dále také pro veřejnou správu v rámci podpory výkonu samoobslužných agend, jelikož definice formuláře bude možné použít kdekoli, kde bude standard implementován. Správci systémů tímto získají možnost publikovat formuláře také ve svých systémech. |
Tabulka 12: Přehled požadovaných cílových parametrů SLA nových nebo měněných služeb: | |||
Název v rámci projektu nově zřizované nebo měněné služby | Specifikace SLA parametru služby | Sjednaná mezní hodnota SLA parametru | Sjednaný způsob měření hodnoty SLA |
Dostupnost všech služeb, rozhraní a integrací v provozním (produkčním) prostředí | Technické komponenty budou dostupné pro konzumenty 24x7. | 99,5 %, 24x7 | Fault a Capacity Monitoring v kombinaci s E2E testy |
Dostupnost všech služeb, rozhraní a integrací v předprodukčním (stage) prostředí | Technické komponenty budou dostupné pro konzumenty 10x5 od 8 do 18 hodin. | 95 %, 10x5, 8 – 18 hodin | Fault a Capacity Monitoring v kombinaci s E2E testy |
Dostupnost všech služeb, rozhraní a integrací v testovacím prostředí | Technické komponenty budou dostupné pro konzumenty 10x5 od 8 do 18 hodin. | 90 %, 10x5, 8 – 18 hodin | Fault a Capacity Monitoring v kombinaci s E2E testy |
Podpora | Zákaznická podpora | 24x7 | Měření na úrovni ServiceDesku |
Zahájení řešení požadavku – odstranění závady | Kritická závada (nefunkční části systému, nedostupnost systému z URL ani z jiných zdrojů, systém nespolupracuje se systémy třetích stran atd.). | Zahájení do 2 hodin od nahlášení požadavku, vyřešení do 4 hodin od nahlášení, 24x7 | Měření na úrovni ServiceDesku |
Zahájení řešení požadavku – odstranění závady | Závada s vysokou prioritou (některá ze základních funkcí systému je nestabilní atp.). | Zahájení do 8 hodin od nahlášení požadavku, vyřešení do 24 hodin od nahlášení, 24x7 | Měření na úrovni ServiceDesku |
Zahájení řešení požadavku – odstranění závady | Závada se střední prioritou (závada nemá vliv na funkčnost portálu, nedostatky nepodstatné povahy, např. v podobě zvýšení doby odezvy | Zahájení do 24 hodin od nahlášení požadavku, vyřešení do 96 hodin, 24x7 | Měření na úrovni ServiceDesku |
v běžném provozu). | |||
Zahájení řešení požadavku – odstranění závady | Ostatní závady a požadavky na malé změny funkcionality portálu, které jsou řízeny procesy Request managementu. | Zahájení a vyřešení do jednoho měsíce nebo v následující verzi (release), 24x7 | Měření na úrovni ServiceDesku |
Zahájení řešení požadavku – odstranění závady | Závady detekované na testovacím prostředí | Zahájení do 8 hodin od nahlášení požadavku, vyřešení do 48 hodin od nahlášení, 10x5, 8 – 18 hodin | Měření na úrovni ServiceDesku |
Zahájení řešení požadavku – odstranění závady | Závady detekované na předprodukčním (stage) prostředí. | Zahájení do 8 hodin od nahlášení požadavku, vyřešení do 24 hodin od nahlášení, 10x5, 8 – 18 hodin | Měření na úrovni ServiceDesku |
Zajištění služby HelpDesk a monitoring služeb | Dostupnost služeb HelpDesk, kontaktní adresa elektronické pošty, kontaktní formulář a monitoring | Dostupnost a KPIs definována na úrovni služeb a rozhraní | Měření pomocí reportingu jednotlivých služeb |
Činnost správy zranitelností | Periodické provedení a report | Pravidelný měsíční reporting | Vulnerability skenování, penetrační a bezpečnostní testování změn (předem definovaných), provozní deník |
Kritické záplaty | Kritické záplaty | Instalovány během 12 hodin od vydání oznámení | Provozní deník |
Penetrační testy | Penetrační testy | Pravidelně min. 1x ročně | Provozní deník |
Tabulka 13: Popis klíčových měřitelných ukazatelů výkonnosti (KPI): | |||||
Název v rámci projektu nově zřizované nebo měněné služby vůči koncovému klientovi | Předpokládaný počet transakcí za rok | Kolik stojí každá ukončená transakce bez DPH? [Kč] | Jaké % uživatelů je spokojeno s poskytovanou službou? | Jaké % transakcí je úspěšně dokončeno? | Jaké % uživatelů si zvolí raději elektronickou formu služby než ne- elektronickou? |
Počet učiněných podání | cca 25 000 | 0 | 95 % | 99 % | 100 % |
Počet zobrazení/čtení údajů z AIS | cca 1 mil. | 0 | 95 % | 96 % | 100 % |
2.2.3. Byznys architektura - poskytování veřejných služeb
Tabulka 14: Katalog organizačních jednotek, aktérů a rolí: | ||
Název objektu | Počet uživatelů služby / IS | Vysvětlení významu objektu |
Aktér (organizace, organizační jednotky / úředníci, klienti veřejné správy) | ||
Fyzická osoba | Statisíce | Občan ČR nebo jiná fyzická osoba využívající služeb veřejné správy ČR, vedená v základním registru obyvatel. |
Tabulka 14: Katalog organizačních jednotek, aktérů a rolí: | ||
Název objektu | Počet uživatelů služby / IS | Vysvětlení významu objektu |
OVM | Tisíce | Orgán veřejné moci poskytující služby veřejné správy. |
Role aktérů při výkonu a příjmu služby | ||
Uživatel | Statisíce | Konzument služeb veřejné správy. |
Úřad | Tisíce | Role orgánu veřejné moci. |
Tabulka 15: Katalog funkcí a procesů veřejné správy a ve veřejné správě: | |
Název objektu | Vysvětlení významu objektu |
Agendové funkce (agendy dle RPP, a dále neregistrované, podpůrné a provozní agendy nebo funkční oblasti) | |
Agenda A344 (Portál veřejné správy) | |
Agendy OVM (různé) | |
Procesy v agendách nebo funkčních oblastech | |
Čtení z agendových informačních systémů | Hlavní proces pro načítání údajů ze správních evidencí a dalších agendových informačních systémů s využitím přístupu se zaručenou identitou. |
Přístup do portálu přes mobilní aplikaci | Hlavní proces pro zajištění přístupu do PVS (anonymního i autentizovaného) přes mobilní rozhraní formou progresivní webové aplikace (jednoho z typů mobilních aplikací). |
Učinění podání / odeslání formuláře | Hlavní proces pro zajištění učinění podání / odeslání formuláře. Dojde k rozšíření publikace uceleného seznamu formulářů s funkčními odkazy na Portálu občana, které spolupracující subjekty na svých portálech nabízejí. Uživatel tak nebude muset přecházet na konkrétní portál, jehož formulář potřebuje, ale daný formulář si vyhledá přímo na Portálu občana a otevře pomocí odkazu za zachování principu single sign-on. Uvedené formuláře jsou dostupné na portálech jednotlivých poskytovatelů služeb (SeP). Portál občana v současné době umožňuje přistupovat k těmto formulářům nepřímo tak, že uživatel přihlášený pomocí NIA může přecházet na jiné portály publikující na Portálu občana svou dlaždici. |
Vyhledávání a procházení katalogu služeb veřejné správy | Hlavní proces pro zobrazení katalogu služeb veřejné správy na informační části PVS, umožní procházení a vyhledávání služeb. Služby budou tříděny do kategorií a podkategorií pro snazší orientaci. |
Vyhledávání a procházení katalogu služeb v rámci Jednotné digitální brány | Hlavní proces pro zobrazení katalogu služeb v rámci Jednotné digitální brány na informační části PVS. Umožní procházení a vyhledávání služeb. Služby budou tříděny do kategorií a podkategorií pro snazší orientaci. |
Prezentace a procházení design systému Ministerstva vnitra | Dílčí aktivita pro prezentaci design systému, jeho procházení vč. detailních popisů částí design systému, praktických příkladů, manuálů a grafických vzorů. |
Upozorňování na termíny a blížící se události | Dílčí aktivita pro zajištění rozesílání notifikací prostřednictvím nové notifikační služby. Mezi obslužné kanály patří datové schránky, elektronická pošta a SMS. |
Založení datové schránky | Dílčí aktivita pro založení datové schránky v reálném čase, a to pouze s využitím přístupu se značnou či vysokou úrovní důvěry přes kvalifikovaný systém elektronické identifikace. Předmětem požadavku je umožnit uživateli – fyzické osobě, aby některé úkony týkající se datových schránek mohla provádět |
Tabulka 15: Katalog funkcí a procesů veřejné správy a ve veřejné správě: | |
Název objektu | Vysvětlení významu objektu |
prostřednictvím dálkového přístupu z Portálu občana, tedy bez nutnosti návštěvy kontaktního místa Czech Point. Služba umožní uživateli zřízení následujících typů datové schránky na žádost: • Fyzická osoba – FO (40) • Podnikající fyzická osoba – PFO (30) Zřízení datové schránky v prostředí klientského portálu ISDS probíhá on-line. Zápis identifikátoru nové datové schránky do ROB / ROS má ale časovou prodlevu (cca 10 minut). Portál občana proto musí od ISDS získat informaci, že již došlo ke zřízení datové schránky a že je schránka aktivována, aby mohlo dojít k připojení nové datové schránky do Portálu občana. K tomuto účelu bude využívat webovou službu ISDS FindDataBox2. Rozhraní ISDS je popsáno v přílohách provozního řádu na adrese: xxxxx://xxx.xxxxxxxxxxxxxx.xxxx/xxxxxxxx-xxxxxxxxx/xxxxxxxx-xxx V případě nepřipojené datové schránky zobrazuje Portál občana uživateli oznámení „Nemáte připojenou datovou schránku“ na místech, kde je využíván přístup do datové schránky. Přitom nabízí uživateli dvě volby: • Přidat účet – přesměrování na přihlašovací stránku klientského portálu ISDS (po přihlášení a udělení souhlasu s povolením přístupu dojde k připojení datové schránky do Portálu občana). • Založit – v současnosti přesměrování na informační stránku s popisem zřízení datové schránky; nově bude uživatel přesměrován do klientského portálu ISDS. | |
Funkce (činnosti) zařazené v procesu nebo samostatně existující na podporu agend / funkčních oblastí (NEPOVINNÉ) | |
Tabulka 16: Katalog (interních a externích) služeb: | |||
Název služby | Kdo poskytuje službu | Kdo je konzumentem služby | Výčet použitých obslužných rozhraní služby |
Interní služby veřejné správy (dovnitř úřadu či subjektu VS) | |||
Externí služby veřejné správy (vně úřadu či subjektu VS) | |||
Čtení z agendových informačních systémů | MV (PVS – transakční část) | Občan | Webový portál, mobilní aplikace |
Učinění podání / odeslání formuláře | MV (PVS – transakční a informační část) | Občan, OVM | Webový portál, mobilní aplikace, datová schránka |
Vyhledávání a procházení katalogu služeb veřejné správy | MV (PVS – informační část) | Občan, OVM | Webový portál, mobilní aplikace |
Vyhledávání a procházení katalogu služeb v rámci Jednotné | MV (PVS – informační část) | Občan, OVM | Webový portál, mobilní aplikace |
Tabulka 16: Katalog (interních a externích) služeb: | |||
Název služby | Kdo poskytuje službu | Kdo je konzumentem služby | Výčet použitých obslužných rozhraní služby |
digitální brány | |||
Prezentace a procházení design systému Ministerstva vnitra | MV (PVS – informační část) | Občan, OVM | Webový portál |
Upozorňování na termíny a blížící se události | MV (PVS – transakční část) | Občan | SMTP server, datová schránka, SMS gateway |
Založení datové schránky | MV (PVS – transakční část) | Občan | Webový portál, mobilní aplikace |
Tabulka 17: Využití front-office rozhraní předmětem projektu: | ||
Rozhraní | Využití | Popis využití rozhraní v projektu |
Asistovaná přepážka | Nerelevantní | |
Webový portál | Ano | Jedná se o primární rozhraní pro poskytování služeb klientovi. |
Datová zpráva (ISDS) | Ano | Klient pro práci s datovými schránkami. |
Elektronicky podepsaný dokument do e-Podatelny | Ne | PVS využívá jiné nástroje pro učinění podání a odesílání formulářů (datová schránka, obstarání výpisu s přístupem se zaručenou identitou, přímé volání služeb ISZR). |
Listinnou cestou do podatelny | Nerelevantní | |
Tabulka 18: Využití propojeného datového fondu: | ||||
Služba | Použito | Č. žádosti o výjimku | Vysvětlení | Zákonné zmocnění k přístupu |
Čtení referenčních údajů FO (ROB) | Ano | Zákon č. 111/2009 Sb., § 5 odst. 5 | ||
Zápis nových FO (ROB) | Nerelevantní | |||
Editace referenčních údajů FO (ROB) | Nerelevantní | |||
Čtení referenčních údajů PO (ROS) | Ano | Zákon č. 111/2009 Sb., § 5 odst. 5 a § 61 odst. 1 | ||
Zápis nových organizací (ROS) | Nerelevantní | |||
Editace referenčních údajů PO (ROS) | Nerelevantní | |||
Čtení referenčních údajů míst a adres (RÚIAN) | Ano | Zákon č. 111/2009 Sb., § 30 odst. 1 a § 62 odst. 1 | ||
Zápis nových územních id. (RÚIAN) | Nerelevantní | |||
Editace referenčních údajů míst a adres (RÚIAN) | Nerelevantní | |||
Tabulka 18: Využití propojeného datového fondu: | ||||
Služba | Použito | Č. žádosti o výjimku | Vysvětlení | Zákonné zmocnění k přístupu |
Zápis a využití práv a povinností při využívání údajů agend (RPP) | Ano | Zákon č. 111/2009 Sb., § 51 odst. 8 | ||
Zápis rozhodnutí o změnách údajů agend dle § 52 zák. 111/2009 Sb. (RPP) | Nerelevantní | |||
Čerpání informací z agend jiných úřadů (Integrační platformy, eGSB) | Ano | Zákon č. 365/2000 Sb., § 9 odst. 5 a § 6g odst. 3 | ||
Poskytování informací agendám jiných úřadů (Integrační platformy, eGSB) | Ano | Zákon č. 365/2000 Sb., § 6g odst. 3 | ||
Tabulka 19: Využití dalších klíčových prvků eGovernmentu v byznys architektuře projektu: | |||
Název | Popis | Použito | Č. žádosti o výjimku |
Identifikace, autentizace úředníka | Identifikace osob vstupujících do procesu je řešena v souladu s JIP/XXXX | Ano, použito | |
Identifikace, autentizace klienta | Identifikace osob vstupujících do procesu je řešena v souladu se zákonem č. 250/2017 Sb., o elektronické identifikaci | Ano, použito | |
Doručování | Využití Datových schránek pro účely doručování od OVM soukromoprávním subjektům a mezi OVM navzájem | Ano, použito | |
Dodávání | Využití datových schránek pro účely dodávání mezi soukromoprávními subjekty navzájem | Ano, použito | |
Provádění úkonů | Využití Informačního systému datových schránek pro účely příjmu úkonů učiněných soukromoprávním subjektem vůči OVM (např. podání) | Ano, použito | |
Tabulka 20: Identifikace, autentizace a autorizace subjektů/uživatelů v jejich rolích: | ||
Služba využívající identifikaci, autentizaci a autorizaci | Vysvětlení způsobů identifikace, autentizace a autorizace | Použitý prostředek a druh autentizace |
Služby PVS – transakční části | Přístup s využitím jednoho z následujících způsobů (identifikaci a autentizaci upravuje § 6g odst. 3 zák. č. 365/2000 Sb.): • kvalifikovaný systém elektronické identifikace dle zák. č. 250/2017 Sb. (NIA) • autentizační služba ISDS (dle zák. č. 300/2008 Sb.) Autorizaci úkonů zajišťuje: • PVS v podobě souhlasu s učiněním konkrétního | V případě kvalifikovaného systému elektronické identifikace dle zák. č. 250/2017 Sb. (NIA) vyžadován prostředek s úrovní důvěry značná a vyšší. Využívá občan (obecně fyzická osoba vedená v ROB). V případě autentizační služby ISDS (dle zák. č. 300/2008 Sb.) přebírá PVS výchozí nastavení ISDS (připouští všechny |
Tabulka 20: Identifikace, autentizace a autorizace subjektů/uživatelů v jejich rolích: | ||
Služba využívající identifikaci, autentizaci a autorizaci | Vysvětlení způsobů identifikace, autentizace a autorizace | Použitý prostředek a druh autentizace |
úkonu (uchován např. v podobě hash kódů) • ISDS v případě vybraných úkonů realizovaných pomocí ISDS | prostředky). Využívá občan (obecně fyzická osoba vedená v ROB). | |
Služby PVS – informační části | Přístup s využitím jednoho z následujících způsobů (identifikaci a autentizaci upravuje § 6g odst. 3 zák. č. 365/2000 Sb.): • autentizační služba ISDS (dle zák. č. 300/2008 Sb.) • autentizace pomocí služeb XXXX v rámci JIP/XXXX Autorizaci úkonů zajišťuje: • PVS v podobě souhlasu s učiněním konkrétního úkonu (uchován např. v podobě hash kódů) • ISDS v případě úkonů realizovaných pomocí ISDS | V případě autentizační služby ISDS (dle zák. č. 300/2008 Sb.) přebírá PVS výchozí nastavení ISDS (připouští všechny prostředky). Využívá občan (obecně fyzická osoba vedená v ROB) nebo OVM. V případě autentizace pomocí služeb XXXX v rámci JIP/XXXX umožněna pouze vícefaktorová autentizace. Využívá OVM. |
Model byznys architektury (výkonu veřejné správy) – pohled činnostních funkcí
Neautentizovaný
uživatel
Fyzická osoba se
záznamem v ROB
Obecný uživatel
Transakční část PVS
Informační část PVS
Mobilní aplikace
Webový portál
Webový portál
Čtení z agendových
informačních systémů
Učinění podání / odeslání
formuláře
Upozorňování na termíny a
blížící se události
Založení datové schránky
Vyhledávání a procházení Vyhledávání a procházení Prezentace a procházení
katalogu služeb veřejné katalogu služeb v rámci design systému správy Jednotné digitální brány Ministerstva vnitra
Agenda A344 (Portál veřejné správy)
Agendy OVM
Čtení z agendových
informačních systémů
Přístup do portálu přes Učinění podání / odeslání Upozorňování na termíny a Založení datové schránky
mobilní aplikaci
formuláře
blížící se události
Vyhledávání a procházení Vyhledávání a procházení Prezentace a procházení
katalogu služeb veřejné katalogu služeb v rámci design systému správy Jednotné digitální brány Ministerstva vnitra
OVM
OVM
Fyzická osoba se záznamem v ROB
Model byznys architektury (výkonu veřejné správy) – pohled služeb veřejné správy
Neautentizovaný
uživatel
Obecný uživatel
Transakční část PVS
Informační část PVS
Mobilní aplikace
Webový portál
Webový portál
Čtení z agendových
informačních systémů
Učinění podání / odeslání
formuláře
Upozorňování na termíny a
blížící se události
Založení datové schránky
Vyhledávání a procházení Vyhledávání a procházení Prezentace a procházení
katalogu služeb veřejné katalogu služeb v rámci design systému správy Jednotné digitální brány Ministerstva vnitra
Agenda A344 (Portál veřejné správy)
Agendy OVM
Čtení z agendových
informačních systémů
Přístup do portálu přes Učinění podání / odeslání Upozorňování na termíny a Založení datové schránky
mobilní aplikaci
formuláře
blížící se události
Vyhledávání a procházení Vyhledávání a procházení Prezentace a procházení
katalogu služeb veřejné katalogu služeb v rámci design systému správy Jednotné digitální brány Ministerstva vnitra
OVM
OVM
Fyzická osoba se záznamem v ROB
Fyzická osoba se záznamem v ROB
Tabulka 21: Dodržení architektonických principů byznys vrstvy: | ||||
Princip | Požadavek | Dodrženo | Č. žádosti o výjimku | Způsob a míra naplnění |
Dostupnost | Řešíte obecně přístupnost a použitelnost pro klienty se zdravotním postižením? | Ano | ||
Řešíte přístupnost u webových stránek a rozhraní pro komunikaci s klientem? | Ano | |||
Bude každá nová nebo zásadně měněná služba či proces vnitřně plně elektronická? | Ano | Z principu ano, ale poskytovatel (gestor) služby může změnit vnitřní procesy na své straně, aniž by o tom správce PVS informoval, čímž může dojít k narušení principu. | ||
Bude možné učinit podání v plně elektronické podobě kdekoli (bez nutnosti následného dokládání papírových dokumentů) a | Ano | Ano, PVS umožňuje vyřizování agend pomocí formulářů elektronických podání. | ||
Tabulka 21: Dodržení architektonických principů byznys vrstvy: | ||||
Princip | Požadavek | Dodrženo | Č. žádosti o výjimku | Způsob a míra naplnění |
kdykoliv (kromě okamžiků nezbytné údržby systémů)? | ||||
Použitelnost | Budou všechny formuláře služeb v projektu předvyplněny všemi úřadu/státu známými údaji klienta (vlastními či z PPDF)? | Ano | U většiny údajů ano, ale toto závisí na skutečnosti, zda gestor AIS, který údaje eviduje, zpřístupní uvedený AIS správci PVS. | |
Bude klientům dostupná plná historie vzájemné komunikace s úřadem tak, aby byla využitelná pro opakované použití? | Ano | V případě komunikace s využitím PVS ano, ale PPDF není v současnosti v takovém stavu, aby mohla být klientovi zpřístupněna jeho kompletní historie zahrnující komunikaci všemi dostupnými kanály (např. vinou neexistence propojené eSSL). | ||
Důvěryhodnost | Bude zajištěno oboustranné garantované doručení a platnost elektronických dokumentů? | Ano | ||
Bude zajištěno průkazné doložení úkonů z minulosti? | Ano | |||
Transparentnost | Byl veřejnosti představen záměr a cíle projektu? | Ano | Rozsah a předmět plnění byly několikrát publikovány (články, vystoupení představitelů MV atp.). | |
Bude zajištěn přístup klientů ke všem svým řízením všemi dostupnými kanály eGovernmentu? | Ano | Kromě využití připojených digitálních nástrojů (ISDS, ISZR) lze většinu služeb vyřídit i osobně či korespondenčně (např. konverzí do PDF a vytisknutím či exportem podání). | ||
Spolupráce a sdílení | Byly (budou) do návrhu služeb v projektu zapojeny ve vzájemné spolupráci odborné týmy napříč veřejnou správou? | Ano | Vzhledem k tomu, že gestorem mnoha služeb na PVS jsou různá OVM, návrh, implementace a testování jsou realizovány ve spolupráci minimálně s týmem gestora služby. | |
Udržitelnost | Představuje-li projekt nové nebo zásadně pozměněné IT řešení, bude realizováno nad procesně aktualizovanými byznys službami úřadu? | Ano | Ano, jedná se o jeden z klíčových důvodů realizace tohoto projektu. | |
Tabulka 22: Vysvětlení v kontextu byznys architektury úřadu, tedy: |
a) jaké k projektu existují či vznikají duplicity a proč? |
Cílem projektu je další rozvoj jednotného místa, jehož prostřednictvím může občan využívat elektronické služby státu. Projekt nenahrazuje již existující řešení vybudované v rámci jednotlivých institucí, které poskytují elektronické služby veřejné správy a umožňují elektronická podání. Cílem projektu je vytvoření prostředí, které zastřeší stávající řešení jednotlivých institucí a umožní snadno publikovat nové elektronické služby dostupné z jednoho místa. V případě již existujících elektronických služeb bude PVS odkazovat na existující formuláře spolu s předáním přihlášení (single sign-on) z NIA na web či aplikaci úřadu. |
b) jaké jsou další souvislosti? |
PVS je rozvíjen komplementárně s dalšími portály a webovými aplikacemi. |
Vysvětlení byznys architektury projektu: |
Kromě vlastní agendy lze prostřednictvím PVS přistoupit k dalším agendám veřejné správy – PVS je v tomto smyslu součástí federace portálů a webových aplikací. |
2.2.4. Aplikační architektura (aplikací a dat)
2.2.4.1. Aplikační architektura – část: Architektura informačních systémů
Tabulka 23: Katalog všech aplikačních komponent řešení a klíčových aplikačních funkcí: | ||
Typ prvku | Název prvku | Vysvětlení významu aplikačních komponent, funkcí a služeb |
Komponenty, funkce a aplikační služby vytvářené nebo významně měněné v rámci záměru (žádosti) | ||
komponenta | Portál informační části | Portál informační části integruje mj. moduly (komponenty) využívané informační částí PVS. |
komponenta | Portál transakční části | Portál transakční části integruje mj. moduly (komponenty) využívané transakční částí PVS (neboli Portálem občana). |
komponenta | Administrátorský modul (upravený) | Modul zahrnuje funkcionality nezbytné pro správu a nastavení obsahu informační části PVS. |
komponenta | Katalog služeb veřejné správy | Vizualizační komponenta zajišťující vizualizaci katalogu služeb veřejné správy na informační části PVS. Vizualizační komponenta je součástí AIS RPP, nikoli PVS, a může ji využít kterýkoli portál či aplikace, který se připojí k veřejnému API AIS RPP. Vizualizační komponenta využívá design systém (xxxxxxxxxxxx.xxx.xx) k vykreslování katalogu služeb. Katalog služeb, resp. jeho obsah, je čerpán z AIS RPP Editačního, kde dochází i k samotné editaci katalogu služeb – na PVS probíhá pouze vizualizace katalogu s využitím vizualizační komponenty. PVS umožní navíc procházení a vyhledávání služeb v katalogu. Tatáž vizualizační komponenta zajišťuje též vizualizaci katalogu služeb Jednotné digitální brány (služby SDG jsou podmnožinou katalogu služeb VS a od ostatních služeb jsou odlišeny příznakem neboli zvláštním atributem, čerpají se zároveň taktéž z AIS RPP Editačního). Na rozdíl od ostatních služeb jsou překládány do angličtiny. |
komponenta | Notifikační modul (nový) | Modul zahrnující SMTP a SMS gateway pro notifikace uživatelů v rámci perimetru PVS v cloudu. V aplikacích eGovernmentu v perimetru PVS, jako je Portál občana, PVS a další, je využíváno napojení na SMS/SMTP bránu konkrétního poskytovatele, který byl vybrán ve veřejné soutěži. Případná změna tohoto poskytovatele znamená nutnost úpravy implementace a konfigurace každé z těchto aplikací. Pro zprostředkování SMTP a SMS komunikace bude vytvořeno řešení, založené na mikroslužbách a jejich správě pomocí kontejnerů. Cílem této mikroslužby je odstínění poskytovatele SMS/SMTP od jednotlivých aplikací. V případě výměny |
Tabulka 23: Katalog všech aplikačních komponent řešení a klíčových aplikačních funkcí: | ||
Typ prvku | Název prvku | Vysvětlení významu aplikačních komponent, funkcí a služeb |
poskytovatele se tak změní pouze implementace této mikroslužby a nikoli všechny ostatní aplikace. | ||
komponenta | Formulářový server (nový) | Centrální komponenta poskytující funkcionalitu chytrých interaktivních webových formulářů. Formuláře se dynamicky mění v průběhu vyplňování, poskytují průvodce, kontrolují a zobrazují výskyt chyb, provádí automatické doplnění do dovození hodnot v jednotlivých polích, poskytují nápovědu, spouští akce a procesy a odesílají data či část dat do cílových systémů. Formulářový server bude zatím využit pouze pro vybrané, složitější formuláře, jež lze rozdělit na dílčí komponenty (především se jedná o formuláře, kde tělo formuláře lze rozpadnout do několika tematických částí). Standard definice formulářů je postaven na XML standardu XForms, open source technologii Orbeon Forms a je kompatibilní s následujícími dílčími standardy: 1. podpora standardu XForms 1.1 s výjimkou některých částí, 2. částečná podpora standardu XForms 2.0, 3. podpora XQuery 1.0 a XPath 2.0 funkcí a operátorů (Second Edition), 4. rozšíření standardu XForms open source technologií Orbeon Forms, 5. rozšíření XPath 2.0 open source technologií Orbeon Forms, 6. podpora implementace vlastních formulářových prvků vycházející ze standardu XBL 2, 7. možnost přidat vlastní XPath funkce. Definice formuláře je tvořena dle standardů XForms a výše uvedených standardů a je uložena v jednom XHTML souboru, případně v dalších souborech do tohoto definičního souboru importovaných. Jedním z hlavních přínosů a požadavků na standard definice formulářů je, aby definice byla jednoduše přenositelná v souboru, případně více souborech, editovatelná standardními editačními nástroji, verzovatelná systémy, jako jsou SVN či GIT atd. Typicky je tedy definice formuláře vytvořena v rámci jednoho XHTML souboru vytvořeného dle standardů XML. Definice formuláře dle XForms v XHTML souboru de facto odráží základní architektonický vzor pro výstavbu aplikací MVC (Model View Controller). Dle tohoto vzoru je aplikace rozdělena na část datovou, část aplikační logiky a část prezentační. Podobným způsobem je rozdělena i definice formuláře v definičním XHTML souboru. Definice obsahuje: • Model – definice datového modelu formuláře a výstupního ÚEP souboru, • Kontrolér – definice logiky formuláře, provázání prezentační a datové vrstvy, • Prezentace – definice prezentační vrstvy formuláře. Základní struktura definičního souboru formuláře je následující: <xh:html xmlns:xh="xxxx://xxx.x0.xxx/0000/xxxxx" xmlns:xf="xxxx://xxx.x0.xxx/0000/xxxxxx"> <xh:head> |
Tabulka 23: Katalog všech aplikačních komponent řešení a klíčových aplikačních funkcí: | ||
Typ prvku | Název prvku | Vysvětlení významu aplikačních komponent, funkcí a služeb |
<xh:title>Titulek formuáře</xh:title> <xf:model> <!-- Definice datového modelu --> <xf:instance /> <!-- Definice logiky formuláře a vazeb mezi prezentační a datovou vrstvou --> <xf:bind /> </xf:model> </xh:head> <!-- Definice prezentační vrstvy formuláře --> <xh:body> </xh:body> </xh:html> | ||
komponenta | ISDS klient (upravený) | Umožňuje odesílání datových zpráv, pokud má klient datovou schránku a přeje si obdržet výstup služby prostřednictvím datové schránky. Zároveň slouží pro příjem dokumentů datovou schránkou. Nově zajišťuje i procesy spojené se založením datové schránky a automatickou archivací datových zpráv. Komponenta zajišťuje načtení zprávy klienta veřejné správy. Výsledek požadavku či podání je pak využitím této komponenty odeslán zpět klientovi veřejné správy. Automatická archivace datových zpráv: možnost automatické archivace všech datových zpráv, dodaných do datové schránky připojené k Portálu občana Uživatel bude mít možnost aktivovat si automatickou archivaci všech nově příchozích datových zpráv. V případě několika připojených datových schránek bude možné aktivovat si automatickou archivaci samostatně pro každou schránku. Vedle toho bude k dispozici možnost hromadné archivace příchozích datových zpráv. Uživatel ji provede ručně po přihlášení do Portálu občana a zobrazení přehledu zpráv. Uživatel si tak vždy bude moci vybrat variantu, která mu více vyhovuje. Založení datové schránky: Předmětem požadavku je umožnit uživateli – fyzické osobě, aby některé úkony týkající se datových schránek mohla provádět prostřednictvím dálkového přístupu z Portálu občana, tedy bez nutnosti návštěvy kontaktního místa Czech Point. Služba umožní uživateli zřízení následujících typů datové schránky na žádost: • Fyzická osoba – FO (40) • Podnikající fyzická osoba – PFO (30) |
komponenta | Portál design systému MV (xxxxxxxxxxxx.xxx.xx) | Úprava veřejně přístupného portálu design systému určeného pro občany a úřady. Portál obsahuje dílčí sekce, mimo jiné informační část pro klienty veřejné správy, úředníky, kontaktní místa a vývojáře. Primárním cílem je upravit design systém tak, aby splňoval nároky normy WCAG 2.1 pro úroveň AA (dále jen přístupnost AA) – a to jak web design systému samotný, tak jednotlivé komponenty a styly, které obsahuje, a příklady, které užívá. Současný design systém obsahuje příklady komponent, styly a další prvky, které nejsou v souladu s normou WCAG 2.1, |
Tabulka 23: Katalog všech aplikačních komponent řešení a klíčových aplikačních funkcí: | ||
Typ prvku | Název prvku | Vysvětlení významu aplikačních komponent, funkcí a služeb |
a tudíž nevyhovují požadavkům zákona č. 99/2019 Sb., o přístupnosti internetových stránek a mobilních aplikací a o změně zákona č. 365/2000 Sb., o informačních systémech veřejné správy a o změně některých dalších zákonů, ve znění pozdějších předpisů. Úpravy zahrnují především: • Úprava stylů barev – jedná se především o změnu barev design systému tak, aby odpovídaly pravidlům přístupnosti na úrovni AA. • Úprava barvy typografie na webu design systému – design systém definuje barvu textu odstín #3B3B3B, nicméně na webu je v různých textech použito více odstínů odstín #707070, #444444 aj. o Je tedy třeba sjednotit barvu textu na odstín #3B3B3B všude na webu. • Kontrola veškerých užitých příkladů v rámci všech komponent na přístupnost AA a případná úprava. • Výsledný design systém bude kompletně převeden do PDF, kdy bude moci plnit roli plnohodnotného manuálu. V úvodu tohoto PDF bude mj. uvedeno, že aktuální verze design systému je k dispozici | ||
komponenta | Mobilní aplikace | Nejedná se o klasickou hybridní mobilní aplikaci, ale zabalení webové aplikace Portálu občana do podoby nativní mobilní aplikace, s využitím technologie application wrapping, tedy bez nutnosti provádění změn v podkladové webové aplikaci. Tím dostaneme tzv. progresivní webovou aplikaci (tento způsob tvorby webových aplikací razí především společnost Google). Mobilní aplikace musí být vytvořena v souladu s požadavky a možnostmi dané platformy (Android, iOS), přitom je třeba vzít v úvahu, že uživatelé používají různé verze operačního systému. Aplikace může využívat specifické vlastnosti mobilních zařízení, jako je dotykové ovládání, otáčení zobrazení aplikace, zjišťování polohy pomocí GPS, pořizování fotografií apod. Aby ji uživatelé mohli používat, musí si aplikaci stáhnout pomocí obchodu s aplikacemi (Google Play nebo App Store) a nainstalovat na své zařízení. Způsob přihlášení bude jako u webové aplikace (zde se především předpokládá MEP v rámci NIA). Aplikační architektura Základním konceptem pro vývoj mobilní aplikace je již vytvořená architektura založená na mikro-službách organizovaných kolem jednotlivých back-endových funkcionalit, které Portál občana poskytuje. Tento přístup umožní napojení mobilní aplikace na existující API gateway. Využití technologie application wrapping zároveň znamená, že je možné použít front-end stávající webové aplikace. |
Tabulka 23: Katalog všech aplikačních komponent řešení a klíčových aplikačních funkcí: | ||
Typ prvku | Název prvku | Vysvětlení významu aplikačních komponent, funkcí a služeb |
Schéma aplikační architektury Požadavky na funkcionality Mobilní aplikace bude obsahovat veškeré funkcionality, nabízené webovou verzí Portálu občana. Nově bude doplněna funkcionalita push notifikací, která umožní zasílání krátkých oznámení a jejich zobrazování na displeji mobilního zařízení s nainstalovanou aplikací. Poznámka: Doplnění push notifikací bude mít dopad do webové verze Portálu občana, kde bude možné v nastavení notifikací zvolit mobilní aplikaci jako další kanál (vedle e-mailu a SMS). Další novou funkcionalitou bude správa zařízení, která uživateli umožní nastavovat mobilní zařízení, na kterých chce používat aplikaci Portálu občana. Fáze realizace Vývoj mobilní aplikace bude probíhat ve dvou na sebe navazujících fázích: 1. Vytvoření prototypu Prototyp bude sloužit k ověření progresivní webové aplikace Portálu občana a autentizace uživatele: • pro nejrůznější druhy zařízení (tablety, smartphony), • s běžnými operačními systémy (Android, iOS), • v různých rozlišeních displeje. Prototyp bude dostupný pouze na prostředí DEV. Postup vytvoření prototypu: • Vytvoření wrap (Xxxxxxx) • Přizpůsobení FE (PWA) • Odladění přihlášení (integrovaný prohlížeč vs. externí prohlížeč) • Mock notifikace • Test vložení do App Store a Google Play • Základní odladění pro iOS, Android • Test aplikace • Oprava vážných chyb 2. Vytvoření mobilní aplikace Finální verze mobilní aplikace bude vytvořena na základě výsledků testování prototypu. Bude doplněna správa zařízení a push notifikace. Může být upraveno chování aplikace v jednotlivých | ||
Tabulka 23: Katalog všech aplikačních komponent řešení a klíčových aplikačních funkcí: | ||
Typ prvku | Název prvku | Vysvětlení významu aplikačních komponent, funkcí a služeb |
funkcionalitách (např. použití interního nebo externího prohlížeče pro otevírání odkazů) nebo doplněny další potřebné funkcionality. Podpora mobilních zařízení Mobilní aplikace bude vytvořena tak, aby byla funkční na platformě: • Android – poslední 3 verze • iOS poslední 3 verze | ||
komponenta | eGSB adaptér (rozšířený) | Rozšíření využívání stávající komponenty: Komponenta je využívána k výměně údajů a jiných výstupů poskytovaných z informačních systémů veřejné správy. Při implementaci této služby vystupuje Portál občana v roli čtenáře údajů nebo adresáta výstupů z dalších informačních systémů – komunikace probíhá prostřednictvím rozhraní eGSB (v současné době takto Portál občana komunikuje s Registrem řidičů, Rejstříkem živnostenského podnikání a dalšími systémy). Pro toto rozhraní je již Portál občana připojen a má vyvinutou tzv. „čtenářskou aplikaci“, je však zapotřebí definovat tzv. čtenářský kontext (XML soubor) a upravit backend i frontend Portálu občana pro každé dílčí napojení. Větší díl práce spočívá na straně publikujícího subjektu, který si tyto práce sám hradí (jmenovitě musí vyvinout publikační aplikaci dle stanovených postupů, být připojen do Centrálního místa služeb, mít certifikát Správy základních registrů a připravit publikační kontext/datový prvek v XML vč. dokumentace). Dokumentace eGSB je k dispozici na xxxxx://xxx.xxxx.xx/xxxxxx/xxxxxxxxxxx- egsb.aspx. Předpokládá se připojení následujících systémů: • CEPAN: Centrální evidence přeplatků a nedoplatků spravovaná GŘC (Generálním ředitelstvím cel): Dlaždice bude poskytovat přístup k údajům z agendového informačního systému Centrální evidence přeplatků a nedoplatků (CEPAN), jehož agendami jsou: o A392 - Celnictví o A1722 - Správa spotřebních daní Pro publikaci dat na Portálu občana bude využit kontext určený pro čtenáře, kteří nejsou správci daně: o AXXX.1 – Dlužník Kontext dlužník je primárně určen pro zjišťování nedoplatků, druhu nedoplatků a platebních informací pro úhradu nedoplatků dlužníků. Identifikaci osoby dlužníka – uživatele Portálu občana lze provést podle AIFO nebo IČO. AIS následně dohledává údaje za oba typy subjektů (FO a PFO). Obrazovka bude složena z tematických částí (sekcí): o Vnitrostátní daně – obsahuje seznam nedoplatků subjektu za vnitrostátní daně o Clo / daně z dovozu – obsahuje seznam nedoplatků subjektu za clo/daně z dovozu o Exekuční řízení – obsahuje seznam exekučních řízení subjektu • Národní kontaktní místo pro elektronické zdravotnictví (NCP): Pro publikaci dat z NCP na Portálu občana prostřednictvím rozhraní eGSB budou využity kontexty: |
Tabulka 23: Katalog všech aplikačních komponent řešení a klíčových aplikačních funkcí: | ||
Typ prvku | Název prvku | Vysvětlení významu aplikačních komponent, funkcí a služeb |
o A4003.1 – Poskytovatelé zdravotních služeb – vrací seznam poskytovatelů zdravotních služeb, kteří vedou dokumentaci pro osobu žadatele o A4003.2 – Zdravotnická dokumentace pacienta – umožňuje stažení samotného dokumentu (pacientského souhrnu) od konkrétního poskytovatele předáním odkazu na soubor, který je získán službou gsbCtiSoubor Poskytovatelé zdravotních služeb nejsou Agendovými informačními systémy (AIS). Data publikuje NCP, který žádné zdravotní informace nevede a je pouze zprostředkovatelem mezi poskytovateli a PO. | ||
Ostatní komponenty, funkce a aplikační služby integrované na výše uvedené nebo jinak podstatné pro žádost | ||
komponenta | AIS OVM a další systémy | Poskytují údaje a výpisy do PVS. |
komponenta | AISEO | Agendový informační systém evidence obyvatel zahrnující i moduly kompozitních služeb. |
komponenta | Centrála Czech Point | Centrála Czech Point představuje orchestrační rozhraní zajišťující komunikaci s dalšími systémy VS (Rejstřík trestů, Centrální registr řidičů atd.). |
komponenta | eGSB | eGovernment Service Bus (eGSB), dle legislativního znění také Informační systém sdílené služby (ISSS), je unifikované rozhraní pro sdílení údajů mezi jednotlivými informačními systémy veřejné správy. |
komponenta | ISZR | Informační systém základních registrů |
komponenta | NIA | Národní identitní autorita |
Tabulka 24: Katalog aplikačních rozhraní (mezi dvěma různými komponentami A, B): | |||
Název aplikačního rozhraní | Komponenta A | Komponenta B | Vysvětlení obsahu a významu rozhraní aplikačních komponent |
Interní rozhraní (aplikací řešení mezi sebou, na aplikace uvnitř úřadu, případně resortu, krajské korporace, apod.) | |||
REST a SOAP API sdílených mikroslužeb | Sdílené mikroslužby | Integrační platforma | Rozhraní mikroslužeb umožňující modulům portálu komunikovat s mikroslužbami a využívat jejich funkcionality. |
REST API portálových služeb | Portálové moduly | Integrační platforma | Portálové aplikace zahrnují front-end část a back-end část. Back-end část je tvoře REST API. REST API je voláno z webové aplikace, či SPA (single page aplikace) portálu. |
SOAP/REST API integrační platformy | Integrační platforma | Formulářový server | Formulářový server bude využívat integrační platformu pro přístup ke sdíleným službám a mikroslužbám. |
Webové HTTPS rozhraní Formulářového serveru | Formulářový server | Klientský kód webové aplikace na stanici uživatele | Uživatelské rozhraní. |
Externí rozhraní (na aplikace eGovernmentu a jiných úřadů, případně jiná rozhraní) | |||
Tabulka 24: Katalog aplikačních rozhraní (mezi dvěma různými komponentami A, B): | |||
Název aplikačního rozhraní | Komponenta A | Komponenta B | Vysvětlení obsahu a významu rozhraní aplikačních komponent |
Webové služby eGSB | eGSB | Formulářový server, eGSB konektor | Integrační rozhraní pro napojení na eGSB (ISSS – Informační systém sdílených služeb), prostřednictvím kterého jsou integrovány vybrané kooperující systémy. |
Webové služby ISDS | ISDS | ISDS konektor | Webové služby systému ISDS (autentizační rozhraní, přístupové rozhraní a další služby). |
Webové služby ISZR | ISZR | eGSB, Formulářový server, ISZR konektor | Čtenářské webové služby Informačního systému základních registrů. |
Tabulka 25: Katalog aplikacemi podporovaných agend (vazební tabulka aplikací na katalog agendových funkcí v kapitole 2.2.3 - Byznys architektura): | |
Realizovaný systém | Agenda |
Portál veřejné správy | Agenda 344 (Portál veřejné správy) |
Portál veřejné správy | Agendy úřadů |
Model aplikační architektury
Trasakční část PVS
ru
Okolní systémy Veřejné správy
Poskytované služby
agendy A344
SOAP/REST API
integrační platformy
REST a SOAP API
sdílených mikroslužeb
Formulářový server (nový)
ISDS konektor (upravený)
Notifikační modul (nový)
Mobilní aplikace
Portál transakční části
Aplikace agendy A344
ISDS
eGSB
Centrála Czech Point
AISEO
NIA
ISZR
AIS OVM a další systémy
REST API portálových služeb
Webové HTTPS rozhraní Formulářového serve
Informační část PVS
Portál design systému MV
Katalog služeb veřejné správy
Administrátorský modul (upravený)
Portál informační části
Agendy OVM
Tabulka 26: Katalog komunikačních (obslužných) rozhraní, kanálů koncových klientů: | ||||
Rozhraní | Využití | Počet uživatelských přístupů ročně | Č. žádosti o výjimku | Popis využití rozhraní v projektu |
Asistovaná přepážka | ||||
Přepážka úřadu | Ne | Jedná se o samoobslužnou webovou službu. | ||
CzechPOINT (přepážka) | Nerelevan tní | Jedná se o samoobslužnou webovou službu. | ||
Tabulka 26: Katalog komunikačních (obslužných) rozhraní, kanálů koncových klientů: | ||||
Rozhraní | Využití | Počet uživatelských přístupů ročně | Č. žádosti o výjimku | Popis využití rozhraní v projektu |
Call-centrum | Ano | Stovky | Podpora na úrovni L1 zajišťována prostřednictvím služeb DCeGOV. | |
Webový portál | ||||
Aplikace v portálu úřadu s autentizovaným klientem | Ano | Statisíce | Klienti z řad veřejnosti Klienti z prostředí úřadu, typicky administrátoři PVS, využívají webového klienta a autentizují se prostřednictvím JIP/XXXX. Vlastní přihlášení do portálu využívá standard token based autentizace SAML 2. | |
Aplikace v Portálu občana jako střechovém portálu VS | Nerelevan tní | |||
Tlustý aplikační klient | Ne | Obslužné rozhraní je čistě webové. | ||
Mobilní aplikace | Ne | Dodávka součástí této zakázky. | ||
CzechPOINT@office | Nerelevan tní | |||
Datová zpráva (ISDS) | ||||
Formulář v DS | Ano | Desetitisíce | PVS umožňuje tento způsob komunikace. | |
Elektronicky podepsaný dokument do e-Podatelny | ||||
E-mail s elektronicky podepsaným formulářem | Ne | |||
Webová aplikace pro zaslání elektronicky podepsaného dokumentu do e- Podatelny | Ne | |||
Listinnou cestou do podatelny | ||||
Formulář listinou poštou | Ano | Stovky | Možnost vyplnění elektronicky, tisku a zaslání na podatelnu. | |
Formulář na listinnou podatelnu (osobně) | Ano | Stovky | Možnost vyplnění elektronicky, tisku a zaslání na podatelnu. | |
Jiné | ||||
E-mail s formulářem bez elektronického podpisu | Ne | |||
Aplikace v portálu úřadu s neautentizovaným klientem | Ne | |||
Aplikační rozhraní pro externí systémy | Ne | |||
Tabulka 27: Dodržení architektonických principů aplikační vrstvy: | ||||
Princip | Požadavek | Dodrženo | Č. žádosti o výjimku | Způsob a míra naplnění |
Použitelnost | Umožní design služeb i systému, v případě spolupráce úřadů na řešení životní situace/události klienta, řazení (orchestrování) do komplexního automatizovaného řešení? | Ano | Již v rámci původního návrhu PVS / Portálu občana. | |
Transparentnost | Počítá projekt s prostředky pro zveřejňování měření a auditů výkonnosti poskytovaných služeb? | Ano | Již v rámci původního návrhu PVS / Portálu občana. | |
Bezpečnost | Počítá projekt s auditovatelností a průkazností služeb veřejné správy a vytvářením auditní stopy (provozních logů) pro tento účel? | Ano | Již v rámci původního návrhu PVS / Portálu občana (napojení na DCeGOV, NÚKIB). | |
Udržitelnost | Byl upřednostněn nákup a implementace standardní služby před vývojem vlastního řešení? | Nerelevantní | Řešení je natolik specifické, že ho nelze považovat za standardní produkt. | |
Umožní otevřená modulární architektura projektu vyměňovat jednotlivé prvky řešení bez nutnosti měnit jejich okolí? | Ano | Již v rámci původního návrhu PVS / Portálu občana. | ||
Technologická neutralita | Budou elektronické služby veřejné správy v projektu dostupné na všech běžně používaných klientských platformách? | Ano | Je tak specifikováno v rámci návrhu a požadavků. | |
Tabulka 28: Vysvětlení v kontextu aplikační architektury úřadu, tedy: |
a) jaké k projektu existují či vznikají duplicity? |
V rámci projektu jsou realizovány byznys požadavky vzniklé z legislativních či strategických potřeb – je tedy možné, že aplikační řešení, která jsou implementována, již na trhu v nějaké obdobě existují (např. v případě připravované mobilní aplikace, která vychází z příkladů dobré praxe ověřené trhem). |
b) proč a jaké jsou další souvislosti? |
N/A |
Vysvětlení aplikační architektury projektu: |
Architektonický koncept Portálu občana se opírá o současné hlavní trendy vývoje softwaru, jeho testování, nasazování a provozu, které je možné shrnout pod pojmy: Kontinuální integrace a kontinuální dodávky softwaru. Tyto progresivní metody nutně vyžadují nový pohled na provozní a vývojová oddělení, kde je žádoucí těsnější spolupráce a porozumění mezi členy provozu a vývoje. Tento pohled dostal označení DevOps (z anglických slov Developers, tedy vývojáři a Operations, tedy provoz). DevOps jako jedno slovo naznačuje, že vývojáři i provoz infrastruktury tvoří jeden tým, který se podílí na společném cíli, a tím je kvalitnější software s kratším intervalem dodání v bezpečnějším prostředí. DevOps, jakožto nová kultura IT společností, pak není cílem, ale cestou, která závisí na důvěře, učení a rozvoji. Základním konceptem pro vývoj jsou mikro služby provozované a zorchestrované v kontejnerech za kooperace „infrastruktury jako kódu“. |
2.2.4.2. Aplikační architektura – část: Datová architektura
Tabulka 29: Katalog základních datových entit projektu: | ||
Objekt reálného světa, který je předmětem evidence | Vysvětlení objektu | Je objekt čerpán nebo poskytován jiným subjektům? |
Fyzická osoba | Objekt je persistentně evidován (uchováván) pouze na úrovni referencí do okolních systémů, tj. formou párů hodnot: cizí klíč – systém. Z povahy návrhu PO jsou konkrétní atributy (jméno, příjmení, narození…), popř. další vázané objekty (řidičský průkaz, list vlastnictví atp.) • čerpány na žádost dotčeného subjektu (přihlášeného občana), • „vlastněny“ dotčeným subjektem, • transientní, dotčený subjekt rozhoduje, komu / kdy / jak jsou předány, např. formou podání nebo jako identifikace do dalších systémů. | Je čerpán od jiného subjektu |
Zvolte položku. | ||
Zvolte položku. | ||
Tabulka 30: Využití datového fondu základních registrů a dalších agend: | |||
Název | Použito | Vysvětlení | |
Základní registry | |||
Způsob vedení datového kmene | Evidence jen identifikátoru (pseudonymu) a při potřebě zobrazení aktuální podoby referenčních údajů ze ZR | ||
Evidujeme subjekty práva, které nejsou vedeny v ZR (např. zahraniční) | Ne | ||
Evidujeme fyzické osoby, které nejsou vedeny v XXX | Xx | ||
Využití údajů publikovaných prostřednictvím kompozitních služeb editorů Základních registrů | |||
Evidence obyvatel (ISEO) | Ano | Údaje, které nejsou dostupné v ROB a které jsou zapotřebí pro vyplnění formuláře / dotazování do jiných AIS (rodné číslo). | |
Č. žádosti o výjimku: | |||
Cizinecký informační systém (CIS) | Nerelevantní | Konektor CIS je připraven, průběžně je řešeno. | |
Č. žádosti o | |||
Tabulka 30: Využití datového fondu základních registrů a dalších agend: | |||
Název | Použito | Vysvětlení | |
výjimku: | |||
eGon Service Bus | |||
Čerpání dat přes eGSB | Ano | ||
Č. žádosti o výjimku: | |||
Publikování vlastních dat přes eGSB | Nerelevantní | ||
Č. žádosti o výjimku: | |||
Tabulka 31: Způsob zajištění vedení dat s ohledem na otevřená data veřejné správy: | |||
Požadavek | Použito | Vysvětlení | |
Zajištění přístupu k datům | |||
Budete mít zajištěn přístup k veškerým datům vedeným v databázích dotčených předmětem projektu ve strojově čitelném a otevřeném formátu? | Ano | ||
Č. žádosti o výjimku: | |||
Budete mít výše popsaný přístup k datům zajištěn bez dodatečných finančních nákladů? | Ano | ||
Č. žádosti o výjimku: | |||
Budete moci se zpřístupněnými daty libovolně nakládat? | Ano | ||
Č. žádosti o výjimku: | |||
Publikace výstupů ve formátu otevřených dat | |||
Budou data vedená v databázích dotčených předmětem projektu zveřejňována jako otevřená data? | Ano | Statistické údaje. | |
Č. žádosti o výjimku: | |||
Jaké datové oblasti plánujete zveřejňovat jako otevřená data, kdy a na jakém stupni otevřenosti? | Statistické údaje. | ||
Tabulka 32: Nakládání s osobními a citlivými údaji | |
Způsoby identifikace subjektů (FO, PO) v informačním systému (AIFO, IČO, rodné číslo nebo jiný identifikátor) | |
AIFO, SePP, ID datové schránky, interní bezvýznamové identifikátory | |
Způsoby zavedení základních principů práce s osobními a citlivými údaji dle GDPR: | |
Zabezpečení zpracování: | Veškerá data vedoucí k identifikaci uživatele a jeho dokumenty jsou šifrovány. |
Právo na přístup: | PVS je na toto připraven, subjekt údajů tedy může uplatnit právo získat od správce potvrzení, zda osobní údaje, které se ho týkají, jsou či nejsou zpracovávány, a pokud je tomu tak, může uplatnit právo získat přístup k těmto osobním údajům a vybraným informacím. |
Tabulka 32: Nakládání s osobními a citlivými údaji | |
Právo na opravu: | PVS je na toto připraven, subjekt údajů tedy může uplatnit právo na to, aby správce bez zbytečného odkladu opravil nepřesné osobní údaje, které se ho týkají. S přihlédnutím k účelům zpracování může subjekt údajů uplatnit právo na doplnění neúplných osobních údajů, a to i poskytnutím dodatečného prohlášení. |
Právo na výmaz: | PVS je na toto připraven, subjekt údajů tedy může uplatnit právo na to, aby správce bez zbytečného odkladu vymazal osobní údaje, které se daného subjektu údajů týkají, a správce PVS má povinnost osobní údaje bez zbytečného odkladu vymazat, pokud je dán důvod v souladu s čl. 17 GDPR. |
Právo na omezení zpracování: | PVS je na toto připraven, subjekt údajů tedy může uplatnit právo na to, aby správce omezil zpracování, v kterémkoli z případů uvedených v čl. 18 GDPR. |
Právo na oznamovací povinnost: | Správce PVS je připraven plnit oznamovací povinnost v souladu s čl. 19. |
Právo na přenositelnost: | Exportem z DB do libovolného formátu a struktury. |
Tabulka 33: Dodržení architektonických principů datové vrstvy: | ||||
Princip | Požadavek | Dodrženo | Č. žádosti o výjimku | Způsob a míra naplnění |
Důvěryhodnost | Jakým způsobem zajistíte, aby vzájemně vyměňované informace byly spolehlivé, přesné, relevantní a aktuální a aby klienti elektronické komunikaci důvěřovali? | Ano | Budou využity zabezpečené komunikační kanály a certifikáty. | |
Bezpečnost | Jakým způsobem zajistíte, aby v projektu byla zajištěna adekvátní ochrana osobních údajů a utajovaných informací? | Ano | Budou aplikována veškerá vhodná opatření kybernetické bezpečnosti k zajištění integrity, důvěrnosti a dostupnosti. | |
Tabulka 34: Vysvětlení v kontextu datové architektury úřadu, tedy: |
a) jaké k projektu existují či vznikají duplicity? |
N/A |
b) proč a jaké jsou další souvislosti? |
N/A |
Vysvětlení aplikační architektury projektu: |
2.2.5. Technologická architektura – vrstva IT technologie (HW a SW)
Tabulka 35: Katalog uzlů a klíčových funkcí nebo služeb: | ||
Typ prvku | Název prvku | Vysvětlení významu uzlu, funkce nebo služby |
Technologická služba | Cloudová platforma | Technologická architektura vytvořená jiným subjektem. |
Zvolte položku. | ||
Model technologické architektury – pohled struktury IT technologické architektury
Tabulka 36: Využití sdílených IT technologických a platformových služeb: | ||
Název | Popis | Použito |
PaaS | Pronájem technologií v datovém centru externího subjektu | Od třetí strany |
DC eGOV | Využití centrálních prvků provozního a bezpečnostního monitoringu Dohledového centra eGOV (MV) | Ano |
Tabulka 37: Vysvětlení v kontextu technologické architektury úřadu, tedy: |
a) jaké k funkčnímu celku existují či vznikají duplicity? |
N/A |
b) proč a jaké jsou další souvislosti? |
N/A |
Vysvětlení technologické architektury funkčního celku: |
Předmětem projektu není řešení technologické architektury, je využíváno prostředí vytvořené jiným subjektem (cloudová platforma), které je dimenzované i pro provoz PVS. |
2.2.6. Technologická architektura – vrstva komunikační infrastruktury
Tabulka 38: Katalog infrastrukturních komunikačních funkcí, sítí, cest a klíčových služeb: | ||
Typ prvku | Název prvku | Vysvětlení významu infrastrukturních funkcí, sítí, cest a služeb |
Uzel | CMS | Centrální místo služeb. Je využito pro čerpání služeb eGSB (ISSS), DMZ, bezpečnostních služeb, přístupu k veřejnému internetu atd. |
Tabulka 38: Katalog infrastrukturních komunikačních funkcí, sítí, cest a klíčových služeb: | ||
Typ prvku | Název prvku | Vysvětlení významu infrastrukturních funkcí, sítí, cest a služeb |
Uzel | Cloudová platforma | Technologické prostředí v podobě cloudové platformy využívané k vytváření, hostování a škálování webových aplikací skrze datová centra. |
Komunikační síť | KIVS | Komunikační infrastruktura veřejné správy. Propojení cloudové platformy a perimetru CMS je zajištěno zabezpečeným způsobem, dle platných Provozních podmínek CMS a dokumentu Přehled služeb CMS. |
Lokace | Evropská unie | Lokalita datových center, kde je provozován PVS. |
Uzel | DCeGOV | Dohledové centrum eGovernmentu |
Komunikační síť | Veřejný internet | Veřejný internet |
Model technologické architektury – pohled struktury komunikační infrastruktury
Tabulka 39: Využití sdílených služeb komunikační infrastruktury: | |||
Název | Popis | Použito | Č. žádosti o výjimku |
CMS | Pro publikaci a přístup k vytvářeným službám je využito Centrální místo služeb – aplikace jsou publikovány prostřednictvím CMS | Ano | |
KIVS | Využití komunikační infrastruktury veřejné správy, tj. fyzického propojení infrastruktury úřadů nebo VPN připojení k CMS | Ano | |
NDC | Umístění technologií do Národních datových center v perimetru CMS | Ne | |
Housing (IaaS) | Využití umístění vlastní HW infrastruktury do prostor datového centra třetí strany | Ne | |
Tabulka 40: Vysvětlení v kontextu architektury komunikační infrastruktury úřadu, tedy: |
a) jaké k projektu existují či vznikají duplicity a proč? |
N/A |
b) jaké jsou další souvislosti? |
N/A |
Vysvětlení architektury komunikační infrastruktury projektu: |
2.2.7. Bezpečnostní architektura
Tabulka 41: Katalog bezpečnostní architektury projektu: | ||
Dotčený nebo bezpečnostní prvek | Hrozba / riziko | Vysvětlení způsobu zmírnění hrozby / rizika prvkem architektury |
Firewall | Napadení ISVS, nedostupnost | Správně nastavený a konfigurovaný FW zabrání hrubému útoku na aplikační a infrastrukturní komponenty. |
Reverzní proxy | Nedostupnost, ochrana důvěrnosti datových toků, ochrana webových serverů | Rozkládání zátěže, další úroveň ochrany webových serverů. |
Monitor integrity dat | Změna integrity dat | Změna datových souborů a konfigurací ISVS – narušení integrity – monitoring odhalí, notifikuje a aktivně chrání. |
WAF/Load balancer | Přetížení systému, ochrana před pokročilými hrozbami | Optimalizuje zatížení koncových obsluhovaných nodů. |
SIEM Sentinel | Výskyt anomálií a kritických stavů | V rámci centrálního monitoringu je prováděno aktivní vyhodnocování generovaných logů a je prováděna proaktivní ochrana ISVS. |
Antivirový systém | Napadení konfigurací systému a jeho dat, nedostupnost, cílená destrukce a zničení dat | Nasazením antivirového programu se sníží možnost nákazy. |
Zálohovací SW | Ztráta dat, dlouhodobá nedostupnost | Zálohováním se sníží riziko totální ztráty dat. |
Monitoring zranitelností | Technologické zranitelnosti zneužitelné pro narušení dostupnosti, integrity a důvěrnosti ISVS | Stálým (periodickým) monitoringem je sníženo riziko neřízeného výskytu chyb ISVS, které může způsobit IS zranitelným. |
XXX a session recording | Kritické neautorizované zásahy privilegovaných uživatelů, a jejich neřízený, bezdůkazní přístup | Řízení privilegovaných účtů a nahrávání pomocí komponenty SW řešení PIM a session recordingu. |
Tabulka 41: Katalog bezpečnostní architektury projektu: | ||
Dotčený nebo bezpečnostní prvek | Hrozba / riziko | Vysvětlení způsobu zmírnění hrozby / rizika prvkem architektury |
do ISVS | ||
Tabulka 42: Dodržení architektonických principů bezpečnostní architektury: | ||||
Princip | Požadavek | Dodrženo | Č. žádosti o výjimku | Způsob a míra naplnění |
Bezpečnost | Ochrání projekt prostředky poskytování elektronických služeb veřejné správy před poškozením a zneužitím? | Ano | Monitoring integrity dat, aktivní ochrana firewallem před napadením, monitoringy zranitelností a integrity, ochrana před zahlcením, resp. nedostupností (balancing). | |
Tabulka 43: Vysvětlení bezpečnostní architektury projektu: |
PVS je realizován a provozován v souladu se zákonem č. 181/2014 Sb. (zákon o kybernetické bezpečnosti) a vyhláškou č. 82/2018 Sb. (vyhláška o kybernetické bezpečnosti). Řešení zajišťuje odpovídající úroveň záruk pro elektronickou identifikaci, autentizaci a autorizaci uživatele včetně zajištění potvrzení projevu vůle k podání. PVS je nasazen do dvou geograficky oddělených datových center za účelem zajištění vysoké dostupnosti (Amsterdam, Dublin). Obě lokality jsou provozovány v režimu „active-active“, tj. obě lokality jsou schopné vyřizovat klientské požadavky. Fyzickou bezpečnost a bezpečnost síťové infrastruktury zajišťují správci datových center komerčního cloudu, ve kterých jsou provozovány technologické prvky. Prováděné transakce pomocí formulářů a další činnosti jsou logovány. Je prováděno pravidelné zálohování databáze. Jako kryptografické prostředky jsou používány soukromé klíče a komerční certifikáty pro zajištění šifrované komunikace SSL/TLS s klientskými stanicemi a napojenými AIS/ISVS vydávajícími výpisy a údaje. Průběžně je updatována bezpečnostní politika a dokumentace PVS a havarijní plány. |
2.2.8. Shoda s pravidly, standardizace a dlouhodobá udržitelnost
Tabulka 44: Uveďte, které licence standardizovaných SW produktů budete pořizovat formou centrálních rámcových smluv zajištěných Ministerstvem vnitra. Pokud tento instrument nevyužijete, vysvětlete proč: |
Nerelevantní. PVS takové licence nevyužívá. |
Tabulka 45: Shoda se strategickými dokumenty: | ||||
Požadavek | Odpověď | Č. žádosti o výjimku | Vysvětlení | |
Je řešení v souladu s Informační koncepcí úřadu? | Ano | |||
Je řešení v souladu s Informační koncepcí ČR a cíli či principy Digitálního Česka? | Ano | Který z následujících vybraných podcílů IKČR projekt naplňuje? | ||
☐ | Nemá vazbu na cíle IKČR | |||
☒ | 1.4 Rozvoj on-line „front-office“ služeb jednotlivých rezortů | |||
☐ | 1.5 Zlepšení národního katalogu otevřených dat | |||
☐ | 3.3 Digitalizace dosud nedigitalizovaného obsahu | |||
☐ | 3.4 Vytvoření prostředí pro dlouhodobé ukládání a archivaci digitálního (úředního) obsahu | |||
Tabulka 45: Shoda se strategickými dokumenty: | ||||
Požadavek | Odpověď | Č. žádosti o výjimku | Vysvětlení | |
☒ | 3.7 Zavedení systému důvěryhodné elektronické identifikace do praxe | |||
☐ | 3.8 Vytvoření základních služeb sdílení dat | |||
☐ | 5.7 Podpora budování sdílených agendových systémů v přenesené působnosti | |||
☒ | 5.9 Propojený datový fond | |||
☐ | 5.10 Veřejný datový fond | |||
☐ | 5.11 Geoinformace | |||
☐ | <jiný – popište> | |||
Je řešení v souladu s NAP? | NEPOVINNÉ | Ano | ||
Tabulka 46: Dodržení architektonických principů architektury shody s pravidly: | ||||
Princip | Požadavek | Dodrženo | Č. žádosti o výjimku | Způsob a míra naplnění |
Udržitelnost | Je řešení navrženo pro efektivní údržbu a rozvoj, tj. jako standardizované, rozšiřitelné, integrovatelné, upgradovatelné a podporovatelné i vlastními silami úřadu? | Ano | ||
Spolupráce a sdílení | Jsou nové služby (nebo jejich součásti) koncipovány jako opakovatelné a komplementární ke sdíleným službám eGovernmentu? | Ano | Existuje-li komponenta, která aspiruje na centrální sdílenou službu, je navrhována s tímto kontextem. | |
Udržitelnost | Je zajištěno, že je návrh byznys i IT řešení natolik robustní, modulární, škálovatelný, flexibilní a parametrizovatelný, aby se přizpůsobil očekávaným změnám za dobu jeho životnosti? | Ano | ||
Tabulka 47: Vysvětlení standardizace a udržitelnosti architektury projektu: |
Řešení je navrženo jako modulární a jeho komponenty na vzájemně integrované prostřednictvím rozhraní. Toto řešení umožní snadný provoz a rozvoj PVS včetně snadného přizpůsobování potřebám vzniklým v průběhu životnosti projektu. |
2.2.9. Přehled služeb čtyřvrstvé architektury
Model služeb v čtyřvrstvé vizi architektury veřejné správy nebo jednotlivé modely využití každé vrstvy vrstvou vyšší
• Informační diagram:
Portál informační části | ||
Administrátorský modul (upravený) | ||
Portál design systému MV | ||
Vyhledávání a procházení Vyhledávání a procházení
katalogu služeb veřejné katalogu služeb v rámci správy Jednotné digitální brány
Prezentace a procházení
design systému Ministerstva vnitra
Agendy OVM
Vyhledávání a procházení Vyhledávání a procházení
katalogu služeb veřejné katalogu služeb v rámci správy Jednotné digitální brány
Prezentace a procházení
design systému Ministerstva vnitra
Aplikační služby
Agendy OVM
Katalog služeb veřejné
správy
Technologické služby
Kubernetes Cluster
Webový portál
• Transakční diagram:
Mobilní aplikace | ||
ISDS konektor (upravený) | ||
Formulářový server (nový) | ||
Mobilní aplikace
Webový portál
Čtení z agendových
informačních systémů
Učinění podání / odeslání
formuláře
Upozorňování na termíny a
blížící se události
Založení datové schránky
Agenda A344 (Portál veřejné správy)
Čtení z agendových
informačních systémů
Přístup do portálu přes Učinění podání / odeslání Upozorňování na termíny a Založení datové schránky
mobilní aplikaci
formuláře
blížící se události
Webové HTTPS
rozhraní Formulářového serveru
Poskytované služby
agendy A344
Aplikace agendy A344
Portál transakční části
Notifikační modul
(nový)
Technologické služby
Kubernetes Cluster
REST API portálových služeb
Tabulka 48: Dodržení architektonických principů 4 vrstvé architektury: | ||||
Princip | Požadavek | Dodrženo | Č. žádosti o výjimku | Způsob a míra naplnění |
Technologická neutralita | Jsou odděleny jednotlivé vrstvy architektury řešení systémem služeb poskytovaných navzájem mezi vrstvami? | Ano | ||
Je zajištěna separátní správa, dohled a provoz služeb na jednotlivých vrstvách? | Ano | |||
Tabulka 49: Vysvětlení čtyřvrstvé architektury služeb projektu: |
Aplikační architektura je navržena tak, že jsou jednotlivé služby budovány z opakovaně použitelných služeb a mikroslužeb. Zároveň jsou striktně odděleny části front-end aplikací a back-end aplikací, přičemž integrace je realizována prostřednictvím definovaného API. Tak je možné v budoucnu plánovat rychlejší cyklus obnovy front-end částí aplikací a pomalejší plán rozvoje back-end. Zároveň architektura využívá hybridních cloudových služeb. |
2.3. Kontrola shody architektury řešení projektu se vzory sdílených služeb eGovernmentu
Tabulka 50: Kontrola shody architektury řešení projektu se vzory sdílených služeb eGovernmentu: | ||||
Název architektonického vzoru eGovernmentu | Byl dodržen vzor? | Č. žádosti o výjimku | Podrobný popis způsobu a míry dodržení vzorů návrhem řešení projektu | |
Centrální místo služeb | ||||
Publikujete aplikační služby řešené tímto projektem do CMS druhé generace? | Ano | PVS publikuje portálové řešení prostřednictvím služby CMS – 2.03: Zveřejnění aplikace a publikace do internetu. | ||
Přistupujete ke službám Propojeného datového fondu prostřednictvím CMS druhé generace? | Ano | |||
Jakým způsobem přistupujete do CMS druhé generace? | IPSec | |||
Univerzální kontaktní místo | ||||
Publikujete na CzechPOINT všechny své samoobslužné služby tak, aby mohly být přístupné i asistovaně? | Nerelevantní | PVS není určen pro asistované služby – jedná se o prostor s přístupem se zaručenou identitou, která v současnosti neposkytuje službu zastupování, mandátu či asistence. | ||
Jste na centrálu CzechPOINT připojeni skrze systém CMS? | Ano | |||
Máte služby CzechPOINT@office integrovány do svých systémů? | Nerelevantní | PVS je systém nezávislý na Czech Point@office a doplňuje ho. | ||
Budou všechny interní aplikace dostupné z intranetu úřadu/resortu? | Nerelevantní | PVS je systém přístupný přes webové rozhraní. | ||
Bude využito principu Single | Ano | |||
Tabulka 50: Kontrola shody architektury řešení projektu se vzory sdílených služeb eGovernmentu: | ||||
Název architektonického vzoru eGovernmentu | Byl dodržen vzor? | Č. žádosti o výjimku | Podrobný popis způsobu a míry dodržení vzorů návrhem řešení projektu | |
Sign-On? | ||||
ÚEP včetně eFakturace | ||||
Máte zajištěno předvyplňování formulářů ÚEP všemi státu známými údaji subjektu? | Ano | PVS vyplňuje formuláře vybranými údaji subjektu, ke kterým má přístup, ale technicky je připraven vyplňovat údaji ze všech ISVS. | ||
Máte zajištěn příjem a zpracování el. faktur? | Nerelevantní | |||
Elektronický systém spisové služby | ||||
Je realizace propojení systému se spisovou službou vytvořena dle rozhraní definovaného v kapitole 9 Národního standardu? | Nerelevantní | PVS není napojen na systém spisové služby ani to není legislativně vyžadováno. | ||
Informační systém datových schránek | ||||
Je prováděno automatické vytěžování přijatých formulářů do informačního systému? | Nerelevantní | PVS nepracuje s příchozími datovými zprávami ve svých evidencích. | ||
Propojený datový fond | ||||
Jste ke službám PPDF připojeni skrze CMS? | Ano | |||
Využíváte pro překlad identity mezi agendami služby ISZR? | Ano | |||
Využíváte pouze údaje, které máte explicitně uvedeny v daném zákoně? | Ano | Ano, přístup k údajům probíhá na základě poskytnutí údajů a poskytnutí nebo obstarání výstupů z ISVS s využitím prostředku pro elektronickou identifikaci umožňujícího přístup se zaručenou identitou (v souladu s 365/2000 Sb., § 6g odst. 3; dále 111/2009 Sb., § 5 odst. 5 a 101/2000 Sb.). | ||
Odebíráte na údaje PPDF notifikace skrze služby ISZR? | Ano | |||
Elektronická identita | ||||
Využíváte služeb Národního bodu pro identifikaci a autentizaci? | Ano | |||
Používáte pro překlad identifikátoru identity do své agendy (BSI na AIFO) služeb ISZR? | Ano | |||
Využíváte při obsazení identifikované a autentizované osoby do role úředníka systém JIP/XXXX? | Ano | |||
2.4. Plán projektu
Tabulka 51: Hrubý harmonogram předloženého projektu: | ||||
Fáze / milník | Začátek | Konec | Základní náplň | Navazuje na |
Fáze realizace, průběžného testování a nasazování | 07/2020 | 12/2020 | Implementace předložených funkcionalit a úprav | VZ „Rozvoj Portálu veřejné správy“ v roce 2019 |
do produkce | ||||
Tabulka 52: Projektový kontext předkládaného projektu (v rozvojovém programu, portfoliu úřadu): | |
Předchozí projekty | Popis návaznosti na předchozí projekty |
Pilotní fáze Portálu občana (VZ) | Pilotní aplikace v testovacím prostředí k ověření konceptu. |
Portál veřejné správy 2.0 – Portál občana (projekt IROP) | PVS 2.0 – PO představuje transakční část Portálu veřejné správy (PVS) v podobě moderního personalizovaného samoobslužného místa pro přístup ke službám veřejné správy. PVS 2.0 – PO nabízí možnost činit podání vůči vybraným orgánům veřejné moci (OVM) přímým způsobem, konkrétně prostřednictvím formulářů elektronického podání, a přístup k údajům z informačních systémů veřejné správy. |
Rozvoj PVS v roce 2019 | Předmětem projektu byl navazující rozvoj Portálu veřejné správy, informační a především transakční části (Portálu občana), konkrétně jeho rozšíření a úprava vybraných stávajících funkcionalit v návaznosti na platnou legislativu a záměry Strategie koordinované a komplexní digitalizace České republiky 2018+ (neboli Digitálního Česka). |
Souběžné projekty | Popis návaznosti na souběžné projekty |
Navazující projekty | Popis návaznosti na budoucí projekty |
Tabulka 53: Vysvětlení plánu projektu: |
02/2020: Investiční záměr projektu 03/2020: Znalecký posudek 03/2020: Oslovení potenciálního dodavatele a obdržení nabídky 04/2020: Obdržení kladného stanoviska PS pro transparentní veřejné zakázky 07/2020: Zpracování technického projektu / formuláře OHA 08/2020: Zaslání informace na vládu 09/2020: Podpis smlouvy s dodavatelem 09/2020: Zahájení vývojových prací 09-12/2020: Průběžné analýzy, návrhy, vývoj, testování, implementace 12/2020: Akceptace předmětu plnění |
3. D A L Š Í Ú D A J E O P R O J E K T U
3.1. Připravenost projektu k realizaci
3.1.1. Majetkoprávní vztahy projektu
Tabulka 54: Majetkoprávní vztahy: | ||
Podmínka | Odpověď | Poznámka (důvod) |
Budou vám udělena výhradní práva k užívání k dodávanému produktu? | Ano | Bude řešeno nákupem autorských děl a licencí, včetně zdrojových kódů. |
Budou vám udělena nevýhradní práva k užívání k dodávanému produktu? | Ne | |
Budou práva k autorskému dílu nějak omezena (XXX, konkrétní uživatel, převoditelnost a další šíření, úpravy produktu, parametry…)? | Ne | |
Budete mít přístup ke zdrojovému kódu pro čtení? | Ano | Ano – po dobu vývoje. Po předání s možností editace. |
Bude vám či třetímu subjektu umožněno provádět údržbu, měnit produkt, upravovat jej či rozšiřovat bez souhlasu dodavatele? | Ano | Ano – vlastními silami i třetími stranami. |
Budete mít přístup k aktuální technické dokumentaci produktu? | Ano | Ano – v rámci provozní smlouvy zajištěna pravidelná aktualizace dokumentace produktu ze strany dodavatele. |
Obsahuje budoucí smlouva ujednání o vyloučení odpovědnosti za výpadky fungování? | Ano | Ano – zajišťuje provozní smlouva. |
Budou externí nákupy veřejně soutěženy? | Ne | Realizovat bude NAKIT, s. p., v souladu se zákonem o zadávání veřejných zakázek jakožto zřizovaná organizace MV. |
3.1.2. Finanční připravenost projektu
Tabulka 55: Finanční připravenost: | ||
Druh financování | Odpověď | Popis zajištění, získání financování |
Ne | ||
Financování z vlastních zdrojů | Ano | Státní rozpočet |
Financování pomocí jiných externích zdrojů | Ne | |
3.1.3. Metodická připravenost projektu
Tabulka 56: Metodické připravenost: |
1 Evropské strukturální a investiční fondy
Metodické zajištění | Odpověď | Popis |
Řízení pomocí metodiky (uveďte název) | Ano | ITIL v4 |
Podpora od projektové kanceláře úřadu/resortu | Ne | Ne, zabezpečeno z vlastních personálních zdrojů. |
Podpora od architektonické kanceláře úřadu/resortu | Ano | Ano, zajišťuje odbor Hlavního architekta eGovernmentu MV. |
3.2. Ekonomické parametry projektu
3.2.1. Hodnota výdajů a ekonomická náročnost projektu
Hrubý odhad hodnoty záměru nákupu služeb či investic (externích výdajů), souvisejících s informačními a komunikačními technologiemi (projektu).
Tabulka 57: TCO: | |||
Souhrnná položka modelu TCO [Kč] bez DPH | ① Výdaje na realizaci (výstavbu) projektu | ② Výdaje na provoz a rozvoj (do konce aktuální smlouvy) | Vysvětlení k položce |
Počet měsíců trvání fáze | 5 | 0 | |
A. Předběžné analýzy (vč. rizik), tvorba zadání, výběr řešení, výběr dodavatele – náklady nákupního procesu | |||
B. Nákup SW a HW pro projekt (bez SaaS či PaaS) | <uveďte do tabulky 58 nebo samostatné přílohy rozpad výdajů, pokud výdaj přesahuje 10% celkové ceny projektu a současně přesahuje 1 mil. Kč> | ||
C. Analýza, finální projekt, vývoj, implementace, školení uživatelů, zkušební provoz a testy, případně i migrace dat a akceptační audit | 37 070 082,64 | <při jakékoliv částce uveďte do tabulky 58 nebo samostatné přílohy seznam rolí s počtem člověkodnů a cenu za člověkoden> | |
D. Provoz a podpora řešení HW a SW (bez SaaS či PaaS) | <uveďte do tabulky 58 nebo samostatné přílohy rozpad výdajů, pokud roční provoz a podpora přesahuje 20% celkové ceny řešení> | ||
E. Hardware/Software údržba a průběžné úpravy (bez SaaS či PaaS) | <uveďte do tabulky 58 nebo samostatné přílohy rozpad výdajů, pokud roční údržba a průběžné úpravy přesahuje 20% celkové ceny řešení> | ||
F. Projekty postupné inovace a zlepšování (plánované) | |||
G. Projekty upgrade (pokud jsou plánovány) | |||
H. Zvýšené náklady užívání řešení vč. nákladů na přechod z předchozího řešení (pokud se vyskytnou) | |||
Tabulka 57: TCO: | |||
Souhrnná položka modelu TCO [Kč] bez DPH | ① Výdaje na realizaci (výstavbu) projektu | ② Výdaje na provoz a rozvoj (do konce aktuální smlouvy) | Vysvětlení k položce |
I. Útlum, konzervace a ukončení řešení | <uveďte do tabulky 58 nebo samostatné přílohy rozpad výdajů, pokud útlum, konzervace a ukončení řešení přesahuje 10% celkové ceny řešení> | ||
X. Licence, HW, provoz, podpora, údržba, průběžný rozvoj - vše v subskripci (pouze SaaS a PaaS) | <uveďte do tabulky 58 nebo samostatné přílohy rozpad výdajů, pokud výdaj na SaaP a PaaS přesahuje 1 mil. Kč> | ||
Z. Ostatní nerozlišené režijní náklady | <uveďte do tabulky 58 nebo samostatné přílohy rozpad výdajů, pokud výdaj na nerozlišenou režii přesahuje 0,5 mil. Kč> | ||
Celkem | 37 070 082,64 | ||
Tabulka 58: Vysvětlení a komentář k souhrnu výdajů a ekonomické náročnosti projektu: |
Jedná se o investiční akci, resp. zhodnocení stávajícího informačního systému (PVS). Ke stanovení předpokládané hodnoty byl využit znalecký posudek, č. 3453-45/2020 („Příloha č. 1 – Znalecký posudek“). Výrok znalců byl následující (dle s. 40 přílohy č. 1): Otázka položená objednatelem znaleckého posudku: • Jaká je předpokládaná hodnota připravované vertikální spolupráce „Rozvoj portálu veřejné správy v roce 2020“ s ohledem na předpokládaný rozsah řešení a ceny kapacit v místě a čase obvyklé pro zajištění řešení? Odpověď znalce: • V případě, že objednatel vybere při rozvoji portálu veřejné správy v roce 2020 variantu s využitím stávajících formulářů (v rámci č. 6 písm. b) předmětu plnění), činí předpokládaná hodnota realizace 33.849.794,- Kč bez DPH s intervalem míry nejistoty stanovené zpracovatelem ± 20%. • V případě, že objednatel vybere při rozvoji portálu veřejné správy v roce 2020 variantu s využitím nových formulářů (v rámci č. 6 písm. b) předmětu plnění), činí předpokládaná hodnota realizace 38.222.444,- Kč bez DPH s intervalem míry nejistoty stanovené zpracovatelem ± 20%. V rámci projektu se počítá s realizací varianty č. 2, tedy s využitím nových formulářů, a to v maximální hodnotě spolupráce 37 070 082,64 Kč (jedná se o částku vyčleněnou v rozpočtu MV). Na základě výzvy byla MV zaslána státním podnikem NAKIT indikativní nabídka, která byla v oblasti předpokládané hodnoty v souladu se znaleckým posudkem. |
3.3. Analýza rizik projektu
Tabulka 59: Přehled klíčových identifikovaných rizik neúspěchu projektu: | ||
Označení rizika | Popis rizika | Opatření pro snížení rizika |
a) rizika během projektové přípravy: | ||
Tabulka 59: Přehled klíčových identifikovaných rizik neúspěchu projektu: | ||
Označení rizika | Popis rizika | Opatření pro snížení rizika |
Procesní riziko | Nedodržení podmínek interních procesů MV ČR | Členové realizačního týmu budou zodpovědní za konzistenci veškerého konání v rámci projektu v souladu s interními pravidly MV ČR. |
Procesní riziko | Dlouhé interní schvalování | Konzultovat návrh předběžně s ostatními věcnými útvary. |
Obecné riziko | Neschválení Vládou ČR | Pečlivě komunikovaný záměr. |
Technické riziko | Podceněno následné financování provozu a rozvoje | Dostatečně dimenzovat a předběžně alokovat finanční rozpočet. Při naplnění tohoto rizika by neměl být projekt vůbec realizován a měl by být zastaven a ukončen. |
Legislativní a technické riziko | Riziko vendor-lock-in efektu | Pečlivá příprava smluvních dohod. Stavba vybraných částí systému za využití open source. Uplatňování NAR/NAP a dalších standardů eGov ČR. |
b) rizika v průběhu realizace: | ||
Technické riziko | Dodatečné změny požadavků | Funkční i nefunkční požadavky na systém a jeho celková specifikace byly vytvořeny za spolupráce všech odpovědných osob na straně dodavatele i zadavatele. |
Technické riziko | Nedostatečná koordinace implementačních prací | Koordinaci implementačních prací bude zajišťovat věcný gestor a jeho realizační tým. Tito členové realizačního týmu budou zajišťovat dohled nad dodavatelem a vytvářet potřebné podmínky pro rychlou a kvalitní koordinaci. |
Technické riziko | Nedodržení stanoveného termínu dodání díla | Bude kladen důraz na preciznost formulace smluvních podmínek, včetně vyžadování kvality také u dílčích výsledků. Dodavatel bude vázán smlouvou, ve které budou dohodnuty sankce za případné nedodržení akceptačních kritérií řešení. Realizátor nadefinuje a bude udržovat aktuální harmonogram včetně požadované součinnosti definované v čase. |
Technické riziko | Nedodržení stanoveného termínu realizace projektu | Důsledné sledování plnění věcných a časových podmínek. Striktní nastavení a sledování harmonogramu akce. |
Technické riziko | Živelné pohromy | Bude nastaven systém zálohování a obnovy dat, vč. programového vybavení. |
Technické riziko | Zvýšení cen pořizovaných položek | Odhad ceny byl sestaven realisticky, i s ohledem na případné zvýšení cen relevantních jednotlivých položek akce. |
Technické riziko | Nekvalitní realizační tým | Členové realizačního týmu budou vybráni na základě své specializace, odbornosti a zkušeností. Budou to pracovníci, kteří mají přesně stanovené kompetence a odpovědnosti a na jejichž činnost dohlíží věcný gestor projektu. |
Technické riziko | Nedostatečná, nebo žádná součinnost stávajícího partnera | Analýza smluvních vztahů s dodavatelem a předběžné nastavení smluv tak aby současný dodavatel poskytl odbornou součinnost. |
Finanční riziko | Porušení rozpočtové kázně | Realizátor koncipoval rozpočet projektu dle rozpočtových pravidel ve spolupráci se správcem rozpočtu. |
Finanční riziko | Nedodržení interních finančních pravidel a jiných metodických pokynů MV | Realizátor úzce spolupracuje se správcem rozpočtu, který nese zodpovědnost za dodržování jednotlivých pokynů a metodik, včetně přípravy všech relevantních podkladů (předběžná řídící kontrola, rezervace finančních prostředků apod.). |
Právní riziko | Nedodržení pokynů pro zadávání v režimu vertikální spolupráce | Realizátor akce jakožto veřejný zadavatel má bohaté zkušenosti s realizací zadávacích řízení, řídí se platnou legislativou i vnitřními řídícími dokumenty, pro realizaci a zdůvodnění vertikální spolupráce. |
Právní riziko | Nedodržení právních norem | Realizátor se řídí platnou legislativou i vnitřními řídícími |
Tabulka 59: Přehled klíčových identifikovaných rizik neúspěchu projektu: | ||
Označení rizika | Popis rizika | Opatření pro snížení rizika |
ČR | dokumenty ve všech oblastech své činnosti. Realizátor bude úzce spolupracovat se specialisty na veřejné zakázky, aby byly splněny všechny požadavky dle zákona č. 134/2016 Sb., o veřejných zakázkách. | |
3.4. Plán zavedení, údržby, dlouhodobá udržitelnost výstupů projektu
Tabulka 60: Plánovaný ověřovací provoz (před akceptací) jednotlivých výstupů projektu: | |
Označení výstupu projektu | Plánovaná doba ověřovacího provozu výstupu [týden] |
Rozšíření PVS | Max. 4 týdny |
Tabulka 61: Plánovaná životnost jednotlivých výstupů projektu: | ||
Označení výstupu projektu | Plánovaná životnost výstupu [rok] | Popište plánované změny |
Rozšíření PVS | Nejméně 5 let | Upgrade, rozvoj, příp. legislativní změny. Čerpání a zobrazování všech zdrojů dat nově publikovaných a souvisejících s občany. Zvyšování uživatelské přívětivosti a komfortu na základě metod UX. |
Tabulka 62: Legislativní update: | |
Bude podpora zahrnovat rovněž udržování řešení v souladu s novými právními předpisy (tzv. legislativní update)? Vysvětlete v jakém rozsahu: | Jakým způsobem bude legislativní update hrazen? |
Žádné legislativní změny se nepředpokládají. V maximální možné míře bude vyžadováno, aby bylo možné provádět vybrané změny a parametrizaci na straně MV (např. tvorba nových formulářů). | Součást smlouvy o provozu a podpoře |
Tabulka 63: Jak je zajištěn další budoucí rozvoj předmětné oblasti a její ICT podpory: |
Jedná se o smlouvu na navazující rozvoj PVS, resp. informační a transakční části (Portálu občana, který se aktuálně nachází ve fázi udržitelnosti). Po ukončení smlouvy bude soutěžena / realizována návazná smlouva, jejíž součástí mohou být v případě potřeby rozsáhlejší úpravy systému, pokud to bude žádoucí. |
Tabulka 64: Jak je zajištěno řízené ukončení životnosti jednotlivých výstupů projektu a případný přechod na další řešení, či případná výměna dodavatele nad stejným řešením (tzv. Exit strategie)? |
Transakční část PVS (Portál občana) se aktuálně nachází ve fázi udržitelnosti, která následuje po vstupní investiční fázi, jež skončila 30. 6. 2019. Fáze udržitelnosti dle pravidel IROP trvá po dobu 5 let (plánovaná životnost portálu je však delší), tedy do roku 2024. Po tuto dobu bude zajištěna podpora provozu a případný rozvoj dle potřeb MV. MV má smluvně zajištěno postoupení oprávnění k výkonu majetkových práv autorských k dílu a toto oprávnění je dále postupitelné. Je-li autorským dílem počítačový program, vztahuje se postoupení ve stejném rozsahu na autorské dílo ve strojovém i zdrojovém kódu, jakož i na koncepční přípravné materiály. MV je oprávněno autorská díla i jejich části bez dalšího samo jakýmkoli způsobem užít v původní, zpracované či jinak změněné podobě a udělit třetím osobám oprávnění (licenci) k výkonu práva autorská díla a/nebo jejich část užít. MV je dále oprávněno jakoukoliv nehotovou anebo nedostatečně podrobnou část autorského díla dokončit a díla anebo jejich části zveřejnit, upravovat, zpracovávat včetně překladu, spojit s jiným dílem, zařadit |
Tabulka 64: Jak je zajištěno řízené ukončení životnosti jednotlivých výstupů projektu a případný přechod na další řešení, či případná výměna dodavatele nad stejným řešením (tzv. Exit strategie)? |
do díla souborného a uvádět je na veřejnost pod vlastním jménem. MV v rámci této VZ získá zdrojový kód každé jednotlivé částí díla (SW), který musí být spustitelný v prostředí MV a zaručující možnost ověření, že je kompletní a ve správné verzi, tzn. umožňující kompilaci, instalaci, spuštění a ověření funkcionality, a to včetně podrobné dokumentace zdrojového kódu. Toto platí jak pro implementaci díla, tak i pro záruční opravy a rozvoj. Bude-li součástí díla proprietární SW, MV získá nevýhradní oprávnění užít jej jakýmkoli způsobem na území České republiky a v množstevním rozsahu, který je nezbytný pro pokrytí potřeb MV po dobu účinnosti smlouvy. Vždy musí být předána kompletní uživatelská, administrátorská a provozní dokumentace. Bude-li součástí díla open source SW, je dodavatel povinen zajistit, aby se jednalo o open source software, který může být veřejnosti poskytován zdarma, včetně zdrojových kódů, úplné původní uživatelské, provozní a administrátorské dokumentace a práva takový software měnit. Udělení veškerých práv výše uvedených nelze ze strany dodavatele vypovědět a na jejich udělení nemá vliv ukončení účinnosti Smlouvy. Dodavatel odpovídá za jakoukoliv vadu díla či výstupů z plnění služeb rozvoje, jež se vyskytne v době trvání záruky, pokud není způsobena zaviněním MV z důvodu porušení jeho povinností. Dodavatel je odpovědný za to, že Servisní služby poskytne v souladu se Smlouvou, a že po dobu trvání Smlouvy budou mít dohodnuté vlastnosti, úroveň a charakteristiky. V případě nedodržení těchto povinností (SLA v době provozu, termíny a kvalita v době dodání díla apod.) jsou stanoveny ve smlouvě smluvní pokuty a slevy z ceny, přičemž celková výše smluvních pokut včetně slev z ceny nepřesáhne dvojnásobek soutěžené ceny díla. Odpovědnost dodavatele za škodu není limitována. MV nepředpokládá po dobu provozu nákup jiných služeb než smluvně zajištěných, tedy od dodavatele PVS. Následně bude probíhat výběr dodavatele servisních služeb a služeb rozvoje PVS pro další období dle aktuálně platných zákonů. |
4. V Y J Á D Ř E N Í K B E Z P E Č N O S T N Í M A S P E K T Ů M
Tabulka 65: Předkladatel prohlašuje, že předkládaný projekt bude realizován plně v souladu s níže uvedeným prohlášením: |
Text vyplňujte až na případnou výzvu OHA. |
5. U P O Z O R N Ě N Í A D O P O R U Č E N Í
Tabulka 66:Upozornění a doporučení: |
Komunikační linka mezi poskytovatelem cloudových služeb a Centrálním místem služeb: • Na základě výsledků jednání mezi zástupci OeG a OKB ze dne 3. 8. 2020 podá OeG žádost o prodloužení výjimky pro používání pre-shared keys (dále též „PSK“) pro rok 2021 v rámci komunikace s CMS. Zároveň bylo dosaženo shody, že nebude přistoupeno k využití ExpressRoute, a to jak z důvodů finančních, tak praktických, neboť na trase v současné době nedochází k latencím ani naplnění kapacitních možností. • Co se týče šifrování komunikace, pro uložení master šifrovacího klíče pro šifrování dokumentů je využívána služba MS Azure key vault (Thales HSM as a service FIPS 140-2 Level 2), která podléhá pravidelným auditům potvrzujícím nedostupnost šifrovacích klíčů ze strany poskytovatele cloudu (Microsoft) či amerických agentur a institucí (NSA). Každý uživatel má zároveň vlastní CEK (content encryption key) neboli symetrickou šifru AES-GCM (velikost klíče 256bitů). Tyto CEK nejsou v databázi v otevřené podobě, ale jsou šifrovány pomocí HSM a master klíče formou RSA 2048, tedy asymetrické šifry (privátní klíč nikdy neopouští prostředí HSM). • NÚKIB eviduje výše uvedené RSA 2048 jako dosluhující prostředek, správce PVS/PO bude proto po svém dodavateli požadovat migraci a změnu šifrování uživatelského klíče. Na následující rok je proto plánována migrace z RSA na eliptické křivky (ECC šifra), které poskytují stejné zabezpečení při menší velikosti klíče, přičemž celý proces je zároveň mnohem rychlejší (spotřebovává méně zdrojů systémů). |
6. P Ř Í L O H Y
Tabulka 67: Přílohy: | ||
Typ | Číslo a název přílohy | Upřesnění žádostí o výjimky/přílohy |
Dokumentace | Příloha č. 1 – Znalecký posudek | |
Dokumentace | Příloha č. 2 – Architektonický model | |
Celkový počet příloh: | 2 | |
Elektronický podpis - 24.8.2020 Certifikát autora podpisu :
Jméno : Xxx. Xxxx Xxxxxx
Vydal : PostSignum Qualified C...
Platnost do : 31.8.2020 15:42:22-000 +02:00
49