UML will gelernt sein

[sakura]

Zitat:

Zitat von Tyrael Y.

Aber...in der Realität wird das oft nicht gemacht, da sich viele Firmen davor scheuen lange Planungsphasen zu integrieren.

Das liegt oft auch an unwissenden Bossen. Wenige sind zufrieden, wenn man 6 Monate nur Diagramme zeigt. Es ist schwer soetwas durchzusetzen, wenn der Boss es gewohnt ist nach 2 Wochen etwas handfestes zu sehen.

Aber auch auf Seite der Mitarbeiter gibt es oft sträuben gegen ein solche Planung. Aber es muss einem wohl Spaß machen, soetwas auch zu tun, damit es geht. Wenn ich später wirklich gute Programmierer bei mir habe, dann sind die ihren Job los und kommen in die Softwaredesigngruppe. Das ist um weites komplexer vom Ansatz, aber ich finde auch spannender. Aber noch ist meine Firma zu klein und ich muss es selbst machen :roll:

...:cat:...

[Sourcemaker]

Der Einsatz und Aufwand der bei der Planung betrieben wird richtet sich nach Volumen des Auftrages (finanziell) und der Anzahl der mitarbeitenden Personen (bei großen Aufwand) und natürlich nach dem Kundenforderungen ggf. natürlich auch nach der Genialität des ausführenden Programmierers.

Grüße

Frank

[Sanchez]

Da muss ich mein Vor-Postern zustimmen.
Bei uns wird das gute alte Prototyping verwendet. Der Kunde will halt schnell was sehen und ggf noch ein paar Wünsche und Änderungen haben. Da ist es schon öfters vorgekommen, dass ich einiges total über den haufen werfen musste. Mit einer anständigen Planung und der Einbeziehung der Kunden in die Planung wäre das wohl nicht passiert.

Aber da bei uns jetzt die ISO-Zertifizierung ansteht hoffe ich, dass ich bei der Gelegenheit ein paar Neuerungen einbringen kann.

Aus diesem Grund würd ich gern wissen wie bei euch der Entwicklungsablauf so aussieht. Ich denke doch, dass nicht mehr so viele einfach drauf los einen Prototypen programmieren und den immer weiter bis zum fertigen Produkt entwickeln und dabei immer wieder bereits funktionierendes über den Haufen werfen.

[sakura]

Zitat:

Zitat von Sourcemaker

Der Einsatz und Aufwand der bei der Planung betrieben wird richtet sich nach ...dem Kundenforderungen

Bei uns ausschließlich. Wir erstellen immer erst ein Lastenheft und anschließend ein Pflichtenheft. Wenn das Pflichtenheft vom Kunden abgenommen wurde, dann wird dieses 1:1 umgesetzt. Erst im Anschluß kann/darf der Kunde weitergehende Wünsche äußernh, welche wiederum in einer erweiterten Version des Pflichtenheftes festgehalten werden. Das geht solange, bis der Kunde glücklich ist.

Wir haben auch schon Kunden nicht bekommen (nie verloren!), weil denen unsere Art nicht passte, aber die, die mitmachen verlangen seit dem dieses Vorgehen teilweise auch von anderen Dienstleistern. Es ist einfach rigeros definiert, wer was wofür und wann macht. Wenn sich alle daran halten, ist es am Ende die effektivste und preiswerteste (Kunde)/gewinnbringendste (Dienstleister) Methode ;-)

...:cat:...

[Sourcemaker]

Hi Sakura,

wenn ich bei einer Individualprogrammierung die sagen wir mal momentan 10000 Eur kosten würde ein entsprechendes Pflichtenheft erstellen würde käme das Programm wahrscheinlich das Doppelte. Wenn man also diesen Kunden fragen würde dürfte die Antwort klar sein immer vorrausgesetzt das man den Kunden durch entsprechendes Renommee von seiner Leistungsfähigkeit überzeugen kann.
Ab einer gewissen Auftragsgröße sagen wir 100000 Eur oder bei der Entwicklung einer Standardsoftware mit entsprechend großen Erstellungswert wird eine umfangreichere Planung ein muß sein.

Was ich sagen will es ist relativ.

Grüße

Frank

[Sanchez]

