Laden...

Beispiel für Software Engineering Prozess, bei dem erst modelliert und erst danach programmiert wird

Erstellt von .Kai vor 10 Jahren Letzter Beitrag vor 10 Jahren 4.830 Views
.Kai Themenstarter:in
1.130 Beiträge seit 2005
vor 10 Jahren
Beispiel für Software Engineering Prozess, bei dem erst modelliert und erst danach programmiert wird

Hallo zusammen,

ich bin auf der Suche nach Beispielen und Vorgehensweisen für einen Software Engineering Prozess.

Man stelle sich folgende Situation vor:

Ein Team aus 5 Entwicklern steht vor der Aufgabe eine Software zu entwickeln. Die Anforderungen an die Software wurden zunächst in einem Lasten- später in einem Pflichtenheft niedergeschrieben. Aufgabe des Teams ist es nun die Software zu entwerfen, zunächst ohne Code sondern nur mit Stift, Papier und einem Whiteboard. Wie werden nun Klassen erstellt, welche Methoden soll es geben , wie sieht die Architektur aus, welche Schichten gibt es, usw. usw. All das sollte nach Möglichkeit vor dem eigentlichen programmieren geplant werden.

Wie geht ihr in einem solchen Fall vor, welche Schritte bearbeitet ihr? Verwendet Ihr User Stories? Gibt es bessere Vorgehensweisen als User Stories? Werden UML oder Interaktions-Diagramme verwendet?

Beispiele, Videos, Links, Stichwörter - Mir würde alles helfen.

16.807 Beiträge seit 2008
vor 10 Jahren

Angenommen Du fragst dieses 5er Team, wie es bei Software A vorgegangen ist: ich bezweifel, dass es bei Software B, auch wenn es komplett identisch wär, genau so vorgehen wird.

Das ist einfach eine Frage, die man niemals pauschal und genau oder gar gleichbleibend beantworten kann.
Es liegt immer an der Software an sich, an der Programmiersprache, an der Technologie und vor allem an den Team-Mitgliedern, finanziellen Gegebenheiten und an den Vorgesetzten.
Die ganzen Ansätze wie Agile Softwareentwicklung, RAP oder Extreme Programming: im seltensten Falle wird das doch so umgesetzt, wie es gedacht war.
Auch die Idee mit dem Klassendesign auf Papier ist schön; aber in der Realität - behaupte ich - unterscheidet sich der Aufbau bzw. die Architektur und die Klassen vom Plan.

* es wird immer die Situation geben, dass das Lasten-/Pflichtenheft nachgebesser wird oder werden muss - vor allem bei schwierigen Kunden, die sich nicht wirklich entscheiden können.
Fällt mir spontan folgendes Bild ein: Anforderungen an das Design einer Schaukel (Cartoon, englisch) (ich verlink es mit Absicht).
* hinzu kommt Zeitdruck, weswegen man immer den Druck im Nacken hat dann doch etwas unsauber zu arbeiten bzw. dazu neigt

Man kann auch nicht sagen, ob irgendetwas irgendwie mehr passt; das muss ja jeder selbst für sich herausfinden. Oft passt Methoda A gar nicht zu Software A aber zu Software B; oder vielleicht bietet eine Technologie bzw. dessen IDE ganz andere Möglichkeiten. Hinzu kommt, dass man zum Beispiel ein Tool gerne einsetzen möchte, weil es sich als nützlich herausgestellt hat, aber für die Vorgesetzten (vllt auch weil sie den Mehrwert nicht erkennen) aufgrund der Kosten nicht nehmen wollen.

Fazit meinerseits: Google-Suche nach life the universe and everything

C
2.121 Beiträge seit 2010
vor 10 Jahren

Ich denke auch, ein 100% pauschales Vorgehen ist nicht sinnvoll. Das hängt immer von den Anforderungen ab.
Gibt es viele kleinere Abläufe die alle (oder viele) relativ kurz und schlüssig sind? Oder hängt alles voneinander ab?
Gibt es viele oder nur wenige wichtige Klassen die sich durch das gesamte Projekt ziehen?
Die zentralen wichtigen Klassen sollten natürlich gescheit geplant werden. Die zu ändern könnte einen großen Teil des Projekts verändern.
Andere Klassen sind so klein oder werden so "lokal" eingesetzt dass ich persönlich dafür erst mal keinen Stift in die Hand nehmen würde.

Ich bin gespannt was hier noch alles für Antworten kommen.

49.485 Beiträge seit 2005
vor 10 Jahren

Hallo .Kai,

ich sehe das nicht so pessimistisch, wie die anderen. Zwar ist man nach einem Projekt immer schlauer und hat Idee, wie man es beim nächsten Mal besser machen kann, aber natürlich sollte man sich trotzdem vor dem Projekt überlegen, wie man für dieses Projekt vorgehen will.

