Funkcyjny pomiar oprogramowania

Funkcyjny pomiar

oprogramowania

Funkcyjny pomiar

oprogramowania

Katarzyna Nowakowska

Mateusz Górnisiewicz

Budowa i Integracja

Systemów Informacyjnych

Mariusz Trzaska

slide 2

O czym będziemy mówić?

• Ogólnie o metrykach
• Miary oprogramowania
• Techniki estymacji
• Model COCOMO
• Metoda Punktów Funkcyjnych
• Metoda Punktów Przypadków

Użycia

slide 3

Metryki

• Miary

– Wymiarowanie informacji (np. wielkość, jakość oprogramowania, …))

• Po co mierzyć?

– Umożliwia porównywanie
– Pozwala na szacowanie kosztów, czasu, niezbędnych zasobów
– Ułatwia kontrolę nad projektem („nie da się kontrolować niemierzalnego”)

slide 4

Co można mierzyć?

• Procesy

– Czas, nakład pracy

• Produkty

– Rozmiar, modularność

• Zasoby

– Cena, ilość

slide 5

Metryki Oprogramowania

• Mogą wskazywać:

– Rozmiar projektu

• KLOC (tysiąc linii kodu)
• Punkty Funkcyjne (Function Points – FP)

– Jakość oprogramowania

• prawidłowość
• możliwość powtórnego użycia
• użyteczność
• niezawodność

slide 6

Synteza metryk

• Metryki mogą być:

– „Surowymi” wskaźnikami (np. KLOC)
– Wskaźnikami wywiedzionymi (syntetycznymi)

• Średni czas pomiędzy błędami
• Koszt

slide 7

Miary jakości produktu

• Poprawność

– Błędy/moduł

• Z punktu widzenia programisty
• Może być mierzone przed ukończeniem produktu
• Niektóre moduły mogą być priorytetowe

slide 8

Miary jakości produktu

• Użyteczność

– Średni czas wykonywania zadania

• Miara względnie obiektywna, zależna jednak od zdolności użytkowników

– Punktowa ocena łatwości używania

• Dobra miara satysfakcji użytkownika, jednak bardzo subiektywna

slide 9

Miary jakości produktu

• Łatwość wprowadzania zmian

– Średni czas naprawy błędu

• Miara dość obiektywna, zależna jednak od zdolności programistów

– Złożoność cyklometryczna

• Szacuje łatwość zmiany produktu jeszcze przed pojawieniem się konieczności wprowadzenia zmian

- Wypadkowa wielu różnych czynników
(np. jakości dokumentacji)

slide 10

Miary ponownej używalności

• Ilość użytych niezmienionych modułów

– Łatwo mierzalne
– Nie ukazuje jednak łatwości modyfikacji (np. potrzeby jedynie drobnej zmiany do powtórnego użycia modułu)

• Stosunek ilości nowych do wszystkich linii kodu

– Niska wartość oznacza łatwość ponownego użycia
– Miara daje fałszywe rezultaty, gdy produkt używa całości starego i dużych ilości nowego kodu

slide 11

Miara modularności

• Średnia wielkość modułu wyrażona w ilości linii kodu

– Niska wartość zwykle oznacza wysoką modularność
– Silnie zależne od typu aplikacji, jako że niekiedy właściwe mogą być obszerne moduły o niskim stopniu złożoności.

slide 12

Miara wielkości - KLOC

• Tysiące linii kodu

– Łatwe do zmierzenia

• W mierzeniu produktywności

– Nie wiadomo, czy dana linia jest wolna od błędu
– Wydajniejsi programiści mogą potrzebować mniejszej liczby linii

• W mierzeniu rozmiaru projektu

– Zależne od użytego języka programowania

slide 13

Szacowanie ilości linii kodu

• Strukturalna dekompozycja projektu – podział na moduły
• Programista przedstawia trzy liczby:

