V-Modell: Die 5 häufigsten Probleme vermeiden

Das V-Modell ist ein Entwicklungsprozessmodell, das ursprünglich bei staatlichen Projekten (u. a. Rüstung) zur Anwendung kam. Bis heute ist es bei Projekten im regulierten Umfeld (z. B. Medizintechnik, Banken) in vielen Köpfen und Normen verankert. Das führt zu Konflikten in Teams, die agile Entwicklungsprozesse bevorzugen.

Dieser Artikel hilft, diesen Widerspruch aufzulösen. Sie erfahren, wie Sie die fünf häufigsten Probleme vermeiden und das V-Modell richtig einsetzen.

1. V-Modell: Die Grundlagen

a) Ziele des V-Modells

Ziel 1: Entwicklungsziele erreichen

Wie alle Entwicklungsprozessmodelle soll auch das V-Modell dazu beitragen, dass Entwicklungsprojekte in der geplanten Zeit und mit den geplanten Ressourcen die Ergebnisse (Produkte, Software) in der geplanten Qualität erreichen.

Ziel 2: Klarheit schaffen

Dazu ist es notwendig, dass jede Rolle im Entwicklungsprojekt weiß, welchen Input sie zu welchem Zeitpunkt mit welchen Methoden in welchen Output überführen muss.

Ziel 3: Regulatorische Anforderungen erfüllen

In regulierten Branchen wie der Medizintechnik, im Bankenumfeld oder der Luftfahrindustrie müssen Gesetze, Normen und Leitlinien befolgt werden, die das Arbeiten nach dem V-Modell nahelegen.

b) Besonderheiten des V-Modells

Die verschiedenen Phasen

Das V-Modell unterscheidet viele Entwicklungsphasen, die sich in drei Gruppen unterteilen lassen:

1. Planung und Spezifikation (s. Abb. 1 in blau)
2. Implementierung (in grün)
3. Verifizierung und Validierung (in violett)

Spezifikation von Tests während der Planungsphasen

Das V-Modell zeichnet sich dadurch aus, dass die Verifizierung und Validierung bereits während der Planungsphasen spezifiziert werden. Anhand welcher „Tests“ entschieden wird, ob die in der Planungsphase gestellten Anforderungen erfüllt sind oder nicht, wird bereits bei der Planung festgelegt.

Die roten Pfeile in der Abbildung 1 repräsentieren diese Zuordnung.

Die Tester prüfen dann in den Testphasen gegen die Spezifikationen aus den Spezifikations-/Planungsphasen.

c) Abgrenzung zu anderen Prozessmodellen

Wasserfall-Modell

Genau diese Zuordnung unterscheidet das V-Modell vom Wasserfall-Modell. Das V-Modell ist kein Wasserfall-Modell, bei dem die Verifizierungs- und Validierungsaktivitäten in der grafischen Darstellung nur „hochgeklappt werden“.

In beiden Modellen ist es möglich, bei Fehlern, die in einer Phase erkannt werden, wieder in vorherige Phasen zurückzuspringen, um dort die Fehler zu beheben. Aber die Aktivitäten erfolgen linear.

Agile Prozessmodelle

Trotz aller Rücksprünge wird das V im Rahmen des Entwicklungsprojekts nur einmal durchlaufen. Man nimmt dabei an, dass die Anforderungen zu Beginn des Projekts ausreichend, vollständig und korrekt bestimmt wurden.

Agile Prozessmodelle machen diese Annahme nicht. Vielmehr nutzen sie ein iteratives, inkrementelles Vorgehen, um die Anforderungen schrittweise zu erheben und erfüllen.

2. Phasen und Verantwortlichkeiten

a) Überblick über die Phasen und Aktivitäten

Diese Übersicht geht davon aus, dass das zu entwickelnde System/Produkt aus mehreren Systemkomponenten besteht, die jeweils Hardware und Software beinhalten, welche selbst wiederum in Komponenten (z. B. Software-Komponenten) unterteilt sind (s. Abb. 2).

b) Beschreibung der Aktivitäten/Phasen

c) Verantwortliche Rollen

Die Aktivitäten beim V-Modell liegen nicht nur bei der Entwicklungsabteilung (s. Tabelle 2).

Die Aufgabe der Geschäftsführung besteht darin, den Kontext des Produkts bzw. Systems zu bestimmen.

Machen Sie Ihren Entwicklungsprozess auditsicher

