Formulář žádosti. o stanovisko Hlavního architekta egovernmentu k plánovanému ICT projektu typ A. Odbor Hlavního architekta egovernmentu MV

Formulář žádosti o stanovisko Hlavního architekta eGovernmentu k plánovanému ICT projektu – typ A

Odbor Hlavního architekta eGovernmentu MV

Praha, říjen 2016 verze 5.0

Obsah 1.

2.

3.

Základní podmínky projektu ................................................................................................................................. 3 1.1.

Úvodní informace o zpracovateli projektu ................................................................................................... 3

1.2.

Shrnutí charakteristik projektu .................................................................................................................... 3

1.3.

Potřebnost a výstupy projektu ..................................................................................................................... 3

1.4.

Právní klasifikace předmětu projektu .......................................................................................................... 4

Architektonické informace o projektu ................................................................................................................. 6 2.1.

Dodržení architektonických principů NA VS ČR............................................................................................ 6

2.2.

Enterprise architektura projektu a její kontext ............................................................................................ 6

2.2.1.

Motivační architektura - strategie a směrování .................................................................................. 6

2.2.2.

Efektivita projektu – výkonnostní architektura .................................................................................. 6

2.2.3.

Byznys architektura – poskytování veřejných služeb .......................................................................... 6

2.2.4.

Aplikační architektura (aplikací a dat)............................................................................................... 15

2.2.5.

Technologická architektura – vrstva IT technologie (HW a SW) ....................................................... 24

2.2.6.

Technologická architektura – vrstva komunikační infrastruktury..................................................... 28

2.2.7.

Bezpečnostní architektura ................................................................................................................ 32

2.2.8.

Shoda s pravidly, standardizace a dlouhodobá udržitelnost ............................................................ 32

2.2.9.

Přehled služeb čtyřvrstvé architektury ............................................................................................. 33

2.3.

Kontrola shody architektury řešení projektu se vzory sdílených služeb eGovernmentu ........................... 34

2.4.

Plán projektu .............................................................................................................................................. 34

Další údaje o projektu......................................................................................................................................... 36 3.1.

Připravenost projektu k realizaci ................................................................................................................ 36

3.1.1.

Majetkoprávní vztahy projektu (jen pro projekty zahrnující vývoj SW) ............................................ 36

3.1.2.

Finanční připravenost projektu ......................................................................................................... 36

3.1.3.

Metodická připravenost projektu ..................................................................................................... 36

3.2.

Ekonomické parametry projektu................................................................................................................ 37

3.2.1.

Hodnota výdajů a ekonomická náročnost projektu .......................................................................... 37

3.2.2.

Personální náročnost projektu .......................................................................................................... 38

3.3.

Analýza rizik projektu ................................................................................................................................. 38

3.4.

Plán zavedení, údržby, dlouhodobá udržitelnost výstupů projektu ........................................................... 39

4.

Vyjádření k bezpečnostním aspektům ............................................................................................................... 40

5.

Upozornění a doporučení ................................................................................................................................... 41

6.

Přílohy ................................................................................................................................................................ 42

2

1. 1.1.

Z Á K L A D N Í

P O D M Í N K Y

P R O J E K T U

Úvodní informace o zpracovateli projektu

Úvodní informace o zpracovateli projektu Organizace zpracovatele

Česko-moravsko-slezký kraj

Moravská 11 Morava 987 65

12345678

Ředitel pro informatiku nebo Statutární zástupce

František Bit

Ředitel IT

[email protected]

+420 147 258 369

Kontaktní osoba projektu

Eliška Projektová

ředitelka projektové kanceláře

[email protected]

+420 963 852 741

Architekt projektu

Břetislav Šubler

Podnikový architekt, Architektizmus CZ, a.s.

breta.subler@archi tektizmus.cz

+420 321 654 987

Datum vypracování žádosti:

1.2.

28.11.2016

Shrnutí charakteristik projektu

Shrnutí charakteristik projektu Název projektu:

Elektronizace výkonných agend úřadu

Hlavní cíl projektu:

Nasazení a provoz elektronizovaných verzí výkonných agend úřadu

Termín plánovaného zahájení realizace projektu (zahájení výstavby, je-li součástí):

31.8.2017

Termín plánovaného dokončení realizace projektu (uvedení do ostrého provozu):

29.9.2017

Termín plánovaného zahájení provozu (spuštění ostrého provozu):

31.10.2017

Termín plánovaného ukončení provozu (konec smluvního vztahu s dodavatelem):

30.11.2016

Předpokládaný počet let využívání výstupů projektu (počet let od začátku využívání víc než 5 do konce využívá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:

0

Komentář k výjimkám: Určení věcného správce, technického správce a provozovatele Věcný správce:

Petr Důsledný

Technický správce:

Marek Technický

Provozovatel:

Veronika Provozná

Aktuální (počáteční) plánované (rozpočtované) výdaje projektu (položka posledního řádku tabulky TCO v kapitole 3.2.1) v Kč bez DPH:

49 738 911

TCO 5 (součet sloupce 3 tabulky TCO v kapitole 3.2.1) v Kč bez DPH:

69 785 806

1.3.

Potřebnost a výstupy projektu

Výchozí stav – popis výchozí situace projektu: Na úřadě se veškeré dokumenty ukládají papírově, žádosti přicházející e-mailem se tisknou na papír a posléze jsou "papírově" zpracovávány. Popis projektu: Projekt přináší elektronizace služeb úřadu přístupných přes Portál Občana v souladu se seznamem předepsaných 3

životných situací. Pro usnadnění přístupu k Portálu Občanu jsou řízeny i Kiosky pro veřejnost v prostorech úřadu. Uvnitř úřadu projekt přináší elektronizaci služeb zejména v podobě bezpapírové kanceláře v spojení s řízeným životním cyklem oběhu především elektronických dokumentů, a to i řízenou dlouhodobou archivaci. Projekt přináší i elektronizace pracovního postupu workflow. V neposlední řade součástí projektu je i podpora nasazeného řešení. Přehled výstupů projektu: Označení výstupu

Množství a jednotka

Vysvětlení výstupu

Rozsah změny

Elektronizace agend

1ks informační systém

Systém zajišťující služby Portálu Občana.

Nový

bezpapírová kancelář

1 ks informační systém

Systém zabezpečující správu a řízený oběh elektronických dokumentů dle workflow s ohledem na životní cyklus, včetně řízení přístupu k jednotlivým dokumentům.

Nový

Workflow engine

1ks skupina informační systém

Kombinace Informačních systémů poskytujících služby vytváření, řízení a provozování elektronizovaného pracovního postupu (workflow) dle předepsaných regulí.

Nový

Elektronický archiv

50 TB archivační ho prostoru

Elektronický archiv zabezpečující povinné dlouhodobé uchovávání elektronických dokumentů s ohledem na délku předepsanou legislativou.

Nový

Kiosky na úřadu

5ks koncových stanic

Přístupový bod v podobě koncových stanic včetně potřebného softvérového vybavení, umožňující občanům elektronický přístup k Portálu Občana v prostorech úřadu.

Nový

technická podpora řešení

5 let

Zabezpečení technické a servisní podpory pro řešení.

Nový Zvolte položku.

1.4.

Právní klasifikace předmětu projektu

Klasifikace předmětu projektu dle zákonů eGovernmentu 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 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

Klasifikace dle zák. o kybernetické bezpečnosti

Významný informační systém

4

Vazba projektu na informace v Portálu veřejné správy Klasifikace Vyberte

Vysvětlete

Jsou na Portálu veřejné správy popsány všechny související životní situace v souladu s vyhláškou č. 442/2006 Sb.?

Ano

Informační systém Portál Občana plně zohledňuje zveřejněný seznam životných situací.

Bude k dispozici pro přístup občanů k el. službám úřadu využita navigace v Portálu veřejné správy?

Ano

Informační systém Portál Občana tuto požadavku svojí funkcionalitou zohledňuje.

Jsou na Portálu veřejné správy dostupné všechny formuláře využívané projektem?

Ano

Tenhle požadavekje splněn.

5

2.

A R C H I T E K T O N I C K É P R O J E K T U

2.1.

I N F O R M A C E

O

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ě, pakliže 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. 2.2.1.

Enterprise architektura projektu a její kontext Motivační architektura - strategie a směrování

Vysvětlete, proč projekt realizujete v této podobě a čeho jím chcete dosáhnout: Zefektivnění a rozšíření činností úřadu: -zvýšení dostupnosti služeb, -zkrácení času potřebného k vyřízení žádostí, -snadnější udržitelnost ve smyslu archivace dokumentů a dat, -zvýšení bezpečnosti řízeným oběhem dokumentů respektující jejich životní cyklus, -lepší prokazatelnost a auditovatelnost, -šetření našich lesů ve smyslu bezpapírovosti a elektronizace.

2.2.2.

Efektivita projektu – výkonnostní architektura

Vysvětlete dopad projektu na hospodárnost, účelnost, účinnost a kvalitu služeb v organizaci: Hospodárnost bude ovlivněna pozitivně přechodem elektronizaci a bezpapírovost. Projekt nemění účelnost služeb. Účinnost služeb pomocí elektronizace a řízeného workflow vzroste zkrácením doby požadované k vyřízení žádosti.. Kvalit služeb bude též zvýšena ve smyslu zvýšení jejich dostupnosti, a to zpětné dlouhodobé auditovatelnosti žádosti.

2.2.3.

Byznys architektura – poskytování veřejných služeb

Katalog organizačních jednotek, aktérů a rolí Název objektu

Počet uživatelů IS

Vysvětlení významu objektu

6

Název objektu

Počet uživatelů IS

Vysvětlení významu objektu

Aktér (organizace, organizační jednotky / úředníci, klienti veřejné správy) Úřad statutárního města

Statutární město je město, které má právo si svoji správu organizovat podle základní městské vyhlášky, která se označuje jako statut města. Statutární města v ČR se na rozdíl od ostatních měst, obcí a městysů mohou členit na dílčí samosprávné části, jež jsou vymezeny právě ve statutu dotčeného statutárního města

Úředník

Fyzická osoba, která pracuje ve veřejné správě, a jehož pracovištěm je úřad.

Role aktérů při výkonu a příjmu služby IT oddělení

IT oddělení úřadu.

Koordinátor OD

Role koordinátora Otevřených dat, jehož úkolem je proces publikování Otevřených dat.

Poskytovatel veřejných služeb

Město v roli poskytovatele veřejných služeb zajišťuje komunitní, sociální, správní a živnostenské služby.

Role poskytovatele Otevřených dat

Role poskytovatele Otevřených dat úřadem.

Správce LKOD

Role správce Lokálního katalogu Otevřených dat, jehož úkolem je udržování katalogu v chodu na Portálu občana.

Výkon podpůrných aktivit

Podpůrné aktivity jsou realizovány formou výkonu rutinních kancelářských činností.

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, dále neregistrované, podpůrné a provozní agendy nebo funkční oblasti) Agendy vykonávané statutárními městy

