Schönen guten Abend!

Wollte mal wissen, wie eure Herangehensweise bei euren Projekten ist. Macht ihr vorher alles, was eigentlich dazugehört, also Pflichtenheft, Diagramme, Pläne usw. oder programmiert ihr einfach drauf los? Wie sieht's mit Prototyping aus?

Ich versuche schon meistens mir einen Plan zu machen, was am Ende dastehen soll, aber mehr auch nicht und ich halte mich auch (für meine privaten Sachen) eher weniger an diesen Plan.

Wäre mal interessant zu hören, wie ihr das so macht...

MfG

Merlin83

Interessante Frage:

merlin83 hat folgendes geschrieben:

Macht ihr vorher alles, was eigentlich dazugehört, also Pflichtenheft, Diagramme, Pläne usw. oder programmiert ihr einfach drauf los?

Also ich mach den ganzen Kram nicht. Was nicht heißt, dass ich blind drauflos programmiere. Ein Projekt formt sich in meinem Kopf. Bis ich das aufgeschrieben habe, sind mir jedesmal mindestens schon drei Verbesserungen und/oder Änderungen eingefallen. So hat sich die Brain-Methode trotz aller Kritik (mangelnde Professionalität, bla bla bla, vor allem von s.g. "gelernten" Informatikern) durchgesetzt. Die jeweiligen Auftraggeber waren übrigens immer mit den Ergebnissen mehr als zufrieden. Und bei privaten Projekten bin ich sowieso niemandem Rechenschaft schuldig.

merlin83 hat folgendes geschrieben:

Wie sieht's mit Prototyping aus?

Wenn du damit das Erstellen von Test-Hilfsprogrammen meinst, aus denen man dann funktionierende Teile ins Hauptprojekt übernimmt, dann ja ...

Gruß,
Jörg

Naja, Pflichtenheft gibt's bei mir nur nur in sofern, daß es eine To-Do-Liste für jede Unit gibt, damit ich nicht irgendwas vergesse, was ich noch einbauen wollte, wenn ich grad keine Zeit habe, das sofort zu machen.

Wenn es um kleinere Arbeiten im Unterricht geht, dann geht es sofort los, denn wir bekommen immer eine umfangreiche Arbeitsanweisung. Wenn es aber umfangreichere Arbeiten sind, dann mach ich mir schon nen Plan vorher, z.B. wie die Klassen aussehen müssen, und was überhaupt passieren muss.

Hi, also, ich stimme da .Chef zu. Meine Projekte entstehen auch im Kopf, Änderungen und Verbesserungen kommen während der Arbeit laufend dazu. Ich hab' keine Probleme damit, einen mühsam erarbeitetet Code (ganze Prozedur!) zu verwerfen, wenn ich etwas Besseres finde. Das passe ich dann an und baue es ein.

Allerdings kommt es oft vor, dass ein vermeintlich fertiges Programm beim ersten "echten" Einsatz Bugs hat... *Schäm*

Hi, also, ich stimme da .Chef zu. Meine Projekte entstehen auch im Kopf, Änderungen und Verbesserungen kommen während der Arbeit laufend dazu. Ich hab' keine Probleme damit, einen mühsam erarbeitetet Code (ganze Prozedur!) zu verwerfen, wenn ich etwas Besseres finde. Das passe ich dann an und baue es ein.

Allerdings kommt es oft vor, dass ein vermeintlich fertiges Programm beim ersten "echten" Einsatz noch Bugs hat... *Schäm*

//Edit: wie kommt das denn 2x hier rein?

Tja, ich kann zwar noch nicht viel, aber ich programmier auch einfach drauf los. Wie mein jetziges Chat-Programm, was in Arbeit ist... Ich hab erst mal einen funktionierenden Chat mit sehr wenig Funktionen und der auch nur mit 2 Personen möglich ist. Den hab ich dann kopiert und der Kopierte ist so zusagen mein Testgelände Wenn was schief geht, ist das dann nicht schlimm.

Wenn du so fragst: Naja, ich nutz maximal die ToDo-Funktion von Delphi für Dinge, die ich noch ergänzen muss. Ansonsten formt sich das bei mir auch eher im Kopf.

Derzeit arbeite ich mit einigen anderen hier ausm DF an nem Großprojekt und da ist eigentlich auch nur die Rohform in ner Diskussion entstanden, danach gabs ne Bibliotheksgliederung (für den Teil an dem wir grad arbeiten) und dann wurde eigentlich so weiterprogrammiert, wie das jeder wollte (das einige nicht wollten, sei hier mal außen vor gelassen). Und dann wurde eben nur noch immermal sich ausgetauscht, was grad wo sich geändert hat, oder wo noch was zu ergänzen ist.

Aber für meine eigenen Projekte ist meine Gliederung im Kopf, bis auf, wie oben erwähnt, die Bugliste und liegengebliebenen Aufgaben, die sich als ToDos in der IDE niederschlagen.

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

