Welche Modelle / Vorgehensmodelle heute zeitgemäß in der Softwareentwicklung?

[DennisXX]

Hi Folks !

Früher war ja eindeutig das Wasserfallmodell der Standard schlechthin, aber angeblich soll dieses inzwischen deutlich veraltet sein.

Was mir jetzt speziell in Bezug auf agile Softwareentwicklung einfällt ist daß ein Softwareprojekt iterativ in mehrere kleinere Wasserfälle oder Wassermodelle aufgeteilt werden könnte.

Gibt es außer dem V-Modell (wenn dieses denn heute tatsächlich zeitgemäß ist) noch andere Modelle im Rahmen der Softwareentwicklung, die quasi das Non-Plus-Ultra sind?

Greetz

Dennis

[flashpixx]

siehe V-Modell (Entwicklungsstandard) speziell V-Modell-XT und Modellgetriebene Softwareentwicklung

[Joey P]

also flashpixx ich hab heut schon einige antworten von dir gesehen und ich muss über deine überaus enorme hilfsbereitschaft staunen...

Also ich hab gerade heute meine Prüfung in Softwaretechnik gehabt daher hab ich noch paar dinge im kopf...

also das V- Modell wird heute noch verwendet z.B. wann immer irgendein Bundesamt irgendein Software Projekt hat wird das V- Modell sogar vorgeschrieben...bin mir jetzt net sicher ob dich tatsächlich noch das V- Modell 97 oder das V- Modell XT verwenden...

Wasserfallmodell haben wir auch durchgenommen, allerdings denke ich dass es nicht sehr oft verwendet wird, weil das Wasserfallmodell so wie es ist einfach nicht funktioniert...

es gibt ein Spiralmodell, dazu kann ich allerdings nicht viel sagen ausser dass es aus 4 Phasen besteht, die nacheinander immer wieder durchlaufen werden. Nach jeden durchlauf entsteht ein Produkt, das auf dem Produkt des vorherigen durchlaufs aufbaut und als Grundlage für das Produkt des nächsten Durchlaufs dient...aber am besten googlest du da selber mal danach...

Was Agile Modelle angeht da gibt es Extreme Programming, Scrum, Crystal..........und noch mehr.....

Extreme Programming (XP) wird selten als eigenständige Methode verwendet sondern meistens fließen elemente aus XP in andere agile Modelle ein.....

Scrum hingegen wird recht oft verwendet (ist auch das Modell das mich am meisten fasziniert)

da kann man sogar ein Zertifikat machen als "Zertifizierter Scrum Master"

[flashpixx]

also flashpixx ich hab heut schon einige antworten von dir gesehen und ich muss über deine überaus enorme hilfsbereitschaft staunen...

Danke dafür

Scrum hingegen wird recht oft verwendet (ist auch das Modell das mich am meisten fasziniert)

da kann man sogar ein Zertifikat machen als "Zertifizierter Scrum Master"

Man sollte alle Modellansätze durchaus auch sehr kritisch sehen z.B. wie Scrum

Zu den weiteren Aufgaben eines Entwicklungsteams zählt die Schätzung des Umfangs einer jeden User Story (im Estimation Meeting) sowie das Herunterbrechen der für einen Sprint ausgewählten User Stories in technische Arbeitsschritte (so genannte Tasks), deren Bearbeitung in der Regel nicht länger als einen Tag dauert.

Alleine dieses ist vielleicht theoretisch möglich, praktisch wird es aber immer wieder Probleme geben, bei denen Lösungen nicht innerhalb von einem Tag erarbeitet werden können und nicht jedes Problem ist so zerlegbar, dass man daraus einzelne Tasks mit jeweils einem Tag Arbeitszeit machen kann.

In analoger Weise liegt die Einschätzung der Tasks und der Zeit, die dafür nötig ist von dem Erfahrungswert des jeweiligen Entwicklers ab. Ein erfahrener Entwickler kann eine Problemstellung schnell mit hoher Qualität umsetzen, ein Berufsanfänger wird dafür mehr Zeit benötigen und die Qualität wird auch unterschiedlich sein.

Modelle zu entwerfen ist ein wichtiges Mittel im Designprozess, aber auch in jedem Designprozess muss die Frage gestellt werden, ob ein solcher Ansatz zum Ziel führt. Man kann mit einem solchen System auch sehr viel Zeit in der Planung / Meetings verbringen ohne ein Produkt zu entwickeln. Wenn noch die Akzeptanz der Mitarbeiter darunter leidet, dass Planung von Entwicklung los gekoppelt wird, dann leidet letztendlich das Produkt darunter. Zusätzlich sind fachlich gut ausgebildete und motivierte Entwickler / Designer / Leiter oft in der Lage ein Projekt auch ohne Modell zur vollen Zufriedenheit umzusetzen. Fehlerhaftes Management kann man nicht durch solche Tools kompensieren, es liegt letztendlich in der richtigen Vernetzung von allen (menschlichen & technischen) Komponenten.

