Analyse von Innovator for Business Analysts

Aus Winfwiki

Fallstudienarbeit
Hochschule:	Hochschule für Oekonomie & Management
Standort:	Hamburg
Studiengang:	Bachelor Wirtschaftsinformatik
Veranstaltung:	Fallstudie / Wissenschaftliches Arbeiten
Betreuer:	Prof._Dr._Uwe_Kern
Typ:	Fallstudienarbeit
Themengebiet:	Geschäftsmodellierung
Autor(en):	Ulrich Müller, Patrick Friedhoff, Anas Bouchir, Jakob Engelmartin
Studienzeitmodell:	Abendstudium
Semesterbezeichnung:	SS11
Studiensemester:	2
Bearbeitungsstatus:	begutachtet
Prüfungstermin:
Abgabetermin:

1 Verzeichnisse

1.1 Inhaltsverzeichnis

Inhaltsverzeichnis 1 Verzeichnisse 1.1 Inhaltsverzeichnis 1.2 Abkürzungsverzeichnis 1.3 Abbildungsverzeichnis 1.4 Tabellenverzeichnis 2 Einleitung 3 Grundlagen 3.1 Definition Geschäftsprozess 3.2 Geschäftsprozessmodellierung 3.2.1 Ziele 3.2.2 Vorgehensweise 3.3 Kurzvorstellung BPMN 2.0 3.4 Kurzvorstellung UML 4 Analysekriterien für Modellierungswerkzeuge 4.1 Umsetzung von Modellierungsstandards 4.2 Benutzerfreundlichkeit und Ergonomie 4.3 Wieder- und Weiterverwendbarkeit 4.4 Mehrbenutzertauglichkeit 4.5 Dokumentationsmöglichkeiten 4.6 Im- und Exportmöglichkeiten 5 Analyse von Innovator for Business Analysts 5.1 Umsetzung von Modellierungsstandards 5.1.1 Anwendungsfalldiagramm 5.1.2 BPMN-Diagramm für Geschäftsprozesse 5.1.3 Strukturdiagramm 5.1.4 Klassendiagramm 5.1.5 Geschäftsressourcendiagramm 5.1.6 Organigramm 5.1.7 Zustandsdiagramm 5.1.8 Maskenflussdiagramm 5.2 Benutzerfreundlichkeit und Ergonomie 5.3 Wieder- und Weiterverwendbarkeit 5.4 Mehrbenutzertauglichkeit 5.5 Dokumentationsmöglichkeiten 5.6 Im- und Exportmöglichkeiten 5.6.1 BPEL Generator 5.6.2 WSDL Importer 6 Fazit 7 Fußnoten 8 Anhang 8.1 Literaturverzeichnis 8.2 Weitere Anhänge

1.2 Abkürzungsverzeichnis

Abkürzung	Bedeutung
BPEL	Business Process Execution Language
BPMN	Business Process Model and Notation[1]
DRY	Don’t Repeat Yourself
GPO	Geschäftsprozessoptimierung
LDAP	Lightweight Directory Access Protocol
MOF	Meta Object Facility
SOA	Serviceorientierte Architektur
SOAP	Simple Object Access Protocol
UML	Unified Modeling Language
WSDL	Web Services Description Language
XMI	XML Metadata Interchange
XML	Extensible Markup Language
XPDL	XML Process Definition Language

1.3 Abbildungsverzeichnis

Abb.-Nr.	Abbildung
1	camunda BPMN-Framework: Technische Umsetzung mit BPMN (rot) oder herkömmliche Anwendungsentwicklung mit vorheriger spezifischer Modellierung (blau)
2	Frontansicht des Architekturwürfels
3	Diagramme der Architekturmatrix
4	Schichten einer SOA
5	Anwendungsfalldiagrammelemente in Innovator for Business Analysts
6	Fallbeispiel als Anwendungsfalldiagramm
7	In Innovator modelliertes BPMN 2.0-Geschäftsprozessdiagramm: Beispielprozess mit Teilnehmern und Lanes in einer Kollaboration
8	Prozessstart mit 2 Ereignissen ohne ereignisbasiertes Parallelgateway
9	Beispiel eines Strukturdiagramms in Innovator for Business Analysts
10	Klassendiagrammelemente in Innovator for Business Analysts
11	Fallbeispiel als Klassendiagramm
12	Beispiel eines Geschäftsressourcendiagramms in Innovator for Business Analysts
13	Beispiel eines Zustandsdiagramms in Innovator for Business Analysts
14	Ausschnitt eines Maskenflussdiagramms in Innovator for Business Analysts
15	Benutzeroberfläche
16	Individualisierbarkeit der Benutzeroberfläche
17	Whiteboard vom Anwendungsfall
18	Rechteverwaltung in Innovator for Business Analysts
19	Aufnahme von Anforderungen in Innovator for Business Analysts
20	Status von Anforderungen
21	Anforderungen im Anwendungsfalldiagramm
22	Anforderungen im BPMN-Diagramm
23	Diagrammorientierte Dokumentation als MS-Word-Datei
24	Dokumentation im HTML-Format
25	Suchfunktion in der HTML-Dokumentation
26	Anforderungen in der HTML-Dokumentation
27	Anwendungsfalldiagramm in der HTML-Dokumentation
28	BPEL Exporter
29	WSDL Importer

1.4 Tabellenverzeichnis

Tabelle Nr.	Tabellentitel
1	Aufgabenträger zur Ausführung von Aktivitäten
2	Diagramme der UML
3	Zusammenfassung Fokus der Architekturmatrix
4	Vor- und Nachteile eines integrierten/nicht integrierten Modells

2 Einleitung

Geschäftsprozesse haben - auf die letzten Jahre betrachtet - in Unternehmen zunehmend an Bedeutung gewonnen^[2]. So bringt Geschäftsprozessmagement eine Vielzahl von Aufgabenstellungen für das Unternehmen mit sich. Diese sind auf unterschiedliche Art und Weise für den zukünftigen Erfolg relevant^[3].

Im Rahmen dieser Fallstudie wird das Modellierungswerkzeug Innovator for Business Analysts untersucht, ein primär für fachliche Modellierung von Geschäftsprozessen entwickeltes Werkzeug^[4]. Die Software ist ein Produkt der MID GmbH aus Nürnberg.

Motivation dieser Arbeit ist es, den Weg von der Anforderung über die Modellierung bis hin zum ausgeführten Ergebnis anhand eines dafür vorgesehenen Werkzeuges zu untersuchen.

Hierbei werden die Kriterien, welche die Anforderungen an ein Modellierungswerkzeug definieren, systematisch hergeleitet und im Anschluss der Innovator for Business Analysts diesbezüglich analysiert.

Dabei werden zunächst relevante Grundlagen erläutert und die zugehörigen Begriffe definiert. Daran schließt das Kapitel "Analysekriterien für Modellierungswerkzeuge" an, in welchem die Anforderungen an ein Modellierungswerkzeug ausgearbeitet und relevante Kriterien definiert werden. Im Folgenden wird die Analyse von Innovator for Business Analysts anhand der definierten Kriterien durchgeführt. Abschließend werden im Fazit die Ergebnisse zusammengefasst und eine Beurteilung der Software getroffen.

3 Grundlagen

3.1 Definition Geschäftsprozess

Ein Geschäftsprozess besteht aus einer Menge von Aktivitäten, die sich über mehrere organisatorische Einheiten verteilen können^[5].
Diese Aktivitäten können nacheinander laufen (sequentiell) oder nebenläufig (parallel) und verfolgen ein definiertes Ziel unter Berücksichtigung bestimmter Regeln^[6].
Bereits Davenport hatte eine genaue Vorstellung vom Geschäftsprozess, sowohl definitorisch als auch bezogen auf die relevanten Eigenschaften, die ihn kennzeichnen: „[...] Ein Prozess ist einfach eine strukturierte, gemessene Menge von Aktivitäten. Der Prozess wird konzipiert, um ein bestimmtes Output zu erzeugen [...]. Besonderes Augenmerk soll darauf gerichtet werden, wie die Arbeit in einer Organisation erledigt wird [...]. Ein Prozess ist also eine bestimmte Anordnung von Arbeitshandlungen durch Zeit und Raum, mit einem Anfang, einem Ende, und eindeutig identifizierte In- und Outputs: eine Struktur des Handelns.“^[7]
Die Teilaktivitäten eines Geschäftsprozesses lassen sich in manuelle, teil-automatisierte und automatisierte Aktivitäten unterteilen. Abhängig von der Beschaffenheit einer Aktivität werden unterschiedliche Aufgabenträger benötigt. Tabelle 1 verdeutlicht diesen Zusammenhang^[6].

Tabelle 1: Aufgabenträger zur Ausführung von Aktivitäten

		Aufgabenträger
		personell	nicht-personell (maschinell)
Aktivität
	manuell	X
	teil-automatisiert	X	X
	automatisiert		X

Quelle: Bartsch (2010), S. 10

3.2 Geschäftsprozessmodellierung

3.2.1 Ziele

Laut der Marktstudie "BPM 2010" des Fraunhofer-Instituts für Arbeitswirtschaft und Organisation hat die Bedeutung der Geschäftsprozesse für Unternehmen und Organisationen in den letzten Jahren weiter zugenommen^[2]. Damit ein Unternehmen dem steigenden Wettbewerbsdruck bezüglich Zeit, Kosten und Qualität gewachsen ist, sind effiziente und effektive Organisationsformen nötig. Dabei sind durchgängige, prozessorientierte Ansätze erforderlich^[8].
Hat sich ein Unternehmen dazu entschlossen, den Weg der Prozessorientierung zu gehen, ergibt sich umgehend die Notwendigkeit, aktuelle Geschäftsprozesse/-abläufe aufzunehmen und zu dokumentieren, um einen Überblick über die Prozesslandschaft zu erreichen und Optimierungspotenzial zu erkennen.
Diese Optimierung der vorhandenen Prozesse dient dazu, vorhandene Dysfunktionalitäten im Unternehmen (lange Durchlaufzeiten, Bearbeitungsfehler, Doppelarbeiten, Schnittstellenprobleme, hohe Prozesskosten)^[9] zu reduzieren. Dies nennt man Geschäftsprozessoptimierung (GPO).
Bei der Aufnahme und während der Optimierung (dauerhafter, iterativer Vorgang) von Geschäftsprozessen, schließlich zur Dokumentation, ist mit steigender Komplexität eine geeignete Toolunterstützung notwendig. Die Software hilft, den Überblick über die Vielzahl von Prozessen zu wahren, Zusammenhänge darzustellen (von Prozessen untereinander sowie mit benötigten Ressourcen), und eine unternehmensweite Nutzung der Erkenntnisse und ihrer Dokumentation zu ermöglichen. Dabei sollen eine einheitliche, systematische Vorgehensweise und einfache flexible Aktualisierbarkeit erreicht werden^[10].
"Prozess-Management ist ein zentraler Bestandteil eines integrierten Konzeptes für das Geschäftsprozess- und Workflow-Management. Es dient dem Abgleich mit der Unternehmensstrategie, der organisatorischen Gestaltung von Prozessen sowie deren technischer Umsetzung mit geeigneten Kommunikations- und Informationssystemen."^[11]
Die Optimierung von Geschäftsprozessen dient schließlich der nachhaltigen Verbesserung der Wettbewerbsfähigkeit, indem alle wesentlichen Arbeitsabläufe an den Kundenanforderungen ausgerichtet werden^[12].

3.2.2 Vorgehensweise

Um diese Ziele nun zu erreichen, gibt es eine Reihe von Möglichkeiten. Aktivitäten können weggelassen, ausgelagert (Outsourcing), zusammengefasst, parallelisiert (gleichzeitige Ausführung), innerhalb der Prozesskette verlagert, beschleunigt (indem Arbeitsmittel zur effizienten Erledigung bereitgestellt werden) werden, und schließlich auch neue Aktivitäten ergänzen^[13].
Die Optimierung von Geschäftsprozessen durchläuft dabei die gleichen Phasen wie Organisationsprojekte:

• Projektvorbereitung (Team zusammenstellen, Eingrenzung/Prozessauswahl, Projektplanung)
• Ist-Aufnahme (Erhebungen, Prozess-Modellierung, Kennzahlen)
• Prozess-Analyse (Schwachstellen, Auswertung Kennzahlen, Verbesserungsansätze)
• Sollkonzeption (Modellierung Soll-Prozesse, Prozessbewertung, Konsequenzen für Aufbauorganisation)
• Ergebnispräsentation^[14]

