Lucka Žoltá

Řízení projektu

Projektové řízení můžeme definovat jako plánování, organizování a řízení činností a jejich zdrojů v rámci uceleného projektu za respektování časových, zdrojových a nákladových omezení (obvykle s cílem dosažení maximálního ekonomického efektu).

Projektové řízení musí odpovědět na následující otázky:

• Jak dlouho bude trvat realizace projektu?
• Jaké jsou časové a finanční rezervy pro splnění plánu?
• Je dostatek zdrojů ke komplementaci projektu, jak je naplánován?
• Jaké jsou náklady na jednotlivé zdroje aplikované na projektu?

Nástroje řízení

• Metoda kritické cesty (Critical Path Method – CPM) – síťová analýza
• Technika hodnocení a kontroly programů (Program Evaluation and Review Technique – PERT) – síťový uzlově orientovaný graf
• Ganttův diagram – úsečkový, grafická prezentace na časové ose
• Exekutivní informační systémy (Executive Information Systems –EIS)
• Distribuované projektové řízení – aplikuje a integruje nástroje pro plánování a řízení inovací, nástroje pro podporu rozhodování, CAD,CAM,…

Metoda kritické cesty

Sestrojíme orientovaný, ohodnocený graf reprezentující projekt. Každá hrana v něm má svoji váhu a každý vrchol své označení + dvě prázdné proměnné (levá a pravá) pro zápis hodnot cest. Hrany, které budou ležet na cestách budeme označovat. Graf může obsahovat i více než jednu kritickou cestu.

Nejprve projdeme graf zleva ze vstupního vrcholu (hodnota jeho levé proměnné je na začátku 0). Do levé proměnné tohoto vrcholu pak zapíšeme hodnotu cesty (hodnota cesty z předchozího vrcholu + hodnota hrany). Hranu vybíráme tak, že při vstupu do nějakého vrcholu budeme vybírat vždy hranu, ze které dostaneme nejvyšší hodnotu cesty (např. do vrcholu D půjdeme po hraně z B, protože cesta má hodnotu 7, což je vyšší než z C, kde má cesta hodnotu 4).

Tímto postupem vyplníme levé proměnné všech vrcholů a dojdeme až do výstupního (koncového) vrcholu grafu. V jeho levé proměnné nyní máme minimální délku projektu.

Druhý průchod grafu začínáme v koncovém vrcholu, opíšeme hodnotu z jeho levé proměnné do pravé a jdeme proti směru orientovaných hran (vpravo). Nyní však vybíráme cestu s nejmenší možnou hodnotou a její hodnotu hran odečítáme, výsledek zapíšeme do pravé proměnné vrcholu (např. do D půjdeme přes G, protože dostaneme hodnotu 7, což je menší, než kdybychom tam šli přímo z H). Když dojdeme do počátečního bodu, měli bychom v něm mít vpravo 0. Vrcholy se stejnými hodnotami vlevo a vpravo leží na kritické cestě (na obrázku označené červeně).

Soft skills při vedení projektu

Co to znamená vést skupinu?

• Dosahovat se skupinou požadovaných výsledků
• Vytvářet postoje, které motivují skupinu k nejlepšímu výkonu
• Přinášet postoje skupiny uspokojení z práce na projektu a z jejich vlastních výsledků
• Využívat schopností vést skupinu, získaných dříve studiem i zkušenostmi

Rozdíl mezi řízením a vedením

• řízení = Autoritativní proces, kdy vedoucí řídí, rozkazuje a nařizuje
• vedení = Vedoucí je se svou skupinou, umožňuje skupině vidět výsledky a učit se z chyb

Ideální je, když vedoucí řídí úkoly a vede lidi.

Definice ideálního vedoucího

• je v denním kontaktu s členy skupiny - zajímá se o ně a motivuje je
• je k dispozici v případě potřeby
• soustředí se na hlavní cíle projektu a připomíná je ostatním
• rozpoznává včas překážky a odstraňuje je
• je důsledný, dodržuje sliby
• podílí se se skupinou o maximum informací
• informuje a naslouchá
• ví co lidé dělají a co by chtěli dělat
• pomáhá skupině dosáhnout cílů a aby lidé cítili úspěch
• rozhoduje se bez omluv, rozhodnutí lehce nemění
• vyjednává s dobrou vůli a otevřeně
• předpokládá že členové skupiny jsou zralí, mají snahu růst, jsou motivovaní a že pracují kvalitně
• nešetří uznáním a odměnami

