Metody punktów funkcyjnych

1. Metody punktów funkcyjnych Dariusz Piechociński

2. Typy metod • FPA – Function Point Analisys • IFPUG – International Function Point Users Group • MkII FPA – Mark II FPA • UKSMA – United Kingdom Software Metrics Association • FFP – Full Functional Piont • COSMIC – Common Software Measurment International Consorcium

3. Metoda punktów funkcyjnychthe Function Point Analysis Służy do szacowania oprogramowania zarówno w przypadku nowych projektów, jak i modernizacji i rozbudowy istniejących systemów. Została opracowana przez A. J. Albrechta z IBM w latach 70. Jest propagowana i aktywnie rozwijana przez IFPUG. Główne zadania IFPUG to opracowywanie i publikacja podręczników z kolejnymi wersjami FPA. Jest to najbardziej popularna metoda do pomiaru oprogramowania.

4. Analiza punktów funkcyjnych Proces poprawnego stosowania FPA nie jest procesem trywialnym, składa się z sześciu kroków: • zdefiniowanie typu procesu liczenia punktów funkcyjnych • identyfikacja zakresu analizy oraz granic aplikacji • wyliczenie punktów funkcyjnych dla danych • wyliczenie punktów funkcyjnych dla transakcji przetwarzających dane • obliczenie współczynnika dopasowania wartości • wyliczenie końcowej wartości punktów funkcyjnych

5. 1. Określenie typu zliczania punktów funkcyjnych Można wyróżnić trzy typy: a) dla nowo powstających projektów, kiedy wszelkie oceny dokonuje się na podstawie wymagań funkcjonalnych przedstawionych przez końcowego użytkownika oraz wymagań co do konwersji danych b) dotyczy przypadku modyfikacji istniejącej aplikacji, polegającej na zmianie funkcjonalności c) pomiar istniejącej, pracującej aplikacji

6. 2. Identyfikacja zakresu analizy oraz granic aplikacji Poprzez zakres analizy rozumie się funkcjonalność, która podlega szacowaniu. IFPUG określa następujące reguły stosowane do wyznaczenia granic aplikacji: • wyznaczona granica wynika głównie z punktu widzenia i potrzeb użytkownika, tzn. użytkownik powinien określić zakres aplikacji, jej biznesową i użytkową funkcjonalność • granice pomiędzy współpracującymi aplikacjami powinny wynikać z ich funkcjonalności a nie z uwarunkowań technologicznych • ustanowiona początkowo granica jest niezależna od zakresu analizy, za wyjątkiem takich zmian funkcjonalności, których dodanie lub usunięcie spowoduje odpowiednio rozszerzenie lub redukcję granicy aplikacji.

7. 3. Wyliczenie punktów funkcyjnych dla danych Na tym etapie należy zidentyfikować wszystkie logiczne zbiory danych aplikacji (ILF i EIF) oraz oszacować ich kompletność. Następnie trzeba wyliczyć liczbę nieuzgodnionych punktów funkcyjnych dla wszystkich ILF i EIF. ILF (an internal logical file) – grupa logicznie powiązanych danych, wymaganych, określonych przez użytkownika lub danych kontrolnych utrzymywanych i działających w granicach danej aplikacji. Dane kontrolne to dane niezbędne do sterowania procesami aplikacji. EIF (an external interface file) - określona przez użytkownika grupa logicznie powiązanych danych lub informacji kontrolnych odnoszących się do aplikacji, lecz utrzymywanych w granicach innej aplikacji.

8. 3.1. Wyliczenie punktów funkcyjnych dla danych Dla każdego ILF i EIF należy wyznaczyć liczbę elementów danych (DET) oraz liczbę elementów rekordów (RET). RET (a record element type) – to podgrupa danych w ILF lub EIF określona przez użytkownika, może być opcjonalna lub obowiązkowa. DET (a data element type) – to unikalne, określone przez użytkownika, nie powtarzające się pole w ILF lub EIF.

