Effiziente Softwareentwicklung mit Referenzmodellen

Effiziente Softwareentwicklung mit Referenzmodellen Jörg Becker · Patrick Delfmann Tobias Rieke (Herausgeber) Effizi...

Author: Jörg Becker | Patrick Delfmann | Tobias Rieke (Editors)

38 downloads 1159 Views 4MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

Effiziente Softwareentwicklung mit Referenzmodellen

Jörg Becker · Patrick Delfmann Tobias Rieke (Herausgeber)

Effiziente Softwareentwicklung mit Referenzmodellen Mit 70 Abbildungen und 3 Tabellen

Physica-Verlag Ein Unternehmen von Springer

Professor Dr. Jörg Becker Dr. Patrick Delfmann Tobias Rieke Westfälische Wilhelms-Universität Münster European Research Center for Information Systems (ERCIS) Leonardo-Campus 3 48149 Münster [email protected] [email protected] [email protected]

ISBN 978-3-7908-1993-9 Physica-Verlag Heidelberg

Bibliografische Information der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar. Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik Deutschland vom 9. September 1965 in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des Urheberrechtsgesetzes. Physica-Verlag ist ein Unternehmen von Springer Science+Business Media springer.de © Physica-Verlag Heidelberg 2007 Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften. Herstellung: LE-TEX Jelonek, Schmidt & Vöckler GbR, Leipzig Umschlaggestaltung: WMX Design GmbH, Heidelberg SPIN 12111732

134/3180YL - 5 4 3 2 1 0

Gedruckt auf säurefreiem Papier

Vorwort

Die deutsche Softwarebranche ist zunehmend von dem Trend geprägt, Routineaufgaben, die in späten Phasen des Softwareentwicklungsprozesses durchgeführt werden müssen, ins Ausland, insbesondere in Billiglohnländer, zu verlagern. Besonders hiervon betroffen sind reine Programmiertätigkeiten. Bemühungen, den Softwarestandort Deutschland zu stärken, sollten sich aus diesem Grund auf frühe Phasen der Softwareentwicklung, insbesondere die Fachkonzeption, konzentrieren. Dieser Phase kommt enorme Bedeutung zu, da hier die betriebswirtschaftlichen Anforderungen, denen die spätere Software genügen soll, in eine Form überführt werden, die als Ausgangsbasis für die Softwareimplementierung verwendet werden kann. Fehler im Fachkonzept können aus diesem Grund im Ergebnis zu einer Software führen, die sich für den ursprünglich angestrebten Zweck nicht mehr eignet. Eine Herausforderung in der Softwareentwicklung besteht also darin, hochwertige Fachkonzepte zur Verfügung zu stellen, um die Entwicklung von Software hoher Qualität zu ermöglichen. Die Entwicklung von solchen Fachkonzepten setzt voraus, dass entsprechendes Domänenwissen zur Verfügung steht. Für die Repräsentation solchen Wissens bieten sich Referenzmodelle an. Im vorliegenden Band wird untersucht, in wie weit Referenzmodelle den Softwareentwicklungsprozess unterstützen können. Dabei wird stets das Ziel verfolgt, Softwareentwickler weitestgehend von sämtlichen Aufgaben zu entlasten, die automatisierbar sind. Hierzu gehört insbesondere die Verwaltung von Modellvarianten, die aufgrund der Vielfalt der Anforderungen unterschiedlicher Unternehmen an Software (z. B. abhängig von Unternehmensmerkmalen wie Sektor, Sparte, Wirtschaftsstufe, Geschäftsart etc.) konstruiert und gepflegt werden müssen. Weiterhin können Teile des Softwarecodes automatisiert aus fachkonzeptionellen Modellen generiert werden. Letztlich ist die Kommunikation mit den Softwarenutzern durch geeignete Controllingmechanismen zu unterstützen, die dem Softwareentwickler anzeigen, in wieweit die Anforderungen der Softwarenutzer erfüllt sind.

VI

Vorwort

Der vorliegende Sammelband ist im Rahmen des vom Bundesministerium für Bildung und Forschung (BMBF) geförderten Forschungsprojekts RefMod06 entstanden. Im RefMod06-Projekt sind für die Unterstützung des Softwareentwicklungsprozesses durch Automatisierung von Teilaufgaben verschiedene Konzepte entwickelt worden, die in den einzelnen Beiträgen dieses Bandes vorgestellt werden. JÖRG BECKER, PATRICK DELFMANN und TOBIAS RIEKE vermitteln in ihrem Beitrag Referenzmodellierung – Perspektiven für die effiziente Gestaltung von Softwaresystemen einen Überblick über die Zusammenhänge der verschiedenen Entwicklungskonzepte und motivieren die detaillierten Ausführungen der folgenden Beiträge. Das grundlegende Konzept der Softwareentwicklung mit Referenzmodellen, die konfigurative Referenzmodellierung, wird im Beitrag von PATRICK DELFMANN und ARMIN STEIN vorgestellt. Aufbauend auf theoretischen Grundlagen der konfigurativen Referenzmodellierung wird ein spezielles Fachkonzept für ein konfiguratives Referenzmodellierungswerkzeug entwickelt, das die redundanzarme Verwaltung von Modellvarianten ermöglicht. Zur Umsetzung dieses Fachkonzepts konstruieren TOBIAS RIEKE und ARMIN STEIN eine Architektur eines konfigurativen Referenzmodellierungswerkzeugs – adapt(x). Die Funktionalitäten des Modellierungswerkzeugs werden an konkreten Modellierungs- und Variantenbildungsbeispielen im Beitrag Anpassung von Referenzmodellen mit adapt(x) von PATRICK DELFMANN, TOBIAS RIEKE und ARMIN STEIN gezeigt. JULIA WAGNER, THOMAS ANDRES und YVES LAUER diskutieren in ihrem Beitrag Vom Prozess zur Ausführung – Modellgestützte Entwicklung betriebswirtschaftlicher Software Konzepte zur automatisierten Überführung von Softwaremodellen und ihren Varianten in Softwarecode. Der Sicherstellung der Qualität des gesamten Softwareentwicklungsprozesses sowie der Software selbst widmen sich CHRISTIAN SEEL und PETER LOOS, indem sie entsprechende Mechanismen für das Controlling konfigurativer Referenzmodelle vorstellen. Die konkrete Anwendung der konfigurativen Referenzmodellierung im Rahmen der Konstruktion von Warenwirtschaftssystemen zeigen MICHAEL EISENBARTH und CLAUS KÖDEL in ihrem Beitrag Entwicklung konfigurativer Referenzmodelle für Warenwirtschaftssysteme mit adapt(x). Die Ergebnisse des Forschungsprojekts RefMod06 sind auf Disziplinen, die mit der Softwareentwicklung verwandt sind, übertragbar und umfassen ebenfalls die Organisationsgestaltung und Unternehmensmodellierung. Dieser Sammelband richtet sich damit neben der wissenschaftlichen Community der Wirtschaftsinformatik insbesondere an Mitglieder von IT- und Organisationsabteilungen in Unternehmen aller Wirtschaftszweige und Branchen sowie an Softwarehäuser und Unternehmensberatungen.

Vorwort

VII

Wir möchten uns bei allen Autoren, Organisatoren und Beteiligten, die das Forschungsprojekt und diese Veröffentlichung überhaupt möglich gemacht haben, herzlich bedanken. Insbesondere danken wir dem Bundesministerium für Bildung und Forschung (BMBF) sowie dem Projektträger, dem Deutschen Zentrum für Luft- und Raumfahrt (DLR), die das Projekt RefMod06 im Zeitraum vom 01.01.2004 bis zum 30.06.2006 finanziell gefördert haben (Geschäftszeichen: 01 IS C05 A). Münster, im Juli 2007

Jörg Becker Patrick Delfmann Tobias Rieke

Inhaltsverzeichnis

Vorwort ........................................................................................... V Referenzmodellierung – Perspektiven für die effiziente Gestaltung von Softwaresystemen Jörg Becker, Patrick Delfmann, Tobias Rieke.........................................1 1 Motivation .............................................................................................. 1 2 Das Forschungsprojekt RefMod06 ......................................................... 2 2.1 Entwicklung einer konfigurativen Referenzmodellierungstechnik ....................................................... 3 2.2 Entwicklung von Codegeneratoren................................................. 4 2.3 Entwicklung von Controllingmechanismen.................................... 5 3 Projektverlauf ......................................................................................... 6 4 Projektergebnis ....................................................................................... 8 Literaturverzeichnis ..................................................................................... 9 Fachkonzept eines konfigurativen Referenzmodellierungswerkzeugs Patrick Delfmann, Armin Stein ...........................................................11 1 Wiederverwendungsansätze für Informationsmodelle ......................... 11 2 Grundlagen der konfigurativen Referenzmodellierung ........................ 12 2.1 Konfigurationsparameter .............................................................. 12 2.2 Konfigurationsmechanismen ........................................................ 13 3 Fachkonzept des Referenzmodellierungswerkzeugs ............................ 20 3.1 Grundlegende Spezifikationen...................................................... 20 3.2 Konfigurationsmechanismen ........................................................ 23 4 Implementierungsaspekte ..................................................................... 29 5 Ausblick................................................................................................ 30 Literaturverzeichnis ................................................................................... 30

X

Inhaltsverzeichnis

Architektur eines konfigurativen Referenzmodellierungswerkzeugs – adapt(x) Tobias Rieke, Armin Stein ................................................................ 33 1 Gestaltungsentscheidungen für die Architektur eines konfigurativen Referenzmodellierungswerkzeugs ............................... 33 2 Die Softwarearchitektur von adapt(x) .................................................. 34 3 XML-basierter Austausch von Modelldaten: CML.............................. 35 4 Ablauf einer Konfiguration innerhalb von adapt(x) ............................. 40 5 Vorbereitung der Konfiguration in ARIS mit Makros.......................... 40 Literaturverzeichnis ................................................................................... 41 Anpassung von Referenzmodellen mit adapt(x) Patrick Delfmann, Tobias Rieke, Armin Stein ..................................... 43 1 Vorbereitung der Konfiguration in adapt(x)......................................... 43 2 Vorbereitung der Konfiguration in ARIS ............................................. 47 3 Durchführung der Konfiguration.......................................................... 48 4 Zusammenfassung und Ausblick.......................................................... 57 Literaturverzeichnis ................................................................................... 59 Vom Prozess zur Ausführung – Modellgestützte Entwicklung betriebswirtschaftlicher Software Julia Wagner, Thomas Andres, Yves Lauer......................................... 61 1 Einleitung ............................................................................................. 61 2 Model Driven Architecture (MDA)...................................................... 62 3 Anwendungsfelder der MDA ............................................................... 64 3.1 Umsetzung von Geschäftsprozessen in IT-Systeme ..................... 64 3.2 Investitionsschutz und Technologie-Lebenszyklen ...................... 64 4 Modellgestützte Entwicklung am Anwendungsbeispiel Ticketreservierung ................................................................................ 65 4.1 Geschäftsprozessanalyse............................................................... 67 4.2 Anforderungsanalyse .................................................................... 69 4.3 Analyseklassemodell..................................................................... 71 4.4 Systemdesign und Generierung .................................................... 73 5 Fazit und Ausblick................................................................................ 74 Literaturverzeichnis ................................................................................... 76

Inhaltsverzeichnis

XI

Controlling konfigurativer Referenzmodelle Christian Seel, Peter Loos ..................................................................77 1 Motivation für das Controlling konfigurativer Referenzmodelle ......... 77 2 Teilaufgaben des Controllings konfigurativer Referenzmodelle.......... 80 2.1 Controlling der Referenzmodelladaption...................................... 83 2.2 Controlling des Projektmanagements ........................................... 88 2.3 Controlling des konfigurierbaren Referenzmodells ...................... 89 3 Modellierung der Controllingmechanismen und -konzepte ................. 94 4 DV-technische Umsetzung ................................................................... 99 5 Fazit .................................................................................................... 103 Literaturverzeichnis ................................................................................. 104 Entwicklung konfigurativer Referenzmodelle für Warenwirtschaftssysteme mit adapt(x) Michael Eisenbarth, Claus Ködel ......................................................107 1 Motivation .......................................................................................... 107 1.1 Ausgangssituation ....................................................................... 108 1.2 Stand der Praxis .......................................................................... 108 1.3 Anforderungen an eine Konfigurationsunterstützung................. 112 2 adapt(x) bei maxess ............................................................................ 113 2.1 Nutzungsszenario........................................................................ 113 2.2 adapt(x)-Konfiguration ............................................................... 114 2.3 Erzeugung von Kundenvarianten mithilfe der Elementselektion über Konfigurationsterme .............................. 115 2.4 Ausblenden von maxess-spezifischen Modellelementen mit der Elementselektion über Konfigurationsattribute.............. 120 3 Fazit .................................................................................................... 125 Autorenverzeichnis.....................................................................127

Referenzmodellierung – Perspektiven für die effiziente Gestaltung von Softwaresystemen

Jörg Becker, Patrick Delfmann, Tobias Rieke Abstract: Die frühen Phasen der Softwareentwicklung – insbesondere die Fachkonzeption – werden immer wichtiger, da aus hier gemachten Fehlern enorme Zusatzkosten in späteren Phasen des Softwareentwicklungsprozesses resultieren können. Referenzmodelle unterstützen die fachkonzeptionelle Spezifikation und helfen Softwareunternehmen bei der Gestaltung ihrer Software. Um am Markt bestehen zu können, müssen Softwareunternehmen in der Lage sein, die speziellen Anforderungen von Software nutzenden Unternehmen einerseits möglichst vollständig und andererseits möglichst zeitnah zu erfüllen. Mit dem Ziel, Softwareunternehmen entsprechend zu befähigen, ist im vom Bundesministerium für Bildung und Forschung (BMBF) geförderten Projekt RefMod06 ein Konzept entwickelt worden, das erstens eine Methode zum Variantenmanagement von kundenspezifischen, fachkonzeptionellen Softwaremodellen, zweitens eine Methode zur automatisierten Überführung dieser Modelle in Code und drittens eine Methode zum Controlling des Softwareentwicklungsprozesses zur Verbesserten Reaktion auf Kundenanforderungen umfasst. In diesem Beitrag wird ein Überblick über die verschiedenen im Projekt RefMod06 erzielten Teilergebnisse und deren Beziehungen vermittelt. Diese werden in den weiteren Beiträgen des vorliegenden Sammelbands detailliert dargestellt.

1

Motivation

Referenzmodelle sind in der Praxis seit einigen Jahren als probates Hilfsmittel bei der Gestaltung von Softwaresystemen bei Großunternehmen etabliert. Das in den Referenzmodellen enthaltene Know-how, das bei der Gestaltung von fachkonzeptionellen Modellen in den frühen Phasen der Softwareentwicklung genutzt werden kann, wirkt sich kosten- und zeit-

2

Jörg Becker, Patrick Delfmann, Tobias Rieke

mindernd auf den Softwareerstellungsprozess aus [BeSc04, S. 74; Silv01; RoAa07]. Auch für kleine und mittlere Softwareunternehmen (KMSU) verspricht die Wiederverwendung des in Referenzmodellen enthaltenen Wissens Einsparpotenziale. Da i. d. R. aber Referenzmodelle allgemeingültig formuliert sind und Kunden von KMSU sich typischerweise auf speziell gearteten Nischenmärkten platzieren, sind die Referenzmodelle an die Anforderungen der speziell gearteten Märkte und Teilmärkte anzupassen. Weiterhin ist zu erwarten, dass Anpassungen nicht nur Markt- sondern auch Kundenindividuell vorzunehmen sind. Da sich die erstellten Varianten der verschiedenen Kunden meist in großen Teilen überlappen, entstehen Redundanzen in der Modellbasis, die wiederum Zusatzaufwand für die Modellpflege nach sich ziehen können. Die daraus resultierende umfangreiche und komplexe Modellbasis erfordert einen erhöhten Pflegeaufwand zur Minimierung etwaiger Redundanzen und Inkonsistenzen. Kurzfristige Anforderungen von bestehenden Kunden, die sich in einer weiteren Adaption der Modelle äußern können, sind daher aufgrund des hohen Pflegeaufwandes meist nicht möglich. Anpassungen der Software, die auf Basis eines effizienten und wenig aufwändigen Feedbacks realisiert werden könnten, bleiben aufgrund der fehlenden methodischen Unterstützung häufig aus. Die Wiederverwendung und Adaption von Referenzmodellen erscheint aus den genannten Gründen für die meisten KMSU zunächst nicht lohnenswert, da es den Anschein hat, dass die Einsparungen, die durch die Nutzung von Referenzmodellen zu erzielen sind, den erhöhten Adaptionsund Pflegeaufwand nicht kompensieren können („Referenzmodellierungsdilemma“; vgl. [BDKK02, S. 26]). Die Adaption in den frühen fachkonzeptionellen Phasen zieht zudem eine entsprechende Adaption der nachgelagerten Phasen nach sich, die durch unzureichende methodische Unterstützung weiteren Aufwand erzeugen.

2

Das Forschungsprojekt RefMod06

Im Rahmen des in diesem Sammelband vorgestellten Forschungsprojekts RefMod06 ist deshalb ein Konzept entwickelt worden, das es kleinen und mittleren Softwareunternehmen ermöglicht, das in Referenzmodellen enthaltene Know-how effizient für die Entwicklung von Standardsoftware zu nutzen. Die Softwareentwicklung erfolgt üblicherweise entsprechend den klassischen Phasen (Anforderungs-)Analyse, Entwurf, Implementierung, Test und Betrieb (vgl. Abbildung 1) [Balz98 S. 99].

Perspektiven für die effiziente Gestaltung von Softwaresystemen

3

Abbildung 1: Phasenmodell für das Software Engineering

Das Projekt setzt auf Basis dieses generischen Vorgehensmodells an drei Stellen an. 1. In der Phase der Anforderungsanalyse wird das Management von Modellvarianten, die bspw. für verschiedene Kunden gepflegt werden müssen, explizit berücksichtigt. Adaptionsmechanismen für SoftwareReferenzmodelle erlauben eine redundanzfreie und damit weniger aufwändige und fehleranfällige Verwaltung von Modellvarianten. 2. Die nachfolgenden Phasen werden entsprechend der Idee der „Model Driven Architecture (MDA)“ [OMG03] durch Codegeneratoren unterstützt. 3. Ist die entwickelte Software in den Betrieb übergegangen, kommt es regelmäßig zu nachträglichen Anforderungen der Kunden an den Softwarehersteller. Derzeit besteht hier eine Lücke, die die Phase des Betriebs mit der Anforderungsanalyse für ein neues Release der Software verbindet. Controllingmechanismen helfen in verschiedenen Phasen, ein Feedback in frühere Phasen nachfolgender Iteration zu ermöglichen. Die Ansatzpunkte der drei Teilziele des Forschungsprojektes sind der folgenden Abbildung dargestellt und werden in den folgenden Unterabschnitten detaillierter betrachtet:

Abbildung 2: RefMod06-Phasenmodell für das Software Engineering

2.1 Entwicklung einer konfigurativen Referenzmodellierungstechnik Die Nutzung von Referenzmodellen im Rahmen der Anforderungsanalyse des Softwareentwicklungsprozesses ermöglicht es, das im Referenzmodell enthaltene und der Software zu Grunde liegende Know-how als Basis für eine Diskussion mit dem Kunden zu nutzen. Der Kunde kann auf Basis der

4


fachkonzeptionellen Informationsmodelle, die noch keine DV-spezifischen Informationen enthalten und daher für die Fachanwender noch gut verständlich sind, Abweichungen und Ergänzungen zum dargestellten Referenzmodell aufzeigen. Die hieraus entstehende Kundenvariante des Modells wird in das Referenzmodell integriert. Ebenso wird mit anderen Kundenvarianten verfahren. Es entsteht ein Gesamtmodell, das alle Varianten bereits enthält. Vorteilhaft hieran ist, dass Gemeinsamkeiten der Kundenvarianten in diesem Gesamtmodell nur einmal gepflegt werden müssen. Soll eine Variante separat angezeigt werden, soll diese aus dem Referenzmodell heraus generiert werden können. Zur Unterstützung dieses Vorgehens wird eine spezielle Referenzmodellierungstechnik benötigt, die die teilautomatisierte Generierung von Referenzmodellvarianten erlaubt sowie durch methodische Hilfestellungen beschleunigt und vereinfacht. Die Modellierungstechnik stellt Mechanismen bereit, die eine einfache Markierung von Varianten erlaubt und diese redundanzfrei im Referenzmodell ablegt. Eine Referenzmodellierungstechnik, die per se bereits Anpassungsmechanismen enthält, ist nur dann anwendbar, wenn sie durch ein Modellierungswerkzeug implementiert ist. Daher wird auf Grundlage der fachkonzeptionellen Spezifikation der Modellierungstechnik ein Prototyp für ein ReferenzmodellierungswerkzeugPlugin implementiert. Dieser ermöglicht es im Rahmen der Anforderungsanalyse zum einen, eine Vorkonfiguration für das Kundengespräch aufgrund von Unternehmensmerkmalen vorzunehmen. Zum anderen ist es erforderlich, dass die einzelnen im Referenzmodell enthaltenen Kundenvarianten selektiert und nicht relevante Modellelemente (anderer Kunden) ausgeblendet werden. Mit der Entwicklung der Referenzmodellierungskomponente soll die Flexibilität der Softwareentwicklung insbesondere in der Phase der Anforderungsanalyse gesteigert werden. Auch ist eine Steigerung der mit dem Variantenkonzept einhergehenden Modellqualität Ziel der Entwicklung. 2.2 Entwicklung von Codegeneratoren Basis des weiteren Prozesses der Softwareentwicklung ist das kundenspezifische Modell, das aus dem Referenzmodell abgeleitet wird. Ein übliches weiteres Vorgehen besteht entweder im Customizing von Standardsoftware oder in der weiteren manuellen Verfeinerung des Softwaremodells bis hin zur Implementierung. Im Rahmen des Projekts RefMod06 wird das Softwaremodell – der Idee der Model Driven Architecture (MDA) [OMG03] folgend – als Input für Codegeneratoren verwendet. Über mehrere Zwischenergebnisse in Form


5

von Modellen unterschiedlichen Technisierungsgrads wird das Softwaremodell sukzessive und weitgehend automatisiert in konkreten Softwarecode überführt. Aufgrund der teilweisen Automatisierung soll die Effizienz des Softwareentwicklungsprozesses einerseits gefördert werden. Andererseits soll zudem die Reaktionszeit auf kurzfristige Änderungswünsche seitens des Kunden verringert werden, so dass eine erhöhte Flexibilität des Softwareunternehmens erreicht werden kann. Das zweite Teilziel dieses Forschungsprojekts besteht daher in der Unterstützung des Softwareentwicklungsprozesses durch automatisierte Generierung von technischen Softwaremodellen und Softwarecode. 2.3 Entwicklung von Controllingmechanismen Nach Fertigstellung der Software und Auslieferung an den Kunden beginnt für die meisten Softwareunternehmen die Phase der Betreuung der Software und des technische Supports. Zudem ist es üblich, dass nach Auslieferung der Software Korrekturen durchgeführt und weitere Anforderungen an die Software gestellt werden. Hier werden jedoch üblicherweise nur die dringend notwendigen Anforderungen spezifiziert, da kleine Schwachstellen in der Bedienung, überflüssige Menüstrukturen, Funktionalitäten und Abläufe in der Regel durch den Anwender kompensiert werden können. Dem Softwareunternehmen werden diese Aspekte daher häufig nicht mitgeteilt und fließen damit auch nicht zeitnah in ein neues Release der Software ein. Mechanismen für ein effizientes Feedback fehlen bislang in vielen branchenspezifischen Lösungen der KMSU. Daher verfolgt das dritte Teilziel des Forschungsprojekts die Entwicklung von Controllingmechanismen für die verschiedenen Phasen der Softwareentwicklung. So wird in diesem Rahmen der Erfolg der Software hinsichtlich der Passgenauigkeit der ausgewählten Referenzmodellvariante, der Umsetzung in Software und der Effizienz und Effektivität der Software im Einsatz beim Kunden untersucht. Alle drei Kriterien werden gemessen und bewertet und können wertvolle Anregungen liefern, die wiederum zu einer Anpassung der Referenzmodelle führen können. Mechanismen, die ein Controlling der Einführung und ein Monitoring der laufenden Software ermöglichen, werden in die fachkonzeptionelle Spezifikation der Referenzmodellierungstechnik integriert. Hiermit soll die Qualität der Software kontinuierlich gesteigert und eine zeitnahe Umsetzung neuer Anforderungen von Seiten des Marktes erreicht werden.

6

3


Projektverlauf

Die drei Teilziele werden zur Realisierung in ein Phasenmodell eingebettet (vgl. Abbildung 3). Als Input für die Spezifikation der Referenzmodellierungstechnik dient das Ergebnis einer projektspezifischen Anforderungsanalyse, die einerseits theoretische Anforderungen an eine konfigurative Referenzmodellierungstechnik und andererseits spezielle Anforderungen seitens der KMSU beinhaltet.

Abbildung 3: Phasenmodell des Projekts RefMod06

Aufbauend auf der Anforderungsanalyse werden die theoretischen Grundlagen der konfigurativen Referenzmodellierung ermittelt und als Fachkonzept realisiert (zu den theoretischen Grundlagen der konfigurativen Refe-


7

renzmodellierung und entsprechenden Fachkonzepten vgl. ausführlich [BDKK02; BKKD03; BeDK04; Delf06; DeKn07]). Dabei sind die Teilaufgaben der Entwicklung einer Basismodellierungstechnik, der Integration der Konfigurationsmechanismen, der Anreicherung um Controllingkonzepte und der Entwicklung von Transformationsmechanismen für die Codegenerierung zu erfüllen. Mit dem Ziel, ein konfiguratives Referenzmodellierungswerkzeug zu implementieren, werden in einem nächsten Schritt die theoretischen Grundlagen der konfigurativen Referenzmodellierung zur Spezifikation eines Fachkonzepts für ein solches Werkzeug wiederverwendet. Die allgemeingültig formulierten theoretischen Grundlagen werden hierbei auf die speziellen Anforderungen seitens der Implementierungsplattform – eines bestehenden Basismodellierungswerkzeugs – übertragen. Das Fachkonzept (vgl. hierzu den Beitrag Fachkonzept eines konfigurativen Referenzmodellierungswerkzeugs von PATRICK DELFMANN und ARMIN STEIN) wird schließlich für die Implementierung des konfigurativen Referenzmodellierungswerkzeugs verwendet. Die Architektur dieses Werkzeugs wird vorgestellt (vgl. hierzu den Beitrag Architektur eines konfigurativen Referenzmodellierungswerkzeugs – adapt(x) von TOBIAS RIEKE und ARMIN STEIN) und sein Funktionsumfang sowie seine Anwendung (vgl. den Beitrag Anpassung von Referenzmodellen mit adapt(x) von PATRICK DELFMANN, TOBIAS RIEKE und ARMIN STEIN) beschrieben. Die Umsetzung der mit dem Modellierungswerkzeug entstehenden fachkonzeptionellen Modelle in Code wird im Kapitel zu den Codegeneratoren beschrieben. Da diese Implementierung unabhängig von der Modellierungskomponente und auf den Ergebnissen der Modellierung aufsetzt, wird sie in einem separaten Kapitel mit Fokus auf Codegeneratoren erläutert (vgl. hierzu den Beitrag Vom Prozess zur Ausführung – Modellgestützte Entwicklung betriebswirtschaftlicher Software von JULIA WAGNER, THOMAS ANDRES und YVES LAUER). Das Konzept zum Referenzmodellcontrolling wird im Beitrag Controlling konfigurativer Referenzmodelle von CHRISTIAN SEEL und PETER LOOS dargestellt und einer beispielhaften Anwendung unterzogen. Die notwendigen Erweiterungen des Modellierungswerkzeugs werden fachkonzeptionell beschrieben und anhand von konkreten Anwendungsbeispielen erläutert. Die Validierung der entwickelten Konzepte zur konfigurativen Referenzmodellierung wird im Anschluss anhand eines konkreten Praxisbeispiels durchgeführt. Dabei dient ein Handelsreferenzmodell [BeSc04] als Grundlage, das bereits als Hilfe für die Softwareentwicklung eines KMSU, das als Projektpartner auftritt, eingesetzt wird (vgl. hierzu den Beitrag Entwicklung konfigurativer Referenzmodelle für Warenwirtschaftssysteme

8


mit adapt(x) von MICHAEL EISENBARTH und CLAUS KÖDEL in diesem Band).

4

Projektergebnis

Nach Abschluss des Projekts RefMod06 steht ein Referenzmodellierungswerkzeug zur Verfügung, dass es auch KMSU erlaubt, das in Referenzmodellen enthaltene Wissen für die frühen Phasen der Softwareentwicklung zu nutzen.

Referenzmodellanwender (KMSU)

Referenzmodellersteller

Marktbearbeitung

Formulierung

Pflege, Adaption, Entwicklung

Konfiguratives Referenzmodell

Konfiguration

Tool, Referenzmodellrepository

Markt Kunde Generierung

Monitoring & Feedback

Anforderungen des Marktes

Software

Abbildung 4: Softwareentwicklungs- und Wartungsprozess bei Einsatz des Referenzmodellierungswerkzeugs

Durch effizient gestaltete Konfigurationsmechanismen sind die KMSU in der Lage, aus allgemeinen Modellen spezielle abzuleiten und diese auch kontinuierlich weiterzuentwickeln, dabei ferner eigene Varianten zu formulieren sowie zu verwalten. Die kontinuierliche Weiterentwicklung der Modelle wird durch in den Modellen selbst enthaltene Controllingkonzepte unterstützt, die es erlauben, auf kurzfristige Anforderungen der Softwarekunden zu reagieren und ausgehend von den Ausprägungen der Controllingkennzahlen Anpassungen der Referenzmodelle vorzunehmen, wobei dies wiederum durch die Konfigurationsmechanismen unterstützt wird. Um den Prozess von der Fachkonzepterstellung bis hin zur Implementierung der Software zu beschleunigen, stehen weiterhin Codegeneratoren zur


9

Verfügung. Die Zusammenhänge der Referenzmodellnutzung und der beteiligten Marktpartner sind in Abbildung 4 dargestellt.

Literaturverzeichnis [Balz98] Balzert, H.: Lehrbuch der Softwaretechnik. Software-Management, Software-Qualitätssicherung, Unternehmensmodellierung. Heidelberg et al. 1998. [BDKK02] Becker, J.; Delfmann, P.; Knackstedt, R.; Kuropka, D.: Konfigurative Referenzmodellierung. In: Becker, J.; Knackstedt, R. (Hrsg.): Wissensmanagement mit Referenzmodellen. Konzepte für die Anwendungssystem- und Organisationsgestaltung. Heidelberg 2002, S. 25-144. [BeDK04] Becker, J.; Delfmann, P.; Knackstedt, R.: Konstruktion von Referenzmodellierungssprachen. Ein Ordnungsrahmen zur Spezifikation von Adaptionsmechanismen für Informationsmodelle. Wirtschaftsinformatik 46 (2004) 4, S. 251-264. [BeSc04] Becker, J.; Schütte, R.: Handelsinformationssysteme. 2. Auflage, Frankfurt am Main 2004. [BKKD03] Becker, J.; Knackstedt, R.; Kuropka, D.; Delfmann, P.: Konfiguration fachkonzeptioneller Referenzmodelle. In: Uhr, W.; Esswein, W.; Schoop, E. (Hrsg.): Wirtschaftsinformatik 2003, Band II. Medien – Märkte – Mobilität. Heidelberg 2003, S. 901-920. [DeKn07] Delfmann, P.; Knackstedt, R.: Konfiguration von Informationsmodellen. Untersuchungen zu Bedarf und Werkzeugunterstützung. In: Oberweis, A.; Weinhardt, C.; Gimpel, H.; Koschmider, A.; Pankratius, V.; Schnizler, B. (Hrsg.): eOrganisation: Service-, Prozess-, Market-Engineering. Proceedings der 8. Internationalen Tagung Wirtschaftsinformatik. Band 2. Karlsruhe 2007, S. 127-144. [OMG03] Object Management Group: MDA Guide Version 1.0.1. 2003. http:// www.omg.org/docs/omg/03-06-01.pdf [RoAa07] Rosemann, M.; van der Aalst, W. M. P.: A Configurable Reference Modelling Language. Information Systems 23 (2007) 1, S. 1-23. [Silv01] Silverston, L.: The Data Model Resource Book, Volume 2. A Library of Data Models for Specific Industries. 2001.

Fachkonzept eines konfigurativen Referenzmodellierungswerkzeugs

