V-Modell

Das V-Modell des Systems-Engineering-Prozesses. ⓘ

Das V-Modell ist eine grafische Darstellung des Lebenszyklus einer Systementwicklung. Es wird verwendet, um strenge Modelle des Entwicklungslebenszyklus und des Projektmanagements zu erstellen. Das V-Modell lässt sich in drei große Kategorien einteilen: das deutsche V-Modell, ein allgemeines Testmodell und der Standard der US-Regierung. ⓘ

Das V-Modell fasst die wichtigsten Schritte zusammen, die in Verbindung mit den entsprechenden Ergebnissen innerhalb des Rahmens der computergestützten Systemvalidierung oder der Projektlebenszyklusentwicklung durchgeführt werden müssen. Es beschreibt die auszuführenden Aktivitäten und die Ergebnisse, die während der Produktentwicklung erzielt werden müssen. ⓘ

Die linke Seite des "V" steht für die Zerlegung der Anforderungen und die Erstellung der Systemspezifikationen. Die rechte Seite des "V" steht für die Integration der Teile und deren Validierung. Die Anforderungen müssen jedoch zunächst anhand der übergeordneten Anforderungen oder des Nutzerbedarfs validiert werden. Darüber hinaus gibt es auch so etwas wie die Validierung von Systemmodellen. Diese kann teilweise auch auf der linken Seite erfolgen. Die Behauptung, dass die Validierung nur auf der rechten Seite stattfindet, ist nicht ganz richtig. Am einfachsten ist es zu sagen, dass die Verifizierung immer gegen die Anforderungen (technische Begriffe) und die Validierung immer gegen die reale Welt oder die Bedürfnisse der Benutzer erfolgt. Die Luft- und Raumfahrtnorm RTCA DO-178B besagt, dass die Anforderungen validiert - als wahr bestätigt - werden und das Endprodukt verifiziert wird, um sicherzustellen, dass es diese Anforderungen erfüllt. ⓘ

Validierung kann mit der Frage ausgedrückt werden: "Bauen Sie das Richtige?" und Verifizierung mit "Bauen Sie es richtig?" ⓘ

Phasen des V-Modells über Zeit und Detaillierung ⓘ

Vorgeschlagen wurde dieses Vorgehen zuerst von dem US-amerikanischen Softwareingenieur Barry Boehm im Jahre 1979 und basiert auf dem Wasserfallmodell: Die Phasenergebnisse sind bindende Vorgaben für die nächsttiefere Projektphase. Der linke, nach unten führende Ast für die Spezifizierungsphasen schließt mit der Realisierungsphase ab. Eine Erweiterung gegenüber dem Wasserfallmodell sind die zeitlich nachfolgenden Testphasen, die im rechten, nach oben führenden Ast dargestellt werden. Den spezifizierenden Phasen stehen jeweils testende Phasen gegenüber, was in der Darstellung ein charakteristisches „V“ ergibt, das dem Modell auch den Namen gab. Diese Gegenüberstellung soll zu einer möglichst hohen Testabdeckung führen, weil die Spezifikationen der jeweiligen Entwicklungsstufen die Grundlage für die Tests (Testfälle) in den entsprechenden Teststufen sind. ⓘ

Zum V-Modell im Allgemeinen werden in der Literatur die Anzahl der Phasen und auch deren Bezeichnungen unterschiedlich dargestellt, jedoch immer mit 1:1-Gegenüberstellung von Entwurfs- und Teststufen. ⓘ

Das allgemeine V-Modell ist die Grundlage von Entwicklungsstandards wie z. B. dem V-Modell (Entwicklungsstandard) der öffentlichen Hand in Deutschland. ⓘ

Arten

Es gibt drei allgemeine Arten von V-Modellen. ⓘ

V-Modell

Das deutsche V-Modell, die offizielle Projektmanagementmethode der deutschen Regierung. Es entspricht in etwa PRINCE2, ist aber direkter auf die Softwareentwicklung ausgerichtet. Das Hauptmerkmal der Verwendung einer "V"-Darstellung bestand darin, den Nachweis zu verlangen, dass die Produkte auf der linken Seite des V von der entsprechenden Test- und Integrationsorganisation, die die rechte Seite des V umsetzt, akzeptiert werden. ⓘ

