====== Kategorizace SW chyb, kritéria korektnosti a použitelnosti, spolehlivost SW(A4M33TVS) ====== ===== Softwarová chyba ===== * Prezentace toho, že program nedělá něco nepředpokládaného * Míra toho, kdy program přestává být užitečný (lidem) * Je to nesouhlas mezi programem se specifikací pouze tehdy, jestliže specifikace existují a jsou správné ===== Softwarové chyby ===== * **Pochybení**: Akce člověka, která produkuje nesprávný výsledek. * **Vada**: Nesprávný krok, proces nebo definice dat v počítačovém programu. Výsledek pochybení. Potenciálně vede k selhání. * **Selhání**: Nesprávný výsledek. Projev vady. * **Chyba**: Kvantitativní vyjádření toho, na kolik je výsledek nesprávný {{:statnice:si:swerr.png?500| Sw. chyby [1.]}} ===== Kategorie softwarových chyb ===== * **Chyby uživatelského rozhraní** * Problémy s funkčností - program nedělá něco, co by měl dělat nebo to dělá nevhodně(zmatečně, neúspěšně), lze některé operace provést obtížně * To co se "předpokládá" od programu, žije pouze v mysli uživatele * Všechny programy mají problémy s funkčností vzhledem k různým uživatelům * Funkční problém je chybou, pokud očekávání uživatele jsou rozumná * **Vstupy** * Jak lze nalézt, jak program používat (jaká je nápověda)? * Jak snadné je ztratit se v programu? * Jaké chyby uživatel dělá a kolik ho to stojí času? * Co mu chybí? * Nutí prg. uživatele přemýšlet nepřirozeně? * **Výstupy** * Rychlost je základ interaktivního sw. * Cokoli co budí dojem pomalého prg. je problém. * Získá uživatel, co potřebuje? * Mají výstupy smysl? * Může uživatel přizpůsobit výstup potřebám? * Zle výstup přesměrovat dle potřeby(monitor, tisk, soubor...)? * **Chyby omezení** * Chyby zpracování vyjímek zahrnující neschopnost * Předvídání možnosti chyby a bránit se jim * Zpracování podmínek chyby * Zpracovaní detekované chyby různými způspby * Chyby hraničních podmínek * Nejjednodušší hranice jsou numerické * Mezní nároky na paměť, za kterých program může pracovat * Výpočetní chyby * Chyby aritmetiky jsou časté a obtížně detekovatelné * Program ztrácí přesnost během výpočtu vlivem zaokrouhlovacích chyb a ořezání * Výpočetní chyby způsobené chybnými algoritmy * **Procesní chyby** * Sekvenční * Počáteční a jiné speciální stavy * Funkce mohou selhat při prvním použití, např. chybějící inicializační informace či soubory * Nastaví se skutečně vše do výchozího bodu, vymažou se všechna data, jestliže uživatel provede reset programu? * Chyby řízení nastane, pokud program provede chybný příští krok * Extrémní chyba nastane, pokud se program zastaví nebo vymkne kontrole řízení * Paralelní * Chyby souběhu - race error * Jedny z nejméně testovaných * Nastávají v multiprocesových sys. a integračních sys. * Velmi obtížně se opakují * Zátěžové podmínky * Program se začne chovat chybně pokud se přetíží * Chyby velkého //objemu// - hodně práce za dlouhou dobu * Chyby velkého //stresu// - hodně práce v daném okamžiku * Všechny programy mají své limity, ale je důležité vědět co nastane * **Chyby vedení** * Hardware - program posílá chybová data na zařízení, ignorují chybové kódy přicházející zpět a zkouší použít zařízení, která neexistují nebo jsou aktuálně vytížená * Řízení zdrojů a vedení * Staré problémy se opět objevují, pokud programátor zakomponuje do programu nějakou starou verzi komponenty * Ujistěte se, že program má správný copyright, vstupní obrazovky a čísla verzí * Dokumentace - slabá dokumentace může způsobit ztrátu víry uživatele, že sw. pracuje spráně * Chyby testování * Chyby udělané testy jsou nejčastějšími chybami objevenými během testování * Jestliže program navádí většinu uživatelů ke způsobení chyb, pak je špatně navržen * **Chyby požadavků, vlastností a funkčnosti** * Požadavky a specifikace * Neúplné, nejednoznačné, vzájemně si odporující * Hlavní zdroj drahých chyb * Chyby vlastností - chybějící, chybné, nevyžádané vlastnosti * Interakce vlastností - nepredikované interakce(přesměrování telefonu ve smyčce) * Preventivní opatření proti chybám ve specifikacích a vlastnostech: * Problém v komunikaci člověk-člověk * Jazyk formálních specifikací poskytující krátkodobé řešení, avšak neřeší problém chyb v dlouhodobém horizontu. * **Strukturální chyby** * Chyby v řízení sekvencí * Příkaz GOTO * Většina chyb řízení (v novém kódu) se dá snadno testovat a je chycena během testování jednotek * Neupravený starý kód může mít řadu chyb v řídicím toku * Stlačování za účelem kratšího prováděcího času nebo menšího nároku na paměť je špatná politika * Chyby zpracování * Zahrnuje chyby vyhodnocení aritmetických, algebraických nebo matematických fcí. a výběr algoritmu * Řada problému vznikne špatnou konverzí dat na jinou reprezentaci * Chyby logiky * Neporozumění jak se selekční či logické operátory chovají samostatně nebo v kombinacích * Neporozumění sémantice uspořádání logických výrazů a jeho vyhodnocení specifickými překladači * Chyby datového toku - nevztahují se k chybám řízení * Chyby toku řízení - část logického výrazu, která je použita pro ovládání toku řízení * Inicializační chyby - opomenutí inicializace pracovního prostoru, registů, nebo části dat * Chyby a anomálie toku dat * Nastane pokud existuje cesta, při které se udělá s daty něco neodůvodněného např. použití neinicializované proměnné, nebo neexistující proměné * Jsou stejně tak důležité jako anomálie toku řízení * **Datové chyby** * Lze je nalézt ve specifikacích datových objektů, jejich formátů, počtu nebo jejich počátečních hodnotách * Sw. se vyvíjí k tabulkám obsahujících řídicí a procesní fce. * Trendy programování vedou k zvýšenému používání nedeklarovaných, interních, speciálních programovacích jazyků * Dynamické vs. statické * Protože efekt poškození dynamických dat se může projevit velmi vzdáleně od příčiny, nalézají se takovéto chyby velmi obtížně * Základní problém zbytků ve sdílených zdrojích (např. vyčištění po použití uživatelem, sdílené čištění pomocí ovladače zdrojů, žádné čištění) * Informace, parametr, řízení * Údaj plní jednu ze tří rolí: jako parametr, jako řízení, jako zdroj informace * Informace je obvykle dynamická s tendencí lokality pro danou transakci (nedostatek ochranného kódu validace dat) * Neadekvátní validace dat často vede k ukazování prstem * Obsah, struktura, atributy * Obsah - aktuální bitový vzor, řetězec znaků, nebo číslo vložené do datové struktury * Struktura - velikost, tvar a počty popisující datové položky * Atributy - specifikace významu (sémantika) * Základem je explicitní dokumentace obsahu, struktury a atributů všech datových objektů * **Chyby implementace** * Chyby kódování * Dobrý překladač chytne syntaktické chyby, nedeklarovaná data, procedury, kód a mnoho inicializačních problémů * Častou chybou kódu jsou dokumentační chyby (komentáře) * Úsilí programování je dominováno údržbou * Chyby paměti * Charakteristiky * Nejobtížnější chyby z hlediska lokalizace * Nejdůležitější chyby z hlediska opravy * Projevy nesprávného obsahu paměti jsou nepredikovatelné * Chyby v obsahu paměti se typicky projevují vzdáleně od jejich příčiny * Chyby zůstávají často nedetekováné dokud nejsou náhodně spuštěny * Typy chyb * Chyby hranic polí * Přístup přes nesefinovaný ukazatel * Čtení z neinicializované paměti * Chyby ztráty paměti (memory leaks) * Slabá místa výkonnosti * Kolekce vyčerpávající přesné množiny dat pro výkonnostní test programu a každé jeho komponenty (profilování) * Zaměření se na kritická data * Sběr správně vybraných dat * Řádka - kolikrát proběhla každá řádka - nejpřesnější, ale nejnáročnější na sběr dat * Funkce - méně podrobné než předchozí * Čas - data se sbírají z údajů časovaných běhů funkcí. Data jsou správná pro daný běh, ale závisí na stavu mikroprocesoru a paměti. Nejméně náročný sběr ===== Kritéria korektnosti a použitelnosti ===== == Komunikace == Mate pravdu, kriteria korektnosti a pouzitelnosti byla v prednaskach zminena pouze okrajove. Syllabulus predmetu byl napsan totiz nekym jinym, takze jsem mel troche problemy s tim, co vlastne autor zminenou otazkou myslel, nebot "obchodni" fantazirovani na tema "kriteria korektnosti a pouzitelnosti" se do naseho predmetu nehodi, ackoliv v 90. Letech na dane tema byla napsana rada knih. Bohuzel, zmenit obsah predmetu zvlaste kdyz se dane tema dostane do statnicovych otazek neni jednoduche. Pro Vasi potrebu, moznou kratkou a jasnou definici, z meho pohledu plne dostacujici, lze nalezt na http://it.toolbox.com/wiki/index.php/Software_Quality_Metrics http://www.testingstandards.co.uk/living_glossary.htm Zdravi Radek Marik ===== Spolehlivost softwaru ===== často definovaná jako pravděpodobnost, že systém, vozidlo, stroj, zařízení, atd. bude vykonávat svou zamýšlenou funkci v daných operačních podmínkách po specifikovanou dobu. ===== Modely spolehlivosti softwaru ===== používají se k odhadu spolehlivosti nebo počtu zbývajících defektu softwarového produktu, který byl uvolněn mezi zákazníky. **Důvody použití: ** - Objektivní vyjádření kvality produktu - Plánování zdrojů pro fázi údržby sw. **Sledovanou proměnnou** studovaných kritérií je počet defektu (nebo rychlost defektu normalizovaná počtem řádku kódu) za daný casový interval (týdny, měsíce, atd.), nebo doba mezi dvěma selháními. === Statický model === používá atributy projektu nebo programových modulu k odhadu počtu defektu v softwaru. * Parametry modelu jsou odhadovány na základě řady předchozích projektů. == Základní předpoklady == * Rychlost defektu pozorovaných během vývojového procesu je positivně korelovaná s rychlostí defektu v poli nasazení * Za předpokladu stejné rychlosti injektáže chyb, čím více defektů je objeveno a odstraněno dříve, tím méně jich zůstane na pozdější fáze. * Princip **"Udělej to správně hned napoprvé"**: jestliže každý krok vývojového procesu se provede s minimálním vznikem chyb, pak finální produkt bude dobrý. Rovněž znamená, ze vzniklé chyby se mají odstraňovat co nejdříve. == Weibullova distribuce == * Jedna ze tří známých distribucí extremálních hodnot * Konce hustory pravděpodnosti se blíží asymptoticky k nule, ale nikdy ji nedosáhnou. * Kumulativní distribuční funkce (CDF): {{:statnice:si:vz1.png?200|}} * funkce hustoty pravděpodobnosti (PDF): {{:statnice:si:vz2.png?200|}} * Pokud se aplikuje v softwaru, pak PDF typicky znamená hustotu defektů (rychlosti) v době přírustkového vzoru defektů (platné defekty) a CDF znamená kumulativní vzor přírustku defektů. {{:statnice:si:pdfchart.png?300|}} == Rayleighuv model == * Patří do rodiny Weibullových distribucí. * m = 2 == Spolehlivost a validace predikce == * **Spolehlivost** vyjadřuje stupeň změny výstupu modelu vzhledem k možnostem fluktuací ve vstupních datech. * čím užší je konfidenční interval, tím je odhad spolehlivější. * Větší vzorky vedou na užší konfidenční intervaly. * Používejte pokud možno více modelů a spoléhejte se na jejich společné hodnocení. * Základní podmínkou dosažen platnosti predikce je zajištění přesnosti a spolehlivosti vstupních dat. * Platnost se hodnotí porovnáním odhadu z modelů a jejich skutečných hodnot. === Dynamický model === * Používá průběžného vývoje vzoru defektů k odhadu spolehlivosti finálního produktu. * Je založen na exponenciálním rozložení a růstu spolehlivosti - vrchol přírůstků defektů je předpokládán na počátku, po té klesá. * Modely růstu spolehlivosti se obvykle odhadují z dat fáze formálního testování. * Odůvodnění vychází z toho, že vzory procesu přírůstku defektů této fáze jsou vhodným indikátorem spolehlivosti produktu pociťovanou zákazníky. * Během tohoto testování po fázi vývoje, kdy se objevují selhání, identifikují a opravují defekty, se softwarový produkt stává stabilnější a jeho spolehlivost roste s časem. Tyto modely se proto nazývají **modely růstu spolehlivosti.** * Parametry dynamických modelů jsou odhadovány na základě mnoha údaju zaznamenaných o hodnoceném produktu k danému datu. * Kategorie: * Modeluje se celý vývojový proces. Model vychází s Rayleighova modelu. * Modeluje se fáze formálního testování. Model vychází z exponenciálního modelu a jiných modelů růstu spolehlivosti. == Exponenciální model == {{:statnice:si:expmodel.png?500|}} == Model doby mezi selháním == * Očekává se, že doby následných selhání se prodlužují po každém odstranění defektu. * Často se předpokládá, že doba mezi selháním (//i - 1//) a //i// řídí rozložením, jehož parametry mají vztah k počtu skrytých defektů setrvávajících v produktu po (//i - 1//) selháních. == Modely počtu vad == * Počet vad či selhání (nebo normalizované rychlosti) ve specifikovaném časovém intervalu. * Časový interval je pevný //aprioiri//. * Počet defektů nebo selhání pozorovaných během intervalu se považuje za náhodnou proměnnou. * Očekává se, že se počet pozorovaných selhání za jednotku času bude zmenšovat. == Model Jelinski-Moranda (J-M) == * Jeden z prvních modelu sw. spolehlivoasti - 1972 * model doby mezi selháním * Předpoklady: * Sw. má //N// nedostatků na počátku testování * Selhání se projeví čistě náhodně * Všechny vady přispívají rovnocenně k příčině selhání během testování * Čas opravy je zanedbatelný * Oprava defektu je dokonalá * Hazardní funkce v čase //t_i//, doba mezi selháním (//i - 1//) a //i//, je dána: {{:statnice:si:j-m.png?200|}} * Hazardní fce je konstantou mezi dvěma selháními, ale zmenšuje se po krocích /fí po každém odstranění defektu. * Jak se jednotlivé vady odstraňují, očekává se že doba k dalšímu selhání bude delší. == Modely Littlewooda (LW) == * Podobné předchozímu J-M * Předpokládá se, že různé vady mají různou velikost a nerovnost příspěvků k selhání. * Vady většího rozsahu mají tendenci být detekovány a opraveny dříve * Zohledněním velikosti chyby se předpoklady přibližují realitě * V reálných podmínkách (reálný sw. projekt) předpoklad rovnocenné rychlosti selhání pro všechny vady běžně vůbec nenastává //[[http://labe.felk.cvut.cz/~marikr/teaching/A4M33TSV_10/Handouts/13.spolehlivost.pdf | 13. přednáška TVS]] obsahuje další dynamické modely: // * Goel-Okumotuv (G-O) model nedokonalého opravování * Vychází z dokonalé opravy J-M * Goel-Okumotuv model nehomogenního Poissonova procesu (NHPP) *počet selhání v daných intervalech testování * NHPP model * Musa-Okumotuv (M-O) model logaritmického Poissonova prováděcího času * počet selhání v čase se řídí nehomogenním Poissonovým procesem * Zpožděný S model - předpokládá zpožděný vrchol nárůstu defektů * Zohledňuje nutnost analýzy selhání - nestačí pouze detekovat chybu, je potřeba ji detekovat * Založen na nehomogen. Poissonovým procesem s různou fcí. střední hodnoty * Inflexní S model - předpokládá pozdější a ostřejší vrchol nárůstu defektů * Model růstu spolehlivosti sw. * Čím více detekovaných defektů, tím více nedetekovaných selhání se stává detekovatelných ===== Materiály ====== - [[http://labe.felk.cvut.cz/~marikr/teaching/A4M33TSV_10/Handouts/03.softwaroveChyby.pdf | 3. přednáška TVS]] - [[http://oi-wiki.cz/lib/exe/fetch.php/courses/a4m33tvs/tvs_priprava_zk.pdf | TVS – zkouška 2010/2011 ]] - [[http://labe.felk.cvut.cz/~marikr/teaching/A4M33TSV_10/Handouts/13.spolehlivost.pdf | 13. přednáška TVS]]