V-Modell
Inhaltsverzeichnis: Definition – Bestandteile und Phasen – Vorteile und Nachteile – Fragen aus der Praxis – Hinweise
Wissen kompakt: Das V-Modell ist ein Vorgehensmodell für IT-Entwicklungsprojekte, das Definitions- und Entwurfsphasen entsprechende Testphasen gegenüberstellt.
V-Modell – ein Vorgehensmodell für IT-Entwicklungsprojekte
Das V-Modell ist ein Vorgehensmodell für IT-Entwicklungsprojekte, wobei das “V” nicht für Vorgehen steht, sondern sich aus der V-förmigen Visualisierung abgeleitet, die Definitions- und Entwurfsphasen entsprechende Testphasen gegenüberstellt.
Das Vorgehensmodell wurde erstmals 1979 von Barry W. Boehm, einem US-amerikanischen Software Engineer mit einem Fokus auf die Validierung1 und die Verifizierung2 der Ergebnisse beschrieben.3
Das Besondere am V-Modell ist, dass es sowohl die funktionale als auch die technische Entwicklung betrachtet und Qualitätssicherungsmaßnahmen definiert. Diese Maßnahmen ergänzen die Phasen zur Definition und Entwicklung eines Produkts um entsprechende Testphasen, sodass sowohl einzelne Komponenten als auch das Gesamtsystem ordnungsgemäß getestet werden kann.
Bestandteile und Phasen im V-Modell
Das V-Modell lässt sich in verschiedenen Bereichen und in unterschiedlichen Ausprägungen darstellen und anwenden. Die gängigste Verwendung findet im Software Engineering statt4 und gliedert sich in drei Bestandteile:
- Die linke Seite des “V” beschäftigt sich mit der Definition von Anforderungen und dem Entwurf eines Systems, der mittels Top-Down-Prinzip kontinuierlich weiterentwickelt wird.
- Die Implementierung am Fuße des “V”.
- Die rechte Seite des “V” validiert und verifiziert die linke Seite. Hier werden von der Komponenten- bis zur Systemebene Tests nach dem Bottom-Up-Prinzip durchgeführt, bis das Produkt schließlich als Ganzes abgenommen wird.
Das V-Modell lässt sich in folgende Phasen gliedern:
- die Anforderungsdefinition, in der Nutzungsanforderungen bzw. Stakeholder-Anforderungen beschrieben werden,
- die Systemspezifikation als funktionaler Systementwurf mit der Definition von Systemanforderungen, dokumentiert bspw. als Systems Requirements Specification,
- die Systemarchitektur als technischer Systementwurf zur Umsetzung der Systemanforderungen
- und die Komponentenspezifikation.
- Danach folgt die Implementierung, sowie
- der Komponententest (gegenüber von der Komponentenspezifikation),
- der Integrationstest (gegenüber vom Architekturentwurf bzw. dem technischen Systementwurf),
- der Systemtest (gegenüber der Systemspezifikation bzw. dem funktionalen Systementwurf)
- und der Abnahmetest bzw. Akzeptanztest (gegenüber der Anforderungsdefinition).
Vorteile und Nachteile des V-Modells
Das V-Modell bietet eine Reihe von Vorteilen:
- Als Vorgehensmodell beschreibt es eine klare Struktur für den Entwicklungsprozess, bei dem die Entwurfsphasen mit den entsprechenden Testphasen verbunden werden. Dies erleichtert eine systematische Planung und Durchführung von Projekten.
- Durch die enge Verknüpfung von Entwicklungs- und Testaktivitäten können Fehler frühzeitig erkannt werden. Dies trägt dazu bei, die Kosten und den Aufwand für die Fehlerbehebung in späteren Phasen zu reduzieren.
- Das Vorgehensmodell legt Wert auf eine gründliche Anforderungsanalyse zu Beginn des Projekts. Dadurch werden die Anforderungen klar definiert und Missverständnisse vermieden, was zu einem verbesserten Endprodukt führt.
- Da das Vorgehensmodell eine detaillierte Dokumentation der Entwicklungs- und Testaktivitäten vorsieht, ist es leicht nachvollziehbar, welche Schritte durchgeführt und welche Ergebnisse erzielt wurden. Dies kann bei der Qualitätssicherung und der Erfüllung von regulatorischen Anforderungen hilfreich sein.
- Das phasenbasierte Vorgehen ist relativ bekannt, leicht zu verstehen und insbesondere in regulatorischen Bereichen wie bspw. der Medizintechnik, der Rüstungsindustrie oder in der Automobilbranche verbreitet. Es fördert eine systematische und strukturierte Vorgehensweise bei der Entwicklung von Systemen oder Softwareprodukten.
Trotz dieser Vorteile gibt es auch einige Nachteile:
- Aufgrund seiner festen Struktur und strengen Phasenabläufe gilt es bisweilen als starr werden. Dies kann ggf. zu Problemen führen, wenn Änderungen während des Projekts erforderlich sind oder wenn agile Ansätze bevorzugt werden.
- Das Vorgehen erfordert eine relativ umfangreiche Dokumentation während des gesamten Entwicklungsprozesses. Dies kann zu einem erhöhten administrativen Aufwand führen, der Ressourcen binden und die Flexibilität beeinträchtigen kann.
- Aufgrund der sequenziellen Natur des Vorgehensmodells können die Entwicklungszyklen länger sein, insbesondere wenn umfangreiche Tests und Überprüfungen in jeder Phase durchgeführt werden müssen.
- Das Vorgehen ist möglicherweise überdimensioniert und zu komplex für kleine Projekte oder Teams mit begrenzten Ressourcen. In solchen Fällen kann eine flexiblere und weniger formalisierte Vorgehensweise angemessener sein.
- Und es suggeriert einen rein sequenziellen Ablauf, der aber in der Praxis so häufig nicht gegeben ist und auch nicht gegeben sein muss.
Fragen aus der Praxis
Hier finden Sie einige Fragen und Antworten aus der Praxis:
Welche Varianten des V-Modells gibt es?
Es gibt eine ganze Reihe von Varianten des V-Modells:
- Das V-Modell 97 war ein Standard für die Entwicklung von IT-Systemen der Bundeswehr und der deutschen Bundesverwaltung und wurde 1997 veröffentlicht. Es war eine Revision der ersten Veröffentlichung im Jahre 1992 und bestand aus einem Regelungsteil, einem Teil für behördenspezifischen Ergänzungen, einer Handbuchsammlung, einer Methodenzuordnung und Werkzeuganforderungen.
- Das V-Modell XT gilt als Revision des V-Modell 97 und löste dieses im Jahr 2004 ab. Es ist ein deutscher Standard für die Planung und Durchführung von Systementwicklungsprojekten und richtet sich sowohl an Auftraggeber als auch an Auftragnehmer. Inhaltlich unterscheidet es sich stark von seinem Vorgänger und führt mit u. a. mit einem “extreme Tailoring”, Projekttypen, Projekttypvarianten, Produkten und Aktivitäten, Vorgehensbausteinen, Projektdurchführungsstrategien und Entscheidungspunkten neuartige Grundkonzepte ein.
- Das V-Modell XT Bund erweitert das V-Modell XT für Behörden und legt seinen Fokus auf die Durchführung von Auftraggeber-Projekten und die Eigenentwicklung von Softwaresystemen.
- Das V-Modell XT Bayern ist ein Vorgehensmodell für bayerische Behörden und unterstützt Auftraggeberprojekte im Bereich der Softwareentwicklung und -anpassung.
- Das V-Modell XT Bw erweitert das V-Modell XT für die Bundeswehr und integiert Verfahrensbestimmungen für die Bedarfsermittlung, Bedarfsdeckung und Nutzung.
- Im Automobilsektor gibt es mit ASPICE bzw. Automotive SPICE eine weitere Variante. SPICE steht für Software Process Improvement and Capability dEtermination und wird zur Bewertung von Reifegraddimensionen der Entwicklungsprozesse für Elektronik- und Softwarebasierten-Systeme angewendet.
Ist das V-Modell eine Marke und fallen Lizenzgebühren an?
Die Bundesrepublik Deutschland hat sich frühzeitig mit der Standardisierung des V-Modells beschäftigt und das V-Modell® als geschützte Marke eingetragen. Weder bei der Verwendung der heute aktuelle Variante V-Modell XT noch bei der Anwendung des “allgemeinen” V-Modells fallen Lizenzgebühren an.
Was ist der Unterschied zwischen V-Modell und Wasserfallmodell?
Das Wasserfallmodell ist ein lineares Planungsmodell aus dem traditionellen Projektmanagement. Ein Projekt wird dabei in mehrere Phasen unterteilt, die sequenziell aufeinander folgen: Analyse -> Design -> Implementierung -> Test -> Betrieb. Seinen Namen hat das Modell von der grafischen Darstellung, bei der die Phasen – ähnlich wie bei einem Wasserfall – von oben nach unten “fließen” bzw. dargstellt werden. Es eignet sich gut für Projekte, bei denen die Anforderungen bereits zu Projektbeginn klar sind und es wenige Änderungen gibt. Gerne wird behauptet, dass es keine Rückkoppelung zwischen den Phasen gäbe, das stimmt aber nicht. Natürlich lassen sich auch Änderungen im Zuge des Wasserfallmodells managen, lediglich die Abarbeitung sprich die entsprechenden Aktivitäten erfolgen linear.
Im Gegensatz zum Wasserfallmodell zeichnet sich das V-Modell dadurch aus, dass die Verifizierung und Validierung bereits während der Analyse und des Designs spezifiziert werden. In den Testphasen prüfen die Tester gegen die Spezifikationen aus den Analyse- und Designphasen. Damit ergibt sich auch, dass das V-Modell mehr als nur ein “hochgeklapptes Wasserfallmodell” ist.
Warum wird das V-Modell auch als "umgeklapptes Wasserfallmodell" bezeichnet?
Das V-Modell wird oft als “umgeklapptes Wasserfallmodell” bezeichnet, weil es einige Ähnlichkeiten mit dem Wasserfallmodell aufweist, jedoch einige Phasen “umzeichnet” und Elemente auf derselben horizontalen Ebene anordnet. Da jedoch die Verifizierung und Validierung bereits während der Anforderungsdefinition, dem Systementwurf, dem Architekturentwurf und dem Komponentenentwurf spezifiziert werden, wird die Bezeichung der Realität nicht gerecht. Das V-Modell ist kein Wasserfallmodell, sondern beschreibt inhaltlich ein anderes Vorgehen.
Welche Rollen kommen typischerweise in einem V-Modell-Projekt zum Einsatz?
- In der Phase der Anforderungsdefinition und beim funktionalen Systementwurf bzw. der Systemspezifikation kommt ein Anforderungsanalyst oder ein Requirements Engineer zum Einsatz.
- Beim technischen Systementwurf bzw. dem Architekturentwurf ist die Rolle des Softwarearchitekten gefragt.
- Bei der Implementierung dürfen Softwareentwickler bzw. Programmier in die Tasten hauen.
- Die Meinungen variieren, ob es sinnvoll ist, separate Softwaretester für die Komponenten-, Integrations- und Systemtests zu nutzen oder ob es nicht besser ist, wenn Softwareentwickler diese Aufgaben in Personalunion übernehmen.
- Den Abnahmetest sollte dann aber eine “entwicklungsexterne” Person, ein “Abnahmetester” oder ein Stakeholder durchführen.
Darüber hinaus sind auch viele weitere Rollen denkbar. Das V-Modell XT liefert bspw. eine umfassende Liste an Rollen, wobei eine Person durchaus verschiedene Rollen übernehmen kann, sofern sie sich inhaltlich nicht widersprechen.
Wie relevant ist das V-Modell heutzutage?
Die Relevanz des V-Modells hängt stark von den spezifischen Anforderungen, Präferenzen und Kontexten der jeweiligen Organisationen und Projekte ab.
In einigen Branchen, insbesondere in sicherheitskritischen Bereichen wie der Luft- und Raumfahrt, dem Gesundheitswesen und der Automobilindustrie, ist es weiterhin relevant und wird sogar oft als Standardvorgehensmodell verwendet, um die Einhaltung von Qualitäts- und Sicherheitsstandards sicherzustellen.
Dazu bevorzugen manche Organisationen traditionelle, plangetriebene Ansätze für die Softwareentwicklung und setzen daher weiterhin auf das V-Modell als Rahmenwerk für ihre Projekte.
Mit dem Aufkommen agiler Entwicklungsmethoden wie Scrum und Kanban sowie der zunehmenden Betonung von DevOps und Continuous Integration/Continuous Deployment (CI/CD) haben sich die Praktiken und Ansätze in der Softwareentwicklung geändert. In agilen Umgebungen kann das V-Modell als zu schwerfällig und bürokratisch empfunden werden, was seine Anwendbarkeit in solchen Kontexten einschränken kann.
Kurzum: Während das V-Modell in einigen Bereichen nach wie vor verbreitet ist, haben sich in anderen Bereichen agile (oder hybride) Ansätze als beliebter erwiesen.
Vereinfacht die Visualisierung des Vorgehensmodell die Realität der Systementwicklung so stark, dass sich Anwender in falscher Sicherheit wiegen könnten?
Hinweise:
Haben Sie Lust auf einen neuen Lieblings-Newsletter?
Die Inhalte auf dieser Seite dürfen Sie gerne teilen oder verlinken.
[1] Definition von Validierung laut ISO 9000: “Bestätigung durch objektiven Nachweis, dass die Anforderungen für eine bestimmte Anwendung oder einen bestimmten Gebrauch erfüllt sind.”
Die Validierung überprüft also, ob das Produkt den Bedürfnissen der Nutzer entspricht. Dabei wird geprüft, ob die Anforderungen mit den Zielen der Stakeholder übereinstimmen. Im V-Model erfolgt die Validierung z. B. mittels Abnahmetest.
[2] Definition von Verifizierung laut ISO9000: “Bestätigung durch einen objektiven Nachweis, dass Anforderungen erfüllt werden.”
Die Verifikation stellt sicher, dass das Ergebnis einer Entwicklung den vorgegebenen Spezifikationen entspricht. Im V-Modell erfolgt die Verifizierung durch Komponenten-, Integrations und Systemtests. Allerdings lässt sich durch diese Tests nicht beweisen, dass das betrachtete Produkt fehlerfrei ist. Das Prüfen von Falschem macht Falsches nicht richtig.
[3] Barry W. Boehm: Guidelines for Verifying and Validating Software Requirements and Design Specifiations
[4] Neben dem Einsatz im Bereich des System Engineerings kann das V-Modell bspw. im Requirements Engineering eingesetzt werden. Dort stehen sich bspw. Business Requirements und Business Cases, Stakeholder Requirements und Systementwurf, Solution Requirements und Architekturentwurf sowie System Requirements und Komponentenentwurf gegenüber. Auch ein Einsatz im Kontext von Automotive SPICE ist möglich.
Hier finden Sie ein Erklärungsvideo zum V-Modell.
Hier finden Sie eine ausführliche Beschreibung der geschichtlichen Entwicklung des Vorgehensmodells.
Und hier finden Sie ergänzende Informationen aus dem t2informatik Blog:
Managen Sie noch Prozesse?
Der beste Prozess im Anforderungsmanagement
IT-Analyse als kreativer Prozess