Rozdíly

Zde můžete vidět rozdíly mezi vybranou verzí a aktuální verzí dané stránky.

Odkaz na výstup diff

Následující verze		 Předchozí verze
znalostni_baze:funkcni_nefunkcni_pozadavky [2024/06/13 10:52] – vytvořeno Tomáš Šedivecznalostni_baze:funkcni_nefunkcni_pozadavky [2024/06/13 14:46] (aktuální) – [Sběr požadavků vzhledem k hierarchizaci úřadu] Tomáš Šedivec
Řádek 1: Řádek 1:
 ====== Funkční a nefunkční požadavky ISVS ====== ====== Funkční a nefunkční požadavky ISVS ======
 +
 +<WRAP center round tip 60%>
 +Příloha s {{ :znalostni_baze:funkcni_a_nefunkcni_pozadavky_na_is_vs_a_jejich_sluzby_priloha_se_vzorov....xlsx |vzorovými příklady funkčních a nefunkčních požadavků}}
 +</WRAP>
 +
  
 Toto je metodické doporučení obsahující návody ke správě funkčních a nefunkčních požadavků na ISVS požadavků na informační systémy veřejné správy (dále „ISVS“), dalších informačních systémů (dále „IS“) a služeb, které jsou jimi poskytovány, včetně možnosti pořízení cloudových služeb (SaaS, PaaS, IaaS). Dokument dále obsahuje vzorový seznam funkčních a nefunkčních požadavků a základní kategorizace systému. Toto je metodické doporučení obsahující návody ke správě funkčních a nefunkčních požadavků na ISVS požadavků na informační systémy veřejné správy (dále „ISVS“), dalších informačních systémů (dále „IS“) a služeb, které jsou jimi poskytovány, včetně možnosti pořízení cloudových služeb (SaaS, PaaS, IaaS). Dokument dále obsahuje vzorový seznam funkčních a nefunkčních požadavků a základní kategorizace systému.
Řádek 33: Řádek 38:
 Tato metodika by měla též posloužit jako součást přípravy variantních řešení pro pořízení nebo obnovu informačních systémů, služeb a ICT řešení. Dále by měla metodika sloužit jako podklad pro ekonomickou analýzu úpravy zadávacích podmínek, například i v oblasti nastavení stropové ceny. Tato metodika by měla též posloužit jako součást přípravy variantních řešení pro pořízení nebo obnovu informačních systémů, služeb a ICT řešení. Dále by měla metodika sloužit jako podklad pro ekonomickou analýzu úpravy zadávacích podmínek, například i v oblasti nastavení stropové ceny.
  
 +<WRAP center round info 60%>
 Příklad: Příklad:
  
 Úřad provozuje nevyhovující informační systém, jehož obnova dle dále navrhovaných kritérií a skutečných potřeb úřadu by byla dražší než pořízení nového informačního systému. Ovšem skutečnou cenu rekonstrukce stávajícího systému, stejně jako skutečnou cenu nového informačního systému lze zjistit pouze zpětně po jeho provozování. Avšak na základě analýzy potřeb úřadu ve formě funkčních a nefunkčních požadavků lze stanovit rozsah prací, následně vyhodnotit jednotlivé varianty a tuto analýzu mít jako podklad pro následné uskutečnění výběrového řízení v dané optimální variantě. Úřad provozuje nevyhovující informační systém, jehož obnova dle dále navrhovaných kritérií a skutečných potřeb úřadu by byla dražší než pořízení nového informačního systému. Ovšem skutečnou cenu rekonstrukce stávajícího systému, stejně jako skutečnou cenu nového informačního systému lze zjistit pouze zpětně po jeho provozování. Avšak na základě analýzy potřeb úřadu ve formě funkčních a nefunkčních požadavků lze stanovit rozsah prací, následně vyhodnotit jednotlivé varianty a tuto analýzu mít jako podklad pro následné uskutečnění výběrového řízení v dané optimální variantě.
 +
 +</WRAP>
  
 ===== Jak dokument použít ===== ===== Jak dokument použít =====
Řádek 52: Řádek 60:
   -Žádné požadavky na změnu nevznikly (tato varianta se vyskytuje téže zřídka)   -Žádné požadavky na změnu nevznikly (tato varianta se vyskytuje téže zřídka)
  
-{{media/image1.png?601x607|C:\Users\Martin Rod\Downloads\Untitled Diagram (6).png}}+{{ :znalostni_baze:fnp1.png?600 |}}
  
  
Řádek 102: Řádek 110:
 Není pravdou, že čas věnovaný na sběr požadavků prodlužuje projekt, naopak je to nezbytně vynaložený čas, který povede ke zkrácení nutného času na úspěšnou realizaci. Není pravdou, že čas věnovaný na sběr požadavků prodlužuje projekt, naopak je to nezbytně vynaložený čas, který povede ke zkrácení nutného času na úspěšnou realizaci.
  
 +<WRAP center round info 60%>
 Příklad: Příklad:
  
Řádek 109: Řádek 118:
  
 Syntézou stávajícího stavu s nově zadanými parametry je jasná představa o nutných změnách v relaci na tyto požadavky. Ta se dá následně užít při dalším zpracování (gap analýza, analýza nákladů a přínosů, následná transformace na požadavku pro zadávací dokumentaci). Syntézou stávajícího stavu s nově zadanými parametry je jasná představa o nutných změnách v relaci na tyto požadavky. Ta se dá následně užít při dalším zpracování (gap analýza, analýza nákladů a přínosů, následná transformace na požadavku pro zadávací dokumentaci).
 +
 +</WRAP>
  
 ==== Přínos dobrých požadavků ==== ==== Přínos dobrých požadavků ====
Řádek 127: Řádek 138:
  
 **Hlavním dopadem špatných požadavků jsou předělávky**, velice často již ve fázi vývoje nebo po finální verzi. Díky tomuto **předělávky často dosahují 30 % až 50 % vývojových nákladů, chyby v požadavcích často dělají 70 % až 85 % cen předělávek (oprava a vícepráce)**. Nedostatky, jež se stanou ve fázi sběru požadavků, způsobí 40 až 50 % chyb. Oprava chyb je mnohem levnější v raných etapách projektu, tedy ve strategii, plánu a přípravy (průřezově ve všech dílčích fází). **V relativní škále, pakliže oprava chyby ve fázi formalizace požadavků stála 1000 Kč**, při tvorbě designu oprava stojí již 1000 Kč a dále 2000 Kč až 3000 Kč na opravu již odvedené práce. **Pakliže by si chyby všiml až uživatel, oprava chyby by stála 100 000 Kč.** (Wiegers, 2013 p. 19) **Hlavním dopadem špatných požadavků jsou předělávky**, velice často již ve fázi vývoje nebo po finální verzi. Díky tomuto **předělávky často dosahují 30 % až 50 % vývojových nákladů, chyby v požadavcích často dělají 70 % až 85 % cen předělávek (oprava a vícepráce)**. Nedostatky, jež se stanou ve fázi sběru požadavků, způsobí 40 až 50 % chyb. Oprava chyb je mnohem levnější v raných etapách projektu, tedy ve strategii, plánu a přípravy (průřezově ve všech dílčích fází). **V relativní škále, pakliže oprava chyby ve fázi formalizace požadavků stála 1000 Kč**, při tvorbě designu oprava stojí již 1000 Kč a dále 2000 Kč až 3000 Kč na opravu již odvedené práce. **Pakliže by si chyby všiml až uživatel, oprava chyby by stála 100 000 Kč.** (Wiegers, 2013 p. 19)
 +
 +{{ :znalostni_baze:fnp2.png?600 |}}
  
 Základní přehled etap pro řízení ICT Základní přehled etap pro řízení ICT
 +
 +{{ :znalostni_baze:fnp3.png?600 |}}
  
 === Právní dopady špatných požadavků === === Právní dopady špatných požadavků ===
Řádek 188: Řádek 203:
 ===== Souvislost požadavků na ICT řešení s byznysovými procesy, architekturou a ICT ===== ===== Souvislost požadavků na ICT řešení s byznysovými procesy, architekturou a ICT =====
  
-{{media/image3.emf?601x230}}Existuje souvislost mezi byznysovým výkonem funkce úřadu, architekturou a již zavedeným ICT. Tuto souvislost je potřeba zachytit pro sběr požadavků na ICT řešení.+Existuje souvislost mezi byznysovým výkonem funkce úřadu, architekturou a již zavedeným ICT. Tuto souvislost je potřeba zachytit pro sběr požadavků na ICT řešení. 
 + 
 +{{ :znalostni_baze:fnp4.png?600 |}}
  
-Obr xyz: Graf válec matice 
  
 ==== Zjednodušený model jako matice ==== ==== Zjednodušený model jako matice ====
Řádek 316: Řádek 332:
 Business funkce je možné dělit na klíčové, nebo kontextovou/okrajovou. Výchozím pravidlem je, že klíčové funkce není možno outsourcována z organizace pryč, kdežto okrajové funkce je možné outsourcurcovat. Zde je dopad na kybernetickou bezpečnost a prevenci vendor lock-in efektu. Business funkce je možné dělit na klíčové, nebo kontextovou/okrajovou. Výchozím pravidlem je, že klíčové funkce není možno outsourcována z organizace pryč, kdežto okrajové funkce je možné outsourcurcovat. Zde je dopad na kybernetickou bezpečnost a prevenci vendor lock-in efektu.
  
-Obrázek 3 – Pohled poptávajícího z hlediska prostředkové typizace řešení. 
 ^Core business                                                                                                             ^Context business                                                                                           ^ ^Core business                                                                                                             ^Context business                                                                                           ^
 |Velká pravděpodobnost vendor lock-inu\\ \\ Řešení bude muset být vyvíjeno na míru\\ \\ Typicky Agendové informační systémy|Menší pravděpodobnost vendor lock-inu\\ \\ Budou existovat typizovaná řešení\\ \\ Typicky docházkový systém| |Velká pravděpodobnost vendor lock-inu\\ \\ Řešení bude muset být vyvíjeno na míru\\ \\ Typicky Agendové informační systémy|Menší pravděpodobnost vendor lock-inu\\ \\ Budou existovat typizovaná řešení\\ \\ Typicky docházkový systém|
Řádek 326: Řádek 341:
 V rámci samotné aplikace a jejích následných prostředků je možné tuto aplikaci provozovat jen jako službu (SaaS), anebo je možné vlastnit i provozovat fyzické prostředky, tj. servery, mainframy, datová uložiště aj. (On-Premise řešení). I z tohoto hlediska lze sestavit hierarchizovaný model. Diagram obsahuje členění jednotlivých součástí daného řešení (obrázek 3). Tedy pro řešení typu SaaS je dodavatel zodpovědný za celé řešení související se softwarem, při užití PaaS je oblast aplikací a dat přesunuta k objednavateli řešení. Analogicky z druhého konce pro On-Premise řešení platí, že obsahuje všechny zmíněné elementy. V rámci samotné aplikace a jejích následných prostředků je možné tuto aplikaci provozovat jen jako službu (SaaS), anebo je možné vlastnit i provozovat fyzické prostředky, tj. servery, mainframy, datová uložiště aj. (On-Premise řešení). I z tohoto hlediska lze sestavit hierarchizovaný model. Diagram obsahuje členění jednotlivých součástí daného řešení (obrázek 3). Tedy pro řešení typu SaaS je dodavatel zodpovědný za celé řešení související se softwarem, při užití PaaS je oblast aplikací a dat přesunuta k objednavateli řešení. Analogicky z druhého konce pro On-Premise řešení platí, že obsahuje všechny zmíněné elementy.
  
-{{media/image4.emf?545x331}} +{{ :znalostni_baze:fnp5.png?600 |}}
- +
-Kontrola Flexibilita+
  
 Nezávisle na prostředkové typizaci je nutné vždy mít na pozoru oblast vlastnictví a dostupnosti dat. Správa dat samotných, po boku služeb, je jedním z kritických aktiv každého úřadu. Nezávisle na prostředkové typizaci je nutné vždy mít na pozoru oblast vlastnictví a dostupnosti dat. Správa dat samotných, po boku služeb, je jedním z kritických aktiv každého úřadu.
Řádek 338: Řádek 351:
 |+\\ Vyšší kontrola\\ \\ Možnost vyšší kybernetické bezpečnosti\\ \\ V dlouhém měřítku může být levnější\\ \\ -\\ \\ Nižší flexibilita|+\\ \\ Vysoká flexibilita\\ \\ Možná lepší prvotní nastavení kybernetické bezpečnosti\\ \\ V krátkém měříku může být výhodnější\\ \\ -\\ \\ Nižší kontrola| |+\\ Vyšší kontrola\\ \\ Možnost vyšší kybernetické bezpečnosti\\ \\ V dlouhém měřítku může být levnější\\ \\ -\\ \\ Nižší flexibilita|+\\ \\ Vysoká flexibilita\\ \\ Možná lepší prvotní nastavení kybernetické bezpečnosti\\ \\ V krátkém měříku může být výhodnější\\ \\ -\\ \\ Nižší kontrola|
  
 +<WRAP center round info 60%>
 Příklad: Příklad:
  
Řádek 343: Řádek 357:
  
 Avšak již nyní obecně je doporučené rozdělit hardwarovou a softwarovou část tak, aby se dala tvořit flexibilní modulární řešení. Díky tomu se otevírá možnost znovu-použitelnosti, sdílení služeb, virtualizace, kontejnerizace a přístupu SOA (službově orientovaná architektura). Rozdělením na hardwarovou a softwarovou část je nejen umožněno nasazení do cloudu, ale i díky tomuto rozdělení je implementace cloudového řešení usnadněna. Avšak již nyní obecně je doporučené rozdělit hardwarovou a softwarovou část tak, aby se dala tvořit flexibilní modulární řešení. Díky tomu se otevírá možnost znovu-použitelnosti, sdílení služeb, virtualizace, kontejnerizace a přístupu SOA (službově orientovaná architektura). Rozdělením na hardwarovou a softwarovou část je nejen umožněno nasazení do cloudu, ale i díky tomuto rozdělení je implementace cloudového řešení usnadněna.
 +
 +</WRAP>
  
 === Časový horizont provozu ICT řešení === === Časový horizont provozu ICT řešení ===
Řádek 358: Řádek 374:
 Možnost rozdělení nebo slučování soutěží na jednotlivé systémy musí odpovídat požadavkům 3E, IK úřadu, strategickému konceptu ICT řešení, operačnímu konceptu ICT řešení a dalším strategiím úřadu. Možnost rozdělení nebo slučování soutěží na jednotlivé systémy musí odpovídat požadavkům 3E, IK úřadu, strategickému konceptu ICT řešení, operačnímu konceptu ICT řešení a dalším strategiím úřadu.
  
 +<WRAP center round info 60%>
 Příklad: Příklad:
  
 Strategií úřadu je převést všechny provozní systémy do privátního cloudu. Po vybudování eGov cloudu se úřadu vyplatí dát všechny své provozní systémy do veřejného cloudu a tak to i učiní. Strategií úřadu je převést všechny provozní systémy do privátního cloudu. Po vybudování eGov cloudu se úřadu vyplatí dát všechny své provozní systémy do veřejného cloudu a tak to i učiní.
  
-====== Výhody a správná aplikace modularity ======+</WRAP> 
 + 
 +===== Výhody a správná aplikace modularity =====
  
 Jedním z hlavních výhod modularity a její standardizace je navržení stavebních bloků (v literatuře a materiálech uváděné též jako building blocks), které se podílejí na stavbě funkčních celků. Specifikovaní stavebních bloků, je možno vykonat pěti způsoby (tabulka 1). Krom samotného sběru požadavků pro samotné ICT řešení lze ten sběr znovu využít pro standardizace stavebních bloků architektury eGovernmentu. Jedním z hlavních výhod modularity a její standardizace je navržení stavebních bloků (v literatuře a materiálech uváděné též jako building blocks), které se podílejí na stavbě funkčních celků. Specifikovaní stavebních bloků, je možno vykonat pěti způsoby (tabulka 1). Krom samotného sběru požadavků pro samotné ICT řešení lze ten sběr znovu využít pro standardizace stavebních bloků architektury eGovernmentu.
Řádek 379: Řádek 398:
 |Vybudován jedním OVS (nebo pověřeným komerčním subjektem) za účelem poskytování za úplatu (např. převodem rozpočtové položky).|* Úřady přesně vědí, pakliže se podílí na nakoupení stavebního bloku, co nakupují s jasně definovanými požadavky\\ * Úřad přesně ví, co může přesunutím rozpočtové položky sdílet s jinými úřady\\ * Nebo možný podklad pro vznik dalších forem stavebních bloků                                                                                                                                                                                                                                                                                                                                 | |Vybudován jedním OVS (nebo pověřeným komerčním subjektem) za účelem poskytování za úplatu (např. převodem rozpočtové položky).|* Úřady přesně vědí, pakliže se podílí na nakoupení stavebního bloku, co nakupují s jasně definovanými požadavky\\ * Úřad přesně ví, co může přesunutím rozpočtové položky sdílet s jinými úřady\\ * Nebo možný podklad pro vznik dalších forem stavebních bloků                                                                                                                                                                                                                                                                                                                                 |
  
-===== Modularita technologický a dodavatelský pohled =====+==== Modularita technologický a dodavatelský pohled ====
  
 Modularita je podstatným požadavek pro udržitelnost ICT řešení, jež nevykonávají triviální funkce. Umožňuje lepší správu ICT řešení a možnost rozvoje i po delší dobu provozu. Je nutné jít rozdělit na dva stupně: Modularita je podstatným požadavek pro udržitelnost ICT řešení, jež nevykonávají triviální funkce. Umožňuje lepší správu ICT řešení a možnost rozvoje i po delší dobu provozu. Je nutné jít rozdělit na dva stupně:
Řádek 386: Řádek 405:
   * ICT řešení je objednáván od více dodavatelů (při splnění předchozí podmínky) – a přidaná hodnota integrace je vytvářena (třeba i sub dodávkou) na straně úřadu   * ICT řešení je objednáván od více dodavatelů (při splnění předchozí podmínky) – a přidaná hodnota integrace je vytvářena (třeba i sub dodávkou) na straně úřadu
  
