Planen grösserer projekte (C++)

[stimmy]

hallo,

mich würde mal interessieren wie ihr grössere projekte plant. wenn ich kleinere anwendungen schreibe, dann schreibe ich die aus dem kopf raus. keine notizen, keine planung nichts. wie macht man nun aber die planung eines grösseren projektes? kennt ihr z.B. das half-life SDK? wenn man sich den sourcecode anschaut, denkt man sich schon "wie haben die jungs von valve dieses projekt geplant".

ich meine woher weiss man später was für klassen das projekt haben soll, welche methoden namen, wieviele methoden, was für variablen, welche namen, etc. etc.

wie plant man sowas am besten, wie plant ihr sowas? kommt mir jetzt bitte nicht mit papier und bleistift
klar könnte man sogar ein half-life (engine) sowie den game source (SDK) ohne jegliche vorherige planung schreiben. dies würde jedoch dazu führen das man 100x mehr zeit in anspruch nimmt da sich der sourcecode zur entwicklungszeit ständig ändern würde. insofern, wer macht sowas schon ohne planung.

[pli]

Wenn ich ein Projekt angehe, was aus mehr als einer .cpp/.c Datei besteht schreib ich mir vorher auf was es koennen soll. Dann teile ich das ganze in Bereiche ein, jeder Bereich besteht aus einer Klasse. Die Bereiche koennen sich natuerlich auch ueberlappen, diese Ueberlappungen sind dann die Beziehungen zwischen den Klassen. Schlagwort UML.
Das ganze male ich mir dann an mein Whiteboard (zuhause hab ich eins von IKEA *g*). Dann zerlege ich das in Funktionsgruppen. Dateneingabe, Datenausgabe, Datenverwurstung, ...
Danach kommt die Zeitplanung. Was braucht was zum Laufen. So kann ich entscheiden, was ich zuerst entwickle. So bastel ich z.B. zuerst die Einleseroutinen und teste die. Wenn die gehen bastel ich die ersten Ausgaberoutinen, dann kann ich Daten einlesen und ausgeben (z.B. anzeigen via OpenGL). Und jetzt nach und nach immer neue Funktionengruppen einbauen. Rotation/Translation von einzelnen Dreiecken, dann von Meshs (weil die ja auf Dreiecke aufbauen), dann Kollisionserkennung u.s.w.

Dazu gibts tausende von Schinken wie man das effektiv macht. Denke das wichtigste ist, dass du das Projekt nicht als grossen Block siehst, sondern als mehrere/dutzende/hunderte kleiner Bloecke die miteinander interagieren. Und wenn du die Beziehungen dazwischen aufschreibst kannst unten anfangen und dich durch den Block arbeiten. Zum Schreiben empfehle ich Papier und Bleistift oder Whiteboard und Marker, ist einfach griffiger als das ganze im PC mit MS Project oder Visio oder so zu machen.

[Codehure]

Moin Moin
Hier mal einige Schlagwörter
Für nähere Informationen bitte die Uni deiner Wahl aufsuchen!

Pflichtenheft
- genaue Abstimmung was der Kunde haben will
- Interfaces des Programm festlegen
- Datenformat festlegen

Programmplanung
http://de.wikipedia.org/wiki/Softwareentwicklung
http://de.wikipedia.org/wiki/Softwaretechnik
als erstes ist immer etwas großes weißes!Eine leere Tafel, verdammt viel Papier oder ähnliches. Der erste Entwurf ist imho immer auf einem nicht digitalem Medium. Grund: Entwickler bzw Designer haben so die Möglichkeit synchron an der Tafel zu malen und so ihre Ideen darzustellen und reifen zu lassen.

und verdammt vieles mehr.

Projektplanung
Aufteilung des großen Packetes in kleine handliche Packete
usw.
usw.

Das Gebiet ist so riesig das du mit dieser Frage angefangen hast das ich dir erstmal empfehlen möchte einige Bücher bzw Vorlesungen zu diesem Thema dir anzuhören bzw zu lesen.

cu Jens

[stimmy]

danke für euer feedback, klingt interessant! so etwa stelle ich mir das vor.
pli eine frage: lohnt sich den ein Whiteboard als self-developer, sprich einzel entwickler? und lohnt sich ein Whiteboard wenn man UML software wie z.B. rose oder ähnliches einsetzt? was genau schreibst du auf dein Whiteboard? speziell die klassenhierarchie oder das grund muster deiner planung? oder was genau?

