Projektplanung, wie?

Original geschrieben von Tom
Servus!

1.) Anforderungsdefinition
2.) 1.) -> Pflichtenheft
3.) Implementierung
4.) User Feedback
5.) If !(Kunde zufrieden) Goto 3.)

...

Gruss Tom
Zum Vergrößern anklicken....

Tom wir wollten nicht wissen, wie mann es machen sollte, sondern wie es abläuft :-)

Ich reisse mich oft am riemen, aber geschäftlich gibts immer wieder das Problem der schwankenden Kundenwünsche.

Privat meine Schwankenden Wünsche. Drum verfahre ich nach dem Prinzip:
Häppchen erstellen, und am Schluss hoffen das, das zusammengesetzte einen Sinn macht.
 
Als erstes versuch ich immer, die grobe Aufgabe der späteren Software in maximal drei Sätzen zusammenzufassen. Danach gibt's eine Runde Brainstorming mit den Leuten, die die Software haben wollen. Aus allen zusammengekommenen Ideen werden dann die rausgesiebt, die von allen (oder zumindest der Mehrheit) als wichtig oder sinnvoll angesehen werden.
Aus der stichpunktartigen Liste der Programmfeatures entsteht dann im dritten Schritt das Pflichtenheft, welches sich dann wiederum nach und nach in Code und Benutzerschnittstelle verwandelt.

Nebenbei werden natürlich immer noch Aufgabenlisten geführt, die nach Dringlichkeit sortiert sind und sich immer mit dem aktuellen Projektstand ändern. Und selbstverständlich noch die Dokumentation, sortiert nach Bibliothek, Klasse, Methode und Variable.
 
vorläufiges Design
- Idee (Was für ein Programm/Spiel will ich überhaubt?)
- Programmiersprache: Abhängig vom Betriebssystem und natürlich deren Fähigkeiten (OOP, Speichermanagement, Datenbanken, client/server..)
- grobe Liste der Features bis zum Vorläufigen Release
- Regeln ausarbeiten (Was darf der User letztlich tun)
- Features mit Details in einer Liste von Anwendungsfällen (AWF)
- Klassendiagramm oder PAP
- GUI-Entwurft (Fenster, Dialoge und Abfragen)

dann gehts schon zum programmieren
- Umsetzung der Programm-Struktur
- Erste läuffähige Version
- erste wichtige AWF implementieren
- Regeln verarbeiten
.
.

endgültiges Design
- Überarbeitung der Struktur nach den ersten Implementierungs-Erfahrungen
- neue Features hinzu, alte überarbeiten oder entfernen


verschiedene Tests
- testen der AWF und Regeln

Release
- Bugfreie :eek: Programm-Version
- Source-Dokumentation (z.B. Cppdoc2, javadoc...)
- User-Dokumentation´

----
So hab ich das bei uns an der FH gelernt und schon oft benutzt.

Meine Klassendiagramme, Regeln und AWF stell ich mir an meiner Magnet- und Schreib-Tafel direkt über meinem Monitor zusammen. So behalte ich immer alles im Auge ;)
 
Ich stehe auf Patchwork, damit komme ich am besten klar.
Ich habs bei größeren Projekten / Funktionen auch schonmal mit Papier / Struktogrammen probiert, aber im Endeffekt halte ich mich eh nie an meine Pläne. :)
 
Stimmt schon aber beim Pläne entwickeln baut sich im Kopf eine sehr gut durchdachte Struktur auf!
Zum Vergrößern anklicken....
... welche man zu einem späteren Zeitpunkt evtl. doch wieder über den Haufen werfen muss, weil man feststellt, dass man sonst nicht richtig weiter kommt oder weil man sich nach den Kunden richten muss, die sich das auf einmal doch ganz anders vorgestellt haben. :rolleyes:
Trotzdem kann eine solche Struktur nicht schaden, wenn sie wirklich gut durchdacht ist. Allerdings sollte man diese immer mit der Zielgruppe zusammen aufbauen, sonst _kann_ das schnell nach hinten losgehen.
 
Original geschrieben von Lirion
... welche man zu einem späteren Zeitpunkt evtl. doch wieder über den Haufen werfen muss, weil man feststellt, dass man sonst nicht richtig weiter kommt oder weil man sich nach den Kunden richten muss, die sich das auf einmal doch ganz anders vorgestellt haben.
Zum Vergrößern anklicken....

Jaaaaaaaaaaa endlich ein Praktiker :-)
 
.:jOki:. hat gesagt.:
...Meine Klassendiagramme, Regeln und AWF stell ich mir an meiner Magnet- und Schreib-Tafel direkt über meinem Monitor zusammen. So behalte ich immer alles im Auge ;)
Zum Vergrößern anklicken....
Das ist eine gute Idee ;)! Du musst aber viel Platz haben. Verwendest du wirklich kein UML Werkzeug?
 
Ich bin zwar nur "Hobby-Programmierer", aber wenn ich mir den Thread so ansehe stellt sich mir die Frage:

Gibt es im Bereich Programmierung nicht auch Richtlinien, Normen, etc., wie in jedem anderen technischen Fachbereich auch? Gehört Projektorganisation zum Informatikstudium?
Ich komme aus dem Maschinenbau und bei uns ist eine geordnete Vorgehensweise bei (Maschinenbau)Projekten schon durch die Qualitätssicherung vorgeschrieben, mal abgesehen von unendlich vielen externen Vorschriften und Normen.

Ich denke ein allgemein gehaltener Projektablaufplan sollte zumindest vorhanden sein, der die einzelnen Projektabschnitte beschreibt. Sonst fährt man doch zwangsläufig ins Chaos!:rolleyes:
Gerade wenn man im Team arbeiten will/muss ist eine gute Dokumentation wichtig.
Auch eine evtl. Wiederverwendbarkeit von Code, also das Lagern in Datenbanken o. ä. halte ich für wichtig. Was sich bewährt hat und ausgereift ist, braucht ja nicht immer neu "erfunden" zu werden.

Ich merk schon, ich laber wieder zu viel!:rolleyes:
 
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück