SCHWERPUNKT: MODELLE - Sigs-Datacom GmbH

Poster:
Verteilte
Versionskontrolle
November / Dezember 2012 • Nr. 6
€ 8,90 Österreich € 9,90 Schweiz sfr 16,50
www.OBJEKTspektrum.de
Die Zeitschrift für Software-Engineering und -Management
SCHWERPUNKT: MODELLE
SCHWERPUNKT: MODELLE
BPMN 2.0: Eine Zwischenbilanz
Analoge Modellierung
Die Lösung des MDD-Paradoxons
FACHARTIKEL
G 6540F
Anforderungen ermitteln – Zehn Schritte für die Praxis
Architekturen für moderne Web-Anwendungen - Teil 2

Konferenz
Ausstellung
OOP
21. – 25. Januar 2013 22. – 24. Januar 2013
2013
software meets business
ICM International Congress Center München
15%
plus eBook Reader
3.0 von TrekStor
bei Anmeldung bis zum
30.11.2012
CONTINUOUS INNOVATION:
The Foundation for Success
Software Architecture (incl. Professional Architect) | Web Architecture Neu
Trends & Techniques (incl. Automotive & DevOps) Neu | Integration
Architecture | Project Management & Lean IT Neu | Technologies (incl.
Language & Mobile Development) | Testing & Quality (incl. Security Testing)
Requirements Engineering & Acceptance Test Driven Development Neu
Agile, Lean, Scrum & Kanban | Reinventing Management Neu
Keynotes
+++ How Secure Are We? Identity Management and Social Networking Threats, Jeff Crume (IBM) +++ Beyond
Budgeting – A Management Model for New Business and People Realities, Bjarte Bogsnes (Statoil) +++ Generation
iPhone – die Zukunft vernetzt, Masanori Fujita (Zühlke) +++ The Coming of Age of Platforms, Mary Poppendieck +++
Autobahn for Racing to a Billion Users, Subbu Subramanian (Facebook) +++
Veranstalter:
Programm und Infos:
www.OOP2013.de

editorial
chefredakteur
IT’S NEXT TOP-MODELL?
Computer auf dem Catwalk? Das Cover dieser Ausgabe von
OBJEKTspektrum zeigt, dass auch unsere anscheinend so rationale
Szene hochgradig von Mode und Zeitgeist geprägt ist.
Deutlich wird das zum Beispiel, wenn man die Entwicklung der
Diskussion in der IT-Gemeinde über Modellierung und Modelle
im Laufe der vergangenen Jahre und Jahrzehnte betrachtet.
Immer neue Modellierungstrends sind über die Zeit entstanden
und teilweise auch wieder verschwunden.
Mit den Datenbanken haben vor langer Zeit Datenmodelle
Einzug in die IT gehalten – diese waren aus der real existierenden
Anwendungsentwicklung der 80er Jahre kaum wegzudenken.
Sogar Unternehmensdatenmodelle wurden propagiert und die IT
damit im Gesamtunternehmen strategisch geadelt. Daneben entstand
eine erste Softwareguru-Szene mit Persönlich keiten wie Tom
DeMarco und Ed Yourdon, die Datenfluss modelle der
Strukturierten Analyse predigten. Zumindest die Modelle der
Strukturierten Analyse sind inzwischen IT-Geschichte.
Die 90er Jahre waren von objektorientierten Modellen und
ihren Päpsten, wie Grady Booch, Ivar Jacobson und James
Rumbaugh, geprägt. Die Unified Modeling Language (UML) war
das kristallisierte Ergebnis dieser Epoche und wirkt bis heute
nachhaltig auf unsere Arbeit. Die Verwendung der UML ist heute
offensichtlich geübte Praxis. Umso wertvoller empfinde ich den
Artikel von Gabriele Taentzer und Thorsten Arendt in dieser
Ausgabe von OBJEKTspektrum, in dem die beiden praktische
Tipps für die Qualitätssicherung von UML-Modellen geben.
Einen Höhepunkt der objektorientierten Modellierung haben
wir seit Anfang dieses Jahrtausends mit den Ansätzen der Model
Driven Architecture (MDA) erlebt, die die alte Vision wiederbelebt
haben, dass man aus Modellen Software generieren kann.
Dieser Ansatz für Softwareentwicklung ist heute noch weit verbreitet,
auch wenn nicht ganz so lautstark darüber berichtet wird
wie über aktuelle Hype-Themen. Benedikt von Treskow hat in
diesem Heft einen wirklich guten Erfahrungsbericht hierüber
geschrieben und Daniela Schilling geht sogar noch einen Schritt
weiter, wenn sie ihren Generator-Generator mit dem Ziel der Ent -
mysti fizierung des modellgetriebenen Designs vorstellt.
Parallel zu diesen Modellen hat die Modellierung von Ge -
schäfts prozessen immer mehr an Fahrt aufgenommen. Einen
ersten Schub bekam das Thema dadurch, dass August-Wilhelm
Scheer vor den erfolgreichen Einsatz von SAP-Standardsoftware
die Modellierung von Prozessketten setzte. Es gibt immer noch
Erweiterungen von Prozessmodellierungsansätzen wie den von
Holger Breitling und Stefan Hofer in ihrem Artikel zur exemplarischen
Geschäftsprozessmodellierung. Im Sinne der Standardi -
sierung spielt aber gewiss BPMN eine immer größere Rolle, wo -
rüber Jakob Freund in seinem Artikel berichtet.
Der aktuelle IT-Zeitgeist, der ja wesentlich durch die agile Soft -
ware entwicklung beeinflusst ist, schiebt Modelle immer häufiger
in die Ecke der zu schwergewichtigen Entwicklung. Ist das der
Anfang vom Ende der Modellierung in der Anwendungsent -
wicklung? Kann man einen roten Faden in dieser Modell -
geschichte erkennen? Oder sind es wirklich nur sich mehr oder
weniger wiederholende Moden?
Fangen wir einmal mit der Frage an, was Modellierung eigentlich
soll. Modelle dienen definitionsgemäß der Abstraktion – sei es der
Abstraktion und Formalisierung von fachlichen Anforderungen
und damit der besseren Kommunika tion zwischen Anwendern
bzw. Auftraggebern und Entwicklern oder der Abstraktion im
Sinne einer architektonischen Struk turierung oder sogar der
Generierung von Anwendungssystemen. Aber für all diese Ziele
sind Modelle nicht unumstritten oder ohne Alternative.
Sowohl die objektorientierte Modellierung als auch die
Geschäftsprozessmodellierung haben sich das Ziel einer besseren
Kommunikation mit dem Auftraggeber auf ihre Fahnen geschrieben.
Die objektorientierten Modelle haben diesen Anspruch nicht
immer erfüllt. Genau in diesem Punkt wird die UML-
Verwendung in agilen Projektkontexten oft als Verschwendung
empfunden, wenn die Modelle keinen direkten Nutzen für die
Anwender darstellen, sondern nur als Übergabe-Artefakte zwischen
zwei Entwicklungsphasen dienen. Hier wird in agilen
Projekten die direkte und persönliche Kommunikation zwischen
Fachleuten und Entwicklern in kurzen Iterationen bevorzugt.
Zur Kommunikation zwischen Fachbereich und Entwicklung
scheinen Prozessmodelle besser geeignet zu sein. Sie können auch
einen fachlichen Rahmen um agile Anforderungen bilden, die in
User-Storys formuliert werden und damit nicht nur das System
aus Anwendersicht dokumentieren, sondern auch wesentliche
Orientierungs- und Strukturierungshilfe geben. Kim Nena
Duggen und Stefan Toth stellen in ihrem Artikel sogar einen
leichtgewichtigen Prozessmodellierungsansatz vor, der ohne
Werkzeugeinsatz mit kurzen Feedback-Schleifen ideal in agile
Entwicklungsmodelle passt. Und in manchen werkzeuggetriebenen
Ansätzen wird auch hier Software für automatisierte Work -
flows aus Prozessmodellen generiert.
Zur Strukturierung (und damit auch Dokumentation) komplexer
Softwaresysteme hat sich die UML in ihrer Tradition der
Daten- und Funktionsabstraktion wirklich bewährt und es gibt
meiner Meinung nach keine wirkliche Alternative zu ihr, auch
wenn Martin Fowler öffentlichkeitswirksam forderte, dass zur
Dokumentation eigentlich guter Code ausreichen sollte. Die
zwischenzeitlich fast religiöse Diskussion darum hat er selbst entschärft,
indem er den Nutzen von Modellen gerade zur
Strukturierung komplexer Systeme einräumt.
Ich habe die Hoffnung, dass sich die IT zunehmend von modischen
Trends emanzipiert. Es gibt keine „Weltformel” für alle
Probleme in der Anwendungsentwicklung, sondern wir müssen
für die jeweiligen Aufgaben adäquate Verfahren, Artefakte und
Werkzeuge wählen. Handwerklich saubere Arbeit – in der
Spezifikation, der Modellierung und in der Programmierung –
ersetzt mehr und mehr die Tool-Gläubigkeit in der Software -
entwicklung. Gutes Handwerk braucht gute Ausbildung und das
Nutzen von Erfahrungen. Wir müssen nicht mit Kanonen auf
Spatzen schießen, aber gerade in großen und komplexen
Systemen können wir auf die Erfahrungen, die wir in den letzten
Jahrzehnten mit Architekturen und Modellen gemacht haben,
nicht verzichten.
Ihr Thorsten Janning
NEWS
LETTER
Alle zwei Monate kostenlos
• Heftinhalte • ausgewählte Artikel im Pdf-Format • ergänzende Weiterbildungsangebote
Anmeldung unter www.sigs-datacom.de/os/newsletter/

?
Frage des Monats
Stimmen Sie mit ab!
sigs-datacom.de/fachzeitschriften/objektspektrum/os-umfrage.html
SCHWERPUNKT:
MODELLE
Daniela Schilling
VOM SCHUSTER MIT DEN GERADEN
ABSÄTZEN:
DIE LÖSUNG DES MDD-PARADOXONS · · 32
Generatoren und domänenspezifische Sprachen (DSLs) stellen
zusammen mit Modellen zwar die zentralen Elemente der
modellgetriebenen Entwicklung dar, sie selber werden aber mit
den herkömmlichen Methoden paradoxerweise nicht modellgetrieben
entwickelt. Daraus resultiert, dass die Generator- und
DSL-Entwicklung als zeitaufwändige und fehleranfällige
Geheimwissen schaft gilt. Dieser Artikel stellt eine Lösung vor, mit
der dieses Paradoxon behoben werden kann.
EDITORIAL · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 3
AUS DER SZENE · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 6
STELLENMARKT · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 56
BUCHBESPRECHUNG
FRANK PIENTKA REZENSISERT:
„SOFTWAREARCHITEKTUREN DOKUMENTIEREN
UND KOMMUNIZIEREN” VON STEFAN ZÖRNER · · · · · 71
IMPRESSUM · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 75
KONFERENZBERICHTE
VORSCHAU: OOP 2013 · · · · · · · · · · · · · · · · · · · · · · · · · · 84
RÜCKSCHAU: ARCHITEKTUREN 2012 · · · · · · · · · · · · 85
SEMINARE & VERANSTALTUNGEN · · · · · · · · · · · · · · · 86
THEMENVORSCHAU & INSERENTENVERZEICHNIS · · 87
Template-basierte Spezifikation eines
Generators.
schwerpunkt
Jacob Fahrenkrug
Volker Kultermann
VON SURFERN UND SCHWERÖLTANKERN:
TROTZ KULTURSCHOCK ZUM
WIRTSCHAFTLICHEN ERFOLG · · · · · · · · · · 50
Die agile Welt wird in der aktuellen Literatur wie eine paradiesische
Insel beschrieben. Auf dieser Insel ist man angeblich angekommen,
sobald die Organisation agil arbeitet. In der Umsetzung
von Projekten arbeitet man jedoch selten isoliert von der
Außenwelt. Es gibt Partner, Subunter nehmer oder Kunden, die
ebenfalls ihren Teil zum Projekt beitragen. Nicht immer sind diese
Mitstreiter agil organisiert. In der Realität sind Projekte irgendwo
zwischen agilen Surfern und schwerfälligen Schweröltankern weit
verbreitet. Der Artikel beschreibt Herausforderungen und Best
Practices, um solche Projekte trotz aller Unterschiede in der
Projektorganisation zu einem wirtschaftlichen Erfolg zu bringen.
Holger Breitling
Stefan Hofer
BEISPIELHAFT GUT MODELLIERT:
EXEMPLARISCHE GESCHÄFTSPROZESS-
MODELLIERUNG IN DER PRAXIS · · · · · · · · · · · · · · · · · · · 8
Gabriele Taentzer
Thorsten Arendt
BESSER MODELLIEREN:
QUALITÄTSSICHERUNG VON UML-MODELLEN · · · · · · 14
TITEL-STORY
Stefan Toth
Kim Nena Duggen
ANALOGE MODELLIERUNG:
ÜBER DIE QUALITÄTSSTIFTENDE
ABKEHR VOM TOOL · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 20
TITEL-STORY
4 5 www.objektspektrum.de

Poster-
Beilage
Das beiliegende Poster zu Distributed Version Control
lieferte uns die bbv AG. Der Postersponsor eröffnete
kürzlich eine Niederlassung in München.
schwerpunkt
Jakob Freund
BPMN 2.0:
EINE ZWISCHENBILANZ · · · · · · · · · · · · · · · · · · · · · · · · · 26
TITEL-STORY
Daniela Schilling
VOM SCHUSTER MIT DEN GERADEN ABSÄTZEN:
DIE LÖSUNG DES MDD-PARADOXONS · · · · · · · · · · · · 32
Benedikt von Treskow
MODELLGETRIEBENE SOFTWAREENTWICKLUNG
IN EINEM GROSSPROJEKT:
EIN PRAXISBERICHT ÜBER DEN
ERFOLGREICHEN EINSATZ VON MDD · · · · · · · · · · · · · 39
Christof Ebert
ANFORDERUNGEN ERMITTELN:
ZEHN SCHRITTE FÜR DIE PRAXIS · · · · · · · · · 61
Eine Anforderung beschreibt, was der Kunde oder Benutzer
vom Produkt erwarten. Dies umfasst Ziele, Nutzen,
Funktionen, Qualitätseigenschaften und Randbedingungen.
Doch woher kommen die Anforderungen? Sammelt man
Anforderungen nur ein, floppt das spätere Produkt, weil die
Eigenschaften fehlen, die ein Produkt erst richtig attraktiv
machen. Anforderungen müssen gezielt entwickelt werden –
und das ist nicht einfach. Der Artikel stellt die methodische
Ermittlung von Anforderungen in zehn Schritten vor.
fachartikel
Jacob Fahrenkrug
Volker Kultermann
VON SURFERN UND SCHWERÖLTANKERN:
TROTZ KULTURSCHOCK ZUM
WIRTSCHAFTLICHEN ERFOLG · · · · · · · · · · · · · · · · · · · · 50
Christof Ebert
ANFORDERUNGEN ERMITTELN:
ZEHN SCHRITTE FÜR DIE PRAXIS · · · · · · · · · · · · · · · · · · · 61
TITEL-STORY
Andreas Hartmann
Tom Hombergs
Eberhard Wolff
ARCHITEKTUREN FÜR MODERNE
WEB-ANWENDUNGEN:
TEIL 2: JAVASCRIPT UND JEE-PORTAL-SERVER · · · · · 72
TITEL-STORY
Patric Keller
Veit Köppen
Peter Liggesmeyer
SICHERHEIT IN DER FAHRZEUGTECHNIK:
SOFTWARE IN EINGEBETTETEN SYSTEMEN · · · · · · · · 78
Herausforderung: Viele Interessengruppen mit
eigenen Zielen.
Patric Keller
Veit Köppen
Peter Liggesmeyer
SICHERHEIT IN DER FAHRZEUGTECHNIK:
SOFTWARE IN
EINGEBETTETEN SYSTEMEN · · · · · · · · · · · · 78
Die Fahrzeugtechnik ist einer der wichtigsten Treiber für
Innovationen bei der Entwicklung komplexer Systeme. Trotz
der wachsenden Komplexität muss Qualität sichergestellt
werden. Das erfordert leistungsfähige Modellierungs- und
Analysetechniken sowie geeignete Entwicklungsprozesse
und Verfahren, die das Verstehen der komplizierten
Sachverhalte erleichtern. Der Artikel beleuchtet aus Sicht
der Qualitätssicherung Probleme und Einflussfaktoren, die in
der Entwicklung von eingebetteten Systemen zumeist nicht
hinreichend berücksichtigt werden.
6/2012 www.sigs-datacom.de

aus der szene
Links und rechts
des Wegs schauen
Dr. Johannes Textor:
von den Gassen
Lübecks an die
Grachten Utrechts.
Informatik ist Informatik – und Medizin
ist Medizin. Das ist natürlich eine
Aussage, die so nicht stimmt. Denn
besonders spannend wird es immer
dann, wenn die eine Disziplin die andere
befruchtet – und vice versa. Dr.
Johannes Textor weiß, wovon die Rede
ist. 1979 in Göttingen geboren, studierte
er Informatik mit Anwendungsfach
Medizinische Informatik an der
Lübecker Universität, seit September
2011 forscht und arbeitet er in Utrecht.
An der größten Universität der
Niederlande beschäftigt er sich mit
„Computational Immunology“ und
„Artifiziellen Immunsystemen“. Sein
aktuelles Team an der Utrechter Uni versität besteht aus rund 25
Postdocs aus der ganzen Welt.Von der Gesellschaft für Informatik
(GI) wurde Textor kürzlich für die beste Informatik-Dissertation
im deutschsprachigen Raum ausgezeichnet. Das Thema seiner
Doktorarbeit lautete: „Search and Learning in the Immune
System: Models of Immune Surveillance and Negative Selection”.
Textors Leitfrage war: „Können Methoden der Informatik das
Funktionieren des menschlichen Immunsystems erklären?“
In seiner Forschung hat Textor die T-Zellen des menschlichen
Immunsystems im Blick. Diese kann man sich als eine Art
„Polizeistreife des Körpers” vorstellen: Jede T-Zelle ist spezialisiert
auf die Erkennung von ganz bestimmten Antigenen (Krank -
heitserregern) und patrouilliert ständig durch den Körper, um überall
nach diesen Antigenen zu suchen. Textor geht in seiner
Dissertation den Fragen nach, wie es die T-Zellen schaffen, ein in
den Körper eindringendes Antigen meist nach nur wenigen Stunden
zu finden, und wie es das Immunsystem trotz der riesigen Vielfalt
Die Simulation der Erkennung von Antigenen in einem infizierten
Lymphknoten des menschlichen Immunsystems. Nach
acht Stunden haben alle Zellen das Antigen gefunden und ihre
Bewegung entsprechend stark verlangsamt (rote Farben).
und rasend schnellen Entwicklung der Krankheitserreger in unserer
Umwelt schafft, einen nahezu vollständigen Schutz aufzubauen.
Die Arbeit betrachtet diese beiden Fragen aus einem neuen
Blickwinkel – aus dem der Informatik. Viele der Probleme, die T-
Zellen lösen müssen, sind nämlich auch in der Informatik
bekannt: Wie lässt sich ein Problem effizient auf viele kleine
Agenten ohne zentrale Kontrolle verteilen? Wie kann ein System
auf anormale und potenziell gefährliche Signale zuverlässig reagieren,
wenn es diese Signale nie zuvor gesehen hat? Die Arbeit
nutzt analytische Werkzeuge aus Gebieten der Informatik, wie
der Schwarmintelligenz und dem maschinellen Lernen, um genau
zu verstehen, wie T-Zellen diese schwierigen Aufgaben lösen.
Die so konstruierten Modelle sind in der Lage, überprüfbare
Aussagen über das Verhalten des Immunsystems in bestimmten
Situationen zu treffen. So wird beispielsweise ein Modell verwendet,
um vorherzusagen, welche Teile der Proteine von Viren –
konkret wird das HIV-Virus betrachtet – vom Immunsystem
erkannt werden müssten. Es zeigt sich, dass diese Vorhersagen
genauer sind als die aller anderen bislang vorgeschlagenen
Erklärungsmodelle. Solche Vorhersagen könnten in der Zukunft
bei der Entwicklung von Impfstoffen für neuartige Krank heits -
erreger von Nutzen sein.
Neben interdisziplinärer Inspiration und Doktorvätern aus
unterschiedlichen Fächern, wie dem Informatiker K. Rüdiger
Reischuk und dem Mediziner Jürgen Westermann von der
Universität Lübeck, benötigt man für solche Erkenntnisse
Software: Textor hat sie entwickelt und bietet sie zum Download
an. Wie „Negative Selection“ funktioniert, klären Algorithmen,
die in Java geschrieben sind. „DAGitty“ heißt ein Werkzeug, mit
dem sich kausale Diagramme zeichnen und analysieren lassen,
geschrieben ebenfalls in JavaScript. „LImmSim” ist eine agentenbasierte
Simulation des Immunsystems, geschrieben in C++.
Wenn Textor in die Zukunft blickt, dann kann er auch links
und rechts des Wegs schauen: Eine Professur in der
Bioinformatik? Warum nicht? Aber auch in der institutionellen
Forschung gibt es Möglichkeiten. Eine Arbeit in der Industrie
kann er sich ebenfalls vorstellen – die Bioinformatik bietet viele
Optionen.
dagitty.net/
bioinformatics.bio.uu.nl/textor/
Schon am Anfang
die Regeln kennen
Gereon Weiß, Gruppenleiter Automotive Software bei der
Fraunhofer Einrichtung für Systeme der Kommunikationstechnik
(ESK München), weiß, wo häufig der Schuh drückt: Deshalb hat
er gemeinsam mit seinem Team den „Richtlinien-Checker“ entwickelt.
Damit können Softwareentwickler bereits bei der Model -
lierung überprüfen, ob die Modelle den Richtlinien entsprechen.
Die Definition von Richtlinien und die automatisierte Prüfung
der Einhaltung dieser Richtlinien sollen den Entwicklungsprozess
zusätzlich formalisieren, um Fehler zu vermeiden. „Zwar gibt es
bereits Möglichkeiten, seine Modelle auf Regelkonformität zu
prüfen. Aber uns hat es gefehlt, verschiedene Sets an Regeln zu
testen – je nach Modell und nach Untersuchungsinteresse.
Deswegen haben wir unseren Richtlinien-Checker mit verschiedenen
Profilen entwickelt“, sagt Weiß.
Gerade Entwickler von Software für Fahrzeuge sehen sich
einem hohen Innovationsdruck und immer kürzer werdenden
6 7

aus der szene
Foto: Fraunhofer ESK.
Foto: Fraunhofer ESK.
Gereon Weiß weiß,
wie man vorne prüft,
um hinten Fehler zu
vermeiden.
Mit dem Richtlinien-Checker der Fraunhofer ESK können
Softwareentwickler bereits bei der Modellierung überprüfen,
ob die Modelle den Richtlinien entsprechen.
Produktzyklen gegenüber. Hinzu kommt
die hohe Varianten vielfalt der Software.
Dem begegnen sie mit modellbasierter
Softwareentwicklung: Die sehr umfangreichen
Softwaremodelle müssen
bereits im Entstehungsprozess auf ihre
Richtlinien konformität geprüft werden,
um hochqualitative Software zu entwi -
ckeln. Gleichzeitig kann durch eine frühe
Qualitätsprüfung der Software der
spätere Aufwand für das Testen um
rund 30 Prozent reduziert werden. Die
Profile umfassen ein Set von Regeln, die
der Entwickler selbst definieren kann.
So können beispielsweise spezielle
Profile für Abnahmetests von Modellen
erstellt werden, die die Übernahme zugelieferter
Modelle absichern. Auch können
gezielt Profile für Entwickler genutzt werden, die bekannte
Fallstricke und die Einhaltung Framework-spezifischer Anfor -
derungen überprüfen. Hiermit können Fehler in Modellen frühzeitig
vermieden werden, die in der Regel erst zu einem späteren
Zeitpunkt bemerkt werden, wenn ihre Beseitigung teuer wird.
Außer den klassischen Regeln können auch informelle Aspekte,
zum Beispiel die Gestaltung von grafischen Modellelementen, wie
Statecharts und anderen Diagrammtypen, mit Richtlinien festgehalten
und überprüft werden. Dadurch stellt man eine einheitliche
Modellierung sicher und kann den Freiheitsgrad des Modellierers
flexibel definieren. Eine weitere Herausforderung bei der
Softwareentwicklung sind große und internationale Teams.
Dadurch müssen die Modelle teilweise länderspezifische Details
aufweisen oder in verschiedenen Sprachen geprüft werden. Auch
hier helfen die Profile des Richtlinien-Checkers, da so die Regeln
länder- oder projektspezifisch hinterlegt und auf Mausklick geladen
werden können.
esk.fraunhofer.de/de/projekte/richtlinien-checker.html
Die Internet-Chefin
Kostenlose Smartphones für alle 14.000 Mitarbeiter weltweit,
egal ob in Vollzeit oder Teilzeit angestellt, freies Essen in der
Kantine in Silicon Valley und neu gestaltete Büroräume für eine
freundlichere Atmosphäre am Arbeitsplatz – das waren einige der
ersten Maßnahmen von Marissa Mayer an ihrem neuen
Foto: picture alliance / dpa / Walter Bieri.
Marissa Mayer (37)
wechselte im Juli
2012 von Google zu
Yahoo, wo sie als
Vorstandsvorsitzende
das angeschlagene
Unternehmen aus der
Krise herausführen
soll.
Arbeitsplatz als Yahoo-Chefin. Kein
Wunder also, dass viele sie für die
„coolste Chefin der Welt halten”.
Mayer, die in Stanford Informatik
studiert hat, startete ihre Karriere beim
UBS Research Lab in der Schweiz. Beim
1998 gegründeten Internet-Startup
Google, das heute weltweit rund 32.500
Mitarbeiter beschäftigt und 2011 einen
Jahresumsatz von rund 38 Milliarden
US-Dollar hatte, begann sie 1999 als
„Mitarbeiterin Nummer 20”. Als
Produktmanagerin war Mayer maßgeblich
am Design aller Google-Produkte
beteiligt. Das Magazin Newsweek
bezeichnete sie vor einiger Zeit als
„Zarin für Produktstarts” und die Los
Angeles Times schrieb 2011 über sie,
„wohl kein anderer Mensch habe soviel
Einfluss darauf, wie Menschen das
Internet erleben”. Googles Suchmaske –
das ist vor allem eine puristische weiße
Seite, ein Suchfeld – das war's. Und genau das war einer der
Gründe für den enormen Erfolg und die Beliebtheit von Google.
Bereits 2008 zählte das amerikanische Wirtschafsmagazin
(Fortune) Mayer als Jüngste zu den „50 mächtigsten Frauen der
Welt”. Für Google war Mayer außerdem ein wichtiges
Aushängeschild und Sprachrohr des Unternehmens, die neben den
Konzernchefs Eric Schmidt, Larry Page und Sergey Brin bei
öffentlichen Auftritten, Präsentationen und Ankündigungen stets
im Rampenlicht stand.
Für viel öffentlichen Wirbel sorgte im Juli 2012 Mayers
Wechsel vom Internet-Giganten Google zum leicht angeschlagenen
Internet-Riesen Yahoo – nicht zuletzt, weil sie gleichzeitig
bekannt gab, im siebten Monat schwanger zu sein. Für Mayer
selbst, die nach kurzer Babypause direkt in ihrem neuen Job
weitermachen will, aber auch für ihren neuen Arbeitgeber Yahoo,
sei das kein Thema, betonten beide Seiten. Und trotzdem scheint
genau diese Konstellation – leitende Position und schwanger –
angesichts aktueller Diskussionen über die Frauenquote und die
Vereinbarkeit von Beruf und Familie die Menschen sehr zu
beschäftigen: „Wenn sie Erfolg hat, ist das ein Durchbruch für alle
Frauen”, sagte der amerikanische Unternehmensstratege Kevin
Coyne zu „wallstreetjournal.de” und er fährt fort: „Die Frauen
werden noch in Jahrzehnten von ihr sprechen”.
Bei ihrem neuen Arbeitgeber Yahoo steht Mayer nun vor der
schwierigen Aufgabe, das Unternehmen wieder auf Erfolgskurs zu
bringen. Mit rund 700 Millionen Nutzern weltweit zählt Yahoo
zwar ebenfalls zu den ganz Großen in der Internet-Branche,
jedoch kränkelt das Unternehmen schon seit Längerem.
Stagnierende Umsatzzahlen (2011 waren es „nur“ knapp 5
Milliarden US-Dollar), rückläufige Gewinnzahlen und gerichtliche
Auseinandersetzungen mit der Konkurrenz, zuletzt eine Klage
gegen Facebook, prägten die letzten Jahre. Kein Wunder also,
dass der Chefposten bei Yahoo als einer der schwierigsten in der
Branche gilt – mehrere Chefs kamen und gingen in den letzten
Jahren, zuletzt wurden Mayers Vorgänger Carol Bartz und Scott
Thompson von ihrem Arbeitgeber entlassen. Es bleibt abzuwarten
– und spannend –, ob es Mayer gelingen wird, den Erfolg von
Google auf Yahoo zu übertragen.
6/2012

schwerpunkt
mehr zum thema:
openmodels.at/web/bpm
die autoren
BEISPIELHAFT GUT MODELLIERT:
EXEMPLARISCHE
GESCHÄFTSPROZESS-
MODELLIERUNG IN DER PRAXIS
Szenariobasiert und konkret, piktografisch und fachbereichstauglich – durch diese Merkmale
eignet sich die exemplarische Geschäftsprozess-Modellierung (eGPM) besonders, um kooperative,
IT-gestützte Arbeitsprozesse zu beschreiben und zu untersuchen. Seit Dezember 2011
steht ein kostenfreies Modellierungswerkzeug für die eGPM zur Verfügung – ein guter Grund,
in diesem Artikel die seit Jahren in der Praxis erfolgreiche Methode und ihre
Anwendungsmöglichkeiten ausführlich vorzustellen.
Holger Breitling
(holger.breitling@c1-wps.de)
hat die exemplarische Geschäftsprozess-
Modellierung maßgeblich mit entwickelt und verantwortet
das Transformationsbüro in der
Geschäfts leitung der C1 WPS. Sein Haupt -
interesse liegt in der Beratung und dem Manage -
ment von großen Transformationsprojekten.
Die exemplarische Geschäftsprozess-Mo -
del lierung (eGPM) ist eine Model lierungs -
methode, mit der sich kooperative Arbeits -
prozesse anhand beispielhafter Abläufe
darstellen lassen. Sie besteht aus mehreren
Modelltypen und einem dazu passenden
Vorgehen.
Der Modelltyp Kooperationsbild bildet
das Zentrum der eGPM (siehe Abbildung 1).
Sein Vorläufer wurde in einem Kran -
kenhausprojekt entwickelt, um dort gemeinsam
mit den Fachkräften die Zusammen -
arbeit der einzelnen Abteilungen bei der
Behandlung von Patienten zu analysieren
(vgl. [Kra96], [Zül04]). Kooperationsbilder
sind szenariobasiert und visualisieren jeweils
ein zu untersuchendes Szenario.
Die wesentlichen Modellelemente des
Ko operationsbilds sind die beteiligten
Akteure und die von ihnen im Prozess verwendeten
Gegenstände. Diese Elemente
werden anhand der Bearbeitungsschritte
oder der Weitergabe von Gegenständen
zwischen den Akteuren verbunden. Im
Fokus der Modellierung stehen daher die
Fragen:
■ Wer macht was mit welchem Gegen -
stand?
■ Wer gibt welchen Gegenstand an wen
weiter?
■ Wer informiert wen mit Hilfe welches
Gegenstands?
Von diesen Grundfragen angetrieben, entstehen
sehr konkrete Prozessdarstellungen,
die explizit die Kooperation und Ko ordi -
nation zwischen den beteiligten Akteuren
betrachten. Darüber hinaus wird klar herausgearbeitet,
welche Arbeitsschritte auf
welche Art durch Informationssysteme
unterstützt werden. Die eGPM umfasst
Abb. 1: Kooperationsbild für einen Antragsprozess (Versicherung).
Stefan Hofer
(stefan.hofer@c1-wps.de)
hat seinen Schwerpunkt im Transformationsbüro
der C1 WPS: Er berät bei der Erhebung, Model -
lierung und Umgestaltung von Anwendungs land -
schaften und bei der exemplarischen Modellierung
von Geschäftsprozessen.
neben dem Kooperationsbild noch weitere
Modelltypen (siehe Kasten 1).
Fachbereichs- und
Workshop-Tauglichkeit
Wenn wir fachliche Abläufe modellieren
und beschreiben, sind wir darauf angewiesen,
dass fachliche Experten unsere Er -
gebnisse beurteilen und bewerten können.
Anderenfalls haben wir zwar Modelle, aber
keine Gewissheit, ob sie die betrachteten
Ist- oder Soll-Situationen richtig darstellen.
Die Kooperationsbilder der eGPM sind
genau in diesem Sinne „fachbereichstauglich“,
weil sie als Szenarien die Geschäfts -
prozesse in Form konkreter Geschichten
visuell und piktografisch präsentieren. Die
einzelnen Schritte können als natürlichsprachliche
Sätze gelesen werden (Beispiel:
„Der Sachbearbeiter erfasst den Vertrag
anhand des Scans im Verwaltungssystem“).
Beides führt dazu, dass die Modelle für
Mitarbeiter des Fachbereichs auch ohne
Kenntnis der Modellierungsmethode verständlich
und bewertbar sind.
In unserer Arbeit hat es sich bewährt, in
Workshops mit mehreren Beteiligten live zu
8 9

schwerpunkt
Das Kooperationsbild ist der zentrale
Modelltyp der eGPM. Modelle dieses
Typs können durch ebenfalls szenariobasierte
Arbeitsplatzbilder und IT-Inter -
aktionsbilder weiter verfeinert werden.
Um den Überblick über die Szenarien zu
bewahren, werden Modelle der Typen
„Anwendungsfall-Diagramm“ und „Pro -
zess landkarte” eingesetzt.
In den Szenarien gesammelte Konzepte
(„das Buchhaltungssystem“, „der Ver -
trag“, „der Filialleiter“) können in eigenen
Modelltypen gesammelt und strukturiert
werden:
■ Die IT-Landschaft stellt Anwendun -
gen und Daten dar.
■ Das Begriffsmodell stellt Gegenstän -
de und Fachbegriffe dar.
■ Das Arbeitsumgebungsmodell stellt
Rollen und Organisations ein heiten
dar.
Die Verbindungen zwischen Modellen
sind im Modellierungswerkzeug als
Referenzen implementiert, sodass zwischen
Modellen navigiert werden kann.
Kasten 1: Modelltypen der eGPM.
modellieren: Von einem Beamer an die
Wand geworfen, entsteht das Modell
Schritt für Schritt und für alle sichtbar. Die
Teilnehmer greifen korrigierend in die
Modellierung ein, wenn sie ihre Aussagen
im Modell nicht richtig umgesetzt sehen,
und stimmen sich in dem Workshop auch
wechselseitig über ihre Sichten auf den
Prozess ab. Am Ende eines solchen Work -
shops stehen darum Modelle, die bereits
eine eingehende Qualitätssicherung erfahren
haben. Die Beteiligten nehmen aber
nicht nur die Modelle als Ergebnis mit. Das
gemeinschaftliche Modellieren ist für sie
ein Verständnisprozess, in dem sie die
Arbeitswelt von Kollegen und anderen
Abteilungen anschaulich vorgeführt be -
kommen.
Integration mit dem
Use-Case-Ansatz
Die eGPM wird von uns an zwei Punkten
an die Use-Case-Methode (in der Lesart
von [Coc00]) angebunden:
1. Übersicht: Am Beginn einer Mod el -
lierung mit eGPM steht die Auswahl der
Prozesse, die in Workshops zu untersuchen
sind. Hierfür erarbeiten wir gemeinsam
mit den Vertretern der beteiligten
Fachbereiche eine Übersicht über die
Geschäftsprozesse in Form von Business-
Use-Cases. Für das Thema „Kredit“ in
einer Bank können beispielsweise die
Business-Use-Cases „An tragsbearbei -
tung“, „Kreditablö sung“ und „An -
schluss finanzierung“ relevant sein und
dann noch nach Kredit- und Sicher -
heitsarten (z. B. „Konsu menten kredit
ohne Sicherheit“, „Baufinan zierung mit
Grundschuld“) weiter differenziert werden.
Zur Übersichts dar stellung nutzen
wir Use-Case-Dia gram me auf Flip-
Charts oder im Model lierungswerkzeug.
Aus den Busi ness-Use-Cases wählen wir
dann diejenigen aus, die wir vertieft mit
Hilfe von Ko operationsbildern modellieren
wollen.
2. Variationen: Bei der Erarbeitung der
Kooperationsbilder halten wir uns an
ein Hauptszenario und notieren potenzielle
Verzweigungen. Wir entscheiden
in einem zweiten Schritt, ob sich aus
diesen Verzweigungen aus unserer Sicht
der Bedarf ableitet, weitere Ko opera -
tionsbilder zu modellieren, oder ob es
sich um kleinere Variationen des bestehenden
Kooperationsbilds handelt.
Den zweiten Fall dokumentieren wir,
indem wir die Use-Case-Technik einsetzen:
Wir integrieren die grafische Dar -
stellung des Kooperationsbilds zur ausführlichen
Dokumentation in ein
Text dokument und ergänzen diese
Darstellung um eine Use-Case-Tabelle,
die das behandelte Szenario als Main
Successs Scenario beschreibt und
Variationen als Extensions darstellt. So
können die beispielhaften eGPM-
Modelle mit Hilfe der Use-Case-
Technik um Variationen bzw. Verzwei -
gun gen erweitert werden.
Die Anbindung der eGPM an Use-Cases ist
aus mehreren Gründen sehr sinnvoll:
■ Mit der Re-Interpretation der Koopera -
tionsbilder als Business-Use-Cases er -
■
■
■
gibt sich eine Brücke – zu einer sehr
bekannten – und von vielen Menschen
beherrschten Methode.
Der Export der Kooperationsbilder in
ein Textdokument und die Ergänzung
durch Use-Case-Tabellen ergeben ein
Format, das es ermöglicht, die Prozesse
ausführlicher darzustellen und flexibel
in andere schriftliche Konzeptionen
einzubinden.
Die Use-Case-Technik bietet das notwendige
Instrumentarium, um die einzelnen
„Geschichten“, die die Koopera -
tionsbilder erzählen, systematisch um
Variationen und Fallunterscheidungen
zu ergänzen.
Die Kooperationsbilder können, aufgefasst
als Business-Use-Cases, um andere,
kleinerteilige Use-Cases ergänzt
werden, die z. B. auf die Interaktion
zwischen Anwender und System fokussieren.
eGPM im Vergleich zu anderen
Ansätzen
Verbreitete Notationen, wie die Business
Process Model and Notation (BPMN) und
die Ereignisgesteuerte Prozesskette (EPK)
(vgl. [Wes07]), wurden durch die Infor -
matik geprägt. Im Gegensatz zu eGPM liegt
bei diesen Ansätzen der Fokus nicht auf der
Kooperation und Koordination von Ak -
teuren. Mit ihren Ausdrucksmitteln, wie
z. B. Fallunterscheidungen, können Ge -
schäfts prozesse als Algorithmen beschrieben
werden. Unserer Erfahrung nach verleitet
das viele Modellierer zu einer
algo rithmischen Denkweise. Das Resultat
sind abstrakte Modelle, in denen Voll -
ständigkeit (also das Abdecken aller möglichen
Prozessverläufe) im Vordergrund
steht –, selbst wenn die Automatisierung
der modellierten Prozesse gar nicht angestrebt
wird. Derartige Modelle sind in ihren
Verästelungen potenziell sehr komplex:
Fachbereichsmitarbeiter, die hierfür nicht
speziell ausgebildet sind, können sie in der
Regel nur schwer validieren und der einzelne,
beispielhafte, konkret besprochene und
bestätigte Verlauf verschwindet dahinter.
Für die szenariobasierten Modelltypen
der eGPM haben wir bewusst auf die
Möglichkeit verzichtet, Fallunterscheidun -
gen modellieren zu können. Der Mo -
dellierer kann sich so auf die fachliche
Aussagekraft des Modells konzentrieren,
statt auf eine algorithmisch korrekte
Prozessbeschreibung achten zu müssen. Es
werden beispielhafte, konkrete Fälle
6/2012

schwerpunkt
Abb. 2: Bearbeiten eines Kooperationsbilds in ADONIS.
beschrieben, die durch Mitarbeiter aus den
Fachabteilungen effektiv beurteilt werden
können. Als Konsequenz daraus können
die Modelle der eGPM allerdings weder
ausgeführt noch automatisiert in algorithmische
Notationen überführt werden.
Trotzdem schließen sich die Automati -
sierung von Geschäftsprozessen und eGPM
nicht aus: Szenariobasierte Modelle eignen
sich hervorragend als fachlich validierte
Grundlage für die Erstellung der ausführbaren
Modelle. Für die manuelle Überführung
in BPMN gibt es praxisbewährte
Transformationsregeln.
Die Abgrenzung zu Use-Cases ist naturgemäß
weniger hart, da es sich in beiden
Fällen um szenariobasierte Methoden handelt.
Ein wichtiger Mehrwert der eGPM
besteht darin, dass sie eine piktografische
Darstellung für kooperative Arbeits -
prozesse beinhaltet, die sehr gut für Mo -
dellierungsworkshops mit Gruppen geeignet
ist (Use-Cases hingegen besitzen keine
eigene grafische Darstellung für Prozesse).
Ein weiterer Vorteil von eGPM ist ihr
fokussiertes Vokabular: Die Konzentration
auf Akteure, Gegenstände und Aktivitäten
als primäre Modellierungselemente zwingt
die Modellierenden dazu, Ross und Reiter
zu nennen, Kooperation und Koordination
zu betrachten und aktiv Begriffsarbeit zu
leisten. Zusammengefasst besitzt die eGPM
gegenüber anderen Ansätzen also folgende
Alleinstellungsmerkmale:
■ Eine piktografische, für Modellierungs -
workshops mit Gruppen gut geeignete
Darstellung.
■ Die Betrachtung beispielhafter Prozess -
verläufe.
■ Die explizite Berücksichtigung von
Kooperation und Koordination (auch
informell).
■ Nur wenige verschiedene Modellele -
mente.
■ Die Fokussierung auf Akteure, Gegen -
stände und Aktivitäten, was die Be -
griffs arbeit fördert.
Ist- und Soll-Prozesse
Werden Prozesse mit eGPM in ihrem Ist-
Zustand aufgenommen, macht die
Orientierung an der tatsächlichen Arbeit in
den Fachabteilungen die Defizite und
Verbesserungspotenziale sichtbar. Davon
ausgehend können in einem zweiten Schritt
sehr gut Soll-Prozesse entworfen werden,
die die Vision einer geänderten IT-Un -
terstützung und/oder veränderten IT-Land -
schaft transportieren.
Das Modellierungswerkzeug
Zunächst als Methode auf der Basis von
Flipcharts, Wandtafeln und Powerpoint
entstanden, wurde eGPM 2004 als so
genannte Anwendungsbibliothek auf der
kommerziellen Modellierungsplattform
„ADONIS“ des Herstellers BOC implementiert
worden (siehe Abbildung 2). Auf
dieser Plattform bietet die BOC unterschiedliche
Modellierungsmethoden an,
unter anderem eine klassische Geschäfts -
prozess-Modellierungsmethode, BPMN,
UML und das für das Architekturmanage -
ment maßgeschneiderte Werkzeug
„ADOit“. Mit der Anwendungsbibliothek
für eGPM wird aus der Plattform ein
eGPM-Modellierungswerkzeug.
Das Modellierungswerkzeug ist für
Windows-Systeme verfügbar. Es ist repositorybasiert
und erlaubt sowohl den Stand-
Alone-Betrieb als auch die Nutzung eines
gemeinsamen Repositorys.
Der Aufbau des Werkzeugs beinhaltet
den Repository-Explorer auf der linken
Seite, die Modellierungsfläche auf der rechten
Seite (sie füllt meist den Großteil des
Fensters aus), sowie die Model lierungs -
leiste mit den zur Verfügung stehenden
Modellelementen als vertikalem Teiler.
Links unten befindet sich der so genann-
10 11

schwerpunkt
Die Open Models Initiative (OMI) der Universität Wien ist eine Community für
Entwickler von Modellierungsmethoden. Ihr Motto lautet: „Models for everyone“. Ihr
Ziel ist es, Modelle und Referenzmodelle in verschiedenen Modellierungssprachen im
Sinne des Open-Source-Gedankens frei zur Verfügung zu stellen. Zu diesem Zweck werden
auch kostenfreie Modellierungswerkzeuge bereitgestellt.
Als technische Grundlage für die kostenfreien Modellierungswerkzeuge bietet OMI den
Methodenentwicklern eine Modellierungsplattform auf Basis des kommerziellen
Werkzeugs „ADONIS“ der BOC Group an. Die auf openmodels.at veröffentlichten
Modellierungswerkzeuge sind frei verwendbar – auch für den kommerziellen Einsatz.
Kasten 2: Die „Open Models Initiative“ (OMI).
te Navigator, der das gesamte Modell in der
Übersicht zeigt und der es erlaubt, schnell
in die gewünschten Ausschnitte hinein zu
springen.
Zur Modellierung wird ein Modell -
element auf der Modellierungsleiste ausgewählt
und auf der Modellierungsfläche
platziert. Akteure und Gegenstände sind
dabei selbständig positionierbare Ele mente,
während die Aktivitäten in Form von
Pfeilen als Verbinder zwischen derartigen
Elementen platziert werden.
Die Firma BOC unterstützt gemeinsam
mit der Firma C1 WPS als Metho den -
entwickler die „Open Models Initiative“
(siehe Kasten 2). Im Rahmen dieser Ini -
tiative wurde im Dezember 2011 das
eGPM-Modellierungswerkzeug zur freien
Verwendung bereitgestellt, auch für kommerzielle
Zwecke. Dabei handelt es sich um
die Stand-Alone-Version mit den wichtigs -
ten Modelltypen. Mit diesem Funk tions -
umfang ist das Werkzeug im professionellen
Umfeld einsetzbar.
Einsatz bei agiler
Vorgehensweise
Die eGPM ist eine Modellierungsmethode,
die sich gut mit agilem Vorgehen in der
Softwareentwicklung verbinden lässt.
Dabei ist zu berücksichtigen, dass agile
Entwicklungsprozesse es anstreben, die
Anforderungsermittlung schlank zu halten,
und dafür die direkte Kommunikation,
Rückkopplung und das Reagieren auf
wech selnde Anforderungen betonen.
Insofern mag es sein, dass manches agile
Projekt tatsächlich mit den schon sprichwörtlichen
Karteikarten auskommt. Wenn
es jedoch sinnvoll erscheint, sich intensiv in
Geschäftsprozesse einzuarbeiten und Pro -
zess modellierung zu betreiben, ist eGPM
die Methode, die mit ihrer Work shop-
Eignung und den gemeinsam erarbeiteten,
prägnanten und beispielhaften Pro zessen
eine ideale Keimzelle für eine intensive
Kommunikation zwischen Ent wicklern und
Fachabteilung darstellt. Dazu ist die
Modellierung leichtgewichtig und von
Iteration zu Iteration können in schlanker
Weise Prozesse korrigiert oder neu modelliert
werden. Nach unserer Erfah rung,
unter anderem im Einsatzbeispiel
„Grundlage für Neuentwicklung“ (siehe
den folgenden Abschnitt), bietet eine kleine
Auswahl gemeinsam modellierter eGPM-
Kooperationsbilder wichtige Kristallisa -
tionspunkte für spätere Diskussionen und
Klärungen, denn fruchtbar diskutiert wird
eben meist anhand von Beispielen.
Einsatzbeispiele
aus der Praxis
Die eGPM wurde ursprünglich zur Unter -
stützung der Anforderungsanalyse für die
objektorientierte Softwareentwicklung entwickelt.
Über die Jahre hat sie sich in vielen
Einsatzkontexten bewährt, von denen wir
einige im Folgenden kurz vorstellen.
Auswahl von Standardsoftware
(Versicherungsvertrieb)
Im Rahmen einer Ausschreibung für ein
CRM-System beschreibt ein Versicherungs -
vertrieb mit Hilfe von Kooperationsbildern
beispielhaft die wichtigsten Prozesse, die
die zu beschaffende Standardsoftware
unter stützen soll. Die Kooperationsbilder
werden, gemeinsam mit den anderen Aus -
schreibungsunterlagen, mehreren Anbie -
tern zur Verfügung gestellt.
In Auswahl-Workshops demonstrieren
die Anbieter, wie sich die modellierten
Prozesse mit ihrer Software umsetzen lassen
und wo die Software vom Wunsch des
Kunden abweicht. Besonderer Nutzen:
■ Die gute Verständlichkeit der Modelle
versetzt die Anbieter in die Lage, bei
Abweichungen von den Vorgaben alternative
Umsetzungsvorschläge zu
machen, mit denen unter Umständen
das gleiche Ziel erreicht werden kann
wie in den vom Kunden zur Verfügung
gestellten Prozessen.
■ Die Organisation erkennt, wie die zu -
künftigen Arbeitsabläufe aussehen
würden. Gegebenenfalls vorhandener
Anpassungsbedarf kann konkret diskutiert
werden.
Grundlage für Neuentwicklung
(Autovermietung)
Ein Autovermietungsunternehmen steigt
ins Leasinggeschäft ein und erarbeitet die
Geschäftsprozesse für den neuen Ge -
schäfts bereich mit Hilfe von eGPM. Die
entstehenden Kooperationsbilder sind die
Grundlage für die die Neuentwicklung
einer Leasing-Software. Die modellierten
IT-gestützten Gegenstände (z. B. „Reser -
vierung“, „Angebotsliste“, „Angebot“) stehen
Pate für wesentlich fachliche Konzepte
in der neuen Software (zum Teil bis zur
Granularität von Klassen, meist aber für
größere Zusammenhänge). Die identifizierten
Arbeitsplätze (z. B. „Akquisiteur“,
„After Sales Agent“) und die dort jeweils
erkennbaren Aufgaben und Abläufe bilden
die Grundlage für die funktionale Parti -
tionierung und ergonomische Gestaltung
der Software. Besonderer Nutzen:
■
■
■
Die zukünftigen Akteure werden bei
der Gestaltung ihrer Prozesse fruchtbar
einbezogen und bringen viele gute
Ideen ein.
Der zu unterstützende Arbeitskontext
wird in Form der Arbeitsplätze und der
verwendeten Gegenstände in den
Modellen so greifbar, dass eine gute
Grundlage für die Gestaltung der
Software gegeben ist.
Im Rahmen von Softwareentwicklung
dokumentiert eGPM auch die Gründe
für die konkrete Gestaltung der Soft -
ware („Design Rationale“, vgl. [Bre06]).
6/2012

IT-Landschaften
Der jüngste Modelltyp der eGPM zeigt,
dass sich trotz des Namens der Methode
nicht nur Prozesse damit darstellen lassen.
Er gehört zu den Konzept-Modelltypen
(siehe Kasten 1) und bietet damit eine statische
Architektursicht auf IT-Systeme, die in
den Prozessen verwendet werden. Das
Modellierungswerkzeug bildet diese
Beziehung über einen Referenzmechanis -
mus ab. Dadurch kann zum Beispiel ausgewertet
werden, welche Kooperationsbilder
die Verwendung eines bestimmten IT-
Systems zeigen.
IT-Landschaften dokumentieren die
fach lichen Verantwortungen und Abhän -
gig keiten eines IT-Systems, indem sie ihm
die von ihm verwalteten und ausgetauschten
Datenobjekte zuordnen. Um die verschwerpunkt
Abb. 3: IT-Landschaft für eine Versicherung.
Einführung neuer Prozesse
(Banksoftware-Hersteller)
Ein Hersteller von Banksoftware hat ein
neues Banksystem fertiggestellt und steht
vor der Aufgabe, seine Kunden (die Ban -
ken) auf das neue System umzustellen. Mit
der eGPM modelliert er zunächst die bankfachlichen
Kernprozesse, wie sie mit dem
Vorgängersystem durchgeführt wurden.
Anschließend modelliert er mit den Pilot -
anwendern und Produktmanagern für das
System die Kernprozesse, wie sie mit dem
neuen System umgesetzt werden sollten.
Die wesentlichen Unterschiede werden analysiert.
Besonderer Nutzen:
■ Aus den Kernprozessen für das neue
System generiert das Unternehmen eine
HTML-basierte Prozessreferenz für die
Banken.
■ Die herausgearbeiteten wichtigen Ver -
än derungen, die sich aus dem System -
wechsel ergeben, werden den Bank -
mitarbeitern in standardisierten
Schu lungen vermittelt und mit Hilfe der
eGPM-Darstellung in den richtigen
Kontext gesetzt.
Weiterentwicklung einer IT-Landschaft
(Autoteile-Handel)
Da die Mitarbeiter eines Unternehmens mit
der IT-Unterstützung ihrer Arbeit unzufrieden
sind, veranlasst die Unterneh mens -
führung eine Aufnahme und Bewertung der
IT-Landschaft. In Workshops analysieren
Vertreter aus Fachabteilungen und IT mit
Hilfe von Kooperationsbildern, welche
Anwendungen wie von ihren Benutzern
verwendet werden. Die gesammelten Infor -
mationen über die Anwendungen werden
in einem Modell vom Typ IT-Landschaft
(siehe nächster Abschnitt) konsolidiert und
aus IT-Sicht ergänzt. Besonderer Nutzen:
■ Mit Hilfe des Modells können
Management, Fachabteilungen und IT
über die IT-Landschaft diskutieren und
ihre Weiterentwicklung planen: Welche
fachliche Verantwortlichkeit hat ein
System? Welche Probleme und Risiken
gibt es? Kann es isoliert betrachtet und
geändert werden oder hängt es von
anderen ab? Welche Abteilungen und
Prozesse wären von einer Änderung
betroffen?
12 13

schwerpunkt
schiedenen Blick winkel und Verwendungs -
zwecke der Systeme auszudrücken, können
sie mit Hilfe von Frontends („Terminal -
emulation“ in Abbildung 3) und durch
Verschach te lung („Dokumentarchiv“ in
Abbildung 3) weiter strukturiert werden.
Zwar kann man die IT-Landschaften der
eGPM auch für technisch orientierte
Darstellungen verwenden, doch bieten
andere Notationen dafür reichhaltigere
Ausdrucksmittel. Orientiert man sich hingegen
an den fachlichen Zusammen -
hängen, erhält man eine Darstellung, die
für Management, Fachabteilung und IT
gleichermaßen nachvollziehbar ist und
über die gleichberechtigt (statt technikzentriert)
kommuniziert werden kann. Die IT-
Landschaft (siehe Abbildung 3) ist auf folgende
Aspekte fokussiert:
■ Welche Systeme verwalten welche
Geschäfts-/Datenobjekte?
■ Welches System ist führendes System
für welche Geschäfts-/Datenobjekte?
■ Welche Systeme tauschen mit welchen
anderen Systemen welche Geschäfts-/
Datenobjekte aus? Erfolgt der Aus -
tausch synchron oder asynchron?
Welches System initiiert den Aus -
tausch?
■ Über welche Frontends (Benutzerober -
flächen) werden welche Systeme von
ihren Anwendern benutzt?
Durch die enge Integration mit den Ko -
operationsbildern können Verantwort -
lichkeiten und Abhängigkeiten zudem gut
aus fachlicher Sicht validiert werden.
Damit stellt die IT-Landschaft eine wertvolle
Ergänzung zu technisch motivierten
Modellen dar, die ihre Validierung z. B.
über die Auswertung von Schnittstellen zu -
griffen erfahren.
Fazit
In diesem Artikel haben wir eine kurze
Einführung in die exemplarische Geschäfts -
prozess-Modellierung mit der Vorstellung
praktischer Einsatzbeispiele der Methode
verbunden. Wir hoffen, damit das Interesse
an dieser etwas anderen Art der Prozess -
modellierung geweckt zu haben. Also dann:
Einfach das Modellierungswerkzeug unter
openmodels.at herunterladen, ausprobieren
und eigene Erfahrungen sammeln. ■
Literatur
[Bre06] H. Breitling, A. Kornstädt, J. Sauer,
Design Rationale in Exemplary Business
Process Modeling, in: A. Dutoit et al. (Hrsg.),
Rationale Management in Software Engi -
neering, Springer 2006
[Coc00] A. Cockburn, Writing Effective Use
Cases, Addison-Wesley 2000
[Kra96] A. Krabbel, S. Ratuski, I. Wetzel,
Requirements Analysis of Joint Tasks in Hos -
pitals, in: B. Dahlbom et al. (Hrsg.), IRIS 19
„The Future“, Proc. of the 19th Inf. Systems
Re search Seminar in Scandinavia, 1996
[Wes08] M. Weske, Business Process Manage -
ment, Springer 2007
[Zül04] H. Züllighoven, Object-Oriented
Cons truction Handbook, Morgan Kaufmann
2004
TOP-JOBS FÜR
SOFTWARE-INGENIEURE
Zufriedene Mitarbeitende
Virtualisation
Distributed
Platform Independent
Kanban
Klare Vision
Flache Hierarchie
CAN
CI
Agile Development
OO
Java EE
Silverlight
Embedded
ARM HP Quality Center
Kompetente Kollegen Maven
TFS
Mobile AppTDD
Embedded Linux
Testing
.NET
Scrum
OSGi
Clean Code
Quick Test
Android
Java
Coded UI
ATDD
Eclipse
Azure
C++
Multi-Core
Wir von bbv erachten aktuelle Methoden und Technologien als zentrale
Elemente unseres Erfolges und sehen unsere Mitarbeitenden als
unser grösstes Kapital. Einsatzbereitschaft und Eigenverantwortung
sind uns wichtig und herausfordernde Projekte, stetige Förderung und
konsequente Weiterbildung liegen uns am Herzen.
Bewerben Sie sich noch heute!
www.bbv.ch/karriere
Luzern · Zug · Bern · Zürich · München

schwerpunkt
mehr zum thema:
eclipse.org/modeling/emft/refactor/
die autoren
BESSER MODELLIEREN:
QUALITÄTSSICHERUNG VON
UML-MODELLEN
Der Artikel präsentiert einen Qualitätssicherungsprozess für Softwaremodelle, der Metriken,
Smells und Refactorings verwendet. Unterstützende Werkzeuge basieren auf dem „Eclipse
Modeling Framework“ (EMF) und können in Modellierungsumgebungen, wie z. B. „Papyrus“ oder
„IBM Rational Software Architect“, integriert werden. Neben einer groben Einführung in das
Refaktorisieren von Modellen liefert dieser Artikel zudem Hinweise auf weiterführende
Literatur.
Dr. Gabriele Taentzer
(taentzer@mathematik.uni-marburg.de)
ist Professorin für Softwaretechnik am
Fachbereich Mathematik und Informatik der
Philipps-Universität Marburg. In der Forschung
beschäftigt sie sich mit der modellgetriebenen
Softwareentwicklung, visuellen Sprachen und
Graftransformation.
In der modernen Softwareentwicklung
spielen Modelle eine wichtige Rolle. Ihre
Einsatzgebiete reichen von der System -
analyse über die Spezifikation von Archi -
tektur und Design bis hin zur Generierung
von Code. Für die Entwicklung qualitativ
hochwertiger Software ist es somit ratsam,
bereits die Qualität der involvierten
Modelle zu prüfen und diese gegebenenfalls
zu verbessern. Ursachen für eine eingeschränkte
Qualität von Modellen können
zum Beispiel Unerfahrenheit mit dem
Modellieren per se, mit der verwendeten
Modellierungssprache oder dem unterstützenden
Modellierungswerkzeug, aber auch
unerfüllte projektspezifische Richt linien
sein.
Eine standardisierte Modellierungs -
sprache für Softwaresysteme ist die Unified
Modeling Language (UML) (vgl. [OMG]),
deren Sichtenkonzept auf das Modell in
verschiedenen Diagrammen weitere
Probleme verursacht:
■
■
So können Sachverhalte redundant
modelliert werden, weil Modellierer
jeweils nur ihre Sicht auf das Ge samt -
modell haben.
Oder nicht benötigte Modellelemente
werden nur aus einem Diagramm
gelöscht und verbleiben somit als ungenutzte
Elemente im Modell.
In diesem Artikel 1 ) stellen wir eine Werk -
zeugumgebung vor, deren Komponenten
einen projektspezifischen Qualitäts siche -
rungs prozess für Softwaremodelle unterstützen.
Dieser Prozess basiert auf Metri -
ken, Smells und Refactorings als
1
) Diese Arbeit wurde teilweise von Siemens
Corporate Technology, München, gefördert.
Quali tätssicherungstechniken für Software -
modelle (vgl. [Are11]). Die Umgebung ist
flexibel bezüglich der Modellierungs -
sprache, der Auswahl vorhandener Techni -
ken sowie der konkret verwendeten
Spezifikationssprachen für Erweiterungen.
Die Werkzeuge sind in hohem Maße integriert:
Einerseits benutzen sie sich gegenseitig,
andererseits kann der Qualitäts -
sicherungsprozess komplett innerhalb einer
vorhandenen Modellierungsumgebung, wie
„Papyrus“ (vgl. [Ecl-a]) und „IBM
Rational Software Architect“ (vgl. [IBM]),
durchgeführt werden. Die Werkzeuge
basieren auf dem Eclipse Modeling
Framework (EMF) (vgl. [Stei08]) und werden
im Eclipse-Incubation-Projekt „EMF
Refactor“ (vgl. [Ecl-b]) angeboten.
Modellqualität
Im Gegensatz zur Softwarequalität gibt es
für die Qualität von Softwaremodellen keinen
offiziellen Standard. Eine Übersicht
über die in der Literatur betrachteten
Qualitätsaspekte findet man in einem
Artikel von Mohagheghi et. al. (vgl.
[Moh09]). Dort werden sechs primäre
Qualitätsaspekte identifiziert, die in
Forschungspapieren der Jahre 2000 bis
2007 hinsichtlich der Qualität von Soft -
waremodellen diskutiert wurden: die so
genannten 6C-Goals. Diese sind (in alphabetischer
Reihenfolge):
■ Changeability (Änderbarkeit): Ein
Modell ist gut änderbar, wenn Modi -
fikationen oder Verbesserungen in
einem Maße unterstützt werden, dass
das Modell schnell und kontinuierlich
weiterentwickelt werden kann.
■ Completeness (Vollständigkeit): Ein
Modell ist vollständig, wenn es zum
Thorsten Arendt
(arendt@mathematik.uni-Marburg.de)
ist wissenschaftlicher Mitarbeiter und Doktorand
am Fachbereich Mathematik und Informatik der
Philipps-Universität Marburg. Ein Schwerpunkt seiner
Arbeit ist die modellbasierte Softwareent -
wicklung, insbesondere die Qualitätssicherung von
Softwaremodellen und die Entwicklung geeigneter
Werkzeuge.
einen alle relevanten und notwendigen
Informationen enthält und zum anderen
entsprechend dem Model lierungs -
zweck ausreichend detailliert ist.
■ Comprehensibility (Verständlichkeit):
Ein Modell ist gut verständlich, wenn
es von den vorgesehenen Anwendern
gelesen und schnell interpretiert werden
kann (Anwender sind hier entweder
menschliche Benutzer oder verarbeitende
Werkzeuge).
■ Confinement (Angemessenheit): Ein
Sachverhalt wurde angemessen modelliert,
wenn das Modell mit dem Mo del -
lierungszweck und der Model lierungs -
domäne übereinstimmt. Diese
Defi ni tion schließt auch die Auswahl
der Modellierungssprache und der relevanten
Konzepte (z. B. Diagramme und
Elemente) auf der richtigen Abstrak -
tions ebene mit ein.
■ Consistency (Konsistenz): Ein Modell
ist konsistent, wenn es frei von Wi -
dersprüchen ist. Dazu zählt zum einen
die syntaktische Konsistenz bezüglich
14 15

schwerpunkt
Papyrus
Installieren Sie die aktuelle Version „Juno“ der „Eclipse Modeling Tools“ von der Seite
eclipse.org/downloads. Starten Sie Eclipse und installieren Sie die UML-Modellierungs -
umgebung Papyrus (Help > Install New Software… > Work with: Juno > Modeling > Papyrus
SDK Binaries > next > …) sowie das Werkzeug BIRT für die Erstellung von Berichten
(Help > Install New Software… > Work with: Juno > Bussiness… > BIRT Framework > next >
…). Laden Sie sich anschließend aus dem Download-Bereich der EMF-Refactor-Web-
Seite (eclipse.org/modeling/emft/refactor) das Archiv Juno.zip herunter, entpacken Sie dieses
in das plugins-Verzeichnis Ihrer Eclipse-Installation und starten Sie Eclipse neu. Ein Bei -
spielprojekt kann ebenfalls von der EMF-Refactor-Web-Seite heruntergeladen werden.
IBM RSA v7.5.5
Wenn Sie eine bereits installierte Version des IBM Rational Software Architect haben,
laden Sie sich aus dem Download-Bereich der EMF-Refactor-Web-Seite
(eclipse.org/modeling/emft/refactor) das Archiv RSA755.zip herunter, entpacken Sie dieses in
das plugins-Verzeichnis Ihrer RSA-Installation und starten Sie den RSA. Auch hier stellt
die Web-Seite von EMF Refactor ein Beispielprojekt zum Download bereit.
Kasten 1: Download und Installation der Werkzeuge, Techniken und Beispiele für
die Qualitätssicherung von UML-Modellen.
■
der verwendeten Modellierungssprache
und gegebenenfalls einzuhaltenden
Mo dellierungskonventionen, zum an -
deren aber auch die Konsistenz hinsichtlich
semantischer Widersprüche,
beispielsweise zu Modellen einer anderen
Abstraktionsebene.
Correctness (Korrektheit): Ein Modell
ist korrekt, wenn es die richtigen Ele -
mente und Beziehungen zwischen diesen
enthält und richtige Aussagen über
die zu modellierende Domäne trifft.
Wie bereits erwähnt, basieren diese De -
finitionen (oder besser: Beschreibungen)
nicht auf einem offiziell anerkannten
Standard. Sie stellen jedoch den aktuellen
Stand der Technik dar und sollten somit bei
der Betrachtung von Modellqualität immer
mit berücksichtigt werden. Anhand des
Domänenmodells eines KFZ-Verleihs (siehe
Abbildung 1) wollen wir die beschriebenen
Qualitätsaspekte im Folgenden andiskutieren.
Der Verleih (Company) hat eine hierarchisch
organisierte Mitarbeiter struktur
(Employee, Supervisor) sowie eine Menge
von Kunden (Customer) mit Adres sen und
Bankverbindungen. Weiterhin bietet das
Unternehmen einen Dienst für den Verleih
seiner Kraftfahrzeuge an (VehicleRental,
Vehicle).
Obwohl das Modell konsistent zur
UML-Sprachspezifikation ist (Qualitäts -
aspekt „Consistency“), weist es bezüglich
anderer Aspekte die folgenden Mängel auf:
■
■
Die in den Klassen Car, Truck und
Motorbike vorkommenden redundanten
Attribute power und manufacturer beeinflussen
die Änderbarkeit des Modells,
da z. B. bei der Einführung einer neuen
Klasse Manufacturer das Modell an mehreren
statt an einer Stelle angepasst
werden muss („Change ability“).
Die abstrakte Klasse Supervisor ist eine
Unterklasse der konkreten Klasse
Employee. Hier wird das Prinzip der
Abstraktion unzweckmäßig verwendet,
da z. B. kein Objekt der Klasse
Abb. 1: UML-Klassenmodell eines KFZ-Verleihs.
6/2012

schwerpunkt
■
■
Supervisor in einem Sequenzdiagramm
modelliert werden kann, obwohl ein
Vorgesetzter auch ein Mitarbeiter ist
(„Confinement“). Andererseits könnte
diese Klasse aber auch fälschlicherweise
als abstrakt gekennzeichnet sein („Cor-
rec tness“).
Eine unzweckmäßige Verwendung des
Abstraktionsprinzips kommt auch bei
der Klasse Service vor, die von lediglich
einer einzigen konkreten Klasse
(VehicleRental) beerbt wird („Confi ne -
ment“). Jedoch könnten die angebotenen
Dienste auch noch unvollständig
modelliert sein („Completeness“).
Das Modell enthält ein Interface
IService (siehe Modellbaum in Abbil -
dung 1), das in keinem Diagramm vorkommt
und möglicherweise das Er geb -
nis eines fehlerhaften Löschens ist
(siehe oben). Solche ungenutzten Ele -
mente beeinflussen unter anderem die
Verständlichkeit des Modells („Com-
pre hensibility“).
Im Folgenden beschreiben wir, wie die
Qualität des Beispielmodells analysiert und
durch Umstrukturierung gezielt verbessert
werden kann.
Modellmetriken
Softwaremetriken sind verbreitete Hilfsmit -
tel, um bestimmte (Qualitäts-)Eigen -
schaften zu messen. Somit kann es in einem
Modell-Review hilfreich sein, einen Bericht
über projektspezifische Modellmetriken zu
erstellen und zu analysieren. In unserer
Umgebung wird eine Metrikenberechnung
aus dem Kontextmenü eines Modell -
elements gestartet (EMF Metrics > Calculate
Configured UML Metrics). Ebenso können die
konfigurierten Metriken lediglich auf dem
selektierten Element oder auch transitiv auf
allen enthaltenen Elementen (z. B. auf
Opera tionen einer selektierten Klasse)
berechnet werden. Die Metrikwerte werden
in einer eigenen Sicht präsentiert und
können anschließend in Formaten wie
HTML, PDF oder PPT exportiert werden.
Die Werkzeugumgebung unterstützt rudimentäre
Designs, wie Listen und verschiedene
Diagrammarten. Weitere Designs
können leicht importiert werden.
Abbildung 2 zeigt den Export der berechneten
Metriken NATM (Gesamtanzahl der
Attribute in Klassen des Modells) und
NOM (Gesamtanzahl der Operationen in
Klassen des Modells) auf unserem Beispiel -
modell in Form eines Kuchendiagramms.
Abb. 2: Export einer
Metrikenberechnung.
Das unausgeglichene Verhältnis zwischen
Attributen (40) und Operationen (4) kann
unterschiedlich interpretiert werden:
Einerseits könnte es ein Hinweis darauf
sein, dass das objektorientierte Prinzip der
Operationen nicht genügend genutzt wird
(„Confinement“), andererseits könnte es
auf eine unvollständige Modellierung hinweisen
(„Completeness“).
Smells in Softwaremodellen
Eine weitere Technik zur Qualitäts -
sicherung von Softwaremodellen sind
Smells in Softwaremodellen. Dies sind
Stellen im Modell, die hinsichtlich be -
stimmter Qualitätskriterien verdächtig
sind. Sie sollten genauer betrachtet und
eventuell verbessert werden. Viele Smells in
Softwaremodellen für UML-Klassen -
modelle wurden aus entsprechenden Smells
für objektorientierte Programme abgeleitet
(vgl. [Fow99]).
Smells in Softwaremodellen können
metrik- oder musterbasiert sein. Ein
Abb. 3: Gefundene Smells.
Beispiel für einen metrikbasierten Smell ist
der oben diskutierte Fall, in dem deutlich
mehr Attribute als Operationen im Modell
vorhanden sind (Too Many Knowers).
Andere Smells in Softwaremodellen werden
als Muster auf der abstrakten Syntax der
Modellierungssprache definiert, die dann
in konkreten Modellen gesucht werden.
Ein Beispiel für einen solchen Smell ist Equal
Attributes in Sibling Classes, der nach Klassen
mit derselben Oberklasse sucht, die zusätzlich
alle ein Attribut mit gleichen Eigen -
schaften (Name, Typ und Multiplizität)
besitzen.
In unserer Werkzeugumgebung wird eine
Smell-Analyse aus dem Kontextmenü eines
Modellelements gestartet (EMF Smell >
Calculate Configured UML Smells). Ein Aufruf
auf dem Wurzelelement vom Typ Model
sucht nach allen konfigurierten Smells im
gesamten Modell. Die gefundenen Smells
werden in einer eigenen Sicht präsentiert
und können anschließend exportiert werden.
In unserem Beispielmodell befinden sich
insgesamt zwölf Smells (siehe auch Abbi l -
dung 3):
■
■
■
Der Smell Equal Attributes in Sibling
Classes ist insgesamt sechsmal vorhanden
(die beiden Attribute power und
manufacturer jeweils in den Klassen Car,
Truck und Motorbike).
Ebenso werden die anderen beschriebenen
Situationen gefunden (Smells
Speculative Generality, Unused Interface
und Concrete Superclass).
Der Smell Long Parameter List, der nach
Operationen mit einer hohen Anzahl
von Eingabeparametern sucht, tritt
16 17

schwerpunkt
dreimal auf. Das Beispiel berücksichtigt
hier eine projektspezifische Grenze von
mindestens vier Eingabeparametern.
Wählt man ein konkretes Vorkommen eines
Smells aus (z. B. {Motorbike, power} in Ab -
bildung 3), werden die entsprechenden Mo -
dellelemente im Modellbaum sowie in offenen
grafischen Diagrammeditoren markiert.
Abb. 4: Anwendbare Refactorings.
Refactorings für
Softwaremodelle
Eine bekannte Technik für die Quali täts -
sicherung von Programmen durch Um -
strukturierung, ohne die Semantik zu
ändern, ist Refactoring (vgl. [Fow99]).
Diese Technik kann auch zur Qualitäts -
sicherung von Softwaremodellen angewendet
werden und wird vom Eclipse-Plug-In
„EMF Refactor“ (vgl. [Ecl-b]) unterstützt.
Bei der Durchführung eines Refactorings
benutzt EMF Refactor eine fest vorgegebene
Struktur: Nach einer ersten Überprüfung
von Vorbedingungen auf dem aktuellen
Kontext (Initial Check) folgen eine zweite
Überprüfung unter Einbeziehung der eingegebenen
Parameterwerte (Final Check) und
schließlich die Durchführung der konkreten
Änderungen (Model Change).
Refactorings können sowohl direkt auf
den Modellelementen als auch aus der
Ergebnissicht der Smell-Suche (z B.
{Motorbike, power} > Refactoring Analysis)
aufgerufen werden. Im zweiten Fall schlägt
EMF Refactor alle Refactorings vor, die in
dem konkreten Kontext anwendbar sind.
Beispielsweise werden für die Eliminierung
des Smells Equal Attributes in Sibling Classes
auf den Elementen {Motorbike, power} neun
Refactorings vorgeschlagen, die auf einem
dieser beiden Elemente durchgeführt werden
können (siehe Abbildung 4). Da jedoch
auch anwendbare Refactorings vorgeschlagen
werden, die nicht unmittelbar dazu beitragen,
den Smell zu entfernen (wie z. B.
Rename Class), bietet EMF Refactor eine
manuelle Konfiguration der geeigneten
Model Refactorings an.
In unserem Beispiel wenden wir das
Refactoring Pull Up Attribute auf das
Attribut power an. Da die UML Mehr -
fachvererbung erlaubt, muss als Parameter
die Oberklasse angegeben werden, in die
das Attribut verschoben werden soll. Der
Eingabedialog bietet zudem die Mög -
lichkeit, Voransichten der Änderungen am
Modell sowie der vorkommenden Smells
vor und nach dem Refactoring anzuzeigen.
Sind bestimmte Vorbedingungen nicht
erfüllt, werden detaillierte Fehlermel dun -
gen angezeigt. Weiterhin stehen die
üblichen Funktionalitäten undo und redo
zur Verfügung. Abbildung 5 zeigt einen
Ausschnitt unseres Beispielmodells nach
Durchführung von Pull Up Attribute auf den
Attributen power und manufacturer.
Projektspezifische
Anpassungen
Da Softwaremodelle für verschiedene
Zwecke und in unterschiedlichen Domänen
(z. B. Web-Anwendungen und eingebettete
Systeme) eingesetzt werden, variieren auch
die Bedeutung einzelner Qualitätsaspekte
und somit die Auswahl spezifischer Si -
cherungstechniken. Unsere Werkzeug -
umge bung bietet die Möglichkeit, die vorhandenen
Techniken projektspezifisch zu
konfigurieren (z. B. Project > Properties >
EMF Smell). In der Standardeinstellung sind
alle vorhandenen Techniken aktiviert. Zwei
weitere projektspezifische Einstellungen
wurden bereits erwähnt: die Einstellung der
Grenzen bei metrikbasierten Smells und die
Konfiguration der für die Eliminierung von
Smells in Softwaremodellen geeigneten
Refactorings.
Neben der Anwendung von vorhandenen
Techniken bietet die Werkzeugumgebung
auch die Möglichkeit, neue Metriken,
Smells und Refactorings zu integrieren
(z. B. über File > New > Other… > EMF Smell
> Model-Smell). Dazu besitzt jedes Werk -
zeug einen Codegenerator, der nach der
Eingabe spezifischer Informationen (z. B.
den Namen des Smells) Code generiert, der
dann vom Anwendungsmodul verwendet
werden kann. Vorhandene Techniken können
kombiniert werden: Neue Metriken
oder metrikbasierte Smells benutzen vorhandene
Metriken, neue Refactorings kombinieren
vorhandene Refactorings. Neue
Techniken können in Java, der Object
Constraint Language (OCL) oder der
Modelltransformationssprache Henshin
(vgl. [Are10]) spezifiziert und weitere
Spezi fikationssprachen über entsprechende
Adapter integriert werden.
Implementierte Techniken
für UML
Die Werkzeuge unterstützen zurzeit über
100 Metriken sowie jeweils 30 Smells und
Refactorings für UML-Modelle. Sie
join the
experts
of enterprise infrastructure
Software-Entwickler / Architekt (m/w)
Arbeiten Sie gerne selbstständig, motiviert und im Team? Haben Sie gesunden Ehrgeiz und Lust Verantwortung
zu übernehmen? Wir bieten Ihnen erstklassigen Wissensaustausch, ein tolles Umfeld, spannende Projekte in den
unterschiedlichsten Branchen und Bereichen sowie herausfordernde Produktentwicklung.
Wenn Sie ihr Know-how gerne auch als Trainer oder Coach weitergeben möchten, Sie über Berufserfahrung
mit verteilten Systemen verfügen und Ihnen Komponenten- und Objektorientierung im .NET- oder JEE-
Umfeld vertraut sind, dann lernen Sie uns doch kennen. Wir freuen uns auf Ihre Bewerbung!
Software GmbH
Henkestraße 91, 91052 Erlangen
Telefon: 09131/ 89 03-0
Telefax: 09131/ 89 03-55
Internet: www.mathema.de
E-Mail: info@mathema.de

schwerpunkt
Abb. 5: Teil des verbesserten UML-Klassenmodells.
ermöglichen einen flexiblen Einsatz zur
Quali tätssicherung verschiedenartiger
UML-Modelle. Viele Smells und
Refactorings für Klassendiagramme orientieren
sich an den entsprechenden Pendants
für Klassen struk turen auf Programmier -
ebene, wie in [Fow99] beschrieben. Weitere
Techniken können mit Hilfe der erwähnten
Spezifi kationssprachen leicht ergänzt werden.
Neben den bereits erwähnten Metriken
NATM und NOM werden alle gängigen
objektorientierten Metriken für UML-
Modelle unterstützt, etwa Metriken hinsichtlich
bestimmter Eigenschaften über
Vererbung (z. B. MaxDIT – Maximale Tiefe
aller Vererbungshierarchien im Klassen -
modell) oder Kopplung (z. B. Ce – Efferent
Coupling/ausgehende Abhängigkeiten eines
Pakets und Ca – Afferent Coupling/eingehende
Abhängigkeiten eines Pakets).
Weiterhin können die Metriken auf verschiedenen
Modellelement-Typen berechnet
werden (Modell, Paket, Klasse usw.).
Weitere implementierte Smells und Refac -
torings für UML-Modelle neben den in
unserem Beispiel diskutierten sind:
■
■
Multiple Definition of Classes with
Equal Names: Dieser musterbasierte
Smell identifiziert Klassen in unterschiedlichen
Paketen, die den gleichen
Namen besitzen.
Primitive Obsession: Dieser metrikbasierte
Smell wurde in zwei unterschiedlichen
Varianten implementiert. Zum
einen tritt dieser Smell auf, wenn die
Anzahl der konstanten Attribute einer
Klasse einen spezifischen Wert überschreitet,
und zum anderen, wenn die
Anzahl der Attribute einer Klasse mit
primitivem Datentyp (Integer, String)
über dem konfigurierten Schwellenwert
liegt.
■
■
Introduce Parameter Object: Dieses
Refactoring erstellt – ausgehend von
einer Liste von Parametern einer Opera -
tion – eine neue Klasse, legt für jeden
dieser Parameter ein entsprechendes
Attribut in der Klasse an und ersetzt
schließlich die Parameterliste durch
einen neuen Parameter, getypt durch die
neue Klasse (sowohl in der ur sprüng -
lichen Operation als auch in anderen
Operationen der gleichen Klasse).
Remove Isolated State: Bei diesem
Refactoring wird ein Zustand, der
weder eigehende noch ausgehende
Transitionen besitzt, aus der entsprechenden
Region eines Zustandsdia -
gramms gelöscht.
Die Liste der unterstützten Metriken,
Smells und Refactorings für UML-Modelle
wird sukzessive erweitert.
Literatur & Links
Fazit
In diesem Artikel haben wir einen
Qualitätssicherungsprozess für Software -
modelle sowie eine unterstützende Werk -
zeug umgebung anhand eines Beispiel -
modells der UML vorgestellt. Prozess und
Werkzeuge bedienen dabei zwei verschiedene
Benutzergruppen:
[Are10] T. Arendt, E. Biermann, S. Jurack, C. Krause, G. Taentzer, Henshin: Advanced Concepts
and Tools for In-Place EMF Model Transformations, MoDELS 2010, Springer 2010
[Are11] T. Arendt, S. Kranz, F. Mantz, N. Regnat, G. Taentzer, Towards Syntactical Model
Quality Assurance in Industrial Software Development: Process Definition and Tool Support,
Software Engineering 2011
[Ecl-a] Eclipse, Papyrus, siehe: eclipse.org/modeling/mdt/papyrus/
[Ecl-b] Eclipse, EMF Refactor, siehe: eclipse.org/modeling/emft/refactor/
[Fow99] M. Fowler, K. Beck, Refactoring – Improving the Design of Existing Code, Addison-
Wesley 1999
[IBM] IBM, Rational Software Architect, siehe:
http://www-01.ibm.com/software/rational/products/swarchitect/
[Moh09] P. Mohagheghi, V. Dehlen, T. Neple, Definitions and Approaches to Model Quality in
Model-Based Software Development – A Review of Literature, Information and Software
Technology, 12/2009
[OMG] Object Management Group, Unified Modeling Language, siehe: omg.org/spec/UML/
[Stei08] D. Steinberg, F. Budinsky, M. Paternostro, E. Merks, EMF: Eclipse Modeling Frame -
work, Addison-Wesley 2008
[Yat] Yatta Solutions GmbH, UML Lab, siehe: uml-lab.com
■
■
Qualitätsverantwortliche können projektspezifische
Qualitätseigenschaften
und somit bestimmte Sicherungs -
techniken festlegen.
Modellierer und Reviewer werden aufgrund
der Integration der Werkzeuge in
Modellierungsumgebungen direkt in
ihrer Modellierungsarbeit unterstützt.
Obwohl der Anwendungsfokus der vorgestellten
Werkzeuge auf der direkten Mo -
dellierung von Softwareartefakten liegt,
sind auch andere Anwendungsszenarien
denkbar. Beispielsweise könnte in einem
Reverse-Engineering-Prozess aus dem vorhandenen
Programmcode ein entsprechendes
UML-Modell erstellt werden (z. B. mit
UML Lab, vgl. [Yat]) und anschließend das
Design ähnlich einer statischen Code -
analyse mit Hilfe der vorhandenen Metri -
ken und Smells analysiert werden. Eine
Batch-Verarbeitung ist derzeit noch nicht
möglich. Entsprechende Schnittstellen werden
jedoch in einer zukünftigen Version
von EMF Refactor bereitgestellt. ■
18 19

advertorial
MODEL DRIVEN ARCHITECTURE
(ODER WIE AUCH IMMER SIE ES NENNEN MÖCHTEN)
FUNKTIONIERT
Als die UML 1996 als Standard für die Modellierung von Software und Systemen präsentiert wurde, haben die Erfinder gedacht, dass es jetzt
den einen, einzig wahren Standard gibt, der dazu geeignet ist, die Welt (speziell die der Techniker) zu beschreiben.
2012 – knapp 16 Jahre später – beschreibt
die UML immer noch erst knapp 10% aller
Software und Systeme. Es gibt nicht mehr
nur die UML, sondern BPMN, SysML,
BrainML, Togaf, … und viele, viele andere
Sprachen, die ihren Ursprung schon in der
UML haben, aber eben Domain spezifisch
(DSL) sind. Daran kann man aber auch
erkennen, dass die Erkenntnis: „Ein Bild
sagt mehr als tausend Worte“ schon längst
in vielen anderen Branchen Einzug gehalten
hat und nicht mehr nur „für Soft -
wareentwickler only“ verwendet wird.
Unter uns gesagt: Man kann mit allen
DSLs mehr oder weniger auch wirklich
alles modellieren, wenn man möchte. Und
meiner Meinung nach adressiert man mit
DSLs viel mehr die Eitelkeit von
Fachanwendern, die das eine wollen und
das andere eben justament nicht.
Ein klassisches „not invented here“-
Problem, was leider eine große Heraus -
forderung für die gesamte Branche darstellt.
Wie auch immer…Was aber - egal
welcher DSL Fraktion man angehört - auch
ein Fakt ist: Aus semantisch korrekten
Modellen kann man wiederverwendbare,
wenn man will auch ausführbare Anwen -
dun gen generieren. Damit entsteht das,
wovon die Branche schon lange träumt:
wiederverwendbare, fehlerfreiere, überschaubarere
Ergebnisse.
Es gibt mittlerweile Domänen, wo ohne
UML oder entsprechender DSL, die
Komplexität nicht mehr zu bewältigen
wäre. Das sind scheinbar ganz banale
Systeme wie die Ladestromsteuerung von
Hoch leistungsbatterien in modernen Elek -
tro fahrzeugen. In der Grundschaltung
betrachtet eine primitive Anordnung, aber
bei genauerer Betrachtung – Temperatur -
fühler, Bremsenergierückführung, Sonnen -
licht kollektoren, zuschaltbare Benzin-/
Diesel motoren etc. – ist die Komplexität
unglaublich groß und dann noch verschiedene
Varianten und Versionen. Wenn Ihnen
nun die Frage auf der Zunge liegt: Zahlt
sich das überhaupt aus? Meine klare
Antwort: JA!
Fachabteilungen können jetzt auf wichtige Modellinformationen mittels WEB/Cloud
Anwendung zugreifen
Also Model Driven Architecture lässt
sich in allen Domänen anwenden. Für den
abstrakten Metamodellierer genauso wie
für den Codezeilenjunkie.
Das Produkt Enterprise Architect von
SparxSystems begleitet mittlerweile über
320.000 Anwender im Arbeitsalltag in den
unterschiedlichsten Lebenslagen. Die einen
verwenden es klassisch für das Design von
neuen, innovativen Anwendungen und
wollen die seltene Chance, endlich mal was
komplett Neues entwickeln zu dürfen, professionell
angehen und nutzen. Die anderen
sind dankbar für die automatisiert generierbare
technische Dokumentation aus
bestehendem source code. Enterprise
Architect basiert auf einem Datenbank -
repository: Damit entsteht der große
Vorteil, dass alle Elemente und Konnek -
toren (Kanten, Verbindungen) samt ihren
Baselines über die Lebensdauer beisammen
sind und man sich sogenannte Medien -
brüche sparen kann. Enterprise Architect
ist aber ein UML-Tool mit all seinen
Komplexitäten und daher mitunter für die
Fachseite oder den Kunden nicht unbedingt
geeignet (Anmerkung am Rande: Der
Versuch, „Otto Normalverbraucher“ zu
erklären, dass er seine Anforderungen doch
gleich mit UML modellieren möge, stößt
sicherlich auf allgemeine Verwunderung,
wenn ihr Auftraggeber nicht selbst UML-
Anwender ist. So sind selbst die meisten
Fachanwender/Auftraggeber nicht in der
Lage, wohl formatierte und eineindeutige
Anforderungen zu formulieren, aber das ist
eine andere Geschichte).
Um aber die Anforderungen bzw. vielmehr
die Umsetzung von Anforderungen in
Use Cases, Activities oder gar Klassen zu
verfolgen (=tracen), müssen diese letztlich
auch ins Enterprise Architect Repository.
Dazu kann man sie importieren oder verknüpfen.
Das ist z. B. mit DOORS, Team
Foundation Server, CodeBeamer, Polarion
oder dem meist genutzten Anforderungs -
managementtool Excel möglich. Kreative
Weiterentwicklungen wie EnArWEB
(Enterprise Architect für WEB) des
SparxSystems Partners LieberLieber, die
auf dem Repository von Enterprise Archi -
tect beruhen, erleichtern diese Aufgabe
aber wesentlich.
■
KONTAKT:
SparxSystems Software GmbH
Handelskai 340/Top 5
A-1020 Wien
URL: www.sparxsystems.at
E-Mail: peter.lieber@sparxsystems.at
Vorgestellte Produkte:
Enterprise Architect, AMUSE, EnArWEB
6/2012

„Worauf konzentrieren Sie sich, wenn Sie
Modelle erstellen?“ Häufig lautet die
Antwort auf diese Frage: „Auf das Tool“.
IT-Werkzeuge nehmen bei der Model -
lierung einen prominenten Platz ein und
beanspruchen damit auch einen guten Teil
unserer Aufmerksamkeit. Darunter leiden
insbesondere kreative Prozesse, wie der
Entwurf von Software oder die Beschrei -
bung komplexer Fachlichkeit.
Kein Wunder also, wenn viele Konzepte
am Flipchart oder Whiteboard entwickelt
werden. Architektur und Entwurfsarbeit
finden heute oft in Kleingruppen statt, werden
informell vorangetrieben und möglichst
schnell der Umsetzung zugeführt.
Agile Praktiken ergreifen immer mehr
Disziplinen und letztendlich verschließen
sich auch die analytischen Domänen nicht
davor.
Die Geschäftsprozess-Modellierung ist
eine dieser Domänen. Komplizierte, vielschwerpunkt
die autoren
ANALOGE MODELLIERUNG:
ÜBER DIE QUALITÄTSSTIFTENDE
ABKEHR VOM TOOL
Modellierung wird fast untrennbar mit Modellierungswerkzeugen in Verbindung gebracht.
Trotz des unbestrittenen Nutzens von Werkzeugen ist die initiale Modellerstellung oft aufwändig,
fehleranfällig und wenig begeisternd. Am Beispiel der Geschäftsprozess-Modellierung zeigt
dieser Artikel einen alternativen Weg auf, der den kreativen Prozess der Modellerstellung vom
Modellierungswerkzeug löst. Physische Modelle und interaktives Vorgehen schaffen eine leichtgewichtige
und lebendige Modellierungsdisziplin.
Stefan Toth
(st@oose.de)
arbeitet als Softwarearchitekt, Berater und Trainer
bei oose. Seine Schwerpunkte sind die Konzeption
und Bewertung mittlerer bis großer
Softwarelösungen sowie die Verbindung dieser
Themen zu agilem Vorgehen und EAM.
leicht unternehmensweite Abläufe, die
meist eine Vielzahl von Stakeholdern
betreffen, sollen hier in verständliche und
klare Diagramme gegossen werden. Nur so
können Prozesse geeignet analysiert, optimiert
oder automatisiert werden. Aus -
tausch, Zusammenarbeit und eine dynamische
Modellierung sind hier extrem wichtig
und doch selten gelebt.
Unser Artikel greift diesen Faden auf.
Ausgehend von den in der Praxis beobachtbaren
Problemen, stellen wir alternative
Modellierungstechniken für Geschäfts -
prozesse vor – inklusive konkreter Hin -
weise zu deren Anwendung. Die gewonnenen
Erkenntnisse betten wir in einen
Gesamtprozess ein, der Schritt für Schritt
beschreibt, wie Sie von der Erhebung und
Analyse über die Beschrei bung bis zur
Wartung von Modellen gelangen. Als
Modellierungsnotation verwenden wir die
Business Process Model & Notation
Kim Nena Duggen
(kd@oose.de)
arbeitet als Business-Analyst, Beraterin und
Trainerin bei oose in Hamburg. Ihre Schwerpunkte
liegen in der Analyse, Modellierung und
Optimierung von Geschäftsprozessen und dem
Coaching von Business-Analysten.
(BPMN). Kasten 1 bietet für Neulinge
etwas Hintergrund, später zeigen wir auch
die wichtigsten Notations ele mente im
Überblick (siehe Abbildung 1). Die Kon -
zepte und Erkenntnisse sind auf andere
Domänen wie Architektur und Notationen
wie UML übertragbar.
Was ist die BPMN 2.0?
Die BPMN ist eine grafische Spezifikationssprache zum Modellieren von Geschäfts -
prozessen. Sie wurde 2002 von der Object Management Group (offenes Konsortium für
Spezifikationen in der Computerindustrie) erarbeitet und 2010 in der Version 2.0 um ein
Metamodell und weitere Diagrammarten erweitert.
Warum sollte man BPMN zur Modellierung nutzen?
Die BPMN 2.0 eignet sich als Modellierungsnotation für Geschäftsprozesse, da sie ein
weit verbreiteter Standard ist. Sie ist so konzipiert, dass sowohl Fachabteilungen als
auch IT-Vertreter den Einsatz der Elemente leicht erlernen können. Gleichzeitig ist die
Notation so mächtig, dass ausführbare Modellierung zur Automatisierung von
Prozessen genutzt werden kann.
Wo findet man die Spezifikation?
Hier: omg.org/spec/BPMN/2.0/
Kasten 1: Die Business Process Model & Notation (BPMN 2.0).
Stärken und Schwächen von
Modellierungswerkzeugen
Modellierungswerkzeuge leisten enorme
Dienste, wenn es um die Dokumentation
und Verwaltung von Konzepten, Sichten
und Entscheidungen geht. Sie erlauben
unternehmensweiten Zugriff auf Modelle
und bieten Analyse- und Auswertungs -
möglichkeiten für Beziehungen und
Elemente. Auch die Weiterentwicklung und
Wartung von komplexen Konzepten oder
Prozessmodellen sind mit Modellierungs -
werk zeugen einfacher und effektiver als
ohne. Der Abschnitt „Der Modellierungs -
prozess“ illustriert, wie ein Vorgehen aussehen
kann, das diese Vorteile von Tools
nutzt.
Die Verwendung von Modellierungs -
werk zeugen hat allerdings auch Nachteile,
20 21

■ Fachliche Fragen in den Vordergrund
bringen: Intuitive und „nicht spürbare“
Werkzeuge fördern den fachlichen
Fokus. Abstraktionen und Verein -
fachungen vom Standard sind einfacher
möglich und ad-hoc anwendbar.
■ Den nötigen Überblick fördern:
Mehrere Prozesse gleichzeitig sichtbar
zu machen und Zusammenhänge oder
Verantwortlichkeitsübergänge zu visualisieren,
stärkt die Übersicht und
Erkenntnisfähigkeit.
■ Dynamik und Interaktion stärken: Die
Abkehr vom klassischen Besprechungsschwerpunkt
Abb. 1: BPMN-Übersetzung (angelehnt an [Sil11]).
die sich hauptsächlich dann zeigen, wenn
gleichzeitig modelliert und konzeptionell
gearbeitet wird. Werden Geschäftsprozess-
Modelle erstellt, trifft genau das zu:
Generell sollte hier in Workshops gearbeitet
werden. Dynamik und der Austausch
zwischen Fachabteilungen und Analysten
sind extrem wichtig. Alle Beteiligten müssen
den Überblick über modellierte Pro -
zesse und deren Kontext haben und letztlich
ist der Wille zur Beteiligung bei
fachlichen Ansprechpartnern essenziell.
Modellierungswerkzeuge können hier einige
Schwächen offenbaren:
■ Erzwungener Formalismus: An kreativen
Analyseworkshops nehmen mehrere
fachliche Stakeholder und Prozess -
experten teil, um eine initiale Sicht auf
die Prozesslandschaft zu erarbeiten.
Dabei ist es hilfreich, Formalien zu -
nächst beiseite zu lassen und sich auf
die Fachlichkeit zu konzentrieren.
Tools erzwingen jedoch meist eine
„korrekte“ Modellierung und machen
Details von Anfang an wichtig.
■ Überforderung von fachlichen An -
sprech partnern: Modellierungs werk -
zeuge bieten eine Vielzahl von Op tionen
und Elementen zur Model lierung. Diese
Vollständigkeit in der Umsetzung von
Notationen ist bei der detaillierten
Ausgestaltung oder Auto matisierung
von Prozessen wichtig, behindert bei der
ersten Erhebung allerdings deutlich.
Fachliche Ansprech partner sind von der
Symbolvielfalt oft erschlagen, sehen sich
mit einer recht flachen Lernkurve konfrontiert
und verlieren schnell den Fokus
auf die Domäne.
■ Schwer greifbare Zusammenhänge: Die
Analyse von Unternehmensarchi tek -
turen erfordert unterschiedliche Mo -
dell arten (Business Process Diagrams,
Domänendiagramme, Organigramme
usw.), Prozessmodelle werden auf
unterschiedlichen Abstraktionsebenen
erstellt und Prozesse bedingen sich oft
gegenseitig. Diese Zusammenhänge
sind im Werkzeug häufig nicht direkt
sichtbar. Im Tool von Diagramm zu
Diagramm und zum Navigations -
bereich zu springen, führt häufig dazu,
dass Workshop-Teilnehmer den Überblick
verlieren. Erschwerend kommt
hinzu, dass größere Modelle wegen der
üblichen Beamer-Auflösung nie vollständig
gezeigt werden können.
■ Bedienung vor Fachlichkeit: Die An -
ordnung und Ausrichtung von Modell -
elementen, die richtige Beschriftung,
die Suche nach Tool-Optionen und
Teilnehmer-Tipps zu Tastenkombina -
tionen lenken die Aufmerksamkeit weg
von der Fachlichkeit. Es wird aufwändiger,
komplizierte Sachverhalte zu
besprechen, und wichtige fachliche
Fragen bleiben oft ungeklärt. Work -
shops werden zäh und verlieren an
Dynamik.
■ Wenig interaktiver Charakter: Model -
lierungswerkzeuge in Workshops einzusetzen,
bedingt meist ein klassisches
Besprechungs-Setup: Der Beamer projiziert
an eine Wand und die Workshop-
Teilnehmer sitzen an einem großen
Tisch. Das fördert eine konsumierende
Haltung und behindert einen lebendigen
Austausch. Es gibt keine direkte
Form der Mitgestaltung, sondern einen
Mittler in Form des Modellierers.
Damit behindert man die Lebendigkeit
des Prozesses, es entsteht ein Nadelöhr
und wichtige Fragen werden vielleicht
nicht gestellt. Werden Modellierungs -
vorschläge direkt in das Tool aufgenommen,
entstehen Diskussions pau -
sen, in denen die Teilnehmer warten.
■ Starrheit von Modelliertem: In der
Praxis ist zu beobachten, dass weder
Modellierer noch fachliche Ansprech -
partner grobe Änderungen an in
Werkzeugen erfassten Prozessen vornehmen
wollen. Ein im Tool modellierter
Prozess wirkt häufig professioneller,
durchdachter und stabiler, als er es
eigentlich ist. Teilnehmer sehen sich im
ersten Moment ohne Zugriffs- oder
Gestal tungs möglichkeit und halten sich
mit grundlegenden Fragen und Änderungswünschen
eher zurück.
Alternative Modellierungs -
techniken
Die beobachtbaren Schwächen von Tools
können mit alternativen Modellierungs -
techniken überwunden werden. Auf der
Suche danach sind folgende Ziele zentral:
6/2012

schwerpunkt
Setup, die Arbeit im Stehen und mit
haptischen Dingen ist ein agiler Trend,
der auch in großen Konzernen angekommen
ist. Die Mitwirkenden arbeiten
engagierter und fokussierter. Sie
werden aktiv in die Modellierung einbezogen
und gestalten mit. Durch die
einfache Änderbarkeit von modellierten
Ideen wird eine dynamische Weiter -
entwicklung von Ideen und Konzepten
möglich.
Vier Analogtechniken
Wir haben mehrere Techniken in realen
Projektsituationen getestet. Positive Effekte
sind vor allem bei der technologiefreien
(„analogen“) Modellierung spürbar:
■ Flipchart: In der ersten Variante zeichnen
die Workshop-Teilnehmer (oder ein
Moderator) die eingebrachten Pro -
zessinhalte auf ein Flipchart. Das
schafft einen guten Überblick und liefert
eine Diskussionsgrundlage für die
Gruppe.
■ Meta-Planwand mit Moderations -
karten: Eine andere Möglichkeit
besteht darin, Prozessergebnisse auf
Moderationskarten zu schreiben und
diese zur Übersicht an einer Meta-
Planwand anzubringen. Alle Teil neh -
mer können durch selbständiges
Ausfüllen der Karten interaktiv Input
geben. Darüber hinaus können die
Karten flexibel verschoben oder umbenannt
werden.
■ Moderationskarten auf dem Tisch: Um
eine größere Arbeitsfläche zu schaffen,
an der mehrere Beteiligte von verschiedenen
Seiten arbeiten, können
Moderationskarten auch freifliegend auf
einem großen Tisch verwendet werden.
■ Whiteboard/Whiteboard-Folie und
Post-its: Im vierten Ansatz werden
Prozesse mittels geeigneter Post-its auf
einer Whiteboard-Folie angebracht.
Später werden Verbindungslinien eingezeichnet.
Das vorrangige Ziel – Ergebnisse zu visualisieren
und Einigkeit innerhalb der Gruppe
herzustellen – wird mit jeder der beschriebenen
werkzeugunabhängigen Varianten
er reicht. Man profitiert allerdings vor
allem von Techniken, die große Flexibilität
gewährleisten. Im Praxiseinsatz ist das bei
Flipcharts und auch bei Meta-Planwänden
nicht unbedingt der Fall. Darüber hinaus
sind eine einfache Ergebnissicherung und
■
■
■
■
■
■
Ergebnis-Loyalität erreichen: Haptisch visualisierte Modelle schaffen Verbindung
mit dem Ergebnis und intensivieren die Kommunikation. Hängen Sie Plots und
Whiteboard-Folien mit Modellen an gut frequentierten Orten sichtbar auf.
Entspannung für die Fachexperten: Machen Sie eine Pause zwischen der gemeinsamen
Modellierung und den anschließenden Reviews. So werden mehr Fehler aufgedeckt,
mehr Lücken erkannt und das Review wird effektiver.
Fremdbeurteilung: Lassen Sie modellierte Prozesse von unbeteiligten Dritten in eigenen
Worten wiedergeben. So wird deutlich, ob die Modelle selbstsprechend und
logisch konstruiert sind.
Sich beschränken: Modellieren Sie nur das, was nötig ist. Klassifizieren Sie die identifizierten
Prozesse und detaillieren Sie nur wichtige und/oder unklare Abläufe.
Level für Level: Ein stufenweises Vorgehen vermeidet Detailverlorenheit oder zu
hohe Abstraktionsgrade. Gehen Sie von der Essenz über Gutfall- und Schlechtfall-
Beschreibungen bis hin zur Erweiterung um Varianten. Die Modellierung wird einfacher
und die ins Tool überführten Prozesse werden stabiler.
Experimente wagen: Testen Sie vorhandene Materialien wie Flipcharts, Meta-
Planwände oder auch Post-its in Workshop-Situationen und sammeln Sie so Best
Practices, um die im eigenen Kontext passendste Modellierungstechniken zu finden.
Kasten 2: Modellierungstipps.
zumindest temporäre Stabilität von Vorteil
– beides Dinge, die bei der Nutzung von
Moderationskarten auf Tischen nicht gegeben
sind. Am besten erfüllen Whiteboard-
Folien diese Kriterien. Sie haben sich im
Praxiseinsatz in Kombination mit Post-its
gut bewährt. Die Anleihe bei agilen
Planungsinstrumenten (wie Backlog-Wän -
den) ist hier auch am stärksten spürbar.
Experimentieren Sie aber zunächst durchaus
mit vorhandenen Ressourcen wie
Flipcharts oder Meta-Planwänden, um die
im eigenen Kontext geeignete Model -
lierungstechnik zu entdecken (diesen und
zusätzliche Praxistipps zur Modellierung
zeigt Kasten 2).
Pragmatischer Wortschatz
Da die Workshops zu Beginn einer Pro -
zesserhebung lediglich dazu dienen sollen,
Prozesse zu identifizieren und diese grob zu
beschreiben, empfiehlt es sich, ein reduziertes
Set von BPMN-Elementen zu nutzen –
eben den Wortschatz zu begrenzen. Mo -
derierte Prozessworkshops bieten Fach -
experten und künftigen Modellierern eine
wunderbare Möglichkeit, um die Notation
leicht kennen und anwenden zu lernen.
Abbildung 1 zeigt die reduzierte BPMN-
Palette und die nötigen Post-it- oder
Moderationskarten-Elemente.
Bedeutung für die
Zusammenarbeit
In der praktischen Anwendung der Tech -
niken profitieren sowohl die fachliche als
auch die technische und organisatorische
Seite von der angesprochenen Interaktivität
und Dynamik. Aus Gesprächen mit
Projektmitarbeitern können wir folgende
Essenz ableiten:
■
■
■
■
Business-Analysten profitieren stark
von der einfachen Änderbarkeit bereits
modellierter Prozessteile. Dadurch sind
Rückmeldungen von Fachexperten einfacher
aufzunehmen, was auch die
Anzahl an Rück mel dungen und Ideen
steigert. Einige Analysten berichteten
davon, „endlich ehrliches Feedback“ zu
bekommen.
Fachabteilungen sind oft überrascht,
wenn sich das Prozessbild an einer
Wand entfaltet. Einfachheit oder
Komple xität fallen leichter auf. Ein klarer
Vorteil ist die gute Review-
Möglichkeit in frühen Projektphasen.
Durch die vereinfachte Notation und
eine flexible Ausrichtung können
Fachabteilungen Änderungen „leicht
und schnell selbst durchführen“.
Führungskräfte sind mitunter etwas
skeptisch, weil teuer gekaufte Tools
nicht von Beginn an eingesetzt werden
und das „Zettelwerk“ auf den ersten
Blick nicht professionell wirkt. „Die
Ergebnisse sprechen allerdings eine
andere Sprache“.
Softwareentwickler fühlen sich meist
besser informiert und haben das
Gefühl, dass der Fachbereich „mehr
erzählt“. Die „Fachlichkeit wird greif-
22 23

schwerpunkt
Rolle
Business-Analyst
Modellierer
Fachexperte
IT-Ansprechpartner
Verantwortlichkeit
Organisation, Erhebung, Moderation.
Erstellung der Modelle (haptisch, im Tool).
Zulieferung des fachlichen Inhalts (Ist/Soll), Definition aller
Anforderungen und Machbarkeitsanalyse der organisatorischen
Anforderungen.
Zulieferung des technischen Inhalts und Machbarkeitsanalyse
der IT-Anforderungen.
Profiwissen und
Praxislösungen
Alle Bücher inkl.
kostenlosem E-Book!
Entscheider Festlegung des Projektfokus, Ressourcenallokation,
Umsetzungsverantwortung.
Tabelle 1: Typische Teilnehmer von Modellierungsworkshops.
NEU
barer“. Auch loben sie die „gemeinsame
Sprache“ – ein Effekt, der mit der
vereinfachten, auch für fachliche
Ansprechpartner leicht erlernbaren
BPMN aus Abbildung 1 zusammenhängt.
Die vorgestellten Techniken zur Model -
lierung haben sich bei der gemeinsamen
Modellierung bewährt. Workshops bringen
die Beteiligten zusammen und ermöglichen
einen direkten Austausch. Wer aber sind
die Beteiligten genau und was sind ihre
Aufgaben während der Modellierung?
Tabelle 1 zeigt eine typische Zusammen -
setzung und definiert Verant wort lichkeiten
für die wichtigsten Rollen.
Die Rolle des Modellierers wird in der
Praxis – je nach Teamgröße und Knowhow
– entweder eigenständig besetzt, Busi -
ness-Analysten zugeschlagen oder direkt
den Fachexperten übertragen. Wie im
Modellierungsprozess weiter unten zu
sehen, ist es ideal, wenn Fachexperten die
Modellierung ihrer eigenen fachlichen
Inhalte selbst übernehmen. Durch die vereinfachte
Notation (siehe Abbildung 1) und
die haptische Arbeit ist das meist gut zu
erreichen.
Der Modellierungsprozess
Wir orientieren uns zunächst an dem Vor -
gehensmodell IBPM (Integrierte Business
Process Management Projektmethodik)
von Slama und Nelius (vgl. [Nel11]). Zur
Integration eines Geschäftsprozessmanage -
ment-Projekts in einem Unternehmen sehen
sie die Erhebung und Beschreibung von
Prozessmodellen über vier Abstraktions -
ebenen vor:
■ In der Planungsphase wird zunächst der
Prozess-Scope definiert, also der
Beschreibungskontext eingeengt. Ein
Wertschöpfungsketten-Diagramm listet
die Prozesse auf, die näher betrachtet
werden sollen.
■ Im Rahmen der Analyse wird lediglich
der Gutfall 1 ) des einzelnen Prozesses
betrachtet, um sich in der initialen
Beschreibung nicht in Details zu verlieren.
■ Mittels einer Auflistung aller Ausnah -
me fälle wird im fachlichen Design eine
Erweiterung um Varianten, Fehler -
hand ling usw. vorgenommen.
■ Schlussendlich entsteht so eine fachlich
vollwertige Beschreibung aller Aspekte
des Geschäftsprozesses, seiner Ge -
schäfts objekte und der beteiligten
Rollen.
Dieses Vorgehen eignet sich hervorragend,
um mit den jeweiligen Fachexperten Ab läufe
stufenweise zu vervollständigen. Je nach
Projektziel kann bis zu einer deskriptiven,
einer eher analytischen oder sogar einer ausführbaren
Ebene detailliert werden.
Auf dieser Basis baut der in Abbildung 2
gezeigte Prozess auf. Er ergänzt IBPM um
die oben vorgestellten alternativen Model -
lierungs techniken und illustriert die wichtigsten
Verantwortlichkeiten (gleichzeitig
ist er ein kleines Beispiel für die Model -
lierung mit Post-its). In insgesamt zehn
1
) Der Gutfall betrachtet nur den regulären Prozess,
ohne Ausnahmen und Fehlersituationen. Beim
Schlechtfall kommen Alternativen, Fehlerkompen -
sationen etc. hinzu. Die bewusste Trennung dieser
beiden Fälle ist Teil des methodischen Vorgehens,
dient der Blickwinkelerweiterung und hilft dabei,
sich nicht schon zu Beginn in Details zu verlieren.
NEU
Stefan Zörner
Softwarearchitekturen
dokumentieren und kommunizieren
Entwürfe, Entscheidungen und Lösungen
nachvollziehbar und wirkungsvoll festhalten
277 Seiten
Flexibler Einband. € 34,90
ISBN 978-3-446-42924-6
Klaus Leopold,
Siegfried Kaltenecker
Kanban in der IT
Eine Kultur der kontinuierlichen
Verbesserung schaffen
331 Seiten
Flexibler Einband. € 34,90
ISBN 978-3-446-43059-4
Auch als Kindle-
Edition erhältlich!
Ernst Tiemeyer
Handbuch IT-Management
Konzepte, Methoden, Lösungen
und Arbeitshilfen für die Praxis
4., überarbeitete Auflage
719 Seiten
Flexibler Einband. € 59,90
ISBN 978-3-446-42751-8
Jetzt direkt bestellen!
Carl Hanser Verlag GmbH & Co. KG
direkt@hanser.de
6/2012
www.hanser-fachbuch.de/computer
www.hanser.de/computer

schwerpunkt
2. Nach der Unsicherheit bezogen auf die
Prozessinhalte (siehe „Priorität“ bzw.
„Stabilität“ in Abbildung 3).
Jeder Prozess kann in beiden Kategorien
eine hohe (H), mittlere (M) oder niedrige
(N) Bewertung erhalten. Im weiteren
Verlauf werden vorrangig die hoch kategorisierten
Prozesse näher betrachtet – zu -
nächst jene mit der Bewertung H/H, also
Prozesse, die sehr wichtig für das Projekt,
aber auch sehr unklar sind.
Abb. 2: Der oose-Modellierungsprozess.
Schritten führt er so detailliert wie nötig,
aber so schlank wie möglich zu belastbaren
Ergebnissen. In der Praxis werden für einen
Durchlauf – je nach Beschrei bungsfokus –
mehrere Definitions-, Model lierungs- und
Überarbeitungsworkshops abgehalten, die
im Abstand von einigen Tagen oder
Wochen abgehalten werden können. Die
Schritte beschreiben wir nachfolgend im
Detail.
Kick-off vorbereiten und
Projektfokus definieren
Zunächst ist festzulegen, welche Abtei -
lungen, Teams oder Personen an der Be -
schreibung der Fachlichkeit mitwirken sollen.
Danach wird der Kick-off vorbereitet
(Überlegungen zu Medien, Raumausstat -
tung und unterstützendes Informations -
material). Im ersten Workshop definieren
Entscheider (z. B. die Abteilungsleiter) dann
den Projektfokus.
Prozesse identifizieren
Der nächste Schritt ist die Identifizierung der
Prozesse. In einem weiteren Workshop werden
die für den Fokus relevanten
Fachexperten aktiv eingebunden. Sie identifizieren
Prozesse entweder unter
Zuhilfenahme von Referenzmodellen oder
arbeiten sich logisch durch die End-to-End-
Abläufe – von der Kundenanfrage bis zur
Leistungserbringung. Dabei achten sie darauf,
unterstützende Prozesse nicht zu vergessen,
die lediglich indirekt dazu dienen,
Leistungen zu erbringen. Ein gutes Re -
ferenzmodell enthält zumindest eine Auf -
listung der gängigsten Prozesse vergleichbarer
Unternehmen und liefert damit eine gute
Ausgangsbasis (vgl. [Nis08]). Die identifizierten
Prozesse werden zunächst auf
Moderationskarten oder großen Post-its
gesammelt und an einer (Meta-Plan-)Wand
nach thematischer Zusammen gehörigkeit
gruppiert. Als Namenskonvention dienen
Substantiv und Verb (z. B. „Prozesse identifizieren“).
Prozesse essenziell beschreiben
Nach der Identifikation der zentralen
Prozesse, wird eine essenzielle Gutfall-
Beschreibung jedes Prozesses angelegt. Der
Gutfall behandelt keine Ausnahmen oder
Fehler, grenzt aber die Prozessinhalte ab und
macht eine erste Struktur ableitbar.
Essenzielle Beschreibungen sind bewusst
stark vereinfacht, abstrakt, technologieneutral
und unabhängig von den Personen, die
sie im Realfall implementieren. Die Essenz -
beschreibungen werden für die identifizierten
Prozesse in einem mit Abbildung 3 vergleichbaren
Formular oder zunächst auf
Flipcharts erstellt. Dabei müssen die
Formularinhalte nicht vollständig erarbeitet
werden. Sie werden teilweise noch später
detaillierter betrachtet. Zunächst geht
es darum, die Prozesse etwas näher kennenzulernen
und sie grob voneinander ab -
zugrenzen.
Prozesse klassifizieren
Anschließend klassifizieren die Workshop-
Teilnehmer alle Prozesse nach zwei Achsen:
1. Nach der Wichtigkeit für die Errei -
chung des Projektziels.
Gutfall-Modellierung vornehmen
Nun beginnt die Modellierung der Prozesse
selbst und die vorgestellten Model lierungs -
techniken beginnen ihre Stärken auszuspielen.
Alle in der Essenzbeschreibung enthaltenen
Aktivitäten, Ereignisse und
Ge schäfts objekte werden visualisiert. Postits
wandern auf möglichst große Wand -
flächen, Moderationskarten auf Pinn -
wände. Ein erster Entwurf entsteht aus den
Auslösern (= Startereignis), Ergebnissen
(= Endereignis) und Essenzschritten (=
Akti vitäten) der Essenzbeschreibung.
Die Teilnehmer sammeln und benennen
Aktivitäten und Ereignisse (eintretende
bzw. auslösende Zustände). Um auszudrücken,
wer für eine Aktivität des Pro -
zesses verantwortlich ist, werden die
Karten oder Post-its in entsprechend
benannte Bahnen (Lanes) sortiert (zur
Notation siehe Abbildung 2). Es ist ausreichend
Platz zwischen den modellierten
Elementen ratsam, um vielfache Neuarran -
ge ments zu vermeiden: Die grafische
Darstellung des Gutfalls kann neue Ak -
tivitäten offensichtlich machen und die spätere
Schlechtfall-Betrachtung ergänzt
Verzweigungen, Ereignisse und eventuell
auch weitere Aktivitäten.
Nach dieser gemeinsamen Modellierung
sind die wichtigsten Prozesse grafisch dokumentiert
und die vor- und nachgelagerte
Prozesse sind über die benötigten In- und
Outputs ableitbar. Der Prozess würde in etwa
so aussehen, wie in Abbildung 2 dargestellt.
Review durchführen
Mit ein wenig zeitlichem Abstand wird in
einem weiteren Workshop ein Review der
grob beschriebenen Prozesse vorgenommen.
Bei jedem Prozess, der einem Review
unterzogen wird, gibt ein Fachexperte (vorrangig
jemand, der nicht an der initialen
Beschreibung mitgewirkt hat) den Prozess
anhand des Post-its-Modells in eigenen
Worten wieder. Anschließend können An -
24 25

schwerpunkt
Abb. 3: Formular zur Essenzbeschreibung von Prozessen.
passungen flexibel durch Umpositio -
nierungen und Ergänzungen im physischen
Modell durchgeführt werden.
Gutfall-Modellierung
korrigieren und erweitern
Es folgen die Detaillierung und Erwei -
terung des Post-it- oder des Kartenmodells.
Der grobe Prozess wird durch gezielte
Diskussionen des Schlechtfalls um Alterna -
tiven, Ausnahmen und Kompensations -
aktivitäten ergänzt. In unserem Beispiel aus
Abbildung 2 werden etwa nach Schritt 5
Prozesse mit niedriger Wertung zurückgestellt
– ein alternativer Weg und ein
Schlechtfall für die betroffenen Prozesse.
Darüber hinaus wird nun am visualisierten
Modell für alle deutlich, wo Verant -
wortlichkeitsübergänge nötig sind und wo die
Komplexität hoch ist. Auf dieser Basis kann
entschieden werden, ob der Teil nehmerkreis
für den nächsten Workshop erweitert wird,
ob Teilprozesse ausgelagert oder unnötige
Aktivitäten eingespart werden können.
Detaillierte Prozesse ins Tool überführen
Es hat sich bewährt, die Prozessmodelle
eine gewisse Zeit für alle Beteiligten sichtbar
hängen zu lassen. So können nötige
Ergänzungen vorgenommen oder unklare
Punkte geklärt werden. Ist der beschriebene
Prozess einigermaßen stabil, beginnt die
Überführung ins Modellierungswerkzeug.
Sukzessive werden nun Organisations -
struk turen (Prozessbeteiligte), Prozesse,
Geschäftsobjekte (Entitäten), Regelwerke
und weitere ausgestaltende Details im Tool
erfasst. Gleichzeitig dient ein Abgleich zwischen
bereits vorhandenen Modell elementen
mit den neuen Modellinhalten der Überprüfung
auf Wiederverwen dungs möglichkeiten.
Die Beschreibungslogik im Tool unterstützt
beim Angleichen der Lösung an Architekturoder
Model lierungs vorgaben.
Finales Review und Abnahme durchführen
Die ins Tool überführten Modelle können
dann im Zusammenhang betrachtet werden.
Hierzu können bewusst Sichten auf
Elemente der Unternehmensarchitektur
gebildet werden. Zum Beispiel würde ein
Blick auf den Sollprozess im Zusam -
menspiel mit dem Organigramm inklusive
konkreter Stellenbesetzung zeigen, ob
Parallelisierungen möglich sind oder
Engpässe entstehen könnten. Die Work -
shop-Beteiligten nutzen Tool-Funktionen,
um ein Review der Ergebnisse durchzuführen
und diese abzunehmen.
Weitere Verwendung der Modelle
Die Modelle können nun im Model -
lierungswerkzeug genutzt werden. Idealer -
weise stehen sie allen Interessierten unternehmensweit
zur Verfügung. Sichten und
Ausschnitte (z. B. Abstraktionsebene für die
Geschäftsführung) ermöglichen eine zielgruppengerechte
Kommunikation. Modelle
werden im Tool gewartet und aktualisiert,
weiterentwickelt und möglichst auch versioniert.
Die Stärken von Modellierungs -
werkzeugen beginnen zu greifen.
Fazit und Ausblick
Bei der Erhebung und Analyse von Ge -
schäftsprozessen sind Austausch, Dynamik
und Übersicht sehr wichtig. Um dieser
Tatsache Rechnung zu tragen, sollten Sie
eine Umgebung schaffen, in der fachliche
Fragen in den Vordergrund rücken,
Interaktion gefördert wird und der Kontext
immer sichtbar ist. Die vorgestellten alternativen
Modellierungstechniken arbeiten in
diese Richtung und verdrängen Tools aus
den frühen Phasen der Modellierung.
Haptische, anfassbare, physische Tech ni -
ken, wie das Modellieren auf Whiteboard-
Folie, bieten ein hohes Maß an Flexibilität. In
gemeinsamen Workshops greifen die
Beteiligten direkt ein und verwenden einen
einfach erlernbaren, eingeschränkten No ta -
tions-Wortschatz. In der Praxis kann man
beobachten, dass die Akzeptanz gegenüber
der Geschäftsprozess-Modellierung steigt,
die Qualität der Prozesse verbessert wird und
gleichzeitig die Erstellungsaufwände sinken.
Der hier vorgestellte Modellierungs -
prozess illustriert, wie diese Form der
Modellierung abläuft und wie sich Modelle
schließlich hin zum Tool entwickeln. Die
Agilität der Modellierung wird durch einzelne
Schritte des Prozesses erhöht: So
fokussiert die Priorisierung Aufwände auf
die wichtigen Unternehmensteile, direktes
Feedback sorgt für stabilere Entwürfe und
Fachexperten wenden die Analysemetho -
den auch selbst an. Der Prozess wird iterativ
durchlaufen und kann leicht verschlankt
oder erweitert werden.
Die in diesem Artikel beschriebenen
Ideen haben wir in der Praxis erprobt und
sie sollten mit dem vorliegenden Material
ausprobiert werden können. In Kasten 2
finden Sie weitere Hinweise für den Praxis -
einsatz. Experimentieren Sie mit den
Methoden und passen Sie den Prozess auf
Ihr Unternehmen und Ihr Projekt an.
Fangen Sie klein an – weniger formal bringt
manchmal mehr Ergebnis.
■
Literatur & Links
[OMG] Object Management Group (OMG),
BPMN 2.0 Spezifikation, siehe:
omg.org/spec/BPMN/2.0/
[oos] BPM-Werkzeugliste, siehe:
oose.de/nuetzliches/fachliches/bpm-werkzeuge
[Nel11] R. Nelius, D. Slama, Enterprise BPM –
Erfolgsrezepte für unternehmensweites Pro -
zess management, dpunkt.verlag 2011
[Nis08] V. Nissen, M. Seifert, Das Consulting
C – Grundzüge eines Prozessreferenzmodells
für Beratungsunternehmen, in: M. Bichler
(Hrsg.), Proc. der Multikonferenz Wirtschafts -
informatik, München, GITO-Verlag 2008
[Sil11] B. Silver, BPMN Method & Style, Cody
Cassidy Press 2011
6/2012

Zur Vorgeschichte
In BPMN modellierte Geschäftsprozesse
können zwar erst direkt in Prozess-Engines
ausgeführt werden, seit die Version 2.0 ein
formales Metamodell in Form eines XML-
Schemas vorgibt, das der Serialisierung der
Diagramme dient. Tatsächlich wurde der
Standard jedoch schon zuvor für die
Prozessautomatisierung eingesetzt, beispielsweise
2010 bei der 1&1 Internet AG:
Dort wurde die Bestellabwicklung von
DSL-Anschlüssen in BPMN modelliert und
mit Hilfe einer Modelltransformation
(Mapping) in die proprietäre Prozess -
sprache von JBoss jBPM 3 überführt (vgl.
[Cam-a]). Schon damals konnten nennenswerte
Vorteile bei der Prozessabstimmung
zwischen Fachabteilung und IT sowie im
Rahmen des Prozessbetriebs auch innerschwerpunkt
mehr zum thema:
bpmn.info
der autor
BPMN 2.0:
EINE ZWISCHENBILANZ
Die Business Process Model and Notation (BPMN) 2.0 wurde im Januar 2011 verabschiedet.
Die primäre Intention dieses Standards ist die Verbesserung der Abstimmung zwischen
Business und IT bei der Entwicklung von Anwendungen für das Human-Workflow-Management
und die Orchestrierung von (Web-)Services. Knapp zwei Jahre später ist es nun Zeit für eine
Zwischenbilanz: Wo stehen wir in der Zusammenarbeit zwischen Business und IT, wenn es um
die Automatisierung von Geschäftsprozessen mit BPMN geht?
Jakob Freund
(jakob.freund@camunda.com)
ist Geschäftsführer der camunda services GmbH
und berät seine Kunden zu den Themen Business
Process Management und BPMN. Er interessiert
sich für Prozessarchitekturen, die sowohl die
Organisation als auch die technische Umsetzung
von Kernprozessen direkt unterstützen.
Der Siegeszug von BPMN
Obwohl die Business Process Model and
Notation (BPMN) bereits 2002 entwickelt
wurde, begann ihre eigentliche Verbreitung
im Jahre 2005 mit der Adaption durch die
Object Management Group (OMG), die
unter anderem den UML-Standard verantwortet.
Seitdem wurde sie weltweit von
zahlreichen Unternehmen und Behörden
aufgegriffen, wobei sie gerade in Deutsch -
land erst relativ spät wahrgenommen wurde.
Eine Ursache dürfte in der hierzulande
traditionellen Dominanz der ereignisgesteuerten
Prozesskette (EPK) sowie be -
stimmter Tools für das organisatorische
Prozessmanagement liegen, deren Her -
steller eigene Notationen definiert haben
und diese auch gern beibehalten hätten.
Ungefähr im Jahr 2008 begann aber auch
in Deutschland die Trendwende zu Gunsten
der BPMN, nicht zuletzt, weil viele Unter -
nehmen lieber einen global gültigen
Standard für die Prozessmodellierung verwenden
als die proprietäre Notation ir -
gend eines Tool-Herstellers.
halb der IT realisiert werden. Dieses Phä -
no men beschränkte sich nicht auf die
Prozessautomatisierung, sondern konnte
auch allgemein in IT-Projekten beobachtet
werden, wie beispielsweise dem Atlas-
Projekt des Bundesministeriums der Finan -
zen (vgl. [Cam-b]).
Mit der Version 2.0 und der somit direkten
Ausführbarkeit der Prozessmodelle
waren dementsprechend große Hoffnungen
verbunden, da die zuvor notwendigen
Mappings nun entfielen und ein echter
Roundtrip der Modelle zwischen Business
und IT in greifbare Nähe rückte.
Schleppende Umsetzung
in den Engines
Obwohl die Prozess-Engine-Anbieter IBM,
Oracle und SAP selbst die drei hauptverantwortlich
treibenden Kräfte hinter
BPMN 2.0 waren, sollte es noch einige
Monate dauern, bis sie den Standard in
ihren eigenen Produkten überhaupt umge-
setzt hatten. Andere große und weltweit
relevante Anbieter von Prozess-Engines
verweigern sich bis heute der BPMN und
bleiben älteren Standards, wie z. B. der
Business Process Execution Language
(BPEL) und der XPDL (XML Process De -
finition Language (XPDL), oder ihrer eigenen
proprietären Prozessbeschrei bungs -
sprache, treu.
Aus Sicht dieser Hersteller ist das natürlich
verständlich, aus Anwendersicht aber
eher enttäuschend. Zwar muss man zugestehen,
dass die Idee der einfachen Aus -
tauschbarkeit von Prozess-Engines dank
BPMN 2.0 ohnehin in der Praxis kaum realistisch
ist: Dafür sind proprietäre Erwei -
terungen des Standards in den jeweiligen
Produkten aus unterschiedlichen und
zumeist nachvollziehbaren Gründen zu
häufig erforderlich. Trotzdem lohnt sich
das Erlernen einer einheitlichen Aus -
führungssprache: Einen guten Teil des
Know-hows, das man für die Prozess -
Abb. 1: Tool-Kette auf Basis von BPMN 2.0.
26 27

schwerpunkt
Abb. 2: Laufzeitinformationen für eine konkrete Prozessinstanz, eingeblendet in einem
BPMN-Diagramm aus Adonis (der Prozess steht momentan in der Aufgabe
„Rechnung klären“, erkennbar an der orangefarbenen Markierung).
umsetzung in einem Produkt von Oracle
aufbauen muss, kann man für die Auto -
matisierung mit SAP Netweaver wiederverwenden.
Sobald das Produkt jedoch eine
andere Sprache spricht, muss man die
Lernkurve in dieser Hinsicht komplett
erneut durchlaufen.
Auch deshalb ist es umso erfreulicher,
dass neue Anbieter von Prozess-Engines
den Markt betreten haben, die von Anfang
an konsequent auf BPMN 2.0 setzen.
Dabei hat sicher auch das Open-Source-
Projekt „Activiti“ (vgl. [Act]) unterstützt,
das eine native BPMN-2.0-Engine enthält
und in unterschiedliche kommerzielle
Produkte integriert wurde.
Erfreuliche Umsetzung in den
Modellierungswerkzeugen
Der Markt für Modellierungswerkzeuge ist
schon weiter. Mittlerweile haben die meis -
ten etablierten Hersteller BPMN in ihren
Produkten berücksichtigt. An dieser Stelle
hat tatsächlich das marktwirtschaftliche
Prinzip gewirkt: Manch ein Anbieter war
zunächst wenig begeistert von BPMN, hat
dann aber notgedrungen die Unter stützung
umgesetzt, da sie in Ausschrei bungen und
Kundenanfragen immer häufiger zum
K.O.-Kriterium wurde.
Mittlerweile kann man als Kunde also aus
einer breiten Palette von BPMN-Werk zeugen
wählen, die sowohl als Open-Source bzw. als
Freeware als auch zu kleinen und großen
Lizenzpreisen von bis zu sechsstelligen
Beträgen verfügbar sind. Damit einher geht
ein größerer und besser funktionierender
Markt für Beratungs- und
Schulungsleistungen: Dem BPMN-Exper ten
ist es egal, mit welchem Tool der Kunde
arbeitet. Er kann auf jedem Produkt schulen
und beraten, das BPMN ordentlich unterstützt.
Dementsprechend zahlreich sind mittlerweile
auch die Informa tions quellen im
Internet sowie die Bücher, Beratungs- und
Seminarangebote zu BPMN. Der damit verbundene
zunehmende Qualitäts- und
Preiswettbewerb dürfte schlussendlich
wiederum dem Kunden zu Gute kommen.
In Bezug auf die angestrebte verbesserte
Abstimmung zwischen Business und IT spielt
die Kombinierbarkeit von Model -
lierungswerkzeugen und Prozess-Engines
eine besondere Rolle. Im Idealfall können
Business-Analysten, Requirements-Engi -
neers, Product Owner und andere Akteure
mit einem intuitiv bedienbaren Werkzeug
den Soll-Prozess modellieren und die Ent -
wickler können dieses Modell in der
Entwicklungsumgebung ihrer Prozess-En -
gine direkt übernehmen und in die technische
Ausführung bringen (siehe Abbil dung 1).
Wenn dabei Änderungen des Prozessmodells
erforderlich werden, können diese sofort in
das fachliche Model lierungswerkzeug zurükkgespielt
und bei Bedarf durch den Vertreter
der Fachseite geprüft und freigegeben werden.
Diese Kombination aus Forward- und
Reverse-Engineering wird in der BPM-Welt
auch als Roundtrip bezeichnet. Ein guter Teil
der Idee hinter BPMN 2.0 basiert auf der
Ambition, diesen Roundtrip praktisch zu
verwirklichen.
Auch hier fällt die Bilanz in Bezug auf die
größeren Hersteller eher ernüchternd aus:
Ein vollständiger BPMN-Roundtrip mit
einem wirklich businesstauglichen Tool einerseits
und einer entwicklerfreundlichen
Umgebung andererseits ist bislang nicht in
Sicht. Dabei wäre das technisch gar nicht so
schwierig und es wurde bereits demons triert,
wie eine BPMN-2.0-Prozess-Engine mit acht
unterschiedlichen BPMN-Model lierungs -
werk zeugen gekoppelt werden kann, darunter
so bekannte Werkzeuge wie „BOC Ado -
nis“ oder „Enterprise Archi tect“ (vgl.
[BPM-a]). Dabei ist es sogar möglich, die
Historie für eine durchlaufene Prozessinstanz
inklusive der Laufzeitin for ma tionen, wie z.
B. der Durchlaufzeit für einzelne Aufgaben,
direkt im Diagramm des fachlichen Werk -
zeugs einzublenden (siehe Abbildung 2).
Anforderungen an die
Betriebsorganisation
Mit der Popularität von BPMN nahm
naturgemäß auch die Anzahl ihrer Kritiker
Abb. 3: Dieses Diagramm sieht einfach aus, ist aber missverständlich.
6/2012

zu. Ein häufiges Argument gegen den
Standard ist die Komplexität der Notation:
Über 60 unterschiedliche Symbole sind darin
enthalten und man darf natürlich be -
zweifeln, dass der durchschnittliche Fach -
anwender, beispielsweise im Vertrieb oder
in der Buchhaltung, all diese Symbole erlernen
wird. Mittlerweile hat sich aber die
Erkenntnis durchgesetzt, dass genau dieser
Fachanwender erstens tatsächlich zugänglicher
für viele Symbole ist, als zunächst
angenommen, und zweitens die gesamte
Palette auch gar nicht kennen muss, um
von BPMN zu profitieren.
Das folgende Prozessfragment verdeutlicht
das: Ein eingegangener Antrag wird
geprüft. Wenn der Antrag in Ordnung ist,
wird er angenommen, ansonsten abgelehnt.
Außerdem soll, wenn sich die Prüfung länschwerpunkt
Abb. 4: Eine EPK-Version des
Diagramms aus Abbildung 3.
ger hinzieht, die entstehende Verzögerung
nach fünf Tagen gemeldet werden, damit
der Vorgang eskaliert werden kann. Wenn
man diesen Prozess modelliert und sich
dabei auf diejenigen Symbole der BPMN
beschränkt, die man auch aus anderen
Notationen kennt, besteht eine gute
Chance, dass ein Diagramm wie in
Abbildung 3 dabei herauskommt. Zum
Vergleich zeigt Abbildung 4 eine traditionelle
EPK, die nach demselben Prinzip aufgebaut
ist.
Diese Modelle erscheinen zunächst einfach,
da die verwendeten Symbole mehr
oder weniger allgemein bekannt sind.
Jedoch ist die Semantik weder korrekt noch
eindeutig nachvollziehbar: Den Modellen
zufolge würde, wenn die Antragsprüfung
fünf Tage oder länger dauert, diese Ver -
zögerung erst nach abgeschlossener
Prüfung gemeldet werden. Wir könnten
also den Antrag auch 100 Tage lang prüfen
– eine Verzögerung wird stets erst gemeldet,
wenn die Prüfung abgeschlossen ist.
Wir könnten das Ganze umbauen, um der
gewünschten Semantik näher zu kommen,
werden diese aber nie ganz erreichen,
zumindest nicht ohne eine größere Anzahl
von Symbolen hinzuzuziehen und damit
das Diagramm schlussendlich wieder un -
übersichtlich zu machen.
In Abbildung 5 sehen wir, wie wir die
gewünschte Semantik relativ elegant erreichen
können. Wir benutzen dazu ein angeheftetes
Zeitereignis, das als „nicht unterbrechend“
markiert ist (gestrichelte Linie).
Jetzt drücken wir aus, dass nach fünf Tagen
eine Verzögerung gemeldet wird, wenn die
Antragsprüfung entsprechend lange dauert
(und auch nur dann). Die Antragsprüfung
wird nicht abgebrochen, sondern parallel
zur Verzögerungsmeldung fortgesetzt. Wir
Abb. 5: Das Zeitereignis markiert eindeutig, unter welchen Umständen eine
Verzögerung gemeldet wird.
haben die Erfahrung gemacht, dass auch
Fachanwender ohne BPMN-Kenntnisse diese
Darstellung relativ schnell verinnerlichen
und auf andere Prozessfragmente anwenden
können, denn tatsächlich handelt es sich
hierbei um ein Muster, das in den unterschiedlichsten
Prozessen immer wiederkehrt.
Ganz nebenbei ist dieses Diagramm nicht
nur eindeutig interpretierbar, sondern in
einer BPMN-2.0-Prozess-Engine auch noch
direkt ausführbar. In der EPK haben wir eine
solche Form der Modellierung überhaupt
nicht zur Verfü gung.
Das Beispiel ist nur die Spitze des
Eisbergs: Es gibt zahlreiche Modellierungs -
muster dieser Art, deren Existenz den meis -
ten Interessierten zunächst gar nicht
bewusst ist, die aber den eigentlichen Wert
von BPMN in der Praxis ausmachen. Hier
wird auch deutlich, dass BPMN tatsächlich
ein starkes Umdenken erfordert, wenn man
bislang mit älteren Prozessnotationen wie
der EPK gearbeitet hat. Insofern ist es nicht
überraschend, dass EPK-Kenner häufig
größere Schwierigkeiten haben, BPMN zu
verinnerlichen, als Menschen, die noch
überhaupt keine Erfahrung in der Prozess -
modellierung haben. Im schlimmsten Fall
mussten wir feststellen, dass leidenschaftliche
EPK-Anhänger BPMN anders anwenden
als eigentlich gedacht, damit sie ihre
bisherigen Denkmuster nicht aufgeben
mussten. Ein schönes Beispiel hierfür ist die
„Prozess-Schnittstelle“ in der EPK, die eine
Verknüpfung von zwei Prozessen im Sinne
eines Vorgängers und Nachfolgers ermöglicht.
Das Konzept widerspricht fundamental
den zentralen BPMN-Denkmustern, die
eine solche Beziehung nur entweder als
einen sequenziellen Aufruf von zwei
Teilprozessen innerhalb eines Ober -
prozesses begreifen würden oder als eine
Kollaboration zweiter autonomer Prozesse,
die über Nachrichtenflüsse miteinander
kommunizieren.
Insgesamt kann man festhalten, dass
BPMN zwar die Abstimmung zwischen
Fach- und IT-Seite wesentlich verbessern
kann, dies aber auch das Meistern einer
steilen Lernkurve auf Seiten der Prozess -
modellierer bedingt. Das gilt wohlgemerkt
für die Ersteller, nicht für die Betrachter der
Prozessmodelle. Ein guter Prozessmodel -
lierer ist in der Lage, mit BPMN sehr aussagekräftige,
häufig direkt ausführbare
BPMN-Diagramme zu erstellen, die trotzdem
auch von BPMN-unkundigen Fach an -
wendern schnell verstanden und korrekt
interpretiert werden können.
28 29

schwerpunkt
Abb. 6: Ein „Two-Phase-Commit“, modelliert in BPMN (Quelle: Daniel Meyer,
camunda).
Neue technische Patterns
Da BPMN eine vom konkreten Soft -
wareprodukt unabhängige Sprache ist,
wird sie auch zunehmend zu einem beliebten
Vehikel für Architekturdiskussionen in
der IT-Community:
■
■
■
In seiner Dissertation hat beispielsweise
Volker Stiehl die Umsetzung der be -
kannten EAI-Workflow-Patterns mit
BPMN und Prozess-Engines beleuchtet
(vgl. [Sti11]).
Bernd Rücker schlägt eine konkrete
Umsetzung des UI-Mediator-Patterns
zur Kombination von Masken- und
Prozessflüssen in Prozess-Engines vor
(vgl. [BPM-b]).
Daniel Meyer modelliert mögliche
Strategien zur Sicherung der Trans -
aktionssicherheit in BPMN und
beschreibt ihre Konsequenzen für Pro -
zess anwendungsarchitekturen (siehe
Abbildung 6 bzw. [BPM-c]).
Obwohl diese und viele weitere Diskus -
sionsteilnehmer aus unterschiedlichen Kon -
texten stammen und verschiedene
Software produkte kennen, sprechen sie
doch mit BPMN alle eine gemeinsame
Sprache und können auf diese Weise ihr
Wissen weitergeben, ihre Erfahrungen austauschen
und neue Lösungsansätze miteinander
diskutieren.
Verfeinerungen funktionieren
nur selten
In der Lehre und Praxis dominiert bis heute
eine etwas problematische Vorstellung
davon, wie man von einem fachlichen zu
einem technischen Prozessmodell gelangen
kann: Dieser zufolge beschreibt man einen
Geschäftsprozess zunächst nur grob und
verfeinert ihn dann über Teil- oder Unter -
prozesse (in BPMN Sub Processes), bis man
einen Detaillierungsgrad erreicht hat, der
eine direkte Ausführung in einer Prozess-
Engine erlaubt. Während also die unteren
Ebenen des Modells technisch verwertet
werden, können die oberen Ebenen als
Dokumentation für Mitarbeiter oder
Auditoren dienen.
Dieses auf den ersten Blick sehr plausible
Vorgehen wird inzwischen seit fast zehn
Jahren empfohlen – und doch gibt es so gut
wie keine Beispiele aus realen Projekten, in
denen es tatsächlich funktioniert hat (ich
kann das zwar nicht empirisch belegen,
beschäftige mich aber seit 2004 mit dem
Thema und beziehe hier insofern Stellung
aus meiner eigenen Sicht). Wo liegt das
Problem? Zusammengefasst gibt es – ganz
unabhängig von BPMN – zwei Ursachen:
1. Eine konsistente Verfeinerung ist häufig
schon auf fachlicher Ebene schwierig
und beim Übergang in die technische
Umsetzung so gut wie unmöglich.
2. Das ausführbare Prozessmodell ist
nicht nur die technische Abbildung
fachlicher Anforderungen, sondern
selbst ebenfalls ein fachlicher Artefakt
und darf daher nicht nur von Ent -
wicklern determiniert werden.
Um den ersten Punkt zu verdeutlichen,
betrachten wir einen typischen End-to-
End-Prozess, den Rechnungseingang in
Abbildung 7, auf grober Ebene. Das Pro -
blem ergibt sich, wenn wir diesen Prozess
verfeinern wollen, um bestimmte Details
aufzunehmen. Beispielsweise wird die Ge -
schäftsführung nicht jede Rechnung sofort
bezahlen, die genehmigt wurde. Nehmen
wir an, sie macht nur einmal pro Monat,
z. B. zum Monatsende, einen Sammel -
Nutzen Sie Ihre Chance!
Werden Sie Teil des OIO-Teams.
täglicher Austausch mit
Technologie-Begeisterten
ständige
Weiterbildung
Verantwortung
anspruchsvolle
Entwicklungsprojekte
hausinternes
Schulungsprogramm
fl exible
Arbeitszeitgestaltung
Wir sind das Expertenhaus für die Softwareentwicklung mit Java, XML und Open
Source in Mannheim und suchen zur Festanstellung:
+ Java Experte (m/w)
+ Java Consultant (m/w)
+ Java Senior Consultant (m/w)
+ Atlassian Consultant (m/w)
Sie arbeiten in einem hochmotivierten Expertenteam mit wenig Bürokratie und
bringen sich von Anfang an aktiv in die Geschäftsprozesse mit ein. Dazu zählt
die Mitwirkung bei anspruchsvollen Entwicklunsprojekten bei uns vor Ort und bei
unseren namhaften internationalen und nationalen Kunden.
Als Consultant sind Sie in unseren drei Geschäftsbereichen als Trainer, Berater
und Entwickler tätig und betreiben regelmäßig Forschung und Weiterbildung.
Sie fühlen sich angesprochen?
Dann senden Sie uns Ihre Bewerbung per Email an work@oio.de
Weitere Informationen fi nden Sie unter www.oio.de.
) Schulung )
) Beratung ) ) Entwicklung )
OIO - Orientation in Objects GmbH I Weinheimer Str. 68 I 68309 Mannheim I Tel. +49 621 71839-0 I Fax +49 621 71839-50 I info@oio.de I www.oio.de

schwerpunkt
Abb. 7: Der Prozess „Rechnungseingang“, grob beschrieben.
durchlauf, um alle aufgelaufenen Rech -
nungen zu bezahlen. Dieser Umstand ist
gewissermaßen eine Detailinformation
(Wie erledigt die Geschäftsführung die
Aufgabe „Rechnung bezahlen?“), aber wir
können sie in diesem Diagramm nicht sauber
und präzise beschreiben. Natürlich
könnten wir irgendeinen Hinweis hineinsetzen,
eine Textanmerkung an der Auf -
gabe „Rechnung bezahlen“ zum Beispiel.
Aber wir wollen ja den Ablauf insgesamt
verfeinern, um ihn im Ergebnis so detailliert
zu beschreiben, dass eine Prozess-
Engine ihn ausführen kann, soweit das
sinnvoll ist. Mit diesem Prozessmodell ist
das jedoch unmöglich: Es beschreibt genau
einen Vorgang (eine Rechnung) und für
jede Rechnung wird die Aufgabe „Rech -
nung bezahlen“ ausgeführt. Es ist unmöglich,
in dieses Modell z. B. einen Teilprozess
„Rechnungen bezahlen“ einzufügen, der
erst am Monatsende ausgeführt wird.
Besser ausgedrückt, wäre es sogar möglich,
aber dieser Teilprozess würde genauso oft
ausgeführt, wie es eingehende Rechnungen
gibt, d. h. bei 20 Rechnungen pro Monat
wird am Monatsende zwanzigmal der
Teilprozess „Rechnungen bezahlen“ ausgeführt,
was wohl kaum im Sinne des
Erfinders wäre. Dieses Prinzip ist nicht verhandelbar
und es gilt auch nicht erst, seit es
BPMN gibt. Dahinter steckt das Paradigma
des Tokens, das nach einem eindeutig definierten
Schema durch ein Prozessmodell
läuft, egal ob es sich dabei um BPMN, EPK
oder eine andere „kontrollflussbasierte
Notation“ handelt (vgl. [All09]).
Ein weiteres Problem auf dem Weg zum
ausführbaren Modell betrifft die Unter -
scheidung zwischen dem „menschlichen“
und dem „technischen“ Fluss. Beginnen wir
mit der Annahme, dass der oben dargestellte
Prozess durch einen Workflow unterstützt
werden soll. Wir können die dargestellten
Aufgaben typisieren, um dar zu stellen, ob
eine Aufgabe manuell (eine Hand), als User-
Task (ein Torso) oder als Service-Task
(Zahnräder) ausgeführt wird. Manuelle
Aufgaben werden unabhängig von der
Prozess-Engine von Menschen erledigt,
User-Tasks sind Aufgaben, die ein Anwender
von der Prozess-Engine in seiner Aufgaben -
liste zugeordnet bekommt und dann erledigt
(typisches Human-Work flow-Management
also), und Service-Tasks werden direkt von
der Prozess-Engine ausgeführt, indem diese
eine Schnittstelle aufruft.
Während die Prozess-Engine sowohl
User- als auch Service-Tasks interpretiert,
überspringt sie manuelle Aufgaben während
der Ausführung. Wir kommen aber in
Verlegenheit, sobald wir innerhalb eines
Prozesses Entscheidungspunkte in Form
von Gateways haben, die mal von einem
Menschen und mal von einer Prozess-
Engine interpretiert werden sollen.
In dem in Abbildung 8 gezeigten Prozess
soll die Team-Assistenz eine erhaltene
Rechnung noch vor dem Scannen darauf
prüfen, ob sie bestimmten Anforderungen
genügt (z. B. ob sie eine vollständige An -
schrift enthält). Tut sie das nicht, muss eine
neue Rechnung angefordert werden. Nur
wenn die Rechnung in Ordnung ist, wird
sie gescannt und damit der technische
Workflow in Gang gesetzt. Das in Abbil -
dung 8 gezeigte Beispiel kann so nicht in
eine Prozess-Engine „deployed“ werden:
Abb. 8: Die Rechnung wird manuell geprüft, bevor der Workflow starten soll.
30 31

schwerpunkt
Abb. 9: Menschliche und technische Abläufe im Zusammenspiel
(Kollaborationsdiagramm).
Während die Engine die beiden rechten
Gateways interpretieren soll, um den Fluss
zu steuern, wird erwartet, dass sie das erste
Gateway ignoriert (zumal ein technischer
Prozess ja auch noch gar nicht gestartet
wurde). Ein Prozessfluss kann jedoch nur
entweder von einer Maschine (Prozess-
Engine) oder von einem Menschen kontrolliert
werden, was auch für jede Verfei -
nerung des Flusses gilt.
Eine mögliche Lösung dieses Problems ist
in Abbildung 9 dargestellt. In diesem
Kollaborationsdiagramm gibt es drei so
genannte Pools, in denen jeweils ein Pro -
zess enthalten ist. Der oberste Prozess
beschreibt das Verhalten der Team-Assis -
tenz, der mittlere Pool beschreibt den technischen
Workflow in der Prozess-Engine
und der unterste zeigt, dass die Ge -
schäftsführung am Monatsende alle fälligen
Überweisungen ausführen wird. Mit
dieser strikten Trennung von menschlichen
und technischen Flüssen können wir den
Prozess in Gänze betrachten, analysieren
und diskutieren und ihn gleichzeitig konsis -
tent und direkt in der Prozess-Engine
umsetzen, denn der mittlere Pool ist tatsächlich
ohne Transformation genauso
ablauffähig, wie er hier dargestellt wird.
In dem Beispiel wird auch der zweite
oben angeführte Grund für die Schwäche
Literatur & Links
des Verfeinerungsparadigmas deutlich: Der
Schritt „PDF archivieren“ wird automatisch
ausgeführt, kein Anwender ist daran
direkt beteiligt. Dass diese Datei archiviert
wird, ist aber nicht etwa der Wunsch eines
Softwareentwicklers, sondern eine fachliche
Anforderung. Sie muss also von der
Fachseite kommen, obwohl im mittleren
Pool doch scheinbar „nur“ die technische
Umsetzung beschrieben wird. Es ist
schlichtweg nicht möglich, das gezeigte
Kollaborationsdiagramm in einem gröberen
Diagramm zusammenfassen, ohne größere
Fehler im Token-Fluss in Kauf zu nehmen.
Das ist in der Praxis jedoch weniger
kritisch, als häufig angenommen wird.
Tatsächlich basiert unser methodisches
Framework zur Anwendung der BPMN,
das im „Praxishandbuch BPMN“ (vgl.
[Fre12]) beschrieben wird, auf genau dieser
Erkenntnis. Nichtsdestotrotz wird er -
kennbar, dass einige grundsätzliche Para -
digmen, die bislang in der Welt der
Prozessmodellierung galten, möglicherweise
infrage gestellt werden müssen.
Fazit
BPMN wird von vielen Unternehmen verschiedenster
Branchen sowie im öffentlichen
Dienst genutzt und ist in zahlreichen
Produkten implementiert. Als Kommunika -
tionsvehikel zwischen Business und IT
konnte sich der Standard trotz der zum Teil
verzögerten Umsetzung durch die Soft -
warehersteller bereits bewähren. Nicht s -
destotrotz befinden wir uns noch in einer
frühen Phase der Lernkurve und jede
gewonnene Erkenntnis wirft neue Fragen
auf dem jeweils nächsthöheren Niveau auf.
Insgesamt gibt es aber bereits ein großes
Ökosystem an Softwareherstellern, Bera -
tern, Anwendern und Wissenschaftlern, in
dem konkrete Lösungsansätze für das
Prozessmanagement sowohl für die fachliche
Prozessorganisation als auch für die
technische Prozessumsetzung auf Basis von
BPMN intensiv entwickelt, diskutiert und
getestet werden. Unterm Strich darf BPMN
insofern schon aus heutiger Sicht als eine
Erfolgsgeschichte bewertet werden, die
einen wichtigen Beitrag zur Weiterent -
wicklung der Informatik leistet. ■
[Act] Activiti, Activiti BPM Platform, siehe: Activiti.org
[All09] T. Allweyer, BPMN 2.0, Books On Demand, 2009
[BPM-a] BPM-Guide.de, BPMN 2.0 funktioniert, siehe: bpm-guide.de/2012/06/18/bpmn20-works/
[BPM-b] BPM-Guide.de, Page-Flow vs. Process-Flow – how a UI Mediator might help, siehe: bpmguide.de/2012/04/04/pageflow-vs-process-flow-and-ui-mediator-pattern
[BPM-c] BPM-Guide.de, Where is the „retry” in BPMN 2.0, siehe:
bpm-guide.de/2012/06/15/where-is-the-retry-in-bpmn-2-0/
[Cam-a] camunda, Prozessautomatisierung mit BPMN und Open Source, siehe:
camunda.com/references/1&1_de.pdf
[Cam-b] camunda, Prozessmodellierung und IT-Spezifikation mit BPMN 2.0, siehe:
camunda.com/references/bmf_de.pdf
[Fre12] J. Freund, B. Rücker, Praxishandbuch BPMN, Carl Hanser Verlag 2012
[Sti11] V. Stiehl, Systematisches Konstruieren von Verbundanwendungen unter Verwendung von
BPMN, TU Darmstadt 2011, siehe: tuprints.ulb.tu-darmstadt.de/2751/1/verbundanwendungen.pdf
6/2012

schwerpunkt
mehr zum thema:
hypersenses.com
die autorin
VOM SCHUSTER MIT
DEN GERADEN ABSÄTZEN:
DIE LÖSUNG DES
MDD-PARADOXONS
Generatoren und domänenspezifische Sprachen (DSLs) stellen zusammen mit Modellen zwar
die zentralen Elemente der modellgetriebenen Entwicklung dar, sie selber werden aber mit den
herkömmlichen Methoden paradoxerweise nicht modellgetrieben entwickelt. Daraus resultiert,
dass die Generator- und DSL-Entwicklung als zeitaufwändige und fehleranfällige Geheimwissen -
schaft gilt. In diesem Artikel stelle ich eine Lösung vor, mit der dieses Paradoxon behoben werden
kann und Aufwand und Komplexität deutlich reduziert werden können.
Dr. Daniela Schilling
(dschilling@d-s-t-g.com)
ist bei Delta Software Technology als
Programm-Manager mit dem Schwerpunkt
generative Entwicklung tätig.
Modelle und modellgetriebene Methoden
haben erfolgreich Einzug in die Software -
entwicklung gehalten. Sie gelten als
Garanten für Qualität, Effizienz und gute
Wartbarkeit, insbesondere wenn ähnliche
Aufgaben mehrfach gelöst werden müssen.
Das Lösen ähnlicher Aufgaben entspricht
dem Standardfall in der Softwareent -
wicklung. Beispiele dafür sind Funktionen
oder (Teil-)Anwendungen, die im Rahmen
einer neuen Anwendung mit Anpassungen
wiederverwendet werden, für mehrere
Kunden in unterschiedlichen Ausprägun -
gen verfügbar sein sollen, kontextabhängig
unterschiedliche Ausprägungen zeigen oder
für verschiedene Plattformen zur Verfü -
gung gestellt werden sollen.
Ein Sprichwort besagt, dass der Schuster
zwar die Schuhe anderer Leute flickt, selbst
aber schiefe Absätze trägt. Ähnlich verhält
es sich mit Generatoren und DSLs.
Die Grundlage für die modellgetriebene
Entwicklung stellen – neben den Modellen
– Generatoren und domänenspezifische
Sprachen (Domain Specific Languages,
DSLs) dar. Dabei gibt es zwei Mög -
lichkeiten, das Thema Generator und DSL
zu handhaben:
Vorgehensweise besteht darin, dass die
Generatoren und DSLs maßgeschneidert
für eine bestimmte Aufgaben -
stellung entwickelt werden und so ein
höherer Abstraktionsgrad erreicht werden
kann.
Bei der Entwicklung individueller Genera -
toren und DSLs mit herkömmlichen Me -
tho den, wie z. B. Template-basierten Ansät -
zen (ein Beispiel zeigt Abbildung 1), gilt es,
mehrere Hürden zu nehmen: Der Genera -
tor muss Daten aus einer Konfiguration,
also der Beschreibung, wie der Generator
parametrisiert werden soll, auslesen. Die
dazu notwenige Navigation muss manuell
entwickelt werden. Auf der anderen Seite
muss dafür gesorgt werden, dass die
Konfiguration alle Informationen bereithält,
die der Generator erwartet – und das
sowohl in der vom Generator erwarteten
Art und Weise, als auch an exakt der korrekten
Stelle. Sollen der Generator oder die
DSL, mittels der die Konfigurationen
beschrieben werden, verändert werden,
wirkt sich dies oft auch auf den jeweils
anderen Part aus.
Die Spezifikation oder Implementierung
eines Generators besteht in den meisten
Ansätzen aus einer Beschreibung des zu
generierenden Codes, einer Beschreibung,
wie die Codeanteile zusammenzufügen
sind, und verschiedenen Berechnungs vor -
schriften. Da diese drei Bestandteile bei
derartigen Ansätzen nicht strikt voneinander
getrennt, sondern stark miteinander
verwoben sind, ist die Spezifikation nur
schwer les- und wartbar. Soll der generierte
Code für Entwickler gut lesbar sein und
vielleicht auch noch vorhandene Unterneh -
■
■
Zum einen besteht die Möglichkeit, vorgefertigte,
universelle Generatoren und
DSLs zu verwenden. Ein Beispiel dafür
sind die vielen Generatoren, die Java-
Code aus UML-Modellen erzeugen.
Die zweite Möglichkeit besteht darin,
Generatoren und DSLs individuell zu
entwickeln. Der Vorteil dieser zweiten
1
)Das hier verwendete Beispiel wurde von Mykola
Dobrochynskyy in DotNetPro Ausgabe 02/2011 vorgestellt.
Abb. 1: Template-basierte Spezifikation eines Generators 1 ).
32 33

schwerpunkt
Für den bereits erwähnten Schuster ist es
klar, was er tun muss, um zu ordentlichen
Schuhen mit geraden Absätzen zu kommen.
Er muss nur seine eigenen Schuhe
genauso behandeln wie die seiner Kunden.
Ähnlich muss man auch mit dem MDD-
Paradoxon verfahren. Deshalb schlage ich
eine modellgetriebene Entwicklung von
Generatoren und DSLs vor, mit der die
zuvor aufgeführten Hürden beseitigt werden
können.
Abb. 2: Schematische Darstellung des Konzepts.
Modellgetriebene Entwicklung
von Generatoren und DSLs
Ein Generator wird immer dann benötigt,
wenn Varianten eines Systems oder eines
Teil systems entwickelt werden, also eine
System familie gebildet werden soll. Dabei
sollen neue Aufgaben einmal gelöst und
mensrichtlinien zur Programmierung erfüllen,
ist zusätzlicher Aufwand erforderlich.
Die Entwicklung einer DSL, die zum
Generator passt und darüber hinaus zu
einem späteren Zeitpunkt noch erweiterbar
ist, setzt viel Erfahrung in der Entwicklung
von Grammatiken voraus. Soll diese DSL
nicht nur von ihren Entwicklern, sondern
auch von weiteren Personen verwendet
werden, ist ein hoher Einarbeitungs -
aufwand erforderlich. Aus diesen und weiteren
Gründen gilt die Entwicklung von
Generatoren und DSLs als fehleranfällige
Geheimwissenschaft, für die erfahrene
Entwickler und viel Zeit erforderlich sind.
Hinzu kommt ein großer initialer
Entwicklungsaufwand für Generator und
DSL, bevor sie in Betrieb genommen, getes -
tet oder in den übrigen Entwicklungs pro -
zess integriert werden können. Das passt
aber nicht zu den in vielen Unternehmen
eingesetzten agilen Entwicklungsprozessen,
bei denen tägliche oder wöchentliche
Builds erforderlich sind.
Doch wie kommt es, dass Generatoren
und DSLs als Garanten für Effizienz und
Qualität gelten, ihre eigene Entwicklung
jedoch scheinbar so komplex ist? Ein Grund
ist meiner Meinung nach, dass Genera toren
und DSLs zwar selber Soft ware sind, sie aber
nicht mit modellgetriebenen Methoden entwickelt
werden. Diese Tatsache bezeichne
ich als das Model-Driven-Development-
Paradox (kurz MDD-Pa radoxon).
2
) Die generative Softwareentwicklung wird umfassend
in dem Buch „Generative Programming.
Methods, Tools, and Applications“ von Krzystof
Czarnecki und Ulrich Eisenecker beschrieben
(Addison-Wesley, 2000).
Die generative Softwareentwicklung zielt auf die weitgehend automatisierte Erstellung
von Softwaresystemen auf der Grundlage von Software-Systemfamilien.
Die Softwaresysteme einer Familie weisen eine gemeinsame, hoch flexible System -
architektur auf und werden überwiegend aus Softwarebausteinen, die zur Familie gehören,
erstellt. Bestimmte Softwarebausteine werden in allen Systemen einer Familie eingesetzt,
andere nur in einigen und einige spezielle Bausteine können für einzelne
Softwaresysteme ergänzt werden. Die Architektur bildet mit den Bausteinen den
Lösungsraum. Selbstverständlich können Softwaresysteme aus den einzelnen Bausteinen
gemäß der Architektur auch manuell erstellt werden. Hierfür sind jedoch tiefgehende
Kenntnisse der Architektur sowie der zugehörigen Bausteine erforderlich. Die manuelle
Erstellung ist daher zeitaufwändig und fehleranfällig.
Der Erstellungsprozess kann automatisiert werden, wenn eine domänenspezifische
Sprache vorliegt, mit deren Hilfe die gewünschten Softwaresysteme der Familie vollständig
und richtig beschrieben werden können. Eine domänenspezifische Sprache kann
textuell, dialogbasiert oder grafisch-interaktiv sein. Die domänenspezifische Sprache
umfasst den Problemraum.
Eine mit einer domänenspezifischen Sprache erstellte Spezifikation eines Software -
systems wird unter Verwendung von Konfigurationswissen automatisch vervollständigt,
analysiert, auf Baubarkeit getestet und je nach Bedarf optimiert. Anschließend kann das
System mit den gewünschten Eigenschaften automatisch erzeugt werden.
Die Bestandteile Problemraum, Konfigurationswissen und Lösungsraum bilden zusammen
das generative Domänenmodell. Es kann vorkommen, dass eine einzelne Domäne
so umfangreich und komplex ist, dass sie in Teildomänen zerlegt werden muss, oder dass
eine Softwaresystemfamilie mehrere Domänen umspannt. Dann werden mehrere generative
Domänenmodelle in geeigneter Weise miteinander verbunden, um die gewünschten
Systeme zu erstellen.
Die generative Softwareentwicklung umfasst zwei Kernprozesse: das Domain
Engineering und das Application Engineering. Im Domain Engineering wird festgelegt,
was genau zur Domäne gehört, die Domäne wird analysiert und es wird die gesamte
Infrastruktur zur Wiederverwendung einschließlich Systemfamilien-Architektur, Bau -
steinen und erforderlichen Werkzeugen erstellt. Das Application Engineering beginnt
mit der Analyse der Kundenanforderungen, die bei weitgehender Automatisierung mit
einer domänenspezifischen Sprache beschrieben werden, der Erzeugung des gewünschten
Systems, seinem Test und seiner Auslieferung. Äußert der Kunde spezielle Wünsche,
die bisher nicht abgedeckt sind, muss entschieden werden, ob das Domain Engineering
erneut durchlaufen wird. Andernfalls können die Kundenwünsche nicht auf der
Grundlage der Softwaresystem-Familie erfüllt werden.
Prof. Ulrich Eisenecker, Leipzig.
Kasten 1: Generative Softwareentwicklung. 2 )
6/2012

schwerpunkt
sich wiederholende oder ähnliche Aufga -
ben dann vom Generator übernommen
werden (dies entspricht dem Prinzip der
generativen Softwareentwicklung, siehe
Kasten 1). Um möglichst effiziente Genera -
toren und DSLs zu gewährleisten, werden
diese nicht universell einsetzbar, sondern
maßgeschneidert für eine bestimmte
Aufgabe entwickelt.
Das zu entwickelnde System – und damit
auch der Generator – stehen aber nicht im
luftleeren Raum, sondern sind Teil einer
Anwendungsdomäne, für die bestimmte
Eigenschaften bekannt sind. Häufig ergibt
sich die Notwendigkeit für einen Generator
nicht im ersten Schritt, sondern erst, nachdem
bereits eine Anwendung, ein Teil -
system oder ein Prototyp erstellt wurden.
Es ist sinnvoll, diese Implemen tierun gen bei
der Entwicklung des Generators wiederzuverwenden,
damit das in der Imple men -
tierung enthaltene Expertenwis sen nicht
verloren geht bzw. mühsam nachimplementiert
und erneut getestet werden muss. Die
folgenden Elemente sind Teil der hier vorgestellten
Lösung (siehe Abbildung 2):
■ Variabilitätsmodell: Programmier spra -
chenunabhängige Beschreibung der
Anwendungsdomäne.
■ Codemuster: Diese spezifizieren ge -
mein sam mit dem Variabilitätsmodell
den Generator.
■ Konfigurationsmuster: Diese spezifizieren
gemeinsam mit dem Variabi li täts -
modell die DSL.
■ Generator: Wird automatisch aus
Variabilitätsmodell und Codemustern
erzeugt.
■ DSL: Wird inklusive eines Parsers automatisch
aus Variabilitätsmodell und
Kon figurationsmustern erzeugt.
■ Konfiguration: Mittels DSL formulierte
Anforderungen an den Generator.
■ Generate: Ausgabe des Generators.
01 CREATE TABLE Person
02 (
03 Person_ID NUMBER(10) NOT NULL,
04 Name VARCHAR2(400),
05 ProjectRole VARCHAR2(400),
06 CONSTRAINT Person_PK PRIMARY KEY
(Person_ID)
07 );
08
09 CREATE TABLE WorkItem
10 (
11 WorkItem_ID NUMBER(10) NOT NULL,
12 Opened DATE,
13 Closed DATE,
14 Description VARCHAR2(400),
15 CONSTRAINT WorkItem_PK PRIMARY KEY
(WorkItem_ID)
16 );
Listing 1: Zwei beispielhafte PL/SQL-
Tabellen.
hat wiederum einen Namen und einen
Datentyp, wobei als Datentyp String,
Datetime und Integer zur Verfügung stehen.
Für diese Tabellen soll der entsprechende
Oracle-PL/SQL-Code generiert werden.
Zur Veranschaulichung der Konzepte wurde
die Aufgabenstellung vereinfacht (siehe
Listing 1).
Das Variabilitätsmodell
Das zentrale Element des Ansatzes ist das
Varia bilitätsmodell. Es stellt eine Form von
Metamodell dar, für das bestimmte Eigen -
schaften festgelegt sind (z. B. ist es strikt
hierarchisch). Das Variabilitätsmodell wird
aus den Eigenschaften der Anwendungs -
domäne abgeleitet und beschreibt die
Punkte, in denen sich die zu generierenden
Artefakte unterscheiden können. Es ist
vollständig unabhängig von der Program -
miersprache, die später generiert werden
soll. Es ist sogar möglich, dasselbe Variabi -
litätsmodell für verschiedene Programmier -
sprachen zu verwenden. Ein Variabilitäts -
modell setzt sich aus beliebig vielen
Meta klassen zusammen. Jede dieser Klas -
sen hat wiederum beliebig viele Features,
die die Eigenschaften der Klasse definieren.
Ich habe an dieser Stelle die UML als
Mo dellierungssprache für das Variabilitäts -
modell gewählt (siehe Abbildung 3). Dies
ist jedoch nur beispielhaft – andere Darstel -
lungsformen sind ebenso möglich.
Der Generator
Mittels Codemustern wird spezifiziert, wie
der zu generierende Code aussehen soll. Ein
Codemuster beschreibt einen Teilaspekt des
Generators. Der gesamte Generator wird
durch eine Menge von Codemustern be -
schrieben, die sich gegenseitig aufrufen und
auf diese Weise einen Aufrufbaum bilden.
Jedes Codemuster wird an eine Klasse aus
Die verschiedenen Artefakte werden im
Folgenden genauer betrachtet, zuvor wird
jedoch noch ein Beispiel für eine Gene -
rierungsaufgabe beschrieben, das ich zur
Veranschaulichung des Konzepts verwende.
Eine Generierungsaufgabe
Ein Beispiel für eine Generierungsaufgabe
ist die Erzeugung von Datenbank-Be -
schreibungen mit beliebigen Tabellen. Jede
Tabelle hat einen Namen und eine
bestimmte Anzahl von Spalten. Eine Spalte
Abb. 3: Variabilitätsmodell zum Tabellenbeispiel in Listing 1 als UML-Diagramm.
34 35

schwerpunkt
Abb. 4: Zwei Codemuster mit Verbindungen zum Variabilitätsmodell.
dem Variabilitätsmodell gebunden, diese
bildet dann den Kontext des Musters.
Die Codemuster können aus existierendem
Code oder Codefragmenten abgeleitet
werden. Dazu werden die Stellen im Code
identifiziert, die variieren können. Jede dieser
Stellen wird an ein Feature aus dem
Variabilitätsmodell gebunden. Außerdem
wird für jede der Stellen festgelegt, ob ein
Wert berechnet, ein Wert aus der Konfi -
guration ausgelesen, zur Erzeugung weiteren
Codes ein anderes Codemuster aufgerufen
oder ob dieses Stück Code nur unter
bestimmten Bedingungen ausgegeben werden
soll. Da auch Anteile der DSL mit den
Features verbunden werden, entsteht eine
Verbindung zwischen Generator und DSL,
aus der die Navigation automatisch abgeleitet
werden kann. Darüber hinaus ist im
Variabilitätsmodell für jedes Feature festgelegt,
ob dieses optional oder zwingend
erforderlich ist. Durch die Verbindung zwischen
den variablen Stellen und dem
Variabilitätsmodell wird somit auch festgelegt,
ob bestimmte Codestellen optional
oder zwingend erforderlich sind.
Für unser Beispiel benötigen wir zwei
Codemuster, CreateTable und CreateColumn,
die entsprechend ihren Namen an die
Metaklassen Table und Column gebunden
werden. Die Aufgabe von CreateTable
besteht darin, den Rahmen einer Tabelle zu
erzeugen. Dazu gehört das Festlegen des
Namens der Tabelle, der ID und des
Tabellenschlüssels. Als Codevor lage können
die Zeilen 01 bis 07 aus Listing 1 verwendet
werden. In diesem Muster sind der
Tabellenname und die Spalten variabel.
Statt des konkreten Tabellennamens wird
ein Platzhalter, hier tableName, verwendet.
Die entsprechenden Stellen werden mit
dem Feature name der Klasse Table verbunden.
Zudem wird definiert, dass der tatsächliche
Tabellenname bei der Gene -
rierung aus der Konfiguration ausgelesen
werden soll. Die Generierung der Spalten
erfolgt durch den Aufruf des Musters
CreateColumn. Der Aufruf ist mit
createColumns beschriftet und mit der
Komposition columns verbunden.
Trends und Innovationen im Software Engineering
Neues aus Wissenschaft und Praxis
Softwareforen-Jahrestreffen | 29. und 30. Januar 2013 in Leipzig
Aus dem Vortragsprogramm:
Lothar Engelke, Geschäftsführer Infrastruktur (ITERGO Informationstechnologie GmbH):
Infrastruktur 2020 – Wohin geht die Reise?
Prof. Dr. Andreas Gadatsch (Hochschule Hochschule Bonn-Rhein-Sieg):
Der CIO wird abgeschafft!? – Aktuelle Trends zum Informations- und Prozessmanagement
Dr. Thorsten Weyer, Head of Requirements Engineering (paluno - Universität Duisburg-Essen):
Von Geistersehern, Tagträumern und Weisen – Überlegungen zum agilen Requirements Engineering
Alle Informationen auf www.softwareforen.de/goto/jahrestreffen

DSL und Konfiguration
Um eine Konfiguration beschreiben zu
können, wird eine DSL benötigt. Die
Grammatik der DSL ergibt sich automatisch
aus dem Variabilitätsmodell. Mittels
der hier vorgestellten Lösung können zwei
Darstellungsformen von DSLs erzeugt werden.
Zum einen kann eine klassische Text-
DSL erzeugt werden und zum anderen eine
Formular-DSL. Letztere ähnelt in Aussehen
und Bedienung einem elektronischen
Bestellformular. Aufgrund ihrer einfachen
Bedienbarkeit, auch für Nicht-Experten,
betrachten wir im Folgenden Formular-
DSLs.
Die DSL wird ebenfalls mit Hilfe von
Mustern – den Konfigurationsmustern –
spezifiziert, die mit Metaklassen verbunden
werden. Ein Konfigurationsmuster kann
zum einen erläuternden Text enthalten.
Dieser Text wird später der Person angezeigt,
die die Konfiguration mittels der DSL
erzeugt. Der Text kann zum Bespiel
beschreiben, welche variablen Stellen exis -
tieren, ob diese zwingend einen Wert enthalten
müssen oder ob sie optional sind.
Zum anderen kann ein Konfigurations -
muster eine Beschreibung von Eingabe -
feldern enthalten, in die Text eingeben werden
kann, eine Auswahlliste spezifizieren
oder einen Aufruf eines anderen Konfigura -
tionsmusters enthalten, um weitere
Konfigurationsmöglichkeiten zu spezifizieren.
Die Felder werden, wie die variablen
Stellen der Codemuster, mit Features des
Variabilitätsmodells verbunden. Auf diese
Weise wird die Verbindung zwischen dem
Generator und der DSL einfach spezifiziert
und muss nicht mühsam implementiert
werden (siehe Abbildung 6).
Der Einfachheit halber habe ich für das
Tabellenbeispiel zu jeder Klasse ein Konfi -
gurationsmuster angegeben, eine solche
1:1-Beziehung ist jedoch kein Muss (siehe
Abbildung 7).
Wie im Fall des Generators gilt auch hier:
Das Variabilitätsmodell und die Konfigura -
tions muster enthalten alle nötigen Informa -
tionen, um die DSL automatisch zu erzeuschwerpunkt
Das Codemuster CreateColumn enthält
zunächst den Spaltennamen als variable
Stelle. Diese ist mit dem Feature name der
Klasse Column verbunden, der tatsächliche
Name soll aus der Konfiguration ausgelesen
werden. Neben dem Namen der Spalte
muss noch ihr Datentyp festgelegt werden.
Da das Variabilitätsmodell unabhängig von
der Programmiersprache ist, enthält die
Aufzählung Datatype im Variabilitäts -
modell andere Bezeichner, als in Oracle
PL/SQL benötigt, weshalb nicht einfach der
in der Konfiguration ausgewählte Datentyp
ausgegeben wird. Stattdessen werden
Codeblöcke verwendet, die den auszugebenden
Code enthalten. Bedingungen definieren,
wann der jeweilige Block ausgegeben
werden soll. Beispielsweise soll
VARCHAR2 (400) immer dann ausgegeben
werden, wenn als datatype in der
Konfiguration String ausgewählt wurde. Da
es sich bei datatype um ein Feature der
Klasse Column handelt, besteht auch hier
wieder eine Verbindung zum Variabilitäts -
modell.
Die 1:1-Beziehung im Tabellen beispiel –
jeweils ein Muster zu einer Metaklasse –
sowie das Beibehalten der Hierarchie, hängen
mit dem stark vereinfachten Beispiel zusammen.
In komplexeren Anwendungen ist diese
Beziehung nicht zwangsläufig gegeben.
Wenn Sie sich die Muster in Abbildung 4
ansehen, werden Sie feststellen, dass im
Muster weder Operationen, Bedingungen,
noch Berechnungsvorschriften enthalten
sind, die nur zur Codegenerierung benötigt
werden (zum Vergleich siehe Abbildung 1).
So enthalten die Muster beispielsweise keine
Push- und Pop-Operationen zur Ein -
rückung – stattdessen wird der Code an
genau der Stelle generiert, an der er im
Muster angezeigt wird bzw. an der die variable
Stelle im Muster angezeigt wird. Die
Berechnungsvorschriften, also z. B. welcher
Wert aus der Konfiguration ausgelesen
werden soll, oder Bedingungen, wann ein
Codeblock generiert werden soll, sind in
den Eigenschaften der jeweiligen variablen
Stelle enthalten. Abbildung 5 zeigt die
Abb. 5: Eigenschaften eines Codeblocks.
Eigenschaften des Codeblocks, der mit
VARCHAR2 (400) beschriftet ist. Auf diese
Weise wird das WYSIWYG-Prinzip konsequent
umgesetzt und die Lesbarkeit des
Musters und damit der Generator-
Spezifikation signifikant verbessert.
Variabilitätsmodell und Codemuster enthalten
zusammen alle nötigen Informatio -
nen, um einen Generator automatisch zu
erzeugen. Durch die Verbindung der
Codemuster mit dem Variabilitätsmodell
kann die Navigation automatisch abgeleitet
werden. Sobald ein Teil des Variabi -
litätsmodells und der Codemuster erstellt
wurde, kann bereits ein Generator erzeugt
werden. Es ist nicht notwendig, zunächst
die vollständige Spezifikation zu erstellen.
Stattdessen können die noch fehlenden
Anteile anschließend nach und nach hinzugefügt
werden. Auf diese Weise stehen
innerhalb kürzester Zeit verwendbare
Generatoren zur Verfügung. Wöchentliche
oder gar tägliche Builds sind kein Problem,
sodass sich die Entwicklung des Generators
ohne weiteres in einen agilen Entwick -
lungs prozess integrieren lässt.
Noch einen Vorteil bietet dieses Vor -
gehen: Die Spezifikation des Generators
wird aus existierendem Code abgeleitet.
Der generierte Code sieht nahezu genauso
aus wie der Ursprungscode. Auf diese
Weise kommen implementierungstechnische
Finessen und Optimierungen auch in
den Generaten zum Tragen. War der
Ursprungscode lesbar, so gilt dies auch für
den generierten Code. Außerdem ist es auf
diese Weise möglich, unternehmensspezifische
Programmier-Richtlinien auch durch
den generierten Code einzuhalten.
Abb. 6: Verbindung zwischen Konfigurations- und Codemuster via Variabilitätsmodell.
36 37

schwerpunkt
Abb. 7: Konfigurationsmuster des Tabellenbeispiels.
gen. Das gilt insbesondere für die Gram -
matik der DSL, die nicht explizit entwickelt
werden muss, sondern automatisch aus
dem Variabilitätsmodell abgeleitet werden
kann, da das Variabilitätsmodell implizit
die Menge aller zulässigen (Teil-)Gram -
matiken darstellt. Sobald Variabi li täts -
modell und Konfigurationsmuster teilweise
erstellt wurden, kann die DSL erstellt werden.
Somit steht auch innerhalb kürzes ter
Zeit eine (Teil-)DSL zur Verfügung und die
DSL-Entwicklung lässt sich problemlos in
einen agilen Entwicklungsprozess integrieren.
Die Formular-DSL
Aus den Konfigurationsmustern und dem
Variabilitätsmodell kann automatisch eine
Formular-DSL erzeugt werden, die einem
elektronischen Bestellschein ähnelt. Sie ist
einfach zu handhaben, sodass auch für
Nicht-Experten keine langwierige Einarbei -
tung erforderlich ist. In einem solchen
Formular werden Instanzen von zwingend
erforderlichen Klassen und Features automatisch
eingefügt, weitere können hinzugefügt
und mit Default-Werten gefüllt werden.
Durch die Spezifikation mittels
Variabilitäts modell und Konfigurations -
muster wird sichergestellt, dass nur Werte
eingegeben werden können, die auch vom
Generator verarbeitet werden können. Eine
so erzeugte Konfiguration entspricht dann
einer Instanz des Variabilitätsmodells.
Aufgrund ihrer Struktur kann man eine
solche Konfiguration als XML-Dokument
speichern. Dies hat den Vorteil, dass man
sie auch leicht mit anderen Werkzeugen
austauschen kann.
Noch mehr Wiederverwendung
Generatoren und DSLs werden eingesetzt,
um Varianten einer Funktion oder eines
Produkts zu erzeugen. Aber auch bei der
Spezifikation von Generator und DSL müssen
häufig ähnliche Aufgaben oder Funk -
tionen beschrieben werden. Um den Auf -
wand für die Spezifikation zu reduzieren,
schlage ich – neben der Wiederverwendung
von existierendem Code – die Verwendung
von Vererbungsmechanismen vor. Es sind
drei Arten von Vererbung möglich:
■ Vererbung auf Variabilitätsmodell-Ebene
■ Mustervererbung
■ Frame-Vererbung
Abb. 8: Konfiguration der beiden Beispieltabellen.
Auf Variabilitätsmodell-Ebene wird Verer -
bung eingesetzt, um ähnliche Metaklassen
zu erzeugen. Mustervererbung kommt
immer dann zum Einsatz, wenn zwei
Muster erzeugt werden sollen, die eine ähnliche
Aufgabe, aber unterschiedliche Kon -
texte haben. Soll eine Funktion oder ein
Produkt in mehreren Implementierungs -
varianten verfügbar sein, z. B. für verschiedene
Plattformen, Programmiersprachen
oder in unterschiedlichen Ausprägungen
für mehrere Kunden, besteht die Mög -
lichkeit, mehrere so genannte Frames in -
nerhalb eines Musters zu erzeugen. Jeder
dieser Frames beschreibt eine Implemen -
tierungsvariante, alle Frames innerhalb
eines Musters haben den gleichen Kontext.
Für jede Implementierungsvariante wird
ein Generator erzeugt. Da das Variabi -
litätsmodell und die DSL programmiersprachenunabhängig
sind, muss die DSL
nicht verändert werden. Tatsächlich kann
eine Konfiguration für alle durch die Ver -
erbung entstandenen Generatoren verwendet
werden.
Für Muster- oder Frame-Vererbung wird
zunächst ein Muster bzw. Frame, wie oben
beschrieben, erzeugt. Weitere Muster oder
Frames entstehen dann durch Vererbung.
Unterschiede zwischen dem vererbenden
und dem erbenden Muster/Frame entstehen
durch die Überschreibung der relevanten
Merkmale. Wird anschließend das vererbende
Muster/Frame verändert, so werden
diese Änderungen auch an die erbenden
Muster/Frames weiter gegeben, falls das
entsprechende Feature nicht überschrieben
wurde.
Der oben beschriebene Tabellengenera -
tor generiert PL/SQL-Tabellen. Soll zusätzlich
auch MySQL generiert werden, benötigt
man dazu einen entsprechenden
Generator. In dem hier vorgestellten Ansatz
lässt sich dieser zweite Generator ganz einfach
durch Vererbung erzeugen. In beiden
6/2012

schwerpunkt
Codemustern werden neue MySQL-Frames
angelegt, die vom existierenden PL/SQL-
Frame erben. Der Code für PL/SQL und
MySQL unterscheidet sich hier nur in den
möglichen Datentypen. Während in
PL/SQL VARCHAR2 zum Einsatz kommt,
wird an dieser Stelle in MySQL TEXT verwendet.
Nur im Muster CreateColumn müssen
Überschreibungen vorgenommen werden,
das Muster CreateTable kann so
beibehalten werden – fertig ist der zweite
Generator. Abbildung 9 zeigt das Muster
CreateColumn mit seinen beiden Frames.
Wird diesem Generator nun die in Ab -
bildung 8 dargestellte Konfiguration übergeben,
werden beide Tabellen als MySQL-
Code generiert.
Vererbung lässt sich nicht nur bei der
Spezifikation des Generators einsetzen –
das gleiche Prinzip kann man auch auf die
Konfigurationsmuster anwenden. Auf diese
Weise können die Vererbungsmechanismen
auch die Entwicklung der DSL vereinfachen.
Anwendungsgebiete
Eine Einschränkung des hier vorgestellten
Ansatzes auf ein bestimmtes Anwendungs -
gebiet gibt es nicht. Der Generator und die
dazugehörige DSL können perfekt auf die
jeweiligen unternehmens- und projektspezifischen
sowie technischen Anforderungen
zugeschnitten werden. Die Verwendung der
Codemuster bietet gleich mehrere Vorteile:
Zum einen kann beliebiger Code als
Vorlage dienen, sodass es keine Einschrän -
kung bezüglich der zu generierenden Pro -
grammiersprache gibt. Zum anderen werden
bewährte Optimierungen, z. B.
Speicher platz-Optimierungen, wiederverwendet.
Damit kann sichergestellt werden,
dass auch der generierte Code die Opti -
mierungsmaßnahmen umsetzt. Darüber
hinaus wird so das Expertenwissen auch
allen anderen Entwicklern des Teams zur
Verfügung gestellt.
Ebenso gibt es keine Begrenzungen für die
Größe der zu lösenden Aufgabe, denn der
Ansatz skaliert sowohl für kleine (Teil-)
Aufgaben als auch für große und komplexe
Systeme.
Die hier vorgeschlagene Formular-DSL
ist auch von Nicht-Experten ohne großen
Abb. 9: Codemuster mit den zwei Frames PL/SQL und MySQL.
Einarbeitungsaufwand bedienbar, da sie
einem elektronischen Bestellformular
ähnelt. Auf diese Art ist eine Aufgaben -
teilung möglich: Die Entwicklungs abtei -
lung erstellt den Generator und die passende
DSL, eine Fachabteilung kann dann die
für sie geeignete Konfiguration vornehmen.
Wir haben dieses Vorgehen verwendet,
um tausende von Service-Adaptern und
SQL-Anwendungen zu generieren, die nun
erfolgreich bei unseren Kunden im Einsatz
sind. Genauso kann die Methode zur
Generierung von eingebettetem Code angewendet
werden, um Mobile-Apps zu erzeugen
oder große Anwendungen zu generieren.
Der Gewinn
Stellt man die Vorteile modellgetriebener
Entwicklung nicht generell in Frage, so sind
diese auch auf die Entwicklung von
Generatoren und DSLs übertragbar. Zu
den Vorteilen gehört, dass die Entwicklung
auf ein höheres Abstraktionslevel gehoben
wird: Statt zu programmieren, werden
Generator und DSL deklariert. Die konsequente
Umsetzung des WYSIWYG-Prinzips
steigert die Lesbarkeit der Spezifikationen,
was die Entwicklung und Wartung erleichtert.
Zudem kann der Testaufwand reduziert
werden. Die strikte Trennung von
Variabilitätsmodell und Mustern verbessert
zum einen die Wartbarkeit des Systems und
ermöglicht zum anderen aber auch eine
verteilte Entwicklung.
Aufgrund des geringen Initialaufwands
skaliert der Ansatz für Aufgaben jeglicher
Größe. Selbst kleine Aufgaben, wie das
zuvor gezeigte Tabellenbeispiel, können
effizient gelöst werden. Zudem ist es jederzeit
möglich, weitere Klassen und Features
sowie Muster hinzuzufügen und das
System so zu einem großen und komplexen
System auszubauen. Es ist also nicht notwendig,
schon zu Beginn der Entwicklung
alle Anforderungen an Generator und DSL
zu kennen.
Der zweite Effekt des geringen Initial -
aufwands besteht darin, dass sich die vorgestellte
Methode bereits dann lohnt, wenn
es nur zwei Varianten des (Teil-)Systems
geben soll. Durch die Erweiterbarkeit von
Variabilitätsmodell, DSL und Generator ist
es unerheblich, ob von vornherein feststeht,
dass mehrere Varianten benötigt werden
und generative Methoden zum Einsatz
kommen sollen, oder ob sich dies erst herausstellt,
wenn bereits eine Variante produktiv
ist.
Vom Schuster mit
den geraden Absätzen
Individuell entwickelte Generatoren und
DSLs erhöhen den Abstraktionsgrad der
Softwareentwicklung. Mit der hier vorgestellten
Lösung können durch die Ver -
knüpfung der Generator- und DSL-
Spezifikation mit einem Variabilitätsmodell
Informationen, wie die Grammatik der
DSL oder die Navigation des Generators,
automatisch abgeleitet werden und müssen
nicht, wie in klassischen Ansätzen, mühsam
erarbeitet werden. Dieses Vorgehen
löst das MDD-Paradoxon und ermöglicht
so die Nutzung der Vorteile modellgetriebener
Methoden bereits bei der Ent -
wicklung von Generatoren und DSLs.
Außerdem können bewährte und getestete
Implementierungen einfach zur Spezifika -
tion maßgeschneiderter Generatoren
wieder verwendet werden. Aus der zeitaufwändigen
und fehleranfälligen Geheim wis -
senschaft wird so eine weit weniger komplexe
Entwicklungsaufgabe, die sich auch
leicht in agile Entwicklungsprozesse integrieren
lässt.
■
Das Fundament für Softwarearchitekten –
vertiefen Sie Ihr Know-how!
www.sigs-datacom.de/wissen/themenchannel/software-architektur.html
38 39

schwerpunkt
der autor
MODELLGETRIEBENE SOFTWARE-
ENTWICKLUNG IN EINEM
GROSSPROJEKT:
EIN PRAXISBERICHT ÜBER DEN
ERFOLGREICHEN EINSATZ VON MDD
Die Vorteile von MDD sind bekannt: erhöhte Produktivität durch Automatisierung sowie verbesserte
Qualität und Wartbarkeit, um nur die wichtigsten zu nennen. Wie Modelltransforma -
tionen funktionieren und welche Werkzeuge es gibt, beschreiben thematisch verwandte Artikel.
Aber wie funktioniert der MDD-Ansatz in einem realen Großprojekt? Dieser Artikel befasst sich
mit der MDD-Vorgehensweise in der Praxis und stellt aus den gemachten Erfahrungen eine
Reihe von Bausteinen vor, die zu einem erfolgreichen Einsatz von MDD führen. Dabei steht
nicht nur Technologie im Vordergrund, sondern es werden auch Prozessfaktoren und organisatorische
Faktoren mit einbezogen.
Benedikt von Treskow
(benedikt.vonTreskow@credit-suisse.com)
ist Solution Architekt bei der Credit Suisse AG und
verantwortlich für Architektur und Design von serviceorientierten
JEE-Applikationen. Seine
Schwerpunkte sind die Konzeption und Umsetzung
von modellgetriebenen Entwicklungsmethoden.
Im Folgenden stelle ich kurz das Projekt
vor, um das es in diesem Artikel geht, und
erläutere die Beweggründe, weshalb in der
Initiierungsphase des Projekts der modellgetriebene
Weg eingeschlagen wurde. Die
Motivation für eine modellgetriebene
Softwareentwicklung (Model Driven
Development, MDD) lässt sich auf andere
ähnliche Projekte übertragen. Anschließend
beschreibe ich die wichtigsten Bausteine
näher und gehe auf die Lektionen ein, die
wir bei der Einführung und Verwendung
modellgetriebener Methoden gelernt ha -
ben. Eine vollständige Auflistung aller
Faktoren ist aus Platzgründen nicht möglich.
Abschließend gehe ich der Frage nach,
wie MDD mit agilem Vorgehen kombiniert
werden kann und welche Herausfor derun -
gen dabei bestehen.
Das Projekt
Die in diesem Artikel geschilderten Erfah -
rungen stammen aus einem mehrjährigen
Modernisierungsprojekt, das ein in die
Jahre gekommenes Kernsystem auf einer
modernen SOA-Plattform neu implementiert.
Dabei geht es nicht um eine Code-zu-
Code-Migration, sondern um den Entwurf
einer von Grund auf neuen Architektur für
ein dezentrales System, das sich mit unterschiedlichen
Schnittstellen-Technologien in
die Applikationslandschaft einfügt.
In einem Vorprojekt wurden bereits
modell getriebene Ansätze gewählt, um das
Altsystem nachzudokumentieren sowie
Systemstrukturen und Abhängigkeiten zu
analysieren. Ziel war dabei die möglichst
vollständige Erfassung der bestehenden
Funktionalität sowie die Planung des mehrjährigen
Migrationsvorgehens.
Zu den bestehenden Anforderungen des
Ist-Systems werden durch die Optimierung
der Geschäftsprozesse zusätzliche Anfor -
derungen erhoben. Doch nicht nur funktionale,
sondern auch hohe nicht-funktionale
Anforderungen, wie Performance und
hohes Transaktionsvolumen, die für
zukünftige Ansprüche auch nach oben skalierbar
sein müssen, sind Herausfor derun -
gen für das Projekt. Ein solches Moderni -
sierungsvorhaben ist nur mit einem großen
Team zu bewerkstelligen. Circa 80
Projektmitglieder arbeiten gemein sam an
der Lösung vielfältiger Aufgaben.
Die MDD-Methode wurde in drei
Phasen schrittweise eingeführt (siehe Abbil -
dung 1). Zu Beginn entwickelte das
Architekturteam eine Referenzapplikation.
In dieser wurden diverse technische Proto -
Abb. 1: Einführung von MDD im Projekt.
typen vereint, um die Architektur zu verifizieren
und generierbare Teile zu identifizieren.
Die Referenzapplikation diente später
als Testumgebung und Hilfsmittel für das
Einlernen neuer Teammitglieder.
In der zweiten Phase wurde die MDD-
Werkzeugkette finalisiert und darauf basierend
das erste Applikations-Release 0.5 mit
einem kleineren Entwicklerteam verwirklicht.
Ziel war es dabei, die End-to-End-
Mach barkeit der modellgetriebenen Me -
tho de zu prüfen und die Werkzeugkette für
das Aus rollen auf ein größeres Team vorzubereiten.
Meilensteine der dritten Phase waren die
Verwendung der MDD-Werkzeugkette im
gesamten Team inklusive Offshore-
Mitarbeitern und die erfolgreiche Lieferung
des folgenden Applikationsrelease 1.0.
Aktuell ist die MDD-Werkzeugkette im
Wartungsmodus und bildet die Basis für
zukünftige Releases.
6/2012

schwerpunkt
Treiber für den MDD-Einsatz
Im Folgenden werden die Treiber des konkreten
Projekts erläutert, weshalb eine
modellgetriebene Vorgehensweise gewählt
wurde. Die hier genannten Gründe sind
nicht projektspezifisch, sondern bekannte
Gegebenheiten in vergleichbaren Projekten.
Wartbarkeit und Langlebigkeit
Für das zu entwickelnde System wird eine
lange Lebenszeit erwartet, sodass hohe
Anforderungen an die Wartbarkeit gestellt
werden. Dies gelingt nur durch eine stets
aktuelle Dokumentation des Systems, die
durch Modelle (=Dokumentation) und den
Einsatz von Codegeneratoren immer synchron
mit der Implementierung gehalten
wird.
Die Erfahrung mit dem Altsystem hat
gezeigt, dass eine vernachlässigte Doku -
men tation zu schwerer Wartbarkeit führen
kann. Sehr aufwändig sind Re-Doku -
mentationen und Analysen, die immer
durch Abstraktion (modellbasiert, grafische
Abhängigkeiten) bewerkstelligt werden.
Durch MDD wird diese Abstraktion
von Anfang an gelebt und dadurch eine
hohe Qualität der Dokumentation erreicht
(Document-first). Modelle stellen nicht das
einzige Dokumentationsmedium dar. Sie
bieten aber immer einen Einstiegspunkt in
das System und referenzieren weiterführende
technische Dokumentation.
Kommunikation in verteilten Teams
Auch wenn es der Idealzustand wäre, dass
alle Projektmitglieder in einem Raum
arbeiten, sind die Teams in derartigen
Projekten zum Teil global verteilt. Häufig
werden Anforderungen und Geschäfts -
prozesse von einem Team spezifiziert, während
ein anderes Team Design und Imple -
mentierung übernimmt.
Die Größe des Projektteams erfordert
präzise Spezifikationen. Vor allem in
Offshore-Szenarien können durch den
Einsatz von MDD Anforderungen eindeutig
beschrieben werden. Durch Modelle
wird eine gemeinsame Sprache definiert,
die durchgängig nachvollziehbar ist – von
den Anforderungen, über das Design bis
hin zum Code. Die durch MDD herbeigeführte
Abstraktion ermöglicht es, Fach -
exper ten einzubeziehen, die nicht unbedingt
die eingesetzte Zieltechnologie
beherrschen müssen.
Automatisierung
Die mehrjährige Laufzeit des Projekts
erfordert ein einheitliches Vorgehen auf der
vorgegebener Architektur. Zwar müssen
Korrekturen (Refactorings) auch an der
Architektur möglich sein, der grundlegende
Architekturstil (z. B. Schichtenmodell) so -
wie eingesetzte Muster und Frameworks
werden jedoch zu Beginn definiert und
nicht jedes Jahr neu festgelegt.
Im Sinne der „Software-Industriali -
sierung“ (vgl. [Zie10]) errichtet man mit
MDD eine Fertigungsstraße, auf der in
geteilten Arbeitsschritten Anforderungen
spezifiziert sowie Design und Implemen -
tierung erstellt werden. Die Architekturund
Design-Richtlinien werden von Anfang
an durch Codegenerierung durchgesetzt,
sodass sich die Entwickler auf das Wesent -
liche, nämlich die Implementierung der
Fachlogik, konzentrieren können.
Technologische Bausteine
„Out of the box“ eignen sich MDD-
Werkzeuge nur bedingt für den produktiven
Einsatz. Üblich ist die Anpassung von
MDD-Generatoren an die Gegebenheiten
der Zielplattform sowie an die Architekturund
Unternehmensstandards, wie beispielsweise
die Verwendung existierender Frame -
works oder Code-Richtlinien.
In diesem Abschnitt beschreibe ich die
wesentlichen technologischen Bausteine für
die Erstellung bzw. Anpassung eines
Generator-Frameworks.
Domänenspezifische Sprache
Die Definition eines Metamodells ist die
Basis der domänenspezifischen Sprache
(Domain Specific Language, DSL) und bildet
ein eindeutiges Verständnis und ge -
mein sames Vokabular für die Ziel archi -
tektur. Die Erstellung des Meta modells ist
typischerweise ein iterativer Prozess. Zu
Beginn steht ein konzeptioneller Entwurf
(Blueprint), der dann in weiteren Schritten
stetig verfeinert wird.
In Abbildung 1 zeigen die Schritte 1 und 2
exemplarisch, wie das konzeptionelle,
schichtenbasierte SOA-Modell „Archi -
tektur Blueprint“ in das „Formale Meta -
modell“ überführt wird. Im Projektbeispiel
wurden im Blueprint zuerst die Schichten
konzipiert, beispielsweise: Wo finden
Input/Output-Mapping und Validierung
statt? Wo werden Business-Regeln ausgeführt?
Wo werden Datenzugriffe implementiert
oder externe Systeme aufgerufen?
Während der Verfeinerung zum „Formalen
Metamodell“ werden dann konkrete
Elemente auf den Schichten spezifiziert
sowie deren Attribute und Abhängigkeiten
untereinander. Hier werden beispielsweise
spezifische Servicetypen definiert (Daten -
bank, Regelausführung, externer Aufruf
usw.) und deren Eigenschaften beschrieben.
Einerseits ist es wichtig, das Metamodell in
einen stabilen Zustand zu bringen (häufige
Änderungen könnten sich später negativ
auf den Entwicklungsprozess auswirken),
andererseits sollte das Metamodell so entworfen
werden, dass erforderliche Erwei -
terungen flexibel vorgenommen werden
kön nen.
Abbildung 2 zeigt das Metamodell als
Bestandteil der 3. Transformationskette. Es
ist die Grundlage für den Model lierungs stil
(konkrete Syntax, z. B. durch Ableitung
eines UML-Profils) und wird durch die
Modell-zu-Modell-Transforma tion instanziiert.
Die Generator-Templates beziehen
sich auf das Metamodell und sind UMLfrei.
Abb. 2: Vom Architektur-Blueprint, über das Metamodell zur Transformationskette.
Verhältnis generierter/manuell
geschriebener Code
Es hängt stark von der Applikationsart und
der eingesetzten Programmiersprache ab,
wie viel Code generiert werden kann.
Sicher gibt es Plattformen, auf denen
100 % Codegenerierung möglich und
erwünscht ist (z. B. eingebettete Systeme).
40 41

schwerpunkt
Schicht Generierte Manuell erstellte Generierter
Elemente Elemente Anteil
Adapter JEE-Beans Mapping-Klassen 50 %
(MDB, SessionBeans)
Business-Services / Java-Interfaces Konkrete Klassen 40 %
Compound-Services Abstrakte Klassen
Basis-Services
Service-Orchestrierung Java-Klassen – 100 %
Datenmodell JPA-Entitäten – 100 %
Unit-Tests JUnit-Tests Testdaten-Instanzen 70 %
(Infrastruktur-Code)
Tabelle 1: Auszug generierte Anteile.
Im Rahmen von Geschäftsapplikationen ist
eine vollständige Generierung nicht das
Ziel. Das würde die Komplexität der Busi -
ness-Logik lediglich auf die Modellebene
heben, aber nicht davon abstrahieren.
Tabelle 1 listet generierte und manuell
erstellte Anteile auf den jeweiligen Schich -
ten auf.
Die hier gezeigten strukturellen Code -
bestandteile zählen eher zum MDD-
Standard-Repertoire. Im Folgenden hebe
ich die Service-Orchestrierung hervor, mit
der wir im Projekt sehr gute Erfahrungen
machen. Die Service-Orchestrierung stellt
die Implementierung eines Compound
Service dar (Definition aus [Jos08], häufig
wird der Begriff Micro-Flow äquivalent
verwendet). Dieser fasst durch eine Aufruf -
kette interne Basis-Services in einer Trans -
aktion zusammen.
Team Empowerment
Pair Programming
Test Driven Development
TRAINING
Abbildung 3 zeigt ein Beispiel für eine
Service-Orchestrierung. Jede Aktion stellt
einen Verarbeitungsschritt dar, in dem
Basis- oder weitere Compound-Services
auf gerufen werden (z. B. Daten validieren,
Daten anreichern, Daten weitersenden).
Der hierfür angepasste Modellierungsstil
ist auf wenige Elemente beschränkt. Da -
durch werden die Ablauf-Diagramme nicht
für Verhaltensprogrammierung missbraucht,
sondern bleiben auf einer fachlichen
Ebene, während algorithmische
Details im Code implementiert werden.
Diagramme wie das in Abbildung 3 werden
im Projekt auch von technologiefernen
Rol len verwendet, um die fachliche Kor -
rekt heit zu verifizieren.
Die vollständige Generierung der
Service-Orchestrierung ist ein gutes Beispiel
dafür, wie die Dokumentation mit der
Imple mentierung vollkommen synchron
gehalten wird.
Frühe Modellvalidierung
Häufig bieten Generator-Frameworks eine
integrierte Validierungs-API an, sodass
während der Codegenerierung die Eingabe-
Modelle auf Korrektheit geprüft werden
Clean Code
Spring
Sprint Burndown
Continuous Integration
Bob Martin Dr. Peter Hruschka Fahd Al-Fatish
Detlef Buder
5.–6.11.2012 PSPO mit Fahd Al-Fatish Frankfurt/M.
8.–9.11.2012 PSM mit Fahd Al-Fatish Frankfurt/M.
4.–5.2.2013 Clean Code mit Bob Martin Karlsruhe
6.–8.2.2013 Advanced TDD mit Bob Martin Karlsruhe
21.–22.2.2013 PSPO mit Fahd Al-Fatish Karlsruhe
25.2.2013 Scrum Basics mit Detlef Buder Karlsruhe
26.–27.2.2013 Agiles Requirements Engineering mit Dr. Peter Hruschka Frankfurt/M.
Bei Angabe von »OBJEKTspektrum« bei der Anmeldung unter »Bemerkungen« erhalten Sie 5% Rabatt auf die Teilnahmegebühr.
www.andrena.de
andrena objects ag · Albert-Nestler-Straße 9 · 76131 Karlsruhe
Telefon 0721 6105-122 · Telefax 0721 6105-140 · veranstaltungen@andrena.de
Experts in agile software engineering

schwerpunkt
Kategorie
Vollständigkeit
Korrektheit
Konvention
Beispielregel
Ist Modellelement dokumentiert?
Sind Typen an Datenattributen definiert?
Sind Typen an Serviceparametern definiert?
Referenzieren Datenattribute korrekte Typen
(z. B. referenziert eine Entität kein Datentransferobjekt)?
Verwenden Serviceparameter die korrekten Typen (Datentransferobjekte)?
Ist eine Abhängigkeit zwischen zwei fachlichen Komponenten erlaubt?
Namenskonventionen
Tabelle 2: Drei Kategorien der Validierungsregeln.
können. Die Erfahrung hat gezeigt, dass
eine frühere Validierung – nicht nur aus
generierbaren Modellen, sondern auch aus
Anforderungsspezifikationen und High-
Level-Designs – sehr wichtig ist, um früh
auf Unvollständigkeiten reagieren zu können
oder Projektkonventionen (z. B.
Namens gebung) rechtzeitig einzuhalten.
Sinnvoll sind Modellierungswerkzeuge,
die „on-the fly“ validieren und dem Benut -
zer unmittelbar Feedback geben, wie man
es von Programmier-Editoren kennt. Ne -
ben der automatischen syntaktischen
Validierung sind semantische Reviews, z. B.
über die Granularität der Services oder
Datenstrukturen, für die Qualitäts -
sicherung nicht wegzudenken und können
durch Werkzeuge nicht ersetzt werden. Alle
Validierungsregeln lassen sich in drei Kate -
gorien einteilen (siehe Tabelle 2).
Eingeschränkter Modellierungsstil
Abhängig vom gewählten Modellierungs -
werk zeug werden bei einem gegebenen
Metamodell Werkzeugerweiterungen automatisch
erzeugt (z. B. angepasste Dia -
grammtypen, Modellierungspaletten und
Kon text menus).
Bewährt haben sich im Projekt speziell
entwickelte Erweiterungen, um den Model -
lierer besser zu führen und das Design effizient
nach Richtlinien zu erstellen. Dazu
gehören – neben Modellvorlagen und
-mustern – die unterstützte Navigation
durch das Modell, die schnelle Suche über
referenzierte Elemente oder die einfache
Navigation vom Modellelement zur entsprechenden
Quellcode-Stelle.
Die Diskussion über grafische und textuelle
Modelle kann ich aus Platzgründen
hier nicht weiter vertiefen. Wir machen mit
grafischer Notation sehr gute Erfahrungen,
gerade weil Abläufe, komplexe Daten -
modelle und deren Beziehungen grafisch
am besten erfassbar sind. Ganz typisch sind
Meetings mit an die Wand gestrahlten
Ablauf-Diagrammen einer Service-Orches -
trierung, die dann mit Fachexperten Archi -
tekten und Entwicklern gemeinsam besprochen
werden. Es gibt auch Verwendung für
textuelle Modellierung, z. B. im GUI-
Design oder als formale Geschäftsregel-
Definition.
Continuous Integration
Aus der Projekterfahrung ist ein weiterer
wichtiger Baustein die Einbindung von
MDD in den kontinuierlichen Integrations -
prozess (Continuous Integration). Diese
ermöglicht nicht nur die ständige Überwachung
der Modellqualität (Validation),
sondern auch die Prüfung, ob Modell und
Code synchron zueinander sind. Regel -
mäßig werden sämtliche Generatoren auf
allen Modellen ausgeführt und anschließend
prüft der Compiler, ob die Imple -
mentierung zu den generierten Schnitt -
stellen und abstrakten Klassen kompatibel
ist.
Abb. 3: Beispiel „Service-Orchestrierung“
Darüber hinaus berichten speziell entwickelte
Reports über Codebestandteile,
die ihren Ursprung nicht im Modell haben
(auch solche können natürlich ihre Berech -
ti gung haben). Zu empfehlen ist der Einsatz
gängiger Best Practices über MDD und den
Entwurf domänenspezifischer Sprachen
(vgl. hierzu z. B. [Sta06], [Völ11]).
Organisatorische Bausteine
Das Bereitstellen einer funktionierenden
Werkzeugkette führt noch nicht zur erfolgreichen
Umsetzung der MDD-Methodik.
Im Folgenden beschreibe ich die nicht
weniger wichtigen soften Faktoren, die ein
Projekt berücksichtigen sollte.
Rollenverteilung
Die Konzeption und Implementierung der
MDD-Werkzeugkette wird in der Initi -
ierungsphase des Projekts zeitgleich mit der
Definition der Zielarchitektur durchgeführt.
Ein dediziertes Team (siehe „Archi -
tek turumsetzungsteam“ in Abbildung 4),
das aus Spezialisten der Ziel-Plattform und
MDD-Experten besteht, ist hierfür verantwortlich.
In enger Zusammenarbeit werden
anhand von Prototypen die Design-Richt -
linien und generierbare Teile definiert.
Dieses Team ist außerdem für die Lauf -
zeitaspekte und die Einhaltung der nichtfunktionalen
Anforderungen verantwortlich.
Wichtig ist, dass das Architekturum set -
zungsteam schnell auf Änderungsanforderungen
und Erweiterungen reagieren kann
und einen eigenen Release-Zyklus der
MDD-Werkzeugkette und des Laufzeit-
42 43

schwerpunkt
Frameworks pflegt, der mit dem Implemen -
tierungsteam und dessen Entwicklungs -
prozess abgestimmt ist.
Modellbasiertes Requirements-
Engineering
Es bewährte sich im Projekt, das Require -
ments-Engineering nahezu vollständig in die
MDD-Methode einzubeziehen. So können
die Anforderungen an Schnittstellen mit
Hilfe von konzeptionellen Daten modellen
(Business-Objekt-Modell) be schrie ben werden.
Auch die formale Be schrei bung von
Anwendungsfällen im Modell (z. B. Akti -
vitäten- oder Sequenz diagramme) ermöglicht
eine einheitliche und validierbare Spe -
zifi kation. Aus den Anforderungen
abge leitete Designmodelle referenzieren ihre
Herkunft und stellen somit eine nahtlose
Nachvollziehbarkeit (Traceability) her.
Daher lassen sich in der Wartung Änderungsanforderungen
schnell umsetzen, da
mit Hilfe des Modells die zu ändernden
Systembestandteile effizient identifiziert
werden. Abbildung 5 zeigt dies an einem einfachen
Beispiel: Die Änderungsanforderung
„E-Mail senden“ wird in einem alternativen
Ablauf des Anfor derungsfalls beschrieben
(1). Über die verlinkten Designmodelle ist
die Stelle für die Anpassung effizient lokalisiert
und wird in der Service-Orchestrierung
ergänzt (2). Die Code-Generierung sorgt
dafür, dass für den Entwickler die Schablone
vorgeneriert wird, in der der eigentliche
Basis-Service für den E-Mail-Versand aufgerufen
wird (3).
Das Testteam profitiert von den im
Modell definierten Anforderungen: Mit
Hilfe von speziellen Reports lassen sich die
zu testenden Bestandteile aus dem Modell
automatisch beziehen, z. B. durch das Aus -
lesen aller fachlichen Pfade eines Anfor -
derungsfalls.
Abb. 4: Architekturumsetzungsteam.
durch konkurrierende Modifikationen
minimiert. Darüber hinaus können
Zugriffsberechti gungen erzwingen, welche
Teams auf welchen Modellpartitionen
arbeiten. Letzterer Mechanismus wird im
Projekt lediglich auf sehr zentralen
Modellpartitionen (z. B. Da tenmodell) eingesetzt.
Das Mergen und ge legentliche
Auflösen von Konflikten wird mit
Werkzeugunterstützung vorgenommen.
Durch ein gemeinsam genutztes (Modell-)
Re pository hat das gesamte Projektteam
ständig eine gemeinsame Sicht auf Anfor -
derungen, Design und Code.
MDD und agile Prozesse
Kritiker des MDD-Ansatzes wenden ein,
dass man mit MDD an Flexibilität verliert.
Diesen Eindruck mag das von der OMG
beschriebene MDA-Vorgehen vermitteln,
das falsch als Wasserfall-Modell interpretiert
werden kann (Computation Indepen -
dent Model -> Platform Independent
Model -> Platform Specific Model, vgl.
[OMG12]).
Im Folgenden beschreibe ich, wie sich
agile und modellgetriebene Ansätze ge -
winn bringend ergänzen, aber auch, wo
wesentliche Unterschiede bestehen.
Skalierbarkeit des MDD-Ansatzes
Um den modellzentrierten Ansatz in einem
größeren Team auszurollen, muss zu
Beginn (d. h. bevor das Team die Zielgröße
erreicht) feststehen, wie mit dem Modell
gearbeitet wird. Auch wenn Model -
lierungs werkzeuge generell Teamwork
unterstützen, sollten Fragen zu Teamwork,
Locking-Granularität, Modell-Merging etc.
geklärt werden.
Im konkreten Projekt wurde das Modell
nach fachlichen Komponenten partitioniert
und die Verantwortlichkeiten wurden auf
kleine Teams verteilt. Dadurch wird die
Wahrschein lichkeit von Modellkonflikten
Abb. 5: Von der Änderungsanforderung, über das Modell zum Code.
6/2012

schwerpunkt
Iteratives Vorgehen mit kleinen Teams
Modelle stellen kein Hindernis dar, um ein
agiles Vorgehen einzusetzen. Die Voraus -
setzung wird zuerst durch die Projekt -
organisation geschaffen. Ein großes Team
muss in mehrere kleine unterteilt werden,
denen die Lieferverantwortung für eine
Teilkomponente übertragen wird.
Die kleinen Teams bestehen aus diversen
Rollen (Require ments-Engi neers und
Entwickler), sodass Kommuni ka tionswege
optimiert werden. Innerhalb dieser Teams
werden agile Methoden angewandt, z. B.
eigenständige Sprint-Planung und regelmäßige
Scrum-Meetings. Das funktioniert bei
gegebener Infra struktur auch über
Zeitzonen hinweg.
Geliefert werden fachliche abgeschlossene
Anwendungsfälle, die jeweils einer
Komponente zugewiesen werden. Es ist
nicht auszuschließen, dass mehrere Teams
gemeinsame Komponenten modifizieren,
z. B. Datenmodelle oder Basis-Services.
Diese zentralen Komponenten werden
durch dedizierte Teams gewartet, die Änderungsanforderungen
entgegennehmen und
diese kontrolliert umsetzen.
Restrukturierung (Refactoring)
Refactorings auf Codeebene werden optimal
durch Entwicklungswerkzeuge unterstützt.
Bei Verwendung des MDD-Ansatzes
kann Mehraufwand entstehen, weil die
Synchronisation von Modellen und Code
ganzheitlich betrachtet werden muss.
Allerdings gibt es technische Lösungen, um
den Mehraufwand zu minimieren: Für
mögliche Änderungen helfen Refactoring-
Skripte, wie sie z. B. in „Eclipse JDT“ (vgl.
[Ecl]) unterstützt werden. Falls Massen -
änderungen (Verschieben, Umbenennen,
etc.) erforderlich sind, leiten wir diese
Skripte automatisch aus dem Modell ab
und führen sie auf der Codeebene aus.
Fazit
Modellgetriebene Ansätze (auch in anderen
Varianten als hier dargestellt) sind aus größeren
Projekten nicht wegzudenken. Bei
der Berücksichtigung von bewährten
Praktiken ist die Einführung von MDD aus
technischer Sicht unproblematisch. Das
alleinige Bereitstellen einer MDD-Werk -
zeugkette reicht allerdings häufig nicht aus.
Wichtig sind die ganzheitliche Betrachtung
von MDD und die Adressierung softer
Faktoren, wie Organisation und Prozesse.
Ein wesentlicher Beitrag zum Erfolg von
MDD im konkreten Projekt war die holis -
tische Umsetzung, d. h. die Einbeziehung aller
Mitarbeiter des Projekts als Nutzer der
Modelle. So werden die Vorteile von MDD
nicht nur für eine „elitäre“ Gruppe sichtbar,
sondern für alle Projekt beteiligten. Ver -
gleichs schätzungen über die fachliche Kom -
ple xität haben gezeigt, dass im Projekt für die
Implementierung neuer Anforderung die Effi -
zienz um ca. 30 bis 40 % gesteigert wurde.
Beim Skalieren über die Teamgröße wurden
die meisten Lektionen gelernt. In einem
wachsenden Team bedarf es spezieller
Rollen, die das Wissen als Coachs ebenso
weitergeben wie gute Dokumentation über
die Installation und Anwendung der MDD-
Werkzeugkette (z. B. durch eine Referenz -
applikation). Die Einarbeitung neuer
Mitarbeiter ist nicht zu vernachlässigen.
Haben aber Entwickler die Zusammen -
hänge von Modell, Generatoren und Code
verstanden, können sie sich schnell produktiv
einbringen.
Nicht nur Teams ändern sich, sondern
auch die Modellgröße und die Art, wie auf
das Modell zugegriffen wird. In dem hier
Literatur & Links
vorgestellten Projekt ging die erste
Festlegung der Modellpartitionierung nicht
weit genug und wurde später korrigiert,
nachdem die Teilkomponenten und Team -
ver ant wortlichkeiten feststanden.
Auch bei der Generatorentwicklung gab
es gelernte Lektionen. Beispielsweise hat
die Modellierung von Testdaten-Instanzen
zu Beginn sehr gut funktioniert und ermöglichte
die vollständige Generierung von
Unit-Tests. Mit wachsendem Datenmodell
erwies sich aber dieser Ansatz als zeitaufwändig.
Nach einer Korrektur nimmt der
Unit-Testgenerator nun dem Entwickler
immer noch die Arbeit für das Erstellen von
Unit-Tests ab, die Dateninstanzen werden
aber im Code oder in einer Datenbank
hinterlegt. Generell sollte es das Ziel der
Codegenerierung sein, möglichst sinnvoll,
statt möglichst viel zu generieren.
Nicht jedes Projekt eignet sich für MDD,
z. B. wenn die Projektgröße den initialen
Aufwand für die Erstellung der MDD-
Werkzeugkette nicht rechtfertigt. Hat aber
eine Organisation den MDD-Prozess etabliert,
so ist die Wahrscheinlichkeit groß,
dass sich verwandte Projekte mit einem
ähnlichem Architekturstil finden. Dann
kann ein Unternehmen durch Software-
Industrialisierung über Projektgrenzen hinaus
profitieren, indem bereits implementierte
MDD-Werkzeugketten in Projekten
wiederverwendet werden. Eine Weiterent -
wicklung des klassischen MDD-Vorgehens
ist die Kombination von MDD mit agilen
Vorgehensmodellen. In diesem Artikel habe
ich gezeigt, dass diese Methoden sich nicht
ausschließen und ein Projekt von beiden
Ansätzen profitieren kann.
■
Wert der Dokumentation
Beim Thema Dokumentation besteht der
we sentliche Unterschied der Ansätze. Lang -
lebige aktuelle Dokumentation widerspricht
dem agilen Prinzip „der Code ist die
Dokumentation“ (vgl. [Fow05]). Dieses
Prinzip ist nicht anwendbar, wenn es sich
um eine nicht mehr gelehrte Sprache handelt
und nur wenig Experten-Know-how
vorhanden ist. Spätestens in ein paar
Jahren, wenn vielleicht auch Java nicht
mehr State-of-the-Art ist, muss diese Aus -
sage hinterfragt werden.
[Ecl] Eclipse, Eclipse Java development tools (JDT), siehe: eclipse.org/jdt
[Fow05] M. Fowler, CodeAsDocumentation, 2005, siehe:
martinfowler.com/bliki/CodeAsDocumentation.html
[Jos08] N. Josuttis, SOA in der Praxis, dpunkt.verlag 2008, siehe:
soa-in-der-praxis.de/soa-glossar.html
[OMG12] Object Management Group (OMG), MDA Specifications, 2012, siehe :
omg.org/mda/specs.htm
[Sta06] T. Stahl, M. Völter, Model-Driven Software Development, Wiley 2006
[Völ11] M. Völter, DSL Best Practices, 2011, siehe:
voelter.de/data/pub/DSLBestPractices-2011Update.pdf
[Zie10] S. Ziegler et. al., Industrielle Software Entwicklung, BITKOM 2010, siehe:
bitkom.org/files/documents/Industrielle_Softwareentwicklung_web.pdf
44 45

advertorial
der autor
ANFORDERUNGSMANAGEMENT
IN EINER ZUNEHMEND AGILEN
PROJEKTLANDSCHAFT
Agiles Anforderungsmanagement findet aktuell eine große Beachtung bei
Prozessverantwortlichen in der Industrie. Häufig werden die agilen Methoden allerdings isoliert
betrachtet. Eine solche Betrachtungsweise behindert aber die mögliche Evolution des
Anforderungsmanagements. Die ideologische Trennung der bisherigen Vorgehensweisen von
den agilen Methoden muss aufgegeben werden, um das Ziel des Anforderungsmanagements
zu erreichen: ein gemeinsames Verständnis über ein zu entwickelndes System zwischen
Auftragnehmer und Auftraggeber zu erreichen. Der Artikel beschreibt die wesentlichen Änderungen
und Vorteile, die sich durch die agilen Methoden ergeben. Es wird gezeigt, dass die
Elemente des agilen Anforderungsmanagements als Bereicherung der aktuellen
Methodenlandschaft zu verstehen sind und nicht als ein radikaler Paradigmenwechsel.
Arno Dämon
(arno.daemon@de.ibm.com)
hat in verschiedenen Rollen und Firmen über 15
Jahre Erfahrung in der Softwareentwicklung als
Entwickler und Konfigurationsmanager gesammelt,
bevor er im Jahr 2000 zu IBM Rational wechselte.
Er hat seit dieser Zeit umfangreiche Erfahrung in
den Bereichen Änderungs- und Konfigurations -
management akkumuliert. In letzter Zeit hat sich
Arno Dämon mit der Umsetzung der anforderungsgetriebenen
Softwareentwicklung in einigen
Implementierungsprojekten auseinandergesetzt.
Ein verschärfter Wettbewerb und komplexere
Projekte zwingen die Hersteller, ihre
Prozesse und Abläufe in der Art zu verbessern,
dass die Projekte in einer kürzeren
Zeit als noch vor einigen Jahren auf den
Markt gebracht werden können. Gleich -
zeitig sollen die Produkte aber in exzellenter
Qualität und mit konkurrenzfähigen
Eigenschaften versehen werden.
Auf der Suche nach Verbesserungs mög -
lichkeiten rücken häufig die Anforderun -
gen und die Anforderungsmanagement -
prozesse in den Fokus, weil sie im gesamten
Entwicklungsprozess eine wichtige Rolle
spielen und durch die permanente Präsenz
offensichtlich ein hohes Verbesserungs -
potenzial bieten. Belastbare und konsistente
Anforderungen, deren Änderungen formal
über die Projektlaufzeit kontrolliert
werden, senken nachweisbar die Fehler -
raten über die gesamte Projektlaufzeit (vgl.
Abb. 1).
Gleichzeitig planen viele Firmen Projekte
mit agilen Ansätzen wie Scrum oder XP
durchzuführen, denn die Projekte, die dem
agilen Entwicklungsansatz gefolgt sind,
haben sehr oft die erwarteten Verbes serun -
gen erbracht. Sie stehen daher bei den
Überlegungen der Methoden- und Tool-
Verantwortlichen häufig an oberster Stelle
der potenziellen Konzepte.
Doch schaut man sich z. B. den Scrum-
Ansatz an, dann fällt auf, dass der bislang
verbreitete formale Anforderungsmanage -
ment ansatz hier nicht enthalten ist. Im
Gegenteil, häufig wird das formale
Anforderungsmanagement komplett abgelehnt
und als Gefahr von den „Agilisten“
angesehen.
Im Folgenden wird beschrieben, wie
Anforderungsmanagement unter dem
Gesichtspunkt der agilen Methoden betrieben
werden sollte und welche Vorteile die
Umstellung vom formalen Anforderungs -
manage ment auf das agile Anforderungs -
manage ment erbringen kann.
Was ist eigentlich anders?
Anforderungsmanagement wird häufig so
verstanden, dass am Anfang des Projekts
eine Spezifikation geschrieben und dann in
einer Baseline eingefroren wird. Oft werden
daraus umfangreiche Lastenhefte generiert
und mit einem potenziellen Lieferan -
ten ausgetauscht. Änderungen an den
An forderungen sind risikobehaftet und
sollten nur unter formaler Kontrolle durch-
Abb. 1: Kosten durch späte Entdeckung von Fehlern
geführt werden. In vielen Fällen werden die
An forderungen in starren Systemen mit
einem Metamodell versehen, um einheitliche
Strukturen zu generieren.
Im agilen Umfeld werden Anforderungen
anders verstanden. Sie sollen die Kunden -
wünsche abbilden und helfen, sie zu verstehen.
Durch enge Zusammenarbeit mit dem
Kunden soll sichergestellt werden, dass die
Wünsche stets aktuell in den Anfor -
derungen abgebildet sind. Änderungen sind
willkommen und werden daher als selbstverständlicher
Teil des Anforderungs -
manage ments verstanden. Spätestens nach
jeder Iteration werden sie geprüft und überarbeitet.
Agil arbeitende Teams betrachten
die Änderungen eher als Zeichen von
Reifung, also als Fortschritt.
6/2012

advertorial
Agile Verfahren wie Scrum beinhalten
daher kaum Anforderungsmanagement im
klassischen Sinn. Scrum verwendet eine
einfache priorisierte Liste, die die An -
forderungen (Product Backlog genannt)
enthält. Die Anforderungen des Kunden
werden im Wesentlichen als Benutzer -
geschichten textuell erfasst und durch die
kontinuierliche direkte Kommunikation
der Anforderungsbeteiligten konsistent
gehalten. Bereits realisierte und vom
Auftraggeber akzeptierte Anforderungen
werden aus dem Product Backlog gestrichen.
Der Product Backlog ist damit eine
Liste von Anforderungen die noch erledigt
werden müssen.
Als Synonym für eine Person oder eine
Gruppe, die ein berechtigtes Interesse am
Verlauf oder dem Ergebnis des Projekts hat,
wird in diesem Artikel die Bezeichnung
„Stakeholder“ (in etwa identisch mit dem
Projektbeteiligten der DIN 69905) verwendet.
Stakeholder oder Projektbeteiligte sind
alle Personen, Institutionen und Doku -
mente, die von der Entwicklung und vom
Betrieb eines Systems in irgendeiner Weise
betroffen sind. Dazu gehören auch
Personen, die nicht in der Systement -
wicklung mitwirken, aber das neue System
zum Beispiel nutzen, in Betrieb halten oder
schulen. Stakeholder sind die Informations -
lieferanten für Ziele, Anforderungen und
Randbedingungen an ein zu entwickelndes
System oder Produkt.
Der Stakeholder soll idealerweise direkt
mit dem Projektteam in Kontakt stehen
und am besten auch räumlich nahe zu dem
agilen Team sein, um eine kontinuierliche
Kommunikation zu garantieren. Am Ende
jeder Iteration wird der aktuelle Stand der
Entwicklung von dem Stakeholder in
Augenschein genommen und überprüft.
Das ist möglich, da das agile Team nach
jeder Iteration per Definition funktionierende
Software bereitstellen soll. Dieser
Stand des Projektes wird als „Potentially
Shippable Functionality“ bezeichnet. Das
bedeutet, dass der Stakeholder potenziell
auslieferbare und in sich abgeschlossene
Funktionalität erhält und anschließend
begutachten kann. Beim Scrum wird der
Stakeholder als „Product Owner“ bezeichnet.
Die Lücke zwischen den Erwartungen
des Auftraggebers und dem im Produkt tatsächlich
enthaltenen Kundennutzen wird
durch ständig wiederkehrende formale
Überprüfung (Retrospektive) offengelegt.
Die gewonnenen Erkenntnisse werden in
Abb. 2: Vergleich des Kundennutzens bei
Anwendung des Wasserfallmodells oder
des agilen Modells
der folgenden Iteration erneut in die
Anforderungen miteinbezogen. Es ist
durchaus üblich, dass die Ergebnisse aus
der Retrospektive auch den Inhalt des
Product Backlog verändern.
Agile Projekte liefern daher in der Regel
einen höheren Kundennutzen zu einem früheren
Zeitpunkt.
Die Vorteile des agilen Anforderungs -
managements sind im Wesentlichen:
■
■
Höhere Sichtbarkeit über die gesamte
Projektlaufzeit:
Durch die kontinuierliche Überprüfung
und Begutachtung der Arbeitsergeb -
nisse bei jedem Abschluss einer
Iteration wird der Status direkt aus den
gewonnenen Ergebnissen abgeleitet.
Die Reife der Software basiert auf dem
aktuellen Stand des Projekts. Bei den
formellen Projekten ist die Sichtbarkeit
während der Phase der Erfassung von
Anforderungen hoch, aber der Kunde
bleibt nach dem Start der Implemen -
tierungsarbeiten fast im Dunkeln, ob
und wie seine Anforderungen umgesetzt
wurden oder nicht. Zwischen -
geschobene Meilensteine sollen im formell
durchgeführten Projekt die
Sicht barkeit verbessern. Bei genauer
Betrachtung erkennt man an dieser
Stelle schon die Hinwendung zum iterativen,
agilen Verfahren.
Bessere Anpassungsfähigkeit an geänderte
Bedingungen und Änderungswünsche:
Im Zuge der Realisierung von Soft -
wareanforderungen sind Änderungen
■
an der Tagesordnung. Eine späte Änderung
der Anforderung ist oft ein Wett -
bewerbsvorteil für den Auftraggeber.
Für die traditionellen Methoden, wie
z. B. die Wasserfallmethode, ist eine
späte Änderung ein nahezu unkalkulierbares
Risiko. Agiles Anforderungs -
management ermöglicht es dem
Kunden zu jedem Zeitpunkt, die Anfor -
derungen an sich ändernde Bedin -
gungen anzupassen.
Risikominimierung:
Die agilen Methoden im Anforderungs -
management führen zu einer Fo kus -
sierung auf die schnelle Lieferung von
Kundennutzen. Als Ergebnis dieser
Fokussierung und der damit verbundenen
Vorteile sind die Organisationen in
der Lage, das Gesamtrisiko, das mit der
Entwicklung verbunden ist, signifikant
zu reduzieren. Hier wird einer der
wichtigsten Unterschiede zwischen den
formellen Entwicklungsansätzen und
dem agilen Anforderungsmanagement
sichtbar.
Die formellen Methoden gehen davon
aus, dass die Eigenschaften eines
Produktes am Projektanfang vollständig,
eindeutig und messbar vorliegen.
Durch diese Vorgehensweise soll das
Risiko, mit einer fehlerhaften Spezifika -
tion zu arbeiten, reduziert oder ausgeschlossen
werden. Agile Projekte hingegen
nehmen immer die Stories vom
Product Backlog, von denen angenommen
wird, dass das Risiko sie zu implementieren
besonders hoch ist.
Diese Vorgehensweise macht Sinn,
wenn man bedenkt, dass agil arbeitende
Teams möglichst früh und möglichst
viel aus den Projektergebnissen lernen
wollen. Unter diesem Gesichtspunkt
wäre es kontraproduktiv, die „spannenden“
Themen erst in einer späten
Projektphase abzuarbeiten.
Agiles Anforderungsmanagement konzentriert
sich daher sehr stark auf Interaktion
mit dem Auftraggeber, wobei der größte
Teil dieser Wechselwirkung durch Retros -
pektiven und Prototyping herbeigeführt
wird. Die Retrospektiven dienen zunächst
der Verbesserung der Fehlerraten in der
angestrebten Lösung, aber sie sind auch
eine Methode zur Verbesserung der
Qualität der Anforderungen selbst, da
nicht nur die Software, sondern auch die
Anforderungen überprüft werden.
46 47

advertorial
Ist es nicht möglich, alle Anforderungen
von nur einer einzigen Person zu erhalten,
kann es notwendig werden, bei der
Erhebung der Anforderungen diese als
einen Prozess zu betrachten. Das bringt
inhärent den Vorteil mit sich, dass die
Anforderungen aus unterschiedlichen
Stand punkten der am Projekt Beteiligten
formuliert werden.
Weiterhin sollten die Projekte, die vom
formellen Anforderungsmanagement zum
agilen Ansatz wechseln, ohne Bedenken die
verschiedenen Interviewtechniken, die in
den Vorgängerprojekten benutzt wurden,
einsetzen. Die Bedeutung der kontextfreien
Fragen, offenen Fragen und Meta-Fragen
sind auch in einem agilen Umfeld gültig.
Wie sehen die Anforderungen
in agilen Projekten aus?
Die Ausgestaltung der Anforderungen im
agilen Umfeld ist nicht fest vorgegeben. Sie
sollten dennoch nicht blindlings definiert
werden. Bestimmte Sachverhalte lassen sich
von Fall zu Fall durch verschiedene
Verfahren formulieren. Verschiedene For -
men, die allerdings unternehmens- oder
projektspezifisch standardisiert sein sollten,
helfen trotz der Vielfalt der Ausdrucks -
möglichkeiten, einer bestimmten Semantik
zu folgen. Diese kann nach jeder Retros -
pektive überprüft und gegebenenfalls angepasst
werden.
Oft reicht ein kurzer syntaktisch standardisierter
Satz (Benutzergeschichte) auf einer
Karteikarte aus, um eine Anforderung hinreichend
zu beschreiben. Ein anderes Mal
ist es besser, die möglichen Ablaufvarianten
zu visualisieren, also ein Bild zu zeichnen
(Aktivitätsdiagramm), oder ein Status dia -
gramm zur Darstellung der möglichen
Zustände der Lösung zu beschreiben.
Am häufigsten werden jedoch textuelle
Notationen verwendet. Bei Scrum ist eine
User Story eine der gebräuchlichsten
Formen der Notation für ein Element des
Product Backlog. Definitionsgemäß
gehorcht sie einer speziellen Syntax:
„Als möchte ich , weil
”. Also z. B.: “Als Adminis -
trator möchte ich das Passwort eines
Benutzers zurücksetzen können, weil dieser
sonst bei vergessenem Passwort keine
Möglichkeit mehr hat, in das System zu
gelangen”.
Die User Stories werden vom Product
Owner zur Verfügung gestellt und sind
Abb. 3: Rational Requirements Composer unterstützt die Bearbeitung des „Product
Backlog“
bewusst kurz gehalten. Eine gut gemachte
Story ist rein fachlich gehalten. Es ist üblicherweise
keine gute Idee, eine Story nach
Komponenten zu zerteilen – also Frontend,
Mittelschicht und Datenbank. Sinnvoller
ist es, sie in funktionale Teile zu zerlegen.
Die Kunst des Product Owners besteht
darin, diese Stories in genau der richtigen
Größe bereitzustellen und besonders darauf
zu achten, dass sie nicht zu lang werden.
Als Faustregel sollte gelten: Die Story
muss klein genug sein, um in einen Sprint
zu passen und muss noch gut schätzbar
sein, allerdings muss die Story groß genug
sein, um einen funktionalen Mehrwert zu
bieten und schätzbar sein.
Epics sind Anforderungen, die eigentlich
nur als Platzhalter für große, später zu realisierende
Features stehen. Epics sind zu
groß für die Implementierung, sie müssen
zunächst in kleine User Stories geschnitten
werden. Weiterhin eignen sich Elemente
aus der UML wie Anwendungs-, Zustandsoder
auch Sequenzdiagramme.
Der richtige
Detaillierungsgrad
Wie tief ein Team im Einzelfall Anfor -
derungen vor der Realisierung verstehen
sollte, hängt von der Kompliziertheit und
Komplexität der Anforderung selbst ab,
ebenso aber von der Ausgangssituation bei
den Anforderungsgebern und System -
benutzern sowie den Bedürfnissen und
Notwendigkeiten auf Seiten der Realisierer.
Gute User Stories sollten sich an sechs
Kriterien orientieren, die unter dem
Akronym „INVEST” zusammengefasst
werden (vgl. [Wak03]).
Für Anforderungsmanager, die vom streng
formellen zum agilen, iterativen Anfor -
derungs management umsteigen, ist es ein
sinnvoller erster Schritt, gezielt die
Verständnistiefe, also die Unvollkommen heit
der Anforderungen zu steuern. Der
Anforderungsmanager sollte die gezielte
Unvollkommenheit als notwendigen Opti -
mierungsschritt akzeptieren lernen. Die
erfahrenen Agilisten sollten allerdings
anspruchsvollere Techniken ebenso beherrschen
lernen, weil eine Standardisierung auf
der Basis einfachster Mittel nicht optimal ist.
Das Rauschen im Blätterwald
Das agile Anforderungsmanagement kann
zunächst vollkommen ohne Unterstützung
durch ein Softwaretool betrieben werden.
Die grundlegenden Tätigkeiten eines An -
forderungsmanagers oder Product Owners
können mit „Post-it“ und Karteikarten
abgebildet werden. Dieser rudimentäre
Ansatz ist durchaus tragfähig. Insbeson -
dere bei größeren und pragmatisch arbeitenden
Teams macht der Einsatz eines
unterstützenden Tools Sinn. Der Require -
ments Composer von Rational bietet hier
6/2012

advertorial
Freigabe anzeigen. Des Weiteren können sie
Dateien, die mit anderen Tools erstellt wurden,
hochladen und zu ihren Anfor -
derungsinformationen hinzufügen – dazu
zählt auch das Zuweisen von Attributen
und Tags, das Einordnen in Objektgruppen
und die Prüfung und Freigabe durch andere.
Abb. 4: Bearbeitung von Benutzergeschichten in Rational Requiements Composer
eine effektive Unterstützung für agiles
Anforderungsmanagement an.
Teams, die mit Rational Requirements
Composer (RRC) arbeiten, können An -
forderungsartefakte mit beliebigen zugehörigen
Informationen verknüpfen. Des
Weiteren besteht die Möglichkeit, Arte -
fakte in Dokumente und Benutzer -
schnittstellenskizzen einzubetten, um Ideen
auf diese Weise zu optimieren. Dieser
umfassende und flexible Ansatz ermöglicht
es den Teams, flexibel zusammenzuarbeiten
und während der Entwicklung geschäftsorientierter
Lösungen Sachverhalte zu klären
und eine Einigung zu erreichen.
Rational Requirements Composer unterstützt
das agile Anforderungsmanagement
bei Aufgaben wie:
■
Alle Projektbeteiligten einzubinden und
die aktive Zusammenarbeit bei allen
Anforderungen zu vereinfachen.
■ Gemeinsame Visionen und das Ver -
ständnis der Projekt- und Programm -
anforderungen zu erreichen.
■ Teams mithilfe der integrierten Glos -
sarfunktionen durch ein gemeinsames
Vokabular zu vereinen.
■ Neuen Teammitgliedern in kurzer Zeit
einen produktiven Projekteinstieg zu
ermöglichen, indem ihnen die Anfor -
derungen, der Geschäftskontext und
die bisherigen Diskussionen online zur
Verfügung gestellt werden.
Durch die Nutzung einer gemeinsamen
Datenbank und den Einsatz von Web-
Clients können die Beteiligten Dokumente
oder Diagramme auf einfachste Weise
erstellen, den aktuellen Arbeitsstand des
Teams anzeigen und offene Fragen klären.
Sie können sich in Gruppen über Anfor -
derungen austauschen, viele kleine schnelle
Onlineprüfungen durchführen und deren
Zusammenfassung
Die Kunst des agilen Anforderungs -
managements besteht darin, die genannten
Eigenschaften – angemessen, passend, relevant
und so weiter – zu erfüllen. Dabei ist
Iteration wichtiger als Spezifikation. Die
Aufgabe des Teams beschränkt sich nicht
nur auf die Erhebung, Analyse, Spezifi -
kation und Dokumentation von Anfor -
derungen, sondern auch auf die Inhalte und
Bedeutungen von Anforderungen. Diese
sind zwischen den Beteiligten (vor allem
zwischen fachlichen Vertretern und
Entwicklern) „proaktiv“ zu vermitteln und
zu klären.
Es gilt: Evolution ist wichtiger als
Determination. Die Aufgabe des Anfor -
derungsmanagements findet im Gegensatz
zu den klassischen Methoden keinen eigenen
Abschluss mehr, sondern ist eine, die
gesamte Entwicklungszeit begleitende
Tätigkeit. Agiles Anforderungsmanage -
ment verlangt, dass Spezifikationen,
Defini tionen und andere Artefakte jederzeit
hinterfragt werden dürfen und gegebenenfalls
weiterentwickelt werden. ■
Literatur
[Wak03] Wake, William C.: INVEST in Good
Stories, and SMART Tasks, 2003:
www.xp123.com
Erstmals erschienen im Online Themenspecial
Requirements Engineering 2012
Die IBM Premium-Konferenz steht ganz im Zeichen der Innovationen
von Software und Systemen. Entdecken Sie unter dem Motto „Next
Now!“, wie Softwareentwicklung bereits heute die Weichen für die
Innovationen von morgen stellt: Vom 14. bis 15. 11. 2012 in Pots -
dam. Freuen Sie sich auf internationale Top-Keynote-Sprecher, zahlreiche
Workshops und die Solution Expo. In 40 Sessions in fünf parallelen
Tracks erhalten die Teilnehmer kompakt Informationen über die
neuesten Entwicklungen im Software- und Systembereich.
Weitere Detailinformationen finden Sie unter: www.ibm.com/de/events/innovate
48 49

Haben Sie schon einmal über...
Collaborative Application Lifecycle Management
Dann
haben
die richtige
wir
Lektüre
für
Sie !
Winter 2012
www.OBJEKTspektrum.de
...nachgedacht ?
In Kooperation mit IBM
SONDERBEILAGE
Collaborative Application Lifecycle Management
Die Zeitschrift für Software-Engineering und -Management
Am 14.12.2012 erscheint unsere
Sonderbeilage zum Thema CALM
mit Meinungen, Lösungen und
Fallbeispielen. Das rund 36 Seiten
starke Magazin beschreibt die
Möglichkeiten zum effizienten
Tracking Ihrer Anwendungen mit
zahlreichen Fachbeiträgen, Tipps
und Meinungen von Experten.
Das Magazin erscheint als Sonderbeilage in den Ausgaben 01/2013.
Bestellen Sie Ihr persönliches und kostenloses Exemplar per E-Mail bei
Birgitt.Gilis@sigs-datacom.de
Betreff: CALM

fachartikel
mehr zum thema:
noop.nl
randsinrepose.com/
die autoren
VON SURFERN UND
SCHWERÖLTANKERN:
TROTZ KULTURSCHOCK ZUM
WIRTSCHAFTLICHEN ERFOLG
Die agile Welt wird in der aktuellen Literatur wie eine paradiesische Insel beschrieben. Auf dieser
Insel ist man angeblich angekommen, sobald die Organisation agil arbeitet. In der Umsetzung von
Projekten arbeitet man jedoch selten isoliert von der Außenwelt. Es gibt Partner, Subunter nehmer
oder Kunden, die ebenfalls ihren Teil zum Projekt beitragen. Nicht immer sind diese Mitstreiter
agil organisiert. In der Realität sind Projekte irgendwo zwischen agilen Surfern und schwerfälligen
Schweröltankern weit verbreitet. In diesem Artikel beschreiben wir, welche Herausforderungen
wir erlebt und welche Best Practices wir entwickelt haben, um solche Projekte trotz aller
Unterschiede in der Projektorganisation zu einem wirtschaftlichen Erfolg zu bringen.
Jacob Fahrenkrug
(jfahrenkrug@hypoport.de)
ist Softwarearchitekt bei der HYPOPORT AG. Als
Teil eines selbstorganisierten und funktionsübergreifenden
Teams treibt er die Entwicklung der
Finanzierungsplattform EUROPACE NL für den
niederländischen Immobilienfinanzierungs-Markt
voran.
Unsere Organisation ist nach agilen Prin -
zipien aufgestellt. Wir entwickeln und
betreiben Finanzmarktplätze – differenziert
nach Produktsparten, Ländern und Ziel -
gruppen. Unser Hauptinteresse dabei ist es,
einen möglichst erfolgreichen Marktplatz
zu etablieren, da unsere Erlöse durch
erfolgreich über den Marktplatz abgewi -
ckelte Transaktionen entstehen. Bei der
Entwicklung dieser Marktplätze arbeiten
wir sehr häufig mit potenziellen oder
bereits aktiven Nutzern zusammen. Bei diesen
Partnern handelt es sich um Banken,
Versicherungen und größere Vertriebsorga -
nisa tionen von Finanzdienstleistungs -
produkten.
Nicht zuletzt aufgrund einer zunehmenden
Regulierung des Marktes trifft man
dabei vielfach auf Partner, die nach klassischen,
am Wasserfallmodell orientierten
Vorgehensweisen arbeiten. Insofern ist ein
gemeinsames Projekt von Surfern und
Schweröltankern bei uns eher die Regel als
die Ausnahme.
Banken und große
Systemhäuser
Bei der Umsetzung von Projekten mit
Schwer öltankern haben wir als Surfer die
Beobachtung gemacht, dass es einige
Reibungspunkte gibt.
Funktional aufgestellte Partner
Neben den Anwendern und den Entwick -
lern des neuen Produkts gibt es sehr oft
Stabsstellen und Zentralfunktionen, die
sich für jeweils einzelne Aspekte der
Produkt entwicklung in der Verantwortung
sehen. Ihr Hauptaugenmerk liegt zumeist
leider nicht auf dem wirtschaftlichen Erfolg
eines Produkts, sondern auf der maximalen
Verwirklichung desjenigen Aspekts innerhalb
des Produkts, für den sie verantwortlich
sind. Da gibt es beispielsweise die
Enterprise-Architekten, die unabhängig
vom jeweiligen Produktkontext ihre Stan -
dard-Architekturprinzipien verwirklichen
wollen. Ebenso gibt es Qualitätsmanager,
die auf jeden Fall erst testen wollen, wenn
das Produkt in Gänze fertig gestellt ist.
Diese funktionale Orientierung wird nach
unserer Erfahrung sogar noch immens verstärkt,
wenn sich die gesamte Organisation
entlang dieser funktionalen Rollen aufgestellt
hat. Neben dem abgeschwächten
Fokus auf die eigentlichen Produktziele
kommt dann oft noch erschwerend hinzu,
dass die Mitarbeiter an diversen Themen
bzw. Projekten parallel arbeiten. Aus Sicht
des einzelnen Mitarbeiters besteht seine
Aufgabe dann nicht in der Realisierung
einer konkreten Produktidee, sondern im
Ausfüllen einer Funktion (z. B. Testen) in
einer Vielzahl von Produkten, die um seine
Mitarbeit im Rahmen seiner Funktion konkurrieren.
Vor diesem Hintergrund ist es verständlich,
dass sich die Produktentwicklung eher
nach einem Multi-Projekt-Monster anfühlt
als nach einer gemeinsamen, am Erfolg
eines Produkts ausgerichteten agilen Vor -
gehensweise. Gravierende Nachteile sind
dabei – neben den Aufwänden für die
Planung und die Erfüllung der Planung –
insbesondere auch die häufigen Kontext -
wechsel bei den einzelnen Projektbe teilig -
ten. Dass in dieser Situation noch Zeit für
produktive Arbeit am wirtschaftlichen
Erfolg des Produkts bleibt, grenzt fast
schon an ein Wunder.
Volker Kultermann
(volker.kultermann@hypoport.de)
ist Produktleiter bei der HYPOPORT AG. Er verantwortet
die Entwicklung der neuen Plattform -
generation von EUROPACE für den deutschen
Markt. Dabei gestaltet er viele Projekte aus dem
Banken- und Bausparkassenumfeld.
Wirtschaftliches Setup des Projekts
Eine weitere Herausforderung, die bereits
sehr früh im Aufsetzen eines gemeinsamen
Projekts zu meistern ist, ist die Frage nach
der wirtschaftlichen Gestaltung des Pro jekts.
Bei den ersten gemeinsamen Produkt -
entwicklungen ist es oftmals sehr schwer,
gegen das Standardmuster eines auf einem
Pflichtenheft basierenden Festpreisange bots
mit fest vereinbartem Projektplan anzukommen.
Gibt es bereits eine Historie gemeinsamer
erfolgreicher Projekte, so ist es sehr viel
leichter möglich, eine Form der Zusammen -
arbeit zu etablieren, bei der man gemeinsam
den wirtschaftlichen Erfolg des Produkts
gestaltet und nicht vorab Verhandlungen
über ein Festpreisprojekt führen muss.
Räumlich voneinander getrennte
Projektpartner
Eine ebenfalls regelmäßig anzutreffende
Rahmenbedingung ist die räumliche Tren -
nung von Projektpartnern. Zu der räumlichen
Trennung kommt zum Teil noch
erschwerend hinzu, dass die Projektpartner
keine gemeinsame Muttersprache haben.
Wir haben diese Herausforderung zum
Beispiel bei unserem niederländischen Fi -
50 51

fachartikel
nanz marktplatz. Innerhalb dieses Projekts
arbeiten das Entwicklerteam in Berlin und
unsere Business-Analysten in den Nieder -
landen. Organisatorisch stellt uns das vor
einige Probleme. In agilen Projekten wird
Wert darauf gelegt, möglichst direkten
Kontakt zueinander zu haben. Bei einer
räumlichen Trennung wird die Kommuni -
kation schwieriger. Häufig muss zum
Telefon gegriffen werden. Am Telefon kann
nicht immer alles besprochen werden und es
kommt leichter zu Missverständnissen.
Jeder, der schon einmal an einem Software -
design-Meeting teilgenommen hat, weiß,
wie schwer es ist, ein gemeinsames Pro blemund
Lösungsverständnis zu entwickeln.
Selbst wenn viele Bilder am White board entstehen,
diese direkt diskutiert werden und
alle Teilnehmer dieselbe Sprache sprechen,
ist es ein schwieriges Unterfangen. Unserer
Erfahrung nach potenziert sich das Problem,
sobald Sprache und Kommunikationskanäle
weniger direkt sind.
Meeting-Marathons
Wir haben die Erfahrung gemacht, dass
Banken, Systemhäuser und Finanz diens t -
leister ihr Geschäft überwiegend durch
aufwändige Prozesse steuern. Das liegt einerseits
an besonderen rechtlichen Rah men -
bedingungen und andererseits schlicht an
ihrer Größe. Teil solcher Prozes se sind häufig
fest vorgegebene Meetings, an denen sämtliche
Stakeholder teilnehmen müssen. Diese
Meetings werden dann aus Kosten gründen
alle auf einen Tag gelegt. Im Ergebnis bedeutet
dies häufig, dass in den meisten Meetings
zu viele Leute sitzen. Das Niveau der
Meetings muss so gestaltet werden, dass alle
Teilnehmer verstehen, worum es geht. Viel
Zeit geht verloren, weil man die
Rahmenbedingungen und die Gründe für das
Meeting erläutern muss. Dadurch sinkt die
Produktivität der Meetings signifikant.
Unser Werkzeugkasten
Im Laufe der Zeit haben wir in unterschiedlichen
Projekten mit verschiedenen
Werkzeugen experimentiert. Die Werk -
zeuge, die am besten funktionierten, stellen
wir im Folgenden vor.
Persönliches Netzwerk
Ein persönliches Netzwerk ist eine der
effektivsten Methoden, um ein gemeinsames
Commitment und einen reibungslosen
Fluss von Informationen zu erreichen.
Jeder Mensch weiß aus eigener Erfahrung,
dass es leichter ist, jemanden anzurufen,
Abb. 1: Das persönliche Netzwerk.
den man bereits persönlich getroffen hat,
als jemand völlig Fremden. Ebenfalls
bekannt ist, dass ein Telefonat oder ein
Gespräch in der Kaffeeküche oft größere
Erfolgs chancen haben als eine lange E-
Mail. Netzwerke, die eine große Hierarchie
und viele Fach bereiche überspannen, sind
besonders nützlich. Es ist wichtig, sich
genau zu überlegen, wie das Netzwerk aussehen
sollte. Dafür braucht man Zeit, denn
man muss den Partner und dessen
Organisation kennenlernen. Das Netzwerk
sollte aus Per sonen bestehen, die Einfluss
haben. Nicht immer sind Personen mit
Titeln oder Kom pe tenzträger die wahren
Entscheider. Welche Rollen braucht man in
einem guten persönlichen Netzwerk?
Unserer Erfahrung nach braucht man gute
Beziehungen zu folgenden Personenkreisen
(siehe auch Abbil dung 1):
■ Der Einstiegspunkt ist der Projektleiter.
■ Weiterhin braucht man direkten
Kontakt zu Architekten, Schnittstellen-
Verantwortlichen, Testern, Key-
Accoun tern und Kollegen vom Betrieb.
■ Der Zugang zu Marketing und Chefs
der IT-Abteilungen hilft ebenfalls.
Der eine oder andere Leser wird jetzt sagen:
„Toll, selbstverständlich brauche ich so ein
Netzwerk! Aber warum hilft mir das
besonders, wenn ich als agiler Surfer ein
Projekt mit einem Schweröltanker umsetzen
will?”
Durch ein gutes Netzwerk kann man
Entscheidungen schneller voranbringen.
Weil die Entscheidungen erst möglichst spät
im agilen Prozess getroffen werden, ist dies
für einen agilen Projektpartner von be -
sonderer Bedeutung. Es gibt nur kurze
Zeitfenster für die Entscheidung, um schnell
produktiv weiter zu arbeiten. Häufig ist man
inmitten der Umsetzung einer Anforderung
und stellt fest, dass es eine Definitionslücke
gibt. Wenn man dann die aktuelle Iteration
nicht abbrechen möchte, muss schnell eine
Entscheidung her.
In einem unserer Projekte, ging es um die
Erstellung einer Schnittstelle zur Prüfung
der Kreditwürdigkeit von Kreditantrags -
stellern. Die Schnittstelle ist für unseren
Finanzmarktplatz von besonderer strategischer
Bedeutung, weil sie zu einem besseren
Verhältnis von gestellten Kreditanträgen zu
vermittelten Krediten führt. Je früher diese
Schnittstelle also am Markt ist, desto besser
6/2012

fachartikel
ist dies für die Nutzer der Plattform und
damit auch für uns. Unser Projektpartner
war ein großer niederländischer Kredit -
dienstleister mit einer funktional aufgestellten
IT-Abteilung. Das bedeutete für uns,
dass wir mit Mitarbeitern aus diversen
Abteilungen zusammen arbeiten mussten.
Wir haben drei Workshops beim Partner
gebraucht, bis wir die richtigen Kollegen an
einem Tisch hatten. Ab diesem Zeitpunkt
konnten wir richtig Fahrt aufnehmen und
die Schnittstelle gemeinsam in drei weiteren
Workshops definieren. Das Ergebnis
war so überzeugend, dass unser Partner in
Erwägung zog, die Schnittstelle auch intern
einzusetzen und anderen Partnern zur
Verfügung zu stellen. Ohne ein persönliches
Netzwerk hätten wir diese Qualität innerhalb
von sechs Workshops zu je zwei Tagen
nicht erreicht.
Meetings und Meeting-Räume
richtig gestalten
Ein Szenario, das wir regelmäßig bei Kick -
off-Veranstaltungen mit großen System -
häusern und Banken erleben, ist das
Folgende: Wir werden eingeladen, um den
Projekt-Kickoff bei unseren Partnern
durchzuführen. Uns wird ein tolles
Gebäude mit einem riesigen sterilen
Meeting-Raum präsentiert. Dazu kommen
eine zwei Folien lange Agenda und eine
ganze Armee an Teil nehmern. Es gibt einen
großen Tisch in der Mitte. Auf der einen
Seite sitzen unsere angehenden Partner, die
andere Seite ist für uns reserviert. Meistens
wird eine solche Veranstaltung zu einer
Show, bei der es darum geht, klar zu
machen, wer der „Boss” bei diesem Projekt
sein wird.
Wir sind der Meinung, dass ein solches
Gebaren nicht gut für das gemeinsame
Projektziel ist. Damit ein Kickoff trotzdem
ein intensives Kennenlernen mit konkreten
Aufgaben, Verantwortlichen und einem
Folgetermin wird, haben wir einen einfachen
Trick. Als erstes sollte man fragen, ob
sich ein Flipchart und ein Whiteboard auftreiben
lassen. In der allgemeinen Ver -
wirrung kann man sich dann dem Raum
widmen. Zunächst sollte man den Tisch an
die Seite stellen und die Stühle im Halbkreis
arrangieren (siehe Abbildung 2). Sobald
Flipchart und/oder Whiteboard eintreffen,
wird die Situation folgendermaßen erklärt:
Das neue „Setting” des Raums führt dazu,
dass alle Beteiligten in eine gemeinsame
Richtung schauen. Was gut ist, da man ja
ein gemeinsames Ziel hat.
Abb. 2: Vergleich von Meeting-Raum-Setups.
Dieser Termin soll genutzt werden, um die
ersten Kontakte in Richtung persönliches
Netzwerk zu knüpfen. Deshalb gibt es eine
ausgedehnte Vorstellungsrunde. Jeder
Teilnehmer stellt sich kurz vor und schreibt
seinen Namen, E-Mail-Adresse und Telefon -
nummer auf ein Flipchart. An schlie ßend
darf jeder Anwesende seine wichtigste Frage
für diese Veranstaltung nennen. Diese wird
ebenfalls auf ein Flipchart geschrieben. Es
gibt keine Pflicht, eine Frage zu formulieren.
Sobald jeder einmal zu Wort gekommen ist,
kann man verkünden, dass diese Fragen die
Agenda des heutigen Meetings darstellen,
und man sollte in eine zehn- bis fünfzehnminütige
Pause gehen. Diese Pause ist wichtig
für die Organisatoren, um sich mit der
Situation abzufinden und sich auf das einzulassen,
was gerade passiert ist.
Unsere Erfahrung zeigt, dass der Verzicht
auf Folien und die Entfernung der physischen
Barriere in Form des Tisches sowie
das persönliche Engagement (jeder Teil -
nehmer hatte bereits mindestens einmal
den Stift in der Hand und hat somit etwas
zum Meeting beigetragen) eine positive
Stimmung schaffen. Es war noch nie je -
mand böse, dass die ursprüngliche Agenda
nicht beachtet wurde. Bisher wurde dieses
Verhalten immer als erfrischend und ausgesprochen
professionell wahrgenommen.
Räumliche Barrieren aufheben
Ganz egal wie gut die Technik heute bereits
ist, kein Telefonat und keine Video -
konferenz ersetzen ein gutes Gespräch, das
von Angesicht zu Angesicht geführt wird.
Der direkte Kontakt zu den Kollegen ist
wichtig, um das persönliche Netzwerk auszubauen
und sich in Meetings nicht unproduktiv
gegenüber zu sitzen. Videokon -
ferenzen erzwingen ein „sich gegenüber
Sitzen“. Bei Telefonaten geht ein wichtiger
Kanal der Kommunikation, die Körper -
sprache, verloren. Nun lässt sich nicht
immer begründen, warum bei jeder Frage
eine Dienstreise gebucht werden muss, aber
manche Probleme lassen sich einfach nicht
per Telefon oder Videokonferenz lösen. Es
gibt viele Beispiele für Meetings, die sich
nicht effektiv per Telefon oder Video -
konferenz abhalten lassen. Dazu gehören
Kickoffs und fachliche Workshops, bei
denen es darum geht, ein gemeinsames
Verständnis zu entwickeln. Auch Retro -
spektiven, bei denen besprochen wird, wie
die Zusammenarbeit bisher lief und wie sie
in Zukunft laufen soll, gehören dazu.
Regelmäßige Meetings, die abwechselnd
an den Standorten der Beteiligten ausgerichtet
werden, sind unserer Meinung nach
entscheidend für ein gutes Klima im
Projekt. Dadurch, dass solche Meetings
häufig den ganzen Tag dauern und die
Pausen gemeinsam verbracht werden, lernt
man sich besser kennen. Man versteht die
Ängste und Sorgen der Partner, wodurch
eine Arbeitsatmosphäre geschaffen wird,
die auf Verständnis und Vertrauen beruht.
Die zuerst vielleicht abschreckend wirken-
52 53

Partner mit dem agilen Virus infizieren
Partner, die wenig Erfahrungen mit agilen
Projekten haben, fokussieren sich häufig
auf lokale Probleme. Dieses Denken führt
dazu, dass jeder Projektpartner versucht,
innerhalb klarer Grenzen möglichst kostengünstig
durch das Projekt zu kommen.
In agilen Projekten gibt es solche Gren -
zen nicht. Es wird sich einem höheren Ziel
unterworfen: dem gemeinsamen Business-
Case. Ohne einen solchen Business-Case
würde es das Projekt nicht geben. Natür -
lich sind Kosten auch in agilen Projekten
eine wichtige Dimension, jedoch wird diese
nicht über alles gestellt. Aus unserer Sicht
macht es wenig Sinn, harte Grenzen zwischen
den Partnern zu ziehen. Das Konzept
hinter dieser Philosophie nennen wir
Achievement by Caring. Dadurch, dass sich
alle Beteiligten dem „höheren Ziel” (dem
gemeinsamen Business-Case) unterwerfen,
gibt es keine Grenzen. Aufgaben werden da
erledigt, wo die Kompetenzen liegen, nicht
da, wo die Budgets größer sind. Wenn
Wissen und/oder Fertigkeiten zwischen den
Partnern verteilt sind, werden die Aufgaben
gemeinsam erledigt. Das fördert die
Verteilung von Wissen und ein Gefühl von
Zusammenhalt. Dieses Konzept ist kein
Hexenwerk und den meisten Menschen
durchaus bewusst. Leider wird in Kosten
getriebenen Projekten häufig dieses höhere
Ziel dem Budget untergeordnet.
Die beste Möglichkeit, diese Denkweise
zu durchbrechen, ist, einige ausgewählte
einflussreiche Personen aus dem persönlichen
Netzwerk mit dem agilen Virus zu
infizieren. Auch diese Methode konnten
wir erfolgreich in dem erwähnten Schnitt -
stellen-Projekt einsetzen. Zu Beginn unserer
Workshops haben wir viel mit dem
Projektleiter unseres Partners über Res -
sour cen diskutieren müssen. Nach den
ersten drei Workshops haben sich drei der
Mitarbeiter unseres Partners persönlich
engagiert und das Projekt und die Ver -
fügbarkeit von Ressourcen von innen vorfachartikel
den Kosten für Dienstreisen sind gut inves -
tiertes Geld. An dieser Stelle möchten wir
gerne das obige Beispiel aus unserem
Schnittstellenprojekt nochmals anbringen.
Für dieses Projekt sind zu jedem der sechs
Workshops drei unserer Mitarbeiter zu
unserem Partner in die Niederlande geflogen.
Stellt man die Reisekosten nun ins
Verhältnis zu den anschließend aufgetretenen
Wartungskosten aufgrund von Spezifi -
kationsfehlern, so fällt die Bilanz klar zu
Gunsten der Reisekosten aus. Bei einem
anderen, früheren Schnittstellenprojekt mit
demselben Partner haben wir versucht, die
Reisekosten zu sparen, und kämpfen noch
heute mit den immer wieder auftretenden
Systemfehlern.
Fragen statt erklären
In agilen Organisationen sind funktionsübergreifende
Teams ein wesentliches
Standbein des Projekt-Setups. Das hat den
Vorteil, dass Spezialwissen schnell auf viele
Teammitglieder verteilt wird:
■ Mittelfristig werden so die Entwickler
zu kleinen Domänenexperten und Tes -
tern.
■ Die Tester werden zu kleinen Entwick -
lern und Domänenexperten.
■ Die Domänenexperten werden zu kleinen
Testern und Entwicklern.
Das heißt nicht, dass jeder alles perfekt
beherrscht, aber jedes Teammitglied hat so
viel Einblick in die Tätigkeiten der Kol -
legen, dass bei Engpässen ausgeholfen werden
kann. Durch die regelmäßigen
Meetings werden außerdem Moderations -
techniken und der Umgang mit Medien wie
Flip charts, Meta-Planwänden und White -
boards professionalisiert.
Wenn ein solcher „Alleskönner” auf
Part ner trifft, die funktional organisiert
sind, kann es leicht passieren, dass die
Partner überrannt werden. Im schlimmsten
Fall werden die Mitarbeiter aus dem agilen
Team als überheblich und besserwisserisch
wahrgenommen. Deshalb ist es unserer
Meinung nach wichtig, möglichst wenig
inhaltlich zu dozieren, denn die Partner
sind auch Profis auf ihrem Gebiet und es
gibt garantiert eine Menge Dinge, die man
von ihnen lernen kann. Das Motto, das wir
uns dabei zunutze machen, ist: Zuhören,
um zu verstehen, anstatt zuzuhören, um zu
antworten. Wenn man verstehen möchte,
was den Partner zu bestimmten Entschei -
dungen treibt, muss man Fragen stellen.
Durch Fragen ist der Partner auch weiterhin
involviert und weiß, dass es um ihn
geht und nicht um eine weitere
Selbstdarstellungsshow der coolen agilen
Truppe. Fragen sorgen ebenfalls dafür, dass
der Partner mit eigenen kreativen Lösungs -
vorschlägen kommt. Ein Vorschlag aus den
eigenen Reihen hat eine deutlich höhere
Chance, am Ende auch umgesetzt zu werden,
als eine Lösung, die von außen
kommt.
Praktisch,
klar, effektiv!
Inkl. kostenlosem
E-Book!
Chris Rupp, Stefan Queins, die SOPHISTen
UML 2 glasklar
Praxiswissen für die UML-Modellierung
4., aktualisierte und erweiterte Auflage. 580 Seiten
Flexibler Einband. € 34,90
ISBN 978-3-446-43057-0
Inkl. kostenlosem
E-Book!
Gernot Starke
Effektive Softwarearchitekturen
Ein praktischer Leitfaden
5., überarbeitete Auflage
426 Seiten. Flexibler Einband
€ 44,90
ISBN 978-3-446-42728-0
Chris Rupp, die SOPHISTen
Requirements-Engineering
und -Management
Professionelle, iterative
Anforderungsanalyse für die Praxis
5., aktualisierte und erweiterte
Auflage. 569 Seiten
Flexibler Einband. Vierfarbig
€ 49,90
ISBN 978-3-446-41841-7
Jetzt direkt bestellen!
Carl Hanser Verlag GmbH & Co. KG
direkt@hanser.de
6/2012
www.hanser-fachbuch.de/computer
www.hanser.de/computer

fachartikel
■ Dem klassischen Auftraggeber verlangt
dies ein höheres Maß an Vertrauen ab.
■ Für den klassischen Lieferanten bedeutet
es, dass er die von ihm bearbeiteten
Themen aus Marktsicht und wirtschaftlicher
Sicht verstehen und bewerten
muss. Dies ist eine wesentlich größere
Herausforderung, als diese lediglich
inhaltlich durchdringen und
umsetzen zu müssen.
Abb. 3: Chancen- und Risikoverteilung im Projektsetup.
angetrieben. Beim letzten Workshop war
sogar der Meeting-Raum bereits so vorbereitet,
dass kein Tisch im Weg stand, und
wir hatten ausreichend Flipchart-Papier
und -Marker.
Um es mit den Worten von Jurgen Apello
zu sagen: Change Agents werden ausfindig
gemacht und Change Agents leben das
gewünschte Verhalten vor. Diese Vorbilder
generieren dann Nachahmer (frei übersetzt
aus [App12]). Getreu dem Motto „Think
Big”, kann dadurch sogar eine ganze Orga -
nisation des Partners agil werden (dieses
Ziel haben wir noch nie erreicht, aber es ist
schön, davon zu träumen).
Wirtschaftliches Setup des Projekts
„Ich will wissen, was genau ich wann
bekomme und wie viel es mich kostet.” Die
meisten Gespräche bezüglich eines Projekt-
Setups folgen diesem Muster. Bei einem
klassischen Lieferanten-Auftraggeber-Ver -
hält nis ist das auch ein legitimer Ansatz.
Schließlich trägt das Risiko des wirtschaftlichen
Erfolgs allein der Auftraggeber,
wohingegen der Lieferant nur das Risiko
der Erbringung einer Leistung trägt. Man
kann dort zwar über eine lange Zusam -
menarbeit das gegenseitige Vertrauen ausbauen
– der Tenor der Zusammenarbeit
wird sich dadurch allerdings nicht grundlegend
ändern.
Unser Ziel ist eine konstruktive Zusam -
menarbeit auf Augenhöhe, die bei allen
Beteiligten den wirtschaftlichen Erfolg des
Produkts ins Zentrum rückt. Das lässt sich
jedoch nur erreichen, indem man das
Lieferanten-Auftraggeber-Verhältnis aufbricht
bzw. dieses klassische Muster in der
Zusammenarbeit erst gar nicht etabliert.
Nur wenn alle Projektbeteiligten, wie in
Abbildung 3 dargestellt, gleiche Chancen
und Risiken und damit auch gleiche
Zielsysteme haben, wird dies nach unserer
Erfahrung auch gelingen. Erreicht werden
kann das, indem die klassische Vergütung in
Form von fest vereinbarten Zahlungen nach
Projekt- bzw. Entwicklungsfortschritt vermieden
wird. An ihre Stelle tritt eine laufende
Beteiligung am Erfolg des Pro dukts.
Das hat natürlich Auswirkungen auf die
Projektbeteiligten:
Der Lohn für dieses beiderseitige Invest -
ment ist eine Harmonisierung der Ziel -
systeme. Dadurch werden lokale Opti -
mierungen (z. B. Minimierung des eigenen
Aufwands) vermieden und alle Beteiligten
arbeiten mit ganzer Kraft für ein erfolgreiches
Produkt.
Wie kann so etwas in der Realität aussehen?
Bei den von uns entwickelten und
betriebenen Finanzmarktplätzen wird für
jede erfolgreiche Transaktion eine geringe
Gebühr fällig. Diese Transaktionsgebühr
motiviert uns, bestimmte Produktentwick -
lungen mit Partnern durchzuführen – oder
auch nicht. Eine klassische Projektvergü -
tung nach dem beschriebenen Lieferanten-
Auftraggeber-Verhältnis ist in einigen
Projekten dann zwar immer noch vorhanden,
tritt aber absolut in den Hintergrund
und bestimmt nicht die Art der Zu sam -
menarbeit.
Ein weiterer, von uns häufig beobachteter
Nebeneffekt dieses Ansatzes ist die bei
großen Partnern sehr viel einfachere Bud -
getierung einer gemeinsamen Produktent -
wick lung. Für große, klassisch aufgestellte
Projekte müssen häufig komplexe Budge -
tierungsprozesse durchlaufen werden.
Leistungen müssen vorab möglichst detailliert
beschrieben und Stundensätze verhandelt
werden. Tritt an diese Stelle jedoch
eine laufende Partizipation am gemeinsamen
wirtschaftlichen Erfolg, so entspricht
dies Vertriebs- oder Produktionskosten. Da
diese nicht wie bei Projekten vorab anfallen,
sondern im laufenden Geschäftsbetrieb
im Rahmen des Vertriebs bzw. der Pro -
duktion, führt dies – insbesondere in großen,
klassisch aufgestellten Organisationen
– zu einem sehr viel einfacheren Start der
Zusammenarbeit als die Budgetierung und
Planung eines gemeinsamen klassischen
Projekts.
Zusammenfassung
Schweröltanker und Surfer haben beide
ihre Daseinsberechtigung. Und je nach
Aufgabe kann der eine oder andere zum
Einsatz kommen. Man muss sich bewusst
machen, dass Schweröltanker aufgrund
ihrer Schwere und Größe hochseetauglich
sind. Sie sind in der Lage, mal ein Unwetter
zu überstehen, und können große Mengen
54 55

fachartikel
Öl über eine weite Strecke transportieren.
Dabei haben sie nicht die Fähigkeit, schnell
zu reagieren. Beim Bremsen, Beschleunigen
und Lenken greift das Gesetz von der
Trägheit der Masse.
Surfer sind klein, leicht und wendig.
Kurs änderungen sind jederzeit möglich.
Innerhalb von Sekunden können sie Fahrt
aufnehmen und abbremsen. Die Wellen
werden nicht gebrochen, sondern die
Energie der Wellen wird genutzt, um
schneller und langsamer zu werden. Jedoch
kann mit einem Surfbrett keine große
Menge auf einmal transportiert werden.
Auch weite Strecken können nicht am
Stück gefahren werden.
Wir haben in diesem Artikel beschrieben,
dass es einige Herausforderungen gibt,
wenn Surfer und Schweröltanker gemeinsam
dasselbe Ziel ansteuern. Unsere
Erfahrungen lassen sich wie folgt zusam -
menfassen:
■
Wichtig ist die Bildung eines persönlichen
Netzwerks, damit die richtigen
Leute zum richtigen Zeitpunkt
Entschei dungen treffen können. Ein
persönliches Netzwerk hilft besonders,
wenn man es mit einem funktional aufgestellten
Partner zu tun hat. Wenn das
persönliche Netzwerk Entscheidungs -
träger aus jedem Funktionsbereich des
Partners umspannt, können schnell die
richtigen Leute zusammengebracht und
eine Entscheidung herbeigeführt werden,
die ohne ein solches Netzwerk
Mo nate dauern würde.
■ Durch ein kommunikationsförderndes
Setup von Meeting-Räumen und eine
Moderation, die alle Meeting-Teil -
nehmer dazu bringt, sich zu engagieren,
werden aus Meeting-Marathons produktive
soziale Events, die das Team
zusammenschweißen.
■ Wenn man das Gefühl hat, dass der
Projektpartner bei einem bestimmten
Problem nicht die optimale Lösung
gewählt hat, sollte man durch Fragen
versuchen, die Beweggründe zu ermitteln.
Das schafft Verständnis und
Vertrauen. Fragen sind ebenfalls ein
gutes Mittel gegen Meeting-Mara -
thons. So kann schon im Vorfeld
hinterfragt werden, ob der Teilneh mer -
kreis der richtige ist oder ob es sinnvoll
ist, ein komplexes fachliches Problem
nach einem anstrengenden Arbeitstag
um 18:30 Uhr zu klären.
■ Räumliche Barrieren sollten soweit wie
möglich eliminiert werden, um die
Missverständnisse, die aufgrund von
fehlenden Kommunikationskanälen
entstehen, zu vermeiden. Gegen eine
räumliche Trennung hilft nur eins: Man
muss sich an einem gemeinsamen Ort
treffen und so oft wie möglich gemeinsam
arbeiten. Dadurch können auch
sprachliche Missverständnisse schneller
aufgelöst werden.
■ Das Infizieren von einzelnen Mitar -
beitern des Schweröltankers mit dem
agilen Virus führt dazu, dass Entschei -
dungen und Vorgehensweisen auch von
innen heraus angestoßen werden.
■
Veränderungen, die aus den eigenen
Reihen kommen, werden schneller
akzeptiert als solche, die von außen
kommen. Damit ist die aktive Verbrei -
tung des agilen Virus ein sehr gutes
Mittel gegen funktional aufgestellte
Partner. Diese Methode kann ebenfalls
benutzen werden, um Veränderungen
am wirtschaftlichen Setup zu erreichen.
Ist das Projekt dann so gestaltet, dass
alle Beteiligten am wirtschaftlichen
Erfolg partizipieren statt an der
Erbringung einzelner Leistungen, sind
die Weichen für eine erfolgreiche Zu -
sammenarbeit richtig gestellt. Das
Projekt-Setup entsprechend zu gestalten,
ist eine besonders schwere Auf gabe, die
nur durch gegenseitiges Verständnis und
Vertrauen zwischen den Projektpart nern
gemeistert werden kann. Alle in diesem
Artikel vorgestellten Werkzeuge helfen
dabei, genau das herzustellen.
In einer Welt voller Surfer und Schwer -
öltanker, die gemeinsam Projekte umsetzen
wollen, versuchen wir, unsere Erfahrungen
zu teilen. Unser Ziel ist es, dass auch andere
Surfer gemeinsam mit Schweröltankern
ans Ziel gelangen.
■
Literatur
[App12] J. Appelo, How to Change the World:
Change Management 3.0, Jojo Ventures BV
2012
Vorsprung durch Schulungen von innoQ
Certified Professional for Software Architecture (iSAQB ® ) ·
Ruby on Rails · RESTful HTTP · Cloud Computing · Webarchitektur
www.innoQ.com/training
Unsere Standorte in Ihrer Nähe: Düsseldorf · Frankfurt · München · Zürich

WIR
SUCHEN
DICH!
SOA
SCRUM
CMS
KONZEPTION
TESTING
BPM
.NET
EAI
PROJEKTMANAGEMENT
SHAREPOINT
CRM
IDENTITY MANAGEMENT
BIZTALK
ANALYSE
Acando freut sich
auf neue Kollegen
mit Microsoft- oder
Java-Know-how
Consultant bei Acando
Die Acando Group ist eine internationale Management- und IT-Beratung mit Sitz in Stockholm. Rund 1.000 Mitarbeiterinnen
und Mitarbeiter in fünf Ländern machen Acando mit ihrem Know-how und ihrer Leidenschaft zu einem
angesehenen Dienstleister auf dem europäischen Markt. In Deutschland sind wir rund 300 Kolleginnen und Kollegen
am Hauptstandort im Herzen von Hamburg und in vier weiteren Metropolen. Vielseitige Projekte, ein transparentes
Karriere-Konzept und aktiv gelebter Teamgeist zeichnen Acando als attraktiven Arbeitgeber für Berufseinsteiger und
erfahrene Experten aus.
Consultants für die Standorte
Hamburg, Düsseldorf, Frankfurt a. M., Stuttgart, München
Kontakt
Franziska Schlüter
Bewerbung
www.acando.de

expedITion-Workshops
– jetzt bewerben –
Capgemini-expedITion.de
Schließlich haben wir das Wichtigste ja gemeinsam und sehen IT-Architektur nicht
als Bereich, sondern als etwas, das uns jeden Tag aufs Neue begeistert. Klingt
inspirierend? Dann sehen Sie sich unsere Angebote für angehende und erfahrene
IT-Architekten an, die unter www.de.capgemini.com/karriere-technology schon auf
Sie warten. Zum Beispiel:
IT-Architekt (m/w) Public Sector
IT-Architekt (m/w) Banken und Versicherungen
IT-Architekt (m/w) Logistik
IT-Architekt (m/w) Automotive
Substanz? Herzlich? Willkommen!

Machen Sie Karriere
SW-Testautomatisierer (m/w)
Dienstort: München, Wien, Linz, Graz oder Lustenau
Unsere Testautomatomatisierer werden nach einer eingehenden
Certified Tester Schulung und Tool-Einarbeitung laufend
in spannenden Entwicklungsprojekten zur Qualitätssicherung
von Software und neuen Technologien eingesetzt.
Ihre Aufgaben- und Verantwortungsbereiche:
▪ Testautomatisierung
▪ Entwicklung von Test-Frameworks
▪ Erstellung von Testtreibern und -Scripts
▪ Durchführung von Software-Tests inkl. Testprotokollierung
Wir freuen uns über folgende Eigenschaften:
▪ Fundierte Erfahrung und entsprechende Ausbildung in der
Software-Entwicklung (Informatik HTL, FH, UNI)
▪ Sehr gute Kenntnisse in Java- oder .Net-Entwicklungsumgebungen
▪ Erfahrung im Software-Test von Vorteil (z.B. Unit-Test-
Erstellung oder sonstige Testautomatisierung; wird durch
unser Ausbildungsprogramm ergänzt)
▪ Kenntnisse von Testautomatisierungstools
von Vorteil
▪ Genauigkeit und analytisches Denken
▪ Reisebereitschaft (projektabhängig)
▪ Persönliches Engagement
Trainer und Berater (m/w)
Dienstort: München, Wien, Linz, Graz oder Lustenau
Ihre Aufgaben- und Verantwortungsbereiche:
▪ Durchführen von Trainings in den Bereichen ISTQB, IREB,
ISAQB, Software-Testing und Qualitätsmanagement
▪ Beratung in IT-Qualitätsmanagement, Software- und
System-Qualitätsmanagement
▪ Methodische Beratung
(z.B. Requirements-Engineering,
Testen, Review-Techniken)
▪ IT-Prozess-Beratung, Prozess-
Analysen bei unseren Kunden
Wir freuen uns über folgende Eigenschaften:
▪ Fundierte Ausbildung (z.B. Studium Wirtschafts-
Informatik, Informatik oder entsprechende andere
Weiterbildungen)
▪ Mindestens 5 Jahre praktische Erfahrung in Entwicklung,
Projektmanagement oder Qualitätsmanagement von SW
▪ Wenn möglich bereits Erfahrung als
Trainer in SW-Entwicklungsthemen
▪ Kommunikative und offene
Persönlichkeit
▪ Seriöses Auftreten
▪ Reisebereitschaft
▪ Persönliches Engagement
Wir bieten Ihnen
▪
▪
▪
▪
▪
▪
▪
Attraktive Position mit Entwicklungspotential in einem jungen und dynamisch wachsenden Unternehmen
Persönlich beeinflussbare Verantwortungsbereiche sowie interessante Zukunftsperspektiven
Laufende Aus- und Weiterbildung
Gutes leistungsorientiertes Gehaltspaket: außergewöhnliches Engagement und Erfolg werden belohnt!
Moderne Arbeitsmittel und flexibles Arbeitszeitmodell
Unterschiedliche Benefits und Sozialleistungen
Corporate Social Responsibility
Bewerben Sie sich jetzt!
www.software-quality-lab.com/karriere/
2013 Besuchen Sie uns bei den
Software Quality Days 2013!
Jetzt online anmelden! www.software-quality-days.com

Zukunft bewegen.
„Lösungen für die Zukunft entwickeln.
Und die eigenen Karrierechancen.
Bei DB Systel.“
Die Deutsche Bahn ist ein führendes Mobilitäts- und Logistikunternehmen. Unsere
Tochter DB Systel GmbH ist einer der größten Anbieter von ICT-Services in Deutschland
und deckt dabei den gesamten Lebenszyklus von ICT-Lösungen ab. Von der strategischen
Planung über die fachliche Analyse und die Entwicklung bis hin zu Betrieb und kontinuierlicher
Optimierung.
Wir suchen zum nächstmöglichen Termin in Frankfurt am Main engagierte
(Senior-)Softwareentwickler und Technische Architekturexperten
u. a. für folgende Technologieschwerpunkte:
SAP, BusinessObjects, SharePoint
JEE, Oracle, DB2
Mobile Applikationen (iOS, BlackBerry, Android)
EAI, SOA, MDM, BPM
Ihr Profil:
abgeschlossenes einschlägiges Studium an einer Hochschule oder Fachhochschule
oder durch entsprechende einschlägige berufliche Erfahrung erworbene Kenntnisse
im Tätigkeitsbereich und angrenzenden Aufgabengebieten
gute Englischkenntnisse in Wort und Schrift
Kommunikations- und Teamfähigkeit
hohe Kunden- und Serviceorientierung
Ziel- und Ergebnisorientierung
Zuverlässigkeit und Verantwortungsbewusstsein
Interessiert? Dann senden Sie Ihre aussagekräftige Bewerbung bitte unter Angabe des
Ausschreibungskennworts, Ihres frühestmöglichen Eintrittstermins und Ihrer Jahresbrutto-
Gehaltsvorstellung an:
DB Mobility Logistics AG
Personalgewinnung
Bewerbermanagement Professionals
Ausschreibungskennwort: OBJEKTspektrum Softwareentwicklung
Caroline-Michaelis-Str. 5–11
10115 Berlin
E-Mail: bewerbung@dbsystel.de
Fragen beantworten wir Ihnen unter unserer Bewerberhotline gerne montags bis freitags von
10:00 bis 12:00 Uhr und von 14:00 bis 16:00 Uhr unter der Telefonnummer 069 265-18601.
Informationen zur DB als Arbeitgeber und zu den vielfältigen Einstiegsmöglichkeiten erhalten
Sie unter www.deutschebahn.com/karriere sowie unter www.dbsystel.de/karriere.

0 5
Unterstützung im
Softwareprojekt
cover_OS_05_12:cover_OS_05_09.qxd 03.08.12 10:53 Seite 1
Poster zu
GUI-Technologien
www.OBJEKTspektrum.de
SCHWERPUNKT: AGILE@ENTERPRISE
G 6540F
September/ Oktober 2012 • Nr. 5
€ 8,90 Österreich € 9,90 Schweiz sfr 16,50
Die Zeitschrift für Software-Engineering und -Management
SCHWERPUNKT: AGILE@ENTERPRISE
Agiles Management – ein Widerspruch in sich?
Praxisbeispiel: Allianz Global Insurance
Zertifizierungsmöglichkeiten
INTERVIEW MIT KEN SCHWABER: „Agilität ist keine Methode”
FACHARTIKELTotal Quality Management in der IT
COBOL im 21. Jahrhundert
Jeden Tag sind Sie aktiv in Softwareentwicklungsprojekten
involviert und managen sie. Wie erläutern Sie Ihrem
übergeordneten Projektverantwortlichen die neuesten Trends
und belegen die Wirtschaftlichkeit der richtigen Technologie?
OBJEKTspektrum unterstützt Sie bei der Argumentation
und liefert Ihnen wertvolle Anregungen für den Alltag
des Software-Engineerings.
JavaSPEKTRUM ist das Praxismagazin für professionelle
Softwarearchitekten und Entwickler, die mit der Java-Plattform
arbeiten. Das Heft stellt neue Entwicklungen und Konzepte vor, prüft
die Relevanz für den täglichen Einsatz. Es werden aktuelle Themen
wie Aspektorientierung, Agilität, Eclipse, Embedded vertieft. Wie
Java mit anderen Plattformen in der Praxis effizient interagieren
kann, erfahren Sie in der Rubrik „Integrationsspektrum“.
Java SPEKTRUM
Alle Jahresabonnementen erhalten einen persönlichen Login zu allen Artikel-pdfs.
Wir benötigen hierfür unbedingt Ihre e-Mail-Adresse.
Bitte schicken uns diesen Bestellschein ausgefüllt per Fax (+49 (0)2241/2341-199)
zurück oder gehen Sie online unter www.sigs.de/publications/aboservice.htm
Schwerpunkt Java in the box: Mobil, Embedded, Robotik
G30325 www.javaspektrum.de
Ste lenmarkt
ab Seite 41
weitere Angebote
online
AUSGABE 5 · Oktober / November ’12
D / 6,40 · A / 7,30 · SFR 12,50
mit Integrations-
4 1 9 4 1 5 6 1 0 6 4 0 5
Magazin für professionelle Entwicklung und Integration von Enterprise-Systemen
Schwerpunkt
Java in the box:
Mobil, Embedded, Robotik
Unternehmensanwendungen
mit
Oracle ADF Mobile
Echtzeit-Java-Technologie
in sicherheitskritischen
Systemen
Javas Erfolg
in der Industrie
Java 7: Das Fork-Join-Framework
für mehr Performance
Testen – Teil 3: Feinabstimmung
von Entwickler- und Testteams
Eine Lanze für XML brechen
mit
Java User Group-
Terminen
cover_JS_05_12.in d 1 29.08.12 08:25
+++ Jetzt bestellen +++
Hiermit bestelle ich
ein Mini-Abo mit 3 Ausgaben für nur 15,00 €:
q OBJEKTspektrum* q JavaSPEKTRUM*
*wandelt sich automatisch in Jahresabo um, wenn nicht 6 Wochen vor Ende des Bezugszeitraums gekündigt wird
ein Jahresabonnement: Deutschland Europa Auß. Europa
OBJEKTspektrum (OS) q 50,90 € q 58,60 € q 63,60 €
JavaSPEKTRUM (JS) q 36,60 € q 42,00 € q 49,00 €
Kombi-Abo (OS+JS) q 81,30 € q 95,40 € q 105,00 €
ein kostenloses Probeheft
q OBJEKTspektrum q JavaSPEKTRUM
Firma:
Name:
Straße:
Telefon:
e-Mail:
Zahlungswunsch: q per Rechnung
Abteilung:
Vorname:
L/PLZ/Ort:
Telefax:
Position:
q per Kreditkarte – wir rufen Sie an unter Tel.-Nr.:
q per Bankeinzug Kto.-Nr.: BLZ: Bank:
Datum:
Unterschrift:
Verlagsanschrift: SIGS DATACOM GmbH, Lindlaustr. 2c, 53842 Troisdorf, Tel.-Nr.: +49 (0) 2241/2341-100, Fax-Nr.: +49 (0) 2241/2341-199, info@sigs-datacom.de
Die vollständigen AGBs finden Sie unter http://www.sigs-datacom.de/agb/

fachartikel
der autor
m e h r z u m t h e m a :
vector.com/RE-Buch
vector.com/RE-Publikationen
ANFORDERUNGEN ERMITTELN:
ZEHN SCHRITTE FÜR DIE PRAXIS
Eine Anforderung beschreibt, was der Kunde oder Benutzer vom Produkt erwarten. Dies
umfasst Ziele, Nutzen, Funktionen, Qualitätseigenschaften und Randbedingungen. Doch woher
kommen die Anforderungen? Sammelt man Anforderungen nur ein, floppt das spätere
Produkt, weil die Eigenschaften fehlen, die ein Produkt erst richtig attraktiv machen.
Anforderungen müssen gezielt entwickelt werden – und das ist nicht einfach. Im Folgenden
beschreibe ich die methodische Ermittlung von Anforderungen in zehn Schritten. 1 )
Christof Ebert
(Christof.Ebert@vector.com)
ist Geschäftsführer der Vector Consulting Services.
Er unterstützt Unternehmen weltweit bei der
Optimierung ihrer Produktentwicklung und
-strategie sowie im Veränderungsmanagement.
Er lehrt an der Universität Stuttgart.
Erfolgreiche Anforderungen
Die Saturn-V-Rakete ist die größte jemals
gebaute Rakete. Mit ihr wurden die ersten
Menschen zum Mond gebracht. Der deutsche
Wernher von Braun wusste als ihr
Konstrukteur, dass der Schlüssel zum Er -
folg in abgestimmten Anforderungen lag.
Eine wichtige Anforderung war, wie viel
Gewicht die Saturn V transportieren muss.
Das war eine fundamentale Anforderung
im gesamten Raumfahrtprogramm, denn
nur mit ausreichend Schub konnte die
Raumkapsel die Erde verlassen. Doch verschiedene
kritische Anforderungen hingen
voneinander ab: Startgewicht, Manövrier -
fähigkeit und auch die große Menge
Treibstoff waren bei starkem Schub kaum
beherrschbar. Was tun? Von Braun analysierte
die Anforderungen und Randbe din -
gungen und erhielt vom NASA-Manage -
ment nach einiger Zeit die Antwort, dass
die Raumkapsel maximal 34 Tonnen wiegen
würde. Diese Schätzung wäre verlässlich,
wäre sicher genug und er solle nun die
Rakete dazu konstruieren. Von Braun
machte weitere methodische Analysen und
kommunizierte seinen Entwicklungsleitern,
dass die Rakete eine Zuladung von 40
Tonnen transportieren müsse. Das erforderte
substanzielle Änderungen des ur -
sprüng lichen Designs, beispielsweise fünf
statt vier Triebwerke.
Einige Jahre später kam dann die Apollo-
11-Kapsel zum Start – und wog 50 Tonnen.
Der Start der Saturn mit dieser Zuladung
gelang zwar gerade noch, wäre aber mit
den ursprünglichen Anforderungen
geschei tert. Der Rest ist Geschichte – und
zeigt die Bedeutung einer methodischen
Anforderungsermittlung.
Software- und IT-Projekte sind häufig in
der gleichen Situation. Die Anforderungen
sind unsicher und demzufolge sind die
Schätzungen von Dauern, Produktivität
und Kosten falsch. Zusätzliches Budget
und einen Zeitpuffer hinzuzufügen, ergibt
aber auch keinen Sinn, denn man weiß ja
gar nicht, auf welcher Basis geschätzt werden
soll. Und jeder Personentag mehr
macht das Projekt teurer. Der Software-
Guru Tom DeMarco, der inzwischen auf
fünfzig Jahre Erfahrungen mit verkorksten
IT-Projekten zurückblickt, fasst seine
Erfahrungen lapidar wie folgt zusammen:
„Früher dachte ich, Termin- und Budget -
überschreitungen kommen von schlechter
Schätzung und Planung. Dann dachte ich,
sie kommen von der hohen Komplexität.
Heute weiß ich, dass sie davon kommen,
dass praktisch jedes Projekt falsch begonnen
wird. Dann fehlt die Zeit für
Anforderungsanalyse und Planung. Und
damit ist das Scheitern vorprogrammiert.“
Anforderungen kommunizieren Bedürf -
nisse und Randbedingungen. Das Require -
ments Engineering (RE) ist die Disziplin,
die die Behandlung von Anforderungen
über den gesamten Lebenszyklus der
Software hinweg umfasst. RE – und dabei
insbesondere die Ermittlung von Anfor -
erungen – ist schwierig in der Umsetzung,
da es zwar viele Interessengruppen gibt
(siehe Abbildung 1), die sich gerne überall
1P)
Dieser Artikel basiert teilweise auf dem Buch
„Systematisches Requirements Engineering“ von
Christof Ebert (vgl. [Ebe12]).
Abb. 1: Herausforderung: Viele Interessengruppen mit eigenen Zielen.
6 / 2 012

Das Ziel ist, die ursächlichen Fragen und
die Umgebung oder die Kunden des
Auftraggebers zu verstehen und Lösungen
für bestehende Bedürfnisse zu entwickeln.
Hierbei kommt dem Marketing eine
Schlüssel rolle zu – vor allem bei Lösungen,
die verschiedene Kunden als Markt adressieren
sollen. Daher verlangt dieser Schritt
eine kommerzielle Analyse des Markts, der
Wettbewerber, der Preise und deren Elas ti -
zität sowie der Segmentierung des Markts.
Häufig resultieren aus diesem ersten Schritt
sehr viele Ideen, die nicht notwendigerweise
realisiert werden (siehe Abbildung 2).
Diese Ideen müssen aber dokumentiert
werden, um nichts zu übersehen und sie
dann methodisch zu bewerten und zu reduzieren.
Während der Ermittlung treten viefachartikel
einmischen, sich aber nicht festlegen wollen.
Vielfältige und oft sich widersprechende
Interessengeflechte bei Auftragnehmer
und Auftraggeber verschärfen die Situa -
tion. Projekte scheitern daher vor allem
wegen eines unzureichenden RE (vgl.
[Ebe12]). Das sollte Grund genug sein, sich
intensiver mit der Ermittlung von
Anforderungen zu befassen. Wir betrachten
daher die Ermittlung von Anfor -
derungen im Folgenden methodisch und
anhand von konkreten Schritten, die sich in
die Praxis umsetzen lassen.
Schritt 1: Stakeholder und
Interessengruppen klären
Klären Sie zuerst die relevanten Stake -
holder und die rechtliche Verbindlichkeit
der Anforderungen. Es geht um einen
Vertrag, den Sie erfüllen wollen. Also muss
von Beginn an klar sein, wer die relevanten
Vertragspartner sind. Dieser Schritt beantwortet
die Fragen: Wer stellt überhaupt die
Anforderungen und bezahlt für das
Produkt oder Projekt? Wer hat Interesse am
Erfolg des Projekts? Wie kommuniziert das
Projekt mit dem Kunden? Welche Schnitt -
stellen mit dem Kunden oder dessen
Interessengruppen existieren? Wie sehen
das Reporting und die Eskalationswege
aus?
Interessengruppen werden nach Kunden,
Lieferanten, Vertriebspartnern und firmeninternen
Gruppen unterschieden. Nehmen
Sie diese verschiedenen Perspektiven explizit
ein, z. B. Auftraggeber, Benutzer, Ent -
wickler, Geschäftsleitung. Prüfen Sie, in
welchem Verhältnis diese Gruppen zueinander
stehen. Fragen Sie grundsätzlich
jeden Gesprächspartner danach, ob er sich
weitere Personen vorstellen kann, die eine
wichtige Rolle spielen könnten.
RE bedeutet Zusammenarbeit. Abbil -
dung 1 verdeutlicht einige der Schlüssel -
rollen, die bei der Definition und Bearbei -
tung von Anforderungen eine Rolle spielen.
Sie sind um typische Dokumente des RE
herum gruppiert. Damit wird unterstrichen,
dass RE formale Artefakte liefert,
anhand derer Vereinbarungen getroffen
und ausgetauscht werden. Wie bei jedem
Prozess kann man geteilter Meinung darüber
sein, ob man ihn personen- bzw. rollenorientiert
beschreibt oder eher dokumentenzentrisch.
Beides muss adressiert
werden, denn zu einem Prozess gehören
sowohl die Aus führenden als auch die
Ergebnisse. Es hängt eher von der
Prozessreife ab, ob die Perso nen den
Prozess stark beeinflussen oder ob ein
Unternehmen versucht, den Prozess unabhängig
von der Situation und den beteiligten
Interessengruppen zu stabilisieren und
damit auch verbesserungsfähig zu machen.
Neben den offensichtlichen Rollen, wie
beispielsweise den Kunden, dem Projekt -
manager oder der Entwicklung, gibt es
auch weniger auffällige Rollen, die aber
trotzdem zusammenspielen müssen. Die
Geschäftsführung und das obere Manage -
ment sind wichtig für RE, da sie die
Geschäfts- und Projektziele definieren,
anhand derer die Anforderungen bewertet
werden. Ein Produktmanager wiederum
muss zwischen Vertrieb, Entwicklung und
Projektmanagement vermitteln, um Um -
satz- und Gewinnziele zu erreichen.
Während eine Projektmanagerin daran
gemessen wird, ob sie ihr Projekt pünktlich
und mit der richtigen Qualität abschließt,
wird der Vertrieb anhand von Verkaufs -
zahlen bewertet. Ein typischer Zielkonflikt
zwischen diesen beiden Rollen ist die
Stabilität von Anforderungen. Ein Verkäu -
fer ist immer bereit, die Anforderungen
opportunistisch anzupassen, um die
Verkaufszahlen in die Höhe zu treiben. Die
Projektmanagerin auf der anderen Seite
will ihr Projekt in trockene Tücher bringen
und ist daher an Stabilität interessiert.
Hier kommt nun der Produktmanager
ins Spiel, der am Langzeiterfolg und am
gesamten Ergebnis der Produktlinie gemessen
wird. Er muss beide Ziele optimieren:
die Kosten und den Umsatz. Denn nur
dann stimmt der Gewinn. Ähnlich verhält
es sich mit der Geschäftsleitung oder ihrem
jeweiligen Management. Wer kennt es
nicht, das Phänomen, dass Kunden und
Geschäftsleitung ihre naturgemäß engen
Kontakte auch nutzen, um neue Ideen zu
konkretisieren, und dabei häufig Zusagen
machen, die niemals mit der unternehmerischen
Realität abgestimmt waren? Es ist
einfach zu verlockend, einen neuen oder
erweiterten Auftrag an Land zu ziehen.
Kunden haben ihr eigenes Geschäft und
stehen nicht beliebig für Diskussionen zur
Verfügung. Das ist übrigens ein wesentlicher
Grund dafür, weshalb agile Vor -
gehensweisen nicht immer so einfach
umzusetzen sind, wie es deren Protago -
nisten glauben machen. Soweit der Kunde
nicht direkt für Gespräche oder Workshops
zur Verfügung steht, übernimmt intern der
Produktmanager die Rolle des Kunden.
Der Vertrieb oder das Marketing können
diese Rolle auch spielen, allerdings sollte
man Zielkonflikte vermeiden, die darin
bestehen, dass der Vertrieb beispielsweise
nur eine Region oder einen aktuellen
Kunden konkret abdeckt und den Erfolg an
diesen Umsatzzahlen misst, während das
Produkt eine weitaus größere Ausdehnung
hat.
Schritt 2: Kritische
Erfolgsfaktoren identifizieren
In diesem Schritt geht es darum, zu verstehen,
was den Kunden, Benutzer oder
Markt wirklich bewegt und wie das eigene
zukünftige Produkt darauf einen positiven
Einfluss nehmen kann. Was ist dem
Kunden wirklich wichtig? Was ist in seinen
Augen der größte Nutzen? Hinterfragen Sie
die Aussagen des Kunden. Was will er erreichen?
Was sind seine Beweggründe?
Welche Einflüsse und Bedingungen spielen
eine Rolle? Wichtig ist es, bereits in diesem
Schritt sauber zwischen Anforderungen
und Lösungen zu trennen.
Abb. 2: Ermittlung: Mögliche
Anforderungen erfassen.
62 63

Sie suchen gezielt nach Fachinformationen?
Bei WISSEN – der kostenlosen Online-Bibliothek
von SIGS DATACOM – sind Sie direkt am Ziel!
Hochkarätige Fachbeiträge, Praxisberichte, Interviews, Vorträge und Whitepaper –
alles ist online leicht auffindbar. Bei Suchmaschinen-Anfragen haben Sie den Aufwand,
bei den Ergebnissen die Spreu vom Weizen zu trennen und die qualitativ hochwertigen
Inhalte zu filtern, die Ihnen wirklich weiterhelfen.
Anders bei der Online-Bibliothek WISSEN!
Hier haben Sie – in gewohnter Qualität von OBJEKTspektrum und JavaSPEKTRUM –
kostenlos Zugriff auf vielfältige Fachinformationen. Namhafte Evangelisten und Experten
aus der Branche haben die Inhalte vorstrukturiert nach Ihren Anforderungen.
Sie wissen genau was und wie Sie suchen und welche Informationen Sie benötigen.
Aktuell unterstützen 13 Themenchannel
Sie bei Ihrer täglichen Arbeit:
Software-Architektur
Projektmanagement Mobile
Software-Qualität und Testen
Softskills
Java
IT-Management
Embedded
Scrum und Agile
SOA und BPM
Cloud Computing
Requirements Engineering
Modelling
Überzeugen Sie sich selbst unter www.sigs-datacom.de/wissen/themenchannel

fachartikel
Sicht auf die Kunden der eigenen Kunden
offensichtlich, dass eine Lösung für deren
eigene Probleme zu neuen Diensten und
damit zu Wertschöpfung führt.
Abb. 3: RE schafft Konflikte.
le Konflikte zutage (siehe Abbildung 3).
Beispiele für Konflikte sind:
■ Eine Vielfalt von Funktionen und Ab -
hän gigkeiten zwischen diesen Funk -
tionen.
■ Verschiedene Schlüsselgruppen auf der
Kundenseite, z. B. Einkauf vs. Benutzer
vs. Administratoren.
■ Sich widersprechende inhaltliche Ziele,
z. B. Funktionalität vs. Kosten und
Budget, Qualität vs. Entwicklungszeit,
Kosten für geplante Qualität vs. aktuelle
Entwicklungszeit.
■ Technische Implikationen, z. B. Sicher -
heit vs. Zugriffsmöglichkeiten.
Derartige Konflikte sind normal. Das liegt
an den verschiedenen Perspektiven, aber
auch daran, dass man gerne aneinander
vorbeiredet, um kritische Erfolgsfaktoren
aus der eigenen Perspektive zu festigen.
Lösen Sie Konflikte sofort auf, denn
sonst rächen sie sich später durch Nach -
arbeiten oder kontinuierliches Hinterfra -
gen. Das Erkennen und Auflösen von
Konflikten ist der eigentliche kreative
Prozess der Anforderungsermittlung, denn
es werden sowohl technische als auch
betriebswirtschaftliche und menschliche
Randbedingungen berücksichtigt. Ob
Konflikte eskalieren und wie gut wir sie
auflösen können, hängt mit unserer Kom -
munikationsfähigkeit zusammen (vgl.
[Sch10]). Getroffene Entscheidungen – also
Annahmen, Randbedingungen und Priori -
täten – müssen als Vereinbarungen unterzeichnet
werden.
Schaffen Sie Win-Win-Positionen im
Herausarbeiten der kritischen Erfolgsfak -
toren. Nehmen wir an, ein Hersteller von
Aufzügen will diese direkt mit einem eigenen
Rechner koppeln, um die Adminis -
tration und den Service zu vereinfachen.
Kunden sind dem zunächst abgeneigt, da es
die Komplexität erhöht und keinen offensichtlichen
Mehrwert schafft. Nun entwi -
ckelt der Hersteller eine Zusatzfunktion, mit
der automatisch Notrufe sicher übertragen
werden, was für den Kunden die eigenen
Aufwände zur Überwachung reduziert.
Damit ist das für den Hersteller technisch
notwendige Feature auch für den Kunden
ein greifbarer Mehrwert. Hier wird deutlich,
dass ein Hersteller in der wirtschaftlichen
Gewinnkette immer den Punkt im Auge
behalten muss, der einen Wert erzeugt, für
den bezahlt wird. Häufig wird erst durch die
Abb. 4: Der Systemkontext.
Schritt 3: Vision, Umfang
und Kontext abstimmen
Anforderungen müssen einen Zusatznutzen
bieten, für den ein Kunde bereit ist zu zahlen.
Hier wird entschieden: Was wird sich
durch das Produkt konkret ändern? Wie
sieht die Änderung aus? Was wird durch
das Produkt besser oder anders?
Lassen Sie Funktionen bereits jetzt weg,
die der Kunde nicht wünscht oder bei denen
Quelle und Wert unklar sind. Notieren Sie
für alle extrahierten Anfor derungen immer
die Quelle und den wahrgenommenen Wert
aus Kundensicht. Achten Sie auf
Ausgewogenheit und Voll stän digkeit. Häufig
springen dem Analys ten oder Produkt -
manager sofort die neuen Funktionen ins
Auge, während Quali tätsan for derungen und
Randbedingungen vernachlässigt werden.
Klären Sie mit den relevanten Schlüssel -
personen, was der Kunde möchte und was
er braucht. Stimmen Sie mit ihm ab, was
Sie brauchen (z. B. Kostenanforderungen,
Randbedingungen, Qualitätsan forderun -
gen, Plattformvorgaben, technische Rand -
bedingungen). Divergenzen müssen jetzt
geklärt werden oder es wird nachher unzufriedene
Kunden geben. Aus Ihrem technischen
Wissen allein können Sie kaum eine
Verbindung zu den tatsächlichen Anfor -
derungen herstellen – Sie müssen sich in die
Kundensicht einarbeiten.
Danach werden Systemumgebung und
-kontext abgestimmt. Dabei wird zwischen
Problemraum und Lösungsraum unterschieden:
64 65

fachartikel
■ Der Problemraum entspricht der
Zielsetzung und den Anforderungen,
also dem, was zu tun ist.
■ Der Lösungsraum entspricht dem
Archi tekturentwurf und der Reali -
sierung, also wie das im Problemraum
definierte Ziel erreicht wird.
Anwendungsfälle helfen bei der Beschrei -
bung des Problemraums, um einzugrenzen,
was die Erfordernisse sind. Sie werden im
weiteren Schritt für den Entwurf des
Lösungsraumes genutzt. Die Schlüssel -
fragen lauten: In welcher Umgebung wird
das System eingesetzt? Was ist Bestandteil
des Systems und was nicht? Was sind die
Schnittstellen des Systems? Was ist das zu
entwickelnde System und was ist es nicht?
Der Lösungsraum wird durch diese
Anwen dungsfällte und Kontextdiagramme
festgelegt, also dadurch, welche Kompo -
nenten oder Lösungsbestandteile geliefert
werden müssen und daher Teil des Projekts
sind und welche Anteile bereits vorhanden
sind oder aber zu einem späteren Zeitpunkt
zur Verfügung stehen.
Der Systemkontext beschreibt die
Grenzen des zu entwickelnden Systems und
somit seiner Schnittstellen zur Außenwelt
(siehe Abbildung 4). Der Systemkontext
legt damit auch fest, was gemacht wird und
was nicht. Er beinhaltet Personen, andere
Systeme, Prozesse, Ereignisse und
Dokumente. Im Rahmen der Kontextab -
grenzung wird geklärt, welche Aspekte
durch das zu entwickelnde System abgedeckt
werden und welche Aspekte Teil der
Umgebung dieses Systems sind.
Jetzt werden die vielfältigen Schnittste -
llen des Systems identifiziert und spezifiziert,
also die Eingangs- und Ausgangs -
parameter eines interaktiven Systems oder
die physikalischen Schnittstellen eines eingebetteten
Systems. An dieser Stelle entscheidet
sich häufig auch bereits, wie portabel
die Lösung später einmal sein wird.
Wenn beispielsweise ein bestimmtes
Kommunika tions protokoll vorausgesetzt
wird, kann es später schwierig sein, dies zu
ändern. Halten Sie also die Schnittstellen so
abstrakt wie möglich oder isolieren Sie die
Schnittstellen vom restlichen Lösungsraum.
Dazu werden Use-Case-Diagramme eingesetzt,
die die Akteure in der System -
umgebung und deren Beziehungen zueinander
veranschaulichen (z. B., wer welche
Informationen nutzt). Auch Datenfluss-
Diagramme kommen zum Einsatz, um
Quellen und Senken in der Systemumge -
Abb. 5: Ermittlung: Vision und Umfang
festlegen.
bung mit Datenflüssen zum und vom
System darzustellen. Als Ergebnis dieses
Schritts sind einige Ideen gestrichen und die
Vision, der Umfang und der Kontext des
Produkts stehen fest (siehe Abbildung 5).
Schritt 4: Anforderungen
methodisch entwickeln
Nun werden die Anforderungen an die spätere
Lösung konkret identifiziert und entwickelt.
Das umfasst sowohl die funktionalen
Anforderungen, also konkrete
Funk tionen, Algorithmen etc., als auch
Quali tätsanforderungen und Randbedin -
gun gen, wie z. B. Performance, Sicherheit
und gesetzliche Regelungen. Die entscheidende
Frage hier ist: Was sind jene
Eigenschaften, durch die sich die Lösung
später besser verkaufen lässt? Weshalb
investiert jemand in dieses Produkt?
Ermitteln Sie die Anforderungen zielorientiert.
In diesem Schritt ist die Struktur
noch untergeordnet, denn sie könnte die
Abb. 6: Ermittlung: Unbekannte Anforderungen identifizieren.
Kreativität einschränken oder Lösungs -
möglichkeiten und Zusammenhänge verstecken.
Check- und Fragelisten helfen
beim Extrahieren von Anforderungen, die
vielleicht sonst verborgen blieben. Die
Quellen für Anforderungen und für die
Bewertung, welche Anforderungen wesentlich
sind, sind vielfältig und sollten situativ
genutzt werden:
■ Marktforschung/Marktstudien, speziell
für neue Produkte, in den Bereichen
B2B und B2C.
■ Internet (Blogs, Foren, Bewertungen)
für Folgeprodukte und neue Funk -
tionen.
■ Eigene Forschung für neue Produkte.
■ Eigene Entwicklung.
■ Eigenes Marketing und Vertrieb.
■ Eigene Dienstleistungen für Folge pro -
dukte, Korrekturen und neue Funk -
tionen.
■ Benutzergruppen für Folgeprodukte,
speziell im Bereich B2B und B2C.
■ Kundeninterviews, Seminare und
Work shops.
■ Bestehende Lasten- und Pflichtenhefte.
■ Händler, Vertriebspartner für Folgepro -
duk te, Korrekturen und neue
Funktionen.
■ Berater (intern, extern) für Strategie -
definition, Vision und neue Produkte.
Unbekannte Anforderungen und Rand be -
dingungen sind schwierig zu ermitteln,
denn wir können nicht direkt danach fragen
(siehe Abbildung 6). Wir sollten uns
aber darüber im Klaren sein, dass es immer
6/2012

fachartikel
bung eines archetypischen hypothetischen
Benutzers und seiner Ziele, demografische
Daten, Verhaltens weisen,
Vorlieben sowie Herausar bei tung und
Typisierung der damit verbundenen
Anwendungsfälle, vgl. [Coo99]).
■ Kontextbewertung: Demografische
Analysen (d. h. Analyse von Daten und
Statistiken für bestimmte Märkte und
deren Verhalten, Kaufverhalten, Vorlie -
ben und Größe), ethnografische Analy -
sen, kulturelle Besonderheiten, Farben
und Symbolik.
Abb. 7: Ermittlung: Methodische Vervollständigung.
Perspektiven gibt, wo wir als Auftrag -
nehmer nicht alles wissen oder wo der Auf -
traggeber nicht alles weiß. Die Be reiche, wo
wir etwas wissen und der Benutzer oder
Kunde ebenfalls, wurden ja bereits adressiert.
Nun geht es darum, zu hinterfragen,
was wir nicht wissen (können) und was der
Benutzer oder Kunde nicht weiß.
Hilfsmittel, um Annahmen und Entschei -
dungen zu verdeutlichen, sind ein Baum -
diagramm, das die Anforderungen herunterbricht,
eine Durchführbarkeitsstudie
oder Prototyping, ein Modell, das
Annahmen beschreibt und untersucht, oder
Normen, die mit externen Randbedin gun -
gen vergleichen.
Betrachten Sie die Anforderungen im Zu -
sammenhang, um zu verstehen, welche
Anforderungen sich widersprechen oder
konkurrieren. Modellieren Sie Abhängig -
keiten, um die Machbarkeit der Lösung im
Kontext zu prüfen. Spielen Sie Szenarien
durch, auch solche, die nur ausnahmsweise
auftreten. Konflikte sind natürlich und
müssen dokumentiert, priorisiert und entschieden
werden. Nehmen Sie technische
oder projektinterne Konflikte nie persönlich.
Hier sind einige Techniken, um Anfor -
derungen methodisch zu ermitteln und zu
bewerten – gerade wenn wir als Auftrag -
nehmer oder der Auftraggeber nicht genau
wissen, um was es geht (siehe Abbildung 7):
■ Kunden und Marktstudien: Frage bö -
gen, Interviews, Analyse existierender
Dokumente. Das sind die häufigsten
Instrumente, um Anforderungen zu
ermitteln und zu entwickeln.
■ Kreativitätstechniken und Gruppen -
arbeit: Brainstorming, Fokusgruppen,
Rollenspiele und Workshops. Achtung:
Gruppenorientierte Techniken müssen
sorgfältig moderiert werden, denn sie
können auch zu Blockadesituationen
führen. Beispielsweise kann ein Brain -
storming bei starken Teilnehmern dazu
führen, dass gute Ideen der schwächeren
Teilnehmer unausgesprochen bleiben
und der Lösungsraum viel zu früh
eingeengt wird. Rollenspiele wiederum
erfordern ein gutes gegenseitiges
Verständnis und können nicht über
Hierarchieebenen oder Abteilungen
hinweg durchgeführt werden.
■ Schrittweise Ermittlung: Prototyping,
Simulation, Ablaufmodell, Benutzer -
schnitt stelle, Experimente, Konzept -
tests mit Kunden und Anforderungen
aus Benutzeraktivitäten synthetisieren.
■ Modelle und Analysen: Konzepte,
Szenarien, Bilder, Diagramme, strukturierte
und formalisierte Analysever -
fahren (z. B. strukturierte Analyse,
objekt orientierte Analyse, Joint Appli -
cation Development, Problem Frames,
QFD, FMEA), Anforderungen aus exis -
tierendem System herausarbeiten sowie
Glossar und Taxonomie als Verständ -
nishilfe aufbauen.
■ Kognitive Verfahren: Protokollanalyse,
Verhalten und Persona (d. h. Beschrei -
Nutzen Sie „negative Anforderungen“, um
Szenarien, Fälle und Verhalten zu beschreiben,
die nicht eintreten dürfen. Welche
Basisfaktoren können im nächsten Release
wegfallen? Welche Verhaltensweisen müssen
gezielt ausgeschlossen werden?
Negative Anforderungen werden in der
Spezifikation gleich gehandhabt wie die
bekannten „positiven Anforderungen“, mit
dem Unterschied, dass sie in der späteren
Entwicklung wirksam ausgeschlossen oder
in ihrer Wirkung abgeschwächt werden
müssen. Hier ein Beispiel:
■ M-Req-1: Bei geöffneten Türen darf der
Aufzug nicht fahren.
■ M-Req-2: Bei Betrieb und Wartung des
Aufzugs darf zu keinem Zeitpunkt,
auch nicht in Ausnahmesituationen,
eine Gefahr für Menschen ausgehen.
■ K-Req-1: Das Betriebssystem darf nicht
ausfallen.
Negative Anforderungen werden typischerweise
durch Misuse Cases, Abuse Cases
oder ganz banal als Anforderung, die als
„negativ“ deklariert wird, dargestellt. Im
Ergebnis sind einige neue Anforderungen
ermittelt.
Schritt 5: Anforderungen dokumentieren
und strukturieren
Anforderungen müssen systematisch erfasst
und beschrieben werden, um nachher bearbeitet
werden zu können. Dieser Schritt
beantwortet die Fragen: Wie kann ich die
Anforderungen so beschreiben und strukturieren,
dass ich sie später wiederfinden
kann? Wie hängen die Anforderungen zu -
sammen und können zur besseren Ver -
ständlichkeit gebündelt werden?
Die Anforderungen sollten hinreichend
gut beschrieben sein, um die Projektrisiken
abzuschwächen (vgl. [Dav05]). Eine Be -
schreibungssystematik dient dazu, Anfor -
66 67

interne und externe Abhängigkeiten besser
zu verstehen. Sie beantwortet die Frage: Ist
die vorgeschlagene Lösung hinreichend,
um die Anforderungen abzudecken? Ein
Lösungsmodell dient der Kommunikation
von bestimmten vorläufigen Lösungsent -
scheidungen, bevor mit dem Design oder
der Architektur begonnen wird. Beispiels -
weise beschreibt die Lösung, welche
Objekte oder Komponenten im System eingesetzt
werden und wie diese untereinander
und mit der Außenwelt kommunizieren.
Andere Modelle erläutern, wie Daten -
strukturen aussehen und wie darauf zugefachartikel
derungen zu separieren und sie lesbar zu
machen. Numerische Codes werden eingeführt,
damit jede einzelne Anforderung
identifizierbar und damit verfolgbar ist.
Die Nachverfolgung von Anforderungen ist
nicht nur während des Projekts wichtig,
sondern auch bereits für das spätere Änderungsmanagement.
Wie wollen Sie eine
Änderung kommunizieren, wenn Sie dazu
keine Referenz haben? Dazu eignen sich
vorgegebene Templates oder Datenbanken,
aber auch einfache Tabellen- oder Text -
programme.
Niemals sollten Anforderungen nur mit
Papier und Bleistift übernommen werden.
Das führt zu psychologischen Blockaden,
denn der Änderungsaufwand selbst für
kleinste Änderungen wird als zu groß empfunden.
Beschreiben Sie daher die
Anforderungen bereits frühzeitig in einem
offenen und änderungsfreundlichen Werk -
zeug.
Schritt 6: Anforderungen
modellieren
Der Problemraum wird modelliert, um Zu -
sam menhänge zu erkennen. Die Schlüssel -
Abb. 8: Anforderungen und Bedürfnisse bewerten.
fragen sind: Wie hängen die Anforderungen
zusammen? Welche Einflüsse aus der
Umgebung und untereinander treten auf?
Die Modellierung ist zwangsläufig eine
Randbedingung der Realität, um bestimmte
Blickwinkel einzunehmen oder bestimmte
Fragestellungen zu beantworten. Bei -
spiels weise kann ein Anforderungsmodell
die zeitlichen Abhängigkeiten von externen
Szenarien beschreiben oder es kann auf
Anwendungsfälle (Use-Cases) eingehen.
Ähnlich wie die Modellierung des Pro -
blemraums dient die Modellierung des
Lösungsraums dazu, die Lösung und deren
GEWINNER!
Leserbefragung
1. Preis
5 Tage
OOP2013
software meets business
21. – 25. Januar 2013, München
Carsten Sydow
www.javaspektrum.de
www.objektspektrum.de
2. Preis
2-tägiges
Seminar
Matthias Gutheil
SIGS-DATACOM GmbH
Lindlaustraße 2c
53842 Troisdorf
Tel.: +49 (0)2241 2341-100
Fax: +49 (0)2241 2341-199
Email: info@sigs-datacom.de
3. – 15. Preis
Fachbücher
Mario Beyeler
Björn Kimminich
Jose Marin
Ralph Nelius
Harald Radlinger
Michael Schneider
Jürgen Schiewe
Gerald Simon
Michael Siwak
Michael Starck
Frank Ullrich
Jan Windhuysen
Reto Zenger
6/2012

fachartikel
Beispiel: Gefahrenanalyse
System: Aufzug
Subsystem: Seilzug-Feststellbremse
1) Kritischer Use-Case: Was muss unbedingt funktionieren? Beispiel: Aus der Funk -
tionsbeschreibung von Servo-Mechanik, Seilzug, Elektromotor, und Ansteuer -
elektronik lassen sich kritische Use-Cases oder mögliche Unfallszenarien identifizieren.
Nach der Abwärtsfahrt mit vielen Haltepunkten steht der Aufzug und wird
durch die Seilzug-Feststellbremse abgesichert. Die aufgebrachte Zuspannkraft
sichert die Kabine gegen minimale Bewegungen.
2) Fehlfunktionen: Welche Fehlfunktionen können auftreten? Methoden: Gefahren -
analyse, System-FMEA und Komponenten-FMEA, Misuse-Cases. Beispiel: Die
Zuspannkraft kann sich physikalisch beim Abkühlen des Seil-Brems-Systems soweit
verringern, dass die Kabine nicht mehr ausreichend gesichert ist
3) Bewertung: Wie kritisch ist die jeweilige Fehlfunktion? Methoden: FTA (Fault Tree
Analysis), FMEDA (Failure Modes, Effects and Diagnostic Coverage Analysis),
Zuverlässigkeitsdiagramme. Beispiel: Aufzüge können Personenschäden verursachen.
Daher Bewertung mit SIL (Safety Integrity Level) 3.
4) Schutzziel: Wie muss eine noch fehlende Produktanforderung aussehen? Beispiel:
Nach jeder Bewegung muss die Kabine ausreichend gesichert sein.
5) Umsetzung: Wie muss die zugehörige Komponenten-Anforderung aussehen?
Beispiel: Aus den Schutzzielen leiten sich mit den Wie-Fragen die Sicher heits -
anforderungen auf Komponentenebene ab. „Welche Sicherheitsfunktion kann die
Fehlfunktion kompensieren?“ „Wie lässt sich die Sicherheitsfunktion umsetzen?“
Beispiel: Die beteiligten Elektronikkomponenten überwachen Kabinenbewegungen
auch nach Stillstand, um Seilverkürzungen durch Abkühlung entgegenzuwirken.
Kasten 1: Anforderungen und Bedürfnisse bewerten.
griffen wird. Bei eingebetteten Systemen
beschreibt ein Lösungsmodell zeitliche
Abhängigkeiten oder, wie auf äußere Erei -
gnisse reagiert wird.
Schritt 7: Anforderungen
analysieren
Entscheidend sind hier Antworten auf die
Fragen: Wie beeinflussen sich die Anfor -
derungen gegenseitig? Welche Anforderun -
gen ermöglichen Wiederverwendung?
Welche Anforderungen können so modifiziert
werden, dass sich Teile von früheren
Lösungen wiederverwenden lassen? Welche
Anforderungen verursachen den meisten
Aufwand? Welche tragen am meisten zu
den vorgegebenen Zielen bei? Gibt es
Anforderungen, die sehr viel Aufwand verursachen
und wenig Bezug zu den identifizierten
Zielen haben? Die Antworten aus
diesem Schritt beeinflussen typischerweise
die parallel laufenden Vertragsver hand -
lungen hinsichtlich der Angebotsgestal -
tung. Je nach der zur Verfügung stehenden
Zeit kann in diesem Schritt auch bereits
eine erste grobe Modellierung von Pro -
blem- und Lösungsraum erfolgen.
Nur mit einer begleitenden Analyse verstehen
Sie die Zusammenhänge und Rand -
be dingungen. Aus diesem Grund werden in
vielen Unternehmen die Personen, die
Anforderungen ermitteln, auch als System -
analysten bezeichnet. In dieser Analyse
geht es sowohl um das Produktmanage -
ment als auch um eine technische Analyse.
Häufig sind bestimmte Funktionen nicht
machbar oder Randbedingungen konkurrieren
miteinander. Manche Anforderungen
bedingen andere Anforderungen. Stellen
Sie fest, welche Abhängigkeiten (auch
ungewollte) bestehen. Prüfen Sie, ob die
Anforderungen hinreichend zur Wert -
schöp fung beitragen, sodass der Kunde
bereit ist, dafür Geld in die Hand zu nehmen.
Ermitteln Sie, was zum System und
was zu seiner Umwelt gehört. Mit der
Festlegung der System grenze entscheidet
sich der Zweck des Systems, d. h. welche
Leistung das System seiner Umwelt bringt
und wie es von außen genutzt wird.
Ein gutes Hilfsmittel zur initialen Bewer -
tung ist das Kano-Modell. Abbildung 8
zeigt die drei Faktoren (Basis-, Leistungsund
Begeisterungsfaktoren) aus dem Kano-
Modell. Die Punkte sind erfasste Anfor -
derungen. Diese werden nun für verschiedene
Perspektiven (oder Zielgruppen,
Rollen) jeweils in die drei Kategorien gruppiert.
Dann wird ausgewählt, was realisiert
wird. Die Abbildung zeigt, dass wenige
Begeisterungsfaktoren so ausgewählt werden,
dass für jede Zielgruppe ein Kauf -
anreiz geschaffen wird, ohne zu viel zu
investieren. Umgekehrt werden nicht alle
möglichen Basisfaktoren implementiert –
wohlwissend, dass dafür sowieso nicht
gezahlt wird.
Schritt 8: Anforderungen prüfen
Dieser Schritt beantwortet die Frage, ob die
Anforderungen die richtige Qualität haben.
Sind sie hinreichend beschrieben, um daraus
eine gute und brauchbare Lösung abzuleiten?
Die Prüfung von Anforderungen lohnt
sich. Fehler in Anforderungen sind im
Projekt selbst schwierig zu identifizieren
und teuer in ihrer Korrektur. Anfor -
derungen werden daher frühzeitig geprüft.
Keine andere Technik der Qualitätskon -
trolle hat einen solch hohen wirtschaftlichen
Nutzen wie die Prüfung von
Anforderungen (vgl. [Ebe07]). Korrekturen
während der Anforderungsentwicklung
und Dokumentation sind sehr viel günstiger
als spätere Nacharbeiten. Das gilt so -
wohl extern, beispielsweise durch die
Konsistenz der Entwicklungsergebnisse mit
Kundenerwartungen und Marktanfor -
derun gen, als auch intern, beispielsweise
durch brauchbare Spezifikationen (d. h.
Verständlichkeit, Vollständigkeit, Mach -
bar keit, Widerspruchsfreiheit usw.).
Eine gute Anforderung beschreibt etwas,
das notwendig, überprüfbar und erreichbar
ist. Notwendig ist eine Anforderung dann,
wenn durch ihr Verschwinden die Ab -
nahme oder die Vertragserfüllung infrage
gestellt wäre. Häufig gibt es allerdings keine
klare Antwort zum wirklichen Bedarf
oder Grenznutzen der spezifischen Anfor -
derung und man kann die Anforderung
streichen oder niedrig priorisieren. Überprüfbar
ist eine Anforderung dann, wenn
beim Lesen der Anforderungsspezifikation
68 69

fachartikel
■ Trennen Sie bei der Anforderungsermittlung zwischen der externen Sicht (Markt-
anforderungen, Bedürfnisse, Problembeschreibung) und der internen Sicht
(Produktanforderungen, Lösungskonzeption, Komponentenanforderungen).
■ Ermitteln Sie die Anforderungen systematisch. Nutzen Sie dazu Checklisten, Frage -
listen, Regeln für Workshops und Interviews, Analysemethoden, verständliche
Notationen und durchgängige Prüfverfahren.
■ Bilden Sie in der Spezifikation der Anforderungen drei Typen von Anforderungen:
Markt-, Produkt- und Komponentenanforderungen. Vermischen Sie diese drei verschiedenen
Sichtweisen nicht, denn sie helfen bei der Strukturierung und Entwick -
lung der späteren Lösung und bei der sauberen Behandlung von Änderungen auf
einer dieser drei Abstraktionsebenen.
■ Trennen Sie in Spezifikationen sauber zwischen „Was“ (Anforderungen) und „Wie“
(Lösungen). Beginnen Sie nicht zu früh mit der Lösung, solange noch nicht klar ist,
was die wesentlichen Bedürfnisse sind.
■ Modellieren Sie beim Übergang von der Problembeschreibung (z. B. Lastenheft) zur
Lösungskonzeption (z. B. Pflichtenheft) sowohl die Systemumgebung als auch die zu
entwickelnde Systemarchitektur. Beim Übergang zu den Komponentenan -
forderungen muss die Systemarchitektur bereits hinreichend detailliert sein, um
Auswirkungen von Entwurfsentscheidungen (z. B. Partitionierungen) bewerten zu
können.
■ Antworten Sie immer auf der Basis der Konsequenzen auf den Projektplan, falls es
zu Änderungsvorschlägen kommt. Begeben Sie sich nie in eine Situation, in der
Änderungswünsche isoliert von den Auswirkungen im Projekt und der Rückwirkung
auf andere Funktionen behandelt werden.
■ Lösen Sie Konflikte sofort auf, denn sonst rächen sie sich später durch Nacharbeiten
oder kontinuierliches Hinterfragen. Versuchen Sie, Win-Win-Ergebnisse zu erreichen.
■ Berücksichtigen Sie alle Anforderungen. Entscheiden Sie explizit, was übernommen
wird und was nicht. Fragen Sie relevante Interessenvertreter, ob etwas übersehen
wurde. Machen Sie dabei klar, dass die Ermittlung von Anforderungen noch keine
Garantie für deren Lieferung ist. Geliefert wird nur, was vereinbart und bezahlt wird.
■ Betrachten Sie die Anforderungsermittlung projektbegleitend. Als Prozess begleitet
es die weitere Entwicklung bis zum Projektabschluss und darüber hinaus in die
Betriebs- und Wartungsphase – bis zum Lebensende des Produkts.
■ Setzen Sie Methodik und Werkzeuge bei der Ermittlung situativ ein. Ein Werkzeug
allein bringt keine Verbesserung. Die Basis für gute Ergebnisse sind Systematik und
Disziplin. Zuerst muss ein schlanker Prozess für das RE für alle Projektbeteiligten
(auch Vertrieb) verpflichtend vereinbart werden. Anforderungen und deren Verwal -
tung können durch einfache Spreadsheets unterstützt werden.
■ Optimieren Sie das RE und Sie werden in den Projekten beträchtlichen Aufwand
sparen. Systematische Anforderungsermittlung reduziert Nacharbeiten, Zusatz -
aufwände durch Inkonsistenzen und Fehler, die erst spät entdeckt werden.
Kasten 2: Tipps für die Praxis.
klar wird, wie sie später getestet und abgenommen
wird. Erreichbar ist eine Anfor -
derung, wenn sie technisch möglich ist. Sie
darf nicht im Widerspruch zu anderen
Anforderungen und Randbedingungen, wie
Budget oder Übergabetermin, stehen.
Kasten 1 zeigt die systematische Erarbei -
tung von Qualitätszielen und daraus abgeleiteten
Prüfschritten, die dann zu einer
Vervollständigung der noch fehlenden
Anforderungen führen.
Schritt 9: Anforderungen
priorisieren
Die Priorisierung ist eine wirtschaftliche
Entscheidung, die vom Produktmanager
oder demjenigen getragen werden muss,
der für den kommerziellen Erfolg des
Produkts oder Projekts verantwortlich ist.
Sie erlaubt, bei Zeitdruck oder drohenden
Budgetüberschreitungen eher unwichtige
Funktionen herauszunehmen. Aus dem
Verhältnis von Aufwand und Nutzenbei -
trag lässt sich eine erste interne Priori -
sierung ableiten.
Die Kernfrage lautet: Welche Anfor -
derungen sind erfolgsentscheidend und
welche könnten vernachlässigt werden?
Idealerweise können Sie die Priorisierung
direkt mit dem Kunden verhandeln. Dieser
hat meistens ein Interesse an termingenauer
Lieferung und weiß um die Schwierig -
keiten, alle Anforderungen und Einflüsse
exakt abzuschätzen. Bedenken Sie, dass der
Kunde seine eigenen Geschäftsmodelle hat
– was für Sie wichtig oder unwichtig
erscheint, muss nicht auch für den Kunden
gelten. Versuchen Sie daher, das Geschäfts -
modell des Kunden immer wieder zu
hinterfragen, um zu prüfen, wie seine
Anforderungen dazu passen. Falls der
Kunde kein Interesse an der Priorisierung
hat oder falls diese nicht ausreichend ist
(z. B. wenn nur 10 % des Aufwands niedrig
priorisiert sind), muss diese Bewertng beim
Lieferanten intern übernommen werden,
beispielsweise durch den Key Account
Manager für diesen Kunden oder durch
den Vertrieb oder das Marketing. Die
Priorisierung darf nie allein im technischen
Bereich erfolgen.
Die Klassifikation der Anforderungen
baut auf der Priorisierung auf und bildet
die Anforderungen auf verschiedene
Inkremente, Iterationen oder Produkt -
versionen (Releases) ab. Sie unterscheidet
die Anforderungen auch nach der Art der
Realisierung. Beispielsweise sind manche
Anforderungen nicht technischer Natur
und verlangen nach organisatorischen
Änderungen beim Benutzer.
Schritt 10: Über
Annahmen und
Anforderungen entscheiden
Nun haben wir eine Menge von Rand -
bedingungen, Annahmen, Anforderungen,
Prioritäten und Abhängigkeiten herausgearbeitet,
modelliert und bewertet. Führen
Sie getroffene Annahmen, Randbe din -
gungen und Prioritäten immer wieder einer
Entscheidungen zu. Sind Sie noch auf Kurs?
Passen die getroffenen Annahmen zu den
Randbedingungen und Kundenzielen? Die
Entscheidung sollte iterativ nach jedem und
6/2012

fachartikel
teilweise in jedem der beschriebenen neun
Schritte geschehen, denn sonst wird es
unübersichtlich und aufwändig, sollte es zu
Änderungen kommen. Bei Kunden hatten
wir schon Fälle, wo die Anforderungen
nahezu fertig herausgearbeitet und analysiert
waren, um dann festzustellen, dass
wesentliche Zielgruppen und Interessen -
vertreter nicht berücksichtigt waren. Als
diese sich dann einbrachten, hatte sich die
Lage dadurch nochmals stark geändert.
Solche Entscheidungen können sowohl
intern als auch extern fallen. Prioritäten
aus Kundensicht werden vorzugsweise
direkt mit den Kunden getroffen. Sie werden
aber nicht sofort zugesichert, denn
noch sind Aufwände und Implikationen
nicht bewertet. Daher erfolgt die endgültige
Priorisierung immer intern. Nur so wird die
bestmögliche Konvergenz von Zielen und
Randbedin gungen erreicht. Jede dieser
Festle gungen muss in Form einer Verein -
barung dokumentiert werden und wird
damit zu einem Bestandteil der Anfor -
derungen.
Fazit
Anforderungen konkretisieren Ziele und
definieren die Basis, auf der eine Lösung
zum Kundennutzen entwickelt wird. Viel
zu häufig werden Anforderungen unzusammenhängend
gesammelt, statt sie aus
einer Wertvorstellung und Vision aus Kun -
densicht heraus zu entwickeln.
Das Problem dabei ist, dass Funktionen
schrittweise in ein zunehmend komplexes
Produkt hinein entwickelt werden, ohne
dass eine Sicht auf das endgültige Produkt
vorliegt. Zumeist werden die Anforderun -
gen nur oberflächlich beschrieben und
nicht im Kontext analysiert, weil dieser
nicht klar beschrieben und abgestimmt ist.
Die Konsequenz sind viele Anfor derungs -
änderungen und entsprechend Termin- und
Kostenüberschreitungen sowie eine immer
weniger beherrschte Komplexität des
Produkts, was spätestens mit Varianten
oder Versionen dann zu unnötigen Fehlern
und weiteren Zusatzaufwänden führt.
Ziele und Anforderungen sind nicht
absolut wahr. Verschiedene Interessen -
gruppen haben eine unterschiedliche
Wahrnehmung und natürlich divergierende
Ziele. Die Anforderungsermittlung schafft
eine Basis gegenseitigen Verstehens. In
einem Projekt ohne definierte und vereinbarte
Ziele sind die Eigenschaften und die
Qualität des resultierenden Produkts und
damit unser wirtschaftlicher Erfolg von
zufälliger Natur. Sie ergeben sich bestenfalls
noch teilweise aus offensichtlichen
Bedürfnissen der Problemstellung. Zur
Hauptsache hängen sie jedoch von der
Interpretation und den Vorlieben der beteiligten
Gruppen ab (z. B. Produktmanager,
Vertrieb, Entwickler, Systemanalysten), von
Gruppenstrukturen und von den Beziehun -
gen zwischen diesen Gruppen. Das Projekt
ist nicht marktorientiert und sein Erfolg ist
fragwürdig.
Die Anforderungsermittlung hat die folgenden
Ergebnisse:
■
■
■
Kontext und Vision des Projekts oder
des Produkts.
Bedürfnisse und Erwartungen an das
Projekt.
Spezifizierte Anforderungen.
■ Gemeinsame Basis für Marketing, Ent -
wicklung und Kunden.
Das Ende dieser initialen Ermittlung ist
erreicht, wenn alle notwendigen Abstim -
mungen für das Projekt unterzeichnet sind.
Alle wichtigen Interessengruppen müssen
darin übereinstimmen, das Ende erreicht zu
haben – sonst werden sie nie aufhören, Än -
derungen vorzuschlagen. Änderungen an
Projektinhalten sollten vertraglich geregelt
werden, insbesondere der Änderungsprozess
und die Entscheidung, welche Änderungen
aufgenommen werden. Häufig
führt die Furcht vor eigenen Unzuläng -
lichkeiten in der Ermittlungsphase zu
einem viel zu langen und unproduktiven
Kreis lauf von Spezifikationen, Nachbes -
serungen und Abstimmungsgesprächen.
Den Interessengruppen sollten dabei drei
Regeln ganz klar sein:
1. Anforderungen sind nicht stabil.
Anforderungen vor Projektstart einfrieren
zu wollen, ist der falsche Ansatz.
Wichtig ist es, ein sauberes Änderungsmanagement
zu vereinbaren, um später
mit Änderungen umgehen zu können.
2. Nur ein zügiger Projektabschluss kann
die Anforderungsfluktuationen begrenzen.
Vereinbaren Sie eine kurze
Projektdauer und die Änderungen und
Unsicherheiten gehen automatisch
zurück. Teilen Sie das Projekt in
Inkremente auf, um die Komplexität
und damit die Anforderungs än -
derungen zu kontrollieren.
3. Analyse schafft Paralyse. Das Projekt
muss gestartet werden, um den Markt -
eintritt nicht zu verpassen. Jeder Kunde
oder Markt will eine Lösung für die
artikulierten Bedürfnisse zum optimalen
Zeitpunkt und nicht ein übergewichtiges
Produkt viel zu spät. Nehmen
Sie Funktionen heraus, über die man
sich nicht einigen kann – sie sind offensichtlich
nicht so wichtig. Priorisieren
Sie nach Marktwert und Machbarkeit.
Ein komplexes Produkt, das zu viele
Bedürfnisse in einem Schritt erfüllen
will, findet nachher keinen großen
Markt.
Achten Sie daher auf einen schnellen – aber
nicht vorzeitigen – Abschluss der Ermitt -
lung. In aller Regel sind die Anforderungen
weder stabil noch komplett. Also müssen die
kritischen Anforderungen verstanden sein,
um damit ein Projekt inkrementell aufzusetzen.
Da sich die Anforderungen nach der
Ermittlungsaktivität noch ändern, sollte die
Ermittlung immer auch spätere Änderungen
antizipieren. David Parnas hatte das als
„Design for Change“ charakterisiert. Heute
sprechen wir von „Tech nical Debt“ (vgl.
[Ebe12]). Gemeint ist, dass wir unser Design
so machen müssen, dass Risiken, Altlasten
und offene Punkte für zukünftige Versionen
in ihren Konse quenzen und Kosten
beherrscht werden.
■
Literatur
[Coo99] A. Cooper, The Inmates are Running
the Asylum, Macmillan 1999
[Dav05] A.M. Davis, Just Enough
Requirements Management, Dorset House
2005
[Ebe07] C. Ebert, R. Dumke, Software
Measure ment, Springer-Verlag 2007
[Ebe12] C. Ebert, Systematisches Require -
ments Engineering (4. überarb. Auflage),
dpunkt.verlag 2012
[Sch10] E. Schick, Der Ich-Faktor, Han ser
Verlag 2010
70 71

mehr zum thema:
swadok.de
buchbesprechung für sie gelesen von ...
SOFTWAREARCHITEKTUR-
DOKUMENTATION WIRD MÖGLICH
Das Buch von Stefan Zörner gibt Antworten auf die Frage, warum eine Dokumentation der
Softwarearchitektur nötig ist. Dazu gibt es ganz praktische Hilfestellungen, wie eine gute
Architekturdokumentation möglich wird.
... Frank Pientka
(Frank.Pientka@gmx.de),
Senior Software Architect bei der MATERNA GmbH
und Gründungsmitglied des iSAQBs.
Nach einer kurzen Motivation des Themas
(Kapitel 1) werden im Hauptteil des Buches
die Grundlagen und Voraussetzungen
(Kapitel 2-6) für eine gute Softwarearchi -
tektur erläutert. Es schließen sich drei
Praxis kapitel (7-9) an, in denen der Autor
die Dokumentationswerkzeuge vorstellt
und einen Überblick über die Architektur
gibt. Bei der Auswahl des Dokumentations -
werkzeugs ist es wichtig zu klären, an wen
die Architekturdokumentation adressiert
ist und wer sie erstellen soll. Außerdem ist
es hier wichtig, die genannten Schwächen
und Stärken der jeweiligen Werkzeuge zu
kennen und sich dann bewusst für die am
besten geeignete Lösung zum Verwalten,
Erstellen und Kommunizieren der Archi -
tektur inhalte zu entscheiden.
In einem eigenen Kapitel (8) diskutiert
der Autor die Vor- und Nachteile, die
Archi tekturdokumentation begleitend oder
im Nachhinein durchzuführen. Da eine
Softwarearchitektur nicht nur auf dem
Papier, sondern irgendwann einmal auch
im Code stattfindet, zeigt Zörner dies am
Beispiel einer Schach-Engine „DokChess“,
deren Code auch auf der Web-Seite zum
Buch verfügbar ist. Ab schließend wird im
Buch auf die typischen Stolpersteine bei der
Architekturdokumen tation eingegangen,
insbesondere darauf, wie diese umgangen
oder entschärft werden können. Immer
wieder streut der Autor Beispiele ein und
fasst am Ende jedes Kapitels die
Kernaussagen zusammen.
Für eine pragmatische Architekturdoku -
men tation sollte eine Balance zwischen
einem „so viel wie nötig“ und einem „so
wenig wie möglich“ gefunden werden.
Zörner macht Lust, Architekturdoku -
mentation nicht nur als lästige und notwendige
Pflicht zu sehen, sondern sie als
effizientes Kommunikations- und Entschei -
dungs mittel zu nutzen.
Wichtige Architekturaspekte lassen sich
mit Bildern besser festhalten und kommunizieren.
Verschiedene Architektursichten
Stefan Zörner
„Softwarearchitekturen
dokumentieren und kommunizieren:
Entwürfe, Entscheidungen und
Lösungen nachvollziehbar und
wirkungsvoll festhalten“
Hanser Verlag, München, 2012
ISBN: 978-3-446-42924-6
277 Seiten, flexibler Einband
34,90 € (auch als E-Book erhältlich)
helfen, die Aspekte fokussierter darzustellen.
Der Autor empfiehlt hierfür eine
„Simplified UML”, um die wenigen UML-
Elemente korrekt und konsistent zu verwenden,
am besten unter Angabe der verwendeten
UML-Version.
Zörner verwendet originelle und eingängige
Schaubilder, wie die Architektur-
Brezel, das Vier-Quadranten-Modell (Was,
Wie, Wohin noch, Warum), eine Kreuz -
tabelle für Qualitätsziele mit Qualitäts -
szenarien oder den Produktkarton. Diese
helfen, komplexe Zusammenhänge prägnant
darzustellen. Die Beispiele im Buch
sind programmiersprachen- und technolo-
gieneutral, wobei ein Grundverständnis der
UML hilfreich ist.
Der Autor plädiert für eine feste Archi -
tektur-Dokumentationsstruktur, die so -
wohl denjenigen hilft, die die Dokumen -
tation erstellen, als auch denjenigen, die sie
lesen. Dabei empfiehlt er die weit verbreitete
arc42-Vorlage seines Vorwort-Schreibers
Gernot Starke, zumal Zörner hierzu eigene
Strukturergänzungen und die Werkzeug -
unterstützung für „MagicDraw“ und
„Confluence“ eingebracht hat.
Für die Architekturdokumentation müssen
die relevanten Themen identifiziert,
priorisiert und dann jeweils mit einem kurzen
Konzept und möglichen Lösungs -
optionen umrissen werden. Deswegen ist es
dem Autor für einen nachvollziehbaren und
bewertbaren Architekturentwurf wichtig,
dass die relevanten Einflussfaktoren – wie
Randb edin gungen, Risiken und Quali -
tätsziele – betrachtet werden und zentrale
Entscheidun gen festgehalten werden. Dabei
ist ihm der Lösungsweg mit den betrachteten
und verworfenen Alternativen mindestens
genauso wichtig wie die getroffene Entschei -
dung.
Zörner greift aktuelle Trends, z. B. die
agile Softwareentwicklung, auf und schlägt
gängige Werkzeuge, z. B. UML-Werkzeuge,
Wikis, Blogs, MindMaps und Bugtracking-
Tools, bei der Architektur dokumentation
vor.
Man merkt dem Buch an, dass sein Autor
seit mehreren Jahren den Spagat als
Softwareentwickler, Apache-Committer,
Architekt, Trainer oder Referent übt. Bei
der Fülle der präsentierten Ideen bietet es
sich an, Ausschnitte aus dem Buch bei passender
Gelegenheit immer wieder nachzulesen.
Die dazugehörige Webseite und die im
Preis des gedruckten Buches enthaltene
PDF-Fassung erhöhen den Nutzen, da
damit das Lesen und spätere Nachschlagen
erleichtert werden. Ich kann das Buch allen
Softwarearchitekten und Softwerkern
wärmstens empfehlen kann.
■
6/2012

fachartikel
m e h r z u m t h e m a :
de.wikipedia.org/wiki/JavaScript
de.wikipedia.org/wiki/Portal_%28Informatik%29
die autoren
ARCHITEKTUREN FÜR MODERNE
WEB-ANWENDUNGEN:
TEIL 2: JAVASCRIPT UND
JEE-PORTAL-SERVER
Web-Anwendungen lassen sich in Anwendungsklassen unterteilen, die sich jeweils unterschiedlich
gut mit den verschiedenen Technologie-Stacks realisieren lassen. In der letzten Ausgabe
von OBJEKTspektrum haben wir einige Anwendungsklassen vorgestellt und Realisierungen auf
der Basis von Content-Management-Systemen (CMS) und serverseitigen Web-Frameworks
beleuchtet. Anschließend haben wir gezeigt, welche Anwendungsklassen sich mit den zwei vorgestellten
Realisierungstypen am besten umsetzen lassen. Diesmal stellen wir zwei weitere
Realisierungstypen vor – Architekturen auf der Basis von JavaScript und JEE-Portal-Servern –
und zeigen so eine technologische Lösung für die restlichen Anwendungsklassen.
Andreas Hartmann
(hartmann@adesso.de)
ist Principal Software Architect bei der adesso AG,
Vortragender auf Konferenzen sowie Autor diverser
Fachartikel. Sein Tätigkeitsschwerpunkt liegt in
der Konzeption und Implementierung von leichtgewichtigen
Softwarearchitekturen und Frameworks
auf Basis der JEE-Plattform.
JavaScript-basierte
Web-Anwendungen
Die Rolle von JavaScript in modernen Web-
Anwendungen ist fundamental. Gelegent -
lich wird noch versucht, JavaScript direkt
mit der Anforderungsdefinition zu verbieten,
um Rücksicht auf diejenigen zu nehmen,
die JavaScript aus Policy-Gründen
nicht aktiviert haben, oder um „barrierefrei”
zu sein. Im Projektverlauf wird dann
aber trotzdem häufig JavaScript eingesetzt,
weil eine neue Anforderung hinzugekommen
ist, die sich nur mit JavaScript umsetzen
lässt. Dazu zählt beispielsweise eine
Sicherheitsabfrage vor dem Schließen eines
Fensters mit einem bereits ausgefüllten
Formular. Oder das eingesetzte Web-
Frame work abstrahiert so sehr von
JavaScript, dass es dem Entwickler gar
nicht auffällt, dass er JavaScript einsetzt.
Dieses ambivalente bis ablehnende Ver -
halten gegenüber JavaScript ist oft kontraproduktiv.
Ein bewusster Einsatz von
JavaScript bietet nämlich viele Möglich -
keiten (siehe Abbildung 1).
Mit Hilfe von JavaScript kann der
Browser mittlerweile als vollwertige An -
wen dungsplattform für Rich Internet
Tom Hombergs
(tom.hombergs@adesso.de)
ist Senior Software Engineer bei der adesso AG
und arbeitet dort als Architekt und Entwickler an
der Konzeption und Entwicklung von Anwendungen
auf Basis von Java-Technologien. Seine
Schwerpunkte sind Web-Anwendungen.
Eberhard Wolff
(eberhard.wolff@adesso.de)
arbeitet als Architektur- und Technologie-Manager
für die adesso AG in Berlin. Er wurde von Oracle in
die Gruppe der Java-Champions aufgenommen, ist
Autor einiger Fachbücher und spricht regelmäßiger
auf verschiedenen Konferenzen.
Abb. 1: Neue Möglichkeiten mit HTML5 und JavaScript.
Appli cations (RIAs) genutzt werden.
JavaScript kann natürlich wie bisher eingesetzt
werden, um die Benutzungsoberfläche
dynamischer und letztendlich für den
Benutzer angenehmer zur gestalten. Aber
der Einsatz der mit HTML5 eingeführten
JavaScript-APIs eröffnet völlig neue Mög -
lichkeiten, die nicht nur Einfluss auf die
Benutzungsoberfläche, sondern auch auf
die Implementierung der Geschäftslogik
und die serverseitige Architektur haben. Im
72 73

fachartikel
Der Begriff Unobtrusive JavaScript und das übergreifende Konzept des Pro gressive
Enhancement stammen aus der Zeit der Anfänge von AJAX, in der JavaScript eine größere
Rolle zukam als zuvor. Das Konzept des Progressive En han cement sieht vor, bei der
Entwicklung von Web-Anwendungen zunächst eine Grundfunktionalität zur Verfügung
zu stellen, die mit allen Browsern und von allen Benutzern genutzt werden kann. Auf
Basis dieser Grundfunktionalität kann dann weitere Funktionalität hinzugefügt werden,
die nur verfügbar ist, wenn der Benutzer und dessen Browser die notwendigen
Voraussetzungen dafür mitbringen. Unobtrusive JavaScript greift dieses Konzept auf
und überträgt es auf die Verwendung von JavaScript. Java Script soll demnach nur für
Zusatzfunk tionalität eingebaut werden, auf die man auch verzichten kann, denn nicht
jeder Benutzer hat JavaScript in seinem Browser aktiviert. Laut einer Untersu chung von
Yahoo aus dem Jahre 2010 haben aber nur etwa ein bis zwei Prozent der Internet-Nutzer
JavaScript in ihrem Browser deaktiviert (vgl. [Zak10]). In Anbetracht dieser Verbreitung
von JavaScript und der Einführung zahlreicher neuer JavaScript-APIs mit HTML5 sollte
das Konzept des Unobtrusive Javascript von Anwendung zu Anwen dung überdacht
werden. Sind für die An wen dung beispielsweise HTML5-Java Script-Features notwendig,
kann man auf JavaScript nicht verzichten. Sind die Nutzer der Anwendung dagegen
hauptsächlich Mitarbeiter in Unternehmen mit restriktiven Sicherheits-Policies, sollte
man dem Konzept des Unobtrusive JavaScript folgen. Zumindest bei öffentlich zugänglichen
Anwendungen im In ter net ist zu beobachten, dass JavaScript mehr und mehr eine
zwingende Voraus setzung zur Nutzung ist. Als Beispiel lassen sich die Anwendungen
von Google, wie z. B. „Google Docs“ und „GMail“, nennen, die ohne JavaScript nicht
lauffähig sind.
Kasten 1: Unobtrusive JavaScript.
Folgenden erläutern wir verschiedene
Szenarien zum Einsatz von JavaScript
sowie deren Auswirkungen auf die Archi -
tektur einer Web-Anwendung.
Bereicherung der GUI mit JavaScript
Der Einsatz von JavaScript zur Berei cherung
der Benutzungsoberfläche ist nichts Neues.
Dabei liefert ein Web-Server üblicherweise
ein HTML-Dokument mit viel serverseitig
generiertem Markup und wenig JavaScript
aus. Der JavaScript-Code ergänzt das
Markup, um es dynamischer zu gestalten,
z. B. um Formulareingaben clients eitig zu
validieren oder um Tabellen mit einer
Filteroption zu versehen. Dafür steht eine
Vielzahl von JavaScript-Frame works mit
diversen Plug-Ins zur Verfügung, die so gut
wie jeden Anwendungsfall abdecken. Das
wohl am weitesten verbreitete Framework
dieser Art ist „JQuery“ (vgl. [Jqu]).
Der Ansatz, JavaScript als Ergänzung
einzusetzen, folgt dem verbreiteten Grund -
satz des Unobtrusive JavaScript, nach dem
eine Anwendung auch ohne JavaScript
funktionieren soll und durch JavaScript nur
optionale Zusatz-Features umgesetzt werden
(siehe Kasten 1). Dieser Ansatz eignet
sich somit gut für Web-Anwendungen, die
hohe Anforderungen an eine ansprechende
Benutzungsoberfläche stellen, bei denen
aber Kompromisse in Bezug auf die
Usability bei deaktiviertem JavaScript
akzeptabel sind.
Dieser Ansatz lässt sich leicht mit einem
der bewährten, im letzten Artikel vorgestellten
serverseitigen Web-Frameworks verbinden
(vgl. [Har12]). Sowohl das HTML-
Markup als auch das JavaScript werden
durch eines der konventionellen Web-Frame -
works erzeugt. Allerdings verstecken viele
dieser Frame works den Einsatz von
JavaScript, sodass der Entwickler in einigen
Fällen gar nicht mehr weiß, ob die von ihm
entwickelte Benut zungsoberfläche JavaScript
einsetzt oder nicht. Hier sind Model/View/
Co ntroller-Frameworks den komponentenbasierten
Frameworks gegenüber im Vorteil,
da sie keine so umfassende Abstraktion über
HTTP, HTML oder JavaScript haben.
Unterstützen die Web-Frameworks Java -
Script, kann der Funktionsumfang mit einer
guten JavaScript-Bibliothek wie JQuery meistens
nicht mithalten. So ist es häufig trotzdem
notwendig, JavaScript an einigen Stellen
per Hand zu schreiben. Dadurch entsteht
eine Diskrepanz in der Entwicklung: An einigen
Stellen wird JavaScript automatisch
erzeugt, an anderen Stellen per Hand. Das
kann zu Konflikten führen.
Erzeugung der GUI mit JavaScript
JavaScript kann durch die Performance
moderner JavaScript-Implementierungen
und die Vielzahl mächtiger Bibliotheken
mittlerweile viel mehr, als nur einfache
GUI-Logik implementieren. Die Entwick -
lung der gesamten Benutzungs ober fläche
kann in JavaScript erfolgen. In diesem
Szenario wird von einem Web-Server ein so
gut wie leeres HTML-Dokument mit einer
JavaScript-Datei ausgeliefert. Die Java -
Script-Datei enthält Code, der das komplette
HTML-Markup für die Benut -
zungsoberfläche erzeugt. Die Logik zur
Erzeugung des HTML-Markups wird also
vom Server vollständig in den Client verlagert.
Wo man sonst vielleicht ein kompo -
nentenbasiertes Web-Framework auf der
Server-Seite genutzt hat, greift man nun auf
ein JavaScript-Templating-Framework, wie
z. B. „HandlebarsJS“, zurück, um dem
Code Struktur zu geben (vgl. [Han]). Mit
solchen Templating-Frameworks lassen
sich Oberflächen-Elemente an zentraler
Stelle definieren und an verschiedenen
Stellen der Benutzungsoberfläche mit
unterschiedlichen Inhalten anzeigen. Ak -
tuell entsteht in dem Bereich der
JavaScript-Templating-Bibliotheken eine
Vielzahl von Technologien.
Der Server liefert also nur HTML-Gerüs -
te und JavaScript aus. Serverseitige Web-
Frameworks haben in diesem Szenario
kaum noch eine Bedeutung – allenfalls zur
Erzeugung des HTML-Rahmens können
sie eingesetzt werden. Einen fast leeren
HTML-Rahmen kann man aber auch mit
viel weniger Overhead erzeugen. Da die
Erzeugung des HTML-Markups vollständig
im Client abläuft, hat der Server aber
auch nicht mehr so viel zu tun und kann
potenziell mehr parallele Anfragen beantworten,
als dies beim Einsatz eines serverseitigen
Web-Frameworks der Fall wäre.
Das ausgelieferte JavaScript ist vollständig
von Hand programmiert, es gibt keine
Mischung mehr mit automatisch erzeugtem
JavaScript-Code.
Serverseitige Anwendungslogik kann
dem JavaScript-Client beispielsweise über
eine REST-Schnittstelle zur Verfügung ge -
stellt werden. Hierfür kommen REST-
Frameworks wie „Jersey“, „Restlet“ zum
Einsatz (vgl. [Jer], [Res]). Zum Aufruf der
REST-Schnittstelle aus dem JavaScript-
Code heraus wird die bewährte
XmlHttpRequest-API genutzt. Es handelt
sich also um gewöhnliche AJAX-Anfragen.
Da der Zustand der Benutzungsoberfläche
6 / 2 012

fachartikel
im Client gespeichert wird, ist die serverseitige
Verarbeitungslogik zustandslos. Damit
sinkt der Speicher-Footprint auf dem Server
und die nicht immer ganz einfach umzusetzende
Replikation von Sessions in einem
Server-Cluster ist kein Thema mehr.
Im Hinblick auf Barrierefreiheit ist bei
einer JavaScript-lastigen Architektur übrigens
nicht viel mehr Sorgfalt erforderlich
als bei Architekturen ohne JavaScript.
Gegen den Grundsatz des Unobtrusive
JavaScript wird hier zwar explizit verstoßen.
Allerdings unterstützen moderne
Hilfs programme für Benutzer mit Behin -
derungen mittlerweile den ARIA-Standard
des W3C, durch den Oberflächenelemente
im Markup mit bestimmten Rollen annotiert
werden können. Diese Rollen werden
von Hilfsprogrammen, wie z. B. Screen-
Readern, dann ausgewertet – egal ob das
Markup mit JavaScript erzeugt wurde oder
nicht.
Echtzeitkommunikation mit WebSocket
Anwendungen, die eine Echtzeit-Kom -
muni kation zwischen Client und Server in
beiden Richtungen erfordern, konnte man
bisher eher schlecht als Web-Anwendungen
implementieren. Zu dieser Gattung von
Anwendung gehören zum Beispiel
Monitoring-Dashboards, die in kurzen
Abständen regelmäßig Daten von einem
Server entgegennehmen und diese anzeigen.
Da das HTTP-Protokoll eine Kommuni -
kation vom Server zum Client nur nach
einer Client-Anfrage vorsieht, müsste hier
intensiv vom Comet-Programmiermodell
Gebrauch gemacht werden. Dabei sendet
der Client zunächst eine AJAX-Anfrage an
den Server. Dieser hält die Anfrage solange
offen, bis neue Daten zum Versenden verfügbar
sind, und sendet diese Daten dann
als Antwort auf die Anfrage zurück. Nach
dem Empfang der Daten schickt der Client
direkt die nächste Anfrage dieser Art an
den Server. Dadurch kann der Server jederzeit
aktuelle Daten an den Client schicken,
da ständig eine entsprechende Anfrage vorliegt.
Die Kommunikation geht aber immer
noch vom Client aus. Ein echter Server-
Push-Mechanismus ließ sich bisher in Web-
Anwendungen nicht realisieren, weshalb
Echtzeit-Anwendungen oft mit einem eigenen
Client-Programm umgesetzt wurden.
Die WebSocket-API schließt genau diese
Lücke. Per WebSocket ist es möglich, eine
Socket-Verbindung aus dem Browser heraus
zu einem oder mehreren Servern aufzubauen.
Ist eine solche Verbindung einmal
aufgebaut, kann sie sowohl vom Client als
auch vom Server zum Versenden von
Nachrichten genutzt werden. Der Server ist
nun in der Lage, echte Push-Nachrichten
an den Client zu senden. Natürlich möchte
man diese Verbindungen weder client- noch
serverseitig manuell im Code verwalten.
Deshalb greift man auf Frameworks wie
„SocketIO“ zurück (vgl. [Soc]). Im clientseitigen
JavaScript-Code dient SocketIO als
Abstraktion der WebSocket-API. Server -
seitig kann es im Zusammenspiel mit dem
JavaScript-Framework „NodeJS“ als
WebSocket-Server eingesetzt werden (vgl.
[Joy]). Ist man serverseitig auf Java angewiesen,
kann beispielsweise ein Jetty-Web-
Server als WebSocket-Server fungieren, da
er eine entsprechende WebSocket-Biblio -
thek direkt mitbringt (vgl. [Jet]). Eine gute
Abstraktion über verschiedene Kommuni -
kations mechanismen – unter anderem auch
WebSockets – ist das „Atmosphere“-
Frame work (vgl. [Atm]).
Offline-Anwendungen
Ein weiteres Szenario, das bisher nicht mit
einer Web-Architektur abzubilden war,
sind offline-fähige Web-Anwendungen.
Einmal vom Server heruntergeladen, sind
sie auch ohne Internet-Verbindung lauffähig.
Der Benutzer kann mit der Anwen -
dung arbeiten und entstandene Daten bei
der nächsten Online-Sitzung mit dem
Server synchronisieren. Bisher musste für
ein solches Szenario stets ein proprietäres
Client-Programm oder Plug-In installiert
werden.
Mit dem in HTML5 eingeführten
Application Cache können offline-fähige
Anwendungen nun auch mit dem Browser
als Client realisiert werden. Der Entwickler
definiert, welche Dateien der Browser beim
ersten Zugriff in einem Cache halten soll.
Gibt man die Adresse der Web-Anwendung
ohne eine Verbindung zum Internet in den
Browser ein, lädt dieser die definierten
Dateien aus dem Cache, sodass die
Anwendung weiterhin funktioniert. Daten,
die bei der Nutzung der Web-Anwendung
im Offline-Modus anfallen, können z. B. in
der ebenfalls mit HTML5 eingeführten
IndexedDB gespeichert werden. Dabei
handelt es sich um eine NoSQL-
Datenbank, die vom Browser zur Ver fü -
gung gestellt wird und die Java Script-Ob -
jekte im JSON-Format (JavaScript Object
Notation) persistiert.
Zur Vereinfachung der clientseitigen Da -
ten speicherung kann z. B. das „AmplifyJS”-
Framework eingesetzt werden, das eine
Abstraktionsschicht zum Datenspeicher zur
Verfügung stellt (vgl. [Amp]). So muss der
restliche JavaScript-Code nicht zwischen
Online- und Offline-Datenspeicherung
unter scheiden. Zur Synchronisation der
offline angefallenen Daten mit einer serverseitigen
Datenbank hat man mehrere Mög -
lichkeiten. Greift man serverseitig auf eine
Datenbank mit REST-Schnittstelle zurück,
wie z. B. „CouchDB“, kann man aus dem
JavaScript-Code der Web-Anwendung heraus
diese REST-Schnittstelle bedienen (vgl.
[Apa]). Alternativ kann die Synchroni -
sierung auch per WebSocket vorgenommen
werden, wofür dann allerdings ein
WebSocket-Server als Vermittler zwischen
Client und Datenbank notwendig wird.
Ein großer Vorteil dieses Offline-Szena -
rios ist, dass der Rollout einer Anwendung
völlig trivial wird. Zur „Installation” der
Client-Anwendung greift der Benutzer einfach
einmal online auf die Anwendung zu.
Der Browser kümmert sich dann darum,
die benötigten Daten in den Cache zu
laden. Vorsicht ist bei einer offline-fähigen
Anwendung geboten, wenn im Offline-
Modus sicherheitskritische Daten verarbeitet
oder erzeugt werden. Da die komplette
Anwendungslogik in JavaScript abgebildet
werden muss, stehen hier Tür und Tor für
clientseitige Manipulation offen.
JEE-Portal-Server
Für Unternehmen stellen Portale eine einheitliche
Plattform für Mitarbeiter, Partner,
Kunden und/oder Lieferanten dar, die einen
personalisierten Zugriff auf Informationen
und Prozesse ermöglicht. Die wirtschaftlichen
Beweggründe sind dabei die effizientere
Nutzung der bestehenden IT-Infra struk -
tur, die Personalisierung von Infor ma tionen,
die Verwaltung von Wissen, die Vermei dung
von Medienbrüchen und die Optimierung
der Arbeitsabläufe durch eine bereichs- und
unternehmensübergreifende Anwendungs -
integration.
Portale, respektive JEE-Portal-Server,
adres sieren die Themen Aggregation, Per -
so nalisierung, Präsentation und Sicherheit.
Portale übernehmen dabei die Rolle einer
Integrationsplattform zur Aggregation von
Inhalten und Anwendungen. Typische
Merkmale von Portal-Servern sind:
■ Benutzer können persönliche Bereiche
individuell konfigurieren.
■ Portal-Server ermöglichen die Um -
setzung eines einheitlichen Look&Feels
74 75

fachartikel
Abb. 2: Portal-Pages.
■
■
und die Aufbereitung der Inhalte für
unterschiedliche Ausgabekanäle. Dabei
werden Anforderungen z. B. aus dem
mobilen und barrierefreien Kontext
umgesetzt.
Portal-Server stellen den notwendigen
technischen Rahmen für eine einheitliche
Sicherheitsarchitektur zur Verfü -
gung. Die technischen Rahmenbedin -
gun gen für das Single Sign-on bei den
einzelnen Anwendungen hängen allerdings
vom konkret eingesetzten Portal-
Server ab. Ergänzend hierzu erfolgt die
Vergabe von Berechtigungen auf verschiedene
Portal-Bestandteile orthogonal
zu dem Berechtigungs konzept der
integrierten Anwendun gen. So wird
festgelegt, welche Benut zer/Gruppen
welche Portal-Bestandteile sehen oder
editieren dürfen. Nach einer
Anmeldung am Portal erhält der Be -
nutzer dann gemäß seiner Portal-
Berechtigung Zugriff auf die einzelnen
Portal-Bestandteile.
Darüber hinaus bieten die verschiedenen
Portal-Server eine Fülle von bereits fertigen
Portlets an, die im Rahmen der eigenen
Anwendung verwendet und bei
Bedarf angepasst werden können. So hat
zum Beispiel das Liferay Portal einen
sehr umfangreichen Satz von Portlets zu
verschiedenen Bereichen, wie z. B.
Community, Content-Ma nage ment so -
wie Collaboration (vgl. [Lif]).
Ein Portal im Sinne von „Java EE“ setzt
sich aus einer oder mehreren Portal Pages
zusammen (siehe Abbildung 2). Auf einer
Portal Page befinden sich mehrere Portlets,
die jeweils die Logik und Darstellung für
einen Teil der Seite verwalten, sowie
Portlet-Applications. Eine Portlet-Applica -
tion besteht dabei aus mehreren Portlets,
die in sich geschlossen eine fachlich/technisch
sinnvolle Einheit bilden. Dem Benut -
zer ist es prinzipiell möglich, Portlets ge -
mäß seiner eigenen Vorstellung anzuordnen
und nach Belieben weitere Portlets auf seine
Portal-Seite zu legen, sofern er hierzu die
notwendigen Berechtigungen hat.
Ein Portlet selbst besteht aus einem
Portlet Title, den Portlet Modes View, Edit
und Help, den Portlet States Normal,
Maximized und Minimized, dem eigentlichen
Content sowie dem Portlet Window,
das alles umschließt (siehe Abbildung 3).
Welche Portlet Modes angezeigt werden,
hängt von der konkreten Berechtigung
eines Benutzers ab. Gängig ist, dass ein
Benutzer lediglich die Berechtigung für den
Portlet Mode View hat, während ein
Administrator die Berechtigung für den
Portlet Mode Edit erhält, um so das Portlet
anzupassen. Der Portlet Mode Help wird
in Regel nicht verwendet, da eine Extra-
Hilfeseite heutzutage nicht mehr den Be -
nut zeranforderungen hinsichtlich der Hilfe -
funktionalität entspricht. Hier wird vielmehr
eine kontextsensitive Hilfe bei den
Portlet Modes View und Edit erwartet.
Bei den Portlet States ist Normal der gängige.
Dabei werden mehrere Portlets
gemeinsam auf der Seite angezeigt. Die
Portlet States Maximized und Minimized
stehen dem Benutzer in den meisten
Portalen nicht direkt zur Verfügung, sondern
werden – abhängig vom fachlichen
Kontext – programmatisch benutzt.
Die Implementierung von Portlets ge -
schieht auf Basis des Standards „JSR
impressum
Verlag: SIGS DATACOM GmbH
Lindlaustr. 2c, D-53842 Troisdorf
Tel.: +49 (0) 2241/2341-100, Fax: +49 (0) 2241/2341-199
www.sigs-datacom.de · E-Mail: info@sigs-datacom.de
Chefredakteur: Thorsten Janning
Lindlaustr. 2c, D-53842 Troisdorf
Tel.: +49 (0) 2241/2341-100, Fax: +49 (0) 2241/2341-199
E-Mail: fachartikel@objektspektrum.de
Mitglieder der Redaktion:
Matthias Bohlen, Consultant
Wolfgang Keller, object architects
Dr. Johannes Mainusch, Otto GmbH & Co. KG
Prof. Dr. Andreas Rausch, Technische Universität Clausthal
Martin Schimak, Martin Schimak GmbH
Rainer Singvogel, msg systems ag
Torsten Weber, GROSSWEBER, Groß, Weber & Partner
Honorary Editorial Member: Dr. Frances Paulisch
Aus der Szene: Ulrich Schmitz und Kirsten Waldheim,
E-Mail: Ulrich.Schmitz@sigs-datacom.de
Schlussredakteurin: Kirsten Waldheim,
E-Mail: schlussredaktion@objektspektrum.de
Freie Mitarbeiterin: Elke Niedermair, E-Mail: e.a.n@gmx.de
Manuskripteinsendungen: Manuskripte werden von der Redaktion –
ausschließlich in elektronischer Form – gerne angenommen. Mit der
Einsendung von Manuskripten gibt der Verfasser die Zustimmung zum
Abdruck, zur Vervielfältigung auf Datenträgern und zur Übersetzung.
Weitere Informationen und Honorarfestlegungen finden Sie in unseren
Autorenrichtlinien: www.sigs-datacom.de/fachzeitschriften/
objektspektrum/hinweise-fuer-autoren/richtlinien.html.
Verlagsleitung: Günter Fuhrmeister
Redaktions- und Herstellungsleitung Zeitschriften:
Susanne Herl, Tel.: +49 (0) 2241/2341-550,
E-Mail: Susanne.Herl@sigs-datacom.de
Leserservice: objektspektrum@sigs-datacom.de
Vertriebs- und Marketingleitung: Beate Friedrichs
Tel.: +49(0)2241 / 2341 - 560, Email: Beate.Friedrichs@sigs-datacom.de
Anzeigen: Brigitta und Karl Reinhart
Ostring 5h, D-85630 Grasbrunn,
Tel.: +49 (0) 89/464729, Fax: +49 (0) 89/463815,
E-Mail: Karl.Reinhart@sigs-datacom.de
Druck: F&W Mediencenter GmbH
Holzhauser Feld 2 · D-83361 Kienberg · Tel.: +49 (0) 8628/9884-52
E-Mail: anzeigendaten@objektspektrum.de
Abonnenten-Service: IPS Datenservice GmbH, Postfach 13 31,
D-53335 Meckenheim, Tel.: +49 (0) 22 25/70 85-374
Fax: +49 (0) 22 25/70 85-376, Patrick König, Markus Preis
E-Mail: aboservice@sigs-datacom.de
Erscheinungsweise: zweimonatlich
Bezugspreise:
Einzelverkaufspreis: € 8,90 (D), € 9,90 (A), sfr 16,50 (CH)
Jahresabonnement Deutschland: € 50,90 inkl. Versandkosten
Jahresabonnement Europa: € 58,20 inkl. Versandkosten
Jahresabonnement außerhalb Europas: € 63,60 inkl. Versandkosten
Studentenabo: € 44,84 inkl. Versandkosten
Bankverbindung:
Postbank München, Konto-Nr. 560 737 801, BLZ 700 100 80
Lieferung an Handel:
Verlagsunion KG, Postfach 5707,
D-65047 Wiesbaden, Tel.: +49 (0) 61 23/620-0
Layout und Produktion: leuchtfeuer-agentur · Sven Lesemann
Büro in Köln: Schanzenstraße 31 · D-51063 Köln,
www.leuchtfeuer-agentur.de · E-Mail: Lesemann@leuchtfeuer-agentur.de
Urheberrecht: Für Programme, die als Beispiele veröffentlicht werden, kann
der Herausgeber weder Gewähr noch irgendwelche Haftung über nehmen. Aus
der Veröffentlichung kann nicht geschlossen wer den, dass die beschriebenen
Lösungen oder verwendeten Bezeich nungen frei von gewerblichen
Schutzrechten sind. Die Erwähnung oder Be ur teilung von Produkten stellt keine
irgendwie geartete Empfehlung dar. Für die mit Namen oder Signatur
gekennzeichneten Beiträge über nehmen der Verlag und die Redaktion lediglich
die presse rechtliche Verantwortung.
© 2012 SIGS DATACOM GmbH
ISSN 0945-0491
Die Zeitschrift wird mit chlorfreiem Papier hergestellt
6/2012

fachartikel
Abb. 3: Portlet.
168“ bzw. des aktuellen „JSR-286-
Portlet“-Standards, wobei JSR 168 rudimentär
ist. In diesem Standard wird z. B.
nicht geregelt, wie Nachrichten zwischen
einzelnen Portlets ausgetauscht werden
können. Hierfür hatten die diversen Portal-
Server-Hersteller jeweils bisher eigene proprietäre
Lösungen. Im JSR 286 wurden
unter anderem die Inter Portlet
Communication (IPC) und das Resource
Serving mit aufgenommen.
Bei den Portlets unterscheidet man unter
anderem zwischen der Action und der
Render Phase. In der Action Phase wird
eine Aktion innerhalb eines Portlets ausgelöst,
während in der Render Phase der
Portlet Content lediglich dargestellt wird.
Abb. 4: Sequenzdiagramm JSR 268.
Das Zusammenspiel zwischen den einzelnen
Portlets regelt dabei der Portlet Con -
tainer. Dieser sorgt unter anderem für die
korrekte Bearbeitungsabfolge bei einer Be -
nut zerinteraktion. Abbildung 4 zeigt ein
Sequenzdiagramm. Hier wird zunächst die
Benutzerinteraktion in Portlet A bearbeitet
und anschließend der Content aller Portlets
erzeugt. Für weitere Details sei auf den JSR
286 verwiesen (vgl. [Ora]).
Die Implementierung von Portlets nach
JSR 286 erinnert stark an die Pro -
grammierung von Servlets und ist dementsprechend
so nicht praktikabel im Rahmen
der Anwendungsentwicklung einsetzbar.
Um die verschiedenen Web-Frameworks im
Rahmen der Portlet-Entwicklung dennoch
einsetzen zu können, wird jeweils eine
Web-Framework-spezifische Portlet Bridge
benötigt. So gibt es zur Nutzung von „Java
Server Faces“ bei der Portlet-Entwicklung
den JSR 329, der die JSF Portlet Bridge
adressiert.
Das Einbinden bestehender Web-Appli -
kationen in ein Portal ist ein komplexer
Vorgang. Zwar kann man auf verschiedene
Web-Clipping-Lösungen diverser Portal-
Server-Hersteller zurückgreifen, jedoch treten
hier schon recht schnell erste technische
Probleme auf, wenn eine zu integrierende
Anwendung JavaScript enthält oder sich
ändert. Alternativ trifft man nicht selten
iFrame-basierte Lösungen an. Dabei entstehen
Nachteile, z. B. dass eingebundene
Anwendungen nicht am Portlet-Lebens -
zyklus teilnehmen und meist eine fest vorgegebene
Größe besitzen. Gemeinsam
haben beide Lösungsansätze, dass hier
jeweils versucht wird, eine bestehende
Anwendung in ein Portlet zu überführen,
ohne dass hierbei Aspekte wie Navig -
ationsstruktur und Benutzungskonzept an
das Portal angepasst werden.
Einen anderen Lösungsansatz verfolgt
der Standard Web Services for Remote
Portlets (WSRP), wenn es um die Einbin -
dung bestehender Anwendungen geht.
Hierbei werden Portlets/Web-Anwendun -
gen eines anderen Portal-Servers/Applika -
tions-Servers mittels des WSRP-Standards
in das eigene Portal eingebunden (siehe
Abbildung 5).
Browser-seitige Integration
Portal-Server ermöglichen also die Inte -
gration verschiedene Portlets zu einem großen
Ganzen. Aber die Integration verschiedener
Web-Anwendungen kann auch im
Browser erfolgen. Dabei kann zwischen
Oberflächen- und Geschäftslogik-Inte -
gration unterschieden werden. Diese beiden
Va rianten gelten vom Ansatz her prinzipiell
erst einmal für alle vorgestellten
Reali sierungstypen, wobei sich dies natürlich
abhängig von der konkreten
Technologie in der Ausführung entsprechend
unterscheidet.
Die Oberflächenintegration kann mittels
Screen-Scraping, iFrames oder beispielsweise
als Popup erfolgen. Bei der Anbin -
dung mittels Screen-Scraping werden aus
einer anderen Web-Applikation Bereiche
herausgeschnitten und innerhalb der eigenen
Web-Applikation zur Anzeige ge -
bracht. Eine solche Anbindung ist meistens
komplex und schwer zu implementieren.
76 77

fachartikel
Abb. 5: WSRP-Szenario.
Darüber hinaus ziehen Änderungen an der
eingebunden Web-Applikation meist Änderungen
an der einbindenden Web-Applika -
tion nach sich. Dieses Vorgehen hat allerdings
den Vorteil, dass man prinzipiell die
volle Kontrolle über den Seiteninhalt hat.
Bei der Integration mittels eines iFrames
wird in der Regel in einen Teil der Web-
Seite die vollständige Web-Applikation
inte griert. Das führt zu einem Bruch im
Look&Feel zwischen der eingebunden
Web-Applikation und der eigentlichen
Web-Applikation. Des Weiteren können
zwischen den beiden Web-Applikationen
Nachrichten und Daten nicht ohne weiteres
ausgetauscht werden, da es sich hierbei um
eine Cross Domain Communication handelt,
die aus Sicherheitsgründen nicht er -
laubt ist, da Cross-Site-Scripting-Angriffe
möglich sind. Eine Solche Kommunikation
wurde jedoch mit HTML5 deutlich vereinfacht.
Darüber hinaus durchläuft jede Web-
Applikation ihren eigenen Lebenszyklus
und hat erst mal ihren eigenen Sicherheits -
ontext, sodass man auch diese Bereiche
integrieren muss.
Die Integration mittels Popup ist seit der
durchgängigen Verfügbarkeit von Browser-
Tabs eine optisch ansprechende Lösung,
um eine Integration mehrerer Web-Appli -
kationen zu erreichen. Die integrierte An -
wen dung öffnet sich dann in einem neuen
Tab. Prinzipiell ergeben sich aber dieselben
technischen Probleme wie bei der iFramebasierten
Lösungen.
Bei der Integration auf Geschäftslogik-
Ebene werden Services direkt aus dem
Browser heraus aufgerufen und die entsprechenden
Daten zur Anzeige gebracht.
Für die Darstellung der Daten ist dabei die
aufrufende Web-Applikation verantwortlich.
Das setzt allerdings voraus, dass
bereits entsprechende Services existieren
und diese mit einer passenden Schnittstel -
len technologie ausgestattet sind, die sich
aus einem Browser ansprechen lässt, wie z.
B. REST Services.
Literatur & Links
Fazit
Bei dem Versuch, den Anwendungsklassen
einen eindeutigen Realisierungstyp zuzuordnen,
lässt sich ziemlich schnell feststellen,
dass es keine allgemeingültige Lösung
gibt. Das Problem ist vielschichtig und
kann nicht auf die zwei Parameter „fachlicher
Einsatz“ und „Technologie-Stack“
heruntergebrochen werden. Unter anderem
spielen das technologische Know-how des
Teams und Vorgaben hinsichtlich der
Betriebsplattform eine entscheidende Rolle.
Für eine erste Auswahl kann man allerdings
den möglichen Lösungsraum entsprechend
eingrenzen: Bei Business-to-Business-
Lösungen, die mehrere Anwendungen in
einer GUI integrieren, kann es sinnvoll sein,
einen Portal-Server oder browserseitige
Integration einzusetzen. Gerade in diesem
Bereich werden Portal-Server-Features, wie
vom Benutzer individuell zusammengestellte
Portal-Seiten, aber praktisch nie ausgenutzt,
weshalb der Einsatz eines Portal-
Servers gut überlegt sein sollte.
Sachbearbeiter-Anwendungen zur Unter -
stützung der Kernprozesse der Unter -
nehmen und Anwendungen für Businessto-Consumer-Lösungen
lassen sich
beispielsweise gut mit einem der im letzten
Artikel vorgestellten serverseitigen Web-
Frameworks umsetzen. Aufgrund der
hohen Komplexität der GUI wird der
Einsatz von JavaScript aber fast immer
erforderlich sein. Auch die Erzeugung der
kompletten GUI mit JavaScript ist eine
mögliche Alternative, gerade wenn
Echtzeit-Kommunikation und Offline-
Fähigkeit ins Spiel kommen.
■
[Amp] AmplifyJS Framework, Homepage, siehe: amplifyjs.com/
[Apa] The Apache Software Foundation, CouchDB-Datenbank, siehe: couchdb.apache.org/
[Atm] Atmosphere Framework, Homepage, siehe: atmosphere.java.net/
[Han] HandlebarsJS Framework, Homepage, siehe: handlebarsjs.com/
[Har12] A. Hartmann, T. Hombergs, E. Wollf, Architekturen für moderne Web-Anwendungen:
Teil 1: CMS und serverseitige Web-Frameworks, in: OBJEKTspektrum 5/2012
[Jer] Jersey REST-Framework, Homepage, siehe: jersey.java.net/
[Jet] Jetty-Webserver-Projekt, Homepage, siehe: jetty.codehaus.org/jetty/
[Joy] Joyent, Inc., NodeJS Framework, siehe: nodejs.org/
[Jqu] JQuery Framework, Homepage, siehe: jquery.com/
[Lif] Liferay Portalservers, Homepage, siehe: liferay.com/
[Ora] Oracle, JSR 286: Portlet Specification, siehe: jcp.org/en/jsr/detail?id=286
[Res] Restlet Framework, Homepage, siehe: restlet.org/
[Soc] SocketIO Frameworks, Homepage, siehe: socket.io/
[Zak10] N.C. Zakas, How many users have JavaScript disabled?, 2010, siehe:
developer.yahoo.com/blogs/ydn/posts/2010/10/how-many-users-have-javascript-disabled/
6/2012

fachartikel
m e h r z u m t h e m a :
vierfores.de
nutzfahrzeuge.fraunhofer.de
die autoren
SICHERHEIT IN DER
FAHRZEUGTECHNIK:
SOFTWARE IN EINGEBETTETEN
SYSTEMEN
Die Fahrzeugtechnik ist einer der wichtigsten Treiber für Innovationen bei der Entwicklung komplexer
Systeme. Stetig erhöht sich hier der Anteil softwaregesteuerter Komponenten und auch
der Einsatz autonomer Fahrzeuge ist heute vorstellbar. Trotz der wachsenden Komplexität
muss Qualität sichergestellt werden. Das erfordert leistungsfähige Modellierungs- und
Analysetechniken sowie geeignete Entwicklungsprozesse und Verfahren, die das Verstehen der
komplizierten Sachverhalte erleichtern. Der Artikel beleuchtet aus Sicht der Qualitätssicherung
Probleme und Einflussfaktoren, die in der Entwicklung von eingebetteten Systemen zumeist
nicht hinreichend berücksichtigt werden. Unzulänglichkeiten existierender Verfahren und
Techniken sowie mögliche Ansätze zur Verbesserung werden diskutiert und potenzielle
Anwendungen im Kontext der Entwicklung von autonomen Systemen beschrieben.
Dr. Patric Keller
(pkeller@cs.uni-kl.de)
ist wissenschaftlicher Mitarbeiter am Lehrstuhl
Software Dependability im Fachbereich Informatik
der TU Kaiserslautern. Er forscht zu den Themen
Sicherheit, Zuverlässigkeit und Verfügbarkeit von
Systemen.
Verfahren und Modelle in der
Qualitätssicherung
Pkw-Produzenten haben früher bei ihren
Fahrzeugen vornehmlich Leistungsdaten in
den Vordergrund gestellt. Aktuell prägen
Schlagwörter wie Sicherheit und Komfort
die Entwicklungen der Automobilindustrie
maßgeblich mit. Fahrerassistenz-Systeme,
wie z. B. Spurhalte-, Notbrems- oder Ein -
park-Systeme, vermitteln mehr Sicherheit
durch eine Entlastung und Unterstützung
Die in diesem Artikel beschriebenen
Arbei ten finden im Pilotprojekt „Virtu -
elle und Erweiterte Realität für höchste
Sicherheit und Zuverlässigkeit von Ein -
gebetteten Systemen“ (ViERforES) im
Rahmen des BMBF-Programms „Spit -
zen forschung und Innovation in den
Neuen Ländern“ statt. ViERforES ist
Bestandteil der Innovationsallianz Vir -
tuel le Techniken – ein Zusammenschluss
mehrerer vom Bundesministerium für
Bildung und Forschung (BMBF) unter
dem Dach der Hightech-Strategie IKT
2020 geförderter Projekte. Beteiligt an
den Forschungsarbeiten sind die Ottovon-Guericke-Universität
Magdeburg,
die TU Kaiserslautern, das Fraunhofer-
Institut für Experimentelles Software
Engineering in Kaiserslautern und das
Fraunhofer-Institut für Fabrikbetrieb und
-automatisierung in Magdeburg.
Kasten 1: Das Projekt ViERforES.
des Fahrers in unterschiedlichsten Situa -
tionen. Derartige Systeme erfordern entsprechend
leistungsfähige Softwarelösun -
gen. Die technischen Herausforderungen
bei der Realisierung solcher Systeme sind
immens. Vor allem Aspekte wie Zuver -
lässigkeit, Verfügbarkeit und Sicherheit
sind von besonderer Bedeutung (vgl.
[Sch12]). Sicherheit adressiert hier vor
allem Safety- und Security-Eigenschaften
der Systeme, d. h. die Einflüsse des Systems
auf die Umwelt (Safety) und umgekehrt
(Security). Die genannten Aspekte werden
zunehmend durch Software in ihrer
Interaktion mit elektronischen Komponen -
ten, mechanischen Bauteilen und der
Umgebung des Systems beeinflusst. Daher
muss auf die Sicherstellung der damit verbundenen
Eigenschaften innerhalb der
Software ein besonderes Augenmerk gelegt
werden.
Während Zuverlässigkeit das Ausfallver -
halten eines Systems in Abhängigkeit von
Betriebsbedingungen und Laufzeit be -
schreibt, thematisiert der Begriff Sicherheit
im Sinne von Safety die kritischen bzw.
unerwünschten Systemzustände, deren
Ursachen und Auftrittsverhalten. Eine im
Zusammenhang mit Safety weit verbreitete
Technik zur Analyse von Ursache-/ Wirkzu -
sammenhängen von Aus fäl len ist die
Fehlerbaum-Analyse (vgl. [DIN90] und
[DIN07]). Dabei handelt es sich um eine
Methode, die Ausfälle z. B. auf Komponen -
ten ebene qualitativ und quantitativ in
Relation zu gefährlichen Wirkungen im
Dr. Veit Köppen
(vkoeppen@ovgu.de)
ist geschäftsführender Leiter des Center for Digital
Engineering an der Otto-von-Guericke-Universität
Magdeburg und wissenschaftlicher Assistent im
Institut für Technische und Betriebliche
Informationssysteme.
Prof. Dr. Peter Liggesmeyer
(liggesmeyer@cs.uni-kl.de)
ist Inhaber des Lehrstuhls Software Dependability
im FB Informatik der TU Kaiserslautern, wissenschaftlicher
Direktor des Fraunhofer-Instituts für
Experimentelles Software Engineering, und
Vizepräsident der Gesellschaft für Informatik.
System setzt. Das heißt, durch diese
Methode lassen sich zum einen die Art und
Weise eines System ausfalls und zum anderen
die Wahr schein lichkeit für ein
Systemversagen erfassen. Der Terminus
„gefährlich“ bezeichnet in diesem
Zusammenhang eine Situation des Systems,
in der der Eintritt eines Ereig nisses, das zur
Verletzung von Personen oder zur
Beschädigung bzw. Verlust von Eigentum
führen kann, möglich ist. Abbildung 1 zeigt
den prinzipiellen Aufbau des bei der
78 79

fachartikel
Abb. 1: Fehlerbaum, der die Bedingung für einen Systemausfall mittels grafischer
Elemente beschreibt.
Analyse verwendeten Fehlerbaummodells
anhand eines einfachen Beispiels.
Die Fehlerbaum-Analysetechnik eignet
sich, um Fragen nach den Bedingungen,
unter denen ein bestimmter unerwünschter
Systemzustand erreicht werden kann, zu
beantworten. Das kann auch die Ab -
schätzung der Wahrscheinlichkeit für dessen
Eintritt einschließen. In den letzten
Jahren wurden das Verfahren und das zu
Grunde liegende Modell um zusätzliche
Methoden und Elemente erweitert. Dane -
ben gibt es eine Vielzahl weiterer formaler
und informaler Techniken, die gegenwärtig
zum Einsatz kommen (eine Übersicht geben
[Lig00] und [Lig09]).
Geeignete Analyseverfahren müssen zum
einen das Versagen von Hardware -
komponenten berücksichtigen. Zum anderen
müssen sie auch systematische Fehler,
d. h. Fehler, die sich während der
Konzeption, des Designs oder der
Implementierung in den für die Steuerung
relevanten Softwaremodulen manifestieren,
in die Analysen mit einbeziehen. Außerdem
spielen umweltbedingte Störeinflüsse, wie
erschwerte Witterungsbedingungen und die
Verfälschung von Sensordaten, die sich auf
die Qualität der Sensordaten auswirken
und letztendlich die Entscheidung über das
Eingreifen in das Fahrverhalten mitbestimmen,
eine nicht zu vernachlässigende Rolle.
Hinzu kommen Betrachtungen zu Reak -
tionen auf unvorhergesehene Ereignisse,
wie Teilsystemausfälle oder die Verletzung
temporaler Bedingungen (kritisch in
Echtzeitsystemen). All diese Aspekte und
viele weitere müssen durch die Analyse
abgedeckt sein.
Die aktuellen Forschungsarbeiten konzentrieren
sich darauf, existierende Model -
lierungskonzepte, wie Komponen tenfehler-
Bäume (vgl. [Kai03]) und State/Event
Fehlerbäume (vgl. [Kai06]) zu erweitern
und anzupassen, um die gewünschten
Analysen zu ermöglichen. Dies beinhaltet
in einem ersten Schritt die Definition geeigneter
Modelle, die nicht nur in der Lage
sein müssen, statische, sondern auch komplexe
dynamische Abhängigkeiten (z. B.
Adaption, zeitliche Abhängigkeiten) abzubilden.
Als Referenzsystem dient hierbei
unter anderem der Entwurf eines Acc-
Teilsystems (Adaptive Cruise Control).
Dessen Hauptaufgabe ist die Koordination
des Fahrverhaltens eines Fahrzeugs in
einem Verbund. Im Rahmen der Unter -
suchung an diesem System gilt es, die relevanten
Ursache- und Wirkzusammenhänge
bezüglich Sensorversagen und Verfälschung
von Sensordaten formal zu erfassen und zu
bewerten. Abbildung 2 zeigt einen Aus -
schnitt eines Komponentenfehler-Baums.
Schadcode und mögliche
Einflüsse auf die Sicherheit
Während die Abschätzungsmethodik im
Safety-Bereich bereits etabliert ist, müssen
auch Abhängigkeitsstrukturen hinsichtlich
einer umfassenden Sicherheit beachtet werden.
Bei komplexen, offenen Systemen
muss damit gerechnet werden, dass eine
mangelhafte Datensicherheit (Security)
Gefährdungen im Sinne von Safety hervor-
Weiterführende Ansätze
Im grundlegenden Aufbau ähneln sich die
genannten Systeme größtenteils: Auf Basis
von Sensordaten werden Entscheidungen
entsprechend vordefinierten Regeln getroffen,
die das Fahrverhalten direkt (durch
aktiven Eingriff, z. B. Abbremsen) oder passiv
(z. B. durch Warnung des Fahrers)
beeinflussen können. Systemausfälle sind
dabei auf Fehler in der Hard- oder Soft -
ware zurückzuführen. Die Eigenschaft solcher
Systeme, Echtzeitbedingungen einhalten
zu müssen, deren Adaptivität sowie
deren Komplexität machen es schwierig,
bestehende Analysetechniken und -verfahren
anzuwenden.
Abb. 2: Auszug der erweiterten Komponenten-Fehlerbäume, erstellt im Rahmen der
ACC-Analysearbeiten.
6 / 2 012

fachartikel
rufen kann. Bei der Betrachtung von komplexem
Systemverbünden, wie sie z. B. im
Fahrzeug eingesetzt werden, muss man bei
der Angriffssicherheit zwischen eingeschleustem
Schadcode und Angriffen von
außen unterscheiden.
Schadcode-Erkennung und die durch den
Nutzer einzuleitenden Maßnahmen unterscheiden
sich in der Domäne eingebetteter
Systeme grundlegend von der im Desktop-
Bereich. Die Gründe hierfür sind die zur
Verfügung stehenden Ressourcen und die
Funktionalität des Systemverbunds. Bereits
bei der Entwicklung müssen potenzielle
Eigenschaften von Schadcode betrachtet
werden – das schließt unter anderem die
folgenden Eigenschaften ein (vgl. hierzu
auch [Kil06]):
Interoperabilitätsebene
Technisch
Pragmatisch
Sozial
Semantisch
Politisch / Menschlich
Organisatorisch
Juristisch
Physisch
International
Empirisch
Dynamisch
Beispiel in der Fahrzeugtechnik
CAN-Bus.
Stelle ich die Bremse am richtigen Rad?
Nutzerakzeptanz.
Spezifikation der Maßeinheiten,
Mnemonische Namen der Datenfelder.
Gutes ABS vs. schlechte Atomenergie.
Unfallfreie Fahrt bzw. Schadensminimierung.
Darf die Bremse autonom gestellt werden?
Steckerform, Pin-Belegung.
Eignung für den weltweiten Markt.
ABS / ESP im Fahrsicherheitstraining.
Ausfallerkennung der Drehgeber.
■ Verbreitungsmethode.
■ Aktivierung.
■ Unterbringung auf dem System, insbesondere
bei verteilten Komponenten.
■ Wirkungsweise auf das System, inklusive
Fragen der Steuerung
■ Nutzung und Art der Kommunika -
tions infrastruktur.
■ Funktionalität des Schadcodes, vom
Kom munikationsmanagement bis hin
zur Spionage.
■ Selbstschutzmechanismen der Schad -
soft ware, wie Polymorphie oder Tar -
nung.
Um die Analyse während der Entwicklung
effizient zu unterstützen, sind eine formale
Klassifikation potenzieller Schadcode-
Software und deren Zusammenspiel in den
Softwarekomponenten zielführend. Hierbei
können die obigen Eigenschaften entsprechend
ihren möglichen Ausprägungen einfach
aufgenommen und während der
Entwicklung entsprechend den Szenarien,
Ressourcen und Anforderungen getestet
werden.
Eine weitere Frage bei der Berück -
sichtigung der Domäne eingebetteter
Systeme ist die Behandlung von identifiziertem
Schadcode. Dabei ist zu berück -
sichtigen, dass einerseits das Gesamtsystem
nach Möglichkeit weiter funktionieren
muss und eine Intervention durch den
Nutzer möglichst gering gehalten werden
sollte. Andererseits müssen Informationen
über die Entdeckung und mögliche
Vorgehensmaßnahmen aufgrund kleiner
Displays einfach und verständlich gestaltet
sein. Hier muss eine Vielzahl von Fragen
der Visualisierung bezüglich Eindeutigkeit
Syntaktisch
Konzeptionell
und Verständnis berücksichtigt werden.
Nur durch eine frühzeitige Einbeziehung
potenzieller Nutzer und ein entsprechendes
Anforderungsprofil in der Bedienung kann
sich an dieser Stelle ein System erfolgreich
in der Praxis bewähren. Das schließt darüber
hinaus auch Fragen der Interaktion
zwischen Nutzer und System ein. In
Abhängigkeit vom Nutzerprofil ist dabei
der Informations- und Interaktionsgrad
adaptiv anzupassen.
Faktoren Interoperabilität
und Sicherheit
Das Zusammenspiel unterschiedlicher
Syste me bedeutet zunehmend auch eine
Komplexität bei der Kopplung und Inte -
gration innerhalb des Gesamtsystems. Eine
Infrastruktur im eingebetteten Systembe -
trieb muss sicherstellen, dass der Ausfall
und der Austausch defekter oder zu ersetzender
Komponenten einfach gestaltet
sind. Das bedeutet, dass bereits im Ent -
wick lungsprozess geeignete Maßnahmen
definiert werden müssen.
Interoperabilität erfordert ein korrektes
Zusammenspiel zwischen unabhängigen
und zumeist heterogenen Komponenten
innerhalb eines Systems, um gemeinsam
eine definierte Funktionalität zu erbringen.
Theoretisch kann man durch standardisierte
Austauschformate und Kommunika -
tions strukturen eine einfach beherrschbare
Datenfelder und -typen der CAN-Nachrichten.
Kompatibler Drehgeber mit anderem Wirkprinzip des Sensors.
Tabelle 1: Interoperabilitätsebenen in der Fahrzeugtechnik.
Struktur erreichen. Jedoch stellt die Ein -
haltung der Standards eine in der Praxis
häufig sehr hohe Hürde bei der Ent -
wicklung von Komponenten dar. Das liegt
nicht nur an der Weiterentwicklung von
Techniken, sondern häufig auch an den
strikten oder einschränkenden Vorgaben
der Standards. M. Manso, M. Wachowicz
und M. Bernabé diskutieren in [Man09]
eine Vielzahl von Ebenen der Inter -
operabilität, wie in Tabelle 1 beschrieben.
Der Transfer auf Beispiele der Fahr -
zeugtechnik anhand von ABS & ESP
(Antiblockier-System und Electronic Stabi -
lity Control) findet sich ebenfalls dort.
Die Angriffssicherheit ist im großen
Maße abhängig von der Inter operabi -
litätssteuerung, d. h. von möglichen
Kommunikationsinfrastrukturen, der Ar -
chi tektur im Systemverbund, Kopplungs -
konzepten und Schnittstellen. Die Preise für
eingebettete Systeme fallen stetig. Das
ermöglicht den Einsatz redundanter
System komponenten, die sowohl die
Ausfall- als auch die Angriffssicherheit
erhöhen können. Redundanz ermöglicht
die Validation der Reaktionen der einzelnen
Komponenten. Darüber hinaus können
effiziente und sichere Implementierungen
parallel genutzt werden. So kann in definierten
Abständen eine Validierung der
Reaktionen erfolgen, ohne die Effizienz des
Systems stark einzuschränken.
80 81

fachartikel
zu Grunde liegenden Ent wicklungsprozesse
zu bewerten und entsprechend zu beeinflussen.
Abb. 3: Transformationen zwischen Entwicklung und Verifikation (vgl. [Güd12]).
Bei der Entwicklung von Systemen exis -
tieren häufig Zielkonflikte. Diese Kon flikte
müssen bereits in der Entwicklung adressiert
werden, weshalb sie bereits zu diesem
Zeitpunkt erkannt und Lösungen gefunden
werden sollten. Leistungsfähige Model -
lierungs techniken und Simulationen spielen
hier eine tragende Rolle. Aktuell werden in
den Domänen „Virtuelles Engi neering“,
„Digitales Engineering“ und „Rapid-
Prototyping“ neue Methoden, Techniken
und Werkzeuge eingesetzt, um bereits in
den frühen Phasen der System entwicklung
Eigenschaften der Systeme, aber auch der
Sicherheits- und
Zuverlässigkeitsanforderungen
Bei der Entwicklung neuer Systeme steht
oft die effiziente Konstruktion im Vorder -
grund. Das kann sich auf unterschiedliche
Aspekte, wie Time-to-Market oder Kosten,
beziehen, die im Unterschied zur Qualität
leicht erfasst werden können. Qualität
erfordert die Beachtung vieler Aspekte.
Neben Fragen der Sicherheit sind unter
anderem auch Fragen zur Zuverlässigkeit,
Korrektheit, Verfügbarkeit und Fehler -
toleranz zu beantworten. Allein eine nachträgliche
Überprüfung des Systems ist dabei
nicht zielführend. Bereits in frühen Phasen
der Konzeption und des Entwurfs – aber
auch während der Entwicklung – müssen
zweckdienliche Maßnahmen ergriffen werden.
Modellbasierte Ansätze, formale
Methoden und stochastische Verfahren
können hier geeignete Lösungen bieten.
Um noch nicht realisierte Komponenten
eines Systems bei dieser Analyse mit
Online Themenspecials des Jahres 2012
Cloud erschienen am 26.04.2012
Mobile erschienen am 05.06.2012
Requirements Engineering erschienen am 28.06.2012
Testing – neue Konzepte,
Strategien, Zukunftsaussichten erschienen am 27.09.2012
Agility – nicht nur Scrum ist agil! 18.10.2012
Architekturen – neue Modelle für Anforderungen,
Qualitätsssicherung und Risikoanalyse 15.11.2012
Anmeldung unter: www.sigs-datacom.de/os/themenspecial.htm
6/2012

fachartikel
Abb. 4: RAVON, ausgestattet mit multiplen
Sensoren zur Umwelterfassung
(Quelle: uni-kl.de/ravon).
sionalität im Entwicklungsprozess Rech -
nung getragen werden und gleichzeitige
Fehl ent wicklungen können vermieden werden.
Aufgrund der unterschiedlichen Metho den
und einzusetzenden Tools ist eine Integration
in den Entwicklungsprozess unabdingbar,
um eine Steuerung der nicht-funktionalen
Eigenschaften der Systeme handhabbar zu
gestalten (siehe Abbildung 3). So ermöglicht
es beispielsweise eine formale Beschreibung
in der Sprache SAML (vgl. [Güd12]), Sicher -
heitsanforderungen zu spezifizieren und
bereits im Entwicklungsprozess den Einfluss
dieser Faktoren zu steuern.
Abb. 5: Grafische Darstellung eines
Verhaltensmoduls mit Eingangs- und
Ausgangssteuerwerten (Quelle: [Pro10]).
betrachten zu können, ist die Integration
entsprechender Modelle notwendig. Aus
diesen Modellen müssen die zu betrachtenden
Eigenschaften abgeleitet werden. Dabei
ist es nicht hinreichend, das System –
sowohl software- als auch hardwareseitig –
zu modellieren, sondern es müssen darüber
hinaus Aspekte der Umgebung in die
Analyse einbezogen werden. Im Anschluss
kann – unter Verschmelzung von
Eigenschaftsbeschreibung und Modell –
eine Analyse erfolgen. Hierbei ist festzuhalten,
dass die stochastische Analyse durch
eine Vielzahl von Parametern und eine
hohe Anzahl an Teilkomponenten
erschwert wird. Auch die Definition der
Ziele kann konfliktbehaftet sein. Ein möglicher
Ausweg aus diesem Dilemma ist die
Identifikation von potenziellen Kompro -
missen durch eine Pareto-Optimierung
(vgl. [Ste86]). So kann der Multi di men -
Autonome Fahrzeuge
Im Vergleich mit den Sicherheitsan for -
derungen von Fahrassistenz-Systemen
übersteigen die Anforderungen von autonomen
Fahrsystemen die vorherigen deutlich.
Eine wesentliche Funktion autonomer
Fahrzeuge ist das Erreichen eines festgelegten
Zielpunkts, ausgehend vom definierten
Startpunkt. Hierbei werden die von der
Sensorik generierten Umgebungsinforma -
tionen genutzt, um dem System die Planung
und das sichere Abfahren von Routen zu
ermöglichen.
Eine besondere Eigenschaft derartiger
Systeme ist es, dass sie eigenständig, also
ohne Eingriff von außen, spezifiziertes
Verhalten korrekt, zuverlässig und sicher
umsetzen. Dabei sollen Gefährdungen (z. B.
Hindernisse oder Personen auf der Strecke)
selbstständig erkannt und – wenn notwendig
– entsprechende Gegenreaktionen initiiert
werden. Ähnlich wie bei den Assis tenz -
Abb. 6: Beispiel für die Kopplung zweier Verhaltensmodule mittels eines
Fusionsmoduls (Quelle: [Pro10]).
systemen wird eine Vielzahl von hete ro -
genen Sensoren zu einem Verbund gekoppelt.
Die produzierten Daten fusionieren zu
einem gemeinsamen Umgebungs modell,
das für die Navigation und Kolli sions -
vermeidung verwendet wird.
Die Forschungsarbeiten im Rahmen der
Entwicklung neuer Techniken für Sicher -
heitsanalysen nutzen unter anderem das
von der Arbeitsgruppe Robotik an der TU
Kaiserslautern entwickelte RAVON-
System (Robust Autonomous Vehicle for
Off-Road Navigation) (siehe Abbildung 4)
als Evaluierungsplattform. Dieses zeichnet
sich durch die Fähigkeit aus, auf der
Grundlage eines komplexen Verhaltens -
netz werks (dem „Integrated Behaviorbased
Control“ (iB2C) Network), Umge -
bungsinformationen in Navigations- und
Steuerungsbefehle umzuwandeln. Im Kern
setzt sich dieses Netzwerk aus einzelnen
Modulen, den so genannten Verhaltens -
modulen, zusammen (vgl. [Pro10], siehe
Abbildung 5). Jedes dieser Module übernimmt
bestimmte Aufgaben, wie z. B. die
Berechnung von Abstands- oder Geschwin -
dig keitswerten aus gegebenen Eingabe -
werten (ē > ). Die errechneten Ausgabev ek -
toren (ū > ) können wiederum als Eingabe für
andere Module dienen. Durch Stimulation
(s), Inhibition (ī > ) oder Aktivitätssignale (ā > )
können sich diese Module gegenseitig
beeinflussen. Um komplexes Verhalten zu
realisieren, werden Gruppen von Verhal -
tensmodulen mittels so genannter Fusions -
module zusammengeschaltet (siehe Abbil -
dung 6).
Das entstehende Netzwerk organisiert
sich auf unterschiedlichen Hierarchie -
ebenen (siehe Abbildung 7). Dabei gibt es
übergeordnete Ebenen, die z. B. für die
82 83

fachartikel
Abb. 7: Beispiel für die hierarchische Organisation auf unterschiedlichen Ebenen
(Quelle: [Pro10]).
Routenplanung verantwortlich sind, und
untergeordnete Verhaltensebenen, deren
Aufgabe ist es z. B., Anweisungen in Steuer -
daten für Lenkung, Motor usw. umzuwandeln.
Ab einem bestimmten Punkt erreichen
diese Netze eine Komplexität, bei der es
nicht mehr möglich ist, einfache Zusam -
menhänge betreffend Sicherheit und
Verlässlichkeit zu erfassen (beispielsweise
setzt sich der RAVON-Demonstrator aus
über 500 Modulen zusammen). Frage -
stellungen, die speziell in der Verwendung
von diesen Verhaltensnetzen auftauchen,
sind unter anderem:
■ Wie wirken sich Ausfälle einzelner
Module auf die Sicherheit und Zuver -
lässigkeit des Gesamtsystems aus?
■ Gibt es Module, die sich gegenseitig
blockieren und nicht-spezifiziertes
Verhalten hervorrufen können?
■ Wie wirkt sich Sensorrauschen auf das
Gesamtverhalten aus?
■ Unter welchen Bedingungen ist der
Systembetrieb nicht mehr sicher?
■ Wie wahrscheinlich ist ein System -
versagen unter bestimmten Bedin gun gen?
Aufgrund der Komplexität und der starken
Abhängigkeit der Elemente der Verhaltens -
netze sind Verfahren wie einfache klassische
Fehlerbaum-Analysen zur Bewertung
der Systemsicherheit nicht geeignet. Der
Einsatz von State-Event-Fehlerbäumen er -
mög licht es, dynamische Aspekten (z. B.
Verhaltensadaption) in die Untersuchungen
einzubeziehen. Die Module werden als
Literatur & Links
Fehlerkomponenten modelliert und deren
Abhängigkeiten in Form von Ereignissen
beschrieben. Die Modellierung konzentriert
sich dabei ausschließlich auf Bereiche
des Systems, die zu den Sicherheits -
mechanismen in Beziehung stehen. Zur
Analyse werden die Modelle in eine Form
von Petri-Netzen überführt (vgl. [Kai06]).
Auf diese Weise können die internen
Zustände von Modulen sowie deren
Abhängigkeiten zu unerwünschten System -
zuständen in Relation gesetzt werden.
Ein Ansatz zur Bewertung der Zuver -
lässig keit verfolgt die Transformation von
relevanten Teilen der Verhaltensnetze in
endliche Automaten. Das ermöglicht weitere
Analysen, z. B. die Untersuchung der
Erreichbarkeit und die Berechnung der
Wahrscheinlichkeit des Eintritts eines
bestimmten Zustands. Eine besondere
Herausforderung im Rahmen von quantitativen
Analysen stellt dabei das Abschät -
zen der Ausfallwahrscheinlichkeiten für die
Verhaltensmodule dar, da diese als Soft -
ware realisiert sind und entsprechende
Kennwerte somit nur schwierig zu erfassen
sind.
■
[DIN90] DIN 25424-2:1990-04, Fehlerbaumanalyse – Handrechenverfahren zur Auswertung
eines Fehlerbaums, Beuth Verlag 1990
[DIN07] DIN EN 61025:2007-08, Fehlzustandsbaumanalyse, Beuth Verlag 2007
[Güd12] M. Güdemann, M. Lipaczewski, S. Struck, F. Ortmeier, Unifying Probabilistic and
Traditional Formal Model Based Analysis, in: Proc. of 8. Dagstuhl-Workshop MBEES 2012 -
Model-Based Development of Embedded Systems, 2012
[Kai03] B. Kaiser, P. Liggesmeyer, O. Mäckel, A new component concept for fault trees, in: Proc.
of 8th Australian Workshop on Industrial Experience with Safety Critical Systems and Software –
SCS 2003
[Kai06] B. Kaiser, State/event fault trees. A safety and reliability analysis technique for softwarecontrolled
systems, Verlag Dr. Hut 2006
[Kil06] S. Kiltz, A. Lang, J. Dittmann, Klassifizierung der Eigenschaften von Trojanischen Pferden,
D-A-CH Security 2006, Syssec 2006
[Lig00] P. Liggesmeyer, Qualitätssicherung softwareintensiver technischer Systeme, Spektrum-
Verlag 2000
[Lig09] P. Liggesmeyer, Software-Qualität, Spektrum-Verlag 2009
[Man09] M. Manso, M. Wachowicz, M. Bernabé, Towards an Integrated Model of Inter -
operability for Spatial Data Infrastructures, Transactions in GIS 13 (1), 2009
[Pro10] M. Proetzsch, Development Process for Complex Behavior-Based Robot Control Systems,
ser. RRLab Dissertations, Verlag Dr. Hut 2010
[Sch12] F. Schmidt, Funktionale Absicherung kamerabasierter Aktiver Fahrerassistenzsysteme
durch Hardware-in-the-Loop-Tests, Dissertation, TU Kaiserslautern 2012
[Ste86] R.E. Steuer, Multiple Criteria Optimization: Theory, Computation and Application, John
Wiley & Sons 1986
6/2012

konferenzvorschau
mehr zum thema:
OOP2013.de
die autorin
OOP 2013
CONTINUOUS INNOVATION:
THE FOUNDATION FOR SUCCESS
Die OOP hat sich seit vielen Jahren zu dem Treffpunkt für technisch-fachliche Experten,
Projektleiter und IT-Führungskräfte etabliert. Auf der Konferenz erhalten diese einen exzellenten
Überblick über den aktuellen Stand des modernen Software-Engineering. Sowohl vielversprechende
Konzepte für zukünftige Herausforderungen als auch neueste Techniken, die sich bereits in der
Praxis bewährt haben, werden auf der Konferenz diskutiert. Die nächste OOP findet vom 21. bis
25. Januar 2013 im International Congress Center München statt.
Jutta Eckstein
(jutta@eckstein.com)
ist Technical Chair der OOP.
OOP
2013
software meets business
Die nächste OOP steht ganz unter dem
Motto der Innovation – nicht als Produkt,
sondern vielmehr als Haltung, wie dies
Uwe Reineck, Ulrich Sambeth und Andreas
Winklhofer in ihrem neuesten Buch ausführen.
Wie die Autoren dort ebenfalls erläutern,
ermöglicht es erst diese Haltung, neue
Probleme mit neuen Mitteln zu lösen. Was
das für die Softwareentwicklung, für
Architekturen und für verwendete Spra -
chen bedeutet, wollen wir auf der OOP-
Konferenz beleuchten. Wir möchten uns
aber nicht nur auf die technische Pers -
pektive beschränken, denn wie Prof. Dr.
Felix C. Brodbeck (Universität München)
in einem Interview mit der Süddeutschen
Zeitung deutlich macht, behindert das
heutzutage meist verankerte aufgabenorientierte
(im Gegensatz zum personenorientierten)
Management die Innovations -
kraft, da bei diesem Managementstil die
Kompetenzen und die Kreativität der
Mitarbeiter nicht genügend einbezogen
werden. Deshalb wollen wir im Rahmen
der Konferenz alternative Managementstile
betrachten.
Wie bereits 2012 wurde das Programm
auch diesmal durch die OOP-Community
gestaltet. Die neun Track-Chairs wurden
dabei von 31 Reviewern unterstützt, die
sicherstellen, dass sich das Motto
„Continuous Innova tion: The Foundation
for Success“ durch das gesamte Programm
zieht. Zu meiner großen Freude ist es uns
erneut gelungen, exzellente Keynote-
Sprecher für die Konfe renz zu verpflichten.
Darunter sind z. B.:
■
Bjarte Bogsnes erklärt, wie ein Leben
ohne Budgets gelingen kann. Dabei
handelt es sich nicht um einen theoretischen
Erguss, sondern er berichtet von
seiner Erfahrung, wie er bei seinem
Arbeitgeber Statoil die Idee des „Be -
yond Budgeting“ umgesetzt hat.
■ Da der Lean-Gedanke meist in einem
Atemzug mit Innovationen genannt
wird, freuen wir uns besonders, dass
Mary Poppendieck, ihres Zeichens
Urheberin der Lean-Softwareent wick -
lung, mit uns ihre Gedanken zum Reife -
prozess von Plattformen teilt.
■ Subbu Subramanian, Engineering-Ma -
nager des Infrastruktur-Teams bei Face -
book, gibt uns Einblicke in das Thema
Skalierung.
Interaktive Formate sollen den Austausch
über innovative Ideen anregen. So findet in
der Ausstellungshalle, wie schon bei der
letzten OOP, die „OpenArena“ statt, die
allen Teilnehmern dazu ausreichend Gele -
genheit bietet. Nicolai Josuttis veranstaltet
als „Chef de Cuisine“ eine Kochshow, bei
der drei Expertenteams an einem Beispiel
parallel mit verschiedenen Zutaten
(Standards und Tools) einen Geschäfts -
prozess umsetzen und garnieren.
Jörg Bächtiger macht mittels eines
Theater stücks die Tücken von „Conti nuous
Delivery“ deutlich. Frank Busch mann lädt
zusammen mit Kevlin Henney zu einer
„Fishbowl” ein – dabei handelt es sich um
eine offene Diskussionsrunde mit wechselnden
Teilnehmern, dieses Mal zum Thema
„Agilität und Architektur“. Und schließlich
sorgt Martin Heider mit „Pecha Kucha All
Night Long” dafür, dass ein Feuerwerk an
Ideen abgebrannt wird: Hier haben die
Sprecher gerade mal 6 Minuten und 40 Se -
kunden Zeit, um auf den Punkt zu kommen
– da bleibt keine Zeit für „Gelaber“.
Auch über die Keynotes hinaus bietet das
Programm in den einzelnen Tracks viele
Highlights: Im von Stefan Tilkov zusam -
men gestellten Track zu „Web Archi -
tecture“ spricht zum Beispiel Oliver Gierke
über „Hypermedia-getriebene REST-
Architekturen“. Bernd Kolb konnte für seinen
Technologies-Track Horia Dragomir
vom Spielehersteller Wooga gewinnen, der
in die Zukunft von HTML 5 blickt. Bei
Technologies befinden sich außerdem die
Spezial-Tracks zum Thema „Sprachen und
Mobile Development“.
Im neuen Track „Requirements Engi -
neering &Acceptance Test Driven Develop -
ment“ (RE&ATDD), gezeichnet von
Susanne Mühlbauer, gibt beispielsweise
Ellen Gottesdiener Einblicke in Sessions zu
„Product Discovery“. Matthias Bohlen
zeigt in seinem Track „Reinventing Ma -
nage ment“ viele neue Ideen im Manage -
ment auf – unter anderem werden dort
Einblicke in „Real Options, Theorie U
sowie Design und Innovation Thinking“
gegeben. Frank Buytendijk geht in diesem
Track auf das Thema „Postmodern IT“ ein.
Thorsten Janning ist verantwortlich für
„Pro ject Management& Lean IT“ und hat
hier unter anderem Robert Brazile eingeladen,
um zum Thema „Product Manage ment
für Entwickler“ zu sprechen. Michael Stal
hat den „Softwarearchitektur“-Track inklusive
einem Spezial-Track zum Thema
„Professional Architect“ gestaltet. Hier stellt
beispielsweise Gernot Starke den „Knigge
für Softwarearchitekten” vor. Den Track zu
„Agile, Lean, Scrum und Kan ban“ hat
Bernd Schiffer entworfen, in dem Einblicke
in „Lean Startup“ gegeben werden und in
dem Klaus Leopold über „Muster in
Kanban” berichtet. Schließlich gibt es noch
einen Spezial-Track zum Thema „Auto-
motive Entwicklung“ sowie einen zu
„DevOps“, also zu der Strategie, Ent -
wicklung und Produktion zur schnelleren
Inbetriebnahme enger zusammenzubringen.
Natürlich soll auch in diesem Jahr das
entspannte Networking nicht zu kurz kommen.
Den passenden Rahmen hierfür bieten
die Welcome Reception am Dienstag
mit dem anschließenden Klassiker IT-
Stammtisch, an dem Experten über das vergangene
IT-Jahr debattieren.
■
84 85

konferenzrückblick
mehr zum thema:
is.uni-paderborn.de/architekturen2012
fg-swa.gi.de
die autoren
ARCHITEKTUREN 2012:
INDUSTRIE UND
WISSENSCHAFT TREFFEN SICH
Modellgetriebene Softwareentwicklung gehört heute zum Stand der Technik. Trotzdem gibt es
immer noch viele Herausforderungen, wie die langfristige Wartung, der Übergang von
Architektur zur Implementierung und nicht zuletzt der Nachwuchs an Fachkräften in diesem
Bereich. Auf der Fachtagung „Architekturen 2012“ trafen sich Anfang Juli 2012 in Paderborn
Menschen aus Industrie und Wissenschaft, um sich zu diesen Themen auszutauschen.
Benjamin Klatt
(klatt@fzi.de)
ist wissenschaftlicher Mitarbeiter am FZI
Forschungszentrum Informatik. Der Schwerpunkt
seiner Arbeit liegt auf der Evolution und Qualitäts -
analyse von Software sowie der modellgetriebenen
Softwareentwicklung.
Die Fachgruppe Architekturen der Gesell -
schaft für Informatik (GI) verfolgt das Ziel,
die Themen Softwarearchitektur und -qualität
sowohl im industriellen Einsatz als
auch in Forschung und Lehre in
Deutschland voranzutreiben. Eine der
wichtigsten Veran stal tungen in diesem
Zusammenschluss ist die Jahrestagung der
Fachgruppe, die in diesem Jahr in der
Zukunftsmeile Fürsten allee in Paderborn
stattfand.
Zwei Tage lang wurden innovative Pro -
jekte, Best Practices, Lessons Learned und
aktuelle Forschungsprojekte in Vorträgen
und Arbeitskreistreffen diskutiert. Hierbei
trafen Architekten und Entwickler aus der
Industrie auf Professoren und Wissen -
schaftler aus der deutschen Software-
Engineering-Forschung.
Das Themenspektrum reichte in diesem
Jahr von der Modernisierung von Entwick -
l ungsprozessen, der Rekonstruktion von
Softwarearchitektur, über die langfristige
Nachvollziehbarkeit von Entwurfsentschei -
dungen, bis hin zu zukunftsweisenden
Systemen für „On-The-Fly Computing“.
Die Erfahrungsberichte der Industrie ka -
men von Firmen aus dem Paderborner Um -
feld, wie Wincor Nixdorf oder avarto, aber
auch von überregionalen Firmen, wie beispielsweise
Accso aus Darmstadt. Auch die
wissenschaftlichen Vertreter kamen nicht
nur aus Paderborn, sondern aus allen Re -
gionen Deutschlands, wie zum Beispiel dem
KIT und FZI Karlsruhe, dem Fraun hofer
IESE Kaiserslautern, der Christian-Alb rechts-
Universität Kiel und der TU Mün chen.
Wichtiger Bestandteil einer Fachgruppe
zur aktiven Vernetzung von Industrie und
Wissenschaft sind die Arbeitskreise. Hier
wird aktiv an aktuellen Themen gearbeitet
und gemeinsame Aktivitäten werden
geplant. Im Rahmen der Architekturen
2012 trafen sich die folgenden Arbeits -
kreise:
■
■
■
■
Traceability/Evolution
Langlebige Softwaresysteme
Langlebige Technische Systeme
Modellgetriebene Softwareentwicklung
Speziell in Letzterem zeigte sich, dass ein
hoher Know-how-Bedarf seitens der
Industrie besteht. Während in der Ausbil -
dung und Lehre bereits fundiertes Wissen –
auch im Umgang mit domänenspezifischen
Modellen und deren integriertem Einsatz in
der Praxis – vermittelt wird, besteht industriell
ein sehr hoher Bedarf, der, wenn
überhaupt, nur mittel- bis langfristig
gedeckt werden kann. Das liegt nicht
zuletzt an der inzwischen breiten Anwen -
dung modellgetriebener Entwicklung in
verschiedenen Domänen von eingebetteten
Systemen bis hin zu betrieblichen Informa -
tionssystemen sowohl zur effizienteren
Softwareentwicklung als auch zur Simula -
tion und Qualitätsvorhersage.
Es zeichnet sich deutlich ab, dass sich die
modellgetriebene Entwicklung dem nächs -
ten Reifegrad nähert. Vor einigen Jahren
wurde noch über Grundlagen diskutiert, beispielsweise
wie ein modellgetriebener Code-
Generator strukturiert werden sollte oder
was der UML noch an Ausdrucks mög -
lichkeiten fehlt. Dagegen spricht man heute
über die Effizienz bei der Entwick lung von
domänenspezifischen Sprachen (DSLs) oder
den Umgang mit mehreren, zusammenhängenden
DSLs. Immer mehr Open-Source-
Projekte, beispielsweise im Umfeld des
Eclipse-Modeling-Frameworks, entstehen
und werden vorangetrieben, die auf den
besagten Grundlagen aufbauen. „Die Arbeit
mit Modellen, sei es zur Architektur -
entwicklung, Simulation oder zur Analyse
von Bestandssoftware, führt die Software -
entwicklung weiter auf ihrem Weg zu einer
reifen Ingenieursdisziplin“, so Dr. Stefan
Sauer, Geschäftsführer des s-lab–Software
Quality Lab an der Universität Paderborn.
Steffen Becker
(steffen.becker@upb.de)
ist Juniorprofessor für Softwaretechnik an der
Universität Paderborn und Sprecher des GI
Arbeitskreises modellgetriebene Softwareent -
wicklung. Seine Interessen umfassen insbesondere
die Modellierung und Qualitätsanalyse dynamischer
Softwaresysteme.
Die stetige Weiterentwicklung dieser
Themen auch fachgruppenübergreifend hat
dazu geführt, dass die Fachgruppe
„Architekturen“ in diesem Jahr aus der
Fusion der Fachgruppen „Software-
Architektur“ und „Objektorientierte
Software-Entwicklung“ hervorgegangen
ist, um diese beiden Kompetenzfelder noch
besser miteinander zu verknüpfen. Durch
diese Fusion sollen die Aktivitäten stärker
gebündelt und speziell die Verbindung der
Mitglieder aus Industrie und Wissenschaft
weiter ausgebaut werden. Die entstandene
GI-Fachgruppe „Architekturen“ ist wie
ihre Vorgängerorganisationen Ansprech -
partner sowohl für ihre Mitglieder als auch
allgemein für Unternehmen und For -
schungs einrichtungen, um die Software -
technik im Bereich Architekturen und
Entwurf in Deutschland weiter zu fördern
und Kompetenzen zu vermitteln.
In diesem Sinne ist jeder Interessierte
herzlich eingeladen, sich direkt an die
Fachgruppe oder an einen der Arbeitskreise
zu wenden.
■
6/2012

seminare
80 mm hoch, 2 farbig
Wissen wie´s geht
Trainings für Java / Java EE
•Java Grundlagen- und Expertenkurse
•Java EE: Web-Entwicklung & EJB 3.0
•JSF, JPA, Spring, Struts
•Eclipse, Opensource
•IBM WebSphere, Portal, RAD
•IBM Host Grundlagen für Java Entwickler
•Java Entwicklung mit Android etc.
aformatik Training & Consulting GmbH & Co. KG
Tilsiter Str. 6 | 71065 Sindelfingen | 07031 238070
www.aformatik.de
Zusammen
Wirken
Profitieren Sie von uns!
Wir sind unabhängig, hersteller- und produktneutral.
Unsere langjährig erfahrenen, praxisnahen und didaktisch
ausgebildeten Trainer bieten Ihnen hochaktuelle
Inhalte, moderne Lerntechniken, praxisbezogene Beispiele
und Übungen mit durchgängigem Fallbeispiel in
einer angenehmen und komfortablen Lernatmosphäre.
oose.
Innovative Informatik
Persistenz mit Hibernate
OR-Mapping von Java-Objekten
29. – 31. Oktober 2012, 1.315,– € (zzgl. 19 % MwSt.)
Testkonzepte
Software-Tests zur kontinuierlichen Sicherung der
Qualität
28. – 30. November 2012, 1.315,– € (zzgl. 19 % MwSt.)
Sicherheitskonzepte unter Java
Mechanismen für Datenschutz und
Datensicherheit in Netzwerken
29. – 30. November 2012, 925,– € (zzgl. 19 % MwSt.)
Lesen bildet. Training macht fit.
Software GmbH
Henkestraße 91, 91052 Erlangen
Telefon: (09131) 89032-0
Telefax: (09131) 89032-55
meet the
Internet: training.mathema.de
E-Mail: training@mathema.de
experts
of enterprise infrastructure
Neues in Java 7
Die nächste Java Generation
5. – 6. November 2012, 835,– € (zzgl. 19 % MwSt.)
Web-Anwendungen mit
JavaServer Faces (JSF)
Komponentenbasierte
Web-Entwicklung mit
JavaServer Faces (JSF)
21. – 23. Nov. 2012
1.180,– € (zzgl. 19 % MwSt.)
2012_okt_os_2_9.indd 1
13.09.2012 11:12:08 Uhr
Vom Wissen zum Können
Seminare
o Agiles Requirements Engineering
o Analyse und Design mit UML
mit Tooltag oder OCUP-F-Zertifizierung
o Requirements Engineering & Management
optional mit CPRE-Zertifizierung
o Geschäftsprozesse modellieren mit BPMN
optional mit OCEB-Zertifizierung
o Systems Engineering mit SysML/UML
optional mit OCSMP-Model-User-Zertifizierung
o CTFL: Certified Tester Foundation Level
o Agiles Testen
o Softwarearchitektur
optional mit CPSA-Zertifizierung
o Architekturbewertung
o Kommunikation & Moderation
für Analytiker und Entwickler
o Certified Scrum Master
o Führen als Scrum Master
o Professional Scrum Master
o Agiles SW-Projektmanagement
Iteratives Vorgehen und Timeboxing
o PMI Agile Certified Practitioner
(PMI-ACP) SM
o Java für Anwendungsentwickler
o Einstieg in Enterprise JavaBeans
Publikationen unserer Trainer
oose.de
Kontakt:
SIGS-DATACOM GmbH, Anja Keß,
Lindlaustraße 2c, D-53842 Troisdorf,
Tel.: +49 (0) 22 41 / 23 41-201, Fax: +49 (0) 22 41 / 23 41-199
Email: anja.kess@sigs-datacom.de
www.sigs-datacom.de
WISSENSVERMITTLUNG aus 1. Hand
■ Continuous Delivery
Ganzheitliche Optimierung
der Entwicklungsprozesse!
Michael Hüttermann
16. November 2012, Köln 1.090,- € zzgl. MwSt.
■ Software Testen im 21. Jahrhundert
Effektive und effiziente Verfahren
zum professionellen Testen
Peter Zimmerer
20. – 22. November 2012, München 2.090,- € zzgl. MwSt.
■ Clean Code Developer Akademie:
Komponentenorientierung -
Software arbeitsteilig entwickeln
Stefan Lieser, Ralf Westphal
21. – 23. November 2012, Hamburg 2.290,- € zzgl. MwSt.
■ Methoden und Sozialkompetenz
in IT-Projekten
Souverän handeln
Anneliese Engel, Daniela Scheurlen
21. – 22. November 2012, Nürnberg 1.590,- € zzgl. MwSt.
■ Best Practices für sichere Web-Anwendungen
Sicherheitslücken in Webanwendungen
erkennen, schließen und vermeiden
Thomas Schreiber
28. – 30. November 2012, München 2.090,- € zzgl. MwSt.
■ Die Architektur Akademie
Konzeption, Erstellung und Weiterentwicklung
von tragfähigen Software-Architekturen
Frank Buschmann
4.690,- € zzgl. MwSt.
10. – 12. Dezember 2012, München inkl. 5 Übernachtungen
86 86 87 87

vorschau
THEMENVORSCHAU JANUAR/FEBRUAR 2013
Dieses Heft erscheint am 14. Dezember 2012
Schwerpunktthema:
IT-Trends 2013
Linking Open Data
Modellgetriebene Multiplattform-Entwicklung
Verschlankung der IT-Organisation durch Prozessvarianten
Beyond Budgeting
Agiles Testen: Die Mischung macht’s
Und andere Trendthemen
SAGEN SIE UNS IHRE MEINUNG!
Leserbriefe nehmen wir gerne entgegen.
Schicken Sie einfach eine E-Mail mit Namen
und Anschrift an
leserbrief@objektspektrum.de.
Die Redaktion behält sich Kürzungen vor. In
keinem Fall spiegeln Leserbriefe die Meinung
der Redaktion wider.
Hinweis: Diese Vorschau ist ein Auszug aus der aktuellen Planung. Änderungen behalten wir uns vor.
WEITERE SCHWERPUNKTTHEMEN 2013
März/April 2013: IT-Governance
Mai/Juni 2013: Requirements-Engineering
Juli/August 2013: Testautomatisierung
aufruf
AUFRUF ZU BEITRÄGEN FÜR DIE AUSGABE MÄRZ/APRIL 2013
Einreichung der Entwürfe bis zum 16. Dezember 2012
Wir suchen anspruchsvolle, gut geschriebene, unterhaltsame Fachbeiträge zu allen Themenbereichen von OBJEKTspektrum, insbesondere auch zum
Schwerpunktthema:
IT-Governance
In dieser Ausgabe von OBJEKTspektrum legen wir besonderen Wert auf Artikel, die entweder moderne Konzepte und Werkzeuge beschreiben oder Erfahrungs -
berichte bieten. Mögliche Themen können sein:
IT-Kennzahlen und IT-Management-Cockpits
Portfolio-Planung und -Steuerung
Zentrale und dezentrale Steuerung der IT
IT-Demand- und IT-Supply-Varianten
Ansätze für Lean IT-Management
Beiträge sollten einen Umfang von bis zu 22.000 Textzeichen (ohne Leerzeichen) haben und ein bis zwei Abbildungen pro Seite (bei 4-6 Heftseiten) enthalten.
Weitere Informationen und Termine finden Sie unter sigs-datacom.de/fachzeitschriften/objektspektrum/hinweise-fuer-autoren/aufruf-zu-beitraegen.html
oder folgen Sie uns auf Twitter unter: twitter.com/objektspektrum.
inserenten
FIRMA URL SEITE
Acando GmbH www.acando.de 56
aformatik Training & Consulting GmbH & Co.KG www.aformatik.de 86
andrena Objects www.andrena.de 41
bbv Software Services AG www.bbv.ch 13
Capgemini Deutschland GmbH www.capgemini.de 57
Carl Hanser Verlag www.hanser.de 23; 53
DB Systel GmbH www.db.de/karriere 59
IBM Deutschland www.ibm.com 45-49
innoQ Deutschland GmbH www.innoq.com 55
JavaSPEKTRUM Miniabo www.javaspektrum.de 60
MATHEMA Software GmbH www.mathema.de 17; 86
OBJEKTspektrum Information Days www.infodays.de 88
OBJEKTspektrum-Leserbefragung www.objektspektrum.de 67
OBJEKTspektrum Miniabo www.objektspektrum.de 60
Online Themenspecials www.objektspektrum.de 81
OOP 2013 www.oop2013.de 2
oose Innovative Informatik GmbH www.oose.de 86
FIRMA URL SEITE
Orientation in Objects GmbH www.oio.de 29
SIGS DATACOM Wissen www.sigs-datacom.de/wissen 38; 63
Software Quality Lab GmbH www.software-quality-lab.com 58
Softwareforen Leipzig GmbH www.softwareforen.de 35
SparxSystems Central Europe www.sparxsystems.at 19
Banderolen (teilweise nur Teilauflage):
IBM Deutschland
www.ibm.com
Software Quality Lab GmbH
www.software-quality-lab.com
Posterbeilage:
bbv Software Services AG
www.bbv.ch
Teilbeilagen:
OOP 2013
www.oop2013.de
OBJEKTspektrum Inforrmation Days
www.infodays.de
Software & Support Media GmbH
www.entwickler-akademie.de
6/2012

iSAQB
2. iSAQB Architekturtage
Softwarearchitektur
im Team.
Softwarearchitektur
im Wandel.
■ 20.11.2012, München ■ 21.11.2012, Frankfurt ■ 22.11.2012, Düsseldorf
www.infodays.de
Platin-Sponsoren:
Gold-Sponsoren:
Silber-Sponsoren:
oose.
Innovative Informatik