Soubor agend statutárních měst zaregistrovaných v RPP.

Funkce pro občana a veřejnost

Funkce portálu občana pro veřejnost pokrývající vnější funkcionalitu: vyhledávání a publikaci informací a příjem podání s vazbou na životní situace. Dále vnitřní funkce: pro ověření identity žadatele, doručování rozhodnutí, řízení oběhu dokumentů a správu, dohled a řízení oprávnění.

Poskytování Otevřených dat

Poskytování Otevřených dat je podpořeno legislativním rámcem: 

Strategický rámec rozvoje veřejné správy České republiky pro období 2014-2020 o



Akční plán České republiky Partnerství pro otevřené vládnutí na období let 2014 až 2016 o



Závazek č. 3 – Zpřístupnění dat a informací

Strategie rozvoje ICT služeb veřejné správy a její opatření na zefektivnění ICT služeb o



Specifický cíl 3.1 – Dobudování funkčního rámce eGovernmentu

Strategický cíl č. 5 – Od izolovaných dat k propojeným a otevřeným datům veřejné správy a ke kvalifikovaným rozhodnutím vedoucím k vyšší efektivnosti služeb VS

Akční plán boje s korupcí na rok 2016 (Akční plán boje s 7

Název objektu

Vysvětlení významu objektu korupcí na rok 2016 o 

Cíl č. 2 – Transparentnost a otevřený přístup k informacím

Státní politika v elektronických komunikacích „Digitální Česko v. 2.0, Cesta k digitální ekonomice“ o

Cíl 5.4. – Využívání informací veřejného sektoru

Procesy v agendách nebo funkčních oblastech "Papírová" autentizace

Proces ověření pravosti, kde posouzení pravosti je závislé na lidském faktoru (např. vrátný posoudí tvář osoby s fotografií na průkazce).

Elektronická autentizace

Plně elektronický proces ověření pravosti identity.

Proces publikování OD

Proces publikování Otevřených dat od výběru, přes čištění, anonymizaci, až po kontrolu a nahrání do katalogu.

Správa lokálního katalogu OD

Proces udržování lokálního katalogu Otevřených dat v chodu.

Funkce (činnosti) řazené v procesu nebo samostatně existující na podporu agend / funkčních obl. (NEPOVINNÉ) Autentizační funkce

Prokázaní pravosti (autentizace) identity pro entitu (osobu, informační systém, atd.) přistupující k aktivu.

Autorizační funkce

Přidělení (autorizace), úprava, nebo odebrání oprávnění osoby k aktivu.

Funkce auditu

Možnost zpětně dohledat a prokázat uskutečněný přístup k aktivu.

Funkce pro ověření identity žadatele a doručování rozhodnutí

Funkce pro jednoznačnou identifikaci osoby žadatele nebo jeho zmocněnce (vstup) a prokazatelné doručení rozhodnutí (výstup). V obou krocích se předpokládají a užívají kvalifikované nástroje (ePodpis, ePečeť, eČasovéRazítko) dle platného nařízení eIDAS

Funkce zajištění chodu úřadu

Podporné funkce klíčové pro chod úřadu.

Podpora kancelářských činností

Podpora kancelářských činnosti, které jsou zapotřebí k zajištění chodu úřadu.

Vyhledávání informací

Funkce pro snadné a intuitivní vyhledávání informací na portálu občana

Zveřejnění informací

Funkce pro publikaci životních situací s vazbou na katalog služeb úřadu.

Řízení přístupu a jeho zajištění

Agregační funkce zajištující bezpečnost ve smyslu řízení přístupu na úřadě, a to jak 

fyzickou,



elektronickou (počítačovou).

Katalog (interních a externích) služeb veřejné správy 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 8

Název služby

Kdo poskytuje službu

Kdo je konzumentem služby


Asset management Ekonomické a organizační služby Podpora kancelářských činností Property Management Služba administrace obsahu IAM Služba jednotného přihlášení a využití IAM Služba užívání a sdílení dokumentů v DMS Služba užívání a sdílení interních analytických informací Služba vedení finančního účetnictví Služby efektivního řízení, správy rizik a zajištění shody Služby Facility Managementu Služby finanční kontroly a výkaznictví Služby plánování a organizace Služby podpory provozu Služby poskytování IT 9

Název služby




služeb Služby správy majetku Služby vnitřní organizace procesů a práce s dokumenty Služby zajištění správy IT Služby zajišťování lidských zdrojů Služby řízení aktiv Služby řízení ICT Služby řízení zdrojů a změn Externí služby veřejné správy Služba poskytování neveřejných informací Služba poskytování veřejných informací Služba publikování vybraných informací z portálu úředníka Služba sdílení interních informací v rámci portálu úředníka Služba užívání informací a podání na portálu občana Služby rozvoje města 10

Název služby




Služby uzemního plánování Služby zajištění zpětné vazby Služby úřadu pro veřejnost Veřejné služby Zajištění oboustranné důvěry Zajišťování personalizovan é elektronicke služby

Využití front-office rozhraní předmětem projektu Rozhraní Využití Popis využití rozhraní v projektu Asistovaná přepážka Ano Vyškolený pracovník používá Portál Úředníka pro obsluhu. Webový portál Ano Občan používá Portál Občana pro kontakt s úřadem. Datová zpráva (ISDS) Ano Systém ISDS se využívá jak jeden ze vstupně-výstupních rozhraní do Workflow Portálu Úředníka. Elektronicky podepsaný Ano V celém rozsahu. dokument do e-Podatelny Listinnou cestou do Ano V celém rozsahu. podatelny Využití propojeného datového fondu Služba

Použito

Č. výjimky Vysvětlení

Zmocnění k přístupu

Čtení referenčních údajů FO (ROB)

Ano

-

Je použito pro informační systémy v projektu.

Právní předpis #101

Zápis nových FO (ROB)

Ano

-



Editace referenčních údajů FO (ROB)

Ano

-



Čtení referenčních údajů PO (ROS)

Ano

-



Zápis nových organizací (ROS)

Ano

-



Editace referenčních údajů PO (ROS)

Ano

-



Čtení referenčních údajů míst a adres

Ano

-

Je použito pro

Právní předpis #107. 11

Služba

Použito

Č. výjimky Vysvětlení

(RÚIAN)

Zmocnění k přístupu

informační systémy v projektu.

Zápis nových územních id. (RÚIAN)

Ano

-



Editace referenčních údajů míst a adres Ano (RÚIAN)

-



Zápis a využití práv a povinností při využívání údajů agend (RPP)

Ano

-



Zápis rozhodnutí o změnách údajů agend dle §52 zák. 111/2009 Sb. (RPP)

Ano

-



Čerpání informací z agend jiných úřadů Ano (Integrační platformy, eGSB)

-



Poskytování informací agendám jiných úřadů (Integrační platformy, eGSB)

-

-

-

Nerelevantní

Využití dalších klíčových prvků eGovernmentu v byznys architektuře projektu Název Popis

Použito

Č. výjimky

Identifikace, autentizace úředníka

Identifikace osob vstupujících do procesu je řešena v souladu s JIP/KAAS

Ano, použito

-

Identifikace, autentizace klienta

Identifikace osob vstupujících do procesu je řešena v souladu s Národním identitním schématem

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

-

Identifikace, autentizace a autorizace subjektů/uživatelů v jejich rolích Vysvětlení způsobů identifikace a autentizace, tj. ověření identity subjektů/ uživatelů v jejich rolí pro službu a informační systém: Identifikace žadatele probíhá dle použitého komunikačního kanálu osobně vyškoleným pracovníkem, resp. elektronicky vůči systému NIA.

12

Model byznys architektury (výkonu veřejné správy) – pohled činnostních funkcí

Model byznys architektury (výkonu veřejné správy) – pohled služeb veřejné správy

Dodržení architektonických principů Princip

Požadavek

Dodrženo

Dostupnost

Bude každá nová nebo zásadně Ano měněná služba či proces vnitřně plně elektronická?

Č. výjimky

Způsob a míra naplnění

-

Využívají se elektronizované služby kombinace Portálu Občana a Portálu Úředníka v kombinaci s Workflow a systémem pro zprávu dokumentů DMS. Samotná data 13

Princip

Požadavek

Dodrženo

Č. výjimky

Způsob a míra naplnění jsou ukládané v digitální podobě.

Dostupnost

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 kdykoliv (kromě okamžiků nezbytné údržby systémů)?

Ano

-

Služby vnitřně plně elektronické a umožňují úplné provozování bez jediného papíru.

Dostupnost

Budou na pobočkách úřadu k dispozici veřejné stanice (Kiosky) pro samoobslužná podání?

Ano

-

V rámci projektu bude zřízeno 5k Kiosků pro veřejnost v prostorech úřadu.

Použitelnost

Budou všechny formuláře Ano služeb v projektu předvyplněny všemi úřadu/státu známými údaji klienta?

-

Údaje jsou před-načítané z ISZR.

Použitelnost

Bude klientům dostupná plná historie vzájemné komunikace s úřadem tak, aby byla využitelná pro opakované použití?

Ano

-

Projekt realizuje dlouhodobé uchovávání žádostí včetně přístupu k nim.

Důvěryhodnost

Bude zajištěno oboustranné garantované doručení a platnost elektronických dokumentů?

Ano

-

Je realizované pomocí předepsaných komunikačních prostředků.

Důvěryhodnost

Bude zajištěno průkazné doložení úkonů z minulosti?

Ano

-

Systémy umožňují auditovatelnost vykonaných úkonů.

Transparentnost Byl veřejnosti představen záměr a cíle projektu?

Ano

Transparentnost Bude zajištěn přístup klientů ke Ano všem svým řízením všemi dostupnými kanály eGovernmentu? Spolupráce a sdílení

Byly (budou) do návrhu služeb Ano v projektu zapojeny ve vzájemné spolupráci odborné týmy napříč veřejnou správou?

Udržitelnost

Představuje-li projekt nové nebo zásadně pozměněné IT řešení, bude realizováno nad inovovanými byznys službami eGovernmentu?

Ano

Byly vyvěšené informační letáky na úřední desce včetně informativního videa ve vestibulu. -

Rozhraní byly vyvinuty pro standardně dostupné platformy. Bylo zapojené interní IT oddělení úřadu.

-

Ano, projekt zahrňuje i inovaci služeb.

Vysvětlení v kontextu byznys architektury úřadu, tedy jaké k projektu existují či vznikají duplicity a proč a jaké jsou další souvislosti: Úřad bude dostupný přes vícero nových komunikačních rozhraní pro komunikaci s úřadem ze strany občana.

14

Vysvětlení byznys architektury projektu: Použití řízeného pracovního prostupu (Workflow) s možností auditu omezuje množství reklamací a možných chyb způsobených procesními omyly.

2.2.4.

Aplikační architektura (aplikací a dat)

2.2.4.1.

Aplikační architektura – část: Architektura informačních systémů

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) Application Service

