Software-Entwicklung und -Planung
-
void* schrieb:
Meine Idee:
1. detailiertes Pflichtenheft
2. ausarbeiten eines abstrakten Designs der Software
3. Definition von Schnittstellen und der wichtigsten Mechanismen/Algorithmen, Festlegung
welche Module/Klassen gebraucht werden und was Ihre Aufgaben sind (beliebig detailliert möglich)
4. ImplementierungJa nur das wird nicht funktionieren.
Meine Argumente:
der Bedarf an Entwicklern ist während der Pflichtenhefterstellung sehr viel geringer, später beim coden höher - Du nutzt die Resourcen ungeschickt aus, erst hast Du zuviele Leute, später zu wenige
Du hast in Deinem Plan keine Iteration vorgesehen, d.h. Du gehst davon aus, daß das Pflichtenheft vollständig und wohldefiniert ist - im Regelfall ist dem nicht so. An welchem Punkt wirst Du Fehler im Pflichtenheft korrigieren?
Es gibt immer Rückwirkungen von der Implementierung in die Phase 3 des Designs, weil sich herausstellt daß der Aufbau ungeschickt ist. Viele Dinge lassen sich planen, aber sie sind nicht zu 100% durchdachte (einfach weil die dynamische Interaktion im Voraus sehr schwer durchschaubar ist).
Late prototype: Eure erste Softwareversion wird erst nach sehr langer Zeit startbar sein. Dadurch wird die Geduld der Geldgeber/Kunden sehr strapaziert und das Vertrauen in diese Vorgehensweise nicht gefördert.
das von Dir vorgestellte Entwicklungsmodell wird allgemein als veraltet betrachtetBei Eurem Problem und der Teamgröße könnten einige Ideen von XP sehr hilfreich sein: http://www.c-plusplus.net/titelanzeige.php?ISBN=3827317096
Vor allem die Codierungsstandards werden durch einige Ideen wie Teamprogramming und/oder Codereading sehr leicht eingeführt und auch im Alltag überprüft.
-
Was du (void*) geschrieben hast, sieht nach dem Wasserfallmodel aus.
Mit der Organisation von Softwareprojekten haben sich schon viele leute befasst. Es wurden dem entsprechend viele Modelle entwickelt, wie man soetwas angehen könnte. Das wohl einfachste Model ist in der Tat das Wasserfallmodel, das nicht unbedingt das beste ist (-> Marc++us). XP ist auch ein Vorgehensmodel, was vor allem in den letzten beiden Jahren so richtig bekannt geworden ist.
Auf jeden Fall solltest du dir erstmal einen kleinen Überblich verschaffen, was es da so alles gibt (XP ist dabei mit Sicherheit einer der Favoriten). Als Quelle dazu fallen mir zunächst nur Bücher von Helmut Balzert ein (Hab momentan keine Quellen hier).
Das richtige Entwicklungsmodel ist auf jeden Fall abhängig von der Firmenstruktur und dem Projekt selber. Es kann durchaus sein, das ein Entwicklungsmodel in einem Projekt gut funktioniert, im anderen jedoch einiges an Problemen mit sich bringt. Gute Entwicklungsmodelle minimieren jedoch zimlich gut eventuelle Probleme.
* Kein Mensch würde auf die Idee kommen z.B. eine Maschine nach dem Schema zu bauen, wie hier Software entsteht
Hierzu nur noch folgendes: Software wird entwickelt, nicht produziert. Ein Vergleich mit dem Automobilbau: Softwareentwicklung entsricht nicht der Produktion des Autos sondern am ehesten der Phase bis zur Erstellung des ersten Prototyps.
Solche Vergleiche hört man immer wieder - das sind Analogien, die zu absolut falschen Schlussfolgerungen führen können - deshalb sind sie gefährlich und gehören eigentlich verboten (hart ausgedrückt).
-
tunichtgut schrieb:
Hierzu nur noch folgendes: Software wird entwickelt, nicht produziert. Ein Vergleich mit dem Automobilbau: Softwareentwicklung entsricht nicht der Produktion des Autos sondern am ehesten der Phase bis zur Erstellung des ersten Prototyps.
Solche Vergleiche hört man immer wieder - das sind Analogien, die zu absolut falschen Schlussfolgerungen führen können - deshalb sind sie gefährlich und gehören eigentlich verboten (hart ausgedrückt).
Dem muß ich deutlich widersprechen.
Der Vergleich Maschinenbau - Softwareentwicklung ist durchaus richtig, wenn man darunter die Konstruktionsphase der Maschine einbezieht. Dort wird konstruiert, skizziert, simuliert, Modelle gebaut, und dann wieder begonnen, bevor am Ende dann Teileskizzen entstehen - womit die Produktion beginnt. Ab hier verschwindet die Analogie. Aber die gesamte technische Entstehungsgeschichte heißt in beiden Fällen Entwicklung, aber bei der Software wird daraus oftmals nur "Bastelei".
-
Ja nur das wird nicht funktionieren.
*Seufz*
Meine Argumente:
der Bedarf an Entwicklern ist während der Pflichtenhefterstellung sehr viel geringer, später beim coden höher - Du nutzt die Resourcen ungeschickt aus, erst hast Du zuviele Leute, später zu wenigeDas sehe ich in unserem Fall weniger als Problem an. Für Leute die nicht ausgelastet sind gibt es genügend kleinere Aufgaben die schon längst einmal angegangen werden sollten.
Du hast in Deinem Plan keine Iteration vorgesehen, d.h. Du gehst davon aus, daß das Pflichtenheft vollständig und wohldefiniert ist - im Regelfall ist dem nicht so. An welchem Punkt wirst Du Fehler im Pflichtenheft korrigieren?
Es gibt immer Rückwirkungen von der Implementierung in die Phase 3 des Designs, weil sich herausstellt daß der Aufbau ungeschickt ist. Viele Dinge lassen sich planen, aber sie sind nicht zu 100% durchdachte (einfach weil die dynamische Interaktion im Voraus sehr schwer durchschaubar ist).Sorry, war von mir natürlich nicht beschrieben. Ein zurückgehen soll natürlich möglich sein. Ich würde das im Vergleich zum heutigen Vorgehen (SEHR viele Iterationsschritte) bloss gerne etwas bremsen.
Late prototype: Eure erste Softwareversion wird erst nach sehr langer Zeit startbar sein. Dadurch wird die Geduld der Geldgeber/Kunden sehr strapaziert und das Vertrauen in diese Vorgehensweise nicht gefördert.Das kann uns zum Glück ziemlich egal sein, da das Software für die eigene Verwendung ist, d.h. der Termindruck ist relativ niedrig.
das von Dir vorgestellte Entwicklungsmodell wird allgemein als veraltet betrachtet*Seufz*
Bei Eurem Problem und der Teamgröße könnten einige Ideen von XP sehr hilfreich sein: http://www.c-plusplus.net/titelanzeige.php?ISBN=3827317096
Vor allem die Codierungsstandards werden durch einige Ideen wie Teamprogramming und/oder Codereading sehr leicht eingeführt und auch im Alltag überprüft.
Danke, werde ich mir mal zu Gemüte führen.
...
Auf jeden Fall solltest du dir erstmal einen kleinen Überblich verschaffen, was es da so alles gibt (XP ist dabei mit Sicherheit einer der Favoriten). Als Quelle dazu fallen mir zunächst nur Bücher von Helmut Balzert ein (Hab momentan keine Quellen hier).Ok, ich werde mich auch nach Balzert'scher Literatur umsehen.
Das richtige Entwicklungsmodel ist auf jeden Fall abhängig von der Firmenstruktur und dem Projekt selber. Es kann durchaus sein, das ein Entwicklungsmodel in einem Projekt gut funktioniert, im anderen jedoch einiges an Problemen mit sich bringt. Gute Entwicklungsmodelle minimieren jedoch zimlich gut eventuelle Probleme.
Sehe ich ein.
Zitat:
* Kein Mensch würde auf die Idee kommen z.B. eine Maschine nach dem Schema zu bauen, wie hier Software entstehtHierzu nur noch folgendes: Software wird entwickelt, nicht produziert. Ein Vergleich mit dem Automobilbau: Softwareentwicklung entsricht nicht der Produktion des Autos sondern am ehesten der Phase bis zur Erstellung des ersten Prototyps.
Solche Vergleiche hört man immer wieder - das sind Analogien, die zu absolut falschen Schlussfolgerungen führen können - deshalb sind sie gefährlich und gehören eigentlich verboten (hart ausgedrückt).
Ok, wiederum schlecht formuliert.
* Kein Mensch würde auf die Idee kommen z.B. eine Maschine nach dem Schema zu entwickeln/entwerfen, wie hier Software entsteht.
Mir gefällt dieser Vergleich (besonders hier in einem Maschinenbauunternehmen) sehr gut, aber ich bin ja schon still...
Danke an alle und gruß
void*
-
Vor allem noch was beachten: willst Du eine neue Methode einführen, so mußt Du dies mit meßbaren Vorteilen begründen:
spart Geld
ist schnellerDies sind in einer Firma die einzigen Argumente, die stechen. Sachen wie "macht man so nicht" oder "ist besser" oder "ist veraltet" sind weniger gut argumentierbar, weil man dann immer das "hat doch bisher immer funktioniert" entgegen halten muß.
Dein Argument mit dem Termindruck kann ich nicht akzeptieren. Auch bei internen Projekten fragt sich irgendwann jemand, was er für sein Geld bekommt und wo die Sache bleibt. Außer Ihr seid eine so große Firma, daß Ihr auch mal 5 Jahresgehälter verpulvern könnte ohne daß es jemand bemerkt.
Schnelle Lieferung von Software stärkt das Vertrauen in Eure Abteilung und auch in die neue Methodik. Das ist auch bei internen Projekten immer ein Pluspunkt für Euch - und wie gesagt für die neue Vorgehensweise.
Ich kenne die Argumentation mit der Zeit, gerade bei Firmen, die nicht nur Software machen - andere Bereiche liefern Dinge nach Zeitplänen ab, aber "Software dauert halt". Das hat sich so in den Köpfen festgesetzt, daß es als stehendes Gesetz gültig wurde. Gefallen tut es nicht, aber es wird akzeptiert. Unterschätze aber nicht, daß sich viele Leute trotzdem heimlich wünschen, daß Software planbarer und überschaubarer entwickelt wird. Eines Tages wird jemand bei Euch in der Firma mal ein Angebot für die gleiche Software bei einem externen Entwickler einholen und überrascht feststellen, daß es nur ein Drittel kostet. Dann habt Ihr ein Problem. Viele Softwareabteilungen in "Gemischtfirmen" haben sich dadurch völlig aufgelöst. Ich kenne hier im Umkreis einige Maschinenbauer, die überhaupt keine eigene Softwareabteilung mehr haben, obwohl die Steuerung sehr wichtig ist. Da sind noch 2 SPS-Leute fest drin, aber alles bzgl. PC wird extern gemacht.
-
Kann Marc++us hier voll und ganz aus eigener Erfahrung zustimmen. Ich sitze seit vier Jahren direkt beim Kunden (größter Autokonzern in Europa) in den Projekten. Und letztendlich zählt hier nur das Ergebnis. Obwohl hier alles nur interne Projekte sind, haben alle Projekte Termindruck. Weil letztendlich die Anwender sich nicht dafür interessieren, ob und wie wir entwickeln.
Am Anfang wissen wir nur, um welches Thema es geht und wie bisher der Workflow im Konzern abläuft. Die eigentlichen Features, Datenbank-Tabellen etc. entstehen on the fly. Es ist nichts ungewöhnliches, das jede Woche ein Coder zum DB-Entwickler ankommt, und ein neues Feld oder eine neue Tabelle benötigt. Und das auf zwei Jahre gesehen! Die User selbst fangen dann sogar mit der Software zu arbeiten, obwohl sie noch voll in der Entwicklung steckt. Wir geben dann immer Versionen raus, die "ungefährlich" sind.
Pflichtenheft? Hab ich einmal gesehen, in drei Projekten. Selbst Online-Hilfen und Handbücher für den Endanwender gibts nicht. Das KnowHow ist nur in den Köpfen der Entwickler und Fachabteilungen drin. Wer was wissen will, fragt nen Kollegen.
So sieht es in Wirklichkeit in Projekten aus. UML-Tools usw. hat hier auch noch nie jemand benutzt. Manchmal frage ich mich, wie Rational Rose Umsatz macht.
-
Artchi schrieb:
So sieht es in Wirklichkeit in Projekten aus.
Du hast zwar recht, was nicht impliziert, dass das gut ist... ... und einen sanften Gegentrend zu erwirken ist bestimmt nicht verkehrt... aber man sollte nicht 3 stufen auf einmal nehmen.
-junix
-
Diese Arbeitsweise kann ich bei uns so nicht bestätigen. Bei größeren Projekten gibt es immer eine Pflichtenheft. Dem geht ein Projektauftrag voraus (kurze Beschreibung des Projekts, Meilensteine, Aufwände der Beteiligten, Maschinenanforderungen....). Schließlich muß ja erstmal festgestellt werden, was unsere Kunden (die anderen Abteilungen) überhaupt wollen. Meistens wissen die das nämlich selber nicht so genau. Deshalb sitzt man oft und teilweise lange zusammen und erarbeitet das erst einmal. Klar ist, daß sich die Aufgaben (je nach Abteilung) immer wieder ändern. Es gibt leider auch eine Abteilung bei uns, die noch 1 oder 2 Wochen vor der Einführung gerne ganz neue Ideen hat....
Natürlich bleibt es bei Projekten, die monatelang laufen (ich bin gerade bei einem, daß bis Spätjahr 2005 angesetzt ist), immer wieder Nachbesserungen geben muß. Man muß hier und da neue Datenfelder für die DB aufnehmen. Aber um auch das zu minimieren, werden bei DB Datenmodelle angefordert. Ohne die wird keine neue DB eingerichtet. Wir verwenden hier schon seit ettlichen Jahren Case/4/0. Unsere Software-Gurus drängen darauf, auch die Funktions- und Datenflußmodellierung zu machen. Ob und wie sinnvoll das ist, sei mal dahingestellt und hier gibt es grade Diskussionen drüber. Schließlich muß man im Falle der Pflege auch den ganzen Krempel mitanpassen, was den Änderungsaufwand weiter erhöht. Beim Datenmodell is das natürlich kein Thema. Aber die anderen Sachen...
Bei großen Projekten (ettliche PM=Personenmonate) werden immer häufiger Vorstudien aufgesetzt. Das sind kleine Projekte, die dem eigentlichen Projekt vorgeschaltet sind, um die Aufgaben, die zu erwartenden Aufwände bei allen Beteiligten (Analyse, Implementierung, Test, ggf. Optimierung, Einführung, Schulung) und die Abhängigkeiten im bestehenden System und der Projektlandschaft zu erkennen. Dann entscheidet ein Gremium, ob es weitergeht oder was wie angepaßt werden muß.
Bei uns (sehr große Versicherung) gibt es ca. 400 Leute, die sich mit IS (Informationssysteme) beschäftigen und ständig laufen große und sehr viele kleine Projekte ab. Wichtig ist deshalb, daß es Gremien gibt, die entscheiden, welche Projekte wie und wann realisiert werden. Natürlich wird auch fortlaufend controlled. Es sind stets zu festgelegten Zeitpunkten Fortschrittsberichte zu erstellen und es ist anzugeben, was erreicht wurde, welche Probleme sich ergeben oder ob Ziele nicht erreicht werden können.
Das Verfahren ist zwar teilweise etwas bürokratisch, aber bei einer großen Mannschaft auch gar nicht anders zu machen. Schließlich geht es hier teilweise um Millionenbeträge, die betrachtet werden müssen.
Programmdokumentationen und Schnittstellendef. sind bei uns übrigens Pflicht. Es hält sich zwar nicht jeder dran (und manchmal muß man das auch erst nach Projektende nachschieben, damit der Termin gehalten werden kann) aber in der Regel klappt es ganz gut. Viele von den "alteingesessenen" haben aber den Sinn von Kommentaren und Erklärungen (warum tue ich das, was ich mache) nicht so richtig eingesehen. Aber nun ja. Bei neuen Projekten wird versucht, dies konsequent mitzucontrollen.
-
Dein Argument mit dem Termindruck kann ich nicht akzeptieren. Auch bei internen Projekten fragt sich irgendwann jemand, was er für sein Geld bekommt und wo die Sache bleibt. Außer Ihr seid eine so große Firma, daß Ihr auch mal 5 Jahresgehälter verpulvern könnte ohne daß es jemand bemerkt.
Ich habe ja auch nicht gemeint, dass es vollkommen egal ist. Aber ich denke ein Monat hin oder her interessiert hier niemanden.
Schnelle Lieferung von Software stärkt das Vertrauen in Eure Abteilung und auch in die neue Methodik. Das ist auch bei internen Projekten immer ein Pluspunkt für Euch - und wie gesagt für die neue Vorgehensweise.
Das sehe ich genauso. Aber es gibt hier ein Problem: Den den es zu überzeugen gilt, ist Teil unserer Abteilung...
Eines Tages wird jemand bei Euch in der Firma mal ein Angebot für die gleiche Software bei einem externen Entwickler einholen und überrascht feststellen, daß es nur ein Drittel kostet. Dann habt Ihr ein Problem. Viele Softwareabteilungen in "Gemischtfirmen" haben sich dadurch völlig aufgelöst. Ich kenne hier im Umkreis einige Maschinenbauer, die überhaupt keine eigene Softwareabteilung mehr haben, obwohl die Steuerung sehr wichtig ist. Da sind noch 2 SPS-Leute fest drin, aber alles bzgl. PC wird extern gemacht.
In diesem Punkt haben wir (aufgrund unseres Chef-Entwicklers) eine Sonderstellung, er hat unsere Firma aufgrund seiner Programme in unserer Nische zum Weltmarktführer gemacht. Projekte lassen sich hier nicht so einfach ausser Haus geben. Aber ich stimme Deiner Argumentation natürlich zu!
...
So sieht es in Wirklichkeit in Projekten aus. UML-Tools usw. hat hier auch noch nie jemand benutzt. Manchmal frage ich mich, wie Rational Rose Umsatz macht.Da habe ich schon verschiedenes erlebt. In einem Ingenieur-Büro wurde genauso entwickelt, wie Du das beschrieben hast. Meine Diplomarbeit habe ich jedoch bei einem großen deutschen Unternehmen (Elektronikhersteller, Automotive-Zulieferer) gemacht. Dort war die Arbeit recht streng reglementiert. Vor allem Dokumentation und Planung waren sehr detailliert geregelt.
Du hast zwar recht, was nicht impliziert, dass das gut ist... ... und einen sanften Gegentrend zu erwirken ist bestimmt nicht verkehrt... aber man sollte nicht 3 stufen auf einmal nehmen.
Das ist was mir am Herzen liegt, ein sanfter Umschwung in organisierteres Arbeiten, alles in sinnvollem Umfang.
-
@JFK
Das kenn ich irgendowher. Ich war auch lange in so einem Betrieb. Alles für den Großrechner musste dokumentiert, schriftlich niedergelegt, genehmigt und nochmals genehmigt werden. Abteilungsübergreifend war das ganz schön ätzend, vor allem wenn die Abteilungen verschiednen Vorständen zugeordnet waren. Da musste ja jeder informiert werden und zustimmen. Dafür gab es als Vorgabe immer nur ein "so flexibel wie möglich".
Wie es im Leben so ist, kamen aber immer wieder Anforderungen, die eilig waren oder die in die gewachsenen Strukturen nicht reinpassten. So als Notnagel gab (gibt es wahrscheinlich heute noch) es eine kleine Gruppe von vier Mann, die an einem Mittelrechner arbeiteten, und die von den Genehmigungspflichten und der teilweise überzogenen Dokumentationspflich so ziemlich entbunden waren. Wenn irgendwo was nicht ganz korrekt lief konnte das ja auch schnell und unbürokratisch korrigiert werden. Ohne diese Gruppe wäre sehr vieles nicht fertig geworden.
-
Hallo.
SnorreDev schrieb:
Urgs - sowas ist immer toll. Chaos für alle
Achja - Lies dir am besten Rapid Developement von M$ Press durch. Da findest du sehr viele Argumente dafür.Gibt es da auch einen Link o.ä.?
Mfg, Jover
-
@Kauz01: Also so eine von Dir beschriebene "Taskforce" gibt es bei uns dankeswerterweise nicht. Es gibt aber Bereiche, welche die Anwendungsentwickler betreuen und schulen. Aber die Probleme, die man selber schafft, muß man - ggf. in Zusammenarbeit mit Spezialisten - auch selber wieder wegschaffen.
Obwohl wir nicht in C++ oder einer anderen objektorientieren Sprache programmieren, ist man schon länger dabei, die DB-Physik von der Anwendungslogik zu verstecken, um flexibler zu bleiben. Das dies teilweise dazu (ge)führt (hat), daß alles nur noch komplizierter wird, ist eine andere Sache. Man muß bei der Sache bedenken, daß unsere Programme nich nur die allerneusten Schmankerl der Tarifwelt abdecken müssen, sondern auch Tarife, die schon deutlich älter sind als ich selbst. Und in dem Bereich, in dem ich arbeite, haben wir halt lange Vertragslaufzeiten von (eher theoretischen) bis zu 99 Jahren. Das muß man dabei halt immer bedenken. Deswegen kann man auch nicht einfach mal so auf jeden abfahrenden "Sprachen-Zug" aufspringen und muß genau überlegen, wo man hin will. Auch deshalb wird es Mainframes noch laaaaaaaaaaaaaange geben. Vermutlich länger, als unsere heutigen, "klassischen" PCs.
-
@JFK
Ich kenn die Problematik. Als das größere Übel hab ich aber in Erinnerung, dass die Kreativität der Produkt-Entwickler in Zusammenarbeit mit dem Außendienst Blüten treibt, mit denen ein "normalen" Programmierers einfach nicht rechnet.
Vereinfacht ausgedrückt: Kaum hat man ein Design, das passt, kommt was neues, so dass es garantiert nicht mehr passt.
Wenn man dann nicht sehr flexibel reagieren kann (oder darf) ....
-
Ach das meinst Du... Naja. Das is der normaler Wahnsinn, den bei uns 2 Abteilungen betreiben.... Aber es sichert wenigstens jede Menge Arbeitsplätze...
Das Problem ist, daß kein Mensch soweit voraus denken kann, was dann immer kommt. Da hilft übrigens auch die OOP nicht sehr viel weiter, weil die in solchen Dingen nicht helfen könnte. Man kann leider nicht von A das B ableiten und davon wiederum C. Deshalb versuchen wir ja, viele Dinge nach und nach wegzukapseln und so langsam etwas zu erstellen, was im Detail relativ flexibel ist, jedoch im Zusammenhang ein schwer überschaubares Gesamtkonstrukt ergibt. Hier wird der Test extrem wichtig, wobei man leider nie alle Dinge testen und berücksichtigen kann.
Allerdings kann das die Kreativität mancher Leute auch nicht abfangen und so werden halt immer wieder Projekte aufgelegt, die das neue auf die gleichen Beine stellt, das alte möglichst auch und das ganz alte wird halt per Weiche beibehalten, wenn's nich anders geht.Umso wichtiger ist aber eine sehr umfassende Dokumentation und Analyse. Bis jetzt klappt das auch immer ganz gut und wir kriegen jedes Problem in den Griff. Allerdings investiert die Gesellschaft auch einiges, um das zu ermöglichen. Solche Sachen gibts halt nicht zum Nulltarif. Aber sie zahlen sich auch wieder aus; ansonsten würden wir das auch nicht machen!