Verifikace a certifikace softwaru. Metody ověřování a testování softwaru Automatická statická analýza programů

Pojmy „ověření“ a „validace“ se v odborné literatuře velmi často používají a jsou spojovány s analýzou kvality jakéhokoli softwaru. V odborné literatuře lze nalézt různé výklady těchto pojmů. Pokusme se tedy tento problém pochopit.

Nejsprávnější je z našeho pohledu následující definice. Validace a ověřování jsou činnosti, které jsou zaměřeny na provádění kontroly kvality s cílem odhalit v ní chyby v rané fázi. Zdálo by se, že mají společný cíl. Ale přesto mají tyto druhy rozdíly ve zdrojích kontrolovaných vlastností, omezení a pravidel, jejichž nedodržení lze považovat za chybu.

Verifikace je ověření shody softwaru se specifikací požadavků, architekturou nebo „Povinnostmi“ tohoto pojmu je porovnání postupu výpočtu s procesem jejich vývoje, pravidly a standardy.

Ověření dat lze provést za účelem zjištění souladu provozu programu se zavedenými normami, požadavky, rozhodnutími o návrhu a uživatelskou dokumentací. Tyto dokumenty zároveň podléhají povinnému předběžnému ověření, s nímž je provedeno porovnání shody s jejich normami a předpisy platnými v zemi, kde je software provozován. Je nutné počítat s dodržením všech posloupností prováděných operací.

V případě zjištění chyby nebo závady v provozu programu nebo zjištění rozporu mezi výše uvedenými dokumenty a dosavadním fungováním programu by mělo být rozhodnutí o výběru dokumentu k opravě samostatným úkolem.

Na rozdíl od verifikace je validace zodpovědná za ověření, že vyvíjené nebo udržované softwarové produkty splňují potřeby nebo potřeby zákazníků nebo uživatelů. Tyto potřeby často nejsou zaznamenány v žádné dokumentaci. Proto je validace méně formalizovaná než verifikace. Jedná se o proces, ve kterém je přítomen zástupce zákazníka, uživatele a může být také přítomen analytik nebo expert v Jinými slovy ti, kteří mohou vyjádřit konkrétní potřeby a skutečné potřeby zainteresovaných stran.

Verifikace je odpovědí na otázku „Je software proveden správně?“ a validace je odpovědí na otázku „Je software proveden správně?“.

Při hledání odpovědi na položené otázky lze zjistit, že validace (či certifikace) z hlediska obsahu má o něco širší význam než verifikace (verifikace). Verifikace však úzce souvisí se zajištěním kontroly kvality softwarových produktů.

Například verifikace počítačového programu zahrnuje proces, jehož cílem je zajistit, aby požadavky na data získaná v určitém životním cyklu produktu odpovídaly požadavkům získaným v předchozí fázi.

Pokud se budeme bavit o verifikaci modelu, tak zde budeme hovořit o kontrole správnosti zobrazení tohoto výpočtového modelu potřebného konceptuálního popř.

Při ověřování systémového kódu se analyzuje zdrojové kódování a kontroluje se jeho soulad s dokumentárním popisem.

Proces ověřování může zahrnovat operace obsahující alternativní výpočty. Technická a vědecká dokumentace nového projektu je porovnána s odpovídající dokumentací stávajícího projektu, povinné testování, schválení nového softwarového produktu a demonstrace výsledků.

20. Verifikace a validace softwaru

Verifikace a validace odkazuje na procesy ověřování a kontroly, které ověřují, že software odpovídá jeho specifikaci a požadavkům zákazníka. Verifikace a validace pokrývají celý životní cyklus softwaru – začínají ve fázi analýzy požadavků a končí verifikací programového kódu ve fázi testování hotového softwarového systému.

Ověření a atest není totéž, i když je snadné je zaměnit. Stručně, rozdíl mezi nimi lze definovat takto:

Verifikace odpovídá na otázku, zda je systém správně navržen;

Certifikace odpovídá na otázku, zda systém funguje správně.

Verifikace podle těchto definic kontroluje, zda software odpovídá specifikaci systému, zejména funkčním a nefunkčním požadavkům. Certifikace je obecnější proces. Během ověřování se musíte ujistit, že softwarový produkt splňuje očekávání zákazníka. Validace se provádí po ověření s cílem zjistit, jak systém splňuje nejen specifikaci, ale také očekávání zákazníka.

