Przykład zastosowania metody analizy ryzyka PRisMa – „Testowanie i jakość oprogramowania. Modele, techniki, narzędzia”

Prezentujemy Państwu rozdział z książki „Testowanie i jakość oprogramowania. Modele, techniki, narzędzia”, przedstawiający praktyczne wykorzystanie metody PRisMa, służącej do analizy ryzyka w projektach IT.
„Testowanie i jakość oprogramowania. Modele, techniki, narzędzia” autorstwa Adama Romana to pierwszy w Polsce podręcznik kompleksowo opisujący nowoczesne podejście do testowania. Bogato ilustrowany przykładami w przystępny sposób prezentuje większość spotykanych w praktyce metod efektywnego testowania, zarządzania procesem testowym oraz zapewniania jakości oprogramowania. Polecany początkującym i zaawansowanym testerom, kierownikom testów, programistom stosującym testy jednostkowe, osobom usprawniającym proces testowy w organizacji oraz inżynierom jakości oprogramowania. Idealna pomoc dla przygotowujących się do egzaminów ISTQB na wszystkich poziomach zaawansowania.
Przykład: zastosowanie PRisMa do systemu ELROJ
Rozważmy ponownie system ELROJ – metodę stosujemy PRisMa do analizy ryzyka w tym systemie. W fazie Przygotowania zdefiniowano następujące czynniki. Dla wypływu: widoczne obszary (WidOb) oraz istotność z biznesowego punktu widzenia (IstBiz) z wagami odpowiednio 1,0 oraz 2,0. Dla prawdopodobieństwa: złożoność (Złoż) oraz nowe technologie i metody (NTech), ponieważ zespół będzie pierwszy raz pracował nad systemem komunikującym się ze sprzętem (ekrany na przystankach). Wagi dla tych czynników określono odpowiednio jako 1,0 oraz 2,0. Ustalono, że wykorzystana będzie skala Likerta (od 1 do 5). Wykorzystane zostaną standardowe, ogólne zasady oceniania zdefiniowane w PRisMa.
W fazie Planowania określono trzech interesariuszy: kierownika projektu, analityka biznesowego, oraz architekta systemu. Ponadto zidentyfikowano następujące ryzyka:
- Brak komunikacji systemu z ekranem.
- Niepoprawność wyświetlanych wyników na ekranie.
- Niewygodny interfejs użytkownika.
- Błędy w logice biznesowej systemu (zarządzanie liniami i kursami).
- Wolne działanie systemu.
Interesariuszom przypisano następujące czynniki:
- Kierownikowi projektu: widoczne obszary, istotność biznesowa, złożoność, nowe technologie.
- Analitykowi biznesowemu: widoczne obszary, istotność biznesowa.
- Architektowi systemu: złożoność, nowe technologie.
Analityk biznesowy nie powinien oceniać ryzyk pod kątem czynników technicznych (bo się na tym nie zna i jego ocena może być wypaczona). Podobnie architekt nie powinien wykorzystywać czynników biznesowych.
W fazie indywidualnego przygotowania wszyscy trzej członkowie zespołu dokonali analizy ryzyk, oceniając je na podstawie przypisanych im czynników. Wyniki są zebrane w tabelach 19.10–19.12.
Tabela 19.10. Szacowanie ryzyka przez kierownika projektu
Kierownik projektu |
Wpływ |
Prawdopodobieństwo |
||
Czynniki |
WidOb |
IstBiz |
Złoż |
NTech |
Wagi |
1,0 |
2,0 |
1,0 |
2,0 |
R1: brak komunikacji z ekranem |
4 |
5 |
1 |
5 |
R2: niepoprawna informacja na ekranie |
5 |
5 |
3 |
1 |
R3: niewygodny interfejs |
2 |
1 |
1 |
2 |
R4: błędy w logice biznesowej |
1 |
3 |
5 |
4 |
R5: wolne działanie systemu |
2 |
4 |
4 |
4 |
Tabela 19.11. Szacowanie ryzyka przez analityka biznesowego
Analityk biznesowy |
Wpływ |
Prawdopodobieństwo |
||
Czynniki |
WidOb |
IstBiz |
Złoż |
NTech |
Wagi |
1,0 |
2,0 |
1,0 |
2,0 |
R1: brak komunikacji z ekranem |
5 |
3 |
Te czynniki nie podlegają ocenie, gdyż nie zostały przypisane analitykowi biznesowemu |
|
R2: niepoprawna informacja na ekranie |
5 |
5 |
||
R3: niewygodny interfejs |
1 |
1 |
||
R4: błędy w logice biznesowej |
3 |
2 |
||
R5: wolne działanie systemu |
4 |
3 |
Tabela 19.12. Szacowanie ryzyka przez architekta systemu
Architekt systemu |
Wpływ |
Prawdopodobieństwo |
||
Czynniki |
WidOb |
IstBiz |
Złoż |
NTech |
Wagi |
1,0 |
2.,0 |
1,0 |
2,0 |
R1: brak komunikacji z ekranem |
Te czynniki nie podlegają ocenie, gdyż nie zostały przypisane architektowi systemu |
3 |
5 |
|
R2: niepoprawna informacja na ekranie |
5 |
1 |
||
R3: niewygodny interfejs |
1 |
1 |
||
R4: błędy w logice biznesowej |
4 |
4 |
||
R5: wolne działanie systemu |
1 |
3 |
W kroku Przetwarzanie indywidualnych ocen kierownik testów uśrednia oceny, otrzymując wynik przedstawiony w tabeli 19.13.
Tabela 19.13. Uśrednione oceny
Uśrednione oceny |
Wpływ |
Prawdopodobieństwo |
||
Czynniki |
WidOb |
IstBiz |
Złoż |
NTech |
Wagi |
1,0 |
2, |
1,0 |
2,0 |
R1: brak komunikacji z ekranem |
4,5 |
4,0 |
2,0 |
5,0 |
R2: niepoprawna informacja na ekranie |
5,0 |
5,0 |
4,0 |
1,0 |
R3: niewygodny interfejs |
1,5 |
1,0 |
1,0 |
1,5 |
R4: błędy w logice biznesowej |
2,0 |
2,5 |
4,5 |
4,0 |
R5: wolne działanie systemu |
3,0 |
3,5 |
2,5 |
3,5 |
Uśrednione oceny są mnożone przez odpowiadające im czynniki. W wyniku otrzymujemy ważoną ocenę. Rezultat przedstawiony jest w tabeli 19.14.
Tabela 19.14. Ważona ocena ryzyk produktowych
Ryzyko |
Wpływ |
Prawdopodobieństwo |
R1: brak komunikacji z ekranem |
4,5+8,0=12,5 |
2,0+10,0=12,0 |
R2: niepoprawna informacja na ekranie |
5,0+10,0=15,0 |
4,0+2,0=6,0 |
R3: niewygodny interfejs |
1,5+2,0=3.5 |
1,0+3,0=4,0 |
R4: Błędy w logice biznesowej |
2,0+5,0=7,0 |
4,5+8,0=12,5 |
R5: Wolne działanie systemu |
3,0+7,0=10,0 |
2,5+7,0=9,5 |
Każde z ryzyk jest nanoszone na macierz ryzyka. W wyniku otrzymujemy macierz przedstawioną na rys. 19.17. Współrzędne każdego z ryzyk odpowiadają wartościom jego wpływu oraz prawdopodobieństwa. Wartości minimalne i maksymalne obu osi są wyznaczane na podstawie teoretycznych wartości skrajnych ocen, jakie można uzyskać. Minimalna ocena wpływu to:
natomiast maksymalna to:
Takie same wartości skrajne przyjmuje skala dla prawdopodobieństwa. Środkową wartością na obu skalach jest 9, zatem punkt o współrzędnych stanowi środek macierzy.
Rysunek 19.17. Macierz ryzyka produktowego dla systemu ELROJ
W fazie Spotkanie uzgadniające, należy ustalić przynależność do odpowiedniego kwadrantu ryzyka R5 (wolne działanie systemu), które jako jedyne znalazło się w obszarze koła. Zespół ustalił, że ze względu na niedużą liczbę przetwarzanych danych oraz dobrą przepustowość sieci ryzyko to cechować się będzie niskim prawdopodobieństwem. W rezultacie ryzyko przechodzi z kwadrantu II (wysoki wpływ, wysokie prawdopodobieństwo) do kwadrantu IV (wysoki wpływ, niskie prawdopodobieństwo).
W ostatniej fazie (zdefiniowanie zróżnicowanych podejść testowania opartego na ryzyku) są ustalane metody łagodzenia ryzyka. W naszym przypadku będzie to ustalenie odpowiednich metod testowania. Wyniki tej fazy są przedstawione w tabeli 19.15.
Tabela 19.15. Metody łagodzenia ryzyka dla systemu ELROJ
Ryzyko |
Kwadrant |
Wpływ |
Prawdopodobieństwo |
Metody łagodzenia |
R1 |
II |
wysoki |
wysokie |
Wczesny prototyp systemu sprawdzający połączenie z ekranem |
R2 |
IV |
wysoki |
niskie |
Testowanie białoskrzynkowe (kryterium MC/DC) oraz inspekcje kodu |
R5 |
IV |
wysoki |
niskie |
Testy wydajnościowe, inspekcja projektu bazy danych |
R4 |
I |
niski |
wysokie |
Testowanie eksploracyjne oraz testowanie w oparciu o przypadki użycia |
R3 |
III |
niski |
niskie |
Brak (poziom znikomy, nie ma potrzeby alokacji zasobów na testowanie tego ryzyka) |
W wyniku przeprowadzenia analizy ryzyka metodą PRisMa mamy zidentyfikowane ryzyka, określony ich typ oraz dobrze zdefiniowane akcje łagodzenia tych ryzyk. Przeprowadzenie takiego procesu pozwala w olbrzymim stopniu zredukować poziom ryzyka w systemie. Już sam fakt identyfikacji ryzyk (stworzenie macierzy ryzyka) jest dużym sukcesem, a i tak wciąż – jeśli idzie o analizę ryzyka – wiele firm nie dochodzi nawet do tego etapu!
„Testowanie i jakość oprogramowania. Modele, techniki, narzędzia” pojawi się w księgarniach już w maju!