Jump to content
Melde dich an, um diesem Inhalt zu folgen  
Gast newnils

Unit-Tests im Wasserfallmodell

Empfohlene Beiträge

Gast newnils

Hallo,

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

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

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 von kylt

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
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 von newnils

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
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.

 

 

 

 

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
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. 

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
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?

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

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.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

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

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Nimm an der Diskussion teil

Du kannst jetzt hier posten und Dich später registrieren. Wenn Du bereits über eine Konto verfügst, melde Dich jetzt an, um mit Deinem Konto zu posten.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Clear editor

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

Melde dich an, um diesem Inhalt zu folgen  

Fachinformatiker.de, 2019 SE Internet Services

fidelogo_small.png

if_icon-6-mail-envelope-closed_314900.pnSchicken Sie uns eine Nachricht!

Fachinformatiker.de ist die größte IT-Community
rund um Ausbildung, Job, Weiterbildung für IT-Fachkräfte.

Fachinformatiker.de App


Get it on Google Play

Kontakt

Hier werben?
Oder senden Sie eine E-Mail an

Social media u. feeds

Jobboard für Fachinformatiker und IT-Fachkräfte

×
×
  • Neu erstellen...

Wichtige Information

Fachinformatiker.de verwendet Cookies. Mehr dazu in unserer Datenschutzerklärung