[Marc++us]

Codehure schrieb:

Pflichtenheft
- genaue Abstimmung was der Kunde haben will

Hat nur einen Haken:

Der Kunde weiß in 98% der Fälle zu Beginn des Projekts nicht, was er will. Sobald er erste Prototypen bekommt und sieht, wird seine Vorstellung aber klarer, und wer weiß vor allem dann recht bald, was er NICHT wollte oder was ANDERS sein sollte.

Daher ist die einmalige Abstimmung mit Kundenwünschen zu BEGINN des Projektes, anschliessend die Ableitung der Aufgaben, Entwicklung und Auslieferung, in dieser Form reine Theorie und wird dazu führen, daß der Kunde das Produkt nicht akzeptiert.

[Codehure]

Marc++us schrieb:

Der Kunde weiß in 98% der Fälle zu Beginn des Projekts nicht, was er will. Sobald er erste Prototypen bekommt und sieht, wird seine Vorstellung aber klarer, und wer weiß vor allem dann recht bald, was er NICHT wollte oder was ANDERS sein sollte.

Stimmt. Aber...

1. Änderungen kosten Geld !
1.1 Änderungen die nicht in dem Pflichtenheft stehen kosten dem Kunden Geld.
1.2 Änderungen die im Pflichtenheft stehen kosten dem Programmierer Geld.

Natürlich ist die einzigste Konstante in der Softwareentwicklung das es immer Änderungen geben wird und vor allem immer eine mehr als man mit gerechnet hat!

Marc++us schrieb:

Daher ist die einmalige Abstimmung mit Kundenwünschen zu BEGINN des Projektes, anschliessend die Ableitung der Aufgaben, Entwicklung und Auslieferung, in dieser Form reine Theorie und wird dazu führen, daß der Kunde das Produkt nicht akzeptiert.

Wenn der Kunde seine Wünsche nicht spezifizieren kann ist es das Problem des Kunden wenn er nicht das bekommt was er will sondern das wofür er bezahlt hat!
Natürlich müssen in den Entwicklungsprozess immer wieder Abstimmungstermine mit dem Kunden einfliessen und Rücksprachen getroffen werden (=>XP).

cu Jens

[Marc++us]

Codehure schrieb:

Wenn der Kunde seine Wünsche nicht spezifizieren kann ist es das Problem des Kunden wenn er nicht das bekommt was er will sondern das wofür er bezahlt hat!

Und mit der Einstellung bekommst Du Aufträge?

[Codehure]

Moin Moin

Codehure schrieb:

Wenn der Kunde seine Wünsche nicht spezifizieren kann ist es das Problem des Kunden wenn er nicht das bekommt was er will sondern das wofür er bezahlt hat!

Kann sein das ich grade durch deine Logik nicht durchblicke!

Bei großen Projekten wird durch ein Pflichtenheft soviel spezifiziert das es für beide Seiten keine Unklarheiten exestieren dürfen!
Wenn es noch Unklarheiten gibt ist das Pflichtenheft falsch bzw ungenügend. Und in den Bereich wo ich tätig bin sind zum Beispiel Design Prototypen im Pflichtenheft, zwar sehr rudimentär, vorhanden.
Und wenn der Kunde dieses Pflichtenheft unterschreibt, und etwas unterschreibt das er nicht möchte ist es sein Problem! Das Problem des Programmierers ist es vorher dafür zu sorgen das das im Pflichtenheft steht was der Kunde möchte bzw was machbar ist für den möglichen Preis.

cu Jens

[Chew-Z]

Soweit zur Theorie...

[Unix-Tom]

In der Praxis steht das Design erst fest wenn der Kunde mal Bsp. sieht.
IN größeren Firmen (Microsoft,etc) machen dies eigene Leute, welche sich Wissenschaftlich damit befassen.

Dies sind aber Produkte für den Massenmarkt.
Wer ein Programm will weiß nicht wie das Design aussieht und man hat auch kein Geld komplexe Designstudien zu implementieren. Deshalb muss die das GUI dem Kunden ansprechen und Zweckm. sein. Hier hat man aber bereits mit dem Projekt begonnen.

So sieht die Praxis aus.
Das zum Thema Fachtheorie aus dem Studium.

