Prof. Dr. Christian Johner

Autor: Prof. Dr. Christian Johner

Inhaber der Johner Institut GmbH

V-Modell vs. Wasserfallmodell für und Hardware- und Softwareentwicklung:
Am Beispiel der Entwicklung von Medizinprodukten

Montag 26. Januar 2015

Das V-Modell ist ein Entwicklungsprozessmodell, das ursprünglich für staatliche Projekte entwickelt wurde. Das V-Modell unterscheidet sich vom Wasserfall-Modell dadurch, dass bereits während der konstruktiven Phasen (z.B. während dem Schreiben der Anforderungen oder dem Entwerfen der Architektur) die zugehörigen Tests spezifiziert werden müssen.

Das hat den Vorteil, dass unvollständige Spezifikationen oder Festlegungen frühzeitig erkannt werden, auch dadurch, dass die für das Testen verantwortlichen Personen mit eingebunden werden.

Beim V-Modell wird ebenso wie beim Wasserfall-Modell in den Testphasen gegen die Spezifikationen bzw. Festlegungen getestet.

V-Modell

Das V-Modell sollte Herstellern von Medizinprodukten zumindest als Dokumentationsmodell dienen. (Zum Vergrößern klicken)

Ein Blick in die Medizintechnik-Normen wie die IEC 60601-1 oder die IEC 62304 macht deutlich, was viele Auditoren und Autoren von Normen denken: Sie verstehen Entwicklungsprozess-Modelle oft als synonym von V-Modellen – obwohl die Normen explizit kein Vorgehensmodell vorschreiben.

Die Phasen des V-Modells

Je nach Typ der Entwicklung (z.B. Medizingerät versus standalone Software) umfasst das V-Modell mehr oder weniger Phasen. Fast immer zählen zu diesen Phasen die folgenden (jeweils mit Synonymen):

  • Anforderungsdefinition, Stakeholder-Requirements (u.a. Nutzungsanforderngen)
  • Systemanforderungen, System Requriements Specification funktionaler Systementwurf
  • Systemarchitektur, System Architecture, technischer Systementwurf
  • Komponentenspezifikation, Component Requirements
  • Komponententests, Unit Tests
  • Integrationstests, Integration Tests
  • Systemtests, Systemtests
  • Validierung, Akzeptanztests, Abnahmetests (Begriffe sind nicht ganz synonym).

Besonders die ersten Phasen im V-Modell werden meist nicht sauber getrennt und die Nutzungsanforderungen und Systemanforderungen verwechselt.

V-Modell: Erste Phasen

1. Phase im V-Modell: Nutzungsanforderungen

Nutzungsanforderungen sind gemäß Definition an einem interaktiven System notwendige Tätigkeiten, um ein Handlungsziel zu erreichen. Man formuliert Nutzungsanforderungen mit der Schablone „Der Nutzer muss am System xxx können“, wobei xxx für eingeben, auswählen oder eine kognitive Handlung wie erkennen, verstehen, unterscheiden steht.

Ein Beispiel für eine Nutzungsanforderung wäre: „Der Nutzer muss am System die Diagnose des Patienten erkennen können“. Nutzungsanforderungen sind keine(!) konkreten Beschreibungen einer Lösung.

Lesen Sie hier mehr zum Identifizieren von Nutzungsanforderungen.

2. Phase im V-Modell: Systemanforderungen

Systemanforderungen beschreiben aus Black-Box-Sicht, wie das System die Nutzungsanforderungen umsetzt. Hierzu zählt die konkrete Beschreibung der Schnittstellen, das sind wiederum im Wesentlichen die GUI und ggf. andere Schnittstellen nach außen. Zur GUI gehört eine Beschreibung der Screens, eine Beschreibung, wie man durch die Screens navigieren kann und wie das System auf Benutzereingaben, auch falsche, reagiert.

Die Systemanforderungen beschreiben nicht(!) wie man das System technisch umsetzt, um dieses Black-Box-Verhalten zu erreichen. Eine gute Systemarchitektur ermöglicht es, das System an ein Entwicklungshaus zu geben und dort umsetzen zu lassen, ohne dass das Entwicklungshaus Rückfragen stellen müsste.

