SZACOWANIE
ZŁOŻONOŚCI
OPROGRAMOWANIA

Arkadiusz Dworak
Mateusz Sobański

Spis treści



Metoda punktów funkcyjnych (FPA -
Function Point Analysis)



Metoda punktów przypadków użycia
(Use Case Points)

Szacowanie złożoności oprogramowania - A.Dworak, M.Sobański

Metoda punktów funkcyjnych

Function Point Analysis

Szacowanie złożoności oprogramowania - A.Dworak, M.Sobański

Metoda punktów funkcyjnych



Autor: Allan Albrecht ,IBM



Rok: 1979



Cel: próba opracowania metody
przewidzenia wysiłku związanego z
produkcją oprogramowania

Szacowanie złożoności oprogramowania - A.Dworak, M.Sobański

Klasy atrybutów produktywności



zewnętrzne wejścia (ang. External
Inputs)



zewnętrzne wyjścia (ang. External
Outputs)



pliki wewnętrzne (ang. Internal
Logical Files)



pliki zewnętrzne (ang. External
Interface Files)



zewnętrzne zapytania (ang. External
Inquires)

Szacowanie złożoności oprogramowania - A.Dworak, M.Sobański

Stopnie złożoności



prosty



średni



złożony

Szacowanie złożoności oprogramowania - A.Dworak, M.Sobański

Stopnie złożoności

i wartości wag

