Inżynieria oprogramowania
Zapewnienie jakości
oprogramowania
i metryki oprogramowania
Slajd 2
Plan wykładu
• Jakość oprogramowania
• Liczba cyklomatyczna (McCabe’s
cyclomatic number)
• Metoda COCOMO
• Analiza Punktów Funkcyjnych
• Metoda Punktów Przypadków Użycia
• Model dojrzałości procesów
wytwórczych (CMM)
Slajd 3
Jakość
oprogramowania
Slajd 4
Jakość oprogramowania 1/2
• Zapewnienie jakości jest rozumiane jako
zespół działań zmierzających do wytworzenia u
wszystkich zainteresowanych
przekonania
przekonania, że
dostarczony produkt właściwie realizuje swoje
funkcje i odpowiada aktualnym wymaganiom i
standardom
• Problem jakości, oprócz mierzalnych
czynników technicznych, włącza dużą liczbę
niemierzalnych obiektywnie czynników
psychologicznych
Slajd 5
Jakość oprogramowania 2/2
• Podstawą obiektywnych wniosków co do jakości
oprogramowania są
pomiary
pomiary pewnych parametrów
użytkowych (niezawodności, szybkości, itd.) w realnym
środowisku, np. przy użyciu metod statystycznych
• Obiektywne pomiary cech produktów
programistycznych są utrudnione lub niemożliwe
• Jakość gotowych produktów programistycznych jest
bardzo trudna do zmierzenia ze względu na ich
złożoność, wieloaspektowość oraz niską
przewidywalności wszystkich aspektów ich
zastosowań w długim czasie
Slajd 6
Miary Jakości Oprogramowania
• Liczba błędów
• Liczba linii kodu
• Gęstość błędów (Liczba błędów/rozmiar
kodu)
• Liczba instrukcji wykonywalnych
• Złożoności algorytmów
• Koszty (Metoda COCOMO – osobo-
miesiące)
Slajd 7
Elementy pomiaru oprogramowania
Slajd 8
Modele i miary wydajności
Wydajność
Wartość
Koszt
Jakość
Ilość
Personel
Zasoby
Złożoność
Niezawodność
Defekty
Wielkość
Funkcjonalność
Czas
Pieniądze
Sprzęt
Oprogramowanie
Ograniczenia
środowiskowe
Trudność
problemu
Czynniki
wpływające
na ogólną
wydajność
Mylące, wręcz niebezpieczne jest zastępowanie wielu miar
jedną miarą, np. długością wyprodukowanego kodu
Slajd 9
Techniki szacowania nakładów
pracy 1/2
•
Modele algorytmiczne
Modele algorytmiczne
- opis przedsięwzięcia
za pomocą charakteryzujących go
atrybutów (liczbowych) i na tej bazie
wyliczenie (np. prosta formuła
matematyczna) nakładów
•
Ocena przez ekspertów
Ocena przez ekspertów
- bazują na
własnym doświadczeniu zdobytym przy
realizacji innych projektów
Slajd 10
Techniki szacowania nakładów
pracy 2/2
•
Ocena przez analogię
Ocena przez analogię
- przy założeniu gromadzenia
informacji o uprzednio wykonanych projektach; wyszukuje
się podobne systemy poprzednio zrealizowane i
wykorzystuje nakłady poniesione na ich stworzenie
•
Wycena dla wygranej
Wycena dla wygranej
(ang. pricing to win) - na podstawie
oceny możliwości klienta oraz przewidywanych
działań konkurencji; opiera się na prawie Parkinsona -
przedsięwzięcia są wykonywane przy założonych kosztach
(jakie by one nie były)
•
Szacowanie wstępujące
Szacowanie wstępujące
- dzieli się przedsięwzięcie na
mniejsze zadania, które łatwiej oszacować; koszt
całości jest ich sumą (ew. z narzutem na integrację)
Slajd 11
Modele algorytmiczne szacowania
nakładów 1/2
• Większość modeli przyjmuje, że jednym z
istotnych atrybutów jest
rozmiar systemu
rozmiar systemu,
mierzony np. liczbą instrukcji (linii) kodu
(ang. Lines Of Code - LOC), KLOC (ang. Kilo-
LOC), KDSI (ang. Kilo (thousand) of
Delivered Source code Instructions)
• Najlepiej jest stosować zestawy metryk,
co pozwala zmniejszyć błędy pomiaru
Slajd 12
Modele algorytmiczne szacowania
nakładów 2/2
• Metryki powinny być wykorzystywane jako metody
wspomagania ekspertów (stosowane
formalistycznie mogą być groźne)
• Pomimo pochodzenia empirycznego, metryki
skutecznie pomagają w szybkiej i mniej
subiektywnej ocenie oprogramowania
• Żadna metoda przewidywania kosztów nie jest
doskonała i jest oparta na szeregu arbitralnych
założeń; niemniej dla celów planowania tego rodzaju
metody stają się koniecznością
Slajd 13
wrażliwość na błędy,
możliwości testowania,
częstotliwość
występowania awarii,
dostępność systemu,
propagacja błędów,
ilość linii kodu, złożoność
kodu, złożoność programu,
złożoność obliczeniową,
funkcjonalną, modułową,
łatwość implementacji,
rozmiar dokumentacji,
ilość zadań wykonanych
terminowo i po terminie,
Różnorodne metryki uwzględniają m.in.
następujące aspekty
współzależność zadań,
wielkość i koszt projektu,
czas trwania projektu,
zagrożenia projektu
(ryzyko),
czas gotowości produktu,
kompletność wymagań,
kompletność planowania,
stabilność wymagań,
odpowiedniość
posiadanych zasobów
sprzętowych, materiałowych
i ludzkich,
efektywność zespołu,
efektywność poszczególnych
osób.
Slajd 14
Miary Jakości Oprogramowania
Slajd 15
Liczba
cyklomatyczna
(McCabe’s cyclomatic
number)
Slajd 16
Liczba cyklomatyczna
(McCabe’s cyclomatic number)
• Zaproponowana przez McCabe’a; odnosi się do schematu
blokowego programu i jest równa liczbie niezależnych
dróg w takim schemacie (liczba decyzji w programie +1)
• Krytykowana m.in. za nieuwzględnienie złożoności
przepływów danych lub złożoności programów
niestrukturalnych
Program P jest reprezentowany przez graf G, gdzie:
e - liczba krawędzi
n - liczba węzłów
d - liczba węzłów decyzyjnych
v(P)=e-n+2
v(P)=d+1
v(P) - liczba niezależnych ścieżek w G
Slajd 17
Metoda COCOMO
Slajd 18
Metoda COnstructive COst MOdel
(COCOMO) 1/2
Powstała w oparciu o dane z rzeczywistych
projektów, realizowanych tradycyjnie (np. bez
narzędzi CASE)
Wymaga
oszacowania liczby instrukcji
, z których
będzie składał się system (co może być tak samo
trudne jak oszacowanie nakładów)
Slajd 19
Metoda COnstructive COst MOdel
(COCOMO) 2/2
Wyróżnia się trzy klasy przedsięwzięć:
•
Łatwe
Łatwe
(organiczne, ang. organic) - wykonywane przez
stosunkowo małe zespoły, złożone z osób o podobnych
wysokich kwalifikacjach; dziedzina oraz wykorzystywane
metody i narzędzia są dobrze znane
•
Pośrednie
Pośrednie
(półoderwane, ang. semi-detached) - członkowie
zespołu różnią się stopniem zaawansowania; pewne
aspekty dziedziny problemu lub wykorzystywane narzędzia
nie są dobrze znane
•
Trudne
Trudne
(osadzonych, ang. embedded) - przedsięwzięcia
realizujące systemy o bardzo złożonych wymaganiach;
dziedzina problemu, stosowane narzędzia i metody mogą
być w dużej mierze nieznane; członkowie zespołu nie
mają doświadczenia w realizacji podobnych zadań
Slajd 20
Wady metody COCOMO 1/2
• Liczba linii kodu jest znana dokładnie dopiero
wtedy, gdy system jest napisany a szacunki
mogą być (i zwykle są ) obarczone bardzo
poważnym błędem (niekiedy ponad 100%)
• Określenie “linii kodu źródłowego” inaczej
wygląda dla każdego języka
programowania (np. 1 linia w Smalltalk’u jest
równoważna 10-ciu linii w C; dla języków
4GL ten stosunek może być nawet 1000:1)
Slajd 21
Wady metody COCOMO 2/2
• Koncepcja oparta na liniach kodu źródłowego natomiast
całkowicie nie przystaje do współczesnych narzędzi
programistycznych, np. opartych o programowanie
wizyjne
• Opiera się tylko na długości kodu i nie bierze w ogóle
pod uwagę funkcjonalności ani złożoności produktu
• Kwalifikacja przedsięwzięcia do predefiniowanych
klas oraz dobór czynników modyfikujących jest
trudny, a ewentualne błędy mogą prowadzić do
znacznych rozbieżności pomiędzy oczekiwanym i
rzeczywistym kosztem
Slajd 22
Analiza Punktów
Funkcyjnych
Slajd 23
Analiza Punktów Funkcyjnych 1/6
Metoda analizy punktów funkcyjnych (ang.
functional points - FP), została opracowana
przez Albrechta; łączy ona własności
metody, badającej rozmiar projektu
programu z możliwościami metody
badającej produkt programowy (jego
funkcjonalność)
FP = UFP * TCF
Slajd 24
Analiza Punktów Funkcyjnych 2/6
Liczbę pierwotną punktów funkcyjnych (UFP) wylicza się
korzystając z następujących danych:
• Wejścia użytkownika
:
obiekty wejściowe wpływające
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
Slajd 25
Pierwotne punkty funkcjonalne 3/6
Czynnik złożoności
Wejścia użytkownika (I)
Wyjścia użytkownika (O)
Zbiory danych
wewnętrzne (l)
Zbiory danych
zewnętrzne (E)
Zapytania zewnętrzne
(F)
Prost
y
3
4
7
5
3
Średn
i
4
5
10
7
4
Złożo
ny
6
7
15
10
6
Wagi przypisywane elementom zależą od ich typu
UFP = w
i
*e
i
+ w
o
*e
o
+ w
e
*e
e
+ w
l
*e
l
+
w
f
*e
f
gdzie w
x
- wagi czynników, e
x
- liczności elementów
Slajd 26
Współczynnik złożoności technicznej
(TCF) 4/6
TCF - liczba ustalana na podstawie wpływu 14
czynników (0.65<=TCF<=1.35 ):
1. występowanie urządzeń komunikacyjnych
2. rozproszenie przetwarzania
3. długość czasu oczekiwania na odpowiedź
systemu
4. stopień obciążenia sprzętu istniejącego
5. częstotliwość wykonywania dużych transakcji
6. wprowadzanie danych w trybie bezpośrednim
7. wydajność użytkownika końcowego
Slajd 27
Współczynnik złożoności technicznej
(TCF) 5/6
8. aktualizacja danych w trybie bezpośrednim
9. złożoność przetwarzania danych
10. możliwość ponownego użycia programów
w innych zastosowaniach
11. łatwość instalacji
12. łatwość obsługi systemu
13. rozproszenie terytorialne
14. łatwość wprowadzania zmian -
pielęgnowania systemu
Slajd 28
Wykorzystanie punktów funkcyjnych
6/6
• Ocena złożoności realizacji systemów
• Audyt projektów
• 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
Slajd 29
Szacowanie przez Punkty Funkcyjne
• Szacowanie liczby linii kodu w aplikacji
– 1 FP = 125 instrukcji w C
Slajd 30
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
Slajd 31
Metoda Punktów Przypadków
Użycia
Slajd 32
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
Slajd 33
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
Slajd 34
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
Slajd 35
Metoda Punktów Przypadków Użycia
•Modyfikacja przez czynniki techniczne
Technical Complexity Factor(TCF) = 0,6 + (0,01 * Wagowa suma
powyższych)
Slajd 36
Metoda Punktów Przypadków Użycia
• Modyfikacja przez czynniki środowiskowe
Environmental Factor(EF) = 1,4 + (-0,33 * Wagowa suma
powyższych)
Slajd 37
Metoda Punktów Przypadków Użycia
• Ostatecznie poszukiwany rezultat
UCP = UUCP * TCF * EF
• Przyjmuje się, że
1 UCP = 20
osobogodzin
pracy programisty
Slajd 38
Model dojrzałości procesów
wytwórczych (CMM)
Slajd 39
Dojrzałość procesów wytwórczych
Niedojrzałość
Dojrzałość
Improwizacja podczas
procesu wytwórczego
Proces jest wyspecyfikowany,
ale specyfikacja nie jest
stosowana
Doraźne reagowanie w
sytuacji kryzysów
Harmonogram i budżet są
przekraczane
Funkcjonalność jest
stopniowo okrajana
Jakość produktu jest niska
Brak obiektywnych
kryteriów oceny
Zdolność do budowy
oprogramowania jest cechą
organizacji a nie personelu
Proces jest zdefiniowany,
znany i wykorzystywany
Proces jest obserwowany i
ulepszany
Prace są planowane i
monitorowane
Role i odpowiedzialności
są zdefiniowane
Obiektywna, ilościowa
ocena
Slajd 40
Poziomy dojrzałości wytwórców 1/2
Wyróżniono 5 poziomów dojrzałości wytwórców
(poczynając od p. najniższego):
•
początkowy
początkowy (1)
- proces chaotyczny, nie
istnieją żadne standardy, decyzje
podejmowane ad hoc; może dotyczyć nawet
firm o dobrym zaawansowaniu technicznym
•
powtarzalny
powtarzalny (2)
– proces
zindywidualizowany; przedsięwzięcia
wykonywane w podobny sposób (standardy de
facto); standardy nie są udokumentowane
i nie istnieją ścisłe procedury kontroli
Slajd 41
Poziomy dojrzałości wytwórców 2/2
•
zdefiniowany
zdefiniowany (3)
- proces zinstytucjonalizowany;
standardy postępowania są zdefiniowane, sformalizowane
i ich stosowanie jest kotrolowane
•
zarządzany
zarządzany (4)
- proces nie tylko podlega kontroli ale
jest również mierzony w sposób ilościowy; informacje
zwrotne wykorzystywane są do sterowania procesem
•
optymalizujący
optymalizujący (5)
- standardy są ciągle uaktualniane;
informacje zwrotne wpływają na ulepszenie procesu;
standardy zawierają elementy pozwalające na dostrojenie
procesu do aktualnych potrzeb
Niewiele firm uzyskało poziom 3-ci, umożliwiający
dostarczanie oprogr. dla Dep. Obrony; tylko IBM w
zakresie oprogr. promu kosmicznego dla NASA uzyskał
poziom 5-ty
Slajd 42
O czym był wykład?
• Jakość oprogramowania
• Liczba cyklomatyczna (McCabe’s
cyclomatic number)
• Metoda COCOMO
• Analiza Punktów Funkcyjnych
• Metoda Punktów Przypadków Użycia
• Model dojrzałości procesów
wytwórczych (CMM)