Analýza a řízení rizik

softwarová rizika – rizika jsou charakteristická tím, že vždy zahrnují nejistoty a v případě, že nastanou, ztráty.

proces řízení rizik  →→→

kategorie rizik

-          obchodní rizika

-          projektová rizika

-          technická rizika

obchodní rizika - vytvoření skvělého produktu, který nikdo nechce (marketingové riziko)

                          - vytvoření produktu, který nezapadá do podnikové strategie (strategické riziko)

                          - vytvoření produktu, kterému obchodní zástupci nerozumí, neví jak ho prodat

                          - ztráta podpory vedení, vlivem změny zaměření nebo změny osob (riziko managementu)

                          - ztráta rozpočtu (rozpočtové riziko)

Jiné rozdělení rizik                            projektová, produktová a obchodní rizika - příklady

-          známá rizika – dají se odhalit po pečlivém vyhodnocení plánu, obchodního a technického prostředí a jiných spolehlivých zdrojů

-          předvídatelná rizika – jsou odhadnuta ze zkušeností z předchozích projektů

-          nepředvídatelná rizika – dají se jen velmi těžko předpovědět

identifikace rizik

-          rizika obecná

o   velikost vytvářeného produktu

§  Odhad velikosti v LOC (Physical Lines of Code, snadno měřitelný, závislý na programovacím jazyku, nevhodné pro neprocedurální jazyky) nebo FP (metoda funkčních bodů, vychází z empirického vztahu mezi počitatelnými veličinami a ohodnocením složitosti, nezávislé na jazyku, vhodné pro odhady)

§  Odhad velikosti produktu v počtu programů, souborů, transakcí

§  Průměrná procentuální odchylka velikosti produktu podle předchozích produktů

§  Velikost databáze vytvářené nebo používané v produktu

§  Počet uživatelů produktu, počet projektovaných změn požadavků pro produkt - před dodáním, po dodání, množství znovupoužitého softwaru

o   obchodní dopad

§  Jak produkt ovlivní zisk společnosti

§  Je dodací termín rozumný

§  Počet zákazníků, kteří budou používat tento produkt

§  Počet ostatních produktů/systémů, s nimiž musí produkt spolupracovat

§  Množství a kvalita dokumentace produktu, která musí být produkována a dodána zákazníkovi

§  Cena za pozdní dodání, cena za defektní produkt

o   charakteristiky zákazníka

§  Pracovali jsme se zákazníkem již dříve

§  Ví zákazník dobře, co chce

§  Souhlasí s tím, že bude muset věnovat čas realizátorům pro stanovení požadavků a identifikaci rozsahu projektu

§  Chce se zúčastnit sledování (inspekcí) projektu

§  Je zákazník technicky vzdělaný v oblasti produktu

o   definice procesu

§  Má vaše organizace metodiku procesu vývoje softwaru, použitelnou pro tento projekt

§  Přijali členové týmu metodiku softwarového procesu a budou ji používat

§  Byla ona metodika softwarového procesu používána i pro jiné projekty

§  Jsou inspekce (formální revize, přezkoumání) specifikací požadavků, návrhu a kódu řádně prováděny

§  Jsou inspekce (formální revize, přezkoumání) dokumentovány, včetně nalezených chyb a použitých zdrojů

§  Je zajištěno, aby práce na projektu odpovídaly standardům SI

§  Existuje správa konfigurací k udržení konsistence v systémových/softwarových požadavcích, návrhu, kódu a testovacích případech

§  Existuje správa změn v požadavcích zákazníka, které mají dopad na software

§  Je pro každý subkontrakt dokumentována práce, specifikace softwarových požadavků a plán softwarového vývoje

o   vývojové prostředí

§  Máte nástroj pro řízení managementu softwarového projektu

§  Jsou k disposici nástroje pro analýzu a návrh

§  Jsou k disposici nástroje pro testování a jsou vhodné pro vytvářený produkt

§  Jsou všechny softwarové nástroje integrovány

§  Byli členové týmu vyškoleni v používání všech nástrojů

o   použitá technologie

§  Je budovaná technologie není dostatečně vyzkoušená

§  Má software rozhraní s novým a neověřeným hardwarem

§  je požadována tvorba programových komponent, které jsou odlišné od dříve vytvářených