Jak již bylo zmíněno dříve, ověřování systémových požadavků je velmi důležité v raných fázích vývoje softwaru. V požadavcích se často vyskytují chyby a opomenutí; v takových případech konečný produkt pravděpodobně nebude splňovat očekávání zákazníka. Validace požadavků však samozřejmě nemůže odhalit všechny problémy ve specifikaci požadavků. Někdy se mezery a chyby v požadavcích odhalí až po dokončení implementace systému.

Procesy ověřování a validace používají dvě hlavní techniky pro kontrolu a analýzu systémů.

1. Kontrola softwaru. Analýza a ověření různých reprezentací systému, jako je dokumentace specifikace požadavků, architektonická schémata nebo zdrojový kód programu. Kontrola se provádí ve všech fázích procesu vývoje softwarového systému. Souběžně s kontrolou lze provádět automatickou analýzu zdrojového kódu programů a souvisejících dokumentů. Inspekce a automatizovaná analýza jsou statické metody ověřování a validace, protože nevyžadují spustitelný systém.

2. Testování softwaru. Spuštění spustitelného kódu s testovacími daty a prozkoumání výstupu a výkonu softwarového produktu za účelem ověření, že systém funguje správně. Testování je dynamická metoda ověřování a ověřování, protože je aplikována na běžící systém.

Na Obr. Obrázek 20.1 ukazuje místo kontroly a testování v procesu vývoje softwaru. Šipky označují fáze vývojového procesu, kde lze tyto metody použít. Podle tohoto schématu lze provádět kontrolu ve všech fázích procesu vývoje systému a testování - když je vytvořen prototyp nebo spustitelný program.

Kontrolní metody zahrnují: kontrolu programu, automatickou analýzu zdrojového kódu a formální ověření. Statické metody však mohou pouze zkontrolovat, zda programy odpovídají specifikaci, nelze je použít ke kontrole správného fungování systému. Navíc nefunkční charakteristiky jako výkon a spolehlivost nelze testovat statickými metodami. Proto se pro vyhodnocení nefunkčních charakteristik provádí testování systému.

Rýže. 20.1. Statické a dynamické ověřování a atestace

Navzdory rozšířenému používání kontroly softwaru je testování stále převládající metodou ověřování a certifikace. Testování je ověření chodu programů s daty podobnými skutečným, které budou zpracovány za provozu systému. Přítomnost závad a nesrovnalostí s požadavky v programu se zjišťuje zkoumáním výstupních dat a identifikací anomálních mezi nimi. Testování se provádí během implementační fáze systému (pro ověření, že systém splňuje očekávání vývojářů) a po dokončení jeho implementace.

V různých fázích procesu vývoje softwaru se používají různé typy testování.

1. Testování defektů vedeny za účelem zjištění nesrovnalostí mezi programem a jeho specifikací, které jsou způsobeny chybami nebo závadami v programech. Tyto testy jsou navrženy tak, aby odhalovaly chyby v systému, a ne aby simulovaly jeho provoz.

2. Statistické testování vyhodnocuje výkon a spolehlivost programů a také provoz systému v různých provozních režimech. Testy jsou navrženy tak, aby napodobovaly skutečný provoz systému s reálnými vstupními daty. Spolehlivost systému je hodnocena počtem poruch zaznamenaných při práci programů. Výkon je hodnocen měřením celkové doby provozu a doby odezvy systému při zpracování testovacích dat.

Hlavním účelem ověřování a kvalifikace je ujistit se, že systém je „vhodný pro daný účel“. Vhodnost softwarového systému pro zamýšlený účel neznamená, že by měl být absolutně bez chyb. Systém by spíše měl být přiměřeně vhodný pro účely, pro které byl určen. Požadované platnost shody závisí na účelu systému, očekávání uživatelů a tržních podmínkách pro softwarové produkty.

1. Účel softwaru.Úroveň spolehlivosti shody závisí na tom, jak kritický je vyvinutý software podle určitých kritérií. Například úroveň spolehlivosti systémů kritických z hlediska bezpečnosti by měla být výrazně vyšší než úroveň spolehlivosti prototypových softwarových systémů vyvíjených k demonstraci nějaké nové myšlenky.