-==== Modularita ve vtahu k řízení jednotlivých modulů a jejich životních cyklů ====+=== Modularita ve vtahu k řízení jednotlivých modulů a jejich životních cyklů ===
  
 Přechodem od monolitického řešení je možné flexibilních řízení životních cyklu jednotlivých modulů, jenž jsou nezávislé nad životních cyklem svrchovaného a souhrnného informačního ICT řešení. Při dostatečné míře modularity je téže možné upravovat či nahrazovat moduly nejen jako celé portfolio, ale po jednotlivých modulech v různých časech. To umožnuje vyšší a flexibilní kontrolu nad ICT řešením, neboť je možné spravovat každý modul zvlášť, a každý modul může mít svého dodavatele se svým životním cyklem, a to i mimo výše zmíněný hlavních životní ICT řešení. Tím se jedná i o jednu z možných efektivních obran proti vendor lock-in efektu. Přechodem od monolitického řešení je možné flexibilních řízení životních cyklu jednotlivých modulů, jenž jsou nezávislé nad životních cyklem svrchovaného a souhrnného informačního ICT řešení. Při dostatečné míře modularity je téže možné upravovat či nahrazovat moduly nejen jako celé portfolio, ale po jednotlivých modulech v různých časech. To umožnuje vyšší a flexibilní kontrolu nad ICT řešením, neboť je možné spravovat každý modul zvlášť, a každý modul může mít svého dodavatele se svým životním cyklem, a to i mimo výše zmíněný hlavních životní ICT řešení. Tím se jedná i o jednu z možných efektivních obran proti vendor lock-in efektu.
 +<WRAP center round info 60%>
  
-Příklad 3+Příklad:
  
 Mějme celostátní informační systém veřejné správy. Obsáhlejší změnou legislativy dochází ke změnám v procesech, jenž jsou technicky podporovány a řešeny několika dílčími komponentami (moduly). V případě této změny stačí upravit pouze tyto moduly a není nutné zasahovat do zbytku informačního systému. Mějme celostátní informační systém veřejné správy. Obsáhlejší změnou legislativy dochází ke změnám v procesech, jenž jsou technicky podporovány a řešeny několika dílčími komponentami (moduly). V případě této změny stačí upravit pouze tyto moduly a není nutné zasahovat do zbytku informačního systému.
  
 Mějme informační systém, kde analytický sub-systém zastaral. Díky modularitě řešení je analytický možno nahradit snadno a to řešením, jež podporuje nejmodernější trendy v oblasti analýzy dat (např. strojové učení, velká data). Mějme informační systém, kde analytický sub-systém zastaral. Díky modularitě řešení je analytický možno nahradit snadno a to řešením, jež podporuje nejmodernější trendy v oblasti analýzy dat (např. strojové učení, velká data).
 +
 +</WRAP>
  
 Avšak aby princip modulárního řešení byl funkční (a téže splňoval obranu proti vendor-lock-inu), je nutné myslet na způsob komunikace mezi těmito moduly. V případě specifikace komunikačního rozhraní, je tedy zásadní nastavit pravidla a standardy tak, aby je mohli využívat nezávisle (finančně, technologicky aj.) i další strany/potenciální další dodavatelé. Avšak aby princip modulárního řešení byl funkční (a téže splňoval obranu proti vendor-lock-inu), je nutné myslet na způsob komunikace mezi těmito moduly. V případě specifikace komunikačního rozhraní, je tedy zásadní nastavit pravidla a standardy tak, aby je mohli využívat nezávisle (finančně, technologicky aj.) i další strany/potenciální další dodavatelé.
  
-Příklad 4+<WRAP center round info 60%> 
 +Příklad:
  
 Mějme informační systém s celorepublikovou působností. Systém sice „moduly“ obsahuje, avšak jsou dodávány pomocí jednoho dodavatele. Navíc tyto moduly jsou propojeny proprietárním komunikačním rozhraním z dílny toho stejného dodavatele. Přestože systém obsahuje „moduly“, tak se nedá říci, že naplňuje princip modularity popisovaným a doporučovaným v této metodice. Mějme informační systém s celorepublikovou působností. Systém sice „moduly“ obsahuje, avšak jsou dodávány pomocí jednoho dodavatele. Navíc tyto moduly jsou propojeny proprietárním komunikačním rozhraním z dílny toho stejného dodavatele. Přestože systém obsahuje „moduly“, tak se nedá říci, že naplňuje princip modularity popisovaným a doporučovaným v této metodice.
  
-==== Modularita podpořená více dodavateli – manažerské zajištění integrace na straně objednatele ====+</WRAP> 
 + 
 +=== Modularita podpořená více dodavateli – manažerské zajištění integrace na straně objednatele ===
  
 Dalším možným krokem k zvýšení modularity ICT řešení je možné celý informační systém rozdělit na více zakázek a přidanou hodnotu integrace vytvářet na straně objednavatele. Nebo integraci objednat, jako sub dodávku od dalšího dodavatele. Nebo další možností je objednat modulární dílo od jednoho dodavatel a mít možnost měnit dodavatele správce jednotlivých modulů. Míra rozdělení musí odpovídat zásadám 3E, schopnosti řídit rizika a schopnosti integrace. Dalším možným krokem k zvýšení modularity ICT řešení je možné celý informační systém rozdělit na více zakázek a přidanou hodnotu integrace vytvářet na straně objednavatele. Nebo integraci objednat, jako sub dodávku od dalšího dodavatele. Nebo další možností je objednat modulární dílo od jednoho dodavatel a mít možnost měnit dodavatele správce jednotlivých modulů. Míra rozdělení musí odpovídat zásadám 3E, schopnosti řídit rizika a schopnosti integrace.
Řádek 413: Řádek 438:
 |Modulární ICT řešení od více dodavatelů s vlastní integrací                                             |Existuje vysoká znalost o ICT řešení uvnitř organizace a velká část přidané hodnoty vzniká uvnitř organizace. Změny jsou snadné.                           |Uvnitř úřadu musí existovat schopnost řídit komplexní projekty rychle a efektivně. Musí existovat schopnosti vývoje vlastních celků (již jen pro schopnost sub dodávek). A to vše na úrovni komerčních firem.\\ \\ Dále je nutno zajistit dobré rozvržení rozhraní a spolupráce. Jakékoliv zpoždění či nefunkční stav na jakékoliv nezbytné komponentě způsobuje ohrožení projektu ICT řešení.| |Modulární ICT řešení od více dodavatelů s vlastní integrací                                             |Existuje vysoká znalost o ICT řešení uvnitř organizace a velká část přidané hodnoty vzniká uvnitř organizace. Změny jsou snadné.                           |Uvnitř úřadu musí existovat schopnost řídit komplexní projekty rychle a efektivně. Musí existovat schopnosti vývoje vlastních celků (již jen pro schopnost sub dodávek). A to vše na úrovni komerčních firem.\\ \\ Dále je nutno zajistit dobré rozvržení rozhraní a spolupráce. Jakékoliv zpoždění či nefunkční stav na jakékoliv nezbytné komponentě způsobuje ohrožení projektu ICT řešení.|
  
 +<WRAP center round info 60%>
 Příklad: Příklad:
  
Řádek 419: Řádek 445:
 Jiný úřad si pořizoval rozsáhlý systém, kde jako součást exit strategie je možno ukončit spolupráci na částech pořizovaného systému (který je modulární) dle požadavku úřadu. Jiný úřad si pořizoval rozsáhlý systém, kde jako součást exit strategie je možno ukončit spolupráci na částech pořizovaného systému (který je modulární) dle požadavku úřadu.
  
-====== Souvislost požadavků, zadávacího řízení a udržitelnosti ICT řešení v průběhu jeho životního cyklu ======+</WRAP>
  
-===== Souvislost provozních modelů a občanského zákoníků  =====+===== Souvislost požadavků, zadávacího řízení a udržitelnosti ICT řešení v průběhu jeho životního cyklu ===== 
 + 
 +==== Souvislost provozních modelů a občanského zákoníků  ====
  
 Bez ohledu nad zvoleným typem provozu se veškeré právní aspekty a dopady řídí platnou legislativou (viz občanský zákoník aj.) To, co v daném smluvním materiálu není specifikováno, se řídí obecnými předpisy a zvyklostmi, tedy jejich výklad je více otevřený na interpretaci v daném prostředí. Bez ohledu nad zvoleným typem provozu se veškeré právní aspekty a dopady řídí platnou legislativou (viz občanský zákoník aj.) To, co v daném smluvním materiálu není specifikováno, se řídí obecnými předpisy a zvyklostmi, tedy jejich výklad je více otevřený na interpretaci v daném prostředí.
Řádek 427: Řádek 455:
 Z tohoto legislativního principu vyplývá, že je nutno jakékoliv smluvní vztahy koncipovat takovým způsobem, aby byly v rámci smlouvy právně specifikované, dokazatelné a následně vymahatelné. Tohoto stavu si musí úřad být vědom. Z tohoto legislativního principu vyplývá, že je nutno jakékoliv smluvní vztahy koncipovat takovým způsobem, aby byly v rámci smlouvy právně specifikované, dokazatelné a následně vymahatelné. Tohoto stavu si musí úřad být vědom.
  
 +<WRAP center round info 60%>
 Příklad: Příklad:
  
 Nechť je v existence informační systém, jenž schraňuje důležitá data. Tento systém je provozován (vysoutěžen) soukromou firmou. Následně v průběhu provozu byl tento systém postižen kritickým výpadkem, kdy došlo k neobnovitelné ztrátě dat. Tento typ události byl smluvně ošetřen, avšak nebyla smluvně stanovena žádná sankce. Úřad, tedy přišel nenávratně o data a navíc dále ani nebyl schopen vymáhat kompenzaci za tento výpadek. Nechť je v existence informační systém, jenž schraňuje důležitá data. Tento systém je provozován (vysoutěžen) soukromou firmou. Následně v průběhu provozu byl tento systém postižen kritickým výpadkem, kdy došlo k neobnovitelné ztrátě dat. Tento typ události byl smluvně ošetřen, avšak nebyla smluvně stanovena žádná sankce. Úřad, tedy přišel nenávratně o data a navíc dále ani nebyl schopen vymáhat kompenzaci za tento výpadek.
  
-===== Možnost rozdělení rolí =====+</WRAP> 
 + 
 +==== Možnost rozdělení rolí ====
  
 Celý vývoj ICT řešení lze rozdělit, ve smyslu úloh nikoliv modularity, do několika rolí, jež nemusí být obsazeny stejnými osobami či organizacemi. Ovšem úroveň dělby práce a outsourcing **musí odpovídat nárokům 3E.** Přidanou hodnotou této služby je a mělo by být i odhad pracnosti a nákladovosti jednotlivých požadavků. Celý vývoj ICT řešení lze rozdělit, ve smyslu úloh nikoliv modularity, do několika rolí, jež nemusí být obsazeny stejnými osobami či organizacemi. Ovšem úroveň dělby práce a outsourcing **musí odpovídat nárokům 3E.** Přidanou hodnotou této služby je a mělo by být i odhad pracnosti a nákladovosti jednotlivých požadavků.
Řádek 444: Řádek 475:
 |Provoz                       |Provoz díla                                   |Kontrola provozu díla                   | |Provoz                       |Provoz díla                                   |Kontrola provozu díla                   |
  
 +<WRAP center round info 60%>
 Příklad: Příklad:
  
 Středně velký úřad se rozhodne pořídit nový informační systém. Návrh Solution architektury a funkční a nefunkční požadavků si nechá dodat od externího poradce s dobrými referencemi. Kontrolu jim dodaného návrhu zvládne sám. Solution design je ponechán v rukou dodavatel, pakliže se bude držet vymezených mezí Solution architektury Zadávací dokumentaci včetně návrhu smluv si nachá zpracovat od renomované právní kanceláře. Přebrání díla zajistí poradce. Na implementaci vypíše další výběrové řízení (protože k němu má již dokumentaci z předchozích kroků). Středně velký úřad se rozhodne pořídit nový informační systém. Návrh Solution architektury a funkční a nefunkční požadavků si nechá dodat od externího poradce s dobrými referencemi. Kontrolu jim dodaného návrhu zvládne sám. Solution design je ponechán v rukou dodavatel, pakliže se bude držet vymezených mezí Solution architektury Zadávací dokumentaci včetně návrhu smluv si nachá zpracovat od renomované právní kanceláře. Přebrání díla zajistí poradce. Na implementaci vypíše další výběrové řízení (protože k němu má již dokumentaci z předchozích kroků).
  
-=====  Rozdělení na dodavatele a implementátora =====+</WRAP> 
 + 
 +====  Rozdělení na dodavatele a implementátora ====
  
 Při pořizování ICT řešení je vhodné rozdělit pořízení a dodávku na řešení na dva dílčí kroky, které na sebe časově navazují. Jedním je samotná tvorba a tedy i pořízení ICT řešení. Druhým je pak implementace ICT řešení a uvedení do provozu. Tímto rozdělením se tento proces dá jako celek zefektivnit, neboť toto oddělení dodavatele a implementátora umožňuje optimální výběr specializovaných stran pro daný typ úkonu. Při pořizování ICT řešení je vhodné rozdělit pořízení a dodávku na řešení na dva dílčí kroky, které na sebe časově navazují. Jedním je samotná tvorba a tedy i pořízení ICT řešení. Druhým je pak implementace ICT řešení a uvedení do provozu. Tímto rozdělením se tento proces dá jako celek zefektivnit, neboť toto oddělení dodavatele a implementátora umožňuje optimální výběr specializovaných stran pro daný typ úkonu.
Řádek 460: Řádek 494:
 Smyslem tohoto rozdělení je, že může nastat situace (vždy je nutné posoudit), kdy existuje strana, která je excelentní v oblasti vývoje, avšak se vůbec nezabývá implementací. A naopak existuje druhá strana, která je na tom opačně, tedy umožňuje excelentní implementaci, ale sama se vývojem nezabývá, nebo nemá patřičné schopnosti. Smyslem tohoto rozdělení je, že může nastat situace (vždy je nutné posoudit), kdy existuje strana, která je excelentní v oblasti vývoje, avšak se vůbec nezabývá implementací. A naopak existuje druhá strana, která je na tom opačně, tedy umožňuje excelentní implementaci, ale sama se vývojem nezabývá, nebo nemá patřičné schopnosti.
  
-===== Zdroje vendor lock in efektu pohled licenční politiky a znalosti ICT řešení =====+==== Zdroje vendor lock in efektu pohled licenční politiky a znalosti ICT řešení ====
  
 Za účelem provozu informačních systémů je nezbytné zvolit správnou licenční politiku a podmínky pro výběr podporovaných řešení za účelem dosažení cílů **3E.** Nevýhodný Vendor lock-in, tj. situace kdy dodavatel zneužívá svého dominantního postavení, je proti zásadám 3E. Typicky následujícím způsobem: Za účelem provozu informačních systémů je nezbytné zvolit správnou licenční politiku a podmínky pro výběr podporovaných řešení za účelem dosažení cílů **3E.** Nevýhodný Vendor lock-in, tj. situace kdy dodavatel zneužívá svého dominantního postavení, je proti zásadám 3E. Typicky následujícím způsobem:
Řádek 476: Řádek 510:
 Lze si představit situace kdy sice úřad má dobře nastavené licenční podmínky, ale ICT řešení je natolik obskurní že ho nelze spravovat. A naopak systém je dobře a velice znám, ale licenční politika je tak nevýhodná, že to nemění situaci. A proto je nezbytné stanovit příslušná kvalifikační kritéria na technologickou základnu řešení (např.: „Databázová technologie je mezi 10 světové nejpoužívanějšími na světě“ nebo v případě požadavku na open source: „Serverová platforma je mezi 5 pěti nejvíce používanými open source serverových platforem nabízených s podporou“). Lze si představit situace kdy sice úřad má dobře nastavené licenční podmínky, ale ICT řešení je natolik obskurní že ho nelze spravovat. A naopak systém je dobře a velice znám, ale licenční politika je tak nevýhodná, že to nemění situaci. A proto je nezbytné stanovit příslušná kvalifikační kritéria na technologickou základnu řešení (např.: „Databázová technologie je mezi 10 světové nejpoužívanějšími na světě“ nebo v případě požadavku na open source: „Serverová platforma je mezi 5 pěti nejvíce používanými open source serverových platforem nabízených s podporou“).
  
-===== Doporučení v licenční politice =====+==== Doporučení v licenční politice ====
  
 **V situacích vývoje na míru potřebám úřadu,** pakliže nebudou rizika pokryta jinak, dle specifických požadavků, **musí buď být dílo** vedeno pod (zde se jedná o zásady Z16 a Z17): **V situacích vývoje na míru potřebám úřadu,** pakliže nebudou rizika pokryta jinak, dle specifických požadavků, **musí buď být dílo** vedeno pod (zde se jedná o zásady Z16 a Z17):
Řádek 487: Řádek 521:
 Důležité je mít na paměti že i v případě propriálního systému nebo jazykového vybavení je stále možné toto zajisti (pakliže tomu nebrání jiné situace, např. výslovný zákaz). Důležité je mít na paměti že i v případě propriálního systému nebo jazykového vybavení je stále možné toto zajisti (pakliže tomu nebrání jiné situace, např. výslovný zákaz).
  
 +<WRAP center round info 60%>
 Příklad: Příklad:
  
 Úřad provozuje podnikový ekonomický systém v nevýhradní licenci. Vznikl požadavek na vytvoření specifické funkcionality. Tento modul již úřad otevře jako open source, protože je očekávané situace že další uživatelé onen otevřený modul (byť třeba v proprietárním jazyce) použijí též a dojde k jeho rozvoji. Úřad provozuje podnikový ekonomický systém v nevýhradní licenci. Vznikl požadavek na vytvoření specifické funkcionality. Tento modul již úřad otevře jako open source, protože je očekávané situace že další uživatelé onen otevřený modul (byť třeba v proprietárním jazyce) použijí též a dojde k jeho rozvoji.
  