Wenn ich mal davon ausgehe das ein 100.000€ Projekt umfangreicher ist als ein 10.000€ Projekt, dann ist wohl beim kleineren Projekt auch weniger Planung nötig.

[kiar]

hallo.

ich gehe seit geraumer zeit genau den weg, den sakura dargelegt hat. ich programmiere zwar nur so zum hobby, aber wenn amn keine struktur drin hat kann man sehr schnell den überblick verlieren. ich habe natürlich einen vorteil ich bin kunde und dienstleister in einem, da kann man sich das pflichtenheft hinbiegen.

@sourcemaker wenn der kunde ein 10000 euro projekt nur dann akzeptiert, obwohl der dienstleister auf ein pflichtenheft besteht, kommt der kunde spätestens, wenn eine weitere implementierung angezeigt ist und der das doppelte drauf zahlt.

ausserdem läuft es in der wirtschaft doch auch nicht anders erst die ausschreibung und dann das angebot.

in meiner branche kann man auch keine kompromisse machen, wenn es sein muss, muss es sein.

raik

habe hier ein buch 'uml mit delphi' autor : max kleiner. werde ich mir wohl doch mal intensiver reinsaugen müssen

[LarsMiddendorf]

Über das Verhältnis zwischen Planung und Realisierung habe ich mir auch schon öfter mal Gedanken gemacht. Das geplant werden muß steht außer Diskussion, aber wie ist das richtige Verhältnis.Gibt es da vielleicht einen sinnvollen Mittelweg. Mich würden da mal Meinungen aus dem täglichen Alltag von Softwareentwicklern interessieren:

-Ist es überhaupt möglich ein größeres Programm komplett zu planen und dann erst umzusetzen? Kann man alle Probleme komplett voher überblicken, so daß die tatsächliche Umsetzung dann auch elegant ist, oder geht man teilweise wieder einen Schritt zurück zur Planung?

-Oder ist es eventuell sinnvoller immer inkrementell Teile des Programms zu planen und direkt umzusetzen und zu testen?

-Was ist besser beim Softwareentwurf: Top-Down oder Bottom-Up?

-Wie detailliert sollte der UML Entwurf sein? Wenn man direkt alle Felder und Methoden einträgt, dann hat man ja im Prinzip keine höhere Abstraktionsebene als wenn man es direkt programmiert? Muß man für jede kleine Klasse ein Diagramm anlegen, die man doch schneller direkt programmieren könnte? Behindert man sich dadurch nicht selber?

[sakura]

Hi Lars,

hat Dich der Thread zum mitmachen animiert :mrgreen: Freut mich, also will ich meine nächsten 9ct auch noch loswerden... Dazu würfle ich Deine Sätze ein wenig durcheinander, so daß es mir passt :angle: Ausserdem greife ich immer wieder auf ModelMaker zurück, da ich mit dem Tool seit einigen Jahren arbeite. Es soll aber nicht heißen, daß es nicht vielleicht bessere Tools gibt.

Zitat:

Zitat von LarsMiddendorf

Mich würden da mal Meinungen aus dem täglichen Alltag von Softwareentwicklern interessieren

Dann mache ich mal den Anfang ;-)

Zitat:

Zitat von LarsMiddendorf

Gibt es da vielleicht einen sinnvollen Mittelweg.

Ja, ich glaube schon. Aber ist dieser für jedes Projekt etwas anders. Soll es nur mal schnell ein Utility sein, welches sich einer speziellen Aufgabe widmet, keinen Schnick-Schnack bieten soll, dann wird man oft wohl komplett ohne UML auskommen. Nicht jedoch, ohne einen festen Plan. Manchmal mag es reichen seich das Ziel zu merken (lösche alle Dateien die "$$$*.*" entsprechen), aber sich dieses zu notieren wird nicht schaden ;-)

Sollte es etwas mehr sein (lösche alle Dateien auf allen Rechnern im Netzwerk die "$$$*.*" entsprechen und älter als eine Woche sein), dann sollte man sich zumindest schon einmal etwas Gedanken machen, ob man da nicht vielleicht ein, zwei Klassen (Netzwerksuche, Dateifilter, ...) entwickeln kann, welche man später in anderen Projekten wiederverwenden kann. Diese sollte man dann vielleicht schon in einem UML-Tool (z.B. ModelMaker) erstellen und gleich dokumentieren. Warum?... ein paar Zeilen später.

