Punkty funkcyjne

To takie proste

•Wejścia użytkownika: obiekty wejściowe wpływających na
dane w systemie
•Wyjścia użytkownika: obiekty wyjściowe związane z danymi
w systemie
•Zbiory danych wewnętrzne: liczba wewnętrznych plików
roboczych.
•Zbiory danych zewnętrzne: liczba plików zewnętrznych
zapełnianych przez produkt programowy
•Zapytania zewnętrzne: interfejsy z otoczeniem programu

Analiza Punktów Funkcyjnych

Metoda analizy punktów funkcyjnych (FPA), opracowana przez
Albrechta w latach 1979-1983 bada pewien zestaw wartości.
Łączy ona własności metody, badającej rozmiar projektu
programu z możliwościami metody badającej produkt
programowy.

Liczbę nie skorygowanych punktów funkcyjnych wylicza się na
podstawie formuły korzystając z następujących danych:

Schemat aplikacji

3. Czarnecka-Chrobot Beata „Metoda

punktów funkcyjnych – bieżące standardy”

Schemat obliczania PF

• występowanie urządzeń

komunikacyjnych

• rozproszenie przetwarzania
• długość czasu oczekiwania

na odpowiedź systemu

• stopień obciążenia sprzętu

istniejącego

• częstotliwość wykonywania

dużych transakcji

• wprowadzanie danych w

trybie bezpośrednim

• wydajność użytkownika

końcowego

• aktualizacja danych w

trybie bezpośrednim

• złożoność przetwarzania

danych

• możliwość ponownego

użycia programów w innych
zastosowaniach

• łatwość instalacji
• łatwość obsługi systemu
• rozproszenie terytorialne
• łatwość wprowadzania

zmian - pielęgnowania
systemu

Korekcja Punktów

Funkcyjnych

VAF

k

k

k







1

14

VAF

k

k

k







1

14

FP

VAF UFP









( ,

,

)

065 001

FP

VAF UFP









( ,

,

)

065 001

kompleksowy współczynnik
korygujący

Punkty funkcyjne (FPs):

FP

UFP





( , .... , )

065 135

FP

UFP





( , .... , )

065 135

0

5

4

3

2

1

Wpływ

czynnika

Bez

wpływu

Bardzo

silny wpływ

Skorygowane Punkty

Funkcyjne

Kolejność obliczeń Punktów

Funkcyjnych

Identyfikacja systemu
Obliczenie współczynnika korygującego
Wyznaczenie ilości zbiorów danych i ich

złożoności
Wyznaczenie ilości i złożoności elementów

funkcjonalnych (we, wy, zapytania)
Realizacja obliczeń
Weryfikacja
Raport, zebranie recenzujące

Aplikacje a Punkty

Funkcyjne

1 FP  125 instrukcji w C
10 FPs - typowy mały program tworzony samodzielnie

przez klienta (1 m-c)

100 FPs - większość popularnych aplikacji; wartość

typowa dla aplikacji tworzonych przez klienta
samodzielnie (6 m-cy)

1,000 FPs - komercyjne aplikacje w MS Windows, małe

aplikacje klient-serwer (10 osób, ponad 12 m-cy)

10,000 FPs - systemy (100 osób, ponad 18 m-cy)
100,000 FPs - MS Windows’95, MVS, systemy militarne

Punkty Funkcyjne a

pracochłonność

Wykorzystanie punktów

funkcyjnych

Ocena złożoności realizacji systemów

Audyt projektów

Wybór systemów informatycznych funkcjonujących w
przedsiębiorstwie do reinżynierii (wg. koszt utrzymania/FPs)

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

Punkty Funkcyjne a języki

baz danych

wg. Software Productivity Research

Typ języka lub
konkretny język

Access
ANSI SQL
CLARION
CA Clipper
dBase III
dBase IV
DELPHI
FOXPRO 2.5
INFORMIX
MAGIC
ORACLE
Oracle Developer 2000
PROGRESS v.4
SYBASE

Poziom języka

wg. SPR

8.5
25.0
5.5
17.0
8.0
9.0
11.0
9.5
8.0
15.0
8.0
14.0
9.0
8.0

Efektywność

LOC/FP

