Softwareverifizierung und -validierung - Software verification and validation

IEEE- Softwarelebenszyklus

Im Softwareprojektmanagement , Softwaretest und Software Engineering ist Verifikation und Validierung ( V&V ) der Prozess der Überprüfung, ob ein Softwaresystem Spezifikationen und Anforderungen erfüllt, damit es seinen beabsichtigten Zweck erfüllt. Es kann auch als Softwarequalitätskontrolle bezeichnet werden . Es liegt normalerweise in der Verantwortung von Softwaretestern als Teil des Softwareentwicklungslebenszyklus . Vereinfacht gesagt lautet die Software-Verifizierung: "Angenommen, wir sollten X bauen, erreicht unsere Software dann ihre Ziele ohne Fehler oder Lücken?" Auf der anderen Seite lautet die Softwarevalidierung: "War X das, was wir hätten bauen sollen? Erfüllt X die hohen Anforderungen?"

Definitionen

Verifizierung und Validierung sind nicht dasselbe, obwohl sie oft verwechselt werden. Böhm hat den Unterschied prägnant ausgedrückt als

  • Überprüfung: Bauen wir das Produkt richtig?
  • Validierung: Bauen wir das richtige Produkt?

„Das richtige Produkt bauen“ prüft, ob die Vorgaben vom System korrekt umgesetzt werden, während „das richtige Produkt bauen“ auf die Bedürfnisse des Nutzers zurückgreift . In einigen Kontexten sind sowohl schriftliche Anforderungen als auch formelle Verfahren oder Protokolle zur Feststellung der Einhaltung erforderlich. Im Idealfall bieten formale Methoden eine mathematische Garantie dafür, dass die Software ihren Spezifikationen entspricht.

Die Erstellung des Produktrechts impliziert die Verwendung der Anforderungsspezifikation als Input für die nächste Phase des Entwicklungsprozesses, den Designprozess, dessen Ergebnis die Designspezifikation ist. Dann impliziert es auch die Verwendung der Entwurfsspezifikation, um den Bauprozess zu unterstützen. Jedes Mal, wenn die Ausgabe eines Prozesses seine Eingabespezifikation korrekt implementiert, ist das Softwareprodukt der endgültigen Verifizierung einen Schritt näher gekommen. Wenn die Ausgabe eines Prozesses falsch ist, bauen die Entwickler das von den Stakeholdern gewünschte Produkt nicht richtig. Diese Art der Überprüfung wird als "Artefakt- oder Spezifikationsüberprüfung" bezeichnet.

Das richtige Produkt aufzubauen bedeutet, eine Anforderungsspezifikation zu erstellen, die die Bedürfnisse und Ziele der Stakeholder des Softwareprodukts enthält. Wenn ein solches Artefakt unvollständig oder falsch ist, können die Entwickler das gewünschte Produkt nicht erstellen. Dies ist eine Form der "Artefakt- oder Spezifikationsvalidierung".

Hinweis: Die Verifizierung beginnt vor der Validierung und läuft dann parallel, bis das Softwareprodukt freigegeben wird.

Softwareüberprüfung

Es würde bedeuten, zu überprüfen, ob die Spezifikationen durch Ausführen der Software erfüllt werden, dies ist jedoch nicht möglich (zB wie kann jemand wissen, ob die Architektur/das Design/etc. durch das Ausführen der Software korrekt implementiert sind?). Nur durch die Überprüfung der zugehörigen Artefakte kann jemand feststellen, ob die Spezifikationen erfüllt werden oder nicht.

Artefakt- oder Spezifikationsüberprüfung

Die Ausgabe jeder Prozessstufe der Softwareentwicklung kann auch einer Überprüfung unterzogen werden, wenn sie mit ihrer Eingabespezifikation verglichen wird (siehe Definition von CMMI unten).

Beispiele für die Artefaktverifizierung:

  • Von der Designspezifikation gegen die Anforderungsspezifikation: Implementieren die Spezifikationen für Architekturdesign, Detaildesign und datenbanklogisches Modell die funktionalen und nichtfunktionalen Anforderungsspezifikationen korrekt?
  • Von den Konstruktionsartefakten gegen die Designspezifikation: Implementieren der Quellcode, die Benutzeroberflächen und das physische Datenbankmodell die Designspezifikation korrekt?

Softwarevalidierung