-===== Výhody a rizika jednotlivých přístupů k licenčním právům a službám =====+</WRAP> 
 + 
 +==== Výhody a rizika jednotlivých přístupů k licenčním právům a službám ====
  
 Zvolení a správa jednotlivých typů licenčních ujednání, nebo využití služby, ze své podstaty přináší různé klady, ale i negativa. Zvolení a správa jednotlivých typů licenčních ujednání, nebo využití služby, ze své podstaty přináší různé klady, ale i negativa.
Řádek 504: Řádek 541:
 |Služby                           |* Nejsou počáteční investiční náklady\\ * Přechod může být plynulejší\\ * Můžou dobře řešit dočasné požadavky                                                      |* V dlouhodobém horizontu se nemusí vyplatit\\ * Nelze ze své podstaty do těchto služeb nikdy investovat.\\ * Nutno připravit dobrou migrační politiku\\ (to je zapotřebí všude, avšak je potřeba myslet na specifika služeb)| |Služby                           |* Nejsou počáteční investiční náklady\\ * Přechod může být plynulejší\\ * Můžou dobře řešit dočasné požadavky                                                      |* V dlouhodobém horizontu se nemusí vyplatit\\ * Nelze ze své podstaty do těchto služeb nikdy investovat.\\ * Nutno připravit dobrou migrační politiku\\ (to je zapotřebí všude, avšak je potřeba myslet na specifika služeb)|
  
-=====  Homogenní a heterogenní přístup k intelektuálním právům =====+====  Homogenní a heterogenní přístup k intelektuálním právům ====
  
 Přístup k intelektuálním právům na informační systém lze rozdělit na dva přístupy: Přístup k intelektuálním právům na informační systém lze rozdělit na dva přístupy:
Řádek 510: Řádek 547:
 Homogenní přístup k intelektuálním právům, nastává tehdy, když celé ICT řešení je vedeno jen pod jedním režimem vlastnických práv. Tento přístup má menší výhodu v jednodušší licenční správě, avšak někdy zbytečně dochází k újmě objednavatele tím, že dodavatel překryje celou část kódu více restriktivními podmínkami, než je nutné. Dále je nutné konstatovat, že u větších systémů tento přístup není praktický. Homogenní přístup k intelektuálním právům, nastává tehdy, když celé ICT řešení je vedeno jen pod jedním režimem vlastnických práv. Tento přístup má menší výhodu v jednodušší licenční správě, avšak někdy zbytečně dochází k újmě objednavatele tím, že dodavatel překryje celou část kódu více restriktivními podmínkami, než je nutné. Dále je nutné konstatovat, že u větších systémů tento přístup není praktický.
  
 +<WRAP center round info 60%>
 Příklad: Příklad:
  
 Úřad si chce koupit antivirový software, vlastní nebo zakázkový vývoj nemá cenu, takže je zvolena varianta nákupu standartních licencí. Úřad si chce koupit antivirový software, vlastní nebo zakázkový vývoj nemá cenu, takže je zvolena varianta nákupu standartních licencí.
 +</WRAP>
 +
 +{{ :znalostni_baze:fnp6.png?600 |}}
  
 Heterogenní přístup k intelektuálním právům, nastává tehdy, když ICT řešení je vedeno pod více režimy vlastnických práv. Tento přístup má menší administrativní nevýhodu v tom, že je nutné spravovat více typů licencí. Avšak díky tomuto přístupu a obzvláště pak v kombinaci s modulárním ICT řešení, je možné dosáhnout lepší udržitelnosti, možnosti rozvoje a efektivněji zabránit vendor lock-inu. A to následujícím způsobem: Díky možnosti přebrat správu licencí pod svojí činnost (in-sourcing), lze zajistit licenční správu ICT řešení i bez dodavatele. A to i v situaci kdy některé části jsou unikátně dodané dodavatelem, pakliže tyto části jsou řádně smluvně ošetřeny. Tyto unikátní části by měli tvořit moduly ICT řešení, aby je bylo možno nahrazovat. Heterogenní přístup k intelektuálním právům, nastává tehdy, když ICT řešení je vedeno pod více režimy vlastnických práv. Tento přístup má menší administrativní nevýhodu v tom, že je nutné spravovat více typů licencí. Avšak díky tomuto přístupu a obzvláště pak v kombinaci s modulárním ICT řešení, je možné dosáhnout lepší udržitelnosti, možnosti rozvoje a efektivněji zabránit vendor lock-inu. A to následujícím způsobem: Díky možnosti přebrat správu licencí pod svojí činnost (in-sourcing), lze zajistit licenční správu ICT řešení i bez dodavatele. A to i v situaci kdy některé části jsou unikátně dodané dodavatelem, pakliže tyto části jsou řádně smluvně ošetřeny. Tyto unikátní části by měli tvořit moduly ICT řešení, aby je bylo možno nahrazovat.
Řádek 518: Řádek 559:
 Kombinací různých režimů intelektuálních práv, lze dosáhnout optimální situace, než být ve stavu, kde je vše v licenci dodavatele. Lze si představit situace, kde ICT řešení kombinuje všechny vyjmenované licenční režimy. Databáze využívá komerčně dostupný software, operační systém je pod Open Sourcem, sběrnice je zajištěna již vlastním kódem a napojení na systémy e-Governmentu je zajištěno centrálně dodaným softwarem. Kombinací různých režimů intelektuálních práv, lze dosáhnout optimální situace, než být ve stavu, kde je vše v licenci dodavatele. Lze si představit situace, kde ICT řešení kombinuje všechny vyjmenované licenční režimy. Databáze využívá komerčně dostupný software, operační systém je pod Open Sourcem, sběrnice je zajištěna již vlastním kódem a napojení na systémy e-Governmentu je zajištěno centrálně dodaným softwarem.
  
 +
 +
 +<WRAP center round info 60%>
 Příklad: Příklad:
  
 Úřad chce spustit nový agendový informační systém. Dodavatel dodá informační systém, kde servery jsou provozovány na operačním systému v režimu Open Source, ale dodavatel zajištuje podporu. Protože úřad již provozuje značnou část svým databází jako komerční a běžně dostupné řešení, bude tato databáze implementována do současného řešení (tento krok je opřen o informační koncepci daného úřadu). Část systému obsahuje řešení, jež plně vlastní úřad. Úřad chce spustit nový agendový informační systém. Dodavatel dodá informační systém, kde servery jsou provozovány na operačním systému v režimu Open Source, ale dodavatel zajištuje podporu. Protože úřad již provozuje značnou část svým databází jako komerční a běžně dostupné řešení, bude tato databáze implementována do současného řešení (tento krok je opřen o informační koncepci daného úřadu). Část systému obsahuje řešení, jež plně vlastní úřad.
 +
 +</WRAP>
  
 Režimy vlastnění jsou následující: Režimy vlastnění jsou následující:
Řádek 542: Řádek 588:
 Je možné, že v některých případech může být pořízen software, který bude pořízen pro všeobecné použití ve veřejné správě. Bude se pravděpodobně jednat o běžně komerčně využívaný software. Je možné, že v některých případech může být pořízen software, který bude pořízen pro všeobecné použití ve veřejné správě. Bude se pravděpodobně jednat o běžně komerčně využívaný software.
  
-===== Požadavky na ICT řešení a zadávání veřejné zakázky =====+==== Požadavky na ICT řešení a zadávání veřejné zakázky ====
  
 Všechny požadavky, které jsou známy před, jež by mělo být maximum. Je nutné přepsat do předmětu veřejné zakázky a vzorových smluv k ním přiložených. Všechny požadavky, které jsou známy před, jež by mělo být maximum. Je nutné přepsat do předmětu veřejné zakázky a vzorových smluv k ním přiložených.
  
-==== Práva stran, autorská práva majetková a osobní ====+=== Práva stran, autorská práva majetková a osobní ===
  
 Rozsah práv v oblasti duševního vlastnictví je vhodné nastavit co nejvíce ve prospěch orgánu veřejné moci jakožto zadavatele, jestliže je to hospodárné a technicky účelné. Obecně platí, že pokud je dané řešení na základě poptávky zadavatele přímo vyvíjeno a implementováno, měl by zadavatel mít k tomuto řešení sjednán maximální rozsah práv, zejména právo ke zdrojovému kódu, právo řešení upravovat jiným subjektem, postupovat jej jinému subjektu apod. Je tomu tak proto, že je to právě zadavatel, kdo hradí vývoj daného řešení a je tedy nanejvýš vhodné, aby zadavatel měl nad tímto řešení maximální ekonomickou a technickou kontrolu, nikoliv aby toto zadavatelem uhrazené plnění dodavatel dále zpeněžoval. Naopak pokud je poskytováno široce dostupné řešení, vyvinuté nákladem dodavatele a totožné či podobné pro všechny zákazníky, tj. tzv. krabicové řešení, které lze zároveň snadno nahradit, není nutné mít maximální rozsah práv sjednán, neboť by to nebylo účelné a hospodářská náročnost by byla neodpovídající. Přesto i v tomto případě by měl mít zadavatel sjednán adekvátní oprávnění, pokud jde o úpravy řešení, sublicencování, apod., zejména s přihlédnutím k vnitřním procesům (tj. vazby licencí na stanice vs. na zaměstnance, zahrnutí např. pravidelných úprav podle změn legislativy, oprávnění k licencím pro podřízené organizace, apod.). Rozsah práv v oblasti duševního vlastnictví je vhodné nastavit co nejvíce ve prospěch orgánu veřejné moci jakožto zadavatele, jestliže je to hospodárné a technicky účelné. Obecně platí, že pokud je dané řešení na základě poptávky zadavatele přímo vyvíjeno a implementováno, měl by zadavatel mít k tomuto řešení sjednán maximální rozsah práv, zejména právo ke zdrojovému kódu, právo řešení upravovat jiným subjektem, postupovat jej jinému subjektu apod. Je tomu tak proto, že je to právě zadavatel, kdo hradí vývoj daného řešení a je tedy nanejvýš vhodné, aby zadavatel měl nad tímto řešení maximální ekonomickou a technickou kontrolu, nikoliv aby toto zadavatelem uhrazené plnění dodavatel dále zpeněžoval. Naopak pokud je poskytováno široce dostupné řešení, vyvinuté nákladem dodavatele a totožné či podobné pro všechny zákazníky, tj. tzv. krabicové řešení, které lze zároveň snadno nahradit, není nutné mít maximální rozsah práv sjednán, neboť by to nebylo účelné a hospodářská náročnost by byla neodpovídající. Přesto i v tomto případě by měl mít zadavatel sjednán adekvátní oprávnění, pokud jde o úpravy řešení, sublicencování, apod., zejména s přihlédnutím k vnitřním procesům (tj. vazby licencí na stanice vs. na zaměstnance, zahrnutí např. pravidelných úprav podle změn legislativy, oprávnění k licencím pro podřízené organizace, apod.).
Řádek 557: Řádek 603:
 A je nezbytné zajistit si oba typy práv, pakliže dochází k vývoji na míru, nebo dle požadavků úřadu, nebo v jiných případech kdy je to příhodno. A to ve vyžadovaném rozsahu (nebo rozsahu větším, avšak vždy tak aby smluvní klauzule s úžeji definovanými právy (avšak dostatečnými právy) byla platná)). A je nezbytné zajistit si oba typy práv, pakliže dochází k vývoji na míru, nebo dle požadavků úřadu, nebo v jiných případech kdy je to příhodno. A to ve vyžadovaném rozsahu (nebo rozsahu větším, avšak vždy tak aby smluvní klauzule s úžeji definovanými právy (avšak dostatečnými právy) byla platná)).
  
 +<WRAP center round info 60%>
 Příklad: Příklad:
  
 Úřad si chce nechat vyvinout část řešení pod otevřenou licencí. Součást podmínek dodání díla je i vypořádání i autorského právo osobního. Autoři díla dají souhlas k využití jejich díla v rozsahu dané licence. Úřad si chce nechat vyvinout část řešení pod otevřenou licencí. Součást podmínek dodání díla je i vypořádání i autorského právo osobního. Autoři díla dají souhlas k využití jejich díla v rozsahu dané licence.
  
-==== Další rozvoj ====+</WRAP> 
 + 
 +=== Další rozvoj ===
  
 Je zřejmé, že plnění v oblasti informačních a komunikačních technologií není plněním jednorázovým, nýbrž je založeno na průběžném dodávání plnění. Zadavatel musí tuto potřebu dalších plnění, zejména pokud jde o aktualizace, reakce na vývoj legislativy, reakce na vývoj v oblasti kybernetické bezpečnosti, adekvátně anticipovat a případně využít např. rámcovou smlouvu, sjednání opce, apod., a toto další anticipované plnění adekvátně zohlednit v zadávací dokumentaci. Je zřejmé, že plnění v oblasti informačních a komunikačních technologií není plněním jednorázovým, nýbrž je založeno na průběžném dodávání plnění. Zadavatel musí tuto potřebu dalších plnění, zejména pokud jde o aktualizace, reakce na vývoj legislativy, reakce na vývoj v oblasti kybernetické bezpečnosti, adekvátně anticipovat a případně využít např. rámcovou smlouvu, sjednání opce, apod., a toto další anticipované plnění adekvátně zohlednit v zadávací dokumentaci.
  
-===== Správa, podpora, rozvoj, údržba ICT řešení jako součást zadávacího řízení a úvodní dodávky a jako předmět následujících výběrových řízení  =====+==== Správa, podpora, rozvoj, údržba ICT řešení jako součást zadávacího řízení a úvodní dodávky a jako předmět následujících výběrových řízení  ====
  
 Při koncipování smluv a dlouhodobých plánů pro pořízení ICT řešení je potřeba vyházet z toho že je v případě ICT řešení na mírů úřadu, lze vycházet z předpokladu, že ten kdo řešení vybudoval, bude ICT řešení lépe než ostatní, než kdokoliv jiný (a to i přes doporučováno variantu používání co nejvíce standartních řešení, jak otevřených tak komerčně užívaných). Snahou je přesunout a co nejvíce znalostí do širšího pole působení, pokud možno otevřenou licencí. Ale nelze se vyhnout faktu, že informace (tj. znalostí) jsou ve společnosti distribuovány asymetricky a asynchronně. Z tohoto důvodu je ve většině případů vhodné, díky této informační asymetrii spojit vybudování, správu, podporu, rozvoj a údržbu do jedné zakázky. Dalším důvodem je, že pakliže dodavatel řešení pověřen i budoucí správou, tak je spíše motivován vybudovat udržitelné ICT řešení, protože ono ICT řešení bude spravovat i nadále. Obecně jsou lepší dlouhodobější vztahy pro správu ICT sofistikovaných řešení. U vztahů komoditního typu je na otázce optimalizace kapacit a fixace cen. Při koncipování smluv a dlouhodobých plánů pro pořízení ICT řešení je potřeba vyházet z toho že je v případě ICT řešení na mírů úřadu, lze vycházet z předpokladu, že ten kdo řešení vybudoval, bude ICT řešení lépe než ostatní, než kdokoliv jiný (a to i přes doporučováno variantu používání co nejvíce standartních řešení, jak otevřených tak komerčně užívaných). Snahou je přesunout a co nejvíce znalostí do širšího pole působení, pokud možno otevřenou licencí. Ale nelze se vyhnout faktu, že informace (tj. znalostí) jsou ve společnosti distribuovány asymetricky a asynchronně. Z tohoto důvodu je ve většině případů vhodné, díky této informační asymetrii spojit vybudování, správu, podporu, rozvoj a údržbu do jedné zakázky. Dalším důvodem je, že pakliže dodavatel řešení pověřen i budoucí správou, tak je spíše motivován vybudovat udržitelné ICT řešení, protože ono ICT řešení bude spravovat i nadále. Obecně jsou lepší dlouhodobější vztahy pro správu ICT sofistikovaných řešení. U vztahů komoditního typu je na otázce optimalizace kapacit a fixace cen.
Řádek 589: Řádek 638:
 S dobou plánovaného provozu ICT řešení se pojí požadavky na udržitelnost ICT řešení, která musí být v souladu s plánovanou dobou provozu, nebo musí být zajištěna adekvátní technologická náhrada zastarávajících součástí. S dobou plánovaného provozu ICT řešení se pojí požadavky na udržitelnost ICT řešení, která musí být v souladu s plánovanou dobou provozu, nebo musí být zajištěna adekvátní technologická náhrada zastarávajících součástí.
  
-====== Pořízení ICT řešení je samostatným projektem se svými požadavky ======+===== Pořízení ICT řešení je samostatným projektem se svými požadavky =====
  
 Pořízení ICT řešení je sám o sobě samostatným projektem z čehož plyne: Pořízení ICT řešení je sám o sobě samostatným projektem z čehož plyne:
Řádek 597: Řádek 646:
   - Zavedení, obnova, rozvoj nebo rozšíření informačního ICT řešení přinese změny v organizaci.   - Zavedení, obnova, rozvoj nebo rozšíření informačního ICT řešení přinese změny v organizaci.
  
-===== Pořízení ICT řešení jako součást širšího procesu organizační změny =====+==== Pořízení ICT řešení jako součást širšího procesu organizační změny ====
  
 Samotné pořízení ICT řešení je součástí širší organizační změny, jež musí být Samotné pořízení ICT řešení je součástí širší organizační změny, jež musí být
  
-==== Činnosti související se zaváděním nového ICT řešení ====+=== Činnosti související se zaváděním nového ICT řešení ===
  
 Zavádění ICT řešení je a má být zasazeno do širšího kontextu (viz graf X hierarchický popis souvisejících činností) mnohem obsáhlejšího projektu. V grafu je znázorněno, jak proces zavádění souvisí s dalšími činnostmi. Zavádění ICT řešení je a má být zasazeno do širšího kontextu (viz graf X hierarchický popis souvisejících činností) mnohem obsáhlejšího projektu. V grafu je znázorněno, jak proces zavádění souvisí s dalšími činnostmi.
  