Allgemeines Testen

In der weltweiten Testgemeinschaft wird das V-Modell weithin als eine vage illustrative Darstellung des Softwareentwicklungsprozesses angesehen, wie er im International Software Testing Qualifications Board Foundation Syllabus für Softwaretester beschrieben wird. Es gibt keine einheitliche Definition dieses Modells, das im alternativen Artikel über das V-Modell (Softwareentwicklung) direkter behandelt wird. ⓘ

Standard der US-Regierung

Auch in den USA gibt es ein staatliches Standard-V-Modell, das wie sein deutsches Pendant etwa 20 Jahre alt ist. Sein Anwendungsbereich ist ein enger gefasstes Modell für den Lebenszyklus der Systementwicklung, das jedoch weitaus detaillierter und strenger ist, als die meisten britischen Praktiker und Tester unter dem V-Modell verstehen würden. ⓘ

Validierung vs. Verifizierung

Manchmal wird gesagt, dass Validierung durch die Frage "Bauen Sie das Richtige?" und Verifizierung durch "Bauen Sie es richtig?" ausgedrückt werden kann. In der Praxis werden diese Begriffe unterschiedlich verwendet. ⓘ

Der PMBOK-Leitfaden, der auch von der IEEE als Standard übernommen wurde (der gemeinsam von INCOSE, dem Systems Engineering Research Council SERC und der IEEE Computer Society gepflegt wird), definiert sie in seiner vierten Ausgabe wie folgt:

• "Validierung. Die Zusicherung, dass ein Produkt, eine Dienstleistung oder ein System die Anforderungen des Kunden und anderer identifizierter Interessengruppen erfüllt. Sie beinhaltet oft die Akzeptanz und Eignung bei externen Kunden. Im Gegensatz zur Verifizierung."
• "Verifizierung. Die Bewertung, ob ein Produkt, eine Dienstleistung oder ein System einer Vorschrift, Anforderung, Spezifikation oder auferlegten Bedingung entspricht oder nicht. Es handelt sich dabei oft um einen internen Prozess. Im Gegensatz zur Validierung." ⓘ

Ziele

Das V-Modell ist ein Leitfaden für die Planung und Durchführung von Projekten. Die folgenden Ziele sollen durch eine Projektdurchführung erreicht werden:

• Minimierung von Projektrisiken: Das V-Modell verbessert die Projekttransparenz und Projektsteuerung, indem es standardisierte Vorgehensweisen vorgibt und die entsprechenden Ergebnisse und verantwortlichen Rollen beschreibt. Es ermöglicht ein frühzeitiges Erkennen von Planungsabweichungen und Risiken und verbessert das Prozessmanagement, wodurch das Projektrisiko reduziert wird.
• Verbesserung und Sicherstellung der Qualität: Als standardisiertes Vorgehensmodell stellt das V-Modell sicher, dass die zu liefernden Ergebnisse vollständig sind und die gewünschte Qualität haben. Definierte Zwischenergebnisse können frühzeitig überprüft werden. Einheitliche Produktinhalte verbessern die Lesbarkeit, Verständlichkeit und Überprüfbarkeit.
• Reduktion der Gesamtkosten über den gesamten Projekt- und Systemlebenszyklus: Der Aufwand für die Entwicklung, die Produktion, den Betrieb und die Wartung eines Systems kann durch die Anwendung eines standardisierten Vorgehensmodells transparent berechnet, geschätzt und kontrolliert werden. Die erzielten Ergebnisse sind einheitlich und leicht nachvollziehbar. Dies reduziert die Abhängigkeit des Erwerbers vom Lieferanten und den Aufwand für nachfolgende Aktivitäten und Projekte.
• Verbesserung der Kommunikation zwischen allen Beteiligten: Die standardisierte und einheitliche Beschreibung aller relevanten Elemente und Begriffe ist die Basis für das gegenseitige Verständnis zwischen allen Beteiligten. Dadurch wird der Reibungsverlust zwischen Anwender, Erwerber, Lieferant und Entwickler reduziert. ⓘ

Themen des V-Modells

Systemtechnik und Verifikation. ⓘ

Systemtechnik und -verifikation