In einem Repository im Sinne eines Wörterbuchs werden dann bei der Geschäftsprozessmodellierung die Modellbausteine und ihren Beziehungen untereinander beschrieben. Dazu werden Geschäftsprozesse und Workflows mit den entsprechenden Verbindungen und Schnittstellen zur Umwelt erfasst. Neben der Dokumentations- und Auskunftsfunktion kann hiermit auch die Konsistenzprüfung der Modelle und Teilmodelle erfolgen^[15].
Um die Komplexität der Darstellung zu reduzieren und die Verständlichkeit und Transparenz der Modelle zu verbessern, ist es nicht sinnvoll, in einer einzigen Darstellung alle modellierungsrelevanten Sachverhalte abzubilden. Vielmehr erscheint ein Sichtenkonzept empfehlenswert, das den verschiedenen Blickwinkeln auf einen Prozess Rechnung trägt. Die Notation von Geschäftsprozessen wird unterstützt durch z.B. Organisations-, Aktivitäts-, Applikations- und Informationsstruktur-Sichten^[16].
Im Laufe der Jahre wurden verschiedene Methoden und Standards der Prozessmodellierung entworfen, die teilweise in neuen Versionen weiterentwickelt wurden, um Erfahrungen und Bedürfnisse aus der Praxis einzuarbeiten. Einige gängige Methoden sind die erweiterte ereignisgesteuerte Prozesskette (eEPK), Swimlane, UML und in den letzten Jahren mit zunehmender Bedeutung der Business Process Modeling and Notation (BPMN) Standard^[17].
UML und BPMN sind in den folgenden Kapitel näher beschrieben, da sie für die anschließende Analyse von Innovator for Business Analysts die Hauptrolle spielen. Besonders die UML dient neben der Notation von Prozessen auch der Modellierung in der Softwareentwicklung, von der Anforderungsanalyse mit Use Case Diagrammen (Anwendungsfälle), über Aktivitäten-Diagramme bis zur Daten- und Klassenmodellierung. Dies ist von Bedeutung, da die betriebswirtschaftlichen Geschäftsprozesse in ein ausführbares Workflowmodell überführt werden müssen. Die Modelle werden mit Hilfe von Workflow-Management-Systemen und Modellierungstools simuliert^[16]. Das in dieser Arbeit untersuchte Produkt Innovator for Business Analysts ist ein solches Modellierungstool, und es wird im Folgenden untersucht, inwiefern die relevanten Standards, die von der Darstellung der Geschäftsprozesse hin zu den Darstellungswerkzeugen in der Softwareentwicklung reichen, unterstützt werden.

3.4 Kurzvorstellung UML

Neben der BPMN ist die Unified Modeling Language (UML) ein weiterer Modellierungsstandard. Sie ist eine Modellierungssprache, die das Ziel verfolgt, den gesamten Prozess der Softwareentwicklung, von der Aufnahme der Anforderungen bis zur Implementierung, abbilden zu können^[26]. Darüber hinaus können mit der UML andere Prozesse, wie z.B. Geschäftsprozesse, modelliert werden^[27]. Die UML liegt aktuell in der Version 2.3 vor und wird von der Object Management Group (OMG) weiterentwickelt und spezifiziert.
Um dem breiten Spektrum an Anwendungsbereichen gerecht zu werden, ist die UML modular in 14 verschiedene Diagrammarten unterteilt. In Tabelle 2 sind diese Diagrammarten der UML nach Strukturdiagrammen, Verhaltensdiagrammen und Interaktionsdiagrammen gegliedert. Strukturdiagramme bilden die Struktur eines Systems ab, Verhaltensdiagramme zeigen Verhalten von Objekten auf und Interaktionsdiagramme verdeutlichen Interaktionen zwischen Objekten. Außerdem werden typische Anwendungsbereiche der einzelnen Diagrammarten aufgezeigt:

Tabelle 2: Diagramme der UML

Diagramm	Gliederung	Anwendungsbereich
Aktivitätsdiagramm	Verhaltensdiagramm	Anforderungsmodellierung
Anwendungsfalldiagramm	Verhaltensdiagramm	Anforderungsmodellierung
Interaktionsübersichtsdiagramm	Interaktionsdiagramm	Anforderungs- und Analysemodellierung
Klassendiagramm	Strukturdiagramm	Analyse-, Entwurfs- und Implementierungsmodellierung
Kommunikationsdiagramm	Interaktionsdiagramm	Entwurfsmodellierung
Komponentendiagramm	Strukturdiagramm	Implementierungsmodellierung
Kompositionsdiagramm	Strukturdiagramm	Entwurfsmodellierung
Objektdiagramm	Strukturdiagramm	Entwurfsmodellierung
Paketdiagramm	Strukturdiagramm	Analysemodellierung
Profildiagramm	Strukturdiagramm	Entwurfsmodellierung
Sequenzdiagramm	Interaktionsdiagramm	Analysemodellierung
Timing-Diagramm	Interaktionsdiagramm	Entwurfsmodellierung
Verteilungsdiagramm	Strukturdiagramm	Implementierungsmodellierung
Zustandsdiagramm	Verhaltensdiagramm	Entwurfsmodellierung

Die UML-Komponenten selbst werden durch das UML-Metamodell Meta Object Facility (MOF) beschrieben. Durch das Metamodell und die Bereitstellung der standardisierten Schnittstelle XML Metadata Interchange (XMI) ist die Möglichkeit gegeben, UML-Diagramme zwischen Modellierungstools austauschen zu können^[28].

4 Analysekriterien für Modellierungswerkzeuge

Anforderungen an ein Modellierungswerkzeug bestehen auf verschiedenen Ebenen.

Jedoch sind die Erfassung, Modellierung, Optimierung und Ausführung von Geschäftsprozessen nicht die einzigen möglichen Einsatzgebiete von Modellierungswerkzeugen. Der weiterführende Entwurf von verschiedenen Diagrammtypen auf konzeptioneller und technischer Ebene gehört dann dazu, wenn der Brückenschlag von den Geschäftsprozessen zu Services und somit der IT-Unterstützung in Form von Programmen und Services gelingen soll. Es wird also der Schritt zur Anwendungsentwicklung (Entwurfsbereich) gemacht. Dabei bedarf es - neben der Modellierung von Geschäftsprozessen als einer möglichen Darstellung von Anforderungen - der Unterstützung aller Entstehungsphasen einer Software-Lösung, begonnen bei der Anforderungsanalyse über die Systemarchitektur und das Software-Design bis hin zur Codierung^[35].

Wie in der Realität bedarf es auch in der Beschreibung einer Software-Architektur verschiedener Ansichten. Die einzelnen Blickwinkel oder Perspektiven sind dabei nicht richtig oder falsch, denn „nur die Summe aller Betrachtungen ergibt ein vollständiges Bild“^[36].

Die Umsetzung von Anforderungen von Unternehmen kann also auf zwei Wegen erfolgen: Auf der einen Seite werden die Geschäftsprozessmodelle nicht verlassen, sondern (mittels Process Engine) zur Ausführung gebracht. Die andere Seite stellt die Umsetzung durch Anwendungsentwicklung dar, welche im Schritt vor der Umsetzung meist noch eine spezifische Modellierung erfordert^[34]. Dies wird durch Abbildung 1 verdeutlicht.

4.1 Umsetzung von Modellierungsstandards

Drawehn und Gayer beschreiben in der Marktstudie "BPM 2010" des Fraunhofer-Instituts für Arbeitswirtschaft und Organisation BPMN als vielversprechenden Ansatz, die Lücke zwischen fachlicher Geschäftsprozessmodellierung und der technischen Prozessimplementierung zu schließen. Zudem konnte BPMN als ein Standard, welcher gezielt für die Prozessmodellierung entwickelt wurde, bereits einen hohen Verbreitungsgrad erreichen^[37]. Wie im Abschnitt Kurzvorstellung BPMN 2.0 erwähnt, bietet BPMN 2.0 neben der visuellen Modellierung die Möglichkeit, entsprechend angereicherte Prozesse direkt oder in einer BPEL-Umgebung auszuführen^[24].
An eine Software, welche im Umfeld der Geschäftsprozessmodellierung (als Teil der Geschäftsmodellierung) eingesetzt wird, ergibt sich daher die Anforderung, BPMN in der Version 2.0 zu unterstützen. Die Umsetzung hinsichtlich fachlicher Geschäftsprozessmodellierung wird im Abschnitt BPMN-Diagramm für Geschäftsprozesse untersucht.
Die für den Schluss der Lücke zur technischen Implementation notwendigen Eigenschaften werden im Abschnitt Analysekriterien: Im- und Exportmöglichkeiten spezifiziert.

Es können jedoch nicht alle Sachverhalte in einer Unternehmung mit direkt ausgeführten Prozessen abgebildet werden. So ergibt sich weiterhin die Notwendigkeit, Software zu entwickeln. Für die Beschreibung von Software-Architekturen hat sich in der Praxis der „3-mal-3“-Ansatz bewährt. Dieser beschreibt einen Würfel, dessen Kanten den Ebenen, Perspektiven und Standpunkten entsprechen^[38]. Die Dimension Ebenen ist dabei unterteilt in Technologie, System und Geschäft, während die Standpunkte in die Bereiche konzeptionell, Ausführung und Implementation untergliedert werden, sowie Perspektive in Struktur, Verhalten und Interaktion^[39].

Die Front des Würfels wird schließlich als Architekturmatrix bezeichnet^[40][41].

Folgende Tabelle gibt die Inhalte der Zellen der Matrix wieder:

Tabelle 3: Zusammenfassung Fokus der Architekturmatrix

	Standpunkt	Fokus
Geschäft	Konzeptionell	Geschäftsbetreiber und die Leistungen der Organisation, davon abgeleitet die vernetzten Begriffe der jeweiligen Domäne in der Form eines Geschäftsobjektmodells
	Ausführung	Mit welchen Geschäftsprozessen soll auf die Geschäftsereignisse, also den Bedürfnissen der Kunden, reagiert werden? Welche Geschäftsfunktionen sind dazu notwendig?
	Implementation	Welche Geschäftsrollen und Akteure des Unternehmens sind für die Ausführung der Geschäftsprozesse notwendig und wie wird der Prozess im Unternehmen installiert?
System	Konzeptionell	Welche Services abgeleitet von den Geschäftsobjekten müssen durch das System bereitgestellt werden und wie sind diese untereinander verbunden?
	Ausführung	Zu welchen weitgehend unabhängigen und parallel ausführbaren Subsystemen lassen sich die Services zusammenfassen? Welche aufrufbaren Funktionen stellen diese bereit?
	Implementation	Durch welche Applikationen und Hardwarebausteine werden die Subsysteme implementiert. Wie wird kommuniziert und welches ist die Laufzeitumgebung?
Technologie	Konzeptionell	Aufzählen der Komponenten als kleinste konzeptionelle Einheit einer Architektur und Darstellen der Funktionsweise sowie Interaktionspfade
	Ausführung	Zu welchen Modulen werden die Komponenten zusammengefasst? Benennen der einzusetzenden Middleware und Technologie sowie der notwendigen Infrastruktur.
	Implementation	Auf welchen physikalischen Geräten und Server laufen welche Module, wie sieht das Netzwerk aus und mit welchen Hilfsmitteln wird entwickelt?

Quelle: Schäfer (2010), S. 140

Zu den einzelnen Zellen wiederum eignen sich bestimmte Diagrammtypen als Darstellungsmethode. Diese sind in der folgenden Matrix dargestellt, wobei die unterschiedlichen Diagrammtypen nicht ausschließlich auf einzelne Zellen fixiert sind^[42]:

Dies sind im Einzelnen:

1. Geschäftsobjekt-/Geschäftsklassen-Diagramm (oben links)
2. Anwendungsfall-Diagramm (oben Mitte)
3. Rollen/Akteure (oben rechts)
4. Komponenten und Konnektoren (Mitte links)
5. Komponentendiagramm (Mitte)
6. Modulorganisation (Mitte rechts)
7. (Design-)Klassen- und Datenmodell (unten links)
8. Interaktions-/Sequenzdiagramm (unten Mitte)
9. Laufzeit-Plattform-/Infrastruktur-Modell (unten rechts)

