Die Frage nach Softwaretechnik im kleineren Rahmen, stellt sich immer mal wieder. Damit ich das nicht immer mal wieder schreiben muss, gibt's die Antwort, die ich in einem Posting in einem anderen Forum schrieb, nun auch hier:

Hallo zusammen,

ich fange in den nächsten Tagen mit meiner Diplomarbeit an, die 24 Wochen dauert … und stehe vor der Frage, wie sich ein Software-Entwickler die Zeit für die verschidenen Entwicklungs- und Realisierungspahsen aufteilt!!?

Neid… mit 24 Wochen hätte ich erstmal Urlaub gemacht

Wir hatten nur 12 und davon war ich 8 Wochen arbeiten. Eigentlich sollten es nur zwei Wochen sein, aber da kam ein Faktor ein, der jede Planung mühelos vernichten kann. Er heißt Kunde. „Ich hätte da noch eine Idee…“ Dein Kunde heißt Professor und glaub' mir, die haben auch Ideen, dass man manches anders machen muss, wenn man eine gute Note haben will. Ich hatte einen Kunden (mit Termingeschäft…), der nur zahlt, wenn ich seine Ideen umsetze und einen Professor

Mein Betreuer will als erstes eine Detaillierte Aufteilung der Diplomarbeit in abgeschlossene Blöcke und Festlegung deren Termine (Meilensteine) sehen, aber es fehlt mir leider noch die Erfahrung, um so ein großes Projekt zu planen.

Der wichtigste Punkt: Sei realistisch. Überlege, wieviel Zeit Du für einen Punkt brauchst. Wenn Du glaubst, dass Du für den Punkt x Tage brauchst, überleg nochmal. Meistens kommen dann (x+y) Tage raus. Dann veranschlagst Du 2*(x+y) Tage dafür. Das ist Dein Meilenstein. Dann schau auf Deine 24 Wochen und begreife, dass Du nicht 24 Wochen 7 Tage/Woche arbeiten wirst. Fleiß in allen Ehren, aber bleiben wir realistisch. Manche Meilensteine wirst Du früher erreichen. Das gibt Dir die Sicherheit und notwendige Zeitreserve, wenn ein Meilenstein sich mal richtig questellt. Auch ein Termingeschäft muss entsprechende Reserven haben, sonst wird's Glückspiel. Was in die 24 Wochen reinpasst ist Deine Diplomarbeit. Nicht mehr. Wenn Du später mehr schaffst, dann ist das eine tolle Diplomarbeit. Planst Du eine tolle Diplomarbeit und die Zeit reicht nicht, weil Dein Kunde da noch eine Idee hatte, dann ist das SEHR unpraktisch.

Du schreibst eine Software…

Ich plane üblicherweise wie folgt:

1. Identifizierung meiner Schwachstellen in dem Projekt
2. Entwicklung von Very-Quick-und-Very-Dirty Lösungen für fraglichen Punkte, die ich identifizieren konnte.
   Daraufhin bin ich nicht mehr unwissend, was die Projektplanung und -umsetzung angeht.
3. grobe Projektplanung
   Plane nicht zuviel, sobald Du feststellst, dass Du einen Meilenstein nur mit einem Umweg erreichst, was dazu führt, dass Du Details Deiner Projektplanung überarbeiten musst, war die vorherige Arbeit Zeitverschwendung. Details planst Du, wenn der Zeitpunkt gekommen ist. Wichtig ist die Unterscheidung, was für Dich ein Detail ist und was für Dich aufgrund persönlicher Unkenntnis ein Problem darstellen könnte. Vorrangiges Planungziel: Was genau macht die Software, welche Informationen gehen rein, was kommt als Ergebnis raus?
   Wie die Software das macht, interessiert nicht.
