V-Modell vs. Wasserfallmodell für Hardware- und Softwareentwicklung

Mittwoch 11. Juli 2018

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 frühzeitig erkannt werden, auch dadurch, dass die für das Testen verantwortlichen Personen mit eingebunden werden.

Allgemeines

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

V-Modell

Abb. 1: Das V-Modell sollte Herstellern zumindest als Dokumentationsmodell dienen. (Zum Vergrößern klicken)

Ein Blick in viele domänenspezifische Normen (z.B. IEC 60601-1 und IEC 62304 in der Medizintechnik) macht deutlich, wie viele Autoren von Normen sowie Auditoren denken: Sie verstehen Entwicklungsprozess-Modelle oft synonym mit V-Modellen – obwohl die Normen kein spezifisches Vorgehensmodell vorschreiben.

Die Phasen des V-Modells

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

  1. Anforderungsdefinition, Stakeholder-Requirements (u.a. Nutzungsanforderngen)
  2. Systemanforderungen, System Requriements Specification funktionaler Systementwurf
  3. Systemarchitektur, System Architecture, technischer Systementwurf
  4. Komponentenspezifikation, Component Requirements
  5. Komponententests, Unit Tests
  6. Integrationstests, Integration Tests
  7. Systemtests, Systemtests
  8. 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

Abb. 2: Abgrenzung der Phasen im V-Modell

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.

Weiterführende Informationen

Lesen Sie hier mehr zum Identifizieren von Nutzungsanforderungen. Lernen Sie, die wirklichen Anforderungen Ihrer Kunden zu erfüllen und im Markt erfolgreich zu sein.

2. Phase im V-Modell: Systemanforderungen

Systemanforderungen beschreiben aus Black-Box-Sicht, wie das System die Nutzungsanforderungen umsetzt. Hierzu gehört die konkrete Beschreibung der externen Schnittstellen. Zu diesen zählen die GUI, Datenschnittstellen sowie Schnittstellen zum Anwendungsteil oder der Versorgung mit Strom, Wasser oder Gasen.

Beispielsweise gälte es bei der GUI-Spezifikation, die Screens zu spezifizieren inkl. einer 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 System Requirements Specification ermöglicht es, das System von einem Entwicklungsdienstleister ohne weitere Rückfragen entwickeln zu lassen.

Weiterführende Informationen

Lesen Sie hier mehr zum Spezifizieren von Systemanforderungen. Sie erfahren, wie Sie diese schnell und normenkonform dokumentieren.

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 umsetzen kann, ohne wesentliche Design-Entscheidungen treffen zu müssen.

Aspekte der Architektur sind bei Software beispielsweise die Programmiersprache und eingesetzten Technologien, das Komponenten- und Klassendiagramm sowie 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
Weiterführende Informationen

Lesen Sie hier mehr zum Thema Software-Architektur und System-Architektur.

Verantwortlichkeiten im V-Modell

Was ist eigentlich die Aufgabe des Chefs, fragt ein Teilnehmer eines Inhouse-Seminars. 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.

V-Modell: Verantwortlichkeiten

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

Die Verantwortlichkeiten lassen sich wie folgt den Aufgaben zuordnen:

  • 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.

Somit leisten alle Rollenwichtige und wertschöpfende Beiträge – auch der Chef :-).

V-Modell versus agile Entwicklung

Viele Hersteller lieben die agile Software-Entwicklung, besonders die Software-Entwickler.

Regulatorische Anforderungen (in der Medizintechnik)

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

Regulatorisch besteht somit keine Gefahr. Allerdings beobachtet das Johner Institut bei agil entwickelnden Firmen das Folgende:

Herausforderungen

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

V-Modell und agile Entwicklung

Abb. 4: Zerlegung des V-Modells in Mini-Vs?!

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

Das Johner Institut 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.

Das Johner Institut schätzt die agile Entwicklung. Aber agile Entwicklung der Agilität wegen ist genauso absurd wie der naive Glaube, man könne eine Entwicklung rein linear durchlaufen.

Weiterführende Informationen

Lesen Sie hier mehr zum Thema agile Software-Entwicklung.

Typische Missverständnisse und Fehler

1. 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 Wikipedia

Abb. 5: Quelle: http://de.wikipedia.org/wiki/V-Modell

Bereits das Wort „Systemanforderungsanalyse“ lässt 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.

2. Unklare Begriffe und Phasen im V-Modell gemäß IEC 60601-1

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

V-Modell der IEC 60601-1

Abb. 6: 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 werden aus „Anwenderbedürfnissen“ Anforderungen an ein programmierbares elektrisches medizinisches System, kurz PEMS, abgeleitet. Also Systemanforderungen.

Das erste, was man sich fragen kann 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.

Vorsicht!

Wer so unpräzise mit den Begrifflichkeiten umgeht, wird 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.

Weiterführende Informationen

Lesen Sie hier mehr zum Thema Unterschiede von Verifizierung und Validierung.

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.

3. 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. Er fragt im Micro-Consulting, ob das bedeuten würde, dass die Tests bereits vor der Programmierung spezifiziert sein müssten.

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

Abb. 7: 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.

Unterstützung

Lassen Sie uns wissen, wenn wie Sie unterstützen können. Beispielsweise dabei, 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 dabei kann das Johner Institut helfen.

Jetzt Kontakt aufnehmen


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

Kommentar schreiben