Der Systems-Engineering-Prozess (SEP) bietet einen Weg zur Verbesserung der Kosteneffizienz komplexer Systeme aus der Sicht des Systemeigentümers über die gesamte Lebensdauer des Systems, von der Konzeption bis zur Ausmusterung. ⓘ

Er umfasst die frühzeitige und umfassende Ermittlung der Ziele, ein Betriebskonzept, das die Bedürfnisse der Nutzer und die Betriebsumgebung beschreibt, gründliche und prüfbare Systemanforderungen, einen detaillierten Entwurf, die Implementierung, strenge Akzeptanztests des implementierten Systems, um sicherzustellen, dass es die angegebenen Anforderungen erfüllt (Systemverifizierung), die Messung seiner Wirksamkeit bei der Erreichung der Ziele (Systemvalidierung), den laufenden Betrieb und die Wartung, Systemaufrüstungen im Laufe der Zeit und schließlich die Außerbetriebnahme. ⓘ

Der Schwerpunkt des Prozesses liegt auf anforderungsorientiertem Design und Testen. Alle Entwurfselemente und Akzeptanztests müssen sich auf eine oder mehrere Systemanforderungen zurückführen lassen, und jede Anforderung muss durch mindestens ein Entwurfselement und einen Akzeptanztest abgedeckt werden. Diese Strenge stellt sicher, dass nichts unnötig getan wird und alles Notwendige getan wird. ⓘ

Die zwei Ströme

Spezifikationsstrom

Der Spezifikationsstrom besteht hauptsächlich aus:

• Spezifikationen der Benutzeranforderungen
• Funktionale Anforderungsspezifikationen
• Design-Spezifikationen ⓘ

Test-Stream

Der Teststrom besteht im Allgemeinen aus:

• Installationsqualifizierung (IQ)
• Qualifizierung für den Betrieb (OQ)
• Leistungsqualifizierung (PQ) ⓘ

Der Entwicklungsstrom kann (je nach Systemtyp und Entwicklungsumfang) aus Anpassung, Konfiguration oder Kodierung bestehen. ⓘ

Anwendungen

Off-Core-Alternativen (zur Veranschaulichung von Aufwärts- und Abwärtsiterationen sowie der Zeit- und Reifedimension). Quelle - K. Forsberg und H. Mooz 2004 ⓘ

Das V-Modell wird verwendet, um den Softwareentwicklungsprozess innerhalb der deutschen Bundesverwaltung zu regeln. Heutzutage ist es immer noch der Standard für Projekte der deutschen Bundesverwaltung und des Verteidigungsministeriums sowie für Softwareentwickler in der Region. ⓘ

Das Konzept des V-Modells wurde in den späten 1980er Jahren gleichzeitig, aber unabhängig voneinander in Deutschland und in den Vereinigten Staaten entwickelt:

• Das deutsche V-Modell wurde ursprünglich von der IABG in Ottobrunn bei München in Zusammenarbeit mit dem Bundesamt für Wehrtechnik und Beschaffung in Koblenz für das Bundesverteidigungsministerium entwickelt. Es wurde im Sommer 1992 vom Bundesinnenministerium für den zivilen Behördenbereich übernommen.
• Das US-amerikanische V-Modell, wie es in den Proceedings des National Council on Systems Engineering (NCOSE; seit 1995 INCOSE) von 1991 dokumentiert ist, wurde für Satellitensysteme entwickelt, die Hardware, Software und menschliche Interaktion umfassen.
• Das V-Modell tauchte zum ersten Mal bei Hughes Aircraft um 1982 als Teil des Vorentwurfs für das FAA Advanced Automation System (AAS) Programm auf. Es bildete schließlich die Teststrategie für den Hughes AAS Design Competition Phase (DCP) Vorschlag. Es wurde erstellt, um den Test- und Integrationsansatz zu zeigen, der durch neue Herausforderungen zur Aufdeckung latenter Fehler in der Software angetrieben wurde. Die Notwendigkeit dieses neuen Niveaus der Erkennung latenter Fehler ergab sich aus dem Ziel, die Denk- und Planungsprozesse des Fluglotsen zu automatisieren, wie es das Programm zur automatischen Flugverkehrskontrolle auf der Strecke (AERA) vorsieht. Der Grund, warum das V so leistungsfähig ist, liegt in der Hughes-Kultur, alle Texte und Analysen mit mehrdimensionalen Bildern zu verbinden. Dies war die Grundlage der Sequential Thematic Organization of Publications (STOP), die 1963 von Hughes entwickelt und bis zur Ausgliederung von Hughes durch das Howard Hughes Medical Institute im Jahr 1985 verwendet wurde.
• Das US-Verteidigungsministerium stellt die Interaktionen des Systementwicklungsprozesses in eine V-Modell-Beziehung. ⓘ

