V-Modell
Das V-Modell ist ein Vorgehensmodell der System- und Softwareentwicklung: Der linke Ast verfeinert Anforderungen schrittweise bis zur Implementierung, der rechte Ast verifiziert jede Ebene gegen ihre Spezifikation. Jeder Entwicklungsstufe steht damit eine eigene Teststufe gegenüber — das unterscheidet das V-Modell vom einfachen Wasserfall, bei dem das Testen erst am Ende als eine Phase erscheint.
Aufbau: linker und rechter Ast
Die Kernidee des V ist die Zuordnung von Spezifikation und Verifikation auf jeder Ebene. Eine typische Ausprägung für eingebettete Systeme:
| Linker Ast (Spezifikation) | Rechter Ast (Verifikation) |
|---|---|
| Stakeholder- und Systemanforderungen | Validierung / Systemtest |
| Systemarchitektur | Systemintegrationstest |
| Softwareanforderungen | Software-Test |
| Softwarearchitektur | Software-Integrationstest |
| Detailentwurf und Implementierung | Unit-/Modultest |
Die Spitze des V bildet die Implementierung. Entscheidend ist die horizontale Beziehung: Der Systemintegrationstest wird gegen die Systemarchitektur geplant, der Unit-Test gegen den Detailentwurf — jede Teststufe beantwortet die Frage, ob die zugehörige Spezifikationsebene korrekt umgesetzt wurde. Testfälle können so bereits entstehen, während die jeweilige Ebene spezifiziert wird, nicht erst nach der Implementierung.
Rolle in ISO 26262 und Automotive SPICE
Sicherheitsnormen und Prozessqualitätsmodelle setzen die V-Struktur als Referenzrahmen voraus. Die ISO 26262 organisiert die Produktentwicklung entlang des V — auf Systemebene sowie in eigenen Ästen für Hardware- und Softwareentwicklung, jeweils mit Spezifikationsphasen auf der linken und Integrations- und Verifikationsphasen auf der rechten Seite. Automotive SPICE ordnet seine Engineering-Prozesse (System- und Software-Engineering von der Anforderungsanalyse bis zum Systemtest) ebenfalls in einer V-Darstellung an und verlangt bidirektionale Traceability zwischen den korrespondierenden Ebenen als Basispraktik. Wer in diesen Kontexten arbeitet, kommt am V-Modell als Ordnungsrahmen nicht vorbei — unabhängig davon, wie iterativ die tatsächliche Entwicklung abläuft.
V-Modell heißt nicht Wasserfall
Ein verbreitetes Missverständnis liest das V als starren, einmaligen Durchlauf. Das V beschreibt jedoch eine logische Struktur, keinen Kalender: Es legt fest, welche Verifikation zu welcher Spezifikation gehört — nicht, dass alle Anforderungen final sein müssen, bevor die erste Zeile Code entsteht. In der Praxis wird das V pro Iteration, Release oder Änderung durchlaufen; gerade bei kurzen Zyklen und Over-the-Air-Updates entsteht so eine Folge kleiner Vs. Davon zu unterscheiden ist das V-Modell XT, ein konkreter Vorgehensstandard für Projekte der öffentlichen Hand in Deutschland.
V-Modell in der Praxis: Das V ist nur so gut wie seine Querverbindungen
Der eigentliche Wert des V-Modells liegt in den horizontalen Beziehungen — und genau dort scheitert es in der Praxis am häufigsten. Anforderungen liegen im Requirements-Management-Werkzeug, Architekturmodelle im MBSE-Tool, Code und Unit-Tests im Repository, Systemtests im Testmanagement: Zwischen linkem und rechtem Ast verlaufen Werkzeuggrenzen. Ohne durchgängige Trace-Links von der Anforderung bis zum zugehörigen Testfall bleibt das V ein Schaubild — belegen lässt sich die Abdeckung dann nur durch manuelle Rekonstruktion. Erst mit gepflegter Traceability zwischen den Ästen kann eine Impact-Analyse bei jeder Änderung zeigen, welche Testfälle betroffen sind, und der Nachweis der Abdeckung wird auf Knopfdruck möglich statt zur wochenlangen Audit-Vorbereitung.