2. 12. 2013 © Jiří Sochor, Jaroslav Ráček 1
Řízení kvality SW produktů
2. 12. 2013 © Jiří Sochor, Jaroslav Ráček 2
Klasický pohled na kvalitu SW
Každý program dělá něco správně; nemusí však dělat to,
co chceme, aby dělal.
Kvalita: Dodržení explicitně stanovených funkčních a výkonových
požadavků, dodržení explicitně dokumentovaných vývojových
standardů a implicitních charakteristik, které jsou očekávány
u profesionálně vyrobeného software.
Aspekty kvality:
- odchylky od požadavků na software
- nedodržení standardů
- odchylky od běžných zvyklostí (implicitních požadavků)
2. 12. 2013 © Jiří Sochor, Jaroslav Ráček 3
Nový pohled - spojité chápání kvality
2. 12. 2013 © Jiří Sochor, Jaroslav Ráček 4
Kvalita - IEEE Std. 610.12-1990
Stupeň, do jaké míry systém, komponenta nebo proces splňuje
specifikované požadavky.
Stupeň, do jaké míry systém, komponenta nebo proces splňuje
zákazníkovy nebo uživatelovy potřeby nebo jeho očekávání.
2. 12. 2013 © Jiří Sochor, Jaroslav Ráček 5
Faktory kvality software
Přímo měřitelné faktory
- #chyb/KLOC/čas
Pouze nepřímo měřitelné faktory
- použitelnost, udržovatelnost
Kategorie faktorů kvality:
- operační charakteristiky
- schopnost akceptovat změny
- adaptibilita na nové prostředí
2. 12. 2013 © Jiří Sochor, Jaroslav Ráček 6
Faktory kvality - McCall
2. 12. 2013 © Jiří Sochor, Jaroslav Ráček 7
Faktory kvality - McCall
2. 12. 2013 © Jiří Sochor, Jaroslav Ráček 8
Relativní cena odstranění závady
Zdroj: Barry W. Boehm, 1981, COCOMO
2. 12. 2013 © Jiří Sochor, Jaroslav Ráček 9
IBM ortogonální klasifikace defektů (ODC)
• Funkce - chyba ovlivňující schopnosti, rozhraní uživatelů,
rozhraní výrobku, rozhraní s HW architekturou nebo globální datovou
strukturou.
• Rozhraní - chyba při interakci s ostatními komponentami nebo ovladači
přes volání, makra, řídící bloky nebo seznamy parametrů.
• Ověřování - chyba v logice programu, která selže při validaci dat a
hodnot před tím, než jsou použity.
• Přiřazení - chyba při inicializaci datové struktury nebo bloku kódu.
• Časování/serializace - chyba, která zahrnuje časování sdílených a RT
prostředků.
• Sestavení/balení/spojování - chyba související s problémy s repozitory
projektu, změnami vedení, nebo správou verzí.
• Dokumentace - chyba, která ovlivňuje publikace a návody pro údržbu.
• Algoritmus - chyba, která se týká efektivity nebo správnosti algoritmu
nebo datové struktury, ne však jejich návrhu.
2. 12. 2013 © Jiří Sochor, Jaroslav Ráček 10
Typ defektu a asociace s etapou
Chillarege et al
• funkce
• rozhraní
• ověřování
• přiřazení
• časování/serializace
• sestavení/balení/spojování
• dokumentace
• algoritmus
• návrh
• návrh na nízké úrovni
• návrh na nízké úrovni nebo kód
• kód
• návrh na nízké úrovni
• knihovní nástroje
• publikace
• návrh na nízké úrovni
Typ defektu Vývojová etapa
2. 12. 2013 © Jiří Sochor, Jaroslav Ráček 11
Funkční selhání podle etapy
Chillarege et al
2. 12. 2013 © Jiří Sochor, Jaroslav Ráček 12
Rozložení druhů chyb při testování
Chillarege et al
2. 12. 2013 © Jiří Sochor, Jaroslav Ráček 13
SQA - Software Quality Assurance
2. 12. 2013 © Jiří Sochor, Jaroslav Ráček 14
Produkty podle etap
Software
Concept
Requirements
Analysis
Design
Coding and
Debugging
Systems
Testing
Deployment &
Maintenance
Possible Deliverables by Phase
 Concept Document
 Statement of Work (SOW)
 Project Charter
 RFP & Proposal
 Requirements Document (Software Requirements Specification)
 Work Breakdown Structure (WBS)
 Functional Specification ( Top Level Design Specification)
 Entity Relationship Diagram
 Data Flow Diagram
 Detailed Design Specification
 Object Diagrams
 Detailed Data Model
 Coding Standards
 Working Code
 Unit Tests
 Acceptance Test Procedures
 Tested Application
 Maintenance Specification
 Deployed Application
 Project Development Plan
 (Software Development Plan )
 Baseline Project Plan
 Quality Assurance Plan
 Configuration Management Plan
 Risk Management Plan
 Integration Plan
 Detailed SQA Test Plan
 SQA Test Cases
 User Documentation
 Training Plan
