wie geht man bei großem Projekt vor????

[tobiasw]

ich wollte mal fragen wie ihr vorgeht wenn ihr größere Projekte plant zu entwickeln??? Mach ihr Programmablaufpläne oder wie geht das?

Gruß

[SirThornberry]

Also bei uns wird einfach erstmal das Zielproject geplant. Also was alles zu dem Project gehört. Bei programmen was das Programm können soll. Und dann wird gesagt wer welchen Teil davon umsetzt.

[PierreB]

moin,

also größere projekte hab ich zwar noch nicht weiter gemacht, aber meistens nehme ich
mir zettel und stift, schreibe auf was das programm machen soll und welche funktionen es überhaupt hat.

dann mach ich so eine art liste wie
form1 = hauptprogramm
form2 = optionen
form3 = hilfe
usw.

danach realisier ich soweit es geht alle forms und schmeiß sie zusammen.

wenn du ein größeres projekt machen willst solltest du darauf achten alles gut zu benennen,
sonst wirds schnell unüberichtlich !

[SirThornberry]

Und bei größeren Projekten die Objectorientierung nicht aus den Augen verlieren. Da oftmals das Projekt von mehreren Realisiert wird und jeder nur einen Teil davon baut sollte dann alles ohne Problem zusammengefügt werden können. Also keine Globalen (da sonst eventuell Konflikte auftreten wenn anderen auch Globale mit gleichem Namen verwenden). Und bevor man loslegt werden noch Schnittstellen definiert. Also wenn einer das "Hauptfenster" programmiert und der anderen die "Optionen" dann wird definiert wie die Optionen aufgerufen werden. Und sobald dann eine dummyfunktion zum Optionsaufruf vorhanden ist (die funktion muss noch nicht wirklich was machen) gibt man den teil frei so das die anderen die Schnittstellen schon nutzen können. Am besten geht es wenn man erst alle Methoden und Properties declariert (also Methoden die noch leer sind und nichts machen) so das andere in ihren Modulen schon die Funktionsaufrufe einbauen können. Anschließend füllt dann jeder seine Methoden und wirft ab und zu mal ein Update seiner Objecte in die Runde damit die anderen in ihren Testprojekten Ihre module und aufrufe testen können.

[malo]

Also zuerst einmal 'ne Featureliste, was das Programm können "muss", also was unentbehrlich dafür ist. Danach eine zweite Sparte Featureliste, was du dir sonst noch so überlegst. Am besten zu jedem Feature eine kleine Erklärung schreiben, wie du dir vorstellst, es umzusetzen. Also in erster Linie fragen wie "VCL - non VCL", "Grafik womit? DelphiX, DirectX, OpenGL oder reine Delphi-Language?", "Delphi Version", "Mit welcher Komponente realisierbar? (Button oder SpeedButton? Memo oder RichEdit? Wie Sounds abspielen?)", "was für Sounds brauch ich?", "Ist mp3 notwendig oder reichen MIDI?" usw...

Sind zwar teilweise recht unnütze Fragen, die man sich da stellen sollte, die aber trotzdem einiges entscheiden können. Beispielsweise die Größe der .exe. Oder die Programmgeschwindigkeit. Wenn man zu lange und zu komplexe Funktionen eingebaut hat, wird das Prog dementsprechend langsamer, wenn man zu viele bzw. die falschen Kompos eingebunden hat, kann die .exe am Ende zu groß werden, wenn das Projekt enstprechend groß ist.

Außerdem solltest du eine genaue Aufgabenverteilung machen, wer was macht, wenn das Projekt eine Gemeinschaftsarbeit ist.

Außerdem solltest du das ganze mit jemanden besprechen, da eine einzelne Person meist viele Sachen vergisst, die einem zweiten sofort einfallen. Besonders praktisch ist das, wenn man sowieso ein Gemeinschaftsprojekt macht, da man dann sowieso Mitarbeiter hat. Von denen kann man sich dann einen oder zwei rauspicken, die dann mit dir die Sachen besprechen



Ich hoffe, ich konnte dir helfen



PS: Gehört das nicht eher in K&T?

[CalganX]