[Joey P]

Zusätzlich sind fachlich gut ausgebildete und motivierte Entwickler / Designer / Leiter oft in der Lage ein Projekt auch ohne Modell zur vollen Zufriedenheit umzusetzen.

Wie soll ich das verstehen Code & Fix oder was? wenn es ein größeres Projekt ist können die Entwickler/ Designer/ Leiter noch so gut sein, die sache wird schief gehen...garantiert...

[flashpixx]

Wie soll ich das verstehen Code & Fix oder was?

Ein Modell ist ein "beschränktes Bild der Realität", welches die Informationen enthält, die für die Lösung des Problems wichtig sind. Wenn heute von Modellen gesprochen wird, werden damit oft Diagramme & Tools zur Modellierung verbunden. In vielen Fällen liegt das Problem eben schon im Modell, da es zu beschränkt ist und eben relevante Teile nicht abbildet. Die Modellentwicklung wird nicht durch das Tool bestimmt, sondern durch die Entwickler / Designer etc. die durch Erfahrungen eben eine höchst abstrakte Sichtweise haben. Man kann ein unvollständiges Modell nicht durch Flickenschusterei korrigieren, sondern man muss von Anfang an das Modell so universell wie möglich gestalten und dazu muss man eben auf das Fachwissen der Entwickler bauen. Die Darstellung und Koordination eines solchen Modells über verschiedene Personen / Arbeitsgruppen ist ein anderes Thema. Der entscheidende Punkt ist, dass die Problemstellung möglichst universell abstrakt formuliert werden kann, damit man später eine Lösungsstrategie entwickeln kann und hier müssen alle Bereiche das Fachwissen beisteuern.

[Joey P]

Nun das erklärt aber nicht die Aussage, dass "gut ausgebildete Entwickler [...] ohne Modell zur vollen Zufriedenheit umsetzen"

[flashpixx]

Ich denke wir müssen erst einmal definieren was das Modell ist, ich gehe davon aus, dass viele ein Modell so sehen, dass es irgendeine hübsche Graphik in einer Projektmanagementsoftware ist, in der entsprechende Personen eine Problemstellung beschreiben, validieren und umsetzen.

Für mich ist ein Modell eine abstrakte Beschreibung des Problems mit einer entsprechenden Lösungsstrategie, wobei ich diese nicht zwingend zu Papier bringen muss. Das "ohne Modell" würde ich eher als "ohne schriftliches Modell" formulieren.

[lilith2k3]

Es ist schwer, dazu eine gute Antwort zu geben.

Zwar gibt es selbstredend viele weitere, Alternativen zu dem unflexiblen Wasserfallmodell; allerdings sind -wie überall- Theorie und Praxis zwei verschiedene Paar Schuhe.

daß ein Softwareprojekt iterativ in mehrere kleinere Wasserfälle oder Wassermodelle aufgeteilt werden könnte.

Das ist ein falsches Bild: Das Bild vom Wasserfall suggeriert eine einzige Entwicklungsrichtung; nämlich: nach vorn. Tatsächlich beruhen die modernen Entwicklungstechniken eben nicht auf einem eindimensionalen Verstädnis von Entwicklung. Zwar schreitet die Entwicklungszeit linear voran; mit gleichem Recht kann man das von einem Projekt nicht unbedingt sagen. Da gibt es ein Vor, ein Zurück, Seitenzweig auf, Seitenzweig zu etc.

In der Praxis findet man eine Mischung aus Agile, Scrum, V-Modell und irgendwo dazwischen.

[Joey P]

Wenn man bedenkt dass in der Praxis der Kunde immer wieder mit neuen Ideen kommt funktioniert das Wasserfallmodell schlichtweg nicht, weil es nicht vorgesehen ist aus der z.B. Systemtest Phase nochmal zurück zu springen...

Das "ohne Modell" würde ich eher als "ohne schriftliches Modell" formulieren.

ok, so wie du das jetzt beschrieben hast stimme ich dir zu

Aber es ist durchaus wahr, Theorie und Praxis sind 2 Paar Schuhe...

[flashpixx]

Wenn man bedenkt dass in der Praxis der Kunde immer wieder mit neuen Ideen kommt funktioniert das Wasserfallmodell schlichtweg nicht, weil es nicht vorgesehen ist aus der z.B. Systemtest Phase nochmal zurück zu springen...