Patrick Delfmann, Armin Stein Abstract: Die konfigurative Referenzmodellierung stellt ein probates Mittel zur Verwaltung von Varianten konzeptioneller Softwaremodelle dar. Eine adäquate Unterstützung der Softwareentwicklung durch die konfigurative Referenzmodellierung kann jedoch nur dann gewährleistet werden, wenn ein entsprechendes Modellierungswerkzeug zur Verfügung steht. Die konzeptionellen Grundlagen der konfigurativen Referenzmodellierung werden in diesem Beitrag eingeführt und auf das konkrete Problem einer Werkzeugimplementierung übertragen. Es wird ein Fachkonzept in Form eines Datenmodells vorgestellt, das den Ausgangspunkt für die Implementierung eines konfigurativen Referenzmodellierungswerkzeugs darstellt. Instanzen der einzelnen Elemente des Datenmodells repräsentieren hierbei den Inhalt der durch das Modellierungswerkzeug zu verwaltenden Modelle und Modellvarianten.

1

Wiederverwendungsansätze für Informationsmodelle

Die Effektivität und Effizienz der fachkonzeptionellen Modellierung kann erhöht werden, indem bestehende Modelle als Ausgangslösung für die Entwicklung spezifischer Modelle – z. B. kundenspezifischer Softwaremodelle – genutzt werden [Schü98, S. 367ff.]. In einer entsprechenden Modellbeziehung werden als Ausgangslösung dienende Modelle als Referenzmodelle bezeichnet. Für die Ableitung spezifischer Modelle eignen sich unterschiedliche Ansätze zur Wiederverwendung fachkonzeptioneller Modelle [Broc03, S. 259ff.], die auch kombiniert eingesetzt werden können. In vielen Fällen ist eine Anpassung des Referenzmodells durch freie Modifikation seiner Modellteile vorgesehen [Krus96; Sche97; Kurb03; Hamm97; Hars94; Rohl95; BeSc04]. Der Detaillierungsgrad des Referenzmodells wird in diesem Fall bewusst eingeschränkt. Ist das Referenzmodell in Komponenten zerlegt, können diese Komponenten im Rahmen der

12

Patrick Delfmann, Armin Stein

Aggregation [Lang97; Remm97; Hamm99; HaPS99; Schu01] zu neuen Lösungen zusammengesetzt werden. Die Kombinierbarkeit kann dabei durch Schnittstellendefinitionen eingeschränkt werden. Die Instanziierung eines Referenzmodells [Schü98; Schw99; Schu01; Wolf01] sieht dagegen vor, dass Platzhalter durch zulässige Ausprägungen ihres Wertebereichs gefüllt werden, wodurch die Anpassung des Modell explizit beschränkt wird. Konfigurierbare Referenzmodelle enthalten Regeln, die determinieren, wie die Modelle in Abhängigkeit anwendungskontextspezifisch gewählter Ausprägungen von Parametern – so genannten Konfigurationsparametern – zu verändern sind [BDKK02; BDDK03; BeDK04; Delf06; Knac06; DeKn07]. Bei der Konfiguration werden entsprechend den Konfigurationsregeln aus einem Gesamtmodell, das aus mehreren spezifischen Modellvarianten besteht, einzelne spezifische Modelle abgeleitet. Der Konfigurationsprozess entspricht damit einer Projektion des Ursprungsmodells, die eine reduzierte Version des Ursprungsmodells zum Ergebnis hat. Anwendungskontextspezifisch (z. B. kundenspezifisch) nicht relevante Modellbestandteile werden ausgeblendet. Die Konfiguration eignet sich in besonderem Maße für die Formulierung von konkreten Gestaltungsempfehlungen und für die Anpassung des Referenzmodells an vorausgeplante Anwendungskontexte. Damit ist sie insbesondere für die Veraltung von Modellvarianten im Rahmen der Softwareentwicklung geeignet, da die Modellvarianten Softwareanforderungen von Kunden repräsentieren, welche im Vorfeld bekannt sein sollten (vgl. auch den einführenden Beitrag von JÖRG BECKER, PATRICK DELFMANN und TOBIAS RIEKE in diesem Band). Die übrigen Wiederverwendungsansätze zeichnen sich gegenüber der Konfiguration dadurch aus, dass die Vorwegnahme der im Rahmen der Referenzmodellanwendung notwendig werdenden Modellanpassungen geringer ausfällt. Anwendern der übrigen Wiederverwendungsansätze werden damit größere kreative Gestaltungsfreiräume bei der Anpassung von Modellen eingeräumt, weswegen sich diese Ansätze insbesondere für Feinanpassungen eignen, die sich bspw. an eine Konfiguration anschließen.

2

Grundlagen der konfigurativen Referenzmodellierung

2.1 Konfigurationsparameter Die Ursachen für die Konstruktion von Softwaremodellvarianten, die mithilfe der konfigurativen Referenzmodellierung verwaltet werden sollen,


13

bilden abweichende Anforderungen unterschiedlicher Nutzergruppen. Diese Anforderungen können einerseits aus unterschiedlichen betriebswirtschaftlichen Merkmalen der Unternehmen, die die Software nutzen, resultieren. Andererseits können persönliche Präferenzen hinsichtlich der Gestaltung der Software dazu führen, dass unterschiedliche Anforderungen an eine Software formuliert werden. Die unterschiedlichen Anforderungstypen dienen der Konfiguration als Konfigurationsparameter und werden in Unternehmensmerkmale und Perspektiven gegliedert [BDKK02, S. 38]: • Unternehmensmerkmale und ihre Ausprägungen beschreiben die Klasse von Unternehmen, für die eine Anpassung des Referenzmodells durchgeführt werden soll. Beispiele für Unternehmensmerkmale in der Handelsdomäne sind Geschäftsart oder Wirtschaftsstufe [BeSc04, S. 2]. Exemplarische Ausprägungen der Geschäftsart sind Lager-, Strecken- und Zentralregulierungsgeschäft. In der Industriedomäne werden derartige Unterscheidungen bspw. durch Betriebstypologien [MeLo00, S. 116ff.; LoHM02, S. 279ff.; Kurb03, S. 32ff.] vorgenommen. • Perspektiven werden vorrangig durch den verfolgten Modellierungszweck, z. B. Anwendungssystem- oder Organisationsgestaltung, die Rolle der Anwender im Projekt, z. B. Methodenexperte oder Anwender, und sonstige Einflüsse wie z. B. layouttechnische Präferenzen von Modellanwendern determiniert [BDKK02, S. 28ff.; RoSD05, S. 50ff.].

2.2 Konfigurationsmechanismen Die Umsetzung der Konfiguration, d. h. die Anpassung der Modelle gemäß den Anforderungen, die in den Konfigurationsparametern repräsentiert sind, wird – dem Prinzip der Effizienzsteigerung folgend – durch automatisierte Konfigurationsmechanismen realisiert. Um die Anwendung der Konfigurationsmechanismen benutzerfreundlich und einfach zu gestalten, ist es vorteilhaft, Mechanismen mit unterschiedlich weitem Wirkungsgrad bereitzustellen. Es werden deshalb fünf unterschiedliche Kategorien von Konfigurationsmechanismen differenziert (vgl. im Folgenden [BDKK02, S. 72ff.]): Modelltypselektion

Werden Modelle mit der gleichen Modellierungssprache konstruiert, so gehören sie dem gleichen Modelltyp an, z. B. dem der Ereignisgesteuerten Prozessketten (EPK, vgl. [KeNS92]), der Fachbegriffsmodelle [Spie93],

14


der Entity-Relationship-Modelle (ERM, vgl. [Chen76]), oder der Organigramme (z. B. [Groc82, S. 305; Schr96, S. 125]). Der Konfigurationsmechanismus der Modelltypselektion unterstützt die Zuordnung von Modelltypen zu Konfigurationsparametern, wodurch eine Nutzergruppenabhängige Ein- und Ausblendung von Modellen bestimmter Typen ermöglicht wird. In der Softwareentwicklung ist dieses Vorgehen sinnvoll, wenn das Softwarefachkonzept aufgabenteilig erstellt wird und bspw. Datenbankentwicklern ausschließlich die Datensicht zur Verfügung stehen soll (vgl. Tabelle 1). Modelltyp

Perspektive Geschäftslogik

Perspektive Datenbank

Entity-Relationship-Modell

Organigramm

Ereignisgesteuerte Prozesskette

Tabelle 1:

Exemplarische Modelltypselektion

Elementtypselektion

Elementtypselektionen ermöglichen es, zu Modelltypen Varianten zu bilden, die sich in der Menge der verwendbaren Modellelementtypen unterscheiden. Je nach eingenommener Perspektive des Modellanwenders kann es erforderlich sein, Modelltypen mit unterschiedlicher Ausdrucksmächtigkeit bzgl. des Angebots an Elementtypen zur Verfügung zu stellen. Beispielsweise unterscheiden sich Varianten der erweiterten Ereignisgesteuerten Prozesskette in den Modellelementtypen, die an Funktionen annotiert werden können. Kandidaten für die Annotation stellen z. B. Entitytypen und Organisationseinheiten dar. Die Modelltypvarianten werden gebildet, indem ihnen Elementtypen abhängig vom Konfigurationsparameter zugeordnet werden. Im Rahmen der Softwareentwicklung unterstützen Elementtypselektionen den Entwicklungsprozess bspw. dann, wenn aus Übersichtsgründen Detailbereiche von Modellen ausgeblendet werden müssen (etwa Attributbeschreibungen in ERMs; vgl. Abbildung 1).


15

Abbildung 1: Exemplarische Elementtypselektion im ERM [Delf06, S. 102] Elementselektion

Elementselektionen äußern sich in der konfigurationsparameterabhängigen Selektion von einzelnen Modellelementen, bspw. einer einzelnen Prozessmodellfunktion „Rechnung prüfen“. Auf Basis dieser Selektion können einzelne Elemente ausgeblendet werden, die für den Anwendungskontext des aktuellen Konfigurationsparameters nicht relevant sind. Im Rahmen der Elementselektion werden zwei Konfigurationsmechanismen unterschieden:

16


Elementselektion über Konfigurationsattribute

Die Variantenbildung mithilfe der Elementselektion über Konfigurationsattribute erfolgt über die Auswertung von Eigenschaften, die den Modellelementen zugeordnet sind. Beispielsweise kann einer Funktion eines Prozessmodells ein Attribut zugeordnet werden, das diese anhand ihres Automatisierungsgrads klassifiziert.

Abbildung 2: Exemplarische Elementselektion über Konfigurationsattribute in der EPK [BDKK02, S. 111]


17

Konfigurationsparameterspezifisch kann mithilfe des Mechanismus festgelegt werden, welche Funktionen mit welchem Automatisierungsgrad angezeigt bzw. ausgeblendet werden sollen. Eine solche Klassifikation wird bspw. vorgenommen, wenn die zur Verfügung stehenden Modelle im Rahmen einer integrierten Anwendungssystem- und Organisationsgestaltung entstanden sind und anhand des Automatisierungsgrads ermittelt werden kann, ob die Modellteile sich für eine Implementierung – in diesem Fall im Rahmen der Softwareentwicklung – eignen oder nicht (vgl. Beispiel in Abbildung 2). Elementselektion über Konfigurationsterme

Die Elementselektion über Konfigurationsterme ist dadurch gekennzeichnet, dass dem zu konfigurierenden Modellelement ein boolescher Ausdruck zugewiesen wird, der die direkte Zuordnung des Elements zu einer oder mehreren Konfigurationsparameterausprägungen ermöglicht.

Abbildung 3: Exemplarische Elementselektion über Konfigurationsterme im ERM [BDKK02, S. 117; Delf06, S. 121]

18


Diese Vorgehensweise bietet sich im Software Engineering insbesondere für die Unterscheidung von Kundenvarianten an (vgl. exemplarisch Abbildung 3; hier wird ein Datenmodell angepasst, je nachdem, ob das softwarenutzende Handelsunternehmen Direktverkauf betreibt oder nicht, was sich in der Notwendigkeit widerspiegelt, einen Bezug zwischen Angebot und Auftrag herzustellen zu müssen oder nicht). Die Wirkungsweise der Selektion unterscheidet sich nicht von derjenigen der Elementselektion über Konfigurationsattribute. Abhängig von der jeweiligen Konfigurationssituation kann die Anwendung eines der beiden Konfigurationsmechanismen gegenüber dem anderen zu Effizienzsteigerungen bei der Konstruktion und Anwendung der konfigurativen Modelle führen (vgl. hierzu Abschnitt 3.2). Bezeichnungsvariation

Der Mechanismus der Bezeichnungsvariation berücksichtigt, dass es erforderlich sein kann, die Bezeichnungen von Modellelementen auszutauschen.

Abbildung 4: Exemplarische Bezeichnungsvariationen in der EPK [DeKn07]


19

Im Software Engineering kommt sie vorwiegend bei der Konstruktion von Kundenvarianten zum Einsatz, wenn sich in den Kundenunternehmen unterschiedliche Begriffskonventionen etabliert haben. So wird eine Kreditorenrechnung in unterschiedlichen Unternehmen bspw. synonym als „Kreditorenrechnung“ oder in einfacherer Form als „Rechnung“ bezeichnet (vgl. Abbildung 4). Darstellungsvariation

Die Darstellungsvariation dient dazu, abhängig von der jeweiligen Nutzergruppe der Modelle die grafischen Symbole der einzelnen Modellelemente auszutauschen [Allw98]. Im Software Engineering kann die Darstellungsvariation dazu eingesetzt werden, zum Zweck der Diskussion der Modelle mit dem Kunden diese anschaulicher zu gestalten, indem die häufig abstrakten Symbole in Informationsmodellen durch anschaulichere Bildzeichen ausgetauscht werden (vgl. Abbildung 5).

Abbildung 5: Exemplarische Darstellungsvarianten der EPK [DeKn07]

20

3


Fachkonzept des Referenzmodellierungswerkzeugs

Das Fachkonzept des konfigurativen Referenzmodellierungswerkzeugs basiert auf theoretischen Grundlagen der konfigurativen Referenzmodellierung, die in der Literatur ausführlich diskutiert worden sind [BDKK02; BKKD03; BeDK04; Delf06; DeKn07]. Im Rahmen dieser Beiträge werden Konzepte zur Konfiguration von Informationsmodellen eingeführt, die mit dem Ziel der Übertragbarkeit auf beliebige Modellierungssprachen und Implementierungsplattformen allgemeingültig formuliert werden. Darüber hinaus sind sie sprachtheoretisch ausgerichtet und werden mithilfe mehrerer sprachlicher Modellebenen spezifiziert. Diese Konzepte werden im Folgenden auf den konkreten Anwendungskontext der Implementierung als Modellierungswerkzeug übertragen. Das werkzeugbezogene Fachkonzept lehnt sich an die Architektur Integrierter Informationssysteme (ARIS [Sche97]) an, welche sich zur Beschreibung fachkonzeptioneller Inhalte durchgesetzt hat. Aus den Sichten der Architektur, Daten, Prozesse, Funktionen und Organisation, wird insbesondere die Datensicht fokussiert, da die Verwaltung von Modellinhalten sowie Konfigurationseinstellungen auf Datenebene stattfindet. Auf die umfangreiche Beschreibung von Prozesslogik, die insbesondere für Zwecke der grafischen Darstellung von Modellen auf der Modellierungsoberfläche des Werkzeugs sowie für die allgemeine Bedienung notwendig ist, wird verzichtet (vgl. hierzu auch den Beitrag von TOBIAS RIEKE und ARMIN STEIN in diesem Band). Für die Manipulation der Daten zur Realisierung von Konfigurationsmechanismen reichen deklarative Mechanismen, wie sie bspw. von einfachen Datenbankmanipulationssprachen (z. B. SQL) zur Verfügung gestellt werden, weitestgehend aus. Die fachkonzeptionellen Spezifikationen werden als erweiterte EntityRelationship-Modelle in der Notation mit (min,max)-Kardinalitäten nach SCHLAGETER und STUCKY dargestellt [ScSt83, S. 90f.]. 3.1 Grundlegende Spezifikationen Grundlage der konfigurativen Verwaltung von Informationsmodellen sind die in Abschnitt 2.1 eingeführten Konfigurationsparameter mit ihren jeweiligen Ausprägungen, die determinieren, ob Modellinhalte für entsprechende Nutzergruppen relevant sind oder nicht (vgl. Abbildung 1). Ein Beispiel für eine Kombination aus Konfigurationsparameter und Konfigurationsparameterausprägung ist die Zuordnung „Geschäftsart=Lagergeschäft“, wobei der Konfigurationsparameter durch die Geschäftsart und die Konfigurationsparameterausprägung durch das Lagergeschäft beschrie-


21

ben wird. Ein weiteres Beispiel für solch eine Kombination ist die Aussage „Rolle=Manager“. Im ersten Fall ist der Konfigurationsparameter als Unternehmensmerkmal und seine Konfigurationsparameterausprägung als Unternehmensmerkmalsausprägung spezialisiert. Im zweiten Fall wird eine Perspektive mit einer Perspektivenausprägung in Beziehung gesetzt. Weitere Beispiele für Unternehmensmerkmale, Unternehmensmerkmalsausprägungen, Perspektiven und Perspektivenausprägungen finden sich in Abbildung 6 sowie in Abschnitt 2.1.

Abbildung 6: Konfigurationsparameter

Weitere grundlegende Spezifikationen des Modellierungswerkzeugs sind bezüglich der Verwaltung der allgemeinen Modelldaten vorzunehmen, d. h. es ist darzustellen, wie Modelle, Modellierungssprachen und Modellelemente zusammenhängen (vgl. Abbildung 7). Jedes Modell, das mit dem Modellierungswerkzeug verwaltet wird, gehört eindeutig zu einem Modellsystem. In Modellsystemen können mehrere Modelle enthalten sein, die auch in unterschiedlichen Modellierungssprachen verfasst sein (bspw. als EPK oder als ERM), also unterschiedlichen Modelltypen angehören können. Innerhalb eines Modellsystems werden die enthaltenen Modelle – dem Grundsatz der Architektur Integrierter Informationssysteme folgend – miteinander verknüpft (bspw. wenn ein Prozess, der durch ein Prozessmodell repräsentiert wird, auf Daten, die durch Datenmodelle repräsentiert werden, zugreift). Die Verknüpfung wird über die Modellelemente realisiert (bspw. konkrete Entitytypen, Funktionen oder Ereignisse), deren Elementdefinition eindeutig im Modellsystem angelegt wird. Diese Elementdefinitionen lassen sich in verschiedenen Modellen als Elementausprägungen wiederverwenden. Wird bspw. in einem Datenmodell in ERM-Notation ein Entitytyp „Auftrag“ definiert, so werden eine Elementdefinition und

22


eine entsprechende Elementausprägung für das Datenmodell angelegt. Soll dieser „Auftrag“ in einem Prozessmodell wiederverwendet werden – etwa als Input für eine Prozessfunktion – so wird für das Prozessmodell eine weitere Elementausprägung angelegt, die auf die bereits bestehende Elementdefinition verweist. Auf diese Weise ist sichergestellt, dass das wiederverwendete Modellelement semantisch demjenigen im Ursprungsmodell entspricht. Es ist eine echte Verknüpfung hergestellt.

Abbildung 7: Grundlegendes Datenmodell des Modellierungswerkzeugs

Modellelemente bzw. Elementdefinitionen gehören eindeutig einem Elementtyp an, der wiederum einem oder mehreren Modelltypen zugeordnet sein kann. Beispiele Für Elementtypen sind „Funktion“, „Ereignis“ oder „Entitytyp“, während Beispiele für Elementdefinitionen sowie Elementausprägungen „Funktion: Rechnung prüfen“ oder „Entitytyp: Lieferant“ sind. Modellelemente werden in Modellen mit Kanten in Beziehung gesetzt. Bspw. wird die zeitlich-sachlogische Abfolge von Funktionen innerhalb eines Prozessmodells durch gerichtete Kontrollflusskanten von Aktivität zu Aktivität repräsentiert. Analog zu Elementdefinitionen und -ausprägungen werden auch bei Kanten Kantendefinitionen und -ausprägungen unterschieden. Die Kardinalität (2,2) stellt sicher, dass eine Kante stets mit genau zwei Modellelementen verbunden sein muss. Ebenso gehören Kantendefinitionen jeweils genau einem Kantentyp an, der festlegt, zwischen Elementen welcher Elementtypen die Kante gezogen werden darf.


23

3.2 Konfigurationsmechanismen Die grundlegenden Spezifikationen, die die Modelldatenbasis darstellen, werden zur Realisierung der Konfigurationsmechanismen mit den Spezifikationen der Konfigurationsparameter verknüpft. Um Modellinhalte abhängig von Konfigurationsparametern darstellen zu können, werden die Konfigurationsparameter und deren Ausprägungen im Datenmodell mit den Elementen der Modelldatenbasis in Beziehung gesetzt. Das Modellierungswerkzeug kann dann zur Darstellung der Modellinhalte auf eben diese Beziehungen zugreifen. Modelltypselektion und Elementtypselektion

Zur Realisierung der Modelltypselektion werden im Datenmodell Modelltypen mit der Kombination von Konfigurationsparametern und Konfigurationsparameterausprägungen (KP-KPA-Zuordnung) verknüpft (vgl. Abbildung 8; bereits eingeführte Elementtypen werden im Folgenden grau schattiert; die Konfigurationsparameterstruktur wird aufgrund ihrer zentralen Bedeutung für die Konfiguration schwarz hervorgehoben). Im entsprechenden Relationshiptyp werden zulässige Modelltypen für die jeweilige Konfigurationsparameterausprägung vermerkt. Ist ein Modelltyp nicht vermerkt, so werden alle Modelle, die diesem Modelltyp angehören, für die entsprechende Konfigurationsparameterausprägung ausgeblendet.

Abbildung 8: Modelltypselektion und Elementtypselektion

Elementtypselektionen werden analog realisiert. Um Elementtypselektionen pro Modelltyp realisieren zu können, wird die Zuordnung zur KPKPA-Zuordnung nicht über den Elementtyp selbst, sondern über seine Beziehung zum jeweiligen Modelltyp vorgenommen (ET-MT-Zuordnung). So ist es möglich, Elementtypen aus einem Modelltyp zu entfernen, während sie für einen anderen Modelltyp weiterhin zur Verfügung stehen.

24


Modell- und Elementselektion – Überblick

Wie bereits in Abschnitt 2.2 angedeutet werden Elementselektionen mit zwei unterschiedlichen Formen von Konfigurationsmechanismen umgesetzt. Zur Annotation von Konfigurationseinstellungen an Modellelemente werden spezielle Platzhalter eingeführt, die Konfigurationsattribute und Konfigurationsterme repräsentieren und als Konfigurationsannotationen diese beiden Konfigurationseinstellungsformen zusammenfassen. Um sowohl Modellelementen als auch ganzen Modellen Konfigurationseinstellungen annotieren zu können, wird die Konfigurationsannotation sowohl dem Modell als auch der Elementausprägung zugewiesen (vgl. hierzu und im Folgenden Abbildung 9). Modell- und Elementselektion über Konfigurationsattribute

Die Spezialisierung Konfigurationsattribut der Konfigurationsannotation setzt sich aus einem Attribut sowie seiner Ausprägung zusammen. Ein Beispiel für ein konkretes Attribut ist der „Automatisierungsgrad“, der bspw. eine Funktion in einem Prozessmodell charakterisiert. Eine korrespondierende exemplarische Attributausprägung ist „vollautomatisch“. Das entsprechende Konfigurationsattribut ist „Automatisierungsgrad=vollautomatisch“, das sich aus Attribut und Ausprägung zusammensetzt. Durch die Zuweisung solcher Konfigurationsattribute lassen sich Modellelemente in Kategorien einordnen, auf deren Grundlage eine Konfiguration vorgenommen werden kann. Die Konstruktion von Modell- und Modellelementkategorien lässt sich anhand von einzelnen Konfigurationsattributen und darüber hinaus anhand von logisch verknüpften Mengen von Konfigurationsattributen vornehmen. Deshalb werden sowohl einzelne als auch zusammengesetzte Konfigurationsattribute unter dem Begriff Konfigurationsregeln zusammengefasst. Eine Konfigurationsregel, die sich aus logisch verknüpften, mehreren Konfigurationsattributen zusammensetzt, wird als komplexe Konfigurationsregel spezialisiert. Eine komplexe Konfigurationsregel enthält stets genau wiederum zwei Konfigurationsregeln, die über einen logischen Operator (AND bzw. OR) verknüpft sind. Sollen mehr als zwei Konfigurationsregeln verknüpft werden, so lassen sich über die Generalisierung der komplexen Konfigurationsregel zur Konfigurationsregel verschachtelte logische Ausdrücke von Konfigurationsattributen aufbauen. Zusätzlich kann einer Konfigurationsregel ein Operator direkt zugewiesen werden – nämlich genau dann, wenn die Konfigurationsregel durch einen NOT-Operator negiert werden soll (vgl. negierte Konfigurationsregel). Negierte Konfigurationsregeln können analog zu komplexen Konfigurationsregeln über die Gene-


25

ralisierung zur Konfigurationsregel verschachtelt werden. Ein Beispiel für eine negierte Konfigurationsregel, die eine komplexe Konfigurationsregel enthält, ist die folgende: NOT (Automatisierungsgrad=vollautomatisch AND Detailelement=TRUE) Sie drückt aus, dass nur die Modelle bzw. Modellelemente angezeigt werden sollen, die nicht der Kombination aus den Eigenschaften „vollautomatisch“ und „Detailelement“ entsprechen – d. h., die entweder nicht vollautomatisiert sind oder nicht die Eigenschaft eines Detailelements besitzen oder weder vollautomatisiert sind noch Detailinformationen vermitteln. Ob eine Konfigurationsregel angewendet wird, ist abhängig von der jeweiligen Nutzergruppe, die auf die Modelle zugreift. Deshalb werden Konfigurationsregeln mit der KP-KPA-Zuordnung in Beziehung gesetzt.

Abbildung 9: Element- und Modellselektion über Konfigurationsattribute

Ein Konfigurationsprozess, der durch die Elementselektion über Konfigurationsattribute umgesetzt wird, läuft damit wie folgt ab: • Anhand der ausgewählten Konfigurationsparameterausprägung wird ermittelt, welche Konfigurationsregeln auszuführen sind. • Die Konfigurationsregeln werden mit den Konfigurationsattributen verglichen, die den Modellen und Modellelementen annotiert sind. • Entsprechen die Konfigurationsattribute an den Modellen oder Modellelementen den Konfigurationsregeln, so werden die Modelle oder Modellelemente angezeigt. Anderenfalls werden sie ausgeblendet. Im Bei-

26


spielfall würde etwa ein Modellelement, das das Konfigurationsattribut „Automatisierungsgrad=manuell“ trägt, angezeigt. Modell- und Elementselektion über Konfigurationsterme

Die Elementselektion über Konfigurationsterme ist gegenüber der Elementselektion über Konfigurationsattribute dadurch charakterisiert, dass hier Modelle und Modellelemente direkt mit Konfigurationsparameterausprägungen in Beziehung gesetzt werden, anstatt sie zunächst durch die Vergabe von Eigenschaften in Kategorien einzuteilen. Die Konfigurationsterme, die den Modellen oder Modellelementausprägungen annotiert werden können, enthalten direkt die Informationen, die sie als relevant für Konfigurationsparameterausprägungen kennzeichnen (vgl. hierzu und im Folgenden Abbildung 10). Da Modelle und Modellelemente auch für mehrere Konfigurationsparameterausprägungen relevant sein können, ist auch hier – analog zu den Konfigurationsattributen – eine Kombination durch logische Verknüpfung verschiedener Konfigurationsterme möglich. Konfigurationsterme werden deshalb spezialisiert in einfache Konfigurationsterme, die der KP-KPA-Zuordnung entsprechen sowie in komplexe Konfigurationsterme, die durch logische Operatoren (AND bzw. OR) verknüpfte Mengen von KP-KPA-Zuordnungen darstellen. Konfigurationsparameter (1,n)

Konfigurations(1,1) parameterausprägung

Elementausprägung

(0,n)

(0,n)

(1,1)

Konfigurationsannotation

KP-KPAZuordnung

Konfigurationsattribut

D,T

Operator

(0,n)

(0,n)

(0,n) (0,n)

Modell

(0,n)

Konfigurationsterm

D,T

Negierter Konfigurationsterm

(0,n) (0,1)

Komplexer Konfigurationsterm

Abbildung 10: Element- und Modellselektion über Konfigurationsterme

(0,n)


27

Sollen mehr als zwei Konfigurationsterme verknüpft werden, so lassen sich über die Generalisierung vom komplexen Konfigurationsterm zum Konfigurationsterm verschachtelte logische Ausdrücke von Konfigurationstermen aufbauen. Zusätzlich kann einem Konfigurationsterm ein Operator direkt zugewiesen werden – nämlich genau dann, wenn der Term durch einen NOT-Operator negiert werden soll (vgl. negierten Konfigurationsterm). Negierte Konfigurationsterme können analog zu komplexen Konfigurationstermen über die Generalisierung zum Konfigurationsterm verschachtelt werden. Ein Beispiel für einen komplexen Konfigurationsterm, der wiederum mehrere komplexe Konfigurationsterme enthält, ist der folgende: (Geschäftsart (Lager) AND Geschäftsart (Strecke)) OR (Geschäftsart (Lager) AND Geschäftsart (Strecke) AND Geschäftsart (Zentralregulierung)) Er drückt aus, dass das Modellelement, dem dieser Term zugewiesen ist, nur dann angezeigt wird, wenn das Referenzmodell für ein Unternehmen konfiguriert wird, das entweder die Geschäftsarten Lager und Strecke gleichzeitig praktiziert, oder aber alle drei Geschäftsarten. Ein Konfigurationsprozess, der durch die Elementselektion über Konfigurationsterme umgesetzt wird, läuft wie folgt ab: • Die ausgewählte Konfigurationsparameterausprägung wird mit den Konfigurationstermen sämtlicher Modelle und Modellelemente verglichen. • Erfüllt die Konfigurationsparameterausprägung den Konfigurationsterm, so wird das Element bzw. das Modell angezeigt. Anderenfalls wird es ausgeblendet. Vergleich der Modell- und Elementselektion über Konfigurationsattribute sowie über Konfigurationsterme

Trotz ihrer Äquivalenz wird keiner der beiden Konfigurationsmechanismen als redundant eingestuft. Vielmehr sind die Mechanismen für unterschiedliche Anwendungsszenarien relevant. Die Elementselektion über Konfigurationsterme eignet sich für die Konfiguration von einzelnen Modellelementen, für die keine spezielle Eigenschaft als Konfigurationsgrundlage mit Ausnahme der expliziten Zugehörigkeit zu einem konkreten Anwendungskontext identifiziert werden kann. Umgekehrt eignet sich die Elementselektion über Konfigurationsattribute für modellübergreifende Gruppen von Elementen, die gemeinsame identifizierende Eigenschaften aufweisen.

28


Die Benutzerführung bei der Anwendung der Konfigurationsmechanismen würde durch Kappung eines der beiden Konfigurationsmechanismen erschwert. Bei der exklusiven Unterstützung der Elementselektion über Konfigurationsattribute wäre zur Substitution der Elementselektion über Konfigurationsterme eine sehr umfassende Liste von konfigurationsbezogenen Attributen pro Modellelement bereitzustellen. Umgekehrt wäre bei exklusiv vorhandener Elementselektion über Konfigurationsterme bei jedem Modellelement explizit als Term anzugeben, für welche Konfigurationsparameterausprägungen es zur Verfügung steht. Beim Anlegen neuer Konfigurationsparameter wäre jedes Mal eine Überarbeitung sämtlicher Terme notwendig. Ferner wäre der Bezug zu der Eigenschaft, die die konfigurationsabhängige Selektion auslöst, nicht mehr erkennbar, weswegen vom Modellersteller und -anwender zusätzliche Transferleistungen zu erbringen wären. Die Bereitstellung beider Konfigurationsmechanismen begründet sich folglich in der Steigerung der Effizienz seitens des Modellerstellers bei der Entwicklung des konfigurativen Modells. Bezeichnungsvariation und Darstellungsvariation

Die Bezeichnungsvariation wird realisiert, indem Elementdefinitionen abhängig von der aktuellen Konfigurationsparameterausprägung ihre Bezeichner zugeordnet werden (vgl. hierzu und zur Darstellungsvariation Abbildung 11). Auf diese Weise ändert sich die Bezeichnung des jeweiligen Modellelements entsprechend.

Abbildung 11: Bezeichnungs- und Darstellungsvariation

Für die Realisierung der Darstellungsvariation werden Elementtypen abhängig von der aktuellen Konfigurationsparameterausprägung und abhängig von dem Modelltyp, dem sie zugewiesen sind, unterschiedliche Sym-


29

