Process Landscaping
Eine Methode zur Modellierung und Analyse
verteilter Softwareprozesse
Dissertation
zur Erlangung des Grades eines
DOKTORS DER NATURWISSENSCHAFTEN
der Universität Dortmund
am Fachbereich Informatik
von
Ursula Wellen
Dortmund
2003

Zusammenfassung
Die Betrachtung komplexer Softwareentwicklungsprozesse erfordert nicht nur die
Berücksichtigung der traditionellen Entwicklungsphasen wie Anforderungsdefinition,
Analyse, Entwurf, Implementation und Test, sie verlangt eine ganzheitliche Betrach-
tung aller Aktivitäten rund um ein Softwareentwicklungsprojekt. Mit einer solchen
ganzheitlichen Betrachtung wird eine Reihe unterschiedlicher Ziele verfolgt. Dazu
zählen vor allem die Dokumentation und Analyse von Softwareentwicklungsprozes-
sen zum einen für Präsentations- und Schulungszwecke z.B. für neue Mitarbeiter eines
Softwareunternehmens, zum anderen für die Identifikation von Optimierungsansätzen
des Softwareentwicklungsprozesses mit dem letztendlichen Ziel, ein qualitativ hoch-
wertiges Softwareprodukt zu erstellen. Unabhängig vom konkreten Ziel der Betrach-
tung startet diese zumeist mit der Erstellung von Prozessmodellen. Die Modelle sollen
ein möglichst vollständiges und verständliches Bild der realen Prozesse widerspiegeln.
Die Aufgabe der Erstellung solcher Modelle wird um einiges komplexer, wenn es um
die Abbildung einer geografisch verteilten Entwicklung für Softwaresysteme geht.
Mit Process Landscaping wird im Rahmen dieser Dissertation eine Methode ent-
wickelt und validiert, die bisher nicht oder nur unzureichend berücksichtigte Aspekte
bei der Dokumentation und Analyse verteilt stattfindender Softwareentwicklungspro-
zesse beinhaltet. Dazu zählt insbesondere die Unterstützung bei der Erstellung eines
konsistenten Gesamtbildes einer großen Menge von Prozessmodellen auf unterschied-
lichen Abstraktionsebenen und dessen Analyse aus unterschiedlichen Blickwinkeln.
Die unterschiedlichen Blickwinkel resultieren beim Process Landscaping aus einer lo-
gischen, die Durchführungsreihenfolge von Aktivitäten berücksichtigenden, und ei-
ner verteilungsspezifischen Sicht. Die Modellierung der oberen Abstraktionsebenen
erlaubt insbesondere auch eine Analyse unstrukturierter Prozesse, die kein festes Ab-
laufverhalten aufweisen. Ein Schwerpunkt der Methode liegt auf der Identifikation,
Dokumentation und Analyse von Schnittstellen zwischen Prozessen und zwischen ein-
zelnen Aktivitäten innerhalb eines Prozesses. Dieser Schwerpunkt berücksichtigt da-
mit auch den Verteilungsaspekt komplexer Softwareentwicklungsprozesse. Die Ana-
lyseziele des Process Landscaping konzentrieren sich auf verschiedene Kommunika-
tionseigenschaften der betrachteten Prozesse, die sich entweder aus ihrer statischen
Kommunikationsinfrastruktur ergeben oder aus ihrem (dynamischen) Kommunikati-
onsverhalten. Für die Anwendung der Methode wird eine Werkzeugunterstützung zur
Modellierung und Simulation präsentiert.
Danksagung
Diese Arbeit entstand am Lehrstuhl für Software-Technologie unter der Betreuung
von Herrn Prof. Dr. Volker Gruhn als Erstgutachter und Herrn Prof. Dr. Ernst-Erich
Doberkat als Zweitgutachter.
Bei der Erstellung dieser Dissertation wurde ich von vielen Personen unterstützt. Ohne
ihre Hilfsbereitschaft wäre es mir unmöglich gewesen, die Arbeit in der vorliegenden
Form zu erstellen.
Herrn Prof. Dr. Gruhn danke ich für die Betreuung während der Erstellung dieser Ar-
beit und für die Möglichkeit, meine Forschungsarbeit auch über Lehrveranstaltungen
in Form von Projektgruppen und Seminaren vorantreiben zu können. Herrn Prof. Dr.
Ernst-Erich Doberkat danke ich für die bereitwillige Übernahme des Zweitgutachtens.
Die intensiven Gespräche mit ihm und seine detaillierten Anmerkungen waren mir
eine wertvolle Hilfe.
Zunächst möchte ich mich bei allen Kollegen des Lehrstuhls für Software-Technologie
bedanken. Die gute kollegiale Atmosphäre hat mir sehr geholfen. Mein besonderer
Dank gilt hier Klaus Alfert, der mit mir in vielen Stunden konstruktiver Gespräche
die formale Seite der Petrinetze diskutiert hat. Seine zahlreichen Anmerkungen gegen
Ende der Arbeit waren in gleichem Maße von großem Wert. Georgios Lajios danke ich
für seine Unterstützung beim kritischen Umgang mit selbst erstellten Definitionen.
Den Studenten, die meine Forschungsarbeiten durch Diplomarbeiten und Projektgrup-
pen unterstützt haben, gebührt ebenfalls ein besonderer Dank. In alphabetischer Rei-
henfolge waren dies Carsten Brockmann, Andreas Pohlmann, Hartmut Reichelt, Marc
Störzel sowie alle Teilnehmer der Projektgruppe Palermo.
Auch außerhalb des Lehrstuhls haben viele Personen zum Gelingen dieser Arbeit bei-
getragen. Hier möchte ich vor allem Joachim Coutelle und Jörg Dickmann danken. Ih-
re Geduld und Mühe, die sich durch viele Stunden hilfreichen Kritisierens, geduldigen
Zuhörens und intensiver Diskussionen geäußert haben, haben zur Identifikation vieler
Verbesserungsmöglichkeiten und damit zum Fortschreiten dieser Arbeit beigetragen.
Ingrid Reck danke ich besonders herzlich für ihr intensives Korrekturlesen meiner Ar-
beit und für ihre ständige Bereitschaft zur Hilfestellung bei Formulierungsfragen.
Inhaltsverzeichnis
1 Einleitung 1
1.1 Einführung in das Forschungsgebiet der Softwareprozesstechnologie . 1
1.2 Zielsetzung der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3 Terminologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.4 Struktur der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2 Die Methode des Process Landscaping 15
2.1 Ziele und Grundsätze des Process Landscaping . . . . . . . . . . . . 16
2.2 Methodische Schritte zur Erstellung einer Prozesslandschaft . . . . . 19
2.2.1 Beispielprozesslandschaft der komponentenbasierten Software-
entwicklung . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2.2 Identifikation von Kernaktivitäten und ihren Schnittstellen . . 21
2.2.3 Verfeinerung von Kernaktivitäten bis auf Prozessmodellebene 23
2.2.4 Verfeinerung von Schnittstellen . . . . . . . . . . . . . . . . 26
2.2.5 Verfeinerung von Prozessmodellen . . . . . . . . . . . . . . . 27
2.2.6 Validation der modellierten Prozesslandschaft . . . . . . . . . 30
2.3 Methodische Schritte zur Analyse einer Prozesslandschaft . . . . . . 33
2.3.1 Umstrukturierung zur Erstellung unterschiedlicher Sichten auf
eine Prozesslandschaft . . . . . . . . . . . . . . . . . . . . . 34
2.3.2 Attributierung einer Prozesslandschaft zur Analyse statischer
Kommunikationseigenschaften . . . . . . . . . . . . . . . . . 37
2.3.3 Attributierung einer Prozesslandschaft zur Analyse dynami-
scher Kommunikationseigenschaften . . . . . . . . . . . . . 39
2.3.4 Interpretation statischer Kommunikationseigenschaften . . . . 42
2.3.5 Interpretation dynamischer Kommunikationseigenschaften . . 46
2.4 Vergleich mit existierenden Modellierungs- und Analyseansätzen . . . 48
3 Formale Basis des Process Landscaping 57
3.1 Notation der oberen Ebenen einer Prozesslandschaft . . . . . . . . . . 59
3.1.1 Basisdefinition und erste Ausbaustufe einer Prozesslandschaft 59
3.1.2 Grafische Repräsentation einer Prozesslandschaft . . . . . . . 73
3.1.3 Erweiterungen zur Analyse statischer Kommunikationseigen-
schaften . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
iii
Inhaltsverzeichnis
3.2 Notation der unteren Ebenen einer Prozesslandschaft . . . . . . . . . 94
3.2.1 Hinzufügen von Ablaufinformationen . . . . . . . . . . . . . 95
3.2.1.1 Erweiterung einer Prozesslandschaft zu einem
kohärenten Netz . . . . . . . . . . . . . . . . . . . 98
3.2.1.2 Festlegung der Schaltverhalten . . . . . . . . . . . 103
3.2.1.3 Anpassung der Verfeinerungskonzepte für die Mo-
dellierung der unteren Ebenen einer Prozesslandschaft115
3.2.1.4 Sonderfälle . . . . . . . . . . . . . . . . . . . . . . 118
3.2.2 Erweiterungen zur Analyse dynamischer Kommunikations-
eigenschaften . . . . . . . . . . . . . . . . . . . . . . . . . . 127
3.2.2.1 Umstrukturierung einer Prozesslandschaft in eine
lokale Sicht . . . . . . . . . . . . . . . . . . . . . 128
3.2.2.2 Erweiterungen zur vierten Ausbaustufe einer
Prozesslandschaft . . . . . . . . . . . . . . . . . . 137
3.3 Einordnung in den Bereich der Petrinetze . . . . . . . . . . . . . . . 146
4 Validation der Analysemethoden 155
4.1 Analyse statischer Kommunikationseigenschaften . . . . . . . . . . . 156
4.1.1 Struktur der Prozesslandschaft PLtop−com . . . . . . . . . . 157
4.1.2 Analyse der Kommunikationsinfrastruktur einer Prozessland-
schaft PLtop−com . . . . . . . . . . . . . . . . . . . . . . . 159
4.1.2.1 Analyse der Ausgangsbasis . . . . . . . . . . . . . 159
4.1.2.2 Analyse verschiedener Optimierungsansätze . . . . 164
4.1.3 Nutzenbetrachtung . . . . . . . . . . . . . . . . . . . . . . . 172
4.2 Analyse dynamischer Kommunikationseigenschaften . . . . . . . . . 174
4.2.1 Struktur der Prozesslandschaft PLcom . . . . . . . . . . . . . 174
4.2.2 Analyse der Kommunikationseffizienz einer Prozesslandschaft
PLcom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
4.2.2.1 Analyse der Ausgangsbasis . . . . . . . . . . . . . 177
4.2.2.2 Analyse verschiedener Optimierungsansätze . . . . 183
4.2.3 Nutzenbetrachtung . . . . . . . . . . . . . . . . . . . . . . . 188
5 Werkzeugunterstützung 191
5.1 Modellierung und Analyse der oberen Ebenen einer Prozesslandschaft 193
5.1.1 Unterstützung der Modellierungsphase . . . . . . . . . . . . 194
5.1.2 Unterstützung der Nutzungsphase . . . . . . . . . . . . . . . 197
5.2 Erweiterung zur Modellierung und Analyse unterer Ebenen . . . . . . 199
5.3 Modellierung und Simulation der unteren Ebenen einer Prozessland-
schaft . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
5.4 Status der Werkzeugunterstützung . . . . . . . . . . . . . . . . . . . 209
6 Zusammenfassung und Ausblick 211
6.1 Zusammenfassung der Arbeit . . . . . . . . . . . . . . . . . . . . . . 211
6.2 Ausblick auf weiterführende Arbeiten . . . . . . . . . . . . . . . . . 213
iv
Inhaltsverzeichnis
A Aufbau der Beispielprozesslandschaft 215
A.1 Prozesslandschaft ω . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
A.2 Detailinformationen zur statischen Analyse . . . . . . . . . . . . . . 218
A.3 Detailinformationen zur dynamischen Analyse . . . . . . . . . . . . . 262
Literaturverzeichnis 215
Abbildungsverzeichnis 286
Tabellenverzeichnis 291
v

Kapitel 1
Einleitung
1.1 Einführung in das Forschungsgebiet der Software-
prozesstechnologie
Seit mehr als 25 Jahren entstehen auf dem Forschungsgebiet der Softwareprozess-
technologie und in der Industrie immer neue Vorgehensmodelle zur Unterstützung
von Softwareentwicklungsprozessen, die einem besseren Management dieser Prozes-
se dienen sollen. Unter einem Vorgehensmodell ist hier eine Darstellung gemeint, „die
weitgehend den Softwareentwicklungsprozess beschreibt und auch Analysen des Pro-
zesses gestattet“ [Chr92]. Die Darstellung komplexer Softwareentwicklungsprozesse
erfordert nicht nur die Berücksichtigung der traditionellen Entwicklungsphasen wie
Anforderungsdefinition, Analyse, Entwurf, Implementation und Test, sie verlangt ei-
ne ganzheitliche Betrachtung aller Aktivitäten rund um ein Softwareentwicklungspro-
jekt. Dazu gehört das Projektmanagement mit all seinen organisatorischen und stra-
tegischen Aufgaben ebenso wie das Qualitätsmanagement und das Konfigurationsma-
nagement. Mit einer solchen ganzheitlichen Betrachtung wird eine Reihe unterschied-
licher Ziele verfolgt. Dabei bildet die Dokumentation der Prozesse die Grundlage für
Präsentations- und Schulungszwecke z.B. für neue Mitarbeiter eines Softwareunter-
nehmens; ihre Analyse dient der Identifikation von Optimierungsansätzen des Soft-
wareentwicklungsprozesses mit dem letztendlichen Ziel, ein qualitativ hochwertiges
Softwareprodukt zu erstellen.
Dass der Trend zur Erarbeitung immer weiterer Vorgehensmodelle auch weiterhin
nicht an Aktualität verliert, hat verschiedene Gründe:
 Entwicklungsparadigmen wie z.B. die objektorientierte oder die komponenten-
basierte Softwareentwicklung haben einen großen Einfluss auf die Vorgehens-
strategien und damit auch auf die Vorgehensmodelle. Mit der Evolution exis-
tierender und der Generierung neuer Paradigmen sind auch die Vorgehensmo-
delle einem stetigen Wandel unterworfen. Im Zusammenhang mit der objekt-
orientierten Softwareentwicklung ist beispielsweise der Unified Software De-
velopment Process entwickelt worden [JBR98], im Rahmen der komponenten-
1
Einleitung
basierten Softwareentwicklung ist unter anderem Select Perspective entstanden
[AF98].
 Viele Vorgehensmodelle sind für spezielle Anwendungsdomänen erstellt wor-
den. Neue Domänen, wie zum Beispiel der e-business- und der Multimedia-
Bereich, erfordern spezielle und damit auch wieder neue Vorgehensmodelle.
Aktuell beschäftigt sich die Softwareprozesstechnologie verstärkt mit Unterstüt-
zungsmöglichkeiten für das Gebiet des Mobile Computing [WC01] und – An-
wendungsgebiete übergreifend – Web-basierten Prozessen. Die unterstützenden
Web-basierten Systeme bezeichnen in diesem Zusammenhang „Software, die es
ermöglicht, Geschäftsvorfälle über das World Wide Web abzuwickeln“ [Col02].
 Die zunehmende Globalisierung vieler Unternehmen hat einen erhöhten Vertei-
lungsgrad eines Softwareprozesses zur Folge, der wiederum andere Vorgehens-
weisen für sein Management notwendig macht. Die RWTH Aachen beschäftigt
sich beispielsweise mit der Delegation verteilter Prozesse [BJSW01]. Aber auch
die zuvor genannten Anwendungsdomänen zeichnen sich durch Prozesse aus,
die insbesondere den Verteilungsaspekt beinhalten.
Neben diesen eher aspektorientierten Forschungsgebieten rund um das Thema der Vor-
gehensmodelle gibt es Bemühungen, verbesserte Beschreibungsmöglichkeiten für Pro-
zesse zu entwickeln. Hier ist vor allem das Schlagwort Process Pattern zu nennen
[Stö01a]. Die ersten Arbeiten zum Thema Pattern allgemein erschienen Ende der 70er
Jahre unter anderem mit [AISJ77] und [Ale79]. Ein Pattern wird hier wie folgt be-
schrieben:
„Each pattern describes a problem that occurs over and over again in our environment
and then describes the core of the solution to that problem in such a way that you can
use this solution a million times over without ever doing it the same way twice.“ (zitiert
in [RJ00]).
Das Konzept der Pattern-Verwendung bezieht sich dort auf das Anwendungsgebiet der
Gebäudearchitektur. Es wurde von Gamma et al. mit der Entwicklung von Design Pat-
tern auf das Gebiet der Softwaretechnologie übertragen [GHJV94] und findet inzwi-
schen auch auf dem Gebiet der Softwareprozesstechnologie Verwendung [Amb98].
Der Einsatz von Process Pattern unterstützt jedoch keine dynamischen Analysen und
auch nicht die Automatisierung der zugrundeliegenden Prozesse. Aus diesem Grund
werden auch weiterhin bereits bekannte Prozessmodellierungssprachen wie unter an-
derem Little-Jil [SOSW98], APEL [DEA98] oder die ereignisgesteuerten Prozessket-
ten [LSW97] sowie die vielfach eingesetzten und in unterschiedlichen Varianten exis-
tierenden Petrinetze [Bau96] verwendet und weiterentwickelt.
Ein weiteres Schlagwort auf dem Gebiet der Softwareprozesstechnologie ist PSEE
(Process-sensitive Software Engineering Environment). Es ist im Zusammenhang mit
einem der Kernziele der Softwareprozesstechnologie entstanden, der informations-
technischen Prozessunterstützung [DKW99]. Eine PSEE wird von einer Process En-
gine, beispielsweise einem Interpreter einer Prozessmodellierungssprache, gesteuert.
2
1.1 Einführung in das Forschungsgebiet der Softwareprozesstechnologie
Diese kontrolliert den Informationsfluss zwischen den Arbeitsplätzen der verschie-
denen Prozessbeteiligten gemäß einem zugrundeliegenden Prozessmodell. Letzteres
wird zusammen mit Informationen über ein zu entwickelndes Softwareprodukt sowie
den Prozessstatus in einem Repository verwaltet.
Unabhängig vom konkreten Ziel der Dokumentation, Analyse oder informationstech-
nischen Unterstützung verschiedener Prozesse erfordert jedes Ziel zunächst die Er-
stellung von Prozessmodellen. Sie dienen sowohl als fachlich bestimmte Grundlage
der Softwarerealisierung als auch teilweise zur Festlegung der Kontrollstrukturen ei-
nes Prozesses. Die Modelle sollen ein möglichst vollständiges und verständliches Bild
der realen Prozesse widerspiegeln. Die Aufgabe der Erstellung solcher Modelle wird
um einiges komplexer, wenn es um die Abbildung einer geografisch verteilten Soft-
wareentwicklung für Softwaresysteme geht. Die Berücksichtigung von Schnittstellen
zwischen und innerhalb von Prozessen gewinnt hier besonders an Bedeutung.
In [CDP95] werden laut der Autoren erstmals Schnittstellen explizit betrachtet bzw.
wird beschrieben, welche Erkenntnisgewinne dabei erzielt werden konnten. Die Vor-
gehensweise für diese Betrachtung war hierbei bottom-up, d.h. man identifizierte und
beschrieb die Schnittstellen zwischen den Prozessen zweier Unternehmen entlang ihrer
Prozessmodelle und fasste sie zu Gruppen zusammen. Auf diese Weise konnten neben
der stark variierenden Granularität der Schnittstellenbeschreibungen auch viele Inkon-
sistenzen sowohl in den Prozessen als auch in den entsprechenden Prozessmodellen
aufgedeckt werden. Ein Top-Down-Ansatz, der Schnittstellen von Beginn eines Mo-
dellierungsprojektes an explizit berücksichtigt, würde einer starken Varianz der Gra-
nularität entgegenwirken, Inkonsistenzen im Prozess eher aufdecken und im Modell
gänzlich vermeiden, weil diese schon bei der Wissensakquise vor der Modellerstellung
oder spätestens während der Modellierung identifiziert würden. Ein solcher Ansatz
ist – zumindest in den einschlägigen Zeitschriften und auf Konferenzen, die sich mit
dem Thema der Softwareprozessmodellierung beschäftigen – nicht identifiziert wor-
den. Die vorangegangene Diskussion zeigt hier jedoch deutlich einen entsprechenden
Handlungsbedarf.
Neben der Berücksichtigung von Schnittstellen bei der Modellierung von geografisch
verteilt durchgeführter Softwareentwicklung spielt die Kommunikation der verteilt ar-
beitenden Prozessbeteiligten eine immer bedeutendere Rolle. Diese Kommunikation
wird derzeit meist mit Fokus auf deren informationstechnische Unterstützung, etwa
durch Workflowmanagementsysteme [BT98] oder andere CSCW-Systeme (Group-
ware, etc.) [Hay00], analysiert. Eine Kommunikationsanalyse mit dem Ziel der Kom-
munikationsoptimierung erfordert jedoch nicht nur eine Analyse der hierfür einge-
setzten Systeme, sondern auch des Kommunikationsverhaltens und der systemunab-
hängigen Eigenschaften einer Kommunikationsinfrastruktur auf einem anderen Ab-
straktionsniveau. Dieses muss die geografische Verteilung der Kommunikationspart-
ner und ihre Kommunikationsintensität untereinander stärker als bislang berücksichti-
gen. Sitzen Prozessbeteiligte, die häufig miteinander kommunizieren müssen, in einem
verteilt ablaufenden Prozess geografisch weit auseinander, kann kein noch so perfor-
mantes Kommunikationssystem diese ineffiziente Verteilung der partizipierenden Pro-
3
Einleitung
zessbeteiligten ausgleichen. Da die bislang zur Verfügung stehenden Analysemetho-
den das Kommunikationsverhalten der Prozessbeteiligten nicht unter dem Aspekt ihrer
geografischen Verteilung untersuchen und die für die Kommunikation erforderlichen
Eigenschaften einer zugrundeliegenden Infrastruktur immer systemabhängig betrach-
tet werden, ergeben sich neue Anforderungen an diese Analysemethoden bzw. es ergibt
sich die Forderung nach geeigneten neuen.
Eine Konzentration auf Kommunikationseigenschaften von verteilten Prozessen be-
züglich Infrastruktur und Verhalten erfordert für deren Analyse eine geeignete Model-
lierung, die auch die Fragen beantwortet, wo welche Informationen gehalten werden
und welche Prozessteilnehmer diese über welche Standorte hinweg austauschen. Die-
se Fragen können teilweise, wie bei der Fokussierung auf andere Aspekte innerhalb
eines Softwareentwicklungsprozesses (beispielsweise verschiedene beteiligte Rollen)
oft propagiert, durch die Erstellung spezifischer Prozessmodelle beantwortet werden,
deren Integration einen Gesamtüberblick über alle Aspekte der modellierten Prozes-
se verschafft [FKN+92]. Diese Integration ist jedoch mit einem großen Kontrollauf-
wand verbunden, da sowohl Redundanzen als auch Inkonsistenzen entstehen können.
Wünschenswert wäre eine Möglichkeit der Fokussierung durch die Veränderung des
Blickwinkels auf ein einmal erstelltes Prozessmodell, d.h. eine Umordnung der Mo-
dellelemente von der Betrachtung ihrer logischen Abfolge zu einer Betrachtung der
Verteilung auf verschiedene Standorte. Die daraus resultierenden Erkenntnisse können
möglicherweise Aufschluss über Umstände geben, die bei der bisherigen Modellie-
rung nicht ohne weiteres erkennbar waren. Die anhaltende Diskussion über die Fra-
ge nach geeigneten Sichten zur Analyse bestimmter Aspekte und/oder der Integrati-
on bzw. Aggregation von Teilmodellen zu einem Gesamtmodell (vgl. beispielsweise
[MENW99, GEMT00]) zeigt, dass auch hier noch immer Forschungsbedarf vorhanden
ist.
Alle bislang angesprochenen Aspekte der (Software-)Prozessmodellierung werden
hauptsächlich bei strukturierten Prozessen untersucht. Diese klar definierten und wie-
derholbaren Prozesse sind relativ einfach abzubilden und z.B. durch Workflowmana-
gementsysteme gut zu unterstützen. Es gibt jedoch insbesondere in Klein- und Mit-
telbetrieben eine Vielzahl von Softwareprozessen, die sowohl auf Kreativität basie-
ren als auch auf daraus resultierender Flexibilität ihres Ablaufs. Diese aufgrund des
Fehlens einer festen Ablaufreihenfolge auch als unstrukturiert bezeichneten Prozesse
werden zurzeit nicht oder kaum durch geeignete Prozessmodellierung unterstützt. Oft
behilft man sich mit der Modellierung aller möglichen Ablaufalternativen, was jedoch
sehr aufwändig ist, immer die Gefahr der Unvollständigkeit birgt und die Kreativi-
tät der Prozessbeteiligten einschränkt. Zudem ist das Erkennen von Schwachstellen
unstrukturierter Prozesse und/oder eine gezielte Modifikation ohne eine angemessene
Dokumentation nicht oder nur schwer möglich. Für das Messen der Auswirkungen
von Modifikationen gilt das gleiche; weitere Gründe sind in [DD98] aufgeführt. Die
Suche nach einer geeigneten Form der Modellierung für diese Art von Softwarepro-
zessen ist bislang noch nicht abgeschlossen und erfordert daher ebenfalls das Ergreifen
entsprechender Maßnahmen.
4
1.1 Einführung in das Forschungsgebiet der Softwareprozesstechnologie
Manchmal ist es wünschenswert, Prozesse zunächst auf einem hohen Abstraktionsni-
veau abzubilden und sie erst zu einem späteren Zeitpunkt für bestimmte Analysen zu
verfeinern. Für diese Situationen ist es hilfreich, eine geeignete Vorgehensweise für
die Modellierung zur Hand zu haben, die über entsprechende Verfeinerungsmechanis-
men verfügt, so dass eine Neumodellierung für detaillierte Abbildungen entfällt und
so die Gefahr von Inkonsistenzen zwischen den groben und den detaillierten Model-
len gar nicht erst aufkommt. Zur Unterstützung von Prozessbeteiligten empfiehlt sich
zusätzlich eine geeignete grafische Darstellung der Prozessmodelle, da diese meist
leichter verständlich sind als mathematische Modelle. Für genaue Analysen ist jedoch
eine formale Grundlage erforderlich. Petrinetze erfüllen diese Anforderungen: Über
die Möglichkeit von Transitionsverfeinerungen ist ein geeignetes Verfeinerungskon-
zept zur Erstellung verschiedener Abstraktionsebenen gegeben [Bau96]. Die grafische
Darstellung eines Petrinetzes als bipartiter Graph erlaubt eine Visualisierung der Pro-
zessmodelle, während seine formale Grundlage exakte Analysen ermöglicht.
Die bekannten Petrinetz-Varianten haben jedoch den Nachteil, dass bei der Modellie-
rung immer auch ein Ablauf berücksichtigt werden muss, um das Modell formal kor-
rekt zu halten. Dies ist aber gerade bei den zuvor erwähnten unstrukturierten Prozessen
oft nicht gewünscht. Für sie ist daher eine geeignete Darstellungsform zu entwickeln.
Zusammenfassend sind in diesem Abschnitt fünf verschiedene Problemstellungen im
Bereich der Softwareprozesstechnologie identifiziert worden, nämlich
1. die mangelnde explizite Berücksichtigung von Schnittstellen innerhalb von und
zwischen Softwareprozessen,
2. die mangelnde Berücksichtigung der geografischen Verteilung von Prozessbe-
teiligten und die daraus resultierenden Auswirkungen auf deren Kommunikati-
onseffizienz,
3. die fehlende Möglichkeit der Betrachtung von Softwareprozessmodellen unter
verschiedenen Blickwinkeln ohne den Aufwand einer Neumodellierung oder ei-
ner Integration verschiedener Sichten,
4. die mangelnde Modellierungsunterstützung für unstrukturierte Softwareprozes-
se und schließlich
5. die mangelnde durchgängige Modellierungsunterstützung für Softwareprozesse,
die sowohl auf sehr abstraktem als auch – zumindest in Teilbereichen – auf sehr
detailliertem Niveau betrachtet werden sollen und die neben einer mathematisch
präzisen Darstellung auch ihre Visualisierung ermöglicht.
Aus diesen identifizierten und hier aufgeführten Problemstellungen ist die Motivation
für die vorliegende Arbeit entstanden. Die Erarbeitung geeigneter Lösungsmöglich-
keiten verbessert die Unterstützung sowohl der Prozessbeteiligten als auch des Pro-
zessmanagements, deren gemeinsames Ziel es ist, mit Hilfe eines verbesserten Soft-
wareprozesses effektiver ein qualitativ hochwertiges Softwareprodukt zu erstellen. Die
5
Einleitung
mangelnde Berücksichtigung von Schnittstellen zwischen Prozessen birgt insbeson-
dere durch die aktuell zunehmende Globalisierung von Unternehmen und der damit
einhergehenden geografischen Verteilung von Prozessen eine wachsende Gefahr, die
Menge der an einer Softwareentwicklung beteiligten Teilprozesse nur punktuell zu
verbessern, ohne eine tatsächliche Optimierung des Gesamtprozesses zu erreichen.
Die geografische Verteilung der Prozessbeteiligten erfordert des Weiteren eine Ana-
lyse und ggf. Optimierung des Kommunikationsverhaltens und systemunabhängiger
Kommunikationsstrukturen, die – wie bereits diskutiert – nicht durch die Analyse
und Optimierung verwendeter Kommunikationssysteme ersetzt werden können. Die
Umstrukturierung von Softwareprozessmodellen zur Erstellung verschiedener Sichten
vermeidet mögliche Inkonsistenzen in den Modellen, die bislang nur unzureichend ge-
handhabt werden können. Die fehlende oder zumindest unzureichende Modellierungs-
unterstützung für unstrukturierte Softwareprozesse nimmt Klein- und Mittelbetrieben
bislang die Möglichkeit, durch verbesserte Softwareprozesse eine Qualitätssteigerung
ihrer Softwareprodukte zu erreichen. Und schließlich werden auch viele Softwareun-
ternehmen durch die mangelnde durchgängige Modellierung ihrer Prozesse auf ver-
schiedenen Abstraktionsebenen davon abgehalten, die Prozessmodellierung als Mittel
zur Identifikation von Optimierungsansätzen einzusetzen.
Die Diskussion der Problemstellungen zeigt die Notwendigkeit auf, entsprechende Lö-
sungsansätze zu erarbeiten und diese den Prozessbeteiligten und -verantwortlichen zur
Verfügung zu stellen. Die Erarbeitung dieser Lösungsansätze ist Inhalt der vorliegen-
den Arbeit. Ihre konkrete Zielsetzung wird im folgenden Abschnitt erläutert.
1.2 Zielsetzung der Arbeit
Im Rahmen dieser Dissertation wird eine Methode entwickelt und validiert, mit der
verteilte Softwareprozesse modelliert und analysiert werden können. Ziel der Me-
thode ist es, die im vorangegangenen Abschnitt 1.1 aufgeführten Problemstellungen
aufzugreifen und geeignete Lösungsmöglichkeiten anzubieten. Bevor die Methode in
Kapitel 2 im Detail vorgestellt wird, wird kurz erläutert, wie sie zur Lösung dieser
Problemstellungen beiträgt.
Die Modellierung von Prozessmodellen setzt hier auf eine strukturierte und durch-
gängige Vorgehensweise, mit der nach dem Top-Down-Ansatz eine zusammenhän-
gende Menge von Prozessen über verschiedene Abstraktionsebenen mit unterschiedli-
chem Detaillierungsgrad abgebildet wird, ohne dass dabei der Gesamtüberblick verlo-
ren geht. Dazu werden dem Anwender für jeden Modellierungsschritt Techniken zur
Wissensakquise angeboten, die für den jeweils gewünschten Detaillierungsgrad an-
gemessen sind. Die durch die Darstellung der Softwareprozesse entstehende Menge
von Prozessmodellen, nachfolgend als Prozesslandschaft bezeichnet, hat der Methode
ihren Namen gegeben:
Process Landscaping
6
1.2 Zielsetzung der Arbeit
Ein Schwerpunkt des Process Landscaping liegt auf der Identifikation, Dokumentation
und Analyse von prozessübergreifenden und prozessinternen Schnittstellen zwischen
Aktivitäten innerhalb dieser Prozessmodelle. Die Methode berücksichtigt explizit die
im vorangegangenen Abschnitt zuerst genannte Problemstellung, indem bereits auf der
obersten Abstraktionsebene eines jeden Modells zumindest die Existenz von Schnitt-
stellen abgebildet wird. Diese Information kann über mehrere Verfeinerungsschritte
nach und nach detailliert werden, bis für eine Schnittstelle eine umfassende Beschrei-
bung bezüglich ihres Inhalts, der auf sie zugreifenden Prozessbeteiligten, etc. vorliegt.
Verbinden die Schnittstellen gleichzeitig verschiedene Standorte, an denen Prozesse
ausgeführt werden, wird insbesondere auch der Verteilungsaspekt komplexer Soft-
wareprozesse (und damit die zweite Problemstellung) berücksichtigt. Über diese geo-
grafische Verteilung können Anforderungen an die zugrundeliegende Kommunika-
tionsinfrastruktur gestellt und überprüft werden. Auch das Kommunikationsverhal-
ten innerhalb eines verteilten Softwareprozesses und seine damit zusammenhängende
Wirtschaftlichkeit können über die Schnittstellenbetrachtung zwischen verschiedenen
Standorten analysiert werden.
Überprüfung und Analyse verschiedener Kommunikationsaspekte werden durch eine
auf die entsprechenden Modelleigenschaften konzentrierte Sicht erleichtert, die durch
die Umstrukturierung einer bereits existierenden Prozesslandschaft entsteht. Diese ist
durch die traditionelle Vorgehensweise der Prozessmodellierung entstanden, die ein
Modell entlang der kausalen Zusammenhänge verschiedener durchzuführender Aufga-
ben innerhalb des abzubildenden Prozesses entwirft. Ihre Umstrukturierung erfüllt die
Anforderung an die Existenz verschiedener Sichten, die durch die dritte angesproche-
ne Problemstellung aufgestellt worden ist, konkret der Anforderung nach dem Verzicht
auf Neumodellierung und/oder Integration verschiedener Sichten.
Der Top-Down-Ansatz des Process Landscaping ermöglicht die Berücksichtigung der
Problemstellungen 1. bis 3. nicht nur für strukturierte, sondern auch für unstrukturier-
te Softwareprozesse. Dazu wird eine Vorgehensweise der Prozessmodellierung einge-
führt, die zunächst explizit von Ablaufinformationen abstrahiert und so gleichzeitig die
in der vierten Problemstellung formulierte Anforderung erfüllt. Verfeinerungskonzep-
te, die sowohl das spätere Hinzufügen der Ablaufinformationen als auch eine schritt-
weise Detaillierung verschiedener Prozesselemente erlauben, sichern schließlich eine
durchgängige Modellierungsunterstützung für Softwareprozesse, wie sie im Rahmen
der fünften Problemstellung diskutiert worden ist.
Bezüglich der Analyseziele des Process Landscaping sind noch einige Charakteristika
hervorzuheben. Die Methode verfolgt eine prozessorientierte Analyse, d.h. der Fo-
kus liegt nicht auf der Qualität der Ergebnisse eines Softwareprozesses, sondern auf
der Qualität des Prozesses selbst. Der Vorteil dieses Analyseansatzes liegt darin, dass
Schwächen des Prozesses bereits identifiziert werden können, bevor das Modell ausge-
führt wird, indem verschiedene Modellvarianten, die das gleiche Ziel (beispielsweise
Aufbau eines weiteren Standortes im Rahmen eines komponentenbasierten Software-
entwicklungsprojektes) haben, analysiert und verglichen werden können. Durch die
Verbesserung von Prozessmodellen kann so schließlich auch die Qualität der Soft-
7
Einleitung
wareprodukte verbessert werden, die entlang dieser Prozessmodelle erstellt werden.
Im Rahmen der Analyse des Process Landscaping werden verschiedene Eigenschaften
einer Softwareprozesslandschaft untersucht. Dies sind zum einen diejenigen Eigen-
schaften statischer Kommunikationsstrukturen, die Auswirkungen auf die Kommuni-
kationskosten verteilter Prozesse haben, zum anderen sind dies Eigenschaften, die die
Wirtschaftlichkeit des Kommunikationsverhaltens, welches sich aus der Prozessdyna-
mik ergibt, beeinflussen. Für die Analyse wird jedoch aufgrund ihrer Individualität
keine allgemeingültige Metrik zur Qualitätsmessung der analysierten Landschaften
angegeben. Es wird stattdessen mit Hilfe von Vergleichsanalysen und unter der An-
nahme konkreter Planungsideen das jeweilige Kostenoptimum für eine gegebene Pro-
zesslandschaft berechnet und so quantitativ nachvollziehbar das Ziel einer qualitativ
hochwertigen Prozesslandschaft angestrebt.
Für die Anwendung des Process Landscaping ist eine Werkzeugunterstützung zur Mo-
dellierung und Simulation – als eine Form der Analyse – implementiert. Methode und
Werkzeug werden an einem durchgängigen Beispiel erläutert und validiert. Voraus-
setzung für dieses Vorhaben ist neben der exakten Definition verwendeter Begriffe
und der Erläuterung der Vorgehensweise beim Einsatz des Process Landscaping die
Erarbeitung einer formalen Grundlage. Die wichtigsten im Rahmen des Process Land-
scaping verwendeten Begriffe werden im nachfolgenden Abschnitt eingeführt.
1.3 Terminologie
Innerhalb dieses Abschnitts wird eine Grundmenge von Begriffen definiert, die in
der Arbeit verwendet wird. Diese Menge erhebt nicht den Anspruch, ein umfassen-
des Glossar aller im Bereich der Softwareprozesstechnologie verwendeten Begriffe
zu repräsentieren. Sie deckt lediglich eine Kernmenge der im Rahmen dieser Arbeit
benutzten Begriffe rund um Softwareprozesse und -prozessmodelle ab.
Bei der Methode des Process Landscaping steht die Modellierung einer Menge von
zusammenhängenden Prozessen im Zentrum der Betrachtungen. Sowohl die Prozesse
als auch ihr Zusammenhang können dabei unterschiedlich detailliert modelliert wer-
den. Eine Prozesslandschaft ist eine Abbildung von realen Prozessen in Form eines
Modells auf unterschiedlichen Abstraktionsebenen. Abbildung 1.1 verdeutlicht den
Zusammenhang zwischen realen Prozessen und ihrer Darstellung innerhalb einer Pro-
zesslandschaft.
Die Elemente der Prozesslandschaft sind rechts benannt. Diese repräsentieren Aus-
schnitte einer realen Welt, deren korrespondierende Elemente auf der linken Seite der
Abbildung aufgeführt sind. Die Relationen zwischen Elementen der realen Welt sind
– genauso wie die Relationen zwischen den sie darstellenden Elementen der Prozess-
landschaft – durch das Symbol einer Aggregation veranschaulicht. Die Korrespondenz
zwischen den Elementen der realen Welt und der Prozesslandschaft wird durch das
Symbol der Assoziation angezeigt.
Auf der obersten Abstraktionsebene einer Prozesslandschaft werden Kernaktivitätsbe-
8
1.3 Terminologie
schreibungen (kurz Kernaktivitäten) abgebildet, die die Kernprozesse eines Software-
projektes darstellen. Jeder Kernprozess besteht aus einer Menge von Prozessen, die
wiederum in Teilprozesse und Aktivitäten aufgeteilt sind. Innerhalb der Modellwelt,
der Prozesslandschaft, werden diese Bestandteile der Prozesse als Aktivitätsbeschrei-
bungen (kurz Aktivitäten) oder als Prozessmodelle bezeichnet, die im Modell durch
Verfeinerung der Kernaktivitäten und Aktivitäten entstehen. Der Unterschied zwischen
den beiden Modellbegriffen Aktivität und Prozessmodell besteht darin, dass ein Pro-
zessmodell explizit von der Betrachtung der Ablaufinformationen ausgeht, die die Tei-
le der Prozesse miteinander verbinden. Spricht man dagegen in der Modellwelt von
einer Aktivität, müssen diese Ablaufinformationen nicht notwendigerweise abgebildet
sein. Der Modellbegriff Aktivität ist damit als Oberbegriff für abgebildete Prozesse,
Teilprozesse oder Aktivitäten anzusehen.
Kernprozess Kernaktivität(sbeschreibung)
Prozess Aktivität(sbeschreibung)
Teilprozess/Aktivität Prozessmodell/Aktivität(sbeschreibung)
1 1
1 1
1 1
Dokument Dokumenttyp
1 1
Information/Nachricht Informationstyp
1 1
1
n
1
n
1
n
1
n
besteht aus
wird dargestellt durch
reale Welt Prozesslandschaft
Abbildung 1.1: Prozesse, Aktivitäten und ihre Darstellung in einer Prozesslandschaft
Aufgrund der Unterscheidung zwischen Aktivitäten mit und ohne Ablaufinformatio-
nen wird ihm Rahmen des Process Landscaping bewusst von Verfeinerung bis auf
9
Einleitung
Prozessmodellebene gesprochen (vgl. Abschnitt 2.2.3). Die Ablaufinformationen von
Prozessen unterteilen damit eine Prozesslandschaft in eine Anzahl oberer und unte-
rer Ebenen. Auf ihren oberen Ebenen werden diese explizit nicht abgebildet; auf den
unteren Ebenen fließen sie in die Darstellung mit ein.
Informationsobjekte werden innerhalb einer Prozesslandschaft ebenfalls in unter-
schiedlichen Detaillierungsstufen abgebildet. Auf den oberen Ebenen sind ausschließ-
lich Dokumente abgebildet, die sich dort als Dokumenttypen wiederfinden. Ein Do-
kument ist eine Menge von Informationen oder Materialien, die im Rahmen eines
Prozesses erzeugt oder bearbeitet werden. Auf den unteren Ebenen kann eine Viel-
zahl unterschiedlicher Informationsobjekte abgebildet werden. Diese werden in der
Modellwelt entsprechend als Informationstypen unterschiedlicher Art dargestellt, die
meist als Nachrichten zwischen Aktivitäten ausgetauscht werden.
Die eingeführten Begriffe sind teilweise direkt aus der Literatur übernommen, teilwei-
se unterscheidet sich ihre Bedeutung im Rahmen des Process Landscaping von diesen.
Beispielsweise definieren Hammer und Champy 1993: „We define a process as a col-
lection of activities that takes one or more kinds of input and creates an output that is of
value to the customer“ [HC93]. Diese Definition akzentuiert die Kundenorientierung,
die auch beim Process Landscaping eine wichtige Rolle spielt (vgl. Abschnitt 2.2.2).
Beim Process Landscaping wird unter einem Prozess ein Softwareprozess eines Unter-
nehmens verstanden, der als eine spezielle Form eines Geschäftsprozesses angesehen
wird, konkret als diejenige, deren Ergebnis ein Softwareprodukt für einen tatsächli-
chen oder einen möglichen Kunden ist. Dies entspricht dem Verständnis von Keen,
der sich bei der Zielgruppe eines Geschäftsprozesses auf Kunden eines Unternehmens
oder einen Markt beschränkt [Kee97]. Er beschreibt einen Geschäftsprozess als eine
Menge von Aktivitäten, die Informationen verarbeiten und ein Ergebnis produzieren.
Dabei wurde die Menge von Aktivitäten dazu entworfen, ein bestimmtes Ergebnis für
einen Kundenbereich oder einen Markt zu erzeugen.
Lonchamp definiert einen Softwareprozess als „a set of partially ordered process steps,
with sets of related artifacts, human and computerized resources, organizational struc-
tures and constraints, intended to produce and maintain the requested software deli-
verables“ [Lon93]. Die partielle Ordnung der Prozessschritte impliziert – zumindest
für Teilbereiche – Wissen über den Ablauf eines betrachteten Prozesses. Damit betont
Lonchamp im Gegensatz zu Keen neben den beteiligten Ressourcen auch die Berück-
sichtigung von Ablaufinformationen. Für Geschäftsprozesse allgemein wird dies in
ähnlicher Form von Becker und Vossen formuliert, die diese als „inhaltlich abgeschlos-
sene zeitliche und sachlogische Abfolge der Funktionen, die zur Bearbeitung eines
betriebswirtschaftlich relevanten Objektes notwendig ist“, ansehen [VB96]. Zusam-
menfassend wird durch die Begriffsdefinitionen von Lonchamp und Becker/Vossen
das Vorhandensein eines strukturierten Prozessablaufs und dessen Berücksichtigung
bei der Prozessmodellierung stets impliziert. Beim Process Landscaping ist die Be-
rücksichtigung von Ablaufinformationen dagegen nicht zwangsläufig für alle Abstrak-
tionsebenen einer Prozesslandschaft gefordert. Ihre oberen Ebenen abstrahieren sogar
bewusst davon. Das Process Landscaping folgt damit nicht den beiden in der Lite-
10
1.3 Terminologie
ratur formulierten Definitionen. Warum die Möglichkeit der Abstraktion von Ablauf-
informationen – insbesondere für Softwareprozesse – sinnvoll ist, wurde bereits in
Abschnitt 1.2 erläutert.
Bezogen auf die Verwendung der Begriffe innerhalb der Modellwelt, die in Abbil-
dung 1.1 aufgeführt sind, gibt es noch weitere Unterschiede zur Literatur. So wird eine
Aktivität von Lonchamp als elementarer Prozessschritt bezeichnet, wobei „at the le-
vel of abstraction of the process description, an activity has no visible substructure“
[Lon93, FH93]. Diese Beschreibung einer Aktivität ist jedoch nicht für das Process
Landscaping gültig, da sie einer Lösung der in Abschnitt 1.2 identifizierten Problem-
stellung der durchgängigen Modellierungsunterstützung auf unterschiedlichen Ab-
straktionsebenen inklusive ihrer Visualisierung hinderlich wäre. Bei der Methode kann
eine Aktivität sehr wohl durch weitere (Teil-)Aktivitäten verfeinert werden. Das Kon-
zept der Aktivitätsverfeinerung inklusive einer entsprechenden grafischen Darstellung
ist elementarer Bestandteil des Process Landscaping und wird in den Abschnitten 2.2.3
und 2.2.5 detailliert diskutiert.
Ein Prozessmodell wird von Humphrey und Feiler definiert als eine abstrakte Re-
präsentation eines Prozesses auf Architektur-, Design- oder Definitionsebene [FH93].
Dieses kann mehr oder weniger formal sein und eine bestimmte Sicht auf einen Prozess
widerspiegeln [Lon93]. Beim Process Landscaping wird diese Bedeutung noch um die
explizite Berücksichtigung von Ablaufinformationen erweitert. Der Grund für die Er-
weiterung ist die unterschiedliche Verwendung des Begriffs Prozessmodell, der beim
Process Landscaping einen Teilbereich innerhalb einer Prozesslandschaft beschreibt,
während er bei Humphrey und Feiler als Oberbegriff für abgebildete Prozesse oder
Teilprozesse verwendet wird. Diese Rolle des Oberbegriffs übernimmt beim Process
Landscaping der Begriff der Aktivität (vgl. Beschreibung der Abbildung 1.1).
Zusätzlich erfährt der Begriff der Sicht auf eine Prozesslandschaft im Rahmen die-
ser Arbeit eine besondere Bedeutung. Lonchamp definiert diesen als „the particular
approach of a software process conveyed by a process model“ [Lon93]. Er ist der Mei-
nung, dass ein vollständiges Softwareprozessmodell oft die Integration verschiedener
Modelle erfordert, die verschiedene Aspekte des Softwareprozesses, beispielsweise
Management-, Qualitäts- und Entwicklungsaspekte, betrachten. Derniame et al. for-
mulieren dies ähnlich. Sie unterscheiden Submodelle wie das Aktivitätenmodell, das
Produktmodell, das Ressourcenmodell und das Rollenmodell, die verschiedene Aspek-
te derselben Prozesslandschaft darstellen [DKW99]. Finkelstein et al. haben ein Rah-
menwerk zur Integration dieser verschiedenen Sichten entwickelt [FKN+92], welches
allgemein anerkannt und vielfach genutzt wird [GMT99, FS96].
Die Verwendung des Begriffes Sicht im Rahmen des Process Landscaping entspricht
der zitierten Definition von Lonchamp, wenn die Erstellung verschiedener Sichten zur
Analyse verschiedener Aspekte als sinnvoll erachtet wird. Die Integration separat er-
stellter Modelle, die jeweils verschiedene Sichten reflektieren – ist jedoch explizit nicht
gewünscht. Stattdessen wird eine Vorgehensweise zur Erstellung verschiedener Sich-
ten gefordert, die – ausgehend von einer Sicht – durch Umstrukturierung der Mo-
dellelemente weitere Sichten entstehen lässt. Diese Vorgehensweise lässt die Nutzung
11
Einleitung
eines Rahmenwerks zur Integration der Sichten überflüssig werden.
Auch in der Wirtschaftsinformatik wird der Begriff der Sicht auf ein Prozessmo-
dell verwendet: „Ein Prozessmodell stellt immer eine (spezielle) Sicht auf ein Un-
ternehmen dar, indem es den Durchlauf eines Objektes fokussiert. Die Vielzahl an be-
triebswirtschaftlichen Objekten (z.B. Bestellungen, Aufträge, Rechnungen, Mahnun-
gen, Baugruppen, Teile inklusive ihrer jeweiligen Spezialisierungen) schlägt sich bei
einer umfangreichen Modellierung in einer entsprechenden Vielzahl an Prozessmodel-
len nieder.“ [Ros96]. Da hier die zumeist separat erstellten Prozessmodelle oft nicht
näher zueinander in Beziehung gesetzt werden, droht die Gefahr von Einzelprozess-
analysen, d.h. der Optimierung eines einzelnen Prozesses ohne Berücksichtigung von
etwaigen Wechselwirkungen. Im Rahmen des Process Landscaping wird dieser Gefahr
entgegenwirkt, indem nicht verschiedene Prozessmodelle separat entwickelt werden,
die dann miteinander abzugleichen oder zu integrieren sind, sondern indem zunächst
eine Prozesslandschaft erstellt wird, die später zur Konzentration auf bestimmte zu
betrachtende Eigenschaften umstrukturiert wird. Das Process Landscaping startet da-
bei mit der Erstellung einer Prozesslandschaft, bei der der kausale Zusammenhang
der einzelnen Aktivitäten im Vordergrund steht. Die entstehende hierarchisch aufge-
baute Struktur wird als logische Sicht auf eine Prozesslandschaft bezeichnet. Soll für
eine Analyse der Verteilungsaspekt dieser Landschaft stärker hervorgehoben werden,
so wird sie in eine lokale Sicht umstrukturiert (vgl. Abschnitt 2.3.1). Diese gruppiert
alle Aktivitäten einer Prozesslandschaft nach den Standorten, an denen diese durchge-
führt werden. Die Bedeutung des Begriffes der lokalen Sicht unterscheidet sich hier
jedoch von derjenigen in anderen Arbeiten im Kontext verteilter Prozesse. In [FKT00]
bezeichnet beispielsweise die lokale Sicht einen Teil einer Prozesslandschaft, der an
einem konkreten, einzelnen Standort ausgeführt wird. Teilweise wird auch der Begriff
der verteilten Sicht für lokal (über verschiedene Standorte) verteilte Systeme verwen-
det [TE00].
In der lokalen Sicht werden im Rahmen des Process Landscaping verschiedene Kom-
munikationsaspekte analysiert. Unter dem Begriff der Kommunikation wird hier der
zielgerichtete Austausch von Informationen zwischen zwei oder mehreren Aktivitäten
innerhalb einer Prozesslandschaft verstanden, die an verschiedenen Standorten aus-
geführt werden können. Die Informationen liegen als Dokumente vor, die mit Hil-
fe einer Kommunikationsinfrastruktur transportiert werden. Kommunikationsanaly-
sen in der Informatik allgemein betrachten meist andere Aspekte, wie beispielswei-
se die einer Kommunikation zugrundeliegenden Protokolle verteilter Rechnersysteme
[Kru84, HK00] oder die Architektur einer verteilten Anwendung, deren Komponenten
miteinander kommunizieren bzw. Nachrichten austauschen [Emm00, GT00]. Damit
unterscheidet sich die Verwendung des Begriffs beim Process Landscaping insofern
von der üblichen, als hier eher technische Aspekte der Kommunikation außer acht
gelassen werden und stattdessen bislang kaum betrachtete Aspekte, die sich aus der
geografischen Verteilung der Prozessbeteiligten ergeben, in den Vordergrund der Be-
trachtung treten.
12
1.4 Struktur der Arbeit
1.4 Struktur der Arbeit
Nach der Einführung in das Forschungsgebiet der Softwareprozesstechnologie, in das
sich die vorliegende Arbeit einfügt, der Identifikation weiterer Unterstützungsmög-
lichkeiten verteilter Softwareprozesse, die mit dem Process Landscaping angeboten
werden, der Diskussion der sich daraus ergebenden Zielsetzung dieser Arbeit und der
Einführung der in diesem Zusammenhang verwendeten Begriffe sind die Vorausset-
zungen zur ausführlichen Erläuterung der Methode gegeben. Kapitel 2 führt zunächst
die Ziele und Grundsätze sowie die methodischen Schritte des Process Landscaping
ein, die zur Erreichung der festgelegten Ziele durchzuführen sind. Letztere decken
sowohl Modellierungs- als auch Analyseziele ab. Ein abschließender Abschnitt bein-
haltet einen Vergleich mit anderen existierenden Modellierungs- und Analyseansätzen
(Abschnitt 2.4).
Eine formale Basis der Methode, die insbesondere für die Erreichung der Analyse-
ziele erforderlich ist, wird ausführlich in Kapitel 3 diskutiert. Die dort eingeführten
Definitionen fügen sich in die bekannte Petrinetz-Notation ein. Sie werden an einem
durchgängigen Beispiel erläutert und motiviert. Eine vergleichende Diskussion mit an-
deren Petrinetz-Varianten wird abschließend in Abschnitt 3.3 durchgeführt.
Das zur Erläuterung der formalen Basis herangezogene Beispiel, die Darstellung einer
komponentenbasierten, verteilten Softwareentwicklung, wird in Kapitel 4 auch zur Va-
lidation der Analysemethoden des Process Landscaping herangezogen. Zusammen mit
der Methode des Process Landscaping sind einige unterstützende Softwarewerkzeuge
entstanden und existierende Werkzeuge erweitert worden, die die Anwendung der Me-
thode erleichtern. Kapitel 5 stellt deren Kernfunktionalitäten vor und zeigt auf, welche
Bereiche der Methode derzeit eine Werkzeugunterstützung vorweisen können. Kapi-
tel 6 schließt die Arbeit mit einer Zusammenfassung und einem Ausblick auf mögliche
weiterführende Arbeiten ab.
13

Kapitel 2
Die Methode des Process
Landscaping
In der Literatur wird unter dem Begriff Methode eine „planmäßige und begründete
Vorgehensweise zur Erreichung festgelegter Ziele (i.a. im Rahmen festgelegter Prin-
zipien)“ verstanden. „Zu einer Methode gehören eine Notation, systematische Hand-
lungsanweisungen und Regeln zur Überprüfung der Ergebnisse.“ [HMF92]. Diese De-
finition einer Methode ist im Informatik-Begriffsnetz der Gesellschaft für Informatik
(GI) festgehalten [GF01]. Ihr liegen vorangegangene Definitionen verschiedener dort
referenzierter Autoren zugrunde [HMF92, Bal82, Chr92]. Balzert sieht beispielsweise
eine Methode als eine Handlungsvorschrift an, die beschreibt, wie – ausgehend von
gegebenen Bedingungen – ein Ziel mit einer festgelegten Schrittfolge erreicht wird
[Bal82]. Chroust verwendet synonym den Begriff Methodik [Chr92].
Die Methodendefinition der GI berücksichtigt alle Aspekte vorangegangener Defini-
tionen und führt zusätzlich die Bestandteile einer Methode explizit auf, während äl-
tere Definitionen hauptsächlich die Handlungsvorschriften einer Methode betrachten.
Das Process Landscaping basiert auf der Methodendefinition der GI, da vor allem ei-
ne Notation als Bestandteil einer Methode unverzichtbar ist, wenn exakte Analysen
durchgeführt werden sollen.
Dieses Kapitel ist entlang der laut Definition notwendigen Bestandteile einer Methode
strukturiert, konkret den methodischen Schritten und den zu erreichenden Zielen bzw.
Ergebnissen. Zunächst wird – nach einer Erläuterung zu beachtender Grundsätze –
die Vorgehensweise in Form einzelner Schritte zur Erstellung und Überprüfung einer
Prozesslandschaft als ein Ergebnis des Process Landscaping diskutiert. Anschließend
werden die Analyseziele der Methode definiert, ihre Vorgehensweise und Interpreta-
tionsrahmen für eine quantitative Bewertung vorgestellt. Die zugrundeliegende for-
male Notation zur Beschreibung einer Prozesslandschaft und ihrer zu analysierenden
Eigenschaften wird zunächst nicht betrachtet. Sie wird im nachfolgenden Kapitel 3
diskutiert.
15
Die Methode des Process Landscaping
2.1 Ziele und Grundsätze des Process Landscaping
Ein erstes Ziel des Process Landscaping ist die Erstellung einer konsistenten Soft-
wareprozesslandschaft. Das Process Landscaping geht dabei von der Annahme aus,
dass im Rahmen von Modellierungsprojekten unabhängig von ihren konkreten Zielen
insbesondere folgende Fragestellungen diskutiert werden müssen [GW00a]:
 Welches sind die Kernprozesse im Rahmen einer Softwareentwicklung?
 In welcher Reihenfolge sollten sie modelliert werden?
 Wie sehen die Schnittstellen zwischen ihnen aus?
Alle drei Fragen beschäftigen sich indirekt mit der Gewährleistung der Konsistenz ei-
ner Prozesslandschaft: Sind alle Kernprozesse identifiziert, können auch alle Schnitt-
stellen gefunden werden. Deren Identifikation wird zusätzlich durch eine geeignete
Modellierungsreihenfolge unterstützt. Sind die Schnittstellen beschrieben, können sie
auf ihre Konsistenz überprüft werden. Dies alles führt letztendlich zu einer konsisten-
ten Softwareprozesslandschaft.
Erst die Beantwortung der obigen Fragen ermöglicht eine zusammenhängende Be-
trachtung aller beteiligten Prozesse. Fehlt diese Möglichkeit, entsteht leicht eine Viel-
zahl einzelner Modelle, deren Zusammenhang nicht erkennbar ist. Eine Fokussierung
auf Details erschwert insbesondere eine stringente Modellierung und Modifizierung
von Schnittstellen. Ein zusammenhängendes Gesamtbild ermöglicht daher die Identi-
fikation von Verbesserungspotenzial der modellierten Prozesse. Aufgrund dieser Er-
kenntnis stehen bei der Methode des Process Landscaping nicht einzelne Prozesse,
sondern die Menge der zusammenhängenden Prozesse – deren Modell kurz als Pro-
zesslandschaft bezeichnet wird – im Zentrum der Betrachtungen.
Der Modellierung einer Prozesslandschaft mit der Methode des Process Landscaping
sind verschiedene Prinzipien zugrundegelegt:
 Anzahl von Kernprozessen:
Das Process Landscaping geht von einer kleinen Anzahl zu identifizierender und
zu betrachtender Kernprozesse aus [GW99a]. Sie soll die Übersichtlichkeit der
obersten Ebene einer Softwareprozesslandschaft gewährleisten.
 Modellierungsreihenfolge von Prozessen:
Das Process Landscaping geht von der Annahme aus, dass ein Gesamtüberblick
über die Menge aller an einer Softwareentwicklung beteiligten Prozesse für die
Erstellung einer Prozesslandschaft nutzbringend ist. Ein erster Überblick wird
durch die Identifikation und Auflistung aller Kernprozesse erreicht. Die voll-
ständige Identifikation dieser Kernprozesse kann dadurch gewährleistet werden,
dass Kernprozesse in der Reihenfolge ihrer Nutzung in einem Kundenlebens-
zyklus vom Modellierer – meist im Rahmen eines Interviews – erfragt werden.
16
2.1 Ziele und Grundsätze des Process Landscaping
Unter einem Kundenlebenszyklus wird hier der Lebenslauf eines Softwaresys-
tems von Projektbeginn an über Nutzung und Betreuung bis zur Außerbetrieb-
nahme – also ein Softwarelebenszyklus [GF01] – verstanden, der aus der Sicht
eines potentiellen Kunden betrachtet wird. Das Process Landscaping setzt dabei
voraus, dass – meist zu Beginn eines Softwareentwicklungsprojektes – mindes-
tens einer der Kernprozesse eine Schnittstelle zu einem potentiellen Kunden hat.
Der Begriff des Kunden wird hierbei sehr weit gefasst, da es sich bei ihm um
keinen konkreten Auftraggeber oder Anwender handeln muss. Die Anlehnung
der Modellierungsreihenfolge an einen Kundenlebenszyklus unterstützt ein ziel-
gerichtetes Vorgehen und gewährleistet die Berücksichtigung aller beteiligten
Kernprozesse.
 Kernprozesse mit Kundenschnittstellen:
Das Process Landscaping unterscheidet zwischen Kernprozessen mit direkten
Schnittstellen zu Kunden und internen, unterstützenden (Kern-)Prozessen. Die-
se Unterscheidung folgt der Empfehlung von Höderath [Höd98], der zwischen
Marktprozessen und internen Prozessen unterscheidet. Bei ersteren existiert ei-
ne direkte Kommunikation mit Kunden und damit direkte Schnittstellen, letztere
haben keine direkten Schnittstellen zum Kunden. Diese Unterscheidung unter-
stützt den Modellierer bei der Frage nach dem Detaillierungsgrad zu modellie-
render Kernprozesse in Abhängigkeit vom Modellierungsziel.
 Schnittstellen von Kernprozessen:
Das Process Landscaping zeichnet sich dadurch aus, dass Schnittstellen zwi-
schen Prozessen von Beginn ihrer Modellierung an berücksichtigt werden. Sie
können bereits auf hohem Abstraktionsniveau identifiziert und dann solange ver-
feinert werden, bis der Typ der Kommunikation und das Format aller auszutau-
schenden Objekte vollständig festgelegt sind.
 Grundsätze ordnungsmäßiger Modellierung [Ros96]:
Während die obigen Grundsätze sich konkret auf die Modellierung von Pro-
zessmengen und ihren Schnittstellen beziehen, bilden die Grundsätze der
ordnungsmäßigen Modellierung einen allgemeingültigen Ordnungsrahmen zur
Darstellung von Inhalten und Gestaltung von Prozessmodellen. Diese Grundsät-
ze werden auch vom Process Landscaping berücksichtigt. Sie unterstützen die
Handhabung komplexer, zusammenhängender Prozessmodelle und beinhalten
im Einzelnen [BRS95]
– den Grundsatz der syntaktischen und semantischen Richtigkeit inklusive
sichtenübergreifender Konsistenzregeln,
– den Grundsatz der Relevanz, nach dem die in einem Modell enthaltenen
Elemente genau dann relevant sind, wenn ihr Fehlen den Nutzen des Mo-
dells bezüglich eines konkreten Modellierungsziels vermindern würde,
– den Grundsatz der Wirtschaftlichkeit, der dem Detaillierungsgrad eines
Modells eine obere Grenze setzt,
17
Die Methode des Process Landscaping
– den Grundsatz der Klarheit bezüglich des Layouts von Prozessmodellen
und der Findung eines geeigneten Abstraktionsgrades,
– den Grundsatz der syntaktischen und semantischen Vergleichbarkeit, wo-
bei sich die syntaktische Vergleichbarkeit auf die Kompatibilität konsisten-
ter Modelle bezieht und die semantische Vergleichbarkeit die inhaltliche
Vergleichbarkeit z.B. von Soll- und Ist-Modellen betrachtet und
– den Grundsatz des systematischen Aufbaus, der dem Sachverhalt der Mo-
dellierung in getrennten Sichten und der daraus folgenden Notwendigkeit
der Integration der einzelnen Sichten Rechnung trägt.
Das Analyseziel des Process Landscaping ist die Unterstützung der Prozessverantwort-
lichen durch Aussagen über bestimmte Eigenschaften einer Prozesslandschaft. Dazu
werden sowohl statische Analysen mittels Zählen, Aggregieren und Auswerten defi-
nierter Attributwerte durchgeführt als auch dynamische Analysen durch Simulationen,
die zeitliche Aspekte und Ablaufverhalten eines Modells berücksichtigen. Zur Über-
prüfung der Analyseergebnisse werden teils Soll- und Ist-Ausprägungen einer Pro-
zesslandschaft verglichen, teils werden Metriken für eine Bewertung von Teilzielen
definiert (vgl. Abschnitt 2.3). Die konkret betrachteten Eigenschaften beziehen sich
auf Kommunikationsstruktur und -verhalten. Die Analyse dieser Eigenschaften einer
Prozesslandschaft mit der Methode des Process Landscaping berücksichtigt die fol-
genden Kriterien:
 Analysieren heißt messen und bewerten:
Diesem Prinzip folgt auch die Methode des Process Landscaping. Wie bereits im
Begriff Messen eine Zwecksetzung notwendig impliziert ist (Messen ist „eine
Zuordnung von Zahlen zu Objekten oder Ereignissen“ [Ort83] nach bestimmten
Regeln zum Zwecke einer (vergleichenden) Beschreibung oder zur Beurteilung
eines Sachverhaltes), so setzt auch das Process Landscaping immer ein Opti-
mierungsziel bzw. eine Änderungsidee voraus, bezüglich derer die Eigenschaf-
ten einer Prozesslandschaft zu bewerten sind. Beispielsweise kann die Kommu-
nikation von Prozessen innerhalb einer Prozesslandschaft bezüglich der Ände-
rungsidee betrachtet werden, eine Teilmenge von Aktivitäten an einem gemein-
samen Standort konzentrieren zu wollen. Die für diese Betrachtung angewendete
Messmethode kann dabei eine direkte Zuordnung von Zahlen zu Landschafts-
bereichen bzw. eine Klassifikation über unterschiedlich komplexe Berechnungs-
algorithmen oder eine Durchführung von Simulationsläufen mit anschließenden
stochastischen Berechnungen auf der Basis der gewonnenen Simulationsdaten
sein. Ein Vergleich der gemessenen Kommunikationseigenschaften vor und nach
der Änderung der Prozesslandschaft erlaubt eine anschließende Bewertung die-
ser Änderungsidee.
 Kommunikationskosten:
Das Process Landscaping unterscheidet bei der Betrachtung von Kommunika-
tionskosten zwischen den Kosten, die durch Kommunikation innerhalb eines
18
2.2 Methodische Schritte zur Erstellung einer Prozesslandschaft
Standortes (interne Kommunikation) entstehen und den Kosten, die durch Kom-
munikation zwischen verschiedenen Standorten (externe Kommunikation) ent-
stehen. Dabei wird – in Anlehnung an viele typische Situationen in der Praxis –
angenommen, dass externe Kommunikation teurer zu bewerten ist als interne.
Beispiele für externe Kommunikation sind eine Wählleitung mit anschließen-
dem Datenaustausch per WAN oder eine Videokonferenz. Interne Kommuni-
kation kann dagegen beispielsweise durch einen Datenaustausch per Dateizu-
griff innerhalb eines LANs oder direkt mit einem Gesprächspartner innerhalb
eines Raumes stattfinden. Interne Kommunikation ist neben einer schnelleren
Abwicklung häufig auch dadurch preiswerter, dass keine Kommunikationssys-
teme benötigt werden, die zusätzliche Kosten verursachen.
 effiziente Kommunikation:
Ein globales Optimierungsziel des Process Landscaping ist das Erreichen ei-
ner effizienten Kommunikation. Im Rahmen dieser Arbeit wird eine Kommu-
nikation als effizient bezeichnet, wenn ein Informationsaustausch in möglichst
geringer Zeit und mit möglichst geringem Aufwand für die beteiligten Kom-
munikationspartner durchgeführt werden kann. Die Kommunikationseffizienz
bezieht sich dabei auf räumliche Verteilung, Auslastung und Informationsfluss
und -verteilung von Prozessen [SW02a]. Bei einer ungleichmäßigen Verteilung
entstehen sowohl für den auf eine Antwort wartenden als auch für den angespro-
chenen Kommunikationspartner temporäre und monetäre Aufwände. Je gleich-
mäßiger eine Verteilung der Kommunikationsaufwände auf die einzelnen Kom-
munikationspartner in einer Prozesslandschaft gelingt, desto effizienter kann die
Kommunikation innerhalb dieser Prozesslandschaft erfolgen. Dabei wird das
auch in anderen Bereichen häufig angewandte Verursacherprinzip zugrundege-
legt. Dieses legt einem Prozess, der angefragte Informationen versendet, die ent-
stehenden Kommunikationskosten zur Last, was seine Effizienz verringert.
2.2 Methodische Schritte zur Erstellung einer Prozess-
landschaft
Ein Ziel des Process Landscaping ist die Modellierung einer Prozesslandschaft, die ei-
ne Menge zusammengehöriger Prozesse und ihre Beziehungen zueinander beschreibt.
Die notwendigen Schritte zur Erreichung dieses Ziels sind [GW00a, GW00b]:
1. Identifikation von (Kern-)Aktivitäten und ihren Schnittstellen
2. Verfeinerung von Aktivitäten bis auf Prozessmodellebene
3. Verfeinerung von Schnittstellen
4. Verfeinerung von Prozessmodellen
5. Validation der modellierten Prozesslandschaft
19
Die Methode des Process Landscaping
Diese Schritte werden im Folgenden zusammen mit den beteiligten Rollen und unter-
stützenden Techniken vorgestellt. Die Reihenfolge der einzelnen Schritte wird bis auf
den ersten nicht fest vorgeschrieben. Diese Freiheit erlaubt unterschiedliche Abstrak-
tionsgrade bei der Modellierung von Aktivitäten und Schnittstellen. Sie unterstützt die
Konzentration auf eine den projektspezifischen Anforderungen angepasste Detaillie-
rung dort, wo sie erforderlich ist. Der erste Schritt besteht aus der Identifikation der
Kernaktivitäten und ihren Schnittstellen sowie ihrer Anordnung auf der obersten Ebe-
ne der zu modellierenden Prozesslandschaft gemäß den in Abschnitt 2.1 erläuterten
Prinzipien. Auf jede Kernaktivität kann die Methode des Process Landscaping erneut
angewandt werden, bis schließlich individuelle Prozessmodelle und ihre Schnittstel-
len entstanden sind (vgl. Schritte 2 und 3). Anschließend können Details überall dort
hinzugefügt werden, wo es notwendig erscheint (vgl. Schritt 4). Schritt 5 befasst sich
nicht mehr mit der Entwicklung, sondern mit der abschließenden Überprüfung einer
entstandenen Prozesslandschaft vor ihrer Freigabe.
Die einzelnen Schritte werden in den Abschnitten 2.2.2 bis 2.2.6 entlang eines Bei-
spiels detailliert beschrieben. Für die Diskussion des Process Landscaping wurde be-
wusst ein komplexes Beispiel der komponentenbasierten Softwareentwicklung ge-
wählt, da sich darin viele typische Abläufe und charakteristische Eigenschaften ab-
bilden lassen, die bei realen Softwareentwicklungsprojekten unter Umständen nur ver-
einzelt auftreten.
2.2.1 Beispielprozesslandschaft der komponentenbasierten Software-
entwicklung
Zur Erläuterung der einzelnen methodischen Schritte wird eine Softwareprozess-
landschaft modelliert, die Aktivitäten, Abläufe und Informationsobjekte der kom-
ponentenbasierten Softwareentwicklung abbildet. Die Motivation für die Wahl ei-
ner solchen Softwareprozesslandschaft liegt im aktuellen Trend begründet, der kom-
ponentenbasierten Softwareentwicklung einen wachsenden Stellenwert beizumessen
[FRS+01, SWR+00]. Sie berücksichtigt die Aspekte der flexiblen Verteilung von An-
wendungen ebenso wie „die Tendenz, Software aus vordefinierten Bausteinen zusam-
menzubauen, die immer mehr Anwendungswissen umfassen“ [GT00].
Die Beispielprozesslandschaft ist auf Grundlage von Interviews und Literaturrecher-
chen entstanden. Für Letzteres sei insbesondere eine Fallstudie eines mehrjährigen
realen Softwareprojektes in [AF98] erwähnt.
Die Prozesse der komponentenbasierten Softwareentwicklung beinhalten immer
 das Projektmanagement,
 das Application Engineering,
 das Component Engineering,
 das Qualitätsmanagement und
 das Domain Engineering.
20
2.2 Methodische Schritte zur Erstellung einer Prozesslandschaft
Für die Diskussion der Modellierung und Analyse dieser Kernprozesse sind die eng-
lischen Begriffe gewählt worden, wenn keine prägnante Übersetzung möglich ist, wie
beispielsweise für den Begriff des Domain Engineering, der nicht ohne ausführliche
Erläuterung des übersetzten Begriffs auskommt. Des Weiteren hilft die Verwendung
des englischen Begriffs Application Engineering, zwischen der Anwendungsentwick-
lung im Allgemeinen und der Anwendungsentwicklung im Rahmen der komponenten-
basierten Softwareentwicklung – üblicherweise als Application Engineering bezeich-
net – zu unterscheiden.
Alle Schritte des Process Landscaping werden nachfolgend entlang des Beispiels der
komponentenbasierten Softwareentwicklung erläutert, indem die zugehörigen Kern-
prozesse zunächst als Kernaktivitäten in einem Koordinatensystem angeordnet und
anschließend sowohl Aktivitäten als auch ihre Schnittstellen nach und nach verfeinert
werden. Die resultierende Softwareprozesslandschaft dient als Basis für die Erläute-
rung und Validation der Analyseschritte und für die Diskussion der formalen Notation
einer Prozesslandschaft.
2.2.2 Identifikation von Kernaktivitäten und ihren Schnittstellen
Der erste Modellierungsschritt des Process Landscaping hat die Erstellung der obers-
ten Ebene einer Prozesslandschaft zum Ziel. Diese Ebene beinhaltet die Kernaktivitä-
ten und ihre Schnittstellen zueinander. Die für den Durchlauf eines Kundenlebenszyk-
lus notwendigen Kernaktivitäten und ihre Schnittstellen werden im Rahmen von Inter-
views mit den Prozessverantwortlichen identifiziert und in einem Koordinatensystem
angeordnet (vgl. Abbildung 2.1). Als unterstützende Techniken können verschiedene
Methoden der Wissensakquise eingesetzt werden. Hier eignen sich insbesondere freie
und standardisierte Interviews [Kor00]: Während ein freies Interview individuell und
lediglich anhand eines (groben) Leitfadens durchgeführt wird, werden in einem stan-
dardisierten Interview vorformulierte Fragen gestellt, um sich eine bereits existierende
Vorstellung eines (geistigen) Modells erläutern oder bestätigen zu lassen.
Die Gruppierung der identifizierten Kernaktivitäten auf der obersten Abstraktionsebe-
ne wird durch ein Koordinatensystem unterstützt. Auf der X-Achse werden die Kern-
aktivitäten in Abhängigkeit ihrer direkten Schnittstellen zum Kunden angeordnet: Je
mehr direkte Schnittstellen ein Kernprozess aufweist, desto weiter links wird die zuge-
hörige Kernaktivität angeordnet. Interne, rein unterstützende Kernaktivitäten werden
rechts angeordnet. Die Y-Achse beschreibt, an welcher Stelle des Kundenlebenszyk-
lus die beschriebenen Prozesse benötigt werden: Je früher ein Prozess im Verlauf eines
Kundenlebenszyklus angestoßen wird, desto weiter unten wird er angeordnet. Unter-
stützung bei der Anordnung der Kernaktivitäten im Koordinatensystem bietet auch
hier das freie Interview, wenn vom Interviewpartner eine reale Problemlösung nach-
vollzogen wird. Die durchzuführenden Kernprozesse werden in der Reihenfolge ihres
Auftretens aufgelistet und vom Modellierer entsprechend im Koordinatensystem der
Prozesslandschaft (als Kernaktivitäten) angeordnet.
Gemäß den beiden Achsen des Koordinatensystems ergibt sich eine natürliche Rich-
21
Die Methode des Process Landscaping
tung für die Modellierung der Prozesslandschaft. Sie beginnt mit dem chronologisch
ersten Kundenprozess (links unten). Von diesem ausgehend werden Prozesse model-
liert, die ihn direkt unterstützen sowie Prozesse, die zeitlich unmittelbar folgen. Die
Modellierungsrichtung gewährleistet, dass Details über andere Prozesse (z.B. von der
rechten oberen Ecke der Prozesslandschaft) nicht beschrieben werden, bevor sie nicht
aktuell benötigt werden. Durch die Modellierungsrichtung ergibt sich eine schrittweise
Betrachtung aller in der Prozesslandschaft dargestellten Prozesse.
Application
Engineering Qualitätsmanagement
Component Engineering
Domain Engineering
Projektmanagement
K
un
de
nl
eb
en
sz
yk
lu
s
Kundenprozess interner Prozess
Abbildung 2.1: Oberste Ebene einer Prozesslandschaft zur Darstellung komponenten-
basierter Softwareentwicklung
Abbildung 2.1 zeigt die Anordnung der identifizierten Kernaktivitäten auf der obersten
Ebene der Prozesslandschaft als Ergebnis des ersten Schrittes des Process Landsca-
ping. Die Ebene besteht aus fünf Kernaktivitäten und ihren Schnittstellen. Die Anord-
nung der einzelnen Kernaktivitäten lässt erkennen, dass hier ein erster Kundenkontakt
über Prozesse des Projektmanagement stattfindet. Diese Kernaktivität stellt innerhalb
der in Abbildung 2.1 dargestellten Prozesslandschaft eine Besonderheit dar. Prozes-
se aus dem Projektmanagement betreffen sowohl kundennahe als auch rein interne,
unterstützende Aktivitäten. Aus diesem Grund ist diese Kernaktivität entlang der ge-
samten X-Achse angeordnet, was jedoch nicht bedeuten soll, dass ihre Aktivitäten nur
zu Beginn eines Kundenlebenszyklus vorkommen können (vgl. z.B. die Schnittstelle
zwischen Application Engineering und Projektmanagement). Aus Übersichtlichkeits-
gründen erstreckt sich das Projektmanagement jedoch nicht über die gesamte Fläche
22
2.2 Methodische Schritte zur Erstellung einer Prozesslandschaft
des Koordinatensystems, sondern bleibt nah an der X-Achse.
Um die Entwicklung einer vom Kunden gewünschten Software durchführen zu kön-
nen, müssen u.a. vom Qualitätsmanagement vorgegebene Richtlinien berücksichtigt
werden. Die zugehörigen Prozesse haben im Vergleich zum Projektmanagement keine
direkten Schnittstellen zum Kunden. Daher ist beispielsweise die Kernaktivität Quali-
tätsmanagement – gemäß dem Prinzip der Unterteilung von Kernprozessen in Kunden-
prozesse und interne Prozesse – auf der obersten Ebene der Prozesslandschaft weiter
rechts angeordnet. Der Prozess des Application Engineering setzt die Software aus
den vorhandenen Komponenten zusammen. Er hat im Gegensatz zum Qualitätsma-
nagement viele Berührungspunkte zum Kunden. Da er sich fast über den gesamten
Kundenlebenszyklus erstreckt, ist er entlang der Y-Achse angeordnet. Das Component
Engineering ist eng mit dem Application Engineering verzahnt, da hier Komponenten
entwickelt werden, die dem Application Engineering nicht oder nicht in ausreichender
Qualität zur Verfügung stehen. Das Component Engineering hat aber keine direkten
Schnittstellen zum Kunden und ist daher im Koordinatensystem etwas weiter rechts
angeordnet.
Die Schnittstellen zwischen den Kernaktivitäten sind auf dieser obersten Ebene durch
bidirektionale Pfeile angedeutet. Sie können identifiziert werden, indem die Pro-
zessverantwortlichen nach den Typen der auszutauschenden Informationen befragt
werden. Wenn die Prozessverantwortlichen zweier miteinander in Beziehung stehen-
der Kernprozesse befragt werden, lassen sich unterschiedliche Auffassungen und Ge-
wichtungen bezüglich ihrer Zusammenarbeit erkennen und in einer gemeinsamen Ab-
stimmung klären.
Der Umfang der im Koordinatensystem platzierten Kernaktivitäten steht nicht unbe-
dingt in einem direkten Bezug zu ihrer Komplexität. Daher lässt sich von ihrer Größe
weder auf die Menge der sie enthaltenden Teilaktivitäten noch auf ihren Stellenwert
innerhalb der gesamten Prozesslandschaft schließen. Die in Abbildung 2.1 verwende-
ten Größenverhältnisse sind lediglich aus Gründen der Übersichtlichkeit gewählt und
vermeiden Überschneidungen der Rechtecke und Pfeile. Die abgebildete oberste Ebe-
ne der Prozesslandschaft unterstützt jedoch die zusammenhängende Betrachtung der
beteiligten (später verfeinerten) Kernaktivitäten und erfüllt damit die zu Beginn des
Abschnitts 2.1 entsprechend formulierte Anforderung.
2.2.3 Verfeinerung von Kernaktivitäten bis auf Prozessmodellebene
Kernaktivitäten stellen die Kernprozesse zunächst nur sehr abstrakt dar. Neben einem
Namen wird lediglich angegeben, zu welchen anderen Kernaktivitäten Schnittstellen
bestehen. Kernaktivitäten werden vom Prozessmodellierer verfeinert, um zusätzliche
Details über die Kernprozesse in die Prozesslandschaft aufzunehmen. Ziel ist es, eine
vollständige Liste aller Aktivitäten innerhalb eines Kernprozesses zu erarbeiten, deren
Beschreibung bei Bedarf weiter verfeinert werden kann. Hierfür empfehlen sich wei-
tere Methoden der Wissensakquise wie z.B. die offene, direkte Beobachtungsmethode
[Kra96], die noch weiter in die strukturierte und unstrukturierte Beobachtung unter-
23
Die Methode des Process Landscaping
teilt wird: Während bei der strukturierten Beobachtungsmethode Arbeitsabläufe der
zu modellierenden Prozesse betrachtet und nach im voraus festgelegten Richtlinien
protokolliert werden, liegen bei der unstrukturierten Beobachtung keine Richtlinien
zur Erhebung der beobachteten Abläufe vor.
Die Verfeinerung einer Kernaktivität geschieht durch die Angabe der zugehörigen Ak-
tivitäten inklusive ihrer Abhängigkeiten, also durch die Erstellung einer neuen Pro-
zesslandschaft pro Kernprozess. Die Aktivitäten können ihrerseits so lange verfeinert
werden, bis sie aus Sicht des Modellierers nicht weiter zerlegt werden sollten. Ablauf-
informationen, wie die Festlegung einer Durchführungsreihenfolge der identifizierten
Aktivitäten, werden im Rahmen dieses Methodenschrittes nicht modelliert, da sie die
Übersichtlichkeit bezüglich der wichtigsten Aktivitäten innerhalb der Kernaktivitäten
einschränken. Solche Informationen werden erst bei einer weiteren Verfeinerung der
Aktivitäten berücksichtigt (siehe Abschnitt 2.2.5).
Um auch nach durchgeführten Verfeinerungen das Gesamtbild einer Prozesslandschaft
nicht aus den Augen zu verlieren ist es wichtig, eine Übersicht über die Hierarchiebe-
ziehungen zwischen Aktivitäten einer Landschaft zu erstellen, die sich auf unterschied-
lichen Abstraktionsebenen befinden. Diese Übersicht, die einfach als Baumstruktur
abgebildet werden kann, gewährleistet zusammen mit der Darstellung der Kernaktivi-
täten auf der obersten Ebene einen Überblick sowohl in die Breite als auch in die Tiefe
einer modellierten Prozesslandschaft.
Aufgrund der Unterscheidung zwischen Aktivitäten mit und ohne Ablaufinformatio-
nen wird ihm Rahmen dieses Methodenschrittes bewusst von Verfeinerung bis auf
Prozessmodellebene gesprochen. Der Begriff Aktivität wird hier für modellierte Pro-
zesse verwendet, bei denen vom Ablauf abstrahiert sein kann, während der Begriff
Prozessmodell die Berücksichtigung von Ablaufinformationen impliziert (vgl. Ab-
schnitt 1.3). Bezogen auf die gesamte Prozesslandschaft wird entsprechend von ihren
oberen Ebenen gesprochen, die keine Ablaufinformationen enthalten, während in ihren
unteren Ebenen diese explizit berücksichtigt sind.
Die Abstraktion von Ablaufinformationen hat neben einer besseren Übersichtlichkeit
vor allem den Vorteil, dass für die oberen Ebenen einer Prozesslandschaft ein Ge-
samtbild erstellt werden kann, welches auch der Durchführung unstrukturierter und
flexibler Prozesse als Unterstützung dient, indem die wichtigsten Aktivitäten und exis-
tierende Relationen zueinander dargestellt sind. Flexibilität bezieht sich hier auf die
Ablaufreihenfolge definierter Aktivitäten, die sich aus der Unstrukturiertheit des zu-
grundeliegenden Prozesses ergibt. Eine korrespondierende Flexibilität in der Prozess-
landschaft kann durch das Abstrahieren von einem festen Ablauf ermöglicht werden.
Durch die Möglichkeit des Abstrahierens von Ablaufinformationen wird dem Grund-
satz der Wirtschaftlichkeit genüge getan, der dem Detaillierungsgrad eines Modells
insbesondere für unstrukturierte Prozesse eine obere Grenze setzt (vgl. Abschnitt 2.1).
Abbildung 2.2 beinhaltet ein Gesamtbild ohne Ablaufinformationen für die Prozess-
landschaft der komponentenbasierten Softwareentwicklung. Mit fünf Aktivitäten auf
der obersten Abstraktionsebene ist die Breite der Prozesslandschaft festgelegt, wäh-
rend die Tiefe bislang durch drei Hierarchiestufen begrenzt ist. Letztere kann durch
24
2.2 Methodische Schritte zur Erstellung einer Prozesslandschaft
Verfeinernde Aktivitäten
exkl. Relationen
Verfeinernde Aktivitäten
inkl. Relationen
Abbildung 2.2: Verfeinerung von Kernaktivitäten bis auf Prozessmodellebene
25
Die Methode des Process Landscaping
weitere Verfeinerungen der dargestellten Aktivitäten verändert werden.
Der obere Teil der Abbildung zeigt die Kernaktivitäten und Aktivitäten der Software-
prozesslandschaft als Baumstruktur. Die Kernaktivitäten, die in Abbildung 2.1 als
oberste Ebene modelliert sind, erkennt man hier an den Symbolen, die das Koordina-
tensystem einer Prozesslandschaft darstellen. Sie sind den betreffenden Aktivitätsna-
men vorangestellt. Die eckigen Symbole repräsentieren verfeinernde Aktivitäten, die
selbst auch wieder verfeinert sein können. Die Aktivität Komponentenentwicklung in-
nerhalb der Kernaktivität Component Engineering ist zum Beispiel durch eine Menge
von sieben Aktivitäten weiter verfeinert worden. Die Aktivitäten Konfigurationsma-
nagement und Zusammenstellung der Komponentenmenge, die beide Teilbereiche des
Application Engineering abdecken, sind ebenfalls bereits weiter verfeinert worden. In
der Abbildung sind diese Verfeinerungen aus Platzgründen durch gestrichelte Linien
angedeutet, die die Aktivitäten mit ihren jeweiligen Teilaktivitäten verbinden.
Am Beispiel der verfeinerten Aktivität Projektmanagement wird im unteren Teil der
Abbildung 2.2 gezeigt, ob Relationen zu anderen Aktivitäten auf einer gemeinsamen
Abstraktionsebene existieren und wie deren Existenzen dargestellt werden. Der gestri-
chelte Pfeil verbindet die Aktivität Projektmanagement mit ihrer verfeinerten Darstel-
lung. Die bidirektionalen Pfeile zwischen den einzelnen Aktivitäten innerhalb der Ver-
feinerung weisen darauf hin, dass die dadurch angedeuteten Schnittstellen noch nicht
verfeinert sind (vgl. Abschnitt 2.2.4). Die abgebildeten Aktivitäten sind auch in der
Baumstruktur dargestellt, jedoch ohne Informationen über vorhandene Schnittstellen
untereinander.
2.2.4 Verfeinerung von Schnittstellen
Auf dem obersten Abstraktionsniveau einer Schnittstelle wird zunächst nur angezeigt,
dass die beteiligten Prozesse Aktivitäten enthalten, die mindestens eine Schnittstel-
le haben. Für eine detailliertere Beschreibung werden diese Schnittstellen vom Pro-
zessmodellierer mit jeweils einem Objekttyp assoziiert (im Beispiel zunächst über
entsprechende Namen, vgl. Abbildung 2.3), der angibt, welche Art von Information
ausgetauscht werden kann. Die Identifikation der in einem Softwareentwicklungspro-
jekt benötigten und erzeugten Dokumente ist hier hilfreich bei der Wissensakquise.
Dabei geht man davon aus, dass die wichtigsten Informationen in Form von Doku-
menten ausgetauscht werden (z.B. Anforderungsdokument, Projektplan, Fehlerreport,
usw.).
Bei der Verfeinerung von Schnittstellen werden jedoch nicht nur die auszutauschenden
Objekttypen identifiziert. Für jeden Objekttyp wird gleichzeitig auch die Richtung des
Informationsaustausches definiert. Damit besteht das Ergebnis der Verfeinerung von
Schnittstellen aus einer Menge von Objekttypen inklusive ihrer Relationen zu Aktivi-
täten.
Abbildung 2.3 zeigt das Beispiel der verfeinerten Schnittstelle zwischen den Kernpro-
zessen Qualitätsmanagement und Application Engineering. Sie beinhaltet insgesamt
fünf Schnittstellen zusammen mit den assoziierten Objekttypen, die ausgetauscht wer-
26
2.2 Methodische Schritte zur Erstellung einer Prozesslandschaft
Fehlerreport
getesteter Softwarecode
Spezifikationsrichtlinien
Systemarchitektur
zu testender Softwarecode
A
pp
lic
at
io
n 
En
gi
ne
er
in
g
Qu
ali
tät
sm
an
ag
em
en
t
Abbildung 2.3: Verfeinerte Schnittstelle zwischen Qualitätsmanagement und
Application Engineering
den. In der grafischen Repräsentation werden die Schnittstellen als Kreise dargestellt.
Gerichtete Kanten zeigen die Richtung des Informationsaustausches an. Beispielswei-
se werden dem Application Engineering Spezifikationsrichtlinien seitens des Quali-
tätsmanagements zur Verfügung gestellt. Einige Objekttypen werden wechselseitig
zwischen Prozessen des Application Engineering und Prozessen des Qualitätsmana-
gements ausgetauscht. Dies gilt z.B. für den Softwarecode, der als zu testender dem
Qualitätsmanagement zur Verfügung gestellt wird und nach einer Testphase zusammen
mit einem Fehlerreport an das Application Engineering zurückgeht.
2.2.5 Verfeinerung von Prozessmodellen
Prozessmodelle stellen typischerweise den konkreten Ablauf einer Menge von Akti-
vitäten dar und beinhalten damit explizit Ablaufinformationen (vgl. Abschnitt 1.3).
Sie sind daher auf den unteren Ebenen einer Prozesslandschaft anzuordnen. Die Wis-
sensakquise über die einzelnen Aktivitäten und die Reihenfolge ihrer Durchführung
startet mit weiteren Interviews und dem sorgfältigen Lesen verfügbarer Dokumenta-
tion. Indirekte Methoden der Wissensakquise eignen sich als Ergänzung der in den
Abschnitten 2.2.2 und 2.2.3 vorgeschlagenen direkten Methoden, die bei der Identi-
fikation von Kernaktivitäten und ihren Schnittstellen und ihrer Verfeinerung bis auf
Prozessmodellebene zum Einsatz kommen (vgl. Abschnitt 2.2.2). Sie erfragen Wissen
nicht direkt, sondern versuchen, die gesuchte Information aus anderen Informationen
abzuleiten. Dazu bedienen sie sich verschiedener Skalierungstechniken wie beispiels-
weise dem Konstruktgitter-Verfahren (repertory grid) [SG87].
27
Die Methode des Process Landscaping
Eine weitere wichtige Methode zur Gewinnung detaillierterer Informationen über Ak-
tivitäten ist die Entwicklung von Szenarien, die typische Situationen beschreiben. Da-
bei werden gleichzeitig weitere Aktivitäten identifiziert, die ebenfalls mit dieser Situa-
tion in Verbindung stehen. Jedes Szenario startet mit einer abstrakten Beschreibung.
Jeweils ein Prozessverantwortlicher und ein Prozessmodellierer nutzen das Szenario
für einen schrittweisen Walkthrough, wobei jeder Aktivität Detailwissen hinzugefügt
wird (etwa mögliche Ausnahmesituationen, die auftreten können; welches Objekt als
Eingabe benötigt wird und welches als Ergebnis produziert wird; wer verantwortlich
ist; welche Werkzeuge eingesetzt werden; welche Richtlinien beachtet werden müs-
sen). Das Ergebnis eines Walkthrough ist ein detaillierteres Prozessmodell, das auf
die gleiche Art und Weise wie die gerade beschriebene noch weiter verfeinert werden
kann.
Abbildung 2.4: Prozessmodell zur Beschreibung der Anforderungsanalyse
Abbildung 2.4 zeigt ein Prozessmodell zur Beschreibung der Aktivität Anforderungs-
analyse erstellen, hier dargestellt als Funsoft-Netz [Gru91], einer Variante der High-
Level-Petrinetze. Wie die Legende zeigt, sind die einzelnen Teilaktivitäten in der Ab-
bildung durch rechteckige Symbole dargestellt. Die verschiedenen Schnittstellen, die
die zu verarbeitenden Informationsobjekte weiterleiten, sind durch Kreise gekenn-
zeichnet. Auf einer tieferen Abstraktionsebene weiter verfeinerte Aktivitäten sind am
rechteckigen Symbol mit einem breitem Rand erkennbar. Werden Informationsobjekte
über Prozessmodell-Grenzen hinweg ausgetauscht, ist dies durch Kreise mit senkrecht
durchgezogener Linie (sogenannte Systemkanäle) symbolisiert. In Abbildung 2.4 wird
28
2.2 Methodische Schritte zur Erstellung einer Prozesslandschaft
beispielsweise der Review-Report zum Anforderungsdokument vom Qualitätsmana-
gement über den Systemkanal Review Anforderungsdokument zur Aktivität Überar-
beitung Anforderungen, einer Aktivität innerhalb der Anforderungsanalyse, weiterge-
leitet.
Das abgebildete Prozessmodell ist der Kernaktivität Application Engineering zugeord-
net und stellt das – immer noch recht grobe – Szenario einer objektorientierten Anfor-
derungsanalyse dar. Ausgehend von den ersten Anforderungen an das zu entwickelnde
Softwaresystem und einem Geschäftsprozessmodell des Kundenunternehmens erfolgt
die Anforderungsanalyse zusammen mit einer Machbarkeitsstudie. Letztere wird auf
der Basis von Use Cases erstellt. Sie gibt Auskunft darüber, ob bestimmte technische
Anforderungen erfüllt werden können und ob sich vielleicht einige der Anforderungen
widersprechen. Die Erkenntnisse aus der Machbarkeitsstudie und die identifizierten
Anforderungen werden in einem Anforderungsdokument zusammengefasst und nach
einem Review durch das Qualitätsmanagement entweder zunächst überarbeitet oder
nach erfolgreichem Review an nachfolgende Aktivitäten, wie zum Beispiel Spezifika-
tion erstellen, weitergeleitet.
Die Aktivität Anforderungsanalyse ist noch einmal explizit verfeinert worden. Diese
Verfeinerung ist im unteren Teil der Abbildung 2.4 dargestellt und durch gestrichelte
Linien mit der verfeinerten Aktivität verbunden. Die Aktivität Anforderungsanalyse
besteht in diesem Beispiel aus Teilschritten zur Identifikation nichtfunktionaler An-
forderungen und zu berücksichtigender Objekttypen. Für Letztere werden in einem
nächsten Schritt bestehende Relationen identifiziert, Use Cases und ein erstes grobes
Klassendiagramm (zunächst noch ohne vollständige Benennung und Zuordnung von
Methoden) erstellt. Alle Teilergebnisse werden zu einer Menge von Anforderungen
zusammengestellt, die – wie im oberen Teil der Abbildung 2.4 erkennbar – mit den
Erkenntnissen der Machbarkeitsstudie zum gesamten Anforderungsdokument zusam-
mengeführt werden. Für die zugrundeliegende formale Definition der Verfeinerung ei-
ner durch Petrinetze dargestellten Prozesslandschaft sei an dieser Stelle auf Kapitel 3
verwiesen.
Werden Informationsobjekte zwischen zwei Aktivitäten ausgetauscht, die zwei unter-
schiedlichen Kernaktivitäten A und B zugeordnet sind, so gehören die entsprechenden
Systemkanäle zur Schnittstellenvereinbarung zwischen A und B. Der Name eines Sys-
temkanals gibt den Typ der auszutauschenden Informationsobjekte an. Eine vollstän-
dige Schnittstellenvereinbarung zwischen zwei (bereits verfeinerten) Kernaktivitäten
beinhaltet folgende Informationen (vgl. Abbildung 2.3):
 Typen der auszutauschenden Informationsobjekte,
 vollständige Menge der Aktivitäten, die die Schnittstelle zum Versand von Daten
nutzen (inklusive der verantwortlichen Rollen),
 vollständige Menge der Aktivitäten, die die Schnittstelle zum Empfang von Da-
ten nutzen (inklusive der verantwortlichen Rollen),
 Medium, über das Daten auszutauschen sind (Applikation, e-mail, Telefon, etc.).
29
Die Methode des Process Landscaping
Die Wissensakquise über die einzelnen Prozesse liefert als Ergebnis sowohl detaillier-
tere, verfeinerte Aktivitäten als auch die Beschreibung verfeinerter Schnittstellen zwi-
schen den Kernaktivitäten einer Prozesslandschaft. Im Beispiel in Abbildung 2.4 sind
nicht alle Ergebnisse der Wissensakquise detailliert modelliert. Beispielsweise kann
die Anforderungsanalyse durch eine ausführlichere Darstellung der Zusammenarbeit
mit dem Qualitätsmanagement (Reviews der Use Cases und des Klassendiagramms)
noch weiter verfeinert werden.
2.2.6 Validation der modellierten Prozesslandschaft
Die Validation einer Prozesslandschaft hat deren Freigabe und Implementation zum
Ziel. Für die Freigabe einer Prozesslandschaft müssen alle Details von den Prozessver-
antwortlichen überprüft werden. Sind sie der Ansicht, dass alle Aktivitäten inklusive
ihrer Schnittstellen vollständig und korrekt sind, so ist damit eine Vorbedingung für
die Freigabe erfüllt. Die Begriffe der Vollständigkeit und Korrektheit werden hier je-
doch nicht im streng mathematischen Sinne verwendet. Eine Prozesslandschaft wird
als vollständig angesehen, wenn alle Prozessverantwortlichen die Menge der Aktivi-
täten und Schnittstellen als ausreichend und ausreichend detailliert erachten, um die
modellierten Prozesse mit Hilfe der Prozesslandschaft durchführen zu können. Eine
vollständige Prozesslandschaft gilt als korrekt, wenn die Prozessverantwortlichen al-
le modellierten Relationen zwischen Aktivitäten und Schnittstellen als sinnvoll und
erforderlich akzeptieren und sich die Prozessbeteiligten mit den dargestellten Aktivi-
täten und (falls modelliert) Abläufen identifizieren können.
Unterstützung bei der Überprüfung auf Vollständigkeit bietet die Suche nach Aktivitä-
ten und Informationsobjekten innerhalb einer Prozesslandschaft, die isoliert modelliert
sind, also keine Relationen zu anderen Landschaftselementen aufweisen. Bezüglich
der Korrektheit der modellierten Relationen zu Informationsobjekten ist zu untersu-
chen, ob diese nur produziert, aber nicht verwendet werden bzw. umgekehrt von einer
Aktivität verwendet, aber von keiner anderen dargestellten Aktivität erzeugt werden.
Eine solche Situation sollte nur in Ausnahmefällen vorkommen. In der Regel kann da-
von ausgegangen werden, dass produzierte Informationsobjekte einen Verwendungs-
zweck innerhalb einer Prozesslandschaft haben bzw. benötigte Informationsobjekte
von einer Aktivität erzeugt worden sind.
Eine weitere Vorbedingung für die Freigabe einer Prozesslandschaft besteht in der Ver-
einbarung der Schnittstellen zwischen Aktivitäten. Dazu wird für jede Aktivität, die
Ablaufinformationen enthält, ein Walkthrough mit dem Prozessverantwortlichen des
freizugebenden Modells und den Verantwortlichen aller mit den zugehörigen Schnitt-
stellen verbundenen Modellen durchgeführt. Dieser wird vom Prozessverantwortli-
chen der betreffenden Aktivität moderiert. Ziele eines solchen Walkthrough sind die
Präsentation von Prozessdetails zur Erlangung eines gemeinsamen Verständnisses für
die Struktur und den Ablauf des Prozesses sowie eine abschließende Vereinbarung
der Struktur aller das Modell betreffenden Schnittstellen. Nach Abschluss dieser Ver-
einbarung für alle Aktivitäten kann die Prozesslandschaft instanziiert werden, indem
30
2.2 Methodische Schritte zur Erstellung einer Prozesslandschaft
alle Aktivitäten bzw. Prozessmodelle inklusive ihrer Schnittstellen instanziiert werden.
Die einzelnen Modelle unterliegen ab diesem Zeitpunkt einer Änderungskontrolle. Die
Führung einer entsprechenden Änderungshistorie ist sinnvoll, um die Nachvollziehbar-
keit geänderter Modelle zu gewährleisten.
Es gibt verschiedene Möglichkeiten, eine Prozesslandschaft in die Praxis umzusetzen.
Beispiele hierfür sind das traditionelle Training der Prozessbeteiligten, operationale
Tests mit verschiedenen Testszenarien und die Ausarbeitung detaillierter Arbeitsan-
weisungen. Walkthroughs entlang von Testszenarien überprüfen, ob die Prozessland-
schaft die realen Prozesse tatsächlich widerspiegelt. Dabei sollten Szenarien verwen-
det werden, die mehr als eine verfeinerte Aktivität und mehr als eine Kernaktivität
abdecken.
Das Erstellen von Arbeitsanweisungen für die einzelnen Arbeitsschritte aller Prozesse
unterstützt die Implementation der Prozesslandschaft auf einem detaillierten Niveau
insbesondere für diejenigen Prozesse, die mehrere unterschiedliche Verantwortungs-
bereiche betreffen, da jede Weiterleitung an einen anderen Prozessbeteiligten explizit
aufgeführt ist. Arbeitsanweisungen informieren über Verantwortlichkeiten, Vereinba-
rungen bezüglich Zeit- und Kostenrahmen (Service Levels), Schlüsselindikatoren über
die Performanz von Tätigkeiten und Richtlinien, die für jeden Arbeitsschritt beachtet
werden müssen.
Abbildung 2.5 gibt abschließend einen Überblick über das Ergebnis der Anwendung
des Process Landscaping auf die Prozesse einer komponentenbasierten Softwareent-
wicklung. Die entstandene Prozesslandschaft ist relativ abstrakt und nicht vollständig
dargestellt, da dies den Rahmen der Abbildung sprengen würde und außerdem der
Überblick verloren ginge. Es soll lediglich ein Gefühl für den Aufbau und die Kom-
plexität der verschiedenen Abstraktionsebenen und ihren Relationen zueinander ver-
mittelt werden.
Die Kernaktivitäten der Prozesslandschaft sind als Rechtecke auf der obersten Ab-
straktionsebene zusammen mit angedeuteten Schnittstellen (bidirektionale Pfeile) zwi-
schen ihnen angeordnet. Des Weiteren sind die Kernaktivitäten Application Enginee-
ring und Projektmanagement (in Abbildung 2.5 mit B und E abgekürzt; vgl. Legende
in Abbildung 2.5) auf einer tieferen Abstraktionsebene beispielhaft verfeinert. Diese
Verfeinerungen sind durch gestrichelte Linien mit den jeweils verfeinerten Kernaktivi-
täten, zur besseren Übersichtlichkeit weiß hinterlegt, verbunden. Sie beinhalten nicht
nur die Menge der verfeinernden Aktivitäten, sondern zusätzlich auch durch Kreise
angedeutete Informationsobjekte, die diese austauschen. Ablaufinformationen sind da-
bei noch nicht berücksichtigt worden. Dies ist daran erkennbar, dass die zugehörigen
Pfeile meist keine eindeutige Richtung eines Informationsaustausches angeben. Abbil-
dung 2.5 zeigt ebenfalls die Verfeinerung einiger Schnittstellen durch
 die explizite Benennung der auszutauschenden Informationsobjekte,
 die Angabe der jeweiligen Richtung des Informationsaustausches und
 die (abstrakte) Darstellung aller beteiligten Aktivitäten, die über die jeweilige
Schnittstelle entsprechende Informationen empfangen bzw. versenden.
31
Die Methode des Process Landscaping
E2 E3
E5
E1 E4
E8E7E6
E9E11 E10E12
E13 E14
17
B1 B2
B4
B5
B9
B6
B3
B7
B8
BB
B B
6
22
5
A
FE
DCB
  5   gekaufte Komponente
  6   Komponentenanforderung
17   erste Anforderungen
22   Abnahmefreigabe
7,3
7,27,1
7,4
A    Komponentenbasierte
        Softwareentwicklung
B    Application Engineering
C    Component Engineering
D    Qualitätsmanagement
E    Projektmanagement
F    Domain Engineering
B7   Zusammenstellung der
       Komponentenmenge
Abbildung 2.5: Gesamtbild der Prozesslandschaft einer komponentenbasierten
Softwareentwicklung
32
2.3 Methodische Schritte zur Analyse einer Prozesslandschaft
Beispielsweise wird die Information über die Abnahmefreigabe (22) für ein erstelltes
Softwaresystem von einer verfeinernden Aktivität des Application Engineering (B
3
)
an eine verfeinernde Aktivität des Projektmanagement (E
14
) gesendet.
Innerhalb des verfeinerten Application Engineering ist beispielhaft eine verfeinernde
Aktivität (B
7
) nochmals verfeinert. So wird verdeutlicht, dass die Anzahl der Abstrak-
tionsebenen innerhalb einer Prozesslandschaft beliebig und unterschiedlich sein kann.
Zusätzlich ist in dieser Abstraktionsebene anhand der überall eindeutigen Richtung
des Informationsaustausches erkennbar, dass dort Ablaufinformationen berücksichtigt
sind. Ab welchem Detaillierungsgrad dies geschieht, ist jedoch prozessspezifisch und
bleibt dem Modellierer überlassen.
Die verschiedenen Arten von Verfeinerungen unterstützen die inkrementelle Vervoll-
ständigung von Prozesslandschaften. Da Aktivitäten und Schnittstellen in beliebiger
Reihenfolge verfeinert werden können, sind detailliertere Informationen über die ver-
schiedenen Landschaftselemente jederzeit in die Prozesslandschaft integrierbar, ohne
dass dabei der Überblick über den Gesamtzusammenhang verloren geht. Die oberen
Ebenen einer Prozesslandschaft unterstützen vor allem unstrukturierte Prozesse ohne
festgelegten Ablauf, also insbesondere auch Softwareprozesse mit einem hohen
Anteil an Kreativität und Flexibilität, die bislang kaum durch Prozessmodellierung
unterstützt werden. Der Aufwand hierfür war im Verhältnis zum Nutzen meist zu
hoch, wenn Ablaufinformationen von Beginn an im Modell zu berücksichtigen waren.
2.3 Methodische Schritte zur Analyse einer Prozessland-
schaft
Weitere Ergebnisse des Process Landscaping, die durch verschiedene Analyseschrit-
te erzielt werden, sind Aussagen über Kommunikationseigenschaften einer verteilten
Prozesslandschaft. Nutzer der verschiedenen Analyseergebnisse sind vor allem das
Projekt- und Prozessmanagement sowie die Prozessverantwortlichen. Ihre Aufgabe ist
es unter anderem, Möglichkeiten zur Effizienzsteigerung der Projektkommunikation
zu identifizieren [Ros96]. Dabei ist allerdings davon auszugehen, dass insbesondere
für fachlich sinnvoll strukturierte Prozesse die Analyse von Kommunikationseigen-
schaften lohnt. Dies sind Prozesse, die zumindest als funktionsfähig und zielführend
angesehen werden. Bei Prozessen, die diese Kriterien nicht erfüllen, lässt sich zwar
auch eine Kommunikationsanalyse durchführen, ihr Nutzen ist jedoch nur partiell und
verbessert den Gesamtprozess nicht. Hier sollte es zunächst von höherer Priorität sein,
die generelle Funktionsfähigkeit und Zielerreichung zu sichern.
Bei fachlich sinnvoll strukturierten Prozessen kann die Kommunikationsanalyse
sowohl auf statischer als auch auf dynamischer Ebene nutzbringend zur Effizienz-
steigerung der Projektkommunikation eingesetzt werden. Dies wird die nachfolgende
Diskussion zusammen mit der in Kapitel 4 präsentierten Validation zeigen.
33
Die Methode des Process Landscaping
Die Analyse lässt sich unterteilen in
 vorbereitende Schritte wie
– der Fokussierung auf bestimmte Charakteristika für Teilbereiche einer Pro-
zesslandschaft,
– der Attributierung von Landschaftselementen
 und ausführende Schritte wie
– dem eigentlichen Messen bzw. Berechnen von Attributwerten,
– dem Bewerten der Kommunikationscharakteristika.
Beim zweiten Punkt muss man sich darüber im Klaren sein, dass bei jeder Messung aus
der Vielzahl von Attributen eines Sachverhaltes eine einzelne abstrakte Zahl resultiert.
Das Process Landscaping verwendet diese Abstraktion als eine – von Zeigler, Praeho-
fer und Kim ausführlich diskutierte – Methode zur Reduzierung der Komplexität eines
Modells „unter Beibehaltung seiner Gültigkeit innerhalb eines Experimentierrahmens“
[ZPK00] und sieht sie damit als eine gültige Modellvereinfachung an. Wie die Abstrak-
tion von zu analysierenden Charakteristika einer Prozesslandschaft zu Attributen von
Landschaftselementen durchgeführt wird, ist jeweils in Abhängigkeit der konkret be-
trachteten Eigenschaften erläutert. Die Bewertung der Kommunikationscharakteristika
erfolgt anschließend auf Grundlage der gemessenen Attributwerte zusammen mit den
sich daraus ergebenden Erkenntnissen über die Struktur einer Prozesslandschaft.
Die Analyseschritte werden unabhängig von den im Einzelnen zu analysierenden Ei-
genschaften immer in einer festen Reihenfolge durchlaufen, und das Vorgehen bei
der Konzentration auf Teilmengen von Landschaftselementen weist für alle betrach-
teten Eigenschaften eine identische Struktur auf. Entsprechend ist dieses Unterkapitel
gegliedert: Abschnitt 2.3.1 diskutiert zunächst die Erstellung unterschiedlicher Sich-
ten auf eine Prozesslandschaft für eine Fokussierung auf bestimmte zu untersuchende
Charakteristika. Abschnitt 2.3.2 beschreibt anschließend diejenigen Attribute, die sta-
tische Kommunikationseigenschaften ausmachen. In Abschnitt 2.3.3 finden sich die
für eine Analyse dynamischer Kommunikationseigenschaften erforderlichen Attribu-
te. Nach der Diskussion dieser vorbereitenden Schritte erfolgt in den Abschnitten 2.3.4
bis 2.3.5, die die Bemessungsgrundlagen und Bewertungsprinzipien der verschiedenen
Eigenschaften erläutern, die Diskussion der ausführenden Schritte.
2.3.1 Umstrukturierung zur Erstellung unterschiedlicher Sichten auf
eine Prozesslandschaft
Die in Abschnitt 2.2 vorgestellten Modellierungsschritte des Process Landscaping ha-
ben eine Prozesslandschaft zum Ergebnis, die entlang eines Kundenlebenszyklus ent-
worfen wurde und somit insbesondere kausale Zusammenhänge der modellierten Ak-
tivitäten widerspiegelt. Die entstandene Form der hierarchisch aufgebauten Struktur
34
2.3 Methodische Schritte zur Analyse einer Prozesslandschaft
wird im Rahmen des Process Landscaping als logische Sicht auf eine Prozessland-
schaft bezeichnet (vgl. Abschnitt 1.3). Verteilungsaspekte sind innerhalb dieser Sicht
durch Lokationsattribute berücksichtigt, die für jede Aktivität den Standort festlegen,
an dem diese ausgeführt werden. Sie sind jedoch in der grafischen Repräsentation ei-
ner Prozesslandschaft nicht immer deutlich erkennbar. Dies erschwert eine Analyse
mit Blick auf eben diese Verteilungsaspekte.
Um lokale Verteilungsaspekte innerhalb der logischen Sicht hervorzuheben, bedarf es
einer Möglichkeit, die gegebene Prozesslandschaft nach anderen Ordnungskriterien
– eben der räumlichen Verteilung von Aktivitäten – umzustrukturieren, ohne dass
dabei bereits modellierte Informationen verloren gehen. Abbildung 2.6 verdeutlicht
diese Situation zunächst an einem abstrakten Beispiel. Dabei wird der Fokus auf die
Auswirkungen einer Umstrukturierung auf die betroffenen Aktivitäten gelegt. Von der
Darstellung von Koordinationsinformationen für die Weiterleitung von Nachrichten
und Objekten ist hier abstrahiert worden, da diese unter anderem von der Notation
einer Prozesslandschaft abhängt. Diese ist jedoch bislang noch nicht diskutiert
worden; eine abstrakte Darstellung würde den Rahmen der Abbildung sprengen und
kaum zum besseren Verständnis des Umstrukturierungskonzeptes beitragen.
[2]
[2]
[1]
[3]a1 a2
a3 a4
b1 b2
b3 b4
A B
C D
d1 d2
d3 d4
c1 c2
c3 c4
a1 a2
b3 c1
c2 c3
b3 b4
a3 d2
d3 d4
b1 d2
d3 d4
a3 b2
c3 c4
a3 d2
d3 d4
Verfeinerungen der  Kernaktivitätenai, bi, ci, di
KernaktivitätenA, B, C, D Verfeinerungsschritte
Umstrukturierung
Abbildung 2.6: Umstrukturierung einer Prozesslandschaft
35
Die Methode des Process Landscaping
Der in Abbildung 2.6 mit [1] gekennzeichnete Ausschnitt repräsentiert die oberste
Ebene einer beliebigen Prozesslandschaft, die aus den vier Kernaktivitäten A, B, C
und D besteht. Diese sind als relativ grobe, zusammengehörende Puzzleteile darge-
stellt. Grenzen ihre Ränder an ein anderes Puzzleteil, so wird dies als existierende
Schnittstelle interpretiert. Die beiden mit [2] gekennzeichneten Ausschnitte deuten
an, dass die Kernaktivitäten jeweils durch eine Menge von weiteren Aktivitäten ver-
feinert worden sind. Die Zugehörigkeit zu ihrer jeweiligen Kernaktivität wird durch
die Verwendung gleicher Buchstaben deutlich, wobei die Kernaktivitäten mit einem
Großbuchstaben versehen sind, die verfeinernden Aktivitäten jeweils mit dem entspre-
chenden Kleinbuchstaben. Für die Erstellung der lokalen Sicht muss in einem ersten
Schritt sichergestellt werden, dass für jedes Element der Prozesslandschaft – zumin-
dest für alle Aktivitäten – der Ort, an dem diese ausgeführt werden, angegeben ist. Die
Umstrukturierung kann dann anhand der verschiedenen angegebenen Orte erfolgen.
Der mit [3] gekennzeichnete Ausschnitt skizziert die lokale Sicht der so verfeinerten
Prozesslandschaft. Hier wird deutlich, dass Umstrukturierung nicht nur eine einfache
Neugruppierung bestehender Aktivitäten bedeutet, da einige von ihnen durchaus an
mehreren Orten vorhanden sein können und deshalb in der lokalen Sicht mehrfach dar-
gestellt sein müssen. In Abbildung 2.6 sind daher im rechten Ausschnitt unter anderem
die Aktivitäten a
3
, d
2
, d
3
und d
4
mehrfach vorhanden. Die verschiedenen Lokalitäten
innerhalb der Prozesslandschaft sind durch die jeweils voneinander abgegrenzt dar-
gestellten Puzzleteile angedeutet. Schnittstellen zwischen ihnen sind noch nicht klar
erkennbar.
Für eine analytische Betrachtung der Kommunikation muss auch die Koordination der
Informationsverteilung auf verschiedene Standorte explizit festgelegt werden. Konkret
bedeutet dies, dass eine Aktivität die von ihr bereitzustellenden Daten nicht nur pro-
duziert, sondern auch entscheidet, welche der nachfolgenden Aktivitäten bzw. welcher
Standort diese Daten erhalten soll. Teilweise benötigen alle nachfolgenden Aktivitä-
ten die erzeugten Daten, manchmal sind sie nur für eine Teilmenge der nachfolgenden
Aktivitäten bestimmt und damit nur für einen bzw. einige Standorte. Bezogen auf das
abstrakte Beispiel in Abbildung 2.6 muss beispielsweise festgelegt werden, ob Infor-
mationen, die in der logischen Sicht von Aktivität a
2
an Aktivität a
3
weitergeleitet
wurden, in der lokalen Sicht an alle drei existierenden Aktivitäten a
3
weiterzuleiten
sind. Stellt diese abstrakte Prozesslandschaft die Beauftragung der Entwicklung einer
einzelnen Komponente im Rahmen einer komponentenbasierten Softwareentwicklung
dar, so ist der Auftrag sicherlich nur an eine der drei Aktivitäten a
3
zu vergeben. Wird
aber hier die Weiterleitung von Richtlinien seitens des Qualitätsmanagements an die
verschiedenen Komponentenentwicklungsstandorte dargestellt, sind diese an alle drei
Standorte zu versenden, und es entstehen weitere Schnittstellen, die in der logischen
Sicht nicht erkennbar sind. Für jede Situation muss also die Informationsverteilung
kontextabhängig vom Modellierer im Modell abgebildet werden.
Die Hervorhebung von Verteilungsaspekten innerhalb einer Prozesslandschaft durch
die Erstellung einer lokalen Sicht produziert zwar eine Menge zusätzlicher Schnitt-
stellen im Modell, erschwert damit jedoch nicht gleichzeitig das Verständnis für die
36
2.3 Methodische Schritte zur Analyse einer Prozesslandschaft
Prozesslandschaft. Sie lenkt von logischen Abhängigkeiten der Aktivitäten ab und er-
leichtert somit die Konzentration auf Verteilungsaspekte. Dies ist für alle diskutierten
Analysen des Process Landscaping zumindest in Teilbereichen erforderlich.
2.3.2 Attributierung einer Prozesslandschaft zur Analyse statischer
Kommunikationseigenschaften
Die Analyse statischer Kommunikationseigenschaften schließt die Betrachtung von
Abläufen und Häufigkeiten ihrer Durchführung explizit aus und beschränkt sich auf
die Kommunikationsinfrastruktur einer verteilten Prozesslandschaft. Diese lässt sich
durch Kommunikationskanäle und deren Eigenschaften beschreiben. Unter einem
Kommunikationskanal ist dabei ein Paar von Aktivitäten zu verstehen, das einen In-
formationstyp in einer festgelegten Richtung austauscht. Insgesamt sind also immer
drei Elemente einer Prozesslandschaft und eine definierte Richtung des Informations-
austausches notwendig, um einen Kommunikationskanal zu bilden. Die Menge aller
Kommunikationskanäle repräsentiert die Kommunikationsinfrastruktur einer Prozess-
landschaft. Verbindet ein Kommunikationskanal dazu noch Aktivitäten, die an unter-
schiedlichen Standorten stattfinden, können über Eigenschaften der Kommunikations-
infrastruktur gleichzeitig auch Aussagen über die Verteilungsstruktur der Prozessland-
schaft gemacht werden. Das Process Landscaping abstrahiert Eigenschaften dieser
Infrastruktur über die Attribute Synchronität, Verschlüsselung, Privatheit, Veränder-
barkeit, Mehrfachversand und Persistenz. Diese Kommunikationsattribute werden im
Folgenden näher erläutert.
Während die ersten fünf Attribute bestimmen, wie eine Information ausgetauscht wird,
legt das Attribut Persistenz fest, ob eine Information lokal gespeichert wird, bevor sie
versandt wird bzw. nachdem sie empfangen worden ist. Ein synchroner Kommunika-
tionskanal schließt Datenträger wie Briefe oder Faxe aus, während ein asynchroner
Kanal diese durchaus repräsentieren kann.
Verschlüsselter Informationsaustausch erhöht die Komplexität der Kommunikationsin-
frastruktur, da dies Kodierungswerkzeuge beim Sender und Dekodierungswerkzeuge
beim Empfänger voraussetzt. Ein privater Informationsaustausch hat ebenfalls Auswir-
kungen auf die Komplexität, da er erhöhte Sicherheitsanforderungen an die Infrastruk-
tur stellt. Hierfür muss gewährleistet werden, dass eine Information ausschließlich vom
angegebenen Empfänger lesbar ist. Ist dieses Attribut gesetzt, wird gleichzeitig die
Identifikation besonders schützenswerter Informationen unterstützt. Die Verschlüsse-
lung einer Information erhöht somit die Sicherheit während des Datenaustausches,
während die Privatheit den Empfängerkreis für sicherheitssensible Daten einschränkt.
Das Attribut Veränderbarkeit setzt voraus, dass Informationen nicht schreibgeschützt
in einem Datenaustauschformat versendet werden, das dem Empfänger direkte Ände-
rungen an den erhaltenen Informationen erlaubt: Eine Postscript-Datei oder ein sig-
niertes Dokument weisen beispielsweise eine nicht veränderbare Form auf. Das At-
tribut Mehrfachversand hat lediglich Auswirkung auf die Infrastruktur der sendenden
Aktivität, da hier entsprechende Funktionalitäten zur Verfügung stehen müssen: Brie-
37
Die Methode des Process Landscaping
fe müssen beispielsweise mehrfach gedruckt werden, Mail-Werkzeuge benötigen eine
entsprechende Adressenverwaltung.
Eine Kommunikation kann trotz korrekter Definition eines Kommunikationskanals
immer noch daran scheitern, dass z.B. die sendende Aktivität eine Information ver-
schlüsselt, der Empfänger jedoch eine unverschlüsselte Nachricht erwartet und seine
Infrastruktur daher keine Dekodierungsfunktionalität zur Verfügung stellt. Ist die Aus-
prägung der Attribute Synchronität, Verschlüsselung, Privatheit, Veränderbarkeit und
Mehrfachversand jeweils für beide beteiligten Aktivitäten eines Kommunikationska-
nals gleich, wird er im Folgenden als funktionsfähig bezeichnet. Das Persistenzattribut
spielt hierbei eine untergeordnete Rolle, da es sich nicht auf die Art einer Kommuni-
kation auswirkt. Damit ist die Beschreibung einer komplexen Kommunikationsinfra-
struktur auf eine kleine Menge von Attributen mit jeweils einem Minimum an Ausprä-
gungsmöglichkeiten (ja bzw. nein) reduziert.
Ein weiteres Attribut, welches zumindest einen indirekten Einfluss auf die statischen
Kommunikationseigenschaften einer Prozesslandschaft hat, ist das Lokationsattribut.
Wie bereits beschrieben, legt es für jede Aktivität den Standort fest, an dem sie aus-
geführt wird. Dies erlaubt eine Kommunikationsanalyse sowohl an einem als auch
zwischen verschiedenen Orten. Insbesondere für die Analyse von verteilter Kommuni-
kation ist das Lokationsattribut von großer Wichtigkeit, denn immer dort, wo Kommu-
nikation über Ortsgrenzen hinaus stattfindet, erhöht sich gemäß der in Abschnitt 2.1
diskutierten Annahme, dass externe Kommunikation im Vergleich zu interner als teu-
rer zu bewerten ist, auch der entsprechende Kostenfaktor.
Für eine sinnvolle Analyse sind in Abhängigkeit der zu untersuchenden Eigenschaf-
ten noch einige Konsistenzprüfungen durchzuführen. Bei der Analyse statischer Kom-
munikationseigenschaften betrifft dies insbesondere die Funktionsfähigkeit von Kom-
munikationskanälen. Das Identifizieren nicht funktionsfähiger Kommunikationskanäle
deckt Abstimmungs- und Modellierungsfehler auf. Ein Abstimmungsfehler liegt bei-
spielsweise vor, wenn die einem Kommunikationskanal zugehörigen Aktivitäten von
verschiedenen Modellierern der Prozesslandschaft hinzugefügt wurden und deren je-
weilige Interviewpartner unterschiedliche Vorstellungen über ihre Kommunikationsin-
frastruktur haben. Derartige Unstimmigkeiten können nach ihrer Identifikation schnell
behoben werden.
Weitere Konsistenzprüfungen betreffen den Abgleich der Ausprägungen verschiedener
Kommunikationsattribute. So darf ein als nicht veränderbar verschicktes Dokument
von der Empfängeraktivität nicht überschrieben werden. Ist in der Prozesslandschaft
trotzdem ein Schreibzugriff auf dieses Dokument dargestellt, so ist vom Modellierer zu
überprüfen, ob diese Situation korrekt ist. Es ist möglich, dass die Empfängeraktivität
das Dokument zu einem späteren Zeitpunkt bearbeiten darf, was aber aufgrund der
fehlenden Ablaufinformation im Modell nicht unbedingt deutlich wird.
Damit sind alle für die Analyse statischer Kommunikationseigenschaften als sinnvoll
erachteten Attribute eingeführt und ihre Bedeutung – zunächst losgelöst von einer kon-
kreten Beispiellandschaft – erläutert worden. In Abschnitt 2.3.4 wird ein Interpreta-
tionsrahmen aufgespannt, der eine für den Anwender nutzbringende Analyse dieser
38
2.3 Methodische Schritte zur Analyse einer Prozesslandschaft
Kommunikationseigenschaften erlaubt. Dabei wird insbesondere der Verteilungsas-
pekt innerhalb einer Prozesslandschaft berücksichtigt, die dazu in ihrer lokalen Sicht
betrachtet wird. Eine Nutzenbetrachtung der Analyse für ein konkretes Beispiel erfolgt
in Abschnitt 4.1.3.
2.3.3 Attributierung einer Prozesslandschaft zur Analyse dynamischer
Kommunikationseigenschaften
Im Unterschied zur Analyse einer statischen Kommunikationsinfrastruktur schließt das
Process Landscaping für die Analyse dynamischer Kommunikationseigenschaften die
Berücksichtigung von Ablaufinformationen innerhalb einer Prozesslandschaft explizit
ein. Damit greift hier die von Feiler und Humphrey aufgestellte Definition der Ana-
lyse (von Softwareprozessen) als „the use of process traces, process definitions, and
process plans to assess process behaviour“ [FH93], die diejenigen Kommunikationsei-
genschaften betrachtet, die sich aus dem dynamischen Verhalten der Prozesslandschaft
ergeben.
Im Vordergrund dieses Analyseschrittes stehen verschiedene Effizienzbetrachtungen.
Sie basieren auf der simulativen Analyse verschiedener Landschaftseigenschaften, die
wiederum über die Messung und Auswertung ihrer zugeordneten Attributwerte erfolgt.
Dabei sollte zu Beginn der Analyse darauf geachtet werden, dass die zu untersuchende
Prozesslandschaft ein möglichst homogenes Abstraktionsniveau aufweist. Nur so kann
sichergestellt werden, dass die in einer Simulation gewonnenen Werte sinnvoll analy-
sierbar sind. Des Weiteren ist zu beachten, dass die Simulationsergebnisse nicht global
zu bewerten sind, sondern immer im Zusammenhang mit der konkret betrachteten Pro-
zesslandschaft zu sehen sind. Beispielsweise müssen die Kommunikationskosten eines
Standortes innerhalb einer Prozesslandschaft immer im Verhältnis zu den Kommuni-
kationskosten anderer Standorte der Landschaft und im Verhältnis zu den Kommuni-
kationskosten der gesamten Landschaft betrachtet werden, um qualitative Aussagen
über die Höhe der Kosten treffen zu können. Ohne die Vergleichswerte anderer Stand-
orte und ohne Kenntnisse über die Gesamtkosten bleiben qualitative Aussagen immer
vage und sind damit nicht sinnvoll nutzbar.
Die Effizienzbetrachtungen berücksichtigen den in Abschnitt 2.1 formulierten Grund-
satz der effizienten Kommunikation, indem sie die folgenden, die Kommunikationsef-
fizienz beeinflussenden, Kriterien beleuchten:
 Auslastungsgrad verteilter Aktivitäten bzgl. der Kommunikationshäufigkeit:
Hier liegt das Hauptaugenmerk auf der Leistungsfähigkeit der Aktivitäten in
Abhängigkeit ihrer Auslastung. Dabei ist insbesondere darauf zu achten, dass
Engpässe – also eine zu hohe Auslastung von Aktivitäten – auch die Effizienz
anderer Aktivitäten beeinflussen, wenn nämlich letztgenannte von den Ergeb-
nissen der ausgelasteten Aktivitäten abhängig sind.
 räumliche Verteilung von Aktivitäten bzgl. entstehender Kommunikationskos-
ten: Die Aktivitäten einer Prozesslandschaft sollten so verteilt sein, dass die
39
Die Methode des Process Landscaping
Kosten, die durch Kommunikation zwischen Orten (externe Kommunikation)
entstehen, möglichst gering sind.
 Informationsverteilung bzgl. der Zugriffshäufigkeit auf Informationen innerhalb
einer Prozesslandschaft: Informationen, die häufig von Prozessteilnehmern an-
gefragt werden, erfordern eine Kommunikationsstruktur, die die durch eine Be-
antwortung von Anfragen involvierten Aktivitäten unterstützen. Die betroffe-
nen Aktivitäten können über ihre Rolle identifiziert werden, die sie bei einer
initiierten Kommunikation spielen: Signalisiert ein Kommunikationspartner den
Wunsch zu kommunizieren, übernimmt er die Rolle des Initiators. Sobald der
zweite Kommunikationspartner auf diesen Wunsch reagiert, übernimmt er die
Rolle des Responders; die Kommunikation kann beginnen. Diese gilt als erfolg-
reich, wenn ein Initiator ohne nennenswerte zeitliche Verzögerung die angefrag-
te Information vom Responder erhält. Je gleichmäßiger die Rollen des Initiators
und des Responders innerhalb einer Prozesslandschaft verteilt sind, desto hö-
her ist die Anzahl erfolgreicher Kommunikationsversuche und desto effizienter
damit die Informationsverteilung.
 Informationsfluss innerhalb einer Prozesslandschaft: Werden Daten gleichen
Typs mehrfach zwischen verschiedenen Aktivitäten ausgetauscht und ist gleich-
zeitig der Bearbeitungsanteil innerhalb der Aktivitäten gering, so ist die Kom-
munikationseffizienz bzgl. des Informationsflusses als gering einzuschätzen. Die
Minimierung dieser im Folgenden als Ping-Pong-Kommunikation [GW99b] be-
zeichneten Form des Informationsflusses hilft, die Kommunikationseffizienz in-
nerhalb einer Prozesslandschaft zu steigern.
Die verschiedenen Aspekte der Kommunikationseffizienz lassen sich über Eigenschaf-
ten wie Kommunikationsaufkommen, zeitliche Prozessauslastung, durchschnittliche
Weglänge für Informationsobjekte und die Häufigkeit von Nachfrage und Bereitstel-
lung von Informationen charakterisieren, die wiederum anhand konkreter Attribute der
Elemente einer Prozesslandschaft gemessen und bewertet werden können. Für Letz-
teres wird in Abschnitt 2.3.5 ein geeigneter Interpretationsrahmen diskutiert, dessen
Nutzen in Abschnitt 4.2.2 validiert wird.
Abbildung 2.7 stellt den Zusammenhang zwischen den verschiedenen Effizienzbe-
trachtungen, ihren charakteristischen Eigenschaften und den sie beschreibenden At-
tributen dar.
Die Auslastung einer Aktivität lässt sich definieren als Verhältnis des Zeitraums, in
dem diese durchgeführt wird, zur Gesamtzeit der Durchführung aller Aktivitäten ei-
ner Prozesslandschaft. Da dieser für die Durchführung benötigte Zeitraum von der
Komplexität der zu verarbeitenden Daten abhängt, lässt sich die Kommunikationsef-
fizienz bzgl. des Auslastungsgrades mit Hilfe eines Komplexitätswertes realitätsnäher
messen, der den Zeitaufwand einer Aktivität für die Verarbeitung einer Information
beeinflusst (vgl. Abbildung 2.7). Das entsprechende Attribut Komplexitätswert ist hier
definiert als eine Zahl zwischen eins und zehn, mit dem eine für den durchschnittli-
40
2.3 Methodische Schritte zur Analyse einer Prozesslandschaft
chen Zeitaufwand angegebene Verarbeitungsdauer multipliziert wird (vgl. hierzu auch
Abschnitt 4.2.1, Seite 4.2.1).
Effizienzbetrachtung Eigenschaft Attribut
Auslastungsgrad von
Aktivitäten
Auslastung Komplexitätswert
Räumliche Verteilung Kommunikations-
aufkommen
Kapazität
Kosten
Via
Volumen
SenderInformationsverteilung
Nachfrage/
Bereitstellung von
Informationen Empfänger
Initiator/Responder-Rolle
Übertragungsrichtung
Informationsfluss durchschnittl.Pfadlänge Identifikator
Abbildung 2.7: Zusammenhang zwischen Effizienzbetrachtungen, Eigenschaften und
Attributen einer Prozesslandschaft
Die Kommunikationseffizienz bzgl. der räumlichen Verteilung von Aktivitäten lässt
sich durch die Eigenschaft Kommunikationsaufkommen beschreiben. Diese dient als
Bemessungsgrundlage für den auf einen konkreten Zeitraum bezogenen und in Kosten
umgerechneten Aufwand von Aktivitäten, der durch Kommunikation entsteht. Die Be-
rechnung des Kommunikationsaufkommens erfolgt über Attribute beteiligter Kommu-
nikationskanäle und auszutauschender Informationen. Für eine Menge von Kommuni-
kationskanälen sind hierfür jeweils ihre Kapazität und ein Kostenmaß als gemeinsame
Attribute festzulegen; über die auszutauschenden Informationen müssen jeweils ihr
Sender, das Volumen und der sie übertragende Kommunikationskanal bekannt sein.
Bei einem Informationsaustausch übernimmt die anfragende Aktivität die Rolle des
Initiators und die antwortende Aktivität die des Responders. Diese Rollen sind unter-
schiedlich zu denen eines Senders bzw. Empfängers. So ist etwa bei einem Informa-
tionsabruf von einer Webseite der Initiator der Kommunikation gleichzeitig auch der
Empfänger der Daten. Je gleichmäßiger die Rollen Initiator und Responder innerhalb
einer Prozesslandschaft verteilt sind, desto effizienter ist die betrachtete Informations-
verteilung. Insgesamt müssen, wie in Abbildung 2.7 dargestellt, Empfänger und Sen-
der als Attribute der auszutauschenden Informationen sowie die Initiator-/Responder-
Rolle und die Übertragungsrichtung als Attribute der beteiligten Kommunikations-
kanäle gemessen werden, um Aussagen über die Kommunikationseffizienz bzgl. einer
Informationsverteilung treffen zu können.
Die durchschnittliche Pfadlänge, die eine Information innerhalb einer Prozessland-
schaft bis zur ihrer endgültigen Verarbeitung benötigt hilft, weitere lohnenswerte Teil-
41
Die Methode des Process Landscaping
bereiche dieser Landschaft als Analysekandidaten zur möglichen Effizienzsteigerung
aufzuspüren. Diese durchschnittliche Pfadlänge ergibt sich aus der Menge der Rela-
tionen zwischen Aktivitäten und Schnittstellen, die ein Informationsobjekt, von einer
verfeinerten Aktivität ausgehend, passiert, bevor es zurück zu eben dieser verfeinerten
Aktivität gesendet wird. Diese an sich statische Länge wird während einer Simulati-
on mehrfach gemessen, wobei sich durch die möglichen unterschiedlichen Pfade, die
ein beobachtetes Informationsobjekt durchlaufen kann, die gesuchte durchschnittli-
che Pfadlänge berechnen lässt. Voraussetzung für die Messung einer solchen Pfadlän-
ge ist eine eindeutige Identifizierungsmöglichkeit der betrachteten Informationen auf
dem Weg durch die Prozesslandschaft und damit die Existenz eines entsprechenden
Identifikator-Attributs für jede zu betrachtende Information (vgl. Abbildung 2.7).
Bei allen Arten der Effizienzbetrachtung liegt das Hauptaugenmerk auf verschiedenen
Verteilungsaspekten innerhalb einer gegebenen Prozesslandschaft: Beim Auslastungs-
grad liegt der Fokus auf einer gleichmäßigen Arbeitsverteilung, bei der räumlichen
Verteilung auf der lokalen Verteilung der Aktivitäten selbst, bei der Informationsvertei-
lung auf einer gleichmäßigen Verteilung der Initiator- und Responder-Rolle und beim
Informationsfluss auf einem möglichst gleichverteilten Bearbeitungsanteil von Akti-
vitäten zur Verarbeitung konkreter Informationen. Wann eine Verteilung als effizient
eingestuft werden kann und welche Interpretationsprinzipien dabei zu berücksichtigen
sind, wird in Abschnitt 2.3.5 diskutiert.
Abschließend ist noch festzuhalten, dass auch die Analyse dynamischer Kommuni-
kationseigenschaften einige Konsistenzprüfungen voraussetzt. Diese bestehen jedoch
nicht nur darin, die Vollständigkeit einer Attributierung zu überprüfen, sondern auch
die Kongruenz weiterer Attributwerte zu sichern. Beispielsweise müssen für Sender
und Empfänger einer Nachricht jeweils unterschiedliche Aktivitäten angegeben sein.
Diese müssen wiederum mit Kommunikationskanälen verbunden sein, die innerhalb
der betrachteten Teilmenge aller existierenden Kommunikationskanäle liegen. Anders
ausgedrückt muss sichergestellt sein, dass ausgewählte Teilmengen einer Prozessland-
schaft alle Landschaftselemente enthalten, die für eine konkrete Analyse zu berück-
sichtigen sind.
Nachdem mit der Umstrukturierung einer logischen in die lokale Sicht einer Prozess-
landschaft und ihrer Attributierung alle vorbereitenden Schritte für die Analysen des
Process Landscaping erläutert worden sind, werden im Folgenden die Interpretations-
rahmen der verschiedenen betrachteten Eigenschaften diskutiert.
2.3.4 Interpretation statischer Kommunikationseigenschaften
Das Process Landscaping unterstützt bei der Analyse statischer Kommunikationsei-
genschaften vor allem die oberen Ebenen einer Prozesslandschaft, innerhalb derer Ab-
laufinformationen noch nicht modelliert sind (vgl. Abschnitt 2.2.3). Der Schwerpunkt
der Analyse liegt auf der Kommunikationsinfrastruktur. Für diese Analyse wird die
Vielfalt der Werte der Kommunikationsattribute wie folgt bewertet: Mit zunehmen-
der Vielfalt der Werte einer betrachteten Menge von Kommunikationsattributen steigt
42
2.3 Methodische Schritte zur Analyse einer Prozesslandschaft
die Komplexität der betrachteten Infrastruktur. Die Dichte einer Kommunikationsin-
frastruktur wird über die Anzahl existierender Kommunikationskanäle innerhalb einer
betrachteten Teilmenge einer Prozesslandschaft berechnet. Sie ist unabhängig von der
Ausprägung der Kommunikationsattribute und damit unabhängig von der zuvor be-
schriebenen Komplexität einer Infrastruktur.
Die Interpretation der Eigenschaften Komplexität und Dichte einer Kommunikations-
infrastruktur ist an die Begriffe Kopplung und Kohäsion aus dem Bereich der kom-
ponentenbasierten Softwareentwicklung angelehnt. Dort wird angestrebt, die einzel-
nen Komponenten eines Softwaresystems möglichst mit hoher Kohäsion und geringer
Kopplung zu entwickeln. Hier dienen sie als Maß bei der Zusammenfassung einzelner
Aktivitäten bzw. einer Menge von Aktivitäten an einem gemeinsamen Standort und bei
der Aufteilung auf verschiedene Standorte. Unter dem Oberbegriff der Kopplung von
Standorten betrachtet das Process Landscaping die Kommunikation zwischen Aktivi-
täten verschiedener Standorte. Die Kohäsion eines Standortes beinhaltet entsprechend
die Kommunikation zwischen Aktivitäten eines gemeinsamen Standortes. Je höher die
Kohäsion und je geringer die Kopplung von Standorten, desto besser wird die Zuord-
nung der Aktivitäten einer Prozesslandschaft zu diesen Standorten bewertet.
Der Interpretationsrahmen zur Analyse statischer Kommunikationseigenschaften ei-
ner Prozesslandschaft kann nun wie folgt aufgespannt werden: Für Teilbereiche einer
Prozesslandschaft untersucht das Process Landscaping die
 Kommunikation zwischen verschiedenen Orten mit Hilfe der
– Kopplungsdichte,
die sich aus der Anzahl der Kommunikationskanäle zwischen zwei ausge-
wählten Standorten oder bezüglich eines einzelnen zu mehreren anderen
Standorten ergibt.
– Kopplungskomplexität,
die sich aus der Anzahl unterschiedlich ausgeprägter Kommunikations-
kanäle zwischen zwei ausgewählten Standorten oder bezüglich eines ein-
zelnen zu mehreren anderen Standorten ergibt.
– Kopplungszahl,
die sich aus der Anzahl der Kanäle ergibt, die Aktivitäten an einem ausge-
wählten Standort mit Aktivitäten an anderen Standorten verbinden.
 und die Kommunikation innerhalb eines Ortes mit Hilfe der
– Kohäsionsdichte,
die sich aus der Anzahl der Kommunikationskanäle an genau einem Stand-
ort ergibt.
– Kohäsionskomplexität,
die sich aus der Anzahl der vorkommenden Kombinationen unterschied-
lich ausgeprägter Kommunikationsattribute an genau einem Standort er-
gibt.
43
Die Methode des Process Landscaping
– Kohäsionszahl,
die sich aus der Anzahl der Aktivitäten ergibt, die innerhalb eines ausge-
wählten Standortes durch Kommunikationskanäle verbunden sind.
Ziel der Analyse von Kopplung und Kohäsion mit Hilfe der obigen Begriffe ist es, be-
züglich verschiedener Umstrukturierungsziele der Kommunikationsinfrastruktur einer
Prozesslandschaft die jeweils bestmögliche Alternative herauszufinden. So kann etwa
bei einem geplanten Auflösen des Standortes einer Firma die Frage geklärt werden,
wie die einzelnen Aktivitäten dieses Standortes auf bestehende oder neue Standorte
verteilt werden sollten. Als Bemessungsgrundlage dient hierbei die Kopplung zu Ak-
tivitäten an anderen Standorten und die Kohäsion zu anderen Aktivitäten am gleichen
Standort. Eine Umverteilung der Aktivitäten des aufzulösenden Standortes ist mit dem
Ziel zu untersuchen, Orte mit hoher Kohäsion und geringer Kopplung zu erhalten. Da-
bei folgt man der Annahme, dass Kommunikation zwischen zwei Orten teurer ist als
die Kommunikation zwischen Aktivitäten, die am selben Ort ausgeführt werden (vgl.
Abschnitt 2.1). Es ist jedoch nicht sinnvoll, Kommunikation aus Gründen der Kosten-
ersparnis ersatzlos zu streichen, sondern möglichst durch Verlegung von Aktivitäten
teure externe Kommunikation durch günstigere interne Kommunikation zu ersetzen.
Die Bemessungsgrundlage für die Kommunikationskosten ergibt sich aufgrund der
bislang betrachteten statischen Kommunikationsinfrastruktur wie folgt: Zunächst wird
das Verhältnis zwischen der externen und internen Kommunikationsdichte eines Or-
tes o als Quotient betrachtet. Da auf den oberen Ebenen einer Prozesslandschaft noch
keine Ablaufinformationen berücksichtigt sind, wird die Nutzungshäufigkeit jedes
Kommunikationskanals abstrakt auf einer Skala von eins bis zehn festgelegt. Diese
Skala hat sich in verschiedenen Interviews als sinnvoll für die Abschätzung von Nut-
zungshäufigkeiten der Kommunikationskanäle herausgestellt. Die Abschätzung sollte
mit Hilfe der Prozessbeteiligten bzw. -verantwortlichen durchgeführt werden, die von
entsprechenden Erfahrungswerten abstrahieren können.
Die Kosten pro Nutzung eines Kommunikationskanals werden auf einer Skala von
eins bis fünf bestimmt. Diese Skala ergibt sich aus der Anzahl der zu berücksichti-
genden Kommunikationsattribute. Die Werte der Kopplungs- und Kohäsionskomple-
xitäten dienen hierbei als Richtwerte: Je komplexer die Kommunikationsinfrastruktur
zwischen zwei Aktivitäten oder zwischen zwei Orten, desto höher der Wert auf der
Kostenskala. Insgesamt lässt sich der so aufgebaute Kommunikationskostenfaktor Kkf
berechnen als
Kopplungsdichte(o) × (Nutzungsha¨ufigkeit ×Kosten) pro externer Kanal
Koha¨sionsdichte(o) × (Nutzungsha¨ufigkeit ×Kosten) pro interner Kanal
Er ermöglicht es, auf einer einfachen Bemessungsgrundlage für die statischen Kommu-
nikationsaspekte einer Prozesslandschaft zu bleiben. Je kleiner der Kkf eines Stand-
ortes ist, desto effizienter ist seine Kommunikationsinfrastruktur.
Wird die Minimierung dieses Kkf ausschließlich und konsequent als Optimierungs-
ansatz verwendet, führt dies zu dem Ergebnis, dass alle Aktivitäten am gleichen Ort
stattfinden. In der Realität ist dieser ausschließliche Ansatz jedoch unbrauchbar, da
44
2.3 Methodische Schritte zur Analyse einer Prozesslandschaft
viele Aktivitäten aus unterschiedlichsten Gründen über verschiedene Standorte ver-
teilt stattfinden. Kundennähe, Standortkosten oder gemeinsam mit anderen zu nutzen-
de Ressourcen sind nur einige dieser Gründe. Eine Grundvoraussetzung für Optimie-
rungsansätze sollten daher vorhandene Vorüberlegungen bzw. Strategien sein, wie und
wo eine Prozesslandschaft verändert werden soll. Denkbare Strategien in diesem Zu-
sammenhang sind
 die geplante Auflösung eines Standortes,
 das geplante Zusammenlegen von Standorten,
 die geplante Verlagerung einzelner Aktivitäten oder
 der geplante Aufbau eines neuen Standortes.
Grundsätzlich sind alle vier Strategien zur Veränderung bzw. Verbesserung einer Pro-
zesslandschaft ähnlich strukturiert. Sie erfordern jedoch unterschiedliche Vorgehens-
weisen bei der Optimierung. Soll beispielsweise ein Standort aufgelöst werden, so ist
möglichst ein Ort mit hohem Kkf in Betracht zu ziehen. Werden seine Aktivitäten auf
diejenigen Standorte verteilt, mit denen sie zuvor intensiv extern kommuniziert haben,
kann diese Kommunikation nach ihrer Verlagerung durch günstigere interne Kommu-
nikation ersetzt werden. Sollen Standorte zusammengelegt werden, so sind zwei Orte
auszuwählen, die eine relativ hohe Kopplungsdichte aufweisen, damit der Kkf des re-
sultierenden Ortes möglichst gering gehalten werden kann. Nach der Verlagerung einer
Aktivität zu einem anderen Standort sollte der Kkf beider Orte (Ursprung und Ziel)
mindestens gleich bleiben, jedoch nicht größer als vorher sein. Dadurch wird verhin-
dert, dass eine Aktivität aus einem Verbund mit hoher Kohäsion gelöst wird. Für den
geplanten Aufbau eines neuen Standortes durch Verlagerung verschiedener Aktivitä-
ten gilt schließlich, dass die Summe aller Kommunikationskostenfaktoren (inklusive
des neuen Standortes) möglichst kleiner werden sollte.
Schließlich bleibt noch festzuhalten, dass sich alle vier Strategien ausschließlich
auf statische Eigenschaften der Kommunikationsinfrastruktur einer Prozesslandschaft
stützen. Diese Form der Analyse eignet sich daher besonders für unstrukturierte und
flexible Prozesse ohne festgeschriebene Abläufe wie beispielsweise Softwareprozesse
mit einem hohen Maß an Kreativität und Flexibilität. Die hier diskutierten Optimie-
rungsansätze sind jedoch nicht als einzig mögliche Kriterien zur Optimierung einer
Prozesslandschaft anzusehen. So werden oft politische Überlegungen eingesetzt, wenn
es um die Veränderung von Standorten eines Unternehmens geht. Die hier beschriebe-
nen Strategien sind als weitere mögliche Entscheidungshilfen für Prozessverantwort-
liche gedacht, wie sie bislang in der Literatur noch nicht berücksichtigt worden sind.
Die vier gerade diskutierten Optimierungsansätze werden in Abschnitt 4.1.2.2 auf eine
Beispielprozesslandschaft angewendet und ihr Nutzen validiert.
45
Die Methode des Process Landscaping
2.3.5 Interpretation dynamischer Kommunikationseigenschaften
Die Interpretation dynamischer Kommunikationseigenschaften einer verteilten Pro-
zesslandschaft muss vor allem das dynamische Verhalten beteiligter Aktivitäten wäh-
rend der Kommunikation berücksichtigen. Damit reichen statische Messungen von At-
tributwerten nicht mehr aus. Das Process Landscaping bietet die simulative Analyse
für die Auswertung des dynamischen Verhaltens an.
Für eine Nutzenbetrachtung und damit auch für eine qualitative Bewertung der durch
die Simulation einer Prozesslandschaft erhaltenen Zahlengrößen verschiedener Effizi-
enzaspekte stellt sich die Frage, wie eine Einschätzung der Qualität dieser Effizienz-
aspekte vorgenommen werden kann. Beim Process Landscaping wird dies in Anleh-
nung an die AMI-Methode realisiert [DF96]. Die Methode besteht aus zwölf Schritten,
die zu vier Aktivitäten (Assess, Analysis, Metricate, Improve) zusammengefasst sind.
Die Aktivität Assess definiert nach der ersten Einschätzung einer Prozesslandschaft
Primärziele wie z.B. die Verbesserung der Kommunikationseffizienz des modellier-
ten Entwicklungsprozesses. Diese Primärziele werden nach ihrer Validation durch die
Aktivität Analyse in Teilziele wie z.B. der Kommunikationseffizienz bzgl. einer räum-
lichen Verteilung miteinander kommunizierender Aktivitäten und der Kommunikati-
onseffizienz bzgl. des Informationsflusses innerhalb einer Prozesslandschaft zerlegt,
für die dann Metriken identifiziert werden können. Die Aktivität Metricate ist für das
Sammeln der für eine Analyse notwendigen Daten zuständig (im Rahmen des Pro-
cess Landscaping per Simulation). Schließlich beinhaltet die Aktivität Improve die
Auswertung der Daten, wobei sie die quantitativen Analyseergebnisse auch qualitativ
bewertet.
Man kann jedoch auch – wie bei der Analyse statischer Kommunikationseigenschaf-
ten – ein konkretes Optimierungsziel voraussetzen und auf der Basis einer gegebenen
Attributausprägung (Ist-Zustand einer gegebenen Prozesslandschaft) die effizientes-
te Alternative für eine geplante Attributausprägung (Soll-Zustand einer Prozessland-
schaft) ermitteln. Die in Abschnitt 2.3.2 formulierten Optimierungsansätze, die eine
Verlagerung von Aktivitäten innerhalb einer Prozesslandschaft auf andere Standorte
implizieren, sind auch für die Analyse dynamischer Kommunikationseigenschaften
geeignet. Modellierungsseitig sollte zuvor – wie bereits in Abschnitt 2.3.3 erläutert –
darauf geachtet werden, dass die betrachteten Teilbereiche einer gegebenen Prozess-
landschaft in etwa die gleiche Abstraktionstiefe haben, um zu sinnvollen und damit
verwertbaren Ergebnissen zu gelangen. Die Bewertung der Ergebnisse für diese Teil-
bereiche kann dann mit Hilfe von Vergleichswerten bezüglich anderer Teilbereiche
erfolgen.
Im Folgenden wird auf die in Abschnitt 2.3.2 diskutierten Effizienzbetrachtungen ein-
gegangen und jeweils erläutert, wie die Simulationsergebnisse hinsichtlich einer mög-
lichen Effizienzoptimierung zu interpretieren sind.
Je gleichmäßiger die Auslastung der Aktivitäten innerhalb einer Prozesslandschaft,
desto effizienter kann die Kommunikation innerhalb dieser Landschaft erfolgen. Als
Bewertungsgrundlage sollte jedoch nicht nur die durchschnittliche Auslastung aller
46
2.3 Methodische Schritte zur Analyse einer Prozesslandschaft
Aktivitäten im Verhältnis zur Gesamtdauer einer Simulation dienen, da durch die Mit-
telwertbildung gerade die interessanten Extremwerte aus dem Blickfeld geraten. Die
Betrachtung der Schwankungsbreite ist ebenfalls von großer Bedeutung, da ihr Auftre-
ten zu zeitweiligen Verarbeitungsengpässen führen kann. Eine Auslastung von 100%
über einen längeren Zeitraum hinweg zeigt meist eine überlastete Aktivität an. Zur
Entlastung kann diese entweder von Teilaufgaben befreit oder mit mehr Ressourcen
ausgestattet werden. Bei einem niedrigen Auslastungsgrad ist der Kontext näher zu
betrachten. Es gibt durchaus Aktivitäten, die im Verlauf eines durchschnittlichen Kun-
denlebenszyklus nur selten aktiv werden. Aus dem Bereich der komponentenbasierten
Softwareentwicklung sei hier die Abnahme eines erstellten Softwaresystems mit dem
Kunden als Beispiel genannt. Hat die untersuchte Aktivität jedoch keinen solchen Aus-
nahmecharakter, so ist die geringe Auslastung in vielen Fällen auf eine Überlastung der
ihr vorgelagerten Aktivitäten zurückzuführen.
Für die räumliche Verteilung miteinander kommunizierender Aktivitäten gilt: Je nied-
riger das externe Kommunikationsaufkommen (gemäß dem Prinzip, dass externe
Kommunikation teurer ist als interne) und je gleichmäßiger dies innerhalb einer Pro-
zesslandschaft verteilt ist, desto effizienter kann die Kommunikation durchgeführt wer-
den. Als Bewertungsgrundlage wird das Verursacherprinzip herangezogen, bei dem
einer sendenden Aktivität pro Informationsaustausch die bei der externen Kommuni-
kation entstehenden Kosten berechnet werden. Eine Einzelberechnung erfolgt durch
die einfache Formel:
Kapazit a¨t
Volumen
×Kostenmaß
Kapazität und Volumen werden hierbei in kB gemessen, für das Kostenmaß stehen
verschiedene Kostenmodelle zur Verfügung, die in Anhang A.3 aufgeführt sind.
Gleichzeitig wird der Auslastungsgrad der an externer Kommunikation beteiligten
Kommunikationskanäle berechnet. Ihre Nutzungsdauer im Verhältnis zur Gesamtzeit
einer Simulation bestimmt das (externe) Kommunikationsaufkommen zwischen zwei
Standorten. Als Faustregel für eine effiziente räumliche Verteilung sollte gelten, dass
zwei Aktivitäten um so eher an einem gemeinsamen Standort auszuführen sind, je
mehr sie miteinander kommunizieren.
Eine geschickte Informationsverteilung trägt – wie bereits in Abschnitt 2.3.3 erläu-
tert – im Rahmen des Process Landscaping zu einer hohen Kommunikationseffizienz
bei, wenn die Rollen Initiator und Responder und damit auch der Aufwand für die
Reaktion auf Informationsanforderungen möglichst gleichmäßig auf alle Aktivitäten
innerhalb einer Prozesslandschaft verteilt sind. Dies minimiert gleichzeitig den zeitli-
chen Aufwand einer anfragenden Aktivität, benötigte Informationen zu erhalten. Ein
Aufwand kann in diesem Zusammenhang in zweifacher Hinsicht gemessen werden.
Zum einen stellt jede Anfrage, die beantwortet werden muss, eine Unterbrechung der
antwortenden Aktivität dar. Daher sollte die Anzahl von Anfragen pro Zeiteinheit ein
bestimmtes Maß nicht überschreiten. Zum anderen entsteht ein Aufwand beim Res-
ponder dadurch, dass die angefragten Informationen bereitgestellt werden müssen.
47
Die Methode des Process Landscaping
Dieser Aufwand lässt sich als Zeit messen die der Responder braucht, um nach Be-
stätigung des Kommunikationswunsches die angefragten Informationen zu liefern. Der
Aufwand für den Responder kann unter anderem dadurch reduziert werden, dass Infor-
mationen so weit wie möglich zwischengespeichert werden. Insbesondere wenn sich
abzeichnet, dass ein und dieselbe Information von verschiedenen Anfragern angefor-
dert wird, sollte über ein Auslagern der Informationsverteilung nachgedacht werden.
Die Anfrage nach Richtlinien seitens verschiedener Komponentenentwicklungsstand-
orte an das Qualitätsmanagement innerhalb einer verteilten Softwareentwicklung ist
ein Beispiel für eine solche Situation. Eine Verbesserung könnte dadurch erfolgen,
dass die Richtlinien in einem Intranet abgelegt werden und dort jeder anfragenden
Aktivität lesend zur Verfügung gestellt werden.
Die Kommunikationseffizienz bzgl. des Informationsflusses innerhalb einer Prozess-
landschaft zeichnet sich durch eine möglichst große durchschnittliche Pfadlänge zwi-
schen zwei verfeinerten Aktivitäten aus, die zur Verarbeitung einer konkreten Infor-
mation erforderlich ist: Eine kurzer Pfad, auf dem ein Informationsobjekt, ausgehend
von und endend in einer verfeinerten Aktivität, aber innerhalb einer zweiten verfeiner-
ten Aktivität bearbeitet wird, weist auf eine geringe Bearbeitungstiefe hin. Eine solche
Situation weist in aller Regel auf eine tayloristische Organisation hin [PW94], in der
Prüfung und Bearbeitung einer Information strikt voneinander getrennt sind. Ist eine
solche Situation jedoch nicht aufgrund einer tayloristischen Organisation entstanden,
so sollte überlegt werden, ob die Aufgabenverteilung zugunsten einer höheren Bear-
beitungstiefe verändert werden kann. Je kürzer also der Bearbeitungspfad einer Infor-
mation, desto wahrscheinlicher ist es, einen ineffizienten Informationsfluss aufgespürt
zu haben. Zwar ist die Länge eines Bearbeitungspfades eine statische Eigenschaft, die
sich bereits durch die Modellierung der Prozesslandschaft ergibt. Während der Simu-
lation werden jedoch – soweit vorhanden – verschiedene mögliche Pfade unterschied-
lich häufig durchlaufen. So bestimmt die Dynamik die durchschnittliche Weglänge,
die innerhalb einer Prozesslandschaft während der Simulation durchlaufen wird. Zeigt
sich dabei ein eher niedriger Wert (beispielsweise im unteren Drittel einer gegebenen
Skala), so ist dies ein Zeichen dafür, dass ein kurzer Pfad relativ häufig durchlaufen
wird.
2.4 Vergleich mit existierenden Modellierungs- und
Analyseansätzen
Ausgangspunkt für einen Vergleich des Process Landscaping mit anderen
Modellierungs- und Analyseansätzen ist die Menge der in Kapitel 1 identifizierten fünf
Problemstellungen (siehe Seite 5), für die das Process Landscaping Unterstützung an-
bietet. Es wird diskutiert, ob und inwiefern andere Methoden diese Problemstellungen
ebenfalls berücksichtigen. Zusätzlich wird untersucht, welche verschiedenen Aspekte
zu Vorgehen, Rollen, Ergebnissen und unterstützenden Techniken, die in der Literatur
auch als Komponenten einer Methode bezeichnet werden [Hey95, HB96], im Vorder-
48
2.4 Vergleich mit existierenden Modellierungs- und Analyseansätzen
grund der jeweiligen Ansätze stehen. Dies ist insbesondere vor dem Hintergrund zu
sehen, dass der Begriff der Methode gegenwärtig sehr unterschiedlich verwendet wird
und somit ein Vergleich verschiedener Ansätze nicht immer ohne weiteres möglich ist.
Für die nachfolgende Diskussion sind aus jeder dieser Methodenkategorien, die sich
aus der Berücksichtigung der oben aufgeführten Aspekte ergeben, einzelne Repräsen-
tanten ausgewählt worden.
Viele Prozessmodellierungsmethoden legen den Schwerpunkt auf eine zugrundelie-
gende Notation, die jedoch laut der Definition aus dem Informatik-Begriffsnetz [GF01]
nur einen von mehreren Bestandteilen einer Methode ausmacht. Wenn Abeysinghe und
Phalp beispielsweise die Kombination zweier Prozessmodellierungsmethoden disku-
tieren [AP97], sind dies keine Methoden wie im Rahmen dieser Arbeit formuliert (vgl.
Einleitung dieses Kapitels 2), sondern lediglich Notationen (im genannten Beispiel
Hoare’s Communicating Sequential Processes (CSP) [Hoa85] und eine Untermenge
der Role Activity Diagrams (RADs) [OR86]), die wiederum Bestandteil einer Metho-
de sein können. Ziel der in [AP97] vorgestellten Methodenkombination ist es, zunächst
mit RADs ein lesbares und verständliches Prozessmodell für Prozessbeteiligte zu er-
stellen, um die semantische Korrektheit der Modelle diskutieren zu können. Anschlie-
ßend soll die Übersetzung nach CSP dazu dienen, ein Modell zur Prozesssimulation
zu erhalten, um die Auswirkungen von Prozessveränderungen untersuchen zu können.
Das Process Landscaping wird dagegen durchgängig von nur einer Notation, den Pe-
trinetzen (vgl. Kapitel 3), unterstützt. Bei dieser wird für einen schnellen und transpa-
renten Überblick zunächst von einigen Petrinetz-Eigenschaften abstrahiert, die in einer
späteren Modellierungsphase für detaillierte Analysen wieder hinzugefügt werden.
Insgesamt berücksichtigt die Methode von Abeysinghe und Phalp keine der fünf
in Abschnitt 1.1 aufgeführten Problemstellungen explizit. Schnittstellen zwischen
Prozessmodellen werden hier lediglich über gleichnamige Aktivitäten identifiziert;
Verteilungs- und Kommunikationsaspekte werden ebenso wie die Betrachtung von
(Software-)Prozessen unter verschiedenen Blickwinkeln nicht angesprochen. Mit
RADs kann man zwar auch unstrukturierte Prozesse abbilden, dies wird aber mehr
durch die Notation unterstützt als durch die Vorgehensweise einer Methode.
Andere Methoden betreffen Softwareprozessverbesserungen (Software Process
Improvement, SPI). Dies können Analysemethoden sein, die sich auf konkrete Eigen-
schaften von Prozessen beziehen und für diese Optimierungsansätze bieten, wie das
beim Process Landscaping für die verschiedenen Kommunikationseigenschaften der
Fall ist. Meist werden darunter jedoch spezielle Methoden wie SPICE [Sim96] und
BOOTSTRAP [KSK+94] verstanden, oder es werden sogenannte maturity models wie
CMM [PWCC94] zur Prozessverbesserung eingesetzt. Sie konzentrieren sich auf Pro-
zesseigenschaften zur Unterstützung von Unternehmensstrategien und -organisationen
und versuchen, für diese einen Zielerreichungsplan zu entwickeln [CFS01]. Beispiele
aus diesem Bereich, die auf den oben genannten Methoden und Modellen aufsetzen,
sind u.a. Accelerator, ein Modell und eine Methode zur Einführung eines Verbesse-
rungsprogramms für Prozesse [IPB01] und eine Methode von Kellner et al. für Design,
Definition und Entwicklung von Softwareprozessen [KBO96].
49
Die Methode des Process Landscaping
Der erste Schritt der Accelerator-Methode ist die Evaluation von Unternehmensprozes-
sen auf der Basis von Dokumenten-Reviews, Interviews und Informationsanalyse. Ob
und wie das Evaluationsergebnis als eine Menge von Prozessmodellen dokumentiert
wird, bleibt dabei den Anwendern von Accelerator überlassen; eine (durchgängige)
Modellierungsunterstützung wird nicht angeboten. Während der Evaluationsphase ste-
hen nicht die Schnittstellen zwischen Prozessen bzw. Aktivitäten im Vordergrund der
Betrachtung, sondern die Koordination parallel durchzuführender Aktivitäten. Auch
die geografische Verteilung der Prozessbeteiligten und die daraus resultierende Aus-
wirkung auf deren Kommunikationseffizienz wird nicht explizit untersucht.
Kellner, Briand und Over sehen die Erstellung von Prozessmodellen als wichtige Vo-
raussetzung zur Erreichung von Prozessverbesserungen an [KBO96]. Schwerpunkte
ihrer Methode liegen daher auf einer geeigneten Vorgehensweise zum Design und zur
Definition von Softwareprozessen und auf der Institutionalisierung einer kontinuier-
lichen Prozessverbesserung. Aber auch hier wird keine explizite Modellierungsunter-
stützung angeboten. Stattdessen verweisen die Autoren unter anderem auf [CKO92],
wo bewusst auf die Empfehlung eines Modellierungsparadigmas verzichtet wird, da
ihrer Meinung nach jedes Paradigma nur die Darstellung bestimmter Aspekte von Soft-
wareprozessen unterstützt. Aus diesem Grund werden auch bei ihrer Methode weder
Schnittstellen noch Verteilungsaspekte explizit betrachtet, und es fehlt eine gezielte
Unterstützung für unstrukturierte Prozesse. Insgesamt betrachten damit beide Metho-
den, die den Fokus auf Softwareprozessverbesserungen setzen, keine der Problem-
stellungen, die das Process Landscaping aufgreift. Lediglich das Ziel der Prozessver-
besserung bezüglich bestimmter Eigenschaften kann als Gemeinsamkeit festgehalten
werden.
Bayer, Junginger und Kühn schlagen (für die Entwicklung von e-business-
Anwendungen) eine Modellierungsmöglichkeit vor, die Schnittstellen zu Informati-
onssystemen zwar berücksichtigt, aber den Schwerpunkt eher auf die Schnittstellen
zwischen Kunde und e-business-Anwendung sowie die im Rahmen eines Entwick-
lungsprozesses zu erstellenden Teilprodukte setzt [BJK00]. Ihr Ansatz ist stark werk-
zeugzentriert, da sie mit dem „(meta) business process management toolkit ADONIS“
den Modellierer unterstützen wollen, ohne detailliert auf eine dem Werkzeug und
seiner Handhabung zugrundeliegende Methode einzugehen. Bei dieser Methode zur
„Metamodellierung im Geschäftsprozeßmanagement“ wird die Menge der methodi-
schen Schritte zur Erstellung eines Prozessmodells als Vorgehensmodell bezeichnet
und die Notation als eine – von der Methode selbst unabhängige – Modellierungs-
technik [KJKP99]. Da für die Modellierung sowohl ereignisgesteuerte Prozessketten
[LSW97] als auch Aktivitätsdiagramme [Bal01] eingesetzt werden können, unterstützt
die Methode die Darstellung strukturierter und unstrukturierter Prozesse. Eine durch-
gängige Modellierungsunterstützung, die Inkonsistenzen beim Notationswechsel ver-
meidet, ist jedoch nicht vorhanden. Dies verhindert eine Modellerstellung nach der
Process Landscaping Methode, die im Rahmen eines Modellierungsprojektes Ablauf-
informationen erst zu einem späteren Zeitpunkt berücksichtigen will.
Die explizite Berücksichtigung der geografischen Verteilung eines Prozesses ist bei der
50
2.4 Vergleich mit existierenden Modellierungs- und Analyseansätzen
von Junginger et al. erarbeiteten Methode ebenfalls nicht gegeben; eine hierfür geson-
derte Sicht auf Prozessmodelle wird nicht zur Verfügung gestellt. Allgemein sehen die
Autoren die Erstellung verschiedener Sichten jedoch als wichtige Forschungsaufgabe
im Rahmen der Weiterentwicklung ihrer Methode an [KJKP99]. Die bei den genann-
ten Autoren diskutierten Anforderungen an eine Analyse sind auf einem anderen Ab-
straktionsniveau als beim Process Landscaping zu sehen. Sie bieten im Rahmen ihrer
Methode die Möglichkeit sowohl der statischen als auch der dynamischen Analyse an.
Beide Analyseformen beziehen sich jedoch nicht auf konkrete Ziele, wie dies durch
die schwerpunktmäßige Betrachtung von Kommunikationsstrukturen und -verhalten
beim Process Landscaping der Fall ist.
Zwei weitere Methoden, die sich nicht auf eine Werkzeugunterstützung oder einzelne
Methodenbestandteile konzentrieren, werden nachfolgend ebenfalls mit dem Process
Landscaping verglichen. Die PTA (Process Tradeoff Analysis) Methode ist ein quan-
titativer Modellierungsansatz zur Unterstützung von Planungs- und Kontrollaktivitä-
ten des Projektmanagements, die potentielle Prozessveränderungen wie Entwicklungs-
kosten, Produktqualität und Projektplanung evaluieren [RHV00]. Auf der Grundlage
stochastischer, zustandsbasierter Simulationsmodelle werden verschiedene mögliche
Prozessalternativen gegeneinander abgewogen. Ein ähnliches Vorgehen ist beim Pro-
cess Landscaping für potentielle Veränderungen einer Kommunikationsinfrastruktur
gewählt worden. Die Identifikation der bestmöglichen Prozessalternative im Hinblick
auf zukünftige Prozessveränderungen wird beim Process Landscaping jedoch auch für
die oberen Ebenen einer Prozesslandschaft unterstützt, für die mit PTA aufgrund der
fehlenden Dynamik keine Simulationsmodelle erstellt und ausgewertet werden kön-
nen. Für detailliert modellierte, strukturierte Prozesse liegt der Analyseschwerpunkt
von PTA auf der Auswertung von Daten bezüglich Kosten, Zeiten und Qualität für
ein Softwareentwicklungsprojekt bzw. ein zu erstellendes Softwareprodukt [RVM99].
Raffo et. al berücksichtigen zwar explizit die Abhängigkeiten zwischen verschiede-
nen Prozesskomponenten, dies erfolgt jedoch nicht über die Betrachtung von Schnitt-
stellen, sondern über ein gemeinsames Datenrepository. Kommunikationsaspekte wer-
den nicht explizit betrachtet, geografische Verteilungsaspekte eines Softwareprozesses
ebenfalls nicht.
SeeMe präsentiert sich als Modellierungsmethode „für die Darstellung sozialer und
semi-strukturierter Aspekte von Kommunikations- und Kooperationsbeziehungen“.
Dabei liegt ein Schwerpunkt auf der „Vermeidung hinderlicher Einschränkungen der
Modellierungsfreiheit sowie der Darstellung vager Informationen“ [HHL98]. Diese
Methode ist jedoch nicht für den Anwendungsbereich der Geschäftsprozessmodellie-
rung oder – noch spezieller – für den der Softwareprozessmodellierung entwickelt,
sondern für den Bereich sozialer Prozesse mit Schwerpunkt auf Kommunikation. Auf-
grund dieser völlig unterschiedlichen Einsatzgebiete erfährt auch der Begriff der Kom-
munikation eine gänzlich andere Betrachtung. Während SeeMe Prozessmodelle als
Kommunikationsmittel u.a. zur Aushandlung von Softwareanforderungen ansieht und
daher ein Optimum ihrer Kommunizierbarkeit anstrebt, nutzt das Process Landscaping
eine Prozesslandschaft zur Analyse von Kommunikationsstruktur und -verhalten inner-
51
Die Methode des Process Landscaping
halb der dargestellten Prozesse. Daher sind das Process Landscaping und SeeMe bzgl.
ihrer Modellierungsziele nur schwer zu vergleichen. Lediglich die Anforderung, Infor-
mationen bei der Modellierung bewusst auszulassen, kann als gemeinsames Merkmal
eingestuft werden: Während das Process Landscaping auf den oberen Ebenen einer
Prozesslandschaft bewusst auf die Darstellung von Ablaufinformationen verzichtet,
hebt SeeMe diese Einschränkungen der Modellierungsfreiheit durch die Bereitstel-
lung zusätzlicher Notationselemente auf, die dem Modellierer das bewusste Auslas-
sen von Informationen sowie die Kennzeichnung unsicherer Informationen ermögli-
chen [HKL02]. Unstrukturierte Prozesse können also mit beiden Methoden abgebildet
werden, somit bieten beide einen Lösungsansatz zur vierten in Abschnitt 1.1 disku-
tierten Problemstellung an. Das beim Process Landscaping als elementar angesehene
Prozesselement der Schnittstelle wird bei der Modellierung mit SeeMe jedoch nicht
eingesetzt. Des Weiteren werden die Problemstellungen bezüglich der geografischen
Verteilung der Prozessbeteiligten und der Erstellung verschiedener Sichten auf eine
Prozesslandschaft mit SeeMe nicht berücksichtigt.
Hess und Brecht untersuchen insgesamt 17 Methoden „für die projekthafte, grundle-
gende Neugestaltung betrieblicher Prozesse“ aus unterschiedlichen „Denkrichtungen“
und Umfeldern [HB96]. Sie stellen dabei ebenfalls gravierende Unterschiede sowohl in
den Schwerpunkten dieser Methoden (Ablauforganisation, Anwendungsdomäne, un-
terstützende Informationssysteme) als auch in ihrem Aufbau (Vorgehen in Reorga-
nisationsprojekten, Ausarbeitung von Modellierungstechniken) fest. Ihr Fazit: „Eine
einheitliche Konstruktionslehre für Prozesse hat sich noch nicht herausgebildet“.
Für den Vergleich der Methoden haben die Autoren einen Kriterienkatalog erstellt, der
verschiedene Gesichtspunkte von Gestaltungsfeldern über die Einbeziehung der Rolle
der Geschäftsstrategie bis zur Gegenüberstellung der Methodenkomponenten enthält.
Die Kriterien, auf deren Grundlage das Process Landscaping entstanden ist, spielen für
den Vergleich von Hess und Brecht jedoch keine Rolle. Umgekehrt enthält ihr Katalog
aber Kriterien, an denen sich auch das Process Landscaping messen lassen kann:
 Die bei den Autoren als Umfang der Prozessarchitektur bezeichnete Menge der
betrachteten Prozesse beinhaltet beim Process Landscaping alle Prozesse eines
Unternehmens.
 Die Ist-Dokumentation der betrachteten Prozesse kann beim Process Landsca-
ping flexibel von grob, über in Teilbereichen detailliert bis detailliert gestaltet
werden.
 Das generelle Vorgehen der Methode ist als Top-Down einzustufen.
 Die Modellierung des Ablaufs beinhaltet beim Process Landscaping sowohl
zeitliche Abhängigkeiten als auch den Datenfluss zwischen Aktivitäten.
 Als Methodenkomponenten des Process Landscaping sind das strukturierte Vor-
gehen, beteiligte Rollen, verschiedene Techniken zur Wissensakquise, Model-
lierung und Analyse sowie die explizit zu erreichenden Ziele bzw. Ergebnisse
vorhanden.
52
2.4 Vergleich mit existierenden Modellierungs- und Analyseansätzen
Der Vergleich des Process Landscaping mit anderen Modellierungs- und Analyseme-
thoden macht deutlich, dass der Begriff der Methode auch aktuell noch sehr unter-
schiedlich verwendet wird. Beim Entwurf einer Methode wird zumeist nur eine Teil-
menge ihrer Bestandteile (Notation, systematische Handlungsanweisungen und Re-
geln zur Überprüfung der Ergebnisse), ihr Ziel oder aber eine Werkzeugunterstützung
schwerpunktmäßig betrachtet. Das Process Landscaping verfolgt dagegen einen An-
satz, der alle aufgeführten Bestandteile berücksichtigt. Tabelle 2.1 fasst die verglei-
chende Diskussion zusammen.
Da nicht alle diskutierten Methoden einen Namen haben, ist in der ersten Spalte der
Tabelle zunächst eine Referenz angegeben, um eindeutig auf die gerade Betrachte-
te verweisen zu können. Die Methodennamen sind zusätzlich angegeben, soweit sie
existieren. Die zweite Spalte gibt jeweils den individuellen Schwerpunkt einer Metho-
de an, und die dritte Spalte enthält die Nummer der in Abschnitt 1.1, Seite 5 aufge-
führten Problemstellungen, die neben dem Process Landscaping auch von der jeweils
diskutierten Methode berücksichtigt werden. Die letzte Spalte enthält zusätzliche Ge-
meinsamkeiten oder Unterschiede, die durch einen ausschließlichen Vergleich entlang
der fünf Problemstellungen nicht deutlich werden.
Die für die angesprochene Betrachtung des Verteilungsaspektes erforderliche explizite
Berücksichtigung von Schnittstellen von Beginn der Modellierung an ist ein Allein-
stellungsmerkmal des Process Landscaping. Dieses unterstützt unter anderem die Er-
stellung der logischen Sicht auf eine Prozesslandschaft, in der direkte Schnittstellen
zu einem Kunden und Schnittstellen von Prozessen entlang des Kundenlebenszyklus
betrachtet werden. Für letzteres ist hervorzuheben, dass die Schnittstellen zwischen
Prozessen hier ohne die Berücksichtigung organisatorischer Strukturen eines Unter-
nehmens betrachtet werden. Diese rein logische Sicht erlaubt somit die Identifikation
von Optimierungspotential, ohne dabei von vorhandenen Organisationsstrukturen ein-
geschränkt zu werden.
Durch die Art der Berücksichtigung des Verteilungsaspektes in einer Softwareprozess-
landschaft werden auch die Kommunikationsinfrastruktur und das Kommunikations-
verhalten in einer solchen Landschaft auf eine Weise betrachtet, wie dies in der Li-
teratur bislang nicht bekannt ist. Dies wird jedoch nicht erst durch den Vergleich mit
SeeMe deutlich, sondern bereits an der Verwendung des Kommunikationsbegriffs, der
sich stark von der üblichen Verwendung im Bereich der Informatik abhebt (vgl. Ab-
schnitt 1.3).
Auch die Forderung nach verschiedenen Blickwinkeln auf eine Prozesslandschaft
ohne den Aufwand einer Neumodellierung oder einer Integration verschiedener
Sichten ist bislang in der Literatur nicht diskutiert worden. Die Notwendigkeit der
Existenz verschiedener Sichten ist zwar allgemein anerkannt, letztere wurden jedoch
– zumindest aufgrund des Kenntnisstandes durch vorangegangene Literaturrecher-
che – bislang immer mit dem erwähnten Zusatzaufwand erstellt. Zwar lässt sich
darüber streiten, wie groß bzw. wie gering der Aufwand einer Umstrukturierung ist,
die bei anderen Ansätzen bestehende Gefahr von Inkonsistenzen ist jedoch beim
Process Landscaping nicht gegeben, da keine der in einer logischen Sicht vorhandenen
53
Die Methode des Process Landscaping
Methoden- Schwerpunkt berücksichtigte Gemeinsamkeiten /
referenz Problemstellung Unterschiede
[AP97] Notation 4. Darstellung unstrukturierter Prozesse
aufgrund der Notation möglich;
keine durchgängige Notation;
keine methodische Vorgehensweise
[IPB01] SPI – gemeinsames Ziel der Prozess-
Accelerator verbesserung
[KBO96] SPI – Modellierung von Prozessen als
gemeinsame Voraussetzung ihrer
Verbesserung
[KJKP99] Werkzeugunterstützung 4. Schnittstellenbetrachtung implizit,
Adonis aber zwischen Informationssystemen
und Kunden
[RHV00] Projektmanagement – ähnliches Vorgehen bei der Prozess-
PTA analyse durch Simulation und Gegen-
überstellung verschiedener Prozess-
alternativen
[HHL98] Kommunikationsaspekte 4., 5. Betrachtung unterschiedlicher
SeeMe Kommunikationsaspekte
[HB96] betriebliche Prozesse – Beschreibung der Vorgehensweise als
17 Methoden gemeinsame Methodenkomponente
Tabelle 2.1: Vergleich des Process Landscaping mit anderen Methoden
54
2.4 Vergleich mit existierenden Modellierungs- und Analyseansätzen
Aktivitäten und Schnittstellen in der lokalen Sicht verloren geht. Sie werden lediglich
umgestellt und bezüglich ihrer geografischen Verteilung detaillierter dargestellt. Eine
formale Basis bietet hierzu definierte Regeln zur Umstrukturierung und ermöglicht
Konsistenzprüfungen (vgl. Abschnitt 3.2.2.1).
Ein weiterer wesentlicher Unterschied zwischen Process Landscaping und anderen
Modellierungsmethoden liegt darin, dass bislang vorrangig Aspekte wie Kontrollfluss,
Datenfluss und Arbeitsverteilung im Hinblick auf den Ablauf von Prozessen abgebildet
wurden. Das Process Landscaping stellt dagegen den bislang in der Literatur vernach-
lässigten Verteilungsaspekt von Prozessen und deren Kommunikation untereinander in
den Vordergrund der Betrachtung, und zwar unabhängig davon, ob dabei ein Ablauf
berücksichtigt wird oder nicht [GW01b, GW01a]. Die bislang gemachte Differenzie-
rung zwischen wiederholbaren, strukturierten Prozessen und den eher unstrukturierten,
kreativen und kooperativen Prozessen [CFJ98] ist mit dem Process Landscaping abge-
schwächt worden, da die Methode die Modellierung beider Prozessformen ermöglicht
und außerdem einen konsistenten Übergang von den Prozessmodellen der unstruktu-
rierten zu denen der strukturierten Prozesse bietet. Dazu wird eine Prozesslandschaft
nach dem Top-Down-Vorgehen erstellt, wobei auch strukturierte Prozesse zunächst re-
lativ abstrakt modelliert werden und diese dann sukzessive verfeinert werden können.
Diese Vorgehensweise wird durch eine formale Notation unterstützt; die Sicherung
des konsistenten Übergangs auf Basis dieser formalen Notation ist in Abschnitt 3.2.1
dargestellt.
In diesem Kapitel sind die Notation und eine Werkzeugunterstützung jedoch noch
nicht diskutiert worden. Die Notwendigkeit der formalen Basis ist in Kapitel 1 bereits
motiviert worden. Sie wird im nachfolgenden Kapitel 3 detailliert diskutiert.
55

Kapitel 3
Formale Basis des Process
Landscaping
Die Möglichkeit der formalen Beschreibung einer verteilten Prozesslandschaft ist für
das Process Landscaping eine unverzichtbare Voraussetzung, insbesondere zur Durch-
führung der in Abschnitt 2.3 diskutierten Analyseschritte der Methode. Erst eine for-
male Notation erlaubt exakte Konsistenzprüfungen einer erstellten Prozesslandschaft
sowie genaue Analysen von Landschaftseigenschaften. Im Rahmen des Process Land-
scaping ergeben sich jedoch noch weitere Anforderungen an eine Beschreibungsspra-
che. Dies sind:
 die Möglichkeit der expliziten Modellierung von Schnittstellen,
 die Unterstützung eines unterschiedlichen Detaillierungsgrades von Land-
schaftselementen,
 das Abstrahieren von Ablaufinformationen für die oberen Ebenen einer Prozess-
landschaft,
 die Berücksichtigung des Verteilungsaspekts innerhalb einer Prozesslandschaft
und
 die Formulierung von Attributen der Landschaftselemente zur Analyse verschie-
dener Landschaftseigenschaften.
Insbesondere die vier zuerst genannten Anforderungen gelten auch für eine grafische
Darstellung einer Prozesslandschaft. Alle möglichen Attribute von Landschaftsele-
menten visualisieren zu wollen, würde jedoch die Komplexität der grafischen Dar-
stellung zu groß werden lassen.
Eine Grundidee des Process Landscaping ist es, die Modellierung einer Prozessland-
schaft von einem Abstraktionsniveau aus zu beginnen, das zunächst von den Ablauf-
informationen von und zwischen Prozessen abstrahiert und sich auf die Identifikation
57
Formale Basis des Process Landscaping
von (Kern-)Aktivitäten und zentralen Informationstypen konzentriert. Eine solche Pro-
zesslandschaft muss später möglichst einfach um Ablaufinformationen und weitere
Informationstypen ergänzt werden können. Gleichzeitig soll eine Übersicht über die
Hierarchiebeziehungen zwischen den verschiedenen Abstraktionsebenen dem Model-
lierer helfen, den Gesamtüberblick über die entstehende Prozesslandschaft zu behalten.
Für die Unterstützung der Process Landscaping Methode ist eine formale Grundlage
erforderlich, die für sehr unterschiedliche Abstraktionsebenen geeignet oder geeignet
erweiterbar ist.
Die Auswahl für eine geeignete Prozessmodellierungssprache zur Beschreibung einer
Prozesslandschaft ist mit den aufgeführten Anforderungen bereits stark eingeschränkt:
Semi-formale Sprachen wie UML [FR99] können zwar für die Erstellung, nicht aber
für die Analyse einer Prozesslandschaft eingesetzt werden. Streng formale Sprachen
wie Z [Spi92] sind dagegen nicht geeignet, Prozesse so abzubilden, dass die resultie-
renden Modelle auch für Prozessbeteiligte ohne genaue Kenntnisse dieser Spezifikati-
onssprache leicht verständlich sind. Sprachen wie JIL [SO97] oder APPL/A [SHO95]
unterstützen keine Visualisierung von Prozessen, sondern setzen ihren Schwerpunkt
auf die Unterstützung der Prozessausführung. Einen Überblick über existierende Pro-
zessmodellierungssprachen geben Zamli und Lee [ZL01].
In diesem Kapitel wird gezeigt, dass Petrinetze [Bau96] für die formulierten Anforde-
rungen zweckmäßig sind. Sie sind ein gut geeignetes Beschreibungsmittel für verteilte
(Software-)Prozesse und vereinen die Vorteile eines grafischen Beschreibungsmittels
und eines mathematisch präzisen und daher analysierbaren Formalismus.
Die Modellierung einer Prozesslandschaft startet zunächst mit einer – im Rahmen die-
ser Dissertation entwickelten – abstrakten Petrinetz-Variante PLL (Process Landsca-
ping Language), mit der die oberen Ebenen einer Prozesslandschaft relativ abstrakt und
ohne Ablaufinformationen, aber bereits mit Hierarchieinformationen und ersten Re-
lationen zwischen verschiedenen Landschaftselementen beschrieben werden können.
Diese abstrahierten Ablaufinformationen können über mehrere Schritte nachträglich
ergänzt werden, wenn beispielsweise das dynamische Verhalten der Prozesslandschaft
analysiert werden soll.
Zur Abgrenzung der einzelnen, aufeinander aufbauenden Erweiterungsschritte unter-
einander werden verschiedene Ausbaustufen einer Prozesslandschaft eingeführt. Die
Basisdefinition einer Prozesslandschaft ermöglicht die Darstellung ihrer oberen Ebe-
nen, die erste Ausbaustufe enthält zusätzliche Informationen beispielsweise über die
lokale Verteilung ihrer Elemente. Die zweite Ausbaustufe ermöglicht die Analyse von
Eigenschaften einer Prozesslandschaft, die ihre Kommunikationsinfrastruktur charak-
terisieren. In der dritten Ausbaustufe einer Prozesslandschaft ist diese um die Möglich-
keit der Modellierung von Ablaufinformationen erweitert, und in der vierten Ausbau-
stufe können Analysen bezüglich des Kommunikationsverhaltens einer Prozessland-
schaft durchgeführt werden.
Die Struktur dieses Kapitels folgt dem Top-Down-Vorgehen der Modellierung einer
Prozesslandschaft mit Process Landscaping. Zunächst werden die zur Modellierung
(Abschnitt 3.1.1) und grafischen Repräsentation (Abschnitt 3.1.2) der oberen Land-
58
3.1 Notation der oberen Ebenen einer Prozesslandschaft
schaftsebenen erforderlichen Strukturen und Konzepte definiert. Diese werden an-
schließend um notwendige Definitionen zur Analyse von Kommunikationseigenschaf-
ten erweitert (Abschnitt 3.1.3). Abschnitt 3.2.1 diskutiert die verschiedenen Schrit-
te zur nachträglichen Ergänzung von Ablaufinformationen in eine Prozesslandschaft.
In Abschnitt 3.2.2 werden die in Abschnitt 3.1.1 eingeführten Strukturen und Kon-
zepte für die Modellierung der unteren Landschaftsebenen erweitert. Sie bilden die
zur Ausführung und damit zur dynamischen Analyse einer Prozesslandschaft notwen-
digen formalen Grundlagen. Die Definitionen werden im gesamten Kapitel – soweit
sinnvoll – von dem in Abschnitt 2.2.1 eingeführten Beispiel durchgängig begleitet, an-
hand dessen der Einsatz und Nutzen der verschiedenen Sprachkonstrukte verdeutlicht
wird. Abschließend wird in Abschnitt 3.3 eine vergleichende Diskussion mit anderen
aus der Literatur bekannten Petrinetz-Ansätzen geführt.
3.1 Notation der oberen Ebenen einer Prozesslandschaft
Im Folgenden wird die Petrinetz-Variante PLL eingeführt, die eine Modellierung von
Prozessen (als komplexe Aktivitäten) und Dokumenten (als zentrale Informationsty-
pen) sowie ihren Beziehungen zueinander erlaubt, jedoch explizit von Ablaufinforma-
tionen abstrahiert. Es wird gezeigt, dass sie die Anforderungen an die Notation von
oberen Ebenen einer Prozesslandschaft erfüllt. Abschnitt 3.1.1 definiert zunächst den
Kern von PLL, mit dem das Konzept der Schnittstellenbetrachtung sowie die Ver-
feinerungsmöglichkeiten von Schnittstellen und Aktivitäten innerhalb einer Prozess-
landschaft unterstützt werden. Die erste Ausbaustufe einer Prozesslandschaft erlaubt
unter anderem die Berücksichtigung von Verteilungsaspekten und unterscheidet ver-
schiedene Dokumenttypen. Verschiedene grafische Repräsentationen einer Prozess-
landschaft werden in Abschnitt 3.1.2 eingeführt. Dabei wird insbesondere auf Un-
terschiede zur grafischen Repräsentation konventioneller Petrinetze eingegangen. In
Abschnitt 3.1.3 wird das der ersten Ausbaustufe einer Prozesslandschaft zugrunde-
liegende Petrinetz um eine Menge von Abbildungen und Begriffen erweitert, die die
Analyse der oberen Landschaftsebenen bezüglich verschiedener Kommunikationsei-
genschaften ermöglicht (zweite Ausbaustufe einer Prozesslandschaft).
3.1.1 Basisdefinition und erste Ausbaustufe einer Prozesslandschaft
Für die Einführung von PLL ist die Kenntnis über einige Relationen und Mengen er-
forderlich, die nachfolgend definiert werden. Mit Hilfe der Menge von Nachfolgern
und der Menge von Vorgängern eines Elementes x aus einer Menge X können Aussa-
gen über die in der Einleitung erwähnten hierarchischen Beziehungen zwischen Akti-
vitäten auf den verschiedenen Ebenen einer Prozesslandschaft formuliert werden.
Definition 3.1.1. Sei R ⊆ X ×X eine binäre Relation über der Menge X.
R({x}) := {y ∈ X | (x, y) ∈ R}
59
Formale Basis des Process Landscaping
ist das Relationenbild der Relation R für x ∈ X. Dabei stellt R(x) eine vereinfachen-
de Schreibweise für R({x}) dar.
Das Relationenbild der Relation R beschreibt also diejenigen Elemente y ∈ X, die
mit x ∈ X in Relation R stehen.
Definition 3.1.2. SeiX eine endliche nichtleere Menge und R eine Menge geordneter
Paare (x, y) mit x, y ∈ X, also R ⊂ X ×X. Dann heißt G = (X,R) ein endlicher
gerichteter Graph. Die Elemente von X heißen Knoten, die Elemente von R heißen
Kanten. Ist (x, y) eine Kante, so heißt x Vorgänger von y, und y heißt Nachfolger
von x. Ein Knoten, der keinen Vorgänger hat, heißt Quelle; ein Knoten, der keinen
Nachfolger hat, heißt Senke oder Blatt.
Definition 3.1.3. Ein gerichteter Graph mit genau einer Quelle und der Eigenschaft,
dass es für jeden Knoten x ∈ X genau einen Weg von der Quelle nach x gibt, heißt
gerichteter Baum.
Definition 3.1.4. Sei G ein gerichteter Baum mit G = (X,R). Die Menge der Nach-
folger succR(x) eines Elements x aus der Menge X ist wie folgt definiert:
succR(x) := R(x)
succR(x) bezeichnet die Menge aller direkten Nachfolger von x.
Bemerkung 3.1.5. succ+R(x) ist die transitive Hülle von succR(x) und bezeichnet die
Menge aller Nachfolger – auch der nicht direkten – von x.
Definition 3.1.6. Sei G ein gerichteter Baum mit G = (X,R). Die Menge der Vor-
gänger predR(x) eines Elements x aus der Menge X ist wie folgt definiert:
predR(x) := {y ∈ X | x ∈ succR(y)}
Die Vorgänger eines Elementes x können also über eine Menge von Nachfolgern de-
finiert werden: Ist das Element x in der Menge der Nachfolger des Elementes y, dann
ist y Vorgänger von x.
Notation 3.1.7. Wenn keine Missverständnisse auftreten können, wird im Folgenden
succR kurz als succ und predR kurz als pred geschrieben. Entsprechend wird succ+R
kurz als succ+ geschrieben. Des Weiteren wird ein gerichteter Baum kurz als Baum
bezeichnet.
Nachfolgend werden ausgezeichnete Mengen innerhalb des Relationenbildes definiert.
Definition 3.1.8. Sei G ein Baum mitG = (X,R). Die Abbildung ref (kurz für refine-
ment) liefert alle Elemente der Menge X, deren Nachfolgermenge nicht leer ist:
ref (R) := {x ∈ X | succ(x) = ∅}
60
3.1 Notation der oberen Ebenen einer Prozesslandschaft
Die Abbildung leaves liefert alle Elemente der Menge X, deren Nachfolgermenge leer
ist, also alle Blätter des Baumes G:
leaves(R) := {x ∈ X | succ(x) = ∅}
Die Abbildung top liefert alle Elemente der Menge X, die direkte Nachfolger der
Quelle r ∈ X des Baumes G sind:
top(R) := succ(r)
Mit dem Baum G = (X,R) ist es möglich, hierarchische Strukturen innerhalb einer
Prozesslandschaft zu beschreiben und über seine grafische Repräsentation einem Mo-
dellierer auf einfache Art und Weise einen Gesamtüberblick über diese Landschaft zu
ermöglichen. Mit den definierten Teilmengen der Menge X können konkrete Abstrak-
tionsebenen einer Prozesslandschaft spezifiziert werden.
Definition 3.1.9. Ein Petrinetz (oder Petrinetzgraph) ist ein Tripel PN = (S,T,F) mit
S ∩ T = ∅
F ⊆ (S × T ) ∪ (T × S)
Die Elemente von S heißen Stellen, die von T heißen Transitionen. Die Elemente
beider Mengen, S∪T , werden auch als Knoten bezeichnet. Die Elemente von F heißen
Kanten.
Bemerkung 3.1.10. Ein Petrinetz ist hier lediglich ein bipartiter Graph, da seine Kno-
tenmengen disjunkt sind und jede Kante einen Knoten aus S mit einem Knoten aus T
verbindet.
Definition 3.1.11. Die Basis einer Prozesslandschaft ist definiert als ein Tupel
ω := (A,S,Z,AB) mit
A = ∅, S = ∅
A ∩ S = ∅
Z ⊆ (A× S) ∪ (S ×A)
Der Graph (A,AB) ist ein Baum mit AB ⊂ A×A.
Das Tripel
(
leaves(AB), S, Z ∩
(
(leaves(AB) × S) ∪ (S × leaves(AB))
)
)
ist ein
Petrinetz.
Notation 3.1.12. Elemente der Menge A heißen Aktivitätsbeschreibungen (kurz: Ak-
tivitäten) und Elemente der Menge S Schnittstellenbeschreibungen (kurz: Schnitt-
stellen). Elemente der Menge Z heißen Zugriffe. (a, s) ∈ Z bedeutet, dass eine Akti-
vität a ∈ A einen erzeugenden oder schreibenden Zugriff auf eine Schnittstelle s ∈ S
61
Formale Basis des Process Landscaping
hat, und (s, a) ∈ Z bedeutet, dass eine Aktivität a ∈ A lesend auf eine Schnittstelle
s ∈ S zugreift. Die Relation AB ist eine ausgezeichnete Menge von Paaren von Aktivi-
täten. Sie ermöglicht eine hierarchische Ordnung der Aktivitäten als Baum. Der Baum
(A,AB), im Folgenden verkürzt als AB bezeichnet, heißt daher Aktivitätenbaum. So
kann über den Aktivitätenbaum zum Ausdruck gebracht werden, dass eine Aktivität aus
mehreren Nachfolgeraktivitäten zusammengesetzt ist.
Notation 3.1.13. Die Menge leaves(AB), deren Elemente als Aktivitäten einer Pro-
zesslandschaft im zugehörigen Petrinetz abgebildet werden, wird nachfolgend verkürzt
als APN bezeichnet.
Analog wird die Menge Z∩
(
(leaves(AB)×S)∪(S× leaves(AB))
)
, deren Elemente
die Zugriffe einer Prozesslandschaft im zugehörigen Petrinetz darstellen, nachfolgend
verkürzt als ZPN bezeichnet.
Wichtig ist festzuhalten, dass eine Prozesslandschaft nur in der Kombination eines Pe-
trinetzes mit einem Aktivitätenbaum vollständig beschrieben werden kann, deren Ak-
tivitäten aus einer gemeinsamen Menge A stammen: Während der Aktivitätenbaum
die hierarchische Struktur einer Prozesslandschaft beschreibt und durch die Relatio-
nen zwischen den verschiedenen Aktivitäten auch die Anzahl der Abstraktionsebe-
nen bestimmt, beschreibt ein Petrinetz die Struktur genau einer Abstraktionsebene, die
– zumeist – ausschließlich die Blätter des Aktivitätenbaumes zusammen ihren Zugrif-
fen auf alle innerhalb der Landschaft existierenden Schnittstellen darstellt.
Die Verfeinerung von Aktivitäten einer Prozesslandschaft ist ein elementarer Model-
lierungsschritt des Process Landscaping. Die zur Darstellung der Prozesslandschaft
verwendete Notation muss daher die Möglichkeit der Verfeinerung entsprechend be-
rücksichtigen. Nachfolgend wird definiert, wie sich die Verfeinerung einer Aktivität
sowohl auf das zugrundeliegende Petrinetz als auch auf den zugehörigen Aktivitäten-
baum auswirkt.
Definition 3.1.14. Sei ω = (A,S,Z,AB) die Basis einer Prozesslandschaft und
a ∈ leaves(AB). Eine Prozesslandschaft
ω′ = (A′, S′, Z ′, AB′) mit A′ = A ∪ {a
1
, ..., an} und
A ∩ {a
1
, ..., an} = ∅, n ≥ 2
heißt Verfeinerung von ω bezüglich der Aktivität a :⇔
1. S′ = S ∪ {s
1
, ..., sm} und S ∩ {s1, ..., sm} = ∅,m ∈ N0, wobei m = 0
bedeutet, dass S′ = S
2. (a) Es existieren Mengen D
1
,D
2
mit
D
1
= {(s, a˜) | a˜ ∈ A\{a}, s ∈ S ∧ (s, a˜) ∈ Z}
D
2
= {(a˜, s) | a˜ ∈ A\{a}, s ∈ S ∧ (a˜, s) ∈ Z}
62
3.1 Notation der oberen Ebenen einer Prozesslandschaft
(b) Seien {s ∈ S | (s, a) ∈ Z} = {sin ,1, ..., sin ,p} für ein p ∈ N0. Dann
existiert für p = 0 eine Menge D
3
mit
D
3
=
⋃
1≤k≤p
Bk wobei
∀ 1 ≤ k ≤ p : Bk ⊆ {(sin ,k, ai) | 1 ≤ i ≤ n} und Bk = ∅
p = 0 bedeutet, dass D
3
= ∅.
(c) Seien {s ∈ S | (a, s) ∈ Z} = {sout ,1, ..., sout ,q} für ein q ∈ N0. Dann
existiert für q = 0 eine Menge D
4
mit
D
4
=
⋃
1≤k≤p
Ck wobei
∀ 1 ≤ k ≤ p : Ck ⊆ {(ai, sout ,k) | 1 ≤ i ≤ n} und Ck = ∅
q = 0 bedeutet, dass D
4
= ∅.
(d) Schließlich existieren Mengen D
5
,D
6
mit
D
5
=
⋃
1≤j≤m
Fj wobei
∀ 1 ≤ j ≤ m : Fj ⊆ {(sj , ai) | 1 ≤ i ≤ n}
D
6
=
⋃
1≤j≤m
Gj wobei
∀ 1 ≤ j ≤ m : Gj ⊆ {(ai, sj) | 1 ≤ i ≤ n}
und ∀ 1 ≤ j ≤ m : Fj ∪Gj = ∅
Es gilt: Z′ =
⋃
1≤l≤6
Dl
3. AB′ = AB ∪ {(a, ai) | 1 ≤ i ≤ n}
Bedingung 1. erlaubt das Hinzufügen weiterer Schnittstellen in die verfeinerte Prozess-
landschaft. Bedingung 2. legt die Menge der Zugriffe Z′ als Vereinigung verschiedener
Teilmengen fest:
 Alle Zugriffe, die bereits in Z existieren, aber nicht mit der Aktivität a verbun-
den waren, bleiben erhalten (D
1
,D
2
).
 Es kommen keine Zugriffe auf die Aktivität amehr in ω′ vor. Diejenigen Zugrif-
fe, die die Schnittstellen sin,k (sout ,k) mit der Aktivität a verbunden haben, wer-
den in ω′ durch solche ersetzt, die die sin,k (sout ,k) mit den verfeinernden Ak-
tivitäten ai verbinden (D3,D4). Sind D3 bzw. D4 nicht leer, wird jede Schnitt-
stelle sin,k bzw. sout ,k mit mindestens einer Aktivität ai verbunden. An dieser
Stelle werden also Elemente z ∈ Z ausgetauscht. Welche der nichtleeren Teil-
mengen Bk und Ck verwendet werden, aus denen sich die Mengen D3 und D4
zusammensetzen, bleibt dem Modellierer überlassen, da dies vom Kontext der
Prozesslandschaft abhängig ist.
63
Formale Basis des Process Landscaping
 Des Weiteren können in der verfeinerten Prozesslandschaft zusätzliche Schnitt-
stellen existieren. In diesem Fall existieren zusätzliche Zugriffe von den verfei-
nernden Aktivitäten ai derart, dass mindestens eine Aktivität ai lesend und eine
Aktivität a′i schreibend auf jede neue Schnittstelle zugreift (D5,D6). Auch hier
ist die konkrete Auswahl der nichtleeren Teilmengen Fj und Gj , aus denen sich
die Mengen D
5
respektive D
6
zusammensetzen, vom Kontext der Prozessland-
schaft abhängig und bleibt daher dem Modellierer überlassen.
Die dritte Bedingung beschreibt die Auswirkungen auf den Aktivitätenbaum der Pro-
zesslandschaft, der durch die Verfeinerung um mindestens zwei weitere Elemente
(a, ai) erweitert worden ist.
Die Einschränkung der Aktivitätsverfeinerung einer Prozesslandschaft auf die Men-
ge der Blätter des zugehörigen Aktivitätenbaumes ist sinnvoll, da sie Überlegungen
der Anbindung von Nachfolgern der ersetzten Aktivität a an die sie verfeinernden
Aktivitäten ai verhindert. Diese könnten ohne Wissen über inhaltliche Details der Pro-
zesslandschaft leicht zu falschen Darstellungen führen. Es ist hervorzuheben, dass die
Verfeinerung einer Prozesslandschaft bezüglich einer Aktivität für den Aktivitäten-
baum eine echte Erweiterung bedeutet, da die verfeinerte Aktivität a in der Menge A
erhalten bleibt.
Für das zugrundeliegende Petrinetz bedeutet diese Verfeinerung dagegen die Erset-
zung von a durch ein neues Teilnetz, da hierfür lediglich die Menge {a
1
, ..., an} ⊆
leaves(AB′) verwendet wird. Bezogen auf die grafische Darstellung des verfeiner-
ten Petrinetzes ist die Aktivität a der Prozesslandschaft ω durch Elemente der Mengen
A′PN = leaves(AB
′
), S′ und Z′PN = Z ′∩
(
(leaves(AB′)×S′)∪(S′×leaves(AB′))
)
ersetzt worden. Die Aktivität a wird dabei durch mindestens zwei andere Aktivitäten
verfeinert, da n ≥ 2. Dies ist sinnvoll, da bei einer Verfeinerung durch nur eine ein-
zige Aktivität diese lediglich die Rolle der verfeinerten Aktivität übernehmen würde
und der Informationsgehalt der Prozesslandschaft sich nicht geändert hätte.
Bemerkung 3.1.15. Die hierarchischen Beziehungen zwischen Aktivitäten einer Pro-
zesslandschaft ω können mit Hilfe der in Definition 3.1.8 formulierten Teilmengen wie
folgt ausgedrückt werden:
• Die Menge ref (AB) besteht aus allen inneren Knoten des Aktivitätenbaumes
AB und damit allen verfeinerten Aktivitäten.
• Die Menge leaves(AB) besteht aus allen Blättern des Aktivitätenbaumes AB
und damit aus allen nicht weiter verfeinerten Aktivitäten der Prozesslandschaft
ω.
• Die Menge top(AB) besteht aus allen Aktivitäten der obersten Abstraktions-
ebene der Prozesslandschaft ω unterhalb der Quelle r.
• Die Quelle r des Aktivitätenbaumes AB ist ein Element der Menge A, das ober-
halb der obersten Abstraktionsebene der Prozesslandschaft ω angeordnet ist.
64
3.1 Notation der oberen Ebenen einer Prozesslandschaft
Notation 3.1.16. Wenn keine Missverständnisse auftreten können, werden im Folgen-
den die Mengen ref (AB), leaves(AB) und top(AB) kurz als Mengen ref , leaves und
top bezeichnet.
Neben der Verfeinerung gibt es noch eine zweite Möglichkeit – die Erweiterung –
zur Ergänzung einer Prozesslandschaft um weitere Informationen. Während bei der
Verfeinerung bezüglich einer Aktivität a ∈ A diese im zugrundeliegenden Petrinetz
durch ein Teilnetz ersetzt und im zugehörigen Aktivitätenbaum eine Hierarchiestufe
eingefügt wird, wird bei der Erweiterung das Petrinetz durch Hinzufügen von Kanten
und Knoten (als Elemente der Menge (A∪S)× (S ∪A)) vergrößert. Alle Knoten des
erweiterten Netzes bleiben erhalten.
Bezogen auf den Aktivitätenbaum einer Prozesslandschaft bewirkt eine Erweiterung
die Vergrößerung der Nachfolgermenge für eine Aktivität a ∈ A. Dazu werden die
hinzugefügten Aktivitäten eindeutig konkreten Elementen des Aktivitätenbaumes zu-
geordnet. Bildlich gesprochen wird jede „Aktivitätswaise“ von genau einer verfeiner-
ten Aktivität „adoptiert“.
Definition 3.1.17. Sei ω = (A,S,Z,AB) die Basis einer Prozesslandschaft und
Aadd ⊂ A die Menge derjenigen Aktivitäten, die im Zuge einer Erweiterung der Pro-
zesslandschaft hinzugefügt wurden. Die Menge aller Aktivitäten a ∈ A, deren Nach-
folger Blätter sind, lässt sich formulieren als
pred leaves := {a ∈ A | succ(a) ∈ leaves}
Die Abbildung adopt ordnet jeder Aktivität a ∈ Aadd eine übergeordnete Aktivität
a ∈ pred leaves zu:
adopt : Aadd → pred leaves
Über die Abbildung adopt wird der Aktivitätenbaum erweitert, indem die Anzahl der
Blätter vergrößert wird. Die Tiefe der hierarchischen Struktur der korrespondierenden
Prozesslandschaft wird hierbei nicht verändert.
Die Umkehrrelation von adopt ist definiert als
adopt−1 := {(a
1
, a
2
) | a
2
∈ Aadd ∧ a1 = adopt(a2)}
Für sie gilt offensichtlich: adopt−1 ⊂ AB, da AB der Aktivitätenbaum der erweiter-
ten Prozesslandschaft ist.
Die „Adoption“ erscheint auf den ersten Blick trivial. Sie ist jedoch für eine korrekte
und vollständige Abbildung des Aktivitätenbaumes erforderlich, da es zwar für einen
Modellierer aufgrund des Kontexts einer Prozesslandschaft deutlich wird, wo hinzu-
gefügte Aktivitäten im korrespondierenden Aktivitätenbaum einzuordnen sind, diese
Eindeutigkeit für die formale Basis jedoch nicht gegeben ist.
Schnittstellen spielen beim Process Landscaping ebenfalls eine zentrale Rolle. Eine
Notation, die die Methode geeignet unterstützen soll, muss daher die Möglichkeit bie-
ten, Schnittstellen als Elemente einer Prozesslandschaft sowohl auf oberster Abstrak-
tionsebene als auch verfeinert auf unteren Ebenen darzustellen. Dies ist insbesonde-
re für diejenigen Schnittstellen interessant, für die mindestens zwei verschiedenartige
65
Formale Basis des Process Landscaping
Zugriffe von Aktivitäten existieren, d.h. für die eine Aktivität lesend und die andere
schreibend auf die Schnittstelle zugreift.
Definition 3.1.18. Sei ω = (A,S,Z,AB) die Basis einer Prozesslandschaft, P(S)
die Potenzmenge von S und a
1
, a
2
∈ A, a
1
= a
2
. Durch die Abbildung interface
wird die Menge aller Schnittstellen zwischen zwei Aktivitäten a
1
und a
2
definiert:
interface : A×A→ P(S) mit
interface
(
(a
1
, a
2
)
)
:={s∈ S|
(
(a
1
, s)∈ Z∧(s, a
2
)∈ Z
)
∨
(
(a
2
, s)∈ Z∧(s, a
1
)∈ Z
)
}
Bemerkung 3.1.19. Um zu verdeutlichen, dass die Abbildung interface auf Tupeln
von Aktivitäten operiert, werden diese mit einem zusätzlichen Klammernpaar um-
schlossen.
Beispiel:
Das in Abbildung 3.1 dargestellte Beispiel verdeutlicht grafisch, wann Schnittstellen
Elemente einer Menge interface
(
(ai, aj)
)
mit i, j ∈ N, i = j sind.
Clientkomponente
Grobentwurf 1 Feinentwurf
Serverkomponente
Grobentwurf2
Auftrag Komponentenentwicklung
Softwarearchitektur Clientkomponente1
2
a1 a2
a3
s1
s2
Abbildung 3.1: Schnittstellen zwischen Aktivitäten
Es gilt: interface
(
(a
1
, a
2
)
)
= {s
1
},
interface
(
(a
1
, a
3
)
)
= ∅ und
interface
(
(a
2
, a
3
)
)
= ∅.
In Abbildung 3.1 ist die Schnittstelle s
1
Element von interface
(
(a
1
, a
2
)
)
; s
2
gehört
keiner der drei möglichen Mengen von Schnittstellen zwischen den abgebildeten Ak-
tivitäten an.
Die nachfolgende Definition legt fest, wie sich die Verfeinerung einer Schnittstelle
innerhalb einer Prozesslandschaft ω auf das zugrundeliegende Petrinetz auswirkt.
66
3.1 Notation der oberen Ebenen einer Prozesslandschaft
Definition 3.1.20. Sei ω = (A,S,Z,AB) die Basis einer Prozesslandschaft und
s ∈ S. Eine Prozesslandschaft
ω′ = (A′, S′, Z ′, AB′) mit S′ =
(
S \ {s}
)
∪ {s
1
, ..., sn} und
S ∩ {s
1
, ..., sn} = ∅, n ≥ 2
heißt Verfeinerung einer Prozesslandschaft ω bezüglich der Schnittstelle s :⇔
1. A′ = A
2. (a) Es existieren Mengen E
1
, E
2
mit
E
1
= {(a, s˜) | s˜ ∈ S\s, a ∈ A, (a, s˜) ∈ Z}
E
2
= {(s˜, a) | s˜ ∈ S\s, a ∈ A, (s˜, a) ∈ Z}
(b) Des Weiteren existieren Mengen E
3
, E
4
mit
E
3
= {(a, si) | 1 ≤ i ≤ n, a ∈ A, (a, s) ∈ Z}
E
4
= {(si, a) | 1 ≤ i ≤ n, a ∈ A, (s, a) ∈ Z}
Es gilt: Z′ =
⋃
1≤l≤4
El
3. AB′ = AB
In der Verfeinerung ω′ ist die Schnittstelle s der Prozesslandschaft ω durch mindes-
tens zwei Elemente der Menge S′ ersetzt worden, die nicht in der Menge S liegen.
Dies sichert die Steigerung des Informationsgehalts einer Prozesslandschaft, die durch
die Verfeinerung beabsichtigt ist. Die erste Bedingung fordert, dass bei einer Verfeine-
rung einer Prozesslandschaft bezüglich einer Schnittstelle die Menge der Aktivitäten
unverändert bleibt. Bedingung 2. legt die Menge der Zugriffe Z′ als Vereinigung ver-
schiedener Teilmengen fest:
 Analog zur Verfeinerung einer Prozesslandschaft bezüglich einer Aktivität gilt
auch hier, dass alle Zugriffe, die bereits in Z existieren, aber nicht mit der
Schnittstelle s verbunden waren, erhalten bleiben (E
1
, E
2
).
 Es kommen keine Zugriffe auf die Schnittstelle s mehr in ω′ vor; stattdessen
existieren Zugriffe auf alle verfeinernden Schnittstellen si, die diese in ω′ mit
denjenigen Aktivitäten verbinden, die in ω mit der jetzt verfeinerten Schnittstel-
le s verbunden waren (E
3
, E
4
). An dieser Stelle werden also wieder Elemente
z ∈ Z ausgetauscht.
Auf den Aktivitätenbaum einer Prozesslandschaft hat die Verfeinerung einer Schnitt-
stelle keinerlei Auswirkungen, da dieser lediglich die Hierarchieinformationen für die
Aktivitäten beinhaltet, dabei aber keine Zugriffe auf Schnittstellen berücksichtigt (Be-
dingung 3.).
67
Formale Basis des Process Landscaping
Das der verfeinerten Basis einer Prozesslandschaft zugrundeliegende Petrinetz setzt
sich hier aus den Mengen A′PN = APN , S′ und Z′PN = Z ′ ∩
(
(leaves(AB)× S′) ∪
(S′ × leaves(AB))
)
zusammen.
Bezogen auf das der Basis einer Prozesslandschaft zugrundeliegende Petrinetz ist ein
wichtiger Unterschied zwischen der Verfeinerung bezüglich einer Aktivität a und be-
züglich einer Schnittstelle s festzuhalten: Während bei der Verfeinerung einer Pro-
zesslandschaft ω bezüglich einer Schnittstelle diese in der Menge S′ nicht mehr ent-
halten ist, wird bei einer Verfeinerung bezüglich einer Aktivität diese lediglich im zu-
gehörigen Petrinetz der verfeinerten Prozesslandschaft ω′ nicht mehr dargestellt. Die
Aktivität a bleibt jedoch Element der Aktivitätenmenge und findet sich weiterhin im
Aktivitätenbaum (vgl. Definition 3.1.14).
Mit den Definitionen 3.1.14 und 3.1.20 ist die Möglichkeit der Verfeinerung einer
Prozesslandschaft bezüglich beider Grundmengen eines Petrinetzes (Aktivitäten und
Schnittstellen) gegeben. Bei ihrer Durchführung muss jedoch zwingend eine sequenti-
elle Reihenfolge eingehalten werden. Für einen Modellierer bedeutet dies, dass immer
nur die zuletzt verfeinerte Prozesslandschaft weiter verfeinert werden darf. Die paralle-
le Durchführung mehrerer Verfeinerungsschritte birgt die Gefahr von Inkonsistenzen,
die nicht oder nur mit großem Aufwand korrigiert werden können. Die Ursache für
die entstehenden Inkonsistenzen liegt in den modellierten Zugriffen zwischen parallel
verfeinerten Aktivitäten und Schnittstellen, die in Abhängigkeit jedes einzelnen Ver-
feinerungsschrittes individuell anzupassen sind.
Die Forderung nach streng sequentieller Vorgehensweise bei Verfeinerungen unter-
scheidet das Process Landscaping von der traditionellen Art der Verfeinerung von Pe-
trinetzen. Dort wird im Rahmen einer Verfeinerung eine Transition durch ein transi-
tionsberandetes Teilnetz ersetzt bzw. eine Stelle durch ein stellenberandetes Teilnetz
[Bau96], ohne eine mögliche parallele Vorgehensweise auszuschließen. Aus diesem
Grund spricht man im Rahmen des Process Landscaping auch von der Verfeinerung
einer Prozesslandschaft bezüglich einer Aktivität oder einer Schnittstelle anstatt von
der Verfeinerung einer Aktivität oder Schnittstelle. Die Ursache für diesen Unterschied
liegt vor allem darin, dass die Verfeinerung eines Petrinetzes, das einer Prozessland-
schaft zugrundeliegt, immer auch Auswirkungen auf die Randstellen des zu ersetzen-
den Petrinetzelementes hat. Insbesondere müssen hier immer die Zugriffe, die mit dem
ersetzten Petrinetzelement verbunden sind, angepasst werden und bestimmten Regeln
genügen (vgl. Bedingungen 2. in den Definitionen 3.1.14 und 3.1.20).
Bezüglich der Schnittstellenverfeinerung ist hier noch ein weiterer wichtiger Unter-
schied festzuhalten: Beim Process Landscaping wird eine Schnittstelle nicht durch
ein Teil- bzw. Subnetz ersetzt, sondern lediglich durch eine Menge von detaillierten
Schnittstellen inklusive der Zugriffe ihrer Aktivitäten im Vor- und Nachbereich der
verfeinerten Schnittstelle.
Bemerkung 3.1.21. Wird eine Schnittstelle s ∈ S verfeinert, die Element einer
Menge interface
(
(a
1
, a
2
)
)
ist, spricht man auch von der Verfeinerung dieser Men-
ge interface
(
(a
1
, a
2
)
)
.
68
3.1 Notation der oberen Ebenen einer Prozesslandschaft
Notation 3.1.22. Sei ω = (A,S,Z,AB) die Basis einer Prozesslandschaft. Eine Men-
ge interface
(
(a
1
, a
2
)
)
von Schnittstellen zwischen zwei Aktivitäten, von denen min-
destens eine eine verfeinerte Aktivität ist (d.h. a
1
∈ ref oder a
2
∈ ref ), wird als impli-
zit bezeichnet. Ein Element einer solchen impliziten Schnittstellenmenge wird entspre-
chend implizite Schnittstelle genannt. Eine Menge von Schnittstellen zwischen zwei
Blättern eines Aktivitätenbaumes wird als explizit bezeichnet; ihre Elemente werden
entsprechend als explizite Schnittstellen bezeichnet.
Clientkomponente
Grobentwurf
Serverkomponente
Grobentwurf
Feinentwurf
Entscheidung
neu oder anpassen
1
2
Komponentenentwicklung
        1  Softwarearchitektur Clientkomponente
2  Auftrag Komponentenentwicklung
a4
a1 a2
a3
a5
Abbildung 3.2: Implizite und explizite Mengen von Schnittstellen zwischen
Aktivitäten
Abbildung 3.2 verdeutlicht den Unterschied zwischen impliziten und expliziten Men-
gen von Schnittstellen. Die Menge interface
(
(Entscheidung neu oder anpassen, Kom-
ponentenentwicklung)
)
mit der Schnittstelle Auftrag Komponentenentwicklung als
Element ist implizit, da letztere Aktivität verfeinert ist. In Abbildung 3.2 ist
dies durch die eingerahmten Aktivitäten dargestellt, die (neben weiteren) in-
nerhalb der Aktivität Komponentenentwicklung stattfinden. Die Schnittstelle
Auftrag Komponentenentwicklung ist gleichzeitig Element der expliziten Mengen
interface
(
(Entscheidung neu oder anpassen,Clientkomponente Grobentwurf )) und
interface
(
(Entscheidung neu oder anpassen, Serverkomponente Grobentwurf )). In
Abbildung 3.2 ist dies durch die gestrichelten Pfeile angedeutet, die die Schnittstelle
Auftrag Komponentenentwicklung mit den innerhalb der Aktivität Komponenten-
entwicklung dargestellten verfeinernden Aktivitäten verbindet. Es sei jedoch darauf
hingewiesen, dass in einem Petrinetz, welches einer Prozesslandschaft ω zugrunde-
liegt, nur explizite Mengen von Schnittstellen vorkommen, da dort nur Aktivitäten
der Menge leaves auf die Schnittstellen zugreifen. Tabelle 3.1 fasst die Situation
zusammen.
Bei Schnittstellen wird ebenfalls bewusst zwischen den Begriffen der Verfeinerung und
der Erweiterung innerhalb einer Prozesslandschaft unterschieden (vgl. Verfeinerung
und Erweiterung von Aktivitäten): Verfeinerung bedeutet die Ersetzung einer Schnitt-
stelle durch mindestens zwei weitere. Dagegen wird bei einer Erweiterung mindestens
69
Formale Basis des Process Landscaping
ein zusätzlicher Zugriff einer Aktivität auf eine Schnittstelle derart festgelegt, dass
diese die Restriktionen für Elemente einer Menge interface
(
(a
1
, a
2
)
)
aus Definition
3.1.18 erfüllt.
Interface Landschaftselement Schnittstelle
interface
(
(a
1
, a
2
)
)
explizite Schnittstelle zwischen a
1
, a
2
{s
1
}
interface
(
(a
1
, a
3
)
)
explizite Schnittstelle zwischen a
1
, a
3
∅
interface
(
(a
4
, a
1
)
)
implizite Schnittstelle zwischen a
4
, a
1
{s
2
}
interface
(
(a
4
, a
2
)
)
explizite Schnittstelle zwischen a
4
, a
2
∅
interface
(
(a
4
, a
3
)
)
explizite Schnittstelle zwischen a
4
, a
3
{s
2
}
Tabelle 3.1: Zusammenfassung der in Abbildung 3.2 dargestellten Situation
Abbildung 3.3 verdeutlicht den Unterschied zwischen der Verfeinerung und
der Erweiterung am Beispiel der beiden bereits in Abbildung 3.1 einge-
führten Schnittstellen. Die mit gestrichelten Kreisen dargestellten Schnitt-
stellen stellen eine Verfeinerung der ursprünglichen Schnittstelle Software-
architektur Clientkomponente und damit eine Verfeinerung der Menge
interface
(
(Clientkomponente Grobentwurf ,Feinentwurf )) dar (vgl. Abbildung 3.1,
Seite 66). Die Schnittstelle Komponentenintegrationsplan ist dagegen eine Erwei-
terung der Menge interface
(
(Clientkomponente Grobentwurf ,Feinentwurf )) und
die Schnittstelle Auftrag Komponentenentwicklung eine Erweiterung der Menge
interface
(
(Clientkomponente Grobentwurf , Serverkomponente Grobentwurf )).
3
2
1.1
1.2
1.3
        1.1   Grafische Beschreibung der  Softwarearchitektur Clientkomponente
        1.2   Verbale Beschreibung der Softwarearchitektur Clientkomponente, deutsch
        1.3   Verbale Beschreibung der Softwarearchitektur Clientkomponente, englisch
2      Auftrag Komponentenentwicklung
3      Komponentenintegrationsplan
Clientkomponente
Grobentwurf
Serverkomponente
Grobentwurf
Feinentwurf
Abbildung 3.3: Verfeinerung und Erweiterung von Schnittstellen
Bemerkung 3.1.23. Für alle nachfolgend betrachteten Prozesslandschaften wird vor-
ausgesetzt, dass sie durch Verfeinerungen gemäß Definition 3.1.14 und Definition
3.1.20 und/oder Erweiterungen gemäß Definition 3.1.17 aus einer „Initialbasis“
ωo = ({a}, ∅, ∅, ∅) hervorgegangen sind.
70
3.1 Notation der oberen Ebenen einer Prozesslandschaft
Die Voraussetzung ist wichtig, um für jede Prozesslandschaft eindeutig auf ihr Aus-
gangsmodell schließen zu können. Dieser Rückschluss wird in Abschnitt 3.2.1.4 noch
detaillierter diskutiert (vgl. Definition 3.2.40).
Die bislang formulierten Definitionen sind ausreichend für die Modellierung von obe-
ren Ebenen einer Prozesslandschaft und berücksichtigen gleichzeitig die für das Pro-
cess Landscaping erforderlichen Konzepte zur Darstellung von Schnittstellen und Ver-
feinerungen. Lediglich die Einschränkung der auf den oberen Ebenen zu betrachten-
den Informationen auf diejenigen, die zumeist als – unterscheidbare – Dokumentty-
pen produziert bzw. verarbeitet werden, ist bislang nicht explizit formuliert worden.
Für diesen Zweck kann eine Prozesslandschaft leicht um eine Menge DT von Doku-
menttypen und eine Abbildung erweitert werden, die jeder Schnittstelle genau einen
Dokumenttyp zuordnet.
Für die Diskussion einer konkreten Prozesslandschaft mit beteiligten Personen (Mit-
arbeiter, Projektleiter, etc.) ist es sinnvoll, die Aktivitäten, Schnittstellen und Doku-
menttypen mit sprechenden Namen zu versehen. Dies kann über eine Menge NAME
von Namen und einer Abbildung erfolgen, die jeder Aktivität, jeder Schnittstelle und
jedem Dokumenttyp einen Namen zuordnet.
Schließlich kann auch die Anforderung des Process Landscaping nach der Berücksich-
tigung der geografischen Verteilung der Aktivitäten einer Prozesslandschaft realisiert
werden über eine Menge O von Orten und einer Abbildung, die jeder Aktivität min-
destens einen Ort zuordnet.
Die gerade angesprochenen Erweiterungen der Basis einer Prozesslandschaft führen
zur ersten Ausbaustufe der Definition 3.1.11 (vgl. Seite 61):
Definition 3.1.24. Sei ω = (A,S,Z,AB) die Basis einer Prozesslandschaft, DT eine
Menge von Dokumenttypen mit DT = ∅, NAME die Menge aller Zeichenfolgen und
P(O) die Potenzmenge der Menge aller Orte mit O = ∅. Sei weiterhin
• type eine Abbildung, die jeder Schnittstelle s ∈ S genau einen Dokumenttypen
dt ∈ DT zuweist:
type : S → DT
• name eine Abbildung, die allen Aktivitäten, Schnittstellen und Dokumenttypen
der Prozesslandschaft PLtop einen Namen n ∈ NAME zuordnet:
name : A ∪ S ∪DT → NAME
• local eine Abbildung, die jeder Aktivität a ∈ A eine mindestens einelementige
Menge von Orten o ∈ O zuordnet:
local : A→ P(O)\{∅}
Damit lässt sich die erste Ausbaustufe einer Prozesslandschaft definieren als ein Tu-
pel
PLtop := (ω,DT,NAME , O, type ,name , local )
71
Formale Basis des Process Landscaping
Notation 3.1.25. Wenn keine Missverständnisse auftreten können, wird eine Prozess-
landschaft PLtop = (ω,DT,NAME , O, type ,name , local ) im Folgenden verkürzt
als PLtop = (A,S,Z,AB) bezeichnet.
Bemerkung 3.1.26. Der Index top der Prozesslandschaft PLtop deutet an, dass es
sich um eine Prozesslandschaft handelt, deren obere Ebenen in der Petrinetz-Variante
PPL (vgl. Einleitung zu Abschnitt 3.1, Seite 59) notiert sind.
Mit der Abbildung type kann für jede Schnittstelle der ersten Ausbaustufe einer Pro-
zesslandschaft festgelegt werden, ob diese zum Beispiel Informationsobjekte vom Typ
Anforderungsdokument, Entwurfsdokument, etc. enthält. Dies ist beispielsweise bei
einer komponentenbasierten Softwareentwicklung sinnvoll, wenn verschiedene Kom-
ponenten von unterschiedlichen Entwicklergruppen realisiert werden und demzufolge
für jede Komponente die obigen Dokumenttypen erstellt werden müssen. Die entste-
henden Dokumente haben in diesem Fall jeweils den gleichen Typ, beziehen sich aber
auf unterschiedliche Komponenten eines zu erstellenden Gesamtsystems.
Konsistenzbedingung 3.1.27. Für eine eindeutige Identifizierung von Schnittstellen
und Aktivitäten innerhalb von PLtop müssen diese einen eindeutigen Namen haben.
Daher muss die Abbildung name injektiv sein.
Mit der Abbildung local ist es möglich, den Verteilungsaspekt einer Prozesslandschaft
zu berücksichtigen. Die Zuordnung mehrerer Orte zu einer Aktivität ist beispielsweise
immer dann notwendig, wenn diese Aktivität als eine logische Einheit modelliert wur-
de, aber innerhalb eines realen Prozesses an verschiedenen Orten durchgeführt wird.
Ein typisches Beispiel innerhalb der komponentenbasierten Softwareentwicklung ist
die Aktivität Component Engineering, die mehrfach und meist an unterschiedlichen
Orten innerhalb eines Projektes durchgeführt wird. Die Berücksichtigung der Anzahl
der einer Aktivität zugeordneten Orte unterstützt unter anderem eine Analyse der Kom-
munikationsstruktur innerhalb einer Prozesslandschaft (vgl. Abschnitt 3.1.3).
Definition 3.1.28. Sei PLtop = (A,S,Z,AB) die erste Ausbaustufe einer Prozess-
landschaft. Bei einem Informationsaustausch zwischen Aktivitäten a
1
, a
2
∈ A, die an
unterschiedlichen Orten stattfinden, lässt sich eine Abbildung definieren, die für die
beteiligte Schnittstelle s′ ∈ S eine für sie gültige Ortemenge locals(s′) zuordnet:
Sei s′ ∈ interface
(
(a
1
, a
2
)
)
. Es gilt:
local s : S → P(O)\{∅} mit local s(s′) := local (a1) ∪ local (a2)
Schnittstellen werden damit immer allen Orten zugeordnet, an denen auf sie zugrei-
fende Aktivitäten durchgeführt werden.
Mit der ersten Ausbaustufe einer Prozesslandschaft können ihre oberen Ebenen un-
ter Berücksichtigung aller hierfür diskutierten Anforderungen formuliert werden. Ihre
grafische Repräsentation wird im nachfolgenden Abschnitt diskutiert. Dabei wird ins-
besondere auf Unterschiede zur grafischen Repräsentation konventioneller Petrinetze
eingegangen.
72
3.1 Notation der oberen Ebenen einer Prozesslandschaft
3.1.2 Grafische Repräsentation einer Prozesslandschaft
Die Abbildungen 3.1 bis 3.3 auf den Seiten 66, 69 und 70 stellen Ausschnitte ei-
ner Prozesslandschaft zur komponentenbasierten Softwareentwicklung in Form von
PLL-Petrinetzen dar. In Abbildung 3.2 ist dabei zusätzlich die Hierarchie zwischen
Aktivitäten angedeutet. Für die grafische Repräsentation einer Prozesslandschaft in
PLL-Notation sind neben diesen weitere Darstellungsformen entwickelt worden, die
die Konzentration auf einzelne Aspekte der Landschaft auf unterschiedlichen Abstrak-
tionsebenen unterstützen, indem sie auf unterschiedliche Art und Weise von Elemen-
ten der Prozesslandschaft abstrahieren. Diese Abstraktionen haben den Vorteil, dass
man je nach Zielgruppe und Einsatzziel der grafischen Repräsentationen diese indivi-
duell unterstützen kann. Zielgruppe kann dabei das Management eines Unternehmens
oder eine Gruppe der in den Softwareprozess involvierten Mitarbeiter sein, die auf je-
weils unterschiedlichen Abstraktionsebenen über die dargestellten Prozesse diskutie-
ren wollen. Als mögliche Einsatzziele sind die Dokumentation, aber auch die Analyse
verschiedener Eigenschaften der modellierten Prozesse denkbar (vgl. Kapitel 2).
Dieser Abschnitt erläutert die grafischen Repräsentationsformen einer in PLL notier-
ten Prozesslandschaft. Sie abstrahieren von der konventionellen Repräsentation eines
Petrinetzes durch Stellen, Transitionen und Kanten. Die Anwendung der für eine Pro-
zesslandschaft PLtop definierten Abbildung name erleichtert die Diskussion über den
Inhalt der verschiedenen Repräsentationen. Die Anwendung der Abbildungen type
und local wird dagegen in den grafischen Darstellungen zunächst nicht weiter berück-
sichtigt, um diese nicht mit Informationen zu überladen.
Abbildung 3.4 zeigt die hierarchische Ordnung von Aktivitäten als Aktivitätenbaum
am Beispiel einer Prozesslandschaft zur komponentenbasierten Softwareentwicklung.
Wichtige inhaltliche Merkmale der abgebildeten Prozesslandschaft sind beispielsweise
die Aktivitäten Component Engineering und Domain Engineering, die sich auf glei-
cher Abstraktionsebene befinden. Einige der Aktivitäten sind stärker verfeinert, bei
anderen ist aus Gründen der Übersichtlichkeit von Details abstrahiert worden. Letz-
tere sind in Abbildung 3.4 mit einem Sternchen gekennzeichnet. Die Aktivität Kom-
ponentenentwicklung innerhalb des Component Engineering ist zum Beispiel durch
sieben weitere Aktivitäten verfeinert, die Aktivität Konfigurationsmanagement (CE)
durch drei weitere. Die Abkürzung (AE) zeigt an, dass die damit versehenen Aktivi-
täten dem Application Engineering zugeordnet sind. Gleichnamige Aktivitäten – bis
auf das Kürzel – existieren auch innerhalb des Component Engineering. Dort sind sie
entsprechend mit dem Kürzel (CE) versehen worden.
In dieser Darstellungsform werden weder Schnittstellen und noch Zugriffe betrachtet.
Sie sind ausgeblendet, um sich auf die Hierarchieinformationen konzentrieren zu kön-
nen, die in der grafischen Repräsentation eines Petrinetzes nicht erkennbar sind. Ein
Aktivitätenbaum repräsentiert damit immer nur einen Teil einer Prozesslandschaft. Er
lässt sich nicht als Petrinetz darstellen. Der in Abbildung 3.4 gezeigte Ausschnitt der
Prozesslandschaft entspricht den in Definition 3.1.11 eingeführten Mengen A (exklu-
sive der über das Sternsymbol abstrahierten Aktivitäten) und AB aus PLtop mit
73
Formale Basis des Process Landscaping
Komponentenbasierte Softwareentwicklung
Application Engineering
Component Engineering
Qualitätsmanagement
Projektmanagement
Wiederverwendungsrepository verwalten
Projekt einschätzen
Geschäftsprozess modellieren
Domain Engineering
Konfigurationsmanagement (AE)
Anforderungsanalyse erstellen
Feedback an DE geben
Versionsmanagement (AE)
Release erstellen (AE)
Releaseplanung (AE)
Spezifikation erstellen
System installieren
System integrieren
Systemarchitektur erstellen
Zur Abnahme freigeben
Zusammenstellung der Komponentenmenge
Anfrage an DE
Entscheidung "neu" oder "anpassen"
Komponentenanpassung
Komponentenentwicklung
"Buy or Build"-Entscheidung treffen
Abnahme mit dem Kunden
CE mit Komponentenentwicklung beauftragen
Kommunikation mit dem Kunden
Markt analysieren
Projekt initialisieren
Projektabschluss
Projektdarstellung nach außen
Projektplanerstellung
Projektsteuerung und -kontrolle
Ressourcenplanung
Risikomanagement
Teamzusammenstellung
Management
Review
Test
Konfigurationsmanagement (CE)
Komponente kaufen
Fehlerkorrektur
*
*
*
*
*
*
* : verfeinerte Aktivität;
     die sie verfeinernden
     Aktivitäten sind hier
     nicht abgebildet
Abbildung 3.4: Aktivitätenbaum einer Prozesslandschaft zur komponentenbasierten
Softwareentwicklung
74
3.1 Notation der oberen Ebenen einer Prozesslandschaft
A =
{Komponentenbasierte Softwareentwicklung, Application Engineering, Anforderungs-
analyse erstellen, Feedback an DE geben, Konfigurationsmanagement (AE), Relea-
seplanung (AE), Release erstellen (AE), Versionsmanagement (AE), Spezifikation er-
stellen, System installieren, System integrieren, Systemarchitektur erstellen, Zur Ab-
nahme freigeben, Zusammenstellung der Komponentenmenge, Component Enginee-
ring, Anfrage an DE, Entscheidung „neu“ oder „anpassen“, Komponentenanpassung,
Komponentenentwicklung, Konfigurationsmanagement (CE), Fehlerkorrektur, Domain
Engineering, Geschäftsprozess modellieren, Projekt einschätzen, Wiederverwendungs-
repository verwalten, Projektmanagement, „Buy or Build“-Entscheidung treffen, Ab-
nahme mit dem Kunden, CE mit Komponentenentwicklung beauftragen, Komponen-
te kaufen, Kommunikation mit dem Kunden, Markt analysieren, Projekt initialisieren,
Projektabschluss, Projektdarstellung nach außen, Projektplanerstellung, Projektsteue-
rung und -kontrolle, Ressourcenplanung, Risikomanagement, Teamzusammenstellung,
Qualitätsmanagement, Management, Review, Test}
AB =
{ (Komponentenbasierte Softwareentwicklung, Application Engineering), (Komponen-
tenbasierte Softwareentwicklung, Component Engineering), (Komponentenbasierte
Softwareentwicklung, Domain Engineering), (Komponentenbasierte Softwareentwick-
lung, Projektmanagement), (Komponentenbasierte Softwareentwicklung, Qualitätsma-
nagement),
(Application Engineering, Anforderungsanalyse erstellen), (Application Engineering,
Feedback an DE geben), (Application Engineering, Konfigurationsmanagement (AE)),
(Application Engineering, Releaseplanung (AE)), (Application Engineering, Release
erstellen (AE)), (Application Engineering, Versionsmanagement (AE)), (Konfigurati-
onsmanagement (AE), Releaseplanung (AE)), (Konfigurationsmanagement (AE), Re-
lease erstellen (AE)), (Konfigurationsmanagement (AE), Versionsmanagement (AE)),
(Application Engineering, Spezifikation erstellen), (Application Engineering, System
installieren), (Application Engineering, System integrieren), (Application Enginee-
ring, Systemarchitektur erstellen), (Application Engineering, Zur Abnahme freigeben),
(Application Engineering, Zusammenstellung der Komponentenmenge),
(Component Engineering, Anfrage an DE), (Component Engineering, Entscheidung
„neu“ oder „anpassen“), (Component Engineering, Komponentenanpassung), (Com-
ponent Engineering, Komponentenentwicklung), (Component Engineering, Konfigura-
tionsmanagement (CE)), (Component Engineering, Fehlerkorrektur),
(Domain Engineering, Geschäftsprozess modellieren), (Domain Engineering, Projekt
einschätzen), (Domain Engineering, Wiederverwendungsrepository verwalten),
(Projektmanagement, „Buy or Build“-Entscheidung treffen), (Projektmanagement,
Abnahme mit dem Kunden), (Projektmanagement, CE mit Komponentenentwicklung
beauftragen), (Projektmanagement, Komponente kaufen), (Projektmanagement, Kom-
munikation mit dem Kunden), (Projektmanagement, Markt analysieren), (Projektma-
nagement, Projekt initialisieren), (Projektmanagement, Projektabschluss), (Projekt-
management, Projektdarstellung nach außen), (Projektmanagement, Projektplaner-
75
Formale Basis des Process Landscaping
stellung), (Projektmanagement, Projektsteuerung und -kontrolle), (Projektmanage-
ment, Ressourcenplanung), (Projektmanagement, Risikomanagement), (Projektmana-
gement, Teamzusammenstellung),
(Qualitätsmanagement, Management), (Qualitätsmanagement, Review), (Qualitäts-
management, Test) }.
Die in die textuelle Beschreibung der MengeAB eingefügten Absätze entsprechen den
Aktivitäten der obersten Landschaftsebene und sollen die Vergleichbarkeit mit Abbil-
dung 3.4 erleichtern. Insgesamt beinhaltet die in Abbildung 3.4 dargestellte Prozess-
landschaft zur komponentenbasierten Softwareentwicklung 65 Aktivitäten (inklusive
der dort lediglich mit einem Sternchen angedeuteten), davon 53 nicht weiter verfeiner-
te.
Die Aktivität Application Engineering ist in Abbildung 3.5 verfeinert dargestellt. Dass
diese Abbildung tatsächlich einer bzw. genau der gerade erwähnten Verfeinerung ent-
spricht, lässt sich jedoch nur mit Hilfe des Aktivitätenbaumes (vgl. Abbildung 3.4)
erkennen, der belegt, dass alle verfeinernden Aktivitäten im Aktivitätenbaum AB die
Aktivität Application Engineering als gemeinsamen direkten Vorgänger haben. Ab-
bildung 3.5 zeigt zusätzlich die Existenz von Schnittstellen zwischen Aktivitäten, an-
gedeutet durch bidirektionale Pfeile. Diese Form der grafischen Repräsentation einer
Prozesslandschaft entspricht ebenfalls nicht der Darstellung durch ein konventionelles
Petrinetz, da die Schnittstellen nicht explizit dargestellt sind und somit eine Grund-
menge eines Petrinetzes nicht berücksichtigt ist.
System integrieren
Anforderungsanalyse
erstellen
Konfigurations-
management
Zusammenstellung der
Komponentenmenge
Systemarchitektur
erstellen
Spezifikation erstellen
Feedback an DE
geben
Zur Abnahme
freigeben
System installieren
Abbildung 3.5: Verfeinerung der Aktivität Application Engineering mit angedeuteten
Schnittstellen
76
3.1 Notation der oberen Ebenen einer Prozesslandschaft
Anhand des in Abbildung 3.5 dargestellten Ausschnitts der Beispielprozessland-
schaft kann ebenfalls keine vollständige Beschreibung aller Mengen des Tupels
(A,S,Z,AB) angegeben werden. Es kann lediglich eine Teilmenge A′ ⊂ A ange-
geben werden. Die bidirektionalen Pfeile lassen erkennen, dass S und Z nichtleere
Mengen sind, ihre konkreten Elemente sind im dargestellten Ausschnitt nicht aufge-
führt. Über den Aktivitätenbaum AB kann ebenfalls keine Aussage getroffen werden.
Sollen Details über die im realen Prozess auszutauschenden Informationsobjekte dar-
gestellt werden, können die bidirektionalen Pfeile durch die Angabe konkreter Schnitt-
stellen verfeinert werden. In diesem Fall wird eine Darstellungsform verwendet, die
in Abbildung 3.6 am Beispiel der Verfeinerung der Aktivität Zusammenstellung der
Komponentenmenge verdeutlicht wird. Dass es sich auch bei diesem Ausschnitt der
Prozesslandschaft um eine Verfeinerung einer Aktivität a ∈ A handelt, ist ebenfalls
nur mit Hilfe des Aktivitätenbaumes AB aus Abbildung 3.4 erkennbar.
vorhandene Komponenten
auswählen28 11
9
6
technische Komponenten-
anforderungen erstellen
5
4
Komponente hinzufügen Komponente anfordern
7 8
3
getestete Komponente
gekaufte Komponente
Komponentenanforderung
Anforderungsdokument
projektbezogene Komponentenmenge
3
4
5
6
7
technische Komponentenanforderung
Systemarchitektur
Review technische Komponentenanforderung
8
9
11
Feedback von Repository28
29
Anfrage an Repository29
Abbildung 3.6: Verfeinerung der Aktivität Zusammenstellung der Komponentenmenge
In Abbildung 3.6 sind vier Aktivitäten und zehn Schnittstellen dargestellt. Letztere
werden meist ähnlich wie ihre Dokumenttypen benannt. Beispielsweise wird die tech-
nische Komponentenanforderung – als Anforderungsdokument typisiert (was jedoch
in der Abbildung nicht ersichtlich ist) – von der sie erstellenden Aktivität zur Ak-
tivität Komponente anfordern weitergeleitet. Für den in Abbildung 3.6 dargestellten
Ausschnitt der Beispielprozesslandschaft können zu folgenden Mengen Aussagen be-
züglich ihrer Elemente gemacht werden:
77
Formale Basis des Process Landscaping
 A ⊃ A′′ und A′′ =
{ Komponente hinzufügen, Komponente anfordern, vorhandene Komponenten
auswählen, technische Komponentenanforderungen erstellen}
 S ⊃ S′′ und S′′ =
{ Anforderungsdokument, getestete Komponente, gekaufte Komponente, Kom-
ponentenanforderung, projektbezogene Komponentenmenge, technische Kom-
ponentenanforderung, Review technische Komponentenanforderung, Systemar-
chitektur, Feedback von Repository, Anfrage an Repository}
 Z ⊃ Z ′′ und Z′′ =
{ (getestete Komponente, Komponente hinzufügen), (gekaufte Komponente,
Komponente hinzufügen), (Komponente hinzufügen, projektbezogene Kompo-
nentenmenge), (Feedback von Repository, vorhandene Komponenten auswäh-
len), (vorhandene Komponenten auswählen, projektbezogene Komponenten-
menge), (vorhandene Komponenten auswählen, Anfrage an Repository), (Sys-
temarchitektur, vorhandene Komponenten auswählen), (Anforderungsdokument,
vorhandene Komponenten auswählen), (Anforderungsdokument, technische
Komponentenanforderungen erstellen), (Systemarchitektur, technische Kompo-
nentenanforderungen erstellen), (Review technische Komponentenanforderung,
technische Komponentenanforderungen erstellen), (technische Komponentenan-
forderung, technische Komponentenanforderungen erstellen), (technische Kom-
ponentenanforderungen erstellen, technische Komponentenanforderung), (tech-
nische Komponentenanforderung, Komponente anfordern), (Komponente anfor-
dern, Komponentenanforderung)}
Der Unterschied zur konventionellen Darstellung eines Petrinetzes liegt in Abbil-
dung 3.6 in der Andeutung von Datenflüssen zu weiteren Aktivitäten, die außerhalb
der abgebildeten Verfeinerung liegen. Alle in der Abbildung fett dargestellten Schnitt-
stellen der Prozesslandschaft repräsentieren Schnittstellen auch zu Aktivitäten, die
nicht zur Verfeinerung der Aktivität Zusammenstellung der Komponentenmenge ge-
hören und daher auf der abgebildeten Abstraktionsebene nicht sichtbar sind. Auf die
Schnittstelle Systemarchitektur wird zum Beispiel von der Aktivität Systemarchitektur
erstellen lesend und schreibend zugegriffen. Diese Aktivität befindet sich jedoch in
einem anderen Teilbaum des zugehörigen Aktivitätenbaumes (vgl. Abbildung 3.4).
Neben den eher aktivitätsbezogenen Darstellungsformen existiert die Dokumenten-
sicht als eine weitere Darstellungsform. Sie unterstützt einen schnellen Überblick auf
die Zugriffsart (lesend oder schreibend) und die Anzahl der Zugriffe auf konkrete
Schnittstellen. Abbildung 3.7 zeigt die Dokumentensicht auf die Schnittstelle System-
architektur. Dabei wird sowohl von der Einordnung der zugreifenden Aktivitäten in die
hierarchische Struktur als auch von der Reihenfolge ihrer Zugriffe abstrahiert. Trotz-
dem kommt diese Darstellungsform der konventionellen Repräsentation eines Petri-
netzes am nächsten, da sowohl Schnittstellen und Aktivitäten als auch Zugriffe und
damit Datenflüsse eindeutig identifiziert werden können. Lediglich der Kontrollfluss
ist nicht erkennbar.
78
3.1 Notation der oberen Ebenen einer Prozesslandschaft
Feedback an DE geben
Reviewdurchführung 11
Systemarchitektur
erstellen
technische Komponenten-
anforderungen erstellen
vorhandene Komponenten
auswählen
Versionsmanagement (AE)
Systemarchitektur11
Wiederverwendungs-
repository verwalten
Abbildung 3.7: Dokumentensicht auf die Schnittstelle Systemarchitektur
Die in Abbildung 3.7 dargestellten Elemente stellen einen weiteren Ausschnitt der
Beispielprozesslandschaft dar. Auch hier können die Elemente von Teilmengen der
Mengen A, S und Z konkret aufgeführt werden:
 A ⊃ A′′′ und A′′′ =
{Systemarchitektur erstellen, Reviewdurchführung, Feedback an DE geben, Ver-
sionsmanagement (AE), vorhandene Komponenten auswählen, technische Kom-
ponentenanforderungen erstellen, Wiederverwendungsrepository verwalten}
 S ⊃ S′′′ und S′′′ =
{Systemarchitektur}
 Z ⊂ Z ′′′ und Z′′′ =
{(Systemarchitektur erstellen, Systemarchitektur), (Systemarchitektur, Systemar-
chitektur erstellen), (Systemarchitektur, Reviewdurchführung), (Systemarchitek-
tur, Feedback an DE geben), (Systemarchitektur, Versionsmanagement (AE)),
(Systemarchitektur, vorhandene Komponenten auswählen), (Systemarchitektur,
technische Komponentenanforderungen erstellen), (Systemarchitektur, Wieder-
verwendungsrepository verwalten)}
Zusammenfassend kann zwischen vier verschiedenen Darstellungsformen einer Pro-
zesslandschaft (bzw. Ausschnitten davon) in PLL-Notation unterschieden werden:
 dem Aktivitätenbaum,
 zwei Arten der Darstellung von Aktivitätsverfeinerungen (mit und ohne Berück-
sichtigung von Schnittstellen) und
 der Dokumentensicht.
Die erste Darstellungsform konzentriert sich – als einzige – auf die hierarchische
Struktur der Aktivitäten einer Prozesslandschaft, die nächsten beiden auf die Relatio-
nen zwischen Aktivitäten, die jeweils auf gleicher Abstraktionsebene angeordnet sind,
79
Formale Basis des Process Landscaping
und die letzte stellt die Zugriffe auf eine konkrete Schnittstelle dar. Ein weiterer wich-
tiger Punkt ist die Tatsache, dass die grafische zweidimensionale Darstellung einer
Prozesslandschaft durch ein Petrinetz niemals alle Elemente der Aktivitätenmenge A
darstellt, sondern immer nur eine Teilmenge der Elemente des zugehörigen Aktivitä-
tenbaumes AB, konkret die Blätter leaves(AB) (vgl. Definition 3.1.11, Seite 61). Eine
vollständige Darstellung einer Prozesslandschaft lässt sich also nur mit der Kombina-
tion Petrinetz/Aktivitätenbaum erreichen.
Die verschiedenen Darstellungsformen werden unter anderem in Abschnitt 3.1.3 ver-
wendet, in dem die Definitionen für die Analyse konkreter Kommunikationseigen-
schaften mit Beispielen unterlegt sind.
3.1.3 Erweiterungen zur Analyse statischer Kommunikationseigen-
schaften
In diesem Abschnitt wird die in Abschnitt 3.1.1 eingeführte Petrinetz-Variante PLL,
die die Modellierung der oberen Ebenen einer Prozesslandschaft gemäß der Process
Landscaping Methode unterstützt, um Möglichkeiten der Analyse dieser oberen Ebe-
nen erweitert. Der Fokus liegt dabei auf Analysemöglichkeiten von Kommunikati-
onseigenschaften einer verteilten Prozesslandschaft und damit auf der modellierten
Semantik der Prozesse und ihrer Kommunikation untereinander. In PLL wird die
Formulierung dieser Kommunikationseigenschaften über die Definition entsprechen-
der Funktionen realisiert, wobei die Funktionswerte konkrete Ausprägungen von Ei-
genschaften der Landschaftselemente repräsentieren. Die zusätzliche Auszeichnung
spezifischer Teilnetze als Elemente einer Kommunikationsinfrastruktur unterstützt die
Analyse der Kommunikation in einer verteilten Prozesslandschaft ebenfalls.
Bemerkung 3.1.29. Alle Eigenschaften, die nachfolgend für Petrinetze definiert wer-
den, gelten gleichzeitig auch für Prozesslandschaften, die durch ein entsprechendes
Petrinetz repräsentiert werden. Beispielsweise heißt eine Prozesslandschaft – unab-
hängig von ihrer Ausbaustufe – kohärent, wenn sie durch ein kohärentes Petrinetz re-
präsentiert wird.
Für die Analyse verschiedener Abstraktionsebenen einer in PLL modellierten Pro-
zesslandschaft ist es sinnvoll, zwischen Zugriffen von verfeinerten Aktivitäten auf
Schnittstellen und denen von nicht weiter verfeinerten Aktivitäten auf Schnittstellen
zu unterscheiden. Diese Unterscheidung erleichtert es dem Analysten, die für seine
Analyse relevante Teilmenge an Zugriffen gezielter zu betrachten. Soll beispielswei-
se die Kommunikationsstruktur der unteren Abstraktionsebene einer in PLL model-
lierten Prozesslandschaft untersucht werden, reicht die Berücksichtigung derjenigen
Zugriffe aus, die von nicht weiter verfeinerten Aktivitäten ausgehen. Soll dagegen die
Kommunikationsstruktur einer gesamten Prozesslandschaft untersucht werden, ergibt
sich diese aus der Menge der kleinteiligen Kommunikationsstrukturen auf den unteren
Ebenen.
80
3.1 Notation der oberen Ebenen einer Prozesslandschaft
Definition 3.1.30. Sei PLtop = (A,S,Z,AB) die erste Ausbaustufe einer Prozess-
landschaft. Ein Zugriff von einer Aktivität a ∈ A auf eine Schnittstelle s ∈ S heißt
explizit genau dann, wenn die Aktivität a nicht verfeinert ist und auf die Schnittstelle s
lesend oder schreibend zugreift, also wenn
(a, s) ∈ Z ∨ (s, a) ∈ Z mit a ∈ leaves .
Die Menge
explicit := {(a, s) ∈ Z | a ∈ leaves} ∪ {(s, a) ∈ Z | a ∈ leaves}
enthält alle expliziten Zugriffe einer Prozesslandschaft.
Die Menge explicit umfasst damit die Menge aller Zugriffe zwischen Schnittstellen
und Blättern des Aktivitätenbaumes AB.
Definition 3.1.31. Sei PLtop = (A,S,Z,AB) die erste Ausbaustufe einer Prozess-
landschaft. Ein Zugriff von einer Aktivität a ∈ A auf eine Schnittstelle s ∈ S heißt
implizit genau dann, wenn es einen Nachfolger b ∈ succ(a) der Aktivität a gibt, der
auf die Schnittstelle s lesend oder schreibend zugreift.
Die Menge
implicit :={(a, s) ∈ Z | ∃ b ∈ succ(a) : (b, s) ∈ Z}∪
{(s, a) ∈ Z | ∃ b ∈ succ(a) : (s, b) ∈ Z}
enthält alle impliziten Zugriffe einer Prozesslandschaft.
Die Menge implicit umfasst damit die Menge aller Zugriffe von verfeinerten Aktivi-
täten auf Schnittstellen.
In Abbildung 3.2 auf Seite 69 stellt beispielsweise der lesende Zugriff der Aktivi-
tät Komponentenentwicklung auf die Schnittstelle Auftrag Komponentenentwicklung
einen impliziten Zugriff dar, während der lesende Zugriff der Aktivität Serverkompo-
nente Grobentwurf auf diese Schnittstelle ein expliziter Zugriff ist.
Zur Unterstützung eines Modellierers bzw. eines Modellierungsteams, welches ge-
meinsam eine komplexe Prozesslandschaft erstellt, wird der Begriff der Vollständig-
keit eingeführt. Dieser hilft, offensichtliche Modellierungslücken in einer Prozessland-
schaft aufzudecken, die spätere Analyseergebnisse verfälschen können.
Definition 3.1.32. Sei PLtop = (A,S,Z,AB) die erste Ausbaustufe einer Prozess-
landschaft.
PLtop heißt vollständig:⇔
1. ∀ a ∈ leaves ∃ s ∈ S : (a, s) ∈ Z ∨ (s, a) ∈ Z
2. ∀ s ∈ S ∃ a ∈ A : (a, s) ∈ Z ∨ (s, a) ∈ Z
3. ∀ a ∈ A : |succ(a)| = 1
81
Formale Basis des Process Landscaping
Die Forderung nach der Vollständigkeit einer Prozesslandschaft PLtop verhindert
durch die ersten beiden Bedingungen die Modellierung von isolierten Aktivitäten und
Schnittstellen. Die dritte Bedingung fordert die Verfeinerung von Aktivitäten durch
mindestens zwei weitere. Dies ist sinnvoll, da bei einer Verfeinerung durch nur eine
einzige Aktivität diese lediglich die Rolle der verfeinerten Aktivität übernehmen wür-
de und der Informationsgehalt der Prozesslandschaft sich damit nicht geändert hätte.
Eine solche Situation kann den Modellierer auf die Unvollständigkeit seiner Arbeit
hinweisen.
Im Rahmen der Erweiterungen von PLL, die speziell für die Analyse statischer Kom-
munikationseigenschaften erforderlich sind, werden nachfolgend Attribute inklusive
ihrer Wertemenge für Zugriffe z ∈ Z definiert. Konkret sind dies die Attribute Per-
sistenz, Synchronität, Veränderbarkeit, Privatheit, Verschlüsselung und Mehrfachver-
sand. Mit ihrer Hilfe werden Eigenschaften einer Prozesslandschaft formuliert, die
sich aus der syntaktischen Struktur des zugrundeliegenden Petrinetzes nicht ableiten
lassen.
Definition 3.1.33. Sei PLtop = (A,S,Z,AB) die erste Ausbaustufe einer Prozess-
landschaft und PLtop vollständig. Die Menge der möglichen Attributwerte von Zugrif-
fen z ∈ Z ist definiert als
switch := {1, 0, undefined}
Notation 3.1.34. Die Elemente der Menge switch heißen Schalterwerte.
Die Elemente eines Zugriffs z = (a, s) ∈ Z ∨ z = (s, a) ∈ Z können durch Ab-
bildungen mit verschiedenen Attributen versehen werden, die jeweils Attributwerte
der Menge switch annehmen. Zu Beginn der Modellierung einer Prozesslandschaft
sind die konkreten Schalterwerte oft noch nicht bekannt, daher ist der Standardwert
undefined . Er ermöglicht ein späteres und sukzessives Setzen aller Schalterwerte auf
0 oder 1. Ihre Bedeutung hängt von den jeweiligen Abbildungen ab und wird jeweils
am Beispiel erläutert.
Definition 3.1.35. Sei PLtop = (A,S,Z,AB) die erste Ausbaustufe einer Prozess-
landschaft und PLtop vollständig. Die Abbildungen per, synch, change, coded,
priv und mult legen für alle Zugriffe z ∈ Z einer Prozesslandschaft deren Ausprä-
gungen bezüglich Persistenz, Synchronität, Veränderbarkeit, Verschlüsselung, Privat-
heit und Mehrfachversand eines Informationsaustausches fest:
Persistenz: per : Z → switch
Synchronität: synch : Z → switch
Veränderbarkeit: change : Z → switch
Verschlüsselung: coded : Z → switch
Privatheit: priv : Z → switch
Mehrfachversand: mult : Z → switch
82
3.1 Notation der oberen Ebenen einer Prozesslandschaft
Beispiel:
Wird der Softwarecode verschiedener Komponenten sowohl bei der erzeugenden Ak-
tivität und der sie verwendenden Aktivität als auch in einem Wiederverwendungsre-
pository lokal gespeichert, so gilt für alle korrespondierenden Zugriffe z ∈ Z , dass
per (z) = 1. Für diese sollte in Betracht gezogen werden, eine gemeinsame Datenba-
sis zu schaffen, um Mehrfacharchivierung und somit mögliche Inkonsistenzen durch
Redundanzen zu vermeiden. Um solche Inkonsistenzen zu verhindern, müssten an-
dernfalls alle archivierenden Aktivitäten über Änderungen an Dokumenten informiert
werden. Ein durchdachter Aktualisierungsmechanismus würde notwendig werden.
Die Erwartung einer synchronen bzw. asynchronen Kommunikation hat Auswirkun-
gen auf die dafür notwendige Infrastruktur: Briefpost kann ausschließlich als asyn-
chrone Kommunikation modelliert werden (synch(z) = 0), während Telefonate oder
(Video-) Konferenzen immer als synchron zu modellieren sind (synch(z) = 1). Wird
eine Kommunikation als synchron eingestuft, erfolgt keine temporäre Zwischenspei-
cherung der auszutauschenden Daten in Wartebuffern, jedoch müssen sich beide Akti-
vitäten zeitlich aufeinander abstimmen.
Der Inhalt einer Datei im pdf-Format ist als nicht veränderbar (change(z) = 0) ein-
zustufen. Eine MS-Word-Datei kann dagegen von jedem Empfänger verändert werden
(change(z) = 1), sofern er ein entsprechendes Textverarbeitungssystem zur Verfü-
gung hat. Signierte Dokumente sollten als nicht veränderbar attributiert werden. Ver-
änderbarkeit ist immer dann zu verhindern, wenn Urheberrechte gewahrt werden sol-
len.
Verschlüsselung von Kommunikation ist seit jeher ein grundlegendes Problem. Zum
einen ist bei einer Kommunikation häufig sicherzustellen, dass sie nicht von Dritten
abgehört wird (coded (z) = 1). Zum anderen verlangsamt die Verschlüsselung die
Kommunikationsgeschwindigkeit und stellt teilweise hohe Ansprüche an die verwen-
dete Technik. Hier ist immer ein vertretbarer Mittelweg zu finden.
Beispiele für private Kommunikation sind Briefpost, E-Mail oder Telefon
(priv (z) = 1). Beispiele für öffentliche Kommunikation (priv (z) = 0) sind Aushän-
ge, Internet-Newsgroups oder Werbeanzeigen.
Mehrfachversand (mult(z) = 1) gibt es sowohl bei der herkömmlichen Kommunika-
tion (Serienbriefe oder Anzeigen in Zeitungen/Aushängen) als auch bei der elektroni-
schen Kommunikation (E-Mail-Verteiler, Internet-Newsgroups oder Webseiten).
Notation 3.1.36. Alle durch die Abbildungen per , synch, coded , change , priv und
mult repräsentierten Attribute einer Prozesslandschaft heißen Kommunikationsattri-
bute.
Nach der Definition der Kommunikationsattribute wird im Folgenden festgelegt, wie
sie in einer Art Baukastensystem zusammengesetzt werden können, um die Kommu-
nikationsstruktur einer Prozesslandschaft analysieren zu können. Diese kann mit Hilfe
von Kommunikationskanälen beschrieben werden, die jeweils zwei Aktivitäten a
1
und
a
2
und den Elementen der zugehörigen Mengen interface
(
(a
1
, a
2
)
)
zugeordnet sind
und als besondere Teilnetze innerhalb des zugrundeliegenden Petrinetzes ausgezeich-
83
Formale Basis des Process Landscaping
net werden. Kommunikationskanäle oder kurz Kanäle beschreiben durch die Ausprä-
gung der zugehörigen Kommunikationsattribute die Eigenschaften der Kommunika-
tion zwischen zwei Aktivitäten. Dabei erfüllt eine auf eine Schnittstelle schreibend
zugreifende Aktivität a
1
die Rolle eines Senders und eine lesend zugreifende Aktivi-
tät a
2
die Rolle eines Empfängers.
Definition 3.1.37. Sei PLtop = (A,S,Z,AB) die erste Ausbaustufe einer Prozess-
landschaft und PLtop vollständig. Sei weiterhin CC = ∅ eine Menge, deren Elemente
Kommunikationskanäle repräsentieren und ZZ ⊂ Z × Z , wobei für alle a
1
, a
2
∈ A
mit a
1
= a
2
, s ∈ S und (z
1
, z
2
) ∈ ZZ gilt:
1. z
1
= (a
1
, s) ⇒ z
2
= (s, a
2
)
2. z
1
= (s, a
1
) ⇒ z
2
= (a
2
, s)
Die Abbildung channel ordnet jedem Tupel (z
1
, z
2
) ∈ ZZ genau einen Kommunika-
tionskanal zu:
channel : ZZ → CC
Damit stellen z
1
und z
2
Zugriffe zur gleichen Schnittstelle s dar, wobei einer der
beiden als Schreibzugriff definiert ist, der jeweils andere als Lesezugriff. Diese
Restriktionen für die Urbildmenge der Abbildung channel sind notwendige Voraus-
setzung für einen funktionsfähigen Informationsaustausch.
Beispiel:
Abbildung 3.8 zeigt beispielhaft verschiedene Kommunikationskanäle innerhalb ei-
ner Softwareprozesslandschaft. Die Abkürzung (AE) zeigt an, dass die beiden damit
versehenen Aktivitäten verfeinernde Aktivitäten des Application Engineering sind.
Die Abbildung enthält insgesamt sieben Zugriffe, wobei (z
1
, z
3
), (z
1
, z
4
), (z
1
, z
5
),
(z
1
, z
6
) und (z
1
, z
7
) fünf mögliche Kommunikationskanäle darstellen. Ein Modellierer
kann die Auswahl der Kanäle aber auf (z
1
, z
3
), (z
1
, z
4
) und (z
1
, z
6
) beschränken, wenn
beispielsweise die Aktivitäten Releaseplanung (AE) und Versionsmanagement (AE)
das Anforderungsdokument (über die gleichnamige Schnittstelle) nicht direkt von der
Aktivität Anforderungsanalyse erstellen erhalten.
Die in Abbildung 3.8 verwendete Dokumentensicht ist auch für die Identifikation von
Kommunikationskanälen zwischen verschiedenen Orten hilfreich. Abbildung 3.9 zeigt
dies an einem Beispiel, in dem das Qualitätsmanagement Richtlinien – u.a. zur Pro-
grammierung – an das Component Engineering schickt.
In dieser verteilten Prozesslandschaft zur komponentenbasierten Softwareentwicklung
existieren zwei Standorte, die die Aktivitäten des Qualitätsmanagements enthalten,
sowie insgesamt fünf Standorte, an denen Komponenten entwickelt werden. Es gilt:
local (Qualitätsmanagement) = {o
1
, o
2
}
local (Component Engineering) = {o
1
, o
2
, o
3
, o
4
, o
5
}
84
3.1 Notation der oberen Ebenen einer Prozesslandschaft
Reviewdurchführung
Spezifikation erstellen
3Anforderungsanalyse
erstellen Releaseplanung (AE)
Anforderungsdokument3
technische Komponenten-
anforderungen erstellen
Versionsmanagement (AE)
a1
a3
a2
a4
a5
a6
z2
z1
z3
z7
z6
z5
z4
s1
Abbildung 3.8: Kommunikationskanäle in einer Prozesslandschaft
Component
Engineering
Component
Engineering
25
Qualitätsmanagement
Component
Engineering
Component
Engineering
Component
Engineering
Qualitätsmanagement
25  Richtlinien
Qualitätsmanagement ComponentEngineering25
 o1
 o2
 o1
 o2
 o3
 o4
 o5
o1 o2 o1 o2 o3 o4 o5
Abbildung 3.9: Kommunikationskanäle in einer verteilten Prozesslandschaft
85
Formale Basis des Process Landscaping
Damit werden an den Orten o
1
und o
2
jeweils Aktivitäten des Qualitätsmanagements
und des Component Engineering durchgeführt. An den Orten o
3
bis o
5
finden sich
dagegen ausschließlich Aktivitäten des Component Engineering. Wird nun die Doku-
mentensicht auf das Richtliniendokument derart erweitert, dass jede Aktivität in der
Häufigkeit ihres Vorkommens abgebildet wird und auf die Richtlinien zugreift, resul-
tiert daraus der untere Teil der Abbildung 3.9. Hier kann ein Modellierer beispielsweise
festlegen, dass das Qualitätsmanagement am Ort o
1
ausschließlich mit dem Compo-
nent Engineering am selben Ort kommuniziert, während das Qualitätsmanagement am
Ort o
2
sich um alle weiteren Komponentenentwicklungsstandorte kümmert. Aus der
Menge aller theoretisch möglichen Kommunikationskanäle werden so nur diejenigen
ausgewählt, die tatsächlich vorkommen.
Definition 3.1.38. Sei PLtop = (A,S,Z,AB) die erste Ausbaustufe einer Prozess-
landschaft, PLtop vollständig, CC = ∅ eine Menge von Kommunikationskanälen und
K := switch6
das sechsfache kartesische Produkt der Menge switch , wobei jedes k ∈ K ein geord-
netes Tupel ist. Mit der Abbildung valueZ wird jedem Zugriff z ∈ Z eine konkrete
Ausprägungskombination der Kommunikationsattribute zugeordnet:
valueZ : Z → K mitvalueZ(z) = (k1, ..., k6)
Die Abbildung gibt mit
k
1
die Ausprägung der Persistenz,
k
2
die Ausprägung der Synchronität,
k
3
die Ausprägung der Veränderbarkeit,
k
4
die Ausprägung der Kodierung,
k
5
die Ausprägung der Privatheit und
k
6
die Ausprägung des Mehrfachversands an.
Bemerkung 3.1.39. Für einen funktionsfähigen Kommunikationskanal müssen bis auf
die Persistenz die Attributwerte derjenigen Kommunikationsattribute zusammenpas-
sen, die den beteiligten Zugriffen zugeordnet sind. Dies ist immer dann der Fall, wenn
die Attributwerte eines Kommunikationskanals jeweils pro Attribut identisch sind. Die
Persistenz wird für die Funktionsfähigkeit eines Kommunikationskanals nicht betrach-
tet.
Die bislang in diesem Abschnitt definierten Abbildungen zur Unterstützung der stati-
schen Analyse einer Prozesslandschaft führen zu ihrer nächsthöheren Ausbaustufe:
Definition 3.1.40. Sei PLtop = (A,S,Z,AB) die erste Ausbaustufe einer Prozess-
landschaft, PLtop vollständig,
• switch die Menge aller möglichen Attributwerte von Zugriffen,
86
3.1 Notation der oberen Ebenen einer Prozesslandschaft
• ZZ ⊂ Z × Z ,
• CC = ∅ eine Menge von funktionsfähigen Kommunikationskanälen,
• K das sechsfache kartesische Produkt der Menge switch wie in Definition
3.1.38 festgelegt,
• per , synch, change , coded , priv und mult die in Definition 3.1.35 eingeführten
Abbildungen zur Festlegung der Kommunikationsattribute,
• channel eine Abbildung zur Festlegung von Kommunikationskanälen gemäß
Definition 3.1.37 und schließlich
• valueZ die Abbildung aus der vorangegangenen Definition 3.1.38.
Damit lässt sich die zweite Ausbaustufe einer Prozesslandschaft definieren als ein
Tupel
PLtop−com :=
(PLtop, switch , ZZ,CC,K, per , synch, change , coded , priv ,mult , channel , valueZ)
Notation 3.1.41. Wenn keine Missverständnisse auftreten können, wird eine Prozess-
landschaft PLtop−com = (PLtop, switch , ZZ , CC , K, per , synch , change , coded ,
priv , mult , channel , valueZ) im Folgenden verkürzt als PLtop−com = (A,S,Z,AB)
bezeichnet.
Im Folgenden werden grundsätzlich funktionsfähige Kommunikationskanäle betrach-
tet. Dazu wird zunächst die Abbildung valueZ erweitert als Abbildung von der Menge
der Kommunikationskanäle auf das kartesische Produkt K . Dies erleichtert eine Zu-
weisung von konkreten Attributausprägungen an die beteiligten Zugriffe, da so statt
zwölf nur noch sechs Werte pro Kommunikationskanal zuzuweisen sind.
Definition 3.1.42. Sei PLtop−com = (A,S,Z,AB) die zweite Ausbaustufe einer Pro-
zesslandschaft und CC = ∅ die zugehörige Menge funktionsfähiger Kommunikations-
kanäle. Sei weiterhin K das sechsfache kartesische Produkt der Menge switch wie in
Definition 3.1.38 festgelegt. Mit der Abbildung valueCC wird jedem Kommunikations-
kanal cc ∈ CC mit cc = (z
1
, z
2
), z
1
, z
2
∈ Z eine konkrete Ausprägungskombination
der Kommunikationsattribute zugeordnet:
valueCC : CC → K mit
valueCC(z1, z2) := valueZ(z1)
Für funktionsfähige Kommunikationskanäle wird nachfolgend eine Begriffssamm-
lung zur Analyse von Komplexität und Dichte der Kommunikationsinfrastruktur einer
Prozesslandschaft definiert. Die Dichte einer Kommunikationsinfrastruktur ist abhän-
gig von der Anzahl vorhandener Kommunikationskanäle innerhalb einer betrachteten
Prozesslandschaft bzw. innerhalb einer betrachteten Teilmenge. Die Komplexität der
Kommunikationsinfrastruktur einer Prozesslandschaft wird beeinflusst von den Attri-
buten
87
Formale Basis des Process Landscaping
 Persistenz (Aufwand für Datenhaltung),
 Synchronität (technisch unterschiedliche Kommunikationsvoraussetzungen),
 Veränderbarkeit (Verfügbarkeit von z.B. Signaturmechanismen),
 Verschlüsselung (Verfügbarkeit von Kodierungs- und Sicherheitsmechanismen),
 Privatheit (Aufwand für Zugriffs- und Schlüsselverwaltung) und
 Mehrfachversand (nicht immer standardmäßig verfügbar).
Je unterschiedlicher die Attribute für eine Menge von Kommunikationskanälen ausge-
prägt sind und je vielfältiger letztere damit sind, desto komplexer ist die korrespondie-
rende Infrastruktur.
Definition 3.1.43. Sei PLtop−com = (A,S,Z,AB) die zweite Ausbaustufe einer Pro-
zesslandschaft und CC = ∅ die zugehörige Menge funktionsfähiger Kommunikations-
kanäle. Mit Hilfe der Abbildung valueCC lässt sich die Komplexität einer Kommuni-
kationsinfrastruktur definieren als:
Komplexit a¨t := |{valueCC (cc) | ∃ z1, z2 ∈ Z : channel(z1, z2) = cc} |
Kopplung von Orten
Unter dem Oberbegriff der Kopplung von Orten wird die Kommunikation zwischen
Aktivitäten an verschiedenen ausgewählten Orten betrachtet. Der Begriff der Kopp-
lung ist dabei, wie bereits zu Beginn des Abschnitts 2.3.4 motiviert, dem Bereich der
komponentenbasierten Softwareentwicklung entliehen.
Definition 3.1.44. Sei PLtop−com = (A,S,Z,AB) die zweite Ausbaustufe einer Pro-
zesslandschaft und CC = ∅ die zugehörige Menge funktionsfähiger Kommunikations-
kanäle. Weiterhin seien o
1
, o
2
∈ O mit o
1
= o
2
, s ∈ S,
A(o) :={a ∈ leaves | local(a) = {o}} und
CC(o) :={cc ∈ CC | ∃ a ∈ A(o)∃ a′ /∈ A(o) :
cc = channel
(
(a, s), (s, a′)
)
∨ cc = channel
(
(a′, s), (s, a)
)
}
diejenige Teilmenge aller Kanäle cc ∈ CC , über die jeweils eine Aktivität a ∈ A(o)
mit einer Aktivität a′ /∈ A(o) kommuniziert.
Die Kopplungsdichte zwischen zwei Orten o
1
und o
2
entspricht der Anzahl der Kom-
munikationskanäle zwischen allen Paaren von Aktivitäten a und a′ der beiden ausge-
wählten Orte o
1
und o
2
:
Kopplungsdichte
2
(o
1
, o
2
) := |CC(o
1
) ∩ CC(o
2
)|
Bemerkung 3.1.45. Der Index der Kopplungsdichte zeigt die Anzahl der Orte an, für
die diese Kopplungsdichte berechnet wird.
88
3.1 Notation der oberen Ebenen einer Prozesslandschaft
Beispiel:
Im Beispiel der Prozesslandschaft zur komponentenbasierten Softwareentwick-
lung sind die meisten der Projektmanagementaktivitäten einem Standort o
1
=
Managementstandort zugeordnet. An diesem finden alle koordinierenden Aktivitä-
ten wie Projektplanung, Ressourcenverteilung und Projektsteuerung statt. Außerdem
werden hier wichtige Entscheidungen wie Einkauf oder Neuentwicklung benötigter
Komponenten getroffen. An einem zweiten Standort o
2
= Anwendungsentwicklung
wird die Anwendung für den Kunden entwickelt. Dazu werden Spezifikationen er-
stellt, die Softwarearchitektur entworfen und schließlich die gekauften und die durch
das Component Engineering realisierten Komponenten zu einem Gesamtsystem zu-
sammengesetzt. Außerdem werden an diesem Ort alle begleitenden Reviews und Tests
des zu erstellenden Systems durchgeführt.
Tabelle 3.2 zeigt die Kommunikation zwischen den beiden Standorten. Jede Zeile re-
präsentiert einen Kommunikationskanal. Insgesamt werden elf Dokumente vom Ma-
nagementstandort zur Anwendungsentwicklung und 13 Dokumente von der Anwen-
dungsentwicklung zum Managementstandort geschickt. Daraus ergibt sich für die
Kopplungsdichte ein Wert von 24 bei 20 Aktivitäten am Managementstandort und
16 Aktivitäten bei der Anwendungsentwicklung.
Definition 3.1.46. Sei PLtop−com = (A,S,Z,AB) die zweite Ausbaustufe einer Pro-
zesslandschaft und o ∈ O. Die Kopplungsdichte eines Ortes o ist definiert als
Kopplungsdichte
1
(o) :=
∑
o′∈O\{o}
Kopplungsdichte
2
(o, o′)
Die Kopplungsdichte eines Ortes entspricht damit der Anzahl der Kommunikations-
kanäle zwischen allen Paaren von Aktivitäten a ∈ A(o) und a′ /∈ A(o), bei denen
also local (a) = {o} und {o} /∈ local (a′). Sie wird durch die Anzahl seiner ein- und
ausgehenden Kommunikationskanäle bestimmt.
Beispiel:
Abbildung 3.10 zeigt einen Überblick über die Kopplungsdichten der Beispielprozess-
landschaft, die hier über insgesamt vier Standorte verteilt ist. Neben dem Manage-
mentstandort und der Anwendungsentwicklung gibt es noch den Kundenstandort und
die Komponentenentwicklung. Am Standort des Kunden werden beispielsweise das
Anforderungsdokument erstellt und die Abnahme durchgeführt, während bei der Kom-
ponentenentwicklung der Entwurf und die Implementierung der neu zu entwickelnden
Komponenten durchgeführt werden. Die Zahlen an den Verbindungslinien zwischen
den einzelnen Standorten entsprechen der Kopplungsdichte. Die Kopplungsdichte des
Managementstandortes (= 38) lässt sich für dieses Beispiel als Summe der Kopplungs-
dichten zum Kundenstandort, zur Anwendungs- und zur Komponentenentwicklung
berechnen.
89
Formale Basis des Process Landscaping
Sender-Aktivität Ort Empfänger-Aktivität Ort Dokument
Releaseplanung o
2
Projektplanerstellung o
1
Releaseplanung
Buy-or-Build o
1
Komponente kaufen o
2
Buy-or-Build
Entscheidung treffen Entscheidung
Projekt einschätzen o
1
Releaseplanung o
2
Projekteinschätzung
Wiederverwendungs- o
1
Spezifikation o
2
Repository
repository verwalten erstellen Spezifikation
Wiederverwendungs- o
1
Systemarchitektur o
2
Repository
repository verwalten erstellen Architektur
Wiederverwendungs- o
1
Vorh. Komponenten o
2
Repository
repository verwalten auswählen Softwarekomponenten
Geschäftsprozess o
1
Spezifikation o
2
Repository
modellieren erstellen Spezifikation
Testdurchführung o
2
Testablauf- o
1
Status Test
verfolgung
Testvorbereitung o
2
Testauswertung o
1
Testbeschreibung
Testdurchführung o
2
Testauswertung o
1
Fehlerprotokoll integr.
Softwaresystem
Testdurchführung o
2
Testauswertung o
1
Fehlerprotokoll install.
Softwaresystem
Testdurchführung o
2
Testauswertung o
1
Fehlerprotokoll
Neue Komponente
Richtlinienerstellung o
1
Testvorbereitung o
2
Richtlinien
Richtlinienerstellung o
1
Testdurchführung o
2
Richtlinien
Richtlinienerstellung o
1
Reviewdurchführung o
2
Richtlinien
Testplanerstellung o
1
Testvorbereitung o
2
Testplan
Testablaufverfolgung o
1
Testvorbereitung o
2
Testplan
Reviewdurchführung o
2
Testablaufverfolgung o
1
Status Review
Reviewdurchführung o
2
Reviewauswertung o
1
Review
Anforderungsdokument
Reviewdurchführung o
2
Reviewauswertung o
1
Review
Spezifikationsdokument
Reviewdurchführung o
2
Reviewauswertung o
1
Review
Systemarchitektur
Reviewdurchführung o
2
Reviewauswertung o
1
Review
Releaseplanung
Reviewdurchführung o
2
Reviewauswertung o
1
Review Technische
Komponentenanforderung
Komponente anfordern o
2
Markt analysieren o
1
Komponentenanforderung
Tabelle 3.2: Kommunikation zwischen dem Managementstandort und dem Standort
Anwendungsentwicklung
90
3.1 Notation der oberen Ebenen einer Prozesslandschaft
Managementstandort
Aktivitäten: 20
Kundenstandort
Aktivitäten: 4
Anwendungsentwicklung
Aktivitäten: 16
Komponentenentwicklung
Aktivitäten: 1224
413
5 9
Abbildung 3.10: Berechnung der Kopplungsdichte eines Ortes
Über die Kopplungskomplexität von Orten lässt sich die Komplexität der Kommuni-
kationsstruktur einer Prozesslandschaft bestimmen.
Definition 3.1.47. Sei PLtop−com = (A,S,Z,AB) die zweite Ausbaustufe einer Pro-
zesslandschaft, CC = ∅ die zugehörige Menge funktionsfähiger Kommunikations-
kanäle und o
1
, o
2
∈ O mit o
1
= o
2
. Weiterhin sei mit CC(o) eine Teilmenge der
funktionsfähigen Kommunikationskanäle wie in Definition 3.1.44 festgelegt. Die Kopp-
lungskomplexität zwischen zwei Orten o
1
und o
2
bezeichnet die Anzahl der verschie-
denartig ausgeprägten Kommunikationskanäle zwischen allen Paaren von Aktivitäten
a, a′ ∈ A der beiden ausgewählten Orte o
1
und o
2
:
Kopplungskomplexit a¨ t
2
(o
1
, o
2
) :=
∣
∣
{valueCC(cc) | cc ∈ CC(o1) ∩ CC(o2)}
∣
∣
Definition 3.1.48. Sei PLtop−com = (A,S,Z,AB) die zweite Ausbaustufe einer Pro-
zesslandschaft und o ∈ O. Die Kopplungskomplexität eines Ortes o ist definiert als
Kopplungskomplexit a¨ t
1
(o) :=
∑
o′∈O\{o}
Kopplungskomplexit a¨ t
2
(o, o′)
Die Kopplungskomplexität eines Ortes bezeichnet damit die Anzahl der verschieden-
artig ausgeprägten Kommunikationskanäle zwischen allen Paaren von Aktivitäten
a ∈ A(o) und a′ /∈ A(o), bei denen also local (a) = {o} und {o} /∈ local (a′) ist.
Beispiele:
 Fall 1: Innerhalb einer Prozesslandschaft ist geplant, Standorte zusammenzule-
gen. Eine hohe Kopplungskomplexität zwischen zwei Orten deutet darauf hin,
dass vorzugsweise diese zwei Orte zusammengelegt werden sollten, um den
Aufwand für den Aufbau einer Kommunikationsinfrastruktur zu minimieren.
Für die Identifikation der maximalen Kopplungskomplexität einer Prozessland-
schaft wird diese für alle möglichen Kombinationen von jeweils zwei Orten be-
rechnet.
91
Formale Basis des Process Landscaping
 Fall 2: Innerhalb einer Prozesslandschaft werden die Auflösung eines oder meh-
rerer Standorte und die Verteilung der dortigen Aktivitäten auf andere Stand-
orte geplant. Es empfiehlt sich, eher Aktivitäten von Orten mit geringer Kopp-
lungskomplexität auf mehrere Standorte zu verteilen statt Aktivitäten von Orten
mit hoher Kopplungskomplexität, um die Kostensteigerung der verbleibenden
Standorte möglichst gering zu halten. Dazu wird das Minimum der Kopplungs-
komplexitäten aller Orte berechnet.
 Fall 3: Ergibt die Analyse einer gegebenen Prozesslandschaft eine hohe Kopp-
lungskomplexität zu externen Aktivitäten (z.B. Zulieferer), sollte individuell
überlegt werden, ob dies erwünscht ist. So kann es z.B. sein, dass eine hohe
Kopplung an Zuliefereraktivitäten eine große Abhängigkeit anzeigt, die immer
vermieden werden sollte.
Die Kopplungszahl eines Ortes wird ähnlich der Kopplungsdichte eines Ortes defi-
niert, allerdings wird hierfür lediglich die Anzahl derjenigen Orte gezählt, die über
Kommunikationskanäle mit dem betrachteten Ort verbunden sind.
Definition 3.1.49. Sei PLtop−com = (A,S,Z,AB) die zweite Ausbaustufe einer Pro-
zesslandschaft und o ∈ O. Die Kopplungszahl eines Ortes o entspricht der Anzahl der
Orte, die über Kommunikationskanäle zwischen allen Paaren von Aktivitäten a und a′
verbunden sind, bei denen local (a) = {o} und o /∈ local (a′) gilt:
Kopplungszahl (o) :=
∣
∣
{o′ ∈ O\{o} | Kopplungsdichte
2
(o, o′) ≥ 1}
∣
∣
Die Kopplungszahl eines Ortes bezeichnet also die Anzahl der Orte, mit denen ein
ausgewählter Ort kommuniziert. Der Managementstandort der Prozesslandschaft in
Abbildung 3.10 hat beispielsweise eine Kopplungszahl von drei.
Kohäsion von Orten
Kohäsion in Prozesslandschaften ist ähnlich aufzufassen wie Kohäsion im Rahmen
komponentenbasierter Softwareentwicklung. Es werden Anzahl und Vielfalt der Kom-
munikationskanäle zwischen Aktivitäten eines Ortes betrachtet.
Definition 3.1.50. Sei PLtop−com = (A,S,Z,AB) die zweite Ausbaustufe einer Pro-
zesslandschaft und CC = ∅ die zugehörige Menge funktionsfähiger Kommunikations-
kanäle. Weiterhin seien s ∈ S, o ∈ O und A(o) := {a ∈ leaves | local(a) = {o}}.
Schließlich sei
CC ′(o) := {cc ∈ CC | ∃ a, a′ ∈ A(o) : cc = channel
(
(a, s), (s, a′)
)
∨
cc = channel
(
(a′, s), (s, a)
)
}
diejenige Teilmenge aller Kommunikationskanäle cc ∈ CC , über die jeweils zwei am
gleichen Ort o liegende Aktivitäten a, a′ ∈ A miteinander kommunizieren.
Die Kohäsionsdichte eines Ortes o entspricht der Anzahl der funktionsfähigen Kom-
munikationskanäle zwischen allen Paaren von Aktivitäten a, a′ an diesem Ort o:
Koha¨sionsdichte(o) :=
∣
∣CC ′(o)
∣
∣
92
3.1 Notation der oberen Ebenen einer Prozesslandschaft
Tabelle 3.3 zeigt die interne Kommunikation am Managementstandort. Jede Zeile re-
präsentiert einen Kommunikationskanal, woraus sich insgesamt eine Kohäsionsdichte
von 20 ergibt.
Sender-Aktivität Dokument Empfänger-Aktivität
Ressourcenplanung Ausstattung Projekt initialisieren
Teamzusammenstellung Projektteam Projekt initialisieren
Projektplanerstellung Projektplan Projekt initialisieren
Risikomanagement Abnahmefreigabe Projektsteuerung
und -kontrolle
Projektsteuerung und -kontrolle Projektstatus Projektdarstellung
nach außen
Markt analysieren Marktanalyse Buy or Build-
Entscheidung treffen
Buy or Build-Entscheidung treffen Buy or Build-Entscheidung CE mit Komponenten-
entwicklung beauftragen
Projekt einschätzen Projekteinschätzung Risikomanagement
Projekt einschätzen Projekteinschätzung Markt analysieren
Projekt einschätzen Projekteinschätzung Projektsteuerung
und -kontrolle
Geschäftsprozess modellieren Geschäftsprozessmodell Wiederverwendungs-
repository verwalten
Wiederverwendungsrepository verwalten Repository Architektur Projekt einschätzen
Wiederverwendungsrepository verwalten Repository Projekt einschätzen
Softwarekomponenten
Richtlinienerstellung Richtlinien Reviewauswertung
Richtlinienerstellung Richtlinien Testauswertung
Testauswertung Testauswertung Richtlinienerstellung
Testablaufverfolgung Testplan Reviewauswertung
Testplanerstellung Testplan Testablaufverfolgung
Testplanerstellung Testplan Projektplanerstellung
Reviewauswertung Reviewauswertung Richtlinienerstellung
Tabelle 3.3: Interne Kommunikation am Managementstandort
Definition 3.1.51. Sei PLtop−com = (A,S,Z,AB) die zweite Ausbaustufe einer Pro-
zesslandschaft, CC = ∅ die zugehörige Menge funktionsfähiger Kommunikations-
kanäle und o ∈ O. Sei weiterhin mit CC′(o) eine Teilmenge der funktionsfähigen
Kommunikationskanäle wie in Definition 3.1.50 festgelegt.
Die Kohäsionskomplexität eines Ortes o entspricht der Anzahl unterschiedlich ausge-
prägter Kommunikationskanäle zwischen allen Paaren von Aktivitäten a, a′ an diesem
Ort o:
Koha¨sionskomplexit a¨t(o) :=
∣
∣
{valueCC(cc) | cc ∈ CC ′(o)}
∣
∣
93
Formale Basis des Process Landscaping
Für das Beispiel des Managementstandortes wurde eine Kohäsionskomplexität von
12 berechnet. Die Kommunikation verläuft mehrheitlich asynchron, da Informationen
über Dokumente ausgetauscht werden, deren Inhalt lediglich bei Besprechungstermi-
nen synchron vermittelt wird. Kombinationen von Attributwerten, die in diesem Bei-
spiel nicht vorkommen, sind unter anderem ein verschlüsselter Mehrfachversand, ver-
änderbarer und synchroner Informationsaustausch oder eine gleichzeitig asynchrone
und verschlüsselte Kommunikation.
Definition 3.1.52. Sei PLtop−com = (A,S,Z,AB) die zweite Ausbaustufe einer Pro-
zesslandschaft, CC = ∅ die zugehörige Menge funktionsfähiger Kommunikations-
kanäle, s ∈ S und o ∈ O. Weiterhin sei mit A(o) eine Aktivitätsteilmenge wie in
Definition 3.1.50 festgelegt.
Die Kohäsionszahl entspricht der Anzahl der Aktivitäten an einem Ort o, die über
Kommunikationskanäle mit anderen Aktivitäten am selben Ort o verbunden sind:
Koha¨sionszahl (o) :=
∣
∣
{a ∈ A(o) | ∃ a′ ∈ A(o) : cc = channel
(
(a, s), (s, a′)
)
∨
cc = channel
(
(a′, s), (s, a)
)
}
∣
∣
Die Kohäsionszahl des Managementstandortes der Beispielprozesslandschaft be-
trägt 19. Die Differenz zur Gesamtzahl von 20 Aktivitäten (vgl. Abbildung 3.10) er-
klärt sich dadurch, dass die Aktivität Projektabschluss zwar externe Kommunikation
mit dem Kunden betreibt, intern aber – zumindest bei dem modellierten Abstraktions-
grad – keine Informationen weitergeleitet werden.
Mit den Definitionen rund um die Begriffe der Kohäsion und Kopplung von Aktivitä-
ten ist ein Rahmenwerk entstanden, das die Analyse der Kommunikationsinfrastruktur
der zweiten Ausbaustufe einer gegebenen Prozesslandschaft erlaubt. Wie die konkre-
ten Kopplungs- und Kohäsionswerte zur Berechung und Analyse eines Kommunika-
tionskostenfaktors Kkf eingesetzt werden, ist bereits in Abschnitt 2.3.4 auf Seite 44
erläutert worden. Die Analyse bleibt auf statischer Ebene, da die verwendete PLL-
Notation keinerlei Information über die Dynamik der Kommunikation enthält. Um für
eine gegebene Prozesslandschaft, die in PLL-Notation dargestellt ist, ihr dynamisches
Verhalten betrachten zu können, muss diese zunächst um Ablaufinformationen ergänzt
werden. Diese Ergänzungen sowie zusätzliche Erweiterungen des zugrundeliegenden
Petrinetzes sind Thema des nachfolgenden Abschnitts.
3.2 Notation der unteren Ebenen einer Prozesslandschaft
Die unteren Ebenen einer Prozesslandschaft unterscheiden sich insofern von den obe-
ren, als dass auf den unteren immer auch Ablaufinformationen modelliert sind. Die
Ergänzung der zweiten Ausbaustufe einer Prozesslandschaft um diese Ablaufinforma-
tionen und damit der Übergang von der Modellierung der oberen zur Modellierung der
unteren Ebenen wird in Abschnitt 3.2.1 diskutiert. In Abschnitt 3.2.2 werden weitere
Abbildungen und Begriffe formuliert, die für eine vierte Ausbaustufe einer Prozess-
94
3.2 Notation der unteren Ebenen einer Prozesslandschaft
landschaft die Analyse der unteren Landschaftsebenen bezüglich verschiedener dyna-
mischer Kommunikationseigenschaften ermöglichen.
3.2.1 Hinzufügen von Ablaufinformationen
Die Ergänzung einer in PLL notierten Prozesslandschaft um Ablaufinformationen er-
fordert die Berücksichtigung verschiedener Aspekte. Zunächst wird das zugrundelie-
gende Petrinetz durch das Hinzufügen weiterer Zugriffe z ∈ Z zu einem zusammen-
hängenden Graphen ergänzt. Für diesen werden Bedingungen formuliert, wann eine
Aktivität schaltfähig ist, um darüber vom Kontext der betrachteten Prozesslandschaft
abhängige Verhaltensvorschriften festlegen zu können. Die einzelnen hierfür notwen-
digen Schritte werden in der Reihenfolge ihrer Durchführung diskutiert. Zuvor werden
jedoch einige grundlegende Begriffe definiert, die bestimmte Eigenschaften von Petri-
netzen charakterisieren. Sie werden für die schrittweise Ergänzung benötigt.
Definition 3.2.1. Sei R ⊆ X ×X eine binäre Relation und x, y ∈ X.
•x := {y | yRx} heißt der Vorbereich von x.
x• := {y | xRy} heißt der Nachbereich von x.
Des Weiteren wird definiert:
•X :=
⋃
x∈X
•x und X• :=
⋃
x∈X
x • .
Insbesondere gilt also für x, y ∈ X: x ∈ •y ⇔ y ∈ x•.
Definition 3.2.2. Sei PN = (APN , S, ZPN ) ein Petrinetz. PN heißt proper:⇔
1. S ∪APN = ∅
2. •(S ∪APN ) ∪ (S ∪APN )• = S ∪APN
Bedingung 1. bedeutet, dass ein Netz ohne Knoten ausgeschlossen ist. Bedingung 2.
bedeutet, dass es keine isolierten Knoten gibt. Dadurch wird ein minimaler lokaler
Zusammenhang gefordert.
Definition 3.2.3. Sei PN = (APN , S, ZPN ) ein properes Petrinetz. Seien weiter
k, k′ ∈ APN ∪ S. Eine Folge z1, ..., zn von Zugriffen heißt ungerichteter Pfad von
k nach k′ :⇔ Es existiert eine Folge
k = k
1
, k
2
, ..., kn, kn+1 = k′ von k nach k′
von Knoten aus APN ∪ S, so dass für alle 1 ≤ i ≤ n gilt:
zi = (ki, ki+1) ∈ ZPN ∨ zi = (ki+1, ki) ∈ ZPN
PN heißt kohärent :⇔Für alle k, k′ ∈ (APN ∪ S)
existiert ein ungerichteter Pfad von k nach k′.
95
Formale Basis des Process Landscaping
Durch die Kohärenz wird ein vollständiger Zusammenhang zwischen den Knoten aus
APN und S gefordert.
Um für eine über mehrere Orte verteilte Prozesslandschaft deren Kommunikationsver-
halten analysieren zu können, werden für die Struktur des zugrundeliegenden Petri-
netzes Einschränkungen formuliert, die „Synchronieaussagen“ [Bau96] ermöglichen.
Diese beantworten unter anderem „Fragen der Art, wie oft Ereignisse einer Art A und
Ereignisse einer Art B im Verhältnis zueinander stattfinden können“ [Bau96]. Bezogen
auf die Analyse von Kommunikationsverhalten einer verteilten Prozesslandschaft kön-
nen dies Fragen nach den internen Kommunikationskosten im Verhältnis zu externen
Kommunikationskosten sein oder Fragen zum Verhältnis der Prozessauslastungen ver-
schiedener Teilbereiche einer Prozesslandschaft zueinander (vgl. Abschnitt 3.2.2.2).
Für das Beispiel der komponentenbasierten Softwareentwicklung muss dazu unter an-
derem messbar sein, wie oft das Qualitätsmanagement Reviews für welche Kompo-
nentenentwicklungsstandorte durchzuführen hat. Dazu muss auch eindeutig erkenn-
bar sein, welcher Standort ein Dokument zum Review an das Qualitätsmanagement
schickt. Letzteres ist aber nur dann möglich, wenn im zugrundeliegenden Petrinetz je-
de Aktivität eines Komponentenentwicklungsstandortes über einen eigenen Kommu-
nikationskanal – und damit über eine separate Schnittstelle – mit einer Aktivität des
Qualitätsmanagements kommuniziert. Würde die Kommunikation mehrerer Kompo-
nentenentwicklungsstandorte mit einem Qualitätsmanagementstandort über eine ge-
meinsame Schnittstelle modelliert, wäre die eindeutige Identifikation der Herkunft
eines weitergeleiteten Informationsobjektes nicht mehr klar nachvollziehbar. Für ei-
ne Prozesslandschaft werden dazu entsprechende Einschränkungen für die Menge der
Schnittstellen formuliert.
Definition 3.2.4. Sei PLtop−com = (A,S,Z,AB) die zweite Ausbaustufe einer Pro-
zesslandschaft. Für die Menge S der Schnittstellen können zwei ausgezeichnete Teil-
mengen definiert werden.
Sextern :={s ∈ S
∣
∣
| • s| = |s • | = 1 ∧ •s ∩ s• = ∅}
Sintern :=S\Sextern
Bemerkung 3.2.5. Durch Sintern und Sextern wird die Menge S der Schnittstellen in
zwei disjunkte Teilmengen unterteilt, d.h.
S = Sintern ∪ Sextern mit Sintern ∩ Sextern = ∅
Notation 3.2.6. Sintern bezeichnet eine Menge von internen Schnittstellen, Sextern
eine Menge von externen Schnittstellen.
Bemerkung 3.2.7. Eine externe Schnittstelle gibt an, dass es eine Verbindung zwi-
schen zwei Aktivitäten auf oberen Abstraktionsniveaus gibt und damit mindestens eine
Schnittstelle zwischen zwei Aktivitäten innerhalb von verfeinerten bzw. noch zu verfei-
nernden Aktivitäten. Die zugehörigen Einschränkungen sind erforderlich um sicherzu-
stellen, dass die Grenzen zwischen zwei verfeinerten Aktivitäten einfach handhabbare
96
3.2 Notation der unteren Ebenen einer Prozesslandschaft
Schnittstellen bleiben, an denen keine Konflikte auftreten. Letztere sind immer dann
gegeben, wenn zwei Aktivitäten mindestens eine gemeinsame (markierte) Schnittstelle
in ihren Vorbereichen haben.
Alle für das Hinzufügen von Ablaufinformationen zu einer als PLtop−com vorliegen-
den Prozesslandschaft erforderlichen Schritte werden nach der Einführung notwen-
diger Definitionen und Abbildungsvorschriften jeweils beispielhaft an Ausschnitten
der Prozesslandschaft zur komponentenbasierten Softwareentwicklung erläutert, die
in Abschnitt 2.2.1 eingeführt worden ist. Diese Schritte beinhalten
1. die Erweiterung der Prozesslandschaft PLtop−com zu einer kohärenten Prozess-
landschaft,
2. das Festlegen der Schaltverhalten für alle Aktivitäten innerhalb der Prozessland-
schaft,
3. die Erweiterung der Verfeinerungskonzepte bezüglich Aktivitäten und Schnitt-
stellen und
4. die Berücksichtigung von speziellen Situationen innerhalb der Prozessland-
schaft.
3
technische
Komponentenan-
forderungen erstellen
Anforderungsanalyse
erstellen 8
15
Geschäftsprozess
modellieren
technische Komponentenanforderung8
Geschäftsprozessmodell15
  Anforderungsdokument3
26
Review Anforderungsdokument26
17
erste Anforderungen17
9
Review technische Komponentenanforderung9
30
Anfrage nach Geschäftsprozessmodell30
11
Systemarchitektur11
Abbildung 3.11: Teilausschnitt der Beispielprozesslandschaft
Abbildung 3.11 zeigt einen Ausschnitt der in PLLmodellierten Prozesslandschaft zur
komponentenbasierten Softwareentwicklung. Für die Diskussion der Schritte 1. bis 4.
werden Aktivitäten des Application Engineering und des Domain Engineering näher
betrachtet, die auf die acht in der Abbildung dargestellten Schnittstellen zugreifen. Die
97
Formale Basis des Process Landscaping
beiden Schnittstellen erste Anforderungen und Anfrage nach Geschäftsprozessmodell
werden nur innerhalb des dargestellten Teilbereichs verwendet und sind daher nicht
fett umrandet. Der in Abbildung 3.11 dargestellte Teilbereich der Prozesslandschaft
ist für die Diskussion repräsentativ, da sowohl verschiedene Abstraktionsebenen und
Aktivitäten aus verschiedenen Verfeinerungen als auch unterschiedliche Zugriffe und
Schnittstellen betrachtet werden. Die Landschaftselemente (Aktivitäten, Schnittstel-
len, Zugriffe) sind in Abbildung 3.11 als eigene Prozesslandschaft dargestellt, um den
Kontext der Aktivitäten und ihrer Zugriffe auf die Schnittstellen zu verdeutlichen. Im
korrespondierenden Aktivitätenbaum stehen sie in keiner Hierarchierelation zueinan-
der.
Bevor eine Prozesslandschaft PLtop−com zu einer kohärenten Landschaft erweitert
werden kann, muss sie verschiedene Voraussetzungen erfüllen. Ihre Vollständigkeit
(vgl. Definition 3.1.32, Seite 81) ist eine Mindestvoraussetzung. Sie gewährleistet die
Erstellung einer kohärenten Prozesslandschaft, die nicht aus isolierten Fragmenten be-
steht. Für eine spätere Darstellung von Ablaufinformationen sollte ein Modellierer au-
ßerdem zunächst überprüfen, ob jede Aktivität über einen lesenden Zugriff mit einer
Schnittstelle verknüpft ist. Existiert kein solcher Zugriff bzw. keine korrespondierende
Schnittstelle, entsteht in der kohärenten Prozesslandschaft eine Aktivität ohne Vorbe-
reich, die somit immer schaltfähig ist (vgl. Definition 3.2.15, Seite 104). Dies ist aber
aus Ablaufsicht selten so gewollt, und daher sollte ggf. eine entsprechende Schnittstel-
le bereits in der PLL-Notation ergänzt werden. Eine Ergänzung dieser Schnittstelle
zu einem späteren Zeitpunkt hätte den Nachteil, dass nachträglich nicht nur weitere
Datenflussrelationen modelliert, sondern auch bereits definierte Schaltregeln (vgl. Ab-
schnitt 3.2.1.2) erneut überprüft und eventuell angepasst werden müssten.
Im Beispielausschnitt der Prozesslandschaft in Abbildung 3.11 ist die Schnittstelle
Anfrage nach Geschäftsprozessmodell mit einem lesenden Zugriff seitens der Akti-
vität Geschäftsprozess modellieren aus dem zuletzt angesprochenen Grund ergänzt
worden. In der erweiterten Prozesslandschaft wird sie zum Vorbereich der Aktivität
Geschäftsprozess modellieren, ohne dessen Belegung diese nicht schalten kann.
3.2.1.1 Erweiterung einer Prozesslandschaft zu einem kohärenten Netz
Die Erweiterung einer Prozesslandschaft zu einem kohärenten Netz berücksichtigt
zunächst nur nicht weiter verfeinerte Aktivitäten zusammen mit ihren expliziten Zu-
griffen auf Schnittstellen. Existieren in einer Prozesslandschaft PLtop−com mehrere
Zugriffe von Aktivitäten auf eine Schnittstelle s, muss diese für die Konstruktion einer
kohärenten Prozesslandschaft mehrfach dupliziert werden. Die Anzahl der resultie-
renden Schnittstellen ergibt sich aus der Anzahl der auf s schreibend zugreifenden
Aktivitäten multipliziert mit der Anzahl der auf s lesend zugreifenden Aktivitäten,
sofern nicht ausschließlich lesende oder ausschließlich schreibende Zugriffe auf
die Schnittstelle s existieren. So wird sichergestellt, dass zunächst alle möglichen
Datenflüsse abgebildet sind.
98
3.2 Notation der unteren Ebenen einer Prozesslandschaft
Definition 3.2.8. Sei PLtop−com = (A,S,Z,AB) die zweite Ausbaustufe einer Pro-
zesslandschaft und S = {s
1
, ..., sn}.
Eine Prozesslandschaft PL = (APL, SPL, ZPL, ABPL) heißt Erweiterung von
PLtop−com zu einer kohärenten Prozesslandschaft genau dann, wenn
1. APL = A
2. Sei card(si) eine Bezeichnung, die angibt, durch wieviele Schnittstellen s˜ ∈
SPL eine Schnittstelle si ∈ S ersetzt wird.
∀ si ∈ S : card(si) =















|{a ∈ leaves | (a, si) ∈ explicit}| falls
{a ∈ leaves | (si, a) ∈ explicit} = ∅
|{a ∈ leaves | (si, a) ∈ explicit}| falls
{a ∈ leaves | (a, si) ∈ explicit} = ∅
|{a ∈ leaves | (a, si) ∈ explicit}|×
|{a ∈ leaves | (si, a) ∈ explicit}| sonst
Für jede Schnittstelle si ∈ S existiert eine Menge G(si) mit
G(si) = {si,1, ..., si,card(s
i
)
},
G(si) ∩ S = ∅ und
∀ 1 ≤ i, j ≤ n, i = j : G(si) ∩G(sj) = ∅
Damit gilt: SPL = ˙
⋃
s
i
∈S
G(si)
3. ZPL = {(a, s˜) | a ∈ A,∃ si : (a, si) ∈ Z, s˜ ∈ G(si)}∪
{(s˜, a) | a ∈ A,∃ si : (si, a) ∈ Z, s˜ ∈ G(si)}
4. ABPL = AB
Mit der ersten Bedingung wird sichergestellt, dass die Menge der Aktivitäten einer
Prozesslandschaft im Rahmen der Erweiterung nicht verändert wird. Mit der zweiten
Bedingung wird für jede Schnittstelle si ∈ S aus PLtop−com die Anzahl der s˜ ∈ SPL
festgelegt, durch die jedes si ∈ S im Rahmen der Erweiterung ersetzt wird. Dazu wird
jedem si ∈ S eine Menge G(si) ⊂ SPL zugeordnet, deren Mächtigkeit mit Hilfe der
Bezeichnung card(si) bestimmt wird:
 Existieren keine lesenden (schreibenden) Zugriffe von Aktivitäten auf eine
Schnittstelle si ∈ S, entspricht die Mächtigkeit der Menge G(si) der Anzahl
der schreibenden (lesenden) Zugriffe auf diese Schnittstelle si ∈ S.
 Existieren sowohl lesende als auch schreibende Zugriffe auf eine Schnittstelle
si ∈ S, entspricht die Mächtigkeit von G(si) dem Produkt aus der Anzahl der
lesenden Zugriffe auf diese Schnittstelle si ∈ S und der Anzahl der schreiben-
den Zugriffe.
99
Formale Basis des Process Landscaping
Des Weiteren wird mitG(si)∩S = ∅ sichergestellt, dass die Menge der Schnittstellen
s˜ ∈ SPL nicht aus der Menge der Schnittstellen si ∈ S konstruiert, sondern neu
definiert wird. Die Menge der Schnittstellen s˜ ∈ SPL lässt sich dann als disjunkte
Vereinigung aller Mengen G(si) formulieren.
Die dritte Bedingung fordert, dass jeder Zugriff (a, si) aus PLtop−com so oft als Zu-
griff (a, s˜) in PL vorkommt, wie Schnittstellen s˜ aus der korrespondierenden Schnitt-
stelle si entstanden sind. Dies gilt analog für jeden Zugriff (si, a) ∈ Z . Die vierte Be-
dingung sichert die Beibehaltung des Aktivitätenbaumes AB in unveränderter Form.
Definition 3.2.9. Sei PL = (APL, SPL, ZPL, ABPL) eine kohärente Prozess-
landschaft, die durch Erweiterung der zweiten Ausbaustufe einer Prozesslandschaft
PLtop−com = (A,S,Z,AB) entstanden ist. Jedes s˜ ∈ SPL ist durch Duplizieren von
si ∈ S = {s1, ..., sn} entstanden:⇔ s˜ ∈ G(si).
Notation 3.2.10. Wenn keine Missverständnisse auftreten können, wird im Folgen-
den eine Prozesslandschaft PL = (APL, SPL, ZPL, ABPL) verkürzt als Prozessland-
schaft PL = (A,S,Z,AB) bezeichnet.
Bemerkung 3.2.11. Für die Schnittstellen einer kohärenten Prozesslandschaft PL =
(A,S,Z,AB) mit S = Sintern ∪ Sextern können weitere Aussagen getroffen werden:
1. Sintern = {s ∈ S | •s ∩ s• = ∅}
2. Sextern = S\Sintern
3. |Sintern | = |{a ∈ A | a ∈ (•s ∩ s•)}|
Die gemäß Definition 3.2.8 entstandenen Schnittstellen sind immer dann externe
Schnittstellen, wenn alle für sie geforderten Einschränkungen gültig sind (vgl. Defi-
nition 3.2.4 einer externen Schnittstelle, Seite 96). Es kann jedoch vorkommen, dass
auf sie von der gleichen Aktivität sowohl lesend als auch schreibend zugegriffen wird,
ihr Vor- und Nachbereich also gemeinsame Elemente haben. Ist •s∩s• = ∅, so handelt
es sich um eine interne Schnittstelle. Ihre Anzahl entspricht der Anzahl an Aktivitäten,
die sowohl im Vor- als auch im Nachbereich einer Schnittstelle s enthalten ist.
Abbildung 3.12 zeigt die Dokumentensicht der im Beispiel beteiligten Schnittstellen.
Alle Aktivitäten, die zusätzlich zu den ursprünglich betrachteten in Relation zu die-
sen Schnittstellen stehen (vgl. Abbildung 3.11), werden im Rahmen des ersten Er-
weiterungsschrittes ebenfalls berücksichtigt. Konkret sind dies die Aktivitäten Versi-
onsmanagement (AE), Releaseplanung (AE), Reviewdurchführung (AE), Spezifikati-
on erstellen, Komponente anfordern, Wiederverwendungsrepository verwalten, Pro-
jekt einschätzen und Reviewauswertung. Die Abkürzung (AE) zeigt an, dass die damit
versehenen Aktivitäten verfeinernde Aktivitäten des Application Engineering sind.
Für den in Abbildung 3.11 vorgestellten Ausschnitt der Beispielprozesslandschaft lie-
fert der erste Erweiterungsschritt das in Abbildung 3.13 dargestellte Ergebnis. Um die
Verständlichkeit trotz steigender Komplexität der dargestellten Prozesslandschaft wei-
ter zu gewährleisten, werden die Namen der Aktivitäten nachfolgend unterhalb der sie
100
3.2 Notation der unteren Ebenen einer Prozesslandschaft
3Releaseplanung (AE)
Versionsmanagement (AE)
technische Komponenten-
anforderungen erstellen
Anforderungsanalyse erstellen
Spezifikation erstellen
15
Anforderungsanalyse
erstellen
Wiederverwendungs-
repository verwalten
Geschäftsprozess modellieren
Reviewdurchführung
technische Komponenten-
anforderungen erstellen
Komponente anfordern
Reviewdurchführung
8
Geschäftsprozessmodell15
3 Anforderungsdokument
technische Komponentenanforderung8
26
Anforderungsanalyse erstellen
Reviewauswertung
Reviewdurchführung
Review Anforderungsdokument26
Feedback an DE geben
Reviewdurchführung 11
Systemarchitektur erstellen
technische Komponenten-
anforderungen erstellen
vorhandene Komponenten
auswählen
Versionsmanagement (AE)
Wiederverwendungs-
repository verwalten
Systemarchitektur11
9
technische Komponenten-
anforderung stellen
Reviewauswertung
Reviewdurchführung
Review technische Komponentenanforderung9
Abbildung 3.12: Dokumentensicht der Schnittstellen Anforderungsdokument,
technische Komponentenanforderung, Review technische
Komponentenanforderung, Systemarchitektur, Geschäfts-
prozessmodell und Review Anforderungsdokument
101
Formale Basis des Process Landscaping
repräsentierenden Rechtecke aufgeführt, sofern sie nicht nur aus einem Buchstaben
bestehen. Die Schnittstellen behalten ihre Nummern bei, werden jedoch indiziert. So
bleibt transparent, welche Schnittstelle in PL durch die Duplizierung welcher Schnitt-
stelle aus PLtop−com entstanden ist.
31
32
152
35
36
82
81
83
153
Anforderungs-
analyse erstellen
Geschäfts-
prozess
modellieren
technische Komponenten-
anforderungen erstellen
Review-
durchführung
Spezifikation erstellen
Wiederverwendungsrepository
verwalten
Komponente anfordern
151
33
Versionsmanagement (AE)34
Releaseplanung (AE)
technische Komponentenanforderung81, 82 , 83
Geschäftsprozessmodell151,152, 153
Anforderungsdokument31,..., 36
Review Anforderungsdokument
Reviewauswertung
262
261
17
erste Anforderungen17
261, 262
Systemarchitektur
erstellen
111
112
114
Systemarchitektur111,..., 117
vorhandene Komponente
auswählen
Feedback an DE geben
113
115
116
117
30
Anfrage nach Geschäftsprozessmodell30
Review technische Komponentenanforderung91, 92
91
92
Abbildung 3.13: Kohärente Prozesslandschaft als Ergebnis des ersten Erweiterungs-
schrittes
Im vorliegenden Beispiel liegt die Schnittstelle Anforderungsdokument jetzt sechsmal
vor, die Schnittstelle technische Komponentenanforderung dreimal, Systemarchitektur
siebenmal, Geschäftsprozessmodell dreimal und Review Anforderungsdokument sowie
Review technische Komponentenanforderung jeweils zweimal.
Durch die Duplizierung der Schnittstellen und einer geeigneten Verknüpfung von Ak-
102
3.2 Notation der unteren Ebenen einer Prozesslandschaft
tivitäten und Schnittstellen über Zugriffe (gemäß Definition 3.2.8) entsteht eine kohä-
rente Prozesslandschaft PL, in der alle Informationen über mögliche Datenflüsse der
Prozesslandschaft PLtop−com enthalten sind. Sie liefert die Basis für den zweiten Er-
weiterungsschritt, der der Landschaft Informationen über das Ablaufverhalten in Form
von Verhaltensvorschriften hinzufügt.
3.2.1.2 Festlegung der Schaltverhalten
Um Informationen über das dynamische Verhalten einer Prozesslandschaft analysieren
zu können, muss das Schaltverhalten (Schaltfähigkeit und Schaltregeln) ihrer Aktivi-
täten betrachtet werden. Dies geschieht durch das Festlegen von Bedingungen für die
Belegungen des Vor- und Nachbereichs der zu betrachtenden Aktivitäten mit Marken
vor und nach dem Schalten. Marken repräsentieren Informationsobjekte, die innerhalb
einer Prozesslandschaft von schaltfähigen Aktivitäten verarbeitet bzw. erzeugt werden.
Mit Hilfe von Marken kann die Ausführung eines Petrinetzes definiert werden.
Bemerkung 3.2.12. Über das konkrete Schaltverhalten in einer kohärenten Prozess-
landschaft kann zunächst keine Aussage getroffen werden. In einfachen Petrinetzen wie
Bedingungs-/Ereignisnetzen und Stellen-/Transitionsnetzen wird ein sogenanntes ein-
faches Schaltverhalten verwendet, d.h. eine Aktivität ist schaltfähig, wenn alle Schnitt-
stellen in ihrem Vorbereich jeweils mit mindestens einer Marke belegt sind und die
Kapazität aller Ausgabeschnittstellen ausreichend ist. Für Kanten ohne Gewichtsan-
gabe wird dabei üblicherweise ein Kantengewicht von 1 angenommen; Stellen ohne
Kapazitätsangabe wird eine Kapazität von ∞ zugeordnet [Bau96]. Die Schaltung ei-
ner Aktivität bewirkt die Belegung aller Schnittstellen in ihrem Nachbereich mit einer
(weiteren) Marke.
In einer kohärenten Prozesslandschaft (vgl. Bemerkung 3.1.29 und Definition 3.2.3)
entstehen viele Ablaufsituationen, in denen nur eine Teilmenge aller Schnittstellen im
Vorbereich einer Aktivität mit Marken belegt sein muss, um eine Schaltung zu erlau-
ben. Des Weiteren können Ablaufsituationen auftreten, bei denen die Schaltung einer
Aktivität lediglich die Belegung einer Teilmenge aller Schnittstellen in ihrem Nachbe-
reich bewirken soll. Für die verschiedenen Ablaufsituationen werden den Aktivitäten
einer Prozesslandschaft verschiedene Aktivierungsbedingungen und Regeln zur Folge-
markierung von Schnittstellen im Nachbereich zugeordnet. Für diesen Zweck werden
u.a. die für Petrinetze bereits bekannten Arten des deterministischen und komplexen
Schaltverhaltens [Gru91] verwendet. Während diese bei Gruhn jedoch als Bestandteil
von Jobs definiert sind (die wiederum Aktivitäten eines Softwareprozesses ausführen),
werden sie im Rahmen des Process Landscaping über ausgezeichnete Teilmengen der
Vor- und Nachbereiche einer Aktivität festgelegt, die je nach Ablaufsituation für ihre
Schaltfähigkeit und Schaltung genutzt werden. Es gibt mehrere Gründe für diese ver-
änderte Definition. Zum einen erleichtert sie die Einführung einer weiteren Art von
Schaltverhalten, die gleichzeitig auch mögliche Abhängigkeiten zwischen Teilmengen
der Vor- und Nachbereiche einer Aktivität berücksichtigt (vgl. Definition 3.2.26). Der-
artige Ablaufsituationen weisen einen Modellierer auf sinnvolle Stellen zur Verfeine-
103
Formale Basis des Process Landscaping
rung der Prozesslandschaft hin (vgl. Abschnitt 3.2.1.4). Zum anderen müssen Ablauf-
situationen, an denen externe Schnittstellen beteiligt sind, gesondert betrachtet werden,
um Konfliktsituationen zu vermeiden, die Synchronieaussagen erschweren oder sogar
verhindern. Auch dies fällt leichter, wenn bei der Definition eines Schaltverhaltens die
beteiligten Schnittstellen aus dem Vor- und Nachbereich einer betrachteten Aktivität
im Vordergrund stehen (vgl. Abbildungen 3.15 und 3.17 auf den Seiten 106 und 107).
Notation 3.2.13. Im Folgenden sei PN = (APN , S, ZPN ) ein kohärentes Petrinetz
und M : S → N eine Markierungsfunktion (kurz: Markierung), die jeder Schnittstelle
s ∈ S eine Anzahl von Marken zuordnet.
Bemerkung 3.2.14. Üblicherweise wird bei der Definition von markierten Netzen die-
sem immer eine feste Startmarkierung M
0
zugeordnet. Da diese im Rahmen des Pro-
cess Landscaping jedoch nicht benötigt wird, wird in den nachfolgenden Definitionen
darauf verzichtet.
Definition 3.2.15. Sei Ssource ,a ⊆ •a eine Teilmenge des Vorbereichs einer Aktivität
a ∈ APN . Die Aktivität a ∈ APN heißt schaltfähig :⇔
∀ s ∈Ssource ,a :M(s) ≥ 1 und
Ssource ,a = ∅
Definition 3.2.16. Eine Teilmenge Ssource ,a ⊆ •a für ein a ∈ APN heißt
Schaltmenge von a :⇔ a ist schaltfähig.
Die Menge (Hsource ,a) legt – mit der Menge aller möglichen Teilmengen des Vorbe-
reichs einer Aktivität als Elemente – die Menge aller Schaltmengen einer Aktivität
a ∈ APN fest:
(Hsource ,a) :=
{
Ssource ,a | Ssource,a ist Schaltmenge von a
}
Definition 3.2.17. Sei M(N) die Menge aller Markierungen eines kohärenten Petri-
netzes und M eine feste Markierung. Eine Aktivität a ∈ APN schaltet von M nach
M′, wenn a unter M schaltfähig ist und M′ aus M durch Entnahme von Marken aus
den Schnittstellen des Vorbereichs von a und Ablage von Marken auf Schnittstellen des
Nachbereichs von a entsteht. M′ heißt Folgemarkierung von M.
Definition 3.2.18. Eine Teilmenge Sdest ,a ⊆ a• für ein a ∈ APN heißt Ergebnismen-
ge von a :⇔
∀ s′ ∈ a• :M ′(s′) =
{
M(s′) + 1 falls s′ ∈ Sdest ,a
M(s′) sonst
und
Sdest ,a = ∅
104
3.2 Notation der unteren Ebenen einer Prozesslandschaft
Die Menge (Hdest ,a) legt – mit der Menge aller möglichen Teilmengen des Nachbe-
reichs einer Aktivität als Elemente – die Menge aller Ergebnismengen einer Aktivität
a ∈ APN fest:
(Hdest ,a) :=
{
Sdest ,a | Sdest ,a ist Ergebnismenge von a
}
Definition 3.2.19. Eine schaltfähige Aktivität a ∈ APN hat ein einfaches Eingangs-
schaltverhalten :⇔
1. |•a| ≥ 1
2. ∀Ssource ,a ∈ (Hsource ,a) : |Ssource ,a| = |•a |
3. ∀ s ∈ •a :M ′(s) =M(s)− 1
Eine Aktivität mit einem einfachen Eingangsschaltverhalten hat somit genau eine
Schaltmenge. Diese Schaltmenge ist mit dem Vorbereich der betrachteten Aktivität
identisch.
Definition 3.2.20. Eine schaltfähige Aktivität a ∈ APN hat ein einfaches Ausgangs-
schaltverhalten :⇔
1. |a•| ≥ 1
2. ∀Sdest ,a ∈ (Hdest ,a) : |Sdest ,a| = |a•|
3. ∀ s ∈ a• :M ′(s) =M(s) + 1
Hat eine Aktivität ein einfaches Ausgangsschaltverhalten, hat sie genau eine Ergeb-
nismenge. Diese Ergebnismenge ist mit dem Nachbereich der betrachteten Aktivität
identisch.
Definition 3.2.21. Eine schaltfähige Aktivität a ∈ APN hat ein deterministisches
Eingangsschaltverhalten :⇔
1. |•a| ≥ 2
2. ∀Ssource ,a ∈ (Hsource ,a) : |Ssource ,a| = 1
3. ∀ s ∈ •a ∃!Ssource ,a mit s ∈ Ssource ,a:M ′(s)=
{
M(s)− 1 falls s ∈ Ssource ,a
M(s) sonst
Die Zuordnung des deterministischen Eingangsschaltverhaltens ist eingeschränkt auf
diejenigen Aktivitäten, deren Vorbereich mehr als eine Schnittstelle umfasst. Zusätz-
lich wird gefordert, dass jede Schaltmenge genau eine Schnittstelle beinhaltet und so-
mit die Anzahl der verschiedenen Schaltmengen mit der Anzahl der Schnittstellen im
Vorbereich der korrespondierenden Aktivität übereinstimmt.
Ein deterministisches Eingangsschaltverhalten einer Aktivität lässt sich innerhalb ei-
nes Petrinetzes auch wie in Abbildung 3.14 darstellen [Gru91]. Die Bezeichnung XOR
105
Formale Basis des Process Landscaping
kennzeichnet dort das deterministische Eingangsschaltverhalten der Aktivität a
3
, und
die mit si bezeichneten Schnittstellen repräsentieren jeweils interne Schnittstellen. In
der äquivalenten Darstellung (vgl. rechte Seite der Abbildung 3.14) haben die Aktivi-
täten a
1
und a
2
eine gemeinsame Ergebnismenge.
XOR a3 si
si
sia2
a1
a3
a2
a1
~
=
Abbildung 3.14: Deterministisches Eingangsschaltverhalten bei internen Schnittstellen
si im Vorbereich einer Aktivität a3
Diese Form einer äquivalenten Darstellung ist nur für interne Schnittstellen gültig. Sie
ist für externe Schnittstellen weiter anzupassen, da ansonsten die Restriktionen für den
Vorbereich von externen Schnittstellen verletzt werden, für den gilt, dass er nur genau
eine Aktivität beinhalten darf (vgl. Definition 3.2.4, Seite 96). Abbildung 3.15 zeigt
diese Anpassung, bei der zwei Empfängeraktivitäten arecipient−1, arecipient−2 und eine
interne Schnittstelle si derart zwischengefügt sind, dass arecipient−1 den Nachbereich
der oberen externen Schnittstelle se und arecipient−2 den Nachbereich der unteren ex-
ternen Schnittstelle se bildet. Die beiden Empfängeraktivitäten haben das gleiche Ein-
gangsschaltverhalten wie die Aktivitäten a
1
und a
2
in Abbildung 3.14.
XOR a3
s
e
s
e
a2
a1
a3si
a
recipient-1se
s
e
a1
a2 arecipient-2
~
=
Abbildung 3.15: Deterministisches Eingangsschaltverhalten bei externen Schnitt-
stellen se im Vorbereich einer Aktivität a3
Definition 3.2.22. Eine schaltfähige Aktivität a ∈ APN hat ein deterministisches
Ausgangsschaltverhalten :⇔
1. |a• | ≥ 2
2. ∀Sdest ,a ∈ (Hdest ,a) : |Sdest ,a| = 1
3. ∀ s ∈ a• ∃!Sdest ,a mit s ∈ Sdest ,a:M ′(s)=
{
M(s) + 1 falls s ∈ Sdest ,a
M(s) sonst
106
3.2 Notation der unteren Ebenen einer Prozesslandschaft
Die Restriktionen für die Ergebnismengen bei einem deterministischen Ausgangs-
schaltverhalten sind analog zu denen für die Schaltmengen bei einem deterministi-
schen Eingangsschaltverhalten.
Durch ein deterministisches Eingangsschaltverhalten lässt sich eine Ablaufsituation
modellieren, bei der aus dem Vorbereich einer schaltfähigen Aktivität genau aus ei-
ner von mehreren Schnittstellen eine Marke entnommen wird. Analog wird durch ein
deterministisches Ausgangsschaltverhalten nur genau eine von mehreren vorhande-
nen Schnittstellen des Nachbereichs mit einer (weiteren) Marke belegt. Welcher der
Schnittstellen im Nachbereich von a durch die Folgemarkierung M′ eine Marke zuge-
ordnet wird, kann zufällig oder durch weitere Bedingungen festgelegt werden.
Ein deterministisches Ausgangsschaltverhalten einer Aktivität a
1
lässt sich äquivalent
auch als Konflikt darstellen [Gru91]. Abbildung 3.16 verdeutlicht diese Situation für
interne Schnittstellen innerhalb einer Prozesslandschaft.
XORa1 a1
si
si
a2
a3
~
= si
a2
a3
Abbildung 3.16: Deterministisches Ausgangsschaltverhalten bzgl. interner Schnitt-
stellen im Nachbereich einer Aktivität a
1
Diese Form einer äquivalenten Darstellung ist nur für interne Schnittstellen einer Pro-
zesslandschaft gültig. Sie ist für externe Schnittstellen weiter anzupassen, da sonst
analog zum Fall des deterministischen Eingangsschaltverhaltens die Restriktionen für
den Nachbereich von externen Schnittstellen verletzt werden. Die rechte Seite der
Abbildung 3.17 zeigt diese Anpassung, bei der, ähnlich dem Fall des deterministi-
schen Eingangsschaltverhaltens, eine interne Schnittstelle si und zwei Senderaktivitä-
ten asender−1, asender−2 als Nachbereich von si derart zwischengefügt sind, dass die
obere externe Schnittstelle se die Ergebnismenge von asender−1 bildet und die untere
externe Schnittstelle se die Ergebnismenge von asender−1. Beide Senderaktivitäten ha-
ben das gleiche Eingangsschaltverhalten wie die Aktivitäten a
2
und a
3
in Abbildung
3.16.
a3
a2
a1XORa1 si
s
e
s
e
a
sender-1
a
sender-2
s
e
s
e
a2
a3
~
=
Abbildung 3.17: Deterministisches Ausgangsschaltverhalten bzgl. externer Schnitt-
stellen im Nachbereich einer Aktivität a
1
107
Formale Basis des Process Landscaping
Definition 3.2.23. Eine schaltfähige Aktivität a ∈ APN hat ein komplexes Eingangs-
schaltverhalten :⇔
1. |•a| ≥ 2
2. ∀Ssource ,a ∈ (Hsource ,a) : |Ssource ,a| ≥ 1 ∧ |(Hsource ,a)| > 1
3. ∀ s ∈ •a ∃!Ssource ,a mit s ∈ Ssource ,a:M ′(s)=
{
M(s)− 1 falls s ∈ Ssource ,a
M(s) sonst
Analog zum deterministischen wird auch für das komplexe Eingangsschaltverhalten
gefordert, dass der Vorbereich der korrespondierenden Aktivität mehr als eine Schnitt-
stelle umfasst. Zusätzlich dürfen bei einem komplexen Eingangsschaltverhalten die
Schaltmengen mehr als eine Schnittstelle enthalten, und es müssen mindestens zwei
verschiedene, aber nicht notwendigerweise disjunkte Schaltmengen existieren.
Definition 3.2.24. Eine schaltfähige Aktivität a ∈ APN hat ein komplexes Ausgangs-
schaltverhalten :⇔
1. | a• | ≥ 2
2. ∀Sdest ,a ∈ (Hdest ,a) : |Sdest ,a| ≥ 1 ∧ |(Hdest ,a)| > 1
3. ∀ s ∈ a• ∃!Sdest ,a mit s ∈ Sdest ,a :M ′(s)=
{
M(s) + 1 falls s ∈ Sdest ,a
M(s) sonst
Bei einem komplexen Schaltverhalten einer Aktivität muss immer eine von mehreren
vorhandenen Schaltmengen im Vorbereich markiert sein bzw. eine von mehreren vor-
handenen Ergebnismengen im Nachbereich durch eine Folgemarkierung belegt wer-
den. Ein deterministisches Schaltverhalten stellt somit einen Spezialfall des komple-
xen Schaltverhaltens dar. Jedes komplexe Eingangsschaltverhalten lässt sich jedoch
auch durch eine Folge von einfachen Eingangsschaltverhalten ausdrücken. Gleiches
gilt für das komplexe Ausgangsschaltverhalten. Diese Rückführung vom komplexen
auf das einfache Schaltverhalten wird im Folgenden näher erläutert.
Abbildung 3.18 zeigt links eine Aktivität A mit komplexem Eingangsschaltverhalten.
Die verschiedenen vorhandenen Schaltmengen sind durch die gestrichelten Linien er-
kennbar. Insgesamt hat Aktivität A vier Schnittstellen in ihrem Vorbereich, die sich
in den vier verschiedenen Schaltmengen {a}, {b, c}, {c, d} und {d} wiederfinden.
Letztere sind so konstruiert, dass alle möglichen Kombinationen von Schaltmengen
vorkommen, nämlich
 Schaltmengen, die nur eine einzelne Schnittstelle enthalten,
 Schaltmengen, die Teilmenge einer anderen Schaltmenge sind und
 Schaltmengen, die gemeinsame Schnittstellen haben.
108
3.2 Notation der unteren Ebenen einer Prozesslandschaft
d
a
b
c
A
d
a
b
c
si A'
S 
source (a)
S 
source (b,c)
S 
source (c,d)
S 
source (d)
Abbildung 3.18: Rückführung eines komplexen auf ein einfaches Eingangsschalt-
verhalten
Die rechte Seite der Abbildung 3.18 zeigt, wie das komplexe Eingangsschaltverhalten
der Aktivität A durch eine Menge von Aktivitäten Si mit jeweils einfachem Ein- und
Ausgangsschaltverhalten dargestellt ist. Pro Schaltmenge der Aktivität A ist dort ei-
ne Aktivität Ssource(a), Ssource(b,c), Ssource(c,d) und Ssource(d) mit einfachem Ein- und
Ausgangsschaltverhalten modelliert, die genau eine der Schaltmengen als Vorbereich
und eine gemeinsame (neue) Schnittstelle si ∈ Sintern als Nachbereich hat. Diese
Schnittstelle si bildet den Vorbereich der Aktivität A′, die damit ebenfalls ein einfa-
ches Eingangsschaltverhalten aufweist. Die Aktivitäten A und A′ unterscheiden sich
damit lediglich durch ihre unterschiedlichen Vorbereiche; semantisch sind sie als iden-
tisch anzusehen.
Durch die Veränderung des Schaltverhaltens der Aktivität A mit Hilfe der Aktivitä-
ten Ssource(a), Ssource(b,c), Ssource(c,d) und Ssource(d) werden die Schaltmengen von A
teilweise den Vorbereichen mehrerer Aktivitäten zugeordnet. Diese Situation tritt im-
mer dann auf, wenn eine der beteiligten Schnittstellen in mehr als einer Schaltmenge
enthalten ist. Sind a, b, c und d externe Schnittstellen, so ist durch die Veränderung
die Restriktion gemäß Definition 3.2.4 auf Seite 96 verletzt worden, nach der externe
Schnittstellen nur genau eine Aktivität in ihrem Nachbereich haben dürfen. In diesem
Fall muss die in Abbildung 3.18 dargestellte Situation analog der in Abbildung 3.15
auf Seite 106 dargestellten Erweiterung mittels der Empfängeraktivitäten arecipient−1,
arecipient−2 und einer zusätzlichen internen Schnittstelle im Vorbereich der betreffen-
den Schnittstelle angepasst werden.
Wie sich das komplexe Ausgangsschaltverhalten einer Aktivität A durch eine Fol-
ge von einfachen Ausgangsschaltverhalten ausdrücken lässt, ist in Abbildung 3.19
dargestellt. Diese hat die Ergebnismengen {a, b}, {b, c} und {c, d} in ihrem Nach-
bereich. Analog zur Verfeinerung einer Aktivität mit komplexem Eingangsschaltver-
halten werden hier pro Ergebnismenge eine verfeinernde Aktivität Sdest(a,b), Sdest(b,c)
und Sdest(c,d) mit einfachem Ein- und Ausgangsschaltverhalten modelliert, wobei je-
de Aktivität genau eine der Ergebnismengen als Nachbereich und eine gemeinsame
109
Formale Basis des Process Landscaping
(neue) Schnittstelle si ∈ Sintern als Vorbereich hat. Die Aktivitäten A und A′ sind
wiederum als semantisch identisch anzusehen.
d
a
b
c
si
d
a
b
c
S dest (a,b)
S dest (b,c)
S dest (c,d)
A A'
Abbildung 3.19: Rückführung eines komplexen auf ein einfaches Ausgangsschalt-
verhalten
Falls {a}, {b}, {c} und/oder {d} externe Schnittstellen sind, können durch die Rück-
führung auch hier Situationen entstehen, die die Restriktionen aus Definition 3.2.4
verletzen. In diesen Fällen ist das Petrinetz entsprechend der in Abbildung 3.17 dar-
gestellten Erweiterung mittels der Senderaktivitäten ssender−1, ssender−2 und einer
zusätzlichen internen Schnittstelle im Vorbereich der betreffenden Schnittstelle anzu-
passen.
Das Wissen um die Rückführung eines komplexen auf ein einfaches Schaltverhalten
unterstützt einen Modellierer in zweierlei Hinsicht. Zum einen ist es bei der Verfei-
nerung einer Aktivität mit komplexem Schaltverhalten hilfreich, zum anderen soll ein
Modellierer bei der Erstellung der unteren Ebenen einer Prozesslandschaft nicht auf
diejenigen Petrinetz-Varianten beschränkt werden, die die Modellierung von komple-
xen Schaltverhalten unterstützen. Für letzteren Fall ist über die diskutierte Rückfüh-
rung eine Möglichkeit gegeben, nach dem Hinzufügen von ersten Ablaufinformationen
auch ohne die verschiedenen Schaltverhalten eine Prozesslandschaft detaillierter mo-
dellieren zu können.
Definition 3.2.25. Sei a ∈ APN eine Aktivität, für die gilt, dass |(Hsource ,a)| > 1
und |(Hdest ,a)| > 1. Sei weiterhin DEPa ⊆ (Hsource ,a) × (Hdest ,a) Teilmenge des
Kreuzproduktes der Schalt- und Ergebnismengen der Aktivität a. Die Relation DEPa
definiert Abhängigkeiten zwischen der Belegung von Schalt- und Ergebnismengen ei-
ner Aktivität a :⇔
∀Ssource ,a ∈ (Hsource ,a)∃Sdest ,a ∈ (Hdest ,a) : (Ssource ,a, Sdest ,a) ∈ DEPa
Über DEPa wird für eine Aktivität a ∈ APN festgelegt, welche Ergebnismenge
Sdest ,a ∈ (Hdest ,a) bei der Belegung welcher Schaltmenge Ssource ,a ∈ (Hsource ,a)
nach dem Schalten mit Marken belegt wird.
110
3.2 Notation der unteren Ebenen einer Prozesslandschaft
Definition 3.2.26. Eine schaltfähige Aktivität a ∈ APN hat ein von der Belegung ihres
Vorbereiches abhängiges Ausgangsschaltverhalten :⇔
1. |a• | > 1 ∧ |•a | > 1
2. ∀Sdest ,a ∈ (Hdest ,a) : |Sdest ,a| ≥ 1 ∧ |(Hdest ,a)| > 1
3. ∀Ssource ,a ∈ (Hsource ,a) : |Ssource ,a| ≥ 1 ∧ |(Hsource ,a)| > 1
4. ∀ s ∈ a• ∃!Sdest ,a mit s ∈ Sdest ,a :M ′(s) =
{
M(s) + 1 falls s ∈ Sdest ,a
M(s) sonst
5. ∀Ssource ,a ∈ (Hsource ,a)∃Sdest ,a ∈ (Hdest ,a) : (Ssource ,a, Sdest ,a) ∈ DEPa
6. |DEPa| > 1
Die Bedingungen 1. bis 4. fordern ein komplexes Ein- und Ausgangsschaltverhalten
der Aktivität a. Des Weiteren muss jeder Schaltmenge genau eine Ergebnismenge zu-
geordnet werden, die nach dem Schalten der Aktivität a mit einer (weiteren) Marke
belegt wird (Bedingung 5.). Außerdem wird mit Bedingung 6. gefordert, dass DEPa
mindestens zwei Elemente enthält.
Für die Betrachtung des dynamischen Verhaltens einer Prozesslandschaft mit Hilfe der
Ein- und Ausgangsschaltverhalten aller Aktivitäten ist gemäß der Definitionen 3.2.19
bis 3.2.26 grundsätzlich immer festzulegen, welche Teilmengen aus dem Vor- bzw.
Nachbereich mögliche Schalt- bzw. Ergebnismengen sind. Da hierfür keine allgemein-
gültigen und kontextunabhängigen Aussagen gemacht werden können, muss ein Mo-
dellierer in Abhängigkeit der modellierten Situationen das jeweilige Schaltverhalten
(neu) definieren. Auf der Petrinetzebene ergibt sich somit in Abhängigkeit der Anzahl
von Schaltmengen einer Aktivität und ihren Relationen zueinander eine konkrete Form
des Eingangsschaltverhaltens. Analoges gilt für das Ausgangsschaltverhalten.
Definition 3.2.27. Sei PN = (APN , S, ZPN ) ein kohärentes Petrinetz. Die Abbildung
fsource ordnet jeder Aktivität a ∈ APN ein Eingangsschaltverhalten zu:
fsource : APN → {all , det , complex}
Dabei bezeichnet all das einfache, det das deterministische und complex das komple-
xe Schaltverhalten.
Definition 3.2.28. Sei PN = (APN , S, ZPN ) ein kohärentes Petrinetz. Die Abbildung
fdest ordnet jeder Aktivität a ∈ APN ein Ausgangsschaltverhalten zu:
fdest : APN → {all , det , complex , dependent}
Dabei bezeichnet dependent das abhängige Schaltverhalten.
Mit den Markierungsfunktionen M und M′ sowie den Abbildungen fsource und fdest
ist das einer Prozesslandschaft zugrundeliegende Petrinetz um Eigenschaften ergänzt
worden, die die Beschreibung dynamischen Verhaltens erlauben. Damit führen diese
Ergänzungen zur nächsten Ausbaustufe einer Prozesslandschaft.
111
Formale Basis des Process Landscaping
Definition 3.2.29. Sei PLtop−com = (A,S,Z,AB) die zweite Ausbaustufe einer Pro-
zesslandschaft und PLtop−com kohärent. Seien weiterhin
• M : S → N und M ′ : S → N Markierungsfunktionen, die jeder Schnittstelle
eine Anzahl von Marken zuordnen,
• fsource eine Abbildung zur Festlegung des Eingangsschaltverhaltens gemäß De-
finition 3.2.27 und
• fdest eine Abbildung zur Festlegung des Ausgangsschaltverhaltens gemäß Defi-
nition 3.2.28.
Die dritte Ausbaustufe einer Prozesslandschaft ist definiert als ein Tupel
PLbottom := (PLtop−com ,M,M
′, fsource , fdest )
Bemerkung 3.2.30. Der Index bottom der Prozesslandschaft PLbottom deutet an, dass
es sich um eine Prozesslandschaft handelt, deren untere Ebenen im Mittelpunkt der
Modellierung stehen.
Notation 3.2.31. Wenn keine Missverständnisse auftreten können, wird im Folgenden
eine Prozesslandschaft PLbottom= (PLtop−com ,M,M ′,K, fsource , fdest ) verkürzt als
Prozesslandschaft PLbottom = (A,S,Z,AB) bezeichnet.
Nach der Zuordnung der Schaltverhalten zu allen Aktivitäten einer Prozesslandschaft
können aus Gründen der Übersichtlichkeit noch diejenigen Schnittstellen inklusive ih-
rer zugehörigen Zugriffe entfernt werden, die bei keinem Schaltverhalten Berücksich-
tigung gefunden haben und somit in keiner Ergebnismenge liegen.
Definition 3.2.32. Sei PN = (APN , S, ZPN ) ein kohärentes Petrinetz. Sei weiter
(Hdest ,A
P N
) :=
⋃
a∈A
P N
(Hdest ,a)
die Menge aller Ergebnismengen eines kohärenten Petrinetzes. Eine Schnittstelle s∈ S
heißt relevant:⇔
s• = ∅ ∨ •s = ∅ ∨ ∃Sdest ,a ∈ (Hdest ,A
P N
) : s ∈ Sdest ,a
Eine Schnittstelle wird also als relevant bezeichnet, wenn sie in mindestens einer Er-
gebnismenge liegt oder ihr Vor- oder Nachbereich leer ist. Im letzten Fall wird s als
Randstelle bezeichnet.
Definition 3.2.33. Sei PN = (APN , S, ZPN ) ein kohärentes Petrinetz. Die Menge
Srelevant := {s | s ist relevant}
bezeichnet die Menge aller relevanten Schnittstellen innerhalb eines kohärenten Petri-
netzes PN = (APN , S, ZPN ).
112
3.2 Notation der unteren Ebenen einer Prozesslandschaft
Die Menge der irrelevanten Schnittstellen enthält diejenigen Schnittstellen, die durch
die Konstruktion des kohärenten Petrinetzes entstanden sind, um die Darstellung aller
möglichen Datenflüsse sicherzustellen, die aber in keiner realen Ablaufsituation benö-
tigt werden, also weder in einer Schalt- noch in einer Ergebnismenge enthalten sind.
Werden sie inklusive ihrer zugehörigen Zugriffe wieder aus einer Prozesslandschaft
entfernt, können sich für die korrespondierenden Aktivitäten Änderungen der Schalt-
verhalten ergeben. Aus einem komplexen Schaltverhalten kann so beispielsweise ein
einfaches oder ein deterministisches Schaltverhalten werden. Die Eliminierung der ir-
relevanten Schnittstellen ist nicht zwingend erforderlich, da die korrespondierenden
Ablaufsituationen bei einer Analyse nicht berücksichtigt werden. Dieser Schritt er-
leichtert jedoch die Analyse durch die Verringerung der Komplexität der dargestellten
Prozesslandschaft.
In Tabelle 3.4 sind die Ein- und Ausgangsschaltverhalten der Aktivitäten Anforde-
rungsanalyse erstellen, Geschäftsprozess modellieren, technische Komponentenanfor-
derungen erstellen und Reviewdurchführung aus der Beispielprozesslandschaft (vgl.
Abbildung 3.13 auf Seite 102) aufgeführt. Alle weiteren in Abbildung 3.13 abgebilde-
ten Aktivitäten werden in der nachfolgenden Diskussion nicht weiter berücksichtigt.
Den jeweiligen Schaltverhalten sind die konkreten Schalt- und Ergebnismengen
zugeordnet. Bei einem abhängigen Ausgangsschaltverhalten sind zusätzlich die
Elemente depi ∈ DEPa aufgeführt, die die Relationen zwischen Schalt- und Ergeb-
nismengen beschreiben. Die verschiedenen Bestandteile einer Spalte sind – analog
zur Spaltenüberschrift – jeweils durch einen Schrägstrich voneinander getrennt.
Aktivität Eingangsschaltverhalten/ Ausgangsschaltverhalten/
Schaltmengen Ergebnismengen/
Abhängigkeitsrelationen
Anforderungs- complex
/
dependent
/
analyse {17}, {3
1
, 15
2
, 17}, {3
1
, 26
1
} {3
1
, 30}, {3
1
, 3
5
}, {3
1
, 3
2
, 3
3
, 3
4
, 3
6
}
/
erstellen {17} × {3
1
, 30}, {3
1
, 15
2
, 17} × {3
1
, 3
5
},
{3
1
, 26
1
} ×
{
{3
1
, 3
5
}, {3
1
, 3
2
, 3
3
, 3
4
, 3
6
}
}
Geschäftsprozess det
/
all
modellieren {30}, {15
1
}
technische complex
/
dependent
/
Komponenten- {3
2
, 11
2
}, {8
1
, 9
1
} {8
1
, 8
3
}, {8
2
}
/
anforderungen {3
2
, 11
2
} × {8
1
, 8
3
},
erstellen {8
1
, 9
1
} ×
{
{8
1
, 8
3
}, {8
2
}
}
Review- det
/
complex
/
durchführung {3
5
}, {8
3
}, {11
4
} {26
1
, 26
2
}, {9
1
, 9
2
}
Tabelle 3.4: Ein- und Ausgangsschaltverhalten der Aktivitäten aus der Beispiel-
prozesslandschaft
113
Formale Basis des Process Landscaping
Abbildung 3.20 zeigt den Ausschnitt der Prozesslandschaft aus Abbildung 3.13, de-
ren Struktur durch die Konstruktion des kohärenten Petrinetzes und die Zuordnung der
verschiedenen Schaltverhalten entstanden ist. Diese Schaltverhalten sind aus Grün-
den der Übersichtlichkeit in der Abbildung nicht explizit dargestellt, sondern nur in
Tabelle 3.4 aufgeführt. Gleichzeitig ist zum besseren Überblick auch von allen bei der
Zuordnung der Schaltverhalten nicht weiter berücksichtigten Aktivitäten abstrahiert
worden. Damit ist neben den ursprünglich betrachteten drei Aktivitäten zusätzlich die
Aktivität Reviewdurchführung in den Mittelpunkt der Beispielbetrachtung gerückt. Sie
wird in Abschnitt 3.2.1.4 noch detaillierter diskutiert werden.
31
32
152
35
36
82
81
83
153
Anforderungs-
analyse erstellen
Geschäfts-
prozess
modellieren
technische Komponenten-
anforderungen erstellen
Review-
durchführung
151
33
34
technische Komponentenanforderung81, 82 , 83
Geschäftsprozessmodell151,152, 153
Anforderungsdokument31,..., 36
Review Anforderungsdokument
262
261
17
erste Anforderungen17
261, 262
112
Systemarchitektur112
30
Anfrage nach Geschäftsprozessmodell30
Review technische Komponentenanforderung91, 92
91
92
Abbildung 3.20: Kohärente Beispielprozesslandschaft mit zugeordneten Schalt-
verhalten
114
3.2 Notation der unteren Ebenen einer Prozesslandschaft
3.2.1.3 Anpassung der Verfeinerungskonzepte für die Modellierung der unteren
Ebenen einer Prozesslandschaft
Im Folgenden werden Erweiterungen diskutiert, die eine Modellierung von Prozessen
(als Ablauf sequentieller und paralleler Aktivitäten) und Informationen (als möglicher-
weise unterschiedliche Informationstypen) sowie ihre Beziehungen zueinander erlau-
ben. Ergänzungen weiterer Informationen erfolgen unter anderem mittels Verfeinerun-
gen und Erweiterungen der Landschaft, wie sie bereits in Abschnitt 3.1.1 eingeführt
worden sind. Das Konzept der Verfeinerung muss jedoch für die unteren Ebenen einer
Prozesslandschaft um zusätzliche Bedingungen ergänzt werden, um die Restriktionen
für externe Schnittstellen zu erfüllen. Die Notwendigkeit dieser Anpassung ist bereits
zu Beginn des Abschnitts 3.2.1 motiviert worden. Das Analyseziel, Synchronieaussa-
gen in einer verteilten Prozesslandschaft machen zu können, hat dort die Unterschei-
dung in interne und externe Schnittstellen (vgl. Definition 3.2.4, Seite 96) zur Folge
gehabt.
Konsistenzbedingung 3.2.34. Sei PLbottom = (A,S,Z,AB) die dritte Ausbaustufe
einer Prozesslandschaft mit S = Sintern ∪ Sextern. Bei der Verfeinerung PL′bottom =
(A′, S′, Z ′, AB′) einer Prozesslandschaft PLbottom bezüglich einer Aktivität a mit
S′ = S′intern ∪ S
′
extern müssen zusätzlich zu den in Definition 3.1.14 formulierten
die folgenden Bedingungen für die externen Schnittstellen erfüllt sein:
1. ∀ s ∈ •a ∪ a• : s ∈ S′extern
2. Sextern ⊂ S′extern
Bedingung 1. impliziert eine wichtige Vorbedingung für die Verfeinerung von Pro-
zesslandschaften: Soll eine Prozesslandschaft PLbottom bezüglich einer Aktivität a
verfeinert werden, müssen zuvor alle Schnittstellen aus ihrem Vor- und Nachbereich
als externe Schnittstellen deklariert werden. Dies kann eine Änderung der Modellie-
rung derart erfordern, dass die Prozesslandschaft zur Erfüllung der Restriktionen für
externe Schnittstellen vor dem Verfeinerungsschritt angepasst werden muss.
Beispiel:
Abbildung 3.21 zeigt die Aktivität Release erstellen (CE), eine verfeinernde Aktivi-
tät des Konfigurationsmanagement (CE). Anhand der fett umrandeten Schnittstellen
Releaseplanung und installiertes Softwaresystem lässt sich leicht erkennen, dass noch
weitere Aktivitäten auf den Vorbereich von Release erstellen (CE) zugreifen.
Soll die Aktivität Release erstellen (CE) detaillierter modelliert werden, muss ihr Vor-
bereich zunächst entsprechend dem ersten Teil der Konsistenzbedingung 3.2.34 an-
gepasst werden. Dies geschieht mit Hilfe der (hier nicht abgebildeten) Dokumenten-
sichten der betroffenen Schnittstellen, aus denen ersichtlich wird, dass insgesamt fünf
verschiedene Aktivitäten auf die Schnittstelle Releaseplanung und insgesamt sechs
verschiedene Aktivitäten auf die Schnittstelle installiertes Softwaresystem zugreifen.
115
Formale Basis des Process Landscaping
Release
erstellen (CE)
35
27
36
27   installiertes Softwaresystem
35   Releaseplanung
36   Konfiguration
Abbildung 3.21: Aktivität Release erstellen zusammen mit ihrem Vor- und Nach-
bereich
Abbildung 3.22 zeigt das Ergebnis der Anpassungen gemäß der Restriktionen für ex-
terne Schnittstellen, die durch Duplizieren der beiden Schnittstellen installiertes Soft-
waresystem und Releaseplanung realisiert worden sind. Durch diese Form der Anpas-
sung hat sich gleichzeitig die Ergebnismenge der beiden Aktivitäten Releaseplanung
(CE) und System installieren vergrößert, die schreibend auf jeweils eine der betrof-
fenen Schnittstellen zugreifen. Dies kann wiederum eine Anpassung ihres Schaltver-
haltens notwendig machen. Insgesamt erfordern die Anpassungsschritte somit neben
der Konsistenzsicherung für externe Schnittstellen auch eine Festlegung der Verfei-
nerungsreihenfolge von Landschaftselementen – konkret der Duplizierung beteiligter
Schnittstellen vor der Verfeinerung zugreifender Aktivitäten – und eine mögliche Neu-
festlegung der Ausgangsschaltverhalten vorgelagerter Aktivitäten.
Release
erstellen (CE) 36
27   installiertes Softwaresystem
35   Releaseplanung
36   Konfiguration
Release-
planung (CE)
System
installieren
35
27
35
35
27
27
27
35
27
Abbildung 3.22: Anpassungen der Prozesslandschaft als Voraussetzung der
Verfeinerung der Aktivität Release erstellen (CE)
116
3.2 Notation der unteren Ebenen einer Prozesslandschaft
Am gerade diskutierten Beispiel wird ein weiterer wesentlicher Unterschied zur tradi-
tionellen Verfeinerung von Petrinetzen deutlich: Beim Process Landscaping kann ei-
ne Verfeinerung Auswirkungen auf den Vor- und Nachbereich einer zu verfeinernden
Aktivität und sogar auf das Schaltverhalten der im Ablauf vor- bzw. nachgelagerten
Aktivitäten haben. Damit beschränkt sich die Verfeinerung im Gegensatz zur traditio-
nellen Verfeinerung nicht mehr nur auf eine einzelne Transition, sondern auch auf ihre
Umgebung. Die Einhaltung einer festen Reihenfolge von Verfeinerungsschritten wird
dadurch um so wichtiger.
Konsistenzbedingung 3.2.35. Sei PLbottom = (A,S,Z,AB) die dritte Ausbaustufe
einer Prozesslandschaft mit S = Sintern ∪ Sextern. Bei der Verfeinerung PL′bottom =
(A′, S′, Z ′, AB′) einer Prozesslandschaft PLbottom bezüglich einer externen Schnitt-
stelle s und S′ = S′intern ∪ S′extern muss zusätzlich zu den in Definition 3.1.14 for-
mulierten die folgende Bedingung für die internen und externen Schnittstellen erfüllt
sein:
S′intern = Sintern
Die Bedingung fordert, dass die Menge der internen Schnittstellen in der verfeinernden
Prozesslandschaft unverändert bleibt, eine externe Schnittstelle damit ausschließlich
durch externe Schnittstellen verfeinert werden darf.
Für die Verfeinerung von Schnittstellen auf den unteren Ebenen einer Prozessland-
schaft ist das zugehörige Verfeinerungskonzept damit im Vergleich zur traditionellen
Vorgehensweise noch weiter eingeschränkt worden, da auf den unteren Ebenen nicht
mehr alle, sondern nur noch die externen Schnittstellen verfeinert werden dürfen. In-
terne Schnittstellen müssen damit vor einer möglichen Verfeinerung zunächst an die
Restriktionen der externen angepasst werden. Dies geschieht analog zum diskutierten
Beispiel der Verfeinerung der Prozesslandschaft bezüglich einer Aktivität durch ihre
Duplizierung.
Systemarchitektur
erstellen
Wiederverwendungs-
repository verwalten
Systemarchitektur
erstellen
Wiederverwendungs-
repository verwalten
113
111
112
112 Komponentenschnittstelle
11
111 Komponentenkopplung
113 Client-/Server-Aufteilung
11 Systemarchitektur
Abbildung 3.23: Verfeinerung einer externen Schnittstelle
117
Formale Basis des Process Landscaping
Abbildung 3.23 zeigt ein Beispiel, bei dem die Schnittstelle Systemarchitektur
durch die drei Schnittstellen Komponentenkopplung, Komponentenschnittstellen und
Client/Server-Aufteilung verfeinert worden ist.
Für die Verfeinerung einer Prozesslandschaft bezüglich einer Aktivität ist das zugehö-
rige Verfeinerungskonzept mit einer weiteren Konsistenzbedingung zu versehen:
Konsistenzbedingung 3.2.36. Sei PLbottom = (A,S,Z,AB) die dritte Ausbaustufe
einer Prozesslandschaft. Bei der Verfeinerung PL′bottom = (A′, S′, Z ′, AB′) einer
Prozesslandschaft PLbottom bezüglich einer Aktivität a mit A′ = A∪{a1, ..., an} und
A ∩ {a
1
, ..., an} = ∅, n ≥ 2 muss zusätzlich zu den in Definition 3.1.14 formulierten
die folgende Bedingung für die Menge Z′ der Zugriffe erfüllt sein:
∀ 1 ≤ i ≤ n :({ai} × S) ∩ Z ′ = ∅∧
(S × {ai}) ∩ Z ′ = ∅
Diese Konsistenzbedingung sichert den vollständigen Zusammenhang des der verfei-
nerten Prozesslandschaft PL′bottom zugrundeliegenden Petrinetzes. Ein solcher Zu-
sammenhang war für die oberen Ebenen aufgrund der fehlenden Ablaufinformatio-
nen nicht notwendig. Für die oberen Ebenen einer Prozesslandschaft war deshalb in
Definition 3.1.14 lediglich gefordert, dass keine im Rahmen der Verfeinerung zusätz-
lich modellierte Schnittstelle isoliert ist. Für die verfeinernden Aktivitäten ai war dies
jedoch nicht gefordert.
Mit den diskutierten Konsistenzbedingungen sind die für die oberen Ebenen einer Pro-
zesslandschaft definierten Konzepte der Verfeinerung von Aktivitäten und Schnittstel-
len auch für die unteren Ebenen einsetzbar. Damit ist gewährleistet, dass für die in
Abschnitt 1.1 identifizierte Problemstellung – die mangelnde durchgängige Model-
lierungsunterstützung sowohl auf sehr abstraktem als auch auf sehr detailliertem Ni-
veau – ein für alle Landschaftsebenen einheitliches Verfeinerungskonzept angewendet
werden kann. Insgesamt ist somit für die in Abschnitt 2.2 diskutierten Modellierungs-
schritte des Process Landscaping eine umfassende formale Basis beschrieben.
3.2.1.4 Sonderfälle
Die in den vorangegangenen Abschnitten 3.2.1.1 und 3.2.1.2 durchgeführten Schritte
reichen nicht immer aus, um den Kontext einer Prozesslandschaft in Bezug auf ihr Ab-
laufverhalten verständlich abzubilden. Wenn dieser Kontext eine konkrete Reihenfolge
der Belegung verschiedener Ergebnismengen erfordert, kann bei einem nicht einfachen
Ausgangsschaltverhalten die zufällige Auswahl einer von mehreren Ergebnismengen
dazu führen, dass nicht alle modellierten Pfade durchlaufen werden können, obwohl
dies aber im Rahmen der modellierten Ablaufsituation erforderlich wäre. Beispiels-
weise sollte in Abbildung 3.20 auf Seite 114 das Anforderungsdokument immer zuerst
von der Aktivität Reviewdurchführung begutachtet werden, bevor es an die Aktivität
technische Komponentenanforderungen erstellen weitergeleitet wird. Derartige Situa-
tionen sind dadurch entstanden, dass auf den oberen Ebenen einer Prozesslandschaft
118
3.2 Notation der unteren Ebenen einer Prozesslandschaft
keine Ablaufinformationen modelliert sind und ihr Hinzufügen auf den unteren Ebe-
nen bislang ausschließlich durch syntaktische Regeln erfolgt ist. Dies ermöglicht dem
Modellierer zwar einen einfachen und konsistenten Übergang zu den unteren Ebenen,
kann aber teilweise auch zu der gerade beispielhaft beschriebenen Situation führen.
Für die Handhabung derartiger Fälle werden im Folgenden spezielle Situationen dis-
kutiert. Dies sind im Einzelnen:
 Sonderfall Zusammengefasste Aktivität (Eine Aktivität A empfängt – über ein
komplexes Eingangsschaltverhalten – verschiedene Informationstypen und be-
legt in Abhängigkeit vom Eingangsschaltverhalten genau eine von mehreren dis-
junkten Ergebnismengen im Nachbereich, weist also ein abhängiges Ausgangs-
schaltverhalten auf.)
 Sonderfall Zwei-Phasen-Aktivität (In der ersten Phase wird nur eine Teilmenge
aller Schnittstellen im Vorbereich einer Aktivität A als Schaltmenge verwendet,
in der zweiten Phase müssen alle Schnittstellen im Vorbereich belegt sein. Da
diese vollständige Belegung aber von A selbst in der ersten Phase über eine ge-
sonderte Ergebnismenge initiiert wird, liegt auch in diesem Fall ein abhängiges
Ausgangsschaltverhalten vor.)
 Sonderfall Vier-Augen-Prinzip (Auch hier liegt ein abhängiges Ausgangsschalt-
verhalten vor. Dieser Fall ähnelt der Zwei-Phasen-Aktivität insofern, als Aktivi-
tät A ebenfalls mehrfach ausgeführt werden kann, jedoch unter anderen Voraus-
setzungen für die vorhandenen Schnittstellen im Vorbereich.)
Die genannten Sonderfälle werden zunächst abstrakt diskutiert, anschließend in der
Beispielprozesslandschaft (Abbildung 3.20, Seite 114) aufgezeigt und die entspre-
chend notwendigen Anpassungen zur Sicherstellung einer eindeutigen Darstellung
des Ablaufverhaltens vorgenommen.
Zusammengefasste Aktivität:
Abbildung 3.24 stellt den Sonderfall einer zusammengefassten Aktivität dar. Die Ak-
tivität A hat ein deterministisches Eingangs- und ein abhängiges Ausgangsschaltver-
halten, wobei das deterministische Eingangsschaltverhalten – wie bereits erwähnt –
einen Spezialfall des komplexen Eingangsschaltverhaltens darstellt.A belegt nach dem
Schalten in Abhängigkeit der Schaltmenge im Vorbereich jeweils eine andere Ergeb-
nismenge in ihrem Nachbereich. Die bei der Ausführung der Aktivität verwendeten
und erzeugten Informationstypen gehören also paarweise zueinander. Des Weiteren
gilt, dass die Schaltmengen paarweise disjunkt sind. Formal:
 fsource(A) = det mit
Ssource ,A−1 = {a}, Ssource ,A−2 = {b}, Ssource ,A−3 = {c}
 fdest(A) = dependent mit
Sdest ,A−1 = {d}, Sdest ,A−2 = {e}, Sdest ,A−3 = {f}
119
Formale Basis des Process Landscaping
 DEPA = ({a} × {d}, {b} × {e}, {c} × {f})
 |(Hsource ,A)| = |(Hdest ,A)| > 1
Die Forderung, dass die Anzahl der Schalt- und Ergebnismengen größer eins sein
muss, ergibt sich aus dem abhängigen Ausgangsschaltverhalten der Aktivität A (vgl.
Definition 3.2.26, Seite 111). In Abhängigkeit der Anzahl vorliegender Ergebnismen-
gen kann jede Aktivität A durch eine entsprechende Menge von Teilaktivitäten Ai
verfeinert werden.
A
a
b
c
d
e
f
a A1 d
b A2 e
c A3 f
Review
durchführen
Review
durchführen
Review
durchführen
Review
durchführen
Reviewergebnisse
Dokumentea,b,c
d,e,f
Abbildung 3.24: Zusammengefasste Aktivität
Durch eine Verfeinerung von A entsteht eine semantisch sinnvolle Verfeinerung, wie
sie rechts in Abbildung 3.24 dargestellt ist. Die Aktivität A wurde hier durch die
Aktivitäten A
1
, A
2
und A
3
verfeinert. Diesen wird jeweils das einfache Eingangs- und
Ausgangsschaltverhalten zugeordnet. Als Beispiel für eine konkrete Situation dieses
Sonderfalls ist in der Abbildung eine Reviewtätigkeit dargestellt, die in Abhängigkeit
vom Vorhandensein eines Dokumentes a, b oder c eines der Reviewergebnisse d, e
oder f produziert.
Zwei-Phasen-Aktivität:
Eine Zwei-Phasen-Aktivität zeichnet sich dadurch aus, dass die vollständige Durch-
führung der ihr zugewiesenen Operationen von dem Ergebnis einer zweiten Aktivität
abhängt. Die linke Seite der Abbildung 3.25 zeigt eine solche Situation.
Die Aktivität A hat ein komplexes Eingangs- und ein abhängiges Ausgangsschaltver-
halten, ihre Ergebnismengen sind disjunkt. Es gilt:
 fsource(A) = complex mit
Ssource ,A−1 = {a}, Ssource ,A−2 = {a, c}
 fdest(A) = dependent mit
Sdest ,A−1 = {b}, Sdest ,A−2 = {d}
 DEPA = ({a} × {b}, {a, c} × {d})
120
3.2 Notation der unteren Ebenen einer Prozesslandschaft
c
B
b
A
da
erzeugen
erzeugen
Anfragedokument
Anfrageergebnis
Ergebnisdokument
Auftragsdokumenta, a 
copy
b
c
d
a A1 b B c
a dA2
erzeugen erzeugen
copy erzeugen
Abbildung 3.25: Zwei-Phasen-Aktivität
In einer ersten Phase schaltet A aufgrund eines an der Schnittstelle a vorliegenden
(gleichnamigen) Informationsobjektes. Die Erzeugung des Informationsobjektes d ist
jedoch abhängig vom Vorliegen des Informationsobjektes c, welches durch die Akti-
vität B erzeugt wird. Dazu erzeugt A zunächst das Informationsobjekt b, Aktivität B
kann schalten und c erzeugen. In einer zweiten Phase kann A schließlich d erzeugen.
Um die zeitliche Abhängigkeit der beiden Durchläufe transparent zu machen, wird
Aktivität A durch die Aktivitäten A
1
und A
2
verfeinert.
Damit ist analog zur zusammengefassten Aktivität auch bei der Zwei-Phasen-Aktivität
eine Abhängigkeit zwischen Schalt- und Ergebnismengen identifiziert. Eine analoge
Verfeinerung ist jedoch nicht direkt möglich, da ein in der Schnittstelle a vorliegender
Informationstyp für den Durchlauf beider Phasen benötigt wird. Das zugrundeliegen-
de Petrinetz wird daher um eine interne Schnittstelle acopy – eine lokale Kopie der
externen Schnittstelle a – erweitert, auf die die Aktivität A sowohl lesend als auch
schreibend zugreift. Nach dieser Erweiterung kann eine Verfeinerung der Aktivität A
analog zur zusammengefassten Aktivität durchgeführt werden.
Zur Identifikation einer Zwei-Phasen-Aktivität A reicht damit das Vorhandensein ei-
nes abhängigen Ausgangsschaltverhaltens nicht aus. Es muss auch eine Wechselbezie-
hung zu einer zweiten Aktivität B vorhanden sein. Für diese muss eine Schaltmenge
Ssource ,B identisch mit einer Ergebnismenge Sdest ,A der Aktivität A sein. Umgekehrt
muss eine Ergebnismenge Sdest ,B der Aktivität B identisch mit einer Schaltmenge
Ssource ,A der Aktivität A sein oder zumindest Ssource ,A als Teilmenge enthalten.
Definition 3.2.37. Sei PN = (APN , S, ZPN ) ein kohärentes Petrinetz. Eine Aktivität
a ∈ APN ist eine Zwei-Phasen-Aktivität :⇔
1. fsource(a) = complex
2. fdest(a) = dependent
3. ∃Sdest ,a ∈ (Hdest ,a), b ∈ A,Ssource ,b ∈ (Hsource ,b) : Sdest ,a ⊇ Ssource ,b
4. ∃Ssource ,a ∈ (Hsource ,a), b ∈ A,Sdest ,b ∈ (Hdest ,b) : Ssource ,a ⊇ Sdest ,b
121
Formale Basis des Process Landscaping
Die rechte Seite der Abbildung 3.25 zeigt die entsprechende Anpassung bzw.
Verfeinerung des Sonderfalls Zwei-Phasen-Aktivität: Aktivität A
1
erzeugt das In-
formationsobjekt b sowie eine Kopie des Informationsobjektes a. Für Letzteres
ist das zugrundeliegende Petrinetz um eine Schnittstelle acopy und zwei Zugriffe
(A
1
, acopy) und (acopy, A2) erweitert worden, über die die Aktivitäten A1 und A2
das Informationsobjekt a austauschen. Liegt b in der gleichnamigen Schnittstelle
vor, kann Aktivität B das Objekt c erzeugen. Die Schnittstellen c und acopy bilden
schließlich die Schaltmenge für Aktivität A
2
, so dass bei deren Belegung A
2
schalten
und das erzeugte Informationsobjekt d auf der entsprechenden Schnittstelle abgelegt
werden kann. Den Aktivitäten A
1
und A
2
ist jeweils ein einfaches Ein- und Ausgangs-
schaltverhalten zugeordnet.
Vier-Augen-Prinzip:
Der obere Teil der Abbildung 3.26 zeigt den Sonderfall des Vier-Augen-Prinzips.
Bei diesem erzeugt die Aktivität A das Informationsobjekt b und speichert es in den
Schnittstellen b
1
und b
2
bzw. b
3
. Bevor es von Aktivität B verwendet werden kann,
muss es von Aktivität C geprüft werden. In Abhängigkeit des Prüfungsergebnisses
(Informationsobjekt c) überarbeitet Aktivität A das Informationsobjekt b noch einmal
und stellt es entweder Aktivität C für eine erneute Prüfung zur Verfügung oder gibt es
Aktivität B zur weiteren Verwendung weiter.
b1 A b3
B
Cr
A1 b3
nach Prüfung
verwenden
Review
durchführen
erzeugen/
verbessern
erzeugen
a
b1, b2, b3, b3, copy
Startdokument
erzeugtes Dokument
Review
durchführen
C r
verbessern
b3 A2 b2 BE
senden
b2
a
a
b1
r Reviewergebnis
copy
nach Prüfung
verwenden
Abbildung 3.26: Vier-Augen-Prinzip
122
3.2 Notation der unteren Ebenen einer Prozesslandschaft
Für das Schaltverhalten der Aktivität A gilt:
 fsource(A) = complex mit
Ssource ,A−1 = {a}, Ssource ,A−2 = {b1, r}
 fdest(A) = dependent mit Sdest ,A−1 = {b1, b3}, Sdest ,A−2 = {b2}
 DEPA = ({a} × {b1, b3}, {b1, r} ×
{
{b
1
, b
3
}, {b
2
}
}
)
Damit ist auch für diesen Sonderfall eine Abhängigkeit zwischen Schalt- und Ergeb-
nismengen gegeben, und eine entsprechende Verfeinerung der Aktivität A durch zwei
Teilaktivitäten (aufgrund zweier vorliegender Schaltmengen) kann vorgenommen wer-
den.
Eine kausale – und damit auch zeitliche – Abhängigkeit für das Schalten der verschie-
denen Aktivitäten liegt ebenfalls vor, da Aktivität C mindestens einmal geschaltet ha-
ben muss, bevor Aktivität B schalten darf. Andernfalls könnten Dokumente ungeprüft
weiterverwendet werden. Diese zeitliche Abhängigkeit ist im vorliegenden Petrinetz
im oberen Teil der Abbildung 3.26 nicht erkennbar. Sie wird erst durch eine verfeiner-
te Modellierung der Ablaufsituation deutlich, die im unteren Teil der Abbildung 3.26
dargestellt ist: Aktivität A ist jetzt durch die Aktivitäten A
1
,E undA
2
detaillierter dar-
gestellt, wobeiA
1
undE ein einfaches Eingangs- und Ausgangsschaltverhalten haben,
A
2
dagegen zwar ein einfaches Eingangs- aber ein komplexes Ausgangsschaltverhal-
ten. Die Aktivität E ist eine Senderaktivität (vgl. Abbildung 3.17, Seite 107), die im
Vorbereich der externen Schnittstelle b
3
zwischengefügt wurde, um die Restriktionen
für externe Schnittstellen nicht zu verletzen. Sie wird über eine interne Schnittstelle
b
3, copy aktiviert und sendet von Aktivität A1 erzeugte Informationstypen an die Akti-
vität C .
Die Anwendungen der beschriebenen Sonderfälle sind Verfeinerungsschritte, die sich
aus konkreten Ablaufsituationen ergeben. Sie sind bereits an der Struktur des zugrun-
deliegenden Petrinetzes erkennbar. Allen ist eine Abhängigkeit zwischen Schalt- und
Ergebnismengen gemeinsam (abhängiges Ausgangsschaltverhalten), die sich im Son-
derfall der zusammengesetzten Aktivität durch eine 1:1-Beziehung ausdrückt, ansons-
ten durch eine n:m-Beziehung. Wechselbeziehungen zu anderen Aktivitäten werden,
falls vorhanden, nach der Anwendung der Sonderfälle durch die Anordnung der ver-
feinernden Aktivitäten deutlich. Eine Zwei-Phasen-Aktivität weist zusätzlich immer
Zugriffe zu Schalt- und Ergebnismengen einer zweiten Aktivität auf. Die tatsächli-
che Anwendung der Sonderfälle muss jedoch dem Modellierer überlassen werden, da
Verfeinerungen innerhalb einer Prozesslandschaft vom jeweiligen Modellierungsziel
abhängig sind.
In der diskutierten Beispiellandschaft können nach der Zuweisung der verschiedenen
Schaltverhalten (vgl. Tabelle 3.4 und Abbildung 3.20, Seite 113) alle drei Sonderfälle
identifiziert werden:
 Die Aktivität Anforderungsanalyse erstellen entspricht einer Zwei-Phasen-Akti-
vität, da sie für die Erstellung eines Anforderungsdokuments zunächst das Ge-
123
Formale Basis des Process Landscaping
schäftsprozessmodell anfordert. Da sie ihr Ergebnis – das Anforderungsdoku-
ment – einem Review unterzieht und in Abhängigkeit vom Reviewergebnis ge-
gebenenfalls Verbesserungen einarbeiten muss, liegt eine n:m-Beziehung zwi-
schen ihren Schalt- und Ergebnismengen vor. Bei drei Ergebnismengen kann die
Aktivität entsprechend durch drei verfeinernde Aktivitäten dargestellt werden.
 Die Aktivität Reviewdurchführung ist eine zusammengefasste Aktivität, da sie in
Abhängigkeit des eingehenden Dokumentes jeweils ein korrespondierendes Re-
viewergebnis produziert. Diese Abhängigkeit lässt sich über eine 1:1-Beziehung
ihrer Schalt- und Ergebnismengen formulieren. Mit zwei identifizierten Ergeb-
nismengen kann die Aktivität durch zwei verfeinernde Aktivitäten dargestellt
werden.
 Die Aktivität technische Komponentenanforderungen erstellen repräsentiert den
Sonderfall des Vier-Augen-Prinzips, da ihr Ergebnis einem Review unterzogen
wird und sie eventuell erneut durchlaufen werden muss. Die Relationen zwi-
schen ihren Schalt- und Ergebnismengen lassen sich als n:m-Beziehung formu-
lieren. Auch in diesem Fall liegen zwei Ergebnismengen vor. Entsprechend kann
die Aktivität durch zwei verfeinernde Aktivitäten dargestellt werden.
technische Komponentenanforderung81,..., 83
Anforderungsdokument31,..., 36, 35,copy
31
Review-
durch-
führung
30A117 A2 35 E152 35 261 A3
36
34
33
32
copy senden
91, 92 Review technische Komponentenanforderung
17
copy
262
Geschäftsprozessmodell151, 152, 153
Review Anforderungsdokument
erste Anforderungen17, 17
copy
261, 262
Anfrage nach Geschäftsprozessmodell30
Systemarchitektur112
Anforderungsanalyse erstellenA1, A2, A3
Geschäfts-
prozess
modellieren
151
153
82
81
83
technische Komponenten-
anforderungen erstellen
112
91
92
Abbildung 3.27: Beispielprozesslandschaft nach Anpassungen bezüglich des
Sonderfalls Zwei-Phasen- Aktivität
124
3.2 Notation der unteren Ebenen einer Prozesslandschaft
In Abbildung 3.27 sind zunächst die Anpassungen an der Aktivität Anforderungsana-
lyse erstellen dargestellt. Sie ist jetzt durch die drei Aktivitäten A
1
, A
2
und A
3
ver-
feinert. Entsprechend des Sonderfalls der Zwei-Phasen-Aktivität wurde das zugrun-
deliegende Petrinetz zudem durch eine Kopie der Schnittstelle erste Anforderungen
inklusive zugehöriger Zugriffe erweitert. Da die Schnittstelle 3
5
eine externe Schnitt-
stelle ist, wurde sie entsprechend ihrer Restriktionen als interne kopiert. Zusätzlich
wurde eine Senderaktivität E eingefügt. So werden die temporalen Abhängigkeiten
der drei Teilaktivitäten transparent und die Ablaufinformationen verdeutlicht. Die ver-
feinernden Aktivitäten A
1
, A
2
und A
3
sowie die Senderaktivität E haben jeweils ein
einfaches Eingangsschaltverhalten.
technische Komponentenanforderung81,..., 83, 83,copy
Anforderungsdokument
31
Reviewdurch-
führung (3)
30A117 A2 35 E152 35 261 A3
36
34
33
32
B1 83 E 83
Reviewdurch-
führung (8)
B2 82
81
copy senden
copy
senden
91
91, 92 Review technische Komponentenanforderung
17
copy
112
262
92
Geschäftsprozessmodell151, 152, 153
Review Anforderungsdokument
erste Anforderungen17, 17
copy
261, 262
Anfrage nach Geschäftsprozessmodell30
Systemarchitektur112
Anforderungsanalyse erstellen
technische Komponentenanforderungen erstellen
A1, A2, A3
B1, B2
Geschäfts-
prozess
modellieren
151
153
31,..., 36, 35,copy
Abbildung 3.28: Beispielprozesslandschaft nach Anpassungen bezüglich der
Sonderfälle Zusammengefasste Aktivität und Vier-Augen-Prinzip
Abbildung 3.28 zeigt die Anpassungen der Beispielprozesslandschaft, die sich aus dem
Sonderfall Zusammengefasste Aktivität für die Aktivität Reviewdurchführung ergeben
sowie die Anpassungen, die sich aus dem Sonderfall Vier-Augen-Prinzip für die Ak-
tivität technische Komponentenanforderung erstellen ergeben. Die Aktivität Review-
durchführung ist durch die beiden Aktivitäten Reviewdurchführung(3) und Review-
durchführung(8) verfeinert worden, die Aktivität technische Komponentenanforderun-
125
Formale Basis des Process Landscaping
gen erstellen entsprechend durch die Aktivitäten B
1
und B
2
. Da die Schnittstelle 8
3
eine externe Schnittstelle ist, wurde das zugrundeliegende Petrinetz ebenfalls entspre-
chend ihrer Restriktionen angepasst.
Mit der Betrachtung verschiedener Sonderfälle ist die Diskussion bezüglich der Er-
gänzung einer Prozesslandschaft um Ablaufinformationen abgeschlossen, wobei für
die Erweiterung des zugrundeliegenden Petrinetzes zu einem kohärenten Netz nur die
nicht weiter verfeinerten Aktivitäten a ∈ leaves berücksichtigt wurden. Bislang ist
damit nur eine konkrete Repräsentation einer hierarchisch strukturierten Prozessland-
schaft diskutiert worden. Diese Repräsentation zeigt die Prozesslandschaft als ein ko-
härentes, teilweise verfeinertes und nicht hierarchisches Petrinetz, bestehend aus allen
Blättern des Aktivitätenbaumes AB.
Damit ist eine Prozesslandschaft PLbottom immer eine konkrete Repräsentation aus
einer Familie von Prozesslandschaftsrepräsentationen, die einen gemeinsamen Akti-
vitätenbaum AB haben. Es existieren andere mögliche Repräsentationen der gleichen
Prozesslandschaft, bei denen Teilnetze zu einer einzigen Aktivität a ∈ ref zusammen-
gefasst sind und so von Verfeinerungen abstrahiert wird. Eine solche Vergröberung
und die daraus resultierende neue Repräsentation einer Prozesslandschaft kann durch
eine Abbildung erstellt werden. Bevor diese Abbildung definiert werden kann, sind
noch einige Vorüberlegungen notwendig.
Definition 3.2.38. Sei afold ∈ ref ein innerer Knoten des Aktivitätenbaumes AB der
dritten Ausbaustufe einer Prozesslandschaft PLbottom . Die Menge emptyafold enthält
alle Nachfolger – auch die nicht direkten – der Aktivität afold :
emptyafold := succ
+
(afold )
Die Menge emptysintern enthält alle Schnittstellen s ∈ S, zu denen Zugriffe z ∈ Z
von Elementen der Menge emptyafold existieren:
emptysintern := {s ∈ S |∃ (s, a), (a
′, s) ∈ Z : a, a′ ∈ emptyafold }
Die Menge emptyz enthält alle Zugriffe z ∈ Z von Elementen aus emptyafold zu
Elementen aus emptysintern :
emptyz :={(a, s) ∈ Z | a ∈ emptyafold ∧ s ∈ emptysintern}∪
{(s, a) ∈ Z | s ∈ emptysintern ∧ a ∈ emptyafold }
Die Menge replacez enthält alle Zugriffe z ∈ Z von Elementen aus emptyafold zu
Elementen aus S\emptysintern :
replacez :={(a, s) ∈ Z | a ∈ emptyafold ∧ s ∈ S\empty sintern}∪
{(s, a) ∈ Z | s ∈ S\emptysintern ∧ a ∈ emptyafold }
Die Menge substitutionz enthält Zugriffe z ∈ Z von afold zu Elementen aus
S\emptysintern :
substitutionz :={(afold , s) | (a, s) ∈ replacez}∪
{(s, afold ) | (s, a) ∈ replacez}
126
3.2 Notation der unteren Ebenen einer Prozesslandschaft
Notation 3.2.39. Ein Element afold ∈ ref wird als Repräsentationsaktivität bezeich-
net.
Damit sind alle für eine Definition der Abbildung fold notwendigen Vorarbeiten ge-
leistet.
Definition 3.2.40. Sei PLbottom = (A,S,Z,AB) die dritte Ausbaustufe einer Pro-
zesslandschaft. Die Abbildung fold liefert weitere Petrinetz-Repräsentationen der
Prozesslandschaft PLbottom, bei der genau ein Teilbaum aus AB nicht detailliert dar-
gestellt ist, sondern durch eine Repräsentationsaktivität afold repräsentiert ist:
fold : (APN , S, ZPN , afold ) → (A
′
PN , S
′, Z ′PN , afold ) wobei
A′PN := APN\emptyafold
S′ := S\empty sintern
Z ′PN :=
(
ZPN\(emptyz ∪ replacez)
)
∪ substitutionz
Die Menge emptyafold enthält dabei alle Aktivitäten a ∈ APN , die nach Anwendung
der Abbildung fold nicht mehr explizit dargestellt sind, sondern durch die Aktivität
afold repräsentiert werden.
Die Menge emptysintern enthält alle Schnittstellen s ∈ S, die nach Anwendung der
Abbildung fold nicht mehr explizit dargestellt sind.
Die Menge emptyz enthält alle Zugriffe z ∈ ZPN , die nach Anwendung der Abbil-
dung fold nicht mehr explizit dargestellt sind.
Die Menge replacez enthält alle Zugriffe z ∈ ZPN , die durch die Anwendung der
Abbildung fold durch Zugriffe (s, afold ) oder (afold , s) ersetzt werden.
Die Menge substitutionz enthält Zugriffe z, die nach Anwendung der Abbildung fold
auf die Menge replacez neu in der Petrinetz-Repräsentation entstanden sind.
Bemerkung 3.2.41. Mehrfachanwendungen der Abbildung fold führen zu Repräsen-
tationen einer Prozesslandschaft, bei denen mehrere Teilbäume aus AB durch ver-
schiedene Repräsentationsaktivitäten afold
i
dargestellt sind. Vor einer Mehrfachan-
wendung von fold muss geprüft werden, ob die verschiedenen afold in der transitiven
Hülle eines jeweils anderen a′fold liegen. Ist dies für zwei afold und a′fold der Fall, so
gilt entweder afold ∈ succ+(a′fold ) oder a′fold ∈ succ+(afold ) (vgl. Bemerkung 3.1.5).
Im ersten Fall kann daher auf die Anwendung von fold bezüglich der Repräsentati-
onsaktivität afold , andernfalls auf die Anwendung von fold bezüglich a′fold verzichtet
werden.
Eine Prozesslandschaft PLbottom kann so mit Hilfe der Abbildung fold in unterschied-
lichen Detaillierungsgraden als Prozesslandschaft PL′bottom formuliert werden.
3.2.2 Erweiterungen zur Analyse dynamischer Kommunikationseigen-
schaften
Dieser Abschnitt führt zusätzliche Erweiterungen des einer Prozesslandschaft zugrun-
deliegenden Petrinetzes ein. Diese unterstützen insbesondere die Analyse dynamischer
127
Formale Basis des Process Landscaping
Kommunikationseigenschaften in einer verteilten Prozesslandschaft. Zuvor wird je-
doch die Umstrukturierung einer gegebenen Prozesslandschaft diskutiert, deren Er-
gebnis sich auf den Verteilungsaspekt der Aktivitäten auf verschiedene Standorte kon-
zentriert und so die Betrachtung spezieller Kommunikationseigenschaften erleichtert.
3.2.2.1 Umstrukturierung einer Prozesslandschaft in eine lokale Sicht
Bislang wurde bei einer Prozesslandschaft immer davon ausgegangen, dass ihre Ver-
feinerung nach logischen Gesichtspunkten durchgeführt wird, was bedeutet, dass kom-
plexe Aktivitäten durch eine Menge einfacherer Aktivitäten verfeinert werden und
auch die Schnittstellen zwischen ihnen den Inhalt der auszutauschenden Informations-
typen immer detaillierter darstellen. Die Sicht auf eine so entstandene hierarchische
Prozesslandschaft spiegelt vor allem die temporalen und kausalen Zusammenhänge
wider. Verteilungsaspekte sind durch die Abbildung local berücksichtigt, sie sind je-
doch in der grafischen Repräsentation einer Prozesslandschaft nicht erkennbar, da die
Lokalitätsattribute von Aktivitäten hier bislang nicht berücksichtigt sind.
Notation 3.2.42. Eine nach logischen Gesichtspunkten strukturierte Prozessland-
schaft PL wird im Folgenden kurz als PLlogic bzw. als logische Sicht einer Pro-
zesslandschaft bezeichnet.
Um die Analyse einer über mehrere Standorte verteilten Prozesslandschaft durch eine
geeignete grafische Repräsentation zu unterstützen, kann die logische Sicht derart um-
strukturiert werden, dass sich für die Aktivitäten eine neue Anordnung ergibt. Diese
spiegelt dann die lokale Verteilung aller Aktivitäten in einer Prozesslandschaft wi-
der. Ihre Anordnungskriterien resultieren aus den verschiedenen Standorten und deren
Strukturen.
Notation 3.2.43. Eine nach lokalen Gesichtspunkten strukturierte Prozesslandschaft
PL wird im Folgenden kurz als PLlocal bzw. als lokale Sicht einer Prozesslandschaft
bezeichnet.
In Abschnitt 2.3.1 wurde bereits am Beispiel eines Puzzles abstrakt dargestellt, wel-
che Auswirkungen eine Umstrukturierung von der logischen in die lokale Sicht auf
die grafische Repräsentation der Prozesslandschaft haben kann (vgl. Abbildung 2.6,
Seite 35). Im folgenden Abschnitt wird auf die formalen Grundlagen der Umstruktu-
rierung eingegangen.
Wird eine Prozesslandschaft PLlogic nach lokalen Gesichtspunkten in eine Prozess-
landschaft PLlocal umstrukturiert, werden Aktivitäten, die in PLlogic nur einmal mo-
delliert sind, in PLlocal immer dann mehrfach dargestellt, wenn sie an mehreren Or-
ten durchgeführt werden, die Kardinalität ihres Lokalitätsattributs also größer eins ist.
Dies wird insbesondere am Beispiel der Prozesslandschaft zur komponentenbasierten
Softwareentwicklung deutlich, wenn mehrere Komponenten an unterschiedlichen Or-
ten parallel entwickelt werden. Um die so entstehenden zusätzlichen Aktivitäten der
Prozesslandschaft PLlocal eindeutig auf ihren Ursprung in der logischen Sicht zurück-
führen zu können, werden sie in PLlocal als Paar formuliert:
128
3.2 Notation der unteren Ebenen einer Prozesslandschaft
Definition 3.2.44. Sei PLlogic = (Alogic , Slogic , Zlogic , ABlogic) die dritte Ausbaustu-
fe einer nach logischen Gesichtspunkten modellierten Prozesslandschaft und O = ∅
eine gültige Ortemenge, deren Elemente mit Hilfe der Abbildung local den Aktivitäten
der Prozesslandschaft zugeordnet sind.
Sei weiterhin PLlocal = (Alocal , Slocal , Zlocal , ABlocal ) die dritte Ausbaustufe einer
nach lokalen Gesichtspunkten umstrukturierte Prozesslandschaft, die aus der Um-
strukturierung von PLlogic entstanden ist. Für die Aktivitäten aus Alogic gilt:
∀ a ∈ Alogic : Alocal ,a = {a} × local(a)
Die Menge Alocal lässt sich definieren als
Alocal :=
⋃
a∈A
logic
Alocal ,a
Mit der Formulierung der Aktivitäten aus Alocal ist immer eindeutig erkennbar, wel-
che Aktivität aus Alogic mit welchen Aktivitäten aus Alocal korrespondiert. Durch das
Kreuzprodukt einer Aktivität aus Alogic mit ihren Lokationsattributen ist jedoch nicht
nur diese eindeutige Zuordnung gewährleistet, es wird auch gleichzeitig die Anzahl
der in einer Prozesslandschaft PLlocal korrespondierenden Aktivitäten festgelegt.
Die Schnittstellen der in PLlocal mehrfach vorhandenen Aktivitäten zu anderen wer-
den ebenfalls entsprechend mehrfach dargestellt, um spätere Kommunikationsanaly-
sen zwischen verschiedenen Standorten zu ermöglichen. Die so entstehenden zusätz-
lichen Elemente der Prozesslandschaft PLlocal müssen verschiedenen Bedingungen
genügen. Zuvor werden jedoch alle Schnittstellen s ∈ Slogic , über die zwei Aktivitä-
ten unterschiedlicher Standorte Informationen austauschen, zu externen Schnittstellen
(vgl. Definition 3.2.4 auf Seite 96) umformuliert. Dies erleichtert nicht nur die Um-
strukturierung in eine lokale Sicht, sondern unterstützt vor allem die angesprochene
Kommunikationsanalyse.
Konsistenzbedingung 3.2.45. Sei PLlogic = (Alogic , Slogic , Zlogic , ABlogic) die logi-
sche Sicht auf die dritte Ausbaustufe einer Prozesslandschaft und Sextern ⊆ Slogic die
Menge der externen Schnittstellen in PLlogic .
∀ s ∈ Slogic :
⋃
a∈•s
local (•s) =
⋃
a∈s•
local (s•) ⇒ s ∈ Sextern
Durch diese Bedingung werden alle Schnittstellen, die zwischen zwei oder mehr Orten
liegen, zu externen Schnittstellen. Sie müssen gegebenenfalls gemäß der in Definiti-
on 3.2.4 auf Seite 96 für sie formulierten Restriktionen angepasst werden. Die dazu
erforderlichen Schritte sind bereits durch die Abbildungen 3.15 (Seite 106) und 3.17
(Seite 107) erläutert worden.
Definition 3.2.46. Sei PLlogic = (Alogic , Slogic , Zlogic , ABlogic) die dritte Ausbaustu-
fe einer nach logischen Gesichtspunkten modellierten Prozesslandschaft und O = ∅
129
Formale Basis des Process Landscaping
eine gültige Ortemenge, deren Elemente mit Hilfe der Abbildung local den Ak-
tivitäten der Prozesslandschaft zugeordnet sind. Für die lokale Sicht PLlocal =
(Alocal , Slocal , Zlocal , ABlocal ) der Prozesslandschaft können die Mengen Slocal , Zlocal
und ABlocal wie folgt definiert werden:
Für alle si ∈ Slogic mit Slogic = {s1, ..., sn}, n ∈ N und •s = {ai}, s• = {a′i} mit
ai, a′i ∈ Alogic , ai = a
′
i wird eine Teilmenge
Ti ⊆ Alocal ,a
i
×Alocal ,a′
i
als diejenige Menge aller Aktivitätenpaare der lokalen Sicht gewählt, die miteinander
kommunizieren. Dann gelte für die Menge der Schnittstellen Si = {si,1, ..., si,|T
i
|
},
über die die Aktivitätenpaare kommunizieren, dass
{si,1, ..., si,|T
i
|
} ∩ Slogic = ∅
∀ 1 ≤ i, j ≤ n, i = j : Si ∩ Sj = ∅
Somit kann Slocal definiert werden als
Slocal :=
(
Slogic\Sextern
)
∪ {si,j | 1 ≤ i ≤ n, 1 ≤ k ≤ |Ti|}
Für Zlocal gilt
Zlocal :={(si,j, ai) | ∃ a ∈ Alogic , si ∈ Slogic : (si, a) ∈ Zlogic}∪
{(ai, si,j) | ∃ a ∈ Alogic , si ∈ Slogic : (a, si) ∈ Zlogic}∪
{(s˜, ai) | ∃ a ∈ Alogic , s˜ ∈ Slogic\Sextern : (s˜, a) ∈ Zlogic ∧ ai ∈ Alocal ,a}∪
{(ai, s˜) | ∃ a ∈ Alogic , s˜ ∈ Slogic\Sextern : (a, s˜) ∈ Zlogic ∧ ai ∈ Alocal ,a}
Schließlich gilt
ABlocal = ABlogic
Die Kardinalität der Mengen Ti ist abhängig von den existierenden Datenflüssen zwi-
schen kommunizierenden Aktivitäten. Sie kann durchaus kleiner sein als die Menge
aller theoretisch möglichen Datenflüsse zwischen verschiedenen Aktivitäten, die über
modellierte Zugriffe miteinander verbunden sind und jeweils an mehreren Orten aus-
geführt werden. Die Existenz dieser Datenflüsse ist abhängig vom Kontext einer mo-
dellierten Prozesslandschaft. Ihre Anzahl wird daher vom Modellierer festgelegt.
Für die Schnittstellen in der lokalen Sicht einer Prozesslandschaft muss sichergestellt
werden, dass diese nicht aus der Menge der Schnittstellen si ∈ Slogic ausgewählt wer-
den, sondern bis auf die Elemente der Menge Slogic\Sextern neu definiert werden. Die-
se Elemente der Menge Slogic\Sextern repräsentieren die Randstellen der Prozessland-
schaft (bei denen also entweder ihr Vor- oder ihr Nachbereich leer ist). Des Weiteren
müssen die Teilmengen Si, Sj , die jeweils verschiedene Schnittstellen aus der logi-
schen Sicht repräsentieren, paarweise disjunkt sein. Die Anzahl der Schnittstellen pro
130
3.2 Notation der unteren Ebenen einer Prozesslandschaft
Teilmenge ist beschränkt durch die Anzahl der über sie kommunizierenden Aktivitä-
tenpaare. Somit kann Slocal formuliert werden als die Menge Slogic\Sextern zusammen
mit der Vereinigung aller Schnittstellen zwischen je zwei miteinander kommunizieren-
den Aktivitätenpaare.
Alle Zugriffe z ∈ Zlocal entstehen durch (mehrfaches) Ersetzen der Zugriffe
z ∈ Zlogic . Die Zugriffe auf Schnittstellen s˜ ∈ Slogic\Sextern , deren Vor- oder Nachbe-
reich leer ist (also •s˜ = ∅ oder s˜• = ∅), werden dabei gesondert behandelt, da sie nicht
den Restriktionen der Definition 3.2.46 genügen. Hier werden die Zugriffe (s˜, a) und
(a, s˜) so oft ersetzt, wie es Ortsattribute der jeweils auf sie zugreifenden Aktivitäten
a ∈ Alogic gibt.
Auf den Aktivitätenbaum der Prozesslandschaft hat die Umstrukturierung in die lokale
Sicht keinerlei Auswirkungen.
Die Anzahl der Schnittstellen in der lokalen Sicht einer Prozesslandschaft, die durch
die Umstrukturierung entstehen, ist nach oben beschränkt. Formal:
Bemerkung 3.2.47. Sei PLlogic = (Alogic , Slogic , Zlogic , ABlogic) die dritte Ausbau-
stufe einer nach logischen Gesichtspunkten modellierten Prozesslandschaft undO = ∅
eine gültige Ortemenge, deren Elemente mit Hilfe der Abbildung local den Aktivitäten
der Prozesslandschaft zugeordnet sind.
Sei weiterhin PLlocal = (Alocal , Slocal , Zlocal , ABlocal ) die dritte Ausbaustufe einer
nach lokalen Gesichtspunkten umstrukturierten Prozesslandschaft, die aus der Um-
strukturierung von PLlogic entstanden ist und a1, a2 ∈ Alogic , a1 = a2. Es gilt:
∀ s ∈ Slogic mit • s = {a1}, s• = {a2} :
|{sk ∈ Slocal | ∃ oi ∈ local (a1) : (a1, oi) = •sk ∨
∃ oj ∈ local (a2) : (a2, oj) = sk•}| ≤ |local (a1)| × |local (a2)|
Mit den formulierten Restriktionen wird gefordert, dass in Abhängigkeit der Kardi-
nalität der Aktivitätsteilmengen Alocal ,a
1
und Alocal ,a
2
auch deren Schnittstellen ent-
sprechend häufig in der Prozesslandschaft PLlocal vorkommen können: Die Anzahl
der Schnittstellen s ∈ Slocal ist nach oben beschränkt durch das Produkt der Anzahl
derjenigen Orte, an denen die Aktivität a
1
durchgeführt wird und der Anzahl derjeni-
gen Orte, an denen die Aktivität a
2
durchgeführt wird. Die Menge der so entstehenden
zusätzlichen Schnittstellen kann aber auch kleiner sein, wenn beispielsweise in ei-
ner zu modellierenden Prozesslandschaft nicht alle aus syntaktischer Sicht möglichen
Schnittstellen tatsächlich existieren.
Externe Schnittstellen verbinden in der lokalen Sicht nicht mehr zwei verfeinerte Ak-
tivitäten (vgl. Bemerkung 3.2.7 auf Seite 96), sondern sind genau diejenigen, über die
zwei Aktivitäten unterschiedlicher Standorte Informationen austauschen. Damit gilt:
Konsistenzbedingung 3.2.48. Sei PLlocal = (Alocal , Slocal , Zlocal , ABlocal ) die dritte
Ausbaustufe einer nach lokalen Gesichtspunkten strukturierte Prozesslandschaft und
Slocal ,extern ⊆ Slocal die Menge der externen Schnittstellen in PLlocal.
131
Formale Basis des Process Landscaping
Sei weiterhin ˜local eine Abbildung, die die Aktivitäten der lokalen Sicht auf ihr jewei-
liges Ortsattribut o ∈ O abbildet:
˜local : Alocal → O mit ˜local
(
(a, o)
)
= o
∀ s ∈ Slocal :
⋃
a∈•s
˜local (a) =
⋃
a∈s•
˜local (a) ⇒ s ∈ Slocal ,extern
Mit dieser Konsistenzbedingung wird die Menge der Schnittstellen, die die Restrik-
tionen für externe Schnittstellen gemäß Definition 3.2.4 erfüllen, in der lokalen Sicht
eingeschränkt auf diejenigen, die Aktivitäten zwischen verschiedenen Standorten mit-
einander verbinden. Diese Einschränkung hilft dem Analysten, der den Schwerpunkt
seiner Analyse auf das Kommunikationsverhalten zwischen verschiedenen Standorten
innerhalb einer Prozesslandschaft legen will.
Was diese Konsistenzbedingung sowie die Definition 3.2.46 für einen Modellierer be-
deuten, der eine Umstrukturierung durchführen will, zeigt das nachfolgende Beispiel.
Abbildung 3.29 zeigt einen Ausschnitt aus der Beispielprozesslandschaft PLlogic für
komponentenbasierte Softwareentwicklung. Er beinhaltet Aktivitäten des Component
Engineering, die nach der Komponentenentwicklung und der Releaseerstellung jede
neue Komponente vom Qualitätsmanagement testen lassen. Die Aktivität Fehlerkor-
rektur erhält anschließend ein Fehlerprotokoll, dessen Inhalt darüber entscheidet, ob
Mängel behoben werden müssen und die neue Komponente erneut dem Qualitäts-
management vorzulegen ist oder aber diese an die Aktivität Komponente hinzufügen
weitergeleitet werden kann. Die Aktivität Fehlerkorrektur hat damit ein deterministi-
sches Ausgangsschaltverhalten. Dem Qualitätsmanagement ist ein deterministisches
Eingangsschaltverhalten zugeordnet, da hier eine neue Komponente entweder erstma-
lig oder nochmalig getestet werden muss.
A QM
D
31 32 33 34
34
copy
32
copy
o1 o2 o3 o4 o1o5 o2
o6
B
o1 o2 o3 o4 o5
C
o1 o2 o3 o4 o5
 A         Komponentenentwicklung
B         Release erstellen
C         Fehlerkorrektur
 D         Komponente hinzufügen
QM     Qualitätsmanagement
31                  Komponentenimplementation
32 , 32
copy      Komponente
34 , 34
copy      getestete Komponente
       33                  Fehlerprotokoll neue Komponente
Abbildung 3.29: Ausschnitt der Beispielprozesslandschaft PLlogic
Für das Beispiel gilt weiterhin, dass alle Aktivitäten des Component Engineering an
fünf verschiedenen Standorten o
1
bis o
5
stattfinden (vgl. Reiter an den Aktivitäten in
132
3.2 Notation der unteren Ebenen einer Prozesslandschaft
Abbildung 3.29), während das Qualitätsmanagement lediglich an den beiden Stand-
orten o
1
und o
2
vorkommt. Mit Hilfe einer erweiterten Dokumentensicht (vgl. Ab-
schnitt 3.1.2), in der für jede Schnittstelle s ∈ Slogic die Zugriffe aller Aktivitäten
eines jeden Standortes explizit aufgeführt sind, kann ein Modellierer zunächst – in
Abhängigkeit des modellierten Kontextes – die tatsächlich vorkommenden Datenflüs-
se aus der Menge aller theoretisch möglichen auswählen. Abbildung 3.30 zeigt diese
erweiterte Dokumentensicht für alle Schnittstellen aus Abbildung 3.29.
Abbildung 3.31 zeigt alle tatsächlich vorkommenden Datenflüsse innerhalb der Bei-
spiellandschaft aus Abbildung 3.29 als Prozessfragmente. Hier wird deutlich, warum
in der Konsistenzbedingung 3.2.46 auf Seite 129 die Anzahl der in PLlocal vorkom-
menden Schnittstellen und Zugriffe auch kleiner als die Anzahl aller möglichen sein
kann: Alle Aktivitäten des Component Engineering, die am Standort o
1
durchge-
führt werden, kommunizieren ausschließlich mit dem Qualitätsmanagement am sel-
ben Standort. Analoges gilt für die Aktivitäten des Component Engineering am Stand-
ort o
2
. Diese und die Aktivitäten des Component Engineering an den Standorten o
3
, o
4
und o
5
kommunizieren ausschließlich mit dem Qualitätsmanagement am Standort o
2
.
Verklebt man nun die Prozessfragmente aus Abbildung 3.31 derart, dass alle Aktivitä-
ten mit gleichem Namen und gleichem Lokationsattribut jeweils nur einmal vorkom-
men, entsteht die Prozesslandschaft PLlocal in Abbildung 3.32. Hier wird deutlich,
was in Abbildung 3.29 nur durch zusätzliche Dokumentation der Lokationsattribu-
te ersichtlich wurde. Die externen Schnittstellen sind außerhalb der grau hinterleg-
ten Standorte o
1
bis o
6
angeordnet. Sie verbinden die insgesamt sechs vorhandenen
Standorte der Prozesslandschaft miteinander und sind daher Grundlage für eine exter-
ne Kommunikation, die aus dieser lokalen Sicht fokussiert betrachtet werden kann.
Die Umstrukturierung einer Prozesslandschaft in eine lokale Sicht hat teilweise Aus-
wirkungen auf die Schaltverhalten von Aktivitäten. Beispielsweise kann aus einem
ursprünglich einfachen Ausgangsschaltverhalten jetzt ein deterministisches oder sogar
komplexes Schaltverhalten geworden sein.
Insgesamt können mögliche Änderungen von Schaltverhalten nicht kontextunabhän-
gig identifiziert und automatisiert durchgeführt werden. Dies ist Aufgabe des Model-
lierers, der in Abhängigkeit der modellierten Situationen das jeweilige Schaltverhalten
anpassen muss. In Abbildung 3.32 ist unter anderem das Eingangsschaltverhalten der
Aktivität Komponente hinzufügen von einem einfachen zu einem deterministischen
verändert worden.
Mit der Anwendung der Abbildung local auf alle Aktivitäten einer Prozesslandschaft
PLlogic , ihrer Umstrukturierung und der anschließenden kontextabhängigen Anpas-
sung verschiedener Schaltverhalten ist umfassend beschrieben, wie man die lokale
Sicht für eine in einer logischen Sicht erstellten Prozesslandschaft erhält. Diese lokale
Sicht kann analog der Verfeinerungen in der logischen Sicht weiter detailliert werden.
Dazu werden alle beschriebenen Schritte individuell für jeden Ort der Prozessland-
schaft erneut durchgeführt.
Neben der Möglichkeit einer weiteren Detaillierung wie gerade beschrieben sollte sich
ein Modellierer zuvor jedoch immer die Frage nach möglichen Schnittstellen zwischen
133
Formale Basis des Process Landscaping
B
A
A
B
B
B
A
A
A
B
 o1
 o5
 o4
 o3
 o2
 o1
 o2
 o3
 o4
 o5
31
C
B
B
C
C
C
B
B
B
C
 o1
 o5
 o4
 o3
 o2
 o1
 o2
 o3
 o4
 o5
C
QM
QM
C
C
C
C
 o1
 o2
 o1
 o2
 o3
 o4
 o5
3332
copy
QM
B
B
QM
B
B
B
 o1
 o5
 o4
 o3
 o2
 o1
 o2
32
QM
C
C
QM
C
C
C
 o1
 o5
 o4
 o3
 o2
 o1
 o2
34
C
C
D
C
C
C
 o1
 o5
 o4
 o3
 o2
 o6
34
copy
 A         Komponentenentwicklung
B         Release erstellen
C         Fehlerkorrektur
 D         Komponente hinzufügen
QM     Qualitätsmanagement
31                  Komponentenimplementation
32 , 32
copy      Komponente
34 , 34
copy      getestete Komponente
       33                  Fehlerprotokoll neue Komponente
Abbildung 3.30: Erweiterte Dokumentensicht der Schnittstellen aus Abbildung 3.29
134
3.2 Notation der unteren Ebenen einer Prozesslandschaft
 o1
31A B
31A B
31A B
31A B
31A B
int
int
int
int
int
B C
B C
B C
B C
B C
int
int
int
int
int
32
copy
32
copy
32
copy
32
copy
32
copy
32B QM
32B QM
32B QM
32B QM
32B QM
int
int
ext
ext
ext
C D
C D
C D
C D
C D
int
ext
ext
ext
ext
34C QM
34C QM
34C QM
34C QM
34C QM
int
int
ext
ext
ext
33QM C
33QM C
33QM C
33QM C
33QM C
int
int
ext
ext
ext
34
copy
34
copy
34
copy
34
copy
34
copy
5 von  25 5 von  10 5 von  5
 o1  o1
 o2  o2
 o3  o3
 o4  o4
 o5  o5
 o1  o1
 o2  o2
 o3  o2
 o4  o2
 o5  o2
 o1  o6
 o6 o2
 o3  o6
 o4  o6
 o5  o6
 o1  o1
 o2  o2
 o3  o3
 o4  o4
 o5  o5
 o1  o1
 o2  o2
 o3  o2
 o4  o2
 o5  o2
 o1
 o2  o2
 o2  o3
 o2  o4
 o2  o5
31                  Komponentenimplementation
32 , 32
copy      Komponente
34 , 34
copy      getestete Komponente
       33                  Fehlerprotokoll neue Komponente
 A         Komponentenentwicklung
B         Release erstellen
C         Fehlerkorrektur
 D         Komponente hinzufügen
QM     Qualitätsmanagement
Abbildung 3.31: Auswahl der tatsächlich existierenden Datenflüsse
135
Formale Basis des Process Landscaping
A B QM C
D
31 32 33 34
32
copy 34copy
A B QM C31 32 33 34
32
copy 34copy
A B C31 32 34
32
copy
34
copy
A B C31 32 34
32
copy 34copy
A B C31 32 34
32
copy 34copy
31                 Komponentenimplementation
32 , 32
copy     Komponente
34 , 34
copy     getestete Komponente
       33                 Fehlerprotokoll neue Komponente
 A         Komponentenentwicklung
B         Release erstellen
C         Fehlerkorrektur
 D         Komponente hinzufügen
QM     Qualitätsmanagement
o1o1 o1 o1
o2o2o2o2
o3 o3 o3
o4o4o4
o5o5o5
33
33
33
o6
Abbildung 3.32: Lokale Sicht auf die Beispielprozesslandschaft aus Abbildung 3.29
136
3.2 Notation der unteren Ebenen einer Prozesslandschaft
denjenigen Aktivitäten stellen, die in der logischen Sicht nur einmal vorkommen. Bei-
spielsweise sollten sich die Qualitätsmanagement-Aktivitäten der beiden Standorte o
1
und o
2
aus Abbildung 3.32 bezüglich der Vorgabe von Richtlinien abstimmen. Da auch
die Frage nach weiteren Schnittstellen immer nur kontextabhängig beantwortet werden
kann, bleibt diese Form der Erweiterung einer Prozesslandschaft ebenfalls Aufgabe
des Modellierers und kann nicht automatisiert durchgeführt werden.
Für eine Prozesslandschaft PLbottom werden im folgenden Abschnitt zusätzliche Er-
weiterungen und ausgezeichnete Teilnetze des korrespondierenden Petrinetzes einge-
führt, die im Rahmen der Kommunikationsanalyse von unteren Landschaftsebenen
erforderlich sind. Sie sind speziell bei der Berücksichtigung des geografischen Vertei-
lungsaspektes – also der lokalen Sicht einer Prozesslandschaft – hilfreich, jedoch auch
für die logische Sicht gültig.
3.2.2.2 Erweiterungen zur vierten Ausbaustufe einer Prozesslandschaft
Ziel der Analyse der unteren Ebenen einer verteilten Prozesslandschaft ist – wie bereits
in Abschnitt 2.3.3 erläutert – die Effizienzbetrachtung des Kommunikationsverhaltens
innerhalb dieser Landschaft. Das zugrundeliegende Petrinetz muss dazu die Festle-
gung und Auswertung verschiedener Landschaftsattribute ermöglichen, wie beispiels-
weise die Identifikation von Sender und Empfänger eines Informationsobjektes, des-
sen Volumen und entstehende Kommunikationskosten. Der Zusammenhang zwischen
verschiedenen Aspekten der Effizienz, Landschaftseigenschaften und konkreten Attri-
buten von Landschaftselementen ist in Abbildung 2.7 auf Seite 41 (Abschnitt 2.3.3)
bereits informal dargestellt. Für die dort aufgeführten Attribute wird im Folgenden
eine formale Basis eingeführt.
In PLL als Petrinetz-Variante ist jeder Schnittstelle ein nicht näher spezifizierter
Dokumenttyp dt ∈ DT zugewiesen (wie z.B. Anforderung, Review, etc., vgl.
Definition 3.1.24 auf Seite 71). Für eine simulative Auswertung dynamischer Kom-
munikationseigenschaften über die verschiedenen repräsentierten Dokumente müssen
diese Dokumenttypen mit Attributen versehen werden.
Beispiel:
Eine konkretes Dokument, das als Marke innerhalb einer Prozesslandschaft dargestellt
wird, weist mindestens die folgenden Attribute auf:
 Sender
 Empfänger
 via (Kommunikationskanal, über den das Dokument verschickt wird)
 Id (zur eindeutigen Identifizierung)
 Volumen
137
Formale Basis des Process Landscaping
Die Attributwerte für Sender und Empfänger entsprechen konkreten in der Prozess-
landschaft modellierten Aktivitäten, die Attributwerte für via entsprechen konkreten
Kommunikationskanälen. Eine Identitätsnummer und das Volumen eines Dokuments
lassen sich jeweils als natürliche oder als reelle Zahl ausdrücken.
Formal kann ein Dokumenttyp dt∗ ∈ DT ∗ mit einer festen Menge an Attributen als
kartesisches Produkt formuliert werden.
Definition 3.2.49. Sei PLbottom = (A,S,Z,AB) die dritte Ausbaustufe einer Pro-
zesslandschaft, CC = ∅ die zugehörige Menge funktionsfähiger Kommunikations-
kanäle und DT∗ eine Menge von Dokumenttypen mitDT∗ := A×A×CC ×Z×R.
Seien weiterhin a
1
, a
2
∈ A, cc
1
∈ CC , n ∈ N und r ∈ R. Die Abbildung type∗
ordnet den Schnittstellen von PLbottom Dokumenttypen zu, die mit einer konkreten
Attributmenge versehen sind:
type∗ : S → DT ∗
wobei für ein dt∗ ∈ DT ∗gilt :
dt∗ := (a
1
, a
2
, cc
1
, n, r)
Des Weiteren gilt:
• netsender ist eine Abbildung, die, angewendet auf ein dt∗ ∈ DT ∗, den Sender
eines Dokumenttyps ermittelt:
netsender : DT ∗ → Alocal mit netsender (dt∗) = a1
• netreceiver ist eine Abbildung, die, angewendet auf ein dt∗ ∈ DT ∗, den Emp-
fänger eines Dokumenttyps ermittelt:
netreceiver : DT ∗ → Alocal mit netreceiver (dt∗) = a2
• netvia ist eine Abbildung, die, angewendet auf ein dt∗ ∈ DT ∗, den zur Versen-
dung eines Dokumenttyps verwendeten Kommunikationskanal ermittelt:
netvia : DT ∗ → CC mit netvia(dt∗) = cc
1
• documentid ist eine injektive Abbildung, die, angewendet auf ein dt∗ ∈ DT ∗,
die Identitätsnummer eines Dokumenttyps ermittelt:
documentid : DT ∗ → N mit documentid (dt∗) = n
• volume ist eine Abbildung, die, angewendet auf ein dt∗ ∈ DT ∗, das Volumen
eines Dokumenttyps ermittelt:
volume : DT ∗ → R mit volume(dt∗) = r
138
3.2 Notation der unteren Ebenen einer Prozesslandschaft
Die in Definition 3.2.49 eingeführte Konstruktion der Dokumenttypen erlaubt auf ein-
fache Art und Weise die Auswertung von Simulationsdaten einer verteilten Prozess-
landschaft bezüglich der Kommunikation verschiedenartig ausgeprägter Dokumentty-
pen.
Damit ist diejenige Teilmenge der in Abschnitt 2.3.3 geforderten Attribute für die Ana-
lyse spezieller Kommunikationseigenschaften definiert, die den zu betrachtenden In-
formationsobjekten zugeordnet werden kann. Nachfolgend werden zusätzliche Erwei-
terungen eingeführt, die der Betrachtung
 der Informationsverteilung,
 der räumlichen Verteilung von Aktivitäten,
 des Informationsflusses und
 der Auslastung aller modellierten Prozesse
dienen (vgl. Abschnitt 2.3.3) und damit eine Bewertung der Kommunikationseffizienz
innerhalb einer Prozesslandschaft unterstützen.
Bei der Simulation wird ein Informationsaustausch dadurch modelliert, dass ein Kom-
munikationspartner, der Initiator, den Wunsch zur Kommunikation signalisiert. Erst
wenn der andere Simulationspartner diese Anfrage beantwortet, übernimmt er dadurch
die Rolle des Responders. Danach können Nachrichten zwischen beiden Partnern aus-
getauscht werden. Dabei hängt die Richtung des Nachrichtenaustausches nicht zwin-
gend mit der Rollenverteilung von Initiator und Responder zusammen.
Die Initiatorrolle ist formal dadurch gekennzeichnet, dass zum Vorbereich einer Akti-
vität eine ausgezeichnete Schnittstelle sinit existiert, die zur Schaltmenge dieser Akti-
vität gehört. Die Responderrolle lässt sich analog als ausgezeichnete Schnittstelle sresp
beschreiben, die zum Vorbereich der gleichen Aktivität gehört. Formal lassen sich die
beiden Rollen wie folgt definieren:
Definition 3.2.50. Sei PLbottom = (A,S,Z,AB) die dritte Ausbaustufe einer Pro-
zesslandschaft mit S = Sintern∪Sextern . Sei Sadd := Sinit∪Sresp mit Sinit∩Sresp = ∅
eine Menge von Schnittstellen, die der Prozesslandschaft PLbottom zur Analyse des In-
formationsaustausches über Kommunikationskanäle hinzugefügt wurde.
Sei weiterhin CC = ∅ die zugehörige Menge funktionsfähiger Kommunikationskanä-
le, a
1
, a
2
∈ A, s
1
, s
2
∈ Sextern und cc1 := channel
(
(a
1
, s
1
), (s
1
, a
2
)
)
∈ CC ,
cc
2
:= channel
(
(a
1
, s
2
), (s
2
, a
2
)
)
∈ CC . Ein Element sinit ∈ Sinit heißt Initia-
torrolle für einen Informationsaustausch über einen Kommunikationskanal cc
1
: ⇔
1. ∀Ssource ,a
1
∈ (Hsource ,a
1
) : sinit ∈ Ssource ,a
1
2. •sinit = ∅
3. ∀ a ∈ A∃! sinit ∈ Sinit : (sinit , a) ∈ Z
139
Formale Basis des Process Landscaping
Ein Element sresp ∈ Sresp heißt Responderrolle für einen Informationsaustausch über
einen Kommunikationskanal cc
2
: ⇔
1. ∀Ssource ,a
1
∈ (Hsource ,a
1
) : sresp ∈ Ssource ,a
1
2. •sresp = ∅
3. ∀ a ∈ A∃! sresp ∈ Sresp : (sresp , a) ∈ Z
Elemente aus Sinit und Sresp sind damit immer Elemente der Schaltmengen einer Ak-
tivität a
1
∈ A, die wiederum einem Kommunikationskanal zugeordnet ist. Für eine
passende Verteilung von Initiator- und Responderrolle muss gelten: cc
1
= cc
2
und
damit s
1
= s
2
.
Eine gültige Anfangsmarkierung als notwendige Voraussetzung zur Aktivierung des
Kommunikationskanals cc lässt sich – bis auf die Schnittstelle, die die zu kom-
munizierende Nachricht enthält – analog zur gültigen Anfangsmarkierung inner-
halb einer Prozesslandschaft PL formulieren (vgl. Definition 3.2.15 auf Seite 104).
Die Bedingungen für sinit und sresp müssen nicht notwendigerweise erfüllt sein,
wenn keine Betrachtung der Informationsverteilung durchgeführt werden soll, die
Initiator-/Responder-Rolle also nicht explizit betrachtet wird.
sinit
35, copy
s
resp
Senden Reviewdurchführung35
35, copy Anforderungsdokument (zum Versand)
35 Anforderungsdokument (zum Review)
Kommunikationskanal
erweiterter Kommunikationskanal
Abbildung 3.33: Kommunikationskanal erweitert um Initiator- und Responderrolle
Abbildung 3.33 zeigt beispielhaft den Aufbau des Kommunikationskanals, der ein An-
forderungsdokument von der Aktivität Senden (vgl. Abbildung 3.21 auf Seite 116)
über eine externe Schnittstelle an die Aktivität Reviewdurchführung des Qualitätsma-
nagements weiterleitet. Da nicht nur die Datenschnittstelle 3
5,copy, sondern sowohl
die Initiatorrolle sinit als auch die Responderstelle sresp mit je einer Marke belegt ist,
kann die Kommunikation über die Schnittstelle Anforderungsdokument (zum Review)
unmittelbar stattfinden. Von der konkreten Typisierung der Datenschnittstellen 3
5
und
3
5,copy ist abstrahiert worden.
140
3.2 Notation der unteren Ebenen einer Prozesslandschaft
Mit Hilfe der Erweiterung eines Kommunikationskanals durch eine Initiator- und ei-
ne Responderrolle ist sichergestellt, dass eine Datenübertragung über eine Schnitt-
stelle s
1
nur genau dann stattfinden kann, wenn eine Markierungsfunktion den
Schnittstellen sinit und sresp mindestens je eine Marke zuordnet. Wie es zu die-
ser Belegung kommt, ist eine Designentscheidung des Modellierers. Eine perma-
nente Sende-/Empfangsbereitschaft kann beispielsweise dadurch implementiert wer-
den, dass diese Schnittstellen initial belegt sind und zu den Zugriffen (sinit , a) und
(sresp , a) jeweils zurückführende Zugriffe (a, sinit) und (a, sresp) modelliert werden.
Für die Analyse dynamischer Kommunikationseigenschaften ist die Betrachtung der
Initiator- und Responderrolle nützlich, da mit ihrer Hilfe der potentielle Nutzungs-
grad bereitgestellter Informationen und damit die Kommunikationseffizienz bezüg-
lich der Informationsverteilung gemessen werden kann. Da die Entwicklung eines
konkreten Beispiels aufgrund der durchzuführenden Parametrisierung und Simulation
einer Prozesslandschaft an dieser Stelle den Rahmen sprengen würde, sei hierfür auf
Abschnitt 4.2.2 verwiesen, in dem die Informationsverteilung am Beispiel der Pro-
zesslandschaft zur komponentenbasierten Softwareentwicklung ausführlich diskutiert
wird.
Für eine Menge von Kommunikationskanälen können Kapazität und Kostenfaktor für
ihre Nutzung durch zwei einfache Zuweisungsfunktionen formal ausgedrückt werden.
Definition 3.2.51. Sei CC = ∅ eine Menge von funktionsfähigen Kommunikations-
kanälen. Sei weiterhin CAP ⊆ R+ eine Menge möglicher Kanalkapazitäten (z.B.
gemessen in kBit pro Sekunde). Die Abbildung capacity ordnet jedem Kommunikati-
onskanal cc ∈ CC eine konkrete Datenkapazität zu:
capacity : CC → CAP
Definition 3.2.52. Sei CC = ∅ eine Menge von funktionsfähigen Kommunikations-
kanälen. Sei weiterhin COST ⊆ R+ eine Menge möglicher Kanalkosten (z.B. ge-
messen in Euro). Die Abbildung cost ordnet jedem Kommunikationskanal cc ∈ CC
konkrete Kosten zu, die bei seiner Nutzung anfallen:
cost : CC → COST
Beispiel:
Ein einfaches Beispiel für Kosten und Kapazitäten eines Kommunikationskanals ist ein
Faxgerät mit einer Kapazität von 14.000 Bit pro Sekunde, welches bei seiner Nutzung
0,12 Euro pro Minute an Kosten verursacht. Für eine reale Kostenberechnung werden
jedoch meist komplexere Modelle verwendet, die das zu übertragende Volumen, die
Kapazität des Kanals, eine Grundgebühr und die Nutzungsdauer berücksichtigen.
Im Rahmen der Process Landscaping-Analyse dynamischer Kommunikationseigen-
schaften wird die diskutierte Form der Zuweisung von Kapazitäten und Kostenma-
ßen an Kommunikationskanäle genutzt, um das Kommunikationsaufkommen in einer
verteilten Prozesslandschaft zu messen und damit die Bewertung der Kommunikati-
onseffizienz bezüglich der räumlichen Verteilung der beteiligten Aktivitäten durch-
führen zu können. Sie gilt als gut, wenn die Zuordnung von modellierten Prozessen
141
Formale Basis des Process Landscaping
zu einzelnen Orten zumindest für einen Großteil (> 50%) der beteiligten Orte zu
einem niedrigen Verhältnis von externem zu internem Kommunikationsaufkommen
führt (vgl. Abschnitt 2.3.5). Für die Diskussion eines konkreten Beispiels sei auch hier
wieder auf Abschnitt 4.2.2 verwiesen.
Um zeitabhängiges Ablaufverhalten innerhalb einer Prozesslandschaft analysieren zu
können, kann das zugrundeliegende Petrinetz um Zeitstempel erweitert werden. Diese
Zeitstempel beschreiben bezüglich einer globalen Uhr für die gesamte Prozessland-
schaft den frühesten Zeitpunkt, zu dem ein Informationsobjekt zum Schalten einer
Aktivität zur Verfügung steht. Die Werte der globalen Uhr repräsentieren damit Mo-
dellzeiten, die bei der Ausführung einer Prozesslandschaft bzw. eines sie repräsentie-
renden Petrinetzes berücksichtigt werden.
Definition 3.2.53. Sei PLbottom = (A,S,Z,AB) die dritte Ausbaustufe einer Pro-
zesslandschaft und Z die Menge der ganzen Zahlen. Die Abbildung timestamp defi-
niert den Zeitraum, den eine Schnittstelle mit einer Marke belegt ist, bevor letztere als
aktivierende Marke im Vorbereich einer Aktivität angesehen wird:
timestamp : S → Z
Konkret bedeutet beispielsweise der Wert 10, dass zu einem Zeitpunkt t = 100 eine
Aktivität zwar ein Informationsobjekt erzeugt und im Nachbereich ablegt, dieses aber
erst zum Zeitpunkt t = 110 für nachfolgende Aktivitäten zur Verfügung steht.
Eine Zeitbehaftung lässt sich bei Petrinetzen aber auch anders recht einfach beschrei-
ben: Jeder Ausgabekante z = (a, s) ∈ Z kann ein Ausdruck zugeordnet werden, der
einen Zahlenwert (integer) liefert. Dieser gibt, in Bezug auf eine globale Uhr, den frü-
hesten Zeitpunkt an, zu dem ein Informationsobjekt zum Schalten einer Aktivität zur
Verfügung steht. Prinzipiell ist jedes Netzelement geeignet, mit Zeitattributen versehen
zu werden [Bau96].
Der Zeitfaktor spielt besonders bei der Analyse der Kommunikationseffizienz bezüg-
lich der Prozessauslastung eine wichtige Rolle. Die Auslastung eines Prozesses ist
in Abschnitt 2.3.5 definiert als das Verhältnis der Zeitspanne, in der mindestens eine
Aktivität eines Prozesses aktiv ist, zur Gesamtzeit der Betrachtung.
Eine weitere Effizienzbetrachtung im Rahmen der Analyse dynamischer Kommunika-
tionseigenschaften bezieht sich auf den Informationsfluss innerhalb einer verteilten
Prozesslandschaft. Dieser sollte für jedes betrachtete Informationsobjekt eine Min-
destlänge nicht unterschreiten, um sogenannte Ping-Pong-Kommunikation [GW99b]
zu vermeiden.
Für die Berechnung der Länge eines Informationsflusses, nachfolgend als Pfadlän-
ge bezeichnet, wird die Pfadlänge eines konkreten Informationstyps berechnet, den
dieser, ausgehend von einer Aktivität a
1
an einem Ort o
1
, über verschiedene Akti-
vitäten an einem Ort o
2
zurücklegt, bevor er zur Aktivität an+1 an Ort o1 zurück-
gelangt. Im korrespondierenden Petrinetz müssen hierfür zwei externe Schnittstellen
s
1
, sn ∈ Sextern mit dem gleichen Typ assoziiert sein. Eine Pfadlänge berechnet sich
aus der Anzahl aller Aktivitäten und Schnittstellen, die der betrachtete Informationstyp
auf seinem Weg von einer externen Schnittstelle zur anderen passiert.
142
3.2 Notation der unteren Ebenen einer Prozesslandschaft
Definition 3.2.54. Sei PLbottom = (A,S,Z,AB) die dritte Ausbaustufe einer Pro-
zesslandschaft. Ein Pfad p innerhalb einer Prozesslandschaft PLbottom von einer Ak-
tivität a
1
zu einer Aktivität an+1 ist definiert als Folge von Aktivitäten und Schnittstel-
len:
p := (a
1
, s
1
, a
2
, s
2
, ..., sn, an+1)
Dabei gilt: ai ∈ A mit 1 ≤ i ≤ n+ 1,
si ∈ S mit 1 ≤ i ≤ n und
(a
1
, s
1
), (s
1
, a
2
), (a
2
, s
2
), ..., (sn, an+1) ∈ Z
Im Folgenden seien PLo
1
und PLo
2
zwei beliebige aber feste Ausschnitte einer Pro-
zesslandschaft PLbottom = (A,S,Z,AB) mit S = Sintern ∪ Sextern und o1, o2 ∈ O,
für die gilt, dass
 PLo
1
=(Ao
1
, So
1
, Zo
1
, AB) mit So
1
= Sintern
o
1
∪ Sextern
o
1
 PLo
2
=(Ao
2
, So
2
, Zo
2
, AB) und So
2
= Sintern
o
2
∪ Sextern
o
2
mit
– Ao
1
, Ao
2
⊂ A, Ao
1
∩Ao
2
= ∅ und
∀ a ∈ Ao
1
: local (a) = {o
1
}
∀ a ∈ Ao
2
: local (a) = {o
2
}
– Sintern
o
1
, Sintern
o
2
⊂ Sintern und So
1
∩ So
2
= ∅
– Sextern
o
1
, Sextern
o
2
⊂ Sextern
– Zo
1
, Zo
2
⊂ Z und Zo
1
∩ Zo
2
= ∅
Definition 3.2.55. Sei PLbottom =(A,S,Z,AB) die dritte Ausbaustufe einerProzess-
landschaft und S=Sintern ∪ Sextern . Seien weiterhin
• type∗ : S → DT ∗ die in Definition 3.2.49 eingeführte Abbildung, die den
Schnittstellen einer Prozesslandschaft Dokumenttypen zuordnet und
• documentid : DT ∗ → N die ebenfalls in Definition 3.2.49 eingeführte Abbil-
dung, die die Identitätsnummer eines Dokumenttyps ermittelt.
Schließlich seien s
1
, sn ∈ Sextern, für die gilt:
documentid
(
type∗(s
1
)
)
= documentid
(
type∗(sn)
)
Die Länge eines Pfades p = (a
1
, s
1
, a
2
, s
2
, ..., sn, an+1) mit n ∈ N innerhalb einer
Prozesslandschaft PLo
2
, der bei einer Aktivität a
1
∈ Ao
1
startet und bei einer Aktivität
an+1 ∈ Ao
1
endet, aber ansonsten vollständig in PLo
2
liegt, ist definiert als
pathlength(p) := 2n − 2
143
Formale Basis des Process Landscaping
Für die Aktivitäten und Schnittstellen auf einem solchen Pfad p müssen dabei die fol-
genden Bedingungen erfüllt sein:
a
1
, an+1 ∈ Ao
1
s
1
, sn ∈ Sextern
a
2
, a
3
..., an ∈ Ao
2
s
2
, ..., sn−1 ∈ Sintern
o
2
(a
1
, s
1
), (sn, an+1) ∈ Zo
1
(s
1
, a
2
), (a
2
, s
2
), ..., (sn−1, an) ∈ Zo
2
Bemerkung 3.2.56. Die Länge eines Pfades p lässt die Zugriffe (a
1
, s
1
) und
(sn, an+1) außer acht, da laut Definition nur derjeinige Teil des Pfades betrachtet
wird, der vollständig in PLo
2
liegt.
Beispiel:
Abbildung 3.34 zeigt einen relativ kurzen Pfad des Informationstyps Richtliniener-
weiterung, der als Vorschlag vom Qualitätsmanagement über eine verfeinerte Schnitt-
stelle an das Projektmanagement weitergeleitet, dort geprüft und beurteilt wird und
anschließend mit einem entsprechenden Vermerk an das Qualitätsmanagement zurück-
geschickt wird.
Richtlinienerweiterung
extrahieren
Richtlinienerweiterung
einarbeiten
Qualitätsmanagement Projektmanagement
verfeinerte
Schnittstelle
251 Richtlinienerweiterung (Vorschlag)
Richtlinienerweiterung (inkl. Vermerk)252
251
252
Annahme der
Richtlinienerweiterung
Weiterleitung der
Richtlinienerweiterung
252
Abbildung 3.34: Pfad des Informationstyps Richtlinienerweiterung
Der betrachtete Pfad p kann formuliert werden als p = (Richtlinienerweiterung
extrahieren, Richtlinienerweiterung (Vorschlag), Annahme der Richtlinienerweite-
rung, Richtlinienerweiterung (inkl. Vermerk), Weiterleitung der Richtlinienerweite-
rung, Richtlinienerweiterung (inkl. Vermerk), Richtlinienerweiterung einarbeiten). Er
startet am Standort Qualitätsmanagement, der die Prozesslandschaft PLo
1
reprä-
sentiert, durchläuft einen Teil des Standortes Projektmanagement (PLo
2
) und endet
144
3.2 Notation der unteren Ebenen einer Prozesslandschaft
schließlich wieder am Standort Qualitätsmanagement. Alle in Abbildung 3.34 dar-
gestellten Schnittstellen sind mit der Nummer 25 bezeichnet. Dies deutet an, dass
der dort dargestellte Pfad ausschließlich den des Informationstyps Richtlinienerweite-
rung repräsentiert. Damit gilt: documentid (Richtlinienerweiterung(Vorschlag)) =
documentid (Richtlinienerweiterung(inkl .Vermerk)).
Die Pfadlänge pathlength(p) beträgt in diesem Fall vier, da die Zugriffe (Richtlinien-
erweiterung extrahieren, Richtlinienerweiterung (Vorschlag)) und (Richtlinienerwei-
terung (inkl. Vermerk), Richtlinienerweiterung einarbeiten) bei der Zählung nicht be-
rücksichtigt werden.
Notation 3.2.57. Der längste mögliche Pfad innerhalb einer Prozesslandschaft PLo
2
,
der bei einer Aktivität a
1
∈ Ao
1
startet, über die Schnittstelle s
1
zur Prozesslandschaft
PLo
2
verläuft, über die Schnittstelle sn zur Prozesslandschaft PLo
1
zurückkehrt und
bei einer Aktivität an+1 ∈ Ao
1
endet, aber ansonsten vollständig in PLo
2
liegt, wird
mit
maxpath(a1, s1, sn)
bezeichnet.
Der kürzeste mögliche Pfad innerhalb einer Prozesslandschaft PLo
2
, der bei einer
Aktivität a
1
∈ Ao
1
startet, über die Schnittstelle s
1
zur Prozesslandschaft PLo
2
ver-
läuft, über die Schnittstelle sn zur Prozesslandschaft PLo
1
zurückkehrt und bei einer
Aktivität an+1 ∈ Ao
1
endet, aber ansonsten vollständig in PLo
2
liegt, wird mit
minpath(a1, s1, sn)
bezeichnet.
Zur Analyse der Kommunikationseffizienz bezüglich der Informationsflüsse in einer
Prozesslandschaft können die Pfadlängen verschiedener Informationstypen am Mini-
mum und Maximum aller möglichen Pfade gemessen und bewertet werden (vgl. Ab-
schnitt 2.3.5). Allgemein gilt dabei, dass eine kurze Pfadlänge zwischen Aktivitäten
verschiedener Orte auf Verbesserungspotential hinweist, soweit sie nicht aufgrund be-
stimmter Aufgabenverteilungen (z.B. Controlling-Aufgaben) explizit gewünscht ist. In
Abschnitt 4.2.2 wird dies am konkreten Beispiel diskutiert.
Mit den Erweiterungen einer Prozesslandschaft zur Analyse verschiedener, die Effi-
zienz beeinflussenden Eigenschaften kann die nächste Ausbaustufe einer Prozessland-
schaft formuliert werden.
Definition 3.2.58. Sei PLbottom = (A,S,Z,AB) die dritte Ausbaustufe einer Pro-
zesslandschaft. Sei weiterhin
• DT ∗ eine Menge von Dokumenttypen mit einer festen Anzahl an Attributen,
• type∗ eine Abbildung zur Zuordnung von Dokumenttypen dt∗ ∈ DT ∗ zu Schnitt-
stellen s ∈ S,
• Sinit eine Menge von Initiatorrollen,
145
Formale Basis des Process Landscaping
• Sresp eine Menge von Responderrollen,
• CAP ⊆ R+ eine Menge möglicher Kanalkapazitäten,
• COST ⊆ R+ eine Menge möglicher Kanalkosten,
• P eine Menge von Pfaden p (gemäß Definition 3.2.54) innerhalb der Prozess-
landschaft PLbottom ,
• capacity eine Abbildung zur Festlegung von Kanalkapazitäten gemäß Definition
3.2.51,
• cost eine Abbildung zur Festlegung von Kanalkosten gemäß Definition 3.2.52,
• timestamp eine Abbildung zur Festlegung von Aktivitätsdauern gemäß Defini-
tion 3.2.53 und schließlich
• pathlength eine Abbildung zur Bestimmung der Länge eines Pfades bezüglich
zweier fester Landschaftsausschnitte PLo
1
und PLo
2
für einen konkreten Infor-
mationstyp.
Die vierte Ausbaustufe einer Prozesslandschaft ist definiert als ein Tupel
PLcom := (A,S,Z,AB,NAME , O,name , local , switch , ZZ,CC,K, per , synch,
change, coded , priv ,mult , channel , valueZ ,M,M
′, fsource , fdest ,
DT ∗, Sinit , Sresp , CAP,COST,P, type
∗, capacity , cost , timestamp,
pathlength)
Bei dieser Ausbaustufe ist zu beachten, dass – im Gegensatz zu allen vorangegan-
genen Ausbaustufen – hier neben einer Erweiterung der Prozesslandschaft auch eine
Ersetzung vorgenommen worden ist: die Menge DT der Dokumenttypen und die Ab-
bildung type sind durch die MengeDT∗ der Dokumenttypen und die Abbildung type∗
ersetzt worden, um detailliertere Analysen durchführen zu können.
Mit der vierten Ausbaustufe einer Prozesslandschaft ist die formale Grundlage aller in
Abschnitt 2.3.3 diskutierten Analyseziele der Methode des Process Landscaping be-
schrieben. Am Beispiel einer Prozesslandschaft zur komponentenbasierten Software-
entwicklung kann diese nun eingesetzt werden, um die verschiedenen Analyseziele zu
validieren.
3.3 Einordnung in den Bereich der Petrinetze
Die Petrinetze als formale Basis des Process Landscaping haben sich als geeignetes
Instrument zur Beschreibung einer verteilten Prozesslandschaft erwiesen: Alle in der
Einleitung dieses Kapitels 3 aufgeführten Modellierungsanforderungen konnten erfüllt
werden; ihre Umsetzung ist jeweils an Ausschnitten eines durchgängigen Beispiels
146
3.3 Einordnung in den Bereich der Petrinetze
gezeigt worden. Für die Erstellung einer Prozesslandschaft nach dem Top-Down-
Vorgehen sind Eigenschaften eingeführt worden, die bereits aus verschiedenen exis-
tierenden Petrinetz-Varianten bekannt sind. So konnte jeweils eine Prozesslandschaft
– ausgehend von ihrer Basisdefinition – in ihrer ersten bis zu ihrer vierten Ausbaustufe
formuliert werden.
Innerhalb der letzten 40 Jahre ist eine Vielzahl von Petrinetz-Varianten sowie Petrinetz-
basierten Methoden und Werkzeugen entstanden. Sie werden in verschiedenen Be-
reichen wie beispielsweise technischen Steuerungssystemen und Workflowmanage-
mentsystemen eingesetzt. Viele dieser Petrinetz-Varianten sind spezielle Erweiterun-
gen zur Betrachtung spezifischer Eigenschaften eines modellierten Systems, oft in-
klusive der Betrachtung des dynamischen Verhaltens dieses Systems. Beispiele hierfür
sind unter anderem die Verhaltensspezifikation von CORBA-Systemen [BPS+99] oder
die Berücksichtigung unscharfer Zeitaussagen bei der Spezifikation von Hypermedia-
Anwendungen [Alf03].
Alle Petrinetz-Formalismen bieten den Vorteil, dass die formal spezifizierten Pro-
zessmodelle durch verschiedene Analyse- und Konsistenzbedingungen validiert und
teilweise auch verifiziert werden können. Nachteile der herkömmlichen Petrinetz-
Formalismen sind jedoch die hohe Komplexität und Größe schon bei sehr kleinen
Ausschnitten eines realen Prozessmodells [BBD+99]. Gerade die Komplexität konnte
durch die im Rahmen dieser Arbeit entwickelte abstrakte Petrinetz-Variante PLL ver-
ringert werden, die speziell zur Darstellung der oberen Ebenen einer Prozesslandschaft
entwickelt worden ist. Der Begriff abstrakt weist an dieser Stelle auf die Abstraktion
von Ablaufinformationen hin. Er wird damit anders als beispielsweise bei Padberg
genutzt [Pad98]. Dort wird unter dem Konzept abstrakter Petrinetze die Instanziie-
rung verschiedener Netzklassen verstanden, bei denen Datentyp und Netzstruktur als
abstrakte Parameter angesehen werden. Die angesprochene Komplexität in der Dar-
stellung eines Petrinetzes konnte in PLL dadurch verringert werden, dass kein zu-
sammenhängendes Netz für eine Prozesslandschaft gefordert wird, sondern lediglich
pro Abstraktionsebene alle beteiligten Aktivitäten, Schnittstellen und Zugriffe darzu-
stellen sind. Der Zusammenhang aller Aktivitäten einer Prozesslandschaft bleibt über
seinen Aktivitätenbaum transparent. Somit ist ein Teil der Komplexität durch die Aus-
lagerung von Informationen – über den Zusammenhang von und die hierarchischen
Beziehungen zwischen Aktivitäten – in den Aktivitätenbaum verringert worden. Die
Darstellung der Dynamik eines Netzes entfällt bei PLL völlig, was die Komplexität
noch weiter verringert. Auf diese Weise wird zwar die Aussagekraft vermindert, bei
traditionellen Petrinetzen mögliche Aussagen über den Ablauf eines Prozesses sind
jedoch hier gar nicht gefragt.
Das Vorgehen bei der Entwicklung und Anwendung verschiedener und damit auch ver-
schieden komplexer Petrinetz-Varianten zur Modellierung und Analyse einer Prozess-
landschaft mit der Methode des Process Landscaping entspricht den Strukturierungs-
merkmalen des Petrinetz-Baukastens [GE01], einer Arbeit der DFG-Forschergruppe
Petrinetz-Technologie. Dieser bietet die Möglichkeit, abhängig von Anforderun-
gen an ein Petrinetz und einem Anwendungsbereich eine geeignete Petrinetz-Vari-
147
Formale Basis des Process Landscaping
ante mit – soweit vorhanden – entsprechender Werkzeugunterstützung auszuwäh-
len. Dazu sind von der DFG-Forschergruppe drei verschiedene Sichten auf Petrinet-
ze entwickelt worden: die Anwendungsentwickler-Sicht, die Experten-Sicht und die
Werkzeugentwickler-Sicht.
 Die Anwendungsentwickler-Sicht hilft einem Anwendungsentwickler bei der
Suche nach einer Petrinetz-Notation, mit der er seine Anwendungsdomäne ge-
eignet darstellen kann und die ihn beim Entwicklungsprozess seiner Applikation
unterstützt.
 Die Experten-Sicht ermöglicht es einem Petrinetz-Experten, neue Typen und
Netzeigenschaften in einer einheitlichen formalen Struktur zu definieren, von
verschiedenen Netztypen zu profitieren und seine Ergebnisse dem Anwendungs-
entwickler geeignet zur Verfügung zu stellen.
 Die Werkzeugentwickler-Sicht erlaubt es schließlich einem Entwickler von
Software-Werkzeugen, passende Werkzeuge für bestimmte Aufgaben zu finden
und sie in geeigneter Form zu integrieren.
Eine semi-formale Petrinetz-Klassifikation bildet die gemeinsame Basis dieser drei
Sichten. Diese Klassifikation beinhaltet verschiedene Petrinetz-Typen, die über ihre
Attribute und Attributwerte strukturiert werden und beschreibt in einer objektorien-
tierten Form die Relationen zwischen den verschiedenen Netz-Typen. Abbildung 3.35
[BBD+99] zeigt diese Klassifikation als Klassendiagramm in UML-Notation. Es dient
hier als Diskussionsgrundlage zur Einordnung der für das Process Landscaping ver-
wendeten Petrinetze bzw. der Eigenschaften, die sie mit verschiedenen existierenden
Petrinetz-Typen gemeinsam haben.
Im Zentrum der Abbildung 3.35 steht die abstrakte Klasse Petri Net Type mit ihren
acht Attributen place, transition, tp-edge, pt-edge, activation, firing, marking und to-
ken. Die ersten drei Attribute beschreiben die Existenz von Stellen und Transitionen
als Bestandteile eines Petrinetzes sowie Kanten zwischen Stellen und Transitionen
(pt-edge) und umgekehrt (tp-edge). Des Weiteren ist die Klasse durch die Existenz
von Marken (token) auf Stellen, dem Aktivieren und Schalten von Transitionen und
der Markierung von Stellen bzw. Netzen charakterisiert.
Alle Klassifikationsmerkmale für Petrinetze sind in Abbildung 3.35 als separate Klas-
sen über eine Vererbungsrelation mit der abstrakten Klasse Petri Net Type verbunden.
Sie werden als Spezialisierungen der Klasse Petri Net Type eingeführt, die selbst wie-
derum sogenannte Spezialisierungspfade enthalten. Diese werden teilweise im Fol-
genden detaillierter dargestellt, sofern dies der Diskussion um die Einordnung der im
Rahmen des Process Landscaping genutzten Netzeigenschaften dient.
Klasse 1.1 repräsentiert das Klassifikationsmerkmal der Markierungsgrenze von Stel-
len und damit der maximal möglichen Anzahl an Marken auf einer Stelle. Diese kann
entweder individuell unterschiedlich oder aber einheitlich festgelegt werden. Für die
verschiedenen Ebenen einer Prozesslandschaft ist die Markierungsgrenze zwar auf
einen einheitlichen, aber nicht auf den konkreten Wert 1 festgelegt worden. Das für
148
3.3 Einordnung in den Bereich der Petrinetze
place
transition
tp-edge
pt-edge
activation
firing
marking
token
Petri Net Type
1.3
transitionPrePostSet : {fix, flexible}
1.2
edgeWeighting : {uniform, individual}
1.11 (Nets with Analysis)
1.10 (Nets with Verification)
verificationFacilities
1.9 (Nets with Structure)
structureType = {dynamic, static}
1.6
token : {dist-token, black-token}
1.7 (Timed Net)
clock : {local, global}
timedElement
authorizedElements
1.8 (Nets with Authorization)
1.5 (Net Systems)
initialMarking
1.4
markingStructuring : {uniform, individual}
1.1
markingLimit : {uniform, individual}
1.12 (Nets with Transformation)
transformationKind
transformationTarget
transformationProperty
TransformationSource
Abbildung 3.35: Objektorientierte Petrinetz-Klassifikation
149
Formale Basis des Process Landscaping
eine Prozesslandschaft erlaubte Kantengewicht, in Abbildung 3.35 repräsentiert als
Klasse 1.2, ist für die Darstellung der unteren Ebenen auf bis unendlich groß festge-
legt (vgl. Bemerkung 3.2.12, Seite 103).
Ein nächstes Klassifikationsmerkmal ist die Struktur des Vor- und Nachbereichs ei-
ner Transition (vgl. Klasse 1.3 in Abbildung 3.35). Diese ist für die oberen Ebenen
einer Prozesslandschaft irrelevant und daher nicht näher spezifiziert; für die unteren
Ebenen ist sie flexibel, da eine Transition sowohl unterschiedliche Eingangs- als auch
Ausgangsschaltverhalten haben kann (vgl. Definitionen 3.2.27 und 3.2.28, Seite 111).
Hier ist jedoch festzuhalten, dass die Definition der verschiedenen Schaltverhalten im
Rahmen des Process Landscaping nicht von den Funsoft-Netzen [Gru91] übernom-
men worden sind. Die Gründe hierfür sind bereits in Abschnitt 3.2.1.2 auf Seite 103
erläutert worden. Zusätzlich ist zu den bislang bekannten Ausgangsschaltverhalten das
abhängige Ausgangsschaltverhalten (vgl. Definition 3.2.26, Seite 111) neu eingeführt
worden.
Klasse 1.4 repräsentiert das Klassifikationsmerkmal der Markierungsstruktur. Für die
unteren Ebenen einer Prozesslandschaft ist diese einheitlich als ein Datentyp fest-
gelegt, der als kartesisches Produkt von fünf Mengen formuliert ist (vgl. Defini-
tion 3.2.49, Seite 138). Mit der Existenz einer Markierungsstruktur gilt gleichzeitig,
dass eine initiale Markierung für das den unteren Ebenen zugrundeliegende Petrinetz
gegeben sein muss (vgl. Klasse 1.5). Das Klassifikationsmerkmal der Autorisierung
wird beim Process Landscaping dagegen nicht berücksichtigt (vgl. Klasse 1.8 (Nets
with Authorization)).
Zeitbehaftete Petrinetze (Klasse 1.7 (Timed Net)) haben mit dem einer Prozessland-
schaft vierter Ausbaustufe zugrundeliegenden Petrinetz ebenfalls einige Eigenschaften
gemeinsam, denn auf den unteren Ebenen einer Landschaft wird jeder Stelle ein Zeit-
stempel zugewiesen, der – bezogen auf eine globale Uhr – den frühesten Zeitpunkt
angibt, zu dem ein Informationsobjekt zum Schalten einer Aktivität zur Verfügung
steht (vgl. Definition 3.2.53, Seite 142).
Das Klassifikationsmerkmal der Marke, dargestellt mit der Klasse 1.6, ist eng mit
dem der Markierungsstruktur verknüpft, denn durch den Dokumenttyp, der mit einer
festen Menge von Attributen versehen ist, werden für die unteren Ebenen einer Pro-
zesslandschaft unterscheidbare Marken verwendet. Für ihre oberen Ebenen ist dieses
Klassifikationsmerkmal nicht relevant. Abbildung 3.36 zeigt, dass – neben den bislang
diskutierten – insbesondere dieses Merkmal direkt zur Verwendung von High-Level-
Petrinetzen für die Darstellung der unteren Ebenen einer Prozesslandschaften führt,
deren Datenstruktur explizit gegeben ist. Diese Netztypen zeichnen sich unter ande-
rem dadurch aus, dass sie durch einfachere Petrinetze (Low-Level-Netze) ausgedrückt
werden können [Smi98]. Durch die in der vierten Ausbaustufe einer Prozesslandschaft
verwendete Stellentypisierung wird deutlich, dass das zugrundeliegende Petrinetz ge-
meinsame Merkmale mit Netzen höherer Ordnung und mit farbigen Petrinetzen hat
(vgl. Klassen 1.6.1.1.1.2 und 1.6.1.1.1.3 in Abbildung 3.36). Das Process Landsca-
ping verwendet hier zwar keine Inskriptionssprache wie beispielsweise die farbigen
Netze [Jen97] und beschreibt die Datenstruktur des Dokumenttypen auch nicht als al-
150
3.3 Einordnung in den Bereich der Petrinetze
gebraische Spezifikation wie die Prädikat-/Transitionsnetze [Gen86]. Trotzdem stützt
sich die verwendete Beschreibung als kartesisches Produkt auf algebraische Grundla-
gen. Damit kann die vierte Ausbaustufe einer Prozesslandschaft als ähnlich zu bzw.
verwandt mit den in Abbildung 3.36 durch die Klasse 1.6.1.1.1.2 repräsentierten alge-
braischen High-Level-Netzen angesehen werden.
token : {dist-token, black-token}
1.6
placetypes = colour sets
transguards = incidence matrices
1.6.1.1.1.4 (CPN'81 like)
dt-formalism = ML
datamodels = sets
marking = set.elements
arc-inscript = ML expressions
placetypes = ML types
transguards = ML expressions
complex-activation = var-bind
1.6.1.1.1.3 (CP'92 like)1.6.1.1.1.2 (Higher Order Nets)
dt-formalism = alg. HO Spec.
datamodels = HO algebras
marking = algebra.elements
arc-inscript = terms
transguards = predicates
placetypes = sorts
complex-activation = var-bind
dt-formalism = alg.Spec.
datamodels = algebras
marking = algebra.elements
arc-inscript = terms
transguards = equations
complex-activation = var-bind
1.6.1.1.1.1 (AHL-like)
arc-inscript
1.6.1.1.1
transguards
1.6.1.1.2
placetypes
1.6.1.1.3
placetypes
1.6.1.2.3
transguards
1.6.1.2.2
arc-inscript
1.6.1.2.1
invariant = {concrete, t-invariant}
1.6.1.3.2
invariant = symbolic
1.6.1.3.1
datastruct = implicit
1.6.1.2 (Foldings)
analysis = invariants
1.6.1.3 (HL Nets with Analysis)
datastruct = explicit
dt-formalism
1.6.1.1(HL Datatype)
1.6.1 (HL Nets)
token = dist-token
datastruct : {explicit, implicit}
datamodels
marking = data.elements
complex-activation
token = black-token
1.6.2 (LL Nets)
Abbildung 3.36: Klassifikationsmerkmal Marke
Bezüglich des Klassifikationsmerkmals der Netzstruktur (vgl. Klasse 1.9 (Nets with
Structure) in Abbildung 3.35) gilt für alle Ebenen einer Prozesslandschaft, dass das zu-
grundeliegende Petrinetz eine statische Struktur hat. Diese kann durch Verfeinerungen
sowohl bezüglich einer Aktivität als auch einer Schnittstelle modifiziert werden. Das
Konzept zur Verfeinerung einer Transition bzw. einer Stelle ist in der Literatur bereits
bekannt [Bau96]. Für das Process Landscaping ist dieses jedoch verändert worden, aus
Gründen, die in den Abschnitten 3.1.1 und 3.2.1.3 ausführlich diskutiert worden sind.
Die sukzessive Verfeinerung einer Prozesslandschaft führt gleichzeitig die Eigenschaft
der Hierarchie für das zugrundeliegende Petrinetz ein. Diese Eigenschaft ist in der Li-
151
Formale Basis des Process Landscaping
teratur bislang für High-Level-Netze wie beispielsweise den Funsoft-Netzen [Gru91]
oder den hierarchischen farbigen Netzen [Jen97] bekannt. Im Rahmen des Process
Landscaping wird sie jedoch bereits für die oberen Ebenen einer Prozesslandschaft
eingeführt und damit eine Petrinetz-Variante – PLL –, die ansonsten keine Eigen-
schaft höherer Petrinetze aufweist. Während die bekannten High-Level-Netze Hierar-
chieinformationen über ausgezeichnete Transitionen und Stellen (substitution transiti-
ons, fusion places [Jen97]) darstellen, werden diese Informationen bei PLL durch den
Aktivitätenbaum aufgezeigt. Letzterer wird für alle Ausbaustufen einer Prozessland-
schaft genutzt, so dass die Darstellungsform der traditionellen hierarchischen Netze
nicht mehr erforderlich ist.
Die beiden Klassifikationsmerkmale der Verifikation und der Analyse (vgl. Klassen
1.10 (Nets with Verification) und 1.11 (Nets with Analysis) in Abbildung 3.35) sind
für das Process Landscaping nicht relevant. Statt der Verifikation und der Analyse von
Netzstrukturen wie Lebendigkeit, Erreichbarkeit etc. werden konkrete Kommunikati-
onseigenschaften einer Prozesslandschaft mittels numerischer Analyse oder Simulati-
on validiert.
Das letzte der in Abbildung 3.35 aufgeführten Klassifikationsmerkmale ist das der
Transformation (vgl. Klasse 1.12 (Nets with Transformation)). Dieses Merkmal, in Ab-
bildung 3.37 [BBD+99] detaillierter dargestellt, unterscheidet zwischen verschiedenen
Formen einer Transformation. Sie starten meist von einem einfachen Petrinetz wie den
Stellen-/Transitionsnetzen und werden über verschiedene Vorgehensweisen zu High-
Level-Netzen erweitert (vgl. transformationKind add bzw. recode in Abbildung 3.37).
Demgegenüber stehen andere Vorgehensweisen, die von einem High-Level-Netz aus-
gehen und dieses auf einfache Netze abbilden (vgl. transformationKind ignore, encode
und decode). Das Process Landscaping folgt dem Prinzip, einem zunächst möglichst
einfachen Petrinetztyp nach und nach Eigenschaften hinzuzufügen (transformation-
Kind add), die schließlich zur vierten Ausbaustufe einer Prozesslandschaft mit einem
zugrundeliegenden algebraischen High-Level-Netz führen.
Die in Abbildung 3.35 aufgeführten Klassifikationsmerkmale sind hauptsächlich für
die unteren Ebenen einer Prozesslandschaft bzw. für die dritte und vierte Ausbau-
stufe einer Prozesslandschaft diskutiert worden. Dies liegt vor allem daran, dass mit
PLL für die oberen Ebenen (erste und zweite Ausbaustufe) einer Prozesslandschaft
aufgrund ihrer Abstraktion von Ablaufinformationen – und damit vom Kontrollfluss
innerhalb eines zugrundeliegenden Petrinetzes – eine für Petrinetze sehr untypische
Variante entstanden ist. In PLL ist gerade auf eine Stärke der Petrinetze – der Be-
trachtungsmöglichkeit dynamischer Systeme bzw. dynamischen Verhaltens auf Basis
einer statischen Netzstruktur – explizit verzichtet worden. PLL ist damit nur schwer in
das Klassifikationsschema einzuordnen. Dieser Netztyp kann auch nicht als abstrakte
Variante eines einfachen Petrinetzes bezeichnet werden, da er mit seinem Verfeine-
rungskonzept für Aktivitäten und Schnittstellen sowie der daraus resultierenden hier-
archischen Struktur typische Eigenschaften der High-Level-Netze aufweist.
Bezüglich der Darstellungsmöglichkeit für Informationsobjekte und Aktivitäten ist
PLL mit Datenflussdiagrammen (DFD) [Bal96] vergleichbar. Bei Letzteren können
152
3.3 Einordnung in den Bereich der Petrinetze
transformationKind
transformationTarget
transformationProperty
transformationSource
1.12
1.12.2.1.2.1(CPN) {E}
analysis = {place invariants, transition invariants}
preserved-props = {boundedness, liveness, fairness}
1.12.2.1.2
transformationSource = CPN
transformationTarget = PT
1.12.1.2.4.1
transformationSource = PT
transformationTarget = AHL
transformationSource = AHL
transformationTarget = PT
1.12.1.1.2.1{E}
transformation
transformationSource = PT
transformationTarget = Decorated_Occurrence_Net
1.12.3.4.1
added : dt-formalism
1.12.1.2.4
1.12.2.1.3
transformationSource = HOFN
transformationTarget = AHL
1.12.2.1.1 {E}
transformationSource = AHL
transformationTarget = PT
ignored : dt-formalism
1.12.1.1.2
1.12.3.4
recoded : netstructure
transformationProperty = behavior preserving
1.12.3.2.1
transformationSource = AHL
transformationTarget = HOFN
transformationKind = encode
codeForm = data
codeTo = netstructure
1.12.2.1
added : marking
1.12.1.2.5
added : facts
1.12.1.2.3
added : time
1.12.1.2.2
added : data
1.12.1.2.1
ignored : flexarcs
1.12.1.1.3
ignored : data
1.12.1.1.1
transformationKind : decode
codeForm = netstructure
codeTo = data
1.12.2.2
recoded : roles
1.12.3.3
recoded : dt-formalism
1.12.3.2
recoded : data
1.12.3.1
transformationKind = add
added : model_element
property = behavior reflecting
1.12.1.2
transformationKind = ignore
ignored : model_element
property = behavior preserving
1.12.1.1
1.12.3
transformationKind = recode
recoded = model_element1.12.2
transformationKind : {encode, decode}
codeForm : model_element
codeTo : model_element
transformationProperty = behavior preserving
transformationKind : {add, ignore}
1.12.1
Abbildung 3.37: Klassifikationsmerkmal Transformation
153
Formale Basis des Process Landscaping
die Funktionen als Aktivitäten einer Prozesslandschaft interpretiert werden. Zusätz-
lich gibt es die Möglichkeit der Modellierung von Datenspeichern, die jedoch für die
obersten Ebenen einer Prozesslandschaft nicht von Bedeutung sind und daher keine
Verwendung finden. Für die Wahl von PLL statt der DFD zur Modellierung der obe-
ren Ebenen haben zwei Gründe gesprochen: Zum einen hätten die DFD mit größerem
Aufwand um Verfeinerungskonzepte erweitert und angepasst werden müssen. Dies
liegt unter anderem daran, dass bei einem DFD der Fokus eindeutig auf der Darstel-
lung von Daten (in Form von Datenflüssen, Datenspeichern und Schnittstellen) liegt,
während die Petrinetze den Fokus eher auf deren Verarbeitung legen (in Form von
sequentiell und/oder parallel auszuführenden Aktivitäten). Ein zweiter Grund für die
Entwicklung und den Einsatz von PLL ist die Verhinderung eines Notationsbruchs,
der bei der Verwendung von DFDs für die oberen Ebenen einer Prozesslandschaft
und dem Einsatz von Petrinetzen für die unteren Ebenen vorhanden wäre. Ein solcher
Notationsbruch birgt immer die Gefahr von Inkonsistenzen. Mit PLL ist lediglich
von – wenn auch typischen – Eigenschaften eines traditionellen Petrinetzes abstrahiert
worden, die für den Übergang zur dritten Ausbaustufe einer Prozesslandschaft wieder
hinzugefügt wurden.
Insgesamt hat sich somit bei der Suche nach einer geeigneten Petrinetz-Variante zur
Unterstützung des Process Landscaping aus der Sicht eines Anwenders keine Varian-
te aus dem Petrinetz-Baukasten gefunden, die den Anforderungen zur Erstellung der
oberen Ebenen einer Prozesslandschaft genügt. Daher ist ein Wechsel zur Experten-
Sicht erfolgt, um verschiedene Petrinetz-Typen zu entwickeln, die der Modellierung
und Analyse von verteilten Prozesslandschaften unterschiedlicher Ausbaustufen die-
nen. Während die Methode, bedingt durch ihr Top-Down-Vorgehen, jedoch nachein-
ander alle eingeführten Petrinetz-Varianten nutzt, stellt der Petrinetz-Baukasten eine
Sammlung verschiedener Varianten dar, aus denen sich ein Anwender die für ihn je-
weils passende auswählen kann. Über die Klassifikation der Netztypen werden zwar
ihre Relationen untereinander beschrieben, ein Übergang zwischen ihnen im Rahmen
einer gemeinsamen Anwendung wird hier jedoch nicht unterstützt.
Eine Werkzeugunterstützung für die Anwendung der Methode des Process Landsca-
ping ist bislang noch nicht diskutiert worden. Hierfür ist zunächst die Werkzeug-
entwickler-Sicht eingenommen worden, um aus der Menge der bereits vorhandenen
Petrinetz-Werzeuge geeignete zu finden und diese zu integrieren. Die Werkzeugunter-
stützung ist jedoch Gegenstand des Kapitels 5 und wird daher an dieser Stelle nicht
weiter diskutiert.
154
Kapitel 4
Validation der Analysemethoden
Neben der Modellierung einer verteilten Prozesslandschaft bildet die Analyse einen
zweiten Schwerpunkt des Process Landscaping. Die Analysemethoden und ihre Zie-
le, die Untersuchung von Kommunikationseigenschaften einer Prozesslandschaft, sind
bereits in Abschnitt 2.3 motiviert und erläutert worden. Die Modellierung einer Pro-
zesslandschaft, die die Aktivitäten und Abläufe der komponentenbasierten Software-
entwicklung darstellt und in diesem Kapitel zur Validation der Analysemethoden her-
angezogen wird, ist in Abschnitt 2.2.1 eingeführt.
Die Beispielprozesslandschaft wird sowohl einer statischen als auch einer dynami-
schen Analyse unterzogen. Allgemein befasst sich die statische Analyse mit der Mes-
sung und Bewertung von Attributwerten einer gegebenen Prozesslandschaft ohne ihre
direkte Ausführung. Bei der dynamischen Analyse wird die Prozesslandschaft simu-
liert, um Informationen über Kommunikationseigenschaften wie die durch Kommuni-
kation entstehende Prozessauslastung oder durch das Kommunikationsverhalten ent-
stehende Kosten zu erhalten.
Die Validation der beiden Analysemethoden gibt Auskunft über deren Eignung und
Aussagekraft für ihre jeweilige Aufgabenstellung. Zeigler et al. definieren die Valida-
tion als „ ... the process of testing a model for validity ... where the validity answers the
question of whether it is impossible to distinguish the model and system in the expe-
rimental frame of interest“ [ZPK00]. Der Experimentierrahmen spezifiziert dabei die
Bedingungen bzw. die inhaltlichen Aspekte, unter denen ein System betrachtet wird.
Wird diese Definition auf die Validation der Analysemethoden des Process Landsca-
ping angewandt, müssen die bezüglich der Kommunikation innerhalb einer Prozess-
landschaft gemessenen Werte auf ihre Gültigkeit hin überprüft werden. Der Begriff der
Gültigkeit umfasst hier insbesondere auch den Nutzen der über die Werte gemessenen
und zu bewertenden Eigenschaften der Prozesslandschaft. Derniame et al. beschreiben
die Validation als „The process of evaluating the useful properties of a model, by in-
spection, simulation or test“ [DKW99] und zielen damit ebenfalls auf die Nützlichkeit
von Modelleigenschaften ab.
Die Struktur dieses Kapitels folgt den in Abschnitt 2.3 festgelegten Analysezielen, die
155
Validation der Analysemethoden
sich durch die Untersuchung statischer und dynamischer Kommunikationseigenschaf-
ten überprüfen lassen. Für die Analyse statischer Kommunikationseigenschaften wird
in Abschnitt 4.1.1 zunächst ein Überblick über die Ausprägung der Eigenschaften der
in PLL notierten Beispielprozesslandschaft gegeben. Für diese Ausprägung werden
die Kommunikationskostenfaktoren pro Standort und für verschiedene Abstraktions-
ebenen berechnet. Anschließend wird für unterschiedliche Optimierungsansätze (vgl.
Abschnitt 2.3.4) die bezüglich der Kommunikationskosten jeweils günstigste Lösung
identifiziert und diskutiert. Die Ergebnisse der so durchgeführten Analyseschritte am
konkreten Beispiel werden anschließend unter dem Aspekt ihres allgemeinen Nutzens
untersucht.
Für die Analyse dynamischer Kommunikationseigenschaften wird in Abschnitt 4.2
ebenfalls zunächst ein Überblick über die Struktur der Beispielprozesslandschaft
PLcom und die Ausprägung ihrer Eigenschaften gegeben. Nach der Analyse der Aus-
gangsbasis in Abschnitt 4.2.2.1 wird in Abschnitt 4.2.2.2 entlang eines konkreten Sze-
narios ein modifiziertes Simulationsmodell analysiert. Dabei wird überprüft, inwieweit
die Modifikationen Auswirkungen auf die Effizienz der Beispielprozesslandschaft ha-
ben. Beide Analysedurchläufe betrachten dabei insbesondere die in Abschnitt 2.3.3 de-
finierten Eigenschaften Kommunikationsaufkommen, Prozessauslastung, durchschnitt-
liche Pfadlänge und Initiator/Responder-Erfüllungsrate, die die Effizienz einer Pro-
zesslandschaft bezüglich ihres Kommunikationsverhaltens maßgeblich beeinflussen.
Abschließend wird in Abschnitt 4.2.3 auch für die Analyse dynamischer Kommunika-
tionseigenschaften eine Nutzenbetrachtung durchgeführt.
Die Basisdaten sowohl für die Analyse statischer als auch dynamischer Kommuni-
kationseigenschaften sind in den Abschnitten 4.1 und 4.2 nicht detailliert aufgeführt.
Sie betreffen insbesondere alle Aktivitäten sowie ihre geografische Verteilung inner-
halb der Prozesslandschaft, alle Dokumente und existierende Kommunikationskanäle
inklusive ihrer Attributierung. Diese und weitere für die Analysen notwendigen Ba-
sisdaten finden sich in Anhang A. Er ist unterteilt in Informationen über die Struktur
der Prozesslandschaft (Anhang A.1) und über die Wertebelegungen der instanziier-
ten Landschaft sowohl für die Analyse statischer (Anhang A.2) als auch dynamischer
Kommunikationseigenschaften (Anhang A.3).
4.1 Analyse statischer Kommunikationseigenschaften
Die Analyse der Kommunikationsstruktur einer Prozesslandschaft PLtop−com kann
aufgrund fehlender Informationen zum Ablauf und zum Kommunikationsverhalten nur
statisch erfolgen. Im zugrundeliegenden Petrinetz wird dazu das Verhältnis zwischen
den zur internen und externen Kommunikation genutzten Kommunikationskanälen be-
trachtet. Die zugehörigen Attribute werden pro Kommunikationskanal ausgewertet.
Im Rahmen des Process Landscaping lässt sich die statische Analyse als die Unter-
suchung des Aufbaus der Kommunikationsinfrastruktur einer Prozesslandschaft defi-
nieren, die anhand vorgegebener Attribute von Kommunikationskanälen und daraus
156
4.1 Analyse statischer Kommunikationseigenschaften
berechenbaren Kommunikationskostenfaktoren erfolgt. Aufgrund dieses Kkf – und
der fehlenden Ablaufinformationen – ist der Abstraktionsgrad eines realen kompo-
nentenbasierten Softwareentwicklungsprozesses verglichen mit seiner Darstellung als
Prozesslandschaft PLtop−com relativ hoch:
 Der Kkf repräsentiert Verhältnisse zwischen internen und externen Kommuni-
kationskosten, er zeigt nicht die absoluten Kommunikationskosten einer Pro-
zesslandschaft auf (vgl. Abschnitt 2.3.4). Je höher also der Kkf , desto ungünsti-
ger ist die Aufteilung der Kosten auf interne und externe Kommunikationskanä-
le.
 Die Kosten für die Nutzung eines Kommunikationskanals als Bestandteil des
Kkf werden abstrakt auf einer Skala von eins bis fünf gemessen: In Abhängig-
keit der Belegung der Kommunikationsattribute wird einem Kanal jeweils ein
Kostenpunkt zugeordnet, falls
synch = 1 oder synch = 0
coded = 1
change = 0
priv = 0
mult = 1
Eine Analyse auf einem solchen Abstraktionsniveau muss ein konkretes Ziel voraus-
setzen, um sinnvoll zu sein. Ansonsten sind die resultierenden Zahlenwerte zu abstrakt,
um beispielsweise eine korrekte Bewertung des Anstiegs oder der Senkung von Ko-
stenfaktoren durchführen zu können. Daher dient die nachfolgende Diskussion der
Ausgangsbasis in Abschnitt 4.1.1 zunächst dem Verständnis der Analyseschritte und
der Erläuterung der wichtigsten berechneten Werte. In Abschnitt 4.1.2.2 werden diese
Werte zur vergleichenden Analyse herangezogen, um bezüglich verschiedener Opti-
mierungsziele die beste Lösung zu identifizieren.
4.1.1 Struktur der Prozesslandschaft PLtop−com
Die in Abschnitt 2.2.1 eingeführte Beispielprozesslandschaft ist nach logischen Ge-
sichtspunkten modelliert. Um bei der Analyse auch die geografische Verteilung der
Aktivitäten zu berücksichtigen, ist die Prozesslandschaft zunächst in ihre lokale Sicht
umstrukturiert worden. Diese Umstrukturierung ist gemäß der in Abschnitt 3.2.2.1
formulierten Definition 3.2.44 und Konsistenzbedingung 3.2.46 erfolgt: Während die
Definition 3.2.44 Anzahl und Struktur der Aktivitäten in einer lokalen Sicht festlegt,
beschreibt die Konsistenzbedingung 3.2.46 die oberen Grenzen für die Anzahl der
Schnittstellen, die sich durch die Umstrukturierung aus der logischen Sicht ergibt.
Abbildung 4.1 zeigt die lokale Sicht auf den Aktivitätenbaum der Prozesslandschaft.
Diese bildet den Ausgangspunkt der Analyse. Waren in der logischen Sicht noch drei
157
Validation der Analysemethoden
Abstraktionsebenen modelliert, ist die lokale Sicht zunächst auf zwei Abstraktionsebe-
nen beschränkt worden.
Komponentenbasierte Softwareentwicklung
Zentrale
Außenstelle - 1
Außenstelle - 2: Komponentenentwicklung - 3
Anwendungsentwicklung
Kundenlokation
Managementlokation
Qualitätsmanagement - Z
Komponentenentwicklung - 1
Komponentenentwicklung - 2
Qualitätsmanagement - A
Außenstelle - 4: Komponentenentwicklung - 5
Außenstelle - 3: Komponentenentwicklung - 4
 
Abbildung 4.1: Lokale Sicht der Beispielprozesslandschaft PLtop−com
Auf der obersten Ebene der lokalen Sicht existieren insgesamt fünf Orte, eine Zen-
trale und vier Außenstellen. Die Zentrale ist in je einen Standort für das Applica-
tion Engineering (Standort Anwendungsentwicklung), das Projektmanagement inklu-
sive des Domain Engineering (Standort Managementlokation), ein Qualitätsmanage-
ment (Standort Qualitätsmanagement-Z) und einen Standort für das Component Engi-
neering (Standort Komponentenentwicklung-1) unterteilt. Zusätzlich existiert hier ei-
ne Kundenlokation, an der einige Aktivitäten ausgeführt werden, die intensive Zu-
sammenarbeit mit dem Kunden erfordern. An allen Außenstellen werden Aktivitä-
ten zur Entwicklung weiterer Komponenten durchgeführt (Komponentenentwicklung-2
bis Komponentenentwicklung-5). Außenstelle-1 weist zusätzlich noch eigene Quali-
tätsmanagement-Aktivitäten auf (Standort Qualitätsmanagement-A). Für alle anderen
Außenstellen übernimmt das Qualitätsmanagement der Zentrale die Test- und Review-
aktivitäten.
Tabelle 4.1 gibt einen Überblick über die Komplexität der Beispielprozesslandschaft.
Durch die Verteilung einiger Aktivitäten auf mehrere Standorte hat sich beim Wech-
sel von der logischen zur lokalen Sicht die Gesamtzahl der zu betrachtenden Ak-
tivitäten erhöht. Des Weiteren sind den verschiedenen Datenflüssen insgesamt 269
158
4.1 Analyse statischer Kommunikationseigenschaften
(99 plus 170) Kommunikationskanäle zur internen und externen Kommunikation zu-
geordnet. Diese sind jeweils mit Kommunikationsattributen versehen und für die Ana-
lyse mit 3228 (zwölf Werte pro Kommunikationskanal) konkreten Werten belegt. Alle
Kommunikationskanäle wurden so instanziiert, dass sie funktionsfähig sind (vgl. Ab-
schnitt 3.1.3). Für eine detaillierte Auflistung aller Aktivitäten, ihrer Verteilung sowie
bestehender Kommunikationskanäle sei auf Anhang A.1 verwiesen. Im Anhang A.2
sind die genauen Werte aller der nachfolgenden Analyse zugrundeliegenden Kommu-
nikationsattribute aufgeführt.
Anzahl
Dokumente 69
Aktivitäten 114
Abstraktionsebenen 2
Orte auf oberster Ebene 5
Orte auf unterer Ebene 10
Kommunikationskanäle zur externen Kommunikation 99
Kommunikationskanäle zur internen Kommunikation 170
Attribute pro Kommunikationskanal 12
Wertzuweisungen an Aktivitäten 114
Wertzuweisungen an Kommunikationskanäle 3228
Tabelle 4.1: Aufbau der Prozesslandschaft
4.1.2 Analyse der Kommunikationsinfrastruktur einer Prozessland-
schaft PLtop−com
4.1.2.1 Analyse der Ausgangsbasis
Für jeden der zehn Standorte der Beispielprozesslandschaft sind die nachfolgend auf-
geführten Eigenschaften gemäß den in den Abschnitten 2.3.4 und 3.1.3 eingeführten
Definitionen gemessen bzw. berechnet worden:
 Kopplungsdichte zwischen zwei ausgewählten Orten
 Kopplungsdichte pro Ort (Kopplungsdichte bzgl. aller mit diesem kommunizie-
renden Ort)
 Kopplungskomplexität zwischen Orten
 Kopplungskomplexität pro Ort (Kopplungskomplexität bzgl. aller mit diesem
kommunizierenden Ort)
 Kopplungszahl
 Kohäsionsdichte pro Ort
159
Validation der Analysemethoden
 Kohäsionskomplexität pro Ort
 Kohäsionszahl
Die einzelnen Ergebnisse sind in den Tabellen 4.2 bis 4.5 aufgeführt. Sie bilden die
Grundlage zur Berechnung der Kommunikationskostenfaktoren Kkf , die unabhängig
vom konkret verfolgten Optimierungsansatz minimal gehalten werden sollen, um eine
mit Blick auf die statischen Kommunikationseigenschaften möglichst effiziente Pro-
zesslandschaft zu erhalten.
Kopplungs- Kopplungs-
Ort 1 Ort 2 dichte komplexität
Kundenlokation Anwendungsentwicklung 5 4
Kundenlokation Managementlokation 6 5
Kundenlokation Qualitätsmanagement-Z 2 2
Anwendungsentwicklung Managementlokation 13 7
Anwendungsentwicklung Qualitätsmanagement-Z 12 5
Anwendungsentwicklung Komponentenentwicklung-1 1 1
Anwendungsentwicklung Komponentenentwicklung-2 1 1
Anwendungsentwicklung Komponentenentwicklung-3 1 1
Anwendungsentwicklung Komponentenentwicklung-4 1 1
Anwendungsentwicklung Komponentenentwicklung-5 1 1
Managementlokation Komponentenentwicklung-1 6 2
Managementlokation Komponentenentwicklung-2 6 2
Managementlokation Komponentenentwicklung-3 6 2
Managementlokation Komponentenentwicklung-4 6 2
Managementlokation Komponentenentwicklung-5 6 2
Managementlokation Qualitätsmanagement-Z 4 3
Managementlokation Qualitätsmanagement-A 1 1
Komponentenentwicklung-1 Qualitätsmanagement-Z 4 4
Komponentenentwicklung-2 Qualitätsmanagement-A 4 4
Komponentenentwicklung-3 Qualitätsmanagement-Z 4 4
Komponentenentwicklung-4 Qualitätsmanagement-Z 4 4
Komponentenentwicklung-5 Qualitätsmanagement-Z 4 4
Qualitätsmanagement-A Qualitätsmanagement-Z 1 1
Tabelle 4.2: Kopplung zwischen zwei Orten
Bei den berechneten Werten für die Kopplungsdichte zwischen zwei Orten (vgl. Tabel-
le 4.2) fallen diejenigen zwischen der Anwendungsentwicklung und der Management-
lokation und zwischen der Anwendungsentwicklung und dem zentralen Qualitätsma-
nagement auf, da hier die Werte deutlich höher als bei anderen Kopplungsdichten lie-
gen. Führt man sich aber die Aktivitäten an den Standorten Managementlokation und
160
4.1 Analyse statischer Kommunikationseigenschaften
Qualitätsmanagement-Z vor Augen, werden die höheren Werte verständlich, da die-
se vor allem Kontroll- und Steuerungsaufgaben für die gesamte Softwareentwicklung
umfassen.
Ort Kopplungsdichte Kopplungskomplexität
Kundenlokation 13 9
Anwendungsentwicklung 35 12
Managementlokation 54 12
Komponentenentwicklung-1 11 6
Komponentenentwicklung-2 11 6
Komponentenentwicklung-3 11 6
Komponentenentwicklung-4 11 6
Komponentenentwicklung-5 11 6
Qualitätsmanagement-Z 35 8
Qualitätsmanagement-A 6 6
Tabelle 4.3: Kopplung eines Ortes
Die in Tabelle 4.3 aufgeführte Kopplungsdichte der Orte Managementlokation, Quali-
tätsmanagement-Z und Anwendungsentwicklung ist erwartungsgemäß ebenfalls höher.
Sie bezieht sich auf die Anzahl aller Aktivitäten an anderen Orten, die mit Aktivitä-
ten am betrachteten Ort kommunizieren. Die Werte der Kopplungskomplexitäten für
die Kommunikationskanäle pro Standort (zu allen anderen Standorten der Prozess-
landschaft) liegen meist knapp unter der Summe ihrer Kopplungskomplexitäten zu
einzelnen anderen Standorten (vgl. Tabelle 4.2). Bei der Berechnung dieser Summe ist
zu beachten, dass mehrfach existierende Ausprägungen eines Kommunikationskanals
nur einmal gezählt werden. Das Ergebnis lässt darauf schließen, dass Aktivitäten, die
innerhalb der Zentrale ausgeführt werden, für die Kommunikation zur Außenstelle-1
ähnlich ausgeprägte Kanäle wie zu den übrigen Außenstellen verwenden, ansonsten
jedoch eine relativ heterogene Kommunikationsinfrastruktur vorliegt.
Zur Berechnung der verschiedenen Kommunikationskostenfaktoren Kkf müssen auch
die Kohäsionsdichten und -komplexitäten der einzelnen Standorte bestimmt werden.
Diese sind in Tabelle 4.4 aufgeführt.
Bei einem Vergleich der Kohäsionsdichten zu den in Tabelle 4.2 aufgeführten Kopp-
lungsdichten fällt auf, dass diese bei den Standorten Komponentenentwicklung-1 bis
Komponentenentwicklung-5 deutlich höher liegen (vgl. Tabelle 4.4). Dies lässt sich je-
doch durch die Aufgabenstellung der dort durchgeführten Aktivitäten erklären. Dort
werden die einzelnen Komponenten des zu erstellenden Gesamtsystems entwickelt.
Die Kommunikation zur Zentrale, die die Kopplungsdichte beeinflusst, erfolgt daher
hauptsächlich aufgrund von Prüfungs- und Steuerungsaktivitäten sowie von Auslie-
ferungen der entwickelten Komponenten. Ansonsten werden die Aufgaben losgelöst
vom Kernprozess des Application Engineering, aber mit verstärkter interner Kommu-
nikation, durchgeführt. Letzteres führt wiederum zu den vergleichsweise hohen Kopp-
lungsdichten.
161
Validation der Analysemethoden
Ort Kohäsionsdichte Kohäsionskomplexität
Kundenlokation 1 1
Anwendungsentwicklung 20 6
Managementlokation 19 12
Komponentenentwicklung-1 18 5
Komponentenentwicklung-2 18 5
Komponentenentwicklung-3 18 5
Komponentenentwicklung-4 18 5
Komponentenentwicklung-5 18 5
Qualitätsmanagement-Z 23 8
Qualitätsmanagement-A 17 7
Tabelle 4.4: Kohäsion eines Ortes
Die Komplexitäten der Kommunikationskanäle sind bei interner und externer Kom-
munikation der einzelnen Standorte jeweils ähnlich. Hier fällt die vergleichsweise ho-
he Komplexität sowohl der Kopplung als auch der Kohäsion des Standortes Manage-
mentlokation auf. Dieser Standort kommuniziert jedoch als einziger mit allen anderen
Standorten der Prozesslandschaft (der Standort Anwendungsentwicklung weist keinen
Kommunikationskanal zum Standort Qualitätsmanagement-A auf) und beinhaltet au-
ßerdem zwei aus logischer Sicht unterschiedliche Aufgabenbereiche (Projektmana-
gement und Domain Engineering), die jeweils unterschiedliche Anforderungen an die
Kommunikationsinfrastruktur haben. Beide Aspekte zusammen verursachen die in den
Tabellen 4.3 und 4.4 aufgeführten erhöhten Komplexitätswerte.
Ort Anzahl Aktivitäten Kopplungszahl Kohäsionszahl
Kundenlokation 3 3 2
Anwendungsentwicklung 14 13 14
Managementlokation 16 12 13
Komponentenentwicklung-1 13 8 12
Komponentenentwicklung-2 13 8 12
Komponentenentwicklung-3 13 8 12
Komponentenentwicklung-4 13 8 12
Komponentenentwicklung-5 13 8 12
Qualitätsmanagement-Z 8 6 8
Qualitätsmanagement-A 8 6 8
Tabelle 4.5: Kopplungs- und Kohäsionszahl eines Ortes
Die berechneten Kopplungs- und Kohäsionszahlen in Tabelle 4.5 zeigen auf, wie vie-
le der Aktivitäten pro Standort an interner bzw. an externer Kommunikation betei-
ligt sind. Die Aktivitäten am Standort Anwendungsentwicklung sind fast vollständig
162
4.1 Analyse statischer Kommunikationseigenschaften
sowohl an interner als auch an externer Kommunikation beteiligt. Die Aktivitäten
der Standorte Komponentenentwicklung-1 bis Komponentenentwicklung-5 sind dage-
gen hauptsächlich an interner Kommunikation beteiligt. Diese Verschiebung lässt sich
ebenfalls mit den Aufgaben der an den jeweiligen Standorten durchgeführten Aktivitä-
ten erklären. Damit erweisen sich die Kopplungs- und Kohäsionszahlen insbesondere
für den Vergleich verschiedener Situationen und ihrer Interpretation als hilfreich.
Die bislang erörterten Kopplungs- und Kohäsionswerte der Beispielprozesslandschaft
PLtop−com machen den ersten Teil der für eine Analyse der Kommunikationskosten
notwendigen Daten aus. Der zweite Teil beinhaltet Informationen über das eingesetzte
Kostenmodell. Da auf den betrachteten Ebenen der Prozesslandschaft keine Ablaufin-
formationen berücksichtigt worden sind, wird im Rahmen der Analyse die Nutzungs-
häufigkeit jedes Kommunikationskanals abstrakt auf einer Skala von eins bis zehn fest-
gelegt (zur Motivation vgl. Abschnitt 2.3.4). Auch die Kosten pro übertragener Infor-
mationseinheit werden für jeden Kanal auf einer Skala von eins bis fünf bestimmt.
Diese ergibt sich aus der Anzahl möglicher Kostenpunkte, die einem Kommunikati-
onskanal in Abhängigkeit der Ausprägung seiner Attribute zugeordnet worden sind
(vgl. Abschnitt 4.1).
Insgesamt ist es mit dem so aufgebauten Kkf
Kopplungsdichte(o) × (Nutzungsha¨ufigkeit ×Kosten) pro externer Kanal
Koha¨sionsdichte(o) × (Nutzungsha¨ufigkeit ×Kosten) pro interner Kanal
möglich, auf einer einfachen Bemessungsgrundlage für die statischen Kommunika-
tionseigenschaften einer Prozesslandschaft zu bleiben. Für die konkreten Werte der
Nutzungshäufigkeit pro Kommunikationskanal und Kosten pro Informationseinheit sei
wieder auf Anhang A.2 verwiesen. Nachfolgend sind in Tabelle 4.6 die berechneten
Kommunikationskostenfaktoren für jeden Standort aufgeführt.
Ort Kkf
Kundenlokation 186,33
Anwendungsentwicklung 8,87
Managementlokation 6,14
Komponentenentwicklung-1 0,26
Komponentenentwicklung-2 0,26
Komponentenentwicklung-3 0,26
Komponentenentwicklung-4 0,26
Komponentenentwicklung-5 0,26
Qualitätsmanagement-Z 2,28
Qualitätsmanagement-A 0,15
Tabelle 4.6: Kommunikationskostenfaktoren aller Orte
Der Kkf der Kundenlokation fällt hier deutlich aus dem Rahmen. Die interne Kom-
munikation an diesem Ort ist nur unvollständig modelliert, da sie für den Software-
163
Validation der Analysemethoden
entwicklungsprozess kaum eine Rolle spielt. Beim Kunden selbst wird das Anforde-
rungsdokument erstellt und die Abnahme des Softwareproduktes durchgeführt. Le-
diglich die externe Kommunikation spielt eine Rolle, da sie unter anderem den Soft-
wareentwicklungsprozess mit ersten Daten in Form des Anforderungsdokumentes be-
liefert. Da jedoch kein Softwareentwicklungsprojekt Einfluss auf die Kundenlokation
hat, bleibt dieser Standort im Verlauf der Analyse weitestgehend unberührt.
In Tabelle 4.6 fallen weiter die erhöhten Kommunikationskostenfaktoren der Stand-
orte Anwendungsentwicklung und Managementlokation auf. Diese sind nicht durch
die Anzahl der dortigen Aktivitäten zu erklären, sondern vor allem durch die Anzahl
der jeweils an externer Kommunikation beteiligten Aktivitäten, die deutlich von der
an anderen Standorten abweicht (vgl. Kopplungszahlen in Tabelle 4.5). Am Stand-
ort Anwendungsentwicklung wirkt sich zusätzlich noch die erhöhte Komplexität der
externen Kommunikationskanäle aus, die die Kosten ihrer Nutzung beeinflusst. Eine
erhöhte Komplexität der internen Kommunikationskanäle wie beim Standort Mana-
gementlokation wirkt sich dagegen nicht so stark aus, da interne Kommunikation im
Verhältnis zur externen Kommunikation immer als preisgünstiger angesehen wird.
Mit der bislang durchgeführten Diskussion ist ein Gesamtbild über die statische Kom-
munikationsinfrastruktur und ihrer Kosten einer mit konkreten Werten instanziierten
Beispielprozesslandschaft gegeben. Es dient als Ausgangsbasis für vergleichende Ana-
lysen mit modifizierten Prozesslandschaften.
4.1.2.2 Analyse verschiedener Optimierungsansätze
Im Folgenden werden die in Abschnitt 2.3.4 aufgeführten Strategien zur strukturellen
Veränderung einer Prozesslandschaft durchgespielt. Die Anwendung dieser Strategien
führt zu verschiedenen Landschaftsvarianten mit unterschiedlichen Kommunikations-
strukturen, deren Kostenfaktoren miteinander verglichen werden, um die jeweils be-
züglich der Kommunikationskosten günstigste Lösung zu identifizieren. Die Strategien
sind im Einzelnen:
 Aufbau eines neuen Standortes
 Zusammenlegen mehrerer Orte
 Verlagerung von Aktivitäten
 Verlagerung von Verantwortlichkeiten bei mehrfach vorhandenen Aktivitäten
Für jede Strategie werden konkrete Szenarien entwickelt und die Ergebnisse des
Optimierungsansatzes – die Minimierung des jeweiligen Kkf – diskutiert. So können
über den Vergleich verschiedener Kostenfaktoren sinnvolle Änderungen identifiziert
werden.
164
4.1 Analyse statischer Kommunikationseigenschaften
Aufbau eines neuen Standortes
Szenario:
Im Rahmen dieses Szenarios wird innerhalb der Zentrale ein zusätzlicher Standort
errichtet. An diesem können beispielsweise Teilaktivitäten der Managementlokation
durchgeführt werden, an der bislang sowohl Projektmanagementaktivitäten als auch
Aktivitäten aus dem Bereich des Domain Engineering ausgeführt werden. Letztere
sollen zukünftig am zusätzlichen Standort stattfinden. Alternativ könnten aber auch
Aktivitäten aus dem Konfigurationsmanagement des Application Engineering (Stand-
ort Anwendungsentwicklung) oder die Tests und Reviews des Qualitätsmanagements
(Standort Qualitätsmanagement-Z) ausgelagert werden. Die Berechnung des Kkf für
alle drei Alternativen wird zeigen, welche die kostengünstigste ist.
Zur Vereinfachung wird die Auslagerung des Domain Engineering (drei Aktivitäten)
zu einem neuen Standort in Tabelle 4.7 als Alternative1 bezeichnet, die Auslagerung
des Konfigurationsmanagements (drei Aktivitäten) vom Standort Anwendungsentwick-
lung als Alternative2 und die Auslagerung der Test- und Reviewtätigkeiten (fünf Ak-
tivitäten) des zentralen Qualitätsmanagements als Alternative3.
Kkf Kkf Kkf Kkf
Ort Ausgangsbasis Alternative1 Alternative2 Alternative3
Kundenlokation 186,33
Anwendungsentwicklung 8,87 10,94
Managementlokation 6,14 7,72
Komponentenentwicklung-1 0,26
Komponentenentwicklung-2 0,26
Komponentenentwicklung-3 0,26
Komponentenentwicklung-4 0,26
Komponentenentwicklung-5 0,26
Qualitätsmanagement-Z 2,28 1241,66
Qualitätsmanagement-A 0,15
neuer Standort 23,55 18,7 1209,6
Tabelle 4.7: Kommunikationskostenfaktoren aller Orte – Alternativen 1 bis 3
Tabelle 4.7 zeigt die Auswirkungen der drei Alternativen auf die Kommunikationskos-
tenfaktoren der jeweils betroffenen Standorte. Die dazu notwendigen Neuberechnun-
gen der Kopplungs- und Kohäsionsdichten sind im Anhang A.2 in den Tabellen A.19
bis A.30 detailliert dargestellt. Bei der Auslagerung von Aktivitäten zum neuen Stand-
ort ist jeweils darauf geachtet worden, logisch eng zusammengehörende Bereiche nicht
voneinander zu trennen. So ist bei Alternative1 der gesamte Bereich des Domain En-
gineering ausgelagert worden, bei Alternative2 die vollständig zum Konfigurations-
management des Application Engineering gehörende Menge an Aktivitäten und bei
Alternative3 ausschließlich diejenigen Bereiche des Qualitätsmanagements, die zur
operativen Qualitätssicherung zählen.
165
Validation der Analysemethoden
Trotzdem sind bei den drei Alternativen große Unterschiede in den Auswirkungen auf
die betroffenen Kommunikationskostenfaktoren festzustellen. Insbesondere eine Auf-
teilung des zentralen Qualitätsmanagements auf zwei Standorte (Alternative3) hätte
negative Auswirkungen auf den Kkf sowohl des alten als auch des neuen Standortes.
Dabei schien sich das zentrale Qualitätsmanagement – aufgrund der im Vergleich zu
den Außenstellen ebenfalls relativ hohen Kommunikationskosten – für eine Aufteilung
genauso anzubieten wie die Standorte Anwendungsentwicklung und Managementloka-
tion. Der Grund liegt in der relativ geringen Kohäsion der beiden betrachteten Orte: Die
am Standort Qualitätsmanagement-Z verbleibenden Aktivitäten nutzen beispielswei-
se nur noch genau einen Kommunikationskanal zur internen Kommunikation (siehe
Tabelle A.29 in Anhang A.2). Am neuen Standort werden zwar mehr interne Kom-
munikationskanäle genutzt, die externen werden jedoch um ein Vielfaches häufiger
genutzt, da über sie der Informationsaustausch bezüglich der Reviews und Tests von
insgesamt vier an verschiedenen Standorten zu entwickelnden Komponenten verläuft.
Da der Kkf über das Verhältnis zwischen internen und externen Kommunikations-
faktoren berechnet wird, verschlechtert sich dieses kostenungünstige Verhältnis noch
weiter und resultiert in den in Tabelle 4.7 aufgeführten Ergebnissen. Dass diese für
die Alternative3 jedoch so negativ ausfallen würden, ist ein Analyseergebnis, welches
durch „bloßes Hinsehen“ nicht erkennbar gewesen ist.
Auch die Aufteilung der Managementlokation (Alternative1) in ihre logischen Be-
standteile Projektmanagement und Domain Engineering ist nicht die kostengünstigste
Alternative für die Errichtung eines neuen Standortes. Bei dieser hätte die Manage-
mentlokation eine Kostensteigerung von mehr als 25% zu erwarten. Bezüglich des Kkf
hat sich die Verlagerung des Konfigurationsmanagements aus dem Application Engi-
neering als die aus Kostensicht beste Lösung herausgestellt. Die Kostensteigerung für
den verkleinerten Standort Anwendungsentwicklung beträgt hier 23, 34%. Aber auch
die Gesamtkosten, die bei der Errichtung eines zusätzlichen Standortes entstehen, sind
hier mit einem Kkf von insgesamt 29, 64 (10, 94 plus 18, 7) die günstigsten aller drei
diskutierten Alternativen.
Nach der Identifikation der zahlenmäßig günstigsten Alternative sollte diese immer
auch auf die Auswirkung ihrer Umsetzung untersucht werden. Im vorliegenden Fall
der Aufteilung des Application Engineering und seines Konfigurationsmanagements
auf verschiedene Standorte hätte die Umsetzung beispielsweise eine in der Realität
eher unübliche Arbeitssituation zur Folge, da ein Softwareentwicklungsteam zumeist
gleichzeitig für Konfigurationsmanagementaufgaben verantwortlich ist. Ein Grund für
diese Aufgabenzuordnung ist das Wissen um die Softwarearchitektur, das sowohl für
die Entwicklung als auch für die Konfiguration eines Softwaresystems erforderlich
ist. Eine geografische Aufteilung der Aktivitäten hätte hier wahrscheinlich negative
Auswirkungen auf den Arbeitsablauf, da zuvor zentriertes Wissen ebenfalls aufgeteilt
würde.
Bei Alternative1 ist die Situation anders gelagert. Die Auskopplung des Domain En-
gineering vom Managementstandort, die mit einem Kkf von insgesamt 31, 27 (7, 72
plus 23, 55) geringfügig teurer ist als die Aufteilung des Application Engineering
166
4.1 Analyse statischer Kommunikationseigenschaften
und seines Konfigurationsmanagements auf verschiedene Standorte, erscheint aus
semantischer Sicht sinnvoller: Das Domain Engineering beinhaltet vor allem operative
Aktivitäten, während das Projektmanagement Steuerungs- und Kontrollaufgaben
durchführt. Eine Trennung dieser beiden Aufgabenbereiche hätte keine Aufteilung
von für alle Aufgaben wichtigen Wissensträger auf verschiedene Standorte zur Folge.
Da die Steigerung der Kommunikationskosten vergleichsweise ähnlich ist, sollte
daher Alternative1 für die Umsetzung ausgewählt werden.
Zusammenlegen mehrerer Orte
Szenario:
Für das Zusammenlegen mehrerer Orte wird die kostengünstigste aus allen Kombina-
tionen von jeweils zwei Orten innerhalb der Zentrale berechnet. Lediglich die Kun-
denlokation bleibt unberücksichtigt. Die existierenden Außenstellen werden ebenfalls
nicht in die Überlegungen dieses Szenarios einbezogen.
Für die Zentrale existieren insgesamt sechs verschiedene Möglichkeiten, jeweils zwei
Standorte zusammenzulegen. Tabelle 4.8 zeigt die Auswirkungen auf den Kkf durch
ein Zusammenlegen verschiedener Orte. Für ihre detaillierte Berechnung sei wieder
auf Anhang A.2, Tabellen A.31 bis A.54, verwiesen. Innerhalb der Tabellen werden
die unterschiedlichen Möglichkeiten der Zusammenlegung als Fusionsalternative1 bis
Fusionsalternative6 bezeichnet. Die Sternchen in Tabelle 4.8 kennzeichnen die jeweils
zusammengelegten Standorte und erleichtern den Vergleich mit den Kommunikations-
kostenfaktoren der Ausgangsbasis.
Das Zusammenlegen zweier Standorte kommt dem Bestreben nach einer möglichst ge-
ringen Kopplung und einer möglichst hohen Kohäsion entgegen, da zur externen Kom-
munikation verwendete Kommunikationskanäle hierbei teilweise zu internen werden.
Bezogen auf die Beispielprozesslandschaft bedeutet damit jede Fusionsalternative eine
Verringerung der Kommunikationskosten. Für die Identifikation der kostengünstigsten
Zusammenlegung zweier Standorte hat sich gezeigt, dass die Werte der Ausgangsba-
sis ausreichend sind. Eine Neuberechnung für alle Fusionsalternativen ist nur für den
Fall erforderlich, dass die konkreten Kommunikationskostenfaktoren der fusionierten
Standorte von Interesse sind.
Betrachtet man die für die jeweiligen Fusionsalternativen 1 bis 6 berechneten Kom-
munikationskostenfaktoren, könnte man zunächst glauben, dass Fusionsalternative3
mit dem geringsten Kkf das Maximum an Kostenersparnis bringen wird. Hier ist der
Kkf von zuvor ingesamt 11,15 (8,87 plus 2,28) auf 0,57 gesunken. Tatsächlich ist
aber das Verhältnis der beiden alten zum jeweils neuen Kkf zu betrachten. Bei Fusi-
onsalternative3 macht dies eine Differenz von 10,58 aus. Demnach wird die Zusam-
menlegung der beiden Standorte Anwendungsentwicklung und Managementlokation
mit 13,36 (Fusionsalternative1) das Maximum an Kostenersparnis erreichen.
Ausschlaggebend für die Zusammenlegung der Standorte Anwendungsentwicklung
und Managementlokation als kostengünstigste Alternative ist, dass am zusammenge-
legten Standort die Mehrheit aller am Softwareentwicklungsprozess beteiligten Akti-
vitäten stattfindet und gleichzeitig die beiden Standorte mit den zuvor schon höchsten
167
Validation der Analysemethoden
Kkf Kkf Kkf Kkf Kkf Kkf Kkf
Ort Ausgangsbasis Alt.1 Alt.2 Alt.3 Alt.4 Alt.5 Alt.6
Kundenlokation 186,33
Anwendungsentwicklung 8,87 * * *
Managementlokation 6,14 * * *
Komponentenentwicklung-1 0,26 * * *
Komponentenentwicklung-2 0,26
Komponentenentwicklung-3 0,26
Komponentenentwicklung-4 0,26
Komponentenentwicklung-5 0,26
Qualitätsmanagement-Z 2,28 * * *
Qualitätsmanagement-A 0,15
Anwendungsentwicklung inkl.
Managementlokation 1,65
Anwendungsentwicklung inkl.
Komponentenentwicklung-1 1,51
Anwendungsentwicklung inkl.
Qualitätsmanagement-Z 0,57
Managementlokation inkl.
Komponentenentwicklung-1 1,12
Managementlokation inkl.
Qualitätsmanagement-Z 3,61
Qualitätsmanagement-Z inkl.
Komponentenentwicklung-1 0,77
Tabelle 4.8: Kommunikationskostenfaktoren aller Orte – Fusionsalternativen 1 bis 6
168
4.1 Analyse statischer Kommunikationseigenschaften
Kommunikationskostenfaktoren zusammengelegt werden. Dies entspräche jedoch ei-
nem Optimierungsansatz, der – wie in Abschnitt 2.3.4 bereits angesprochen – aus-
schließlich den Kkf berücksichtigt und daher nicht immer nutzbringend ist. Für das
Zusammenlegen von Standorten ist das rechnerisch günstigste Ergebnis deshalb un-
bedingt, wie zuvor beim Aufbau eines neuen Standortes, auf die Auswirkung seiner
Umsetzung zu untersuchen.
Die zuvor erwähnte Fusionsalternative3 bietet die zweitgünstigste Kostenersparnis. Sie
sollte ebenfalls für eine Umsetzung in Betracht gezogen werden, da hier zwei Aufga-
benbereiche zusammengelegt würden, die viele Berührungspunkte haben: Jedes Teil-
ergebnis des Application Engineering muss vom Qualitätsmanagement überprüft wer-
den, bevor es weiter verarbeitet wird.
Es zeigt sich, dass gerade für die Zusammenlegung von Standorten ein Kommunikati-
onskostenfaktor nur eines von mehreren Entscheidungskriterien sein sollte. Der Kkf
kann jedoch bei der Entscheidungsfindung als neutrales Argument sinnvoll eingesetzt
werden, wenn mehrere Alternativen aufgrund anderer Kriterien vorliegen.
Verlagerung von Aktivitäten
Szenario:
Die Aktivität Anforderungsanalyse erstellen soll von der Kundenlokation an einen an-
deren Ort der Zentrale verlagert werden. Auch hierfür wird die kostengünstigste Alter-
native berechnet.
Die bestmögliche Alternative für die Verlagerung einer einzelnen – wenn auch kom-
plexen – Aktivität ist meist eine mit starker Kopplung an Aktivitäten, die an anderen
Standorten stattfinden. Hintergrund dieses Optimierungsansatzes ist damit die Absicht
nach lokaler Verbesserung eines Kkf , jedoch mit Blick auf die Auswirkung auf die
Kommunikationskosten für die Prozesslandschaft insgesamt.
Kkf Kkf Kkf Kkf Kkf
Ort Ausgangsbasis Alt.1 Alt.2 Alt.3 Alt.4
Kundenlokation 186,33 32 32 32 32
Anwendungsentwicklung 8,87 4,05
Managementlokation 6,14 6,45
Komponentenentwicklung-1 0,26 0,97
Komponentenentwicklung-2 0,26
Komponentenentwicklung-3 0,26
Komponentenentwicklung-4 0,26
Komponentenentwicklung-5 0,26
Qualitätsmanagement-Z 2,28 1,98
Qualitätsmanagement-A 0,15
Tabelle 4.9: Kommunikationskostenfaktoren aller Orte – Verlagerungsalternativen 1
bis 4
169
Validation der Analysemethoden
Tabelle 4.9 zeigt die für die Verlagerung der Aktivität Anforderungsanalyse erstel-
len möglichen Alternativen innerhalb der Zentrale und die jeweils damit verbunde-
nen veränderten Kommunikationskostenfaktoren. Die detaillierten Berechnungsgrund-
lagen finden sich in den Tabellen A.55 bis A.70 in Anhang A.2.
Die drastische Verringerung der Kommunikationskosten an der Kundenlokation er-
staunt nicht weiter, da die dort entfernte Aktivität nur einen Kommunikationskanal
für die interne Kommunikation verwendet hat, aber acht zur externen Kommunikation
(vgl. Tabellen A.2 bis A.4 in Anhang A.2). Zusätzlich war die Kommunikation zum
zentralen Qualitätsmanagement aufgrund der Nutzungshäufigkeit und der Kosten pro
Informationseinheit vergleichsweise teuer (vgl. Tabelle A.3 in Anhang A.2). Durch die
Verlagerung ist die Kundenlokation jetzt von diesen Kosten befreit.
Es fällt auf, dass bei zwei Verlagerungsalternativen (1 und 3) nicht nur die Gesamt-
kosten der Prozesslandschaft gesenkt werden können, sondern gleichzeitig auch die
lokalen Kommunikationskosten derjenigen Standorte, die alternativ um die Aktivität
Anforderungsanalyse erstellen erweitert worden sind. Am Standort Anwendungsent-
wicklung konnten diese sogar um mehr als 50% gesenkt werden. Verlagerungsalterna-
tive1 ist damit als die kostengünstigste identifiziert. Ihre Umsetzung ist auch für den
Ablauf der Softwareentwicklung sinnvoll, da das Ergebnis der Aktivität Anforderungs-
analyse erstellen in vielen Bereichen des Application Engineering benötigt wird und
seine Erstellung am gleichen Standort einen einfachen und schnellen Zugriff ermög-
licht.
Des Weiteren kann festgehalten werden, dass sich lokale Verbesserungen eines Kkf
auch positiv auf andere Standorte innerhalb einer Prozesslandschaft auswirken kön-
nen. Der erwartete Nutzen der für die Identifikation der kostengünstigsten Alternative
durchzuführenden Berechnungen hat sich damit noch weiter erhöht.
Verlagerung von Verantwortlichkeiten bei mehrfach vorhandenen Aktivitäten
Szenario:
Das Qualitätsmanagement des zentralen Standortes weist, verglichen mit dem Qua-
litätsmanagement der Außenstelle-1, ein wesentlich höheres Arbeits- und Kommu-
nikationsaufkommen auf. In der Zentrale werden die Testaktivitäten für vier von
fünf Komponentenentwicklungsstandorten und zusätzlich noch die Reviews und
Tests für die Entwicklung des Gesamtsystems durchgeführt. Das Qualitätsmanage-
ment der Außenstelle-1 wickelt dagegen lediglich die Testaktivitäten des Standortes
Komponentenentwicklung-2 ab, ein vergleichsweise geringer Arbeits- und Kommu-
nikationsaufwand. Trotzdem müssen hier bis auf drei Aktivitäten alle Qualitätsma-
nagementaktivitäten zur Verfügung stehen. Hier soll nun analysiert werden, wie sich
die Durchführung der Testaktivitäten von vier Komponentenentwicklungsstandorten
durch das Qualitätsmanagement der Außenstelle-1 auf den Kkf der Prozesslandschaft
auswirkt. Das zentrale Qualitätsmanagement soll dann nur noch für das Application
Engineering und das Component Engineering der Zentrale verantwortlich sein, wäh-
rend das Qualitätsmanagement der Außenstelle-1 sich um alle außerhalb der Zentrale
entwickelten Komponenten kümmert.
170
4.1 Analyse statischer Kommunikationseigenschaften
Durch die Verschiebung der Verantwortlichkeiten verändern sich lediglich die Kom-
munikationskostenfaktoren der beiden Qualitätsmanagementstandorte, und dies auch
nur aufgrund veränderter Kopplungsdichten. Die jeweiligen Kohäsionsdichten und
-komplexitäten sowie die dadurch entstehenden internen Kommunikationskosten ver-
ändern sich nicht. Neben der Verschiebung der Kopplungsdichten verändert sich des
Weiteren noch die Nutzungshäufigkeit bestehender externer Kanäle, da sich zwar der
Auslastungsgrad der kommunizierenden Aktivitäten geändert hat, aber nicht ihre An-
zahl. Die Standorte Komponentenentwicklung-1 bis Komponentenentwicklung-5 wei-
sen einen unveränderten Kkf auf. Ein Teil der externen Kommunikation der Stand-
orte Komponentenentwicklung-3 bis Komponentenentwicklung-5 verläuft jetzt über
den Standort Qualitätsmanagement-A statt über Qualitätsmanagement-Z. Die verän-
derten Kommunikationskostenfaktoren dieser beiden Qualitätsmanagementstandorte
sind in Tabelle 4.10 zusammen mit denen der Ausgangsbasis dargestellt.
Kkf Kkf
Ort Ausgangsbasis nach Verschiebung
Kundenlokation 186,33
Anwendungsentwicklung 8,87
Managementlokation 6,14
Qualitätsmanagement-Z 2,28 1,12
Qualitätsmanagement-A 0,15 1,18
Komponentenentwicklung-1 0,26
Komponentenentwicklung-2 0,26
Komponentenentwicklung-3 0,26
Komponentenentwicklung-4 0,26
Komponentenentwicklung-5 0,26
Tabelle 4.10: Kommunikationskostenfaktoren aller Orte nach Verschiebung der
QM-Verantwortlichkeiten
Während die Kosten für den Standort Qualitätsmanagement-Z um über 50% ge-
sunken sind, steigen die Kosten für den Standort Qualitätsmanagement-A verhält-
nismäßig stark an. Trotzdem liegt der Wert bei einem Vergleich der Kommunika-
tionskostenfaktoren aller Standorte (ausgenommen Komponentenentwicklung-1 bis
Komponentenentwicklung-5) mit 1, 18 noch an zweitgünstigster Stelle. Auch die Ge-
samtkosten der Prozesslandschaft sind um den Wert 0, 13 leicht gesunken.
Betrachtet man die Kommunikationskostenfaktoren der obersten Abstraktionsebene
nach Verschiebung der Verantwortlichkeiten (vgl. Tabelle 4.11), hat die Außenstelle-1
jetzt den höchsten Kkf . Dieser ist fast auf das ursprüngliche Niveau des Kkf der Zen-
trale angestiegen. Bedenkt man, dass an der Zentrale die größte Anzahl aller am Soft-
wareentwicklungsprozess teilnehmenden Aktivitäten stattfindet, erscheint der Kkf der
Außenstelle-1 jetzt unverhältnismäßig hoch.
171
Validation der Analysemethoden
Kkf Kkf
Ort Ausgangsbasis nach Verschiebung
Zentrale 0,30 0,04
Außenstelle-1 0,09 0,29
Außenstelle-2 0,26
Außenstelle-3 0,26
Außenstelle-4 0,26
Tabelle 4.11: Kommunikationskostenfaktoren aller Orte auf oberster Ebene nach
Verschiebung der QM-Verantwortlichkeiten
An dieser Stelle stößt die Analyse der Kommunikationskosten einer Prozesslandschaft
allein auf der Basis statischer Kommunikationsstrukturen und abstrakter Skalen für die
Nutzungshäufigkeit pro Kommunikationskanal sowie Kosten pro Informationseinheit
an ihre Grenzen. Weitere Analysen sind für eine solche Situation nur unter Berücksich-
tigung zusätzlicher, dynamischer Kommunikationseigenschaften hilfreich. Tendenziell
scheint eine Verschiebung der Verantwortlichkeiten, wie im Szenario vorgeschlagen,
sinnvoll. Wie groß dieser Nutzen aber tatsächlich sowohl in Bezug auf die Kommu-
nikationskosten als auch auf den Auslastungsgrad ist, lässt sich hier nicht mehr näher
bestimmen.
4.1.3 Nutzenbetrachtung
Der erwünschte bzw. angestrebte Nutzen der vorangegangenen Analyse einer Prozess-
landschaft ist immer eine Verringerung von Kommunikationskosten. Diese soll vor
allem bei unstrukturierten Prozessen nutzbringend eingesetzt werden, für die eine de-
taillierte Ablaufmodellierung nicht sinnvoll oder nicht möglich ist, für die aber trotz-
dem eine Analyse der Kommunikationskosten erwünscht ist.
Die Analyse der Infrastruktur einer Prozesslandschaft bezüglich ihrer Kommunikati-
onskosten unterscheidet sich deutlich von in der Literatur beschriebenen (statischen)
Analysen. Letztere untersuchen beispielsweise die „Senkung der Informations- und
Kommunikationskosten für den Austausch von Informationen zwischen Akteuren ...
durch die zunehmende Verbreitung und Nutzung von Standards“ [WSvW+00]. Andere
untersuchen sogenannte kommunikationseffiziente parallele Algorithmen mit dem Ziel
einer niedrigeren Kommunikationszeit als der lokalen Bearbeitungszeit. Hier sind je-
doch die Anwendungsbereiche nicht Prozessmodelle, sondern Sortieralgorithmen und
Multisearch-Verfahren [BD96, ABK95].
Ein besonderes Merkmal der im Rahmen des Process Landscaping durchgeführten
statischen Analyse ist die Untersuchung einer sich aufgrund organisatorischer Maß-
nahmen verändernden Kommunikationsinfrastruktur. Diese organisatorischen Maß-
nahmen beziehen sich auf die Verlagerung von Aktivitäten, wie sie in der realen Welt
durchaus regelmäßig vorkommen:
172
4.1 Analyse statischer Kommunikationseigenschaften
 Bei der Expansion eines Unternehmens am zentralen Standort kann es erforder-
lich werden, ein weiteres, zusätzliches Gebäude zu mieten.
 Nach einer Übergangszeit zieht ein Unternehmen oft von zwei kleineren in ein
größeres Gebäude um.
 Es kommt vor, dass ein Standort verkleinert wird, weil beispielsweise der Miet-
vertrag eines Gebäudes nicht verlängert wird oder Aktivitäten ausgelagert wur-
den.
 Es sollte immer ein Bestreben sein, mehrfach vorhandene Aktivitäten gleichmä-
ßig auszulasten. Dieses Bestreben kann beispielsweise über die Verlagerung von
Verantwortlichkeiten realisiert werden und führt damit oft zu einem veränderten
Kommunikationsverhalten.
Führt ein konkretes Optimierungsziel zu einer lokal begrenzten Kostensenkung inner-
halb einer Prozesslandschaft, muss diese Kostensenkung unter Beachtung der mögli-
chen Seiteneffekte auf andere Standorte der Prozesslandschaft betrachtet werden. In
Abschnitt 4.1.2.2 sind entsprechende Situationen diskutiert worden. Dabei ist hervor-
zuheben, dass diese – einfach berechenbaren – Ergebnisse nicht durch bloßes Hin-
schauen zu erkennen sind, auch nicht durch genaues Betrachten der 269 in Anhang A.2
aufgelisteten Kommunikationskanäle.
Eine Umsetzung der Ergebnisse sollte auch nicht ausschließlich aufgrund der gewon-
nenen Zahlenwerte durchgeführt werden. Es ist zuvor immer ihre Auswirkung auf die
zugrundeliegenden realen Softwareprozesse zu untersuchen. Die Diskussion in Ab-
schnitt 4.1.2.2 hat gezeigt, dass teilweise der zweitgünstigste berechnete Wert die bes-
sere Alternative für den Ablauf der Softwareprozesse ist. Somit ist der Kkf nicht als
ausschließliches Entscheidungskriterium anzusehen, jedoch als ein kostenbezogenes
Hilfsmittel zur Entscheidungsfindung.
Zusammenfassend kann festgehalten werden, dass die Analyse statischer Kommuni-
kationseigenschaften einer verteilten Prozesslandschaft auf eine Weise durchgeführt
wurde, wie sie bislang in der bekannten Literatur noch nicht diskutiert worden ist. Da-
bei sei noch einmal daran erinnert, dass sich die Analyse auf fachlich sinnvoll struk-
turierte Prozesse konzentriert, um nutzbringende Ergebnisse anbieten zu können. Je
stärker die statische Kommunikationsinfrastruktur für ein spezifisches Optimierungs-
ziel verändert wird, desto nutzbringender ist die Analyse. Die Grenzen dieser Analyse
sind jedoch dann erreicht, wenn der Schwerpunkt auf einer veränderten Nutzungs-
häufigkeit bereits vorhandener Kommunikationskanäle liegt oder lediglich verwende-
te Kostenmodelle variiert werden. Für derartige Situationen sollte einer dynamischen
Analyse der Vorzug gegeben werden, wie sie in Abschnitt 4.2.2.2 diskutiert wird.
173
Validation der Analysemethoden
4.2 Analyse dynamischer Kommunikationseigenschaften
Die Analyse dynamischer Kommunikationseigenschaften einer Prozesslandschaft
PLcom basiert auf der diskreten ereignisorientierten Simulation von zeitbehafteten
Petrinetzen. Hierbei entspricht jedes Schalten einer Aktivität der Behandlung eines
Ereignisses. Ablaufinformationen, die bei der Analyse statischer Kommunikationsei-
genschaften nicht berücksichtigt werden, sind damit eine unbedingte Voraussetzung
für die Durchführung dieser Analysemethode. Während der Simulation einer Prozess-
landschaft gilt jedes Senden, Verarbeiten und Empfangen einer Nachricht als ein Er-
eignis, welches die weitere Dynamik der gesamten Landschaft beeinflusst.
Allgemein unterscheidet man zwischen kontinuierlicher und diskreter Simulation
[LK91]. Kontinuierliche Simulation wird meist dadurch realisiert, dass in konstan-
ten, relativ kurzen Zeitabständen der Zustand eines simulierten Systems aktualisiert
wird. Diskrete Simulation basiert auf der Annahme, dass sich ein Systemzustand nur
durch Ereignisse ändert, die in Bezug zur Simulationszeit zu bestimmten, diskreten
Zeitpunkten auftreten. Dabei kann jede Änderung des Systemzustandes wiederum zu
einem Ereignis bzw. einer Menge von Ereignissen führen, so dass sich die Dynamik
des Systems als ein Fortschreiben von Ereignissen darstellt. Da die Analyse dyna-
mischer Kommunikationseigenschaften auf dem Nachrichtenaustausch (als Ereignis)
zwischen Aktivitäten basiert, bietet sich hier die diskrete ereignisorientierte Simulation
an.
Die in diesem Abschnitt diskutierte Simulation setzt den Fokus auf die Betrachtung der
externen Kommunikation, die, gemäß dem Prinzip der teuren externen und vergleichs-
weise preiswerten internen Kommunikation, ausschlaggebend für die Kommunikati-
onskosten einer Prozesslandschaft ist. Entsprechend sind einige Änderungen an der
Beispiellandschaft vorgenommen worden, die nachfolgend in Abschnitt 4.2.1 erläutert
werden.
4.2.1 Struktur der Prozesslandschaft PLcom
Grundlage für die Analyse dynamischer Kommunikationseigenschaften ist, wie im
Fall der Analyse statischer Eigenschaften, die lokale Sicht auf die Beispielprozessland-
schaft, jedoch ergänzt um Ablaufinformationen. Die geografische Verteilung der Akti-
vitäten ist in Abbildung 4.2 dargestellt. Sie entspricht fast vollständig der Verteilung,
wie sie in Abschnitt 4.1 diskutiert wurde. Ausnahmen bilden lediglich der separate
Standort für das Domain Engineering innerhalb des zentralen Standortes und das Feh-
len des Standortes Kundenlokation. Die dort vorhandenen Aktivitäten sind den Stand-
orten Anwendungsentwicklung (Aktivität Anforderungsanalyse erstellen) und Mana-
gementlokation (Aktivitäten Kommunikation mit dem Kunden und Abnahme mit dem
Kunden) zugeordnet worden. Der Grund für diese Verschiebung ist das Analyseergeb-
nis in Abschnitt 4.1.2.2, demzufolge die Verlagerung der Aktivität Anforderungsana-
lyse erstellen zum Application Engineering eine deutliche Reduzierung der Kommu-
nikationskosten bewirkt. Da die beiden anderen Aktivitäten Kommunikation mit dem
174
4.2 Analyse dynamischer Kommunikationseigenschaften
Kunden und Abnahme mit dem Kunden für die Betrachtung der externen Kommuni-
kation zwischen den übrigen Standorten der Prozesslandschaft vernachlässigbar sind,
konnten diese ebenfalls ohne weiteres verschoben werden. Dies hat die Auflösung des
Standortes Kundenlokation zur Folge.
Ansonsten findet sich auch innerhalb der Prozesslandschaft PLcom an jedem Standort
der obersten Abstraktionsebene das Component Engineering, welches überall iden-
tisch aufgebaut ist. Bis auf einen Teilbereich des Qualitätsmanagements am Standort
Außenstelle-1 finden alle weiteren Aktivitäten der komponentenbasierten Softwareent-
wicklung am zentralen Standort statt.
Komponentenbasierte Softwareentwicklung
Zentrale
Außenstelle - 1
Außenstelle - 2:  Komponentenentwicklung - 3
Anwendungsentwicklung
Projektmanagement
Domain Engineering
Qualitätsmanagement - Z
Komponentenentwicklung - 1
Komponentenentwicklung - 2
Qualitätsmanagement - A
Außenstelle - 3:  Komponentenentwicklung - 4
Außenstelle - 4:  Komponentenentwicklung - 5
Abbildung 4.2: Lokale Sicht der Beispielprozesslandschaft PLcom
Für die Simulation der Beispielprozesslandschaft sind dieser einige Aktivitäten hin-
zugefügt worden, die in unmittelbarem Zusammenhang mit der Kommunikation zwi-
schen verschiedenen Standorten stehen. Sie unterstützen die Analyse dadurch, dass sie
als Messpunkte für das Ablesen von Simulationswerten genutzt werden. Beispiele sind
die Aktivitäten Review Anforderungen anstoßen am Standort Anwendungsentwicklung
oder Projekt freigeben am Standort Managementlokation. Des Weiteren sind einige
Aktivitäten zusammengefasst worden, die für die Betrachtung der externen Kommu-
nikation der verschiedenen Standorte nicht relevant sind. So wird beispielsweise das
Konfigurationsmanagement des Application Engineering und des Component Engi-
neering als eine nicht weiter verfeinerte Aktivität angesehen. Ebenso werden verschie-
dene Entwicklungsaktivitäten des Application Engineering und des Component En-
175
Validation der Analysemethoden
gineering zusammengefasst, die hauptsächlich interne Kommunikation erzeugen. Im
Component Engineering sind aus diesem Grund zum Beispiel alle Entwurfsaktivitäten
zur Aktivität Spezifikation erstellen zusammengefasst. So wird gleichzeitig ein homo-
genes Abstraktionsniveau für alle modellierten Standorte erreicht, das als Ergebnis der
Modellierungsphase nicht für alle Bereiche der Prozesslandschaft gegeben war. Die-
ses ist jedoch eine wichtige Voraussetzung, um zu sinnvoll verwertbaren Ergebnissen
zu gelangen. Für eine detaillierte Auflistung aller Ergänzungen und Abstraktionen der
Beispielprozesslandschaft sei auf [Stö01b] verwiesen.
Im zugehörigen Simulationsmodell der Beispielprozesslandschaft wird jeder Standort
der unteren Ebene der lokalen Sicht als separates Petrinetz dargestellt. Die Standorte
Komponentenentwicklung-1 bis Komponentenentwicklung-5 sind dabei durch mehre-
re Instanzen eines Netzes abgebildet. Kommunikationskanäle werden ebenfalls in se-
paraten Petrinetzen dargestellt. Jedes dieser nachfolgend als Kommunikationssystem
bezeichneten Netze repräsentiert eine Menge von Kommunikationskanälen, die eine
gemeinsame technische Realisierung besitzen, also gleiche Kapazitäts- und Kosten-
werte aufweisen. Insgesamt besteht das Simulationsmodell aus 27 separaten Petrinet-
zen, auf die weit über hundert Aktivitäten und etwa ebenso viele Schnittstellen verteilt
sind. Eine genaue Zählung der Aktivitäten und Schnittstellen wie in Abschnitt 4.1.1
(vgl. Tabelle 4.1 auf Seite 159) macht hier wenig Sinn, da mehrere Abstraktionen und
Verfeinerungen speziell für die Simulation durchgeführt worden sind. Die konkrete
Verteilung der Aktivitäten auf verschiedene Netze sowie ihre Parametrisierung ist in
Anhang A.3 aufgeführt. Dort ist pro Standort das zugrundeliegende Petrinetz abge-
bildet. Zusätzlich ist jeder Abbildung eine Tabelle beigefügt, die Auskunft über die
Dauer einer jeden Aktivität und über das Volumen jeder dargestellten Informations-
einheit gibt.
Eine Besonderheit im Simulationsmodell stellt das Netz Setup dar. Es dient ausschließ-
lich der Simulationssteuerung, indem es mit konkreten Werten belegte Instanzen der
Petrinetze für die einzelnen Standorte anlegt und über Referenzen bestimmt, wel-
che Instanzen während der Simulation jeweils miteinander kommunizieren. Außerdem
produziert es in zufällig festgelegten Zeitabständen jeweils eine Marke zum Erzeugen
einer Kundenanfrage bzw. eines Kundenauftrags. Die Marken werden an das Netz des
Projektmanagements übertragen und starten so ein (nächstes) Softwareentwicklungs-
projekt.
Beim Erzeugen der Auftragsmarken wird ihr Komplexitätswert – und damit die Kom-
plexität eines Softwareentwicklungsprojektes – gleichverteilt zwischen 0 und 10 zu-
fällig gewählt. Die obere Grenze von 10 ist hier nicht zufällig entstanden, sondern
hat sich im Verlauf vieler Gespräche mit verschiedenen Softwareprojektleitern und
-mitarbeitern als praktisch erwiesen. Der Komplexitätswert, der sich im Verlauf der
Simulation nicht mehr verändert, beeinflusst die Zeitbedarfe aller nachfolgenden Ak-
tivitäten, das Volumen von Nachrichten und Bearbeitungsentscheidungen. Die Grund-
lagen dieser Werte beruhen auf der Annahme, dass mit der modellierten Prozessland-
schaft verschiedene Softwareprojekte in einer Größenordnung von ca. 100, 500 und
1000 Personentagen simuliert werden.
176
4.2 Analyse dynamischer Kommunikationseigenschaften
Der Zeitbedarf der Aktivität Anforderungsanalyse erstellen wird beispielsweise mit
Hilfe der Funktion 4 + x.c() × 4, 1 berechnet. Dabei repräsentiert 4 die Mindestdau-
er dieser Aktivität, x repräsentiert den Komplexitätswert, und x.c() ist eine Verzöge-
rungsfunktion zur Bestimmung des Zeitbedarfes der Aktivität. Der Faktor 4,1 dient der
Modellierung der Spanne zwischen minimalem und maximalem Zeitbedarf der Akti-
vität Anforderungsanalyse erstellen. So wird der Zeitbedarf einer Aktivität durch eine
Verzögerungsfunktion, eine additive und eine multiplikative Konstante berechnet. In
ähnlicher Form wird das Volumen von auszutauschenden Informationen – insbeson-
dere von Softwareartefakten – berechnet, das ebenfalls von der Größe der jeweiligen
Softwareprojekte abhängig ist.
Die konkreten Werte der so parametrisierten Prozesslandschaft sind in Anhang A.3
ab Seite 272 detailliert aufgeführt. Dort finden sich auch verschiedene Kostenmodel-
le, die zur Berechnung der Kommunikationskosten bei der Nutzung der Kommunika-
tionskanäle benötigt werden. Die Parametrisierung der Prozesslandschaft ermöglicht
die Analyse der in in Abschnitt 2.3.3 eingeführten Kommunikationseigenschaften. Für
den Zusammenhang zwischen ihnen und den zu messenden Attributen sei noch einmal
auf Abbildung 2.7 auf Seite 41 verwiesen.
Nach der Erläuterung der Struktur der Beispielprozesslandschaft PLcom und ihrer Ab-
bildung im Simulationsmodell werden im nachfolgenden Abschnitt die Simulationser-
gebnisse dieser Ausgangsbasis diskutiert.
4.2.2 Analyse der Kommunikationseffizienz einer Prozesslandschaft
PLcom
4.2.2.1 Analyse der Ausgangsbasis
Die Kommunikationseffizienz einer Prozesslandschaft PLcom wird im Rahmen der Si-
mulation an ihren zentralen Eigenschaften Kommunikationsaufkommen, Prozessaus-
lastung, durchschnittliche Pfadlänge und Initiator-/Responder-Erfüllungsrate gemes-
sen (vgl. Abschnitte 2.3.3 und 2.3.5). Für die Auswertung der konkreten Simulati-
onsergebnisse ist zu beachten, dass pseudozufällige Ereignisse das Systemverhalten
bestimmen [LK91]. Für Petrinetze bedeutet das, dass bei einem Simulationslauf nicht
zwangsläufig jeder Pfad auf dem Erreichbarkeitsgraphen durchlaufen wird. Jeder Si-
mulationslauf stellt damit eine Realisierung eines stochastischen Prozesses dar. Um
für diesen aussagekräftige Analysen zu erstellen, sind mehrere Simulationsläufe unter
gleichen Rahmenbedingungen erforderlich. Für die Analyse der Ausgangsbasis und
auch der später betrachteten Optimierungsansätze wird daher eine Hierarchie von Pro-
jekten, Experimenten und Simulationsläufen aufgebaut, wie sie in Abbildung 4.3 skiz-
ziert ist.
Eine Menge von Simulationsläufen wird in einem Experiment zusammengefasst. Jedes
Experiment beschreibt die vollständige Parametrisierung eines Simulationsmodells, in
diesem Fall die Parametrisierung der Elemente aller 27 Petrinetze mit insgesamt 34
Simulationsläufen. Auf der Projektebene können wiederum mehrere Experimente vor-
177
Validation der Analysemethoden
handen sein, die verschiedene Ausprägungen einer Prozesslandschaft, beispielsweise
für verschiedene Optimierungsansätze, beinhalten.
Simulations-
ablauf 11
Simulations-
ablauf t
x
Simulations-
ablauf 1
n
Simulations-
ablauf n
n +1
Simulations-
ablauf n
n +m
Simulations-
ablauf t
n +m+1
...... ...... ......
Projekt
Experiment 1 Experiment n Experiment t......... .........
Abbildung 4.3: Hierarchie von Projekten, Experimenten und Simulationsläufen
Für die Auswertung aller anfallenden Daten innerhalb eines Experimentes ist eine
Werkzeugunterstützung entwickelt worden, die
 Kommunikationskosten zuweist,
 Prozessauslastungen berechnet,
 Pfadlängen bestimmt und
 Initiator-/Responder-Raten ermittelt.
Auf die Werkzeugunterstützung wird in Kapitel 5 noch näher eingegangen. Dieser
Abschnitt konzentriert sich auf die Diskussion der Simulationsergebnisse. Diese wer-
den als Realisierungen einer (unbekannten) Verteilung aufgefasst. Um Letztere näher
zu beschreiben, werden ein erwartungstreuer Mittelwertschätzer und eine Standard-
abweichung als stochastisch verteilte Größen berechnet [BS89]. Ihre Darstellung im
laufenden Text erfolgt in folgender Schreibweise:
< erwartungstreuerMittelwertscha¨tzer > ± < Standardabweichung >
Die in den nachfolgenden Tabellen 4.12 bis 4.18 aufgeführten Werte der berechneten
Minima, Maxima, Mittelwerte und Standardabweichungen sind jeweils über alle 34
Simulationsläufe gemittelt.
Die nachfolgende Diskussion ist entlang der betrachteten Eigenschaften strukturiert.
Für alle gilt jedoch, dass der Analyseschwerpunkt auf der Kopplung zwischen den
einzelnen Bereichen der Zentrale und den Außenstellen der Prozesslandschaft liegt.
Dabei sind in den Übersichtstabellen nicht immer alle berechneten Werte aufgeführt,
sondern lediglich diejenigen, auf die in der Diskussion näher eingegangen wird.
178
4.2 Analyse dynamischer Kommunikationseigenschaften
Kommunikationskosten:
Bei der Betrachtung der Kommunikationskosten ist zu beachten, dass im Rahmen der
dynamischen Analyse Kosten für externe Kommunikation gemäß dem Verursacher-
prinzip immer dem Sender angelastet werden. Die in Tabelle 4.12 aufgeführten Kosten
berechnen sich als Summe der durch die Nutzung unterschiedlicher Kommunikations-
systeme anfallenden Gebühren. Dabei wird berücksichtigt, dass diese für relativ kurze
Entfernungen z.B. innerhalb der Zentrale niedriger liegen als bei den größeren Ent-
fernungen zwischen der Zentrale und den Außenstellen. So sind beispielsweise dem
Standort Projektmanagement Kosten in Höhe von 11.317,66 ± 2.658,77 Euro vor al-
lem dadurch entstanden, dass er Entwicklungsaufträge an die weiter entfernten Stand-
orte Komponentenentwicklung-2 bis Komponentenentwicklung-5 vergibt.
erwartungstr. Standard-
Ort Min Max Mittelwert abweichung
Anwendungsentwicklung 309,10 8092,43 4999,36 1547,79
Komponentenentwicklung-2 66,69 653,13 252,85 122,37
Komponentenentwicklung-3 2250,60 4524,39 19988,44 11236,82
Komponentenentwicklung-4 2822,33 45039,23 19616,26 10263,10
Komponentenentwicklung-5 3126,34 38423,55 19446,60 9492,91
Projektmanagement 4283,68 17481,06 11317,66 2658,77
Qualitätsmanagement-Z 7341,68 51663,98 30186,45 8525,46
Qualitätsmanagement-A 0,00 1138,77 56,58 222,11
Tabelle 4.12: Kommunikationskosten der Beispielprozesslandschaft
Die Kommunikationskosten zwischen dem Component Engineering und dem Qua-
litätsmanagement fallen teilweise als interne Kosten an, beispielsweise zwischen
Komponentenentwicklung-1 und Qualitätsmanagement-Z in der Zentrale oder zwi-
schen Komponentenentwicklung-2 und Qualitätsmanagement-A in der Außenstelle-1.
Für die Komponentenentwicklung-3 bis Komponentenentwicklung-5 sind diese Kosten
als teure externe Kommunikationskosten zu berechnen. In Tabelle 4.12 können die
beiden Situationen direkt miteinander verglichen werden. Dem zentralen Qualitätsma-
nagement werden Kosten in Höhe von 30.186,45 ± 8.525,46 Euro zugeordnet, den mit
ihm kommunizierenden und weit entfernt liegenden Standorten Komponentenentwick-
lung-3 bis Komponentenentwicklung-5 Gesamtkosten in Höhe von ca. 59.000 Euro.
Im Vergleich zum zentralen Qualitätsmanagement wird das Qualitätsmanagement der
Außenstelle-1 lediglich mit 56,58 ± 222,11 Euro für seine externe Kommunikation
belastet, wenn es Vorschläge zur Richtlinienerweiterung an die Zentrale schickt. Die
hohe Streuungsrate liegt darin begründet, dass dieser Versand nur relativ selten er-
folgt. An dieser Stelle sei darauf hingewiesen, dass die Standardabweichung gleich
der Wurzel aus dem erwartungstreuen Varianzschätzer (Wurzel der Summe der Feh-
lerquadrate) [BS89] ist und damit auch bei einem gemittelten Simulationsergebnis,
dessen Standardabweichung größer ist als der erwartungstreue Mittelwert, keine nega-
tiven Werte auftreten.
179
Validation der Analysemethoden
Insgesamt weist das zentrale Qualitätsmanagement die höchsten Kommunikati-
onskosten innerhalb der Beispielprozesslandschaft PLcom auf. Ein Vergleich mit
der Außenstelle-1 lässt jedoch vermuten, dass diese Kosten durch eine geeignete
Umverteilung der Arbeitslast wahrscheinlich verringert werden können.
Prozessauslastung:
Für eine an einem (beliebigen aber festen) Standort stattfindende Aktivität wird die
Prozessauslastung zu einem bestimmten Zeitpunkt t gemessen. Ein Standort gilt als
ausgelastet, solange mindestens ein Nachbereich einer Aktivität mit einer Marke be-
legt ist, dessen Zeitstempel größer als t ist. Diese Auslastung wird im Verhältnis zur
Gesamtzeit eines Softwareprojektes auf einer Skala von 0 bis 100 in Prozent gemessen.
erwartungstr. Standard-
Ort Min Max Mittelwert abweichung
Anwendungsentwicklung 63,28 88,44 76,50 6,32
Komponentenentwicklung-1 16,18 66,37 46,03 13,78
Komponentenentwicklung-2 25,55 78,04 53,41 0,14
Komponentenentwicklung-3 32,13 74,50 50,94 9,04
Komponentenentwicklung-4 27,59 75,81 51,80 11,38
Komponentenentwicklung-5 27,11 79,86 53,97 12,42
Domain Engineering 28,33 51,00 37,73 5,28
Projektmanagement 20,31 54,12 35,38 7,39
Qualitätsmanagement-Z 66,22 98,65 85,84 9,09
Qualitätsmanagement-A 1,05 20,90 10,28 5,53
Tabelle 4.13: Prozessauslastung der Beispielprozesslandschaft
Tabelle 4.13 zeigt die berechneten Auslastungen für die verschiedenen Standorte der
Beispielprozesslandschaft. Bei ihrer Bewertung ist zu berücksichtigen, dass die Aus-
lastungen aller Standorte derart zusammenhängen, dass beispielsweise ein stark be-
anspruchter Standort die Auslastung nachfolgender Aktivitäten an anderen Standorten
negativ beeinflussen kann. Das ist dann der Fall, wenn die nachfolgenden Aktivitäten
auf Informationen vom ausgelasteten Standort warten. Daher sind die Werte in Tabel-
le 4.13 immer in ihrem Gesamtzusammenhang zu betrachten.
Der Standort Anwendungsentwicklung hat mit 76,50 ± 6,32% erwartungsgemäß einen
relativ hohen Auslastungsgrad. Dies liegt nicht nur darin begründet, dass hier ein
großer Teil der produktiven Arbeit zur Entwicklung des Gesamtsystems durchgeführt
wird, sondern ist vor allem durch die lange Nachlaufzeit während der Simulation, also
der Zeit zwischen dem Eingang des letzten Entwicklungsauftrags und dem Beenden
der letzten Aktivität Zur Abnahme freigeben, zu erklären.
Die Standorte Domain Engineering und Projektmanagement sind mit 37,73 ± 5,28%
und 35,38 ± 7,39% relativ gering ausgelastet. Diese Auslastung liegt ebenfalls im
erwarteten Rahmen, da sie dem zeitlichen Anteil der Aktivitäten am gesamten Soft-
180
4.2 Analyse dynamischer Kommunikationseigenschaften
wareentwicklungsprozess entspricht. Alle fünf Standorte des Component Engineering
weisen einen ungefähren Auslastungsgrad von etwas über 50± 12% auf. Dabei fällt
vor allem die Höhe der Standardabweichung auf. Diese lässt sich durch die gleichver-
teilte Zuweisung der Projekte auf die einzelnen Standorte erklären, nach der jeder der
fünf Standorte nur ein Fünftel der insgesamt durchzuführenden Aufträge erhält.
Das zentrale Qualitätsmanagement ist mit 85,84 ± 9,09% am stärksten ausgelastet,
im Vergleich zu anderen Standorten sicher auch überlastet. Dies deutete sich bereits
bei der Betrachtung der Kommunikationskosten an, die ebenfalls den höchsten Wert
innerhalb der Beispielprozesslandschaft aufzeigen. Das Qualitätsmanagement der
Außenstelle-1 weist dagegen mit 10,28 ± 5,53% einen sehr niedrigen Auslastungs-
grad auf. Da es lediglich für einen Standort des Component Engineering zuständig
ist, lässt dieser Wert auf eine daraus resultierende Unterbeschäftigung schließen.
Qualitätsmangement-Z und Qualitätsmanagement-A zeigen somit eine sehr unter-
schiedliche und damit nicht optimale Auslastung der Beispielprozesslandschaft auf.
Durchschnittliche Pfadlänge:
In Abschnitt 2.3.5 ist die Kommunikationseffizienz bezüglich des Informationsflus-
ses innerhalb verteilten einer Prozesslandschaft als möglichst große durchschnittliche
Pfadlänge zwischen zwei verfeinerten Aktivitäten beschrieben, die zur Verarbeitung
einer konkreten Information erforderlich ist. Da die Längen der während einer Simu-
lation tatsächlich durchlaufenen Pfade zusammen mit der Häufigkeit ihres Auftretens
in die in Tabelle 4.14 aufgeführten Werte eingehen, können diese analog zum Aus-
lastungsgrad nur in ihrem Gesamtzusammenhang interpretiert werden. Die Bedeutung
eines langen bzw. kurzen Pfades kann somit nur am konkreten, parametrisierten Simu-
lationsmodell festgemacht werden. Aus Sicht eines Modellierers ist außerdem darauf
zu achten, dass die Prozesslandschaft einen möglichst gleichverteilten Abstraktions-
grad aufweist, um die in einer Simulation gewonnenen Werte nicht zu verfälschen.
erwartungstr. Standard-
Ort Min Max Mittelwert abweichung
Anwendungsentwicklung 2,2872 2,7774 2,6143 0,1401
Komponentenentwicklung-1 2,5455 3,3600 2,9480 0,2085
Komponentenentwicklung-2 2,8571 3,3333 3,1072 0,1390
Komponentenentwicklung-3 2,5000 3,3333 2,9891 0,1977
Komponentenentwicklung-4 2,4000 3,3600 3,0494 0,2084
Komponentenentwicklung-5 2,5882 3,3750 3,0652 0,1804
Domain Engineering 2,5455 3,3750 3,0320 0,2144
Projektmanagement 3,3759 3,5211 3,4443 0,0376
Qualitätsmanagement-Z 2,1691 2,9620 2,8596 0,1827
Qualitätsmanagement-A 2,0000 2,5833 2,3396 0,2118
Tabelle 4.14: Durchschnittliche Pfadlänge der Beispielprozesslandschaft
181
Validation der Analysemethoden
Eine statische Analyse der Pfadlängen lieferte einen Wertebereich von 1 bis 5; beide
Extremwerte wurden im Projektmanagement identifiziert. Dieser Wertebereich lässt
sich als Skala für die Interpretation der durch die Simulation gewonnenen Werte heran-
ziehen. Eine durchschnittliche Pfadlänge im unteren Bereich der Skala weist damit auf
eine geringe Bearbeitungstiefe hin, Werte im oberen Bereich auf eine vergleichsweise
größere Bearbeitungstiefe der ausgetauschten Information. Für die genauere Betrach-
tung der Simulationsergebnisse sind nachfolgend jedoch nur diejenigen interessant, die
auf eine geringe Bearbeitungstiefe hinweisen und nicht aufgrund einer tayloristischen
Arbeitsorganisation entstanden sind (vgl. Abschnitt 2.3.5).
In Tabelle 4.14 weisen bis auf Qualitätsmanagement-A alle Standorte eine durch-
schnittliche Pfadlänge von über 2,5 und damit eine als nicht auffällig zu bewerten-
de Bearbeitungstiefe auf. Für das Projektmanagement liegt dieser Wert mit 3,4443 ±
0,0376 am höchsten, obwohl hier in der statischen Analyse auch der kürzeste mögliche
Pfad identifiziert wurde. Auf diesem werden Vorschläge zu Richtlinienerweiterungen
an das zentrale Qualitätsmanagement weitergeleitet. Da dies aber nur relativ selten
vorkommt, fällt die Pfadlänge von 1 hier kaum ins Gewicht.
Das Qualitätsmanagement der Außenstelle-1 weist mit einer durchschnittlichen
Pfadlänge von 2,3396 ± 0,2118 als einziger Standort einen vergleichsweisen
niedrigen Wert auf. Da hier jedoch bis auf das Erarbeiten von möglichen Richtli-
nienerweiterungen ausschließlich prüfende Tätigkeiten durchgeführt werden und
daher eine tayloristische Arbeitsverteilung vorliegt, sind kurze Pfade durchaus
gewollt. Eine niedrige durchschnittliche Pfadlänge ist also lediglich bei einer nicht
tayloristischen Arbeitsverteilung ein Indiz für einen nicht optimalen Informationsfluss.
Initiator-/Responder-Erfüllungsrate:
Die Initiator-/Responder-Erfüllungsrate (kurz: I/R-Rate) dient als Indikator für die
Kommunikationseffizienz bezüglich der Informationsverteilung innerhalb einer Pro-
zesslandschaft. Diese Rate misst das anteilige Verhältnis erfolgreicher (ohne zeitli-
che Verzögerung durchgeführter) Kommunikationsversuche zur Gesamtzahl der wäh-
rend einer Simulation unternommenen Kommunikationsversuche. Die der Messung
der I/R-Rate zugrundeliegende Modellierung bewirkt, dass ein Responder erst nach
Durchlauf einer Reihe von Aktivitäten, die ein zu kommunizierendes Dokument als
Ergebnis hat, wieder für eine Kommunikation verfügbar ist. Je mehr Zeit ein solcher
Durchlauf in Anspruch nimmt, desto mehr Kommunikationsanfragen können nur zeit-
verzögert beantwortet werden. Damit hängt die I/R-Rate der verschiedenen Standorte
eng mit ihrer jeweiligen Prozessauslastung zusammen.
Tabelle 4.15 zeigt die während der Simulation der Beispielprozesslandschaft gemes-
senen I/R-Raten derjenigen Standortpaare, für die der gemessene Wert eine nähere
Betrachtung lohnt. Dies sind vor allem Werte in den Randbereichen des Intervalls von
0 bis 100 in Prozent. Für einige Paarungen wie beispielweise dem Application En-
gineering und einem Component Engineering ist die Betrachtung der I/R-Rate nicht
relevant, da zwischen den beiden nur einmal pro Entwicklungsprojekt eine erstellte
Komponente verschickt wird. Für andere Paarungen wie beispielsweise die Kommu-
182
4.2 Analyse dynamischer Kommunikationseigenschaften
erwartungstr. Standard-
Orte Min Max Mittelwert abweichung
Anwendungsentwicklung ⇒
Qualitätsmanagement-Z 4,39 35,71 13,73 7,32
Qualitätsmanagement-Z ⇒
Anwendungsentwicklung 58,97 83,75 74,27 5,08
Domain Engineering ⇒
Anwendungsentwicklung 50,00 93,75 71,05 11,37
Domain Engineering ⇒
Qualitätsmanagement-Z 5,56 53,85 17,45 10,39
Projektmanagement ⇒
Qualitätsmanagement-Z 3,85 31,25 15,86 6,96
Qualitätsmanagement-Z ⇒
Projektmanagement 50,00 88,00 71,35 8,12
Projektmanagement ⇒
Domain Engineering 26,32 50,00 38,12 6,13
Domain Engineering ⇒
Projektmanagement 75,76 97,37 88,51 5,56
Tabelle 4.15: Initiator-/Responder-Erfüllungsrate der Beispielprozesslandschaft
nikation zwischen dem Projektmanagement und dem Domain Engineering mit einer
I/R-Rate von 38,12 ± 6,13% (vgl. Tabelle 4.15) sind die Resultate relativ unspektaku-
lär. Sie ermöglichen keine aussagekräftige Interpretation und werden daher nicht näher
untersucht.
Wie aufgrund des hohen Auslastungsgrades des zentralen Qualitätsmanagements be-
reits zu erwarten war, weisen alle Paarungen, bei dem dieser Standort die Rolle des
Responders einnimmt, mit einem Wert von maximal 17,45 ± 10,39% eine sehr gerin-
ge I/R-Rate auf: Nur maximal ein Viertel aller Kommunikationsversuche gelingt hier
ohne zeitliche Verzögerung. Nimmt das zentrale Qualitätsmanagement dagegen die
Rolle des Initiators ein, liegen die I/R-Raten bei über 70%. Alle übrigen Paarungen in
Tabelle 4.15 haben – bis auf die Kommunikation vom Projektmanagement zum Do-
main Engineering – ebenfalls eine hohe Rate. Die Kommunikationseffizienz bezüglich
des Informationsflusses ist damit als gut zu bewerten.
4.2.2.2 Analyse verschiedener Optimierungsansätze
Die in Abschnitt 4.2.2.1 diskutierte Auswertung der Beispielprozesslandschaft hat ei-
nige Schwächen und damit gleichzeitig einige Optimierungsansätze aufgezeigt. Letz-
tere sind konform zu den allgemeinen Optimierungszielen, konkret
 einer Reduktion des externen Kommunikationsaufkommens,
 einer gleichmäßigeren Auslastung der Prozesse,
183
Validation der Analysemethoden
 einer Erhöhung der durchschnittlichen Bearbeitungstiefe und
 einer Steigerung der Rate erfolgreicher Kommunikationsversuche.
Für die identifizierten Optimierungsansätze wird nachfolgend ein Szenario entwickelt,
für das durch die Simulation einer veränderten Parametrisierung der Beispielprozess-
landschaft überprüft wird, ob dies im Vergleich zur ursprünglichen Prozesslandschaft
tatsächlich zu einer verbesserten Effizienz der betrachteten Kommunikation bezüglich
des Kommunikationsaufkommens, der Prozessauslastung und der durchschnittliche
Pfadlänge führt. Dabei wird darauf geachtet, dass das Abstraktionsniveau der modi-
fizierten Prozesslandschaft weiterhin einheitlich bleibt, um zu sinnvoll verwertbaren
Ergebnissen zu gelangen. Die veränderte I/R-Rate wird für das modifizierte Simu-
lationsmodell nicht näher betrachtet, da die Auswertung der Ausgangsbasis gezeigt
hat, dass deren Analyse eng mit der der Prozessauslastung zusammenhängt. Die
veränderten Werte sind jedoch der Vollständigkeit halber in Anhang A.3 aufgeführt
(vgl. Tabelle A.79 in Anhang A.3).
Szenario:
Die Auswertung der Kommunikationskosten in Abschnitt 4.2.2.1 hat gezeigt, dass
diese für die Kommunikation zwischen den Standorten Qualitätsmanagement-A und
Komponentenentwicklung-2 in der Außenstelle-1 deutlich unter denen für die Kommu-
nikation zwischen dem zentralen Qualitätsmanagement und den an der Außenstelle-2
bis Außenstelle-4 vorhandenen Komponentenentwicklungsstandorten liegen. Um die
Kosten des zentralen Qualitätsmanagements zu senken, soll jetzt über ein VPN (Vir-
tual Private Network) [BGKK99] mit den weit entfernt liegenden Komponentenent-
wicklungsstandorten kommuniziert werden. Das VPN arbeitet auf Basis des Internets.
Die Kommunikationspartner müssen sich für seine Nutzung lediglich zum Ortstarif
bei ihrem lokalen Internetprovider einwählen. Auf diesem Weg sollten die Kommuni-
kationskosten erheblich verringert werden können.
Auch die Prozessauslastung der Ausgangsbasis hat eine große Diskrepanz zwischen
dem zentralen Qualitätsmanagement und dem der Außenstelle-1 aufgezeigt. Für ei-
ne gleichmäßigere Auslastung soll die Betreuung der Standorte Komponentenent-
wicklung-3 bis Komponentenentwicklung-5 vom Standort Qualitätsmanagement-A
übernommen werden. Dieses Szenario entspricht damit dem der statischen Analyse
in Abschnitt 4.1.2.2, bei dem ebenfalls die Auswirkung der Verantwortlichkeitsverla-
gerung für mehrfach in der Prozesslandschaft vorhandene Prüfaktivitäten untersucht
wurde. Dort konnten jedoch allein auf Grundlage der Informationen über die statische
Kommunikationsinfrastruktur und abstrakte Wertebereiche sowohl für die Kommuni-
kationskosten als auch für die Nutzungshäufigkeiten der involvierten Kommunikati-
onskanäle keine eindeutig belegbaren Verbesserungen identifiziert werden.
Für die Weiterleitung von Vorschlägen zur Richtlinienerweiterung vom Projektmana-
gement an das zentrale Qualitätsmanagement ist mit einer Pfadlänge von 1 der kürzeste
Pfad innerhalb der gesamten Beispielprozesslandschaft identifiziert worden. Da diese
Weiterleitung aber nicht dem Ansatz der tayloristischen Arbeitsteilung entspricht, soll-
184
4.2 Analyse dynamischer Kommunikationseigenschaften
te hier eine Möglichkeit zur Optimierung des Informationsflusses durch Umverteilung
der Verantwortlichkeiten gegeben sein. Dazu sollen die Richtlinien im modifizierten
Modell von beiden Qualitätsmanagementstandorten gleichberechtigt verändert werden
dürfen. Aus diesem Grund werden die Richtlinien auf einen Server ausgelagert, auf
den beide Standorte bzw. deren Qualitätsmanagementaktivitäten schreibenden Zugriff
haben. Der Pfad zur Weiterleitung von Vorschlägen zur Richtlinienerweitung entfällt
damit völlig. Gleichzeitig ermöglicht die Auslagerung einen lesenden Zugriff für alle
Aktivitäten des Component Engineering, womit auch die – relativ häufig vorkommen-
den – Anfragen nach Richtlinien seitens der Standorte Komponentenentwicklung-1 bis
Komponentenentwicklung-5 und Anwendungsentwicklung entfallen.
Die Simulation des beschriebenen Szenarios und der Vergleich mit der ursprünglichen
Prozesslandschaft führt zu folgenden Ergebnissen:
Kommunikationsaufkommen:
Das Kommunikationsverhalten der Komponentenentwicklungsstandorte an den
Außenstellen-2 bis -4 hat sich zum einen bezüglich des Kommunikationspartners,
zum anderen aber auch bezüglich des Kommunikationssystems und dem damit
verbundenen Kostenmodell geändert. Eine Kommunikation zwischen ihnen und
dem Qualitätsmanagement der Außenstelle-1 wird jetzt über eine ISDN-Verbindung
mit dem Tarif RegioCall (vgl. Anhang A.3) aufgebaut. Das Resultat des so ver-
änderten Simulationsmodells verursacht für den Standort Qualitätsmanagement-A
erwartungsgemäß höhere Kosten, da dieser jetzt mehrere Standorte zu betreuen
hat. Gleichzeitig sind jedoch die Kosten für das zentrale Qualitätsmanagement und
auch für die betroffenen Komponentenentwicklungsstandorte erheblich gesunken.
Insgesamt konnten die Kommunikationskosten für alle Qualitätsmanagement- und
Komponentenentwicklungsstandorte von ursprünglich ca. 89.000 Euro um etwa
24.000 Euro und damit um mehr als ein Viertel gesenkt werden.
Ausgangsbasis modifiziertes Modell
erw. Standard- erw. Standard-
Ort Mittelwert abw. Mittelwert abw.
Anwendungsentwicklung 4999,36 1547,79 5167,68 1246,98
Komponentenentwicklung-2 252,85 122,37 243,18 95,55
Komponentenentwicklung-3 19988,44 11236,82 7773,99 4520,91
Komponentenentwicklung-4 19616,26 10263,10 7670,51 3647,21
Komponentenentwicklung-5 19446,60 9492,91 7316,71 3133,32
Projektmanagement 11317,66 2658,77 11204,86 2556,14
Qualitätsmanagement-Z 30186,45 8525,46 0,00 0,00
Qualitätsmanagement-A 56,58 222,11 952,42 256,62
Tabelle 4.16: Kommunikationskosten der modifizierten Beispielprozesslandschaft
185
Validation der Analysemethoden
Prozessauslastung:
Die gestiegenen Kommunikationskosten für den Standort Qualitätsmanagement-A
sind auf die gleichzeitig gestiegene Prozessauslastung für diesen Bereich der Prozess-
landschaft zurückzuführen. Der Auslastungsgrad liegt hier jetzt bei 64,10 ± 5,62%
(vgl. Tabelle 4.17). Damit verbunden ist die deutliche Verbesserung der Auslastung
für das zentrale Qualitätsmanagement. Sie ist von ursprünglich 85,84 ± 9,09% auf
69,22 ± 11,42% gesunken. Beide Standorte weisen nunmehr einen akzeptablen Aus-
lastungsgrad auf.
Ausgangsbasis modifiziertes Modell
erw. Standard- erw. Standard-
Ort Mittelwert abw. Mittelwert abw.
Anwendungsentwicklung 76,50 6,32 77,71 7,12
Komponentenentwicklung-1 46,03 13,78 51,94 12,64
Komponentenentwicklung-2 53,41 0,14 46,25 12,03
Komponentenentwicklung-3 50,94 9,04 45,40 18,39
Komponentenentwicklung-4 51,80 11,38 46,54 15,98
Komponentenentwicklung-5 53,97 12,42 50,79 12,09
Domain Engineering 37,73 5,28 42,22 5,80
Projektmanagement 35,38 7,39 40,52 9,53
Qualitätsmanagement-Z 85,84 9,09 69,22 11,42
Qualitätsmanagement-A 10,82 5,53 64,10 5,62
Tabelle 4.17: Prozessauslastung der modifizierten Beispielprozesslandschaft
Insgesamt konnte – bis auf den Standort Anwendungsentwicklung und die Kompo-
nentenentwicklungsstandorte – eine Verbesserung für die gesamte Prozesslandschaft
erzielt werden. Für die Komponentenentwicklungsstandorte ist dies nur natürlich, da
ihr Kommunikationsverhalten nicht verändert wurde. Lediglich das Kostenmodell
und die Kommunikationspartner sind variiert worden. Für den Standort Anwen-
dungsentwicklung ist die Prozessauslastung mit nunmehr 77,71 ± 7,12% noch etwas
angestiegen. Der Wert ist ein deutliches Indiz für weiteren Optimierungsbedarf.
Durchschnittliche Pfadlänge:
Die Betrachtung der durchschnittlichen Pfadlänge für die modifizierte Prozessland-
schaft ist lediglich für das Projektmanagement und die Standorte Qualitätsmanage-
ment-Z und Qualitätsmanagement-A interessant, da nur von ihnen Anfragen nach
Richtlinien weitergeleitet bzw. bearbeitet werden. Diese Anfragen waren im ursprüng-
lichen Modell ausschlaggebend für extrem kurze Pfadlängen. Beim Projektmanage-
ment wurden zudem im ursprünglichen Modell die Extremwerte 1 und 5 als Ergebnis
einer statischen Analyse gemessen.
Tabelle 4.18 zeigt jedoch für das Projektmanagement nur eine sehr geringfügige Erhö-
hung der durchschnittlichen Pfadlänge. Dies lässt sich auf das seltene Auftreten von
186
4.2 Analyse dynamischer Kommunikationseigenschaften
Ausgangsbasis modifiziertes Modell
erw. Standard- erw. Standard-
Ort Mittelwert abw. Mittelwert abw.
Anwendungsentwicklung 2,6143 0,1401 2,5905 0,1135
Komponentenentwicklung-1 2,9480 0,2085 3,00 0,20
Komponentenentwicklung-2 3,1072 0,1390 3,0038 0,2026
Komponentenentwicklung-3 2,9891 0,1977 3,0144 0,1970
Komponentenentwicklung-4 3,0494 0,2084 3,09 0,19
Komponentenentwicklung-5 3,0652 0,1804 3,03 0,18
Domain Engineering 3,0320 0,2144 3,00 0,00
Projektmanagement 3,4443 0,0376 3,4571 0,0384
Qualitätsmanagement-Z 2,8596 0,1827 2,3053 0,0933
Qualitätsmanagement-A 2,3396 0,2118 2,2951 1,1914
Tabelle 4.18: Durchschnittliche Pfadlänge der modifizierten Beispielprozesslandschaft
Richtlinienanfragen zurückführen. Der entsprechende Wert für das Qualitätsmanage-
ment der Zentrale ist dagegen gesunken. Die Ursache hierfür liegt in der Nutzung
des Richtlinienservers, der jetzt anstelle einer Aktivität des Qualitätsmanagements für
diesbezügliche Anfragen zur Verfügung steht. Pfade zur Bearbeitung von Richtlinien
sind somit insgesamt verkürzt worden. Ähnliches gilt für das Qualitätsmanagement der
Außenstelle-1. Hier ist der Unterschied zum Wert der durchschnittlichen Pfadlänge der
Ausgangsbasis nur deshalb geringfügig, weil der Standort im modifizierten Modell
Richtlinienerweiterungen jetzt nicht mehr über das Projektmanagement weiterleitet,
sondern direkt auf den Server stellt. Die Pfadlänge ändert sich dadurch also nicht. Sie
ließe sich zwar modellierungsseitig leicht durch das Hinzufügen oder Verfeinern von
Aktivitäten ändern, dies würde jedoch das geforderte einheitliche Abstraktionsniveau
derart verändern, dass keine sinnvoll verwertbaren Ergebnisse mehr berechnet werden
könnten.
Bislang ist für die modifizierte Prozesslandschaft eine Verbesserung für das Kommu-
nikationsaufkommen, die Prozessauslastung und die durchschnittliche Pfadlänge in
Form der Zahlenwerte der Simulationsergebnisse diskutiert worden. Analog zur stati-
schen Analyse müssen diese zahlenmäßigen Verbesserungen ebenfalls bezüglich ihrer
Auswirkungen auf den realen Ablauf eines Softwareentwicklungsprojektes bewertet
werden. Es ist zu untersuchen, ob die optimierten Zahlenwerte tatsächlich zu einer
Verbesserung der Prozessabläufe führen oder ob die Steigerung der Kommunikations-
effizienz auch Nachteile mit sich bringt.
Die durch das Szenario auf Seite 184 dargestellte Modifizierung der Prozesslandschaft
beinhaltet sowohl einige Veränderungen der Kommunikationsinfrastruktur als auch
Umverteilungen von Verantwortlichkeiten und veränderte Zugriffsmöglichkeiten auf
bestimmte Daten. Besteht die Veränderung der Infrastruktur aus dem Austausch ei-
nes vorhandenen Kommunikationssystems durch ein kostengünstigeres wie im Fall
des VPN, über das das zentrale Qualitätsmanagement jetzt mit den Außenstellen In-
187
Validation der Analysemethoden
formationen austauscht, so hat dies sicherlich keine negativen Seiteneffekte auf den
Arbeitsablauf. Muss die bestehende Infrastruktur erweitert werden, damit das Quali-
tätsmanagement der Außenstelle-1 die Test- und Reviewtätigkeiten jetzt auch für die
anderen Außenstellen durchführen kann, so bedeutet dies zunächst einen zusätzlichen
Kostenaufwand. Für die vorliegende Situation kann dieser Aufwand jedoch als gering
angesehen werden, der durch die berechneten Einsparungen schnell wieder ausgegli-
chen ist.
Viel interessanter aber ist die Frage, welche Auswirkungen die Umverteilung der
Verantwortlichkeiten vom zentralen Qualitätsmanagement auf die fachliche Struk-
turierung der Prozessabläufe der Außenstelle-1 hat. Ist mit der Außenstelle-1 an
jedem Softwareprojekt beteiligt und ist damit auch ständig das dort angesiedelte
Qualitätsmanagement-A involviert, so ist auch die Umverteilung der Verantwortlich-
keiten sinnvoll. Ist jedoch die Außenstelle-1 nur an einigen wenigen Softwareprojek-
ten beteiligt, so kann das zentrale Qualitätsmanagement nur für diese Projekte entlastet
werden, und eine permanente Veränderung der Verantwortlichkeiten wäre die Folge.
Eine solche Situation ist eher nicht sinnvoll, denn ein ständig wechselnder Prozessab-
lauf trägt nicht zur Erhaltung oder gar Steigerung der Prozessqualität bei.
Schließlich bedeutet die Auslagerung der Richtlinien auf einen Server, auf den alle
Beteiligten zumindest einen lesenden Zugriff haben, eine Veränderung von Zugriffs-
möglichkeiten, die sich positiv auf den Ablauf einer Softwareentwicklung auswirkt.
So entfallen viele Anfragen – und damit insbesondere auch der Aufwand für deren
Beantwortung –, die sich negativ auf die Prozessauslastung ausgewirkt haben. Mit der
modifizierten Situation ist den zuvor mit der Beantwortung beschäftigten Aktivitäten
jetzt mehr Raum für die Ausführung ihrer eigentlichen Aufgaben gegeben.
Insgesamt sind damit die Ergebnisse der dynamischen Analyse ebenso wie die der
statischen immer vor dem Hintergrund der modellierten realen Prozesse zu sehen und
zu bewerten, damit sie zu einer echten Verbesserung führen.
4.2.3 Nutzenbetrachtung
Der angestrebte Nutzen bei der Analyse dynamischer Kommunikationseigenschaften
auf der Basis einer Simulation ist die Erreichung einer möglichst hohen Kommuni-
kationseffizienz der untersuchten verteilten Prozesslandschaft. Diese Effizienz bezieht
sich auf
 den Auslastungsgrad verteilter Aktivitäten mit Blick auf die Kommunikations-
häufigkeit,
 die räumliche Verteilung von Aktivitäten bezüglich entstehender Kommunikati-
onskosten,
 die Informationsbereitstellung mit Auswirkung auf die Zugriffshäufigkeit auf
Informationen, die von Aktivitäten explizit verteilt werden und
188
4.2 Analyse dynamischer Kommunikationseigenschaften
 die Minimierung der Anzahl vorhandener kurzer Informationsflüsse bzw. Bear-
beitungspfade bezüglich Informationen gleichen Typs.
Der in Abschnitt 4.2.2.2 diskutierte Ansatz greift damit die Prozesssimulation und
-optimierung als eines der von Fugetta angeführten wesentlichen Anwendungsgebie-
te der Prozessmodellierung auf [Fug00]. Zusätzlich zu den dort genannten Zielen des
Erkennens unnötiger Verzögerungen und der Umverteilung von Verantwortlichkeiten
berücksichtigt er auch Ziele einer verbesserten Kommunikationskostenstruktur und ei-
ner besseren Prozessauslastung. Bezogen auf eine Prozesslandschaft sind diese Ziele
erreichbar durch die Identifikation
 derjenigen Stellen, an denen die Effizienz von Aktivitäten durch häufiges War-
ten auf eine Beantwortung ihrer Anfragen vermindert wurde. Im Beispiel wurde
durch die Auslagerung der Qualitätsrichtlinien auf einen Server eine Verbesse-
rung erreicht, da auf diesem Weg sowohl die Anzahl wartender Aktivitäten als
auch die Dauer vieler Wartezeiten stark verringert werden konnte.
 derjenigen Stellen, an denen sich die Einführung eines preiswerteren Kommu-
nikationssystems lohnt. Eine Kostenersparnis für die Beispielprozesslandschaft
durch die Einführung eines neuen Kommunikationssystems konnte ebenfalls in
Abschnitt 4.2.2.2 aufgezeigt werden.
 von bezüglich ihrer Auslastung über- und unterforderten Aktivitäten. Die Um-
verteilung von Aufgaben bzw. Verantwortlichkeiten bezüglich des Qualitätsma-
nagements führte zu einer insgesamt besseren Auslastung aller Standorte bzw.
der an ihnen stattfindenden Aktivitäten.
 von Stellen geringer Bearbeitungstiefe, die sich zum Teil als erwünscht (tayloris-
tische Arbeitsorganisation), zum Teil als verbesserungsbedürftig herausstellten.
Für Letztere konnte in der Beispielprozesslandschaft eine Verbesserung vorge-
schlagen und deren Nutzen (also eine tatsächliche Verbesserung) nachgewiesen
werden.
Die Zielerreichung wurde in Abschnitt 4.2.2.2 an einer konkreten Beispielprozess-
landschaft demonstriert. Zwar müssen auch hier – wie bei jeder Entscheidungsfin-
dung – immer zusätzlich vorhandene Rahmenbedingungen berücksichtigt werden, die
Betrachtung der Kommunikationseffizienz hat sich jedoch insbesondere für verteilte
Prozesslandschaften als nützliches Kriterium bei der Suche nach Optimierungsmög-
lichkeiten erwiesen.
Die in Abschnitt 4.2.2.2 genannten Ziele sind auch auf andere Prozesslandschaften an-
wendbar, da sie losgelöst vom konkreten Kontext der komponentenbasierten Software-
entwicklung formuliert sind. Bei der Interpretation der Auswertungsergebnisse sollte
jedoch nicht vergessen werden, dass menschliches Verhalten mit modelliert wurde –
zum Beispiel durch die Wahrscheinlichkeit, dass ein erstelltes Dokument nachbear-
beitet werden muss (vgl. beispielsweise Aktivität Anforderungsanalyse nachbessern
189
Validation der Analysemethoden
am Standort Anwendungsentwicklung, Anhang A.3). Dies mindert nach Fugetta die
Aussagekraft quantitativer Ergebnisse eines analysierten Modells [Fug00]. Daher soll-
te der Erkenntnisgewinn der Kommunikationsanalyse eher qualitativ als quantitativ
gesehen bzw. bewertet werden. Dieser qualitative Erkenntnisgewinn wird durch den
Vergleich der Simulationswerte für eine gegebene Prozesslandschaft mit einer für ver-
schiedene Optimierungsziele modifizierten Prozesslandschaft erreicht, wie er in Ab-
schnitt 4.2.2.2 vorgenommen wurde.
Sowohl die Analysemethoden des Process Landscaping als auch die dazu erforderliche
vorangehende Modellierung von Prozesslandschaften werden in weiten Teilen durch
geeignete Werkzeuge unterstützt. Diese Werkzeuge werden im nachfolgenden Kapitel
näher vorgestellt. Sie sind teilweise eigens zur Unterstützung der Methode erstellt wor-
den, teilweise ist bereits existierende Software um Process Landscaping-spezifische
Komponenten erweitert worden.
190
Kapitel 5
Werkzeugunterstützung
Eine globale Anforderung an alle Werkzeuge, die im Rahmen des Process Landscaping
eingesetzt werden, ist die Berücksichtigung der Petrinetze als formale Basis der Me-
thode. Dabei sollte vor allem diejenige Petrinetz-Variante unterstützt werden, die von
Ablaufinformationen und damit vom Kontrollfluss abstrahiert. Bislang konzentrieren
sich aber sowohl Methoden der Prozessmodellierung als auch unterstützende Werkzeu-
ge auf die Darstellung von Abläufen. Dies wird auf dem Gebiet der Softwaretechno-
logie bereits an der Definition des Prozessbegriffs deutlich, die einen Prozess als eine
partiell geordnete Menge von Prozessschritten zur Erstellung eines Softwareproduktes
bezeichnet und damit eine Vorgehensweise – also einen Ablauf – zur Durchführung
konkreter Aktivitäten erkennen lässt (vgl. Kapitel 1.3). Viele Prozesse sind jedoch zu
unstrukturiert oder folgen einer flexiblen Ablaufreihenfolge. Letztere beschränkt sich
nicht auf Parallelitäten und Sequenzen von Aktivitäten, sondern lässt die Reihenfol-
ge ihrer Durchführung offen. Diese Art von Prozessen kann daher bislang kaum oder
gar nicht durch Prozessmodellierung unterstützt werden, denn jeder durch einen de-
finierten Ablauf beschriebene Prozess unterstützt einen Prozessteilnehmer nicht nur,
sondern schränkt gleichzeitig seine individuelle Vorgehensweise ein. Unstrukturierte
oder flexibel ablaufende Prozesse – in der Literatur auch als semi-strukturiert bezeich-
net [Dei00] – finden sich jedoch sehr häufig in Klein- und Mittelbetrieben, die verstärkt
auf Kreativität und Flexibilität ihrer Softwareentwicklung setzen. Flexibilität bezieht
sich hier auf eine nicht im vorhinein festgelegte Ablaufreihenfolge definierter Akti-
vitäten, die sich aus der Unstrukturiertheit des zugrundeliegenden Prozesses ergibt.
Eine korrespondierende Flexibilität im Prozessmodell kann entweder durch die Mo-
dellierung aller möglichen Ablaufalternativen oder durch die Abstraktion von einem
festen Ablauf ermöglicht werden. Für die Methode des Process Landscaping wird in
Abschnitt 5.1 eine geeignete Werkzeugunterstützung für die zweite Möglichkeit vor-
gestellt.
Durch den aktuellen Trend, die Softwareentwicklung auf teilweise weit auseinander-
liegende Standorte zu verteilen, entstehen weitere Anforderungen an eine werkzeug-
gestützte Prozessmodellierung: Er erfordert die Erstellung der Modelle durch meh-
rere Modellierer. Diese Erstellung muss trotz einer geografischen Verteilung sowohl
191
Werkzeugunterstützung
der Prozesse als auch der Modellierer in einem kooperativen Arbeitsprozess erfolgen
[Zie96]. Mit solchen Kooperationsprozessen und der Notwendigkeit, diese informati-
onstechnisch zu unterstützen, beschäftigt sich seit Mitte der achtziger Jahre das For-
schungsgebiet der Computer-Supported Cooperative Work (CSCW) [Gre88]. Das in
Abschnitt 5.1 diskutierte Werkzeug zur Unterstützung des Process Landscaping ver-
folgt mit der expliziten Berücksichtigung dieser arbeitsteiligen Kooperationsprozesse
gleichzeitig eines der Kernziele des CSCW.
Durch ein verteiltes Modellieren von Prozessen ergibt sich des Weiteren die verstärkte
Notwendigkeit einer werkzeugunterstützten Konsistenzprüfung für die erstellten Mo-
delle. Verfügbare Modellierungswerkzeuge unterstützen ein verteiltes und kooperie-
rendes Arbeiten bislang nicht oder nur unzureichend (vgl. beispielsweise Aris [IDS01],
LeuSmart [ade99], Innovator [MID01], Bonapart [Int01], Adonis [BOC02]). Ein Team
von Modellierern, das an einer gemeinsamen Menge von Prozessmodellen arbeitet,
muss daher viel Aufwand für die Abstimmung der Schnittstellen zwischen den Ein-
zelmodellen betreiben. Ein Werkzeug zur Prozessmodellierung sollte jedoch nicht nur
die gemeinsame Erstellung einer Prozesslandschaft durch ein Modellierungsteam un-
terstützen, welches vielleicht zudem noch geografisch verteilt arbeitet, sondern auch
eine gleichzeitige Nutzung der Prozessmodelle seitens der geografisch verteilten Pro-
zessbeteiligten ermöglichen, die diese zur Unterstützung ihrer Arbeit verwenden wol-
len. Mit dieser Unterstützung ist hier nicht der Einsatz eines (verteilten) Systems ge-
meint, sondern eine Zugriffsmöglichkeit auf die Darstellung und Dokumentation der
Prozesse für ein besseres Prozessverständnis.
Bislang konzentriert sich die Werkzeugunterstützung auf die Rolle des Modellierers,
indem Funktionen zur einfachen und schnellen Darstellung von Prozessen angeboten
werden. Prozessbeteiligte haben jedoch andere Anforderungen an die Nutzung einer
Prozesslandschaft als ein Modellierer für deren Erstellung. Für sie ist es neben einem
Gesamtüberblick wichtig, ohne große Umwege diejenigen Informationen innerhalb
des Gesamtprozesses zu finden, die für sie relevant sind. Das bedeutet, dass die für
ihren Standort und ihre Teilaufgaben relevanten Informationen einfach zu filtern sein
müssen, Querbezüge zu anderen Aktivitäten aber über die modellierten Schnittstellen
schnell herstellbar sein sollten.
Im Zusammenhang mit der Entwicklung des Process Landscaping ist ein Prozessmo-
dellierungswerkzeug mit Namen Piazza Palermo entstanden [Pro01], mit dem eine zu-
sammengehörige Menge von Prozessen verteilt und unter Vernachlässigung von Ab-
laufinformationen als eine einheitliche Prozesslandschaft kooperativ modelliert wer-
den kann. Einige prototypisch realisierte Analysefunktionen stehen ebenfalls zur Ver-
fügung. Prozessbeteiligte können über einen Webbrowser lesend auf eine modellierte
Prozesslandschaft zugreifen. Ihnen stehen sowohl Navigationsmöglichkeiten durch die
Landschaft als auch Möglichkeiten zur gezielten Informationssuche zur Verfügung.
Die Oberfläche und die Funktionalitäten von Piazza Palermo werden in Abschnitt 5.1
vorgestellt.
Eine durchgängige weiterführende Modellierung der unteren Ebenen einer Prozess-
landschaft ohne Bruch in der Anwendung des Process Landscaping wird mit Hilfe ei-
192
5.1 Modellierung und Analyse der oberen Ebenen einer Prozesslandschaft
ner ebenfalls im Rahmen der Methode entwickelten Schnittstelle von Piazza Palermo
zu einem bereits existierenden Prozessmodellierungswerkzeug gewährleistet [Bro02].
Diese Schnittstelle unterstützt den Modellierer Schritt für Schritt bei der konsistenten
Erweiterung einer mit Piazza Palermo erstellten Prozesslandschaft zur Modellierung
und Analyse ihrer unteren Ebenen. Sie wird in Abschnitt 5.2 ausführlich diskutiert.
Abschnitt 5.3 erläutert zunächst kurz die Vorgehensweise bei der Modellierung der un-
teren Ebenen einer Prozesslandschaft mit dem Prozessmodellierungswerkzeug Renew
[KW99]. Der Fokus liegt dabei auf der Modellierung eines Simulationsmodells zur
Analyse der dynamischen Kommunikationseigenschaften einer gegebenen Prozess-
landschaft. Zur Auswertung der Simulationsergebnisse ist das Werkzeug im Rahmen
dieser Arbeit um die Anbindung an eine Datenbank und eine entsprechende Auswer-
tungskomponente erweitert worden, die speziell die Analyseziele des Process Land-
scaping berücksichtigt [Stö01b, SW02b]. Die Diskussion dieser Erweiterungen bildet
einen weiteren Schwerpunkt des Abschnitts 5.3.
Alle Komponenten der Werkzeugunterstützung werden entlang der bereits aus den vor-
angegangenen Kapiteln bekannten Prozesslandschaft zur komponentenbasierten Soft-
wareentwicklung diskutiert.
5.1 Modellierung und Analyse der oberen Ebenen einer
Prozesslandschaft
Erklärtes Ziel bei der Realisierung des Prozessmodellierungswerkzeugs Piazza
Palermo war die Erstellung eines Werkzeugs, welches insbesondere die rollenspezi-
fischen Anforderungen von Modellierern und Prozessbeteiligten an eine Prozessland-
schaft berücksichtigt. Der Zugriff auf die von Piazza Palermo zur Verfügung gestellten
Funktionalitäten ist daher bezüglich der unterschiedlichen Rollenanforderungen auf-
geteilt: Der Editor des Werkzeugs ist ausschließlich für eine Nutzung durch den bzw.
die Prozessmodellierer vorgesehen. Er ermöglicht neben der grafischen Modellierung
einer Prozesslandschaft auch deren Dokumentation und bietet Funktionen zur Konsis-
tenzprüfung und Analyse. Die Trennung zwischen Funktionalitäten für Modellierung
und Nutzung einer Prozesslandschaft seitens der Beteiligten wird durch einen zweiten,
ausschließlich lesenden Zugriff auf die Daten einer Prozesslandschaft deutlich: Ein
Viewer erlaubt jedem Prozessbeteiligten über einen Webbrowser lesenden Zugriff auf
die Prozessdokumentation. Er realisiert gleichzeitig eine sehr einfache und effiziente
Bereitstellung wichtiger Prozessinformationen für die geografisch verteilt arbeitenden
Prozessbeteiligten.
Mit dieser Aufteilung der Kernfunktionen können sowohl Modellierer als auch Betei-
ligte der Prozesslandschaft individuell unterstützt werden. Beide Rollen greifen auf ei-
ne gemeinsame Datenbasis zu, die die Konsistenz der produzierten und genutzten Da-
ten sichert. Bezüglich der zugrundeliegenden Softwarearchitektur sei an dieser Stelle
lediglich darauf hingewiesen, dass Piazza Palermo client/server-basiert mit einer zen-
tralen Datenbank arbeitet. Dies ist Grundlage für ein verteiltes Arbeiten sowohl der
193
Werkzeugunterstützung
Modellierer als auch der Prozessbeteiligten. Die Architektur wurde an die Struktur des
Model-View-Controller-Entwurfsmusters [GHJV94] angelehnt. Eine detaillierte Be-
schreibung zur Verteilung der einzelnen Softwarekomponenten auf Client und Server
und ihrer Kommunikation untereinander ist in [Pro01] zu finden.
5.1.1 Unterstützung der Modellierungsphase
Im Folgenden wird erläutert, wie die Aufgaben und Anforderungen eines Prozessmo-
dellierers unterstützt werden bzw. durch entsprechende Funktionen im Editor des
Werkzeugs realisiert worden sind.
Abbildung 5.1 zeigt eine Prozesslandschaft, in der Kernprozesse der komponentenba-
sierten Softwareerstellung abgebildet sind. Alle zu einer Prozesslandschaft gehörigen
Prozesse, Teilprozesse und Aktivitäten sind hierarchisch geordnet als Baum darge-
stellt. Ihre Relation zueinander – konkret ihre hierarchische Ordnung – ist aus dem
Navigationsbaum, dem sogenannten Aktivitätenbaum, ersichtlich. Von den auszutau-
schenden Informationen ist in dieser Darstellung abstrahiert worden.
Abbildung 5.1: Verschiedene Arbeitsfenster zur Darstellung und Bearbeitung einer
Prozesslandschaft
Zusätzlich bietet das Werkzeug dem Modellierer die Möglichkeit, alle innerhalb der
Prozesslandschaft definierten Dokumente (Registerkarte All Documents) und deren
Typen (Registerkarte Document Types) angezeigt zu bekommen. Als Beispiel sei das
in der hier diskutierten Prozesslandschaft dargestellte Dokument Entwicklungsbeauf-
tragung vom Typ Auftragsdokument genannt. Bei der Modellierung einer Prozessland-
schaft mit Piazza Palermo wird davon ausgegangen, dass alle Informationen über Do-
194
5.1 Modellierung und Analyse der oberen Ebenen einer Prozesslandschaft
kumente ausgetauscht werden, die jeweils von einem konkreten Typ wie z.B. Anforde-
rungsdokument oder Review-Bericht sind. Es wird also nicht nur von Ablaufinforma-
tionen innerhalb der Prozesse abstrahiert, man beschränkt sich auch bei der Modellie-
rung von Informationsobjekten auf diejenigen Kerndaten, die schriftlich fixiert werden
und einer konkreten Dokumentationsform (Dokumenttyp) zugeordnet werden können.
Abbildung 5.1 zeigt alle zur Aktivität Component Engineering gehörenden Teilakti-
vitäten (dargestellt durch Rechtecke) und verwendete Dokumente (dargestellt durch
Kreise). Der Überblick über die gesamte Softwareprozesslandschaft bleibt durch das
Fenster Landscape Navigation erhalten. Im rechts dargestellten Arbeitsfenster können
die Landschaftselemente editiert werden. Jede Aktivität kann zusätzlich noch weiter
verfeinert werden. Bereits verfeinerte Aktivitäten innerhalb einer Abstraktionsebene
erkennt man im Arbeitsfenster an ihrer Weißfärbung. Nicht weiter verfeinerte Aktivi-
täten sind grau gezeichnet. In Abbildung 5.1 erkennt man sowohl verfeinerte als auch
nicht verfeinerte Aktivitäten als Bestandteile der Aktivität Component Engineering.
Werden Dokumente von einer Aktivität geschrieben und von einer anderen Aktivität
gelesen, bezeichnet man sie auch als Schnittstellendokumente. Liegen die beiden be-
teiligten Aktivitäten nicht in derselben Verfeinerung, werden die zugehörigen Schnitt-
stellendokumente durch einen breiteren Rand besonders gekennzeichnet. In Abbil-
dung 5.1 sind alle dort vorhandenen Dokumente Schnittstellendokumente, die sowohl
von Aktivitäten innerhalb der Verfeinerung des Component Engineering als auch von
Aktivitäten auf höheren oder niedrigeren Abstraktionsebenen verwendet werden.
Die grafische Repräsentation der Beispiellandschaft in Abbildung 5.1 bzw. der Teilaus-
schnitt im rechten Arbeitsfenster erinnert an ein konventionelles Petrinetz, dargestellt
durch einen bipartiten Graphen. Der Unterschied liegt im Fehlen des Kontrollflusses.
Mit Piazza Palermo werden lediglich Zugriffe von Aktivitäten auf Dokumente (als
spezielle Informationstypen) modelliert. Welche Aktivität jedoch wann und unter wel-
chen Voraussetzungen auf Dokumente zugreift, ist nicht modelliert, da Ablaufinforma-
tionen nicht betrachtet werden. Eine mit Piazza Palermo erstellte Prozesslandschaft ist
somit konform zu den in Abschnitt 3.1 formulierten formalen Grundlagen der oberen
Ebenen einer Prozesslandschaft.
Durch die Abstraktion von Ablaufinformationen und die Fokussierung auf Aktivitäten,
Informationen und den Zugriffen auf letztere ist das Modellierungsresultat bei der Ver-
wendung von Piazza Palermo auch mit Datenflussdiagrammen vergleichbar, die laut
Definition Verarbeitungen (hier: Aktivitäten) und Daten (hier: Dokumente) sowie die
Verbindungen (hier: Lese-/Schreibzugriffe) zwischen beiden darstellen [Bal96].
Sind Veränderungen am Inhalt einer Verfeinerung vorgenommen worden, wird dies im
zugehörigen Arbeitsfenster rechts oben durch den Begriff CHANGED angezeigt (vgl.
Abbildung 5.1). Sämtliche Änderungen werden vorerst nur lokal am Arbeitsplatz des
Modellierers durchgeführt und noch nicht in die Datenbank übernommen. Während
der Modellierer seine Änderungen bzw. Erweitungen innerhalb einer Abstraktions-
ebene durchführt, wird dies allen anderen parallel an dieser Prozesslandschaft arbei-
tenden Modellierern angezeigt. Der Schreibschutz pro Arbeitsfenster und damit pro
Abstraktionsebene einer Prozesslandschaft sichert die Konsistenz bei gleichzeitiger
195
Werkzeugunterstützung
Bearbeitung durch mehrere Modellierer. Bei einem Änderungsversuch eines zweiten
Modellierers erhält dieser eine Fehlermeldung, die auch den Namen des bearbeitenden
Modellierers enthält. Diese Information verhindert lange Wartezeiten bei notwendigen
Änderungen und verbessert die Effizienz einer kooperierenden Modellierung, da die
beteiligten Modellierer sich gegenseitig identifizieren und direkt (außerhalb des Werk-
zeugs) erforderliche Anpassungen an der Prozesslandschaft miteinander abstimmen
können. Trotzdem bleibt im Unterschied zu anderen Prozessmodellierungswerkzeu-
gen die parallele Bearbeitung einer Prozesslandschaft durch ein Modellierungsteam
gewährleistet, da immer nur die jeweils bearbeitete Abstraktionsebene, d.h. nur die
Verfeinerung einer einzelnen Aktivität, für den Schreibzugriff, nicht aber den Lesezu-
griff anderer Modellierer gesperrt ist.
Der Editor von Piazza Palermo erlaubt dem Modellierer jederzeit eine detaillierte Ana-
lyse der aktuellen Prozesslandschaft. So lassen sich früh Fehler während der Model-
lierung identifizieren oder Verbesserungen protokollieren. Der Aufruf der Analyse-
funktion liefert eine Menge verschiedener Ergebnisse, die analog zu den Aktivitäten
einer Prozesslandschaft über einen Navigationsbaum angewählt werden können. Die
oberste Ebene des Analysebaumes (vgl. Statistics in Abbildung 5.2) liefert zunächst
allgemeine Informationen über eine Prozesslandschaft, wie beispielsweise die Anzahl
modellierter Aktivitäten und Dokumente oder die maximale Tiefe des Aktivitätenbau-
mes.
Abbildung 5.2: Analyseergebnis der Softwareprozesslandschaft
Abbildung 5.2 zeigt das Analyseergebnis der Beispiellandschaft. Die Kategorie Un-
used Documents liefert Informationen über diejenigen Landschaftselemente, die noch
nicht über Zugriffsrelationen mit anderen verbunden sind. Die in der Abbildung ausge-
wählte Kategorie Access zeigt für jede Aktivität die Anzahl verwendeter Dokumente
an. Durch Markieren einer konkreten Aktivität werden diese Dokumente jeweils na-
mentlich aufgelistet. Diese Information kann auch über eine Dokumentensicht (Docu-
ment To Activity Access) eingesehen werden. Über Documents kann man unter ande-
rem erkennen, ob es modellierte Dokumente gibt, die nur gelesen oder nur geschrieben
196
5.1 Modellierung und Analyse der oberen Ebenen einer Prozesslandschaft
werden. So sollten Dokumente wie z.B. das Anforderungsdokument im Laufe eines
Softwareentwicklungsprojektes immer geschrieben und auch gelesen werden. Dage-
gen sollten etwa Programmierrichtlinien von Entwicklungsaktivitäten ausschließlich
gelesen werden können. Ist aber aktuell nur ein schreibender Zugriff modelliert, kann
dieser Fehler innerhalb der Statistik über Write Only Documents schnell identifiziert
werden. Sollten Verfeinerungen einer Aktivität leer sein, oder enthält eine Verfeine-
rung nur eine einzige Aktivität, wird dies unter Refinements angezeigt.
Die Analyse unterstützt damit insbesondere Anforderungen, die der Rolle des Model-
lierers zuzuordnen sind. Dieser kann über die verschiedenen Analysekategorien auf
schnellem und einfachem Weg Inkonsistenzen und Unvollständigkeiten in einer Pro-
zesslandschaft identifizieren, die gerade bei der parallelen Modellierung eines verteilt
arbeitenden Teams verstärkt auftreten können.
Eine Unterstützung semantischer Analysen wie z.B. die Untersuchung effizienter Ver-
teilung der Prozesse und damit einer effizienten Kommunikationsstruktur für eine Pro-
zesslandschaft PLtop−com (vgl. Abschnitt 3.1.3) ist ein zukünftiges Ziel der Analyse
mit Piazza Palermo. Dazu ist es bereits jetzt möglich, die modellierten Zugriffe von
Aktivitäten auf Dokumente mit Kommunikationsattributen bezüglich Veränderbarkeit,
Verschlüsselung, Persistenz, Privatheit und Synchronität zu versehen (vgl. Object In-
spector in Abbildung 5.1). Die Auswertung der Attributwerte erfolgt momentan pro-
totypisch über SQL-Abfragen; eine Umstrukturierung in die lokale Sicht muss noch
manuell durchgeführt werden.
5.1.2 Unterstützung der Nutzungsphase
Dieses Unterkapitel beschreibt den Einsatz und Nutzen von Piazza Palermo für die
Rolle des Prozessbeteiligten, der sich einen schnellen Überblick über den Gesamtpro-
zess, der von ihm durchzuführenden Aktivitäten und die von ihm zu verwendenden
Dokumente verschaffen will. Wie bereits erwähnt, ist für Prozessbeteiligte ein geson-
derter, ausschließlich lesender Zugriff auf modellierte Prozesslandschaften implemen-
tiert worden. Dies hat den Vorteil, dass Prozessbeteiligte nicht von Modellierungs-
funktionen des Werkzeugs abgelenkt werden oder sich aufwändig einarbeiten müssen.
Zusätzlich schützt es die Arbeit der Modellierer vor ungewollten Veränderungen an
einer Prozesslandschaft.
Piazza Palermo bietet über ein Webportal Zugriff auf den Aktivitätenbaum und die Do-
kumentation einer Prozesslandschaft. Dies erfordert lediglich einen Arbeitsplatzrech-
ner, der über einen Internet-/Intranetanschluss und einen Browser verfügt. Der Editor
von Piazza Palermo muss nicht verfügbar sein. Der Begriff des Webportals meint hier
eine „Eingangspforte“ bzw. einen „Informationskanal“ für Prozessbeteiligte. Er er-
füllt nicht unbedingt alle mit ihm verknüpften Anforderungen, die u.a. in [HH99] und
[HKM01] diskutiert werden.
Abbildung 5.3 zeigt die diskutierte Softwareprozesslandschaft aus der Sicht eines
Prozessbeteiligten, zu erkennen an ihrem Namen CBD4 (Component-Based Develop-
ment4), rechts oben in der Grafik aufgeführt. Der Aufbau des links in der Abbildung
197
Werkzeugunterstützung
dargestellten Navigationsbaumes ist an den des Editors angelehnt. Er erlaubt dem An-
wender eine intuitive Navigation sowohl durch die Aktivitäten als auch durch die Lis-
te modellierter Dokumente der aktuellen Prozesslandschaft. Wird beispielsweise eine
Aktivität ausgewählt, so werden neben ihrer Dokumentation (Description) auch Quer-
bezüge zu benötigten bzw. erzeugten Dokumenten (Source/Target Documents) aufge-
zeigt. Die Liste der zugehörigen Dokumente besteht aus Links, mit deren Hilfe direkt
zu deren Beschreibung navigiert werden kann. Am Beispiel der Aktivität Spezifikation
erstellen ist dies in Abbildung 5.3 gezeigt. Ist ein Anwender an der vollständigen Do-
kumentation einer Prozesslandschaft interessiert, kann er diese ebenfalls abrufen. Sie
setzt sich zusammen aus den Einzeldokumentationen jeder Aktivität und jedes model-
lierten Dokuments.
Abbildung 5.3: Webportal von Piazza Palermo
Das Portal von Piazza Palermo bietet neben dem manuellen Durchlauf durch eine Pro-
zesslandschaft entlang des Aktivitätenbaumes und der Dokumentenliste auch jederzeit
die gezielte Suche nach Aktivitäten oder Dokumenten. So erlaubt es allen Prozessbe-
teiligten eine effiziente und bequeme Nutzung ihrer Prozesslandschaft ohne die Not-
wendigkeit zusätzlicher Softwareinstallation. Aufwändige Einarbeitungsphasen oder
gar Schulungen sind nicht notwendig, wenn dem Anwender der Umgang mit dem In-
ternet und Grundfunktionen herkömmlicher Browser vertraut sind, da das Portal eine
intuitive Navigation und übersichtliche Darstellung der modellierten Informationen
bietet.
198
5.2 Erweiterung zur Modellierung und Analyse unterer Ebenen
5.2 Erweiterung zur Modellierung und Analyse unterer
Ebenen
Für einen Modellierer, der sowohl die unteren als auch die oberen Ebenen einer Pro-
zesslandschaft durchgängig werkzeugunterstützt modellieren möchte, ist im Rahmen
des Process Landscaping eine Schnittstelle als Erweiterung von Piazza Palermo reali-
siert worden, die die Übertragung von Prozesslandschaften aus Piazza Palermo heraus
in ein Werkzeug für die Modellierung der unteren Ebenen ermöglicht. Die Software
verwendet XML-Dateien zur Speicherung, Verwaltung und Übertragung der Land-
schaftsdaten. Für eine detaillierte Beschreibung der Datenverwaltung und der der
Schnittstelle zugrundeliegenden Softwarearchitektur sei auf [Bro02] verwiesen. Als
Modellierungswerkzeug für die unteren Landschaftsebenen, in welches eine Prozess-
landschaft übertragen wird, bot sich Renew an [Kum00], da dieses mit dem werk-
zeugeigenen Editor erstellte Prozesslandschaften ebenfalls als XML-Datei speichert
und verwaltet. Die XML-Schnittstelle von Renew stellt somit einen wichtigen Teil des
Bindegliedes zwischen Piazza Palermo und Renew dar.
Die Handhabung der Schnittstelle wird entlang der in Abschnitt 3.2.1 vorgestellten
Vorgehensweise für das Hinzufügen von Ablaufinformationen wiederum am Beispiel
der Prozesslandschaft zur komponentenbasierten Softwareentwicklung beschrieben.
Nach dem Öffnen einer zu übertragenden Prozesslandschaft bzw. eines Teilbereiches
einer Landschaft (z.B. Verfeinerungen einzelner Aktivitäten) erfolgt der Aufruf der
Schnittstellenkomponente in Piazza Palermo. Eine Dialogmaske wie in Abbildung 5.4
dargestellt informiert den Anwender über den Fortschritt der Übertragung. Dieser Dia-
log ist in drei Bereiche unterteilt.
Abbildung 5.4: Ansicht der Schnittstellenoberfläche nach dem Start
Der Bereich Progress links in der Abbildung zeigt an, welche Schritte bereits durchge-
führt wurden und welche noch folgen. Im unteren Bereich sind die Schaltflächen back,
next und cancel zu finden, mit denen der Modellierer den Übertragungsablauf steuern
199
Werkzeugunterstützung
kann. Im Hauptbereich transformation progress findet sich schließlich eine Statusmel-
dung zum jeweiligen Arbeitsschritt. In einigen Fällen hat der Anwender hier zusätzlich
die Möglichkeit, eine Anweisung zum Überspringen des nächsten Arbeitsschrittes zu
geben.
Nach dem Start der Schnittstellenkomponente und der Anzeige der in Abbildung 5.4
dargestellten Dialogmaske wird vom Werkzeug zunächst die XML-Struktur für das
Hinzufügen von Ablaufinformationen vorbereitet. Dazu sind zuvor alle Verfeinerun-
gen der ausgewählten Prozesslandschaft zu einem zusammenhängenden Petrinetz ver-
knüpft worden, indem unter anderem alle aus syntaktischer Sicht möglichen Daten-
flüsse (gemäß Definition 3.2.8 in Abschnitt 3.2.1.1) berechnet und dargestellt werden.
Nach diesen automatisierten Schritten ist es die Aufgabe des Modellierers, für jede
Aktivität das Ein- und Ausgangsschaltverhalten festzulegen.
Abbildung 5.5 zeigt die zugehörige Eingabemaske. Auf der linken Seite wird zunächst
eine Aktivität ausgewählt. Für diese werden am unteren Rand weitere Informationen,
wie ihre Anordnung im Aktivitätenbaum (als Pfad) und ihre Dokumentation, ange-
zeigt. Auf der rechten Seite der Eingabemaske sind die Schnittstellen im Vor- (In-
put interfaces) und Nachbereich (Output interfaces) der ausgewählten Aktivität auf-
gelistet. Für diese werden bei ihrer Auswahl ebenfalls weitere Informationen (inter-
face description) angezeigt. In den Schnittstellenlisten selbst sind zusätzlich Vor- und
Nachbereich aller Schnittstellen aufgeführt.
Abbildung 5.5: Festlegen der Schaltverhalten
Ändert der Modellierer das voreingestellte All-Schaltverhalten einer Aktivität, kann
er anschließend die Listen der Schalt- (Input sets) und Ergebnismengen (Output sets)
200
5.2 Erweiterung zur Modellierung und Analyse unterer Ebenen
entsprechend verändern. Das Sternsymbol vor dem Namen einer Schnittstelle zeigt
ihm an, dass diese in einer ausgewählten Schalt- bzw. Ergebnismenge enthalten ist.
In Abbildung 5.5 ist die Bearbeitung des Schaltverhaltens der Aktivität Entscheidung
neu oder anpassen dargestellt. Für diese wurden zwei Schaltmengen input set und vier
Ergebnismengen output set festgelegt. Die Schaltmenge input set 2 umfasst den ge-
samten Vorbereich der Aktivität, während die ausgewählte Ergebnismenge output set 3
lediglich die Schnittstellen Auftrag Komponentenentwicklung.1 und Auftrag Kompo-
nentenentwicklung.2 enthält. Um den Inhalt der übrigen Schalt- und Ergebnismengen
anzuzeigen, kann der Modellierer die jeweiligen Mengen in der Liste auswählen. Die
zugehörigen Schnittstellen werden dann unmittelbar mit dem Sternsymbol markiert.
Da alle Informationen, die der Modellierer an dieser Stelle eingibt, direkt in die Pro-
zesslandschaft übertragen werden, kann diese jederzeit in Textform angezeigt werden.
Abbildung 5.6 zeigt diese Darstellung.
Abbildung 5.6: Darstellung der Prozesslandschaft innerhalb der Schnittstelle
Hier sind für jede Aktivität die zugehörigen Schaltverhalten, Schalt- und Ergebnis-
mengen, gegebenenfalls Relationen zwischen Schalt- und Ergebnismengen (bei ab-
hängigem Ausgangsschaltverhalten, vgl. Definition 3.2.26 in Abschnitt 3.2.1.2) sowie
alle Schnittstellen inklusive ihrem Vor- bzw. Nachbereich aufgeführt. Bei Bedarf kann
diese textuelle Darstellung über die Zwischenablage in andere Programme übertragen,
dort bearbeitet und ausgedruckt werden.
Der Nutzen dieser in Abbildung 5.6 dargestellten Ansicht der Prozesslandschaft be-
steht in der Gewährleistung eines vollständigen Überblicks über den aktuellen Status
der hinzugefügten Ablaufinformationen. Dieser kann bei der Komplexität der Infor-
mationen, die pro Aktivität einzugeben sind, ohne diese Ansicht leicht verloren gehen.
201
Werkzeugunterstützung
Nach dem Festlegen der Schaltverhalten aller Aktivitäten kann der Modellierer optio-
nal nach den in Abschnitt 3.2.1.4 definierten Sonderfällen Zusammengefasste Aktivität,
Zwei-Phasen-Aktivität und Vier-Augen-Prinzip suchen lassen und diese automatisiert
verfeinern. Konnte in der ausgewählten Prozesslandschaft ein Sonderfall identifiziert
werden, wird dies mit der in Abbildung 5.7 dargestellten Dialogmaske angezeigt. Im
hier dargestellten Fall ist die Aktivität Anforderungsanalyse erstellen als Zwei-Phasen-
Aktivität identifiziert worden, die für die Erstellung eines Anforderungsdokumentes in
der ersten Phase zunächst das Ergebnis der Aktivität Geschäftsprozess modellieren an-
fordert. Die Schnittstelle Erste Anforderungen.1 wird für beide Phasen benötigt und
daher entsprechend dupliziert, bevor die Aktivität Anforderungsanalyse erstellen ge-
mäß dem Sonderfall der Zwei-Phasen-Aktivität verfeinert wird (vgl. Diskussion dieses
Sonderfalls in Abschnitt 3.2.1.4).
Abbildung 5.7: Ansicht der Schnittstellenoberfläche bei identifiziertem Sonderfall
Die automatisierte Anwendung eines identifizierten Sonderfalls muss vom Modellierer
explizit angestoßen werden. Die Durchführung erfolgt dann wie in Abschnitt 3.2.1.4
beschrieben. Die Schnittstellenkomponente ist dabei so realisiert, dass später ohne Pro-
bleme weitere Sonderfälle berücksichtigt werden können, die zum jetzigen Zeitpunkt
noch nicht spezifiziert sind.
Das Ergebnis einer in Piazza Palermo modellierten, mit Ablaufinformationen er-
gänzten und in Renew übertragenen Prozesslandschaft ist ausschnittsweise in Abbil-
dung 5.8 dargestellt. Für die Darstellung in Renew wurde jedoch aus Gründen der
Übersichtlichkeit von einigen Landschaftsattributen abstrahiert. Lediglich die Namen
der Aktivitäten und Schnittstellen sowie die Information, ob es sich um interne oder
202
5.3 Modellierung und Simulation der unteren Ebenen einer Prozesslandschaft
externe Schnittstellen handelt, sind angegeben. Damit ist die Übergabe einer Prozess-
landschaft von Piazza Palermo nach Renew inklusive des Hinzufügens von Ablauf-
informationen mit Hilfe der Schnittstellenkomponente abgeschlossen. Jetzt kann ein
Modellierer die unteren Ebenen dieser Prozesslandschaft beliebig tief und detailliert
modellieren.
Abbildung 5.8: Ausschnitt aus der in Renew importierten Prozesslandschaft
Soll eine Analyse der dynamischen Kommunikationseigenschaften dieser – nun als ein
zusammenhängendes, komplexes Petrinetz modellierten – Landschaft erfolgen, bie-
tet es sich an, diese in ihre lokale Sicht umzustrukturieren und in mehrere Teilnetze
aufzuteilen, um so die Kommunikation in einer verteilten Prozesslandschaft geeignet
betrachten zu können. Für die Analyse dynamischer Kommunikationseigenschaften
ist Renew um eine Datenbankanbindung und eine Auswertungskomponente erweitert
worden. Die Diskussion der Erstellung eines Simulationsmodells und die Auswertung
der Simulationsergebnisse ist Gegenstand des nachfolgenden Unterkapitels.
5.3 Modellierung und Simulation der unteren Ebenen einer
Prozesslandschaft
Für die Modellierung der unteren Ebenen einer Prozesslandschaft existiert bereits ei-
ne Vielfalt von Prozessmodellierungswerkzeugen [CPN00], die auf unterschiedlichen
Petrinetz-Varianten basieren. Zur Unterstützung des Process Landscaping ist aus dieser
Vielfalt Renew, ein am Arbeitsbereich TGI des Fachbereichs Informatik der Univer-
sität Hamburg entwickeltes Softwarewerkzeug ausgewählt worden, das den Anforde-
rungen der Methode genügt.
Mit Hilfe des grafischen Editors von Renew können Prozesslandschaften von Model-
lierern mit Petrinetz-Kenntnissen recht schnell und komfortabel modelliert werden.
203
Werkzeugunterstützung
Durch den Einsatz sogenannter Stellvertreterstellen (virtual places) kann die grafische
Darstellung von Petrinetzen vereinfacht werden. Diese Stellen sind lediglich Kopien
der grafischen Darstellung einer Stelle und semantisch von dieser nicht unterscheidbar.
Sie verbessern die Lesbarkeit und damit die Verständlichkeit von modellierten Netzen,
in denen bestimmte Stellen mit vielen Transitionen verbunden sind. Beispielweise bie-
tet sich die Darstellung der Schnittstelle Anfrage an Repository.1(Anfrage) (links in
Abbildung 5.8) als Stellvertreterstelle an, nachdem die Prozesslandschaft vollständig
mit Ablaufinformationen angereichert und in Renew übertragen ist, da viele Aktivitä-
ten eine entsprechende Anfrage stellen.
In Renew wird unter anderem zwischen einfachen und flexiblen Kanten unterschie-
den. Flexible Kanten haben die Eigenschaft, dass Art und Anzahl derjenigen Marken,
die sie transportieren, während der Simulation durch entsprechende Inskriptionen si-
tuationsabhängig verändert werden können. In Abbildung 5.8 sind alle fünf von der
Aktivität Entscheidung neu oder anpassen.2 (linke obere Aktivität) nach oben verlau-
fende Kanten als flexible Kanten modelliert, erkennbar an ihrer doppelten Pfeilspitze.
Weitere Kanten und deren Nutzung sind im Handbuch für Renew [KWD00] beschrie-
ben.
Für die Simulation einer verteilten Prozesslandschaft zur Analyse dynamischer Kom-
munikationseigenschaften empfiehlt es sich, diese auf mehrere Petrinetze aufzuteilen.
Wie in Abschnitt 4.2.1 bereits für die zur Validation herangezogene Beispielprozess-
landschaft beschrieben, wird für ihre lokale Sicht jeder Standort als separates Netz
modelliert. Inhaltlich identische Standorte wie beispielsweise Komponentenentwick-
lung-1 bis Komponentenentwicklung-5 sind dabei durch mehrere Instanzen eines Net-
zes abgebildet. Auch die Kommunikationssysteme werden als separate Netze model-
liert. Bei der Modellierung eines Kommunikationskanals innerhalb eines Kommuni-
kationssystems werden die Aktivitäten a
1
und a
2
jeweils durch ein Aktivitätenpaar
(a
1,dn, a1,up) und (a2,dn, a2,up) ersetzt. Eine die Kommunikation startende Aktivi-
tät adn wird dabei als Downlink bezeichnet, eine zur Kommunikation aufgerufene
Aktivität aup als Uplink.
Abbildung 5.9 zeigt, wie sich die Aktivitätenpaare sowie die an der Kommuni-
kation beteiligte Schnittstelle auf die drei Teilnetze verteilen. Das Aktivitätenpaar
(a
1,dn, a1,up) repräsentiert die Aktivität Geschäftsprozess modellieren als eine der ver-
feinernden Aktivitäten des Domain Engineering. Die beiden Elemente a
1,dn und a1,up
sind auf die Teilnetze Domain Engineering und Kommunikationssystem verteilt. Ana-
log finden sich die Elemente des Aktivitätenpaares (a
2,dn, a2,up) in den Teilnetzen
Kommunikationssystem und Application Engineering wieder.
Die verwendeten Mechanismen zur Kommunikation der verschiedenen Netze unter-
einander werden in Renew mit Hilfe der Programmiersprache Java implementiert.
Diese Umsetzung wird nachfolgend für einige Situationen innerhalb der Beispielpro-
zesslandschaft zur komponentenbasierten Softwareentwicklung erläutert, wie sie zur
Validation der Analysemethode des Process Landscaping durchgeführt worden ist.
204
5.3 Modellierung und Simulation der unteren Ebenen einer Prozesslandschaft
15
Domain Engineering Application Engineering
15
a1, up a2, dna1, dn a2, up
Domain Engineering Application EngineeringKommunikationssystem
Geschäftsprozessmodell modellierena1
Geschäftsprozessmodell15
Anforderungsanalyse erstellena2
Abbildung 5.9: Kommunikationskanal innerhalb eines Kommunikationssystems
Ein Dokumenttyp kann in Java wie folgt als Attributmenge einer Klasse formuliert
werden:
public class Token{
private int complexity;
private NetInstance sender;
private NetInstance via;
private NetInstance receiver;
private double volume;
}
NetInstance repräsentiert dabei eine Basisklasse aller modellierten Teilbereiche
einer Prozesslandschaft.
Die Modellierung der Responderstelle im Netz einer sendenden Aktivität stellt ei-
ne netzübergreifende Besonderheit dar. Abbildung 5.10 zeigt die zugehörigen Aus-
schnitte der Petrinetze am Beispiel des Application Engineering am Standort Anwen-
dungsentwicklung, das mit dem Projektmanagement und dem zentralen Qualitätsma-
nagement kommuniziert. Die Kommunikationsbereitschaft wird potentiellen Initiato-
ren durch das Belegen der Responderstelle mit einer Marke angezeigt. Durch die Auf-
teilung der Prozesslandschaft auf verschiedene Petrinetze für verschiedene Standorte
sind Initiator und Responder jedoch auf unterschiedliche Netze aufgeteilt, obwohl bei-
de Stellen zum Vorbereich der sendenden Aktivität gehören. Daher wird der erfolglose
Kommunikationsversuch eines Initiators mit einem bereits beschäftigten Responder
205
Werkzeugunterstützung
jetzt dadurch verhindert, dass letzterer jedem potentiellen Initiator immer eine ent-
sprechende Zustandsänderung der Responderstelle mitteilt. So wird ein Kommunika-
tionsversuch mit einem beschäftigten Responder gar nicht erst initiiert.
während dieser Aktivität
nicht Verfügbar
nach dieser Aktivität
wieder verfügbar
PM:noResponder_AE();
QM:noResponder_AE();
PM:responderAE();
QM:responderAE();
:responder_AE()
:noResponder_AE()
senden an AE
initiator_PM
responder_AE
Ausschnitt aus AE
Ausschnitt 
aus PM
:responder_AE()
:noResponder_AE()
senden an AE
initiator_QM
responder_AE
Ausschnitt 
aus QM
Abbildung 5.10: Modellierung einer Responderstelle innerhalb eines Petrinetzes
Die links im Petrinetz Anwendungsentwicklung dargestellte Aktivität entfernt eine
Marke von der Responderstelle des Netzes. Sie stellt das Gegenstück zu den Akti-
vitäten aller mit dem Netz kommunizierenden Initiatoren dar. Beim Schalten dieser
Aktivitäten wird eine Marke auf den Stellen responder_AE in den zugehörigen Netzen
(rechts in Abbildung 5.10) entfernt. Sowohl Responder- als auch Initiatorstellen sind
über bidirektionale Kanten mit der sendenden Aktivität verbunden. Für die Initiator-
stellen initiator_PM und initiator_QM ist so eine permanente Kommunikationsbereit-
schaft gewährleistet. Für die Responderstelle, die außerhalb des Senders modelliert ist,
ist über diesen Mechanismus ebenfalls die Anzeige der Kommunikationsbereitschaft
anzeigbar.
Diese Form der Modellierung ist lediglich für das zentrale Qualitätsmanagement ver-
ändert worden. Dort sind die Responderstellen als permanent belegt modelliert, um
mögliche Verklemmungen des gesamten Simulationsmodells zu verhindern. Eine per-
manente Belegung ermöglich zwar, dass das Application Engineering ein weiteres
Anforderungsdokument erstellen kann, während ein zuvor erstelltes vom Qualitäts-
management geprüft wird. Das Review dieses weiteren Dokumentes kann so aber erst
vom Application Engineering angestoßen werden, wenn das Reviewergebnis des ers-
ten Dokuments zurückgeschickt worden ist und das Application Engineering somit
nicht mehr auf das erste Reviewergebnis wartet.
Parallele Modellierung durch ein Team von Modellierern ist im Gegensatz zu Piazza
Palermo bei Renew nicht vorgesehen. Auch eine getrennte Nutzung durch Modellie-
rer und Prozessbeteiligte ist nicht möglich. Beides ist allerdings auch von Anfang an
nicht Ziel des Werkzeugs gewesen. Einen Schwerpunkt des Werkzeugs bildet dagegen
die Möglichkeit der Simulation von Prozesslandschaften. Die Simulationsläufe wer-
206
5.3 Modellierung und Simulation der unteren Ebenen einer Prozesslandschaft
den von einer Simulationskomponente ausgeführt, die ebenfalls von Renew zur Ver-
fügung gestellt wird. Diese Simulationsläufe können sowohl animiert als auch nicht
animiert durchgeführt werden. Da für die Simulation einer Prozesslandschaft im Rah-
men des Process Landscaping Massendaten anfallen, sollte die Animation lediglich
für die Überprüfung der korrekten Modellierung der einzelnen Teilnetze eingesetzt
werden; auf eine Animation der eigentlichen Simulationsläufe sollte jedoch aus Per-
formanzgründen verzichtet werden.
Die Ergebnisse der verschiedenen Simulationsläufe werden persistent in einer Daten-
bank gespeichert, deren Schnittstelle zu Renew im Rahmen des Process Landscaping
realisiert wurde. Weitere zur Bewertung der Kommunikationseffizienz einer Prozess-
landschaft notwendigen Daten sind in einer XML-Datei gespeichert. Diese im Folgen-
den als Projektdatei bezeichnete Datei beinhaltet beispielsweise Informationen über
verwendete Kostenmodelle und Relationen zwischen den einzelnen Netzen.
Eine erste Auswertung der Simulationsergebnisse im Zusammenhang mit den in der
Projektdatei gespeicherten Daten wird von einer Auswertungskomponente durchge-
führt, die ebenfalls im Rahmen des Process Landscaping als Erweiterung von Renew
realisiert worden ist. Diese Auswertungskomponente stellt vor allem verschiedene Pro-
cess Landscaping-spezifische Analysealgorithmen zur Verfügung. Im Einzelnen sind
dies Algorithmen
 zur Berechnung von Prozessauslastungen,
 zur Bestimmung von Pfadlängen,
 zur Ermittlung von Initiator-/Responderraten und
 zur Aufbereitung der stochastischen Auswertung.
Das Ergebnis der verschiedenen Algorithmen wird in einem dreigeteilten Fenster dar-
gestellt, das in Abbildung 5.11 zu sehen ist. Im linken oberen Bereich ist die hierar-
chische Datenstruktur der Simulationsläufe abgebildet, die die Gliederung in Projekte,
Experimente und Netze zeigt. Wird ein Eintrag selektiert, werden im rechten oberen
Bereich weitere Details angezeigt. In Abbildung 5.11 bestehen diese Details aus den
Kommunikationskosten, durchschnittlichen Pfadlängen und Prozessauslastungen für
das Projektmanagement eines Softwareentwicklungsprojektes, welches als separates
Petrinetz, im Beispiel als Cluster PM bezeichnet, modelliert ist. Die dort berechneten
Werte basieren auf zwei Simulationsläufen. Ihre Darstellung erfolgt textuell, indem
zunächst die Anzahl der Stichproben, ein erwartungstreuer Mittelwert und ein erwar-
tungstreuer Schätzer der Varianz aufgeführt werden. Darunter ist die Verteilung der
Stichprobenwerte aufgelistet, indem in jeder Zeile ein halboffenes Intervall mit relati-
ver Häufigkeit ausgegeben wird. Im unteren Bereich des Fensters in Abbildung 5.11
werden während der Auswertung Logging-Informationen ausgegeben wie beispiels-
weise das erfolgreiche Öffnen der Datenbank oder das Einlesen der darin enthaltenen
Daten.
207
Werkzeugunterstützung
Abbildung 5.11: Oberfläche der Auswertungskomponente von Renew
208
5.4 Status der Werkzeugunterstützung
Neben der Berechnung und Darstellung der Auswertungsdaten bietet die Auswer-
tungskomponente weitergehende Funktionalitäten, die eine Arbeitserleichterung für
den Modellierer darstellen. Beispielsweise kann die Funktionsweise der Auswertungs-
komponente über Parameter beeinflusst werden, die sich auf datenbankbezogene Ein-
stellungen zur Datenbankadresse, Benutzername und Passwort beziehen. Diese Werte
überschreiben bzw. ergänzen Angaben in der Projektdatei. Auf diese Weise wird der
Austausch von Projektdateien ermöglicht. Weitere Einstellmöglichkeiten sind die An-
zahl standardmäßig durchzuführender Experimente (Mengen von Simulationsläufen,
vgl. Abbildung 4.3 in Abschnitt 4.2.2.1) und die Ein- bzw. Ausschaltung der animier-
ten Simulation.
5.4 Status der Werkzeugunterstützung
Mit der in den vorangegangenen Abschnitten vorgestellten Software existiert eine
Werkzeugunterstützung, die die Modellierungsschritte des Process Landscaping – bis
auf die Umstrukturierung von der logischen in die lokale Sicht – vollständig unter-
stützt. Für die Modellierung der oberen Ebenen einer Prozesslandschaft ist dabei zu-
sätzlich besonderer Wert auf das parallele Arbeiten in einem Modellierungsteam gelegt
worden, welches zudem noch geografisch verteilt arbeiten kann. Dass die Umstruk-
turierung einer gegebenen Prozesslandschaft werkzeuggestützt durchgeführt werden
kann, ist jedoch zumindest für die oberen Ebenen prototypisch in [Poh00] gezeigt wor-
den. Eine durchgängige Modellierung von den oberen zu den unteren Ebenen ist durch
die in Abschnitt 5.2 dargestellte Schnittstellenkomponente ebenfalls ermöglicht. Sie
erlaubt einen Werkzeugwechsel ohne Bruch in der Anwendung des Process Landsca-
ping.
Die werkzeuggestützte Analyse konzentriert sich für die oberen Ebenen auf Konsis-
tenzprüfungen einer erstellten Prozesslandschaft. Die Möglichkeit der Festlegung von
Attributwerten für eine Kommunikationsinfrastruktur ist ebenfalls gegeben. Die Aus-
wertung der Attributwerte erfolgt zurzeit noch prototypisch über deren Export in eine
Datenbank (MS-Access) und anschließende SQL-Abfragen.
Für die unteren Ebenen ist eine vollständige Werkzeugunterstützung vorhanden. Sie
ermöglicht nicht nur die Simulation und damit die Analyse dynamischen Verhaltens
einer Prozesslandschaft, sondern bietet gleichzeitig die Auswertung der gewonnenen
Simulationsergebnisse für die Process Landscaping-spezifischen Kommunikationsei-
genschaften an.
209

Kapitel 6
Zusammenfassung und Ausblick
6.1 Zusammenfassung der Arbeit
Die Methode des Process Landscaping unterstützt ein strukturiertes Vorgehen zur Er-
stellung und Analyse einer verteilten Prozesslandschaft. Sie berücksichtigt verschiede-
ne Aspekte zu Vorgehen, Rollen, Ergebnissen und unterstützenden Techniken, die in
der Literatur auch als Komponenten einer Methode bezeichnet werden [Hey95, HB96].
Für jeden Vorgehensschritt sind verantwortliche bzw. beteiligte Rollen sowie die Ziel-
gruppe der Ergebnisse benannt. Ergebnisse der Methode sind neben einer Prozess-
landschaft das Erreichen konkreter Analyseziele für verschiedene Abstraktionsebenen
und zugehörige Interpretationsrahmen. Das Ergebnis der Modellierungsschritte, die
Prozesslandschaft, ist unter Berücksichtigung sowohl allgemeiner Prinzipien wie den
Grundsätzen ordnungsmäßiger Modellierung als auch methodenspezifischer Grundsät-
ze wie beispielsweise der besonderen Schnittstellenbetrachtung entstanden. Aber auch
das Erreichen der Analyseziele – Bewertung und ggf. Verbesserung von Kommunikati-
onseigenschaften unter besonderer Berücksichtigung von Verteilungsaspekten – wird
durch methodenneutrale und -spezifische Grundsätze unterstützt. Schließlich stehen
für jeden Methodenschritt – soweit sinnvoll – Techniken zur Erreichung der verschie-
denen Ergebnisse zur Verfügung. Diese reichen von unterschiedlichen Arten der Wis-
sensakquise für die Modellierung einer Prozesslandschaft über die Umstrukturierung
in die lokale Sicht bis hin zu Vorgehensweisen für die Bewertung von quantitativen
Analyseergebnissen.
Das Process Landscaping unterstützt im Gegensatz zu vielen anderen Modellierungs-
und Analyseansätzen auch unstrukturierte Prozesse, für die kein fester Ablauf vorgege-
ben ist. Dazu wird sowohl die Möglichkeit der Modellierung ohne Ablaufinformatio-
nen gegeben, und dies für verschiedene Abstraktionsebenen, als auch die Möglichkeit
der Analyse ihrer statischen Kommunikationsinfrastruktur. Ein konsistenter Modellie-
rungsübergang zu Prozessen mit Ablaufinformationen wird durch eine entsprechen-
de konstruktive Erweiterung der zugrundeliegenden Petrinetze gewährleistet. Dieser
Übergang zeichnet die Modellierungsschritte des Process Landscaping zusammen mit
seinen Alleinstellungsmerkmalen – der expliziten Schnittstellenbetrachtung und der
Umstrukturierungsmöglichkeit von der logischen in die lokale Sicht einer Prozess-
211
Zusammenfassung und Ausblick
landschaft – aus. Für strukturierte Prozesse bietet die vorgestellte Methode die Mög-
lichkeit, über die Analyse des dynamischen Kommunikationsverhaltens unter beson-
derer Berücksichtigung von Verteilungsaspekten die Kommunikationseffizienz einer
Prozesslandschaft als ein Kriterium für Optimierungsansätze zu untersuchen.
Die formale Basis einer Prozesslandschaft bedient sich der Eigenschaften verschie-
dener Petrinetz-Varianten. Ausgehend von der Basisdefinition einer Prozesslandschaft
wird diese schrittweise um Abbildungen und Attribute erweitert, die zur Modellie-
rung und Analyse der verschiedenen Abstraktionsebenen erforderlich sind. Dabei sind
teilweise Definitionen aus der Literatur übernommen, teilweise sind die definierten
Begriffe – wie beispielsweise das Schaltverhalten – jedoch anders eingeführt. Für
die Analyse verschiedener Kommunikationseigenschaften existieren zusätzliche, land-
schaftsspezifische Attribute und Abbildungen.
Ein wichtiges Merkmal der formalen Grundlage des Process Landscaping ist die For-
mulierung der Basis einer Prozesslandschaft und aller vier Ausbaustufen als Kombina-
tion eines gerichteten Baumes zusammen mit einem je nach Ausbaustufe unterschied-
lich ausgeprägten Petrinetz. Während der Aktivitätenbaum die Gesamtübersicht über
die hierarchische Struktur einer modellierten Prozesslandschaft ermöglicht, unterstützt
das Petrinetz die Betrachtung vorhandener Aktivitäten und ihrer Zugriffe auf erzeug-
te bzw. genutzte Informationsobjekte auf unterschiedlichen Abstraktionsebenen. Die
vorgestellten Verfeinerungskonzepte sowohl für Aktivitäten als auch für Schnittstellen
unterscheiden sich von der traditionellen Vorgehensweise der in der Literatur vorge-
schlagenen Konzepte, da sie auch die Umgebung zu verfeinernder Knoten eines Petri-
netzes einbeziehen. Dies erfordert zwar die Einhaltung einer festen Reihenfolge bei der
Durchführung von Verfeinerungen, ermöglicht aber trotzdem ein sukzessives Hinzu-
fügen von Detailinformationen überall dort, wo es aus Sicht des Modellierers sinnvoll
erscheint.
Bei den oberen Ebenen einer Prozesslandschaft wird durch ihre Modellierung mit
PLL explizit von Ablaufinformationen abstrahiert, nicht aber von der Schnittstel-
lenbetrachtung zwischen Aktivitäten. Ein konsistenter Modellierungsübergang zu den
unteren Ebenen einer Prozesslandschaft wird durch die konstruktive Erstellung einer
kohärenten Prozesslandschaft ermöglicht. Dort wird eine explizite Schnittstellenbe-
trachtung insbesondere durch die Unterscheidung in interne und externe Schnittstellen
unterstützt. Sie ermöglicht vor allem in der lokalen Sicht eine fokussierte Betrachtung
der Kommunikation zwischen geografisch verteilt arbeitenden Aktivitäten.
Insgesamt unterstützt so die Notation einer Prozesslandschaft als Aktivitätenbaum zu-
sammen mit einem Petrinetz alle in Abschnitt 1.1 diskutierten Problemstellungen, in-
dem sie für die in Kapitel 2 präsentierten Lösungsmöglichkeiten eine geeignete forma-
le Basis anbietet. Sie ist insbesondere notwendige Voraussetzung für die Analyse des
Process Landscaping, die sich in die Analyse statischer und dynamischer Kommuni-
kationseigenschaften unterteilt: Die Analyse statischer Kommunikationseigenschaften
setzt den Fokus auf die Kommunikationsinfrastruktur einer Prozesslandschaft. Sie hat
die Minimierung eines Kommunikationskostenfaktors für diese Infrastruktur bezüg-
lich verschiedener Strategien zum Ziel. Die Analyse dynamischer Kommunikationsei-
212
6.2 Ausblick auf weiterführende Arbeiten
genschaften untersucht mit Hilfe der Simulation einer verteilten Prozesslandschaft de-
ren Kommunikationseffizienz mit dem Ziel ihrer Optimierung durch die Verbesserung
sowohl des Auslastungsgrades von Aktivitäten, deren geografischer Verteilung, der
Informationsverteilung als auch des Informationsflusses. Beide Analyseformen sind
bislang nicht in der Literatur diskutiert worden, bieten jedoch für fachlich sinnvoll
strukturierte Prozesse ein geeignetes Hilfsmittel für deren Effizienzsteigerung.
Die für die Methode vorhandene Werkzeugunterstützung erlaubt die Modellierung al-
ler Abstraktionsebenen mit und ohne Berücksichtigung von Ablaufinformationen. Für
die oberen Ebenen ist dazu ein Modellierungswerkzeug entwickelt worden; für die
unteren Ebenen ist eines von vielen bereits vorhandenen Petrinetz-Werkzeugen ausge-
wählt worden. Eine XML-Schnittstelle ermöglicht einen konsistenten Übergang von
den oberen zu den unteren Ebenen einer Prozesslandschaft. Diese durchgängige Mo-
dellierungsunterstützung verbessert die Einsatzmöglichkeit des Process Landscaping
insbesondere für komplexe Prozesslandschaften und trägt somit auch zur Steigerung
der Akzeptanz der Methode bei, wie dies allgemein bei werkzeuggestützten Methoden
der Fall ist [LSS99]. Bezogen auf die Analyseschritte des Process Landscaping wird
die Untersuchung der Kommunikationseffizienz erst durch eine geeignete Werkzeug-
unterstützung möglich. Dies ist mit der Erweiterung des Petrinetz-Werkzeugs Renew
durch die Anbindung an eine Datenbank zur konsistenten Speicherung der Simulati-
onsergebnisse und deren Verarbeitung durch eine Auswertungskomponente gegeben.
6.2 Ausblick auf weiterführende Arbeiten
Weiterführende Arbeiten im Rahmen des Process Landscaping konzentrieren sich auf
drei verschiedene Aspekte, konkret
 der Verbesserung und Erweiterung der Werkzeugunterstützung,
 der Erweiterung von Analysemöglichkeiten verteilter Prozesslandschaften und
 der Anwendung der Methode in weiteren Projekten.
Bezüglich der Werkzeugunterstützung ist unter anderem eine Optimierung von Tei-
len der Benutzeroberfläche und die Realisierung von Schnittstellen zwischen Piazza
Palermo und weiteren Petrinetz-basierten Softwarewerkzeugen insbesondere für den
Übergang zwischen den oberen und unteren Ebenen einer Prozesslandschaft sinn-
voll. Die bereits Ende des Abschnitts 5.1.1 angesprochene Realisierung zur verbesser-
ten werkzeuggestützten Analyse der Kommunikationsinfrastruktur einer Prozessland-
schaft ist ebenfalls ein zukünftiges Ziel. Vor allem erscheint jedoch eine Unterstützung
für die Umstrukturierung von der logischen in die lokale Sicht hilfreich. Die im Rah-
men dieser Arbeit noch manuell durchgeführte Umstrukturierung ist relativ zeitauf-
wändig. Weiterführende Ansätze bezüglich des Umstrukturierungskonzeptes werden
in [KW02] vorgestellt, bei denen eine rollenbasierte in die logische Sicht umstruktu-
riert wird. Diese Idee basiert auf dem gleichen Konzept wie die Umstrukturierung von
der logischen in die lokale Sicht.
213
Zusammenfassung und Ausblick
Die Analysemöglichkeiten des Process Landscaping sind bislang hauptsächlich im
Rahmen dieser Arbeit – am Beispiel der komponentenbasierten Softwareentwick-
lung – validiert worden. Empirische Untersuchungen in realen Projekten können die
hier diskutierte Nutzenbetrachtung weiter untermauern und die Hinzunahme der Kom-
munikation als Entscheidungskriterium bei Prozessoptimierungen zum Regelfall wer-
den lassen.
Verteilte Prozesslandschaften bieten eine Vielzahl von Analysemöglichkeiten weiterer
Aspekte, die bislang nicht oder nur unzureichend berücksichtigt worden sind. Bei-
spielsweise bietet es sich gerade für geografisch verteilte Prozesse an, deren Autono-
mie bezüglich der von ihnen benötigten und/oder erstellten Daten oder bezüglich der
Durchführung ihrer Aufgaben zu betrachten und im Gesamtzusammenhang aller ko-
operierenden Prozesse zu bewerten. Erste Ideen zur Autonomiebetrachtung in einer
verteilten Softwareprozesslandschaft werden in [GW02] diskutiert.
Process Landscaping ist bereits auf komplexe Prozesse in der Telekommunikations-
branche [GW00a] sowie auf Softwareprozesse zur komponentenbasierten Software-
entwicklung [GW00b] und auch zur Erstellung multimedialer Lehr- und Lernsysteme
[KW02] angewandt worden. Im Bereich der Telekommunikation diente die Model-
lierung der Darstellung und Schulung neu zu konzipierender Geschäftsprozesse mit
besonderem Schwerpunkt auf der Festlegung von Schnittstellen zwischen den Pro-
zessen und Aktivitäten, die oft über mehrere organisatorische Geschäftseinheiten hin-
weg verliefen. Letztere waren zusätzlich meist geografisch über den gesamten Glo-
bus verteilt. Die Modellierung verteilter Softwareprozesse zur komponentenbasierten
Softwareentwicklung in [GW00b] hatte die explizite Formulierung der einzelnen Mo-
dellierungsschritte des Process Landscaping und die Einordnung der Methode in den
wissenschaftlichen Hintergrund zum Ziel. Schließlich stand bei der Modellierung ei-
ner Prozesslandschaft zur Erstellung multimedialer Lehr- und Lernsysteme die Um-
strukturierung einer rollenbasierten Sicht in eine logische Sicht unter Anwendung des
Umstrukturierungskonzeptes der Methode im Vordergrund der Betrachtung.
Die Erfahrungen in allen drei beschriebenen Projekten haben nicht nur gezeigt, dass
Handlungsbedarf für die in Abschnitt 1.1 diskutierten Problemstellungen besteht, ins-
besondere für die explizite Berücksichtigung von Schnittstellen innerhalb von und zwi-
schen Prozessen, der Lösungsansatz des Process Landscaping hat sich dabei auch als
geeignet erwiesen. Die Anwendung des Process Landscaping in weiteren Projekten
kann belegen, dass die Methode nicht nur zur Modellierung und Analyse von Soft-
wareprozessen geeignet ist, sondern auch für andere Formen von Geschäftsprozessen.
Dies ist zwar im Bereich der Telekommunikation schon geschehen, sollte aber durch
Erfahrungswerte weiterer Projekte detailliert nachgewiesen werden.
Insgesamt bleibt festzuhalten, dass der Einsatz des Process Landscaping in weiteren
Prozessmodellierungs- und -analyseprojekten den im Rahmen dieser Arbeit erbrachten
Nachweis des Nutzens auch in der täglichen Praxis bestätigen kann und daher für
verschiedene prozessorientierte Projekte angestrebt wird.
214
Anhang A
Aufbau der
Beispielprozesslandschaft
Der Anhang enthält viele Detailinformationen der Prozesslandschaft, die die kompo-
nentenbasierte Softwareentwicklung darstellt. Diese dient als Beispiel sowohl zur Er-
läuterung der Methode des Process Landscaping als auch als Validationsgrundlage der
Analyse. Der Anhang ist unterteilt in Informationen über die Aktivitäten der Prozess-
landschaft ω und ihrer Verteilung auf die verschiedenen Standorte (Abschnitt A.1) und
in Detailinformationen zur statischen (Abschnitt A.2) und zur dynamischen Analyse
(Abschnitt A.3). Die beiden letztgenannten Unterkapitel zeigen neben den konkre-
ten Werten der instanziierten Prozesslandschaft zusätzlich Vorberechnungen, die die
Grundlage der in Kapitel 4 diskutierten Optimierungsansätze bilden.
A.1 Prozesslandschaft ω
Aktivität Sublevel Toplevel
Anforderungsanalyse erstellen Kundenlokation Zentrale
Abnahme mit dem Kunden Kundenlokation
Kommunikation mit dem Kunden Kundenlokation
Release erstellen Anwendungsentwicklung Zentrale
Releaseplanung Anwendungsentwicklung
Versionsmanagement Anwendungsentwicklung
Spezifikation erstellen Anwendungsentwicklung
System installieren Anwendungsentwicklung
System integrieren Anwendungsentwicklung
Systemarchitektur erstellen Anwendungsentwicklung
Zur Abnahme freigeben Anwendungsentwicklung
Komponente anfordern Anwendungsentwicklung
Komponente hinzufügen Anwendungsentwicklung
215
Aufbau der Beispielprozesslandschaft
Aktivität Sublevel Toplevel
Technische Komponentenanforderung erstellen Anwendungsentwicklung
Vorhandene Komponenten auswählen Anwendungsentwicklung
Komponente kaufen Anwendungsentwicklung
Feedback an DE geben Anwendungsentwicklung
Clientkomponente Grobentwurf Komponentenentwicklung-1 Zentrale
Datenbankentwurf und Datenmigration Komponentenentwicklung-1
Datenbankimplementierung Komponentenentwicklung-1
Feinentwurf Komponentenentwicklung-1
Implementierung Komponentenentwicklung-1
Klassenintegration Komponentenentwicklung-1
Serverkomponente Grobentwurf Komponentenentwicklung-1
Komponentenanpassung Komponentenentwicklung-1
Release erstellen (CE) Komponentenentwicklung-1
Releaseplanung (CE) Komponentenentwicklung-1
Versionsmanagement(CE) Komponentenentwicklung-1
Fehlerkorrektur Komponentenentwicklung-1
Richtlinien anfragen Komponentenentwicklung-1
Entscheidung neu oder anpassen Managementlokation Zentrale
Geschäftsprozess modellieren Managementlokation
Wiederverwendungsrepository verwalten Managementlokation
Projekt einschätzen Managementlokation
Buy or Build-Entscheidung treffen Managementlokation
CE mit Komponentenentwicklung beauftragen Managementlokation
Markt analysieren Managementlokation
Projekt initialisieren Managementlokation
Projektabschluss Managementlokation
Projektdarstellung nach außen Managementlokation
Projektplanerstellung Managementlokation
Projektsteuerung und -kontrolle Managementlokation
Ressourcenplanung Managementlokation
Risikomanagement Managementlokation
Teamzusammenstellung Managementlokation
Testablaufverfolgung Managementlokation
Richtlinienerweiterung weiterleiten Managementlokation
Richtlinienerstellung Qualitätsmanagement-Z Zentrale
Testplanerstellung Qualitätsmanagement-Z
Reviewauswertung Qualitätsmanagement-Z
Testauswertung Qualitätsmanagement-Z
Reviewdurchführung Qualitätsmanagement-Z
Testdurchführung Qualitätsmanagement-Z
Testvorbereitung Qualitätsmanagement-Z
216
A.1 Prozesslandschaft ω
Aktivität Sublevel Toplevel
Clientkomponente Grobentwurf Komponentenentwicklung-2 Außenstelle-1
Datenbankentwurf und Datenmigration Komponentenentwicklung-2
Datenbankimplementierung Komponentenentwicklung-2
Feinentwurf Komponentenentwicklung-2
Implementierung Komponentenentwicklung-2
Klassenintegration Komponentenentwicklung-2
Serverkomponente Grobentwurf Komponentenentwicklung-2
Komponentenanpassung Komponentenentwicklung-2
Release erstellen (CE) Komponentenentwicklung-2
Releaseplanung (CE) Komponentenentwicklung-2
Versionsmanagement (CE) Komponentenentwicklung-2
Fehlerkorrektur Komponentenentwicklung-2
Richtlinien anfragen Komponentenentwicklung-2
Testauswertung Qualitätsmanagement-A Außenstelle-1
Testplanerstellung Qualitätsmanagement-A
Testablaufverfolgung Qualitätsmanagement-A
Reviewauswertung Qualitätsmanagement-A
Richtlinienerweiterung vorschlagen Qualitätsmanagement-A
Reviewdurchführung Qualitätsmanagement-A
Testdurchführung Qualitätsmanagement-A
Testvorbereitung Qualitätsmanagement-A
Clientkomponente Grobentwurf Komponentenentwicklung-3 Außenstelle-2
Datenbankentwurf und Datenmigration Komponentenentwicklung-3
Datenbankimplementierung Komponentenentwicklung-3
Feinentwurf Komponentenentwicklung-3
Implementierung Komponentenentwicklung-3
Klassenintegration Komponentenentwicklung-3
Serverkomponente Grobentwurf Komponentenentwicklung-3
Komponentenanpassung Komponentenentwicklung-3
Release erstellen (CE) Komponentenentwicklung-3
Releaseplanung (CE) Komponentenentwicklung-3
Versionsmanagement (CE) Komponentenentwicklung-3
Fehlerkorrektur Komponentenentwicklung-3
Richtlinien anfragen Komponentenentwicklung-3
Clientkomponente Grobentwurf Komponentenentwicklung-4 Außenstelle-3
Datenbankentwurf und Datenmigration Komponentenentwicklung-4
Datenbankimplementierung Komponentenentwicklung-4
Feinentwurf Komponentenentwicklung-4
Implementierung Komponentenentwicklung-4
Klassenintegration Komponentenentwicklung-4
Serverkomponente Grobentwurf Komponentenentwicklung-4
217
Aufbau der Beispielprozesslandschaft
Aktivität Sublevel Toplevel
Komponentenanpassung Komponentenentwicklung-4
Release erstelle (CE) Komponentenentwicklung-4
Releaseplanung (CE) Komponentenentwicklung-4
Versionsmanagement (CE) Komponentenentwicklung-4
Fehlerkorrektur Komponentenentwicklung-4
Richtlinien anfragen Komponentenentwicklung-4
Clientkomponente Grobentwurf Komponentenentwicklung-5 Außenstelle-4
Datenbankentwurf und Datenmigration Komponentenentwicklung-5
Datenimplementierung Komponentenentwicklung-5
Feinentwurf Komponentenentwicklung-5
Implementierung Komponentenentwicklung-5
Klassenintegration Komponentenentwicklung-5
Serverkomponente Grobentwurf Komponentenentwicklung-5
Komponentenanpassung Komponentenentwicklung-5
Release erstellen (CE) Komponentenentwicklung-5
Releaseplanung (CE) Komponentenentwicklung-5
Versionsmanagement (CE) Komponentenentwicklung-5
Fehlerkorrektur Komponentenentwicklung-5
Richtlinien anfragen Komponentenentwicklung-5
Tabelle A.1: Aktivitäten der Prozesslandschaft ω und ihre lokale Verteilung
A.2 Detailinformationen zur statischen Analyse
In diesem Abschnitt sind alle zur Berechnung der in Abschnitt 2.3.2 diskutierten Kom-
munikationskostenfaktoren Kkf notwendigen Kommunikationskanäle in Tabellenform
dargestellt. Im Einzelnen ist dies eine Liste aller existierenden Kommunikationskanäle
zusammen mit ihren Attributen, Nutzungshäufigkeiten und Kosten (Tabellen A.2 bis
A.18).
In den Tabellen gehören jeweils drei Zeilen zur Beschreibung eines Kommunikati-
onskanals. In der ersten Spalte bezeichnet die erste Zeile dabei jeweils die sendende
Aktivität, die zweite Zeile bezeichnet das zu versendende Dokument, und die dritte
Zeile bezeichnet die das Dokument empfangende Aktivität. Die Aktivitätsnamen sind
aus Platzgründen teilweise abgekürzt. Die Kosten pro Nutzung eines Kommunikati-
onskanals (vorletzte Spalte) setzen sich aus der Summe der vergebenen Kostenpunkte
(vgl. Abschnitt 4.1.2, Seite 157) zusammen. In der letzten mit NH bezeichneten Spalte
ist die grob geschätzte Nutzungshäufigkeit des jeweiligen Kommunikationskanals pro
Entwicklungsprojekt auf einer Skala von 1 bis 10 angegeben.
218
A.2 Detailinformationen zur statischen Analyse
Kommunikationskanal per synch coded change priv mult Kosten NH
Zur Abnahme freigeben
Abnahmefreigabe 1 1 0 0 0 1 3 2
Abnahme m. d. Kunden
Anf.-Analyse erstellen
Anforderungsdokument 1 0 0 0 0 1 3 1
Spezifikation erstellen
Anf.-Analyse erstellen
Anforderungsdokument 1 0 1 0 1 0 4 1
Vorh. Komp. auswählen
Anf.-Analyse erstellen
Anforderungsdokument 1 0 0 0 1 0 4 1
Versionsmanagement (AE)
Anf.-Analyse erstellen
Anforderungsdokument 1 0 0 0 1 0 3 1
Releaseplanung (AE)
Tabelle A.2: Kommunikationskanäle zwischen Kundenlokation und
Anwendungsentwicklung
Kommunikationskanal per synch coded change priv mult Kosten NH
Anf.-Analyse erstellen
Anforderungsdokument 1 0 0 1 1 1 3 5
Reviewdurchführung
Reviewdurchführung
Review Anforderungsdok. 1 0 1 0 1 0 4 5
Anf.-Analyse erstellen
Tabelle A.3: Kommunikationskanäle zwischen Kundenlokation und
Qualitätsmanagement-Z
219
Aufbau der Beispielprozesslandschaft
Kommunikationskanal per synch coded change priv mult Kosten NH
Abnahme m. d. Kunden
Abnahmebericht 1 0 1 0 1 0 4 2
Projektabschluss
Kommunik. m. d. Kunden
Erste Anforderungen 0 0 0 1 0 1 2 3
Projektplanerstellung
Kommunik. m. d. Kunden
Erste Anforderungen 0 1 0 1 0 1 2 3
Teamzusammenstellung
Kommunik. m. d. Kunden
Erste Anforderungen 0 1 0 1 0 1 2 3
Ressourcenplanung
Anf.-Analyse erstellen
Anfrage GP-Modell 0 1 0 0 0 0 2 1
G.-Prozess modellieren
G.-Prozess modellieren
Geschäftsprozessmodell 1 0 1 0 0 0 3 1
Anf.-Analyse erstellen
Tabelle A.4: Kommunikationskanäle zwischen Kundenlokation und
Managementlokation
Kommunikationskanal per synch coded change priv mult Kosten NH
Richtlinienerstellung
Richtlinien 1 0 0 0 1 0 3 2
Richtl.erweit. vorschl.
Tabelle A.5: Kommunikationskanäle zwischen Qualitätsmanagement-A
und Qualitätsmanagement-Z
220
A.2 Detailinformationen zur statischen Analyse
Kommunikationskanal per synch coded change priv mult Kosten NH
Releaseplanung (AE)
Releaseplanung 1 0 1 0 0 0 3 2
Projektplanerstellung
Buy/Build-Ent. treffen
Buy/Build-Entscheidung 1 1 0 1 0 1 2 5
Komponente kaufen
Projekt einschätzen
Projekteinschätzung 1 1 0 1 1 0 2 2
Releaseplanung (AE)
Komponente anfordern
Komponentenanforderung 1 0 1 0 0 1 4 2
Markt analysieren
Komponente anfordern
Komponentenanforderung 1 1 0 0 0 0 2 5
Entsch. neu/anpassen
Feedback an DE geben
Feedback an DE 0 0 1 1 0 0 2 4
Wiederverw.-repos. verw.
Feedback an DE geben
Feedback an DE 0 0 1 1 0 0 2 4
Wiederverw.-repos. verw.
Spezifikation erstellen
Anfrage an Repository 0 1 0 1 0 1 2 1
Wiederverw.-repos. verw.
Wiederverw.-repos. verw.
Feedback v. Repository 1 0 1 0 0 0 3 2
Spezifikation erstellen
Systemarchit. erstellen
Anfrage an Repository 0 1 0 1 0 1 2 1
Wiederverw.-repos. verw.
221
Aufbau der Beispielprozesslandschaft
Kommunikationskanal per synch coded change priv mult Kosten NH
Wiederverw.-repos. verw.
Feedback v. Repository 1 0 1 0 0 0 3 2
Systemarchit. erstellen
vorh. Komp. auswählen
Anfrage an Repository 0 1 0 1 0 1 2 1
Wiederverw.-repos. verw.
Spezifikation erstellen
Spezifikationsdokument 1 0 1 0 0 0 3 1
Wiederverw.-repos. verw.
Systemarchit. erstellen
Systemarchitektur 1 0 1 0 0 0 3 1
Wiederverw.-repos. verw.
Tabelle A.6: Kommunikationskanäle zwischen Anwendungsentwicklung
und Managementlokation
Kommunikationskanal per synch coded change priv mult Kosten NH
Testdurchführung
Fehlerprot. install. SW-Syst. 1 0 1 0 0 1 4 3
System installieren
Testdurchführung
Fehlerprot. integr. SW-Syst. 1 0 1 0 0 1 4 3
System integrieren
Reviewdurchführung
Review Releaseplanung 1 0 1 0 0 1 4 4
Releaseplanung (AE)
techn. Komp.-anf. erstellen
techn. Komp.-anforderung 1 0 1 0 1 0 4 2
Reviewdurchführung
System installieren
installiertes Softwaresystem 1 0 0 0 0 0 2 2
Testvorbereitung
222
A.2 Detailinformationen zur statischen Analyse
Kommunikationskanal per synch coded change priv mult Kosten NH
System integrieren
integriertes Softwaresyst. 0 0 0 0 0 0 2 2
Testvorbereitung
Releaseplanung
Releaseplanung 1 0 0 0 0 1 3 2
Reviewdurchführung
Reviewdurchführung
Review Spezifikationsdok. 0 0 0 0 1 1 4 3
Spezifikation erstellen
Reviewdurchführung
Review Systemarchitektur 0 0 0 0 1 1 4 3
Systemarchitektur erstellen
Reviewdurchführung
Review techn. Komp.-anf. 0 0 0 0 1 1 4 4
Komponentenanf. erstellen
Spezifikation erstellen
Spezifikationsdokument 1 0 0 0 1 1 4 2
Reviewdurchführung
Systemarchit. erstellen
Systemarchitektur 1 0 0 0 1 1 4 2
Reviewdurchführung
Tabelle A.7: Kommunikationskanäle zwischen Anwendungsentwicklung
und Qualitätsmanagement-Z
Kommunikationskanal per synch coded change priv mult Kosten NH
Fehlerkorrektur
getestete Komponente 1 0 1 0 0 0 3 1
Komponente hinzufügen
Tabelle A.8: Kommunikationskanäle zwischen Anwendungsentwicklung
und Komponentenentwicklung-1 bis -5
223
Aufbau der Beispielprozesslandschaft
Kommunikationskanal per synch coded change priv mult Kosten NH
Testdurchführung
Fehlerprot. neue Komp. 1 0 0 0 0 1 3 4
Fehlerkorrektur
Release erstellen (CE)
Neue Komponente 1 0 1 0 0 1 4 2
Testvorbereitung
Richtlinien anfragen
Anfrage n. Richtlinien 0 1 0 1 1 1 3 1
Richtlinienerstellung
Richtlinienerstellung
Richtlinien 1 0 0 0 0 0 2 1
Richtlinien anfragen
Tabelle A.9: Kommunikationskanäle zwischen Komponentenentwicklung-1,
-3, -4, -5 und Qualitätsmanagement-Z
Kommunikationskanal per synch coded change priv mult Kosten NH
Testdurchführung
Fehlerprot. neue Komp. 1 0 0 0 0 1 3 4
Fehlerkorrektur
Release erstellen (CE)
Neue Komponente 1 0 1 0 0 1 4 2
Testvorbereitung
Richtlinien anfragen
Anfrage n. Richtlinien 0 1 0 1 1 1 3 1
Richtlinienerstellung
Richtlinienerstellung
Richtlinien 1 0 0 0 0 0 2 1
Richtlinien anfragen
Tabelle A.10: Kommunikationskanäle zwischen Komponentenentwicklung-2
und Qualitätsmanagement-A
224
A.2 Detailinformationen zur statischen Analyse
Kommunikationskanal per synch coded change priv mult Kosten NH
Entsch. neu/anpassen
Auftrag Komp.-anpass. 1 0 1 0 1 0 4 1
Komponentenanpassung
Entsch. neu/anpassen
Auftrag Komp.-anpass. 1 0 1 0 1 0 4 1
Releaseplanung (CE)
Entsch. neu/anpassen
Auftrag Komp.-entw. 1 0 1 0 1 0 4 3
Clientkomp. Grobentw.
Entsch. neu/anpassen
Auftrag Komp.-entw. 1 0 1 0 1 0 4 1
Serverkomp. Grobentw.
Entsch. neu/anpassen
Auftrag Komp.-entw. 1 0 1 0 1 0 4 1
Releaseplanung (CE)
Versionsmanagement
versionierte Komponente 1 0 1 0 0 0 3 1
Wiederverw.-repos. verw.
Tabelle A.11: Kommunikationskanäle zwischen Komponentenentwicklung-1,
-2, -3, -4, -5 und Managementlokation
Kommunikationskanal per synch coded change priv mult Kosten NH
Richtl.-erweit. vorschl.
Vorschlag Richtlinienerw. 0 0 0 1 0 0 1 2
R.-vorschlag weiterleiten
Tabelle A.12: Kommunikationskanäle zwischen Qualitätsmanagement-A
und Managementlokation
225
Aufbau der Beispielprozesslandschaft
Kommunikationskanal per synch coded change priv mult Kosten NH
Risikomanagement
Analysen und Berichte 1 0 1 0 1 0 4 5
Projektst. und -kontrolle
Projektplanerstellung
Anfrage an DE 0 1 0 1 0 1 2 1
Projekt einschätzen
G.-Prozess modellieren
Anfrage an Repository 0 1 0 1 0 1 2 1
Wiederverw.-rep. verw.
Wiederverw.-rep. verw.
Feedback v. Repository 0 0 1 0 1 1 5 2
G.-Prozess modellieren
Projekt einschätzen
Anfrage an Repository 0 1 0 1 0 1 2 1
Wiederverw.-rep. verw.
Wiederverw.rep. verw.
Feedback v. Repository 0 0 1 0 1 0 4 2
Projekt einschätzen
Ressourcenplanung
Ausstattung 1 0 0 0 0 1 3 1
Projekt initialisieren
Buy/Build-Entsch. treffen
Buy/Build-Entscheidung 1 1 0 0 0 0 2 5
CE m. Entw. beauftr.
CE m. Entw. beauftr.
Entwicklungsbeauftragung 1 0 1 0 1 0 4 5
Entsch. neu/anpassen
G.-Prozess modellieren
Geschäftsprozessmodell 1 0 1 0 0 0 3 1
Wiederverw.-rep. verw.
226
A.2 Detailinformationen zur statischen Analyse
Kommunikationskanal per synch coded change priv mult Kosten NH
Markt analysieren
Marktanalyse 1 0 0 0 1 1 4 1
Buy/Build-Entsch. treffen
Projekt einschätzen
Projekteinschätzung 1 0 0 1 1 0 2 2
Projektplanerstellung
Projekt einschätzen
Projekteinschätzung 1 0 0 0 1 0 3 2
Risikomanagement
Projekt einschätzen
Projekteinschätzung 1 1 0 0 1 1 4 2
Markt analysieren
Projekt initialisieren
Projektinitialisierung 0 1 0 0 0 1 3 1
Projektst. u. -kontrolle
Projektst. u. -kontrolle
Projektplan 1 1 0 0 0 0 2 2
Projekt initialisieren
Projektplanerstellung
Projektplan 1 0 0 0 0 1 3 2
Projektst. u. -kontrolle
Projektst. u. -kontrolle
Projektstatus 1 0 0 1 0 0 1 5
Projektdarst. n. aussen
Teamzusammenstellung
Projektteam 1 0 0 0 1 1 4 1
Projekt initialisieren
Tabelle A.13: Kommunikationskanäle am Standort Managementlokation
227
Aufbau der Beispielprozesslandschaft
Kommunikationskanal per synch coded change priv mult Kosten NH
Kommunik. m. d. Kunden
Erste Anforderungen 0 1 0 1 0 1 2 3
Anf.-analyse erstellen
Tabelle A.14: Kommunikationskanäle am Standort Kundenlokation
Kommunikationskanal per synch coded change priv mult Kosten NH
Reviewauswertung
Reviewauswertung 1 0 1 0 1 0 4 10
Richtlinienerstellung
Richtlinienerstellung
Richtlinien 1 0 0 0 0 0 2 1
Testauswertung
Richtlinienerstellung
Richtlinien 1 0 0 0 0 0 2 1
Reviewauswertung
Testauswertung
Testauswertung 1 0 1 0 1 0 4 6
Richtlinienerstellung
Testplanerstellung
Testplan 1 0 0 0 1 0 3 1
Testablaufverfolgung
Testplanerstellung
Testplan 1 0 0 0 1 0 3 1
Reviewauswertung
Testplanerstellung
Testplan 1 0 0 0 1 0 3 1
Testauswertung
Reviewdurchführung
Rev. Anforderungsdok. 1 0 1 0 0 0 3 5
Reviewauswertung
228
A.2 Detailinformationen zur statischen Analyse
Kommunikationskanal per synch coded change priv mult Kosten NH
Reviewdurchführung
Rev. Spezifikationsdok. 1 0 1 0 0 0 3 3
Reviewauswertung
Reviewdurchführung
Review Systemarchitektur 1 0 1 0 0 0 3 3
Reviewauswertung
Reviewdurchführung
Review Releaseplanung 1 0 1 0 0 0 3 2
Reviewauswertung
Reviewdurchführung
Rev. techn. Komp.-anf. 1 0 1 0 0 0 3 4
Reviewauswertung
Testdurchführung
Fehlerprot. neue Komp. 1 0 1 0 0 0 3 4
Testauswertung
Testdurchführung
Fehlerprot. install. SW-Syst. 1 0 1 0 0 0 3 3
Testauswertung
Testdurchführung
Fehlerprot. integr. SW-Syst. 1 0 1 0 0 0 3 3
Testauswertung
Richtlinienerstellung
Richtlinien 1 0 0 0 1 1 4 1
Reviewdurchführung
Richtlinienerstellung
Richtlinien 1 0 0 0 1 1 4 1
Testdurchführung
Richtlinienerstellung
Richtlinien 1 0 0 0 1 1 4 1
Testvorbereitung
229
Aufbau der Beispielprozesslandschaft
Kommunikationskanal per synch coded change priv mult Kosten NH
Reviewdurchführung
Status Review 1 1 0 1 0 1 2 3
Testablaufverfolgung
Reviewdurchführung
Status Test 1 1 0 1 0 1 2 3
Testablaufverfolgung
Testvorbereitung
Testbeschreibung 1 0 0 0 1 1 4 1
Testdurchführung
Testplanerstellung
Testplan 1 0 1 0 0 1 4 1
Testvorbereitung
Testvorbereitung
Testbeschreibung 1 0 0 0 0 1 3 1
Testauswertung
Tabelle A.15: Kommunikationskanäle am Standort Qualitätsmanagement-Z
Kommunikationskanal per synch coded change priv mult Kosten NH
Komp.-anpassung
Komp.-implementation 1 0 0 0 1 0 3 1
Release erstellen
Klassenintegration
Komp.-implementation 1 0 0 0 1 0 3 1
Release erstellen
Serverkomp. Grobentw.
Komp.-integrationsplan 1 0 0 0 1 1 4 2
Feinentwurf
Serverkomp. Grobentw.
Komp.-integrationsplan 1 0 0 0 1 1 4 2
DB-Entw. u. D.-migration
230
A.2 Detailinformationen zur statischen Analyse
Kommunikationskanal per synch coded change priv mult Kosten NH
Clientkomp. Grobentw.
Komp.-integrationsplan 1 0 0 0 1 1 4 2
Feinentwurf
Clientkomp. Grobentw.
Komp.-integrationsplan 1 0 0 0 1 1 4 2
DB-Entw. u. D.-migrat.
Releaseplanung (CE)
Komp.-releaseplanung 1 0 0 0 1 1 4 2
Release erstellen
Implementierung
Quellcode 1 0 1 1 1 1 4 1
Klassenintegration
Serverkomp. Grobentw.
Schnittstellenbeschreibung 1 0 1 0 1 1 5 2
Feinentwurf
Clientkomp. Grobentw.
Schnittstellenbeschreibung 1 0 1 0 1 1 5 2
Feinentwurf
Clientkomp. Grobentw.
SW-Archit. Clientkomp. 1 0 0 1 1 1 3 2
Feinentwurf
Serverkomp. Grobentw.
SW-Archit. Serverkomp. 1 0 0 1 1 1 3 2
Feinentwurf
Serverkomp. Grobentwurf
SW-Archit. Serverkomp. 1 0 0 1 1 1 3 2
DB-Entw. u. D.-migration
Feinentwurf
SW-Entw. Clientkomp. 1 0 0 0 1 1 4 2
Implementierung
231
Aufbau der Beispielprozesslandschaft
Kommunikationskanal per synch coded change priv mult Kosten NH
Feinentwurf
SW-Entw. Serverkomp. 1 0 0 0 1 1 4 2
Implementierung
DB-Entw. u. D.-migration
SW-Entw. u. D.-migration 1 0 0 0 1 1 4 2
DB-Implementierung
Fehlerkorrektur
getestete Komponente 1 0 0 0 1 1 4 3
Versionsmanagement (CE)
Release erstellen
neue Komponente 1 0 0 0 1 1 4 3
Fehlerkorrektur
Tabelle A.16: Kommunikationskanäle an den Standorten Komponenten-
entwicklung-1 bis -5
Kommunikationskanal per synch coded change priv mult Kosten NH
Komponente kaufen
gekaufte Komponente 0 0 0 0 1 0 3 3
Komponente hinzufügen
System installieren
install. SW-System 1 1 0 0 0 0 2 1
Zur Abnahme freigeben
System installieren
install. SW-System 1 0 0 0 1 0 3 1
Release erstellen
System integrieren
integr. SW-System 0 1 0 1 1 1 3 1
System installieren
System integrieren
integr. SW-System 0 0 0 0 1 0 3 1
Feedback an DE geben
232
A.2 Detailinformationen zur statischen Analyse
Kommunikationskanal per synch coded change priv mult Kosten NH
System integrieren
integr. SW-System 0 0 0 0 1 0 3 1
Versionsmanagement (AE)
Release erstellen (AE)
Konfiguration 1 1 0 0 1 0 3 1
Versionsmanagement (AE)
Releaseplanung (AE)
Releaseplanung 1 0 0 0 0 1 3 2
Release erstellen
techn. Komp.-anf. erst.
techn. Komp.-anford. 1 0 0 0 1 0 3 1
Komponente anfordern
Spezifikation erstellen
Spezifikationsdokument 1 0 0 0 1 1 4 1
Systemarchit. erstellen
Spezifikation erstellen
Spezifikationsdokument 1 0 0 0 1 0 3 1
Feedback an DE geben
Spezifikation erstellen
Spezifikationsdokument 1 0 0 0 1 0 3 1
Releaseplanung (AE)
Spezifikation erstellen
Spezifikationsdokument 1 0 0 0 1 0 3 1
Versionsmanagement (AE)
Systemarchit. erstellen
Systemarchitektur 1 0 0 0 1 1 4 1
techn. Komp.-anf. erst.
Systemarchit. erstellen
Systemarchitektur 1 0 0 0 1 0 3 1
Komponenten auswählen
233
Aufbau der Beispielprozesslandschaft
Kommunikationskanal per synch coded change priv mult Kosten NH
Systemarchit. erstellen
Systemarchitektur 1 0 0 0 1 0 3 1
Versionsmanagement (AE)
Systemarchit. erstellen
Systemarchitektur 1 0 0 0 1 0 3 1
Feedback an DE geben
Komponente hinzufügen
projektbez. Komp.-menge 1 0 0 0 1 0 3 1
Feedback an DE geben
Komponente hinzufügen
projektbez. Komp.-menge 1 0 0 0 1 1 4 2
vorh. Komp. auswählen
Komponente hinzufügen
projektbez. Komp.-menge 1 0 0 0 1 1 4 1
System integrieren
Tabelle A.17: Kommunikationskanäle am Standort Anwendungsentwicklung
Kommunikationskanal per synch coded change priv mult Kosten NH
Reviewauswertung
Reviewauswertung 1 0 1 0 1 0 4 4
Richtl.-erweit. vorschl.
Testauswertung
Testauswertung 1 0 1 0 1 0 4 4
Richtl.-erweit. vorschl.
Testplanerstellung
Testplan 1 0 0 0 1 0 3 1
Testablaufverfolgung
Testplanerstellung
Testplan 1 0 0 0 1 0 3 1
Reviewauswertung
234
A.2 Detailinformationen zur statischen Analyse
Kommunikationskanal per synch coded change priv mult Kosten NH
Testplanerstellung
Testplan 1 0 0 0 1 0 3 1
Testauswertung
Reviewdurchführung
Rev. Komp.releaseplan. 1 0 0 0 1 0 3 2
Reviewauswertung
Testdurchführung
Fehlerprot. neue Komp. 1 0 1 0 0 0 3 3
Testauswertung
Reviewdurchführung
Status Review 1 1 0 1 0 1 2 3
Testablaufverfolgung
Reviewdurchführung
Status Test 1 1 0 1 0 1 2 3
Testablaufverfolgung
Testvorbereitung
Testbeschreibung 1 0 0 0 1 1 4 1
Testdurchführung
Testplanerstellung
Testplan 1 0 1 0 0 1 4 1
Testvorbereitung
Testvorbereitung
Testbeschreibung 1 0 0 0 0 1 3 1
Testauswertung
Richtl.-erweit. vorschl.
Richtlinien 1 0 0 0 0 0 2 1
Testauswertung
Richtl.-erweit. vorschl.
Richtlinien 1 0 0 0 0 0 2 1
Reviewauswertung
235
Aufbau der Beispielprozesslandschaft
Kommunikationskanal per synch coded change priv mult Kosten NH
Richtl.-erweit. vorschl.
Richtlinien 1 0 0 0 1 1 4 1
Reviewdurchführung
Richtl.-erweit. vorschl.
Richtlinien 1 0 0 0 1 1 4 1
Testdurchführung
Richtl.-erweit. vorschl.
Richtlinien 1 0 0 0 1 1 4 1
Testvorbereitung
Tabelle A.18: Kommunikationskanäle am Standort Qualitätsmanagement-A
Die Tabellen A.19 bis A.70 zeigen verschiedene Detailberechnungen, die zur Messung
der Kkf verschiedener Optimierungsansätze erforderlich sind.
Aufbau eines neuen Standortes: (Tabellen A.19 bis A.30)
Ort 1 Ort 2 Kopplungs- Kopplungs-
dichte komplexität
Kundenlokation Anwendungsentwicklung 5 4
Kundenlokation Managementlokation 4 3
Kundenlokation Qualitätsmanagement-Z 2 2
Anwendungsentwicklung Managementlokation 4 4
Anwendungsentwicklung Qualitätsmanagement-Z 12 5
Anwendungsentwicklung Komponentenentwicklung-1 1 1
Anwendungsentwicklung Komponentenentwicklung-2 1 1
Anwendungsentwicklung Komponentenentwicklung-3 1 1
Anwendungsentwicklung Komponentenentwicklung-4 1 1
Anwendungsentwicklung Komponentenentwicklung-5 1 1
Managementlokation Komponentenentwicklung-1 5 1
Managementlokation Komponentenentwicklung-2 5 1
Managementlokation Komponentenentwicklung-3 5 1
Managementlokation Komponentenentwicklung-4 5 1
Managementlokation Komponentenentwicklung-5 5 1
Managementlokation Qualitätsmanagement-Z 4 3
Managementlokation Qualitätsmanagement-A 1 1
neuer Standort Kundenlokation 2 2
neuer Standort Anwendungsentwicklung 9 5
236
A.2 Detailinformationen zur statischen Analyse
Ort 1 Ort 2 Kopplungs- Kopplungs-
dichte komplexität
neuer Standort Managementlokation 4 4
neuer Standort Komponentenentwicklung-1 1 1
neuer Standort Komponentenentwicklung-2 1 1
neuer Standort Komponentenentwicklung-3 1 1
neuer Standort Komponentenentwicklung-4 1 1
neuer Standort Komponentenentwicklung-5 1 1
Komponentenentwicklung-1 Qualitätsmanagement-Z 4 4
Komponentenentwicklung-2 Qualitätsmanagement-A 4 4
Komponentenentwicklung-3 Qualitätsmanagement-Z 4 4
Komponentenentwicklung-4 Qualitätsmanagement-Z 4 4
Komponentenentwicklung-5 Qualitätsmanagement-Z 4 4
Qualitätsmanagement-A Qualitätsmanagement-Z 1 1
Tabelle A.19: Kopplung zwischen zwei Orten – Alternative1
Ort Kopplungsdichte Kopplungskomplexität
Kundenlokation 13 9
Anwendungsentwicklung 35 13
Managementlokation 42 9
neuer Standort 20 5
Komponentenentwicklung-1 11 6
Komponentenentwicklung-2 11 6
Komponentenentwicklung-3 11 6
Komponentenentwicklung-4 11 6
Komponentenentwicklung-5 11 6
Qualitätsmanagement-Z 35 8
Qualitätsmanagement-A 6 6
Tabelle A.20: Kopplung eines Ortes – Alternative1
Ort Kohäsionsdichte Kohäsionskomplexität
Kundenlokation 1 1
Anwendungsentwicklung 20 6
Managementlokation 10 7
neuer Standort 5 4
Komponentenentwicklung-1 18 5
Komponentenentwicklung-2 18 5
Komponentenentwicklung-3 18 5
237
Aufbau der Beispielprozesslandschaft
Ort Kohäsionsdichte Kohäsionskomplexität
Komponentenentwicklung-4 18 5
Komponentenentwicklung-5 18 5
Qualitätsmanagement-Z 23 8
Qualitätsmanagement-A 17 7
Tabelle A.21: Kohäsion eines Ortes – Alternative1
Ort Kkf
Kundenlokation 186,33
Anwendungsentwicklung 8,87
Managementlokation 7,72
neuer Standort 23,55
Komponentenentwicklung-1 0,26
Komponentenentwicklung-2 0,26
Komponentenentwicklung-3 0,26
Komponentenentwicklung-4 0,26
Komponentenentwicklung-5 0,26
Qualitätsmanagement-Z 2,28
Qualitätsmanagement-A 0,15
Tabelle A.22: Kommunikationskostenfaktoren aller Orte – Alternative1
Ort 1 Ort 2 Kopplungs- Kopplungs-
dichte komplexität
Kundenlokation Anwendungsentwicklung 3 3
Kundenlokation Managementlokation 6 5
Kundenlokation Qualitätsmanagement-Z 2 2
Anwendungsentwicklung Managementlokation 11 6
Anwendungsentwicklung Qualitätsmanagement-Z 10 4
Anwendungsentwicklung Komponentenentwicklung-1 1 1
Anwendungsentwicklung Komponentenentwicklung-2 1 1
Anwendungsentwicklung Komponentenentwicklung-3 1 1
Anwendungsentwicklung Komponentenentwicklung-4 1 1
Anwendungsentwicklung Komponentenentwicklung-5 1 1
Managementlokation Komponentenentwicklung-1 6 2
Managementlokation Komponentenentwicklung-2 6 2
Managementlokation Komponentenentwicklung-3 6 2
Managementlokation Komponentenentwicklung-4 6 2
Managementlokation Komponentenentwicklung-5 6 2
238
A.2 Detailinformationen zur statischen Analyse
Ort 1 Ort 2 Kopplungs- Kopplungs-
dichte komplexität
Managementlokation Qualitätsmanagement-Z 4 3
Managementlokation Qualitätsmanagement-A 1 1
neuer Standort Kundenlokation 2 1
neuer Standort Anwendungsentwicklung 5 1
neuer Standort Managementlokation 2 1
neuer Standort Qualitätsmanagement-Z 2 1
Komponentenentwicklung-1 Qualitätsmanagement-Z 4 4
Komponentenentwicklung-2 Qualitätsmanagement-A 4 4
Komponentenentwicklung-3 Qualitätsmanagement-Z 4 4
Komponentenentwicklung-4 Qualitätsmanagement-Z 4 4
Komponentenentwicklung-5 Qualitätsmanagement-Z 4 4
Qualitätsmanagement-A Qualitätsmanagement-Z 1 1
Tabelle A.23: Kopplung zwischen zwei Orten – Alternative2
Ort Kopplungsdichte Kopplungskomplexität
Kundenlokation 13 9
Anwendungsentwicklung 34 11
Managementlokation 54 9
neuer Standort 11 5
Komponentenentwicklung-1 11 6
Komponentenentwicklung-2 11 6
Komponentenentwicklung-3 11 6
Komponentenentwicklung-4 11 6
Komponentenentwicklung-5 11 6
Qualitätsmanagement-Z 35 8
Qualitätsmanagement-A 6 6
Tabelle A.24: Kopplung eines Ortes– Alternative2
Ort Kohäsionsdichte Kohäsionskomplexität
Kundenlokation 1 1
Anwendungsentwicklung 18 4
Managementlokation 19 12
neuer Standort 2 2
Komponentenentwicklung-1 18 5
Komponentenentwicklung-2 18 5
Komponentenentwicklung-3 18 5
239
Aufbau der Beispielprozesslandschaft
Ort Kohäsionsdichte Kohäsionskomplexität
Komponentenentwicklung-4 18 5
Komponentenentwicklung-5 18 5
Qualitätsmanagement-Z 23 8
Qualitätsmanagement-A 17 7
Tabelle A.25: Kohäsion eines Ortes – Alternative2
Ort Kkf
Kundenlokation 186,33
Anwendungsentwicklung 10,94
Managementlokation 6,14
neuer Standort 18,7
Komponentenentwicklung-1 0,26
Komponentenentwicklung-2 0,26
Komponentenentwicklung-3 0,26
Komponentenentwicklung-4 0,26
Komponentenentwicklung-5 0,26
Qualitätsmanagement-Z 2,28
Qualitätsmanagement-A 0,15
Tabelle A.26: Kommunikationskostenfaktoren aller Orte – Alternative2
Ort 1 Ort 2 Kopplungs- Kopplungs-
dichte komplexität
Kundenlokation Anwendungsentwicklung 5 4
Kundenlokation Managementlokation 6 5
Anwendungsentwicklung Managementlokation 13 7
Anwendungsentwicklung Komponentenentwicklung-1 1 1
Anwendungsentwicklung Komponentenentwicklung-2 1 1
Anwendungsentwicklung Komponentenentwicklung-3 1 1
Anwendungsentwicklung Komponentenentwicklung-4 1 1
Anwendungsentwicklung Komponentenentwicklung-5 1 1
Managementlokation Komponentenentwicklung-1 6 2
Managementlokation Komponentenentwicklung-2 6 2
Managementlokation Komponentenentwicklung-3 6 2
Managementlokation Komponentenentwicklung-4 6 2
Managementlokation Komponentenentwicklung-5 6 2
Managementlokation Qualitätsmanagement-Z 4 3
Managementlokation Qualitätsmanagement-A 1 1
240
A.2 Detailinformationen zur statischen Analyse
Ort 1 Ort 2 Kopplungs- Kopplungs-
dichte komplexität
neuer Standort Kundenlokation 2 2
neuer Standort Anwendungsentwicklung 12 5
neuer Standort Qualitätsmanagement-Z 12 6
neuer Standort Komponentenentwicklung-1 2 2
Komponentenentwicklung-1 Qualitätsmanagement-Z 2 2
Komponentenentwicklung-2 Qualitätsmanagement-A 4 4
Komponentenentwicklung-3 Qualitätsmanagement-Z 2 2
Komponentenentwicklung-4 Qualitätsmanagement-Z 2 2
Komponentenentwicklung-5 Qualitätsmanagement-Z 2 2
Komponentenentwicklung-2 neuer Standort 2 2
Komponentenentwicklung-3 neuer Standort 2 2
Komponentenentwicklung-4 neuer Standort 2 2
Komponentenentwicklung-5 neuer Standort 2 2
Qualitätsmanagement-A Qualitätsmanagement-Z 1 1
Tabelle A.27: Kopplung zwischen zwei Orten – Alternative3
Ort Kopplungsdichte Kopplungskomplexität
Kundenlokation 13 9
Anwendungsentwicklung 35 13
Managementlokation 54 9
neuer Standort 36 9
Komponentenentwicklung-1 11 6
Komponentenentwicklung-2 11 6
Komponentenentwicklung-3 11 6
Komponentenentwicklung-4 11 6
Komponentenentwicklung-5 11 6
Qualitätsmanagement-Z 25 8
Qualitätsmanagement-A 6 6
Tabelle A.28: Kopplung eines Ortes – Alternative3
241
Aufbau der Beispielprozesslandschaft
Ort Kohäsionsdichte Kohäsionskomplexität
Kundenlokation 1 1
Anwendungsentwicklung 20 6
Managementlokation 19 12
neuer Standort 10 3
Komponentenentwicklung-1 18 5
Komponentenentwicklung-2 18 5
Komponentenentwicklung-3 18 5
Komponentenentwicklung-4 18 5
Komponentenentwicklung-5 18 5
Qualitätsmanagement-Z 1 1
Qualitätsmanagement-A 17 7
Tabelle A.29: Kohäsion eines Ortes – Alternative3
Ort Kkf
Kundenlokation 186,33
Anwendungsentwicklung 8,87
Managementlokation 6,14
neuer Standort 1209,6
Komponentenentwicklung-1 0,26
Komponentenentwicklung-2 0,26
Komponentenentwicklung-3 0,26
Komponentenentwicklung-4 0,26
Komponentenentwicklung-5 0,26
Qualitätsmanagement-Z 1241,66
Qualitätsmanagement-A 0,15
Tabelle A.30: Kommunikationskostenfaktoren aller Orte – Alternative3
Zusammenlegen mehrerer Orte: (Tabellen A.31 bis A.54)
Kopplungs- Kopplungs-
Ort 1 Ort 2 dichte komplexität
Anwendungsentwicklung
Kundenlokation inkl. Management 11 8
Kundenlokation Qualitätsmanagement-Z 2 2
Anwendungsentwicklung
inkl. Management Qualitätsmanagement-Z 16 6
242
A.2 Detailinformationen zur statischen Analyse
Kopplungs- Kopplungs-
Ort 1 Ort 2 dichte komplexität
Anwendungsentwicklung
inkl. Management Komponentenentwicklung-1 7 2
Anwendungsentwicklung
inkl. Management Komponentenentwicklung-2 7 2
Anwendungsentwicklung
inkl. Management Komponentenentwicklung-3 7 2
Anwendungsentwicklung
inkl. Management Komponentenentwicklung-4 7 2
Anwendungsentwicklung
inkl. Management Komponentenentwicklung-5 7 2
Anwendungsentwicklung
inkl. Management Qualitätsmanagement-A 1 1
Komponentenentwicklung-1 Qualitätsmanagement-Z 4 4
Komponentenentwicklung-2 Qualitätsmanagement-A 4 4
Komponentenentwicklung-3 Qualitätsmanagement-Z 4 4
Komponentenentwicklung-4 Qualitätsmanagement-Z 4 4
Komponentenentwicklung-5 Qualitätsmanagement-Z 4 4
Qualitätsmanagement-A Qualitätsmanagement-Z 1 1
Tabelle A.31: Kopplung zwischen zwei Orten – Fusionsalternative1
Ort Kopplungsdichte Kopplungskomplexität
Kundenlokation 13 9
Anwendungsentwicklung
inkl. Management 62 12
Komponentenentwicklung-1 11 6
Komponentenentwicklung-2 11 6
Komponentenentwicklung-3 11 6
Komponentenentwicklung-4 11 6
Komponentenentwicklung-5 11 6
Qualitätsmanagement-Z 35 8
Qualitätsmanagement-A 6 6
Tabelle A.32: Kopplung eines Ortes – Fusionsalternative1
243
Aufbau der Beispielprozesslandschaft
Ort Kohäsionsdichte Kohäsionskomplexität
Kundenlokation 1 1
Anwendungsentwicklung
inkl. Management 52 16
Komponentenentwicklung-1 18 5
Komponentenentwicklung-2 18 5
Komponentenentwicklung-3 18 5
Komponentenentwicklung-4 18 5
Komponentenentwicklung-5 18 5
Qualitätsmanagement-Z 23 8
Qualitätsmanagement-A 17 7
Tabelle A.33: Kohäsion eines Ortes – Fusionsalternative1
Ort Kkf
Kundenlokation 186,33
Anwendungsentwicklung inkl. Management 1,65
Komponentenentwicklung-1 0,26
Komponentenentwicklung-2 0,26
Komponentenentwicklung-3 0,26
Komponentenentwicklung-4 0,26
Komponentenentwicklung-5 0,26
Qualitätsmanagement-Z 2,28
Qualitätsmanagement-A 0,15
Tabelle A.34: Kommunikationskostenfaktoren aller Orte –
Fusionsalternative1
Ort 1 Ort 2 Kopplungs- Kopplungs-
dichte komplexität
Anwendungsentwicklung inkl.
Kundenlokation Komponentenentwicklung-1 5 4
Kundenlokation Managementlokation 6 5
Kundenlokation Qualitätsmanagement-Z 2 2
Anwendungsentwicklung inkl.
Komponentenentwicklung-1 Managementlokation 19 8
Anwendungsentwicklung inkl.
Komponentenentwicklung-1 Qualitätsmanagement-Z 16 6
244
A.2 Detailinformationen zur statischen Analyse
Ort 1 Ort 2 Kopplungs- Kopplungs-
dichte komplexität
Anwendungsentwicklung inkl.
Komponentenentwicklung-1 Komponentenentwicklung-2 1 1
Anwendungsentwicklung inkl.
Komponentenentwicklung-1 Komponentenentwicklung-3 1 1
Anwendungsentwicklung inkl.
Komponentenentwicklung-1 Komponentenentwicklung-4 1 1
Anwendungsentwicklung inkl.
Komponentenentwicklung-1 Komponentenentwicklung-5 1 1
Managementlokation Komponentenentwicklung-2 6 2
Managementlokation Komponentenentwicklung-3 6 2
Managementlokation Komponentenentwicklung-4 6 2
Managementlokation Komponentenentwicklung-5 6 2
Managementlokation Qualitätsmanagement-Z 4 3
Managementlokation Qualitätsmanagement-A 1 1
Komponentenentwicklung-2 Qualitätsmanagement-A 4 4
Komponentenentwicklung-3 Qualitätsmanagement-Z 4 4
Komponentenentwicklung-4 Qualitätsmanagement-Z 4 4
Komponentenentwicklung-5 Qualitätsmanagement-Z 4 4
Qualitätsmanagement-A Qualitätsmanagement-Z 1 1
Tabelle A.35: Kopplung zwischen zwei Orten – Fusionsalternative2
Ort Kopplungsdichte Kopplungskomplexität
Kundenlokation 13 9
Anwendungsentwicklung inkl.
Komponentenentwicklung-1 46 13
Managementlokation 54 9
Komponentenentwicklung-2 11 6
Komponentenentwicklung-3 11 6
Komponentenentwicklung-4 11 6
Komponentenentwicklung-5 11 6
Qualitätsmanagement-Z 35 8
Qualitätsmanagement-A 6 6
Tabelle A.36: Kopplung eines Ortes – Fusionsalternative2
245
Aufbau der Beispielprozesslandschaft
Ort Kohäsionsdichte Kohäsionskomplexität
Kundenlokation 1 1
Anwendungsentwicklung inkl.
Komponentenentwicklung-1 38 10
Managementlokation 19 12
Komponentenentwicklung-2 18 5
Komponentenentwicklung-3 18 5
Komponentenentwicklung-4 18 5
Komponentenentwicklung-5 18 5
Qualitätsmanagement-Z 23 8
Qualitätsmanagement-A 17 7
Tabelle A.37: Kohäsion eines Ortes – Fusionsalternative2
Ort Kkf
Kundenlokation 186,33
Anwendungsentwicklung inkl. Komponentenentwicklung-1 1,51
Managementlokation 6,14
Komponentenentwicklung-2 0,26
Komponentenentwicklung-3 0,26
Komponentenentwicklung-4 0,26
Komponentenentwicklung-5 0,26
Qualitätsmanagement-Z 2,28
Qualitätsmanagement-A 0,15
Tabelle A.38: Kommunikationskostenfaktoren aller Orte –
Fusionsalternative2
Ort 1 Ort 2 Kopplungs- Kopplungs-
dichte komplexität
Anwendungsentwicklung inkl.
Kundenlokation Qualitätsmanagement-Z 7 5
Kundenlokation Managementlokation 6 5
Anwendungsentwicklung inkl.
Qualitätsmanagement-Z Managementlokation 17 10
Anwendungsentwicklung inkl.
Qualitätsmanagement-Z Komponentenentwicklung-1 5 5
246
A.2 Detailinformationen zur statischen Analyse
Ort 1 Ort 2 Kopplungs- Kopplungs-
dichte komplexität
Anwendungsentwicklung inkl.
Qualitätsmanagement-Z Komponentenentwicklung-2 1 1
Anwendungsentwicklung inkl.
Qualitätsmanagement-Z Komponentenentwicklung-3 5 5
Anwendungsentwicklung inkl.
Qualitätsmanagement-Z Komponentenentwicklung-4 5 5
Anwendungsentwicklung inkl.
Qualitätsmanagement-Z Komponentenentwicklung-5 5 5
Managementlokation Komponentenentwicklung-1 6 2
Managementlokation Komponentenentwicklung-2 6 2
Managementlokation Komponentenentwicklung-3 6 2
Managementlokation Komponentenentwicklung-4 6 2
Managementlokation Komponentenentwicklung-5 6 2
Managementlokation Qualitätsmanagement-A 1 1
Anwendungsentwicklung inkl.
Qualitätsmanagement-A Qualitätsmanagement-Z 1 1
Tabelle A.39: Kopplung zwischen zwei Orten – Fusionsalternative3
Ort Kopplungsdichte Kopplungskomplexität
Kundenlokation 13 9
Anwendungsentwicklung inkl.
Qualitätsmanagement-Z 46 13
Managementlokation 54 9
Komponentenentwicklung-1 11 6
Komponentenentwicklung-2 11 6
Komponentenentwicklung-3 11 6
Komponentenentwicklung-4 11 6
Komponentenentwicklung-5 11 6
Qualitätsmanagement-A 6 6
Tabelle A.40: Kopplung eines Ortes – Fusionsalternative3
Ort Kohäsionsdichte Kohäsionskomplexität
Kundenlokation 1 1
Anwendungsentwicklung inkl.
Qualitätsmanagement-Z 55 11
Managementlokation 19 12
247
Aufbau der Beispielprozesslandschaft
Ort Kohäsionsdichte Kohäsionskomplexität
Komponentenentwicklung-1 18 5
Komponentenentwicklung-2 18 5
Komponentenentwicklung-3 18 5
Komponentenentwicklung-4 18 5
Komponentenentwicklung-5 18 5
Qualitätsmanagement-A 17 7
Tabelle A.41: Kohäsion eines Ortes – Fusionsalternative3
Ort Kkf
Kundenlokation 186,33
Anwendungsentwicklung inkl. Qualitätsmanagement-Z 0,57
Managementlokation 6,14
Komponentenentwicklung-1 0,26
Komponentenentwicklung-2 0,26
Komponentenentwicklung-3 0,26
Komponentenentwicklung-4 0,26
Komponentenentwicklung-5 0,26
Qualitätsmanagement-A 0,15
Tabelle A.42: Kommunikationskostenfaktoren aller Orte –
Fusionsalternative3
Ort 1 Ort 2 Kopplungs- Kopplungs-
dichte komplexität
Kundenlokation Anwendungsentwicklung 5 4
Managementlokation inkl.
Kundenlokation Komponentenentwicklung-1 6 5
Kundenlokation Qualitätsmanagement-Z 2 2
Anwendungsentwicklung Managementlokation inkl.
Komponentenentwicklung-1 14 7
Anwendungsentwicklung Qualitätsmanagement-Z 12 5
Anwendungsentwicklung Komponentenentwicklung-2 1 1
Anwendungsentwicklung Komponentenentwicklung-3 1 1
Anwendungsentwicklung Komponentenentwicklung-4 1 1
Anwendungsentwicklung Komponentenentwicklung-5 1 1
Managementlokation inkl.
Komponentenentwicklung-1 Komponentenentwicklung-2 6 2
248
A.2 Detailinformationen zur statischen Analyse
Ort 1 Ort 2 Kopplungs- Kopplungs-
Managementlokation inkl.
Komponentenentwicklung-1 Komponentenentwicklung-3 6 2
Managementlokation inkl.
Komponentenentwicklung-1 Komponentenentwicklung-4 6 2
Managementlokation inkl.
Komponentenentwicklung-1 Komponentenentwicklung-5 6 2
Managementlokation inkl.
Komponentenentwicklung-1 Qualitätsmanagement-Z 8 5
Managementlokation inkl.
Komponentenentwicklung-1 Qualitätsmanagement-A 1 1
Komponentenentwicklung-1 Qualitätsmanagement-Z 4 4
Komponentenentwicklung-2 Qualitätsmanagement-A 4 4
Komponentenentwicklung-3 Qualitätsmanagement-Z 4 4
Komponentenentwicklung-4 Qualitätsmanagement-Z 4 4
Komponentenentwicklung-5 Qualitätsmanagement-Z 4 4
Qualitätsmanagement-A Qualitätsmanagement-Z 1 1
Tabelle A.43: Kopplung zwischen zwei Orten – Fusionsalternative4
Ort Kopplungsdichte Kopplungskomplexität
Kundenlokation 13 9
Anwendungsentwicklung 35 13
Managementlokation inkl.
Komponentenentwicklung-1 53 13
Komponentenentwicklung-2 11 6
Komponentenentwicklung-3 11 6
Komponentenentwicklung-4 11 6
Komponentenentwicklung-5 11 6
Qualitätsmanagement-Z 35 8
Qualitätsmanagement-A 6 6
Tabelle A.44: Kopplung eines Ortes – Fusionsalternative4
Ort Kohäsionsdichte Kohäsionskomplexität
Kundenlokation 1 1
Anwendungsentwicklung 20 6
Managementlokation inkl.
Komponentenentwicklung-1 43 14
Komponentenentwicklung-2 18 5
249
Aufbau der Beispielprozesslandschaft
Ort Kohäsionsdichte Kohäsionskomplexität
Komponentenentwicklung-3 18 5
Komponentenentwicklung-4 18 5
Komponentenentwicklung-5 18 5
Qualitätsmanagement-Z 23 8
Qualitätsmanagement-A 17 7
Tabelle A.45: Kohäsion eines Ortes – Fusionsalternative4
Ort Kkf
Kundenlokation 186,33
Anwendungsentwicklung 8,87
Managementlokation inkl. Komponentenentwicklung-1 1,12
Komponentenentwicklung-2 0,26
Komponentenentwicklung-3 0,26
Komponentenentwicklung-4 0,26
Komponentenentwicklung-5 0,26
Qualitätsmanagement-Z 2,28
Qualitätsmanagement-A 0,15
Tabelle A.46: Kommunikationskostenfaktoren aller Orte –
Fusionsalternative4
Ort 1 Ort 2 Kopplungs- Kopplungs-
dichte komplexität
Kundenlokation Anwendungsentwicklung 5 4
Managementlokation inkl.
Kundenlokation Qualitätsmanagement-Z 8 7
Managementlokation inkl.
Anwendungsentwicklung Qualitätsmanagement-Z 25 11
Anwendungsentwicklung Komponentenentwicklung-1 1 1
Anwendungsentwicklung Komponentenentwicklung-2 1 1
Anwendungsentwicklung Komponentenentwicklung-3 1 1
Anwendungsentwicklung Komponentenentwicklung-4 1 1
Anwendungsentwicklung Komponentenentwicklung-5 1 1
Managementlokation inkl.
Qualitätsmanagement-Z Komponentenentwicklung-1 10 6
Managementlokation inkl.
Qualitätsmanagement-Z Komponentenentwicklung-2 6 2
250
A.2 Detailinformationen zur statischen Analyse
Ort 1 Ort 2 Kopplungs- Kopplungs-
Managementlokation inkl.
Qualitätsmanagement-Z Komponentenentwicklung-3 10 6
Managementlokation inkl.
Qualitätsmanagement-Z Komponentenentwicklung-4 10 6
Managementlokation inkl.
Qualitätsmanagement-Z Komponentenentwicklung-5 10 6
Managementlokation inkl.
Qualitätsmanagement-Z Qualitätsmanagement-A 1 1
Komponentenentwicklung-2 Qualitätsmanagement-A 4 4
Tabelle A.47: Kopplung zwischen zwei Orten – Fusionsalternative5
Ort Kopplungsdichte Kopplungskomplexität
Kundenlokation 13 9
Anwendungsentwicklung 35 13
Managementlokation inkl.
Qualitätsmanagement-Z 74 15
Komponentenentwicklung-1 11 6
Komponentenentwicklung-2 11 6
Komponentenentwicklung-3 11 6
Komponentenentwicklung-4 11 6
Komponentenentwicklung-5 11 6
Qualitätsmanagement-A 6 6
Tabelle A.48: Kopplung eines Ortes – Fusionsalternative5
Ort Kohäsionsdichte Kohäsionskomplexität
Kundenlokation 1 1
Anwendungsentwicklung 20 6
Managementlokation inkl.
Qualitätsmanagement-Z 46 15
Komponentenentwicklung-1 18 5
Komponentenentwicklung-2 18 5
Komponentenentwicklung-3 18 5
Komponentenentwicklung-4 18 5
Komponentenentwicklung-5 18 5
Qualitätsmanagement-A 17 7
Tabelle A.49: Kohäsion eines Ortes – Fusionsalternative5
251
Aufbau der Beispielprozesslandschaft
Ort Kkf
Kundenlokation 186,33
Anwendungsentwicklung 8,87
Managementlokation inkl. Qualitätsmanagement-Z 3,61
Komponentenentwicklung-1 0,26
Komponentenentwicklung-2 0,26
Komponentenentwicklung-3 0,26
Komponentenentwicklung-4 0,26
Komponentenentwicklung-5 0,26
Qualitätsmanagement-A 0,15
Tabelle A.50: Kommunikationskostenfaktoren aller Orte –
Fusionsalternative5
Ort 1 Ort 2 Kopplungs- Kopplungs-
dichte komplexität
Kundenlokation Anwendungsentwicklung 5 4
Kundenlokation Managementlokation 6 5
Qualitätsmanagement-Z inkl.
Kundenlokation Komponentenentwicklung-1 2 2
Anwendungsentwicklung Managementlokation 13 7
Qualitätsmanagement-Z inkl.
Anwendungsentwicklung Komponentenentwicklung-1 13 6
Anwendungsentwicklung Komponentenentwicklung-2 1 1
Anwendungsentwicklung Komponentenentwicklung-3 1 1
Anwendungsentwicklung Komponentenentwicklung-4 1 1
Anwendungsentwicklung Komponentenentwicklung-5 1 1
Managementlokation Komponentenentwicklung-2 6 2
Managementlokation Komponentenentwicklung-3 6 2
Managementlokation Komponentenentwicklung-4 6 2
Managementlokation Komponentenentwicklung-5 6 2
Qualitätsmanagement-Z inkl.
Managementlokation Komponentenentwicklung-1 10 5
Managementlokation Qualitätsmanagement-A 1 1
Komponentenentwicklung-2 Qualitätsmanagement-A 4 4
Qualitätsmanagement-Z inkl.
Komponentenentwicklung-3 Komponentenentwicklung-1 4 4
Qualitätsmanagement-Z inkl.
Komponentenentwicklung-4 Komponentenentwicklung-1 4 4
252
A.2 Detailinformationen zur statischen Analyse
Ort 1 Ort 2 Kopplungs- Kopplungs-
Qualitätsmanagement-Z inkl.
Komponentenentwicklung-5 Komponentenentwicklung-1 4 4
Qualitätsmanagement-Z inkl.
Qualitätsmanagement-A Komponentenentwicklung-1 1 1
Tabelle A.51: Kopplung zwischen zwei Orten – Fusionsalternative6
Ort Kopplungsdichte Kopplungskomplexität
Kundenlokation 13 9
Anwendungsentwicklung 35 13
Managementlokation 54 9
Komponentenentwicklung-2 11 6
Komponentenentwicklung-3 11 6
Komponentenentwicklung-4 11 6
Komponentenentwicklung-5 11 6
Qualitätsmanagement-Z inkl.
Komponentenentwicklung-1 38 9
Qualitätsmanagement-A 6 6
Tabelle A.52: Kopplung eines Ortes – Fusionsalternative6
Ort Kohäsionsdichte Kohäsionskomplexität
Kundenlokation 1 1
Anwendungsentwicklung 20 6
Managementlokation 19 12
Komponentenentwicklung-2 18 5
Komponentenentwicklung-3 18 5
Komponentenentwicklung-4 18 5
Komponentenentwicklung-5 18 5
Qualitätsmanagement-Z inkl.
Komponentenentwicklung-1 45 12
Qualitätsmanagement-A 17 7
Tabelle A.53: Kohäsion eines Ortes – Fusionsalternative6
253
Aufbau der Beispielprozesslandschaft
Ort Kkf
Kundenlokation 186,33
Anwendungsentwicklung 8,87
Managementlokation 6,14
Komponentenentwicklung-2 0,26
Komponentenentwicklung-3 0,26
Komponentenentwicklung-4 0,26
Komponentenentwicklung-5 0,26
Qualitätsmanagement-Z inkl. Komponentenentwicklung-1 0,77
Qualitätsmanagement-A 0,15
Tabelle A.54: Kommunikationskostenfaktoren aller Orte –
Fusionsalternative6
Verlagerung einer Aktivität: (Tabellen A.55 bis A.70)
Die in den nachfolgenden Tabellen mit einem Sternchen versehenen Standorte bein-
halten die verlagerte Aktivität Anforderungsanalyse.
Ort 1 Ort 2 Kopplungs- Kopplungs-
dichte komplexität
verkleinerte
Kundenlokation Anwendungsentwicklung* 2 2
verkleinerte
Kundenlokation Managementlokation 4 3
Anwendungsentwicklung* Managementlokation 15 7
Anwendungsentwicklung* Qualitätsmanagement-Z 14 6
Anwendungsentwicklung* Komponentenentwicklung-1 1 1
Anwendungsentwicklung* Komponentenentwicklung-2 1 1
Anwendungsentwicklung* Komponentenentwicklung-3 1 1
Anwendungsentwicklung* Komponentenentwicklung-4 1 1
Anwendungsentwicklung* Komponentenentwicklung-5 1 1
Managementlokation Komponentenentwicklung-1 6 2
Managementlokation Komponentenentwicklung-2 6 2
Managementlokation Komponentenentwicklung-3 6 2
Managementlokation Komponentenentwicklung-4 6 2
Managementlokation Komponentenentwicklung-5 6 2
Managementlokation Qualitätsmanagement-Z 4 3
Managementlokation Qualitätsmanagement-A 1 1
Komponentenentwicklung-1 Qualitätsmanagement-Z 4 4
Komponentenentwicklung-2 Qualitätsmanagement-A 4 4
Komponentenentwicklung-3 Qualitätsmanagement-Z 4 4
254
A.2 Detailinformationen zur statischen Analyse
Ort 1 Ort 2 Kopplungs- Kopplungs-
dichte komplexität
Komponentenentwicklung-4 Qualitätsmanagement-Z 4 4
Komponentenentwicklung-5 Qualitätsmanagement-Z 4 4
Qualitätsmanagement-A Qualitätsmanagement-Z 1 1
Tabelle A.55: Kopplung zwischen zwei Orten – Verlagerungsalternative1
Ort Kopplungsdichte Kopplungskomplexität
verkleinerte
Kundenlokation 6 4
Anwendungsentwicklung* 36 12
Managementlokation 54 9
Komponentenentwicklung-1 11 6
Komponentenentwicklung-2 11 6
Komponentenentwicklung-3 11 6
Komponentenentwicklung-4 11 6
Komponentenentwicklung-5 11 6
Qualitätsmanagement-Z 35 8
Qualitätsmanagement-A 6 6
Tabelle A.56: Kopplung eines Ortes – Verlagerungsalternative1
Ort Kohäsionsdichte Kohäsionskomplexität
verkleinerte
Kundenlokation 0 0
Anwendungsentwicklung* 24 7
Managementlokation 19 12
Komponentenentwicklung-1 18 5
Komponentenentwicklung-2 18 5
Komponentenentwicklung-3 18 5
Komponentenentwicklung-4 18 5
Komponentenentwicklung-5 18 5
Qualitätsmanagement-Z 23 8
Qualitätsmanagement-A 17 7
Tabelle A.57: Kohäsion eines Ortes – Verlagerungsalternative1
255
Aufbau der Beispielprozesslandschaft
Ort Kkf
verkleinerte Kundenlokation 32
Anwendungsentwicklung* 4,05
Managementlokation 6,14
Komponentenentwicklung-1 0,26
Komponentenentwicklung-2 0,26
Komponentenentwicklung-3 0,26
Komponentenentwicklung-4 0,26
Komponentenentwicklung-5 0,26
Qualitätsmanagement-Z 2,28
Qualitätsmanagement-A 0,15
Tabelle A.58: Kommunikationskostenfaktoren aller Orte –
Verlagerungsalternative1
Ort 1 Ort 2 Kopplungs- Kopplungs-
dichte komplexität
verkleinerte
Kundenlokation Anwendungsentwicklung 1 1
verkleinerte
Kundenlokation Managementlokation* 5 3
Anwendungsentwicklung Managementlokation* 17 10
Anwendungsentwicklung Qualitätsmanagement-Z 12 5
Anwendungsentwicklung Komponentenentwicklung-1 1 1
Anwendungsentwicklung Komponentenentwicklung-2 1 1
Anwendungsentwicklung Komponentenentwicklung-3 1 1
Anwendungsentwicklung Komponentenentwicklung-4 1 1
Anwendungsentwicklung Komponentenentwicklung-5 1 1
Managementlokation* Komponentenentwicklung-1 6 2
Managementlokation* Komponentenentwicklung-2 6 2
Managementlokation* Komponentenentwicklung-3 6 2
Managementlokation* Komponentenentwicklung-4 6 2
Managementlokation* Komponentenentwicklung-5 6 2
Managementlokation* Qualitätsmanagement-Z 6 4
Managementlokation* Qualitätsmanagement-A 1 1
Komponentenentwicklung-1 Qualitätsmanagement-Z 4 4
Komponentenentwicklung-2 Qualitätsmanagement-A 4 4
Komponentenentwicklung-3 Qualitätsmanagement-Z 4 4
Komponentenentwicklung-4 Qualitätsmanagement-Z 4 4
256
A.2 Detailinformationen zur statischen Analyse
Ort 1 Ort 2 Kopplungs- Kopplungs-
dichte komplexität
Komponentenentwicklung-5 Qualitätsmanagement-Z 4 4
Qualitätsmanagement-A Qualitätsmanagement-Z 1 1
Tabelle A.59: Kopplung zwischen zwei Orten – Verlagerungsalternative2
Ort Kopplungsdichte Kopplungskomplexität
verkleinerte
Kundenlokation 6 4
Anwendungsentwicklung 35 13
Managementlokation* 59 13
Komponentenentwicklung-1 11 6
Komponentenentwicklung-2 11 6
Komponentenentwicklung-3 11 6
Komponentenentwicklung-4 11 6
Komponentenentwicklung-5 11 6
Qualitätsmanagement-Z 35 8
Qualitätsmanagement-A 6 6
Tabelle A.60: Kopplung eines Ortes – Verlagerungsalternative2
Ort Kohäsionsdichte Kohäsionskomplexität
verkleinerte
Kundenlokation 0 0
Anwendungsentwicklung 20 6
Managementlokation* 21 12
Komponentenentwicklung-1 18 5
Komponentenentwicklung-2 18 5
Komponentenentwicklung-3 18 5
Komponentenentwicklung-4 18 5
Komponentenentwicklung-5 18 5
Qualitätsmanagement-Z 23 8
Qualitätsmanagement-A 17 7
Tabelle A.61: Kohäsion eines Ortes – Verlagerungsalternative2
257
Aufbau der Beispielprozesslandschaft
Ort Kkf
verkleinerte Kundenlokation 32
Anwendungsentwicklung 8,87
Managementlokation* 6,45
Komponentenentwicklung-1 0,26
Komponentenentwicklung-2 0,26
Komponentenentwicklung-3 0,26
Komponentenentwicklung-4 0,26
Komponentenentwicklung-5 0,26
Qualitätsmanagement-Z 2,28
Qualitätsmanagement-A 0,15
Tabelle A.62: Kommunikationskostenfaktoren aller Orte –
Verlagerungsalternative2
Ort 1 Ort 2 Kopplungs- Kopplungs-
dichte komplexität
verkleinerte
Kundenlokation Anwendungsentwicklung 1 1
verkleinerte
Kundenlokation Managementlokation 4 3
verkleinerte
Kundenlokation Qualitätsmanagement-Z* 1 1
Anwendungsentwicklung Managementlokation 13 7
Anwendungsentwicklung Qualitätsmanagement-Z* 16 6
Anwendungsentwicklung Komponentenentwicklung-1 1 1
Anwendungsentwicklung Komponentenentwicklung-2 1 1
Anwendungsentwicklung Komponentenentwicklung-3 1 1
Anwendungsentwicklung Komponentenentwicklung-4 1 1
Anwendungsentwicklung Komponentenentwicklung-5 1 1
Managementlokation Komponentenentwicklung-1 6 2
Managementlokation Komponentenentwicklung-2 6 2
Managementlokation Komponentenentwicklung-3 6 2
Managementlokation Komponentenentwicklung-4 6 2
Managementlokation Komponentenentwicklung-5 6 2
Managementlokation Qualitätsmanagement-Z* 6 5
Managementlokation Qualitätsmanagement-A 1 1
Komponentenentwicklung-1 Qualitätsmanagement-Z* 4 4
Komponentenentwicklung-2 Qualitätsmanagement-A 4 4
Komponentenentwicklung-3 Qualitätsmanagement-Z* 4 4
Komponentenentwicklung-4 Qualitätsmanagement-Z* 4 4
258
A.2 Detailinformationen zur statischen Analyse
Ort 1 Ort 2 Kopplungs- Kopplungs-
dichte komplexität
Komponentenentwicklung-5 Qualitätsmanagement-Z* 4 4
Qualitätsmanagement-A Qualitätsmanagement-Z* 1 1
Tabelle A.63: Kopplung zwischen zwei Orten – Verlagerungsalternative3
Ort Kopplungsdichte Kopplungskomplexität
verkleinerte
Kundenlokation 6 4
Anwendungsentwicklung 35 13
Managementlokation 54 9
Komponentenentwicklung-1 11 6
Komponentenentwicklung-2 11 6
Komponentenentwicklung-3 11 6
Komponentenentwicklung-4 11 6
Komponentenentwicklung-5 11 6
Qualitätsmanagement-Z* 40 11
Qualitätsmanagement-A 6 6
Tabelle A.64: Kopplung eines Ortes – Verlagerungsalternative3
Ort Kohäsionsdichte Kohäsionskomplexität
verkleinerte
Kundenlokation 1 1
Anwendungsentwicklung 20 6
Managementlokation 19 12
Komponentenentwicklung-1 18 5
Komponentenentwicklung-2 18 5
Komponentenentwicklung-3 18 5
Komponentenentwicklung-4 18 5
Komponentenentwicklung-5 18 5
Qualitätsmanagement-Z* 25 9
Qualitätsmanagement-A 17 7
Tabelle A.65: Kohäsion eines Ortes – Verlagerungsalternative3
259
Aufbau der Beispielprozesslandschaft
Ort Kkf
verkleinerte Kundenlokation 32
Anwendungsentwicklung 8,87
Managementlokation 6,14
Komponentenentwicklung-1 0,26
Komponentenentwicklung-2 0,26
Komponentenentwicklung-3 0,26
Komponentenentwicklung-4 0,26
Komponentenentwicklung-5 0,26
Qualitätsmanagement-Z* 1,98
Qualitätsmanagement-A 0,15
Tabelle A.66: Kommunikationskostenfaktoren aller Orte –
Verlagerungsalternative3
Ort 1 Ort 2 Kopplungs- Kopplungs-
dichte komplexität
verkleinerte
Kundenlokation Anwendungsentwicklung 1 1
verkleinerte
Kundenlokation Managementlokation 4 3
verkleinerte
Kundenlokation Qualitätsmanagement-Z 2 2
Anwendungsentwicklung Managementlokation 13 7
Anwendungsentwicklung Qualitätsmanagement-Z 12 5
Anwendungsentwicklung Komponentenentwicklung-1* 5 5
Anwendungsentwicklung Komponentenentwicklung-2 1 1
Anwendungsentwicklung Komponentenentwicklung-3 1 1
Anwendungsentwicklung Komponentenentwicklung-4 1 1
Anwendungsentwicklung Komponentenentwicklung-5 1 1
Managementlokation Komponentenentwicklung-1* 8 3
Managementlokation Komponentenentwicklung-2 6 2
Managementlokation Komponentenentwicklung-3 6 2
Managementlokation Komponentenentwicklung-4 6 2
Managementlokation Komponentenentwicklung-5 6 2
Managementlokation Qualitätsmanagement-Z 4 3
Managementlokation Qualitätsmanagement-A 1 1
Komponentenentwicklung-1* Qualitätsmanagement-Z 6 6
Komponentenentwicklung-2 Qualitätsmanagement-A 4 4
Komponentenentwicklung-3 Qualitätsmanagement-Z 4 4
Komponentenentwicklung-4 Qualitätsmanagement-Z 4 4
260
A.2 Detailinformationen zur statischen Analyse
Ort 1 Ort 2 Kopplungs- Kopplungs-
dichte komplexität
Komponentenentwicklung-5 Qualitätsmanagement-Z 4 4
Qualitätsmanagement-A Qualitätsmanagement-Z 1 1
verkleinerte
Kundenlokation Komponentenentwicklung-1* 1 1
Tabelle A.67: Kopplung zwischen zwei Orten – Verlagerungsalternative4
Ort Kopplungsdichte Kopplungskomplexität
verkleinerte
Kundenlokation 7 4
Anwendungsentwicklung 35 13
Managementlokation 54 9
Komponentenentwicklung-1* 20 11
Komponentenentwicklung-2 11 6
Komponentenentwicklung-3 11 6
Komponentenentwicklung-4 11 6
Komponentenentwicklung-5 11 6
Qualitätsmanagement-Z 35 8
Qualitätsmanagement-A 6 6
Tabelle A.68: Kopplung eines Ortes – Verlagerungsalternative4
Ort Kohäsionsdichte Kohäsionskomplexität
verkleinerte
Kundenlokation 0 0
Anwendungsentwicklung 20 6
Managementlokation 19 12
Komponentenentwicklung-1* 18 5
Komponentenentwicklung-2 18 5
Komponentenentwicklung-3 18 5
Komponentenentwicklung-4 18 5
Komponentenentwicklung-5 18 5
Qualitätsmanagement-Z 23 8
Qualitätsmanagement-A 17 7
Tabelle A.69: Kohäsion eines Ortes – Verlagerungsalternative4
261
Aufbau der Beispielprozesslandschaft
Ort Kkf
verkleinerte Kundenlokation 32
Anwendungsentwicklung 8,87
Managementlokation 6,14
Komponentenentwicklung-1* 0,97
Komponentenentwicklung-2 0,26
Komponentenentwicklung-3 0,26
Komponentenentwicklung-4 0,26
Komponentenentwicklung-5 0,26
Qualitätsmanagement-Z 2,28
Qualitätsmanagement-A 0,15
Tabelle A.70: Kommunikationskostenfaktoren aller Orte –
Verlagerungsalternative4
A.3 Detailinformationen zur dynamischen Analyse
In diesem Abschnitt sind die zur Parametrisierung des Simulationsmodells verwen-
deten Daten detailliert aufgeführt. Dazu ist für jedes separat modellierte Petrinetz eine
entsprechende Abbildung eingefügt, die mit Hilfe der Tabellen A.71 bis A.76 Auskunft
über Zeitbedarfe der modellierten Aktivitäten und Volumina der ausgetauschten Infor-
mationen geben. Den Zeitbedarfen sowie den Volumina liegen Schätzungen für kleine
(ca. 100 Personentage), mittlere (ca. 500 Personentage) und große Projekte (ca. 1000
Personentage) zugrunde. Nähere Begründungen für bestimmte Volumina und Zeitbe-
darfe finden sich bei [Stö01b].
Ist in den Tabellen A.71 bis A.76 anstelle des Zeitbedarfs ein Volumen angegeben,
so bedeutet dies, dass durch die Aktivität eine Kommunikation angestoßen wird, bei
der eine Nachricht der angegebenen Größe übermittelt wird. Die in den Tabellen mit
x.c() abstrakt angegebene Variable repräsentiert den Komplexitätswert, der während
der Simulation zufällig und gleichverteilt auf einer Skala von 1 bis 10 zugewiesen
wird.
Nach der Darstellung der Simulationsmodelle sowie zugehöriger Zeitbedarfe und Vo-
lumina sind abschließend zwei Kostenmodelle erläutert, die die Kosten der modellier-
ten Kommunikationssysteme beeinflussen.
262
A.3 Detailinformationen zur dynamischen Analyse
:ersteAnforderungen(x)
x
x Anforderungs-
analyse erstellen
:setQMz(n)
QMz
n
n
:setPM(n)
PM
n:setDE(n)
DE
de
Anforderungs-
dokument
qm
xx
Komponenten-
anf. extrahieren
:WV_Architektur(x)
x @ 5 + 5.9 * x.c()
[]
de
x
Anf.-Dokument
Komponente
Repository
Architektur
z
pm
:gekaufteKomponente(y)
qm
xx @ 14 + x.c() * 16.7
:TestIntegrOk(x)
qm
System in-
tegrieren
zz
y y
:ReviewArchOk(x)
x
x
System in-
stallieren
:entwickelteKomponente(z)
integriertes
System
installiertes
System
Systemar-
chitektur
pm
x @ 2 + x.c() * 3.6
[]
Konfigurations-
management bedienen
y @ 2 + y.c() * 2.4 y
de
Feedback an
DE geben
x
z @ 2 + 3.6* z.c()
x
Test Integration
anstoßen
Zur Abnahme
freigeben
y
y
pm
Richtlinien
anfordern
:Richtlinien(x)[true, rla]
[Math.random() < 0.1, rla]
Richtlinienanforderung
initiator_AE
:responder_QM()
qm
[Math.random() < 0.1, x];
qm
:responder_DE()
ersteAnforderungen
akzGP_Modell
:responder_PM()
responder_QM
x
gekaufteKomponente
ReviewArchOk
Richtlinien
WV_Architektur
entwickelteKomponente
setQMz
setPM
setDE
ReviewAnfOk
Review Anf.
anstoßen
:noResponder_DE()
responder_DE
de:responder_AE();
pm:responder_AE();
:akzGP_Modell(y)
:ReviewAnfNOk(anfNOk)
:TestIntegrNOk(x)
Komponentenmenge
zusammenstellen
:noResponder_QM()
responder_PM
Paralle-
lisieren
x
y
y
z
z
x
Review Architek-
tur anstoßen
:noResponder_PM()
depmqm
de:noResponder_AE();
pm:noResponder_AE();
x xx
y
y
TestIntegrOk
WV_ArchitekturAnfrage v: new AE_QMZ;
//action [x.setSender(this),
//x.setVia(v), x.setReceiver(qm),
//x.setVolume()];
action arc = new CBDToken(x, this, qm, x.c() * 92.5 + 75);
//v:ReviewArchitektur(x);
v:ReviewArchitektur(arc);
v: new PM_AE;
action [x.setSender(this), x.setVia(v),
x.setReceiver(pm), 
x.setVolume(x.c() * 20 + 50)];
v:fertigesSWSystem(x);
Komponen-
ten anfragen
cen
:init()
n
ce
ce:responder_AE()
:getResponder_AE(n)
action y = new CBDToken(x);
action z = new CBDToken(x);
action y = new CBDToken(x);
:ReviewAnfOk(x);
Anforderungsanalyse nachbessern[Math.random() < 0.1, anfNOk];
x @ 3.5 + x.c() * 4.375
Integration nachbessern
[Math.random() < 0.1, rla]
Integration nachbessern x @ 1.75 + x.c() * 0.95
x
[Math.random() < 0.1, rla]
action rla = new CBDToken(x);
Systemarchi-
tektur erstellen
[Math.random() < 0.1, rla]
action rla = new CBDToken(x)
xx
x
//action vce = cen.getVia();
action ace = cen.answer();
vce: Architektur(ace);
responder_CE
cen
:ArchitekturAnfrage(cen);
vce = cen.getVia()
vce
vce
:responder_CE(n) :noResponder_CE(n)
x @ 4 + 4.6 * x.c()
anfNOk @ 1 + 1.125 * anfNOk.c()
x @ 7 + x.c() * 3.8
v: new PM_AE;
action [z.setSender(this), z.setVia(v), 
z.setReceiver(pm), z.setVolume(z.c() * 95 + 50)];
v:KomponentenAnfrage(z)
[Math.random() < 0.1, rla]
Math.random() < 0.1
v: new AE_QMZ;
action [x.setSender(this),
x.setVia(v), x.setReceiver(qm),
x.setVolume(x.c() * 850 + 200)];
v:TestSystemintegration(x);
v: new DE_AE;
action [y.setSender(this),
y.setVia(v), y.setReceiver(de),
y.setVolume(y.c() * 140 + 100)];
v:FeedbackAnDE(y);
import de.ls10.pl_support.dataModel.CBDToken;
import de.renew.simulator.NetInstance;
CBDToken x, y, z, a, b, c, anfNOk, rla, ace, cen, arc;
NetInstance ce, n, v, de, pm, qm, vce;
v: new AE_QMZ;
action [x.setSender(this), x.setVia(v),
x.setReceiver(qm), x.setVolume(x.c() * 215 + 100)];
v:ReviewAnf(x);
v: new DE_AE;
action [y.setSender(this), y.setVia(v),
y.setReceiver(de),
y.setVolume(y.c() * 95 + 50)];
v:WV_ArchitekturAnfrage(y);
action rla = new CBDToken(x)
action rla = new CBDToken(x)
v: new AE_QMZ;
action rla.setSender(this); action rla.setVia(v); action rla.setReceiver(qm);
action rla.setVolume(5);
v:RichtlinienAnfrage(rla);
:ReviewArchNOk(x)
action rla = new CBDToken(x)
//zur Koordination
Abbildung A.1: Standort Anwendungsentwicklung im Simulationsmodell
263
Aufbau der Beispielprozesslandschaft
Aktivität Zeitbedarf Volumen
Anforderungsanalyse
erstellen 4 - 45 Tage =ˆ 4 + x.c() × 4.1
Review Anforderungs-
dokument anstoßen 75 - 2.250 kB =ˆ 100 + x.c() × 215
Anforderungsanalyse
nachbessern 1 - 11 Tage =ˆ 1 + x.c() × 1.0
Komponentenan-
forderungen extrahieren 5 - 64 Tage =ˆ 5 + x.c() × 5.9
Zusammenstellung der
Komponentenmenge 2 - 38 Tage =ˆ 2 + x.c() × 3.6
Komponente anfordern 50 - 100 kB =ˆ 50 + x.c() × 95
Systemarchitektur
erstellen 7 - 45 Tage =ˆ 7 + x.c() × 3.8
Systemarchitektur
nachbessern 2 - 11 Tage =ˆ 1.75 + x.c() × 0.95
Review Architektur
anstoßen 75 - 1000 kB =ˆ 75 + x.c() × 92.5
System integrieren 14 - 181 Tage =ˆ 14 + x.c() × 16.7
Systemintegration
nachbessern 4 - 45 Tage =ˆ 4 + x.c() × 4.1
Integrationstest
anstoßen 500 - 9000 kB =ˆ 500 + x.c() × 850
System installieren 2 - 38 Tage =ˆ 2 + x.c() × 3.6
Richtlinien anfragen 5 kB =ˆ 5
Konfigurations-
management 2 - 26 Tage =ˆ 2 + x.c() × 2.4
Feedback an DE geben 100 - 1500 kB =ˆ 10 + x.c() × 140
Zur Abnahme freigeben 5 - 75 kB =ˆ 5 + x.c() × 7
Tabelle A.71: Parametrisierung des Standortes Anwendungsentwicklung
264
A.3 Detailinformationen zur dynamischen Analyse
:setQMz(n)
QMz
x
   Projekt
einschätzen
    Projekt
einschätzung
x
n
n
:setPM(n)
PM
n
:setAE(n)
AE
:modellieren(x)
x x
GP model-
lieren
initiator_DE
[]
initiator_DE
:responder_PM()
initiator_DE
   GP
Modell
ae
qm
import de.ls10.pl_support.dataModel.CBDToken;
import de.renew.simulator.NetInstance;
CBDToken x, rla;
NetInstance n, ae, pm, qm, v;
:FeedbackAnDE(x)
x x
WV_Arch.
erstellen
xx @ (x.c() * 1.6 + 2)
x x
:ReviewWV_ArchOk(x)
xx
Repository
updatenRepository
[]
xx @ (x.c() * 2.1 + 5)
:WV_ArchitekturAnfrage(x)
WV_Anfrage
bearbeiten
[]
[]
qmpm ae
initiator_DE
:responder_AE()
pm
einschätzen
modellieren
setQMz
setPM
setAE
FeedbackAnDE
WV_ArchitekturAnfrage
ReviewWV_ArchOk
:einschätzen(x)
qmpm ae
pm:noResponder_DE();
ae:noResponder_DE();
//qm:noResponder_DE()
pm:responder_DE();
ae:responder_DE();
//qm:responder_DE()
responder_DE noResponder_DE
responder_AE
:noResponder_AE()
responder_PM
pm
:noResponder_QM()
:responder_QM()
v: new PM_DE;
action [x.setSender(this), x.setReceiver(pm),
x.setVia(v), x.setVolume(x.c() * 205 + 150)];
v:GP_Modell(x);
v: new DE_QMZ;
action [x.setSender(this), x.setVia(v),
x.setReceiver(qm), 
x.setVolume(x.c() * 95 + 50)];
v:WV_Architektur(x);
v: new DE_AE;
action [x.setSender(this), x.setReceiver(ae),
x.setVia(v),
x.setVolume(x.c() * 95 + 50)];
v:WV_Architektur(x);
:init()
responder_QM
Richtlinien
anfordern :Richtlinien(x)
Richtlinienv: new AE_QMZ;
action x.setSender(this); action x.setVia(v); action x.setReceiver(qm);
action x.setVolume(x.c() * 42000.0);
v:RichtlinienAnfrage(x);
x
x
qm
v: new PM_DE;
action [x.setSender(this), x.setReceiver(pm),
x.setVia(v), x.setVolume(x.c() * 20 + 50)];
v:Einschätzung(x);
x
x @ (x.c() * 2.2 + 4)
action rla = new CBDToken(x)
[Math.random() < 0,1 , rla]
[Math.random() < 0.1, rla]
action rla = new CBDToken(x)
x
:noResponder_PM()
x @ (x.c() * 2.0 + 2)
action rla = new CBDToken(x)
[]
[Math.random() < 0,1 ,rla]
[Math.random() < 0,1 , rla]
action rla = new CBDToken(x)
Abbildung A.2: Standort Domain Engineering im Simulationsmodell
Aktivität Zeitbedarf Volumen
Projekt einschätzen 2 - 22 Tage =ˆ 2 + x.c() × 2
Geschäftsprozess
modellieren 4 - 26 Tage =ˆ 4 + x.c() × 2.2
Wiederverwendungs-
architektur erstellen 1 - 7 Tage =ˆ 1 + x.c() × 0.7
Wiederverwendungs-
repository verwalten 0 Tage =ˆ 0
Repository-Anfrage
bearbeiten 5 - 26 Tage =ˆ 5 + x.c() × 21
Richtlinien anfragen 5 kB =ˆ 5
Tabelle A.72: Parametrisierung des Standortes Domain Engineering
265
Aufbau der Beispielprozesslandschaft
x x
Spezifika-
tion erstellen
:setQM(n)
QMz
n
n
AE
:Entwicklungsauftrag(x)
:setAE(n)
x @ x.c() * 7.2 + 5
[]
qmReview Spezi-
fikation anstoßen
genehmigte
SpezifikationKomponente
implementieren
:TestKomponenteOk(x)x
ae
initiator_CE
fehlerfrei getestete
Komponente
Komponente
abliefern
Richtlinien
anfordern :Richtlinien(x)
[true, rla]
Konfigurations-
mgmt bedienen
x
qm
[Math.random() < 0.1, rla]
v: new CE_AE_null;
action [x.setSender(this), x.setVia(v),
x.setReceiver(ae),
x.setVolume(x.c() * 340 + 200)];
v:entwickelteKomponente(x);
v: new CE_QM_null;
action rla.setSender(this); action rla.setVia(v); action rla.setReceiver(qm);
action x.setVolume(5);
v:RichtlinienAnfrage(rla);
import de.ls10.pl_support.dataModel.CBDToken;
import de.renew.simulator.NetInstance;
CBDToken x, y, rla, arc, aanf;
NetInstance n, ae, pm, qm, v;
setQM
setAE
Entwicklungsauftrag
Richtlinien
TestKomponenteOk
:responder_AE()
aeqm
aeqm
ungetestete
Komponente
Test Komponente
anstoßen
qm
PM
n
:setPM(n)
pm
pm
:init()
Komponenten-
spezifikation
x
qm:getResponder_QM(this)
qm x
x
x
x
x qm
qm:getResponder_QM(this);
xx
x x
ae:getResponder_AE(this)
ae
responder_AE
initiator_CE
x
v: new CE_QM_null;
action [x.setSender(this), x.setVia(v), x.setReceiver(qm),
x.setVolume(x.c() * 340 + 200)];
v:TestKomponente(x);
x @ x.c() * 7.2 + 5
x
:Architektur(arc)
arc
arc
x
x
ae
v: new CE_AE_null;
action aanf = new CBDToken(x, this, ae, x.getVolume());
action aanf.setVia(v);
v: ArchitekturAnfrage(aanf);
:ReviewSpezNOk(x)
Spez. nach-
bessern
:TestKompNOk(x)
Implementation
nachbessern
x x
x x x @ x.c() * 1.8 + 1.25
action rla = new CBDToken(x)
x @ x.c() * 1.8 + 1.25
[Math.random() < 0.1, rla]
action rla = new CBDToken(x)
x
responder_QM
:responder_QM()
v: new PM_CE_null;
ae:responder_CE(this);
pm:responder_CE([v,this]);
ae:noResponder_CE(this);
pm:noResponder_CE([v,this]);
v: new CE_QM_null;
action [x.setSender(this), x.setVia(v), x.setReceiver(qm),
x.setVolume(x.c() * 95 + 50)];
v:ReviewSpezifikation(x);
:ReviewSpezOk(x)
Abbildung A.3: Standort Komponentenentwicklung im Simulationsmodell
Aktivität Zeitbedarf Volumen
Spezifikation
erstellen 5 - 77 Tage =ˆ 5 + x.c() × 7.2
Review Spezifikation
anstoßen 50 - 1000 kB =ˆ 50 + x.c() × 95
Komponente implementieren 5 - 77 Tage =ˆ 5 + x.c() × 7.2
Komponente testen lassen 200 - 3600 kB =ˆ 200 + x.c() × 340
Komponente abliefern 200 - 3600 kB =ˆ 200 + x.c() × 340
Konfigurations-
management 1 - 15 Tage =ˆ 1 + x.c() × 1.4
Richtlinien anfragen 5 kB =ˆ 5
Tabelle A.73: Parametrisierung der Standorte Komponentenentwicklung-1 bis -5
266
A.3 Detailinformationen zur dynamischen Analyse
responder_CE
Kunden-
auftrag
Komm. mit
dem Kunden
x
erste Anfor-
derungen
[ein,true] [ein,false]
Beschluss
Projekt
ablehnen
Komp.
kaufen
fertiges SW-
System
x
x @ (x.c() * 1.2 + 1)
l @ (l.c()  * 3.2 + 4)
n
:setDE(n)
de
:Einschätzung(ein)
ein
x
:kundenanfrage(x)
Anfrage d. Kunden
x
:responder_DE()
[]
initiator_PM
x x3
GP-Modellie-
rungsauftrag
initiator_PM
:GP_Modell(x)
xx
GP_ModellGP_Modell mit
Kunden abstimmen
x @ (x.c() * 1.9 + 3)
[x, true] @ (x.c() * 0.4 + 1)
[x, true]
x
Bewertung GP_Modell
[x, false]
x x
mangelhaftes
GP_Modell
x
GP_Modell 
nachbessern
GP_Modell
akzeptieren
Abnahme mit
d. Kunden
:ReviewProjOk(x)
x
pp
n
:setAE(n)
n
:setQMZ(n)
erste An-
forderungen
Projekt be-
auftragen
[ein, Math.random() < 0.8] @ (ein.c() * 0.4 + 1)
Projekteinschätzung
ein
Proj. be-
werten
:responder_QM()
qmz
ae
:responder_AE()
GP_Modell 
übermitteln
:KomponentenAnfrage(x)
ae
:ReviewProjNOk(pp)
x
gekaufte
Komponente
Anforderungsdoku-
ment Komponente
Komponente 
beauftragen
m @ (m.c() * 0.8 +1)
Projektplan
nachbessern
pp pp
m
:responder_CE([v,n])
Build-Or-Buy-
Entscheidung
:fertigesSWSystem(x)
x
Richtlinien
anfordern
:Richtlinien(x)
[true, rla]
QMZAEDE
qmz
de
aede qmz
ae:responder_PM();
de:responder_PM();
qma:responder_PM();
qmz:responder_PM();
v: new PM_QMZ;
action rla.setSender(this); action rla.setVia(v); action rla.setReceiver(qmz);
action rla.setVolume(5);
v:RichtlinienAnfrage(rla);
x2
setQMZsetAEsetDE
responder_DE
Einschätzung
Richtlinien
ReviewProjNOk
ReviewProjOk
GP_Modellresponder_AE
Einschätzung
Projekt anstoßen
:noResponder_DE()
ae
de
ae:noResponder_PM();
de:noResponder_PM();
qma:noResponder_PM();
qmz:noResponder_PM();
aedeqmz
fertigesSWSystem
Projekt 
freigeben
:noResponder_QM()
responder_AE
responder_DE
responder_DE
:noResponder_AE()
KomponentenAnfrage
l
x @ (x.c() * 0.7 + 2)
x
l m
m
:noResponder_CE([v,n])
l
abgeschlossenes
Projekt
import de.renew.util.Dist;
import de.ls10.pl_support.dataModel.CBDToken;
import de.renew.simulator.NetInstance;
CBDToken x, x2, x3, m, l, ein, pp, rla, rle, rlew;
NetInstance n, r, ce, de, qmz, qma, ae, v, vce;
pp @ (pp.c() * 0.4 + 1)
v:new PM_AE;
action [x.setSender(this), x.setVia(v),
x.setReceiver(ae), 
x.setVolume(x.c() * 205 + 150)];
v:akzGP_Modell(x);
:init()
[]
[v,n]
x
Parallel-
lisieren
Buy-Or-Build
Entschiedaction m = new CBDToken(x);
action l = new CBDToken(x);
responder_QM
:setQMA(n)
setQMA
n QMA
qma qma
x
action rla = new CBDToken(ein);
[Math.random() < 0.1, rla]
:RichtlinienErweiterung(rle)
rle rle
Weiterleiten
responder_AE
qmz
Projketplan
ein @ (ein.c() * 1.6 + 2)
x @ (x.c() * 0.1 + 3)
v: new PM_QMZ;
action [pp.setSender(this), pp.setVia(v),
pp.setReceiver(qmz), pp.setVolume(pp.c() * 20 + 50)];
v:ReviewProjektplan(pp);
v: new PM_AE;
action [x2.setSender(this), x2.setVia(v),
x2.setReceiver(ae), x2.setVolume(x2.c() * 120 + 50)];
v:ersteAnforderungen(x2);
v: new PM_DE;
action [x.setSender(this), x.setVia(v),
x.setReceiver(de), x.setVolume(x.c() * 120 + 50)];
v:einschätzen(x);
v: new PM_DE;
action [x3.setSender(this), x3.setVia(v),
x3.setReceiver(de), 
x3.setVolume(x3.c() * 140 + 100)];
v:modellieren(x3);
v: new PM_DE;
action [x.setSender(this), x.setVia(v),
x.setReceiver(de), 
x.setVolume(x.c() * 140 + 100)];
v:modellieren(x);
v: new PM_AE;
action [l.setSender(this), l.setVia(v),
l.setReceiver(ae),
l.setVolume(l.c() * 340 + 200)];
v:gekaufteKomponente(l);
//v: new PM_CE;
action [m.setSender(this), m.setVia(v),
m.setReceiver(n),
m.setVolume(m.c() * 47.5 + 25)];
v:Entwicklungsauftrag(m);
v: new PM_QMZ;
action rlew = new CBDToken(rle, this, qmz, rle.getVolume());
v: RichtlinienErweiterung(rlew);
x
[v,n]
[v,n]
Abbildung A.4: Standort Projektmanagement im Simulationsmodell
267
Aufbau der Beispielprozesslandschaft
Aktivität Zeitbedarf Volumen
Kommunikation
mit dem Kunden 3 - 22 Tage =ˆ 3 + x.c() × 1.9
Projekteinschätzung
anstoßen 50 - 750 kB =ˆ 50 + x.c() × 70
Projekt bewerten 1 - 4 Tage =ˆ 1 + x.c() × 0.4
Projekt ablehnen 0 Tage
Projekt freigeben 2 - 18 Tage =ˆ 2 + x.c() × 1.6
Review Projektplan
anstoßen 50 - 250 kB =ˆ 50 + x.c() × 20
Projektplan nachbessern 1 - 5 Tage =ˆ 1 + x.c() × 0.3
Geschäftsprozess-
modellierung beauftragen 100 - 1500 kB =ˆ 100 + x.c() × 140
Projekt beauftragen 3 Tage
Geschäftsprozessmodell
mit Kunden abstimmen 1 - 5 Tage =ˆ 1 + x.c() × 0.4
Geschäftsprozessmodell-
Nachbesserung anstoßen 100 - 1500 kB =ˆ 100 + x.c() × 140
Geschäftsprozessmodell
akzeptieren 0 Tage
Geschäftsprozessmodell
übermitteln 150 - 2200 kB =ˆ 150 + x.c() × 205
Build-or-Buy-Entscheidung 2 - 9 Tage =ˆ 2 + x.c() × 0.7
Komponente kaufen 4 - 36 Tage =ˆ 4 + x.c() × 3.2
Komponente beauftragen 1 - 9 Tage =ˆ 1 + x.c() × 0.8 25 - 500 kB =ˆ 25 + x.c() × 47.5
Abnahme mit dem Kunden 1 - 13 Tage =ˆ 1 + x.c() × 1.2
Richtlinienerweiterungs-
vorschlag weiterleiten 0 - 150 kB =ˆ x.c() × 15
Richtlinien anfragen 5 kB =ˆ 5
Tabelle A.74: Parametrisierung des Standortes Projektmanagement
268
A.3 Detailinformationen zur dynamischen Analyse
spez
Spezifikation
reviewen
spez
[]
initiator_QM
:TestKomponente(test);
test
Komponente
testen
test
[test, Math.random() < 0.5] @ (3 + test.c() * 2.1)
v = test.getVia();
action [testOk = test.answer(),
test.setVolume(test.c() * 7 + 5)];
v:TestKomponenteOk(testOk);
Spez. beanstanden Spez. freigeben
Komp. beanstanden
initiator_QMinitiator_QM
Komp. freigeben
:ReviewAnf(anf)
anf
Anforderung
reviewen
anf
[anf, false]Anf. beanstanden Anf. freigeben
[spez, Math.random() < 0.5] @ (2 + 3.6 *spez.c())
:ReviewArchitektur(arch)
arch arch
[arch, Math.random() < 0.5] @ (3 + 1.8 * arch.c())
Arch. beanstanden Arch. freigeben
Architektur
reviewen
sys sys
[sys, Math.random() < 0.5] @ (4 + 2.3 * sys.c())
Integr. beanstanden Integr. freigeben
Systemintegration
         testen
:ReviewWV_Arch(arch)
WV_Arch.
reviewen
arch
[arch, Math.random() < 0.5] @ (1 + arch.c() * 1.1)
WV_Arch. beanstanden WV_Arch. freigeben
:ReviewProjektplan(pp)
pp
Projektplan
reviewen
pp
:responder_PM()
rl @ (1 + rl.c()* 2.6)
rl
n
:setDE(n)
n
:setAE(n)
AE DEimport de.ls10.pl_support.dataModel.CBDToken;
import de.renew.simulator.NetInstance;
CBDToken anf, arch, sys, rl, spez, test, wv, pp, rle;
CBDToken anfOk, anfNOk, archOk, archNOk, sysOk, sysNOk, rlAntw, spezOk, spezNOk, testOk, testNOk, wvOk, wvNOk, ppOk, ppNOk, ppr;
NetInstance n, r, ae, de, ce, pm, v;
n
:setPM(n)
PM
Projektplan beanstanden
aedepm
v: new PM_QMZ;
action [ppr.setVolume(ppr.c() * 20 + 50)];
v:ReviewProjNOk(ppr);
ae:responder_QM();
de:responder_QM();
pm:responder_QM();
v: new AE_QMZ;
action [archNOk= arch.answer(),
archNOk.setVolume(arch.c() * 16 + 40)];
v:ReviewArchNOk(archNOk);
ReviewAnf
ReviewArchitektur
TestSystemintegration
ReviewSpezifikation
TestKomponente
ReviewWV_Arch
setAE setDE setPM
ReviewProjektplan
RichtlinienAnfrage
:responder_DE() :noResponder_DE()
:noResponder_PM()
:responder_CE()
:responder_AE() :noResponder_AE()
aedepm
:TestSystemintegration(sys)
:ReviewSpezifikation(spez);
:noResponder_CE()
v
v
v: new DE_QMZ;
action [archNOk = arch.answer(),
archNOk.setVolume(arch.c() * 95 + 50)];
v:FeedbackAnDE(archNOk);
v: new DE_QMZ;
action [archOk = arch.answer(),
arch.setVolume(arch.c() * 7 + 5)];
v:ReviewWV_ArchOk(archOk);
a
ae
ae
v = sys.getVia();
action [sysOk = sys.answer(),
sys.setVolume(sys.c() * 7 + 5)];
v:TestIntegrOk(sysOk); de
pm
v: new PM_QMZ;
action [ppr.setVolume(ppr.c() * 7 + 5)];
v:ReviewProjOk(ppr);
:init()
n
:getResponder_QM(n)
ce
ce:responder_QM()
[ppr, Math.random() < 0.5] @ (1 + pp.c() * 0.3)
[anf, true]
[arch, false] [arch, true]
[sys, false] [sys, true]
action [rlAntw = rl.answer(),
rl.setVolume(250)];
v:Richtlinien(rlAntw);
[spez, false] [spez, true]
[test, false] [test, true]
arch
[arch, false] [arch, true]
[ppr, false]
Projektplan freigeben
[ppr, true]
ae:noResponder_QM();
de:noResponder_QM();
pm:noResponder_QM();
v: new AE_QMZ;
action [archOk = arch.answer(),
 arch.setVolume(arch.c() * 7 + 5)];
v:ReviewArchOk(archOk);
v: new AE_QMZ;
action [anfNOk = anf.answer(),
anfNOk.setVolume(anf.c() * 40 + 50)];
v:ReviewAnfNOk(anfNOk);
responder_PM
[anf,Math.random() < 0.5] @ (1 + anf.c() * 1.8)
responder_AE[]
responder_DE[]
responder_CE[]
initiator_QM
Kontrolle
Richtlinien
liefern
Richtlinien einarbeiten
:RichtlinienErweiterung(rle)
rle @ (1 + rle.c() * 0.5)
v: new AE_QMZ;
action [anfOk = anf.answer(), 
anfOk.setVolume(anf.c() * 7 + 5)];
v:ReviewAnfOk(anfOk);
v: new AE_QMZ;
action [sysNOk = sys.answer(),
sysNOk.setVolume(sys.c() * 50 + 95)];
v:TestIntegrNOk(sysNOk);
action ppr = pp.answer();
v = spez.getVia();
action [spezNOk = spez.answer(), 
spezNOk.setVolume(spez.c() * 95 + 50)];
v:ReviewSpezNOk(spezNOk);
v = spez.getVia();
action [spezOk = spez.answer(),
spez.setVolume(spez.c() * 7 + 5)];
v:ReviewSpezOk(spezOk);
v = test.getVia();
action [testNOk = test.answer(),
testNOk.setVolume(test.c() * 95 + 50)];
v:TestKompNOk(testNOk);
:RichtlinienAnfrage(rl);
v = rl.getVia();
Abbildung A.5: Standort Qualitätsmanagement-Z im Simulationsmodell
269
Aufbau der Beispielprozesslandschaft
Aktivität Zeitbedarf Volumen
Projektplan reviewen 1 - 4 Tage =ˆ 1 + x.c() × 0.4
Projektplan beanstanden 50 - 250 kB =ˆ 50 + x.c() × 20
Projektplan freigeben 5 - 75 kB =ˆ 5 + x.c() × 7
Wiederverwendungs-
architektur reviewen 1 - 12 Tage =ˆ 1 + x.c() × 1.1
Wiederverwendungs-
architektur beanstanden 50 - 1000 kB =ˆ 50 + x.c() × 95
Wiederverwendungs-
architektur freigeben 5 - 75 kB =ˆ 5 + x.c() × 7
Anforderungsdokument
reviewen 1 - 19 Tage =ˆ 1 + x.c() × 1.8
Anforderungsdokument
beanstanden 50 - 450 kB =ˆ 50 + x.c() × 40
Anforderungsdokument
freigeben 5 - 75 kB =ˆ 5 + x.c() × 7
Architektur reviewen 3 - 21 Tage =ˆ 3 + x.c() × 1.8
Architektur beanstanden 40 - 205 kB =ˆ 40 + x.c() × 16
Architektur freigeben 5 - 75 kB =ˆ 5 + x.c() × 7
Systemintegration testen 4 - 27 Tage =ˆ 4 + x.c() × 2.3
Systemintegration beanstanden 50 - 1000 kB =ˆ 50 + x.c() × 95
Systemintegration freigeben 5 - 75 kB =ˆ 5 + x.c() × 7
Spezifikation reviewen 2 - 38 Tage =ˆ 2 + x.c() × 3.6
Spezifikation beanstanden 50 - 1000 kB =ˆ 50 + x.c() × 95
Spezifikation freigeben 5 - 75 kB =ˆ 5 + x.c() × 7
Komponente testen 3 - 24 Tage =ˆ 3 + x.c() × 2.1
Komponente beanstanden 50 - 1000 kB =ˆ 50 + x.c() × 95
Komponente freigeben 5 - 75 kB =ˆ 5 + x.c() × 7
Richtlinienerweiterungs-
vorschlag einarbeiten 1 - 27 Tage =ˆ 1 + x.c() × 2.6
Richtlinien liefern 1 - 6 Tage =ˆ 1 + x.c() × 0.5 250 kB =ˆ 250
Tabelle A.75: Parametrisierung des Standortes Qualitätsmanagement-Z
270
A.3 Detailinformationen zur dynamischen Analyse
:ReviewSpezifikation(spez)
spez
Spezifikation
reviewen
spez
[spez, false]
[]
initiator_QM
:TestKomponente(test)
test
Komponente
testen
test
[test, false]
Spez. beanstanden Spez. freigeben
Komp. beanstanden Komp. freigeben
:setCE(n)
[any, true]
:setPM(n) pm
:responder_PM()
import de.ls10.pl_support.dataModel.CBDToken;
import de.renew.simulator.NetInstance;
CBDToken spez, spezOk, spezNOk, test, testOk, testNOk, rle, any;
NetInstance n, r, ae, de, ce, pm, v;
:noResponder_CE()
ce:responder_QM(); ce:noResponder_QM();
:noResponder_PM()
:responder_CE()
n
ce
v: new CE_QMA;
action [testOk = test.answer(),
 testOk.setVolume(test.c() * 7 + 5)];
v:TestKomponenteOk(testOk);
:init()
ReviewSpezifikation
TestKomponente
ce
ce:responder_QM();
n
ce
:getResponder_QM(n)
v: new PM_QMA;
action [rle = new CBDToken(any),
rle.setSender(this),
rle.setVia(v),
rle.setReceiver(pm),
rle.setVolume(any.c() * 15 + 0)];
v:RichtlinienErweiterung(rle)
[spez, true]
[test, Math.random() < 0.5] @ (test.c() * 2.1 + 3)
[test, true]
v: new CE_QMA;
action [spezOk = spez.answer(),
spez.setVolume(spez.c() * 7 + 5)];
v:ReviewSpezOk(spezOk);
v: new CE_QMA;
action [testNOk = test.answer(),
testNOk.setVolume(test.c() * 95 + 50)];
v:TestKompNOk(testNOk);
[spez, Math.random() < 0.5] @ (spez.c() * 3.6 + 2)
responder_PM
responder_CE[]
[test, Math.random() < 0.1]
[spez, Math.random()< 0.1]
n
v: new CE_QMA;
action [spezNOk = spez.answer(),
spezNOk.setVolume(spez.c() * 95 + 50)];
v:ReviewSpezNOk(spezNOk);
Abbildung A.6: Standort Qualitätsmanagement-A der Außenstelle-1 im
Simulationsmodell
Der Standort Qualitätsmanagement-A der Außenstelle-1 enthält eine Teilmenge der
Aktivitäten des zentralen Qualitätsmanagements. Konkret sind dies die Aktivitäten
 Spezifikation reviewen
 Spezifikation beanstanden
 Spezifikation freigeben
 Komponente testen
 Komponente beanstanden
 Komponente freigeben
Zusätzlich enthält der Standort die Aktivität Richtlinienerweiterungsvorschlag erar-
beiten, deren Volumen in Tabelle A.76 angegeben ist.
Aktivität Zeitbedarf Volumen
Richtlinienerweiterungs-
vorschlag erarbeiten 50 - 150 kB =ˆ x.c() × 15
Tabelle A.76: Parametrisierung des Standortes Qualitätsmanagement-A
271
Aufbau der Beispielprozesslandschaft
Nachfolgend sind weitere Parameter des Simulationsmodells aufgeführt, die Einfluss
auf die Kosten der Kommunikationssysteme haben. Dies sind zum einen zwei Kos-
tenmodelle für unterschiedliche Gebührenberechnungen und zum anderen eine Liste
aller innerhalb der Beispielprozesslandschaft verwendeten Kommunikationssysteme.
Für letztere wird vereinfachend davon ausgegangen, dass jeweils alle Kommunikati-
onskanäle zwischen zwei Standorten zu einem Kommunikationssystem zusammenge-
fasst sind.
Kostenmodelle für Kommunikationssysteme
Kostenmodell a:
Für Standleitungen ist ein monatlicher Festpreis festgelegt, der sich nach der Kapazität
und der garantierten Qualität der Leitung richtet. Bei diesem Kostenmodell steht die
Leitung den Kommunikationspartnern ohne zusätzliche Gebühren jederzeit zur Verfü-
gung.
Kostenmodell b:
Bei diesem Kostenmodell ist die Nutzungsgebühr abhängig von der Größe des zu über-
tragenden Volumens, der Kapazität des genutzten Kommunikationskanals, einem fes-
ten Preis pro Einheit und der mittleren Dauer einer Einheit. Tabelle A.77 zeigt Bei-
spielwerte, anhand derer die Berechnung der Kosten für dieses Modell verdeutlicht
werden.
Variable Beschreibung Beispieldaten
V zu übertragendes Volumen (Eingabewert)
K Kapazität des Kanals 64 kBit/s
P Preis pro Einheit 0,12 Euro
E mittlere Dauer einer Einheit Mittelwert(120s, 15s) = 67,5s
Tabelle A.77: Beispieldaten zum Kostenmodell b
Für dieses Beispiel wird zunächst ein Durchschnittspreis P

berechnet:
P

= Preis/Einheit in Euro × 60 s/min / mittlere Dauer einer Einheit in s
= 0,12 Euro × 60 s/min / 67,5s
≈ 0,11 Euro/min
Die Übertragungskosten einer Nachricht einer Größe V lassen sich nun wie folgt ab-
schätzen:
K

= P

[Euro/min]×
V [kBit]
K[kBit/s]× 60[s/min]
272
A.3 Detailinformationen zur dynamischen Analyse
Bei beiden Kostenmodellen finden in der Realität zusätzlich anfallende Grundgebüh-
ren keine Berücksichtigung.
Kommunikationssystem Ausprägung Kosten in Euro
Anwendungsentwicklung ⇔
Qualitätsmanagement-Z Ethernet im LAN 0.00
Komponentenentwicklung-1 ⇒
Anwendungsentwicklung Ethernet im LAN 0.00
Komponentenentwicklung-2 ⇒ ISDN mit Kabelbündung
Anwendungsentwicklung bei RegioCall 2 x 0.11 = 0.22
Komponentenentwicklung-3 ⇒ ISDN mit Kabelbündung
Anwendungsentwicklung bei GlobalCall 2 x 3.63 = 7.26
Komponentenentwicklung-4 ⇒ ISDN mit Kabelbündung
Anwendungsentwicklung bei GlobalCall 2 x 3.63 = 7.26
Komponentenentwicklung-5 ⇒ ISDN mit Kabelbündung
Anwendungsentwicklung bei GlobalCall 2 x 3.63 = 7.26
Komponentenentwicklung-1 ⇔
Qualitätsmanagement-Z Ethernet im LAN 0.00
Komponentenentwicklung-2 ⇔
Qualitätsmanagement-A Ethernet im LAN 0.00
Komponentenentwicklung-3 ⇔ ISDN mit Kabelbündung
Qualitätsmanagement-Z bei GlobalCall 2 x 3.63 = 7.26
Komponentenentwicklung-4 ⇔ ISDN mit Kabelbündung
Qualitätsmanagement-Z bei GlobalCall 2 x 3.63 = 7.26
Komponentenentwicklung-5 ⇔ ISDN mit Kabelbündung
Qualitätsmanagement-Z bei GlobalCall 2 x 3.63 = 7.26
Domain Engineering ⇔
Anwendungsentwicklung Ethernet im LAN 0.00
Domain Engineering ⇔
Qualitätsmanagement-Z Ethernet im LAN 0.00
Projektmanagement ⇔
Anwendungsentwicklung ISDN bei RegioCall 0.11
Projektmanagement ⇒
Komponentenentwicklung-1 Ethernet im LAN 0.00
Projektmanagement ⇒
Komponentenentwicklung-2 Fax bei RegioCall 0.11
Projektmanagement ⇒
Komponentenentwicklung-3 Fax bei GlobalCall 3.63
Projektmanagement ⇒
Komponentenentwicklung-4 Fax bei GlobalCall 3.63
Projektmanagement ⇒
Komponentenentwicklung-5 Fax bei GlobalCall 3.63
273
Aufbau der Beispielprozesslandschaft
Kommunikationssystem Ausprägung Kosten in Euro
Projektmanagement ⇔
Domain Engineering Ethernet im LAN 0.00
Projektmanagement ⇔
Qualitätsmanagement-Z Ethernet im LAN 0.00
Qualitätsmanagement-A ⇒
Projektmanagement ISDN bei RegioCall 0.11
Tabelle A.78: Kommunikationssysteme der Beispielprozesslandschaft
Tabelle A.79 zeigt abschließend ausgewählte Initiator-/Responder-Erfüllungsraten der
modifizierten Prozesslandschaft, die in Abschnitt 4.2.2.2 nicht näher diskutiert werden,
da deren Analyse eng mit der der Prozessauslastung zusammenhängt.
erwartungstr. Standard-
Orte Min Max Mittelwert abweichung
Anwendungsentwicklung ⇒
Qualitätsmanagement-Z 10,53 43,94 24,25 9,40
Domain Engineering ⇒
Qualitätsmanagement-Z 11,11 53,85 28,43 8,96
Projektmanagement ⇒
Qualitätsmanagement-Z 13,04 58,06 28,33 8,72
Tabelle A.79: Initiator-/Responder-Erfüllungsraten der modifizierten
Beispielprozesslandschaft
274
Literaturverzeichnis
[ABK95] M. Adler, J. W. Byers und R. M. Karp. Parallel Sorting With Limi-
ted Bandwidth. In Proceedings of the 7th Annual ACM Symposium on
Parallel Algorithms and Architectures, Seiten 129–136, Santa Barbara,
California, 1995. ACM Press.
[ade99] adesso AG, 1999. http://www.adesso.de/de/solutions/
leusmart/index.html, Stand 2001.
[AF98] P. Allen und S. Frost. Component-based Development for Enterprise
Systems - Applying the Select Perspective. Cambridge University Press,
1998.
[AISJ77] C. A. Alexander, S. Ishikawa, M. Silverstein und M. Jacobson. The
Timeless Way of Building. Oxford University Press, New York, 1977.
[Ale79] C. A. Alexander. The Timeless Way of Building. Oxford University
Press, New York, 1979.
[Alf03] K. Alfert. Vitruv: Specifying temporal Aspects of Multimedia Presen-
tations. Dr. rer. nat. Dissertation, Universität Dortmund, Fachbereich
Informatik, Lehrstuhl für Software-Technologie, 2003.
[Amb98] S. W. Ambler. Process Patterns – Building Large-Scale Systems Using
Object Technology. Cambridge University Press, 1998.
[AP97] G. Abeysinghe und K. Phalp. Combining process modelling methods.
Information and Software Technology, 39(2):107–124, 1997.
[Bal82] H. Balzert. Die Entwicklung von Software-Systemen, Prinzipien, Me-
thoden, Sprachen, Werkzeuge. Bibliographisches Institut, 1982.
[Bal96] H. Balzert. Lehrbuch der Software-Technik – Software-Entwicklung.
Spektrum Akademischer Verlag, 1996.
[Bal01] H. Balzert. UML kompakt. Spektrum Akademischer Verlag, 2001.
[Bau96] B. Baumgarten. Petri-Netze - Grundlagen und Anwendungen. Spektrum
Akademischer Verlag, 2. Auflage, 1996.
275
Literaturverzeichnis
[BBD+99] A. Battke, A. Borusan, J. Dehnert, H. Ehrig, C. Ermel, M. Gajewski,
K. Hoffmann, B. Hohberg, G. Juhas, S. Lemke, A. Martens, J. Padberg,
W. Reisig, T. Vesper, H. Weber und M. Weber. Initial Realization of
the Petri Net Baukasten, 1999. Technischer Bericht, Humbold Univer-
sität Berlin, http://www.informatik.hu-berlin.de/PNT/
pnt-public.html, Stand September 2002.
[BD96] A. Bäumker und W. Dittrich. Fully Dynamic Search Trees for an Exten-
sion of the BSP Model. In Proceedings of the 8th Annual ACM Sympo-
sium on Parallel Algorithms and Architectures, Seiten 233–242, Pagua,
Italy, Juni 1996. ACM Press.
[BGKK99] T. Braun, M. Günter, M. Kasumi und I. Khalil. Virtual Private Network
Architecture. Interner Bericht, 1999. http://citeseer.nj.nec.
com/braun99virtual.html, Stand September 2002.
[BJK00] F. Bayer, S. Junginger und H. Kühn. A Business Process-Oriented Me-
thodology for Developing E-Business Applications. In U. F. Baake,
R. N. Zobel und M. Al-Akaidi, Hrsg., Proceedings of the 7th European
Concurrent Engineering Conference (ECEC’2000), Seiten 32–40, Lei-
cester, UK, April 2000. SCS Press.
[BJSW01] S. Becker, D. Jäger, A. Schleicher und B. Westfechtel. A Delegation
Based Model for Distributed Software Process Management. In V. Am-
briola, Hrsg., Software Process Technology – Proceedings of the 8th Eu-
ropean Workshop on Software Process Technology EWSPT, Seiten 130–
144, Witten, Germany, 2001. Springer Verlag. Erschienen als Lecture
Notes in Computer Science 2077.
[BOC02] BOC GmbH, 2002. http://www.boc-eu.com/german/
aktuelles/index.shtml, Stand September 2002.
[BPS+99] R. Bastide, P. Palanque, O. Si, D.-H. Le und D. Navarre. Petri-Net Ba-
sed Behavioural Specification of CORBA Systems. In S. Donatelli und
J. Kleijn, Hrsg., Proceedings of the 20th International Conference on
Applications and Theory of Petri Nets APTN’99, Seiten 66–85, Wil-
liamsburg, VA, USA, 1999. Springer Verlag. Erschienen als Lecture
Notes in Computer Science 1639.
[Bro02] C. Brockmann. Werkzeugunterstützte Modellierung von Prozessland-
schaften auf verschiedenen Abstraktionsebenen. Diplomarbeit, Uni-
versität Dortmund, Fachbereich Informatik, Lehrstuhl für Software-
Technologie, April 2002.
[BRS95] J. Becker, M. Rosemann und R. Schütte. Grundsätze ordnungsmäßiger
Modellierung. Wirtschaftsinformatik, 5(37):435–445, Oktober 1995.
276
Literaturverzeichnis
[BS89] I. N. Bronstein und K. A. Semendjajew. Taschenbuch der Mathematik,
1989.
[BT98] G. A. Bolcer und R. N. Taylor. Advanced Workflow Management Tech-
nologies. Software Process: Improvement and practice, 4(3):125–171,
1998.
[CDP95] D. C. Carr, A. Dandekar und D. E. Perry. Experiments in Process In-
terface Descriptions, Visualizations and Analyses. In W. Schäfer, Hrsg.,
Software Process Technology – Proceedings of the 4th European Work-
shop on Software Process Technology EWSPT, Seiten 119–137, Noord-
wijkerhout, The Netherlands, April 1995. Springer Verlag. Erschienen
als Lecture Notes in Computer Science 913.
[CFJ98] R. Conradi, A. Fugetta und M. L. Jaccheri. Six Theses on Software Pro-
cess Research. In V. Gruhn, Hrsg., Software Process Technology – Pro-
ceedings of the 6th European Workshop on Software Process Technolo-
gy EWSPT, Seiten 100–104, Weybridge, UK, September 1998. Springer
Verlag. Erschienen als Lecture Notes in Computer Science 1487.
[CFS01] F. Cattaneo, A. Fugetta und D. Sciuto. Pursuing coherence in software
process assessment and improvement. Software process improvement
and practice, 6(1):3–22, März 2001.
[Chr92] G. Chroust. Modelle der Software-Entwicklung. Oldenbourg Verlag,
1992.
[CKO92] B. Curtis, M. I. Kellner und J. Over. Process Modeling. Communicati-
ons of the ACM, 35(9):75–90, 1992.
[Col02] J. Coldewey. Agile Entwicklung Web-basierter Systeme. Wirtschafts-
informatik, 44(3):237–248, 2002.
[CPN00] CPN group. Petri Nets World – Tools and Software, 2000. Universität
Aarhus, Dänemark, http://www.daimi.au.dk/PetriNets/
tools/, Stand September 2002.
[DD98] O. Demirors und E. Demirors. Software Process Improvement in a
Small Organization: Difficulties and Suggestions. In V. Gruhn, Hrsg.,
Software Process Technology – Proceedings of the 6th European Work-
shop on Software Process Technology EWSPT, Seiten 1–12, Weybridge,
UK, September 1998. Springer Verlag. Erschienen als Lecture Notes in
Computer Science 1487.
[DEA98] S. Dami, J. Estublier und M. Amiour. APEL: a Graphical Yet Executa-
ble Formalism for Process Modeling. Automated Software Engineering,
5(1):61–96, 1998.
277
Literaturverzeichnis
[Dei00] W. Deiters. Information Gathering and Process Modeling in a Petri Net
Based Approach. In W. M. van der Aalst, J. Desel und A. Oberweis,
Hrsg., Business Process Management – Models, Techniques, and Em-
pirical Studies, Seiten 274–288. Springer Verlag, 2000. Erschienen als
Lecture Notes in Computer Science 1806.
[DF96] C. Debou und N. Fuchs. AMI: Ein quantitativer Ansatz für Software-
Projekt- und Prozessmanagement. In C. Ebert und R. Dumke, Hrsg.,
Software-Metriken in der Praxis, Seiten 181–185. Springer Verlag,
1996.
[DKW99] J.-C. Derniame, A. B. Kaba und B. Warboys. The Software Process:
Modelling and Technology. In J.-C. Derniame, A. B. Kaba und D. Wa-
stell, Hrsg., Software Process: Principles, Methodology, and Technolo-
gy, Seiten 1–13. Springer Verlag, 1999. Erschienen als Lecture Notes in
Computer Science 1500.
[Emm00] W. Emmerich. Software Engineering and Middleware: A Roadmap.
In A. Finkelstein, Hrsg., The Future of Software Engineering – 22nd
International Conference On Software Engineering 2000, Seiten 117–
129, ICSE, Toronto, Kanada, 2000. ACM Press.
[FH93] P. H. Feiler und W. S. Humphrey. Software Process Development and
Enactment: Concepts and Definitions. In Proceedings of the Second
International Conference on the Software Process, Seiten 28–40, Berlin,
Germany, Februar 1993. IEEE Computer Society Press.
[FKN+92] A. Finkelstein, J. Kramer, J. Nuseibeh, L. Finkelstein und M. Goedicke.
Viewpoints: A Framework for Integrating Multiple Perspectives in Sys-
tem Development. International Journal of Software Engineering and
Knowledge Engineering, 2(1):31–57, 1992.
[FKT00] I. Fischer, M. Koch und G. Taentzer. Local Views on Distributed Sys-
tems and their Communications. In H. Ehrig, G. Engels, H.-J. Kreowski
und G. Rozenberg, Hrsg., Proceedings of the 6th International Work-
shop on Theory and Application of Graph Transformation (TAGT’98),
Seiten 164–178, Paderborn, Germany, November 2000. Springer Ver-
lag. Erschienen als Lecture Notes in Computer Science 1764.
[FR99] X. Franch und R. M. Ribo. Using UML for Modelling the Static Part of a
Software Process. In R. France und B. Rumpe, Hrsg., Proceedings of the
2th Unified Language Conference UML’99, Seiten 292–307, Colorado,
USA, Oktober 1999. Springer Verlag. Erschienen als Lecture Notes in
Computer Science 1723.
[FRS+01] M. Friedewald, H. D. Rombach, P. Stahl, M. Broy, S. Hartkopf, S. Kim-
peler, K. Kohler, R. Wucher und P. Zoche. Softwareentwicklung in
Deutschland. Informatik Spektrum, 24(2):81–90, April 2001.
278
Literaturverzeichnis
[FS96] A. Finkelstein und I. Sommerville. The Viewpoints FAQ. Software
Engineering Journal, 11(1):2–4, 1996.
[Fug00] A. Fugetta. Software Process: A Roadmap. In A. Finkelstein, Hrsg., The
Future of Software Engineering, 22nd International Conference on Soft-
ware Engineering, Seiten 25–33, ICSE, Toronto, Kanada, 2000. ACM
Press.
[GE01] M. Gajewski und H. Ehrig. The «Petri Net Baukasten»: An Overview. In
H. Ehrig, G. Juhas, J. Padberg und G. Rozenberg, Hrsg., Unifying Petri
Nets – Advances in Petri Nets, Seiten 26–53. Springer Verlag, 2001.
Erschienen als Lecture Notes in Computer Science 2128.
[GEMT00] M. Goedicke, B. Enders, T. Meyer und G. Taentzer. ViewPoint-Oriented
Software Development: Tool Support for Integrating Multiple Perspec-
tives by Distributed Graph Transformation. In S. Graf und M. Schwartz-
bach, Hrsg., Proceedings of the 6th International Conference on Tools
and Algorithms for the Construction and Analysis of Systems, Seiten
43–47, Berlin, Germany, März/April 2000. Springer Verlag. Erschienen
als Lecture Notes in Computer Science 1785.
[Gen86] H. J. Genrich. Predicate/Transition Nets. In G. Goos und J. Hartma-
nis, Hrsg., Petri Nets: Central Models and Their Properties – Advances
in Petri Nets 1986, Part I, Proceedings of an Advanced Course, Sei-
ten 207–247, Bad Honnef, Germany, September 1986. Springer Verlag.
Erschienen als Lecture Notes in Computer Science 254.
[GF01] Arbeitskreis „Begriffe und Konzepte der Vorgehensmodellie-
rung“ GI-Fachgruppe 5.11. Begriffssammlung Vorgehensmodel-
le, 2001. http://www.vorgehensmodelle.de/Giak/
arbeitskreise/vorgehensmodelle/themenbereiche/
prinzipMethodeWerkzeug.html, Stand: September 2002.
[GHJV94] E. Gamma, R. Helm, R. Johnson und J. Vlissides. Design Patterns:
Elements of Reusable Object-Oriented Software. Addison Wesley, 1994.
[GMT99] M. Goedicke, T. Meyer und G. Taentzer. ViewPoint-oriented Software
Development by Distributed Graph Transformation: Towards a Basis for
Living with Inconsistencies. In Proceedings of the 4th IEEE Internatio-
nal Symposium on Requirements Engineering, Seiten 92–99, Limerick,
Ireland, Juni 1999. IEEE Computer Society Press.
[Gre88] I. Greif. Computer-Supported Cooperative Work – A Book of Readings.
Morgan Kaufmann, 1988.
[Gru91] V. Gruhn. Validation and Verification of Software Process Models.
Dr. rer. nat. Dissertation, Universität Dortmund, Juni 1991.
279
Literaturverzeichnis
[GT00] V. Gruhn und A. Thiel. Komponentenmodelle. Addison Wesley, 2000.
[GW99a] V. Gruhn und U. Wellen. Software Process Landscaping – An Approach
to Structure Complex Software Processes. In International Process
Technology Workshop (IPTW) Proceedings, 1999.
[GW99b] V. Gruhn und U. Wellen. Software Support for Distributed Business Pro-
cesses. In Asia-Pacific Software Engineering Conference, Seiten 200–
205, Takamatsu, Japan, 1999. IEEE Computer Society Press.
[GW00a] V. Gruhn und U. Wellen. Process Landscaping – eine Methode zur Ge-
schäftsprozessmodellierung. Wirtschaftsinformatik, 4:297–309, August
2000.
[GW00b] V. Gruhn und U. Wellen. Structuring Complex Software Processes by
„Process Landscaping“. In R. Conradi, Hrsg., Software Process Techno-
logy – Proceedings of the 7th European Workshop on Software Process
Technology EWSPT, Seiten 138–149, Kaprun, Austria, Februar 2000.
Springer Verlag. Erschienen als Lecture Notes in Computer Science
1780.
[GW01a] V. Gruhn und U. Wellen. Analysing a process landscape by simulation.
The Journal of Systems and Software, 59:333–342, 2001.
[GW01b] V. Gruhn und U. Wellen. Process Landscaping – Modelling Distributed
Processes and Proving Properties of Distributed Process Models. In
H. Ehrig, G. Juhas, J. Padberg und G. Rozenberg, Hrsg., Unifying Petri
Nets – Advances in Petri Nets, Seiten 103–125. Springer Verlag, 2001.
Erschienen als Lecture Notes in Computer Science 2128.
[GW02] V. Gruhn und U. Wellen. Autonomies in a Software Process Land-
scape. Interner Bericht 120, Universität Dortmund, Lehrstuhl Software-
Technologie, Januar 2002.
[Hay00] N. Hayes. Work-arounds and Boundary Crossing in a High Tech Op-
tronics Company: The Role of Co-operative Workflow Technologies.
Computer Supported Cooperative Work (CSCW) – The Journal of Col-
laborative Computing, 9(3):435–455, 2000.
[HB96] T. Hess und L. Brecht. State of the Art des Business Process Redesign:
Darstellung und Vergleich bestehender Methoden. Gabler Verlag, 2.
Auflage, 1996.
[HC93] M. Hammer und J. Champy. Reengineering the Corporation – A Mani-
festo for Business Revolution. Harper Collins Publishers, 1993.
[Höd98] M. Höderath. IV-Strategie als Voraussetzung für IV-Controlling am
Beispiel eines Energieversorgers. Controlling, 10(2):72–79, März 1998.
280
Literaturverzeichnis
[Hey95] M. Heym. Prozess- und Methoden-Management für Informationssyste-
me. Springer Verlag, 1995.
[HH99] T. Hess und V. Herwig. Portale im Internet. Wirtschaftsinformatik,
41(6):551–553, 1999.
[HHL98] T. Herrmann, M. Hoffmann und K.-U. Loser. Sozio-orientierte und
semi-strukturierte Modellierung mit SeeMe. In Proceedings der Fach-
tagung MobIS’98, Rundbrief des GI-Fachausschusses 5.2, Wirtschafts-
informatik, Seiten 15–22, 1998.
[HK00] P. Herrmann und H. Krumm. A Framework for Modeling Transfer Pro-
tocols. Computer Networks, 34(2):317–337, 2000.
[HKL02] T. Herrmann, G. Kunau und K.-U. Loser. Sociotechnical Walkthrough
– ein methodischer Beitrag zur Gestaltung soziotechnischer Systeme.
2002.
[HKM01] W. Hasselbrink, A. Koschel und A. Mester. Basistechnologien für
die Entwicklung von Internet-Portalen. In A. Heuer, F. Leymann und
D. Priebe, Hrsg., Datenbanksysteme in Büro, Technik und Wissenschaft,
9. GI-Fachtagung Oldenburg, Seiten 517–526. Springer Verlag, 2001.
[HMF92] W. Hesse, G. Merbeth und R. Frölich. Software-Entwicklung – Vorge-
hensmodelle, Projektführung,Produktverwaltung, Handbuch der Infor-
matik. Band 5.3. Oldenbourg Verlag, 1992.
[Hoa85] C. A. R. Hoare. Communicating Sequential Processes. Prentice Hall,
1985.
[IDS01] IDS Scheer AG, 2001. http://www.ids-scheer.com/de/, Ru-
brik Produkte, Stand September 2002.
[Int01] IntraWare AG, 2001. http://www.intraware.de/, Rubrik
GPM, Stand September 2002.
[IPB01] P. Isacsson, G. Pedersen und S. Bang. Accelerating CMM-based impro-
vement programs: the accelerator model and method with experiences.
Software process improvement and practice, 6(1):23–34, März 2001.
[JBR98] I. Jacobson, G. Booch und J. Rumbaugh. The Unified Software Deve-
lopment Process. Addison Wesley, 1998.
[Jen97] K. Jensen. Coloured Petri Nets – Basic Concepts, Analysis Methods and
Practical Use, Band 1. Springer Verlag, 2. Auflage, 1997.
[KBO96] M. I. Kellner, L. Briand und J. W. Over. A Method for Designing, Defi-
ning and Evolving Software Processes. In Proceedings of the 4th Inter-
national Conference on the Software Process, Seiten 37–48, Brighton,
UK, Dezember 1996. IEEE Computer Society Press.
281
Literaturverzeichnis
[Kee97] P. G. W. Keen, Hrsg. The Process Edge. Harvard Business School Press,
1997.
[KJKP99] H. Kühn, S. Junginger, D. Karagiannis und C. Petersen. Metamodel-
lierung im Geschäftsprozessmanagement: Konzepte, Erfahrungen und
Potentiale. In J. Desel, K. Pohl und A. Schürr, Hrsg., Modellierung ’99
– Workshop der Gesellschaft für Informatik, März 1999 in Karlsruhe,
Seiten 75–90. Teubner Verlag, 1999.
[Kor00] D. S. Koreimann. Grundlagen der Software-Entwicklung. Oldenbourg
Verlag, 3. Auflage, 2000.
[Kra96] H. Krallmann. Systemanalyse im Unternehmen. Oldenbourg Verlag, 2.
Auflage, 1996.
[Kru84] H. Krumm. Spezifikation, Implementierung und Verifikation von Kom-
munikationsdiensten für verteilte DV-Systeme. Dr. rer. nat. Dissertation,
Universität Karlsruhe, Juni 1984.
[KSK+94] P. Kuvaja, J. Similä, L. Krzanik, A. Bicego, S. Saukkonen und G. Koch.
Software Process Assessment and Improvement: the BOOTSTRAP Ap-
proach. Blackwell Publishers, Oxford, 1994.
[Kum00] O. Kummer. Renew – The Reference Net Workshop, 2000. Tool De-
monstrations, 21st International Conference on Application and Theory
of Petri Nets, http://www.renew.de, Stand Juli 2002.
[KW99] O. Kummer und F. Wienberg. Renew – The Reference Net Workshop.
Petri Net Newsletter, 56:12–16, 1999.
[KW02] C. Kopka und U. Wellen. Role-based Views to Approach Suitable Soft-
ware Process Models for the Development of Multimedia Systems. In
Proceedings of the IEEE Forth International Symposium on Multime-
dia Software Engineering (MSE’2002), Seiten 140–147, Newport Be-
ach, California, Dezember 2002. IEEE Computer Society.
[KWD00] O. Kummer, F. Wienberg und M. Duvigneau. Renew – User Guide,
Release 1.4, November 2000, 2000. Universität Hamburg, http://
www.renew.de, Stand Juli 2001.
[LK91] A. M. Law und W. D. Kelton. Simulation, Modeling & Analysis.
McGraw-Hill, 2. Auflage, 1991.
[Lon93] J. Lonchamp. A Structured Conceptual and Terminological Framework
for Software Process Engineering. In Proceedings of the Second In-
ternational Conference on the Software Process, Seiten 41–53, Berlin,
Germany, Februar 1993. IEEE Computer Society Press.
282
Literaturverzeichnis
[LSS99] S. Leinenbach, C. Seel und A.-W. Scheer. Metamodellierung im Ge-
schäftsprozessmanagement: Konzepte, Erfahrungen und Potentiale. In
J. Desel, K. Pohl und A. Schürr, Hrsg., Modellierung ’99 – Workshop
der Gesellschaft für Informatik, März 1999 in Karlsruhe, Seiten 11–26.
Teubner Verlag, 1999.
[LSW97] P. Langner, C. Schneider und J. Wehler. Prozessmodellierung mit ereig-
nisgesteuerten Prozeßketten (EPKs) und Petrinetzen. Wirtschaftsinfor-
matik, 39(5):479–489, 1997.
[MENW99] T. Menzies, S. Easterbrook, B. Nuseibeh und S. Waugh. An empiri-
cal investigation of multiple viewpoint reasoning in requirements engi-
neering. In Proceedings of the 4th International Symposium on Requi-
rements Engineering (RE’99), Seiten 100–110, Limerick, Ireland, Juni
1999. IEEE Computer Society Press.
[MID01] MID, 2001. http://www.mid.de/de/innovator/, Stand Sep-
tember 2002.
[OR86] A. M. Ould und C. Roberts. Modeling iteration in the software process.
In M. Dowson, Hrsg., Proceedings of the 3th International Software
Process Workshop, Seiten 101–104, Beckenridge, Colorado, USA, No-
vember 1986. IEEE Computer Society Press.
[Ort83] B. Orth. Grundlagen des Messens. In H. Fegert und J. Bredenkamp,
Hrsg., Messen und Testen, Band 4, Seiten 136–180. Verlag für Psycho-
logie, 1983.
[Pad98] J. Padberg. Abstract Petri Nets as a Uniform Approach to High-Level
Petri Nets. In J. L. Fiadeiro, Hrsg., Proceedings of the 13th Euro-
pean Workshop on Algebraic Development Techniques, WADT’98, Sei-
ten 240–259, Lissabon, Portugal, April 1998. Springer Verlag. Erschie-
nen als Lecture Notes in Computer Science 1589.
[Poh00] A. Pohlmann. Visualisierung und Simulation von Prozeßlandschaften
– Die lokale Sichtweise. Diplomarbeit, Universität Dortmund, Fachbe-
reich Informatik, Lehrstuhl für Software-Technologie, Mai 2000.
[Pro01] Projektgruppe Palermo. Endbericht der Projektgruppe Palermo. Interner
Bericht 109, Universität Dortmund, Fachbereich Informatik, Lehrstuhl
für Software-Technologie, Februar 2001.
[PW94] W. Pfeiffer und E. Weiß. Lean-Management – Grundlagen der Führung
und Organisation lernender Unternehmen. Erich Schmidt Verlag, 1994.
[PWCC94] M. Paulk, C. Weber, B. Curtis und M. Chrissis, Hrsg. The Capability
Maturity Model. Addison Wesley, 1994.
283
Literaturverzeichnis
[RHV00] D. Raffo, W. Harrison und J. Vandeville. Coordinating models and me-
trics to manage software projects. Software process improvement and
practice, 5(2-3):159–168, Juni/September 2000.
[RJ00] L. Rising und N. S. Janoff. The Scrum Software Development Process
for Small Teams. IEEE Software, 17(4):26–32, Juli/August 2000.
[Ros96] M. Rosemann. Komplexitätsmanagement in Prozessmodellen. Gabler
Verlag, 1996.
[RVM99] D. M. Raffo, J. V. Vandeville und R. Martin. Software Process Simula-
tion to Achieve Higher CMM Levels. Journal of Systems and Software,
46(2-3):163–172, 1999.
[SG87] M. L. G. Shaw und B. R. Gaines. An Interactive Knowledge-Elicitation
Technique using Personal Construct Technology. In A. L. Kidd, Hrsg.,
Kowledge Acquisition for Expert Systems – A Practical Handbook, Sei-
ten 109–136. Plenum Press, 1987.
[SHO95] S. M. Sutton, D. Heimbigner und L. J. Osterweil. APP/L: A Language
for Software Process Programming. ACM Transactions on Software
Engineering and Methodology, 4(3):221–286, 1995.
[Sim96] J.-M. Simon. SPICE: Overview for software process improvement.
Journal of Systems Architecture, 42(8):633–641, 1996.
[Smi98] E. Smith. Principles of High-Level Net Theory. In W. Reisig und G. Ro-
zenberg, Hrsg., Lectures on Petri Nets I: Basic Models – Advances in
Petri Nets, Seiten 174–210. Springer Verlag, 1998. Erschienen als Lec-
ture Notes in Computer Science 1491.
[SO97] S. M. Sutton und L. J. Osterweil. The Design of a Next-Generation
Process Language. In M. Jazayeri und H. Schauer, Hrsg., Proceedings
of the Joint 6th European Software Engineering Conference and the 5th
ACM SIGSOFT Symposium on the Foundation of Software Engineering,
Seiten 142–158, Zürich, Switzerland, September 1997. Springer Verlag.
Erschienen als Lecture Notes in Computer Science 1301.
[SOSW98] B. Staudt Lerner, L. J. Osterweil, S. M. Sutton Jr. und A. Wise. Pro-
gramming Process Coordination in Little-JIL. In V. Gruhn, Hrsg., Soft-
ware Process Technology – Proceedings of the 6th European Workshop
on Software Process Technology EWSPT, Seiten 127–131, Weybridge,
UK, September 1998. Springer Verlag. Erschienen als Lecture Notes in
Computer Science 1487.
[Spi92] J. M. Spivey. The Z Notation: A Reference Manual. Prentice Hall, 2.
Auflage, 1992.
284
Literaturverzeichnis
[Stö01a] H. Störrle. Describing Process Patterns with UML. In V. Ambriola,
Hrsg., Software Process Technology – Proceedings of the 8th European
Workshop on Software Process Technology EWSPT, Seiten 173–181,
Witten, Germany, 2001. Springer Verlag. Erschienen als Lecture Notes
in Computer Science 2077.
[Stö01b] M. Störzel. Simulation verteilter Prozesslandschaften. Diplomarbeit,
Universität Dortmund, Fachbereich Informatik, Lehrstuhl für Software-
Technologie, Oktober 2001.
[SW02a] M. Störzel und U. Wellen. Modelling and Simulation of Communica-
tion between Distributed Processes. In M. Al-Akaidi, Hrsg., Procee-
dings of the Fourth Middle East Symposium on Simulation and Model-
ling (MESM’2002), Seiten 156–160, Sharjah, U.A.E., September 2002.
SCS European Publishing House. ISBN: 90-77039-09-0.
[SW02b] M. Störzel und U. Wellen. Tool Support for Distributed Management of
Simulation Models and Evaluation Data. In A. Verbraeck und W. Krug,
Hrsg., Proceedings of the 14th European Simulation Symposium, Seiten
387–392, Dresden, Germany, Oktober 2002. SCS European Publishing
House. ISBN: 3-936150-21-4.
[SWR+00] P. Stahl, R. Wucher, H. D. Rombach, S. Hartkopf, K. Kohler, M. Fried-
wald, S. Kimpeler, P. Zoche, M. Broy und I. Krüger. Analyse und Eva-
luation der Softwareentwicklung in Deutschland. Studie, Bundesmini-
sterium für Bildung und Forschung BMBF, Nürnberg, Dezember 2000.
http://www.iid.de, Stand September 2002.
[TE00] G. Taentzer und H. Ehrig. Semantics of Distributed System Specifi-
cations based on Graph Transformation, 2000. GI-Jahrestagung 2000,
Workshop „Rigorose Entwicklung software-intensiver Systeme“.
[VB96] G. Vossen und J. Becker, Hrsg. Geschäftsprozeßmodellierung und
Workflow-Management. Thompson Publishing, 1996.
[WC01] A. I. Wang und L. Chunnian. Process Support for Mobile Work across
Heterogeneous Systems. In V. Ambriola, Hrsg., Software Process
Technology – Proceedings of the 8th European Workshop on Software
Process Technology EWSPT, Seiten 117–129, Witten, Germany, 2001.
Springer Verlag. Erschienen als Lecture Notes in Computer Science
2077.
[WSvW+00] T. Weitzel, S. Son, F. v. Westarp, P. Buxmann und W. Kö-
nig. Wirtschaftlichkeitsanalyse von Kommunikationsstandards –
eine Fallstudie am Beispiel von X.500 Directory Services mit
der Siemens AG. SFB 403 AB-00-05, Institut für Wirt-
schaftsinformatik, J. W. Goethe-Universität, Frankfurt am Main,
285
Literaturverzeichnis
2000. http://caladan.wiwi.uni-frankfurt.de/IWI/
projectb3/deu/publikat/x500/index.htm, Stand Septem-
ber 2002.
[Zie96] J. Ziegler. Rechnerunterstützung für kooperative Arbeit – Computer
Supported Cooperative Work. In H.-J. Bullinger und H. J. Warnecke,
Hrsg., Ein Handbuch für das moderne Management, Seiten 680–690.
Springer Verlag, 1996.
[ZL01] K. Zamli und P. Lee. Taxonomie of Process Modeling Languages. In
Proceedings of ACS/IEEE International Conference on Computer Sys-
tems and Applications, Seiten 435–437, Beirut, Libanon, Juni 2001.
IEEE Computer Society Press.
[ZPK00] B. P. Zeigler, H. Praehofer und T. G. Kim. Theory of Modeling and
Simulation – Integrating Discrete Event and Continuous Complex Dy-
namic Systems. Academic Press, 2. Auflage, 2000.
286
Abbildungsverzeichnis
1.1 Prozesse, Aktivitäten und ihre Darstellung in einer Prozesslandschaft . 9
2.1 Oberste Ebene einer Prozesslandschaft zur Darstellung komponenten-
basierter Softwareentwicklung . . . . . . . . . . . . . . . . . . . . . 22
2.2 Verfeinerung von Kernaktivitäten bis auf Prozessmodellebene . . . . 25
2.3 Verfeinerte Schnittstelle zwischen Qualitätsmanagement und
Application Engineering . . . . . . . . . . . . . . . . . . . . . . . . 27
2.4 Prozessmodell zur Beschreibung der Anforderungsanalyse . . . . . . 28
2.5 Gesamtbild der Prozesslandschaft einer komponentenbasierten
Softwareentwicklung . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.6 Umstrukturierung einer Prozesslandschaft . . . . . . . . . . . . . . . 35
2.7 Zusammenhang zwischen Effizienzbetrachtungen, Eigenschaften und
Attributen einer Prozesslandschaft . . . . . . . . . . . . . . . . . . . 41
3.1 Schnittstellen zwischen Aktivitäten . . . . . . . . . . . . . . . . . . . 66
3.2 Implizite und explizite Mengen von Schnittstellen zwischen Aktivitäten 69
3.3 Verfeinerung und Erweiterung von Schnittstellen . . . . . . . . . . . 70
3.4 Aktivitätenbaum einer Prozesslandschaft zur komponentenbasierten
Softwareentwicklung . . . . . . . . . . . . . . . . . . . . . . . . . . 74
3.5 Verfeinerung der Aktivität Application Engineering mit angedeuteten
Schnittstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
3.6 Verfeinerung der Aktivität Zusammenstellung der Komponentenmenge 77
3.7 Dokumentensicht auf die Schnittstelle Systemarchitektur . . . . . . . 79
3.8 Kommunikationskanäle in einer Prozesslandschaft . . . . . . . . . . 85
3.9 Kommunikationskanäle in einer verteilten Prozesslandschaft . . . . . 85
3.10 Berechnung der Kopplungsdichte eines Ortes . . . . . . . . . . . . . 91
3.11 Teilausschnitt der Beispielprozesslandschaft . . . . . . . . . . . . . . 97
287
Abbildungsverzeichnis
3.12 Dokumentensicht der Schnittstellen Anforderungsdokument, technische
Komponentenanforderung, Review technische Komponentenanforde-
rung, Systemarchitektur, Geschäftsprozessmodell und Review Anfor-
derungsdokument . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
3.13 Kohärente Prozesslandschaft als Ergebnis des ersten Erweiterungs-
schrittes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
3.14 Deterministisches Eingangsschaltverhalten bei internen Schnittstellen
si im Vorbereich einer Aktivität a3 . . . . . . . . . . . . . . . . . . . 106
3.15 Deterministisches Eingangsschaltverhalten bei externen Schnittstellen
se im Vorbereich einer Aktivität a3 . . . . . . . . . . . . . . . . . . . 106
3.16 Deterministisches Ausgangsschaltverhalten bzgl. interner Schnitt-
stellen im Nachbereich einer Aktivität a
1
. . . . . . . . . . . . . . . 107
3.17 Deterministisches Ausgangsschaltverhalten bzgl. externer Schnitt-
stellen im Nachbereich einer Aktivität a
1
. . . . . . . . . . . . . . . 107
3.18 Rückführung eines komplexen auf ein einfaches Eingangsschalt-
verhalten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
3.19 Rückführung eines komplexen auf ein einfaches Ausgangsschalt-
verhalten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
3.20 Kohärente Beispielprozesslandschaft mit zugeordneten Schaltverhalten 114
3.21 Aktivität Release erstellen zusammen mit ihrem Vor- und Nachbereich 116
3.22 Anpassungen der Prozesslandschaft als Voraussetzung der
Verfeinerung der Aktivität Release erstellen (CE) . . . . . . . . . . . 116
3.23 Verfeinerung einer externen Schnittstelle . . . . . . . . . . . . . . . . 117
3.24 Zusammengefasste Aktivität . . . . . . . . . . . . . . . . . . . . . . 120
3.25 Zwei-Phasen-Aktivität . . . . . . . . . . . . . . . . . . . . . . . . . 121
3.26 Vier-Augen-Prinzip . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
3.27 Beispielprozesslandschaft nach Anpassungen bezüglich des
Sonderfalls Zwei-Phasen-Aktivität . . . . . . . . . . . . . . . . . . . 124
3.28 Beispielprozesslandschaft nach Anpassungen bezüglich der
Sonderfälle Zusammengefasste Aktivität und Vier-Augen-Prinzip . . . 125
3.29 Ausschnitt der Beispielprozesslandschaft PLlogic . . . . . . . . . . . 132
3.30 Erweiterte Dokumentensicht der Schnittstellen aus Abbildung 3.29 . . 134
3.31 Auswahl der tatsächlich existierenden Datenflüsse . . . . . . . . . . . 135
3.32 Lokale Sicht auf die Beispielprozesslandschaft aus Abbildung 3.29 . . 136
3.33 Kommunikationskanal erweitert um Initiator- und Responderrolle . . 140
3.34 Pfad des Informationstyps Richtlinienerweiterung . . . . . . . . . . . 144
3.35 Objektorientierte Petrinetz-Klassifikation . . . . . . . . . . . . . . . 149
3.36 Klassifikationsmerkmal Marke . . . . . . . . . . . . . . . . . . . . . 151
3.37 Klassifikationsmerkmal Transformation . . . . . . . . . . . . . . . . 153
288
Abbildungsverzeichnis
4.1 Lokale Sicht der Beispielprozesslandschaft PLtop−com . . . . . . . . 158
4.2 Lokale Sicht der Beispielprozesslandschaft PLcom . . . . . . . . . . 175
4.3 Hierarchie von Projekten, Experimenten und Simulationsläufen . . . . 178
5.1 Verschiedene Arbeitsfenster zur Darstellung und Bearbeitung einer
Prozesslandschaft . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
5.2 Analyseergebnis der Softwareprozesslandschaft . . . . . . . . . . . . 196
5.3 Webportal von Piazza Palermo . . . . . . . . . . . . . . . . . . . . . 198
5.4 Ansicht der Schnittstellenoberfläche nach dem Start . . . . . . . . . . 199
5.5 Festlegen der Schaltverhalten . . . . . . . . . . . . . . . . . . . . . . 200
5.6 Darstellung der Prozesslandschaft innerhalb der Schnittstelle . . . . . 201
5.7 Ansicht der Schnittstellenoberfläche bei identifiziertem Sonderfall . . 202
5.8 Ausschnitt aus der in Renew importierten Prozesslandschaft . . . . . . 203
5.9 Kommunikationskanal innerhalb eines Kommunikationssystems . . . 205
5.10 Modellierung einer Responderstelle innerhalb eines Petrinetzes . . . . 206
5.11 Oberfläche der Auswertungskomponente von Renew . . . . . . . . . 208
A.1 Standort Anwendungsentwicklung im Simulationsmodell . . . . . . . 263
A.2 Standort Domain Engineering im Simulationsmodell . . . . . . . . . 265
A.3 Standort Komponentenentwicklung im Simulationsmodell . . . . . . . 266
A.4 Standort Projektmanagement im Simulationsmodell . . . . . . . . . . 267
A.5 Standort Qualitätsmanagement-Z im Simulationsmodell . . . . . . . 269
A.6 Standort Qualitätsmanagement-A der Außenstelle-1 im Simulations-
modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
289

Tabellenverzeichnis
2.1 Vergleich des Process Landscaping mit anderen Methoden . . . . . . 54
3.1 Zusammenfassung der in Abbildung 3.2 dargestellten Situation . . . . 70
3.2 Kommunikation zwischen dem Managementstandort und dem Stand-
ort Anwendungsentwicklung . . . . . . . . . . . . . . . . . . . . . . 90
3.3 Interne Kommunikation am Managementstandort . . . . . . . . . . . 93
3.4 Ein- und Ausgangsschaltverhalten der Aktivitäten aus der Beispiel-
prozesslandschaft . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
4.1 Aufbau der Prozesslandschaft . . . . . . . . . . . . . . . . . . . . . . 159
4.2 Kopplung zwischen zwei Orten . . . . . . . . . . . . . . . . . . . . . 160
4.3 Kopplung eines Ortes . . . . . . . . . . . . . . . . . . . . . . . . . . 161
4.4 Kohäsion eines Ortes . . . . . . . . . . . . . . . . . . . . . . . . . . 162
4.5 Kopplungs- und Kohäsionszahl eines Ortes . . . . . . . . . . . . . . 162
4.6 Kommunikationskostenfaktoren aller Orte . . . . . . . . . . . . . . . 163
4.7 Kommunikationskostenfaktoren aller Orte – Alternativen 1 bis 3 . . . 165
4.8 Kommunikationskostenfaktoren aller Orte – Fusionsalternativen 1 bis 6 168
4.9 Kommunikationskostenfaktoren aller Orte – Verlagerungsalternativen
1 bis 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
4.10 Kommunikationskostenfaktoren aller Orte nach Verschiebung der
QM- Verantwortlichkeiten . . . . . . . . . . . . . . . . . . . . . . . 171
4.11 Kommunikationskostenfaktoren aller Orte auf oberster Ebene nach
Verschiebung der QM-Verantwortlichkeiten . . . . . . . . . . . . . . 172
4.12 Kommunikationskosten der Beispielprozesslandschaft . . . . . . . . . 179
4.13 Prozessauslastung der Beispielprozesslandschaft . . . . . . . . . . . . 180
4.14 Durchschnittliche Pfadlänge der Beispielprozesslandschaft . . . . . . 181
4.15 Initiator-/Responder-Erfüllungsrate der Beispielprozesslandschaft . . 183
4.16 Kommunikationskosten der modifizierten Beispielprozesslandschaft . 185
4.17 Prozessauslastung der modifizierten Beispielprozesslandschaft . . . . 186
291
Tabellenverzeichnis
4.18 Durchschnittliche Pfadlänge der modifizierten Beispielprozessland-
schaft . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
A.1 Aktivitäten der Prozesslandschaft ω und ihre lokale Verteilung . . . . 218
A.2 Kommunikationskanäle zwischen Kundenlokation und Anwendungs-
entwicklung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
A.3 Kommunikationskanäle zwischen Kundenlokation und Qualitäts-
management-Z . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
A.4 Kommunikationskanäle zwischen Kundenlokation und Management-
lokation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
A.5 Kommunikationskanäle zwischen Qualitätsmanagement-A und
Qualitätsmanagement-Z . . . . . . . . . . . . . . . . . . . . . . . . . 220
A.6 Kommunikationskanäle zwischen Anwendungsentwicklung und
Managementlokation . . . . . . . . . . . . . . . . . . . . . . . . . . 222
A.7 Kommunikationskanäle zwischen Anwendungsentwicklung und
Qualitätsmanagement-Z . . . . . . . . . . . . . . . . . . . . . . . . . 223
A.8 Kommunikationskanäle zwischen Anwendungsentwicklung und
Komponentenentwicklung-1 bis -5 . . . . . . . . . . . . . . . . . . . 223
A.9 Kommunikationskanäle zwischen Komponentenentwicklung-1, -3, -4,
-5 und Qualitätsmanagement-Z . . . . . . . . . . . . . . . . . . . . . 224
A.10 Kommunikationskanäle zwischen Komponentenentwicklung-2 und
Qualitätsmanagement-A . . . . . . . . . . . . . . . . . . . . . . . . 224
A.11 Kommunikationskanäle zwischen Komponentenentwicklung-1, -2, -3,
-4, -5 und Managementlokation . . . . . . . . . . . . . . . . . . . . . 225
A.12 Kommunikationskanäle zwischen Qualitätsmanagement-A und
Managementlokation . . . . . . . . . . . . . . . . . . . . . . . . . . 225
A.13 Kommunikationskanäle am Standort Managementlokation . . . . . . 227
A.14 Kommunikationskanäle am Standort Kundenlokation . . . . . . . . . 228
A.15 Kommunikationskanäle am Standort Qualitätsmanagement-Z . . . . . 230
A.16 Kommunikationskanäle an den Standorten Komponenten-
entwicklung-1 bis -5 . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
A.17 Kommunikationskanäle am Standort Anwendungsentwicklung . . . . 234
A.18 Kommunikationskanäle am Standort Qualitätsmanagement-A . . . . . 236
A.19 Kopplung zwischen zwei Orten – Alternative1 . . . . . . . . . . . . . 237
A.20 Kopplung eines Ortes – Alternative1 . . . . . . . . . . . . . . . . . . 237
A.21 Kohäsion eines Ortes – Alternative1 . . . . . . . . . . . . . . . . . . 238
A.22 Kommunikationskostenfaktoren aller Orte – Alternative1 . . . . . . . 238
A.23 Kopplung zwischen zwei Orten – Alternative2 . . . . . . . . . . . . . 239
A.24 Kopplung eines Ortes– Alternative2 . . . . . . . . . . . . . . . . . . 239
292
Tabellenverzeichnis
A.25 Kohäsion eines Ortes – Alternative2 . . . . . . . . . . . . . . . . . . 240
A.26 Kommunikationskostenfaktoren aller Orte – Alternative2 . . . . . . . 240
A.27 Kopplung zwischen zwei Orten – Alternative3 . . . . . . . . . . . . . 241
A.28 Kopplung eines Ortes – Alternative3 . . . . . . . . . . . . . . . . . . 241
A.29 Kohäsion eines Ortes – Alternative3 . . . . . . . . . . . . . . . . . . 242
A.30 Kommunikationskostenfaktoren aller Orte – Alternative3 . . . . . . . 242
A.31 Kopplung zwischen zwei Orten – Fusionsalternative1 . . . . . . . . . 243
A.32 Kopplung eines Ortes – Fusionsalternative1 . . . . . . . . . . . . . . 243
A.33 Kohäsion eines Ortes – Fusionsalternative1 . . . . . . . . . . . . . . 244
A.34 Kommunikationskostenfaktoren aller Orte – Fusionsalternative1 . . . 244
A.35 Kopplung zwischen zwei Orten – Fusionsalternative2 . . . . . . . . . 245
A.36 Kopplung eines Ortes – Fusionsalternative2 . . . . . . . . . . . . . . 245
A.37 Kohäsion eines Ortes – Fusionsalternative2 . . . . . . . . . . . . . . 246
A.38 Kommunikationskostenfaktoren aller Orte – Fusionsalternative2 . . . 246
A.39 Kopplung zwischen zwei Orten – Fusionsalternative3 . . . . . . . . . 247
A.40 Kopplung eines Ortes – Fusionsalternative3 . . . . . . . . . . . . . . 247
A.41 Kohäsion eines Ortes – Fusionsalternative3 . . . . . . . . . . . . . . 248
A.42 Kommunikationskostenfaktoren aller Orte – Fusionsalternative3 . . . 248
A.43 Kopplung zwischen zwei Orten – Fusionsalternative4 . . . . . . . . . 249
A.44 Kopplung eines Ortes – Fusionsalternative4 . . . . . . . . . . . . . . 249
A.45 Kohäsion eines Ortes – Fusionsalternative4 . . . . . . . . . . . . . . 250
A.46 Kommunikationskostenfaktoren aller Orte – Fusionsalternative4 . . . 250
A.47 Kopplung zwischen zwei Orten – Fusionsalternative5 . . . . . . . . . 251
A.48 Kopplung eines Ortes – Fusionsalternative5 . . . . . . . . . . . . . . 251
A.49 Kohäsion eines Ortes – Fusionsalternative5 . . . . . . . . . . . . . . 251
A.50 Kommunikationskostenfaktoren aller Orte – Fusionsalternative5 . . . 252
A.51 Kopplung zwischen zwei Orten – Fusionsalternative6 . . . . . . . . . 253
A.52 Kopplung eines Ortes – Fusionsalternative6 . . . . . . . . . . . . . . 253
A.53 Kohäsion eines Ortes – Fusionsalternative6 . . . . . . . . . . . . . . 253
A.54 Kommunikationskostenfaktoren aller Orte – Fusionsalternative6 . . . 254
A.55 Kopplung zwischen zwei Orten – Verlagerungsalternative1 . . . . . . 255
A.56 Kopplung eines Ortes – Verlagerungsalternative1 . . . . . . . . . . . 255
A.57 Kohäsion eines Ortes – Verlagerungsalternative1 . . . . . . . . . . . 255
A.58 Kommunikationskostenfaktoren aller Orte – Verlagerungsalternative1 256
A.59 Kopplung zwischen zwei Orten – Verlagerungsalternative2 . . . . . . 257
A.60 Kopplung eines Ortes – Verlagerungsalternative2 . . . . . . . . . . . 257
A.61 Kohäsion eines Ortes – Verlagerungsalternative2 . . . . . . . . . . . 257
293
Tabellenverzeichnis
A.62 Kommunikationskostenfaktoren aller Orte – Verlagerungsalternative2 258
A.63 Kopplung zwischen zwei Orten – Verlagerungsalternative3 . . . . . . 259
A.64 Kopplung eines Ortes – Verlagerungsalternative3 . . . . . . . . . . . 259
A.65 Kohäsion eines Ortes – Verlagerungsalternative3 . . . . . . . . . . . 259
A.66 Kommunikationskostenfaktoren aller Orte – Verlagerungsalternative3 260
A.67 Kopplung zwischen zwei Orten – Verlagerungsalternative4 . . . . . . 261
A.68 Kopplung eines Ortes – Verlagerungsalternative4 . . . . . . . . . . . 261
A.69 Kohäsion eines Ortes – Verlagerungsalternative4 . . . . . . . . . . . 261
A.70 Kommunikationskostenfaktoren aller Orte – Verlagerungsalternative4 262
A.71 Parametrisierung des Standortes Anwendungsentwicklung . . . . . . . 264
A.72 Parametrisierung des Standortes Domain Engineering . . . . . . . . . 265
A.73 Parametrisierung der Standorte Komponentenentwicklung-1 bis -5 . . 266
A.74 Parametrisierung des Standortes Projektmanagement . . . . . . . . . 268
A.75 Parametrisierung des Standortes Qualitätsmanagement-Z . . . . . . . 270
A.76 Parametrisierung des Standortes Qualitätsmanagement-A . . . . . . . 271
A.77 Beispieldaten zum Kostenmodell b . . . . . . . . . . . . . . . . . . . 272
A.78 Kommunikationssysteme der Beispielprozesslandschaft . . . . . . . . 274
A.79 Initiator-/Responder-Erfüllungsraten der modifizierten Beispielprozess-
landschaft . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
294