Author
Das V-Modell ist ein Vorgehensmodell zur Softwareentwicklung und -prüfung, das oft als Variante zum traditionellen Wasserfallmodell betrachtet wird. Im Vergleich zu den Life-Cycle-Phasen des Standard-Wasserfallmodells, die in einem linearen Softwareentwicklungsprozess ineinander übergehen, wird im V-modell die Testphase parallel zu allen Phasen durchgeführt.
Das Wasserfallmodell wurde im Laufe seiner Entwicklung durch eine besser definierte Testphase ergänzt und lässt sich visuell als V-Form anordnen. Das „V“ steht auch für „Verifizierungs- und Validierungsmodell“, womit das Vorgehensmodell ebenfalls beschrieben wird.
Das Buch Developing and Managing Embedded Systems and Products – Methods, Techniques, Tools, Processes, and Teamwork von Kim R. Fowler und Craig L. Silver definiert die Verifizierungs- und Validierungskomponenten des V-models wie folgt:
„Die Verifizierung ist eine objektive Reihe von Tests, die bestätigen soll, dass das Produkt die Anforderungsmetriken erfüllt, während die Validierung bestätigen soll, dass das Produkt die ursprüngliche Absicht erfüllt.“
Können wir Sie bei Ihrem nächsten Entwicklungsprojekt unterstützen?
Softwareentwicklung Unternehmen – nearshore pricing, German HQ and management!
Das V-modell Diagramm
Schematisch fließen die Schritte innerhalb des V-models sowohl in der Verifizierungs- als auch in der Validierungsphase ab der Programmierung aufwärts und bilden ein V.
Die vertikale Achse des V-Modells gibt den Abstand zum fertigen Softwareprodukt im Software Development Life Cycle (SDLC) an. Die Anforderungsdefinition sitzt an der Spitze des V-modells, während die Programmierung die Basis bildet. Die horizontale Achse repräsentiert die Zeitlinie, wobei die Anforderungsdefinition am weitesten von der fertigen Software entfernt ist.
Die horizontalen und vertikalen Achsen repräsentieren die Zeit bzw. den Projektfortschritt (links nach rechts) und die Abstraktionsebene.
Als ein Vorgehensmodell für die Softwareentwicklung sollte das V-modell nicht mit dem Vue v-modell verwechselt werden, bei der es sich um ein Directive des JavaScript Frameworks handelt, die Zwei-Wege-Datenbindung zwischen Eingabe- und Formulardaten oder zwei Komponenten liefert.
Die Hintergrundgeschichte des V-modells
Wie jeder Superheld hat auch jede gute Softwareentwicklungsmethodik oder jedes gute Framework seine eigene Origins-Story. Laut Tim Weilkiens Buch Systems Engineering with SysML/UML aus dem Jahr 2017 wurde das Vorgehensmodell ursprünglich für den deutschen Staat als Methodik zur Planung und Umsetzung von Systementwicklungsprojekten im öffentlichen Sektor entwickelt.
Der deutsche Einfluss zeigt sich im spezifischen Ansatz des V-Modells, der den Software Development Life Cycle ähnlich wie in der Systemtechnik systematisiert. Das zuerst veröffentlichte V-Modell 97 wurde 2004 als V-Modell XT (Extreme Tailoring) aktualisiert, nachdem ein Konsens erzielt wurde, dass die ursprüngliche Methodik nicht mehr für moderne Softwareentwicklungsprojekte geeignet war.
Das aktuelle V-Modell XT aus dem Jahr 2004 basiert auf dem Vorgänger V-Modell 97. Die Überarbeitung des Modells hat stattgefunden, als sich nach 7 Jahren herausstellte, dass das alte V-Modell nicht mehr dem aktuellen Stand der Technik entsprach. Es war nicht mehr geeignet, um die neuesten Techniken und Methoden zu unterstützen.
Das V-Modell XT ist eine Toolbox, die aus definierten Rollen, Produkten und Aktivitäten besteht, die je nach Projekt angepasst werden können. Die Regeln stellen sicher, dass der Ansatz logisch und konsistent bleibt.
Entwicklungs- (Validierung) und Testphase (Verifizierung) des V-Modells
In einem traditionellen Ansatz sind die Phasen des Software Development Life Cycles dieselben wie im Wasserfallmodell:
- Anforderungsdefinition und -spezifikation
- Funktionaler Systementwurf
- Architekturentwurf
- Komponentenentwurf
- Programmierung
Die Kodierung ist das Fundament des V-modells und die letzte Phase des Entwicklungszyklus, bevor die Testphase mit der Komponentenprüfung beginnt.
- Komponententests
- Integrationstests
- Systemtests
- Abnahmetests
V-modell Entwicklungsphasen
Eine kurze Einführung in die vier Phasen bevor und während der Programmierung:
Anforderungsdefinition
Der erste Schritt eines jeden Softwareentwicklungsprojekts, ganz unabhängig von Methodik oder Framework, besteht darin, den Nutzen und die Funktionalität der Software zu ermitteln – oder vereinfacht gesagt, was die Software tun soll. Der Umfang des Programmes wird von allen Stakeholdern, die auf die Nutzung Einfluss haben, festgelegt, einschließlich der Benutzer, der Sponsoren/Eigentümer der App und aller anderen relevanten Parteien.
Techniken können Interviews, Markt- /Benutzerforschung und Analysen sein, wie sich die Software auf Personen, Prozesse, Einnahmen oder Ausgaben innerhalb einer Organisation auswirken könnte.
Die Anforderungen werden anschließend auf Grundlage der gesammelten Informationen definiert und zu einem übergeordneten Anforderungsdokument zusammengestellt, dem das Endprodukt entsprechen muss.
Funktionaler Systementwurf
Die Anforderungsdefinition beeinflusst die Funktionalität des Softwaresystems. Erforderliche Funktionalitäten, die Benutzeroberfläche, über die auf die Funktionen zugegriffen wird, User-Storys, Workflows und Datenstrukturen werden in dieser Phase festgelegt.
Der Systemtestplan und die Dokumentation werden während dieser Phase erstellt, sodass mehr Zeit für die Ausführung in den späteren Phasen bleibt.
Architekturentwurf
Auf den funktionalen Systementwurf folgt der Architekturentwurf. In dieser Phase werden normalerweise eine Reihe potenzieller technischer Ansätze vorgeschlagen und Entscheidungen anhand von technischen und finanziellen Vor- und Nachteilen getroffen.
Ein High-Level-Tech-Stack wurde wahrscheinlich bereits während der Anforderungsdefinition oder dem funktionalen Systementwurf festgelegt, aber Details wie Datenbanktechnologie und Hosting-Spezifikationen (z.B. eine öffentliche, private oder hybride Cloud, die jeweiligen Anbieter, u.v.m.) werden im Architekturentwurf festgelegt.
Diese Informationen ermöglichen auch das Design und die Dokumentation von Integrationstests.
Komponentenentwurf
Die grundlegenden Details der einzelnen Komponenten werden im Komponentenentwurf festgelegt. Alle Funktionalitäten und die Komponenten, aus denen sie bestehen, werden beschrieben, einschließlich Details für die Zusammenwirkung. Backend-Komponenten wie API und Datenbanktabellen werden ebenfalls dokumentiert.
Durch die API-Schnittstellenspezifikation und detaillierte Komponentenbeschreibungen können nun auch Komponententests erstellt werden.
Programmierung
In dieser Hauptphase wird der eigentliche Code geschrieben, aus dem alle Komponentendetails bestehen und der benötigt wird, um alle Funktionalitäten des komplexen Softwaresystems zu realisieren. Front- und Backend-Softwareentwickler verwenden die Codierungssprachen, spezifische Frameworks oder Bibliotheken, die vorab für das Projekt festgelegt wurden.
Alle in den früheren Phasen des Entwicklungsprozesses festgelegten Spezifikationen werden durch Code- und Softwareentwicklungs-Tools zum Leben erweckt.
Testphasen des V-models
Eine kurze Beschreibung der vier Testphasen, die mit den Entwicklungsphasen einhergehen:
Komponententest
Komponententests dienen dazu, die kleinsten Komponenten, aus denen ein funktionierendes Softwaresystem besteht, anhand ihrer festgelegten Merkmale zu überprüfen. Komponenten können je nach Programmiersprache als Module, Units oder Klassen definiert werden. Wenn sie als Unit oder Klasse definiert sind, wird diese Phase als Unit- oder Klassentest und nicht als Komponententest bezeichnet.
Komponententests überprüfen, ob der Output einer Komponente das ist, was von einem bestimmten Input mit den jeweiligen Spezifikationen erwartet wird. Tests müssen einzelne Komponenten isolieren und unabhängig von Abhängigkeiten oder Schnittstellen mit anderen Komponenten verifizieren, um Fehler oder andere Defekte besser lokalisieren zu können.
Komponententests werden normalerweise über automatisiere Selenium Testframeworks wie PyUnit, JUnit, JEST, Jasmine, etc. durchgeführt.
Komponententests können auch verwendet werden, um nicht-funktionale Aspekte wie Architektureffizienz – Speicherverbrauch, Memory-Verbrauch, etc. und Wartungsaspekte einschließlich Codekomplexität und Dokumentationsqualität sowie Funktionalitäten zu überprüfen.
Integrationstests
Nachdem Komponenten getestet und isoliert überprüft wurden, verifizieren Integrationstests die korrekte Funktion und Kommunikation. Diese Phase ist mit dem Architekturentwurf verbunden. Integrationstests werden verwendet, um zu überprüfen, wie Gruppen von Komponenten oder breitere Sub-Systeme innerhalb einer Software zusammenarbeiten.
Integrationstests können anhand der Spezifikation, der Systemarchitektur, der Anwendungsfälle oder der Workflow-Beschreibungen entwickelt werden.
Systemtests
Systemtests werden im funktionalen Systementwurf ausgeführt. Systemtests überprüfen die Funktionalität des gesamten Softwaresystems und seiner Kommunikation mit externen Systemen, wie beispielsweise Browser oder Hardware. Alle Kompatibilitätsprobleme sollten hier entdeckt werden.
Akzeptanztests
Auf der höchsten Abstraktionsebene laufen die Akzeptanztests, die der Anforderungsdefinitionsphase entsprechen. Die Stakeholder, die möglicherweise nicht direkt an den späteren Phasen des Entwicklungsprozesses beteiligt sind, wie beispielsweise Geschäftsführer oder Endnutzer, können hier teilnehmen.
Die Prüfung bezieht sich in der Regel auf die Benutzerumgebung und ist so konzipiert, dass die Software die wichtigsten Geschäftsanforderungen sowie nicht-funktionsfähige Anforderungen wie Ladezeiten, UX-Qualität, etc. erfüllt.
Die meisten Akzeptanztests sind zum großen Teil manuell.
Die Stärken des V-modells
Die Vorteile des V-modells liegen in der einfachen Anwendung und dem Fokus auf Testverfahren im Vergleich zur Standard-Wasserfallmethodik. Lineare Vorgehensmodelle wurden weitgehend durch iterative, flexible Ansätze ersetzt. Es kann jedoch immer noch einen Platz für das V-modell in einfachen Softwareentwicklungsprojekten geben, die in der Regel einen Festpreis und genau definierte Anforderungen haben.
- Ein relativ starres Modell, in dem Phasen linear abgeschlossen werden.
- Funktioniert gut für kleinere Projekte, in denen die Anforderungen klar und gut dokumentiert sind.
- Einfach und leicht zu verstehen und anzuwenden.
- Leicht zu verwalten, da jede Phase klare Ergebnisse und Überprüfungsverfahren hat.
Die Schwächen des V-models
Das V-modell findet in der modernen Softwareentwicklung im Wesentlichen aus den gleichen Gründen wie der Wasserfallansatz immer weniger Anwendung, da es sich hierbei lediglich um eine Weiterentwicklung handelt. Das Vorgehensmodell setzt voraus, dass alle Anforderungen bereits in der konzeptionellen oder vorläufigen Phase des Life Cycles entschieden werden.
Insbesondere für komplexere Softwaresysteme ist dies normalerweise nicht der Fall. Anforderungen, Entwurf und Bewertung verlaufen häufig vor der endgültigen Integration und Annahme über mehrere Iterationen. Für viele Softwareprodukte ist die Iteration von Softwareprodukten ein konstanter Zyklus.
Die jetzigen Gegebenheiten sind der Grund, warum die verschiedenen Frameworks, die unter die agile Softwareentwicklung fallen, jetzt die Softwareentwicklung dominieren.
Die Schwachstellen des V-modells können wie folgt zusammengefasst werden:
- Nicht geeignet für komplexe und objektorientierte Softwareanwendungen.
- Nicht für lange und/oder laufende iterative Softwareprojekte.
- Nicht geeignet für Software, deren Anforderungen sich ändern.
- Das Modell macht es schwierig, spätere Änderungen an der Konstruktion und Funktionalität vorzunehmen, sobald die Überprüfungsphasen gestartet wurden.
- Im linearen Lebenszyklus wird erst spät eine funktionierende Software erstellt.
Wann gelingt IT Outsourcing?
(und wann nicht?)