bole zugeordnet. Diese Beziehung wird durch den Relationshiptyp Darstellung hergestellt. Die Unterscheidung der zugeordneten Modelltypen ist notwendig, da Elementtypen bei gleicher Konfigurationsparameterausprägung in unterschiedlichen Modelltypen unterschiedliche Symbole haben können. Die in den Abbildungen 6-11 dargestellten Datenmodelle sind Teil eines integrierten Gesamtdatenmodells, das nochmals in Abbildung 12 zusammengefasst ist. Das Gesamtdatenmodell repräsentiert hiermit die Gesamtdatenbasis des konfigurativen Modellierungswerkzeugs. (1,1)

(0,n) (0,n)

Kantendefinition

(0,n)

(1,1)

Kantenausprägung

(2,2)

(2,2)

(0,n)

(0,n)

Elementdefinition

(0,n)

(1,1)

Elementausprägung

(1,1)

(1,1)

(0,n)

(0,n)

Attributausprägung

Kantentyp

(1,1)

Konfigurationsattribut

(1,n)

Attribut

(2,2)

(0,n)

(0,n)

Konfigurationsannotation

Komplexe Konfigurationsregel

D,T

(0,n) (0,n)

Modellsystem

(0,n)

(1,1)

Modell

Symbol D,T

(0,n)

Konfigurationsregel

(0,n)

(1,1) (0,1) (0,n)

(1,1)

Darstellung (0,n)

(0,n) (1,n)

(0,n)

Bezeichnung

Modelltyp

(1,n)

(1,n)

Negierte Konfigurationsregel

Elementtyp

(0,n) (0,n)

KP-KPAZuordnung

(0,n) (0,n) (0,n) (0,n)

(0,1)

D,T

(1,1)

(0,n)

Konfigurationsterm

Konfigurationsparameterausprägung (1,n)

(0,n) (0,n)

Negierter Konfigurationsterm

Komplexer Konfigurationsterm

Konfigurationsparameter

(0,n)

Operator

(0,n)

(0,n)

Abbildung 12: Gesamtdatenmodell

4

Implementierungsaspekte

Die Konfigurationsunterstützung vorhandener Werkzeuge ist zum momentanen Zeitpunkt nur bedingt gegeben. Werkzeuge mit umfangreicher Skriptsprachenfunktionalität wie ConceptBase oder Cubetto stellen viel versprechende Plattformen dar, die für den Zweck der Konfiguration erweitert werden können. Hierbei ist allerdings die Frage zu stellen, ob sich solche Werkzeuge, die sich gegen etablierte, kommerzielle Werkzeuge wie

30


bspw. ARIS behaupten müssen, durchsetzen können. Die Ergebnisse einer empirischen Studie [DeKn07] zeigen, dass sich der Bekanntheits- und damit Verbreitungsgrad solcher Werkzeuge in Grenzen hält, was diese Vermutung untermauert. Grundsätzlich vielversprechend erscheint ebenfalls der Ansatz, ein Modellierungswerkzeug auf Basis eines weit verbreiteten Zeichenprogramms zu entwickeln, wie er von Semtalk verfolgt wird. Hier fehlt allerdings die Möglichkeit der Spezifikation von Konfigurationsfunktionalität (vgl. nochmals [DeKn07]). Ausgehend von diesen Überlegungen wird auf der Basis des Fachkonzepts zur Konfiguration von Informationsmodellen ein Aufsatz für das am weitesten verbreitete Werkzeug entwickelt. Der Konfigurationsaufsatz adapt(x) wird für das Modellierungswerkzeug ARIS entwickelt, der in der zum momentanen Zeitpunkt vorhandenen Version die vorgestellten Konfigurationsmechanismen unterstützt (vgl. zu einer ausführlichen Beschreibung dieses Werkzeugs die Beiträge von TOBIAS RIEKE und ARMIN STEIN sowie von PATRICK DELFMANN, TOBIAS RIEKE und ARMIN STEIN in diesem Band).

5

Ausblick

Mit dem Ziel, Softwareentwicklern eine möglichst umfassende methodische Unterstützung für die Verwaltung von Softwaremodellvarianten bzw. für die Anpassung von Softwaremodellen zu geben, bietet sich neben der Konfiguration die zusätzliche Berücksichtigung der in Abschnitt 1 bereits erwähnten übrigen Wiederverwendungsansätze an. Um eine möglichst einfache Verwendung der unterschiedlichen Ansätze zu gewährleisten, sind diese in einer gemeinsamen Modellierungstechnik zu integrieren. Das Fachkonzept des konfigurativen Referenzmodellierungswerkzeugs ist auf Basis dieser Technik zu erweitern. Ansätze zur Integration konfigurativer und anderer Wiederverwendungsansätze, die sich für die Erweiterung des hier vorgestellten Fachkonzepts eignen, finden sich insbesondere bei [BeDK04; Delf06].

Literaturverzeichnis [Allw98] Allweyer, T.: Modellbasiertes Wissensmanagement. Information Management & Consulting 13 (1998) 1, S. 37-45.


31

[BDKK02] Becker, J.; Delfmann, P.; Knackstedt, K.; Kuropka, K.: Konfigurative Referenzmodellierung. In: Becker, J.; Knackstedt, R. (Hrsg.): Wissensmanagement mit Referenzmodellen. Konzepte für die Anwendungssystem- und Organisationsgestaltung. Heidelberg 2002, S. 25-144. [BeDK04] Becker, J.; Delfmann, P.; Knackstedt, R.: Konstruktion von Referenzmodellierungssprachen. Ein Ordnungsrahmen zur Spezifikation von Adaptionsmechanismen für Informationsmodelle. Wirtschaftsinformatik 46 (2004) 4, S. 251-264. [BeSc04] Becker, J.; Schütte, R.: Handelsinformationssysteme. 2. Auflage, Frankfurt am Main 2004. [BKKD03] Becker, J.; Knackstedt, R.; Kuropka, D.; Delfmann, P.: Konfiguration fachkonzeptioneller Referenzmodelle. In: Uhr, W.; Esswein, W.; Schoop, E. (Hrsg.): Wirtschaftsinformatik 2003, Band II. Medien – Märkte – Mobilität. Heidelberg 2003, S. 901-920. [Broc03] vom Brocke, J.: Referenzmodellierung. Gestaltung und Verteilung von Konstruktionsprozessen. Berlin 2003. [Chen76] Chen, P. P.-S.: The Entity-Relationship Model. Toward a Unified View of Data. ACM Transactions on Database-Systems 1 (1976) 1, S. 9-36. [DeKn07] Delfmann, P.; Knackstedt, R.: Konfiguration von Informationsmodellen. Untersuchungen zu Bedarf und Werkzeugunterstützung. In: Oberweis, A.; Weinhardt, C.; Gimpel, H.; Koschmider, A.; Pankratius, V.; Schnizler, B. (Hrsg.): eOrganisation: Service-, Prozess-, Market-Engineering. Proceedings der 8. Internationalen Tagung Wirtschaftsinformatik. Band 2. Karlsruhe 2007, S. 127-144. [Delf06] Delfmann, P.: Adaptive Referenzmodellierung. Methodische Konzepte zur Konstruktion und Anwendung wiederverwendungsorientierter Informationsmodelle. Berlin 2006. [Groc82] Grochla, E.: Grundlagen der organisatorischen Gestaltung. Stuttgart 1982. [Hamm97] Hamm, V.: Informationstechnikbasierte Referenzprozesse. Prozessorientierte Gestaltung des industriellen Einkaufs. Wiesbaden 1997. [Hamm99] Hammel, C.: Generische Spezifikation betrieblicher Anwendungssysteme. Aachen 1999. [HaPS99] Han, T.-D.; Purao, S.; Storey, V. C.: A Methodology for Building a Repository of Object-Oriented Design Fragments. In: Akoka, J.; Bouzeghoub, M.; Comyn-Wattiau, I.; Métais, E. (Hrsg.): Conceptual Modeling – ER '99 – 18th International Conference on Conceptual Modeling, Paris, France, November 15-18, 1999 Proceedings. Berlin et al. 1999, S. 203-217. [Hars94] Hars, A.: Referenzdatenmodelle. Grundlagen effizienter Datenmodellierung. Wiesbaden 1994. [KeNS92] Keller, G.; Nüttgens, M.; Scheer, A.-W.: Semantische Prozeßmodellierung auf der Grundlage „Ereignisgesteuerter Prozeßketten (EPK)“. In: Scheer, A.-W. (Hrsg.): Veröffentlichungen des Instituts für Wirtschaftsinformatik, Heft 89. Saarbrücken 1992.

32


[Knac06] Knackstedt, R.: Fachkonzeptionelle Referenzmodellierung einer Managementunterstützung mit quantitativen und qualitativen Daten. Methodische Konzepte zur Konstruktion und Anwendung. Berlin 2006. [Krus96] Kruse, C.: Referenzmodellgestütztes Geschäftsprozessmanagement. Ein Ansatz zur prozessorientierten Gestaltung vertriebslogistischer Systeme. Wiesbaden 1996. [Kurb03] Kurbel, K.: Produktionsplanung und -steuerung: methodische Grundlagen von PPS-Systemen und Erweiterungen. 5. Auflage, München et al. 2003. [Lan97] Lang, K.: Gestaltung von Geschäftsprozessen mit Referenzprozeßbausteinen. Wiesbaden 1997. [LoHM02] Lohmann, M.; Hau, M.; Mertens, P.: Anforderungsanalyse auf der Basis von Unternehmensmerkmalen. In: Becker, J.; Knackstedt, R. (Hrsg.): Wissensmanagement mit Referenzmodellen. Heidelberg 2002, S. 279-289. [MeLo00] Mertens, P.; Lohmann, M.: Branche oder Betriebstyp als Klassifikationskriterien für die Standardsoftware der Zukunft? Erste Überlegungen, wie künftig betriebswirtschaftliche Standardsoftware entstehen könnte. In: Bodendorf, F.; Grauer, M. (Hrsg.): Verbundtagung Wirtschaftsinformatik 2000. Aachen 2000, S. 110 135. [Remm97] Remme, M.: Konstruktion von Geschäftsprozessen. Ein modellgestützter Ansatz durch Montage generischer Prozesspartikel. Wiesbaden 1997. [Rohl95] Rohloff, M.: Produktionsmanagement in modularen Organisationsstrukturen. Reorganisation der Produktion und objektorientierte Informationssysteme für verteilte Planungssegmente. München, Wien 1995. [RoSD05] Rosemann, M.; Schwegmann, A.; Delfmann, P.: Vorbereitung der Prozessmodellierung. In: Becker, J.; Kugeler, M.; Rosemann, M. (Hrsg.): Prozessmanagement. Ein Leitfaden zur prozessorientierten Organisationsgestaltung. 5. Auflage, Berlin et al. 2005, S. 45-103. [Sche97] Scheer, A.-W.: Wirtschaftsinformatik. Referenzmodelle für industrielle Geschäftsprozesse. 7. Auflage, Berlin et al. 1997. [Schr96] Schreyögg, G.: Organisation. Grundlagen moderner Organisationsgestaltung. Wiesbaden 1996. [Schu01] Schulze D.: Grundlagen der wissensbasierten Konstruktion von Modellen betrieblicher Systeme. Aachen 2001. [Schü98] Schütte, R.: Grundsätze ordnungsmäßiger Referenzmodellierung. Konstruktion konfigurations- und anpassungsorientierter Modelle. Wiesbaden 1998. [Schw99] Schwegmann, A.: Objektorientierte Referenzmodellierung. Theoretische Grundlagen und praktische Anwendung. Wiesbaden 1999. [ScSt83] Schlageter G.; Stucky, W.: Datenbanksysteme – Konzepte und Modelle. 2. Auflage, Stuttgart 1983. [Spie93] Spiegel, H.: Methodik zur Analyse und Dokumentation fachlicher Begriffswelten innerhalb des Unternehmens TELEKOM. Darmstadt 1993. [Wolf01] Wolf, S.: Wissenschaftstheoretische und fachmethodische Grundlagen der Konstruktion von generischen Referenzmodellen betrieblicher Systeme. Aachen 2001.

Architektur eines konfigurativen Referenzmodellierungswerkzeugs – adapt(x)

Tobias Rieke, Armin Stein Abstract: Eine Reihe von Grundsatzentscheidungen beeinflusst die Konstruktion eines konfigurativen Referenzmodellierungswerkzeugs. Hierzu zählen neben der Selektion eines adäquaten Fachkonzepts insbesondere die Auswahl der Implementierungsplattform und die damit einhergehende Softwarearchitektur des Werkzeugs. In diesem Rahmen ist auch zu entscheiden, ob die Konstruktion des Werkzeugs im Rahmen einer Neuentwicklung oder auf Grundlage bestehender Werkzeuge realisiert wird, die entsprechend erweitert werden. Der vorliegende Beitrag erläutert die Anforderungen, die ausgehend von der konfigurativen Referenzmodellierung an ein Modellierungswerkzeug zu stellen sind und leitet daraus Gestaltungsaspekte hinsichtlich der Werkzeugarchitektur ab, welche detailliert beschrieben werden.

1

Gestaltungsentscheidungen für die Architektur eines konfigurativen Referenzmodellierungswerkzeugs

Bei der Entwicklung der Funktionalitäten, die zur Unterstützung der konfigurativen Referenzmodellierung benötigt werden, muss im Vorfeld entschieden werden, ob eine Neuentwicklung sinnvoll ist, oder ob die Weiterentwicklung vorhandener Werkzeuge als Lösung in Frage kommt. Hierbei ist insbesondere zu beachten in wie weit vorhandene Modellierungswerkzeuge überhaupt erweiterungsfähig sind bzw. ob Neuentwicklungen gegenüber etablierten Werkzeugen überhaupt Chancen eingeräumt werden können, sich am Markt durchzusetzen. Ausgehend von diesen Überlegungen sind im Rahmen einer Studie Modellierungswerkzeuge untersucht worden, die sich in besonderem Maße für eine Weiterentwicklung eignen – sogenannte Metamodellierungswerkzeuge [DeKn07]. Ob ihrer eingeschränkten Benutzerfreundlichkeit wurde diese Alternative jedoch verworfen. Ebenfalls wurde die Alternative einer

34

Tobias Rieke, Armin Stein

Eigenentwicklung verworfen, da in einem solchen Rahmen nicht vertretbarer Zusatzaufwand bzgl. der Erstellung von Standardfunktionalitäten zu erwarten war, deren Ausgereiftheit von Standardwerkzeugen zudem bei weitem übertroffen werden dürfte. Aus diesem Grund wurde entschieden, eine Erweiterung zu entwickeln, die unabhängig vom Modellierungswerkzeug ist und dessen Mangel an Konfigurationsfunktionalität ergänzt. Hierzu werden Modelle, die mithilfe einer beliebigen Modellierungssoftware erstellt werden, exportiert, in ein werkzeug- und plattformunabhängiges Format überführt, in der Erweiterung konfiguriert und wiederum als werkzeugabhängige Datei rückimportiert. Die einzelnen Schritte des Im- und Export- sowie des Transformationsprozesses bleiben dabei aus ergonomischen Gründen für den Nutzer transparent.

2

Die Softwarearchitektur von adapt(x)

Eine solche prototypische Implementierung wurde im Rahmen des RefMod06-Projekts unter dem Namen adapt(x) in Verbindung mit dem Modellierungswerkzeug ARIS Business Architect 7.0 der IDS Scheer AG entwickelt. Dieses Werkzeug zeichnet sich durch die Bereitstellung einer Skriptsprache aus, die es ermöglicht, auf viele Bereiche des Programms Einfluss zu nehmen. Abbildung 1 stellt die aus den Anforderungen entstandene Architektur der Erweiterung dar und wird im Folgenden erläutert. Auf der linken Seite sind die innerhalb des Basismodellierungswerkzeugs zu implementierenden Elemente abgebildet, die zur Vorbereitung der Konfiguration dienen. Die von der jeweiligen Modellierungsumgebung unabhängige Komponente adapt(x), welche auf einem klassischen DreiSchichten-Modell, getrennt in Darstellungs-, Logik- und Datenbankschicht, beruht, ist rechts dargestellt. Weiterhin existiert eine XML-Beschreibung [W3C06] in Form einer XML-Schema-Datei, die als Schnittstelle zur Modellierungsumgebung dient. Auf Seiten der Modellierungsumgebung müssen Möglichkeiten geschaffen werden, um Modelle konfigurierbar zu machen, d. h. es müssen sowohl Konfigurationsterme als auch Konfigurationsattribute an Elementausprägungen und Modelle annotiert werden können (vgl. hierzu den Beitrag von PATRICK DELFMANN und ARMIN STEIN in diesem Band). Die möglichen Ausprägungen der verwendeten Konfigurationsparameter werden in einer MySQL-Datenbank gehalten [MySQ06], auf die auch von adapt(x) zugegriffen wird. Hierbei sollte die Kommunikation bidirektional funktionieren, was bedeutet, dass Parameterausprägungen, die in der Modellierungsumgebung (neu) angelegt

Architektur eines konfigurativen Referenzmodellierungswerkzeugs – adapt(x) 35

werden, so in die Datenbank geschrieben werden, dass sie in adapt(x) verfügbar sind, und umgekehrt. Weiterhin ist es wünschenswert, dass ein automatisierter Aufruf von adapt(x) aus der Modellierungsumgebung stattfinden kann, um ein benutzerunfreundliches manuelles Exportieren und Importieren zu vermeiden.

Abbildung 1: Architektur von adapt(x)

Als visuelle Schnittstelle für den Benutzer stehen Fenster via Java Swing [Sun06a] und Java AWT [Sun06b] zur Verfügung, die über Schnittstellen auf Klassen und Methoden innerhalb der Geschäftslogik zugreifen.

3

XML-basierter Austausch von Modelldaten: CML

Die Kommunikationsschicht zum Modellierungswerkzeug wird durch eine MySQL-Datenbank und ein XML-Schema umgesetzt. Die Datenbank einerseits enthält hierbei die Konfigurationsparameter, deren Ausprägungen, Konfigurationsregeln, Benutzerinformationen, Sprachdefinitionen und Anwendungsregeln der verwendeten Modellierungsumgebung. Um eine Kon-

36


figuration unabhängig von einer speziellen Modellierungsumgebung vornehmen zu können, wurde andererseits ein XML-Format entwickelt, dessen Struktur sich nach den für die Konfiguration relevanten und benötigten Informationen richtet. Angelehnt an die Anforderungen des „configurative information modeling“ wurde die Bezeichnung CML für „coin markup language“ gewählt. Dieses Schema umfasst allgemeine (MiscArea), definitions- (DefArea) und modellspezifische (ModelArea) Bereiche (vgl. Abbildung 2 links, unterer Ast). Die zwei übergeordneten Attribute Tool und RefModID speichern einerseits eine Bezeichnung der Modellierungsumgebung, andererseits den Namen des Referenzmodells, das exportiert wurde. Anhand des Namens des Werkzeugs werden in der Datenbank die entsprechenden Metamodellregeln und Konsistenzsicherungsalgorithmen ausgewählt, die werkzeugspezifisch sind.

Abbildung 2: Grundstruktur der CML, Aufbau der MiscArea

Elemente, die für die Konfiguration nicht benötigt werden (MiscChildElement), können im Bereich MiscArea in verschiedenen Containern durch den Konfigurationsprozess hindurchgereicht werden. Die Bezeichnung ChildElement bezieht sich im Folgenden immer auf Elemente, die nicht für eine Konfiguration relevant sind, jedoch für die weitere Verwendung in der Modellierungsumgebung zwischengespeichert werden müssen. Beispiele für solche Elemente sind verwendete Schriftarten, Sprachkonventionen oder Datenbankeinstellungen des Modellierungswerkzeugs. Im Bereich DefArea (vgl. Abbildung 3) werden Definitionen von Elementen (DefType), die innerhalb des Referenzmodells ausgeprägt werden, gespeichert. Da Definitionsausprägungen in unterschiedlichen Modellen vertreten sein können, werden die Typen unabhängig von den jeweils konkreten Modellen in diesem gesonderten Bereich abgelegt. Definitionen können wiederum werkzeugspezifische Informationen enthalten, die für eine Konfiguration nicht relevant sind – Beispiele hierfür sind der Name des Erstellers, Zeitstempel der letzten Änderungen oder intern vergebene IDs. Diese werden als ChildElement in der entsprechenden Rubrik abgelegt (Def-ChildElement). Notwendig für eine Konfiguration ist die Hinter-


legung des Namens (DefLabel), welche Ausprägungen eine Definition besitzt (DefOcc), welche Kanten ein-, und welche ausgehen (InDefCxn, OutDefCxn) sowie Verbindungen zu verknüpften Modellen, wenn ein Element als Ausgangspunkt für eine Verfeinerung dient (LinkedModel). Innerhalb der Attribute (Bereich attributes) werden Informationen über den Elementtyp (DefType), die eindeutige ID der Definition (DefID) sowie ein zugeordnetes Symbol (DefSymbol) gespeichert. Zusätzliche, tiefer geschachtelte Attribute können in dem Container DefAttribute gespeichert werden. Mit diesen Angaben kann eine Elementtypselektion durchgeführt werden, indem jedes Element, das einem gewählten Typ entspricht, aus der CML entfernt wird.

Abbildung 3: DefArea mit Darstellung der untergeordneten Elemente

Durch die Aufzählung sämtlicher Ausprägungen (Occurrences) der Definition innerhalb des XML-Elements DefOcc können diese und die damit im Zusammenhang stehenden Kanten beim Entfernen einer Definition ebenfalls gelöscht werden. Modelle sind immer jeweils genau einer Technik zugeordnet und werden als ModType-Element im Bereich ModelArea geführt (vgl. Abbildung 4). Der Typ eines Modells (attributes: ModType) kann – im Falle von

38


ARIS – bspw. „MT_EEPC“ sein, ein Code, der für „ModelType Enhanced EventProcessChain“ steht. Damit adapt(x) werkzeugunabhängig erkennen kann, dass es sich bei diesem Kürzel um das werkzeugspezifische für „EPK“ handelt, muss in der Datenbank im Vorfeld ein Namespace für das Modellierungswerkzeug angelegt werden, anhand dessen die Übersetzung vorgenommen werden kann. Durch die optionalen Elemente COINAttribut und COINTerm können auch attributierte oder mit Termen versehene Modelle – unabhängig von ihrem Typ – mittels einer Modellselektion entfernt werden. Ansonsten entsprechen die Elemente des ModTyp“ denen des DefType; attributes: ModID ist eine eindeutige ID des Modells, attributes: ModName eine Bezeichnung. ModLabel kann Modellbezeichnungen in unterschiedlichen Sprachen aufnehmen, ModChildElement umfasst wiederum nicht für die Konfiguration benötigte Elemente, ModAttribute komplexere, nicht benötigte Attributstrukturen.

Abbildung 4: Modellelement mit Darstellung der untergeordneten Elemente

Die in Modellen gebündelten Ausprägungen sind unter dem Element Occ abgelegt (vgl. nochmals Abbildung 4). In den attributes auf oberster Ebene werden die für die Konfiguration zusätzlich relevanten Informationen gespeichert, während die Konfigurationsattribute und -terme – wie schon bei


den Modellen – in zusätzlichen Elementen gespeichert werden: COINAttribut und COINTerm (vgl. Abbildung 5).

Abbildung 5: Ausprägungselement mit Darstellung der untergeordneten Elemente

Die attributes des Elements dienen in erster Linie der Ermöglichung einer Darstellungsvariation, indem die Farbe (OccColor), Größe (ElemSizeX, ElemSizeY) und Rahmenart (BorderStyle, BorderColor, BorderWidth) hinterlegt wird. Für eine Darstellungsvariation der Symbole ist ein Attribut OccSymbol reserviert, das bei ARIS jedoch nicht geändert werden kann, da dort eine 1:1-Zuordnung zwischen Elementtyp und Darstellung in der internen Datenbank festgelegt ist. Eine Ausprägung ist eindeutig über eine attributes:OccID identifizierbar und trägt eine Bezeichnung (attributes: OccName). Weiterhin wird auf die ID der Definition der Ausprägung referenziert (attributes:OccDefRef). Innerhalb eines Occurrence-Elements werden außerdem die in den Definitionen enthaltenen Kanten ausgeprägt

40


(OutCxnOcc). OccChildElement und OccAttribute erlauben wieder für jeden Bereich das Speichern von modellabhängigen, für die Konfiguration irrelevanten Informationen.

4

Ablauf einer Konfiguration innerhalb von adapt(x)

Um schließlich ein Referenzmodell innerhalb von adapt(x) konfigurieren zu können, wird aus der CML-Datei durch JAXB [Sun06c], einem JavaXML-Objekt-Mapper, ein Java-Objekt erzeugt, dessen Elemente durch eigens für CML geschaffene JAXB-Klassen manipuliert werden können. Diese Geschäftslogik vereint die oben angeführten in den Werkzeugen fehlenden Funktionen. Hierzu gehören neben den Mechanismen der Konfiguration selbst auch die Überprüfung der Modellkonsistenz, eine Benutzerverwaltung sowie Klassen zur Termerzeugung und -auswertung. adapt(x) nutzt XALAN [Apac05] als XSLT-Transformator, um die verschiedenen modellierungsumgebungsabhängigen XML-Sprachvarianten in CML zu übersetzen. Hierfür ist es notwendig, dass eine entsprechende XSLT-Datei für die jeweilige Modellierungsanwendung erstellt wird. Die Datenbankschnittstelle ist mittels einer JDBC-Klasse [Sun06d] im Singleton-Verfahren realisiert, die dafür sorgt, dass lediglich eine Datenverbindung während der Session benötigt wird. Die Schnittstellen zur Geschäftslogik sind derart implementiert, dass von der zugrunde liegenden Datenbankarchitektur abstrahiert wird, was es ermöglicht, einerseits unterschiedliche Datenbanktypen zu verwenden, andererseits beliebige Zugriffsmethoden – wie bspw. Hibernate [Elli04] – einzubinden. Schließlich wird während der Konfiguration ein Audit-Trail erstellt, der es ermöglicht, die Konfiguration einerseits menschenlesbar auszuwerten, andererseits aufgrund eindeutig definierter Symbole eine maschinelle Bearbeitung erlaubt. Der Audit-Trail ist insbesondere für das Controlling von Konfigurationsprozessen relevant, wie sie im Beitrag von CHRISTIAN SEEL und PETER LOOS in diesem Band thematisiert werden.

5

Vorbereitung der Konfiguration in ARIS mit Makros

Damit ein Modell von adapt(x) konfiguriert werden kann, muss es im Vorfeld mit Konfigurationsregeln angereichert werden. Dies bedeutet im Einzelnen, dass die für die Konfiguration relevanten Elemente – seien es Objekte oder Modelle – attributiert bzw. mit den entsprechenden Termen versehen werden. Hierzu ist es erforderlich, dass das Attributieren für den Be-


nutzer möglichst intuitiv vorgenommen werden kann. Realisiert wurde dies durch ein in Aris-Script entwickeltes Plugin innerhalb von ARIS in Form von Makros (vgl. Abbildung 1). Dieses besteht aus Dialogen, die den Anwender bei der Auswahl der Parameter anleiten und die Erstellung von Konfigurationsregeln unterstützen (vgl. zur Nutzung dieses Plugins den folgenden Beitrag von PATRICK DELFMANN, TOBIAS RIEKE und ARMIN STEIN). Um zu vermeiden, dass Parameter redundant angelegt werden und somit unter Umständen Inkonsistenzen auftreten, wird auf die mit adapt(x) gemeinsam genutzte Datenbank zugegriffen. Mit der vorgestellten getrennten Architektur ist es möglich, mittels der Ergänzung der unterschiedlichen Modellierungswerkzeuge durch eine Anleitung zur Attributierung der Elemente nahezu jedes Modell, das als XML exportiert werden kann, zu konfigurieren.

Literaturverzeichnis [Apac05] The Apache Software Foundation: Xalan-Java Version 2.7.0. http://xml .apache.org/xalan-j. 2005. [DeKn07] Delfmann, P.; Knackstedt, R.: Konfiguration von Informationsmodellen. Untersuchungen zu Bedarf und Werkzeugunterstützung. In: Oberweis, A.; Weinhardt, C.; Gimpel, H.; Koschmider, A.; Pankratius, V.; Schnizler, B. (Hrsg.): eOrganisation: Service-, Prozess-, Market-Engineering. Proceedings der 8. Internationalen Tagung Wirtschaftsinformatik. Band 2. Karlsruhe 2007, S. 127-144. [Elli04] Elliott, J.: Hibernate: a developer's notebook. Cambridge 2004. [Sun06a] Sun Microsystems: Creating a GUI with JFC/Swing. http://java.sun. com/docs/books/tutorial/uiswing. 2006. [Sun06b] Sun Microsystems: The AWT in 1.0 and 1.1. http://java.sun.com/products/jdk/awt. 2006. [Sun06c] Sun Microsystems: Java Architecture for XML Binding (JAXB). http:// java.sun.com/webservices/jaxb. 2006. [Sun06d] Sun Microsystems: Java SE - Java Database Connectivity (JDBC). https://java.sun.com/javase/technologies/database/index.jsp. 2006. [MySQ06] MySQL AB: My SQL – Die populärste Open-Source-Datenbank der Welt. http://www.mysql.de. 2006. [W3C06] World Wide Web Consortium: Extensible Markup Language (XML). http://www.w3.org/XML. 2006.

Anpassung von Referenzmodellen mit adapt(x)

Patrick Delfmann, Tobias Rieke, Armin Stein Abstract: Das konfigurative Referenzmodellierungswerkzeug adapt(x) wurde als ein Add-on für den ARIS Business Architect 7.0 entwickelt. Aufgrund der Möglichkeit des plattformunabhängigen XML-Exports sowohl von Modellen als auch von ganzen Datenbanken findet somit lediglich die Modellierung als solche sowie die Attributierung der Modellelemente in der konventionellen Modellierungsumgebung ARIS statt. Die eigentliche Konfiguration ist in ein Add-on ausgelagert, das unter Zuhilfenahme verschiedener Frameworks in Java implementiert ist und durch seine modulare Entwicklungen mittels weniger Ergänzungen auch an andere Modellierungsumgebungen angepasst werden kann. Um eine Konfiguration zu ermöglichen, die den fachkonzeptionellen Anforderungen entspricht, wird der von ARIS erzeugte Code durch eine Übersetzungsschnittstelle in ein generisches XML-Schema übersetzt. Dieses ermöglicht eine vereinfachte Anwendung von Konfigurationsmechanismen auf die Modelldaten. Zur Sicherstellung einer konsistenten Datenhaltung greifen beide Teile auf eine gemeinsame Datenbasis zu. Dieses Umfeld führt zu Besonderheiten bei der Bedienung von adapt(x) im Zusammenspiel mit ARIS, welche in diesem Beitrag ausführlich erläutert werden.

1

Vorbereitung der Konfiguration in adapt(x)

Das Konfigurationswerkzeug adapt(x) setzt das im Beitrag von PATRICK DELFMANN und ARMIN STEIN eingeführte Fachkonzept um und nutzt die im Beitrag von TOBIAS RIEKE und ARMIN STEIN vorgestellte Anwendungssystemarchitektur. Als Ausgangspunkt für die Demonstration von adapt(x) dient der folgende Beispielprozess der Rechnungsprüfung aus dem Handels-H-Modell [BeSc04] (vgl. Abbildung 1). In ihm sind die verschiedenen Abläufe der Rechnungsprüfung für die Ausprägung Lager- und Streckengeschäft sowie Zentralregulierung vereint.

44

Patrick Delfmann, Tobias Rieke, Armin Stein

Die Hinterlegungen der Elemente in Abbildung 1 deuten an, welche Elemente für welche Merkmalsausprägung des Unternehmensmerkmals „Geschäftsart“ relevant sind. Damit das Referenzmodell innerhalb von ARIS konfigurierbar gemacht werden kann, werden diese Unternehmensmerkmale zunächst in der externen adapt(x)-Applikation in der Datenbank angelegt. Wurden bereits unabhängig von adapt(x) Parameter angelegt, werden diese beim initialen Modellexport direkt in die Datenbank übertragen. Rechnung ist eingetroffen

Rechnung Rechnung auf Geschäftsart prüfen Rechnungsprüfer

Wareneingang ist verbucht

Wareneingangsbeleg

Rechnungsprüfer

Lagergeschäft liegt vor

Streckengeschäft liegt vor

Rechnung gegen Wareneingang prüfen Rechnung ist gegen Wareneingang geprüft

Rechnungskopie ist eingetroffen Rechnungskopie

Rechnung Rechnung preislich prüfen Rechnungsprüfer Rechnung ist preislich geprüft

Kreditorenbuchhaltung

Korrekte KundenLieferanten-ZuO sicherstellen

Rechnungsprüfer

Korrekte KundenLieferantenZuO ist...

Fakturierung

Abbildung 1: Rechnungsprüfungsprozess für verschiedene Geschäftsarten

Zum Anlegen von Konfigurationsparametern und allgemeinen Konfigurationsregeln wird adapt(x) aus ARIS heraus gestartet (vgl. Abbildung 2). Hierbei wird in der externen Datenbank automatisch ein Bereich für das zu konfigurierende Referenzmodell anhand der Bezeichnung der ARIS-Datenbank angelegt.