-=== Stanovení byznysových cílů ===+== Stanovení byznysových cílů ==
  
 Prvním krokem při pořízení ICT řešení je stanovení si „//business objective“// v češtině cíle organizace. //Byznysové cíl// mohou být např: snížení administrativní náročnosti, tak aby bylo zapotřebí jen 25 % současného množství pracovníků“ či vedení agendy dle nového zákona. Cílů může být více. Také aplikace strategií či jiných strategických dokumentů je záhodno propsat do byznysových cílů Prvním krokem při pořízení ICT řešení je stanovení si „//business objective“// v češtině cíle organizace. //Byznysové cíl// mohou být např: snížení administrativní náročnosti, tak aby bylo zapotřebí jen 25 % současného množství pracovníků“ či vedení agendy dle nového zákona. Cílů může být více. Také aplikace strategií či jiných strategických dokumentů je záhodno propsat do byznysových cílů
  
-=== Záměr pořízení nového ICT řešení ===+== Záměr pořízení nového ICT řešení ==
  
 V této části je definována, co by mělo ICT řešení splňovat, tak aby splnil vytyčené cíle. Tento proces pořízení ICT řešení je vytyčen projektovým záměrem. V této části je definována, co by mělo ICT řešení splňovat, tak aby splnil vytyčené cíle. Tento proces pořízení ICT řešení je vytyčen projektovým záměrem.
  
-=== Organizační změny a změny kompetencí ===+== Organizační změny a změny kompetencí ==
  
 Při pořízení ICT řešení je nezbytné uvažovat o změnách v samostatné organizaci. Je vycházet z vize architektury úřadu a byznys architektury, jež má vycházet kromě jiných pravidel i z pravidel NAP, NAR a metod řízení ICT. ICT řešení je nástroje podpory výkonu činnosti. Dále je nutné změnit stavy a alokaci pracovníků a změnit kompetence. Při pořízení ICT řešení je nezbytné uvažovat o změnách v samostatné organizaci. Je vycházet z vize architektury úřadu a byznys architektury, jež má vycházet kromě jiných pravidel i z pravidel NAP, NAR a metod řízení ICT. ICT řešení je nástroje podpory výkonu činnosti. Dále je nutné změnit stavy a alokaci pracovníků a změnit kompetence.
  
-=== Zajištění dlouhodobého financování ===+== Zajištění dlouhodobého financování ==
  
 V průběhu provozu informačního ICT řešení budou kromě pořizovacích nákladů vznikat náklady další, proto je nezbytné zajistit financování a ekonomický model provozu v dlouhodobém měřítku. V průběhu provozu informačního ICT řešení budou kromě pořizovacích nákladů vznikat náklady další, proto je nezbytné zajistit financování a ekonomický model provozu v dlouhodobém měřítku.
Řádek 623: Řádek 672:
 V případě evropských dotací se kromě financích z nich obdržených pojí požadavky na udržitelnost. Z čehož plynou požadavky na podporu díla. V případě evropských dotací se kromě financích z nich obdržených pojí požadavky na udržitelnost. Z čehož plynou požadavky na podporu díla.
  
-=== Školení ===+== Školení ==
  
 Nezbytnou součástí procesu zavádění a užívání ICT řešení je nutnost proškolit uživatele či administrátory ICT řešení. Nutnost proškolení rolí odpovídá úrovni, do jaké hloubky chce úřad ICT řešení provozovat (viz. část „prostředková typizace“). A dále získat vlastní kapacitu školení do úrovně potřebné organizací, pakliže školení bude prováděno samotným úřadem. Nezbytnou součástí procesu zavádění a užívání ICT řešení je nutnost proškolit uživatele či administrátory ICT řešení. Nutnost proškolení rolí odpovídá úrovni, do jaké hloubky chce úřad ICT řešení provozovat (viz. část „prostředková typizace“). A dále získat vlastní kapacitu školení do úrovně potřebné organizací, pakliže školení bude prováděno samotným úřadem.
  
-=== Pořízení nového ICT řešení ===+** Pořízení nového ICT řešení **
  
-==  Zavedení ICT řešení ==+**  Zavedení ICT řešení **
  
 Zavedení nového ICT řešení sebou obnáší role integrace do současného prostředí, kde je nezbytné součinnost (a tedy i její smluvní a organizační zajištění) se dodavatelem současného a dodavateli, případně integrátory, současných řešení. Včetně ustanovení do provozu. Zavedení nového ICT řešení sebou obnáší role integrace do současného prostředí, kde je nezbytné součinnost (a tedy i její smluvní a organizační zajištění) se dodavatelem současného a dodavateli, případně integrátory, současných řešení. Včetně ustanovení do provozu.
  
-==  Údržba ICT řešení  ==+**  Údržba ICT řešení  **
  
 Je nutné zajistit rozpočet a organizaci údržby ICT řešení, tak aby splňoval do budoucna daná kritéria. Je nutné zajistit rozpočet a organizaci údržby ICT řešení, tak aby splňoval do budoucna daná kritéria.
  
-==  Podpora ICT řešení ==+**  Podpora ICT řešení **
  
 Je nutné myslet i na zajištění podpory ICT řešení (help desk, podpora na místě). Rozsah podpory musí odpovídat úrovni, do jaké hloubky a šířky chce úřad ICT řešení provozovat, či jaké činnosti chce provozovat interně či externě. Je nutné myslet i na zajištění podpory ICT řešení (help desk, podpora na místě). Rozsah podpory musí odpovídat úrovni, do jaké hloubky a šířky chce úřad ICT řešení provozovat, či jaké činnosti chce provozovat interně či externě.
  
-==  Rozvoj nového ICT řešení  ==+** Rozvoj nového ICT řešení  **
  
 V průběhu provozu informačního ICT řešení se budou objevovat nové požadavky na nové funkcionality, na tyto požadavky. V průběhu provozu informačního ICT řešení se budou objevovat nové požadavky na nové funkcionality, na tyto požadavky.
  
-==== Příležitosti ====+=== Příležitosti ===
  
 Každé zavedení nového informačního ICT řešení sebou obnáší příležitosti pro organizaci. Obecně jde konstatovat, že veškeré „Ohrožení“ dle SWOT matice jdou otočit na „možnosti“. Každé zavedení nového informačního ICT řešení sebou obnáší příležitosti pro organizaci. Obecně jde konstatovat, že veškeré „Ohrožení“ dle SWOT matice jdou otočit na „možnosti“.
  
-=====  Kontinuální činnosti po zavedení ICT řešení =====+{{ :znalostni_baze:fnp7.png?600 |}} 
 + 
 +====  Kontinuální činnosti po zavedení ICT řešení ====
  
 Po zavedení ICT řešení vzniknou nové kontinuálně provozované činnosti úřadem, které nejsou projektového rázu. Po zavedení ICT řešení vzniknou nové kontinuálně provozované činnosti úřadem, které nejsou projektového rázu.
  
-==== Řízení ICT řešení ====+{{ :znalostni_baze:fnp8.png?600 |}} 
 + 
 +=== Řízení ICT řešení ===
  
 Samotné ICT řešení je nezbytné řídit jak v strategické, operační tak i v zdrojové úrovni. Samotné ICT řešení je nezbytné řídit jak v strategické, operační tak i v zdrojové úrovni.
  
-==== Provoz ICT řešení ====+=== Provoz ICT řešení ===
  
 ICT řešení bude muset být provozováno, zaleží na prostředkové typizaci. ICT řešení bude muset být provozováno, zaleží na prostředkové typizaci.
  
-==== Obsluha ICT řešení ====+=== Obsluha ICT řešení ===
  
 S ICT řešením bude muset pracovat určitý počet pracovníků, kteří s ním budou muset pracovat. S ICT řešením bude muset pracovat určitý počet pracovníků, kteří s ním budou muset pracovat.
  
-==== Rozvoj ICT řešení ====+=== Rozvoj ICT řešení ===
  
 Pakliže rozsah rozvoje řešení nepřesáhne přidělené prostředky, možnosti vlastního rozvoje dle smlouvy s dodavatelem, nebo nepřesáhne pracovní síly, jež jsou k dispozici, tak menší rozvoj ICT řešení je kontinuální činností. Pakliže rozsah rozvoje řešení nepřesáhne přidělené prostředky, možnosti vlastního rozvoje dle smlouvy s dodavatelem, nebo nepřesáhne pracovní síly, jež jsou k dispozici, tak menší rozvoj ICT řešení je kontinuální činností.
  
-====== Požadavky a jejich vlastnosti ======+===== Požadavky a jejich vlastnosti =====
  
-===== Účel poždavků =====+==== Účel poždavků ====
  
 Formulování požadavků je mezidisciplinární disciplína, jež dělá mediátora mezi potřebami odběratele a dodavatele, tak aby se splnili zájmy a potřeby, které má ICT řešení, software, systém nebo služba mít. Výsledkem procesu sběru a tvorby dobrého požadavku je: Formulování požadavků je mezidisciplinární disciplína, jež dělá mediátora mezi potřebami odběratele a dodavatele, tak aby se splnili zájmy a potřeby, které má ICT řešení, software, systém nebo služba mít. Výsledkem procesu sběru a tvorby dobrého požadavku je:
Řádek 679: Řádek 732:
   - Sběr požadavků s následným vyhodnocením poskytuje základ pro návrhu architektury řešení, případně návrhu řešení (pakliže je řešeno). Dále pro formulování testovací a akceptačních scénářů, jimiž se návrh architektury řešení, případně návrhu řešení a jeho implementace ověřuje.   - Sběr požadavků s následným vyhodnocením poskytuje základ pro návrhu architektury řešení, případně návrhu řešení (pakliže je řešeno). Dále pro formulování testovací a akceptačních scénářů, jimiž se návrh architektury řešení, případně návrhu řešení a jeho implementace ověřuje.
  
-===== Definice požadavků a jejich klasifikace =====+==== Definice požadavků a jejich klasifikace ====
  
-==== Definice požadavku ====+=== Definice požadavku ===
  
 Procesně orientovaná definice: „Požadavek je cokoliv, co rozhoduje o volbách designu“ (Wiegers, 2013 p. 6) Statická definice požadavku: „Vyjádření, jež převádí nebo vyjadřuje potřebu a její asociované omezení“ (ISO/IEC/IEEE, 2011 p. 5) Procesně orientovaná definice: „Požadavek je cokoliv, co rozhoduje o volbách designu“ (Wiegers, 2013 p. 6) Statická definice požadavku: „Vyjádření, jež převádí nebo vyjadřuje potřebu a její asociované omezení“ (ISO/IEC/IEEE, 2011 p. 5)
  
-==== Opodstatněnost požadavků ====+=== Opodstatněnost požadavků ===
  
 Dobře formulovaný požadavek má následující vlastnosti Dobře formulovaný požadavek má následující vlastnosti
Řádek 694: Řádek 747:
   - Definuje výkon systému, když je používán specifickými zainteresovanými stranami nebo koresponduje se systémem, nebo schopností uživatele, operátora nebo jiné zainteresované stran   - Definuje výkon systému, když je používán specifickými zainteresovanými stranami nebo koresponduje se systémem, nebo schopností uživatele, operátora nebo jiné zainteresované stran
  
-==== Typizace a hierarchizace požadavků ====+=== Typizace a hierarchizace požadavků ===
  
 Požadavky jdou rozdělit do několika rovin. Z pozice, v jakém detailu a hierarchii jsou sbírány. Na vrcholu stojí Business požadavky (kterými jsou naplňovány byzynsové cíle), z nichž plynou požadavky zainteresovaných stran, které vedou k systémovým požadavkům. Dále existují typy požadavků, jež se třídí podle obsahových kritérií. Požadavky jdou rozdělit do několika rovin. Z pozice, v jakém detailu a hierarchii jsou sbírány. Na vrcholu stojí Business požadavky (kterými jsou naplňovány byzynsové cíle), z nichž plynou požadavky zainteresovaných stran, které vedou k systémovým požadavkům. Dále existují typy požadavků, jež se třídí podle obsahových kritérií.
  
-=== Hierarchizace požadavků ===+== Hierarchizace požadavků ==
  
 Požadavky mají svojí hierarchii jak v čase (v prvotní tvorbě systému) tak ve významu, kdy a jaké požadavky jsou nadřazeny jiným. Požadavky mají svojí hierarchii jak v čase (v prvotní tvorbě systému) tak ve významu, kdy a jaké požadavky jsou nadřazeny jiným.
Řádek 704: Řádek 757:
   - Business požadavky – jsou požadavky co má systém dělat z pohledu business funkce   - Business požadavky – jsou požadavky co má systém dělat z pohledu business funkce
   - Požadavky zainteresovaných stran – jsou požadavky, které každá zainteresovaná strana vnímá, že je potřebuje k dosažení svých cílů. (Seznam možných zainteresovaných stran je uveden v tomto materiále)   - Požadavky zainteresovaných stran – jsou požadavky, které každá zainteresovaná strana vnímá, že je potřebuje k dosažení svých cílů. (Seznam možných zainteresovaných stran je uveden v tomto materiále)
-  - Systémové požadavky – jsou požadavky na samotný systém, co konkrétního má systém dělat. Kapitola, jež se věnuje systémovým požadavků je+  - Systémové požadavky – jsou požadavky na samotný systém, co konkrétního má systém dělat. 
  
-obr. Xyz : Hierarchické uspořádání požadavků+{{ :znalostni_baze:fnp9.png?600 |}}
  
-=== Typy požadavků ===+== Typy požadavků ==
  
 Funkční – //Funkční požadavky popisují funkce systému, funkce systémových prvků nebo úloh, které mají být provedeny// (ISO/IEC/IEEE, 2011 p. 13). Nebo //„[Funkční požadavky] je popis chování systému, jež bude projevovat za určitých podmínek.// (Wiegers, 2013 p. 7) Funkční – //Funkční požadavky popisují funkce systému, funkce systémových prvků nebo úloh, které mají být provedeny// (ISO/IEC/IEEE, 2011 p. 13). Nebo //„[Funkční požadavky] je popis chování systému, jež bude projevovat za určitých podmínek.// (Wiegers, 2013 p. 7)
Řádek 714: Řádek 767:
 Nefunkční požadavky – //„Tyto požadavky popisují skutečnosti/stavy, za kterých systém musí operovat, existovat nebo popisují systémové vlastnosti. Specifikují jakost systému.“// (ISO/IEC/IEEE, 2011 p. 14). Nebo //„popis vlastností nebo charakteristik, které systém musí projevovat, nebo omezení která musí být respektována“.// (Wiegers, 2013 p. 7) Nefunkční požadavky – //„Tyto požadavky popisují skutečnosti/stavy, za kterých systém musí operovat, existovat nebo popisují systémové vlastnosti. Specifikují jakost systému.“// (ISO/IEC/IEEE, 2011 p. 14). Nebo //„popis vlastností nebo charakteristik, které systém musí projevovat, nebo omezení která musí být respektována“.// (Wiegers, 2013 p. 7)
  
-==== Vlastnosti samotného požadavku ====+=== Vlastnosti samotného požadavku ===
  
 Každý požadavek musí mít všechny následující vlastnosti: Každý požadavek musí mít všechny následující vlastnosti:
Řádek 728: Řádek 781:
   - Verifikovatelný – Požadavek má prostředek k verifikaci, že splňuje daný požadavek. Požadavek je posílen tím, že je měřitelný.   - Verifikovatelný – Požadavek má prostředek k verifikaci, že splňuje daný požadavek. Požadavek je posílen tím, že je měřitelný.
  
-==== Atributy požadavků ====+=== Atributy požadavků ===
  
 Každý vedený požadavek má mít následující atributy. U některých atributů se vede škála, v rámci bezpečnostní komunity se zažila škála 1-4 kde 1 je nejnižší hodnota a 4 nejvyšší. Proto ji doporučuje využívat i zde: Každý vedený požadavek má mít následující atributy. U některých atributů se vede škála, v rámci bezpečnostní komunity se zažila škála 1-4 kde 1 je nejnižší hodnota a 4 nejvyšší. Proto ji doporučuje využívat i zde:
Řádek 748: Řádek 801:
   - Omezený – omezený jen na danou oblast a nejde mimo vymezenou oblast   - Omezený – omezený jen na danou oblast a nejde mimo vymezenou oblast
  
-====== Sběr požadavků ======+===== Sběr požadavků =====
  
-===== Dělení sběru požadavků dle času =====+==== Dělení sběru požadavků dle času ====
  
 Proces sběru požadavků můžeme rozdělit na dva typy sběru podle času: Proces sběru požadavků můžeme rozdělit na dva typy sběru podle času:
Řádek 757: Řádek 810:
   - Požadavky, které se sbírají v rámci jednoho projektu zavedení konkrétního ICT řešení.   - Požadavky, které se sbírají v rámci jednoho projektu zavedení konkrétního ICT řešení.
  
-==== Kontinuální sběr požadavků ====+=== Kontinuální sběr požadavků ===
  
 V rámci systému řízení (tj. plánování, budování, nákupu a rozvoje) ICT technologií((Lze využít ISO/IEC 38500:2015 V rámci systému řízení (tj. plánování, budování, nákupu a rozvoje) ICT technologií((Lze využít ISO/IEC 38500:2015
-)) má mít organizace zavedený systém sběru požadavků. Tento systém řízení ICT technologií je uveden v XXX kde rozpracovává sběr požadavků ve své části YYY. Součástí kontinuálního sběru požadavků je i využití nástrojů, kde jsou požadavky zaznamenávány, včetně náležitostí, které jsou uvedeny v následujících kapitolách ZZZ tohoto dokumentu. Po jejich sběru následuje hodnocení, přiřazování priorit a případná implementace. Požadavky k minulým i budoucím konkrétním ICT řešením se též sbírají pro jejich další využití. Takovéto nástroje by měl též umožňovat sběr požadavků i ke konkrétnímu projektu.+)) má mít organizace zavedený systém sběru požadavků. Tento systém řízení ICT technologií je uveden v XXX kde rozpracovává sběr požadavků ve své části YYY. Součástí kontinuálního sběru požadavků je i využití nástrojů, kde jsou požadavky zaznamenávány, včetně náležitostí, které jsou uvedeny v následujících kapitolách tohoto dokumentu. Po jejich sběru následuje hodnocení, přiřazování priorit a případná implementace. Požadavky k minulým i budoucím konkrétním ICT řešením se též sbírají pro jejich další využití. Takovéto nástroje by měl též umožňovat sběr požadavků i ke konkrétnímu projektu.
  
 +<WRAP center round info 60%>
 Příklad: Příklad:
  
 Úřad vede sběr požadavků kontinuálně díky změně legislativy o oblasti GDPR je tento požadavek zaznamenán a při pravidelné údržbě systému je implementován do všech systému, kterých se tento požadavek týká. Úřad vede sběr požadavků kontinuálně díky změně legislativy o oblasti GDPR je tento požadavek zaznamenán a při pravidelné údržbě systému je implementován do všech systému, kterých se tento požadavek týká.
  
