Analiza Punktów Funkcyjnych Analiza Punktów Funkcyjnych
Autorzy:
Autorzy:
Filip Budziewicz
Michał Jaworski
Wstęp Wstęp
Najczęściej stosowaną miarą w szacowaniu i ocenie
oprogramowania jest obecnie metoda punktów funkcyjnych. metoda punktów funkcyjnych Opracowana przez A. J. Albrechta i innych pracowników firmy A. J. Albrechta IBM w połowie lat 70 – tych. Po kilku latach IBM zrzekł się IBM
wszelkich praw autorskich do metody FPA FPA i przekazał je do wspólnego użytku.
Powołano międzynarodową organizację użytkowników FPA
(IFPUG IFPUG – International Function Point User Group) z zarządem
w Westerville, Ohio, USA.
Zalety stosowania FPA.
Zalety stosowania FPA.
Rozwiązanie niezależne od stosowanego języka programowania,
FPA jest stosowane do szacowania całych systemów informatycznych lub tylko ich poszczególnych modułów,
Może być stosowane w dowolnym momencie cyklu życiowego oprogramowania,
Wiele obecnie wykorzystywanych narzędzi bazuje na
Główne wady FPA.
Główne wady FPA.
Poprawne wyliczenie punktów funkcyjnych jest czasochłonne i dość kosztowne,
Proces automatycznego obliczania punktów funkcyjnych nie jest na razie stosowany,
Ze względu na nie reprezentatywność wyników nie stosuje się FPA dla systemów o bardzo małym rozmiarze,
Brak konwersji między standardem IFPUG a innymi metodami opartymi na metodzie FPA,
Umiejscowienie centrów szkoleniowych i certyfikacyjnych IFPUG
Proces wyliczania Punktów Funkcyjnych.
Proces wyliczania Punktów Funkcyjnych.
1) Zdefiniowanie typu procesu liczenia punktów funkcyjnych, 2) Identyfikacja zakresu analizy oraz określenie granic aplikacji, 3) Wyliczenie liczby nieuzgodnionych punktów funkcyjnych dla
wszystkich ILF i EIF,
4) Wyliczenie liczby nie uzgodnionych punktów funkcyjnych dla wszystkich funkcji transakcyjnych – EI, EO, EQ,
5) Obliczenie współczynnika dopasowania wartości VAF,
6) Wyliczanie końcowej wartości punktów funkcyjnych,
1) Zdefiniowanie typu procesu liczenia punktów funkcyjnych.
1) Zdefiniowanie typu procesu liczenia punktów funkcyjnych.
Dla nowo powstających projektów,
W przypadku modyfikacji istniejącej aplikacji,
Pomiar istniejącej, pracującej aplikacji
2) Identyfikacja zakresu analizy oraz określenie granic aplikacji.
2) Identyfikacja zakresu analizy oraz określenie granic aplikacji.
Zakresem analizy jest funkcjonalność aplikacji
IFPUG definiuje trzy główne reguły wyznaczania granic aplikacji:
Wyznaczenie granicy aplikacji przez użytkownika,
Granice wynikają z funkcjonalności aplikacji,
Granica aplikacji jest niezależna od zakresu analizy
3) Wyliczenie liczby nieuzgodnionych punktów funkcyjnych dla 3) Wyliczenie liczby nieuzgodnionych punktów funkcyjnych dla
wszystkich ILF i EIF.
wszystkich ILF i EIF.
Na tym etapie wyróżniamy trzy punkty postępowania:
Identyfikacja logicznych zbiorów danych aplikacji (ILF i EIF),
Oszacowanie kompletności tych zbiorów,
Kalkulacje liczby nieuzgodnionych punktów funkcyjnych dla zbiorów danych (ILF i EIF)
ILF ILF (Internal Logical File) – Wymagane przez aplikację dane powiązane ze sobą logicznie. Często wprowadzane przez użytkownika. Dane te muszą pozostawać ze sobą w logicznym powiązaniu. Mogą być to też dane kontrolne do sterowania aplikacją.
Dane te są przechowywane w granicach danej aplikacji.
EIF EIF (External Interface File) – Dane te muszą tak jak ILF pozostawać w logicznym powiązaniu. Mogą być wymagane przez aplikację do działania lub mogą być
wprowadzane przez użytkownika albo być danymi kontrolnymi aplikacji. Dane te są
jednak przechowywane w granicach innej aplikacji.
3.1) Zależności ILF i EIF.
3.1) Zależności ILF i EIF.
Internal Logical File
Internal Logical File Granica aplikacji nr 1
Granica aplikacji nr 2
EIF jednej aplikacji musi być ILF’em w innej aplikacji ! EIF jednej aplikacji musi być ILF’em w innej aplikacji !
Internal Logical File External Interface File
3.2) Oszacowanie kompletności zbiorów (RET i DET).
3.2) Oszacowanie kompletności zbiorów (RET i DET).
Po zidentyfikowaniu ILF i EIF dla danej aplikacji należy wyznaczyć liczbę punktów RET i DET dla każdego ILF i EIF. Liczba elementów RET i DET decyduje o ilości nieuzgodnionych punktów funkcyjnych.
RETRET (Record Element Type) – podgrupa danych ILF lub EIF określana przez użytkownika.
Reguły wyznaczania RET:
Jest to każda podgrupa danych ILF lub EIF,
Jeśli niemożliwe jest wydzielenie takiej podgrupy jako RET traktowany jest cały ILF lub EIF
DETDET (Data Element Type) – jest to unikalne pole określane przez użytkownika aplikacji.
Reguły wyznaczania DET:
Jest to każde unikalna, definiowane przez użytkownika pole będące elementem ILF lub EIF,
Grupa danych umożliwiająca relację z innym ILF lub EIF powinna zostać policzona jako jeden element DET,
Jeśli więcej niż jedna aplikacja korzysta z tych samych ILF lub EIF ale każda z nich odwołuje się do nich inaczej to liczba DET wyznaczana jest oddzielnie dla każdej aplikacji
Aplikacja nr 1
Aplikacja nr 2 Blok danych adresowych
Kod pocztowy Ulica Miasto
3 DET
1 DET
3.2) Oszacowanie kompletności zbiorów (RET i DET) C.D.
3.2) Oszacowanie kompletności zbiorów (RET i DET) C.D.
Na podstawie ilości RET i DET dla każdego ILF lub EIF musimy oszacować poziom funkcjonalnej kompletności.
Liczba DET
RET 1 - 19 20 - 50 51 >
1 niski niski średni
2 - 5 niski średni wysoki
6 > średni wysoki wysoki
Po wyznaczeniu poziomu kompletności funkcjonalnej przypisujemy ILF i EIF odpowiednią liczbę
3.3)
3.3) Kalkulacje liczby nieuzgodnionych punktów Kalkulacje liczby nieuzgodnionych punktów funkcyjnych dla zbiorów danych (ILF i EIF).
funkcyjnych dla zbiorów danych (ILF i EIF).
Dla ILF:
Poziom kompletności funkcjonalnej Liczba surowych punktów funkcyjnych
niski 7
średni 10
wysoki 15
Dla EIF:
Poziom kompletności funkcjonalnej Liczba surowych punktów funkcyjnych
niski 5
średni 7
wysoki 10
Suma daje ilość nieuzgodnionych punktów funkcyjnych
4) Wyliczenie liczby nie uzgodnionych punktów 4) Wyliczenie liczby nie uzgodnionych punktów
funkcyjnych dla wszystkich funkcji transakcyjnych – EI, funkcyjnych dla wszystkich funkcji transakcyjnych – EI,
EO, EQ.
EO, EQ.
W tym punkcie zidentyfikujemy funkcje transakcyjne (EI, EO, EQ) i ich kompletność oraz wyliczymy liczbę surowych punktów funkcyjnych.
EI (External Inputs) – Wykorzystuje dane kontrolne które pochodzą z poza granicy aplikacji lub dane podawane przez użytkownika. Działanie EI sprowadza się do oddziaływania na jeden lub więcej ILF w którym dokonuje on zmian jego danych lub pobudza system do
konkretnego zachowania. Zaliczany jest do grupy procesów elementarnych.
EO (External Outputs) – Jest on wykorzystywany do przesyłania danych użytkownika lub danych kontrolnych poza granicę aplikacji. EO może również działać na jednym lub więcej ILF i dokonywać takich samych operacji jak EI. Jest również zaliczany do procesów
elementarnych.
EQ (External Inquiry) - Jest on wykorzystywany do przesyłania danych użytkownika lub danych kontrolnych poza granicę aplikacji. W trakcie działania EQ nie może dojść do modyfikacji ILF lub do zmiany zachowania systemu.
4) Wyliczenie liczby nie uzgodnionych punktów 4) Wyliczenie liczby nie uzgodnionych punktów
funkcyjnych dla wszystkich funkcji transakcyjnych – EI, funkcyjnych dla wszystkich funkcji transakcyjnych – EI,
EO, EQ C.D.
EO, EQ C.D.
Funkcja Transakcyjny typ funkcyjny
EI EO EQ
Zmiana zachowania systemu główny możliwy niedozwolony Modyfikacja jednego lub więcej ILF główny możliwy niedozwolony Prezentacja informacji użytkownikowi możliwy główny główny
Każdy proces elementarny musi być jednoznacznie określony i może być liczony tylko raz.
Każdy proces elementarny musi być jednoznacznie określony i może być liczony tylko raz.
Ciekawostki...
System operacyjny Microsoft Windows ‘95 zawiera około 100 tys. Punktów Funkcyjnych
4) Zależności EI, EO, EQ z ILF i EIF.
4) Zależności EI, EO, EQ z ILF i EIF.
Internal Logical File
Internal Logical File Granica aplikacji
Inna aplikacja External Inputs
External Outputs
External Inquiry
Plik transakcyjny
Plik transakcyjny Wprowadź
dane Wyświetl
dane
Wyświetl dane
4.1) Zależność EI, EO, EQ od liczby FTR i DET.
4.1) Zależność EI, EO, EQ od liczby FTR i DET.
Aby przypisać wszystkim EI, EO, EQ odpowiednie liczby punktów funkcyjnych musimy wyznaczyć liczbę FTR i do tego wynik porównać z wynikiem DET.
FTR (File Type Referenced) – jest to:
• każdy czytany lub modyfikowany EI, EO, EQ,
• EIF z którego czytane są informacje, FTR jest wyliczany jako:
• każdy modyfikowany ILF to jeden FTR,
• każdy czytany ILF i EIF to jeden FTR,
Na podstawie wartości FTR i DET szacujemy poziom funkcjonalnej kompletności dla EI, EO, EQ
zgodnie z poniższymi regułami.
4.2) Szacowanie poziomu funkcjonalnej kompletności dla 4.2) Szacowanie poziomu funkcjonalnej kompletności dla
EI, EO, EQ.
EI, EO, EQ.
Dla EI:
Liczba DET
FTR 1 - 4 5 - 15 16 >
0 – 1 niski niski średni
2 niski średni wysoki
3 > średni wysoki wysoki
Dla EO i EQ:
Liczba DET
FTR 1 - 5 6 - 19 20 >
0 – 1 niski niski średni
4.3) Przypisywanie odpowiedniej liczby nieuzgodnionych 4.3) Przypisywanie odpowiedniej liczby nieuzgodnionych
punktów funkcyjnych EI, EO, EQ.
punktów funkcyjnych EI, EO, EQ.
Poziom kompletności funkcjonalnej Liczba surowych punktów funkcyjnych
niski 3
średni 4
wysoki 6
Poziom kompletności funkcjonalnej Liczba surowych punktów funkcyjnych
niski 4
średni 5
wysoki 7
Dla EI i EQ:
Dla EO:
5) Obliczenie współczynnika dopasowania wartości VAF 5) Obliczenie współczynnika dopasowania wartości VAF
Współczynnik VAF (Value Adjustment Factor) – współczynnik dopasowania wartości jest obliczany na podstawie odpowiedzi na 14 pytań charakteryzujących aplikacje.
lp. Ogólne charakterystyki systemu
1 Przesł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
5.1) Obliczenie współczynnika dopasowania wartości VAF 5.1) Obliczenie współczynnika dopasowania wartości VAF C.D. C.D.
Aby otrzymać wartość VAF należy wykonać poniższe kroki:
• każdą z 14 charakterystyk oszacuj wartością z przedziału 1 – 5 co odpowiada określeniu tzw. stopnia wpływu DI (Degree of Influence),
• sumuje my wszystkie wyniki DI i otrzymujemy tzw. całkowity stopień wpływu TDI (Total Degree of Influence),
• obliczamy VAF podstawiając TDI do równania:
VAF = (TDI * 0.01) + 0.65
VAF = (TDI * 0.01) + 0.65
6) Wyliczanie końcowej wartości punktów funkcyjnych 6) Wyliczanie końcowej wartości punktów funkcyjnych
Poniższy wzór ma zastosowanie tylko dla nowopowstającej aplikacji Poniższy wzór ma zastosowanie tylko dla nowopowstającej aplikacji
DFP = (UFP + CFP) * VAF DFP = (UFP + CFP) * VAF
Gdzie:
• DFP (Developement 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,
6.1) Wyliczanie końcowej wartości punktów funkcyjnych 6.1) Wyliczanie końcowej wartości punktów funkcyjnych C.D. C.D.
Poniższy wzór ma zastosowanie tylko dla modyfikacji funkcjonalności aplikacji Poniższy wzór ma zastosowanie tylko dla modyfikacji funkcjonalności aplikacji
EFP = [(ADD + CHGA + CFP) * VAFA] + (DEL * VAFB) EFP = [(ADD + CHGA + CFP) * VAFA] + (DEL * VAFB)
Gdzie:
• EFP (Enhancement Project Function Point) – końcowa wartość punktów funkcyjnych w przypadku modyfikacji funkcjonalności aplikacji,
• 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,
• VAFA (Value Adjustment Factor After) – współczynnik dopasowania wartości liczony po
modyfikacji aplikacji,• DEL - nieuzgodniona liczba punktów funkcyjnych odzwierciedlająca te funkcje które zostaną
usunięte w procesie modyfikacji aplikacji,• VAFB (Value Adjustment Factor Before) – współczynnik dopasowania wartości liczony przed
modyfikacją aplikacji,6.2) Wyliczanie końcowej wartości punktów funkcyjnych 6.2) Wyliczanie końcowej wartości punktów funkcyjnych C.D. C.D.
Poniższy wzór ma zastosowanie tylko dla pracującej aplikacji Poniższy wzór ma zastosowanie tylko dla pracującej aplikacji
AFP = AD * VAF AFP = AD * VAF
Gdzie:
• AFP – (Aplication Function Point) – końcowa wartość punktów funkcyjnych,
• AD - nieuzgodniona liczba punktów funkcyjnych wynikająca z funkcjonalności aplikacji,
6.3) Wyliczanie końcowej wartości punktów funkcyjnych 6.3) Wyliczanie końcowej wartości punktów funkcyjnych C.D. C.D.
Poniższy wzór ma zastosowanie tylko dla aplikacji po modyfikacji Poniższy wzór ma zastosowanie tylko dla aplikacji po modyfikacji
AFP = [(UFBP + ADD + CHGA) – (CHGB + DEL)] * VAF AFP = [(UFBP + ADD + CHGA) – (CHGB + DEL)] * VAF
Gdzie:
• UFPB (Unadjusted Function Point Count Before) - nieuzgodniona liczba punktów funkcyjnych wynikająca z funkcjonalności aplikacji, przed modyfikacją,
• CHGB - nieuzgodniona liczba punktów funkcyjnych wynikająca z modyfikacji istniejących
funkcji,
Wykorzystanie FPA w praktyce – opis systemu Wykorzystanie FPA w praktyce – opis systemu
Charakterystyka systemu na przykładzie, którego pokażemy wykorzystanie FPA w prkatyce:
(System stworzony przez Romana Budzowskiego, Uniwersytet Szczeciński)
ePlan ePlan
Obserwując problemy związane z układaniem planu zajęć oraz z wprowadzaniem do niego
kolejnych poprawek i publikowaniem tych informacji powstał pomysł stworzenia narzędzi sużących do wspomagania procesu tworzenia i publikacji planu zajęć. W projekcie tym założyłem powstanie dwóch niezależnych od siebie aplikacji. Jedna, stworzona w Delphi wspiera proces układania planu (zasilanie bazy danych) oraz tworzenia wydruków umieszczanych przy dziekanacie. Wadą tych wydruków jest mała czytelność, jako że na jednym wydruku umieszczony jest plan dla całego roku (5-7 grup dziekańskich). Druga aplikacja, napisana w PHP odpowiada za wyświetlanie w
przeglądarce internetowej planu zajęć dla wybranej grupy (podgrupy), prowadzącego czy sali.
Zaletą tego rozwiązania jest uzyskanie tylko potrzebnych nam informacji. Jako system do przechowywania danych został wykorzystany serwer MySQL. Aplikację internetową można zobaczyć pod adresem:
Szacowanie rozmiaru plików logicznych Szacowanie rozmiaru plików logicznych
Tworzenie aplikacji (internetowej czy tradycyjnej) wykorzystującej do przechowywania danych serwer baz danych powoduje, że mamy w takim przypadku do czynienia z tylko jednym plikiem logicznym (dla jednej bazy danych). Relacyjna baza danych składa się z tabel. Tabele
przechowywane w bazie danych traktujemy jak elementy typu rekord (RET). Tabele składają się z pól, które traktujemy jako elementy typu dane (DET). W opisywanych liczba RET i DET
kształtowała się następująco:
RET DET
ePlan 8 37
Szacowanie rozmiaru transakcji Szacowanie rozmiaru transakcji
Liczba transakcji w przypadku korzystania z baz danych przesądzać będzie o rozmiarze systemu.
Oto charakterystyka transakcji dla obu systemów:
Wyjścia Wejścia Zapytania
Proste 6 3 1
Średnie - - -
Złożone - - -
Szacowanie ogólnej charakterystyki systemu Szacowanie ogólnej charakterystyki systemu
IFPUG wyodrębnił 14 czynników pozwalających na określenie ogólnej charakterystyki systemu. Każdemu z nich można przypisać wagę od 0 (brak wpływu) do 5 (silny wpływ). Wagi te wykorzystuje się do obliczenia współczynnika
skorygowania. Poniżej skupię się na podaniu cech charakterystycznych dla aplikacji internetowych.
lp. Ogólne charakterystyki systemu ePlan
1 Przesłanie danych 3
2 Przetwarzanie rozproszone 3
3 Wydajność 3
4 Obciążenie platformy sprzętowej 2
5 Stopa transakcji 3
6 Wprowadzanie danych on-line 1
7 Wydajność użytkownika końcowego 2
8 Aktualizacja on-line 0
9 Przetwarzanie złożone 2
10 Wielokrotna używalność 2
11 Łatwość instalacji 1
12 Łatwość obsługi 0
13 Wielokrotna lokalizacja 3
14 Łatwość wprowadzania zmian 1