Aplikační služby portálu města

Zahrnuje veškeré aplikační služby, které slouží pro publikaci celého spektra informací vně úřadu a služby, jejichž prostřednictvím proudí informace a požadavky do úřadu.

Application Service

Autentizační služba

Autentizační služba Portálu občana pro ověření identity.

Application Component

Identity Access Management (IAM)

Je systém zahrnující administraci individuálních identit (uživatelských účtů) v rámci informačních systémů organizace. V prostředí organizace se správa identit týká zavedení a správy jednotlivých rolí a přístupových práv pro jednotlivé uživatele k interním IS prostřednictvím vnitřní sítě. Systémy identity dávají vedení úřadu a správcům IT nástroje potřebné k definici a kontrole přístupu uživatelů prostřednictvím aplikací ke všem uloženým datům organizace. IAM zajišťuje základní funkce v oblastech:    

Jednotného přihlášení (SSO) pro uživatele Integrace identit s Active Directory úřadu Integrace s dalšími IS úřadu (typicky Ekonomický, Majetkový, Agendový IS) Integrace na vnější subjekty zajišťující správu identit ve veřejné správě (typicky JIP/KAAS)

Application Service

Ověření identity osoby

Služba ověření identity osoby systémem IDM.


Portál občana

Pattern: Informační systém zajišťující všechny požadované aplikační funkce portálu občana. Dále portál občana úřadu nebo jeho podřízených organizací slouží pro zveřejnění katalogu Otevřených Dat, nabídku základních a/nebo pokročilých nástrojů pro jejich prezentaci, analýzu a interpretaci.

ORP: Vytváří jednotné prostředí pro publikaci: - povinně zveřejňovaných informací o výkonu přenesené působnosti a o výkonu samosprávy (úřední deska) - informací nepovinně zveřejňovaných informací (veřejnost a media) - o zřizovaných a příspěvkových organizacích (služby) - vybraných digitalizovaných datových zdrojů - informací o plánovaných aktivitách úřadu, novinek, odkazů apod.

15

Typ prvku

Název prvku

Vysvětlení významu aplikačních komponent, funkcí a služeb Podporuje elektronizaci agend prostřednictvím: - služeb elektronických formulářů - služeb elektronické rezervace času úředníka - služeb elektronické notifikace - aktivního žadatele, odběratele Zajišťuje a zabezpečuje: - komunikaci s okolím úřadu - ochranu zpřístupněných publikovaných digitálních dokumentů - integraci všech externích služeb na jednom místě (např. registr oznámení vedený u poskytovatele služeb - PVS nebo komerční subjekt)

STM: Portál občana tvoří aplikační komponenty:  Redakční systém webu (obsah)  Komponenta pro příjem podání (veřejnost)  Řízení publikace vnějších služeb úřadu (nabídka)  Povinně zveřejňované informace (deska)  Rezervační systém (asistence)  Informace pro veřejnost (statistika) Celý systém je doplněn modulem pro Řízení publikace služeb úřadu pro veřejnost, který ve spolupráci s interním modulem správy Katalogu celého úřadu nabízí funkce pro řízení celého životního cyklu služeb úřadu (podnět, analýza, návrh, realizace, test, publikace, provoz, kvalita, rozvoj a zrušení služby).

KRJ: Portál občana tvoří aplikační komponenty:  Redakční systém webu (obsah)  Komponenta pro příjem podání (veřejnost)  Řízení publikace vnějších služeb úřadu (nabídka)  Povinně zveřejňované informace (deska)  Rezervační systém (asistence)  Informace pro veřejnost (statistika) Application Service

Publikování OpenData

Služba publikování OpenData informačním systémem.

Zvolte položku. Ostatní komponenty, funkce a aplikační služby integrované na výše uvedené nebo jinak podstatné pro žádost Application Service

Adresářové služby domény

Doménové služby poskytované doménou Active Directory


Informační systémy městského úřadu

Uskupení vzájemně provázaných dílčích informačních systémů obce.


IS domény adresářových služeb

Informační systém Active adresářových služeb.


NIA

Národní identitní autorita - je českou implementací informačního systému typu eIDAS.

Zvolte položku. 16

Katalog aplikačních rozhraní: Název aplikačního Komponenta A rozhraní

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.) rozhraní domény adresářových služeb

Aplikační rozhraní domény adresářových služeb.

rozhraní IDM

Aplikační rozhraní systému IDM.

Externí rozhraní (na aplikace eGovernmentu a jiných úřadů, případně jiná rozhraní) Aplikační rozhraní systému eIDAS (Národní identitní autority).

rozhraní systému eIDAS (NIA)

Katalog aplikacemi podporovaných agend (vazební tabulka aplikací na katalog agendových funkcí v kapitole Byznys architektura) Realizovaný systém

Agenda

Identity Access Management (IAM) Portál občana

Model aplikační architektury – pohled struktury aplikací

17

Model aplikační architektury – pohled komunikace aplikací

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ě Asistovaná přepážka Přepážka úřadu Ano 700000

CzechPOINT (přepážka)

Ano

Call-centrum

Ano

Aplikace v portálu úřadu s autentizovaným klientem CzechPOINT@home

Ano Ano

500000 Č. výjimky: 200000 Webový portál 250000 150000 Č. výjimky:

Tlustý aplikační klient

Ano

75000

Mobilní aplikace

Ano

180000

CzechPOINT@office

Ano

Formulář v DS

E-mail s elektronicky podepsaným formulářem

-

-

Popis využití rozhraní v projektu

Rozhraní zůstává zachováno, pouze přibývají jeho elektronické prvky, jako je např. použití podpisových padů. Projekt plně zohledňuje využití rozhraní. Projekt zohledňuje využití rozhraní. Projekt plně zohledňuje využití rozhraní. Projekt plně zohledňuje využití rozhraní, kde na straně žadatele dochází k ověření jeho identity pomocí elektronického občanského průkazu v kombinaci s připojenou čtečkou karet. Projekt plně zohledňuje využití rozhraní tlustého klienta. Projekt plně zohledňuje využití rozhraní užitím běžných dostupných mobilních platforem. Projekt plně zohledňuje využití rozhraní.

130000 Č. výjimky: Datová zpráva (ISDS) Ano 180000 Projekt plně zohledňuje využití rozhraní systému ISDS. Č. výjimky: Elektronicky podepsaný dokument do e-Podatelny Ano 60000 Projekt plně zohledňuje využití rozhraní tohoto typu.

18

Rozhraní

Využití

Počet uživatelských přístupů ročně 25000

Webová aplikace pro zaslání elektronicky podepsaného dokumentu do e-Podatelny

Ano

Formulář listinou poštou

Ano

Listinnou cestou do podatelny 270000

Formulář na listinnou podatelnu (osobně)

Ano

160000

E-mail s formulářem bez elektronického podpisu Aplikace v portálu úřadu s neautentizovaným klientem Aplikační rozhraní pro externí systémy

Ano

Jiné 200000

Nerelevantní

-

Ano

5000

Popis využití rozhraní v projektu Projekt plně zohledňuje využití rozhraní.

