Was ist Softwareverifikation? Was sie prüft – und was nicht

Softwareverifikation umfasst Prüfungen, mit denen festgestellt wird, ob ein Produkt oder ein Entwicklungsergebnis den dafür geltenden Anforderungen und Spezifikationen entspricht. Die praktische Frage lautet: „Wurde es gemäß den Vorgaben erstellt?“ Im Systems-Engineering-Rahmen der NASA vergleicht die Verifikation das Produkt mit seinen Anforderungen oder Spezifikationen; dieselbe Unterscheidung hilft auch beim Verständnis von Softwareprogrammen, Komponenten und Liefergegenständen. NASA: Produktverifikation

Verifikation ist keine einzelne Tätigkeit, die zwangsläufig erst am Ende stattfindet. Sie kann während der Entwicklung auf unterschiedliche Liefergegenstände angewendet werden: Eine Spezifikation lässt sich anhand zuvor vereinbarter Bedürfnisse prüfen, ein Entwurf anhand von Anforderungen und eine Implementierung anhand des Entwurfs oder technischer Kriterien. Der Vergleichsmaßstab muss ausdrücklich benannt sein: Ohne eine identifizierbare Anforderung lässt sich nicht klar sagen, welche Bedingung geprüft wurde. Die konkrete Abfolge hängt vom Projekt ab und ist keine allgemeingültige Anleitung.

Verifikation bedeutet auch nicht, die gesamte Software für jede Situation als korrekt, sicher oder nützlich zu erklären. Eine Prüfung liefert Belege für einen bestimmten Umfang, anhand festgelegter Kriterien und unter bestimmten Bedingungen. Die Prüfung einer konkreten Berechnung zeigt beispielsweise nicht automatisch, dass sich alle Funktionen, Versionen, Eingabedaten und Umgebungen angemessen verhalten.

Zu den Prüfgegenständen können Anforderungen, Entwurf, ausführbarer Code, integrierte Komponenten und zugehörige Dokumentation gehören, sofern anwendbare Kriterien für den Vergleich vorliegen. Die NASA-Seite beschreibt die Verifikation eines Endprodukts als Prüfung der Übereinstimmung mit Anforderungen oder Spezifikationen und betont, wie wichtig eine kontrollierte Referenzkonfiguration ist. Dieselbe Logik gilt für den Umfang: Jede Aussage sollte benennen, welches Element und welche Version untersucht wurden. NASA: Produktverifikation

Ein einfaches Beispiel: Eine Anforderung könnte vorgeben, dass eine Anwendung aus Mengen und Preisen einen Gesamtbetrag berechnet. Bei der Verifikation lässt sich prüfen, ob die implementierte Formel der spezifizierten Regel entspricht und ob das Ergebnis in den untersuchten Fällen dem erwarteten Ergebnis entspricht. Ist die Regel selbst mangelhaft formuliert – etwa weil ein für die tatsächliche Nutzung erforderlicher Rabatt fehlt –, kann das Programm der Regel entsprechen und dennoch den Bedarf verfehlen. Deshalb sind Verifikation und Validierung keine Synonyme.

Auch die Dokumentation ist wichtig, weil sie festlegt, was als konform gilt, und festhält, welche Tätigkeit durchgeführt wurde. Ein Verifikations- und Validierungsplan kann Zuständigkeiten, maßgebliche Dokumente, Methoden und Matrizen dokumentieren, die Anforderungen mit Nachweisen verknüpfen. Der von der NASA veröffentlichte Gliederungsentwurf enthält getrennte Abschnitte für Verifikations- und Validierungsmethoden, deren Umsetzung und Anforderungsmatrizen. Rückverfolgbarkeit hilft, Abdeckung und Lücken zu erkennen, aber eine vollständige Matrix beweist für sich genommen nicht, dass jedes Ergebnis korrekt ist. NASA: Gliederungsentwurf für einen Verifikations- und Validierungsplan

Bei der Verifikation können verschiedene Untersuchungsformen kombiniert werden. Bei einer menschlichen Prüfung werden Dokumente oder Änderungen mit festgelegten Kriterien verglichen; eine Analyse kann Eigenschaften oder Widersprüche erkennen, ohne das Programm auszuführen; ein Test beobachtet das Softwareverhalten bei der Ausführung unter ausgewählten Bedingungen. Die Informationen des NIST zu seinen Schulungsangeboten für Softwareverifikation und -validierung heben die Dokumentation von Nachweisen und den Einsatz beider Arten von Verfahren hervor. Die Beispiele beziehen sich jedoch auf Labor-Tabellenkalkulationen und stellen keine vollständige Liste für alle Projekte dar. NIST: Schulung zu Softwareverifikation und -validierung

