Ověření a validace softwaru - Software verification and validation

Životní cyklus softwaru IEEE

Ve správě softwarových projektů , testování softwaru a softwarového inženýrství je ověřování a ověřování ( V&V ) proces kontroly, zda softwarový systém splňuje specifikace a požadavky tak, aby splnil svůj zamýšlený účel. Může být také označováno jako kontrola kvality softwaru . To je obvykle v kompetenci testery softwaru v rámci životního cyklu vývoje softwaru . Jednoduše řečeno, ověření softwaru zní: „Za předpokladu, že bychom měli vytvořit X, dosahuje náš software svých cílů bez jakýchkoli chyb nebo mezer?“ Na druhou stranu validace softwaru zní: "Bylo X to, co jsme měli postavit? Splňuje X požadavky na vysoké úrovni?"

Definice

Ověření a validace nejsou totéž, i když jsou často zmatené. Boehm stručně vyjádřil rozdíl jako

  • Ověření: Stavíme produkt správně?
  • Ověření: Stavíme správný produkt?

„Budování správného produktu“ kontroluje, zda jsou specifikace správně implementovány systémem, zatímco „budování správného produktu“ odkazuje zpět na potřeby uživatele . V některých kontextech je vyžadováno mít písemné požadavky jak na formální postupy, tak protokoly pro určování shody. V ideálním případě formální metody poskytují matematickou záruku, že software splňuje jeho specifikace.

Vybudování práva na produkt znamená použití specifikace požadavků jako vstupu pro další fázi procesu vývoje, procesu návrhu, jehož výstupem je specifikace návrhu. Potom to také znamená použití specifikace návrhu k posílení stavebního procesu. Pokaždé, když výstup procesu správně implementuje jeho vstupní specifikaci, je softwarový produkt o krok blíže konečnému ověření. Pokud je výstup procesu nesprávný, vývojáři nevytvářejí produkt, který akcionáři chtějí správně. Tento druh ověření se nazývá „ověření artefaktu nebo specifikace“.

Vytvoření správného produktu znamená vytvoření specifikace požadavků, která obsahuje potřeby a cíle zúčastněných stran softwarového produktu. Pokud je takový artefakt neúplný nebo nesprávný, vývojáři nebudou schopni postavit produkt, který chtějí zúčastněné strany. Toto je forma „ověření artefaktu nebo specifikace“.

Poznámka: Ověření začíná před validací a poté probíhá souběžně, dokud není vydán softwarový produkt.

Ověření softwaru

Znamenalo by to ověřit, zda jsou splněny specifikace spuštěním softwaru, ale to není možné (např. Jak může někdo vědět, zda je architektura/design/atd. Správně implementována spuštěním softwaru?). Pouze při kontrole souvisejících artefaktů může někdo dojít k závěru, zda jsou specifikace splněny či nikoli.

Ověření artefaktu nebo specifikace

Výstup každé fáze procesu vývoje softwaru lze také ověřit, pokud je porovnán s jeho vstupní specifikací (viz definici CMMI níže).

Příklady ověření artefaktu:

  • Specifikace návrhu oproti specifikaci požadavku: Implementují specifikace architektonického návrhu, podrobný design a databázový logický model správně specifikace funkčních a nefunkčních požadavků?
  • O konstrukčních artefaktech proti specifikaci návrhu: Implementují zdrojový kód, uživatelská rozhraní a databázový fyzický model správně specifikaci návrhu?

Ověření softwaru

Ověření softwaru kontroluje, zda softwarový produkt splňuje nebo vyhovuje zamýšlenému použití (kontrola na vysoké úrovni), tj. Software splňuje požadavky uživatele, nikoli jako artefakty specifikace nebo potřeby těch, kteří budou software provozovat pouze; ale jako potřeby všech zúčastněných stran (jako jsou uživatelé, provozovatelé, správci, manažeři, investoři atd.). Ověření softwaru lze provést dvěma způsoby: interním a externím. Během interní validace softwaru se předpokládá, že cíle zúčastněných stran byly správně pochopeny a že byly přesně a komplexně vyjádřeny v artefaktech požadavků. Pokud software splňuje specifikaci požadavku, byl interně ověřen. K externí validaci dochází, když se provádí tak, že se zeptáte zúčastněných stran, zda software splňuje jejich potřeby. Různé metodiky vývoje softwaru vyžadují různé úrovně zapojení uživatelů a zúčastněných stran a zpětnou vazbu; externí validace tedy může být diskrétní nebo spojitá událost. Úspěšné konečné externí ověření nastane, když všechny zúčastněné strany přijmou softwarový produkt a vyjádří, že splňuje jejich potřeby. Taková konečná externí validace vyžaduje použití přejímací zkoušky, která je dynamickou zkouškou .

