plik

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

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

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

niewielkie opóźnienia lub prawie

niewidoczne straty finansowe

niewygoda i kłopoty nie związane z

działaniem programu

pomijalne

możliwe do

dotrzym. terminy

wystarczające

środki fin.

akcept. szybkość i

jakość pielęgnacji

niewielkie ogranicz.

funkcjonalności

opóźnienia lub straty finansowe małego

rzędu

degradacja jednej mniej istotnych

funkcjonalności

marginalne

możliwe

opóźnienia

braki fin., możliwość

przekr. budżetu

niewielkie opóźnienia

we wprow. modyfik.

istotne ogr.

funkcjonalności

opóźnienia i straty średniej wielkości

powoduje ograniczenie funkcjonalności,

które zmniejsza szansę sukcesu

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.

niepowodzenie oznacza opóźnienia i

duże straty finansowe

niespełnienie wymagań oznacza klęskę

przedsięwzięcia

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

40%

niechęć użytkowników

utrata źródeł finansowania

10%

zmiany osobowe w zespole

15%

brak doświadczenia pracowników

30%

zmiana wymagań klienta

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

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ę