Wie sieht das bei euch aus? Wie genau plant ihr?

Wenn ich etwas plane, dann muß es nicht mit Bleistift und Papier sein. Natürlich kann ich auch gleich mit meinem Codeeditor planen. Ob ich jetzt class X schreibe, oder auf Papier einen Kasten mit dem Klassennamen X, ist doch egal. Es ist nur eine andere Sprache (UML oder C++). UML benutze ich nur dann, wenn ich mit jemand anderen Plane, also einem Teamkollegen. Da macht es Sinn, sich vor eine Tafel zu stellen oder vor ein Blatt Papier zu setzen und gemeinsam was aufzuzeichnen. Wenn ich aber alleine arbeite, plane ich mit der C++-Sprache elektronisch und nicht analog mit Bildchen.

Also wenn Du schon so fragst, ist eine Bottom-Up Entwicklung (testgetrieben, Prototyping) für Dich wahrscheinlich das Beste.
Und dann ständiges Refactoring ... Patterns ankucken, anpassen, implentieren, refactoring, Testen, ...

Studium <-> Praxisrefektion!³³

Ich kann in meiner Liga (10M - 1G€) natürlich nicht so verfahren.

Also auch eine wichtige Frage: Was willst Du mit den Code erreichen?

steht für 10^9. ist aber falsch hier. wirtschaftler kennen sowas nicht oder meiden es und schreiben 1 Mrd €. was prof84 macht, liegt nicht nur an eventuellen projektgrößen, sondern auch daran, was er kann. und was das ist, erkennt man schnell.

steht für 10^9.

2^30

2^30 waere Gi.

ich denke auch mal dass du nicht erst struktogramme erstellt hast, als du vor hattest gehen zu lernen. (ich gehe mal davon aus, dass struktogramme zu deiner zeit etwas total cooles waren, denn ich weiß nicht wie das uml-äquivalent dazu heißt, falls du jüngeren baujahres sein solltest).

1. denken
2. planen
3. rumcoden

Nur der Umfang ist variabel und sollte jeder an seinen Fähigkeiten und dem Umfang des Projektes/der Mitarbeiteranzahl fest machen.

Erstmal nachdenken was willst du haben und was soll das Programm später können, das sollte UNBEDINBGT sein, sonst musst du unter Umständen den späteren Quellcode komplett umschreiben weil du das letzte gewollte Feature nicht mehr rein bekommst.
Hier gibts auch diverse Techniken wie Brainstorming etc, aber die Hauptsache ist ein intensives Nachdenken wie das Ergebnis nachher aussehen soll und was es können soll(evtl mit mehreren und dann von Dritten, zB Endanwendern Feedback einholen ob das toll ist was du erdacht hast), denn in der Planungsphase sind Veränderungen am schnellsten zu machen(besser einen Satz schreiben und etwas streichen, als den Quellcode umrödeln).
Wenn es ein Kundenauftrag ist, ist das gewollte ja auch für die Kostenplanung nicht grad unwichtig.

Beim Planen ist es halt die Kunst soviel zu planen wie nötig, aber nicht mehr.
Zu wenig führt nachher besonders bei mehreren Mitarbeitern oder Aufgaben die man das erste Mal angeht zu Chaos, weil nix zusammenpasst.
Zu viel führt zu verdammt viel verschwendeter Zeit, in der man Offensichtlichkeiten aufschreibt.
Wenn ich etwas programmiere fällt mir meistens spontan ein Weg ein, es zu machen und ich weiß auch ganz genau, ob und wo es dabei Probleme geben könnte.
Wenn ich da auf "problemlos" komme, brauch ich auch nicht zu planen, bei sowas habe ich immer recht :p
Bestenfalls nochmal kurz zu überlegen ob der erdachte weg der Beste ist.
Aber "Regel" is halt, wenn du weißt, du kannst den jeweiligen Teilbereich von Anfang bis Ende der Programmierung ohne Planung problemlos überblicken, dann brauchst du da auch nicht viel planen da.

Naja und programmieren sollte klar sein, ohne gehts nicht, wobei obiges eigentlich das ist wofür man in einer Firma wesentlich besser bezahlt wird und es gibt nichts langweiligeres als ein von anderen voll durchgeplantes Projekt nur umzusetzen :p