-=== Sběr požadavků ke konkrétnímu ICT řešení ===+</WRAP> 
 + 
 +== Sběr požadavků ke konkrétnímu ICT řešení ==
  
 Ke konkrétnímu ICT řešení, nebo k jeho aktualizaci, se využívají jak požadavky, které byly sebrány v rámci kontinuálního sběru požadavků, tak i požadavky, které se sbírají ke konkrétnímu ICT řešení. Poznatky ke konkrétnímu ICT řešení u se též předávají do ICT řešení sběru požadavků (viz předchozí kapitola) pro jejich další využití. Popis sběru bude více popsán dále. Ke konkrétnímu ICT řešení, nebo k jeho aktualizaci, se využívají jak požadavky, které byly sebrány v rámci kontinuálního sběru požadavků, tak i požadavky, které se sbírají ke konkrétnímu ICT řešení. Poznatky ke konkrétnímu ICT řešení u se též předávají do ICT řešení sběru požadavků (viz předchozí kapitola) pro jejich další využití. Popis sběru bude více popsán dále.
  
 +<WRAP center round info 60%>
 Příklad: Příklad:
  
 V konkrétním systému je zaznamenán požadavek na zavedení flexibilní work-flow podpory. Tento požadavek se přenese i do obecné sbírky požadavků a je zařazen pro implementaci u relevantních systémů. V konkrétním systému je zaznamenán požadavek na zavedení flexibilní work-flow podpory. Tento požadavek se přenese i do obecné sbírky požadavků a je zařazen pro implementaci u relevantních systémů.
  
-==== Sběr požadavků dle postupu sběru ====+</WRAP> 
 + 
 +=== Sběr požadavků dle postupu sběru ===
  
 Při sběru požadavků jak při kontinuální bázi, tak při sběru požadavků na konkrétní projekt, dochází ke dvěma typům sběrů požadavků. Jednak k rekursivnímu sběru tak k iterativnímu sběru. Z pohledu úřadu a státní správy je rekursivní sběr upřednostňován (jak v prioritách, tak i v procesech řízení) před iterativním. Avšak iterativní proces nelze vyloučit z důvodů toho, že přináší hodnotu zachycení dalších požadavků Při sběru požadavků jak při kontinuální bázi, tak při sběru požadavků na konkrétní projekt, dochází ke dvěma typům sběrů požadavků. Jednak k rekursivnímu sběru tak k iterativnímu sběru. Z pohledu úřadu a státní správy je rekursivní sběr upřednostňován (jak v prioritách, tak i v procesech řízení) před iterativním. Avšak iterativní proces nelze vyloučit z důvodů toho, že přináší hodnotu zachycení dalších požadavků
  
-=== Rekursivní sběr požadavků ===+== Rekursivní sběr požadavků ==
  
 Ve zjednodušeném pohledu se jedná o přístup od shora dolů, kde sbírané požadavky se přepisují z vrchní vrstvy na nižší, dále jsou dovozovány další požadavky a tím je přidávána hodnota ICT řešení. Prostup ale může být i obou směrný. Avšak obecný **postup je** odvozené **požadavky dedukovat.** Ve zjednodušeném pohledu se jedná o přístup od shora dolů, kde sbírané požadavky se přepisují z vrchní vrstvy na nižší, dále jsou dovozovány další požadavky a tím je přidávána hodnota ICT řešení. Prostup ale může být i obou směrný. Avšak obecný **postup je** odvozené **požadavky dedukovat.**
  
 +<WRAP center round info 60%>
 Příklad: Příklad:
  
 Při sběru požadavků na IS existuje požadavek, aby IS komunikoval se současnými systémy. Z toho plny že, současným systémem je i spisová služba. A z toho plyne, že komunikuje přes rozhraní, které má technické specifikace. Při sběru požadavků na IS existuje požadavek, aby IS komunikoval se současnými systémy. Z toho plny že, současným systémem je i spisová služba. A z toho plyne, že komunikuje přes rozhraní, které má technické specifikace.
  
-=== Iterativní vývoj  ===+</WRAP> 
 + 
 +== Iterativní vývoj  ==
  
 Ve zjednodušeném pohledu se jedná o přístup od zdola nahoru, kde sbírané požadavky se přepisují ze spodní vrstvy na vyšší, dále jsou dovozovány další a tím je přidávána hodnota ICT řešení. Opět může být zde i vazba směrem zpátky na nižší vrstvy z výších vrstev, ale **postup je** odvozené **požadavky indukovat.** Ve zjednodušeném pohledu se jedná o přístup od zdola nahoru, kde sbírané požadavky se přepisují ze spodní vrstvy na vyšší, dále jsou dovozovány další a tím je přidávána hodnota ICT řešení. Opět může být zde i vazba směrem zpátky na nižší vrstvy z výších vrstev, ale **postup je** odvozené **požadavky indukovat.**
  
 +<WRAP center round info 60%>
 Příklad: Příklad:
  
 Při sběru požadavků připomene bezpečnostní odbor, že komunikace IS má být šifrována. Šifrována má být, protože je to součástí bezpečnostní politiky. Soulad s bezpečnostní politikou byl zahrnut do souboru požadavků. Při sběru požadavků připomene bezpečnostní odbor, že komunikace IS má být šifrována. Šifrována má být, protože je to součástí bezpečnostní politiky. Soulad s bezpečnostní politikou byl zahrnut do souboru požadavků.
  
-===== Zainteresované strany – stakeholders =====+</WRAP> 
 + 
 +==== Zainteresované strany – stakeholders ====
  
 Zainteresovanou stranou jsou organizace či osoby, jež přímo či nepřímo, je zainteresovaná na projektu buď tím že se na ní podíl, dotýká nebo má z něj užitek. Zainteresovanou stranou jsou organizace či osoby, jež přímo či nepřímo, je zainteresovaná na projektu buď tím že se na ní podíl, dotýká nebo má z něj užitek.
  
-==== Dělení na zainteresované strany a jejich třídy ====+=== Dělení na zainteresované strany a jejich třídy ===
  
 V rámci sběru požadavků existují jako podmnožina zainteresované strany i třídy. Převážně se používají pro uživatele. V rámci sběru požadavků existují jako podmnožina zainteresované strany i třídy. Převážně se používají pro uživatele.
  
 +<WRAP center round info 60%>
 Příklad: Příklad:
  
 Při sběru požadavků na novou spisovou službu je kromě zainteresované strany „uživatelé“ vedeny i její třídy. „zkušení uživatelé“, „noví uživatelé“ a „uživatelé specifické agendy X“. Dále například administrátoři. Při sběru požadavků na novou spisovou službu je kromě zainteresované strany „uživatelé“ vedeny i její třídy. „zkušení uživatelé“, „noví uživatelé“ a „uživatelé specifické agendy X“. Dále například administrátoři.
  
-==== Minimální okruh zainteresovaných stran ====+</WRAP>
  
-=== Vedení organizace – management  ===+=== Minimální okruh zainteresovaných stran === 
 + 
 +== Vedení organizace – management  ==
  
 Vedení organizace či části organizačního celku ustanovuje omezení, zdroje a povinnosti. V případě nezapojení věcného gestora přejímá jeho činnosti. Vedení úřadu může zadávat požadavky nejen v rámci zadání vertikálně z pozice moci, ale i horizontálně jako jeden ze skupiny zainteresovaných stran. Vedení organizace či části organizačního celku ustanovuje omezení, zdroje a povinnosti. V případě nezapojení věcného gestora přejímá jeho činnosti. Vedení úřadu může zadávat požadavky nejen v rámci zadání vertikálně z pozice moci, ale i horizontálně jako jeden ze skupiny zainteresovaných stran.
  
-=== Přímí uživatelé ===+== Přímí uživatelé ==
  
 Jsou přímými uživateli a provádí běžnou činnost. Ti specifikují požadavky pro přímé užívání. (U této skupiny je důležité třídění požadavků, které mají, kvůli nepotřebě). Jsou přímými uživateli a provádí běžnou činnost. Ti specifikují požadavky pro přímé užívání. (U této skupiny je důležité třídění požadavků, které mají, kvůli nepotřebě).
Řádek 818: Řádek 886:
 Tito uživatelé se budou podílet ve větší míře na procesních požadavcích. Tito uživatelé se budou podílet ve větší míře na procesních požadavcích.
  
-=== Nepřímí uživatelé ===+== Nepřímí uživatelé ==
  
 Toto jsou uživatelé výstupů. Často jsou to vedoucí pracovníci, kteří dohlíží nebo monitorují nižší pracovníky a používají výstupy jejich činnosti. Ti specifikují toho, co by ICT řešení mělo umět pro jejich potřeby nebo potřeby organizace. Toto jsou uživatelé výstupů. Často jsou to vedoucí pracovníci, kteří dohlíží nebo monitorují nižší pracovníky a používají výstupy jejich činnosti. Ti specifikují toho, co by ICT řešení mělo umět pro jejich potřeby nebo potřeby organizace.
  
-=== Ekonomická oddělení ===+== Ekonomická oddělení ==
  
 Specifikují požadavky a podílejí se na výběru a dodavatel nebo alokaci zdrojů. Specifikují požadavky a podílejí se na výběru a dodavatel nebo alokaci zdrojů.
  
-=== Právní oddělení ===+== Právní oddělení ==
  
 Právní oddělení specifikuje případné další právní požadavky, které nenastolilo vedení organizace nebo věcný gestor a stanovuje právní rámec (případně navrhuje optimalizaci legislativy, pakliže je čas ji provést). Dále v souvislosti s novým ICT řešeními specifikuje možnosti spolupráce dalších již zavedených ICT řešení. Právní oddělení specifikuje případné další právní požadavky, které nenastolilo vedení organizace nebo věcný gestor a stanovuje právní rámec (případně navrhuje optimalizaci legislativy, pakliže je čas ji provést). Dále v souvislosti s novým ICT řešeními specifikuje možnosti spolupráce dalších již zavedených ICT řešení.
  
-=== Manažer bezpečnosti – bezpečnostní odbor ===+== Manažer bezpečnosti – bezpečnostní odbor ==
  
 Manažer bezpečnosti nebo bezpečnostní odbor navrhuje pravidla, jež se týkají bezpečnosti fyzické, administrativní, osobní a technické a jiné. Manažer bezpečnosti nebo bezpečnostní odbor navrhuje pravidla, jež se týkají bezpečnosti fyzické, administrativní, osobní a technické a jiné.
  
-=== Architekt úřadu ===+== Architekt úřadu ==
  
 Pakliže úřad má architekta, který se zabývá architekturou úřadu, tak je povinou zainteresovanou stranou. Jeho úkolem je, promítnou architektonickou vizi do požadavků. Z tohoto svého mandátu dodávají architektonické požadavky. Pakliže úřad má architekta, který se zabývá architekturou úřadu, tak je povinou zainteresovanou stranou. Jeho úkolem je, promítnou architektonickou vizi do požadavků. Z tohoto svého mandátu dodávají architektonické požadavky.
  
-=== Pověřenec pro ochran osobních údajů (Data protection officer)  ===+== Pověřenec pro ochran osobních údajů (Data protection officer)  ==
  
-=== Hlavním úkolem pověřence pro ochranu osobních údajů je návrh pravidel pro ochranu osobních údajů a dalších práv, jež vyplívají ze směrnice GDPR. ===+== Hlavním úkolem pověřence pro ochranu osobních údajů je návrh pravidel pro ochranu osobních údajů a dalších práv, jež vyplívají ze směrnice GDPR. ==
  
-==== Širší okruh zainteresovaných stran ====+=== Širší okruh zainteresovaných stran ===
  
-=== Věcní správci – gestoři ===+== Věcní správci – gestoři ==
  
 Ve většině organizací státní správy je zaveden věcný správce, ten pomáhá se schopnostmi aplikace a vnitřním organizačním kontextem. Ve většině organizací státní správy je zaveden věcný správce, ten pomáhá se schopnostmi aplikace a vnitřním organizačním kontextem.
  
-=== Oddělení rozvoje IT ===+== Oddělení rozvoje IT ==
  
 Takováto oddělení se zabývají architekturou a rozvojem IT organizace. Toto oddělení vypomáhá se specifikacemi, které se týkají napojení s ostatními ICT řešeními a potenciálními synergiemi které mohou vzniknout. Dále je to centrum sběru požadavků v organizaci, tj. vede centrálním systém sběru požadavků v organizaci. Dále toto oddělení má na starosti ICT řešení úřadu. Takováto oddělení se zabývají architekturou a rozvojem IT organizace. Toto oddělení vypomáhá se specifikacemi, které se týkají napojení s ostatními ICT řešeními a potenciálními synergiemi které mohou vzniknout. Dále je to centrum sběru požadavků v organizaci, tj. vede centrálním systém sběru požadavků v organizaci. Dále toto oddělení má na starosti ICT řešení úřadu.
  
-=== Oddělení provozu IT ===+== Oddělení provozu IT ==
  
 Předává a zpracovává chybová hlášení pro jejich nápravu a pro další vylepšení. Předává a zpracovává chybová hlášení pro jejich nápravu a pro další vylepšení.
  
-=== Klienti veřejné správy – občané ===+== Klienti veřejné správy – občané ==
  
 Podstatná zainteresovaná strana. U některých není občan zainteresován přímo, u některých ano. Pakliže že občan je zainteresovanou stranou je podstatné ho jako zainteresovanou stranu zahrnout. Podstatná zainteresovaná strana. U některých není občan zainteresován přímo, u některých ano. Pakliže že občan je zainteresovanou stranou je podstatné ho jako zainteresovanou stranu zahrnout.
  
 +<WRAP center round info 60%>
 Příklad: Příklad:
  
 Buduje se nová aplikace do portálu občana. Občany nelze zahrnout jako takové do interních pracovních postupů. Ovšem reprezentativní vzorek občanů je konzultováni pomocí dotazníků a hloubkových rozhovorů. Buduje se nová aplikace do portálu občana. Občany nelze zahrnout jako takové do interních pracovních postupů. Ovšem reprezentativní vzorek občanů je konzultováni pomocí dotazníků a hloubkových rozhovorů.
  
-=== Sponzor projektu ===+</WRAP> 
 + 
 +== Sponzor projektu ==
  
 Pakliže existuje externí sponzor projektu, nebo nadřízená organizace tak ta specifikuje většinou byzynsové požadavky Pakliže existuje externí sponzor projektu, nebo nadřízená organizace tak ta specifikuje většinou byzynsové požadavky
  
 +<WRAP center round info 60%>
 Příklad: Příklad:
  
 Typický sponzorem projektu může být EU, která určuje podmínkami dotací business požadavky, které jsou nepřekročitelné. Např.: //„Systém musí být provozován 5 let.“// Z čehož plyne požadavek na udržitelnost celého systému na 5 let provozu. Dalším sponzorem může být stát, v rámci dotací ze státního rozpočtu. Nebo kraje, které poskytnou dotace na rozvoj IS obcí, ale s podmínkou že IS musí být schopny přesunu do technologických center kraje. Typický sponzorem projektu může být EU, která určuje podmínkami dotací business požadavky, které jsou nepřekročitelné. Např.: //„Systém musí být provozován 5 let.“// Z čehož plyne požadavek na udržitelnost celého systému na 5 let provozu. Dalším sponzorem může být stát, v rámci dotací ze státního rozpočtu. Nebo kraje, které poskytnou dotace na rozvoj IS obcí, ale s podmínkou že IS musí být schopny přesunu do technologických center kraje.
  
-==== Skryté zainteresované strany – negativní vlivy na projekt ====+</WRAP> 
 + 
 +=== Skryté zainteresované strany – negativní vlivy na projekt ===
  
 Lidská společnost není ideální, proto existují i zainteresované strany, která mají různé zájmy, na (ne)vzniku, (ne)obnově, (ne)rozvoji nebo (ne)rozšíření ICT řešení. Nebo i tyto zájmy jdou na úkor celého projektu. Ovšem zodpovědností úřadu je se s takovými vlivy vypořádat. Důvodů může být několik: Lidská společnost není ideální, proto existují i zainteresované strany, která mají různé zájmy, na (ne)vzniku, (ne)obnově, (ne)rozvoji nebo (ne)rozšíření ICT řešení. Nebo i tyto zájmy jdou na úkor celého projektu. Ovšem zodpovědností úřadu je se s takovými vlivy vypořádat. Důvodů může být několik:
Řádek 883: Řádek 957:
   * Kombinace výše uvedeného   * Kombinace výše uvedeného
  
-==== Signifikantní požadavky ====+=== Signifikantní požadavky ===
  
-=== Nastavení komunikace ===+== Nastavení komunikace ==
  
 Jedním z hlavních a napříč celým spektrem universálním požadavkem je jasná definice komunikace. Řízení stávajících ICT řešení, kde dochází k úpravám, či vytváření nových řešení je vždy propojeno s nutností komunikace. Ta probíhá v zásadě ve formě interní (komunikace organizace, mezi jejími složkami), tak externí (komunikace s dodavatelem a dalšími stranami). Jedním z hlavních a napříč celým spektrem universálním požadavkem je jasná definice komunikace. Řízení stávajících ICT řešení, kde dochází k úpravám, či vytváření nových řešení je vždy propojeno s nutností komunikace. Ta probíhá v zásadě ve formě interní (komunikace organizace, mezi jejími složkami), tak externí (komunikace s dodavatelem a dalšími stranami).
  
