Das V-Modell erklärt

In der Softwareentwicklung gibt es viele Prozesse, die die Entwicklung erleichtern sollen, egal ob agil oder traditionell. Einer der bekanntesten ist das V-Modell. Was es genau beinhaltet, wie es sich grob vom Wasserfallmodell unterscheidet und wann es sich lohnt, es anzuwenden, erfahren Sie im Folgenden.

Das V-Modell ist ein Vorgehensmodell in der Softwareentwicklung, das einen linearen Projektablauf abbildet. Es unterteilt den gesamten Projektablauf in Phasen, die von Anfang an fest definiert sind. Gegenüber dem Wasserfallmodell, das ebenfalls ein lineares Modell ist, hat das V-Modell zusätzlich Testphasen, die den Entwicklungsphasen gegenüberstehen. 
Das V-Modell arbeitet also mit festen Projektphasen, die durch Testphasen ergänzt werden. In der Praxis bedeutet dies, dass bei der Softwareentwicklung nicht nur die Systemarchitektur und die Spezifikationen der Komponenten erstellt werden, sondern gleichzeitig auch die Testphasen. So wird sichergestellt, dass die Komponenten und das Gesamtsystem gründlich getestet werden und alles reibungslos funktioniert. 
Das V-Modell ist keine neue Erfindung, sondern wurde bereits 1979 von dem US-Amerikaner Barry Boehm entwickelt. Boehm veranschaulichte sein V-Modell mit einer V-förmigen Grafik. Auf der linken Seite des V stehen die Anforderungen an das Projekt. Diese werden Schritt für Schritt detaillierter, bis sie schließlich auf der untersten Ebene mit ihrer technischen Umsetzung klar definiert sind. Die Spitze des V stellt die Umsetzung dar. Dies ist die eigentliche Produktentwicklung, die Programmierung, in der das Produkt entsteht. Auf der rechten Seite des Vs befinden sich die einzelnen Funktionen und wie diese getestet werden sollen. Diese fließen immer mehr zusammen, bis in einem letzten Schritt das Gesamtsystem getestet wird.

Seit 1979 sind Jahrzehnte vergangen und viele Fachleute haben sich mit dem V-Modell beschäftigt. Seitdem wurden verschiedene Typen oder Varianten der Methode beschrieben, analysiert und erprobt. Sie lassen sich nicht vollständig voneinander trennen, es gibt auch Mischtypen. 
Das allgemeine V-Modell ist eine Ableitung des Wasserfallmodells und beschreibt ein allgemeines Vorgehen bei der Softwareentwicklung. 
Eine Variante des amerikanischen Modells wurde in Deutschland patentiert und als V-Modell® der Bundesrepublik Deutschland für staatliche Projekte eingesetzt, weshalb viele öffentliche IT-Projekte nach diesem Modell entwickelt wurden. Seit 2005 wird diese Methode standardmäßig in öffentlichen Ausschreibungen gefordert.

Das V-Modell lässt sich grundsätzlich in drei Phasen unterteilen. In der Entwurfsphase werden die Anforderungen aufgenommen und in einen Systementwurf überführt. Diese Anforderungen werden nach dem Top-Down-Prinzip immer spezifischer und stellen die linke Seite des V-Modells dar. In der zweiten Phase, der Implementierungsphase, wird das Produkt entwickelt. Es folgt die Validierungsphase, in der nach dem Bottom-up-Prinzip vorgegangen und getestet wird. Dies ist die rechte Seite des V. Man beginnt mit den Tests auf Komponentenebene und arbeitet sich bis zu den Tests auf Systemebene vor. Diese Phase und das gesamte Projekt enden mit der Produktabnahme.
 
Die Entwurfsphase

Die Entwurfsphase umfasst mehrere Ebenen. Diese Ebenen sind voneinander abhängig, d. h. wenn in einer höheren Ebene eine Änderung vorgenommen wird, ändert sich auch etwas in den darunter liegenden Ebenen. 
Ein wichtiger Schritt in der Entwurfsphase ist die Analyse der Anforderungen. Bevor mit der Arbeit begonnen werden kann, müssen alle Anforderungen genau untersucht und klar definiert werden. Dadurch wird festgelegt, was das Endprodukt können muss.
Im Schritt des Systementwurfs wird geklärt, ob es überhaupt möglich ist, alle diese Anforderungen umzusetzen. Es wird ein Design für das gesamte System entwickelt und je nach Art des Projekts auch schon mögliche grafische Designs. Dazu gehört auch die Architektur, in der das System in einzelne Komponenten zerlegt wird. Dies beinhaltet auch die Definition der Schnittstellen und deren Abhängigkeiten. 
Die Entwurfsphase endet mit der Spezifikation der Komponenten. Dies ist die unterste Ebene, auf der festgelegt wird, wie die Funktionen in Ihrem Produkt umgesetzt werden.
 
