Błąd pomiaru

Błędy pomiarów, błędy modeli oraz opisane wcześniej zależności sprawiają, że na etapie przetargu menedżerowie firm wytwarzających oprogramowanie mogą co najwyżej opierać się na pewnych "przedziałach ufności", w których prawdopodobnie zmieszczą się prognozowane wielkości nakładów i czasu realizacji. Szerokość takiego przedziału dobrze określa zakres ryzyka związanego z projektem. Im szerszy przedział, tym bardziej ryzykowny jest projekt. Wąski przedział wskazuje na dobrze zdefiniowany projekt. Dolna granica przedziału pozwoli zidentyfikować ryzyko związane ze stworzeniem zbyt niskiej oferty cenowej.

Klienci rzadko godzą się na cenę, która w pełni przenosi na zleceniodawcę ryzyko firmy wytwarzającej oprogramowanie. Stąd proponowaną strategią jest wewnętrzne ubezpieczanie ryzyka związanego z błędami estymacji.

Czynniki niepowodzenia

Niepewność, błędy szacowania oraz złożoność procesu i produktu są czynnikami utrudniającymi prowadzenie analizy ekonomicznej, a w konsekwencji podejmowanie racjonalnych decyzji w inżynierii oprogramowania. Nie są to jednak czynniki decydujące o skali błędnych decyzji i rozczarowań charakterystycznych dla omawianego sektora. Jak dowodzą liczne badania empiryczne, znacznie większy wpływ wywierają złe zarządzanie oraz inne błędy ludzkie.

Cykl rozwojowy dużych systemów informacyjnych często trwa kilka lat. W tym czasie zamawiający okresowo przekazuje na rzecz wykonawcy pewne sumy określone w umowie. Najczęściej testy akceptacyjne są przeprowadzane na końcu cyklu, dlatego przydatność oprogramowania w aspekcie potrzeb użytkownika jest niewiadomą w momencie, w którym większa część kosztów została już poniesiona przez zamawiającego. Wykonawca przekazuje zleceniodawcy informacje, które mają go przekonać, że zlecenie jest realizowane zgodnie z harmonogramem oraz w ramach uzgodnionego budżetu. Informacje te, w formie raportów lub innych dokumentów, obejmują zestawienia wydatków (planowanych i rzeczywistych), wykresy Gantta, sieci PERT, potwierdzenie stosowania najlepszych praktyk, estymowane punkty funkcyjne (FP), liczby wierszy kodu, liczby spełnionych wymagań, liczby błędów, stopień zgodności z modelem CMM (Capability Maturity Model) oraz modelami ISO.

Wszystkie te informacje mają demonstrować, że ryzyko niedostarczenia produktu i niezgodności ze specyfikacją wymagań jest niewielkie. Opisywana praktyka jest klinicznym przypadkiem koncentrowania się na technikach i mechanizmach zamiast na zasadach, na narzędziach zamiast na decyzjach i rezultatach, a przede wszystkim, na efektywności cząstkowej zamiast na efektach dotyczących całości. W rezultacie punkt ciężkości stosowanych w inżynierii oprogramowania metryk to spojrzenie z perspektywy procesu i produktu, a nie klienta i jego potrzeb. Stosowane metryki dostarczają informacji ex post. W dodatku, pomimo wszystkich wspomnianych miar, dostawca produktu najczęściej nie może odpowiedzieć klientowi na proste pytania, chociażby najbardziej oczywiste:

Jaka dokładnie część projektu jest gotowa? Jakie jest prawdopodobieństwo, że projekt zakończy się sukcesem w ramach budżetu i zgodnie z przyjętym harmonogramem?

W świetle powyższego nie można się dziwić, że projekty kończą się niepowodzeniem (tj. przekraczają budżet, kończą się z opóźnieniem lub są zarzucane przed wdrożeniem). Tylko w Stanach Zjednoczonych w ciągu roku wydano 81 mld USD na projekty, z których zrezygnowano przed wdrożeniem (80 tys. projektów). Ok. 80% dużych i średnich projektów realizowanych na rzecz Depar- tamentu Obrony przekroczyło budżet o ponad 100% planowanej sumy oraz odnotowało opóźnienie powyżej 12 miesięcy (wg informacji serwisuhttp://www.standishgroup.com ).