Hi,
ich werfe mal das Stichwort Application-Lifecycle-Management (kurz ALM) ein (ich liebe dieses Wort ). Das Prinzip ist folgendes: jede Stufe des ALM steht für eine Stufe der Entwicklung. Beginn beim Festlegen der Requirements (was wird das Programm können müssen?) bis hin zur Datenausgabe (wie bekommt der Benutzer die Daten zu Gesicht?).

@Delphman: das mit dem Bleistift und dem Papier ist eine gute Idee, allerdings würde ich erstmal ganz anders anfangen. Das Designen der GUI ist eine Sache, die wohl erst am Ende kommt. Wichtiger ist erstmal, was das Programm macht, dann wie das Programm die Aufgaben bewältigt. Erst dann kommt die Entwicklung. Und selbst dann ist die GUI-Entwicklung unwichtig. Es geht jetzt erstmal darum, dass die verschiedenen Objekte (Stichwort OOP) richtig funktionieren und die Abläufe des Programmes gesichert sind. Wenn das alles funktioniert und getestet wurde, kommt erst die richtige GUI-Entwicklung.
Hört sich so an, als ob das nur Theorie wäre, aber die meisten großen Projekte arbeiten so. Und Borland bietet hierfür ja auch ihre ALM-Lösungen an (zu finden auf der Borlandwebsite).

Ich schreibe im Moment einen Artikel über ALM, der hier auch mal veröffentlicht wird, wenn er fertig ist.

Chris

[Jelly]

Also ich habs nie richtig gelernt, weder in Schule oder Uni. Eigentlich alles durch "Learn by doing" und viel lesen...

Was Chakotay schreibt, ist unbedingr zu beachten, wenns auch nicht immer leicht fällt: Die strikte Trennung zwischen Funktionsumsetzung und GUI.

Ich programmier in erster Linie mit Datenbanken, und da geh ich wie folgt vor:
1. Ich überleg mir genau, was das Programm können muss. Das schreib ich mir stichwortartig auf.

2. Dann überleg ich mir die Datenstruktur wie ich alles speichern soll, und wie die Zusammenhänge zwischen meinen Daten liegen.

3. Anschließend mach ich mir recht viele Gedanken, über Methoden im Programm, die ich sicherlich immer wieder verwenden werde. Diese Methode kapsel ich dann meist in Klassen, wenn ich sehr flexibel bleiben will, und das genaue Verhalten über Eigenschaften anpassen kann. Wenn ich faul bin oder unter Zeitdruck steh, kommt eine einfache Funktion auch mal einfach so global in eine Unit. Letzteres versuch ich, wos geht, jedoch zu vermeiden.

4. Somit steht erst mal das Grundgerüst. Dann gehts so langsam an die erste Zeile programmieren.

Ich komm mit dem Verfahren recht gut klar, und behalt auch den Überblick bei größeren Projekten. Kompliziert wirds allerdings, wenn du im Laufe der Programmierung entweder auf unerwartete Probleme stößt, oder dir der Auftraggeber plötzlich mit neuen Sachen kommt, die er aber auch unbedingt haben will, diese aber nicht wirklich ins bisherige Konzept passen. Denn dann fängt oftmals das Gewurschtele an, am besten das Ganze auch noch unter Zeitdruck. Ich häng da momentan schon Jahre lang in so einem wirklich großen Projekt. Zum Glück sieht nachher keiner den Quellcode, denn der ist zum Teil unter aller S**. Das Projekt war so groß, aber von Anfang an einfach nicht klar genug definiert. Immer wieder kamen neue Ideen auf, die auch noch unbedingt aufgenommen werden müssen. Das Gescheiteste wäre wohl, das Ganze Projekt nochmals von neuem zu starten.

Was ich mit Letzterem sagen will, man kann nicht genug Zeit in die Planung investieren, denn spätestens in der Schlußphase des Projekts tauchen nach Murphys Gesetz immer irgendwelche Probleme auf, und diese gilt es so klein wie möglich zu halten. Das ist leichter gesagt als getan, und erfordert sicherlich etwas Erfahrung.

Gruß

[stoxx]

Hi Tobias,


dass was meine VorRedner hier sagten, nennt sich MVC Modell.
Falls Du in diesen Grundlagen noch nicht vertraut bist, unbedingt ansehen !

