Function Point Analysis
Opracował: Maciej Zdziarstek

Czym jest FPA?

Metoda punktów funkcyjnych (Function Point Analysis) oszacowuje koszt projektu na podstawie funkcji użytkowych, które system ma realizować.

Stąd wynika, ze metoda ta może być stosowana dopiero wtedy, gdy funkcje te są z grubsza znane.

Metoda jest oparta na zliczaniu ilości wejść i wyjść systemu, miejsc przechowywania danych i innych kryteriów. Te dane są następnie mnożone przez zadane z góry wagi i sumowane. Rezultatem jest liczba „punktów funkcyjnych”.

FPA c.d.

Punkty funkcyjne mogą być następnie modyfikowane zależnie od dodatkowych czynników złożoności oprogramowania.

Dodatkowo należy wspomnieć, iż FPA służy (taki był zamysł twórców) do szacowania oprogramowania zarówno w przypadku nowych projektów, jak i modernizacji oraz rozbudowy już istniejących.

FPA jest najlepiej dopracowaną metodą pomiaru software’u, jest ciągle rozwijana a nad zgodnością ze standardem czuwa IFPUG.

Wymiary „przestrzeni” projektu

Opis metody

Metoda punktów funkcyjnych oszacowuje koszt projektu na podstawie funkcji użytkowych, które system ma realizować. Stąd wynika, ze metoda ta może być stosowana dopiero wtedy, gdy funkcje te są z grubsza znane.

Metoda jest oparta na zliczaniu ilości wejść i wyjść systemu, miejsc przechowywania danych i innych kryteriów. Te dane są następnie mnożone przez zadane z góry wagi i sumowane. Rezultatem jest liczba „punktów funkcyjnych”.

Punkty funkcyjne mogą być następnie modyfikowane zależnie od dodatkowych czynników złożoności oprogramowania.

Zdefiniowanie typu procesu liczenia punktów funkcyjnych

Pierwszy dla nowo powstających projektów, kiedy wszelkie oceny dokonuje się dokonuje się na podstawie wymagań funkcjonalnych przedstawionych przez końcowego użytkownika oraz wymagań co do konwersji danych

Drugi dotyczy przypadku modyfikacji istniejącej aplikacji, polegającej na zmianie funkcjonalności, tzn. usunięcia jakiejś funkcji, zmianie lub dodanie nowej

Trzeci to pomiar istniejącej, funkcjonującej aplikacji

Identyfikacja zakresu analizy oraz określenie granic aplikacji

Użytkownik powinien zdefiniować zakres aplikacji, jej użytkową funkcjonalność

Granice pomiędzy współpracującym aplikacjami powinny wynikać z ich funkcjonalności a nie uwarunkowań technologicznych

Ustanowiona początkowo granica aplikacji jest niezależna od zakresu analizy, za wyjątkiem takich zmian funkcjonalności, których dodanie lub usunięcie spowoduje rozszerzenie lub redukcję granicy aplikacji

Wyliczenie nieuzgodnionych punktów funkcyjnych dla wszystkich ILF oraz EIF

Na tym etapie należy zidentyfikować wszystkie możliwe logiczne zbiory danych aplikacji (ILF-internal logical files oraz EIF-external logical files)

ILF – grupa logicznie powiązanych danych, wymaganych, określonych przez użytkownika lub danych kontrolnych utrzymywanych i działających w ramach danej aplikacji

EIF – określona przez użytkownika grupa logicznie powiązanych danych lub informacji kontrolnych odnoszących się do aplikacji lecze utrzymywanych w granicach innej aplikacji

Wyliczenie nieuzgodnionych punktów funkcyjnych dla wszystkich ILF oraz EIF c.d.

Po zidentyfikowaniu wszystkich ILF i EIF dla każdego z nich należy

wyznaczyć RET (record element type) i DET (data element type),

których liczba decyduje o ilości nieuzgodnionych punktów

funkcyjnych.

