Współczesny paradygmat metryk oprogramowania jest skoncentrowany na mierzeniu niewłaściwych wielkości i powinien być zmieniony w taki sposób, aby pokazywał obecność lub nieobecność głównych indykatorów ryzyka. Należą do nich:

- zła specyfikacja wymagań (warto zmienić te narzędzia zarządzania specyfikacją, które nie wspomagają oceny poprawności wymagań);

- błędy lub zaniechania w zakresie komunikacji z klientem (usprawnienie komunikacji zmniejsza ryzyko przyjęcia błędnej specyfikacji wymagań oraz ułatwia zarządzanie zmianą - odpowiednie zalecenia znalazły się w ISO 9001);

- brak planów lub błędne plany (wiele projektów nie ma planu realizacji; należy wprowadzić metryki pomagające monitorować wykorzystanie i modyfikację planów w trakcie cyklu rozwojowego);

- brak definicji procesu oraz standardów (problem jest rozwiązany w modelach CMM i standardach ISO);

- brak wsparcia ze strony kierownictwa (ryzyko uznane za podstawowy czynnik niepowodzenia TQM; potrzebne są metryki ukazujące stopień zaangażowania kierownictwa);

- zaniechanie walidacji specyfikacji wymagań (działanie powinno być uznane za etap w procesie wytwarzania);

- podporządkowanie czynników technicznych czynnikom politycznym (brak metryk);

- błędna alokacja zasobów (należy oprzeć decyzje na metodach analizy ekonomicznej);

- zmiany specyfikacji wymagań (monitorowanie zmian i reagowanie na nie powinny być wspomagane narzędziami zarządzania specyfikacją).

Nietrudno spostrzec, że większość czynników ryzyka leży po stronie problemów organizacyjnych i sfery zarządzania, w mniejszym stopniu dotycząc problemów technicznych. Spośród wymienionych indykatorów ryzyka jedynie pierwszy (zła specyfikacja wymagań) ma charakter techniczny. Zasoby wydatkowane na ograniczanie ryzyka technicznego będą zmarnowane, jeśli jednocześnie nie podejmie się prób zmniejszenia ryzyka leżącego w sferze zarządzania.

Wytwarzanie oprogramowania jest działalnością twórczą, która z trudnością poddaje się rygorom analizy formalnej. Osiągana w praktyce jakość prognoz i estymacji powoduje, że wyniki analiz ekonomicznych powinny być traktowane w kategoriach niepewności, zaś zarządzanie procesem wytwarzania oprogramowania powinno w znacznej mierze polegać na świadomym zarządzaniu niepewnością i ryzykiem.

Kluczem do zmniejszania rozczarowań i niepowodzeń jest podniesienie jakości zarządzania wytwarzaniem oprogramowania. Umiejętne stosowanie analizy ekonomicznej może stać się czynnikiem lepszego zarządzania. Z kolei lepsze zarządzanie ułatwi sensowne stosowanie analizy ekonomicznej.

--------------------------------------------------------------------------------

Prof. dr hab. Piotr Jędrzejowicz jest kierownikiem Katedry Systemów Informacyjnych w Wyższej Szkole Morskiej w Gdyni. Artykuł powstał na podstawie referatu "Wybrane narzędzia analizy ekonomicznej w inżynierii oprogra-mowania, czyli jak unikać niepewnoś- ci, błędnych decyzji i rozczarowań?", wygłoszonego w trakcie XIII Górskiej Szkoły PTI "Efektywność zastosowań systemów informatycznych".

* opracowano na podstawie książki W. A. Sherdena The Fortune Sellers. The big business of buying and selling predictions wydanej przez J. Wiley w 1998 r. oraz referatu The Certainty of Uncertainty wygłoszonego na konferencji The European Software Measurement Conference FESMA â98 w Antwerpii.