Projekt plně zohledňuje využití rozhraní, kde po doručení listinné podoby žádosti je žádost skenováním digitalizována a dále její přenos/zpracování probíhá elektronicky. Projekt plně zohledňuje využití rozhraní, kde po osobním odevzdání je žádost skenováním digitalizována a její další přenos a zpracování probíhá elektronickou formou. Projekt plně zohledňuje využití rozhraní tohoto typu. Projekt neřeší tento způsob komunikace. Projekt plně zohledňuje využití rozhraní, bude publikován popis programovacího aplikačního rozhraní (API) pro externí webslužby.

Dodržení architektonických principů Princip Požadavek

Dodrženo Č. výjimky 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 klienta, řazení (orchestrování) do komplexního automatizovaného řešení?

Ano

-

Struktura a zpracování dat pomocí informačních systémů umožňuje orchestrovatelnost služeb.

Transparentnost

Počítá projekt s prostředky pro zveřejňování měření a auditů výkonnosti poskytovaných služeb?

Ano

-

Data budou zveřejněna mj. na webových stránkách úřadu.

Bezpečnost

Počítá projekt s auditovatelností Ano a průkazností služeb veřejné správy a vytvářením auditní stopy (provozních logů) pro tento účel?

-

Návrh struktury informačních systémů s ohledem na žurnálování umožňuje zpětnou auditovatelnost a dohledatelnou kontrolu provedených úkonů.

Udržitelnost

Byl upřednostněn nákup a implementace standardní služby před vývojem vlastního řešení?

Ano

-

Bylo provedeno soutěžení hotových řešení včetně vypracování odborných posudků.

Udržitelnost

Umožní otevřená modulární Ano architektura projektu vyměňovat jednotlivé prvky řešení bez nutnosti měnit jejich okolí?

-

Návrh struktury informačních systémů byl poveden s ohledem na jejich modulárnost.

Technologická neutralita

Budou elektronické služby veřejné správy v projektu dostupné na všech běžně používaných platformách?

-

Informační systémy zohledňují přístup z běžně dostupných platforem.

Ano

19

Vysvětlení v kontextu aplikační architektury úřadu, tedy jaké k projektu existují či vznikají duplicity a proč a jaké jsou další souvislosti: Informační systémy v kontextu úřadu přebírají ústřednou roli nosnosti správy, evidence, oběhu a uchovávání žádostí. Vysvětlení aplikační architektury projektu: Jádro projektu tvoří následující informační systémy: -DMS - uchovávání, správa a řízený oběh veškerých dokumentů, -PÚ - pracovní nástroj úředníka zohledňující definované pracovní postupy, -PO - pracovní nástroj pro přístup občanů k předdefinované množině pracovních postupů, -BPMS - nástroj pro procesní modelování a návrh pracovních postupů (workflow). 2.2.4.2. Aplikační architektura – část: Datová architektura Využití datového fondu základních registrů a dalších agend Název

Použito

Vysvětlení

Způsob vedení datového kmene

Evidence referenčních údajů s notifikací změn ze ZR

V projektu je použita varianta s notifikací změn z ZR.

Evidujeme subjekty práva, které nejsou vedeny v ZR (např. zahraniční)

Ano

Subjekty jsou vedeny v oddělené lokální databáze.

Základní registry

Evidujeme fyzické osoby, které nejsou Ano vedeny v ROB

Evidence je zabezpečená vyhrazeným lokálním systémem.

Využití údajů publikovaných prostřednictvím kompozitních služeb editorů Základních registrů Evidence obyvatel (ISEO)

Ano

Údaje jsou využity pro zpracování jednotlivých agend.

Č. výjimky: Cizinecký informační systém (CIS)

Ano Č. výjimky: -

Data z CIS jsou využity pro potřebu některých výkonných agend organizacemi zřizovaných městem.

Ano

Projekt uplatňuje v plném rozsahu čerpání dat z eGSB.

eGon Service Bus Čerpání dat přes eGSB

Č. výjimky: Publikování vlastních dat přes eGSB

Ano Č. výjimky: -

Katalog základních datových entit projektu: Objekt reálného světa, který je předmětem evidence

Projekt uplatňuje publikování vlastních dat úřadu přes eGSB.

Vysvětlení objektu

Aktivní datové zprávy

Databáze aktivních datových zpráv

Analytické datové objekty

Seznam datových objektů v OLAP a DWH

Byznys pravidla

Uložené byznys pravidla.

Centrální zdroj (úložiště) nestrukturovaných dat

Úložiště pro nestrukturovaná data.

Data dlouhodobého majetku a zásob

Data dlouhodobého majetku a zásob zajišťují operativní evidenci a odpisy majetku v rámci platných legislativních předpisů spojených s životním cyklem majetku.

Data na klientských stanicích

Data dislokovaná na klientských stanicích.

Data nákladového a manažerského účetnictví

Data nákladového, manažerského účetnictví a 20

Objekt reálného světa, který je předmětem evidence

Vysvětlení objektu controllingu slouží pro podporu strategického, taktického i operativního řízení organizací prostřednictvím propojení nefinančních a finančních informací o hospodaření úřadu nebo i zřizovaných organizací.

Data o příjmench, výdajích, pohledávkách a závazcích

Data o příjmech a pohledávkách obsahují evidenci a zpracování všech pohledávek organizace s kontrolou vymáhání nezaplacených pohledávek, penalizace při prodlení a přepočtu výše pohledávek. Evidence dat o zpracování všech závazků organizace s kontrolou rozpočtových prostředků a disponibilních prostředků na účtech.

Data o zaměstnancích

Evidenční, osobní, dovednostní, mzdová a hodnotící data o zaměstnancích.

Data rozpočtu, účetnictví a výkaznictví

Jedná se o rozpočtová data a jejich změny při čerpání. Z těchto dat se rovněž tvoří požadované výstupy definované legislativou a jednotlivé požadavky na uživatelské výstupy.

Datové kostky

Data uložená v hvězdicovém tvaru

Datové tržiště 1: Geografie a demografie

Příklad datového tržiště

Datové tržiště 2: Ekonomika a Majetek


Datové tržiště 3: Výkony agend SM


Datové úložiště analytického serveru

Data OLAP

Datové úložiště datového skladu

Data DWH

Dimenze

Úhel pohledu na zkoumaná data

DM4: Školství a Zdravotnictví


Dříve doručené datové zprávy

Databáze dříve doručených datových zpráv

Evidence aktiv Externí parametry, podmínky, pravidla (SLA) Fakta

Předmět analýzy

Instance procesů

Uložené instance procesů.

Interní parametry, podmínky, pravidla (OLA) Katalog služeb Katalog vnějších služeb úřadu

Datový objekt obsahující část katalogu služeb určený pro publikaci na portálu občana

Konfigurační data Kvalifikované prostředky zaměstnanců úřadu pro ePodpis

Certifikát zaměstnance organizace od poskytovatele kvalifikovaných služeb el. identity.

Kvalifikované prostředky úřadu pro tvorbu ePečetě

Certifikát organizace od poskytovatele kvalifikovaných služeb el. identity.

Loader

Perzistentní data o nastavení datových pump

Log dávky

Výstupy logovacího modulu. 21



Metadata

Data o datech

Metadata komunikace

Uložené metadata komunikace.

Množina aplikačních služeb Množina byznys služeb Množina infrastrukturních služeb Množina technologických služeb Odchylky

Zkalkulované odchylky

Offline formulář

Datový objekt formuláře, se kterým klient pracuje offline po předchozím stažení

Online formulář

Datový objekt formuláře, se kterým klient pracuje online po autentizaci pomocí identity providera

Online formulář

Datový objekt formuláře, se kterým klient pracuje online po autentizaci pomocí identity providera

Operation Data Store

Operační úložiště dat

Oprávnění přístupu

Matice oprávnění

Organizační struktura

Záznam organizační struktury sloužící jako zdroj i cíl dat pro práci modulu Workflow systémů.

Plánovač

Data o časovém zpracování

Pravidla datového úložiště

Uložená pravidla

Pravidla čištění dat

Uložené postupy jak se čistí zdrojová data

Procesní modely

Uložené procesní modely.

Procesy, pravidla, kontroly, legislativa

Datové entity pro uložení informací o procesech, pravidlech, kontrolách a legislativě

Reportovací datové objekty

Datové objety pro tvorbu reportů

Rizika, ošetření, KRI

Datové entity obsahující informace o rizicích, cílech, politikách a ukazatelích rizik

Sdílené úložiště (CMS)

Datová komponenta pro zajištění, sdílení řízení datového obsahu portálu úředníka (CMS - Content Management System)

Soubory s modely Stage Area

Zóna pro sběr dat

Strategie, cíle, politiky, KPI

Datové entity obsahující informace o strategiích, cílech, politikách a ukazatelích výkonnosti

Tickety Transformační pravidla

Data určující trasformaci vstupů na výstupy

Trendy

Trendy ukazatelů

Události a incidenty Ukazatele

Sledované a vyhodnocované metriky

Zdroje dat

Seznam zdrojů dat

22



Úložiště ETL nástroje

Data ETL

Úložiště WF

Datový objekt zajišťující perzistenci definice toku pracovních činností i jejich všechny proběhlé instance

Číselník pracovních míst

Číselník pracovních míst sloužící jako zdroj i cíl dat pro práci modulu Workflow systémů.

Číselníky a rejstříky

Data číselníků a rejstříků pro interní užití a správu externích registrů.

Životní situace osob

Datový objekt obsahující hierarchicky uspořádané životní situace žadatelů, které úřad pokrývá buď asistovanými nebo samoobslužnými službami, definovanými v katalogu vnějších služeb úřadu. Datové úložiště popisující jednotlivé životní situace.

Publikování výstupů v podobě otevřených dat: Plánujete publikovat část datové základny projektu jako otevřená data?

Ano Č. výjimky:

Jaké datové sady plánujete publikovat?

-

Termíny zakázek údržby pouličního osvětlení a sekání trávníků.

Způsoby identifikace dat FO v Agendovém IS ( AIFO, rodné číslo nebo jiný identifikátor) či míra využití pseudonymizace (dle GDPR): Bude použita kombinace uvedených včetně pseudonymizace. Dodržení architektonických principů Princip Požadavek

Dodrženo Č. výjimky Způsob a míra naplnění

Důvěryhodnost

Jakým způsobem zajistíte, aby Ano vzájemně vyměňované informace byly spolehlivé, přesné, relevantní a aktuální a aby klienti elektronické komunikaci důvěřovali?

-

Dodržení pravidla bude zaručeno pomocí procesních zámků nad transakcemi, a to včetně push notifikace do všech otevřených transakcí změn.

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í?

-

Uložená data budou šifrována užitím algoritmů symetrického šifrování s délkou klíče 512bitů. Mimo to úložiště dat budou fyzicky zabezpečena. Veškeré přístupy k nim jsou auditovatelné.

Ano

Vysvětlení v kontextu datové architektury úřadu, tedy jaké k projektu existují či vznikají duplicity a proč a jaké jsou další souvislosti: Data z jednotlivých i dosavadních "papírových" rozhraní se elektronizují a uchovávají v digitální podobě. Vysvětlení k datové architektuře projektu: Data jsou elektronizována a uchovaná v zašifrované podobě v normalizované formě, takže při jejich ukládání nedochází k duplicitě.

23

2.2.5.

Technologická architektura – vrstva IT technologie (HW a SW)

Katalog uzlů a klíčových funkcí nebo služeb: Typ prvku

Název prvku

Vysvětlení významu uzlu, funkce nebo služby

Infrastructure Service

Akceptace provozních Akceptace provozních podmínek CMS podmínek CMS


Bezpečné připojení


Node

Bezpečný datový úložný prostor a výpočetní výkon pro komponenty eIDAS

Na úrovni modelu EA nelze blížeji specifikovat. Nutno vyspecifikovat výkonové a objemové parametry na základě provedeného sizingu, ale až ve fázi detailního návrhu SA.


Běhové prostředí

Služby běhového prostředí.


Databázové služby

Služby ukládání dat v databázích.

Node

Datový zdroj a výpočetní výkon pro FM

Nezbytná infrastruktura, která bude definována až ve fázi datilního návrhu.

Node

Datový zdroj a výpočetní výkon pro konfigurační databázi


Node

Datový zdroj a výpočetní výkon pro monitorovací systém


Node

Datový zdroj a výpočetní výkon pro Portál občana


Node

Datový zdroj a výpočetní výkon pro Portál úředníka


Node

Datový zdroj a výpočetní výkon pro SAM software


Node

Datový zdroj a výpočetní výkon pro Sevice desk


Node

Datový úložný prostor Na úrovni modelu EA nelze blížeji specifikovat. Nutno a výpočení výkon pro vyspecifikovat výkonové a objemové parametry na základě provedeného sizingu, ale až ve fázi detailního návrhu SA. běh BPMS

Node

Datový úložný prostor Na úrovni modelu EA nelze blížeji specifikovat. Nutno a výpočení výkon pro vyspecifikovat výkonové a objemové parametry na základě provedeného sizingu, ale až ve fázi detailního návrhu SA. běh GRC

Node

Datový úložný prostor Na úrovni modelu EA nelze blížeji specifikovat. Nutno vyspecifikovat výkonové a objemové parametry na základě 24

Typ prvku

Název prvku a výpočení výkon pro běh IAM

Vysvětlení významu uzlu, funkce nebo služby provedeného sizingu, ale až ve fázi detailního návrhu SA.

Node

Datový úložný prostor DNa úrovni modelu EA nelze blížeji specifikovat. Nutno a výpočení výkon pro vyspecifikovat výkonové a objemové parametry na základě běh IS Správy majetku provedeného sizingu, ale až ve fázi detailního návrhu SA.

Node

Datový úložný prostor Na úrovni modelu EA nelze blížeji specifikovat. Nutno a výpočení výkon pro vyspecifikovat výkonové a objemové parametry na základě provedeného sizingu, ale až ve fázi detailního návrhu SA. běh PIS

Node

Datový úložný prostor Na úrovni modelu EA nelze blížeji specifikovat. Nutno a výpočení výkon pro vyspecifikovat výkonové a objemové parametry na základě provedeného sizingu, ale až ve fázi detailního návrhu SA. ERP

Node

Datový úložný prostor Na úrovni modelu EA nelze blížeji specifikovat. Nutno a výpočetní výkon pro vyspecifikovat výkonové a objemové parametry na základě provedeného sizingu, ale až ve fázi detailního návrhu SA. CASE nástroj

Node

Datový úložný prostor Na úrovni modelu EA nelze blížeji specifikovat. Nutno a výpočetní výkon pro vyspecifikovat výkonové a objemové parametry na základě provedeného sizingu, ale až ve fázi detailního návrhu SA. DMS

Node

Datový úložný prostor Na úrovni modelu EA nelze blížeji specifikovat. Nutno a výpočetní výkon pro vyspecifikovat výkonové a objemové parametry na základě provedeného sizingu, ale až ve fázi detailního návrhu SA. provoz Datového skladu a Manažerského IS

Node

Disková virtualizace

Obsahuje logické komponenty pro ukládaní dat aplikací - virtuální diskové prostory (VDE), které jsou navázány prostřednictvím Virtualizačního software na SAN infrastrukturu.


do CMS

do CMS


do Internetu

do Internetu


do S-TESTA

do S-TESTA

Node

Fyzické aplikační servery

HW aplikačních serverů (CPU, RAM, I/O) optimalizovaný pro výpočetní výkon.

Node

Fyzické databázové servery

HW aplikačních serverů (CPU, RAM, I/O) optimalizovaný pro vstupně/výstupní datové operace.

Node

Host server

Fyzický server, na kterém běží hostované aplikace Zřizovaných, Příspěvkových organizací kraje a Úřadů městských částí.


Hostování internetové Hostování internetové domény domény


Interní technologické služby (primární datové centrum)

Serverové, diskové a síťové služby technologické vrstvy primárního datového centra.


Interní technologické služby (sekundární datové centrum)

Serverové, diskové a síťové služby technologické vrstvy sekundárního datového centra.


IPSec VPN

IPSec VPN

25

Typ prvku

Název prvku



KIVS VPN

KIVS VPN

Node

Komunikační server pro zprostředkování služeb centra

Realizuje služby bezpečné komunikační infrastruktury pro běh aplikační komponenty Komunikační brána (AppProxy) zajišťující zprostředkování Služeb centrálních ISVS pro vnitřní IS úřadu a jejich koncové uživatele.

Node

Komunikační server pro území

Realizuje služby bezpečné komunikační infrastruktury pro běh aplikační komponenty Portál občana (PO) zajišťující publikaci a předávání požadavků na Vnější služby úřadu, které zprostředkovávají koncoví uživatelé prostřednictvím funkcí jednotlivých AIS.

Node

Komunikační uzel

Komunikační uzel mezi datovým centrem a okolím. Sdružuje rozhraní a konektory


Krajský konektor

Krajský konektor


NDC

Infrastrukturní služba Národní datové centrum

Node

Obecná záloha

Záloha clusteru

Node

Obecné datové centrum

Obecné datové centrum

Node

Obecný cluster

Obecný cluster

Node

Personální počítač

Koncové zařízení pro lokální běh a vzdálený přístup k definovaným aplikacím organizace, který je koncovému uživateli umožněn na základě řízení oprávnění přístupu.


Poskytování dat o uživatelích

Adresářové služby domény Active Directory.


Propojení s jiným OVM



Přenos elektronické pošty



Přímé připojení



Přístup do CMS

Přístup do CMS


Přístup do internetu



Přístup k aplikaci



Přístup k záznamům o Přístup k záznamům o provozu provozu


Přístup k účtovacím informacím

Node

Serverová virtualizace Obsahuje logické komponenty pro běh aplikací - virtuální stroje (VM), které jsou navázány prostřednictvím Virtualizačního software na fyzické aplikační a databázové servery.


Služby bezpečné host infrastruktury


Infrastrukturní služby Bezpečné komunikační infrastruktury zajišťující běh hostovaných aplikací Zřizovaných a Příspěvkových 26

Typ prvku

Název prvku

Vysvětlení významu uzlu, funkce nebo služby organizací kraje.


Služby bezpečné komunikační infrastruktury pro eGOV

Infrastrukturní služby Bezpečné komunikační infrastruktury zajišťující běh aplikační komponenty Komunikační brána.


Služby bezpečné komunikační infrastruktury pro portál úřadu

Infrastrukturní služby Bezpečné komunikační infrastruktury zajišťující běh aplikační komponenty Portál občana.


Služby datového centra


Spuštění aplikací

Technologické služby koncové uživatelské stanice zajišťující běh kancelářských a podnikových aplikací.


SSL VPN

SSL VPN

Node

Síť

Node

Síťová virtualizace

Logické síťové komponenty, které jsou navázány prostřednictvím Virtualizačního software na fyzické síťové prvky.


Technologické služby

Technologické služby infrastruktury pro systém BPMS.

Node

Telefon

Analogový nebo digitální (VIOP) přístroj pro hlasovou komunikaci.


Telefonní služby

Telefonní služby Technologické vrstvy zajišťující potřeby spojené s výkonem koncového uživatele na jemu přiřazeném funkčním místě úřadu.


Tiskové služby

Tiskové služby Technologické vrstvy zajišťující potřeby koncových uživatelů v oblasti tvorby klasických papírových výstupů.

