Laden...

Verbreitete Modelle der Softwareentwicklung?

Erstellt von voodoo44 vor 12 Jahren Letzter Beitrag vor 12 Jahren 3.363 Views
V
voodoo44 Themenstarter:in
82 Beiträge seit 2008
vor 12 Jahren
Verbreitete Modelle der Softwareentwicklung?

Hallo liebe User,

ich muss euch mal wieder stören. Wie schonmal hier im Forum "breitgetreten" schreibe ich gerade an meiner Abschlussarbeit für's Studium. Thematisch beschäftige ich mich dabei mit der Continuous Integration und dazugehörigen Tools. Mehr kann und will ich da (noch) nicht verraten.

Nun zum Punkt, warum ich auf euch zukomme:
Als (in meinen Augen) qualitativ auf hohem Niveau fungierendes Forum habt ihr hier User, die viel Wissen aus der aktuellen Praxis der Softwareentwicklung und des -Engineering hier einbringen, sodass ich denke, dass ihr neben Büchern die richtige Anlaufstelle seid.

Heute möchte ich von euch gern wissen, ob ihr nähere Informationen zu den "Vorgehensmodellen" in der Softwareentwicklung aus der Praxis nennen könnt.

Es ist mir klar, dass es wahrscheinlich wenige Firmen gibt, die nach den Modellen aus dem Lehrbuch entwickeln und dass hier und da jede Firma ihren Entwicklungsprozess selbstständig an ihre Bedürfnisse anpasst.
Weiterhin ist mir bewusst, dass wahrscheinlich diese ganzen Modelle wie das "Wasserfallmodell" in der Zwischenzeit nur mehr im Lehrbuch auftauchen (Stichwort: agile Softwareentwicklung, die immer mehr im kommen ist - siehe CI).

Könnt ihr vielleicht mal ein wenig "aus dem Nähkästchen" plaudern oder mir ein paar Statistiken zukommen lassen (sofern vorhanden), wie ihr in euren Firmen Software entwickelt? Wie ist euer Vorgehensmodell dabei? Oder habt ihr gar keins?

In der Hoffnung auf ein paar brauchbare Antworten

Viele Grüße,

Tom

C
2.121 Beiträge seit 2010
vor 12 Jahren

"Agil" ist ein Stichwort der letzten Zeit.
Bei Projekten mit Kundeneinfluss dürfte das sowieso schon immer eine sinnvolle Variante gewesen sein. Die besten Vorschriften bringen einem nichts, wenn dann am Ende nichts brauchbares rauskommt. Daher dürfte es kein Felher sein, wenn man das tut was gerade nötig ist. Egal wie mans nennt 😉

69 Beiträge seit 2009
vor 12 Jahren

Daher dürfte es kein Felher sein, wenn man das tut was gerade nötig ist. Egal wie mans nennt 😉

So läuft das auch bei uns. Ob man das jetzt im akademischen Sinne "agil" nennen kann oder nicht, mag ich nicht festlegen. Wir entwickeln hier in einem kleinen Team (5-7 Entwickler) und es gibt letztendlich kein formal vorgeschriebenes Vorgehensmodell. Wir haben eine relativ alte Software-Suite im Einsatz (seit etwa 10 Jahren), die permanent am Leben gehalten und erweitert werden muss und planen/entwickeln seit einiger Zeit an einer Neuentwicklung, die sie "demnächst" ablösen soll. Ich weiss nicht, ob dir das wirklich weiterhilft, aber praktisch gelebt wird das bei uns so (die Punkte sind nach Priorität sortiert, der wichtigste oben):

1.) Wenn ein Kunde eine Anforderung hat, für die er auch bezahlen mag, wird das mit Priorität so quick wie möglich & dirty wie nötig umgesetzt ("Vergiss die Wartbarkeit der alten Software, bald machen wir eh alles neu und besser")
2.) Wird ein Bug bekannt, wird er zügig behoben. Oft genug notdürftig mit irgendwelchen hart-kodierten Hacks, bei denen sich einem eigentlich die Zehennägel hochrollen sollten - aber Hauptsache, es geht wieder sigh
3.) Gibt es Anforderungen, die nicht direkt bezahlt werden, kommen die auf eine Liste und werden bei Zeiten umgesetzt. Diese Liste ist ziemlich lang, und nur die allerkleinsten Änderungen kommen immer mal wieder in die Releases.
4.) Tests (im Sinne von organisierten Unit- oder Integrationstests unter Beteiligung dedizierter Tester) gibt es aus Zeit- und Personalmangel selten bis gar nicht. Meistens "testet" der zuständige Entwickler in der IDE, der Rest wird beim Kunden gemacht.
5.) Falls neben den Punkten 1-4 (und der entsprechenden Dokumentation) Zeit bleibt, wird an der Konzeption der neuen Software und deren Umsetzung gearbeitet - leider sehr oft unterbrochen durch die Punkte 1-4 und daher wenig effektiv ...

Das ist also das "Modell", nach dem bei uns entwickelt wird. Nachdem ich bereits zuvor bei zwei anderen Firmen ähnliche Erfahrungen gesammelt habe und von dem was ich so höre/lese, vermute ich stark, dass das auch als 'verbreitetes Modell' durchgehen kann. Die Praxis weicht eben oft vom akademischen Ideal ab, um den Kunden/Chef schnell zufrieden zu stellen. Und die Hoffnung bleibt, dass man in der neuen Version alles organisierter, ordentlicher und damit besser machen kann ...

Vielleicht noch als Schlusswort: Auch wenn das hier vielleicht (für dein Anliegen) etwas negativ klingen mag, macht mir die Arbeit doch Spass und ist ziemlich abwechslungsreich. Es ist zwar bei Zeiten mal etwas stressig und man muss sich des Öfteren auf die Finger beissen, weil man genau weiss, dass man gerade mal wieder bewusst gegen X Regeln der professionellen Softwareentwicklung verstösst, trotzdem lernt man eine Menge dabei. Und letztendlich funktioniert das System irgendwie, wir bekommen es immer irgendwie hin, unsere Aufgaben zu erledigen und die Anforderungen zu erfüllen.

Ich hoffe, es gibt noch weitere Antworten, denn mich interessiert es auch sehr, wie in anderen Unternehmen bei der Softwareentwicklung praktisch vorgegangen wird. Ansonsten: Viel Erfolg bei deiner Abschlussarbeit 😃

C
2.121 Beiträge seit 2010
vor 12 Jahren

Was jannemann13 da schreibt dürfte meistens die praktische Umsetzung sein. Das "immer irgendwie hinkriegen" ist doch das hauptsächliche Ziel.
Ich finde es sowieso schade wenn versucht wird, alles mit möglichst viele Regeln zu versehen. Die passen auf einen Teil der Arbeit, nämlich den Teil den der Autor der Regeln gerade in Gedanken hatte. Auf den anderen Teil passen sie nicht und machen somit die Arbeit als ganzes komplizierter.
Da stellt man einen Satz Vorschriften auf, gibt dem noch einen super klingenden Namen und entweder verbaut man sich damit seinen Erfolg (weil sich das was zu tun ist nunmal nicht daran hält), oder man tut halt doch das momentan nötige. In beiden Fällen war die Vorschrift umsonst 😉

Ich kenne mit mit solchen Modellen ehrlich gesagt kein bisschen aus. Aber wenn in einem Modell nicht drin steht "Falls es Änderungen im Plan gibt, sollten diese schnell berücksichtigt werden", kann so ein Modell nichts taugen. So etwas finde ich dann aber schon zu banal, eigentlich sollte das auch ohne Regeln klar sein.

Ja das hilft dem Fragesteller kein bisschen, merk ich auch gerade. Aber jetzt hab ichs schon geschrieben 😉
Und vielleicht sind das ja trotzdem die praktischen Erfahrungen die er sich wünscht.