Papalapap. Also privat kann man das machen wie man will. Ein Pflichtenheft ist privat eigentlich auch Blödsinn. Allerdings sollte man sich im klaren sein was man privat machen will. Da gibt es die

a) Man setzt sich an den Rechner, klimpert ein wenig auf der Tastatur und guckt was da rauskommt;

b) Man will gezielt ein Programm schreiben. In diesem Fall braucht man kein Pflichtenheft, aber ein Plan. Das und das kommt rein und das wars. Tolle Ideen hat man bei der Plannung, nicht beim programmieren. Wenn man beim Programmieren eine Idee hat, dann schreibt man sie auf und baut sie in die nächste Version ein.

Dann gibt es die Aufträge. Zwar gibt es das schnelle Tool was man den Kunden mal eben schreiben kann, aber das tut man nicht. Es gibt auch hier zwei Möglichkeiten

a) Man hat eine Idee, macht sich ein Plan, programmiert das Tool und versucht es dem Kunden das so zu verkaufen;

b) Der Kunde will was haben. In diesem gibt es zwei Möglichkeiten

- es ist was größeres, dann macht man ein Pflichtenheft;

- es ist was kleines, wo ein Pflichtenheft zu viel Arbeit machen würde, dann macht man eine Geschprächstnotiz in der man alle Punkte des Programms niederschreibt. In der Firma schreibt man das dann nochmal sauber auf und schickt das als Bestätigung z.B. per Fax dem Kunden zu. Auf keinen Fall bespricht man ein Programm mündlich. Niemals. Alle bei denen es keine Probleme bei sowas gab hatten Glück. Man kann eine Woche Arbei investieren um dann bei der Vorführung festzustellen, daß er das anders gemeint hat. Hat man eine Geschprächstnotiz, dann kan man zumindest vorweisen, daß das so besprochen wurde. Eine Woche später haben die Kunden meistens eine ganz andere Erinnerung an das Gespräch wie der Programmierer. Also immer schön schriftlich plannen.

Mir ging es bei der Frage eigentlich um zwei Dinge:

1. Theoretisch: Beim Studium lernt man die "Prinzipien der Softwareentwicklung" und wie eine vernünftige Projektplanung aussieht, z.b. Prototyping (explorativ, experimentell, evolutionär usw.), Lastenheft & Pflichtenheft, Strukturierte Analyse (mit Datenflussdiagrammen, Kontextdiagrammen, Prozessspezifikationen) oder Real-Time-Analyse, alles mit Abstraktion, Modularisierung und unter Beachtung tausend anderer Dinge.

2. Praktisch: Wenn man ein Projekt vor sich hat, das weit mehr als 10.000 Zeilen Quellcode haben wird, macht 1. Sinn, da man sonst evt. den Überblick verliert (geht mir zumindest so), wenn man nicht ständig daran arbeitet, sondern aus zeitlichen Gründen ca. 10 Stunden/Woche. Ich habe so ein Projekt vor mir und habe außer ein paar Notizen auch keine Planung gemacht (leider).

Wenn man aber nur ein kleines Progrämmchen entwickelt, macht 1. natürlich keinen Sinn. Macht man es aber doch, lernt man die Vorgehensweise und kann sie bei Bedarf anwenden.

Bei mir gibt es so viele Abhängigkeiten, dass ich mir wünsche, dass solche Pläne vorhanden wären. Warum mache ich sie nicht selbst? Weil es zuviel Aufwand ist. ->Zwickmühle.

Aus euren Antworten entnehme ich, dass ihr - wie ich - nicht viel von Planung haltet, sondern auch eher dem Extreme Programming verschrieben seid. Ist ja auch ne Variante...


MfG

Merlin83

bms hat folgendes geschrieben:

Der Kunde will was haben. [...] Pflichtenheft [...] Gesprächsnotiz

Gesprächsnotizen mach ich netürlich auch, dass sehe ich aber nicht unbedingt als "schriftliche Planung" an, sondern mehr als Verständigungshilfe zwischen dem Kunden und mir. Aber was heißt "der Kunde will was haben"? Nachdem er seine Vorstellungen dargelegt hat, sage ich, dass es soundso lang dauert, und abhängig davon wirds bei größeren Sachen entsprechende "Zwischenstände" geben. Wobei ich bis jetzt kaum "Endkundenprojekte" gemacht habe, sondern vielmehr Software als Bestandteil eines größeren Projektes. Da muss man sich nur mit dem Chef einig werden. Und dem sind nur zwei Dinge wichtig: Schafft man die Deadline, und funktionierts? Wie man diese 2 Punkte erfüllt, ist egal.

merlin83 hat folgendes geschrieben:

Aus euren Antworten entnehme ich, dass ihr - wie ich - nicht viel von Planung haltet, sondern auch eher dem Extreme Programming verschrieben seid. Ist ja auch ne Variante...

