1

Inżynieria oprogramowania

wykład 5

Analiza i zarządzanie ryzykiem

2/22

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

3/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

4/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

5/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

6/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ń

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

8/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

9/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

10/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

11/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

12/22

Tablica szacowania zagrożeń
wg Boehma (c.d.)

możliwe zak.

prac przed term.

możliwe

oszczędności

łatwa pielęgnacja

brak ograniczenia

funkcjonalności

2

niewielkie opóźnienia lub prawie

niewidoczne straty finansowe

niewygoda i kłopoty nie związane z

działaniem programu

1

pomijalne

możliwe do

dotrzym. terminy

wystarczające

środki fin.

akcept. szybkość i

jakość pielęgnacji

niewielkie ogranicz.

funkcjonalności

2

opóźnienia lub straty finansowe małego

rzędu

degradacja jednej mniej istotnych

funkcjonalności

1

marginalne

możliwe

opóźnienia

braki fin., możliwość

przekr. budżetu

niewielkie opóźnienia

we wprow. modyfik.

istotne ogr.

funkcjonalności

2

opóźnienia i straty średniej wielkości

powoduje ograniczenie funkcjonalności,

które zmniejsza szansę sukcesu

1

krytyczne

niedotrzymanie

terminu oddania

znaczne straty fin.,

przekr. budżetu

opr. nie da się uruch.

lub pielęgnować

ogr. funkcj. lub całk.

unieruchum. syst.

2

niepowodzenie oznacza opóźnienia i

duże straty finansowe

niespełnienie wymagań oznacza klęskę

przedsięwzięcia

1

katastrofalne

harmonogram

koszt

pielęgnacja

funkcjonalność

składnik

kategoria

1- konsekw. wystąp. awarii i niewykrytych błędów ; 2- konsekw. niemożliwości osiąg. założonych celów

13/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)

14/22

Tabela zagrożeń



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

3

40%

niechęć użytkowników

1

5%

utrata źródeł finansowania

2

10%

zmiany osobowe w zespole

2

15%

brak doświadczenia pracowników

2

30%

zmiana wymagań klienta

2

20%

zmiana terminu wykonania

działanie

skutki

prawd.

zagrożenie

15/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

16/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

17/22

Zakres dopuszczalnego
ryzyka

punkt kontrolny

(czas, koszt)

przewidywane przekroczenie kosztów

p

rz

e

w

id

y

w

a

n

e

p

rz

e

k

ro

c

z

e

n

ie

h

a

rm

o

n

o

g

ra

m

u

przerwanie

projektu

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

18/22

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

19/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

20/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

21/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ę

22

Dziękuję za uwagę

źródło: „Praktyczne podejście do inżynierii oprogramowania”, R.S. Pressman