Planen grösserer projekte (C++)
-
Codehure schrieb:
Pflichtenheft
- genaue Abstimmung was der Kunde haben willHat 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.
-
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
-
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?
-
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
-
Soweit zur Theorie...
-
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.
-
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)
-
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
-
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
-
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)
-
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.
-
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
-
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
-
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)
-
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 !
-
nice
-
In ein Pflichtenheft gehört rein was die Software machen soll. (Funktionalität)
Es gehören Grundsatzdinge rein wie die Software aussehen soll.In Verbindung mit XP sieht er in kurzer Zeit ob es seinen Vorstellungen entspricht.
Den Kunde ist es egal welche Klassen oder Ansätze dazu führen.
Wüsste er das würde er nicht programmieren lassen. Von Firmen die Auslager mal abgesehen. Hier muss man sogar Bibliotheken nutzen die vorgegeben werden.XP schließt ein Pflichtenheft nicht aus.
Zu Wiederverwendbarkeit:
Ich habe hier viele eigene Biblotheken, welche ich immer wieder verwende.
Projektspezifische Klassen braucht man sowieso nicht.
Sollte ich jedoch bemerken eine Klasse auch später mal brauchen zu können dann erstelle ich sie so das ich sie auch später verwenden kann.XP sagt aber auch bereits aus das man im Team Programmieren kann. Ein Programm wird in wichtige Teile und Funktionalität geteilt.
So kann jeder Entwickler eine Teil machen und über eine Schnittstelle einbinden.
-
...
Die Software scheint exakt das zu tun, was wir wollten. ...sehr nice.
tut sie's jetzt, oder sieht das nur so aus?Hast aber recht, häufig wird es dann so belohnt.
-
stimmy schrieb:
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?
Ist Geschmackssache, sicherlich hab ich alle Dokumente im PC, aber gerade wenn ich nicht 100%ig sicher bin, was ich wie machen will, nehm ich das WB. Da schreib ich dann z.B. Klassen mit ihren Funktionen und Attributen drauf, schreib mir skizzenartig auf was eine Funktion koennen muss oder (da ich viel mit Grafik mache) mache mir Skizzen und Zeichnungen um mir klar zu machen ob z.B. die Transformationen stimmen.
Du kannst auch auf dem WB alle noch zu implementierenden Klassen notieren und als Motivation immer die wegstreichen die fertig sind.Ist halt echt Geschmackssache genau wie manche lieber Notizen im PC als auf Papier erfassen. Teuer ist so ein WB allerdings nicht, mein altes WB war einfach ein lackiertes Pressspahnbrett (sowas wie ne Schrankrueckwand) aus dem Baumarkt, 2m2 fuer 14 EUR und dann nicht-wasserfeste WB Marker und Fensterputzmittel. Sieht nicht so elegant aus wie die teuren teile in Bueros, aber fuer daheim allemal ausreichend. Im Moment hab ich kein Platz fuer das grosse Ding und hab 2 IKEA WBs (je 80x60) aus Metall.
Die Teile haben halt noch den Vorteil, dass man auf 2qm wesentlich mehr auf einem Blick darstellen kann als auf einem 17" oder 19" Bildschirm.
-
Moin Moin
pli schrieb:
Die Teile haben halt noch den Vorteil, dass man auf 2qm wesentlich mehr auf einem Blick darstellen kann als auf einem 17" oder 19" Bildschirm.
Und die Benutzung ist wesentlich einfacher als die Benutzung der Software Tools .
cu Jens