B
48 Beiträge seit 2010
vor 12 Jahren

jannemann13 beschreibt schon sehr schön wie es wohl wirklich in sehr vielen Firmen abläuft.

Wenn ich sehr sauberen Code schreibe, Pattern verwende und penibel darauf achte gegen keine Prinzipien zu verstoßen, brauche ich drei bis viermal so lang wie für hingerotzen Durchschnittscode. Die Konsequenz ist, dass sich Änderungen und Wartungsarbeiten nicht mehr ganz so schnell und elegant durchführen lassen wie beim durchstylten Traumsystem. In der Summe bin ich trotzdem noch schneller wenn ich häufiger mal ein Auge zudrücke und gegen Lehrbuchmeinungen verstoße.

Ich verstehe die Vorgehensmodelle als hochgradig weltfremd was kleinere Projekte betrifft. Bei Monsterprojekten haben sie sicherlich ihre Daseinsberechtigung, das kann ich nicht beurteilen.

Code den ich zu Hause schreibe könnte man ins Museum stellen so sauber ist er. Auf der Arbeit muss es schnell gehen. Das Ergebnis zählt.

Vielleicht fehlt mir aber auch noch Erfahrung. Ich bin erst 1,5 Jahre "Profi".

G
538 Beiträge seit 2008
vor 12 Jahren

jannemann schreibt vor allem so, als hätte ich auch schon mal in der Firma gearbeitet ...

Der Vorteil der Klugheit liegt darin, dass man sich dumm stellen kann - umgekehrt ist das schon schwieriger (K. Tucholsky)
Das Problem mit Internet-Zitaten ist, dass sie oftmals zu unrecht als authentisch angenommen werden. (K. Adenauer)

V
voodoo44 Themenstarter:in
82 Beiträge seit 2008
vor 12 Jahren