Die Softwarevalidierung prüft, ob das Softwareprodukt den vorgesehenen Verwendungszweck erfüllt oder geeignet ist (High-Level-Checking), dh die Software erfüllt die Benutzeranforderungen, nicht als Spezifikationsartefakte oder nur als Bedarf derjenigen, die die Software betreiben; sondern nach den Bedürfnissen aller Beteiligten (wie Benutzer, Betreiber, Administratoren, Manager, Investoren usw.). Es gibt zwei Möglichkeiten, eine Softwarevalidierung durchzuführen: intern und extern. Bei der internen Softwarevalidierung wird davon ausgegangen, dass die Ziele der Stakeholder richtig verstanden und in den Anforderungsartefakten präzise und umfassend zum Ausdruck gebracht wurden. Wenn die Software die Anforderungsspezifikation erfüllt, wurde sie intern validiert. Eine externe Validierung erfolgt, wenn sie durchgeführt wird, indem die Stakeholder gefragt werden, ob die Software ihren Anforderungen entspricht. Unterschiedliche Softwareentwicklungsmethoden erfordern unterschiedliche Ebenen der Einbeziehung und des Feedbacks von Benutzern und Interessengruppen; Daher kann die externe Validierung ein diskretes oder ein kontinuierliches Ereignis sein. Eine erfolgreiche abschließende externe Validierung erfolgt, wenn alle Beteiligten das Softwareprodukt akzeptieren und zum Ausdruck bringen, dass es ihren Bedürfnissen entspricht. Eine solche abschließende externe Validierung erfordert die Verwendung eines Abnahmetests, bei dem es sich um einen dynamischen Test handelt .

Es ist jedoch auch möglich, interne statische Tests durchzuführen, um herauszufinden, ob die Software die Anforderungsspezifikation erfüllt, dies fällt jedoch in den Rahmen der statischen Verifizierung, da die Software nicht läuft.

Artefakt- oder Spezifikationsvalidierung

Anforderungen sollten validiert werden, bevor das Softwareprodukt als Ganzes fertig ist (der Wasserfall-Entwicklungsprozess erfordert, dass sie vor Designbeginn perfekt definiert sind; iterative Entwicklungsprozesse erfordern dies jedoch nicht und ermöglichen ihre kontinuierliche Verbesserung).

Beispiele für die Artefaktvalidierung:

  • Validierung der Benutzeranforderungsspezifikation: Benutzeranforderungen, wie sie in einem Dokument mit der Bezeichnung Benutzeranforderungsspezifikation angegeben sind, werden validiert, indem überprüft wird, ob sie tatsächlich den Willen und die Ziele der Beteiligten widerspiegeln. Dies kann durch Interviews mit den Stakeholdern und direkte Nachfragen (statisches Testen) oder sogar durch die Freigabe von Prototypen und deren Bewertung durch die Nutzer und Stakeholder erfolgen (dynamisches Testen).
  • Validierung der Benutzereingabe: Benutzereingaben (erfasst von einem beliebigen Peripheriegerät wie Tastatur, biometrischer Sensor usw.) werden validiert, indem überprüft wird, ob die von den Softwareoperatoren oder Benutzern bereitgestellten Eingaben die Domänenregeln und -beschränkungen (wie Datentyp, Bereich) erfüllen und Format).

Validierung vs. Verifizierung

Gemäß dem Capability Maturity Model (CMMI-SW v1.1)

  • Softwarevalidierung: Der Prozess der Evaluierung von Software während oder am Ende des Entwicklungsprozesses, um zu bestimmen, ob sie spezifizierte Anforderungen erfüllt. [IEEE-STD-610]
  • Softwareverifikation: Der Prozess der Softwarebewertung, um festzustellen, ob die Produkte einer bestimmten Entwicklungsphase die zu Beginn dieser Phase gestellten Bedingungen erfüllen. [IEEE-STD-610]

Die Validierung während des Softwareentwicklungsprozesses kann als eine Form der Validierung der Benutzeranforderungsspezifikation angesehen werden; und dass am Ende des Entwicklungsprozesses einer internen und/oder externen Softwarevalidierung entspricht. Die Verifikation ist aus Sicht von CMMI offensichtlich Artefakt-Art.