-== Interní ==+** Interní **
  
 Musí být ustanoveno kdo a v jaké kompetenci může komunikovat potřeby dále. Musí být ustanoveno kdo a v jaké kompetenci může komunikovat potřeby dále.
  
-== K dodavateli ==+** K dodavateli **
  
 Musí být ustanoveni styční pracovníci na obou stranách, včetně mechanismů jejich obměny. A dále ustanoveny kdo jaké požadavky může formulovat a schvalovat ve své finální podobě. Musí být ustanoveni styční pracovníci na obou stranách, včetně mechanismů jejich obměny. A dále ustanoveny kdo jaké požadavky může formulovat a schvalovat ve své finální podobě.
  
-=== Kvalita kódu a dopad na udržitelnost systému. ===+== Kvalita kódu a dopad na udržitelnost systému. ==
  
 V jiných kapitolách je popsáno „čeho“ by systém měl být schopen. Jak bylo uvedeno: každý požadavek má být verifikovatelný. To sebou nese kritéria validace, která jsou známá př. „//komunikace musí probíhat pomocí SHA 4096//“, takovýto požadavek je jasně verifikovatelný. V jiných kapitolách je popsáno „čeho“ by systém měl být schopen. Jak bylo uvedeno: každý požadavek má být verifikovatelný. To sebou nese kritéria validace, která jsou známá př. „//komunikace musí probíhat pomocí SHA 4096//“, takovýto požadavek je jasně verifikovatelný.
Řádek 920: Řádek 994:
 Pakliže návrh ICT řešení dělají architekti, paralelou pravidel eGovernmentu je urbanistika, tak paralelou (ohledně kontroly kvality) ze stavebnictví se jedná o stavební dozor. Pakliže návrh ICT řešení dělají architekti, paralelou pravidel eGovernmentu je urbanistika, tak paralelou (ohledně kontroly kvality) ze stavebnictví se jedná o stavební dozor.
  
-===== Postup požadavku od identifikace potřeby do implementace =====+==== Postup požadavku od identifikace potřeby do implementace ====
  
 Každá ze zainteresovaných stran bude mít požadavky ICT řešení, ovšem je nutné zjistit formalizovaný a dokumentovaný postup požadavků od jejich zajištění do jejich implementace. Mezi funkční implementací a požadavkem je mnoho mezi kroků, které pakliže nejsou dodrženy, tak hrozí negativní následky (zpoždění, více náklady, bezpečnostní chyby, neúplná funkčnost programu, rozšiřování záměru atd.). Ve všech fázích je prováděna dokumentace, dle postupů popsaných v XXX. Každá ze zainteresovaných stran bude mít požadavky ICT řešení, ovšem je nutné zjistit formalizovaný a dokumentovaný postup požadavků od jejich zajištění do jejich implementace. Mezi funkční implementací a požadavkem je mnoho mezi kroků, které pakliže nejsou dodrženy, tak hrozí negativní následky (zpoždění, více náklady, bezpečnostní chyby, neúplná funkčnost programu, rozšiřování záměru atd.). Ve všech fázích je prováděna dokumentace, dle postupů popsaných v XXX.
  
-==== Sekvenčně je postup požadavku k funkční implementaci následující: ====+=== Sekvenčně je postup požadavku k funkční implementaci následující: ===
  
   - Identifikace potřeby (může být přeskočeno)   - Identifikace potřeby (může být přeskočeno)
Řádek 945: Řádek 1019:
 V průběhu času pravděpodobně dojde ke změně souboru požadavků, proto je důležité si nastavit procesy, aby se včas a v co nejlepší kvalitě (ze kterých plynou požadavky) byli zaznamenány a obratem vy komunikovány další zainteresovaným stranám a řídícím orgánům projektu. Včasné zaznamenání změny, i bez alternativy, má svoji hodnotu. Dodavatel může změnit priority a nedojde k mrhání prostředků. Změnou požadavků může být i vynechání některých požadavků, jejich změna nebo přidání nových. V průběhu času pravděpodobně dojde ke změně souboru požadavků, proto je důležité si nastavit procesy, aby se včas a v co nejlepší kvalitě (ze kterých plynou požadavky) byli zaznamenány a obratem vy komunikovány další zainteresovaným stranám a řídícím orgánům projektu. Včasné zaznamenání změny, i bez alternativy, má svoji hodnotu. Dodavatel může změnit priority a nedojde k mrhání prostředků. Změnou požadavků může být i vynechání některých požadavků, jejich změna nebo přidání nových.
  
-====== Dokumentace předcházející vzniku požadavků ======+===== Dokumentace předcházející vzniku požadavků =====
  
 Před zahájením procesu sběru požadavků je nezbytné/ dobré schválit následující závazné a koncepční dokumenty, ze kterých budou plynout následující akce. Tyto dokumenty jsou předpokládány v Metodách řízení. Před zahájením procesu sběru požadavků je nezbytné/ dobré schválit následující závazné a koncepční dokumenty, ze kterých budou plynout následující akce. Tyto dokumenty jsou předpokládány v Metodách řízení.
  
-===== Strategický koncept provozu ICT řešení =====+==== Strategický koncept provozu ICT řešení ====
  
 Účelem tohoto dokumentu je nastínit kontext a souvislosti, jež se s projektem pojí. Tento dokument slouží především k formulaci, jak bude systém nebo systémy využívány. Vychází z předpokladů nebo záměrů výkonu funkcí úřadu. Jeho hlavním účelem je pomoct zainteresovaným stranám pochopit kontext při sestavování požadavků na systém. Účelem tohoto dokumentu je nastínit kontext a souvislosti, jež se s projektem pojí. Tento dokument slouží především k formulaci, jak bude systém nebo systémy využívány. Vychází z předpokladů nebo záměrů výkonu funkcí úřadu. Jeho hlavním účelem je pomoct zainteresovaným stranám pochopit kontext při sestavování požadavků na systém.
Řádek 960: Řádek 1034:
 |Schvaluje:                   |Vedení                                                                                                                             | |Schvaluje:                   |Vedení                                                                                                                             |
  
-===== Operační koncept provozu ICT řešení =====+==== Operační koncept provozu ICT řešení ====
  
 Tento dokument slouží k pochopení toho, co má systém konkrétně vykonávat a v jakém kontextu je zasazen. Dochází ke konceptualizaci vztahů mezi systémy a interakcemi uživatelů. Tento dokument slouží k pochopení toho, co má systém konkrétně vykonávat a v jakém kontextu je zasazen. Dochází ke konceptualizaci vztahů mezi systémy a interakcemi uživatelů.
Řádek 969: Řádek 1043:
 |Schvaluje:                   |Věcný gestor                          | |Schvaluje:                   |Věcný gestor                          |
  
-===== Hierarchie souborů požadavků =====+==== Hierarchie souborů požadavků ====
  
 Po schválení souborů požadavků zainteresovanými stranami se požadavky hierarchicky dělí na následujících kategorie: Po schválení souborů požadavků zainteresovanými stranami se požadavky hierarchicky dělí na následujících kategorie:
  
-  - Byzynysové požadavky+  - Byznysové požadavky \\ Požadavky, jež se pojí k byznysovým požadavkům 
 +  - Požadavky zainteresovaných stran \\ Požadavky, jež se pojí k požadavků zainteresovaných stran 
 +  - Systémové požadavky \\ Požadavky, jež se pojí k systému jako celku. 
 +  - Sub Systémové požadavky \\ Požadavky, jež se pojí k subsystémům. 
 +  -Softwarové požadavky \\ Požadavky, jež se pojí k Softwaru.
  
-> Požadavky, jež se pojí k byznysovým požadavkům+Vztah mezi těmito požadavky je kaskádovitý od byznysových požadavků po softwarové požadavky.
  
-<ol start="2" style="list-style-type: decimal;"> +==== Interakce mezi dokumenty ====
-Požadavky zainteresovaných stran +
- +
-> Poždavky, jež se pojí k požadavků zainteresovaných stran +
- +
- +
-Systémové požadavky +
- +
-> Požadavky, jež se pojí k systému jako celku. +
- +
-  - Sub Systémové požadavky +
- +
-> Požadavky, jež se pojí k subsystémům. +
- +
-<ol start="2" style="list-style-type: lower-alpha;"> +
-Softwarové požadavky +
- +
-> Požadavky, jež se pojí k Softwaru. +
- +
-Vztah mezi těmito požadavky je kaskádovitý od byzynsových požadavků po softwarové požadavky. +
- +
-===== Interakce mezi dokumenty =====+
  
 Operační koncept provozu ICT řešení, který vchází ze Strategického konceptu provozu ICT řešení, ovlivňuje sběr požadavků a požadavky, tím že vytváří společný základ sběru požadavků. Byzynsové požadavky formují požadavky zainteresovaných stran a tím vytváří ucelené požadavky vůči předchozím dokumentům. Operační koncept provozu ICT řešení, který vchází ze Strategického konceptu provozu ICT řešení, ovlivňuje sběr požadavků a požadavky, tím že vytváří společný základ sběru požadavků. Byzynsové požadavky formují požadavky zainteresovaných stran a tím vytváří ucelené požadavky vůči předchozím dokumentům.
  
-===== Požadavky na externího partnera pro sběr požadavků =====+==== Požadavky na externího partnera pro sběr požadavků ====
  
 V rozsáhlých projektech bude nezbytné zajistit dodávky služeb pro sběr požadavků externími silami, protože úřad nedisponuje patřičným know-how, jak tuto činnost provést, a i lidskými silami nad rámec běžné činnosti (i při zavedení systému průběžném sběru tyto situace mohou nastat) Je však nezbytné, aby dodavatel služeb měl patřičné schopnosti pro realizaci této činnosti. Talentovaní analytici jsou ti, jenž z projektu udělají, ten, který uspěje. V rozsáhlých projektech bude nezbytné zajistit dodávky služeb pro sběr požadavků externími silami, protože úřad nedisponuje patřičným know-how, jak tuto činnost provést, a i lidskými silami nad rámec běžné činnosti (i při zavedení systému průběžném sběru tyto situace mohou nastat) Je však nezbytné, aby dodavatel služeb měl patřičné schopnosti pro realizaci této činnosti. Talentovaní analytici jsou ti, jenž z projektu udělají, ten, který uspěje.
Řádek 1010: Řádek 1067:
 Sběrem požadavků se zaobírají organizace International Institute of Business Analysis a International Requirements Engineering Board. Tyto organizace poskytují certifikace a školení v oblasti sběru požadavků. Sběrem požadavků se zaobírají organizace International Institute of Business Analysis a International Requirements Engineering Board. Tyto organizace poskytují certifikace a školení v oblasti sběru požadavků.
  
-==== Dodávka externí pracovní síly ====+=== Dodávka externí pracovní síly ===
  
 Oblastí dodávky jsou patřičné pracovní síly (man day), které zajistí danou činnost, protože tato činnost je částečně nárazovitého charakteru a lidské zdroje nebudou k dispozici. Nehledě na to že pro tuto činnost musí pracovníci splňovat patřičné kvality. Oblastí dodávky jsou patřičné pracovní síly (man day), které zajistí danou činnost, protože tato činnost je částečně nárazovitého charakteru a lidské zdroje nebudou k dispozici. Nehledě na to že pro tuto činnost musí pracovníci splňovat patřičné kvality.
  
-==== Dodávka know-how sběru požadavků ====+=== Dodávka know-how sběru požadavků ===
  
 Sběr požadavků na ICT je samostatnou disciplínou. Schopnost realizovat tuto činnost mají jen někteří dodavatelé, nikoliv všichni. Je za potřebí požadavky sbírat ve standardizované formě, tak aby se s nimi dalo pracovat opakovaně. Sběr požadavků na ICT je samostatnou disciplínou. Schopnost realizovat tuto činnost mají jen někteří dodavatelé, nikoliv všichni. Je za potřebí požadavky sbírat ve standardizované formě, tak aby se s nimi dalo pracovat opakovaně.
  
-==== Dodávka znalosti oboru nebo řízení velkých informačních ICT řešení ====+=== Dodávka znalosti oboru nebo řízení velkých informačních ICT řešení ===
  
 Při sběru požadavků je nutné mít vhled do dané oblasti, tak aby „to be“ stav odpovídal moderním požadavkům a trendům. Nejlépe příklady nejlepší praxe ze zahraničí, jak ze státního, tak i soukromého sektoru. Znalost dané oblasti může být v méně optimální variantě kompenzována znalostí obdobných prací na rozsáhlejších ICT řešení. Pakliže nejsou zmapovány procesy „AS IS“ je otázkou do jaké míry je mapovat, pakliže dojde ke změně. Při sběru požadavků je nutné mít vhled do dané oblasti, tak aby „to be“ stav odpovídal moderním požadavkům a trendům. Nejlépe příklady nejlepší praxe ze zahraničí, jak ze státního, tak i soukromého sektoru. Znalost dané oblasti může být v méně optimální variantě kompenzována znalostí obdobných prací na rozsáhlejších ICT řešení. Pakliže nejsou zmapovány procesy „AS IS“ je otázkou do jaké míry je mapovat, pakliže dojde ke změně.
  
-==== Dodávka leadership dovedností pro aktivizaci pracovních sil ====+=== Dodávka leadership dovedností pro aktivizaci pracovních sil ===
  
 V průběhu sběru požadavků je důležité mít to, aby ti, co požadavky sbírají, měli patřičné „měkké dovednosti“, tak aby dokázali zaktivizovat úřad k dobré spolupráci. Tato oblast je ovšem těžko smluvně pod chytitelná, přesto ji zde uvádíme. V průběhu sběru požadavků je důležité mít to, aby ti, co požadavky sbírají, měli patřičné „měkké dovednosti“, tak aby dokázali zaktivizovat úřad k dobré spolupráci. Tato oblast je ovšem těžko smluvně pod chytitelná, přesto ji zde uvádíme.
  
-==== Dodávka služeb ve formátu architektury úřadu a zavedeného procesního modelování  ====+=== Dodávka služeb ve formátu architektury úřadu a zavedeného procesního modelování  ===
  
 Další podmínkou dodání služeb je to že externí partner předá požadavky na nové ICT řešení, případně pakliže dochází i k mapování starého ICT řešení, tak i u něho, ve formátu architektury, kterému úřad rozumí. Míra detailu sběru architektonických požadavků má dopovídat jakou volnost dostane dodavatel ICT řešení, při dodávce svého díla. Stejně tento požadavek platí i pro procesní modely. Dále je požadavkem i dodání pohledů (zvolené grafické reprezentace) modelů pro rozhodování vedoucích pracovníků. Další podmínkou dodání služeb je to že externí partner předá požadavky na nové ICT řešení, případně pakliže dochází i k mapování starého ICT řešení, tak i u něho, ve formátu architektury, kterému úřad rozumí. Míra detailu sběru architektonických požadavků má dopovídat jakou volnost dostane dodavatel ICT řešení, při dodávce svého díla. Stejně tento požadavek platí i pro procesní modely. Dále je požadavkem i dodání pohledů (zvolené grafické reprezentace) modelů pro rozhodování vedoucích pracovníků.
  
-==== Výlučnost rolí ====+=== Výlučnost rolí ===
  
 Jednou z podmínek, dle uvážení úřadu, je možnost stanovit výlučnost rolí. Dodavateli konzultačních služeb může být zakázáno účastnit se výběrového řízení na ICT řešení samotný, nebo poskytovat služby dodavatelům. Případně může dodavateli služeb na sběr požadavků být zakázány další navržené role. Jednou z podmínek, dle uvážení úřadu, je možnost stanovit výlučnost rolí. Dodavateli konzultačních služeb může být zakázáno účastnit se výběrového řízení na ICT řešení samotný, nebo poskytovat služby dodavatelům. Případně může dodavateli služeb na sběr požadavků být zakázány další navržené role.
  
-====== Interní standardizace sběru požadavků jako manažerský systém podpořený informačním systémem. ======+===== Interní standardizace sběru požadavků jako manažerský systém podpořený informačním systémem. =====
  
 V rámci chodu organizace je nutné sběr požadavků standardizovat, a to pomocí procesů, rolí a dedikovaným úložištěm. Je absolutně nezbytné všechny požadavky sepisovat a nevést je jen ve formě distribuované znalosti. V rámci chodu organizace je nutné sběr požadavků standardizovat, a to pomocí procesů, rolí a dedikovaným úložištěm. Je absolutně nezbytné všechny požadavky sepisovat a nevést je jen ve formě distribuované znalosti.
Řádek 1040: Řádek 1097:
 Zde navrhovaný systém sběru požadavků je využitelný i jako systém sběru požadavků v celé organizaci i na požadavky mimo oblast ICT a jde dále napojit i na další manažerské, informační, ekonomické (napojení na DNS) a jiné systémy. Díky mírným úpravám postupů a informačního systému je takovéto rozšíření jednoduché. Zde navrhovaný systém sběru požadavků je využitelný i jako systém sběru požadavků v celé organizaci i na požadavky mimo oblast ICT a jde dále napojit i na další manažerské, informační, ekonomické (napojení na DNS) a jiné systémy. Díky mírným úpravám postupů a informačního systému je takovéto rozšíření jednoduché.
  
 +<WRAP center round info 60%>
 Příklad: Příklad:
  
 Při zavedení systému sběru požadavků organizace ví jaké požadavky a v jakém počtu (pakliže byli katalogizovány) jsou vyžadovány. Tento systém lze využít i pro položky, jež se nepojí s ICT. Díky katalogu si odbor úřadu vyžádá novou kancelářskou židli, tento požadavek je validován ekonomickým oddělením a židle je dodána. Stačí, že v systému je kategorie ne-ICT požadavků. Některé požadavky mohou být absolutně bez katalogového zařazení, např. požadavek na zavedení klimatizace do objektu. Ovšem požadavek je evidován pro další využití. Při zavedení systému sběru požadavků organizace ví jaké požadavky a v jakém počtu (pakliže byli katalogizovány) jsou vyžadovány. Tento systém lze využít i pro položky, jež se nepojí s ICT. Díky katalogu si odbor úřadu vyžádá novou kancelářskou židli, tento požadavek je validován ekonomickým oddělením a židle je dodána. Stačí, že v systému je kategorie ne-ICT požadavků. Některé požadavky mohou být absolutně bez katalogového zařazení, např. požadavek na zavedení klimatizace do objektu. Ovšem požadavek je evidován pro další využití.
  