Zitat:

Zitat von LarsMiddendorf

Ist es überhaupt möglich ein größeres Programm komplett zu planen und dann erst umzusetzen?

Kommt wohl wieder auf die Größe an, aber ist das denn nötig? Nehmen wir mal ein größeres Softwareprojekt, wie es in meiner Firma zur Zeit läuft. Planungs- und Umsetzungszeitraum ca. 18 Monate.

Zitat:

Zitat von LarsMiddendorf

Wie detailliert sollte der UML Entwurf sein?

Der erste Entwurf sollte gar keine Details enthalten. Wie auch, man muss ja erst einmal eine Idee aufs Papier bringen (MindMap Diagram). Darin sollte man erst einmal alle Ideen, Erfahrungen, Gedanken, Wünsche, Kundenvorschläge :mrgreen:, etc. notieren. Dann kann man anfangen sich Gedanken zu machen, was aus den Ideen genutzt wird, was warten kann und was man gar nicht braucht oder will.

Wenn man die Komponenten (oder Utilities, Teilprogramme, Funktionen, etc.) der ersten Stufe festgelegt hat, dann sollte man sich anschließend auch daran halten, damit man später nicht vom Weg abkommt.

Nun geht es ans erste Design. Man schaut welche Komponente welche Teilbereiche hat. Diese hält man dann wieder fest. Und spätesten jetzt sollte man sich auch im Klaren sein, was die Komponenten miteinander tun sollen (nicht das wie!) Auch sollte man schauen, ob man evtl. Dinge beachten muss, die die zurückgestellten Komponenten später benötigen, um sich in das Gesamtprojekt zu integrieren.

Zitat:

Zitat von LarsMiddendorf

Wenn man direkt alle Felder und Methoden einträgt, dann hat man ja im Prinzip keine höhere Abstraktionsebene als wenn man es direkt programmiert?

Jetzt kann man anfangen für jede einzelne Komponente eine Lösung zu ermitteln und diese in Klassen aufzuteilen. Wenn man diese Klassen hat muss man anfangen zu ermitteln, wie diese untereinander kommunizieren und welche Schnittstellen es gibt. Das alles sollte imho noch im Diagramm geschehen. Hier verlasse ich meistens die Diagrammebene und gehe später in den Code-Editor von ModelMaker. Das hat den Vorteil, daß ich später den Code wieder auf Diagrammebene "zaubern" kann. *break, mehr zum weiteren Weg kommt gleich...*

Zitat:

Zitat von LarsMiddendorf

Kann man alle Probleme komplett voher überblicken, so daß die tatsächliche Umsetzung dann auch elegant ist

Komplett - bestimmt, aber man braucht nur den IQ von Einstein + 200, die Intuition aller Frauen zzgl. der Gabe in die Zukunft der Kundenwünsche zu schauen ;-) Nein, ich glaube nicht. Aber man kann sich auf viele vorbereiten und offen planen, so daß man später nicht alles wieder umstoßen muss, nur weil der Kunden gerne Icons hätte und das ja auch sinnvoll ist.

Zitat:

Zitat von LarsMiddendorf

oder geht man teilweise wieder einen Schritt zurück zur Planung?

Ja! Wenn man merkt, daß es happert, dann sollte man nicht einfach eine Lösung an Ort und Stelle bauen. Das ist zwar meistens schnell gemacht, aber bei Projekten mit Größen von mehreren 1000 A4 Code ist das auch gefährlich. Keiner kann mir erzählen, daß er/sie dann noch die Hand ins Feuer legen würde, wenn die Änderung auch andere Stellen betrifft. Also lieber zurück zum Reißbrett und versichern, daß es passt. Änderung dort eintragen und erst dann(!) implementieren.

Zitat:

Zitat von LarsMiddendorf

Oder ist es eventuell sinnvoller immer inkrementell Teile des Programms zu planen und direkt umzusetzen und zu testen?

Teile eines Programmes - was sind diese? Andere Programme, dann ja! Oder doch nur eine Unit - hm, macht man doch eh, oder arbeitest Du an 6 Units gleichzeitig :shock: !weiterlesen!

