Metryka programu
- Jarosław Badurek,
- 27.06.2005
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?
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
Więcej nie znaczy lepiej
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.
Paradoks produktywności
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.
Programy są różne
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ą.
14 czynników korekcyjnych wagowanych od 0 do 5 każdy (dla każdego czynnika można wskazać szczegółowe interpretacje dla wyboru wagi).