– Pesymistyczna szacowana ilość linii
– Średnia szacowana ilość linii
– Optymistyczna szacowana ilość linii
– Można użyć współczynnika wagi opartego na jakości poprzednich estymacji

slide 14

Szacowanie ilości linii kodu

• W =Faktyczny KLOC / szacowany KLOC
• Przykład: W=200/80 = 2.5
• W przyszłych projektach

– KLOC = W x szacowany KLOC
– Szacowany KLOC = 100
– Ostatecznie KLOC szacowany = 100 x 2.5 = 250

slide 15

Punkty obiektowe

• Zliczenie liczby

– ekranów
– raportów
– Komponentów języków 3. generacji (3GL)

• Dla każdego używa się następujących czynników wagowych:
• Typ obiektu

prosty

średni skomplikowany

• Ekran 1

• Raport

• Komponent 3GL

slide 16

Techniki estymacji

• Na podstawie objętości specyfikacji
• Na podstawie projektu systemu
• Powyższe metody silnie zależne od stylu zapisu specyfikacji i projektu systemu

slide 18

COCOMO

(Constructive Cost Model –

Strukturalny Model Kosztu)

COCOMO

(Constructive Cost Model –

Strukturalny Model Kosztu)

• Model podstawowy

– Niewielka wiedza n/t projektu

• Model pośredni

– Po określeniu wymagań

• Model zaawansowany

– Po ukończeniu produktu

slide 19

COCOMO

Podstawowy wzór:
E = aS

– E = nakład w osobomiesiącach
– S = objętość wyrażona w tysiącach linii kodu źródłowego (KDSI)
– F = Czynnik korygujący (=1 in basic model)

Klasa

Łatwy

2.4 1.05

Niełatwy 3.6 1.20
Trudny

3.0 1.12

slide 20

COCOMO

•

Proponowana wielkość zespołu (w osobomiesiącach):

    Przedsięwzięcie łatwe: Czas [miesiące] = 2,5*Nakład^0,32
    Przedsięwzięcie niełatwe: Czas [miesiące] = 2,5*Nakład^0,35
    Przedsięwzięcie trudne: Czas [miesiące] = 2,5* Nakład^0,38

•

Czynniki modyfikujące:

wymagania wobec niezawodności systemu,

rozmiar bazy danych w stosunku do rozmiaru kodu,

złoźoność systemu: złoźoność struktur danych, złoźoność algorytmów, komunikacja z innymi systemami, stosowanie obliczeń równoległych,

wymagania co do wydajności systemu,

ograniczenia pamięci,

zmienność sprzętu i oprogramowania systemowego tworzącego środowisko pracy systemu.

slide 21

COCOMO

• Hierarchia

– Poziom prosty – rozmiar kodu źródłowego
– Poziom pośredni – rozmiar kodu źródłowego oraz inne czynniki (subiektywna ocena dostępnych zasobów, skomplikowania produktu i .t. p.)
– Poziom zaawansowany – poziom pośredni, wraz z analizą wpływu czynników na poszczególne fazy projektu

slide 22

Punkty Funkcyjne (FP)

• Próba zmierzenia funkcjonalności dostarczanej przez oprogramowanie
• W przypadku produktywności

– Mierzą funkcjonalność efektu końcowego – zamiast wejściowej ilości linii kodu
– Wielu programistów może pracować na ten sam Punkt Funkcyjny
– Złożona metoda pomiaru

slide 23

Szacowanie przez Punkty

Funkcyjne

Szacowanie przez Punkty

Funkcyjne

x Czynnik Wagowy

Wejścia

użytkownika

Wyjścia

użytkownika

Zapytania

zewnętrzne

Zbiory danych

wewnętrznych

Zbiory danych

zewnętrznych

Prosty

Średni

Złożony

Suma

slide 24

Szacowanie przez Punkty

Funkcyjne

Szacowanie przez Punkty

Funkcyjne

• Dane wejściowe:

–     Wejścia użytkownika: obiekty wejściowe wpływających na dane w systemie.
–     Wyjścia użytkownika: obiekty wyjściowe /wią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.

