Inżynieria oprogramowania
wykład 5
Analiza i zarzÄ…dzanie ryzykiem
1
Przyczyny występowania ryzyka w
przedsięwzięciu informatycznym
ryzyko dotyczy zdarzeń, których wystąpienie będzie
miało negatywny wpływ na realizowany projekt
występuje zarówno po stronie klienta jak i producenta
dotyczy wydarzeń, działań w przyszłości, których nie
umiemy (nie można) przewidzieć
związane jest ze zmianami w przedsięwzięciu: możliwość
zmiany wymagań przez klienta, zmiana środowiska
aplikacji, zmiana technologii, zmiana sytuacji na
potencjalnym rynku produktu
istnienie wielu możliwości powoduje konieczność wyboru
(np. technologii, funkcjonalności, pracowników, metody
zarządzania jakością)  nie wiadomo który wybór będzie
korzystny niepewność wyboru
2/22
Podział ryzyka
ryzyko po stronie klienta (biznesowe)
Ä„ð przyczyny wzrost kosztu produktu, przekroczenie terminu,
działanie inne niż zakładane, brak produktu
Ä„ð skutki brak możliwość funkcjonowania przedsiÄ™biorstwa,
zwiększenie kosztów działalności, pogorszenie pozycji
rynkowej
Ä„ð zapobieganie przygotowanie alternatywnych scenariuszy
ryzyko wykonawcy (projektowe)
Ä„ð uniemożliwienie wykonania produktu o okreÅ›lonych
właściwościach w określonym czasie, bez przekroczenia
kosztów
Ä„ð zapobieganie  identyfikacja i kontrola zagrożeÅ„, plany
awaryjne
3/22
Główne strategie w zarządzaniu
ryzykiem
strategia reakcji  szkoła zarządzania ryzykiem
Indiany Jonesa *, brak analizy zagrożenia i planu
ratunkowego, rozwiÄ…zanie problemu opracowywane i
wdrażane  na bieżąco , strategia ogólnie dość
ryzykowna
strategia akcji określenie potencjalnych zagrożeń,
prawdopodobieństwa ich wystąpienia oraz rozmiaru
skutków, opracowanie planu kontroli zagrożeń i działań
awaryjnych, początek działań dużo wcześniej niż
pojawienie się problemów, strategia bardziej rozsądna i
zalecana
* R. Thomsett: The Indiana Jones school of risk management, American Programmer, t. 5, nr 7, 1992
4/22
Cechy zagrożeń*
niepewność (przyczyna) zagrożenie może
wystąpić ale nie musi, nie można dokładnie
przewidzieć rzeczywistych skutków
straty (skutek) zwiększenie kosztów,
niedotrzymanie terminów, konieczność
zaangażowana dodatkowych środków i inne
komplikacje oraz niepożądane efekty
* R. P. Higuera: Team risk management , CrossTalk, 1995
5/22
Rodzaje zagrożeń
projektowe utrudniają realizację przedsięwzięcia,
zwłaszcza w zakresie terminowości wykonania i budżetu, a
także powodują utrudnienia w gospodarowaniu zasobami
(w tym ludzkimi), czynnikami ryzyka są również przyczyny
niepewności prognozowania (wielkość, złożoność,
niepewność strukturalna  niedokładny opis wymagań,
podział na moduły, typ przetwarzanych informacji
techniczne wpływają głównie na jakość produktu i
terminowość procesu wytwarzania, oznaczają wystąpienie
trudności, które nie wydawały się tak skomplikowane na
etapie planowania i projektowania, oznaczają trudności z
projektem i jego implementacją, interfejsem, pielęgnacją
programu, powodujÄ… je nowe technologie i niesprawdzone
rozwiązania, niedokładność specyfikacji
ekonomiczne utrudniajÄ… sukces rynkowy produktu,
znanych jest 5 głównych zagrożeń
6/22
Zagrożenia ekonomiczne
ryzyko marketingowe dobry produkt ale brak
zainteresowania nim
ryzyko strategiczne niezgodność produktu z
ogólnym profilem firmy
nieumiejętna sprzedaż produktu
ryzyko zarzÄ…dzania spadek zainteresowania
produktem na skutek zmiany strategii zarzÄ…du
lub zmiany zarzÄ…du firmy
ryzyko budżetowe zmniejszenie budżetu
produktu lub zasobów ludzkich
7/22
Podział zagrożeń wg Charette a*
znane możliwe do identyfikacji na podstawie m. in.
analizy planu przedsięwzięcia oraz środowiska
powstawania produktu ( niemożliwy do dotrzymania termin
wykonania, brak udokumentowanej specyfikacji wymagań,
brak opisu zakresu działania produktu, niedoskonałość
środowiska tworzenia produktu
przewidywalne możliwe do określenia na podstawie
porównania z poprzednimi przedsięwzięciami (zmiany w
zespole pracowników, niepoprawna komunikacja z
klientem, rozproszenie zespołu spowodowane
wykonywaniem obowiązków w ramach pielęgnacji
produktu
nieprzewidywalne zdarzenia o charakterze losowym
* R. N. Charette: Software engineering risk analysis and management , McGraw-Hill/Intertext, 1989
8/22
Identyfikowanie zagrożeń 
lista kontrolna zagrożeń*
wielkość produktu jako przyczyna zagrożeń
uwarunkowania handlowe narzucane przez
kierownictwo oraz rynek
cechy klienta jakość komunikacji, wiedza i
doświadczenia (pomocne w specyfikacji wymagań)
dokładność zdefiniowania i przestrzeganie zasad
procesu wytwórczego
środowisko tworzenia dostępność i jakość narzędzi do
tworzenia produktu
technologia cechy programu na tle stosowanej
technologii, nowe technologie w procesie wytwórczym
cechy zespołu wielkość, doświadczenie, umiejętności
* w literaturze istnieje wiele przykładowych list kontrolnych, bardziej lub mniej szczegółowych
9/22
Składniki ryzyka*
związane z funkcjonalnością niepewność
spełnienia wymagań i użyteczność programu
związane z kosztem możliwość
przekroczenia budżetu
związane z pielęgnacją niepewność
możliwości poprawiania, rozszerzania i
dostosowywania programu
związane z harmonogramem niepewność
dotrzymania terminu produkcji
* B. Boehm: Software risk management , IEEE Computer Society Press, 1989
10/22
ZarzÄ…dzanie ryzykiem
identyfikacja czynników ryzyka / zagrożeń
kontrola ryzyka obejmujÄ…ca monitorowanie
czynników ryzyka / zagrożeń
określenie strategii i procedur na wypadek
zaistnienia czynników ryzyka w celu
ograniczenia skutków
11/22
Tablica szacowania zagrożeń
wg Boehma (c.d.)
składnik
funkcjonalność pielęgnacja koszt harmonogram
kategoria
niespełnienie wymagań oznacza klęskę niepowodzenie oznacza opóz
nienia i
katastrofalne 1
przedsięwzięcia duże straty finansowe
ogr. funkcj. lub całk. opr. nie da się uruch. znaczne straty fin., niedotrzymanie
2
unieruchum. syst. lub pielęgnować przekr. budżetu terminu oddania
powoduje ograniczenie funkcjonalności, opóz
nienia i straty średniej wielkości
krytyczne 1
które zmniejsza szansę sukcesu
istotne ogr. niewielkie opóz
nienia braki fin., możliwość możliwe
2
funkcjonalności we wprow. modyfik. przekr. budżetu opóz
nienia
degradacja jednej mniej istotnych opóz
nienia lub straty finansowe małego
marginalne 1
funkcjonalności rzędu
niewielkie ogranicz. akcept. szybkość i wystarczające możliwe do
2
funkcjonalności jakość pielęgnacji środki fin. dotrzym. terminy
niewygoda i kłopoty nie związane z niewielkie opóz
nienia lub prawie
pomijalne 1
działaniem programu niewidoczne straty finansowe
brak ograniczenia łatwa pielęgnacja możliwe możliwe zak.
2
funkcjonalności oszczędności prac przed term.
1- konsekw. wystąp. awarii i niewykrytych błędów ; 2- konsekw. niemożliwości osiąg. założonych celów
12/22
Przewidywanie ryzyka -
czynności
identyfikacja zagrożeń
ustalanie prawdopodobieństwa wystąpienia
zagrożenia
oznaczenie skutków
oszacowanie rozmiaru skutków wystąpienia
zagrożenia i wpływ na realizację
przedsięwzięcia
ocena poprawności przewidywań
Do analizy zagrożeń sporządza się tzw. tabelę zagrożeń, w
której umieszczane są szczegóły związane z danym typem
zagrożenia (prawdopodobieństwo, straty)
13/22
Tabela zagrożeń
zagrożenie prawd. skutki działanie
zmiana terminu wykonania 20% 2
zmiana wymagań klienta 30% 2
brak doświadczenia pracowników 15% 2
zmiany osobowe w zespole 10% 2
utrata z
ródeł finansowania 5% 1
niechęć użytkowników 40% 3
po wypełnieniu tabela jest sortowana wg prawdopodobieństwa oraz
wielkości skutków
u góry tabeli znajdują się zagrożenia o dużym prawd. wystąpienia oraz
sporych potencjalnych stratach (1. etap)
zagrożenia o bardzo małym prawdopodobieństwie nie są dokładnie
analizowane
zagrożenia o poważnych skutkach i średnim lub dużym prawd. oraz
zagrożenia o małych skutkach ale dużym prawd. podlegają dalszej analizie
14/22
Szacowanie skutków zagrożeń
obliczenie średniego prawdopodobieństwa możliwości
wystąpienia zagrożenia dla każdego rodzaju ryzyka
ustalenie wpływu zagrożenia na składniki ryzyka (wg
tablicy szacowania zagrożeń)
obliczenia podatności na zagrożenie RE*
RE = P " C
gdzie: P - prawdopodobieństwo, C - koszt strat poniesionych w wyniku
pojawienia się zagrożenia
suma podatności obliczonych dla wszystkich zagrożeń może być
uwzględniona w szacowaniu kosztów przedsięwzięcia
składniki tablicy zagrożeń powinny być stale analizowane i w miarę
potrzeb uaktualniane (dodawane nowe, usuwane niepotrzebne,
istniejące ewentualnie przesuwane w tabeli w górę lub dół)
* E. M. Hall: Managing risk: methods for software systems development , Addison-Wesley, 1988
15/22
Ocena ryzyka
prowadzona na podstawie informacji o zagrożeniach
uporządkowanych w postaci trójek: typ,
prawdopodobieństwo, skutki
w dalszym etapie procesu zarządzania ryzykiem należy
określić tzw. zakres dopuszczalnego ryzyka, najczęściej
oddzielnie dla poszczególnych aspektów przedsięwzięcia
programistycznego (funkcjonalność, pielęgnacja, koszty,
harmonogram  tablica szacowania zagrożeń)
po przekroczeniu zakresu dopuszczalnego ryzyka nawet
w jednym aspekcie, prace nad przedsięwzięciem zostaną
przerwane
ustalenie zakresu dopuszczalnego ryzyka zwiÄ…zane jest
z określeniem tzw. punktu kontrolnego
16/22
Zakres dopuszczalnego
ryzyka
punkt kontrolny
(czas, koszt)
przerwanie
projektu
przewidywane przekroczenie kosztów
w rzeczywistości wyznacza się na podstawie wielu punktów kontrolnych dla
różnych aspektów niepewności obszar, w którym następuje przerwanie projektu
17/22
harmonogramu
przewidywane przekroczenie
Strategia postępowania z
zagrożeniami
w miarę możliwości unikanie zagrożeń, szczególnie w
 strategii akcji
monitorowanie zagrożeń wraz z postępem procesu
wytwórczego, prawdopodobieństwo wystąpienia
zagrożenia może zwiększyć się lub zmniejszyć w
zależności od różnych czynników
kontrolowanie zagrożeń, sprawdzanie czy zastosowane
środki zapobiegawcze przynoszą efekty
tworzenie planów awaryjnych na wypadek faktycznego
zaistnienia zagrożenia
18/22
Przykład planu działania
awaryjnego
zagrożenie: rotacja pracowników
plan awaryjny:
Ä„ð okreÅ›lenie standardów tworzenia dokumentacji
Ä„ð zaplanowanie systemu zastÄ™pstw
Ä„ð dokÅ‚adne informacje o pracach wykonywanych przez
odchodzących pracowników
Ä„ð plan chwilowego przesuniÄ™cia zasobów, zmiany
harmonogramu wykonywanych prac w celu
ułatwienia wdrożenia się nowym członkom zespołu
Ä„ð plan przekazania obowiÄ…zków przez odchodzÄ…cych
osobom zastępującym
19/22
Zasada Pareto w zarzÄ…dzaniu
ryzykiem
zapobieganie, monitorowanie i kontrolowanie zagrożeń
zwiększa koszty przedsięwzięcia
należy dokonać rachunku zysków i strat i sprawdzić czy
koszty działań zapobiegawczych nie przekraczają
zysków uzyskanych poprzez unikanie zagrożeń
zasada 80-20 Pareto:
Ä„ð 80% ogólnego ryzyka zwiÄ…zanego z przedsiÄ™wziÄ™ciem jest
spowodowanych jednym z 20% najważniejszych
zidentyfikowanych zagrożeń
Ä„ð czÄ™sto zagrożenia spoza 20% najważniejszych jest pomijanych
20/22
Analiza bezpieczeństwa i
ryzyka awarii oprogramowania
wchodzi w zakres procesu zapewnienia jakości
obejmuje działania:
Ä„ð identyfikowanie zagrożeÅ„
Ä„ð szacowanie zagrożeÅ„ o negatywnym wpÅ‚ywie na
oprogramowanie i mogących spowodować jego
awariÄ™
Ä„ð w przypadku wczesnej identyfikacji takich zagrożeÅ„
można dokonać w projekcie odpowiednich zmian,
które zminimalizują występowanie tych zagrożeń lub
pozwolÄ… na lepszÄ… ich kontrolÄ™
21/22
Dziękuję za uwagę
z
ródło:  Praktyczne podejście do inżynierii oprogramowania , R.S. Pressman
22