Způsoby prevence chyb v software, metriky a oponentury. 

[aswi přednáška [file], aswi [file]]

Způsoby prevence chyb

Cíl: zabránit vzniku a dalšímu šíření chyby

Kontroly a měření meziproduktů (častější v úvodních fázích)+

Prověření meziproduktu nezávislým oponentem (dříve než se z něj začne vycházet v další práci)

Metafora řidič (udává směr, vysvětluje, naslouchá) + navigátor (dohledává, kontroluje, pomáhá) - svědomí páru (společný cíl, plné nasazení, komunikace)

Změna interní struktury software, která jej činí srozumitelnějším a snáze upravitelným, aniž by změnila jeho vnější chování

Změna designu, oprava

Podobné Faganovské inspekci, menší důraz na formálnost

Kontrola nezaujatým čtenářem

Autor prochází kód a vysvětluje

Měření

Přesnost a dokazatelnost, možnost statistik

GQM přístup, FURPS

Detekční a opravné techniky

Cíl: najít a opravit již existující chybu

Testování a ladění (typické v koncových fázích, tzv. výstupní kontrola)

Psaní čistého kódu 

snižuje riziko "ukrytí" zákeřných programových chyb už v prvotní fázi psaní kódu

podporuje efektivnější ladění

Refaktorizace kódu = změna struktury kódu, která nemá vliv na jeho celkovou funkčnost (přejmenování proměnné/metody, vyjmutí kódu do samostatné metody,..)

snížení složitosti kódu

Zpřehlednění

Kdy provádět revizi kódu? Ideální by bylo během nebo těsně po vlastní implementaci. Revize kódu je jedním ze základních aspektů párového programování (Pair Programming). Dvojice společně vyvíjí kód a revize probíhá neustále. Pokud neaplikujete párového programování, můžete nastavit povinnou revizi kódu při umisťování změn na server. Revizi můžete také provádět v rámci celého vývojového týmu na pracovních poradách.

Jak je revize kódu efektivní? Záleží na úrovni zkušeností vývojáře a "revizora". U začínajících vývojářů budou revize častější a revizorem by měl být zkušený pracovník. Při revizi kódu vytvořeného zkušeným vývojářem nemusí být objeveno mnoho chyb, ale celý proces může posloužit k tomu, že posluchačům budou předány zkušenosti a praktické rady. Technik revizí kódu je více a liší se svojí formálností, obsazením revizního týmu a způsobem evidence nalezených defektů.

Statická analýza (kontrola) kódu = analýza kódu, která je prováděna bez nutnosti spouštění programu – soubor preventivních technik. Ověření formální správnosti + dodržování pravidel + metriky

Nástroje: překladač a jeho hlášení

Testování je technika dynamické analýzy kódu. Psaní testů by podle metodologie Test-Driven Development (TDD) mělo předcházet vlastní implementaci. Zkuste si tento přístup zažít a uvidíte, že se vám zalíbí. A pokud ne, vězte, že testy stejně musíte napsat. Jinak se pro vás stane prvotní vývoj a především pozdější zásahy do produkčního kódu noční můrou. Testy jsou indikátory chybových stavů. 

První typ testů, který napíšete, budou jednotkové testy (unit test). Základní logika jednotkového testu je jednoduchá. Voláte metodu instance testované třídy s určitými vstupy a validujete výstupy. Pokud výstupy neodpovídají předpokladům, test selže a je nutno hledat chybu v implementaci. Lze prohlásit, že vyšší pokrytí testy lépe pojistí váš kód. Ale je také nutno dodat, že testy se nesmí psát jen z formality, ale musí být správně cílené na problémové situace. 

Pokud je test napsaný tak, že "vidí" do implementace, mluvíme o white-box testování. Pokud je testovaný kód pro test černou skříňkou, hovoříme o black-box testování. Oba přístupy mají své opodstatnění. Pomocí "bílého" testování snáze pokryjete všechny cesty provádění. "Černé" testování zase zosobňuje naivní přístup klientské strany, který může přinést nečekané způsoby volání.

Vyšší formou testů jsou integrační a systémové testy. Validují interakci více objektů a funkcionalitu větších celků. Pamatujte, že požadavky na kvalitu kódu testů jsou stejně přísná jako na vlastní testovaný (produkční) kód. Kód testů budete udržovat stejně dlouho jako produkční kód. Zjednodušeně shrnuto, testy by měly běžet krátkou dobu, na libovolném "kompatibilním" počítači, měly by po sobě uklidit a neměly by být na sobě vzájemně závislé.

Snažte se co nejvíce testů zautomatizovat, určitě se vám práce vyplatí. Bez automatizace nejsou některé typy testů vůbec proveditelné. Těžko se shání několik stovek uživatelů na zátěžové testy, kteří by v jednom čase začali používat a zatěžovat vaši aplikaci :)

