UML - Buzzword für Manager?
-
Optimizer schrieb:
Die Idee, ein paar Notationen zu vereinheitlichen, mag ja nicht verkehrt sein (auch wenn ich mich Frage, zu welchem Problem das die Lösung ist).
Das liegt am System. Informatiker bringen es einfach nicht fertig, über etwas zu sprechen, ohne es zu definieren. Einer nahme für Klassen Wölkchen, einer Kästen, einer Kreise - das ging nicht. Es liegt in der Natur der Informatiker, hier einen Standard zu entwerfen, der das normiert. Das war das Problem: es störten sich offensichtlich viele Leute daran, daß es keinen Standard für die Zeichnungen gab. Und UML ist die Lösung für das Problem "es gibt keinen Standard für Zeichnungsdokumentation in der Software".
Ich mag UML für Diskussionen am Whiteboard... (ich meine, für hoch performante Group based Brainstormings mit multidirektionalem Knowledge Transfer). Es fällt leichter, eine kleine Klassenhierarchie zu zeichnen, als class hinzuschreiben, ist übersichtlicher, klarer. Man kann auch besser "editieren". Und dynamische Zusammenhänge lassen sich damit besser darstellen, gerade das fällt vielen Leuten schwer, sich vorzustellen wie das nachher alles aussieht, wenn sich die Objekte tatsächlich gegenseitig befeuern.
Aber mir haben die Wölkchen besser gefallen... deswegen hatte ich mich damals für Booch entschieden.
-
SideWinder schrieb:
Gerade als Programmierer verwendet man doch die ganze Zeit fachspezifische Fremdwörter die sonst niemand versteht. Erklärt seinem Chef warum das Projekt so toll ist indem man 10 neue Technologien, Design Pattern und sonstigen für den Chef absolut unwichtigen Unfug erzählt und regt sich im selben Satz darübe auf, dass der Chef seine eigene Fachsprache verwenet die man selbst nicht verstehen kann.
Wer es noch nicht gesehen hat: Die Abteilung der Programmierer ist in der Firma eindeutig das untere Ende der Nahrungskette. Hauptziel ist es nicht möglichst viele tolle und schöne Programme zu schreiben sondern dem Kunden die Software - so dämlich und buggy sie auch ist - zu verkaufen.
MfG SideWinder
Das sind aber keine Fremdwörter in der von mir zitierten Phrase sondern da hat jemand nur einen Satz mit Pseudo-Informationen aufgeblasen.
-
Optimizer schrieb:
Dafür braucht man sich aber nicht für jede Tätigkeit einen neuen Buzz-Namen ausdenken, sonst bist du irgendwann Direct art and Production support and Product senior stylistic supervisor.
Oder Controler<T>
Marc++us schrieb:
für Diskussionen am Whiteboard... (ich meine, für hoch performante Group based Brainstormings mit multidirektionalem Knowledge Transfer)
...ups, naja unser Organigramm gibts momentan (wegen dem merger
) auch nur auf dem Weissen Brett (ich mag das schwarze ja lieber 
) :p :pSideWinder schrieb:
Wer es noch nicht gesehen hat: Die Abteilung der Programmierer ist in der Firma eindeutig das untere Ende der Nahrungskette. Hauptziel ist es nicht möglichst viele tolle und schöne Programme zu schreiben sondern dem Kunden die Software - so dämlich und buggy sie auch ist - zu verkaufen.
Ist nicht nur in der SW Branche so. Hast wohl noch nicht gemerkt, dass alles was es heute so zu kaufen gibt, nur noch Schrott ist?
Ne, echt, Chief x Officers habens echt drauf
-
SideWinder schrieb:
Hauptziel ist es nicht möglichst viele tolle und schöne Programme zu schreiben sondern dem Kunden die Software - so dämlich und buggy sie auch ist - zu verkaufen.
Da bricht jetzt glatt ne Welt für mich zusammen. Und die Leute, die Mikrowellenessen produzieren wollen garnicht total leckeres und hochwertiges Essen produzieren sondern nur Geld verdienen? Das ist aber gemein!
So funktioniert *jede* Firma.
-
hmmm... Ich schließe mich mal grob den Sichtweisen von SideWinder und Prof84 an.
1. Ich halte UML für wichtig und gut. Und zwar immer dann, wenn es darum geht, bestimmte Strukturen oder Abläufe zu dokumentieren oder darüber mit irgendwem zu kommunizieren. Es ist wichtig, dafür eine standardisierte Sprache zu haben. Das beugt Missverständnissen vor (die Voraussetzung ist natürlich, dass alle Beteiligten diese Sprache sprechen). Es geht dabei nicht so sehr darum, ob UML nun die absolut beste Sprache für diesen Zweck ist, es geht mehr um die Standardisierung. UML ist anderen gleichwertigen Sprachen vorzuziehen, weil sie sich einfach durchgesetzt hat. Es sprechen nunmal sehr viele Leute UML, UML ist gut dokumentiert und UML wird in den Hochschulen gelehrt. Wenn man sich nur schnell mal eine Skizze machen möchte, um sich selbst etwas zu visualisieren, braucht man sicherlich kein UML. ...sofern die Skizze danach dann auch im Mülleimer landet und nicht in irgendweiner Art von Dokumentation. Aber als Kommunikationsmittel sind solche individuellen Skizzen IMHO eher weniger geeignet.
BTW: Es gibt ja auch in anderen Bereichen standardisierte Sprachen und das aus gutem Grund. Man stelle sich vor, im Flugverkehr kommt es zu irgendeinem Missverständnis. Soetwas kann ganz schnell zu einer Katastrophe führen. Und deshalb ist auch dort der Ablauf des Funkverkehrs sehr genau standardisiert. Ähnliches gilt für das Militär: Auch da ist die Kommunikation standardisiert.
2. Ich halte Fachsprachen und die Beherrschung dieser generell für wichtig und gut. Die Gründe sind praktisch genau die gleichen wie bei der UML. Mit einer passenden Fachsprache kann man sich unmissverständlich ausdrücken. Begriffe sind eindeutig definiert und müssen nicht immer wieder bei jedem Gespräch neu erarbeitet werden. Wie will man halbwegs effizient - in einem Team - arbeiten, wenn man keine Sprache hat, die dafür geeignet ist? Wie will man zu sinnvollen Gedanken in einem Gebiet kommen, wenn einem dafür die Sprache fehlt? Dumm ist es nur, wenn einem diese Fachsprache so sehr in Fleisch und Blut übergeht, dass man sie auch in anderen Zusammenhängen verwendet. Oder auch bei der Kommunikation mit Leuten, die diese Sprache nicht sprechen. Die würden das dann wohl nur als so eine Art Buzzword-Geplapper auffassen. Es kommt also immer auf den Zusammenhang an. Wenn Prof84 von "Profis" oder ähnlichem spricht, dann kann man aber davon ausgehen, dass jeder, der in diesem Zusammenhang gemeint ist, die entsprechende Sprache, sei es nun die UML oder eine andere Fachsprache, sprechen können sollte. Unter Profis ist das deshalb eindeutig auch die passende Kommunikationsgrundlage.
BTW: Wenn man sich mal den Inhalt von Hochschulstudien ansieht, stellt man fest, dass ein erheblicher Bestandteil davon das Lernen der Fachsprache(n) des jeweiligen Gebiets darstellt. Wenn man irgendwann mal ne mündliche Prüfung hat, dann fragt der Prüfer meistens genau das ab: Er versucht herauszufinden, ob sich der Prüfling in der entsprechenden Begriffswelt zurechtfindet, ob er mit den Begriffen etwas anfangen kann und ob er sich mit diesen Begriffen ausdrücken kann.
-
First-Class-Posting
<OT>
Edit:Jester schrieb:
So funktioniert *jede* Firma.
Ich verstehe dann aber nicht wieso in der Baubranche die Maurer nie am Design des Gebäudes rütteln wollen sondern strikt die Mauer bauen die ihnen aufgetragen wurde? Die Programmierer sind die einzigen Handwerker die rund um die Uhr in der Planung herumpfuschen wollen "weil es so ja viel besser geht" *g*
</OT>MfG SideWinder
-
Gregor schrieb:
2. Ich halte Fachsprachen und die Beherrschung dieser generell für wichtig und gut. ... Oder auch bei der Kommunikation mit Leuten, die diese Sprache nicht sprechen. Die würden das dann wohl nur als so eine Art Buzzword-Geplapper auffassen. Es kommt also immer auf den Zusammenhang an.
Da wäre ich vorsichtig.
Du gehst davon aus, daß erst das Fach da war, und danach die standardisierte Sprache eingeführt wurde, damit man sich über Fachspezifika in eindeutig definierten Begriffen unterhalten kann.
Inzwischen wird aber auch eine andere Form der Fachsprache gepflegt, die dadurch entsteht, daß man eine Sprache schafft, um ein Gebiet zu "emanzipieren" oder eben auch um durch eine Fachsprache die eigene Kommunikation für Außenstehende unverständlich zu machen, oder auch um Inhalte zu verschleiern. Hier wird die auf technischem Gebiet teilweise notwendige Fachsprache dazu benutzt, um eine neue Ebene zu schaffen, die sachlich gar nicht existiert. Es ist mehr eine Formalsprache.
Und da regen sich natürlich all die Personen auf, die hier a) bewußt aus dem Kreis ausgeschlossen werden sollen und b) die die Begriffe verstehen und erkennen, daß für dieses Themengebiet - anders als bei etwas Neuem - gar keine zusätzlichen Begriffe hätten eingeführt werden müssen, daß es eine reine modisch klingende Umbenennung ist.
-
SideWinder schrieb:
Ich verstehe dann aber nicht wieso in der Baubranche die Maurer nie am Design des Gebäudes rütteln wollen sondern strikt die Mauer bauen die ihnen aufgetragen wurde? Die Programmierer sind die einzigen Handwerker die rund um die Uhr in der Planung herumpfuschen wollen "weil es so ja viel besser geht" *g*
Wir haben festgestellt, dass du Schüler bist, also arbeitest du nicht in einer Firma, in der die einen Planen und die anderen programmieren.
Arbeitet irgendwer in einer Firma, in der es Leute gibt, die wirklich nur zum Schreiben von Code da sind und andere die wirklich nur die SW planen?
-
SideWinder schrieb:
Ich verstehe dann aber nicht wieso in der Baubranche die Maurer nie am Design des Gebäudes rütteln wollen sondern strikt die Mauer bauen die ihnen aufgetragen wurde? Die Programmierer sind die einzigen Handwerker die rund um die Uhr in der Planung herumpfuschen wollen "weil es so ja viel besser geht" *g*
niemals würde ein wirtschaftler dort sagen "diese talbrücke arbeiten wir als hängebrücke aus, sie hat drei stützen dort, dort und dort..." oder wie ein hochhaus gebaut wird. nein, er trägt das fachleuten (architekten und statikern) auf. er verwirft viele vorschläge, versucht auch zu ändern, aber doch in grenzen. bei der software ist es so, daß die wirtschaftler selber sich ahnung zumuten und bis ins detail planen, was welches modul machen soll. das kommt noch von der killerapplikation dazumal, der lohnbuchhaltung, die zur massiven einführung von computern geführt hat.
-
JetztMalKlartext schrieb:
Wir haben festgestellt, dass du Schüler bist, also arbeitest du nicht in einer Firma, in der die einen Planen und die anderen programmieren.
Wie kommst du zu deinem "also"-Entschluss?
Arbeitet irgendwer in einer Firma, in der es Leute gibt, die wirklich nur zum Schreiben von Code da sind und andere die wirklich nur die SW planen?
Ja. Jedes Jahr 1 Monat Vollzeit in den Ferien und neben der Schule mehr "freie Mitarbeit" je nach Zeit.
MfG SideWinder
-
Damit das jetzt nicht falsch verstanden wird: Die Planen dort aber nicht im Detail sondern eher Dinge wie Feature-Anforderungen, etc. übernehmen dann auch gleich den Kundensupport und stehen somit fachlich mit dem Programm in Verbindung. Die Programmierer sind für die technische Seite zuständig.
UML kommt allerdings nur selten vor (Klassendiagramme, kurze grobe Ablaufsdiagramme, etc.)
MfG SideWinder
-
Na als Schüler "zählst" du nicht als "richtiger Mitarbeiter" der dazu geeignet ist irgenwelche (Teil)Projekte zu planen. Solchen werden meistens nur kleine Teilaufgaben geben.
SideWinder schrieb:
Damit das jetzt nicht falsch verstanden wird: Die Planen dort aber nicht im Detail sondern eher Dinge wie Feature-Anforderungen, etc. übernehmen dann auch gleich den Kundensupport und stehen somit fachlich mit dem Programm in Verbindung. Die Programmierer sind für die technische Seite zuständig.
Das meine ich ja. Ich glaube nicht, dass es möglich ist, dass irgendwelche Informatiker ein geniales UML-Diagramm mit ca. über 200++ Seiten erstellen, das dann an die dummen Programmierer gegeben wird und die den Code tippen.
-
Dafür ist UML imho auch nicht gemacht:
Seite 1, Antwort #3:
SideWinder schrieb:
(Jede Funktion vorher mit UML und einem Aktivitätsdiagramm zu zeichnen ist hingegen dämlich).
Aber was spricht dagegen ein Klassendiagramm in einem standardisierten Visualisierungsformat zu zeichnen?
MfG SideWinder
-
Gar nichts, ich wüsste auch nicht, wer sich dagegen geäußert hat.
Das negativste dazu war möglicherweise von mir mit (sinngemäß) "naja nett, aber welches Problem löst es?".Wir wollen nur feststellen, ob UML zuviel von Wirtschaftlern benutzt wird um dick auflabern zu können. Da muss ich dann eigentlich nur die Posts von Prof84 lesen und für mich ist die Antwort schon mal klar.
-
Marc++us schrieb:
Inzwischen wird aber auch eine andere Form der Fachsprache gepflegt, die dadurch entsteht, daß man eine Sprache schafft, um ein Gebiet zu "emanzipieren" oder eben auch um durch eine Fachsprache die eigene Kommunikation für Außenstehende unverständlich zu machen, oder auch um Inhalte zu verschleiern. Hier wird die auf technischem Gebiet teilweise notwendige Fachsprache dazu benutzt, um eine neue Ebene zu schaffen, die sachlich gar nicht existiert. Es ist mehr eine Formalsprache.
Definiere 'sachlich existent'.
-
Optimizer schrieb:
Wir wollen nur feststellen, ob UML zuviel von Wirtschaftlern benutzt wird um dick auflabern zu können. Da muss ich dann eigentlich nur die Posts von Prof84 lesen und für mich ist die Antwort schon mal klar.
Ich glaube, wenn Du Prof84 als Wirtschaftler abstempelst, dann tust Du ihm Unrecht.
-
SideWinder schrieb:
Aber was spricht dagegen ein Klassendiagramm in einem standardisierten Visualisierungsformat zu zeichnen?
Hängt davon ab.
Unter Umständen viel, wenn es keine zusätzlichen Informationen enthält. Oftmals wird UML mittels Tool dazu eingesetzt, am Ende das Projekt "zu dokumentieren". Das ist völliger Unfug, da auf diese Weise die Existenz einer Dokumentation nur simuliert wird und bzgl des Informationsgehalts zwischen der Darstellung als Code und der Darstellung als Grafik kein Unterschied besteht.
-
Gregor schrieb:
Optimizer schrieb:
Wir wollen nur feststellen, ob UML zuviel von Wirtschaftlern benutzt wird um dick auflabern zu können. Da muss ich dann eigentlich nur die Posts von Prof84 lesen und für mich ist die Antwort schon mal klar.
Ich glaube, wenn Du Prof84 als Wirtschaftler abstempelst, dann tust Du ihm Unrecht.
Jo, ich glaube auch und möchte das ein bisschen zurücknehmen. Aber dick auflabern tut er ja schon.
-
Optimizer schrieb:
Aber dick auflabern tut er ja schon.
Allerdings. Und für einen BWL-Hasser wie mich (oder jede andere kluge Person) liest sich das einfach nur noch peinlich
-
SideWinder schrieb:
Dafür ist UML imho auch nicht gemacht:
Dafür meinst du
Ich glaube nicht, dass es möglich ist, dass irgendwelche Informatiker ein geniales UML-Diagramm mit ca. über 200++ Seiten erstellen, das dann an die dummen Programmierer gegeben wird und die den Code tippen.
Aber du hast doch diesen Vergleich mit den Maurern gebracht und damit der funktionieren kann müsste UML doch sowas wie der Bauplan für die Softwaremaurer sein.