9. RET i DET • Reguły wyznaczania RET: • licz jako RET każdą podgrupę danych ILF lub EIF • jeśli nie można wydzielić podgrup należy każdy ILF i EIF policzyć jako jeden RET • Reguły obliczania DET: • jako DET należy liczyć każde unikalne, zidentyfikowane przez użytkownika pole, będące elementem ILF lub EIF • jeśli dwie aplikacje korzystają z tych samych wewnętrznych (ILF) lub zewnętrznych (EIF) logicznych zbiorów danych ale odwołują się inaczej do podgrup danych to liczbę DET należy liczyć stosownie do każdej aplikacji • każda grupa danych, która umożliwia relację z innym ILF lub EIF musi zostać policzona jako jeden DET

10. Złożoność ILF i EIF Na podstawie obliczonej liczby RET i DET szacuje się poziom funkcjonalnej kompletności dla każdego ILF i EIF, zgodnie z poniższą tabelą: DET RET

11. Liczba punktów funkcyjnych Na podstawie wyznaczonego poziomu funkcjonalnej kompletności wyznacza się ilość punktów funkcyjnych, przypadających na każdy ILF i ELF, zgodnie z tabelą: Wynik stanowi suma punktów funkcyjnych przypadająca na każdy ILF i EIF.

12. 4. Wyliczenie punktów funkcyjnych dla transakcji przetwarzających dane Ten etap polega na zidentyfikowaniu tzw. funkcji transakcyjnych (EI, EO, EQ) oraz ich kompletności (złożoności), a następnie wyliczeniu liczby surowych punktów funkcyjnych dla każdej z funkcji.

13. Funkcje transakcyjne EI (external inputs) – to proces elementarny, któremu są poddawane dane lub dane kontrolne przychodzące spoza granic aplikacji. Podstawowym celem EI jest działanie na/z jednym lub więcej ILF zmieniając jego dane lub/i zachowanie systemu. EO (external outputs) – to proces elementarny, który wysyła dane lub dane kontrolne poza granice aplikacji. Podstawowym celem EO jest prezentacja informacji użytkownikowi w procesie wyszukiwania tychże. Proces powinien zawierać przynajmniej formułę lub wzór matematyczny wyliczający wartość danych lub generować wyprowadzane dane. EO może również działać na/z jednym lub więcej ILF zmieniając jego dane lub/i zachowanie systemu. EQ (external inquiry) - to proces elementarny, który wysyła dane lub dane kontrolne poza granice aplikacji. Podstawowym celem EQ jest prezentacja informacji użytkownikowi poprzez wyszukanie danych z ILF lub ELF, ale bez korzystania ze wzorów matematycznych oraz bez generowania danych. W trakcie działania EQ nie może nastąpić modyfikacja ILF i zmiana zachowania systemu.

14. Transakcyjny typ funkcjonalny Aby zidentyfikować funkcje EI, EO, EQ należy każdy proces elementarny poddać analizie co do jego podstawowej celowości i zgodnie z tabelą określić typ funkcjonalny: Każdy proces elementarny musi być jednoznacznie określony i może być liczony tylko raz.

15. FTR i DET Aby wyznaczyć poziom funkcjonalnej kompletności funkcji transakcyjnych trzeba wcześniej obliczyć wartość FTR i DET. • FTR (a file type referenced) to: • ILF czytany lub modyfikowany przez funkcję transakcyjną • EIF, z którego czytane są informacje • Reguły liczenia FTR są następujące: • licz każdy modyfikowany ILF jako jeden FTR • każdy czytany ILF i ELF licz jako jeden FTR • każdy plik licz tylko raz Wartość DET wyznacza się jak poprzednio.

16. Złożoność EI, EO, EQ Na podstawie wyznaczonych liczb FTR i DET, wyznacza się poziom funkcjonalnej kompletności wg tabeli: DET FTR

17. Liczba punktów funkcyjnych Gdy znana jest już kompletność funkcji transakcyjnych, można wyznaczyć ilość punktów funkcyjnych, dla EI, EO, EQ zgodnie z tabelą:

18. 5. Obliczenie współczynnika dopasowania wartości VAF VAF (the value adjustment factor) – jest oparty na 14 generalnych charakterystykach GSC, których zadaniem jest oszacowanie funkcjonalności liczonej aplikacji. GSC zawiera zbiór pytań, które pozwalają na całkowite oszacowanie złożoności systemu, poprzez określenie cech takich jak: rozproszone przetwarzanie, szybkość wykonywania transakcji, aktualizacja on-line, ponowne użycie. Dokładny opis wszystkich pytań można znaleźć w „Function Point Counting Practises Manual” wydawanym przez IFPUG.