Je však také možné provést interní statické testy a zjistit, zda software splňuje specifikaci požadavků, ale spadá do rozsahu statického ověření, protože software není spuštěn.

Ověření artefaktu nebo specifikace

Požadavky by měly být ověřeny dříve, než bude softwarový produkt jako celek připraven (proces vývoje vodopádu vyžaduje, aby byly dokonale definovány před zahájením návrhu; ale iterační vývojové procesy nevyžadují, aby tomu tak bylo, a umožňují jejich neustálé zlepšování).

Příklady ověření artefaktu:

  • Ověření specifikace požadavků uživatele: Požadavky uživatele uvedené v dokumentu nazvaném Specifikace požadavků uživatele se ověřují kontrolou, zda skutečně představují vůli a cíle zúčastněných stran. To lze provést pohovorem se zúčastněnými stranami a jejich přímým požádáním (statické testování) nebo dokonce uvolněním prototypů a jejich posouzeními od uživatelů a zúčastněných stran (dynamické testování).
  • Ověření vstupu uživatele: Vstup uživatele (shromážděný jakoukoli periferií, jako je klávesnice, biometrický senzor atd.) Je ověřen kontrolou, zda vstup poskytovaný provozovateli softwaru nebo uživateli splňuje pravidla domény a omezení (jako je typ dat, rozsah a formát).

Ověření vs. ověření

Podle modelu schopnosti splatnosti (CMMI-SW v1.1),

  • Ověření softwaru: Proces hodnocení softwaru během nebo na konci procesu vývoje za účelem zjištění, zda splňuje stanovené požadavky. [IEEE-STD-610]
  • Ověření softwaru: Proces hodnocení softwaru za účelem zjištění, zda produkty dané vývojové fáze splňují podmínky stanovené na začátku této fáze. [IEEE-STD-610]

Ověření během procesu vývoje softwaru lze považovat za formu ověření specifikace uživatelských požadavků; a že na konci procesu vývoje je ekvivalentní interní a/nebo externí validaci softwaru. Ověření, z pohledu CMMI, je evidentně druhu artefaktu.

Jinými slovy, ověření softwaru zajišťuje, že výstup každé fáze procesu vývoje softwaru účinně provádí to, co specifikuje jeho odpovídající vstupní artefakt (požadavek -> design -> softwarový produkt), zatímco validace softwaru zajišťuje, že softwarový produkt splňuje potřeby všechny zúčastněné strany (proto byla specifikace požadavku správně a přesně vyjádřena na prvním místě). Ověření softwaru zajišťuje, že „jste jej postavili správně“ a potvrzuje, že produkt, jak je uveden, splňuje plány vývojářů. Ověření softwaru zajišťuje, že „jste postavili správnou věc“, a potvrzuje, že produkt, jak je uveden, splňuje zamýšlené použití a cíle zúčastněných stran.

Tento článek použil přísnou nebo úzkou definici ověření.

Z pohledu testování:

  • Chyba - chybná nebo chybějící funkce v kódu.
  • Selhání - projev chyby během provádění. Software nebyl účinný. Nedělá to „to, co“ dělat má.
  • Porucha - podle své specifikace systém nesplňuje specifikovanou funkčnost. Software nebyl efektivní (vyžadoval příliš mnoho zdrojů, jako jsou cykly CPU, používal příliš mnoho paměti, provedl příliš mnoho I/O operací atd.), Nebyl použitelný, nebyl spolehlivý atd. Nedělá to něco "jak" to má dělat.

Související pojmy

Ověření i validace souvisí s pojmy kvality a zajištění kvality softwaru . Ověření a validace samy o sobě nezaručují kvalitu softwaru; je vyžadováno plánování, sledovatelnost , správa konfigurace a další aspekty softwarového inženýrství.

