UML und Offshoring: Was ist wahr, was ist Legende?

Viele von euch haben bestimmt auch schonmal von euren Profs oder Berufsschullehreren die Aussage gehört, dass man eigentlich nur noch in Billiglohnländern programmiert und demnächst nur noch UMLs bei uns gemacht werden.

Aus der Praxis habe ich aber ein ganz anderes Bild. Unternehmen die mit Offshoring arbeiten/gearbeitet haben sind eher unzufrieden. Man kann die Leute eben nicht als Codeklopfer missbrauchen und sozio-kulturelle Faktoren sind aus der Theorie komplett ausgenommen.

Das viel gelobte UML ist vielleicht eine gute Stütze zur Dokumentation aber die vollständige Modellierung des Systems ist so aufwendig, dass man auch gleich selber programmieren kann. Gibt es Tools die exakte Round-Trip-Entwicklung möglich machen?

Ich kann mir auch nur schwer vorstellen, dass man die Modellierung so exakt machen kann, dass quasi komplett mechanisiertes Programmieren übrig bliebt. Selbst wenn man das schafft: Wie motiviere ich denn die Mitarbeiter und was spricht dagegen einen solchen Job von einer Software durchführen zu lassen?

Mich würde interessieren:* Was hab ihr für Erfahrungen gemacht?

• Welche Tools kann man Einsetzen?
• Gibt es Literatur, Statistiken oder Studien die das Bild genauer machen können?

Gruß

Levi

Guten Morgen.

Wir hatten dazu schon mal ein Thema aber ich finde offensichtlich im Moment nicht die richtigen Stichworte fuer die Suche.

Es ist wahr, dass viele Projekte in Indien, China, oder Russland umgesetzt werden.
Aber ich denke, dass man das nich alles ueber einen Kamm scheren kann.
Ich denke, dass es auch vor allem auch darauf ankommt, welches Business-Wissen fuer die Software benoetigt wird. Spezielle Finanzworkflows fuer den deutschen Markt...ich bezweifel, dass das als Offshore so gut klappt. Basis-Wissen vielleicht eher.
Probleme, die es neben kulturellen Hindernissen gibt, ist vor allem auch die Ressourcenverwaltung und die Zeitunterschiede.
Oft sind das ja Auftragsentwickler, die ihre Mannschaft spontan zusammen stellen oder mal mitten drin austauschen, weil spezielles Wissen woanders benoetigt wird.
Ich bezweifel auch, dass es ohne spezielle Offshore-Betreuung durch einen Internen klappt. Personell muss auch intern bei einem groesseren Projekt investiert werden.

Ich bestaetige aber Deine Vermutung, dass man niemals alles planen kann - genauso wie, dass niemals alles in der Software-Entwicklung dokumentiert wird.
Was Du bei Tools genau meinst weis ich nicht. Projekt-Planungstools wie MS-Project oder Jira und TFS sind ja nicht auf sowas speziell zugeschnitten.

Ich kenne ein Paar Firmen die Ihre Entwicklung ende der 90er ausgelagert haben, und dann alle, ausnahmslos zurückgekommen sind.

Es ist nicht so das da wo sie hingegangen sind schlecht gearbeitet wurde, aber die Kommunikationsprobleme haben zu Verzögerungen und Kostenexplosionen geführt die das ganze Adabsurdum geführt haben.

Und wenn Professoren immer noch glauben das eine SW von der Idee bis zur Implementierung nur einmal geplant wird, sollten sie evtl ihre Lochstreifen beiseite legen und mal schauen ob sich in den letzten 20 Jahren nicht doch etwas getan hat.

Und wenn Professoren immer noch glauben das eine SW von der Idee bis zur Implementierung nur einmal geplant wird, sollten sie evtl ihre Lochstreifen beiseite legen und mal schauen ob sich in den letzten 20 Jahren nicht doch etwas getan hat.

Ja, das ist nur ein Knackpunkt. UML-Tools (z.B. VisualParadigm) propagieren ja die "Round-Trip"-Entwicklung. Aber das Problem alles erstmal in ein UML-Klassendiagramm gegossen haben zu müssen bleibt ja.

Hallo zusammen,

Wir hatten dazu schon mal ein Thema

vermutlich ist folgender Thread gemeint:
Probleme in verteilten und multikulturellen Teams

und am Rande vielleicht auch noch:
Im Ausland arbeiten?!

herbivore

Danke herbivore! Mich interessiert allerdings eher die technische Seite.

Also ich kenne aus meiner Praxis ausschließlich UML in der Entwurfsphase als Werkzeug zur Dokumentation im Pflichtenheft. Mich würde interessieren ob jemand gute Erfahrungen damit gemacht hat die UML-Klassendiagramme per Round-Trip in der Entwicklungsühase weiterzubenutzen.

Hallo Levion,

Wikipedia sagt dazu in UML tool:

There is some debate among software developers about how useful code generation as such is. It certainly depends on the specific problem domain and how far code generation should be applied. There are well known areas where code generation is an established practice, not limited to the field of UML.

