V-Modell als Projektmanagementmethode

Dieser Artikel dient zur Einführung in das Thema: V-Modell als Projektmanagementmethode. Die Grundprinzipien des V-Modells, die Anwendungsgebiete und Praxisbeispiele werden hier angesprochen.

Der Artikel ist geeignet für diejenigen, die das V-Modell näher kennenlernen und ein Fingerspitzengefühl bekommen möchten, um zu entscheiden, ob dieses Modell für ein eigenes Projekt als Projektmanagementmethode geeignet ist.

*1) Um Grafiken zu vergrößern, benutzen Sie die rechte Maustaste und die Option: “Bild in neuem Tab öffnen”.

Das V-Modell ist ein weitverbreitetes Projektmanagementmodell, das in der Automotive-Industrie während der Software- und Systementwicklung verwendet wird. Vor allem in großen und komplexen Projekten, bei denen die Anforderungen schon von Anfang des Projekts mehr oder weniger gut definiert sind, kann man das V-Modell verwenden.

Das V-Modell basiert auf linearen und sequenziellen Phasen, die voneinander provisorisch getrennt sind. Diese Phasen stellen beide Schenkel des V-Modells dar. Auf der linken Seite des V-Modells befinden sich die Phasen für die Entwicklung des Systems und der Software und auf der rechten Seite die Phasen für die Validierung und das Testing des Systems und der Software.

Das „alte“ Wasserfallmodell erwies sich Ende 1970er als zu starr und wenig flexibel in Bezug auf die Verifikation und Validierung von Systemen. So entstand in den 1980er Jahren das Verständnis, dass während der Produktentwicklung eine andere Vorgehensweise entwickelt werden soll.

Ende 1970er Jahre hat der amerikanische Ingenieur Barry Boehm das V-Modell vorgestellt. Anfang 1980er wurde das V-Modell für die deutsche Bundeswehr weiterentwickelt und standardisiert. Später wurde das Modell in vielen industriellen Projekten verwendet, besonders in der Automobilindustrie, Flugzeugbau, Schiffsbau und Eisenbahn.

Das Ziel der Entwicklung des V-Modells war, ein klares und definiertes Entwicklungsmodell zu erstellen, welches eine strikte und systematische Struktur anbieten kann und ein höheres Ausmaß an Qualität und Validierungsgrad gewährleistet.

Ein solches Modell ist besonders für die sicherheitskritischen Projekte [2], [3] geeignet, weil der Testabdeckungsgrad, die Testqualität und somit die gesamte Produktqualität sich auf hohem Niveau befinden.

Mit der Weiterentwicklung der Softwaretechnik und sich ändernden Anforderungen in der Industrie wurde das ursprünglich ausgearbeitete V-Modell mehrmals überarbeitet und eine neuere Version, das „V-Modell 97“ wurde veröffentlicht.

Im Jahr 2005 wurde das „V-Modell XT“ (Extreme Tailoring) eingeführt. Dieses neue Modell baute auf den Grundprinzipien des ursprünglichen V-Modells auf, war aber flexibler und anpassungsfähiger für die Anwendung in unterschiedlichen Projekttypen und -größen.

Insbesondere in der modernen Softwareentwicklung, in der sich Anforderungen oft während des Projektverlaufs ändern, war es notwendig, ein flexibleres Vorgehensmodell zu erstellen.

Das neue Modell erlaubt, die Projektspezifikationen auf die jeweilige Situation zuzuschneiden (Tailoring) und ist in der Lage, sowohl in klassischen als auch in agilen Projektumgebungen angewendet zu werden.

Die linke Seite des V-Modells steht für die Spezifikations-, Entwurfsphasen und Implementierung, während die rechte Seite des V-Modells die Test- und Verifikationsphasen beschreibt. Jedes Element auf der linken Seite des V-Modells wird mit genau einem Element validiert (getestet).