Čerpáno ze skript Information Management (Ing. Přemysl Soldán)

Modelovací jazyky byznys procesů – IDEF0, UML, EPC, BPMN

Účelem modelování je vytvoření takové abstrakce procesu, která umožňuje pochopení všech jeho aktivit, souvislostí mezi těmito aktivitami a rolemi zapojenými do tohoto procesu.

Při sestavování podnikového modelu je nejprve je nutné identifikovat, jaké funkce daná organizace či podnik má plnit a za jakým účelem. 

1. Hledáme co je vstupem a výstupem těchto funkcí a jak jsou tyto funkce strukturovány. Následuje 
2. Další krok popisující jak tyto funkce budou zajišťovat transformaci vstupů na výstupy pomocí k tomu určených aktivit a procesů.
3. Nakonec je nutné definovat, čím konkrétně jsou v předchozích krocích definované toky dané a kdo a co bude realizovat specifikované aktivity. 

V podstatě tedy existují tři základní přístupy, které se využívají k modelování procesů, a které vychází ze tří základních typů použité abstrakce: 

1. Funkční přístup zaměřený především na funkce, jejich strukturování, vstupy a výstupy. Příkladem metody je IDEF.
2. Přístup specifikací chování je zaměřen na řídící aspekt vykonávání procesu cestou stanovení událostí a podmínek, za kterých mohou být jednotlivé aktivity prováděny. Příkladem je metoda EPC, BPMN.
   
3. Strukturální přístup je zaměřen na statický aspekt procesu. Cílem je postihnout entity a zdroje vystupující v procesu včetně jejich atributů, činností (služeb) a vzájemných vazeb. Určuje se pomocí UML.

IDEF (Integration DEFinition)

Metoda IDEF, konkrétně IDEF0, poskytuje modelovací jazyk s danou syntaxí a sémantikou, umožňující vytvořit strukturovanou grafickou reprezentaci systému nebo organizace. Budeme se zabývat typem IDEF0 určeným pro účely sestavení funkčního modelu, který strukturovaným způsobem popisuje funkce modelované doménové oblasti (existuje i IDEF1- struktura systému a IDEF2- chování). 

Skládá se z následujících prvků: 

1. Funkce (Function) popisující činnost transformující vstup na požadovaný výstup. 

2. Vstupem (Input) jsou data nebo objekty, které budou funkcí transformovány na výstup. 

3. Výstupem (Output) rozumíme data nebo objekty produkované funkcí. 

4. Řízení (Control) je dáno pravidly potřebnými k vytvoření požadovaného výstupu. 

5. Mechanismus (Mechanism) definuje prostředky nutné k realizaci funkce. 

Každá funkce nese své číselné označení (ID) a případně také označení diagramu - aby bylo možné vytvářet hierarchii diagramů odpovídající dekompozici funkcí (rozložení na podfunkce). Je zde pravidlo že diagram by neměl mít méně než tři a více než šest funkcí. Platí zde také důležitá vlastnost těchto diagramů, kdy výstupy dané funkce mohou být vstupem, řízením či mechanismem jiných funkcí. Tímto způsobem jsou definovány vzájemné závislosti mezi funkcemi. 

 Příklad IDEF0 - realizace zakázky.

EPC (Event-driven Process Chains)

Určuje jaká bude posloupnost aktivit, případně, které z aktivit budou moci být realizovány souběžně (paralelismus). Spočívá v řetězení událostí a aktivit do posloupnosti realizující požadovaný cíl. Z obecného pohledu vykonávání procesu událost definuje vstupní podmínku (precondition) uskutečnění aktivity. Ukončení aktivity pak definuje další událost – výstupní podmínku (postcondition), na kterou mohou navazovat další aktivity. Z toho vyplývá, že každá aktivita je vymezena dvěmi událostmi a tak je i jednoznačně definován její začátek a konec. 

Byznys proces specifikovaný pomocí EPC diagramu využívá následujících elementů:

• Aktivity (Activities), které jsou základními stavebními bloky určují, co má být v rámci procesu vykonáno. 
• Události (Events) popisují situace před a/nebo po vykonání aktivity. Aktivity jsou vzájemně propojeny pomocí událostí. Jinak řečeno, nějaká událost může vyjadřovat výstupní podmínku jedné aktivity a současně vstupní podmínku jiné aktivity. 
• Logické spojky (Connectors) se používají ke spojování aktivit a událostí. Tímto způsobem je popsán řídící tok procesu. EPC používá tři typy spojek: ∧ (AND – a současně), ∨ (OR – nebo) a XOR (exclusive OR – vzájemně se vylučující nebo). 

