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)
2
Szacowanie złożoności oprogramowania - A.Dworak, M.Sobański
Metoda punktów funkcyjnych
Function Point Analysis
3
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
4
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)
5
Szacowanie złożoności oprogramowania - A.Dworak, M.Sobański
Stopnie złożoności
prosty
średni
złożony
6
Szacowanie złożoności oprogramowania - A.Dworak, M.Sobański
Stopnie złożoności
i wartości wag
Lp(
i)
Element
przetwarzania
Poziom złożoności elementu(j)
Prosty
Średni
Złożony
1
Zewnętrzne wejścia
3
4
6
2
Zewnętrzne wyjścia
4
5
7
3
Pliki wewnętrzne
7
10
15
4
Pliki zewnętrzne
5
7
10
5
Zewnętrzne zapytania
3
4
6
7
Szacowanie złożoności oprogramowania - A.Dworak, M.Sobański
Globalną wartość
nieskorygowanych punktów
funkcyjnych
5
1
3
1
i
j
ij
ij
n
w
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
8
Szacowanie złożoności oprogramowania - A.Dworak, M.Sobański
Przykład
Lp(
i)
Element
przetwarzania
Poziom złożoności
elementu(j)
Ilość wystąpień
Prosty
Średni
Złożony
Razem
1
Zewnętrzne
wejścia
2 x
3
3 x
4
4 x
6
42
2
Zewnętrzne
wyjścia
1 x
4
1 x
5
2 x
7
23
3
Pliki wewnętrzne
3 x
7
4 x
10
4 x
15
121
4
Pliki zewnętrzne
2 x
5
2 x
7
1 x
10
34
5
Zewnętrzne
zapytania
3 x
3
4 x
4
6 x
6
61
NFP:
281
9
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
10
Szacowanie złożoności oprogramowania - A.Dworak, M.Sobański
Pytania korygujące
1.
Czy jest wymagane przesyłanie danych?
2.
Czy są funkcje przetwarzania rozproszonego?
3.
Czy wydajność ma kluczowe znaczenie?
4.
Czy system ma działać w mocno obciążonym
środowisku operacyjnym?
5.
Czy system wymaga wprowadzania danych on-
line?
6.
Czy wewnętrzne przetwarzanie jest złożone?
7.
Czy kod ma być re-używalny?
11
Szacowanie złożoności oprogramowania - A.Dworak, M.Sobański
Pytania korygujące cd
8.
Czy wejścia, wyjścia, pliki i zapytania są złożone?
9.
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?
12
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
13
Szacowanie złożoności oprogramowania - A.Dworak, M.Sobański
Przykład
Pytanie
Ocena
1
3
2
4
3
2
4
3
5
1
6
5
7
0
8
1
9
2
10
4
11
4
12
5
13
3
14
1
NFP= 281
suma= 3
+
4
+
2
+
3
+
1
+
5
+
0
+
1
+
2
+
4
+
4
+
5
+
3
+
1
= 38
FP= 281(0,65
+
0,01
x
38)=289,43
14
Szacowanie złożoności oprogramowania - A.Dworak, M.Sobański
Pracochłonność
Szacowanie złożoności oprogramowania - A.Dworak, M.Sobański
15
w naszym przypadku około 20
Metoda punktów przypadków
użycia
(Use Case Points) - UCP
16
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:
5
5
5
5
Ś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:
10
10
10
10
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:
15
15
15
15
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
l:
E1
E2
E3
E4
E5
E6
E7
E8
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
l:
T1
T2
T3
T4
T5
T6
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
l:
T7
T8
T9
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
43