Lesen Sie hier mehr zum Spezifizieren von Systemanforderungen.

Verwechslung von Nutzungs- und Systemanforderungen im V-Modell bei Wikipedia

Haben Sie schon einmal nachgesehen, was Wikipedia zum V-Modell schreibt? Sie werden dort auf diese Abbildung stoßen:

V Modell nach WikipediaQuelle: http://de.wikipedia.org/wiki/V-Modell

Bereits das Wort „Systemanforderungsanalyse“ lässt mich etwas schaudern. Darin stecken nämlich zwei Begriffe und somit auch zwei Phasen, die keinesfalls zusammenfallen sollten:

  • Zum einen gibt es die Stakeholder-Anforderungen insbesondere die Nutzungsanforderungen.
  • Zum anderen gibt es die Systemanforderungen, also eine Beschreibung des künftigen Systems aus Blackbox-Sicht. Bei Software gehören hierzu eine Beschreibung der Benutzerschnittstelle (wie das System aussieht und wie es auf Benutzereingaben reagiert), manche sogenannte „nicht-funktionale“ Anforderungen (z.B. an das Zeitverhalten) und Beschreibungen der nach außen „sichtbaren“ technischen Schnittstellen.

Das V-Modell der IEC 60601-1

Ähnlich problematisch ist das V-Modell der IEC 60601-1:

V-Modell der IEC 60601-1

Das V-Modell der IEC 60601-1 verwechselt ebenfalls Systemanforderungen (werden verifiziert) und Stakeholder-Anforderungen (werden validiert). (Bildquelle: IEC 62304, die die IEC 60601-1 zitiert)

Laut dieser Norm (siehe Abbildung) werden aus Anwenderbedürfnissen Anforderungen an ein programmierbares elektrisches medizinisches System, kurz PEMS, abgeleitet. Also Systemanforderungen.

Das erste, was ich mich frage ist, was die Norm unter Anwenderbedürfnissen versteht. Es handelt sich um einen nicht definierten Begriff. Wahrscheinlich verstanden die Autoren darunter ein nicht näher verstandenes Mischmasch aus Erfordernissen, Wünschen, Nutzungsanforderungen und direkt formulierten Systemanforderungen. Wer so unpräzise mit den Begrifflichkeiten umgeht, wird nachher auch unpräzise Ergebnisse erzielen.

Wohin diese mangelnde Präzision führt, erkennen Sie selbst: Die Norm glaubt die Erfüllung von PEMS-Anforderungen, also Systemanforderungen, validieren zu können. Systemanforderungen kann man (im Systemtest) verifizieren, aber nicht validieren. Validieren kann man definitionsgemäß hingegen Nutzungsanforderungen. Doch die tauchen wie eben diskutiert überhaupt nicht in dem Bild auf, sondern gehen im Nebel der Anwenderbedürfnisse unter.

Wem diese Unterschiede nicht gleich einleuchten, dem empfehle ich das (zumindest für mich) wegweisende Seminar von Thomas Geis. Es heißt „Usability, Requirements und IEC 62366“. Thomas Geis ist sehr streng mit den Begrifflichkeiten. Und das macht seine Ergebnisse so sensationell. Wenn Sie eine Innovationsmaschine erleben wollen, besuchen Sie das Seminar – oder buchen Sie ihn am besten gleich. Mach ich auch so…

3. Phase im V-Modell: System- oder Software-Architektur

Die Architektur beschreibt, wie man das System technisch umsetzen will. Das Ergebnis muss so präzise sein, dass ein Entwickler mit dieser Vorgabe das System runterprogrammieren kann, ohne eine Design-Entscheidungen treffen zu müssen. Aspekte der Architektur sind beispielsweise die Programmiersprache und eingesetzten Technologien, das Komponenten- und Klassendiagramm und Datenbank-Schemata. Die Architektur muss so beschaffen sein, dass die

  • die Systemanforderungen umgesetzt sind: Das sind wie geschrieben die Anforderungen an das System aus Blackbox-Sicht erfüllt sind, wozu auch Performanz-Anforderungen und die Portabilität des Systems zählen.
  • das System wartbar, änderbar und testbar ist,
  • die Komponenten und deren Schnittstellen erkennbar und
  • bei Software die SOUPs und die Sicherheitsklassen der Komponenten identifiziert sind

