home  |  suche  |  kontakt/johner  |  institut 
studierende  |  tech-docs  |  mindmailer 

Einführung

Das V-Modell ist eines der verbreiteten Prozessmodelle und findet bei vielen Entwicklungsprojekte, nicht nur im IT-Bereich, Anwendung. Bei vielen staatlichen Projekten wird es sogar zwingend vorgeschrieben.

Das V-Modell kann als eine Weiterentwicklung des Wasserfallmodells betrachtet werden, dem die Möglichkeit der Rücksprünge in eine vorhergehende Phase hinzugefügt ist. Wichtige Phasen sind

  • Anforderungsdefinition oder Anforderungsanalyse, 
  • Funktionaler Systementwurf, auch als funktionale Spezifikation, als Software System Requirements oder Pflichtenheft bezeichnet.
  • Technischer Systementwurf auch als Architektur bezeichnet. Oft zerlegt man diese Phase in zwei Unterphasen, die Grob- und Feinarchitektur, welche man auch Grobdesign und Feindesign nennt.
  • Implementierung, Programmierung, Kodierung
  • Modultests
  • Integrationstests
  • Funktions- und Systemtests
  • Abnahmetests (Validierung)

Der wichtigste Unterschied zum Wasserfallmodell besteht darin, dass bereits während der konstruktiven Phasen die Testfälle spezifziert (natürlich nicht durchgeführt) werden.

Anforderungsdefinition: 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 Schriftfarbe auswählen können”. Nutzungsanforderungen sind keine(!) konkreten Beschreibungen einer Lösung.

Funktionaler Systementwurf: 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. Weitere Aspekte (ebenfalls Blackbox-Sicht) umfassen:

  • Performanz, Reaktionszeit, Ressourcenverbrauch
  • Robustheit, Verhalten bei Überlast und Fehleingaben
  • Installierbarkeit, Update-Fähigkeit, unterstütze Plattformen
  • usw.

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.

Technischer Systementwurf: 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 und
  • die Komponenten und deren Schnittstellen erkennbar.

Die Architektur beschreibt man üblicherweise aus mehreren Sichten, darunter

  • die oben genannte statische Sicht mit Komponenten- und Klassendiagrammen
  • die dynamische Sicht, also die Beschreibung wie Prozesse und Workflows ablaufen
  • die Deployment-Sicht, die Beschreibung auf welchem System welche Artefakte (dll, jar, exe, Server usw.) installiert sind.

Verifikation und Validierung

Zu den Stärken des V-Modells zählt sicher die Tatsache, dass möglichst früh im Entwicklungsprozess die Tests definiert werden. Man unterscheidet bei dieser Überprüfung die Begriffe "Validierung" und "Verifikation".

Während der Validierung wird überprüft, ob die (Nutzungs-)Anforderungen erfüllt wurden, also ob die richtigen Dinge getan wurden. Hier geht es also darum, ob die Nutzer ihre Nutzungsziele erreichen können. Wenn Sie einen Defibrillator entwickeln würden, würden Sie bei der Validierung prüfen, ob man mit dem Gerät das Herz von Patienten wieder zum regelmäßigen Schlagen bringen würde.

Hingegen prüft man während der Verifikation, ob die Dinge richtig getan wurden, d.h. man prüft ob ein System wie spezifziert entwickelt wurde. Um das Beispiel des Defibrillators fortzusetzen: Bei der Verifizierung könnte man prüfen, ob das Gerät wie spezifiziert 2000 Volt an den Elektroden anliegen hat. Bei einer Software würde man prüfen, ob die GUI wie spezifiziert aussieht und wie spezifiziert auf Benutzeraktionen reagiert. Die Verifizierung bezieht sich also beispielsweise auf die System- und nicht auf die Nutzungsanforderungen.

Da die Validierung erst zum Ende des Entwicklungsprozesses erfolgt, besteht die Gefahr, dass Fehler in den Anforderungen bis zum Schluss unentdeckt bleiben. Dies ist ein großer Nachteil im Vergleich zu den iterativen Vorgehensmodellen, wie dem XP. Weiterhin verlangt das V-Modell eine Konstanz der Anforderungen. Sobald die Phase der Anforderungsanalyse abgeschlossen ist, sieht das V-Modell keine Änderungen an den Anforderungen mehr vor. Diese Annahme ist jedoch in den wenigsten Projekten zutreffend. C. Jones berichtete 1986, dass 80% der Projekte unter instabilen oder wachsenden Anforderungen leiden würden. Da die meisten Projekte zudem unter Zeitnot geraten, kommen die letzten Phasen oft zu kurz. Und das sind beim V-Modell die Testphasen ...