Szacowanie zlozonosci oprogramowania

background image

SZACOWANIE
ZŁOŻONOŚCI
OPROGRAMOWANIA

Arkadiusz Dworak
Mateusz Sobański

background image

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

background image

Metoda punktów funkcyjnych

Function Point Analysis

3

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

background image

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

background image

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

background image

Stopnie złożoności

prosty

średni

złożony

6

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

background image

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

background image

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

background image

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

background image

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

background image

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

background image

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

background image

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

background image

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

background image

Pracochłonność

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

15

w naszym przypadku około 20

background image

Metoda punktów przypadków

użycia

(Use Case Points) - UCP

16

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

background image

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.

background image

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

background image

Ś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

background image

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

background image

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.

background image

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.

background image

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.

background image

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

background image

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.

background image

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.

background image

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.

background image

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.

background image

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

background image

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

background image

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.

background image

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.

background image

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.

background image

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.

background image

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.

background image

Prosty:

Definicje:

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

Waga = 1

background image

Ś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

background image

Złożoność:

Definicje:

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

Waga = 3

background image

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.

background image

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:

background image

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:

background image

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.

background image

Koniec

Dziękujemy za uwagę

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

43


Document Outline


Wyszukiwarka

Podobne podstrony:
BYT 2003 Szacowanie zlozonosci oprogramowania v1
BYT 2004 Szacowanie zlozonosci oprogramowania v2
ZPR Mierzenie zlozonosci oprogramowania
Szacowanie oprogramowania IS rokIV w10 v0 1
Szacowanie Koszt%F3w Tworzenia Oprogramowania
Szacowanie oprogramowania
W4 Proces wytwórczy oprogramowania
analiza złożonych aktów ruchowych w sytuacjach patologicznych
Proces tworzenia oprogramowania
Szacowanie zasobów st
metodologia badan wydatkow i szacowanie budzetu rekomowego
BYT 2005 Pomiar funkcjonalnosci oprogramowania
oprogramowanie uzytkoweCz1 Zarzadzanie2011
Lec04 PL Oprogramowanie fin
08 Prototypowanie oprogramowaniaid 7587 ppt
Złożone konstrukcje metalowe

więcej podobnych podstron