2. Očekávání uživatelů. Se smutkem je třeba poznamenat, že v současné době má většina uživatelů nízké nároky na software. Uživatelé jsou tak zvyklí na poruchy, ke kterým dochází při běhu programů, že je to nepřekvapí. Jsou ochotni tolerovat selhání systému, pokud výhody jeho používání převažují nad nevýhodami. Od počátku 90. let však tolerance uživatelů k poruchám softwarových systémů postupně klesá. V poslední době je vytváření nespolehlivých systémů téměř nepřijatelné, a tak společnosti zabývající se vývojem softwaru musí věnovat verifikaci a validaci softwaru stále více pozornosti.

3. Podmínky na trhu se softwarem. Při hodnocení softwarového systému musí prodávající znát konkurenční systémy, cenu, kterou je kupující ochoten za systém zaplatit, a očekávanou dobu uvedení tohoto systému na trh. Pokud má vývojářská společnost více konkurentů, je nutné určit datum vstupu systému na trh před ukončením plného testování a ladění, v opačném případě mohou konkurenti vstoupit na trh jako první. Pokud zákazníci nejsou ochotni nakupovat software za vysokou cenu, mohou být ochotni tolerovat více selhání systému. Při stanovení nákladů na proces ověřování a kvalifikace je třeba vzít v úvahu všechny tyto faktory.

Chyby jsou v systému zpravidla nalezeny při ověřování a atestaci. V systému se provádějí změny za účelem opravy chyb. Tento proces ladění obvykle integrován s dalšími ověřovacími a atestačními procesy. Nicméně testování (nebo obecněji verifikace a validace) a ladění jsou různé procesy, které mají různé cíle.

1. Verifikace a validace je proces zjišťování závad v softwarovém systému.

2. Ladění - proces lokalizace defektů (chyb) a jejich opravy (obr. 20.2).

Rýže. 20.2. Proces ladění

Neexistují žádné jednoduché metody pro ladění programů. Zkušení debuggerové najdou chyby porovnáním testovacích výstupních vzorů s výstupem testovaných systémů. Lokalizace chyby vyžaduje znalost typů chyb, výstupních vzorů, programovacího jazyka a procesu programování. Znalost procesu vývoje softwaru je velmi důležitá. Ladicí programy jsou si vědomy nejběžnějších programovacích chyb (jako je zvýšení čítače). Bere také v úvahu chyby, které jsou typické pro určité programovací jazyky, například ty spojené s používáním ukazatelů v jazyce C.

Lokalizace chyb v kódu programu není vždy jednoduchý proces, protože chyba se nemusí nutně nacházet poblíž bodu v kódu programu, kde došlo k havárii. Aby izoloval chyby, debugger vyvíjí další softwarové testy, které pomáhají identifikovat zdroj chyby v programu. Možná budete muset ručně sledovat provádění programu.

Interaktivní ladicí nástroje jsou součástí sady nástrojů jazykové podpory, které jsou integrovány se systémem kompilace kódu. Poskytují speciální prostředí pro provádění programu, jehož prostřednictvím můžete přistupovat k tabulce identifikátorů a odtud k hodnotám proměnných. Uživatelé často řídí provádění programu způsobem krok za krokem, postupným přecházením od příkazu k příkazu. Po provedení každého příkazu jsou zkontrolovány hodnoty proměnných a identifikovány možné chyby.

Chyba nalezená v programu je opravena, poté je nutné program znovu zkontrolovat. Chcete-li to provést, můžete znovu zkontrolovat program nebo zopakovat předchozí test. Opakované testování se používá k zajištění toho, že změny provedené v programu nezanesly do systému nové chyby, protože v praxi se vysoké procento „oprav chyb“ buď nedokončí úplně, nebo do programu zavedou nové chyby.

V zásadě je nutné po každé opravě spouštět všechny testy znovu při retestování, ale v praxi je tento přístup příliš drahý. Proto se při plánování procesu testování zjišťují závislosti mezi částmi systému a pro každou část jsou přiřazeny testy. Poté je možné sledovat prvky programu pomocí speciálních testovacích případů (řídících dat) vybraných pro tyto prvky. Pokud jsou zdokumentovány výsledky trasování, pak lze k testování změněného programového prvku a jeho závislých komponent použít pouze podmnožinu celkové sady testovacích dat.