- vždycky je střídání události s aktivitou a mezitím dáváme logické spojky. Je tu ale pravidlo, že nemůžeme jít z události do spojky OR nebo XOR (jedině z aktivity).

BPMN (Business Process Model and Notation)

Poskytuje grafické znázornění pro specifikaci podnikových procesů v procesním diagramu (BPD). Procesní diagram je založen na flowchart technologii, která je velmi podobná diagramu aktivit.

Pomocí BPMN vznikají jednoduché diagramy, které se skládají z omezeného počtu grafických prvků. Díky tomu je pro vlastníky procesů, vývojáře a analytiky snadné porozumět procesním tokům i samotným procesům. BPMN se rozděluje na čtyři základní kategorie, viz níže. Tyto čtyři kategorie usnadňují tvorbu jednoduchých diagramů podnikových procesů a také umožňují tvorbu nových druhů tokových objektů a artefaktů, které přispívají k lepší srozumitelnosti diagramů.

Flow objects - Tokové objekty

• Events - Události
• Activities - Aktivity / Činnosti
• Gateways - Brány

Connecting objects - Spojovací objekty

• Sequence flow - Sekvenční tok
• Message flow - Tok zpráv
• Association - Asociace

Swim lanes - Plavecké dráhy (Kontexty)

• Pool - Bazény (Kontext)
• Lane - Dráhy (Oddíly kontextu)

Artifacts - Artefakty

• Data object - Datové Objekty
• Group - Skupiny
• Annotation - Anotace

Řízení rizik

Je potřeba vymezit si důsledně všechna možná rizika pro konkrétní projekt. Rizika vznikají ještě před zahájením samotného projektu a také v jeho průběhu. 

Věcným výstupem procesu analýzy rizik je dokument který obsahuje:

• popis IS
• stanovení úrovně hrozeb
• odhad ztrát
• stanovení protiopatření
• určení zbytkových rizik

Druhy rizik a jejich příklady

Rizika projektová

• špatná komunikace členů týmu - rozdílná interpretace toho co mělo být uděláno 
• opoždění v čase - špatné plánování, malá časová rezerva
• kompetence - pracovníci neodpovídají kvalifikaci
• neznámá kvalita produktu
• neschopnost pracovat jako tým - kulturní rozdíly
• ztráta klíčové osoby - nemocenská, mateřská
• selhání technických zdrojů
• nedodržení rozpočtu

Rizika finanční - daňové změny, inflace, změny úrokových sazeb

Rizika přírodní - povodně, zemětřesení

Rizika vyšší moci - války, katastrofy

Řízení rizik

Disciplína se zabývá tvorbou činností, navzájem provázaných, které se snaží zamezit nebo zmírnit výskyt rizik nebo nemilých překvapení. Rizika ohrožují dosažení našich cílů, mají potenciálně negativní dopad na naši činnost a s určitou pravděpodobností se u naší činnosti vyskytnou. Řízení rizik se snaží tyto negativní dopady co nejvíce eliminovat.

Řízení rizik se skládá ze 4 činností:

1.     Identifikace rizik a oblastí hrozeb - vyhotoví se jejich seznam 

2.     Hodnocení rizik - pro určení hodnoty rizika je nutné nejdříve určit následující hodnoty:

• dopad rizika - na projekt a jeho průběh
• pravděpodobnost - s jakou pravděpodobností riziko nastane

- následně se stanoví hodnota rizika podle tabulky, která určujeme míru akceptovatelnoti rizik (vlevo)

- můžeme mít i víc jak 3 sloupce a řádky, záleží jak podrobnou chceme mít stupnici

- všechny rizika mají přidělené dvě hodnoty od 1-3 s jejich dopadem (I) a s jejich pravděpodobností (P)

=> riziko odpovídá jednomu políčku v tabulce kde se protly jeho hodnoty - high/ medium/ low, kdy high jsou vysoké rizika které se musí neprodleně řešit 

3.     Strategie zvládnutí rizik