Lp(

Element

przetwarzania

Poziom złożoności elementu(j)

Prosty

Średni

Złożony

Zewnętrzne wejścia

Zewnętrzne wyjścia

Pliki wewnętrzne

Pliki zewnętrzne

Zewnętrzne zapytania

Szacowanie złożoności oprogramowania - A.Dworak, M.Sobański

Globalną wartość

nieskorygowanych punktów

funkcyjnych









NFP

• NFP – nieskorygowane punkty funkcyjne

• w – wartość współczynnika wagi

• n – liczba elementów w projekcie

• i – numer elementu przetwarzania

• j – numer poziomu złożoności

Szacowanie złożoności oprogramowania - A.Dworak, M.Sobański

Przykład

Lp(

Element

przetwarzania

Poziom złożoności

elementu(j)

Ilość wystąpień

Prosty

Średni

Złożony

Razem

Zewnętrzne

wejścia

2 x

3 x

4 x

Zewnętrzne

wyjścia

1 x

2 x

Pliki wewnętrzne

3 x

4 x

121

Pliki zewnętrzne

2 x

1 x

Zewnętrzne

zapytania

3 x

4 x

6 x

NFP:

281

Szacowanie złożoności oprogramowania - A.Dworak, M.Sobański

Korekcja wartości punktów

funkcyjnych



ilość czynników: 14



oceny: 0-5,



0 – brak wpływu



5 – bardzo duży wpływ

Szacowanie złożoności oprogramowania - A.Dworak, M.Sobański

Pytania korygujące

Czy jest wymagane przesyłanie danych?

Czy są funkcje przetwarzania rozproszonego?

Czy wydajność ma kluczowe znaczenie?

Czy system ma działać w mocno obciążonym
środowisku operacyjnym?

Czy system wymaga wprowadzania danych on-
line?

Czy wewnętrzne przetwarzanie jest złożone?

Czy kod ma być re-używalny?

Szacowanie złożoności oprogramowania - A.Dworak, M.Sobański

Pytania korygujące cd

Czy wejścia, wyjścia, pliki i zapytania są złożone?

Czy wprowadzanie danych on-line wymaga
transakcji obejmujących wiele ekranów lub operacji?

10.

Czy pliki główne są aktualizowane on-line?

11.

Czy system ma mieć automatyczne konwersje i
instalacje?

12.

Czy system wymaga mechanizmu kopii zapasowych i
odtwarzania?

13.

Czy system jest projektowany dla wielu instalacji w
różnych organizacjach?

14.

Czy aplikacja jest projektowana, aby wspomagać
zmiany i być łatwą w użyciu przez użytkownika?

Szacowanie złożoności oprogramowania - A.Dworak, M.Sobański

Kompleksowy współczynnik

korygujący

• FP – kompleksowa wartość skorygowanych punktów funkcyjnych

• NFP – nieskorygowana wartość punktów funkcyjnych

• k – wartość współczynnika korygującego

• 0,65 i 0,01 - stałe współczynniki, ustalone na podstawie doświadczeń
i badań statystycznych wykonywanych systemów

Szacowanie złożoności oprogramowania - A.Dworak, M.Sobański

Przykład

Pytanie

Ocena

NFP= 281

suma= 3

= 38

FP= 281(0,65

0,01

38)=289,43

Szacowanie złożoności oprogramowania - A.Dworak, M.Sobański

Pracochłonność

Szacowanie złożoności oprogramowania - A.Dworak, M.Sobański

w naszym przypadku około 20

Metoda punktów przypadków

użycia

(Use Case Points) - UCP

Szacowanie złożoności oprogramowania - A.Dworak, M.Sobański

Klasyfikacja przypadków

użycia

Tu identyfikujemy wszystkie przypadki
użycia, a dokładniej mówiąc specyfikacje
przypadków użycia, ponieważ do
szacowania potrzebny nam będzie opis
scenariusza podstawowego i model klas
analitycznych (identyfikacja klas
zaangażowanych w realizacje danego
przypadku użycia). Na tym etapie należy
określić poziom złożoności dla każdego
przypadku użycia. Metoda wskazuje trzy
typy złożoności.

Prosta złożoność przypadku użycia:

Definicje:



Prosty interfejs dla
użytkownika.



Operuje na pojedynczej
encji bazy danych.



Podstawowy scenariusz
zawiera 3 lub mniej
kroków.



Implementacja obejmuje
mniej niż 5 klas.

Waga:



Średnia złożoność przypadku

użycia:

Definicje:



Średnio złożony interfejs
dla użytkownika.



Operuje na 2 (lub więcej)
encjach bazy danych.



Podstawowy scenariusz
zawiera od 4 do 7 kroków.



Implementacja obejmuje
5 lub 10 klas

Waga:



Duża złożoność przypadku użycia:

Definicje:



Złożony interfejs dla
użytkownika.



Operuje na 3 (lub więcej)
encjach bazy danych.



Podstawowy scenariusz
zawiera powyżej 7 kroków.



Implementacja obejmuje
powyżej 10 klas

Waga:



Obliczanie…

Następnie przechodzimy do obliczenia
nieskorygowanej wagi przypadków użycia w
skrócie oznaczoną UUCW (ang . Unadjusted Use
Cases Weight). W tym celu zliczamy liczbę
przypadków użycia zakwalifikowanych do każdej
ze wskazanych kategorii (prosty, średnio złożony,
złożony). Następnie liczbę przypadków użycia w
danej kategorii wymnażamy przez wartość wagi
dla danej kategorii złożoności przypadku użycia.
Wartość nieskorygowanej wagi przypadków użycia
stanowić będzie suma wcześniej zdefiniowanych
iloczynów po każdej kategorii złożoności
przypadku użycia.

Wzorek:

Podsumowując, formuła obliczania

nieskorygowanej wagi:

n – liczba przypadków użycia zakwalifikowanych do i-tej kategorii

złożoności przypadku użycia

w – wartość wagi dla i-tej kategorii złożoności przypadku użycia.

Czynniki złożoności

środowiska:

(ang. Environmental Complexity Factors )
Charakteryzują dostawcę oprogramowania. Metoda
wskazuje osiem czynników złożoności środowiska i
każdemu z nich przypisuje wagę, która mówi jak
bardzo dany czynnik wpływa na ostateczny wynik.
Im waga czynnika jest większa tym czynnik ma
większy wpływ na zmniejszenie pracochłonności
wytworzenia systemu informatycznego. Warto
zwrócić uwagę, że większość czynników posiada
dodatnie wagi. Oznacza to, że wzrost ich wpływu
redukuje pracochłonność. Z kolei wzrost wpływu
czynników z ujemnymi wagami spowoduje
zwiększenie pracochłonności.

Wagi:

Symbo



Opis:

Znajomość metodyki, języka UML
Doświadczenie zespołu
Znajomość technik obiektowych
Umiejętności głównego analityka
Motywacja zespołu
Stabilność wymagań
Udział pracowników w niepełnym

czasie

Skomplikowane języki

programowania

Wagi

   1,5
   0,5
    1
   0,5
    1
    2
   -1
   -1

Przyjrzyjmy się bliżej czynnikom

złożoności środowiska:



E1 – mówi czy zespół jest zna dziedzinę problemu i
techniczne aspekty rozwiązania problemu klienta. Zwraca się
uwagę na znajomość metodyki w ramach której realizowany
jest projekt np. RUP (ang. Rational Unified Process) jak
również znajomość języków modelowania systemu np. UML
(ang. Unified Modeling Language).



E2 – ogólnie rozumiane doświadczenie zespołu w
wytwarzaniu oprogramowania.Podstawowy scenariusz
zawiera powyżej 7 kroków.



E3 – doświadczenie w projektowaniu aplikacji zorientowanych
obiektowo związane z umiejętnością projektowania aplikacji
obiektowych, oraz umiejętność wykorzystania wspierających
narzędzi do projektowania systemów informatycznych.

Przyjrzyjmy się bliżej czynnikom

złożoności środowiska:



E4 – określa zdolność analityka do właściwego pozyskiwania
wymagań od klienta oraz posiadanie wiedzy z dziedziny
rozwiązywanego problemu.



E5 – ocenia zdolność do zaangażowania się zespołu w powierzone
im zadania.



E6 – definiuje czy wymagania nie są narażone na częste zmiany.



E7 – określa, czy wśród zespołu znajduje się duża liczba
pracowników pracujących w niepełnym wymiarze czasu (np.
stażyści, studenci)



E8 – uściśla jak trudny do opanowania jest język programowania,
w którym implementowany będzie przyszły system informatyczny.

Wzór:

W metodzie punktów przypadków użycia wpływ każdego czynnika

oceniamy w skali od 0 do 5 (zakres liczb naturalnych), przy czym:



0 oznacza, że czynnik jest nieistotny dla projektu



3 oznacza średni wpływ



5 oznacza silny wpływ

w – wartość wagi i-tego czynnika,
impact – ocena wpływu i-tego czynnika.

Czynniki złożoności

technicznej

(ang. Technical Complexity Factor)
charakteryzują przyszły system informatyczny.
Metoda definiuje precyzyjnie chce określić
specyfikę produktu wskazując trzynaście
czynników. Podobnie jak czynniki
środowiskowe, każdemu z nich przypisano
wagę oddającą stopień w jakim czynnik
wpływa na wartość końcowej estymacji.
Wzrost wpływu każdego współczynnika
złożoności technicznej powoduje zawsze
wzrost końcowej wartości szacowanej
pracochłonności.

Czynniki złożoności

technicznej

Symbo



Opis:

Rozproszenie systemu
Wydajność systemu
Wydajność dla użytkownika

końcowego

Złożone przetwarzanie

wewnętrzne

Re-używalność
Łatwość w instalacji

Wagi

   2
   1
   1
   1
   1

0,5

Czynniki złożoności

technicznej

Symbo



T10



T11



T12



T13

Opis:

Łatwość użycia
Przenośność
Łatwość wprowadzania zmian
Współbieżność
Specjalne mechanizmy ochrony

dostępu

Udostępnianie userom z

zewnętrznym

Dodatkowe szkolenia użytkowników

Wagi

0,5

   2
   1
   1
   1
   1
   1

Przyjrzyjmy się również czynnikom

złożoności technicznej:



T1 – mówi czy w systemie wymagane jest rozproszone
przetwarzanie danych.



T2 – określa wydajność systemu , w odniesieniu do czasu
reakcji na zdarzenia, przepustowość, itp .



T3 – definiuje wydajność dla końcowego użytkownika w
kontekście jego percepcji.



T4 – określa czy wymagane są skomplikowane operacje
przetwarzania danych, korzystanie z zaawansowanych
algorytmów.



T5 – mówi czy elementy lub kod wytwarzanego systemu,
będzie wykorzystywany powtórnie.

Przyjrzyjmy się również czynnikom

złożoności technicznej:



T6 – określa sposób instalacji łatwość i przyjazność instalacji systemu,
wskazuje czy wymagany będzie udział specjalistów do instalacji i
konfiguracji początkowej ze strony dostawcy oprogramowania.



T7 – określa dostosowanie interfejsu użytkownika do jego potrzeb,
wygodę w korzystaniu oraz łatwość nauczenia się korzystania z
systemu.



T8 – mówi czy aplikacja powinna działać w określonych środowiskach.



T9 – określa czy system ma być tak konstruowany, by można było go
łatwo w przyszłości rozbudowywać.



T10 – mówi czy w systemie będzie miało miejsce przetwarzanie
współbieżne.

Przyjrzyjmy się również czynnikom

złożoności technicznej:



T11 – definiuje czy system będzie wymagał
wykorzystania mechanizmów związanych z
zabezpieczeniem dostępu do systemu lub
danych.



T12 – określa w jakim stopniu z systemu będą
korzystały inne zewnętrzne systemy lub aktorzy.



T13 – określa potrzebę organizacji szkoleń dla
użytkowników.

Wzór:

Analogicznie jak poprzednio wpływ każdego czynnika oceniamy

w skali od 0 do 5 (zakres liczb naturalnych), przy czym:



0 oznacza, że czynnik jest nieistotny dla projektu



3 oznacza średni wpływ



5 oznacza silny wpływ

w – wartość wagi i-tego czynnika,
impact – ocena wpływu i-tego czynnika.

Klasyfikacja aktorów:

Tu identyfikujemy wszystkich

aktorów, którzy będą wchodzić w
interakcję z przyszłym systemem
informatycznym. Na tym etapie
należy określić poziom złożoności dla
każdego typu aktora. Metoda
wskazuje trzy typy złożoności.

Prosty:

Definicje:



System zewnętrzny,
komunikujący się z
docelowym przez interfejs
programistyczny (API).
Podstawowy scenariusz
zawiera 3 lub mniej
kroków.



Waga = 1

Średnio złożoność:

Definicje:



System zewnętrzny komunikujący
się przez bardziej złożony protokół,
np. http.



Człowiek wchodzący w interakcję z
systemem poprzez terminal
tekstowy.



Waga = 2

Złożoność:

Definicje:



Użytkownik końcowy (człowiek),
komunikujący się z systemem
najczęściej przez interfejs
graficzny.



Waga = 3

Wzór:

Następnie obliczamy nieskorygowaną wagę aktorów w skrócie

oznaczoną UAW (ang. Unadjusted Actors Weight). W tym
celu zliczamy liczbę aktorów zakwalifikowanych do każdej ze
wskazanych kategorii (prosty, średnio złożony, złożony).

n – liczba aktorów zakwalifikowanych do i-

tej kategorii,

w – wartość wagi dla i-tej kategorii.

Ostatecznie:

Działania metody punktów przypadków użycia dobiegają
powoli końca. Wyznaczyliśmy już kilka współczynników,
przyszedł w końcu czas na wykorzystanie ich wartości.
Po obliczeniu nieskorygowanych wag aktorów UAW i
nieskorygowanych przypadków użycia UUCW, możemy
obliczyć nieskorygowanie punkty przypadków użycia
(ang. Unadjusted Use Case Points) w skrócie UUCP,
poprzez zwykłe sumowanie dwóch powyższych wartości:

Szczególny przypadek użycia UCP:

Natomiast interesujące nas szczególnie punkty
przypadków użycia UCP wyznaczymy za pomocą
formuły, która wykorzystuje wcześniej wyznaczone
wartości czynnika złożoności technicznej TCF i
czynnika złożoności środowiska ECF:

Ostatni etap UCP:

Ostatnim etapem w metodzie UCP jest przeliczenie
punktów przypadków użycia na konkretne wartości
pracochłonności liczone w osobogodzinach.
Dokonuje się to poprzez pomnożenie UCP przez tak
zwany współczynnik produktywności PF (ang.
Productivity Factor). Współczynnik produktywności
przekształca nam jeden punkt przypadku użycia na
ilość godzin pracy człowieka. Historycznie wartość
współczynnika PF wahała się od 15 do 30
roboczogodzin na jeden punkt przypadków użycia. Z
badań Karnera, twórcy metody, wynika, że realizacja
jednego UCP wymaga około 20 roboczogodzin.

Koniec

Dziękujemy za uwagę

Szacowanie złożoności oprogramowania - A.Dworak, M.Sobański

Document Outline