Die Frage ist natürlich, wie es kommt, dass ihr euch im Angesicht der Konjunktur von agilem Projektmanagement und extreme Programming für ein recht klassisches Vorgehen, wie du es skizziert hast, entschieden habt.

Nichtsdestotrotz stehen auch bei agilen Techniken Usecases hoch im Kurs. Und ich denke auch für eher klassischen Entwurf kann man daraus viel ziehen. Usecases eigenen sich deshalb recht gut zur Kommunikation mit dem Kunden, weil sie aus seiner Welt stammen und er sie wirklich verstehen kann.

Nun schreibst du aber, dass ihr schon ein Lasten- bzw. Pflichtenheft (was aus meiner Sicht exakt das gleiche ist, für dich anscheinen aber nicht) habt. Dann müsste sich der Entwurf m.E. auch genau darauf stützen. Denn wenn du oder der Kunde jetzt noch Usecases schreibt, dann besteht ja immer die Gefahr der Abweichung vom Lasten-/Pflichtenheft und da letztere üblicherweise Vertragsbestandteil sind, sind sie im Zweifelsfall maßgeblich.

Was du beschreibst, erinnert mich bis zu einem gewissen Maße an Domain-Driven Design, nur eben ohne die agilen Techniken. Allerdings ist das Wasserfallmodell, das die zu bearbeitenden Schritte oder besser Phasen beschreibt und das hinter deiner Beschreibung durchscheint, sowieso schon ziemliche lange out.

Was die Arten der Diagramme angeht, bietet UML ja einen reichen Fundus. Der Frage, welche Diagrammarten ihr dabei wählt, kann und will ich nicht vorgreifen. Ich bin mir allerdings sicher, dass wenn man das System vor dem Programmieren komplett beschreiben will, so dass die Programmierer die vollständige Anwendung nur aus dem Ergebnis des Entwurfs (also eben den Diagrammen) programmieren können, man nicht nur mit zwei oder drei Diagrammtypen hinkommen wird. Dazu sind die zu beschreibenden Aspekte doch zu vielfältig. Oder man braucht eben neben den Diagrammen doch wieder ein gerüttelt Maß an (technischer) Prosa.

herbivore

PS: Ich habe gerade ein Buch von Michael Feathers gelesen, der sagt, eine Software-Architektur ist nur dann gut, wenn sie testbar ist. Für ihn ist Testbarkeit das wesentliche Kriterium für die Qualität von Software-Architektur. Wenn man dem folgt, dann ist testdriven Design die logische Konsequenz. Ich bin mir allerdings hinsichtlich des Aufwands für testdriven Design nicht sicher. Während der Implementierungsphase ist es schon deutlich aufwändiger. Neulich habe ich mal angefangen, eine Übungsaufgabe testdriven zu lösen. Obwohl ich den Sinn einsehen, war es doch recht zäh. Allerdings bin ich dabei noch nicht so weit gekommen, die Früchte zu ernten. Und habee eben deshalb noch nicht herausgefunden, ob man in dem Moment, wo man die letzte Codezeile geschrieben hat, automatisch ein quasi fehlerfreies System hat. Oder zumindest ein System, bei dem man die verbleibenden Fehler schnell und mühelos entfernen kann.

.Kai Themenstarter:in
1.130 Beiträge seit 2005
vor 10 Jahren

Hallo zusammen,

vielen Dank für die vielen Antworten. Allerdings fürchte ich, dass ich mich ein wenig zu unklar ausgedrückt habe.

Die von mir angesprochene Vorgehensweise war lediglich ein Beispiel. Mich interessiert im Allgemeinen welche Vorgehensweise ihr beim Entwickeln verwendet, welche Tools werden eingesetzt, usw.

Wie würdet ihr z.B. einen Sprint in einem Agilen Prozess am Whiteboard planen, wie würdet Ihr die einzelnen Module am Whiteboard planen, usw. usw.

Im Prinzip weiß ich gar nicht genau was ich suche. Idealerweise würde ich ein Team gerne beobachten wie es eine Software entwickelt, wie Besprechungen geführt werden, wie die Architektur geplant wird, usw. Vielleicht gibt es so etwas als Video?

Sefan Lieser und Ralf Westphal haben so etwas mal aufgenommen:
Softwareentwurf als Video – Ein Experiment

Im Prinzip geht das schon in die richtige Richtung, aber vielleicht gibt es ja noch mehr....

Schwierig zu verstehen, ich weiß, aber mich interessiert das Vorgehen, weil ich einfach mal einen Blick über den Tellerrand wagen möchte. Oft ist es ja so, dass man einen gewissen Prozess hat, ob Agil oder nicht ist ja zunächst egal, und diesen so verwendet wenn er gut funktioniert. Sicherlich gibt es aber immer etwas Besseres oder Anderes und genau das interessiert mich.

