Czy narzędzia analizy ekonomicznej, zastosowane w inżynierii oprogramowania, pozwalają na uniknięcie niepewności, błędnych decyzji i rozczarowań?

Trudno kwestionować słuszność posłużenia się stan- dardowymi miernikami eko- nomicznymi do pokazania wszystkim zainteresowanym, że istnieją przekonywające przesłanki biznesowe inwestowania w określone rozwiązanie informatyczne. Menedżerowie zwrócą przede wszystkim uwagę na argumenty, których sami używają na co dzień i które rozumieją, zwłaszcza jeśli za ich pomocą będzie można dowieść, że jest interes do zrobienia. Niestety, nie jest to łatwe, ponieważ zastosowanie narzędzi analizy ekonomicznej w inżynierii oprogramowania nastręcza ogromne trudności.

Szacowanie nieoszacowanego

Nawet oszacowania ex post mogą spowodować kłopoty, które się zwielokrotniają, gdy rachunek ma być oparty na danych estymowanych i prognozowanych. Możliwości współczesnych technik estymacji i prognozowania w sposób istotny odbiegają bowiem od oczekiwań i potrzeb menedżerów zarządzających procesem wytwarzania oprogramowania.

Na etapie negocjacji, gdzie potrzebne są szacunki nakładów i czasu realizacji projektu, błąd nie powinien przekraczać 30%, zaś na etapie planowania fazy kodowania - 5%. Tymczasem nie ma dowodów, by istniejące modele i narzędzia gwarantowały lepszą jakość niż 100% błędu w odniesieniu do nakładów i czasu realizacji na etapie specyfikacji wymagań oraz 30% błędu na etapie rozpoczęcia kodowania. Co więcej, menedżerowie przyznają, że w wielu przypadkach skala błędu w odniesieniu do obu wielkości przekracza 200%.

Nowe modele, procedury, systemy i narzędzia mogą przynosić niewielką poprawę jakości prognoz (szczególnie w przypadku firm wytwarzających podobne produkty o znanej i zweryfikowanej specyfikacji i stabilnym procesie rozwojowym), lecz nie zmieniają w sposób zasadniczy opisanej sytuacji. Prawdopodobnie zresztą wymagania i oczekiwania menedżerów oprogramowania i ich klientów nie mogą być spełnione, zainteresowane strony zaś powinny się pogodzić z ograniczoną dokładnością estymacji i prognoz w inżynierii oprogramowania. W rezultacie może lepiej byłoby skoncentrować się na zarządzaniu niepewnością i ryzykiem w branży oprogramowania, zamiast poszukiwać rozwiązań, których nie da się osiągnąć.

Podobne problemy towarzyszą przecież prognozom w odniesieniu do wszystkich systemów, które charakteryzuje brak determinizmu i naturalnych praw rządzących ich rozwojem oraz złożoność, nieliniowość i zdolność do adaptacji. Takie analogie między jakością a efektywnością predykcji zachodzą chociażby w naukach ekonomicznych i naukach o zarządzaniu.

Nietrudno dostrzec wiele innych podobieństw między praktyką ekonomii i teorią zarządzania a inżynierią oprogramowania. Wszystkie te dyscypliny zajmują się budowaniem i projekto- waniem złożonych artefaktów, obejmują działania oparte na intensywnym wykorzystaniu wiedzy, a uzyskiwane efekty zależą także od kontekstu społecznego.

Ilustracją tej ostatniej zależności są być może nieco anegdotyczne, lecz prawdziwe zjawiska i zdarzenia zachodzące w sferze wytwarzania oprogramowania, np.

- przeniesienie dodatkowych pracowników do opóźnionych projektów zwiększa opóźnienie;

- programiści produkują tysiące niepotrzebnych wierszy kodu, jeśli tylko ich wynagrodzenie oparte jest na wydajności mierzonej liczbą napisanych wierszy kodu na jednostkę czasu;

- personel testujący nie ujawnia wykrytych błędów kodu, by zapewnić zgodność stopy wykrywanych błędów w trakcie testowania z planami lub założeniami;

- programiści obciążają kosztami swojej pracy projekty, w których są rezerwy budżetu, a nie te, nad którymi w rzeczywistości pracowali;

często rezygnuje się z projektów, które wyglądają niezwykle atrakcyjnie, jeśli chodzi o relację miedzy nakładami a wielkością, zanim zrealizowano cokolwiek o znaczeniu praktycznym.