slide 25

Szacowanie przez Punkty

Funkcyjne

Szacowanie przez Punkty

Funkcyjne

FP = suma x (0.65 + 0.01



Ci)

•     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

Kompleksowy

Czynnik

Korygujący

slide 26

Szacowanie przez Punkty

Funkcyjne

Szacowanie przez Punkty

Funkcyjne

• Szacowanie liczby linii kodu w aplikacji

– 1 FP = 125 instrukcji w C

slide 27

Użyteczność Punktów

Funkcyjnych

Użyteczność Punktów

Funkcyjnych

• Szacowanie czasu projektu

– czas = FP x czas na jeden FP

• Szacowanie ilość błędów

– Ilość błędów na jeden FP

• Umowy

– Mogą zawierać cenę za jeden FP
– Śledzenie postępu – ile FP zostało już spełnionych

slide 28

Użyteczność Punktów

Funkcyjnych

Użyteczność 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

slide 29

Metoda Punktów Przypadków

Użycia – Use Case Points (UCP)

Metoda Punktów Przypadków

Użycia – Use Case Points (UCP)

• Bazuje na diagramach Use Case
• Wymaga:

– Starannego modelowania aktorów
– Ostrożności w oznaczaniu powiązań

między poszczególnymi przypadkami
użycia

– Odpowiedniego poziomu

szczegółowości modelu

slide 30

Metoda Punktów Przypadków

Użycia

Metoda Punktów Przypadków

Użycia

• Klasyfikacja aktorów

– Aktor prosty - zewnętrzny wobec analizowanego, komunikujący

się przez jeden z interfejsów programistycznych (Waga – 1)

– Aktor średnio-złożony - system zewnętrzny, dostępny przez

protokół z rodziny TCP/IP, HTTP lub podobny; również zbiory

danych (Waga – 2)

– Aktor złożony - zazwyczaj użytkownik końcowy, komunikujący

się z systemem poprzez interfejs graficzny lub stronę WWW

(Waga – 3)

• Suma nieskorygowanych wag aktorów (UAW)

– Suma wszystkich aktorów, pomnożona przez współczynniki ich

wag

slide 31

Metoda Punktów Przypadków

Użycia

Metoda Punktów Przypadków

Użycia

• Klasyfikacja przypadków użycia

– Prosty przypadek użycia – do trzech transakcji (Waga – 5)

– Średnio-złożony przypadek użycia – od czterech do siedmiu

transakcji (Waga – 10)

– Złożony przypadek użycia – więcej niż siedem transakcji

(Waga – 15)

• Możliwa również poprzez zliczenie klas potrzebnych

do obsługi przypadku

– Prosty przypadek użycia - nie więcej niż pięć klas (Waga – 5)

– Średnio-złożony przypadek użycia - od pięciu do dziesięciu klas

(Waga – 10)

– Złożony przypadek użycia - powyżej dziesięciu klas (Waga –

15)

• Suma nieskorygowanych wag przypadków użycia

(UUCW)

– Suma wszystkich przypadków, pomnożona przez współczynniki

ich wag

slide 32

Metoda Punktów Przypadków

Użycia

Metoda Punktów Przypadków

Użycia

•Modyfikacja przez czynniki techniczne

Technical Complexity Factor(TCF) = 0,6 + (0,01 * Wagowa suma

powyższych)

slide 33

Metoda Punktów Przypadków

Użycia

Metoda Punktów Przypadków

Użycia

• Modyfikacja przez czynniki środowiskowe

Environmental Factor(EF) = 1,4 + (-0,33 * Wagowa suma

powyższych)

slide 34

Metoda Punktów Przypadków

Użycia

Metoda Punktów Przypadków

Użycia

• Ostatecznie poszukiwany

rezultat

UCP = UUCP * TCF * EF

• Przyjmuje się, że 1 UCP = 20

osobogodzin pracy programisty

Document Outline