Odeslat svou dobrou práci do znalostní báze je jednoduché. Použijte níže uvedený formulář

Studenti, postgraduální studenti, mladí vědci, kteří využívají znalostní základnu ve svém studiu a práci, vám budou velmi vděční.

Hostováno na http://www.allbest.ru/

Esej

Metody ověřování a testování softwaru

Úvod

Lidé mají tendenci dělat chyby. Chyby vždy byly a budou. V IT prostředí existuje vtip, že pokud se program spustí napoprvé a hned funguje, tak je potřeba hledat chybu.

Spolu s rozvojem výpočetní techniky, s jejím pronikáním do všech sfér života, roste i počet chyb v programech. Růst chyb je navíc neúměrný růstu počtu programů. Každý rok se řady programátorů doplňují o bydlokodéry (jmenují se legie), kteří exponenciálně rozvíjejí pole chyb.

Chyby nejsou viditelné ve všech oblastech. Nikoho například nezajímají chyby a zranitelnosti v prohlížečích jako „amigo“. Ano, a ztráty z takových chyb jsou zanedbatelné: maximum, které může běžný uživatel ztratit, jsou účty na sociálních sítích, jeden a půl tisíce průměrných fotografií z dovolené a sbírka porna.

Existují však oblasti, ve kterých mohou chyby v programování vést k nejnešťastnějším důsledkům. Jedním z prvních případů, které se mi podařilo najít, byla kosmická loď Mariner 1, která byla zničena 22. července 1962, 293 sekund po startu, kvůli chybě v programu palubního počítače. Je dobře, že tehdy nedošlo k žádnému úmrtí.

A co se stane, když palubní počítač Boeingu-747 se čtyřmi stovkami pasažérů na palubě vyhodí výjimku?

Právě pro oblasti, které lze nazvat „seriózní“, byly vynalezeny metody ověřování a testování.

V některé zahraniční literatuře jsou procesy ověřování a testování identifikovány a někde je testování považováno za jeden ze způsobů ověřování. Tuto práci provedu podle svého nejlepšího porozumění, samostatně zvažuji procesy ověřování a testování. Pro spravedlnost se také dotknu tématu validace softwaru.

1. Definice

Životní cyklus(LC) software. Tento termín označuje časový interval od myšlenky na vytvoření softwaru s potřebnou funkčností k vyřešení určitých problémů až do úplného ukončení používání nejnovější verze tohoto programu.

Artefaktyživotní cyklus softwaru (SW). Patří sem různé informační materiály související s tvorbou softwaru. Jedná se o zadání, popis architektury, zdrojový kód, uživatelskou dokumentaci a další dokumenty. Materiály, které byly použity při vývoji, ale nebyly zaznamenány v přístupné podobě (například komentáře v kódu a zneužití vývojářů v chatu), nejsou artefakty.

2. Ověření

Ověření kontroluje shodu některých artefaktů vytvořených v průběhu vývoje a údržby softwaru s jinými dříve vytvořenými nebo použitými jako počáteční data a také shodu těchto artefaktů a jejich vývojových procesů s pravidly a standardy. Při ověřování se kontroluje zejména soulad mezi normami norem, popis požadavků (referenčních podmínek) na software, konstrukční řešení, zdrojový kód, uživatelská dokumentace a fungování samotného softwaru. Kromě toho se ověřuje, že požadavky, konstrukční řešení, dokumentace a kódy jsou vypracovány v souladu s normami a standardy přijatými v dané zemi, odvětví a organizaci při vývoji softwaru a také, že při jejich tvorbě jsou všechny operace specifikované v standardy byly provedeny správným způsobem. Chyby a závady zjištěné při ověřování jsou nesrovnalosti nebo rozpory mezi několika uvedenými dokumenty, mezi dokumenty a skutečným provozem programu, mezi normami standardů a skutečnými procesy vývoje a údržby softwaru. Samostatným úkolem je přitom rozhodnout, který dokument se má opravit (možná oba).

Výše uvedené je oficiální definice ověřování. Ve skutečnosti je vše mnohem jednodušší: ověření určuje děláme program správně?.

Hlavními metodami ověřování jsou tedy zkoumání a kontrola.

ověření odbornosti programu

3. Validace