Po důkladném zhodnocení rizik je nutné vytvořit plán rizik, ve kterém bude uvedeno určení strategie zvládnutí, minimalizace nebo eliminace rizik. Faktory, které ovlivňují tvorbu strategie: fáze projektu, velikost, priorita, komplexnost, časová a finanční náročnost. Tvorba plánu rizik není nijak složitá, ale je prioritně důležité rozpoznat všechna závažná rizika, které mohou náš projekt ovlivnit a k těmto rizikům navrhnou účinná protiopatření.

V tabulce musí být uvedeno: riziko, váha rizika, jeho pravděpodobnost a jeho hodnota. Dále zde musí být stanoveno preventivní opatření, pokud riziko nastane, jaké kroky podniknout k jeho odstranění nebo minimalizaci. Důležité je také určit odpovědnou osobu spojenou s provedením preventivního opatření. Určení krizového scénáře je další důležitou součástí tabulky plánu rizik. Krizový scénář se stanovuje pro případ, že se nepodaří riziko odstranit nebo jej minimalizovat. 

4.     Monitoring vývoje rizikových stavů

Během jakéhokoli projektu se mohou objevit další rizikové události a proto musejí být rizika stále monitorována. Nikdy nemůžeme určit a rozpoznat všechna rizika a pravděpodobnost, se kterou mohou nastat, proto je důležité abychom stále identifikovali nová rizika a přehodnocovali rizika, která byla již dříve rozpoznána. To znamená, že Plán rizik a jejich řízení se bude stále měnit v čase.

Struktura OS

Co vše provádí operační systém

• Organizuje přístup a využívání zdrojů počítače (čas procesoru, přístup k datům na discích, přístup do paměti).
• Fyzicky zajišťuje vstup a výstup dat podle požadavků ostatních programů.
• Komunikuje s uživatelem a na základě jeho pokynů vykonává požadované akce.
• Reaguje na chybové stavy programů a mylné požadavky uživatelů tak, aby tyto chyby nezpůsobily zásadní destrukci systému nebo poškození dat.
• Spravuje komunikaci s periferiemi. Definuje nastavení klávesnice, citlivost myši a dalších zařízení.
• Eviduje využívání systémových zdrojů apod.

Struktura OS

Operační systém je zpravidla tvořen tzv. jádrem (kernel), ovladači V/V zařízení (driver), příkazovým procesorem (shell) a podpůrnými systémovými programy.

• Jádro - po zavedení do paměti řídí činnost počítače, poskytuje procesům služby a řeší správu prostředků a správu procesů.
• Ovladač - zvláštní (pod)program pro ovládání konkrétního zařízení standardním způsobem. Použití strategie s ovladači umožňuje snadnou konfigurovatelnost technického vybavení.
• Příkazový procesor - program, který umožňuje uživatelům zadávat příkazy ve speciálním, obvykle jednoduchém jazyce.
• Podpůrné programy - do této kategorie jsou mnohdy zahrnovány i překladače (jazyk C v OS UNIX) a sestavující programy. Stojí na stejném místě jako aplikační programy.

Jádro OS

Jádro se zpravidla dělí na dvě podstatné části:

1. Správa procesů - správa procesů (prakticky není u jednoduchých OS) řeší problematiku aktivování a deaktivování procesů podle jejich priority resp. požadavků na prostředky.
2. Správa prostředků - zajišťuje činnost V/V zařízení, přiděluje paměť, případně procesory. Velmi důležitou částí správy prostředků je: správa souborů - způsob ukládání souborů a přístupu k nim. Moderní OS zajišťují jednotný pohled na soubory a zařízení. Zařízení jsou považovány za soubory se speciálním jménem.

Generické komponenty OS

• Správa procesoru (procesorů)
• Správa procesů (proces – činnost řízená programem)
• Správa vnitřní (hlavní) paměti
• Správa souborů Správa I/O systému
• Správa vnější (sekundární) paměti Networking, distribuované systémy Systém ochran Interpret příkazů

Správa procesů

• Proces – činnost řízená programem, provedení programu, „process“ nebo „task“
• Proces potřebuje pro svou realizaci jisté zdroje (CPU, paměť, I/O zařízení, …)
• Z hlediska správy procesů je OS zodpovědný za:
• Vytváření a rušení procesů
• Potlačení a obnovení procesů
• Synchronizace procesů a jejich vzájemná komunikace
• Variantou procesu je tzv. Vlákno – jednotka plánování činností definovaná v programu. Vlákna používají zdroje přidělené procesu.

Správa procesoru