Die Implementierungsphase

In der Implementierungsphase wird das Produkt programmiert und die Software erstellt. Das V-Modell macht keine Vorgaben oder Vorschläge, wie diese eigentliche Phase der Softwareentwicklung ablaufen soll. 
 
Die Validierungsphase

Wir befinden uns jetzt auf der rechten Seite des Vs. Die Tests, die auf dieser Seite zu finden sind, entsprechen immer der Ebene auf der linken Seite des Vs. In der Grafik stehen sie sich also gegenüber. 
Auf der kleinsten Ebene findet der Komponententest statt. Hier werden die einzelnen Komponenten und Merkmale betrachtet und festgestellt, inwieweit sie so umgesetzt wurden, wie sie in den Anforderungen zu finden sind. Es ist wichtig, nur diese zu betrachten und nicht auch die Abhängigkeiten. Denn in beiden kann ein Fehler auftreten, aber die Abhängigkeiten sollen hier noch nicht überprüft werden.
Danach folgt der Integrationstest. Hier wird überprüft, ob die Module zusammenarbeiten und ob der Datenaustausch zwischen den Komponenten reibungslos funktioniert. 
Danach kommt der Systemtest. Spätestens hier wird auch der Kunde mit an den Tisch geholt und es gibt mehrere Testläufe des Gesamtsystems. Dies hat zum einen den Hintergrund, dass noch einmal alle Funktionalitäten getestet werden sollen, zum anderen kann der Kunde aber auch testen, inwieweit das System für ihn nutzbar ist.
Diese Phase wird als Abnahme bezeichnet, wobei ein abschließender Test unter realen Bedingungen stattfinden sollte, d. h. in der Umgebung, in der die Software später auch eingesetzt werden soll. Zum Test sollten Benutzer eingeladen werden, um ein möglichst realistisches Testergebnis zu erhalten. 
Mit der letzten Phase gilt der Test als abgeschlossen und die Softwareentwicklung nach dem V-Modell als beendet, da das Produkt genau so funktioniert, wie es in der Entwurfsphase vereinbart wurde.

Wie alle Projektmanagementmethoden hat auch das V-Modell Stärken und Schwächen und ist für manche Projekte besser geeignet als für andere. Zu den Vorteilen gehört, dass die Tests sehr früh konzipiert werden, wodurch unvollständige Spezifikationen leichter erkannt werden können. Auch die einfache Struktur der Methode erweist sich als vorteilhaft, da keine langwierigen und komplizierten Schulungen erforderlich sind, um den Mitarbeitenden zu erklären, wie sie vorgehen sollen. Ein weiterer Vorteil kann darin bestehen, dass der Kunde in der eigentlichen Entwicklungsphase nicht anwesend ist. Dadurch hat das Entwicklungsteam viele Freiheiten und kann ungestört arbeiten. Dies hängt auch damit zusammen, dass bereits zu Beginn die Spezifikationen mit den entsprechenden Tests festgelegt werden. Positiv ist auch die frühe Einbindung der Tester, die so mögliche Probleme aufdecken können und generell die hohe Anzahl an Tests, was zu einer erhöhten Sicherheit führt.
Die Nachteile werden meist von den Vertretern der "neuen", agilen Methoden bzw. Frameworks angeführt, schließlich ist das Modell schon über 40 Jahre alt. Das lineare Vorgehen wird von vielen generell als veraltet angesehen, was aber nicht bedeutet, dass es heutzutage nirgendwo mehr angewendet wird. 
Die Tatsache, dass das V-Modell recht einfach ist, wird von Kritikern als Beleg dafür angeführt, dass die Methode zu simpel sei und Entscheider in falscher Sicherheit wiege. Außerdem ist es weniger flexibel als agile Ansätze, bei welchen iterativ vorgegangen wird.

Das V-Modell hat sicher seine Daseinsberechtigung, vor allem wegen der Sicherheit, die es schafft. Immerhin werden durch die vielen Tests Probleme aufgedeckt, die so vielleicht erst am Ende aufgefallen wären. Dennoch ist dieser lineare Prozess in der heutigen Softwareentwicklung, in der agile Ansätze immer mehr an Bedeutung gewinnen, nicht ideal. Dies liegt unter anderem daran, dass Projekte nicht zeitnah angepasst werden können.
Daher sollte vor Projektbeginn sorgfältig abgewogen werden, ob diese Methode die richtige ist. Sie eignet sich gut für Projekte mit hierarchischen Komponenten und geringer Komplexität.