UML - Buzzword für Manager?
-
ich persönlich bin von UML auch nicht besonders angetan...es ist sicherlich ein nettes Werkzeug, aber man kann sich auch tot-UMLen, wenn man wirklich alles nur nach diesem Standard planen und formulieren möchte. Ich fand es sehr amüsant, als bei uns an der FH mal ein Vortrag zweier Leute von BlueByte stattfand, die über die Siedler-Reihe sprachen. In der Hörerschaft saß auch unsere Software Engineering-Prof'in, die dann irgendwann gegen Ende fragte, wie denn die ganze Planung und Kommunikation zwischen den einzelnen Teams wohl aussehe...tja, kurz gesagt, der erste Satz, der als Antwort kam, war: "Wir machen keine UML-Diagramme oder so!"...die war nicht gerade zufrieden...
-
Mit Sicherheit ist die UML nicht das "Ein und Alles", das ist richtig. Aber sie _kann_ sich in Projekten als nützlich erweisen. Und das ist glaube ich der Punkt an dem wir die ganze Zeit festhengen und uns uneinig sind. Die Betonung liegt auf kann. Ich finde man sollte die UML auch nur dann einsetzen, wenn es Sinn machen würde und nicht um irgendwelche Manager zu beeindrucken oder gar den Klienten durch schöne Bildchen in den (falschen) Glauben zu versetzen, wie weit das Projekt schon ist... Das klingt ein wenig übertrieben, aber in einigen Betrieben ist dies gang und gebe. Sinnvoll erweißt sich jedoch die Verbesserung der Kommunikation zwischen Analysten, Designern und Programmierern. Es ist wie schon gesagt einfacher wenn alle Beteiligten eine Sprache sprechen. Ein wenig abstrakt gesehen: Wohin soll es führen, wenn der Analyst deutsch, der Designer englisch und der programmierer französisch spricht; es würde keine gelungene kommunikation zu stande kommen.
-
Prof84@work schrieb:
Optimizer schrieb:
Jedes Diagramm benötigt sowieso eine Erklärung von jemandem der im Projekt drin ist, damit man die ganze Idee rüberbringen kann. Ein Haufen Klassen mit Pfeilen darin erklärt nie, wie das jetzt alles auszusehen und zu funktionieren hat. Wie eine Klasse im Diagramm auszusehen hat, da kann man improvisieren, das ist nicht das schwierigste, rauszulesen. UML will die Entwickler in ein Korsett zwingen, nicht mehr frei improvisieren und das Wesentliche hinkritzeln zu können, dabei muss es gar nicht sein, dass ein UML-Sequenzdiagramm gerade die beste Darstellungsform ist. Wir haben bei einem Studienprojekt den Schmarrn schon mal weggeworfen, was anderes hingekritzelt, dem Prof erklärt und die beste Arbeit abgegeben. Wie gesagt, nichts gegen Stift und Papier.
Wenn ein Manager mit Hilfe von Umsatz-Charts über seine Anforderungen, Ziele und Konzepte für SW sprechen möchte, darf er das! Der Elektroingeieur mit seinen Schaltplan, der Lagerist mit seinen Bestandslisten, der Kraftwerksleiter mit seinem Power-Grid Plan etc. Und der SW- Éntwickler mit UML.
Klar, darf man alles hernehmen. Aber es ist Bullshit, zu glauben, dass man damit anderen etwas erklären kann. Wenn du für dich ein Diagramm (egal welcher Art) als Gedächtnisstütze machst, super! Dass es UML sein muss, ist schon die allererste Fehlannahme. Es ist völlig egal, ob es irgendeiner formalen Vorschrift genügt. Sobald man anderen was damit erklärt, muss man wieder was dazu erzählen und spätestens dabei wird jedes Wirtschaftler-Geblubber gnadenlos enttarnt.
Meine Aufgabe als Analyst, Architekt, Entwickler oder Anforderungsmanger ist es Roundtrip-Engineering zwischen den Domainmodellen der Stakeholder und meiner SW zu betreiben - ich bin der Analytiker.
Nach dem, was du hier aufzählst, bist du ein Software-Entwickler. Die Putzfrau macht auch keine höhere Arbeit, wenn sie Sanitärbeauftragte heißt. Klar ist die Arbeit vielseitig und man sitzt nicht nur vor dem Computer und tippt. 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.
So, jetzt versuch mal eine bidirektionale Traceability zwischen Code und z.B. einer CAD Zeichung herzustellen. Klar kannst Du remarks reinschreiben, aber versuch mal das System zu warten und zu überblicken.
Das hättest du auch mit weniger gebuzze sagen können, oder? Ist das eigentlich eine dumme Angewohnheit von dir? Redest du mit jedem so? Kann man sowas ernst nehmen? Hätte es das rein deutsche Äquivalent nicht getan? Hättest du nicht einfach schreiben können "Wie kann ich Zusammenhänge zwischen Code und einer CAD-Zeichnung nachvollziehen, überblicken und warten"? Oder ist die Entropie (Informationsgehalt pro Datenmenge) dieser Botschaft doch höher als angenommen?
Genau das ist der Vorteil von Visualisierungen!
Der Vorteil von Visualisierungen im Allgemeinen wird nicht abgestritten.
In der Konzeptentwicklung werden aber nicht nur zwei sondern sehr viele Aspekte von unterschiedlichen Domainen aufeinandergestellt - HW, SW, Management, Testen, Wartung, Operationen, Prozesse etc. und die kannst Du ja gerne direkt im Code warten fürs Changemanagement. Wir Profis machen es nicht so ...
Wir auch nicht. Wir verwenden Bugtracking-Systeme, Versionskontroll-Systeme, ja manchmal sogar mach ich einen Rechtsklick in Visual Studio und schau mir das Klassendiagramm (nicht UML-konform) an. Das kann man alles jeder für sich machen, da braucht man keinen Manager, der jetzt dick auflabert und sich auf UML was einbildet.
Genau deshalb betreibt man Abstraktion und Modellierung. Das ist nicht nur in der SW-Entwicklung so, dass ist in faßt allen Fachbereichen so. Und was soll jetzt hier die Ausrede sein es nicht zu tunen [tun?]. Das Du eine Codezeile schneller ändern kannst?!
Jetzt auf einmal wieder so pragmatisch? Du erinnerst mich die meiste Zeit eher an einen Manager, der seine Mitarbeiter anweist "mach' mir mal ein UML-Diagramm, damit ich ..Roundtrip-Engineering...Domainmodellen...Stakeholder...bidirektionale Traceability...remarks...Changemanagement ... kann." und danach wird es zu den Akten gelegt. Sowas ist einfach nur g'schaftlig.
UML kann man schon hernehmen, wenn man sich an der umständlichen Notation nicht stört aber gespickt mit Buzzwords und Wichtigtuerei kommt es zu oft in die Hände von Leuten, die glauben, dass es ohne gar nicht mehr geht. Und das ist das Problem bei UML. 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). Aber die Wirtschaftler haben es schon für sich entdeckt und Marc++us sagte schon einmal treffend, dass du bereits die dunkle Seite betreten hast.
-
lucky_tux schrieb:
Es ist wie schon gesagt einfacher wenn alle Beteiligten eine Sprache sprechen. Ein wenig abstrakt gesehen: Wohin soll es führen, wenn der Analyst deutsch, der Designer englisch und der programmierer französisch spricht; es würde keine gelungene kommunikation zu stande kommen.
Es ist fraglich, ob UML genau dieses Problem wirklich löst. Ist es wirklich das Problem, dass ich etwas nicht als Klasse verstehen kann, wenn du den Kasten eckig machst und ich rund?
Ich glaube, dass Kommunikationsprobleme mehr high-level sind, wenn man eine Lib für irgendwas plant, dass die Leute unterschiedliche Vorstellungen haben, wie man sowas benutzen soll, wenn es fertig ist. Solche Probleme löst UML nicht. Ein Klassendiagramm kann ich schon lesen und ich lache auch keinen aus, wenn er nicht weiß, dass '#' protected heißt, nur weil es unsinnigerweise Sprachneutral erzwungen wird.
-
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
-
Optimizer schrieb:
Es ist fraglich, ob UML genau dieses Problem wirklich löst. Ist es wirklich das Problem, dass ich etwas nicht als Klasse verstehen kann, wenn du den Kasten eckig machst und ich rund?
Ist es wirklich das Problem, dass jemand "void main()" schreibt und der andere "int main()" wenn der Compiler doch eh das gleiche draus macht? Nein? Richtig. Trotzdem hat man sich halt mit UML auf einen Visualisierungsstandard geeinigt. Was ist daran so schlimm?
MfG SideWinder
-
@SideWinder: Studierst du Wirtschaftsinformatik?
-
Nein.
MfG SideWinder
-
Sehe gerade, du bist noch Schüler. Was willst du mal studiern?
-
Entweder ein anderes technisches Studium oder Informatik in maximal 4 Jahren.
MfG SideWinder
-
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