Ocena przez analogię

Metoda podobna do poprzedniej, tylko że analogia nie musi dotyczyć doświadczeń osób oceniających, ale np. porównania danych bieżącego projektu z danymi zgromadzonymi w bazie charakterystyki produktywności firmy lub bazie zakończonych projektów.

Ocena zstępująca/wstępująca

Koszt i parametry całości są szacowane "z góry" lub "z dołu" jako suma mniejszych składowych, np. modułów.

Szacunek kosztów jednostkowych

Oceniający dysponuje danymi o parametrach czynności podstawowych (elementarnych), np. średni czas tworzenia strony dokumentacji lub średnia liczba linii kodu w miesiącu na osobę. Na ich podstawie wyliczane są pozostałe parametry projektu, np. pracochłonność otrzymujemy przez podzielenie oszacowanej liczby linii kodu programu przez średnią produktywność programisty w liniach kodu na miesiąc.

Podejście to może wprowadzać duży błąd systematyczny do oszacowań, przez korzystanie z syntetycznych "wysoce" uśrednionych parametrów podstawowych. Nie daje się także łatwo zastosować do niektórych etapów produkcji oprogramowania, szczególnie koncepcyjnych, takich jak analiza wymagań i projektowanie.

Modelowanie algorytmiczne

Na podstawie danych z poprzednich projektów opracowywany jest sparametryzowany model charakterystyk projektu i korelacji między nimi. Po wprowadzeniu kilku podstawowych parametrów (najczęściej szacujących złożoność lub rozmiar programu) pozostałe wyliczane są automatycznie.

Dostępnych jest obecnie wiele różnych modeli opartych na uśrednionych parametrach wielu zakończonych projektów.

Do najbardziej znanych modeli parametrycznych należą:

metoda punktów funkcyjnych FPA (Function Points Analysis)

model COCOMO (COnstructive COst MOdel).

Z notatnika praktyka

1 Proces jest na tyle dojrzały, na ile dojrzałe są metody jego pomiaru.

2 Oszacowania są tym składnikiem projektu, który jest najbardziej podatny na "naciski" z zewnątrz.

3 Bez informacji opartej na faktach, jesteś kolejną osobą z kolejną opinią na pewien temat.

4 Nie pytaj, czy mierzyć charakterystyki projektu. Pytaj, jak je mierzyć.

5 Nie kieruj nowych pracowników do spóźnionego projektu. Zakończy się on jeszcze później.

6 Pamiętaj o regule 40-20-40. 40% czasu projektu powinno zajmować planowanie, analiza wymagań i projekt, 20% czasu - kodowanie, a pozostałe 40% testowanie i pielęgnacja.

<hr size=1 noshade>Zarządzanie projektami informatycznymi - część 6