38
13
58
19
40
36
29
34
40
21
40
23
36
40

wg. Software Productivity Research

Poziom języka

wg. SPR

1 - 3
4 - 8
9 - 15
16 - 23
24 - 55

>55

Średnia produktywność

FPs/osobomiesiąc

5 - 10
10 - 20
16 - 23
15 - 30
30 - 50
40 - 100

Punkty Funkcyjne a

wydajność zespołu

Mocne strony stosowania FPA wg. Capers

Jones’a :

• FPA jest stosowana bez względu na używany

język programowania.

• FPA jest stosowana do szacowania całych

systemów

informatycznych

lub

tylko

ich

poszczególnych modułów.

• FPA jest stosowana do szacowania nowego

softwaru jak i w przypadku modernizacji już
pracującego.

• Wiele narzędzi programistycznych szacujących

koszty i inne wskaźniki związane z realizacją
projektów informatycznych bazuje na FPA.

Główne wady FPA to:

• Gwarancję osiągnięcia poprawnych rezultatów dają

certyfikowani specjaliści FPA.

• Poprawne wyliczenie punktów funkcyjnych wymaga

również dużo czasu, a co za tym idzie jest dość

kosztowne.

• Automatyzacja procesu obliczenia punktów funkcyjnych

może być obciążona nieznaną dokładnością, jak na razie

nie jest stosowana.

• Rezultaty obliczeń FPA w wypadku systemów o rozmiarze

mniejszym niż 15 punktów funkcyjnych mogą być

niereprezentatywne.

• Brak powiązań (konwersji) pomiędzy standardem IFPUG i

różnymi wersjami FPA, które powstały na bazie

standardu, jednak rozwijają się w różny sposób i w

różnych kierunkach.

FPA - Zdefiniowanie typu procesu

liczenia punktów funkcyjnych – krok 1

• Pierwszy 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.

• Drugi

dotyczy

przypadku

modyfikacji

istniejącej aplikacji, polegającej na zmianie

funkcjonalności, tzn. usunięcie niektórych

funkcji, zmiana lub dodanie nowych.

• Trzeci to pomiar istniejącej, pracującej

aplikacji.

FPA - Identyfikacja zakresu analizy oraz

określenie granic aplikacji – krok 2

• Wyznaczona granica wynika głównie z punktu

widzenia i potrzeb użytkownika, tzn. użytkownik

powinien zdefiniować zakres aplikacji, jej

biznesową i użytkową funkcjonalność.

• Granice pomiędzy współpracującymi aplikacjami

winny wynikać z ich funkcjonalności a nie z

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 odpowiednio rozszerzenie lub

redukcję granicy aplikacji.

FPA - Wyliczenie liczby

nieskorygowanych punktów

funkcyjnych dla wszystkich ILF i EIF –

krok 3

• Na etapie tym należy zidentyfikować wszystkie

logiczne zbiory danych aplikacji (ILF ang. internal

logical files oraz EIF ang. external logical files)

oraz oszacować ich kompletność. Następnie

wyliczyć

liczbę

nieskorygowanych

punktów

funkcyjnych dla wszystkich ILF i EIF.

• Po zidentyfikowaniu wszystkich ILF i EIF dla

każdego z nich należy wyznaczyć wszystkie tzw.

RET’y (ang. record element type) i DET’y (ang.

data element type) , których liczba decyduje o

ilości nieskorygowanych punktów funkcyjnych.

ILFy (ang. Internal Logical File) to logiczne zbiory

danych, wymaganych, określonych przez użytkownika
lub danych kontrolnych utrzymywanych i działających w
granicach aplikacji. ILF najczęściej odpowiada encji w
drugiej lub trzeciej postaci normalnej lub nazwie
nadanej grupie powiązanych logicznie danych na
diagramach przepływów. Poprzez dane kontrolne
rozumie się dane niezbędne do sterowania procesami
aplikacji.

EIF (ang. External Interface File), czyli zewnętrzny zbiór

danych, to grupy logicznie powiązanych danych,
określone przez użytkownika lub dane kontrolne
odnoszące się do wymiarowanej aplikacji, ale
przechowywane w granicach innej aplikacji.

