Unit-Tests im Wasserfallmodell

[Gast newnils]

Hallo,

passen Unit-Tests und Wasserfallmodell zusammen? Wo sollte ich erwähnen in der Doku, wenn ich Unit-Tests machen würde?

[monolith]

Warum sollte das nicht passen? Jetzt mal rein praktisch gedacht.

[kylt]

Nabend,

vor 7 Stunden schrieb monolith:

Warum sollte das nicht passen? Jetzt mal rein praktisch gedacht.

Deine Aussage impliziert ein "Ja", was ich so aber nicht stehen lassen würde.

vor 8 Stunden schrieb newnils:

Hallo,

passen Unit-Tests und Wasserfallmodell zusammen? 

Wasserfall selbst gibt dir nur die Projektstruktur mit der zeitlichen Abarbeitung. Wenn du von den vier Hauptpunkten "Definition", "Entwicklung" , "Überprüfung" und "Produktivsetzung" ( https://de.wikipedia.org/wiki/Wasserfallmodell )  nur den Punkt der Entwicklung heraus nimmst, dann kannst du natürlich während der Code Entwicklung auf z.B. Unit Tests setzen, damit ein Entwickler eine gewisse Qualitätskontrolle für das gewünschte Ergebnis hast. 

Bei allem weiteren gehe ich auf die Blanke - und für die Prüfung relevante Theorie ein, die natürlich so in der Praxis nicht gelebt wird.

Einen Mehrwert bringt dir Unit Test erst dann wenn du viele Komplexe und sich ständig verändernden Prozesse hast, die per Definition in dem Wasserfallmodell ausgeschlossen sind. Denn es wird das gewünschte Verhalten nur einmalig innerhalb der Planungsphase definiert. Daraus folgt:

1) Auf Grund der linearen Entwicklung sind nur die Erfolgsfälle als Unit Test eindeutig abbildbar (da vordefiniert) und nicht die möglichen Fehlerfälle, die z.B. durch die anschließende Überprüfungs-Phase erst aufgedeckt werden. Meist gibt es nur ein richtig, aber verschiedene "falsche" Ergebnisse. Damit verlieren die Tests Ihre eigentliche Wirkung Fehler zu erkennen.

2) Können auch die Erfolgsfälle falsch definiert sein, da ja keine Absprache nach der Definition mehr mit dem Auftraggeber durchgeführt wird. Das heißt es wird eigentlich nur 1:1 die Pflichtenheft Dokumentation getestet. Da aber in der Phase "Überprüfung" selbiges noch einmal gemacht wird, entsteht doppelter Aufwand für das Testing und verzögert den Prozess im schlimmsten Fall, da die Entwicklung länger dauert. 

3) Wie in 2 schon beschrieben, gilt die Überprüfung als gesonderte Phase nach der Entwicklung. Tritt hier ein Fehler auf,  der z.B. ein Showstopper ist,  beginnt man nach der Theorie wieder mit der Definition und Abnahme des geänderten  Pflichtenheft. Man startet also wieder von Vorn und geht nicht die iterative Schleife über Entwicklung > Test > Entwicklung > Test.

4) Selbst wenn die Unit Test Fehlschlagen bedeutet dies auf Grund von 2)  und 3 ) , dass man bei dem Projekt im schlimmsten Fall von Vorne beginnen muss und im Besten Fall mit vielen bekannten Fehlern trotzdem Produktiv geht. 

Bearbeitet 29. November 2018 von kylt

[Gast newnils]

vor 16 Minuten schrieb kylt:

Nabend,

Deine Aussage impliziert ein "Ja", was ich so aber nicht stehen lassen würde.

Wasserfall selbst gibt dir nur die Projektstruktur mit der zeitlichen Abarbeitung. Wenn du von den vier Hauptpunkten "Definition", "Entwicklung" , "Überprüfung" und "Produktivsetzung" ( https://de.wikipedia.org/wiki/Wasserfallmodell )  nur den Punkt der Entwicklung heraus nimmst, dann kannst du natürlich während der Code Entwicklung auf z.B. Unit Tests setzen, damit ein Entwickler eine gewisse Qualitätskontrolle für das gewünschte Ergebnis hast. 

Bei allem weiteren gehe ich auf die Blanke - und für die Prüfung relevante Theorie ein, die natürlich so in der Praxis nicht gelebt wird.

Einen Mehrwert bringt dir Unit Test erst dann wenn du viele Komplexe und sich ständig verändernden Prozesse hast, die per Definition in dem Wasserfallmodell ausgeschlossen sind. Denn es wird das gewünschte Verhalten nur einmalig innerhalb der Planungsphase definiert. Daraus folgt:

1) Auf Grund der linearen Entwicklung sind nur die Erfolgsfälle als Unit Test eindeutig abbildbar (da vordefiniert) und nicht die möglichen Fehlerfälle, die z.B. durch die anschließende Überprüfungs-Phase erst aufgedeckt werden. Meist gibt es nur ein richtig, aber verschiedene "falsche" Ergebnisse. Damit verlieren die Tests Ihre eigentliche Wirkung Fehler zu erkennen.

2) Können auch die Erfolgsfälle falsch definiert sein, da ja keine Absprache nach der Definition mehr mit dem Auftraggeber durchgeführt wird. Das heißt es wird eigentlich nur 1:1 die Pflichtenheft Dokumentation getestet. Da aber in der Phase "Überprüfung" selbiges noch einmal gemacht wird, entsteht doppelter Aufwand für das Testing und verzögert den Prozess im schlimmsten Fall, da die Entwicklung länger dauert. 