19. 5.1. Współczynnik dopasowania wartości Aby obliczyć VAF należy wykonać następujące kroki: • oszacuj każdą z 14 charakterystyk, wynik umieść na skali od 1 do 5, co odpowiada określeniu tzw. stopnia wpływu DI • oblicz całkowity stopień wpływu TDI sumując wyniki z punktu 1 • oblicz VAF korzystając z równania: VAF = (TDI * 0,01) + 0,65

20. 6. Wyliczenie końcowej wartości punktów funkcyjnych Ten krok ma 3 warianty w zależności od typu zliczania punktów funkcyjnych, jaki został przyjęty w punkcie 1.

21. 6.1. Projekt nowego systemu DFP = (UFP + CFP) * VAF DFP (development project function point count) - całkowita liczba punktów funkcyjnych dla nowego projektu UFP (unadjusted function point) – nieuzgodniona liczba punktów funkcyjnych dla funkcjonalności aplikacji, dostępnej dla użytkownika końcowego po instalacji CFP (conversion function point) – nieuzgodniona liczba punktów funkcyjnych wynikająca z konwersji danych

22. 6.2. Modyfikacja systemu EFP = [(ADD + CHGA + CFP) * VAFA] + DEL * (VAFB) EFP (enhancement project function point) – końcowa wartość punktów funkcyjnych w wypadku modyfikacji aplikacji. ADD - nieuzgodniona liczba punktów funkcyjnych odzwierciedlająca te funkcje, które będą dodane w procesie modyfikacji. CHGA - nieuzgodniona liczba punktów funkcyjnych liczona dla modyfikacji istniejących funkcji. VAFA – współczynnik VAF liczony po modyfikacji. DEL - nieuzgodniona liczba punktów funkcyjnych odzwierciedlająca te funkcje, które będą usunięte w procesie modyfikacji. VAFB - współczynnik VAF liczony przed modyfikacji.

23. 6.3. Wymiarowanie istniejącego systemu AFP = AD * VAF AFP – końcowa wartość punktów funkcyjnych AD - nieuzgodniona liczba punktów funkcyjnych wynikająca z funkcjonalności aplikacji, dostępnej dla użytkownika końcowego.

24. 6.3. Wymiarowanie istniejącego systemu (2) Aby wyznaczyć liczbę punktów funkcyjnych po modyfikacji należy użyć wzoru: AFP = [(UFPB + ADD + CHGA) – (CHGB + DEL)] * VAF AFP – końcowa wartość punktów funkcyjnych UFPB - nieuzgodniona liczba punktów funkcyjnych wynikająca z funkcjonalności aplikacji przed modyfikacją. ADD - nieuzgodniona liczba punktów funkcyjnych odzwierciedlająca te funkcje, które zostaną dodane podczas modyfikacji. CHGA - nieuzgodniona liczba punktów funkcyjnych modyfikacji istniejących funkcji, liczona po modyfikacji. CHGB - nieuzgodniona liczba punktów funkcyjnych modyfikacji istniejących funkcji, liczona przed modyfikacją. DEL - nieuzgodniona liczba punktów funkcyjnych odzwierciedlająca te funkcje, które zostaną usunięte w wyniku modyfikacji

25. Zalety FPA • jest stosowana bez względu na język programowania • jest stosowana do szacowania całych systemów informatycznych lub tylko ich poszczególnych modułów • jest stosowana do szacowania nowego oprogramowania jak i modernizacji istniejącego • wiele narzędzi programistycznych szacujących koszty i inne wskaźniki bazuje na FPA

26. Wady FPA • tylko certyfikowani specjaliści dają gwarancję osiągnięcia poprawnych rezultatów • poprawne wyliczenie punktów funkcyjnych wymaga dużo czasu, więc jest dość kosztowne • nie jest stosowana automatyzacja FPA • wyniki obliczeń dla systemów mniejszych niż 15 FP, mogą być niereprezentatywne • brak powiązań między standardem IFPUG a innymi wersjami FPA

