Od kodu do osobomiesięcy

Musimy się zatem liczyć, że nasz wykładniczy współczynnik B będzie większy od jedności. W pierwszej wersji COCOMO przyjmowano jego poziom równy 1,05, 1,12 lub 1,20, w zależności od typu projektu kwa-lifikowanego jako organiczny (organic), częściowo samodzielny (semi-detached) lub wbudowany (embedded). W modelu ADA wartości te wahały się od 1,04 do 1,24, natomiast aktualny model COCOMO II wyznacza współczynnik równaniem

B = 1,01 + 0,01 x € Wi

gdzie Wi jest wartością jednego z 5 współczynników skali (scale factor), przyjmujących wagi od 0 do 5: PREC (precedensowość, precedentedness), FLEX (elastyczność, felxibility), RESL (ryzykowność, risk resolution), TEAM (zespołowość, team cohesion), PMAT (procesowość, process maturity).

Każdemu z nich można przypisać jedną z wartości: 0 = ekstra wysoka (extra high), 1 = bardzo wysoka (very high), 2 = wysoka (high), 3 = nominalna (nominal), 4 = niska (low), 5 = bardzo niska (very low).

W ten sposób dochodzimy do zakresu B od 1,01 (wszystkie wagi = 0) do 1,26 (wszystkie wagi = 5). Tak więc dla systemu o złożoności 200 KSLOC mamy zakres nakładów w osobomiesiącach (dla A = 1) od 2001,01 do 2001,26 czyli między 211 a 793 OM. Mamy więc dużą rozpiętość skali, ale mieszczą się w niej wszelkie warianty projektowe: od najłatwiejszych do najtrudniejszych. Tymczasem relatywny krok zmiany nakładów w osobomiesiącach jest dość niewielki i wynosi tylko 4,71% przy zmianie jednego współczynnika skali o jeden krok wagowy. Faktyczną wartość mnożnika A (2,8 - 3,67), podobnie jak innych współczynników, wyznacza się szczegółowo za pomocą tabel referencyjnych publikowanych w dokumentacji COCOMO.

Od kopania do programowania

Po znalezieniu liczby osobomiesięcy, niezbędnych do realizacji projektu i przełożeniu ich na optymalny czas kalendarzowy, uzyskujemy średnią ilość potrzebnych osób. Przykładowo: jeśli dla 200 OM czas optymalny wynosi 10 miesięcy, to teoretycznie potrzeba nam będzie 20 osób w zespole do realizacji przedsięwzięcia w tym czasie. Tutaj pojawia się dość często stawiane w tym kontekście pytanie, dlaczego nie można by skrócić czasu poprzez zwiększenie liczebności zespołu?

Prosta arytmetyka wskazywałaby na twierdzącą odpowiedź. W końcu 40 osób pracujących przez 5 miesięcy daje nominalnie tę samą ilość wykonanej pracy. Niemniej właśnie prezentowane reguły wykluczają taką możliwość. To właśnie identyfikację tej bariery czasowej należy uznać za najważniejszy wkład modelu COCOMO do praktyki inżynierii software'owej - ważniejszy nawet aniżeli powiązanie funkcjonalności programu z jego wielkością i przełożenie jej na niezbędne nakłady czasowe za pomocą empirycznych tabel.

Mamy tu bowiem do czynienia z sytuacją podobną jak podczas kopania dołu, powiedzmy 2 metry na metr, który dwie osoby mogą wykopać w ciągu godziny. Tu też nie ma możliwości ukończenia pracy w pół godziny czterema osobami: one się po prostu w tym dole naraz nie zmieszczą. Przykład z dołem może wydawać się banalny, ale mniej banalne są analogie, jakie znajdziemy przy realizacji złożonych projektów IT. To, co jest fizycznym ograniczeniem przestrzennym podczas kopania, odpowiada ograniczeniom możliwości integracji grupy osób, które muszą się ze sobą komunikować podczas tworzenia systemu informatycznego.