45

Abbildung 2: adapt(x) aus ARIS heraus starten

Die Unternehmensmerkmale und Perspektiven können in adapt(x) durch die Maske, die in Abbildung 3 dargestellt ist, erzeugt, verändert oder gelöscht werden.

Abbildung 3: Anlegen von Unternehmensmerkmalen und Perspektiven

Diese Einträge stehen nach dem Anlegen einerseits in der Modellierungsumgebung über die Erweiterung zur Verfügung, andererseits ermöglichen sie die Konfiguration durch die Selektion der relevanten Parameter. Ein Referenzmodell kann zum einen über bestimmte Unternehmensmerkmale konfiguriert werden, zum anderen über ausgewählte Perspektiven. Bei einer Konfiguration, die das Gesamtmodell des hier verwendeten Beispiels für das Lagergeschäft anpasst, wurde noch keine Rücksicht auf perspektivenabhängige Präferenzen genommen. Welche Aktion aufgrund der Auswahl einer Perspektivenausprägung durchgeführt werden soll, wird mittels Konfigurationsregeln festgelegt. Diese stellen eine Ausprägung ei-

46


nes Konfigurationsmechanismus dar. So ist beispielsweise „EPKs entfernen“ eine Ausprägung des Mechanismus Modelltypselektion (vgl. Abbildung 4). Auf diese Weise können Mechanismen Regeln zugeordnet werden, für die dann eine Zuweisung zu Perspektivenausprägungen vorgenommen werden kann.

Abbildung 4: Anlegen einer Konfigurationsregel

Die folgende Übersicht illustriert, wie eine solche Zuordnung vorgenommen wird. Für eine Perspektive (z. B. „Rolle: Manager“), in der keine rein transitorischen Ereignisse zwischen Prozessfunktionen in EPKs gewünscht sind – so genannte Trivialereignisse – wird die Konfigurationsregel „EPK: Keine Trivialereignisse“ angelegt. Diese Regel entspricht einer Elementselektion über Konfigurationsattribute und wird der Perspektive zugeordnet. Dies führt dazu, dass bei einer Konfiguration eines Modells unter Auswahl der Perspektive „Rolle: Manager“ eine Elementselektion durchgeführt wird, bei der Elemente mit dem Attribut „Trivialelement=True“ ausgeblendet werden.


47

Abbildung 5: Konfigurationsregeln Perspektivenausprägungen zuordnen

2

Vorbereitung der Konfiguration in ARIS

Nachdem die Merkmale, Parameter und Regeln in adapt(x) angelegt sind, können die Modelle in ARIS mit Konfigurationseinstellungen versehen werden.

Abbildung 6: Terme für Modellelemente anlegen

48


Hierzu wird das Skript Konfigurationsterme_Konfigurationsattribute_editieren (Modellelemente) ausgeführt, mit dem Konfigurationsattribute und/ oder Konfigurationsterme für ein oder mehrere Modellelemente angelegt werden können (vgl. Abbildung 6). Somit werden die Elemente sukzessive – dem Schema in Abbildung 6 entsprechend – mit Konfigurationstermen versehen. Zusätzlich – zur Realisierung einer Elementselektion nach Attributen – wird bspw. das Ereignis „Rechnung ist gegen Wareneingang geprüft“ als Trivialereignis markiert (vgl. Abbildung 7). Dies ermöglicht es, bei einer Konfiguration in Verbindung mit der Perspektive „Manager“ (vgl. Abbildung 3), das Ereignis aus dem dann konfigurierten Modell auszublenden. Es bietet sich an, die Konfigurationsannotationen schon während der Entwicklung des Referenzmodells, und nicht erst im Anschluss, vorzunehmen.

Abbildung 7: Attributierung eines Elements

3

Durchführung der Konfiguration

Sobald das Modell Konfigurationseinstellungen erhalten hat, kann die Konfiguration durchgeführt werden. Hierfür wird das Modell – wobei es sich hier um ein einzelnes Modell oder die gesamte Referenzmodellbasis handeln kann – über das Makro „Referenzmodell konfigurieren“ nach


49

adapt(x) exportiert (vgl. Abbildung 2). Ein Export eines Teilmodells bietet sich bspw. dann an, wenn das gesamte Referenzmodell bereits unternehmensmerkmalspezifisch konfiguriert wurde und für einzelne Elemente noch eine perspektivenspezifische Anpassung vorgenommen werden soll. Bei der Durchführung dieses Schritts wird das (Referenz-)Modell, wie im Beitrag von TOBIAS RIEKE und ARMIN STEIN in diesem Band bereits beschrieben, zunächst von ARIS in der ARIS Markup Language (AML) exportiert und anschließend mittels XALAN nach CML transformiert. Der Empfangsbildschirm von adapt(x) zeigt eine Übersicht über die im Referenzmodell enthaltenen Teilmodelle (vgl. Abbildung 8).

Abbildung 8: Auflistung der im Referenzmodell enthaltenen Teilmodelle

Die Übersicht kann als Orientierung verwendet werden, um eine so genannte Ad-hoc-Konfiguration des Referenzmodells vorzunehmen. Dies bedeutet, dass einzelne Konfigurationsmechanismen ohne die Anwendung von im Vorfeld definierten Konfigurationsregeln durchgeführt werden.

Abbildung 9: Ad-hoc-Konfiguration: Ausblenden aller Modellelemente des Typs „Stelle“ aus dem Rechnungsprüfungsprozess

50


Für eine Ad-hoc-Konfiguration sind die Mechanismen Modelltypselektion, Elementtypselektion, Darstellungsvariation und Bezeichnungsvariation geeignet. Da bei Selektionen, von denen lediglich Typen betroffen sind, keine Auswahl der zu entfernenden Elemente aufgrund von konkret modelloder elementbezogenen Einstellungen erfolgt, können die Typen unabhängig von Konfigurationsregeln ausgeblendet werden (vgl. Abbildung 9). Bei einer Konfiguration über Konfigurationsparameter werden alle Parameter – und somit die hinterlegten Regeln – ausgewählt, die relevant für den Konfigurationsschritt sind (vgl. Abbildung 10).

Abbildung 10: Konfiguration über Konfigurationsparameter

Im Beispiel wird das Modell für das Zentralregulierungsgeschäft sowie für die Perspektiven „Manager“, „Darstellung für Farbenblinde“ und „Anwendungssystemgestaltung“ konfiguriert.

Tabelle 1:

Zuordnung der Regeln zu Perspektiven


51

Den Perspektiven sind Konfigurationsregeln mit jeweils unterschiedlichen Konfigurationsmechanismen zugeordnet, die unterschiedliche Modifikationen in den Modellen hervorrufen (vgl. Tabelle 1; vgl. für die Zuordnung von Konfigurationsregeln zu -mechanismen nochmals Abbildung 5).

Rechnung ist eingetroffen



Wareneingangsbel eg

Rechnungsprüfer


Streckengesch äft liegt vor


Rechnungskop ie ist eingetroffen


Kreditorenbuchhalt ung


Rechnungskopie

Rechnungsprüfer


Fakturierung

Rechnungskop ie ist eingetroffen Rechnungskopie

„Zentralregulierung“ „Manager“ „Farbblindheit“ „Anwendungssystemgestaltung“

Korrekte KundenLieferanten-ZuO sicherstellen Korrekte KundenLieferantenZuO ist...

Fakturierung

Abbildung 11: Ergebnis der Konfiguration „Zentralregulierung“

52


Das entsprechend den Konfigurationsregeln angepasste und nach ARIS zurückexportierte Modell gestaltet sich gemäß Abbildung 11.




Wareneingangsbel eg

Rechnungsprüfer








Rechnungsprüfer


Fakturierung


Rechnung

„Streckengeschäft“ „Manager“ „Farbblindheit“ „Anwendungssystemgestaltung“

Rechnung preislich prüfen

Rechnung ist preislich geprüft


Fakturierung

Abbildung 12: Ergebnis der Konfiguration „Streckengeschäft“

Es ist zu beachten, dass nicht nur die attributierten und mit Termen versehenen Objekte aus dem Modell entfernt, sondern auch – der Konsistenz


53

der Technik EPK entsprechend – syntaktische Korrekturen durchgeführt werden. Vor der Schnittstelle „Fakturierung“ wird so das XOR-Element entfernt, da der alternative Entscheidungsstrang des Lager- und Streckengeschäfts im auf Zentralregulierung konfigurierten Modell nicht mehr vorhanden ist. Das Entfernen des Elements „Rechnungsprüfer“ wird aufgrund der Regel „Anwendungssystemgestaltung“ veranlasst: es sollen keine Informationen über Organisationseinheiten mehr dargestellt werden. Die Regel „EPK: Schwarz-Weiß“ führt dazu, dass die Elemente „Funktion“ und „Ereignis“ von ihrer Standardfarbe zu einer monochromen Darstellungsweise geändert werden. Der Entitytyp „Rechnungskopie“ wird nicht geändert, da die angelegte Regel für die Perspektive „Farbblindheit“ keine Farbänderung für diesen Typen beinhaltet. In Bezug auf die Konsistenzsicherung müssen noch weitere Fälle berücksichtigt werden. Die verwendeten Algorithmen können aufgrund ihrer Regeln Elemente löschen und neue Kanten erstellen, unter bestimmten Voraussetzungen kann dies jedoch nur unter Berücksichtigung der Semantik, d. h. mit Interaktion des Modellierers, geschehen [Delf06, S. 139ff.]. Eine Konfiguration des Modells für das Unternehmensmerkmal „Streckengeschäft“ verdeutlicht dieses Problem. Hierzu wird zunächst in Abbildung 12 dargestellt, wie ein auf diese Art konfiguriertes Modell aussehen sollte, wobei wiederum die Perspektiven „Anwendungssystemgestaltung“, „Manager“ und „Farbblindheit“ verwendet werden.

Abbildung 13: Dialog zur Konfliktbehandlung

Während der Durchführung der Konfiguration erreicht der Algorithmus eine Stelle, an der die Entscheidung, wie eine Kante gelegt werden soll, nicht mehr automatisch getroffen werden kann. Nach dem Ausblenden aller nicht relevanten Modellelemente existieren mehrere Möglichkeiten, eine vom Ereignis „Rechnung ist eingegangen“ ausgehende Kante zu zie-

54


hen, nämlich zur Funktion „Rechnung preislich prüfen“ und zum einzigen zusammenführenden AND-Konnektor.




Wareneingangsbel eg

Rechnungsprüfer








Rechnungsprüfer


Fakturierung

Abbildung 14: Entscheidungsproblem bei der Konfiguration gemäß „Streckengeschäft“


55

Der semantisch korrekte Ablauf des Prozesses führt jedoch nur über den erstgenannten Weg. Dies kann allerdings nicht automatisiert erkannt werden, da hier eine Entscheidung rein aufgrund der Modellsemantik getroffen werden muss. Aus diesem Grund wird während des Konfigurationsprozesses eine Rückfrage an den Anwender gestellt (vgl. Abbildung 13), der dieses Problem dann intuitiv durch die Auswahl von „Rechnung preislich prüfen“ lösen kann. Dies resultiert dann ohne weitere Notwendigkeit der Bearbeitung in dem Modell von Abbildung 12. Da zum Zeitpunkt der Fragestellung das Modell visuell nicht vorliegt, kann die Entscheidung für eine Alternative problematisch sein. Die Auswahl von ermöglicht es, die Entscheidung auf eine Anwendung innerhalb der Modellierungsumgebung zu verschieben. Dies führt zum Zustand, der in Abbildung 14 dargestellt ist. Der Anwender muss dann die optisch hervorgehobenen und mit dem Hinweis „Kante überprüfen!“ versehenen Konnektoren manuell löschen und die Elemente entsprechend neu verbinden. Während der Konfiguration wird ein Log erstellt, das elektronisch ausgewertet werden kann. Es enthält Informationen über die verwendeten Unternehmensmerkmale und Perspektiven, sowie die zugewiesenen Regeln. Das folgende Beispiel stellt einen Ausschnitt aus dem Log der oben durchgeführten Konfiguration dar: +--------------------------Adapt(x)-Log-Datei---+ | Verwendetes Referenzmodell: [--mod] Handels_H | | Erstelldatum: [-date] 25.09.06 14:04 Uhr | | Verwendetes Tool: [-tool] ARIS70 | | Angemeldeter Benutzer: [-user] system, system | +-----------------------------------------------+ +-----------------------------------------------+ + Ausgewählte Unternehmensmerkmale: + +-----------------------------------------------+ [-kpas] Streckengeschäft +-----------------------------------------------+ + Ausgewählte Perspektiven: + +-----------------------------------------------+ [-kpas] Anwendungssystemgestaltung [-kpas] Darstellung für Farbenblinde [-kpas] Manager +-----------------------------------------------+ + Elementtypselektion + +-----------------------------------------------+ Angewandte Konfigurationsregel: [konfr] Keine Organisationseinheiten --[x]-- "Rechnungsprüfer" --[x]-- "Rechnungsprüfer" --[x]-- "Rechnungsprüfer" --[x]-- "Rechnungsprüfer"

56


