it-swarm.com.de

Kann jemand den V-Modell-Prozess erklären? Warum unterscheidet es sich vom Wasserfallmodell?

Es scheint, dass das V-Modell nur das Wasserfallmodell ist, bei dem die untere Hälfte des Wasserfalls nach oben gebogen ist, um ein V zu bilden. Ich sehe nicht, wie es etwas Neues hinzufügt.

Aus den Diagrammen verstehe ich auch den Fluss nicht. Es gibt Pfeile in alle Richtungen und ich kann nicht verstehen, was zuerst kommt. Folgen wir dem V von links oben nach unten in die Mitte und dann wieder nach rechts oben? Oder gehen wir das V runter und machen alles höher, bevor der Gegenstand niedriger wird?

Dem Internet fehlt eine ausreichende Erklärung für dieses Modell. Es wäre großartig, wenn jemand es in echter StackExchange-Form erklären könnte :)

V Model

19
CodyBugstein

Das V-Modell ist eine Erweiterung des Waterfall-Modells. Erwarten Sie also nicht, dass es sich stark unterscheidet.

Grundsätzlich Sie folgen dem V-Modell von links nach rechts, genau wie im Wasserfallmodell. In Waterfall erledigen Sie Anforderungen, Design, Implementierung, Überprüfung und schließlich Wartung. Auf die gleiche Weise erledigen Sie im V-Modell Anforderungen, Design, Implementierung, Verifizierung und Wartung: in beiden Fällen dieselben Schritte.

Die Hauptunterschiede zu Waterfall sind die Art und Weise, wie es dargestellt wird, und die Betonung des Testens.

Die Darstellung des Flusses als V-Form hilft dabei, den Unterschied zwischen allem, was vor dem Codieren kommt (Anforderungen, Architektur und Design), und allem, was auf das Codieren folgt (im Wesentlichen Testen), zu machen. Während Tests in Waterfall nur einer von fünf Schritten sind, sieht es im V-Modell praktisch wie die Hälfte des Prozesses aus.

Das Diagramm in Ihrer Frage ist etwas komplizierter. Es soll gezeigt werden, dass beispielsweise der Systemdesignschritt nicht nur zum Systemdesigndokument führt, wie es das Wasserfallmodell vorschlagen würde, sondern auch zum Systemtestdesign, das später beim Schreiben von Systemtests hilfreich sein wird. Das Diagramm zeigt nur noch mehr Nachdruck auf das Testen. Schließlich hilft das Ausführen von Systemtestdesign beim Architekturdesign (es wäre umständlich, Architekturdesign unabhängig vom Systemtestdesign durchzuführen).


Wenn ich nach anderen Erklärungen im Internet suche, kann ich es nicht vermeiden, den folgenden Artikel von Bhakti Satalkar zu zitieren:

Der Hauptunterschied zwischen dem Wasserfallmodell und dem V-Modell besteht darin, dass im Wasserfallmodell die Testaktivitäten ausgeführt werden, nachdem die Entwicklungsaktivitäten beendet sind. Im V-Modell beginnen die Testaktivitäten hingegen mit der ersten Stufe. Mit anderen Worten, das Wasserfallmodell ist ein kontinuierlicher Prozess, während das V-Modell ein simultaner Prozess ist. Im Vergleich zu einer Software, die mit dem Wasserfallmodell erstellt wurde, ist die Anzahl der Fehler in der Software, die mit dem V-Modell erstellt wurde, geringer. Dies liegt daran, dass es Testaktivitäten gibt, die gleichzeitig im V-Modell durchgeführt werden. Daher wird das Wasserfallmodell verwendet, wenn die Anforderungen des Benutzers festgelegt sind. Wenn die Anforderungen des Benutzers ungewiss sind und sich ständig ändern, ist das V-Modell die bessere Alternative.

Diese Erklärung ist irreführend. Dies ist nur dann der Fall, wenn Sie das „V-Modell“ im Zitat durch eine agile Methode ersetzen.

Im Gegensatz zu den Artikelzuständen erfolgt das Testen im V-Modell nach der Codierung. siehe zum Beispiel Wikipedia :

eine verbreitete praktische Kritik am V-Modell ist, dass es dazu führt, dass Tests in enge Fenster gepresst werden am Ende der Entwicklung wenn frühere Phasen überlaufen sind, das Implementierungsdatum jedoch fest bleibt.

Während im V-Modell das Systemtestdesign dem Systemdesign folgt, ohne zu warten, bis die Produktimplementierung abgeschlossen ist, bedeutet dies nicht, dass die Tests selbst vor dem Codieren durchgeführt werden. Der Autor verwechselt das V-Modell mit agilen Ansätzen wie Test Driven Development (TDD) in Extreme Programming (XP).

17