Management-Zusammenfassung dieses Beitrags:
Das V‑Modell (auch Vorgehensmodell, engl. V‑Model) beschreibt ein Vorgehen bei der Entwicklung von Software, Systemen oder Produkten, welches sich grafisch entlang eines Vs visualisieren lässt.
In diesem Beitrag wird das V‑Modell und dessen Einsatz in verschiedenen Kontexten wie dem Systems oder → Requirements Engineering beschrieben.
Das V‑Modell verwendet ein V zur Visualisierung der Reihenfolge von Schritten oder Prozessen. Die Besonderheit ist, dass die Schritte / Prozesse im V‑Modell in zwei Hälften (grüne und rote Rechtecke in Abbildung 0.1) so angeordnet sind, dass einem Schritt auf der linken Hälfte ein Schritt auf der rechten Hälfte zugeordnet werden kann.
Generell kommt das V‑Modell aus der → Softwareentwicklung, ist aber inzwischen nicht mehr darauf beschränkt. Die Einsatzgebiete sind:
- → Systems Engineering
- Requirements Engineering
- → Software Engineering
- → Projektmanagement
Abbildung 0.1 zeigt ein einfaches V‑Modell zur Softwareentwicklung: Auf der linken Hälfte / auf dem linken Zweig repräsentieren die grünen Rechtecke die Prozesse des Requirements und Software Engineerings. Die Umsetzung des entwickelten Komponentendesigns erfolgt in der Komponentenimplementierung (blaues Rechteck). Korrespondierend zu den Prozessen des Requirements und Software Engineerings werden die → Testprozesse auf der rechten Hälfte / auf dem rechten Zweig des Vs angeordnet (rote Rechtecke). Wichtig ist dabei vertikale Anordnung: Die Tests auf einer vertikalen Stufe (oder horizontalen Linie) gehören zu den entsprechenden Requirements- und Design-Prozessen und ‑Artefakten der gleichen vertikalen Stufe.
Abbildung 0.1: Ein einfaches V‑Modell
Auch wenn in diesem Beitrag und auch allgemein von “dem V‑Modell” gesprochen wird, so gibt es kein eindeutiges V‑Modell, was als allgemeingültig bezeichnet werden kann. Richtiger wäre es von “einem V‑Modell” zu sprechen, was für einen konkreten Einsatzfall verwendet wird.
1. Einleitung und Grundlagen
In diesem Kapitel werden zunächst einige Definitionen und Grundlagen zum V‑Modell geliefert.
1.1 Definitionen
In der Wikipedia steht /#Wiki-V-Modell/:
“Das V‑Modell ist ein Vorgehensmodell, welches ursprünglich für die Softwareentwicklung konzipiert wurde. Ähnlich dem → Wasserfallmodell organisiert es den Softwareentwicklungsprozess in Phasen. Zusätzlich zu diesen Entwicklungsphasen definiert das V‑Modell auch das Vorgehen zur Qualitätssicherung (→ Testen), indem den einzelnen Entwicklungsphasen Testphasen gegenüber gestellt werden. Auf der linken Seite wird mit einer funktionalen/fachlichen Spezifikation begonnen, die immer tiefer detailliert zu einer technischen Spezifikation und Implementierungsgrundlage ausgebaut wird. In der Spitze erfolgt die Implementierung, die anschließend auf der rechten Seite gegen die entsprechenden Spezifikationen der linken Seite getestet wird. So entsteht bildlich das namensgebende “V”, welches die einzelnen Entwicklungsebenen ihren jeweiligen Testebenen gegenüberstellt.”
Beim VDI wird ausgeführt /#V‑Modell-VDI-2206/:
“Das V‑Modell, 1995 von Bröhl und Dröschel in der Softwareentwicklung aufgebracht, beschreibt grundsätzlich eine sachlogische Verknüpfung von Aufgaben der interdisziplinären Produktentwicklung.”
1.2 Herleitung aus der Prozessdarstellung
Generell kann das V‑Modell aus einer Prozessdarstellung gewonnen werden. In Abbildung 1.1 ist die klassische Abfolge der Softwareentwicklung mit den fünf Phasen / Prozessschritten …
- Analyse,
- Design,
- Implementierung,
- Test und
- Betrieb
dargestellt. Aus der rein linearen Abfolge (Punkt A) wird durch einfaches Umzeichnen ein Wasserfallmodell gewonnen (Punkt B). Da Analyse und Betrieb sowie Design und Test “Gegenstücke darstellen”, kann ein V‑Modell daraus generiert werden (Punkt C).
Abbildung 1.1: Von der Prozessdarstellung zum V‑Modell
Anmerkungen:
- Das V‑Modell wird teilweise auch als “umgeklapptes Wasserfallmodell” bezeichnet
- Durch das Umzeichnen kommt eine zusätzliche Semantik / Bedeutung in das Modell, da sich die Elemente auf der gleichen horizontalen Ebene ergänzen
1.3 Darstellungsmöglichkeiten
Die Darstellung des Vs erfolgt entweder durch Rechtecke oder Parallelogramme (Abbildung 1.2). Beide Darstellungsformen sind gleichwertig.
Abbildung 1.2: Darstellungsformen des V‑Modells (generell)
1.4 Das V‑Modell XT
Das V‑Modell XT ist ein Vorgehensmodell für IT-Entwicklungsprojekte der Behörden und Verwaltungen der Bundesrepublik Deutschland /#Wiki-V-Modell/. Das V‑Modell XT beschreibt ebenfalls ein Vorgehen bei der Erstellung von Softwareprodukten, ist aber eher Projektmanagement-Vorgehensmodell mit vielen Projektmanagement-Vorgaben. Der Schwerpunkt in diesem Beitrag liegt jedoch bei dem der Produktentwicklung und ‑erstellung, sodass das V‑Modell XT nur gestreift wird.
Zum V‑Modell XT existieren umfangreiche und vollständig ausgearbeitete Dokumentationen, die unter /#V‑Modell-XT/ zu finden sind.
2. Der Einsatz in verschiedenen Themengebieten
Das V‑Modell kann in sehr vielen Gebieten rund um die Produktentstehung zum Einsatz kommen. In diesem Kapitel sind einige Beispiele aufgeführt.
2.1 Software Engineering
Im “klassischen” Software Engineering beschränkt sich das V‑Modell auf den Softwareentwicklungsprozess von der → Anforderungsermittlung bis zum → Abnahmetest (Abbildung 2.1). Dabei wird schrittweise (“von oben nach unten”) der Detaillierungsgrad erhöht. Die zeitliche Abfolge der einzelnen Vorgänge ergibt sich, indem man entlang der beiden schräg eingezeichneten Pfeile die Vorgänge, beginnend mit dem → Anforderungsmanagement und endend mit der Gesamtabnahme, bearbeitet.
Die Schritte im Einzelnen:
- Requirements / Anforderungen bilden die Basis für ein Softwaresystem und müssen daher frühzeitig ermittelt werden. Es müssen zumindest die Anforderungen erfasst werden, die für die Abnahme (im Abnahmetest) notwendig sind
- Die Systemspezifikation beschreibt das System als Ganzes und stellt entsprechend die Anforderungen eines Gesamtsystems zusammen
- Der Architekturentwurf ist eine technische Beschreibung, wie das Gesamtsystem aufgebaut werden soll und definiert insbesondere die Komponenten und die Schnittstellen zwischen den Komponenten
- Der Komponentenentwurf verfeinert die im Architekturentwurf festgelegten Komponenten und legt deren innere Struktur fest
- Die Implementierung ist die technische Umsetzung der Software und kann daher auch als Programmierung bezeichnet werden
- Beim Komponententest (oder auch Modul- oder Unit-Test) werden die einzelnen Komponenten anhand des Komponentenentwurfs getestet
- Der Integrationstest betrachtetet mehrere Komponenten und deren Zusammenspiel (über die festgelegten Schnittstellen)
- Beim Systemtest wird das Gesamtsystem getestet
- Beim Abnahmetest (auch Abnahmevorgang oder kurz Abnahme) werden die Tests aus dem Systemtest verwendet und weitere Tests zur Validierung hinzugefügt, umso eine Gesamtabnahme durchzuführen. In der Regel werden auch noch weitere Artefakte bei der Abnahme überprüft, so beispielsweise Handbücher oder Qualitätsprotokolle (wie aus der → FMEA)
Abbildung 2.1: Das V‑Modell im Software Engineering
Anmerkungen:
- In Abbildung 2.1 ist eine zeitliche Reihenfolge eingezeichnet. Dies ist aber nicht als Vorgabe zu verstehen: Rücksprünge sind in diesem V‑Modell erlaubt
- Statt Entwurf werden auch die Begriffe Design oder Spezifikation verwendet: Alle drei Begriffe sind (in diesem Kontext) synonym einsetzbar, wobei Spezifikation vermieden werden sollte, um Missverständnisse zu vermeiden
- Die in das V eingezeichneten Pfeile repräsentieren auch die → Traces: Die durchgezogenen Pfeilen sind vertikale, die gepunkteten Pfeile horizontale Traces
- Das Testen / der → Softwaretest wird unterteilt in Validieren und → Verifizieren
2.2 Requirements Engineering
Das V‑Modell kann auch nur für die Requirements eingesetzt werden. Dabei werden im linken Zweig die Verfeinerungsstufen der Anforderungen und im rechten Zweig die Software- oder Systementwürfe aufgezeichnet (Abbildung 2.2). Als Basis dienen die drei → Anforderungstypen “Business Requirements”, “→ Stakeholder Requirements” und “Solution Requirements” (siehe hierzu “→ Die Klassifikation von Anforderungen”), die um “System Requirements” — die technische Implementierungen beschreiben — ergänzt werden.
Abbildung 2.2: Ein V‑Modell für das Requirements Engineering
Anmerkung:
Ein V‑Modell nur für das Requirements Engineering ist in der Praxis selten zu finden, da im Allgemeinen nicht der Übergang von den Requirements zum Entwurf im Vordergrund steht, sondern das Abgleichen von schriftlich fixierten Anforderungen und (in Lösungen) umgesetzten Anforderungen.
2.3 Systems Engineering
Das Systems Engineering bedient sich generell des V‑Modells. In der minimalen Fassung nach /GfSE19/ werden dabei drei Komponenten betrachtet (Abbildung 2.3):
- Zielklärung: Es muss ein Ziel (für das zu entwickelnde System) beschrieben werden
- Lösungssuche: Es werden Lösungen zur Erreichung des Ziels gesucht und beschrieben
- Bewertung: Die Lösungen werden bewertet
Die drei Komponenten werden mehrfach hintereinander / “→ iterativ” betrachtet / durchlaufen, solange bis eine abschließende Bewertung durchgeführt wird.
Abbildung 2.3: Das V‑Modell im Systems Engineering (minimal, nach /GfSE19/)
Auf Basis diese V‑Modells können Verfeinerungen / Zergliederungen der drei Komponenten vorgenommen werden, die je nach Themenschwerpunkt unterschiedlich ausfallen können.
2.4 Automotive Spice
Im Automotive-Spice-Kontext wird das V‑Modell “doppelt” eingesetzt (Abbildung 2.4): Das erste V wird für das System generell (blaue Rechtecke, oberer Bereich), das zweite V für das Software Engineering (orange Rechtecke, unterer Bereich) verwendet.
Abbildung 2.4: Das V‑Modell im Automotive Spice
Die Kopplung der beiden Bestandteile System und Software Engineering ist in Abbildung 2.5 wiedergegeben.
Abbildung 2.5: Die Kopplung der V‑Modelle im Automotive Spice
2.5 Mechatronische Systeme
Beim VDI (Verein deutscher Ingenieure) wird ein V‑Modell zur Beschreibung der Entwicklung von mechatronischen Systemen als → Richtlinie definiert, welches die “Entwicklung mechatronischer und cyber-physischen Systemen” umfasst /#V‑Modell-VDI-2206/.
3. Varianten und Ergänzungen des V‑Modells
Es gibt eine Reihe von Varianten und Ergänzungen des V‑Modells. Dabei werden weitere Elemente zur Ergänzung der grafischen Darstellung hinzugefügt, um bestimmte Sachverhalte zu verdeutlichen. Typische Varianten sind in Abbildung 3.1 dargestellt.
Abbildung 3.1: Varianten und Ergänzungen des V‑Modells
3.1 Ergänzung um Tätigkeiten und Rollen
In Abbildung 3.2 sind den einzelnen Prozessschritten (generelle) Tätigkeiten im Software Engineering (obere Reihe) zugeordnet und farblich hervorgehoben. Es werden hierbei die fünf Tätigkeiten / übergeordneten Prozessschritte …
- Analyse,
- Design,
- Implementierung,
- Test und
- Abnahme
verwendet und so unterteilt, dass sich ein V‑Modell mit neun Einzeltätigkeiten ergibt.
Abbildung 3.2: Das V‑Modell im Software Engineering mit Zuordnung von Tätigkeiten
Anmerkung:
Statt Abnahme wird häufig der Begriff Betrieb verwendet (siehe auch Abbildung 1.1). Inhaltlich ist es aber das gleiche: Dieser Prozessschritt kennzeichnet den Übergang von der Entwicklung in den Betrieb.
Durch Zuordnung von Rollen zu den einzelnen Tätigkeiten entsteht ein Gesamteindruck eines Softwareentwicklungsvorhabens (Abbildung 3.3).
Abbildung 3.3: Das V‑Modell im Software Engineering mit Zuordnung von Tätigkeiten und Rollen
Wenn man den Rollen aus Abbildung 3.3 noch → Aufwände und → Dauern zuordnet, so kann man die Anzahl der benötigten Mitarbeiter (FTE — Full Time Equivalent) in einem → Vorhaben bestimmen (Abbildung 3.4).
Abbildung 3.4: Das V‑Modell im Software Engineering mit Tätigkeiten, Rollen und Aufwänden
3.2 Ergänzung um Einzeltätigkeiten
Möchte man einzelne Tätigkeiten erfassen, die zur Unterstützung des Vorgehens entlang eines V‑Modells durchgeführt werden sollen, so können diese in der V‑Modell-Darstellung hinzugefügt werden.
In Abbildung 3.5 sind beispielhaft ergänzende Tätigkeiten (aquamarine Rechtecke) dargestellt, die bei der Umsetzung eines Softwareentwicklungsvorhabens mit dem V‑Modell hilfreich sind.
Abbildung 3.5: Das V‑Modell im Software Engineering mit ergänzenden Tätigkeiten
In Abbildung 3.6 sind die beiden grundsätzlichen Tätigkeiten mit ihren (vertikalen) Wirkrichtungen dargestellt:
- Zerlegen und spezifizieren
- Realisieren und integrieren
Abbildung 3.6: Das V‑Modell mit Wirkrichtungen und Tätigkeiten
Die gestrichelten Pfeile deuten die möglichen Rücksprünge zwischen den Prozessschritten an: Das V‑Modell muss keinesfalls linear durchlaufen werden, sondern erlaubt ein Zurückspringen.
3.3 Ergänzung um Dokumente und Artefakte
Zur Verdeutlichung, welche Dokumente beim Durchlaufen des V‑Modells entstehen sollen, können der Darstellung einzelne Dokumente und Artefakte grafisch hinzugefügt werden.
In Abbildung 3.7 sind beispielhaft Dokumente (grüne Rechtecke mit Wellenkante) dargestellt, die sich bei der Umsetzung eines Softwareentwicklungsvorhabens mit dem V‑Modell ergeben könnten.
Abbildung 3.7: Das V‑Modell im Software Engineering mit ergänzenden Dokumenten
4. Stärken und Schwächen des Einsatzes eines V‑Modells
Als generelle Stärken und Schwächen des Einsatzes eines V‑Modells können genannt werden:
Stärken:
- Das V‑Modell kann — nach entsprechender Erläuterung — schnell zur Klärung von Abläufen herangezogen werden
- Das V‑Modell ist vielen Personen bekannt
- Das V‑Modell ist in einigen Normen und Standards verankert
- In regulatorischen Umfeldern (wie der Medizintechnik oder im Automotive-Kontext) kann das V‑Modell zur Qualitätssicherung herangezogen werden
- Das V‑Modell ergänzt gut die “klassischen” Produktentstehungsprozesse (PEPs), die häufig im Maschinenbau anzutreffen sind
- Die FMEA passt gut zum V‑Modell: Beide Ansätze betrachten Systeme → Top-down und haben die → Qualität im Fokus
Schwächen:
- Das V‑Modell unterteilt → relativ starr ein Vorgehen in einzelne Blöcke
- Das V‑Modell wird von vielen Personen abgelehnt, da es als “Einstieg in die Bürokratie” gesehen wird
- Wenn das V‑Modell nur als rein theoretische Betrachtung gesehen wird, verfehlt es seine Wirkung
5. Häufig gestellte Fragen und Antworten (FAQ) zum V‑Modell
Einige Fragen zum V‑Modell werden häufig gestellt – diese werden hier wiedergegeben.
- F: Müssen Lizenzgebühren für die Verwendung des V‑Modells gezahlt werden?
A: Nein. Die Nutzung des V‑Modells ist kostenfrei — insbesondere, da es kein allgemeines V‑Modell gibt. - F: Ist das V‑Modell noch “zeitgemäß” und hat noch eine Relevanz?
A: Ja. Gerade vor dem Hintergrund der → Digitalisierung und der Verbindung von Hard- und Software beim Internet of Things (IOT) kann das V‑Modell helfen, die Abläufe, Schnittstellen und Verantwortlichkeiten zu erkennen und auszugestalten. - F: Ist das V‑Modell auch international bekannt (und einsetzbar)?
A: Ja und nein. Das V‑Modell ist im deutschsprachigen Raum verbreitet und wird bei vielen Engineering-Firmen eingesetzt. International sieht das durchaus anders aus: Dort ist im Automotive-Umfeld das V‑Modell nach Automotive Spice bekannt, darüber hinaus findet das V‑Modell eher selten Anwendung. - F: Muss man bei agiler Vorgehensweise (Agiles RE) das V‑Modell berücksichtigen?
A: Es kommt darauf an. Um hohe Qualität bei der Umsetzung eines Systems nachzuweisen, kommt man kaum am V‑Modell vorbei.
Haben Sie noch weitere Fragen oder möchten Sie Ergänzungen an der FAQ vornehmen? Am besten schreiben Sie mir hierzu eine E‑Mail an: kontakt@peterjohann-consulting.de.
A. Präsentationen, Literatur und Weblinks
Das V‑Modell ist eine Grundlage für das Requirements Engineering, welches in der hier aufgeführten Präsentation beschrieben wird.
| Inhalt | Typ |
|---|---|
| Requirements Engineering (und Business Analysis) – Eine Einführung (RE-Basispräsentation) | 
|
In folgenden Büchern wird als Teilaspekt das V‑Modell erläutert:
- /Ebert19/ Christof Ebert: Systematisches Requirements Engineering. Anforderungen ermitteln, dokumentieren, analysieren und verwalten, dpunkt, Heidelberg 6. Auflage 2019, ISBN 978–3‑86490–562‑9
- /Ebert22/ Christof Ebert: Systematisches Requirements Engineering. Anforderungen ermitteln, dokumentieren, analysieren und verwalten, dpunkt, Heidelberg 7. Auflage 2022, ISBN 978–3‑86490–919‑1
- /GfSE19/ siehe /Zuccaro19/
- /Kuhrmann11/ Marco Kuhrmann, Thomas Ternité, Jan Friedrich: Das V‑Modell XT anpassen: Anpassung und Einführung kompakt für V‑Modell XT Prozessingenieure, Springer, Berlin 2011, ISBN 978–3‑642–01489‑5
- /Pfeifer21/ Tilo Pfeifer, Robert Schmitt: Masing Handbuch → Qualitätsmanagement, Hanser, München 7. Auflage 2021, ISBN 978–3‑446–46230‑4
- /Zuccaro19/ Claudio Zuccaro, Jürgen Rambo, Hannes Hüffer, Johannes Fritz, Thaddäus Dorsch: GfSE SE-Handbuch. Die Klammer in der technischen Entwicklung, GfSE – Gesellschaft Für Systems Engineering, Bremen 2017, ISBN 978–3‑9818805–6‑4
Auf folgende Weblinks zum V‑Modell wird in diesem Beitrag Bezug genommen:
- /#V‑Modell-Geschichte-Kneuper-18/ “Die geschichtliche Entwicklung des V‑Modells”, Beitrag von Ralf Kneuper aus dem Jahr 2018 (deutsch, pdf-Datei, 11 Seiten)
- /#V‑Modell-VDI-2206/ VDI/VDE 2206 “Entwicklung mechatronischer und cyber-physischer Systeme”, Richtlinie, Modellfassung aus dem Jahr 2021
- /#V‑Modell-XT/ Das V‑Modell-XT, Version 2.3 aus dem Jahr 2019 (deutsch, pdf-Datei, 439 Seiten)
- /#Wiki-V-Modell/ V‑Modell (engl. V‑Model) in der deutschen Wikipedia
Legende zu den Weblinks
/ / Verweis auf eine Website (allgemein)
/*/ Verweis auf eine Website, die als Ergänzung zu einem Buch dient
/#/ Verweis auf ein einzelnes Thema auf einer Website
/#V/ Verweis auf ein Video auf einer Website
Letzte Aktualisierung: 28.12.2022 © Peterjohann Consulting, 2005–2024