Naja nicht nur der Kunde, sondern oft ergibt sich aus dem Problem noch mal eine Neu- bzw. Umstrukturierung des Plans und dann ist das Wasserfallmodell durchaus sehr unflexibel, ob da Scrum als System besser ist, würde ich auch etwas kritisch sehen.

Aber es ist durchaus wahr, Theorie und Praxis sind 2 Paar Schuhe...

Natürlich, obwohl ich denke, wenn man wirklich das Problem richtig abstrakt und vollständig formuliert hat und dann die technische Spezifikation möglichst universell hält, dann kann man auf Änderungen durchaus flexibel mit recht wenig Aufwand reagieren. Ich sehe häufig, dass die Problemstellung schon nur "schnell" hingeklatscht wird, d.h. hier wird Zeit eingespart, was aber letztendlich dann zu Mehraufwand bei der Entwicklung führt, weil man bei entsprechenden Änderungen wieder das Modell und damit den Entwicklungsprozess verändern muss. Gerade in das erste Modelldesign muss man eben Zeit, Erfahrung und Know-How hineinstecken, damit man hier umfangreich das Problem abbilden kann.

[Joey P]

ob da Scrum als System besser ist, würde ich auch etwas kritisch sehen.

übernächstes Semester muss ich ne Projektarbeit machen und da hatte ich vor Scrum als Modell vorzuschlagen...dann berichte ich wie es gelaufen ist

[flashpixx]

Vielleicht kannst Du ja die Arbeit online Stellen, ich fwürde mich darüber jedenfalls freuen

[Joey P]

Vielleicht kannst Du ja die Arbeit online Stellen, ich fwürde mich darüber jedenfalls freuen

Ja werd ich machen...ich weiß nur noch nicht was ich machen werde...es stehen ja Projekte zur Auswahl...manche gibt es jedes Jahr und manche wechseln weil sie von firmen kommen...dieses Jahr gab es paar interessante Projekte...ich schätze ich würde mich sehr für die Schach Engine interessieren...

[T3D]

@flashpixx: nu weis ich warum du mit mir vor 2 Tagen darueber diskutiert hattest

übernächstes Semester muss ich ne Projektarbeit machen und da hatte ich vor Scrum als Modell vorzuschlagen...dann berichte ich wie es gelaufen ist

Ich moecht meine Bachelorarbeit in die Richtung schreiben, brauch eigentlich nur noch die passende Firma dazu. Eventuell koennen wir uns ja austauschen wenn es soweit ist.

Unser Prof fuer Projektmanagement konnt uns in die richtung leider nich viel beibringen da er von den ganzen agilen Methoden absolut keine Ahnung hatte. Hab ihn dann ma mein Buch ueber Scrum ausgeliehn und nun issa begeistert

[Joey P]

Das Thema ist jetzt über ein Jahr her ich hatte ja gesagt ich berichte wie es mit dem Projekt gelaufen ist. Es waren übrigens 2 Projekte mit 2 unterschiedlichen teams.

Also wenn man softwaretechnik aus der Vorlesung kennt macht man sich ein Bild wie es so abläuft, wenn man es jedoch anwendet läuft es nicht immer nach plan...so viel zu "theorie und Praxis" im einen Team hatten wir scrum verwendet zwar war das grundgerüst das von scrum wir hatten die rollenverteilung auch wenn der product owner und scrum master mit entwickeln mussten da wir ja nur ein kleines Team waren, was ja im scrum ja nicht so vorgesehen ist...

Wir hatten auch für einen product back Log gesorgt aber es kam trotzdem immer wieder mal vor dass es hieß mach mal schnell das und das weil wichtig auch wenn es nicht geplant war, also es wurde (und konnte auch nicht immer) strickt nach plan vorgegangen werden...so viel dazu letzten Endes war es eben UNSER scrum

[lilith2k3]

Wie wäre es mit Kanban ?

[Joey P]

Wäre durchaus auch ne Möglichkeit ich will auch nicht bestreiten dass es noch unzählige andere modelle gibt aber wenn die Zeit für das Projekt an sich schon sehr beschränkt ist muss man eben das nehmen was man zumindest schon halbwegs kann statt sich auch noch mit einem Modell auseinander setzen zu müssen das man überhaupt nicht kennt...

[lilith2k3]

War nur insodern ein Gedanke, da Kanban recht "locker" ist, und man bequem auch Scrum draus machen kann, ohne den ganzen "Firlefanz"

[Joey P]

Danke für den Tipp ich werd's mir bei Gelegenheit mal anschauen es stehen ja noch einige Projekte an