-===== Standardizovaný proces sběru požadavků =====+</WRAP> 
 + 
 +==== Standardizovaný proces sběru požadavků ====
  
 Nastavením jednotného stylu procesu dochází k jasnější a přehlednější správě procesu jako takového. Navíc se díky tomu proces sběru stává rutinní záležitostí, což přispívá k bezproblémovému chodu organizace. Nastavením jednotného stylu procesu dochází k jasnější a přehlednější správě procesu jako takového. Navíc se díky tomu proces sběru stává rutinní záležitostí, což přispívá k bezproblémovému chodu organizace.
Řádek 1050: Řádek 1110:
 Je nutné stanovit konkrétního pracovníka, osobu, který je za proces jako celek zodpovědný. Aby takový člověk mohl tuto odpovědnost přijmout, tak je povinné tomuto pracovníkovi zajistit mandát pro zajištění a řízení běhu tohoto procesu. Je nutné stanovit konkrétního pracovníka, osobu, který je za proces jako celek zodpovědný. Aby takový člověk mohl tuto odpovědnost přijmout, tak je povinné tomuto pracovníkovi zajistit mandát pro zajištění a řízení běhu tohoto procesu.
  
-===== Nastavení podmínek pro sběr požadavků uvnitř organizace =====+==== Nastavení podmínek pro sběr požadavků uvnitř organizace ====
  
 Úřad musí nastavit podmínky pro sběr požadavků v organizaci (a to i s externími partnery). Většina zaměstnanců úřadu nemá znalosti pro danou tématiku a je tedy úkolem úřadu poskytnou jim patřičné znalosti vhled a kontext do problematiky a její důležitost. Včetně motivačních prostředků, tak aby zapojení uživatelů bylo dostatečné. Úřad musí nastavit podmínky pro sběr požadavků v organizaci (a to i s externími partnery). Většina zaměstnanců úřadu nemá znalosti pro danou tématiku a je tedy úkolem úřadu poskytnou jim patřičné znalosti vhled a kontext do problematiky a její důležitost. Včetně motivačních prostředků, tak aby zapojení uživatelů bylo dostatečné.
  
 +<WRAP center round info 60%>
 Příklad: Příklad:
  
 Mgr. Adolf Slovák je referentem na svém oddělení již 10 let. Díky úzké pracovní specializaci mu nejsou dány známy okolnosti pro sběr požadavků na nové ICT řešení. Při předávání požadavků opomene to, že potřebuje export dat ze systému ve formátu “.xlsx“. Díky tomuto opomenutí systém neplní svojí hlavní roli primární evidence ekonomický případů. Referent si stále vede oddělenou tabulku s daty a dobudování této funkcionalitu by stále mnoho prostředků. Mgr. Adolf Slovák je referentem na svém oddělení již 10 let. Díky úzké pracovní specializaci mu nejsou dány známy okolnosti pro sběr požadavků na nové ICT řešení. Při předávání požadavků opomene to, že potřebuje export dat ze systému ve formátu “.xlsx“. Díky tomuto opomenutí systém neplní svojí hlavní roli primární evidence ekonomický případů. Referent si stále vede oddělenou tabulku s daty a dobudování této funkcionalitu by stále mnoho prostředků.
  
-===== Odpovědnost =====+</WRAP> 
 + 
 +==== Odpovědnost ====
  
 Pro zajištění funkce sběru požadavků je nutné ustanovit odpovědnosti pro řízení sběru požadavků nejméně v následujícím rozsahu a za zlepšování procesu. Sběr požadavky by měl být řízen a podporován vrcholným řízením ICT. Pro zajištění funkce sběru požadavků je nutné ustanovit odpovědnosti pro řízení sběru požadavků nejméně v následujícím rozsahu a za zlepšování procesu. Sběr požadavky by měl být řízen a podporován vrcholným řízením ICT.
  
 +<WRAP center round info 60%>
 Příklad: Příklad:
  
Řádek 1071: Řádek 1135:
  
 V takové organizaci již existuje rámec tedy jak zavést procesy řízení ICT. V takové organizaci již existuje rámec tedy jak zavést procesy řízení ICT.
 +</WRAP>
  
-==== Zajištění rolí v procesu ====+ 
 +=== Zajištění rolí v procesu ===
  
 V samotném sběru požadavků je nezbytné zajistit několik funkci a několik roli a to buď: V samotném sběru požadavků je nezbytné zajistit několik funkci a několik roli a to buď:
Řádek 1080: Řádek 1146:
   - kombinací externích a interních zdrojů   - kombinací externích a interních zdrojů
  
-=== Odpovědnost za proces a zajištění sběru ===+== Odpovědnost za proces a zajištění sběru ==
  
 Musí být ustanoven konkrétní pracovník, který má proces sběru požadavků jako svou odpovědnost Jeho úkolem je zajistit proces sběru požadavků jako takový. Nebo zajištovat sběry požadavků, kde je určen pracovník odpovědný za další pracovníky, kteří sbírají požadavky pro své ICT řešení. Musí být ustanoven konkrétní pracovník, který má proces sběru požadavků jako svou odpovědnost Jeho úkolem je zajistit proces sběru požadavků jako takový. Nebo zajištovat sběry požadavků, kde je určen pracovník odpovědný za další pracovníky, kteří sbírají požadavky pro své ICT řešení.
  
-Příklad:\\ +<WRAP center round info 60%> 
-\\+Příklad: 
 V organizaci pracuje Ing. Petr Sbíravý je vedoucím oddělení rozvoje IT. Je pověřen svým náměstek a popisem práce, jako odpovědný pracovník za sběr požadavků ve své organizaci. Existuje nástroj pro sběr požadavků v organizaci, se kterým jsou seznámeni a proškoleni účastníci procesu a oddělení pan Ing. Sbíravého věcně odpovídá za tento nástroj. V organizaci pracuje Ing. Petr Sbíravý je vedoucím oddělení rozvoje IT. Je pověřen svým náměstek a popisem práce, jako odpovědný pracovník za sběr požadavků ve své organizaci. Existuje nástroj pro sběr požadavků v organizaci, se kterým jsou seznámeni a proškoleni účastníci procesu a oddělení pan Ing. Sbíravého věcně odpovídá za tento nástroj.
  
-=== Odpovědnost za požadavky ===+</WRAP> 
 + 
 +== Odpovědnost za požadavky ==
  
 Musí být stanoveny osoby, jež jsou odpovědni za požadavky jako takové. Jak v úrovni oblastí požadavků, tak v úrovni jednotlivých ICT řešení. Musí být stanoveny osoby, jež jsou odpovědni za požadavky jako takové. Jak v úrovni oblastí požadavků, tak v úrovni jednotlivých ICT řešení.
  
-== Horizontální pohled ==+** Horizontální pohled **
  
 Jsou dále pověřeni pracovníci, kteří odpovídají za konkrétní oblasti (portfolia) požadavků. Každá oblast (bezpečnost, GDPR, dokumentace) má svého správce požadavků. Viz. Zainteresované strany. Jsou dále pověřeni pracovníci, kteří odpovídají za konkrétní oblasti (portfolia) požadavků. Každá oblast (bezpečnost, GDPR, dokumentace) má svého správce požadavků. Viz. Zainteresované strany.
  
 +<WRAP center round info 60%>
 Příklad: Příklad:
  
 Ing. Antonín Lorenc je vedoucím bezpečnostního odboru, ten zodpovídá za oblast bezpečnostních požadavků. Ing. Antonín Lorenc je vedoucím bezpečnostního odboru, ten zodpovídá za oblast bezpečnostních požadavků.
 +</WRAP>
  
-== Vertikální pohled ==+ 
 +** Vertikální pohled **
  
 Jsou dále ustanoveni pracovníci odpovědni za konkrétní ICT řešení, tak aby porozuměli potřebám, jež jsou kladeny na ICT řešení. Jsou dále ustanoveni pracovníci odpovědni za konkrétní ICT řešení, tak aby porozuměli potřebám, jež jsou kladeny na ICT řešení.
  
 +<WRAP center round info 60%>
 Příklad: Příklad:
  
 Mgr. Jan Psavý je pověřen sběrem požadavků na spisové služby je odpovědný za to, že požadavky na spisovou službu jsou sebrány řádně. Mgr. Jan Psavý je pověřen sběrem požadavků na spisové služby je odpovědný za to, že požadavky na spisovou službu jsou sebrány řádně.
  
-=====  Standardizace rolí při sběru požadavků =====+</WRAP> 
 + 
 +====  Standardizace rolí při sběru požadavků ====
  
 Vzhledem k širokému záběru informačních ICT řešení do jednotlivých aspektů a oblastí (jako je bezpečnost, architektura, udržitelnost a další) je doporučeno přiřadit tyto aspekty a oblasti ICT řešení (a k nim jejich požadavky) v rámci organizační struktury jednotlivým útvarům, jež mají znalosti a vykonávají danou roli. Vzhledem k širokému záběru informačních ICT řešení do jednotlivých aspektů a oblastí (jako je bezpečnost, architektura, udržitelnost a další) je doporučeno přiřadit tyto aspekty a oblasti ICT řešení (a k nim jejich požadavky) v rámci organizační struktury jednotlivým útvarům, jež mají znalosti a vykonávají danou roli.
  
 +<WRAP center round info 60%>
 Příklad: Příklad:
  
 Role GDRP zmocněnce je jednou ze standardizovaných rolí. Pracovník vykonávající tuto rolu v případě tvorby či změně ICT řešení se účastní jednání za svoji oblast (zde tedy GDPR), přináší, vytváří, spravuje požadavky v této oblasti a v rámci procesu je za ně odpovědný a udržuje je v specializovaném a dedikovaném uložišti. Role GDRP zmocněnce je jednou ze standardizovaných rolí. Pracovník vykonávající tuto rolu v případě tvorby či změně ICT řešení se účastní jednání za svoji oblast (zde tedy GDPR), přináší, vytváří, spravuje požadavky v této oblasti a v rámci procesu je za ně odpovědný a udržuje je v specializovaném a dedikovaném uložišti.
  
-===== Využití sběru požadavků jako nástroje průběžné změny nebo rozvoje =====+</WRAP> 
 + 
 +==== Využití sběru požadavků jako nástroje průběžné změny nebo rozvoje ====
  
 Díky kontinuálnímu procesu sběru požadavků od jejich detekce až po jejich validaci předání lze sledovat současný stav ICT řešení a soubor požadavků, které jsou v procesu zpracování. Tyto požadavky jsou zapracovávány buď: Díky kontinuálnímu procesu sběru požadavků od jejich detekce až po jejich validaci předání lze sledovat současný stav ICT řešení a soubor požadavků, které jsou v procesu zpracování. Tyto požadavky jsou zapracovávány buď:
Řádek 1123: Řádek 1201:
   - Ve větší balíčcích – v případě dodávky nových větších funkcionalit   - Ve větší balíčcích – v případě dodávky nových větších funkcionalit
  
-===== Nástroje na vedení požadavků =====+==== Nástroje na vedení požadavků ====
  
 Vedení samotných požadavků musí být v souladu s interními a externími pravidly organizace. K vedení požadavků se mají používat centrální nástroje pro zprávu a vedení požadavků. Absolutním minimem, jež není doporučováno, je použití tabulkového editoru kde budou požadavky vedeny řádně. Avšak toto řešení nevyhovuje. Existuje celá řada nástrojů pro správu požadavků, které jsou dostupné jako: Vedení samotných požadavků musí být v souladu s interními a externími pravidly organizace. K vedení požadavků se mají používat centrální nástroje pro zprávu a vedení požadavků. Absolutním minimem, jež není doporučováno, je použití tabulkového editoru kde budou požadavky vedeny řádně. Avšak toto řešení nevyhovuje. Existuje celá řada nástrojů pro správu požadavků, které jsou dostupné jako:
Řádek 1131: Řádek 1209:
   - Cloudové řešení   - Cloudové řešení
  
-===== Uložiště požadavků =====+==== Uložiště požadavků ====
  
 Jak bylo řečeno průběžně v celém tomto dokumentu, existence specializovaného dedikovaného úložiště je předpokladem pro efektivní komplexní správu požadavků v dané organizaci. Úložiště musí být téže aktivně spravováno tak, aby sloužilo jako aktivní, přístupný zásobník vědomostí a požadavků k nim. Jak bylo řečeno průběžně v celém tomto dokumentu, existence specializovaného dedikovaného úložiště je předpokladem pro efektivní komplexní správu požadavků v dané organizaci. Úložiště musí být téže aktivně spravováno tak, aby sloužilo jako aktivní, přístupný zásobník vědomostí a požadavků k nim.
  
-===== Proces a metodika =====+==== Proces a metodika ====
  
-==== Komunikace ====+=== Komunikace ===
  
 Smluvně a organizačně je nezbytné stanovit (přiřazení rolí), s kým bude komunikováno a kdo má jaké oprávnění k odsouhlasení návrhů či změn. Jde o příslušnou míru delegace činností v organizaci a přidělení kontaktních osob z dodávajících společností. Dále musí být myšleno na to jak, kdy a jakým způsobem bude probíhat komunikace, se zajištěním prostředí, které zamezuje vzniku komunikačních bariér. Smluvně a organizačně je nezbytné stanovit (přiřazení rolí), s kým bude komunikováno a kdo má jaké oprávnění k odsouhlasení návrhů či změn. Jde o příslušnou míru delegace činností v organizaci a přidělení kontaktních osob z dodávajících společností. Dále musí být myšleno na to jak, kdy a jakým způsobem bude probíhat komunikace, se zajištěním prostředí, které zamezuje vzniku komunikačních bariér.
Řádek 1145: Řádek 1223:
 Pro komunikace mezi externími celky (např, dodavateli) je určeno jednotné komunikační místo (Single Point of Contact), tak aby tento kanál byl zřetelně jasný. Pro komunikace mezi externími celky (např, dodavateli) je určeno jednotné komunikační místo (Single Point of Contact), tak aby tento kanál byl zřetelně jasný.
  
-==== Techniky sběru požadavků ====+=== Techniky sběru požadavků ===
  
 Pro sběr požadavků, jejich analýzu a klasifikaci se používají následující techniky (výčet je pouze demonstrativní povahy): Pro sběr požadavků, jejich analýzu a klasifikaci se používají následující techniky (výčet je pouze demonstrativní povahy):
Řádek 1156: Řádek 1234:
   - Návrhy a prototypy   - Návrhy a prototypy
  
-===== Iterace a prototypování =====+==== Iterace a prototypování ====
  
 Součástí procesu sběru požadavků je nezbytnost iterací procesu formulování požadavků. Žádné požadavky nemohou být nikdy dokonalé, ale cílem je v rámci zásad 3E dosáhnout 2 až 3 iteracemi dobrých požadavků. Součástí iterací nemusí být sběr požadavků na nejnižší úrovni, nebo při druhé iteraci. Další nezbytnou praxí je předvádění maket v průběhu sběru a předvádění prototypů v rámci vývoje, aby chyby mohli být napraveny v nejranějším stadiu realizace. Součástí procesu sběru požadavků je nezbytnost iterací procesu formulování požadavků. Žádné požadavky nemohou být nikdy dokonalé, ale cílem je v rámci zásad 3E dosáhnout 2 až 3 iteracemi dobrých požadavků. Součástí iterací nemusí být sběr požadavků na nejnižší úrovni, nebo při druhé iteraci. Další nezbytnou praxí je předvádění maket v průběhu sběru a předvádění prototypů v rámci vývoje, aby chyby mohli být napraveny v nejranějším stadiu realizace.
  
-==== Řešení sporů v požadavcích a nevalidní požadavky ====+=== Řešení sporů v požadavcích a nevalidní požadavky ===
  
 Všechny podněty k požadavkům by měli být sebrány (pakliže panuje nejistota, jestli něco je požadavkem nebo ne, tak to požadavek pravděpodobně je) i pakliže jsou na první pohled nevalidní (např. pro příští využití). V průběhu sběru vyhodnocování požadavků může dojít k situacím, kdy jsou požadavky na ICT řešení v konfliktu. Proto je nezbytné ustanovit kritéria priorit. Všechny podněty k požadavkům by měli být sebrány (pakliže panuje nejistota, jestli něco je požadavkem nebo ne, tak to požadavek pravděpodobně je) i pakliže jsou na první pohled nevalidní (např. pro příští využití). V průběhu sběru vyhodnocování požadavků může dojít k situacím, kdy jsou požadavky na ICT řešení v konfliktu. Proto je nezbytné ustanovit kritéria priorit.
Řádek 1171: Řádek 1249:
 |Vertikální  |Spor mezi požadavky zainteresovaných stran a systémovými požadavky|Učit hranici (např. absence ekonomické technologického řešení), kdy systémové požadavky jsou důležitější než požadavky zainteresovaných stran, ačkoliv jsou přednější.|Zainteresovaná strana eskaluje k vlastníku projektu                                     | |Vertikální  |Spor mezi požadavky zainteresovaných stran a systémovými požadavky|Učit hranici (např. absence ekonomické technologického řešení), kdy systémové požadavky jsou důležitější než požadavky zainteresovaných stran, ačkoliv jsou přednější.|Zainteresovaná strana eskaluje k vlastníku projektu                                     |
  
