Problemy, z jakimi mamy do czynienia podczas realizacji projektów informatycznych, w znacznym stopniu związane są z błędami planowania, a zwłaszcza niedoszacowania czasu implementacji. Czy inżynieria oprogramowania pozwala na precyzyjny pomiar jego złożoności?

Samo zastosowanie nowoczesnych strategii i narzędzi programowania nie przesądza jeszcze o powodzeniu projektu informatycznego. Owszem, takie metody, jak np. eXtreme Programming (o czym można było poczytać w artykule "Ekstremalna jakość" opublikowanym na łamach tygodnika Computerworld nr 22/2005), mogą pomóc w osiągnięciu sukcesu, ale ważne jest, aby przedsięwzięcie ukończyć w planowanym czasie. Tymczasem często zdarza się, że występujące opóźnienia projektowe próbuje się likwidować, zwiększając liczebność zespołu wykonawców. W ten sposób, z definicji, dochodzi do podwyższenia kosztów, a co gorsza do tzw. paradoksu Brookesa - "Zwiększenie grupy projektowej w celu zmniejszenia opóźnień w trakcie trwania projektu informatycznego prowadzi do ich wzrostu".

Przy "pierwszym czytaniu" tej reguły mamy wrażenie dowcipu na kształt prawa Murphy'ego, ale w praktyce faktycznie działa następujący schemat:

Czas trwania projektu zostaje nieoszacowany (1), co prowadzi do opóźnień, więc kierownictwo projektu reaguje na opóźnienia, zwiększając zespół projektowy (2). "Stary" zespół musi teraz inwestować znaczną część czasu na wdrożenie "nowych" (3), więc wynikły z tego dalszy wzrost opóźnień owocuje kolejnym rozrostem grupy (4), która jest teoretycznie tak duża, że mogłaby nadrobić opóźnienia, ale wykładniczy wzrost liczby kanałów komunikacyjnych w zespole zwiększa chaos i w skrajnym przypadku prowadzi do załamania projektu (5).

Software'owa literatura

Dla wyjścia z opisywanego impasu teoria organizacji proponuje właściwie tylko jedno eleganckie rozwiązanie: przerwać projekt i przeprowadzić jego reorganizację w oparciu o urealnione szacowania czasów realizacji oraz związane z nimi koszty. Z oczywistych i całkowicie pozaorganizacyjnych powodów bardzo rzadko zetkniemy się w praktyce z takim wariantem postępowania. W praktyce raczej mamy do czynienia z próbą przepychania projektu "na siłę". Można i tak, tyle że trzeba tę "siłę" mieć, a tymczasem fizyka prawa zachowania bilansu projektowego w klasycznym trójkącie czas-koszty-jakość jest nieubłagana i dotrzymanie sztywnych ram czasowo-kosztowych musi negatywnie odbić się na jakości systemu informatycznego. I widać, że w praktyce często tak się dzieje.

Czy można w odpowiedni sposób oszacować czasową złożoność projektu IT? Przede wszystkim musimy zacząć od pytania, czy możliwy jest uniwersalny pomiar takiej złożoności w oparciu o już zrealizowane projekty. Owszem, algorytmika posługuje się precyzyjnie pojęciami pamięciowej bądź czasowej złożoności obliczeniowej programu, ale te parametry niewiele mówią o jego czasowej złożoności projektowej. Krótko mówiąc: potrzebujemy specjalnych metryk oprogramowania, by wiarygodnie prognozować czas realizacji projektu. Należy zatem szukać transformacji, która pozwoliłaby powiązać cechy kodu z czasem jego implementacji.

Dla uproszczenia zakładam, że istnieje jakiś fundamentalny budulec oprogramowania, coś na miarę fizycznego atomu, więc wydawać by się mogło, że powinno się udać dokonanie takiego szacowania w podobny sposób jak architektowi, który może przewidzieć czas budowy domu na podstawie jego kubatury i powierzchni, przekładając je precyzyjnie na ilość potrzebnych do wykonania konstrukcji cegieł. Tymczasem przygotowanie programu może być zadaniem podobnie twórczym jak pisanie dzieł literackich. Tu też niewiele da się powiedzieć o związkach rozmiaru tekstu z czasem jego powstawania. Światowemu rekordziście literackiemu, Józefowi Ignacemu Kraszewskiemu, przypisuje się autorstwo ponad 600 tomów. Z kolei sedno dorobku poetyckiego jednego z najwybitniejszych aforystów, Stanisława Jerzego Leca, nieśmiertelne ‚Myśli nieuczesane" mieszczą się na parudziesięciu stronach skromnej broszurki. A przecież powstawały one przez dziesięciolecia mozolnego cyzelowania każdego słowa i przecinka!

