COCOMO i estymacja kosztów oprogramowania

W poprzednim post’cie zajmowałem się rozważaniami na temat wyceny oprogramowania. Ponieważ widzę, że ten temat wzbudził zainteresowanie (dziękuję za uwagi w komentarzach i mailach) dziś chciałbym go kontynuować.

Oczywiście po przeczytaniu poprzedniego tekstu chyba każdemu nasunęły się następujące pytania:

• Ja uzależnić opisywaną wycenę od języka programowania (przecież ilość linii zależy w dużym stopniu od języka)?
• Jak uzależnić wycenę od umiejętności programisty (lub nawet całego zespołu)?
• Co z faktem, że jeden projekt może być bardziej skomplikowany od innego?
• Jak zliczać linie? (Czy liczyć puste? Czy liczyć linie zawierające tylko komentarze? Czy może pomijać pewne linie?)
• Co z faktem, że w projekcie uczestniczą osoby z różnymi umiejętnościami, o różnym doświadczeniu i o różnych funkcjach?

Dziś spróbuję odpowiedzieć na te pytania.

Trochę teorii

Metoda COCOMO przy szacowaniu kosztu posługuje się oczywiście pewnymi wzorami, w najprostszym przypadku są to (wg Wikipedii):

• Nakład pracy w osobomiesiącach: E = a*(KDSI)^b, gdzie KDSI ilość linii kodu w tysiącach (1000 linii to 1KDSI)
• Czas potrzebny do wykonania projektu (time to develop): D = c*E^d
• Liczba osób przy której projekt będzie najefektywniej realizowany: P = E/D

Natomiast współczynniki a, b, c, d są następujące:

Typ projektu	a	b	c	d
Organic	2.4	1.05	2.5	0.38
Semi-detached	3.0	1.12	2.5	0.35
Embedded	3.6	1.20	2.5	0.32

Typy projektu podane w tabeli, to:

• Łatwy ("organic"), to projekt, w którym mały zespół posługuje się znanymi narzędziami pracy. Zna on sprzęt i oprogramowanie, z którymi rozwijany projekt będzie reagować. Presja czasu jest mała. Łatwe projekty są wielkości do max. 50 KDSI.
• Średniej trudności projekt ("semi-detached"), jest to projekt, w którym np. jeden z czynników w projekcie nie jest znany (np. zespół nie zna sprzętu, który przyjdzie mu programować itp.) lub projekt rozmiarami przekracza wielkość projektu typu organic. Zwykle takie projekty są wielkości do 300 KDSI.
• Trudny ("embedded"), to złożony projekt, w którym zwykle wiele czynników jest nieznanych lub należy uwzględnić szczególne procedury, np. w branży bankowej.

To jednak dopiero podstawy tej metody, które w angielskiej Wikipedii określone są mianem „Basic COCOMO”. Jeżeli wczytamy się dokładniej znajdziemy „Intermediate COCOMO”, w którym dodatkowo analizowane są dodatkowe cztery atrybuty:

• Produktu
• Wymagana czytelność stworzonego oprogramowania
• Wielkość bazy danych
• Skomplikowanie
• Sprzętu
• Ograniczenia związane z wydajnością
• Czy tworzony system jest systemem czasu rzeczywistego
• Ograniczenia pamięci
• Personelu
• Analiza możliwości
• Doświadczenie w tworzeniu oprogramowania
• Doświadczenie w tworzeniu oprogramowania danego typu
• Doświadczenie w tworzeniu oprogramowania wykorzystującego dane środowisko, sprzęt czy język programowania
• Projektu
• Jakie narzędzia są potrzebne?
• Jakie metody tworzenia oprogramowania będą wykorzystywane?
• Jaki jest harmonogram projektu?
• Jaka jest presja czasu?

Każdy z wymienionych atrybutów jest oceniany i w zależności od tego dobierane są wartości współczynników w odpowiednim równaniu.

Zobaczmy pewne przykłady

W ramach przykładów chciałbym wrócić do przytaczanego w poprzedniej części oprogramowania Argo UML, dla którego wyliczenia kosztu autorzy serwisu www.ohloh.net przyjęli następujące współczynniki (http://www.ohloh.net/wiki/project_codebase_cost): a=2.4 oraz b=1.05, dodatkowo dla płacy 55000$ rocznie wyszło im:

Wróćmy teraz do kalkulatora dostępnego pod adresem: http://www.cms4site.ru/utility.php?ecur=1.12&eafcur=1&utility=cocomoii&sloc=2%2C300&pph=50, tutaj dodatkowo oprócz podawanej liczby linii oraz kosztu roboczogodziny, wybieramy jeszcze współczynniki, których wartości zależą od poziomu skomplikowania projektu oraz poziomu zaawansowania grupy tworzącej oprogramowanie (przykład na rysunku poniżej).

Podsumowanie

W podsumowaniu chciałbym się zająć jeszcze jednym współczynnikiem, o którym nie wspominałem, a właśnie on ma znaczący wpływ na ostateczny koszt, a który trzeba uzależnić od języka programowania, umiejętności programisty, itp.… to oczywiście płaca. To właśnie tutaj można uwzględnić dodatkowe czynniki nie wymienione wcześniej, gdyż tak naprawdę opisywana wyżej metoda służy przede wszystkim do oszacowania czasu, który należy poświęcić (lub który poświęcono) na dany projekt.

Na samym końcu chciałbym jeszcze wspomnieć o jednej sprawie, mianowicie podane równania są prawidłowe, gdy ilość linii kodu w ocenianym oprogramowaniu wynosi kilka tysięcy (np. wspominany kalkulator wymaga minimalnej wartości 2300 linii kodu). Dlatego moja sugestia, co do liczenia ilości linii we wczorajszym programiku i szacowania jego kosztu jest bez sensu, ale mam nadzieję, że ten żart wam się spodobał.