Für mich klingt das bei den meisten ehrlich gesagt nach einer stark abstrahierten Form von "Continuous Integration" (bzw. eben "agil"😉:

Siehe Bild (Anhang, Quelle: http://www.axelirriger.de/blog/2009/01/02/software-deployments-problemflle-der-softwareentwicklung/)

Es geht mir jetzt nicht darum, ob ihr euren Code "Quick and Dirty" mit irgendwelchen hardcodierten Fixes verschandelt, ob ihr mit Pattern arbeitet oder sonstigem - sondern eben um die "Entwicklungsmodelle".

Im Sinne von:
Habt ihr nen Boss, der euch Aufgaben vorsetzt - "implementiere das", die Software soll so und so aussehen (Softwardesign, nicht Oberflähe)? ("Wasserfallmodell"😉; Oder entwickelt sich euer Produkt von Feature zu Feature weiter? (Evolutionsmodell); Alternativ: ihr schreibt euren Code, checkt ihn regelmäßig (mehrmals am Tag ein) und es werden nächtlich neue Varianten mit den Codeänderungen kompiliert (Nightly-Builds); Schreibt ihr ständig Code, checkt ihn ein und prüft bei jeder Änderung ob das neu implementierte funktioniert? (Continuous Integration)?

Ich finde es ein wenig "gemein", dass man hier diese Vorgehensmodelle als "akademischen Quatsch" abtut. Mal ehrlich: hat sich hier im Vorhinein noch NIEMAND mal Gedanken über Klassendesign o.ä. gemacht? Sicher kommt das immer auf die Projektgröße an, aber ein wenig geplant habt ihr alle schon - oder programmiert ihr wirklich einfach "drauf los"?

Danke erstmal soweit für die Erfahrungen - aber wenn jemand noch was zu sagen hat, immer her mit den Statements. Darf auch weiterhin Kritik an meinem "akademischen Quatsch" beinhalten 😛😉

1.820 Beiträge seit 2005
vor 12 Jahren

Hallo!

ich habe mal in einer Firma gearbeitet, in der das Scrum-Model verwendet wurde:
Man traf sich täglich einmal kurz, hat über abgeschlossene Arbeiten berichtet, evtl. kurz Probleme angesprochen und sich dann gegebenenfalls eine neue Aufgabe von der Wand zugeordnet. Die abgeschlossenen Änderungen wurden dabei regelmäßig eingecheckt, so dass sofort ersichtlich wurde, wenn bei einer Änderung ein Problem aufgetreten ist.
Auch Änderungen der Designer konnten sofort getestet werden, bei Problemen hat man schnell Rücksprache gehalten.
Größere Releases wurden automatisch vom Tester grob überprüft.

Da an einem großen Projekt gearbeitet wurde, welches sich in Server-, Client- und Design-Tätigkeiten aufteilen lies, hat das auch super funktioniert.

Aktuell arbeite ich als einziger .NET-Entwickler in einer Firma, da muss man sich schon selber auf die Finger schauen, um ein Problem oder eine Aufgabe "nicht mal eben schnell irgendwie" zu lösen.
Auch hier hilft ein CI-System, um bestimmte Aufgaben zu automatisieren, Änderungen am Quellcode rückverfolgen zu können und gegebenenfalls Code-Richtlinien definieren zu können.

EDIT: Gerade automatisierte Unit-Tests sind hier wichtg, da ja sonst keiner auf den Quellcode schaut bzw. diesen testet.

Nobody is perfect. I'm sad, i'm not nobody 🙁

B
48 Beiträge seit 2010
vor 12 Jahren

Schreibt ihr ständig Code, checkt ihn ein und prüft bei jeder Änderung ob das neu implementierte funktioniert? (Continuous Integration)?

Genauso, ja. Das Projekt ist relativ klein und die Übersetzung dauert nicht lange, so dass quasi alles direkt getestet werden kann.

Ich finde es ein wenig "gemein", dass man hier diese Vorgehensmodelle als "akademischen Quatsch" abtut. Mal ehrlich: hat sich hier im Vorhinein noch NIEMAND mal Gedanken über Klassendesign o.ä. gemacht? Sicher kommt das immer auf die Projektgröße an, aber ein wenig geplant habt ihr alle schon - oder programmiert ihr wirklich einfach "drauf los"?

Ich habe selbst Informatik (Uni) studiert also darf ich darüber lästern 😃

Ja ich programmiere einfach drauf los. Ich wäre bei neuen Projekten mit hunderten Klassen garnicht in der Lage es vorher bis auf Klassenebene zu entwerfen. Das entwickelt sich mit der Zeit. Ich muss "erforschen" was eine gute Lösung ist. Das geht einfach nicht im Vorfeld in irgendeinem albernen UML-Tool.
Naja, nicht ganz. Es geht doch: Genau dann, wenn man etwas sehr Ähnliches schon einmal gemacht hat. Wenn man sich zum Beispiel was die Datenschicht betrifft für ein Repository-Pattern entscheidet weiß man vorher genau, wie es aussieht, dass da eine abstrakte Fabrik sein wird u.s.w.. Aber warum sollte ich es dann noch aufmalen?
Umgegekehrt kaufe ich niemandem ab, dass er so etwas Komplexes, beim ersten mal und ohne vorher etwas ähnliches gemacht zu haben, mit UML entwerfen kann ohne zu erleben wie es sich in Code "anfühlt".

Die Aussagen beziehen sich auf kleinere und mittlere Projekte. Und da halte ich Vorgehensmodelle und Entwurfsphasen für Zeitverschwendung. Ja, akademischen Quatsch.

Code ist der eigentliche Entwurf. Das eigentlich wesentliche.
Unterstützung in Form von Code gibt es auch: Unit-Tests, Frameworks, Dependency-Injection-Container, OR-Mapper wie nHibernate.... Das sind Dinge die wirklich Helfen. Aber kein Klassendiagramm.

C
2.121 Beiträge seit 2010
vor 12 Jahren

Es hängt stark vom Projekt ab, wie man Klassen designt.
Ich behaupte mal dass nicht jedes brauchbar große Projekt hunderte Klassen hat, die an zig Stellen zusammenarbeiten.
Dann kommts auch noch auf die Anforderungen an, ob man anfangs überhaupt schon wirklich so sinnvoll designen kann dass sich nichts mehr ändern wird. Wenn noch keinem genau klar ist was irgendwann mal wirklich rauskommen soll und aus jeder Idee nochmal was konkreteres werden kann, sind Änderungen an der Tagesordnung. Da sitzt man nicht gern umsonst da und designt ein Programm komplett durch, das später keiner so haben will.

Quatsch würd ichs nicht bezeichnen. Aber es wird schon gern Zeit kaputt gemacht in dem Pläne gemacht werden, die später nie aufgehen.
Man macht auch längst nicht alles voll erweiterbar, ins letzte Detail modular, mit sauberen Schnittstellen, konfigurierbar, wiederverwendbar usw... weils später kein Mensch mehr für was anderes brauchen wird.
Und wenn doch, ist man schneller das eine benötigte Stückchen Code anzupacken, als im Voraus schon wochenlang für Eventualitäten investiert zu haben.
Das sind die Erfahrungen die in der Praxis auftreten. Dass man ein bisschen plant ist ok. Aber man will ja auch nicht enttäuscht sein weil mans umsonst gemacht hat.

Drauf los programmieren... ja so etwa 😉
Nee Scherz beiseite, nicht ganz. Aber man muss einfach mal anfangen um den Einstieg zu finden. Wenns dann Formen annimmt und klarer wird, kann mans noch schöner gestalten.

Klassendiagramme macht man ja indirekt schon dadurch dass man eine Klasse codet. Daraus lässt sich dann ein Diagramm erstellen, wenn die sich mal nicht mehr ständig ändert. Aber da brauch ich mich nicht vorher hinsetzen und irgendwas zeichnen oder auf dem Papier erstellen. Überlegungen macht man natürlich. Aber zu sehr ins Detail gehen ist auch hier meistens zu früh, dazu sollte erst mal ein bisschen was stehen.

69 Beiträge seit 2009
vor 12 Jahren

Ich finde es ein wenig "gemein", dass man hier diese Vorgehensmodelle als "akademischen Quatsch" abtut. Mal ehrlich: hat sich hier im Vorhinein noch NIEMAND mal Gedanken über Klassendesign o.ä. gemacht?

Ich tue die Vorgehensmodelle ja nicht generell als Quatsch ab - schliesslich hab ich sie im Studium auch gelernt und ihren (theoretischen) Nutzen auch erkannt. Ich bin auch der Meinung, dass man, wenn man diese Modelle grundsätzlich kennt und versteht, automatisch effektiver entwickelt als wenn nicht. Es ist nur in der beruflichen Praxis oft so, dass es nicht immer leicht zu vermitteln ist, dass es sich später lohnen kann, am Anfang mehr Zeit zu investieren und gründlich zu planen. Besonders Entscheidern, die nicht aus der Entwickler-Praxis kommen, fehlt meiner Erfahrung nach oft das Verständnis dafür - oder mir fehlt das BWL-mässige Verständnis dafür, warum es besser ist, schnell was auf den Markt zu hauen, auch wenns sich später höchstwahrscheinlich rächen wird 😃

Bei mir ist es jedenfalls auch so, wie oben schon jemand geschrieben hat: wenn ich privat etwas programmiere, dann nehme ich mir Zeit, um mir ein für mich optimales Konzept zurechtzulegen und lege extremen Wert darauf, dass ich immer wieder neuere Techniken/Varianten/Konzepte ausprobiere und umsetze. Ist vielleicht auch so eine Art Kompensation zum Beruf, und so verkommt so manches Projekt dann auch gerne mal zum Selbstzweck, weil ich ewig an der "perfekten" Implementierung feile ... aber so bleibt man halbwegs auf dem Laufenden und lernt dazu, auch wenn diese Projekte natürlich deutlich kleiner und isolierter sind als im Job.

Mal ehrlich: hat sich hier im Vorhinein noch NIEMAND mal Gedanken über Klassendesign o.ä. gemacht?

Das ist halt das Problem mit Bestandssoftware - da hat man nun den Salat und muss irgendwie damit zurechtkommen. Ganz frische Projekte quasi auf der grünen Wiese starten, das hab ich eher selten erlebt. Ist natürlich der Traum jedes Entwicklers, mal ein grosses Projekt völlig ohne Einschränkungen und Zeitdruck ganz neu zu entwerfen ...

Habt ihr nen Boss, der euch Aufgaben vorsetzt - "implementiere das", die Software soll so und so aussehen (Softwardesign, nicht Oberflähe)?

Eher so: "Der Kunde hat die und die Anforderungen, hier ist dein Ansprechpartner, denk dir mal was dazu aus und schätz den Aufwand. Oh, und bitte nicht mehr als 15 MT, mehr kriegen wir nicht bezahlt.". Es gibt hier selten konkrete Vorgaben, was das Softwaredesign angeht, dafür sind wir ja hier als Entwickler beschäftigt 😃 Damit läuft es letztendlich wohl in etwa darauf hinaus, was du als Continuous Integration beschreibst.

Das konkrete Vorgehen läuft dann bei uns meist so: Ein Entwickler ist für das neue Feature/die Anforderung zuständig (normalerweise der, der sich am besten im entsprechenden Teil des Systems auskennt). Der werkelt dann eine Weile still vor sich hin und checkt das Ganze ein, wenn er meint, dass er fertig ist. Das wars ... dann wird die Doku (Handbuch, ChangeLog, Entwicklerdoku) aktualisiert, evtl. gibts ne kurze Info an die anderen Entwickler, und dann gehts ab zum Kunden (bei den "wichtigen" Kunden wird vorher schon noch ein kompletter Testlauf gemacht, soweit das möglich ist, bei kleineren Sachen eher nicht). In den folgenden Tagen werden dann äusserst "agil" die auftretenden Bugs behoben, bis das ganze stabil läuft und vom Kunden abgenommen wird.

Überlegungen macht man natürlich. Aber zu sehr ins Detail gehen ist auch hier meistens zu früh, dazu sollte erst mal ein bisschen was stehen.

Das seh ich genau so. Wenn ich eine neue Komponente entwerfe, mache ich mir natürlich vorher einen Plan (nicht formal, eher Notizen/Skizzen auf Papier oder im Kopf, schicke UML-Diagramme mach ich meist nur für Präsentationen oder im Nachhinein für die Doku). Aber sobald dann die erste lauffähige Version steht, habe ich schon wieder eine lange Liste mit Refactorings, die ich gerne durchführen würde, um die Wartbarkeit/Übersichtlichkeit/Erweiterbarkeit/etc. zu erhöhen. Aber die kosten natürlich reichlich Zeit, und dazu kommen meist noch Last-Minute-Änderungen an den Anforderungen, Missverständnisse mit dem Kunden, unbedachte Schnittstellen zu anderen Systemen, etc. Und das nächste Projekt wartet ja auch schon ...

49.485 Beiträge seit 2005
vor 12 Jahren

Hallo voodoo44,

sicher muss man in der Praxis Abstriche gegenüber der reinen Lehre machen. Trotzdem würde ich die These wagen, dass dieser Thread ein zu düsteres Bild zeichnet. Leider haben die einzelnen Autoren nichts oder nicht viel über die Firma bzw. Firmengröße oder Branche geschrieben. Ich denke, davon hängt viel ab.

Bei einer Versicherung, für die ich immer wieder arbeite, läuft es so: Es gibt ein bestehendes Softwaresystem, das ständig an die sich ändernden Rahmenbedingungen (Gesetzesänderungen, Marktveränderungen, Änderungen in der Geschäftspolitik, Erweiterungen oder Änderungen in der Angebotspalette, neue oder veränderte Anforderungen der Anwender) angepasst werden muss. Es gibt ungefähr ein Dutzend Vollzeitprogrammierer, die damit betraut sind. Änderungen werden je nach Aufwand in zwei Kategorien eingeteilt: Projekte (mehr als ein Personenmonat) und "normale" Wartung.

Die Umsetzung erfolgt in beiden Fällen trotzdem ähnlich und weitgehend klassisch, also ausgehend von einem Fachkonzept über ein (abzunehmendes) IT-Konzept über eine Aufwandsschätzung für die (Teil-)aufgaben, mit anschließender Umsetzung, Entwicklertests und Abnahmetests sowie letztlich Abnahme und Produktivstellung.

Das gilt auch dann, wenn nur wenige Codezeilen zu ändern sind. Das dient nicht nur der Vermeidung von Missverständnissen, sondern auch der späteren Nachvollziehbarkeit.

Außer bei "katastrophalen" Fehlern, die natürlich sofort behoben werden, gibt es typischerweise einen zweimonatigen Releasezyklus und entsprechend nur ca. sechs Releases pro Jahr. Die Implementierungsphase dauert ca. 6 Wochen, die sich anschließende die Testphase durch die Fachabteilung ca. 2 Wochen. Während dieser Zeit beheben die Entwickler die gefundenen Fehler und arbeiten ansonsten an der Planung des und Vorarbeiten für das nächste Release. Neue Fachkonzepte können die ganze Zeit erstellt und eingereicht werden und werden dann entsprechend der Priorität, des Aufwands und der Kapazitäten für eins der folgenden Releases eingeplant.

Unittest sind mindestens erwünscht, bei neuen Projekten sogar vorgeschrieben. (Anm.: zur Verbreitung von Unittests in der Praxis ist übrigens Tatsächlicher Nutzen von Unit-Tests [und TDD] ganz aufschlussreich).

Software-methodisch/programmierstilmäßig gibt es leider keine besonderen Vorgaben. Jeder Programmierer arbeitet also so wie er es für richtig hält. Konkrete Vorgeben gibt es nur für ein Programmkopf und bei den Namenskonventionen. Leider ist es oft so, dass die Architektur erst dann zum Thema wird, wenn sich sie sich in der laufenden Wartung als ungünstig oder unpraktikabel herausstellt.

Die Versionsverwaltung speichert standardmäßig nur eine Version pro Release. Es gibt also während der Implementierungs- und Testphase typischerweise nur die eine aktuelle Version, egal an wievielen Tagen an der Datei gearbeitet wurde. Zwar kann man manuell zusätzliche Versionen anlegen. Da diese bei der nächsten Produktivstellung aber automatisch zu einer zusammengeführt werden, wird davon kaum Gebrauch gemacht. Änderungen werden normalerweise sofort durch den Entwickler compiliert und stehen unmittelbar danach allen Benutzern des Entwicklungssystems zur Verfügung.

Es gibt eine Zeiterfassung auf Ebene der einzelnen Aufgaben. Und eine entsprechend detaillierte Projektsteuerung, die auf Zeitüberschreitungen sofort reagiert.

Selbst wenn man zugestehen muss, dass es Punkte gibt, an denen die technischen oder organisatorischen Rahmenbedingungen noch nicht optimal sind, gibt es doch immerhin ein recht definiertes und klares Vorgehensmodell, das auch wirklich so wie beschrieben eingehalten wird.

herbivore

C
2.121 Beiträge seit 2010
vor 12 Jahren

Da hast du recht, Größe und Organisation des Projekts spielt hier ganz sicher eine wichtige Rolle. Zwei Wochen Planung sind für ein in Jahren ausgedrücktes Projekt viel zu wenig, während es für ein Monatsprojekt zu viel ist.
Auch die Größe des Teams spielt eine Rolle. Wenns viele sind und die evtl. über die Welt verteilt sind, muss das alles viel besser durchgeplant sein, als wenn nur eine handvoll Leute an einem Projekt dran sind und eine Änderung mit all ihren Auswirkungen vielleicht nur eine einzige Person betrifft.

Jemand der nur kleinere interne Projekte für sein Unternehmen macht, darf auch viel nachlässiger sein (muss sogar, sonst lohnt sich seine Arbeit nicht) als ein Entwicklertrupp eines weltweit verbreiteten Produkts, wo ganz anders reagiert werden muss.

Vielleicht sind hier im Forum ja nicht so viele Mitglieder von wirklich riesigen Projekten, daher die eher geringen Anforderungen an Organisation im Voraus.

Ich denke mir auch immer wieder, man könnte eigentlich schon Zeichnungen machen und dies und das ... aber die aktuell zu halten würde teilweise mehr Zeit kosten als drauflos zu programmieren und selbst mit der besten Vorarbeit bleibt am Ende trotzdem noch Programmierarbeit übrig. Das Verhältnis muss eben passen.

C
1.214 Beiträge seit 2006
vor 12 Jahren

In meiner Firma läuft es so ähnlich wie von herbivoir beschrieben.
Unser Produkt könnte man als eine Mischung aus Individualprogrammierung und eigentständigem Produkt bezeichnen. Im Grunde ist es ein eigenes Produkt, da wir aber auch sehr große und wichtige Kunden haben, betreiben wir auch viel "Customizing". Allerdings läuft es nie nach dem Motto "wir brauchen hier sofort eine Erweiterung, möglichst umsonst und möglichst gestern, danke". Dafür sind wir zu groß und lassen uns von den Kunden wenig gefallen.
Wir haben auch Releasezyklen und alle 3-4 Monate kommt eine neue Version raus. Für alles gibt es eigene Abteilungen. Ich bin in der C++ Abteilung, wir sind etwa 50 Leute. Irgendwann kommt jedes Release in das Betastadium, dann dürfen keine neuen Features mehr implementiert werden. Dann wird er die QA Abteilung getestet, kommt in die Doku-Abteilung etc. Es werden nur noch Bugs behoben, alle neuen Features kommen in den nächsten Release.
Es gibt auch eine detaillierte Projektverwaltung, jede Änderung wird dokumentiert, architekturbezogene Aspekte werden mit den Verantwortlichen besprochen usw. Könnte man also sagen, dass wir nach einem Modell arbeiten... Würd mir nur schwer fallen, das Modell konkret zu benennen ^^ Find ich auch nicht so wichtig. Finds nur wichtig, dass ein funktionierender, geordneter Ablauf da ist. Habe schon in mehreren kleinen Firmen gearbeitet und noch viel mehr kleine Firmen kennengelernt, da herrscht meist Chaos pur und man kämpft oft um jede verkaufte Mannstunde. Eigentlich hat man da wenig Chancen, in Ruhe an was sinnvollem zu arbeiten.
So, nun hat so ein Entwicklungsmodell aber leider erstmal wenig mit "Planung" oder "Architektur" zu tun. Dass in größeren Firmen solche Abläufe definiert sind, find ich selbstverständlich. Nur leider bewahren sie nicht vor dem Chaos auf Codeebene. Unsere Software umfasst mittlerweile abermillionen Zeilen C++ Code, geschrieben von hunderten unterschiedlicher Entwickler über zwei Jahrzehnte. Ich habe auch nichts anderes erwartet, aber natürlich ist das ganze irgendwo grauenhaft... Alles, was es so bei http://thedailywtf.com/ oder hier im Forum unter Coding Styles Horror zu lesen gibt, hab ich bei uns im Code schon gesehen. Und ich denke, da hilft auch kein Softwareentwicklungsmodell dagegen. Kann es meiner Meinung auch nach gar nicht.