Die Unified Modeling Language (UML) beschreibt einige dieser Diagrammtypen, sowie weitere wie z.B. das Objektdiagramm, das Verteilungsdiagramm, das Aktivitätsdiagramm und das Zustandsdiagramm^[43]. UML wird erweitert durch die Modellierungssprache SysML, die z.B. das Blockdiagramm und das Anforderungsdiagramm bietet^[44].
Neben der Unterstützung der genannten Diagrammtypen (und ggf. weiteren Typen, um zusätzliche Informationen zu transportieren – z.B. ein Organigramm) sollte durch den engen Bezug der modellierten Daten die geeignete Zusammenfassung der erfassten Diagramme in einer gemeinsamen Datei (Projekt) erfolgen, also in einem Gesamtmodell bzw. einer Modellstruktur^[45].
Es ergeben sich also eine Reihe von Anforderungen an ein Softwareprodukt in der Unterstützung von Diagrammtypen. Es ist zu erwarten, dass keine vollständige Unterstützung aller Diagrammtypen erfolgt, da sich die Typen teilweise überschneiden bzw. in Softwareentwicklungsprozessen teilweise eine untergeordnete Rolle spielen.

4.2 Benutzerfreundlichkeit und Ergonomie

Benutzerfreundlichkeit und Ergonomie sind Softwarequalitätsmerkmale, die beschreiben, inwiefern die Software auf die Benutzerbedürfnisse abgestimmt ist. Ein wichtiges Kriterium dabei ist die Anforderung an die graphische Benutzeroberfläche, welche von der International Standardization Organisation in der DIN EN ISO 9241 spezifiziert und in folgende Grundsätze gegliedert ist:

• Aufgabenangemessenheit
  Ein Dialog ist dann aufgabenangemessen, wenn dem Benutzer nur aufgabenrelevante Informationen angezeigt werden und er somit während seiner Aufgabe unterstützt wird. Ein Beispiel ist die Anzeige von Standardwerten in Eingabeformularen^[46].
• Selbstbeschreibungsfähigkeit
  Ein Dialog ist dann selbstbeschreibungsfähig, wenn dem Benutzer ersichtlich gemacht wird, welche Schritte in dem Dialog durchgeführt werden können, bzw. in welchem Status sich der Dialog befindet. Ein Beispiel hierfür sind Beschreibungen bei Eingabefeldern.
• Steuerbarkeit
  Steuerbarkeit von Dialogen wird dadurch erreicht, dass der Benutzer den Ablauf von Aktionen in der Software selbst starten und beeinflussen kann."^[47] kann. Ein Beispiel sind rückgängig zu machende Aktionen.
• Erwartungskonformität
  Ein Dialog ist erwartungskonform, wenn die Erwartungen des Benutzers aufgrund seiner Arbeitskenntnisse erfüllt werden. Ein simples Beispiel ist die Verwendung gleicher Tastenkombinationen bei gleichen Funktionen in verschiedenen Dialogen.
• Fehlertoleranz
  Ein fehlertoleranter Dialog hat die Anforderung, dass der Benutzer sein Arbeitsergebnis auch dann erzielen kann, wenn nicht korrekte Eingaben getätigt werden und diese mit geringem Aufwand manuellen Eingriffs beseitigt werden können.^[47] Ein Beispiel sind Hinweise bei fehlenden Eingaben in einem Formular.
• Individualisierbarkeit
  Ein Dialog ist individualisierbar, wenn der Dialog Anpassungen an der Oberflächengestaltung zulässt. Ein Beispiel sind andockbare, frei anordenbare Dialoge.
• Lernförderlichkeit
  Die Lernförderlichkeit eines Dialoges ist dann gegeben, wenn der Benutzer seitens des Systems eine Unterstützung beim Erlernen der Funktionalitäten der Dialoge erhält^[47]. Ein Beispiel sind Hilfesysteme.

Laut Stahlknecht und Hasenkamp zählen zu den weiteren Kriterien die Darstellung von zusammengehörigen Informationen in Gruppen und die Konfigurierbarkeit von sicht- und hörbaren Signalen^[48].

4.3 Wieder- und Weiterverwendbarkeit

Unter Wieder- und Weiterverwendbarkeit bezeichnen die Autoren die Möglichkeit in einem Modellierungswerkzeug, bereits modellierte Elemente in neuen Diagrammen wiederverwenden zu können. Änderungen in einem Diagramm/Element sollen dabei in allen anderen Diagrammen, die dieses Diagramm/Element verwenden, sichtbar werden. Daher sollten wiederverwendbare Diagramme lediglich als Verweise in anderen Diagrammen existieren. Wiederverwendbare und integrierte Diagramme bringen sowohl Vor- als auch Nachteile. Tabelle 4 zeigt die Positiven und negativen Aspekte beider Ansätze^[49].

Tabelle 4: Vor- und Nachteile eines integrierten/nicht integrierten Modells

	Vorteile	Nachteile
Integriertes Modell	Synergien durch Wiederverwertbarkeit der Modellinhalte mittel- bis langfristig Einsparungen im Modellmanagement gute Ausgangsbasis für zukünftige Erweiterungen umfassendere Informationsbasis für Auswertungen	Initial erhöhter Strukturierungs- und Erstellungsaufwand Abstimmung zwischen allen beteiligten Organisationsbereichen während der Modellerstellung erforderlich Einschränkungen beim abbildbaren Inhalt im integrierten Modell nicht vollständig vermeidbar
Nicht integrierte Modelle	kurzfristiger Zeitvorteil bei der initialen Erstellung keine Notwendigkeit, methodische Kompromisse in der Modellstruktur einzugehen	langfristig erhöhter Pflegeaufwand durch redundante Modellinhalte unzureichende Wiederverwertbarkeit durch fehlende Integration der Inhalte übergreifende Analysen und Weiterverwendung nahezu unmöglich

Quelle: Stähler, Scheuch (2009), S. 10

Das Darstellen von Abhängigkeiten zwischen den verschieden Modellen und den weiteren modellierten Komponenten trägt zum besseren Verständnis der modellierten Zusammenhänge und zur einfacheren Wartbarkeit und Wiederverwendbarkeit der Modelle bei. Dadurch wird gemäß dem Don´t repeat yourself (DRY)-Prinzip Redundanz reduziert und die Konsistenz gewährleistet.

4.4 Mehrbenutzertauglichkeit

Modelle werden oftmals nicht nur von einer Person im Unternehmen, sondern häufig von mehreren, auch abteilungsübergreifend, erstellt. Um eine Zusammenarbeit mehrerer Personen zu ermöglichen, müssen Modellierungswerkzeuge in der Lage sein, die gleichzeitige Bearbeitung von Modellen zuzulassen. Dabei sollte das Modellierungstool entweder die gleichzeitige Bearbeitung eines Diagrammes mit anschließender Synchronisation zulassen oder die gleichzeitige Bearbeitung eines Diagrammes verhindern, um die Datenintegrität zu gewährleisten. Weitere Kriterien für die Mehrbenutzertauglichkeit sind das Anlegen und Verwalten von Benutzern, Benutzerrechten und Rollen. Darüber hinaus sollten erstellte Modelle in einem zentralen Repository abgelegt werden können.

4.5 Dokumentationsmöglichkeiten

„Viele Unternehmen stehen vor komplexen, historisch gewachsenen und undokumentierten IT Systemen“^[50]. Daher soll die systematische Dokumentation von Prozessen gezielt unterstützt werden^[6].
Somit können sich die Prozessakteure bei der Erfüllung ihrer Aufgaben an entsprechenden Modellen orientieren. Dies trägt zur Reduzierung der Komplexität der Prozesse und zur Erhöhung ihrer Wartbarkeit bei. Eines der primären Ziele beim Entwurf von Geschäftsprozessen ist die Dokumentation und Publikation der Ergebnisse^[51]. Ein Geschäftsmodellierungstool soll die Generierung einer Dokumentation in Textform für Empfänger mit unterschiedlichen Anforderungen und Kenntnissen unterstützen. Der Aufwand für die Erstellung und Aktualisierung der Dokumentation soll dabei möglichst gering gehalten werden. Die Aufnahme der Anforderungen, d.h. die Funktion eines Requirements Management Tools (RM-Tool), soll abgedeckt werden. Damit können die Anforderungen entweder vom Fachbereich selbst oder in enger Zusammenarbeit mit der IT aufgenommen werden. Die Dokumentation soll in einem für alle Beteiligten lesbaren Format durch eine Export-Funktion zur Verfügung gestellt werden. Alternativ könnte der Zugriff direkt auf die Modelle, die auf dem Server gespeichert sind, erfolgen. Der Zugriff auf die aktuelle Version der Prozesse und Modellelemente soll gewährleistet werden^[52].

5 Analyse von Innovator for Business Analysts

Der Innovator for Business Analysts steht in den Editionen Personal (kostenfrei), Professional (Einzelplatzversion) und Enterprise (voller Funktionsumfang) zur Verfügung.^[60].
Da der Rahmen dieser Arbeit den Blick auf das gesamte Unternehmen richtet, wird die Analyse an der Enterprise Edition durchgeführt. Nur hier ist nach Angaben der MID GmbH auch eine Kollaboration im Sinne der Bearbeitung von Modellen durch mehrere Benutzer möglich^[60].

Innovator for Business Analysts wird in der Version 11.3.2 Enterprise sowohl unter Windows XP als auch unter Windows 7, teilweise in einer virtualisierten Umgebung (VMware Workstation/Player) untersucht.
Hierbei kommt die Demo-Version zum Einsatz. Diese ist gegenüber einer volllizenzierten Enterprise Edition bezüglich Laufzeit (60 Tage), der maximalen Anzahl modellierbarer Objekte und Mehrbenutzerfähigkeit eingeschränkt^[61]. In der nachfolgend durchgeführten Analyse schränkt nur die fehlende Mehrbenutzerfähigkeit die Möglichkeiten der selbstständigen Untersuchung ein.
Da dieser Punkt bereits durch das Fraunhofer-Institut für Arbeitswirtschaft und Organisation analysiert wurde, wird in dieser Arbeit an entsprechender Stelle auf diese Ergebnisse referenziert.

Es soll nicht unerwähnt bleiben, dass die MID GmbH für die Durchführung der Analyse Enterprise Lizenzen angeboten hat. Dafür sei an dieser Stelle gedankt. Diese wurde jedoch nicht verwendet, da eine zentrale Serverinfrastruktur Voraussetzung für die Nutzung ist. Diese wurde im Sinne einer Aufwand-Nutzen Abwägung im Rahmen dieser Untersuchung nicht aufgebaut.

Im Verlauf der Analyse wurden dem Support der MID GmbH die gewonnenen Erkenntnisse zur Verfügung gestellt, um falsche Bedienung der Software seitens der Autoren im Analyseergebnis bestmöglichst auszuschließen. Die durch den Support gegebenen Hinweise wurden geprüft und in die Analyse übernommen.
Auch für diese Unterstützung sei der MID GmbH gedankt.

Um einen Praxisbezug in der Analyse herstellen zu können, werden die vom Innovator for Business Analysts angebotenen Diagrammarten anhand eines Fallbeispiels modelliert. Das Fallbeispiel behandelt einen Bestellvorgang, bei dem der gesamte Prozess der Bestellung, von der Aufnahme der Anforderung bis zur Genehmigung und Lieferung der Ware, abgebildet wird. Die Ergebnisse der Modellierung werden jeweils im dazugehörigen Kapitel als Abbildung dargestellt.

5.1 Umsetzung von Modellierungsstandards

5.1.1 Anwendungsfalldiagramm

Das UML Anwendungsfalldiagramm dient in der Anforderungsanalyse der Darstellung von Interaktionen zwischen Benutzern, den sogenannten Akteuren, und Systemen. Systeme beinhalten verschiedene Anwendungsfälle, wobei in dieser Diagrammart dargestellt wird, welche Akteure welche Anwendungsfälle auslösen. Der Innovator for Business Analysts unterstützt folgende Diagrammelemente bei der Anwendungsfallmodellierung:

• Akteure
• Anwendungsfallsysteme
• Anwendungsfälle
• Assoziationen
• Generalisierungen
• Kommentare