Informieren
Planen
Entscheiden
Realisieren (hier tut man dann mal was)
Kontrollieren
Auswerten

=> Saubere Arbeit

Bei Hobbies würd ich mir das aber dreimal überlegen

Naja und programmieren sollte klar sein, ohne gehts nicht, wobei obiges eigentlich das ist wofür man in einer Firma wesentlich besser bezahlt wird und es gibt nichts langweiligeres als ein von anderen voll durchgeplantes Projekt nur umzusetzen :p

So ein Projekt will ich mal sehen! Ich kann mir nicht vorstellen, dass man ein größeres Projekt so planen kann, dass man es ohne Änderungen des Plans umsetzen kann. Irgendwann kommt immer was an das keiner gedacht hat,

Die kunst der planung ist es auch unvorhergesehenes mit einzuplanen und so kompensieren zu können. Was bringt es wenn schon während der entwicklungsfase eines projektes sovile änderungen reinkommen, das der code bereits bei abgabe an den kunden nicht mehr wartbar ist.

ich kann mich da nur an den schweineberg erinnern, der die kosten eines software projektes im zeitverlauf dargestellt hat. Sa ungefähr so aus wie eine Parabel dritten grades.
zum zeitpunkt null haben wir auch null kosten, die bei vorschreitender Projektzeit auch zunehmen, Planungskosten, entwicklungskosten. ( erst 2 entwickler dann 10 )

diese kosten ereichen kurz vor markteinführung ihren höhepunkt, und flachen dann langsamer oder auch schneller ab. In dieser zeit ist der meiste aufwand im bereich support und kundenbetreuung.

Danach kommt eine art talsole, das Projekt kostet nur noch wenig geld, da nur weing änderungen, neue anforderungen eingearbeitet werden müssen, und die aufgrund der "guten" Planung einfach zu integrieren sind.

Anschliesend steigen die Kosten wieder, da implementierung neuer Anforderungen, Fehlerbeseitigungen immer komplizierter werden. Der code wird langsam nicht mehr wartbar, da Anforderungen nicht mit dem implementierten software konzept vereinbar sind. Im Code mitlerweile so vile triks und kniffe enthält um die anforderungen fast nicht mehr implementiert bekommt. Ab dann kommt ein zeitpunkt an dem die änderung dermassen teuer wird, das eine neuimplementierung des ganzen Projektes billiger, wirtschaftlicher und unter umständen auch stabiler ist als ein nachtägliches "reinwürgen"

Je länger es dauert bis das ende des software zyklusses ereicht ist desto besser wurde am anfang des Projektes geplat. Die grundlage dafür wird am anfang eines projektes festgelegt. Nachträgliches gegensteuern ist nur schwer möglich und meist extrem teuer. ( ich glaub es waren die ersten 10% der kosten, die über die lebensdauer eines Projektes entscheiden )

gruss

was prof84 macht, liegt nicht nur an eventuellen projektgrößen, sondern auch daran, was er kann. und was das ist, erkennt man schnell.

internet-surfen und googlen?

Tatsache ist, daß komplexe Software zu produzieren unheimlich aufwendig ist.
Im vorherein aufgestellte Zeitpläne kann man gleich mit zwei multiplizieren und werden trotzdem nicht eingehalten. So manches Team bestehend aus 5 Entwicklern bringt unter Umständen mehr weiter, als ein Moloch mit 50 Entwicklern. Alles eine Sache der Planung, Entwicklungsmethode (Waterfall, Agile Development, Extreme Programming ...) und vorallem Motivation der Teammitglieder.

MfG, Michael
... beruflich in einem größeren Projekt (Medizinische Software, 6 Entwickler, ca. 10 Mannjahre investiert, Java, Agile Development) eingebunden.

das gilt natürlich für den Hobbybereich. Ich denke mal, dass der Threadstarter, sich auch hobbymäßig mit der Programmierung beschäftigt. Bei Hobbys a) geht es *nicht* ums Geld (außer Stromkosten) b) die zeit ist *nicht* begrenzt (außer durch den tod)