2. 12. 2013 © Jiří Sochor, Jaroslav Ráček 15
Přínos SQA
Etapa Cena nalezení a opravy
Požadavky 0.75
Návrh 1.0
Kódování 1.5
Testování 3.0
Systémové testy 10.0
Provoz 60-100.0
Pozn.: Cena normalizovaná vzhledem k ceně v etapě návrhu
2. 12. 2013 © Jiří Sochor, Jaroslav Ráček 16
Přezkoušení SW
• Konverzace
• Přezkoušení mezi
spolupracovníky
• Neformální prezentace
• Formální prezentace
• Prohlídka
• Recenze, inspekce
Méně formální
Více formální
• V literatuře je argumentováno (např. Pressman), že efektivita
roste se zvyšující se formálností.
• Probíhá v období tvorby kódu, odstranění nalezených
nedostatků je relativně levné.
2. 12. 2013 © Jiří Sochor, Jaroslav Ráček 17
Typy formálního přezkoušení
TYP METODY TYPICKÉ CÍLE TYPICKÉ VLASTNOSTI
Prohlídky Minimální náročnost
Školení vývojářů
Krátká doba
Malá/žádná příprava
Neformální proces
Žádné měření
Žádné FTR (Formal
Technical Review)
Odborné
recenze
Zjištění požadavků
Rozlišení nejednoznačností
Školení
Formální proces
Představení autora
Rozsáhlá diskuze
Inspekce Účinné a efektivní zjištění a
odstranění všech defektů
Formální proces
Kontrolní seznam
Měření
Fáze přezkoušení
2. 12. 2013 © Jiří Sochor, Jaroslav Ráček 18
Cíle formálního přezkoušení
• Odhalit chyby ve funkci, logice a implementaci software.
• Ověřit, že zkoumaná položka splňuje požadavky (odpovídá
požadavkům).
• Zajistit, že položka byla prezentována s použitím
předdefinovaných standardů.
• Zajistit jednotný vývoj.
• Zvýšit řiditelnost projektů.
2. 12. 2013 © Jiří Sochor, Jaroslav Ráček 19
• Testování je proces spuštění programu s cílem nalézt chyby.
• Dobrý testovací případ má vysokou pravděpodobnost
nalezení dosud nenalezené chyby.
• Úspěšný test je takový, který odhalí dosud neodhalenou
chybu.
- Myers
Co je testování?
2. 12. 2013 © Jiří Sochor, Jaroslav Ráček 20
V - procesní model
Product
Requirements and
Specification
Analysis
Project
Requirements and
Planning
Production,
Operations, and
Maintenance
System Testing
and Acceptance
Testing
Integration and
Testing
Unit Testing
Coding
Detailed Design
High-Level Desig
Non-functional
Requirements
Load &
Performance Test
User Interface
Design
Usability Test
2. 12. 2013 © Jiří Sochor, Jaroslav Ráček 21
V - procesní model
2. 12. 2013 © Jiří Sochor, Jaroslav Ráček 22
• Testování nemůže ukázat nepřítomnost defektů, může pouze
ukázat, že v softwaru jsou chyby.
• Testování také ukazuje funkce a výkon.
• A je také ukazatelem kvality software.
Co testování ukazuje?
2. 12. 2013 © Jiří Sochor, Jaroslav Ráček 23
Každý inženýrský výrobek může být testován dvěma způsoby:
• test proti specifikovaným funkcím = Validace
“Dělat správné věci”
• test proti vnitřní činnosti = Verifikace
“Dělat věci správně”
Verifikace &Validace
2. 12. 2013 © Jiří Sochor, Jaroslav Ráček 24
Testování v týmu
Testování je destruktivní činnost!
Programátor není dobrým testerem vlastního výtvoru.
Detailní znalost struktury programu usnadňuje hledání
a opravu chyb.
Je nutná spolupráce dvou nezávislých, organizačně
samostatných týmů.
Tým kvality Realizační tým
2. 12. 2013 © Jiří Sochor, Jaroslav Ráček 25
„Černé a bílé skříňky“
FUNKCE - test činnosti každé funkce
- test ČERNÉ SKŘÍŇKY
VNITŘNÍ PRÁCE - test, zda ‘všechny motory pracují’
- test BÍLÉ SKŘÍŇKY
2. 12. 2013 © Jiří Sochor, Jaroslav Ráček 26
Testování „bílá skříňka“
• Zohledňuje strukturu programu
• Pokrývá
– provedené příkazy
– cesty průchodu kódem
2. 12. 2013 © Jiří Sochor, Jaroslav Ráček 27
Testování „bílá skříňka“
1. výpočet cyklomatické
složitosti:
počet rozhodnutí + 1
(predikátové uzly)
nebo
počet ploch (oblastí)
nebo
hrany – uzly + 2
2. 12. 2013 © Jiří Sochor, Jaroslav Ráček 28
Testování „bílá skříňka“
2. Nalezneme nezávislé cesty.
Protože cyklomat. složitost = 4
existují 4 nezávislé cesty:
cesta 1: 1,2,3,6,7,8
cesta 2: 1,2,3,5,7,8
cesta 3: 1,2,4,7,8
cesta 4: 1,2,4,7,1,2,4,...7,8
2
4
3
5 6
7
8
1
2. 12. 2013 © Jiří Sochor, Jaroslav Ráček 29
Testování jednotek, modulů
• Typ testování „bílá skříňka“
- někdy ale jako „černá skříňka“
• Kdo testuje jednotky?
- vývojáři
- testy jednotek jsou programovány
– stejný jazyk jako moduly
– alt.název “Testovací drivery”
• Individuální testy mohou být seskupeny
- „Kolekce testů“ (Test suites)
• Kdy se testují jednotky?
- postupně během vývoje
- po dokončení individuálních modulů
2. 12. 2013 © Jiří Sochor, Jaroslav Ráček 30
Integrace & Testování
• Vývoj/integrace/testování
- nejčastější místo, kde dochází k překrývání aktivit
• Někdy je integrace/testování považováno za jednu
etapu
• Postupně propojuje funkcionalitu
• QA tým pracuje souběžně s vývojovým týmem
2. 12. 2013 © Jiří Sochor, Jaroslav Ráček 31
Integrační postupy
Shora dolů
• Nejprve je implementováno jádro (kostra) systému.
• Zkombinováno do minimální „skořápky“ systému.
• Pro doplnění neúplných částí se použijí „protézy“
nahrazované postupně aktuálními moduly.
Zdola nahoru
• Začne s individuálními moduly a sestavuje zdola.
• Individuální jednotky (po testování jednotek) jsou
kombinovány do subsystémů.
• Subsystémy jsou kombinovány do celku.
2. 12. 2013 © Jiří Sochor, Jaroslav Ráček 32
Testování shora-dolů, zdola-nahoru
Shora-dolů (TDT): použití „stubs“ (pahýly, protézy) - jednoduché
náhražkové objekty se shodným rozhraním.
Zdola-nahoru(BUT): klasický testovací proces s nadřazenými testovacími
objekty - „drivers“.
Testování shora-dolů odhaluje chyby analýzy a návrhu, je v souladu
s prototypováním.
2. 12. 2013 © Jiří Sochor, Jaroslav Ráček 33
Integrační testování
A B C D
A B
C D
Testování modulů
Integrační testování
Kde je chyba ?
Inkrementální integrace a testování
2. 12. 2013 © Jiří Sochor, Jaroslav Ráček 34
Klasifikace metrik
• Metriky produktu
- Explicitní výsledky vývoje SW
- Kód, výstupy, moduly, dokumentace …
• Metriky procesu
- Činnosti spojený s vývojem SW
• Metriky zdrojů
- Zdroje (vstupy) procesu vývoje SW
- Hardware, znalosti, lidé
2. 12. 2013 © Jiří Sochor, Jaroslav Ráček 35
Měření složitosti
• LOC – velikost kódu je funkcí složitosti SW
• Závisí na programovacím jazyce a schopnostech
programátorů
• Halstead’s Software Science
– n1: počet odlišných operátorů
– n2 : počet odlišných operandů
– N1: počet všech operátorů
– N2: počet všech operandů
2. 12. 2013 © Jiří Sochor, Jaroslav Ráček 36
Příklad
if (k < 2)
{
if (k > 3)
x = x*k;
}
• Odlišné operátory: if ( ) { } > < = * ;
• Odlišné operandy: k 2 3 x
• n1 = 10
• n2 = 4
• N1 = 13
• N2 = 7
2. 12. 2013 © Jiří Sochor, Jaroslav Ráček 37
Halsteadovy metriky
• Délka: N = N1 + N2
• Slovník: n = n1 + n2
• Odhadnutá délka: Ñ = n1 log2 n1 + n2 log2 n2
- Odhad pro dobře strukturované programy
• Poměr čistoty: PR = Ñ / N
2. 12. 2013 © Jiří Sochor, Jaroslav Ráček 38
Cyklomatická složitost
• Množina nezávislých cest grafem
• V(G) = E – N + 2
- E je počet hran
- N je počet uzlů
• V(G) = P + 1
- P je počet větvení (na 2 cesty)
2. 12. 2013 © Jiří Sochor, Jaroslav Ráček 39
Cyklomatická složitost - Flow Graph
2. 12. 2013 © Jiří Sochor, Jaroslav Ráček 40
Cyklomatická složitost
• V(G) je počet oblastí grafu.
• Počet oblastí roste s počtem větvení a cyklů.
• Kvantitativní metrika obtížnosti testování.
• Indikátor spolehlivosti.
• Praxe ukazuje, že hodnota V(G) by neměla překročit 10,
jinak bude testování velmi složité.
2. 12. 2013 © Jiří Sochor, Jaroslav Ráček 41
Metriky návrhu
• Složitost struktur
• Složitost dat
• Složitost systému
• Složitost struktur S(i) modulu i
- S(i) = fout
2(i)
- fout (i) počet přímo podřízených (volaných) modulů
2. 12. 2013 © Jiří Sochor, Jaroslav Ráček 42
Metriky návrhu
• Složitost dat D(i)
- D(i) = v(i) / [ fout(i) +1]
- v(i) množství vstupů a výstupů modulu i
• Složitost systému C(i)
- C(i) = S(i) + D(i)
2. 12. 2013 © Jiří Sochor, Jaroslav Ráček 43
Připojení modulů
• Datové a řídící toky
- di - vstupní datové toky do modulu
- ci - vstupní řídící toky do modulu
- do - výstupní datové toky z modulu
- co - výstupní řídící toky z modulu
• Globální struktury
- gd - globální datové proměnné
- gc - globální řídící proměnné
• Okolí
- w - počet volaných modulů
- r - počet modulů, které volají modul
2. 12. 2013 © Jiří Sochor, Jaroslav Ráček 44
Metriky propojení
Mc = k/m (k =1)
m = di + aci + do + bco + gd + cgc + w + r
a, b, c, k jsou nastaveny na základě aktuálních dat (zkušeností)
2. 12. 2013 © Jiří Sochor, Jaroslav Ráček 45
Globální hodnocení kvality výroby SW
Vyspělost organizace: model CMM
Systémy kvality: norma ISO 9001
Ocenění kvality: cena MBNQA
2. 12. 2013 © Jiří Sochor, Jaroslav Ráček 46
CMM - Capability Maturity Model
Úroveň 1: Výchozí
Chaotický proces, nepředvídatelná cena, plán a kvalita.
Úroveň 2: Opakovatelný
Intuitivní; cena a kvalita jsou vysoce proměnlivé, plán je pod
vědomou kontrolou, neformální metody a procedury.
Klíčové prvky :
- řízené požadavky
- plánování softwarového projektu
- řízené subkontrakty na software
- zajištění kvality software
- řízení softwarových konfigurací
také SEI model (Software Engineering Institute, Carnegie-Mellon Univ. ), revize 1993
2. 12. 2013 © Jiří Sochor, Jaroslav Ráček 47
CMM - Capability Maturity Model
Úroveň 3: Definovaný
Orientován na kvalitu; spolehlivé ceny a plány, zlepšující se, ale
dosud nepředvídatelný přínos (výkon) systému kvality.
Klíčové prvky:
- zlepšování organizačního procesu
- definice organizačního procesu
- školicí program
- řízení integrovaného software
- aplikace inženýrských metod u softwarového produktu
- koordinace mezi pracovními skupinami
- detailní prověrky a oponentury
2. 12. 2013 © Jiří Sochor, Jaroslav Ráček 48
CMM - Capability Maturity Model
Úroveň 4: Řízený
Kvantitativní; promyšlená statisticky řízená kvalita produktu.
Klíčové prvky:
- měření a kvantitativní řízení procesu výroby
- řízení kvality
Úroveň 5: Optimalizující
Kvantitativní základ pro kontinuální investice směřující
k automatizaci a zlepšení výrobního procesu.
Klíčové prvky:
- prevence chyb
- inovace technologie
- řízené změny výrobních procesů
2. 12. 2013 © Jiří Sochor, Jaroslav Ráček 49
Vztah mezi MBNQA a ISO 9001
ISO
MBNQA