• OS vybírá procesy běžící na dostupných procesorech.
• Dále podle typu OS zde patří i plánování vláken.

Správa vnitřní paměti

• Vnitřní pamětí se myslí primární, operační paměť, neboli fyzický adresový prostor (pole samostatně adresovatelných slov nebo bytů), repositář pohotově (rychle) dostupných dat sdílený CPU a I/O zařízeními.
• Vnitřní paměť energeticky závislá, ztrácející se po výpadku energie.
• OS je z hlediska správy vnitřní paměti odpovědný za:
• Vedení přehledu, který proces v daném okamžiku využívá kterou část paměti
• Rozhodování, kterému procesu po uvolnění paměti tuto paměť poskytnout
• Přidělování a uvolňování paměti
• Programátor vidí logický adresový prostor – ten je vymezen formou adresy v instrukci. OS zavádí programy a data do tohoto prostoru podle potřeby. Transformaci logické adresy na fyzickou se zpravidla provádí až při provádění instrukce. Struktura logického adresového prostoru může být lineární (pole) nebo dvojdimensionální (kolekce samostatných lineárních segmentů proměnné délky).

Správa I/O systémů

Poskytuje repositář vyrovnávacích pamětí a univerzální rozhraní ovladačů (driverů) I/O zařízení, a pak také samotné ovladače (drivery).

Správa vnější paměti

Správa energeticky nezávislé, sekundární paměti s dostatečnou kapacitou. Jako sekundární paměť obvykle slouží disky. OS je zodpovědný za:

• Správu volné paměti
• Přidělování paměti souborům
• Plánování činnosti disku

Správa souborů

Soubor – identifikovatelná kolekce souvisejících dat definovaná svým tvůrcem. Obvykle reprezentuje i programy i data.

OS je z hlediska správy souborů zodpovědný za:

• Vytváření a rušení souborů
• Vytváření a rušení adresářů (katalogů)
• Podporu primitivních operací pro manipulaci se soubory a adresáři
• Zobrazování souborů do sekundární paměti
• Archivování souborů na energeticky nezávislá média
• Networking, distribuované systémy

Distribuovaný systém – kolekce procesorů nesdílejících ani fyzickou paměť, ani hodiny. Procesory distribuovaného systému jsou propojeny komunikační sítí. Komunikace je řízena protokoly.

Systém ochran

Mechanismus pro řízení přístupu k systémovým a uživatelským zdrojům. Tento systém je součástí všech vrstev OS.

Systém ochran musí:

• Rozlišovat mezi autorizovaným a neautorizovaným použitím
• Poskytnout prostředky pro své prosazení

Interpret příkazů

• Většina zadání je předávána operačnímu systému řídícími příkazy, které zadávají požadavky na:
• Správu a vytváření procesů
• Ovládání I/O zařízení
• Správu sekundární paměti
• Práci v síti

Program, který čte a interpretuje příkazy je označován v různých OS různými názvy – command line interpreter, shell, …

Struktura OS podle jádra

• Monolitická jádra (Monolithic kernel)
• Otevřené systémy (Open systems)
• Microkernel

Monolitický OS

OS je na jednom místě (pod „červenou čárou“). Aplikace používá dobře definované rozhraní systémových volání pro komunikaci s jádrem.

Příklady OS – Unix, Windows NT / XP, Linux, BSD, …

Monolitické jádro je specifické pro komerční systémy.

Výhody:

• Dobrý výkon
• Dobře pochopená koncepce
• Jednoduché pro vývojáře jádra
• Vysoká úroveň ochrany mezi aplikacemi

Nevýhody:

• Žádná ochrana mezi komponentami jádra
• Není jednoduše a bezpečně rozšiřitelné jádro
• Celková struktura je ve výsledku komplikovaná, neexistují hranice mezi moduly jádra 

Otevřené Systémy

Aplikace, knihovny i jádro jsou všechny v jednom adresovém prostoru.

Jestli se to zdá být jako šílená myšlenka, zde jsou příklady – MS-DOS, Mac OS 9 a starší, Windows ME, 98, 95, 3.1, Palm OS.

Tato koncepce bývala velmi běžná.

Výhody:

• Velmi dobrý výkon
• Velmi dobře rozšiřitelné
• Výhodné pro jednouživatelské OS

Nevýhody:

• Žádna ochrana mezi jádrem a aplikacemi
• Nepříliš stabilní
• Skládání rozšíření může vést k nepředvídatelnému chování