Zautomatizovat se dá i interakce s uživatelským rozhraním vaší aplikace. Volba nástrojů závisí na technologii prezentační vrstvy.

Ruční testování

Automatizace buildů

Prototyp je funkčně zjednodušený základ (předobraz, demoverze) vyvíjeného systému. Měl by vzniknout relativně rychle a slouží k průběžné revizi požadavků. Prototyp můžete předvést investorovi a získat zpětnou vazbu. Prototyp je vyvíjen v cyklech. V každém cyklu jsou zapracovány získané připomínky.

Revize výstupů v předimplementačních fázích

Cyclomatic Complexity = složitost části programu (např. metody) co do množství větvení a cyklů. Tyto programové konstrukce zvyšují počet možných cest provádění programu. Vysoké číslo indikuje komplikovaně napsané složité metody, které je problematické pokrývat testy. Řešením je metodu rozbít do více menších metod.

Line Count (SLOC) vyjadřuje množství řádků kódu v metodách. Dlouhé metody jsou nepřehledné a dělají zřejmě více než jednu věc (pro danou úroveň abstrakce). Použitelnost takových metod je problematická, stejně jako pokrytí testy. Řešením je opět refaktorizace do více metod.

Objektové metriky jako Weighted Method Count (celková složitost metod ve třídě), Depth of Inheritance Tree (počet předků třídy) a Coupling Between Objects (provázanost mezi objekty) mohou indikovat problémy v objektovém návrhu. 

Z přednášek aswi [file]:

Matematické důkazy správnosti

Formální model systému - Petriho sítě, algebry (CSP) (a-priory nebo získaný analýzou kódu)

Model checker -> deadlock-free, liveliness, …

Indikátor někde je něco špatně

Stanovení očekávaných/správných hodnot

Průběžné monitorování

Korekce procesu, komponent při odchylkách

Z přednášek aswi [file]:

Proč měřit

Pomáhají najít slabiny -> zlepšení kvality, přesnosti, efektivity…

Dávají přehled a kontrolu nad projektem-produktem - plán, kvalita, splnění požadavků…

Přesnost a dokazatelnost

Možnost statistik a vizuální prezentace

Metrika, měření

Metrika = měřitelná charakteristika nějaké entity

Je získána na základě dat (primitivních metrik)

Měřený objekt - entita: produkt nebo proces

Metriky samy o sobě "k ničemu" -> měření

Plán měření - pro projekt

Co měřit, proč měřit, jak měřit

Organizational focus - záměr zlepšovat kvalitu

Vede k potřebě mít informace

Složitost, přehlednost

Počet UC, funkčních bodů

Možná někdy případně i také LOC

Kvalita (nepřímé metriky)

Pokrytí testy - kódu, požadavků

Charakteristiky defektů - hustota, výskyt

PMD, FindBugs, …

Jitter - change requesty a jejich zpracování, staff turnover, změny postupu a plánu

Breakage = průměrná váha změnu LOC / CR (lines of code / change request)

Pracnost celkem, přepočtená na Change Requesty

Jak měřit

Definovat cíl měření

Přístup k definování metrik

Rámec pro systém zaměřený na konkrétní problémy

Goal = problém + cíl měřícího programu

Question = měřené objekty a způsob měření

Nástroje pro měření

Spreadsheet, kalendář

Řízení měření

Plán měření

GQM přístup

Způsob získání dat

Též Faganovská inspekce

Skupinová technika, cílem je odhalit chyby v návrhu/kódu/dokumentu, sledování standardů, vzdělávání

Ne: dělat potíže autorovi (neúčast vedení), hledat nápravu chyb

Role ve skupině

Moderátor - řídí diskuzi

Průvodce - předkládá dílo

Autor - vysvětluje nejasnosti

Oponenti - hledají chyby, obvykle podle seznamů otázek

Příprava

Distribuce díla (moderátor), projití a hledání problémů (oponenti) - několik dní předem, cca 2 hodiny práce

Schůzka

Sekvenční procházení díla (průvodce či moderátor)

Vznášení připomínek

Zapisování nálezů (chyb a otevřených otázek)

Nejvýše 2 hodiny

Nepřipouštět dlouhé diskuze, řešení chyb (moderátor)

Možná následná schůzka pro vyřešení otázek

Závěry

Verdikt: v pořádku/drobné chyby/nutné přepracování/nová oponentura

Autor odstraní chyby dle nálezů, moderátor zkontroluje

Použitelné ve všech fázích životního cyklu

Velmi dobrá detekce chyb (až 75%)

Výsledkem jsou nižší náklady na vývoj a vyšší produktivita

Náročné na čas

Je třeba zkušenost
