Kann jemand den V-Modell-Prozess erklären? Warum ist es anders als das Waterfall-Modell?

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 verstehe 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 der Mitte und dann wieder nach rechts oben? Oder gehen wir das V runter und tun alles höher, bevor der Gegenstand niedriger wird?

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

Das V-Modell ist eine Erweiterung des Waterfall-Modells. Erwarten Sie also keinen großen Unterschied.

Grundsätzlich folgt man dem V-Modell von links nach rechts , genau wie im Wasserfallmodell. In Waterfall übernehmen Sie Anforderungen, Design, Implementierung, Überprüfung und schließlich Wartung. In gleicher 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 der Darstellung und die Betonung des Testens.

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

Das Diagramm in Ihrer Frage ist etwas komplizierter. Was es zu zeigen versucht, ist, dass zum Beispiel der Systementwurf nicht nur zum Systementwurfsdokument führt, wie es das Waterfall-Modell nahelegt, sondern auch zum Systemtestentwurf, der später beim Schreiben von Systemtests hilfreich sein wird. Das Diagramm legt nur noch mehr Wert auf das Testen . Schließlich hilft das Ausführen von Systemtestentwürfen beim Architekturentwurf (es wäre umständlich, Architekturentwürfe unabhängig vom Systemtestentwurf 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. Beim V-Modell hingegen beginnen die Testaktivitäten mit der ersten Stufe. Mit anderen Worten ist das Wasserfallmodell 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 ein 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 "V-Modell" im Angebot durch eine beliebige Agile-Methode ersetzen.

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

Eine gängige Kritik aus der Praxis am V-Modell ist, dass die Tests am Ende der Entwicklung in enge Fenster gedrückt werden, wenn frühere Phasen überschritten wurden, der Implementierungstermin jedoch weiterhin feststeht.

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