Microkernel OS

Filosofie návrhu – chráněné jádro obsahuje pouze minimální (malou, čistou, logickou) množinu abstrakcí:

• Procesy a vlákna
• Virtuální paměť
• Komunikace mezi procesy

Všechno ostatní jsou server-procesy běžící na uživatelské úrovni.

Příklady OS – Mach, Chorus, QNX, GNU Hurd

Zkušenosti s tímto návrhem jsou smíšené.

Výhody:

• Přidáním server-procesu se rozšíří funkcionalita OS
• Jádro nespecifikuje prostředí OS
• Servery na uživatelské úrovni se nemusí zabývat hardwarem
• Silná ochrana OS i sám proti sobě (části OS jsou oddělené servery)
• Jednoduché rozšíření na distribuovaný nebo multiprocesorový systém

Nevýhody

• Výkon (Systémová volání viz. dále)
• Špatná minulost

Systémová volání – příklad

Kvalitativní a kvantitativní analýza rizik

Kvantitativní

Kvantitativní analýza je náročnější na zdroje a její provedení trvá mnohem déle než kvalitativní analýza rizik. Je tomu tak proto, že hodnotu aktiva (aktivum = cokoli v organizaci co má má nějakou cenu) je nutné vyjádřit v penězích stejně jako možnou škodu v případě realizace konkrétní hrozby. Vyjádření škody ve finančních jednotkách však umožňuje jednodušší rozhodování ve fázi zvládání rizik, kdy vybíráme vhodná opatření.

Výpočet: pravděpodobnost výskytu události * potenciální ztráta = odhad ztrát (očekávaná ztráta) - ALE/EAC

Problém: nespolehlivost výsledku daná nepřesností výchozích údajů

Výhoda: konkrétní výsledky které se dají porovnávat

Přístupy: 

• Analýza historických dat a statistik,
• Analýza závislostí,
• Síťové analýzy,
• Simulace a modelování,
• Marketingové průzkumy a analýzy trhu,

Postup:

1. Identifikace a kvantifikace aktiv 

• Jak se dané aktivum podílí na výnosech, resp. kolik zisku nám generuje?
• Kolik by stálo opětovné pořízení aktiva a zprovoznění?
• Jakou bychom zaplatili pokutu v případě porušení důvěrnosti, integrity a dostupnosti?

2. Identifikace a kvantifikace hrozeb

• Kvalitativní analýza by měla obsahovat skutečná fakta a dostupné údaje. Pozitiva tohoto přístupu jsou zejména ve schopnosti hodnotit dopady na organizaci nebo jedince, které nelze elementárně vyjádřit v peněžních jednotkách (jak je běžné ukvantitativních analýz). Hodnocení dopadů kvalitativním přístupem však v dnešních metodikách postrádá konzistentnost a schopnost pokrýt všechny aspekty, podle kterých je nutné dopady hodnotit. V praxi si každý rizikový analytik vytváří vlastní způsoby hodnocení dopadů a i dalších parametrů pro stanovení míry rizika.

3. Identifikace a kvantifikace zranitelnosti

• V této fázi bychom se měli u každé dvojice hrozba – aktivum zamyslet nad tím, jakou škodu by mohla hrozba způsobit. Tato ztráta se nejčastěji uvádí v procentech a označuje se zkratkou EF (Exposure Factor). Pro její určení si musíme položit podobné otázky jako v případě stanovení hodnoty aktiva, konkrétně:
• O kolik se sníží výnosy resp. zisk v případě narušení důvěrnosti, integrity a dostupnosti?
• Jaké jsou náklady na zotavení se z dané hrozby a obnovu normální funkčnosti?
• Jakou bychom zaplatili pokutu v případě porušení důvěrnosti, integrity a dostupnosti?

4. Stanovení výše škody

• V okamžiku, kdy jsme stanovili hodnotu aktiva (AV), pravděpodobnost hrozby (ARO) a hodnotu zranitelnosti (EF), můžeme přistoupit ke stanovení výše celkové škody tzv. ALE (Annualized Loss Expectancy), kterou získáme součinem těchto hodnot: ALE=AV*EF*ARO.

Kvalitativní

Používá slov k popisu rozsahu možných následků a pravděpodobností, že se tyto následky přihodí. Užité škály mohou být přizpůsobeny nebo upraveny tak, aby vyhovovaly okolnostem, a různá rizika mohou být popsána různým způsobem.