Im Folgenden wird ein Vergleich der in der offiziellen UML Spezifikation enthaltenden Anforderungen an die Diagrammelemente mit der Umsetzung im Innovator for Business Analysts geführt. Der Innovator for Business Analysts unterstützt laut Herstellerbeschreibung die UML Version 2.1 ^[62]. Verglichen wird mit der neuesten UML Spezifikation in der Version 2.3, da Änderungen, die in der Version 2.2 und 2.3 durchgeführt sind, in dieser Analyse nicht zur Geltung kommen.

Akteure
Ein Akteur ist ein Benutzer oder ein anderes System, welcher mit dem Anwendungsfallsystem interagiert. Laut Spezifikation soll dieser als Strichmännchen oder optional als benutzerdefiniertes Symbol dargestellt werden, wobei der Name des Akteurs unterhalb des Symbols steht und kursiv dargestellt werden soll, falls es sich um einen abstrakten Akteur handelt^[63]. Der Innovator for Business Analysts erfüllt die genannten Forderungen der Spezifikation bis auf die Darstellung eines benutzerdefinierten Akteurs.

Anwendungsfallsysteme
Ein Anwendungsfallsystem wird im Innovator for Business Analysts als Viereck mit dem Namen des Systems im oberen Bereich dargestellt. Damit wird die Forderung aus der Spezifikation erfüllt^[64].

Anwendungsfälle
Anwendungsfälle sind Aktionen, die von einem System ausgeführt werden. Die Notation beläuft sich auf Darstellung des Anwendungsfalles in einer Ellipse mit Namen und weiteren Eigenschaften^[65]. Der Innovator for Business Analysts setzt diese Anforderung um. Zwischen Anwendungsfällen können die Abhängigkeiten include (ein Anwendungsfall beinhaltet automatisch einen anderen Anwendungsfall) und extend (ein Anwendungsfall erweitert einen anderen Anwendungsfall) bestehen. Diese Abhängigkeiten werden ebenfalls korrekt mit gestrichelten Linien und den Schlüsselwörtern <<include>> oder <<extend>> dargestellt^[66].

Assoziationen
Assoziationen dienen der Darstellung, welche Akteure welche Anwendungsfälle ausführen können. Die Darstellung erfolgt mit einer einfachen Verbindungslinie. Laut Spezifikation soll es möglich sein, Multiplikatoren anzugeben^[67], um beispielsweise darstellen zu können wie viele gleiche Akteure benötigt werden, um einen Anwendungsfall auszuführen. Die Multiplikatoren werden im Innovator for Business Analysts bei den mit einer Assoziation verbundenen Diagrammelementen eingestellt. Standardmäßig werden die Multiplikatoren nicht im Diagramm angezeigt, durch Konfiguration ist allerdings eine Umstellung möglich.

Generalisierungen
Generalisierungen sind bei Akteuren und Anwendungsfällen möglich. Sie werden mit einem Strich und einem nicht ausgefüllten Pfeil syntaktisch korrekt wiedergegeben^[68]. Die semantische Korrektheit wird in Innovator dadurch hergestellt, dass Assoziationen und Generalisierungen nur zwischen erlaubten Elementen erstellt werden können. So ist es beispielsweise nicht möglich Generalisierungen zwischen Akteuren und Anwendungsfällen herzustellen.

Kommentare
Ein Kommentar ist ein in einem Viereck mit umgeknickter Ecke dargestellte Anmerkung, die mit beliebigen Elementen durch eine gestrichelte Linie verbunden werden kann^[69]. Der Innovator for Business Analysts bietet die Möglichkeit Kommentare zu erstellen, allerdings erfolgt die Notation nicht gemäß UML Spezifikation, da keine umgeknickte Ecke verwendet wird.

Zusammenfassung
Die Modellierung von Anwendungsfällen erfolgt im Innovator durch Hilfestellungen des Tools semantisch korrekt und benutzerorientiert. Die grundlegenden Elemente der Anwendungsfalldiagramme sind bis auf die Kommentare mit korrekter Syntax implementiert. Allerdings sind optionale bzw. erweiternde Diagrammelemente, die in der Spezifikation erwähnt sind, nicht vorhanden und könnten die Funktionalität des Innovator for Business Analysts weiter vervollständigen.

5.1.3 Strukturdiagramm

Unterstützung in Innovator for Business Analysts

Wie bei der Kurzvorstellung UML in Kapitel 3.4 dargelegt gibt es nach UML eine Reihe von Strukturdiagramm-Untertypen. Dies sind Klassendiagramme (in Kapitel 5.1.4 gesondert untersucht), Komponenten-, Kompositions-, Objekt-, Paket-, Profil- und Verteilungsdiagramme.

Innovator for Business Analysts bietet mit seinem Strukturdiagramm eine Modellierungsmöglichkeit für geschachtelte „Objektstrukturen“. Auf der Diagrammfläche werden entsprechend einzelne Objektstrukturen (Strukturknoten) erzeugt, die wiederum aus anzulegenden Struktureinträgen bestehen. Struktureinträge werden typisiert, indem ihnen Datentypen, die zuvor angelegt wurden, zugewiesen werden (per Drag & Drop oder durch Auswahl aus der Modellstruktur). Dies können neben primitiven Typen wie Ja/Nein-Werten z.B. Wertelisten (Anrede etc.) und selbstdefinierten Typen (die benannt, aber nicht mit bekannten Typen wie z.B. Integer definiert werden) auch andere Struktureinträge und vor allem bereits definierte Klassen aus einem Klassendiagramm sein. Es ist nicht möglich, Datentypen, die in einem Entity-Relationship-Modell definiert wurden (Integer, String o.ä.), zuzuweisen. D.h. hier findet eine Beschränkung auf eine textuelle Beschreibung der Typen statt.
Auf diese Weise werden also Objekte mit ihren Attributen definiert, allerdings nicht wie angenommen werden könnte auch mit Methoden. Dies ist Aufgabe des Klassendiagramms (beschrieben im folgenden Abschnitt 5.1.4). Die Aufgabe des Strukturdiagramms ist also auf die fachlich relevante Struktur der Daten gerichtet, als Vorstufe der Klassenmodellierung (oder auch als Ableitung aus dieser, je nach Blickwinkel). Es besteht die Möglichkeit, die Zusammenhänge der abgeleiteten Klassen mit den Strukturknoten im Strukturdiagramm zu hinterlegen. Diese Zusammenhänge können dann später im Whiteboard-Diagramm sichtbar gemacht werden.

Einordnung des Strukturdiagramms im Modellierungsprozess
Insofern ist das Strukturdiagramm in Innovator for Business Analysts eine nicht unwichtige Zwischenstufe in der Modellierung, aber eben auf fachlicher, d.h. nicht technischer, Ebene, sodass in diesem Bereich die Anforderungen mit dem Fachbereich diskutiert werden können. Das Strukturdiagramm in Innovator for Business Analysts entspricht am ehesten dem Objektdiagramm in der UML, wenn auch mit einigen Unterschieden. Es bietet neben dem Anlegen der Strukturobjekte mit ihren Attributen die Möglichkeit der Darstellung von Abhängigkeiten (lineare Verbinder) sowie die Querverbindung zu Klassen. (Mehr dazu auch in Kapitel 5.1.4).

Weitere Strukturdiagramm-Typen
Komponentendiagramme im Sinne der UML werden in Innovator for Business Analysts innerhalb des Klassendiagramms abgebildet (s. Kapitel 5.1.4), erzeugte Komponenten erscheinen in der Modellstruktur als Ordner, der dann z.B. Anforderungen und Anwendungsfälle enthalten kann. Es ist auch möglich, eine Komponente zuerst in der Modellstruktur anzulegen und später in ein Klassendiagramm zu ziehen und dort weiter zu verwenden.
Kompositionsdiagramme sollen in der UML ermöglichen, die innere Struktur von Klassen und Komponenten darzustellen. Es bietet dazu Anschlüsse, Teile und Konnektoren, sowie Schnittstellen, damit die inneren Teile mit der Außenwelt kommunizieren können^[83]. Dieser Diagrammtyp wird von Innovator for Business Analysts nicht unterstützt.
Ebenfalls fehlen Paketdiagramme im engeren Sinne. Pakete dienen der Sammlung von Modellelementen beliebigen Typs, die zu einer Einheit gruppiert werden^[84]. Da Pakete auch geschachtelt werden und als Baum- bzw. Ordnerstruktur abgebildet werden können, kann die gesamte Modellstruktur in Innovator for Business Analysts als Abbildung einer Paket-Organisation betrachtet werden.
Verteilungsdiagramme (Angabe, welcher Software-Teil auf welcher Hardware/Ausführungseinheit läuft) und Profildiagramme (Darstellung von Stereotypen, Tag-Definitionen und Constraints) werden in Innovator for Business Analysts nicht unterstützt.

Zusammenfassung
Nicht alle Strukturdiagramm-Untertypen, die UML vorsieht, sind in Innovator for Business Analysts umgesetzt, und das angebotene Strukturdiagramm entspricht dem Objektdiagramm, das eigentlich nur einer der Untertypen ist.

5.1.4 Klassendiagramm

Das UML Klassendiagramm dient der Analysen-, Entwurfs- und Implementierungsmodellierung und ist daher das zentrale Element der UML^[85]. Der Innovator for Business Analysts unterstützt folgende Diagrammelemente bei der Klassendiagrammmodellierung:

• Klassen
• Assoziationen
• Generalisierungen
• Schnittstellen
• Datentypen
• Aufzählungstypen
• Primitivtypen
• Komponenten
• Attribute und Operationen
• Aufgezählte Werte
• Kommentare

In der weiteren Analyse der Klassendiagramme unter Innovator for Business Analysts wird auf eine ausführliche Erklärung der Diagrammelemente verzichtet, da dieses den Rahmen dieser Arbeit übersteigen würde. Im Folgenden werden die in der offiziellen UML Spezifikation enthaltenden Anforderungen, insbesondere an die Notation, an die o.g. Diagrammelemente mit der Umsetzung im Innovator for Business Analysts verglichen. Danach erfolgt eine Analyse mit der Fragestellung, ob in der Modellierungssoftware Objektdiagramme unterstützt werden.

Klassen, Attribute und Operationen
In Klassen werden gemeinsame Attribute und Operationen von instanziierten Objekten festgelegt. Laut Spezifikation existieren bei der Darstellung von Klassen mehrere Möglichkeiten. Sie werden immer als Viereck dargestellt, können, müssen aber keine Attribute und Operationen enthalten. Wenn Attribute und Operationen angegeben werden, so ist die Klassendarstellung in drei Bereiche getrennt: Klassenname, Attribut- und Operationsliste. Die Sichtbarkeit von Attributen und Operationen können über die Schlüsselwörter private, protected, oder public, bzw. deren festgelegten Symbolen -, + oder # dargestellt werden. In der Darstellungsrichtlinie werden zudem Klassennamen in fetter Schrift bei normalen Klassen, sowie in kursiver Schrift bei abstrakten Klassen gefordert^[86]. Im Innovator for Business Analysts wird das Klassensymbol syntaktisch korrekt abgebildet. Bei der Sichtbarkeit von Attributen und Operationen wurde auf die festgelegten Symbole gesetzt, wobei die Anzeige der Sichtbarkeit von Operationen für die Anzeige im Diagramm zunächst konfiguriert werden muss. Darüber hinaus ist es nicht möglich eine Parameterliste in Klammern anzugeben und den Rückgabewert der Operation festzulegen, was in der Spezifikation auch als optional bezeichnet ist^[87]. Attribute und Operationen können ausgeblendet werden und die Schriftart ändert sich je nach Klassenart.

