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