Mit anderen Worten stellt die Softwareverifizierung sicher, dass die Ausgabe jeder Phase des Softwareentwicklungsprozesses effektiv das ausführt, was ihr entsprechendes Eingabeartefakt spezifiziert (Anforderung -> Design -> Softwareprodukt), während die Softwarevalidierung sicherstellt, dass das Softwareprodukt die Anforderungen von alle Beteiligten (daher wurde die Anforderungsspezifikation von vornherein richtig und genau formuliert). Die Software-Verifizierung stellt sicher, dass "Sie es richtig gebaut haben" und bestätigt, dass das Produkt, wie bereitgestellt, die Pläne der Entwickler erfüllt. Die Softwarevalidierung stellt sicher, dass "Sie das Richtige gebaut haben" und bestätigt, dass das Produkt, wie bereitgestellt, den beabsichtigten Gebrauch und die Ziele der Stakeholder erfüllt.

In diesem Artikel wurde die strenge oder enge Definition von Verifikation verwendet.

Aus Testsicht:

  • Fehler – falsche oder fehlende Funktion im Code.
  • Fehler – die Manifestation eines Fehlers während der Ausführung. Die Software war nicht effektiv. Es tut nicht "was" es tun soll.
  • Fehlfunktion – Das System erfüllt gemäß seiner Spezifikation nicht seine spezifizierte Funktionalität. Die Software war nicht effizient (sie benötigte zu viele Ressourcen wie CPU-Zyklen, sie verbrauchte zu viel Speicher, führte zu viele E/A-Operationen durch usw.), sie war nicht verwendbar, sie war nicht zuverlässig usw. Dies ist nicht der Fall etwas "wie" es tun soll.

Verwandte konzepte

Sowohl Verifikation als auch Validierung beziehen sich auf die Konzepte der Qualität und der Software-Qualitätssicherung . Verifizierung und Validierung allein garantieren keine Softwarequalität; Planung, Rückverfolgbarkeit , Konfigurationsmanagement und andere Aspekte des Software-Engineerings sind erforderlich.

Innerhalb der Modellierungs- und Simulationsgemeinschaft (M&S) sind die Definitionen von Verifikation, Validierung und Akkreditierung ähnlich:

  • M&S-Verifizierung ist der Prozess, bei dem festgestellt wird, ob ein Computermodell , eine Simulation oder ein Verbund von Modellen und Simulationsimplementierungen und die zugehörigen Daten die konzeptionelle Beschreibung und Spezifikationen des Entwicklers genau wiedergeben.
  • M&S-Validierung ist der Prozess zur Bestimmung des Grades, in dem ein Modell, eine Simulation oder ein Verbund von Modellen und Simulationen und die zugehörigen Daten die reale Welt aus der Perspektive der beabsichtigten Verwendung(en) genau wiedergeben.
  • Akkreditierung ist die formelle Bestätigung, dass ein Modell oder eine Simulation für einen bestimmten Zweck akzeptabel ist.

Die Definition der M&S-Validierung konzentriert sich auf die Genauigkeit, mit der die M&S die reale(n) beabsichtigte(n) Verwendung(en) repräsentiert. Die Bestimmung des Grads der M&S-Genauigkeit ist erforderlich, da alle M&S-Annäherungen der Realität entsprechen und es normalerweise entscheidend ist, zu bestimmen, ob der Grad der Annäherung für die beabsichtigte(n) Verwendung(en) akzeptabel ist. Dies steht im Gegensatz zur Softwarevalidierung.

V&V-Methoden

Formell

In geschäftskritischen Softwaresystemen können formale Verfahren verwendet werden, um den korrekten Betrieb eines Systems sicherzustellen. Diese formalen Methoden können sich jedoch als kostspielig erweisen und bis zu 80 Prozent der gesamten Softwaredesignkosten ausmachen.

Unabhängig

Die Independent Software Verification and Validation (ISVV) richtet sich an sicherheitskritische Softwaresysteme und zielt darauf ab, die Qualität von Softwareprodukten zu erhöhen und dadurch Risiken und Kosten über die Nutzungsdauer der Software zu reduzieren. Das Ziel von ISVV ist es, sicherzustellen, dass die Software das spezifizierte Vertrauensniveau und die festgelegten Parameter und definierten Anforderungen erfüllt.

