Hallo guten Tag, beim Software Engineering gibt es die Begriffe Wasserfallmodell und V-Modell. Beide sind linear. Eine Phase kommt nach der nächsten. Am Ende finden Tests statt. Wo ist da der Unterschied ? 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 ?
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.
TenorX schrieb: > 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 ? Wenn ich die Beschreibungen richtig lese, werden beim V-Modell bereits in der jeweiligen Entwurfsphase auch die späteren Tests für genau diese Phase spezifiziert.
:
Bearbeitet durch User
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.
TenorX schrieb: > Beide sind linear. Eine Phase kommt nach der nächsten. Wie soll das funktionieren? Sie kommt eher vor der nächsten. > 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 ? Dass man das tun muss, ist klar, aber das Modell bildet das nicht ab. Es gibt dort eben nur "den Test" und sonst nichts.
>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.
Angehängte Dateien:
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.