Do wyznaczania EIFów stosuje się następujące zasady:
1. dane lub informacje kontrolne, tworzące logiczną grupę

danych i jednoznacznie identyfikowalne przez użytkownika,

2. grupa danych, która przekracza granice wymiarowanej

aplikacji,

3. grupa danych, która nie jest utrzymywana w granicach

mierzonej aplikacji,

4. grupa danych, która jest ILFem w innej aplikacji.

FPA - krok 3 – Wyznaczenie DET’ów i

RET’ów

RET (a record element type) to podgrupa danych w ILF lub EIF,

określona przez użytkownika, może być opcjonalna lub obowiązkowa.

Reguły wyznaczania RET:
       Licz jako RET każdą podgrupę danych ILF’a lub EIF’a.
       Jeśli nie można wydzielić żadnych podgrup należy każdy ILF i EIF policzyć jako jeden RET.

DET (a data element type) to unikalne, określone przez użytkownika, nie

powtarzające się pole.

Reguły obliczania DET:
 Jako DET należy liczyć każde unikalne, zidentyfikowane przez użytkownika pole, będące elementem

ILF’a lub EIF’a.

  Jeśli dwie aplikacje korzystają z tych samych ILF lub EIF ale odwołują się inaczej do podgrup danych,

to liczbę DET należy liczyć stosownie do każdej aplikacji. Na przykład: jedna aplikacja wykorzystuje

następującą grupę danych adresowych: kod pocztowy, miasto, ulica, nr domu, telefon, natomiast

druga aplikacja odnosi się do tych danych jako do bloku, bez rozróżnienia poszczególnych pól. W

pierwszym przypadku przypiszemy odpowiedniemu ILF - 5 DET, w drugim 1 DET.

  Każda grupa danych, która umożliwia relację z innym ILF lub EIF musi zostać policzony jako jeden

DET.

 

FPA – krok 3 - Na podstawie wyznaczonej liczby RET i DET dla
każdego ILF i EIF szacuje się poziom funkcjonalnej
kompletności zgodnie z poniższymi:

 

Liczba
DET
RET

1-19

20-50

51 i więcej niż 51

1

niski

niski

średni

2-5

niski

średni

wysoki

6 i więcej niż 6

średni

wysoki

wysoki

FPA- krok 3 -Przypisanie odpowiedniej liczbę

nieskorygowanych punktów funkcyjnych zgodnie z

poniższymi zasadami, dla ILF i EIF:

 

Poziomu

złożoności

funkcjonalnej

Liczba

nieskorygowanyc

h punktów

funkcyjnych dla

ILF

Liczba

nieskorygowanyc

h punktów

funkcyjnych dla

EIF

niski

7

5

średni

10

7

wysoki

15

10

FPA - Wyliczenie liczby nieskorygowanych

punktów funkcyjnych dla wszystkich funkcji

tranzakcyjnych - krok 4

Identyfikacja funkcji transakcyjnych:

• EI (external inputs) – to proces elementarny,

któremu poddawane są dane lub dane kontrolne

przychodzące spoza granic aplikacji.

• EO (external outputs) – to proces elementarny,

który wysyła dane lub dane kontrolne poza

granice aplikacji.

• EQ (external query) – to proces elementarny,

który wysyła dane lub dane kontrolne poza

granice aplikacji.

Każdy proces elementarny musi być jednoznacznie

sklasyfikowany i może być liczony tylko raz.

FPA - krok 4

Identyfikacja EI,EO,EQ – określenie typów funkcjonalnych

procesów elementarnych.

Funkcja

:

Transakcyjny typ funkcyjny:

EI

EO

EQ

Zmiana

zachowania

systemu.

główn

y

możliwy

niedozwolo

ny

Modyfikacja

jednego

lub więcej ILF

główn

y

możliwy

niedozwolo

ny

Prezentacja informacji
użytkownikowi

możliw

y

główny

główny

FPA - krok 4 – określenie DET’ów i FTR’ów

• Przypisanie funkcji transakcyjnej odpowiedniej

ilości punktów funkcyjnych zależy od ilości
przypisanych funkcji FTR oraz DET.

FTR (ang. File Type Refeneced) to ILF czytany