Es hat inzwischen eine breite Anwendung sowohl in kommerziellen als auch in Verteidigungsprogrammen gefunden. Es wird in erster Linie im Projektmanagement und während des gesamten Projektlebenszyklus eingesetzt. ⓘ

Ein grundlegendes Merkmal des US-amerikanischen V-Modells ist, dass sich Zeit und Reifegrad von links nach rechts bewegen und man sich nicht in der Zeit zurückbewegen kann. Alle Iterationen erfolgen entlang einer vertikalen Linie zu höheren oder niedrigeren Ebenen in der Systemhierarchie, wie in der Abbildung dargestellt. Dies hat sich als ein wichtiger Aspekt des Modells erwiesen. Die Erweiterung des Modells zu einem Dual-Vee-Konzept wird in der Referenz behandelt. ⓘ

Da das V-Modell öffentlich zugänglich ist, wird es auch von vielen Unternehmen genutzt. Im Projektmanagement ist es eine mit PRINCE2 vergleichbare Methode und beschreibt sowohl Methoden für das Projektmanagement als auch Methoden für die Systementwicklung. Das V-Modell ist zwar starr im Ablauf, kann aber sehr flexibel angewandt werden, vor allem, wenn es um den Bereich außerhalb der normalen Parameter des Systementwicklungslebenszyklus geht. ⓘ

Vorteile

Dies sind die Vorteile, die das V-Modell gegenüber anderen Systementwicklungsmodellen bietet:

• Die Nutzer des V-Modells beteiligen sich an der Entwicklung und Pflege des V-Modells. Ein Change Control Board pflegt das V-Modell öffentlich. Der Änderungskontrollausschuss trifft sich täglich bis wöchentlich und bearbeitet alle Änderungswünsche, die während der Systementwicklung und des Tests eingehen.
• Das V-Modell bietet konkrete Hilfestellung bei der Umsetzung einer Aktivität und ihrer Arbeitsschritte, indem es die für die Durchführung eines Arbeitsschritts erforderlichen Ereignisse explizit definiert: Jedes Aktivitätsschema enthält Anweisungen, Empfehlungen und detaillierte Erläuterungen zur Aktivität. ⓘ

Grenzen

Folgende Aspekte werden durch das V-Modell nicht abgedeckt, sie müssen zusätzlich geregelt werden, oder das V-Modell muss entsprechend angepasst werden:

• Die Vergabe von Aufträgen für Dienstleistungen ist nicht geregelt.
• Die Organisation und Durchführung von Betrieb, Wartung, Instandhaltung und Entsorgung der Anlage sind nicht Gegenstand des V-Modells. Die Planung und Erstellung eines Konzepts für diese Aufgaben ist jedoch im V-Modell geregelt.
• Das V-Modell befasst sich mit der Softwareentwicklung innerhalb eines Projektes und nicht mit einer ganzen Organisation. ⓘ

Das V-Modell in der Entwicklung mechatronischer Systeme

V-Modell nach VDI/VDE 2206 aus dem Jahr 2021 ⓘ

Spätestens seit 2004 wird das V-Modell auch allgemeiner in Entwicklungsprozessen verwendet. So empfiehlt die Richtlinie VDI/VDE 2206 das V-Modell als Teil der „Entwicklungsmethodik für mechatronische Systeme“. Hintergrund ist dabei die zunehmende Integration von mechanischen, elektrischen und informationstechnischen Komponenten in mechatronischen Systemen und die damit verbundene Steigerung der Komplexität. ⓘ