Proces validace kontroluje shodu jakýchkoli artefaktů vytvořených nebo používaných během vývoje a údržby softwaru s potřebami a požadavky uživatelů a zákazníků tohoto softwaru, přičemž se berou v úvahu zákony dané oblasti a omezení kontextu používání softwaru. software.

A za spoustou slov se opět skrývá velmi jednoduchý úkol: při validačním procesu se kontroluje, zda tito uživatelé/zákazníci určitou funkcionalitu programu potřebují. Splňuje softwarový produkt přání zákazníků a koncových uživatelů?

4. Testování

Testování je proces odhalování chyb v softwaru prováděním kódu softwarového systému na testovacích datech, shromažďování výkonnostních charakteristik v dynamice provádění v konkrétním operačním prostředí, identifikace různých chyb, defektů, selhání a nedostatků způsobených nepravidelnými a abnormálními situacemi. nebo abnormální ukončení softwaru.

Historicky prvním typem testování bylo ladění.

Ladění je kontrola popisu programového objektu v programovacím jazyce s cílem odhalit v něm chyby a následně je odstranit. Chyby jsou detekovány kompilátorem při jejich syntaktické kontrole. Po odladění se provede verifikace pro kontrolu správnosti kódu a validace pro kontrolu, zda produkt splňuje zadané požadavky.

1. Statické zkušební metody

Statické metody se používají při provádění kontrol a přezkoumávání specifikací komponent bez jejich implementace. Technika statické analýzy spočívá v metodickém přezkoumání a analýze struktury programů a také v prokazování jejich správnosti. Statická analýza je zaměřena na analýzu dokumentů vytvořených ve všech fázích životního cyklu a spočívá v kontrole zdrojového kódu a end-to-end kontrole programu.

Softwarová kontrola je statická kontrola souladu programu s danými specifikacemi, prováděná analýzou různých reprezentací výsledků návrhu (dokumentace, požadavky, specifikace, schémata nebo zdrojový kód programu) v procesech životního cyklu. Revize a kontroly výsledků návrhu a jejich soulad s požadavky zákazníků zajišťují vyšší kvalitu vytvářených softwarových systémů.

2. Metody dynamického testování

Metoda černé skříňky. Při použití této metody jsou použity informace o řešeném problému, ale není známo nic o struktuře programu. Cílem testování podle tohoto principu je identifikovat maximální počet chyb v jednom testu pomocí malé podmnožiny možných vstupních dat.

Testovací metody podle tohoto principu se používají k testování funkcí implementovaných v programu kontrolou nesouladu mezi skutečným chováním funkcí a očekávaným chováním s přihlédnutím ke specifikacím požadavků. Během přípravy na toto testování jsou sestaveny stavové tabulky, grafy příčin a následků 1 a oblasti poruch. Kromě toho jsou připraveny testovací sady, které berou v úvahu parametry a podmínky prostředí ovlivňující chování funkcí.

Metoda bílé krabice.

Tato metoda umožňuje prozkoumat vnitřní strukturu programu a detekce všech chyb v programu je kritériem pro vyčerpávající testování tras řídicích toků, mezi které patří:

Kritérium pokrytí operátora - sada testů v souhrnu musí zajistit, aby každý operátor prošel alespoň jednou;

Kritérium testování větví (neboli pokrytí rozhodování nebo pokrytí přechodu) – sada testů v agregaci musí zajistit, aby každá větev nebo výstup prošel alespoň jednou.

3. Funkční testování

Účelem funkčního testování je odhalit nesrovnalosti mezi skutečným chováním implementovaných funkcí a očekávaným chováním podle specifikace a výchozích požadavků. Funkční testy by měly pokrývat všechny implementované funkce s ohledem na nejpravděpodobnější typy chyb. Testovací scénáře, které kombinují jednotlivé testy, jsou zaměřeny na kontrolu kvality řešení funkčních problémů.

Funkční testy jsou vytvářeny podle specifikací funkcí, návrhových informací a textu v programovacím jazyce a slouží ke zjištění úplnosti implementace funkčních úloh a jejich souladu s výchozími požadavky.

Mezi úkoly funkčního testování patří:

Identifikace souboru funkčních požadavků;

Identifikace externích funkcí a konstrukce sekvencí funkcí v souladu s jejich použitím v softwarovém systému;

Identifikace souboru vstupních dat každé funkce a určení oblastí jejich změny;

Konstrukce testovacích sad a scénářů pro testovací funkce;

Identifikace a prezentace všech funkčních požadavků pomocí testovacích případů a testovacích chyb v programu a při interakci s prostředím.

Testy vytvořené z návrhových informací jsou spojeny s datovými strukturami, algoritmy, rozhraními mezi jednotlivými komponentami a slouží k testování komponent a jejich rozhraní. Hlavním cílem je zajistit úplnost a konzistenci implementovaných funkcí a rozhraní mezi nimi.

5. Typy chyb ANSI/IEEE-7 29 -8 3

Chyba (chyba) - stav programu, ve kterém jsou vytvářeny nesprávné výsledky, jejichž příčinou jsou chyby (chyby) v programových příkazech nebo v technologickém procesu jeho vývoje, což vede k nesprávné interpretaci výchozí informace. , a tedy k nesprávnému rozhodnutí.

Defekt (chyba) v programu - důsledek chyb vývojáře v jakékoli fázi vývoje, které mohou být obsaženy v originále nebo specifikacích návrhu, textech programových kódů, provozní dokumentaci atd. Během provádění programu může být zjištěna závada nebo selhání.

Selhání (selhání) je odchylka programu od fungování nebo neschopnost programu plnit funkce definované požadavky a omezeními, která je považována za událost, která přispívá k přechodu programu do nefunkčního stavu v důsledku chyb. , latentní vady nebo poruchy ve fungujícím prostředí. Selhání může být způsobeno následujícími důvody:

Chybná specifikace nebo vynechaný požadavek, což znamená, že specifikace přesně neodráží to, co uživatel zamýšlel;

Specifikace může obsahovat požadavek, který nelze na daném hardwaru a softwaru splnit;

Návrh programu může obsahovat chyby (např. databáze je navržena bez prostředků ochrany proti neoprávněnému přístupu uživatele, ale ochrana je nutná);

Program může být nesprávný, tzn. provádí neobvyklý algoritmus nebo není plně implementován.

Závěr

Ruské GOST týkající se ověřování a testování softwaru jsou překlady „buržoazních“ norem, jako jsou ISO 12207, ANSI/IEEE-729-83 a další (je jich spousta). Problém je v tom, že tyto mezinárodní standardy řeší otázky testování a ověřování odlišně. Neříkám, že si úplně odporují, ale mohou způsobit zmatek.

Všechny tyto normy byly formulovány v 80. letech minulého století pro americký vesmírný průmysl. V následujících letech byly opraveny a znovu publikovány, ale neshody a rozpory v dokumentech zůstaly.

Závěr: struktura metod ověřování, validace a zkoušení by měla být považována za podmíněnou.

Bibliografie

1. Volná encyklopedie wikipedia.org

2. Kulyamin V.V. Metody ověřování softwaru M.: Institut pro systémové programování, 2008

3. Lavrishcheva E., Petrukhin V. Přednáška "Metody pro kontrolu a testování programů a systémů": NOU "INTUIT" http://www.intuit.ru/studies/professional_retraining/944/courses/237/print_lecture/6130

Hostováno na Allbest.ru

Podobné dokumenty

Životní cyklus softwaru je nepřetržitý proces, který začíná rozhodnutím o nutnosti vytvořit software a končí jeho úplným vyřazením z provozu. Rileyho, Lehmanův a Boehmův přístup k definici životního cyklu softwaru.

abstrakt, přidáno 01.11.2009


Koncepce technologie vývoje programu. Základ návrhu softwaru. Modely životního cyklu, které vznikly historicky během vývoje teorie návrhu softwaru. Spirálové (spirální), kaskádové a iterační modely.

prezentace, přidáno 05.11.2015


Historie vývoje a typy testování softwaru. Instalace, regrese, konfigurace, integrace, lokalizace, testování jednotek. Metody pro snížení složitosti unit testování vyvíjené aplikace.

semestrální práce, přidáno 16.12.2015


Nerozhodnutelnost problému testování softwaru. Typy a úrovně testování. Upstream a Downstream testovací strategie. Metody "bílé" a "černé" krabice. Automatické a ruční testování. Vývoj prostřednictvím testování.

semestrální práce, přidáno 22.03.2015


Požadavky na technologii návrhu softwaru (SW). Složení a popis fází kompletního životního cyklu softwaru. Klasifikace modelů životního cyklu softwaru, jejich vlastnosti. Metodiky vývoje softwaru, extrémní programovací techniky.