http://fara.cs.uni-potsdam.de/~kaufmann/tuts/mvc.pdf

Ziel ist es, so zu programmieren, dass die GUI unabhängigt von "konkreten Berechnungen" ausgetauscht werden könnte und kann, und damit auch flexibel verändert werden könnte.

von einer getrennten Entwicklung dieser beiden Dinge, wie es Chakotay1308
empfohlen hat, rate ich aber ab, da Programmierer keine MAschinen sind.
Die Funktionalität ist nämlich nicht das wichtigste im Programm.
Genauso könnte ich behaupten, fang erst mit der GUI an, definiere dort die Proceduraufrufe an ein "Funktionsobject" und implementiere dann die Funktionen. Nein, das wäre genauso falsch.
Ausserdem will ein Mensch, was programmierer sind, auch mal ein Erfolgserlebnis haben und sehen was sein programm macht, eben in der GUI ! (für kleine Kinder sind es die Bauklötzer )

In einem Programm sind sicherlich viele Dinge zu beachten. Eine Ingenieurs Ebene, Design Fragen, Bedienbarkeitsfragen, Ergonomie usw.
Wenn die Ergonomie zum Beispiel eine übergeordnete Rolle spielt, dann muss sich eben die Implementierund anpassen und sich der GUI unterordnen.

Wie groß soll denn Dein Project werden ?

[stoxx]

hier noch paar Links für Dich gefunden.

Verschiedene Modelle !

http://www.sts.tu-harburg.de/~r.f.mo...03-Planung.pdf

Bitte Seite 12 beachten
Am teuersten ist die Fehlersuche, hab letztens erst einen Vortrag gesehen, dass es wohl Untersuchungen von IBM gibt, in denen sich herausgestellt haben, dass die häufigsten Fehler wohl schon in den Requirements verborgen liegen.
Und dass der Kosten und Zeitaufwand einen beliebigen Fehler zum Schluss in der Wartungsphase (Beim Kunden oder im fertigen Produkt) wohl ungefähr bis zum 100 fachen liegen können.
Also man hätte für einen Euro den Fehler beheben können, wenn man ordentliche Requirements gehabt hätte, diesen Fehler beim Kunden zu beheben ist 100 mal teurer ...


http://www.sts.tu-harburg.de/~r.f.mo...ures/se-ss-04/

Das V - Modell nimmt man wohl heute .. ab Seite 26 ..
-> http://www.sts.tu-harburg.de/~r.f.mo...ensmodelle.pdf

.. kenn mich aber in sooo großen Projekten auch nicht aus

[mimi]

dazu hätte ich eine frage und ein vorschlag:
ich schreibe derzeit ein spiel es wird nach meinen vorstellung doch ein größers projekt mein problem ist eifnach die unübersichtlichkeit und evtl. auch die falsche planung(mal schauen was ihr dazu meint)

Im moment schreibe ich nichts auf oder sowas sondern mach mir einige zeit einige gedanken über das projekt und sobalt alles klar ist fange ich einfach so an und überlegt mir dann wie ich alles defniere im jetztigen projekt:
ich habe eine einfache klasse: TGame in der klasse habe ich mehre record:

TObj
in TOBj: TWalls, TPlayer, TDoors,....
das sind alles record

die haben unterschiedliche variabeln:
TWalls: x,y,w,h:Integer; tc,hc:TColor
TPlayer,y,w,h,tex,punkte:Integer; Name:String
.....

das problem ist jetzt aber das mekre ich bei jedem projekt:
wenn ich alles funktionen die ich brauchen werde vorbereite also überlege welche parmeter sie brauchen wie sie heißen soll und dann defniere und kometiere und dann anfangen sie mit "Leben" zu füllen geht es viel einfach ales wenn ich mit der Create funktion anfangen und sage: der rest kommtvon alleine. Ich stele mir das irngeiwe so vor: wie beim schach(ich kan dies nicht*G*), du musst genau überlegen welchen stein die wan am besten ziehst !


vorschalg:
da dieses Prolem bzw. Fragen wohl häufige gestelt wird(zwar nicht hier aber jeder der ein projekt anfängt) könnten wir doch ein beispiel projekt schreiben was wir genau planen und vorbereiten was haltet ihr davon ???