Kvalitativní analýza je méně náročná na zdroje a trvá kratší mnohem kratší dobu než kvantitativní analýza rizik. Především proto, že hodnotu aktiva není nutné vyjadřovat v penězích stejně jako možnou škodu v případě realizace konkrétní hrozby. To však vede k horší kontrole nákladů ve fázi zvládání rizik, kdy vybíráme vhodná opatření.

Kvalitativní analýza se používá:

• Jako úvodní přehled vedoucí k identifikaci rizik, která vyžadují podrobnější zkoumání;
• Tam, kde tento druh analýzy postačuje k rozhodování; nebo
• Tam, kde číselné údaje nebo zdroje nejsou dostatečné k provedení kvantitativní analýzy.

Princip: Kvalitativní analýza rizik je založena na expertním odhadu jednotlivých aktiv (aktivum = cokoli v organizaci co má má nějakou cenu), hrozeb a zranitelností a pro jejich vyjádření používá slovního nebo číselného hodnocení. Umožňuje tak poměrně snadno a rychle identifikovat ta největší rizika. ).

Nevýhody: Oproti kvantitativní analýze rizik, kde je způsob výpočtu víceméně daný a nikdo ho nezpochybňuje, tak v případě kvalitativní analýzy rizik neexistuje pouze jediná možnost, jak se dobrat výsledku. Možnost zvolit si v podstatě jakoukoliv stupnici pro stanovení hodnoty aktiv, hrozeb a zranitelností představuje sice na jednu stranu výhodu, ale na stranu druhou to komplikuje srovnávání výsledků AR provedených nejrůznějšími společnostmi.

Kvantitativní vs. kvalitativní

Analytici upřednostňující kvantitativní přístup oproti kvalitativnímu často argumentují tím, že kvalitativní hodnocení dopadů je prováděno s vysokou mírou subjektivity, kdy výsledná hodnota závisí z velké části na osobním názoru hodnotitele. Pro stanovení kvantitativní hodnot se využívají výše uvedené metodiky a nástroje (simulace, analýza historických dat a statistik, marketingové průzkumy a analýzy trhu atd.), které však mohou v sobě zahrnovat také jistou míru subjektivity. Odborníci na finance mají k dispozici celou řadu nástrojů na výpočty odhadovaných hodnot, nicméně žádná předpověď rizik i matematicky podložená, nemůže být stoprocentní. Kvantitativní přístupy využívající finanční škály jsou velmi vhodné, pokud je po provedené analýze nutné najít zdroje na pokrytí zjištěných rizik. 

Builder

Slouží k abstrahování tvorby složitých objektů. A to tak, aby stejné výrobní schéma mohlo být použito pro tvorbu různých objektů. Způsob konstrukce těchto objektů je tedy stejný, jednotlivé kroky se však liší. 

Použití Stavitele je vhodné u rozdílných tříd s podobným procesem konstrukce. Samotné třídy mohou být rozdílné a nezávislé. Tím se liší od Abstraktní továrny, která slouží k tvorbě podobných objektů. 

Konstrukci provádí konkrétní implementace rozhraní Builder, ale proces konstrukce řidí třída Director. 

Příklad:

Klient přijde do fastfoodu a chce hlavní menu. Hlavní menu se skládá z hamburgeru, přílohy a nápoje. Výrobní postup je vždy stejný, jen některé kroky mohou být vynechány nebo zaměněny - někdo si objedná cheeseburger jiný může chtít chickenburger bez nápoje. 

Pracovník na přepážce je directorem - vytváří objednávku a řídí pracovníky. O realizaci jednotlivých kroků se starají různé implementace třídy Builder -např. vytvářeč chickenburger menu, vytvářeč cheeseburger menu, apod. Jejich výsledkem je kompletní produkt - balíček se sestaveným jídlem. Menu je možné odebrat teprve poté, kdy jsou všechny kroky konstrukce dokončeny.

Zjednodušeně: Ke konstrukci jednoho objektu slouží právě jeden Builder, proces konstrukce řídí Direktor, objekt ke konstrukci vybírá klient předáním Builderu Direktoru, po ukončení konstrukce si z Builderu pouze vybere výsledek metodou getResult.

Stavitelů ke konstrukci jednoho objektu může být voláno i více. Například pokud je výsledný produkt Composite může být při jeho konstrukci voláno více stavitelů, případně stejný stavitel několikrát za sebou. Tak je zajištěno například vytváření složitých objektů grafického rozhraní operačního systému.