Node

Tiskárna

Zařízení pro tisk textových a grafických dat na papír.


Umístění aplikace OVM do NDC


Node

Uzel pro běh ETL nástrojů

Potřebný výpočentní výkon a úložiště na data pro ETL

Node

Uzel pro běh MIS

Potřebný výpočentní výkon a úložiště na data pro MIS

Node

Uzel pro běh multidimenzionální databáze

Potřebný výpočentní výkon a úložiště na data pro OLAP

Node

Uzel pro běh Relační databáze

Potřebný výpočentní výkon a úložiště na data pro DWH

Node

Virtuální uzel

Virtuální uzel(y) zahrnující logické serverové, síťové a diskové zdroje nezávisle na jejich vyzickém umístění a struktuře.


Zveřejnění aplikace



z CMS/OVM

z CMS/OVM


z S-TESTA

z S-TESTA

27

Typ prvku

Název prvku


Node

Zálohovací server

Server určený pro úlohy zálohování a obnovy dat s vazbou na zálohovací knihovnu.

Infrastructure Function

Čtení Tagů

Funkce pro čtení štítků hodnot

Model technologické architektury – pohled struktury IT technologické architektury

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 NDC

DC eGOV

Využití centrálních prvků provozního a bezpečnostního monitoringu Dohledového centra eGOV (MV)

Nerelevantní

Vysvětlení v kontextu technologické architektury úřadu, tedy jaké k funkčnímu celku existují či vznikají duplicity a proč a jaké jsou další souvislosti: Dosavadní Informační systémy úřadu budou přemigrovány do NDC. Vysvětlení technologické architektury funkčního celku: Projekt využívá služby PaaS od NDC.

2.2.6.

Technologická architektura – vrstva komunikační infrastruktury

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


Akceptace provozních Akceptace provozních podmínek CMS podmínek CMS





Běhové prostředí

Služby běhového prostředí.

Infrastructure

Databázové služby

Služby ukládání dat v databázích. 28

Typ prvku

Název prvku


Service Network (Box)

DMZ 1

Network (Box)

DMZ 2

Demilitarizovaná zóna pro Komunikační server B – Veřejný internet.

Network (Box)

DMZ 3

Demilitarizovaná zóna pro Hostované aplikace - Host server.


do CMS

do CMS


do Internetu

do Internetu


do S-TESTA

do S-TESTA

Network (Box)

FW 1

Network (Box)

FW 2


Hostování internetové Hostování internetové domény domény


Interní technologické služby (primární datové centrum)

Serverové, diskové a síťové služby technologické vrstvy primárního datového centra.


Interní technologické služby (sekundární datové centrum)

Serverové, diskové a síťové služby technologické vrstvy sekundárního datového centra.


IPSec VPN

IPSec VPN

Network (Box)

ISP 1 Centrální

CMS Internet - veřejné připojení do centrálního místa služeb skrze veřejnou síť.

Firewall zabezpečující Segment vnitřní sítě 2 směrem od Veřejného Internetu a Metropolitní sítě.

CMS má vlastní Provider Independent IPv4 adresy a přidělený vlastní autonomní systém AS48298. Adresy jsou propagovány do sítě Internet dvojicí hraničních směrovačů. Směrovače jsou zapojeny v režimu vysoké dostupnosti. CMS propaguje své adresy protokolem BGP přes NIX a ISP T-System. Služby CMS přístupné z Internetu jsou dostupné přes toto propojení. Součástí směrovačů je firewall, který zabezpečuje bezpečný přístup z Internetu do CMS a současně překlad privátních rozsahů na veřejné IP adresy CMS. Současné připojení CMS je 2x 10Gbps. Network (Box)

KIVS

CMS KIVS (Komunikační infrastruktura veřejné správy), součást centrálního místa služeb (CMS). CMS KIVS slouží pro připojení KIVS operátorů pomocí dvojice směrovačů, do kterých jsou přivedeny přípojky ze směrovačů jednotlivých KIVS operátorů. V současné době je připojeno 6 KIVS operátorů. Zajištění vysoké dostupnosti je na směrovačích zajištěno protokolem HSRP. Každému subjektu je přiřazený rozsah, kterým přistupuje ke službám CMS tzv. CMS konsolidovaný rozsah. O překlad adres subjektu do konsolidovaného rozsahu CMS se stará Virtuální Firewall. 29

Typ prvku

Název prvku



KIVS VPN

KIVS VPN


Krajský konektor

Krajský konektor

Network (Box)

Lokální switch

Síťové switche zajišťující připojení personálních počítačů uživatelů úřadu a lokálně připojených tiskáren do sítě.

Network (Box)

Metropolitní síť

Metropolitní síť, zkráceně MAN (Metropolitan Area Network) je rozlehlá počítačová síť, obvykle zasazená do města. Metropolitní síť obsahuje technicky několik menších podsítí pospojovaných navzájem. Propojení se provádí většinou přes Wi-Fi mebo optické vlákno. Metropolitní síť je optimalizována pro větší zeměpisnou oblast než je LAN, v rozsahu od několika bloků budov až po celé město a jeho části.


NDC

Infrastrukturní služba Národní datové centrum


Poskytování dat o uživatelích

Adresářové služby domény Active Directory.











Přístup do CMS

Přístup do CMS








Přístup k záznamům o Přístup k záznamům o provozu provozu




Network (Box)

SAN

Storage Area Network (SAN) - je dedikovaná (oddělená od LAN, WAN, atd.) datová síť, která slouží pro připojení datových zařízení k aplikačním serverům (disková pole, páskové knihovny a jiná zálohovací zařízení).

Network (Box)

Segment vnější sítě

Zóna vnější sítě pro komunikaci vnitřních aplikací úřadu (AIS) s okolními systémy (PO).

Network (Box)

Segment vnější sítě 1

Zóna vnější sítě pro komunikaci vnitřních aplikací úřadu (AIS, IAM) s okolními systémy (ISVS).

Network (Box)

Segmenty vnitřní sítě

Jednotlivé části vnitřní sítě, které jsou od vnějších sítí prostřednictvím centrálního switche.


Služby bezpečné host infrastruktury

Infrastrukturní služby Bezpečné komunikační infrastruktury zajišťující běh hostovaných aplikací Zřizovaných a Příspěvkových organizací kraje.

Infrastructure

Služby bezpečné

Infrastrukturní služby Bezpečné komunikační infrastruktury 30

Typ prvku

Název prvku


Service

komunikační infrastruktury pro eGOV

zajišťující běh aplikační komponenty Komunikační brána.


Služby bezpečné komunikační infrastruktury pro portál úřadu

Infrastrukturní služby Bezpečné komunikační infrastruktury zajišťující běh aplikační komponenty Portál občana.


Služby datového centra


Spuštění aplikací

Technologické služby koncové uživatelské stanice zajišťující běh kancelářských a podnikových aplikací.


SSL VPN

SSL VPN

Network (Box)

Síť mezi datovými centry

Fyzická síť mezi jednotlivými datovými centry

Network (Box)

Síť mezi DC a uzly

Fyzická síť mezi datovým centrem a komunikačním uzlem


Technologické služby

Technologické služby infrastruktury pro systém BPMS.


Telefonní služby

Telefonní služby Technologické vrstvy zajišťující potřeby spojené s výkonem koncového uživatele na jemu přiřazeném funkčním místě úřadu.


Tiskové služby

Tiskové služby Technologické vrstvy zajišťující potřeby koncových uživatelů v oblasti tvorby klasických papírových výstupů.








z CMS/OVM

z CMS/OVM


z S-TESTA

z S-TESTA

Model technologické architektury – pohled struktury komunikační infrastruktury

31

Využití sdílených služeb komunikační infrastruktury Název

Popis

Použito

Č. výjimky

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

Ano

Housing (IaaS)

Využití umístění vlastní HW infrastruktury do prostor datového centra třetí strany

Ne

Vysvětlení v kontextu architektury komunikační infrastruktury úřadu, tedy jaké k projektu existují či vznikají duplicity a proč a jaké jsou další souvislosti: V rámci úřadu bude posilněna komunikační infrastruktura z důvodu migrace systémů do NDC. Vysvětlení architektury komunikační infrastruktury projektu: Projekt posilňuje komunikační infrastrukturu ve smyslu dostupnosti a výkonnosti.

2.2.7.

Bezpečnostní architektura

Katalog bezpečnostní architektury projektu Dotčený nebo bezpečnostní prvek

Hrozba / riziko

Vysvětlení způsobu zmírnění hrozby / rizika prvkem architektury

Databáze informací

fyzická krádež

užití šifrování informací, fyzických zabezpečovacích prvků

Informační systém

neoprávněné užití

autentizace uživatelů IS

Dodržení architektonických principů Princip Požadavek 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?

Dodrženo

Č. výjimky Způsob a míra naplnění

Ano

-

Prostředky jsou ochráněny pomocí zabezpečovacích metod jak fyzické, tak i elektronické bezpečnosti.

Vysvětlení bezpečnostní architektury projektu: Projekt zohledňuje a integruje trendy v bezpečnosti jako prevence proti hrozbám aktuálním hrozbám. Dále též projekt respektuje vyhlášku Kybernetického zákona a dalších spojených nařízení.

2.2.8.

Shoda s pravidly, standardizace a dlouhodobá udržitelnost

Využití centrálního nákupu softwarových produktů Vysvětlete, které licence standardizovaných SW produktů budete pořizovat podle rámcové smlouvy zajištěné Ministerstvem vnitra, případně proč tento instrument nevyužijete: Operační systémy serverů a koncových stanic, databázové systémy, CMS systémy. 32

Katalog komponent, které bude možné znovu využít v jiných projektech (NEPOVINNÉ) Název komponenty