Tja, den Seinen gibts der Herr im Schlaf.

Die Sache mit dem Studium ist die: Viele kommen her und sind programmiertechnisch totale oder zumindest relative Anfänger. Natürlich muss man diesen Leuten irgendeine systematische Vorgehensweise nahelegen, da sie sonst nie auf einen grünen Zweig kommen. Wenn man aber über eine gewisse Erfahrung verfügt, hat man mit der Zeit herausgefunden, welche Planungsschritte man selbst benötigt oder wie man seine Planung am besten einteilt.

Natürlich kommt es immer auf die Größe und vor allem auch die Art des Projektes an, aber ich empfehle drigend das Pflichtenheft nicht außer acht zu lassen. Es gibt verdammt merkwürdige und kranke Menschen auf dieser Welt, die mit vorliebe kranke Aufträge vergeben. Da ist ein Pflichtenheft kein Zeitverlust, sondern die eigene Absicherung, dass man exakt das gemacht hat, was einem aufgetraten wurde (mit unterschriften etc einholen, sonst behaupten sie irgendwann, dass Ding nie gesehen zu haben...) Nur ein Tipp, wenn Euch etwas spanisch vorkommt beim Auftragsgeber und der nicht gerade mit einem zusammen am gleichen Stricke hängt

Zuerst einmal möchte ich im Großen und Ganzen bms Recht geben. Aber die Diskussion um das Pflichtenheft führt meiner Ansicht nach etwas am Thema vorbei. Ein Pflichtenheft MUSS anhand der Spezifikation des Auftraggebers erstellt und von ihm abgesegnet werden. Es ist ausserdem auch immer Grundlage eines Vertrages. Wenn einer Aufträge annimmt ohne ein Pflichtenheft zu erstellen, tja dann ist er selber Schuld, da im Streitfall eine schriftliche Grundlage fehlt (Ob man das jetzt im kleinen Gesprächsnotiz nennt oder im großen Pflichtenheft ist egal. Der Inhalt ist der gleiche).

Aber nun zurück zum Thema. Man kann nämlich auch mit Pflichtenheft extreme Programming anwenden. Das Pflichtenheft beschreibt ja hauptsächlich das Ziel und nicht den Weg. Und ganz ohne Vorstellung was man eigentlich programmieren will kommt man auch nicht zu einem vernünftigen Programm. Projektplanung heißt natürlich Klassendiagramme erstellen usw.. Diese müssen nicht zwangsläufig Teil des Pflichtenhefts sein. Aber ob man sich die Gedanken nur im Kopf macht oder auf Papier ist eigentlich egal (kommt auf die persönliche Gedächtnisleistung an).

Der wesentliche Unterschied zwischen "extreme Programming" und einem geplanten Softwareentwicklungsprozess liegt in der Vorgehensweise während der Entwicklung und weniger in der vorhergehenden Planung. Nun und da ist die Frage wann macht es Sinn genau festzulegen welche Funktionen in welcher Reihenfolge implemtiert werden, und wann Test/Debugphasen in welchem Umfang und mit welcher Testumgebung einfliessen. Und da ist es meiner Ansicht sinnvoller nach Planung vorzugehen und zum Beispiel zunächst sämtliche Schnittstellen festzulegen und die gesamte Klassenhierachie zu Implementieren erst dann merkt man wenn man einen kleinen Denkfehler gemacht hat, und ob sich eine Funktion die man "irgendwann mal" einbauen will sich dann überhaupt verwirklichen lässt. Generell (ausser bei sehr sehr sehr kleinen Tools) spart man sich viel mehr Zeit, wenn man ein wenig Zeit in die Planung des Programms und in die Planung der Entwicklung gesteckt hat. Insofern ist es einfach nur eine Frage der Lust und weniger der Zeit.

Ich gebe Alni soweit bei allem Recht. Der Punkt ist nämlich der: Macht man sich die Mühe der Planung (ausgehend von hinreichend großem Programmieraufwand), kommen nicht nur weniger Fehler in die Software, sondern die Programmierung selbst geht zuverlässiger bzw. einfacher von der Hand. Weiterer Vorteil ist, dass ein Außenstehender sich leichter in die ausprogrammierten Details reinfitzen kann.

Ich finde es nur schade, dass der Aufwand anfangs erstmal größer ist und dadurch abschreckt. Ich habe ja schließlich keine Lust, mich stundenlang hinzusetzen und Diagramme zu malen (auch wenn das teilweise durch Tools erledigt wird). Wenn natürlich alle ohne Planung glücklich und zufrieden sind, ist das auch ok, war es bei mir bisher auch. Jedenfalls habe ich mir jetzt vorgenommen, in Zukunft bißchen mehr Wert auf die Planung zu legen, da meiner Meinung nach davon auch die Qualität der Software abhängt. (Das soll jetzt nicht gegen Software sprechen, die mit einer anderen Herangehensweise erstellt wurde.)