RET – podgrupa danych w ILF lub EIF określona przez użytkownika

DET – unikalne, określone przez użytkownika, niepowtarzające się

pole

Reguły liczenia RET:

- Liczyć RET jako każdą podgrupę danych ILF i EIF

- Jeśli nie można wydzielić żadnych podgrup należ każdy ILF i EIF

policzyć jako jeden RET

Wyliczenie nieuzgodnionych punktów funkcyjnych dla wszystkich ILF oraz EIF c.d.

Reguły obliczania DET:

- Jako DET należy przyjąć każde unikalne, zidentyfikowane przez

użytkownika pole będące elementem ILF lub EIF

- Liczbę DET należy wyznaczać stosownie dla danej aplikacji

Na podstawie wyznaczonej liczby RET i DET dla każdego ILF i EIF

szacuje się poziom funkcjonalnej kompletności zgodnie z

poniższymi zasadami:

Wyliczenie nieuzgodnionych punktów funkcyjnych dla wszystkich ILF oraz EIF c.d.

Click to add text

Wysoki

Wysoki

Średni

6 i więcej niż 6

Wysoki

Średni

Niski

2 - 5

Średni

Niski

Niski

1

51 i więcej niż 51

20 – 50

1 - 19

Liczba DET/RET

Wyliczenie nieuzgodnionych punktów funkcyjnych dla wszystkich ILF oraz EIF c.d.

Na podstawie wyznaczonego poziomu kompletności funkcjonalnej

Możemy przypisać odpowiednią liczbę nieuzgodnionych punktów

funkcyjnych zgodni z zasadami:

Dla ILF:

15

wysoki

10

średni

7

niski

Liczba surowych punktów funkcyjnych

Poziomy kompleksowości funkcjonalnej

Wyliczenie nieuzgodnionych punktów funkcyjnych dla wszystkich ILF oraz EIF c.d.

Oraz dla EIF:

Odpowiednio się wylicza liczbę nieuzgodnionych punktów

funkcyjnych dla każdego ILF i EIF, ich suma daje stosowny wynik.

10

wysoki

7

średni

5

niski

Liczba surowych punktów funkcyjnych

Poziomy kompleksowości funkcjonalnej

Wyliczanie nieuzgodnionych punktów funkcyjnych dla wszystkich funkcji transakcyjnych

Najpierw należy zidentyfikować tzw. funkcje transakcyjne EI, EO,

EQ (external inputs, external outputs,external inquiry)

EI – proces elementarny, któremu poddawane są dane

przychodząca spoza aplikacji.

EO – proces elementarny, który wysyła dane lub dane kontrolne

poza granice aplikacji

EQ - proces elementarny, który wysyła dane lub dane kontrolne

poza granice aplikacji. Z tym, że celem EQ jest prezentacja

Użytkownikowi informacji poprzez wyszukiwanie danych ale bez

korzystania z formuł matematycznych

Wyliczanie nieuzgodnionych punktów funkcyjnych dla wszystkich funkcji transakcyjnych c.d.

Typ funkcjonalny:

główny

główny

możliwy

Prezentacja informacji użytkownikowi

niedozwolony

możliwy

główny

Modyfikacja 1 lub więcej ILF

Zmiana zachowania systemu

niedozwolony

możliwy

główny

EQ

EO

EI

Transakcyjny typ funkcyjny:

Funkcja

Wyliczanie nieuzgodnionych punktów funkcyjnych dla wszystkich funkcji transakcyjnych c.d.

Przypisanie każdemu EI, EO i EQ odpowiedniej liczby punktów

Funkcyjnych zależy od liczby FTR (file type referenced) i DET

(pojęcie DET zostało omówione wcześniej)

FTR to:

- ILF czytany lub modyfikowany przez EI, EO i EQ

- EIF z którego czytane są informacje

Reguły liczenia FTR:

- Licz każdy modyfikowany ILF jako jeden FTR