lub modyfikowany przez funkcję transakcyjną lub
EIF, z którego czytane są dane. Każdy
modyfikowany lub czytany ILF lub czytany EIF jest
liczony jako 1 FTR. Jeden plik danych może być
liczony tylko raz.

FPA - krok 4 – poziom funkcjonalnej

kompletności dla EI w zależności od liczby FTR

i DET:

Liczba DET

FTR

1-4

5-15

16 i

więcej

niż 16

0-1

Niski

Niski

Średni

2

Niski

Średni Wysok

i

3 i więcej

niż 3

Średn

i

Wysoki Wysok

i

FPA - krok 4 – poziom funkcjonalnej

kompletności dla EO i EQ w zależności od

liczby FTR i DET:

Liczba DET

FTR

1-5

6-19

20 i

więcej

niż 20

0-1

Niski

Niski

Średni

2-3

Niski

Średni Wysok

i

4 i więcej

niż 4

Średn

i

Wysoki Wysok

i

FPA - Wyliczenie liczby nieskorygowanych

punktów funkcyjnych dla wszystkich funkcji

transakcyjnych dla EI, EQ i EO - krok 4

Poziomu

złożoności

funkcjonalnej

Liczba

nieskorygowanych

punktów

funkcyjnych dla EI

i EQ

Liczba

nieskorygowanych

punktów

funkcyjnych dla

EO

niski

3

4

średni

4

5

wysoki

6

7

FPA - Obliczenie współczynnika dopasowania

wartości VAF (ang. the value adjustment

factor) – krok 5.

• Oszacuj każdą z 14 charakterystyk,

wynik należy umieścić na skali o

zakresie od 0 do 5, co odpowiada

określeniu tzw. stopnia wływu DI (ang.

the degree of influence).

• Oblicz całkowity stopień wpływu TDI

(ang. the total degree of influence)

dodając otrzymane w punkcie 1 wyniki.

• Oblicz VAF wstawiając TDI do równania:

• VAF=(TDI*0.01)+0.65

Komunikacja

Charakterystyka określa wykorzystanie przez aplikację różnych

protokołów komunikacyjnych.

0

Aplikacja jest czysto wsadowa albo działa na jednym

komputerze.

1

Aplikacja jest wsadowa, ale wykorzystuje zdalne

wprowadzanie danych lub zdalne drukowanie.

2

Aplikacja jest wsadowa, ale wykorzystuje zdalne

wprowadzanie danych i zdalne drukowanie.

3

Aplikacja posiada „front-end” do przetwarzania wsadowego

oraz wprowadzania danych „on-line”.

4

Aplikacja jest więcej niż „front-endem” i wykorzystuje tylko

jeden protokół komunikacyjny.

5

Aplikacja jest więcej niż „front-endem” i wykorzystuje wiele

protokołów komunikacyjnych.

Przetwarzanie rozproszone

Charakterystyka określa w jakim stopniu następuje wymiana danych pomiędzy komponentami systemu.

0

Aplikacja jest monolityczna.

1

Aplikacja przygotowuje dane dla przetwarzania przez użytkownika w innych komponentach systemu,
np. bazie danych albo arkuszu kalkulacyjnym.

2

Dane są przygotowywane do transferu, a następnie przesyłane pod kontrolą aplikacji do innego
systemu (nie dla użytkownika końcowego).

3

Występuje przetwarzanie rozproszone „on-line” jednokierunkowe.

4

Występuje przetwarzanie rozproszone „on-line” dwukierunkowe.

5

Funkcje przetwarzania dynamicznie wykorzystują najodpowiedniejsze rozproszone komponenty
systemu.

Wydajność

Charakterystyka określa wpływ czasu odpowiedzi systemu i przepustowości na proces tworzenia aplikacji.

0 Nie ma specjalnych wymagań odnośnie wydajności.

1

Wymagania odnośnie wydajności zostały postawione, lecz nie były potrzebne dodatkowe działania w
trakcie tworzenia aplikacji.

2

Czas odpowiedzi i przepustowość są krytyczne jedynie w godzinach szczytu. Nieprzekraczalny termin
zakończenia przetwarzania przypada na następny dzień roboczy.

3