Vysvětlení možnosti opětovného využití

IAM - Identity Access Management

Systém se znova se integruje pro další užití navazujících systémů zřizovaných organizací.

Portál občana

Portál občana bude v budoucnu použit pro další integraci se systémem Úplného elektronického podání.

Portál úředníka

Informační systém se znova použije v navazujícím projektu pro implementaci Úplného Elektronického Podání.

Dodržení architektonických principů Princip Požadavek

Dodrženo

Č. výjimky Způsob a míra naplnění

Udržitelnost Je řešení navrženo pro efektivní údržbu Ano a rozvoj, tj. jako standardizované, rozšiřitelné, integrovatelné, upgradovatelné a podporovatelné i vlastními silami úřadu?

-

Ano, projekt realizuje systémy včetně školení, které jsou udržitelné pomocí vlastních sil úřadu.

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

-

Návrh služeb to umožňuje.

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

-

Návrh informačních systémů to zohledňuje.

Vysvětlení standardizace a udržitelnosti architektury projektu: Projektem navrhnuté informační systémy respektují definované pravidla a standardizace

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šší

33

Dodržení architektonických principů Princip

Požadavek

Dodrženo

Č. výjimky

Způsob a míra naplnění

Technologická Jsou odděleny jednotlivé vrstvy Ano neutralita architektury řešení systémem služeb poskytovaných navzájem mezi vrstvami?

-

Služby jednotlivých vrstev jsou odděleny.

Technologická Je zajištěna separátní správa, neutralita dohled a provoz služeb na jednotlivých vrstvách?

-

Projekt bere ohled na zajištění služeb jednotlivých vrstev z vícero aspektů.

Ano

Vysvětlení čtyřvrstvé architektury služeb projektu: Architektura projektu je navržena konceptem Servisně-orientované architektury (SOA - Service-oriented architecture).

2.3.

Kontrola shody architektury řešení projektu se vzory sdílených služeb eGovernmentu

Název architektonického vzoru eGovernmentu

Dodržen vzor?

Č. výjimky Podrobný popis způsobu a míry dodržení vzorů návrhem řešení projektu

Centrální místo služeb

Ano

-

Návrh projektu respektuje předepsaný vzor sdíleného systému.

CzechPOINT

Ano

-

Návrh projektu respektuje předepsaný vzor sdíleného systému CzechPOINT.

Datové schránky

Ano

-

Návrh projektu respektuje předepsaný vzor sdíleného systému ISDS

Elektronická identita

Ano

-

Návrh projektu respektuje předepsaný vzor sdíleného systému Elektronické identity systému NIA.

Propojený datový fond

Ano

-

Návrh projektu respektuje předepsaný vzor sdíleného systému Propojeného datového fondu.

Úplné elektronické podání

Nerelevantní

-

Projekt neimplementuje Úplné Elektronické Podání.

2.4.

Plán projektu

Hrubý harmonogram předloženého projektu Fáze / milník

Začátek

Konec

Základní náplň

Úvodní fáze

10.1.2017

31.5.2017

Navazuje na

Průzkumy, soutěže, výběrová řízení.

Návrhová fáze

1.6.2017

31.7.2017

Sběr požadavků, připomínkování, vyhotovení a schválení seznamu požadavků.

Úvodní fáze

Implementační fáze

1.8.2017

31.10.2017

Vývoj, implementace a testování řešení, stavební práce.

Návrhová fáze

Fáze nasazení

1.11.2017

31.12.2017

Nasazení, integrace, instalace HW.


Fáze školení

1.11.2017

31.12.2017

Absolvování kvalifikačního školení


34

Fáze / milník

Začátek

Konec

Základní náplň

Navazuje na

asistujícího personálu. Fáze zkušebního provozu

1.1.2018

30.4.2018

Zkušební provoz se Fáze nasazení + Fáze školení zaškoleným personálem, monitoring a lazení provozu, odlaďování chyb.

Fáze ostrého provozu s podporou

1.5.2018

31.12.2022

Ostrý provoz včetně očekávané údržby.

Fáze zkušebního provozu

Projektový kontext předkládaného projektu (v rozvojovém programu, portfoliu úřadu) Předchozí projekty Popis návaznosti na předchozí projekty -žádné-

-

Souběžné projekty

Popis návaznosti na souběžné projekty

-žádné-

-

Navazující projekty

Popis návaznosti na budoucí projekty

Projekt integrace ÚEP

Navazující projekt, který implementuje Úplné Elektronické Podání do úřadu.

Zavedení architektonické kanceláře

Zavedení architektonické kanceláře za účelem pro řízení a další rozvoj implementovaných informačních systémů architektury.

Katalog rozvojových etap (přechodových architektur) – roadmapa Etapa/ přechodová architektura Milník Přírůstky a změny v přechodových architekturách oblastí zahrnutých do projektu Vyplývající z vlastního funkčního celku (např. komplexního IS) Hlavní

Impleme Přírůstky: ntační -IDM, fáze -DMS, -PÚ, -PO, -BPMS.

Vyplývající z kontextu úřadu (roadmapy úřadu) Stávající stav architektury

1

Původní stav

Cílový cíl architektury

2

Již obsahuje systémy: -IDM, -DMS, -PO, -PÚ, -BPMS.

Vysvětlení plánu projektu: V projektu budou systémy implementované paralelně v jedné fázi projektu, kde následně budou zavedeny do zkušebního, posléze ostrého provozu.

35

3.

D A L Š Í

3.1. 3.1.1.

Ú D A J E

O

P R O J E K T U

Připravenost projektu k realizaci Majetkoprávní vztahy projektu (jen pro projekty zahrnující vývoj SW)

Podmínka

Ano? Poznámka (důvod)

Budou vám udělena výhradní práva k užívání k dodávanému produktu?

☒ Budou.

Budou vám udělena nevýhradní práva k užívání k dodávanému produktu?

☐

Budou práva k autorskému dílu nějak omezena (IČO, konkrétní uživatel, převoditelnost a další šíření, úpravy produktu, parametry…)?

☐

Budete mít přístup ke zdrojovému kódu pro čtení?

☒

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?

☒

Budete mít přístup k aktuální technické dokumentaci produktu?

☒

Nebudou. Práva autorská omezena nebudou.

Ano. Ano, bude umožněno.

Ano, dokumentace bude dostupná.

Obsahuje budoucí smlouva ujednání o vyloučení odpovědnosti za výpadky fungování?

☒

Budou externí nákupy veřejně soutěženy?

☒ Ano, externí nákupy budou soutěženy.

3.1.2.

Finanční připravenost projektu

Druh financování Financování pomocí ESIF1 Financování z vlastních zdrojů Financování pomocí jiných externích zdrojů

3.1.3.

Ano, obsahuje.

Ano? Popis zajištění, získání financování Pro financování projektu budou využity Evropské investiční

☒ strukturální fondy ☒ Projekt bude též financován z vlastních zdrojů. ☐

Jiné externí zdroje nebudou použity.

Metodická připravenost projektu

Metodické zajištění

Ano? Popis

Řízení pomocí metodiky (uveďte název)

☒

Podpora od projektové kanceláře úřadu/resortu

☒ přítomnost ve svém projektovém portfoliu.

Podpora od architektonické kanceláře úřadu/resortu

☒ funkcionáři projekt schválili.

1

Projekt bude projektově řízen pomocí metodiky IPMA. Projektová kancelář vyjádřila projektu svou podporu a zohlednila její Úřad nemá zřízenou architektonickou kancelář, kompetentní

Evropské strukturální a investiční fondy

36

3.2. 3.2.1.

Ekonomické parametry projektu 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). Plán předpokládané ekonomické náročnosti projektu založené na metodologii 5 letých celkových nákladů vlastnictví (tzv. total costs of ownership) - účelové členění nákladů projektu. Souhrnná položka modelu TCO v Kč bez DPH

① Výdaje na realizaci (výstavbu) projektu

② Výdaje na provoz a rozvoj (do konce aktuální smlouvy)

③ TCO 5 (① plus ② odhadnutý na 5 let)

Vysvětlení k položce

Počet měsíců trvání fáze A. Předběžné analýzy, tvorba zadání, výběr řešení a dodavatele – náklady nákupního procesu B. Nákup SW a HW pro projekt (bez SaaS či PaaS) C. Analýza, vývoj, implementace a zkušební provoz D. Provoz a podpora řešení HW a SW (bez SaaS či PaaS) E. Hardware/Software údržba a průběžné úpravy (bez SaaS či PaaS) 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) I. Útlum, konzervace a ukončení řešení X. Licence, HW, provoz, podpora, údržba, průběžný rozvoj - vše v subskripci (pouze SaaS a PaaS) Z. Ostatní nerozlišené režijní náklady Celkem Celkem žádáno Po dobu prací RVIS a jejího pracovního výboru na konceptu TCO je vyplnění interních nákladů úřadu a ostatních spolupracujících OSS dočasně nepovinné.

Popis funkčního celku, který je projektem rozšiřován či upravován (pokud existuje): Soustava informačních systémů zabepečující plnou elektronizaci agend a bezpapírový chod úřadu.

37

Plánované 5leté externí výdaje celého funkčního celku (mimo tento projekt):

12 744 817,-

Vysvětlení a komentář k souhrnu výdajů a ekonomické náročnosti projektu: Ekonomická náročnost projektu je adekvátní s ohledem na provedený průzkum trhu. Většina zdrojů na financování projektu bude poskytnuta z EISF, zbytek je hrazen z vlastních zdrojů.

3.2.2.

Personální náročnost projektu

Odhady kapacitní náročnosti realizace projektu (korespondující s TCO) Interní / Externí zdroje

Počet osob

Počet přepočtených Vysvětlení rolí v projektu úvazků