Zitat:

Zitat von LarsMiddendorf

Was ist besser beim Softwareentwurf: Top-Down oder Bottom-Up?

Wie an den jetzigen Ausführungen merkst, gibt es keine eindeutige Antwort. Ich verfolge beide Wege gleichzeitig. Erst einmal Top-Down: Was will ich am Ende sehen und was soll es können. Danach jedoch strikt Bottom-Up: Ich weiß jetzt, was jede Komponente tun soll und auch etwa welche Klassen drinne sind. Jetzt stricke ich jede Lösung durch Lösung ihrer kleinen Probleme zu einem Gesamtwerk, welches hoffentlich auch hält ;-)

Zitat:

Zitat von LarsMiddendorf

Muß man für jede kleine Klasse ein Diagramm anlegen, die man doch schneller direkt programmieren könnte?

Bei mir: ja :!: Na gut, fast. Da nicht jede Klasse im Diagramm auftaucht, aber jede Klasse existiert in ModelMaker um evtl. bei Bedarf im Diagramm zu landen ;-) Warum denn? Na ja, wenn es ohne ModelMaker so viel schneller geht, dann werde ich nicht sofort wiedersprechen. Es ist bestimmt einfacher die Klasse mal schnell in Delphi einzutippen. Na gut, mache ich auch, aber im Anschluß importiere ich diese nach ModelMaker und dokumentiere diese auch. Anschließend erstellt ModelMaker mir mein RTF welches ich zu einer HLP-File als Doku kompiliere.

Warum? Einfach, ich kann jetzt víer Wochen/Monate später zurück kommen, schnell in die Doku schauen und den Fehler beseitigen oder vielleicht eine neue Funktion einfügen. Tools wie ModelMaker beiten einfach einen besseren Überblick über die einzelnen Strukturen, Beziehungen und Aufgabenlösungen.

Zitat:

Zitat von LarsMiddendorf

Behindert man sich dadurch nicht selber?

Anfangs dachte ich es auch, aber inzwischen liebe ich diesen Weg, da der auf Dauer immer schneller ans Ziel führt als noch einmal durch 5000 Zeilen Code zu springen, um sich die Beziehungen unter 3 Klassen anzuschauen.

Abschluß :roll:

Mit ModelMaker verwalten wir die aktuelle Version unserer Software (zumindest den Delphi-Teil) von Beginn an, importieren meist auch 3rd Party Codes, damit diese besser verständlich werden und noch behalte ich den Überblick über mehr als 7 MB Delphi-Quellcodes, 2 MB XML Definitionsdateien, 3 MB ASP Quellcodes und fast 3 MB Hilfedateien (ohne wirklichen Inhalt :shock:) :mrgreen:

...:xmas:...

[marvin.maybe]

Hallo,

UML (oder eine andere Modellierungstechnik) ist für kleine und große Software-Projekte ratsam. Bevor sich ein Entwickler an seinen Computer setzt und beginnt seine Ideen in Code zu gießen, sollte er sich wirklich überlegen, was er eigentlich tun möchte (bzw. muss) und dazu ist UML sicherlich gut geeignet.

Eine große Gefahr bei UML als Kommunikationsform innerhalb größerer Entwicklungsteams liegt darin, dass wenig begabte oder unerfahrene Leute UML-Diagramme erstellen und diese von anderen implementiert werden sollen. Wenn ich mir vorstelle, ein saumäßiges Design implementieren zu müssen, bekäme ich Ausschlag... Analyse, Design und Implementierung sollten dieselben Personen machen.

Ich fänd es klasse, wenn ich mein gesamtes Programm in einem UML-Builder "malen" könnte (incl. Attribute und Typen) und diese dann direkt in den Source-Code übertragen könnte. Natürlich müßte auch der Rückweg funktionieren: Wenn ich bespielsweise während der Implementierung merke, dass ich weitere Methoden benötige, müßten diese auch im UML-Diagramm erscheinen.

(Meiner Erfahrung nach, umfasst Implementierung ("Code tippen") ca. 20% einer Entwicklungsphase, der Rest ist Planung (Verstehen was gemeint ist, Design und Specification schreiben, ...), Test und Korrektur).

Gruß,
Jan.