Unterschied Wasserfallodell zu V-Modell

TenorX schrieb:
> Wo ist da der Unterschied ?

Für mich ist das V-Modell ein Wasserfallmodell. Nur weil die einzelnen 
Phasen in V-Form aufgemalt werden ändert sich am zeitlichen Ablauf 
nichts: Vorgegebene Phasen werden linear zeitlich hintereinander 
abgearbeitet.

Die beim V-Modell gerne heraus gestellte Tatsache, dass es für jede 
Entwurfsphase später(!) eine zugehörige Testphase gibt ist ebenfalls 
nichts Besonderes. Eine spätere Phase nutzt Informationen einer früheren 
Phase? Ja potzblitz, wer hätte das gedacht? Das haben wir ja noch nie 
gemacht. /ironie

> Beim V-Modell werden die Tests zwar so gestaltet, dass sie auf die
> Entwurfsphasen abgestimmt sind, aber das muss doch auch beim
> Wasserfallmodell getan werden oder ?

Genau. Es ist ist ziemlich blöd etwas zu testen was man vorher nicht 
gebaut hat. Was die V-Modell Fans so feiern ist eine Trivialität.

Michael Gugelhupf schrieb:
> Was die V-Modell Fans so feiern ist eine Trivialität.

Meines Erachtens nicht.

Die Erkenntnis, dass jedem Requirement auch (sofort) ein entsprechendes 
Testkriterium und Test zugeordnet werden kann und muss, ist (war) nicht 
jedem Offensichtlich. In meinem Umfeld wurden sich mit Tests erst quasi 
mitten in der Entwicklung befasst. Und daran ändert auch 
Unit-Test-Driven-Design nichts, denn das ist quasi nur der unterste Teil 
des Vs, quasi die (wie schon gesagt) Mitte.

>Wenn ich die Beshreibungen richtig lese, werden beim V-Modell >bereits in
>der jeweiligen Entwurfsphase auch die späteren Tests für genau >diese
>Phase spezifiziert.
Habe auch flüchtig gelesen, dass es ja ein Vorteil wäre, dass man sich 
schon über die Tests Gedanken macht.
Ich denke aber das sollte man so oder so.

Wenn man mehr über V-Modell recherchiert sieht man aber auch, dass 
dahinert ein etwas komplexeres Modell steckt mit Akteuren, Aktivitäten 
usw..
Ich glaube das wurde auch als Standard genormt.
https://de.wikipedia.org/wiki/V-Modell_(Entwicklungsstandard)

>ist (war) nicht
>jedem Offensichtlich.

Ja ok dann ist es evtl. doch ein Unterschied.

>Sie kommt eher vor der nächsten.
Stimmt

>Es
>gibt dort eben nur "den Test" und sonst nichts.

Ja ok , da wird dann beim Testen nicht mehr bewusst auf die einzelnen 
Entwurfsschritte geachtet. Verstehe.

Danke euch !

TenorX schrieb:
> Beide sind linear. Eine Phase kommt nach der nächsten.
> Am Ende finden Tests statt.
> Wo ist da der Unterschied ?

Das ist falsch. Das V-Modell enthält explizit keine Zeitkomponente, 
sondern bildet nur verschiedene Granularitätslevel der Entwicklung ab 
und wie diese verifiziert / validiert werden können.

A. S. schrieb:
> Und daran ändert auch
> Unit-Test-Driven-Design nichts, denn das ist quasi nur der unterste Teil
> des Vs, quasi die (wie schon gesagt) Mitte.

Deswegen heißt es ja auch "Test Driven Design", nicht 
"Unit-Test-Driven-Design".

Profi schrieb:
> TenorX schrieb:
>> Beide sind linear. Eine Phase kommt nach der nächsten.
>> Am Ende finden Tests statt.
>> Wo ist da der Unterschied ?
>
> Das ist falsch. Das V-Modell enthält explizit keine Zeitkomponente,

Das sehen die Anwender und Macher anders. Zitat
https://www.cio.bund.de/Web/DE/Architekturen-und-Standards/V-Modell-XT/vmodell_xt_node.html
>> Es unterstützt die Arbeit von Projekten, indem es Ergebnisse und
>> Abläufe vorgibt, so dass zu keinem Zeitpunkt unnötige Arbeiten und
>> möglichst auch keine Leerlaufzeiten entstehen.

Wenn du es genauer wissen willst lese mal in der offiziellen Doku unter 
Stichworten wie Projektfortschrittsstufe, Projektabschnitt oder 
Entscheidungspunkt. Alles schön wasserfallartig.

Mittlerweile hat man noch ein bisschen Iteration (und Inkremente) drüber 
gestrickt. War wohl etwas zu peinlich als glorifiziertes 
Wasserfallmodell durch die Gegend zu dümpeln. Die Iterationen sind sehr 
grob gestrickt, es soll jeweils der gesamte Entwicklungszyklus mehrfach 
durchlaufen werden. Viele schöne kleinere Wasserfälle ...

TenorX schrieb:

> beim Software Engineering gibt es die Begriffe
> Wasserfallmodell und V-Modell.

Ja.


> Beide sind linear. Eine Phase kommt nach der nächsten.
> Am Ende finden Tests statt.
> Wo ist da der Unterschied ?

Ich möchte erstmal auf eine GEMEINSAMKEIT hinweisen:
Das, was heutzutage unter diesen Namen publiziert und
diskutiert wird, hat mit den Ideen des Schöpfers des
Modelles ABSOLUT NICHTS zu tun!

Winston W. Royce stellt die Aussage, dass eine einfache,
vorher festgelegte Abfolge von Schritten in der Regel
völlig unzureichend ist, an den Anfang seines berühmten
Artikels, und diskutiert in diesem zahlreiche
Erweiterungen. Zynischerweise wird er allgemein als der
Schöpfer des Wasserfallmodelles angesehen. "Albert
Einstein, der berühmte Schöpfer der klassischen Mechanik
und des absoluten Raumes"

Beim V-Modell kommt dazu, dass es nicht DAS V-Modell
gibt; das originale V-Modell von Barry Boehm hat mit
dem genormten V-Modell nur den Namen gemeinsam.

In einer dermaßen exakten Wissenschaft wie dem
Projektmanagement spielen solche Kleinigkeiten aber
nicht die geringste Rolle...

Michael Gugelhupf schrieb:

> Profi schrieb:
>> TenorX schrieb:
>>> Beide sind linear. Eine Phase kommt nach der nächsten.
>>> Am Ende finden Tests statt.
>>> Wo ist da der Unterschied ?
>>
>> Das ist falsch. Das V-Modell enthält explizit keine
>> Zeitkomponente,
>
> Das sehen die Anwender [...] anders.

Das ist ohne jede Beweiskraft.

Es gibt auch "Anwender" von "Scrum", die sich darüber
beklagen, dass jeden Tag "eine Präsentation vorbereitet"
werden muss...


Zu jeder Methode gibt es mindestens einen Anwender, der
die Methode völlig entstellt -- und sich dann lautstark
über die Untauglichkeit der Methode beklagt.

Grundlegend kenne ich folgende Unterschiede.

Beim Wasserfallmodell werde die Phasen nacheinander durchlaufen und die 
Testspec entsteht auch erst zum Schluss.

Da das V-Modell leider oft falsch gelebt wird, neigt man dazu zwischen 
den beiden Modellen keinen Unterschied in der Praxis zu sehen.