§  Je požadováno používání nových metod analýzy, návrhu nebo testování

§  Je požadováno použití nekonvenčních metod vývoje softwaru

§  Zákazník si není jistý, zda bude proveditelná požadovaná funkčnost

o   velikost týmu a jeho zkušenost

§  Máte nejlepší odborníky pro projekt

§  Mají tito lidé odpovídající zkušenosti

§  Je jich dostatečný počet

§  Budou pracovat na projektu na plný úvazek

§  Bude případný úbytek pracovníků dostatečně nízký, aby umožnil kontinuitu

-          rizika specifická

Není-li s projektem spojeno žádné riziko, nesnažte se projekt řešit, neboť projekty bez skutečných rizik „nemají šanci“, nepřinášejí nikdy zisk a i proto nebyly realizovány už v minulosti.

Základní projektové riziko:                          

-          chybný časový plán

-          inflační množství požadavků

-          fluktuace projektových pracovníků

-          nízká produktivita práce

-          selhání díky špatnému zadání

Tabulka rizik projektu – obsahuje seznam všech rizik pro náš projekt s uvedením pravděpodobnosti s jakou mohou nastat, stanovení dělící čáry která oddělí hlavní rizika kterým je třeba věnovat pozornost, pro všechna rizika nad dělící čarou se sestaví RMMM

RMMM = Risk Mittigation, Monitoring and Management - zmírnění, sledování a řízení rizik

-          Snaha vyhnout se rizikům, nebo je zmírnit

-          Monitorovat rizika během projektu

-          Řídit průběh rizikových situací podle připraveného plánu

-          Zvážit cenu RMMM a její užitek

-          Plán RMMM

o   I. Úvod – přehled hlavních rizik a odpovědnosti

o   II. Tabulka rizik projektu – popis rizik a faktorů, které je ovlivňují

o   III. Zmírnění (strategie, postup), monitorování (co a jak hlídat) a řízení rizik (plán co dělat)

o   IV. Harmonogram iterací plánu RMMM

o   V. Závěr

Smysl monitorování rizik - Opatření, která mají sloužit jako odezvy na vybraná rizika. Mohou spadat do jedné ze tří kategorií:

-          Předcházení: Navržené opatření by mělo vyloučit danou hrozbu, obvykle eliminováním její příčiny.

-          Zmírnění: Navržené opatření má snížit dopad nebo pravděpodobnost rizika.

-          Akceptace: Navržené opatření se provede v případě, že riziko nastane.

Navržená opatření mohou být následujících typů: Havarijní plány (co dělat když riziko nastane), Alternativní strategie (jak rizikům předcházet), Rezervy (opatření která mají mírnit rizika finanční a časová), Obstarávání (rizikové činnosti lze předat zkušenějšímu externímu zpracovateli, Pojištění (pojistné smlouvy)

Inspekce a revize

-          Inspekce je formální metoda týmového přezkoumání podle přísných pravidel (příprava -> vlastní inspekce -> zpráva)

-          Minimální inspekční tým má tři osoby (max. 7) - autor, čtenář a moderátor/zapisovatel (všichni jsou současně inspektory).

-          Autor musí být vždy přítomen a nesmí zastávat žádnou jinou roli (s výjimkou inspektora).

Role:

-          autor - osoba, která je autorem produktu a je zodpovědná za změny řešící nalezené problémy

-          moderátor - osoba, která zajištuje průběh inspekce podle připraveného plánu

-          čtenář - osoba, která překládá produkt k inspekci

-          zapisovatel - osoba, která zaznamenává indikované chyby a spolupracuje s moderátorem na přípravě zprávy o inspekci

-          inspektor - osoba, která se v předkládaném produktu snaží nalézt chyby

Průběh inspekce - Příprava začíná krátkou schůzkou, kde jsou účastníci inspekce seznámeni s problematikou tak, aby byl všem jasný produkt a jejich role během inspekce. Potom následuje individuální studium podkladů a odkrývání problémů a otázek. Vlastní inspekce je setkání inspekčního týmu s realizátory, kde se probírají nalezené problémy a vyjasňují případné otázky. V poslední fázi se specifikují nalezené defekty a píše se zpráva z inspekce.