Assoziationen
Assoziationen stellen Beziehungen zwischen Klassen dar, wobei diese binär, ternär als auch reflexiv sein können. Sie werden durch eine ausgefüllte Linie mit Klassen an den jeweiligen Endpunkten sichtbar. Optionale Assoziationselemente sind sowohl Namen, Leserichtungen, Multiplikationen als auch Eigenschaften^[88]. Aggregationen sind Assoziationen, bei denen ein Ende als nicht ausgefüllte Raute (bei Kompositionen als ausgefüllte Raute) dargestellt wird. Laut Spezifikation können Assoziationen durch Assoziationsklassen näher beschrieben werden^[89]. In Innovator for Business Analysts können lediglich binäre und reflexive Assoziationen verwendet werden. Ternäre Assoziationen sind genau so wenig implementiert, wie Assoziationsklassen. Die Assoziationen, Kompositionen und Aggregationen selber werden syntaktisch korrekt verwendet, allerdings ist es nicht möglich Assoziationen ohne Namen zu verwenden. Des Weiteren können keine Leserichtungen, sowie mehrere Beschreibungen einer Assoziation zugeordnet werden. In diesem Fall ist die Funktionsweise von Innovator for Business Analysts eingeschränkt. Eine Sonderform der Assoziationen sind Verwendungen. Diese werden eingesetzt, wenn ein Element ein anderes Element für deren vollständige Funktionsweise benötigt. Die Verwendungen werden als gestrichelte Linie mit der Beschreibung <<use>> dargestellt^[90]. Der Innovator for Business Analysts verfolgt diese Notation syntaktisch korrekt.

Generalisierungen
Generalisierungen wurden bereits bei der Anwendungsfallmodellierung beschrieben und können auch bei der Modellierung von Klassendiagrammen verwendet werden.

Schnittstellen
Schnittstellen sind genau festgelegte Funktionalitäten, die einerseits bereitgestellt und verwendet werden können. Auch die UML unterscheidet anbietende und verwendete Schnittstellen. Schnittstellen werden dabei genau wie Klassen in Rechtecken angezeigt, bei denen Attribute und Operationen hinzugefügt werden können. Der einzige sichtbare Unterschied ist die Anzeige eines Symbols neben dem Schnittstellennamen. Auch hier erfüllt der Innovator for Business Analysts die Spezifikationsanforderungen, da eine Beschreibung des Stereotyps mit dem Schlüsselwort <<interface>> eingeblendet werden kann^[91]. Anbietende und verwendete Schnittstellen werden durch Pfeilrichtungen der Assoziationen sowohl in der Spezifikation als auch im Innovator for Business Analysts unterschieden.

Datentypen
Laut Spezifikation sind Datentypen Typen, deren Instanzen sich lediglich von dem Wert der Instanz unterscheiden. Die Darstellung ähnelt dem der Klassen, wobei das Schlüsselwort <<dataType>> als Beschreibung angegeben werden soll^[92]. Im Innovator for Business Analysts werden Datentypen wie gefordert klassenähnlich modelliert, auch die Anzeige eines Stereotyps ist möglich. Darüber hinaus werden Datentypen durch ein Symbol von Klassen unterschieden.

Aufzählungstypen, aufgezählte Werte
Ein Aufzählungstyp ist ein Datentyp, der aus benutzerdefinierten Literalen besteht^[93]. Die Notation ist ähnlich dem der Datentypen. Zusätzlich muss unter dem Namen des Aufzählungstyps eine Liste der Literale angegeben werden können. Darüber hinaus soll das Schlüsselwort <<enumeration>> zur Kennzeichnung verwendet werden. Der Innovator for Business Analysts erlaubt die Angabe der Aufzählungsliste, deren Werte hier "aufgezählte Werte" genannt werden.

Primitivtypen
Primitivtypen sind vordefinierte Datentypen, die keine Unterstruktur besitzen. Beispiele für Primitivtypen sind integer und boolean^[94]. Da Primitivtypen von Datentypen abgeleitet sind, ergibt sich die Tatsache, dass primitive Datentypen ebenfalls Attribute und Operationen besitzen. In der Spezifikation wird für die Notation lediglich das Schlüsselwort <<primitive>> vor dem Namen des Primitivtyps gefordert. Weitere Notationen werden nicht genauer spezifiziert^[94]. Der Innovator for Business Analysts kann den Stereotypen sowohl durch ein Symbol, als auch durch Anzeige des Stereotypnamens darstellen. Darüber hinaus ist es möglich Attribute und Operationen wie bei Klassen anzugeben. Dadurch bietet die Modellierungssoftware alle geforderten Einstellmöglichkeiten an.

Komponenten
Zunächst lässt sich feststellen, dass Komponenten laut Spezifikation nicht Teil von Klassendiagrammen sind, sondern eine eigene Diagrammart in der UML darstellen^[95]. Die UML erlaubt es allerdings Diagrammelemente unterschiedlicher Diagrammarten zu vermischen. Komponenten sind modular gekapselte Teile eines Systems^[96]. Die Notation erlaubt die Darstellung der Komponente in einem Viereck mit dem Stereotypen <<component>> und einem optionalem Komponentensymbol. Außerdem ist es erlaubt Attribute und Operationen aufzulisten^[97]. Der Innovator for Business Analysts setzt die Notationsforderung in der Weise um, dass sowohl Komponenten mit dem Komponentensymbol und dem Stereotypen dargestellt, als auch Attribute und Operationen angegeben werden können.

Objektdiagramme
Objektdiagramme dienen in der Entwurfsmodellierung der Darstellung instanziierter Klassen und somit auch dem Aufzeigen möglicher Testfälle während der Softwaretestung^[98]. Da in der Notation von Objektdiagrammen und Klassendiagramm keine grundlegenden Unterschiede existieren, sondern Objektdiagramme sogar weniger Möglichkeiten als Klassendiagramme bieten, liegt die Vermutung nahe, dass Modellierungssoftware, in denen Klassendiagramme modelliert werden können, auch Objektdiagramme unterstützen. Am ehesten trifft die Notation der Strukturdiagramme in Innovator for Business Analysts auf die UML Objektdiagramme zu. Es können Objektstrukturen mit Struktureinträgen angelegt werden, die Abhängigkeiten zu anderen Objektstrukturen aufweisen können. Dennoch lässt sich diese Diagrammart in Innovator for Business Analysts nicht direkt einer Diagrammart der UML zuordnen, da Strukturdiagramme lediglich ein Obergriff darstellt und die Notation der Objektdiagramme nicht eingehalten wird (z.B. können Objektnamen nicht unterstrichen werden).

Kommentare
Kommentare wurden bereits bei der Anwendungsfallmodellierung beschrieben und können auch bei der Modellierung von Klassendiagrammen verwendet werden.

Zusammenfassung
In der Implementierung der Klassendiagramme werden die Forderungen der UML Spezifikation vom Innovator for Business Analysts umgesetzt. Darüber hinaus zeigt sich, dass die Darstellung der Diagrammelemente (beispielsweise Multiplikatoren bei Assoziationen) für einzelne Diagrammarten konfigurierbar ist. Dieses hat den Vorteil, dass die Diagramme genau für Anwendungszweck und ihre Zielgruppe angepasst werden können (ein Anwendungsentwickler benötigt gegebenenfalls weiterreichende und genauere Informationen als Anforderungsmodellierer). Es wird dabei lediglich die Anzeige angepasst, sodass nicht angezeigte Informationen trotzdem im Hintergrund gespeichert werden. Weiterhin wird deutlich, dass von dem Hersteller eigene Darstellungsmöglichkeiten (Anzeige der Symbole bei Klassen, Schnittstellen, etc.) verwendet werden, die leicht verständlich und übersichtlich sind, aber nicht von der offiziellen UML Spezifikation gefordert werden. Dadurch wird die Darstellung sinnvoll ergänzt.

5.1.5 Geschäftsressourcendiagramm

Innovator for Business Analysts bietet die Möglichkeit, mit einem Geschäftsressourcendiagramm Organisationseinheiten, Gruppen, Stabs- und andere Stellen (im Sinne von Organisationseinheiten), Rollen und Personen, technische Einheiten, Anwendungen und Anwendungssysteme (zusammengefasst als Geschäftsressourcen) im Unternehmen abzubilden und zueinander in Beziehung zu setzen, also die Hierarchie mit abzubilden. Dazu können auch eine Reihe Informationen aus diesem Kontext, wie Verantwortlicher, Stellvertreter und Stakeholderfunktion erfasst werden, sowie Prozesse, die bereits in Innovator for Business Analysts modelliert wurden, zugewiesen werden. Dieser Diagrammtyp dient dem Überblick in der Anforderungsaufnahme, und vor allem auch der Dokumentation, da z.B. die Prozess-Zuordnung zu Organisationseinheiten und Systemen und die Ressourcen-Unterstützung ein wesentlicher Bestandteil des Verständnisses einer Organisation / eines Unternehmens sind.

Dieser Diagrammtyp ist nicht durch die UML vorgegeben, und es besteht eine starke Überschneidung mit dem Organigramm in Innovator, das die gleichen Elemente bietet, allerdings ohne technische Einheiten, Anwendungen und Anwendungssysteme.

5.1.6 Organigramm

Nach Bokranz und Kasten ist ein Organigramm eine grafische oder tabellarische Darstellung der Organisationseinheiten in einem Unternehmen, aus welcher mindestens deren Bezeichnungen und deren hierarchischen Beziehungen hervorgehen. Diese werden als obligatorisch betrachtet. Zu den Organisationseinheiten können die personelle Besetzung, Hinweise auf Hauptaufgaben oder Ordnungsbegriffe wie Telefonnummern, Kostenstellen usw. als weitere Informationen zugeordnet werden. Es ist in der Praxis üblich, über die Elementarform hinaus weitere Informationen zuzuordnen^[99].

In Innovator for Business Analysts können in einem Diagramm vom Typ Organigramm folgende Elementarten mit beinhalteten Elementtypen grafisch modelliert werden:

• Organisationseinheiten
  • Organisationseinheiten
  • Gruppen
  • Stellen
  • Stabstellen
• Ressourcen
  • Personen
  • Mitarbeiter
• Notizen
  • Kommentare

Die obligatorischen Organisationseinheiten sind also bereits als differenzierte Typen modellierbar. Unterscheidbar sind diese in der visuellen Darstellung: Organisationseinheiten werden als Rechteck mit dicker Linie, Gruppen und Stellen als Rechteck mit dünner Linie und Stabstellen als Rechteck mit abgerundeten Ecken dargestellt. Erfolgt die Modellierung hierarchisch, also von oben nach unten, werden die Beziehungen automatisch gesetzt.
Einer Elementart Organisationseinheit können Personen oder Mitarbeiter der Elementart Ressource zugeordnet werden. Auch hier werden die Beziehungen automatisch gesetzt. Ressourcen wiederum ist die Zuordnung von Organisationseinheiten aber nicht möglich.
Ein Kommentar kann, muss aber nicht beliebig vielen Elementen zugeordnet werden.

Zusammenfassung
Die obligatorischen Anforderungen werden erfüllt. Darüber hinaus wird die Modellierung weiterer Informationen ermöglicht. Ebenfalls positiv wird die kontextabhängige Modellierung untergeordneter Elemente bewertet: Während einer Organisationseinheit Ressourcen unterstehen können, können aber einer Ressource keine Organisationseinheiten unterstehen.

Die Möglichkeit, Organigramme im Innovator for Business Analysts zu modellieren, ist eine konsequente Ergänzung zu den Diagrammtypen BPMN und UML.
So kann im Whiteboarddiagramm z.B. die Verknüpfung zwischen Kollaborationen und Pools auf der einen und Akteuren eines Anwendungsfalldiagramms auf der anderen Seite hergestellt werden. Die Verknüpfung weiterer Diagrammelemente ist denkbar und möglich. Dies erleichtert die Einordnung der Diagrammelemente im Gesamtunternehmenskontext.

5.1.7 Zustandsdiagramm

Zustandsdiagramme dienen dazu, die Zustände eines Systems zu beschreiben, die es durchlaufen kann (zusammenfassend auch Automaten genannt). Die Zustände werden dazu mit bedingten Übergängen verbunden, die unterschieden werden in Auslöser (trigger), Bedingungen (guard) und spezielles Verhalten.

Trigger wiederum gibt es mehrere:

• CallTrigger (Reaktion auf die Ausführung einer Methode)
• SignalTrigger (eingehendes Signal, Nachricht)
• ChangeTrigger (Änderung von Variablen)
• TimeTrigger (bestimmter Zeitpunkt oder Ablauf einer Zeit)
• Any Trigger (repräsentiert alle Trigger, nur ausgelöst, wenn kein anderer Übergang aktiviert wird)

