Rozdíly

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

Odkaz na výstup diff

Obě strany předchozí revize Předchozí verze
Následující verze		 Předchozí verze
znalostni_baze:funkcni_nefunkcni_pozadavky [2024/06/13 12:26] – 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í.
 +
 +</WRAP>
  
 ===== Výhody a správná aplikace modularity ===== ===== Výhody a správná aplikace modularity =====
Řádek 389: Řádek 408:
  
 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.
 +
 +</WRAP>
  
 === Modularita podpořená více dodavateli – manažerské zajištění integrace na straně objednatele === === Modularita podpořená více dodavateli – manažerské zajištění integrace na straně objednatele ===
Řá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 418: Řádek 444:
  
 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.
 +
 +</WRAP>
  
 ===== Souvislost požadavků, zadávacího řízení a udržitelnosti ICT řešení v průběhu jeho životního cyklu ===== ===== Souvislost požadavků, zadávacího řízení a udržitelnosti ICT řešení v průběhu jeho životního cyklu =====
Řá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.
 +
 +</WRAP>
  
 ==== Možnost rozdělení rolí ==== ==== Možnost rozdělení rolí ====
Řá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ů).
 +
 +</WRAP>
  
 ====  Rozdělení na dodavatele a implementátora ==== ====  Rozdělení na dodavatele a implementátora ====
Řá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.
 +
 +</WRAP>
  
 ==== Výhody a rizika jednotlivých přístupů k licenčním právům a službám ==== ==== Výhody a rizika jednotlivých přístupů k licenčním právům a službám ====
Řá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 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.
 +
 +</WRAP>
  
 === Další rozvoj === === Další rozvoj ===
Řádek 648: Řádek 697:
  
 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“.
 +
 +{{ :znalostni_baze:fnp7.png?600 |}}
  
 ====  Kontinuální činnosti po zavedení ICT řešení ==== ====  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.
 +
 +{{ :znalostni_baze:fnp8.png?600 |}}
  
 === Řízení ICT řešení === === Řízení ICT řešení ===
Řá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ů ==
Řádek 760: Řádek 813:
  
 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á.
 +
 +</WRAP>
  
 == Sběr požadavků ke konkrétnímu ICT řešení == == Sběr požadavků ke konkrétnímu ICT řešení ==
Řádek 770: Řádek 826:
 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ů.
 +
 +</WRAP>
  
 === Sběr požadavků dle postupu sběru === === Sběr požadavků dle postupu sběru ===
Řádek 782: Řádek 841:
 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.
 +
 +</WRAP>
  
 == Iterativní vývoj  == == Iterativní vývoj  ==
Řádek 790: Řádek 852:
 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ů.
 +
 +</WRAP>
  
 ==== Zainteresované strany – stakeholders ==== ==== Zainteresované strany – stakeholders ====
Řádek 802: Řádek 867:
 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.
 +
 +</WRAP>
  
 === Minimální okruh zainteresovaných stran === === Minimální okruh zainteresovaných stran ===
Řádek 860: Řádek 928:
 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ů.
 +
 +</WRAP>
  
 == Sponzor projektu == == Sponzor projektu ==
Řádek 868: Řádek 939:
 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.
 +
 +</WRAP>
  
 === Skryté zainteresované strany – negativní vlivy na projekt === === Skryté zainteresované strany – negativní vlivy na projekt ===
Řádek 973: Řádek 1047:
 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.
- +
- +
-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. +
- +
- +
-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 ==== ==== Interakce mezi dokumenty ====
Řá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í.
 +
 +</WRAP>
  
 ==== Standardizovaný proces sběru požadavků ==== ==== Standardizovaný proces sběru požadavků ====
Řádek 1054: Řádek 1114:
 Úř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ů.
 +
 +</WRAP>
  
 ==== Odpovědnost ==== ==== Odpovědnost ====
Řádek 1062: Řádek 1125:
 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 ===
Řádek 1084: Řádek 1150:
 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.
 +
 +</WRAP>
  
 == Odpovědnost za požadavky == == Odpovědnost za požadavky ==
Řádek 1096: Řádek 1165:
 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 **
Řádek 1104: Řádek 1176:
 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ě.
 +
 +</WRAP>
  
 ====  Standardizace rolí při sběru požadavků ==== ====  Standardizace rolí při sběru požadavků ====
Řádek 1112: Řádek 1187:
 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.
 +
 +</WRAP>
  
 ==== Využití sběru požadavků jako nástroje průběžné změny nebo rozvoje ==== ==== Využití sběru požadavků jako nástroje průběžné změny nebo rozvoje ====
Řá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).
 +
 +</WRAP>
  
 ==== Strategie ==== ==== Strategie ====
Řá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.
 +
 +</WRAP>
  
 ==== Plán a příprava ==== ==== Plán a příprava ====
Řá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
  
 +</WRAP>
 +
 +
 +===== Reference =====
 +
 +**Hewitt, Eben. 2018.** //Technology Strategy Patterns.// Sebastopol : O'Reilly Media, Inc., 2018.
  
 +**ISO/IEC/IEEE. 2011.** ISO/IEC/IEEE 29148:2011(E). //Systems and software engineering — Life cycle processes — Requirements engineering.// 2011.
  
 +**Wiegers, Karl Eugene. 2013.** //Software Requirements, Third Edition.// Redmond : Microsoft Press, 2013.