Ausgangspunkt ist dabei meist eine konkrete Anforderung bzw. eine Anforderungsliste in Form eines Entwicklungsauftrags. Diese Anforderungen stellen zugleich den Maßstab dar, nach dem das spätere Produkt zu bewerten ist. Im Systementwurf wird die Gesamtfunktion des Systems bzw. des späteren Produktes in Teilfunktionen zerlegt. Sind die Teilfunktionen ermittelt erfolgt die Konkretisierung des Lösungskonzeptes meist getrennt in den einzelnen Fachdisziplinen (Domänen). Die konkreten Lösungen der einzelnen Disziplinen werden im Rahmen der Systemintegration zu einem Gesamtsystem verbunden und ihr Zusammenwirken untersucht. Fortlaufend wird dabei im Zuge der Eigenschaftsabsicherung der jetzige Entwurf gegen die spezifizierten Anforderungen geprüft, dadurch wird sichergestellt, dass die gewünschten Eigenschaften mit den tatsächlichen Eigenschaften übereinstimmen. Der gesamte Prozess kann dabei durch rechnergestützte Modellierung und Simulation unterstützt werden. Ergebnis eines durchlaufenen Zyklus des V-Modells ist das „Produkt“, wobei es sich hierbei um einen bestimmten Reifegrad (Funktionsmuster, Prototyp, Vorserienmuster etc.) des geplanten Endproduktes handeln kann. Das V-Modell stellt also einen iterativen Prozess dar, der sich schrittweise der endgültigen Lösung annähert und je nach Komplexität des Endproduktes vielfach durchlaufen wird. ⓘ

Das V-Modell as Datenstruktur

Neben der Funktion als Prozessmodell kann das V-Modell auch die Grundlage für die Datenstruktur in der Entwicklung übernehmen. Dabei werden die verschiedenen Artefakte der Entwicklung auf dem V positioniert: Links oben die Anforderungen, bis zur Mitte unten zur Implementierung und auf dem rechten Arm die dazugehörigen V&V-Artefakte. Eine Traceability zwischen den Artefakten unterstützt das Arbeiten mit den Artefakten. Diese Umsetzung ist in den gängigen Anforderungsmangementwerkzeugen üblich. ⓘ

Weiterentwicklung

Auf Basis von Erfahrungen aus der industriellen Anwendung und dem technologischen Fortschritt wurde seither eine Vielzahl von Weiterentwicklungen des V-Modells publiziert. Durch Hinwendung zu agilen Methoden, Concurrent-Engineering-Prozessen und die zeitgleiche Relevanz des Systems Engineerings wurde das V-Modell um 2000 beispielsweise zum W-Modell weiterentwickelt. Mit einer vorgezogenen Testphase und der Einbindung von Simulationsprozessen und statistischen Methoden zur Fehlervermeidung greift das W-Modell Maßnahmen auf, die zur Parallelisierung von Arbeitsschritten genutzt werden können. Es dient damit als Möglichkeit, agile Ansätze in klassische Arbeitsumfelder einzubetten. Der Begriff findet vorrangig im deutschsprachigen Raum Verwendung. ⓘ

Die Richtlinie VDI 2206 wurde im VDI in den Jahren 2014 bis 2021 von dem Fachausschuss 4.10 „Interdisziplinäre Produktentstehung“ der VDI/VDE-Gesellschaft Mess- und Automatisierungstechnik überarbeitet und im November 2021 veröffentlicht. Hierbei wurden auf Basis einer Schwachstellenanalyse der hohen Interdisziplinarität, Komplexität und Heterogenität moderner Systeme Rechnung getragen und das V-Modell erneuert. Die Entwicklungen moderner Produkte, die neben einem mechanischen, häufig elektronischen sowie möglichen Software-Anteile mit einer Verbindung zum Internet der Dinge und Dienste umfassen kann, angepasst. Es existieren neben der neuen Richtlinie VDI/VDE 2206 "Entwicklung mechatronischer und cyber-physischer Systeme" weitere wissenschaftliche Veröffentlichungen. Zentral war die Erneuerung des Bildes des V-Modells, das zum Download zur Verfügung steht. https://www.vdi.de/richtlinien/programme-zu-vdi-richtlinien/vdi-2206</nowiki> ⓘ