Testovací plán

Testovací plán je výchozím dokumentem testovací dokumentace. V něm jsou stanoveny základní podmínky, za kterých bude testování probíhat.

Obvykle obsahuje testovací plán tyto údaje.

• Cíl testování - definuje, čeho by mělo být testováním dosaženo. Cílem může být například ověření všech funkčností systému, nebo kontrola správné funkčnosti dodatečně přidaných component, stejně tak se může ověřovat správné fungování aplikace na zákazníkem dodané produkční platformě a podobně.
• Přehled plánovaných testů - ten vychází z testovacích požadavků. Ty vychází v převážné míře z dodaných příkladů užití (Use case), dále mohou vyvstat z komunikace se zákazníkem nebo z bussines případů. Jednoduše řečeno je snaha navrhnout takový seznam testů, který postihne všechny funkčnosti aplikace a to z důrazem na použití ze strany zákazníka.
• Stanovení priorit - pro jednotlivé testované prvky aplikace a tedy i pro jednotlivé testy. Nejvyšší prioritou jsou označené ty prvky, které jsou z hlediska funkce aplikace nejvýznamnější, nebo ty, u kterých v případě nefunkčnosti hrozí největší riziko nesplnění cílů testování. Všechny ostatní prvky jsou otestovány až v případě otestování prvků s nejvyšší prioritou.
• Testovací strategie - popisuje, jaké typy testů budou provedeny (např. zátěžové, funkční apod.) a s jakým cílem (obvykle s vazbou na konkrétní use case). Jednotlivé testy pak zařazuje do konkrétních fází testování (integrační testy, akceptační testy apod.) Dále se zde popisují techniky, kterými budou prováděny jednotlivé typy testů. Velice důležité je i stanovení způsobu, jakým se budou testy vyhodnocovat, a kritérií, podle kterých je test označen jako kompletní.
• Požadavky na zdroje - slouží k definování požadavků, které musí být splněny, aby bylo možné testy provést. Sem se řadí jednak požadavky technického rázu jako je příprava testovacího hardwaru, instalace softwaru, zpřístupnění serverů a podobně. A dále zdroje lidské. Zde je vyjmenováno požadované složení testovacího týmu včetně požadavku na spolupráci jiných pracovníků (např. při instalaci a správě testovacího prostředí)
• Definice rizik - slouží k vymezení situací, které mohou ohrozit úspěšné testování. Sem může spadat například nedodání aplikace ve stanoveném termínu, nedostupný testovací nástroj, nebo nedostatek proškolených pracovníků. U těchto rizik se stanoví míra jejich závažnosti a návrh protiopatření.

Facade

Návrhový vzor Facade představuje řešení, jestliže je nutné zjednodušit vstupní bod do systému.

Při vývoji systému se lehce může stát, že celková jeho struktura se stává velmi těžce zvládnutelnou. I použitím návrhových vzorů se mnohdy dostáváme k velmi komplexnímu systému tříd s mnoha vazbami. Navíc každý systém může obsahovat i několik subsystému, které ještě zvětšují obtížnost pochopení zákonitostí systému. Facade představuje „high-level“ rozhraní, které slouží k zjednodušení komunikace mezi klientem a systémem.

Klient komunikuje se systémem pomocí Facade, kterému zasílá požadavky. Facade tyto požadavky zasílá příslušným objektům. Jinak řečeno Facade překládá svoje rozhraní do jednotlivých rozhraní v systému. Říkáme, že Facade je rozhraním systému, ale ve skutečnosti není použito standardní Java rozhraní (deklarované jako interface), ale Facade je implementován jako třída.

Příklad

Představme si systém, jehož úkolem je realizovat vyřízení zakázky ovoce, které objednávají maloobchody. V takovémto systému by neměla chybět třída respektive modul, která zajišťuje skladové hospodářství (Sklad ovoce), prodej ovoce (Obchod) a evidenci platby pohledávek (Účetnictví). Jelikož takové struktura je pro maloobchod nepřehledná, byla vytvořena třída Zásobování, která umožňuje průhlednou komunikaci s těmito moduly. Maloobchod si může zjistit stav svých dluhů, dotázat se na množství ovoce na skladě, zjistit jeho cenu a objednat si určité množství. Zásobování pouze překládá jeho požadavky na příslušné metody tříd v systému.