Moin ihrs...
Da ich nur in der Freizeit und zum Spass programmiere, habe ich nie gelernt welche Überlegungen man sich vor dem Programmierern einer Software macht.
Hat mir jemand Tipps bzw. Quellen wo ich mich über die Planung von grösseren Softwareprojekten informieren kann?

Also privat bevorzuge ich die VHIT Methode um größere Softwareprojekte zu realisieren.  *spass*

Naja du solltest dir zu Anfang überlegen was reinkommt und was rauskommen soll.
Und das möglichst genau definieren.
Diesen Schritt machst du für jedes einzelne Modul und jede Sub die du brauchst.
Das alles natürlich schriftlich festhalten.
Ein Ablaufplan ist sicher auch brauchbar wenn die Logic entsprechend kompliziert ist. Wobei ich da zugeben muss, dass ich eine Logik die mit so lustigen Pfeilen und Kästchen visualisiert wird, manchmal langsamer verstehe als ein broken Code.

Wenn du dann noch Lust hast kannst du die Details mit einem Struktogram vorbereiten. Wenn das alles sorgfältig gemacht wurde, dann brauchst du im Grunde das alles nur noch mit deiner Programmiersprache "abzuschreiben" bzw. umzusetzen. So besagt das die Theorie, aber ob es in der Praxis immer so funktioniert...

Bei richtigen Projekten werden über 2/3 der veranschlagten Zeit für die Planung benötigt, das Coden selbst ist nur recht wenig. Den von dem 1/3 gehen dann auch noch mal einige Prozente für's testen drauf.

Aber macht ja auch Sinn wenn man sich schon vor dem Coden Gedanken macht, viele Fehler die sonst das neuschreiben mitsichbrignen, kann man so vorher entdecken.

Heiner Kuhlmann hat 2004 beim Perl Workshop einen Vortrag über "rekursives Design und Implementierung von komplexen  Perl-Programmen" gehalten, der da auch einige interessante Aspekte aufgezeigt hat.

Der eine Weg ist die kleinsten Einheiten fertig zu entwickeln. Nachteil: man sieht keine oder nur kleine Fortschritte
Der andere Weg wäre das Grundgerüst zuerst zu erstellen und dieses mit Dummies zu füllen, welche nach und nach durch funktionierenden Code ersetzt werden. Das hat den Vorteil dass man schon in einem recht frühem Entwicklungsstadium was funktionierendes hat.

greetz & fetten Segen
manu\n\n

<!--EDIT|pfuschi|1113171560-->

Es gibt sogenannte Modelle, die man in der Softwareentwicklung anwenden kann. So gibt es z.B. das Wasserfallmodell oder das V-Modell.

Diese Modelle teilen die Softwareentwicklung in verschiedene Phasen auf, in denen feste Dinge zu tun sind, z.B. der Entwurf des Lastenhefts etc.

Struktogramm in seiner eigentlichen Form mag ich nicht besonders. Ich persönlich mache es dann lieber so, dass ich mir auf einem Schmierzettel ein "wildes" Konstrukt aufmale, auf dem mit Pfeilen etc. aufgezeichnet ist, was ich machen muss und was ich aus der jeweiligen Methode benötige.

Wenn ich mich am Anfang mit einer Aufgabe beschäftige, schreibe ich auch häufig einfach mal Gedanken auf, die mir einfallen, wie ich das Problem lösen kann. Häufig kommen nach einer gewissen Zeit neue und zum Teil bessere Ideen.
Und speziell bei Perl schaue ich dann auch erstmal auf CPAN, welche Module es schon in der Richtung gibt. Sehr oft findet man dabei dann auch andere Module, die die gleiche Aufgabe etwas anders lösen und die man besser verwenden sollte.

Wie man den gesammten Softwareentwicklungsprozess angeht, hängt auch häufig von der Firma ab, in der man arbeitet.
Bei mir ist es meistens so, dass die ganze Planungsphase sehr gekürzt ist und sich häufig auf wenige Notizen beschränkt und mehr Zeit für die eigentliche Umsetzung da ist.

Viele Sachen verändern sich im Laufe eines Projekts. Manchmal kommt es vor, dass man am Anfang manche Sachen noch nicht bemerkt hat und sich dann die Umsetzung ändert.

Da ich eigentlich nur kleinere Sachen mache (die großen bleiben zumeist irgendwann liegen), bin ich nicht direkt qualifiziert eine Aussage zu treffen. Ich halte mich aber an das Motto: "Teile und hersche", das heisst ich zerlege alles in Module/Klassen und versuche soviel wie möglich Abstraktion rein zu bringen, um hinterher bei der Umsetzung immer möglichst kleine Teile programmieren zu müssen. Zu jedem Teil (Modul) versuche ich dann ein paar Tests zu schreiben und die Dokumentation als POD einzubinden. Je kleiner alle abzuarbeitenden Bestandteile sind um so größer ist die Chance das ich irgendwann mal fertig werde. Wenn ich das nicht tue weiß ich nach einiger Zeit nicht mehr, was ich mir wobei gedacht habe und wie alles zusammenpasst. Am besten anfangs ein paar Blatt Papier nehmen und anfangen Klassen und Methoden zu überlegen.

Beispiel Webanwendung:

1. Datenbankabstraktion
1.1 Konfiguration in YAML-Datei
1.2 Je Tabelle eine Zugriffsklasse
1.3 Je Klasse die notwendigen Methoden festlegen und vereinheitlichen (Abfrage, Aktualiserungsabfrage, Löschabfrage...)
1.4 Tests für die einzelnen Methoden überlegen
1.5 Methoden schreiben, testen und POD-Dokumentation hinzufügen
2. Validierung von Formulardaten u.a.
2.x (...)
3. Sessionhandling (spare ich mir bei einfacheren Sachen)
3.x (...)
4. Templating
4.x (...)
5. Das eigentliche CGI, was nur noch aus relativ einfachen Aufrufen von Methoden, nach vorgegebenen Aktionen, besteht.

Sonderlich wissenschaftlich ist das jetzt nicht gewesen, aber es klappt einigermaßen gut. Außerdem empfehle ich "refactoring", d.h. immer wenn man wieder mal was dazu gelernt hat, sich das bisherige zu betrachten und zu optimieren.

Ich hoffe das es dir ein wenig hilft,
Ronnie\n\n

<!--EDIT|Ronnie|1113208409-->