Czas odpowiedzi i przepustowość są krytyczne w codziennych godzinach pracy. Projekt musi jednak
wziąć pod uwagę uwarunkowane czasowo interfejsy.

4

Dodatkowo wymagania wydajnościowe użytkownika są dostatecznie wysokie, by spowodować
konieczność wykonania analizy wydajności systemu w fazie projektowej.

5

Dodatkowo proces tworzenia aplikacji wymaga użycia specjalnych narzędzi do projektowania i
implementacji systemu o dużej wydajności.

Specjalne wymagania odnośnie konfiguracji

Charakterystyka określa wpływ ograniczeń dotyczących zasobów sprzętowych na tworzenie aplikacji.

0 Nie ma jawnych lub niejawnych ograniczeń odnośnie konfiguracji.

1

Istnieją ograniczenia operacyjne, lecz są mniej restrykcyjne niż dla typowych aplikacji. Spełnienie
wymagań nie wymaga dodatkowych działań.

2 Aplikacja wymaga uwzględnienia czynników czasowych lub dotyczących bezpieczeństwa.

3 Istnieją specyficzne lub nadzwyczajne wymagania odnośnie procesora dla części aplikacji.

4 Wymagane są specjalne ograniczenia dla aplikacji działającej na głównym procesorze.

5 Dodatkowo istnieją dodatkowe ograniczenia dla aplikacji w rozproszonych komponentach.

Tempo transakcji

Określa wpływ tempa transakcji biznesowych na tworzenie aplikacji.

0 Nie przewiduje się spiętrzenia liczby transakcji.

1

Przewiduje się spiętrzenie liczby transakcji występujące okresowo.

2 Przewiduje się spiętrzenie tygodniowe.

3 Przewiduje się spiętrzenie dzienne.

4

Wysokie tempo transakcji jest jednym z wymagań. Niezbędna jest analiza wydajnościowa w fazie
projektowania.

5

Jak wyżej i dodatkowo niezbędne są narzędzia do analizy wydajności w fazie projektowania, produkcji i/lub
instalacji.

Wprowadzanie danych „on-line”

Określa wpływ ilości interaktywnych transakcji wprowadzania danych na tworzenie
aplikacji.

0 Wszystkie transakcje są przetwarzane wsadowo.
1 1%-7% transakcji odbywa się w trybie interaktywnego wprowadzania danych.
2 8%-15% transakcji odbywa się w trybie interaktywnego wprowadzania danych.
3 16%-23% transakcji odbywa się w trybie interaktywnego wprowadzania danych.
4 24%-30% transakcji odbywa się w trybie interaktywnego wprowadzania danych.

5

Ponad 30% transakcji odbywa się w trybie interaktywnego wprowadzania
danych.

Specjalne ułatwienia dla Użytkownika

Określa wpływ czynników ludzkich i wymagań dotyczących wygody użytkownika na tworzenie aplikacji. Pod uwagę bierze się:

a.

Ułatwienia nawigacji

b.

Menu

c.

Pomoc i dokumentację on-line

d.

Przewijanie ekranu

e.

Zdalne drukowanie (obsługa drukarki sieciowej)

f.

Klawisze skrótu

g.

Wywoływanie przetwarzania wsadowego z transakcji on-line

h.

Wybieranie pól danych przez ustawianie kursora (niesekwencyjne wprowadzanie danych)

i.

Duże użycie wideo, podświetlania, kolorów itp.

j.

Drukowanie elektronicznej dokumentacji użytkownika

k.

Mysz

l.

Wyskakujące okna

m.

Optymalizacja liczby otwartych okien

n.

Wspomaganie dwu języków (liczyć jako 4)

o.

Wspomaganie wielu języków (liczyć jako 6)

p.

Automatyczne przenoszenie kursora

Stopień wpływu

0

Żadna z powyższych cech.

1

1 do 3 cech.

2

4 do 5 cech.

3

6 lub więcej, nie ma jednak specyficznych wymagań co do ułatwień.

4

Jak wyżej oraz podane są wymagania odnośnie interfejsu użytkownika, wymuszające projektowanie
pod tym kątem.

5

Jak wyżej i ponadto potrzebne są specjalne narzędzia oraz procesy, które pokażą, że osiągnięto cel.