-==== Trasovatelná matice požadavků ====+=== Trasovatelná matice požadavků ===
  
 Důležitým prvkem je sledovatelnost požadavku v celém jeho cyklu. Proto musí být ustanovena pravidla pro jejich sledování Důležitým prvkem je sledovatelnost požadavku v celém jeho cyklu. Proto musí být ustanovena pravidla pro jejich sledování
  
-====== Požadavky a životní cyklus ======+===== Požadavky a životní cyklus =====
  
 Na všechny fáze života ICT řešení je potřeba myslet na začátku, při vytváření požadavků na ICT řešení. Fáze životního cyklu informačního ICT řešení jsou rozpracovány v hlavním dokumentech jako příloh k Informační Koncepci ČR, zejména v dokumentu Metody řízení ICT. Na všechny fáze života ICT řešení je potřeba myslet na začátku, při vytváření požadavků na ICT řešení. Fáze životního cyklu informačního ICT řešení jsou rozpracovány v hlavním dokumentech jako příloh k Informační Koncepci ČR, zejména v dokumentu Metody řízení ICT.
Řádek 1181: Řádek 1259:
 Dost často se užívá pojem plánovaná životnost ICT řešení. Tato životnost je však vždy závislá na konkrétní aplikaci. Dále je nutno rozlišovat mezi životností agendy a jejího výkonu a životností aplikačního a technologické části tohoto ICT řešení. Dost často se užívá pojem plánovaná životnost ICT řešení. Tato životnost je však vždy závislá na konkrétní aplikaci. Dále je nutno rozlišovat mezi životností agendy a jejího výkonu a životností aplikačního a technologické části tohoto ICT řešení.
  
 +<WRAP center round info 60%>
 Příklad: Příklad:
  
 Mějme agendu registru obyvatel (ROB), tato agenda bude vykonávána (pravděpodobně) v dnešním stávajícím, či obdobném rozsahu vždy. To samé platí o rozsahu zpracovávaných a uchovávaných dat. Avšak aplikační a technologický aspekt informačního systému se bude (pravděpodobně) měnit a vyvíjet (dle historie papírová evidence, dnes centrální digitální registr). Mějme agendu registru obyvatel (ROB), tato agenda bude vykonávána (pravděpodobně) v dnešním stávajícím, či obdobném rozsahu vždy. To samé platí o rozsahu zpracovávaných a uchovávaných dat. Avšak aplikační a technologický aspekt informačního systému se bude (pravděpodobně) měnit a vyvíjet (dle historie papírová evidence, dnes centrální digitální registr).
  
-===== Strategie =====+</WRAP> 
 + 
 +==== Strategie ====
  
 Vrcholové požadavky a omezení, jenž se následně mají uplatnit. Jedná se zejména o plnění strategických cílů v zatím velice abstrahované podobě, tedy business objectives. Jejich uplatněním vznikají již jednotné principy, zásady, které tvoří základní rámec pro následný tvořený či užívaný ICT řešení. Těmito principy a zásadami se téže myslí architektonický pohled na věc a požadavky plynoucí z architektury úřadu. Vrcholové požadavky a omezení, jenž se následně mají uplatnit. Jedná se zejména o plnění strategických cílů v zatím velice abstrahované podobě, tedy business objectives. Jejich uplatněním vznikají již jednotné principy, zásady, které tvoří základní rámec pro následný tvořený či užívaný ICT řešení. Těmito principy a zásadami se téže myslí architektonický pohled na věc a požadavky plynoucí z architektury úřadu.
Řádek 1191: Řádek 1272:
 Tato část obsahuje konkrétní Vize o funkčnosti (co má tedy ICT řešení dělat) konkrétního ICT řešení. Tato část obsahuje konkrétní Vize o funkčnosti (co má tedy ICT řešení dělat) konkrétního ICT řešení.
  
 +<WRAP center round info 60%>
 Příklad: Příklad:
  
 Resort má zřizovanou organizaci s širokou pobočkovou sítí. Ovšem strategie resortu hovoří o centralizaci podpůrných služeb, ale zachovat širokou sít poboček, kde nadále bude pomáháno klientům veřejné správy a části klientů bude vyhovovat aplikace na portálu občana, Z čehož může vzejít požadavek na centrální Cloudové řešení, avšak s mnoha koncovými body, kde jedna část systému má moduly pro řadového pracovníka stání správy a další modul zajištuje portál občana. Resort má zřizovanou organizaci s širokou pobočkovou sítí. Ovšem strategie resortu hovoří o centralizaci podpůrných služeb, ale zachovat širokou sít poboček, kde nadále bude pomáháno klientům veřejné správy a části klientů bude vyhovovat aplikace na portálu občana, Z čehož může vzejít požadavek na centrální Cloudové řešení, avšak s mnoha koncovými body, kde jedna část systému má moduly pro řadového pracovníka stání správy a další modul zajištuje portál občana.
  
-===== Plán a příprava =====+</WRAP> 
 + 
 +==== Plán a příprava ====
  
 Tato fáze se dá rozlišit na dva základní režimy, po analýze, jež určuje dané přiřazení. Těmi jsou: typizované řešení a tvorba unikátního nového řešení. Zároveň v plánu dochází případně k přípravě rámcových smluv, které umožňují průběžně čerpání dle potřeby. Sběr požadavků jako metodika, která vyústí v jejich sesbírání a zpracování je následně použita pro výběr mezi možnostmi, které jsou uvedeny v následujících podkapitolách. Tato fáze se dá rozlišit na dva základní režimy, po analýze, jež určuje dané přiřazení. Těmi jsou: typizované řešení a tvorba unikátního nového řešení. Zároveň v plánu dochází případně k přípravě rámcových smluv, které umožňují průběžně čerpání dle potřeby. Sběr požadavků jako metodika, která vyústí v jejich sesbírání a zpracování je následně použita pro výběr mezi možnostmi, které jsou uvedeny v následujících podkapitolách.
  
-==== Komerčně dostupné, balíkové řešení, COTS ====+=== Komerčně dostupné, balíkové řešení, COTS ===
  
 OVS vybírá optimální dostupní komerční řešení. Toto řešení však nemusí vždy úplně vyhovovat z důvodu specifických požadavků. Úprava tohoto řešení je rozvíjena standardizovanými metodami, které to umožňují, tato možnost úprav je reflektována už při pořizování. OVS vybírá optimální dostupní komerční řešení. Toto řešení však nemusí vždy úplně vyhovovat z důvodu specifických požadavků. Úprava tohoto řešení je rozvíjena standardizovanými metodami, které to umožňují, tato možnost úprav je reflektována už při pořizování.
Řádek 1205: Řádek 1289:
 Za COTS považujeme i Open Source, který je specifický tím, že je v samotném základu zdarma, ale podpora, či další funkcionality, jako je například rozvoj na míru, je již placená (pokud toto není řešeno vlastními zdroji). Za COTS považujeme i Open Source, který je specifický tím, že je v samotném základu zdarma, ale podpora, či další funkcionality, jako je například rozvoj na míru, je již placená (pokud toto není řešeno vlastními zdroji).
  
-==== Nové řešení ====+=== Nové řešení ===
  
 V rámci konkrétní přípravy vzniká základní, rozsáhlý a detailně vyspecifikovaný seznam požadavků, které jsou kladeny na nové ICT řešení. Na základě tohoto seznamu dojde k vyhovení jednotlivých možných variant řešení. Z těchto řešení je vybráno to optimální, vzhledem k holistickému principu. Následně pokud dochází k dalším úpravám, či změnám zadání, je nutné tento prvotní seznam stále aktualizovat a verzovat. V rámci konkrétní přípravy vzniká základní, rozsáhlý a detailně vyspecifikovaný seznam požadavků, které jsou kladeny na nové ICT řešení. Na základě tohoto seznamu dojde k vyhovení jednotlivých možných variant řešení. Z těchto řešení je vybráno to optimální, vzhledem k holistickému principu. Následně pokud dochází k dalším úpravám, či změnám zadání, je nutné tento prvotní seznam stále aktualizovat a verzovat.
  
-===== Realizace =====+==== Realizace ====
  
 V průběhu realizace při dobře nastavených požadavcích z minulé fáze se v této fázi akcentuje zejména implementace daných požadavků a jejich kontrola kvality (tedy shoda dle specifikace). V průběhu realizace při dobře nastavených požadavcích z minulé fáze se v této fázi akcentuje zejména implementace daných požadavků a jejich kontrola kvality (tedy shoda dle specifikace).
Řádek 1215: Řádek 1299:
 Avšak běžnou praxí je nutné být připraven i na další změnová řízení už i v průběhu samotné realizace. A to na základě režimu změnového managementu, kdy jsou nové požadavky vytvářeny a zpracovávány. Vyřešení těchto nových požadavků je však finančně mnohem náročnější, proto je důležité příčiny vzniku těchto požadavků minimalizovat. Avšak běžnou praxí je nutné být připraven i na další změnová řízení už i v průběhu samotné realizace. A to na základě režimu změnového managementu, kdy jsou nové požadavky vytvářeny a zpracovávány. Vyřešení těchto nových požadavků je však finančně mnohem náročnější, proto je důležité příčiny vzniku těchto požadavků minimalizovat.
  
-===== Produkční provoz =====+==== Produkční provoz ====
  
 Z hlediska učící se organizace se i při provozu musí monitorovat, uchovávat a spravovat v té době nově vyvstalé požadavky. Z hlediska učící se organizace se i při provozu musí monitorovat, uchovávat a spravovat v té době nově vyvstalé požadavky.
Řádek 1223: Řádek 1307:
 Pro provozní optimalizaci se využívají manažerské metody typu PDCA (a jeho varianty, DMAIC, 8D), lean Six Sigma, které mohou využívat monitorovací nástroje pro optimilzace chodu systému. Pro provozní optimalizaci se využívají manažerské metody typu PDCA (a jeho varianty, DMAIC, 8D), lean Six Sigma, které mohou využívat monitorovací nástroje pro optimilzace chodu systému.
  
-===== Vyhodnocení =====+==== Vyhodnocení ====
  
 V této části se vypořádávají a dávají podnět k realizaci zásadních změny a modernizace. Ty spolu se strategií a jejími změnami zahajují nový životní cyklus ICT řešení. V této části se vypořádávají a dávají podnět k realizaci zásadních změny a modernizace. Ty spolu se strategií a jejími změnami zahajují nový životní cyklus ICT řešení.
  
-===== Ukončení služby =====+==== Ukončení služby ====
  
 Exit strategie. ICT řešení samotná již při návrhu musí počítat s eventualitou ukončení ICT řešení, nebo částečného ukončení, řešení a udržitelnosti ICT řešení včetně problematiku přenosu dat z ICT řešení jako takového. Exit strategie. ICT řešení samotná již při návrhu musí počítat s eventualitou ukončení ICT řešení, nebo částečného ukončení, řešení a udržitelnosti ICT řešení včetně problematiku přenosu dat z ICT řešení jako takového.
Řádek 1233: Řádek 1317:
 Prvním procesem je zjištění návazností na ostatní ICT řešení, pakliže tady tyty neexistují, či byly vyřešeny, tak je možné ICT řešení ukončit. Následně v takovémto ICT řešení jsou zbylá data vypořádána, buď aktivním přesunem do dalších částí infrastruktury, nebo svojí archivací. Archivována mají být nejen data, ale i stav, verze sestavení (build), a další data ICT řešení. Podchycení této fáze se provádí pomocí dostatečné dokumentace ICT řešení, datového modelu a přístupům ke kódu. Z tohoto hlediska se jedná o nastavení dostatečné kvality nefunkčních požadavků a právních vztahů. Je možné si představit, pakliže k ICT řešení máme plná práva, že dojde pouze k částečnému ukončení části ICT řešení. Tato dílčí část ICT řešení se následně může využít v dalších řešeních. Prvním procesem je zjištění návazností na ostatní ICT řešení, pakliže tady tyty neexistují, či byly vyřešeny, tak je možné ICT řešení ukončit. Následně v takovémto ICT řešení jsou zbylá data vypořádána, buď aktivním přesunem do dalších částí infrastruktury, nebo svojí archivací. Archivována mají být nejen data, ale i stav, verze sestavení (build), a další data ICT řešení. Podchycení této fáze se provádí pomocí dostatečné dokumentace ICT řešení, datového modelu a přístupům ke kódu. Z tohoto hlediska se jedná o nastavení dostatečné kvality nefunkčních požadavků a právních vztahů. Je možné si představit, pakliže k ICT řešení máme plná práva, že dojde pouze k částečnému ukončení části ICT řešení. Tato dílčí část ICT řešení se následně může využít v dalších řešeních.
  
-====== Sběr požadavků vzhledem k hierarchizaci úřadu ======+===== Sběr požadavků vzhledem k hierarchizaci úřadu =====
  
 Správa požadavků v organizaci je komplexní činnost, která se dotýká více vrstev správy požadavků, kde cyklus je stejný, avšak je realizován na několika různých vrstvách. Požadavek může být přenesen z nižší vrstvy na nižší a na opak. Vrstvy jsou z pohledu z vrchu dolů následující: Správa požadavků v organizaci je komplexní činnost, která se dotýká více vrstev správy požadavků, kde cyklus je stejný, avšak je realizován na několika různých vrstvách. Požadavek může být přenesen z nižší vrstvy na nižší a na opak. Vrstvy jsou z pohledu z vrchu dolů následující:
Řádek 1246: Řádek 1330:
 V předchozích kapitálách bylo řečeno, že s požadavky jde provádět indukce (domyšlení souboru požadavků) a dedukce (z obecného požadavku vytvořit požadavek dílčí). Tato činnost se děje ve stejné vrstvě. V předchozích kapitálách bylo řečeno, že s požadavky jde provádět indukce (domyšlení souboru požadavků) a dedukce (z obecného požadavku vytvořit požadavek dílčí). Tato činnost se děje ve stejné vrstvě.
  
 +<WRAP center round info 60%>
 Příklad: Příklad:
  
Řádek 1252: Řádek 1337:
 Byl vznesen požadavek, aby data uložená v subsystému byla šifrována. Indukcí dojede na to, že mají existovat bezpečnostní požadavky. Námět na kategorii bezpečnostní požadavků je přenesen výše na úroveň celého systému, následně skupiny systému, úřadu a celorepublikovou úroveň. Dále požadavek na bezpečnost je přenesen i níže na úroveň funkce Byl vznesen požadavek, aby data uložená v subsystému byla šifrována. Indukcí dojede na to, že mají existovat bezpečnostní požadavky. Námět na kategorii bezpečnostní požadavků je přenesen výše na úroveň celého systému, následně skupiny systému, úřadu a celorepublikovou úroveň. Dále požadavek na bezpečnost je přenesen i níže na úroveň funkce
  
-====== Obecné požadavky a typizované systémy ======+</WRAP>
  
-K dokumentu jsou přiloženy vzorové požadavky na ICT řešení, které jsou 
  
-  - Povinné, nebo +===== Reference =====
-  - K povinnému vyjádření o potřebě +
- +
-===== To-Be ===== +
- +
-  - EKIS (Vnitřní, vnější, majetek, smlouvy, poplatky a výkazy), +
-  - HR (mzdy, státní služba, komunikace s MV, role), +
-  - Portály, +
-    - Zdroj NAP, zkusil bych vybrat +
-  - Spisová služba +
-    - Standard spisové služby ve formě funkčních požadavků zpracovává MV zde na odkazu: +
-      - [[https://www.mvcr.cz/clanek/narodni-standard-pro-elektronicke-systemy-spisove-sluzby.aspx|https:%%//%%www.mvcr.cz/clanek/narodni-standard-pro-elektronicke-systemy-spisove-sluzby.aspx\\ +
-]]Nefunkční požadavky použijte naše. +
-  - Správa rozhodných skutečností, +
-  - Správa subjektů, +
-  - Správy případů vč. logů IDM, +
-  - Systémy samosprávy (matrika, spisovky), +
-  - Typizovaný AIS, +
-  - E-mail, +
-  - Provozní systémy: docházka, stravování, +
-  - Integrace – sice není systémem, ale musí by být podchycena. +
- +
-===== Vzorové rozdělení IS do 5 kategorií ===== +
- +
-  - Provozní, +
-  - Agendové, +
-  - Bezpečností (SIEM, certifikáty, autority) +
-  - Portály, +
-  - Spisová služba. +
- +
-Kde každá může být dále rozdělena na +
- +
-  - Vlastní vývoj ICT řešení, +
-  - Úprava stávajícího ICT řešení, +
-  - Zakoupení existujícího prodaného (COTS) ICT řešení +
- +
-====== Vedlejší znovu využitelné výstupy a vstupy této metodiky ====== +
- +
-Jak vstup i výstup této metodiky je možné znovu využít či použít vyjmenované materiály: +
- +
-  - Stav systému a procesů //AS IS// – stav systémů a procesů v současné době +
-  - Zamýšlený stav systému //TO BE// – plánovaný stav systémů a procesů +
-  - Mapovat Byznys procesy – stav byznysových procesů +
-  - Vytvářet a užívat podklady pro změnu Byznys procesů +
-  - Vytvářet a užívat podklady pro změnu procesů +
-  - Vytvářet a užívat podklady pro organizační změny +
-  - Uceleně vytvořit a dále rozvíjet schopnost organizování a správy požadavků, a to jak v rámci celého životního cyklu jednotlivých informačního systému, tak i organizace a jejích požadavků jako celku. +
- +
-====== Reference ======+
  
 **Hewitt, Eben. 2018.** //Technology Strategy Patterns.// Sebastopol : O'Reilly Media, Inc., 2018. **Hewitt, Eben. 2018.** //Technology Strategy Patterns.// Sebastopol : O'Reilly Media, Inc., 2018.
Řádek 1311: Řádek 1347:
  
 **Wiegers, Karl Eugene. 2013.** //Software Requirements, Third Edition.// Redmond : Microsoft Press, 2013. **Wiegers, Karl Eugene. 2013.** //Software Requirements, Third Edition.// Redmond : Microsoft Press, 2013.
-