VŠB Ostrava (státnice)

Předměty

2013-02-12T07:02:23+00:00

5.semestr

POS (Grygarek)
DAIS (Amalka, přednąky, barborka)
NM (Vondrák)
ZPG(Němec)

4.semestr

PJP (Běhálek)
TS (moodle)

3.semestr

Matematika (Kovář)
Prog.techniky (Běhálek)
C# (Bober)
ARP (Ličev, Olivka)
SWI (Vondrák)

2.semestr

Matematika (Bouchala)
materiály (kat454)
Logické obvody

1.semestr

Lin.algebra (Vondrák)
Java (Krátký)
Se�ity
projekty
IT
slovníček

Facade

2014-07-25T10:03:48+00:00

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.

Builder

2014-07-25T07:44:35+00:00

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.

Struktura OS

2014-06-07T06:56:53+00:00

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:

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.
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

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

2014-06-06T20:05:12+00:00

Úč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.

Hledáme co je vstupem a výstupem těchto funkcí a jak jsou tyto funkce strukturovány. Následuje
Další krok popisující jak tyto funkce budou zajišťovat transformaci vstupů na výstupy pomocí k tomu určených aktivit a procesů.
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:

Funkční přístup zaměřený především na funkce, jejich strukturování, vstupy a výstupy. Příkladem metody je IDEF.
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.
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

Testovací plán

2014-06-05T10:02:44+00:00

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

Kvalitativní a kvantitativní analýza rizik

2014-06-05T06:42:10+00:00

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.

Řízení rizik

2014-06-04T19:37:02+00:00

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.

Řízení projektu

2014-06-04T18:22:56+00:00

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)

Plánování projektu

2014-06-04T15:49:36+00:00

Plán projektu je formální, schválený dokument, který se používá jako vodítko pro realizaci projektu a projektového řízení. Primárně se plán projektu používá na zdokumentování předpokladů a rozhodnutí, usnadnění komunikace mezi zúčastněnými stranami, a zdokumentování schváleného rozsahu, ceny a harmonogramu. Plán projektu může být pouze souhrnný nebo velmi podrobný.

V plánování je nutné identifikovat potřebné zdroje, defininovat rizika a předpokladané omezení s jejich dopady. Činnost procesu vrcholí v sestavení realistického časového rámce a rozpočtu projektu a přípravě detailních plánů na realizaci projektu.

Plán projektu by měl optimálně obsahovat 4 základní otázky důležité pro projekt a jeho řízení:

Proč? Z jakých důvodů se projekt realizuje? Jaký problém nebo nedostatek má projekt vyřešit? Proč je třeba vynaložit prostředky a úsilí na jeho realizaci?
Co? Co je cílem a výstupem projektu? Jaké jsou hlavní produkty nebo výstupy projektu?
Kdo? Kdo se na realizaci projektu bude podílet? A co bude povinností jednotlivých zúčastněných v rámci projektu? Jak budou účastníci projektu organizováni?
Kdy? Jaký je harmonogram projektu? Jaké jsou významné milníky v průběhu realizace projektu? Jaká je časová osa projektu a kdy nastanou zvláště významné body označované jako milníky, je kompletní?

Cíle plánování

- nejkratší možný čas trvání projektu (souvisí také s náklady)

- nejnižší náklady

- nejmenší riziko

- efektivní využití zdrojů

Strategické cíle plánování by měly být SMART (specific - konkrétní, Measurable - měřitelné, Attainable - dosažitelné, Relevant - relevantní, Time-bound - časově vymezené)

Součásti plánu projektu

stanovení rozsahu
rozpis činností spjatých s projektem - struktura a členění prací
časový harmonogram-milníky
odhad nákladů - plán rozpočtu
organizační uspořádání týmu, plán personálního zabezpečení
přiřazení úloh a odpovědností pracovníkům
určení délky trvání jednotlivých prací
plán komunikace
klíčová rizika, omezení a předpoklady plánované odezvy na rizika
pomocné plány řízení rozsahu, harmonogramu, nákladů, ...

Podpůrné techniky

Brainstorming - vytyčení nápadů na projekt

SWOT analýza - určení silných a slabých stránek projektu

Ganttův diagram - harmonogram projektu

SWOT analýza

S - Strengths - charakteristika silných stránek projektu

W - Weaknesses - charakteristika slabých stránek projektu, jaké jsou nevýhody oproti konkurečním řešením

O - Opportunities - příležitosti na trhu

T- Threats - hrozby

Jednotlivé položky SWOT analýzy je vhodné ohodnotit, aby byla určena jejich důležitost. Na základě důležitosti je možné stanovit význam jednotlivých částí a zohlednit je při tvorbě strategií.

Brainstorming

Brainstorming je skupinová technika zaměřená na generování co nejvíce nápadů na dané téma. Je založena na skupinovém výkonu. Nosnou myšlenkou je předpoklad, že lidé ve skupině, na základě podnětů ostatních, vymyslí více, než by vymysleli jednotlivě.

Před započetím se problém zopakuje.
Mluvit by měl v jednom okamžiku pouze jeden.
Po fázi vymýšlení přijde na řadu výběr nejlepších nápadů ze všech zapsaných.
Zveřejněné nápady by neměly být nikým komentovány ani hodnoceny.
I ten zdánlivě nejhloupější může inspirovat ostatní.
Podpora uvolněné atmosféry - U brainstormingu jde především o kvantitu nápadů. Pomáhá neformální prostředí, tým, který se navzájem zná, žádná kritika ostatních. Dobrá nálada podporuje divergentní (rozbíhavé) myšlení.
Všechno zapisovat - Formální struktura brainstormingového týmu by měla obsahovat pouze zapisovatele, tedy člověka, který se nemusí nutně zúčastnit vymýšlení, ale zapíše všechny nápady, které byly řečeny. Čím více nápadů, tím pravděpodobnější je nalezení nejlepší varianty.

Harmonogram projektu - Ganttův diagram

Je označení pro časový plán projektu, který obsahuje posloupnost provedení jednotlivých činností, plánovaná data plnění těchto činností a klíčové milníky projektu. Harmonogram projektu bývá v praxi většinou vyjádřen formou Ganttova diagramu, který vyjydřuje časové návaznosti činností. Jednotlivé činnosti a dílčí procesy mohou probíhat souběžně a jejich dokončení může být podmíněno kteroukoliv z dalších rozpracovaných částí.