- Każdy czytany ILF oraz EIF licz jako jeden FTR

- Każdy modyfikowany i czytany plik licz tylko raz

Wyliczanie nieuzgodnionych punktów funkcyjnych dla wszystkich funkcji transakcyjnych c.d.

Szacowanie poziomu funkcjonalnej kompletności:

Dla EI:

Dla EO i EQ:

wysoki

wysoki

średni

3 i więcej niż 3

wysoki

średni

niski

2

średni

niski

niski

0 – 1

16 i więcej niż 16

5 – 15

1 - 4

Liczba DET/FTR

Wysoki

wysoki

średni

4 i więcej niż 4

wysoki

średni

niski

2 – 3

średni

niski

niski

0 – 1

20 i więcej niż 20

6 - 19

1 - 5

Liczba DET/FTR

Wyliczanie nieuzgodnionych punktów funkcyjnych dla wszystkich funkcji transakcyjnych c.d.

Na podstawie wyznaczonego poziomu kompletności funkcjonalnej

możemy przypisać odpowiednią liczbę nieuzgodnionych punktów

funkcyjnych zgodnie z poniższymi zasadami:

Dla EI i EQ:

6

4

3

Liczba surowych punktów funkcyjnych

Wysoki

Średni

Niski

Poziom kompletności funkcjonalnej

Wyliczanie nieuzgodnionych punktów funkcyjnych dla wszystkich funkcji transakcyjnych c.d.

Dla EO:

7

5

4

Liczba surowych punktów funkcyjnych

Wysoki

Średni

Niski

Poziom kompletności funkcjonalnej

Obliczanie wartości współczynnika dopasowania wartości VAF

Aby otrzymać VAF (value adjustment factor) należy podjąć kroki:

- Oszacować każdą z 14 charakterystyk, wynik umieścić w skali od

1 do 5

- Obliczyć tzw. całkowity stopień wpływu TDI (total degree of

influence) dodając otrzymane w punkcie wyżej wyniki

- Obliczyć VAF wstawiając TDI do równania:

VAF = (TDI*0.01) + 0.65

Wyliczenie końcowej wartości punktów funkcyjnych

Ostatnim krokiem w analizie punktów funkcyjnych jest końcowe

obliczenie punktów funkcyjnych zależnie od typu liczenia

punktów funkcyjnych.

Do obliczenia całkowitej liczby punktów funkcyjnych należy użyć

wzoru:

DFP = (UFP + CFP) * VAF

gdzie:

Wyliczenie końcowej wartości punktów funkcyjnych c.d.

DFP (development function point count) – całkowita liczba

punktów funkcyjnych dla nowego projektu