Hilft das ein wenig? Wenn nicht, dann fragen Sie mich! Ich antworte gerne, schnell und kostenlos.

Wenn Sie noch mehr über diese Phasen lernen möchten, empfehle ich Ihnen eines meiner Seminare zur Entwicklung medizinischer Software.

V-Modell versus agile Entwicklung

Viele Medizinproduktehersteller liebt die agile Software-Entwicklung, besonders die Software-Entwickler. Die Normen in der Medizintechnik erlauben agile Vorgehensmodelle.

Beispielsweise sind die IEC 62304 und die FDA beide der Meinung, dass eine agile Software-Entwicklung mit ihren jeweiligen Forderungen kompatibel sein können. Letztlich müssen aber die Dokumente am Ende der Entwicklung (!) vorhanden sein. D.h. das V-Modell sollte als Dokumentationsmodell genutzt werden.

Regulatorisch sehe ich daher keine Gefahr. Allerdings beobachte ich bei agile entwickelnden Medizinprodukten das Folgende:

Auf meine Frage, wie sie agile Entwicklung und Anforderungen der Normen wie die der IEC 62304 unter einen Hut bringen, höre ich immer öfter die Antwort „Mit Mini-Vs“. Die Hersteller behaupten also, das klassische V-Modell einfach in kurzen Zyklen iterativ und inkrementell zu durchlaufen.

V-Modell und agile Entwicklung

Ist das das Ei des Kolumbus? Die lange ersehnte Synthese aus prozessorientiertem gesetzeskonformen Entwickeln (als These) und der Flexibilität der agilen Entwicklung (Antithese)?

Diese Frage kann und möchte ich nicht abschließend beantworten. Aber ich möchte Sie auf einige Gefahren hinweisen:

  1. Erhöhter Verifikationsaufwand: Eine Minderheit durchläuft im Rahmen ihrer viele Mini-Vs. Das muss man aber können, denn sonst multipliziert man den Aufwand für Reviews und Tests mit der Anzahl der Iterationen. Wenn Sie die geforderten Verifikationsschritte (in obiger Grafik mit „V“ bezeichnet) wirklich alle durchführen, benötigen Sie sehr schlanke Freigabeprozesse. Andernfalls werden Sie von den Formalitäten der Verifizierung erschlagen und haben genau das Gegenteil erreicht: Einen riesigen QM-Overhead.
  2. Unvollständige Verifizierung/Verifikation: Die Versuchung ist hoch, zwar formal so zu arbeiten, wie die Grafik das zeigt, de facto findet aber eine Verifikation (von ein paar Modultests abgesehen) nur im letzten Sprint statt. Die Vorteile der Verifikation, das frühe Finden von Fehlern in Dokumenten und Code, haben Sie vertan. Teures Nachbessern ist die Folge.
  3. Schlechte Zusammenarbeit von QM/RA und Entwicklung: Sie verifizieren in den ersten Sprints inhaltlich und im letzten Sprint formal. Das ist erst einmal eine gute Idee. Sie wird aber das Auseinanderlaufen von Entwicklung, die für die ersten Sprints verantwortlich zeichnet, und QM, die während des letzten Sprints prüft, weiter gefordert. Diese Diskrepanz im Denken und Handeln kann sich aber auf Dauer als Bumerang erweisen. In anderen Worten: Es besteht die Gefahr, dass sich die Entwicklung für die „Implementierungs-Sprints“ und QM/RA für die QM-Sprints zuständig fühlt. Das wiederum führt dazu, dass die beiden Abteilungen nicht nahtlos zusammenarbeiten und sich die Entwickler über die nervende QM bzw. die QM über die schlampigen Entwicklern mokieren.
  4. Erhöhte Entwicklungsdauer und Aufwände: Sie arbeiten bei den ersten Sprints nicht so sorgfältig wie Sie könnten, besonders was die Erhebung von Nutzungsanforderungen angeht. Der Gedanke schleicht sich ein, dass Fehler ja während der nächsten Sprints auffallen und dann immer noch korrigiert werden können. Je später Sie aber korrigieren, umso aufwendiger wird das.