Modyfikacje „on-line”

Określa wpływ modyfikacji wewnętrznych zbiorów danych na tworzenie aplikacji.

0

Brak.

1

Aktualizacja „on-line” jest dokonywana dla jednego do trzech zbiorów. Obszar aktualizacji nie jest duży, a odtworzenie

poprzedniego stanu jest łatwe.

2

Aktualizacja „on-line” jest dokonywana dla czterech lub więcej zbiorów. Obszar aktualizacji nie jest duży, a odtworzenie
poprzedniego stanu jest łatwe.

3

Aplikacja umożliwia aktualizację „on-line” wszystkich podstawowych zbiorów.

4

Dodatkowo niezbędne jest zabezpieczenie przed utratą danych, które musi być specjalnie zaprojektowane i
oprogramowane w systemie.

5

Dodatkowo duże i rozległe aktualizacje powodują, że w projekcie aplikacji rozważa się koszty odtwarzania stanu

poprzedniego po skasowanej aktualizacji. Niezbędny jest proces odtwarzania w pełni zautomatyzowany i wymagający
minimalnej inwencji operatora.

Złożone przetwarzanie

Określa wpływ logiki przetwarzania na tworzenie aplikacji. Rozważane są:

a.

Specjalne procedury bezpieczeństwa.

b.

Złożone logiczne przetwarzanie.

c.

Złożone przetwarzanie matematyczne.

d.

Rozbudowana obsługa wyjątków, związana z ponownym przetwarzaniem niekompletnych transakcji.

e.

Złożone przetwarzanie do obsługi wielu wariantów wejścia/wyjścia (np. multimedia, niezależność od urządzeń wejściowych).

Stopień wpływu

0

Żaden element złożoności nie występuje.

1

Jeden z wymienionych.

2

Dwa z wymienionych.

3

Trzy z wymienionych.

4

Cztery z wymienionych.

5

Wszystkie wymienione elementy.

Wielokrotne wykorzystywanie

Określa w jakim stopniu aplikacja została zaprojektowana i oprogramowana w celu ponownego użycia jej
fragmentów w innym oprogramowaniu.

0

Kod nie jest przeznaczony do wielokrotnego użycia.

1

Wielokrotnie wykorzystywany kod jest częścią aplikacji.

2

Mniej niż 10% aplikacji jest zbudowane z kodu wielokrotnego użycia.

3

10% lub więcej aplikacji jest zbudowane z kodu wielokrotnego użycia.

4

Aplikacja została specjalnie zaprojektowana jako aplikacja wielokrotnego użycia i dokonuje się jej
dostosowania dla każdego indywidualnego klienta.

5

Jak powyżej, dostosowania może dokonać użytkownik poprzez parametryzację.

Łatwość instalacji

Określa czy i w jakim stopniu konwersja z poprzedniego środowiska wpływa na tworzenie aplikacji.

0

Nie ma żadnych wymagań użytkownika i nie są konieczne żadne ułatwienia instalacyjne.

1

Użytkownik nie stawiał wymagań odnośnie łatwości instalacji, jednakże procedura instalacyjna jest
potrzebna.

2

Wymagania odnośnie instalacji zostały przedstawione i w związku z tym powstały odpowiednie
procedury instalacyjne wraz z dokumentacją, testami i podręcznikiem. Wpływ tych procedur na
projekt aplikacji nie jest istotny.

3

Wymagania odnośnie instalacji zostały przedstawione i w związku z tym powstały odpowiednie
procedury instalacyjne wraz z dokumentacją, testami i podręcznikiem. Wpływ tych procedur na
projekt aplikacji jest znaczący.

4

Jak wyżej dla punktu 2 i ponadto dostarcza się automatyczne narzędzia instalacyjne wraz z
testami.

5

Jak wyżej dla punktu 3 i ponadto dostarcza się automatyczne narzędzia instalacyjne wraz z
testami.

Łatwość operowania

Określa wpływ na tworzenie aplikacji takich aspektów jak kopie zapasowe, odtwarzanie systemu.

0 Nie ma wymagań oprócz standardowego backupu.

1
-
4