Entdecken Sie jetzt, wie Sie Ihren Entwicklungsprozess auditsicher gestalten und dabei weiterhin effizient arbeiten können. Nutzen Sie unseren Auditgarant, um Ihr Medizinprodukt schnell und effizient auf den Markt zu bringen und dabei alle relevanten Anforderungen zu berücksichtigen.

Mehr erfahren

3. Die fünf Probleme beim Einsatz des V-Modells

Problem 1: Verwechseln der Anforderungstypen

Die Unterscheidung der verschiedenen Anforderungstypen ist wichtig, ebenso die Anwendung der jeweils richtigen Methoden, um diese Anforderungen zu identifizieren.

Selbst auf Wikipedia fehlt diese Unterscheidung und/oder Identifizierung der Stakeholder-Anforderungen (s. Abb. 3).

Auch Normen wie die IEC 60601-1 verwechseln die Anforderungstypen (s. Abb. 4).

Im Gegensatz zur Darstellung in Abb. 4 werden Systemanforderungen verifiziert, nicht validiert. Das „S“ in PEMS steht für „System“. Das Identifizieren der Stakeholder-Anforderung fehlt auch in dieser Darstellung.

Problem 2: Illusion „Wasserfall-Modell“

Die Annahme, dass alle (Stakeholder-)Anforderungen von Anfang an vollständig und korrekt erfasst sind, ist selten erfüllt. Das V-Modell basiert aber auf genau dieser Annahme.

Um das zu erreichen, gibt es mehrere Lösungsansätze:

• Stakeholder-Anforderungen systematisch mit der Kontextmethode erheben (Eine direkte Befragung insbesondere der Nutzer ist keine geeignete Methode.)
• Die erhobenen Stakeholder-Anforderungen mit den Stakeholdern validieren.
  1. Die Stakeholder-Requirements-Specification von den Stakeholdern prüfen lassen.
  1. Prototypen und Mockups entwickeln und vor der eigentlichen Entwicklung im Rahmen formative Evaluationen bewerten lassen. Mit dem Feedback iterativ die Stakeholder- und Systemanforderungen verbessern (s. Abb. 5).
• Das Produkt in mehreren Iterationen (mehreren Vs) entwickeln.

Problem 3: Erhöhte Aufwände durch „Mini-Vs“

Durch die iterative Entwicklung mit „Mini-Vs“ (siehe Abb. 6) versuchen Hersteller, den Kompromiss zu finden zwischen regulatorischen Anforderungen und einer agilen Entwicklung.

Die Gefahr besteht dabei, dass der bürokratische Aufwand überproportional steigt. Denn jetzt müssen beispielsweise die Dokumentenprüfungen und -freigaben sowie Tests (beides sind Verifizierungsaktivitäten) nicht nur einmal, sondern bei jeder Iteration (Sprint) durchlaufen werden.

Wenn Hersteller keine schlanken Prüf- und Freigabeprozesse haben, legen sie sich damit lahm.

Mit dem Laden des Videos akzeptieren Sie die Datenschutzerklärung von YouTube.
Mehr erfahren

Video laden

YouTube immer entsperren

PGlmcmFtZSB0aXRsZT0iQWdpbGUgU29mdHdhcmUtRW50d2lja2x1bmc6IEtvbmZvcm0gRU42MjMwNCB1bmQgRkRBPyIgd2lkdGg9IjEyMDAiIGhlaWdodD0iNjc1IiBzcmM9Imh0dHBzOi8vd3d3LnlvdXR1YmUtbm9jb29raWUuY29tL2VtYmVkL0gtNDBfRl9lVG40P2ZlYXR1cmU9b2VtYmVkIiBmcmFtZWJvcmRlcj0iMCIgYWxsb3c9ImFjY2VsZXJvbWV0ZXI7IGF1dG9wbGF5OyBjbGlwYm9hcmQtd3JpdGU7IGVuY3J5cHRlZC1tZWRpYTsgZ3lyb3Njb3BlOyBwaWN0dXJlLWluLXBpY3R1cmU7IHdlYi1zaGFyZSIgcmVmZXJyZXJwb2xpY3k9InN0cmljdC1vcmlnaW4td2hlbi1jcm9zcy1vcmlnaW4iIGFsbG93ZnVsbHNjcmVlbj48L2lmcmFtZT4=

