1
Inżynieria oprogramowania
wykład 7
Zapewnienie jakości
oprogramowania
1
Inżynieria oprogramowania
wykład 7
Zapewnienie jakości
oprogramowania
2/33
Zapewnienie jakości
jest podstawowym priorytetem stosowania inżynierii
oprogramowania
jest czynnością przekrojową → wykonywaną na
każdym etapie procesu wytwórczego
zapewnienie jakości obejmuje następujące czynności:
zarządzanie jakością
metody i narzędzia wspomagające stosowanie inżynierii
oprogramowania
przeglądy techniczne na różnych etapach procesu
wytwórczego
testowanie produktu
zarządzanie dokumentacją
zapewnienie zgodności oprogramowania ze standardami
prowadzenie pomiarów i raportowanie
3/33
Definicja jakości w sensie
ogólnym
jakość (w jęz. grec. poiotes) – przyjmuje się że po raz 1.
użył go Platon, a oznaczało „pewien stopień
doskonałości”, jakość posiada cechy obiektywne -
mierzalne (np. kształt, masa) i subiektywne (np. barwa,
zapach) (źródło: pl.wikipedia.org)
Cyceron wprowadził łaciński odpowiednik qualitas,
tłumaczone jako ang. quality (źródło: pl.wikipedia.org)
„wartość czegoś” (źródło: http://sjp.pwn.pl)
„istotne cechy przedmiotu wyróżniające go spośród
innych” (źródło:
http://sjp.pwn.pl/
)
4/33
Jakość w inżynierii oprogramowania
podstawą do mierzenia jakości są ściśle
sformułowane wymagania – odstępstwa od nich
oznaczają niską jakość
oprogramowanie powinno powstawać z
zachowanie norm, odstępstwo od norm
prowadzi często do obniżania jakości
oprogramowanie powinno spełniać również
wymagania niepisane, zwyczajowe (np. łatwość
obsługi)
5/33
Definicja dobrego oprogramowania
definicja dobrego oprogramowania wg Roberta Glassa
(Defending Quality Intuitively, IEEE Software,1998):
satysfakcja użytkownika = działający produkt + dobra
jakość + dotrzymany budżet i harmonogram
6/33
Czynniki wpływające istotnie
na jakość oprogramowania
mierzalne bezpośrednio, np. liczba usterek na
punkt funkcyjny
mierzalne pośrednio – np. pielęgnowalność,
łatwość użytkowania
7/33
Rodzaje jakości wg cech
mierzalnych
jakość projektu → oparta na cechach projektu
ustalonych przez projektantów
np. efektywność
dotyczy specyfikacji wymagań i projektu systemu
jakość wykonania – związana z dokładnością
realizacji projektu
znaczenie ujawnia się na etapie implementacji
8/33
Czynniki jakości wg McCalla*
zgodność ze specyfikacją i potrzebami klienta
niezawodność – zdolność wykonywania zadań z określoną
dokładnością
efektywność – zasoby i wielkość kodu potrzebne do funkcjonowania
programu
integralność – kontrola dostępu do programu i danych
łatwość użytkowania – obsługa, łatwość wprowadzania danych i
korzystanie z danych wyjściowych
pielęgnowalność – łatwość zdiagnozowania i usunięcia usterek
elastyczność – łatwość modyfikacji programu
testowalność – łatwość testowania programu i stwierdzania
poprawności działania
przenośność do innego środowiska sprzętowego/programowego
możliwość ponownego użycia programu/części programu w innych
programach
współoperatywność – łatwość połączenia z innym systemem
* J. McCall, P. Richards, G. Walters: Factors in software quality, NTIS, 1977
9/33
Kontrola jakości
polega na ocenie różnorodności (minimalizacja
wśród egzemplarzy tego samego typu)
może odbywać się w oparciu o dane
historyczne
realizowana poprzez wykonywanie inspekcji,
przeglądów i testów
jest oceną skuteczności działań procesu
wytwórczego
czynności kontrolne mogą być częściowo lub
całkowicie zautomatyzowane lub prowadzone
„ręcznie”
10/33
Koszt jakości
analiza kosztu jakości może stanowić cenne
dane porównawcze w przyszłych
przedsięwzięciach oraz cenne źródło
poszukiwań możliwości zapewnienia jakości
mniejszymi środkami
składniki kosztu jakości:
czynności zapobiegające
ocena
usuwanie skutków
11/33
Składniki kosztu jakości
koszt zapobiegania
planowanie jakości
formalne przeglądy techniczne
testowanie
szkolenia
koszt oceniania
inspekcja procesu wytwórczego
konfigurowanie i pielęgnacja narzędzi
testowanie
koszt niepowodzeń wewnętrznych (przed udost. użytk.)
przeróbki, poprawki, analiza wykrytych błędów
koszt niepowodzeń zewnętrznych
analiza zgłoszonej usterki, zwrot lub wymiana produktu, pomoc
użytkownikom, naprawy gwarancyjne
12/33
Względny koszt poprawiania błędu na
różnych etapach procesu wytwórczego*
w
z
g
lę
d
n
y
k
o
s
z
t
p
o
p
ra
w
ia
n
ia
b
łę
d
u
1
3-6
10
15-40
30-70
40-1000
w
ym
ag
an
ia
pr
oj
ek
t
ko
do
w
an
ie
te
st
y
lo
ka
ln
e
te
st
y
sy
st
em
ow
e
po
w
dr
oż
en
iu
* B. Boehm: Software Engineering Economics, Prentice-Hall,1981
13/33
Zarządzanie jakością -TQM
termin ten powstał w latach 70-80 XX. wieku w Japonii
TQM – total quality management (kompleksowe
kierowanie jakością)
4 kroki zarządzania jakością
kaizen → usprawnianie realizowanego procesu wytwórczego
(przejrzysty, mierzalny, powtarzalny)
atarimae hinshitsu → analiza czynników negatywnie
wpływających na proces wytwórczy
kansei → analiza użytkowania produktu
miryokuteki hinshitsu → nowy produkt na bazie aktualnego
jako odpowiedź na odbiór produktu przez rynek
14/33
Czynności prowadzące do zapewnienia
jakości (zespół kontroli jakości)
planowanie zapewnienia jakości
sposoby oceny jakości
rodzaje inspekcji i przeglądów
normy wykorzystywane do realizacji przedsięwzięcia
procedury obsługi błędów (wyszukiwania i zgłaszania)
dokumentacja związana z kontrolą jakości
informacje dla zespołu wytwórczego
sprawdzanie zgodności modelu proc. wytw. z normami i planem
przedsięwzięcia
sprawdzanie zgodności prac wytwórczych z przyjętym rodzajem proc. wytw.
kontrola produktu roboczego z wymaganiami
zapewnienie dokumentowania i poprawianie sytuacji odstępstw od założeń
procesu wytwórczego i produktu
archiwizowanie dokumentacji o odstępstwach i niezgodnościach a także
raportowanie o tego typu sytuacji
15/33
Przeglądy techniczne
oprogramowania w kontroli jakości
prowadzą je głównie twórcy oprogramowania
cele
wykrycie błędów w oprogramowaniu
(funkcjonowanie, struktura logiczna, implementacja)
porównanie zgodności z założeniami
sprawdzenie zgodności z normami
uzyskanie spójnego sposobu wytwarzania
pomoc z zarządzaniu przedsięwzięciem
programistycznym
16/33
Statystyczne metody zapewnienia
jakości
zebranie, sklasyfikowanie i pogrupowanie danych o
usterkach
analiza przyczyn powstawania usterek (błędy
projektowe, naruszenie norm, niezgodność ze
specyfikacją, niepoprawna komunikacja z
użytkownikami)
wybór (wg zasady Pareto – 20% najważniejszych
zagrożeń powoduje 80% usterek) 20% głównych
przyczyn występowania usterek
rozwiązanie problemów powodujących wybrane (jak
wyżej) usterki
obliczanie indeksu błędów (EI)
17/33
Obliczanie indeksu błędów (EI)
indeks obliczany jest dla każdego etapu (i) procesu wytwórczego
indeks obliczany jest na podstawie tabeli zawierającej zestawienie
błędów z podziałem na rodzaj błędu i skutki: poważne (S
i
),
umiarkowane (M
i
), drobne (T
i
)
obliczanie wielkości produktu PS [w liniach kodu]
określanie wag błędów, zalecane wartości: w
s
=10, w
m
=3, w
t
=1
dla każdego etapu proc. wytw. oblicza się indeks etapu PI
i
PI
i
=w
s
(S
i
/E
i
)+w
m
(M
i
/E
i
)+w
t
(T
i
/E
i
),
gdzie E
i
– całkowita liczba błędów na i-tym etapie proc. wytw.
obliczanie indeksu błędów (wagi zwiększają się dla kolejnych etapów
procesu wytwórczego):
EI= Σ(i∙PI
i
)/PS=(PI
1
+2PI
2
+3PI
3
+…+iPI
i
)/PS
indeks błędów można wykorzystać do oceny poprawy jakości
wytwarzanego produktu (oprogramowania)
18/33
Niezawodność oprogramowania
jest stosunkowo łatwe do mierzenia i
prognozowania
jest to prawdopodobieństwo bezawaryjnego
działania programu komputerowego w
określonym środowisku przez określony czas*
w kontekście jakości i niezawodności
oprogramowania awaria jest rozumiana jako
niezgodność z wymaganiami
* J. D. Musa, A. Iannino, K. Okomuko: Engineering and managing software with reliability measures,
McGraw-Hill, 1987
19/33
Stosowanie modeli
niezawodności
istnieją 2 główne aspekty zastosowania modeli
niezawodności
ocena niezawodności wytworzonego produktu-
oprogramowania
mogą być użyte do oszacowania liczby niewykrytych defektów
w oprogramowaniu dostarczonym klientowi
aproksymowana liczba defektów może służyć jako:
miara jakości produktu
miara do szacowania nakładów niezbędnych w fazie serwisu
stosowane metryki
liczba defektów lub liczba defektów na tysiąc linii kodu
czas między awariami
20/33
Podział modeli niezawodności
statyczne → liczba defektów oceniana na podstawie innych
parametrów projektu lub jego części (rozmiar, złożoność,
umiejętności zespołu) oraz uwzględniają błąd spowodowany
śladowym wpływem mniej istotnych czynników, dane oparte na
poprzednich projektach (bieżący projekt traktowany jako kolejna
część poprzedniego), zwykle mniej dokładne niż dynamiczne, ale
sprawdzają się w przypadkach małych jednostek (modułów) jako
źródło wskazówek
dynamiczne → oparte na rozkładach statystycznych, korzystają
z wzorca pojawiania się defektów w aktualnym procesie, model
ten odpowiada w znacznym stopniu rzeczywistości, sprawdzają
się przy weryfikacji hipotez (wpływ czynników na jakość lub
niezawodność), dwa typy modeli: obejmujące cały proces
wytwórczy lub tylko fazę testów
21/33
Rozkład Weibulla
m
c
t
m
e
c
t
t
m
t
f
)
/
(
)
(
)
(
m
c
t
e
1
t
F
)
/
(
)
(
gęstość prawdopodobieństwa
skumulowana funkcja rozkładu
(dystrybunata)
m - współczynnik kształtu, c - współczynnik skali, t - czas
w analizie
niezawodności
oprogramowania
stosowano rozkłady
dla m=1 oraz m=2
0,0
0,5
1,0
1,5
2,0
0
0,5
1
1,5
2
2,5
3
m=0.5
m=1
m=2
m=4
m=6
22/33
Model Rayleigha
należy do rodziny rozkładów Weibulla
jest przypadkiem szczególnym dla m=2
krzywa gęstości prawdopodobieństwa rośnie do osiągnięcia maksimum,
potem maleje szybciej niż liniowo
po przyrównaniu pochodnej funkcji gęstości prawdopodobieństwa do 0
otrzymuje się zależność na t
m
– czas osiągnięcia maksimum: t
m
=c/sqrt(2)
po oszacowaniu t
m
można określić kształt krzywej rozkładu
obszar pod krzywą do punktu t
m
jest równy 39,35%
w rzeczywistych zastosowaniach wzór na funkcję gęstości
prawdopodobieństwa mnożony jest przez stałą K wyrażającą całkowitą
liczbę defektów lub łączną częstość defektów
badania doświadczalne dowodzą zgodność rzeczywistych danych z tym
modelem (np. wzorzec usuwania defektów)
23/33
Model Rayleigha
1984, Gafney, jednostka czasu – model 6 faz cyklu produkcji stosowany w IBM
Gafney zaobserwował duże podobieństwo występowania defektów w 6 fazach cyklu
produkcji oprogramowania do rozkładu Rayleigha
IO-przegląd projektu wysokiego poziomu, I1-przegląd projektu niskiego poziomu, I2-inspekcja
kodu, UT-test jednostki, CT-test komponentu, ST-test systemu, GA-faza ogólnej dostępności
faza produkcji
c
z
ę
s
to
ś
ć
d
e
fe
k
tó
w
IO
I1
I2
UT
CT
ST
GA
24/33
Założenia użycia krzywej Rayleigha do
modelowania jakości oprogramowania (1)
1.
częstość defektów wykrytych w procesie wytwarzania oprogramowania
jest dodatnio skorelowana z częstością defektów operacyjnych
(wykrytych przez użytkownika) → im wyższa krzywa, tym wyższa
częstość defektów operacyjnych (faza GA) i odwrotnie
faza produkcji
c
z
ę
s
to
ś
ć
d
e
fe
k
tó
w
IO
I1
I2
UT
CT
ST
GA
25/33
Założenia użycia krzywej Rayleigha do
modelowania jakości oprogramowania (2)
2.
im więcej defektów wykrytych i usuniętych we wczesnych faza
wytwarzania oprogramowania, tym mniej pozostanie ich w fazach
późniejszych (zakładając taką samą częstość wprowadzania
błędów w całym procesie) → poprawa końcowej jakości produktu
faza produkcji
c
z
ę
s
to
ś
ć
d
e
fe
k
tó
w
IO
I1
I2
UT
CT
ST
GA
26/33
Analiza zależności częstości
defektów – przykład*
tabela przedstawia przykładowe wartości współczynnika korelacji Spearmana (duża
fluktuacja danych) między częstościami defektów w fazach produkcji oraz częstością
defektów operacyjnych
badany produkt składał się z 65 komponentów, dostępne były dane o wprowadzaniu i
wykrywaniu defektów we wszystkich fazach wytwarzania, również w czasie
użytkowania
istotna korelacja istnieje dla faz I2, CT, ST oraz łącznie dla wszystkich, dane
potwierdzają 1. założenie modelu Rayleigha
potwierdzenie 2. złożenia: badania w IBM Houston (Developing Error-Free Software,
IEEE AES Magazine, 1988): odsetek wcześnie wykrytych defektów wzrósł z 50 do
85%, a częstość defektów operacyjnych spadła o ok. 70%
0,01
0,31
Łącznie (IO, I1, I2, CT, ST)
0,0001
0,49
test systemu (ST)
0,0001
0,48
test komponentu (CT)
0,02
0,28
kodowanie (I2)
nieważne
0,01
projekt niskiego poziomu (I1)
nieważne
0,11
projekt wysokiego poziomu (IO)
poziom ważności
wart. wsp. korelacji
faza
* S. H. Kan: Metryki i modele w inżynierii oprogramowania, WN PWN, Warszawa, 2006
27/33
Implementacje modelu
Rayleigha
SLIM (Software Life-cycle Model) – opracowany przez
Quantitative Software Management, pakiet pomagający
ocenić wymagane zasoby (środki, czas i koszty) projektu,
jedną z funkcjonalności jest szacowanie liczby defektów
oprogramowania
STEER (Software Error Estimation Reporter, IBM, 1985) –
wykorzystuje wersję dyskretną modelu Rayleigha, dane
procesu porównywane są z 11 wzorcami modelu oraz
wzorcami użytkownika, modele zapisane są w postaci
procentowego rozkładu liczby defektów w poszczególnych
fazach procesu wytwórczego, algorytm dopasowujący
składa się z transformacji logarytmicznej danych,
obliczania wskaźnika separacji między wprowadzonymi
danymi a modelami wzorcowymi oraz wybór modelu o
najniższym wskaźniku separacji
28/33
Miary niezawodności
w przypadku produktu typu maszyna awarie są najczęściej
spowodowane zużyciem, bardzo rzadko błędami projektowymi
w przypadku oprogramowania jest dokładnie odwrotnie: błędy zużycia
nie występują, awarie spowodowane są błędami projektowymi lub
implementacją
średni czas międzyawaryjny (mean time between failure, MTBF)
MTBF = MTTF + MTTR
MTTF – średni czas przedawaryjny (mean time to failure)
MTTR– średni czas do usunięcia awarii (mean time to repair)
dostępność oprogramowania (prawdopodobieństwo poprawnego
działania w losowo wybranej chwili)
dostępność = ( MTTF/( MTTF+MTTR ) )∙100%
MTBF zależy w równym stopniu od MTTF i MTTR, dostępność zależy
bardziej od MTTR
29/33
Normy jakości – ISO 9000
oznaczają zgodność metod wytwarzania produktu z
określonymi procedurami
celem stosowania jest zapewnienie jakości produktu
obejmują praktycznie każdy etap procesu wytwórczego,
począwszy do planowania, poprzez zarządzani,
prowadzenie pomiarów, testowanie, raportowanie
implementacja norm jest nie jest w nich zdefiniowana,
należy do zadań osób zarządzających firmą i procesem
wytwórczym
30/33
Norma ISO 9001
zawiera 20 wymagań do spełnienia przez system
zapewnienia jakości
zadania kierownictwa, system jakości, sprawdzanie projektów,
dokumentacji, danych, zarządzanie procesami wytwórczymi,
inspekcje i testowanie, czynności zapobiegawcze i naprawcze,
zarządzanie danymi o jakości, wewnętrzne kontrole jakości,
szkolenia i obsługa klienta, użycie metod statystycznych
specjalny zestaw procedur dla potrzeb wytwarzania
oprogramowania znajduje się w normie ISO 9000-3
31/33
Czynniki jakości w normie ISO 9126
najważniejsze cechy oprogramowania dobrej
jakości:
funkcjonalność
niezawodność
łatwość użytkowania
efektywność
pielęgnowalność
przenośność
32/33
Plan zapewnienia jakości
jest to schemat czynności zapewniających jakość
czynności:
określenie celu, zakresu i etapów proc. wytw. podlegających kontroli
określenie przywoływanych dokumentów i norm
rola zapewnienia jakości strukturze organizacyjnej firmy
zadania i czynności zapewnienia jakości
określenie dokumentacji przedsięwzięcia, dokumentacji technicznej
(specyfikacja, plany testów…), dokumentacji dla użytkownika (pomoc
itp.)
opis norm i zasad stosowanych w procesie wytwórczym oraz miar
produktu i procesu
lista przeglądów i audytów wraz z podaniem metod
testy: plany, procedury, gromadzenie i przechowywanie wyników,
raportowanie, procedury wykrywania i poprawiania usterek
narzędzia i metody wspomagania zapewnienia jakości
33
Dziękuję za uwagę
źródło: „Praktyczne podejście do inżynierii oprogramowania”, R.S. Pressman