3) Wie in 2 schon beschrieben, gilt die Überprüfung als gesonderte Phase nach der Entwicklung. Tritt hier ein Fehler auf,  der z.B. ein Showstopper ist,  beginnt man nach der Theorie wieder mit der Definition und Abnahme des geänderten  Pflichtenheft. Man startet also wieder von Vorn und geht nicht die iterative Schleife über Entwicklung > Test > Entwicklung > Test.

4) Selbst wenn die Unit Test Fehlschlagen bedeutet dies auf Grund von 2)  und 3 ) , dass man bei dem Projekt im schlimmsten Fall von Vorne beginnen muss und im Besten Fall mit vielen bekannten Fehlern trotzdem Produktiv geht. 

Danke für deine ausführliche Erläuterung!

Ist das Wasserfall überhaupt das richtige für mein Projekt? Ich muss ja davon ausgehen, dass alles funzt und wenn nicht muss das in einem neuen Projekt quasi neu gemacht werden? Wie erwähne ich es am besten in der Doku?

 

Sollte ich da lieber das V-Modell nehmen?

Bearbeitet 29. November 2018 von newnils

[kylt]

vor 16 Minuten schrieb kylt:

Nabend,

Deine Aussage impliziert ein "Ja", was ich so aber nicht stehen lassen würde.

vor 8 Stunden schrieb newnils:

Hallo,

passen Unit-Tests und Wasserfallmodell zusammen? 

 

Ergänzung: Das heißt natürlich trotzdem, dass ein Unit Test für einen Entwickler als reine Selbstüberprüfung der Erfolgsfälle gemacht werden kann, um alle Punkte des Pflichtenheftes abgearbeitet zu haben. - Du könntest dann aber auch eine Excel Tabelle mit dem erledigt Status pflegen, was aber wohl von den Prüfern als weniger Elegant angesehen wird. ?

Ich würde daher meine Contra Punkte aus dem ersten Beitrag nur als Anregung nehmen, warum die Methodik eigentlich nicht richtig zusammen passen, man aber als kompetenter, selbstüberprüfender Entwickler das trotzdem tut. Da die Überprüfung der eigenen Arbeit zum guten Werkzeug dazugehört.

 

 

 

 

[kylt]

vor 4 Minuten schrieb newnils:

[...] Ich muss ja davon ausgehen, dass alles funzt [...] Wie erwähne ich es am besten in der Doku?

 

Du hast wahrscheinlich einen Teil in der Dokumentation alla "Mein Vorgehen in der Entwicklung" Hier kann man gut erläutern, dass man zur Prüfung der vollständigen , gewünschten Implementierung für jeden Punkt einen Erfolgs-Unit-Test schreibt. 

[Gast newnils]

OK, also könnte ich auch schreiben, dass ich mit an dem Wasserfallmodell orientiere, allerdings während der Implemntierung Unit-Tests vornehme um die Qualität zu sichern? Das Wasserfallmodell bildet halt meiner Meinung am besten den geforderten Projektablauf ab, beim V-Modell oder bei einer agilen Entwicklung könnte ich ja auch wieder in eine Phase zurückspringen und das soll bei der Doku ja nicht sein. da läuft es von vorne nach hinten durch. Sollte ich Fehler in der Testphase festellen, kann ich die ja dort auch beheben, bzw. das dort in die Doku schreiben?

[kylt]

Projekte (gerade Abschlussprojekte) sind in verschiedenen Modellen möglich. Es gibt weder richtig , noch falsch. Man muss nur jede Wahl gut begründen können. 

Ein nach Wasserfall Phasen aufgebautes Modell ist aber meist akzeptierter, weil du für das V-Modell echt gut argumentieren musst und dann können in der mündlichen Prüfung schöne Kreuzfragen gestellt werden. Willst du die Prüfer in die Richtung Wasserfall steuern, dann würde ich das auch so machen. 

Die Projektdokumentation soll ja primär dein Vorgehen dokumentieren und nicht das Perfekte Wasser-Fall Modell nachspielen. Gehe daher mehr auf die Inhalte ein, als auf das Model selber. 

Insbesondere die erste Phase ist wichtig und sollte einen wesentlichen Teil deiner Doku ausmachen.

Eine Kosten Nutzen Analyse in der Planung z.B. , eine Planung des kritischen Pfades der Umsetzung, bewusst zurückgestellte Lücken, die man bereits vor der Umsetzung sieht, aber nicht als Teil des Projektes definiert hat.

[Rienne]

Hey,

mal als kleine Verständnisfrage: Geht es hier tatsächlich um das klassische, statitsche Wasserfallmodell oder willst du für das Projekt schon das erweiterte Wasserfallmodell nutzen? Dort kannst du nämlich auch in vorherige Projektphasen zurückspringen, wenn etwas nicht passt. Das ist übrigens auch das Modell, was uns von den Lehrern und Prüfern unserer IHK immer wieder ans Herz gelegt wurde. Nicht zuletzt, weil zum Beispiel die Projektvorgaben der IHK (feste Bearbeitungszeit, muss alleine durchgeführt werden, eindeutige Abgrenzung, ...) es schwer machen gewisse (gerade agile) Vorgehensmodelle zu nutzen.

Wichtig ist vor allem, dass du begründen kannst, warum du dich wofür entschieden hast. Und es macht nunmal durchaus Sinn Unit-Test durchzuführen. Du kannst zum Beispiel auch sagen, dass du dich am erweiterten Wasserfallmodell orientiert hast, aber die Implementierungs- und Testphase interativ durchgeführt hast (was ja ganz oft der Fall ist in der Softwareentwicklung).