Nicht umsonst verlangen Firmen bereits Praxis wenn sie jemanden anstellen wollen.
Diese schönen Wörter wie UML, etc. sind oft in der Praxis auch nicht umsetzbar wie man es in der Theorie lernt.

Ich halte mich da an XP.

[net 0]

Unix-Tom schrieb:

Ich halte mich da an XP.

machen wir das nicht alles so? da wird wenigstens die not zur tugend erklärt. nix 'wasserfallmodell" und ähnlicher schnickschnack
btw: bitte nicht falsch verstehen. ich bin auch anhänger von 'xp' (äääh damit ist jetzt nicht dieses os von m$ gemeint)

[Spacelord]

Codehure schrieb:

Bei großen Projekten wird durch ein Pflichtenheft soviel spezifiziert das es für beide Seiten keine Unklarheiten exestieren dürfen!

Es lebe das (rein sequentielle) Wasserfallmodell!!
Unglücklicherweise hat sich gezeigt dass es so einfach nicht funktioniert....

MfG Spacelord

[Codehure]

Moin Moin

net schrieb:

Unix-Tom schrieb:

Ich halte mich da an XP.

machen wir das nicht alles so? da wird wenigstens die not zur tugend erklärt. nix 'wasserfallmodell" und ähnlicher schnickschnack

Na Super! Erklären wir den Chaotischen Zustand zu einem Model und entwickeln so weiter, aber nun mit einem Model und lauten teuren Büchern! SCNR!

Das das Wasserfall Model in der Praxis oftmals "wenig zweckmäßig" ist bestreitet niemand aber ist es nicht logisch wenigstens am Anfang mit der Prämisse an das Projekt zu gehen alles zu planen und zu spezifizieren?

cu Jens

[net 0]

Codehure schrieb:

Moin Moin

net schrieb:

Unix-Tom schrieb:

Ich halte mich da an XP.

machen wir das nicht alles so? da wird wenigstens die not zur tugend erklärt. nix 'wasserfallmodell" und ähnlicher schnickschnack

Na Super! Erklären wir den Chaotischen Zustand zu einem Model und entwickeln so weiter, aber nun mit einem Model und lauten teuren Büchern! SCNR!

der trick ist wohl, den richtigen mittelweg zu finden: XWP (eXtreme Wasserfall Programming)

[Marc++us]

Codehure schrieb:

Das das Wasserfall Model in der Praxis oftmals "wenig zweckmäßig" ist bestreitet niemand aber ist es nicht logisch wenigstens am Anfang mit der Prämisse an das Projekt zu gehen alles zu planen und zu spezifizieren?

Es ist Wunschdenken. Aber Wünsche sind keine Basis für Projektplanung.

Ich halte diesen Ansatz "mit der Prämisse in das Projekt zu gehen alles zu planen und zu spezifizieren" sogar für unlogisch, wenn die Erfahrung lehrt, daß dieser Ansatz nicht ausreicht. Wenn eine gewisse Vorgehensweise in fast jedem Fall dazu führt, daß im Laufe des Projekts Dinge scheitern, so kann ich die Wahl dieser Methode nicht als logisch bezeichnen.

Ich stimme Dir aber zu wenn Du forderst, daß man zum Projektbeginn natürlich die Anfangsbedingungen und Randbedingungen festhält, und die Startwerte. Sogar die Testfälle, die man am Ende abdecken will. Aber wenn die Planung so vorgesteckt ist, daß man im Laufe des Projekts kein Geld mehr für Planänderungen hat, so ist die Projektplanung zu starr. Eine Projektplanung muß schwingen können (wie eine Brücke), so daß sie unter dem Wind nicht zerbricht. Aber genau diese Denkweise sieht der klassische Ansatz mit Pflichtenheft und Ausprogrammierung der Definitionen nicht vor.

XP bedeutet ja nicht, daß man wahllos und chaotisch die Ereignisse an sich vorüberziehen lässt - XP (und andere Methoden aus diesem Umfeld) versucht ja gerade, ein System in dieses "Einkreisen des Ziels" zu bringen, eine Ordnung und Regelmäßigkeit, und damit eine Planbarkeit. Die Planbarkeit reicht nur bis zum nächsten Zwischenziel, ist dafür aber realistischer und meßbarer. Sozusagen fraktaler.

[Codehure]

Marc++us schrieb:

Ich stimme Dir aber zu wenn Du forderst, daß man zum Projektbeginn natürlich die Anfangsbedingungen und Randbedingungen festhält, und die Startwerte. Sogar die Testfälle, die man am Ende abdecken will. Aber wenn die Planung so vorgesteckt ist, daß man im Laufe des Projekts kein Geld mehr für Planänderungen hat, so ist die Projektplanung zu starr. Eine Projektplanung muß schwingen können (wie eine Brücke), so daß sie unter dem Wind nicht zerbricht. Aber genau diese Denkweise sieht der klassische Ansatz mit Pflichtenheft und Ausprogrammierung der Definitionen nicht vor.

Der Idealfall wäre ja im Pflichtenheft die Teile die sich eventuell ändern können, aufgrund von anderen Entscheidungen, zu finden und die Alternativen einzuplanen und dann zum passenden Zeitpunkt zu entscheiden. Und dann gleich noch das Geld für die Änderungen mit einplanen und die Programierer hätten kaum noch Änderungen und alles wäre super. Sorry der ing. Teil von mir hat kurz die Oberhand gewonnen.
Aber ich spezifiziere lieber ein wenig mehr am Anfang und hab dann im Verlauf des Projektes weniger Ärger mit Kunden die mir erzählen wollen das sie es anderes gemeint haben. Eine Umfangreiche Spezifizierung zwingt den Kunden sich genau mit dem Problem auseinander zu setzen und hilft dem Programmierer das Programm genauso zu erstellen das es dem Kunden zu 100% nutzt.

Aber ich persönlich liebe ja die Projekte die mit den Worten anfangen: "Machen Sie mal so ein Dingsda zum na Sie wissen schon... Aber das blaue Ding muß unbedingt auch mit rein!".

Marc++us schrieb:

XP bedeutet ja nicht, daß man wahllos und chaotisch die Ereignisse an sich vorüberziehen lässt - XP (und andere Methoden aus diesem Umfeld) versucht ja gerade, ein System in dieses "Einkreisen des Ziels" zu bringen, eine Ordnung und Regelmäßigkeit, und damit eine Planbarkeit. Die Planbarkeit reicht nur bis zum nächsten Zwischenziel, ist dafür aber realistischer und meßbarer. Sozusagen fraktaler.

Ich finde nur die beiden Modelle XP und das Wasserfall Model kennzeichnen fast genau die beiden Ender einer Zeitachse und versuchen beide die chaotische Programmierung abzulösen.

Bin ein Anhander von XP mit Pflichtenheft

cu Jens

[Spacelord]

Ich behaupte mal dass viele die vorgeben sich an XP zu halten,XP mit Drauf-los-programmieren gleichsetzen(wobei ich da net und Unix-Tom ausnehme weil ich da ein unausgesprochenen " " gesehen habe).
Stell doch einfach mal die Frage was es heißt eine Geschichte zu erzählen.Dann wird sich relativ schnell die Spreu vom Weizen trennen(vorausgesetzt du weißt es selber :D) .
Der grosse Nachteil von XP im Vergleich zu anderen "durchgeplanteren" Vorgehensmodellen liegt sicherlich in der Wiederverwendbarkeit des Codes.XP sieht es nicht vor Klassenhierarchien so zu gestalten dass sie wiederverwendbar sind.Allerdings hat sich ohnehin im Laufe der Zeit gezeigt dass gerade die,damals als absoluter Vorteil der Objektorientierung angepriesene,Wiederverwendbarkeit sich für die beiden OOP Flagschiffe C++ und Java eher als Luftblase erwiesen hat.
Die meisten Klassen sind viel zu problemspezifisch als dass man die jemals nochmal brauchen könnte.
Was sollte also dagegen sprechen ein Vorgehensmodell zu nutzen dass frühzeitig Schwächen aufzeigt,richtig nach vorne geht und die späteren User ohne großartige Schulungen in die neue Software "rein wachsen" lässt?

Deine Forderung nach dem perfektem Pflichtenheft ist jedenfalls absoluter Nonsenes.

MfG Spacelord

[mantiz]