+-----------------------------------------------+ + Elementselektion + +-----------------------------------------------+ Angewandte Konfigurationsregel: [konfr] EPK: Keine Trivialereignisse --[x]-- "Wareneingangs-beleg" --[x]-- "Rechnungskopie" --[x]-- "Rechnung" --[x]-- "Rechnung ist gegen Wareneingang geprüft" --[x]-- "Wareneingang ist verbucht" --[x]-- "Lagergeschäft liegt vor" --[x]-- "Rechnung gegen Wareneingang prüfen" --[x]-- "Korrekte Kunden-Lieferanten-ZuO sicherstellen" --[x]-- "Rechnung auf Geschäftsart prüfen" --[x]-- "Korrekte Kunden-Lieferanten-ZuO ist sichergestellt" --[x]-- "Rechnungs-kopie ist eingetroffen" --[x]-- "Streckenge-schäft liegt vor" --[x]-- "UND-Regel" --[x]-- "XOR-Regel" --[x]-- "XOR-Regel" --[x]-- "XOR-Regel" --[x]-- "XOR-Regel" --[x]-- "UND-Regel" +-----------------------------------------------+ + Darstellungsvariation + +-----------------------------------------------+ Angewandte Konfigurationsregel: [konfr] EPK: Schwarz-Weiß +-------------------------------Legende---------+ | [A]>[B] - Bezeichnungsvariation | | [--mod] - Konfiguriertes Referenzmodell | | [-date] - Zeitpunkt der Konfiguration | | [-tool] - Verwendetes Modellierungstool | | [-user] - Angemeldeter Benutzer | | [konfr] - Konfigurationsregel | | --[x]-- - Elementausprägung gelöscht | | --[X]-- - Elementdefinition gelöscht | | [O]-x-[ - Kantenausprägung gelöscht | | [D]-x-[ - Kantendefinition gelöscht | | [Mod]:X - Modell gelöscht | | [Elm]:X - Elementtyp gelöscht | | [O]---[ - Kantenausprägung erzeugt | | [D]---[ - Kantendefinition erzeugt | | []->[ ] - Elementgröße verändert | | [b]>[g] - Elementfarbe geändert | | []-->{} - Randstyle geändert | | >[< >]< - Randgröße geändert | | [M:X]>X - Hinterlegung auf Modell gelöscht | | !X!X!X! - Fehler | | | | Ende der Konfiguration: 25.09.06 14:05 Uhr. | +--------------------------Adapt(x)-Log-Datei---+


57

Durch den strukturierten Aufbau und die Codierung können Auswertungsalgorithmen angewandt werden, die das Log auf die Häufig der Anwendung bestimmter Regeln hin untersuchen, oder Elemente, die besonders häufig entfernt wurden, identifizieren. Das Log kann dazu verwendet werden, das Controlling von Anpassungsprozessen zu unterstützen (vgl. auch den Beitrag von CHRISTIAN SEEL und PETER LOOS in diesem Band).

4

Zusammenfassung und Ausblick

Die im Fachkonzept für konfigurative Referenzmodellierungswerkzeuge spezifizierten Anforderungen werden durch adapt(x) vollständig umgesetzt.

Abbildung 15: Erweiterung von adapt(x) zur Definition von Komponenteneigenschaften

Aktuelle Weiterentwicklungen von adapt(x) konzentrieren sich auf die Erweiterung der Adaptionsunterstützung, die neben der Konfiguration

58


auch Wiederverwendungsansätze der Aggregation, Instanziierung, freien Modifikation und Analogiebildung vereint (vgl. auch die abschließenden Bemerkungen im Beitrag von PATRICK DELFMANN und ARMIN STEIN in diesem Band). Die Abbildungen 15 und 16 zeigen erste Ergebnisse dieser Weiterentwicklung. Bspw. sind für die Verwaltung von Modellkomponentenbibliotheken Modellbereiche zu markieren, diese als Komponente auszuweisen und mit entsprechenden Eigenschaften anzureichern, um eine spätere Wiederauffindung bei der Wiederverwendung zu erleichtern (vgl. Abbildung 15). Entsprechend ist der Prozess der Wiederauffindung zu unterstützen. Hierfür sind entsprechende Suchmechanismen zur Verfügung zu stellen, die auf den im Vorfeld definierten Komponenteneigenschaften basieren (vgl. Abbildung 16).

Abbildung 16: Erweiterung von adapt(x) zur Wiederauffindung von Komponenten in Komponentenbibliotheken

Die übrigen Wiederverwendungsansätze Instanziierung, freie Modifikation und Analogiebildung sind entsprechend zu unterstützen. Vgl. zu einer detaillierten Beschreibung der Erweiterungen von adapt(x) [BDFR07]. Mittelfristig ist zu prüfen, in wie weit die Unterstützung der Konsistenzsicherung im Rahmen der Konfiguration methodisch vollständig ausgereift


59

werden kann. Zur Entlastung des Modellierers bietet es sich bspw. an, konfigurierte Modelle, die nachträglich einer semantischen Korrektur unterzogen werden mussten, mit dem ursprünglichen konfigurierbaren Modell zu konsolidieren, so dass die nachträgliche Korrektur bei einer weiteren Konfiguration entfällt. Hierfür müssen zusätzliche Konfigurationseinstellungen, die sich aus der Korrektur ergeben, ins Ursprungsmodell übernommen werden. Zusätzlich ist darauf zu achten, dass das Ursprungsmodell auch nach der Anreicherung mit zusätzlichen Informationen konsistent und lesbar bleibt (vgl. zu einer ersten Umsetzung [DeKn07]).

Literaturverzeichnis [BDFR07] Becker, J.; Delfmann, P.; Franke, J.; Rieke, T.; Stein, A.: Implementierung von generischen Adaptionsmechanismen für Informationsmodelle auf Basis des Referenzmodellierungstools adapt(x). Erscheint in: Arbeitsberichte des Instituts für Wirtschaftsinformatik. Münster 2007. [DeKn07] Delfmann, P.; Knackstedt, R.: Towards Tool Support for Information Model Variant Management - A Design Science Approach. In: Proceedings of the European Conference on Information Systems (ECIS). St. Gallen 2007. [Delf06] Delfmann, P.: Adaptive Referenzmodellierung. Methodische Konzepte zur Konstruktion und Anwendung wiederverwendungsorientierter Informationsmodelle. Berlin 2006.

Vom Prozess zur Ausführung – Modellgestützte Entwicklung betriebswirtschaftlicher Software

Julia Wagner, Thomas Andres, Yves Lauer Abstract: Der wirtschaftliche Erfolg eines Software entwickelnden KMUs hängt neben der schnellen Softwareeinführung über adaptierte Referenzmodelle auch von der effizienten Entwicklung fehlender Funktionen ab. Um gerade KMUs die Möglichkeit zu geben, kundenspezifische Anforderungen effizient und kostengünstig zu realisieren, muss es neue Ansätze bei der Softwareentwicklung geben, die den Übergang von der nichtformalen Welt des Anwenders mit seinen natürlichsprachlichen Anforderungen in die formalisierte Welt des Softwareentwicklers mit seinen formalen Programmiersprachen erleichtern. Durch die Verbindung der Methoden und Sprachen des Geschäftsprozessmanagements mit jenen der Softwareentwicklung wird die Idee der modellgestützten Softwareentwicklung, wie sie von der Object Management Group in ihrer Model Driven Architecture (MDA) festgehalten wird, in die Praxis umgesetzt.

1

Einleitung

Die Marktdynamik, steigender Konkurrenzdruck, kurze Innovationszyklen und sich ständig erneuernde Technologien zwingen Unternehmen neue Wege einzuschlagen. Unter diesem Druck vollzog sich in den letzten Jahren ein fundamentaler Wandel. Wurden früher Unternehmensprozesse entlang der eingesetzten Softwaresysteme gestaltet und damit mitunter unzulässig eingeschränkt, wird heutzutage nach der Maxime gehandelt, ITSysteme optimal auf die Unternehmensziele auszurichten. Betriebswirtschaftliche Softwaresysteme unterstützen Geschäftsprozesse und nicht umgekehrt. Dass eine Vielzahl fachlicher Erfordernisse für die Entwicklung betrieblicher Anwendungssysteme bereits in den Geschäftsprozessen vorliegt, ist leicht nachvollziehbar. Akkurate Geschäftsprozessmodelle unterstützen die klare Abgrenzung fachlicher Anforderungen. Sie sollten deshalb den Softwareentwicklern als Grundlage sowohl für die resultie-

62

Julia Wagner, Thomas Andres, Yves Lauer

rende Systemgestaltung neuer Software als auch für die Systemveränderung bestehender Anwendungssysteme dienen. In der Praxis sehen sich jedoch beide Abteilungen der Herausforderung gegenüber, zunächst eine nicht unbeträchtliche Kommunikationsbarriere überwinden zu müssen. Während sich die Fachabteilungen mit den Prozessen einer Organisation auseinandersetzen, lebt der Softwareentwickler in einer Welt der Objekte und Daten. Beide verwenden unterschiedliche Vorgehensweisen und Notationen, um den Ablauf und das Verhalten von Systemen zu beschreiben. Genau genommen haben beide Seiten auch oft widersprüchliche Zielsysteme: Stabilität, Beherrschbarkeit, geringer Wartungsaufwand treiben die Techniker, schnelle Reaktionen auf Marktanforderungen und Flexibilität sind elementar für den Erfolg der Fachseite. Konflikte zwischen Fach- und IT-Abteilung durch unpräzise Ausdrucksweisen, unterschiedliche Begriffsspezifikationen oder mangelndes gegenseitiges Verständnis sind somit vorprogrammiert. Ziel der modellgestützten Entwicklung muss es folglich sein, sowohl die Dokumentation der betriebswirtschaftlichen Anforderungen als auch die Modellierung implementierungsnaher Konzepte mittels eines durchgängigen Vorgehensmodells und unter Anwendung definierter Transformationsroutinen so miteinander zu verzahnen, dass eine systematische Verfeinerung der Geschäftsprozessmodelle bis hin zur Spezifikation betrieblicher Software ermöglicht wird. Nur so können die Informationen über die veränderten Prozesse und die daraus resultierenden Folgen für die IT-Infrastruktur weitestgehend verlustfrei und flexibel für die Entwicklung von betrieblichen Anwendungen genutzt werden. In den folgenden Ausführungen wird anhand des Fallbeispiels der Ticketreservierung eines Kinounternehmens ein durchgängiger Weg von der Prozessarchitektur über die betriebswirtschaftliche Anforderungsdefinition zur technischen Realisierung aufgezeigt. Aufgrund der Existenz zahlreicher Veröffentlichungen und Softwarelösungen im Bereich Systemdesign und Generierung (z. B. [StVö05], [PeMe06] ) ist der Fokus dieses Artikels auf die Vorgehensweise gerichtet, aus einem Geschäftsprozessmodell ein objektorientiertes Analysemodell abzuleiten, welches wiederum als Grundlage für die Implementierung dient.

2

Model Driven Architecture (MDA)

Die MDA ist eine Initiative der Object Management Group (OMG), die dazu den „MDA Guide” [OMG03] verabschiedet hat. In diesem werden die wesentlichen Konzepte und Vorgehensweisen bei der modellbasierten

Modellgestützte Entwicklung betriebswirtschaftlicher Software

63

Konstruktion von Softwaresystemen skizziert. Zentrale Bedeutung kommt dabei den Begriffen Modell, Metamodell und Modelltransformation zu. Die Grundidee der MDA besteht darin, Software in einem oder mehreren Modellen zu spezifizieren, die durch sukzessives Transformieren und Verfeinern schlussendlich zu einem ausführbaren Softwaresystem auf einer bestimmten Plattform reifen. Durch Automatisieren der Transformationsschritte kann Software kompakt und redundanzarm spezifiziert werden, was die Effizienz bei der Entwicklung und die Qualität der Systeme steigert. Informationen, die spezifisch für eine bestimmte Transformationsrichtung sind, werden ausgelagert, um die Modelle plattformunabhängig und somit portabel und langlebig zu halten. Die MDA sieht dazu zwei Arten von Modellen vor: Fachlich orientierte, plattformunabhängige PIMs (Platform Independent Models) und technisch orientierte, plattformspezifische PSMs (Platform Specific Models). PIMs können mithilfe spezieller Konvertierungsroutinen weitgehend automatisch in PSMs der gewünschten Zielplattform (z. B. J2EE) überführt werden. PSMs bilden dann die Grundlage für die Generierung der eigentlichen Anwendung. Auf diese Weise kann eine Anwendung leicht auf eine andere Plattform portiert werden. Die Kernidee der MDA, Anwendungsdomänen unabhängig von konkreten Technologien zu beschreiben, ist für die Wirtschaftsinformatik nicht neu und wurde bereits vor einiger Zeit thematisiert. Beispielsweise verfolgt das von SCHEER entwickelte Konzept der Architektur integrierter Informationssysteme (ARIS) [Sche02a] ebenso die Zielsetzung, betriebswirtschaftliche Software unabhängig von vorherrschenden technologischen Entwicklungszyklen zu beschreiben. Während SCHEER die Art des Übergangs von einer fachkonzeptionellen Beschreibung zur technischen Realisierung offen lässt, verfolgt die MDA den Ansatz, die technische Realisierung weitgehend aus einer fachlichkonzeptionellen Beschreibung zu generieren [FeLo03a]. Insgesamt stellt die MDA einen technologieinduzierten Ansatz einer modellorientierten Softwareentwicklung dar, der den in der Wirtschaftsinformatik primär anwendungsorientierten Ansatz einer modellbasierten Beschreibung von Informationssystemen ergänzt [FeLo03a]. Gleichzeitig kann insbesondere die wirtschaftsinformatische Forschung der Referenzmodellierung sowohl inhaltlich mit Hilfe von Referenzmodellen als auch methodisch – bspw. mit Methoden zur konfigurativen Referenzmodellierung [BDKK02] – interessante Impulse für die Weiterentwicklung der MDA geben. So liegen für verschiedene Anwendungsdomänen in der Wirtschaftsinformatik Referenzmodelle vor [FeLo03b], die als PIM eingesetzt werden können. Darüber hinaus können die in der Wirtschaftsinformatik bekannten Methoden zu Referenzmodellierung [FeLo02] die Aus-

64


gestaltung des Prozesses der Modelltransformation in der MDA befruchten [FeLo03a].

3

Anwendungsfelder der MDA

Im folgenden Abschnitt wird anhand von zwei erfolgskritischen Anwendungsfeldern der MDA betrachtet, wie die MDA konkrete, signifikante und messbare Vorteile bringen kann. Beide Anwendungsfelder dürften hierbei für alle Unternehmen und Organisationen interessant sein, die in ihren Kerngeschäftsfeldern betriebliche IT-Systeme einsetzen [Buch03]. 3.1 Umsetzung von Geschäftsprozessen in IT-Systeme Gerade auf dem Weg von der Erfassung und Dokumentation von Geschäftsprozessen bis hin zu deren Umsetzung in einem IT-System fallen immer wieder erhebliche vermeidbare Kosten an. Es beginnt damit, dass durch die mangelhafte Verwendung eindeutiger Spezifikations- und Beschreibungsmittel Mehrdeutigkeiten entstehen, die sich schließlich in inkonsistenten oder gar fehlerhaften Systemen niederschlagen. Ein weiterer hoher Anteil vermeidbarer Kosten entsteht bei der eigentlichen Überführung der Analyseergebnisse in ein IT-System. Durch die aufwändige manuelle Umsetzung umfangreicher, schematischer oder fest durch die Architekturdefinition vorgegebener Systemteile leiden Effizienz und Qualität bei der Produktion des Softwaresystems. In den letzten Jahren entstanden verschiedene Trends, die versuchten diese Probleme zu lösen. Geschäftsprozess-Modellierungswerkzeuge spielten dabei eine entscheidende Rolle. Mit der Zeit stellte sich jedoch heraus, dass der alleinige Einsatz solcher Werkzeuge ohne eine entsprechende Anbindung an die IT-Landschaft keine echte Lösung darstellt. Die MDA hingegen propagiert das Vorhandensein einer durchgängigen Werkzeug- und Modellierungskette, die von der Analyse bis hin zum Design, zur Implementierung, zum Test und zum Deployment den gesamten Software-Lebenszyklus ausreichend abdeckt. 3.2 Investitionsschutz und Technologie-Lebenszyklen Das zweite Problem, mit dem sich in den letzten Jahrzehnten viele Softwareentwicklungsorganisationen konfrontiert sehen, ist die Zwangskopplung der Lebenszyklen von IT-Systemen mit der zu Grunde liegenden Technologie. Diese Kopplung bedingt die regelmäßige Neugestaltung und


65

Anpassung der Systeme, wodurch immense Kosten verursacht werden, die oftmals in keinem vernünftigen Verhältnis zur erzielten Reduzierung der Geschäftsprozesskosten stehen. Hier spielt neben den reinen Prozesskosten oft auch der durch Markt und Kunden erzeugte Druck, zeitgemäße Technologien zu verwenden, eine erhebliche Rolle. Ein Unternehmen ohne entsprechende E-Business-Systeme wäre heute beispielsweise undenkbar. Gleichzeitig steigen ironischerweise sogar die Kosten für den Einsatz alternder Technologien, da Know-how und Support nicht mehr im gewohnten Umfang verfügbar sind. Die Kosten eines Umstiegs werden substanziell durch die Portierung vorhandener Implementierungen beeinflusst. Hier macht sich bemerkbar, mit welchem Grad der Formalisierung und auf welchen Abstraktionsniveaus die zu portierenden Anwendungen spezifiziert wurden. Liegen die Systeme praktisch nur als technische Artefakte in einer bestimmten Plattform – etwa als eine Reihe von C++-Dateien und SQL-Skripte – vor, so verursacht die Umstellung, z. B. auf die J2EE-Plattform, hohen manuellen Aufwand. Liegen hingegen zusätzlich Modelle der Anwendung vor, die auf einem abstrakteren Niveau die Prozesse und Komponenten, ihre Schnittstellen, ihr Zusammenspiel und ihr dynamisches Verhalten beschreiben, so kann die Umstellung in weiten Teilen automatisiert werden. Durch die bei der MDA angestrebte Unabhängigkeit von Anwendungsdömanen und konkreten Technologien wird die Langlebigkeit und damit der Wert der entwickelten Softwaresysteme erheblich erhöht. Die entwickelten Modelle werden dabei – analog zu Referenzmodellen – zu wiederverwendbaren Elementen eines Softwaresystems und dienen der Entkopplung der völlig unterschiedlichen Lebenszyklen von Geschäftsprozessen einerseits und der zu ihrer Implementierung eingesetzten Technologien andererseits.

4

Modellgestützte Entwicklung am Anwendungsbeispiel Ticketreservierung

Im folgenden Abschnitt wird am Anwendungsbeispiel der Ticketreservierung ein holistisches Konzept zur modellgestützten Softwareentwicklung vorgestellt, welches auf Basis in ARIS erstellter Geschäftsmodelle und davon derivierter UML-Modelle eine Software implementiert. Der Model Driven Architecture entsprechend werden zum einen Anwendungen auf der Grundlage plattformunabhängiger Modelle entwickelt, zum anderen die Funktionalitäten unabhängig von der technischen Realisierung spezifiziert. Erst beim letzten Schritt von der Funktionsspezifikation zur Codegenerierung werden mithilfe geeigneter Werkzeuge plattformspezifische In-

66


formationen hinzugefügt. Abbildung 1 zeigt die Architektur, welche den Ablauf und Zusammenhang der einzelnen Phasen darstellt.

Abbildung 1: Modellgestützte Entwicklung betriebswirtschaftlicher Software

In einem ersten Schritt werden die Geschäftsprozesse mittels Geschäftsprozessmodellen erfasst um als Grundlage für die sich anschließende Phase der Anforderungsanalyse dienen zu können. Hierzu wird ein Übergang von den Geschäftsprozessmodellen zur UML-Notation geschaffen. In beiden Fällen entstehen dabei Modelle, die sowohl von der gewählten Systemarchitektur als auch von der Implementierungsplattform unabhängig sind. Das Systemdesign erfolgt dann auf Grundlage des Analysemodells. In einem abschließenden Schritt wird letztlich das Designmodell mittels eines Codegenerators in Quellcode umgesetzt. Zur Veranschaulichung der Vorgehensweise bei der modellgestützten Entwicklung betriebswirtschaftlicher Software wurde ein relativ simples Anwendungsbeispiel ausgewählt, um einerseits die Durchgängigkeit des Entwicklungsprozess von fachkonzeptionellen Modellen über UML-Modelle bis hin zum Code greifbarer darlegen zu können und andererseits nicht die Anschaulichkeit der Vorgehensweise durch die Komplexität eines Realszenarios zu beeinträchtigen. Als Anwendungsbeispiel wurde dabei ein fiktives Szenario ausgewählt: Die Beispielsfirma Movie Palace AG möchte ein Softwaresystem für ihre Ticketreservierung einführen. Zu die-


67

sem Zweck werden die Geschäftsprozesse des Unternehmens mit ARIS erhoben und analysiert. Aus den erfassten Prozessen werden mit Hilfe von ARIS UML Diagramme abgeleitet. Im Anschluss werden die Daten des Systemdesigns über eine XMI-Schnittstelle an ein Codegenerator-Framework weitergegeben. 4.1 Geschäftsprozessanalyse Es ist längst zum Allgemeingut geworden, dass es für die Entwicklung betriebswirtschaftlicher Software erforderlich ist, zunächst die Geschäftsprozesse zu betrachten, die mit dem zu entwickelnden System unterstützt werden sollen. Geschäftsprozesse und Software sind möglichst optimal aufeinander abzustimmen. Das eigentliche Ziel der Softwareentwicklung ist nicht die Fertigstellung eines funktionierenden Softwaresystems, sondern die Verbesserung der Prozesse und damit die Unterstützung der Unternehmensziele. Dies kann sich etwa in Form geringerer Kosten, kürzerer Durchlaufzeiten oder höherer Umsätze niederschlagen – oder indem beispielsweise ganz neue, IT-basierte Dienstleistungen realisiert werden [Allw05]. Aus betriebswirtschaftlicher Sicht werden Prozesse meist in natürlicher Sprache, mit Hilfe von einfachen Flowcharts oder – wenn ein ganzheitliches und systematisches Prozessmanagement erfolgt – in Form von Geschäftsprozessmodellen dargestellt. Vom Standpunkt der Softwareentwicklung dienen die Geschäftsprozessmodelle hauptsächlich der Kommunikation mit den Fachabteilungen und als Grundlage für die Anforderungsanalyse der zu erstellenden betriebswirtschaftlichen Software. Aus Sicht der Fachabteilung ist die Softwareentwicklung nur eine der vielen Anwendungsdomänen der Geschäftsprozessanalyse. Weitere Anwendungsdomänen sind bspw. Geschäftsprozessoptimierung, Einführung von ERP-Systemen, Prozesskostenrechnung oder ISO-9000-Zertifizierungen [Sche02b]. In der Praxis hat sich ARIS weltweit als Quasi-Standard zur Geschäftsprozessmodellierung etabliert. Einer der der Kerndiagrammtypen der ARISMethode ist die Ereignisgesteuerte Prozesskette (EPK). Die Methode der EPK wurde im Jahr 1991 am Institut für Wirtschaftsinformatik (IWi) der Universität Saarbrücken für die Geschäftsprozessmodellierung entwickelt [Sche01]. Die EPK ist eine semiformale, grafische Modellierungssprache und dient zur Beschreibung von Prozessen. Geschäftsprozesse werden dabei als eine Folge von Ereignissen und Funktionen modelliert. Sie enthalten alle für die Betrachtung von Abläufen notwendigen Informationen. Für einzelne Prozesselemente können prozessbeschreibende Attribute hinterlegt werden. Die Hierarchisierung von komplexen Strukturen aus Gründen

68


der Übersichtlichkeit ist ebenfalls möglich. Somit lassen sich Prozesse in Teilprozesse aufspalten, die wiederum miteinander verbunden werden können. Ereignisse lösen Funktionen nicht nur aus, sondern werden wiederum von Funktionen als Ergebnisse erzeugt. Durch die Einführung von logischen Verknüpfungen lässt sich eine EPK zu beliebig komplexen Ablaufstrukturen erweitern. Für den Einsatz der ARIS-Methode zur Geschäftsprozessanalyse im Rahmen der modellbasierten Softwareentwicklung lässt sich eine Vielzahl von Argumenten anführen. ARIS wartet mit einer modellbasierten Beschreibung aller relevanten Aspekte eines Unternehmens in einer zentralen Datenbank auf. Es entstehen somit grafische Modelle, die sich wesentlich leichter auf Konsistenz und Vollständigkeit überprüfen lassen, als beispielsweise eine lose Sammlung von Word-Dokumenten oder PowerpointFolien. Des Weiteren ist die ARIS-Methodik im Gegensatz zur Unified Modeling Language sowohl für Mitarbeiter von Fachabteilungen als auch für Softwareentwickler gleichermaßen leicht verständlich. Sie fördert folglich die Kommunikation zwischen den Beteiligten und eignet sich somit für eine gemeinsame Anforderungsanalyse. Weiterhin ermöglicht ARIS den Fachabteilungen durch seine leicht greifbaren Modellierungskonventionen ihre Geschäftsprozesse selbst zu modellieren und so eine aktive Rolle im Softwareentwicklungsprozess einzunehmen. Reservierungswunsch eingegangen

Callcenter-Agent Kino

Vorstellung suchen

Film

Vorstellung

Vorstellungstermin

Legende

Ereignis Vorstellung konnte gefunden werden

Funktion Callcenter-Agent

Personentyp

Vorstellung

Ticketanzahl

Anzahl freier Plätze mit Anzahl gewünschter Tickets vergleichen

Fachbegriff

XOR-Regel Reservierung ist möglich

Reservierung ist nicht möglich

Vorstellung konnte nicht gefunden werden

Abbildung 2: Ereignisgesteuerte Prozesskette


69

Die EPK in Abbildung 2 zeigt bspw. vereinfacht, wie in einem Callcenter einer Kinofirma ein Reservierungswunsch für Kinokarten überprüft wird. Geht ein Reservierungswunsch im Callcenter ein, so wird zunächst anhand der Fachbegriffe Film, Vorstellungstermin und Kino überprüft, ob eine entsprechende Vorstellung vorhanden ist. Diese Überprüfung kann entweder erfolgreich sein – wenn eine entsprechende Vorstellung existiert – oder nicht. Anschließend muss überprüft werden, ob die gewünschte Ticketanzahl für die vorgesehene Vorstellung noch reservierbar ist, woraufhin ggf. der Reservierungsvorgang angestoßen wird. Sämtliche in der EPK visualisierten Objekte und deren Beziehungen sind in einem zentralen Repository abgelegt. So taucht im vorliegenden Beispiel zweimal der Callcenter-Agent als ausführender Personentyp einer Funktion auf. Dabei handelt es sich jedoch um ein einziges Datenbankelement. Dies ermöglicht eine Vielzahl von Auswertungsmöglichkeiten, bspw.: „Welche Funktionen werden von einem Personentyp im Unternehmen ausgeführt?“, und ist somit auch Voraussetzung für die Verknüpfung von Geschäftsprozess- und Anforderungsanalyse. 4.2 Anforderungsanalyse Zwei wesentliche Anforderungen stehen bei der Umsetzung fachlicher Anforderungen in betriebswirtschaftliche Anwendungssysteme im Vordergrund. Einerseits geht es darum, sicherzustellen, dass die erstellten Anwendungen die Unternehmensprozesse möglichst optimal unterstützen, d. h. die von der Fachabteilung definierten Anforderungen möglichst fehlerfrei umgesetzt werden. Andererseits sollen die Produktivität und die Geschwindigkeit der Anwendungserstellung erhöht werden, so dass die betriebswirtschaftliche Software beispielsweise schnell und problemlos an eine erforderliche Prozessänderung angepasst werden kann. Ausgangspunkt von geschäftsprozessorientiertem Anforderungsmanagement ist ein fundiertes Prozesswissen im Unternehmen. Idealerweise wurden die zu unterstützenden Geschäftsprozesse im Einklang mit einem unternehmensweiten Prozessmanagement bereits analysiert und konzipiert. Wichtige Prozessinformationen liegen bereits in Form von Modellen vor und sollten für das Design der IT-Unterstützung genutzt werden. Die Dokumentation dieser betriebswirtschaftlich orientierten Geschäftsprozessmodelle erfolgt jedoch nicht in der Sprache der IT. So wie sich ARIS als Modellierungsmethode für Geschäftsprozesse etabliert hat, gilt dies für die Unified Modeling Language (UML) im Umfeld objektorientierter Softwareentwicklung. Nach der Definition der Object Management Group ist die UML „eine standardisierte Notation und Semantik zur Visualisierung,

70


Konstruktion und Dokumentation von Modellen für die objektorientierte Softwareentwicklung“ [Oest98]. Die UML bietet technisch orientierten Mitarbeitern die Möglichkeit die Fachlogik eines zu entwickelnden Systems in standardisierten Modellen zu erfassen. Da die UML ursprünglich für die Entwicklung von Softwaresystemen konzipiert wurde, sind die relevanten Beschreibungs- und Darstellungsmittel jedoch nicht auf die Prozessmodellierung ausgerichtet. Die Herausforderung besteht folglich darin, beide Modellierungswelten zu integrieren und methodisch so miteinander zu verknüpfen, dass beide Sprachwelten ohne Informationsverlust ineinander überführt werden können. Im folgenden werden anhand des Anwendungsbeispiels der Ticketreservierung zwei sich ergänzende Möglichkeiten aufgezeigt, wie aus einem Geschäftsprozessmodell ein UML-Analysemodell abgeleitet werden kann und somit ein Mapping zwischen der fachlichen Sicht und der IT-Welt ermöglicht wird: «systemUseCase»

«include»

Vorstellung suchen

«businessUseCase» Reservierungswunsch bearbeiten «include» «systemUseCase» Reservierung durchführen

«include»

«businessUseCase»

«include»

«businessUseCase»

Ticketreservierung

«include»

Systembenutzer anmelden

«systemUseCase» Anmeldung durchführen

Callcenter-Agent

«include»

«include» «systemUseCase» «include»

Reservierung suchen

«businessUseCase» Reservierung stornieren

«include»

«systemUseCase» Stornierung durchführen

Abbildung 3: Anwendungsfallmodell

Zunächst werden in den Geschäftsprozessen alle Funktionen identifiziert, die später im Softwaresystem implementiert werden sollen. Die identifizierten Funktionen werden mittels vordefinierter Transformationen in ein UML-Anwendungsfalldiagramm übertragen und dort als Anwendungsfälle


71

betrachtet. So werden beispielsweise beim Transformationsvorgang automatisch alle den identifizierten Funktionen zugeordneten Personentypen ermittelt und als Akteure in das Anwendungsfallmodell platziert. Abbildung 3 stellt das Ergebnis einer solchen Transformation dar. Dabei werden IT-relevante Funktionen als Systemanwendungsfälle (systemUseCase) stereotypisiert, während der übergeordnete Geschäftsprozess als Geschäftsanwendungsfall (businessUseCase) deklariert wird. Die in Abbildung 3 rechts unterhalb der einzelnen Anwendungsfälle erkennbaren Symbole bedeuten, dass die Anwendungsfälle durch weitere UML-Diagramme hinterlegt sind. Nachdem die abzudeckenden Anwendungsfälle nun erfasst sind, kann eine Detaillierung dieser Anwendungsfälle durch weitere UML-Modelltypen erfolgen. Beispielsweise kann der in Abbildung 3 ersichtliche Systemanwendungsfall „Vorstellung suchen“ mittels eines UML-Aktivitätsdiagramms hinterlegt werden, um den Ablauf des Systemanwendungsfalls zu beschreiben. Weitere UML-Diagramme wie Zustands-, Kollaborations- und Sequenzdiagramme können ebenfalls innerhalb der Anforderungsanalyse verwendet werden, um weitere Spezifikationen des Systemverhaltens darzustellen. 4.3 Analyseklassenmodell Ein zweiter Anknüpfungspunkt für die Anforderungsanalyse im Rahmen der modellgestützten Softwareentwicklung stellen die in Abbildung 2 dargestellten Ein- und Ausgabeparameter der EPK-Funktionen – die so genannten Fachbegriffe – dar. Diese werden im Rahmen der Geschäftsprozessmodellierung üblicherweise in einem Fachbegriffsmodell zusammengefasst, da es wesentlich für den Erfolg eines Softwareentwicklungs-Projekts ist, dass alle Beteiligten ein gemeinsames Verständnis der im Projekt genutzten Fachbegriffe besitzen. Diese so einfach klingende Forderung findet in der Praxis jedoch häufig zu wenig Beachtung. In Projekten zeigt sich dann, dass die beteiligten Bereiche (Fachbereich und IT) gleiche Begriffe grundlegend verschieden interpretieren. Für die effiziente Abwicklung von Projekten ist dies von großem Nachteil, da so regelmäßig Reibungsverluste auftreten und Missverständnisse beseitigt werden müssen. Durch die Nutzung von zentralen Fachbegriffsmodellen wird dies weitestgehend verhindert. Bei der Anforderungsanalyse untersucht man die festgelegten Fachbegriffe dahingehend, welche von ihnen als Kandidaten für Fachklassen und welche eher als Fachattribute in Frage kommen. Die so ermittelten Fachbegriffe und Fachattribute werden in einem Diagramm platziert und mit dem jeweiligen Fachbegriff verknüpft. Abbildung 4 zeigt einen Ausschnitt eines solchen Fachbegriffmodells.

72


Film

Film

Kino

Kino

Kinosaal

Kinosaal

Legende

Fachbegriff Klasse Kinosaalnummer

saalnummer

Attribut Vorstellung

Vorstellungstermin

Vorstellung

vorstellungstermin

Abbildung 4: Fachbegriffsmodell

In einem nächsten Schritt werden die einzelnen Fachklassen mittels Transformationen in ein UML-Klassendiagramm übertragen, um ihnen dort die Fachattribute zuzuordnen und die Klassen mittels binärer Assoziationen in Beziehung zu setzten. Abbilddung 5 zeigt das Ergebnis des Übertragungsvorgangs. Das Analyseklassenmodell stellt einen zentralen Baustein der Anforderungsanalyse dar und ist die Basis für eine Systemimplementierung. Deshalb ist die Verbindung zwischen EPK und Analyseklassenmodell für die Integration von Objektorientierung und Prozessorientierung von besonderer Bedeutung. Die Verbindung von Analyseklassenmodell und EPK ermöglicht die Festlegung, welche Objekte durch eine Geschäftsfunktion erzeugt, verändert oder vorausgesetzt werden, und welche Operationen und Attribute notwendig sind. Dadurch kann, basierend auf der Prozessbeschreibung der EPK, das Objektschema entwickelt werden. Die Beziehungen zwischen den einzelnen Geschäftsklassen innerhalb des UML-Klassendiagramms beschreiben die strukturellen Abhängigkeiten. In Abbildung 5 stellt sich dies wie folgt dar: Jedes Kino besitzt mindestens einen Kinosaal und in einem Kinosaal kann eine beliebige Zahl von Vorstellungen gezeigt werden. Weiterhin wird eine Vorstellung immer genau einem Kinosaal zugeordnet. Die Fachklassen können nun in einem nächsten Schritt um weitere fachliche Attribute und Operationen angereichert werden, wie dies in Abbildung 5 erkenntlich wird.


73

«businessClass» «businessClass»

Kinosaal 1

Kino name: String

1..* nummer: Integer anzahlPlätze: Integer vorstellungen(in film: Film): Vorstellung[*] {query} vorstellungen(in film: Film, in termin: Datum): Vorstellung {query}

vorstellungen(in film: Film): Vorstellung[*] {query} *

1

*

*

«businessClass» Film

1

Vorstellung

titel: String spieldauer: Integer

«businessClass»

«businessClass»

*

vorstellungstermin: Datum = null anzahlVerkaufterTickets: Integer einplanen(in vorstellungstermin: Datum) stornieren() film(): Film {query} vorstellungstermin(): Datum {query} freiePlätze(): Integer {query} 1 reservierungErzeugen(in ticketanzahl: Integer): Reservierung reservierungenStornieren() reservierungHinzufügen(in reservierung: Reservierung)

*

Ticket

1

* «businessClass» Reservierung anzahlReservierterTickets: Integer reservierungsnummer: Integer «create» erzeugen(in vorstellung: Vorstellung, in tickets: Integer): Reservierung

Abbildung 5: Analyseklassenmodell

4.4 Systemdesign und Generierung Die Erstellung des Systemdesigns basiert auf den Ergebnissen der Anforderungsanalyse. Eine Systemarchitektur wird festgelegt, Abläufe und Status innerhalb der Softwarekomponenten werden unter Verwendung verschiedener Typen von UML-Diagrammen beschrieben. Diese Informationen werden dann in einem nächsten Schritt in den Codegenerator eingespeist. Zur Codegenierung werden dabei existierende Codegeneratoren angepasst und entweder über das standardisierte Austauschformat XMI (XML Metadata Interchange) für objektorientierte Modelle angebunden, oder die Anbindung erfolgt direkt über die UML Designer Plugin-Schnittstelle. Erst bei der Konfiguration des Codegenerators wird somit eine Entscheidung über die Anwendungsfamilie bzw. Cartridge, Plattform und Programmiersprache getroffen. Der vom Codegenerator produzierte Code bietet zudem geschützte Bereiche, in denen letztendlich die Implementierung der Logik vorgenommen werden kann. D. h. in der Regel wird mittels eines Codege-

74


nerators ein Skelett bzw. ein Anwendungsrahmen generiert, in den der Entwickler manuell entwickelten Anwendungscode einbringt. Die Stellen, an denen manuell entwickelter Code eingebaut wird, und die Art und Weise, wie dieser Code strukturiert ist, werden dabei von der Plattformarchitektur und dem generierten Anwendungsrahmen vorgegeben. Da der durch den Codegenerator produzierte schematische Code zumeist mehr als die Hälfte der Codemasse ausmacht, werden durch diese konsequente Automatisierung die möglichen Fehlerquellen bei der Softwareentwicklung erheblich gesenkt. Letztlich können aus dem generierten Code, wie in Abbildung 6 beispielhaft ersichtlich, auch die benötigten Benutzeroberflächen entworfen werden.

Abbildung 6: Benutzeroberfläche der Ticketreservierung

5

Fazit und Ausblick

In diesem Artikel wurde aufgezeigt, wie Unternehmensprozesse als Basis für die Entwicklung betriebswirtschaftlicher Softwaresysteme genutzt werden können. Durch eine Transformation fachlich orientierter Modelle in technische Verhaltensspezifikationen wurde ein Weg aufgezeigt, wie ge-


75

schäftsprozessorientiertes Anforderungsmanagement für eine Softwaresystemgestaltung praxisorientiert etabliert werden kann. Dabei wird durch den Einsatz von ARIS in der Entwicklung betriebswirtschaftlicher Software der Nutzen von Prozessmodellen weiter gesteigert. Die Inhalte der Modelle werden direkt zur Verbesserung der operativen Abläufe herangezogen. Das Ergebnis ist die passgenaue Erstellung von Software. Veränderungen in den Prozessmodellen auf Fachebene haben transparente Auswirkungen auf technische Beschreibungen und damit auch auf laufende Systeme. Das betriebswirtschaftliche und technische Wissen wandert aus Köpfen und Quellcode in wiederverwendbare Modelle. KMUs können somit kosten- und zeiteffizient bestehende und kommende Standards auch für bereits vorhandene Systeme nutzen. Konkret wird dazu mittels Modellierungswerkzeugen und Transformationsroutinen eine Verbindung zwischen ereignisgesteuerten Prozessketten, Fachbegriffsmodellen und UML-Diagrammen hergestellt. Hierdurch wird der informationsverlustfreie Übergang von der fachlichen Geschäftsprozessmodellierung zu den Implementierungsmodellen der UML möglich. Diese Kombination bildet eine zukunftsweisende Basis für die modellbasierte Entwicklung auf Grundlage eines durchgängigen Vorgehensmodells, das die klassischen Softwareentwicklungsphasen Entwurf, Implementierung und Systembetrieb kohärent miteinander verknüpft. Prozesse und Werkzeuge rund um die MDA sind bereits heute ein erheblicher Gewinn in allen erdenklichen Situationen bei der Softwareentwicklung. Gleichzeitig steht die MDA am Beginn einer spannenden Zeit. Projiziert man die möglichen Weiterentwicklungen unter Berücksichtung der bereits heute realisierbaren Vorteile in die Zukunft, ergibt sich ein beeindruckendes Potenzial. Insbesondere die Kombination von Serviceorientierten Architekturen (SOA) und den Ansätzen der modellbasierten Softwareentwicklung verspricht zum einen die konsequente Kapselung der Funktionalitäten von Softwaresystemen und zum anderen deren Wiederverwendbarkeit in Dienstform, was für eine schnelle Anpassbarkeit von IT Systemen an sich ändernde Geschäftsprozesse eine entscheidende Rolle spielt. Des weiteren dürfte auch im Zusammenspiel von Referenzmodellierung und MDA ein nicht unerhebliches Marktpotenzial stecken, insbesondere wenn man berücksichtigt, dass wiederverwendbare Referenzmodelle in verschiedenen Anwendungsdomänen der Wirtschaftsinformatik (z. B. Personalverwaltung, Logistik, Buchhaltung, Zahlungssysteme) als PIM eingesetzt werden können.

76


Literaturverzeichnis [Allw05] Allweyer, T.: Maßgeschneiderter Methodeneinsatz für die Entwicklung betriebswirtschaftlicher Software. In: Scheer, A.-W.; Wolfram, J.; Wagner, K. (Hrsg.): Vom Prozessmodell zu lauffähigen Anwendungen. Berlin et al. 2005, S. 173-195. [BDKK02] Becker, J.; Delfmann, P.; Knackstedt, R.; Kuropka, D.: Konfigurative Referenzmodellierung. In: Becker, J.; Knackstedt, R. (Hrsg.): Wissensmanagement mit Referenzmodellen. Konzepte für die Anwendungssystem- und Organisationsgestaltung. Heidelberg 2002, S. 25-144. [Buch03] Bucholdt, C.: Ökonomische Entscheidungskriterien für den Einsatz der MDA. Objektspektrum 34 (2002) 2, S. 20-23. [FeLo02] Fettke, P.; Loos, P.: Methoden zur Wiederverwendung von Referenzmodellen – Übersicht und Taxonomie. In: Becker, J.; Knackstedt, R. (Hrsg.): Referenzmodellierung 2002. Methoden – Modelle – Erfahrungen. Münster 2002, S. 9-33. [FeLo03a] Fettke, P.; Loos, P.: Model Driven Architecture (MDA). Wirtschaftsinformatik 45 (2003) 5, S. 555-559. [FeLo03b] Fettke, P.; Loos, P.: Classification of reference models – a methodology and its application. Information Systems and e-Business Management 1 (2003) 1, S. 35-53. [JoWa05] Jost, W.; Wagner, K.: Der Weg vom Prozess zur Anwendung. In: Scheer, A.-W.; Wolfram, J.; Wagner, K. (Hrsg.): Vom Prozessmodell zu lauffähigen Anwendungen. Berlin et al. 2005, S. 17-31. [Koch02] Koch, T.: Model Driven Architecture – Eine Einführung. Objektspektrum 34 (2002) 2, S. 27-34. [Oest98] Oestereich, B.: Objektorientierte Softwareentwicklung. Analyse und Design mit der Unified Modeling Language. München 1998. [OMG03] Object Management Group: MDA Guide Version 1.0.1. 2003. http:// www.omg.org/docs/omg/03-06-01.pdf) [PeMe06] Petrasch, R.; Meimberg, O.: Model Driven Architecture – Eine praxisorientierte Einführung in die MDA. Heidelberg 2006. [Sche01] Scheer, A.-W.: ARIS: Modellierungsmethoden, Metamodelle, Anwendungen. 4. Auflage, Berlin et al. 2001. [Sche02a] Scheer, A.-W.: ARIS: Vom Geschäftsprozess zum Anwendungssystem. 4. Auflage, Berlin et al. 2002. [Sche02b] Scheer, A.-W.: ARIS: Von der Vision zur praktischen Geschäftsprozesssteuerung. In: Scheer, A.-W.; Wolfram, J. (Hrsg.): ARIS in der Praxis – Gestaltung, Implementierung und Optimierung von Geschäftsprozessen. Berlin et al. 2002. [StVö05] Stahl, T.; Völter, M.: Modellgetriebene Softwareentwicklung. Heidelberg 2005.

Controlling konfigurativer Referenzmodelle

Christian Seel, Peter Loos Abstract: Der Einsatz von Referenzmodellen kann die Softwareentwicklung deutlich beschleunigen. Allerdings stellt die Anpassung von Referenzmodellen an die spezifischen Gegebenheiten ihres Einsatzes einen aufwändigen Prozess dar. Konfigurationsmechanismen, die in die Referenzmodelle eingebettet werden, leisten einen wesentlichen Beitrag zur Reduzierung dieses Aufwands. Jedoch ist der Erfolg der Verwendung von Referenzmodellen und Konfigurationsmechanismen wesentlich von deren Passgenauigkeit auf den jeweiligen Anwendungsfall sowie von ihrer Aktualität abhängig. Um beides zu gewährleisten, ist es erforderlich, das Referenzmodell sowie die Konfigurationsmechanismen auf ihre Passgenauigkeit für spezifische Anwendungsfälle zu überprüfen und entsprechende Anpassungen vorzunehmen. Neben diesen beiden Aufgaben umfasst das in diesem Kapitel vorgestellte Konzept zum Controlling konfigurativer Referenzmodelle die Unterstützung bei der Planung von Softwareentwicklungsprojekten.

1

Motivation für das Controlling konfigurativer Referenzmodelle

Die in den vorhergehenden Beiträgen vorgestellten Konzepte und Mechanismen zur Adaption von Referenzmodellen haben das Ziel, den Aufwand bei der Konstruktion fachkonzeptioneller Modelle für die Softwareentwicklung zu verringern und gleichzeitig die Qualität der so erstellten Informationsmodelle zu erhöhen [BeSc04; FeLo07]. Das Gelingen dieser Aufgabe hängt maßgeblich von der Qualität der verwendeten Referenzmodelle sowie deren passgenauer Adaption an die spezifischen Gegebenheiten des jeweiligen Anwendungsfalls ab. Insbesondere für kleine und mittlere Softwareunternehmen (KMSU) stellt die Individualisierung von Software gemäß den Bedürfnissen ihrer Kunden ein wesentliches Differenzierungsmerkmal zur von Großunternehmen angebotenen Standardsoftware

78

Christian Seel, Peter Loos

dar. Daher ist das Customizing der von KMSU angebotenen Software ein zentraler Bestandteil in deren Produktstrategie. Falls im Rahmen des Customizings mehrere Varianten der Referenzmodelladaption für einen bestimmten Modellierungskontext zur Verfügung stehen, ist die Variante auszuwählen, die den größten Beitrag zur Erreichung der mit der Einführung der Software verfolgten Zielen aufweist. Daher ist eine zielabhängige Bewertung der Adaptionsalternativen durchzuführen. Des Weiteren ist, ähnlich zu der Entwicklung von Individualsoftware, auch beim Customizing von Standardsoftware, eine Überprüfung notwendig, ob die vom Kunden vorgegebenen Anforderungen an die Software erfüllt werden. Daher ist die Ergänzung der vorgestellten Konfigurationstechniken um weitere Controllingkonzepte notwendig [HeSe04, S. 28]. Eine dritte Herausforderung besteht aus Sicht des Controllings in den Veränderungen des Umfelds, in dem die Software eingesetzt wird. So führen beispielsweise neue Technologien wie RFID zu Veränderungen in Prozessen oder der Datenhaltung, die wiederum Veränderungen an der eingesetzten Software bedingen und sich daher auch in den fachkonzeptionellen Modellen, die den Ausgangspunkt für die Softwareentwicklung bilden, widerspiegeln müssen. Dementsprechend kommt der Aktualität und Relevanz der Referenzmodelle, der Passgenauigkeit der Konfigurationsmechanismen und der Effektivität und Effizienz des Softwareentwicklungs- und -anpassungsprozesses große Bedeutung zu. Diese Anforderungen lassen sich nur durch permanente Überprüfung und die gegebenenfalls notwendigen Anpassungen erfüllen. Daher ist die Erweiterung der bisher vorgestellten Modellierungstechniken um ein Konzept zum Controlling konfigurativer Referenzmodelle notwendig. Um im Folgenden konkrete Maßnahmen entwickeln zu können, wird zunächst geklärt, welche Teilaufgaben das Controlling konfigurativer Referenzmodelle umfassen soll. Die Teilaufgaben des Controllings lassen sich aus klassischen Definitionen des Begriffs ableiten. Bspw. versteht HORVÁTH unter Controlling „ [..] – funktional gesehen – dasjenige Subsystem der Führung, das Planung und Kontrolle sowie Informationsversorgung systembildend und systemkoppelnd ergebniszielorientiert koordiniert und so die Adaption und Koordination des Gesamtsystems unterstützt“ [Horv94, S. 125f., S. 144]. Controlling ist somit eine Unterstützung der Führung: Es ermöglicht ihr, das Gesamtsystem zielorientiert an Umweltänderungen zu adaptieren und die Koordinationsaufgaben hinsichtlich des operativen Systems wahrzunehmen [Hahn97, S. 18]. REICHMANN definiert den Controllingbegriff wie folgt: „Controlling ist die zielbezogene Unterstützung von Führungsaufgaben, die der systemge-


79

stützten Informationsbeschaffung und Informationsverarbeitung zur Planerstellung, Koordination und Kontrolle dient, es ist eine rechnungswesenund vorsystemgestützte Systematik zur Verbesserung der Entscheidungsqualität auf allen Führungsstufen der Unternehmung“ [Reic95]. Beide Definitionen fokussieren die Unterstützung der Unternehmensführung bei den Teilaufgaben Planung, Koordination und Kontrolle. Überträgt man diese drei genannten Aufgaben auf das Controlling konfigurativer Referenzmodelle, treten vor allem die Aufgaben der Planung unter Kontrolle in den Vordergrund. Das Ziel des Referenzmodellcontrollings besteht in der Unterstützung der Planung in Form von Anpassung des Referenzmodells an die Gegebenheiten des spezifischen, betrachteten Falls und in der Kontrolle, ob das verwendete Referenzmodell der aktuellen Unternehmenswirklichkeit und den Kundenansprüchen Rechnung trägt, sowie, ob die durchgeführte Adaption den für den konkreten Fall definierten spezifischen Anforderungen genügt. Die Koordination spielt beim Controlling konfigurativer Referenzmodelle keine tragende Rolle, dennoch ist sie zu berücksichtigen, da konfigurative Referenzmodelle selbst, wenn sie primär zur Anwendungssystemgestaltung eingesetzt werden, in der Regel auch einen Einfluss auf die Organisationsgestaltung und damit auf die Koordination von Geschäftsprozessen ausüben. Darüber hinaus können Referenzmodelle, die zur Softwareentwicklung konzipiert wurden, bereits um Informationen zum Projektmanagement von auf ihnen basierenden Softwareentwicklungsprojekten angereichert sein, was wiederum eine Unterstützung bei der Koordination darstellt. Einen Hinweis darauf, wie ein Controlling konfigurativer Referenzmodelle umgesetzt werden kann, findet sich bei ZIEGENBEIN. Er versteht unter „Controlling [..] die Bereitstellung von Methoden (Techniken, Instrumente, Modelle, Denkmuster) und Informationen für arbeitsteilig ablaufende Planungs- und Kontrollprozesse sowie die funktionsübergreifende Koordination (Abstimmung) dieser Prozesse“ [Zieg04, S. 23]. Auch diese Definition umfasst die drei Aufgabenbereiche Planung, Kontrolle und Koordination, sieht aber zudem die Bereitstellung von Methoden als eine wesentliche Aufgabe des Controllings. Eine weitergehende Konkretisierung der Controllingaufgaben liefert GROB. Dieser sieht zwei wesentliche Aufgaben des Controllings [Grob96, S. 137-158]: • Schaffung und Betreuung einer Infrastruktur zur Informationsversorgung bei der Planung und Kontrolle (Systemgestaltung), • Koordination und Durchführung von Planung und Kontrolle (Systemnutzung).

80


Für das Controlling konfigurativer Referenzmodelle folgt aus den Definitionen von ZIEGENBEIN und GROB, dass zum einen eine Infrastruktur aufgebaut werden muss, die Techniken, Instrumente, Modelle und Denkmuster bereitstellt, auf deren Basis eine Durchführung des Controllings konfigurativer Referenzmodelle ermöglicht wird. Zum anderen muss ein Konzept zur Nutzung und zum Einsatz einer solchen Infrastruktur entwickelt werden. Zwar wurde die Notwendigkeit eines Controllings von Referenzmodellen erkannt [Schü98, S. 300-308; OtKl99, S. 23-29], ein operationalisierbares Konzept zu dessen Umsetzung fehlt jedoch bislang. Daher ist ein Konzept für eine entsprechende Infrastruktur zu entwickeln (Systemgestaltung) und darzustellen, wie diese Infrastruktur genutzt werden kann (Systemnutzung), wobei die konkrete Ausgestaltung der Durchführung unternehmensspezifisch ist und daher nur in der Praxis bis ins Detail ausgestaltet werden kann. Demzufolge steht die Infrastrukturentwicklung im Vordergrund. Hierzu werden im folgenden Abschnitt zunächst die einzelnen Regelkreise der Controllingmechanismen vorgestellt. Anschließend erfolgt die Vorstellung des um Controllingkonzepte erweiterten Fachkonzepts eines Referenzmodellierungswerkzeugs, welches im Anschluss in ein DV-Konzept überführt wird.

2

Teilaufgaben des Controllings konfigurativer Referenzmodelle

Zur effektiven und vor allem zur effizienten Verwendung von Konfigurationsmechanismen sind die Aktualität und Passgenauigkeit des Referenzmodells und dessen Konfigurationsmechanismen von erheblicher Bedeutung. Welche Teilaufgaben und Regelkreise des Controllings konfigurativer Referenzmodelle erforderlich sind, lässt sich aus dem Vorgehensmodell der referenzmodellgestützten Softwareentwicklung und -anpassung ableiten, das in Abbildung 1 dargestellt ist. Ausgangspunkt der Softwareentwicklung in diesem Vorgehensmodell ist ein um Konfigurationsmechanismen erweitertes Referenzmodell, das als „konfigurierbares Modell“ bezeichnet wird. Es erfolgt zunächst eine Erhebung der für das Einsatzgebiet der Software relevanten Merkmale. Dabei kann es sich um Unternehmensmerkmale und Perspektiven handeln (vgl. auch den Beitrag von PATRICK DELFMANN und ARMIN STEIN in diesem Band). Auf Basis dieser Konfigurationsparameter erfolgt eine automatische Anpassung des Referenzmodells an diese Parameter. Bspw. wer-


81

den für ein Handelsunternehmen ohne Lagerhaltung aus dem Referenzmodell des Warenwirtschaftssystems die Lagerhaltungsprozesse und die zugehörigen Datenobjekte ausgeblendet. Rückwirkung auf das Referenzmodell

Konfigurierbares Adaptierbares Referenzmodell

konstruieren/ erwerben

Adaption

Kennzahlen der ReferenzmodellAdaption

Adaptiertes Konfiguriertes Referenzmodell

generieren

manuelle Anpassung

Unternehmens-/ Kundenspezifisches Modell

konstruieren

KMSU

Verfeinerung

DV-Konzept z. B. OOA/OOD in UML Entwicklungsphase

Kennzahlen der SW-Entwicklung

spezifizieren

Implementierung

Entwickelte Software

entwickeln

Installation

Kennzahlen des Produkteinsatzes

Einsatz der Software

verwenden

SoftwareAnwender (Kunde)

Abbildung 1: Regelkreise des Controllings konfigurativer Referenzmodelle

Diese automatisch adaptierten Modelle dienen nun als Basis für eine weitere manuelle Adaption, da automatische Konfigurationsmechanismen nur Adaptionsalternativen berücksichtigen können, die der Referenzmodellersteller bereits bei der Referenzmodellkonstruktion vorausgesehen hat. Nachdem z. B. in Workshops mit den späteren Anwendern der zu entwickelnden Software, die entsprechenden spezifischen Anforderungen erhoben worden sind, erfolgt dann eine manuelle Anpassung der Modelle.

82


Die so entstehenden fachkonzeptionellen Modelle dokumentieren die Anforderungen der Softwareanwender und fungieren im Weiteren als Ausgangspunkt der Softwareentwicklung bzw. -anpassung. In den nächsten Schritten, Verfeinerung und Implementierung, kann grundsätzlich jedes aus dem Software Engineering bekannte Vorgehensmodell verwendet werden, das eine modellbasierte Anforderungsdefinition erlaubt. Nach Abschluss der Entwicklungsphase erfolgt, als letzte Phase des Vorgehensmodells, die Installation der entwickelten Software beim Kunden, der diese dann produktiv einsetzt. Dieses Vorgehensmodell (vgl. Abbildung 1) lässt sich durch das Hinzufügen von Kennzahlen zur Identifikation von drei Regelkreisen des Controllings konfigurativer Referenzmodelle verwenden. Für das Controlling konfigurativer Referenzmodelle, das Planung, Koordination und Kontrolle dieses Softwareentwicklungsprozess unterstützen soll, lassen sich drei Gruppen von Kennzahlen unterscheiden, die erhoben werden müssen. Dies sind die Kennzahlen der Referenzmodelladaption, die Kennzahlen der Softwareentwicklung sowie die Kennzahlen des Softwareeinsatzes. Die Kennzahlen der Referenzmodelladaption umfassen sämtliche Daten, die während der Anwendung der automatischen Konfigurationsmechanismen verfügbar sind. Sie dokumentieren damit den Verlauf des Adaptionsprozesses. Typische Daten sind beispielsweise Konfigurationsparameter, die zur Adaption verwendet worden sind. Die Kennzahlen der Softwareentwicklung dienen der Steuerung und des Projektmanagements im Rahmen des Softwareentwicklungsprozesses. Sie umfassen sämtliche verfügbaren Kennzahlen für das Management von Softwareprojekten, z. B. die Entwicklungsdauer. Die dritte Gruppe von Kennzahlen wird aus dem täglichen Betrieb der erstellten Software, z. B. aus Logfiles oder Audit-Trails, gewonnen. Sie ermöglichen eine Validierung der zu Beginn der Softwareentwicklung definierten Anforderungen. Anhand dieser drei Kennzahlengruppen lässt sich die Planung, Kontrolle und Koordination von referenzmodellbasierten Softwareentwicklungsprojekten verbessern, indem Schwachstellen des verwendeten Referenzmodells und der darin eingebetteten Konfigurationsmechanismen aufgezeigt werden. Analog zu den drei Kennzahlengruppen ergeben sich drei Regelkreise des Controllings konfigurativer Referenzmodelle, wobei die Zuordnung der Kennzahlen zu Regelkreisen nicht disjunkt ist. Im Folgenden werden die Regelkreise zum Controlling der Referenzmodelladaption, dem Management von Softwareentwicklungsprojekten sowie des konfigurierbaren Referenzmodells vorgestellt. In den ersten Regelkreis, Controlling der Referenzmodelladaption, fließen die Kennzahlen der Referenzmo-


83

delladaption sowie Kennzahlen des Produkteinsatzes aus früheren Projekten ein. In den zweiten Regelkreis, Controlling des Projektmanagements, fließen die Kennzahlen der Softwareentwicklung aus abgeschlossenen Entwicklungsprojekten ein. In den dritten Regelkreis, Controlling des konfigurierbaren Referenzmodells, fließen alle drei genannten Kennzahlengruppen ein. 2.1 Controlling der Referenzmodelladaption Die Konzepte der konfigurativen Referenzmodellierung verringern i. d. R. zwar den Aufwand bei der Konstruktion der fachkonzeptionellen Modelle für die Softwareentwicklung erheblich, führen aber zu einem neuen Entscheidungsproblem. Falls mehrere alternative Referenzmodelladaptionen in einem bestimmten Modellierungskontext existieren, muss in Abhängigkeit von den zugrunde liegenden Zielen die am besten geeignete Alternative selektiert werden. Die Aufgabe aus Sicht des Controllings besteht dabei in der Unterstützung der Planung und Kontrolle der Adaption. Im Rahmen der Planung ist eine kennzahlenbasierte Bewertung der Adaptionsalternativen zu leisten. Die Kontrolle ist notwendig, um die Einhaltung der Kundenanforderungen sicherzustellen. Außerdem sind die Kundenanforderungen häufig Basis für ein Pflichtenheft, das später auch die Grundlage für den Vertrag zwischen dem KMSU und dessen Kunden bildet. Dazu wird ein Verfahren vorgestellt, das die Bewertung verschiedener konkurrierender Adaptionsalternativen sowie die Kontrolle der Zeilerreichung umfasst. Dieses Verfahren basiert auf dem Konzept des Analytical Hierarchy Process (AHP), welches 1978 von SAATY entwickelt wurde [Saat78, S. 147-157; Saat80]. Das Vorgehen lässt sich in fünf Schritte untergliedern: 1. 2. 3. 4.

Identifizierung der alternativen Adaptionsvarianten, Festlegung der für die Bewertung relevanten Kennzahlen, Gewichtung der selektierten Kennzahlen, Wertermittlung jeder Kennzahl für jede ausgewählte Adaptionsalternative und 5. Berechnung der Bewertungsergebnisse. Im ersten Schritt soll die betriebswirtschaftliche Fragestellung, welche durch die Adaptionsalternativen adressiert wird, eindeutig spezifiziert werden, z. B. die Verräumung von angelieferter Frischware in einem Betrieb des Lebensmitteleinzelhandels. Diese Problemdefinition muss für alle alternativen Geschäftsprozesse identisch sein, wobei jede Adaptionsalterna-

84


tive einen anderen Lösungsweg für dieses Problem aufzeigt, wie das folgende Beispiel zeigt. So kann die Fragestellung Zahlung einer Rechnung durch einen Kunden durch die alternativen Prozesse Zahlung mit Kreditkarte, Barzahlung oder Zahlung auf Rechnung gelöst werden. Wie dieses Beispiel zeigt, sind auch Kombinationen der einzelnen Varianten möglich, die, falls sie durch die Konfigurationsmechanismen vorgesehen sind, eine neue Alternative darstellen. So kann beispielsweise, sofern ein entsprechender Prozess als Adaptionsvariante im Referenzmodell vorgesehen ist, auch eine Kombination aller drei Zahlungsarten eine weitere Alternative darstellen. Um die alternativen Adaptionsvarianten in eine Rangfolge einordnen zu können, müssen im zweiten Schritt entsprechende Kriterien, welche den Beitrag zur Zielerreichung jeder Alternative genau beschreiben, festgelegt werden. Dabei werden zwischen monetären Kriterien, z. B. Kosten pro Kunden, und nicht-monetären Kriterien, wie Durchlaufzeit oder Qualität, unterschieden (Aufgrund der später durchgeführten mathematischen Operationen sind nur kardinal skalierte Kennzahlen möglich, da nur bei Ihnen das Verhältnis zweier Kennzahlenausprägungen sinnvoll interpretiert werden kann [Back06]). In diesem Schritt der Bewertung werden die Kennzahlen, die die benötigten Kriterien des spezifischen Problems beschreiben, ausgewählt. Die hierzu verwendeten Kennzahlen müssen in Abhängigkeit des eingesetzten Referenzmodells gewählt werden, da bei Modellen mit verschiedenen Einsatzbereichen, z. B. einerseits die Erfassung von Artikeln im Wareneingang eines Warenwirtschaftssystems [BeSc04] und andererseits die Personalplanung, dieselben Kennzahlen nicht dieselbe Aussagekraft über den Beitrag zur Zielerreichung der Adaptionsalternativen besitzen. Im dritten Schritt werden die Kriterien, welche durch die Kennzahlen dargestellt werden, für den spezifischen Kontext des Benutzers dieser Beurteilungsmethode einzeln gewichtet. Die Gewichtung spiegelt die kundenindividuellen Präferenzen und Anforderungen wider. Sie wird in einer Matrix vorgenommen, die die Bedeutung eines Kriteriums im Vergleich zu einer anderen anzeigt. Gleichung 1 zeigt ein Beispiel für die drei Kennzahlen Qualität, Kosten und Durchlaufzeit. Aus der Matrix wird ersichtlich, dass der Faktor Qualität den doppelten Einfluss auf die Bewertung hat wie die Kosten und 4 mal wichtiger bewertet wird als die Durchlaufzeit. Alle Werte unterhalb der Hauptdiagonalen (graue Schriftfarbe) entsprechen dem Kehrwert der Werte oberhalb der Hauptdiagonalen der Matrix.


Qualität ⎛ 1 ⎜ ⎜ 0,5 Durchlaufzeit ⎜⎝ 0, 25 Qualität Kosten

Kosten 2 1 0, 5

85

Durchlaufzeit

(1)

4⎞ ⎟ 2⎟ 1 ⎟⎠

Anschließend wird die Gewichtungsmatrix quadriert und dann normalisiert. Die Normalisierung erfolgt durch Dividierung der Summe jeder Zeile durch die Gesamtsumme aller Gewichtungen in der Matrix. Als Ergebnis erhält man einen Vektor, der die Wichtigkeit jedes Kriteriums anzeigt. Diese beiden Vorgänge, Quadrierung und Normalisierung, werden so lange wiederholt bis nur noch marginale Veränderungen zwischen dem Gewichtungsvektor der gegenwärtigen Iteration und dem in der zuvor durchgeführten Iteration berechnetem Gewichtungsvektor erkennbar sind (Die Methode zur Berechnung des Gewichtungsvektors basiert auf dem Analytical Hierarchy Process (AHP) [Saat78, S. 147-157; Saat80]). Der erste Durchgang einer solchen Iteration ist in Gleichung 2 dargestellt, die die Beispielgleichung 1 fortführt. Mit der Berechnung des Gewichtungsvektors ist die Normalisierung der Schlüsselkennzahlen jedes Geschäftsprozesses abgeschlossen.

2

2 4⎞ ⎛ 3 6 12 ⎞ ⎛ 1 ⎜ 0, 5 ⎟ ⎜ ⎟ 1 2 = 1, 5 3 6 ⎜ ⎟ ⎜ ⎟ ⎜ 0, 25 0, 5 1 ⎟ ⎜ 0, 75 1, 5 3 ⎟ ⎝ ⎠ ⎝ ⎠

⎛ 21 ⎞ ⎜ 36, 75 = 0, 571 ⎟ ⎜ ⎟ ⎜ 10, 5 ⎟ ⎜ 36, 75 = 0, 286 ⎟ ⎜ ⎟ ⎜ 5, 25 ⎟ = 0,143 ⎟ ⎜ 36, 75 ⎠ normalisiert ⎝

(2)

Im vierten Schritt werden alle ausgewählten Kennzahlen für jede Adaptionsalternative konkrete Werte ermittelt. Die Kennzahlen jeder Alternative können dabei aus anderen in der Vergangenheit angefallenen Daten extrapoliert oder per Simulation gewonnen werden [HeSe04]. Grundsätzlich wird bei dieser Bewertungsmethode davon ausgegangen, dass der Beitrag zur Zielerreichung umso besser ist, je höher der Wert der entsprechenden Kennzahl ausfällt. Für Kennzahlen wie Durchlaufzeit und Kosten gilt jedoch das Gegenteil. Daher erfolgt eine Transformation der Werte dieser Kennzahlen, so dass im Weiteren von der Annahme ausgegangen werden kann, dass ein höherer Wert einer Kennzahl einen größeren Zielerreichungsgrad darstellt. Dazu werden die Werte solcher Kennzahlen zuerst in eine Rangfolge gebracht und dann wird diese umgekehrt; d. h. der

86


in der Rangfolge am höchsten stehende Wert wird gegen den auf der niedrigsten Stufe stehenden Wert ausgetauscht. Falls zwei oder mehr alternative Varianten den gleichen Wert haben, werden alle Werte einer Stufe mit den Werten der korrespondierenden Stufe vertauscht. Nachdem die Definition der Kennzahlen erfolgt ist, wird der Mindestwert für jede Kennzahl festgelegt. Anschließend wird jede Alternative auf Erfüllung dieser Mindestanforderungen überprüft. Sobald nur genau eine Alternative alle Anforderungen erfüllt, ist die am besten geeignete Adaptionsalternative bereits gefunden. Erfüllt keine der Alternativen die Anforderungen, gibt es drei Möglichkeiten: Erstens können die Werte für die Mindestanforderungen an die Kennzahlen geändert werden, zweitens können neue Alternativen berücksichtigt werden, oder drittens können die alternativen Referenzmodelladaptionen manuell so verbessert werden, bis sie den Anforderungen gerecht werden. Nachdem eine oder mehrere dieser drei Veränderungen vorgenommen wurden, wird der Geschäftsprozess erneut der Anforderungsüberprüfung unterzogen. Diese Schritte werden solange wiederholt bis mindestens ein Prozess die Anforderungen erfüllt. Falls mehr als eine Alternative den Anforderungen gerecht wird, werden die Varianten anhand eines Bewertungsverfahrens (Schritt 5) beurteilt. Dieses Verfahren wird anhand des bereits erwähnten Beispiels eines Bezahlvorgangs mit drei unterschiedlichen Ausgestaltungsmöglichkeiten, die jeweils eine Adaptionsvariante des Referenzmodells darstellen, illustriert. Die Durchlaufzeit der drei Beispielprozesse betrage 200 Sekunden für die Alternative Zahlung auf Rechnung, 200 Sekunden für die Alternative Barzahlung und 250 Sekunden für die Alternative Zahlung mit Kreditkarte. Nach obigem Schema müsste die Durchlaufzeit dementsprechend in 250 Sekunden für Zahlung nach Rechnungserhalt sowie für Barzahlung und in 200 Sekunden für Bezahlung mit Kreditkarte geändert werden. Dieser Austausch führt zu einer Matrix, die die Annahme erfüllt, dass ein höherer Wert einer Kennzahl auch ein besseres Ergebnis darstellt. Das Verhältnis der Kennzahlen ändert sich durch den Austausch nicht. Ein weiteres Problem bei der Bewertung sind die verschiedenen Skalierungen der Kennzahlen. So kann die Durchlaufzeit beispielsweise in Sekunden, Millisekunden, Stunden oder Minuten, etc. gemessen werden. Um den Einfluss jeder einzelnen Kennzahl auf die Gesamtbewertung nicht durch die Verwendung von Einheiten, die besonders große oder kleine Zahlen für eine Kennzahl zur Folge haben, zu beeinflussen, werden im nächsten Schritt die Kennzahlen normalisiert, um sie Skalenunabhängig zu machen (Für eine Kennzahl muss bei sämtlichen Adaptionsalternativen bereits vor der Normalisierung dieselbe Einheit gewählt werden). Dadurch bleibt das Ergebnis des Bewertungsverfahrens auch dann unverändert,


87

wenn sich die Einheiten und infolge dessen die Ausprägungen von Kennzahlen verändern. Die Normalisierung der Matrix erfolgt, indem jeder Wert einer Kennzahl durch die Summe der Werte der Kennzahl für alle Alternativen dividiert wird. Durch die Normalisierung kann eine Entscheidung unabhängig von den Einheiten der Kennzahlen getroffen werden, z. B. wenn die Durchlaufzeit entweder durchgängig in Millisekunden oder in Sekunden angegeben ist, sind die absoluten Werte der Kennzahlen unterschiedlich, nicht aber ihr Quotient, welcher maßgeblich für die Bewertung ist. Gleichung 3 zeigt ein Beispiel von Kennzahlen, die anhand dieser Methode normalisiert worden sind. Auch auf die normalisierte Matrix wurde die Austauschmethode für die Kennzahlen Kosten und Durchlaufzeit angewandt, da für diese Kennzahlen ebenso gilt, dass höhere Werte nicht mit besserer Leistung gleichzusetzen sind. Re chnung Qualität Kosten Durch laufzeit

⎛ 5 ⎜ 345 ⎜ ⎜ 250 ⎝

Barzahlung 6 600 250

Kredit karte

(3)

⎛ 0,38 0, 46 0,15 ⎞ ⎟ normalisiert ⎜ 0, 26 0, 46 0, 28 ⎟ ⎜ ⎟ ⎟ ⎜ 0,36 0,36 0, 29 ⎟ 200 ⎟⎠ ⎝ ⎠ 2 ⎞

365

Die normalisierte Matrix mit den alternativen Geschäftsprozessen wird in Gleichung 4 transformiert und schließlich mit dem vorher berechneten Gewichtungsvektor multipliziert. Der Lösungsvektor besteht aus einer Kennzahl pro Adaptionsalternative, die besagt, wie geeignet jede Alternative ist, wobei sich die Werte aller Alternativen immer zu 1 aufsummieren. Diese Kennzahl resultiert aus den gewählten Kennzahlen sowie ihren Werten und Gewichtungen. Dabei gilt: Je höher die Ausprägung der Kennzahl für eine Alternative im Lösungsvektor ist, desto größer ist der Beitrag zur Zielerreichung der entsprechenden Alternative.

T ⎛ 0,38 0,46 0,15 ⎞ ⎛ 0,57 ⎞ ⎛ 0,40 ⎞ ⎜ 0,46 0,26 0,28 ⎟ * ⎜ 0,29 ⎟ = ⎜ 0,38 ⎟ ⎜ ⎟ ⎜ ⎟ ⎜ ⎟ ⎜ 0,29 0,29 0,36 ⎟ ⎜ 0,14 ⎟ ⎜ 0,22 ⎟ ⎝ ⎠ ⎝ ⎠ ⎝ ⎠

(3)

In diesem Beispiel ist die beste alternative Adaptionsvariante die Zahlung auf Rechung (0,40), die zweitbeste die Barzahlung (0,38) und die ungünstigste Alternative die Zahlung per Kreditkarte (0,22). Dieses Vorgehen führt dazu, dass die Modellvariante ausgewählt wird, die den Anforderungen an die vom Anwender spezifizierte Software am besten gerecht wird.

88


Neben der Unterstützung der Planung werden während der Referenzmodelladaption Daten über den Adaptionsprozess gesammelt. Diese Daten werden später dazu genutzt, um Verbesserungspotentiale des Referenzmodells und der dort eingebetteten Konfigurationsmechanismen aufzudecken. Bei diesen Daten handelt es sich um alle während der automatisiert durchgeführten Adaption anfallenden Daten, die in einem Audit-Trail oder einem Log-File gespeichert werden. Dadurch soll nachvollzogen werden können, welche Konfigurationsparameter und -mechanismen verwendet werden und welche manuellen Anpassungen anschließend noch notwendig sind. 2.2 Controlling des Projektmanagements Der zweite Regelkreis des Controllings konfigurativer Referenzmodelle umfasst die Unterstützung bei der Planung und Koordination des Projektmanagements von Softwareentwicklungs- und -anpassungsprojekten. Die Aufwandsschätzung von Softwareprojekten ist eine aus dem Software Engineering lange bekannte aber nicht vollständig gelöste Fragestellung. Die Aufwandsschätzung von Softwareentwicklungs- und anpassungsprojekten erfolgt gewöhnlich durch den Vergleich mit in der Vergangenheit durchgeführten Projekten. Gebräuchliche Verfahren zur Aufwandsabschätzung wie die Analogiemethode [Balz01, S. 78ff.], oder Function-Point-basierte Methoden [Balz01, S. 83-87] wie das Constructive Cost Model (COCOMO) [Balz01, S. 90ff], bedienen sich dieses Ansatzes, indem sie anhand bestimmter Kriterien die Vergleichbarkeit des geplanten Projekts und der in der Vergangenheit abgeschlossenen Projekte aufzeigen. Anschließend wird auf dieser Basis die Zeit- und Kostenplanung des zu realisierenden Projektes durch Übertragung der in den abgeschlossenen Vergleichsprojekten realisierten Größen ermittelt. Nach Durchführung der Konfiguration kann eine erste grobe Abschätzung des Projektaufwands und der benötigten Ressourcen erfolgen. Dieses Controlling des Projektmanagements basiert auf den Erfahrungen aus Vorgängerprojekten, in denen dieselbe Adaption des Basis- bzw. Referenzmodells verwendet wurde. Der erforderliche Aufwand sowie die spezifischen Kenntnisse, die zur Implementierung benötigt werden, sind jeweils im konfigurierbaren Referenzmodell zu jeder Variante hinterlegt. Dabei werden keine monetären Größen verwendet [BaIl04, S. 190f.], da diese sich im Zeitablauf rasch ändern und schlechter aus früheren Projekten übertragbar sind, z. B. falls Teile der Entwicklung ausgelagert worden sind und inzwischen Preisänderungen stattgefunden haben. Nach der Fertigstellung der Software fließt das Wissen über den aktuell angefallenen Aufwand in


89

das konfigurierbare Referenzmodell ein. Auf diese Weise wird sichergestellt, dass die Abschätzung des Aufwands auf Basis der im konfigurierbaren Modell hinterlegten Größen Entwicklungen sowie verkürzten Entwicklungszeiten z. B. durch den Einsatz neuer CASE-Tools, Rechnung trägt. 2.3 Controlling des konfigurierbaren Referenzmodells Aus Sicht des Controllings besteht eine dritte Herausforderung in den Veränderungen des Umfelds, in dem die Software eingesetzt wird. So führen beispielsweise veränderte rechtliche Rahmenbedingungen wie der Sarbanes Oxley Act (SOX) zu Veränderungen in Geschäftsprozessen, die sich in der eingesetzten Software niederschlagen müssen.

Abbildung 2: Phasen des Controllings konfigurativer Modelle [SeDR06]

90


Der dritte Regelkreis, das Controlling des konfigurierbaren Referenzmodells, wird relevant, nachdem die Software implementiert und beim Kunden installiert ist. Dort werden Kennzahlen aus dem laufenden Betrieb der Software gewonnen. Dies geschieht beispielsweise mit Werkzeugen zum Process Performance Measurement (PPM). Dazu werden die entsprechenden Messpunkte bereits in das konfigurierbare Referenzmodell eingebunden, auf deren Basis sich Kennzahlen berechnen lassen. Hierzu wird zunächst auf fachkonzeptioneller Ebene dokumentiert, bei Durchführung welcher Funktion welche Kennzahl gemessen wird; so kann beispielsweise dokumentiert werden, dass die Durchlaufzeit einer betriebswirtschaftlichen Funktion, vom Beginn einer elementaren Funktion bis zum Abschluss der Ausführung einer anderen elementaren Funktion, gemessen wird. Auf Basis der so gewonnen Kennzahlen sowie der während der Adaptionsphase und der Implementierungsphase erhobenen Kennzahlen können Schwachstellen und die daraus resultierenden notwendigen Änderungen im konfigurierbaren Referenzmodell erkannt und dementsprechend bestehende Adaptionsvarianten verändert oder, falls notwendig, neue hinzugefügt werden. Die Phasen des Referenzmodelllebenszyklus unter Einbeziehung des Controllings zeigt Abbildung 2. Beginnt man den Zyklus mit der Referenzmodelladaption, entsprechen die Phasen Implementierung und Software-Anwendung den bereits in Abbildung 1 dargestellten Phasen. Die drei sich daran anschließenden Phasen, Adaptionscontrolling, Anforderungsanalyse, und Konstruktion des Referenzmodells, sind dagegen in der vorherigen Abbildung nicht explizit dargestellt. Sie sind jedoch Bestandteil des Regelkreises Controlling konfigurativer Referenzmodelle. Das Adaptionscontrolling erfolgt in den drei Schritten: • Datenerfassung, • Datenkonsolidierung und • Datenanalyse. In der Phase der Datenerfassung werden die entsprechenden Kennzahlen aus unterschiedlichen Softwareentwicklungsprojekten, denen dasselbe Referenzmodell zugrunde lag, in einer gemeinsamen Datenbasis vereinigt. Dazu ist jede einzelne Kennzahl mit Metadaten zu versehen, die eine Zuordnung der Kennzahl zu dem Projekt bzw. dem Kunden sowie dem Zeitpunkt, an dem sie erhoben wurde, ermöglichen. Die Datenerfassung schließt Kennzahlen der Adaption des Referenzmodells, der Implementierung und des Einsatzes der Software ein. Das Ziel der anschließenden Datenkonsolidierung ist es, die in verschiedenen Anwendungsfällen gewonnen Kennzahlen zu vereinheitlichen, um später nicht Gefahr zu laufen, von Einzelfällen auf das zu Grunde liegende Referenzmodell zu schließen. Dazu werden die Daten so aufbereitet, dass


91

der Zusammenhang zwischen den Kennzahlen eines Projekts hergestellt wird und Kennzahlen verschiedener Projekte, die denselben betriebswirtschaftlichen Inhalt repräsentieren, direkt verglichen werden können. Die Zusammenfassung der Kennzahlen aus einem Projekt ist notwendig, da sich bestimmte Sachverhalte nur durch mehrere Kennzahlen erklären lassen, die dann gemeinsam ein Gesamtbild vermitteln. Nach der Konsolidierung der Daten erfolgt deren Analyse. Um im Rahmen der Analyse Verbesserungspotenziale im Referenzmodell und in den Konfigurationsmechanismen zu erkennen, ist es notwendig, Vergleiche zwischen den bestehenden Varianten des Referenzmodells und möglicherweise vorteilhaften, spezifischen Modellen durchzuführen. Dabei sind sowohl Vergleiche zwischen verschiedenen spezifischen Modellen, zwischen spezifischen Modellen und dem Referenzmodell als auch zwischen verschiedenen Versionen dieser Modelle erforderlich (zum Versionsmanagement von Referenzmodellen vgl. [Thom06; Thom07]). Das Controlling kennt dazu grundsätzlich drei Arten von Vergleichen: • Objektvergleiche, z. B. Vergleich zweier Abteilungen oder zweier Modelle • Zeitvergleiche, z. B. Vergleich einer Referenzmodellvariante zu zwei verschiedenen Zeitpunkten • Soll/Ist-Vergleiche, z. B. Vergleich der gewünschten mit den tatsächlich vorliegenden Kennzahlen einer Modellvariante Der unmittelbare Vergleich mithilfe der zuvor beschriebenen Bewertungsmethode von alternativen Referenzmodelladaptionen ist aufgrund der fehlenden Ausprägungen der Kennzahlen im Referenzmodell und der unternehmensspezifischen Gewichtung der Kriterien nicht durchführbar. Daher werden die implementierten unternehmensspezifischen Modelle mit den Adaptionen des Referenzmodells verglichen, aus denen sie abgeleitet wurden. Durch diesen Vergleich lassen sich solche Modelle identifizieren, die in spezifischen Situationen zu bevorzugen sind. Dadurch wird insbesondere auf die nach Durchführung der automatischen Konfigurationsmechanismen weiteren manuellen Anpassungen eingegangen. Diese Anpassungen stellen die Beseitigung des Diskrepanzempfindens dar, das der Referenzmodellanwender zwischen seinen Anforderungen und dem automatisch adaptierten Referenzmodell empfindet. Daher stellen die spezifischen, manuell angepassten Modelle die Grundlage für potenzielle Veränderungen und Erweiterungen sowohl des Referenzmodells als auch der Konfigurationsmechanismen dar. Dementsprechend ist zu prüfen, ob man anhand der vorliegenden Modelle und Kennzahlen von den vorliegenden spezifischen Modellen auf eine Verbesserungsmöglichkeit im Referenzmodell schließen kann. Dabei deuten bspw. gleiche manuelle Veränderun-

92


gen derselben Variante des konfigurativen Referenzmodells auf eine Problemlösung hin, die als neue Variante in das Referenzmodell übernommen werden kann. Bei der Analyse der spezifischen Modelle ergeben sich drei mögliche Maßnahmen: 1. Das Referenzmodell kann angepasst oder um eine neue Variante erweitert werden. 2. Falls nach der automatischen Adaption eine manuelle Anpassung stattfindet und dabei Modellelemente ergänzt werden, die vor der Referenzmodelladaption schon im adaptierbaren Referenzmodell bereits enthalten waren, deutet dies darauf hin, dass die Zuordnung von Konfigurationsparametern zu Referenzmodellvarianten nicht vollständig adäquat ist. Daher müssen in diesem Fall die Konfigurationsmechanismen und deren Parameter derart angepasst werden, dass die Zuordnung zwischen Modellelementen und Adaptionsmerkmalen korrekt ist. 3. Der Referenzmodellersteller kann zu dem Schluss gelangen, dass man von dem vorliegenden spezifischen Modell nicht auf bestimmte Veränderungen im adaptierbaren Referenzmodell schließen kann. Falls das Referenzmodell oder die darin eingebetteten Konfigurationsmechanismen angepasst werden, existieren zwei mögliche Vorgehensweisen. Einerseits kann die entsprechende Adaptionsvariante im Referenzmodell angepasst werden, was allerdings zu einer Verschlechterung bei der Anwendung in anderen spezifischen Fällen führen kann. Deswegen kann andererseits das spezifische (Teil)-Modell als neue Adaptionsvariante in das Referenzmodell übernommen und mit Adaptionsparametern versehen werden, die die spezifische Situation, in der es entstanden ist, beschreiben [Thom06]. Falls die spezifischen Modelle keine ausreichenden Hinweise auf potenzielle Verbesserungen des konfigurierbaren Referenzmodells bieten und die aktuellen Ist-Kennzahlen die Sollwerte nicht erfüllen, können Maßnahmen zur Geschäftsprozessverbesserung getroffen werden, die durch Simulationen unterstützt werden. Hinsichtlich der Möglichkeiten der Simulation und Verbesserung von Prozessmodellen, die auf fachkonzeptioneller Ebene die größte Bedeutung für die Softwareentwicklung besitzen, sind zwei grundsätzliche Strategien zu unterscheiden. Soll die Ablaufstruktur generell erhalten bleiben, liegt die Optimierungschance in einer Substitution der derzeit verwendeten Ressourcen (Arbeitsmittel, Aufgabenträger) durch wirtschaftlichere Ressourcen. Kann die Ablaufstruktur selbst Veränderungen unterworfen werden, so gibt es verschiedene Ansatzpunkte [Tiem95]. Folgende Veränderungen sind grundsätzlich möglich: Verbessern einzelner Prozessschritte, Eliminieren von Prozessschritten, Ändern der Prozessreihenfolge, Hinzufügen weiterer Prozessschritte,


93

Verschmelzen mehrerer Prozessschritte, Beschleunigen und Parallelisieren von Tätigkeiten. Erst die Erkenntnisse der Zusammenhänge von struktureller und prozessualer Gestaltung ermöglichen die Überschaubarkeit und Interpretationsfähigkeit der Interdependenzen betrieblichen Geschehens. Die Ansatzpunkte für eine konkrete Prozessverbesserung sind in Abbildung 3 dargestellt [LoLo93]. verbessern

1

2+

3

eliminieren

1

2

3

permutieren

3

2

1

hinzufügen

1

2

3

1+2

3

verschmelzen beschleunigen

1

2 1

4

3 3

parallelisieren 2

Abbildung 3: Ansatzpunkte für die Optimierung von Geschäftsprozessen (in Anlehnung an [LoLo93, S. 251])

Diese Ansätze, die i. d. R. das höchste Optimierungspotenzial versprechen, bedürfen der computergerechten Unterstützung durch Modellierungs- und Simulationswerkzeuge [Seel02]. Die auf diese Weise erzeugten neuen Abläufe können durch die Simulation [Tiem95] verschiedener Alternativen und deren Bewertung zur Verbesserung des konfigurativen Referenzmodells beitragen. Bei den drei bisher vorgestellten Regelkreisen sind aus organisatorischer Sicht zwei verschiedene Szenarien denkbar. Zum einen kann der Referenzmodellersteller auf Basis des entwickelten konfigurativen Referenzmodells auch die Softwareentwicklung durchführen. In diesen Fall er-

94


leichtert das Referenzmodell die Anpassung und Verwaltung der Softwarevarianten für verschiedene Kunden. Dieses Szenario ist in Abbildung 1 dargestellt. Zum anderen kann es sich bei Referenzmodellersteller und -nutzer um zwei verschiedene Organisationen handeln. Dieses Szenario ist in Abbildung 2 dargestellt. In diesem Fall unterscheiden sich die möglichen Controllingmaßnahmen nicht von denen des anderen Szenarios, jedoch ist die Datenbeschaffung und Konsolidierung wesentlich aufwändiger, da die entsprechenden Modelle und Kennzahlen der Referenzmodelladaption, der Softwareentwicklung und des Softwareeinsatzes von möglicherweise mehreren verschiedenen anderen Unternehmungen bereitgestellt werden müssen.

3

Modellierung der Controllingmechanismen und -konzepte

Nachdem im vorherigen Abschnitt die grundlegenden Controllingmechanismen konfigurativer Referenzmodelle vorgestellt worden sind, erfolgt nun deren Integration in das Fachkonzept für konfigurative Referenzmodellierungswerkzeuge, wie es bereits im Beitrag von PATRICK DELFMANN und ARMIN STEIN in diesem Band eingeführt worden ist. Wie bei der Vorstellung der Konfigurationsmechanismen ist für die Controllingkonzepte eine Erweiterung des zu Grunde liegenden Datenmodells notwendig. Daher werden die für das Controlling erforderlichen Erweiterungen zunächst anhand von Anwendungsbeispielen vorgestellt und anschließend in das Datenmodell integriert. Als Anwendungsbeispiel dient ein Geschäftsprozess zur Erfassung neuer Artikel, der als erweiterte Ereignisgesteuerte Prozesskette (EPK) in Abbildung 4 dargestellt ist [KeNS92]. An drei Ereignissen in diesem Prozess sind Messpunkte annotiert. Durch diese Messpunkte wird mithilfe von Softwarewerkzeugen, wie z. B. dem Process Performance Manager der IDS-Scheer AG, dokumentiert, unter welchen Rahmenbedingungen ein bestimmtes Ereignis eintrat, z. B. zu welchem Zeitpunkt es stattfand, wer es ausgelöst hat, etc. Anhand dieser Daten lässt sich anschließend die Berechnung von Kennzahlen durchführen. Die Definition der Kennzahlen erfolgt durch Kennzahlenzuordnungsdiagramme (KZD) [Kron05, S. 38]. Kennzahlenzuordnungsdiagramme beschreiben den Aufbau einer Kennzahl anhand von Messpunkten oder anderen Kennzahlen, einer Rechenvorschrift zu ihrer Verknüpfung und der Position der Messpunkte oder Kennzahlen, an der sie in die Rechenvorschrift


95

eingesetzt werden. In der ursprünglichen Form der Kennzahlenzuordnungsdiagramme, wie sie von KRONZ beschrieben werden, wird auf die Rechenvorschrift und die Position verzichtet. Deswegen wird die hier verwendete Form als erweiterte Kennzahlenzuordnungsdiagramme bezeichnet. Durch die Möglichkeit der Verwendung von Kennzahlen innerhalb von Kennzahlenzuordnungsdiagrammen lassen sich durch dieses Instrument auch Kennzahlensysteme darstellen.

Neuer Artikel gelistet

Artikel anlegen_Start

ArtikelStammdaten abfragen

ArtikelStammdaten sind abgefragt

DLZ Stammdatenerfassung Stammdatenerfassung_Start

Position: 2

Stammdatenverwaltung öffnen

Stammdatenerfassung_Start Subtraktion: V1 - V2

Stammdatenverwaltung ist verfügbar

Position: 1 Artikel anlegen_Ende

Stammdaten einpflegen

Stammdaten sind eingepflegt Prozessmodell

Artikel anlegen_Ende erw. Kennzahlenzuordnungsdiagramm

Abbildung 4: Einsatz und Definition von Kennzahlen

Betrachtet man nun spezifische Modelle, für die durch den Einsatz der Software im täglichen Betrieb Daten vorliegen und Kennzahlen bestimmt worden sind, so lassen sich nun anstelle von Messpunkten Fakten an (Teil)-Modelle annotieren. Ein Fakt stellt eine Kennzahl und ihre Ausprägung dar. Neben der Kennzahl und ihrer Ausprägung ist die Einheit, der

96


Typ der Kennzahl (Soll- oder Ist-Wert) der Zeitpunkt des Prozessdurchlaufs zu dem sie bestimmt wurde sowie das Projekt oder der Kunde, bei dem das spezifische Modell eingesetzt wurde vermerkt. In dem in Abbildung 5 dargestellten Beispiel beträgt die Durchlaufzeit für den markierten Teilprozess 42 Minuten. Dabei handelt es sich um eine Ist-Kennzahl, die am 27.07.2006 im spezifischen Modell gemessen wurde, das aus dem Entwicklungsprojekt 471 stammt.

Abbildung 5: Repräsentation ermittelter Kennzahlen

Diese hier vorgestellten Konstrukte zur Durchführung des Controllings stellen eine Erweiterung des Fachkonzepts für konfigurative Referenzmodellierungswerkzeuge dar. Zur Spezifikation dieser Erweiterung müssen die im Beitrag von PATRICK DELFMANN und ARMIN STEIN in diesem Band eingeführten Datenmodelle erweitert werden. Die Erweiterungen gehen vom Konstrukt Elementausprägung aus, das aus den ursprünglichen


97

Datenmodellen bereits bekannt und aus diesem Grund grau schattiert ist (vgl. Abbildung 6). Hierarchie (0,1)

(0,n)

Modellelement

AttributElementZuordnung

(0,n)

(0,n)

Instanzattribut

(0,n)

WB-IAZuO

(0,n)

(0,n)

Wertebereich

Elemente des Referenzmodells

verändert

Legende

Maßnahmenbeschreibung

Entitytyp

(0,n) Maßnahme (0,n)

MaßnahmenBewertungsZuO

Relationshiptyp Uminterpretierter Relationshiptyp

Auswirkung des Controlling

Toleranz

N,P

Name

(0,n)

(n,m)

Attribut Kante mit Kardinalität

(0,n)

Generalisierung/ Spezialisierung

Bewertung

D: N: T: P:

(0,n) Vergleich

Hierarchie (0,1)

(0,n)

(0,n) (0,n)

(0,n) Ziel

disjunkt nicht disjunkt total partiell

Operationalisiert

(0,n)

(1,n)

Fakt

(0,n)

Wert

Zeit, Typ

Controlling des Referenzmodells Format, Zeit

(0,n) (0,n) Rechenvorschrift

(1,n)

(0,n) Anzahl der Variablen

Position

(0,n)

(0,n)

Term

Kennzahlposition im Term

(0,n)

TermKennzahlZuO

(0,n)

Kennzahl

(0,1)

KennzahlEinheitsZuO

(0,n)

Einheit

(0,n) (1,n) KennzahlKategorieZuO Die Berechnung einer Kennzahl kann durch verschiedene Analyseansätze erfolgen, muss jedoch mathematisch zum identischen Ergebnis führen.

(1,n)

Zielkategorie

Kennzahlendefinition

Abbildung 6: Fachkonzept der Controllingkonzepte für konfigurative Referenzmodellierungswerkzeuge

98


Ein Konstrukt, das auf Ausprägungsebene an jedes Modellelement annotiert werden kann, ist das Attribut. Ein spezielles Attribut ist der so genannte Fakt. Ein Fakt entsteht durch die Kombination aus einer Kennzahl und dem Wert, den diese annimmt. Dabei wird zu jedem Wert der Zeitpunkt oder Zeitraum, auf den er sich bezieht sowie sein Typ, z. B. Ist- oder Sollwert, festgehalten. Das Hinzufügen des Zeitbezugs ermöglicht Zeitvergleiche ohne Veränderung der Kennzahlendefinition, was ansonsten erforderlich wäre, um inhaltlich identische Kennzahlen, die zu verschiedenen Zeitpunkten erhoben wurden, unterscheiden zu können. Des Weiteren ist eine Einschränkung des Bereichs möglich, den ein Wert annehmen kann, z. B. eine Zahl zwischen 0 und 100 bei Prozentangaben. Diese Einschränkung wird durch den Entitytyp Wertebereich festgelegt, der nicht direkt mit dem Entitytyp Wert, sondern mit dem Entitytyp Attribut in Beziehung steht, da eine Einschränkung des Wertebereichs auch für andere Spezialisierungen des Attributes, die nicht aus der Controllingsicht stammen, sinnvoll sein kann. Die Definition der Kennzahlen erfolgt durch eine Verknüpfung zweier oder mehrerer Kennzahlen mit einer Rechenvorschrift zu einem Term. Die Struktur des Terms wird durch die Entitytypen Rechenvorschrift und Position festgelegt. Jede Rechenvorschrift besitzt ein Attribut, das angibt wie viele Kennzahlen zu ihrer Berechnung notwendig sind. Die Position gibt an, an welcher Stelle in welchem Term eine bestimmte Kennzahl verwendet wird. Beispielsweise lässt sich die Eigenkapitalrendite mit der Rechenvorschrift „Division“, die die Anzahl der Variablen „zwei“ besitzt, den Kennzahlen „Gewinn“ und „Eigenkapital“ sowie der Festlegung, dass der Gewinn an erster Position und das Eigenkapital an zweiter Position steht, berechnen. Eine exakte Definition der Beschreibung der Rechenvorschrift erfolgt als kontextfreie Grammatik in Backus-NaurForm (BNF) [Naur60; Schö97 S. 25ff.] (vgl. Abbildung 7). G={V, ∑, P, S} V={S, Variable, Ausdruck, Operator} ∑={+, -, *, :, exp, kennzahl, ⎥} P={ S ::= Variable| Ausdruck Ausdruck ::= S| S Operator S| (Ausdruck) Variable ::= kennzahl| ⎥ Operator ::= +| -| *| :| exp } Abbildung 7: Kontextfreie Grammatik zur Formulierung von Rechenvorschriften


99

Durch die Zuordnung eines solchen Terms zu einer Kennzahl können komplexere Kennzahlen definiert werden, die sich mithilfe eines Terms aus mehreren anderen Kennzahlen berechnen lassen. Auf diese Weise können Kennzahlen aggregiert und Kennzahlensysteme dargestellt werden. Die Aggregation von Kennzahlen wird z. B. im Rahmen des Controllings der Referenzmodelladaption verwendet, bei der die relevanten Kennzahlen, ähnlich dem Return-on-Investment (ROI), aggregiert werden, um sie vergleichen zu können. Zur Erleichterung der Verwendung einer Kennzahl ist jede Kenzahl einer oder mehreren Zielkategorien (Zeit, Kosten, Qualität) zugeordnet. Zur eindeutigen Definition jeder Kennzahl ist jeder Kennzahl durch den Entitytyp Einheit eine entsprechende Einheit zugeordnet, was notwendig ist um beispielsweise nicht fälschlicherweise eine in Sekunden gemessene Durchlaufzeit mit einer in Minuten festgehaltenen Durchlaufzeit zu vergleichen. Die Rückwirkung der durch die Kennzahlen erfassten Inhalte auf das Referenzmodell bzw. seine Adaption geschieht durch den Vergleich von Fakten und einer anschließenden Bewertung dieser Vergleiche. Dabei werden Abweichungen der aktuellen Werte von den Soll-Werten, von Werten derselben Kennzahl aus der Vergangenheit oder Werten aus vergleichbaren Projekten berücksichtigt. Diese Bewertung ordnet jedem Vergleichsergebnis potenzielle Maßnahmen zu, die zur Modellverbesserung ergriffen werden können. Damit allerdings nicht jede noch so geringfügige Abweichung sofort zu Maßnahmen führt, ist mit dem Entitytyp Toleranz ein Bereich definiert, in dem Abweichungen zu keiner weiteren Aktion führen sollen. Die Ausführung dieser Maßnahme kann zwar werkzeugunterstützt, z. B. durch die Hervorhebung von Modellelementen, aber nicht ohne Eingriff des Referenzmodellerstellers erfolgen. Wie eine mögliche Unterstützung der bisher vorgestellten Konzepte durch Softwarewerkzeuge gestaltet werden kann, erläutert der folgende Abschnitt.

4

DV-technische Umsetzung

Die zuvor beschriebenen Verfahren, insbesondere die Bewertung von Adaptionsalternativen auf Basis des Analytical Hierachy Process (AHP), erfordern zahlreiche Rechenvorgänge, die bei mehreren Alternativen, die auf Basis mehrerer Kennzahlen verglichen werden sollen, manuell nicht mit vertretbarem Aufwand durchzuführen sind. Daher wurde ein Prototyp in Form eines Softwarewerkzeugs entwickelt, der alle notwendigen Berechnungen durchführt.

100


Abbildung 8: Softwarewerkzeug zum kennzahlenbasierten Vergleich von Adaptionsalternativen

Ein Screenshot dieses Werkzeugs ist in Abbildung 8 dargestellt. Dem gemeinsamen Fachkonzept folgend sowie zur besseren Integration mit den Konfigurationsmechanismen wurde das Werkzeug als Skript für den ARIS Business Architect 7 der IDS Scheer AG entwickelt, das auch als Grundlage für die Implementierung des konfigurativen Referenzmodellierungswerkzeugs adapt(x) verwendet worden ist (vgl. auch den Beitrag von TOBIAS RIEKE und ARMIN STEIN in diesem Band). Eine noch größere Bedeutung als bei der Bewertung der Adaptionsalternativen kommt dem DV-Konzept bei der Erhebung der Kennzahlen sowie der Gegenüberstellung verschiedener um Kennzahlen erweiterter Modellvarianten zu. Die Kennzahlenerhebung setzt eine operationalisierte Definition der Kennzahlen voraus. Für die softwaretechnische Umsetzung bedeutet dies, dass Ereignisse definiert werden müssen, die als Messpunkte für die Kennzahlenerhebung fungieren können. Abbildung 4 zeigt ein Beispiel für die Festlegung von Messpunkten in einem Prozessmodell. Um später diese Messpunkte abfragen zu können, müssen sie bei der Überfüh-


101

rung des Prozessmodells auf Fachkonzept-Ebene über die DV-Konzeptebene bis zur Implementierung mitgeführt werden. In der laufenden Software können sie dann z. B. mithilfe von Log-Files protokolliert werden. Ein Beispiel hierfür zeigt Tabelle 1: ID

ObjektReferenz

Anzahl Positionen

BenutzerID

Status

AnfangTimestamp

EndeTimestamp

421

4711

500

10

Abgeschlossen

23.12.2005 12:00

23.12.2005 12:30

14

4712

350

11

Abgeschlossen

23.12.2005 12:15

23.12.2005 12:30

12

4713

385

12

Abgeschlossen

23.12.2005 12:25

23.12.2005 12:50

189

4714

30

10

Abgeschlossen

23.12.2005 12:40

23.12.2005 12:50

517

4715

120

10

Abgeschlossen

23.12.2005 12:51

23.12.2005 13:05

241

4716

78

10

Abgeschlossen

23.12.2005 13:15

23.12.2005 13:50

163

4717

93

11

Abgebrochen

23.12.2005 12:31

23.12.2005 12:55

761

4718

680

12

Laufend

23.12.2005 12:58

Tabelle 1:

Exemplarische Darstellung eines Log-Files

So lässt sich in diesem Beispiel durch die Timestamps die Durchlaufzeit eines Prozesses berechnen. Des Weiteren lässt sich auch bspw. anhand der Benutzer-ID errechnen, wie viele Prozesse von einem bestimmten Benutzer in einem Zeitabschnitt angestoßen wurden. Darüber hinaus lässt sich bspw. erkennen, welche Art von Gütern durch die Objektreferenz repräsentiert wird und in welcher Häufigkeit dies zu Prozessabbrüchen führt. Vorausgesetzt, dass die Ereignisse, die als Basis für die Messpunkte dienen, konsequent in die Implementierung überführt werden, lassen sich auch Kennzahlen wie die Durchlaufzeit von anderen als der im Log-File explizit festgehaltenen Prozesse ermitteln. Dies kann durch die Berechnung der Differenz aus dem End- und dem Startzeitpunkt verschiedener Teilprozesse erfolgen, wenn diese gemeinsam einen neuen Teilprozess bilden. Hierzu ist allerdings die Kenntnis des Prozessmodells notwendig, auf dem die Ermittlung der Messpunkte basiert.

102


Abbildung 9: Beispiel für die vergleichende Analyse der Adaptionen zweier Kunden [SeDR06]


103

Damit eine Ermittlung der Kennzahlen auf diese Weise möglich ist, müssen die Kennzahlen bereits im Referenzmodell hinterlegt werden und bei der Überführung des Referenzmodells in ein spezifisches Modell ebenfalls überführt und gegebenenfalls adaptiert werden. In der Regel bedeutet dies, dass eine Kennzahl, die an ein Modellelement annotiert wurde, bei Ausblendung des Modellelements ebenfalls ausgeblendet werden muss. Nachdem die Überführung des Referenzmodells und der darin enthaltenen Kennzahlen in ein spezifisches Modell erfolgt ist, müssen die Kennzahlen gemeinsam mit dem Modell bis zur fertigen Implementierung mitgeführt werden. An die Phase der Datenerhebung schließen sich die Phasen Datenkonsolidierung und -analyse an. Wie zuvor dargelegt wurde, besteht das Ziel dieser beiden Phasen in der Zusammenführung und auswertungsgerechten Darstellung der Kennzahlen aus verschiedenen Implementierungen von Referenzmodelladaptionen. Abbildung 9 zeigt die direkte Gegenüberstellung der spezifischen Modelle zweier Kunden. Durch die weiße bzw. dunkle Hinterlegung wird deutlich, welche Modellelemente des integrierten Modells welchem spezifischen Modell entstammen. Anhand der hinterlegten Eigenschaften, die auch die erhobenen Kennzahlen umfassen, können direkte Vergleiche von Modellelementen oder Teilmodellen vorgenommen werden. Das Beispiel in Abbildung 9 zeigt, dass die Durchlaufzeit der Funktion „Beleg sortieren“ bei Kunde B mit nur 10 Minuten wesentlich schneller durchgeführt wird als bei Kunde A. Durch die Analyse weiterer Attribute ergibt sich eine mögliche Erklärung für die unterschiedlichen Durchlaufzeiten. In diesem Fall kann die Differenz beispielsweise durch die Tatsache erklärt werden, dass die Funktion bei Kunde A manuell und bei Kunde B automatisiert ausgeführt wird. Stellt man fest, dass spezifische Modelle überdurchschnittlich gute Werte für Kennzahlen aufweisen, sind die entsprechenden Teilmodelle dahingehend zu überprüfen, ob sie als neue Adaptionsvariante dem Referenzmodell hinzugefügt werden können.

5

Fazit

Referenzmodelle können ihre Aufgabe, als Vorlage für die Erstellung anderer Informationsmodelle zu dienen und dadurch die Konstruktion der abgeleiteten Modelle zu beschleunigen sowie einen Beitrag zur Erhöhung deren Qualität zu leisten, nur sinnvoll erfüllen, wenn sie aktuell und auf den spezifischen Anwendungskontext bezogen sind. Einen wichtigen Schritt zu einer einfacheren und feingranulareren Anpassung der Refe-

104


renzmodelle stellen Konfigurationsmechanismen dar. Allerdings ist erst durch die ständige Überprüfung und Verbesserung der Referenzmodelle und der darin eingebetteten Konfigurationsmechanismen eine kostengünstige und bedarfsgerechte automatische Referenzmodelladaption möglich. Dabei kommt dem Controlling die Aufgabe zu, Schwachstellen im Referenzmodell und den Konfigurationsmechanismen aufzudecken, Verbesserungspotenziale für das Referenzmodell aus spezifischen, manuell adaptierten Modellen aufzuzeigen und die Planung von Softwareentwicklungsprojekten durch das Bereitstellen von Informationen über Implementierungen von Referenzmodellvarianten zu unterstützen. Hierzu wurde ein Konzept aus drei Regelkreisen des Controllings konfigurativer Referenzmodelle vorgestellt und zur Realisierung notwendige Erweiterungen des Fachkonzepts um Modellelemente für Kennzahlen und deren Verarbeitung vorgenommen. Des Weiteren lässt sich abschließend sagen, dass insbesondere für die vorgestellten Controllingkonzepte eine modellgestützte Softwareentwicklung von besonderer Bedeutung ist, da nur so sichergestellt werden kann, dass die bereits im Referenzmodell enthaltenen Kennzahlendefinitionen in das spezifische Fachkonzeptmodell und von da aus bis in die lauffähige Software gelangen, wodurch eine softwarewerkzeugbasierte Erhebung der Kennzahlen erst sinnvoll möglich wird. Dementsprechend wichtig ist die Verwendung geeigneter Codegeneratoren, die in der Lage sind entsprechende Messpunkte für die Kennzahlenerhebung in die entwickelte Software einzubetten (vgl. hierzu den Beitrag von JULIA WAGNER, THOMAS ANDRES und YVES LAUER in diesem Band).

Literaturverzeichnis [Back06] Backhaus, K.: Multivariate Anlaysemethoden: Eine anwendungsorientierte Einführung. 11. Auflage, Berlin et al. 2006. [BaIl04] Baumeister, A.; Ilg, M.: Entwicklungsbegleitende Kalkulation von Softwareprojekten nach dem Unified Process. Wirtschaftsinformatik 46 (2004) 3, S. 188-195. [Balz01] Balzert, H.: Lehrbuch der Software-Technik: Softwareentwicklung. 2. Auflage, Heidelberg 2001. [BDKK02] Becker, J.; Delfmann, P.; Knackstedt, R.; Kuropka, D.: Konfigurative Referenzmodellierung. In: Becker, J.; Knackstedt, R. (Hrsg.): Wissensmanagement mit Referenzmodellen – Konzepte für die Organisations- und Anwendungssystemgestaltung. Heidelberg 2002, S. 25-144. [BeSc04] Becker, J.; Schütte, R.: Handelsinformationssysteme. 2. Auflage, Frankfurt am Main 2004.


105

[Chen76] Chen, P. P.: The Entity-Relationship-Model. Toward a Unified View of Data. ACM Transactions on Database-Systems 1 (1976) 1, S. 9-36. [FeLo07] Fettke, P.; Loos, P.: Perspectives on Reference Modeling. In: Fettke, P.; Loos, P. (Hrsg.): Reference Modeling for Business Systems Analysis. Hershey 2007, S. 1-20. [Grob96] Grob, H. L.: Positionsbestimmung des Controlling. In: Scheer, A.-W. (Hrsg.): Rechnungswesen und EDV: Kundenorientierung in Industrie, Dienstleistung und Verwaltung. Heidelberg 1996, S. 137-158. [Hahn97] Hahn, D.: Controlling in Deutschland – State of the Art. In: Gleich, R.; Seidenschwanz, W. (Hrsg.): Die Kunst des Controlling – Prof. Dr. Péter Horváth zum 60. Geburtstag. München 1997. [HeSe04] Herrmann, K.; Seel, C.: Controlling of adaptive Reference Models. Proceedings of the 6th International Conference MITIP 2004 „The Modern Information Technology in the Innovation Processes of the Industrial Enterprises”. Saarbrücken 2004. [Holt00] Holten, R.: Entwicklung einer Modellierungstechnik für Data-Warehouse-Fachkonzepte. In: Schmidt, H. (Hrsg.): Modellierung betrieblicher Informationssysteme. Proceedings der MobIS-Fachtagung 2000. Siegen 2000, S. 3-21. [Horv94] Horváth, P.: Controlling. 5. Auflage, München 1994. [KeNS92] Keller, G.; Nüttgens, M.; Scheer, A-W: Semantische Prozeßmodellierung auf der Grundlage Ereignisgesteuerter Prozessketten. Veröffentlichung des Instituts für Wirtschaftsinformatik Nr. 89, Universität des Saarlandes, Saarbrücken 1992. [Kron05] Kronz: Management von Prozesskennzahlen im Rahmen der ARIS-Methodik. In: Scheer, A.-W.; Jost, W. (Hrsg.): Corporate Performance Management: ARIS in der Praxis. Berlin 2005, S. 31-44. [LoLo93] Lohoff, P.; Lohoff, H.-G.: Verwaltung im Visier – Optimierung der Büro- und Dienstleistungsprozesse. zfo Zeitschrift für Führung + Organisation 62 (1993) 4, S. 252. [Naur60] Naur, P.: Revised Report on the Algorithmic Language ALGOL 60. Communications of the ACM 3 (1960) 5, S. 299-314. [OtKl99] Otto, A.; Klaus, P.: Referenzmodelle als Basis des Benchmarkings. io management 4 (1999). [Reic95] Reichmann, T.: Controlling mit Kennzahlen und Managementberichten: Grundlagen einer systemgestützten Controlling-Konzeption. 4. Auflage, München 1995. [Saat78] Saaty, T.: Modeling unstructured decision problems: Theory of Analytical Hierarchies. Mathematics and Computers in Simulation 20 (1978). [Saat80] Saaty, T.: Decision making for leaders. Pittsburgh 1980. [Schö97] Schöning, U.: Algorithmen – kurz gefaßt. Heidelberg 1997. [Schü98] Schütte, R.: Grundsätze ordnungsmäßiger Referenzmodellierung. Konstruktion konfigurations- und anpassungsorientierter Modelle. Wiesbaden 1998.

106


[SeDR06] Seel, C.; Delfmann, P.; Rieke, T.: Enterprise System introduction with Controlling Enabled Configurative Information Models. In: Proceedings of the IEEE Workshop on Flexibility in Process-aware Information Systems, hosted by the WETICE 2006. Manchester 2006. [Seel02] Seel, C.: Visuelle Simulation von Dienstleistungsprozessen. Lohmar 2002. [Thom06] Thomas, O.: Management von Referenzmodellen: Entwurf und Realisierung eines Informationssystems zur Entwicklung und Anwendung von Referenzmodellen. Berlin 2006. [Thom07] Thomas, O.: Reference Model Management. In: Fettke, P.; Loos, P. (Hrsg.): Reference Modeling for Business Systems Analysis. Hershey 2007, S. 288-309. [Tiem95] Tiemeyer, E.: Software zur Modellierung und Simulation organisatorischer Systeme. zfo Zeitschrift für Führung + Organisation 64 (1995) 4, S. 250. [Zieg04] Ziegenbein, K.: Controlling. 8. Auflage, Ludwigshafen 2004.

Entwicklung konfigurativer Referenzmodelle für Warenwirtschaftssysteme mit adapt(x)

Michael Eisenbarth, Claus Ködel Abstract: Im vorliegenden Beitrag wird die Anwendung des Prototypen adapt(x) zur Entwicklung von Warenwirtschaftssystemen innerhalb der maxess systemhaus GmbH beschrieben. In den folgenden Abschnitten wird zuerst die Ausgangssituation des Unternehmens maxess motiviert und auf dessen aktuelle Anforderungen zur Modellierung von variantenreichen Geschäftsprozessmodellen eingegangen. Danach wird an einem exemplarischen Referenzmodell demonstriert, inwiefern der Prototyp diese Anforderungen erfüllen kann. Anhand eines durchgängigen Beispiels werden die Grundfunktionalitäten von adapt(x) angewandt, um das maxess-ARIS-Referenzmodell kundenspezifisch konfigurieren zu können. Das Kapitel endet mit einem Fazit bezüglich der Funktionalität von adapt(x) und den erfüllten Anforderungen.

1

Motivation

Die maxess systemhaus gmbh arbeitet bereits seit mehreren Jahren mit Geschäftsprozessmodellen im Zuge der Entwicklung des Warenwirtschaftssystems x-trade. Für die Modellierung entschied sich das Unternehmen Ende der 90er Jahre für das Tool ARIS der IDS-Scheer AG. Anfangs handelte es sich bei den Modellen um einfach gestaltete Geschäftsprozessmodelle vom Typ der erweiterten Ereignisgesteuerten Prozessketten (eEPK). Diese stellten die Prozesse, die mit x-trade realisiert werden können, zunächst im Groben dar. Die in ARIS modellierten Prozesse dienten als Grundlage der Entwicklung des Basis-Softwaresystems von x-trade.

108

Michael Eisenbarth, Claus Ködel

1.1 Ausgangssituation Mit der rasch zunehmenden Funktionalität von x-trade – und der damit einhergehenden zunehmenden Kundenanzahl – wuchsen die Geschäftsprozessmodelle sowohl in ihrer Anzahl als auch in ihrer Größe erheblich an. Dabei entstehen immer häufiger einerseits Varianten in den zu unterstützenden Geschäftsprozessen selbst, andererseits bilden sich Varianten, welche ausschließlich von einem oder mehreren – aber nicht von allen – Kunden genutzt werden bzw. nur für diese entwickelt werden. Dies führt dazu, dass die Übersichtlichkeit der Prozessmodelle aufgrund der Variantenvielfalt überaus leidet Bei Workshops mit Kunden verwendet die maxess systemhaus gmbh die Geschäftsprozessmodelle, um die Kundenprozesse zu analysieren und zu optimieren. ARIS bietet keine Funktionalität, um einem bestimmten Kunden genau seine, oder einem potenziellen Kunden nur die Basisprozesse des Warenwirtschaftssystems x-trade anzuzeigen. Da ein Kunde bei Auslieferung eines Releases u. a. auch einen Web-Export seiner Geschäftsprozessmodelle bekommt, besteht auch hier das Problem, wie dieser so erzeugt werden kann, dass nur diejenigen Geschäftsprozessmodelle enthalten sind, die zu der Basisvariante von x-trade gehören und zusätzlich dem entsprechenden Kunden zugeordnet werden können. Teilweise sind kundenindividuelle Anforderungen sogar vertraglich geschützt, so dass diese Varianten keinem anderen Kunden zur Verfügung gestellt werden dürfen. Ein weiteres Problem ergibt sich während der Modellierung maxess intern. ARIS bietet keine Funktionalität, um Prozessmodelle eines bestimmten Kunden anzuzeigen. Mittels einer solchen kundenspezifischen Sicht auf ein Modell könnten für genau diesen Kunden Erweiterungen hinzumodelliert werden, ohne dass Irritationen durch die Varianten der anderen Kunden im Gesamtmodell bestehen. Interessant wäre in diesem Fall aber auch die Möglichkeit der Rückführung der erweiterten Kundenvariante in das Gesamtmodell. 1.2 Stand der Praxis Um dennoch die kundenspezifischen Varianten in ARIS möglichst sinnvoll verwalten zu können, wurde bei maxess bis dato das im Folgenden beschriebene Verfahren angewendet: Kundenindividuelle Teilprozesse, die eine Kundenvariante innerhalb eines Geschäftsprozessmodells darstellen, werden mit den speziellen Modellelementen des Typs Variantenanfang und Variantenende umschlossen.

Entwicklung konfigurativer Referenzmodelle für Warenwirtschaftssysteme

109

Da diese Objekte sich grafisch von den standardmäßig grün gefärbten Funktionen und magenta gefärbten Ereignissen abheben, werden in jedem Geschäftsprozessmodell sofort die enthaltenen kundenspezifischen Varianten ersichtlich. Zum schnelleren Erkennen, für welchen Kunden eine Variante gilt, wird in die Objekte Variantenanfang und Variantenende der Name des Kunden eingetragen (vgl. Abbildung 1). ...

LO-Gewicht (kg) pflegen

Sammelplat ztypzuordn en

Nicht-SuperMarkt

Super-Markt

WE-Menge der WEPos...


Nicht-SuperMarkt

Plausibilität sprüfung der Meng...

Plausibilitä tsprüfung ist positiv

Ist-MHD der WE-Pos pflegen

Einlagerung shöhe pflegen

Zur WE-Pos zugeordnet es THM...

Chargen-Nr. zur WE-Pos pflegen

Plausibilitä tsprüfung ist negativ W eitere Bearbeitun g...

Menge akzeptieren

Menge ändern

Super-Markt

Daten der WEPosition...

...

Abbildung 1: Ausschnitt aus dem maxess-Referenzmodell

Anschließend erhält jedes Objekt des Geschäftsprozessmodells (Funktion, Ereignis, Variantenanfang und Variantenende), welches zu einer Kundenvariante gehört, in dem Attribut „Beschreibung/Definition“ den Namen des jeweiligen Kunden (vgl. Abbildung 2). Diese Information muss vom Anwender manuell gepflegt werden, was je nach Größe der Kundenvariante entsprechenden Aufwand produziert. Besonders aufwändig ist diese Verfahrensweise dann, wenn es sich um einen kompletten Geschäftsprozess handelt, der kundenspezifischen Charakter hat. Von der Pflege des Attributs “Beschreibung/Definition“ sind Kanten zwischen Objekten sowie

110


Konnektoren ausgenommen. Eine solche Kundenzuordnung bei Kanten und Konnektoren ist bei dieser Vorgehensweise nicht immer eindeutig möglich.

Abbildung 2: Manuelle Zuordnung von Prozessbereichen zu Kunden mit Attributen in ARIS

Die kundenspezifisch gekennzeichneten Objekte werden im Anschluss in der Objektsicht des ARIS-Explorers in einen speziellen Ordner verschoben, der den Namen des Kunden trägt. Die Prozessmodelle selbst ändern sich hierdurch nicht; lediglich die Definitionen der Modellelemente werden kundenspezifisch gespeichert. Die maxess systemhaus gmbh orientiert sich hierbei an dem Ordnungsrahmen des Handels-H-Modells. Dieser Ordnungsrahmen wird in ARIS in der Hauptgruppe dargestellt (vgl. Abbildung 3). Auf gleicher Ebene befindet sich ein Ordner für die kopierten Kundenobjekte, in dem für jeden Kunden nochmals dieser Ordnungsrahmen enthalten ist. Für die kundenindividuelle Anzeige der Prozessmodelle nutzt maxess die Rechteverwaltung in ARIS. Auf die kundenindividuellen Ordner besitzt folglich nur der jeweilige Benutzer (=Kunde) Zugriffsrechte. Voraussetzung ist, dass jeder neue Kunde auch als Benutzer angelegt wird. Wird ein Prozessmodell von einem speziellen Kunden geöffnet, so bekommt dieser Kunde in seinen Prozessmodellen folglich nur noch diejenigen Modellelemente angezeigt, die für ihn relevant sind. Dies sind alle all-


111

gemeinen Modellelemente und zusätzlich diejenigen, denen sein Kundenname zugewiesen wurde. Alle anderen Modellelemente – nämlich diejenigen anderer Kunden – sind zwar noch sichtbar, werden jedoch „ausgegraut“ und ohne Bezeichnung dargestellt.

Abbildung 3: Kundenspezifische Ordnerstruktur in ARIS

112


Ein Administrator hingegen hat sowohl auf die allgemeinen als auch alle kundenindividuellen Modellelemente Zugriff, weshalb für ihn stets das gesamte Prozessmodell inklusive der Kundenmarkierungen angezeigt wird. 1.3 Anforderungen an eine Konfigurationsunterstützung Dieses Handling zur Verwaltung von Prozessvarianten erweist sich zum einen als sehr umständlich, zum anderen ist die Generierung kundenspezifischer Ansichten nicht optimal. Ein Kunde, der sich mit seinem Account anmeldet, sieht zwar nur diejenigen Prozessmodellbereiche, die für ihn relevant sind, er sieht aber auch, dass in diesem Modell noch andere Objekte enthalten sind. Diese werden von ARIS nicht ausgeblendet. Es lässt sich in dem Geschäftsprozessmodell zwar nicht der Inhalt der Objekte erkennen, wohl aber grau umrandete Objektumrisse. Des Weiteren bleiben Kanten und Konnektoren bei dieser Vorgehensweise unberücksichtigt. Dadurch kommt es vor, dass Konnektoren in der kundespezifischen Sicht nicht korrekt sind. Kanten verweisen bspw. auf grau umrandete Objekte, die eigentlich nicht zu der gewählten Prozesssicht gehören. In regelmäßigen Abständen muss somit mittels der Suchfunktion in dem Ordnungsrahmen der Basisprozesse geprüft werden, ob sich noch Objekte darin befinden, die nicht in den kundenspezifischen Ordnungsrahmen verschoben wurden. D. h., dass pro Kunde ein Suchlauf gestartet werden muss, der nach Objekten sucht, die in dem Attribut „Beschreibung/Definition“ den Namen dieses Kunden führen. Werden solche Objekte gefunden, so müssen diese ebenfalls in die entsprechenden kundenspezifischen Ordner verschoben werden. Das bis dato angewendete Verfahren ist fehleranfällig, was für maxess äußerst ungünstige Auswirkungen haben kann – bspw. dann, wenn Objekte von vertraglich geschützten Kundenvarianten versehentlich in dafür nicht vorgesehene kundenspezifische Ordner verschoben werden. Hieraus ergibt sich die Anforderung, das Handling von Kundenvarianten – aber auch von Prozessvarianten – erheblich zu vereinfachen. Denkbar ist hier z. B. eine Steuerung über die rechte Maustaste um zuvor markierte Objekte entsprechend zu kennzeichnen. Dadurch würden die Attributpflege und das Verschieben der kundenspezifischen Objekte entfallen. Weiterhin sollte es möglich sein, eine korrekte Kundenansicht zu erhalten, was bedeutet, dass die grau umrandeten Objekte nicht mehr angezeigt werden, um somit zu einem adäquaten Erscheinungsbild des Geschäftsprozessmodells zu kommen. Das gilt auch für das Führen von Kanten und die korrekte Darstellung von Konnektoren. Konnektoren sollten sich nach Möglichkeit automatisch an den neuen Prozessausschnitt anpassen. Ist dies


113

nicht möglich, sollte der Anwender darauf hingewiesen werden. Existieren mehrere Alternativen, muss ihm die Möglichkeit gegeben werden, sich für eine zu entscheiden. Darüber hinaus wäre es für die Modellierung von Vorteil, wenn sich zwecks kundenindividueller Geschäftsprozessmodellierung der kundenspezifische Geschäftsprozess herausfiltern ließe, an diesem Änderungen vorgenommen werden könnten, und dieser anschließend wieder in das Gesamtmodell überführt werden könnte. Dies hätte den Vorteil, dass beim Modellieren die Anpassungen nur in der kundenspezifischen Modellsicht vorgenommen werden und der Anwender nicht durch andere Kundenvarianten abgelenkt wird. Wünschenswert wäre, dass diese Anpassungen direkt in ARIS realisiert werden können. Sollte das nicht möglich sein, so wäre ein externes Tool denkbar, welches nahtlos in ARIS integriert werden kann.

2

adapt(x) bei maxess

Im Folgenden wird veranschaulicht, inwieweit die Nutzung von adapt(x) das Unternehmen maxess bei der variantenreichen Modellierung unterstützen kann. Weiterhin wird diskutiert, welche der genannten Anforderungen erfüllt werden und welche weiteren Funktionalitäten wünschenswert wären. 2.1 Nutzungsszenario Als Ausgangssituation wird wieder das in der Einleitung dieses Kapitels vorgestellte Beispiel verwendet (vgl. nochmals Abbildung 1), wobei zur vereinfachten Darstellung der erzielten Ergebnisse im Folgenden nur zwei Kundenvarianten betrachtet werden. Mithilfe der in adapt(x) zur Verfügung gestellten zusätzlichen Modellierungskonstrukte wird spezifiziert, welcher der jeweiligen Prozessmodellausschnitte für bestimmte Kunden relevant ist und welcher nicht. In dem hier dargestellten Beispiel werden zwei Varianten betrachtet, die Geschäftsprozesse für eine Alternative „Super-Markt“ und eine Alternative „Hyper-Markt“ darstellen. Soll das Prozessmodell für den Kunden „SuperMarkt“ konfiguriert werden, soll der mittlere Teilprozess (mit maxess-spezifischen Modellelementen als „Super-Markt“-spezifisch) enthalten sein, und der linke Teilprozess (mit maxess-spezifischen Modellelementen als für den „Super-Markt“ nicht relevant) entfernt werden. Die sieben weiteren Aktivitäten sind Basis-Aktivitäten, die in jedem Prozess – unanhängig

114


vom gewählten Kunden – enthalten sind. Im Folgenden werden die einzelnen Schritte des Konfigurationsprozesses beschrieben und illustriert. 2.2 adapt(x)-Konfiguration Nachdem in adapt(x) das zugehörige EPK-Modell als Referenzmodell angelegt und ausgewählt ist, müssen die benötigten Konfigurationsparameter angelegt werden. Wie bereits in der Motivation erläutert, gibt es im Nutzungskontext von maxess nur den Kundennamen als Konfigurationsparameter. Mit dessen Hilfe wird die jeweilige Sicht auf das Referenzmodell gewählt und somit alle nicht benötigten Prozesselemente ausgeblendet. Der Kundenname wird daher als Parameter für die Konfiguration verwendet. In diesem Nutzungsszenario wird der Parameter Kunde als eine mögliche Perspektive gewählt und besitzt drei unterschiedliche – in diesem Beispiel hypothetische – Ausprägungen: „Hyper-Markt“, „Super-Markt“ und „Tante-Emma“ (vgl. Abbildung 4).

Abbildung 4: Konfigurationsparameter bei maxess

Durch das Anlegen dieser Konfigurationsparameter soll gewährleistet werden, dass die EPK-Modelle aus dem Referenzmodell mit Hilfe des Kundennamen konfiguriert werden können. Mit der Spezifikation der Konfigurationsparameter ist die Konfigurationsvorbereitung innerhalb von adapt(x) für die Umsetzung des maxess Nutzungsszenarios zunächst abgeschlossen. In den folgenden Abschnitten werden die Konfigurationsabläufe dargestellt, die zur Erzeugung der kundenspezifischen Modelle notwendig sind. Bei maxess werden zwei Konfigurationsmechanismen verwendet – die Elementselektion über Konfigurationsterme und die Elementselektion über Konfigurationsattribute.


115

2.3 Erzeugung von Kundenvarianten mithilfe der Elementselektion über Konfigurationsterme Um ein in ARIS modelliertes EPK-Modell konfigurieren zu können, müssen die kundenspezifischen bzw. varianten Prozesselemente ausgewählt und Konfigurationstermen zugewiesen werden. Dies hat zur Folge, dass je nach den gewählten Konfigurationsparametern – bspw. nur der selektierte Kunde „Super-Markt“ – die irrelevanten EPK-Modellelemente ausgeblendet werden bzw. die relevanten im Modell enthalten bleiben.

Abbildung 5: Zuordnung eines Konfigurationsterms zu Modellelementen, die nur für den Kunden „Super-Markt“ relevant sind

Dazu wird der für den Kunden „Super-Markt“ relevante Teilprozess selektiert und mithilfe des von adapt(x) zur Verfügung gestellten Makros ein Konfigurationsterm angelegt. Im vorliegenden Fall werden durch das Anlegen des Terms „Kunde=Super-Markt“ (vgl. Abbildung 5) die selektierten Modellelemente nach einer Konfiguration nur noch dann angezeigt, wenn der entsprechende Konfigurationsparameter „Kunde=Super-Markt“ gewählt wurde.

116


Modellelementen, die nur für den Kunden „Super-Markt“ ausgeblendet werden sollen, wird entsprechend ein „umgekehrter“ Konfigurationsterm „NOT Kunde=Super-Markt“ zugewiesen (vgl. Abbildung 6).

Abbildung 6: Zuordnung eines Konfigurationsterms zu einem Modellelement, das nur für den Kunden „Super-Markt“ irrelevant ist

Nachdem den einzelnen Modellelementen die Konfigurationsterme zugewiesen sind, kann die eigentliche Konfiguration gestartet werden. Hierzu wird das Referenzmodell mit Hilfe der zur Verfügung stehenden Exportfunktion aus ARIS exportiert und in adapt(x) importiert. Von adapt(x) aus wird dann die eigentliche Konfiguration gestartet. Dazu wird zuerst eine Auswahl der relevanten Konfigurationsparameter vorgenommen. Im Beispielszenario und im Nutzungskontext von maxess ist dies nur der Kundenname. Soll das Modell für den Kunden „SuperMarkt“ konfiguriert werden, so ist in der Konfigurationsumgebung von adapt(x) der entsprechende Konfigurationsparameter zu wählen (vgl. Abbildung 7).


Abbildung 7: Konfigurationseinstellungen für den Kunden „Super-Markt“

Abbildung 8: Konfiguriertes Modell für den Kunden „Super-Markt“

117

118


Als Ergebnis der Konfiguration wird das Referenzmodell um alle Modellelemente gekürzt, die als nicht relevant für den Kunden „Super-Markt“ deklariert wurden. Im vorliegenden Fall gehört hierzu nur eine einzige Funktion, nämlich diejenige, die sich vor der Konfiguration zwischen den maxess-spezifischen Modellelementen „Nicht-Super-Markt“ befunden hat. Alle anderen Elemente sind für den Kunden „Super-Markt“ relevant. Es wurden ihnen entweder explizit ein Konfigurationsterm zugewiesen, der sie als „Super-Markt“-relevant einstuft, oder ihnen wurde überhaupt keine Konfigurationsinformation annotiert, weshalb sie als Basiselemente eingestuft werden und für alle Varianten gültig sind (vgl. Abbildung 8). Entsprechend kann das Referenzmodell bspw. für den Kunden „HyperMarkt“ konfiguriert werden. Analog ist das Referenzmodell nach adapt(x) zu exportieren und im Anschluss in der Konfigurationsumgebung der Konfigurationsparameter „Hyper-Markt“ auszuwählen (vgl. Abbildung 9).

Abbildung 9: Konfigurationseinstellungen für den Kunden „Hyper-Markt“

Das konfigurierte Modell zeigt nun alle allgemein relevanten Modellelemente sowie auch diejenigen, die nur für den „Super-Markt“ irrelevant sind. Ausgeblendet werden hingegen diejenigen Modellelemente, die nur für den „Super-Markt“ relevant sind (vgl. Abbildung 10). Die Modellkonfiguration läuft für den „Hyper-Markt“ in dieser Weise ab, da für den „Hyper-Markt“ keine expliziten Konfigurationseinstellungen im Referenzmodell enthalten sind. Die Struktur des „Hyper-Markt“Modells ist folglich – bis auf die allgemein gültigen Modellelemente – invers zu der des „Super-Markt“-Modells. Gleiches gilt – vorausgesetzt es


119

werden keine weiteren Konfigurationseinstellungen vorgenommen – für das hier nicht betrachtete und hypothetische „Tante-Emma“-Modell. ...

LO-Gewicht (kg) pflegen

Sammelplat ztypzuordn en

Nicht-SuperMarkt

Ist-MHD der WE-Pos pflegen

Super-Markt

Einlagerung shöhe pflegen

Zur WE-Pos zugeordnet es THM...

Chargen-Nr. zur WE-Pos pflegen


Nicht-SuperMarkt

Super-Markt

Daten der WEPosition...

...

Abbildung 10: Konfiguriertes Modell für den Kunden „Hyper-Markt“

Die Ergebnismodelle sind insbesondere für den maxess-internen Gebrauch wertvoll, da mit ihrer Hilfe ein Vergleich der unterschiedlichen Kundenmodelle gut durchgeführt werden kann. So sind sowohl im „Super-Markt“als auch im „Hyper-Markt“-Modell noch immer die maxess-spezifischen Modellelemente enthalten, anhand derer festgestellt werden kann, wie sich die aktuelle Modellvariante von anderen unterscheidet. Bspw. ist im „Hyper-Markt“-Modell ersichtlich, welche Modellelemente im „Super-Markt“Modell nicht enthalten sind, und dass im „Super-Markt“-Modell Zusatzinformationen enthalten sind, die für das „Hyper-Markt“-Modell ausgeblendet sind. Zwar sind diese Informationen auch im Gesamtmodell – dem Referenzmodell – enthalten, jedoch hier in einer wesentlich übersichtlicheren Form. Dies ist insbesondere dann der Fall, wenn das Referenzmodell sehr umfangreich ist und Varianten für viele verschiedene Kunden enthält. Sollen die kundenindividuellen Modelle allerdings dem Kunden selbst zur Verfügung gestellt werden, ist die Darstellung solcher Zusatzinformationen zu unterbinden. Schließlich ist es ggf. nicht erwünscht, dass ein Kunde Informationen darüber erhält, dass bspw. ein anderer Kunde für den gleichen Geschäftsprozess zusätzliche Funktionalität erhält. Aus diesen Grund wird bei maxess zusätzlich der Konfigurationsmechanismus der Elementselektion über Konfigurationsattribute verwendet,

120


um auf einfache Weise maxess-spezifische Modellelemente auszublenden, wenn die Modelle den Kunden zur Verfügung gestellt werden sollen. 2.4 Ausblenden von maxess-spezifischen Modellelementen mit der Elementselektion über Konfigurationsattribute Für die Ausblendung von maxess-spezifischen Modellelementen wird in adapt(x) ein neuer Konfigurationsparameter angelegt, der bei einer Konfiguration immer dann zusätzlich zu einem Kunden gewählt wird, wenn das Modell dem Kunden selbst zur Verfügung gestellt werden soll. Entsprechend wird der Parameter „maxess-extern“ genannt (vgl. Abbildung 11).

Abbildung 11: Definition eines zusätzlichen Konfigurationsparameters zur Ausblendung von maxess-spezifischen Modellelementen

Für die Elementselektion über Konfigurationsattribute werden in adapt(x) Regeln spezifiziert, die vorgeben, welche Attribute im Modell dafür sorgen dass ein Modellelement ausgeblendet wird. Zur Ausblendung von maxessspezifischen Elementen wird eine solche Konfigurationsregel angelegt. Es wird festgelegt für welche Art von Modellelementen die Regel gültig sein soll. Da die maxess-spezifischen Modellelemente dem Typ „Funktion“ zugeordnet sind, also lediglich anders dargestellt sind als die anderen im Modell enthaltenen grün gefärbten Funktionen, wird als gültiger Elementtyp die „Funktion“ ausgewählt. Weiterhin ist festzulegen, welches Attribut eine Funktion besitzen und wie dieses Attribut ausgeprägt sein muss, damit die Funktion ausgeblendet wird. Im Regeleditor wird festgelegt, dass einer Funktion das Attribut „maxesselement“ zugeordnet sein muss, welches die Ausprägung „TRUE“ trägt. Hiermit wird impliziert, dass es sich bei dem markierten Element um ein maxess-spezifisches Modellelement handelt. Gemäß dem Ziel der Regel wird sie mit „maxess-spezifische Elemente ausblenden“ bezeichnet (vgl. Abbildung 12).


121

Abbildung 12: Anlegen einer Konfigurationsregel zur Ausblendung von maxessspezifischen Modellelementen

Abbildung 13: Zuordnung der neuen Konfigurationsregel zum Konfigurationsparameter „maxess-extern“

122


Schließlich wird die angelegte Konfigurationsregel demjenigen Konfigurationsparameter zugewiesen, bei dessen Auswahl sie aktiv werden soll. In diesem Fall wird die Regel dem Konfigurationsparameter „maxess-extern“ zugewiesen, da gerade dieser für die Ausblendung von maxess-spezifischen Modellelementen genutzt werden soll (vgl. Abbildung 13). Innerhalb von adapt(x) sind die zusätzlichen Konfigurationseinstellungen nun abgeschlossen. In ARIS sind nun den maxess-spezifischen Modellelementen entsprechende Konfigurationsattribute zuzuweisen, die sie als maxess-spezifische Modellelemente ausweisen. Hierzu werden die Elemente markiert und der Editor für Konfigurationsattribute gestartet. Das in adapt(x) angelegte Konfigurationsattribut „maxesselement“ ist dem Editor bereits bekannt, und es kann den markierten Elementen mit der Ausprägung „TRUE“ zugewiesen werden (vgl. Abbildung 14). Hiermit sind sämtliche Konfigurationseinstellungen abgeschlossen.

Abbildung 14: Zuordnung des Konfigurationsattributs „maxesselement=TRUE“ zu maxess-spezifischen Modellelementen


123

Abbildung 15: Konfigurationseinstellungen für den Kunden „Super-Markt” mit zusätzlicher Ausblendung von maxess-spezifischen Modellelementen

Abbildung 16: Konfiguriertes Modell für den Kunden „Super-Markt“ ohne maxess-spezifische Modellelemente

124


Abbildung 17: Konfigurationseinstellungen für den Kunden „Hyper-Markt” mit zusätzlicher Ausblendung von maxess-spezifischen Modellelementen

Abbildung 18: Konfiguriertes Modell für den Kunden „Hyper-Markt“ ohne maxess-spezifische Modellelemente

Soll das Referenzmodell nun für einen spezifischen Kunden konfiguriert werden, und sollen ebenfalls alle maxess-spezifischen Elemente ausgeblendet werden so sind in der Konfigurationsumgebung von adapt(x) je-


125

weils der Konfigurationsparameter für den Kunden und der Konfigurationsparameter „maxess-extern“ auszuwählen (vgl. für den „Super-Markt“ Abbildung 15 sowie für den „Hyper-Markt“ Abbildung 17). Nach der Konfiguration stehen nun die kundenspezifischen Modelle zur Verfügung, die von den maxess-spezifischen Modellelementen bereinigt sind (vgl. für den „Super-Markt“ Abbildung 16 sowie für den „Hyper-Markt“ Abbildung 18).

3

Fazit

Das bisher angewendete Verfahren zur Verwaltung von Kundenvarianten in Prozessmodellen bei maxess gestaltet sich äußerst aufwändig. Bis dato musste die Zuordnung von Modellelementen zu Kunden durch explizite Auswahl jedes Elementes und Bearbeitung des dazugehörigen Attributes erfolgen. Die manuelle Eingabe und Pflege der Kundenattribute für jedes Objekt ist mit hohem Aufwand und Fehleranfälligkeit verbunden. Durch die Verwendung von adapt(x) wird mittels einer einfachen Mehrfachselektion ganzer Prozessteile – aber auch kompletter Prozessmodelle – eine schnelle Zuordnung der Elemente zu einem speziellen Kunden ermöglicht. Hiermit wird eine wesentliche Verringerung des Arbeitsaufwands erreicht. Eine weitere Unzulänglichkeit des bisherigen Verfahrens, die nur partielle Ausblendung von irrelevanten Modellelementen durch „Ausgrauen“, was als eine Beeinträchtigung der Übersichtlichkeit empfunden wird, wird von adapt(x) ebenfalls eliminiert. Somit war es in der Vergangenheit möglich, dass Kunden ein aus Ihrer Sicht unvollständiges Prozessmodell mit ins Leere bzw. in leere, aber grau gefärbte Elemente laufenden Kanten erhielten. Zur Erhöhung der Übersichtlichkeit der konfigurierten Prozessmodelle blendet adapt(x) automatisch unnötige Kanten und Konnektoren aus. Dies vereinfacht und beschleunigt die Anpassung der Modelle an kundenspezifische Anforderungen. In speziellen Fällen bezieht adapt(x) den Benutzer zur Kantenführung mit ein, wenn durch eine kundenspezifische Konfiguration eine nicht eindeutige Kantenführung gewährleistet ist. Hierbei wird der Anwender durch eine Anleitung unterstützt. Durch die Verwendung von Makros innerhalb von ARIS wirkt die Konfigurationsumgebung adapt(x) nicht wie eine entkoppelte Softwarelösung sondern integriert sich in die gewohnte Bedienung. Das Erzeugen perspektivenabhängiger Varianten ist intuitiv und liefert gute Ergebnisse. Als Anregung für die weitere Entwicklung wird einerseits die Einbindung von Mechanismen zur Reintegration von veränderten Modellvarianten mit dem Referenzmodell vorgeschlagen (vgl. hierzu auch die Diskussion im Aus-

126


blick des Beitrags von PATRICK DELFMANN, TOBIAS RIEKE und ARMIN STEIN in diesem Band). Andererseits kann eine automatische Layoutoptimierung, die sich an die Konfiguration anschließt, zu einer weiteren Begrenzung des Anpassungsaufwands beitragen.

Autorenverzeichnis

Thomas Andres IDS Scheer AG Altenkesseler Straße 17 D-66155 Saarbrücken Tel.: +49 (0)681 210 3800 Fax: +49 (0)681 210 1801 E-Mail: [email protected] Prof. Dr. Jörg Becker Westfälische Wilhelms-Universität Münster European Research Center for Information Systems Leonardo-Campus 3 D-48149 Münster Tel.: +49 (0)251 83 38100 Fax: +49 (0)251 83 38109 E-Mail: [email protected] Dr. Patrick Delfmann Westfälische Wilhelms-Universität Münster European Research Center for Information Systems Leonardo-Campus 3 D-48149 Münster Tel.: +49 (0)251 83 38083 Fax: +49 (0)251 83 28083 E-Mail: [email protected]

128

Autorenverzeichnis

Michael Eisenbarth Fraunhofer Institut für Experimentelles Software Engineering Requirements and Usability Engineering Department Fraunhofer-Platz 1 D-67663 Kaiserslautern Tel.: +49 (0)631 6800 2181 Fax: +49 (0)631 6800 1499 E-Mail: [email protected] Claus Ködel maxess systemhaus gmbh Europaallee 3-5 D-67657 Kaiserslautern Tel.: +49 (0)631 303 2500 Fax: +49 (0)631 303 2501 E-Mail: [email protected] Yves Lauer IDS Scheer AG Altenkesseler Straße 17 D-66155 Saarbrücken Tel.: +49 (0)681 210 3800 Fax: +49 (0)681 210 1801 E-Mail: [email protected] Prof. Dr. Peter Loos Universität des Saarlandes Deutsches Forschungszentrum für Künstliche Intelligenz Stuhlsatzenhausweg 3 D-66123 Saarbrücken Tel.: +49 (0)681 302 3106 Fax: +49 (0)681 302 3696 E-Mail: [email protected]

Autorenverzeichnis

Tobias Rieke Westfälische Wilhelms-Universität Münster European Research Center for Information Systems Leonardo-Campus 3 D-48149 Münster Tel.: +49 (0)251 83 38072 Fax: +49 (0)251 83 28072 E-Mail: [email protected] Christian Seel Universität des Saarlandes Deutsches Forschungszentrum für Künstliche Intelligenz Stuhlsatzenhausweg 3 D-66123 Saarbrücken Tel.: +49 (0)681 302 5145 Fax: +49 (0)681 302 3696 E-Mail: [email protected] Armin Stein Westfälische Wilhelms-Universität Münster European Research Center for Information Systems Leonardo-Campus 3 D-48149 Münster Tel.: +49 (0)251 83 38085 Fax: +49 (0)251 83 28085 E-Mail: [email protected] Julia Wagner IDS Scheer AG Altenkesseler Straße 17 D-66155 Saarbrücken Tel.: +49 (0)681 210 3878 Fax: +49 (0)681 210 1801 E-Mail: [email protected]

129

Effiziente Softwareentwicklung mit Referenzmodellen

Objektorientierte Softwareentwicklung mit Smalltalk (Objekttechnologie)

Professionelle Softwareentwicklung mit PHP 5 GERMAN

Komponentenbasierte Softwareentwicklung: mit MDA, UML und XML

Komponentenbasierte Softwareentwicklung mit MDA, UML und XML

Softwareentwicklung kompakt und verständlich

Effiziente numerische Algorithmen 001.ps.gz

Ersatzteilmanagement: Effiziente Ersatzteillogistik für Industrieunternehmen

Softwareentwicklung in C

Softwareentwicklung in C++

Ladungstransportschichten für effiziente organische Halbleiterbauelemente

Produktive Anarchie? Netzwerke freier Softwareentwicklung German

Numerische Verbrennungssimulation: Effiziente numerische Simulation turbulenter Verbrennung

Agentenorientierte Softwareentwicklung : Methoden Und Werkzeuge

Numerische Verbrennungssimulation: Effiziente numerische Simulation turbulenter Verbrennung

Softwareentwicklung kompakt und verständlich: Wie Softwaresysteme entstehen

Softwareentwicklung: Einstieg für Anspruchsvolle (Master Class)

Softwareentwicklung eingebetteter Systeme: Grundlagen, Modellierung, Qualitätssicherung (Xpert.Press)

Agile fachmodellgetriebene Softwareentwicklung für mittelständische IT-Projekte

Effiziente Vielfalt: Die dritte Revolution in der Automobilindustrie German

Effiziente homoopathische Behandlung: Ein strukturiertes Konzept fur den Praxisalltag

Softwareentwicklung von Telematikdiensten: Konzepte, Entwicklung und zukünftige Trends (VDI-Buch)

Effiziente Planung. Beitrag zu einer erfolgreichen Unternehmenssteuerung GERMAN

Mit Familienanschluß

MIT Conference

Konstruieren mit SolidWorks. Mit CD-ROM

Interview mit

Mit Familienanschluс

Interview mit

Mit Familienanschluс

Mit Teufelsg'walt

Effiziente Softwareentwicklung mit Referenzmodellen

Objektorientierte Softwareentwicklung mit Smalltalk (Objekttechnologie)

Professionelle Softwareentwicklung mit PHP 5 GERMAN

Komponentenbasierte Softwareentwicklung: mit MDA, UML und XML

Komponentenbasierte Softwareentwicklung mit MDA, UML und XML

Softwareentwicklung kompakt und verständlich

Effiziente numerische Algorithmen 001.ps.gz

Ersatzteilmanagement: Effiziente Ersatzteillogistik für Industrieunternehmen

Softwareentwicklung in C

Softwareentwicklung in C++

Ladungstransportschichten für effiziente organische Halbleiterbauelemente

Produktive Anarchie? Netzwerke freier Softwareentwicklung German

Numerische Verbrennungssimulation: Effiziente numerische Simulation turbulenter Verbrennung

Agentenorientierte Softwareentwicklung : Methoden Und Werkzeuge

Numerische Verbrennungssimulation: Effiziente numerische Simulation turbulenter Verbrennung

Softwareentwicklung kompakt und verständlich: Wie Softwaresysteme entstehen

Softwareentwicklung: Einstieg für Anspruchsvolle (Master Class)

Softwareentwicklung eingebetteter Systeme: Grundlagen, Modellierung, Qualitätssicherung (Xpert.Press)

Agile fachmodellgetriebene Softwareentwicklung für mittelständische IT-Projekte

Effiziente Vielfalt: Die dritte Revolution in der Automobilindustrie German

Effiziente homoopathische Behandlung: Ein strukturiertes Konzept fur den Praxisalltag

Softwareentwicklung von Telematikdiensten: Konzepte, Entwicklung und zukünftige Trends (VDI-Buch)

Effiziente Planung. Beitrag zu einer erfolgreichen Unternehmenssteuerung GERMAN

Mit Familienanschluß

MIT Conference

Konstruieren mit SolidWorks. Mit CD-ROM

Interview mit

Mit Familienanschluс

Interview mit

Mit Familienanschluс

Mit Teufelsg'walt

Recommend Documents