ISVV-Aktivitäten werden von unabhängigen Entwicklungsteams durchgeführt, die nicht am Softwareentwicklungsprozess beteiligt sind, um die Prozesse und die resultierenden Produkte zu bewerten. Die Unabhängigkeit des ISVV-Teams erfolgt auf drei verschiedenen Ebenen: Finanziell, Management und Technik.

ISVV geht über "traditionelle" Verifikations- und Validierungstechniken hinaus, die von Entwicklungsteams angewendet werden. Während letztere darauf abzielen, sicherzustellen, dass die Software den nominellen Anforderungen entspricht, konzentriert sich ISVV auf nicht funktionale Anforderungen wie Robustheit und Zuverlässigkeit sowie auf Bedingungen, die zum Versagen der Software führen können.

ISVV-Ergebnisse und -Erkenntnisse werden zur Korrektur und Verbesserung an die Entwicklungsteams zurückgemeldet.

Geschichte

ISVV ergibt sich aus der Anwendung von IV&V (Independent Verification and Validation) auf die Software. Die frühe ISVV-Anwendung (wie heute bekannt) geht auf die frühen 1970er Jahre zurück, als die US-Armee das erste bedeutende Programm im Zusammenhang mit IV&V für das Safeguard Anti-Ballistic Missile System sponserte . Ein weiteres Beispiel ist das 1993 gegründete IV&V-Programm der NASA.

Ende der 1970er Jahre wurde IV&V schnell populär. Die stetige Zunahme an Komplexität, Größe und Bedeutung der Software führte zu einer steigenden Nachfrage nach IV&V für Software.

Inzwischen hat sich IV&V (und ISVV für Softwaresysteme) konsolidiert und wird nun von Organisationen wie dem DoD , der FAA , der NASA und der ESA weit verbreitet verwendet . IV&V wird in DO-178B , ISO/IEC 12207 erwähnt und in IEEE 1012 formalisiert .

Bei der ESA

Zunächst in den Jahren 2004-2005 ein europäisches Konsortium durch die geführte European Space Agency und komponiert von DNV , Critical Software SA , Terma und CODA SciSys plc erstellt die erste Version eines Leitfadens für ISVV gewidmet, die so genannte „ESA Leitfaden für unabhängige Verifizierung und Validierung “ mit Unterstützung anderer Organisationen. Dieser Leitfaden behandelt die Methoden, die für alle Phasen der Softwareentwicklung in Bezug auf ISVV anwendbar sind.

Im Jahr 2008 veröffentlichte die Europäische Weltraumorganisation (ESA) eine zweite Version, nachdem sie von vielen verschiedenen Interessenvertretern des europäischen Weltraum-ISVV eingegangen war.

Methodik

ISVV besteht normalerweise aus fünf Hauptphasen, diese Phasen können sequentiell oder als Ergebnis eines Tailoring-Prozesses ausgeführt werden.

Planung

  • Planung von ISVV-Aktivitäten
  • Systemkritikalitätsanalyse: Identifizierung kritischer Komponenten durch eine Reihe von RAMS- Aktivitäten (Value for Money)
  • Auswahl der geeigneten Methoden und Werkzeuge

Anforderungsüberprüfung

  • Prüfung auf: Vollständigkeit, Richtigkeit, Prüfbarkeit

Designüberprüfung

  • Designadäquanz und Konformität mit Softwareanforderungen und Schnittstellen
  • Interne und externe Konsistenz
  • Überprüfung der Machbarkeit und Wartung

Code-Verifizierung

Validierung

  • Identifizierung instabiler Komponenten/Funktionalitäten
  • Validierung mit Fokus auf Fehlerbehandlung: ergänzende (nicht gleichzeitige) Validierung in Bezug auf die vom Entwicklungsteam durchgeführte Validierung
  • Einhaltung von Software- und Systemanforderungen
  • Black - Box - Tests und White - Box - Testverfahren
  • Erfahrungsbasierte Techniken

Regulatorisches Umfeld

Software muss oft die Compliance-Anforderungen gesetzlich regulierter Branchen erfüllen, die oft von Regierungsbehörden oder Industrieverwaltungsbehörden geleitet werden. Beispielsweise verlangt die FDA, dass Softwareversionen und Patches validiert werden.

Siehe auch