The idea of completely leaving the "code level" and starting to do "programming" directly from the UML diagram level (i.e., design level) is quite debated among developers. That is the vision for Model-driven architecture (MDA). This idea is not in such widespread use compared to other software development tools like compilers or software configuration management systems.

An often cited criticism is that the UML diagrams lack the detail that is needed to contain the same information as is covered with the program source: Jack W. Reeves states that the final embodiment of the design lies in the source code.

Insbesondere der letzte Absatz bestätigt, dass UML-Diagramme normalerweise nicht genug Informationen enthalten, um daraus den kompletten Quellcode generieren zu können und beantwortet damit, was du sowieso schon vermutet hast.

Außerdem hat UML eine große Anzahl von verschiedenen Diagrammtypen. Für die Spezifikation, die Basis für die Kommunikation von Auftraggeber und Auftragnehmer ist, werden meistens Anwendungsfalldiagramme und Aktivitätsdiagramme benutzt. Für Codegenerierung bzw. Roundtrip eher Klassendiagramme und Sequenzdiagramme. Schon das spricht dafür, dass die Weiterverwendung der Diagramme aus der Spezifikation ihre Grenzen hat.

herbivore

Aus meiner Erfahrung kann ich sagen, dass UML ein sehr gutes Hilfsmittel sein kann, wenn man es richtig einsetzt und es auch ernst nimmt. Beispielsweise ist es deutlich einfacher, potentielle Probleme bei der Umsetzung von großen Projekten zu identifizieren, wenn man sich wirklich die Arbeit macht, und während der Konzeptionsphase neue Erkenntnisse in ein UML Modell einpflegt. Man erspart sich so nie alle Detail-Probleme, die bei der Realisierung auftreten, aber man geht im besten Fall bereits mit einer sehr konkreten Vorstellung an die Umsetzung heran und vermeidet so konzeptionelle Fehler von vorneherein.

Ich hab mir zur Anfangszeit meines Studiums nie richtig den Sinn von UML vorstellen können, da hat mir eine Vorlesung an der Fernuni Hagen "Software Engineering II" (ich weiß nicht, ob es die heute noch unter diesem Namen gibt) wirklich die Augen geöffnet. Dort wird im Skript über ein paar hundert Seiten eine systematische Vorgehensweise von der ersten Problembeschreibung eines Kunden bis zum vollständigen UML-Modell hin zu der direkt daraus abgeleiteten Implementierung beschrieben.
Gut, da ist wohl ein sehr idealisierter Fall beschrieben, aber ich konnte Einiges aus dieser Vorgehensweise bereits in zwei Großprojekten (> 2 Jahre) adaptieren und kann die Lektüre nur empfehlen.

Zum Thema Offshore - bisher haben alle Auftraggeber für die ich gearbeitet habe, damit ausnahmslos schlechte Erfahrungen gemacht. Ich denke, das liegt nicht daran, dass Inder oder Chinesen "dümmer" oder "weniger ernsthaft" sind, sondern eher an der Kommunikationshürde, die dabei zu Tage tritt. Es ist schon schwierig, wenn Personen im selben Raum ihre Sichten auf eine Problemstellung austauschen wollen, und am Ende alle mit demselben Kenntnisstand heraus gehen sollen ("vom Selben reden"). Wenn die Personen aus verschiedenen kulturellen Kreisen stammen und sich nur über elektronische Hilfsmittel austauschen können, wird es natürlich nicht einfacher. Da hilft auch kein noch so ausgefeiltes UML-Modell, denn dieses kann nie vollständig den Kommunikationsbedarf ersetzen.

[...]
Zum Thema Offshore - bisher haben alle Auftraggeber für die ich gearbeitet habe, damit ausnahmslos schlechte Erfahrungen gemacht.
[...]

Guten Tag zusammen,

die Frage ist doch, mit welcher Erwartungshaltung gehe ich an diese Sache heran?
Wenn ich nur das reine Ergebnis betrachte, kann ich diese negative Erkenntnis teilen. Es wird eine Programmierung in Auftrag gegeben und exakt so ausgeführt, wie man sich beschrieben hat. Sehr schnell und auch technisch auf hohem Niveau. Warum sind wir trotzdem unzufrieden damit?
Weil wir selbst das Ergebnis nicht exakt genug spezifiziert haben und es auch keinen Raum für (für uns) Logische Erweiterungen/Optimierungen gibt, die sich erst während dem programmieren herausstellen.

Kann man dafür jetzt den rumänischen Inder in China verantwortlich machen?
Wir verlangen hohe Preise für eine Individualisierung beim Kunden, die Maßgeschneidert ist. Das ist mit outsourceing in dem Rahmen nicht möglich. Zumindest nicht in meinen Projekten.

Nach einem anfänglichen Versuch mit der Auslagerung von Teilbereichen, hat sich herausgestellt, dass wir in der Zeit in der man das UML macht und noch eine Seite Text dazu erfasst, plus die anschließende Kontrolle und Optimierung des Ergebnisses, keinen Zeit- & Geldvorteil bringt.