27. FP a aplikacje • 1 FP  125 instrukcji w C • 10 FP - typowy mały program tworzony samodzielnie przez klienta (1 m-c) • 100 FP - większość popularnych aplikacji; wartość typowa dla aplikacji tworzonych przez klienta samodzielnie (6 m-cy) • 1.000 FP - komercyjne aplikacje w MS Windows, małe aplikacje klient-serwer (10 osób, ponad 12 m-cy) • 10.000 FP - systemy (100 osób, ponad 18 m-cy) • 100.000 FP - MS Windows’95, MVS, systemy militarne

28. Wykorzystanie FP • Ocena złożoności realizacji systemów • Audyt projektów • Szacowanie liczby testów • Ocena jakości pracy i wydajności zespołów ludzkich • Ocena stopnia zmian, wprowadzanych przez użytkownika na poszczególnych etapach budowy systemu informatycznego • Prognozowanie kosztów pielęgnacji i rozwoju systemów • Porównanie i ocena różnych ofert dostawców oprogramowania pod kątem merytorycznym i kosztowym

29. MarkII FPA • Uproszczenie w stosunku do FPA: • Wejścia – dane przychodzące do systemu • Wyjścia – dane przekazywane do systemów zewnętrznych • Modyfikacja danych – pozyskiwanie i usuwanie danych z magazynów trwałych • Szacowanie tylko na podstawie wymagań funkcjonalnych

30. Podstawowe komponenty logiczne

31. Części składowe komponentów BLC w MkII

32. Części składowe komponentów BLC w IFPUG

33. Pozyskiwanie danych • W MkII każda encja jest traktowana niezależnie i odwołania do niej są liczone jako transakcje logiczne. • W IFPUG encje są grupowane w pliki ILF lub EIF. Odwołania do encji są liczone jako FTR (poprzez EI, EO, EQ).

34. Full Function Points • Stosowana do aplikacji biznesowych, systemów czasu rzeczywistego (np. systemy operacyjne) oraz ich hybryd • Jednakowa skala pomiaru • Łatwa do nauczenia i stosowania • Mierzenie wymagań funkcjonalnych w FFP ułatwia sprecyzowanie tych wymagań • Możliwość automatyzacji z wykorzystaniem modeli UML

35. Punkty pomiarowe Measurments Viewpoints • Punkt widzenia dewelopera: pozwala zmierzyć rozmiar architektury systemu, np.: wielowarstwowe, wielowęzłowe. • Użyteczny dla menedżerów projektu. • Punkt widzenia użytkownika: mierzy rozmiar aplikacji na podstawie wymagań funkcjonalnych. • Porównywalny z metodami I generacji

36. Procesy funkcjonalne (1) • Wejścia / Wyjścia • Dane przekraczają granicę pomiędzy mierzonym systemem a jego użytkownikiem (lub innymi aplikacjami) • Odczyt • Dane przenoszone z magazynu trwałego do mierzonego systemu • Zapis • Dane przenoszone z systemu do magazynu trwałego

37. Procesy funkcjonalne (2)

38. Punkty funkcyjne • Każde przemieszczenie danych w ramach procesów to punkt CFsu • CFsu - COSMIC functional size unit • Rozmiar procesu = suma przemieszczeń danych • Rozmiar systemu = suma rozmiarów poszczególnych procesów funkcyjnych

39. Rozmiar skali punktowej • IFPUG - max. rozmiar procesu to 6UFP, max. rozmiar pliku logicznego to 15UFP. • COSMIC-FFP – brak górnego limitu na rozmiar procesu • Konwersja rozmiaru: Y (Cfsu) = - 6.2  +  1.1 X (UFP)

40. Rozmiar skali punktowej (2) • Systemy lotnicze – rozmiar > 100CFsu • Systemy ubezpieczeniowe – rozmiar > 25CFsu • Pomiar tych systemów metodą IFPUG może oznaczać niedoszacowanie • Pomiar metodą COSMIC-FFP może być wolniejszy niż przy IFPUG

41. KONIEC „Kiedy możesz zmierzyć coś o czym mówisz, i wyrazić to w liczbach, wtedy wiesz coś o tym; ale kiedy nie możesz tego zmierzyć, nie możesz wyrazić tego w liczbach, wtedy twoja wiedza jest skąpa i niesatysfakcjonująca”. ( Lord Kelvin, Popular Lectures and Addresses, 1889 )