Ein Beispiel für die Prüfung anhand einer Spezifikation

Angenommen, eine Spezifikation verlangt, dass ein System eine Anfrage ablehnt, wenn ein Pflichtfeld fehlt. Bei einer Prüfung ließe sich feststellen, ob die Anforderung definiert ist und der Entwurf diesen Fall berücksichtigt; bei einem Test könnte eine unvollständige Anfrage gesendet und die beobachtete Antwort mit dem erwarteten Ergebnis verglichen werden. Jede Methode beantwortet eine andere Frage: Eine Prüfung untersucht Artefakte und Überlegungen, ein Test beobachtet das Verhalten bei bestimmten Eingaben und Bedingungen.

Tests untersuchen nicht allein dadurch alle möglichen Eingaben, dass sie ausgeführt werden. Das Ergebnis hängt davon ab, welche Fälle ausgewählt, welche Version getestet und welche Umgebung verwendet wurde. „Die Tests bestanden“ bedeutet daher, dass bei den durchgeführten Prüfungen keine Abweichung festgestellt wurde – nicht, dass die Fehlerfreiheit nachgewiesen ist. Nachweise lassen sich besser interpretieren, wenn die Verknüpfung von Anforderung, Abnahmekriterium, ausgeführtem Fall, Ergebnis und Produktversion erhalten bleibt.

Eine hilfreiche Dokumentationspraxis

Damit andere nachvollziehen können, was verifiziert wurde, sollten das untersuchte Element und seine Version, die zugehörige Anforderung, die verwendete Methode, relevante Bedingungen und das Ergebnis festgehalten werden. Wenn Kontrollen oder Audits wichtig sind, lässt sich anhand dieser Aufzeichnung der Umfang erläutern und spätere Änderungen überprüfen. Das NIST nennt die Dokumentation von Nachweisen und die fortlaufende Bewertung von Software als Ziele seiner Schulungsressourcen für Labore; der konkrete Inhalt der Aufzeichnung sollte dem jeweiligen Kontext entsprechen. NIST: Schulung zu Softwareverifikation und -validierung

Die Verifikation fragt, ob ein Produkt den festgelegten Anforderungen oder Spezifikationen entspricht. Die Validierung fragt, ob das Produkt den vorgesehenen Zweck und die relevanten Bedürfnisse im Nutzungskontext erfüllt. Die NASA formuliert den Unterschied anhand zweier Fragen: Wurde das Produkt gemäß den Vorgaben richtig umgesetzt, und erfüllt es die Absicht des Kunden in der Einsatzumgebung? NASA: Produktverifikation

Die Tabelle fasst die von der NASA beschriebene Zweckunterscheidung zusammen. Sie bedeutet weder, dass jede Tätigkeit ausschließlich eine bestimmte Methode verwendet, noch dass eine starre Grenze zwischen den Verfahren besteht. NASA: Produktverifikation

Betrachten wir eine Anwendung, die Versandkosten berechnet. Wenn die Spezifikation besagt, dass Grundgebühr und Aufschlag zu addieren sind, ist die Prüfung dieser Berechnung Verifikation. Die Frage, ob die Anwendung tatsächliche Bedürfnisse berücksichtigt – etwa ob sich im Ablauf das Ziel und die vom Dienst angebotene Versandart angeben lassen –, gehört zur Validierung. Die erste Prüfung kann erfolgreich sein, während die zweite zeigt, dass die definierte Lösung für den vorgesehenen Einsatz nicht geeignet ist.

Deshalb genügt es nicht, ein Produkt als „verifiziert“ zu bezeichnen, ohne Bezugspunkt und Umfang anzugeben. Die Validierung ersetzt auch nicht jede Prüfung anhand der Spezifikationen: Beide Perspektiven können nötig sein und sich ergänzen. Die von der NASA beschriebenen Prozesse unterscheiden ihre Ziele, erkennen aber an, dass manche Tätigkeiten in der Praxis ähnlich aussehen können. Die Bezeichnung hängt von der zu beantwortenden Frage ab, nicht allein davon, ob eine Tätigkeit Test oder Prüfung heißt.

