Kwalifikacja: INF.04 - Projektowanie, programowanie i testowanie aplikacji

Często spotyka się przekonanie, że analiza ryzyka jest obecna w każdym modelu cyklu życia projektu informatycznego, ale to nie do końca tak działa. W modelu kaskadowym, czyli tzw. waterfall, wszystko odbywa się etapami – analiza, projektowanie, implementacja i tak dalej, w sztywno określonej kolejności. Tu niestety nie ma miejsca na systematyczną analizę ryzyka na każdym etapie, bo cała koncepcja tego modelu polega na tym, że raz wykonane czynności trudno potem cofnąć lub poprawić, szczególnie gdy coś pójdzie nie tak. To, moim zdaniem, jest jeden z powodów, dla których model kaskadowy bywa krytykowany – brak elastyczności i mała odporność na niespodziewane problemy. Podobnie jest w modelu z prototypem – tam niby tworzy się szybkie makiety czy prototypy, ale głównym celem jest poznanie potrzeb użytkownika i szybkie zebranie informacji zwrotnej, a nie formalna analiza ryzyka. Ryzyko oczywiście można zidentyfikować przy okazji, ale nie jest to centralny punkt tego podejścia. Model Fry’ego to już zupełnie inna bajka – jest bardzo liniowy, nacisk kładzie raczej na dokumentację i ścisłe trzymanie się etapów, a nie na adaptacyjność czy zarządzanie niepewnością. Z mojego punktu widzenia, błędne wybranie któregoś z tych modeli jako tego, gdzie analizuje się ryzyko, wynika z przekonania, że wszędzie jest miejsce na refleksję nad zagrożeniami – niestety, tylko model spiralny wprost i metodycznie wpisuje analizę ryzyka w swój rdzeń. W innych przypadkach analiza ryzyka jeśli się pojawia, to głównie z inicjatywy zespołu, a nie jako zaplanowany, powtarzający się etap procesu. Warto o tym pamiętać przy wyborze metodyki do danego projektu – nie każda zapewni takie same mechanizmy zabezpieczające przed błędami i nieprzewidzianymi zdarzeniami.