Während ein klassisches Wasserfallmodell einen rein linearen Prozess beschreibt, legt das V-Modell (siehe Diagramm: ASPICE 4.0 Prozessgruppen) einen großen Wert auf parallele Aktivitäten. D. h. Parallel zur Phase der Anforderungsimplementierung auf Systemebene wird versucht, einen Plan für die Systemvalidierung zu erstellen und Testfälle zu erarbeiten. Der Fokus im V-Modell liegt auf der Parallelisierung von Entwicklungs- und Testphasen, welche iterativ zu jedem Produktstand durchgeführt werden.

Jede Phase des V-Modells ist klar definiert und hat bestimmte Meilensteine mit Arbeitsprodukten wie Arbeitsergebnissen und dazugehörigen Output-Dokumenten. Zu jeder Phase gehört ein spezifisches Ergebnis: Dokumente und/oder Artefakte, die einen Meilenstein im Projekt repräsentieren.

Zu den wichtigsten Phasen auf der linken Seite des V-Modells gehören:

• Anforderungsanalyse: In dieser Phase werden aus Kundenanforderungen die Systemanforderungen abgeleitet (spezifiziert).
• Systemdesign: Anhand der Systemanforderungen wird das System und die Systemarchitektur in seiner Gesamtheit entworfen oder angepasst.
• Softwarearchitektur: Die Softwarearchitektur und die Softwarekomponenten werden spezifiziert und implementiert.
• Modulentwicklung: Einzelne Softwaremodule werden entworfen und implementiert.
• Test und Verifikation: Jede Phase des Entwicklungsprozesses wird durch entsprechende Tests überprüft.

Das V-Modell trennt die Verifikation und Validierung. Während die Verifikation bedeutet, dass das System (oder Software, Hardware) entsprechend den Spezifikationen entwickelt wird, stellt die Validierung sicher, dass das entwickelte System auch tatsächlich den Bedürfnissen des Kunden entsprechend implementiert wurde.

In den folgenden Abschnitten sind die Phasen des V-Modells im Detail beschrieben und erklärt. Es wird erläutert, wie jede Phase zur erfolgreichen Umsetzung eines Projekts beiträgt.

Die Definition der Kundenanforderungen ist der erste Schritt eines Entwicklungsprozesses. Für die erfolgreiche Erfassung von Kundenanforderungen werden die Workshops zwischen dem Kunden und einem Systemingenieur zur Frageklärung und zum Informationsaustausch durchgeführt.

Am Ende dieser Phase liegt ein detailliertes Lastenheft für die Projektentwicklung vor. Die Spezifikation dient als Ausgangspunkt für das gesamte Projekt. Ein wichtiger Meilenstein in dieser Phase ist die formale Abnahme der Kundenanforderungen durch einen Kunden (bzw. gemeinsam mit diesem).

In der nächsten Phase werden funktionale und nicht-funktionale Systemanforderungen aus Kundenanforderungen abgeleitet, die als Grundlage für die spätere Systementwicklung dienen.

Die Systemspezifikation legt fest, was das System machen muss, um die Kundenanforderungen zu befriedigen.

Dabei muss beachtet werden, dass jede Kundenanforderung mit mindestens einer Systemanforderung abgedeckt werden muss. Die Systemanforderungen müssen die Leistungsmerkmale des Systems sowie die Schnittstellen nach außen im Systemkontext beschreiben.

Die Systemarchitektur beschreibt die Umsetzung eines Systems auf physikalischer Ebene. Die Systemarchitektur beschreibt die Systemkomponenten, wie die benötigten HW-Komponenten, SW-Komponenten, Schnittstellen sowie die Interaktion zwischen den Systemkomponenten.

Die Systemarchitektur stellt das Grundgerüst der weiteren Systementwicklung dar und beschreibt:

• die Struktur des Systems,
• die verwendeten Technologien,
• die zu verwendete Software und Hardware und
• die grundlegenden Designprinzipien, die bei der Implementierung von unterschiedlichen Disziplinen (HW, SW und ME) benötigt werden

Diese Phase ist entscheidend für die spätere Implementierung von unterschiedlichen Disziplinen wie Software und Hardware, weil hier die wichtigsten Architekturentscheidungen getroffen werden.

Lesen Sie detaillierte Informationen zum Thema:

• Systemengineering,
• Systemanforderungen,
• Systemarchitekturanforderungen,
• Systemengineering (in Praxis)