Metryki paradoksów

Nie inaczej jest w branży IT. Inną specyfikę ma zwarty algorytm naukowo-techniczny, posługujący się wyrafinowanymi narzędziami matematycznymi, dokonujący intensywnych obliczeń na relatywnie niewielkiej ilości danych, inną zaś program dla zastosowań gospodarczych, gdzie wielkie ilości informacji przetwarzane są prostymi instrukcjami 4-działaniowej arytmetyki. Tymczasem w obu przypadkach klasyczną metryką jest liczba linii kodowych LoC (Lines of Code). Precyzyjniej mówi się przy tym o źródłowym kodzie logicznym SLoC (Source Line of Code), pomijającym m.in. komentarze.

Już tylko sama ostatnia uwaga budzi zakłopotanie każdego praktyka. Konia z rzędem temu, kto widział program "przedokumentowany". Z reguły narzekamy na luki w dokumentacji, którą często wykonuje się "na kolanie", już po zakończeniu projektu, w myśl zasady, że najpierw program musi "chodzić", a dopiero potem, "jak będzie czas", to się go z grubsza opisze. A przecież dokumentacja (samodokumentacja) ważna jest nie tylko dla klienta i całego przyszłego cyklu życia programu, ale także dla programisty, który nierzadko sam wpada w "dokumentacyjną dziurę" - podczas pisania programu wszystko jest oczywiste, ale po pewnym czasie, gdy przyjdzie mu do powrotu do wcześniejszych fragmentów swego dzieła, to zaczyna drapać się w głowę - "co to ja chciałem przez to powiedzieć?".

Kolejnym problemem "mitycznej linii kodowej" jest paradoks produktywności, wynikający z nieuwzględnienia podczas pomiaru poziomu abstrakcyjności narzędzia programowania, mającego istotne znaczenie dla parametrów jakościowych tworzonego systemu. Od podobnych wad nie są także wolne metody szacowania, porównujące rozmiar kodu w bitach bądź korzystające z różnego rodzaju funkcji dla ilościowych cech kodu, np. liczby stosowanych symboli i słowników (cyklomatyka McCabe). Również i w tym przypadku mogą być one zależne od określonej konfiguracji sprzętowo-software'owej aplikacji, a nie od niej samej (tzn. od jej funkcjonalności). Zatem interesującym rozwiązaniem wydaje się być korzystanie z metod szacowania zorientowanych aplikacyjnie, uwzględniających punkty funkcyjne systemu FP (Function Points).

Punktowanie kodu

Liczenie punktów funkcyjnych zaczyna się od dekompozycji systemu na składowe, które są przypisywane do jednego z 5 rodzajów składowych. Po zsumowaniu wszystkich wag uzyskujemy niestandaryzowaną wartość FP (NFP - punktów funkcyjnych). Teraz dokonujemy ich standaryzacji (SFP), z uwzględnieniem złożoności technicznej (ZT) zgodnie z formułami:

SFP = ZT . NFP

ZT = 0,65 + 0,01 . Ś . Fi

gdzie Fi - techniczne czynniki standaryzacji (korekty) szacowane w skali od 0 (brak) do 5 (bardzo wyraźna zależność), zgodnie z tabelą.

Ostatnim elementem opisywanej metody jest przejście od SFP do LoC, czemu również służą empirycznie dobrane, szczegółowe współczynniki (dla asemblera wahają się one od 200 do 450 linii na punkt funkcyjny). Dla porównania podajmy jeszcze kilka uśrednionych charakterystyk dla wybranych narzędzi: C - 127, Cobol - 107, Java - 53, generatory aplikacji Oracle (Developer) - 23. W podobny sposób możliwe jest przeliczenie punktów funkcyjnych na wartości pieniężne, względnie czasowe. W ten sposób możemy liczbowo powiązać najistotniejsze czynniki będące podstawą dla planowania projektu: czas, pieniądz, rozmiar kodu i jego funkcjonalność. Z pewnością opisywana metoda nie jest idealna, w szczególności trudno ją zautomatyzować z uwagi na subiektywizm występujący w procesie wagowania zdekomponowanych składowych. Niemniej miary punktowo-funkcyjne pozwalają w znacznej mierze uniknąć paradoksu produktywności, stąd mają przewagę nad metrykami opartymi jedynie na liczbie linii kodowych. Trzeba także pamiętać, że szacowanie złożoności projektu jest rodzajem prognozy, którą można manipulować, a ta z kolei może wykazywać tendencję do samospełniania się: szacunki definiują budżet, pod który "przycina się" program.