Interní zaměstnanci organizace

7

4,5 FTE

Jedná se zejména o role z IT oddělení a projektové kanceláře.

Ostatní zaměstnanci VS Externí dodavatelé

Zatím se neuvažují, uveďte, je-li pro projekt významné -

-

Uveďte jen, pokud v projektu objednáváte konkrétní objem hodin/dnů

Odhady dopadů do změn počtu systemizovaných míst spojených s projektem Kategorie systemizovaného Uvnitř úřadu Jinde ve VS Vysvětlení změny a umístění systemizovaných míst místa Pro realizaci projektu

-4

0

Elektronizace systémů a řízené workflow umožní rychlejší vybavování žádostí.

Pro vlastní výkon podpořené 0 externí veřejné služby

0

Projekt nemá vliv na danou kategorii.

Pro IT podporu provozu

1

Konsolidace IT umožní ušetření dvou míst na IT oddělení úřadu. Nárůst jinde ve VS činí pracovníka správy a dohledu provozu v NDC pro potřeby úřadu.

-2

Vysvětlení a komentář k personální náročnosti projektu: Elektronizace agend umožní zvýšení výkonu zpracování žádostí, což umožňuje snížení dosavadní potřebné personální náročnosti úřadu.

3.3.

Analýza rizik projektu

Přehled klíčových identifikovaných rizik neúspěchu projektu Označení rizika

Popis rizika

Opatření pro snížení rizika

nesoučinnost ze strany Zákazník bude nesoučinný pro zákazníka realizaci projektu.

Proaktivní zapojení zainteresovaných stran projektu.

problém s financováním EISF

Zvýšená pozornost u hlídání podmínek pro příjem dotace.

Nastane zamezení finančních zdrojů z EISF.

změna obsahu pravidel Dojde ke změně pravidel ze Intenzivní komunikace s MV ČR s cílem včasného IROP Výzvy 28 strany MV ČR. Nárůst pracnosti odhalení plánovaných změn pro jejich včasnou pro obsáhnutí změn. implementaci. Vyjednávání a prokazatelné stvrzení mít možnost pokračovat dle tehdejších pravidel.

38

3.4.

Plán zavedení, údržby, dlouhodobá udržitelnost výstupů projektu

Plánovaný ověřovací provoz jednotlivých výstupů projektu Označení výstupu projektu

Plánovaná doba ověřovacího provozu výstupu

Jednotné řízení přístupu

4 měsíce

Elektronizace dokumentů

4 měsíce

Elektronizace vnitřních výkonných procesů úřadu

4 měsíce

Zpřístupnění služeb úřadu elektronicky

4 měsíce

Modelování a řízení pracovních procesů

4 měsíce

Plánovaná životnost jednotlivých výstupů projektu Označení výstupu projektu Plánovaná životnost výstupu

Popište plánované změny

Jednotné řízení přístupu

5 let

Výstup v podobě informačního systému bude nasazen, posléze udržován běžným způsobem.

Elektronizace dokumentů

5 let


Elektronizace vnitřních výkonných procesů úřadu

5 let

Výstup v podobě informačního systému bude nasazen, upravován ve smyslu platné legislativy.

Zpřístupnění služeb úřadu elektronicky

5 let


Modelování a řízení pracovních procesů

5 let

Na začátku jsou nastaveny veškeré workflow, v průběhu jsou upravovány, zejména v případě novelizace.

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 a jakým způsobem: Podpora u legislativního update bude zachována. Změny bude úřad schopen adaptovat do pracovních postupů (workflow) pomocí vlastních sil. Jak je zajištěn další budoucí rozvoj předmětné oblasti a její ICT podpory: Oblast bude reagovat vůči přijímané platné legislativě. Jak je zajištěno řízené ukončení životnosti jednotlivých výstupů projektu a případný přechod na další řešení: Projekt po 5 letech je ukončen s tím, že úřad bude schopen ho udržovat ve vlastní režií.

39

4.

V Y J Á D Ř E N Í A S P E K T Ů M

K

B E Z P E Č N O S T N Í M

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.

40

5.

U P O Z O R N Ě N Í

A

D O P O R U Č E N Í

Upozornění a doporučení: Tato žádost je odevzdávaná bez zvláštních upozornění či doporučení.

41

6.

P Ř Í L O H Y

Typ

Číslo a název přílohy

Jiný

A1 - Dodatečné informace ohledně požadavků pravidel na Výzvu 28

Upřesnění výjimky/přílohy

Zvolte položku.

42

Další specifické věci relevantní vůči Pravidlům pro vydání stanoviska OHA k Výzvě #28 – specifické komunikační systémy a infrastruktura II, které nejsou k nalezení ve zdejším Form_A_v5.0 výše:

Řešení projektu (požadavky na zpracování Studie proveditelnosti) Architektonický obsah je nezbytný zejména pro prokázání, že při návrhu projektu byl uplatněn celostní architektonický přístup, …

Způsob využití sdílených prvků architektury úřadu a eGovernmentu Zejména je třeba v aplikační vrstvě modelu architektury vyjádřit vztah k následujícím existujícím a připravovaným systémům a projektům:   

ZR (ISZR, ROB, ROS, RUIAN, RPP, ORG), eGSB; Agendové systémy přispívající do Propojeného datového fondu; CMS/KIVS, NDC, CzP, eGSB, JIP/KAAS, Národní identitní autorita, ISDS, eLegislativa a eSbírka, OpenData, PVS.

Přehled nahrazovaných procesů a technologických prvků a začlenění navrhovaného řešení do stávajícího prostředí úřadu a eGovernmentu Architektura řešení projektu. Ukazuje, jak bude projekt realizován, shrnuje v modelech tzv. „funkční“ a „nefunkční“ specifikaci projektu. Architektura řešení je nutná zejména pro:  

doložení, jak jsou dodrženy Závazné architektonické vzory MV-OHA, které jsou a budou publikovány jako závazné vzory příslušných komponent architektur řešení; doložení jak je realizována a jak bude fungovat realizovaná sdílená služba v rámci prostředí propojeného datového fondu veřejné správy.

Stanovení úrovně dodávky služeb realizovaných projektem s dodržením minimálních požadovaných standardů Stanovení úrovně dodávky služeb jednotlivým skupinám koncových uživatelů připravovaného řešení včetně rozhraní pro příjem a poskytování dat jiným informačním systémům veřejné správy. Minimálně je nutné uvést: 

Dostupnost dané služby v kontextu doby, kdy je služba dostupná (např. 24x7, v pracovní dobu …) případně vliv projektu na zlepšení tohoto parametru vůči současnému stavu.  Úroveň dostupnosti služby s ohledem na skutečnou délku poskytované služby vzhledem k plánované (např. 95 %) případně vliv projektu na zlepšení tohoto parametru vůči současnému stavu.  Maximální doba obnovení dodávky služby (za jakou maximální dobu od zahájení výpadku služby je obnovena dodávka této služby) případně vliv projektu na zlepšení tohoto parametru vůči současnému stavu. Je nutné rozdělit dodávku služby prostřednictvím uživatelského rozhraní (uživatelem je člověk) a prostřednictvím komunikačních rozhraní (uživatelem je jiný informační systém).

Přehled způsobu realizace povinných a případných dalších komunikačních kanálů Popis komunikačních kanálů pro přístup uživatelů a jiných informačních systémů. Pokud je uživatelem jakékoli služby veřejnost, pak musí být splněny tyto povinné komunikační kanály:  Podání formulář musí být realizovatelné s využitím informačního systému datových schránek a portálu veřejné správy.  Offline formulář musí být realizovatelný jako digitálně podepsaný dokument zaslaný standardní elektronickou poštou.  Formulář může být dále realizován interaktivním procesem v rámci portálu řešení. V případě, že jsou vytvářeny nové sdílené komunikační kanály, pak jejich popis, přínos a předpokládané využití. 43

Popis základních životních minimálních standardů

situací

s

potvrzením

dodržení

Identifikace a autentizace osob musí podporovat aktuální stav implementace Nařízením EU 910/2014 o elektronické identifikaci a službách vytvářejících důvěru pro elektronické transakce na vnitřním trhu a o zrušení směrnice 1999/93/ES (eIDAS) Je uveden popis jednotlivých životních situací (use case) s uvedením případných obecných standardů (jako zákon je 181/2014 Sb. Zákon o kybernetické bezpečnosti) či specifickým standardům zadavatele. Zvláště pro nově vytvářené sdílené služby. V případě modernizace či aktualizace stávajících služeb je nutné uvést přínos projektu pro tyto životní situace.

Popis následné technické a technologické podpory realizovaného řešení a způsobu jejího zajištění Uvádí popis realizace technické a technologické podpory realizovaného řešení. Zvláště uvádí realizaci předpokládané dostupnosti a podpory úrovně dostupnosti služeb dle zvoleného modelu dostupnosti služeb. Musí být uvedena vazba na dodržení požadavků o kybernetické bezpečnosti dle výše uvedeného zákona a vyhlášky během provozu. Musí být uvedena exit strategie při ukončení doby udržitelnosti či případného ukončení smlouvy o podpoře dodaného díla.

REALIZACE některých chybících sekcí (užitím z předchozí verze Form_A_v4.21): Využití dalších klíčových prvků eGovernmentu2 Název

Popis

PVS

Přístup občanů k el. službám úřadu je využita navigace v Portálu veřejné správy

2

Použito

Přitom komunikační rozhraní jsou již plně analyzována v kapitole 2.3.3 Byznys architektura projektu

44

Formulář žádosti. o stanovisko Hlavního architekta egovernmentu k plánovanému ICT projektu typ A. Odbor Hlavního architekta egovernmentu MV

Recommend Documents