Lebt man das V-Modell so wie gefordert, entstehen direkt bei der 
Anforderungsanalyse auch die Verlinkungen zu den Tests. Also ist der 
Tester direkt am Anfang des Projekts mit dabei und kann auch bei der 
Anforderunganalyse mitreden und im Optimalfall auch noch die 
Anforderungen anpassen lassen bzw. garnicht anmehmen (Kunden drauf 
hinweisen, dass es da noch eine Definitions-Lücke gibt (was nicht 
Testbar ist, kann man auch nicht herstellen).
Bei dem Ur-Wasserfallmodell ist das nicht so vorgesehen gewesen. Es 
wurde von oben nach unten entwickelt. Das läuft so lange gut, solange 
alle Phasen ihren Job gut gemacht haben und es keine Anforderungslücken 
gibt (Nie der Fall, nur sind die Fehler manchmal nicht so gravierend und 
man hat Glück).
Im Worst-Case wären mehrere Rückschritte notwendig, die den Fehler, der 
beim Testen gefunden wurde, beseitigen. Anforderungsanpassung (was beim 
Kunden in einer späten Phase nicht gut ankommt), Impelemtierung und 
Re-Tests sind dann die Folge. Wenn das bei vielen Kleinigkeiten 
passiert, dann geht es sehr schnell ins Geld und kann das schnell das 
Projekt unrentabel machen (siehe Bild 10er-Regel)

Zurück zum V-Modell: Des Weiteren "erzwingt" das V-Modell dann auch 
automatisch ein Review der einzelnen Domänen. Es schaut sich nicht nur 
der Systemer die Anforderung in der Akquise an, sonder auch zumindest 
der System-Tester (in der Rosa-Roten-Welt).
Und gerade in der Phase kann man am meinsten Geld sparen, wenn man es 
richtig lebt. Und hier spreche ich nicht vom eigenem Geld, sondern auch 
vom Geld des Kunden. Der Kunde sollte sich über so ein Vorgehen freuen, 
auch wenn es lästig ist/erscheint. Er spart später ChangeRequests, die 
bestimmt nicht kostenlos vom Auftragnehmer realisiert werden.

Abgesehen davon, dass das V-Modell dann auch die unterschiedlichen 
Domänen(SW/HW/MD/Produktion) angewendet wird, wo wieder frühzeitig 
mehrer Rollen zum Review erforderlich sind.

Links zum Bildern: 
https://deutscher-mittelstand.com/branchenloesungen/projektkostenabschaetzung

https://www.sixsigmablackbelt.de/fehlerkosten-10er-regel-zehnerregel-rule-of-ten/


Gruß
Simon

TenorX schrieb:
> aber das muss doch auch beim
> Wasserfallmodell getan werden

Nein

Aber es ist irrelevant.

Weil Modelle nicht die Wirklichkeit sind,
sondern Vereinfachungen für kleine Geister.

Wer selber denkt, kommt auf prakikable Lösungen.

Wer stur einem Modell folgt, bleibt dumm.

vn nn schrieb:
> A. S. schrieb:
>> Und daran ändert auch
>> Unit-Test-Driven-Design nichts, denn das ist quasi nur der unterste Teil
>> des Vs, quasi die (wie schon gesagt) Mitte.
>
> Deswegen heißt es ja auch "Test Driven Design", nicht
> "Unit-Test-Driven-Design".

Dann nenn mir doch ein Beispiel, wo TDD nicht mit unittests anfängt.

Mein Verständnis:

- Das Wasserfallmodell sagt, wann etwas gemacht wird. Streng gelebt darf 
man mit jeder Phase erst anfangen, wenn die vorige komplett 
abgeschlossen ist. Das kann man theoretisch soweit treiben, dass eine 
IT-Firma jede einzelne Phase an einen anderen Subunternehmer vergibt (RE 
an ein Beratungshaus, Design an ein Architekturbüro, Codierung an 
Offshore, Testen an Crowdworker...). Jeder Subunternehmer gibt dann 
seine Ergebnisse an den nächsten weiter -> "Softwareentwicklung am 
Fliessband".

- Das V-Modell sagt, was auf welcher Grundlage gemacht wird, also nicht 
mit dem Lastenheft in der Hand sofort losprogrammiert wird, sondern erst 
mal ein Systemmodell entwickelt wird und dieses auch vollständig genug 
sein muss, um die Codierung zu tragen. Und ebenso soll jede Testebene 
auch "ihre" Vorgabenebene komplett abdecken.

Natürlich ist damit die zeitliche Abfolge nicht mehr ganz frei, aber man 
kann linke und rechte Seite sowohl parallel abarbeiten und sich an der 
Fussspitze treffen, als auch - ala Wasserfall - zuerst links oben, dann 
nach mitte unten und von dort rechts rauf arbeiten, solange man keinen 
Schritt wegläßt.
@Simon: Bitte korrigier mich, wenn ich falsch liege.

> Dann nenn mir doch ein Beispiel, wo TDD nicht mit unittests anfängt.

Zum Beispiel Acceptancetest-Driven-Development auf Basis von 
User-Stories, die bei Webanwendungen über Browser-Automatisierung 
getestet werden (-> Selenium, Cucumber und ähnliches)

keinLichtAufGing schrieb:
> aber man kann linke und rechte Seite sowohl parallel abarbeiten und sich
> an der Fussspitze treffen, als auch - ala Wasserfall - zuerst links
> oben, dann nach mitte unten und von dort rechts rauf arbeiten, solange
> man keinen Schritt wegläßt.

Die Abarbeitung ist schon klar, immer nacheinander. Erst runter, dann 
rauf.  Der Witz ist nur, dass die Testkriterien ganz oben rechts (bzw. 
dort Validierung) quasi ganz am Anfang erstellt werden. Trotzdem der 
Test erst am Ende erfolgt.

A. S. schrieb:
> Der Witz ist nur, dass die Testkriterien ganz oben rechts (bzw.
> dort Validierung) quasi ganz am Anfang erstellt werden. Trotzdem der
> Test erst am Ende erfolgt.

Wie auch sonst? Natürlich werden die groben Anforderungen ganz am Anfang 
definiert, und das Gesamtsystem kann auch erst am Ende abgenommen 
werden, während die Details später definiert werden, aber das Modul für 
sich dann auch schon früher getestet werden kann.
Bastelbudeningenieur?

A. S. schrieb:
> vn nn schrieb:
>> A. S. schrieb:
>>> Und daran ändert auch
>>> Unit-Test-Driven-Design nichts, denn das ist quasi nur der unterste Teil
>>> des Vs, quasi die (wie schon gesagt) Mitte.
>>
>> Deswegen heißt es ja auch "Test Driven Design", nicht
>> "Unit-Test-Driven-Design".
>
> Dann nenn mir doch ein Beispiel, wo TDD nicht mit unittests anfängt.

Natürlich werden Unit Tests als erstes ausgeführt, aber nicht als erstes 
definiert.
Und dreh mir nicht die Worte im Mund um.

keinLichtAufGing schrieb:
>> Dann nenn mir doch ein Beispiel, wo TDD nicht mit unittests anfängt.
>
> Zum Beispiel Acceptancetest-Driven-Development auf Basis von
> User-Stories, die bei Webanwendungen über Browser-Automatisierung
> getestet werden (-> Selenium, Cucumber und ähnliches)

Oder so ziemlich jedes System abseits von Browser-Bastelbudenkram. Die 
groben Anforderungen und Tests an ein KFZ-Steuergerät stehen nun mal 
fest, lange bevor es an die Implementierungsdetails geht.