Software-EntwicklungsPhasen
-
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!!?
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.
Würde mich über euere Ideen und Erfahrungen freuen.
Gruß, Softent
-
Also ich habe von mehreren Firmen (bei Vorstellungsgesprächen) gehört, dass es sich etwa so aufteilt:
40% Planung
10% Implementierung
50% TestenDie Prozentwerte varieren sicherlich. Aber von der Zeitverteilung dürfte das denke ich in so ziemlich jeder Firma der fall sein.
Lyrix
-
softent schrieb:
..............
Mein Betreuer will als erstes eine Detaillierte Aufteilung der Diplomarbeit in abgeschlossene Blöcke und Festlegung deren Termine (Meilensteine) sehen,
..............Das Thema interssiert mich mich und wüsste gerne, was hier mit "Aufteilung in abgeschlossene Blöcke" gemeint ist ?
Danke
-
Lyrix schrieb:
Also ich habe von mehreren Firmen (bei Vorstellungsgesprächen) gehört, dass es sich etwa so aufteilt:
40% Planung
10% Implementierung
50% TestenDie Prozentwerte varieren sicherlich. Aber von der Zeitverteilung dürfte das denke ich in so ziemlich jeder Firma der fall sein.
Hm, soviel Planung ist nicht drin. Meistens kommt dann einer und will hir und dort was anderes und dafür dies und das garnicht mehr.
Um was gehts in der Diplomarbeit?
-
kann mir keiner sagen, was "Aufteilung in abgeschlossene Blöcke" bedeutet?
-
ChinYoung schrieb:
kann mir keiner sagen, was "Aufteilung in abgeschlossene Blöcke" bedeutet?
Das bedeutet dass du die Funktionalitaet in verschiedene Bloecke einteilst, und diese nach und nach implementierst. z. B. erst machst du den Block "Text schreiben", danach den Block "Silbentrennung", dann "Rechtschreibpruefung"..... Schlagwort dafuer sind die sog. "Iterativen Entwicklungsmodelle".
-
Es gibt schon einiges an Entwicklungsmodellen.
Beispielsweise das V-Modell '97/XT
Dieses ist so ziemlich das Umfangreichste Entwicklungsmodell für die IT und ich armer Tropf muss mich damit rumschlagen.Eigentlich kann man sagen, dass nur ca. 20-30% überhaupt programmiert wird.
Die Planung und Doku sind so ca. 50%, der Rest ist Debugging.Das Ganze teilt sich wenigstens in diese Schritte:
Anwenderforderungen (Pflichtenheft) aufnehmen
Grobkonzept erstellen und absegnen lassen
Die Feinkonzeptionierung wird meistens während des Programmierens gemacht- gerade im J2EE-Umfeld werden viele Diagramme schon als Quellcode generiert..
Anschließend wird ausgiebig getestet (nach Möglichkeit in einem Umfeld das nicht der Entwicklungsrechner ist, sondern eher aussieht wie so ne Möhre auf der es dann laufen soll..)Am Ende wird dann das Produkt übergeben und meist noch ein Workshop drangehängt..
Sooviel zur Theorie..
-
Am Ende wird dann das Produkt übergeben und meist noch ein Workshop drangehängt..
Ein Workshop wäre vor der Konzeptphase etwas günstiger angesiedelt, da dort die Allgemeinen "Kunden-"Anforderungen formuliert werden.
-
softent schrieb:
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 rein, der jede Planung mühelos vernichten kann. Er heißt Kunde. "Ich hatte 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 Professorsoftent schrieb:
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 14 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 einen 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 Lyrix ausgeht, heißt das 20% Implementierung + 40% Planung und eine gute Chance, dass man in der restlichen 40% Zeit Tests fahren kann, die keine Fehler finden.
Eine sehr beliebte Variante ist ürbigens 5% Planung 150% Implementierung und 1000% Test und Korrekturen.
Auch wenn's schwer fällt und man endlich "produktiv" sein möchte. Plane Deine Zeit sorgfälltig ein. Löse Deine Probleme in übersichtlichen Tests - nicht mit dem Produkt. Notfalls mach ein Fork.
Tools wie Subversion helfen unüberlegte Schritte zurückzugehen. 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.
-
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 ...
-
RED-BARON schrieb:
Theorie, alles Theorie.
Bei hier inner Praxis ist das so, Kunde ruft an meldet Fehler, 20 Minuten später hatter ä Update.
Ungefähr das versuchte ich mit "Eine sehr beliebte Variante ist ürbigens 5% Planung 150% Implementierung und 1000% Test und Korrekturen." auszudrücken.
RED-BARON schrieb:
Danach schlägt der Kunde sich rum und fragt sich, was er doch für nen Mist haben wollte
Und anschließend wird er mein Kunde.
