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]