4. Identifizierung von Unterproblemen (z.B. Datensatz laden, Datensatz aufbereiten, Datensatz verarbeiten, Datensatz schreiben, Darstellung für Datensatz, GUI) (Meilenstein #1)
5. Abhängigkeitsreihenfolge für der Unterprobleme klären (Datensatz aufbereiten kann nicht getestet werden, wenn ich keine Daten laden kann… usw)
6. Wiederverwendbarkeit klären. Ist es sinnvoll dieses Unterproblem generisch zu lösen? Das ist etwas mehr Aufwand, aber wenn ich den Punkt später im Projekt nochmal verwenden kann, spare ich da mehr Zeit.
7. Unterprobleme lösen (Einstieg Schritt 3, gibt's keine Unterprobleme, darfst Du Dich an die Tastatur begeben.)
8. Details planen und Unterproblem implementieren
9. Tests implementieren
10. Tests überprüfen! Nichts ist destrukturver als fehlerhafte Testsprogramme… Entweder ist die Software falsch und Du glaubst, sie funktioniert, weil Du sie ja getestet hast oder reparierst Funktionierendes kaputt.
11. Unterproblem testen und korrigieren
12. Unterproblem inkl. seiner Abhängigkeiten testen und korrigieren
13. Klassen dokumentieren (warum nicht noch beiläufig zusätzlich eine 200 seitige Schnittstellen-Dokumentation mit einreichen, macht Eindruck und wird ja automatisch erstellt…)
14. Meilenstein abhaken, zurücklehnen, durchatmen, lächeln. Du hast Dir 5 Minuten Pause verdient.
15. Nächstes Unterproblem (gibt es kein Unterproblem mehr, geht's bei 16 weiter)
16. Testen bis der Arzt kommt, Testfälle prüfen.
17. Projekt abhaken, zurücklehnen, durchatmen, lächeln. Du hast Dir 10 Minuten Pause und eine halbe Flasche Bier verdient.

Sobald Du ein Unterproblem implementiert hast, baust Du Testfälle für diesen Meilenstein in die Software ein. Z.B. Form von Asserts. Du identifizierst an wichtigen Funktionen die möglichen Eingaben und schreibst für jeden Fall einen Testfall. Per Präprozessor und Compilerswitch schaltest Du zwischen Funktionstest Deiner Software und Programm um. Es gibt quasi zwei main()-Funktionen, eine für das Programm, die andere ist nur dazu da, um Tests mit go oder nogo zu bewerten. Damit garantierst Du die Korrektheit Deiner Funktionen. Das erspart Dir nicht die Testphase, kann diese aber entscheident verkürzen.

Geht man von <anderer User, der von 40% Planung, 10% Implementierung 50% Testen ausgeht> aus, heißt das 20% Implementierung + 40% Planung und eine gute Chance, dass man in den restlichen 40% Zeit Tests fahren kann, die keine Fehler finden.

Eine sehr beliebte Variante ist übrigens 5% Planung, 150% Implementierung und 1000% Test und Korrekturen.

Auch wenn es schwer fällt und man endlich produktiv sein möchte. Plane Deine Zeit sorgfältig ein. Löse Deine Probleme in übersichtlichen Tests - nicht mit dem Produkt. Notfalls mach ein Fork.

Tools wie Subversion helfen unüberlegte Schritte zurückzunehmen. Wenn Du die Übersicht verlierst, geh zurück zu dem Punkt, wo Du sie hattest und plane den nächsten Schritt vernünftig. Nichts dauert länger und ist fehleranfälliger, als eine verlorene Übersicht in einem Programm wiederzufinden, ohne Fehler in das Programm einzubauen.

Viel Erfolg bei Deiner Diplomarbeit.

Folgendes Reply kam auf mein Posting:

Theorie, alles Theorie.
Bei hier inner Praxis ist das so, Kunde ruft an meldet Fehler, 20 Minuten später hatter ä Update.

Nix plane, nicht teste.

Der Kunde hat sich Gedanken zu machen was er haben will.
Dann kommen wir ins Spiel
Danach schlägt der Kunde sich rum und fragt sich, was er doch für nen Mist haben wollte

Getestet wird nur in absoluten Härtefällen, zum Beispiel wenn Cheffe zweifelt ob das Lizensierungsverfahren auch wirklich funktioniert …