Hallo allerseits,
meine Erfahrung ist ebenfalls, dass der Kunde sehr häufig überhaupt nicht weiß, was er will oder aber meint, dass er es vollständig kommuniziert hat, der Entwickler aber dann den Kunden nicht 100%-ig versteht. Oft bleibt das auch nicht aus und keine der beiden Seiten kann etwas dafür. Vom Kunden kann nicht erwartet werden, dass er alle Vorgänge des Entwicklungsprozesses nachvollziehen kann und ebenso kann vom Entwickler nicht erwartet werden, dass er die genaue Vorgehensweise in dem Betrieb des Kunden kennt, wofür er entwickelt. So kann es passieren, dass eine Funktion X für den Kunden selbstverständlich ist, der Entwickler sich aber etwas ganz anderes darunter vorstellt.
Deswegen halte ich es so, dass ich erstmal ein relativ grobes Konzept mit dem Kunden erstelle, wo einzelnen Funktionen beschrieben werden und was insgesamt realisiert werden soll. Während der Entwicklung ist es meiner Meinung nach wichtig, dass der Kunde möglichst häufig über Zwischenschritte informiert wird, nach Möglichkeit mit Testversionen versorgt wird, dass er die bis dahin integrierten Funktionen testen und auf vollständigkeit überprüfen kann. So hat man auch die Möglichkeit während der Entwicklung gewisse Dinge an dem Konzept zu ändern, die dann evtl. noch nicht zu riesig werden, so dass das Budget gesprengt würde. Wenn man anfängt irgendwas zu ändern, wenn eigentlich schon alles fertig ist, dann wird (häufig) der Code unsauber, es ist wesentlich zeitaufwendiger und meistens auch teurer. Da müssen sich beide Seiten einfach flexibel zeigen. Das setzt natürlich ein gewisses Engagement des Kunden voraus, aber so kann der Kunde einem zumindest keine Vorhaltungen darüber machen, weil man ihm ja schließlich ständig die Möglichkeit gegeben hat sofort etwas zu sagen, falls etwas nicht stimmt.

Meiner Meinung nach und aus meiner zugegeben noch sehr kurzen Erfahrung ist dies aber der einzige praktikable Weg für beide Seiten. Hier gibt es zwar immernoch gewisse Mißverständnisse und Kunden, die zu Beginn einmal was sagen wollen und dann erst was fertiges sehen wollen, aber dann sind die selbst Schuld, wenn Änderungen danach kosten.

UML & co. sind zwar eine nette Idee, aber in der Praxis imo relativ unbrauchbar. OK, mein größtes Projekt ging bisher "nur" über knapp 5 Monate zusammen mit noch einem Entwickler, ich weiß nicht, wie es ist, wenn man in einem ganzen Team an einer Software arbeitet, aber wenn man das Projekt dann in möglichst eigenständige Module aufteilt und jedem seinen Teil gibt, dann sollte das auch laufen. Ab einer gewissen Größe kann man nicht mehr alles im Kopf behalten. Da gibt es dann welche, die mit Papier und Bleistift arbeiten, andere mit Excel, Visio oder ähnlichem. Ich mache es gerade so, wie ich Lust habe, aber bisher wollte auch noch kein Kunde eine komplette Dokumentation der Software von mir haben, mit welchen Abhängigkeiten, wo greift was rein, etc., dann würde es evtl. anders aussehen.

Die am meisten von mir genutzten Tools dafür sind:
- Ultraedit
- Excel, Access
- Papier und Kulli (Bleistift mag ich net so)

[net 0]

mantiz schrieb:

Während der Entwicklung ist es meiner Meinung nach wichtig, dass der Kunde möglichst häufig über Zwischenschritte informiert wird, nach Möglichkeit mit Testversionen versorgt wird, dass er die bis dahin integrierten Funktionen testen und auf vollständigkeit überprüfen kann. So hat man auch die Möglichkeit während der Entwicklung gewisse Dinge an dem Konzept zu ändern...

das ist z.b. einer der eckpfeiler von xp. wenn man's so macht dann bekommt man auch öfters solche emails:

Sehr geehrter Herr ....,
Die Software scheint exakt das zu tun, was wir wollten. Auch die Lösung mit
der Konfigurationsdatei finden wir super; wir überlegen sogar gerade, diesen
Mechanisms für ein einfaches "scripting" zu mißbrauchen, um unsere Geräte
(die Datenquellen) nach jedem power-up in einen bestimmten Betriebsmodus zu
setzen, bevor sie senden. Jedenfalls Gratulation !
...
Ansonsten freuen wir uns schon auf die Lieferung der Geräte !

[thats life]

nice