Proces ověřování a validace návrhu

Ověření návrhu

Ověření návrhu je metoda, která potvrzuje, a to zkoumáním a poskytnutím důkazů, že výstup navrženého softwarového produktu splňuje jeho vstupní specifikace. Cílem procesu ověřování návrhu během vývoje softwaru je zajistit, aby navržený softwarový produkt byl stejný, jaký byl specifikován.

Vstupní údaje pro návrh jsou jakékoli fyzické a výkonnostní požadavky, které slouží jako základ pro návrh. Výstupní údaje pro návrh jsou výsledkem každé fáze návrhu a celkového úsilí o návrh. V regulovaných odvětvích, jako jsou zdravotnické prostředky, se konečný výstupní údaje pro návrh stává základem pro hlavní záznam o prostředku, a proto se terminologie týkající se kontroly návrhu tak často objevuje v ověřovací dokumentaci.

V praxi ověřování porovnává dvě sady dokumentů: specifikace, normy a omezení, které byly dodány, s výkresy, kódem a testovacími pokyny, které byly dodány. Každý nesoulad mezi nimi je zjištěním při ověřování.

Ověření návrhu

Verifikace prokazuje vnitřní konzistenci. Validace klade složitější otázku, zda specifikace od začátku popisovala správný produkt.

Ověření návrhu je proces hodnocení softwarového produktu podle přesných požadavků koncových uživatelů nebo zúčastněných stran. Účelem validace návrhu je otestovat softwarový produkt po vývoji, aby se potvrdilo, že splňuje tyto požadavky, když je používán ve vlastním prostředí uživatele.

Validace se zabývá prokázáním konzistence a úplnosti návrhu s ohledem na potřeby uživatelů. V této fázi se skutečně vytvoří verze produktu a ověří se její splnění podle požadavků uživatelů.

Níže uvedený banner označuje dvě poloviny aktivity tak, jak jsou obvykle prezentovány v konstrukčních záznamech.

Následující diagram znázorňuje samotný proces validace návrhu, od potřeb uživatelů až po validovaný produkt.

Účelem je objektivními důkazy prokázat, že produkt splňuje zdokumentované potřeby uživatele. Objektivní důkaz je jednoduše fyzický důkaz výstupu – obrázek, textový soubor, zvukový soubor nebo podepsaná zpráva – který ukazuje, že postup byl skutečně proveden.

Prostřednictvím těchto objektivních důkazů proces důsledně zkoumá, zda produkt splňuje předem definované požadavky. Zahrnuje testovací činnost, inspekci, analýzu a podobné techniky, a proto validace obvykle vychází z testování systému a testování přijetí uživatele spíše než na kontrolách na úrovni jednotek.

Rozdíl mezi ověřením návrhu a ověřením

Vždy existují mylné představy o verifikaci a validaci. Jsou to různé činnosti a obě se provádějí v každé fázi vývojového procesu, nikoli v jednom milníku.

Užitečná zkratka: ověření je většinou statická práce proti dokumentům, zatímco validace je většinou dynamické testování proti běžícímu sestavení.

Proces ověřování návrhu

Proces ověřování probíhá v pěti fázích a každá z nich vytváří artefakt, na kterém závisí další fáze.

Identifikace a příprava:

• Během vývoje specifikace probíhá paralelní ověřovací činnost. To umožňuje konstruktérovi ujistit se, že je specifikace skutečně ověřitelná, aby testovací inženýr mohl začít s podrobnými testovacími plány a postupy. Jakákoli změna specifikace musí být oznámena.
• Určete nejlepší přístup k provádění ověřování a definujte metody měření, požadované zdroje, nástroje a zařízení.
• Dokončený ověřovací plán je před jeho finalizací přezkoumán s konstrukčním týmem, aby se odhalily problémy.

Plánování:

• Plánování ověřování je souběžná činnost hlavního a vývojového týmu. Probíhá po celou dobu životního cyklu projektu a aktualizuje se vždy, když se změní vstupní údaje návrhu.
• Během této fáze je testovaný software nebo systém zdokumentován z hlediska rozsahu.
• Je napsán a následně upřesněn předběžný plán testování. Plán zachycuje kritické milníky, které snižují riziko projektu.
• Jsou vybrány nástroje, testovací prostředí a vývojová strategie a jsou identifikovány požadavky, které mají být potvrzeny inspekcí nebo analýzou.

Developing:

• Modelový případ vývoj se shoduje s Metodologie SDLC projektový tým implementoval. V této fázi je identifikována řada testovacích metod.
• Vstupní údaje pro návrh musí být vyvinuty tak, aby i ty nejjednodušší ověřovací činnosti byly jednoznačné a ověřitelné.
• Doba ověřování se zkracuje, když se podobné koncepty ověřují postupně, protože výstup jednoho testu lze znovu použít jako vstup pro následný test.
• TracMezi testovacími případy a jejich odpovídajícími návrhovými vstupy se vytvářejí propojení proveditelnosti, aby se zajistilo, že je otestován každý požadavek a že výstup návrhu splňuje návrhové vstupy.

Provedení:

• Testovací postupy vytvořené během fáze vývoje jsou prováděny v souladu s testovacím plánem a během ověřovací činnosti jsou striktně dodržovány.
• Pokud se vyskytnou neplatné výsledky nebo pokud je třeba upravit jakýkoli postup, musí být změny zdokumentovány a formálně schváleny.
• Jakýkoli zjištěný problém je zaznamenán jako závada obvyklým způsobem. proces správy vad.
• A tracmatice proveditelnosti je vytvořen za účelem ověření, zda byl otestován každý vstupní návrh identifikovaný v plánu ověřovacích testů, a za účelem určení poměru úspěšnosti.

Zprávy:

• Tato činnost se provádí na konci každé fáze provádění ověřování.
• Zpráva o ověření návrhu poskytuje podrobný souhrn výsledků ověření, včetně správy konfigurace, výsledků pro každý typ testování a problémů zjištěných během ověřovací činnosti.
• Ověření návrhu tracMezi požadavky a odpovídajícími výsledky testů se vytváří zpráva o proveditelnosti, která potvrzuje, že všechny požadavky byly testovány a že byly zaznamenány příslušné výsledky.
• Jakákoli neshoda je zdokumentována a odpovídajícím způsobem řešena.
• RevPo dokončení ověřovací činnosti návrhu se provádějí posouzení a výstupy jsou formálně schváleny.

Proces ověření návrhu

Validace nemá stejnou rigidní posloupnost. Místo toho čerpá z malé sady akceptovaných metod a projekt obvykle používá více než jednu z nich.

• Porovnání s ekvivalentními návrhy. Některé návrhy lze validovat porovnáním s podobným zařízením sloužícím podobnému účelu. To je zvláště důležité při validaci změn konfigurace stávající infrastruktury nebo standardních návrhů, které se začleňují do nového systému nebo aplikace.
• Předvedení a prohlídka. K ověření požadavků a dalších funkcí produktu lze použít jeden nebo oba.
• Analýza. Návrh lze analyzovat pomocí matematického modelování nebo simulace, která znovu vytvoří požadovanou funkcionalitu.
• Testování. Na konečném návrhu se provádějí testy, aby se ověřila schopnost systému fungovat dle specifikace, což je tam, kde funkční testování a nefunkční testování splňovat požadavky uživatele.
• Dokumentace. Plán testování, jeho provedení a výsledky by měly být zdokumentovány a uchovávány jako součást záznamů o návrhu. Validace je nakonec shromážděnými výsledky všech validačních činností.
• Zdůvodnění ekvivalence. Pokud jsou při konečném ověření návrhu použity ekvivalentní výrobky, musí výrobce zdokumentovat podobnost a jakékoli rozdíly oproti původní výrobě.

Příklad

Krátký příklad toto rozlišení konkretizuje.

• Vezměte si jednoduchý produkt: vodotěsné hodinky.
• V dokumentu s požadavky na produkt by mohlo být uvedeno, že „hodinky musí být vodotěsné během plavání“. To je potřeba uživatele a podle toho se měří validace.
• V konstrukční specifikaci by mohlo být uvedeno, že „hodinky by měly fungovat, i když uživatel plave delší dobu“. To je konstrukční vstup a podle toho se měří ověření.
• Výsledky testů by měly potvrdit, že hodinky tyto požadavky splňují. Pokud ne, pokračují iterace redesignu, dokud je nesplňují.

Všimněte si, jak hodinky mohou projít ověřením a přesto selhat v validaci. Pokud specifikace definuje prodloužené plavání jako patnáct minut a skuteční plavci zůstanou ve vodě hodinu, výstup návrhu dokonale odpovídá vstupu a stále uživatele selže.

Výhody ověřování a ověřování návrhu

Níže uvedené výhody přináší spíše průběžné provádění obou aktivit než jejich závěrečné spouštění.

• Návrhy lze průběžně sledovat, což umožňuje splnit uživatelem definované požadavky v každé fázi.
• Ověření návrhu poukazuje na rozdíl mezi tím, jak funkcionalita funguje, a tím, jak se od ní očekává.
• Dokumentace ověřovacích postupů usnadňuje pochopení funkcionality později, kdykoli je provedena změna nebo vylepšení.
• Doba vývoje se neustále zkracuje a produktivita se zvyšuje, což pomáhá dodávat produkt dle očekávání.
• Proces definuje rozsah a oblast působnosti každé validační metody, která má být použita.
• Validaci lze provést s využitím podrobných návrhových dat, která představují požadavky konečného uživatele.
• Jakýkoli rozdíl mezi výsledkem a dokumenty potřebnými uživatelem je zachycen, nikoli ztracen.
• Změny ověřeného návrhu spouštějí aktivitu opětovného ověřování, takže záznam se nikdy neoddálí od produktu.
• Dokumentace každé činnosti, která proběhne během validace, je tím, co dostatečně prokazuje, že návrh splňuje požadavky uživatele.

Ověření a validace návrhu se proto nejlépe plánují v rámci širšího životní cyklus testování softwaru a namapované oproti druhému typy testování softwaru, spíše než aby se s nimi zacházelo jako se samostatným postupem pro dodržování předpisů.

Nejčastější dotazy