Die Softwarearchitektur beschäftigt sich mit der Detaillierung der Software im Kontext eines Systems. In dieser Phase werden die Softwarekomponenten definiert und zu bestimmten Hardwarekomponenten (wie Mikrocontroller) zugeordnet.

Die Schnittstellen von Softwarekomponenten werden definiert, die Programmiersprache und die implementierenden Algorithmen werden festgelegt.

Ein Softwarearchitekt arbeitet während dieser Phase eng mit Entwicklern zusammen und holt vom Entwicklungsteam ein Feedback zur Machbarkeit des Vorhabens während der Entwicklung.

Des Weiteren wird überprüft, ob die Softwarearchitektur den Softwareanforderungen entspricht. Das Softwarearchitekturdokument dient als Basis für die weitere Entwicklung der Software im Projekt.

Die detaillierte Information zur Vorgehensweise und Erstellung einer Softwarearchitektur finden Sie in diesem Artikel:

• Softwarearchitekturanforderungen,
• Softwarearchitektur (in Praxis).

Die Phase für das Ableiten von den Softwareanforderungen aus Systemanforderungen habe ich an der Stelle ausgelassen. Für die Interessanten gibt es den Artikel: Anforderungsmanagement, wo man die Ableitung von Softwareanforderungen aus Systemanforderungen kennenlernen kann.

Eine weitere Phase im V-Modell ist das Softwaremoduldesign und die Softwaremodulimplementierung. Während einer Softwaremoduldesign-Phase werden die zuvor definierte Softwaremodule auf Code-Ebene implementiert.

Die Softwaremodule werden nach den Vorgaben aus Softwarearchitektur und Softwareanforderungen mit dem Code „befüllt“. Solche Faktoren wie Performance, Sicherheit und Wartbarkeit werden bei der Implementierung berücksichtigt.

Die Entwicklung des Codes verläuft nach strikten Codierungsregeln wie Coding-Guideline und Berücksichtigung von MISRA-Regeln.

Nach der Implementierung werden die Softwaremodule getestet. Damit wird überprüft, ob die Implementierung den Softwareanforderungen entspricht. Am Ende dieser Phase steht ein funktionsfähiges System, das jedoch bisher nicht vollständig integriert und getestet ist.

Die rechte Seite des V-Modells bezieht sich auf die Test- und Verifikationsphasen, die parallel zu den Entwicklungsphasen stattfinden sollen.

Hier wird sichergestellt, dass das entwickelte System und die Software den System- und Softwareanforderungen entsprechen und korrekt implementiert wurden.

Sobald ein Softwaremodul erstellt wird, muss dieses Softwaremodul getestet werden (ASPICE: Software Unit Verification). Hier werden die Anforderungen für Tests definiert und die eigentliche Implementierung getestet. Folgende Faktoren sollen beim Testen berücksichtigt werden:

• funktionale Anforderungsabdeckung,
• ob Codefunktionen richtig implementiert sind,
• ob die Schnittstellen (von einem Softwaremodul) richtig umgesetzt sind,
• es soll eine Grenzwertanalyse durchgeführt werden,
• es soll eine Datenfluss- und Kontrollflussanalyse durchgeführt werden
• etc.

Die Softwaremodultests werden oft automatisch durchgeführt. Sobald die Softwaremodule getestet sind, kann man zur nächsten Phase der Validierung: Softwareintegrationstests übergehen.

Während dieser Phase gehen wir zur nächsten Abstraktionsebene in der Software, und zwar zum Kontext der Softwarearchitektur. In dieser Phase werden die Schnittstellen der Softwarekomponenten sowie die Interaktion zwischen den Softwarekomponenten getestet. (siehe ASPICE: SWE.5 Software Component Verification and Integration Verification). Hier wird getestet, ob die implementierten Softwaremodule korrekt miteinander zusammenarbeiten.

Es werden während dieser Phase folgende Punkte in der Software unter anderem überprüft:

• Fehlerzustände und Fehlerbehandlung
• Funktionale Tests
• Nicht-Funktionale Tests
• Schnittstellentests
• Daten- und Kontrollflüsse
• etc.