@herbivore:
Übrigens gibt es tatsächlich Branchen, die einen gewissen Prozess erfordern, wie z.B. die Food oder Pharma Branche. Sobald ein validiertes Umfeld vorliegt, sind Agile Prozesse nicht so einfach umzusetzen, aber das nur am Rand.

49.485 Beiträge seit 2005
vor 10 Jahren

Hallo .Kai,

ich habe mich bemüht, deine Frage ernsthaft zu beantworten. Aber die Konkretisierung klingt mir jetzt doch ein bisschen so, als wärst du, sorry, nur zu faul, verschiedene Bücher über Softwareentwicklung/-architektur durchzulesen und dir die Sachen rauszupicken, die du nützlich findest.

Das Problem bei Softwareentwicklung ist doch, dass fast jeder eine anderen Vorgehensweise verwendet. Und das zudem eine Vorgehensweise, die bei Software A, Projekt A und Team A gut funktioniert, bei Software B, Projekt B und Team B möglicherweise vollkommen ungeeignet oder zumindest suboptimal ist (also genau das, was die beiden anderen von Anfang an geschrieben hatten). Deshalb ist es auch sinnlos, wenn hier alle schreiben, wie sie es machen. Du musst eh selber auswählen. Das kannst du aber auch, wenn du dir das schon fertig geschriebene vornimmst, also insbesondere die genannten Bücher. Das müssen wir hier nicht noch mal alles neu aufschreiben. Mal abgesehen davon, dass man das in einem Forum ohnehin nur sehr oberflächlich und gleichzeitig recht zufällig könnte. Selbst wenn die Leute hier nur ihre besten Tipps aufschreiben würde, heißt das noch lange nicht, dass die in einem Kontext auch passen und funktionieren.

herbivore

.Kai Themenstarter:in
1.130 Beiträge seit 2005
vor 10 Jahren

Hallo herbivore,

ich habe mich bemüht, deine Frage ernsthaft zu beantworten. Aber die Konkretisierung klingt mir jetzt doch ein bisschen so, als wärst du, sorry, nur zu faul, verschiedene Bücher über Softwareentwicklung/-architektur durchzulesen und dir die Sachen rauszupicken, die du nützlich findest.

Interessant, wie negativ doch manche Themen / Anfragen aufgefasst werden können.

Tatsächlich geht es mir nicht darum irgendwie über einen kürzeren Weg an Informationen zu kommen. Hilfreich wäre z.B. folgende Antwort gewesen, die ich jetzt aus den bisherigen Antworten abgeleitet:

Wir verwenden Domain Driven Design und im Rahmen der Planung eines Sprints sitzen wir zusammen am Whiteboard und planen die Architektur, usw. usw.. Im Video XY gibt es dazu einen ganz guten Einblick. Ansonsten kann ich Bücher zu dem Thema empfehlen.

Somit wäre Domain Driven Design doch schon mal ein super Stichwort gewesen, sodass man zumindest schon mal nach Büchern oder Videos schauen kann.

Es geht mir nicht darum einen Entwicklungsprozess in allen Feinheiten präsentiert zu bekommen und eigentlich dachte ich, dass ich das auch so deutlich gemacht hätte. Für mich geht es in einem Forum hauptsächlich um Hinweise zur Lösung, also hauptsächlich um Stichworte oder Links. Unterstellt zu bekommen, ich wäre zu faul, nur weil ich eine allgemeine Frage gestellt habe, halte ich, sorry, in diesem Zusammenhang für daneben.

PS: Ich habe gerade ein Buch von Michael Feathers gelesen, der sagt, eine Software-Architektur ist nur dann gut, wenn sie testbar ist. [...]

Wenn ich mich richtig erinnere, dann war das P.S. in der ersten Version der Antwort noch nicht vorhanden. Genau so etwas hatte ich mir vorgestellt, herbivore. Der Name reicht um nach Bücher zu schauen, die vielleicht von Interesse wären. Danke!

Hinweis von herbivore vor 10 Jahren

Somit wäre Domain Driven Design doch schon mal ein super Stichwort gewesen "Wäre gewesen" erzeugt einen falschen Eindruck, denn das Stichwort wurde von mir tatsächlich und vorher genannt.

Ansonsten habe ich das erstmal überschlafen, und mir nochmal mit ausreichend Abstand angesehen. Doch es bleibt dabei: Der Verdacht der Faulheit drängt sich bei deiner Nachfrage auf, denn wenn man wissen will, wie andere Teams arbeiten, gibt es wahrlich genug Literatur und andere Quellen, die man mit einer passenden Suche leicht findet. Auch (weitere) Stichworte findet man leicht, wenn man sucht. Damit muss man kein Forum beschäftigen. Also nochmal in Kürze: Eingangsfrage ok und wurde von mir auch ausführlich und konkret beantwortet, Nachfrage nicht ok, deshalb die Kritik. Solltest du damit nicht einverstanden sein, lass es uns per PM klären.