Organisierte Planung bei Programmen und Projekten

Hi,

mit dem Erstellen von eigenen Programmen kommt man irgendwann an einen Punkt, an dem man das ganze organisiert angehen möchte.

Da käme man also zu Möglichkeiten wie Struktogrammen, OOP, bzw. UML.

Zudem möchte man später einem Anwender auch eine Dokumentation liefern können, worauf dieser bei den ersten Fragen zurück greifen kann.

Wie plant man jetzt also auf professionelle Art und Weise ein Programm?

Zunächst hat man immer eine Idee, was man für ein Programm erstellen möchte. Diese sollte man dann natürlich erst grob und später detailliert aufschreiben. Doch wie soll das am Besten aussehen?

Bei Recherche stolpert man über die Begriffe Lasten- und Pflichtheft. Wie müssen diese aussehen, dass man es später beim Programmieren leicht hat?

Ein Programm wird so zu einem richtigen Projekt.

Zudem sollte dann auch noch geklärt werden, was man für dieses Projekt an Wissen benötigt und welche Tools, Sprachen etc. man verwenden kann.

Besonders wichtig ist also die Planung. Was muss man zuerst machen und womit geht es weiter? In welchem Zeitrahmen könnte das Projekt realisiert werden? Wie viel Zeit steht zur Verfügung?

Ich suche nun Links zu diesen Themen und hilfreiche Tipps. Wäre echt nett, wenn ihr mich bei der Suche unterstützt.

mfg
Niji

Ich denke es gibt keinen optimalen Weg wie man ein Projekt plant. Jeder Mensch hat andere Vorlieben wie geordnet er an so etwas rangeht und wieviele Notizen er braucht. Das wichtigste ist, daß man niemals den Überblick verliert.

Was sicherlich wichtig ist (sollte ich auch mal langsam machen) ist eine Zusammenstellung aller Features, die das fertige Programm beherrschen soll und dann eine Unterteilung dieser Features in "müssen auf jeden Fall rein" und "wäre toll wenn sie rein kommen". Letztere sind dann die, die man fallen lassen kann wenn es mit der Zeit knapp wird und vielleicht später in einem Update nachschiebt.
Danach ist vielleicht eine Roadmap eine gute Idee um genau zusammen zu stellen was in welcher Reinfolge in Angriff genommen werden soll und an welchen Punkten man seine Milestones setzt.

Diagramme wie UML sind sicherlich bei einem größeren Projekt enorm hilfreich, wenn man mit mehreren an einem Projekt arbeitet würde ich sie schon fast zur Pflicht erheben. Es muss natürlich nicht unbedingt UML sein, hauptsache es gibt eine Diagramm-artige Darstellung wie die Bausteine des Programms zusammen arbeiten.

Was das Zeitmanagment angeht hab ich einmal einen guten Tipp gelesen:
Überlege dir in welcher Zeit du sicher bist das Projekt vollenden zu können. Verdoppele diese Zeit und nimm das als realistisches Minimum. Es hilft sicherlich bestimmte Milestones mit bestimmten Daten zu verknüpfen, aber ich glaube für eine realistische Einschätzung des Zeitaufwandes braucht es vor allem viel Erfahrung. Solang man aber keinen Kunden im Nacken sitzen hat, der auf ein bestimmtes Datum pocht, ist es sicher besser lieber ein wenig zuviel Zeit als zuwenig einzuplanen.

Ich denke wichtig zu sagen ist noch, daß das nicht alles ein Muß ist. Je komplexer das Projekt umso mehr Planung ist sinnvoll, aber im Umkehrschluss bedeutet das auch, wenn das Projekt weniger komplex ist, ist zuviel Planung verschwendete Zeit bzw bringt die Gefahr den Spaß am Coden zu ersticken. Zumindest würde ich mich so fühlen =).

(Jetzt müsste ich mich nur selbst an meine Tipps halten)

Wir lernen in der Schule wie man auf "professionelle" Art und Weise Projekte plant und dokumentiert etc.

Dabei gibt es schon mehr oder minder genaue Regeln wie das ganze ablaufen muss und wie die einzelnen Dokumente (Projektantrag, das von dir bereits angesprochene Pflichten- & Lastenheft, Agendas und Protokolle, ....) ausschauen sollen.
Allerdings kann ich dir nicht wirklich empfehlen das bei privaten Projekten zu machen. Das ganze ist eigentlich nur fuer professionelle Firmenprojekte in der Wirtschaft gedacht. Bei privaten (OS) Projekten kannst du getrost darauf verzichten und dich stattdessen auf eine moeglichst gute technische Dokumentation konzentrieren.

Hm, über die Art wie man an ein Projekt heran geht kenn ich eigentlich nur die beiden Tutorials:

Softwareentwicklung 1
Softwareentwicklung 2

hab sie beide allerdings noch nicht durchgelesen, kann also nicht sagen ob sie gut sind...

cya,
Deathball

Es macht auch noch einen Unterschied, ob du alleine oder in einer Gruppe arbeitest. In letzterem Fall ist das Zeitmanagement etwas komplizierter. Man muss die ganze Geschichte so organisieren, das voneinander zunächst unabhängige Arbeitsschritte parallel erledigt werden.

Außerdem muss man sich in einer Gruppe Meilensteine setzen. Bei einem gewissen Fortschritt des Projekts trifft man sich und diskutiert eventuell aufgetretene Schwierigkeiten oder das weitere Vorgehen.
Dabei sollte man am Anfang ruhig ein paar mehr Meilensteine setzen, da das meist eine sehr kritische Pase ist.

Zitat:

---

Zitat von MagicMagor

Was das Zeitmanagment angeht hab ich einmal einen guten Tipp gelesen:
Überlege dir in welcher Zeit du sicher bist das Projekt vollenden zu können. Verdoppele diese Zeit und nimm das als realistisches Minimum. Es hilft sicherlich bestimmte Milestones mit bestimmten Daten zu verknüpfen, aber ich glaube für eine realistische Einschätzung des Zeitaufwandes braucht es vor allem viel Erfahrung. Solang man aber keinen Kunden im Nacken sitzen hat, der auf ein bestimmtes Datum pocht, ist es sicher besser lieber ein wenig zuviel Zeit als zuwenig einzuplanen.

---

Oder man macht es wie die Japaner. Wenn die merken, dass die Zeit nicht reicht, dann fragen sie nicht nach einer Verschiebung der Frist, sondern arbeiten eben die Nächte durch ...

Zitat:

---

Zitat von derBenny

Oder man macht es wie die Japaner. Wenn die merken, dass die Zeit nicht reicht, dann fragen sie nicht nach einer Verschiebung der Frist, sondern arbeiten eben die Nächte durch ...

---

Oder man macht es wie Redmond und verschiebt zweimal den Termin, dann entfernt man einfach so lange Features und kürzt die QA-Phase, bis es hinkommt. Den "Nächte durcharbeiten"-Kram macht man parallel. Außerdem stellt man erst noch 1000 Entwickler ein.


Es gibt wirklich keine optimale Lösung. Man kann zwar nach ISO-Standard arbeiten und Kram wie Ist- und Sollanalysen machen, Gantt-Diagramme und Risikotabellen erstellen etc., aber das macht wirklich nur bei größeren kommerziellen Projekten Sinn. Wenn man nur mit zehn Leuten an einer kleinen Anwendung rumbastelt wird der Aufwand für die korrekte Abarbeitung der Vorschriften fast schon größer als der der eigentlichen Entwicklung.

Idealerweise sollte man einfach so viele Informationen erarbeiten, wie jeder Mitarbeiter braucht, um jederzeit über den aktuellen Status und die noch ausstehenden Sachen im Bild zu sein. Außerdem sollte man sich ein Entwicklungsmodell suchen und dementsprechend arbeiten - wenn man agil entwickelt ist der ISO-Standard teilweise eher hinderlich als nützlich, während er bei einem traditionellen Wasserfallmodell praktisch unabdingbar ist.

Absolut extrem wichtig ist die Kommunikation zwischen den Entwicklern. Jeder muß jederzeit im Bild sein, wie es um das Projekt steht und wo noch was getan werden muß. Wenn man einen Spezialisten für ein Thema hat so sollte er den anderen genug davon vermitteln, daß im Notfall jemand für ihn einspringen kann. Und die Leute sollten erreichbar sein. Wenn die Reaktionsgeschwindigkeit des Teams davon beschränkt wird, daß ein Mitglied nur alle drei Tage in die Mailbox schaut dann hat das deutliche Auswirkungen auf die Qualität des Endproduktes.


Die Organisation von Softwareentwicklung ist ein Thema für sich und als solches nicht gerade trivial. Außerdem ist eine der wichtigsten Komponenten Erfahrung - denn ohne selbige kann man bei einigen wichtigen Entscheidungen nur raten (beispielsweise dabei, wie lang die QA-Phase im Vergleich zum Rest der Entwicklung sein sollte).

k, thx @ all.

Ich habe jetzt 2 Bücher von irgend einem Prof. bei meinem Vater entdeckt. Da steht alles drin, was ich sonst noch so wissen muss.

Habe die momentan nicht parat. per Edit werd ich den Titel und ein paar Daten noch schreiben.

lg

EDIT: Lehrbuch der Software-Technik Band 1 und 2, ISBN: 3-8274-0042-2 (Band 1), Spektrum Verlag, von Helmut Balzert