Jedna lub kilka następujących cech zostały zaimplementowane w aplikacji. Wybieramy wszystkie
zaimplementowane. Każda cecha to jeden punkt (chyba, że zaznaczono inaczej):

Sprawny i szybki rozruch aplikacji, backup i odtwarzanie po awarii są implementowane, ale wymagają

interwencji administratora (operatora).

Sprawny i szybki rozruch aplikacji, backup i odtwarzanie po awarii są implementowane i nie

wymagają interwencji administratora (liczyć jako 2).

Aplikacja minimalizuje konieczność zastosowania taśm, dysków itp.

Aplikacja minimalizuje konieczność użycia papieru.

5

Aplikacja została zaprojektowana do pracy bez specjalnego nadzoru operatora. Istnieją procedury
automatycznego odtwarzania po awarii.

Wiele miejsc przetwarzania

Określa, w jakim stopniu aplikacja została zaprojektowana do działania na wielu stanowiskach.

0

Wymagania użytkownika nie zawierają informacji o konieczności instalacji więcej niż jednego
stanowiska aplikacji.

1

Uwzględniono w projekcie potrzebę instalacji w wielu miejscach, jednakże wszystkich instalacji
dokonuje się na identycznym sprzęcie i środowisku operacyjnym.

2

Uwzględniono w projekcie potrzebę instalacji w wielu miejscach, jednakże wszystkich instalacji
dokonuje się na podobnym sprzęcie i podobnym środowisku operacyjnym.

3

Uwzględniono w projekcie potrzebę instalacji w wielu miejscach, aplikacja jest zaprojektowana do
działania na różnym sprzęcie i/lub różnych środowiskach operacyjnych.

4

Aplikacja jest taka jak opisano dla 1 lub 2 i ponadto opracowana jest specjalna dokumentacja
instalacyjna oraz dostarcza się z aplikacją testy sprawdzające poprawność instalacji w wielu miejscach.

5

Aplikacja jest taka jak opisano dla 3 i ponadto opracowana jest specjalna dokumentacja instalacyjna
oraz dostarcza się z aplikacją testy sprawdzające poprawność instalacji w wielu miejscach.

Ułatwienia dla zmienności i elastyczności

Określa możliwość łatwej modyfikacji logiki przetwarzania lub struktury danych aplikacji. Pod uwagę
brane są następujące elementy:

a.

Elastyczne zapytania i raporty umożliwiają użytkownikowi tworzenie prostych kwerend (np.
możliwość użycia operatora i/lub do pojedynczego wewnętrznego zbioru logicznego).

b.

Elastyczne zapytania i raporty umożliwiają użytkownikowi tworzenie kwerend o średniej złożoności
(np. możliwość użycia operatora i/lub w zapytaniach kierowanych do kilku wewnętrznych plików
logicznych) (liczone jako 2).

c.

Elastyczne zapytania i raporty umożliwiają użytkownikowi tworzenie kwerend o dużej złożoności
(np. możliwość użycia kombinacji operatorów i/lub w zapytaniach kierowanych do jednego lub kilku
wewnętrznych zbiorów logicznych) (liczone jako 3).

d.

Biznesowe informacje sterujące są przechowywane w tabelach dostępnych użytkownikowi.
Użytkownik może zmieniać te parametry, jednakże zmiany wpływają na działanie systemu od
następnego dnia.

e.

Biznesowe informacje sterujące są przechowywane w tabelach dostępnych użytkownikowi.
Użytkownik może zmieniać te parametry, efekt tych zmian nastąpi dynamicznie natychmiast po ich
wprowadzeniu. (liczone jako 2)

Stopień wpływu

0

Aplikacja nie posiada żadnej z wymienionych charakterystyk.

1

Jedna z wymienionych.

2

Dwie z wymienionych.

3

Trzy z wymienionych.

4

Cztery z wymienionych.

5

Wszystkie.

Dla aplikacji nowotworzonej, końcowa ilość

punktów funkcyjnych wyliczana jest z następującej
zależności:

PF = (UFP + CFP) x VAF,

gdzie:
- UFP (ang. Unadjusted Function Point) –

nieuzgodniona liczba punktów funkcyjnych dla
funkcjonalności dostępnej dla użytkownika
końcowego po instalacji,

- CFP (ang. Conversion Function Point) –