In der UML sind außerdem Ein- und Austrittspunkte vorgesehen, Entscheidungen, Start- und Endpunkte, Gedächtnis (Historie), Kreuzungen, Gabelungen, Vereinigungen und Terminierung, außerdem eine Darstellung nebenläufiger (also ggf. gleichzeitig ablaufender) Automaten^[100].
Innovator for Business Analysts unterstützt in diesem Diagrammtyp neben den „normalen“ Zuständen nur Start- und Endzustände, sowie die Übergange zwischen diesen (die lediglich eine Bedingung erfassen können), sowie die Gliederungsmöglichkeit in parallele Abschnitte (Regionen), die den nebenläufigen Automaten entsprechen. Die Anforderungen in diesem Bereich der UML sind daher nicht vollständig umgesetzt.

5.1.8 Maskenflussdiagramm

Das Maskenflussdiagramm in Innovator bietet in der Anforderungsanalyse die Möglichkeit, mit den gleichen Werkzeugen wie in der BPMN (Kollaboration mit Beteiligten, Lanes, Tasks, Gateways, Ereignissen, Datenein- und ausgabe) ergänzt durch einfache Elemente für Masken und Maskenfelder einen Programmablauf aus Sicht der Oberfläche zu entwerfen und abzustimmen. Dabei geht es nicht um den Entwurf von Masken aus Design- oder Usability-Sicht, sondern die Erfassung der eingegebenen Daten und die Abfolge von Masken in der Oberfläche in Abhängigkeit von Ereignissen, Bedingungen (Gateways) und Benutzereingaben.

In diesem Bereich ist entsprechend die Umsetzung des BPMN-Standards wie in Kapitel 5.1.2 beschrieben gegeben, erweitert durch den zusätzlichen Benutzereingabe-Task.

5.2 Benutzerfreundlichkeit und Ergonomie

Die Benutzeroberfläche des Innovator for Business Analysts besteht aus folgenden Bereichen (siehe Abbildung 15):

1. Modellierungsfläche für Diagramme
   Die Modellierungsfläche befindet sich standardmäßig in der Mitte des Programmfensters. Es ist das zentrale Fenster bei der Diagrammmodellierung im Innovator for Business Analysts. Diagrammelemente können per Drag & Drop auf die Modellierungsoberfläche gezogen werden. Wird mit der Maus über ein verwendetes Diagrammelement gefahren, werden alle verfügbaren Verbinder von diesem Diagrammelement angezeigt und können direkt erstellt werden. Dadurch ist die Modellierungsfläche selbstbeschreibungsfähig. Unterstützende Funktionalitäten wie die einfache Ausrichtung von Diagrammelementen erleichtern den Benutzern die Modellierung. Über Kontextmenüs können Einstellungen ausgewählter Diagrammelemente vorgenommen werden. Auffallend und damit negativ einzustufen ist allerdings die Tatsache, dass bei einem leeren Kontextmenü ein kleines leeres Quadrat anstelle des Kontextmenüs angezeigt wird, welches zur Verwirrung des Benutzers beitragen kann. Positiv fällt auf, dass die Diagrammelemente als Vektorgrafiken angezeigt werden und so kein Qualitätsverlust beim Zoomen vorhanden ist.
2. Ribbon-Menüleiste
   Die Ribbon-Menüleiste befindet sich am oberen Programmfensterrand und ist wie bei den neueren Office-Produkten von Microsoft in Gruppen aufgeteilt, welche sich je nach Kontext öffnen. Beispiel: Beim Bearbeiten von Diagrammen werden automatisch die Diagrammtools eingeblendet. Dadurch erscheint die Oberfläche des Innovator for Business Analysts aufgabenangemessen und unterstützt somit die Arbeit des Benutzers. Das Kriterium der Steuerbarkeit wird nur zum Teil erfüllt, da der Benutzer zwar selbst entscheidet, in welcher Reihenfolge Diagramme erstellt werden und in welcher Reihenfolge bei der Diagrammerstellung vorgegangen wird, allerdings Aktionen wie das Hinzufügen oder Umbenennen von Diagrammelementen nicht über eine Rückgängig-Funktion rückgängig gemacht werden können. Hierbei ist noch Steigerungspotenzial in der Benutzerfreundlichkeit vorhanden.
3. Übersichtsansicht über Modellinhalte
   Am linken Programmfensterrand sind drei verschiedene Ansichten über die Inhalte des aktuellen Modells möglich. Zum einen können in der Modellstruktur alle Diagrammelemente hierarchisch eingeblendet werden. Zum anderen bietet der Modellausschnitt eine Ansicht über alle angelegten Diagramme. Schließlich wird in der Diagrammübersicht angezeigt, welche Diagrammarten in dem Modell verwendet werden.
4. Detailbereich
   Im Detailbereich werden detaillierte Informationen zu dem jeweilig ausgewähltem Diagrammelement angezeigt. Dadurch werden jeweils nur relevante Informationen angezeigt und das Kriterium der Aufgabenangemessenheit erfüllt.
5. Eigenschaftsfenster
   Im Eigenschaftsfenster werden, abhängig vom ausgewählten Diagrammelement, deren Eigenschaften und Merkmale angezeigt. Des Weiteren ist das Editieren der Eigenschaften hier möglich. Dieses Fenster erfüllt ebenso das Kriterium der Aufgabenangemessenheit.
6. Diagrammübersicht
   In der Diagrammübersicht wird die Modellierungsfläche in klein dargestellt. Durch einen Rahmen wird der aktuell angezeigte Diagrammausschnitt angezeigt. Durch Verändern des Rahmens in Größe oder Position kann der angezeigte Diagrammausschnitt geändert werden. Das Fenster verhält sich erwartungskonform.
7. Ergebnisbereich
   Der Ergebnisbereich wird standardmäßig über der Statusleiste angezeigt. In ihm werden Ergebnisse (bspw. Suchergebnisse) in einer Liste angezeigt.
8. Statusleiste
   In der Statusleiste werden die aktuellen Status (Modellserver, Modellname, Benutzername, Rollenname, geöffnetes Diagramm) ersichtlich. Außerdem ist die Zoom-Funktionalität hier implementiert.

Das Kriterium der Fehlertoleranz wird dadurch erfüllt, dass nicht durchzuführende Aktionen (bspw. bei Drag & Drop) durch eine andere Darstellung des Mauszeigers ersichtlich gemacht werden.
Der Fensteraufbau ist fast komplett individualisierbar. Lediglich die Position der Ribbon-Menüleiste ist nicht änderbar. Durch Verschieben der Fenster an andere Positionen werden eine Vorschau und eine weitere Benutzerhilfe angezeigt (siehe Abbildung 16), die es vereinfachen, die Fenster neu anzuordnen. Damit gilt das Kriterium der Individualisierbarkeit als erfüllt.
Ein Offline-Hilfesystem ist in der aktuellen Version zum Zeitpunkt des Verfassens nicht verfügbar. Es wird lediglich eine Online-Hilfe angeboten, welche durch Klicken der Hilfe-Schaltfläche aufgerufen werden kann. In dieser sind der Aufbau des Innovator, sowie wichtige Funktionalitäten beschrieben. Dennoch ist es wünschenswert ein Hilfesystem zu integrieren, welches ausführlich alle Fenster, sowie deren Funktionsweise beschreibt. Damit gilt das Kriterium der Lernförderlichkeit als erfüllt, wenngleich noch Verbesserungspotenzial gesehen wird.
Da durch die Ribbon-Menüleiste und die kontextbezogenen Fenster zusammengehörige Informationen in Gruppen angezeigt werden, ist auch dieses Kriterium erfüllt.
Im Innovator for Business Analysts werden auffallend Animationen, wie z.B. bei dem Hinzufügen neuer Diagrammelemente zu bestehenden Diagrammen oder dem Umbenennen von Diagrammelementen ausgeführt. Diese sind zwar optisch schön anzusehen, verzögern aber auch die Benutzung der Oberfläche. Diese Effekte sind nicht konfigurier-, bzw. abschaltbar und können daher vom Benutzer als störend empfunden werden. Informationstöne können ebenfalls nicht konfiguriert werden. Das Kriterium der Konfigurierbarkeit von hör- und sichtbaren Signalen gilt somit als nicht erfüllt.

Zusammenfassung
Zusammenfassend lässt sich anbringen, dass der Innovator for Business Analysts die Kriterien der Dialoggestaltung nach DIN EN ISO 9241 zum allergrößten Teil erfüllt und die Software somit benutzerfreundlich und ergonomisch gestaltet ist.

5.4 Mehrbenutzertauglichkeit

Laut MID GmbH können Modelle in einem Repository abgelegt werden, welcher einen Zugriff für alle Benutzer einer Organisation erlaubt^[102].
Das Fraunhofer-Institut für Arbeitswirtschaft und Organisation stellt in der Marktstudie "BPM 2010" fest, dass eine übergreifende Arbeit im Unternehmen ermöglicht wird, da der Repository Server als Grundlage für alle Modelle und Elemente dient^[103]. Nach der Anmeldung am Repository Server werden alle verfügbaren Modellstrukturen angezeigt. Durch diese zentrale Datenhaltung können unterschiedliche Benutzer auf diese zugreifen und verteilt an den Modellen arbeiten^[81]. Während der Modellbearbeitung kann je Element die Funktion "Exklusiv bearbeiten" bzw. "Freigeben" gewählt werden. Zudem ist es möglich, alle durch den eigenen Benutzer exklusiv gesperrten Elemente eines Modells gleichzeitig wieder freizugeben.
Somit wird das grundsätzliche Kriterium der Mehrbenutzertauglichkeit im Sinne der abteilungsübergreifenden Zusammenarbeit erfüllt. Inwiefern nach gleichzeitiger Bearbeitung eines Elements eine Synchronisation erfolgt bzw. bei fehlendem Status "Exklusiv bearbeiten" eine Warnung an den anderen Benutzer erfolgt, wird aus den am Eingang dieses Kapitels erwähnten Gründen nicht analysiert.

Im Innovator for Business Analysts ist eine Rechteverwaltung integriert. In dieser lassen sich Rollen und Benutzer anlegen, sowie einzelnen Rollen Rechte zuweisen (siehe Abbildung 18). Darüber hinaus bietet der Innovator for Business Analysts die Möglichkeit, vorhandene Benutzer aus dem Active Directory über Lightweight Directory Access Protocol (LDAP) zu importieren. Dadurch müssen Benutzer nicht mehrfach für die Arbeit im Innovator for Business Analysts angelegt werden. Das Kriterium der Rechteverwaltung wird dadurch erfüllt und sogar darüber hinaus durch die Importiermöglichkeit von Benutzern den aufgestellten Kriterienkatalog.

5.5 Dokumentationsmöglichkeiten

Dokumentationserfassung
Der erste Schritt zur Dokumentation der Geschäftsmodellierung ist die Aufnahme von Anforderungen.
Diese werden in der Praxis häufig per E-Mail oder als klassische Textdateien kommuniziert. Diese lassen sich daraufhin entweder mit speziellen Requirement Management Tools oder in Form von Textdateien aufnehmen und verwalten. Diese Herangehensweise bringt gewisse Nachteile mit sich:

• Die Anforderungen sind i.d.R. nicht in den Modellierungstools integriert.
• Der Synchronisationsaufwand von Anforderungsdokumenten zwischen den verschiedenen Akteuren ist hoch.
• Die Fehleranfälligkeit nimmt wegen der Redundanz zu.
  

Innovator for Business Analysts ermöglicht die Aufnahme von Anforderungen mit einem dafür vorgesehenen Element. In diesem Element lassen sich die Anforderungen in Textform aufnehmen. Für jede Anforderung besteht die Möglichkeit, den Ansprechpartner und die involvierten Stakeholder zu definieren, um für spätere Anpassungen bzw. Rückfragen sofort den passenden Ansprechpartner zu finden und die betroffenen Stakeholder zu kontaktieren.
Anwendungsfalldiagramme eignen sich in einem nächsten Schritt wegen ihrer einfachen Form dafür, von dem Fachbereich ein erstes Feedback zu bekommen, ob die modellierten Elemente und deren Beziehungen den Anforderungen entsprechen. Die Anforderungen lassen sich dann in dem Anwendungsfalldiagramm mit Drag & Drop eindeutig einem oder mehreren Anwendungsfällen zuweisen und bei Änderungswünschen ohne Suchaufwand wiederfinden und bearbeiten. Diese lassen sich weiter in anderen Diagrammtypen analog integrieren, wie z.B. UML-Diagrammen oder BPMN-Diagrammen. Die eingepflegten Anforderungen können mit Hilfe von "Labels" mit einem Entwicklungsstatus versehen werden:

• Entwurf
• in Arbeit
• in Überprüfung
• freigegeben

So wird die Rückverfolgbarkeit von Anforderungen und dokumentierten Eigenschaften modellübergreifend gewährleistet.

Abb. 21: Anforderungen im Anwendungsfalldiagramm

Abb. 22: Anforderungen im BPMN-Diagramm

Dokumentationsgenerierung
Die Generierung der angesammelten Anforderungen und Spezifikationen lässt sich mit einem Dokumentationsassistenten generieren. Der Assistent generiert eine granulare (z.B. für selektierte Elemente oder für einen ausgewählten Ausschnitt des Modells) oder eine vollständige Dokumentation für das gesamte Modell. Innovator for Business Analysts unterstützt verschiedene Ausgabeformate:

• Hierarchische Dokumentation als MS-Word-Datei mit EMF-Grafiken
• Diagrammorientierte Dokumentation als MS-Word-Datei mit EMF-Grafiken
• Thematische Dokumentation als MS-Word-Datei mit EMF-Grafiken
• Eine Dokumentationsausgabe in einem Vorschaufenster in Innovator for Business Analysts
• Dokumentation im HTML-Format mit PNG-Grafiken

Abb. 23: Diagrammorientierte Dokumentation als MS-Word-Datei	Abb. 24: Dokumentation im HTML-Format	Abb. 25: Suchfunktion in der HTML-Dokumentation	Abb. 26: Anforderungen in der HTML-Dokumentation
Abb. 27: Anwendungsfalldiagramm in der HTML-Dokumentation

6 Fazit

In den Grundlagen wurde die Erkenntnis dargestellt, dass ein integriertes Konzept des Geschäftsprozess- und Workflow-Managements dem Abgleich der Unternehmensstrategie, der organisatorischen Gestaltung von Prozessen sowie deren technischer Umsetzung dient. Das camunda BPMN-Framework (Abbildung 1) - Ausgangspunkt der Analysekriterien für ein Modellierungwerkzeug - visualisiert diese in Pyramidenform.

Anhand dieser kommen die Autoren nach der Analyse von Innovator for Business Analysts zu einer positiven Bewertung auf der einen und Verbesserungspotential auf der anderen Seite.

Wertvoll ist der Innovator for Business Analysts, wenn es um die Umsetzung von Anforderungen durch Anwendungsentwicklung geht. Hier kann der Weg der Anforderung - von der strategischen über die operative Ebene bis hin zur technischen Spezifizierung - durchgehend abgebildet werden.
Anwendungsfalldiagramme, BPMN Prozessdiagramme und Klassendiagramme werden dabei einwandfrei umgesetzt. Beim Strukturdiagramm besteht Verbesserungspotential. Wie im Analysekapitel Wieder- und Weiterverwendbarkeit dargestellt, gelingt im Anschluss auf einfachem Wege die übergreifende Darstellung der Modelle auf verschiedenen Ebenen im Whiteboarddiagramm.
So wird die Pyramide im fachlichen sowie im technischen Bereich für die Anwendungsentwicklung (auf der Abbildung die Ebenen 3b und 4b, rechtsseitig und blau dargestellt) durchgehend durch Diagramme unterstützt.

Wie in den Grundlagen zu BPMN 2.0 erläutert, kann seitens des Standards die Ausführung an die grafische Modellierung geknüpft werden. Vorteilhaft ist dies beispielsweise für die Umsetzung einer SOA-Strategie, können auf diese Weise doch verschiedene Services ohne Anwendungsentwicklung orchestriert werden. Die Fallstudie hat gezeigt, dass die Prozessausführung einen hohen Nutzen haben kann. So lässt sich die These aufstellen, dass aus der Modellierung mit BPMN auch schnell der Wunsch folgt, ein Modell mittels Process Engine zur Ausführung zu bringen und dabei die fachliche und technische Ebene konsistent zu halten.
Diesbezüglich hat die untersuchte Software im Versionsstand 11.3.2 nur anfängliche Ansätze zu bieten. Wie in der Analyse der Im- und Exportmöglichkeiten dargestellt, wird hierfür ein Plugin benötigt, welches sich nicht im Standardlieferumfang des Innovator for Business Analysts befindet. Doch auch damit gelingt die Verknüpfung der Pyramidenebenen in vertikaler Richtung nicht, sodass unterschiedliche Versionsstände die Folge sein können, und somit eine Lücke zwischen fachlicher und technischer Ebene droht.
Angemerkt sei, dass der Standard BPMN 2.0, welcher das Mittel zur Behebung der Lücke liefert, erst in diesem im Januar 2011 verabschiedet wurde^[1] und somit noch jung ist.

Insgesamt zu einem positiven Ergebnis kommt die Fallstudie bei der grundsätzlichen Benutzerfreundlichkeit und Ergonomie.

Anwendern, welche Anforderungen an eine zu entwickelnde Software mit Prozessen darstellen und die Softwareentwicklung durch weiterführende Diagramme spezifieren möchten, wird der Innovator for Business Analysts empfohlen.
Ist dagegen die Anforderung eine volle Nutzung des BPMN 2.0-Standards über die Prozessmodellierung hinaus, wird der Blick auf andere Softwareprodukte empfohlen.

7 Fußnoten

1. ↑ ^{1,0 1,1 1,2 1,3 1,4 1,5} Vgl. OMG BPMN 2.0 (2011), S. 1
2. ↑ ^{2,0 2,1} Vgl. Spath et al. (2010), S. i
3. ↑ Vgl. Spath et al. (2010), S. 7
4. ↑ ^{4,0 4,1} Vgl. Spath et al. (2010), S. 144
5. ↑ Vgl. Österle (1995), S. 19
6. ↑ ^{6,0 6,1 6,2} Vgl. Bartsch (2010), S. 9
7. ↑ „[...] a Process is simply a structured, measured set of activities designed to produce a specified output [...]. It implies a strong emphasis on how work is done within an organisation[...]. A Process is thus a specific ordering of Work activities across time and place, with a beginning, an end, and clearly identified input and outputs: a structure of action.“ übersetzt nach Davenport (1993), S. 5
8. ↑ Vgl. Seidlmeier (2010), S. 1
9. ↑ Seidlmeier (2010), S. 2
10. ↑ Vgl. Seidlmeier (2010), S. 6
11. ↑ Gadatsch (2010), S. 1
12. ↑ Vgl. Gadatsch (2010), S. 20
13. ↑ Vgl. Gadatsch (2010), S. 21
14. ↑ Vgl. Gadatsch (2010), S. 22
15. ↑ Vgl. Gadatsch (2010), S. 63
16. ↑ ^{16,0 16,1} Vgl. Gadatsch (2010), S. 67 bis 69
17. ↑ Vgl. Gadatsch (2010), S. 70 f.
18. ↑ Vgl. Allweyer (2009), S. 8
19. ↑ Vgl. OMG BPMN 2.0 (2011), S. 22
20. ↑ Vgl. OMG BPMN 2.0 (2011), S. 22 f.
21. ↑ Vgl. OMG BPMN 2.0 (2011), S. 145
22. ↑ Vgl. OMG BPMN 2.0 (2011), S. 315
23. ↑ Vgl. OMG BPMN 2.0 (2011), S. 24
24. ↑ ^{24,0 24,1} Vgl. Allweyer (2009), S. 12
25. ↑ Vgl. Allweyer (2009), S. 13 f.
26. ↑ Vgl. Seeman, von Gudenberg, S. 3
27. ↑ Vgl. OMG UML Infrastructure (2010), S. 1
28. ↑ Vgl. OMG UML Infrastructure (2010), S. 14
29. ↑ ^{29,0 29,1} Vgl. Spath et al. (2010), S. 8
30. ↑ Vgl. Freund, Rücker (2010), S. 6 bis 8
31. ↑ Vgl. o. V. Fraunhofer IAO: Glossar: Workflow (2010), o. S.
32. ↑ Vgl. Spath et al. (2010), S. 13
33. ↑ Vgl. Spath et al. (2010), S. 11
34. ↑ ^{34,0 34,1} Vgl. Freund, Rücker (2010), S. 16
35. ↑ Vgl. Schäfer (2010), S. 29 ff.
36. ↑ Schäfer (2010), S. 127
37. ↑ Vgl. Spath et al. (2010), S. 16
38. ↑ Vgl. Schäfer (2010), S. 127 ff.
39. ↑ Vgl. Schäfer (2010), S. 129
40. ↑ Vgl. Schäfer (2010), S. 132 u. 137 ff.
41. ↑ Auf weitere Ausführungen soll an dieser Stelle verzichtet werden, da die umfassende Methodenbeschreibung in der Softwareentwicklung den Rahmen dieser Arbeit sprengen würde.
42. ↑ Vgl. Schäfer (2010), S. 140
43. ↑ Vgl. Schäfer (2010), S. 37 bis 77
44. ↑ Vgl. Schäfer (2010), S. 79 ff.
45. ↑ Vgl. Schäfer (2010), S. 91 ff.
46. ↑ Vgl. Stapelkamp (2010), S. 328
47. ↑ ^{47,0 47,1 47,2} Stahlknecht, Hasenkamp (2005), S. 312
48. ↑ Vgl. Stahlknecht, Hasenkamp (2005), S. 313
49. ↑ Vgl. Stähler, Scheuch (2009), S. 10
50. ↑ Gadatsch 2010, S. 112
51. ↑ Vgl. Winter et al. (2010), S. 156
52. ↑ Vgl. Spath et al. (2010), S. 220
53. ↑ Vgl. Spath et al. (2010), S. 13
54. ↑ Vgl. Spath et al. (2010), S. 19 f.
55. ↑ Vgl. Spath et al. (2010), S. 12
56. ↑ Vgl. Schatten et al. (2010), S. 221
57. ↑ Vgl. Spath et al. (2010), S. 17 f.
58. ↑ Vgl. Spath et al. (2010), S. 18 f.
59. ↑ Vgl. Spath et al. (2010), S. 219 f.
60. ↑ ^{60,0 60,1} Vgl. o. V. MID: Downloads (o. J.), o. S.
61. ↑ Vgl. o. V. MID: Innovator Demo (o. J.), o. S.
62. ↑ Vgl. o. V. MID: Modellierungsplattform Innovator (2011), o. S.
63. ↑ Vgl. OMG UML Superstructure (2010), S. 605 f.
64. ↑ Vgl. OMG UML Superstructure (2010), S. 607
65. ↑ Vgl. OMG UML Superstructure (2010), S. 614
66. ↑ Vgl. OMG UML Superstructure (2010), S. 617 f.
67. ↑ Vgl. OMG UML Superstructure (2010), S. 613 f.
68. ↑ Vgl. OMG UML Superstructure (2010), S. 57
69. ↑ Vgl. OMG UML Superstructure (2010), S. 58
70. ↑ ^{70,0 70,1} Vgl. Weidlich, HPI Uni Potsdam (2009), S. 6
71. ↑ ^{71,0 71,1} Vgl. OMG BPMN 2.0 (2011), S. 10
72. ↑ Vgl. o. V. MID: Features (o. J.), o. S.
73. ↑ o. V. MID: Solutions (o. J.), o. S.
74. ↑ ^{74,0 74,1} Vgl. Spath et al. (2010), S. 140
75. ↑ Vgl. Spath et al. (2010), S. 142
76. ↑ Vgl. Freund, Rücker (2010), S. 71 f.
77. ↑ Vgl. Spath et al. (2010), S. 209
78. ↑ ^{78,0 78,1 78,2} Vgl. Spath et al. (2010), S. 137
79. ↑ ^{79,0 79,1} Vgl. Persönliche Mitteilung von "Technische Hotline der MID GmbH" vom 16.06.2011 im Abschnitt Weitere Anhänge
80. ↑ Vgl. Allweyer (2009), S. 93 f.
81. ↑ ^{81,0 81,1} Vgl. Spath et al. (2010), S. 143
82. ↑ Vgl. Spath et al. (2010), S. 206
83. ↑ Vgl. Schäfer (2010), S. 46
84. ↑ Vgl. Forbrig (2007), S. 105
85. ↑ Vgl. Seeman, von Gudenberg, S. 43
86. ↑ Vgl. OMG UML Superstructure (2010), S. 51 f.
87. ↑ Vgl. OMG UML Superstructure (2010), S. 109
88. ↑ Vgl. OMG UML Superstructure (2010), S. 41
89. ↑ Vgl. OMG UML Superstructure (2010), S. 47
90. ↑ Vgl. OMG UML Superstructure (2010), S. 140
91. ↑ Vgl. OMG UML Superstructure (2010), S. 89
92. ↑ Vgl. OMG UML Superstructure (2010), S. 62
93. ↑ Vgl. OMG UML Superstructure (2010), S. 69
94. ↑ ^{94,0 94,1} Vgl. OMG UML Superstructure (2010), S. 125
95. ↑ Vgl. OMG UML Superstructure (2010), S. i f.
96. ↑ Vgl. OMG UML Superstructure (2010), S. 150
97. ↑ Vgl. OMG UML Superstructure (2010), S. 154
98. ↑ Vgl. Seeman, von Gudenberg, S. 49
99. ↑ Vgl. Bokranz, Kasten (2003), S. 165
100. ↑ Vgl. Forbig (2007), S. 124 ff.
101. ↑ o. V. MID: Online-Hilfe (Modellseite) (2011), o. S.
102. ↑ Vgl. o. V. MID: Datasheet Innovator for Business Analysts (2011), S. 3
103. ↑ Vgl. Spath et al. (2010), S. 137 u. 142
104. ↑ ^{104,0 104,1 104,2 104,3} Vgl. Spath et al. (2010), S. 144
105. ↑ o. V. MID: Erweiterungen, o. S.
106. ↑ Vgl. Spath et al. (2010), S. 146
107. ↑ ^{107,0 107,1 107,2} Vgl. Spath et al. (2010), S. 145
108. ↑ o. V. MID: Erweiterungen, o. S.

