Mierzenie produktywności zespołów deweloperskich

Literatura

Inżynieria oprogramowania CASE - Andrzej Jaszkiewicz
Inżynieria oprogramowania w projekcie informatycznym - pod. red. Janusza Górskiego
Klasyka Informatyki Inżynieria oprogramowania - Ian Sommerville

Metryka Cocomo

https://docs.google.com/document/d/10tMhhsZHz5QkClTkPZy4IQHTr_laHT8_t3MQ_mIkSgc

Punkty funkcyjne wg specyfikacji IFPUG

Alan Albrecht w 1979r. opracował metodę punktów funkcyjnych

Powołanie IFPUG w 1984r. (propagowanie i rozwijanie FP)

Ideą tej metody jest określenie rozmiaru oprogramowania z punktu widzenia użytkownika niezależnie od technologii użytej do jego implementacji. Metoda została opracowana z myślą o aplikacjach transakcyjnych. Jej wadą jest to, że słabo nadaje się do szacowania systemów czasu rzeczywistego czy systemów opartych na komunikacji. Potrzeba szacowania rozmiaru funkcjonalnego tych systemów spowodowała powstanie niezależnych od twórców metody punktów funkcyjnych jej rozszerzeń pozwalających na szacowanie tych systemów.

wejścia (EI - External Input) np. formularz
zapytania (EQ - External Inquire) np. wyszukiwanie danych
wyjścia (EO - External Output) np. raporty w aplikacji

Schematy liczenia FP

nowopowstająca aplikacja,
modyfikowana aplikacji,
istniejących aplikacji

Rozmiar funkcjonalny aplikacji jest sumą punktów funkcyjnych dla danych i dla transakcji, wynika z funkcjonalności jakiej oczekuje użytkownik. Z kolei czynnik korygujący wynika z charakterystyk systemu, które mogą wpłynąć na jego złożoność.

Szacowanie rozmiaru funkcjonalnego

Oszacowujemy liczby RET i DET.

RET - tabele przechowywane w bazie danych (rekordy)
DET - tabele przechowywane w bazie danych (dane)

Znając liczbę DET i RET można odczytać stopień złożoności pliku z odpowiednich tabel dla plików wewnętrznych lub zewnętrznych.

Szacowanie punktów funkcyjnych dla danych

Aby policzyć złożoność funkcjonalną dla danych należy zidentyfikować wszystkie pliki ILF, EIF oraz RET i DET w ramach tych plików.

Szacowanie punktów funkcyjnych dla transakcji

Dla transakcji należy zidentyfikować wszystkie transakcje, jakie będą miały miejsce w systemie. Następnie na podstawie liczby DET, FTR (pliki ILF lub EIF) które uczestniczą w transakcji oraz typu transakcji (EI, EO, EQ) określa się złożoność oraz liczbę punktów funkcyjnych dla każdej transakcji na podstawie tabel.

Czynniki korygujące

IFPUG wyodrębnił 14 czynników korygujących (Value Adjustment Factor - VAF). Każdemu z czynników możemy przypisać wagę od 0 - 5.

1. przesyłanie danych
2. przetwarzanie rozproszone
3. wydajność
4. obciążenie platformy sprzętowej
5. stopa transakcji
6. wprowadzanie danych on-line
7. wydajność użytkownika końcowego
8. aktualizacja on-line
9. przetwarzanie złożone
10. wielokrotna używalność
11. łatwość instalacji
12. łatwość obsługi
13. wielokrotna lokalizacja
14. łatwość wprowadzania zmian

Przykład czynnika korygującego dla przesyłu danych

Przykładowy projekt

VAF = 0,65+(0,01*10) = 0,66  
PF = VAF*NPF = 0,66*134 = 89

Zalety

stosowanie jednostek umownych
odzwierciedlenie funkcjonalności systemu (tyczy się systemów bazodanowych)
oszacowanie złożoności systemu w różnych fazach

Pomimo zalet

Metoda ta nie uwzględnia działań związanych z wytworzeniem systemu takich jak konieczność zapewnienia bezpieczeństwa danych, potrzeba przeszkolenia użytkownika, stworzenie dokumentacji, czy konieczność takiej implementacji, aby tworzony system współdziałał z innym systemem.

Wady

trudność stosowania
brak obiektywności
wymagana wiedza ekspercka
możliwość przejścia kursów tylko w USA
duży koszt analizy
kiepskie odzwierciedlenie na dzisiejsze postrzeganie projektów
nie uwzględnia się wewnętrznych złożoności