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

Przykładowy projekt

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

Punkty funkcyjne