nieuzgodniona liczba punktów funkcyjnych
wynikająca z konwersji danych.

FPA - Wyliczenie końcowej wartości punktów

funkcyjnych – krok 6.

FPA - Wyliczenie końcowej wartości punktów

funkcyjnych – krok 6.

W przypadku modyfikacji funkcjonalności aplikacji

rozmiar aplikacji w punktach funkcyjnych można

uzyskać stosując poniższy wzór:

PF = {(ADD+CHGA+CFP) x VAF2} + DEL x VAF1

gdzie:

• ADD – nieuzgodniona liczba punktów funkcyjnych

dla funkcji, które są dodawane,

• CHGA – nieuzgodniona liczba punktów funkcyjnych

dla funkcji, które są modyfikowane,

• DEL – nieuzgodniona liczba punktów funkcyjnych

dla funkcji, które są usuwane,

• VAF1 i VAF2 – to współczynniki VAF liczone

odpowiednio przed i po modyfikacji aplikacji.

FPA - Wyliczenie końcowej wartości punktów

funkcyjnych – krok 6.

Dla działającej aplikacji należy użyć

poniższej formuły w celu obliczenia

końcowej ilości punktów funkcyjnych:

PF=AD*VAF

gdzie:
• AD - nieuzgodniona liczba punktów

funkcyjnych funkcjonalności

dostępnej dla użytkownika

końcowego

Złote reguły Capers Jonesa

Liczba punktów funkcyjnych:
• Podniesiona do potęgi 1,15 jest zgrubnym

oszacowaniem liczby stron dokumentacji
wytworzonej w projekcie.

• Podniesiona do potęgi 1,2 jest zgrubnym

oszacowaniem liczby przypadków testowych.

• Podniesiona do potęgi 0,4 jest zgrubnym

oszacowaniem czasochłonności prac projektowych
w miesiącach.

• Podzielona przez 150 jest zgrubnym oszacowaniem

liczby osób potrzebnych w projekcie.

Punkty funkcyjne a nowe

technologie

• Aplikacje typu klient-serwer
• Aplikacje WWW

 

Rys. 1 Granice aplikacji typu klient-serwer.

KLIENT

SERWER

Rys. 2 Zasady liczenia punktów funkcyjnych dla
aplikacji klient-serwer

Nie liczymy

KLIENT

SERWER

EI

EI

EO lub EQ

W zakresie określenia granic aplikacji

WWW:

• Należy określić właściciela strony WWW .
• Zawsze należy znaleźć i określić biznesowy punkt

widzenia użytkownika, dla którego przeznaczona

jest aplikacja.

• Do granic aplikacji nie można wliczać własności

przeglądarek i wyszukiwarek.

• Należy

rozważyć

zakres

strony

i

jej

funkcjonalności dla takiej samej aplikacji.

• Wiele stron zawiera wiele linków do innych miejsc

w sieci.

• Po ustanowieniu zakresu i granic aplikacji, należy

starać się już ich nie zmieniać.

Szacowanie pracochłonności.

Wzory stworzone na podstawie

danych zebranych przy stosowaniu metody FPA w dużych
organizacjach w ostatnich latach.
Publikacja Capers Jones’a: Programming Languages Table
podaje osobne wzory dla fazy analizy, programowania i testowania.

W fazie analizy związek pomiędzy rozmiarem funkcjonalnym a
nakładami pracy w roboczogodzinach określony jest wzorem
(R – rozmiar funkcjonalny w PF):

W

A

= 4,0342 x (R)

0,9903

[rh] Np.4,0342 x (21)

0,9903

[rh] = 82.25 [rh]

W fazie programowania związek pomiędzy rozmiarem
funkcjonalnym a nakładami pracy w roboczogodzinach określony jest
wzorem:

W

P

= 12,313 x (R)

1,015

[rh] Np. 12,313 x (21)

1,015

[rh] = 270 [rh]

W fazie testowania związek pomiędzy rozmiarem funkcjonalnym a
nakładami pracy w roboczogodzinach określony jest wzorem:

W

T

= 5,2124 x (R)

1,024

[rh] Np. 5,2124 x (21)

1,024

[rh] = 118 [rh]