Ryzyko okiełznane

Wśród informatyków znane są powiedzenia - "Jeśli nie dzieje się nic złego (w domyśle: z projektem informatycznym), to na pewno stanie się wkrótce" (Prawo Murphy'ego) oraz "Jeśli nie analizujesz ryzyka, to automatycznie trafiasz na kłopoty".

Wśród informatyków znane są powiedzenia - "Jeśli nie dzieje się nic złego (w domyśle: z projektem informatycznym), to na pewno stanie się wkrótce" (Prawo Murphy'ego) oraz "Jeśli nie analizujesz ryzyka, to automatycznie trafiasz na kłopoty".

Nie ma jednoznacznej definicji ryzyka. Jego stopień, związany z wytwarzaniem projektów oprogramowania, określa się wg osiągniętych wyników projektowania, a mianowicie:

1. Przerwanie realizacji projektu lub fiasko podjętego przedsięwzięcia.

2. Wytworzenie oprogramowania nie spełniającego pewnych wymagań funkcjonalnych czy jakościowych, np.:

- przedłużenie czasu realizacji, wynikającego z założonego harmonogramu

- zwiększenie kosztów projektu w porównaniu do planowanych kosztów

- niezbyt wysoka użyteczność, zawodność funkcjonowania lub pominięcie problemów bezpieczeństwa.

3. Ujawnienie pewnych wad oprogramowania podczas jego eksploatacji.

Wymienione przypadki mają różny wpływ na wykonawcę i użytkownika. Na ogół powodują one duże straty ekonomiczne. Istotne jest więc poznanie wszystkich cech ryzyka, dotyczącego wytwarzanego oprogramowania.

Źródła ryzyka są różnorodne. Najczęstsze to:

1. Próba realizacji problemu, który nie był jeszcze dokładnie teoretycznie zbadany.

2. Wykorzystanie niewłaściwej metodologii bądź technologii informatycznej.

3. Pojawienie się problemów ludzkich (np. choroba) - nie przewidywanych podczas planowania, jak również niewłaściwa organizacja zespołu lub jego nieodpowiednie kompetencje.

4. Nieprzewidywalne zmiany w otoczeniu, jak załamanie rynku bądź źródeł finansowania czy kłopoty kooperacyjne.

5. Błędy merytoryczne popełnione przy projektowaniu i realizowaniu projektu.

W praktyce przy realizowaniu dużych projektów informatycznych trudno jest wyeliminować wszystkie źródła ryzyka. Dlatego też istotne jest stałe monitorowanie realizacji projektu, jak też odpowiednie zarządzanie ryzykiem, czyli podejmowanie właściwych decyzji korygujących. W przypadku eksploatacji systemu konieczna staje się nie tyle właściwa jego pielęgnacja, ale rozbudowa o dodatkowe funkcje czy zabezpieczenia. Ograniczmy się jedynie do problematyki ryzyka związanej z wytwarzaniem systemu. Warto jednak zaznaczyć, że mniejsze ryzyko wytwarzania projektu nie musi oznaczać zwiększenia ryzyka jego funkcjonowania.

Zarządzanie ryzykiem projektowania

Jest to problem bardzo złożony, składający się z wielu wyjątków, choć w literaturze często analizuje się ryzyko, koncentrując się jedynie na wybranych parametrach, takich jak czas realizacji czy koszty wytwarzania projektu. Problemy zarządzania ryzykiem można przedstawić za pomocą czteropoziomowego drzewa ryzyka.

Poziom pierwszy charakteryzuje w pełni sposób zarządzania, poziom drugi określa podstawowe wymagania, umożliwiające realizację zarządzania. Poziom następny definiuje operacje do wykonania, a ostatni konkretne przedsięwzięcia związane z tymi operacjami lub konkretnie wykorzystywane metody. Takie podejście nie tylko systematyzuje problematykę, ale również pozwala je odnieść do poszczególnych etapów projektowania, jak i też modeli projektowania.

Szacowanie ryzyka

W celu podania metody szacowania ryzyka wyróżniamy dwa podstawowe pojęcia, a mianowicie zagrożenie oraz straty związane z wystąpieniem tego zagrożenia. Przez Z oznaczymy zbiór rozpatrywanych zagrożeń, zaś przez S zbiór strat, odpowiadających poszczególnym zagrożeniom. Tak więc: dla z Z Sz S, Sz R+, gdzie R+ jest zbiorem dodatnich liczb rzeczywistych, opisujących straty np. jako dodatkowe kwoty na zniwelowanie skutków wystąpienia tego zagrożenia. Niech Pz oznacza prawdopodobieństwo (szansę) pojawienia się zagrożenia z Z. Wówczas ryzyko dotyczące zagrożenia z można opisać następującym wzorem:

rz = Pz x Sz(1)

Natomiast ryzyko wytworzenia oprogramowania - R określić możemy następująco:

R = rz(2)/z Z

Ponieważ Pz = 1, zatem R < S = Sz, gdzie S jest

sumaryczną kwotą związaną z niwelowaniem możliwych zagrożeń. Możemy również zdefiniować ryzyko znormalizowane r {0,1} w następujący sposób

r = (3)

Przyjęta definicja (patrz wzory 1 i 2) narzuca systematyczną metodę oceny ryzyka. Metoda ta wymaga sporządzenia i wypełnienia tabeli przedstawionej jako Tabela 1. Często jest ona sporządzana na podstawie różnego typu kwestionariuszy i doświadczenia projektantów (4).

Nie zawsze możliwe jest jednak scharakteryzowanie poszczególnych zagrożeń, a co więcej wyznaczenie prawdopodobieństw ich występowania. Dlatego też często nie podaje się konkretnych wartości, a szacuje się tylko stopień ryzyka jako niski (N), średni (S) bądź wysoki (W). Zakłada się przy tym, że dane zagrożenie jest mało prawdopodobne (M), gdy prawdopodobieństwo jego wystąpienia jest mniejsze od 0,3. Dane zagrożenie z jest prawdopodobne, gdy 0,3 < Pz 0,7 bądź wysoce prawdopodobne, gdy Pz > 0,7. Podobnie wyróżnia się trzy kategorie strat: marginalne (Ma), krytyczne (Kr) oraz katastroficzne (Ka) Nie podaje się tutaj typowych wartości, odpowiadających poszczególnym kategoriom strat, gdyż znacznie zależą one od ponoszonych nakładów w odniesieniu do kosztów utrzymania firmy, wykonującej oprogramowanie. Jako straty uwzględnić można również czas realizacji projektu. Przy takiej gradacji parametrów oszacowanie wielkości ryzyka podaje tabela 2.

Szczegółowa analiza ryzyka wymaga podania konkretnego modelu analizy ryzyka. Dotychczas wykorzystywane są następujące podejścia:

1. Modele sieciowe typu PERT, zorientowane na szacunek czasu realizacji.

2. Drzewa decyzji i zdarzeń pomocne przy ocenie prawdopodobieństw wystąpienia zagrożenia.

3. Cząsteczkowe modelowanie - służące do analizy sytuacji, których nie da się łatwo przewidzieć.

4. Statystyczny szacunek i wyznaczanie korelacji parametrów w celu selekcji zbioru parametrów najbardziej reprezentacyjnych. Na bazie tych modeli wyraża się ryzyko R jako funkcje różnych parametrów i analizuje ich wpływ na wartość R.

Trochę heurystyki

Podstawowym problemem jest właśnie dobór parametrów sterujących, poprzez które zapewniamy zmniejszenie ryzyka projektowania. Oznaczmy przez R zmianę ryzyka, tzn.

R = Rprzed - Rpo (gdzie Rprzed jest ryzykiem istniejącym przed podjęciem decyzji zaradczych, zaś Rpo ryzykiem nadal istniejącym po ich wykonaniu. Niech K - oznacza koszt redukcji ryzyka o R. Wówczas zmniejszenie ryzyka przypadające na jednostkę kosztu (tzw. Risk leverage) wyniesie:

LR = (4)

Wzór ten określa zasadność zmniejszenia ryzyka, gdzie koszty K mogą być odnoszone do kosztów strat S. Porównaj wzory (2) i (4). W zależności od wartości LR, możemy podejmować trzy podstawowe decyzje:

1. Unikanie ryzyka, gdy R = Rdopuszczalne zaś LR = 0.

2. Przenoszenie ryzyka z jednych elementów systemu na inne, np. ze sprzętu na oprogramowanie lub z oprogramowania na operatora, R = const, LR R -> min.

3. Zmniejszenie ryzyka w całym procesie projektowania R -> min oraz LR < LR dopuszczalne.

Tabela 3 podaje główne techniki zarządzania ryzykiem dla typowych czynników prowadzących do unikania lub zmniejszania ryzyka. Są one bardzo ogólne i w praktyce muszą być zastąpione przez mające istotny wpływ na ryzyko konkretne ilościowe parametry.

Mając na uwadze podstawowe czynniki ryzyka, jak i techniki zarządzania ryzykiem, można opracować konkretną metodę minimalizowania ryzyka. Na rys. 2 przedstawiono schemat operacyjny takiej procedury. Jej działanie przedstawiamy za pomocą prostego przykładu minimalizacji ryzyka kosztów.

Załóżmy, że rozpatrujemy oprogramowanie systemu mikroprocesorowego złożonego z 50-60 tys. źródłowych instrukcji (DL). Uwzględniając takie parametry, jak niezawodność, złożoność, wydajność komputera, metodologię projektowania oraz wykorzystywaną metodologię, szacujemy koszt projektu KP zgodnie ze wzorem (metoda COCOMO):

KP = 2.8 DL 1.20 x wsp

gdzie: KP oznacza liczbę osobomiesięcy, DL - rozmiar programu, wsp - współczynnik korekcji uwzględniający wymienione parametry. Dla nich określa się współczynnik wsp z odpowiednich tabel. Niech np. wsp=1.17 (wariant optymistyczny) i wsp=1.41 (wariant pesymistyczny). Dla takich parametrów otrzymujemy KPop = 358 wymaganych osobomiesięcy realizacji projektu (wariant optymistyczny), zaś KPpes = 539 (wariant pesymistyczny). Przedział ten przy dalszej analizie może być rozdzielony na podprzedziały, odpowiadające różnym stopniom ryzyka (N, S, W). Tak więc analiza różnych wariantów jest podstawą do zminimalizowania ryzyka.

Konieczne należy wykorzystać odpowiednie narzędzia, np. COCOMO do definicji modelu ryzyka i oszacowania kosztów oprogramowania oraz np. RISCOMO do przeprowadzenia analizy ryzyka i wyboru odpowiedniego wariantu. Istotne jest poza tym uwzględnienie pewnych typowych zjawisk informatycznych, które towarzyszą procesowi projektowania. Przykładem takich zasad może być rozkład Pareto 80-20.

Wnioski końcowe

Wśród informatyków znane są powiedzenia - "Jeśli nie dzieje się nic złego (w domyśle z projektem informatycznym), to na pewno stanie się to wkrótce" (Prawo Murphy'ego), oraz "Jeśli nie analizujesz ryzyka, to automatycznie trafiasz na kłopoty".

Niech to będzie przestrogą dla projektantów i użytkowników systemów informatycznych. Analiza ryzyka jest więc sprawą konieczną, choć nie jest łatwa i dlatego wymaga systematycznego podejścia. Zasygnalizowałem jedno z nich. Wynika ono także z moich doświadczeń przy kierowaniu dużymi projektami. W czasie ich realizacji wystąpiły podane wyżej zagrożenia, w tym również zmiana zespołu w 30-50% (odejście pracowników do innej pracy), jak również wykrycie istotnych ograniczeń w zastosowaniu niektórych narzędzi (okazały się gorsze niż oczekiwano). Dodatkową trudnością było zintegrowanie zespołu o międzynarodowym składzie, gdzie którego członkowie charakteryzowali się różną mentalnością i innymi przyzwyczajeniami. Mimo tych trudności, dzięki zastosowaniu sugerowanej metody sterowania ryzykiem, projekty ukończono. Wykorzystano przy tym metodologię projektowania mieszanego, łączącego własności podejścia kaskadowego i spiralnego.

Profesor Henryk Krawczyk jest pracownikiem Katedry Architektury Systemów Komputerowych Wydziału Elektroniki, Telekomunikacji i Informatyki na Politechnice Gdańskiej.

Tekst został wygłoszony podczas II Konferencji "Informatyka na wyższych uczelniach dla gospodarki narodowej" Gdańsk 22-24 listopada br. Tytuł i śródtytuły pochodzą od redakcji.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200