Weiterlesen

  • 1012-2012 IEEE-Standard für System- und Softwareverifizierung und -validierung . 2012. doi : 10.1109/IEEESTD.2012.6204026 . ISBN 978-0-7381-7268-2.
  • Tran, E. (1999). "Verifizierung/Validierung/Zertifizierung" . In Koopman, P. (Hrsg.). Themen in zuverlässigen eingebetteten Systemen . Carnegie-Mellon-Universität . Abgerufen 2007-05-18 .
  • Menzies, T.; Y. Hu (2003). "Data Mining für vielbeschäftigte Menschen". Computer . 36 (1): 22–29. doi : 10.1109/MC.2003.1244531 .

Externe Links

Verweise

  1. ^ Pham, H. (1999). Software-Zuverlässigkeit . John Wiley & Sons, Inc. p. 567. ISBN 9813083840. Software-Validierung. Der Prozess, um sicherzustellen, dass die Software den richtigen Prozess ausführt. Software-Verifizierung. Der Prozess, um sicherzustellen, dass die Software den Prozess richtig durchführt.“ Ebenso und auch dort: „Kurz gesagt drückte Böhm (3) den Unterschied zwischen der Softwareverifikation und der Softwarevalidierung wie folgt aus: Verifikation: ''Bauen wir das Produkt richtig? ?'' Validierung: ''Bauen wir das richtige Produkt?''.
  2. ^ "CMMI für Software Engineering, Version 1.1, gestufte Darstellung (CMMI-SW, V1.1, gestuft)" . Ressourcen.sei.cmu.edu . Abgerufen 2021-03-20 .
  3. ^ a b c "Department of Defense Documentation of Verification, Validation & Accreditation (VV&A) für Modelle und Simulationen". Agentur für Raketenabwehr. 2008. Cite Journal erfordert |journal=( Hilfe )
  4. ^ Rogers, R. (1981-10-26). "Planung für unabhängige Software-Verifizierung und -Validierung" . 3. Computer in der Luft- und Raumfahrtkonferenz . San Diego, CA, USA: Amerikanisches Institut für Luft- und Raumfahrt. doi : 10.2514/6.1981-2100 .
  5. ^ Ambrosio, Ana; Mattiello-Francisco, Fatima; Martins, Eliane (2008-05-12). „Ein unabhängiger Software-Verifizierungs- und Validierungsprozess für Raumfahrtanwendungen“ . SpaceOps-Konferenz 2008 . Heidelberg, Deutschland: Amerikanisches Institut für Luft- und Raumfahrt. doi : 10.2514/6.2008-3517 . ISBN 978-1-62410-167-0.
  6. ^ Lewis, Robert O. (1992). Unabhängige Verifizierung und Validierung: ein Lifecycle-Engineering-Prozess für Qualitätssoftware . New York: Wiley. ISBN 0-471-57011-7. OCLC  74908695 .
  7. ^ a b Asbury, Michael (2015-03-09). "Über das IV&V-Programm der NASA" . Nasa . Abgerufen 2021-03-20 .
  8. ^ Balci, O. (2010). "Goldene Regeln für die Verifizierung, Validierung, Prüfung und Zertifizierung von Modellierungs- und Simulationsanwendungen" . undefiniert . Abgerufen 2021-03-20 .
  9. ^ "Abschnitt Flugsoftwaresysteme (TEC-SWF)" . www.esa.int . Abgerufen 2021-03-20 .
  10. ^ a b lavva.pt. "Neuer ISVV-Leitfaden für Weltraum in Arbeit" . www.kritischesoftware.com . Abgerufen 2021-03-20 .
  11. ^ "Allgemeine Prinzipien der Softwarevalidierung; Endgültige Leitlinien für die Industrie und das FDA-Personal" (PDF) . Lebensmittel- und Arzneimittelbehörde . 11. Januar 2002 . Abgerufen am 12. Juli 2009 .
  12. ^ „Leitfaden für die Industrie: Teil 11, Elektronische Aufzeichnungen; Elektronische Signaturen – Umfang und Anwendung“ (PDF) . Lebensmittel- und Arzneimittelbehörde . August 2003 . Abgerufen am 12. Juli 2009 .
  13. ^ "Leitfaden für die Industrie: Cybersicherheit für vernetzte medizinische Geräte mit Standardsoftware (OTS)" (PDF) . Lebensmittel- und Arzneimittelbehörde . 14. Januar 2005 . Abgerufen am 12. Juli 2009 .