Während des Softwarequalifikationstests (ASPICE: SWE.6 Software Verification) wird die Software auf einer höheren Abstraktionsebene (gesamte Software) getestet. Die Software wird gegen die Systemanforderung getestet, dabei werden folgende Punkte in Betracht genommen:

• Funktionale- und Nicht-Funktionale Anforderungen
• Systemschnittstellen auf Softwareebene (Schnittstellen zu anderen Systemen)
• Stresstests
• Sicherheitsanforderungen
• Performance und Robustness
• etc.

In dieser Phase wird nicht nur die Software, sondern das gesamte System (ASPICE: SYS.4 System Integration and Integration Verification) auf der Systemarchitekturebene getestet. Im Fokus werden die einzelnen Systemkomponenten genommen und es wird überprüft, ob diese zusammen korrekt funktionieren und die Systemanforderungen korrekt umgesetzt sind.

Es wird an der Stelle überprüft:

• ob die Systemkomponenten miteinander und entsprechend den Anforderungen funktionieren,
• ob die Schnittstellen von Systemkomponenten korrekt funktionieren,
• ob physische und logische Integration von Software und Hardware korrekt implementiert ist,
• ob die Datenflüsse korrekt ausgeführt werden
• ob die Reaktion auf Systemkomponentenfehler korrekt ausgeführt wird,
• ob das System unter extremen Betriebsbedingungen korrekt funktioniert
• usw.

Die Systemverifikationstests (ASPICE: SYS.5 System Verification) betrachten das gesamte System als eine Einheit. Hier wird die korrekte Umsetzung von Systemanforderungen im Kontext eines vollständig integrierten Systems überprüft.

Hier sind die wichtigsten Punkte, die während den Tests geprüft werden:

• Schnittstellen zu anderen Systemen
• Konformität von Übertragungsprotokollen
• Performance- und Stresstests
• Funktionale- und Ausfallsicherheit
• Erfüllung von Anforderungen aus Normen und Standards
• Umwelttests
• usw.

Am Ende des Abnahmetests erfolgt die offizielle Freigabe des Systems, sofern alle Tests erfolgreich bestanden wurden. Dieser Meilenstein markiert das Ende der Entwicklungs- und Testphase und den Beginn der Betriebs- und Wartungsphase.

Diese Projektphase stellt sicher, dass das Produkt auch während der Produktion und Vermarktung weiterentwickelt und an neue Anforderungen nach Kundenwunsch angepasst werden kann.

Es muss ein Dokument für diese Phase erstellt werden, das die Leistungen an Kunden und die Arbeitsumfänge während dieser Phase beschreibt.

Das V-Modell hat in unterschiedlichen Industriebranchen Verwendung gefunden:

• Automobilindustrie
• Luft- und Raumfahrt
• Verteidigungssektor
• Öffentliche Verwaltung und große IT-Projekte

Das V-Modell bringt eine Vielzahl von Stärken mit sich, die es zu einer bevorzugten Methode in bestimmten Branchen machen. Allerdings gibt es auch einige Nachteile, insbesondere bei modernen, sich schnell ändernden Projekten.

In diesem Kapitel werden die wesentlichen Vor- und Nachteile des V-Modells ausführlich beleuchtet.

Wenn wir das V-Modell mit anderen Projektmanagementmodellen vergleichen, z. B. mit agilen Methoden wie Scrum oder Kanban, kann man folgende Unterschiede feststellen:

Die Bewertung ist subjektiv anhand der praktischen Erfahrung.

Die Erfahrung zeigt, dass es nicht um ein Entwicklungsmodell geht (Agil oder konventionell). Es geht meistens darum, die Prozesse zu definieren. Das V-Modell im Rahmen von ASPICE bietet schon eine solide Grundlage für die Prozesse. Die Agile-Methode bietet im Gegenteil weniger verständliche und nachvollziehbare Prozesse (im Automotive-Bereich muss viel mehr als einfache Softwareentwicklung berücksichtigt werden). D. h. aber nicht, dass diese Lücke nicht geschlossen werden kann. Mit Disziplin und Konsistenz kann man die Automotive-Projekte gut auch mit Agile-Methode bewältigen.