V komunitě modelování a simulace (M&S) jsou definice ověření, validace a akreditace podobné:

  • Ověření M&S je proces určení, že počítačový model , simulace nebo federace implementací modelů a simulací a jejich přidružená data přesně reprezentují koncepční popis a specifikace vývojáře.
  • Ověření M&S je proces určování míry, do jaké jsou model, simulace nebo federace modelů a simulací a jejich přidružená data přesnými reprezentacemi skutečného světa z pohledu zamýšleného použití.
  • Akreditace je formální osvědčení, že model nebo simulace je přijatelné pro použití pro konkrétní účel.

Definice validace M&S se zaměřuje na přesnost, s jakou M&S představuje zamýšlená použití v reálném světě. Určení stupně přesnosti M&S je vyžadováno, protože všechny M&S jsou aproximacemi reality a obvykle je rozhodující určit, zda je stupeň aproximace přijatelný pro zamýšlené použití. To je v kontrastu s ověřováním softwaru.

V&V metody

Formální

V klíčových softwarových systémech lze k zajištění správného fungování systému použít formální metody . Tyto formální metody mohou být nákladné, ale představují až 80 procent celkových nákladů na návrh softwaru.

Nezávislý

Nezávislé ověřování a ověřování softwaru (ISVV) je zaměřeno na softwarové systémy kritické z hlediska bezpečnosti a jeho cílem je zvýšit kvalitu softwarových produktů, a tím snížit rizika a náklady po dobu životnosti softwaru. Cílem ISVV je poskytnout jistotu, že software funguje na zadané úrovni spolehlivosti a v rámci jeho navržených parametrů a definovaných požadavků.

Činnosti ISVV provádějí nezávislé týmy inženýrů, které nejsou zapojeny do procesu vývoje softwaru, za účelem posouzení procesů a výsledných produktů. Nezávislost týmu ISVV se provádí na třech různých úrovních: finanční, manažerské a technické.

ISVV jde nad rámec „tradičních“ technik ověřování a ověřování, které používají vývojové týmy. Zatímco cílem posledního jmenovaného je zajistit, aby software dobře fungoval proti nominálním požadavkům, ISVV se zaměřuje na nefunkční požadavky, jako je robustnost a spolehlivost, a na podmínky, které mohou vést k selhání softwaru.

Výsledky a zjištění ISVV jsou poskytovány zpět vývojovým týmům za účelem opravy a zlepšení.

Dějiny

ISVV pochází z aplikace IV&V (nezávislé ověřování a ověřování) na software. Raná aplikace ISVV (jak ji známe dnes) pochází z počátku 70. let minulého století, kdy americká armáda sponzorovala první významný program související s IV&V pro systém protiraketových střel Safeguard . Dalším příkladem je program IV&V NASA, který byl založen v roce 1993.

Do konce sedmdesátých let se IV&V rychle stalo populárním. Neustálý nárůst složitosti, velikosti a důležitosti softwaru vedl k rostoucí poptávce po softwaru IV&V.

Mezitím se IV&V (a ISVV pro softwarové systémy) konsolidovalo a nyní je široce používáno organizacemi jako DoD , FAA , NASA a ESA . IV&V je zmíněn v DO-178B , ISO/IEC 12207 a formalizován v IEEE 1012 .

V ESA

Zpočátku v letech 2004-2005 vytvořilo evropské konsorcium vedené Evropskou vesmírnou agenturou ve složení DNV , Critical Software SA , Terma a CODA SciSys plc první verzi průvodce věnovaného ISVV s názvem „ESA Guide for Independent Verification and Validation“. „s podporou jiných organizací. Tato příručka pokrývá metodiky použitelné pro všechny fáze softwarového inženýrství v oblasti ISVV.

V roce 2008 vydala Evropská kosmická agentura druhou verzi, která obdržela příspěvky od mnoha různých zúčastněných stran evropské vesmírné ISVV.

Metodologie

ISVV se obvykle skládá z pěti hlavních fází, tyto fáze mohou být prováděny postupně nebo jako výsledek procesu přizpůsobení.

Plánování

  • Plánování aktivit ISVV
  • Analýza kritičnosti systému: Identifikace kritických komponent pomocí sady aktivit RAMS (hodnota za peníze)
  • Výběr vhodných metod a nástrojů

Ověření požadavků

  • Ověření pro: úplnost, správnost, testovatelnost

Ověření návrhu

  • Přiměřenost návrhu a shoda s požadavky na software a rozhraními
  • Vnitřní a vnější konzistence
  • Ověření proveditelnosti a údržby