Nachweise können aus Testergebnissen, Beobachtungen aus Prüfungen, dokumentierten Analysen oder Matrizen bestehen, die Anforderungen mit Kontrollen verknüpfen. Diese Nachweisarten belegen nicht dasselbe: Ein Ausführungsergebnis stützt eine Beobachtung für bestimmte Eingaben und eine bestimmte Umgebung; eine Prüfung kann dokumentieren, dass ein Artefakt anhand von Kriterien bewertet wurde. Die Schlussfolgerung darf nicht über die Nachweise hinausgehen und nicht auf ungeprüfte Versionen oder Bedingungen übertragen werden.

Rückverfolgbarkeit hilft, die Verbindung zwischen einer Anforderung und der zu ihrer Prüfung vorgesehenen Tätigkeit nachzuvollziehen. Der Planungsentwurf der NASA sieht sowohl eine Anforderungsverifikationsmatrix als auch eine Validierungsmatrix vor und verlangt außerdem die Dokumentation von Methoden und Aktivitäten. Das bietet eine Struktur zur Ordnung der Nachweise, aber keine automatische Gewähr dafür, dass Anforderungen gut formuliert, vollständig oder repräsentativ für die Bedürfnisse der Nutzer sind. NASA: Gliederungsentwurf für einen Verifikations- und Validierungsplan

Wenn sich beispielsweise eine Berechnungsregel ändert, lässt sich die Auswirkung überprüfen, sofern bekannt ist, welche Anforderungen, Komponenten und Prüffälle damit verbunden sind. Eine dokumentierte Verknüpfung kann jedoch veraltet sein oder wichtiges Verhalten auslassen. Versionsverwaltung und Überprüfung der Nachweise bleiben erforderlich; eine Liste abgehakter Kästchen ist nur dann nützlich, wenn sie tatsächliche Tätigkeiten, nachvollziehbare Ergebnisse und das richtige Artefakt beschreibt.

Verifikation ist eine begrenzte Praxis und kein mathematischer Beweis der Vollkommenheit. Fehler können bestehen bleiben, weil bestimmte Fälle nicht untersucht wurden, Kriterien unvollständig waren oder die reale Umgebung von der verwendeten abweicht. Ebenso ist es möglich, einer Spezifikation buchstabengetreu zu entsprechen, obwohl sie den Bedarf nicht angemessen abbildet. Eine verantwortungsvolle Aussage benennt daher, was anhand welcher Referenz und unter welchen Bedingungen geprüft wurde, statt die Fehlerfreiheit der Software zu behaupten.

Bei Projekten mit hohem Risiko oder besonderen Kontrollanforderungen kann die Unabhängigkeit der Prüfung wichtig sein. Das NIST-Glossar beschreibt unabhängige Verifikation und Validierung als Prüfung, Analyse und Tests durch eine objektive dritte Partei, die sowohl die Anforderungsdefinition als auch die Umsetzung von Funktionen und Sicherheitsanforderungen untersucht. Diese Beschreibung bezieht sich auf IV&V; sie bedeutet weder, dass jedes Projekt zwingend ein externes Team benötigt, noch dass Unabhängigkeit die Grenzen der Abdeckung beseitigt. NIST: Glossar zu unabhängiger Verifikation und Validierung

Die folgenden Fragen helfen, den Umfang einer Verifikationsaussage oder einer geplanten Prüfung konkret zu bestimmen:

• Welches Produkt, welche Komponente, welches Dokument und welche Version wurden untersucht?
• Mit welcher Anforderung, Spezifikation oder welchem Kriterium wurde verglichen?
• Welche Methode wurde unter welchen Bedingungen angewendet?
• Welche Nachweise wurden festgehalten, und welche Fälle decken sie nicht ab?
• Ging es um die Übereinstimmung mit der Spezifikation oder um die Eignung für den vorgesehenen Einsatz?

Die Norm ISO/IEC/IEEE 12207 bietet einen Rahmen für Softwarelebenszyklusprozesse, doch die für diesen Beitrag zusammengestellten Quellen enthalten nicht den offiziellen Normtext. Dieses Glossar schreibt der Norm daher keine konkreten Anforderungen zu und stellt keine normative Anleitung dar. Die hier erläuterten Hinweise stützen sich hauptsächlich auf NASA-Dokumentation zur Produktverifikation und -validierung sowie auf NIST-Ressourcen zu Nachweisen und IV&V; konkrete Verfahren sollten passend zum System, seinen Risiken und den geltenden Verpflichtungen ausgewählt werden. NASA: Produktverifikation NIST: IV&V