Nein, ich bin kein Gegner der agilen Entwicklung. Aber agile Entwicklung der Agilität wegen ist genauso absurd wie der naive Glaube, man könne eine Entwicklung rein linear durchlaufen.

Die Mini-Vs sind also nicht per se das Ei des Kolumbus. Schade, wäre doch so einfach gewesen.

Lassen Sie mich wissen, wenn ich Sie unterstützen kann. Beispielsweise Ihren Entwicklungsprozess neu zu definieren – normenkonform versteht sich – und unnötigen QM-Overhead loszuwerden. Schließlich ist Ihr Ziel nicht ein bestimmtes Prozessmodell, sondern Software schnell und mit Spaß zu entwickeln. Und genau bei kann ich helfen.

Kontakt aufnehmen

Verantwortlichkeiten im V-Modell

Was ist eigentlich die Aufgabe des Chefs, fragt mich ein Teilnehmer eines Inhouse-Seminars. nachdem ich die Aufgaben von Entwicklern und Produktmanagern abgegrenzt habe.

V-Modell: Verantwortlichkeiten

Verantwortlichkeiten beim V-Modell: Geschäftsführung (blau), Produktmanager, Usability & Requirements Engineers (grün), (Software) Entwickler (rot)

Erst einmal großes Gelächter und zynische Sprüche wie „das Geld zählen“. Da ist etwas Wahres dran. In der Tat besteht die Aufgabe eines Chefs darin, über den (ökonomischen) Erfolg zu wachen. Genauso wie es seine oder ihre Aufgabe ist, diesen zu planen.

Die Geschäftsführung sollte diejenige sein, die den Nutzungskontext und das Geschäftsmodell festlegt (blau). Die Usability- und Requirements-Engineers haben die Aufgabe, in diesem gegebenen Nutzungskontext die Nutzungsanforderungen (und sonstigen Stakeholder-Anforderungen) zu identifizieren und Systemspezifikationen abzuleiten. Diese Aufgabe (grün) übernehmen teilweise auch die Produktmanager.

Die Aufgabe der Entwicklung (rot) besteht darin, spezifizierte Lösungen in lauffähige Produkte zu überführen.

Alle Rollen leisten wichtige und wertschöpfende Beiträge – auch der Chef :-).

Die Planung der Software-Verifizierung: Verlangt die 62304 doch das V-Modell?

Offensichtlich erschrocken ist ein Entwicklungsleiter, als er das Kapitel 5.1.6 der IEC 62304 „Planung der Software-Verifizierung“ gelesen hat. Und so fragt er in meiner Auditsprechstunde, ob das bedeuten würde, dass die Tests bereits vor der Programmierung spezifiziert sein müssten.

Das ist eine gute Frage. Die Antwort lautet zum Glück nein. Anderenfalls hätte die Norm nämlich ein V-Modell erzwungen. Das ist ja genau dadurch charakterisiert, dass die Tests in der jeweiligen konstruktiven Phase spezifiziert werden.

Verifikationsschritte im V-Modell

Die 62304 fordert hingegen, dass man bereits bei der Entwicklungsplanung festlegt, wie man testet. Das schließt ein:

  • die (Blackbox-) Testverfahren (mehr dazu in den Videotrainings zum Testen im Auditgarant),
  • wie man Tests spezifiziert, durchführt und dokumentiert,
  • wann man die Tests durchführt (z.B. nächtlich oder vor dem Release),
  • was die Akzeptanzkriterien sind (nicht jeder Bug muss notwendigerweise behoben werden) und
  • welche Werkzeuge man zum Spezifizieren (z.B. Texteditor, Testdatengenerator), Durchführen (z.B. Testsoftware, Integration mit Build-Management) und Dokumentieren und Tracen (z.B. MedPack) einsetzt.

Die kurze Antwort lautet also: Die konkreten Tests können Sie auch noch unmittelbar vor dem Testen spezifizieren. Die Entwicklungsplanung benötigen Sie aber zu Projektbeginn.


Kategorien: Beliebteste Beiträge, Software & IEC 62304, Systementwicklung, Usability & IEC 62366
Tags: , , ,

Kommentar schreiben