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:44] – Tomáš Šedivecznalostni_baze:funkcni_nefunkcni_pozadavky [2024/06/13 14:46] (aktuální) – [Sběr požadavků vzhledem k hierarchizaci úřadu] Tomáš Šedivec
Řádek 60: Řá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 138: Řá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 199: Řá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 327: Řá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 337: Řá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 406: Řá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 544: Řádek 552:
 Úř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> </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 686: Řá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 742: Řá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 798: Řá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%> <WRAP center round info 60%>
Řádek 1032: Řá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 1342: Řádek 1340:
  
  
 +===== 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.