8 Anhang

8.1 Literaturverzeichnis

Allweyer (2009)	Allweyer, Thomas: BPMN 2.0: Business Process Model and Notation: Einführung in den Standard für die Geschäftsprozessmodellierung, 2., aktualisierte und erweiterte Auflage, Books on Demand GmbH, Norderstedt 2009
Bartsch (2010)	Bartsch, Christian: Modellierung und Simulation von IT-Dienstleistungsprozessen, KIT Scientific Publishing, Karlsruhe 2010
Bokranz, Kasten (2003)	Bokranz, Rainer; Kasten, Lars; Bundesverband der Deutschen Volksbanken und Raiffeisenbanken (BVR) (Hrsg.); Verband für Arbeitsgestaltung, Betriebsorganisation und Unternehmensentwicklung (REFA) (Hrsg.): Organisations-Management in Dienstleistung und Verwaltung: Gestaltungsfelder, Instrumente und Konzepte, 4., überarbeitete Auflage, Gabler, Wiesbaden 2003
Davenport (1993)	Davenport, Th.H.: Process Innovation – reengineering work through information technology, Harvard Business School, Boston 1993
Forbrig (2007)	Forbrig, Peter: Objektorientierte Softwareentwicklung mit UML, 3., völlig neu bearbeitete und erweiterte Auflage, Calr Hanser Verlag, München 2007
Freund, Rücker (2010)	Freund, Jakob; Rücker, Bernd: Praxishandbuch BPMN 2.0, 2., aktualisierte Auflage, Carl Hanser Verlag, München, Wien 2010
Gadatsch (2010)	Gadatsch, Andreas: Grundkurs Geschäftsprozess-Management: Methoden und Werkzeuge für die IT-Praxis: Eine Einführung für Studenten und Praktiker, 6., aktualisierte Auflage, Vieweg + Teubner, Wiesbaden 2010
Linssen (2002)	Linssen, Oliver: Die objektorientierte Modellierung von Geschäftsprozessen: Die erweiterte Object Behaviour Analysis (OBA++) als Ergänzung der Unified Modeling Language (UML). Inauguraldissertation zur Erlangung des akademischen Grades eines Doktors der Wirtschaftswissenschaft (doctor rerum oeconomicarum) am Fachbereich Wirtschafts- und Sozialwissenschaften der Bergischen Universität (GH) Wuppertal, Wuppertal 2002
o. V. Fraunhofer IAO: Glossar: Workflow (2010)	o. V., Fraunhofer-Institut für Arbeitswirtschaft und Organisation IAO (Hrsg.): IAO Zentrum Dokumenten- und Workflow-Management: Glossar: Workflow, 2010, http://www.dm.iao.fraunhofer.de/glossar/thematisch/Workflow.jsp (13.06.2011, 12:21)
o. V. MID: Datasheet Innovator for Business Analysts (2011)	o. V., MID GmbH (Hrsg.): Datasheet Innovator for Business Analysts, 2011, http://www.mid.de/fileadmin/mid/PDF/Datasheets/Datasheet_Innovator_for_Business_Analysts.pdf (12.06.2011, 20:51)
o. V. MID: Downloads (o. J.)	o. V., MID GmbH (Hrsg.): Innovator for Business Analysts: Downloads, o. J., http://www.mid.de/de/produkte/innovator-for-business-analysts/downloads.html (16.06.2011, 12:58)
o. V. MID: Erweiterungen (o. J.)	o. V., MID GmbH (Hrsg.): Produkte: Innovator for Business Analysts: Erweiterungen, o. J., http://www.mid.de/de/produkte/innovator-for-business-analysts/erweiterungen.html (15.06.2011, 16:07)
o. V. MID: Features (o. J.)	o. V., MID GmbH (Hrsg.): Innovator for Business Analysts: Features, o. J., http://www.mid.de/de/produkte/innovator-for-business-analysts/features.html (12.06.2011, 12:45)
o. V. MID: Innovator Demo (o. J.)	o. V., MID GmbH (Hrsg.): Innovator for Business Analysts: Innovator Demo Enterprise Edition (Version 11), o. J., http://www.mid.de/de/produkte/innovator-for-business-analysts/downloads/download-innovator-for-business-analysts/download-enterprise-edition/formular-download-enterprise-edition.html (17.06.2011, 11:13)
o. V. MID: Modellierungsplattform Innovator (2011)	o. V., MID GmbH (Hrsg.): Modellierungsplattform Innovator, 2011, http://www.mid.de/produkte/modellierungsplattform-innovator.html (13.06.2011, 20:13)
o. V. MID: Online-Hilfe (Modellseite) (2011)	o. V., MID GmbH (Hrsg.): Online-Hilfe (Modellseite), 2011, http://www.mid.de/innovator-online-hilfe/modellseite/innovator-11-r3-online-hilfe.html (29.05.2011, 22:47)
o. V. MID: Solutions (o. J.)	o. V., MID GmbH (Hrsg.): Solutions: Business Process Analysis (BPA) und BPMN, o. J., http://www.mid.de/de/solutions/business-process-analysis.html (12.06.2011, 13:16)
OMG BPMN 2.0 (2011)	Object Management Group, Inc. (Hrsg.): Business Process Model and Notation (BPMN): Version 2.0, Needham 2011, http://www.omg.org/spec/BPMN/2.0/PDF (16.05.2011, 21:41)
OMG UML Infrastructure (2010)	Object Management Group, Inc. (Hrsg.): OMG Unified Modeling Language (OMG UML), Infrastructure, Version 2.3, without change bars, Needham 2010, http://www.omg.org/spec/UML/2.3/Infrastructure/PDF (17.05.2011, 20:28)
OMG UML Superstructure (2010)	Object Management Group, Inc. (Hrsg.): OMG Unified Modeling Language (OMG UML), Superstructure, Version 2.3, without change bars, Needham 2010, http://www.omg.org/spec/UML/2.3/Superstructure/PDF (01.06.2011, 21:39)
Österle (1995)	Österle, Hubert: Business Engineering. Prozeß- und Systementwicklung, Band 1, Springer-Verlag, Berlin 1995
Schatten et al. (2010)	Alexander Schatten, Stefan Biffl, Markus Demolsky, Erik Gostischa-Franta, Thomas A-Streicher, Dietmar Winkler: Best Practice Software-Engineering: Eine praxiserprobte Zusammenstellung von komponentenorientierten Konzepten, Methoden und Werkzeugen, Springer-Verlag, Berlin 2010
Schäfer (2010)	Schäfer, Werner: Softwareentwicklung, Einstieg für Anspruchsvolle, Pearson Studium, Addison-Wesley, München 2010
Seemann, von Gudenberg (2006)	Seemann, Jochen; von Gudenberg, Jürgen Wolff: Softwareentwurf mit UML 2, Objektorientierte Modellierung mit Beispielen in Java, 2. Auflage, Springer-Verlag, Berlin Heidelberg 2006
Seidlmeier (2010)	Seidlmeier, Heinrich: Prozessmodellierung mit ARIS®, Eine beispielorientierte Einführung für Studium und Praxis, 3., aktualisierte Auflage, Vieweg + Teubner, Springer Fachmedien, Wiesbaden 2010
Spath et al. (2010)	Spath, Dieter (Hrsg.); Drawehn, Jens; Gayer, Sebastian; Schneider, Patrick; Weisbecker, Anette (Hrsg.); Fraunhofer-Institut für Arbeitswirtschaft und Organisation (Hrsg.): Business process modeling 2010: Modellierung von ausführbaren Geschäftsprozessen mit der Business Process Modeling Notation, Fraunhofer-Verlag, Stuttgart 2010
Stahlknecht, Hasenkamp (2005)	Stahlknecht, Peter; Hasenkamp, Ulrich: Einführung in die Wirtschaftsinformatik, 11. Auflage, Springer-Verlag, Berlin Heidelberg 2005
Stapelkamp (2010)	Stapelkamp, Torsten: Interaction- und Interfacedesign, Web-, Game-, Produkt-, und Servicedesign, Usability und Interface als Corporate Identity, Springer-Verlag, Berlin Heidelberg 2010
Stähler et al. (2009)	Stähler, Dirk; Meier, Ingo; Scheuch, Rolf; Schmülling, Christian; Somssich, Daniel: Enterprise Architecture, BPM und SOA für Business-Analysten: Leitfaden für die Praxis, Carl Hanser Verlag, München 2009
Stähler, Scheuch (2009)	Stähler, Dirk; Scheuch, Rolf: Enterprise architecture, BPM und SOA für Business-Analysten: Leitfaden für die Praxis, Hanser Verlag, München 2009
Teschke (2003)	Teschke, Thorsten: Semantische Komponentensuche auf Basis von Geschäftsprozessmodellen: Dissertation zur Erlangung des Grades des Doktors der Naturwissenschaften am Department für Informatik der Carl von Ossietzky Universität Oldenburg, Oldenburg 2003
Weidlich, HPI Uni Potsdam (2009)	Weidlich, Matthias; Hasso Plattner Institut, Universität Potsdam (Hrsg.): BPMN 2.0: Conformance Level & BPEL Alignment, 27.05.2009, http://www.bpmb.de/images/HU_Berlin_BPMN2_6_Weidlich_BPMN2BPEL.pdf (16.06.2011, 10:40)
Winter et al. (2010)	Winter, Robert; Österle, H. (Hrsg.); Brenner, W. (Hrsg.); Albani, Antonia (Mitarb.); Gericke, Anke (Mitarb.); Gleichauf, Bettina (Mitarb.): Business Engineering Navigator, Springer-Verlag, Berlin 2010

8.2 Weitere Anhänge

Persönliche Mitteilung von "Technische Hotline der MID GmbH" vom 16.06.2011:

Von:  Technische Hotline der MID GmbH 
Gesendet:  Do 16.06.2011 11:35 
An:  Jakob Engelmartin 

[...]
> Zu Ihrer vorherigen Mail wäre uns wichtig zu erfahren, weshalb
> Fraunhofer [...] einen BPMN2BPEL-Generator nutzen konnte, dieser
> jetzt aber nicht zur Verfügung steht.

Die Generatoren für BPEL und WSDL und auch der Importer für WSDL sind
keine festen Bestandteile der ausgelieferten Version. Wir arbeiten mit
diesen Tools in immer wieder erweiterten und auch korrigierten Versionen
bei Kunden bzw. aktuell für eine Buchpublikation.

Wahrscheinlich werden sie in einem späteren Release von Innovator als
offizieller Bestandteil mit der Software ausgeliefert. [...]