prezentace, přidáno 19.09.2016


Historie testování softwaru, hlavní cíle a rysy jeho implementace. Typy a typy testování, úrovně jeho automatizace. Využití a výzkum potřebných technologií. Celý cyklus běhu celého monitorovacího systému.

práce, přidáno 03.05.2018


Základní mezinárodní standardy v oblasti informačních technologií. Mezinárodní norma ISO/IEC 9126. Kvalita a životní cyklus. Charakterizace vnitřních a vnějších atributů kvality. Analýza funkčnosti softwaru.

zpráva, přidáno 13.06.2017


Cíle a cíle softwarového inženýrství. Pojem software. Šest zásad pro efektivní používání softwaru. Typy softwaru: celosystémový, síťový a aplikovaný. Principy tvorby softwaru.

semestrální práce, přidáno 29.06.2010


Obecná charakteristika hlavních modelů životního cyklu: kaskádový, inkrementální, spirálový. Fáze jako součást procesu vývoje softwaru, omezená na konkrétní časový rámec a končící vydáním konkrétního produktu.

prezentace, přidáno 27.12.2013


Informatizace Ruska. Trh se softwarem. Hlavní úkoly standardizace, certifikace a licencování v oblasti informatizace. Soubor inženýrských metod a nástrojů pro tvorbu softwaru. Životní cyklus softwaru.

Tyto dva pojmy validace a ověřování jsou často zaměňovány. Ověření systémových požadavků je navíc často zaměňováno s ověřováním systému. Doporučuji se na tento problém podívat.

V článku jsem zvažoval dva přístupy k objektovému modelování: jako celek a jako strukturu. V aktuálním článku budeme toto rozdělení potřebovat.

Předpokládejme, že máme navržený funkční objekt. Nechť je tento objekt námi uvažován jako součást stavby jiného funkčního objektu. Nechť je popis konstrukce objektu takový, aby obsahoval popis objektu. V takovém popisu má objekt popis jako celek, to znamená, že jeho rozhraní interakce s jinými objekty jsou popsána v rámci konstrukce objektu. Nechť je uveden popis objektu jako struktury. Nechť existuje informační objekt obsahující požadavky na návrh popisu objektu jako konstrukce. Nechť existuje soubor znalostí, který obsahuje odvozovací pravidla, na jejichž základě se získá popis objektu jako struktury z popisu objektu jako celku. Soubor znalostí je to, co se designéři učí v ústavech – hodně, hodně znalostí. Umožňují na základě znalostí o objektu navrhnout jeho strukturu.

Takže můžete začít. Můžeme tvrdit, že pokud je objekt jako celek správně popsán, je-li soubor znalostí správný a byla-li dodržena pravidla vyvozování, pak bude výsledný popis konstrukce objektu správný. To znamená, že na základě tohoto popisu bude postaven funkční objekt odpovídající skutečným provozním podmínkám. Jaká rizika mohou nastat:

1. Použití nesprávných znalostí o Objektu. Model Předmětu v myslích lidí nemusí odpovídat realitě. Neznali skutečné nebezpečí například zemětřesení. V souladu s tím mohou být požadavky na objekt nesprávně formulovány.

2. Neúplný záznam znalostí o Předmětu – něco chybí, dělají se chyby. Věděli například o větrech, ale zapomněli to zmínit. To může vést k nedostatečně úplnému popisu požadavků na objekt.

3. Špatný soubor znalostí. Naučili nás přednost hmotnosti před ostatními parametry, ale ukázalo se, že musíme zvýšit rychlost.

4. Nesprávná aplikace odvozovacích pravidel na popis objektu. Logické chyby, něco chybí v požadavcích na návrh objektu, trasování požadavků je rozbité.

5. Neúplný záznam získaných závěrů o návrhu systému. Se vším se počítalo, se vším se počítalo, ale zapomněli napsat.

6. Vytvořený systém neodpovídá popisu.

Je jasné, že všechny artefakty projektu se zpravidla objeví ve své dokončené podobě až na konci projektu, a i to ne vždy. Ale pokud předpokládáme, že vývoj je vodopád, pak jsou rizika taková, jak jsem popsal. Kontrola každého rizika je specifická operace, kterou lze pojmenovat. Pokud má někdo zájem, můžete zkusit tyto podmínky vymyslet a vyslovit.