UFP (unadjustemnt 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

VAF – współczynnik dopasowania wartości (omówiony wcześniej)

Wyliczenie końcowej wartości punktów funkcyjnych c.d.

W przypadku modyfikacji funkcjonalności aplikacji wzór na

końcowe obliczenie punktów funkcyjnych ma postać:

EFP = [(ADD + CHGA + CFP) * VAFA] + ( DEL * VAFB)

gdzie:

EFP – (enhancment project function point) – końcowa wartość

punktów funkcyjnych w wypadku modyfikacji funkcjonalności

aplikacji

Wyliczenie końcowej wartości punktów funkcyjnych c.d.

ADD – nieuzgodniona liczba punktów funkcyjnych

odzwierciedlająca te funkcje, które zostaną dodane w procesie

modyfikacji aplikacji

CHGA – nieuzgodniona liczba punktów funkcyjnych liczona dla

modyfikacji istniejących funkcji

CFP – omówione slajd wcześniej

VAFA – współczynnik dopasowania wartości, liczony po

modyfikacji aplikacji

DEL – nieuzgodniona liczba punktów funkcyjnych

odzwierciedlająca funkcjonalność elementów, które zostaną

usunięte w wyniku modyfikacji aplikacji

VFAB - współczynnik dopasowania wartości, liczony przed

modyfikacji aplikacji

Wyliczenie końcowej wartości punktów funkcyjnych c.d.

W przypadku obliczenie ilości punktów funkcyjnych dla pracującej

już aplikacji należy użyć wzoru:

AFP = AD * VAF

AFP – końcowa wartość punktów funkcyjnych

AD – nieuzgodniona liczba punktów funkcyjnych wynikająca z

funkcjonalności aplikacji, dostępnej już dla użytkownika

Końcowego

VAF – współczynnik dopasowania wartości liczony dla danej

aplikacji

Wyliczenie końcowej wartości punktów funkcyjnych c.d.

Aby oszacować funkcjonalność aplikacji po modyfikacji, należy

zastosować zależność:

AFP = [(UFPB + ADD + CHGA) – (CHGB + DEL)] * VAF

AFP – końcowa wartość punktów funkcyjnych

UFPB – nieuzgodniona liczba punktów funkcyjnych wynikająca z

funcjonalności aplikacji przed modyfikacją

ADD – nieuzgodniona liczba punktów funkcyjnych

odzwierciedlająca te funkcje, które zostaną dodane w procesie

modyfikacji aplikacji

CHGA – nieuzgodniona liczba punktów funkcyjnych liczona dla

modyfikacji istniejących funkcji

Wyliczenie końcowej wartości punktów funkcyjnych c.d.

CHGB – nieuzgodniona liczba punktów funkcyjnych wynikająca

z modyfikacji istniejących funkcji

DEL – nieuzgodniona liczba punktów funkcyjnych

odzwierciedlająca te funkcje, które zostaną usunięte w wyniku

modyfikacji aplikacji

VAFA – współczynnik dopasowania wartości, liczony po

przeprowadzonej modyfikacji aplikacji

Punkty funkcyjne a ilość linii kodu

Punkty funkcyjne mogą być przeliczane na linie kodu:

80

PL/I

91

COBOL 85

105

Fortran 77

107

COBOL

128

C

320

Asembler

Linie kodu na punkt funkcyjny

Język

Punkty funkcyjne a ilość linii kodu c.d.

35

Visual Basic

55

Java

55

Ada 95

56

C++

64

Prolog

70

Pascal

71

Ada

Linie kodu na punkt funkcyjny

Język

Zalety i wady FPA

Mocne strony FPA:

- FPA można stosować bez względu na język programowania

- FPA jest stosowana do szacowania całych systemów

informatycznych lub tylko ich poszczególnych modułów

- FPA może być używana do szacowania nowego oprogramowania

jak i w przypadku modernizacji już istniejącego

- Wiele narzędzi programistycznych szacujących koszty i inne

wskaźniki związane z realizacją projektów informatycznych

bazuje na FPA

Zalety i wady FPA c.d.

Wady FPA:

- Gwarancję poprawnego stosowania FPA i jej rezultatów dają

tylko certyfikowani specjaliści FPA

- Poprawne wyliczenie punktów funkcyjnych wymaga dużo czasu,

co za tym idzie jest dość kosztowne

- Problemy z automatyzacją obliczeń (nieznana ich dokładność)

- Rezultaty obliczeń FPA dla systemów o rozmiarze mniejszym niż

15 pkt. funkcyjnych mogą być niereprezentatywne

- Brak kohezji między standardem IFPUG a różnymi wersjami FPA

powstałymi na bazie standardu i rozwijającym się w różnych

kierunkach

Bibliografia

- Janusz Górski „Inżynieria oprogramowania w projekcie

informatycznym” wyd. Mikom, Warszawa 2000

Andrzej Jaszkiewicz „Inżynieria oprogramowania CASE”, wyd.

Helion, Gliwice 1997

- Ewa Magiera „Zastosowanie metody punktów funkcyjnych” -

abstrakt

- materiały ze strony: http://www.ifpug.eu.org

Leszek Krupiński

2004-01-05T18:46:14