Inżynieria oprogramowania
wykład 7
Zapewnienie jakości
oprogramowania
1
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
2/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) (z
ródło: pl.wikipedia.org)
Cyceron wprowadził łaciński odpowiednik qualitas,
tłumaczone jako ang. quality (z
ródło: pl.wikipedia.org)
 wartość czegoś (z
ródło: http://sjp.pwn.pl)
 istotne cechy przedmiotu wyróżniające go spośród
innych (z
ródło: http://sjp.pwn.pl/)
3/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)
4/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
5/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
6/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
7/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
8/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
9/33
Koszt jakości
analiza kosztu jakości może stanowić cenne
dane porównawcze w przyszłych
przedsięwzięciach oraz cenne z
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
10/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
11/33
Względny koszt poprawiania błędu na
różnych etapach procesu wytwórczego*
40-1000
30-70
15-40
10
3-6
1
* B. Boehm: Software Engineering Economics, Prentice-Hall,1981
12/33
względny koszt poprawiania błędu
a
e
i
i
t
n
n
k
e
a
y
y
a
u
i
e
g
o
w
j
w
st
st
e
n
a
p
o
o
o
e
e
n
e
r
l
t
t
d
m
ż
m
p
a
y
o
o
e
k
r
k
w
o
st
d
l
y
w
s
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 odpowiedz
na odbiór produktu przez rynek
13/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
14/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
15/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)
16/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 (Si),
umiarkowane (Mi), drobne (Ti)
obliczanie wielkości produktu PS [w liniach kodu]
określanie wag błędów, zalecane wartości: ws=10, wm=3, wt=1
dla każdego etapu proc. wytw. oblicza się indeks etapu PIi
PIi=ws(Si/Ei)+wm(Mi/Ei)+wt(Ti/Ei),
gdzie Ei  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"PIi)/PS=(PI1+2PI2+3PI3+& +iPIi)/PS
indeks błędów można wykorzystać do oceny poprawy jakości
wytwarzanego produktu (oprogramowania)
17/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
18/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
19/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
z
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
20/33
Rozkład Weibulla
m t
f (t) =� �� ( )m �� e-� (t / c )m
gęstość prawdopodobieństwa
t c
m
-� ( t / c )
skumulowana funkcja rozkładu
F (t ) =� 1 -� e
(dystrybunata)
2,0
m - współczynnik kształtu, c - współczynnik skali, t - czas
1,5
w analizie
1,0 niezawodności
oprogramowania
stosowano rozkłady
0,5 dla m=1 oraz m=2
0,0
0 0,5 1 1,5 2 2,5 3
m=0.5 m=1 m=2 m=4 m=6
21/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 tm  czas osiągnięcia maksimum: tm=c/sqrt(2)
po oszacowaniu tm można określić kształt krzywej rozkładu
obszar pod krzywą do punktu tm 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)
22/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 I1 I2 UT CT ST GA
faza produkcji
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
23/33
częstość defektów
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
IO I1 I2 UT CT ST GA
faza produkcji
24/33
częstość defektów
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óz
niejszych (zakładając taką samą częstość wprowadzania
błędów w całym procesie) poprawa końcowej jakości produktu
IO I1 I2 UT CT ST GA
faza produkcji
25/33
częstość defektów
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%
faza wart. wsp. korelacji poziom ważności
projekt wysokiego poziomu (IO) 0,11 nieważne
projekt niskiego poziomu (I1) 0,01 nieważne
kodowanie (I2) 0,28 0,02
test komponentu (CT) 0,48 0,0001
test systemu (ST) 0,49 0,0001
A
ącznie (IO, I1, I2, CT, ST) 0,31 0,01
* S. H. Kan: Metryki i modele w inżynierii oprogramowania, WN PWN, Warszawa, 2006 26/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 wskaz
nika separacji między wprowadzonymi
danymi a modelami wzorcowymi oraz wybór modelu o
najniższym wskaz
niku separacji
27/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
28/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
29/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
30/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ść
31/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
32/33
Dziękuję za uwagę
z
ródło:  Praktyczne podejście do inżynierii oprogramowania , R.S. Pressman
33