Co je ověření? V ruštině je ověření kontrolou dodržování pravidel. Pravidla jsou ve formě dokumentu. To znamená, že by měl existovat dokument s požadavky na dokumentaci. Pokud dokumentace splňuje požadavky tohoto dokumentu, prošla ověřením.

Co je validace? Validace je v ruštině ověření správnosti závěrů. To znamená, že by měl existovat soubor znalostí, který popisuje, jak získat popis návrhu na základě objektových dat. Kontrola správnosti aplikace těchto závěrů je validací. Validace je mimo jiné kontrola konzistence, úplnosti a srozumitelnosti popisu.

Validace požadavků je často zaměňována s validací produktu postaveného na těchto požadavcích. Nemá cenu to dělat.

Verifikace (validace) - spočívá v kontrole a prokázání správnosti vyvinutého programu ve vztahu k souboru formálních prohlášení uvedených ve specifikaci a úplném definování vztahu mezi vstupními a výstupními daty tohoto programu. Zároveň je analyzován vztah mezi proměnnými na vstupu a výstupu programu nikoli ve formě hodnot jako při testování, ale ve formě popisů jejich vlastností, které se objevují při jakémkoli zpracování těchto proměnných v řízeném program.

Verifikace programu v zásadě eliminuje potřebu jeho testování a ladění, protože současně na vyšší úrovni konceptů a popisů všech proměnných je stanovena správnost procesů, jejich zpracování a transformace.

Podstatu každého programu mohou představovat popisy vztahu mezi vstupními a výstupními daty. Tyto vztahy jsou formalizovány 1 specifikací softwaru. V reálném vývoji není formalizace těchto vztahů špatná a některé vztahy jsou zpřesňovány v procesu vývoje programů. Takto neúplně definované nestačí k prokázání správnosti programů. Teprve po úplné a přesné formalizaci všech podmínek a vztahů mezi vstupními a výstupními daty je možné je použít pro automatickou verifikaci.

Metoda induktivních tvrzení.

Ke studiu této metody jsou programu v některých bodech dodány výroky o vlastnostech jeho proměnných:

a) Vstupní proměnné se během provádění programu nemění;

b) Popište stavy proměnných v mezilehlých bodech;

c) Výstupní proměnné jsou popsány z hlediska vztahů mezi proměnnými po skončení programu.

Verifikace spočívá v postupném dokazování, že pravdivost tvrzení vytvořeného v dalším mezilehlém bodě vyplývá ze vstupních proměnných a transformací provedených v prvním kroku.

Pro ověření programu jsou vyžadovány tři jazyky:

· Jazyk pro psaní programových textů;

· Jazyk formulace podmínek ověření;

· Jazyk formace a důkaz správnosti.

Protože se tyto jazyky do značné míry liší, je tato okolnost jednou z aplikací ověřování.

Důkaz správnosti má tyto výhody:

1. Je to jasně formalizovaný proces.

2. Vyžaduje analýzu. Proces kontroly správnosti umožňuje uvažovat části programů, které jsou jinak analyzovány pouze náhodně.

3. objasňuje mezivýsledky výpočtů. Vypisování výrazů nutí programátora jasně si vytvořit své předpoklady o výsledcích výpočtů ve vybraných bodech programu.

4. Identifikuje závislosti. V procesu dokazování programů člověk začíná chápat, jaké předpoklady o vstupních datech nejsou v různých částech programu výslovně testovány.

Nevýhody metody:

1. Složitost; i u malých jednoduchých programů jsou výpočty velmi složité, což může vést k chybám.

2. Chyby Vzhledem ke složitosti metody je snadné dělat chyby jak při tvorbě tvrzení, která mají být dokazována, tak při dokazování.

3. Obtíže při práci s poli.

4. Nedostatek výkonného matematického aparátu.

5. Vysoká pracnost Kontrola programu vyžaduje mzdové náklady než jeho psaní (2 - 6x).

6. Nedostatek expresivity. Často není snadné vytvořit výhodné tvrzení pro intuitivně velmi jednoduchý výpočet:

7. Obtížnost porozumění.

8. Potřeba školení. Tato metoda vyžaduje hodně tréninku a praxe.