spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Die Technik nennt sich Netzplan. Hierfür legst du zuerst eine Liste aller Arbeitsvorgänge an und schaust dann in welcher Reihenfolge die Arbeit ablaufen muss (keine Arbeitsvorgänge vor solchen die zur durchführung des Vorgangs benötigt werden). Zum Teil können Vorgänge auch parallel durchgeführt werden.
Wenn du für jeden Arbeitsvorgang den jeweiligen "Vorgänger" (bzw. die Vorgänger) bestimmt hast kannst du das ganze in einem Diagramm festhalten. Jeder Vorgang bekommt dann ein Kässtchen mit Vorgangsnummer, Beschreibung und Dauer. Die Dauer musst du halt realistisch einschätzen.

Wenn das alles getan ist werden die Puffer berechnet. Gängigerweise schreibst du oben links den frühesten Anfangszeitpunkt, oben rechts der früheste Endzeitpunkt. Der Früheste Anfangszeitpunkt startet bei 0 und entspricht bei allen weiteren Vorgängen dem größten FEZ der Vorgänger. Der FEZ ist der FAZ + die Dauer des Vorgangs. Beim zurückrechnen werden der späteste Anfangszeitpunkt und späteste Endzeitpunkt berechnen. Beim letzten Vorgang entspricht der SEZ dem FEZ des Vorgangs, bei allen anderen Vorgängen ist der SEZ der kleinste SAZ der Nachfolgenden Vorgänge. Der SAZ eines Vorgangs ist der SEZ - der Dauer des Vorgangs.

Wenn alle Zeitpunkte berechnet sind kannst du Gesamtpuffer und freien Puffer für die Vorgänge berechnen. GP = SAZ -FAZ und FP = FAZ (Nachfolger) - FEZ. Der Pfad wo keine Pufferzeiten hat wird kritischer Pfad genannt. Auf diesem "Pfad" dürfen keine Verzögerungen stattfinden um den Projektendzeitpunkt nicht nach hinten zu verschieben. Bei allen anderen Vorgängen können entsprechend den Pufferzeiten die Vorgänge etwas länger dauern.

grüße

Ich teile ein Projekt immer in verschiedene Teile auf.

Der erste Teil ist das Analysieren der Problemstellung, die Problemanalyse und der Entwurf, dabei macht man zuerst soetwas wie eine grobe Architektur, diese verfeinert man dann soweit, dass eigentlich alle Klassen/Objekte die man braucht auf Papier/in Editoren sind und man kein Problem mehr findet was mit diesem Entwurf nicht lösbar wäre.
Diese Phase ist besonders wichtig, wenn man im Team arbeitet, sie dauert erfahrungsgemäß wenn man es gut macht, so 1/3 der Zeit, je nachdem mit wievielen Personen man zusammenarbeitet.
In dieser Phase wird keine einzige Klasse gecodet, sie besteht nur aus intensiven Teamgesprächen.

Ein weiteres Drittel gilt dann der Implementierung. Man weiss jetzt bereits alle Klassen, deren Attribute und Methoden. Diese gilt es jetzt zu coden. In diese Phase kommt eine sehr wichtige Teilphase mit hinein, das Testen. Dazu gehören automatische Tests, manuelle Tests, Testprotokolle etc.
Wenn man im Team arbeitet helfen Tools wie CVS/SVN etc. um Projekte zu untereinander im Team zu sharen.

Als letztes beginnt die Dokumentationsphase, das langsweiligste. Je nachdem wie du das brauchst kann es sehr nervig, oder auch entspannt sein.


Zu der Dauer der Schritte und zu Zeitfestlegung:
Ich finde das diese grobe Einteilung durchaus Sinn macht und jede Phase sollte eine feste Zeitspanne zugewiesen werden. Wie groß diese sein muss bekommt man nur durch Erfahrung oder Zeitdruck mit. Ein nicht zu vernachlässigendes Maß ist natürlich die komplexheit der Anwendung, besonders beim Debugging und Testen kann es dort zu verzögerungen kommen. Allgemein gilt aber, wer besser plant hat damit auch weniger Probleme.