Nie mehr wieder Programmierprojekte ohne ausgiebige Planung
-
Hallo.
Vor kurzem habe ich ein Softwareprojekt für meine Eltern abgeschlossen.
Da ich weitgehend auf eine Analye und Design Phase verzichtet habe, habe ich bei der Implementierung sehr große Probleme gehabt.Ich möchte diesen Fehler in den nächsten Projekten nicht mehr machen, und würde daher gerne eure Vorschläge und Tipps und etc. hören, die man bei der Entwicklung eines Programms braucht. Über Links zu guten Skripten und Texten würde ich mich auch sehr freuen.
-
Also ich hab bemerkt das es oft sehr praktisch ist so ne Art Core zu planen entwickeln und dann alles ... GUI spezifische zu machen ...
-
Kennn nur ein gutes Buch... Software Technik von Balzert (hiess der glaubich) Ist allerdings sehr akademisch und mühsam zu lesen. Ich sehs allerdings ähnlich wie Intrudor:
In der Planung und Analyse würde ich GUI und Funktionalität des Programms immer möglichst trennen. Das ermöglicht auch den einfachen Austausch der Oberfläche...
Meine Design und Planungsphase besteht immer darin, die logisch verwandten Funktionalitäten und Datencontaiern zusammenzufassen und zu Objekten zu erklären. Danach denk ich mir eine "Architektur" aus, wie ich diese OBjekte miteinander verhängen kann, sodass das Ganze funktioniert...
Für das GUI mach ich immer zunächst ein leeres GUI, das die Funktionalität immitiert. Danach lass ich den Auftraggeber damit rumspielen. Gefällts, wird die dummy-funktionalität durch Zugriffe auf den Core ersetzt. Wenn nicht, so wird das GUI gemäss den Wünschen angepasst.
Das Wichtigste ist wohl, dass man sich einwandfrei über die Aufgabe im klaren ist. Meist ist es so, dass der Auftraggeber selber noch nicht so genau weiss, was er eigentlich will. Erst mit dem Kontakt deiner ersten Umsetzung, kann er sich so artikulieren, dass ihr beide vom Selben redet. Das ist meine Erfahrung...
-junix
-
Ja das ist mir schon klar, dass die Daten von der Anzeige getrennt werden sollen.
Das wird von den MFC auch supi unterstützt (Doc/View).Aber ich meine mehr so mit den ganzen UML-Diagrammen und Use Cases usw.
eine Analyse erstellen, dann ein passendes Design und dann die Implementierung.Also im Grunde suche ich eine gute Einführung in UML, und dann etwas wie man mit UML ein Softwareprojekt plant.
Aber die Idee mit der Dummy GUI gefällt mir wirklich sehr gut.
dann hat man nicht immer das Problem, dass der Kunde kurz vor dem Release doch noch ein Feature eingebaut haben will.
-
Ich hab um ehrlich zu sein mit UML bisher noch nichts durchgeplant weil ichs eigentlich nicht gebraucht habe.
Was mir nun schon paar mal so vorgekommen ist .. ist das ich im nachhinein dann nachdem die Kunden wieder Features wollten festgestellt habe das es noch besser und einfacher zu implementieren gewesen wär.
So gut planen das Kunden nix mehr einfällt kannst net.
Nur solltest vielleicht aufpassen das du die Algorithmen nicht primär auf schnelligkeit optimierst sondern viel Platz für Erweiterungen lässt auch wenn die auf kosten der Schnelligkeit gehen ... Weil es bringt dem Kunden im Endefekt ja nix wenn er nen sau schnelles Programm hat aber bei jeder Frage auf Erweiterung kommt ... "soso das wär aber eine Neuentwicklung" ..
edit : Nochmal zu UML .. Bei mir heisst halt immer vom Chef aus .. "Doku ??? Äh erst wenn die Funktionalität steht und alles funktioniert " ... Im Endefekt heisst das dann das gar keine Zeit bleibt um das im Zeit Rahmen vernünftig mitzuführen ... Bei jeder Veränderung müsst man das mit aufschreiben und das ist einfach zu viel .. Außerdem zahlt das ja keiner ..
-
Hi,
ich hab das Buch von der Heide Balzert gelesen (kann mich an den genauen Titel gerade nicht erinnern) die und ihr Mann haben in die Richtung ein paar Bücher geschrieben. Also das von der Heide finde ich nicht schlecht und man kann es sich ganz gut selber beibringen mit den aufgeführten Beispielen. Wenn Du Zeit hast dann geh mal in einen Bücherladen und schau sie Dir an, wenn der Laden groß genug ist dann haben die das bestimmt auch da. Ich habs bisher meistens gesehen ...
Ach ja die Themen sind so grob: Klassen, Assoziationen, Aggregationen, Vererbung, Rollen, Kollaborationsdiagramme, usw... dürfte ausreichend sein.
Das Ganze wird glaub an einem Bsp. durchexerziert.Legoals
-
Ich hänge gerade an UML 2 und bin zunehmend enttäuscht davon - wieder mal ein Gremium, das eine gute Idee durch immer neue Dinge überlädt und unbrauchbar macht. Das ist inzwischen so komplex, daß man während Analyse und Design - noch vor Beginn der Programmierung - UML-Fehler machen kann. Das schlägt bittere Wege ein.
Der ganze große Planungsprozeß (Analyse, Design, Impl, Test) ist bei kleinen Projekten wenig brauchbar, da nicht sonderlich agil und wenig reaktionsfreudig auf Änderungen bei den Kundenwünschen - und gerade bei kleinen Projekten kann man diese weniger gut auf Pflichtenhefte & Co festnageln. Ich finde da einige Ansätze von Agile Development und XP viel schöner, z.B. wie http://www.c-plusplus.net/titelanzeige.php?ISBN=3827317096
-
Danke für den Buchtipp.
Werde mal schauen ob ich noch genug Geld auf der Kasse habe.
Das Feriengeld kommt erst in ein paar Wochen.
-
Frage:
Ist Extreme Programming auch für einzelpersonen als Entwickler?
Also wenn nur einer proggt?
-
Jover schrieb:
Ist Extreme Programming auch für einzelpersonen als Entwickler?
Schwierig. Da Extreme Programming besonderen Wert auf Kommunikation legt. Außerdem wird es auch mit dem möglichst ständig erreichbaren Domain-Experten schwierig. Ich glaube da hilft nur eine ausgefeilte Schizophrenie.
Kleine Iteratioen, Techniken wie Test First und Refactoring sowie Prinzipien wie DTSTTCPW funktionieren natürlich aber auch bei Einzelpersonen.
[edit by kingruedi]hab mal die Quote Tags gefixed[/quote]
-
Nein ich glaube nicht, dass ich schon so Schizophren bin, ein ganzes Entwicklungsteam in mir zu beherbergen.
Welche Wege gibt es dann für eine einzelne Person Projekte zu planen und durchzuführen?
-
Also ich hab das bisher immer so gemacht (wobei ich gestehen muss, dass ich kein großer Planer bin
), dass ich mir ein großes Blatt Papier genommen habe. Erstmal Brainstorming zu dem Projekt gemacht und das versucht zu notieren. Dann habe ich versucht, mir Gedanken über die Implementierung zu machen, in dem ich die grobe Klassenstruktur inkl. Memberfunktionen auf dem Papier notiert habe. Dafür kann man auch gut UML nehmen, damit kenn ich mich aber (noch) nicht aus.Die Programmierarbeit besteht dann eben "nur" noch aus der Implementierung der Memberfunktionen.
Aber bisher war das immer so, dass ich die ersten paar Tage die Skitzen auf dem laufenden gehalten habe (ich hab es nie geschafft, ein Projekt so zu planen, dass wirklich alles funktioniert hat, ich hab ständig eigentlich was am Design geändert, weil mir Dinge eingefallen sind, die ich vorher nicht beachtet hatte
) und dann, nach einer Zeit, hab ich es sein lassen
-
kingruedi schrieb:
... [1]
und dann, nach einer Zeit, hab ich es sein lassen[1]: Ebenso, bloß hab ich noch einen Schmierzettel mit Ideen neben mir liegen und ich versuche viele "// TODO: "- Kommentare in den Quelltext einzubauen.
-
\aleph_0 schrieb:
[1]: Ebenso, bloß hab ich noch einen Schmierzettel mit Ideen neben mir liegen und ich versuche viele "// TODO: "- Kommentare in den Quelltext einzubauen.
jo, dass mit den TODO Kommentaren mach ich auch
-
Kennt jemand von euch die Bücher "UML @ Work" bzw. "Rapid Developement".
Könnt ihr eines Empfehlen?
-
Jover schrieb:
Welche Wege gibt es dann für eine einzelne Person Projekte zu planen und durchzuführen?
Wenn Du von echten Projekten ausgehst (also schliessen wir mal Hobbyprojekte für die Homepage ohne Zielgruppe aus), gibt es eigentlich GAR KEINE Projekte, wo nur eine einzelne Person arbeitet!
Glaubst Du nicht? Doch.
Du gehst jetzt nur von dem Entwickler aus. Aber Du hast im Regelfall schon mindestens eine Person, die ebenfalls beteiligt ist: den Auftraggeber/Kunden. Häufig sogar noch eine weitere Person, nämlich den Tester bzw. denjenigen, der damit arbeiten soll. Oft ist dieser bereits nicht mehr identisch mit dem Auftraggeber.
Also gibt es doch Chancen zur Kommunikation.
Damit kannst Du Dir wohl doch einige der Ideen z.B. von eXP rausziehen, z.B. die schnellen Releasezyklen, oder die intensive Rückkopplung nach jedem Release mit dem Abnehmer.
Denn gerade bei einem einzigen Entwickler ist folgender Weg völlig fatal: Pflichtenheft machen, 4 Monate verschwinden, mit Software wiederkommen. Ein solches Programm erfüllt nicht die Wünsche der Leute, die damit arbeiten müssen, so Sachen werden abgenommen, einige Wochen angesehen, und verstauben dann im Regal.
Je kleiner das Entwicklungsteam ist, desto größer besteht die Gefahr, daß Interpretationsfehler entstehen - also benötigst Du auch als Einzelkämpfer eine intensive Kopplung an den Abnehmer der Software. Und das ist die Erkenntnis, die man auch aus den eXP oder Agile Development-Methoden herausziehen kann.
-
Ja so ungefähr habe ich es bei meinem letzten Projekt ja gemacht.
Ich habe einfach die Wünsche vom Auftraggeber aufgeschrieben, und dann habe ich begonnen zu Programmieren. Nach ein paar Wochen, hab ich ihm dann das erste Release gezeigt, und er hat dann weitere Wünsche eingebracht. Das ging dann so 3-4 mal.Aber das hat meiner Meinung nach nichts mit der Orgranisation des Sources, der Klassenhirachie und dem Design der Anwendung zu tun.
Oder bietet da eXP auch was?Mir geht es darum, dass ich wenn ich die Wünsche des Kunden habe, ich das Programm so code, dass es sauber und Erweiterbar ist.
Erweiterbar, in dem Sinn, dass ich spätere Wünsche des Kunden problemlos einbauen kann.Also:
Wie komm ich vom Wunsch, zu den einzelnen Klassen mit den Daten und Methoden?
-
Ok, Du hast damit aber ein Softwareentwicklungsproblem und kein Projektplanungsproblem. Demnach sind solche Dinge wie UML oder Bücher zum Thema Entwurfsmuster vielleicht näher an Deinem Problem dran.
eXP befasst sich mit dem allgemeinen Projektablauf, nicht mit technischen Festlegungen.
-
Ok, ich hab mich mit der Formulierung etwas vertan.
sind dann die Bücher "Rapid Developement" und "UML @ Work" das richtige?Welches könnt ihr empfehlen?