Ověření kódu

Validace

Regulační prostředí

Software často musí splňovat požadavky na shodu zákonem regulovaných odvětví, která se často řídí vládními agenturami nebo průmyslovými správními úřady. Například FDA vyžaduje verze softwaru a opravy , které mají být ověřeny.

Viz také

Další čtení

  • 1012-2012 Standard IEEE pro ověřování a ověřování systému a softwaru . 2012. doi : 10.1109/IEEESTD.2012.6204026 . ISBN 978-0-7381-7268-2.
  • Tran, E. (1999). „Ověření/ověření/certifikace“ . V Koopman, P. (ed.). Témata v závislých vestavěných systémech . Univerzita Carnegie Mellon . Citováno 2007-05-18 .
  • Menzies, T .; Y. Hu (2003). „Data mining pro velmi zaneprázdněné lidi“. Počítač . 36 (1): 22–29. doi : 10.1109/MC.2003.1244531 .

externí odkazy

Reference

  1. ^ Pham, H. (1999). Spolehlivost softwaru . John Wiley & Sons, Inc. p. 567. ISBN 9813083840. Ověření softwaru. Proces zajištění, že software provádí správný proces. Ověření softwaru. Proces zajištění toho, že software provádí proces správně. “Podobně a také tam:„ Stručně řečeno, Boehm (3) vyjádřil rozdíl mezi ověřením softwaru a ověřením softwaru takto: Ověření: „Budujeme produkt správně ? '' Ověření: '' Vytváříme správný produkt? ''.
  2. ^ "CMMI pro softwarové inženýrství, verze 1.1, představování po etapách (CMMI-SW, V1.1, představeno)" . resources.sei.cmu.edu . Citováno 2021-03-20 .
  3. ^ a b c „Ministerstvo obrany dokumentace verifikace, validace a akreditace (VV&A) pro modely a simulace“. Agentura protiraketové obrany. 2008. Citační deník vyžaduje |journal=( nápověda )
  4. ^ Rogers, R. (1981-10-26). „Plánování nezávislého ověřování a validace softwaru“ . 3. Konference Počítače v letectví . San Diego, CA, USA: Americký institut pro letectví a kosmonautiku. doi : 10,2514/6.1981-2100 .
  5. ^ Ambrosio, Ana; Mattiello-Francisco, Fátima; Martins, Eliane (2008-05-12). „Nezávislý proces ověřování a ověřování softwaru pro vesmírné aplikace“ . Konference SpaceOps 2008 . Heidelberg, Německo: Americký institut pro letectví a kosmonautiku. doi : 10.2514/6.2008-3517 . ISBN 978-1-62410-167-0.
  6. ^ Lewis, Robert O. (1992). Nezávislé ověřování a ověřování: proces technického vývoje životního cyklu kvalitního softwaru . New York: Wiley. ISBN 0-471-57011-7. OCLC  74908695 .
  7. ^ a b Asbury, Michael (09.03.2015). „O programu IV&V NASA“ . NASA . Citováno 2021-03-20 .
  8. ^ Balci, O. (2010). „Zlatá pravidla pro ověřování, ověřování, testování a certifikaci modelování a simulačních aplikací“ . nedefinováno . Citováno 2021-03-20 .
  9. ^ "Sekce letových softwarových systémů (TEC-SWF)" . www.esa.int . Citováno 2021-03-20 .
  10. ^ a b lavva.pt. „Nová příručka ISVV pro vesmír ve stavebnictví“ . www.criticalsoftware.com . Citováno 2021-03-20 .
  11. ^ „Obecné zásady ověřování softwaru; závěrečné pokyny pro průmysl a zaměstnance FDA“ (PDF) . Správa potravin a léčiv . 11. ledna 2002 . Vyvolány 12 July 2009 .
  12. ^ „Pokyny pro průmysl: část 11, elektronické záznamy; elektronické podpisy - rozsah a aplikace“ (PDF) . Správa potravin a léčiv . Srpna 2003 . Vyvolány 12 July 2009 .
  13. ^ „Pokyny pro průmysl: Kybernetická bezpečnost síťových zdravotnických prostředků obsahujících software mimo polici (OTS)“ (PDF) . Správa potravin a léčiv . 14. ledna 2005 . Vyvolány 12 July 2009 .