Problem 4: Nicht-Konformitäten durch „gefaktes V-Modell“

Um dieses Problem zu umgehen, tendieren einige Hersteller dazu, in der Realität iterativ und inkrementell zu arbeiten (ohne das zu dokumentieren), „offiziell“ aber nach dem V-Modell. Mit anderen Worten: Sie entwickeln relativ frei von prozessualen Vorgaben und erstellen am Ende eine Dokumentation, die den Anschein erwecken soll, dass nach den Vorgaben eines V-Modells entwickelt wurde.

Das ist ein Verstoß gegen viele regulatorischen Vorgaben und – so vorhanden – die Vorgaben des eigenen QM-Systems.

Problem 5: Entwicklungsrisiken zu spät erkennen

Ob das Entwicklungsprojekt erfolgreich war, weiß man beim V-Modell erst am Ende. Die Entwicklungsrisiken sind also hoch.

Die folgenden Beispiele zeigen, wie Hersteller diese Risiken minimieren können:

• Mit vertikalen Prototypen frühzeitig herausfinden, ob die Software-Architektur geeignet ist dafür, dass die Software die Anforderungen an das Zeitverhalten und den Ressourcen-Verbrauch erfüllt.
• Mit Mock-Objekten noch nicht entwickelte Komponenten ersetzen, um die bereits entwickelten Komponenten zu testen.
• Mit formativen Evaluationen früh Klarheit schaffen, ob das System gebrauchstauglich ist (s. Abb. 5).

4. V-Modell bei Medizinprodukten

a) Regulatorische Anforderungen

Bei Medizinprodukten stellen mehrere Normen Anforderungen an den Entwicklungsprozess:

• Die ISO 13485 fordert, diesen Prozess zu spezifizieren, der die Rollen bestimmt und Aktivitäten wie die Design-Reviews, die Verifizierung und Validierung festlegt.
• Auch die IEC 60601-1 fordert für programmierbare elektrische medizinische Systeme (PEMS) die Festlegung eines Entwicklungsprozesses. Dieser muss im Wesentlichen die in Abb. 1 dargestellten Aktivitäten umfassen. Ein V-Modell schreibt die Norm allerdings nicht vor.
• Die IEC 62304 enthält im Anhang die in Abbildung gezeigte Darstellung. Sie verweist auf die IEC 60601-1, besteht aber auch nicht auf einem V-Modell. Sie betont sogar, dass agile Ansätze üblich und möglich sind.

b) Zusammenspiel mit anderen Prozessen

Weitere Normen stellen ebenfalls Anforderungen an Prozesse:

• Die ISO 14971 fordert einen Risikomanagementprozess.
• Die IEC 62366-1 legt Anforderungen an den Usability-Engineering-Prozess fest.

c) V-Modell als Dokumentationsmodell

Das V-Modell in seiner reinen Form wenden nur wenige Medizinproduktehersteller an. Sie nutzen es eher als Dokumentationsmodell. Dabei beschreibt das V-Modell, welche Dokumente im Lauf der Entwicklung entstehen sollen und in welchen Abhängigkeiten diese zueinander stehen.

Dieser Ansatz hat sich bewährt, solange nicht das oben beschriebene Prolem 4 (Nicht-Konformitäten durch „gefaktes“ V-Modell) begangen wird.

5. Fazit und Zusammenfassung

Das V-Modell hat es geschafft, sich in den Köpfen der meisten Hersteller und Prüfer (z. B. bei Benannten Stellen und Behörden) festzusetzen. In der Praxis wird es jedoch kaum in der reinen Form gelebt. Bei vielen Firmen haben sich agile Prozessmodelle durchgesetzt.

Aber auch agil arbeitende Entwicklungsteams sollten die Best Practices des V-Modells übernehmen:

• Früh und möglichst systematisch und vollständig die Stakeholder-Anforderungen ermitteln
• Zumindest die Grobarchitektur zu einem frühen Zeitpunkt (und nicht iterativ-inkrementell) erstellen und prüfen
• Die Dokumente gemäß dem V-Modell erstellen und verifizieren

Das neuere V-Modell XT, das agile Ansätze unterstützt, nutzen Medizinproduktehersteller kaum. Das alte V-Modell leistet scheinbar weiterhin gute Dienste.

Änderungshistorie

• 2023-04-28: Artikel komplett neu geschrieben
• 2018-07-11: Erste Version des Artikels