Rozdíly

Zde můžete vidět rozdíly mezi vybranou verzí a aktuální verzí dané stránky.

Odkaz na výstup diff

statnice:si:a4m33tvs1 [2011/05/14 13:51]
tape
statnice:si:a4m33tvs1 [2025/01/03 18:29] (aktuální)
Řádek 1: Řádek 1:
-====== Kategorizace SW chyb, kriteria ​korektnosti a použitelnosti,​ spolehlivost SW(A4M33TVS) ======+====== Kategorizace SW chyb, kritéria ​korektnosti a použitelnosti,​ spolehlivost SW(A4M33TVS) ======
    
-=== Sw. chyba ===   +===== Softwarová ​chyba =====   
-This is a list +  Prezentace toho, že program nedělá něco nepředpokládaného ​ 
-  * The second item +  * Míra toho, kdy program přestává být užitečný (lidem) ​ 
-    * You may have different levels +  * Je to nesouhlas mezi programem se specifikací pouze tehdy, jestliže specifikace existují a jsou správné
-  * Another item+
  
  
- ​* ​Prezentace toho, že program nedělá něco nepředpokládaného ​ +===== Softwarové chyby =====  
- ​* ​Míra tohokdy program přestává být užitečný (lidem) ​ +  ​* ​**Pochybení**:​ Akce člověka, která produkuje nesprávný výsledek. 
- ​* ​Je to nesouhlas mezi programem se specifikací+  **Vada**: Nesprávný krokproces 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.]}}
  
-=== 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|}} 
  
 +===== 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
  
-=== Materiály ====   ​ + 
-- [[http://​labe.felk.cvut.cz/​~marikr/​teaching/​A4M33TSV_10/​Handouts/​03.softwaroveChyby.pdf | 3. přednáška TVS]] + 
 +===== 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]]
  
  
statnice/si/a4m33tvs1.1305373906.txt.gz · Poslední úprava: 2025/01/03 18:25 (upraveno mimo DokuWiki)
Nahoru
chimeric.de = chi`s home Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0